BSSP&O Guidebook

BSS Planning and
Optimization Guidebook
Guidebook for BSS Engineers

This document contains the procedures, practices and rules used for
designing the BSS networks.

2010
BSS Planning and Optimization Team
RAN Planning and Optimization

Edition & Date 1.0 & 05-July-10
Document Change
Owner
Mohammad Omer Ismail
Reviewed &
Approved By

Manager RAN BSS P & O (Arif Khan)
Assistant Manager RAN P&O (Ali Aamer Khan)
First Edition
05-July-10
First Draft
05-July-10
Document Location
\\10.7.26.125\BSS Shared Documents\BSS
Planning Master Documents\BSS P&O Guidebook

TABLE OF CONTENTS

1 PURPOSE ............................................................................................................................7
2 SCOPE .................................................................................................................................7
3 INTRODUCTION .............................................................................................................7
4 BSS P&O PROCESS OVERVIEW ...................................................................................7
4.1 STEP: 1 NSS, RF AND COMMERCIAL INPUTS FOR PLANNING AND FORECASTING ....................... 8
4.2 STEP: 2 MAKING NEW YEAR TECHNICAL AND FINANCIAL PLANS ............................................... 8
4.3 STEP: 3 CO-ORDINATION AND SUPPORT ........................................................................................ 9
4.4 STEP: 4 OPTIMIZATION .................................................................................................................. 9
5 BSS P&O FUNCTIONS ....................................................................................................9
6 EXPECTATIONS FROM BSSP&O ............................................................................... 10
7 OSS PLANNING AND OPTIMIZATION ................................................................... 10
7.1 OSS INTRODUCTION .................................................................................................................... 10
7.2 NMS(S) IN TP BSS NETWORK ..................................................................................................... 11
7.2.1 SIEMENS RADIO COMMANDER INTRODUCTION: ....................................................................... 11
7.2.2 NOKIA NETACT INTRODUCTION: .............................................................................................. 12
7.3 NMS(S) CAPACITIES .................................................................................................................... 12
7.3.1 NOKIA NETACT RC CAPACITIES: ............................................................................................... 12
7.3.2 SIEMENS RADIO COMMANDER CAPACITIES: ............................................................................. 13
7.4 NEW NMS REQUIREMENT CRITERIA ........................................................................................... 13
7.5 NEW NMS PLANNING................................................................................................................. 14
7.6 NEW NMS DEPLOYMENT ............................................................................................................ 14
7.7 NMS PERFORMANCE ANALYSIS .................................................................................................. 15
7.7.1 NMS PERFORMANCE ANALYSIS TOOLS .................................................................................... 16
7.8 NMS OPTIMIZATION ................................................................................................................... 17
8 NEW BSC PLANNING REQUIREMENT AND DEPLOYMENT .......................... 17
8.1 BSC TYPES INTRODUCTION: ........................................................................................................ 17
8.2 INPUTS REQUIRED FOR BSC PLANNING: ..................................................................................... 18
8.2.1 SUBSCRIBER FORECAST. ............................................................................................................ 18
8.2.2 TRX COUNT. ............................................................................................................................. 18
8.3 METHODOLOGY: .......................................................................................................................... 18
8.3.1 NOKIA BSC REQUIREMENT CALCULATION FORMULA ............................................................... 20
8.3.2 SIEMENS BSC REQUIREMENT CALCULATION FORMULA ........................................................... 21
8.4 BSC DEPLOYMENT: ...................................................................................................................... 22
8.4.1 LOCATION SELECTION: .............................................................................................................. 22
8.4.2 BOUNDARY DEFINITION: ........................................................................................................... 22
8.4.3 DATA COMPILATION: ................................................................................................................ 22
8.5 BTS MIGRATION: ......................................................................................................................... 23
8.5.1 NCT PREPARATION: .................................................................................................................. 23
8.5.2 SITE PRIORITY ASSIGNMENT AND RF DATA VERIFICATION: ....................................................... 24
8.5.3 RE-PARENTING WO GENERATION: ............................................................................................ 24
9 BSC RESOURCE OVERLOAD ...................................................................................... 24
9.1 BSC PROCESSOR OVERLOAD ....................................................................................................... 25
9.1.1 HOW TO CHECK PROCESSOR LOADS ........................................................................................... 25
9.1.2 EXAMPLE OF HIGH PROCESSOR LOADS ...................................................................................... 25

9.1.3 HOW TO REDUCE THE PROCESSOR LOADS ................................................................................. 26
9.2 BSS SIGNALING LINKS OVERLOAD.............................................................................................. 26
9.2.1 HOW TO CHECK THE SIGNALING LOADS ..................................................................................... 26
9.2.2 CURRENT SIGNALING LINKS CONFIGURATION IN TP NETWORK: ............................................... 27
9.2.3 WAYS TO DECREASE THE LOAD ................................................................................................. 28
9.2.4 MULTI POINT A- INTERFACE SOLUTION IN NOKIA LAND .......................................................... 29
10 ATER ADDITION PROCESS ........................................................................................ 30
10.1 ATER INTRODUCTION ................................................................................................................ 30
10.2 ATER ADDITION REQUIREMENT: ............................................................................................... 30
10.3 ATER ADDITION PROCESS:......................................................................................................... 31
10.4 ATER ADDITION PROCESS IN SIEMENS: ..................................................................................... 31
10.5 ATER ADDITION PROCESS IN NOKIA: ........................................................................................ 34
10.5.1 DAT (DIRECT ATER TERMINATION) ........................................................................................ 34
10.5.2 TCSM RACKS .......................................................................................................................... 34
10.5.3 NOKIA ATER ADDITION APPENDIX ......................................................................................... 36
11 ABIS/ TRX DIMENSIONING AND EXPANSION..................................................... 37
11.1 CHANNEL TYPES ........................................................................................................................ 37
11.2 EXPANSION REQUIREMENT ....................................................................................................... 38
11.3 STAKEHOLDERS ......................................................................................................................... 38
11.4 EXPANSION PROCESS IN NOKIA BTS ......................................................................................... 38
11.5 EXPANSION PROCESS IN SIEMENS .............................................................................................. 40
12 Licensing ........................................................................................................................... 42
12.1 INTRODUCTION .......................................................................................................................... 42
12.2 LICENSING BSS PRODUCTS ........................................................................................................ 42
12.2.1 NOKIA BSS LICENSES .............................................................................................................. 42
12.2.2 SIEMENS .................................................................................................................................. 43
13 LAPD PLANNING .......................................................................................................... 43
13.1 INTRODUCTION .......................................................................................................................... 43
13.2 ABIS LAPD DIMENSIONING ASPECTS ....................................................................................... 43
13.3 LAPD DIMENSIONING IN SIEMENS BSCS .................................................................................. 44
13.3.1 CBSS LAPD CAPACITY: ........................................................................................................... 44
13.3.2 EBSS LAPD CAPACITY: ........................................................................................................... 45
13.4 LAPD DIMENSIONING IN NOKIA BSCS .................................................................................... 46
14 LAC PLANNING ............................................................................................................. 46
14.1 LOCATION AREA: ...................................................................................................................... 46
14.2 LOCATION AREA CODE: ............................................................................................................ 47
14.2.1 LAC THRESHOLDS: .................................................................................................................. 47
14.3 NEW LAC PLANNING: ............................................................................................................... 48
14.4 LAC LOAD BALANCING ACTIVITY: ........................................................................................... 49
14.5 LAC SPLIT ACTIVITY: ................................................................................................................ 50
15 LAC OPTIMIZATION .................................................................................................... 51
15.1 INTRODUCTION .......................................................................................................................... 51
15.2 PAGING CAPACITY FOR BSC AND LAC .................................................................................... 51
15.3 PAGING PARAMETERS & STATISTICAL COUNTERS .................................................................... 51
15.4 PAGING KPIS ............................................................................................................................ 52
15.5 PAGING TECHNICAL BACKGROUND ....................................................................................... 52
15.6 PAGING GROUPS ........................................................................................................................ 52

15.7 QUEUING IN THE BTS ................................................................................................................ 53
15.8 PAGING STRATEGIES .................................................................................................................. 54
15.9 PAGING OVERLOAD CONDITION ............................................................................................... 56
15.10 LAC SPLITS .............................................................................................................................. 56
16 GPRS PLANNING........................................................................................................... 57
16.1 GPRS/EGPRS PLANNING IN NOKIA BSS ................................................................................ 58
16.1.1 ABIS EDGE DIMENSIONING ..................................................................................................... 58
16.1.2 DYNAMIC ABIS ....................................................................................................................... 59
16.1.3 DYNAMIC ABIS CAPABILITIES................................................................................................... 60
16.1.4 NOKIA PCU PRODUCT FAMILY AND FEATURES ...................................................................... 61
16.1.5 NOKIA PCU DIMENSIONING ................................................................................................... 62
16.2 GPRS/EGPRS PLANNING IN SIEMENS BSS .............................................................................. 63
16.2.1 ABIS EDGE DIMENSIONING ..................................................................................................... 63
16.2.2 SIEMENS PCU PRODUCT FAMILY AND FEATURES ................................................................... 64
16.2.3 SIEMENS PCU DIMENSIONING ................................................................................................ 65
16.3 GB INTERFACE PLANNING ........................................................................................................ 66
16.3.1 GB INTERFACE INTRODUCTION ............................................................................................... 66
16.3.2 GB LINK DIMENSIONING .......................................................................................................... 67
16.3.3 GB LINK DIMENSIONING BSS POINT OF VIEW ....................................................................... 67
16.3.4 GB LINK DIMENSIONING EXAMPLE BSS VIEW....................................................................... 68
17 DATA NETWORK OPTIMIZATION........................................................................... 68
17.1 ABIS CONGESTION: ................................................................................................................... 69
17.1.1 NOKIA EDAP POOL BLOCKING ............................................................................................... 69
17.1.2 SIEMENS EDAP POOL BLOCKING ............................................................................................ 71
17.2 PCU CONGESTION: .................................................................................................................... 72
17.2.1 NOKIA PCU CONGESTION ....................................................................................................... 72
17.2.2 SIEMENS PCU CONGESTION.................................................................................................... 74
17.3 GB UTILIZATION & CONGESTION: ............................................................................................. 76
17.3.1 MEASURING GB UTILIZATION & CONGESTION ......................................................................... 76
17.3.2 CUSTOMIZED REPORT KPI(S) & COUNTERS (SGSN): .............................................................. 77
17.3.3 KEY PERFORMANCE INDICATORS ............................................................................................ 78
17.3.4 GB OPTIMIZATION: .................................................................................................................. 79
18 ANNEXURE ...................................................................................................................... 80
18.1 SIEMENS BSC CAPACITIES ......................................................................................................... 80
18.2 NOKIA BSC CAPACITIES ............................................................................................................ 81
18.2.1 NOKIA BSC FACT SHEET ......................................................................................................... 81

Figure 1 NetAct RC1 Capacity .......................................................................................................... 12
Figure 2 NetAct RC3 Capacity .......................................................................................................... 13
Figure 3 Radio Commander RC1 Capacity ...................................................................................... 13
Figure 4 Radio Commander RC2 Capacity ...................................................................................... 13
Figure 5 NMS Deployment Procedure.............................................................................................. 15
Figure 6 NMS Weekly Performance Report ..................................................................................... 16
Figure 7 BSC High Processor Loads due to feature activation ....................................................... 26
Figure 8 BSC to MSC Signaling Connectivity................................................................................... 28
Figure 9 MOPC Connectivity ............................................................................................................ 29

Figure 10 MOPC Logical Diagram .................................................................................................... 30
Figure 11 Expansion Process ............................................................................................................. 41
Figure 12 Siemens BSCs LAPD Capacities ....................................................................................... 46
Figure 13 Paging Groups and Frame Intervals ................................................................................ 53
Figure 14 LA with 2 cells Combined and 8 cells Noncombined ..................................................... 55
Figure 15 Paging Overload in Siemens BSS - BTS discards a PAGING REQUEST Message ....... 56
Figure 16 EGPRS Coding Schemes Characteristics .......................................................................... 60
Figure 17 Nokia PCU Product Family .............................................................................................. 61
Figure 18 GB Interface ........................................................................................................................ 67
Figure 19 Date Network Main Interfaces .......................................................................................... 69
Figure 20 PCU Resource Utilization ................................................................................................. 74
Figure 21 SCANGPRS Counters ........................................................................................................ 75
Figure 22 PDT Rejections due to PCU Overload .............................................................................. 76

Table 1 Expansion Request Sheet ...................................................................................................... 39
Table 2 Nokia BSCs LAPD Capacities .............................................................................................. 46
Table 3 PCU Types and Capacities ................................................................................................... 62
Table 4 PPXX Cards and No. of PDTs ............................................................................................... 65
Table 5 K Factor for GB Dimensioning ............................................................................................. 68

1 PURPOSE
This document intends to give an overview of the functions of BSS planning &
optimization and describes the process of implementation of those functions. It contains
the planning and optimization guidelines along with the strategies to meet the BSS
design requirements.
2 SCOPE
This document will analyze all the different aspects of BSS planning &
optimization. Each chapter will provide a description of the approach to the specific
task, followed by the criteria, the parameters and the quality objectives. The guidelines
given in this document have been extracted from vendors recommendation and
industry standards. Any deviations from the vendor recommendation have been
discussed and approved. Any amendments in the guidelines will have to be discussed
and approved before being applied.
3 INTRODUCTION
BSS planning and optimization is a sub division of RAN P&O department. The
department is responsible to plan and dimension the base station subsystem (BSS) in
such a way that the performance experienced by the end-users is not limited by an
overload in the BSS. The objective of the department is to accommodate the capacity
requirements for voice, data, signaling and OSS services while maintaining the
performance of a high quality network.
4 BSS P&O PROCESS OVERVIEW
Forecasting to planning to budgeting to implementation and optimization
BSS planning department is responsible for planning and optimization of BSS
network. The BSS planning process starts from making the budgets and plans for the
year based on the inputs from NSS and RF department. The inputs contain the
subscriber and traffic forecast, and new sites and expansion information. These inputs
are produced from the feedback of commercial department. After gathering all the
required information, current network status is assessed and then a precise year plan is
made after taking into consideration the allocated budgets.

After planning, the department ensures the smooth implementation of the plans
and provides support to implementation teams when needed. After the
implementation, BSS network quality is maintained through performance analysis and
optimization.

In the sections below, a brief description of all the steps involved in making New
Year plan are given.

4.1 Step: 1 NSS, RF and Commercial Inputs for Planning and Forecasting
The first step in making a year plan is to gather the key information from NSS and
RF departments. An input of good quality and detail is one of the keys to make a good
forecast and plan. These inputs include, but not limited to:

Expected Network Traffic (Area Wise)
This is drawn by monitoring and analysis of daily network level BH and total daily
traffic trends. This information is then used to assess mErl/Sub region/city wise.
Expected Network BHCA
This is drawn by monitoring and analysis of daily BHCA at the Network BH trends.
From this input BHCA/Sub is approximated which will be used in the dimensioning.
Subscribers Forecast
Based on the inputs from marketing and commercial department, NSS assumes the
expected growth in the subscriber base. Together will the expected traffic per subscriber
and region wise distribution, these are the primary inputs which decides the number of
resources required.
Rollout and Expansion Plans
Rollout and expansion plans from RF are required to determine the resource
availability and requirement in the specific cities/BSCs.
4.2 Step: 2 Making New Year Technical and Financial Plans
In step 2, the BSS planning department does the BSS network analysis, based on the
inputs mentioned above, to determine the resources and budgets required, needs of
rehomings and module expansions etc. The analysis procedure takes into account:

Current BSS Network Capacities
BSS network existing capacities are analyzed by monitoring and analysis of Weekly
and Monthly traffic reports for a period. Based on the current trends, the expected loads
are calculated and over/under utilized resources are identified. This analysis will help
in determining the number of resources required.
Complete cumulative RAN inventory
A complete RAN inventory is maintained which includes the total number and
configurations of TRXs, CELLs, SITEs, BSCs, PCUs as well as any other access
equipment. The inventory specifies the equipment in the Warehouse or delivery which
is scheduled.

Inputs from NSS, BSS inventory and the BSS network analysis are used for HW
calculation on macro level. This calculation gives required number of BSCs,
Trasnscoders, PCUs, TXN media requirement for ATERs etc.

4.3 Step: 3 Co-ordination and Support
BSS planning team doesnt confine itself to planning functions but actively
participates in all the implementation activities as well. The department ensures that all
the activities are being carried out according the plan and pre/post tests are being done
to ensure the quality. Following are the key BSS planning functions in implementation
domain:

Making plans for implementation and generating work orders
Acting as vendor interface
Providing support during crucial activities
Monitoring of post activity performance of the relevant network elements
4.4 Step: 4 Optimization
Optimizations and reporting is another function of the BSS planning department
which prepares reports on daily/weekly/monthly basis. These reports are used for
budgeting, planning and optimization of the BSS network. Based on these reports, the
team works to achieve the KPI values required for a quality network. Since BSS has the
central function in the basic GSM network therefore along with its target KPIs, BSSP&O
helps other department in achieving their KPIs target as well.
5 BSS P&O FUNCTIONS
BSS P&O is responsible to handle all kind of traffic passing through the BSS
network. Following list contains the description of all major functions of the
department.
BSC Planning:
BSC planning is done to accommodate the offered traffic, busy hour all attempts and
signaling loads.
GPRS Resource Planning:
GPRS resource planning is done to ensure that end user never faces any congestion
on Abis and GB interfaces.
PCU Planning:
PCU planning is done to provide the required capacity in the PCUs to handle the
data traffic going through the BSC.
Abis Planning:
Abis planning is done to provide the required Abis resources to accommodate voice,
data, signaling and O&M traffic.
LAC Planning:
LAC planning is required to keep the paging and signaling load on the sites and
BSCs within the design limits.
Performance Analysis:
Performance analysis is done to evaluate and analyze BSC level GPRS performance,
Traffic, BH Call attempts, Signaling loads, E1 Interface Congestions (Abis, Aters),

Paging and location updates, data network performance analysis in order to keep a
check on network performance and for timely highlighting the degradation issues
through daily/weekly/monthly reports
Optimization:
Optimization activities like parametric changes, boundary revisions, resource
allocation to counter congestion, expansions etc. are done in order to maintain the
quality of the network
OSS Planning and Performance:
Required for efficient and effective handling of O&M tasks in the access network.
Performance analysis is done to ensure that no NMS go in a congestion state.
BSS Upgrades:
Evaluation of new softwares by the vendors, conducting the trial of new loads,
benchmarking and comparative study with the existing software loads and
recommendations to the management
Every day Jobs
BSS Level Features Activation, network nodes load balancing, load distribution, BSS
network audits are the other major functions that are being carried out by the
department in routine.
6 EXPECTATIONS FROM BSSP&O
BSSP&O has always set high targets and have managed to achieve those targets as
well. This has only been possible by setting very high standards for itself. Setting high
standards mean that we have high expectations from ourselves as well as from the
management. Our objective is to understand our customers (internal/external)
demands and deliver accordingly. The following list contains the summary of what we
expect from our selves.

Friendly and supportive behavior
Respect for others
Efficient time management
Building Relationship and reducing gaps
Maintaining a high level of performance
Knowledge sharing
Effective resource utilization, budget utilization, timely escalation of performance
degradation
7 OSS PLANNING AND OPTIMIZATION
7.1 OSS Introduction
BSS planning & optimization is responsible for providing the required resources to
do the O&M tasks from a centralized location. The O&M traffic from the BSS nodes is
carried to centralized machines, called NMS or OSS, through LAPD and IP (or X25)
protocols. This O&M data is required for carrying out the following tasks.

Alarm Monitoring
Configuration Management
Log Management
Performance Management

All of these tasks are done through NMS (or OSS) systems. Once the O&M data
arrives at NMS system, these systems converts it into a readable format which is then
used to perform all these tasks.
7.2 NMS(s) in TP BSS Network
TP network contains the BSS network of two technologies namely Siemens and
Nokia. Each technology has a unique way of handling the O&M tasks therefore we
require a Siemens NMS for handling Siemens O&M while a Nokia NMS is required for
Nokia BSS.

Following are the types of NMS system in our network.
Radio Commander For Siemens BSS
NetAct Radio Cluster For Nokia BSS

The table below contains the summary of the NMS systems in TPs BSS network.

Technology System Name Platform Software Version
Nokia
NetAct RC 1
HP
OSS 5.1
NetAct RC 3 OSS 4.2
Siemens
RCOMP1
SUN
BR 9.0
RCOMP2 BR 9.0

7.2.1 Siemens Radio Commander Introduction:
The basic core package of the Radio Commander includes the essential components
for operating and maintaining the mobile radio network and for keeping the system
open for new technologies. Technology plug-ins for GERAN and UTRAN provide
support for the network elements of the different radio technologies. The optional
application packages include:

RC-NMC Q3 or CORBA (only for UTRAN) interface
Open N-interfaces such as SQL, file interface
full O&M support for GPRS and EDGE
GUI customization facilities
O&M ToolSet (OTS) application modules and open N-interfaces

7.2.2 Nokia NetAct Introduction:
NetAct is based on open interfaces and industry standards such as the Next
Generation OSS (NGOSS) and third Generation Partnership Project (3GPP) and
TeleManagement Forums eTOM model. NetAct covers the following parts of the
overall OSS space:

TMN Layers: NetAct covers the network management and the service management
layers. NetAct can also be used as Sub-Network-Management-System, where it
manages the sub network only.
FCAPS coverage: NetAct covers: (FM) Fault Management, (CM) Configuration
Management, (AM) Accounting management, (PM) Performance Management, (SM)
Security Management.
eTOM coverage: Inside the Customer Operations Processes of eTOM (Fulfilment,
Assurance and Billing), NetAct covers the Assurance part with components like
SQM, NWW (Monitor), Reporter, Traffica, and Trace. NetAct covers the Fulfilment
part with components like NetAct Configurator and Optimizer for RAN and BSS
networks. NetAct does not provide components for Billing.
Multi-Technology: NetAct manages different network technologies, including 2G
BSS & NSS, Packet Core, 3G RAN.
Multi-Vendor: NetAct can be easily adapted to the equipment of 3
rd
party vendors.
7.3 NMS(s) Capacities
The sections below will illustrate the current and offered capacities of NMS (OSS)
systems in TP network.
7.3.1 Nokia NetAct RC Capacities:
The following graphs illustrate the offered and current capacity of Nokia NetAct
systems.

Figure 1 NetAct RC1 Capacity

Figure 2 NetAct RC3 Capacity
7.3.2 Siemens Radio Commander Capacities:
The following graphs illustrate the offered and current capacity of Siemens Radio
Commander Systems.

Figure 3 Radio Commander RC1 Capacity

Figure 4 Radio Commander RC2 Capacity
7.4 New NMS Requirement Criteria
A new NMS is only deployed if any of the below mentioned conditions arise:

TRX Utilization of existing systems reaches 70%
End of Support/Maintenance announcement by the vendor
7.5 New NMS Planning
While planning the ordering of a new NMS, following things shall be ensured.
New NMS should be able to handle the capacity requirement of at least 1-2 years
o This is usually done by checking the TRX expansion forecasts given by
RF/commercial department
New NMS package should at least include the services offered by the existing NMS
systems
o This is usually done by comparing the new offer with the PO (Purchase
Orders)/BOQ of the previous NMS system(s) offer
7.6 New NMS Deployment
The figure below illustrates the procedure of deployment of a new NMS system. A
complete description of the deployment procedure can be found in attachments.

Figure 5 NMS Deployment Procedure
7.7 NMS Performance Analysis
NMS performance analysis is important for keeping a check on the capacity
utilization and performance of the NMS systems. A regular and good analysis makes
sure that system never reaches an overload situation which can potentially cause an
outage on the system level. An outage on NMS level means that network will not be
accessible during the outage time.

7.7.1 NMS Performance Analysis Tools
BSS planning & optimization uses the following ways/tools to monitor the
performance the NMS systems.
7.7.1.1 Cacti
Cacti provide a way for proactive monitoring of all OSS Systems in order to keep
them in good health. SNMP protocol has been used to monitor the NMS systems
effectively with minimum overhead on system performance. It provides rapid
deployment and wealth of performance graphs which can provide an insight to
problems in a proactive way.

User can access the Cacti application using the following way.
http://edr.telenor.com.pk/cacti
User Name: Telenor
Password: Telenor@123
7.7.1.2 NMS Capacity Reports
NMS capacity reports are shared by the vendor OSS team on weekly basis. These
reports contain the summary of NMS KPIs. The report contains the average and
maximum utilizations of CPUs, RAM and File System in a weeks time.

Figure 6 NMS Weekly Performance Report

A complete report is attached with this document in the attachments section.
7.8 NMS Optimization
NMS optimization process takes the input from the performance analysis results.
If any of the below mentioned KPIs reaches the 70% mark, that NMS machine is
considered for optimization.

Following are the KPIs being monitored.
CPU Usage
DB Load/DB Used Space

There are two types of optimization techniques being used by BSS planning and
optimization.

1. Load Balancing
The most common cause of system resources overload is uneven loading/load
distribution in the existing resources. In order to rectify the overload problem, BSC
shifting between RCs is done in order to make an even TRX loading on existing NMSs.

The following checks have to be made while making such a load balancing plan.
Check-1: Make sure that the load distribution plan does not alter the regional
boundaries set by operations, NOC and RF departments.
Check-2: Processor and DB Loads of all the NMSs involved in the load balancing
activity should be checked.

2. Operations Escalation
In a case where the load balancing is either not possible or no NMS has enough
room available or the NMS loading is within the planning limits, we consider to escalate
the critical utilization problem to TP OSS operations team. This type of problem is
usually resolved by either by doing:

DB cleanup
Unnecessary process kill
Killing inactive user sessions
Reducing the data retention periods
Implementation of some correction patch or any technique proposed by 3
rd
line
support (Product Line by NSN)
8 NEW BSC PLANNING REQUIREMENT AND DEPLOYMENT
8.1 BSC Types Introduction:
In Telenor Pakistan, BSS equipment of two different vendors is installed, Nokia
and Siemens. Each vendor has provided two versions of BSC equipment in our

Network. Each BSC has its own specifications and hence capacity constraints. Some
major capacity limiting factors that are considered while planning a BSC are mentioned
below:
Nokia
BSC3i 660: Traffic Capacity = 3920 Erl, TRX Capacity = 660
BSC3i 2000: Traffic Capacity = 11880 Erl, TRX Capacity = 2000
Siemens
cBSC: Traffic Capacity = 4800 Erl, TRX Capacity = 900
eBSC: Traffic Capacity = 10000 Erl, TRX Capacity = 2000

It is important to note that a new BSC is planned at 70% loading with respect to
traffic and 90% loading with respect to TRX(s).
8.2 Inputs Required for BSC Planning:
At the start of each year the below mentioned forecasts are required by BSS
planning to calculate the requirement of a new BSC node. Without these inputs, it is
impossible to determine the BSC requirement.
8.2.1 Subscriber Forecast.
A BSC wise subscriber count is required for the coming year based on which the
total expected traffic is calculated. BSS planning expects to receive this input divided
into quarterly subscriber forecast. The subscriber count is translated in to traffic
(Erlangs) through the below mentioned formula:

Traffic/subscriber in 2009 has been 18 mErl.
8.2.2 TRX Count.
TRX count is the second vital input that is required for the calculation of BSC nodes
requirement. It is expected to be provided in the below format:

Rollout site Count per BSC per quarter (for total rollout TRX count, a standard
configuration of 222_222 is assumed for each site and the site count is multiplied by
12).
TRX Expansion count per BSC per quarter.
8.3 Methodology:
The BSC requirement calculation is done based on the previously mentioned inputs
provided to BSS planning. The methodology for this calculation is detailed below:

TRX and Traffic utilization weight age in percentage is calculated per city as a first
step. This is done through the below mentioned formulae:

o Y1 = TRX utilization %age per city.
o X1 = Total TRX in city.
o X2 = Total TRX in Region.

o Y2 = Traffic utilization %age per city.
o Z1 = Total Traffic in city.
o Z2 = Total Nationwide Traffic.
This calculation is done for the current and previous years and the weightage
trend is analyzed. Based on this trend the percentage weightage is extrapolated for
the coming year.
The City wise TRX count and Traffic for the next year is calculated through the
below mentioned formulae:

o S1 = Total Forecasted TRX Count per city.
o X1 = Current TRX count per Region.
o X2 = Forecasted Rollout TRX count per Region.
o X3 = Forecasted TRX expansion count per Region.
o X4 = TRX %age utilization per city.

o S2 = Total Forecasted Traffic per city.
o X1 = Total Forecasted Nationwide Traffic (Calculated previously from the
forecasted subscriber count).
o Y2 = Traffic utilization %age per city.

We have calculated the city wise forecasted Traffic and TRX count for the next year.
Now we will determine the current city wise offered Traffic and TRX count. This is
done through the below mentioned formulae:

o R1 = Offered TRX count per city.
o X1 = Nokia BSC3i 660 count per city.

o X3 = Siemens cBSC count per city.
o X4 = Siemens eBSC count per city.
o T = Planning Threshold (90%)

o R2 = Offered Traffic per city.
o X3 = Siemens cBSC count per city.
o X4 = Siemens eBSC count per city.
8.3.1 Nokia BSC Requirement Calculation Formula
Now we have the forecasted and offered TRX and Traffic values, from these we
can determine whether a BSC is required in a city or not through the below mentioned
formulae:

For TRX:
IF ((S1 - R1)> ((X1 * Z1) + (X2 * Z2)))
Then
CEILING ((S1 - R1)/ (2000 * T / 100), 1)
Else
0
o X1 = TRX threshold per BSC2000 (current value set at 40).
o Z1 = BSC2000 count per city.
o X2 = TRX threshold per BSC660 (current value set at 26).
If the difference between forecasted TRX count and the offered TRX count is greater
than the weighted sum of both BSC2000 and BSC660 at a user defined BSC threshold
value then the difference is divided by the total TRX capacity of a BSC3i 2000 with 90%
dimensioning criteria, this provides the desired BSC count in a city. Otherwise if the
if condition is false the result is zero. This means that the forecasted TRX can be
catered for with the existing BSC(s).

For Traffic
IF ((S2 - R2)> ((X1 * Z1) + (X2 * Z2)))

Then
CEILING ((S2 - R2)/ (11880 * T / 100), 1)
Else
0
o X1 = Traffic threshold per BSC2000 (current value set at 500 Erl).
o X2 = Traffic threshold per BSC660 (current value set at 200 Erl).
If the difference between forecasted Traffic and the offered Traffic is greater than the
weighted sum of both BSC2000 and BSC660 at a user defined BSC threshold value then
the difference is divided by the total Traffic capacity of a BSC3i 2000 with 70%
IF condition is false the result is zero. This means that the forecasted Traffic can be
8.3.2 Siemens BSC Requirement Calculation Formula
For TRX
IF ((S1 - R1)> ((X1 * Z1) + (X2 * Z2)))
Then
CEILING ((S1 - R1)/ (2000 * T / 100), 1)
Else
0
o X1 = TRX threshold per eBSC (current value set at 40).
o Z1 = eBSC count per city.
o X2 = TRX threshold per cBSC (current value set at 26).
o Z2 = cBSC count per city.
If the difference between forecasted TRX count and the offered TRX count is greater
than the weighted sum of both eBSC and cBSC at a user defined BSC threshold value
then the difference is divided by the total TRX capacity of a BSC3i 2000 with 90%
if condition is false the result is zero. This means that the forecasted TRX can be

For Traffic
IF ((S2 - R2)> ((X1 * Z1) + (X2 * Z2)))

Then
CEILING ((S2 - R2)/ (10000 * T / 100), 1)
Else
0
o X1 = Traffic threshold per eBSC (current value set at 500 Erl).
o Z1 = eBSC count per city.
o X2 = Traffic threshold per cBSC (current value set at 200 Erl).
o Z2 = cBSC count per city.
If the difference between forecasted Traffic and the offered Traffic is greater than the
weighted sum of both eBSC and cBSC at a user defined BSC threshold value then the
difference is divided by the total Traffic capacity of a BSC3i 2000 with 70%
IF condition is false the result is zero. This means that the forecasted Traffic can be
8.4 BSC Deployment:
So far we have calculated the requirement for addition of BSC node in a city. Now
we go through the steps involved in BSC deployment.
8.4.1 Location Selection:
BSS planning initiates a request to Site design, power planning, real estate, security
and TXN planning teams to suggest a suitable location in the city for the deployment of
the BSC. It is preferred to deploy a BSC on a MGW or Green Field location but if a
concern is raised from any of the above mentioned stakeholders that MGW or Green
Field location is not feasible then a shelter site is selected after mutual agreement
between all stakeholders. Thereafter, site design and power planning teams are
requested to reserve power and space for the new BSC.
8.4.2 Boundary Definition:
Boundaries are finalized in mutual co-ordination with BSS, RF and NSS planning
Teams. BSC loading criteria, MGW/MSC loading criteria and RF KPI (HOs etc) are kept
in mind while dimensioning BSC boundaries. MGW/MSC with which the BSC should
be connected is nominated by NSS planning team during this phase.
8.4.3 Data Compilation:
BSS planning creates a project folder containing all the relevant plans and WOs that
are required for a BSC deployment. These are mentioned below:
SPC Allocation: A unique signaling point code is assigned by NSS planning.

DCN and NMS Connectivity Plan: TXN planning issues a WO on Service Manager
for the integration of BSC with the NMS that is nominated by BSS planning.
Synchronization and Core TXN plan: TXN planning issues a WO on Service
Manager for BSC clock synchronization and BSC STM patching.
SGSN Plan: BSS requests NSS team to provide SGSN/PAPU allocation and NSEI
allocation to PCUs. The information provided to NSS is as under:
o Number of PCUs.
o Timeslots per PCU (CIR)
o Number of E1s.
o BSC ETs

Based on these inputs, NSS team provides SGSN connectivity plans.
GB connectivity WO: TXN planning issues a WO on Service Manager for the GB
connectivity of the BSC, the SGSN allocations provided by NSS team is attached in
the WO.
BSC Integration: BSS planning provides BSC ETs for Aters and requests NSS to
provide DIU allocations. BSS planning then requests TXN planning to issue the BSC
integration WO on Service Manager with NSS and BSS allocations sheet attached in
it. For details please see Ater addition Process.
Power Plan and Site Layout plan: BSS planning requests Site design and power
planning to provide layout and power plans respectively.
Once all of the above data is gathered, it is compiled in to single sheet and floated to
FO (Field Operations) team for implementation. Upon receiving this plan, FO team
moves this BSC to the requested location. Thereafter BSC is installed/ commissioned
and integrated.
8.5 BTS Migration:
Now the BSC is ready to carry commercial Traffic. The next step is to move the
live sites to this BSC so that the BSC can start carrying the live traffic and can be
declared as capitalized. The process of shifting the sites between BSCs is called re-
parenting or BTS migration. The BTS sites migration steps are given in the sections
below:
8.5.1 NCT Preparation:
BSS planning prepares a re-parenting NCT of sites that were planned to be
migrated to the new BSC with the RF teams. The NCT is prepared using the latest BSC
dumps. This NCT contains the site IDs, segment IDs, existing BSC ID, existing
LAC/RAC IDs, existing BSCs SPC, Cell IDs, new BSCs ID, ET/BCF/BTS IDs from the

new BSC, new BSC LAC/RAC, new BSC SPC, TRX IDs and new NSEI allocations.
Sample sheet is attached in the attachments section.
8.5.2 Site priority assignment and RF Data verification:
BSS planning then sends this NCT to RF along with a site list to assign priority to
sites for migration and to verify the new LAC/RAC IDs and Cell IDs. Site priority
assignment is necessary because a maximum of 15 sites can be migrated in a single
night, hence if the site count is greater than this RF needs to distribute the sites over
several nights. They assign priority according to the activity night making site clusters
that would cause minimum handovers.
8.5.3 Re-parenting WO generation:
Once the feedback is received from RF, BSS planning send this NCT and site list
to TXN planning and requests them to issue the site testing/patching WO (re-parenting
WO). This WO is issued on Service Manager.

The WO ID is sent to FO and they are requested to align their resources,
communicate the activity dates and verify the data provided to them. After every
nights activity FO is required to provide a feedback of the activity to all stakeholders.

After completion of the migration activity BSS optimization floats a benchmark
report which consists of major RF and BSS KPIs. Escalations regarding degradations are
also made through this benchmark report.

9 BSC RESOURCE OVERLOAD
After the integration of a BSC in the network, BSS planning and optimization
continuously keeps on monitoring the BSC performance. This is essential for
maintaining the health of a BSC. The most important KPIs for monitoring the BSC
performance are:
BSCs processor load
o Higher than recommended processor loads can affect the performance of a
BSC and end users experience. It can potentially cause an outage on BSC
level which would mean that no service will be available in that BSC area.
BSC MSC Signaling load
o Higher than recommended signaling load can cause the loss of signaling
information. Signaling information is the most important type of information
in any network. Loss of this information means that many important tasks or
user services will not be performed

9.1 BSC Processor Overload
9.1.1 How to check processor loads
In Siemens we check processor loading of the following processor boards.

CBSC ----- MPCC & TDPC
EBSC ----- MCP, APM, APD1 & APD2

While in Nokia we check the processor loading of following processors.
BSC 660/2000 ---- MCMU & BCSU

Using Optima, we can extract the stats for both Siemens & Nokia. The following
query is used for extracting the processor statistics.

Siemens Query,
SELECT
SIEMENS_BSS.SCANBSC_BHDY.DAY,
SIEMENS_BSS.SCANBSC_BHDY.DATETIME,
SIEMENS_BSS.SCANBSC_BHDY.BSC,
SIEMENS_BSS.SCANBSC_BHDY.BSCPRCLD_1, // gives MCP & MPCC load
SIEMENS_BSS.SCANBSC_BHDY.BSCPRCLD_3, // gives APM load
SIEMENS_BSS.SCANBSC_BHDY.BSCPRCLD_5, // gives APD1 load
SIEMENS_BSS.SCANBSC_BHDY.BSCPRCLD_7, // gives APD2 load
FROM
SIEMENS_BSS.SCANBSC_BHDY

Nokia Query,
SELECT
NOKIA_BSS.P_NBSC_LOAD_BHDY.DAY,
NOKIA_BSS.P_NBSC_LOAD_BHDY.DATETIME,
NOKIA_BSS.P_NBSC_LOAD_BHDY.TIME_PROC_PEAK_LOAD,
NOKIA_BSS.P_NBSC_LOAD_BHDY.OBJECT_ID, // it includes all BSC processors
IDs
NOKIA_BSS.P_NBSC_LOAD_BHDY.BSC,
NOKIA_BSS.P_NBSC_LOAD_BHDY.PROC_PEAK_LOAD, // gives BSC processor
load
FROM NOKIA_BSS.P_NBSC_LOAD_BHDY

9.1.2 Example of high processor loads
BSC Processor loads planning threshold for both Nokia & Siemens is 80%.
During the Trial of eMLPP- Priority Subscriber Project, as NSS implemented the eMLPP
setting at MSS level we experienced an upsurge of around 450% in our Nokia BSC

BCSU processor load. Due to timely understanding of the situation we got hold of the
situation and resolved the issue by deactivating the eMLPP settings.

The figure below shows the trend of BSC high processor load during this case.

Figure 7 BSC High Processor Loads due to feature activation

9.1.3 How to reduce the processor loads
In Siemens land, de activating the Compression / De-compression handovers
shows around 10-12% decrease in TDPC load. In Nokia land , disabling the features
which require huge processing like eMLPP would lower down the processor load.

In general, BSC Processor loads can be normalized by reducing Paging load,
reducing traffic by re-distribution, reducing Location updates, improving CSSR.

9.2 BSS Signaling Links Overload
9.2.1 How to check the signaling loads
To check the BSS Signalling links load we have to use SPOTS for R99 connected
BSC(s) and Reporting Suite for R4 connected BSC(s).

In case of R4 we measure the Signalling TRAFFIC_IN & TRAFFIC_OUT of the
CORE Network for all the signalling links of a particular BSC while for R99 we measure
the Signalling RCSLLOAD & TRSLLOAD of the CORE Network for all the signalling
links of a particular BSC.

The Unit of Sinalling load is mERL and threshold is 400 mERL for individual
signalling links. In case of Nokia Land , we have an optimized Signalling overload
alarm 0026 which indicates the breach of signalling threshold.
9.2.2 Current Signaling links Configuration in TP Network:
Currently we have following sets of configurations in Siemens and Nokia land:
8 links x 64 Kbps
16 links x 64 kbps
8 links x 512 kbps
32 links x 64 kbps (Multi Originating Point Codes , MOPC)
2 links x 2 Mbps (Also known as High Speed links ,HSL)
Please note that High Speed links ,HSL can only be created in R99 Core Network
with both Nokia & Siemens BSC(s). Whereas Multi Originating Point Codes , MOPC
can only be configured in Siemens BSS with R4 Core network. Also 512 kbps Signalling
links are only possible in Nokia land BSCs with R4 Core Network.

a. Example : Signalling Link Distribution Issue
In 2009, We observed that in MOPC implemented Siemens BSCs with R4 & R99
network, 32 Signalling links on RCS path (MSC BSC) were not sharing the Signalling
traffic (only 16 signalling links appeared to be operational on MSC-BSC path).

We raised this Signaling Load distribution issues with NSS Planning. Later on it was
confirmed that MOPC can only be implemented in R4 network connected BSC(s).
Therefore Siemens BSC(s) with MOPC links on R99 Core netwrok were upgraded to
HSL links.Whereas MOPC Signaling Load distribution issues with R4 BSC(s) got
resolved after necessary changes at Core end.

Figure 8 BSC to MSC Signaling Connectivity

b. Example : High C7 Signalling load
In 2009 , we decided to increase Paging Success rate in few cities by increasing the
paging re-attempts on LAC level from Core side. We achieved around 10% increase in
PSR through this testing.But with the increase of Paging Attempts, Signalling traffic
increased as well. We certainly didnt want to revert the parametric setting so we
decided to upgrade the signalling links by implementing the MOPC. In this way we
resolved the High signalling load issue with all the High Capacity Siemens BSC(s) on
R4 Network.
9.2.3 Ways to decrease the load
There are certain ways to decrease the signalling related issues at A-interface.

Disabling certain features/Parameter Tuning
By reducing the Paging Attempts / RACH attempts (by restricting the Cell
boundaries by limiting the TA) / HO related features.

Addition of links or Increasing the Signalling Bandwidth
High Signalling load per link can be reduced by increasing the number of links or by
increasing the BW of the links.

Distribution of link loads/New Link Sets
If Signalling requirement of a particular BSC is exceeding 16 Signalling links (64
kbps each), in case of Siemens High Capacity BSC with R4 network , then we can plan
an additional Link set of 16 links (64 kbps each). This configuration is know as MOPC in

which BSC takes two SPCs. We have to make sure the signalling links distribution in 2
n

manner i.e; 2,4,8,16 or 32 links.
9.2.4 Multi Point A- Interface Solution in Nokia Land
The trial of this feature is currently in progress. Telenor Pakistan requires the
integration of a high Capacity BSC with almost 10,000Erl expected traffic to the existing
R4 network nodes with U3C MGW. Integration of a high Capacity BSC with almost
10,000Erl traffic requires to connect it with two U3C MGW with each supporting almost
5,700Erl traffic in present configuration. The site connectivity diagram below explain
the physical and logical connectivity between High Capacity BSC and the MSC Server
class M13.6 through two Multimedia Gateway release U3C.

Figure 9 MOPC Connectivity

The BSC can create 2 complete link sets, one with each MGW. These link sets
will be defined between the BSC and the two MGWs having equally distributed
links in each link set using single point code on each MGW, each link set

containing a maximum of 16x64kbps channels can be created from each MGW,
Given two MGWs under the same MSS.
The route set between the MSS and the BSC can make the MGWs behave as
STPs. This implies that the route set from the MSS can reach the BSC through
two STPs (the MGWs) and both STP points can be at priority 7 with load sharing
enabled. This will imply that the signaling from the MSS to the BSC will be load
shared over the two signaling link sets towards the BSC.
In case where more than two signalling link sets are required, multiple point
codes can be created on either or both of the MGWs, and these point codes can
further be set as STP points towards the MSS in signalling route sets. A
maximum of 4 STP points (alternate signalling routes or load shared routes) can
be associated to a route set.
Signalling route sets will also be created from the MGWs to the BSC locally.

Figure 10 MOPC Logical Diagram
10 ATER ADDITION PROCESS
10.1 Ater Introduction
Ater is the interface between BSC and Transcoder which is required to carry the
traffic from BSC to MSC and vice versa. Congestion at Ater interface can degrade the
KPIs on Um interface therefore it is very important that Ater utilization is kept within
the safety limits. When calculated from BSS end, utilization on the interface between
BSC and MSC is called Ater utilization whereas if computed from Core (NSS) end it is
called Trunk utilization.
10.2 Ater Addition Requirement:
It is desired that utilization of Aters in the network should always stay below 75%.
This ensures that a rejection will never be faced on Ater interface. In order to keep the
Ater(trunk) utilization at an optimum value of 65%, trunk utilization is monitored from

the BSS traffic reports floated on daily and weekly basis. For any BSC where the trunk
utilization is approaching 75%, Ater addition plan is prepared before hand and floated
as soon as the trunk utilization touches the mark of 75%. In this case, number of
additional Aters required is calculated through the following formula:

At the time of writing, the required trunk utilization is kept at 65%. Existing Aters
means the number of Aters currently defined on the BSC.
10.3 Ater Addition Process:
Once required Ater count is determined, planning data is compiled. In Telenor
Pakistans network, the BSS equipment of Nokia as well as Siemens is deployed, so in
the following sections we will explain the Ater addition process for both types of
technologies separately.
10.4 Ater Addition Process in Siemens:
As a first step we prepare two Excel workbooks that contain all the information
from BSS side (Example of both workbooks in the attachment sections). One workbook
(S-WB-A) contains all the information of the existing Aters, connecting BSCs to certain
MSC/MGW, and the other contains the TRAU Racks that are present at the location of
that MSC/MGW where these Aters are terminating.

Remember that in Siemens BSCs deployed in Telenor Pakistans network, the
Ater is connected with the BSC at one side and with the TRAU rack at the other side.
From this TRAU rack, 4 E1s corresponding to this one Ater originate and terminate at
the MSC/MGW. All the TRAU racks connecting Siemens BSCs with the NSS equipment
(i.e. MSC/MGW) are located at the same location as that of the NSS equipment.

In WB-A, we add the information of these additional Aters and keep the
workbook saved with us for our record and float this to all stake holders as well.

Ater addition process is explained with a real example below.

In this example we will show how to add 6 Aters in Karachi BSC09 that is
already working with 23 Aters. From the Daily and weekly BSS reports, we had been
observing that the Ater utilization for this BSC is continuously rising and is over 70%.
As soon as it touched the mark of 75%, we observed that its busy hour (BH) traffic was
reaching 2150 Erlangs. We calculate the value of required number of Aters using
equation given at the start of this topic. We show the calculations below.

According to these calculations, we require to add 5.5 Aters to bring the trunk
utilization to a desired value of 65%. As it is not possible to add Aters in fractional
quantity, so we round the required number of Aters up. Thus we require the addition of
6 Aters.

The Aters are also represented by PCMS in Siemens BSS terminology.
Conventionally when we write Aters, the number of first Ater is 1, and when we
write PCMS, the number of first Ater is 0. As Karachi BSC09 has already got 23
Aters, this means that PCMS0 to PCMS22 are already running and we have to add 6
Aters numbered from PCMS23 to PCMS28.

Lets now explain various entries in the first workbook i.e. S-WB-A. In this
workbook, we are mainly concerned with two sheets. First sheet is named Sheet1 and
second one is named trau. Lets first discuss sheet1 of S-WB-A. In Col B, we write
the TRAU rack number of the rack which has free ports. In Col C we write the exact
port of the respective rack which is free. Now for each TRAU Rack/TRAU port, we
assign PCMS#; STLP Port and CIC number in columns E, G, and I. PCMS# will start
from 23 and end at 28.

The STLP port is actually the port number on the BSC where the Ater (or any
other E1 connected with BSC) will physically connect with the BSC. In Siemens land, we
have two types of BSCs i.e. cBSC and eBSC. In case of cBSCs, STLP port number (which
is currently unused and can be used for patching the new Ater) is obtained from
another workbook (maintained by BSS Planning) titled Siemens_STLP_dd mon yy.xls
sheet. Here dd is the date, mon is the month, and yy is the year when this workbook was
last modified. It is our convention that we make a new copy of the workbook on
monthly basis or whenever a change is made. 4 CICs are provided against each PCMS.
The value of the CICs is calculated by using the below mentioned formula:

In column E, we write the BSC name along with the MSC/MGW name to which
the BSC is connected. This way we complete the sheet1.

The second sheet i.e. trau, is basically the representation of assignment of
TRAU ports to various PCMS in different BSCs. From this sheet, free TRAU ports can be
found out. These are the TRAU ports and TRAU rack numbers that are written in Col B
and E of the sheet1. We will also write the entry of these new PCMS in the selected

free TRAU ports as PCMS# BSC# MSC/MGW#. We will save this sheet and then
attach this workbook in the email for ater addition request.

The 2nd workbook is titled KHI BSC 09. It is obvious that for any other BSC,
the workbook will take the name of that particular BSC. This workbook is basically a
template maintained by BSS planning. Every time Ater addition is required, we
populate the entries of this workbook, name it after the BSC in which Ater addition is
required, and float it. We do not save the populated workbook with us as all the
information contained in it is also present in the workbook S-WB-A.

This second workbook is just a template in which stake holders put their
respective data so that all the information required for Ater addition is aggregated at
one place. As the Ater addition request is initiated by BSS planning, so the template is
maintained and floated by us. Populating this workbook is extremely easy. Just follow
the following simple steps.

1. Copy TRAU racks numbers from Col B of Sheet 1 in S-WB-A to Col AC of KHI
BSC 09 (this is just an example. The name of this BSC will be of that to which the
Aters are being added).
2. Copy TRAU Module numbers from Col C of Sheet 1 in S-WB-A to Col AD of KHI
BSC 09.
3. Copy Port numbers from Col D of Sheet 1 in S-WB-A to Col AE of KHI BSC 09.
4. Copy BSC/MSC/MGW name from Col D of Sheet 1 in S-WB-A to Col AF of KHI
BSC 09.
5. Copy CIC numbers from Col I of Sheet 1 in S-WB-A to Col AG of KHI BSC 09.
6. Copy PCMS# from Col F of Sheet 1 in S-WB-A to Col AH of KHI BSC 09. Once
done, add 1 to each entry in this column AG.
7. Copy STLP from Col G of Sheet 1 in S-WB-A to Col AK of KHI BSC 09.
Now this workbook is also complete. Attach these sheets and send an email to
point of contact (POC) in TXN Planning and DIUAllocations mailing group. Also
keep the POCs of Field Operations and BSS SLM team in CC along with the relevant
Managers and Assistant Managers. The sample text for this email is as below:

TXN POC,
Please issue the WO for 6 X Aters (PCMS23 ~ PCMS28) addition in KHI BSC9 working with
MSC4.Find attached the TRAU Sheet.

NSS POC,
Please allocate the DIUs accordingly.

TXN planning will then issue the WO on Service Manager and float the ID to all
stakeholders. The email text will look something like this:

Dear All,
WO for 6XAters (PCMS23 ~ PCMS28) addition in KHI BSC9 has been issued with PID C-
24843.
10.5 Ater Addition Process in Nokia:
In Nokia there are two different methods of Ater patching (physically connecting the
Ater with the network element).

DAT (Direct Ater Termination).
TCSM Racks.

We will go through the planning steps of these separately.
10.5.1 DAT (Direct Ater Termination)
All R4 MGW(s) with IWS1-A cards installed support DAT feature. With DAT,
TCSM racks are by-passed and Ater(s) are directly patched on the MGW.

For Ater addition on DAT, only BSC ET, the Ater number and the BSC ID is
required from BSS end. This data compilation is specific to BSC3i 660; For BSC3i 2000
another column is added containing the BSC STM number and the subsequent Timeslot
number, since BSC3i 2000 is an STM based BSC with optical ports. Sample sheet is
attached in Nokia Ater Addition Appendix.

BSS sends this sheet to NSS planning for DIU allocations and requests TXN
planning for transmission allocations and WO generation on Service Manager with
complete NSS/BSS/TXN data.
10.5.2 TCSM Racks
In Nokia two separate generations of TCSM Racks are used. These are mentioned
below:

TCSM 2e
TCSM 3i

The details of both the above is given below.
a. TCSM 2e:
TCSM 2e is an old generation rack that supports a maximum of 8 Ater(s). For Ater
addition BSC ET, the Ater number, BSC ID and the TCSM rack number along with its

subsequent port number is required from BSS end. This data compilation is specific to
BSC3i 660, for BSC3i 2000 another column is added containing the BSC STM number
and the subsequent Timeslot number, since BSC3i 2000 is an STM based BSC with
optical ports. This data is compiled in a sheet and sent to NSS/TXN planning teams for
their respective domains port allocations and WO generation. Along with this sheet,
another sheet containing a graphical view of TCSM allocations is also attached for the
convenience of BSS FO. Both the sheets are attached in Nokia Ater Addition Appendix
for reference.

b. TCSM 3i:
TCSM 3i is a new generation rack that can support a maximum of 96 Aters; it is
further divided in to two types:

i. TCSM 3i Stand Alone Rack.
ii. TCSM 3i Combi Rack.

i. TCSM 3i Stand Alone Rack:
TCSM3i rack contains 6 cartridges with each cartridge consisting of 16 ports.
For Ater addition, BSC ET, the Ater number, BSC ID and TCSM port information is
required from BSS end. TCSM port information consists of BSC RJ45 port number (E1
patched from BSC to TCSM) and MSC RJ45 port numbers (E1s patched from TCSM to
MSC/MGW). This data compilation is specific to BSC3i 660, for BSC3i 2000 another
column is added containing the BSC STM number and the subsequent Timeslot
number, since BSC3i 2000 is an STM based BSC with optical ports. This data is compiled
in a sheet and sent to NSS/TXN planning teams for their respective domains port
allocations and WO generation. Along with this sheet, another sheet containing a
graphical view of TCSM allocations is also attached for the convenience of BSS FO. Both
the sheets are attached in Nokia Ater Addition Appendix for reference.

ii. TCSM 3i Combi Rack:
TCSM 3i Combi rack consists of 6 STMs with each STM supporting 16 Aters. Each
STM port provides optical connectivity.

For Ater addition on BSC3i Combi BSC, BSC ET, STM and Tributary number (ET
Timeslot and STM number from 1 to 2), the Ater number, the BSC ID and TCSM ports
are required from BSS end. TCSM ports consist of TCSM Index (1 of the 16 Ater ports),
STM and Tributary number (ET Timeslot and STM number from 1 to 6) and ports for A-
interface towards the MSC/MGW along with their respective Tributary numbers.

A BSC3i 660 or another BSC3i 2000 can also use the Combi TCSM for its Aters. In
that case the ET of BSC3i 660 or BSC3i 2000 is patched on to the ET port of BSC3i Combi
BSC. For this combination the ET number of that BSC3i 660 or BSC3i 2000, STM number

and Timeslot number (in case the BSC is BSC3i 2000), Combi (Host) BSC ET number
STM and Tributary number (ET Timeslot and STM number from 1 to 2), the Ater
number, the BSC ID and TCSM ports are required from BSS end. TCSM ports consist of
TCSM Index (1 of the 16 Ater ports), STM and Tributary number (ET Timeslot and STM
number from 1 to 6) and ports for A-interface towards the MSC/MGW along with their
respective Tributary numbers.

This data is compiled in a sheet and sent to NSS/TXN planning teams for their
respective domains port allocations and WO generation. Along with this sheet, another
sheet containing a graphical view of TCSM allocations is also attached for the
convenience of BSS FO. Sample sheets are attached in Nokia Ater Addition Appendix
for reference.

When composing a WO request mail, the BSC ID, the Ater numbers to be added,
the BSC SPC, the parent MSC/MGW and the number of signaling Links to be created
are included in the message body. A sample text of Ater addition WO request is given
below:
TXN POC,

Please issue the WO for addition of 6xAter(s) [24 ~ 29] in IMD002_BSC4 (Mardan BSC 04)
working with IMD751_MGW-01. SPC of the BSC is 9525. BSS resource allocations are given
in the attached sheet.

NSS POC,

Please provide DIU allocations.

Note: After WO closure the BSC will be working with 29xAter(s) at 16x64k C7 Signaling Links.

TXN planning after receiving DIU allocations from NSS planning floats a mail to
all stakeholders with providing the ID number of the WO issued on Service Manager by
them. A sample text of Ater addition WO is given below:

BSS P&O,

WO issued for addition of 6xAter(s) [24 ~ 29] in IMD002_BSC4 (Mardan BSC 04) with ID
C25035.
10.5.3 Nokia Ater Addition Appendix
FFD005_BSC1
5xAter(s) on DAT.xls

LLR229_BSC1
2xAter(s) on TCSM 2e.xls

TCSM 2e
Allocations.xls

IAB004_BSC1
5xAter(s) on TCSM3i Standalone.xls

TCSM 3i Standalone
Allocations.xls
IAB004_BSC2
14xAter(s) On TCSM3i Combi.xls

IAB751_BSC1(Combi
BSC) 5xAter(s) on TCSM3i Combi.xls

TCSM3i Combi
Allocations.xls

11 ABIS/ TRX DIMENSIONING AND EXPANSION
Before discussing the expansion procedure, we need to know the channel types
and their bandwidth requirements. Only by knowing their bandwidth requirement we
can assign the resources on Abis interface.
11.1 Channel Types
Abis dimensioning results in a specific output that is used as input in the next
dimensioning phase, BSC EDGE dimensioning. In an EDGE transport network, the
following channels must be carried via the available Abis links:

Transceiver (TRX) traffic channels (TCHs).TRX traffic channels carry user traffic
(voice/data calls). Each TRX can contain a different amount of these traffic carriers,
but the maximum number of channels per TRX available for user traffic is eight
(unless half rate is used). The actual number of these channels depends on the TRX
TCH configuration. The number of the channels carrying user traffic can be less than
eight if stand-alone dedicated control channels (SDCCH) or broadcast control
channels (BCCH) are allocated to the TRX.

From the transport point of view, the allocation/usage of the TRX channels
does not change, regardless of whether the channels are used for the dedicated
channels (SDCCH or BCCH) or for TCHs carrying user traffic. From the transport
point of view, there are always eight channels available per TRX. Each of these
channels reserves 16 Kbit/s bandwidth. This is fixed regardless of the carried traffic
type (voice/ data). These channels are so called fixed allocation channels in Abis and
the amount of the channels does not change. One TRX has eight channels; two TRXs
have 16, and so on.

Link access procedure on the D-channels (LAPD). LAPD channels are used for
signaling or managing the traffic between the BSC and BTS. There is one TRXSIG
LAPD channel for each TRX. The capacity of the channel can vary. For example, the
use of half rate affects the required capacity of the TRXSIG LAPD channels. LAPD
channel size varies from 16kbps to 64kbps.

Channels in the EGPRS dynamic Abis pool, used to carry EGPRS data
dynamically. EDAP channels belong to the EGPRS dynamic Abis pool that is used

for EGPRS data traffic. The dynamic Abis pool is used by EDGE traffic (MCS2-
MCS9) or by GPRS with CS2-CS4 (CS-2 only if an EDGE TRX is used). Voice and
high speed circuit switched data (HSCSD) traffic use the statically allocated TRX
traffic channels. Coding schemes above CS-2 require more than 16kpbs on Abis
interface.

All channels mentioned above are transported in the timeslots of the PCM frame.
One 64 Kbit/s timeslot can be divided into four 16 Kbit/s timeslots. These 16 Kbit/s
timeslots are referred to as sub-timeslots. The timeslots in the radio interface are
referred to as radio timeslots.
11.2 Expansion Requirement
Expansion in a particular site is required due to various reasons; some of them are
listed below.

Capacity Enhancement
To counter blocking
To shift traffic to a cleaner band (1800).
For traffic sharing with some neighbor sites.
11.3 Stakeholders
Below are the stakeholders involved in carrying out expansion process from start to
end.

RF.
BSS planning.
TXN Planning.
Field Operations (FO).
11.4 Expansion Process in Nokia BTS
1. Expansion process starts when RF department sends expansion request on the basis
of above reasons mentioned in section 1.1 in the form of any excel sheet which
contains site ID, BSC name, Current site configuration & new configuration for a
particular site and segment name.
2. BSS planning department start working on the excel sheet by adding five more
columns. e.g;
Sr Site Segment BSC Exisiting New ET # BTS BCF Comments Ref

No. ID (On-Air)
Configuration
900 1800
ID ID
Table 1 Expansion Request Sheet
3. Lets now discuss the Ref Column, there are four Ref codes i.e. 1,2,3,4.
a. 1 means (do-able i.e. expansion activity should be carried out)
b. 2 means (Media Issue/Security Issue/Sites on Hold/Freeze)
c. 3 means (WO issued)
d. 4 means (Media WO requested)
In Comments Column, we simply write comments related to sites for
example, expansion given, site is now on 2 E1s etc.
In ET#, BTS ID and BCF ID column, we assign resources using resource sheet.
4. BSS planning department analysis the request on the basis of simple and complex
expansions. Simple expansions are the ones in which there is no media addition
involved but just TRX addition whereas in complex expansions there is a
requirement of media.
5. NSN team shares latest DUMPS on weekly basis which contains complete
information related to sites like TRX, EDGE/GPRS, BSC, BCF, BTS etc. These dumps
are very useful for BSS planning department to extract right and complete
information for a particular site. These dumps are usually sent by NSN in the form
of xml format and BSS planning uses database parser to convert them in excel sheet
and then by using filters extracts the required information.
6. BSS planning department has some data provided by the vendor in the form of an
excel sheet pasted below which is used to assign BTS IDs, BCF IDs and ET numbers
etc.
BSC_Detail_City_Wis
e_18Dec08 North.xls

7. BSS planning department allocates resources using the resource sheet and dumps
and do the expansions.
8. Below is the template used for expansions which are very simple and self-
explanatory. There are two tabs in it, 900 and 1800. Expansion request comes in
below mentioned format from RF end:
900_1800 (existing) 900_1800 (New)
222_222 222_232

As mentioned in the table above, there is a TRX addition/expansion in 1800
second sector, so the template below will be used while applying the dimensioning rule
that we define 2 TRXs in 900 in each sector and 4 TRXs in 1800 in each sector.

Just for the information 1 TRX takes two 64kpbs time slots which are then
divided into 8 sub time slots. One E1 has 32 time slots, and distribution of these time
slots is as under:

Total Time slots (TS) = 32
Signaling = 1 TS
Synchronization = 1 TS
EDGE/GPRS = 9 TS (minimum)

On the basis of above distribution, we know that this sites configuration cant be
accommodated in 1-E1 therefore 2-E1s would be required. Therefore 20 TRX (max) can
be accommodated at a time which means useable TS are 40 in 2 E1s. Out of these 20
TRX maximum 9 TRXs can be accommodated on E1 present in 900 along with 6 EDGE
TS and rest of the 11 TRX can be accommodated on E1 present in 1800 along with 3
GPRS time slots.
Abis TRX Sample
Template.xls

9. Once the simple expansion plans ready, these are sent back to RF and the RF
generates WO to FO team to get these plans implemented. Whereas the complex
expansions i.e. where there is media addition required which are Ref 4 cases, BSS
planning initiates WO request to TXN team.
11.5 Expansion Process in Siemens
1. This process is just like Nokia process, but we dont really need to make ABIS plans
in Siemens BTS expansions.
2. RF sends expansion request to BSS planning team. BSS Planning team parses the
dumps using parser pasted below and adds columns like comments, E1, TRX Count,
Mel ID, BTSM ID, and LAPD distribution etc in RF expansion request sheet.
DB Creator.xls

3. Dimensioning rules are different in Siemens as compared to Nokia. Rules are listed
below:
a. 1-12 TRX on one E1.

b. 1-12 TRX on one LAPD. TRX should be equally distributed on LAPD to avoid
downtime/congestion.
c. LAPD distribution is different for VSAT sites i.e. 1-6 TRX/ LAPD.
4. Current site configuration which includes TRX counts, E1, BTSM, MEL ID etc is
extracted from dumps.
5. Then, BSS planning allocates resources using dumps and assign STLP/VC where
media addition is required and sends the data back to RF. STLP seet template is
pasted below:
Siemens_STLP_12
Apr 05.xls

Please find below the expansion process work flow in the flow diagram below.

Abis plans/ TRX Expansions Process
BSS FO
BSS FO
TXN Planning
TXN Planning
BSS planning
BSS planning
RF Planning
RF Planning
Analyze request from
RF
Media Required
End
Media WO request
sent to TXN team
Abis Plans received
Get Latest
configuration of sites
from NMS Dumps/
NetAct
Perform Expansions
Start
Media WO Issued
WO Request for
Expansions
Complex Expansion?
Yes
Yes
WO execution, closure
and intimation
Request for
expansions along with
new site configuration
Prepare ABIS Plans/ BSC
resource allocation (BCF/
BTS ID/ ET #)
No
No

Figure 11 Expansion Process

12 Licensing
12.1 Introduction
In this era of technological advancements, every technology product has a license
and copy rights associated with it. This is done in order to make sure that the products
are used only in a way the vendor wants them to be used. Each product has certain
features and licensing every feature means that vendors sell each feature of a product
separately.
12.2 Licensing BSS Products
As discussed above, in order to utilize various features of a product, licenses are
required to be installed on that equipment/product. There are many types of licenses
that are used to operate the hardware installed in Telenor Pakistans Network; however
we will discuss only those that BSS Planning has to deal with directly.

12.2.1 Nokia BSS Licenses
We are only concerned with the hardware TRX licenses, EDGE TRX licenses, and
Soft Channel Capacity Licenses in Nokia BSS. One hardware TRX license is required per
TRX. These are purchased along with the purchase of hardware of TRXs.

1 EDGE TRX License is needed per sector. For example, if a site is operating in
222/202 configuration, it has 3 sectors, so three EDGE TRX licenses are required for this
site. In order to determine the total number of EDGE TRX licenses required on a BSC,
we consider the rollout forecast and expansion forecast communicated by RF Planning
team. We identify how many additional sectors are being added for that particular year.
The number of additional EDGE TRX licenses required are the same as total number of
sectors being added. We calculate them, add some cushion and order these many EDGE
TRX Licenses and request to install them on the BSC. We try that this activity should
not be done more than once in a year.

The 3
rd
type of licenses that we deal with is the Soft channel capacity licenses.
Total number of soft channel licenses defines how many total traffic channels will work
on a particular BSC. Whenever soft channel capacity is exceeded, we request additional
soft channel capacity licenses until the limit of BSC is reached.

One other type of hardware that we use in Nokia BSCs is PCU. PCUs deal with
the packet switched traffic of the Nokia based network. A license is required to operate
the PCUs with all their basic features. So we install as many licenses in the BSCs as the
total number of logical PCUs in that BSC.

12.2.2 Siemens
In Siemens, we deal with TRX licenses and PPXU/UPM licenses. TRX licenses
are same as the hardware TRX licenses in Nokia. We have to install a license for each of
the TRX that is working in the network.

PPXU/UPM cards also require licenses to operate in the BSC. PPXU card are
installed in cBSCs and UPM cards are installed in eBSCs. Their functionality is same as
of the PCUs in Nokia BSCs, i.e. handling the packet switched data. We install the
hardware PPXU Cards/UPM Cards and then install their licenses to make them
functional.

It is important to note here that it is also possible to uninstall a license from a
BSC and install it on another BSC of the same type to enable the similar functionality as
that of the earlier one. In order to install any of these licenses, we contact NSN SSM
team and ask them to provide additional required licenses. Once they provide, we
request NSN SLM team to install them to make the hardware equipment and its
features functional.

13 LAPD PLANNING
13.1 Introduction
LAPD, link access protocol on the D-channel, is required for carrying the
management commands between BSC and BTS. There is one TRX LAPD signaling
channel for each TRX. The capacity of the channel can vary. For example, the use of half
rate affects the required capacity of the TRX signaling LAPD channels. A LAPD channel
can be defined as a 16/32 or a 64kpbs signaling channel. The link size (capacity) of
LAPD channel should be enough to keep the paging load in the required physical limits
or in other words the paging load of any location area should not exceed the capacity of
a LAPD channel of a BTS. Along with the paging load, a LAC should be able to provide
enough capacity to carry the O&M and signaling traffic for a BTS site.

In the following sections we will be discussing the LAPD capacity dimensioning
aspects for both Nokia and Siemens BSS.
13.2 Abis LAPD Dimensioning Aspects
The planning of LAPDs on Abis interface has already been discussed in the section
of ABIS/ TRX DIMENSIONING AND EXPANSION. The criteria of LAPD planning shall
remain the same but in cases where we face congestion on LAPD interface, the
following factors should be taken into account when estimating the capacity of the Abis
LAPD signaling and especially when having the 16 kbit/s (low capacity) link signaling
link:

There can be a maximum of 2 signaling messages unacknowledged at any time, all
the subsequent messages must wait for the acknowledgement of at least one of these
messages; all the messages are stored in signaling processor buffer until responded
to by the opposite end. The LAPD window size 2 is recommended by the GSM
standard 08.56.
The acknowledgement delay varies from a few milliseconds to tens of milliseconds
because of the characteristics of the LAPD protocol, especially if there is a lot of
signaling traffic coming in from the opposite direction (measurement reports and so
on). All this lowers the maximum capacity much below 16 kbit/s.
Disturbances on the physical 2 Mbit/s line may cause more delays, which lowers the
capacity.
Based on these previous factors and measurements made on the Abis link, the
maximum average signaling traffic load should not exceed 8 kbit/s (1000 bytes/sec).
One of the most common messages sent on the highest loaded Abis link (that is, the
BCCH TRX link) is the paging message. The length of the paging message (including
FCS and flags) is about 21 bytes. According to the BSC nominal load and call mix,
about 60% of all capacity can be given to the paging messages; the average paging
message count/sec/link is thus 0.6 x 1000/21 = 29, which roughly equals 100 000
pages per hour (16 kbit/s), which is sufficient, for example, for the nominal BSC call
model. For a 64 kbit/s link, the same general principles apply. The maximum
recommended average signaling traffic is 4000 bytes/sec and the paging message
count as calculated above is maximum 60/sec/link, which equals to 410 000 pages
per hour (64 kbit/s).
The number of paging messages is different depending on the call mix and
configuration. If the reference call mix is not suitable, the limits to be considered are
the earlier mentioned 1000 bytes/s (16 kbit/s LAPD) and 4000 bytes/s (64kbit/s
LAPD) per Abis link.
13.3 LAPD Dimensioning in Siemens BSCs
In Siemens BSS, we will be discussing the LAPD dimensioning limits for both
types of BSCs in separate section.
13.3.1 cBSS LAPD Capacity:
In cBSC, the card for handling the signaling traffic (CSS7 and LAPD) is called
PPXL. The total bandwidth towards the "PPXL" is 1 x 8 Mbit/s; in other words, 128 time
slots at 64 Kbit/sec are available for signaling purposes; for each "PPXL" up to 16 time
slots at 64 Kbit/sec are reserved for the CCSS#7 and 240 time slots (for example 67 at 64
Kbit/sec and 173 at 16 Kbit/sec: 67X64kpbs+173X16kpbs=240 TS at 64Kbps) for LAPD
for handling the signaling towards the BTSs and the TRAUs.

The LAPD capacity of the PPXL board (240 channels) is defined by the
bandwidth of the board itself which is equivalent to 8Mbit/s. This capacity is reached

by using mixture of 16 and 64 Kbit/s channels. If just the 64 Kbit/s case is considered,
the amount of served channels is much lower. One 64 Kbit/s channel is used for error
protection, and up to 16 SS7 links at 64 Kbit/s can be configured. In terms of 64 Kbit/s
channels (LAPD + SS7), the PPXL offers a total capacity of 127 channels. As a
consequence in the worst case up to 63 LAPD channels at 64 Kbit/s can be available for
the interconnection of BTSE(s) to the BSC1. This condition could impose limitations to
the geometric configuration of the Abis Interface; for example, the configuration of
additional LAPD channels for measurement purposes can only be reached reducing the
capacity of the site in terms of supported traffic.

These limitations have been overcome reducing the capacity of the LAPD
channels configured for the control of the connected TRAUs, from the current 64 kbit/s
to 16 kbit/s by implementing a new parameter associated to the LAPDLS Managed
Object.
13.3.2 eBSS LAPD Capacity:
In eBSC, there is a provision for two types of E1 connectivity, electrical (like
cBSC) and optical.

The LIET blade is a Line Module providing 32 physical interfaces (electrical)
E1/T1 to/from Abis/Asub/Gb. Moreover LIET module manages up to 256 LAPD links.
The LIET blade supports the N+1 redundancy concept with N = 9 ; a spare LIET is
available. When a fault occurs to a LIET, the spare takes over the relative lines, serving
the traffic without service interruption until the problem is solved and a switch-back is
consequently performed.

In case of optical connectivity, blade module STM-1/OC3 provides 2 optical links
to/from Abis/Asub/Gb interfaces, which can be configured in:

Channelized mode (63 E1 equivalent lines);
Unchannelized mode (broadband);
Mixed mode.
The overall connectivity per module is 126 (2x63) E1 equivalent lines (channelized
mode) or 2 x 155 MB/s (unchannelized mode).Moreover LM-STM1/OC3 module
manages up to 1024 LAPD links.

The figure below contains the summary of LAPD, SS7 etc capacities for different
types of Siemens BSCs.

Figure 12 Siemens BSCs LAPD Capacities
13.4 LAPD Dimensioning in Nokia BSCs
TRXSIG and BCFSIG (OMUSIG) are LAPD links managed by BCSU AS7
Every ET plug in unit need a LAPD channel for O&M (software download, alarms,
configuration) managed by BCSU AS7
Layer 3 signalling is handled directly by BCSU CPU
Every TCSM needs a LAPD for O&M managed by OMU AS7

BSC Configurations BSCi BSC2i BSC3i 660
BSC3i
1000
BSC3i
2000
Maximum number of LapD links per
BCSU
117 124
170 (AS7-
B)
448 448
(BCFSIG + TRXSIG + ISDN+ET-LAPD)
206 (AS7-
C)
Maximum number of TCHs per BCSU 512 512 880 1600 1600
Table 2 Nokia BSCs LAPD Capacities
14 LAC PLANNING
LAC stands for Location Area Code. Before going into the details of Location Area
Code and its planning let us first see what Location Area is.
14.1 Location Area:
A location area is defined to facilitate MSC/MSS in locating a user. MSC nodes have
two types of communication with MS:

BSS Signaling
This type of communication is used for exchanging all type of signaling
information including call routing, traffic channel allocation etc.
Locating MS (end user)
This type of communication is used to find out the location of the user. Only after
locating the user it is possible for MSC to provide the connection for establishing a
call. This is done by defining the location area within the vicinity of a MSC
boundary. By defining a location area, MSC only searches the user in MSs location
areas rather than trying to find a user in a complete MSC area.

A location area comprises at least one but typically several BTSs. A location area has
the following features:

Location area information of a MS is sent not only periodically in uplink to the
network but also whenever the MS changes the location area.
A mobile station that changes the serving cell in the same location area does not
need to perform a location update.
When the network tries to establish a connection to a mobile station; for a mobile
terminating call, it is necessary to send only the PAGING message to those BTSs that
belong to the current location area of the MS.
Defining a location area, therefore, serves mainly one purpose, reduction in the
signaling load. Every BTS broadcasts the location via the parameter Location Area
Identity. Even when the MS is involved in the active call, the location area still is
communicated to the MS (this is particularly important in the Handover).
14.2 Location Area Code:
Each location area has a unique identifier that is called Location Area Code. Now
we will describe how the planning of LAC is done.

Whenever a LAC is made, it is ensured that the parameter PPS (paging per
second) does not breach the set threshold (explained below). This is basically the
number of pages a BTS transmits in a second. A paging message is sent whenever
someone tries to make a call. The paging message is generated in the location area of the
call termination point. Greater the number of users in a location area, higher will be the
PPS in that location area. While planning, we have to ensure that the PPS in LAC does
not breach a threshold. Below we give the threshold values for PPS in Siemens as well
as Nokia BSCs.
14.2.1 LAC thresholds:
In Siemens eBSC and cBSC, the threshold of PPS is 100. This is at 100% capacity;
however, we operate at maximum on 80% and plan on 65%. If the PPS of any LAC

tends to rise above 80% threshold, we perform the LAC split activity (LAC split activity
will explained late).

In case of Nokia BSCs, the threshold for PPS is 55.5. Again, this is the PPS at 100%
capacity. We perform the LAC split activity if the PPS rises above 80%.
14.3 New LAC planning:
Whenever a new BSC comes in a region, it is given a new LAC. In order to
determine the expected PPS in this LAC of new BSC, we use the following formula.

Where BSC N is the new BSC that will take some sites from the existing BSCs
A, B, and C.

As stated earlier, the LAC is planned at 65% threshold of PPS, so if the expected
PPS is within the 65% limit of the maximum PPS of the BSC, then this BSC will have
only 1 LAC. If, however, the PPS is greater than the 65%, we need to define more than 1
LAC. We need to define as many LACs as required until the PPS is around 65% in each
of the LACs defined in this BSC.
The creation of new LAC will reduce the PPS in existing LACs. The most
important thing to consider while defining a new LAC is that the Location Updates
(LU) should be very small between the LACs. The Location Update message is sent by
the BSC whenever a Mobile Station moves from one LAC to the other. Larger LUs will
cause more loading on the BSC processor and we do not want that. At the same time, a
high number of LUs will put more loads on SDCCH resources in a BTS as well. So the
boundaries between the LACs are made in such a way that there is very minimal
possibility that a user will move from one LAC to another. This is ensured by giving the
LACs the same boundaries as those of the BSCs that are being offloaded by this new
BSC because the BSC boundaries are already made in such a way that there is minimal
possibility that a significant number of users will cross the BSC boundary.

By now, during the LAC planning, we have seen whether more than one LAC is
required in the new BSC or not. If required, we make as many LACs as possible so that
the PPS of all the LACs is no more than 65% of maximum PPS for that BSC. (80%
threshold is the cut-off point where we split the LAC and make a new one). Once all
this working is done, the proposed LAC boundaries are sent to corresponding RF team
for their consent. The RF team will analyze the boundaries and will try to fine tune it in
a way that will reduce the LUs between LAC boundaries even more. RF team will send
the proposed changes back to BSS Planning for our consent. BSS planning will again see
if the PPS in the new proposed boundaries will be around 65% of the threshold using

the equation given above. This activity will continue between RF and BSS Planning
until both teams agree on common boundaries. Once done, these LACs will be defined
in the new BSC.

In addition to above, there are two other perspectives to be considered while
dimensioning a LAC:

Paging which can be handled by BSC per LAC depends upon the size of LAPD.
Total paging which can be handled by BSC depends upon call mix and hardware
configurations. For example, both type of Siemens BSCs (cBSC and eBSC) can handle
1 paging message each 10ms per LAC which gives a value of 360000 page/hour per
LAC.
The second aspect is the pages which can be handled by LAC, Number of pages
which can be handled by LAC depend upon the LAPD size, bigger the LAPD more
pages it can handle, and with 32K signaling used in the Nokia BSS in Telenor
network, approximately 200,000 pages can be handled.
14.4 LAC Load Balancing Activity:
Assume that a BSC is working in the network that has a specific number of LACs
defined in it (number of LACs can be one or more than one). BSS team will constantly
keep on monitoring all the LACs of all the BSCs on weekly basis. For those LACs,
whose PPS is about to reach the threshold of 80%, either LAC balancing or LAC split
plan has to be prepared and made ready and implemented before the PPS breaches the
80% threshold.

Assume that a BSC currently has three LACs. PPS of one LAC is rising and has
reached to 75%. PPS of the other two LACs, however, are only at 55%. In this case we
will shift some sites of the first LAC to the other two LACs. This will help in reducing
the PPS of first LAC, by increasing the PPS of other two LACs. Suppose the PPS of first
LAC comes down to 65%, this would mean that the PPS of the other 2 LACs might go
upto 60% each as we have moved sites from first LAC to these two LACs.

In another case, where the boundary of the first LAC does not touch the boundary
of the other 2 LACs, the sites can be shifted to only one LAC whose boundary touches
the first LAC. This way the PPS of the first LAC can be reduced down to somewhere
around 68% and the adjoining LACs PPS may rise upto 62% which are both acceptable.

Another way to do this is to shift some sites of the LAC adjoining the first LAC to
the 3
rd
LAC. This will increase the PPS of 3
rd
LAC above 55% and reduce the PPS of
LAC 2 below 55%. Now there is more room in this adjoining LAC to take more sites
from first LAC. The drawback in this case, however, is that two boundary adjustments
will be required: one between first and second LAC and one between second and third
LAC, and it will take more time to agree upon the boundaries which are acceptable to

both RF Team and BSS Planning Team. One should avoid such multiple boundary
readjustments and should be done only if the PPS of a LAC is rising very sharply and is
expected to go way over the 80% threshold.

Once we have prepared LAC balancing plan from BSS side, we coordinate with RF
team and decide boundaries that are acceptable both to RF and BSS planning.
14.5 LAC Split Activity:
We have seen how LAC balancing is done. Now let us see the cases where we
need LAC split activity. LAC split is required only if PPS of a LAC is about to cross
threshold and there is only one LAC available in the BSC. In this case there is no 2
nd

LAC available to balance the problematic LAC with.

Another case where LAC split is required is when the PPS of a LAC is about to
breach the threshold but the PPS of the neighboring LACs is also high enough that
shifting more sites to them will raise their PPS to the extent that 80% threshold will be
breached / almost breached.

In such scenarios, we will divide the problematic LAC into two. We always try to
ensure that the newly created LACs out of the one problematic LAC are as balanced as
possible. Ideally, for example, if the problematic LACs PPS is 78% of the total limit (i.e.
at 100%), we will try to ensure that each of the two new LACs have 39% PPS of the total
limit. We try to stay as close to the ideal as possible but some variation is acceptable.

The main issue here is again the boundary from where the LAC should be split.
The best way is to review the history of the region and see if there was a BSC present
here in the past that cuts through the area covered by the problematic LAC. That
boundary of the old BSC can be used as a guide to make the boundary. One can also
look if there was a LAC earlier at this location of problematic LAC. If there was one, the
boundary of that old LAC can also be used as a reference to cut the problematic LAC
into two. If no such boundary existed in the past that cut through the problematic LAC,
we plot the current LAC on MapInfo along with all the roads in that region and try to
make a new boundary that does not cut any major road and cuts the least number of
small roads. We also try to keep the total number of sites equal in both the new LACs.

Once we decide a tentative boundary, it is sent to RF team for their consent. They
will analyze the boundary in terms of the expected Location Updates. If the expected
LUs are high for their liking, they will propose changes in the boundary proposed by us
and send it back for our review. BSS Planning will see whether they have shuffled
enough sites that will render the new two LACs unbalanced. If it appears that the new
LACs will be nearly balanced we accept the changes proposed by RF team and request
Field Operations to proceed with the LAC split activity. If the changes proposed by RF
team are not acceptable, we propose our new changes and send them to RF team. This

activity is repeated until a mutual consent is reached between RF team and BSS
Planning team, after which Field Operations is requested to split the LAC.

15 LAC OPTIMIZATION
15.1 Introduction
LAC location area code performance is measured by its Paging Statistics. The
following are the major indicators that give the indication of the performance of a LAC.

Paging load
Paging Success rate
Paging deletions due to Overload of CCCH)
Location updates (SD Usage %)

We use Optima (Aircom performance monitoring tool), Spots (Siemens Stats
monitoring tool ) & Reporting suite (Nokia Stats monitoring tool) for the extraction of
paging & location updates stats for both Siemens & Nokia region LAC(s).
15.2 Paging Capacity for BSC and LAC
The paging of mobile stations is a network-initiated procedure which is designed
to locate, within a location area, a mobile station to which a terminated call is to be
directed. The BSC, when instructed by the MSC, broadcasts a paging message to all cells
(BTSs) whose location area corresponds to the one indicated by the MSC.

In Siemens, the maximum capacity is 360.000 paging/hours/LAC (100
paging/sec), and we can create up to 20 LACs in both CBSC & EBSCs.
In Nokia, the maximum capacity is 200.000 paging/hours/LAC (55.5 paging/sec),
and we can create upto 4 LACs in both BSC 3i-2000 & upto 2 LACs in BSC 3i-660.

15.3 Paging Parameters & Statistical Counters
In Siemens, following counters are measured for paging analysis,
NTDMPCH_1: Transmission of a PAGING REQUEST message on the PCH for CS
traffic
NTDMPCH_2: Transmission of a PAGING REQUEST message on the PCH for PS
traffic
NTDMPCH_3: Discarding of a received PAGING COMMAND (BSC --> BTS) for CS
traffic due to lack of BTS PCH paging queue places
NTDMPCH_4: Discarding of a received PAGING COMMAND (BSC --> BTS) for PS
traffic

The following formulas are used to determine the paging attempts and discards in a
LAC.

Total Paging Attempts per hour = NTDMPCH_1 + NTDMPCH_2
Total Paging Discards per hour = NTDMPCH_3 + NTDMPCH_4

In Nokia, following counters are measured for paging analysis,
C003000 - PAGING_MSG_SENT: Number of paging commands sent to the BTS.
C003038 - DELETE PAGING COMMAND: Number of delete paging commands.
This counter indicates if some group specific paging queue becomes full so that an
additional paging command cannot be stored to the buffer. In that case the paging
command is deleted.
15.4 P KPI
Paging per Second = Max PAGING_MSG_SENT/3600
Paging deletions per Second = Max DELETE PAGING COMMAND/ 3600

15.5 Paging Technical Background
The greater part of the signaling load on the common control channels originates
from Paging. The amount of paging in a LA is dependent on how many cells that
belong to the same LA and the traffic that is served by these cells.

The number of pages that can be handled by each cell is dependent of the
configuration of the common control channels and size of the paging messages.
15.6 Paging Groups
To prevent that the mobiles having to monitor both the PCH and PPCH
continuously, the mobiles are divided into paging groups. The mobile will only monitor
the paging channel when the paging group to which it belongs to is transmitted.

After a mobile has tuned to the BCCH carrier and decoded the System
Information, it performs an evaluation to which paging group it belongs, and hence,
which particular paging block on the paging channel that is to be monitored. The
operator can set the number of paging groups on the PCH for each cell.

A high number of paging groups means that the mobiles will have to wait for a
longer time before the right paging block arrives. This increases the time for paging.
It also reduces the paging capacity compared to using fewer paging groups. This is
because with a high number of paging groups, each paging group will have a short
paging queue in the BTS.

A low number of paging groups shortens the call setup time, as the mobile listens
to the paging block more frequently. The drawback is that the mobile power
consumption is higher.
The relation between MFRMS, AGBLK and the number of paging groups is:
Combined BCCH/SDCCH cells: Number of paging groups = (3 - AGBLK) *
MFRMS
Non combined BCCH/SDCCH cells: Number of paging groups = (9 - AGBLK) *
MFRMS
The table below shows this relation together with the duration time between
transmissions of each paging group.

Figure 13 Paging Groups and Frame Intervals
15.7 Queuing in the BTS
Incoming Paging Commands are buffered in a queue (one for each paging
group). The BTS distributes the Paging Commands as Paging Request messages on the
radio path when paging blocks are available. A too high rate of incoming Paging
Commands to the BTS increases the queuing time that leads to an increase of the
average time for the paging response. When the queue is full, the incoming pages are
rejected. Before sending a page the time spent in the queue is calculated. If the time
difference between insertion and de-queuing exceeds default value then the page will
be discarded and not sent. If a page is queued for a too long time in the BTS, the page
may also be lost due to the fact that the MSC does not receive the paging response
before the timer PAGTIMER has expired. The risk of excessive delay in the BTS
increases if the time between the transmission of each paging group, set by the
parameter MFRMS, is long. Furthermore, if MFRMS is set to a high value will increase

the risk that the page will be discarded in the BTS at high paging or Immediate
Assignment intensity.
15.8 Paging strategies
The number of CCCHs depends on the channel structure as follows:

COMBINED: for a small cell, 2 TRXs/cell, 3 CCCHs in every signaling Multiframe
(51 TDMA, 235 ms)
NONCOMBINED: for a large cell, 3 TRXs/cell, 9 CCCHs in every signaling
Multiframe (51 TDMA, 235 ms), used if GPRS is enabled in the cell.

The parameters that affect the CCCH capacity on a cell basis are the following:

Number of blocks reserved to AGCH (BS_AG_BLKS_RES); once this parameter is
specified, the PCH is calculated; the parameter range is 0 to 7 and value zero is not
recommended.
Number of Multiframe (BS_PA_MFRMS); this specifies how many multiframes will
go until the given paging group is re-paged; the parameter range is 2 to 9 and the
recommended value is 4.

The paging method is also set in MSC TMSI or IMSI . TMSI is more commonly used,
because of bigger capacity (4/page group). Here we assume that all the radio interface
capacity available is used, thus all extra paging will be ignored.

If we keep the parameter Number of Multiframe value 4, it means that the
same paging group will be re-paged after 4 x 235 ms = 0.940 sec. This will ensure longer
MS battery lifetime, because the MS has to listen quite seldom to a CCCH channel in a
serving cell. In this case you must also ensure from the estimated call mix or from live
network statistics and measurement values that you operate in the nominal BSC load
area and that the Abis paging load does not exceed the limits of LAPD (16 kbit/s or 64
kbit/s) link capacity nor the radio interface paging capacity.

The recommendation concerning MSC paging parameters is to use the 'LA'
paging method, which prevents the unnecessary cell level CI information from being
sent to all cells in the BSS A/Abis interfaces. Paging must, in any case, be performed on
an LA level in the GSM system.

In the MSC there are also parameters related to CCCH (actually PCH) capacity,
which are on a LA basis. To ensure that the paging message reaches the MS, the paging
message is sent several times. The repetition procedure is defined in the MSC. These
MSC parameters are Re-paging_Interval (time between paging attempts) and
Number_of_Repaging_Attempts, which can be modified in the (Nokia) MSC.

The recommended values are: Number_of_Repaging_Attempts = 0,
Repaging_Interval = 3.5s. This works better if TMSI is in use. This means that the first
paging goes with TMSI, and then after 3.5 seconds with IMSI, if the subscriber does not
respond to TMSI.

The conclusion is that paging load is highly dependent on parameters. In the
same LA, the paging load should be monitored. Note that if there is only one small cell
in a given LA, where combined channel structure is in use, this will be the bottleneck if
paging blocking criteria are strictly followed. In other words, the smallest cell in the
LA will set the PCH limit.

Note also that some maximum configurations would not be possible because of
other limiting factors such as the 16 kbit/s Abis or radio interface, which would start to
limit the message traffic, thus it would be useless to define such parameter settings (for
example too large location area size).

If there are only one or two cells with combined channel structure in an LA, you
can choose to live with a high paging blocking rate in this cell because the Probability of
MS location in this cell is very low. Therefore, the Paging blocking rate as seen from the
MSC is not modified much by too few PCHs in this cell.

Figure 14 LA with 2 cells Combined and 8 cells Non-combined
The final Blocking rate is 30 x 4/100 + (1 x 96/100) = 2.16%. Moreover, if the MSC
repeats the Paging messages, the end user blocking rate can be considerably reduced if
the PCH is not overloaded too much: 10% x 10% = 1%.

15.9 Paging Overload Condition

Figure 15 Paging Overload in Siemens BSS - BTS discards a PAGING REQUEST Message
Each paging queue place in the BTS can be seized by one PAGING REQUEST
message (PAGREQ) which itself can contain the mobile identities (IMSI or TMSI) of up
to 3 mobile subscribers simultaneously. This means that the PAGING REQUEST
message can contain the mobile identities of up to 3 PAGING COMMANDS (PGCMD)
that were received from the BSC before.

If the BTS discards a PAGING REQUEST due to lack of paging queue places,
NTDMPCH (3.) is increased by as many counts as mobile identities (IMSI or TMSIs)
were contained in the discarded PAGING REQUEST message. In other words, if the
discarded PAGING REQUEST contains e.g. 3 TMSIs, then NTDMPCH (3.) is increased
by 3.

The BSC starts T17 and discards all new PAGING COMMANDS to the BTS only if
BTS overload handling is enabled in the BSC (BTSOVLH=TRUE). The PAGING
COMMANDS to the BTS are discarded as long as T17 runs.
15.10 LAC Splits
The BSC will discard paging messages from the MSC when the paging queue is
full and the BSC has a counter, DELETE PAGING COMMAND, which steps for every
discarded page. The number of paging messages received from the MSC is counted by

PAGING_MSG_SENT. If the paging queue is congested, consider splitting the LA into two
or more LAs. This will lower the paging load in the BSC.

The rate of discarded pages in a cell shall ideally be 0%. However to be able to
reach this rate there might be a need to increase CCCH capacity or to decrease LA size.
These changes might lead to decreased number of available TCHs or to increased CP
load in the BSC due to more LA updates.

To avoid unnecessary reconfigurations it is suggested to use 0.1% as an acceptable
rate of discarded pages. Since discarded first pages will be retransmitted the probability
that both first and second page will be discarded will be much less than 0.1%.

Note that it can be acceptable to have more than 0.1% discarded pages in cells
with few Establishment cause Answer to paging in Channel Request message. One
example of this situation is if idle mobiles in a dual band network are mainly camping
on one frequency band due to idle mode behavior parameters.

The paging load determines the maximum size of a LA while the Location Update
load in the LA border cells sets the minimum size. The most important rule is not to
exceed the maximum paging capacity of the BTS or the BSC. In rural areas it is often,
because of the lower traffic load, easy to find suitable LA border cells, however there is
no reason to have smaller LAs than necessary. One LA per BSC area is often a good rule
of thumb. If an LA is relatively large, and the paging load is high, one should consider
splitting the LA into two or more LAs. This will reduce the paging load in the BTSs as
well as in the BSC. It should be noted that to change the LA size, the affected cells need
to change its cell global identity, which requires that the cell is halted.

In larger cities, the increased SDCCH load in LA border cells may be more critical.
This can make it more difficult to find suitable LA borders. If the BSC areas are
relatively small, and it is difficult to find suitable LA borders, one LA can cover several
BSC areas.

Regardless of the type of area, rural or urban, it is recommended to have the LA
border cells in low subscriber density area. LA borders crossing over high mobility
areas, e.g. high ways, should be avoided. The most important recommendation is to
carefully monitor the performance of the system.
16 GPRS PLANNING
GPRS gives customers the benefits of instant IP connectivity on-the-move and of
being continuously connected. GPRS provides the possibility of being charged only for
transferred data in addition to more efficient use of limited air interface resources.

GPRS provides packet radio access for a GSM/GPRS mobile. The benefit of GPRS is
that it can use the same resources that circuit-switched connections do by sharing the
overhead capacity. This means that one mobile uses the resources only for a short
period of time, that is, when there is data to be sent or received. The sharing of
resources together with a very fast method of reserving radio channels makes the air
interface usage even more efficient. GPRS coding schemes CS1-CS4 are supported in
conventional 2G networks.

Enhanced Data rates for GSM Evolution (EDGE), introduced to GSM/GPRS
standard Release 99, boosts GSM/GPRS network capacity and data rates to meet the
demands of wireless multimedia applications and mass market deployment.

EDGE uses 200 kHz radio channels, which are the same as the current GSM channel
widths. From a technical perspective, EDGE BSS allows the GSM and GPRS core
network to offer a set of new radio access bearers. EDGE is designed to improve
spectral efficiency through efficient link utilization with GMSK and 8-PSK modulation
schemes, which can be alternated on the same radio slot according to radio channel
conditions. With new modulation, EDGE increases the radio interface data throughput
threefold on an average compared to GPRS.

EDGE Modulation and Coding Schemes MCS1MCS9 provide optimal
performance in all radio conditions. In good radio conditions MCS9 provides up to 59.2
Kbit/s throughputs. In four timeslot multislot allocation 236.8 Kbit/s throughput can be
achieved.
16.1 GPRS/EGPRS Planning in Nokia BSS
With Nokia Dynamic Abis functionality Abis resources for packet data are
reserved dynamically depending on the needed user throughput.
16.1.1 Abis EDGE dimensioning
These guidelines provide information on dimensioning the Abis interface for
EDGE into an existing GSM network. The focus is on calculating the needed
transmission capacity in the Abis interface for the successful operation of the EDGE
network.

The dimensioning principles in EDGE networks differ quite dramatically from
the transmission dimensioning in GSM/GPRS networks. This is due to the introduction
of dynamic Abis, which makes it possible to transport higher data rate radio channels
over the Abis interface more efficiently than static channel allocation in GSM/GPRS
networks.

In GSM/GPRS networks, each timeslot in the radio interface has a corresponding
timeslot in Abis where traffic (voice/data) is carried. Because higher data rates are

supported in EDGE networks than in GPRS networks, more capacity in Abis is needed
in EDGE networks to carry this additional traffic. This is handled by the EGPRS
dynamic Abis pool (EDAP), which provides support for handling variable data rates.

The amount of these channels depends on the data traffic. The maximum
number of EDAP channels in a single EDAP is 48 (12 DS0 or 64 Kbit/s channel).
Multiple pools can be created within one PCM circuit, within the limits of the physical
capacity of the PCM. The throughput of a radio timeslot depends on the used coding
scheme.
16.1.2 Dynamic ABIS
As discussed, EDGE networks are capable of delivering higher data rates than
GPRS. For this reason, the concept of dynamic Abis has been introduced in Nokia
EDGE networks. In EDGE, some traffic timeslots are statically allocated as in
GSM/GPRS, while other timeslots are allocated dynamically when needed. This enables
a more efficient way of allocating Abis resources. It also makes it possible to share
available resources from the EDAP during peak traffic. Dynamic Abis are mandatory
for EDGE and CS-3/CS-4.

In Dynamic Abis, each timeslot in the radio interface has one corresponding
fixed sub-timeslot in the Abis PCM frame. These statically allocated channels are called
master channels. When the data rates go beyond 16 Kbps (when the coding scheme is in
the range from MCS2 to MCS9 and CS-3 and CS-4), extra traffic channels are required to
carry this additional traffic on Abis interface, and these are allocated from the EDAP.
The extra channels are called slave channels. This also applies to GPRS CS-2, if the
GPRS temporary block flow (TBF) is sent via a TRX that is connected to an EDAP. This
is caused by the BTS-BSC in band signaling on the Abis interface. The in band signaling
increases and the size of the radio link control (RLC) block increases from 268 bits to 368
bits (268 bps / 20 ms = 13.4 Kbit/s, 368 bps / 20 ms > 16 Kbit /s).

Figure below shows the allocation of Abis TSLs using different MCSs along with
the data rates of different coding schemes and the required amount of 16 Kbit/s
timeslots from the EDAP.

Figure 16 EGPRS Coding Schemes Characteristics
16.1.3 Dynamic Abis capabilities
The capabilities of the Abis interface implementation are listed below:

The maximum size of the dynamic Abis pool is 12 timeslots.
The master 16 Kbit/s timeslots in the fixed part and the timeslots for the EDAP must
be located in the same PCM frame. If partial E1/T1 switching is used, the PCM
timeslots that are supposed to be on the same E1/T1 frame must always be switched
to the same path.
All timeslots that belong to an EDAP should be contiguous.
One EDAP cannot be shared between several base control function (BCF) cabinets.
Sharing an EDAP between several cabinets may damage the TRX or the
transmission unit (DTRU) hardware.
The EDAP can be shared between the TRXs in the same BCF; it cannot be shared by
the TRXs in different BCFs. As soon as a new BCF is added, a new pool is needed to
take care of the packet-switched data handled by the BCF.
The theoretical maximum number of TRXs attached to one dynamic Abis pool is 20.
However, since the TRXs using EDAP resources must be allocated to the same Abis
ET_PCM line with the EDAP, the maximum TRX count for the EDAP is much less
than 20.

16.1.4 Nokia PCU Product Family and Features
Nokia PCU product family consists of the following products.

Figure 17 Nokia PCU Product Family
In the BSC3i 2000, there can be 0 to 10 logical PCU2s, composed of 0 to 4 physical
plug-in units (Maximum 100 logical PCUs in BSC 3i 2000), per BCSU. In the BSC3i 660,
there can be 0 to 2 logical PCUs per BCSU, composed of 0 to 2 physical plug-in units
(Maximum 36 logical PCUs in BSC 3i 660). A logical PCU is an entity handling the same
functionality in the BSC as a physical PCU plug-in unit in older Nokia BSC models. In
the Gb interface, one logical PCU handles one NSE. The PCU unit performs all the data
processing tasks that are related to the (E)GPRS traffic. It implements both packet
switched traffic-oriented Gb and Abis interfaces in the BSC.

A PCU includes microprocessors and digital signal processors integrated to the
same plug-in-unit to handle the tasks. The main functions are:

GPRS Radio Resource Allocation and Management
Scheduling and GPRS Radio Connection Establishment and Management
Data transfer
MS uplink power control
Coding Scheme Selection
Gb load sharing (uplink) and flow control (downlink)
Initial timing advance (uplink, downlink)
PCU status info collection - statistics
PCUs must be configured to every BCSU installed, but only the activated ones are to
be used. This requirement comes from the general N+1 redundancy principle of the
fault tolerant DX200 Computing Platform.

Features
PCU B
16 DSP per logical PCU one DSP core can handle only one EDAP but one EDAP
can be shared by several DSP cores.
In the PCU1s, one DSP core can handle 0 to 20 channels (16 Kbit/s), therefore
max 256 per PCU1.
PCU1 and PCU1-S can handle 128 radio timeslots or 256 EDAP channels.
PCU1 does not support CS3 & CS4, Extended Dynamic Allocation (EDA),
High Multislot Classes (HMC) or Dual Transfer Mode (DTM).
PCU 2D
8 DSP per logical PCU but more powerful
One DSP core can connect two EGPRS dynamic Abis pools (EDAP), but one
EDAP can be shared by several DSP cores.
One DSP core handles 40 channels. The maximum number of 16 Kbit/s channels
per PCU2 is 256.
PCU2 does not support PBCCH/PCCCH.
PCU2 does not support GPRS with Nokia InSite BTS.
16.1.5 Nokia PCU Dimensioning
The table below contains the capacities of both type of PCUs in use.
Limits per PCU PCU-B PCU2-D
Max RTSLs 256 256
Max 16kbps Abis Channels 256 256
Max 64kbps Abis Channels 64 64
Max EDAPs per PCU 16 16
Max BTSs 64 128
Max SEGs 64 64
Max TRXs 128 256
Max 64kbps Gb Channels 32 32
Logical PCU per PIU 2 2
Max PCU PIU per BCSU 2 5
Table 3 PCU Types and Capacities

PCU loading is done keeping the above mentioned criteria in mind. A total of 3
urban sites and 1 rural site are attached to a PCU. The most important factors to
consider while dimensioning the PCUs for BSS planning is the maximum number of
EDAP pools (max for 16 per PCU) and maximum number of 64kpbs Abis time slots (64
per PCU). These factors are most important because if any of these limits are reached in
a PCU, it will not be possible for to create any new sites/GPRS timeslots in it. Therefore
before assigning any GPRS/EGPRS timeslots to any PCU, we first check the PCU
loading in terms of EDAP pool/ (E)GPRS timeslots. This is usually checked by using
the BSC dump files. BSC dump files contain all the configuration information of a BSC
including PCU. Following are the steps for calculating the time slots per PCU.

Request the latest dump files from NSN Managed Services Team
Parse the dump using the parser available (Attached in the attachments section)
Sum the timeslots of EDAP+DAP defined per site
Extract the DAP pool IDs
Extract the NSE (PCU) against all the DAP pool IDs
Add the timeslots defined in NSE (PCU)
*This will give the number of time slots defined per PCU

Currently PCU symmetry has to be maintained in a BSC, meaning that a PCU
needs to installed and created with each BCSU regardless of its requirement, this
problem has been solved in the new BSC software RG10 in which PCU can be used
asymmetrically.
16.2 GPRS/EGPRS Planning in Siemens BSS
16.2.1 Abis EDGE dimensioning
The major difference between Nokia and Siemens ABIS is that Nokia provides
dynamic capacity on the EDAP pool defined whereas in Siemens complete ABIS pool is
dynamic, irrespective of data/voice traffic. This means that in Siemens, the data
services can occupy any time slot(s) of ABIS pool and no time slot (s) is reserved for any
specific traffic type. Therefore it becomes easier to allocate ABIS resources in Siemens
case for data traffic. Following is a small example which will make you understand
more.
For instance, we have a site planned with a configuration of 4/4/4. In order to
allocate Abis resource, we will make the following calculations:
TRX Count = 12
Abis Pool Required for 1 TRX = 2 X 64kpbs or 8 X 16kpbs
*Abis pool is usually defined in the 16kpbs time slots
Abis Pool Required for 12 TRXs = 12 X 8 X 16kpbs = 76 X 16kpbs
Signaling Requirements = 1 X 64kpbs or 4 X 16 kpbs

1 E1 contains a total of 124 X 16 kpbs timeslots. Since voice services require 76
timslots, we still have 48 timeslots remaining to be allocated. Out of these 48, 4 will be
required for TRX signaling (LAPD) which make a total of 44 remaining timeslots. As
per the standards, a user using EDGE capable handset can get a data rate of 384kbps at
Um interface at maximum. Therefore for providing the required bandwidth for this
much throughput, we have to assign the equivalent bandwidth on Abis interface. 384
kbps is equivalent to 24 * 16 kbps hence 24 timeslots (each of 16kbps) is usually required
at Abis interface for facilitating EDGE maximum throughput.

Now coming back to the example, the site with 4/4/4 configuration will therefore be
requiring 76 (for voice) + 24 (for EDGE/data) + 4 (signaling) = 104 (out of 124) timeslots
on Abis interface.

Now we will discuss the flexibility of Siemens Abis interface. In Nokias case, 24
timeslots (of 16kpbs each) would mean that a maximum throughput of 384kbps is
achievable but in Siemens case you can achieve even more. As mentioned before, in
Siemens the Abis timeslots are not dedicated therefore upon need, EDGE traffic can
occupy more than the 24 timeslots, provided there is no voice traffic running on them
(idle timeslots). The benefit we get is in cases where voice traffic utilization is low and
in those cases we can live with even defining less than 24 timeslots on Abis for GPRS as
well. Please remember that while defining the timeslots, we dont associate them with
any certain type of traffic so the timeslots definition is irrespective of data type. It is
only being used here to make you understand better.
16.2.2 Siemens PCU Product Family and Features
The figure below summarized the capacities of Siemens BSCs in terms of GPRS
channels.

Figure 18 Siemens BSCs GPRS Capacities
In case of eBSC, UPM boards are responsible for handling the packet data
channels. All PDTs are terminated by UPM boards and each UPM board terminates
850PDTs.

Figure 19 eBSC UPM Board Characteristics
In case of cBSCs, PPXX boards are responsible for handling the packet data traffic
channels. Each PPXX can handle 256 PDTs while the PPXX works in load sharing mode.
The table below gives the total number of PDT support in a cBSC with respect to the
number of available cards.

Card N. of
PPXX
N. of GPRS Channels
PPXX
0 0
1 256
2 512
3 768
4 1024
5 1280
6 1536
7 1792
8 2048
9 2304
10 2560
11 2816
12 3072
Table 4 PPXX Cards and No. of PDTs
16.2.3 Siemens PCU Dimensioning
The main difference in Siemens and Nokia PCU family is that in Siemens BSC, it
is possible to let the load balancing of PCU resources to be done by BSC. Although
function of assigning a site to certain PCU is still available in Siemens, most of the time
we let the BSC do the load distribution tasks. This makes the dimensioning job easier in
Siemens case.

Since we are not concerned about dimensioning of a single PCU, we consider all
available PCUs a single resource pool. For example, if we have a cBSC with 12 PPXU
boards, it means that we have a pool of 11+1(load sharing) PCUs available. At any
instant, the effective number of PCUs will remain 11 which results into the pool of
11X256 available PDTs. For dimensioning purposes, a planner just need to calculate the
total number of required PDT resources per BSC rather than per PCU. The easiest way
is to sum up the total number of Abis time slots assigned for data services in a BSC.
Following are the steps for calculating the BSC PCU required resource.

Request the latest dump files from NSN Managed Services Team
Parse the dump using the parser available (Attached in the attachments section)
Sum the total configured timeslots per site. Subtract the number of timeslots
required for carrying CS traffic. Add up the resulting sublots.
This will give the number of time slots defined per BSC
16.3 GB Interface Planning
16.3.1 GB Interface Introduction
The Gb interface is an open multivendor interface which connects one or several
BSSs to an SGSN, facilitating the transfer of GPRS signaling and user data between the
SGSN and BSC, and the logical radio interface between the SGSN and the MS. The Gb
interface allows signals from many users to be multiplexed over the same physical
resource.

To transmit the user data, Gb interface uses communication paths called Network
Service Virtual Connections (NS-VC), which are transmitted through paths offered by
the interface's subnetworks. The subnetworks can be frame relay- or IP-based. Both the
IP and the frame relay based Gb interfaces can exist parallel in the same SGSN. Both FR
and IP cannot be in use at the same time within the same NSE. NS-VC configurations of
both sides (BSS and SGSN) must match.

Figure 20 GB Interface
16.3.2 Gb Link Dimensioning
Each PCU has at least one Gb link towards the SGSN. In case of redundant Gb
two independent links are needed. The outcome of the Gb link dimensioning process is
the average size of the Gb link to carry the data traffic forecast. This part of the process
affects SGSN dimensioning and should be conducted together with PS Core planning.

The Gb should be capable of supporting the instantaneous data traffic being
carried by all cells connected to a particular PCU. If there is insufficient capacity the
effective user rate at the radio cell will be reduced.
16.3.3 Gb Link Dimensioning BSS point of view
The aim in the GB dimensioning is to ensure that the GB link is large enough to
handle the short term peak traffic of any single EDAP or cell data requirement. In
addition to this the target is to estimate that the GB link is large enough to support
simultaneous traffic of several EDAPs or PDTs. This is highly dependent on the traffic
distribution. The equation below is used to calculate the average GB link size (= Frame
Relay Bearer Channel capacity).
area network for that size EDAP Average * k size Gb Average
The k-factor is based on the estimate of the short term traffic distribution. If no
specific information about the distribution is available it is recommended to use the
default values. The table below gives the k values.

The theoretical minimum k-value (1.25) is assuming that the short term traffic is
totally unequal, meaning that when one EDAP/Cell Data resource is full of traffic the
others within the same PCU have no traffic.

The theoretical maximum k-value is the number of EDAPs allocated into one
PCU. This assumes that all the EDAPs are heavily loaded at the same short term period
and the Gb link is supposed to carry such traffic without additional delays.

In reality some delay is allowed during heavy simultaneous short term traffic
bursts and thus it is assumed that k-values greater than 2 are rear.

If no estimate is available for short term traffic distribution the default value shall
be used. To show more cost effective results unequal distribution may be considered.

k-factor
Short term traffic distribution
Unequal (low likelihood
of heavy simultaneous
short term traffic)
Default Equal (high likelihood of
heavy simultaneous short
term traffic)
30% 50% 70%
1.4 2 3
Table 5 K Factor for GB Dimensioning
During the planning phase when individual EDAPs are associated to PCUs more
accurate values for individual Gb links are calculated taking into account the usage of
individual E1/T1 links.
16.3.4 Gb Link Dimensioning Example BSS view
The used input for Gb link dimensioning are:
15 Urban sites having EDAP size 12 TSL
25 Sub-urban sites having EDAP size 6 TSL
Average EDAP size = (15*12 TSL + 25*6 TSL)/40 = 8.25 TSL
The average Gb size according equation above is 2 * 8.25 TSL = 16 TSL. Practical Gb-
size would be 15 and 16 TSL to fully occupy an E1 line
17 DATA NETWORK OPTIMIZATION
Data network optimization needs to be carried out on the following three interfaces:
Abis utilization & congestion
PCU utilization & congestion
Gb interface utilization & data discards

SGSN
SGSN
PCU
Abis Gb
BTS
BTS
A-bis Pool
Blocking
Siemens
EDAP Pool
Blocking Nokia
BSC
PDT Rejections
Territory
Upgrade
Rejections
Nokia
Gb
Throughput &
discarded Data

Figure 21 Date Network Main Interfaces

17.1 ABIS Congestion:
17.1.1 Nokia EDAP Pool Blocking
Dynamic Abis splits Abis E1/T1 transmission lines into:

Permanent 16 kbit/s sub timeslots for signaling
Permanent 16 kbit/s sub timeslots for voice and data

As discussed above, Dynamic Abis Pools (DAP) are allocated for radio timeslots that
require more than 16kbit/s transmission capacity from Abis. The DAP area used by (E)
GPRS is called the EGPRS Dynamic Abis Pool (EDAP). The DAP can be shared by a
number of EDGE-capable transceivers (TRX) in the same BCF cabinet. The DAP and the
TRXs sharing it have to be allocated to the same Abis E1/T1 transmission line.

In the BSC there can be two different (E) GPRS territory types:

1. GPRS territory
CS1 and CS2 packet data channels, no DAP
CS1 - CS4 packet data channels, DAP required
2. EGPRS territory
TSL 1
TSL 12
TSL 13
TSL 18
TSL 24

EDAP pool congestion on Abis interface is identified using NEDs Dynamic Abis
Pool report 280.
17.1.1.1 Key Performance Indicators (KPI)
Inadequate EDAP resources in downlink, S11 (dap_7a)
Indicates the time in minutes per gigabytes when the available downlink EDAP
resources are inadequate because of the size of EDAP. Any value greater than 0
min/GB needs to be evaluated case by case for EDAP expansion
Formula:

Sum(DL_Indadeq_Time_minutes)/Sum(DL GPRS payload_Gbyte+DL EGPRS
payload_Gbyte) =sum( a.dl_tbfs_with_inadeq_edap_res) / (50 * 60)
----------------------------------------------------------------------------------------------------------------
sum over BTS with EGENA Enabled= ( rlc_data_blocks_dl_cs1 *20 +
rlc_data_blocks_dl_cs2 *30 + sum over MCS-1 (xx)* 22 + sum over MCS-2 (xx)* 28 +
sum over MCS-3 (xx)* 37 + sum over MCS-4 (xx)* 44 + sum over MCS-5 (xx)* 56 +
sum over MCS-6 (xx)* 74 + sum over MCS-7 (xx/2)*112 + sum over MCS-8
(xx/2)*136 + sum over MCS-9 (xx/2)*148 ) / (1024*1024*1024)
Where xx = (dl_rlc_blocks_in_ack_mode + dl_rlc_blocks_in_unack_mode)
17.1.1.2 COUNTERS:
As a second step following two counters are checked:
Peak DL EDAP Usage (c76004--- PEAK_DL_EDAP_USAGE)
Peak UL EDAP Usage (c76005--- PEAK_UL_EDAP_USAGE)

Counter c76004 & table name PEAK_DL_EDAP_USAGE gives Peak usage of 16
kbit/s PCM sub TSLs in the downlink direction. 100% Peak DL EDAP usage causing
greater than 0 min/GB of inadequate EDAP pool usage and as a result TBF rejections
shall trigger Edap expansions.

Counter c76005 & table name PEAK_UL_EDAP_USAGE gives Peak usage of 16
kbit/s PCM sub TSLs in the uplink direction. 100% Peak UL EDAP usage causing
greater than 0 min/GB of inadequate EDAP pool usage and as a result TBF rejections
shall trigger Edap expansions.
17.1.1.3 EDAP Expansion:
When EDGE is enabled on a site minimum 6 EDAP TS are defined when
expansion is required TS are increased in steps of three to 9TS,12 TS & 24 TS depending
upon the availability of resources on Abis interface.

17.1.2 Siemens EDAP Pool Blocking
The Dynamic Abis Resource allocation discussed above is applied both to packet
switched services and to circuit switched services in Siemens. According to the service,
the appropriate number of Abis resources is dynamically allocated during the radio
channel allocation. As soon as the radio timeslot is released the allocated Abis resources
are set free again. In case of packet services, the initial number of Abis resources can be
modified at run time, according to Link Adaptation feature.

In case of packet services, the new Abis allocation strategy is coupled with a new
format of PCU frames, the concatenated PCU frames that allow transferring a radio
block split on several Abis resources.

As there are no fixed data timeslots in Siemens architecture; Abis pool is shared
between circuits switched & packet switched traffic.
17.1.2.1 Counters
Abis pool blocking is identified through Abis pool supervision counters in
SCANFBTSM scanner. These counters can be extracted from optima:

Mean number of defined Abis sub-channels
Mean number of available Abis sub channels
Mean number of allocated Abis sub channels
Max number of allocated Abis sub channels
All available Abis sub channels allocated time
Number of successful Abis sub channel seizures
Number of unsuccessful Abis sub channel seizure attempts
Number of Abis sub channel modifications
The counters are formed into following main KPI(s) for Abis analysis with average
of 3 max peaks from a sample of 7 days data at cell busy hour is reported.

1. Abis Pool Blocking= Number of unsuccessful Abis sub-channel seizure attempts)
/(Number of successful Abis sub-channel seizures+ Number of unsuccessful
Abis sub-channel seizure attempts)
2. Abis Pool timeslot Utilization= Max number of allocated Abis sub-channels /
Mean number of available Abis sub-channels
3. Abis Pool Availability= Mean number of available Abis sub-channels / Mean
number of defined Abis sub-channels

17.1.2.3 Abis Pool Expansion
Following aspects are to be considered while considering the Abis pool expansion.

Abis pool blocking greater than 5% is considered for Abis expansion with the
addition of a new E1/LAPD at site.
Abis Pool availability less than 100% depicts media operational issues & needs to be
taken up with concerned team for rectification.
Abis pool timeslot utilization shows the overall usage rate of defined Abis timeslots.
If average Abis TS utilization is greater than 80% abis pool expansion is initiated.
17.2 PCU Congestion:
PCU covers RLC/MAC functionality towards the Abis interface and BSSGP &
Network Service layer towards Gb
17.2.1 Nokia PCU Congestion
BTSs are shared amongst PCU with one BTS being always controlled by one PCU.
BTS sharing amongst PCU(s) imply sharing of packet-switched traffic load among
BCSUs. Equal sharing of the BTSs is efficient from PCU utilization & O&M point of
view because no BTS switchovers from one PCU to another are needed when the
network is growing.

PCU congestion in Nokia land is monitored by territory upgrade rejections.
Counters for territory upgrade rejections can be extracted from optima or from Netact
ND reports
1. Optima: Counter class P_NBSC_TRAFFIC
2. NetAct ND report 239
17.2.1.1 COUNTERS:
The counters available for in P_NBSC_Traffic for analyzing GPRS resource
congestion are as follows:

GPRS TER UPGRD REQ(NE Counter name): GPRS_TER_UPGRD_REQ (Table
counter name)
o Number of territory upgrades requests received from the Packet Controller
Unit.
GPRS TER UG REJ DUE CSW TR( GPRS_TER_UG_REJ_DUE_CSW_TR)
o Number of territory upgrades requests that have been rejected due to the
high load of the circuit switched traffic.
GPRS TER UG REJ DUE LACK PCU CAP (GPRS_TER_UG_REJ_DUE_LACK_PCU)
o Number of territory upgrades requests that have been rejected because the
capacity of the Packet Controller Unit the BTS is connected to is already
totally in use.

GPRS TER UG REJ DUE LACK PSW RES (GPRS_TER_UG_REJ_DUE_LACK_PSW)
o Number of territory upgrades requests that have been rejected because there
are not enough resources capable of GPRS in the BTS.
GPRS_TER_DOWNGRADE_REQ
o Number of territory downgrade requests received from the
GPRS_TER_UG_DUE_DEC_CSW_TR
o Number of GPRS territory upgrades made to fulfill the default GPRS territory
as a consequence of decrease in the circuit switched traffic load.
GPRS_TER_DG_DUE_INC_IN_CSW_TR.
o Number of GPRS territory downgrades made because of the increase in the
circuit switched traffic load.
17.2.1.2 Key Performance Indicators
Few of the above mentioned counters help in analyzing the congestion at PCU
end. Following is the KPI made with the use of the relevant counters PCU congestion
analysis.

% territory upgrade rejections due to PCU congestion= GPRS TER UG REJ DUE LACK
PCU CAP X 100 / GPRS TER UPGRD REQ
17.2.1.3 Counter / KPI Analysis
o Counter report generated from optima gives hourly stats per BSC.
o Counter values are summed up per day to get daily totals; average of three max
values is then reported for each counter.
o Percentage territory upgrade rejections due to PCU congestion is evaluated by
formula given previously, cases with greater than 0% are highlighted for further
analysis.
o Territory upgrade rejection due to PCU congestion at BTS level is extracted with
highlighted BSCs.
o Once the sites are identified their PCU is identified through MML session suing the
command ZFXO: BCSU=0&&6:BTS; (BSC3i-660); or ZFXO:BCSU=0&&10:BTS;
(BSC3i-2000) which gives site configuration per PCU (NSEI/NSVCI).
o The number of equivalent radio timeslots configured on the PCU handling site with
high number of territory upgrade rejections is calculated through following
procedure:
A=Number of EDAP TS(64Kbps)
B=Number of DAP TS (64Kbps)
C=Number dynamic & fixed data timeslots= (1,3) or (2,3) (depends upon
network configuration)
D=Total cells/segments*C (16 Kbps)
RTSLs= Number of sites*( (A*4)+(B*4)+D)

o Number of RTSLs is greater than 256; maximum PCU handling capacity; & hence
rejection in territory upgrades.
17.2.1.4 Nokia PCU Optimization
The site needs to be shifted to another PCU whose handled RTSLs does not
exceed 256 after the site shifting. The following figure explains this further.

Figure 22 PCU Resource Utilization
If all PCUs in a BSC have reached their utilization threshold of 256 RTSLs then
PCU expansion is required. Max attainable PCU count in case of BSC 3i-660 can go upto
24 & to 100 in case of BSC 3i-2000.
17.2.2 Siemens PCU Congestion
Each cell can be related to one Pool of the PPXUs/UPM by means of a specific
CLI command: according to this request a cell may be supported by only one PCU pool;
The cells are assigned dynamically by BSC to PPXU inside the Pool taking in
consideration load balancing concepts, for example a Load balancing algorithm is
applied separately for each configured pool. A cell as well as a PPXU board can be
moved from one Pool to another Pool by means of a Set command. This command is
preceded by the Lock command related to the Managed Object affected by the PCU
pool change.

The number of the supported PDTCHs is up to 3072 in cBSC out of which only
2816 are guaranteed which 91% of the total capacity.

In eBSCs the data capacity of BSS network not only depends upon the maximum
hardware capacity but on installed license capacity too. The licenses are purchased for
Gb throughput & PDTs.
17.2.2.1 Measuring PCU congestion & PDT Utilization in Siemens Land
PCU congestion in Siemens land is monitored by PDTCH/PDT rejections. Counters
for which are extracted from optima:
1. Counter class SCANGPRS

Figure 23 SCANGPRS Counters
Average of three max values from a sample set of 7 values is reported for the
following two counters:
SCANGPRS_6
SCANGPRS_18

Totally utilized PDT count is a KPI calculated from counters in scanner SCANBSC
adding up max count of used PDTs in each PPXU/UPM card:
Used PDT/PDCH count per BSC= NPDCHPCU_2+NPDTPCU_2+NPDTPCU_5+
NPDTPCU_8+NPDTPCU_11+ NPDTPCU_14)
The value for each UPM card if greater than 773 PDTs (91% of 850) or in case of
PPXU greater 233 PDTs(91% of 250) cause PDTCH/PDCH rejections.
17.2.2.3 Siemens PCU Optimization:
PCU expansion is required in case used PDTs are reaching max PCU RTSL
handling capacity. The total PCU capacity attainable is 12 PPXU cards in cBSCs & 10
UPM cards in eBSCs

The figures below illustrate few such examples where PDT rejections are being
faced due to over utilization of PCU resources.

Figure 24 PDT Rejections due to PCU Overload
17.3 Gb Utilization & Congestion:
17.3.1 Measuring Gb utilization & congestion
The following methods are used for calculating the utilization and determining the
congestion in GB interface.

RC2 or GC: Reporting suite report customized report RSSG2G015 - 2G NSVC data
KPI browser (Raw counters)

The following counters are used for this calculation.
disc_data_due_fr_nsvc_cir_oflo (Nsvcdata)
fr_nsvc_passed_data (Nsvcdata)
busy_hour (Nsvcdata)
NSVC_DISC_DATA_BYTES_PR1 (Nsvcdata)
NSVC_DISC_DATA_BYTES_STR (Nsvcdata)

NSVC_DISC_DATA_PACKETS_PR1 (Nsvcdata)
NSVC_PASSED_DATA_BYTES_PR1 (Nsvcdata)
NSVC_PASSED_DATA_PACKETS_STR (Nsvcdata)
NSVC_UPLINK_DATA_IN_BYTES (Nsvcdata)
NSVC_UPLINK_DATA_IN_PACKETS(Nsvcdata)
17.3.2 Customized Report KPI(s) & Counters (SGSN):
NS-VC UL data {NS-VC UL data volume, kB }
o ((nsvcdata.nsvc_uplink_data_in_bytes)/1024)
NS-VC DL data { NS-VC DL data volume, kB}
o ((nsvcdata.nsvc_passed_data_bytes_pr1+nsvcdata.nsvc_passed_data_byte
s_pr2+
nsvcdata.nsvc_passed_data_bytes_pr3+nsvcdata.nsvc_passed_data_bytes
_pr4+ nsvcdata.nsvc_passed_data_bytes_str) / 1024)
Incoming traffic kB
o (nsvcdata.fr_nsvc_passed_data+nsvcdata.disc_data_due_fr_nsvc_cir_oflo
+ nsvcdata.shared_cap_to_anoth_fr_nsvc) / 1024
Traffic to other FR NSVC, share {%}
o 100*decode((nsvcdata.fr_nsvc_passed_data+
nsvcdata.disc_data_due_fr_nsvc_cir_oflo+nsvcdata.shared_cap_to_anoth_
fr_nsvc),0,0,(nsvcdata.shared_cap_to_anoth_fr_nsvc) /
(nsvcdata.fr_nsvc_passed_data +
nsvcdata.disc_data_due_fr_nsvc_cir_oflo +
nsvcdata.shared_cap_to_anoth_fr_nsvc))
Traffic from other FR NSVC, share {%}
o 100*decode((nsvcdata.fr_nsvc_passed_data),0,0,
(nsvcdata.shared_cap_to_anoth_fr_nsvc) /
(nsvcdata.fr_nsvc_passed_data))
Data discard, ratio
o {100*decode((nsvcdata.fr_nsvc_passed_data+nsvcdata.disc_data_due_fr_n
svc_cir_oflo+nsvcdata.shared_cap_to_anoth_fr_nsvc),0,0,(nsvcdata.disc_d
ata_due_fr_nsvc_cir_oflo)/(nsvcdata.fr_nsvc_passed_data +
nsvcdata.disc_data_due_fr_nsvc_cir_oflo +
nsvcdata.shared_cap_to_anoth_fr_nsvc))
Passed {NS-VC DL priority 1 passed data, kB}
o (nsvcdata.nsvc_passed_data_bytes_pr1)/1024

Disc ratio {NS-VC DL priority 1 data discard ratio, %}
o 100*decode( (nsvcdata.nsvc_passed_data_bytes_pr1 +
nsvcdata.nsvc_disc_data_bytes_pr1),0,0,
(nsvcdata.nsvc_disc_data_bytes_pr1) /
(nsvcdata.nsvc_passed_data_bytes_pr1 +
nsvcdata.nsvc_disc_data_bytes_pr1))
Passed {NS-VC DL streaming passed data, kB}
o (nsvcdata.nsvc_passed_data_bytes_str)/1024
Disc ratio { NS-VC DL streaming data discard ratio, %}
o 100*decode( (nsvcdata.nsvc_passed_data_bytes_str +
nsvcdata.nsvc_disc_data_bytes_str),0,0,
(nsvcdata.nsvc_disc_data_bytes_str) /
(nsvcdata.nsvc_passed_data_bytes_str +
nsvcdata.nsvc_disc_data_bytes_str))
17.3.3 Key Performance Indicators
Gb payload NSEI (kbits)= NS-VC DL data *8
Gb throughput NSEI (kbps) =(Gb payload (NSEI))/3600

Discarded Data= (Disc ratio/100)* NS-VC DL data
17.3.4 Gb Optimization:
The following flow is used for GB interface optimization tasks.
Gb utilization & data discards are monitored for each NSEI/NSVCI using the
reports/KPI(s) & counters discussed above.
In case Gb interface (CIR) utilization of an NSEI is exceeding 80% & NSEI is having
data discards:
o Gb interface bandwidth balancing is done by shifting gb timeslots from the
least utilized NSEI/NSVCI to highly utilized NSEI/NSVCI
In case Gb interface (CIR) utilization of an NSEI is less than 80% & NSEI is still
having data discards (random/ Non-random pattern) there can be following two
possibilities:
o Throughput exceeded the Gb bandwidth value (CIR) of the NSEI/NSVCI
causing data discard for the amount of the time this condition persists.
Depending on the discarded data value the CIR should be increased
o If data throughput is less that CIR allocated to the NSEI/NSVCI then there is
a possibility of TXN media fluctuation causing data discards. It should be
taken up with the concerned operations team.

18 ANNEXURE
18.1 Siemens BSC Capacities

18.2 Nokia BSC Capacities

18.2.1 Nokia BSC Fact Sheet

BSSP&O Guidebook

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BSSP&O Guidebook

Загружено:

Авторское право:

Доступные форматы

BSS Planning and

Вам также может понравиться

BSSP&amp;O Guidebook

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BSSP&amp;O Guidebook

Загружено:

Авторское право:

Доступные форматы

BSS Planning and

Вам также может понравиться

BSSP&O Guidebook

BSSP&O Guidebook