The proposed API’s for enablement of matter / IoT applications on prplOS

Due to the tight coupling of embedded solution packages on CPEs (customer premises equipment) products that exist today in the consumer market, like home gateways and home routers, where the product stays with the same code base for many years and apply some security patches and software upgrades as and when required. As a result, the embedded architecture reaches a dead-end stage, where it cannot grow, evolve, or be optimized, and does not even follow the regular CD/CI process. This method also creates another drawback: it does NOT address all the vulnerabilities and security issues, that need to be handled at the platform level (with the upgrade of certain encryption algorithms). This means the CPEs can be easily cracked by hackers. Increasing the cost of support, maintenance cost and bug fixing impacts the quality of the software deliverables and slows down the pace of updates covering the BSP/firmware provided by the SoC vendor. This has a negative impact on all home gateway / home router development projects, which leads to longer time-to-market, huge testing costs, and infrequent OTA (over-the-air) software upgrades. Today, the firmware/BSP provided by various SoC vendors limits the diversity of software platforms; it lacks enhanced architecture and feature support and is unable to implement new software components and feature advancements.

To address this major challenge, a key element is to have a common middleware framework with well-defined API’s/customization based on configuration, plug-ins, and to develop new applications/smart services quickly. The common middleware framework makes any upstream contributions easier and in turn, decrease the fragmentation. It allows ISPs to transition to an evolving hardware platform and kernel development and assures the use of the latest software architecture along with the best security practices. It further allows for rapid innovations with a wider range of features that can be supported for any chipsets expected to be launched in the future. From the home router/home gateway architecture perspective, converging to common middleware with the APIs exposed both at a low level and at a high level proposed by prplOS makes software deployment easier on a variety of chipsets and satisfies a diversity of features and solutions.

The method proposed by prpl is to separate the middleware framework interface – the software – from :

• BSP/firmware – the device drivers that are integrated tightly in the build system must be separated with a hybrid model by overlaying prplOS LLAPIs from the SDK provided by SoC vendors to make it compliant with a single Linux kernel version
• Application/Service layer supporting an ecosystem of different home applications, such as IoT/Matter, security, device management, home automation, and home surveillance.

With reference to figure 1, there are four broader elements required to be considered for building the home gateway/router solution based on prpl.

1. Hardware layer (Low Level APIs)

Low Level APIs are the recommended APIs expected to be supported by BSPs provided by SoC vendors. These APIs will be used by the middleware framework on the CPE device as part of the prpl package and ISPs’ custom middleware components as a value add to ensure core differentiation to other gateway products from respective competitors.

Some of the Low-Level APIs that can be expected are listed below:

1. APIs for integrating with different flavours of SoCs, thereby reducing larger integration/testing efforts which enables integration with multi-SoC in a shorter timeframe, making it fully compliant with the standard Linux kernel
2. APIs for interfacing with different sub-elements of hardware covering wireless (Wi-Fi 6E/7, 5G, 4G, Thread, Zigbee, Bluetooth) and wired (DSL, Fiber, DOCSIS) technologies
3. APIs for management and monitoring of network services/clients, such as firewall, DNS, QoS, connected hosts and user access.
4. APIs for interfacing with various peripherals such as GPIO, Button, PWM, LED, I2C, SDIO, MDIO (Management Data Input/Output), UART, MII (media-independent interface)
5. APIs for interfacing with various device driver(s)
6. APIs to upgrade the latest security patches on a periodic basis
7. APIs for interfacing with TPM (trusted platform module) / TEE hardware to create a secured data storage/data transmission and reception
8. APIs for easier interfacing with middleware and applications that sit on top of SoC-provided firmware/OS – This approach allows middleware stacks on the gateway to rely on a single set of APIs regardless of the chipset model and manufacturer
9. APIs to manage various system hardware resources with a common code base to ensure the entire gateway operates efficiently and reliably
10. APIs to reduce the complexity of integration at the kernel space.
11. APIs to allow any silicon vendor to deliver the driver code by having a seamless interface with the protocol stack/middleware framework(s).
12. APIs to flash fully customizable, static firmware on the fly to reduce the time to deliver features to subscribers.

2. Middleware Framework – Software Components

The goal is to have the common middleware framework for a home gateway available for a wide variety of target platforms that can be used by applications via High Level APIs, and by the hardware platform via Low Level APIs. Below are some of the software components/protocols expected to be part of the middleware framework from prpl OS:

• DHCP (Dynamic Host Configuration Protocol), DNS (Domain Name System), DPI (Deep Packet Inspection), VPN (Virtual private network), RIP (Routing Information Protocol), IGMP (Internet Group Management Protocol), ICMP (Internet Control Message Protocol), ARP (Address Resolution Protocol), HTTPS, IMAP (Internet Message Access Protocol), Telnet, FTP (File Transfer Protocol), WebSocket, NTP (Network Time Protocol), u-bus, d-bus, z-bus, QoS, Wi-Fi Easy mesh, Database, Net Filter, Database, TR-069 (Device Management)/TR-181 (Data Model), TR-232 (bulk data collection), TR-369 (User Service Platform)
• SIP/IMS, MQTT, CoAP, LWM2M (Light weight M2M), Border Router for thread enablement and other critical protocols from SoC vendors, which have fewer dependencies
• Certain optimized routing algorithms/components for performance improvements already carried out on the gateway during system/field testing.

3. Application / Service Layer – (High Level APIs)

The High-Level APIs are the recommended API’s for creating new applications for different flavors of CPE. Some of the High-Level APIs that can be expected from prpl are listed below: –

1. APIs for logging, debugging, data collection & analytics that provide deep insights into subscriber traffic, and help isolate issues and reduce support costs in the long run
2. APIs to facilitate performance measurement and diagnostics, including network mapping and testing via ping, packet capture, and more
3. APIs with automation in an organized workflow using a rule-based control system to meet the end user’s objectives and to meet business requirements in a most cost-effective manner
4. APIs to personalize a service for every subscriber (home user) according to their needs like device selection, and add-ons, as well as service subscriptions
5. APIsfor interfacing with IoT/Matter devices, mobile, and cloud platforms that lower the cost of integration and take control of the consumer touchpoint
6. APIs to take care of intra-device and inter-process communication to reduce the number of software builds needed to improve the efficiency of the overall gateway system
7. APIs to have a more standardized way of handling interoperability with technologies like Wi-Fi, Thread, and Zigbee, using an interface with the Matter framework as shown in figure 2.
8. APIs to take care of configuration management that cover:
   • Control, state, diagnostics
   • Configuration of device management framework (TR-069)
   • IEEE1905.1 – network convergence
   • Network topology and easy mesh configuration
   • Data model
   • OpenSync
   • Event logging
   • Network topology view, flow optimizer, policy enforcement, network automation, network bandwidth, load balancer
9. APIs for managing and monitoring the VVoIP and other critical safety applications like surveillance (ex: eldercare)
10. APIs to interface with User Services Platform (TR-369) – a system of controllers and agents that enables remote manipulation of software and hardware capabilities
11. APIs to enable IoT protocols (MQTT, CoAP, LWM2M) and monitoring these interfaces.
12. APIs to have access from a cloud network via a gateway for monitoring and controlling end devices
13. APIs to have greater flexibility in enabling various third-party home consumer products (e.g. – Wi-Fi devices such as door locks and power outlets)
14. APIs to facilitate interaction with home users with a ‘simple, intuitive and consistent’ manner for control of different smart home appliances
15. APIs to interface with the third-party app server installed on the cloud
16. APIs to build a WebGUI framework
17. APIs to develop new applications by the app developer, with the potential to add to customers’ monthly subscriptions based on their interests: for example, home automation, home security, parental controls, improved detection of cyber threats, augmented reality, game servers, IoT based on Matter standard, and a host of new features/functionalities that can be added into the gateway to support new applications.
    • Container-based applications deployment makes it much easier to achieve this, where the gateway application is decoupled from the gateway device firmware and can be easily moved from one computing environment to another. As a result, the container-based services need not rely on the hardware manufacturers (OEM) update cycle.

4. Validation, Testing & Performance Benchmark

The middleware framework from prpl OS along with High-and Low-Level APIs must be tested to check the performance and stability of the integrated solution on specific hardware platforms. The system testing is more about benchmarking the performance of prplOS on specific target/embedded platforms as shown in figure 2 by interfacing with variety of applications such as web browsing, streaming videos on Smart TVs/Laptops, monitoring surveillance (in elderly care, for example) on tablets, live video broadcasting on Smart TVs, Skype calls on smartphone, Teams meeting calls, and many more. The open-source code available in https://gitlab.com/prpl-foundation/prplos/prplos can be used to build prplOS (based on OpenWrt) for specific hardware platforms.

The prpl Foundation supports around many SoCs, including players such as Atheros, Broadcom, Freescale, Marvell, Nvidia, Qualcomm, Samsung, Synopsys, and TI., The Raspberry Pi (RPi) can also be chosen as one of the target platform, where Broadcom and prpl have enabled the support for the chipset series brcm27xx that covers RPi series 3B+. Our next version of blog shall contain details on validation of prplOS on RaspberryPi and the details on the performance benchmarking.

Conclusion

Fragmentation in the low-level software layer (firmware/BSP) requires ISPs to work with certain third-party system integrators. This eventually increases the costs of overall product development of home gateways, including integration and system/field testing on different SoC/hardware platforms. The non-standardization that exists today means every software vendor puts more effort in to developing the code without adding much value in the process, reinventing the wheel every time, where it affects time-to-market. In a nutshell, the problem statement is very clear – the CPE hardware, firmware, middleware is fragmented.  There is no portability between CPEs, due to which the cost of integration is very high, and many business cases have become impossible.

To address all these challenges, the prpl Foundation has defined a framework with new standard APIs and services to harmonize the way applications can integrate across various CPE devices. The group has released a platform-independent software stack called prplOS as reflected in figure 3, that standardizes software deployments across different flavors of CPE product variants. PrplOS will enable software vendors to build new services that will work on every manufacturer’s CPE device by minimizing platform integration efforts. As a result, ISPs will be able to deploy new/smart services easily, quickly, and more efficiently for their subscribers/customers.

With the launch of the prpl Foundation, app development usingHigh Level APIs enabled in the prplOS stack simplifies the addition of smart services/co-services in home gateway/home router product variants. With the High-Level APIs’ support, the industry is set to create new applications in the smart home ecosystem. The Low-Level APIs defined by the prpl Foundation, working with various SoC vendors, help to realize the benefits of making a dramatic change. They strive to integrate the APIs in the firmware/BSP provided by SoC vendors for seamless integration on different hardware platforms. Instead of every software integrator integrating every driver and feature, SoC vendors are being asked to consolidate their APIs and offer all core features through open, publicly available named APIs, such as the Low-Level API.

The High- and Low-Level API-based approach with the common middleware from the prpl foundation will be able to deliver high levels of stability, reliability, and scalability, making it suitable for gateway/router deployments. It is hoped that the prplOS will create significantly greater value for the “co-creation of new business opportunities” by ISPs to build the smart society of the future.

References:

1. Prpl foundation    – https://prplfoundation.org/documents/
2. Gitlab                  – https://gitlab.com/prpl-foundation/prplos/prplos