Comcast’s MachineQ has opened up about its quiet change in strategy, which has seen it pull back on plans to build all-encompassing LoRaWAN networks in the US, acting as a network operator for the unlicensed-spectrum LPWAN technology (U-LPWAN). After listening to customer feedback, it has begun pivoting to cater for the demands of a DIY crowd that wants coverage in specific geographic locations, and not access to expansive national networks.
We have long been of the opinion that LoRaWAN is best suited to campus-based deployments, where only a handful of gateways might be needed to provide connectivity for thousands or tens of thousands of devices, within a relatively small geographic area. On a cost basis, this is something on which the MNOs can’t compete without radically reinventing the way they charge for their services.
This isn’t to say that LoRa doesn’t have a place in the WAN market, rather that it currently enjoys a clear advantage over MNO rivals in a largely untapped market. Many MNOs have deployed LoRaWAN networks in their territories, but whether more choose to do so now that the L-LPWAN options are viable alternatives will be indicative. If more MNOs continue to sign-up to the LoRa Alliance, then that might change our thinking.
Nonetheless, there is still heaps of room in the LPWAN sector for all manner of approaches. LoRaWAN, thanks to its developer community and use of unlicensed spectrum, isn’t all that much more complex for an IT department to handle than WiFi, meaning that it can be quickly integrated into existing enterprise or commercial deployments. It also scales well, with more capacity simply being a case of adding more gateways – although we’ve heard that there’s not much need for gateways with many channels, as the 8-channel and 16-channel equipment is very capable and not exactly prone to congestion.
Speaking to Light Reading, MachineQ’s general manager Alex Khorram, said that “when we first started, we were out there building networks, strategically, to see what customers and the market wanted.” Khorram said that MachineQ found that many “desired a different relationship with the technology,” that would use networks deployed at manufacturing facilities, medical campuses, or retail locations. Khorram said that these customers “just needed the basic tools.”
Khorram expanded, saying that the customers and partners were more interested in the DIY approach, rather than using a network provided by MachineQ. To this end, they want to purchase products and software, to then install their own systems at their desired locations.
This would be an existential threat for MachineQ if it had not decided to offer the hardware and tools needed, as these customers would simply turn to other providers – and there are quite a few of them. MachineQ can also hook up its customers with its parent Comcast’s business internet services, and from this perspective, MachineQ’s pivot isn’t so concerning, as it’s still bringing in revenue.
But this does indicate that we aren’t going to be seeing a national US MachineQ network, which isn’t great for LoRa advocates, as it was one of the most promising firms that would be able to bring about national coverage in the country that has broken both Sigfox and Ingenu. Neither of these managed to blanket the country, and while the latter is apparently not quite dead, many believe the former is in serious trouble.
So then, MachineQ is now a seller of networking hardware, the MQflex sensor, developer kits, antennae, and power-over-ethernet boxes. It has supporting software for this equipment, as well as a cloud-based platform for accessing the data pulled from the LoRaWAN environments, called MQcentral.
With the pivot came a rebrand (now MachineQ, not machineQ … ) and a more focused set of target applications. It lists its enterprise solutions use cases as: temperature monitoring, asset tracking, predictive maintenance, facilities management, pest control, energy management, utility monitoring, and leak detection.
You will note that most of those involve static, that is non-mobile, applications. This is something that has cropped up a lot in our discussions with/about the LoRaWAN ecosystem – that most of the use cases don’t need the mobility aspects promised by national networks. As such, this means that they are well served by this campus-sized approach, akin to very large private WLANs, and in use cases that absolutely need national mobility, the argument is that these would be high-value enough to plump for a cellular or satellite-based connection.
This is something that is carried over into MachineQ’s example customers – PNI (parking sensors), Mission Data (restaurant and food service management), Fairway IQ (golf course management), Stratis (building management, energy services), Storm Sensor (water and flood monitoring), Sensoterra (irrigation monitoring), Subeca (water utility services), Vutiliti (energy utility monitoring), H2O Degree (utility metering), and Concrete Sensors (construction, concrete curing).
Whether this is a trend seen in early adopters, and that in time more truly mobile applications emerge, remains to be seen. The same accusation can easily be leveled at the L-LPWAN camp, and our ‘low cost equals low value’ aphorism implies that in applications where guaranteed coverage is a must, these would be playing at much higher price-points than those banded around by the LPWAN ecosystem.