NOKIA SIEMENS NETWORKS

CS&I – RDC

Integrated BSS Database Process

Handbook

Process Definition
For
BSS Database Network Design
And04
CMM
Implementation
 SUMMARY

1. INTRODUCTION....................................................................................................... 2

Service Description ................................................................................................................. 2

Database Planning .................................................................................................................. 2

2. SERVICE PHASES................................................................................................... 2

Assessment ............................................................................................................................. 2

Information Analysis ............................................................................................................... 2

Database/Script Creation........................................................................................................ 2

Implementation Support ......................................................................................................... 2

Quality Assurance Revision ................................................................................................... 3

Change Request ...................................................................................................................... 3

3. DELIVERABLES....................................................................................................... 3

Database Planning .................................................................................................................. 3

4. EQUIPMENT SCOPE ............................................................................................... 3

5. SERVICES AND TIMES ........................................................................................... 4

6. DATABASE OVERVIEW .......................................................................................... 5

How Changes are improved in the DATABASE .................................................................... 6

Tools used for DATABASE design ........................................................................................ 7

7. INPUTS REQUIRED FOR DATABASE DESIGN .................................................... 9

8. OPERATION MODE OF CSI-RDC ........................................................................... 9

9. PROCESS TO DELIVERY SCRIPTS AND DATABASE....................................... 10

10. TERMS AND CONDITIONS ................................................................................. 12

11. ANNEXES ............................................................................................................. 12

1
1. INTRODUCTION

Service Description
2G BSS Database planning occurs after Sales Dimensioning, Hardware Planning and BSS 2G Fixed
Networks Planning to set up deliverables that will be used by Field Personnel to Installation and
Commissioning of equipments of BSS 2G Systems. It consists of the design and processing the results
of the preceding step.
The different phases are the ASC/DBA Database and ACL/CLI scripts delivery with focus of the overall
network functionality and hardware planning of each single network element.
In these phases, all the detailed RF and FNP plans and documents are required for the correct
database design and planning, in order to facilitate the implementation, integration and commissioning
of each activity.
This handbook defines the 2G BSS Database Network Design and implementation for ex-Siemens
equipments.
The purpose of this document is to:
· Introduce the 2G BSS database, describing the main characteristics and features;
· Describe the process steps to delivery database and scripts in all process levels;
· Present the terms and conditions to delivery scripts and databases;

This will cover all BSS 2G Network elements, composed by BSC, BTS(s) and TRAU(s).

Database Planning
The main purpose of Database Planning is:
- Build scripts that allow the configurations of several elements of BSS 2G network elements
and its relationship;
- Build scripts to implement, modify or expand customer dialing plan (creation/deletion of sites,
creation/deletion of TRX, site re-homes, creation of BSC(s), data connections to the SGSN,
etc);
- Build scripts to activate, expand or customize software features
- Scripts follows semantics, syntaxes’ and command set dependent of each type of Network
Element;
- Database auditions and verification;
- Support to the O&M and field implementation team;
- Support to the FNP and RF team;

2. SERVICE PHASES

Assessment
The assessment phase evaluate the requirements of customer’s strategy or analyzing already existing
networks for capability of the new demands coming ahead with the rollout of a new project or an
expansion project. These requirements are collected from the RF and FNP teams (internally or from
the customer), describing the scope of the activities. Standard questionnaires called CR (Change
Requests) and the Overview of the Fixed Network Planning are the outputs required for these areas.

Information Analysis
This phase analyzes received documentation of customer and data collected from Assessment Phase
to prepare the Data build Design.

Database/Script Creation
In this phase all scripts to elements configuration are created. Generally these scripts are created
using an internal tool called 2G Database Generator.

Implementation Support
After deployment of deliverables to customer or field commissioning team, there is a time to be
considered to make adjustments to the deliverables or assisting implementation of that deliverables.

2
Quality Assurance Revision
In this phase information received back from customer or field commissioning personnel, corrections
and adjustments applied on the deliverables have to taken into consideration, analyzed and used to
increase quality to future projects.
Figure 1 is showing the whole process to delivery the database and scripts.

Change Request
Change requests result in modification of deliverable items, due to modifications in the input data,
conditions, variables, functionalities, formats, documentation, or any other requirements which impact
the original deliverable. These changes can occur either during the execution of a service or after its
completion, when the supplier has already delivered the service results.
The efforts required for change requests may vary. For the time and cost calculation of change
requests, they will be classified in three levels of impact:
a. Low Impact: a change requiring an effort up to 20% of the effort to produce the original
deliverable;
b. Medium Impact: a change requiring an effort greater than 20% and up to 50% of the effort to
produce the original deliverable; and,
c. High Impact: a change requiring an effort greater than 50% and up to 70% of the effort to
produce the original deliverable.
If a change request requires an effort greater than 70% of the effort to produce the original deliverable,
then the full effort of producing a new deliverable must be considered.

3. DELIVERABLES

Each area of activity has its own deliverables that should be deployed at customer Network

Database Planning
Set of scripts in plain text with specific commands to each BSS 2G Equipment (BSC, BTS and TRAU).
Description Documentation explaining the premises, assumptions and decisions taken can be placed
inside each script or in separate Microsoft Word Document. Microsoft Excel sheets showing
relationship among elements can be used to facilitate customer or field personnel understanding.

4. EQUIPMENT SCOPE

2G BSS Network elements are shown below:

- BTS BS82-II
- BTS BS40-II
- BTS BS240 XS
- BTS BS288
- BTS BS240 II
- BTS BS241 II / BTS BS241 DC
- BTS BS240 XL II
- BSC High Capacity 72
- BSC High Capacity First Step 120
- TRAU

3
5. SERVICES AND TIMES

ITEM # Service Description Execution Time (Working Days)

10001 Databases for creation of new BSC(s) 0,60 MWD per BSC
10002 Scripts for creation/deletion of new sites (BTS) 0,20 MWD per site
Scripts for creation/deletion of new Sectors of existing sites
10003 0,20 MWD per site
(BTS)
10004 Scripts for creation/deletion of new TRX(s) 0,30 MWD up to 40
10005 Scripts for changes in parameters 1,00 MWD
10006 Scripts for changes in parameters (low impact in the network) 0,05 MWD up to 50 changes
Scripts for changes in parameters (medium impact in the
10007 0,07 MWD up to 50 changes
network)
10008 Scripts for changes in parameters (high impact in the network) 0,09 MWD up to 50 changes
10009 Scripts for creation/deletion of TRAU/SS7 Links; 0,20 MWD up to 5
10010 Scripts for re-home of sites (BTS) 0,70 MWD up to 10
10011 Scripts for site cut-over (BTS) 0,20 MWD per site
10012 Scripts for BSC Scanners adjustments 0,10 MWD
Scripts for activation of new features (low impact in the
10013 0,50 MWD up to 100 sites
network)
Scripts for activation of new features (medium impact in the
10014 1,00 MWD up to 100 sites
network)
Scripts for activation of new features (high impact in the
10015 1,50 MWD up to 100
network)
Scripts for creation/deletion/changes of BSS Data elements
10016 0,40 MWD per BSC
(Frame Relay links, PCUs, etc)
10017 Scripts/New Databases for Network new Frequency Plan 1,00 MWD up to 2 BSC
10018 Database reports in Excel format 0,20 MWD
10019 Support and revision of the tools 0,40 MWD
10020 Support for O&M, field implementation and RF teams 0,10 MWD
10021 Database auditions 1,00 MWD
10022 Change Request on deliverables – low impact 0,15 15% of the original time

10023 Change Request on deliverables – medium impact 0,35 35% of the original time

10024 Change Request on deliverables – high impact 0,60 60% of the original time
Table 1 – Execution Time for the deliveries

4
6. DATABASE OVERVIEW

The database for 2G BSS ex-Siemens equipments is a binary file with .DBA extension, which can be
converted by an ASC file that can be viewed by every text editor.
The database contains the following network elements (NEs):
· BSC
· TRAU(s)
· BTS(s)
· PCU (for data connections).
Each database file corresponds to one single BSC, with their entire configuration and NEs connected
to this particular BSC. The database is formed by objects which are described in the figure 1.1.

Figure 2.1 – BR8.0 Object Tree of BSC database objects

5
The figure 2.2 is showing the ASC database file as an example.

Figure 2.2 – BR8.0 ASC database example

How Changes are improved in the DATABASE

A database can be changed according to the necessity. Basically there are two ways to modify one
database:
1. Applying scripts (indicated for most of the cases);
In this case changes are improved in the database by applying scripts (or in .CLI or .ACL
extension). A script is a sequence of texts which can be read and translated by the O&M or
LMT systems and refers to one specific change in the database. E.g.: Script to expand one
TRX.

Figure 2.3 – BR8.0 CLI script example

6
 2. Applying a new database
In this case a new database is uploaded into the BSS system, with the changes required. This
option is only indicated when the changes in the database are so big and takes much time to
run via scripts.

Tools used for DATABASE design

The official tool developed for database design and implementation is called Caddie. This tool is also
available as a module of another tool called OTS (O&M Toolset). It’s software based on client-server
architecture.

.
Figure 2.4 – Caddie Tool

In order to get flexibility and performance’s evaluation of database and scripts delivery, the CSI RDC
Brazil has developed another tool called DB Generator, which is able to generate scripts faster than
Caddie and has the advantage to not use any server connection. It can be used in stand alone mode.

7
 Figure 2.5 – DB Generator Tool

Usefull links:

DBGenerator User Manual

\\192.168.200.10\Projects\RDC_Brazil\2G_BSS_Database\Help\DBGen_help\DBGen_help.htm

DBGenerator short presentation

\\192.168.200.10\Projects\RDC_Brazil\2G_BSS_Database\Help\DataBase Generator.ppt

DBGenerator Tool
\\192.168.200.10\Projects\RDC_Brazil\2G_BSS_Database\Tools\DBGenerator_Tool.zip

8
7. INPUTS REQUIRED FOR DATABASE DESIGN

The following inputs are required for database design:

· Daily database upload in ASC format.

· Daily symbolic name file in TXT format.
· RF Change Request according to the activities required.
· Overview of the planned network
· Detailed forecast of the activities
· Contacts of the professional(s) in the O&M system.

Examples of these inputs can be viewed in the annex of this document.

8. OPERATION MODE OF CSI-RDC

The picture 4.1 shows the operation mode structure of the CSI-RDC.

C&I PM Team
PMO
Latin Am erica
Enabler Centre
Project Project Project
Manager
Manager Manager Manager

Technical
Manager
SPOC Project
Netw ork Designers Team
Local Leader
Delivery
Team
Customer
SPOC Project
Netw ork Designers Team
Local Leader
Delivery
Team

SPOC Project
Network Designers Team
Local Leader
Customer
Delivery
Team

SPOC Project
Netw ork Designers Team
Customer Local Leader
Delivery
Team

SPOC Project
Customer Network Designers Team
Local Leader
Delivery
Customers Local Delivery Team s Team
Latin America Latin Am erica Rio Enabler Centre

Figure 4.1 CSI-RDC – Operation Mode Structure

9
9. PROCESS TO DELIVERY SCRIPTS AND DATABASE

The procedure that NSN applies to implement database changes in one network is briefly represented
in the picture 5.1. The process, in addition to the database planner, it comprises the radio planning
area, transmission planning area, fixed network planning area, implementation area and the project
manager.

The process begins with the project manager (PM). The PM is responsible to provide the scope of
work (SoW) and the detailed forecast for each activity. The Radio planning area is responsible to
provide all the RF information according to the inputs requested by the database area. This input is
called “Change Request”.

The Fixed network planning, together with transmission planning, is responsible to provide all the
information regarding 2 Mbps fixed connectivity between the BSC and the other BSS network
elements.

The database group prepares the scripts and/or databases and sends them to the implementation
team (O&M or field).

The implementation team is responsible to apply the scripts into the system and send back their
feedback to every group involved in the process. It’s recommended that they send back the log file of
the activity.

The process ends when the implementation team, together with all the involved areas, approves the
success of the activity. Basically the final check is the following:
· Implementation checks if the script was correct applied into the system;
· RF Planning area validates the parameters that are related to them;
· FNP area validates the overview of the network after the implementation;

10
 Database Delivery
Process

Start

PM defines Sends the Sow and

Sow & detailed detailed forecast
forecast

RF Planning FNP Transmission

(Delivery (Delivery Planning
Change Overview of (TX Parameters
Requests) The network) Definition)

Sends the Sends

Change Overview of
Request the planned
network

Sends the ASC

database and
Implementation Symbolic DB Planner
(delivery Name creates the
Database & scripts and/or
Symbolic Name) database

Runs the
scripts

Implementation
runs the scripts
Send back to
DB Planner

NO Script
OK?

Yes

No FNP/RF
validates the End
changes

Figure 1 – Process for the deliveries

11
10. TERMS AND CONDITIONS

In order to guarantee the success of database activities, some conditions must be followed:
1. Receive the inputs correctly filled up according to what was agreed in the chapter 3 of this
document.
2. The scope of work and forecast must be trustable and realistic.
3. The total amount of activities per day must respect the timeline required for each activity. This
timeline is only valid considering that the inputs required for the activities are according to
what was specified in this document.
4. The upload of the database and the symbolic name files must be sent around 09:00 am
(Brazil time) or earlier.
5. The scripts must be executed according to the sequence pre-defined by the DB Planner.
Delays in the execution of the scripts must be avoided.
6. Database just guarantees the success of the activity if the script to be executed will be applied
in the same database as it was tested.
7. According to the operation mode of CSI-RDC, the working hours for database activities is
scheduled from 9:00 am to 18:00. Extra hours/efforts need to be scheduled previously with
the Subcontractor RDC Team and approved by the line manager.
8. Any engineer belonging to the Subcontractor RDC Team can provide the same service and
support to each project. All the professionals at this Team are envolved with all the projects at
the same time and are also responsible for the communication between the RDC and the
other involved areas, and has the empowerment to discuss every operational issue related to
his particular project.

11. ANNEXES

Data Base Common Activities

\\192.168.200.10\Projects\RDC_Brazil\2G_BSS_Database\Help\DB_Activities_PPTv2003.ppt

Change Request’s documents example

\\192.168.200.10\Projects\RDC_Brazil\2G_BSS_Database\Example\Template\*.*

ASC Database Upload example

\\192.168.200.10\Projects\RDC_Brazil\2G_BSS_Database\Example\Nova_Base\*.*

Symbolic Name example

\\192.168.200.10\Projects\RDC_Brazil\2G_BSS_Database\Example\Symbolic Name\*.*

12