H

Telecom GIS: An Enterprise Approach Authors' Names: Milind Deshpande

Title of Paper: Author Information:
H

Name: Milind Deshpande Title: General Manager Organization: Reliance Infocomm Ltd. Address: A Block, Ground Floor, DAKC,

Thane Belapur Road, Koparkhairane, Navi Mumbai 400709 Telephone: +91 22 3037 3333 xtn 4885 Fax number: +91 22 3037 3333 xtn 4884 e-mail: Milind_m_Deshpande@ril.com

Telecom GIS: An Enterprise Approach

Abstract:
A new carrier in the recently deregulated India telecommunications market, Reliance Infocomm is building a world-class broadband network, IP backbone, connecting 686 cities with 60,000 kilometers of fiber that will offer terabit capacity. Reliance offers customers national coverage in fixed line, mobile (CDMA), national and international long distance telephony, as well as a full offering of data, image, and value added services. This paper discusses Reliance Infocomms experience gained in implementation of GIS to support telecom network. Activities like equipment modeling, ISP view & geodatabase creation and use in telecom engineering are covered. Several productivity improvement tools in creating network database and pivotal role of GIS in integrating OSS / BSS / Fiber Monitoring System, data dissemination via the corporate Intranet for efficient Operations and Maintenance of the telecom network are presented.

Telecom GIS: An Enterprise Approach

1.0.0

Introduction

Reliance Group is Indias largest business house with total revenues of US$ 13.3 billion with cash profit of over US$ 1.5 billion and total assets of US$ 14.1 billion. The Groups activities span petrochemicals, synthetic fibres, fibre intermediates, textiles, oil & gas, refining & marketing, power, telecom and infocom initiatives, financial services and insurance. Reliance Infocomm Ltd. is implementing countrywide telecom network providing wireless and wireline services to customers. Telecom GIS is being implemented as part of Reliance Infocomm project for serving the business needs of not only infocom business but also the entire Reliance enterprise. This paper discusses experience gained in implementation of tools to improve productivity of large telecom network data creation and integration applications for our telecom GIS which is tightly integrated with the Operations Support System (OSS) / Business Support System (BSS).

2.0.0

Abbreviations

Abbreviation BoM COTS FMS MTO NE NEMS OSS OTDR OSP

Full form Bill of Materials Commercial Off The Shelf Fiber Monitoring System Material Take-Off NetworkEngineer Network Element Management System Operations Support System Optical Time Domain Reflectometer Outside Plant

Abbreviation BSS EPC ISP LOS NE NMS O&M OFC

Full form Business Support System Engineering, Procurement & Construction Inside Plant Loss of Signal Network Element Network Management System Operations and Maintenance Optical Fiber Cable

3.0.0 3.1.0

Business Requirement Assessment & Selection of GIS Objective

Reliance Infocomms objectives are providing high quality, uninterrupted service to the customers throughout the country, in an environment characterized by continuously evolving technology and tremendous competition. To meet these objectives successfully, it is necessary to maximize the utilisation of telecom inventory, adopt efficient work processes and provide tools to the customer facing staff for faster and informed response to customers.

3.2.0

Requirements

GIS platform with a dedicated telecommunication application was considered an optimum solution, since it can store the network inventory, its attributes and geographical information. Interfacing with network management, O & M and customer facing systems enables to meet the business objectives successfully. Some of the main requirements expected to be met by the productivity improvement tools and integration applications on telecom GIS platform were: Data creation for Telecom network covering 60,000 route-kM, 4,000 facilities, Provide network data to OSS / BSS systems Cable fault identification Several Sales, Marketing and Service fulfillment related functions 100,000 buildings and over 40,000 network elements within 1 year.

3.3.0

Selection of GIS Platform & Telecom Application

3.3.1 A team of Project engineers, GIS & telecomm professionals, systems & database administrators held detailed technical discussions with GIS vendors to evaluate system architecture, functional capabilities, RDBMS, version management development environment & customisation efforts. Ease of data conversion, telecom feature modeling, adaptability for network infrastructure creation, detailed engineering were the focus areas in evaluation. Evaluation of COTS packages also involved hands-on experience wherein, 3.3.2 ease of learning and operation, efficiency of CAD functionalities etc. were tested & rated by operators. Detailed analysis of productivity, expected work volume, licensing cost was made and an optimum solution arrived at.

3.4.0

Deployment

Reliance has deployed ArcSDE on Oracle (RAC) on 64-bit Solaris platform using activeactive clustering. The client applications are NetworkEngineer 2.x (NE), ArcView, ArcEditor & ArcInfo. We have also deployed Spatial Analyst and 3D Analyst which can be used for RF applications. ArcIMS servers are used to disseminate the data across the enterprise on the corporate Intranet.

4.0.0 4.1.0

Creation of Network Inventory Modeling & model libraries

4.1.1 Building model libraries requires full understanding of NE, detailed subject knowledge of telecom engineering, operations and maintenance. Integration of telco data on NE platform with OSS has a major bearing on modeling. A team of Network Planning, NE and OSS engineers ensures that model 4.1.2 data is synchronised between NE & OSS in advance for smooth transfer of instance data.

4.1.3

In the work process established for this purpose, Network Planning

personnel collate the model data from vendor documents and pass to NE group for preparing the models. These models are validated by OSS and Network Planning group before instantiating in production environment.

4.2.0
4.2.1

Building on migrated data: OSP

Accurate geo-referenced map data alone is not sufficient to derive

maximum value from the Telco application. Accuracy of survey data is of utmost importance. Some of the important aspects of this data are duct couplers, crosssectional views of the trench and duct-cable association, splice locations, measured & optical cable length (sheath marking), slack loop data at each man-hole / hand-hole. OFC and slack loops data must be captured in a specific manner to support 4.2.2 our highly accurate fault trace algorithm. OTDR equipment located strategically throughout the country has visibility of every optical link of our network. OTDR is able to provide an optical distance with excellent accuracy. However, it is important to note the following factors that affect accurate fault identification on ground: Fiber length of cable is generally 1-2% more than the cable length. Cable is blown in conduits, which have 'snaking', thus increasing the cable and fiber length compared to what is actually drawn in GIS as line feature. Slack loops of 10-20 meters are left in each chamber, approximately every kilometer for ease of maintenance. Line feature in the map does not consider differences in elevations, which add to the cable and fiber length. Since the OTDR equipment can be over 100 kM from the actual fault, the difference between optical and graphical distance increases as the fault is located farther away from OTDR site.

4.3.0

ISP Data Creation

4.3.1 First task in ISP data creation is placing facilities, floor plans and rack layouts in NE. We have developed standardized floor plans on AutoCAD and utilised DXF import capability of NE Model Builder to improve data creation productivity. Typical ISP facilities contain thousands of network elements and related 4.3.2 equipment. Although these can be instantiated one at a time using the models, large man-hour savings were observed by pre-configuring frequently repeating equipment configurations or assemblies. Equipment placed in the ISP facility is displayed in the plan view and elevation view. Network element codes to identify every card geographically are entered during instantiation.

5.0.0 5.1.0

Data Creation Productivity Improvement Tools on NE OSP

5.1.1

Detail view is added to spans after migration based on number of ducts.

SpanXCopy tool developed by MESA Solutions copies detail view of one span to all selected spans having same duct configuration. Estimated saving were 8,000 man-hours for 35,000 spans using this tool. Since the type of cable is not known at the time of preparing the trenching 5.1.2 drawings / survey; only spans and structures are migrated to database from AutoCAD. AddTransmedia tool is developed by MESA Solutions for copying the migrated trench parallel to itself and converting it to a cable of desired model. The inputs are in the form of selection of snapped trench features, offset distance and direction of copy. The trench features are copied as a cable, retaining the geometry of migrated trenches but using the model of cable. Besides very high accuracy, a saving of 7,000 man-hours was estimated by use of this tool. Start Point Configuration tool developed as part of FaultTrace application 5.1.3 populates measured distance of cable slack loop from specified structure and measured / optical lengths of the slack loop. Tool automatically recognises and stores the direction of digitisation of cables as an attribute in Transmedia feature class. Both these attributes are key data for our fault trace algorithm. 5.1.4 ValNetEntID tool performs automatic codification (Network_Entity_ID or NEID) and attribute population for all transmedia. During the network build stage while NE was being implemented, we had to 5.1.5 issue OSP construction drawings for over 5,000 sq. kM area covering 15,000 kM of cabling using AutoCAD. These drawings are currently being migrated to NE platform. CAD_TO_NE tool developed for this purpose allows us to not only retain all the data of the issued drawings, but also performs several additional functions while migration to geodata base. Use of this tool has saved over 18,000 man-hours by avoiding rework on NE platform. The tool performs following activities: Loads all structures & transmedia from shape files to GDB feature classes. Places all splices & makes all necessary connections Performs codification (NEID) of structures and transmedia and splices

5.2.0
5.2.1

ISP
AutoPlace tool using a single client machine and work order, performs

following functions at several facilities in one go: 5.2.2 Placement of Floors and rack (Structure_Units) & adding NEID Placement of fully configured equipment at these sites Creation of detail views for racks UpdatePluginNEID tool automatically performs codification all plugins

based on the NEID of chassis entered manually.

5.2.3

StructEqptChk tool is used for QA / QC which validates NEIDs all

equipment, racks, chassis, and cards based on that of their facility.

6.0.0 6.1.0
6.1.1

Customised Applications Some important functions

COTS functionality of the telecom application goes beyond that of base GIS

platform by serving the needs of engineering, construction and projects monitoring. However, these functionalities are generic in nature and need to be customised to suit organisational work processes. Some of the examples are described in the following sections.

6.2.0

Customised Applications

6.2.1 Typically, printed outputs from GIS are maps. However, EPC activities require strict revision & document control with a central document repository. Material control procedures keep track of BoM and prepare Material Take-Off (MTO) for procurement / delivery / issues. The GIS database is very dynamic, constantly being updated, therefore it is not readily suited to such controls. To meet our revision and document control requirements, a customised application was developed by MESA / ESRI to print all engineering drawings / maps in standard formats, complete with drawing numbers, revision & approval control and BoM. The drawing-wise BoM data is stored in GIS database to enable MTOs for procurement / construction purposes. We have installed an extensive OFC network throughout the country. Main 6.2.2 facilities for optical repeaters / amplifiers are located every 60-80 kM along national and state highways and are mostly unmanned. The OFC network is monitored using Fiber Monitoring System (FMS) consisting of OTDRs located strategically and controlled from National Network Operations Center (NNOC) at Reliance Infocomm Head Quarters at Mumbai. The O & M organisation had an objective to repair any fault through out the country within 4 hours including time required for fault identification, getting map prints, despatch of repair van with crew and repair time. This necessitated fault identification, map prints and trouble ticketing to be completed within 20 minutes to the crew nearest to the fault. While a fully integrated system was being designed, an Interactive fault identification tool using COTS network trace capability was developed. This tool accepts OTDR port name and distance to fault as user inputs via a specially developed GUI, applies compensation to data errors mentioned earlier to provide extremely accurate fault location. This was further developed in to AutoTrace application discussed subsequently. Web based applications are developed for viewing the network and faults 6.2.3 over the company Intranet.

7.0.0 7.1.0

Integration with other systems Business driver

7.1.1

GIS based telecom application requires large investment, manpower and

time in data creation and deployment. Full benefits of such systems can only be realised when the Telecom GIS system becomes an integral part of the OSS / BSS solution and the organisational work processes are designed with GIS as an essential part of such integrated OSS / BSS solution. Based on automatic flow-through business processes, such integration 7.1.2 provides maximum value addition in terms of Single point data entry and elimination of redundant databases, Minimal human intervention in data creation, Improved response to network events, Improved response to customers,

resulting in improved overall efficiency of the enterprise.

7.2.0

Data Transfer to OSS

7.2.1 At Reliance, NetworkEngineer is the application used to manage all network inventory and network infrastructure data. NE also manages the reference data of all network elements up to port level. This data is stored in a geodatabase containing the following: Network inventory data (equipment, cards and physical ports). Physical configuration data includes physical circuits and cross connections. Infrastructure includes facilities & other OSP data like trenches and cables.

The logical network is then created in OSS based on this data transferred from NE. At the beginning of development of this application, a detailed requirement 7.2.2 assessment and data mapping was performed by OSS and NE team covering: All network element and facility naming conventions Modeling details for both physical and logical configurations Overall integration scheme and middleware (Refer Figure 1: API signatures on either side Error handling and database synchronisation issues Test plans & test cases with expected results

NE OSS

Integration Architecture)

Figure 1: NE OSS Integration Architecture

7.2.3 Application for Transfer of Physical Inventory Data to OSS forms the

foundation of total integrated solution. Enclosed Figure 2 indicates Flowchart of

Network Inventory Load to OSS. Following are the important steps involved:
Inventory changed since last upload is transferred to interface tables using a difference cursor with 'ADD', 'DELETE' or 'MODIFY' flags. Middleware adapters are triggered to start transfer to OSS. Inventory data is validated against of reference data in OSS. A 'SUCCESS' or an error code is returned to interface table. ADD inventory previously rejected by OSS is sent as ADD once again. The 'SUCCESS' is also posted to the versioned tables to avoid retransfer of the data during the next dump.

Figure 2 - Flowchart of Network Inventory Load to OSS

7.2.4 The task of error checking, corrections and transferring the data again to OSS is manual and tedious. GIS / Telco application operator may need to check 3,000 records after each dump. This task is facilitated by specially developed GUI, which displays the error message for each inventory item, allows user to zoom to the feature as well as select and start editing the same version, which created the inventory. Due to the difference in representation of links in OSS compared to GIS / 7.2.5 Telco application, transfer of links is more complicated. The Links are populated in the interface tables as follows: Every connected port is scanned and a network trace made. Each complete trace is given a 'Set ID' and each connection link within a set is given a 'Sequence Number'. Two tables are populated where every 'Set ID' is mapped to the OTDR port, which monitors that link. From the first table, OSS picks up 'FROM' port from the first record and 'TO' port from the last record of the set.

From the second table, OSS picks up information of which Link is monitored by

which OTDR port.

7.3.0
7.3.1

Unattended OFC Fault Trace

OSS integration for Fault identification is the most important and highly

integrated application developed jointly by Reliance, MESA and OSS team with inputs by ESRI. The links and OTDR port-mapping tables loaded from GIS database form a key to this automatic flow through process. Refer enclosed Figure 3 indicating the

Flowchart of Automatic Fault Localisation.

Following are the important steps involved: Two adjacent network elements report Loss of Signal (LOS) to NEMS. NEMS raises alarm to OSS OSS Alarm Correlation module analyses and concludes that it is due to a fiber fault. Based on previously transferred inventory, link and OTDR port mapping data, OSS determines which OTDR port needs to be activated for monitoring fault. OSS commands the OTDR to provide optical distance to fault from identified port. The OTDR returns the optical distance of fault via OTDR server to OSS. OSS passes the same along with OTDR port and a Fault ID to Telco application on GIS platform for locating the fault on map. GIS / Telco application places the fault marker, calculates all the necessary attributes and publishes the fault location to Intranet. Simultaneously, the information is returned to OSS for further use like trouble ticketing, history etc. The entire process including actual OTDR trace is completed in 10 minutes without any human intervention

Figure 3 Flowchart of Automatic Fault Localisation.

7.3.2 Distance of attachment (slack loop) from a specified splice, measured /

optical lengths of attachment as well as direction of digitisation is populated by Start point configuration tool. Once the optical fault distance and the OTDR port input is provided, Application starts adding the optical length of the transmedia records in the NE trace collection until it locates the cable in which the fault lies. In the faulty transmedia, application recognises the direction of fault trace and digitisation of the cable. Application compares the measured length at each attachment with balance fault distance to localize the span in which the fault lies. Once the fault is localized within a span, slack length of the first attachment is subtracted from the remaining fault distance and the fault marker is placed at a graphical location based on the ratio of balance measured fault distance to measured length cable between the two attachments. Algorithm for fault trace yields highly accurate results in the range. The accuracy is

governed only by the accuracy of the data. As verified with the field, it was noticed that the fault localized using this application was within a distance of 5 to 25 meters on the ground at site.

8.0.0

Experiences to Share

Development of these tools was performed by various resources. Some of the tools were developed in-house, some with the help of onsite representatives of ESRI India. The main integration applications were handled by MESA SI group. There were several difficulties encountered in the process. These can be broadly classified in as under: APIs and Developer Documentation related issues NE 2.x Core software related issues ESRI core software related issues Work process related issues

The details are discussed in the following sections.

8.1.0

APIs and Developer Documentation

NE 2.x was implemented on ArcGIS / ArcSDE platform for the first time. It had lot of new features in the ISP area as well as port-to-port connectivity. Unfortunately, Object Model Diagrams were not available. Nor were APIs, sample code for developers formally published and very little documentation was available. MESA is making concerted efforts in this area and we hope to see substantial improvement in the situation with NE 3.x.

8.2.0

NE 2.x Core Software Issues

While implementing Network Engineer, we encountered several issues pertaining to core NE functionality. Some of the important ones were BoM was not configurable, real world items represented logically by NE schema (such as span_units, structure_units) were not showing in BoM. Category, Types created by mistake / for testing could not be deleted ArcMap Application Error occurs even when NE is shutdown normally

Ability to model equipment where ports / connections can be made on both front & rear sides Ability to model cable & slack loops in ISP Several model builder related issues, mostly resolved by 2002 end. Several connection editor related issues, mostly resolved by 2002 end

Split & merge functions provided by ESRI cannot be used on spans due to data corruption issues. General instability of NE and inconsistent results even when following the same work process / steps.

Data getting changed in some of the reference tables.

8.3.0
For example,

ESRI related issues

ArcGIS and ArcSDE related issues faced were primarily in the area of poor performance. Poor reconcile / compress performance was observed during initial data creation

where ratio of records in base tables to delta tables is very low. The problem was traced to Oracle 8.1.7 bug and resolved when upgraded to Oracle 9.2.02 Poor reconcile performance with incorrect / non-existent conflicts were observed when dealing with feature classes having relationship classes. Specifically, in case of 1-M composite relationship classes, update on parent objectid would result in conflict on all child records. Further, all conflict features would propagate conflicts to their other relationship classes. Poor performance in spatial selection, geometric network and network tracing etc. There has been substantial improvement with ArcGIS 8.3

8.4.0

Work process related issues

Reliance Infocomm is a new entrant in the field of telecom and the entire land base as well as network data is being created from scratch in a record time. This required preparing the data on AutoCAD platform and migrate it to ArcSDE in an unversioned state. It is necessary to publish all work orders and achieve full compression of state tree. This work process combined with limitations of software, posed several difficulties. With the poor performance of validation and the fact that publishing has to be a sequential activity, the entire process would take several days, shutting down the database for all practical purposes. In case equipment placed in one work order needs to be connected to cable placed in another, pessimistic locking of records implemented in the NE workflow necessitated transitioning of one of the work order. This is very time consuming. The way the fault trace application is designed, it needs to be running continuously on one of the client machine. Moreover, work order running this tool needs to be merged / published upon locating a fault. If any other work order is being transitioned at this time and has finished reconciling, reconciliation of the fault trace work order results in error in the transitioning work order. It is expected that with NE 3.0 based on ArcGIS 8.3 will alleviate several of these problems.

9.0.0

Conclusion

A well-designed and implemented Telecom Application based on GIS platform is a powerful tool available to the telecom enterprises. The application not only maintains inventory of ISP network elements and OSP objects geographically, but is also be used for

vital activities like network planning, engineering and O & M. High value addition is observed by closely integrating the GIS / Telco application with OSS and BSS making it a truly enterprise database application.