Modeling Routing Networks

Routing networks are an additional way to model transportation networks.

Note: The term Network is generally used throughout OTM when referring to routing networks. However, since network can also refer to transportation networks, computer networks and so on, for clarity, it is referred to here as Routing Network.

A single routing network can be used to model an entire transportation network. You do not have to enumerate all of the possible paths through the network.

A routing network consists mainly of a set of network legs that defines the transportation network. A network leg is very similar to an itinerary leg in that it describes how to get from one place to another in a single shipment.

In our example, a single routing network would be set up with nine network legs. You would create the network legs in order to define how a shipment can be planned from one place to another, but the network routing logic would determine how to plan multiple shipments through the routing network to get an order from its source to its destination. Here is a link for the example.

Routing Networks and Itineraries

Network routing in OTM requires the use of an itinerary. Orders match to itineraries based on the itinerary lanes. The routing network goes onto an itinerary leg. The routing network consists of network legs, which are different from itinerary legs.

An itinerary has one or more itinerary legs.
An itinerary leg can have a routing network.
A routing network has one or more network legs.

An itinerary that has a network on one itinerary leg can have other itinerary legs, and can have more than one itinerary leg with a routing network. This is described in Routing Networks in Multi-Leg Itineraries.

An order that matches to an itinerary and has a leg with a routing network can be planned through that network. Within a routing network, leg-level constraints are defined on the network legs, so the leg-level constraints on an itinerary leg are ignored when this itinerary leg has a routing network. (These constraints include, for example, Rate Offering ID, Service Provider Profile ID, Equipment Group Profile ID, and so on).

Different itineraries can share the same itinerary leg (and thus can share the same routing network if this itinerary leg has one). Also, different itinerary legs can share the same routing network, but this is not recommended if both itinerary legs are going to be used within the same planning scenario, as the logic will not treat them as the same network. Instead, the recommended approach is to use the same itinerary leg on different itineraries.

Network Manager

A routing network is defined in the Network Manager, but this manager is used only to define the network ID and name, and high-level parameters. A grid for the network legs potentially would be too unwieldy, and a separate Network Detail Manager defining the network legs on a network allows use of the finder as a search mechanism.

Network Detail Manager

The Network Detail Manager allows you to define which network legs are on which routing networks. The manager itself only defines the association between routing network and network leg, and whether the network leg is active in this network. (The network leg must be active for the network routing logic to consider this leg when routing orders.)

The Network Detail finder, however, allows you to search for legs, and to list all the legs in a routing network.

Routing Network - Network Leg

Network legs are the real substance of the routing network. The network leg is very similar to an itinerary leg. The network leg, however, is defined differently, and so has a different network leg manager.

Geography

The most important aspect of a network leg is that it defines transportation from one place to another. While an itinerary leg defines only a destination location (or set of locations), if any, a network leg has a more specific geography. The network leg must have a source (location or region) and a destination (location or region).

Location: If a network leg has a source or destination location, this location is treated as a throughpoint. An example of a throughpoint is a cross dock or pool or rail ramp. If the network leg has a source or destination throughpoint location, it must also specify the location role to be used. (These location roles are set up on the location; in the network leg, one of these location roles is selected for use in the network).

Note: OTM planning can handle cases where a location is sometimes a throughpoint and sometimes an order's source/destination location; for example, an order that originates at the cross-dock.

Region: A leg with a source region can only be used for an order to enter the network, and a leg with a destination region can only be used for an order to exit the network. A region cannot be used as an intermediate throughpoint within the network. However, an order can start or end at a throughpoint.

The reason for this use of region and location is that a typical scenario will involve many more order source and destination locations than throughpoints. Setting up legs for each source and destination location would be far too unwieldy. On the other hand, defining legs for each throughpoint location (e.g., cross dock or pool) provides control over how the throughpoints are to be used, and better defines the routing problem to make the solution easier.

A region can consist of a single location. In the IL-OH example, there are two geographically separate source distribution center locations, and in the network, these are set up as single-location regions.

Geographically, there are four kinds of network legs (see the Il-OH example):

Region - Region: For example, the "IO-CHI-NE OHIO" leg. This type of leg takes an order from its source to its destination.
Region - Location: For example, the "IO-CHI-IND" leg. This type of leg takes an order from its source to a throughpoint.
Location - Region: For example, the "IO-IND-NE OHIO" leg. This type of leg takes an order from a throughpoint to its destination.
Location - Location: For example, the "IO-IND-CUY" leg. This type of leg takes an order from one throughpoint to another.

Network Leg Manager

The Network Leg Manager is similar but not identical to the Itinerary Leg Manager. The main difference is a network leg has both a source and a destination. However, like the itinerary leg, the network leg has various constraints (such as Rate Offering ID, Service Provider Profile ID, Equipment Group Profile ID, etc) that constrain how an order may be planned along that leg.

As with itinerary legs, an "Expected Cost" and/or "Expected Service Time" can be used if the "Calculate Contracted Rate" and/or "Calculate Service Time" flags are set. These fields are also used within Expected Cost Leg Options.

Routing Network - Regions

Regions are used within routing networks because in real scenarios, there will be many more order source or destination locations than throughpoints, and because it would be unwieldy to have to define network legs for each of these locations.

Note: Only regions defined on the network legs are relevant. Other regions defined for other uses are not used by network routing.

Regions should be designed with the following points in mind:

Regions Indicate Consolidation Opportunities: The regions are also used to indicate to the logic that locations within this region can be consolidated onto multi-stop shipments (if there are equipment-based rates). OTM planning can still consolidate locations from different regions onto the same multi-stop shipment when using network routing, but the order routing logic (in contrast with the subsequent shipment building logic) will consider primarily the possible consolidation of orders originating out of or delivering into the same region.

Use of Regions Reduce Run-Time for Rating the Network: For rating the network, network routing calls the rating engine for each of the network legs in order to determine the cost of using this leg. It should normally be unnecessary to rate from every source location and to every destination location in order to make routing decisions (in contrast with actually building the shipments). Instead, OTM will rate to and from each region, and thus reduce the run-time required to find rates for the network.

Note: An order source location must fall within some network leg source region in order for network routing to plan the order through the network. The same is true for destinations.

Representative Locations

As discussed in this last point, network routing will find rates to and from each region. The rating engine actually needs locations in order to produce rating results. When considering a region, it will need an actual location to represent that region in the rating logic. Therefore, these regions defined for network legs will each need to have a Representative Location. When rating the network, the logic will use this representative location as a stand-in for the region. Thus, when defining the region, some thought should be given to the proper representative location. The following points should be considered:

Geography: The representative location ought to be geographically within the region, and perhaps close to the center point (or close to the area of the region where most of the orders have their sources or destinations). Regions that are too large will not allow the network routing logic to distinguish among different locations whose orders ought to be routed in different ways.
Rating: The representative location must be ratable. That is, the rates that are desired for this region should be applicable to the representative location. Otherwise, these rates will not be considered when the logic rates the network.

You can check the "Ignore Representative Location" field on the relevant source/destination leg. See also "Use of Representative Location" in Bulk Plan Network Routing.

Network Routing Works without Routing Networks

This topic covers modelling routing networks, but note that network routing can be used even if no routing networks are set up, and the transportation network is modeled simply with multi-leg itineraries.

Multi-leg Itineraries are supported. As explained in Routing Networks in Multi-leg Itineraries, network routing matches orders to itineraries, and then creates a representation of the transportation network based on those itineraries. If the itineraries contain a routing network, then OTM will use the routing network when creating this representation. However, OTM will also use itinerary legs with no networks when creating the representation.

Pool-crossdock Itineraries are not supported. Network routing will not use the cross docks and pools defined for a pool-crossdock itinerary. A pool-crossdock itinerary set up to model a transportation network with cross docks and/or pools cannot be used with network routing. If the scenario is to be used with network routing, it should be set up using a routing network (or perhaps less usefully a set of different itineraries).

Re-use Equipment and Re-use Service Provider. constraints are not supported. Currently, network routing does not honor these constraints on the itinerary leg.

If orders start or end on an itinerary leg without a routing network, then there are no region-based network legs to indicate which regions are to be used for rating the network. A new network routing parameter is provided to allow you to define regions to be used by network routing for rating the network. The parameter is ROUTING REGION GROUP GID. A region group is a set of regions, and the regions in this set are the ones to be used for rating the network.

If there are order locations that do not fall within the regions in this group, then these locations are treated as little individual regions for the purposes of rating the network. So if an order has a source or destination location that is not contained by one of these regions, the network routing logic will still be able to plan this order through these itineraries.

Order Movements

Order movements are an important part of order release planning within network routing. They are an important part of the shipment creation process.

See Network Routing and Order Movements for details.