Virtually every communications service provider on the planet is engaged (at some level) in a transition from a legacy TDM circuit-switch network built on TCAP and ISUP signaling to a next-generation multi-service core based on SIP and DIAMETER signaling.  As an industry, we’ve been making slow but patient progress in this transition for the past 15 years but we’re still just at the early stages of the process.  The transition from TDM to SIP has become more of a journey than a destination.  The goal of this blog is to fully explore two crucial aspects of this journey – specifically the role that centralized-routing and centralized-database services play in the core of the next-generation network.  Content for this blog will come from a combination of my personal experience as Founder of NetNumber and from a group of guest authors from around the communications world.  In this first posting I will lead-off with trying to answer the following essential question:

Why should I invest the time and money to implement a centralized-routing and database services engine into my next-generation network?”

Let’s start by looking at the legacy that we’ve inherited as an industry. Over the past 100 years our network deployment model has been to distribute both routing-instructions and subscriber-information out to the edge of the network in the form of “in-switch” routing and subscriber data.  There are of course exceptions to every rule but in general, networks have been designed with a routing-database and subscriber-database in every switch in the network.  Consider the following typical example:

In the TDM network, when a user on a given switch dials a number the originating switch first checks its own local subscriber database to determine if the destination user is served on the local switch.  If not, the switch checks its own local routing database to determine how to route the call to the next-hop.  The next-hop switch follows the same logic using its own in-switch routing database until the call reaches the destination switch that serves the subscriber. 

This model of hop-by-hop routing has been working for decades and it enabled the TDM network to span the globe.  Given the success of this legacy “in-switch” model, why should we consider changing to a centralized-routing model in the next-generation network?  I’ve encountered four powerful and compelling arguments that make the decision obvious.

  1. Operating Cost Savings:  Centralized-routing allows all routing instructions and subscriber profiles to be provisioned and managed via a single logical system in the network.  As a result, the network operations team and business support team only need to learn one provisioning method and one routing engine architecture to support any number of network elements.  By comparison, the old “in-switch” model required the operations and business support teams to learn a different routing model for every type of switch in the network and every vendor in the network.  The long term cost savings of centralized routing are both significant and permanent in the next generation network.
  2. Vendor independence:  Integrating a new network platform (SBC, MGC, AS, xCSCF, SMSC, MMSC, Softswitch, etc.) into the network is greatly simplified by removing the routing-database and subscriber database component from each network element.  In a centralized-routing environment each network element simply selects a standard protocol to access its routing instructions (AIN, CAP, ENUM, INAP, MAP, SIP, WIN, etc.).  As a result, carriers/operators can quickly and efficiently introduce new network elements and new vendors into the network with minimum increase in operational costs.
  3. Faster deployment of new services:  Centralized-routing empowers a carrier/operator to implement new value added services by changing service-logic in just one logical location.  No need to schedule upgrades to every network element to deliver a new value added service.  This concept was first introduced into the SS7/C7 network with the delivery of SCP (service control points) and it has been perfected in the next-generation network through use of centralized routing and database services.
  4. Real time routing updates:  Routing changes are provisioned in one spot in the network and are made available in real-time to any number of distributed network elements via any number of standard query protocols.  By comparison, the old in-switch routing model required a laborious process of updating every switch in the network in an organized fashion.  Roll-back was equally tedious and fraught with risk.

Despite the obvious elegance of a centralized routing architecture, many customers find it difficult to break away from the long history of provisioning a separate in-switch routing database for each switch in the network.  Using an “in-switch” routing engine seems simple at first but it leads to a network where cost and complexity grow with the deployment of every new network element.  On top of that, as networks converge and new services are introduced, it becomes apparent that many in-switch routing engines contain functional limitations that hamper growth.  The challenge of growth in the “in-switch” routing model is higher-operating cost and slower deployment of services.  By comparison, the reward of migrating to centralized-routing is lower operating costs and faster deployment of new services.

The NetNumber team has found that the transition from “in-switch” routing to “centralized-routing” typically takes place over a period of time.  The migration from TDM to SIP services is providing carriers and operators with the perfect opportunity to grow into the new centralized routing architecture.  The NetNumber team has been working with carriers and operators for the past 13 years to help facilitate this transition through the delivery of a multi-protocol, multi-service, centralized routing application called TITAN.  I’ll use real world use—cases from TITAN deployments as a mechanism for exploring how different operators are making use of a CRF or Centralized Routing Function.

Below is a diagram that shows one use-case example of how the NetNumber TITAN is commonly deployed to fulfill the role of a multi-protocol CRF in a converted TDM and SIP network.  TITAN is a widely deployed example of a centralized routing engine so it offers us a large set of real-world use cases that we can leverage to fully explore this subject in detail.  I’ll refer back to this high-level architecture in future posts to this blog when I discuss real-world use-cases.

TITAN Architecture

In summary, practical carrier/operator experience has shown that there are four compelling reasons to include a centralized routing function (CRF) in the next-generation network (Operational Cost Savings, Vendor Independence, Faster Deployment of New Services and Real-Time Routing Updates).  Although the high-level benefits are obviously compelling the process of moving an industry from 100-years of “in-switch routing” to “centralized routing” is likely to take an extended time to complete but the journey is well underway.

Let’s try to make progress every day.  Thanks for your time.  More to come – DJR

Categories: Blog


Leave a Reply

Your email address will not be published. Required fields are marked *