So, I finished developing a w3bstream applet for our startup’s smart meters and then was waiting around for the opening of w3bstrream devnet. During this time, as you might imagine **I became very bored. I used the time to revisit a thought about building an LoRaWAN network infrastructure for IoTeX ecosystem devices and developers.
To explain my ideas for said network, I would like to use the helium network as an analogy
Simplified view of the Helium network architecture
┌─────────────┐
│ │
├┬───────┐ │
┌┐ ┌┐ ││ │ │
││ ││ ┌───►├│ │ │
││ ││ │ ││ │ │
│ ┌─┼┼─┼┼─┐ │ ├┴─────l─┘ │
┌┴─┐ LoRa │ ├───┤ │ UDP │/IP │console │
│ │ ─────► │ │ │ ├─────┘ │ instance │
└──┘ │ ├───┤ │ │ │ ┌───────┐
└─┴───┴─┘ │ │ │┼─────┼│
iot device │ ├─────►├│ ││
hotspot │ AWS │ ││ ││ mobile
│ │ ││ ││ apps
│ │ ││ ││
│ │ │┼─────┼│
└─────────────┘ └───────┘
The way helium network is setup requires two categorises of physical infrastructure
- Helium hotspots (aka miners)
- Helium console/routers
To send data packets across the Helium network, your device must first be registered with an instance of helium-console running on a cloud server. Then it can publish its data packets to hotspots using its registered credentials. Hotspots collect data packets from the IoT devices (LoRaWAN) and sell them to the console instances where the device was registered (UDP/IP), hence completing its journey from device to database.
Enter w3bstream 
W3bstream could play a role similar to that of helium’s consoles, while still offering endpoint decentralization and a WASM virtual machine for dapp logic. IoT devices being developed on the IoTeX ecosystem would benefit from having a LoRaWAN coverage that transmits their data packets to W3bstream.
My team and I have been experimenting with using LoRaWAN devices, and we might have devised an architecture analogous to the Helium network and a protocol to incentivise community driven coverage. By connecting a LoRaWAN module to your computer via USB, and running the appropriate program (currently a Python script), individuals can begin providing IoT devices with a gateway service to w3bstream.
┌┐
││ ┌───────────┐
││ │ │
││ │ │
││ ┌──────┼───┐ ┌───┼─────┐
│ ││ ┌┐ │ │ │ │ │ │
┌┴─┐ LoRa ││ ┌──┬───┐ ││ ┌─┼──────┼─┐ │ │ ┌─┼─────┼───┐
│ │ ───────► ││ ┌───────┐ USB └┼┼│ │ ┌─────┐ ││ HTTPS │ │ └─┼─┼───┼─┼─┘ │ │
└──┘ │┼──┼┼┼┼┼┼┼┼┼───┐ ────────► │┼┼───┼───┼┼┼┼┼┼┼─┼│ ───────► │ │ │ │ │ │ │ │
└───────────────┘ └──────────────────┘ │ │ │ │ │ │ │ │
iot device │ └────────┼─┘ └─┼───────┘ │
LoRaWAN module computer │ │ │ │
(eg raspberry pi) │ │ │ │
└──────────┘ └───────────┘
w3bstream network
The Protocol
-
setup a staking contract where gateway providers and network users skate assets to participate in the protocol. Assets could be IOTX of an XRC20 token designed for the protocol, think w3bstream gateway tokens ($WGT). Staked assets would protect the network from spammers and attackers as well as ensuring that participants act in the best interest of the network or would be slashed.
-
setup a registry contract that binds device identities to accounts with assets at stake.
-
devices publish their payload capsuled with payload single use number and device identifier which is then signed and published with signature.
-
Gateway receives data packets and encapsulates it with it’s own identifier, signed after which it can be and published with signature as a w3bstream event.
-
a applet deployed on w3bstream is then able to identify participants in the transmission by correctly unpacking the encapsulated payload. Assets from the staking pool is then awarded to the gateway provider and subtracted from the network users.
-
each participant is able to make a claim to the staking contract whenever they intend to exit the protocol.
- On claiming, participants would receive
assets staked-assets spent+assets earned-assets slashed
- On claiming, participants would receive
BULIDing The Protocol and Sources
Ideally
The ideal scenario would be for the iotex team to develop the gateway specification, prototypes and the network protocol contracts much like they have done with ucam & Pebble, This is ideal, because the IoTeX team would have access to more resources and developers than any one else could muster.
Alternatively
The second best scenario would be to have a consortium of ecosytem developers work together on the specification financed by the Halo grant program. This is what we are currently pushing for, but it is not ideal because it will take longer to get things done.
Call to action
I invite everyone to discuss whether this is a project worth pursuing, and if so what scenario should be used to bring it to life.
→ [
If you are interested in DePIN you can learn more about the latest developments in the sector and compare projects by visiting DePINscan. DePINscan powered by W3bstream and IoTeX is designed to empower intelligent investors in the DePIN sector.