B9 Archi Dim Methods Workshop June2007
-
Upload
abraham-kra -
Category
Documents
-
view
109 -
download
6
Transcript of B9 Archi Dim Methods Workshop June2007
1 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 BSS Dimensioning Methods
GSM Network Engineering Team
Architecture CHECK
Parameter CHECK
Dimensioning Methods RUN
Network ArchitectureASSESSMENT
2 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Agenda for 6th of June
Start time : 09:00am (French Time)
� High level presentation of Enhanced Transmission Resources
Management
� Counter based dimensioning rules:
* Abis dimensioning
* AterMux PS dimensioning
* GPU/GP dimensioning
* Gb dimensioning
� Main recommendations on BSS PS dimensioning related parameters
� BSS dimensioning: overview on available documentation and tools
� Questions & Answers
End time :1:00pm (French Time)
3 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Enhanced Transmission Resource
Management overview
4 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Enhanced transmission resource management
In B9, transmission resource management algorithms were enhanced
with respect to B8 in order to optimise resource usage at Abis and
Ater interface level.
This was obtained through the following new features:
� M-EGCH Statistical Multiplexing
� Dynamic Abis Allocation
� Ater resource management
� DL retransmission in BTS
5 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
M-EGCH Statistical Multiplexing (1/5)
M-EGCH Statistical Multiplexing
� This feature provides a solution to share the Ater and Abis nibbles between
the radio timeslots of a TRX so that the transmission resources left
available by a PDCH can be reused by other PDCHs as long as those PDCHs
belong to the same TRX.
� An M-EGCH link (Multiplexed Enhanced GPRS CHannel) is a bi-directional
link established between the MFS and the BTS.
TRX
0
1
2
3
4
5
6
7
M-EGCH link
Single Packet pipe
TCH
TCH
Unused TS: no Abis resource required
CS traffic
PS traffic
GCH Extra
GCH Basic
GCH Basic
GCH Extra
GCH Bonus
6 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
M-EGCH Statistical Multiplexing (2/5)
M-EGCH Statistical Multiplexing
B8: one EGCH per RTSB8: one EGCH per RTSB9: one M-EGCH link for
the whole TRXB9: one M-EGCH link for
the whole TRX
0 1 762 3 4 5
EGCH
0 1 762 3 4 5TRX
M-EGCH link
1 to 36 GCHs
composed of
GCH
EGCH
EGCH
EGCH
EGCH
EGCH
EGCH
EGCH
GCH
GCH
GCH
GCH
1 to 5 GCHs depending on the TRX class
GCH
composed of
GCH
GCH
GCH
GCH
TRX
7 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
M-EGCH Statistical Multiplexing (3/5)
M-EGCH Statistical Multiplexing
Number of GCHs required per PDCH for a given CS:
1,601,64CS-4
1,221,25CS-3
1,001,00CS-2
0,730,73CS-1
DLULCS
Number of required GCHs
With Statistical Multiplexing, nb of GCH has not to be rounded-up
8 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
M-EGCH Statistical Multiplexing (4/5)
M-EGCH Statistical Multiplexing
Number of GCHs required per PDCH for a given MCS:
4,394,49MCS-9
4,004,14MCS-8
3,393,49MCS-7
2,312,36MCS-6
1,811,86MCS-5
1,471,50MCS-4
1,281,33MCS-3
1,001,00MCS-2
0,860,89MCS-1
DLULMCS
Number of required GCHs
With Statistical Multiplexing, nb of GCH has not to be rounded-up
9 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
M-EGCH Statistical Multiplexing (5/5)
M-EGCH Statistical Multiplexing
� The size of an M-EGCH link (associated to a TRX) can be dynamically decreased or
increased.
� The algorithms to dynamically decrease or increase the size of an M-EGCH link
correspond to the Dynamic Abis allocation.
10 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Dynamic Abis Allocation (1/5)
Dynamic Abis Allocation
� This feature enables to dynamically allocate Abis nibbles among the
different TRXs used for PS traffic in a given BTS.
� Compared to B8, it allows a higher average Abis bandwidth per PDCH, the
BSC capacity in terms of TRXs is increased, and in some BTS configurations
it may avoid to deploy a second Abis link.
11 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Dynamic Abis Allocation (2/5)
Dynamic Abis Allocation
B8: static Abis allocationB8: static Abis allocation B9: dynamic Abis allocationB9: dynamic Abis allocation
0 1 762 3 4 5
EGCH
0 1 762 3 4 5TRX
M-EGCH link
1 to 36 GCHs (mixture of GCHs using basic, extra and bonus Abis nibbles)
composed of
1 to 5 GCHs depending on the TRX class (and only one GCH can
use a basic Abis nibble)
GCH Basic
composed of
EGCH
EGCH
EGCH
EGCH
EGCH
EGCH
EGCH
GCH Extra
Basic Abis nibbles and
Extra Abis nibbles are statically
mapped to a RTS.They can only be used in the EGCH
of this RTS.GCH Extra
GCH Extra
GCH Extra
GCH Basic
GCH Extra
GCH Basic
GCH Extra
No more constraints in
B9!
GCH Basic
TRX
12 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Dynamic Abis Allocation (3/5)
Dynamic Abis Allocation
� In B8, a lot of Abis nibbles were “wasted”
� An example:
13 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Dynamic Abis Allocation (4/5)
Dynamic Abis Allocation
� In B9, the following Abis nibbles are usable for PS traffic:
� The basic Abis nibbles mapped to a RTS currently available for PS traffic (see
“Autonomous Packet Resource Allocation" feature to know the list of those RTSs)
or mapped to a RTS used as MPDCH.
� The “bonus” basic Abis nibbles currently used for BCCH or static SDCCH
channels:
– The list of “bonus” Abis nibbles depends on the cell configuration.
� All the extra Abis nibbles of the BTS:
– A number of 64k extra Abis TSs is defined for each BTS by O&M
(N_EXTRA_ABIS_TS).
14 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Dynamic Abis Allocation (5/5)
Dynamic Abis Allocation
� Level of sharing of the Abis nibbles are usable for PS traffic:
� The basic Abis nibbles mapped on a RTS allocated to MFS can be used in the M-
EGCH link of any TRX of the CELL.
� The extra Abis nibbles can be used in the M-EGCH link of any TRX of the BTS.
� The “bonus” Abis nibbles can be used in the M-EGCH link of any TRX of the BTS.
TRX 2 M-EGCH link 1
PS traffic
TRX 3 M-EGCH link 2
TRX n M-EGCH link n
BTS
Dynamic A bis
allocation
GCH Extra
GCH Basic
GCH Basic
GCH Extra
GCH Bonus
Abis
TCH
TCH TRX 1 CS
traffic
n ≤ 12
15 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Ater Resource ManagementPrinciples
The Ater Resource Management in a given GPU is based on two
complementary mechanisms:
� GPU Ater TS margin,
� “High Ater usage” handling.
A strong requirement is to ensure GPRS access in all the cells of the GPU (no cell shall be blocked due to an Ater congestion).
16 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Ater Resource ManagementGPU Ater TS Margin
GPU 64k Ater TS margin:
� Aim:
� Ensures that GPRS access can never be blocked in a cell due to lack of Ater
resources in the GPU.
� Handled in each GPU to serve some priority requests at any moment and in any cell
managed by the GPU.
– Priority request is the GCH establishment request for the “first PS traffic in a cell” (first TBF to establish in a cell).
� Management:
� Release of some GCHs when the remaining number of free 64k Ater TSs in the GPU
becomes too low (O&M parameter N_ATER_TS_MARGIN_GPU).
� For a given TRX, when releasing GCHs, it is ensured that:
– Established_Nb_GCH remains higher than Min_Nb_GCH.
17 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Ater Resource Management“High Ater usage” handling (I)
High Ater usage handling:
� Definition of the Ater usage of a GPU:
� Represents the consumption of Ater nibbles (by GCH channels) among the
PCM links connected to the GPU,
� Ater usage can be either “normal” or “high”.
� Decision based on the comparison of the Ater nibble consumption with a
threshold (Ater_Usage_Threshold O&M parameter).
18 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Ater Resource Management“High Ater usage” handling (II)
� Behaviour if Ater usage is “high”:
� Target_Nb_GCH values associated to TRXs of the GPU supporting some PS traffic will be reduced:
GCH_RED_FACTOR_HIGH_ATER_USAGE O&M parameter.
� The reduction factor is only applied on PDCHs newly open.
– “newly open” PDCH means that no radio resources were previously allocated on this PDCH.
� When evaluating Target_Nb_GCH on a given TRX:
– If PDCH already open, no reduction is applied,– If PDCH is newly open, reduction is applied.
19 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Ater Resource Management“High Ater usage” handling (III)
� Example:
� Max_EGPRS_MCS = MCS-9,
� GCH_RED_FACTOR_HIGH_ATER_USAGE = 0,5
1) Ater usage = “normal”
2) Establishment of an EGPRS DL TBF on RTS0-3
� Target_Nb_GCH = 4 * Nb_GCH(Max_EGPRS_MCS) = 4 * 4,49 = 18
3) Ater usage = “high”
4) Establishment of an EGPRS DL TBF on RST4-7
� Target_Nb_GCH = 4 * Nb_GCH(Max_EGPRS_MCS) + 0,5 * 4 * Nb_GCH(Max_EGPRS_MCS) = 4 * 4,49 + 4 * 0,5 * 4,49 = 27 (< 36)
20 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
DL retransmission in the BTSPrinciples (I)
� Goal:
� Avoid consuming transmission resources (Abis + Ater) in case of DL RLC
data block retransmissions.
� Principles:
� Store for a certain time, in the memory of the TRE involved in the packet
transfer mode with an MS, the DL RLC data blocks received from the
RLC/MAC layer for this MS.
� Then, the RLC/MAC layer (in the MFS) can ask the TRE (in the BTS) to
retransmit some data blocks.
� Data received from the MFS are stored in a buffer.
21 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
DL retransmission in the BTSPrinciples (II)
� This mechanism is enabled / disabled depending on the EN_DL_RETRANS_BTSparameter, on the TRX HW capability and on the MFS-BTS round_Trip_delay:
� Gains:� Higher available transmission bandwidth.� M-EGCH link dimensioning is eased.
DisabledDisabledDisabled-disabled
DisabledDisabledDisabled≥ 500 msEnabled
EnabledDisabledDisabled< 500 msEnabled
CS-4+MCS-9
(G4 or M5M)
CS-4
(G3 or M4M)
CS-2
(DRFU)
HW generation of the TRE
Round_Trip_DelayEN_DL_RETRANS_BTS
22 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Counter Based Dimensioning Rules
Architecture CHECK
Parameter CHECK
Dimensioning Methods RUN
Network ArchitectureASSESSMENT
23 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
BSS architecture & dimensioning rules
What’s new in B9 …
BSC Abis TSU
Ater TSU
Abis TSU
Ater TSU
Abis TSU
Ater TSU
SGSN
speech
data
A-ter mux
Gb
A
CS
CS+ PS
PS
CSA-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 -EG CH link 1
PS traffic
TRX 3 M -EG CH link 2
M -EG CH link n
BTS
Dynam ic Ab is
a llocation GCH Extra
GCH Basic
GCH Basic
GCH Extra
GCH Bonus
T CH
T CH TRX 1 CS
traffic
TRX n
Assessment ofbasic and bonus Abis nibbles from
TRX and BTS configuration
Calculate the needed extra Abis TS for real traffic on Abis Itf and the number of
needed Abis links
Assessment ofCS and PS traffic
over Ater
Calculate the total number of Ater
channels and the required number of
Ater links
Evaluate the required
number of Gb64K TS per
GPU
Check the capacity limits and the
parenting rules for Abis TSU ports based on BSC configuration
Calculate the needed radio TS for SDCCH, TCH
and PDCH, then nb of TRXs
Check the load and connectivity
based on TC configuration
Evaluate the required number
of GPU/GP boards
Assessment of traffic values forSDCCH, TCH
and PDCH channels
Check the load and conectivity on
DSP and GPU boards of MFS
Unchangedmethods
24 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 dimensioning methods: what’s new in B9 …
Abis dimensioning
AterMux PS dimensioning
GPU / GP dimensioning
Gb dimensioning
QoS feature impact not taken into account
25 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
BSS architecture & dimensioning rules
BSC Abis TSU
Ater TSU
Abis TSU
Ater TSU
Abis TSU
Ater TSU
SGSN
speech
data
A-ter mux
Gb
A
CS
CS+ PS
PS
CS
A-bisAir
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 -EG CH link 1
PS traffic
TRX 3 M -EG CH link 2
M -EG CH link n
BTS
Dynam ic Ab is
a llocation GCH Extra
GCH Basic
GCH Basic
GCH Extra
GCH Bonus
T CH
T CH TRX 1 CS
traffic
TRX n
Assessment ofbasic and bonus Abis nibbles from
TRX and BTS configuration
Calculate the needed extra Abis TS for real traffic on Abis Itf and the number of
needed Abis links
26 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8
Static Abis allocation
B9
Dynamic Abis allocation
Initial phase Optimized phase
� EDGE activation (in case no EDGE in B8)
� Define Max. MCS
� “Configurable” Nb of Extra TS
�Same B8 EDGE approach : cf the example (slide 33 )
�Set equal to a recommended initial value (cf slide 42 )
�Best Effort approach : put as many Extra TS as there are available on the existing Abis links and respect to BSC limit
B8: Not possible to optimize # Extra TS because of static Abis allocation
� NW with GPRS CS3-4 and/or EDGE
� “Fixed” Nb of Extra TS needed corresponding to TRX class (class 2 to 5)
� NW w/o EDGE or with GPRS CS1-2 only
�Not require Extra TS (Nbof Extra TS = 0)
� Assess the initial setting of Extra TS based on counter measurement.
B9: Extra Abis TS can be optimized, thanks to dynamic Abis allocation
B8 to B9 Abis Dimensioning ProcessesOverview
27 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8
Static Abis allocation
B9
Dynamic Abis allocation
Initial phase Optimized phase
� EDGE activation (in case no EDGE in B8)
� Define Max. MCS
� “Configurable” Nb of Extra TS
�Same B8 EDGE approach : cf the example (slide 33 )
�Set equal to a recommended initial value (cf slide 42 )
�Best Effort approach : put as many Extra TS as there are available on the existing Abis links and respect to BSC limit
B8: Not possible to optimize # Extra TS because of static Abis allocation
� NW with GPRS CS3-4 and/or EDGE
� “Fixed” Nb of Extra TS needed corresponding to TRX class (class 2 to 5)
� NW w/o EDGE or with GPRS CS1-2 only
�Not require Extra TS (Nbof Extra TS = 0)
� Assess the initial setting of Extra TS based on counter measurement.
B9: Extra Abis TS can be optimized, thanks to dynamic Abis allocation
B8 to B9 Abis Dimensioning ProcessesOverview
A B8�B9 migration rule exists for the initialization of the B9 parameter containing the Nb of extra Abis TS:
N_EXTRA_ABIS_TS = 2*[(1*Nb-of-TRX-Trans-Pools-Type2)+(2*Nb-of-TRX-Trans-Pools-Type3)+(3*Nb-of-TRXTrans-Pools-Type4)+(4*Nb-of-TRX-Trans-Pools-Type5)] for each sector of the BTS
In other words, N_EXTRA_ABIS_TS, for the BTS in B9, is the sum of NB_EXTRA_ABIS_TS,for each sector of the BTS in B8.
In order to have an iso-functionnality B8����B9 migration it is recommended to configure MAX_GPRS_CSand MAX_EGPRS_MCS on the basis of the actual capability of the cell (depending on the TRX classes set
In the cell)
28 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Design
EDGE BSS Architecture Activities
Step I: Define EDGE Class
- TRX Class in B8
- CS/MCS in B9
Operational
Step II: Design Abis resource
- Static Abis allocation in B8
- Dynamic Abis allocation in B9
Step III: Design BSC area/resource and Parenting board/port
- Less BSC resource consumption expected in B9
Implement new BSC (if needed)
BTS cutover (intra BSC and/or inter BSC cutovers, if needed)
Deploy Secondary Abis link (if needed)
Activate GPRS (CS-3/4) / EDGE
- B8 parameters
- B9 parameters
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase
29 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Step I:� B8: Define TRX Class for each cells
� Choose TRX Class (from class 1 to class 5)
�On how many TRXs are applied each TRX Class
� Example:
� B9: Define Maximum CS and MCS for each cells� TRX Class concept is removed in B9
� Example:
TRX Class Number of TRX Class (per cell ) CriterionClass 5 (Max CS-4 / Max MCS-9) 1 TRX For cells considered as "High " PS trafficClass 2 (Max CS-4 / Max MCS-5) 1 TRX For cells considered as "Medium " PS trafficClass 1 (Max CS-2) 1 TRX For cells considered as "Low " PS traffic
Max CS (per cell ) Max MCS (per cell ) CriterionCS-4 MCS-9 For cells considered as "High " PS trafficCS-3 MCS-6 For cells considered as "Medium " PS trafficCS-2 MCS-4 For cells considered as "Low " PS traffic
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Design (1/3)
30 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Step II:
� B8: Analyse the Abis resource usage which mainly relates the fixed
number of extra Abis TS “statically” mapping for each RTS.
� Based on TRX Class, Number of TRX Class , TRX configuration of the BTS
and Abis network topology (i.e.Chain, Star,or Ring).
� Is “secondary” Abis deployment needed?
� B9: Design the Abis resource availability which can be “dynamically”
allocated for extra Abis TS when needed (supporting PS traffic).
� Based on defined Max. CS and MCS, TRX configuration of the BTS and Abisnetwork topology (i.e.Chain, Star,or Ring).
� Nb of Extra Abis TS to be set at OMC per BTS
� Is “secondary” Abis deployment needed?
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Design (2/3)
31 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Step III:
� B8 & B9: Design BSC resource/area and Parenting board/port
� This step is common for B8 and B9.
� Design of BSC resource/area is usually needed as GPRS(CS-3,CS-4) / EDGE
implementation consumes more BSC capacity even it should be less impact
in B9.
� Parenting board/port to ensure that load is evenly spread among BSCs &
Abis TSUs
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Design (3/3)
32 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Based on Design results, the Operational activities should be performed
as following:
� Implement BSC extensions and/or new BSC(s) (if needed)
� BTS cutover : load balance among BSCs & Abis TSUs
� Deploy Secondary Abis links for some BTSs (if needed)
� Activate GPRS(CS-3,CS-4)/EDGE : modify parameter values
� B8 parameters
– EN_EGPRS
– MAX_GPRS_CS
– MAX_EGPRS_MCS
– Number of TRE for each TRX pool types
� B9 parameters
– EN_EGPRS
– MAX_GPRS_CS
– MAX_EGPRS_MCS
– N_EXTRA_ABIS_TS
(Number of 64K extra Abis TSs in the BTS ,new in B9)
To be set according to defined TRX Class
Configurable by operator !
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Operational
33 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
1 BTS having 3 Cells with TRX configuration FR 2+2+2
CELL #3
CELL #2
CELL #1
BTS Radio TS ConfigurationTS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
FR TRX #1TRX_PREF_MARK = 1
BCCH TCH TCH TCH TCH TCH TCH TCH
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
FR TRX #2TRX_PREF_MARK = 0
SDCCHTCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
FR TRX #1TRX_PREF_MARK = 1
BCCH TCH TCH TCH TCH TCH TCH TCH
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
FR TRX #2TRX_PREF_MARK = 0
SDCCHTCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
FR TRX #1TRX_PREF_MARK = 1
BCCH TCH TCH TCH TCH TCH TCH TCH
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
FR TRX #2TRX_PREF_MARK = 0
SDCCHTCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
TCH /PDCH
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example (1/8)
34 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8 Design:
� Step I: Define EDGE Class
� 1 TRX Class 5 implemented for each cells.
� Step II: Design Abis Resource (Max 32 Abis TS per 1 Abis link)
� Calculation:
– TS0 = 1 TS
– Basic Abis TS = 2 Abis TS (per TRX) * 6 TRX (3 cells) = 12 TS
– RSL/OML Abis TS = 2 TS
* In case of 64K Statistical Multiplexing for 6 RSL/TRX (3 cells) + 1 OML (1 BTS)
– Extra Abis TS = 24 TS
1 RTS of TRX Class 5 requires 4 extra Abis nibble (EGCH link)
Total Extra Abis nibbles = 4 Abis nibbles * 8 RTS (per TRX) * 3 TRX Class 5 (3 cells) = 96 Abis nibbles
So… Total Extra Abis TS = 96 Abis nibbles / 4 Abis nibbles per TS = 24 Abis TS
– Total required Abis TS = 1 (TS0) + 12 (Basic) + 2 (RSL/OML) + 24 (Extra)
= 39 Abis TS Secondary Abis link needed !!!
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example – case I : B8 (2/8)
35 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8 Design (cont’ ):� Step III: Design BSC resource
Check BSC resource consumption by this BTS
� Based on Step II, there are..
– 12 TS used as “Basic” Abis TS
– 24 TS used as “Extra” Abis TS
� So, Number of FR (equivalent) TRXs consuming the BSC capacity can be simulated as following: -
– [12 (basic) + 24 (extra)] / 2 Abis TS equivalent to 1 TRX
= 18 FR eq TRXs
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example – case I : B8 (3/8)
36 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8 Operational:� 2 Abis links needed to be implemented for this BTS
�Modify parameters to activate EDGE TRX class 5
� Cell parameters: -
- EN_EGPRS = Enable
- MAX_EGPRS_MCS = MCS-9 (to define TRX class 5)
- MAX_GPRS_CS = CS-4 (or any)
� BTS parameter: -
- Number of TRX pool type 5 = 1 (to be set for each BTS sector/Cell)
BSC BTS
Primary Abis link
Secondary Abis link
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example – case I : B8 (4/8)
37 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 Design:
� Step I: Define EDGE Class
� Max MCS is MCS-9 to be set for each cells.
*In order to get the same behaviour as in B8 => to check the Architecture impact from B8 to B9
� Step II: Design Abis Resource (Max 32 Abis TS per 1 Abis link)
� Calculation:
– TS0 = 1 TS
–Basic Abis TS = 2 Abis TS (per TRX) * 6 TRX (3 cells) = 12 TS
–RSL/OML Abis TS = 2 TS
* In case of 64K Statistical Multiplexing for 6 RSL/TRX (3 cells) + 1 OML (1 BTS)
–Max required Extra Abis TS = 17 TS
Only TRX #2 supports GPRS/EDGE as TRX_PREF_MARK = 0. So, Max PDCH group size is 7 PDCHs with Max MCS = MCS-9.
In B9 with M-EGCH link, MCS-9 requires 4.49 GCH
7 PDCH x 3 Cells x 4.49 GCH / PDCH = 94.3 GCH = 95 Abis nibbles
7 x 3 (Cells) Basic nibbles + 2 x 3 (Cells) Bonus nibbles = 27 (basic + bonus) nibbles
(2 bonus nibbles / cell : BCCH in TRX#1+ SDCCH in TRX #2)
95 – 27 = 68 Extra Abis nibbles = 17 Extra Abis TS (4 Abis nibbles per TS)
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example – case II : B9 (5/8)
38 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example – case II : B9 (5/8)
B9 Design:
� Step I: Define EDGE Class
� Max MCS is MCS-9 to be set for each cells.
*In order to get the same behaviour as in B8 => to check the Architecture impact from B8 to B9
� Step II: Design Abis Resource (Max 32 Abis TS per 1 Abis link)
� Calculation:
– TS0 = 1 TS
–Basic Abis TS = 2 Abis TS (per TRX) * 6 TRX (3 cells) = 12 TS
–RSL/OML Abis TS = 2 TS
* In case of 64K Statistical Multiplexing for 6 RSL/TRX (3 cells) + 1 OML (1 BTS)
–Max required Extra Abis TS = 17 TS
Only TRX #2 supports GPRS/EDGE as TRX_PREF_MARK = 0. So, Max PDCH group size is 7 PDCHs with Max MCS = MCS-9.
In B9 with M-EGCH link, MCS-9 requires 4.49 GCH
7 PDCH x 3 Cells x 4.49 GCH / PDCH = 94.3 GCH = 95 Abis nibbles
7 x 3 (Cells) Basic nibbles + 2 x 3 (Cells) Bonus nibbles = 27 (basic + bonus) nibbles
(2 bonus nibbles / cell : BCCH in TRX#1+ SDCCH in TRX #2)
95 – 27 = 68 Extra Abis nibbles = 17 Extra Abis TS (4 Abis nibbles per TS)
N.B. The obtained number of Extra Abis TS is the maximum number we’d need all GPRS and/or EDGE TS having the maximum declared (M)CS. It is recommended to check the real MCS distribution calculating a real average #GCH per PDCH � replace 4.49by:
Sum{MCSi_ratio * nb_GCH_MCSi}<4.49
39 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 Design (cont’):
– Max Total required Abis TS = 1 (TS0) + 12 (Basic) + 2 (RSL/OML) + 17 (Extra)
= 32 Abis TS
� Step III: Design BSC resource
Check BSC resource consumption by this BTS
� Based on Step II, there are..
– 12 TS used as “Basic” Abis TS
– Max 17 TS used as “Extra” Abis TS
� So, Max number of (equivalent) FR TRXs consuming the BSC capacity can be
simulated as following: -
– [12 (basic) + Max 17 (extra)] / 2 Abis TS equivalent to 1 TRX
= Max 14.5 FR eq TRXs
Only 1 Abis link enough !!!
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example – case II : B9 (6/8)
40 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 Operational:�Only 1 Abis link needed to be implemented for this BTS
�Modify parameters to activate EDGE MCS-9
� Cell parameters: -
- EN_EGPRS = Enable
- MAX_EGPRS_MCS = MCS-9
- MAX_GPRS_CS = CS-4 (or any)
� BTS parameter: -
- N_EXTRA_ABIS_TS = 17
BSC BTSPrimary Abis link
New parameter in B9
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example – case II : B9 (7/8)
41 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8:
� 2 Abis links needed
� 24 extra TS
� Fixed number of extra TS
configured according to TRX
pool type
� High BSC resource
consumption
� 18 FR eq TRXs
B9:�Only 1 Abis link enough !
� Max 17 extra TS – less extra TS, thanks to M-EGCH statistical multiplexing & Dynamic Abis allocation features in B9.
� Configurable number of extra TS with O&M BTS parameter
N_EXTRA_ABIS_TS = 17
� Low BSC resource Consumption
� Max 14.5 FR eq TRXs
Summary Architecture impact B8 vs. B9 – based on this example:
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : Example – summary (8/8)
42 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8 to B9 Abis Dimensioning ProcessesFrom B8 to B9 initial phase : High level recommendations
Depending on the configuration of the following parameters:
� MAX_GPRS_CS� MAX_EGPRS_MCS� EN_EGPRS� EN_GPRS
The recommended values for N_EXTRA_ABIS_TS parameter are provided in
the following table:
0 or 1 according to bonus nibbles
availability
CS3-CS4 and EN_EGPRS disable
6 CS3-CS4 and EN_EGPRS enable
0CS1-CS2
N_EXTRA_ABIS_TSConfiguration
This setting allows to support 2 MS MCS9 (4+1) in a typical tri-sector BTS having 21 basic nibbles (7 basic per cell) and 6 bonus nibbles:
Needed nibbles = 2MS * 4PDCH * 4,49GCH_MCS9 = 36 nibbles
Needed extra & bonus nibbles = Needed nibbles – basic nibbles = 36 – (2MS * 4PDCH ) = 28 nibbles
Extra nibbles = Needed extra & bonus nibbles – bonus nibbles = 28 – 6 = 22 nibbles � 6 Extra TS
43 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8 to B9 Abis Dimensioning ProcessesB9 Optimised phase : Assess initial setting of Extra Abis TS (1/3)
� B9 Optimised phase: The first step is to assess the current Extra Abis TS
whether it can handle the PS traffic without causing the QoS and
performances degradation.
If not, it will trigger the Abis re-dimensioning process to find the optimal
Extra Abis TS.
� On Abis interface, Abis nibbles unavailability can lead to two different
situations:
� Service unavailability: TBF establishment / reallocation failure due to lack of
enough Abis nibbles available for the establishment of the needed minimum
number of GCH.
� Service degradation: Radio throughput reduction due to the fact that the
number of available Abis nibbles is less than the needed one in order to support
the targeted throughput
In this case, RLC/MAC data blocks that cannot be sent in a given radio block will
be delayed and sent in a future radio block
44 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8 to B9 Abis Dimensioning ProcessesB9 Optimised phase : Assess initial setting of Extra Abis TS (2/3)
Service unavailability detection observing:
� The number of UL / DL TBF establishment failures due to Abis Congestion:
� TBF establishment failures due to lack of Abis resources
– P105i :
Number of DL TBF establishment failures due to a lack of Abis resources.
– P105j :
Number of UL TBF establishment failures due to a lack of Abis resources.
� TBF establishment requests
– P91a+P91b+P91c+P91d+P91e+P91f :
Number of DL TBF establishment requests.
– P62a+P62b+P62c-P438c :
Number of UL TBF establishment requests
%1,0919191919191
105 >+++++ fPePdPcPbPaP
iP%1,0
438626262
105 >−++ cPcPbPaP
jP•OR
45 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B8 to B9 Abis Dimensioning ProcessesB9 Optimised phase : Assess initial setting of Extra Abis TS (3/3)
Service degradation detection
� Up to now we have not succeeded in finding a way to detect Abis
congestion independently from TBF establishment process because:
� The monitoring of extra & bonus nibbles usage, i.e. through:
Minimum number of free Bonus & Extra nibbles at BTS level: P484
can not be used as a criterium for congestion detection (i.e. if P484=0) because
even if all the available resources at extra & bonus level are used, the nibbles in
the zone MAX_PDCH_HIGH_LOAD – MAX_PDCH could be still free (see next slide)!
� The counter providing information about a deficit of GCH resources at cell level
with respect to R_AVERAGE_GPRS and R_AVERAGE_EGPRS (P470) is in restriction
up to B9MR4ed2 (MFS.PATCH.B9_0.RCxx.30CP_00E) � counter behaviour not
yet observed on field).
If no Abis congestion has been detected looking at TBF establishment failure counters,
The only way to check Abis dimensioning is applying the dimensioning methods described in next slides
46 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 Abis Dimensioning methodsFunctional Reminders
MAX_SPDCH_High_Load Zone From MAX_SPDCH_High_Load to MAX_SPDCH
Basic nibbles of cell
Extra+Bonus nibbles of BTS
Priority N°1
Priority N°2
Priority N°3
Transmission Resource Management: Abis allocation priority
Radio Resource Management: Autonomous Packet Resource Allocation
MIN_SPDCH
MAX_SPDCH_HIGH_LOAD
MAX_SPDCH
reserved for PS priority for PS priority for CS reserved for CS
MAX_SPDCH_Limit
47 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 Abis dimensioning methods
Extra&Bonus Method
� PROs� Easy to apply
� CONs� Focused only on PS traffic
� Focused only on « priority 2 » Abis nibbles:
Extra & Bonus nibbles
MCS Method
� PROs� Take into account all types of Abis nibble
(basic, extra, bonus)
� Take into account PS and CS traffic
� CONs� Complex to apply
48 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 Abis Dimensioning ProcessesExtra&Bonus Method
( )
( )
%100438626262
105___%
%100919191919191
105___%
___,%___%__%3600
466__&_
%30,__%1
__&___&_Re
xcPcPbPaP
jPcongAbisTBFUL
xfPePdPcPbPaP
iPcongAbisTBFDL
congAbisTBFULcongAbisTBFDLMaxcongAbisTBF
PTrafficAbisbonusextraMeasured
CongAbisTBFMin
TrafficAbisbonusextraMeasuredTrafficAbisBonusextraquired
−++=
+++++=
=
=
−=
Required_extra&Bonus_Abis_Traffic
Number of extra Abis TS
Number of bonus nibbles
4÷−Number of extra Abis nibbles
ERLANG C
Number of extra&bonus Abis nibbles
GoS= Grade Of Service
Withquantile=95%
49 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 Abis Dimensioning MethodMCS Method
MCSx
CS
Nb Basic nibbles
Min_SPDCH
Max_SPDCH
Max_SPDCH_High_Load
CS and PS traffic data (from counters)
Customer’s option
Number of Extra TS needed
Average TBF Throughput
MCS Method
MCS Method is based on
a traffic law (Knapsack model)
allowing to dimension resources
shared by different services
(i.e. CS and PS)
It is implemented thanks to 2G
Traffic tool
50 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
MCS Method high level description
GoS reached in all cell for all services?
Calculate GoSof all services in each cell
Compare calculatedGoSsto required ones
Nb extra and bonus = 0
Nb extra and bonus
Nb extra andbonus ++
True
False
How ?
Knapsack model
Traffic_service_1
Resources_service_2
capacityTraffic_service_2
Resources_service_1
Stochastic method allowing to find a distribution f(n, prob(n))
in a multiserviceenvironment, being n the number of used resources
using …
−4÷ Nb of bonus nibbles
Nb of extra Abis nibbles
Nb of extra Abis TS
51 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Abis dimensioning global method
Extra & Bonus method
MCS method
For ALL BTS
Extra nibbles
Needed ?
Extra nibbles
Needed ?
Select minimumm between theoretically missing resources (according to the method given in slide 37 ) and the minimum
between extra & bonus / MCS method results
yes
yes
No
NoFor each BTS
Needing additional
Resources according
to Extra & Bonus method
/4Round up
N_EXTRA_ABIS_TS
N_EXTRA_ABIS_TS=0
52 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Abis dimensioning global methodAn example
Having 1 BTS with:
� Nb of cells: 2
� Traffic info: CS3-CS4 activated – EDGE disable
� Current NB_EXTRA_ABIS_TS = 0
� Current number of used ABIS TS at BTS level over the used ABIS TS at ABIS link level: 18
over 19
� Max_PDCH: 13, 6
� Number of configured bonus nibbles: 8
� Measured Max Extra & Bonus nibbles traffic = 7,5 Erl
� Recommended NB_EXTRA_ABIS_TS = 2
Extra & bonus method
Extra & bonus
traffic (7,5Erl)
Quantile (95%)
5 extra nibbles
MCS method
Min
TheoreticallyMaximum need
method
6 extra nibbles
Basic (19)
Bonus (8)
5 extra nibbles
5 extra nibbles
…
See slide 37
53 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Why is it needed to compare with the theoretically maximum need ?WARNING
During Abis dimensioning interface assessment on some B9 networks (B9MR1 and
B9MR4), abnormal value of indicators managing GCHs were observed. Two explicit
examples (a lot of other examples exist) of that are:
BTS 1
� Nb of cells: 1 (with MAX_PDCH = 6)
� Traffic info: CS3-CS4 deactivated – EDGE disable
� 4 Bonus nibbles available
� The counter p100d (maximum number of GCH per cell) for the related cell reaches the
value 10. The theoretical maximum should be MAX_PDCH * 1 = 6.
BTS 2
� Nb of cells: 1 (with MAX_PDCH = 6)
� Traffic info: CS3-CS4 activated – EDGE disable
� 6 Bonus nibbles available
� The counter p100d (maximum number of GCH per cell) for the related cell is always
equal to the value 12. The theoretical maximum should be MAX_PDCH * 1,64 = 10.
Is this a counter issue or is this due to a bad ressource management ? UNDER INVESTIGATION by TD
54 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 dimensioning methods: what’s new in B9 …
Abis dimensioning
AterMux PS dimensioning
GPU / GP dimensioning
Gb dimensioning
•QoS feature impact not taken into account
55 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
BSS architecture & dimensioning rules
BSC Abis TSU
Ater TSU
Abis TSU
Ater TSU
Abis TSU
Ater TSU
SGSN
speech
data
A-ter mux
Gb
A
CS
CS+ PS
PS
CS
A-bisAir
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 -EG CH link 1
PS traffic
TRX 3 M -EG CH link 2
M -EG CH link n
BTS
Dynam ic Ab is
a llocation GCH Extra
GCH Basic
GCH Basic
GCH Extra
GCH Bonus
T CH
T CH TRX 1 CS
traffic
TRX n
Assessment ofPS traffic over
Ater
Calculate the total number of Ater
channels and the required number of
Ater links Evaluate the required number of GPU/GP
boards
56 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
When GPU & AterMux PS dimensioning assessment is needed
A GPU & AterMux PS dimensioning assessment is triggered by:
� Planned migration: the dimensioning must be done before and after the
migration
� Feature activation: the activation of features causing an increase of
needed GCH resources (i.e. EDGE activation or MAX_GPRS_CS set to
CS3/CS4) could result in Ater Congestion/GPU limitation observation
� Traffic evolution causing:
� AterMux interface underdimensioning
� GPU limitation
– Power Limitation (at PPC/DSP level)
– Memory limitation (at PPC/DSP level)
57 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Indicators for AterMux interface underdimensioningcontrol
The following indicators must be monitored in order to identify
AterMux interface underdimensioning situations:
� At traffic resources (GCH) level:
�High Ater usage implying resource usage reduction: P383b
�Resource unavailability: P383a
�UL / DL TBF establishment failure due to Ater Congestion: P105h /
P105g
� At signalling resources (GSL) level:
� Load monitoring in terms of bandwidth: P41, P42
� Load monitoring in terms of number of treated messages per
second: see next slides
58 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Ater Congestion detection (1/2)
� Traffic congestion
� GSL congestion (at bandwidth level)
Being:
� Measured_GSL_Traffic equal to:
� GSL_link_band_Capacity = 0,42 Erl
P383a/3600 > 0,1%
Measured_GSL_Traffic/GSL_link_band_capacity > 80%
3600
1
8/]/64[
)42,41(
3600
1
__
_
3600
___ ×=×=skbit
PPMax
bandwithLinkGSL
volumedatatimebusyresourcesGSL
P383b/3600 > 30%
59 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
� GSL congestion (in terms of number of messages/sec at GPU/GP level)
Where:
Number of GSL messages/sec per GPU is calculated as a function of PS traffic (UL and DL TBF establishment
requests) and of the number of cells mapped to the GPU/GP. Calculation details are provided in next slides
GSL_link_Max_capacity per GPU is defined as:
K_GSL * (1000ms/GSL_round_trip_delay) * number of configured GSL links per GPU/GP
if GSL_round_trip_delay<500ms
K_GSL * (1000ms/GSL_round_trip_delay) * (1/2) * number of configured GSL links per GPU/GP
if GSL_round_trip_delay 500ms
(being K_GSL the maximum number of outstanding I frames on a GSL link)
N.B. In B9MR4 the allowed range for K_GSL parameter has been enlarged
in order to cope with satellite need: from a range of [0,16] to a range of [0,32])
(Number of GSL messages/sec per GPU)/ GSL_link_Max_capacity per GPU > 75%
Ater Congestion detection (2/2)
≥
Terrestriallinks
Satellitelinks
Referecne GSL_round_trip_delay = 500ms
reference GSL_round_trip_delay = 60ms
BSC
GPU
K_GSL
GSL messages buffer
GSL_round_trip_delay
A message is kept in the buffer during GSL_round_trip_delay
Due to FR 3BKA20FBR202481
60 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Once a potential under-dimensioning has been detected on AterMux PS
interface, AterMux PS dimensioning assessment method must be run at:
I. BSC level (doing the hypothesis of a well balanced traffic distribution
among the GPU/GP boards connected to the BSC)
AND
II. GPU/GP level (in case of multi-GPU configuration and if no additional
GPU/GP resource adding found through the method application at BSC
level) in order to handle congestion situations due to unbalanced
traffic/cell distribution/mapping on GPU/GP boards connected to the
BSC. In this case:a. a reshuffling operation should be done, before adding GPU/GP/Atermux resources, if needed, in order to be
sure about the congestion root cause
b. If the reshuffling does not solve the congestion situation, additional resources, according to the
dimensioning method result, should be added
N.B. If, running the dimensioning assessment method, more than 1 GPU/GP board are identified as under-
dimensioned (i.e. they are not able to handle the required traffic) the adding of GPU/GP boards will be
done in an iterative way (1 GPU/GP at once) monitoring the consequent impact on the AterMux PS
interface.
AterMux PS interface assessment method (1/3)
61 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
AterMux PS interface assessment method (2/3)
AterMux dimensioning
Assessment for GSL traffic
AterMux dimensioning
Assessment for user traffic
GPU/GP dimensioning
Assessment
# Needed GCH
max
# AterMux PS per GPU/GP
2 (for security reason)
# Needed GSL links
# GPU/GP# GSL links
(at least 2 per GPU/GP)
÷Aterlink
GCH_Capacity
CS TCH PS GCH Full 116 Null 0 7/8 100 1/8 16 ¾ 84 ¼ 32 ½ 56 ½ 60 ¼ 28 ¾ 88
Null 0 Full 116
# AterMux PS
÷# AterMux PS per GPU
(user traffic)
÷# AterMux PS per GPU
(GSL traffic)
Method applied at BSC level
62 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
AterMux PS interface assessment method (3/3)
AterMux dimensioning
Assessment for GSL traffic
AterMux dimensioning
Assessment for user traffic
GPU/GP dimensioning
Assessment
# Needed GCH
max
# AterMux PS per GPU/GP
# AterMux PS per GPU (estimated at BSC level)
# Needed GSL links
# GSL links(at least 2 per GPU/GP)
÷
AterlinkGCH_Capacity
# AterMux PS
÷# AterMux PS per GPU
(user traffic)
÷# AterMux PS per GPU
(GSL traffic)
Method applied at GPU/GP level
If #GPU/GP=1
2 max
÷# AterMux PS per GPU
(user traffic)
÷# AterMux PS per GPU
(GSL traffic)
# AterMux PS at BSC level
# Needed GSL links at BSC level
New #GPU/GP at BSC level
# AterMux PS per GPU/GP
If #GPU/GP>1 then 1 GPU/GP must be added and the
#AterMux PS per GPU/GP (for all GPU/GPs)
must be estimated as:
63 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
AterMux PS assessment method – Some Examples (1/3)
Example 1:
� BSC level (current #GPU/GP=2 w/ 2 AterMux links per GPU/GP):� #Needed GCH = 500
� #Needed GPU/GP = 2
� #AterMux PS per BSC = 500/112 = 5
� #AterMux PS per GPU/GP = 5 / 2 = 3
� GPU/GP level� GPU1
– #Needed GCH GPU1 = 200– #Needed GPU/GP = 1– #AterMux PS per GPU/GP = Max (200 / 112, 3) = 3
� GPU2– #Needed GCH GPU2 = 300– #Needed GPU/GP = 1– #AterMux PS per GPU/GP = Max ( 300 / 112, 3) = 3
1) Reshuffle operation is done in order to try to balance traffic between the
two GPUs
2) Add 1 AterMux PS links on both GPUs.
64 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
AterMux PS assessment method – Some Examples (2/3)
Example 2:
� BSC level (current #GPU/GP=2 w/ 2 AterMux links per GPU/GP):� #Needed GCH = 400
� #Needed GPU/GP = 2
� #AterMux PS per BSC = 400/112 = 4
� #AterMux PS per GPU/GP = 4 / 2 = 2
� GPU/GP level� GPU1
– #Needed GCH GPU1 = 160– #Needed GPU/GP = 1– #AterMux PS per GPU/GP = Max (160 / 112, 2) = 2
� GPU2– #Needed GCH GPU2 = 240– #Needed GPU/GP = 1– #AterMux PS per GPU/GP = Max (240 / 112, 2) = 3
1) Reshuffle operation is done in order to try to balance traffic between the
two GPUs
2) If the reshuffle operation has not the wanted effect, add 1 AterMux PS to
GPU2.
65 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
AterMux PS assessment method – Some Examples (3/3) Example 3:
� BSC level (current #GPU/GP=2 w/ 2 AterMux links per GPU/GP):� #Needed GCH = 500
� #Needed GPU/GP = 2
� #AterMux PS per BSC = 500 / 112 = 5
� #AterMux PS per GPU/GP = 5 / 2 = 3
� GPU/GP level� GPU1
– #Needed GCH GPU1 = 200– #Needed GPU/GP = 1– #AterMux PS per GPU/GP = Max (200 / 112, 3) = 3
� GPU2– #Needed GCH GPU2 = 300– #Needed GPU/GP = 2
1) Reshuffle operation is done in order to try to balance traffic between the
two GPUs
2) If Reshuffle has not the wanted effect: � #Needed GCH at BSC = 500
� #Needed GPU/GP = 3� #AterMux PS per BSC = 500 / 112 = 5
� #AterMux PS per GPU/GP = 5 / 3 = 2
66 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
AterMux dimensioning assessment for GSL traffic
AterMux dimensioning
Assessment for GSL traffic
Assessment based
on GSL bandwidth
Assessment based
on the number of
GSL messages per second
max2
(for security reason)
# GSL links
If GSL load > 80% ( slide 58) than add 1 GSL link
on the GPU/GP on which the GSL overload is observed
N.B. In case of GSL under-dimensioning due to a limitation in terms of number of GSL
Messages per second treatement capability, an alternative solution to GSL link adding
is the tuning of K_GSL parameter (WARNING: no field feedback available on this practise)
This method was applied and validated in case of Satellite Ater links
Here an extension to Terrestrial links is presented but no field feedback
exists on that
If aterMux dimensioning assessment is focused only on GSL (because of a clear GSL
congestion observed without any major problem at traffic level) it is recommended to run this method at GPU/GP level
67 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GSL Assessment based on the number of GSL messages per second
How to estimate the number of GSL messages per second (I)
1) Msg on GSL due to RAE4 mechanism 0.3 Msg/sec x Nb_cell
2) Msg on GSL due to PS traffic:
2.1) Msg on GSL due to PS/CS paging 1 x (Nb_PS_paging/sec+ Nb_CS_paging/sec)
2.2) Msg on GSL due to PS data traffic (TBF requests):
� TBF (UL & DL) corresponding to RA update 1.7 x Nb_TBF_Sig_req/sec
� UL TBF without sig on GSL 0 x Nb_UL_TBF_req_noGSL/sec
(eg. ACK of FTP DL transfer)
� TBF (UL & DL) corresponding to PS data (3 cases)
� Low GSL usage (eg. Ping 5 sec) 2.5
� Medium GSL usage 3.5 x Nb_TBF_Data_req/sec
� High GSL usage (worst case) 5
+
Nb GSL messages/sec
B9 major impact
68 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Nb_cell:
number of cell (at BSC level or managed by the GPU, depending if the method is applied at BSC or GPU level)
Nb_PS_paging:
number of processed PS paging requests/sec is measured by P391a/3600
Nb_CS_paging:
number of processed CS paging requests/sec is measured by P391b/3600
Nb_UL_TBF_req_noGSL:
number of UL TBF requests/sec which will not generate any message on the GSL is counted by P62b.
Nb_UL_TBF_req:
the total number of UL TBF requests/sec (P62a+b+c-P438c/3600)
Nb_DL_TBF_req:
the total number of DL TBF requests/sec (P91a+b+c+d+e+f/3600)
Nb_TBF_Sig_req:
the number of TBF (UL and DL)/sec which correspond to signalling traffic. The part of DL TBF signalling requests is estimated with %_DL_TBF_Sig_req = P160 / Nb_DL_TBF_succ.
where P160 = NB_DL_TBF_1_succ and Nb_DL_TBF_succ = P90a+b+c+d+e+f
So Nb_TBF_Sig_req = %_DL_TBF_Sig_req x (Nb_UL_TBF_req-Nb_UL_TBF_req_noGSL + Nb_DL_TBF_req)
Nb_TBF_Data_req:
the number of TBF (UL and DL)/sec which correspond to data traffic.
Nb_TBF_Data_req = Nb_UL_TBF_req + Nb_DL_TBF_req - Nb_UL_TBF_req_noGSL - Nb_TBF_Sig_req
GSL Assessment based on the number of GSL messages per second
How to estimate the number of GSL messages per second (II)
69 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GSL Assessment based on the number of GSL messages per second
Some additional hints
� The assessment must be based on traffic data related to a period during which QoS is acceptable
(success rate greater than 80%). See next slide for details.
� the GSL usage condition can be defined through the following table:
3.52.5Low
53.5HighAvailable
GCH
LowHigh
PS traffic
(TBF req)Nb of Msg on GSL
If #TBF req / sec < 20 TBF/sec
If ater congestion observed
The values provided in the table above are relibale if T_GCH_INACTIVITY=3sec and T_GCH_INACTIVITY_LAST=20sec
(default setting). Otherwise (I.e. T_GCH_INACTIVITY=2sec and T_GCH_INACTIVITY_LAST=6sec GSL load will be greater
due to the consequent increase of deallocation / allocation messages).
70 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GSL Assessment based on the number of GSL messages per second
Global assessment method (run at BSC or GPU/GP level)
Retrieve indicators and
Cells ���� GPUs mapping
(if method applied to 1 GPU/GP)
GSL traffic condition
Calculation
# GSL links
#GSL msgs/sec calculation
•(*) QoS evaluation to be done
•by QoS expert
÷ 75% x GSL_Link_Max_Capacity (see slide 59 for computation )
QoS acceptable ?*(i.e. UL TBF estab success rate >80%)
Yes
Retrieve data on a different
Period or on an updated
configuration with better QoS*
� Select hours with acceptable QoS *
(i.e. for 90% of cells)
� Compare PS traffic in the selected hours
with traffic observed on a « similar » BSC
(reference BSC)
� Estimate PS traffic at busy hours on the basis
of the reference BSC (through a simple proportion
based on the respective number of cells)
NoOR
START
PS
Traffic data
CHECK
Calculation
If the method is applied at BSC level, the
total capacity (for all GPU/GP) must be kept
71 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
AterMux PS interface dimensioning assessment for user traffic
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 in case of no congestion / ater usage reduction
present)
ERLANG CCounters
Required_GCH_Traffic Needed
GCHs
N.B. The dimensioning assessement of AterMux interface can be done
both at BSC and at GPU/GP level (i.e. in case of multi-GP(U) configuration)
Withquantile=99,9%
AterMux dimensioning
Assessment for user traffic
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
72 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Required_GCH_Traffic estimation
Method 1: driven by the estimation of the
required traffic as a function of the
measured GCH traffic and of Ater/GPU
congestion
Method 2: driven by the estimation of the
required traffic as a function of the
measured GCH and radio PS traffic
Required_GCH_Traffic
estimation
P100cP383a, P384,
P201, P202, P402
Required_GCH_Traffic
Required_GCH_Traffic
estimation
P100c P38b
Required_GCH_Traffic
GCH traffic GCH traffic PDCH trafficCongestion
Two different methods can be used for the estimation of the
Required_GCH_traffic quantity:
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
73 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
0
50
100
150
200
250
300
350
400
06/0
3/20
07 :
00h 04h
08h
12h
16h
20h
07/0
3/20
07 :
00h 04h
08h
12h
16h
20h
08/0
3/20
07 :
00h 04h
08h
12h
16h
20h
09/0
3/20
07 :
00h 04h
08h
12h
16h
20h
10/0
3/20
07 :
00h 04h
08h
12h
16h
20h
11/0
3/20
07 :
00h 04h
08h
12h
16h
20h
12/0
3/20
07 :
00h 04h
08h
12h
16h
20h
13/0
3/20
07 :
00h 04h
08h
12h
16h
20h
14/0
3/20
07 :
00h 04h
08h
12h
16h
20h
15/0
3/20
07 :
00h 04h
08h
12h
16h
20h
Required_GCH_Traffic estimationMethod 1
Measured_GCH_trafficRequired_GCH
_traffic
%)30;min(1
____Re
Congestion
TrafficGCHMeasuredTrafficGCHquired
−=
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
74 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
0
50
100
150
200
250
300
350
400
06/0
3/20
07 :
00h 04h
08h
12h
16h
20h
07/0
3/20
07 :
00h 04h
08h
12h
16h
20h
08/0
3/20
07 :
00h 04h
08h
12h
16h
20h
09/0
3/20
07 :
00h 04h
08h
12h
16h
20h
10/0
3/20
07 :
00h 04h
08h
12h
16h
20h
11/0
3/20
07 :
00h 04h
08h
12h
16h
20h
12/0
3/20
07 :
00h 04h
08h
12h
16h
20h
13/0
3/20
07 :
00h 04h
08h
12h
16h
20h
14/0
3/20
07 :
00h 04h
08h
12h
16h
20h
15/0
3/20
07 :
00h 04h
08h
12h
16h
20h
Required_GCH_Traffic estimationMethod 1
%)30;min(1
____Re
Congestion
TrafficGCHMeasuredTrafficGCHquired
−=
Measured_GCH_trafficRequired_GCH
_traffic
Since Method 1 is reliable if congestion is less than 30% and it does not take into
account High Ater usage condition, a complementary method, Method 2, has been defined
{ }{ }
3600
402_%
;3600
)202,201(_%
;3600
384_%
;3600
383_%
_,%_,%_,%_%
_,_3600
100__
PoverloadCPU
PPMaxloadDSP
PCongDSP
aPCongAter
overloadCPUloadDSPCongDSPCongAterMax
LimitationGPUCongestionAterMaxCongestion
cPTrafficGCHMeasured
=
=
=
=
==
=
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
75 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
y = 5,3905x + 21,057
0
112
224
336
448
0 10 20 30 40 50 60 70 80
Required_GCH_Traffic estimationMethod 2
METHOD 2:
Measured PDCH traffic
Measured
GCH trafficResourcessaturation
Required_GCH_Traffic
Measured GCH traffic =
Function_of(PDCH traffic, traffic profile, EGPRS penetration, CS3/CS4 activation, Ater & Abis congestion, high ater usage, available resources, parameter configuration (i.e. MAX_GPRS_CS, MAX_EGPRS_MCS,
T_GCH_INACTIVITY_LAST, EN_FAST_INITIAL_GPRS_ACCESS,EN_EGPRS, etc…))
Required_GCH_traffic has a quasi-linear relashionhip with the PDCH traffic (observed on several networks)
if no congestion nor strong GCH usage reduction due to High Ater usage present
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
76 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
y = 5,3905x + 21,057
0
112
224
336
448
560
0 10 20 30 40 50 60 70 80
An example (1/3)
Measured
GCH traffic
Measured PDCH traffic
N.B. If the PDCH traffic reaches values around 70erl (as previously observed) the related
estimated GCH traffic will require the adding of a 5th link
Following the4th link adding
ERLANG C
Needed_GCH
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
77 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
y = 5,3905x + 21,057
0
112
224
336
448
0 10 20 30 40 50 60 70 80
gch traffic
Pdch traffic
4 links: from12/03 to 27/03
4 links: From08/03 to 11/03
3 links
Abnormal resource management: in the meantime UL TBF Establishment Failure due to BSS Fail equal to 25% …
An example (2/3) Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
78 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
y = 5,3905x + 21,057
0
112
224
336
448
0 10 20 30 40 50 60 70 80 90
gch traffic
Pdch traffic
4 links:• 16 more cells (EDGE/CS3/CS4 activated on 3 cells over 16)
• EN_FAST_INITIAL_GPRS_ACCESS enabled
An example (3/3)
EN_FAST_INITIAL_GPRS_ACCESS = enable represented a workaround for this
abnormal resource management (see slide 112 for related recommandations)
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
79 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Required_GCH_Traffic estimationEGDE, CS3-CS4 activation
With the activation of EDGE and/or the use of GPRS higher coding schemes
(CS3/CS4) the consumption of AterMux transmission resources (GCH) per radio
resource (PDCH) increase.
The increase factor will be a function of:
� the transition type
� the target service penetration (i.e. %EDGE with respect to GPRS)
� the traffic profile
�The following transition types (a, b, c, d, e) must be taken into account:
CS1/CS2
CS3/CS4CS3/CS4
&
EDGEEDGE
a
b
c
d
e
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
80 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Increase factor estimation
The increase factor can be estimated in the following way:
Does a
(set of) reference BSC(s)
Exist ?
Increase_factor =
increase_factor(reference BSCs)
Dimensioning assessment for
Fine tuning
Increase_factor estimated on the basis
of the Avg_target_nb_GCH_per_PDCH
(depending on target service penetration)
Update reference BSCs set
Yes
No
Execute transition
Increase_factor = avg_target_nb_GCH_per_PDCH final / avg_target_nb_GCH_per_PDCH initial
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
81 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Increase_Factor estimated on the basis of the target
Avg_target_nb_GCH_per_PDCH
Being the two following quantities about service penetration known:
% of Radio Resources (PDCH) supporting at least one TBF established in EGPRS mode on
a cell with MAX_EGPRS = MCSx � %_PDCH_EGPRS
% of Radio Resources (PDCH) supporting only TBF established in GPRS mode on a cell
with MAX_GPRS = Csy ���� %_ PDCH_GPRS
[(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS
*1,64)]/ 1,64d
(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*
1,64)/(%_PDCH_EGPRS*4,49)+(%_PDCH_
GPRS*1)
e
[(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS
*1,64)]/1a
[1,64]/1b
[(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS
*1)]/1c
Increase_FactorTransition type
Avg_target_nb_GCH_per_PDCH =
(%_PDCH_EGPRS * nb_GCH_per_PDCH_MCSx) +
(%_PDCH_GPRS*nb_GCH_per_PDCH_Csy)
N.B. If no specific information on service penetration,
%_PDCH_EGPRS=30%
CS1/CS2
CS3/CS4CS3/CS4
&
EDGE
EDGE
a
b
c
d
e
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
82 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Estimated Increase_Factor use
Before EDGE/CS3/CS4
After EDGE/CS3/CS4
Y=a2x + b2
Y=a1x + b1
a2= a1 * Increase_Factor and b2 = b1 (approximation !)
PDCH traffic
GCH traffic
Method 1
Method 2
Required_GCH_traffic new = Required_GCH_traffic current * Increase_Factor
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation Increase Factor Required_GCH_traffic
83 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
y = 5,3905x + 21,057
y = 1,9111x + 20,368
0
112
224
336
448
0 10 20 30 40 50 60 70 80
Estimated Increase_Factor use
Example 1 (CS3-CS4 & EDGE activation)
Estimated (a posteriori) increase factor = (66% * 1,64) + (34% * 4,49) = 2,6 Being PDCH_GPRS=66% and PDCH_EGPRS=34%
« Observed » increase factor = 5,309 / 1,9111 = 2,8
This difference can be explained by the fact that:
� the estimated value is based on average PDCH_GPRS/PDCH_EGPRS values
� the number of established_GCH for a given number of PDCH X is actually the rounded up value of (X*avg_target_nb_GCH_per_PDCH)
� the final and initial trends are estimated trends
PDCH traffic
GCH traffic
CS1-CS2
EDGE / CS3-CS4
%_PDCH_EGPRS= P38c/P38b%_PDCH_GPRS=(P38b-P38c)/P38b
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
84 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
y = 1,798x + 7,6258
y = 2,9487x + 7,6258
0
56
112
168
224
0 5 10 15 20 25 30 35
Estimated Increase_Factor use
Example 2 (CS3-CS4 activation) (I)
Being the increase_factor for this kind of transition (b) equal to 1,64 (cf.
previous slide):
2nd PS AterMux link adding recommendedCurrent AterMux PS
Configuration = 2 x 50% AterMux
ERLANG CNeeded_GCH
Forecasted trend
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
85 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
y = 1,798x + 7,6258
y = 2,9487x + 7,6258
0
56
112
168
224
0 5 10 15 20 25 30 35
Estimated Increase_Factor use
Example 2 (CS3-CS4 activation) (II)
PDCH traffic
GCH traffic
CS1-CS2
CS3-CS4
� The forecasted trend is very close to the observed one after CS3-CS4 activation
� Additional AterMux PS resources are required (as previously recommended)
After CS3-CS4 Activation on 43 over 52 cells:
BSC
level
Forecasted trend
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
86 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Required_GCH_Traffic estimation High level recommendation
Taking into account the method described in previous slides, the following high level recommandations are provided in order to anticipate EDGE / CS3-CS4 activation:
� CS1-CS2 ���� CS3-CS4 and EN_EGPRS=disabled� Recommended number of PS AterMux = round up [(maximum_number_of_GCH * 1,64)/112]
� CS1-CS2 ���� CS3-CS4 and EN_EGPRS=enable (MAX_EGPRS_MCS=9)� Recommended number of PS AterMux = round up [(maximum_number_of_GCH * 3)/112]
� CS3-CS4 ���� CS3-CS4 and EN_EGPRS=enable (MAX_EGPRS_MCS=9)� Recommended number of PS AterMux = round up [[(maximum_number_of_GCH * 3)/1,64]/112]
maximum_number_of_GCH represents the maximum observed value of P100b (in B8) or P100f (in B9). If P100b /
P100f counter value is not available maximum_number_of_GCH=112 (capacity of 1 PS link)
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
87 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Required_GCH_traffic estimationBTS moving
BTSTRX
BSC
BTSTRX
BTSTRX
BTS Moving
Cell Zone relatedTo BTS to move
+
Required_GCH_traffic
Cell Zone relatedTo BSC before BTS moving
GCH
traffic
Cell Zone relatedTo BSC before BTS moving
PDCH contribution due to Cell Zone
Related to BTS to move
PDCH
traffic
Method 1 Method 2
Required_GCH_traffic
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
88 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
y = 1,9907x + 13,44
y = 1,8171x + 8,2315
y = 5,1084x + 12,146
y = 5,7292x + 10,705
0
112
224
336
448
560
0 20 40 60 80 100 120
pdch usage
gch
usag
e
Karl-D: no edge with 2 links
Karl-D: edge activated with 2 links
Karl-D: edge activated with 4 links
karl-C: no edge
Karl-C contrib
Karl_D+Karl_C (6 links w/ 2 GPU)
Karl-D+Karl-C trend
Required_GCH_traffic estimation
An example (I)
In the following graph the evolution of the relashionship between GCH traffic and PDCH
traffic in a BSC, following the activation of EDGE and the moving of some BTS, is put in
evidence:
(3) Cell Zone relatedTo BSC before BTS moving
Cell Zone relatedTo BTS to move In this example:
� « BSC before BTS moving » is called Karl-D� « Cell zone related to BTS to move » is called Karl-C� (xx) gives indication about operation sequence
Estimated final required_GCH_Traffic before the BTS moving
Why is a resource saturation observed even if the number of
AterMux links is the one recommended looking at BSC
traffic level ?
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
(1)
(1’)
(2)
(3)
(4),(2’)
89 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
0
112
224
336
0 10 20 30 40 50 60 70
GPU 1_10
y = 5,7216x + 6,3132
0
112
224
336
0 5 10 15 20 25 30 35 40
Required_GCH_traffic estimation
An example (II)
In case of Multi-GPU
Configuration, even if the total
Number of aterMux links at
BSC level would be enough for
the Required GCH traffic, if the
Traffic is not balanced between
The two GPUs, additional link(s)
Per GPU could be needed…
1 Additional AterMux link
Needed
GPU 1
(3 aterMux links config)
GPU 2
(3 aterMux links config)
Feature
activation
Traffic
evolution
Stable
Network
Required_GCH_Traffic estimation
90 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 dimensioning methods: what’s new in B9 …
Abis dimensioning
AterMux PS dimensioning
GPU / GP dimensioning
Gb dimensioning
•QoS feature impact not taken into account
91 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU Architecture reminder
PPC
DSP
Packet Management Unit (PMU):•PDCH management•PS Paging management•Gb stack management
Packet Transfer Unit (PTU):• RLC/MAC layer management
GPU/GP board
BSC
BTSMS
SGSN
92 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Indicators for GPU/GP limitation control
Power Limitation Memory Limitation Power Limitation Memory Limitation
Dimensioning indicators
P76a P77a
=> P402 (thr )
P392aP392b
P201 (thr_1 )P202 (thr_2 )
P384
QoS indicators
(TBF establ)
P105e P105f
UL TBF estab BSS Failure
P203P204
P105cP105d
GPU limitation
PMU PTUPPC/CPU DSP
MFS parameters:Thr = PMU_CPU_Overload (Default=95%)Thr_1= DSP_Load_Thr_1 (Default=85%)Thr_2= DSP_Load_Thr_2 (Default=95%)
In Alc_Mono_GPRS_Telecom RNO report
CPU Cong BSS Fail DSP Load DSP Cong
B9 only
93 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU/GP limitation detection
GPU limitation
� Power limitation
� Memory limitation
Max(P201,P202)/3600 > 0,1%
UL TBF establishment failure rate due to BSS > 3% P392b = 1000 (B9MR1 & B9MR4 for
legacy MFS)P392b = 4000 (B9MR4 for Mx MFS)
AND
P384/3600 > 0,1%
P402/3600 > 0,1%
This kind of limitation should be no more observable starting from
B9MR1ed6QD2
B9 only
PMU CPU load
DSP CPU load
GPU and P76a > 40% in B8
In case of B8 � B9 migration
OR
94 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU/GP dimensioning method
Being:
� GPU_GCH_Capacity the maximum number of GCHs that the GPU can handle,
� Needed GCHs the number of GCH resources to be handled (for the computation of this
quantity refer to slides dedicated to aterMux dimensioning )
� GPU_for_Ms_context_handling a quantity equal to 1 if a GPU memory limitation due to a
too big number of MS contexts is observed (issue no more observed from B9MR1ed6QD2) and no additional GPU/GP boards needed because of GPU GCH capacity limitation
� GPU_For_Power_Limitation a quantity equal to 1 if a GPU power limitation is observed,
no additional GPU/GP boards needed because of GPU GCH capacity limitation and
GPU_for_Ms_context_handling equal to 0.
Number of GPU
GPU_GCH_Capacity
÷
GPU_for_MS_context_handling (=0/1)
Workaround on issue no more observed fromB9MR1ed6QD2
GPU/GP dimensioning
Assessment
Needed
GCHs +GPU_for_Power_Limitation (=0/1)
+
95 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU/GP dimensioning method
Being:
� GPU_GCH_Capacity the maximum number of GCHs that the GPU can handle,
� Needed GCHs the number of GCH resources to be handled (for the computation of this
quantity refer to slides dedicated to aterMux dimensioning )
� GPU_for_Ms_context_handling a quantity equal to 1 if a GPU memory limitation due to a
too big number of MS contexts is observed (issue no more observed from B9MR1ed6QD2), no additional GPU/GP boards needed because of GPU GCH capacity limitation
� GPU_For_Power_Limitation a quantity equal to 1 if a GPU power limitation is observed,
no additional GPU/GP boards needed because of GPU GCH capacity limitation and
GPU_for_Ms_context_handling equal to 0.
Number of GPU
GPU_GCH_Capacity
÷
GPU_for_MS_context_handling (=0/1)
Workaround on issue no more observed fromB9MR1ed6QD2
GPU/GP dimensioning
Assessment
Needed
GCHs +GPU_for_Power_Limitation (=0/1)
+
If additional GPU/GP resources are needed, the following
operational recommandations apply:
1. If the assessment has been done at BSC level, the required additional resources will be added in one shot operation
2. If the assessment has been done at GPU/GP level, the adding of additional
GPU/GP boards, for a given BSC, will be done in an iterative way (1 GPU/GP at once),
monitoring the consequent impact on the AterMux PS and GPU/GP dimensioning
96 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU_GCH_Capacity calculation (1/3)
� In order to find the GPU_GCH_Capacity, the following limitations must be
taken into account:
� Maximum number of GCH per GPU is:
– B9MR1: 480 – N_ATER_TS_MARGIN_GPU*4
– B9MR4:
– 480 – N_ATER_TS_MARGIN_GPU*4 (for legacy MFS)
– 1560 – N_ATER_TS_MARGIN_GPU*4 (for Mx MFS)
� Maximum number of PDCH per GPU is dynamic depending on the used coding
schemes (for details refer to Architecture section describing GPU/GP capacity in
terms of PDCH)
� Maximum number of GCH is also dynamic because the number of GCH per PDCH
depends on the used coding scheme. Therefore the maximum number of GCHs that
the GPU/GP will be able to handle can be obtained knowing the:
– (M)CS distribution of the analysed network (P55x & P57y counters)
– The maximum number of PDCH per coding scheme
– The maximum number of GCH per PDCH per coding scheme
97 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Number of GCHs required per PDCH for a given (M)CS:
1,601,64CS-4
1,221,25CS-3
1,001,00CS-2
0,730,73CS-1
DLULCS
4,394,49MCS-9
4,004,14MCS-8
3,393,49MCS-7
2,312,36MCS-6
1,811,86MCS-5
1,471,50MCS-4
1,281,33MCS-3
1,001,00MCS-2
0,860,89MCS-1
DLULMCS
Number of required GCHs
GPU_GCH_Capacity calculation (2/3)Reminders
98 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
In DL direction the maximum number of GCHs that a GPU/GP will be able to
handle is defined as:
Max_DL_GCH_GPU = (%CS1 * max_PDCH_CS1 * max_DL_GCH_per_PDCH_CS1)+… (on all
coding schemes)
In UL direction the maximum number of GCHs that a GPU/GP will be able to
handle is defined as:
Max_UL_GCH_GPU = (%CS1 * max_PDCH_CS1 * max_UL_GCH_per_PDCH_CS1)+… (on all
coding schemes)
GPU_GCH_Capacity will be defined in the following way:
GPU_GCH_Capacity calculation (3/3)
{ }∑ ∑ − 4*_____,___,___ GPUMARGINTSATERNCapacityMaxGPUGCHULMaxGPUGCHDLMaxMin
Max_Capacity=480 or 1560 as described in previous slide
99 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
0
112
224
336
448
06/0
3/20
07 :
00h 06h
12h
18h
07/0
3/20
07 :
00h 06h
12h
18h
08/0
3/20
07 :
00h 06h
12h
18h
09/0
3/20
07 :
00h 06h
12h
18h
10/0
3/20
07 :
00h 06h
12h
18h
11/0
3/20
07 :
00h 06h
12h
18h
12/0
3/20
07 :
00h 06h
12h
18h
13/0
3/20
07 :
00h 06h
12h
18h
14/0
3/20
07 :
00h 06h
12h
18h
15/0
3/20
07 :
00h 06h
12h
18h
0
5
10
15
20
25
30
35
Example of GPU with DSP congestionWest Europe network example
GCH_GPU_Capacity
Needed GCH
DSP cong time
GPU is not able to support the required GCH traffic ����
it is recommended to add a new GPU or to use a GP board instead of the needed GPUs boards
N.B. If additional resources are added on AterMux the congestion at GPU level will become
bigger (bottleneck moving from AterMux interface to GPU)
100 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU_for_MS_context_handlingWhat does it mean ?
In B9 GPU board experiences a memory limitation that is quite more
restrictive than in B8 regarding the maximum number of MS contexts (active
or idle):
� B8 limitation is fixed at 2500 MS contexts
� B9MR1 limitation is fixed at 1000 MS contexts
� B9MR4 limitation is fixed at 1000 MS contexts for legacy MFS and at 4000
for MxMFS
The consequence of the limit reaching observed in B9 versions BEFORE
B9MR1ed6QD2 was an abnormal increase of UL TBF establishment failures
due to BSS problem
The workaround proposed up to now for handling this problem is the adding
of 1 more GPU (GPU_for_MS_context_handling=1)
QoS impact no more observed starting from B9MR1ed6QD2
101 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
0
200
400
600
800
1000
1200
21/1
0/20
06 :
00h 03h
06h
09h
12h
15h
18h
21h
22/1
0/20
06 :
00h 03h
06h
09h
12h
15h
18h
21h
23/1
0/20
06 :
00h 03h
06h
09h
12h
15h
18h
21h
24/1
0/20
06 :
00h 03h
06h
09h
12h
15h
18h
21h
25/1
0/20
06 :
00h 03h
06h
09h
12h
15h
18h
21h
0,0%
10,0%
20,0%
30,0%
40,0%
50,0%
60,0%
GPU_for_MS_context_handlingAn example
UL TBF BSS Failure rate
Average number MS context (P392a)
Max number MS context (P392b)
102 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU_for_MS_context_handling calculation
Retrieve indicators for 5 working days
P392bBSC =1000 during at least 12% ofThe observed period
NO
YES
P392bBSC = 1000 when BSS_fail_ratemax
Observed for all days with at least two occurrences of P392bBSC = 1000
Observed QoS acceptable for the customer ?
YES
YES
NO
NO
GPU_for_MS_context_handling=0
GPU_for_MS_context_handling=0
GPU_for_MS_context_handling=1
GPU_for_MS_context_handling=0
103 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
How to reduce impacts of MS context limit
Ms Context pre-emption mechanism (B9MR1ed06QD2)
An intra-cell pre-emption mechanism allows (being the Nb of MS context
equal to 1000) to reduce impacts of MS Context limit reaching on QoS,
improving per cell memory usage at GPU level
Cell B
Cell A
Cell B
Cell A1. New MS context
needed in Cell A: NOK
Idle MS context
Active MS context
GPU Memory for MS context
GPU Memory for MS context
2. New MS context needed in Cell B: OK
104 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
How to reduce impacts of MS context limit
Ms Context pre-emption mechanism (B9MR4)
An inter-cell pre-emption mechanism allows (being the Nb of MS context
equal to 1000 or 4000) to further reduce impacts of MS Context limit reaching
on QoS, improving memory usage at GPU level
1. New MS context needed in Cell A: OK
Idle MS context
Active MS context
GPU Memory for MS context
GPU Memory for MS context
2. New MS context needed in Cell B: OK
Intra and Inter cell pre-emption mechanisms could leadto an increase of PMU CPU load in GPU/GP
105 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU_for_Power_Limitation PMU CPU load
Retrieve indicators for 5 working days
P402/3600 >0,1% during at least 12% ofThe observed period
NO
YES
P402/3600 >0,1% and (max(P105e/P105f) > 1% OR GPU reboots observed during the CPU loaded hours)
YES
NO
GPU_for_Power_Limitation=0
No field feedback exists, up to now, on this method
GPU_for_Power_Limitation=0
GPU_for_Power_Limitation=1
In case of any other abnormal
event / behavior observed during
the CPU loaded hours a specific
analysis should be done in order to
identify the actual problem root cause
WARNING!: In case of B8 ���� B9 migration, an additional condition must be checked for GPU_for_Power_Limitation definition:
If GPU (not GP !) and P76a>40% in B8 then GPU_for_Power_Limitation=1
106 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
GPU_for_Power_Limitation DSP CPU load
Retrieve indicators for 5 working days
Max(P201,P202)/3600 >0,1% during at least 12% ofThe observed period
NO
YES
Max(P201,P202)/3600 >0,1% and (max(P203/P204) > 1% OR GPU rebootsObserved during the CPU loaded hours)
YES
NO
GPU_for_Power_Limitation=0
No field feedback exists, up to now, on this method
GPU_for_Power_Limitation=0
GPU_for_Power_Limitation=1
In case of any other abnormal
event / behavior observed during
the CPU loaded hours a specific
analysis should be done in order to
identify the actual problem root cause
107 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
B9 dimensioning methods: what’s new in B9 …
Abis dimensioning
AterMux PS dimensioning
GPU / GP dimensioning
Gb dimensioning
•QoS feature impact not taken into account
108 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
BSS architecture & dimensioning rules
BSC Abis TSU
Ater TSU
Abis TSU
Ater TSU
Abis TSU
Ater TSU
SGSN
speech
data
A-ter mux
Gb
A
CS
CS+ PS
PS
CS
A-bisAir
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 -EG CH link 1
PS traffic
TRX 3 M -EG CH link 2
M -EG CH link n
BTS
Dynam ic Ab is
a llocation GCH Extra
GCH Basic
GCH Basic
GCH Extra
GCH Bonus
T CH
T CH TRX 1 CS
traffic
TRX n
Evaluate the required
number of GbTS (� E1
links) per GPU
109 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Gb interface dimensioning
It is recommended to configure 1 NSVC (and one PVC) per E1 link in order to
better take advantage of the available global bandwidth
It is recommended to have at least 2 E1 links for redundancy reason
The needed number of TS per NSVC (PVC) can be estimated through the
following method:
Required_Gb_Traffic ERLANG C Required number of Gb TS
3600
1
8/]/64[
)46,45(
3600
1
__
_
3600
_____
arg%15____Re
×=×==
+=
skbit
PPMax
bandwithTSGb
volumedatatimebusyresourcesGbTrafficGbMeasured
inMTrafficGbMeasuredTrafficGbquired
Where:
- P45 (respectively P46) is the number of kilo bytes received from the SGSN (respectively sent to the SGSN) at PVC level
Withquantile=99,9%
110 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
BSS PS Dimensioning: parameter checking
Architecture CHECK
Parameter CHECK
Dimensioning Methods RUN
Network ArchitectureASSESSMENT
111 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
PS Dimensioning: parameter configuration
The following parameters have been identified as having an impact on PS
dimensioning assessment:
� MAX_PDCH_HIGH_LOAD� MAX_PDCH� N_EXTRA_ABIS_TS� MAX_GPRS_CS� MAX_EGPRS_MCS � EN_EGPRS � T_GCH_INACTIVITY� T_GCH_INACTIVITY_LAST � EN_FAST_INITIAL_GPRS_ACCESS � N_GCH_FAST_PS_ACCESS � Ater_Usage_Threshold, GCH_RED_FACTOR_High_Ater_Usage, N_ATER_TS_MARGIN_GPU
� GPRS_MULTISLOT_CLASS_DEF_VALUE� K_GSL (MFS) � R_AVERAGE_GPRS and R_AVERAGE_EGPRS (for future method evolution)
� CBS, EBS, CIR, NIR
N.B. In B9 GPRS_MULTISLOT_CLASS_DEF_VALUE decreasing has not always a visible impact on
PS resource usage (a dedicated test,done during B9MR4 first-Off, put that in evidence)
112 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Main recommendations on parameter settingA focus on Ater usage related parameters
1. Available GCH – (Available GCH x Ater_Usage_Threshold) > N_ATER_TS_MARGIN_GPU2. EN_FAST_INITIAL_GPRS_ACCESS = enable guarantees that one GCH is always established
in the cell.
Hence this setting could avoid situations when UL TBF cannot be established due to lack of
GCH resources.
3. An alternative solution to EN_FAST_INITIAL_GPRS_ACCESS = enable, allowing as much as
possible GCH resource wasting, and being more traffic driven is the tuning of T_GCH_INACTIVITY_LAST and T_GCH_INACTIVITY to their default value (Recommended
option)
PROs
�One GCH is always maintained (guaranteed)
�QoS could be improved due to less resource
allocation / deallocation processing
CONs
� GCH resource usage increase
� Possible impact on end-user throughput
� Potential resource waste in cells
with no traffic
PROs
� QoS could be improved due to less resource
allocation / deallocation processing
�GCH maintained only where needed
CONs
� GCH resource usage increase
� Possible impact on end-user throughput
113 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Main recommendations on parameter settingA focus on Gb interface related parameters (I)
� CIR represents the Committed Information Rate (in Kbits/sec) at Frame Relay level for UL direction (from MFS to SGSN)
� NIR represents the Normal Information Rate (in Kbits/sec) at Frame Relay level for UL direction (from MFS to SGSN)
� CBS represents the Committed Burst Size (in Kbytes) during the time interval T
� EBS represents the Excess Burst Size (in Kbytes) during the time interval T
� EIR represents the Excess Information Rate (in Kbits/sec) at Frame Relay level for UL direction (from MFS to SGSN)
� ACCESS_RATE_BC represents the maximum capacity of the Gb link (number of Gb TS * 64 Kbit/sec)
T
EBS
CBS
Bit rate
time
EIR
CIRNIR
ACCESS_RATE_BC
Gb (E1) link
PVC
114 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
CIR = (CBS * 8) / T
EIR = [(EBS + CBS)*8] / T
CIR <= NIR <= EIR <= ACCESS_RATE_BC Mandatory Rule
If Direct MFS-SGSN connection: CIR = NIR = 0 and EIR = ACCESS_RATE_BC Recc. Rule
Main recommendations on parameter settingA focus on Gb interface related parameters (II)
Warning: the default value for CIR / NIR is 0
� Update this parameter if no direct MFS-SGSN connection
T
EBS
CBS
Bit rate
time
EIR
CIR
NIR
ACCESS_RATE_BC
115 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
None[0,127]
0
Number
ChangeableCellMFSMaximum number of slave and master PDCHs that can be allocated to
the MFS in the cell.MAX_PDCH
None[0,127]
0
Number
ChangeableCellMFSMaximum number of slave and master PDCHs that can be allocated to
the MFS when the CS traffic is high.
MAX_PDCH_HIGH_LOAD
None[0,127]
0
Number
ChangeableCellMFSMinimum number of master and slave PDCHs that are always
allocated to the MFS.
MIN_PDCH
None[0,60]0NumberChangeableBTSBSCNumber of extra Abis (64k) timeslots configured for a BTS.NEW : N_EXTRA_ABIS_TS
None[0,1]0FlagChangeableCellBSCEnables/Disables EGPRS traffic in the cell.EN_EGPRS
None[1,4]2NumberChangeableCellBSCMaximum coding scheme used for GPRS traffic in the cell.MAX_GPRS_CS
None[0,1]0FlagChangeableMFSMFSThis flag indicates whether or not one Slave PDCH is available for
(E)GPRS traffic in the cell (fast initial PS access feature).
- In a Non Evolium BTS, that corresponds to an established PDCH
being able to support incoming (E)GPRS traffic.
- In an Evolium BTS, that corresponds to a PDCH being able to support
incoming (E)GPRS traffic, that PDCH being located on an established
TRX (i.e. the TRX owns an M-EGCH link)
NEW :EN_FAST_INITIAL_GPRS_ACCESS
None[1,5]1NumberNone (DLS)MFSMFSTwo 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).
NEW : N_GCH_FAST_PS_ACCESS
Cell
Instance
MFS
Sub-system
None[1,9]9NumberChangeableMaximum Modulation and Coding Scheme used for EGPRS traffic in
the cell.MAX_EGPRS_MCS
UnitRangeDef value
TypeOMC-R access
DefinitionHMI name
PS dimensioningParameters (I)
116 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
sec[1,100]3TimerChangeableBSSMFS- 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 TBFsestablished on that TRX were released).
NEW : T_GCH_Inactivity
sec[1,200]20TimerChangeableBSSMFS- 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. -
NEW : T_GCH_Inactivity_Last
%[1,100]70NumberChangeableBSSMFSThreshold (percentage of used Ater nibbles, in a GPU) above which the Ater usage is said “high”.
Ater_Usage_Threshold
None[1,2,4,8]8NumberChangeableBSSMFSDefault value of the (E)GPRS multislot class assumed at TBF
establishment when the actual MS (E)GPRS multislot class is
unknown.
- In an Evolium BTS :
The default MS class is used as an input of the best candidate TBF
allocation computation process when the MS class is not known on UL
TBF establishment
- In a Non Evolium BTS :
The default MS class is used as an input of the best candidate TBF
allocation computation process when the MS class is not known on UL
TBF establishment.
In the PDCH anticipation process on UL TBF establishment : the
default MS class is used to determine how many PDCHs are
established in advance to anticipate the concurrent DL TBF
establishment.
GPRS_MULTISLOT_CLASS_DEF_V
ALUE
Instance
Sub-system
UnitRangeDef value
TypeOMC-R access
DefinitionHMI name
PS dimensioningParameters (II)
117 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
bit/s[0,20000]12000NumberChangeablecellMFSAverage bitrate per PDCH for non-Edge capable terminals in this cellR_AVERAGE_GPRS
bit/s[0,59200]30000NumberChangeablecellMFSAverage bitrate per PDCH for Edge capable terminals in this cellR_AVERAGE_EGPRS
%[1,95]95Threshol
d
None (DLS)MFSMFSThreshold beyond which a given DSP is considered as « overloaded »
in terms of CPU load by RRM.NEW: DSP_LOAD_THR_2
%[0,100]95NumberNone (DLS)GPUMFSThreshold above which a GPU enters the PMU CPU overload state.PMU_CPU_Overload
%[1,95]85Threshol
d
None (DLS)MFSMFSThreshold beyond which a given DSP is considered as "loaded" in terms of CPU load by RRM.
NEW: DSP_LOAD_THR_1
none[0,10]2NumberChangeableBSSMFSNumber 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.Note : In case of non-Evolium BTS, those are PDCHs that will be established instead of GCHs.
NEW :N_ATER_TS_MARGIN_GPU
none[0,1,1]0.75NumberChangeablecellMFSReduction factor of the number of GCHs targeted per PDCH, when the Ater usage is “high”.
NEW :GCH_RED_FACTOR_HIGH_ATER
_USAGE
UnitRangeDef value
TypeOMC-R access
Instance
Sub-system
DefinitionHMI name
PS DimensioningParameters (III)
118 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
none[1,16] in
B9MR1
[1,32] in
B9MR4
7NumberNone (DLS)MFSMFSMaximum number of outstanding I frames on a GSL link.K_GSL (MFS)
Kbit/s[0,1984]0NumberChangeablePVCMFSCommitted Information Rate.CIR
Kbytes[0,248]NoneNumberChangeablePVCMFSExcess Burst Size.EBS
Kbit/s[0,1984]0NumberChangeablePVCMFSNormal Information Rate.NIR
Kbytes[0,248]0NumberChangeablePVCMFSCommited Burst Size.CBS
Kbit/s[64,1984]64NumberDisplayedBCMFSPhysical access rate of the Frame Relay bearer channel.NEW: ACCESS_RATE_BCB8: FR_Capacity
UnitRangeDef value
TypeOMC-R access
Instance
Sub-system
DefinitionHMI name
PS DimensioningParameters (IV)
119 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
BSS Dimensioning: Overview on available
documentation and tools
120 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Several tools exist for supporting you …
For PARAMETER CHECK: SMART MCT, AMT .NET
In order to check DLS parameters it is necessary to retrieve BSC/MFS DLS
For ARCHITECTURE CHECK: AMT .NET
For DIMENSIONING METHODS RUN:
� 2G Traffic Tool (B9 only) Prerequisite: NPA or MPM
� Excel templates Prerequisite: RNO
Smart MCTRNL files excel export files
AMT .NET
RNL & EML files
excel export filesOMCAMT v5 script
2G Tool
13 .txt filesexcel export files
NPA / OMCTSL script
Excel
RNO excel export files
RNORNO BestOf
or manual search
Architecture CHECK
Parameter CHECK
Dimensioning Methods RUN
Network ArchitectureASSESSMENT
121 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Several tools exist for supporting you …A focus on dimensioning method implementation
Input data
imported but
manual
analysis
needed
Input data
imported but
manual
analysis
needed
Power limitation and MS context
limitation
XXPaging load estimation
XTraffic method – Reference @ 10
links per GP
XXTraffic method – Reference @ 12
links per GP
GPU/GP dimensioning
GSL load on number of msg/sec
GSL load on bandwidth
traffic – Method2
traffic – Method1
RTCH / PDCH dimensioning
Method detail
X
X
XXGb dimensioning
XX
XXAterMux interface
XAbis interface
XAir Interface
Excel Templates
2G Traffic Tool
Dimensioning task
122 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
Intranet available information
You’ll find all usefull instruments for B9 dimensioning on the following web
page:
B9 Release web page (*) http://aww.quickplace.alcatel.com/QuickPlace/mnd_pcs-
psf/PageLibraryC125712D0058D6B1.nsf/h_Toc/3643c4df564f0a6cc125714100600c65/?OpenDocument
Documentation� B9: BSS Architecture Service Guidelines (ed2 Released available and ed3 available for
review).
� B9 Seminar(s) presentation(s)
� “Quick & Light” dimensioning recommendations for B9 release
� Complete list of needed indicators for dimensioning assessment
� Guidelines on how to identify linked BSC-GPU-PVC-LAPD objects
“Tools”� AMT .NET : Reference to official AMT .NET web page (version 2.0 delivered in w22)
� 2G Traffic tool + data check tool: user guide, executable and TSL script (with related
execution process) for traffic indicator values export (version 1.2.0.2 delivered in
w23).
� Excel templates for dimensioning assessment
(*) http://aro.tm.alcatel.ro � Technology 2G � B9 Release � B9 Architecture & Dimensioning section
123 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
?Questions& Answers
124 |BSS Architecture | June 2007 All Rights Reserved © Alcatel-Lucent 2006, #####
www.alcatel-lucent.com