Our blog

Your 2020 vision for IMS

But this time, we brought in a more open-ended approach to elicit real opinions. It was an improvised session and, so much the better for it. Delegates were simply asked their views on how they imagined the state of IMS to be in 2020 and given the means to enter their thoughts anonymously. Some very candid thoughts were expressed. We captured these and, somewhat overdue, it’s true, here’s a summary of the key ideas that emerged.

By far and away the most frequently expressed view was that IMS will be virtualised. This is hardly controversial but reflects growing awareness that NFV / SDN architecture and deployment models are moving into the mainstream – and that highly specialised solutions such as IMS are the ideal candidates for early adoption and migration. Since many IMS deployments will be driven by VoLTE / VoWiFi, we can expect to see considerable progress towards virtualisation – indeed, we anticipate that virtualised IMS elements (or a clear path towards their delivery) will be the de facto requirement in RFIs / RFPs from early 2016, if not from this point on. After all, why would you invest in legacy hardware solutions if a better alternative were becoming available?

This raised an interesting point, touched on by at least one respondent. In particular, someone volunteered the view that IMS will be dying because of high TCO. This is a valid point, depending on the scale of your operations. However, one solution to this may be found in the NFV approach – after all, if NFV can radically change your cost base, as more than one presenter in the plenary sessions noted – then it should also have an impact on the TCO of IMS. It’s certainly clear that operators expect dramatic cost savings to be enabled; it’s now up to vendors to meet this challenge and deliver.

Next, a number of delegates pointed to the concept of ubiquity. What they meant was that IMS will, they expect, end up being invisible. That is, “it’s just there” (as someone wrote), it’s not an issue and it simply does the job for which it was deployed in the first place. This is both positive (indicative of predicted widespread deployment and so garnering little future attention) and negative (in that the potential for innovation in IMS itself may be seen by some to be limited).

That’s an interesting view – and one we share. IMS itself isn’t the fount of innovation but rather the foundation of it. In other words, innovation won’t be happening in IMS per se, but rather around it, enabled by APIs, as others also noted. IMS exists to do a job and to enable services – some of which will be carrier services, such as VoLTE, but others will (must) be created by external agencies.

While there is still a vague notion that operators will develop the agility to foster service innovation, the fact is that no one could actually identify what such innovation might be. It’s rather like the known unknowns of Plato and Rumsfeld. We know that there will be innovation, but we don’t know in what form. Although this is still frustrating – after so much discussion on the topic of innovation in recent years, there has still been little progress in terms of usable, appealing new applications and initiatives from operators, it’s refreshing to hear people explicitly state that they don’t know what this innovation will or should be.

Instead, the emphasis on APIs, long a favourite topic of ours, suggests recognition of the fact that innovation lies elsewhere, as has been abundantly clear to many outside of the IMS community for some time. Perhaps this points to a removal of the delusion that operators can innovate by themselves. If so, it’s been a long time coming but as a moment of self-realisation, then it’s a positive sign. The next step is to do something more about it, but that’s another story altogether.

Finally, of the primary topics identified, several wrote about QoS. This is clearly a controversial subject – one respondent was clear in that he/she stated that QoS is simply overrated – “only certain applications need to be managed in specific latency / packet loss boundaries” – which suggests that he/she didn’t view QoS as a marketable quality. Interestingly, however, the same correspondent did identify the need for the network to be able to support a range of service qualities (my interpretation), so that customer experience could be adjusted according to the needs of other (not mentioned) applications – describing this as a “QoE trading place”, an interesting concept.

Another drew on this point to remark that an external partner (in this case, Facebook) will build closer relationships with operators, by asking them to host applications in order to access QoE, which presumably must be variable depending on the needs of the application – or which may need to change dynamically. That’s interesting and has long been a favourite topic of conversation – along the lines of “external partners must come to us because what we offer is unique and special”. That remains to be seen.

Similarly, another opined that operators could deliver internationally guaranteed QoS, so there is clearly some debate on the value of service quality – operators agree that they can deliver it, but it’s not clear which services and applications actually need it and to what extent – or what the external demand for these capabilities may be.

Finally, it was also suggested that there is a need to be planning for the replacement of IMS with something else – something which also has to manage millions of concurrent user sessions, integrate with accounting systems, offer user authentication, allow policy integration, provide media capabilities and so on. Indeed, something that looks a lot like the capabilities that IMS was designed to deliver but who knows in what shape this will emerge, except that we can definitely say that it will be virtualised!

So, in all, it was a most interesting session. The selection above draws on the most prominent remarks but the rest can be summarised, thus:

  • There are still roaming issues and they aren’t going to go away! See the next point….
  • SS7 will remain long after 2020, which is good news to some and bad news to others
  • We may need to find another name for what we currently call IMS
  • Costs must come down
  • IMS may be obsolete or legacy by then, but no-one knows what will replace it, which doesn’t provide any answers but is a provocative thought
  • The event should move to Dubai….
  • We hope IMS will be carrying more traffic than on legacy environments
  • IMS needs to evolve, but no-one quite knows how

And that’s it until next year – hopefully, by then we shall see signs that answers to the “what next” questions will be emerging. All of which proves that there is great value still to be found in this annual event and that it continues to draw a wide variety of stakeholders from across the ecosystem, each with interesting (and often entertaining) views.

For what it’s worth, we are clear in that we see IMS being around for some time to come – there just isn’t a viable alternative for an operator with millions of subscribers to serve. That’s not to say that we don’t expect profound changes, but it’s more likely, in our opinion, that these will come from smaller operators without some of the challenges of the Tier 1 community.

There will definitely be other approaches to solve the problem, but we haven’t seen any real evidence that these have yet to emerge. Either operators are persisting with existing solutions or have already jumped into the world of IMS. The most likely way in which things will be shaken up will, we think, emerge through the virtualisation process.

As to APIs and services, that’s more of a cultural than a technical issues – APIs to access network capabilities and resources have been around for years, but it’s only now that there is real momentum behind exposure initiatives. The recognition (from some) that operators are unlikely to be the source of service innovation is crucial – it must inspire a shift of thinking to identify those that can innovate and then to actually do something about it.

However, the commercial success of operator-led initiatives remains to be seen. But, as we move to a world in which new modalities of communication emerge and in which communication becomes simply one of the capabilities of a service rather than the service per se, we can expect to see considerable innovation from partners that need access to robust, reliable communication enablers.

Not that this is new, of course – some operators have been investing in these kinds of API-enabled networks for years - but their focus has been on the enterprise and business requirements. The extension of this into consumer arenas, which will be driven from outside the operator community will be one of the most exciting areas to watch as we head towards 2016. Our position is clear and has been for many years – operators should be focusing on their enterprise partners and leaving the innovation for consumers to others but creating an environment in which their assets can support that innovation. Let’s see what happens.

See you next year!