The recent Things Conference saw several announcements in the world of LoRA, the leading low power WAN technology in unlicensed spectrum (U-LPWAN).
The main chip provider for LoRa, Semtech, announced the launch of a 2.4 GHz version of the technology, initially aimed at shipping applications. Previous implementations have all been in sub-GHz spectrum (900 MHz/868 MHz ISM bands) which allow for longer range, but lower bandwidth, than 2.4 GHz. The new band option could therefore extend the range of applications addressable by LoRa, but comes with the significant downside of being very congested as it already houses WiFi and some wireless personal area network protocols, as well as signals from other devices like microwave ovens.
Another potential major caveat is that the new spec does not yet support the full LoRaWAN architecture, since there has, as yet, not been a statement of support from the LoRa Alliance – the body that standardizes and certifies the networking elements of the LoRaWAN stack, excluding the actual LoRa radio IP that Semtech still wholly owns.
Although it seems likely that the Alliance will add the new variant to its platform, that is not inevitable. Lack of certification would risk restricting the range of multivendor, affordable equipment and devices, and lead to a significant splintering of the ecosystem.
Up till now, LoRaWAN has been more or less standard. Its main sticking points have been the spectrum it operates in, which varies by region, and which version of LoRaWAN was running on the device itself. The biggest problem is whether a user can roam internationally, but with the launch of the Things Network’s Packet Broker, there is now a mechanism to create interconnects between different gateways and networks (see below). And a new one-time device provisioning Join Server will solve most of the other headaches that have plagued LoRa since launch.
We would have finally reached something like the end of the checklist, with the LoRaWAN community having created all the necessary elements and tools to make LoRaWAN a truly mass market proposition. The sector has come a long way from the silicon plus UDP packet forwarder that Semtech had developed for testing, which was seized on by early adopters because it was the only available option at the time.
However, 2.4 GHz is something of a spanner in the works in terms of harmonization. Initially, it looks like a Semtech attempt to solve the lack of a unified global spectrum option, by putting LoRa into the universal 2.4 GHz band. But it reduces one of the main selling points of LoRa – its Long Range (hence the name). In the announcement, we were told that in urban environments, it is going to be around 10% of the range of sub-GHz LoRa, which is fine for the initial shipping application, but is definitely stretching the boundaries of a true wide area network.
Another LPWAN contender, Ingenu’s RPMA protocol, also ran in the 2.4 GHz band. This choice led to many writing it off, as the band was understood to be too noisy and prone to interference, and though Ingenu did manage to make it work efficiently, the spectrum choice seemed to have been a factor in the failure to achieve significant market uptake (ee understand it has recently been acquired by another investor).
Of course, there are merits to running LoRa in 2.4 GHz. The radio chip that will initially power this, the SX1280, should be capable, and Semtech apparently has an announcement coming in Q2 regarding dual-mode 2.4 GHz chips, which might see LoRa paired with the likes of Bluetooth and WiFi.
There should also not be much of a price difference between the 2.4 GHz radio and the sub-GHz version, based on the announcement, which presented the findings from a test deployment on a Roll-On Roll-Off (RoRo) ship from Wilhelmsen, a Norwegian shipping firm. Semtech had discovered that Wilhelmsen was already experimenting with LoRa sensors, which led to the two partnering on a more encompassing trial. This led to some 300 sensors being deployed, which were able to achieve 10-year battery life, sending four measurements per day (split across several messages, due to their size). By all accounts, the sensors were very capable, and had provisioning and onlining tools that were simple enough to be deployed by regular crew members rather than specialist technicians.
Once one ship, or one line of ships, has a LoRa network in place, to monitor its myriad operational functions, tracking the assets and containers that the ship is carrying could be added to the line-up of LoRa applications. What’s more, with the Things Network Packet Broker, it is clear how this would remove a lot of the headaches from deploying LoRa for a global application like shipping, as there would be no need to get the local network operators involved. Instead, the network coverage requirements can be left to the companies involved in the application itself, in this case shipping firms and ports