|
|
|
Systems Architectures
|
Telecommunications Network Modeling
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).
|
|
|
|
