Archive

Posts Tagged ‘conferencing’

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.

Follow

Get every new post delivered to your Inbox.

Join 328 other followers

%d bloggers like this: