Telecom GIS: An Integrated Approach

Telecom GIS: An Integrated Approach


Milind Deshpande
General Manager
Reliance Engineering Associates (P) Ltd.
Ph. No. : +91 22 2762 4885
E-mail: [email protected]

KM Jagadeesh
Vice President
Reliance Infocomm
Ph. No. : +91 22 2762 4815
E-mail: [email protected]

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.

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
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 all versions that are not transferred to base tables. To guard against this, it is required to reconcile all versions after resolving all conflicts, post all versions, compress the database and finally unversion the database. All these tasks are necessarily sequential in nature. Some of the tasks require exclusive access to database and stop users from editing or even reading from the database. This scenario presents major challenges in providing high availability and uptime in an environment having 24×7 hour operations. Each organisation must decide its strategy by weighing these advantages vis-?-vis the uptime requirement.

5.6.0 Applications in Network Planning & Engineering
5.6.1 Several applications in the area of network planning and engineering are possible using the telecom database. These include schematic representation of network, creation and comparison of different versions of network plans, automating network engineering and element codification etc. A lot of scope also exists in RF planning.
6.2.2 Typically, printed GIS outputs are maps. However, EPC activities require strict revision control and document control with a central document repository. Material control procedures require keeping track of BoM and prepare Material Take-Off (MTO) for procurement / delivery and issues. GIS being a dynamic database is not readily amenable to such controls. A customised application is developed to print all engineering drawings and layouts in standard formats complete with drawing numbers, revision & approval control and BoM. The drawing-wise BoM data is also stored in the GIS database to enable MTOs for procurement / construction purposes.

6.2.3 Special data-entry tool is developed to ensure the sufficiency of data, particularly for accurate fault localisation. Tool also recognises and permanently stores direction of digitisation of cables required for long traces.

6.2.4 Automation tool has been developed for entering a large number of facilities in OSP; floors, racks and equipment in ISP. Input in dBaseIV format is validated and features placed in the map automatically, in fraction of time required for doing it manually.

6.2.5 Similar automation tool is developed for copying the migrated trench parallel to itself and converting it to a cable. The inputs are in the form of selection of connected trench features, offset distance and direction of copy. The trench features are copied as a cable, retaining the geometry of migrated trenches but using a model of cable. Such automation has helped in increasing the productivity manifold.

6.2.6 Interactive fault localisation tool using COTS network trace capability is developed. This tool applies compensations to data errors mentioned earlier to provide extremely accurate fault location

6.2.7 Web based applications are developed for viewing the network and faults over the company Intranet.

7.0.0 Integration with other systems

7.1.0 Business driver
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 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 Integration with OSS
7.2.1 Telco application on GIS platform is the data master for all network inventory and network infrastructure data as well as network related reference data.

  • Network inventory data includes 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 configuration is created in OSS based on information from Telco GIS and customer data entered in CRM.

7.2.2 The data volume of physical network inventory, connections and facilities runs in to a few million records for a large network. Single point data creation with automatic uploading in OSS ensuring synchronising of the two databases saves several thousand man-hours.

7.2.3 As a result of this, permanent link is automatically established between OSS and GIS through primary keys, allowing on-the-fly spatial queries to be handled between the two systems. Questions by OSS and field staff requiring information of nearest active electronics facility or nearest manhole based on visual or textual address input are answered in seconds.

7.2.4 Detailed requirement assessment and data mapping is performed jointly by OSS and Telco application team. At this stage, following details are frozen

  • All network element and facility naming conventions
  • Modeling details for both physical and logical configurations
  • Overall integration scheme and middleware
  • API signatures on either side
  • Error handling and database synchronisation issues
  • Test plans & test cases with expected results

7.2.5 We have successfully implemented an application for uploading the network inventory and physical links data to OSS. Enclosed Figure 1 indicates Flowchart of Data Upload 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.
  • The ‘SUCCESS’ is also posted to the versioned tables to avoid retransfer of the data during the next dump.

Figure 1 – Flowchart of Network Inventory Load to OSS 7.2.5 We have successfully implemented an application for uploading the network inventory and physical links data to OSS. Enclosed Figure 1 indicates Flowchart of Data Upload 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.
  • The ‘SUCCESS’ is also posted to the versioned tables to avoid retransfer of the data during the next dump.

Figure 1 – Flowchart of Network Inventory Load to OSS