# Why MittoNet
MittoNet is different from other IoT protocols in that it is much faster, enables the Edge to take decicions and is of a much simpler design. This section takes a look at the design-choices of MittoNet and why we created this Network protocol.
# Range and application
MittoNet is a Field Area Network. It operates in the sub-GHz range, the speed is 50 Kbps and 100 Kbps on (G)FSK modulation. Therefore the range is a around one kilometer in free-air and can cover a building area, including the basement and surroundings.
# Faster means better battery-life
Faster speed means less air-time and hence less battery-usage for End Devices. Sending 12 bytes containing temperature, humidity and pressure (encrypted) takes just 4,5 milliseconds at 50 Kbps. This means that it can run on coin-cell batteries for 5+ years or even solar-cells! Current Sub-GHz IoT protocols is 50 times slower (~1 Kbps) and hence use 50 times more battery power for transmission.
# Faster means security update
Updating the sensors with a security patch or feature update will typically take 30 seconds for a 50 KB (Kilobytes) firmware update. This is in stark contrast with LoRaWAN where a single update containing 100KB takes almost 6 minutes! (opens new window)
# Faster means more use-cases
Another benefit is that sensors are able to send data 50 times more frequently than other Sub-GHz IoT networks. This enables a host of use-cases like sending data every 30 seconds or sending a image (330KB) every hour!
# Spectrum friendly
Faster speed means less air-time per device which enables more devices can share the spectrum. Spectrum is a scarce resource and the more things that become wireless the more effecient they need to be in order to make room for everyone.
Being spectrum efficient is important in order to support the 1 million devices per Km2 predicted in the future.
To see how MittoNet fares in comparison with other popular IoT connectivity options, we can calculate how many devices that can share a 125KHz wide channel if they send a message (12 bytes) every 15th minute.
How many devices can send a message (10 bytes) bytes every 15th minute?
| Network | time/msg. | EDs/Ch | BW/Ch | ED / 125KHz bandwidth |
|---|---|---|---|---|
| SigFox | 2s/msg * 3msgs | 150 | 100 Hz | 187500 |
| MittoNet | 0.005s | 180000 | 120 KHz | 180000 |
| ETSI-LTN | 0.095s | 38000 | 121 KHz | 38000 |
| LoRa (SF12) | 1s | 900 | 125 KHz | 900 |
Prerequisites:
EDs/Channel == time/msg / 15 min
MittoNet is 50Kbps 1 transmission. Unacknowledged. 28 bytes incl. sync+preamble.
Sigfox: 100bps. Unacknowledged. 3 times 2sec transmission. 100Hz/ch - 1250 channels
ETSI-LTN: Mode C, (101 Ksym/s). 1200 bytes incl. sync+preamble
LoRa SF12 250bps. Unacknowledged. 32 bytes incl. sync+preamble.
In practice, these networking protocols are Aloha-style and that they are only
around 18% effecient.
The more devices per bandwidth the better and clearly MittoNet and SigFox comes out on the top here. Also interesting is the absurdly low number of devices LoRa can achieve on the same bandwidth!
# No vendor lock-in
The MittoNet protocol is open, vendor neutral and runs on any commercial off-the-shelf (G)FSK transceiver. This drives cost down, increases competition and encourages both companies and the community to participate.
Some protocols, like LoRaWAN, require the use of proprietary hardware. This does nothing for competition and price and also create a vendor lock-in for the customer.
# Edge Computing and latency
More and more data is being generated and the sheer amount of data generated by sensors in the future is staggering. Also as low latency becomes more and more important. Therefore, the IoT protocol must be able to support the Edge taking decisions based on the sensor-data.
Taking decisions based on the sensor-data requires that data is decrypted at the edge. This leaves out protocols that has end-to-end encryption (from sensor to Application Server) as the Gateway has no way to decode the encrypted data.
By defining "The Edge" as the first step after the data has been sent from the sensors/End-Devices, then the MittoNet Gateway is the Edge Device in MittoNet.
Data per day for 10000 sensor nodes sending data every 5th minute yelds 2.3 Terabytes of data every month. So Edge decision making is critical for latency reasons, being able to work during offline periods but also for bandwidth and storage reasons.
# Simpler for developers
The fact that the protocol includes simple application layer features makes it easy for developers to develop code for sensors and End Devices. Simpler means less bugs, cheaper rollout and maintenance and easier to extend with features as well as develop custom sensors and devices.