Choosing IoT connectivity technology needs careful consideration of multiple technical and commercial factors linked closely to individual use cases. Different applications favour different technologies so what the product is designed to do is a critical factor in the decision. This series of articles discusses what a successful LPWAN technology looks like.
Last time out we considered network capacity; this time we’re going to home in on one of the characteristics that most clearly defines where an IoT technology sits in the performance spectrum from simple and low cost one end to fully specified Industrial IoT at the other – Quality of Service.
If you’re following this series you’ll recall that I have grouped technologies into three categories – LAN/PAN at one end, 3GPP options at the other and an increasingly busy centre ground roughly described as LPWAN. This is the focus of these articles with the goal being to provide guidance on which is right for your application. No single technology is right for every product or use case so it is certainly not the intention of these articles to advocate a particular commercial proposition. Instead I am discussing the implications of the technology choice in terms of particular parameters.
Choosing connectivity technology is complex – there are a lot of features and benefits, often conflicting, to weigh in the balance. So these articles distil the key characteristics that define an IoT connectivity technology to identify those important to your particular use cases. We think that the strength of an IoT connectivity technology can be defined in terms of the following eight parameters. Today we’re focusing on the second in this list – Quality of Service.
- Capacity
- Quality of Service
- Range
- Reliability
- Battery life
- Security
- Cost
- Proprietary vs Standard
QoS
When IoT users talk about quality of service (QoS) they are typically referring to particular requirements for message delivery such as speed of arrival and probability of successful reception. This might be encapsulated in statements such as “emergency messages much be received within 2s”.
Most users understand that there are trade-offs associated with QoS. For example, message delay is often caused by network congestion, so simply over-sizing the network can improve QoS, but at a cost. Short delay times typically limit the ability of devices to move into idle mode and therefore result in much shorter battery life. A network designed just for high QoS requirements would be a little like a parallel road system designed just for emergency vehicles – it would do the job well but be prohibitively expensive.
The best approach is a flexible system that can deliver different QoS outcomes according to need, prioritising the high QoS traffic over the low. This is more akin to our current road system where vehicles with flashing blue lights can move ahead of others in any congested situation.
Before looking at how best this might be achieved, it is worth exploring the limits of QoS guarantees. No system can provide an absolute guarantee that all high QoS messages will be delivered successfully in a short time period. The device may be out of coverage. A base station might be down. There might be local interference from other users. The best that any network can do is aim for a high probability (eg 99%) that under specified use cases the requirement will be met.
Is licensed spectrum necessary for high QoS?
It is sometimes claimed that only networks using licensed spectrum can reliably provide high QoS. This is predicated on the assumption that in unlicensed spectrum interference cannot be controlled and without full control of all relevant factors the operator cannot provide the guarantees needed. Clearly having more control over all key factors makes it easier to meet requirements, but it is not necessary. To continue the analogy, parcel delivery companies guarantee next-day QoS even though they use shared road systems rather than their own dedicated network. They succeed because the level of congestion is generally predictable and systems in place to mitigate the effects of unexpected congestion such as re-routing solutions. The same is true in unlicensed spectrum. Interference will tend to build slowly over time and be predicable and increasingly “mapped”. Solutions such as frequency hopping can mitigate the worst effects and in the longer term interfering users could opt to coordinate between themselves or additional frequency bands could be added to the solution. It may require the operator to work a little harder, but experience suggests that dedicated spectrum is not a prerequisite for providing high QoS.
High QoS messages are nearly always unpredictable as to when they will occur (the routine report of “all’s well” from a monitoring unit rarely requires high QoS). If the messages originate at the device then there needs to be a rapid and reliable random access mechanism. One of the best ways to achieve this is to have a subset of the random access resource set aside for high QoS applications. This subset can be heavily over-dimensioned without having a major impact on the rest of the network. However, this does require that the system specifications detail how the sub-channel will work, where it will be located and under what circumstances devices are entitled to use it. If the messages originate in the network then there is less difficulty in getting the network to schedule them immediately but devices need to be awake to receive them. This means that these devices need to be very frequently monitoring paging channels which will inevitably result in increased battery drain. By allowing devices to determine their optimal idle time, such “always-on” devices can be accommodated without impacting the rest of the network.
There are other factors that might also come into play. The times when high QoS is required are often those when a major incident occurs such as a terrorist attack or unusually severe weather conditions. Such an incident can trigger communications from all end points leading to congested networks. This may be equally true in IoT networks where a power outage can trigger all smart meters in a city to send repeated “power out” alerts. This can swamp networks to the extent that a re-boot is needed resulting in no messages getting through until the network has overcome the congestion. Having solutions that can deal effectively and quickly with widespread alert messages can ensure networks stay available.
Ultimately, affordable QoS is all about intelligent network design. This needs to be at the heart of the technology standard with a range of options to meet diverse needs.
What defines a high QoS network?
LPWAN technologies fall into three categories – uplink only, uplink and partial downlink capability and 100% fully acknowledged transmissions. As we shall see shortly, any discussion on QoS fundamentally needs to address the technology’s downlink capability. The downlink provides the channel though which the network acknowledges a transmission from a device in order to confirm that it was properly received. In simple terms, unless the technology supports acknowledgment of 100% of uplink transmissions, QoS will be compromised. In previous articles I have argued that the underlying technology and modulation scheme are critically important factors in determination of network characteristics. Well, unsurprisingly, that same logic holds true here so let’s consider the three primary options and their associated impact on QoS.
Full acknowledgement? Check the small print
Ultra narrow band modulation schemes can support full acknowledgement – Telensa for example has a UNB solution offering high QoS. But just because the underlying capability is implicitly possible within the constraints of the modulation scheme it should not be interpreted as an indication that this capability makes it into the commercial technology that you buy. The large print giveth and the small print taketh away – in some UNB solutions it explicitly doesn’t!
Is the situation with spread spectrum technologies any better for QoS then? Well, similarly, wide band modulation schemes can support full acknowledgement – the original Weightless-W technology (designed to operate in white space spectrum so not considered further here) is an example. Some other wide band solutions do not. Surprisingly, a well known LPWA technology inaccurately claims to offer full acknowledgement but in fact downlink capabilities are limited to a very small proportion of uplink transmissions meaning that reliability and QoS is compromised. That small print again.
Weightless-P is an Industrial Internet of Things (IIoT) technology. It supports full acknowledgement of all transmissions where required. Weightless-P also supports acknowledged and unacknowledged unicast and multicast traffic. It offers a flexible acknowledgement scheme including deferred and combined acknowledgement for improved resource usage. It also supports both network originated and device originated traffic with paging capacity and low latency in both uplink and downlink. It enables fast network acquisition, Forward Error Correction (FEC), Automatic Retransmission Request (ARQ), Adaptive Channel Coding (ACC), handover, roaming and cell re-selection. Real bidirectional capability also supports over-the-air firmware upgrade and security key negotiation or replacement.
Unsurprisingly, NB-IoT, which will operate in plenty of high bandwidth, licensed spectrum with less stringent regulatory control over transmit power will offer high QoS through full acknowledgement. This is the gold standard in performance terms but, as we noted in the first in this series of articles, NB-IoT is still some years away from commercial deployment and will almost certainly command a cost and energy consumption premium.
