Professional Documents
Culture Documents
BSS Dimensionning B10
BSS Dimensionning B10
Pre-distribution:
NE Velizy NE Timisora NE Portugal NE Egypt
F. Colin Cristian I. Inta Pedro Henriques Wessam Yanni
T. Plantier E. Marza Tiago Dias
M. Talayssat João Frade
LM. Palumbo
Abstract: The aim of this document is to describe BSS architecture configuration rules &
dimensioning processes in Alcatel release B10. It is recommended to be the guideline for
RNE & TPM people who are involve in BSS architecture aspect.
Key words: BTS, BSC, TC, MFS/GP(U), Abis, AterMUX, A, and Gb; B10 release
GSM TIS
DD-MM-YY: Signature: DD-MM-YY: Signature:
All Alcatel system details given in this document are for your comfort only. The system
information may not reflect the latest status of the equipment used in your project.
Please consult in addition to this document the latest product descriptions!
Figure 26: Example of Abis TS usage for 1 BTS/4 TRX – 16K Static Multiplexing ............. 51
Figure 30: Example of Abis TS usage for 1 BTS/4 TRX – 64K Statistical Multiplexing....... 53
Figure 32: Example of Abis TS usage for 1 BTS/4 TRX – 16K Statistical Multiplexing....... 55
Figure 46: Abis and Ater allocation on LIU boards / BSC capacity........................................ 75
Figure 48: BTS position & configuration – design BSC area step 1 ....................................... 77
Figure 49: Transmission planning & BSC position – design BSC area step 2 ........................ 78
Figure 50: BSC area definition – design BSC area step 3 ....................................................... 78
Figure 62: SS7 message length (in bytes) according to GSM event........................................ 97
Figure 63: Difference between Exact busy hour, NPO busy hour and Peak traffic................. 99
Figure 70: The 1st MFS generation (A9135 MFS) Architecture............................................ 120
Figure 80: Gb interface configuration (from 3BK 09559 LAAA EBZZA) ........................... 139
Table 10: Recommended SDCCH configuration for a standard cell – only FR TRXs........... 35
Table 14: RLC data block size for each (M) CS ...................................................................... 43
Table 36: The 1st MFS generation (A9135 MFS) Capacity................................................... 122
References:
[1] 3BK 17430 5000 PGZZA BSS Configuration Rules release B10
Enhanced Transmission Resource Management –
[2] 3BK 10204 0608 DTZZA
Release B9
Introduction of DRFU on G1 MK II BTS Principle of
[3] 3BK 17025 0062 DSZZA
Method
[4] 3BK 17025 0061 DSZZA Introduction of DRFU on G2 BTS Principle of Method
[5] 3BK 11210 0157 DSZZA G3 BTS Architecture and Principles
[6] 3BK 11210 0328 DSZZA BTS G4 Architecture and Principles
[7] 3DC 21083 0001 TQZZA EVOLIUM™ A9100 Base Station Product description
[8] 3BK 10204 0511 DTZZA SFD: Dynamic SDCCH allocation
[9] 3DF 01903 2810 PGZZA BSS B8 Dimensioning Rules
Dimensioning Rules for CS and PS traffic with BSS
[10] 3DC 20003 0019 UZZZA
Software Release B10
GSM/GPRS/EDGE Radio Network Design Process for
[11] 3DC 21150 0323 TQZZA
ALCATEL BSS Release B10
[12] 3DC 21016 0005 TQZZA A9135 MFS Product Description
[13] 3DF 00995 0005 UAZZA GPRS/E-GPRS Radio Network Planning Aspects
[14] 3BK 11203 0100 DSZZA GPRS resource usage and dimensioning B8 release
[15] 3BK 09722 JAAA DSZZA GPRS management functional specification
[16] 3BK 11206 0476 DSZZA BSC abbreviations Release B9
[17] 3DF 019032911 VAZZA B9: BSS Architecture Service Guideline
[18] 3DC 21144 0120 TQZZA Gb over IP in Release B10
[19] 3BK 10204 0028 DTZZA Multiple CCCH
Abbreviations:
Refer to [16].
The dimensioning method due to migration from B8 to B9 release is not detailed in this
document (please refer to [17] document).
Nevertheless, a short presentation about BSS architecture impacts with the introduction
of new B9 features is presented in Annex.
Um Abis
BTS A NSS
AterMUX CS (CS traffic)
MFS Gb
AterMUX PS
BTS
GSS
BSS (CS+PS traffic) (PS traffic)
As presented in shown in Figure 1, the BSS consists of several network elements and
interfaces.
1 MSC (Mobile Switching Center) is a main network element of the NSS having connection to the BSS.
Each TS of a TRX can provide a channel with different codec rates (FR, EFR, HR and AMR)
available for CS traffic, while GPRS CS1/CS4 and EDGE MCS-1/9 available for PS traffic.
As a radio TS is dynamically allocated to serve either CS or PS traffic, the TS is called as
TCH while it supports CS traffic; otherwise called as PDCH while it supports PS traffic.
2.1.2.4 A interface
This interface, connecting TC and MSC, is supported by 2Mbps PCM links (64kbps * 32 TS).
One 64kbps channel on A is corresponding to one 16kbps channel on AterMUX – TC is
responsible for this channel speed conversion.
The A trunk carries up to 31 traffic channels identified by a CIC (Circuit Identification Code).
A Interface
TS 0 Frame Synchronization
TS 1 CIC 1
TS 2 CIC 2
TS 3 CIC 3
: :
: :
: :
: :
TS 30 CIC 30
TS 31 CIC 31
TS : 64 Kbits/sec
2.1.2.5 Gb interface
The Gb interface connects the MFS with the SGSN2 (Serving GPRS Support Node), which is
a main network element of the GSS having connection to the BSS.
When using Frame Relay stack, the Gb interface (GboFR) is supported by 2Mbps PCM links
(64kpbs * 32 TS).
When using UDP/IP/Ethernet stack, the Gb interface (GboIP) is supported by a Gigabit
Ethernet link (GE).
2 SGSN (Serving GPRS Support Node) is a main network element of the GSS having connection to the BSS.
2.2.2 Goal
It is to define the BSS capacity and topology, which is appropriate and necessary to be able
to support the real network traffic or to fit new requirements for network evolution.
2.2.3 Category
According to different network states, the BSS architecture services can be classified into:
1) Network Architecture SETUP
This service is providing the BSS architecture design for a new network.
2) Network Architecture ASSESSMENT
For an existing network, it is important to perform this service to check periodically
the network performance from architecture point of view.
3) Network Architecture EVOLUTION
The BSS architecture should be re-designed in case of some network evolutions e.g.
network extension (to be adapted to a forecasted traffic scenario) and new network
feature activation (GPRS CS 3-4 or EDGE, for instance).
Network Architecture
Setup Initial
Network Architecture
Assessment Steady
Network Architecture
Evolution Developing
(2) Design/Re-design
(2a) BSC/LAC/RAC Areas
FINISH
Fore more details, please refer to section 3.3.3.1 for BSC area design, section 3.3.4 for
LAC design and section 3.3.5 for RAC design.
BSC MFS/GP(U) TC
Type A9120 BSC, A9130 BSC A9135 MFS, A9130 G2 TC, G2.5 TC
MFS (A9125 Compact TC)
Configuration - Conf 1, 2, 3, 4, 5 or 6 for Nb of GP(U) boards - Nb of TC boards
A9120 BSC dedicated to each dedicated to each BSC
BSC
- Stand Alone / Rack shared - Nb of TC racks
configuration with 200, 400, Nb of MFS racks
600, 800 or 1000 TRX for
A9130 BSC
Table 1: BSC-MFS/GP(U)-TC (re) design
Fore more details, please refer to section 3.3 for BSC configuration, section 3.5 for TC
configuration, and section 3.6 for MFS configuration.
Fore more details, please refer to section 3.2 for Abis, section 3.4 for AterMUX & A-
interface and section 3.7 for Gb.
Recommendation/Threshold
(3) Assessment
- Identify bottle necks
- Identify need of new resources / new configuration
FINISH
BSS interfaces:
• Abis dimensioning (for more details, please refer to section 3.2.2)
• AterMUX dimensioning (for more details, please refer to section 3.4.4)
• A dimensioning (for more details, please refer to section 3.4.4.1)
• Gb dimensioning (for more details, please refer to section 3.7.2)
The assessment can identify the existing bottleneck that implies the lack of resources or
unbalanced resource usage.
Therefore, the proposed solutions should be implementing new resources and/or new
configuration and probably parameter modification.
Anyway, it is also possible to use mCCCH feature when master PDCH is implemented.
The mCCCH feature that can be implemented in both G2 BSC and Mx BSC, and has impacts
for:
Telecom: main impact on Paging and Access Control entity
O&M: impacts include the introduction of a new channel type CCH (BCCH +
CCCH) and change of the TRX mapping algorithm
2.3.2 Gb over IP
From B10 MR2 only, the Gb interface can be transported either on Frame Relay (GboFR) or
IP (GboIP) protocol stacks.
The feature Gb interface over IP (GboIP) is transported over a standardized protocol stack
according to 3GPP R6 (UDP/IP/Ethernet).
This feature is optional and allows the backhauling of Gb traffic over IP networks (IPv4); the
traffic flows from/to all GP(U) between MFS and SGSN can be aggregate in one single flow.
So the dimensioning of the IP network – i.e. handling GboIP traffic – shall be done MFS per
MFS instead of a per GP(U) dimensioning basis.
Indeed the IP bandwidth is dynamically shared between all GP(U) within one MFS, and there
is no service differentiation between handled traffic flows (signalling, streaming, best effort).
However, the IP network between SGSN and MFS shall provide enough bandwidth to pass all
aggregated flows.
The feature option, which has to be chosen per a BSC basis, is available and supported on:
• A9130 MFS without any hardware impact (IP Ready)
• A9135 MFS equipped with DS10 systems and the replacement of the switch rack by 2
new GE switches (OS-LS-6224).
• There is no GboIP support for A9135 MFS with AS800 systems
BSS1
BSSG P
NS
FR Frame Relay N etwork
BSS2
BSSG P
NS
FR
BSS3
SG SN
BSSG P
NS
U D P/IP
BSS4
BSSG P
NS
U D P/IP
IP Network
Gb
The following table gives the configuration data of each MX BSC configuration type.
2600 (B9)
600 TRX 2700 (B10) 255 264 176 30 18
The HSL mode relies on the transport of SS7 signalling over a couple of 2Mbps PCM links:
• Whatever the traffic load is
• For redundancy and load sharing purposes
• To double the BSC signalling throughput (for 4500Erl, the SS7 load is 33%)
• HSL links are directly connected to MSC, without passing through TC
BSC TC MSC
ATERMUX Interface A
HSL 1
HSL 2
3.1 BTS
The area covered by a BSS is divided into cells and each cell is managed by a BTS.
Each BTS consists of radio transmission and reception devices including antennae and signal
processing equipment for the Air Interface.
BTS
Generation
Twin
GPRS GPRS GPRS GPRS CS-1, CS-4
CS-1, CS-2 CS-1, CS-2 CS-1, CS-4 EDGE MCS-1, MCS-9
Extension / Reduction
Configuration
BTS Physical Logical
Min Max Min
G2 1 TRE 1 Sector: 8 TRE 1 TRE 1 TRE
Data in this table, based on [1]
Table 3: Configuration – G2 BTS
From B9 support, Evolium BTSs include G3 BTS, G3.5 BTS (which is G3 BTS with
new power supply modules) and micro BTS M4M. See their configurations in Table 4.
Extension/Reduction
Configuration
BTS Physical Logical
Min Max Min
Evolium BTS
1 TRE Up to 18 TRE (1 to 6 sectors) (since B9MR4) 1 TRE TRE
(G3 / G3.5)
M4M
2 TRE Up to 6 TRE (1 to 6 sectors) 2 TRE 1 TRE
(micro BTS)
Data in this table, based on [1]
Table 4: Configuration – Evolium BTS
Extension/Reduction
Configuration
BTS Physical Logical
Min Max Min
Evolium BTS
1 TRE Up to 18 TRE (1 to 6 sectors) (since B9MR4) 1 TRE 1 TRE
(G3.8 / G4.2)
Evolium BTS
1 TRE Up to 24 TRE (1 to 6 sectors) (since B9MR4) 1 TRE 1 TRE
(G5)
M5M
2 TRE Up to 12 TRE (1 to 6 sectors) 2 TRE 1 TRE
(micro BTS)
Data in this table, based on [1]
Table 5: Configuration – Evolium Evolution
N.B. In case of BTS housing TWIN TRA modules and G3 TRX a maximum number
of 12 TRX is allowed.
AMR x x x x x x
EFR x x x x x x
GPRS (CS-1 , CS- 2) x x x x x x
Traffic
GSM 1800 x x x x x
GSM 1900 x x x x
850/1800 x x x
850/1900 x x x
band
Multi
900/1800 x x x x
900/1900 x x x
The EDGE TRA is the first Evolium transceiver that is EDGE capable.
The Twin TRX module is a module that can be used in two different modes
• Capacity mode that generates two functional TRX (16 RTS), in the same or different
cells, with same radio performances as TRA Medium Power (45W GMSK in 900MHz),
• Coverage mode (Tx Diversity mode) that generates a single functional TRX (8 RTS)
allowing either:
Higher Output Power due to Tx diversity ("air coupling") usage (113W to 175W
GMSK in 900MHz, and 88W to 136W GMSK in 1800MHz
Higher Sensitivity (-117.4 to -121dBm) due to 4Rx Uplink Diversity usage (2Rx
Diversity also possible)
Extended Cell:
Its configuration is a BTS with up to 4 TRX in the inner cell and up to 4 TRX in the outer cell.
M4M and M5M do not support extended cell configurations.
Only one extended cell per BTS is possible.
Frequency Hopping:
The Table 9 shows the hopping types supported in B10.
Hopping Type Supported in B9
Non Hopping (NH) x
Base Band Hopping (BBH) x
Radio Hopping (RH) * -
Non Hopping / Radio Hopping (NH/RH) x
NH/RH with Pseudo Non Hopping TRX x
BBH with Pseudo Non Hopping TRX x
Data in this table, based on [1]
* RH works only with M1M and M2M that are now obsolete.
Table 9: Frequency Hopping supported in B10
Principle:
Static SDCCH sub-channels are defined to handle normal SDCCH traffic.
Dynamic SDCCH sub-channels are defined to handle high SDCCH traffic.
Main Rules:
At least one static SDCCH/8 or SDCCH/4 timeslot on BCCH TRX must be configured in a cell.
Combined SDCCHs (SDCCH/4 + BCCH) are always static.
The total number of SDCCH sub-channels configured on static or dynamic SDCCH TS or on a
BCCH/CCCH TS (CCCH combined case) must not exceed 24 sub-channels per TRX and 88
sub-channels per cell.
In order to avoid incoherent allocation strategies between SDCCH and PDCH, a dynamic
SDCCH/8 TS cannot be a PDCH.
BTS with DRFU do not support dynamic SDCCH allocation.
In A9130 BSC Evolution it is not allowed more than one SDCCH TS per TRX.
Recommended default number of SDCCH and configuration are presented in Table 10.
Number of SDCCH sub-channels
Number of TRXs BCCH Combined
Total SDC SDD
1 Yes 12 4 8
2 Yes 12 4 8
2 No 24 8 16
3 No 24 8 16
4 No 32 8 24
5 No 32 8 24
6 No 32 8 24
7 No 40 16 24
8 No 40 16 24
9 No 48 16 32
10 No 48 16 32
11 No 48 16 32
12 No 56 16 40
13 No 56 16 40
14 No 64 24 40
15 No 72 24 48
16 No 72 24 48
Data in this table, based on [8]
Table 10: Recommended SDCCH configuration for a standard cell – only FR TRXs
Remarks:
1) SDC means Static SDCCH, SDD means Dynamic SDCCH, and Max presents the
maximum number of SDCCHs (SDC+SDD) that may be allocated in a cell.
2) Up to 16 TRXs are possible to be configured for a cell – thanks to shared cell feature.
3) For one TRX, dynamic SDCCH are over-dimensioned because of the granularity of 8.
According to Alcatel traffic model, all dynamic SDCCH will not be used.
4) An additional dynamic SDCCH/8 must be provided for each DR TRX (these are
expected mainly on small cells).
5) For some particular cells with high (LU and/or SMS) signalling load, the operator will
probably need to customize the number of SDCCHs (different from the
recommendation) according to his requirements; otherwise the SDCCH dimensioning
should be applied (please refer to section 3.1.3.1).
Required =
Under-dimensioning Over-dimensioning
Increase installed BTSs OK Decrease installed BTSs
When mCCCH feature is enabled, a second CCCH time slot shall be taken into consideration
when computing the required number of BCCH, SDCCH and TCH/PDCH timeslots.
Methodology:
The process of SDCCH dimensioning is presented in Figure 17.
Required
SDCCH Traffic Nb of required
Erlang B SDCCH sub-
channels /
GoS: timeslots
% SDCCH blocking
INPUT
The required SDCCH traffic is computed as below formula.
Measured _ SDCCH _ traffic
Re quired _ SDCCH _ traffic =
1− Min(%SDCCH _ cong , 30%)
Note: 30% is defined as the max congestion rate to be considered because several congestions can be
re-produced from one given user trying to access the network several times.
The other input is Grade of Service (GoS), which is defined by the required SDCCH
congestion rate (pSDCCH).
Normally GoS should be given or agreed by the Mobile Operator.
The typical value for the required SDCCH congestion rate is 0.5%.
METHOD
Concerning only CS traffic, the statistical law Erlang B is used during the dimensioning
process to determine the necessary resources versus the traffic and the target GoS.
As SDCCH is associated to CS traffic only, Erlang B can be applied to calculate the
required number of SDCCH sub-channels according to required SDCCH traffic and the
target congestion rate.
OUTPUT
Number of required SDCCH sub-channels
= Erlang B (Required_SDCCH_traffic, pSDCCH)
Then,
Number of required SDCCH Timeslots
Nb of required SDCCH sub-channels / 8; for non- BCCH combined cell
=
(Nb of required SDCCH sub-channels – 4) / 8; for BCCH combined cell
Assessment:
When % SDCCH congestion (of any cell) > pSDCCH, the SDCCH re-dimensioning is
needed.
Methodology:
The process of TCH/PDCH dimensioning is presented below.
CS service
input data Total
Kaufmann-
Robert required TS
Algorithm for TCH and
PS service PDCH
input data
INPUT
(1) CS service input data:
CS Traffic Intensity in Erlang:
The CS traffic intensity is calculated separately between Full Rate (FR) and Half
Rate (HR) Traffic.
The calculation will take into account the real measured traffic and additional margin
from congestion rate.
Note: 30% is defined as the max congestion rate to be considered because several congested calls
can be re-produced from one given user trying to access the network several times.
Then,
Full Rate CS traffic Intensity is:
FR _ Successful _ Traffic MC 380acell
ρ FR = =
1 − FR _ Cong _ Per 3600 × ( 1 − FR _ Cong _ Per )
CS Bandwidth:
1 TS; for FR
0.5 TS; for HR
CS GoS (as requirement): Blocking Probability rate = 2 %, for instance
Measured _ PS _ traffic
Re quired _ PS _ traffic =
1− Min(%TBF _ radio _ cong , 30%)
Note: 30% is defined as the max congestion rate to be considered because several congestions can be
re-produced from one given user trying to access the network several times.
Where:
P 451b
Measured _ DL _ PS _ traffic =
3600
P 451a
Measured _ UL _ PS _ traffic =
3600
P14
%DL _ TBF _ radio _ cong = × 100 %
P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
P 27
%UL _ TBF _ radio _ cong = × 100 %
P 62a + P 62b + P 62c − P 438c + P 507
Note: MAX_DL(UL)_TBF_SPDCH is the O&M parameter, which defines the maximum number of
Down (Up) link (E)GPRS TBFs per Slave PDCH.
d
8 × ∑ P 20 x × RLC _ Block _ Sizex + ∑ P 55 x × RLC _ Block _ Sizex + ∑ P 20 x
m n
= x =a x =a x =f
1000 × P 38e
d n
8 × ∑ P 21x × RLC _ Block _ Sizex + ∑ P 57 x × RLC _ Block _ Sizex + ∑ P 21x
m
x =a x =f
=
x =a
1000 × P 38 f
Where:
Channel Coding scheme RLC data block size in bytes
CS-1 22
CS-2 32
CS-3 38
CS-4 52
MCS-1 22
MCS-2 28
MCS-3 37
MCS-4 44
MCS-5 56
MCS-6 74
MCS-7 (sent of 2 blocks) 2*56
MCS-8 (sent of 2 blocks) 2*68
MCS-9 (sent of 2 blocks) 2*74
Table 14: RLC data block size for each (M) CS
Remark: PS throughput (in kbps) can also be defined by the target throughput per PDCH,
which probably can be given by the operator e.g. 30kbps for DL & UL (this information
should also be provided in R_AVERAGE_GPRS and R_AVERAGE_EGPRS parameters).
METHOD
In case of the TS sharing between two services (CS and PS), the Knapsack traffic model
with the Kaufmann-Robert algorithm is used to define the total number of required TS
for TCH/PDCH.
Thus, the output result of the TCH/PDCH dimensioning is only the number of TSs
needed for the mixed CS and PS traffic. It couldn’t take into account configuration
parameters (MIN_PDCH, MAX_PDCH, and MAX_PDCH_High_Load) controlling the
sharing of radio resource between these two traffics.
However, we can apply the number of TSs needed (the result from this dimensioning
process) as a range of the zone [MIN_SPDCH, MAX_SPDCH].
Then, this result will be added by numbers of TSs that operator wants to reserve for CS
and for PS to get the final number of TSs needed for CS and PS traffic in the cell.
Assessment
The following diagram presents the TCH/PDCH assessment process.
Nb of “required” Nb of “installed”
TCH/PDCH TSs TCH/PDCH TSs
Required = Installed
Under-dimensioning Over-dimensioning
“Increase” installed TCH/PDCH OK “Decrease” installed TCH/PDCH
To adjust the number of the installed radio TSs according to the required ones, it can
happen the case of the low efficiency resource utilization, for example, one or two
additional TSs require one new TRX!
Thus, the RNE has to define the “optimized” number of required radio TSs to trade-off
between the returned gain and the investment cost.
Up to 15 BTSs
BTS BTS BTS per
1 Abis Chain
Abis Abis Abis
BSC
• Star topology
Each BTS is connected to the BSC directly; an Abis link is dedicated to a BTS.
A star topology can be considered as a particular case of a chain topology with only
one BTS.
This topology is well suited to support BTSs with large configuration and is also
flexible for TRX expansion.
BTS Abis
Abis
Only 1 BTS
Abis per
1 Abis Star
Abis
BTS
BSC
Up to 7 BTSs
BTS BTS BTS
per
1 Abis Ring
Abis Abis Abis
Abis
BSC
BSC
The GSM Recommendation 08.52 defines 2 logical links between the BTS and
the BSC:
• Radio Signalling Link (RSL) is used for supporting traffic management
procedures (MS to network communication).
• Operation & Maintenance Link (OML) is used for supporting network
management procedures.
For details about Abis resource management for RSL/OML, please refer to section 0.
3) Extra Abis TS
On Abis interface, two types of 64kbps TS are considered:
Basic Abis TS: handle OML, RSL and traffic TS
Extra Abis TS: handle only supplementary GPRS (CS-3/CS-4) and EDGE
(MCS-1 to MCS-9) nibbles when needed.
In B10 release, the maximum number of extra Abis TS can be configured through
the new OMC parameter N_EXTRA_ABIS_TS.
Qmux Channel
Used by the BSC to manage Remote
Qmux TS0 Other TS except TS0
Transmission Network Elements.
BTS Channels
TCH/GCH Other TS except TS0 GSM (GPRS CS-1/CS-2) traffic
LAPD channel for BTS (1 OML per BTS)
LAPD Other TS except TS0
LAPD channel for TRX (1 RSL per TRX)
Extra Abis TS Other TS except TS0 To support GPRS CS-3/CS-4 and EDGE
Data in this table, based on [9]
Table 15: Abis Channel Types
(*) Improvement with EVOLIUM™ BTS: In case all BTSs of a chain are EVOLIUM™ BTSs, and if TS0 transparency is used, then the
time-slot used for transmission supervision (QMUX) can be saved (because the OML of EVOLIUM™ BTS supports also the transmission
supervision information).
(**) This column applies even if there is only one G1 BTS in a closed multidrop where other BTSs are not G1 BTSs.
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRXs
when no multiplexing is applied.
Abis Configuration
Nibble 1 Nibble 2 Nibble 3 Nibble 4
TS 0 TS 0 Usage / Transparency
TS 1 TRX 1 - TS 0 TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
TS 2 TRX 1 - TS 4 TRX 1 - TS 5 TRX 1 - TS 6 TRX 1 - TS 7
TS 3 TRX 1 - RSL
TS 4 TRX 2 - TS 0 TRX 2 - TS 1 TRX 2 - TS 2 TRX 2 - TS 3
TS 5 TRX 2 - TS 4 TRX 2 - TS 5 TRX 2 - TS 6 TRX 2 - TS 7 13 TS required
TS 6 TRX 2 - RSL in case of
TS 7 TRX 3 - TS 0 TRX 3 - TS 1 TRX 3 - TS 2 TRX 3 - TS 3
No Multiplexing
TS 8 TRX 3 - TS 4 TRX 3 - TS 5 TRX 3 - TS 6 TRX 3 - TS 7
TS 9 TRX 3 - RSL
TS 10 TRX 4 - TS 0 TRX 4 - TS 1 TRX 4 - TS 2 TRX 4 - TS 3
TS 11 TRX 4 - TS 4 TRX 4 - TS 5 TRX 4 - TS 6 TRX 4 - TS 7
TS 12 TRX 4 - RSL
TS 13 OML
: :
: :
: :
TS 31
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRX
when 16K Static multiplexing is applied.
Rules:
16K Static Multiplexing is used only in a BSS with Evolium BTS and G2 BTS with DRFU,
whereby each TRX carries a maximum of 8 SDCCH.
Not compatible with the Half-Rate mode.
BTS should be connected to a G2 BSC.
Abis Configuration
Nibble 1 Nibble 2 Nibble 3 Nibble 4
TS 0 TS 0 Usage / Transparency
TS 1 TRX 1 - TS 0 TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
TS 2 TRX 1 - TS 4 TRX 1 - TS 5 TRX 1 - TS 6 TRX 1 - TS 7
TS 3 TRX 2 - TS 0 TRX 2 - TS 1 TRX 2 - TS 2 TRX 2 - TS 3
TS 4 TRX 2 - TS 4 TRX 2 - TS 5 TRX 2 - TS 6 TRX 2 - TS 7
TS 5 TRX 3 - TS 0 TRX 3 - TS 1 TRX 3 - TS 2 TRX 3 - TS 3
TS 6 TRX 3 - TS 4 TRX 3 - TS 5 TRX 3 - TS 6 TRX 3 - TS 7
TS 7 TRX 4 - TS 0 TRX 4 - TS 1 TRX 4 - TS 2 TRX 4 - TS 3
TS 8 TRX 4 - TS 4 TRX 4 - TS 5 TRX 4 - TS 6 TRX 4 - TS 7
TS 9 TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL / OML
The following figure shows the example of Abis timeslot consumption for 1 BTS
with 4 TRX when 64K Statistical multiplexing is applied.
Rules:
64k Statistical Multiplexing is used only with Evolium BTS
A BTS with N FR TRE configured with 64K statistical multiplexing requires:
I. (N/4) MCB 64/4
II. One MCB 64/1 when N mod 4 = 1 (BTS with 1, 5, 9 or 13 TREs)
III. One MCB 64/2 when N mod 4 = 2 (BTS with 2, 6, 10 or 14 TREs)
IV. One MCB 64/1 and one MCB 64/2 when N mod 4 = 3 (BTS with 3, 7, 11 or 15
TREs). This configuration is used instead of MCB 64/3 to allow a better usage of
TCU resources at the BSC. It consists of splitting the last 3 RSL into 2 Abis-TS.
The 2 fractions can be mapped on 2 different TCUs
A BTS with N DR TRE configured with 64K statistical multiplexing includes ((N-
1)/2)+1 MCBs of which:
I. (N/2) MCB 64/2
II. (N mod 2) MCB 64/1
Dual Rate attribute is introduced per TRE and not anymore per BTS; only the TRX
using the DR mode must follow the rules concerning DR TRX (possibility to connect
2 DR TRX per TCUC).
As for 64K statistical multiplexing, Abis transmission can be seen as a sequence of MCB
16/1, see below.
Abis Configuration
Nibble 1 Nibble 2 Nibble 3 Nibble 4
TS 0 TS 0 Usage / Transparency
TS 1 TRX1-RSL/OML TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
TS 2 TRX 1 - TS 4 TRX 1 - TS 5 TRX 1 - TS 6 TRX 1 - TS 7
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRX
when 16K Statistical multiplexing is applied.
Figure 32: Example of Abis TS usage for 1 BTS/4 TRX – 16K Statistical Multiplexing
Rules:
16K Statistical Multiplexing is used only with Evolium BTS.
Not compatible with the Half-Rate mode.
Not compatible with dynamic SDCCH allocation.
TS 0 of each TRX must not be assigned to Traffic channel (but to a signalling channel
BCCH/CCCH, SDCCH…).
ET ET ET ET ET ET ET ET
Primary link
TRX 1 to 12 BTS 24TRX
+ extra PS TS
BSC
Secundary link
TRX 13 to 24
+ extra PS TS
The primary and secondary Abis links of a BTS can be on different Abis TSU of different
BSC racks.
BTS 1
BTS 1
12 TRX
16TRX
BSC
BTS 2
BTS 2
6 TRX
6TRX
BTS 1
4 TRX
OML+RSL1-4
OML+RSL1-4
RSL 9-12
First A-bis
RSL 5-8
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
TRX1
TRX1
TRX2
TRX2
TRX3
TRX4
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX9
TRX9
TRX3
TRX4
TRX8
MAX_FR_TRE_PRIMARY = 12
Maximum filling of
RSL 13-16
Second A-bis
TRX13
TRX13
TRX14
TRX14
TRX15
TRX16
TRX16
TRX15
first Abis link
or
OML+RSL1-4
OML+RSL1-4
First A-bis
RSL 5-8
TRX1
TRX1
TRX2
TRX2
TRX3
TRX4
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX3
TRX4
TRX8
TRX8
MAX_FR_TRE_PRIMARY = 8
RSL 13-16
RSL 9-12
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX10
TRX10
TRX11
TRX12
TRX12
TRX16
TRX11
TRX9
TRX9
-
Rules:
OML is always mapped on the first Abis link
TCH and RSL of a TRX are always mapped on the same Abis link
Only EVOLIUM BTS with SUMA board or M5M supports the 2nd Abis link.
It is not possible to have the primary Abis link on terrestrial link and the secondary
one on satellite link.
An EVOLIUM BTS with SUMP board has to be upgraded. An EVOLIUM BTS can
manage only 2 termination points - this implies that it is not possible to:
i) Connect a BTS in chain after a BTS with two Abis
ii) Change the Abis from chain to ring if there is a BTS with two Abis
iii) Attach a second Abis to a BTS that is not at the end of an Abis chain
• Extra Abis TS
New type of Abis TS, introduced since B8, to support
GPRS CS3-CS4 and EDGE services because 1 basic
Abis TS is not enough to transport the high data
throughput of those services.
1 Extra Abis TS contains 4 GCHs (nibbles). “Dynamic”
Various number of required GCH is based on number of
modulation & coding scheme (MCS or CS), please needed Abis
refer to 3.4.4.2.3. TSs
Less GCH consumption in B9 – thanks to M-EGCH
and dynamic Abis allocation
Max number of extra Abis TS is limited by parameter
N_EXTRA_ABIS_TS
It is simple to define the number of needed Abis TSs for conditions of topology, TS0 mode,
Qmux usage, signalling sub-mux and number of TRX because each of them requires the
certain number of TSs.
The most complicated part of Abis dimensioning from B9 release is how to define the number
of extra Abis TSs per BTS, as this kind of TS is allocated dynamically on Abis link when
needed by traffic demand and it can be shared among the BTS sector.
The following presents the Abis dimensioning processes to define the needed extra Abis TSs
based on the counter analysis.
Method 1: Abis dimensioning based on PS traffic only (bonus & extra Abis nibble
traffic)
Target: To estimate the number of Extra Abis Timeslots needed at BTS level.
Gathered Counters:
Counter Name Indicator Name Definition
P466 GABGCHUSEBT Cumulated time during which extra and bonus Abis nibbles are
used in the cell, cumulated over all extra and bonus Abis
nibbles.
P105i GQRDTECBN Number of DL establishment failures due to congestion of
Abis.
P105j GQRUTECBN Number of UL establishment failures due to congestion of
Abis.
P91a + P91b + GTRDTERQN Number of DL TBF establishment requests per cell.
P91c + P91d +
P91e + P91f +
P505
P62a + P62b + GTRUTERQN Number of UL TBF establishment requests per cell.
P62c - P438c +
P507
Table 17: Counter list - Abis dimensioning Method 1
Required extra
& bonus Abis Nb of required
nibble Traffic
Erlang C extra & bonus Abis
Nibbles
GoS:
% Quantile of x
delay sec Nb of required
extra Abis Nibbles
INPUT
The required extra & bonus Abis traffic is computed as below formula.
Measured _ extra & bonus _ Abis _ traffic
Re quired _ extra & bonus _ Abis _ traffic =
1− Min(%TBF _ Abis _ cong , 30%)
Note: 30% is defined as the max congestion rate to be considered because several congestions can
be re-produced from one given user trying to access the network several times.
Where:
P 466
Measured _ extra & bonus _ Abis _ traffic =
3600
%TBF _ Abis _ cong = Max (%DL _ TBF _ Abis _ cong ,%UL _ TBF _ Abis _ cong )
Where:
P105 i
%DL _ TBF _ Abis _ cong = × 100 %
P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
P105 j
%UL _ TBF _ Abis _ cong = × 100%
P 62a + P 62b + P 62c − P 438c + P 507
The other input is Grade of Service (GoS), which is defined by % quantile of x delay
second (pABIS).
Since the MFS always tries to assign TBFs as soon as the request is received, we
usually dimension for 0sec delay.
METHOD
Concerning only PS traffic, the statistical law Erlang C is used during the dimensioning
process to determine the necessary resources versus the traffic and the target GoS.
As extra & bonus Abis nibbles are associated to PS traffic only, Erlang C can be
applied to calculate the required number of extra & bonus Abis nibbles according to
required PS traffic and % quantile of delay time.
OUTPUT
Number of required extra & bonus Abis nibbles
= Erlang C (Required_extra&bonus_Abis_traffic, pABIS)
However the number of bonus Abis nibbles is fixed according to the total number of
BCCH & SDCCH TS in the BTS; i.e. one BCCH (SDCCH) TS gives one bonus Abis
nibble.
Then,
Number of required extra Abis nibbles
= Number of required extra & bonus Abis nibbles – Nbr of bonus Abis nibbles
And
Number of required extra Abis TS
= Number of required extra Abis nibbles / 4
Remark: 1 Abis TS contains 4 Abis nibble
Assessment:
In order to assess the Abis dimensioning, it is suggested to monitor if there is any
impact caused by Abis congestion afterward.
The major degradations due to Abis congestion are:
TBF establishment failures due to Abis congestion:
% _ TBF _ Abis _ cong > 0,1%
Gathered Counters:
Counter Name Indicator Name Definition
MC380a GTCTRFT Time during which the TCH FR are busy
MC380b GTCTRHT Time during which the TCH HR are busy
P100c GAAGCHUST Cumulative time during which a GCH is busy in a cell. The
counter is integrated over all the GCH available in the cell.
P90a+P90b+P90c+ GTRDTESUN Number of DL TBF establishment successes per cell
P90d+P90e+P90f+
P506
P30a + P30b + P30c GTRUTESUN Number of UL TBF establishment successes per cell
+P508
P105i GQRDTECBN Number of DL establishment failures due to congestion of
Abis.
P105j GQRUTECBN Number of UL establishment failures due to congestion of
Abis.
P91a+P91b+P91c+ GTRDTERQN Number of DL TBF establishment requests per cell.
P91d+P91e+P91f+
+ P505
P62a+P62b+P62c- GTRUTERQN Number of UL TBF establishment requests per cell.
-P438c+P507
P20x GQRPDDRxN In acknowledged mode, number of DL RLC data blocks
(x = a…d) (x = 1,.. ,4) (except RLC blocks containing LLC Dummy UI Commands
only) on PDTCH encoded in CS-x (i.e CS-1 (P20a) … CS-4
(P20d)) retransmitted due to unacknowledgement of the
MS.
P20f+P20g+P20h+ GQRPDDRMN In acknowledged mode, number of DL RLC data bytes
P20i+P20j+...+P20n encoded in all MCS-x (x = 1... 9) and retransmitted due to
unacknowledgement of the MS.
P21x GQRPDURxN In acknowledged mode, number of UL RLC data blocks on
(x = a…d) (x = 1,.. ,4) PDTCH encoded in CS-x (i.e CS-1 (P21a) … CS-4 (P21d))
retransmitted due to unacknowledgement of the MFS.
P21f+P21g+P21h+ GQRPDURMN In acknowledged mode, number of UL RLC data bytes
P21i+P21j+…+P21n encoded in all MCS-x (x = 1... 9) and retransmitted due to
unacknowledgement of the MFS.
Methodology:
INPUT METHOD OUTPUT
PS traffic (MCS or GCH)
CS traffic
Abis Method Nb of required
Cell configuration: with Knapsack
extra Abis Nibbles
- Nb of Basic nibbles or with Knapsack
Parameters: + Erlang C
- Min_PDCH
- Max_PDCH_High_load
- Max_PDCH
Compare calculated
GoSs to required ones
False
GoS reached in all
Nb extra and cell for all services?
bonus ++
True
In addition, Abis method can be internally categorized into 2 different ways, depending
on the representative indicators for PS traffic.
PS traffic = MCS traffic
Only Knapsack statistical law is applied in Abis method.
MCS method
N_EXTRA_ABIS_TS=0
For each BTS No
Needing additional Extra nibbles
Resources according Needed ?
to Extra & Bonus method
yes
/4
Round up
N_EXTRA_ABIS_TS
Figure 40: Abis dimensioning process
Group Switch
8 Planes
Abis TSU 2 Stages Ater TSU 2 E1
6 E1
TCUC self-routing, non-blocking DTCC
TCUC DTCC
2x
6x TCUC DTCC
ASMB
G.703
G.703 TCUC DTCC
Ater
Abis TCUC DTCC
muxed
I/F TCUC DTCC
BIUA
TCUC DTCC I/F
AS AS ASMB
TCUC DTCC
TSL Q1 bus
AS
Broadcast bus
Common Functions TSU
From Figure 41, the BSC is basically divided in three building blocks:
1) Abis TSU: For Abis interface management functions – towards the Base
Stations (BTS), see details in section 3.3.1.2
2) Ater TSU: For Ater interface management functions – towards the Core
Network (Circuit and Packet), see details in section 3.3.1.3
3) Common TSU: For all central functions of the equipment;
For different G2 BSC config type, the max number of ExtraAbisTS which can be configured is
different due to fact that ExtraAbisTS must be mapped to FR TCU only, and max 8 EXTS mapped per
TCU are allowed.
G2 BSC Config.1 Config.2 Config.3 Config.4 Config.5 Config.6
TCU number 8 32 48 72 88 112
Max EXTS 51 205 307 461 563 717
N.B. It is recommended to limit the BSC load in terms of FR TRXeq to 80%, being FR TRXeq defined as:
N _ EXTRA _ ABIS _ TSallBTS
FR _ TRXeq = FR _ TRX + 2 × DR _ TRX +
2
Rules:
Each TCUC can handle 6 LAPD signalling links LAPD (i.e. RSL, OML and TSL) that
allows:
4 RSL+ 2 OML
3 RSL+ 3 OML
• 2 ASMB: providing
multiplexing 16kbps from
4 tributaries to 1 highway.
• 2 access switches
DTC Rules:
Any of the first DTCs in each group of 4 supporting an AterMUX interface (among the 16
first Ater Mux) can terminate an SS7 signalling link if the Ater Mux is CS.
There are 6 potential BSC synchronization sources (one from each AterMUX in the first rack).
If the AterMUX is used, then the first DTC attached to that ASMB recovers a synchronization
reference signal and sends this to the BSC central clock.
DTCC can be dedicated for SS7-MTP (supporting a physical SS7 link), GSL (supporting a
physical GSL), BSSAP/GPRSAP (higher layers of SS7 and GSL) or TCHRM (TCH
allocation)
One DTCC TCH-RM pair can handle up to 60 cells and the number of TRX per TCH-RM is
limited to 90.
SSWW CCP1
MUXr
MUXW
SSW
CCPy
Radio Network links
LIU1
E1
OMCPw
LIUn OMCPr
LIU Shelf
(21 slots) ATCA Shelf (14 slots)
r : Redundancy
W : Working
n and y : Network Element Capacity
The BSC capacity is defined with the FR TRXeq parameter that is defined by the formula:
TRX = FR _ TRXeq = FR _ TRX + 2 × DR _ TRX
When the “Optimized HR connectivity” feature is enabled, the TRX calculation become:
TRX = FR _ TRX + DR _ TRX
Note: In Mx BSC, the HDLC channel (High Level Data Link) transports the signalling link (OML
and/or RSL) of the BTS on a 64kbps Abis timeslot.
One HDLC channel is used per LAPD link (if 16K Statistical Signaling Multiplexing or No
Multiplexing mode is applied) or per group of multiplexed RSL and OML (i.e. when 16K Static
or 64K Statistical Signaling Multiplexing mode is applied).
With a high signalling load, a HDLC channel handles 1 DR TRX or 2FR TRX
=> 441 DR TRX or 882 FR TRX per BSC
In order to reach the maximal load of TRX supported by Mx BSC, it is recommended to use
largely the 64K Statistical Multiplexing RSL mode.
In B10 MR2, the BSC performances are improved with the introduction of new TPGSMv3
board.
This board allow a capacity of 1024 HDLC channels (984 channels are available for RSL and
OML), but the same maximum of 481 HDLC is retained initially in order to guarantee
transparent interoperability.
In A9130 BSC Evolution, TCU allocation will only involve the mapping of signalling
channels i.e. RSL/OML on a TCU. Since traffic will be switched within TPGSM so it does
not make sense to map TCHs & EXTS on to the TCU.
Moreover TCU allocation algorithm for signalling links will be highly flexible as we can
allocated any available TCU from the TCU pool from configuration point view i.e. all TCUs
across CCP boards will belong to one pool.
Finally with the optional “Optimized HR connectivity”, the mapping constraints of DR TRX
are removed allowing full TRX connectivity at TCU level.
Rules
A VTCU can handle a maximum of:
• 4 FR TREs (4 RSLs) or
• 2 FR + 1 DR TREs (3 RSLs) or
• 2 DR TREs (2 RSLs)
==> In other words TCU can handle maximum of 4 Eq. FR RSLs
• With “Optimized HR connectivity”, TCU handle 4 FR and/or DR RSL
• TCU can handle maximum of 3 OMLs.
• 7 LAPD per VTCU (for G2 BSC the limit is 6 LAPD per TCUC)
200
2 2 18 34 50 66 82 98 114 130 145 162 70 60 22 4 3
3 3 19 35 51 67 83 99 115 131 147 163 71 61 23 6 5
4 4 20 36 52 68 84 100 116 132 148 164 72 62 24 8 7
5 5 21 37 53 69 85 101 117 133 149 165 73 63 25 10 9
6 6 22 38 54 70 86 102 118 134 150 166 74 64 26 12 11
400
7 7 23 39 55 71 87 103 119 135 151 167 75 65 27 14 13
8 8 24 40 56 72 88 104 120 136 152 168 76 66 28 16 15
9 9 25 41 57 73 89 105 121 137 153 169 x 67 29 18 17
10 10 26 42 58 74 90 106 122 138 154 170 x 68 30 20 19
11 11 27 43 59 75 91 107 123 139 155 171 x 54 48 42 41
12 12 28 44 60 76 92 108 124 140 156 172 x 53 47 40 39
400
13 13 29 45 61 77 93 109 125 141 157 173 58 52 46 38 37
14 14 30 46 62 78 94 110 126 142 158 174 57 51 45 36 35
15 15 31 47 63 79 95 111 127 143 159 175 56 50 44 34 33
200
16 16 32 48 64 80 96 112 128 144 160 176 55 49 43 32 31
Figure 46: Abis and Ater allocation on LIU boards / BSC capacity
For
For each
each BSC
BSC ar
area,
ea, choose
choose a
aB SC
BSC
configuration
configuration
Check
Check B SC border
BSC border with
with RNP
RNP team
team
No
No
OK
OK ??
Yes
Yes
Check
Check Abis
Abis conn
connectivity
ectivity
Yes
Yes No
No
No
No Choose
Choose an
an oth
otherer BSC
BSC configura
configuration,
tion,
OK
OK ??
if
if possibl
possiblee ??
Yes
Yes
Check
Check Ater
Ater connectivity
connectivity
No
No
OK
OK ??
Yes
Yes
Outputs
•BSC configurations
•BSC Areas
In Figure 47, basically the BSC dimensioning consists of two following parts:
• Design BSC area
• Parenting Abis TSU ports of the BSC
Figure 48: BTS position & configuration – design BSC area step 1
Figure 49: Transmission planning & BSC position – design BSC area step 2
This number of Abis used between each geographical location has to be checked with
the actual available number of E1 links, which will be implemented in the network.
This task is usually performed by the Transmission team.
Gathered Counters:
Note: the MC8a values for each cell in the same LA should be identical. However sometimes it was
observed (from counters of live networks) that some cells in the same LA have the different MC8a value
– for this case, the most frequency value will be chosen to be represented the paging traffic of the LA.
Methodology:
The maximum number of paging per Location Area is derived from the paging
limitations at Um interface, Abis Interface and BSC sides as following details.
• Um interface Limitation – Combined cells
There are 3 CCCH blocks per M51 frame for combined cells.
Among those 3 blocks, 3 minus BS_AG_BLK_RES are reserved for paging
(BS_AG_BLK_RES = 1 as an usual default value for combined cells).
A 2.5 Paging/PCH value has been used to derive the maximum paging load per
Location Area.
Therefore;
Available blocks for paging per hour:
2 PCH blocks/Multiframe * (3600s/ 235ms) = 30,638 PCH blocks/ hour
Note: 235 ms is the period of 51 Multiframe
Therefore;
Available blocks for paging per hour:
5 PCH blocks/Multiframe * (3600s / 235 ms) = 76,595 PCH / hour
Maximum paging per hour:
2.5 paging/Block x 76,595 Blocks = 191,489 paging/hour (100%load)
When two CCCH TS are devoted to the cell, the Um paging capacity is then the double
of the previous calculated value (almost 64 paging/s).
Only cells with the mCCCH capability offer such paging capacity, and only if the whole
LA is with cells having two-ccch configuration.
In addition, only one RSL is considered as enough to carry this paging load over the
Abis interface (it is recommended to used 64K statistic multiplexing).
When mCCCH feature is enabled, the paging load on Abis is also doubled and
corresponds to 66 paging commands per second, or
• G2 BSC Limitation
The BSC limit is 70 paging/sec on the A interface (Alcatel traffic model).
The paging on the A interface is the sum of the paging on all Location Area which are
configured on a BSC.
So it depends on the Paging rate on Location Area and on the number of Location Areas
in a BSC.
Limitation Factor
The minimum value from those four limitations is therefore given by the Um interface, which is
45957 pagings/hour if aLA contains at least one combined cell, or is 114893 pagings/hour if the
Location Area contains only non-combined cells (in case of G2 BSC).
This conclusion holds true as long as there are max 5 LAs (resp. 9 LAs) covered by the G2 BSC
(resp. Mx BSC), which should always be the case but it worst to mention it.
In case of non-combined cells, 2 LAs may be covered by one G2 BSC (252000/114893 = 2.19)
and 4 LAs are required by one Mx BSC (439200/114893 = 3.9).
Assessment:
Below figure shows the LA dimensioning assessment (for G2 BSC).
No Yes
Total MC8a > 252000 Re-Design LA, and/or
(Total MC8a of all LA in the BSC) Reduce nb of LA per BSC
Check Um Limitation
No Yes
All Cells in a LA are non-combined
No Yes No Yes
MC8a > 45,957 MC8a > 114893
It is not significant to check Abis limitation, because Um limitation is lower than the
Abis one. Therefore, Um limitation is usually triggered first.
3.3.5 RA Dimensioning
A Routing Area (RA) is a sub-set of one LA and identifies one or several cells in a LA.
In case of a mobile terminating call in GSM, the MS in idle mode will be paged in all cells
belonging to the LA, which the MS is present.
For PS services, the SGSN pages the MS in STANDBY state, in case of a downlink TBF. It
means additional signalling effort (for GPRS/EDGE) will be produced in the network: at each
DL TBF establishment the MS will be paged in the RA if the MS is in the GMM Standby
state.
Introducing RA, which should be smaller than LA, the signalling effort for paging is
now more focused to a smaller area, the signalling load for the cells being reduced.
Note: the P53a (respectively MC8a) values for each cell in the same RA (respectively LA) should be
identical. However sometimes it was observed (from the counter of live networks) that some cells in the
same RA (respectively LA) have the different P53a (respectively MC8a) value – for this case, the most
frequency value will be chosen to be represented the paging traffic of the RA (respectively LA).
Methodology:
It is not possible to define a RA across a LA border (e.g. one cell from LA1 and two
cells from LA2).
Other rules:
- One RA can contain one or several cells
- One cell cannot belong to two RA
- Cells from one BTS can be allocated to different RA
- The maximum number of RA in a LA is 256 (0, 1, 2... 255)
If this ratio is greater than 20% during the day hours, the solution to reduce global
paging load may be splitting RA into several RAs for a corresponding LA (one LA:
several RA).
Assessment:
The limited GPRS paging load ratio can be modified.
3) Assess whether any LA has the current paging load exceeding 60%.
If not, it is OK => no LA/RA re-dimensioning required
If yes, continue to 4)
Example:
If there is one LA which has one RA (LA size = RA size), and at busy hour:
• MC8A = 120,000
• P53a = 36,000
Only non-combined cells are present in the LA. Then for G2 BSC dimensioning:
Paging load of 1 LA with 1 RA = 120000/191489 = 62.6% !! (> 60%)
CS Paging load = (120000-36000)/191489 = 43.8%
PS Paging load = 36000/191489 = 18.8%
GPRS paging load ratio = 36000/120000 = 30%
As GPRS paging load ratio > 20%, we may try to reduce paging load by splitting
RA into several RAs for this LA as below examples:
Estimated Paging load of 1 LA with 2 RA = 43.8% + 18.8%/2 = 53.2%
Estimated Paging load of 1 LA with 3 RA = 43.8% + 18.8%/3 = 50.1%
Estimated Paging load of 1 LA with 4 RA = 43.8% + 18.8%/4 = 48.5%
Nb CCCH TS BS_AG_BLKS_RES PCH blocks AGCH blocks Max paging/s Max assign/s
at 60% load at 60% load
1 3 6 3 38 7
1 4 5 4 32 10
1 5 4 5 25 12
2 3 12 6 76 15
2 4 10 8 63 20
2 5 8 10 51 25
2 6 6 12 38 31
If not all cells in LAC are with mCCCH activated, the paging capacity is like in cells with
single CCCH.
However for AGCH, the capacity in cells with mCCCH should be greater.
The needed number of PCH blocks is defined by Nb_Needed_PCH_Blocks, while the needed
number of AGCH blocks is defined by BS_AG_BLKS_RES=N2.
The need of a second CCCH is also related to the AGCH and PCH loads.
When the nominal cell load is higher than 60%, a re-dimensioning of the CCCH channel is
required or a second CCCH channel shall be allocated to that cell.
The counter MC925f (resp. MC925h) may be recommended to follow the number of
Immediat Assignement (resp. Paging Command) received by the BTS on Abis and discarded
due to congestion.
On the AterMUX CS interface, a 64kbps timeslot transmits information for 4 Circuit Switch
calls (whatever they use FR or HR codec).
On the AterMUX PS interface, a 64kbps timeslot supports 4 GCHs.
3.4.1.2 A interface
The A-interface is a set of 2Mbps PCM links carrying CS traffic between the TC and the
MSC.
One 64kbps channel on A interface is corresponding to one 16kbps channel on AterMUX.
BSC TC MSC
AterMUX A
Since release B7.2, it is possible only 4:1 multiplexing at BSC side and 4:1 de-multiplexing at
TC side.
Therefore, the number of A-interface links is four times of the number of AterMUX CS
interface links. That is:
AterMUX CS AterMUX PS
CH# 1 CH# 2 CH# 3 CH# 4 CH# 1 CH# 2 CH# 3 CH# 4
TS 0 TS 0 Transparency TS 0 TS 0 Transparency
TS 1 TCH TCH TCH TCH TS 1 GCH GCH GCH GCH
TS 2 TCH TCH TCH TCH TS 2 GCH GCH GCH GCH
TS 3 TCH TCH TCH TCH TS 3 GCH GCH GCH GCH
TS 4 TCH TCH TCH TCH TS 4 GCH GCH GCH GCH
TS 5 TCH TCH TCH TCH TS 5 GCH GCH GCH GCH
TS 6 TCH TCH TCH TCH TS 6 GCH GCH GCH GCH
TS 7 TCH TCH TCH TCH TS 7 GCH GCH GCH GCH
TS 8 TCH TCH TCH TCH TS 8 GCH GCH GCH GCH
TS 9 TCH TCH TCH TCH TS 9 GCH GCH GCH GCH
TS 10 TCH TCH TCH TCH TS 10 GCH GCH GCH GCH
TS 11 TCH TCH TCH TCH TS 11 GCH GCH GCH GCH
TS 12 TCH TCH TCH TCH TS 12 GCH GCH GCH GCH
TS 13 TCH TCH TCH TCH TS 13 GCH GCH GCH GCH
TS 14 Qmux TCH TCH TCH TS 14 GCH GCH GCH GCH
TS 15 Alarm octet TS 15 Alarm octet
TS 16 SS7 TS 16 SS7 (not used)
TS 17 TCH TCH TCH TCH TS 17 GCH GCH GCH GCH
TS 18 TCH TCH TCH TCH TS 18 GCH GCH GCH GCH
TS 19 TCH TCH TCH TCH TS 19 GCH GCH GCH GCH
TS 20 TCH TCH TCH TCH TS 20 GCH GCH GCH GCH
TS 21 TCH TCH TCH TCH TS 21 GCH GCH GCH GCH
TS 22 TCH TCH TCH TCH TS 22 GCH GCH GCH GCH
TS 23 TCH TCH TCH TCH TS 23 GCH GCH GCH GCH
TS 24 TCH TCH TCH TCH TS 24 GCH GCH GCH GCH
TS 25 TCH TCH TCH TCH TS 25 GCH GCH GCH GCH
TS 26 TCH TCH TCH TCH TS 26 GCH GCH GCH GCH
TS 27 TCH TCH TCH TCH TS 27 GCH GCH GCH GCH
TS 28 TCH TCH TCH TCH TS 28 GSL
TS 29 TCH TCH TCH TCH TS 29 GCH GCH GCH GCH
TS 30 TCH TCH TCH TCH TS 30 GCH GCH GCH GCH
TS 31 X25 TS 31 GCH GCH GCH GCH
AterMUX CS:
Referring to AterMUX CS structure (in Figure 56), the following figure presents the
AterMUX CS configurations that depend on the G2 BSC configuration.
X 25 Qmux A la rm SS7 T C H N um b e r
P CM 1 (x ) x x x 111
A te r T S U 1
P CM 2 (x ) x x x 111
P CM 1 x x 116
B SC R ack 1 A te r T S U 2
P CM 2 x x 116
P CM 1 x x 116
A te r T S U 3
P CM 2 x x 116
X 25 Qmux A la rm SS7
P CM 1 x x x 115
A te r T S U 4
P CM 2 x x x 115
P CM 1 x x 116
B SC R ack 2 A te r T S U 5
P CM 2 x x 116
P CM 1 x x 116
A te r T S U 6
P CM 2 x x 116
X 25 Qmux A la rm SS7
P CM 1 x x x 115
A te r T S U 7
P CM 2 x x x 115
P CM 1 x x 116
B SC R ack 3 A te r T S U 8
P CM 2 x x 116
P CM 1 x 116
A te r T S U 9
P CM 2 x 116
T o ta l T C H 20 7 4
Figure 57: AterMUX CS interface configuration – G2 BSC
In Figure 57, the number of TCHs is different for each AterMUX link as it depends
on the appearance of signalling channels.
Remark: with BSC configuration 6 Ater TSU 9 PCM 1 & 2 do not convey SS7
links; however, TS 16 is left unused and does not convey any traffic channels, so
total TCH remains 116 not 120.
For G2 BSC, the maximum number of AterMUX CS interfaces is summarized in
below table.
For BSC Evolution, the maximum number of AterMUX links for CS traffic (from
BSC to TC) is 48 and are addressed by Ater-Hway-TP in the range [1-30] and [59-
76]. These links may be used for PS traffic also.
A-interface:
The channel mapping between AterMUX CS interface and A-interface is presented
below:
AterMUX CS A Interface
CH# 1 CH# 2 CH# 3 CH# 4 TS 0 Frame Synchronization
TS 0 Frame Synchronization TS 1 CIC 1
TS 1 TCH TCH TCH TCH TS 2 CIC 2
TS 2 TCH TCH TCH TCH TS 3 CIC 3
: : TS 4 CIC 4
: : TS 5 CIC 5
TS 14 Qmux TCH TCH TCH : :
TS 15 Alarm octet : :
TS 16 SS7 : :
TS 17 TCH TCH TCH TCH : :
TS 18 TCH TCH TCH TCH : :
: : : :
: : : :
TS 30 TCH TCH TCH TCH TS 30 CIC 30
TS 31 X25 TS 31 CIC 31
TS : 64 Kbits/sec TS : 64 Kbits/sec
Channel or Nibble : 16 Kbits/sec
Figure 58: Channel mapping between AterMUX CS and A
3.4.2.2 AterMUX PS
Referring to AterMUX PS structure (Figure 56), the following figure presents an example of
AterMUX PS configuration for a GPU.
Notes:
One GPU can support max. 480 GCH (a GPU has 4 DSPs one of which supports 120
GCH)
One GP can support max. 1560 GCH (a GP has 4 DSPs one of which supports 240 GCH)
5 AterMUX PS are needed to support 480 GCH (9 AterMUX PS are needed to support
1960 GCH)
Note: The max capacity of 5 AterMUX PS is 572 GCH, which is enough to support
480 GCH – refer to Figure 56
At least one GSL is required for a GP(U), but it is recommended to have 2 GSLs per
GP(U) as the security reason is concerned
Maximum 1 GSL is possible for an AterMUX PCM link (TS 28)
For BSC Evolution, the maximum number of AterMUX links dedicated for PS traffic (from
BSC only to MFS) is 28 and they are addressed by Ater-Hway-TP from 31 to 58.
TC
GPU
BSC SGSN
X (MFS) Z
From Figure 60: - X is the number of AterMUX between BSC and GP(U).
- Y is the number of AterMUX between GP(U) and TC.
- Z is the number of Gb between GP(U) and SGSN.
The Figure 61 presents details of Timeslot sharing between CS (TCH) and PS (GCH):
AterMUX CS/PS
PS Traffic Ratio / / / / Full
TS TS Transparency
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH GCH GCH
TS TCH TCH TCH GCH GCH
TS TCH TCH TCH GCH GCH
TS TCH TCH TCH GCH GCH
TS TCH TCH TCH GCH GCH
TS TCH TCH TCH GCH GCH
TS TCH TCH TCH GCH GCH
TS Alarm octet
TS SS
TS TCH TCH GCH GCH GCH
TS TCH TCH GCH GCH GCH
TS TCH TCH GCH GCH GCH
TS TCH TCH GCH GCH GCH
TS TCH TCH GCH GCH GCH
TS TCH TCH GCH GCH GCH
TS TCH TCH GCH GCH GCH
TS TCH GCH GCH GCH GCH
TS TCH GCH GCH GCH GCH
TS TCH GCH GCH GCH GCH
TS TCH GCH GCH GCH GCH
TS GCH GCH GCH GCH GCH
TS GCH GCH GCH GCH GCH
TS GCH GCH GCH GCH GCH
TS GCH GCH GCH GCH GCH
However, when there is enough PS traffic to fill 2 or more PCMs, there is an advantage to
dedicate complete PCMs to PS (AterMUX PS) rather than mixing PS with CS traffic
AterMUX CS/PS).
Indeed, doing so avoids connecting the MFS to the Transcoder, with AterMUX PCMs not
fully devoted to CS traffic, and thus avoids wasting transcoder resource.
So, the minimum usage of mixed AterMUX (CS + PS) is recommended.
With the total bytes for one call attempt from previous table and given BHCA, it is possible to
estimate the SS7 required throughput and corresponding number of SS7 links needed.
Required SS7 throughput (kbps) = BHCA /3600 x Total bytes for one call Attempt * 8/1000
The required SS7 throughput is estimated in the MSC to BSS direction (worst case, because
of paging load).
Nb of SS7 links Nb of SS7 links
BSC type (*) BHCA (**)
at 40% load at 60% load
BSC-EV-200 64 800 8 6
If the resulting number of links is above 16, then SS7 on 2Mbps link (HSL) is required.
So dimensioning SS7 links at 60% load is allowed with the Alcatel-Lucent BSS, if the MSC
can also allow it. This SS7 signalling load is possible as soon as there is a minimum of four
N7 links configured.
Methodology:
INPUT
The SS7 traffic is related to the SCCP traffic generated by Call and Signalling treatments
as detailed in the Method paragraph.
Where:
Remark: a 15% margin is added to the traffic in order to take into account two
phenomena:
Time (H)
Figure 63: Difference between Exact busy hour, NPO busy hour and Peak traffic
The second input is the Grade of Service (GoS), which is defined by the required SS7
congestion rate (pSS7). Normally GoS should be given or agreed by the Mobile Operator.
METHOD
The dimensioning of SS7 links in the Alcatel BSS is linked to three issues:
• SCCP traffic
• Processor load
• Physical link load
This section will explain here the SCCP traffic issue without going in the detailed of
processor load and physical link load.
For each scenario, a dedicated SCCP connection is open between the BSS and the MSC,
for the duration of the scenario. It will carry all the signalling pertaining to that scenario.
Therefore, there is one SCCP connection open for SDCCH and TCH request:
• Speech calls, for a duration approximately equal to the SDCCH + TCH holding time
• External handover, for a duration equal to the overlap time, during which the TCH
resources in the old and the new BSC are simultaneously activated
• Location updates, for a duration approximately equal to the SDCCH holding time
• SMS and other services, for a duration approximately equal to SDCCH holding time
Since B7.2,
The Alcatel BSCs provide 256 SCCP connections per SS7 link.
According to ITU-T Recommendations a maximum load of 40% must be accepted
on a SS7 link: 103 SCCP connections can be supported per SS7 link
There is one SS7 link per AterMUX CS link.
As SS7 is associated to signalling CS traffic only, Erlang B can be applied to calculate the
required number of SCCP connections according to the required SCCP traffic
(SCCP_connection_erlang) and the target congestion rate.
OUTPUT
For example:
If the total number of Ater CS of one BSC is equal to 10 interfaces, the number of
required SS7 links for that BSC is identical to the number of Ater CS (i.e. 10 links
offering up to 1030 SCCP connections).
3.4.4.1 AterMUX CS
Target: To estimate the number of AterMUX-CS links per BSC.
Gathered Counters:
Methodology:
The process of AterMUX-CS dimensioning is presented below.
Signalling Traffic
Required
SDCCH Nb of Nb of
Traffic required SS7 required
Erlang B
per BSC AterMUX-CS
links per BSC
GoS:
% SS7
blocking Final nb of
Choose required
“Max” value AterMUX-CS
User Traffic links per BSC
Required
TCH Nb of Nb of
Traffic Erlang B required TCH required
per BSC AterMUX-CS
links per BSC
GoS:
% TCH
blocking
Signalling traffic
The SS7 traffic is partially related to traffic generated by CS Call as detailed in the
previous paragraph. In LSL mode, each SS7 link is carried by an AterMUX-CS
interface. In this case:
Number of required AterMUX-CS Links (1) = Number of required SS7 Links
As an example, if the total number of required SS7 links of one BSC is 10 links, the
number of needed AterMUX-CS will be equal to 10 links.
For SS7 link definition, please refer to SS7 dimensioning and HSL mode
User traffic
INPUT
The required TCH traffic is computed as below formula.
Where:
MC 380a + MC 380b
Measured _ TCH _ traffic =
3600
Note: a 15% margin is added to the required traffic - see more explanation in 3.4.3.2
The other input is Grade of Service (GoS), which is defined by the required
AterMUX-CS congestion rate (pAterMuxCS). Normally GoS should be given or agreed
by the Mobile Operator.
METHOD
Concerning only CS traffic, the statistical law Erlang B is used during the
dimensioning process to determine the necessary resources versus the traffic and the
target GoS.
As AterMUX-CS is associated to CS traffic only, Erlang B can be applied to calculate
the required number of TCH channels according to required TCH traffic and the target
congestion rate.
OUTPUT
Number of required TCH:
= Erlang B (Required_TCH_traffic, pAterMuxCS)
For example:
If the total number of TCH per BSC x is 1200 TCHs.
Then, the number of required AterMUX-CS links of BSC x is 11 links.
Note: From Figure 57, the total capacity of 11 AterMUX CS links is:
111TCH(link#1) + 111TCH(link#2) + 116TCH(link#3) + 116TCH(link#4) +
116TCH(link#5) + 116TCH(link#6) + 115TCH(link#7) + 115TCH (link#8) +
116TCH(link #9) + 116TCH(link #10) + 116TCH(link #11)
Then,
3.4.4.1.1 A Dimensioning
According to Figure 58, basically the number of required A-interfaces depends on the number
of AterMUX-CS links connected to the Transcoder as following relation:
In this case if there is 40 AterMUX CS links needed at TC level, then the number 160 A-
interface links (40*4) are required from TC to MSC.
BSC level (doing the hypothesis of a well balanced traffic distribution among the
GP(U) boards connected to the BSC)
AND
N.B. If, running the dimensioning assessment method, more than 1 GP(U) board are identified as under-
dimensioned (i.e. they are not able to handle the required traffic) the adding of GP(U) boards will be
done in an iterative way (1 GP(U) at once) monitoring the consequent impact on the AterMux PS
interface.
In Figure 65 the process for AterMux PS dimensioning that must be applied at BSC level, is
presented:
# Needed # Needed
GSL links GCH
Aterlink
GCH_Capacity
GPU/GP dimensioning ÷
Assessment # AterMux PS
÷ ÷
# AterMux PS per GPU # AterMux PS per GPU
(GSL traffic) (user traffic)
max 2 (for security reason)
# GSL links
(at least 2 per GPU/GP) # GPU/GP
# AterMux PS per GPU/GP
Figure 65 AterMux-PS dimensioning process at BSC level
On the other hand, the process that is applied at GP(U) level, if the output of the process
applied at BSC level does not recommend the adding of additional GP(U) resources, is
described in Figure 66:
÷ ÷
# AterMux PS per GPU
(GSL traffic)
# AterMux PS per GPU
(user traffic) ÷ ÷
max # AterMux PS per GPU (estimated at
# AterMux PS per GPU # AterMux PS per GPU
(GSL traffic) (user traffic)
BSC level)
max
# GSL links 2
(at least 2 per GPU/GP) # AterMux PS per GPU/GP
# AterMux PS per GPU/GP
Figure 66 AterMux-PS dimensioning process at GP(U) level
If, applying the dimensioning method at one GP(U), the result is that one (01) board is enough
in order to support the required traffic; the number of needed AterMux PS links for this
GP(U) will be assessed.
Otherwise, if the board is overloaded, it is recommended to add one additional GP(U) board
and the number of AterMux PS links per GP(U) will be re-assessed at BSC level.
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
Example 2
BSC level (2 GP(U) with 2 AterMux links per GP(U)):
#Needed GCH = 400
#Needed GP(U) = 2
#AterMux PS per BSC = 400/112 = 4
#AterMux PS per GP(U) = 4 / 2 = 2
GP(U) level
GPU1
#Needed GCH GPU1 = 160
#Needed GP(U) = 1
#AterMux PS per GP(U) = Max (160 / 112, 2) = 2
GPU2
#Needed GCH GPU2 = 240
#Needed GP(U) = 1
#AterMux PS per GP(U) = Max (240 / 112, 2) = 3
1. Reshuffle operation is done in order to try to balance traffic between the two GPUs
2. If the reshuffle operation has not the wanted effect, add 1 AterMux PS to GPU2.
Example 3:
BSC level 2 GP(U) with 2 AterMux links per GP(U)):
#Needed GCH = 500
#Needed GP(U) = 2
#AterMux PS per BSC = 500 / 112 = 5
#AterMux PS per GP(U) = 5 / 2 = 3
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 GP(U) = 3
#AterMux PS per BSC = 500 / 112 = 5
#AterMux PS per GP(U) = 5 / 3 = 2
AterMux dimensioning
Assessment for GSL traffic
Assessment based
Assessment based
on the number of
on GSL bandwidth
GSL messages per second
2
(for security reason)
max
# GSL links
Gathered Counters:
Methodology:
• Calculate GSL (signalling) traffic for each AterMUX-PS link
GSL_round_trip_delay GPU
A message is kept in the buffer
BSC K_GSL during GSL_round_trip_delay
GSL messages
buffer
Gathered Counters:
Methodology:
Retrieve indicators and •(*) QoS evaluation to be done
•by QoS expert
Cells GPUs mapping
START (if method applied to 1 GPU/GP) Retrieve data on a different
Period or on an updated
configuration with better QoS*
Calculation
+ #GSL msg/sec due to
RAE4 traffic calculation [3]
[1] QoS Acceptable ? Since the method uses the number of TBF establishment requests, the
result can be impacted a lot in case of abnormal degradation or in case of AterMux
interface on satellite link.
Indeed in this latter case the indicators related to TBF establishment show always an
important degradation (even without impact on end user) due to the fact that the answer to
mobile RACH is sent too late with respect to the mobile waiting time before sending a new
request; the consequence of this issue is an abnormal increase of TBF establishment
requests.
In order to be able to anyway handle GSL dimensioning assessment the suggested solution,
in case of not acceptable QoS, is to choose a reference BSC that should have the same PS
traffic amount per cell as the analysed BSC and to estimate the PS traffic in this latter
doing a simple proportion based on the number of cells of the reference / target BSC.
[2] GSL traffic condition. The amount of GSL messages exchanged because of the PS traffic
in terms of UL/DL TBF establishment can be estimated multiplying the number of TBF
establishments by a factor that can have three possible values [2,5-3,5-5]. The factor is
chosen on the basis of the rule described in the below figure.
(TBF req)
#TBF request/sec < 20
Nb of Msg on GSL
High Low
Nb GSL messages/s
N.B. The ½ factor is due to FR 3BKA20FBR202481 that should be corrected in B10 release.
If the GSL link capacity is computed at BSC level the capacity of all GP(U)
must be summed.
• GSL load in terms of treated messages per second on a given GP(U) should not
exceed 75%
It is recommended to increase the number of GSL per GP(U) if GSL load is greater
than 75%.
N.B. This will not assure a balanced load distribution among the GP(U) boards connected
to the BSC, because the AterMux interface capacity is not directly taken into account in the
cell distribution criteria in MFS.
For more details on cell mapping on GP(U) boards, please refer to [15].
In order to estimate the number of AterMux-PS links per GP(U), analyzing the
whole BSC, two main data must be estimated:
• Number of required GCH per BSC
• Number of required GP(U) per BSC
Please find details on the method allowing to estimate the number of GCH (per
BSC or per GPU) in the section 3.6.3.1 and 3.6.3.2.
Please find details of GP(U) dimensioning in the section 3.6.3
Having the number of required GCH and the number of GP(U) board, the Number
of AterMUX-PS links per BSC
= Number of required GCH per BSC / 112 GCH
Remark: 112 GCH is generally applied in case of with GSL configuration, otherwise 116 GCH may
be applied as well. See details in Figure 59 and also refer to section 3.4.4.2.2 GSL dimensioning.
Remark: it is highly recommended to have at least 2 AterMUX-PS links per GP(U) due to security
reason.
Example:
If Number of required GCH per BSC = 330
Number of required GP(U) per BSC = 2
Number of required GSL per GP(U) = 2
How many AterMUX-PS links per GP(U) are required?
- Determine Number of AterMUX-PS links per GP(U) based on signalling + user traffic
= Max (Number of required GSL per GP(U), Number of AterMUX-PS links per
GP(U) based on user traffic, 2)
= Max (2, 2, 2)
= 2 links
Assessment:
AterMUX-PS re-dimensioning is required when:
GSL load in terms of bandwidth is exceeding 80%.
GSL load in terms of number of treated messages per second is exceeding 75%.
GP(U) Ater time congestion rate exceeding 0.1 % can be observed regularly.
GP(U) re-dimensioning is performed.
Warning:
It could happen that, because of unbalanced traffic distribution among the GP(U)
boards connected to one BSC, one GP(U) board is more loaded than others.
This can be discovered applying the AterMux-PS dimensioning process at GP(U)
level. Some examples are provided in 3.4.4.2.1.
Then
From 250 TCH, 222 TCHs can be fit into 2 AterMUX-CS links
Note: From Figure 57, the total capacity of AterMUX-CS links is:
111TCH(link#1) + 111TCH(link#2) = 222 TCHs
Assessment:
AterMUX-CS/PS re-dimensioning is required when:
The increase of TCH traffic
GP(U) Ater time congestion rate exceeding 0.1 % can be observed regularly.
GP(U) re-dimensioning is performed.
In the case of G2.5 TC, these units are combined on one single board, the MT120, offering an
AterMUX connection to a BSC and up to 4 A-trunk connections to the MSC.
The MT120 can also be installed in the place of the ASMC in the G2 TC, and replaces 1
ASMC, 4 ATBX and 8 DT16 boards.
Local
Qmux
ASMC
ATBX
Ater interfaces
MT120
BSC +FAN MSC
TC bus
ASMC
MT120
or
+FAN
MT120
Extension / Reduction
Configuration
TC Physical Logical
Min Max Min
G2 TC 2 AterMux 6 AterMux 1 AterMux 1 AterMux
SU 2 6 1 1
ASMC 2 6 1 1
TRCU SM 4:1 4 24 4 4
MT120 - 4 1 1
Data in this table, based on [1]
Table 33: G2 TC configuration
Rules:
Each BSC must be connected to at least two MT120 boards for redundancy purposes,
refer to Table 34.
Each AterMux CS or mixed link requires one MT120 board.
Each BSC rack can have up to 6 AterMux links and therefore up to 6 MT120 boards:
these boards form a cluster inside TC and have all to be in the same TC rack (but may be
in different subracks).
The AterMux CS and mixed links are gathered in groups of 6 in order to form a complete
cluster handled by one TC; the rest of the links are grouped together and will form a
cluster too, potentially connected to another TC.
A TC rack can handle several BSCs.
3.5.3 TC Dimensioning
The TC dimensioning is based on the connectivity aspect rather than counter (or traffic) point
of view.
The concerned connectivity is the total number of required AterMUX CS links coming from
all BSCs toward to the TC.
Also, the used TC type (either G2 TC or G2.5 TC) has to be taken into account because each
type provides different configuration and capacity.
Then refer to section 3.5.2; we know that each AterMUX link needs one MT120 board
of G2.5 TC.
Therefore,
BSCa needs 10 MT120 boards
BSCb needs 12 MT120 boards
Total = 36 MT 120 boards
BSCc needs 6 MT120 boards
BSCd needs 8 MT120 boards
As 36 MT120 boards are needed, this required one G2.5 TC with 3 subracks –
refer to Table 35.
The following figure shows the BSC connection for mulit-GPU per BSS.
Sub-BSS 1
cell1
cell4 cell2
cell3
MFS
BSC
Sub-BSS2
GSL1
GPU1
cell5
cell6
cell7 GSL2
GPU2
Sub-BSS3 GSL3
GPU3
cell8
cell9 cell10
cell11 GSL4
GPU4
cell13 cell12
cell14
cell15
GPU1: cell1, cell2, cell3, cell4
GPU2: cell5, cell6, cell7
Sub-BSS4 GPU3: cell8, cell9, cell10, cell11 cell12, cell13
GPU4: cell14, cell15
• Figures of above table is taken frome [3BK 10204 0034 DTZZA]. Note that Gb over IP is not supported
on the AS800.
Methodology:
The process of GP(U) dimensioning is presented below.
GPU_for_MS_context_handling (=0/1)
GPU_GCH_Capacity GPU_for_Power_Limitation (=0/1)
Needed Number
GCHs ÷ + + of GPU
As the main input for the estimation of the number of GP(U) boards is represented by
the estimated number of needed GCHs (at BSC or GP(U) level), before being able to
apply the GP(U) dimensioning process, another process for the assessment of the
AterMux PS interface on the basis of the target user traffic must be executed.
With
quantile=99,9%
The required GCH traffic can be computed in different ways depending on the scenario:
1. Stable Network (see 3.6.3.1)
2. Feature Activation (see 3.6.3.2)
Concerning only PS traffic, the statistical law Erlang C is used during the dimensioning
process to determine the necessary resources versus the traffic and the target GoS.
As GCH resources are associated to PS traffic only, Erlang C can be applied to
calculate the required number of GCH according to required PS traffic and the grade of
service.
The Grade of Service (GoS) is defined by %Quantile of x delay second (pGP(U)). Since
the MFS always tries to assign TBFs as soon as the request is received, we usually
dimension for 0sec delay. Normally GoS should be given or agreed by the Operator.
The recommended value is 99.9% quantile of 0 delay sec.
OUTPUT
Being:
GPU_GCH_Capacity the maximum number of GCHs that the GPU can handle (see 3.6.3.3
for details on the estimation of this variable)
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 GP(U) boards needed because of GPU GCH capacity limitation (see 3.6.3.4
for details on the estimation of this variable)
GPU_For_Power_Limitation a quantity equal to 1 if a GPU power limitation is observed, no
additional GP(U) boards needed because of GPU GCH capacity limitation and
GPU_for_Ms_context_handling equal to 0 (see 3.6.3.4 for details on the estimation of this
variable).
Method 1:
Measured _ GCH _ traffic
Re quired _ GCH _ traffic =
1 − Min(%GCH _ cong ,30%)
Note: 30% is defined as the max congestion rate to be considered because several congestions can be
re-produced from one given user trying to access the network several times.
Where:
P100c
Measured _ GCH _ traffic = , and
3600
%GCH _ cong = Max{Ater _ Congestion, GPU _ Limitation} =
Max{% Ater _ Cong ,% DSP _ Cong ,% DSP _ load ,%CPU _ overload }
Where:
P383a
%GCH _ Ater _ cong = × 100%
3600
P384
%GCH _ DSP _ cong = × 100%
3600
Max( P 201, P 202)
% DSP _ load = x100%
3600
P 402
%CPU _ overload = x100%
3600
If P100c value is far different than P101 – P474, P100c is not reliable. The proposed
workaround is GP(U) reset and after that check counter values again.
Method 2:
The Method 2 is based on the relationship between GCH and PDCH traffic.
Indeed it has been observed that in normal good conditions (no congestion and not
relevant high Ater usage time percentage) the relationship between these two quantities
(that depends on the traffic profile, on parameter configuration, on the available
resources) is quasi-linear.
Required_GCH_Traffic
448
y = 5,3905x + 21,057
336
112
0
0 10 20 30 40 50 60 70 80
On the other hand, in case of GCH usage reduction (due to congestion or to the high
Ater usage handling condition) the relationship between GCH and PDCH traffic clearly
shows saturation around the available resource limit.
N.B.: This method does not allow distinguishing between a GCH usage reduction, with respect to
the target number of GCH per PDCH (i.e. on the basis of the MAX_GPRS_CS or
MAX_EGPRS_MCS), due to Abis or Ater congestion.
Since the major limitation observed up to now in the analysed networks is linked to Ater and
not to Abis, the assumption that the GCH reduction is due to Ater underdimensioning is done.
Needed_GCH
Following the
560
4th link adding
448 ERLANG C
y = 5,3905x + 21,057
Measured
GCH traffic
336
224
112
0
0 10 20 30 40 50 60 70 80
Assessment
The assessment of the Required_GCH_traffic must be done when one of the following
conditions is observed:
- Congestion is observed to be regularly greater than 0,1% (i.e. P383a/3600>0,1%)
- High Ater usage is observed to be regularly greater than 30% (i.e. P383b/3600>30%)
The goal of the method is to estimate the increase_factor to apply to the estimated
required_GCH_traffic in stable conditions. Afterwards this increase_factor will be used in
the following way:
Required_GCH_trafficafter_feature_activation = Required_GCH_trafficstable_network * increase_factor
After EDGE/CS3/CS4
Y=a1x + b1
Before EDGE/CS3/CS4
PDCH traffic
a2= a1 * Increase_Factor and b2 = b1 (approximation !)
Increase_factor =
average_target_nb_GCH_per_PDCHfinal / average_target_nb_GCH_per_PDCHinitial
b CS3/CS4 d
CS3/CS4
a
CS1/CS2 &
EDGE
c EDGE e
Being:
%PDCH_EGPRS the % of Radio Resources (PDCH) supporting at least one TBF
established in EGPRS mode on a cell with MAX_EGPRS = MCSx
%PDCH_GPRS the % of Radio Resources (PDCH) supporting only TBF established in
GPRS mode on a cell with MAX_GPRS = CSy
This theoretic capacity is then adapted to the BSS configuration and the traffic profile where
the GP(U) is used, in the following way:
The N_ATER_TS_MARGIN_GPU resources must not be taken into account in the
GP(U) capacity. Therefore the maximum theoretical number of GCH per GP(U)
becomes:
– 480 – N_ATER_TS_MARGIN_GPU*4 (for legacy MFS)
– 1560 – N_ATER_TS_MARGIN_GP*4 (for Mx MFS with GboFR)
– 1920 – N_ATER_TS_MARGIN_GP*4 (for Mx MFS with GboIP)
The fact that the maximum number of PDCH per GP(U) is dynamic depending on
the used coding schemes must be taken into account:
The fact that the maximum number of GCH is also dynamic because the number of
GCH per PDCH depends on the used coding scheme must be taken into account.
Number of required GCHs
MCS UL DL
CS UL DL
MCS-1 0,89 0,86
CS-1 0,73 0,73 MCS-2 1,00 1,00
CS-2 1,00 1,00 MCS-3 1,33 1,28
MCS-4 1,50 1,47
CS-3 1,25 1,22
MCS-5 1,86 1,81
CS-4 1,64 1,60
MCS-6 2,36 2,31
MCS-7 3,49 3,39
MCS-8 4,14 4,00
MCS-9 4,49 4,39
Therefore the maximum number of GCHs that the GP(U) 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
In DL direction the maximum number of GCHs that a GP(U) will be able to handle is
defined as:
Max_DL_GCH_GPU = (%CS1 * max_PDCH_CS1 * max_DL_GCH_CS1)+
(%CS2 * max_PDCH_CS2 * max_DL_GCH_CS2)+… (on all coding schemes)
In UL direction the maximum number of GCHs that a GP(U) will be able to handle is
defined as:
Max_UL_GCH_GPU = (%CS1 * max_PDCH_CS1 * max_UL_GCH_CS1) +
(%CS2 * max_PDCH_CS2 * max_DL_GCH_CS2)+… (on all coding schemes)
Where,
Max_Capacity is equal to 480, 1560 or 1920 GCH depending on the limitation
described above:
% (M)CSx in DL direction = P55x/sum of P55y for all coding schemes
% (M)CSx in UL direction = P57x/sum of P57y for all coding schemes
Assessment:
It is recommended to monitor the GPU GCH congestion through indicators, GP(U) Ater
congestion (P383a/3600) and GP(U) DSP congestion (P384/3600).
If we can see the GCH congestion occurring regularly e.g > 0.1% congestion, GP(U) re-
dimensioning is required.
MS context (P392a)
1000 50,0%
800 40,0%
600 30,0%
400 20,0%
200 10,0%
0 0,0%
21/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
22/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
23/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
24/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
25/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
UL TBF BSS
Failure rate
Retrieve
Retrieveindicators
indicators
for 5 working days
P392bBSC = 2000 NO
during at least 12% of
the observed period
GPU_for_MS_context_handling=0
_
YES
P392bBSC = 2000 when BSS_fail _rate max NO
Observed for all days with at least two occurrences of P392b BSC = 2000
GPU_for_MS_context_handling=0
YES
Observed QoS acceptable NO
GPU_for_MS_context_handling=1
_
for the customer ?
YES
GPU_for_MS_context_handling=0
_ =0
N.B. In B9 MR4 the observation of the number of MS context (P392a and P392b) should no
more represent a limitation in itself but a useful indication about the GP(U) load.
Retrieve indicators
for 5 working days
P402/3600 >0,1%
NO
during at least 12% of GPU_for_Power_Limitation=0
The observed period
YES
NO
P402/3600 >0,1% and cpu_cong_fail_rate > 1% OR GPU reboots GPU_for_Power_Limitation=0
observed during the CPU loaded hours)
YES
GPU_for_Power_Limitation=1
Figure 78 GPU_for_Power_Limitation due to PMU CPU load
In Figure 78,
P105e P105f
cpu _ cong _ fail _ rate= Max( ; )
P91a + P91b + P91c + P91d + P91e + P91f P62a + P62b + P62c - P438c
N.B. In the specific case of B8 to B9 migration the check of the following additional condition
was highly recommended for GPU_for_Power_Limitation variable estimation.
Indeed GPU_for_Power_Limitation = 1 if the observed board is a GPU and if the B8
measured PMU CPU average load is greater than 40%.
This recommendation is the result of ALU simulations about the CPU power budget increase
from B8 to B9.
Max(P201,P202)/3600 >0,1%
NO
during at least 12% of GPU_for_Power_Limitation=0
The observed period
YES
NO
Max(P201,P202)/3600 >0,1% and dsp_load_fail_rate > 1% OR GPU reboots GPU_for_Power_Limitation=0
Observed during the CPU loaded hours)
YES
GPU_for_Power_Limitation=1
Figure 79 GPU_for_Power_Limitation due to DSP CPU load
In Figure 79,
P 203 P 204
dsp _ load _ fail _ rate = Max( ; )
P91a + P91b + P91c + P91d + P91e + P91f P62a + P62b + P62c - P438c
WARNING: Since the methods described for GPU power limitation detection
have not yet been validated on a real network, they could evolve following B9MR4
release generalization.
Assessment:
It is recommended to monitor the PMU and DSP load through the counters (P201, P202,
P402, P76a, P77a).
If we can see that Max(201,202)/3600 or P402/3600 is regularly > 0.1%, GP(U) re-
dimensioning is required.
The BSSGP application layer is in charge of the processing of the packet traffic coming from
a set of radio cells. It manages the Gb interface and the BSSGP Virtual Connections (BVC).
The BVC is a virtual end-to-end path between BSSGP peer entities.
The BSSGP application layer relies on Network Service layer that manages the
communication paths between the Network Service Entity (NSE) of the SGSN and the MFS.
The Network Service layer is composed of two sub-layers:
• Network Service Control (NSC) is independent from the intermediate transmission network
used on the Gb interface and is responsible for:NS PDU transfer between BSS and SGSN: PDU
order is kept, except under exceptional circumstances
- Load-sharing (at the initiative of the sender)
- NS Virtual Connections (NS-VC) management
• Sub-Network Service (SNS) is dependent on the intermediate transmission network and
provides access to the intermediate network
The BVC is identified by a BVC Identifier (BVCI) that is unique in one Network Service
Entity (NSE).
The BVCI together with the NSEI uniquely identifies a BVC within a SGSN.
B S S G P la y e r
GPU m
B S S G P la y e r
GPU n BCV
BCV
BCV BCV
SGSN
BCV
BCV
BVC = one
p e r c e ll BVCI
N S la y e r L o a d s h a r in g
N SE = one per G PU
NSE
N SC sub OR N S -V C I o r R e m o te IP E n d p o in t
la y e r
N S -V C R e m o te IP e n d p o in t
PVC
SN S sub
la y e r N S -V L
IP E n d p o in t
Layer 1 IP n e t w o r k
N S -V L F R b e a re r
F R n e tw o rk
• GboFR
The GboFR interface is supported by one or several Bearer Channels on 2Mbps PCM
links.
Three configurations may be used to connect the MFS with the SGSN as described in
the following figure:
• Through a Frame Relay network
• Direct MFS-SGSN connections: this is the most chosen case of Gb connections.
• Through NSS transmission network
Gb Frame Relay Gb
1) Through a FR Network MFS Netwok
SGSN
Gb
2) Direct MFS - SGSN connections MFS
Gb
Gb
3) Through NSS transmission network MFS MSC/VLR MSC/VLR
Example of connection:
In the following figure, the MFS is connected to the SGSN through a private IP network.
The MFS is connected to “Edge Routers” through a redundant GE link.
The “Edge Routers” are seen as a single gateway IP address, which is a MFS requirement.
The Routers shall implement the VRRP protocol or an equivalent protocol like HSRP.
E1 Ater(circuit)
PDH/SDH network A TC
Ater(packet)
BSC
MSC
GE
MFS
Gb GE
Only the “O&M one LAN” configuration allows GboIP feature in B10 release.
The support of GboIP is based on IPv4 protocol only, and is defined with following
rules:
• One IP EndPoint (UDP port, IP@) per NSEI (i.e. GP(U))
• Up to 16 remote IP EndPoints per GP(U)
• Weight assignment to remote IP EndPoint for load sharing
• One single gateway IP address per MFS
Methodology:
The process of Gb dimensioning is presented below.
INPUT
The required Gb traffic is computed as below formula.
Re quired _ Gb _ traffic = Measured _ Gb _ traffic + 15%m arg in
METHOD
Concerning only PS traffic, the statistical law Erlang C is used during the dimensioning
process to determine the necessary resources versus the traffic and the target GoS.
As Gb resources are associated to PS traffic only, Erlang C can be applied to calculate
the required number of GboFR TS and GboIP throughput according to required PS
traffic and % quantile of delay time.
OUTPUT
• Gb over Frame Relay
For GboFR interface, the measured traffic corresponds to P45 and P46 counters.
Max( P 45, P 46 )
Measured _ Gb _ traffic =
28800
Then the required number of bearer channels (i.e. 64kbps TS) is as follows:
Notes:
1 Erlang = [Gb TS speed (64kbps) * 3600] / 8 =28800 K bytes
Minimum 2 Gb links are required for one GP(U) due to security reason
Maximum 31 Gb TS (TS no. 1 to 31) can be configured per one GboFR link. TS0
cannot be used as it is reserved for specific usages e.g. frame synchronization.
In general, around 4 to 8 TS are configured per one GboFR link.
The overall overhead depends on the traffic flow characteristics (IP packets size).
As an average value, the estimated overhead is about 35% for an IP PDU of 300 bytes.
1) When the GboIP interface is used, the measured traffic is given with P45a and
P46a counters.
Then the required GboIP throughput takes into account the header as follows:
2) When Gb traffic is transported over GboFR interface and then migrated over
GboIP interface (i.e. IP), the measured traffic is given by GboFR counters.
The measured Gb shall take into account the removal BSSGP/NS/FR header
and the addition of the BSSGP/NS/UDP/IP/Ethernet header:
Measured _ GboIP _ traffic = Measured _ Gb _ traffic * (300 + 118) /(300 + 54)
Then,
GboIP throughput required per MFS
= Erlang C (Required_GboIP_traffic; pGb)
Notes: Overhead from GboFR to GboIP = [300 + 118] / [300 + 54] = 18,1%.
In following table, there is the summary showing the GCH usage gain in B9 - thanks to
M-EGCH compared to B8 for each coding scheme. For instance, to support MCS 9,
there are 40 GCHs per TRX needed in B8 but only 36 GCHs per TRX needed in B9.
In Figure 82, there is a noticeable waste of Abis resources in B8 release linked to static
Abis allocation but it can be improved from B9 with dynamic Abis allocation feature
which can manage to use basic Abis nibbles mapping to signalling channels i.e. BCCH
and SDCCH (so called bonus basic nibbles) and all extra Abis nibbles for PS traffic –
so no more wasted Abis nibbles from B9.
Dynamic Abis allocation is mandatory feature (automatically enabled) in B10 (since B9
release).
64kbps timeslot # n
Figure 88: Better transmission resource usage with DL retransmission in the BTS
Without DL Retransmission in the BTS, the RLC/MAC layer shall retransmit the
complete DL RLC data block to the TRE when retransmission needed – so called
“complete” retransmission – B8 case.
If DL Retransmission in the BTS is activated, the RLC/MAC layer may take the benefit
to store RLC data block by TRE in the BTS. In this case, the RLC/MAC layer may
retransmit to the TRE only RLC/MAC header and ask the TRE to add RLC data block
before transmission to the MS – so called “reduced” retransmission – B9 case.
DL Retransmission in the BTS is optional feature, which can be enabled/disabled at
TRX/TRE level. In order to save transmission resource, it is recommended to activate
this feature.
Thus, the total CS traffic really handled by Mx BSC could be limited by the restriction of CIC
number on A-interface (Ater-CS interface as well), rather than the hardware or software
capacity of the Mx BSC itself.
With this limitation, the total traffic that can be “coded” on CIC field is less than 3980Erlang.
This implies a reduction of about 600Erlang regarding the real capacity of the Mx BSC.
In order to overtake the 4096 CIC limitation, the Mx BSC will support the CIC coded on 16-
bits field from B10 release. The CIC code extension to 16-bits field is done with the use of the
4 spare bits in the header.
The CIC code limitation will be eliminated if the connected MSC also supports the 16-bits
CIC code, such as the A5060 Spatial Atrium Call Server (Alcatel-Lucent NGN solution).
At MSC level, the HSL function could be based on two different options;
Two un-channelized 2Mbps PCM links (TS0 + data bulk of 1984kbps)
working in a redundant and load sharing purposes
Two structured 2Mbps PCM links (up to 16 TS per PCM)
The Alcatel-Lucent solution is based on two un-channelized HSL links structured with a
synchronisation TS0 as usual and a data channel of 1984kbps).
To conclude, the CS Core Network that will be interconnected to large Mx BSC (traffic load
higher than 2000Erlang) shall support the un-channelized HSL feature.
For interoperability purposes between Alcatel-Lucent Mx BSC and CS Core Network, the
CSCN elements supporting the HSL feature are:
Legacy MSC equipped with RCP A8362M + Umax EP6
NGN release W4.21
An additional requirement is to be checked; it concerns the signalling mode between BSS and
the MSC.
When MSC supports only the quasi-associated mode of signalling with the BSS, STP
functionality (Signalling Transfer Point) shall be provided outside the BSS (cf. TS 48.006).
As only IPv4 is supported at MFS side, the SGSN shall also support IPv4 protocol.
In the case of GboIP feature, the synchronization clock cannot be extracted from the SGSN.
The following configurations shall be considered:
- In “mixed Gb mode” (FR and IP): clock synchronization can be extracted from the GboFR links
- In GboIP with existing links between MFS & TC: clock synchronization for Ater TDM can be
extracted from the TC links
END OF DOCUMENT