Googlization marches on

Googlization marches on

By Alexander Harrowell

The trend towards modular infrastructure, virtualization, and service-oriented architecture is underway, with or without IMS.

One of the biggest hopes for IMS has been that it could generate a big cut in the cost of telco infrastructure by transferring functions from hardware into software. That would mean that, rather than a small of large, expensive, and task-specific machines; operators could run the software on a large number of cheap, general-purpose IT machines.

Techniques like distributed processing an virtualization mean that very high volume, high availability computing tasks can now be spread over arbitrarily large number of servers, which no longer need to be rated for carrier-grade reliability if the system can failover without end-user noticing anything. Therefore, they can be dramatically cheaper, and the system can be dramatically easier to scale up or down.

The undisputed master of these techniques is Google, a company built essentially on two things, one well-know and one rather less well-know. Everyone has heard of the pageRank search algorithm Sergey Brin invented as a graduate student at Stanford, but the Google Platform, as the firm terms its IT infrastructure, is less famous.

As the search engine grew, its infrastructure needs exploded. The cope with this, the Google engineers adopted a dramatic, new policy-rather that installing big, specialized servers, they instead used very large number of PC-based boxed, mostly home-made.

To stitch them together, they made a major development effort to virtualize their search applications, so that they could run concurrently across many machines and tolerate failures. When a server failed, it would be left in the rack until the system administrator did a regular round of the data center. The other machines grouped under its logical location would preserve state so that the application would continue to run.

Related techniques have been used to improve the internet’s reliability since a massive distributed denial-of-service attack on the rootzone DNS servers in 2002. When a similar attack was stages this year, the system shrugged it off without difficulty, which should come as no surprise. After all, f.root-servers.net now refers to any one of 32 logical machines scattered around the world, some of which are themselves multiple load-balanced physical computers. Using the IP Anycast technique defined in RFC1546, when a request to F root is made, the first of the 32 machines to answer handles it.

The only root servers to suffer degradation of service during the 2007 root DDOS event were those operated by the US Department of Defence and ICANN, neither of which are anycasted.

So-what does Googlization mean for telcos? The technical elements required are required are essentially that everything possible should be implements in software, that independent functions should be autonomous modules, that in the interface between them must be standardized, and that layers should be distinct. For example, routing should no be coupled with application-level processing, and databases should not be specifically coupled to routing.

This is very similar to requirements of another current IT trend, service –oriented architecture. SOA requires that business processes be broken down into specific services, mutually independent, with standardized interfaces and some form of middleware so that applications can be created by assembling existing service components at a high level.

In fast, doing SOA will usually require something similar to Googlization, and Googlization your infrastructure will, by definition, be a good moments to implement SOA. IMS has often been described as an enabling technology for the first, and as a telecoms SOA in itself. But is it really so important?

Going by actual products and deployments, no so much. Where these principles are being put in practice, IMS tends to take a beck seat. There’s no reason, for example, why different functions in an SMSC cannot be disaggregated, so long as they have a common interface with each other and the network entities. It doesn’t need IMS, either. After all, even if you are using SS7, SS7 messages can be carried over IP, and the function only needs to speak SS7 to other devices that explicitly require it.”

Hence, products like Airwide Solutions’ AirMessenger Store. Very simply, it’s a big storage tank for SMS messages in transit, uncoupled from the SMS routing function. It’s the uncoupling, though, not the storage, that is interesting. Now, a carrier can install more SMS delivery capacity without also installing more storage, which depending on the efficiency of their network they may not need. Or, of course, they could install more storage, without more delivery capacity.

“One alternative would be to go out and buy a new SMSC”, says Jay Seaton, CMO of Airwide. “But that’s overkill, because it includes a lot of storage. And this is a product an operator can buy whether they’re an existing Airwide, Comverse or whatever customer or not”.

Disaggregation means adaptability. But it still doesn’t require IMS. According to Seaton, “it’s consistent with the IMS architecture, but we wouldn’t say more than that. It’s too fixed-line-the problem with IMS, our customers say, is that it isn’t actionable in terms of mobile infrastructure”.

“It’s a practical step towards IMS and OMA, but no more,” he said. Like other Airwide SMS products, it supports SMPP over IP, so it could be implemented as part of an IP-based service delivery platform in a non-IMS network.