Fiber Manager Data Architecture Overview

This topic displays a brief summary of the data model hierarchy for a fiber optic cable.

Fiber Optic Cable: This is a feature class sketched on the map to represent the geographic location of the fiber optic cable. All of the objects that represent the internal components of the cable are related to this feature class.

• F_BUFFERTUBE: This is an object class to represent the buffer tubes inside a fiber optic cable. In the field, buffer tubes are used to group, protect, and identify fibers within a cable. In Fiber Manager, buffer tubes are used to display fibers within their designated groups and identify specific fibers (Blue Buffer/Blue Fiber = Fiber 1, Blue Buffer/Orange Fiber = Fiber 2,…) within a cable. In the field, buffer tubes may not always be plastic sleeves that surround glass fibers. They can also be threads wrapped around fibers (OPGW Cables), stainless steel tubes (OPGW Cables), plastic notches in a helical divider (European Cables), or even painted marks on fibers (underground and submarine cables). 

  • F_FIBER: This is an object class to represent a single glass strand within a buffer tube that is used to transmit light from one location to another.

Further, the application also supports bundles and ribbons as a method of strand organization. Starting back at the cable level, that hierarchy looks like the following:

Fiber Optic Cable:

• F_RIBBON: This is an object class that represents the contents contained within a fiber optic cable. Whereas a buffer tube is a single element within a cable, a ribbon represents two elements: a bundle and a ribbon. The bundle is a collection of ribbons, and a ribbon is a collection of fiber strands. Both bundle and ribbon attributes are set and managed within the same object table: F_RIBBON. 

  • F_FIBER: This is an object class to represent a single glass strand within a ribbon that is used to transmit light from one location to another.

This topic displays a brief summary of the data model hierarchy for a patch location.

Patch Location: This is a feature class sketched on the map to represent the geographic location of a patch location. This represents a place where fiber optic service is delivered.

• F_RACK: This is an object class to represent the physical rack that holds the patch panels in a patch location facility.

  • F_PATCHPANEL: This is an object class to represent the panel that holds the cards.

    — F_PATCHPANELCARD: This is an object class to represent the patch panel card that holds the ports. The card is the piece of hardware that is inserted into a patch panel, and it contains one or more optical ports. From a data model perspective, the card forms a convenient “container” to group a collection of ports within a patch panel. The card does not have many distinct characteristics beyond this purpose.
    	— F_FRONTSIDEPORT: This is an object class to represent the front side of the fiber ports. Typically, the front sides of the ports provide service to customer devices or can act as jumper points.
    	— F_BACKSIDEPORT: This is an object class to represent the back side of the fiber ports. Typically, the back sides of the ports connect to the fiber strands.

Further, in addition to a patch panel, there can be many other devices supported at the rack level. Starting back from the patch location itself, the following hierarchies are common in fiber implementations.

Patch Location: This is a feature class sketched on the map to represent the geographic location of a patch location.

• F_RACK: This is an object class to represent the physical rack that holds the patch panels and other devices in a patch location facility.

  • F_ACTIVEDEVICE: This is an object class to represent a fiber device that is powered (for example, switching equipment).

    — F_ACTIVERECEIVEPORT: This is an object class to represent the receive port on an active device.
    — F_ACTIVETRANSMITPORT: This is an object class to represent the transmit port on an active device.
    Alternatively, a small-form factor pluggable (SFP) transceiver could be a child of the active device. The SFP device would be the direct child of the active device, and the common and split ports would be the children of the SFP device.
    — F_SFP: This is an object class to represent the SFP transceiver.
    	— F_SFPCOMMONPORT: This is an object class to represent the SFP common port on the transceiver.
    	— F_SFPSPLITPORT: This is an object class to represent the SFP split port on the transceiver.

  • F_PASSIVEDEVICE: This is an object class to represent a fiber device that is not powered (for example, an optical splitter). They are typically intermediary devices between the source and receiving ends of the signal.

    — F_PASSIVECOMMONPORT: This is an object class to represent the common port on a passive device. It receives the signal.

    — F_PASSIVESPLITPORT: This is an object class to represent the split port on a passive device. After the device splits the signal, it transmits out these split ports. The ports are related “siblings” to the common port.

  • F_SPLITTERDEVICE: This is an object class to represent a splitter. Modeling splitters as object classes is one way to incorporate splitters into your fiber network. Fiber Manager also supports splitters as a feature class sketched on the map.

    IMPORTANT: Wavepoint only support splitters modeled as related objects. It does not support splitters modeled as feature classes. Thus, keep that in mind if you are implementing both Fiber Manager and Wavepoint.

    — F_SPLITTERDEVICEINPUTPORT: This is an object class to represent the input or common port.

    — F_SPLITTERDEVICEOUTPUTPORT: This is an object class to represent the split ports. The ports are related “siblings” to the input port.

  • F_INTERLEAVESPLITTER: This is an object class to represent an optical interleaver, which combines two multiplexed signals into one, but spaces them in an alternating pattern. Although this is a simplistic analogy, it is similar to a zipper, in that a zipper combines the two sides of alternating metal tangs, and then it can be unzipped later back into separate sides. The interleaver accomplishes the same idea, but with optical signals.

    For a diagram, see the help topic Multi Inport Configuration.

    — F_INTERLEAVEINPORT: This is an object class representing the input ports for the interleave splitter. They are attached to the fiber strands.
    	— F_INTERLEAVEINTERNALINPORT: The interleave input ports combine into a single internal input port.
    	— F_INTERLEAVEINTERNALOUTPORT: The internal input port is connected to this internal output port. It is a “sibling” of the internal input port.
    — F_INTERLEAVEOUTPORT: This is an object class representing the output port connected to the internal output port. The interleave output ports are connected to the fiber strands on the opposite side of the interleave splitter.
    — F_INTERLEAVETHROUGHPORTIN: Optical interleavers often have an “express lane” connection that bypasses the interleaving internal ports. This object class represents the input side of that express lane.
    — F_INTERLEAVETHROUGHPORTOUT: This object class represents the output side of the “express lane” connection. It is a “sibling” to the interleave through input port.

  • F_CHASSIS: This is an object class to represent a component chassis. A chassis is a pre-configured arrangement of devices, set together within a modular unit.

    • F_ACTIVEDEVICE: This is an object class to represent a fiber device that is powered (for example, switching equipment).

      — F_ACTIVERECEIVEPORT: This is an object class to represent the receive port on an active device.

      — F_ACTIVETRANSMITPORT: This is an object class to represent the transmit port on an active device.

    • F_DEVICE: This is an object class to represent a fiber device.

      — F_DEVICEPORT: This is an object class to represent the port on a device.

Finally, if your company does not incorporate the idea of racks into the patch location hierarchy, you may use the F_SHELF instead, which is an object class to represent the shelf on which fiber devices sit inside a patch location. And, you could construct patch location favorites with some using racks and other using shelves. It just depends on the facility you are trying to model.

This topic displays a brief summary of the data model hierarchy for a splice point.

A splice point is a place where two or more fiber optic cables are connected. These locations are typically splice enclosures, but they could also be splicing cabinets in a building. Splice points do not contain patch panels or devices, but they can contain related splitter objects. Because splice points are modeled as features, they cannot be placed as a related child object to another feature.

Splice Point: This is a feature class sketched on the map to represent the geographic location of a splice enclosure or a splice cabinet in a building.

• F_SPLITTERDEVICE: This is an optional object class to represent a splitter. Modeling splitters as object classes is one way to incorporate splitters into your fiber network. Fiber Manager also supports splitters as a feature class sketched on the map.

  IMPORTANT: Wavepoint only support splitters modeled as related objects. It does not support splitters modeled as feature classes. Thus, keep that in mind if you are implementing both Fiber Manager and Wavepoint.

  • F_SPLITTERDEVICEINPUTPORT: This is an object class to represent the input or common port.

  • F_SPLITTERDEVICEOUTPUTPORT: This is an object class to represent the split ports. The ports are related “siblings” to the input port.

This topic displays a brief summary of the data model hierarchy for a device point. As covered in the Patch Location topic above, many kinds of devices can be related objects to a patch location. The device point covered below is a feature class device sketched on the map. It is similar to a patch location, but it is simpler. It does not have a rack or shelf apparatus, nor does it have panels or cards. It is simply the device itself and the device’s ports. Examples of these locations include an electric distribution system recloser on a power pole with a SCADA device connected to the fiber optic network. It could also represent a CCTV camera that is monitoring a secure area or a traffic intersection. The concept is that a device is connected to the fiber optic network and defines an end point.

Device Point: This is a feature class sketched on the map to represent the geographic location of a device. This represents a place where fiber optic service is delivered.

• F_DEVICE: This is an object class to represent the physical device located at the site.

  • F_DEVICEPORT: This is an object class to represent the ports on the device. Because this kind of device is an end point, the fiber strands are connected to the ports, and there are no subsequent connections.

This topic displays a brief summary of the data model hierarchy for a splitter location.

As covered in the Patch Location topic, splitters can be related objects to a patch location. Further, as covered in the Splice Point topic, splitters can be related objects to splices.

The splitter location covered below is a feature class splitter sketched on the map. It behaves the same way as a related splitter, but it has a geography and its own feature snapped to a fiber optic cable.  This feature acts in a similar way to a Device Point, with the difference being that these locations always have at least one splitter present.

Splitter Location: This is a feature class sketched on the map to represent the geographic location of a splitter. A splitter is a passive optical device that breaks light into a number of wavelengths to allow several users to utilize a single fiber.  A splitter has one or a few input ports and then a larger number of output ports. For example, a 1 x 8 splitter has 1 input port to accept a single fiber and 8 output ports that can be used to connect 8 customers. Typically, each customer utilizes two wavelengths, one for sending and another for receiving a signal.

• F_SPLITTERINPUTPORT: This is an object class to represent the input or common port.

• F_SPLITTEROUTPUTPORT: This is an object class to represent the split ports. The ports are related “siblings” to the input port.

This topic displays a brief summary of the data model hierarchy for a fiber slack loop.

Slack loops are an essential part of any fiber optic system. These GIS point features represent coils or extra cable at a specific location. These coils are very useful for repairing a cable when it has been damaged or for connecting new fiber optic cables to the network.

Fiber Slack Loop: This is a feature class sketched on the map to represent the geographic location of a slack loop. There are no related objects to this feature class.

This topic displays a brief summary of the data model hierarchy for a fiber fault.

This feature class stores the geographic location of a fault event on a fiber optic cable. Not all faults need to be marked with a fault feature, because some are quickly repaired. There are some cases in which damage to a cable is not so severe that an immediate repair needs to be made. This is a situation where it would be good to store the location of a damaging event so that it can be monitored for future degradation.

Fault locations can be used for tracking warranty issues with fiber optic cables, but these are rare cases. Fiber optic cables are much less likely to fail due to manufacturing issues, compared to underground electrical conductors. Most fault events are the result of an external force such as construction crews digging them up, animals chewing cables, or vandalism. This is not a required object and can be removed from the model if it does not provide value to an organization

Fiber Fault: This is a feature class sketched on the map to represent the geographic location of a fault. There are no related objects to this feature class.

This topic displays a brief summary of the data model hierarchy for a transition point.

A transition point represents a "fake splice" in the network. These features can be used anywhere that there is a significant change in the condition of a fiber optic cable that does not occur at a network junction feature such as a splice or patch location. The two examples of a significant change in condition in the data model are a riser and a demarcation point. A riser symbolizes where a cable transitions from an aerial (overhead) installation to a subterranean (underground) installation. A demarcation point symbolizes where a cable changes ownership. A change in ownership usually occurs within a splice enclosure or a patch panel, but in some instances may occur at boundaries. For example, the boundary between a university's campus and an adjacent neighborhood or the boundary between government offices and contiguous private businesses. This feature provides a flexible way to assign ownership mid-cable without negatively impacting the tracing, reporting or analysis tools in Fiber Manager.

The split operation also creates automatic splice connections at a transition point. These connections are created as straight "pass-through" connections that cannot be edited. The splices are also created as type “Continuous.” This ensures that analysis applications do not “see” them as splices in the network.

Transition Point: This is a feature class sketched on the map to represent the geographic location of the change in type or ownership. There are no related objects to this feature class.

This topic displays a brief summary of the data model hierarchy for a fiber structure.

Fiber structures represent the poles, towers, vaults, etc. that support and house fiber optic facilities. If your company already utilizes electric support features, those can be used for fiber as well.

Fiber Structure: This is a feature class sketched on the map to represent the geographic location of structures. These are then related to the fiber feature classes that are supported by the structures.

This topic displays a brief summary of the data model hierarchy for a fiber connection object

This object table is used to create connections between fibers, ports, device ports, and splitter ports. These objects are represented as the lines that connect objects in the Connection Manager dialog. 

Fiber Connection Object: This is an object class used to store every fiber connection in the network.

This topic displays a brief summary of the data model hierarchy for a circuit.

A circuit represents a "chain of glass" from one location to another. This chain of glass should have a port on either end and strands of fiber in between that are connected end to end.

F_CIRCUIT: This is an object class that keeps tracks of circuits created in the network. The high-level information for the circuit is stored in the F_CIRCUIT table, and the individual components that compose the circuits are stored in the F_CIRCUITCOMPONENT table.

This topic displays a brief summary of the data model hierarchy for a circuit component.

A circuit represents a "chain of glass" from one location to another. This chain of glass should have a port on either end and strands of fiber in between that are connected end to end.

Circuits pass through a variety of cables and ports. This object class keeps tracks of the facilities that compose each circuit.

F_CIRCUITCOMPONENT: This is an object class that keeps tracks of the facilities that compose each circuit. In other words, for every circuit found in the F_CIRCUIT table, the individual pieces are found in the F_CIRCUITCOMPONENT table.

The topics in this section provide additional information about the Fiber Manager data model.