New episode of my LPWAn post series, this time, about the network architecture and the role of the network kernel.

The network architecture is different than a classical IP communication from client to server: the LPWAn architecture is based on a kernel network allowing the protocol transformation from the Sigfox / LoRaWan world to the IP-Internet world.

In the LPWAn protocol the addressing is limited to one device address only to reduce the frame size and as a consequence all the frame have to be captured by a central system: the network kernel. It will route the message correctly to the end user application based on device association made on registration.

This post is related to a french video (as usual) and detailed in the following part of this post.

Basically the following diagram is representing the usual architecture of the LPWAn with a device on the left side communicating to a network (Sigfox or LoRaWan) in the center, this one pushing back an enriched message to a platform where the information is decoded and presented to the end-user.

SigFox / LoRaWan standard architecture

When communicating a device is emitting over the air its message. This one is captured by one or many antenna, named Gateway in LoRaWan and BaseStation in Sigfox. These antennas are capturing any message with the right protocol. In LoRaWan it means the gateway is receiving and processing all the LoRaWan message of any operator.

The message is then transmitted by the gateway / basestation to the network kernel. The communication uses standard telecom way usually based on IP, sometime 4G, sometime cabled Internet connection.

Once received on the network kernel, the message is associated to an existing user or rejected. The role of the network kernel is also to manage the devices and the associated billing. Once a user is identified it is possible to associate the message to an application. The device manager is associating each of the device they own to a device type (sigfox) or an application (lorawan). This association allows two things:

• Decode and validate the received data
• Route the data to the right end-user backend.

The message decoding can be made different ways, Sigfox has really limited capabilities and the backend mainly push the raw data to the end-user backend. It means you are in charge of validating the data and decode the data. You have some custom fields allowing to create a json structure from a given data but it is not easy to use, hard to maintain dans you can’t do any computation so you will have at end to proceed your data on end-user backend.

The things networks offer a really good way to manage the data decoding with the capability to implement  3 level of Javascript function to proceed the received data and generate a business oriented message out of the network kernel.

By-the-way, the main function network kernel are offering is to reroute the message to the end-user backend. Multiple options are possible, the information can be pushed or pulled. You can pull the information by requesting the API offered by the network kernel but regarding the low frequency communication, until you have a lots of device you may do a lot of negative pull. For this reason I usually prefer the push method : on reception of a message the network kernel create a GET or POST request to a given URL. With Sigfox you can batch this request every second in case of messages, in this situation the request will contain all the messages received in this second. This will avoid to overload your application server.

The limit of the Push method is the risk of missing some communication when you update your server or when having a serveur crash. Three mechanisms (at least) can be use:

• The first one is to develop a API fallback solution to request the missing message (not easy to develop)
• The second one is to have a backup callback server where you store the message in raw (no decoding) in parallel of your primary server. You will be later able to re-execute the missing callback from this raw data history. This is more easy to manage because the input interface is exactly the same as the normal way.
• The third solution is to add a queue between network kernel and backend to store the message during the end user backend stop. This will work if all the integration layer including queue manager are redundant dans fault tolerant.

The network kernel also propose other solution like storing the data into a database, this is usually based on a DBaaS solution proposed by a PaaS provider. Sigfox is working with Azure for this. TheThingsNetwork have a such capability but I did not test it yet. Basically this solution is subject to extra payment but solves the question of the dataloss. By-the-way you still have to manage reception trigger.

In the video you will find demo of the two network kernel backend Sigfox and TheThingsNetwork.