The internet of things- a story from the frontier
The full article was originally published by Andreas Baumgartner on Medium. Read the full Article here.
Hello!! and sorry, guys. really long text for a simple-looking PoC following the same path then Harm van den Brink with his iota & lorawan proposal and i have to write some text to explain why such a thing for some (nerdy) people — in fact — is really shiny!
Long story in short: In Harm’s approach, sensor data, transmitted over a LoRaWAN protocol based sensor network are taken from a backend lorawan application server, put into a iota tx object and attached to the tangle. That is cool, but this is just the internet … not the internet of things.
…If our beloved iota protocol could instead go somehow right over the air (i.e. within the LoRaWAN network) — a step further to what harm suggests at the end of his blogpost — we can enjoy all nice benefits of iota regarding data security (over the air) as well as distributed ledgers benefits regarding data integrity…and we can build bullet-proof machine networks working in unlicensed frequency spectrum. If a sensor can create and sign an MAM message which forbits changes to the message at the network-side (e.g. due to corrupt LoRaWAN network) this would be something really valuable. long story in short: it works of course, hurray!! the video shows a MAM tx from a raspberry pi with a lorawan shield to a LoRaWAN-in-a-Box system (all network elements of a lorawan network + a homegrown backend for iota/mam implemented on a pi, basically using LoRaWAN SF 7, CR 4/5, 125kHz channel, packet size 255 Bytes)) in our lab at the tu in chemnitz.
We had a iota over lorawan implementation ready some months ago, but our paper (IEEE) got rejected, DL engineers and communication network engineers are different worlds still. as mam is an essential part in the full communication network engineering picture, we didn’t resubmit.
Proof of Concept: MAM over IOTA over LoRaWAN
As an iota packet is way bigger then the max packet size of LoRaWAN (and unfortunatly of all protocols from the LPWAN family), we need to have a fragmentation of the iota packet into several lorawan packets to make it fit. In the video, the pause between transmission is due to the duty cycle regulations in the unlicensed EU868 MHz frequency band, but please check semtech’s already available SX1281 making LoRa available in the same 2.4 GHz spectrum wifi(802.11) is working in…no duty cycles there. (also no WAN extension to LoRa, but wait. it will come soon:) we’re just a little early as always, IOTA people know the story;) We used the js libraries from you guys, in combination with other languages…this is one of the reasons we needed to press enter on the receiving side 3 times…however 😐
… packet segmentation issues 🙂
The other reason is, because we extended lorawan with scheduling-enhanced transmission channels (working in the ISM subbands) and spreading factors to get rid of the to-be-expected packet-collisions on air due to the ALOHA-protocol-like channel access mechanism in lorawan and the necessity to send a sequence of lorawan packets for an iota/mam/something over it tx object, not only a single packet with some sensor values. these types of communication networks need to scale largely. the different protocol parts need to be triggered by hand still….homegrown stuff has the best taste:) in the video, the sensor is sending initial uplink data to ask for frequency = ISM sub-channel /airtime/Spreading Factor/Coding Rate/TX power (…), triggers an downlink message with the respective settings from a centrialized “airtime scheduler” in the lorawan network …then uses these settings to parse a sequence of lorawan packets for the mam message. This is all just a rough first version, sorry.
To sum it up: Iota is not only a distributed ledger for the internet like all the others, but really meant to be for the internet of things. Even where no cable-connections, WIFI/broadband or mobile network operators are available or affordable or would be too indiscreet to use, it works. now why this is a little shiny: LoRaWAN was meant to transmit boring stuff: Simply transmit plain sensor data (e.g. like temperature data values in harm’s example or something) but never a full grown protocol on top of it, especially no DL based protocol plus extensions. Both worlds meet here