Originally posted on 05Jan10 to IBM Developerworks where it got 6,806 Views
Did you know that the vast majority of calls carried out on the 3.5 billion GSM connections in the world today are protected by a 21-year old 64-bit encryption algorithm? You should now, given that the A5/1 privacy algorithm, devised in 1988, has been deciphered by German computer engineer Karsten Nohl and published as a torrent for fellow code cracking enthusiasts and less benevolent forces to exploit.
Yikes! This harks back to the old days of eves droppers on Analogue phone signals and all those illegally taped conversations (I recall some conversations between the late Princess Diana of Wales and her bodyguard for example). Ok, we’re probably not quite there yet, but by the sounds of this article, we aren’t far from it now…
Originally posted on 31Dec09 to IBM Developerworks where it got 10,998 Views
As I see it, Telcos (particularly in counties that I deal with) are in a perfect position to transform their subscriber’s enthusiasm for social networking into real business benefits Combining traditional Calling Circle Applications (aka Family & Friends, or VPNs as the Telcos would call them) with online (PC or Mobile) communities to share information. These could be short-lived around:
Religious event
Public Holiday
Sporting finals
Wedding Anniversary
21st Birthday Party
Or they could be longer term communities such as :
Kindergartens
Scout Troups
Football Clubs
Fan clubs
Church Groups
Service Clubs (Lions, Apex, Rotary etc)
These are just some that come to mind off the top of my head. I am picturing discounted call and text rates for community members as well as discounted data rates for mobile access to the web community including blogs, activities, profiles, discussions etc. Think about these sort of integrated scenarios for Telcos:
Sending SMS messages to blog subscribers every time that blogger posts a new blog
Emails or SMS message to a community – based on either their profile or their current location.
Microblogging aggregation – the subscriber sends a SMS to a shortcode, which then updates all the other microblogging services that subscriber uses (Facebook, Twitter, MySpace, Freindster etc)
Write blog posts on your mobile phone either via a MMS message (including images, video or audio), the phone web interface, an email interface or (for shorter entries) SMS messages.
Bloggers could recieve SMS messages whenever someone comments on their posts
…. the list goes on…
In these days where churn is a significant issue for most Telcos – especially in countries where mobile number portability (MNP) has been introduced, anything a telco can do to make themselves more sticky for their subscribers is a good thing. Also add to that the potential additional revenue from additional data and messaging usage and we have a proposition that lot of telcos would be interested in. I wouldn’t see this as having a major effect on ARPU, but every little bit helps.
I can picture a wide range of services that telcos could combine with their Social networking offerings that would draw out additional revenue from their subscribers. While there are plenty of Internet based companies offering blogging, file sharing, profiles, microblogging etc, none of them have the established relationship that a Telco has with it’s subscriber base. Additional, very few of them have a local presence outside of their home country. Telcos are localised in nature – either through government heritage, Government regulation, Language or social reasons – Telcos need to take advantage of that fact. OK, their in country competitors have the same advantage, but in this race, the real competitors are the Internet providers. Obviously, a Telco that can move on this territory before their local competition will have a significant advantage in the marketplace.
My gut tells me that within each country, we are just waiting for the first Telco to offer these sort of converged services before all the others in that marketplace decide that they need to as well – the Domino effect.
Speaking about the Domino effect, I am struck by the irony of the naming of that principle and what is happening in the Vietnam telco market right now. The US Government coined the term the Domino effect to justify entering the Vietnam War in support of South Vietnam (to prevent the fall of the rest of South East Asia to communism), yet in the Telecom industry in Vietnam, we are seeing a Domino effect with respect to Service Delivery Platforms right now – one telco goes down the SDP path, so now they are all going down the SDP path…
Now that I have rambled onto the subject of SDPs, a telco could offer Social Networking services without having a SDP in place, but in order to offer true integration between the Social Networking offering and the traditional telco services, a SDP will be required unless they want to go down the custom code path and I think we all know where that ends up – Spaghetti Junction!
Originally posted on 30Dec09 to IBM Developerworks where it got 9,113 Views
As I alluded to in my earlier post (Telcos capitalising on Social Networking tools), Telcos can use Social Networking tools to their advantage in a number of ways. I also mentioned the Idea Factory for Telecom – an adaptation of the basic Idea Factory offering now owned by Software Group Services for Lotus. This offering was originally put together by the High Performance On Demand Services (HiPODS) team and had no less than six servers minimally required for the offering. That is because the Idea Factory (or Innovation Factory as it was previously known but renamed due to trademark issues) was originally offered well before Lotus Connections was released. These days, small to medium implementations can be done with Lotus Connections, IBM Mashup Center and a number of templates and add-ons (widgets) for Connections. A Proof of Concept could potentially be done with a single server. Larger Idea Factory implementations – particularly where Telcos are hosting the service for their enterprise customers and MNVOs would also require a WebSphere Portal Instance as well.
Probably the best explanation I can give to you of the Idea Factory is for you to watch the recorded demonstration I have available below – in fact I have quite a number of variations of the same demo customised for different Telcos – the demo below the most recent which was recorded before Connections 2.5 was released and so was done with beta version of Connections – see if you can spot the fault in the video! I tried to cover it up as much as possible because I needed to show this video to customers, but it’s in there and you will see it if you know what you are looking for….
For online access to the latest Idea Factory (V2) recorded demo – just launch it below… Also note that this is a lower resolution version for online use. I also have a larger version that I used for offline demos, it is 24Mb in size so I will share that with anyone that requests it rather than make it generally available.
Way back in 2007, there was a good whitepaper about the Idea Factory – I have uploaded it to Collaboration_to_innovation-leveraging_web20.pdf. This document is now quite out of date with respect to the technology used to deploy the Idea Factory (then called the Innovation Factory) – these days, we would use Lotus Connections 2.5 as the base platform and add widgets for the polling/surveys requirement and set up activities templates to manage the ideation process, then use IBM Mashup Center rather than QED Wiki which was a IBM Research developed Mashup Environment (check youhtube.com – there are lots of QEDWiki demos available).
The Idea Factory for Telecom fosters collaboration by incorporating a self-service portal for consistent user experience and integration. Aside from this limitation, the concepts expressed in the whitepaper and the usage of the Idea Factory remains relevant. I guess one point that this whitepaper makes it that IBM has been in this Web 2.0 game for a while now – longer than we have had Generally Available product to support the concepts.
If we look at the above diagram, Lotus Connections will take care of most of the Collaborative Services and the Portal (UI) requirements while IBM Mashup Center takes care of the Services Cluster and the Services Catalog (called the Widget Catalog in the Mashup Center).
Originally posted on 23Dec09 to IBM Developerworks where it got 13,046 Views
I was going to use this post to talk about the Idea Factory for Telecom, but I noticed this press release this morning about SK Telecom (South Korea) use of Cloud computing and I though I would share what have seen with Cloud computing in Telcos. The press release follows:
ARMONK, N.Y. – 16 Dec 2009: IBM (NYSE: IBM) today announced that it has successfully built Korea’s first cloud computing environment for a private sector company, SK Telecom, the largest telecommunications company in Korea with over 24 million customers. The cloud environment provides developers with the necessary software and hardware to develop applications that will allow SK Telecom to offer up to 20 new services to their customers by the end of 2009, such as sports news feeds and a photo service.
I can’t claim to have been closely involved with this deal at SK Telecom, but we have spoken to other Telcos in ASEAN about using Cloud Computing in a similar way. Where telcos have a developer ecosystem, Cloud could be deployed in a private could environment for their developers to deploy their test applications within that private cloud. We proposed using the WebSphere Cloudburst appliance to allow developers to self manage and deploy the virtual servers for their applications. The diagram below illustrates what I am talking about:
I guess this could be where I tie in the Idea Factory for Telecom after all. The Idea Factory would be used to support the whole developer ecosystem, while the Cloudburst appliance would be used to support the advanced developers who want to be able to deploy their Java applications within the cloud.
In my view, this is a somewhat obvious use for Cloud within a Telco and SK Telecom’s deployment of Cloud in this manner is proof of that point. The somewhat less obvious use of Cloud within a Telcos is the use of Cloud infrastructure for their core SDP and OSS/BSS infrastructure. I could not imagine a Telco being willing to deploy such core systems in a public cloud, but there is a possibility of deploying it in a private cloud.
The team at Bharti Airtel are working to move the SDP infrastructure there to a Cloud environment – giving them the flexibility to rapidly scale up and down to suite different changing market forces. The other BIG thing that moving to a cloud will change is where the SDP components are deployed. Once the SDP components such as WebSphere Process Server, Telecom Web Services Server, WebSphere Services Registry and Repository and the other components are in a private cloud, it becomes very easy to move to a hosted private cloud or even a public cloud. If we think for a moment about the SDP running in a hosted cloud environment, then it is not a huge leap to host another Telco’s SDP in the same hosted cloud. Now we have a hosted environment in which potentially many telcos have their Service Delivery Platform running.
This diagram illustrates the various SDP deployment options including the Cloud options. What is happening at Bharti is a move from a traditional OutSourcing model to a private cloud, then on to potentially a single client hosted private cloud and then eventually to a multi client cloud option. See that I need below.
What do you think? Can you think of any other cloud scenarios in a telco?
PostScript Taking into account the comments from the internal version of this blog, I have modified the developer ecosystem a bit – using IBM Cloudburst instead of WebSphere Cloudburst would certainly give a Telco a much greater developer platform choice. I’ve left the view above because that is what we proposed to the ASEAN telco, but in retrospect, the IBM Cloudburst option would have better suited their needs – although IBM Cloudburst has a significant price premium associated with it that WebSphere Cloudburst does not. That said, in a cloud environment (customer hosted private, IBM hosted private, multi or single tenanted) for a Service Delivery platform, using IBM Cloudburst would seem to be to be the right way to go.
Originally posted on 18Dec19 to IBM Developerworks where it got 8,218 Views
The announcement by Telstra* the other day of it’s social networking guidelines for employees (See Telstra’s 3Rs of Social Media Engagement and their online training class ) got me thinking about how Telcos should be using Social Networking tools and trends both internally and externally. OK, Internally, a Telco is like any other big company when it comes to collaboration among it’s staff. Social Networking tools help employees to make contacts, learn and share more, find information more rapidly and maintain social networks beyond the physical boundaries of their own work location. If you’re curious about what I am talking about, I recommend you have a look at the great videos on YouTube from Jean Francois Chenier (An IBMer). I have embedded the first of the series below:
It’s pretty easy to see how within any large company, social networking software such as Lotus Connections makes sense provided you have enough people who actually use it – it seems to me to be something like groups calendaring – it is dependent on a significant proportion of the user population using the tool to make it effective. The way I see it, it is only a small step beyond the internal deployment of social networking tools to extend to a Telco’s trading partners. That might include vendors, resellers (of Telco products – I was initially thinking retail, but that could include MNVOs), enterprise customers and others. Situations where employees of the Telco and employees of external companies need to work together and share information and collaborate – share idea, files, information – generally collaborate would seem to be a valid deployment of social networking tools.
IBM already has an offering that uses social networking tools to build communities around the Ideation (Idea generation and growth) process, a kind of virtual brainstorming combined with idea and through sharing. The intent of the offering is to make it easier for companies to find and help to evolve idea for the next product to take to market. In a Telco, this might be idea such applications like “Meet-on-click”** that a telco could take to market. That offering is called the ‘Idea Factory’ and is not actually unique to the Telecom industry. Kraft foods use the Idea Factory to come up with new ideas for product packaging. When deployed in a Telco, we often combine the Idea Factory with IBM Mashup Center (recently V2.0 of Mashup Center was released by the way) – an offering I usually call the “Idea Factory for Telecom”. The Mashup Center is used as a rapid prototyping environment for the ideas that are evolving within the Idea Factory. In my view, this is a great way to build an active and dynamic developer community for the Telco.
China Telecom have demonstrated how effective the Idea Factory can be in a Telco environment – with a year on year improvement of 900% in a competition to find new applications (3 to 27 new products). Their Idea Factory deployment predated IBM Mashup Center, so they didn’t get the benefit of a rapid prototyping tool which I believe could increase the quality of the new product ideas even further.
While I am a big fan of the Idea Factory, I see that as just a starting point for social networking tools hosted by a Telco that extend beyond just their developer community and into their (much) larger subscriber base. Think about building many local communities based around schools, churches, scout troops, national holidays, religious events, local football teams, mothers groups… anything really. The community would have access to a shared virtual community on the web accessible from a PC or (more importantly for many developing nations) from a mobile phone, they would have microblogging, blogs, files sharing, discussion forums, profiles contacts AND be tied into more traditional Telco services such as calling circles. The Telco could provide discounted call and text rate between community members. Sound good? I think so. For the Telco I see a number of benefits:
Decreased likelihood to churn – increased ‘stickiness’
Stronger loyalty to the Telco brand
Increased revenue due to increase in call and text volumes and increased mobile data usage once a reasonable proportion of the community is using the tools
An additional weapon against the Internet based competitors (such as Facebook, Skype, Twitter, Instagram etc)
Telcos in my opinion have a significant advantage over the Internet companies when it comes to offerings like this. They have:
An existing relationship (post or pre paid) customer
More local footprint via people on the ground and reseller/franchisees
Existing monetary arrangements with the customers
Greater trust by customers (typically)
Telcos could easily become the local aggregation point for social networking within that community – for instance with a Facebook connection, subscribers could update their Facebook wall without the need to launch Facebook. Microblogging entries could automatically update status in Facebook, LinkedIn, MySpace and sent a tweet out on twitter.
I think this is going to be big – web based social networking giants like Facebook, MySpace and LinkedIn have proved how popular web based social networking can be – add the local context to it and I think you have a winner for Telcos in many markets.
Now that I have started this thought, I think the next few posts could well be along similar vein – looking at the Idea Factory for Telecom, Telco focused Developer Ecosystems, User generated content and Public focused and Telco integrated social networking capabilities….
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…..
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.
Originally posted on 26Nov09 to IBM Developerworks where it got 11,308 Views
I had a request on the other week to create a number of topology diagrams that showed how a Telco might start small and grow their environment to add new capabilities and services. This was specifically for a telco in Vietnam, but I figured it would make sense to generalise the presentation and the images to make it usable for other opportunities. We’ve had a similar request from other telcos recently as well. The presentation step through 11 phases from a pilot/trial environment through to a full blown system. Each slide has speaker notes explaining what is being added at each phase in terms of products and capabilities. This presentation is not meant to make any recommendations on how to evolve form a small system to a more complex and capable one. What it is supposed to illustrate one possible evolution… Note that it focuses only on the IBM components and some other components would also be required for some phases (such as a transcoding engine in the media extension phase).
Below are three of the diagrams – Phase 1, Phase 6 and Phase 11 and the speaker notes that go along with that phase – to give you a feel for the flow…
Phase 1 – Test Environment
Phase 1 – Test Environment
At this first stage, an initial deployment might be considered a proof of concept or a trial – which could become the test and or ISV environment, The functions that this could offer are:
Composite applications that bring together functions provided by the network. For instance an application that consumes SMS messaging and integrates the location of the handset into an app.
WSRR will get them down the path of SOA Governance – it is important to get this in early to ensure that the governance model is maintained and the Telco will now need to rework services that are created at this stage.
Complex workflows and business processes can be built which include human tasks (such as prototype processes for the production implementation )
Phase 6 – Developer Ecosystem including Web 2.0
Phase 6 introduces the Developer Ecosystem components such as :
Idea Factory for Telecom – which will help make a dispersed group of developers into a community. It enable the sharing of ideas and a framework for the Telco to manage the evolution of the ideas that are generated within the community. It also provides a rapid prototyping capability via…
IBM Mashup Canter which allows users to drag widgets onto a workspace and simply wire them together. It is both the development and the runtime architecture. This means that developers don’t need deep development skills in order to build new applications.
WebSphere sMash which provides a PHP and Groovy scripting environment (both development using the Dojo toolkit and the runtime environment)
This combined with the web services exposure deployed in phase 4 means that the developer ecosystem can now cater for all levels of developers – those with no skills can use the drag and drop mashup environment, script developers can use sMash and more advanced developers can use the web services interface. In the backup slides there is an illustration of this.
For advanced developers the Telco can support developers across a range of IDEs ranging from Rational and Eclipse (where we have Telecom Toolkits available for free) to other IDEs (such as Microsoft Visual Studio or Sun Netbeans) where the IDE has tools to assist developers with consuming web services. In all the IDEs, developers will consume the Web Services Description Language (WSDL) file from a UDDI directory in the DMZ. The UDDI directory (part of WPS) is populated from the WSRR internal services repository.
Phase 11 – IMS integration and extension
When the Telco goes down the IP Mulitmedia Subsystem (IMS) path, the software deployed already has IMS enablement, but at this point we can also add WebSphere Presence Server (PS) and WebSphere XML document Management Server (XDMS – formerly WebSphere Grouplist Manager) which provides IMS services for the IMS services plane. The core infrastructure that was deployed way back in phases 1 and 2 are critical to the IMS Services plane.
It is important to understand that the phases I have split them down into are purely arbitrary and are not necessarily what would happen in a real telco. Which function occurs at what point and in combination with other functions is something that must be driven by the business requirements of the telco. The intent is to illustrate how a telco could start small and add function incrementally building on the previous investments.
Verizon Wireless, AT&T and several major international carriers and vendors threw their support behind an IMS-based approach to delivering voice and SMS services over LTE networks. The level of operator support–the approach also is supported by Orange, Telefonica, TeliaSonera and Vodafone–sits in sharp contrast to another approach, called Voice over LTE via Generic Access, or VoLGA, which is supported by T-Mobile International.
Vendors including Alcatel-Lucent, Ericsson, Nokia Siemens Networks, Nokia, Samsung Electronics and Sony Ericsson also voiced their support for the initiative, dubbed One Voice. The companies said they concluded that an IMS-based approach “is the most applicable approach to meeting the consumers’ expectations for service quality, reliability and availability when moving from existing circuit-switched telephony services to IP-based LTE services. This approach will also open the path to service convergence, as IMS is able to simultaneously serve broadband wireline and LTE wireless networks.”
The companies said that the purpose of the initiative is to create the largest LTE ecosystem possible, and to avoid fragmentation of technical solutions.
Interestingly, both Alcatel-Lucent and Ericsson also support the VoLGA approach, and Nokia Siemens has supported its own solution, called Fast Track Voice, which proposes having mobile switching center servers handle VoIP traffic over LTE networks. VoLGA proponents argue that their approach should be used as an interim solution. All three vendors said they do not see a conflict in supporting the different approaches.
Is it just me or when you read “VoLGA” do you think “Vulgar” – I think the ALu acronym police need to get out from behind their desks and make an arrest for that one!
I’ve drawn up a representation of the situation as I see it. NSN going it alone with Fast Track Voice, almost everyone else supporting VoLGA and planning to move to OneVoice.
The thing that I find really interesting is the inference by ALu that they will continue to stand by VoLGA as well as support it as an interim step to OneVoice while NSN seem to be saying that Fast Track Voice is only an interim step on the path to OneVoice. It’s also interesting to note that the VoLGA consortium seems to be mainly Network Equipment Providers (NEPS) while OneVoice is both NEPs and Telcos…. I suppose the most appropriate message is “watch this space”…
PS. On rereading this post, I imaging some of you are going ‘Huh?’ I apologise for the Telco jargon. Let me take a moment to try and explain some of the terms that appear in this post.
IMS – IP Multimedia Subsystem (not IBM’s mainframe database that helped put man on the moon). This is a specification controlled by 3GPP (a Telco standards body) to describe a next generation IP based telephony environment. Most telcos today still run a legacy switched environment based on very specialised protocols such as SS7 and Sigtran. These protocols are not IP based and as such require very specialised (read expensive) skills to work with them. The other thing is that they are not really standardised – each NEP has their own version of the SS7 protocols. IMS promises to bring much cheaper skills and shorter development cycles to the Telcos core platform – something they have not had before. IBM has a number of products that are targeted at telco’s IMS infrastructure (WebSphere IMS Connector, WebSphere Presence Server and WebSphere XML Document Management Server)
LTE – Long Term Evolution is seen by most NEPS as the next logical evolution step for carriers with GSM networks. That evolutionaty path goes something like this: GSM->GPRS->EDGE->UMTS->HSDP->LTE. LTE promises to deliver high bandwidth mobile connections. The main rival to LTE is WiMax which you may have heard of before.
ALu – Alcatel Lucent (a very common abbreviation for the joint company)
28Nov19
This post hasn’t really aged well. I’ve reposted it because it shows a historical perspective of the direction beck in 2009. These days, the acronym of choice is VOLTE – or Voice Over LTE. VOLTE has received a lot of traction in the past ten years with Apple, Google and others building support for VOLTE into their phones for a number of years now.
A South African information technology company proved it was faster for them to transmit data with a carrier pigeon than to send it using Telkom, the country’s leading internet service provider.
Internet speed and connectivity in Africa’s largest economy are poor because of a bandwidth shortage. It is also expensive.
Local news agency SAPA reported the 11-month-old pigeon, Winston, took one hour and eight minutes to fly the 80 km from Unlimited IT’s offices near Pietermaritzburg to the coastal city of Durban with a data card was strapped to his leg.
Including downloading, the transfer took two hours, six minutes and 57 seconds — the time it took for only four percent of the data to be transferred using a Telkom line.
Okay, it was a bit of a stunt. I am sure if I posted a 32Gb SD Card to the Sydney (standard mail service- often next day delivery, but sometimes the day after that), it would arrive faster than I could transfer that content from my home office. What does that prove in terms of available bandwidth? Not much really – SD cards can hold an incredible amount of information these days. I have worked with customers in the past who shipped hard-drives around when they needed to transfer large amounts of data – even today – on most networks, it would be faster to courier a 1Tb HDD anywhere in the world than to transfer that much data over the wire.
The article did get me thinking though. I travel quite a bit around Asia and have experienced first hand the speed of networks in many countries. I’ve seen networks slower than a dial up modems (in Vietnam IBM Office) – in fact I reckon that my mobile phone as a modem over an EDGE connection (3G in Vietnam is very patchy) would have been faster than the IBM office network connection. This is not a unique situation – in many countries I visit, the network speed is faster in my hotel than it is at the local IBM office.
How does this effect the way we behave? Lets look at a specific example. Last year, I was doing a lot of work for the Globe Telecom SDP project that we eventually won with NSN in the Philippines. I was using Cattail (an IBM Research project for sharing files – similar functionality to the Lotus Connections Files capabilty that we now have in MyDeveloperworks) to upload files so that the local IBMPH IBM team could get to them rather than clog up their mail boxes. Smart – or so I thought. With Cattail, you are able to see who is downloading your files – often quite interesting as it was in this case. I noticed that only one person in the Philippines was downloading the files, despite notifying about 12 people that they each needed to look at the content. After a while I asked this one person why no one else was downloading the files from Cattail – he told me that because the network was so slow, most people were unable to even load the Cattail page to begin the download, so he went through the pain for everyone, then emailed the files around the local team! So much for not clogging up their mail files.
I am constantly frustrated by the US centric assumption that the whole world has the same bandwidth available to them as they do. Even in Australia, I am paying AU$68 per month for 12Gb of traffic – typically around 2 Mbps actual (10Mbps claimed capacity) downstream and 250 kbps actual upstream. By US standards, that must seem slow, but by the standards of developing nations in ASEAN, that’s pretty darn good. There is still a huge digital divide between the haves (the US) and the have-nots (developing nations) – while some countries will have fibre to the home deployed (or being deployed) over the next few years – Singapore will be done very quickly I anticipate – I wont have that sort of speed available to me until 2012 the Australian federal government claims (I expect it will be more like 2020 though as I do not live in the inner suburbs of Melbourne)
So, what point was I trying to make? I am not sure. I am frustrated at my bandwidth sometimes (usually not) but in countries that I visit, the whole nation must feel frustrated. I often see web pages sizes in excess of 500kb – a ridiculously large size and unusable in most of Asia. Application designers need to be mindful of the bandwidth availability if they hope to be successful in Asia. If you have thoughts, please comment…
Originally posted on 23Nov09 to IBM Developerworks where it got 9,206 Views
I’ve met with Celcom (a Telco in Malaysia) a few times this year, they have a funny sign in the lift well of every floor… So much for all the IBM sales staff that were with me!
Apologies for the quality of the photo – I only had my phone camera with me at the time.
