BSSP&O Guidebook

7/18/2019 BSSP&O Guidebook

http://slidepdf.com/reader/full/bsspo-guidebook 1/82

BSS Planning andOptimization 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 ChangeOwner

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 Draft05-July-10

Document Location \\10.7.26.125\BSS Shared Documents\BSSPlanning 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 R ADIO C OMMANDER I NTRODUCTION : ....................... .......................... ...................... 11 7.2.2 N OKIA N ET ACT I NTRODUCTION : .............................................................................................. 12

7.3 NMS(S) CAPACITIES .................................................................................................................... 12 7.3.1 N OKIA N ET ACT RC C APACITIES: .......................... .......................... ......................... .................. 12 7.3.2 SIEMENS R ADIO C OMMANDER C APACITIES: ............................................................................. 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 T OOLS .................................................................................... 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 F ORECAST . ............................................................................................................ 18 8.2.2 TRX C OUNT . ............................................................................................................................. 18

8.3 METHODOLOGY: .......................................................................................................................... 18 8.3.1 N OKIA BSC REQUIREMENT C ALCULATION F ORMULA ........................ ......................... .............. 20

8.3.2 SIEMENS BSC REQUIREMENT C ALCULATION F ORMULA ........................................................... 21

8.4 BSC DEPLOYMENT: ........................... .......................... .......................... ......................... .............. 22

8.4.1 LOCATION SELECTION : .............................................................................................................. 22 8.4.2 BOUNDARY DEFINITION : ........................................................................................................... 22 8.4.3 D ATA C OMPILATION : ................................................................................................................ 22

8.5 BTS MIGRATION: ......................................................................................................................... 23 8.5.1 NCT PREPARATION : ....................... .......................... .......................... ......................... .............. 23

8.5.2 SITE PRIORITY ASSIGNMENT AND RF D ATA VERIFICATION : ........................ .......................... ..... 24

8.5.3 RE-PARENTING WO GENERATION : ............................................................................................ 24

9

BSC RESOURCE OVERLOAD ...................................................................................... 24

9.1 BSC PROCESSOR OVERLOAD ....................................................................................................... 25 9.1.1 H OW TO CHECK PROCESSOR LOADS .......................... .......................... ......................... .............. 25

9.1.2 EXAMPLE OF HIGH PROCESSOR LOADS ...................................................................................... 25



9.1.3 H OW TO REDUCE THE PROCESSOR LOADS ................................................................................. 26

9.2 BSS SIGNALING LINKS OVERLOAD.............................................................................................. 26

9.2.1 H OW TO CHECK THE SIGNALING LOADS ........................ .......................... .......................... ......... 26 9.2.2 C URRENT SIGNALING LINKS C ONFIGURATION IN TP N ETWORK : ......................... ...................... 27 9.2.3 W AYS TO DECREASE THE LOAD ................................................................................................. 28 9.2.4 M ULTI POINT A- I NTERFACE SOLUTION IN N OKIA L AND ............................................ .............. 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 T ERMINATION ) ..... .............................. .............................. ....................... 34

10.5.2 TCSM R ACKS .......................................................................................................................... 34 10.5.3 N OKIA 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 N OKIA 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 C BSS LAPD C APACITY : ......................... ......................... .......................... .......................... ..... 44 13.3.2 EBSS LAPD C APACITY : ........................................................................................................... 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 KPI’S ............................................................................................................................ 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 N OKIA PCU PRODUCT F AMILY AND F EATURES ...................................................................... 61

16.1.5 N OKIA 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 F AMILY AND F EATURES ........................ ......................... .................. 64 16.2.3 SIEMENS PCU DIMENSIONING ................................................................................................ 65

16.3 GB INTERFACE PLANNING ........................................................................................................ 66

16.3.1 GB I NTERFACE I NTRODUCTION ............................................................................................... 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 N OKIA EDAP POOL BLOCKING ............................................................................................... 69

17.1.2 SIEMENS EDAP POOL BLOCKING ............................................................................................ 71

17.2 PCU CONGESTION: ......................... .......................... .......................... ......................... .............. 72

17.2.1 N OKIA PCU C ONGESTION ....................................................................................................... 72 17.2.2 SIEMENS PCU C ONGESTION .................................................................................................... 74

17.3 GB UTILIZATION & CONGESTION: ........................ .......................... ......................... .................. 76

17.3.1 M EASURING GB UTILIZATION & CONGESTION ......................... .......................... ...................... 76 17.3.2 C USTOMIZED REPORT KPI( S ) & C OUNTERS (SGSN): ....................... ......................... .............. 77 17.3.3 K EY PERFORMANCE I NDICATORS ............................................................................................ 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 N OKIA BSC F ACT 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 BSSdesign 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 specifictask, followed by the criteria, the parameters and the quality objectives. The guidelinesgiven in this document have been extracted from vendor’s recommendation andindustry standards. Any deviations from the vendor recommendation have beendiscussed 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. Thedepartment is responsible to plan and dimension the base station subsystem (BSS) insuch a way that the performance experienced by the end-users is not limited by anoverload in the BSS. The objective of the department is to accommodate the capacityrequirements for voice, data, signaling and OSS services while maintaining theperformance 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 BSSnetwork. The BSS planning process starts from making the budgets and plans for theyear based on the inputs from NSS and RF department. The inputs contain thesubscriber and traffic forecast, and new sites and expansion information. These inputsare produced from the feedback of commercial department. After gathering all therequired information, current network status is assessed and then a precise year plan ismade after taking into consideration the allocated budgets.

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

In the sections below, a brief description of all the steps involved in making NewYear 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 andRF departments. An input of good quality and detail is one of the keys to make a goodforecast 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 theexpected growth in the subscriber base. Together will the expected traffic per subscriberand 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 resourceavailability 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 theinputs mentioned above, to determine the resources and budgets required, needs ofrehomings and module expansions etc. The analysis procedure takes into account:

Current BSS Network CapacitiesBSS 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 loadsare calculated and over/under utilized resources are identified. This analysis will helpin determining the number of resources required. Complete cumulative RAN inventory

A complete RAN inventory is maintained which includes the total number andconfigurations of TRXs, CELLs, SITEs, BSCs, PCUs as well as any other accessequipment. The inventory specifies the equipment in the Warehouse or delivery whichis scheduled.

Inputs from NSS, BSS inventory and the BSS network analysis are used for HWcalculation 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 doesn’t confine itself to planning functions but activelyparticipates in all the implementation activities as well. The department ensures that allthe activities are being carried out according the plan and pre/post tests are being doneto 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 departmentwhich prepares reports on daily/weekly/monthly basis. These reports are used for

budgeting, planning and optimization of the BSS network. Based on these reports, theteam works to achieve the KPI values required for a quality network. Since BSS has thecentral function in the basic GSM network therefore along with its target KPIs, BSSP&Ohelps 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 BSSnetwork. Following list contains the description of all major functions of thedepartment. BSC Planning:

BSC planning is done to accommodate the offered traffic, busy hour all attempts andsignaling loads.

GPRS Resource Planning:

GPRS resource planning is done to ensure that end user never faces any congestionon Abis and GB interfaces.

PCU Planning:

PCU planning is done to provide the required capacity in the PCUs to handle thedata 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 andBSCs 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 acheck on network performance and for timely highlighting the degradation issuesthrough 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 thequality 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 andrecommendations to the management

Every day Jobs

BSS Level Features Activation, network nodes load balancing, load distribution, BSSnetwork audits are the other major functions that are being carried out by thedepartment in routine.

6

EXPECTATIONS FROM BSSP&O

BSSP&O has always set high targets and have managed to achieve those targets aswell. This has only been possible by setting very high standards for itself. Setting highstandards mean that we have high expectations from ourselves as well as from themanagement. 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 todo the O&M tasks from a centralized location. The O&M traffic from the BSS nodes iscarried 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 dataarrives at NMS system, these systems converts it into a readable format which is thenused to perform all these tasks.

7.2

NMS(s) in TP BSS Network

TP network contains the BSS network of two technologies namely Siemens andNokia. Each technology has a unique way of handling the O&M tasks therefore werequire a Siemens NMS for handling Siemens O&M while a Nokia NMS is required forNokia 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 TP’s BSS network.

Technology System Name Platform Software Version

NokiaNetAct RC 1

HPOSS 5.1

NetAct RC 3 OSS 4.2

SiemensRCOMP1

SUNBR 9.0

RCOMP2 BR 9.0

7.2.1

Siemens Radio Commander Introduction:

The basic core package of the Radio Commander includes the essential componentsfor operating and maintaining the mobile radio network and for keeping the systemopen for new technologies. Technology plug-ins for GERAN and UTRAN providesupport 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 NextGeneration OSS (NGOSS) and third Generation Partnership Project (3GPP) andTeleManagement Forum’s eTOM model. NetAct covers the following parts of theoverall 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 itmanages the sub network only.

FCAPS coverage: NetAct covers: (FM) Fault Management, (CM) ConfigurationManagement, (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 likeSQM, NWW (Monitor), Reporter, Traffica, and Trace. NetAct covers the Fulfilment

part with components like NetAct Configurator and Optimizer for RAN and BSSnetworks. NetAct does not provide components for Billing.

Multi-Technology: NetAct manages different network technologies, including 2GBSS & NSS, Packet Core, 3G RAN.

Multi-Vendor: NetAct can be easily adapted to the equipment of 3rd 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 RadioCommander 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 yearso 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 NMSsystems

o This is usually done by comparing the new offer with the PO (PurchaseOrders)/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 makessure that system never reaches an overload situation which can potentially cause anoutage on the system level. An outage on NMS level means that network will not beaccessible during the outage time.



7.7.1

NMS Performance Analysis Tools

BSS planning & optimization uses the following ways/tools to monitor theperformance the NMS systems.

7.7.1.1

Cacti

Cacti provide a way for proactive monitoring of all OSS Systems in order to keepthem in good health. SNMP protocol has been used to monitor the NMS systemseffectively with minimum overhead on system performance. It provides rapiddeployment and wealth of performance graphs which can provide an insight toproblems in a proactive way.

User can access the Cacti application using the following way.http://edr.telenor.com.pk/cactiUser Name: TelenorPassword: Telenor@123

7.7.1.2

NMS Capacity Reports

NMS capacity reports are shared by the vendor OSS team on weekly basis. Thesereports contain the summary of NMS KPIs. The report contains the average andmaximum utilizations of CPUs, RAM and File System in a week’s time.

Figure 6 NMS Weekly Performance Report

http://edr.telenor.com.pk/cacti

http://edr.telenor.com.pk/cacti



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

1.

Load Balancing

The most common cause of system resources overload is uneven loading/loaddistribution in the existing resources. In order to rectify the overload problem, BSCshifting 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 regionalboundaries set by operations, NOC and RF departments.Check-2: Processor and DB Loads of all the NMSs involved in the load balancingactivity should be checked.

2.

Operations EscalationIn a case where the load balancing is either not possible or no NMS has enoughroom available or the NMS loading is within the planning limits, we consider to escalatethe critical utilization problem to TP OSS operations team. This type of problem isusually 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 3rd

linesupport (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, Nokiaand Siemens. Each vendor has provided two versions of BSC equipment in our



Network. Each BSC has its own specifications and hence capacity constraints. Somemajor capacity limiting factors that are considered while planning a BSC are mentionedbelow: 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 = 900eBSC: Traffic Capacity = 10000 Erl, TRX Capacity = 2000

It is important to note that a new BSC is planned at 70% loading with respect totraffic 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 isimpossible to determine the BSC requirement.

8.2.1

Subscriber Forecast.

A BSC wise subscriber count is required for the coming year based on which thetotal expected traffic is calculated. BSS planning expects to receive this input dividedinto 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 nodesrequirement. 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 inputsprovided 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 weightagetrend is analyzed. Based on this trend the percentage weightage is extrapolated forthe 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 FormulaNow 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 mentionedformulae:

For TRX:IF ((S1 - R1)> ((X1 * Z1) + (X2 * Z2)))

ThenCEILING ((S1 - R1)/ (2000 * T / 100), 1)

Else0

o

S1 = Total Forecasted TRX Count per city.


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 greaterthan 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 becatered for with the existing BSC(s).

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



ThenCEILING ((S2 - R2)/ (11880 * T / 100), 1)Else0


o

R2 = Offered Traffic per city.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 theweighted sum of both BSC2000 and BSC660 at a user defined BSC threshold value thenthe difference is divided by the total Traffic capacity of a BSC3i 2000 with 70%

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 Traffic can becatered for with the existing BSC(s).

8.3.2

Siemens BSC Requirement Calculation Formula

For TRXIF ((S1 - R1)> ((X1 * Z1) + (X2 * Z2)))

ThenCEILING ((S1 - R1)/ (2000 * T / 100), 1)

Else0

o

S1 = Total Forecasted TRX Count per city.


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 greaterthan 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%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 TrafficIF ((S2 - R2)> ((X1 * Z1) + (X2 * Z2)))



ThenCEILING ((S2 - R2)/ (10000 * T / 100), 1)Else0


o

R2 = Offered Traffic per city.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 theweighted sum of both eBSC and cBSC at a user defined BSC threshold value then thedifference is divided by the total Traffic capacity of a BSC3i 2000 with 70%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 Traffic can becatered for with the existing BSC(s).

8.4

BSC Deployment:

So far we have calculated the requirement for addition of BSC node in a city. Nowwe 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 ofthe BSC. It is preferred to deploy a BSC on a MGW or Green Field location but if aconcern is raised from any of the above mentioned stakeholders that MGW or GreenField location is not feasible then a shelter site is selected after mutual agreementbetween all stakeholders. Thereafter, site design and power planning teams arerequested 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 planningTeams. 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 shouldbe 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 thatare 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 NSEIallocation 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 inthe 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 toFO (Field Operations) team for implementation. Upon receiving this plan, FO teammoves this BSC to the requested location. Thereafter BSC is installed/ commissionedand integrated.

8.5

BTS Migration:

Now the BSC is ready to carry commercial Traffic. The next step is to move thelive sites to this BSC so that the BSC can start carrying the live traffic and can bedeclared 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 sectionsbelow:

8.5.1

NCT Preparation:

BSS planning prepares a re-parenting NCT of sites that were planned to bemigrated to the new BSC with the RF teams. The NCT is prepared using the latest BSCdumps. This NCT contains the site IDs, segment IDs, existing BSC ID, existingLAC/RAC IDs, existing BSC’s SPC, Cell IDs, new BSC’s 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 priorityassignment is necessary because a maximum of 15 sites can be migrated in a singlenight, hence if the site count is greater than this RF needs to distribute the sites overseveral nights. They assign priority according to the activity night making site clustersthat 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 listto TXN planning and requests them to issue the site testing/patching WO (re-parentingWO). 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 everynight’s activity FO is required to provide a feedback of the activity to all stakeholders.

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

9

BSC RESOURCE OVERLOAD

After the integration of a BSC in the network, BSS planning and optimizationcontinuously keeps on monitoring the BSC performance. This is essential formaintaining the health of a BSC. The most important KPIs for monitoring the BSCperformance are:

BSCs processor load

o Higher than recommended processor loads can affect the performance of aBSC and end user’s experience. It can potentially cause an outage on BSClevel which would mean that no service will be available in that BSC area.

BSC – MSC Signaling loado Higher than recommended signaling load can cause the loss of signaling

information. Signaling information is the most important type of informationin any network. Loss of this information means that many important tasks oruser 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 followingquery 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 FROMSIEMENS_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

ID’s 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 eMLPPsetting 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 thesituation 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 handoversshows around 10-12% decrease in TDPC load. In Nokia land , disabling the featureswhich 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 theCORE Network for all the signalling links of a particular BSC while for R99 we measurethe Signalling RCSLLOAD & TRSLLOAD of the CORE Network for all the signallinglinks of a particular BSC.



The Unit of Sinalling load is mERL and threshold is 400 mERL for individualsignalling links. In case of Nokia Land , we have an optimized Signalling overloadalarm 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 Networkwith both Nokia & Siemens BSC(s). Whereas Multi Originating Point Codes , MOPCcan only be configured in Siemens BSS with R4 Core network. Also 512 kbps Signallinglinks are only possible in Nokia land BSC’s with R4 Core Network.

a.

Example : Signalling Link Distribution Issue

In 2009, We observed that in MOPC implemented Siemens BSCs with R4 & R99network, 32 Signalling links on RCS path (MSC BSC) were not sharing the Signallingtraffic (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 wasconfirmed 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 toHSL links.Whereas MOPC Signaling Load distribution issues with R4 BSC(s) gotresolved 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 thepaging re-attempts on LAC level from Core side. We achieved around 10% increase inPSR through this testing.But with the increase of Paging Attempts, Signalling trafficincreased as well. We certainly didn’t want to revert the parametric setting so wedecided to upgrade the signalling links by implementing the MOPC. In this way weresolved 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 Cellboundaries 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 byincreasing the BW of the links.

Distribution of link loads/New Link Sets

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



which BSC takes two SPC’s. We have to make sure the signalling links distribution in 2n 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 existingR4 network nodes with U3C MGW. Integration of a high Capacity BSC with almost10,000Erl traffic requires to connect it with two U3C MGW with each supporting almost5,700Erl traffic in present configuration. The site connectivity diagram below explainthe physical and logical connectivity between High Capacity BSC and the MSC Serverclass 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 setswill be defined between the BSC and the two MGWs having equally distributedlinks 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 asSTPs. This implies that the route set from the MSS can reach the BSC throughtwo 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 loadshared over the two signaling link sets towards the BSC.

In case where more than two signalling link sets are required, multiple pointcodes can be created on either or both of the MGWs, and these point codes canfurther be set as STP points towards the MSS in signalling route sets. Amaximum of 4 STP points (alternate signalling routes or load shared routes) canbe 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 thetraffic from BSC to MSC and vice versa. Congestion at Ater interface can degrade theKPIs on Um interface therefore it is very important that Ater utilization is kept withinthe 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 iscalled 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 theAter(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 trunkutilization is approaching 75%, Ater addition plan is prepared before hand and floatedas soon as the trunk utilization touches the mark of 75%. In this case, number ofadditional Aters required is calculated through the following formula:

At the time of writing, the required trunk utilization is kept at 65%. Existing Atersmeans 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 TelenorPakistan’s network, the BSS equipment of Nokia as well as Siemens is deployed, so inthe 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 informationfrom 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 certainMSC/MGW, and the other contains the TRAU Racks that are present at the location ofthat MSC/MGW where these Aters are terminating.

Remember that in Siemens BSCs deployed in Telenor Pakistan’s 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 atthe 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 theworkbook 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 isalready working with 23 Aters. From the Daily and weekly BSS reports, we had beenobserving 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 wasreaching 2150 Erlangs. We calculate the value of required number of Aters usingequation 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 fractionalquantity, so we round the required number of Aters up. Thus we require the addition of6 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 wewrite “PCMS”, the number of first Ater is “0”. As Karachi BSC09 has already got 23Aters, this means that PCMS0 to PCMS22 are already running and we have to add 6Aters numbered from PCMS23 to PCMS28.

Lets now explain various entries in the first workbook i.e. S-WB-A. In thisworkbook, we are mainly concerned with two sheets. First sheet is named “Sheet1” andsecond one is named “trau”. Let’s 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 exactport of the respective rack which is free. Now for each TRAU Rack/TRAU port, weassign PCMS#; STLP Port and CIC number in columns E, G, and I. PCMS# will startfrom 23 and end at 28.

The STLP port is actually the port number on the BSC where the Ater (or anyother E1 connected with BSC) will physically connect with the BSC. In Siemens land, wehave two types of BSCs i.e. cBSC and eBSC. In case of cBSCs, STLP port number (whichis currently unused and can be used for patching the new Ater) is obtained fromanother 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 waslast modified. It is our convention that we make a new copy of the workbook onmonthly 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 ofTRAU ports to various PCMS in different BSCs. From this sheet, free TRAU ports can befound out. These are the TRAU ports and TRAU rack numbers that are written in Col Band 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 thenattach 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, wepopulate the entries of this workbook, name it after the BSC in which Ater addition isrequired, and float it. We do not save the populated workbook with us as all theinformation contained in it is also present in the workbook S-WB-A.

This second workbook is just a template in which stake holders put theirrespective data so that all the information required for Ater addition is aggregated atone place. As the Ater addition request is initiated by BSS planning, so the template ismaintained and floated by us. Populating this workbook is extremely easy. Just followthe 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 topoint of contact (POC) in TXN Planning and “DIUAllocations” mailing group. Alsokeep the POCs of Field Operations and BSS SLM team in CC along with the relevantManagers 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 allstakeholders. 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 theAter 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 isrequired from BSS end. This data compilation is specific to BSC3i 660; For BSC3i 2000another column is added containing the BSC STM number and the subsequent Timeslotnumber, since BSC3i 2000 is an STM based BSC with optical ports. Sample sheet isattached in Nokia Ater Addition Appendix.

BSS sends this sheet to NSS planning for DIU allocations and requests TXNplanning for transmission allocations and WO generation on Service Manager withcomplete NSS/BSS/TXN data.

10.5.2

TCSM Racks

In Nokia two separate generations of TCSM Racks are used. These are mentionedbelow:

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 Ateraddition 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 toBSC3i 660, for BSC3i 2000 another column is added containing the BSC STM numberand the subsequent Timeslot number, since BSC3i 2000 is an STM based BSC withoptical ports. This data is compiled in a sheet and sent to NSS/TXN planning teams fortheir respective domain’s port allocations and WO generation. Along with this sheet,

another sheet containing a graphical view of TCSM allocations is also attached for theconvenience 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 isfurther 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 isrequired from BSS end. TCSM port information consists of BSC RJ45 port number (E1patched from BSC to TCSM) and MSC RJ45 port numbers (E1s patched from TCSM toMSC/MGW). This data compilation is specific to BSC3i 660, for BSC3i 2000 anothercolumn is added containing the BSC STM number and the subsequent Timeslotnumber, since BSC3i 2000 is an STM based BSC with optical ports. This data is compiledin a sheet and sent to NSS/TXN planning teams for their respective domain’s port

allocations and WO generation. Along with this sheet, another sheet containing agraphical view of TCSM allocations is also attached for the convenience of BSS FO. Boththe 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. EachSTM port provides optical connectivity.

For Ater addition on BSC3i Combi BSC, BSC ET, STM and Tributary number (ETTimeslot 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. Inthat case the ET of BSC3i 660 or BSC3i 2000 is patched on to the ET port of BSC3i CombiBSC. 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 numberSTM and Tributary number (ET Timeslot and STM number from 1 to 2), the Aternumber, the BSC ID and TCSM ports are required from BSS end. TCSM ports consist ofTCSM Index (1 of the 16 Ater ports), STM and Tributary number (ET Timeslot and STMnumber 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 theirrespective domain’s port allocations and WO generation. Along with this sheet, anothersheet containing a graphical view of TCSM allocations is also attached for theconvenience 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 givenbelow: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 givenin 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 toall stakeholders with providing the ID number of the WO issued on Service Manager bythem. 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_BSC12xAter(s) on TCSM 2

TCSM 2e Allocations.x ls

IAB004_BSC15xAter(s) on TCSM3i



TCSM 3i Standalone Allocations.xls

IAB004_BSC214xAter(s) On TCSM

IAB751_BSC1(CombiBSC) 5xAter(s) on TC

TCSM3i Combi Allocations.xls

11

ABIS/ TRX DIMENSIONING AND EXPANSION

Before discussing the expansion procedure, we need to know the channel typesand their bandwidth requirements. Only by knowing their bandwidth requirement wecan assign the resources on Abis interface.

11.1

Channel Types

Abis dimensioning results in a specific output that is used as input in the nextdimensioning phase, BSC EDGE dimensioning. In an EDGE transport network, thefollowing 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 arelisted 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 toend.

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 1800ID 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 arequirement 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 numbersetc.

BSC_Detail_City_Wise_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 1800second sector, so the template below will be used while applying the dimensioning rulethat 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 timeslots is as under:

Total Time slots (TS) = 32Signaling = 1 TSSynchronization = 1 TSEDGE/GPRS = 9 TS (minimum)

On the basis of above distribution, we know that this sites configuration can’t beaccommodated 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 20TRX maximum 9 TRXs can be accommodated on E1 present in 900 along with 6 EDGETS and rest of the 11 TRX can be accommodated on E1 present in 1800 along with 3GPRS time slots.

Abis TRX SampleTemplate.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 don’t 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 FOTXN PlanningBSS planningRF Planning

Analyze request from

RF

Media Required

End

Media WO request

sent to TXN team

Abis Plans received

Get Latestconfiguration of sites

from NMS Dumps/NetAct

Perform Expansions

Start

Media WO Issued

WO Request for

Expansions

Complex Expansion?

Yes

Yes

WO execution, closureand 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 licenseand 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 certainfeatures and licensing every feature means that vendors sell each feature of a productseparately.

12.2

Licensing BSS Products

As discussed above, in order to utilize various features of a product, licenses arerequired to be installed on that equipment/product. There are many types of licensesthat are used to operate the hardware installed in Telenor Pakistan’s Network; howeverwe 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, andSoft Channel Capacity Licenses in Nokia BSS. One hardware TRX license is required perTRX. 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 in222/202 configuration, it has 3 sectors, so three EDGE TRX licenses are required for thissite. 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 ofsectors being added. We calculate them, add some cushion and order these many EDGETRX Licenses and request to install them on the BSC. We try that this activity shouldnot be done more than once in a year.

The 3rd 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 workon a particular BSC. Whenever soft channel capacity is exceeded, we request additionalsoft 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 withthe packet switched traffic of the Nokia based network. A license is required to operatethe PCUs with all their basic features. So we install as many licenses in the BSCs as thetotal number of logical PCUs in that BSC.



12.2.2

Siemens

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

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

It is important to note here that it is also possible to uninstall a license from aBSC and install it on another BSC of the same type to enable the similar functionality asthat of the earlier one. In order to install any of these licenses, we contact NSN SSMteam 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 itsfeatures functional.

13

LAPD PLANNING

13.1

Introduction

LAPD, link access protocol on the D-channel, is required for carrying themanagement commands between BSC and BTS. There is one TRX LAPD signalingchannel 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 channelcan be defined as a 16/32 or a 64kpbs signaling channel. The link size (capacity) ofLAPD channel should be enough to keep the paging load in the required physical limitsor in other words the paging load of any location area should not exceed the capacity ofa LAPD channel of a BTS. Along with the paging load, a LAC should be able to provideenough capacity to carry the O&M and signaling traffic for a BTS site.

In the following sections we will be discussing the LAPD capacity dimensioningaspects 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 sectionof ABIS/ TRX DIMENSIONING AND EXPANSION. The criteria of LAPD planning shallremain the same but in cases where we face congestion on LAPD interface, thefollowing factors should be taken into account when estimating the capacity of the AbisLAPD signaling and especially when having the 16 kbit/s (low capacity) link signalinglink:



There can be a maximum of 2 signaling messages unacknowledged at any time, allthe subsequent messages must wait for the acknowledgement of at least one of thesemessages; all the messages are stored in signaling processor buffer until respondedto by the opposite end. The LAPD window size 2 is recommended by the GSMstandard 08.56.

The acknowledgement delay varies from a few milliseconds to tens of millisecondsbecause of the characteristics of the LAPD protocol, especially if there is a lot ofsignaling traffic coming in from the opposite direction (measurement reports and soon). 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 thecapacity.

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, theBCCH 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 pagingmessage count/sec/link is thus 0.6 x 1000/21 = 29, which roughly equals 100 000pages per hour (16 kbit/s), which is sufficient, for example, for the nominal BSC callmodel. For a 64 kbit/s link, the same general principles apply. The maximumrecommended average signaling traffic is 4000 bytes/sec and the paging messagecount as calculated above is maximum 60/sec/link, which equals to 410 000 pagesper 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/sLAPD) per Abis link.

13.3

LAPD Dimensioning in Siemens BSCs

In Siemens BSS, we will be discussing the LAPD dimensioning limits for bothtypes of BSCs in separate section.

13.3.1

cBSS LAPD Capacity:

In cBSC, the card for handling the signaling traffic (CSS7 and LAPD) is calledPPXL. 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 timeslots at 64 Kbit/sec are reserved for the CCSS#7 and 240 time slots (for example 67 at 64Kbit/sec and 173 at 16 Kbit/sec: 67X64kpbs+173X16kpbs=240 TS at 64Kbps) for LAPDfor handling the signaling towards the BTSs and the TRAUs.

The LAPD capacity of the PPXL board (240 channels) is defined by thebandwidth 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 errorprotection, and up to 16 SS7 links at 64 Kbit/s can be configured. In terms of 64 Kbit/schannels (LAPD + SS7), the PPXL offers a total capacity of 127 channels. As aconsequence 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 tothe geometric configuration of the Abis Interface; for example, the configuration ofadditional LAPD channels for measurement purposes can only be reached reducing thecapacity of the site in terms of supported traffic.

These limitations have been overcome reducing the capacity of the LAPDchannels configured for the control of the connected TRAUs, from the current 64 kbit/sto 16 kbit/s by implementing a new parameter associated to the LAPDLS ManagedObject.

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 isavailable. When a fault occurs to a LIET, the spare takes over the relative lines, servingthe traffic without service interruption until the problem is solved and a switch-back isconsequently performed.

In case of optical connectivity, blade module STM-1/OC3 provides 2 optical linksto/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 (channelizedmode) or 2 x 155 MB/s (unchannelized mode).Moreover LM-STM1/OC3 modulemanages up to 1024 LAPD links.

The figure below contains the summary of LAPD, SS7 etc capacities for differenttypes 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 BSC3i1000

BSC3i2000

Maximum number of LapD links perBCSU

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 AreaCode 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 havetwo types of communication with MS:



BSS SignalingThis 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 acall. This is done by defining the location area within the vicinity of a MSCboundary. By defining a location area, MSC only searches the user in MS’s locationareas 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 hasthe following features:

Location area information of a MS is sent not only periodically in uplink to thenetwork but also whenever the MS changes the location area.

A mobile station that changes the serving cell in the same location area does notneed 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 thesignaling load. Every BTS broadcasts the location via the parameter Location AreaIdentity. Even when the MS is involved in the active call, the location area still iscommunicated 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. Nowwe will describe how the planning of LAC is done.

Whenever a LAC is made, it is ensured that the parameter PPS (paging persecond) does not breach the set threshold (explained below). This is basically thenumber of pages a BTS transmits in a second. A paging message is sent wheneversomeone tries to make a call. The paging message is generated in the location area of thecall 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 doesnot breach a threshold. Below we give the threshold values for PPS in Siemens as wellas 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 activitywill 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 todetermine 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 expectedPPS is within the 65% limit of the maximum PPS of the BSC, then this BSC will haveonly 1 LAC. If, however, the PPS is greater than the 65%, we need to define more than 1LAC. We need to define as many LACs as required until the PPS is around 65% in eachof the LACs defined in this BSC.

The creation of new LAC will reduce the PPS in existing LACs. The mostimportant 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 willcause more loading on the BSC processor and we do not want that. At the same time, ahigh number of LUs will put more loads on SDCCH resources in a BTS as well. So theboundaries between the LACs are made in such a way that there is very minimalpossibility that a user will move from one LAC to another. This is ensured by giving theLACs the same boundaries as those of the BSCs that are being offloaded by this newBSC because the BSC boundaries are already made in such a way that there is minimalpossibility 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 isrequired in the new BSC or not. If required, we make as many LACs as possible so thatthe 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 allthis working is done, the proposed LAC boundaries are sent to corresponding RF teamfor their consent. The RF team will analyze the boundaries and will try to fine tune it ina way that will reduce the LUs between LAC boundaries even more. RF team will sendthe proposed changes back to BSS Planning for our consent. BSS planning will again seeif 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 Planninguntil both teams agree on common boundaries. Once done, these LACs will be definedin 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 hardwareconfigurations. For example, both type of Siemens BSCs (cBSC and eBSC) can handle1 paging message each 10ms per LAC which gives a value of 360000 page/hour perLAC.

The second aspect is the pages which can be handled by LAC, Number of pageswhich can be handled by LAC depend upon the LAPD size, bigger the LAPD morepages 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 LACsdefined in it (number of LACs can be one or more than one). BSS team will constantlykeep 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 splitplan has to be prepared and made ready and implemented before the PPS breaches the80% threshold.

Assume that a BSC currently has three LACs. PPS of one LAC is rising and hasreached to 75%. PPS of the other two LACs, however, are only at 55%. In this case wewill shift some sites of the first LAC to the other two LACs. This will help in reducingthe PPS of first LAC, by increasing the PPS of other two LACs. Suppose the PPS of firstLAC comes down to 65%, this would mean that the PPS of the other 2 LACs might goupto 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 boundaryof the other 2 LACs, the sites can be shifted to only one LAC whose boundary touchesthe first LAC. This way the PPS of the first LAC can be reduced down to somewherearound 68% and the adjoining LAC’s 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 tothe 3rd LAC. This will increase the PPS of 3rd LAC above 55% and reduce the PPS ofLAC 2 below 55%. Now there is more room in this adjoining LAC to take more sitesfrom first LAC. The drawback in this case, however, is that two boundary adjustmentswill be required: one between first and second LAC and one between second and thirdLAC, 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 boundaryreadjustments and should be done only if the PPS of a LAC is rising very sharply and isexpected 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 weneed LAC split activity. LAC split is required only if PPS of a LAC is about to crossthreshold 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 tobreach 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 bebreached / almost breached.

In such scenarios, we will divide the problematic LAC into two. We always try toensure that the newly created LACs out of the one problematic LAC are as balanced aspossible. Ideally, for example, if the problematic LAC’s 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 totallimit. 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 presenthere in the past that cuts through the area covered by the problematic LAC. Thatboundary of the old BSC can be used as a guide to make the boundary. One can alsolook if there was a LAC earlier at this location of problematic LAC. If there was one, theboundary of that old LAC can also be used as a reference to cut the problematic LACinto 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 tomake a new boundary that does not cut any major road and cuts the least number ofsmall 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. Theywill analyze the boundary in terms of the expected Location Updates. If the expectedLUs are high for their liking, they will propose changes in the boundary proposed by usand send it back for our review. BSS Planning will see whether they have shuffledenough sites that will render the new two LACs unbalanced. If it appears that the newLACs will be nearly balanced we accept the changes proposed by RF team and requestField Operations to proceed with the LAC split activity. If the changes proposed by RFteam 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 BSSPlanning 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. Thefollowing 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 Statsmonitoring tool ) & Reporting suite (Nokia Stats monitoring tool) for the extraction ofpaging & 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 designedto locate, within a location area, a mobile station to which a terminated call is to bedirected. 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 (100paging/sec), and we can create up to 20 LAC’s in both CBSC & EBSC’s.

In Nokia, the maximum capacity is 200.000 paging/hours/LAC (55.5 paging/sec),and we can create upto 4 LAC’s in both BSC 3i-2000 & upto 2 LAC’s 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 CStraffic

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 PStraffic



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

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 anadditional paging command cannot be stored to the buffer. In that case the pagingcommand 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 originatesfrom Paging. The amount of paging in a LA is dependent on how many cells thatbelong 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 theconfiguration 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 PPCHcontinuously, the mobiles are divided into paging groups. The mobile will only monitorthe 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 SystemInformation, 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. Theoperator 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 betweentransmissions 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 paginggroup). The BTS distributes the Paging Commands as Paging Request messages on theradio path when paging blocks are available. A too high rate of incoming PagingCommands to the BTS increases the queuing time that leads to an increase of theaverage time for the paging response. When the queue is full, the incoming pages arerejected. 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 willbe discarded and not sent. If a page is queued for a too long time in the BTS, the pagemay also be lost due to the fact that the MSC does not receive the paging responsebefore the timer PAGTIMER has expired. The risk of excessive delay in the BTSincreases if the time between the transmission of each paging group, set by theparameter 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 ImmediateAssignment 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 signalingMultiframe (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 isspecified, 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 therecommended 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 interfacecapacity 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 longerMS battery lifetime, because the MS has to listen quite seldom to a CCCH channel in aserving cell. In this case you must also ensure from the estimated call mix or from livenetwork statistics and measurement values that you operate in the nominal BSC loadarea and that the Abis paging load does not exceed the limits of LAPD (16 kbit/s or 64kbit/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 beingsent to all cells in the BSS A/Abis interfaces. Paging must, in any case, be performed onan 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 pagingmessage is sent several times. The repetition procedure is defined in the MSC. TheseMSC parameters are Re-paging_Interval (time between paging attempts) andNumber_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 firstpaging goes with TMSI, and then after 3.5 seconds with IMSI, if the subscriber does notrespond to TMSI.

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

Note also that some maximum configurations would not be possible because ofother limiting factors such as the 16 kbit/s Abis or radio interface, which would start tolimit 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, youcan choose to live with a high paging blocking rate in this cell because the Probability ofMS location in this cell is very low. Therefore, the Paging blocking rate as seen from theMSC 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 MSCrepeats the Paging messages, the end user blocking rate can be considerably reduced ifthe 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 REQUESTmessage (PAGREQ) which itself can contain the mobile identities (IMSI or TMSI) of upto 3 mobile subscribers simultaneously. This means that the PAGING REQUESTmessage 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 thediscarded PAGING REQUEST contains e.g. 3 TMSIs, then NTDMPCH (3.) is increasedby 3.

The BSC starts T17 and discards all new PAGING COMMANDS to the BTS only ifBTS 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 isfull and the BSC has a counter, DELETE PAGING COMMAND, which steps for everydiscarded 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 twoor 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 toreach 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 CPload in the BSC due to more LA updates.

To avoid unnecessary reconfigurations it is suggested to use 0.1% as an acceptablerate of discarded pages. Since discarded first pages will be retransmitted the probabilitythat 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 cellswith few Establishment cause Answer to paging in Channel Request message. Oneexample 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 Updateload in the LA border cells sets the minimum size. The most important rule is not toexceed 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 isno reason to have smaller LAs than necessary. One LA per BSC area is often a good ruleof thumb. If an LA is relatively large, and the paging load is high, one should considersplitting the LA into two or more LAs. This will reduce the paging load in the BTSs aswell 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 arerelatively small, and it is difficult to find suitable LA borders, one LA can cover severalBSC areas.

Regardless of the type of area, rural or urban, it is recommended to have the LAborder cells in low subscriber density area. LA borders crossing over high mobilityareas, e.g. high ways, should be avoided. The most important recommendation is tocarefully monitor the performance of the system.

16

GPRS PLANNING

GPRS gives customers the benefits of instant IP connectivity on-the-move and ofbeing continuously connected. GPRS provides the possibility of being charged only fortransferred 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 isthat it can use the same resources that circuit-switched connections do by sharing theoverhead capacity. This means that one mobile uses the resources only for a shortperiod of time, that is, when there is data to be sent or received. The sharing ofresources 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 inconventional 2G networks.

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

EDGE uses 200 kHz radio channels, which are the same as the current GSM channelwidths. From a technical perspective, EDGE BSS allows the GSM and GPRS corenetwork 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 modulationschemes, which can be alternated on the same radio slot according to radio channelconditions. With new modulation, EDGE increases the radio interface data throughputthreefold on an average compared to GPRS.

EDGE Modulation and Coding Schemes MCS1–MCS9 provide optimalperformance in all radio conditions. In good radio conditions MCS9 provides up to 59.2Kbit/s throughputs. In four timeslot multislot allocation 236.8 Kbit/s throughput can beachieved.

16.1

GPRS/EGPRS Planning in Nokia BSS

With Nokia Dynamic Abis functionality Abis resources for packet data arereserved dynamically depending on the needed user throughput.

16.1.1

Abis EDGE dimensioning

These guidelines provide information on dimensioning the Abis interface forEDGE into an existing GSM network. The focus is on calculating the neededtransmission capacity in the Abis interface for the successful operation of the EDGEnetwork.

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

In GSM/GPRS networks, each timeslot in the radio interface has a correspondingtimeslot 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 neededin EDGE networks to carry this additional traffic. This is handled by the EGPRSdynamic 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 physicalcapacity of the PCM. The throughput of a radio timeslot depends on the used codingscheme.

16.1.2

Dynamic ABIS

As discussed, EDGE networks are capable of delivering higher data rates thanGPRS. For this reason, the concept of dynamic Abis has been introduced in NokiaEDGE networks. In EDGE, some traffic timeslots are statically allocated as inGSM/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 shareavailable resources from the EDAP during peak traffic. Dynamic Abis are mandatoryfor EDGE and CS-3/CS-4.

In Dynamic Abis, each timeslot in the radio interface has one correspondingfixed sub-timeslot in the Abis PCM frame. These statically allocated channels are calledmaster channels. When the data rates go beyond 16 Kbps (when the coding scheme is inthe range from MCS2 to MCS9 and CS-3 and CS-4), extra traffic channels are required tocarry 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. Thisis caused by the BTS-BSC in band signaling on the Abis interface. The in band signalingincreases and the size of the radio link control (RLC) block increases from 268 bits to 368bits (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 withthe data rates of different coding schemes and the required amount of 16 Kbit/stimeslots 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.



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 CS–3 & CS–4, 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 3urban sites and 1 rural site are attached to a PCU. The most important factors toconsider while dimensioning the PCUs for BSS planning is the maximum number ofEDAP pools (max for 16 per PCU) and maximum number of 64kpbs Abis time slots (64per 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. Thereforebefore assigning any GPRS/EGPRS timeslots to any PCU, we first check the PCUloading in terms of EDAP pool/ (E)GPRS timeslots. This is usually checked by usingthe BSC dump files. BSC dump files contain all the configuration information of a BSCincluding 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 PCUneeds to installed and created with each BCSU regardless of its requirement, thisproblem has been solved in the new BSC software RG10 in which PCU can be usedasymmetrically.

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 providesdynamic capacity on the EDAP pool defined whereas in Siemens complete ABIS pool isdynamic, irrespective of data/voice traffic. This means that in Siemens, the dataservices can occupy any time slot(s) of ABIS pool and no time slot (s) is reserved for anyspecific traffic type. Therefore it becomes easier to allocate ABIS resources in Siemenscase for data traffic. Following is a small example which will make you understandmore.

For instance, we have a site planned with a configuration of 4/4/4. In order toallocate 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 76timslots, we still have 48 timeslots remaining to be allocated. Out of these 48, 4 will berequired for TRX signaling (LAPD) which make a total of 44 remaining timeslots. Asper the standards, a user using EDGE capable handset can get a data rate of 384kbps atUm interface at maximum. Therefore for providing the required bandwidth for this

much throughput, we have to assign the equivalent bandwidth on Abis interface. 384kbps is equivalent to 24 * 16 kbps hence 24 timeslots (each of 16kbps) is usually requiredat Abis interface for facilitating EDGE maximum throughput.

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

Now we will discuss the flexibility of Siemens Abis interface. In Nokia’s case, 24timeslots (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, inSiemens the Abis timeslots are not dedicated therefore upon need, EDGE traffic canoccupy 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 andin those cases we can live with even defining less than 24 timeslots on Abis for GPRS aswell. Please remember that while defining the timeslots, we don’t associate them withany certain type of traffic so the timeslots definition is irrespective of data type. It isonly 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 GPRSchannels.

Figure 18 Siemens BSCs GPRS Capacities

In case of eBSC, UPM boards are responsible for handling the packet datachannels. 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 trafficchannels. 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 thenumber 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, itis possible to let the load balancing of PCU resources to be done by BSC. Althoughfunction of assigning a site to certain PCU is still available in Siemens, most of the timewe let the BSC do the load distribution tasks. This makes the dimensioning job easier inSiemens case.



Since we are not concerned about dimensioning of a single PCU, we consider allavailable PCUs a single resource pool. For example, if we have a cBSC with 12 PPXUboards, it means that we have a pool of 11+1(load sharing) PCUs available. At anyinstant, 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 thetotal number of required PDT resources per BSC rather than per PCU. The easiest wayis 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 severalBSSs to an SGSN, facilitating the transfer of GPRS signaling and user data between theSGSN and BSC, and the logical radio interface between the SGSN and the MS. The Gbinterface allows signals from many users to be multiplexed over the same physicalresource.

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

http://127.0.0.1:43231/NED/NED?action=retrieve&library=sgsn_rel_sg6_cd4_v1_2007_09_25&identifier=general_glossary&edition=11&language=en&coverage=global&encoding=xhtml_1_0&component=data&item=data&pointer=id08972#id08972












Figure 20 GB Interface

16.3.2

Gb Link DimensioningEach 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 isthe average size of the Gb link to carry the data traffic forecast. This part of the processaffects SGSN dimensioning and should be conducted together with PS Core planning.

The Gb should be capable of supporting the instantaneous data traffic beingcarried by all cells connected to a particular PCU. If there is insufficient capacity theeffective 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 tohandle the short term peak traffic of any single EDAP or cell data requirement. Inaddition to this the target is to estimate that the GB link is large enough to supportsimultaneous traffic of several EDAPs or PDTs. This is highly dependent on the trafficdistribution. The equation below is used to calculate the average GB link size (= FrameRelay Bearer Channel capacity).

areanetworkfor thatsizeEDAPAverage*ksizeGbAverage

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 thedefault values. The table below gives the k values.

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



The theoretical maximum k-value is the number of EDAPs allocated into onePCU. This assumes that all the EDAPs are heavily loaded at the same short term periodand 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 shallbe used. To show more cost effective results unequal distribution may be considered.

k-factor

Short term traffic distribution

Unequal (low likelihoodof heavy simultaneous

short term traffic)

Default Equal (high likelihood ofheavy 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 moreaccurate values for individual Gb links are calculated taking into account the usage ofindividual 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 TSLThe 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



SGSNSGSN

PCU

Abis Gb

BTSBTS

A-bis PoolBlocking

Siemens

EDAP PoolBlocking Nokia

BSC

PDT Rejections

TerritoryUpgrade

RejectionsNokia

GbThroughput &

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 thatrequire 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 anumber of EDGE-capable transceivers (TRX) in the same BCF cabinet. The DAP and theTRXs 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 NED’s Dynamic AbisPool 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 EDAPresources are inadequate because of the size of EDAP. Any value greater than 0min/GB needs to be evaluated case by case for EDAP expansion

Formula:

Sum(DL_Indadeq_Time_minutes)/Sum(DL GPRS payload_Gbyte+DL EGPRSpayload_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 16kbit/s PCM sub TSLs in the downlink direction. 100% Peak DL EDAP usage causinggreater than 0 min/GB of inadequate EDAP pool usage and as a result TBF rejectionsshall trigger Edap expansions.

Counter c76005 & table name PEAK_UL_EDAP_USAGE gives Peak usage of 16kbit/s PCM sub TSLs in the uplink direction. 100% Peak UL EDAP usage causinggreater than 0 min/GB of inadequate EDAP pool usage and as a result TBF rejectionsshall trigger Edap expansions.

17.1.1.3

EDAP Expansion:

When EDGE is enabled on a site minimum 6 EDAP TS are defined whenexpansion is required TS are increased in steps of three to 9TS,12 TS & 24 TS dependingupon 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 packetswitched services and to circuit switched services in Siemens. According to the service,the appropriate number of Abis resources is dynamically allocated during the radiochannel 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 bemodified at run time, according to Link Adaptation feature.

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

As there are no fixed data timeslots in Siemens architecture; Abis pool is sharedbetween circuits switched & packet switched traffic.

17.1.2.1

CountersAbis 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

17.1.2.2


The counters are formed into following main KPI(s) for Abis analysis with averageof 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 unsuccessfulAbis 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 / Meannumber 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 betaken 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 amongBCSUs. Equal sharing of the BTSs is efficient from PCU utilization & O&M point ofview because no BTS switchovers from one PCU to another are needed when thenetwork 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 NetactND reports1. 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 resourcecongestion are as follows:

GPRS TER UPGRD REQ(NE Counter name): GPRS_TER_UPGRD_REQ (Tablecounter name)

o Number of territory upgrades requests received from the Packet ControllerUnit.

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 alreadytotally 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_REQo Number of territory downgrade requests received from the

GPRS_TER_UG_DUE_DEC_CSW_TRo 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 thecircuit switched traffic load.

17.2.1.2

Key Performance Indicators

Few of the above mentioned counters help in analyzing the congestion at PCUend. 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 LACKPCU 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 furtheranalysis.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 withhigh number of territory upgrade rejections is calculated through followingprocedure: 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; & hencerejection 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 thenPCU expansion is required. Max attainable PCU count in case of BSC 3i-660 can go upto24 & 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 inconsideration load balancing concepts, for example a Load balancing algorithm isapplied separately for each configured pool. A cell as well as a PPXU board can bemoved from one Pool to another Pool by means of a “Set” command. This command ispreceded by the “Lock” command related to the Managed Object affected by the PCUpool change.



The number of the supported PDTCHs is up to 3072 in cBSC out of which only2816 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 forGb 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. Countersfor 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



17.2.2.2


Totally utilized PDT count is a KPI calculated from counters in scanner SCANBSCadding 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 RTSLhandling capacity. The total PCU capacity attainable is 12 PPXU cards in cBSCs & 10UPM cards in eBSCs

The figures below illustrate few such examples where PDT rejections are beingfaced 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 thecongestion 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 kBo (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_nsvc_cir_oflo+nsvcdata.shared_cap_to_anoth_fr_nsvc),0,0,(nsvcdata.disc_data_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 priority 2 passed data, kB}

o (nsvcdata.nsvc_passed_data_bytes_pr2)/1024

Disc ratio {NS-VC DL priority 2 data discard ratio, %}o 100*decode( (nsvcdata.nsvc_passed_data_bytes_pr2 +

nsvcdata.nsvc_disc_data_bytes_pr2),0,0,(nsvcdata.nsvc_disc_data_bytes_pr2) /(nsvcdata.nsvc_passed_data_bytes_pr2 +nsvcdata.nsvc_disc_data_bytes_pr2))

Passed {NS-VC DL priority 3 passed data, kB}

o

(nsvcdata.nsvc_passed_data_bytes_pr3)/1024 Disc ratio {NS-VC DL priority 3 data discard ratio, %}

o 100*decode( (nsvcdata.nsvc_passed_data_bytes_pr3 +nsvcdata.nsvc_disc_data_bytes_pr3),0,0,(nsvcdata.nsvc_disc_data_bytes_pr3) /(nsvcdata.nsvc_passed_data_bytes_pr3 +nsvcdata.nsvc_disc_data_bytes_pr3))

Passed {NS-VC DL priority 4 passed data, kB}o (nsvcdata.nsvc_passed_data_bytes_pr4)/1024

Disc ratio {NS-VC DL priority 4 data discard ratio, %}

o

100*decode( (nsvcdata.nsvc_passed_data_bytes_pr4 +nsvcdata.nsvc_disc_data_bytes_pr4),0,0,(nsvcdata.nsvc_disc_data_bytes_pr4) /(nsvcdata.nsvc_passed_data_bytes_pr4 +nsvcdata.nsvc_disc_data_bytes_pr4))

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

Documents

Transcript of BSSP&O Guidebook