Embedded Processing or Host Architectures for Cellular IoT Devices

Estimated reading time: 9 minutes

Rising memory costs and limited memory availability are shaping cellular IoT device architecture choices as manufacturers account for higher component prices. Increased expenses are only part of the issue. When a part becomes difficult to source, an engineering team must qualify a replacement and redesign the device around it. 

Which company carries that work depends on the architecture. In a hosted design, the manufacturer integrates a host processor with the cellular module and qualifies the memory that processor uses. When either component changes, the manufacturer is responsible for modifying the hardware or software. 

Embedded processing shifts more of that responsibility to the module supplier. When a cellular module has sufficient processing capacity and memory, it can run part or all of the device software. The manufacturer then has fewer external components to source and maintain. 

By transferring responsibility for a critical component such as memory to the module supplier, device manufacturers can reduce sourcing and lifecycle-management complexity. They benefit from the module supplier’s greater purchasing scale, built by aggregating demand across multiple customers and vertical markets using the same memory technology. 

Choosing between a separate host processor and embedded processing determines not only the initial bill of materials, but also which company carries the engineering work when components become unavailable or if the product moves to another cellular generation. 

How a Hosted Architecture Affects Cellular IoT Design

Many cellular IoT devices follow a similar pattern. A host processor runs the application software, while a separate module provides connectivity. External memory and power management circuitry support the processor. 

This architecture gives the manufacturer direct control over the application software. Keeping that software on the host can simplify switching suppliers by reducing the amount of software that depends on a particular cellular module. 

The manufacturer pays for that supplier flexibility with additional integration and maintenance work. Its engineers must manage communication between the host processor and cellular module, then qualify the external memory used in the host design. 

If the selected memory becomes unavailable, the engineering team must qualify a replacement and verify its compatibility with the host processor. If the replacement is not fully compatible, engineers may need to adapt the software that communicates with the memory and revalidate the design. 

Maintaining this architecture requires enough engineering capacity to evaluate and integrate replacement components. Applications that require substantial memory or processing capacity may justify that investment. For an application with modest requirements, a separate host may add more cost and engineering work than the design needs. 

Embedded Processing Reduces External Components 

Every cellular module contains a processor and memory to run its firmware and connectivity functions. In some modules, the processor has enough available capacity to run the device software as well. This is embedded processing. 

A module with greater processing capacity may cost more than one designed primarily for connectivity, and its memory faces the same cost and availability concerns. Running the application software on the module, however, may eliminate the host microcontroller and its external memory, reducing component costs and board space. With fewer external components, the manufacturer has less hardware to qualify and support throughout the product’s lifecycle.  

Changes in module price or availability may still reach the customer. However, consolidating components within the module transfers greater responsibility to the supplier. If the selected memory becomes unavailable, the supplier must qualify and validate a replacement, not the customer’s engineering team. Manufacturers should therefore determine the supplier’s plan for long-term product support and migration if the original module or any internal component becomes unavailable. 

Placing application logic inside the cellular platform brings the module supplier deeper into the product architecture. The supplier provides the development environment and helps determine whether the module has enough resources to run the application software. 

Customers need a clear account of how the application can move across supported products and where a future migration will require adaptation. A credible supplier should identify which software can carry forward and describe the engineering work that remains when the platform changes. 

Evaluate Application Requirements Before Selecting a Cellular Module 

Cellular module selection often begins with the radio technology. Engineers identify the required cellular standard, then compare the products that support it. That sequence can overlook whether the module’s processor and memory could also run the device software. 

The architecture review should consider flash and RAM consumption alongside radio technology. Those requirements help determine whether the module can run the device software. Interface requirements narrow the choices further. A simple sensor or actuator may require little processing capacity, while other applications may exceed the memory or processing resources available within the appropriate module. 

Customers beginning this evaluation should document: 

• Current flash and RAM consumption
• The application’s software footprint
• Required hardware interfaces and module features 

The architecture review should also account for evolving application requirements during the product’s lifecycle. If those requirements change, engineers may need to reevaluate whether the module still provides sufficient resources or whether the application needs a different architecture. 

Some manufacturers keep a hosted architecture to maintain direct control over the application environment. Others require processing capacity or interfaces unavailable on the appropriate cellular module. Technical requirements and the engineering work the manufacturer is prepared to support should determine the architecture. 

That decision also affects future migration. Software developed for a supported embedded system may carry forward to another module or cellular generation, although platform differences may still require adaptation. 

Ready to evaluate your IoT device? Get a Telit Cinterion Dev or EVK Kit

Plan Application Software Migration Across Module Generations 

IoT products often remain in service through component changes and network transitions. Memory may reach end of life during that period, while a network transition may require the manufacturer to adopt another module family. 

A common software environment can allow portions of the application code to carry forward when the module changes. Application engineers then address hardware or software differences that the common architecture cannot abstract across the two platforms. 

The available migration path depends on the module portfolio and the application’s requirements. A replacement module must support the device’s connectivity needs and provide the right execution environment for its software. This work extends the supplier’s role across product generations.  

Component volatility increases the value of precise migration guidance. Manufacturers need viable alternatives and a clear account of the engineering work each one requires. Selecting compatible hardware resolves only part of the transition. Engineers must also evaluate the application against the new platform’s interfaces and available resources. 

IoT AppZone Supports Embedded System Portability 

Hardware consolidation delivers greater long-term value when engineers can migrate application code without rebuilding it for each module platform. 

Telit Cinterion developed IoT AppZone for customer applications that run on compatible cellular modules. The platform provides a common software environment across major LTE-M, LTE Cat 1, LTE Cat 4, and 5G RedCap products. Customers write their applications in C and use common APIs across supported modules, reducing the amount of product-specific code they must rebuild when moving the application to another module.  

AppZone provides an abstraction layer over the underlying chipset environment. This layer gives developers a consistent software architecture across supported modules while shielding them from chipset-specific interfaces. 

Hardware and platform differences may still require technical evaluation and software adaptation, but the common software environment reduces the platform-specific work left to the customer’s engineering team. The same architecture can support manufacturers that use different compatible Telit Cinterion modules across multiple product lines. Once developers create an application for one supported product, they can reuse portions of that work instead of rebuilding the application logic for every compatible module. 

Telit Cinterion also provides embedded application environments for products that run real-time operating systems, like ThreadX and FreeRTOS™, as well as Linux. Apps on Linux support applications that require user-space access, while Open Linux provides kernel-level access for more sophisticated requirements. Supported RedCap and 5G products use OpenWRT. The appropriate environment depends on the application’s technical requirements and the resources available on the module. 

See our IoT AppZone Developer Resources 

Choose Where Cellular IoT Integration Responsibility Belongs 

A hosted architecture gives the manufacturer direct control over the application environment. It also leaves the manufacturer’s engineering team responsible for qualifying external components and managing the interface between the host processor and cellular module. 

Embedded processing transfers more of that work to the module supplier. The supplier manages component qualification within the module and supports the software environment used by the customer’s application. 

Manufacturers should decide who will carry these responsibilities before finalizing the device architecture. The application’s technical requirements establish what the design needs. The manufacturer must then determine whether its engineering team can support the external components and host-to-module integration throughout the product’s lifecycle. 

In some cases, cost or resource requirements may lead a manufacturer toward a separate host and a simpler connectivity module. Telit Cinterion application engineers can review the proposed architecture, assist with software integration, and identify feature gaps that require additional work when an application moves between products. The team provides similar support when embedded processing is the better fit. 

Current memory price and availability pressures increase the burden on manufacturers that must qualify and integrate replacement memory themselves. Consolidating the application within the module can reduce that exposure when the module provides sufficient resources. Manufacturers evaluating a module supplier should also consider whether that supplier can support the application through later module and network transitions. 

Telit Cinterion has supported embedded customer applications across multiple cellular generations, beginning with 2G and 3G products and continuing through our current 4G and 5G IoT modules portfolio. That experience informs our support for application migration as networks and module platforms evolve. 

Speak with a Telit Cinterion module expert about your application and device architecture.