This week’s episode examines several interesting standards relevant to connectivity and IoT. First are Matter and Thread, which collectively promise to drive the smart home market. Additionally Matt looks at the 5G Network Data Analytics Function (NWDAF) and the Lightweight M2M (LwM2M) device management protocol.
You can access the podcast here, or via Google, Apple, Amazon or Spotify.
An approximate transcript of the podcast is available below:
Welcome to this week’s Wireless Noodle. This week I’ll be drilling into some interesting IoT technologies. First up is the new emerging standards for connected home, Matter and Thread. Then something a little technical in the form of 5G Network Data Analytics function (NWDAF). Finally a look at Lightweight M2M, the standard for device management, particularly relevant for constrained IoT devices.
Smart home: Matter and Thread
The smart home market has been perpetually on the cusp of explosion for the last decade or two. However, with the exception of point solutions such as Amazon Echo, Nest and Ring adoption has been relatively slow. While there may be appealing individual devices no-one has quite cracked the creation of a smart home ecosystem supporting multiple device types. Samsung SmartThings is perhaps the closest. It is possible that this is set to change with the arrival of two standards: Matter and Thread.
Matter is a smart home interoperability protocol developed by the Project Connected Home over IP (CHIP) working group within the Connectivity Standards Alliance (CSA). The CSA was formerly the Zigbee Alliance but expanded its scope beyond the core Zigbee technology. Its membership includes Amazon, Apple, Google, Huawei, Legrand, NXP, Samsung SmartThings, Schneider Electric and Signify.
The fully open Matter 1.0 standard will allow for compatibility between smart home devices. Matter does not create a new communications technology, but instead uses existing standards in the form of Ethernet, WiFi and Thread.
Matter 1.0 will be released in late 2022, having been delayed due to expansion in testing and validation. Ahead of the official launch, several of the members have begun pre-release testing of devices from various vendors. Reportedly Matter ended 2021 with 130 devices.
The list of vendors that have announced support for Matter is extensive, including the usual smart home suspects, Apple, Amazon, Google, Samsung, as well as a broad range of others including Philips Hue, Yale Home, Arlo, Bosch, Danfoss, Ikea, GE, Johnson Controls, LG, Lidl and Osram.
For developers, Matter eases the challenges of building products that are compatible with Amazon, Apple, Google, Samsung and other environments, allowing the user to manage them from any platform. For consumers, logos will be used to acknowledge certified devices and they will not be tied to closed systems supported by single vendors.
Matter promises to be the default networking technology for smart home.
One of the key things that Matter does is to make the Thread standard more important. It is one of the few communications protocols supported by Matter.
Thread was developed in 2014 by a group of vendors including ARM, Nest Labs and Samsung, and later Apple, as a low-power self-healing mesh network to support IoT devices. It is based on the 802.15.4-2006 standard, similar to Zigbee and BLE. The addition of Apple has been notable because it has always shied away from supporting Zigbee, favouring solely WiFi and Bluetooth.
Thread’s big advantage over WiFi is that power consumption can be tiny. By virtue of a highly optimised set of protocols (IP, UDP, 6LoWPAN) packet overheads are small (sub-100 bytes) and handshakes and polling are minimised, giving long battery life.
Compared to Bluetooth Low Energy (BLE), and specifically the mesh version BLE Mesh, performance is more similar. But, the critical challenge for BLE is in the support it receives from vendors. The likes of Apple, Google and Samsung are very much favouring Thread. Add to this that it’s not supported by Matter, other than for initial configuration.
But, it has to be said, there is currently quite a limited range of devices that support Thread.
The arrival of a new set of commonly adopted standards raises the prospect of an acceleration in the growth of the connected home. It won’t be an overnight explosion, simply due to the inherent inertia related to installing smart devices in the home, typically only at the point when older legacy devices such as lighting, air-conditioning or white goods are replaced.
Doing a little number crunching in the report, based on the hyper-granular data in the Transforma Insights IoT Forecast Database, we found that smart home applications will account for 40% of all IoT devices by 2030 (up from 37% in 2020). The smart home is growing even faster than the overall IoT market, particularly between now and 2025. A key part of the growth over the next ten years is in the increasing availability of standardised open ecosystems that simplify the process of developing IoT devices and provide certainty for the end user over interoperability. The connected home is continuing to move away from closed systems based on single vendors. Matter is a critical element in this, and Thread also to a lesser extent.
5G NWDAF
Next up Network Data Analytics Function, or NWDAF. For those of you who tuned in to Episode 3 you’ll remember I spoke about how true innovation in any given technology sector requires the separation of the hardware layer from software/control. This innovation then translates into an explosion of adoption of products and services. Similar trends are manifesting in other sectors today through the concept of IT/OT convergence. With technology developments such as Network Function Virtualisation (NFV), 5G’s Services Based Architecture and NWDAF, we see this trend also play out in the telecoms sector.
One of the key features of 5G is that it creates a modular Service-Based Architecture delivered through Network Functions (NFs). Network Data Analytics Function (NWDAF) allows the data from those NFs to be analysed and functions to be automated. This presents the possibility of enabling and accelerating innovation in new services through exposing the insights and functionality delivered via 5G networks. By doing so, NWDAF holds the key to releasing some of the value of 5G.
So, what is NWDAF?
Network Data Analytics Function (NWDAF) is a set of functionality specified in 3GPP’s release 16, which was frozen in July 2020. NWDAF is part of 5G’s Service-Based Architecture (SBA) which sees the control plane functions delivered through a set of modular software-based ‘Network Functions’ (NFs) relating to the different elements of the operation of the network (e.g. authentication, session management or policy control), each able to access other NFs through standardised APIs. NWDAF involves the application of analytics to these functions of the 5G core network to analyse and automate core network functions and operations, including introducing predictive capabilities. Historically MNOs relied on network probes to monitor the function of the network, whereas NWDAF collects data natively from various NFs, and, via an orchestrator, is able to ‘close the loop’ and automatically make changes to network functions as necessary.
This functionality allows for a range of analytics capabilities (some involving AI/ML) to be applied to network functionality. These include: load analytics and prediction for different network functions, network performance analytics, including load performance and future predictions, data congestion analytics, and network slice management, in terms of load-level calculation.
In addition to the present analytics function it also allows for open APIs to third party developers, to build analytics functions on top of the data, and to end users.
The opportunities from this technology are quite substantial. The main on is cost savings through more efficient operations. It provides for mobile network operators to improve efficiency of network operations, for instance by anomaly detection or network optimisation and resource allocation being used to avoid congestion, rather than having to invest further in sites and/or spectrum.
However, few MNOs will be content simply with cost savings as a justification for implementing 5G. They will look additionally for revenue opportunities. The aforementioned predictive behaviour analysis and avoidance of congestion could be monetised through the delivery of superior grade-of-service, quality of experience (QoE), or a tailored service reflecting a preferred trade-off for the customer. As an example of the latter, there are likely to be devices that would prioritise coverage over bandwidth, or latency over cost.
Also, they could offer enhanced guarantees over quality of services (QoS). This is one of the keys to unlocking the enterprise opportunity. For many use cases, enterprises are entrusting their mission-critical applications to a mobile network, for instance in industrial IoT use cases, or delivering a guaranteed feed for encrypted video footage. Offering nothing better than a best-effort service is not compatible with that aim.
I don’t plan on addressing network slicing here, but NWDAF capabilities are also good for supporting slicing.
Of course, it’s not all plan sailing. There’s legacy networks in the form of LTE, which won’t support the functionality. There’s also a whole load of other standards and technologies that perform similar functions. Plus privacy and policy management challenges crop up, particularly when AI is used.
NWDAF is interesting, but perhaps one to really concern ourselves with in about 5 years time.
Lightweight M2M
Finally, Lightweight M2M. What is it? It’s a device management protocol. It was developed by the Open Mobile Alliance (OMA), which previously developed the OMA-DM standard for phones. OMA reinvented the OMA-DM standard to be more appropriate for IoT, as LwM2M. It is built on the Constrained Application Protocol (CoAP) on top of User Datagram Protocol (UDP) with RESTful APIs for device management, exposing device management resources such as security, connectivity, location and firmware upgrades.
LwM2M is a favoured device management protocol for use with constrained devices using NB-IoT and LTE-M technologies, and also to a lesser extent on LTE Cat-1 and Cat-0 devices.
There are some limitations to LwM2M. Its security is based on Datagram Transport Layer Security (DTLS). Historically, cloud platforms prefer data delivery using MQTT with Transport Layer Security (TLS), or similar. However, MQTT is based on the connection-oriented TCP, and uses TLS for its security, which is also a heavy protocol. LwM2M uses UDP and its associated security protocol, DTLS.
There are a few alternatives to LwM2M for device management. The first is to use vendor-specific device management capabilities, typically based on MQTT. There are numerous examples here, including Digi’s Remote Manager, Telit’s DeviceWISE or Sierra Wireless’ AirVantage .
The other standards that might be relevant have really not been designed for IoT devices, although they are appropriate in the context of less constrained devices, for instance those using 4G and 5G, or ethernet. These include:
- Open Mobile Alliance Device Management (OMA-DM) is designed for devices with more resources, including gateways, routers, connected cars and other less-constrained devices.
- TR-069 (or Technical Report 069) is a specification from the Broadband Forum for remote management of broadband customer premises equipment (CPE).
- TR-369, also known as ‘User Services Platform’ (USP), is the successor to TR-069, extending the device management functionality to IoT devices.
None of these other alternatives is really designed for constrained devices. The proprietary approaches using MQTT are the closest, but as noted before, this being a connection-oriented protocol based on TCP makes is inappropriate for constrained devices that need to minimise communication to maintain battery life.
Quite a few vendors support LwM2M. Technically speaking LwM2M is available on more or less all cellular devices to manage firmware for the modem, by virtue of the requirement from AT&T and Verizon in the US that it be included for that purpose. However, the implementation is somewhat clumsy, relying on AT commands. Communications Service Providers are big advocates, typically, and some enterprise end users in sectors like smart metering and lighting are advocating for it.
In the recent report ‘Lightweight M2M (LwM2M): what is it and how widespread is its use?’ we also forecast how widely adopted it will be. Today not huge, but becoming significant over the next 10 years.
Next week (or possibly a few weeks from now)
If 5G floats your boat, and particularly if you’re interested in the emerging space of mobile private networks, aka private wireless, I recommend you register for our webinar on the 26th September when I’ll share perspectives on both topics and how they overlap. Link: 'A marriage made on the campus? Developments in 5G and private networks and how they come together'.
Just a reminder: if you’re enjoying the podcast I’d be obliged if you could leave a review. It’s much appreciated.
I’m currently on my travels at various conferences and events over September and October so won’t have much time for pulling together a podcast episode. But I’m sure I’ll have a lot to report when I get back. So there may not be an episode for a few weeks. But I’m sure I’ll come armed with lots of thoughts from MWC Las Vegas, IoT Tech Expo, The Things Conference, and many more shows.
Comments