GISdevelopment.net ---> GITA 2002 ---> Systems Architectures

Telecommunications Network Modeling

Steve Van Ausdall
Geographic Information Technology, Inc. (GeoIT)
101 Inverness Drive East, Suite 130
Englewood, CO 80112


Abstract

Telecommunications networks are inherently complex. Telecommunications companies must plan, design, construct, provision, and maintain networks with millions of unique signal paths connecting their subscribers. Often, junctions contain thousands of physical connections. Building and maintaining an information system to model such a network is arguably more complex than building the network itself - especially when system requirements include such features as scalable concurrent multi-user access, versioned workflow processes, conflict detection and resolution, transaction control and data integrity, network analysis, and downstream administrative count changes, or “ripples”. This paper explores and explains some of the complexities, and addresses one of the core tasks – defining database structures to hold the myriad pathways, interconnections, and signal identifiers that can support construction and grow with the company. Once an accurate model of the network has been built, and a user interface has been provided to easily visualize, navigate, update, validate, and issue changes to the network, the resulting system can accelerate engineering and construction, improve customer service and order completion time, and reduce operating costs.

Complexity



Figure 1: A Splice Engineer Repairs an Accidental Cut


Telco networks are the most complex of any infrastructure network, since each feature (cable, device, etc.) can have multiple sets or banks of n connectable elements, or connectors (pairs, fiber strands, posts, ports, etc.). For example, an interface terminal may have 400 input posts, and 800 output posts. In the picture above, a splice engineer is repairing damage to a large bundle of copper pairs. The wires are uniquely colored, in order, so that they can be enumerated and identified.

The simplest types of networks are water / wastewater, gas, and cable. They have only one conduit for transport (the product is broadcast, so to speak), so connections can be specified at the feature level without compromising functionality. This is how most GIS systems support connectivity – at the graphic feature level.

GIS Requirements

So, what is required of a network design and maintenance GIS system? Over the years, through experience, many large companies have learned that an enterprise class system must support these minimum requirements.
  • Continuous Spatial Database
    • No grid tiles, no “lock drawing” required
  • Multi-Version Workflow (Long Transactions / Post / Publish)
    • Store changes in view-private versions within work packages
    • Detect and assist in reconciling version dependency conflicts
    • Automatically post changes to public view
  • Concurrent Multi-User Access
    • Support tens to hundreds of GIS users, and millions of database entities, with acceptable performance
  • Database / System Integrity
    • Enforce complex validation rules (to prevent invalid / incomplete designs)
  • Network Analysis / Design (Telco Only)
    • Provide a complete, summarized view of a range of connectors (network trace, count makeup)
    • Store the physical connections as well as administrative counts for each network element
    • Propagate administrative count changes downstream (“ripple”) for each connected feature along the physical network
Modeling Network Entities

Now that we know what is required, let’s get to the models. The first step is to determine the most generalized forms of the entities we need to model. For the purposes of this paper, the following partial list of generic network entities will be used.
  • Support Structure / Civil Features
    • Pole, Vault, Manhole, Conduit, Span
  • Network Features
    • Copper / Fiber / Coax Cable,
    • Frame, Device, Terminal, Fiber Node
  • Connectors (Carry signals named by counts)
    • Copper Pair, I/O Port, Fiber Strand
  • Connections (Relate connectors)
  • Designations (Pair / Strand Color)
    • Mapping between physical connector
    • and how to find it on the network feature


Figure 2: Simple Network Model


This simple network model is the most basic, supported by most GIS vendors. Some vendors use node-arc-node instead of element-to-element, as this model uses. Node-arcnode models store both the upstream and downstream connections in one connection record (for each arc), instead of one connection per record. The many-to-many <> relationship implies another table to store the two connected network FEATURE_IDs. Sometimes additional attributes about the relationship are stored, such as directionality (flow).

The simple model shown above has the following disadvantages.
  • Connectors (pairs, fibers, ports) are not DB entities - Changing a COUNTS record creates a new version of the entire feature record, causing unnecessary design conflicts.
  • Connections are stored between features instead of between connectors – Code would need to parse COUNTS records and perform matching against connected features to determine physical connections.
  • It would be very difficult to provide network analysis functionality such as trace or ripple, due to ambiguity of physical connection data.


A Complex Network MOdel


This model is “complex” because the connections are stored between connectors, which are associated with a feature. It addresses all the problems with the simple model.

This paper uses an element-to-element connectivity model, but the concepts could be applied to node-arc-node models by modifying the CONNECTION table to contain upstream and downstream node connections at the same (connector) level. Both nodes and links would need associated CONNECTOR records.

Saple Network

The following sample network will be used to see how administrative counts, the physical connectors carrying them, and the connections between physical connectors are stored in the data model. The network uses notations similar to typical RBOC (Regional Bell Operating Company) maps.





The following tables show the information stored for feature “ID10”.



Figure 6: Sample Network Data in Complex CONNECTOR Table


The CONNECTOR table stores the administrative counts of the source of each network feature. In this example, administrative identifier “2B”, counts “25-30” are transported on cable “ID10”.

If the display of historical (previously named) ranges is required, another primary key column might (depending on the GIS vendor) need to be added to the CONNECTOR table. This would allow the historical ranges to be classified as different entities, so they can exist in the same version as the current or proposed ranges. Another solution might cache the count labels, using triggers to repopulate the cache.



Figure 7: Sample Network Data in Complex CONNECTION Table


The source connection of each connector is stored in the CONNECTION table. Each connector can only have one source connection, and the primary key (FEATURE_ID, ADDRESS_SPACE, CONNECTOR_NUM, and VERSION) reflects that fact, as there can only be one row for each unique primary key combination.



Figure 8: Range Based Complex Network Model


This model differs from the previous complex model by adding a RANGE_SIZE attribute to the CONNECTOR and CONNECTION tables. Each row in those two tables can now represent n connectors or connections, with the rule that they must all be contiguously named, ordered, numbered, and connected.

More care must be taken by the application to ensure that all connectors are accounted for, and that they are each accounted for only once, since the primary keys no longer enforce those rules.

Next, we’ll map the data from the sample network into these tables.



Figure 9: Sample Network Data in Range Based Complex CONNECTOR Table



Figure 10: Sample Network Data in Range Based Complex CONNECTION Table


Feature “ID10” now requires only one row in each table to represent the network data. Notice that RANGE_HIGH attributes are not stored. Views can be created to make the value available for use in queries, using the simple formula below.



Figure 11: Comparison of Complex Model and Range Based Complex Model


Automatic Downstream Administrative Count Changes

This section takes a quick look at “ripples” – what they are, and an algorithm outline that gives a good idea of what it would take to implement them in a GIS system.

A ripple is the downstream update of administrative count names or numbers required when a connection changes. The count labels of the features reflect the administrative name of the source, so when a connection changes, all the downstream connectors must be updated.



Figure 12: Disconnection / Ripple Initiation


The user selects feature “ID09” and chooses a function to change the connections. The user then disconnects four connectors in the middle of the range, and renames the new counts as “B, 1-4”.



Figure 13: Results of Disconnection on Sample Network


The system performs the following tasks to perform the disconnection.
  • Updates the connections at cable “ID09”.
  • Traces the network downstream along the updated count ranges.
  • Updates the counts of the appropriate downstream connectors to the new values.
The tables below show the data after the operation is completed. The row shading shows how and why each row changed, according to the following legend.



Figure 14: Update Legend



Figure 15: Ripple Changes in Range Based CONNECTION Table

br>
Notice that ranges are split when necessary, in the previous version. In addition, modified data is associated with a new version, so that if the user requests to undo this change, the new versions of the data can simply be deleted, leaving the original data values. The GIS or the database should contain version management functionality to rollback or commit specific versions. Only one range changed connection (to no source), but four ranges (some of different sizes) changed connector count names.

Ripple Algorithm Outline
  • Algorithm Outline
    • Lock selected and directly connected features
    • Get connection / count changes from user
    • For each count change
      • Perform a network trace downstream
        • Lock each affected downstream feature and keep an ordered list of the updates
        • All range splitting is done in the previous version.
    • Begin a database transaction
    • Apply the stored updates in a long transaction (a new version)
    • Commit the database transaction
    • Redraw the affected features
  • Error Handling
    • Cancel the operation, notify the user if:
      • Exceptions and failures found <\li>
      • A feature is already locked for update by another user <\li>
      • Unpublished entities are affected (workflow state conflict) <\li>
Summary
  • Telecommunications GIS systems typically require specialized database models, and sophisticated custom network update and analysis tools.
  • Range based network data models provide better scalability and performance due to reduced data volumes (10% of the rows required with non-range based models) and faster update times.
  • Investment in GIS can reduce operating costs by automating previously manual tasks such as ripple updates and records posting.
© GISdevelopment.net. All rights reserved.