One way that the unlicensed low power WANs (U-LPWANs) could extend their base, despite the increasing number of licensed network roll-outs by MNOs, is to create truly open platforms, lowering barriers to entry for device makers and service providers, WiFi-style. LoRa, the most widely deployed of the U-LPWANs, may be trying just that with its main technology developer, Semtech, releasing a first batch of code into the ope source process.
This code is the first instalment in the LoRa Basics system and developer program, which has three aims – to ease deployment of LoRa networks; to attract a far wider base of developers and other stakeholders; and to counter the criticism that LoRa remains too dependent on a single chip and IPR provider, Semtech itself.
The first items into open source are LoRa Basics Stationcode – for Linux gateways – and LoRa Basics MAC, RF firmware for end nodes. Future releases will include over-the-air firmware updates based on MAC as well as a data analytics package. Among the ways that this open source offering will simplify deployment of LoRa systems is to eliminate the need to program in embedded C in order to install a network.
This should bring the technology in easier reach of companies with small, or no, IT departments, said Semtech. These are also often companies that fall under the radar of the telcos and so struggle to get connectivity – making them a sweet spot for unlicensed alternatives, perhaps in the hands of providers and integrators with a focus on medium-sized businesses, or particular verticals and use cases.
“Most people are working with web services in Python or js.node, and programming devices is a last hurdle for them – embedded C developers are a dying breed,” said Steven Hegenderfer of Semtech, who is tasked with building up the LoRa developer community. “Basics takes the plumbing out of the way and helps users get up and running with a process that looks more like device configuration than coding,” he told EETimes.
In future, the gateway software may be evolved to run on real time operating systems, to target a wider range of devices and applications. The MAC firmware runs on a 32-bit, 50 MHz microcontroller with at least 64KB RAM. Both packages are available free under a BSD 3.0 open source licence.
There is a need for LoRa to extend its base and reach out to new deployers as the headstart that U-LPWANs gained over their licensed spectrum rivals is being rapidly eroded now the LTE-based standards, NB-IoT and LTE-M, are in mass deployments. The race between the two categories – but also the need for both options, to support the widest range of applications and service providers – is clearly seen in the USA.
There, Sprint has announced that it is testing NB-IoT (also now called LTE Cat-NB) in its network, and will deploy the licensed-spectrum LPWAN (L-LPWAN) technology if it sees enough interest from customers. This is not the build-it-and-they-will-come approach used by its rivals, but seems wise for the number four MNO in the market – especially as it hopes to merge with number three T-Mobile, which is already a Cat-NB advocate.
For now, Sprint says it has an ongoing trial, while T-Mobile (perhaps influenced by its Deutsche Telekom parent) says it has a national network already. Earlier last week, AT&T said it too now had a national NB-IoT network, and Verizon has been deploying the technology since last year.
On the sidelines lurks Dish, the satellite TV firm, which has been deploying an NB-IoT network that has been rumored to be of interest to Amazon (see separate item).
As for LTE Cat-M – the higher powered standard for applications that need faster data rates and are less battery-life sensitive – AT&T and Verizon are both supporting that option. At first, by contrast with most other MNOs in the world, they were focused mainly on Cat-M, while in Europe and Asia it has been far more common to deploy NB-IoT first.
The US operators are not talking numbers or demand levels for their networks and revenues are well hidden behind contracts and NDAs, so it is hard to know how the licensed and unlicensed systems are shaping up in commercial terms. The MNOs are mainly building wide-scale networks which will support any number of users or service providers, while the U-LPWANs are more commonly deployed as private networks for a particular enterprise or vertical; or by a public operator to cover a specific set of locations and use cases.
On the pricing front, AT&T has said that it is working with suppliers to get $5 NB-IoT modules, and says that the dual-mode NB/Cat-M modules are not far behind. It adds that it has pricing plans that can start as low as $5 per year per device – although when you follow that link, you’ll find that you need to add taxes and fees to this figure, and that what is actually advertised is a $30 per year per device plan, which is limited to 64 kbps of throughput.
Also, there is an LTE data plan for North America and one for international use, which both start at $3, as well as a North America LTE Cat-M plan, which also starts at $3. There’s no mention of NB-IoT on this page, and the One Rate plan from before is listed at $32, rather than $30.
So, the starting price includes the cost of the SIM ($2) and the first of the monthly recurring charges of $1. This means that an LTE-M package is going to cost a minimum of $14 per year, for the lowest bucket of monthly data, 500KB. You will also have to be using an approved module.
Going upwards, 1MB costs $1.50 per month ($20 for that first year, $18 per year thereafter), 5MB is $4 per month ($50 per year), 10MB is $6/month, 50MB is $12/month, 500MB is $20/month, 1GB is $22/month, 5GB is $35/month, and the highest tier of 10GB is $60/month. Strangely, there’s no differentiation between International (LTE), North American (LTE), and US (LTE Cat-M) prices, until you get past 50MB per month.
Based on these numbers, the One Rate plan only makes sense once you get above needing 2MB per month, although the wording in the terms is somewhat vague. AT&T says that you can’t have a continuous unattended connection, and that it may proactively reassign the customer to one of the other data plans unless your customer agreement has prohibited that. So good luck to those that think they got a great deal on the $32 One Rate deal but then get punted across to anything higher than the 5MB plan.
IoT pricing is tough for the operator though. Some IoT devices have such small messaging needs that even 500 KB per month is overkill, and unless there is a mission critical function at stake, even the lowest ends of AT&T’s pricing schemes make simple sensing functions cost prohibitive. Once you add in the cost of buying the sensor device, the truck roll costs for installation, and then the provisioning, the kind of sensor that needs less than 500KB of monthly data has a far higher total cost of ownership than you might first assume based on the data plan.
At the other extreme, if you have a video or image-based application, then the 10GB plan might tickle your fancy – that is, until you figure out that over the course of a planned three-year deployment, you’ll have spent $2,160 on just data packages for just one device. In an application that takes place inside a small geographic footprint, using say ten devices, one wonders if it might be cheaper to go about installing an Ethernet or WiFi alternative, given that you have $22,000 to spend on it, and will have a power supply for each of these devices. This is an issue that scales with the number of devices.
So then, it looks like the L-LPWAN crowd get relegated to focusing on the middle ground, for mobile devices that move around in the world but always need a network connection, where you can’t just roll a fixed line alternative to counter high data costs.
If U-LPWAN provider Sigfox is really both willing and able to manage $1 per year pricing, then the MNOs are not going to want to chase that, and in deployments dense with devices (such as a university campus), the ongoing per-device costs are going to push them towards a LoRaWAN network. Smart grid and asset tracking could be the biggest battlegrounds, but as there is such variety between application requirements, we are never going to be able to know with certainty which way a customer will lean. Smart city types should be paying more attention to Wi-SUN though.