Limitation ZigBee Pro and number of routers

Good question. I'd be interested in the answer ... What is the max device depth in practical ? I also want to make a huge network and I'm worried about this parameter.

Hi,

post you have been suggested is about ZigBee and Tree Adressing.

My question is about ZigBee PRO and Many-to-one routing and source routing.

I found that in the Z-stack Developer's Guide is already mentioned:

"For concentrator with no memory constraints, it can store all route record entries it receives and use them to send packets to the source devices in the future. Therefore, devices only need to send route record command once. However, for concentrator without source route caching capability, devices always need to send route record commands along with data packets. The concentrator will store the source route temporarily in the memory and then discard it after usage."

There is post about Z-Stack and external RAM and nobady helps.

http://e2e.ti.com/support/low_power_rf/f/158/p/17697/68731.aspx#68731

I want that concentrator can store route record enteries for thousands of routers. It is possible?

Regards

Hi Genzi,

the latest Z-Stack Version (2.3.0) has a source routing API integrated. With this new APIO you get a callback for each incoming route record packet by registering for ZDO_SRC_RTG_IND. This allows you to store this information whereever you want since it is possible to transmit the data with "AF_DataRequestSrcRtg" and a pointer to your stored relay list. So the only limiting factor is the packet itself. Every relay entry is two bytes long.

Hope this helps.

Regards,

Tobias

Hi,

I have been evaluating ZigBee and it seems to fit our applications well, but there's one special case like this I have been wondering about:

If I have a long daisy-chain of routers, how deep the network can be? There's not going to be any end devices, only routers and a coordinator. There will be some overlap, but basically the network is going to be just a long line of routers (hundreds, probably less than thousand).

I have to use ZigBee Pro (right?) and let's say I'll use CC2530. What things I have to consider? Tobias said the packet is limiting something. If I understood right, the packet might not have enough space to store all hops and that will restrict the network depth?

Regards,

Lasse

Edit: By overlap I mean multiple devices being in radio range (so the network will have some branches)

Hello again,

I have done some research, but I would like some clarifications. Please tell me if I have understood something wrong :)

I have a gateway (or something similar) which is used to manage the network (mentioned in the previous post). Practically nothing else communicates with routers (e.g. no router-to-router unicasts), so the best method is many-to-one and source routing. If I have understood right, then I face at least the following limitations:

• Relay Count: 1 Octet

• Limits maximum number of addresses in the relay list to 256
• Not too bad limit. If every node could reach next two nodes (and naturally those two before), I could have about 500 nodes. And if the gateway is in the middle of the chain, there could be 1000 nodes (500 in both directions)

• Packet size
  • Maximum packet size is 127 octets
  • After overhead there's less than 100 octets left and as Tobias said, each address takes two octets (16-bit nwk address)
  • Limits maximum number of addresses in the relay list to less than 50?

Anything to add?

How can I overcome those limitations? Here's two ideas:

Fragmentation. Can I use message fragmentation? I haven't gone in to the details, but I think about relay list as overhead, and I would expect that I can't send overhead in different packets. I think I'll have to do some reading...

"Normal" routing. I just need to have enough RAM for the routing table, but otherwise there's no "hardcoded" limitations? Using RREQ & RREP the cost field increases with each hop, but is the actual route been sent with the RREQ or RREP packet? Z-Stack Developer’s Guide: "Each of these RREQ packets will contain the total route cost along the route that it traveled." If I understand that right, then there's no route information sent with the packet, but just the link cost of the route taken? It would be "along with" if the route would also be included? English is not my first language, so it's better to make sure ;)

I have been pondering these questions today and I'm starting to feel more and more confused, but I think that's normal. More coffee...

-Lasse

Good morning,

you can forget fragmentation + source routing. Each of the fragmented parts of the packet needs its own complete relay list to find the destination.

Normal AODV routing should work (theoretically) I think. If you only have one destination you could perhaps set the timeout value for your routes to 0 and therby deactivate route expiry. Than perhaps the route reqeust procedure is only called once and each node knwos how to route the packets to the concentrator.. Possible, I think.

Coffee ? Good idea.

Tobias

Good morning,

Thanks, now I don't have to consider fragmentation.

I had a new idea: What if I design the system to use only broadcasts when contacting nodes? I don't think I really need to contact each node independently. I could set the nodes to send their status or whatever information I need on irregular intervals and use broadcasts if I need to send commands, for example, to "turn everything on". This way I could use many-to-one routing, but I don't need to use source routing. Does it sound feasible?

-Lasse

Keep in mind that zigbee will choose the *best* route to take, not necessarily the one with least hop count. So if there's a route limit of 256 devices then your limit may be 256 devices total in your network.

How can you be sure that devices will always be in order (1 ... N)?

Practically speaking, you'll probably want to limit your network to less than that; about 200 devices for reliability reasons. I would recommend limiting it to 128 nodes so that if one coordinator goes out then the devices can switch to another one without loss of service.

I'm curious, what is the application? It sounds interesting. Might even be worth a custom protocol, different from Zigbee. You could do something like:

Broadcast message to anyone who can hear, with IEEE 64bit address in it. Message has sequence number (2Byte) and hop count (1 or 2Byte)

When receiving a message, if message is for that device, use it. Otherwise increase hop count and retransmit.

If received a message with same sequence number twice, don't forward it.

...or another simple custom protocol.

--Derek

Thanks for your input, Derek.

I'm sorry, but I'm not allowed to reveal application details, but I'm sure you can think of many applications, where i.e. a long line of sensors are used to measure something, um, long? ;)

I don't want to stretch the network too thin (to prevent most of the network failing with just one broken router, like you said), so I hope we are able to have at least 4 neighbors for each node (two forward, two backward).  I want to have hundreds of nodes and therefore I need a network depth of hundreds, because, as you said, ZigBee determinates the route.  For example, if I want to have 400 nodes in a line and RF range is enough to always reach next two neighbors, then network depth would be 200 in optimal situations, but in worst case scenario the nwk depth would be 400.

 I’m currently trying to find the limitations imposed by ZB specifications and CC2530. I need to have network depth of hundreds I currently have two options:

Normal AODV routing works if every device has enough memory for the routing table? If I have 400 nodes, the routing table shouldn’t be too big. Or do I run into some kind of limit, like the number of entries in routing table is limited by 8-bit number etc.

Many-to-one with broadcasts should work also? Does anyone think of some limit? There could be something like number of hops is stored in 8-bit number when broadcasting…

The thing with ZigBee is that we are considering migrating to it. Our other products are probably going to use some standard profile, but this is a special case that I’m researching. Actually we are currently using our "own" protocol in those other products, but it’s not designed for this kind of thing (as if ZigBee is). And someone has to get familiar with ZigBee anyhow, so we thought that if I manage to wrench this out of ZB, then those other applications should pose no challenge.

Regards,

Lasse

I see - the nice thing about an outdoor application like this is that you get really good range, especially if you're up high, and also have access to unlimited power via solar. Zigbee is a good technology, can do a lot with it on little micros. You may also want to look at the forthcoming CC2530ZNP, it's a firmware image for the 2530 that makes it into a Zigbee coprocessor, like the cc2480 was. That makes app development easier.

The CC2530 may not have enough RAM for your application. You may be better off with one of the other platforms, like MSP430F5438 which has 16kB of RAM.

TI, is there a RAM calculator available to figure out how much RAM an application like this will need, given node depth, number of children, etc?

Regards,

Derek

Hi sorry to bother you,

Do you have find out some solution to used on the long line sensors schema on zigbee now? 

Hi,

Unfortunately I have not found a solution, the project has been suspended.

 Regards 

OK. Thanks.

Hi. 

In case your project comes back to life, we have a semi-custom, modular protocol which should do what you need with some effort.  Contact me if that's of interest. 

Regards, ...

yes, I have interesting. 

hello，

      now ,I  want  to create a network just the same as yours.

     Would you mind telling me how many routers you used finally.