![]() |
© 2022 Black Swan Telecom Journal | • | protecting and growing a robust communications business | • a service of | ![]() |
![]() |
Email a colleague |
June 2011
VoIP is one of telecom’s greatest success stories. As one of Vonage’s 3 million U.S. customers, I’ve noticed that its voice quality has steadily improved over the years to the point where it’s now as good as my landline.
Yet a decade ago people doubted you could affordably deliver good voice quality from of a best-effort IP network. So what’s spelled the difference?
Network engineering innovation has certainly been key, but an equally important factor is something often overlooked: the highly competitive wholesale telecom market that we have, particularly in the U.S. Think about it. As an over-the-top VoIP retailer, Vonage has no little to no direct engineering control over the networks its traffic rides on. But what Vonage does have is purchasing power. And that purchasing power makes up for any lack of network engineers.
By using their purchasing power to route traffic, VoIP retailers reward the wholesale suppliers who deliver traffic at the right quality and price points. The suppliers who can’t deliver exit the business. And over time, the quality/price point of the whole market is raised.
But the market only works if VoIP retailers have full access to the latest prices and can measure QoS. And that’s where Global Convergence Solutions (GCS) comes in. GCS is in the business of automating LCR (least-cost routing) — or at least what used to be called least-cost routing.
GCS has been flying under the radar for several years now, but it’s nevertheless amassed impressive customers such as Vonage, KDDI and One Communications. The company recently debuted at the B/OSS Live! show where I ran into GCS CEO Neal Axelrad, who strikes me as more of an engineer who got bumped upstairs than a guy content to sit behind a mahogany desk. In the interview that follows, Neal does a great job of demystifying the art of what GCS calls dynamic route management or next-generation LCR.
Dan Baker: Neal, before we get into the technology, I think people would like to get an idea about the origins of GCS. How did you get to where you are today? |
Neal Axelrad: Sure, Dan. Ninety percent of the guys who staff GCS came from ITXC, a pioneer VoIP carrier which grew to be the largest wholesaler — a $400 million company until the dotcom bubble burst. And the people there built all the OSS/BSS toolsets in-house.
ITXC was eventually sold off to TeleGlobe which now belongs to Tata Teleservices. My partner, Jay Meranchik, and I went from there to Infiniroute where we again built the OSS/BSS and did PSTN/IN conversion and interworking of Sprint, AT&T, Bell Canada, and BT and basically helped them communicate via the SIP protocol. It was one of the first peering exchanges. That company was sold and TNS now owns them. In 2006, Jay and I broke away to form GCS. We took no venture funding because we could find plenty of professional-services work building VoIP OSS/BSS to keep us busy while we developed our product.
First things first, how does your system feed the routing instructions to the switches? |
Well, let me explain how it’s done using SIP because that’s the way the world is going. Of course, you can also accomplish the same objective in SS7 for PSTN calls.
In the SIP world, there’s a messaging header in the SIP protocol, the 300 series, that allows the softswitch to interrogate a server for routing instructions. Now that’s important because to set up a rich policy requires setting up several million codes. Even the latest softswitches don’t have the capacity to store and retrieve such a large database of codes during the small window of call-setup. So the server searches for the precise routing instructions and returns that back to the softswitch in a few microseconds.
In traditional Least Cost Routing, the engineers use policies to instruct the system to, say, reduce the number of network hops for a particular call, right? |
Dan, the same principle is in play, it’s just the decision making has become real-time. Let me give you an example. Let’s say you have 10 supplier choices to route traffic to for a particular call. The first one on the list costs you 10 cents, the second 9 cents, and so forth.
We first apply general business policies like “I never want to route calls under water,“ or “I expect at least X quality.” But you also have policies specific to a vendor, say, “to route through vendor ABC, I want a margin of at least Y.“ And when you run those rules, it narrows down your choices from the original 10 vendors to three.
OK, when the call comes through, it redirects back to the server to get route instructions. And it’s here where you start applying rules based on the current state of the network. For instance, what happened to the last call I routed this way? Did the last call go through or did I get a 503 response? There are several VoIP performance metrics we can monitor in to keep track of quality such as PDD (Post Dialing Delay) and the ABR (Answered Bid Ratio — answered calls divided by attempted calls).
Let’s say I’m a prepaid calling card provider and my customer’s call doesn’t complete a couple times. Well, because we understand who the originator and terminator is, we can set our parameters to say, “If the same customer makes a call within 20 seconds to the same number, route it to the second most preferred route.“ There are literally hundreds of options like this in the system. So this gives the operator tons of flexibility and reporting options to work with.
What skill sets did you need to pull together to get to an integrated solution? |
Well, certainly our decade of experience building OSS/BSS solutions leveraging SIP is the cornerstone of everything. There’s also a great deal of data to synchronize. You also need to integrate all the rate addendums — the constantly changing price lists coming in from all your wholesale suppliers.
Then there’s the network mapping and telephone number analysis you need to do: You need an up-to-date understanding of jurisdictional data, Local Number Portability (LNP), and Mobile Number Portability (MNP). And remember, the environment is changing non-stop.
ENUM, the standard that allows you to translate telephone number into a URL, is a challenge to get right, but its benefit is enormous. By dipping into an ENUM database, you may be able find another carrier you can peer with on a no-tariff basis.
Finally, you need to keep up with the network elements. Every time a new version of a softswitch comes out, there are so many changes that it’s like you have a new switch to interface with. So to keep up, you need to do the background work on supporting different versions. A good 20 percent of the work we do is around interfacing to new network element versions.
Neal, how do you handle the addendums? It sounds a lot like intercarrier invoices where you have dozens of different formats to translate. |
Telarix actually pioneered the business of uploading the rate addendums. We have a similar capability. We use templates to parse the incoming electronic files. It would be nice to have a common standard that everybody follows, but with our template-driven application, we can bring in an addendum from any type of carrier and load it in with one mouse click.
Auto-loading eliminates the tedious task of managing thousands of codes in home-grown parsing scripts. Typically, once each addendum is loaded, the rating team then makes decisions based on the new prices. Of course, when you automate all that, it allows an operator to bring in more and more suppliers without placing any additional burden on the rating team which is what we do.
How do you actually deliver your solution? |
We deliver our solution in either a traditional license model or a SaaS-based delivery model and try to make it an easy transition. They can also purchase capacity from us, cloud or no cloud: It all depends on the carrier’s needs.
A year ago, no one would take signaling out of their network and put that information outside their firewall. Then we found out something important: big carriers don’t want to spend money on CAPEX anymore and that makes our SaaS option very attractive.
Is there a practical limit on the number of interconnect partners you should have? |
Not anymore. I remember years ago at Verizon the goal was to pare down the interconnects [mostly TDM] because of the OPEX required for each partner. So they calculated a number of $25,000 of net traffic a year. If you didn’t reach that volume, it wasn’t worth the interconnect expense.
Today it’s an entirely different story. When you connect via SIP, you’re sharing ports and not wasting capacity. So you might as well send traffic to the place that has the best quality and price. Over time, your infrastructure price points and LCR support costs decline significantly, so that allows you connect to more partners. It becomes a self-fulfilling prophecy.
I know guys who have 400 carriers they interconnect with. The bigger constraint these days is managing your contracts and checking your interconnect invoices for accuracy. It’s the lack of efficiency in those areas that sets the limit on the number of partners, not the network.
Finally, Neal, what’s the sweet spot in the market for these dynamic routing solutions? |
Any carrier that has more than three suppliers that they interconnect with needs a solution like ours. That pretty much means every carrier in the world. Additionally, if you are merging with another company, you definitely need this! You have multiple network architectures and you need to understand how to use that network so you can exploit your on-net resources.
This article first appeared in Billing and OSS World.
Copyright 2011 Black Swan Telecom Journal