Operational Support for IoT Deployments
By Kinney Bacon
We constantly hear about IoT, or Internet of Things, discussed in the news but what does it really mean to deploy and support as a service? As service operators replace voice with automation in the triple play bundle, reliably delivering this service becomes critical. This article covers some of the operational issues that service providers need to plan for.
There are two basic types of IoT deployments: large scale industrial/commercial/municipal and consumer. The primary difference is that consumer consists of a large number of customers each with a relatively small number of IoT devices, while the other covers a smaller number of customers each with a relatively large number of IoT devices. This article focuses on the consumer aspects.
For this discussion, the following is assumed: 1) the service provider is offering home automation as a paid service, 2) there is an application available to the customer to manage their IoT devices, and 3) the service provider will be managing the devices with regards to care, field service, and firmware.
In the customer’s home there should be a control device which functions as a bridge to the protocol(s) utilized by the IoT devices, such as ZigBee or Z-wave, passes on commands, collects device status, and implements local rules. For instance, you can have a rule that says when a door opens, turn on the light, and, when the door closes, turn off the light without having to go to the cloud.
The initial installation needs to be able to onboard all the devices into the account and the management system. For this to happen, the controller first needs to be assigned to the customer account. Following that, all the of the devices assigned to the account must be paired to the control device, either by the customer or a technician. Note that this needs to be done in a simple yet secure fashion, such as the model proposed by the Open Connectivity Foundation (OCF) . This function can be significantly assisted by a well-designed IoT application supplied by the service provider, which can either be standalone or integrated into the service provider’s application. One method that can help with the initial installation is to pre-pair the devices to the controller, which can then make customer self-installation much simpler, and for a professional installation, reduce the time the technician spends on the installation.
Aside from the initial installation, capability is needed to remove the controller and sensors from the account when a customer either closes the account or ends the service, as well as a temporary disconnect for non-pay customers. For situations where the devices are permanent but the customer transitory, such as in an MDU, a method is needed for transferring the device’s customer management between customer accounts.
The management of the IoT devices by customers is primarily the ability to control the devices both locally and remotely, set up rules, pair new devices, and remove old ones. Diagnostics and notifications, such as low battery, are also important for the customer and will minimize calls to customer support.
The management of the IoT devices by the service provider needs to consider care support, field service, and any analytics utilized by the service provider. Additionally, firmware management of the devices should be managed by the service provider to ensure that there are no integration issues, especially when multiple vendors are utilized, and have the ability to mitigate any cybersecurity vulnerabilities.
One of the most important aspects that can impact operations is the testing process to ensure that both the hardware and firmware of the controller and IoT devices are well tested in both the lab and the field prior to initial deployment of the devices, and then for any new firmware or hardware revisions. This is especially true when multiple vendors are utilized. Ensuring that the methods and procedures (M&P) used by the service technicians and customer care agents are correct prior to deployment can be critical to a smooth rollout.
All of this leads to the most important operational aspect of deploying IoT as a service, which is the IoT management system. This needs to interface with the billing system, the customer application, care tools, field service tools, firmware management, service assurance tools, and, of course, the actual IoT devices.
Most importantly, the IoT management system needs to be a reliable and robust platform which is scalable and preferably georedundant. While true redundancy is preferred, the additional cost can be substantial, and each service provider needs to determine if this is a requirement or not. The system design needs to focus on minimizing the operational costs of deploying an IoT service. There are a number of vendors available with IoT management system, therefore it is critical for the service provider to consider operational costs that will come with each vendor’s system as well as the capital expense for the system.
One operational aspects that will show up over time is the obsolescence of the IoT devices. As there can be a number of different vendors, each with several models, obsoleted devices will occur. A forward-looking product life plan developed with the vendors will make a huge difference later on. Remember, every new device will be old in just a few years, and you will most likely have thousands or millions of devices in the field.
When it comes to firmware management, having a robust firmware upgrade implementation in the devices can make the difference between a disaster and an annoyance. The last thing anyone wants is to have bricked devices in the field, which can create logistical and public relations nightmares. This generally requires detailed code reviews with the vendor going over possible failure mechanisms and a recovery mechanism. Remember that many of these vendors do not have the experience that service providers have gained over the years in this area.
Of course, there is the problem of IoT cybersecurity. There have been several cases in the news where the devices have been hacked, resulting in loss of customer privacy but also as a mechanism to gain access to the service providers network. This requires a thorough review of the communication protocols to ensure that they are secure, and penetration tests of the IoT devices to ensure there are no known vulnerabilities (don’t trust the vendors to do this). The ability to implement mitigation in the event of an attack is essential to the design and requires working closely with the vendor before deployment to anticipate this.
Finally, two items which need to be addressed are policy management and rules management. The best way to look at this is that policies are implemented by the service provider on what the customer can do, and the rules are employed by the customer. For example, a service provider may have a limit on the number of devices that a customer can control under their current tier. This would be implemented in the policy manager. An example of policy implementation would be to determine what action to take if a customer adds the next device that is more than allowed, such as a pop-up notice but possibly a provision for the customer to go to a higher tier or just a notice that the maximum number of devices has been reached.
Rules management should have a simple user interface (UI) for the customer to design the rules they want, preferably a graphical design. It is recommended that, where possible, the rules be applied in the customers’ controllers so that they operate even if the network is not available. For example, a simple rule might be to turn on a specific light when the door opens. This rule can be downloaded to the controller so that it operates even if the network is offline. More complicated rules, particularly those using features not local, would need to have a hybrid between local and cloud-based rule engines. An example could be using motion detection in a camera to turn on the lights in a home and send an alert to the customer.
In the long run, IoT services provide new business opportunities for cable operators and additional amenities for the customer. It is key for you to do your homework on the front end keeping in mind that this will reduce problems and frustrations on the backend.
Kinney Bacon, PE
Principal Engineer
Premises Technology
Cox Communications, Inc.
Kinney is a Principal Engineer at Cox Communications in the Premises Technology group in Engineering, specializing in strategic architecture for devices and networks in the home or small business. Kinney has been in the cable industry since 1983 working for Scientific-Atlanta, Cisco, Comcast, and Cox Communications. His expertise is in embedded programming, ASIC design, digital circuit design, automated testing, client architecture and system architecture. He is the current chairman of the SCTE IoT Working Group and has been the co-chair of the ATIS IPTV Metadata Working Group. Kinney is a frequent contributor to CableLabs, SCTE•ISBE, CTA, and ATIS. Kinney is an avid cyclist currently living with his wife and two cats in Lawrenceville, GA. He is a graduate of the Georgia Institute of Technology.
shutterstock
