Over the last couple of years, we’ve been working increasingly in the field of smart cities, helping our customers to understand opportunities, define offers and to promote them to the relevant audience. It’s been an interesting time and was both a logical extension to the fields we have been working in, as well as a slightly serendipitous shift. Let me explain the latter point. For some time, we had been working on OSS service assurance for classical networks, but one of our customers began to become involved with the application of standards, such as TMF’s Frameworx, in the emerging field of smart digital services.
Together with our customer, we recognised that a key requirement for a future smart city, or any other digital service environment, would be the need to support many different services – with often highly contrasting performance characteristics – in the same network, and with a rapidly proliferating number of devices. Some services would not have any critical or demanding performance requirements, while others would have either real-time performance requirements or could even have a mix of the two. As such, existing standards for OSS service management would not be sufficient; they would have to evolve.
This recognition brought us to speak to a growing number of people acting in early stage trials of a range of services. At the time, the TMF was largely unknown in this context and service performance was a given, rather than something that would itself be a key characteristic of the future range of services envisaged.
The last couple of years have seen this viewpoint shift radically. Already, there is growing recognition that smart city networks, for example, should be specifically designed to cope with a wider range of performance requirements than has been necessary in traditional voice and data networks, and that the services may themselves have highly volatile performance requirements, adding to the challenge of delivering them effectively.
The role of the TMF in advancing such knowledge has become more widely recognised – today, when we speak to people from a given smart city team, it’s clearly understood that standards to ensure network performance need to be in place to support a known (and unknown) range of services, and are a prerequisite for the successful deployment of a smart city infrastructure.
At the same time, there has been considerable debate around the ways in which the end devices will connect to the network. Sadly, much debate has focused on which technology is likely to dominate. This is misleading. The fact is that connectivity is a tool and will simply be chosen according to what is possible, what is necessary for the specific service, and what can perform the task in hand.
No single form of connectivity will win, rather the debate’s about how different mechanisms will be used according to the needs of the service in question. This was a major topic at the Smart Mobility Summit, held in Amsterdam last year (you can see our presentation on the topic, here, in which we summarise some of the issues to consider).
So, a debate about the merits of one form of connectivity over another misses the point. The tool chosen will be the one that best meets the needs of any particular service. Connectivity is what matters, not whether it’s LoRa, SigFox or WiFi. Each has its merits. What matters are the standards and the availability of connectivity that can deliver the service effectively. Things have moved on. In 2017, we expect to see more emphasis on service needs, not connectivity models – which is why we’re already looking forward to the next edition of the Smart Mobility Summit.
Understanding the need for flexibility and not having an evangelical conviction that there is a single answer is going to be fundamental to moving from pilot to full-scale deployment and we’ll be reporting on several interesting projects throughout the year. Watch this space!
