IoT devices, networks and services need extensive monitoring. Hundreds of thousands of devices are being added daily to the IoT ecosystem, connected to each other and the cloud through Bluetooth, Wi-Fi, cellular and fixed networks.
New communication networks based on EC-GSM, LoRa, LTE-M, NB-IoT and SigFox are being considered by IoT service providers to deliver their services. While the IoT service providers could potentially operate separately from Communication Service Providers (CSP), IoT networks are currently being overlaid on existing communication networks and therefore require the CSP’s support in managing the inter-device communication and in maintaining its quality.
Many of the connected devices will be controlled through reliable, cloud-based management systems, operated by the CSPs. These monitoring/management systems will not only check the performance, but also provide real-time visualisations of the devices, irrespective of their locations: robots on factory floors, connected cars on a highway or medical equipment in a hospital, says Sandeep Raina, Product Marketing director, MYCOM OSI.
IoT monitoring requires all the components of the OSS, i.e. performance management, fault management, service quality management, analytics and automation. However, to set a priority for the monitoring actions in the initial days, IoT will require real-time device and network fault management, followed by proactive device and network performance management. This can then be followed by corrective systems using automation.
Light analytics, in some cases, will need to be introduced right from the beginning to ensure QoS, followed by detailed analytics to support creation of new IoT services. This sequence of IoT management will ensure that the devices are operating in a faultless manner, are always connected and delivering on the promise of 100% connectivity and 100% reliability.
To elaborate on the key aspects of IoT monitoring, here are some considerations for the IoT service providers, as well as the CSPs.
- Real-time monitoring
Whether IoT data traverses narrowband, broadband or cellular networks (mentioned above), it needs to be monitored in real-time (down to a few ms of delay). The physical IoT elements that require monitoring are the endpoint devices, the IoT gateways, the IoT application software, the cloud environment (public or enterprise) which supports interconnection and storage. This requires high efficiency, highly automated OSS, preferably located in the cloud. However, compared to traditional CSP customers, the latency and real-time monitoring needs of the IoT consumer will widely vary. Therefore, the OSS system will need to tune its real-time ability to the application on hand. For example, mission critical IoT devices in manufacturing and healthcare will need more real-time monitoring than fast moving driverless cars which might not always be connected with the cloud or a telecom network.
- Predictive and pre-emptive maintenance
In order to protect the IoT device uptime, it is important to employ predictive and pre-emptive maintenance for those devices that are prone to failure. For example, the OSS should carry out dynamic route optimisation, especially for devices that are mobile (cars, drones, etc.). OSS also has an important role to play in reducing truck rolls and in monitoring and managing remotely located devices, or those located in difficult terrain. In order to predict problems accurately, and then follow up with pre-emptive maintenance, use of big data analytics will be key.
- Device performance
Key IoT performance measurements will include the performance of the sensored devices, and ensuring the reliability, and security of those devices. The OSS system needs to distinguish between IoT devices that need real-time monitoring and those that can do with non-real time monitoring, based on the industry verticals that use those devices and the kind of application that the devices support (life critical, mission critical, etc.). By distinguishing in this way, the IoT SP or the CSP can control the volumes of data that feed its OSS system, retaining the most critical information and discarding what is not required. For end-to-end monitoring for each industry vertical and for each end customer, the CSP needs to provide aggregated performance dashboards and, in some cases, visualisation/drill down to individual devices, for the consumer’s benefit.
- Multi-team collaboration
Managing the billions of IoT devices and the networks that they communicate through requires significant collaboration between different functions of a service provider. The technical operations team will typically be involved in monitoring the following:
- devices classified by their industry vertical
- volume and nature of communication between the devices
- performance of IoT gateways
- IoT network/service analytics
- network capacity/congestion KPIs
The commercial teams (Enterprise sales, IoT partnership team, Customer care) will need to build capabilities to address the different needs of the industry verticals whom they are serving. SLAs and feedback from the IoT service providers will ensure that suitable industry-specific or customer-specific KPIs, dashboards and analytics are built by the operations teams.
There are many businesses who are investing in IoT over the next five years, expecting returns in billions of dollars: operational technology vendors, IoT endpoint vendors, platform vendors and CSPs. Some of the early IoT applications for fleet management, driverless connected cars, smart homes, automated patient care and energy savings will pave the way for shaping the capabilities of the next generation OSS for IoT.
The IoT service providers (including the traditional CSPs) understand that such mission-critical and life-critical devices will require tremendous effort on the provider’s part to analyse and action fault and performance data quickly. They know that, in the absence of predictive models and automated root cause analysis, it will not be possible to serve the IoT customer.
The author is Sandeep Raina, Product Marketing director, MYCOM OSI.
Comment on this article below or via Twitter: @IoTNow_ OR @jcIoTnow
