/ 6LoWPAN

[6LoWPAN] MQTT-SN and Contiki-OS / Part 1

warning
To start reading this post, if you don't have any idea about 6LoWPAN and what I'm writing about, see the links below:

Both links teach you how to init on Contiki and help to run this example. =)

Intro

I'm writing a series of posts about 6LoWPAN because studying this for a year ago for my term paper, makes me know that the possibilities are almost infinite and with IoT growing up, 6LoWPAN will represent a piece of these devices on this new tech revolution. If you already had worked with IoT protocols, probably you heard about MQTT, this protocol is so widespread into IoT that even big players as Philips, General Electric and facebook are using for their products.
mqtt
if you don't know nothing about MQTT, read all parts of this tutorial.

MQTT-SN

Alright, I'm with you but why MQTT-SN?

With a more simpler approach, MQTT-SN is the small brother of MQTT but with less resources for limited devices (constraint RAM and flash). While MQTT uses TCP, in the network stack, MQTT-SN uses the UDP protocol what means so much less overhead on the connection, where re-transmissions with back-off times are irrelevant and you'll need a small portion of resources in your device to work with IP stack (ideal for IEEE 802.15.4 networks). The name MQTT-SN means for Sensor Networks and for this reason, some differences are needed to get things working good. See the official documentation of the MQTT-SN protocol in the page 4, where both MQTT's protocols are compared. I'll highlight the main reasons that differ and are important to you know:

  • In MQTT-SN, you don't need to use the full name of the topic to publish a message, you can use just a number (topic IDs) that you have registered earlier with the broker for that topic. Example, besides send in the packet "/super_ultra_sensor_iot_topic/" you would use 22, where 22 represent the topic registered in both client/server.
  • A custom keep-alive type of message is defined for sleeping devices, usually them that're battery operated. That's I had talked about...limited devices
  • The architecture had been modified by multiple MQTT gateways, where you have different ways to deliver the message to the broker.
  • As written before, you need to pre-define the relation between topic ids and meanings with some control messages changed between the node and the broker of the network.
  • Now you have a QoS (Quality of Service) -1, yes, it's -1 because you'll send in the mode fire and forget, what's common in Sensor Networks.

Working with Contiki and MQTT-SN

Sorry if you already know all of this or if I'm prolix/long-winded but I think that's important to make things clear before to show some code, if you didn't understand something, just ask about, I'll appreciate to help you.

To start this integration between Contiki and MQTT-SN, I'll separate in two-parts:

  1. Simulation with Z1 nodes
  2. Real nodes talking each other

It's important to make in this mode, because if you have problems with the first part, it's more easy to fix and following.

Part 1 - Simulation on Cooja

For MQTT-SN broker, let's use rsmb, simple and easy to use on Linux. This broker made in C language is lightweight to run in any embedded linux board (SBC). Don't worry to download and install this, I had created a repository with RSMB integrated for this post.

MQTT-SN and Contiki repository

Copy all the content to your local directory, make it and start a new simulation on Cooja:

cd your-contiki-directory/
git clone https://github.com/aignacio/mqtt-sn-contiki_example mqtt-sn-contiki
cd mqtt-sn-contiki
make all
cd ../tools/cooja
sudo ant run

compiling_time

Create a simulation with a rpl-border-router device firmware, usually the first device that you insert into simulation field and three nodes with the compiled firmware before (main_core.z1). After created, you'll have something like this:
cooja_demo
If you don't know how to create the simulation, maybe you didn't read the warning in the beginning of this post [go to read and after come back =)]. As in the previous posts, start the tunslip6 to create the tunneled adapter for the communication with our broker.

cd your-contiki-directory/tools/
sudo ./tunslip6 -a 127.0.0.1 aaaa::1/64

In the sequence open a new terminal and start our MQTT-SN broker that's in the folder that you had cloned from my repository:

cd your-contiki-directory/mqtt-sn-contiki/tools/mosquitto.rsmb/rsmb/src
sudo ./broker_mqtts config.mqtt #we must run as sudo because it uses linux sockets API =/

If you have mosquitto broker running on your computer, just close because rsmb also uses the default 1883 port that's the same that mosquitto uses.
mosquitto_problem
Once you get all running, you can use mosquitto-clients software to see the MQTT messages, subscribe with:

mosquitto_sub -t # -v

When you start the simulation, you'll see the nodes publishing in MQTT topics:

The core implementation of MQTT-SN in UDP that's inside the repository (mqtt-sn.c/.h) is coded by me and the main-code.c is self-explanatory to modify, but if you have some doubt about the implementation, just comment below or see the doxygen file in the references. My API of MQTT-SN to use it's in portuguese-br but if someone asks I translate to english without no problem.

Happy codding =)

References
[6LoWPAN] MQTT-SN and Contiki-OS / Part 1
Share this

Subscribe to @aignacio's