As Internet of Things infrastructure starts to really ramp up, one of the things I don’t see a lot of attention being placed on in the media, is who is going to install all of the wireless devices on these networks, particularly those private LPWA network devices.
Cellular M2M deployments have been relatively easy because the networks are fairly mature. Cellular carriers have been building out and refining their coverage since the early 1990’s. Customers assume the network is there and active, and have simple tools to test if there is connectivity. The easiest of which is to look on your cell phone and see how many bars you have for coverage. But what do you do with devices on the new networks that are just starting to be deployed?
This is a key question to answer if we are to get to the billions of devices projected to be deployed in the IoT. If these remote wireless devices are easy to install and are truly “plug and play” then the rapid deployment can happen. From what I have seen so far, these networks and LPWA systems still require a lot of work to set up and activate a single device, and this is once you have a solid wireless link. Very few of the applications out there are self-activating. But this is a topic for another article. Let’s start with basics of how these IoT applications are getting the wireless coverage in place for their customers.
Public LPWA (Low Power Wide Area) networks, like Sigfox and Ingenu, will work like the cellular networks today. Customers will contract with the network providers for coverage in an area and simply hook up their devices to the appropriate wireless modems and look for a signal. Typically most LPWA module or modem manufactures have a red or green light for connectivity. If the green light comes on, the device is talking to the network. Some have a “test” button to send a burst of data on demand. This way you can turn the device on and go to your cloud-based application and see if data starts coming in from the device. If data is flowing as it should, you move on to the next installation. If data is not, then the problems start. Is it a device issue, a coverage issue, a software issue, etc.
Luckily there are network tester tools starting to come on the market to help customers with their installation needs for these public networks. Sigfox has a first generation handheld network tester for its installers with integrated GPS with a LED light that provides link status, green if the link is there and red if not. It also provides some basic info on link quality (blinks 3 times in white if it is very good, 2 times if it is good, etc.). I’m not sure what this translates into in terms of RSSI or link margin, but as a simple tool, it gives you an indication that a signal is present. How available this tool is and whether end customers can get access to is and unknown as of now. Ingenu has a similar tool for its installation crews.
But what about the private networks being built on technologies like LoRa? Luckily, two leading Lora module/modem manufacturers, Link Labs and MultiTech have early versions of a network tester. The MultiTech device is more advanced and supports both European and US frequencies. Both include GPS so you can tie location data to signal strength, but Link Labs only works with its proprietary version of LoRa, Symphony Link.
Both of these tools are just now starting to get used and both companies are working on upgraded versions that will be much more useful and complete products. That said, these are critical tools for deployment. What’s missing in these tools for the private network deployments is the back end software and rules based engines that tell installers how to best locate their hardware for optimal network coverage.
What are these private networks used for? They are typically the Smart Building, Smart City or Smart Agriculture networks where only farm or in building wireless coverage is required. These could be for HVAC management, irrigation management, access control, etc. The typical LoRa network deployment strategy would be placing a single gateway somewhere in the center of the area to be covered and then checking to see if you can get connectivity in all the places you want. For a 5 story building, this might mean putting the device on the 2nd floor and seeing if you can connect from the roof or basement. Connectivity is not just answering the question of can the device connect. You also need to think about how much link margin you need for the connection. This is why the Red Light/Green Light kind of tool doesn’t suffice. You need to know that you have a strong connection and you need to understand what can affect this connectivity.
Here’s an example. A customer goes out to a 7-story building to install several dozen connected bathroom products (monitored soap dispenser, etc.). They pick a mid point in the building and put the LoRa gateway in a telecom closet on the 4th floor. Using the red light/green light tool, they install devices on all floors and get green lights. The installation crew then leaves. The customer fires up his application and sees that data is now coming in for the new install and things are good. As weeks pass, the customer sees that they are getting sporadic data from a few of the devices. Then one day several of the devices stop communicating.
Since the customer hasn’t changed anything, he assumes that there is a problem with either hardware or the network. A crew is then dispatched to go figure out the issue. They start by swapping out hardware in the problem bathrooms. The problem persists so they swap out gateways, but the problem is still there. Finally, they add a second gateway and the problem goes away.
What they didn’t know is that the link margin was always very low on a number of the bathrooms on the lower levels and that when a tenant moved a wall of metal filing cabinets in front of the telecom closet, the link went away. How do you plan for this?
Actually, this is exactly what you need to plan for, environmental changes. Things are always going to change. You need to make sure that your network is designed to meet these challenges. If not, you are going to spend a lot of money on truck rolls.
This is where these simple network testers fall short and where there is a bit of a void in the eco-system needed to provide help with the network design, coverage analysis, and implementation plans. While the fact that these networks are unlicensed may make you think they are as easy as installing your home WiFi, you’d be wrong.
You need to understand the environment you are in and how it can change; what link margin you need to deal with this. To overcome tenant changes, what link margin is really required? You should err on the side of over building because the second router or repeater installed initially is going to be less expensive than a truck roll to fix the problem.
You need to understand what other networks are around you. Is NextNav or another high-powered 900 MHz network coming to a building near you? Are you communicating to outdoor devices from an indoor gateway? How will this change with ice in the winter or foliage in the summer? In working with networks over these years, I’ve seen all of these be issues for networks that weren’t installed properly. Customers would call and say “your stuff is not working, come fix it”. The real issue was of course that it was not installed properly. The customer didn’t understand the issues involved and the hardware manufacturer didn’t give this kind of installation direction.
This is where IOT consulting firms like Widelity can help both manufacturers and end customers alike. For the hardware manufacturers, we can help to build rule-based installation plans, systems and tools for your customers. The easier the installs go, the faster customers roll out, the more hardware gets sold. For end customers we can help to avoid the typical installation missteps by building a detailed and ruled based program for you. This can either be used internally if the company is planning on doing their own installations, or handed off to a third-party installation company.
For more information contact email@example.com.