Mobile Network Operators and the Cloud (Part 2)
Olafur Ingthorsson is an IT professional in Reykjavik, Iceland who writes about cloud computing at Cloud Computing Topics.
This is the second article from my conversation with a UK-based consultant regarding mobile network operators (MNOs) and their position in the cloud computing and third-party data center market.
MNO Platforms are Not on Their Way to the Cloud
When it comes to MNOs, I think most will prefer to run their platforms in their own data centers. Keep in mind that most are running proprietary platforms for their mobile networks and VAS platforms (Ericsson, Huawei, Acision, etc..) These systems will not, in my view, be transferred to a third party colocationfacility anytime soon, except for perhaps purely leveraging facility services, including cooling and electricity. They will not easily become a “shared” infrastructure, unless for providing services to MVNOs.
However, when it comes to storing traffic and messaging data (SMS, MMS, Voice Mail, etc.) services these could potentially be moved to a third-party cloud storage provider, if the incentive is there. Unless the MNO plans to start offering a cloud service directly – and compete with other large cloud providers like Google and Facebook – I cannot see that they have need of a large-scale third party hosting/colocation provider.
Another important factor is that mobile platform infrastructure is becoming more condensed and smaller. Core systems, such as MSC’s, BSC’s and SMSC’s, that previously included rows of cabinets are now being virtualized into blade cabinets, so space requirements are actually becoming smaller than before.
How Mobile Networks and Data Networks Interconnect
Normally MNOs connect their mobile network to data networks (the Internet) through a “GPRS Packet Core” consisting of GGSN (Gateway GPRS Support Node) and SGSN (Serving GPRS Support Node). As the mobile data traffic has been steadily increasing, MNOs have been upgrading these nodes (hardware/software) accordingly. The GPRS interconnections are often directly with an Internet switch/Gateway at a fixed network provider(telecom provider or ISP) that provides access to the Internet.
As long as the Telecom/ISP is providing sufficient capacity at the gateway level to the Internet, the MNO can normally provide adequate service levels to their mobile customers – unless they provide poor data access/bandwidth at the radio level or in the core mobile network itself. Most or all Tier 1 telecoms have reserved bandwidth to an Internet Exchange Point (IXP) so they can guarantee a certain quality level “up to the IXP.” After that, the traffic enters the open Internet, unless there are other reserved lines or bandwidth capacity in place.
CDNs are Relieving Internet Problems
For example, it would be entirely possible for a service provider to reserve bandwidth to a third-party data center in a remote location in order to guarantee service levels and avoid Internet congestion. I can think of data centers run by providers like Amazon or Rackspace. I am not aware of MNOs that have direct connections to a particular social media provider (like Facebook) for improving service levels. These are normally connected via the Internet. However, several social media services, such as YouTube, have placed CDN servers (Akamai in this case) strategically around the globe to cache “popular” content closer to the requester. In this way, service quality can be improved as the congestion and latency problem of the Internet can be avoided. These CDN servers are hosted (colocated) in various data centers, including telecoms/MNOs.
With regard to the need for more power and cooling, it is possible that third-party data center providers can offer more economical solutions compared to MNOs’ own data centers. But as the MNOs platforms are proprietary core platforms, I think it can and will delay the decision to move them to external providers. However, this can be debated, especially for smaller MNOs that do not have the benefits of running large data centers and lack the scale.