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


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)

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




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




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




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


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




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

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.




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




� In B8, a lot of Abis nibbles were “wasted”

� An example:




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




� 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


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


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.


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


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.


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)


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.


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


Counter Based Dimensioning Rules

Architecture CHECK

Parameter CHECK




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


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


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



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


PS traffic


M -EG CH link n

BTS

Dynam ic Ab is


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


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


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)


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


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)


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?



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



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


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


SDCCHTCH /PDCH

TCH /PDCH

TCH /PDCH

TCH /PDCH

TCH /PDCH

TCH /PDCH

TCH /PDCH






SDCCHTCH /PDCH

TCH /PDCH

TCH /PDCH

TCH /PDCH

TCH /PDCH

TCH /PDCH

TCH /PDCH






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)


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)


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

�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



B9 Design:


� 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


� Calculation:

– TS0 = 1 TS

–Basic Abis TS = 2 Abis TS (per TRX) * 6 TRX (3 cells) = 12 TS

–RSL/OML Abis TS = 2 TS


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



B9 Design:


� 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


� Calculation:

– TS0 = 1 TS

–Basic Abis TS = 2 Abis TS (per TRX) * 6 TRX (3 cells) = 12 TS

–RSL/OML Abis TS = 2 TS


–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


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 !!!



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:

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


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


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



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



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


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


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%


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


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


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


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


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



Abis dimensioning



Gb dimensioning

•QoS feature impact not taken into account



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


PS traffic


M -EG CH link n

BTS

Dynam ic Ab is


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


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


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%


� 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


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)



AterMux dimensioning

Assessment for GSL traffic


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)


(GSL traffic)

Method applied at BSC level







GPU/GP dimensioning

Assessment

# Needed GCH

max


# AterMux PS per GPU (estimated at BSC level)

# Needed GSL links

# GSL links(at least 2 per GPU/GP)

÷

AterlinkGCH_Capacity

# AterMux PS


(user traffic)


(GSL traffic)

Method applied at GPU/GP level

If #GPU/GP=1

2 max


(user traffic)


(GSL traffic)

# AterMux PS at BSC level

# Needed GSL links at BSC level

New #GPU/GP at BSC level


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:


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.


AterMux PS assessment method – Some Examples (2/3)

Example 2:



� #AterMux PS per BSC = 400/112 = 4




� GPU2– #Needed GCH GPU2 = 240– #Needed GPU/GP = 1– #AterMux PS per GPU/GP = Max (240 / 112, 2) = 3


two GPUs

2) If the reshuffle operation has not the wanted effect, add 1 AterMux PS to

GPU2.


AterMux PS assessment method – Some Examples (3/3) Example 3:



� #AterMux PS per BSC = 500 / 112 = 5




� GPU2– #Needed GCH GPU2 = 300– #Needed GPU/GP = 2


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


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


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


How to estimate the number of GSL messages per second (II)



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



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


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%



Feature

activation

Traffic

evolution

Stable

Network

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



estimation

P100c P38b


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



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



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


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



y = 5,3905x + 21,057

0

112

224

336

448

0 10 20 30 40 50 60 70 80


METHOD 2:

Measured PDCH traffic

Measured

GCH trafficResourcessaturation


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



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



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



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



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



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


*1,64)]/1a

[1,64]/1b


*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



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


Feature

activation

Traffic

evolution

Stable

Network

Required_GCH_Traffic estimation Increase Factor Required_GCH_traffic


y = 5,3905x + 21,057

y = 1,9111x + 20,368

0

112

224

336

448

0 10 20 30 40 50 60 70 80


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



y = 1,798x + 7,6258

y = 2,9487x + 7,6258

0

56

112

168

224

0 5 10 15 20 25 30 35


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



y = 1,798x + 7,6258

y = 2,9487x + 7,6258

0

56

112

168

224

0 5 10 15 20 25 30 35


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


Feature

activation

Traffic

evolution

Stable

Network


Feature

activation

Traffic

evolution

Stable

Network



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


(1)

(1’)

(2)

(3)

(4),(2’)


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




Abis dimensioning



Gb dimensioning



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


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


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


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)

+


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


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


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


GPU_GCH_Capacity calculation (2/3)Reminders


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


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)


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


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)


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





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


2. New MS context needed in Cell B: OK


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



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


GPU_for_Power_Limitation PMU CPU load


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



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


GPU_for_Power_Limitation DSP CPU load


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


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



Abis dimensioning



Gb dimensioning




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


PS traffic


M -EG CH link n

BTS

Dynam ic Ab is


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


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%


BSS PS Dimensioning: parameter checking

Architecture CHECK

Parameter CHECK




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


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


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


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)


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)


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)


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)


BSS Dimensioning: Overview on available

documentation and tools


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




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


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


?Questions& Answers


www.alcatel-lucent.com

B9 Archi Dim Methods Workshop June2007

Documents

Transcript of B9 Archi Dim Methods Workshop June2007