Large wireless sensor mesh network using Contiki with MSP430/CC1120

Hello Thomas,

I agree having 250 devices in a network, mesh is a good approach. However mesh does not necessarily mean "easy configuration", since there are a lot of parameters to tweak and optimize in such network running an IP stack.

IPv6 and RPL routing is definitely a good solution, that many technologies use as building blocks. Exactly what rouing protocol to use is much up to the end application. RPL is optimized to send data one-to-many or many-to-one, which I understand is your use case. It is not optimum for P2P communication in large network, since data might need to pass all the way up to the Edge Router (sink) and then back down to the destination, due to the routing protocol. A good whitepaper on RPL (and all other IP technologies) can be found here: www.ipso-alliance.org/white-papers
RPL has two modes: storing mode and non-storing mode, in storing mode all routers contains a routing table thus consuming RAM, in non-storing mode the full route is carried in the packet header thus increasing the overhead and need for fragmentation. In Contiki storing mode is used.

The COOJA tool should give you a very good understanding on how your network will perform, I suggest to use heavily.

Contiki does indeed have a CSMA (Carried Sense Multiple Access) mechanism implemented that should take care of collisions, see /core/net/mac/csma.c/h This is not directly connected to the RF driver, however the RF driver need to support Carries Sense, or reading of the current RSSI level. Something that your driver should support. Updated drivers for CC1101 and CC1120 are on its way in to Contiki with this pull request: github.com/.../1002 There are also work being done to add CC1200, on a platform running CC2538 as host MCU and Ethernet as interface to e.g. Internet or other backbone. The platform and cc1200 radio drviers will be added to Contiki in the coming months.

I do believe you have right hardware, what one could need to look into is the amount of RAM you would need for your routers with such large network. You might consider using e.g. CC2538 as host MCU couple with a sub-1GHz transceiver, e.g. CC1200 or CC1120.

Regards,
Jonas

Thank you very much for your reply.

Yes we need multipoint to point communication with one sink (border router) per network.

Right now I'm experimenting with RPL and IPv6 and with the Connection Tree Protocol and the Rime-Stack as we don't need IPv6 at the sensor network. Problem again is (many) lost messages with a high amount of nodes.

I guess RPL would be better in the sense that there are more configuration options like only endnode, router etc.

My question is if the Collection Tree Protocol or RPL would be a better choice for a wireless sensor network with about 250 nodes that send its data periodically to a sink? Actually we don’t need IPv6 in the sensor network itself.

Additionally it should also be possible to reach a specific node from the sink.

I am sorry but I do not know the CTP protocol well enough to answer this question. Should be possible to get extensive information on RPL vs. CTP on the Internet. We have seen real world deployments of RPL based network of 150 devices performing excellent.

Thank you very much for your answers.

I now have good simulation results (using the Cooja simulator of Contiki) with 250 nodes. I simulated different platforms. I mainly simulated 2,4 GHz radio devices because of the better support of those in the simulator.

The radio duty cycling protocol ContikiMAC of Contiki does work very well with 2,4 GHz radio devices, but not with the CC1120. There I had to use the less efficient and less performant radio duty cycling protocol drowsie of Thingsquare.

Is it possible to use the eWOR of the CC1120 with Contiki? The driver of the github pull request doesn't support it!?

No there is no support for either Wake On Radio (WOR) on CC1101 or sniff mode (eWOR) on CC1120/CC1200 as of today. We are looking into adding it to the future drivers. Will keep you posted!

Hi! I'm Marcus from Thingsquare.

Seems like a cool application with vast market possibilities. I like those :).

It would, as you noticed, face at least two challenges: network congestion and possibly running out of RAM for routing table entries, depending on the network depth (hops). ContikiMAC is really good at conserving power, especially when there are many unicasts, as it can optimize the wake-up train of transmissions (make it shorter). It is however single channel which means that you will have problems with scalability and power consumption (broadcasts are costly in terms of power and bandwidth), and regulations (transmissions should be spread out over the spectrum). Collissions equals retransmissions equals wasted energy and might kill battery-operated devices prematurely.

RPL is an excellent choice for you as it will detect problems such as weak or disappearing links and self-repair accordingly. It also uses little control traffic to maintain. A drawback is that parents and especially the root needs to keep routes down to devices in RAM, which often runs out at around 32 or so destinations. You can mitigate it eg by throwing more routers at it, effectively partitioning the network into two or more parts. You state your need as a sensor reading an hour, which is a walk in the park in a network that size. How deep do you expect the network to be, ie how many hops typically and at the most?

Nowadays (time flies) the cc2538 + cc1200, or the cc1310, are more up-to-date alternatives to the msp430+cc1120. You can buy hardware from Zolertia, Weptech, or TI and have a prototype online in a few hours. The MSP430 have very good low-power capabilities, but so has the cc2538 and the cc1310 and comes with additional benefits like a basically de facto standard architecture. The cc2538 has plenty of RAM and flash and so on.

At Thingsquare we run a protocol added in 2012 in 802.15.4e called Coordinated Sampled Listening, with tweaks and modifications on our own. The standardized CSL multichannel support have very poor scalability properties and seems, IMHO, like an afterthought. So we developed our own frequency hopping to satisfy regulations and be robust. It works extremely well. We have also developed data disemination mechanisms and abstractions that can handle thousands of devices in a single network (ie one router), but of course it depends strongly on the application. A device that must send accelerometer data at very high speed should probably not duty cycle the radio while sending data, and so on. But for a once-an-hour network of that kind, it's actually quite simple to accomplish once you have the right tools.

I hope I helped clear out some of your questions and doubts and feel free to hit me up at marcus@thingsquare.com if you like to discuss this further.

Best,
Marcus

Hello,

thank you very much for your answer.

Regarding the size of the RAM for routing tables: Does every parent node need to have all the downward routes to each child node in their routing table or is it enough if the border router has the routes to all of the nodes?

HI Marcus,

We are currently developing a wireless sensor network based on CC1310. In our system, we will have as much as 1000 nodes within a transmission radius of 500m (open space), this is meant for dairy cow monitoring.

I am not too sure if we have chosen the right SoC (CC1310) to work with, and I am bit worry on the design of the concentrator (i.e. the router) that can handle 1000 nodes. In addition, the wireless sensor network will be deployed at China where ISM band is 433/470/779MHz. Would you mind to advise me on the hardware that is suitable for both the end device as well as the concentrator? Thanks!

Cheers,

Howard

I think CC1310 is right choice.

Hi Howard,

in this case the network/application is the limiting factor rather than exactly what chip you are using. The cc1310/cc1350 has limited RAM, but so has the cc2538 (that then could use a cc1200 sub-GHz radio) for example (32 kB still wouldn't be enough), thus the cc1310/1350 would work very well. They also have excellent low-power properties, which I can imagine is important in a cow network.

Since the network size is large and the application simple, you would most likely not use downward routing at all since the routing tables would need such large RAM. Instead a flooding schema or such would be used for downward message propagation (root node -> cow device :)). This is something you do want, since you may want to re-configure the devices, ping devices, perform firmware updates over the air and so on. Data to the backend would go upwards to the root node, and for that the cc1310 (etc) has ample room for the routing information necessary.

We've worked hard on making such applications viable since there are many non-trivial and non-obvious traps that could render the network perpetually inaccessible. We've made it very simple to expand a network - basically just add another gateway (concentrator), they will use different freq hopping schemas that allows both to coexist. The gateways we use are typically cc2538+cc1200 based.

Hope this helps, feel free to drop me an email if you want to discuss how we may be able to help you more,
Marcus
marcus@thingsquare.com

Hi Marcus,

Thanks for the reply!

May I ask a few more questions"

a) What do you mean by downward routing? Having all the sensor nodes connected to one concentrator?

b) For gateway with different freq hopping schemas, does it mean we can program the nodes to transmit with different channel and use only 1 concentrator which will consistently switch the channel to receive data? i.e. 100 nodes, 1-10: Channel 1......91-100: Channel 10, Concentrator keep switching from Channel 1 to 10 to pick up the messages from the 100 nodes. If this is the case, how should we prevent loss packet? i.e. Node 1 is transmitting using Channel 1 but Concentrator has just rotating to Channel 2, and need to go one full round before coming back to Channel 1?

c) Does the existing fateway (CC2538 + CC1200) supports transmission at 433/470/779MHz? It is because the intended system will eventually be deployed in China where the 3 frequency bands are the ISM bands.

Thanks!

Cheers,

Howard

a) downward is from the backend/gateway down to a device. You may think you don't need it, but when you do, and you will :), you will be glad you have it. Upward routing is toward the network root, or concentrator. (this is from the perspective of the 6lowpan common routing protocol RPL)

b) in our system, the gateway sets a hopping schema (eg hop 14-25-8-48-....) at certain intervals, skipping any blacklisted channels. All the devices that are associated with that gateway hops at the same time to the same channels. Since the channel hop sequence is set dynamically by the gateway, you can have several gateways at the same place as they will have different sequences. Thus, you can have eg 250 cows connected to GW 1 and 250 connected to GW 2. With our system, you can also disassociate devices from one gateway and "move" them to another gw.

c) look at the cc1200 page www.ti.com/.../CC1200 , it is declared to only support the following:
169
433
470
868
915
920
and 137 to 158.3 MHz, 205 to 237.5 MHz, and 274 to 316.6 MHz.

best,
Marcus

edit: to clarify point a, you don't need to have downward routes to enable downward messaging. You can use a broadcast-based schema if you design it carefully.

Hi Marcus,

May I clarify the following things with you:

a) In other words, the network structure is (Internet)concentrator -> multiple gateways -> sensor nodes, right?

b) May I know if the hopping schema requires all the sensor nodes stay in listening mode in order to hop to the corresponding channel set by the gateway? In our system, we design the sensor nodes to sleep most of the time, and only wake up every 15 mins (adjustable) to sample the sensor value, transmit the data, and go back to sleep. In this case, does it allow the use of frequency hopping feature?

Cheers,

Howard

Hi Howard,

How is your project going? Have you successfully handled 1000 nodes using CC1310 based on Contiki?

Regards,
Frank