Common design failures

A guide to understanding and resolving errors in your design

Network design is complex and you may encounter scenarios where FOND cannot generate a solution.  This is most commonly due to an issue in the architecture configuration or the input data, or a combination of both. 

This article provides an overview of the error reporting functionality within FOND, as well as details on the most common design error types.

Error reporting in FOND

Errors in FOND are assigned a code, label, summary, and description in order to provide the information that you need in order to understand and resolve the problem. 

Where possible, there will be geospatial features available on the map to point you to the source of the problem. 

In this example, the error is an address that requires 300 fibers, which is too large for any of the cables in the architecture to service. By opening the feature inspector and zooming to the location of the error, we can identify the address quickly.

Please note that not all errors in FOND have a code and description yet. We're continuously working on building out the error library to cover as many scenarios as possible. When an error hasn't yet been configured, or does not yet have a code, you may see something like this:

In these cases, we still have some general guidelines on common errors below to help you along.

21201 - Cables too small

Distribution stage

Often this happens when there is a single address with a fiber allocation ("Number of fibers") higher than the capacity of a drop hub. FOND accounts for this by placing a Drop Dedicated Hub, but a design failure will occur if it finds that there are no distribution cables with enough fiber to serve it.

This can also occur if the largest Drop hub in your architecture requires more fibers than your distribution cable contains.

Example: A single address requires 300 fibers to feed it. FOND places a dedicated drop hub which requires 75 distribution fibers, accounting for a 1:4 split at the drop hub. However, the largest available distribution cable only has 72 fibers. The solution would be to add a larger distribution cable, or to investigate other ways to control fiber allocation in FOND so that you can utilize smaller cable sizes with unsplit fibers.

Feeder stage

Similar to the error at the Distribution step, you may have a distribution hub that requires more fiber than the feeder cable sizes available within your architecture can deliver. As a result, you might need to provide larger feeder cable sizes.

10403 - Cables too small (connectorized)

This error is closely related to 21201 - Cables too small, but is specific to a connectorized architecture.

Often this happens when there is a single address with a fiber allocation ("Number of fibers") higher than the capacity of a drop hub. FOND accounts for this by placing a Drop Dedicated Hub, but a design failure will occur if it finds that there are no tail cables with enough fiber to serve it.

This can also occur if the largest Drop hub in your architecture requires more fibers than your largest tail cable contains.

Example: The architecture below contains 12-port drop hubs with no splitters. This means that a 12 port hub requires up to 12 fibers to feed it (depending on how many addresses it serves), but there is no tail cable large enough to do so. The solution would be to add a 12f tail to the architecture, or to remove the 12-port drop hub.

21203 - Hubs too small

This error occurs when there is a demand which is too large for any single hub to service.

Insufficient split ports

This occurs with the error:

Invalid architecture: found demand with `split` requirement of X, 
but largest hub has `split` capacity Y.

In this case you likely have an address in the input data which requires more split fibers than there are split ports available at the distribution hubs.

Example:  In the project below there is an address requiring 33 split fibers. However, in the architecture settings for the Distribution tier, the largest available distribution hub has 32 split ports available. The solution would be to either increase the port count of the Distribution hubs, decrease the fiber count of the address point, or to convert the address point into one which requires unsplit fiber instead.

Example:  In an alternative example, the address requires only 30 split fibers. However, each Distribution hub requires 4ports to be left spare, which means that only 28 are available. In addition to the solutions described above, you may also choose to decrease the spare port requirement.

Insufficient unsplit ports

This occurs in the Distribution stage with the error:

Invalid architecture: found demand with `express` requirement of X, 
but largest hub has `express` capacity Y

In this case you likely have an address in the input data which requires more unsplit fibers (read more about fiber allocation here) than there are unsplit ports available at the distribution hubs.

Example:  In the project below there is an address requiring one unsplit fiber. However, in the architecture settings for the Distribution tier, there are no unsplit ports available at the Distribution hubs. The solution would be to increase the unsplit port count.

21204 - Too much demand

Feeder stage

The most common feeder design failure happens when FOND needs to use more ports at the feeder hub than is allowed in the architecture, as defined by the Feeder hub demand counts. 

Read Feeder tier settings for more information about how the Feeder hub demand count determines the number of available OLT ports. Keep in mind that underutilized drop and distribution hubs will increase the requirement for feeder ports, and consequently it is possible to utilize all of the feeder ports but serve far fewer than the theoretical maximum number of addresses.

You could fix this by either,

• Increasing the Feeder hub demand count, or
• Adding more Central Offices to the input data, or
• Removing your central offices and allow FOND to determine how many to place.

21205 - Ownership constraint

The Distribution design does not allow Distribution cables to utilize the same path as a Drop cable that originates from a different Distribution hub. Use the feature inspector to locate the source of the problem and adjust (or reset) your moved hubs.

Example: Distribution hub #2 has been moved by the user via the "move hubs" function in FOND. It has been moved onto the "footprint" (AKA service area) of a drop hub which happened to be served by Distribution hub #1. This violates the ownership constraint which underpins the network design model. The solution would be to move Distribution hub #2 to an alternative and valid location, or to simply reset move hubs in order to revert back to the previous design.

21206 - Clustered demand

This generally occurs during the Distribution stage when there are many addresses served by the same point in the network, resulting in many colocated drop hubs. As a result, a single distribution hub does not have sufficient capacity (as defined by "Hub port counts") for all of them.

Example: A housing development on the southwest is missing street data, resulting in a large number of addresses being served from only a few points on the underground network.

One solution is to draw in the missing underground path.

If you do not wish to design this area, but need to ensure sufficient fiber is left for a future expansion, you might instead replace the many address points with a single address with a higher fiber allocation. In this case there were 141 addresses. At a 1:32 split ratio, 5 unsplit fibers is sufficient to service the development in future. See How to control fiber allocation in FOND for more information.

23201 - Clustered demand (connectorized)

This occurs during the Distribution stage of a connectorized architecture when there are many addresses served by the same point in the network, resulting in many colocated drop hubs. As a result, a single distribution hub or splice would need to use more that the maximum "Number of tails per splice" to serve all of the drop hubs at that location (connectorized architectures only).

Refer to 21206 - Clustered demand for suggested solutions.

22301 - Hub capacity constraint

The infeasibility is caused by the network model being unable to simultaneously:

• Satisfy the constraints that every demand is served by a hub

• Satisfy that the total amount of demand served by a hub is not greater than the hub capacity

As a result, at least one hub would need to exceed its capacity in order to produce solution that serves all of the demand in the design.

This generally only occurs when moving hubs.

To fix: Try reverting your previous hub move, or resetting all moved hubs.

31301 - Infeasible model

Infeasible models occur when FOND cannot simultaneously satisfy all of the constraints that are enforced in the network design model. Constraints are unbreakable rules like:

• Every demand is served by a hub
• The total amount of demand served by a hub is not greater than the hub capacity
• ...

An infeasible model can indicate a range of design error types. Where possible, we have identified specific causes of infeasible models and assigned unique error codes to them Some examples are 21206 - Clustered demand, 21205 - Ownership constraint, and 22301 - Hub capacity constraint.

If you encounter an infeasible model and are not sure why, contact the support team for help.

20301 - Timeout

When the network complexity is very high, it can take a long time for FOND to find a solution and it may hit a hard time limit in the process. In these scenarios, the best way forward is to reduce the complexity of the problem. Usually the cause is a large amount of underground or aerial data, and possible solutions are:

• Remove service roads or any other data that doesn't need to be considered for fiber path
• If using dual sided, consider reverting back to street centerlines
• Split the design into two or more smaller projects

Example: Service roads in parking lots can generally be removed from the network. If using Area Select/OpenStreetMap data, identify service roads by highway=service (keeping in mind that some service roads may still be valuable candidates for fiber path).

Errors during "Analyzing the problem"

Unexpected value

A failure or stall at ‘Analyzing the problem’ indicates an issue in the processing of the input data. Most commonly, one of your input data layers contains an unexpected value. This will only happen if you upload your own data (as opposed to using Area Select), and if the field is one that FOND recognizes and tries to process, such as Type in the addresses layer, or Status in the underground or aerial span layers. 

Example: The first underground path feature would cause a design failure because FOND expects Status to be one of NEW or EXISTING.

Unexpected type

Another possibility is that the uploaded data contains a field that FOND recognizes, but in a different data format.

Example: The CostFactor field is configured as a String when FOND expects a Float (decimal/real number).

Errors during "Creating splice tables"

Too much flow for cable size

This can occur if you have Daisy chaining enabled, but some of your tail cable sizes are too low to allow for chaining of hubs.

The daisy chain model performs best if you remove smaller tail sizes from the architecture, anticipating that larger tails are required to chain multiple drop hubs together.

Example: The architecture below contains 4-port drop hubs with no split. Every drop hub will therefore require up to four fibers to feed it (depending on how many addresses the hub is serving). With daisy chaining enabled, it is important to consider the maximum number of hubs that you'd like to see connected in a single chain. For chains of up to three hubs, 12f tails would be recommended.