Utility



Map India Conference 2003
� GISdevelopment.net, All rights reserved.

Telecom GIS: An Integrated Approach


Milind Deshpande
General Manager
Reliance Engineering Associates (P) Ltd.
A Block, Ground Floor,
Dhirubhai Ambani Knowledge City,
Navi Mumbai, 400 709
milind_m_deshpande@ril.com

+91 22 2762 4885

KM Jagadeesh
Vice President
Reliance Infocomm

Jagadeesh_KM@ril.com

+91 22 2762 4815


1.0.0 Introduction
Reliance Infocomm is implementing countrywide telecom network providing wireless and wireline
services to customers. Telecom GIS is being implemented as part of this project for serving the
business needs of the enterprise. This paper discusses experience gained in implementation of a
telecom GIS fully integrated with the Operations Support System (OSS) / Business Support System
(BSS) for countrywide network of Reliance Infocom.
2.0.0
Business Requirement Assessment
At the outset of the vast telecomm infrastructure project, Reliance management recognised the
importance of providing high quality of uninterrupted service to the customers. Continuously evolving
technology and tremendous competition has necessitated maximisation of utilization of telecom
inventory and tight inventory controls.
GIS platform with a dedicated telecommunication application is the optimum solution since it can
store the network inventory in a geographical manner. Interfacing with network, O & M and customer
facing systems enables to meet the business requirements successfully. Some of the main
requirements expected to be met by the GIS / Telecom application are:

Plan, design and engineer Network and expansion

Modeling of (OutSide Plant) OSP and (InSide Plant) ISP items up to port level

Placement of Trenches, Cables, Structures and facilities in the OSP

Facility layouts, equipment placement and port-to-port connectivity

Inventory management including equipment assignment

Repository of As Built and survey data

Provide network data to OSS / BSS systems

Answer service activation / provisioning queries

Cable fault localisation

Several Sales, Marketing and Service fulfillment related functions


3.0.0
Selection of GIS Platform & Telecom Application
Technical evaluation of all existing out-of-box packages was done with one week hands-on
experience wherein ease of learning and operation, efficiency of CAD functionalities etc. were tested
by operators. Map India 2003
Utility



Map India Conference 2003
� GISdevelopment.net, All rights reserved.

Detailed technical discussions involving client functional capabilities, RDBMS, version management
of the GIS platform were carried out.
Ease of data conversion, telecom feature modeling and other functions were evaluated. Efforts in
customisation, after sales support etc. were also considered.
Detailed analysis of productivity expected work volume, licensing cost was made and optimum
solution arrived at.
4.0.0 Data
Creation
4.1.1
It was necessary to create the high-resolution data of cities and inter-city roads for typical
telecom operations since it is not readily available in the country. This data is categorised
into (a) City (b) Survey (c) Roads. Detailed specifications were drawn for each dataset
based on the business requirements.
4.1.2
City data was digitised in AutoCAD Map from 1 or 6 meter resolution satellite imagery. The
work involved 500,000 man-hours and was outsourced from 8 vendors. Survey data in
AutoCAD format was collected by field construction team using over 30 survey contractors.
Road data was procured in coverage form. Over 30,000 kM DGPS survey in navigational
mode and fixed points was done to geo-reference the entire dataset. Migration of data to
GIS platform is done using FME software.
4.1.3
The planning of sequence of activities allowed us to carry out the mammoth task of data
creation in parallel with other project activities without affecting the overall project
schedule. This strategy also allows us to load large amounts of map and inventory data
throughout the lifetime of the telecom operations.
4.1.4
However, this method imposes major constraints on the continuous availability of the multi-
versioned GIS database. Although actual system time for data migration is less than a
day, all preparatory work and attendant actions result in a down time of up to 4-5 days for
uploading such bulk data. We are studying various options to reduce this downtime.
5.0.0
Creation of Network Inventory
5.1.0 Introduction
Unlike the map and survey data, Telecom network inventory and connectivity involves complicated
logical relationships, which are difficult to capture on CAD platform. Migration of such data to GIS
platform is also very complex, error prone and does not lead to cost, efforts or time reduction.
Therefore, network inventory is created directly on selected GIS platform, using telecom application.
5.2.0
Modeling & model libraries
5.2.1
Telecom applications have specially designed data model, providing ability to build models
of frequently used items like ports, cards, chassis, equipment, cables, structures etc.
These models can be instantiated directly or configured into frequently repeating
combinations, which in turn can be instantiated on the map.
5.2.2
Building model libraries requires full understanding of the telco application and detailed
subject knowledge of telecom engineering, operations and maintenance. Integration of GIS
/ telecom application with OSS has a major bearing on modeling. Therefore, wherever
OSS-GIS integration is involved, Telco applications having application having a flexible
model builder is preferable over application with built-in model libraries. Integration with
OSS should ensure that all model reference data is synchronised beforehand, for smooth
transfer of instance data.
5.3.0
Building on migrated data: OSP Map India 2003
Utility



Map India Conference 2003
� GISdevelopment.net, All rights reserved.

5.3.1
Accurate geo-referenced map data is insufficient to derive maximum value from the Telco
application. Accuracy of survey data is of utmost importance. Survey data with trench,
man-hole & hand-hole details, number and alignment of ducts is migrated from AutoCAD
platform. Correct models of span & ducts are populated. Cables are also drawn using
models developed on telco application. Further, cross-sectional views of the trench are
added and cables are associated with ducts. Cable splicing / connection and slack loop
addition is carried out and lastly, as built data of cable optical & run length is entered.
5.3.2
In case of Optical Fiber Cables (OFC), OTDR equipment is able to provide an optical
distance with excellent accuracy. However, following factors affect accuracy of fault
localisation:

Fiber length of cable is generally 2-3% more than the cable length.

Cable is blown in conduits, which have 'snaking', thus increasing the cable and fiber
length.

Slack loops of 10-20 meters are left in each chamber, approximately every kilometer.

Line feature in the map does not consider differences in elevations, which add to the
cable and fiber length.

OTDR equipment can be 100 kM away from the fault.
Unless the fault localisation algorithm compensates for these factors, inaccuracies may add up to
several hundred meters, defeating the whole purpose.
5.4.0
ISP Data Creation
5.4.1
First task in ISP data creation is drawing facilities, floor plans and rack layouts using telco
application. This is a time consuming task in ISP data creation process.
5.4.2
There are thousands of network elements and utility equipment that need to be placed in
the ISP facilities. Although these can be instantiated one at a time using the models, large
man-hour savings are possible by pre-configuring frequently repeating equipment models.
During instantiation, network element codes, if followed, are entered. Equipment thus
placed in the facility are then "racked-in" in the respective racks as per the designs / as
built. At this stage, the ISP equipment can be seen on the telecom application as they are
physically installed in the field.
5.4.3
Connectivity between ISP equipment is logical in nature while connectivity between OSP or
ISP and OSP features is physical. Appropriate rules should be set so that invalid
connections are not allowed by the system.
5.5.0
Requirements posed by Versioning
5.5.1
A multi-version database provides users with an ability to manage changes to the database
through multiple versions. Each user can have multiple versions of the database. Unlike
multi-user database, more than one user can make changes to the same feature
simultaneously. Process of reconciliation detects conflicting changes to same feature by
multiple users and allows proper resolution by manual intervention. It also allows the
organisation to have a workflow to reflect various stages of project from planning,
designing, engineering, construction, As Built to in-service.
5.5.2
In a typical network build phase, there are hundreds of sites each going through the project
stages mentioned above. Multi-versioning capability of the GIS allows us to open versions
for each site, which can then transition through these stages.
5.5.3
Large data loads take very long time in multi-versioned database and hence require the
database to be unversioned. Unversioning the database drops edits from