Telco Talk

A new name and a (slightly) new direction. Telco talk will add Business Process Management within the Telco OSS/BSS arena to the potential subjects we'll cover here. The old Industry Business Partner Technical Strategy Enablement (IBPTSE) team's role remains an important part of IBM's Telecom strategy, so I will probably still cover partner capabilities and content here. I know the blog is pretty much about telco, but I reserve the right to comment on other industries as well :-) I plan to talk about resources that are available to IBM Business Partners, some of the latest issues we are seeing in Telecom, some discussion of IBM software technology and some thoughts on IBM's Smarter Planet initiatives.

In response to the presentation I built (and blogged about - see Telecom Systems Evolution) a number of IBMers asked for costings for each phase. While that would be possible at the early stages where you don't have to take into account scaling, later in the phases, that really does become impossible. For instance lets say phase 4 was US$1m for Telecom New Zealand (with about 2 million subscribers and a heavy post paid mix of subscribers) and compare that with Bharti-Aitel in India with 120 million subscribers and a heavy pre-paid mix. Because of the variations in telcos around the world, there is no way any pricing that was added to the presentation would be in any way applicable - that is something that has to happen on a per telco basis.That said, we are working on a "starting point" or "lite' implementation and wrapping some costs around that - we think this would be a good starting point for many SDP projects - kind of a standard phase 1. The architecture would be built with expansion in mind even though at phase 1, the components would not be excessively sized. So far, we have a near final Bill of Materials and a number of diagrams. I thought I would share those diagrams with you here. We still need to document all the assumptions and limitations that this "SDP Lite" phase 1 architecture would entail.I would appreciate feedback on these diagrams, so please comment.

SPDE 3.0

The IBM Telco specialists should recognise this - it is the Service Provider Delivery Environment Version (SPDE) 3 - IBM's industry framework for Telecoms. I included it here for reference and comparison with the follow diagram that illustrates the areas of impact that SDP lite will have on SPDE 3.0.

Now, see the areas of impact that SDP Lite has on SPDE 3.0 - the Orange shades indicate areas of impact. Iif we map the IBM products in the Bill of Materials over the top of that, we get...

SDP Lite

That's it with the logical views of SDP Lite. The next one is a marketecture diagram to help explain the key principles and functions of SDP lite. I am only showing the production environment in this diagram, but you could also have a separate environment that is a duplicate of this that could be dedicated to both test and ISVs.

For those that want to understand the Deployment units and their basic layout, I have a deployment unit diagram

Finally, an illustration to show how the SDP Lite infrastructure could support a developer ecosystem - the shaded components could be added in subsequent phases - for now, it is all about secure exposure of web services and REST interfaces to a developer ecosystem that is using conventional Integrated Development Environments (IDE). Note also that the hosting servers for the developer applications are out of scope and could be hosted anywhere on the Internet..Keep in mind that this is supposed to provide a starting point - or initial deployment. Infrastructure that could grow, but could be used immediately for smaller trials. With that in mind, in estimating the performance, this is what we get:

Use Cases:

This SDP Lite infrastructure would allow a telco to begin offering a range of new services and products as well as form the basis for a larger and more functionally rich topology later on. Some of the use cases that come to mind immediately include:

Service exposure to 3rd party ISVs - Web Services and/or REST. This represents a new revenue opportunity for many telcos.

Marketing campaigns based around bundled products. For instance: top up your prepaid mobile broadband and get unlimited text messages for 24 hours on your mobile - Globe Telecom in the Philippines are doing this exactly - check out the following Globe TV commercial:

Begin to build a developer ecosystem around the exposed services

Build composite applications that consume and combine existing services to offer new products to subscribers such as

Family Finder - Allow parents to see where their kids are and where they have been

Meet on Click - Friends can see where each other is, what is on locally and send invitations to catch up via SMS, MMS or PushWAP

Emergency notifications - Notify everyone in a specified geographical area of some danger

Location based marketing - Send SMS/MMS/PushWAP messages to subscribers who have oped in when they get within 500m of a retail outlet.

lots of others.....

Assumptions/Performance estimates:

TWSS

Performance basics

50% CPU Maximum

JS12 Blades (one for TWSS Access Gateway, One for TWSS Service Platform)

8Gb RAM

Interfaces supported

SMSM via SMPP

PushWAP via SMPP

MMS via MM7

LBS via MLP

Parlay via CORBA

Presence via SIP

IMS/VoIP via SIP

Expected max transaction rates

100 TPS* for SendSMS via SMPP

10 TPS* for SendMMS via MM7

Other transactions could be added into the mix, but would lower the SMS or MMS transaction rate.

WPS

Performance basics

50% CPU Maximum

JS12 Blade

8Gb RAM

80% Shortlived transactions

20% Long Lived transactions

Expected max transaction rate

20 TPS* of the above transaction split

TAMeb

Performance basics

50% CPU Maximum

JS12 Blades (one for WebSeal, One for TAM Policy Manager)

8Gb RAM

Expected max transaction rate

40* TPS

DB2 Enterprise Edition

Performance basics

50% CPU Maximum

JS12 Blade

8Gb RAM

Minimum of 12 Disks in RAID 1+0 Array

So, assuming that both internal and external users/systems were using the system concurrently, we could support up to 40TPS from external developers (limited by TAMeb) which if we assume they are using 90% TWSS services and 10% composite services will mean that internal systems would have 74TPS of TWSS services and 16TPS of WPS services available if the developers are consuming 50% of the TAM CPU.
.

Component

External
Developers

Remainder
for Internal Use

TAM

40
TPS

n/a

TWSS

36
TPS

(32.7 TPS of SendSMS + 3.2TPS of SendMMS)

74
TPS

(67.3 TPS of Send SMS + 6.8 TPS of SendMMS)

WPS

4
TPS

(3.2 shortlived + 0.8 longlived TPS)

16
TPS

(12.8 TPS shortlived + 3.2 longlived TPS)

These are really rough numbers and I would like to add some more assumptions around then. Of course, if your Telco won't have a developer programme, then 100% of the transactions would be available for internal consumption.
.

What do you think? Are we on the right track for your Telco customer? Would you like to see some changes?