Archive

Posts Tagged ‘telecom time to market’

The intelligent network is death, welcome the dumb network!

November 30, 2010 Leave a comment

SS7 networks or “intelligent networks” have been the core reason why network-based services can not be rolled-out quickly. Specialized skills are needed to launch a new SS7 service.

Currently operators are investing in service delivery platforms or SDPs to move the network intelligence out of SS7. These SDPs will be holding modern copies of the SS7 services.

However do we need intelligent networks? Why can’t we have dumb networks?

The Internet is a dumb TCP/IP network. Intelligence is not in the network but in the applications that run on top of it. Why are telecom networks different? Why do routers have to know if the application is voice, SMS or data? Why does the network have to know about conferencing, numbering plans, etc.?

One example: MSISDN

Why do you want to hard-code an end-user identifier throughout your network & billing systems? Why can’t we have a mechanism like a unique IP address and several DNS names for it. I don’t want to learn a long list of digits to identify a friend. I would like to control my own numbering plan. My direct family starts with 1xx. My friends 2xx. Alternatively I can use their email. I should be able to call a company with its DNS. Ideally I can use the Facebook or Twitter id as well. This would all be possible provided that an internal identifier would be mapped to an end-user identifier instead of using one unique identifier.

Example two: CDRs

Why should every network element know that for every call you need to generate a CDR. However for data, charging is not based on seconds or minutes but data volume? Cannot the metering be done outside the network? Why are we generating millions of CDRs when end-users have a flat-rate or are calling a free number? With software-as-a-service metering can be different per application (pay per GB of storage, per MB of network traffic, per user per month, per company per year, etc.).

The proposal: Define the metering mechanism for each call, SMS or application ad-hoc and use specialized meters outside of the network to meter the service. Time-based meters allow any type of data to pass through to the network but will bill by nano-second, millisecond, second, minute, hour, day, week, month, year, etc. You just configure that this voice application needs second-based billing, that adult entertainment application needs minute-based billing and that compute server needs hourly-based billing. Flat-fee calls would not have to be metered and as such don’t need a meter. Meters could be gateways that scan if data goes through. However they could also be event-based and delegate complex metering into an application to warn them when an event has to be billed, e.g. application download, new user registration, etc.

Simplifying the network by taking out complexity to manage/launch/meter/monitor services would substantially reduce the cost of network equipment. Perhaps to such extend that it becomes too small to meter services and as such also metering can be eliminated. Pure bit-pipe operators could probably do with an Excel or Access database as their billing system.

Infrastructure automation is key to accelerate time-to-market.

November 20, 2010 Leave a comment

Most telecom projects involve installing an Oracle RAC cluster, a SAN, application server clusters, etc. Only the time it takes to procure and install the basic hardware and software takes months. We are not even talking about the costs…

If you want to launch new ideas every month, you have to use Cloud Computing. This can be public cloud, private cloud or hybrid cloud. However even then too much time is spend on installation and configuration of software.

Infrastructure Automation

Infrastructure automation is about making a team productive in quickly launching new services or updating existing services. Infrastructure starts with having a standardized development environment, automated build tools (e.g. Maven or Ant for Java), continuous test automation (junit but also Hudson or Cruisecontrol), etc. The next step would be to also automate deployment (e.g. Puppet & mCollective from PuppetLabs) of server software and Cloud infrastructure.

This type of automation  is often 90% equal so having a standardized framework would extremely shorten the times to get software development up and running as well as deploying it into test and production environments.

This would however only be the start of the journey. Dotcoms launch new features on a weekly or even daily basis. They monitor in detail what users do and often launch multiple alternative versions of a new feature. Gradual deployment of small features allows to see performance problems strait away and avoids extensive regression tests and fast rollback.

Let’s see how this could be applied in telecom.

The key to success is copying Google. Google is having standardized architecture components that are reused among different teams (e.g. BigTable). By building up a shared infrastructure and the tools to quickly deploy new services onto it or update existing features, time to market can be dramatically reduced.  Infrastructure is a secret competitive weapon that too few companies use.

Follow

Get every new post delivered to your Inbox.

Join 301 other followers

%d bloggers like this: