6

I am working with NB-IoT Modem - Quectel BC95 that will be used in a simple IoT sensor that will periodically (Once per hour) send measurements to our server.

Because of the restriction in place by the service operator, I can't use the hardware implementation of CoAP/M2M (Neil Messaging Protocol - as they call "it") and I am stuck with Raw UDP Messaging (Socket).

I want to keep it real simple and keep the "size" of the data at a minimum but still, be prepared that server can expect thousands of these sensors to stream data. I was thinking about just a simple JSON/CSV values inside a UDP message but have no idea if this solution is "Robust" or Secure enough.

Can you please point me into the right direction? Is there any "standardized" way to send data from IoT sensors to a server while using just a simple UDP socket and is easy to implement on the MCU side (We are very resource limited)?

4
  • the UDP protocol does not have a guaranteed delivery mechanism – jsotola Oct 26 '18 at 5:52
  • UDP is great if you're ok with losing packets now and then. It may work for you with sensors continously sending data. – Paulo Soares Oct 26 '18 at 9:20
  • 1
    What "restriction in place by the service operator" could prevent you to use a well-defined standard protocol? Rolling your own will just mean to re-invent what has already been invented. Eg. for privacy you'd have to use DTLS over UDP (coaps://), for reliability you'll need sequence numbers and retransmissino (part of CoAP), etc. – Gambit Support Oct 26 '18 at 14:31
  • What security protocol will you use to validate the data is real and not faked? – SeanJ Oct 28 '18 at 22:46
0

I'm assuming you're already ok with losing some UDP messages on the internet. There are a few other issues you may want to consider:

  1. Will someone on the internet feed you bytes (probing) that may come in as junk
  2. Will someone deliberately feed bad data. (format matches, but bad numbers)
  3. Will this operator have trouble with udp later, with tcp only ok ?

If they atleast allow HTTPS, you could put a certificate on your connect and only accept known devices at the server and solve 1, 2, 3.
If you are actually stuck with UDP, you have 3 as a risk.
To solve 1, send a message that has a blob with your data and a checksum. You could use nano protobuf for making the blob if you prefer that to json. So, at the server, you may know if it doesnt parse or if the checksum does not match, you can prevent 1 above.
To prevent 2 above also, you'll have to use a checksum that cannot be generated by someone else, such as a hash of your data, concatenated with a known secret, (and adding a salt for better protection), etc. Another option: encrypt what you send with a known secret. If you can decrypt it, it means 1 and 2 are both ok. Look at DTLS.
Now, you'll have to find a way to store those keys, make them, etc. And if someone in your org leaks the keys, its a big problem !
Also, see if you can allow only a certain IP range at the server. Atleast blocks some of the attacks. But given that you're using NB-IoT, maybe there's some way to do this well with the cellular provider. Ask them. Maybe, with that support from the cellular operator, you dont have the risk of 1, 2 above.
You'd be reinventing so much that's in CoAP otherwise!

2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.