Architecture

Overview

Streambed is a toolkit used to develop event-first microservices that can run on xDP. This document uses xDP to frame how Streambed components relate to each other, using agriculture as an example.

The following sections describe each major area:

• Cisco Kinetic cloud
• xDP farm
• Third party cloud

Cisco Kinetic cloud

Kinetic allows farm-based sensor and application data to be pushed to the Cisco Kinetic cloud via its Data Control Module (DCM). Once in DCM, sensor and application data can be further processed and routed to third party clouds. The reverse is also possible i.e. third party clouds are able to securely route data to sensors and applications hosted on the farm.

Kinetic also enables farm-based service routers to be commissioned and managed remotely via its Gateway Management Module.

“Third party app server” is as an example of how a third party cloud such as Google’s BigQuery can have an application stream-out authorized data. Data can also be consumed from external sources, enrich existing sensor data and then be republished.

xDP Farm

Sensors typically communicate with one or more gateways on the farm via a LoRaWAN network, noting that other types of network can also be used. Each gateway forwards sensor data to a service router which then forwards this data to the Cisco Kinetic cloud when connected to the internet. While internet connectivity is not a requirement for a large degree of farm-based functionality, to leverage Kinetic and upstream third party clouds then there must be an occasional connection.

A service router delivers sensor data to the third party applications that are running on the service gateway. Third party applications only receive the data that they are authorized to receive. In addition, third party applications may instruct actuators to perform functions e.g. activate a water pump, activate a grain silo’s cooling system etc.

Third party applications are available to a user by running natively on iOS, Android and/or a web browser. These applications are able to connect to a service router via WiFi. User authentication and authorization is employed at this level e.g. a farm user may be able to see all sensor data, while a supplier of irrigation pivots may only see the sensors and actuators in relation to their machines.

The following diagram elaborates further on the components of the xDP Farm:

Jsaas is a service that runs JavaScript programs. It is used by the Control Center to execute user-supplied programs such as those that transform LoRaWAN data into some normalized form. Sophisticated transformations can be expressed using JavaScript, but if more complexity is required then third party applications can be written.

Flatmate provides a container environment for applications that run on the Java Virtual Machine (JVM). Flatmate fulfills some of OSGi’s original goals by hosting multiple JVM applications within the one process to significantly reduce memory requirements, particularly on low powered devices. Flatmate avoids placing a burden on the developer in that there is little difference between running a JVM application with or without it.

Example applications are shown hosted by Flatmate:

• LoRaWAN NS/JS - a LoRaWAN Network Server responsible for decoding data into a form that applications can readily consume
• MQTT Gateway - an MQTT client that can be used for communicating with Streambed applications
• iox-sss-stub-server IOx encrypted secret management
• DQ server - a durable queue shared across applications
• Control Center - a desktop and mobile web application that is used to visualize sensor data, configure custom dashboards and transformers, and on-board and manage LoRaWAN sensors
• Third party app - any other application that can be conceived by being built with Streambed

Each of these services utilizes a durable queue. A durable queue is a commit log where its elements are stored for a period of time. Kafka and Chronicle Queue are good examples of durable queues. Topics address queues and can be both tailed and appended to with data. When a stream tailing service is not running its events are still stored so that when it starts, the service will start reading from the tail and build its state accordingly. Therefore, services can be started and stopped with no loss of data. This is known as event sourcing and is particularly useful when swapping out an old service with a new one. Most data within xDP on the farm is transferred using a durable queue which also enables highly responsive experiences e.g. when sensor data for a device that has never been seen before is received, an application can notify the user in near-real-time.

The journey of a LoRa Alliance certified sensor event

The journey of a LoRa Alliance certified sensor event is along the lines of the following. A soil moisture/temperature sensor, LoRaWAN Gateway and Service Router, such as the Cisco IR829, are used for illustration.

1. The LoRaWAN Gateway publishes encrypted LoRaWAN data packets having received a soil moisture/temperature reading (A). The encrypted data is published over UDP to a LoRaWAN network/join server (NS/JS).
2. The LoRaWAN NS/JS queries the IOx Secure Storage Service (SSS) to map the identity of the sensor with a network session key (NwkSKey). If there is no key known then the sensor data is dropped i.e. active sensors must be known to SSS. If there is a key then it is used to verify the integrity of the LoRaWAN message, again dropping the data at this point if the message is invalid.
3. “End Device metadata” is then read for a sensor, including a topic to publish data to. In the case of our Soilstate UI, this topic is soilstate-data-up-mac-payload and the payload is published to it (B). Only applications privy to an application session key (AppSKey) for the soilstate-data-up-mac-payload stream will be able to decrypt data from it.
4. The Control Center permits a user-supplied transformer program to be written in JavaScript and submitted to jsaas. The existence of the program causes the Control Center to subscribe to the soilstate-data-up-mac-payload stream and receive its data (C).
5. As data is received, it is decrypted from LoRaWAN, normalized into JSON and then passed to jsaas where the user-supplied transformer program resides (D). The data is then normalized and returned, causing the Control Center to source a key for the application and then publish it as encrypted JSON to a soilstate-data-up-json topic (E).
6. An external user connects to the service gateway via their phone (for example). The request lands at the service router and is then forwarded to the Control Center UI web-based application.
7. An active Control Center UI web-based application receives the user’s request and prompts them to authenticate. The user’s credentials are queried against the secret store and their authorizations are returned.
8. On successfully identifying the user, the Control Center tails the soilstate-data-up-json stream, decrypts and renders the data.

Third party cloud

Third parties are able to connect with the Cisco Kinetic cloud for the purposes of enriching xDP farm-based sensor and application data. It is also possible to extract data e.g. a third party could push data into the Google BigQuery service for data warehouse analytics. Both directions require authorization i.e. a government department may only extract data for their research farms and no other farms.

Third parties are also able to push data back to xDP farm hosted sensors and applications, routing via the Cisco Kinetic cloud.

Security

Security is a key concern of the xDP. The following areas are discussed:

• Containers
• Data encryption
• LoRaWAN
• Secrets
• Service Gateway to Service Router

Containers

All of the xDP’s processes are running within containers; LXC for IOx. As such, these processors are limited in terms of:

• how much system resource they use
• how much, if any, of the file system they are able to read and write from
• how much they are able to inspect the running state of other processes

Flatmate is a JVM container host which is also running within an LXC. Its “processes” are the third party Streambed programs as well as some of its own services. All programs that run within Flatmate are subject to the Java Security Manager. Programs perform their required actions via sourcing and targeting durable queue endpoints presented to them.

Data encryption

Data published to xDP’s durable queues is encrypted. While there are few restrictions in terms of what can be consumed or published to a topic of a durable queue, the consumer or producer must have a secret key in order to decrypt/encrypt it. A 12 bit securely randomized salt is retained with each item of encrypted data. From online, “The primary function of salts is to defend against dictionary attacks or against its hashed equivalent, a pre-computed rainbow table attack”.

LoRaWAN

LoRaWAN has multiple layers of security. Firstly, all messages sent or received are subject to a message integrity check which requires a LoRaWAN network session key in order to verify. The MIC (Message Integrity Code) uses AESCMAC on a message’s payload.

In addition, network server destined data and application server destined data is encrypted using network session and application session keys respectively. Encryption uses AES-128.

Secrets

All data deemed sensitive is held within IOx’s Secure service, including:

• the NS/JS network keys for establishing network session keys
• the identity of each service running within xDP and their associated authorization roles
• the authorization roles within the xDP and their associated secrets

Reactive applications

Applications are the key to the xDP - without them would be akin to comparing Apple iOS or Google Android without the ability to make calls or surf the web. While the xDP includes some stock-standard applications and sensor connectivity (for farm: soil moisture/temperature, water levels, grass photosynthesis and more), it is the third party applications that bring significant value to the xDP.

xDP’s Streambed Applications are distinct in that they are written as Reactive Streams-based programs. Reactive Streams and its trait of backpressure has been selected permits the control of resource consumption throughout. Backpressure is important for governing the exchange of data across the asynchronous boundaries of a system.

The xDP enables third party developers to deploy their applications at the edge e.g. on a farm. All applications are supported with telemetry via custom metrics and events.

It is important that the programming model for third party developers is open regardless of its deployment target. This approach promotes the JVM’s original design goal of write once, run anywhere and helps developers avoid unpopular vendor lock-in.

Reactive systems

Understanding Reactive Systems as described by the Reactive Manifesto helps for a further understanding of the Streambed’s design decisions. Here are some highlights of how the Streambed relates to the manifesto:

• Responsive: Reactive Streams is the foundation on which Streambed applications, both internal and third party ones, are based. When an application is in control of its resource usage there is generally sufficient power to respond to requests.

• Resilient: There are a number of points of resiliency starting with the upfront tolerance of the internet being offline. This is an important point of distinction when compared to other platforms that rely on the internet to function usefully.

• Resilient: When using service routers with no in-built storage, a rugged, encrypted external storage device is used.

• Resilient: When a stream tailing service is not running its events are still stored. When it starts, the service will start reading from the tail and build its state accordingly. Therefore, services can be started and stopped with no loss of data. This is known as event sourcing and is particularly useful when swapping out an old service with a new one.

• Resilient: xDP data is synchronized with the Cisco Kinetic cloud data when the internet is online. Streambed applications can be restarted to recover from where they left off given their use of event sourcing.

• Message-driven: Streambed applications are entirely message-driven and Chronicle Queue is used to provide a commit log store for durable messages. Durable messages can be delivered with an at-least-once guarantee.