Definition
In voice telecommunications, Least Cost Routing (LCR) is the process of selecting the lowest-cost carrier for outbound (termination) voice traffic for a given route. The same principles apply in SMS routing.
In other words, when we must choose a carrier for a call, we choose the carrier offering the lowest price.
How it works
Short non-technical description
- Price lists (also called rate lists or tariffs) from the carriers (or providers, or vendors) are loaded into a specialized software routing engine. It could be a switch, a softswitch, or external routing software.
- The software converts all carriers’ price lists to the same format. This process is called normalization.
- (Optional) A routing table is precalculated. The best prices for each route are found and prepared for usage. There may be tens of millions of routes.
- When a switch receives a call, a query is sent to the routing engine for routing instructions.
- The routing engine returns the precalculated route, or calculates a route dynamically, and returns it to the switch within a few milliseconds.
- The switch routes the call to the cheapest route first.
- If that route fails, it tries the next cheapest route, and so on until the call is answered or all routes have been tried.
Technical description
Code Range Normalization
Destination codes (prefixes) are not standard across the industry. The carrier–carrier market has no agreed definitions of its destinations. Every carrier uses the International Telecommunication Union E.164 standard for country codes, but they all use different codes for destinations within a country, usually because there are various suppliers within that country. So, for example, one carrier’s codes for Rome may not be the same as another’s. Usually, most codes match, but there can be differences.
As carriers’ price-lists all differ where prefixes for various destinations do not match, it is necessary to make them work together. This process is called normalization. The software converts all the price lists to one format, which is used in the system. Often it is done dynamically, upon generating the routing table.
As an example, here are carriers A and B and some extracts from their price lists.
Prefix | Destination Name | Price | |
Carrier A | 34 | Spain | 0.006 |
Carrier B | 34 | Spain | 0.007 |
Carrier B | 346 | Spain Mobile | 0.02 |
For the number 346XXXXXXX (where X is any number), Carrier B has prefix 346 priced at 0.02 but Carrier A has only prefix 34 priced at 0.006. Under LCR, Carrier A will be selected first for such a call’s route. Such cases are frequent and must be addressed within the LCR engine.
Longest Prefix Match
In the previous example, the system selected the prefix using the longest prefix match rule. This rule states that if there are several prefixes matching the destination number, the longest one will be selected.
As an example, let’s say a carrier has the following price list. (In this first table, we consider the destination number only.)
Prefix | Destination name |
34 | Spain |
346 | Spain Mobile |
34605 | Spain Mobile ORANGE |
If the call is made to number 34605XXXXXXX (where X is any number), it will be routed to the Spain Mobile ORANGE network. It matches all the prefixes in our example price list: 34, 346, and 34605, but the longest matching prefix is selected: 34605.
If the call is made to number 3461XXXXXXXX (where X is any number), it will be routed to Spain Mobile. It matches only two prefixes from our price list: 34 and 346. The longer one (346) is selected, which is Spain Mobile.
Route Cost
Each destination has its cost. Let’s add a price column to the example table and another destination.
Prefix | Destination name | Price |
34 | Spain | 0.0024 |
346 | Spain Mobile | 0.1605 |
34605 | Spain Mobile ORANGE | 0.1605 |
39 | Italy | 0.0018 |
393 | Italy Mobile | 0.2364 |
39373 | Italy Mobile H3G | 0.2364 |
More than one choice for a route
There can be more than one provider for any given destination, and providers’ prices might differ. Let’s add price columns for more route providers.
Prefix | Destination name | Provider #1 price | Provider #2 price | Provider #3 price |
34 | Spain | 0.0024 | 0.0031 | |
346 | Spain Mobile | 0.1605 | 0.1493 | 0.0124 |
34605 | Spain Mobile ORANGE | 0.1605 | 0.1493 | 0.0109 |
39 | Italy | 0.0018 | 0.002 | 0.0019 |
393 | Italy Mobile | 0.2364 | 0.0439 | |
39373 | Italy Mobile H3G | 0.2364 | 0.0329 |
This table shows three differently priced routes to Spain and Italy. Note that not all providers offer all routes. In the example above, Provider #2 does not offer Italy Mobile at all, and Provider #3 does not provide Spain routes, except for mobiles.
Real-life code tables are much larger than this example; they can have more than 100 000 rows. Fast software algorithms are used to find the cheapest route within an affordable period of time, usually about 20 ms.
Summary
LCR is the most widely used algorithm for selecting routes. To work properly it must:
- have up-to-date routing and cost information;
- be fast;
- be able to normalize the various prefixes and build a routing table (dynamically or statically);
- use the longest prefix when selecting the routes;
- return the route choices in the sequence of increasing costs, from cheapest to most expensive.
Least Cost Routing Challenges
Routing table size
When a routing table is precalculated statically and there are many prices in the system, routing tables can require a lot of RAM. This should be taken into consideration when building a system.
With dynamically built routing tables, RAM problems are not so important. This is because routes are not stored in the RAM, but calculated on the fly.
Quality Concerns
The untold truth about LCR is that it can severely diminish the quality of service of a telephony product.
Very often, the cheapest routes do not offer the best quality. But with LCR, these routes are selected first.
This should be considered by monitoring the route quality and removing bad destinations from the route, for reasons of client satisfaction and the longevity of service usage.
Number portability correction
The mobile number portability (MNP) function should be used to properly address ported numbers and correctly find the route to these numbers. Together with MNP information on which network the number is routed to, LCR could be used to find the cheapest route for ported numbers. Without MNP, LCR will try to determine the cheapest route based on the destination number—which will be wrong. This often leads to a higher route price.
LCR Time Periods
Sometimes there is a demand to change LCR for different time periods. This can be related to better prices being on offer at different times of the day. In VoIP wholesale, this practice is diminishing but keep such possibilities in mind.
Limited Capacity
Very often in the VoIP wholesale business, a specific route has its own capacity. In such cases, only X channels (simultaneous calls) can be sent over for this particular destination to this provider. If more channels are sent, the calls above the limit are dropped with an error code. The LCR engine should be aware of capacity limits and the routing table should be built after removing the routes which are at their limit, to avoid spamming and overloading the route carriers.
LCR Cherry-picking
This is an unethical technique to find an error in a carrier’s price list and exploit it.
This happens when Carrier A’s team finds that Carrier B defines a code range as being fixed-line (and thus cheap), while Carrier A defines the same code range as mobile (and more expensive). Carrier A will send that range to Carrier B and will pay a low fixed-line rate while charging at a high mobile rate, making much more profit. Carrier B will sustain losses if it does not notice that its supplier, C, also defines that range as belonging to a mobile operator and charges a higher rate. Caught in the middle, B can quickly suffer large losses. A credit limit helps in such cases, to block the traffic when it reaches some threshold.
- Photo by Martin Reisch on Unsplash