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 24x7 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.