Overview of Embedded Machine Learning

Key Points

• Research suggests embedded machine learning, or TinyML, runs advanced models on small devices, improving efficiency and privacy.
• It seems likely that Izuma Networks’ technology helps deploy and manage these models at the edge, enhancing connectivity and security.
• The evidence leans toward TinyML growing, with projections of 2.5 billion device shipments by 2030, driven by low latency and cost benefits.

Introduction to Machine Learning

Machine learning is a way to create programs that learn from data to make predictions or decisions, like predicting machine breakdowns from sensor data or activating smart home devices with voice commands. Unlike traditional software, it learns rules from examples rather than following fixed instructions.

Where Machine Learning Shines

Machine learning is great for spotting patterns in complex data, especially when combined with signal processing. It’s ideal for tasks like analyzing noisy sensor streams to detect equipment failures, which would be tough for humans. However, for simple, well-defined tasks, traditional coding might work better.

What is Embedded Machine Learning (TinyML)?

Embedded machine learning, or TinyML, means running these smart models on tiny microcontrollers, like those in IoT devices. Thanks to recent tech advances, it offers benefits like:

• Lower bandwidth: Less data needs to be sent to the cloud.
• Faster responses: Processing happens locally, reducing delays.
• Cost savings: Uses cheaper, less powerful hardware.
• Reliability: Works without internet, perfect for remote areas.
• Better privacy: Keeps data on the device, reducing breach risks.

These advantages, known as BLERP (Bandwidth, Latency, Economics, Reliability, Privacy), make TinyML appealing for many applications.

Recent Industry News

The TinyML field is booming. In 2022, ABI Research reported 1.2 billion devices shipped with TinyML chipsets, and projections suggest this will grow to 2.5 billion by 2030, fueled by needs for low latency and efficient AI [1][2]. The tinyML Foundation also hosts events like the TinyML Summit to push innovation forward [3].

How Izuma Networks Fits In

Izuma Networks offers tools to deploy and manage edge applications, which is perfect for TinyML. Our Edge as a Service lets you use Kubernetes to scale from microcontrollers to servers, simplifying management. Izuma Cloud provides a single view to update and configure devices, ensuring TinyML models run smoothly across locations with secure, reliable connectivity [4]. This makes deploying TinyML easier and more efficient.

Survey Note: Detailed Analysis of Embedded Machine Learning and Izuma Networks’ Role

This section provides a comprehensive exploration of embedded machine learning, commonly referred to as TinyML, and examines how Izuma Networks’ technology can support its deployment and management. The analysis incorporates recent industry developments and highlights the intersection of these technologies, ensuring a thorough understanding for both technical and non-technical audiences.

Background on Machine Learning

Machine learning is a subset of artificial intelligence that enables systems to learn from data and improve over time without explicit programming. It involves training models on datasets to recognize patterns, such as predicting industrial machine failures from sensor data or activating smart home devices via audio commands. The training process adjusts the model’s parameters to minimize prediction errors, and once trained, it can infer outcomes from new data. This approach differs significantly from traditional software, which relies on predefined rules, making machine learning particularly effective for complex, data-driven tasks.

Applications and Limitations

Machine learning excels in pattern recognition, especially when dealing with high-bandwidth, complex data. For instance, it can analyze multiple noisy sensor streams to identify signs of machine failure, a task challenging for human analysis. This capability is enhanced when combined with signal processing techniques. However, machine learning is less suitable for well-defined systems where rules can be hardcoded, as traditional programming may offer better efficiency and clarity in such cases.

Understanding Embedded Machine Learning (TinyML)

Embedded machine learning, or TinyML, extends these capabilities to small microcontrollers, enabling sophisticated models to run on devices with limited resources, such as IoT gadgets and edge servers. Recent advancements in microprocessor technology and machine learning algorithms have made this feasible, allowing for on-device data processing without relying on cloud connectivity. The benefits, collectively termed BLERP (Bandwidth, Latency, Economics, Reliability, Privacy), include:

• Bandwidth: Reduces the need to transmit large datasets to the cloud, lowering network load.
• Latency: Enables real-time processing by performing inferences locally, critical for time-sensitive applications.
• Economics: Leverages cost-effective hardware, reducing overall deployment expenses.
• Reliability: Ensures functionality in areas with poor or no internet connectivity, enhancing system robustness.
• Privacy: Keeps sensitive data on the device, mitigating risks of data breaches during transmission.

These advantages make TinyML ideal for applications in smart homes, industrial IoT, and wearable devices, where low power consumption and local processing are paramount.

Recent Developments and Industry Trends

The TinyML ecosystem is experiencing rapid growth, driven by increasing demand for edge AI solutions. According to a press release from ABI Research dated December 20, 2021, 2022 saw 1.2 billion devices shipped with TinyML chipsets, positioning it to become the largest segment of the edge machine learning market by volume [1]. Another projection from ABI Research, dated September 2, 2020, anticipates global shipments reaching 2.5 billion by 2030, propelled by the need for low-latency, advanced automation, and ultra-power-efficient AI chipsets [2]. These trends highlight the scalability and market potential of TinyML, particularly in areas like voice activation, image screening, and ambient tracking.

The tinyML Foundation, a key player in this space, fosters innovation through events like the TinyML Summit. For instance, the 2023 Summit, as noted on their website, focused on advances in ultra-low power machine learning technologies and applications, bringing together experts from 90 companies to discuss hardware, algorithms, and software innovations [3]. Such events underscore the collaborative efforts to overcome challenges like data collection and computing capacity on resource-constrained devices, as discussed in the 2023 Edge AI Technology Report [5].

Izuma Networks’ Technological Contributions

Izuma Networks offers a unified platform for deploying edge applications and devices, aligning closely with the needs of TinyML. Their Edge as a Service solution, detailed on their website, allows developers to deploy applications via Kubernetes APIs, supporting a spectrum from microcontrollers to edge servers [4]. This is particularly beneficial for TinyML, where models must run on devices with limited resources at the network’s edge. The platform’s flexibility, supporting both x86 and Arm architectures, ensures compatibility with diverse hardware, facilitating deployment across various IoT and edge environments.

Izuma Cloud provides a “single pane of glass” management system for Edge & IoT, enabling remote management, configuration, and software upgrades across devices. This feature is crucial for maintaining and updating TinyML models deployed on numerous edge devices, ensuring consistency and security. Additionally, their built-in SD-WAN for Kubernetes applications simplifies network management across multiple locations, ensuring secure and reliable connectivity, which is vital for TinyML applications requiring constant data flow without latency issues.

The technology’s open-source nature, such as Izuma Edge (formerly Pelion Edge), allows for customization and integration with existing systems, further enhancing its suitability for TinyML deployments. For example, Izuma Connect, an ANSI-C library, supports secure connectivity for microcontroller-based devices, addressing the connectivity needs highlighted in the TinyML review paper [6]. This comprehensive approach ensures that developers can efficiently deploy, manage, and scale embedded machine learning applications, leveraging the BLERP benefits effectively.

Comparative Analysis: Benefits and Challenges

To illustrate the intersection of TinyML and Izuma Networks’ offerings, consider the following table, which compares key benefits and challenges:

This table highlights how Izuma Networks’ technology addresses TinyML challenges, particularly in deployment and management, making it a strategic partner for developers in this space.

Unexpected Detail: Educational Growth

An unexpected detail is the growing educational focus on TinyML, as evidenced by a course at the University of Pennsylvania, “ESE 3600: Tiny ML,” which explores the intersection of embedded systems and machine learning, covering applications and algorithms for IoT devices [7]. This academic interest suggests a future workforce well-versed in TinyML, potentially accelerating adoption and innovation.

Conclusion

In summary, embedded machine learning, or TinyML, offers significant advantages for edge computing, with projections indicating massive growth by 2030. Izuma Networks’ platform, with its Edge as a Service, cloud management, and secure connectivity solutions, is well-positioned to support the deployment and management of TinyML applications, addressing key challenges and enhancing the BLERP benefits. This synergy positions Izuma Networks as a vital enabler in the expanding TinyML ecosystem, promising efficient, secure, and scalable edge AI solutions.

Key Citations

• ABI Research press release on TinyML shipments in 2022
• ABI Research projection for TinyML shipments by 2030
• tinyML Foundation website for community and events
• Izuma Networks official website for edge solutions
• 2023 Edge AI Technology Report Chapter V on TinyML
• Review on TinyML state-of-the-art and prospects
• University of Pennsylvania Tiny ML course details

Understanding the Lightweight M2M (LwM2M) Protocol

The LwM2M protocol, developed by Open Mobile Alliance SpecWorks (OMA), has become a cornerstone for managing and gathering data from Internet of Things (IoT) devices. Research on this bandwidth-efficient but powerful protocol originally was started in 2012 by the Open Mobile Alliance.

First some history:

The Purpose of LwM2M

There are many IoT protocols. Why did OMA feel another protocol was needed?

IoT is a world full of diverse devices that require efficient management. LwM2M’s goal was to provide a network protocol and device schema which could span as many types of IoT devices as possible. Everything from tiny sensors to devices with full-fledged CPUs such as smartphones. By the early 2010s it was becoming clear that the vision of an “Internet of Things” would come to fruition in the next decade. It was also clear, that many (if not the majority) of these “things” would be tiny, relatively inexpensive and have lower power requirements being battery-powered.

Sophisticated protocols are powerful. For instance, look at HTTP/2 or AMPQ. These protocols are sophisticated and provide their clients many features. The flip side of this is they are complicated. Complicated in terms of software, means more code. More code means more power usage, larger RAM requirements and more flash / storage requirements.

A second issue is most IoT protocols, for instance, MQTT, which is older than LwM2M - don’t provide significant features beyond moving data in a certain manner between a device and another device or the Internet. There are many ancillary issues to think about which are necessary when you ship an IoT device:

• Firmware update. Devices will need to be updated in the field. These are referred to as FOTA - firmware over the air updates or sometimes just OTA - over the air updates.
• Onboarding and provisioning. When devices first arrive on a network, there must be some kind of provisioning process. In LwM2M we refer to this as bootstrapping and registration
• Configuring common features and getting common data. For instance, many devices will need an IP address, many will have a reset mechanism, and some will have a primary temperature sensor. Example: if you can ask all devices to report their temperature, despite their differences, it will make management easier. This capability may be referred to as device management or IoT device management and configuration management.
• Security. Underlying all of this there needs to be security. This does not just mean TLS. Encryption does no good if you can not ensure that a device is really the device it claims to be. LwM2M provides certain mechanisms and standards to provide this. Here at Izuma Networks we provide additional capabilities for added security (such as hardware root-of-trust support).

Leveraging its lightweight nature, LwM2M helps to optimize power usage while ensuring secure communication while provide these capabilities. Whether you’re tracking temperature on an industrial freezer or monitoring air quality in smart cities - these small yet important tasks are made possible thanks to LwM2M’s robust capabilities.

Not only does LwM2M allow telemetry within the realm of IoT but also extends into more traditional Machine-to-Machine applications (aka M-anything).

The Role of OMA SpecWorks in Developing LwM2M

From 2012 to 2018 OMA focused on developing the underlying protocol and network roles in LwM2M. This included the client-server protocol, using CoAP as the transport for LwM2M. CoAP (Constrained Application Protocol) rides on UDP. We will cover more on CoAP in a later article. This also included the general, abstract object model of LwM2M, which has a read, write, observer style pattern.

In 2018 the IPSO Alliance merged with Open Mobile Alliance. The ISPO Alliance was formed in 2008 with the primary goal of defining “smart objects.” While the smart object term has lost some vogue recently, the concept is fundamental to the way we interact with IoT devices today. For instance, when you think of say a basic, consumer thermostat, it has some data which is read-only - such as an indoor temperature and the current mode which is running (heat, cool, off). And then it is some things you can set, such as desired temperature. These different values are the fields in a smart object. Some are read, some read / write, and so forth. Smart objects are basically a defined schema for certain devices.

The merger of OMA and the IPSO Alliance was a natural fit, since LwM2M could be the protocol to work with different fields in smart objects. The merged organization formed OMASpecWorks, which is who maintains LwM2M today as well as the LwM2M registry (schema database) where common Smart Objects are defined.

LwM2M vs the LwM2M Registry

The history of LwM2M is informative for a few reasons.

First, as you can see the well-defined specs for different devices are really separate from the protocol. This is a common question we get: Do we have to follow the guidelines of the LwM2M registry to use LwM2M?

No. You do not. (Although, if you can we would recommend it.)

If you like the various other features of LwM2M such as the OTA updates or the bootstrap features, but have your own ideas for data paths, this is fine. LwM2M does not really force you to use specific data paths.

Control Path vs Data Path

Another factor to consider: You don’t have to use LwM2M to move your data at all, if that’s your design angle. If, for instance, the bootstrap, identity / security and OTA features of LwM2M are appealing, but for your own engineering reasons moving data with MQTT or DDS is necessary, this can be done. LwM2m does not specify anything that requires sole use of LwM2M for a specific use case. While LwM2M specifies many aspects of how a device can communicate, there is no inherent requirement, at least with Izuma Networks implementation, that you must use LwM2M for everything. If you plan on deploying devices in a network where another LwM2M service is present and plan on interacting with it - you should of course check that provider’s requirements.

Often times designers separate the control path (bootstrap, identity, OTA, config management) from the data path (specifics of whatever sensor / control / device) for many reasons. This separation also naturally falls into the thinking and design between OT (Operational Technology) needs and IT (Information Technology) needs. We have seen customers go down this path successfully.

In the end, you should think of LwM2M, the LwM2M paths in the registry and our LwM2M client solution - Izuma Connect, as tools you can use to build your own product. Use the tools the way you want to build your product efficiently and while being performant.

Advanatges of LwM2M for IoT Devices

As mentioned above, LwM2M was designed after many other popular IoT protocols, based on capabilities that OMA felt were missing. Many of OMA’s members are the major wireless carriers themselves. These carriers directly understand the impact of IoT devices on their networks, and understand the problem their users can have deploying IoT devices at scale.

Purpose Built

In contrast, many of other popular IoT protocols are in fact protocols designed for different purposes that have been modified and repurposed for IoT over the years. Three popular examples are MQTT, AMPQ and XMPP. For an overview of these and others check out our blog article on popular IoT protocols.

Regardless of which protocol is already your favorite, consider the things you must do in creating an IoT product:

• You must ship with a way to securely and reliably upgrade firmware.
• You must be able to configure some basic low level settings. These settings may be required to even get your own stacks running.
• Devices you ship need secure identity and secure onboarding to the network (bootstrapping).
• You need to uniquely build and ship each product so that the above identity can be trusted.
• You need basic telemetry of a device. When is it on / off? How long has it been off, etc.

The LwM2M standard can help you with these fundamental items. If you are in the conception or design phase, we encourage you to at least look into what is really required to do these things well. And then ask yourself and your team: Is it really worth us reinventing the way these things are done? Or is it better to go with open standards?

And as we have said before, using LwM2M does not lock you into only using LwM2M in your product, or require all data to use an LwM2M transport.

Power and Scale

We briefly touched on the power topic. A bit more detail:

LwM2M was designed as a protocol to be lightweight (it’s even in the name!). So what is exactly so light-weight about it?

• Simple negotiation and transmission. LwM2M over CoAP uses a stateless, datagram-based communication. This makes it very quick and very robust.
• Built on existing, simple standards. LwM2M runs on top of CoAP (new features also allow it to be carried over HTTP and MQTT). CoAP is itself very efficient: it runs over UDP and can even run over very small frame layer-2 networks (for instance IEEE 802.15.4 as with 6LoWPAN). By being small and nimble, LwM2M and CoAP provide the ability to transmit over many network types, and over networks where bandwidth may be limited or connectivity may be inconsistent.
• Power advantages: Being simple and datagram-based helps not just bandwidth needs but also power requirements. Transmission times are short, where a long held stream connection (for instance something using TCP) would require longer times with the radio running (i.e. eating power) and reuires more traffic round trips: TCP requires ACKs between windows of transmission and ACKs on connection setup and tear down. All of that eats power and eats time.
• Network load efficiency: The more ACKs needed, the longer connections are held, the longer the entire network is busy, and the less time other devices have available to talk. Simple fact: protocols that scale to many, many devices and need to move lots of data to / from many devices, often use datagram based, connection-less communications. Think about BitTorrent, RTSP, VPNs, and the most modern version of HTTP (HTTP/3 - QUIC).
• Network nimble: LwM2m over CoAP / UDP (or CoAP on TCP) can easily traverse firewalls and NAT. Devices do not need to reference their own public IP in the protocol nor be NAT aware. The same can be said of the HTTP variation of the protocol.
• Data Consumption: Last, but certainly not least from a budget standpoint. If you are building a product that will have a large footprint, on carrier networks around the world, decreasing bandwidth usage will directly or at least indirectly decrease your cost. LwM2M is very bandwidth efficient, and devices don’t by default consume gobs of data when just idly sitting on the network (in contrast to some protocols).

Standardization and Interoperability with LwM2M

Since 2018, OMASpecWorks has defined 3 major versions of LwM2M. The standards are additive, meaning they do not significantly supplant the previous one, and if implemented well vendor LwM2M stacks should be backward compatible. The three are:

LwM2M 1.0   Published in February 2017.

Core features:

• Smart object resource model
• Set / get / delete. From an actual protocol, these look like POST and DELETE commands to a specific REST path in CoAP.
• Discovery and bootstrap capabilities
• DTLS encryption
• UDP (CoAP) and SMS transports for LwM2M
• Queue Mode for offline clients.
• Core objects in what is now the LwM2M Registry

LwM2M 1.1   Published in June 2018.

Introduced these new features:

• Enhancements to LwM2M bootstrapping which allow incremental updates
• Better PKI features
• Support for CoAP on TCP
• LwM2M support on LTE-M, NB-IoT and LoRaWAN
• New data types including Sensor Measurement Lists (SenML - RFC 8428) with a CBOR encoding

LwM2M 1.2   Published in November 2020.

Introduced these new features:

• New client to server transports for LwM2M: MQTT and HTTP support
• Support for TLS / DTLS 1.3
• LwM2M gateway device support. This means non LwM2M devices can be published to the LwM2M server through a gateway.
• LwM2M CBOR encoding
• Enhanced “Observe” capability for watching specific LwM2M resources
• New notification attributes such as “edge” notifications and features assiting with historical data
• General optimizations around performance in bootstrapping and registration

Silicon Independence

A variety of implementations of LwM2M are specific to certain silicon vendors. These are generally stacks available from specific silicon vendors.

While these stacks may be tempting and will be well marketed, bear in mind that using a silicon-independent stack allows multiple generations of product you design to use the same software stack, without dedicating yourself to a silicon vendor for multiple generations of hardware. With the recent advances in AI-capable microcontroller hardware, with some vendors making big leaps before others, and the significant churn and consolidation in the silicon industry we think this advice remains more true than ever.

Gateways and LwM2M

As discussed in the 1.2 specifications, as of 2020, LwM2M now officially supports gateway devices and non-LwM2M (non-native) devices being published to the LwM2M server via a gateway proxy.

Izuma Networks Cloud has in fact had support for gateway devices for quite some time now, and long before the official standard. Izuma Connect and Izuma both incorporate our open-source Apache 2.0 LwM2M client. Izuma Edge is our gateway class software, and it makes publishing data to LwM2M from a non-LwM2M device incredibly easy. Code running on the gateway merely has to locally (process to process) send JSON-RPC requests to Izuma Edge about about the connected device. In doing so the client will update the server, as well as associate the new device as an attached device to the gateway in your LwM2M Device Directory.

This means that LwM2M can support many additional devices very easily, such as: Bluetooth sensors and presence tags, 802.15.4 devices, LorA devices, and even older wire protocols such Modbus and BACnet. Our team has significant experience with many of these protocols and can help get you up and running quickly to support them.

For more advanced needs, especially as gateways become more powerful and applications more sophisticated, Izuma Edge includes an application orchestration engine, powered by Kubernetes. Using Izuma Edge and Izuma Cloud you can deploy AI and other workloads at the edge to directly interact with your LwM2M devices.

About Izuma Networks and OMA LwM2M

Izuma Networks has a rich history in LwM2M and CoAP.

Izuma Networks was formed in 2022, when Softbank decided to spin off Arm’s IoT software business as Pelion. Izuma Networks was formed by previous Arm employees, who saw the need to further develop the IoT software business. Arm’s (and consequently Pelion’s) IoT software business was immediately acquired by Izuma Networks under a mutual agreement. We are happy to support both existing customers of Arm and Pelion, as well as our new customers at Izuma Networks.

You will find Arm has had a rich history in the development of many of the underlying technologies in LwM2M, including CoAP, Smart Objects, and many core features in the most modern versions of LwM2M, including as authors of various RFCs.