B9 Archi Dim Methods Workshop June2007

Network Architecture ASSESSMENT Architecture CHECK Parameter CHECK Dimensioning Methods RUN
B9 BSS Dimensioning Methods
GSM Network Engineering Team
1 |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)
Enhanced Transmission Resource Management overview
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
M-EGCH Statistical Multiplexing

(1/5)
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.
CS traffic
7 6 5 4
TCH TCH
Unused TS: no Abis resource required
GCH Basic
3
PS traffic
2 1 0 TRX
M-EGCH link
GCH Extra
Single Packet pipe

GCH Extra GCH Bonus GCH Basic

(2/5)
B8: one EGCH per RTS

TRX 0
EGCH
B9: one M-EGCH link for the whole TRX

7
EGCH
1
EGCH
2
EGCH
3
EGCH
4
EGCH
5
EGCH
6
EGCH
TRX
M-EGCH link
composed of
GCH
composed of
GCH GCH GCH
GCH
GCH
GCH
GCH
1 to 5 GCHs depending on the TRX class

6 |BSS Architecture | June 2007 All Rights Reserved Alcatel-Lucent 2006, #####
1 to 36 GCHs
GCH
GCH

(3/5)
Number of GCHs required per PDCH for a given CS:

Number of required GCHs CS CS-1 CS-2 CS-3 CS-4 UL 0,73 1,00 1,25 1,64 DL 0,73 1,00 1,22 1,60
With Statistical Multiplexing, nb of GCH has not to be rounded-up


(4/5)
Number of GCHs required per PDCH for a given MCS:

Number of required GCHs MCS MCS-1 MCS-2 MCS-3 MCS-4 MCS-5 MCS-6 MCS-7 MCS-8 MCS-9 UL 0,89 1,00 1,33 1,50 1,86 2,36 3,49 4,14 4,49 DL 0,86 1,00 1,28 1,47 1,81 2,31 3,39 4,00 4,39
With Statistical Multiplexing, nb of GCH has not to be rounded-up


(5/5)
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.
Dynamic Abis Allocation

(1/5)
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.

(2/5)
B8: static Abis allocation

TRX 0
EGCH
B9: dynamic Abis allocation

7
EGCH
1
EGCH
2
EGCH
3
EGCH
4
EGCH
5
EGCH
6
EGCH
TRX
M-EGCH link
No more constraints in B9!
composed of
GCH Basic
GCH Extra
GCH Extra
GCH Extra
GCH Extra
GCH Basic
GCH Extra
GCH Extra
GCH Basic
1 to 5 GCHs depending on the TRX class (and only one GCH can use a basic Abis nibble)
1 to 36 GCHs (mixture of GCHs using basic, extra and bonus Abis nibbles)
GCH Basic
Basic Abis nibbles and Extra Abis nibbles are statically mapped to a RTS. They can only be used in the EGCH of this RTS.
composed of

Dynamic Abis Allocation In B8, a lot of Abis nibbles were wasted An example:
(3/5)

Dynamic Abis Allocation In B9, the following Abis nibbles are usable for PS traffic:
(4/5)
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).

Dynamic Abis Allocation Level of sharing of the Abis nibbles are usable for PS traffic:
(5/5)
The basic Abis nibbles mapped on a RTS allocated to MFS can be used in the MEGCH 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.
CS traffic
TRX 1 TRX 2
TCH TCH
M-EGCH link 1 M-EGCH link 2
GCH Basic
PS traffic
TRX 3
Dynamic A bis allocation
GCH Extra
Abis
GCH Extra GCH Bonus
TRX n
BTS
M-EGCH link n
n 12
GCH Basic
Ater Resource Management

Principles
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).

GPU 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.

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).

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.

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)
DL retransmission in the BTS

Principles (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.
DL retransmission in the BTS

Principles (II)
This mechanism is enabled / disabled depending on the EN_DL_RETRANS_BTS parameter, on the TRX HW capability and on the MFS-BTS round_Trip_delay:
HW generation of the TRE
EN_DL_RETRANS_BTS
Enabled Enabled disabled
Round_Trip_Delay
CS-2 (DRFU) Disabled Disabled Disabled
CS-4 (G3 or M4M) Disabled Disabled Disabled
CS-4+MCS-9 (G4 or M5M) Enabled Disabled Disabled
< 500 ms 500 ms -
Gains: Higher available transmission bandwidth. M-EGCH link dimensioning is eased.
Counter Based Dimensioning Rules
BSS architecture & dimensioning rules

Whats new in B9
Assessment of traffic values for SDCCH, TCH and PDCH channels Check the load and connectivity based on TC configuration Check the capacity limits and the parenting rules for Abis TSU ports based on BSC configuration
Assessment of basic and bonus Abis nibbles from TRX and BTS configuration
TC
Assessment of CS and PS traffic over Ater
MT120
SMU TRCU TRCU TRCU
speech
MT120
Air
CS traffic PS traffic TRX 1 TRX 2 TRX 3
TCH TCH
A-bis
G C H B asic
SMU
TRCU TRCU TRCU
BSC
Abis TSU Abis TSU Abis TSU Ater TSU Ater TSU Ater TSU
CS
CS
M -EG C H link 1 M -EG C H link 2
TRX n
M -EG C H link n
D yn a m ic A b is a llo c a tion
G C H B asic G C H B on u s G CH Extra
A-ter mux
CS+ PS PS
MFS
GPU board
DSP DSP DSP DSP
G CH Extra
Check the load and conectivity on DSP and GPU boards of MFS
B TS
data
SGSN
Calculate the needed radio TS for SDCCH, TCH and PDCH, then nb of TRXs
Calculate the needed extra Abis TS for real traffic on Abis Itf and the number of needed Abis links
GPU board
DSP DSP DSP DSP
Gb
Evaluate the required number of Gb 64K TS per GPU
Calculate the total number of Ater channels and the required number of Ater links
Evaluate the required number of GPU/GP boards
Unchanged methods
B9 dimensioning methods: whats new in B9

Abis dimensioning AterMux PS dimensioning GPU / GP dimensioning Gb dimensioning
QoS feature impact not taken into account
Assessment of basic and bonus Abis nibbles from TRX and BTS configuration
SMU
TC
MT120
TRCU TRCU TRCU
speech
MT120
SMU TRCU TRCU TRCU
BSC
CS traffic PS traffic TRX 1 TRX 2
TCH TCH
CS
Ater TSU Ater TSU Ater TSU
G C H B asic
Abis TSU Abis TSU Abis TSU
CS
Air
TRX 3 TRX n
M -EG C H link n
A-ter mux
CS+ PS PS
MFS
GPU board
DSP DSP DSP DSP
A-bis
G CH Extra
B TS
GPU board
SGSN
Calculate the needed extra Abis TS for real traffic on Abis Itf and the number of needed Abis links
DSP DSP DSP DSP
Gb
data
B8 to B9 Abis Dimensioning Processes

Overview
B8 Static Abis allocation

Initial phase 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 (Nb of Extra TS = 0)
B9 Dynamic Abis allocation

Optimized phase Assess the initial setting of Extra TS based on counter measurement.
B8: Not possible to optimize # Extra TS because of static Abis allocation
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
B9: Extra Abis TS can be optimized, thanks to dynamic Abis allocation


Overview
B8 Static Abis allocation

Initial phase
B9 Dynamic Abis allocation

Optimized phase
NW with GPRS CS3-4 and/or EDGE activation (in case no EDGE Assess the initial setting of EDGE in B8) Extra TS based on counter measurement. Fixed Nb of Extra TS Define Max. MCS needed corresponding Configurable Nb of Extra TS to TRX class (class 2 to 5) Same B8 EDGE approach A B8 B9 migration rule exists for the initialization of the B9 parameter :containing the Nb of extra Abis TS: NW w/o EDGE or with GPRS cf the example (slide 33 ) CS1-2 only Set equal to a N_EXTRA_ABIS_TS = 2*[(1*Nb-of-TRX-Trans-Pools-Type2)+(2*Nb-of-TRX-Trans-Pools-Type3)+(3*Nb-ofNot require Extra TS (Nb recommended initial value TRXTrans-Pools-Type4)+(4*Nb-of-TRX-Trans-Pools-Type5)] for each sector of the BTS of Extra TS = 0) (cf slide 42 ) in B9, is the sum of NB_EXTRA_ABIS_TS, In other words, N_EXTRA_ABIS_TS, for the BTSBest Effort approach : put as many Extra TS as there are for each sector of the BTS in B8. available on the existing B8: Not possible to Abis links and respect to optimize # Extra In order to have an iso-functionnality B8 B9 BSC limit it is recommended to configure MAX_GPRS_CS migration TS because of and MAX_EGPRS_MCS on the basis of the actual capability of the cell (depending on the TRX classes set static Abis In the cell) allocation B9: Extra Abis TS can be optimized, thanks to dynamic Abis allocation

From B8 to B9 initial phase
EDGE BSS Architecture Activities

Step I: Define EDGE Class - TRX Class in B8 - CS/MCS in B9 Step II: Design Abis resource - Static Abis allocation in B8 - Dynamic Abis allocation in B9
Design
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)
Operational
Deploy Secondary Abis link (if needed) Activate GPRS (CS-3/4) / EDGE - B8 parameters - B9 parameters

From B8 to B9 initial phase : Design (1/3)
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:
TRX Class Class 5 (Max CS-4 / Max MCS-9) Class 2 (Max CS-4 / Max MCS-5) Class 1 (Max CS-2) Number of TRX Class (per cell) 1 TRX 1 TRX 1 TRX Criterion For cells considered as "High" PS traffic For cells considered as "Medium" PS traffic For cells considered as "Low" PS traffic
B9: Define Maximum CS and MCS for each cells

TRX Class concept is removed in B9 Example:
Max CS (per cell) CS-4 CS-3 CS-2 Max MCS (per cell) MCS-9 MCS-6 MCS-4 Criterion For cells considered as "High" PS traffic For cells considered as "Medium" PS traffic For cells considered as "Low" PS traffic

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 Abis network topology (i.e.Chain, Star,or Ring). Nb of Extra Abis TS to be set at OMC per BTS Is secondary Abis deployment needed?

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

From B8 to B9 initial phase : Operational
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 To be set according to MAX_GPRS_CS defined TRX Class MAX_EGPRS_MCS Number of TRE for each TRX pool types EN_EGPRS MAX_GPRS_CS MAX_EGPRS_MCS Configurable by operator ! N_EXTRA_ABIS_TS (Number of 64K extra Abis TSs in the BTS ,new in B9)
B9 parameters

From B8 to B9 initial phase : Example (1/8)
1 BTS having 3 Cells with TRX configuration FR 2+2+2
BTS
FR TRX #1 TRX_PREF_MARK = 1
Radio TS Configuration
TS0 TS1 TCH TS1 TCH / PDCH TS1 TCH TS1 TCH / PDCH TS1 TCH TS1 TCH / PDCH TS2 TCH TS2 TCH / PDCH TS2 TCH TS2 TCH / PDCH TS2 TCH TS2 TCH / PDCH TS3 TCH TS3 TCH / PDCH TS3 TCH TS3 TCH / PDCH TS3 TCH TS3 TCH / PDCH TS4 TCH TS4 TCH / PDCH TS4 TCH TS4 TCH / PDCH TS4 TCH TS4 TCH / PDCH TS5 TCH TS5 TCH / PDCH TS5 TCH TS5 TCH / PDCH TS5 TCH TS5 TCH / PDCH TS6 TCH TS6 TCH / PDCH TS6 TCH TS6 TCH / PDCH TS6 TCH TS6 TCH / PDCH TS7 TCH TS7 TCH / PDCH TS7 TCH TS7 TCH / PDCH TS7 TCH TS7 TCH / PDCH
BCCH
TS0
CELL #1
SDCCH
TS0
CELL #2
BCCH
TS0
SDCCH
TS0
CELL #3
BCCH
TS0
SDCCH

From B8 to B9 initial phase : Example case I : B8 (2/8)
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 Basic Abis TS = 12 TS RSL/OML Abis TS Extra Abis TS = 1 TS = 2 Abis TS (per TRX) * 6 TRX (3 cells) = 2 TS = 24 TS
* In case of 64K Statistical Multiplexing for 6 RSL/TRX (3 cells) + 1 OML (1 BTS)
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 (Extra)
= 1 (TS0) + 12 (Basic) + 2 (RSL/OML) + 24 = 39 Abis TS
Secondary Abis link needed !!!


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 Operational:
2 Abis links needed to be implemented for this BTS
Primary Abis link
BSC
Secondary Abis link
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)

From B8 to B9 initial phase : Example case II : B9 (5/8)

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 Basic Abis TS TS RSL/OML Abis TS = 1 TS = 2 Abis TS (per TRX) * 6 TRX (3 cells) = 12 = 2 TS = 17 TS
Max required Extra Abis 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 wed need all GPRS Max MCS is MCS-9 to be set for each cells. and/or EDGE TS having the maximum *In order to get the same behaviour as in B8 => to check the Architecture impact from is recommended to check declared (M)CS. It B8 to B9 the real MCS distribution calculating a Step II: Design Abis Resource (Max 32 Abis TS per 1 Abis link) replace real average #GCH per PDCH 4.49 by:
Calculation:
TS0 Basic Abis TS TS RSL/OML Abis TS
= 1 TS Sum{MCSi_ratio * nb_GCH_MCSi}<4.49 = 2 Abis TS (per TRX) * 6 TRX (3 cells) = 12 = 2 TS = 17 TS
Max required Extra Abis 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)

B9 Design (cont):
Max Total required Abis TS = 1 (TS0) + 12 (Basic) + 2 (RSL/OML) + 17 (Extra) Only 1 Abis link enough !!! = 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

B9 Operational:
Only 1 Abis link needed to be implemented for this BTS
BSC
Primary Abis link
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
New parameter in B9

From B8 to B9 initial phase : Example summary (8/8)
Summary Architecture impact B8 vs. B9 based on this example:

B8: 2 Abis links needed
24 extra TS Fixed number of extra TS configured according to TRX pool type
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
High BSC resource consumption

18 FR eq TRXs
Low BSC resource Consumption

Max 14.5 FR eq TRXs

From 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:
Configuration CS1-CS2 CS3-CS4 and EN_EGPRS disable CS3-CS4 and EN_EGPRS enable N_EXTRA_ABIS_TS 0 0 or 1 according to bonus nibbles availability 6
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

B9 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

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
P105i > 0,1% P91a + P91b + P91c + P91d + P91e + P91 f
OR
P105 j > 0,1% P62a + P62b + P62c P 438c

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
B9 Abis Dimensioning methods

Functional Reminders
Radio Resource Management: Autonomous Packet Resource Allocation

reserved for PS priority for PS priority for CS reserved for CS
MIN_SPDCH MAX_SPDCH_HIGH_LOAD MAX_SPDCH_Limit MAX_SPDCH
Transmission Resource Management: Abis allocation priority

MAX_SPDCH_High_Load Zone From MAX_SPDCH_High_Load to MAX_SPDCH
Basic nibbles of cell Priority N1 Priority N2 Extra+Bonus nibbles of BTS Priority N3
B9 Abis dimensioning methods

Extra&Bonus Method PROs
Easy to apply
MCS Method PROs

Take into account all types of Abis nibble (basic, extra, bonus) Take into account PS and CS traffic
CONs
Focused only on PS traffic Focused only on priority 2 Abis nibbles: Extra & Bonus nibbles
CONs
Complex to apply
B9 Abis Dimensioning Processes

Extra&Bonus Method
With quantile=95% Required_extra &Bonus_Abis_Traffic Number of bonus nibbles
ERLANG C
Number of extra Abis TS
Number of extra&bonus Abis nibbles

Re quired _ extra & Bonus _ Abis _ Traffic =
Number of extra Abis nibbles
Measured _ extra & bonus _ Abis _ Traffic 1 Min(%TBF _ Abis _ Cong ,30% ) P 466 Measured _ extra & bonus _ Abis _ Traffic = 3600 %TBF _ Abis _ cong = Max(% DL _ TBF _ Abis _ cong ,%UL _ TBF _ Abis _ cong ) % DL _ TBF _ Abis _ cong = P105i x100% P91a + P91b + P91c + P91d + P91e + P91 f P105 j %UL _ TBF _ Abis _ cong = x100% P 62a + P62b + P62c P 438c
GoS= Grade Of Service
B9 Abis Dimensioning Method

MCS Method
CS and PS traffic data (from counters)
MCSx CS
MCS Method
Nb Basic nibbles
Number of Extra TS needed
Customers option
Min_SPDCH Max_SPDCH Max_SPDCH_High_Load
Average TBF Throughput
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
MCS Method high level description

How ?
Nb extra and bonus = 0
using
Calculate GoS of all services in each cell
Compare calculated GoSs to required ones
Traffic_ service_1
Traffic_ service_2
Resources_ Resources_ capacity service_1 service_2 Knapsack model
False
Nb extra and bonus ++
GoS reached in all cell for all services?

True
Nb of extra Abis TS
Nb extra and bonus
Nb of bonus nibbles
Nb of extra Abis nibbles

Stochastic method allowing to find a distribution f(n, prob(n)) in a multiservice environment, being n the number of used resources
Abis dimensioning global method

For ALL BTS Extra & Bonus method yes Extra nibbles Needed ?
No
MCS method N_EXTRA_ABIS_TS=0

For each BTS Needing additional Resources according to Extra & Bonus method
Extra nibbles Needed ? yes
No
Select minimumm between theoretically missing resources (according to the method given in slide 37 ) and the minimum between extra & bonus / MCS method results /4 N_EXTRA_ABIS_TS
Round up
Abis dimensioning global method

An 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 traffic (7,5Erl) Quantile (95%)
Extra & bonus method MCS method
5 extra nibbles
6 extra nibbles
5 extra nibbles
Min
Basic (19) Bonus (8)

Theoretically Maximum need method
5 extra nibbles
See slide 37
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
Assessment of PS traffic over Ater
TC
MT120
SMU TRCU TRCU TRCU
speech
MT120
SMU TRCU TRCU TRCU
BSC
TCH TCH
G C H B asic
CS
CS
Air
TRX 3 TRX n
M -EG C H link n
A-ter mux
CS+ PS PS
MFS
GPU board
DSP DSP DSP DSP
A-bis
G CH Extra
B TS
SGSN
GPU board
DSP DSP DSP DSP
Gb
data
Calculate the total number of Ater channels and the required number of Ater links
Evaluate the required number of GPU/GP boards
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)
Indicators for AterMux interface underdimensioning control

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
Ater Congestion detection

Traffic congestion
P383a/3600 > 0,1% P383b/3600 > 30%
(1/2)
GSL congestion (at bandwidth level)
Measured_GSL_Traffic/GSL_link_band_capacity > 80%
Being: Measured_GSL_Traffic equal to:

GSL _ resources _ busy _ time data _ volume 1 Max( P 41, P 42) 1 = = 3600 GSL _ Link _ bandwith 3600 [64kbit / s ] / 8 3600
GSL_link_band_Capacity = 0,42 Erl
Ater Congestion detection

GPU
K_GSL
GSL messages buffer A message is kept in the buffer during GSL_round_trip_delay
(2/2)
GSL congestion (in terms of number of messages/sec at GPU/GP level)

GSL_round_trip_delay
BSC
(Number of GSL messages/sec per GPU)/ GSL_link_Max_capacity per GPU > 75%
Where:
reference GSL_round_trip_delay = 60ms
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
Due to FR 3BKA20FBR202481
Terrestrial links Satellite links
K_GSL * (1000ms/GSL_round_trip_delay) * (1/2) * number of configured GSL links per GPU/GP if GSL_round_trip_delay 500ms
Referecne 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])
AterMux PS interface assessment method
(1/3)
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 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 underdimensioned (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.
b.
AterMux PS interface assessment method Method applied at BSC level

AterMux dimensioning Assessment for GSL traffic
# Needed GSL links
(2/3)
AterMux dimensioning Assessment for user traffic

# Needed GCH
GPU/GP dimensioning Assessment
# AterMux PS
Aterlink GCH_Capacity
# AterMux PS per GPU (GSL traffic)
max
# AterMux PS per GPU (user traffic)
(for security reason)
# GSL links
(at least 2 per GPU/GP)
CS Full 7/8 Null
TCH 116 100 84 56 28 0
PS Null 1/8 Full
GCH 0 16 32 60 88 116
# GPU/GP
# AterMux PS per GPU/GP

AterMux PS interface assessment method Method applied at GPU/GP level

# Needed GSL links
(3/3)
AterMux dimensioning Assessment for user traffic

# Needed GCH 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: New #GPU/GP at BSC level # AterMux PS at BSC level
Aterlink GCH_Capacity
GPU/GP dimensioning Assessment

If #GPU/GP=1
# AterMux PS
# Needed GSL links at BSC level
max
# AterMux PS per GPU (user traffic) # AterMux PS per GPU (estimated at BSC level)
# AterMux PS per GPU (user traffic)
# GSL links
(at least 2 per GPU/GP)
max
# AterMux PS per GPU/GP # AterMux PS per GPU/GP

AterMux PS assessment method Some Examples

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
(1/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.

#Needed GCH = 400 #Needed GPU/GP = 2 #AterMux PS per BSC = 400/112 = 4 #AterMux PS per GPU/GP = 4 / 2 = 2
(2/3)
GPU/GP level
GPU1
GPU2
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.

#Needed GCH = 500 #Needed GPU/GP = 2 #AterMux PS per BSC = 500 / 112 = 5 #AterMux PS per GPU/GP = 5 / 2 = 3
(3/3)
GPU/GP level
GPU1
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
AterMux dimensioning assessment for GSL traffic

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
If GSL load > 80% ( slide 58) than add 1 GSL link on the GPU/GP on which the GSL overload is observed
Assessment based on GSL bandwidth
Assessment based on the number of GSL messages per second
2
(for security reason)
max
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
# GSL links
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)
GSL Assessment based on the number of GSL messages per second

How to estimate the number of GSL messages per second (I) B9 major impact
1) Msg on GSL due to RAE4 mechanism 2) Msg on GSL due to PS traffic: 2.1) Msg on GSL due to PS/CS paging
0.3 Msg/sec x Nb_cell
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 UL TBF without sig on GSL (eg. ACK of FTP DL transfer) TBF (UL & DL) corresponding to PS data (3 cases) Low GSL usage (eg. Ping 5 sec) Medium GSL usage High GSL usage (worst case) 2.5 3.5 5 x Nb_TBF_Data_req/sec 1.7 x Nb_TBF_Sig_req/sec 0 x Nb_UL_TBF_req_noGSL/sec
Nb GSL messages/sec

How to estimate the number of GSL messages per second (II)
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

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:
PS traffic If #TBF req / sec < 20 TBF/sec Nb of Msg on GSL (TBF req) High Available GCH If ater congestion observed Low 2.5 3.5 High 3.5 Low 5
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).

Global assessment method (run at BSC or GPU/GP level)
Retrieve indicators and Cells GPUs mapping (if method applied to 1 GPU/GP)
(*) QoS evaluation to be done by QoS expert Retrieve data on a different Period or on an updated configuration with better QoS*
START
PS Traffic data CHECK
QoS acceptable ?*
(i.e. UL TBF estab success rate >80%)
No
OR
Yes GSL traffic condition Calculation
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)
#GSL msgs/sec calculation Calculation
# GSL links
75% x GSL_Link_Max_Capacity (see slide 59 for computation If the method is applied at BSC level, the total capacity (for all GPU/GP) must be kept
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)
AterMux dimensioning Assessment for user traffic Required_GCH_Traffic Counters Required_GCH_Traffic estimation
Stable Network Feature activation Traffic evolution
Needed GCHs ERLANG C
With quantile=99,9%
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)
Required_GCH_Traffic estimation
Two different methods can be used for the estimation of the Required_GCH_traffic quantity:
Method 1: driven by the estimation of the required traffic as a function of the measured GCH traffic and of Ater/GPU congestion P383a, P384, P201, P202, P402 Congestion
Stable Network
Feature Traffic activation evolution
Method 2: driven by the estimation of the required traffic as a function of the measured GCH and radio PS traffic
P100c GCH traffic
P100c GCH traffic
P38b PDCH traffic
Required_GCH_Traffic estimation Required_GCH_Traffic
Required_GCH_Traffic estimation Required_GCH_Traffic
Method 1
Stable Network Feature Traffic activation evolution
Re quired _ GCH _ Traffic =

400
Measured _ GCH _ Traffic 1 min(Congestion30%) ;

Measured_GCH _traffic
Required_GCH _traffic
350
300
250
200
150
100
50
0 06/03/2007 : 00h 04h 08h 12h 16h 20h 07/03/2007 : 00h 04h 08h 12h 16h 20h 08/03/2007 : 00h 04h 08h 12h 16h 20h 09/03/2007 : 00h 04h 08h 12h 16h 20h 10/03/2007 : 00h 04h 08h 12h 16h 20h 11/03/2007 : 00h 04h 08h 12h 16h 20h 12/03/2007 : 00h 04h 08h 12h 16h 20h 13/03/2007 : 00h 04h 08h 12h 16h 20h 14/03/2007 : 00h 04h 08h 12h 16h 20h 15/03/2007 : 00h 04h 08h 12h 16h 20h
Method 1
Re quired _ GCH _ Traffic =

400
Measured _ GCH _ Traffic 1 min(Congestion30%) ;
Required_GCH _traffic
350
300
250
P100c Measured_GCH 3600 _traffic Congestion = Max{Ater _ Congestion, GPU _ Limitation} = Max{% Ater _ Cong ,% DSP _ Cong ,% DSP _ load ,%CPU _ overload } Measured _ GCH _ Traffic = P383a ; 3600 P384 % DSP _ Cong = ; 3600 Max( P 201, P 202) % DSP _ load = ; 3600 P 402 %CPU _ overload = 3600 % Ater _ Cong =
200
150
100
50
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
06/03/2007 : 00h 04h 08h 12h 16h 20h 07/03/2007 : 00h 04h 08h 12h 16h 20h 08/03/2007 : 00h 04h 08h 12h 16h 20h 09/03/2007 : 00h 04h 08h 12h 16h 20h 10/03/2007 : 00h 04h 08h 12h 16h 20h 11/03/2007 : 00h 04h 08h 12h 16h 20h 12/03/2007 : 00h 04h 08h 12h 16h 20h 13/03/2007 : 00h 04h 08h 12h 16h 20h 14/03/2007 : 00h 04h 08h 12h 16h 20h 15/03/2007 : 00h 04h 08h 12h 16h 20h
Method 2 METHOD 2:
448 y = 5,3905x + 21,057
Required_GCH_Traffic
336
Measured GCH traffic
224
Resources saturation
112
0 0 10 20 30 40 50 60 70 80
Measured PDCH 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
An example
Following the 4th link adding
(1/3)
Stable Network
Needed_GCH
560
448 y = 5,3905x + 21,057
ERLANG C
Measured GCH traffic
336
224
112
0 0 10 20 30 40 50 60 70 80
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
An example
4 links: from 12/03 to 27/03
gch traffic
448
(2/3)
Stable Network
y = 5,3905x + 21,057
336
4 links: From 08/03 to 11/03
224
3 links
112
0 0 10 20 30 40 50 60 70 80
Pdch traffic
Abnormal resource management: in the meantime UL TBF Establishment Failure due to BSS Fail equal to 25%
An example
(3/3)
Stable Network
gch traffic
448
4 links: 16 more cells (EDGE/CS3/CS4 activated on 3 cells over 16) EN_FAST_INITIAL_GPRS_ACCESS enabled
y = 5,3905x + 21,057
336
224
112
0 0 10 20 30 40 50 60 70 80 90
Pdch traffic
EN_FAST_INITIAL_GPRS_ACCESS = enable represented a workaround for this abnormal resource management (see slide 112 for related recommandations)
EGDE, 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:

b CS1/CS2 c a EDGE e CS3/CS4 d CS3/CS4 & EDGE
Increase factor estimation

The increase factor can be estimated in the following way:
Stable Network
Does a (set of) reference BSC(s) Exist ? No
Yes
Increase_factor = increase_factor(reference BSCs)
Increase_factor estimated on the basis of the Avg_target_nb_GCH_per_PDCH (depending on target service penetration)
Execute transition
Increase_factor = avg_target_nb_GCH_per_PDCH final / avg_target_nb_GCH_per_PDCH initial
Dimensioning assessment for Fine tuning
Update reference BSCs set
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 Transition type a b c d e Increase_Factor
[(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS *1,64)]/1 [1,64]/1 [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS *1)]/1 [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS *1,64)]/ 1,64 (%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS* 1,64)/(%_PDCH_EGPRS*4,49)+(%_PDCH_ GPRS*1)
CS1/CS2
b a c
CS3/CS4
d
CS3/CS4 & EDGE
EDGE
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%
Estimated Increase_Factor use

Increase Factor
Required_GCH_traffic
Method 1 Required_GCH_traffic new = Required_GCH_traffic current * Increase_Factor Method 2
After EDGE/CS3/CS4
GCH traffic
Y=a2x + b2
Y=a1x + b1
Before EDGE/CS3/CS4
PDCH traffic a2= a1 * Increase_Factor and b2 = b1 (approximation !)


Example 1 (CS3-CS4 & EDGE activation)
448 y = 5,3905x + 21,057
EDGE / CS3-CS4
336
GCH traffic
224
CS1-CS2
y = 1,9111x + 20,368
%_PDCH_EGPRS= P38c/P38b %_PDCH_GPRS=(P38b-P38c)/P38b

112
PDCH traffic
0 0 10 20 30 40 50 60 70 80
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

Example 2 (CS3-CS4 activation) (I)
Being the increase_factor for this kind of transition (b) equal to 1,64 (cf. previous slide):
224
168
Needed_GCH Forecasted trend

112 y = 2,9487x + 7,6258
ERLANG C
y = 1,798x + 7,6258 56
0 0 5 10 15 20 25 30 35
Current AterMux PS Configuration = 2 x 50% AterMux

2nd PS AterMux link adding recommended

Example 2 (CS3-CS4 activation) (II) After CS3-CS4 Activation on 43 over 52 cells:
224
GCH traffic
168
CS3-CS4
Forecasted trend
BSC level
112 y = 2,9487x + 7,6258
y = 1,798x + 7,6258 56
CS1-CS2
0 0 5 10 15 20 25 30 35
PDCH traffic
The forecasted trend is very close to the observed one after CS3-CS4 activation Additional AterMux PS resources are required (as previously recommended)
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 CS1-CS2 CS3-CS4 CS3-CS4 and EN_EGPRS=disabled CS3-CS4 and EN_EGPRS=enable (MAX_EGPRS_MCS=9) CS3-CS4 and EN_EGPRS=enable (MAX_EGPRS_MCS=9)
Recommended number of PS AterMux = round up [(maximum_number_of_GCH * 1,64)/112]
Recommended number of PS AterMux = round up [(maximum_number_of_GCH * 3)/112]
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)
Required_GCH_traffic estimation
BTS moving
BTS Moving
BTS TRX BTS TRX BTS TRX BSC
Method 1
Cell Zone related To BTS to move Cell Zone related To BSC before BTS moving
GCH traffic
Method 2
+
PDCH traffic Cell Zone related PDCH contribution To BSC before BTS moving due to Cell Zone Related to BTS to move
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:
560 y = 5,7292x + 10,705
Estimated final required_GCH_Traffic before the BTS moving
448
(4),(2)
Karl-D: no edge with 2 links 336 gch usage y = 5,1084x + 12,146
(3)
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)
224
(2) (1)
112 y = 1,9907x + 13,44
Karl-D+Karl-C trend
(1)
y = 1,8171x + 8,2315 0 0 20 40 60 pdch usage 80 100
(3) Cell Zone related Cell Zone related To BSC before BTS moving To BTS to move
Why is a resource saturation observed even if the number of AterMux links is the one 120 recommended looking at BSC traffic level ?
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
An example (II)
GPU 1_10
336
GPU 1 (3 aterMux links config)

224 y = 5,7216x + 6,3132
112
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
336
0 0 5 10 15 20 25 30 35 40
224
1 Additional AterMux link Needed
112
GPU 2 (3 aterMux links config)

0 0
10
20
30
40
50
60
70

GPU Architecture reminder
GPU/GP board
Packet Management Unit (PMU): PDCH management PS Paging management Gb stack management SGSN
PPC
BSC
DSP
Packet Transfer Unit (PTU): RLC/MAC layer management

MS BTS
Indicators for GPU/GP limitation control

B9 only
GPU limitation
PMU
PTU
PPC/CPU DSP Power Limitation Memory Limitation Power Limitation Memory Limitation P76a P392a P201 (thr_1 ) Dimensioning P77a P384 P392b P202 (thr_2 ) indicators => P402 (thr ) QoS P105e UL TBF estab P203 P105c indicators P105f BSS Failure P204 P105d (TBF establ)
CPU Cong
BSS Fail
DSP Load
DSP Cong
In Alc_Mono_GPRS_Telecom RNO report MFS parameters: Thr = PMU_CPU_Overload (Default=95%) Thr_1 = DSP_Load_Thr_1 (Default=85%) Thr_2 = DSP_Load_Thr_2 (Default=95%)
GPU/GP limitation detection

GPU limitation Power limitation
PMU CPU load
In case of B8
B9 migration
GPU and P76a > 40% in B8
OR
P402/3600 > 0,1%
DSP CPU load
Max(P201,P202)/3600 > 0,1%
B9 only
Memory limitation
This kind of limitation should be no more observable starting from B9MR1ed6QD2 AND
P392b = 1000 (B9MR1 & B9MR4 for legacy MFS) P392b = 4000 (B9MR4 for Mx MFS)
UL TBF establishment failure rate due to BSS > 3%
P384/3600 > 0,1%

GPU/GP dimensioning method

GPU/GP dimensioning Assessment GPU_for_MS_context_handling (=0/1) GPU_GCH_Capacity GPU_for_Power_Limitation (=0/1) Needed GCHs
+
Workaround on issue no more observed from B9MR1ed6QD2
Number of GPU
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.
GPU/GP dimensioning method

GPU/GP dimensioning Assessment GPU_for_MS_context_handling (=0/1) GPU_GCH_Capacity GPU_for_Power_Limitation (=0/1) Needed GCHs
+
Workaround on issue no more observed from B9MR1ed6QD2
Number of GPU
IfBeing: additional GPU/GP resources are needed, the following operational recommandations apply: GPU_GCH_Capacity the maximum number of GCHs that the GPU can handle, 1. Needed assessment has been done at BSC be handled (for the computation of this If the GCHs the number of GCH resources to level, the required additional resources will be added dedicated to aterMux dimensioning quantity refer to slides in one shot operation ) 2. GPU_for_Ms_context_handling done at GPU/GP level,GPU memory limitation due to a If the assessment has been a quantity equal to 1 if a the adding of additional too big number of a contexts is will be (issue no more observed from B9MR1ed6QD2), GPU/GP boards, for MS given BSC,observed done in an iterative way (1 GPU/GP at once), no additional GPU/GP boards needed because of GPU PS and GPU/GP dimensioning monitoring the consequent impact on the AterMux 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.
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
Reminders
(2/3)
Number of GCHs required per PDCH for a given (M)CS:

Number of required GCHs MCS MCS-1 CS CS-1 CS-2 CS-3 CS-4 UL 0,73 1,00 1,25 1,64 DL 0,73 1,00 1,22 1,60 MCS-2 MCS-3 MCS-4 MCS-5 MCS-6 MCS-7 MCS-8 MCS-9 UL 0,89 1,00 1,33 1,50 1,86 2,36 3,49 4,14 4,49 DL 0,86 1,00 1,28 1,47 1,81 2,31 3,39 4,00 4,39
(3/3)
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:

Min{ Max _ DL _ GCH _ GPU , Max _ UL _ GCH _ GPU , Max _ Capacity N _ ATER _ TS _ MARGIN _ GPU * 4}
Max_Capacity=480 or 1560 as described in previous slide
Example of GPU with DSP congestion

West Europe network example
Needed GCH
448
GCH_GPU_Capacity
35
30
336 25
20 224 15
10 112
DSP cong time
0 06/03/2007 : 00h 07/03/2007 : 00h 08/03/2007 : 00h 09/03/2007 : 00h 10/03/2007 : 00h 11/03/2007 : 00h 12/03/2007 : 00h 13/03/2007 : 00h 14/03/2007 : 00h 15/03/2007 : 00h 06h 12h 18h 06h 12h 18h 06h 12h 18h 06h 12h 18h 06h 12h 18h 06h 12h 18h 06h 12h 18h 06h 12h 18h 06h 12h 18h 06h 12h 18h
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)
GPU_for_MS_context_handling
What 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

GPU_for_MS_context_handling
An example
1200
Average number MS context (P392a)
Max number MS context (P392b)
60,0%
1000
50,0%
800
40,0%
600
30,0%
400
20,0%
200
10,0%
0 03h 06h 09h 12h 15h 18h 21h 03h 06h 09h 12h 15h 18h 21h 03h 06h 09h 12h 15h 18h 21h 03h 06h 09h 12h 15h 18h 21h 03h 06h 09h 12h 15h 18h 21/10/2006 : 00h 22/10/2006 : 00h 23/10/2006 : 00h 24/10/2006 : 00h
0,0%
UL TBF BSS Failure rate
25/10/2006 : 00h
21h
GPU_for_MS_context_handling calculation
Retrieve indicators for 5 working days
P392bBSC =1000 during at least 12% of The observed period
NO
GPU_for_MS_context_handling=0
YES
P392bBSC = 1000 when BSS_fail_ratemax Observed for all days with at least two occurrences of P392bBSC = 1000
NO
YES
Observed QoS acceptable for the customer ?
NO
YES
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
GPU Memory for MS context Cell A
1. New MS context needed in Cell A: NOK 2. New MS context needed in Cell B: OK
GPU Memory for MS context Cell A
Cell B
Cell B
Idle MS context Active MS context
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
GPU Memory for MS context
1. New MS context needed in Cell A: OK 2. New MS context needed in Cell B: OK
GPU Memory for MS context
Idle MS context Active MS context Intra and Inter cell pre-emption mechanisms could lead to an increase of PMU CPU load in GPU/GP
GPU_for_Power_Limitation
PMU CPU load
No field feedback exists, up to now, on this method
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
P402/3600 >0,1% during at least 12% of The observed period
NO
GPU_for_Power_Limitation=0
YES
P402/3600 >0,1% and (max(P105e/P105f) > 1% OR GPU reboots observed during the CPU loaded hours)
NO
YES
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
GPU_for_Power_Limitation
DSP CPU load
No field feedback exists, up to now, on this method
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
Max(P201,P202)/3600 >0,1% during at least 12% of The observed period
NO
YES
Max(P201,P202)/3600 >0,1% and (max(P203/P204) > 1% OR GPU reboots Observed during the CPU loaded hours)
NO
YES
TC
MT120
SMU TRCU TRCU TRCU
speech
MT120
SMU TRCU TRCU TRCU
BSC
TCH TCH
G C H B asic
CS
CS
Air
TRX 3 TRX n
M -EG C H link n
A-ter mux
CS+ PS PS
MFS
GPU board
DSP DSP DSP DSP
A-bis
G CH Extra
B TS
SGSN
GPU board
DSP DSP DSP DSP
Gb
data
Evaluate the required number of Gb TS ( E1 links) per GPU
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
With quantile=99,9%
Re quired _ Gb _ Traffic = Measured _ Gb _ Traffic + 15% M arg in Measured _ Gb _ Traffic = Gb _ resources _ busy _ time data _ volume 1 Max( P 45, P 46) 1 = = 3600 Gb _ TS _ bandwith 3600 [64kbit / s ] / 8 3600
Where: - P45 (respectively P46) is the number of kilo bytes received from the SGSN (respectively sent to the SGSN) at PVC level
BSS PS Dimensioning: parameter checking
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)
Main recommendations on parameter setting

A focus on Ater usage related parameters
1. Available GCH (Available GCH x Ater_Usage_Threshold) > N_ATER_TS_MARGIN_GPU 2. 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.
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
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 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

A focus on Gb interface related parameters (I)
Bit rate ACCESS_RATE_BC EIR PVC Gb (E1) link CBS T time EBS NIR CIR
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)

A focus on Gb interface related parameters (II)
Bit rate ACCESS_RATE_BC EIR EBS NIR CIR
CBS T time
CIR = (CBS * 8) / T EIR = [(EBS + CBS)*8] / T CIR <= NIR <= EIR <= ACCESS_RATE_BC
Mandatory Rule Recc. Rule
If Direct MFS-SGSN connection: CIR = NIR = 0 and EIR = ACCESS_RATE_BC
Warning: the default value for CIR / NIR is 0 Update this parameter if no direct MFS-SGSN connection
PS dimensioning
Parameters (I)
HMI name
Definition
Subsystem
Instanc e
OMC-R access
Type
Def value
Range
Unit
MAX_EGPRS_MCS
Maximum Modulation and Coding Scheme used for EGPRS traffic in the cell. Maximum coding scheme used for GPRS traffic in the cell.
MFS
Cell
Changeable
Number
[1,9]
None
MAX_GPRS_CS
BSC
Cell
Changeable
Number
[1,4]
None
EN_EGPRS
Enables/Disables EGPRS traffic in the cell.
BSC
Cell
Changeable
Flag
[0,1]
None
NEW : N_EXTRA_ABIS_TS MIN_PDCH
Number of extra Abis (64k) timeslots configured for a BTS. Minimum number of master and slave PDCHs that are always allocated to the MFS. Maximum number of slave and master PDCHs that can be allocated to the MFS in the cell. Maximum number of slave and master PDCHs that can be allocated to the MFS when the CS traffic is high. This 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) 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).
BSC MFS
BTS Cell
Changeable Changeable
Number
0 0
[0,60]
None
Number MFS Cell Changeable Number MFS Cell Changeable Number MFS MFS Changeable Flag 0 0 0
[0,127]
None
MAX_PDCH
[0,127]
None
MAX_PDCH_HIGH_LOAD
[0,127] [0,1]
None None
NEW : EN_FAST_INITIAL_GPRS_ACCESS
NEW : N_GCH_FAST_PS_ACCESS
MFS
MFS
None (DLS)
Number
[1,5]
None
PS dimensioning
Parameters (II)
HMI name
Definition
Subsystem
Instanc e
OMC-R access
Type
Def value
Range
Unit
NEW : 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 established on that TRX were released). - 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. Default 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.
MFS
BSS
Changeable
Timer
[1,100]
sec
NEW : T_GCH_Inactivity_Last
MFS
BSS
Changeable
Timer
20
[1,200]
sec
GPRS_MULTISLOT_CLASS_DEF_V ALUE
MFS
BSS
Changeable
Number
[1,2,4,8]
None
Ater_Usage_Threshold
Threshold (percentage of used Ater nibbles, in a GPU) above which the Ater usage is said high.
MFS
BSS
Changeable
Number
70
[1,100]
PS Dimensioning
Parameters (III)
HMI name
NEW : GCH_RED_FACTOR_HIGH_ATER _USAGE NEW : N_ATER_TS_MARGIN_GPU
Definition
Reduction factor of the number of GCHs targeted per PDCH, when the Ater usage is high.
Subsystem
MFS
Instanc e
cell
OMC-R access
Changeable
Type
Number
Def value
0.75
Range
[0,1,1]
Unit
none
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. Note : In case of non-Evolium BTS, those are PDCHs that will be established instead of GCHs. Average bitrate per PDCH for non-Edge capable terminals in this cell
MFS
BSS
Changeable
Number
[0,10]
none
R_AVERAGE_GPRS
MFS
cell
Changeable
Number
12000
[0,20000]
bit/s
R_AVERAGE_EGPRS
Average bitrate per PDCH for Edge capable terminals in this cell
MFS
cell
Changeable
Number
30000
[0,59200]
bit/s
PMU_CPU_Overload
Threshold above which a GPU enters the PMU CPU overload state.
MFS
GPU
None (DLS)
Number
95
[0,100]
NEW: DSP_LOAD_THR_1
Threshold beyond which a given DSP is considered as "loaded" in terms of CPU load by RRM.
MFS
MFS
None (DLS)
Threshol d
85
[1,95]
NEW: DSP_LOAD_THR_2
Threshold beyond which a given DSP is considered as overloaded in terms of CPU load by RRM.
MFS
MFS
None (DLS)
Threshol d
95
[1,95]
PS Dimensioning
Parameters (IV)
HMI name
K_GSL (MFS)
Definition
Maximum number of outstanding I frames on a GSL link.
Subsystem
MFS
Instanc e
MFS
OMC-R access
None (DLS)
Type
Number 7
Def value
Range
[1,16] in B9MR1 [1,32] in B9MR4
Unit
none
NEW: ACCESS_RATE_BC B8: FR_Capacity
Physical access rate of the Frame Relay bearer channel.
MFS
BC
Displayed
Number
64
[64,1984]
Kbit/s
CBS
Commited Burst Size.
MFS
PVC
Changeable
Number
[0,248]
Kbytes
EBS
Excess Burst Size.
MFS
PVC
Changeable
Number
None
[0,248]
Kbytes
NIR
Normal Information Rate.
MFS
PVC
Changeable
Number
[0,1984]
Kbit/s
CIR
Committed Information Rate.
MFS
PVC
Changeable
Number
[0,1984]
Kbit/s
BSS Dimensioning: Overview on available documentation and tools
Network Architecture ASSESSMENT
Several tools exist for supporting you

For PARAMETER CHECK: SMART MCT, AMT .NET RNL files Smart MCT excel export files
Architecture CHECK Parameter CHECK Dimensioning Methods RUN
In order to check DLS parameters it is necessary to retrieve BSC/MFS DLS
For ARCHITECTURE CHECK: AMT .NET AMT v5 script OMC AMT .NET excel export files
RNL & EML files For DIMENSIONING METHODS RUN: 2G Traffic Tool (B9 only)
TSL script 13 .txt files
Prerequisite: NPA or MPM

excel export files
NPA / OMC
2G Tool
Excel templates
RNO BestOf or manual search
Prerequisite: RNO RNO Excel
RNO excel export files

Several tools exist for supporting you

A focus on dimensioning method implementation
Dimensioning task Method detail 2G Traffic Tool X X X traffic Method1 traffic Method2 GSL load on bandwidth GSL load on number of msg/sec GPU/GP dimensioning Traffic method Reference @ 12 links per GP Traffic method Reference @ 10 links per GP X X X X X X X X X X Excel Templates
Air Interface
RTCH / PDCH dimensioning Paging load estimation
Abis interface AterMux interface
Gb dimensioning
Power limitation and MS context Input data Input data limitation imported but imported but manual manual analysis analysis needed needed X X
Intranet available information

Youll find all usefull instruments for B9 dimensioning on the following web page: B9 Release web page (*)
http://aww.quickplace.alcatel.com/QuickPlace/mnd_pcspsf/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
Questions
& Answers
www.alcatel-lucent.com

B9 Archi Dim Methods Workshop June2007

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

B9 Archi Dim Methods Workshop June2007

Enviado por

Direitos autorais:

Formatos disponíveis

Network Architecture ASSESSMENT Architecture CHECK Parameter CHECK Dimensioning Methods RUN

B9 BSS Dimensioning Methods

GSM Network Engineering Team

1 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Agenda for 6th of June

2 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Enhanced Transmission Resource Management overview

3 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Enhanced transmission resource management

This was obtained through the following new features:

4 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

M-EGCH Statistical Multiplexing

Unused TS: no Abis resource required

Single Packet pipe

5 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

M-EGCH Statistical Multiplexing

B8: one EGCH per RTS

B9: one M-EGCH link for the whole TRX

1 to 5 GCHs depending on the TRX class

M-EGCH Statistical Multiplexing

Number of GCHs required per PDCH for a given CS:

With Statistical Multiplexing, nb of GCH has not to be rounded-up

M-EGCH Statistical Multiplexing

Number of GCHs required per PDCH for a given MCS:

With Statistical Multiplexing, nb of GCH has not to be rounded-up

M-EGCH Statistical Multiplexing

9 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Dynamic Abis Allocation

10 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Dynamic Abis Allocation

B8: static Abis allocation

B9: dynamic Abis allocation

Dynamic Abis Allocation

12 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Dynamic Abis Allocation

All the extra Abis nibbles of the BTS:

13 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Dynamic Abis Allocation

M-EGCH link 1 M-EGCH link 2

Dynamic A bis allocation

14 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Ater Resource Management

15 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Ater Resource Management

GPU 64k Ater TS margin: Aim:

16 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Ater Resource Management

17 |BSS Architecture | June 2007

All Rights Reserved Alcatel-Lucent 2006, #####

Ater Resource Management

18 |BSS Architecture | June 2007