Tricky: WPANID, WNWKPANID and multiple coordinators

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a tricky one: I am about to set up a network with ~25 nodes (all routers) and would like to have 2 coordinators. This is based around Zigbits with SerialNet.

What I want is to have the routers to connect to any of the 2 coordinators by joining either network, so that if one fails all devices would connect to the remaining coordinator. Obviously, I don't want any other "unknown" routers or end-devices being able to connect to that mesh, nor do I want my devices accidentally to connect to an "unknown" coordiantor.

I am currently setting WPANID=0 and WNWKPANID to "my number" (1234) on all devices.

The guide says that if I would start a 2nd coordinator, it should create a mesh using a different WPANID and nodes will connect to either mesh (because they all do have the same WNWKPANID).

But there a plenty of questions
- Is that how it works?
- Or would it be better to set WPANID to "my number" and leave WNWKPANID to FFFF?
- If it does work that way, is there any way to guide a router towards one of the meshes in an easy way?

Thanks in advance

Last Edited: Fri. Oct 16, 2015 - 02:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But there a plenty of questions
But this forum is NOT the place for questions.

I'll move the thread to the wireless forum for now.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are trying to do something really wired, but here it goes. WPANID must be different on different coordinators, otherwise it is impossible to predict how stacks will behave.

Nodes might have zero WPANID, they'll pick first available network in this case.

Having fixed WNWKPANID is not standard anyway, but it is a bad idea to have two coordinators have the same WNWKPANID. So I'd leave WNWKPANID undefined (0xffff).

Use security to protect against other devices joining your network.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
WPANID must be different on different coordinators, otherwise it is impossible to predict how stacks will behave.

If I set it to 0, the stack is creating a WPANID based on the MAC address. So, that should cover this....

alexru wrote:
Nodes might have zero WPANID, they'll pick first available network in this case.

Yepp, that's what I am doing - and what I want

alexru wrote:
Having fixed WNWKPANID is not standard anyway, but it is a bad idea to have two coordinators have the same WNWKPANID. So I'd leave WNWKPANID undefined (0xffff).

It looks tempting to use WNWKPANID to separate the meshes. Maybe I need a better understanding here:
What is this number actually for?
And what could go wrong if I use different WPANIDs but the same WNWKPANID?

alexru wrote:
Use security to protect against other devices joining your network.

The problem starts with which of the 2 coordinators to declare as the Trust Center.
Then, if one of my devices does find a "foreign" mesh and tries to attach (and fails because it can't answer the security keys), how would I get the device to try further? Or does it that automatically?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Baycity wrote:
What is this number actually for?
To identify PAN ID in messages, so you don't have to transmit 8 bytes in each frame.

Baycity wrote:
And what could go wrong if I use different WPANIDs but the same WNWKPANID?
Normally it would trigger PAN ID conflict resolution. All nodes know networks's extended PAN ID (WPANID) and short PAN ID (WNWKPANID). If node receives a message containing both PAN IDs (periodic Link Status, for example) and this information does not match note's own information it will initiate PAN ID conflict resolution. Usually short PAN Id is selected randomly and there is a chance that random number is the same as in some existing network, so this is a normal process.

In case of SerialNet build (and public versions of BitCloud in general) PAN ID conflict resolution is disabled, since it takes space and it is a very rare event, if not forced intentionally.

So I honestly have no idea what might happen, but it is not a normal operation mode.

Baycity wrote:
The problem starts with which of the 2 coordinators to declare as the Trust Center.
SerialNet only supports basic security mode, there are no Trust Centers in ZigBee understanding of this term. Just give them both the same network key.

Baycity wrote:
Then, if one of my devices does find a "foreign" mesh and tries to attach (and fails because it can't answer the security keys), how would I get the device to try further? Or does it that automatically?
+WJOIN will return error and your application should keep trying.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
In case of SerialNet build (and public versions of BitCloud in general) PAN ID conflict resolution is disabled, since it takes space and it is a very rare event, if not forced intentionally.

Aligns with what I saw here: The 2nd coordinator gave me a copy of what I saw on the main coordinator in terms of output. after a few 10 seconds, it stopped. And when I tried a +WLEAVE, it crashed/froze.

I wonder, when the whole thing of Zigbee was designed in the first place, how was it planned if 2 users would have their networks nearby so that a node could "see" both coordinators? Was it planned that users do need to set their coordinators PANID into all their devices?

alexru wrote:
SerialNet only supports basic security mode, there are no Trust Centers in ZigBee understanding of this term. Just give them both the same network key.

Ah, and set WTCADDR to FFFFFFFFFFFFFFFA or leave it to the default and set WSECSTATUS=0, I see.

alexru wrote:
+WJOIN will return error and your application should keep trying.

Means, at the next +WJOIN attempt it will try a different mesh if more than one is in reach?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Baycity wrote:
I wonder, when the whole thing of Zigbee was designed in the first place, how was it planned if 2 users would have their networks nearby so that a node could "see" both coordinators? Was it planned that users do need to set their coordinators PANID into all their devices?
Different profiles solve this problem differently. There is no universal "ZigBee solution".

Baycity wrote:
Means, at the next +WJOIN attempt it will try a different mesh if more than one is in reach?
It will try "the best one", which one is the best depends on the number of factors, but best signal is probably the most dominant.

ZigBee is messy in this way and SerialNet limits you even more in what you can do.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Was just reading the NWKPANID section again and realised that there is a good chance that my repeaters will cause network separation if the coordinator drops out and gets restarted, considering that I use a non-fixed NWKPANID.

So, just to clarify this:
If I go for 0xFFFF = automatic short PANID and my coordinator gets restarted, it will form a mesh with a new short PANID and therefore the routers will not be able to connect to the coordinator any more?

Will be no problem for our 'smart' devices (loggers) as they try to re-join after a while if they can't get data through.
But for our passive routers (just pre-configured Zigbits for extending the mesh), I have no idea how I could get them back into the mesh.

You said, the source for SerialNet is avaiable? Maybe I have to take that and add a command that does a leave+join if there is no traffic for several minutes. Just an idea...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Baycity wrote:
You said, the source for SerialNet is avaiable?
Ask avr@atmel.com, they'll tell you how to get it.

Baycity wrote:
Maybe I have to take that and add a command that does a leave+join if there is no traffic for several minutes. Just an idea...
You need to send data from time to time and if it fails, then rejoin.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.