Originally posted on 01Dec09 to IBM Developerworks where it got 9,557 Views
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.
- Build composite applications that consume and combine existing services to automate processes like retailer commissions
- 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.
https://www.youtube.com/watch?v=aL1UiXwY4LI - 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…..
- Family Finder – Allow parents to see where their kids are and where they have been
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?
Please comment…
* TPS estimates are very conservative which will give any telco taking on this sort of SDP lite topology plenty of room to grow.
