Reply
Posts: 32
Registered: ‎12-11-2016

Understanding ZigBee neighbor/routing/association tables in Ember

I'm trying to understand the ZigBee routing tables from the Ember - or more specifically, the associated devices list. See below - this shows no associated devices, but we have neighbors, and routes to other devices.

 

The "associated devices" comes from the IeeeAddress ZDO call - the devices shown as neighbours were directly associated to the coordinator - clearly they are still communicating as they operate correctly, and have a good LQI - why are they not showing in the list of associated devices in Ember processor?

 

Thanks

Chris

 

ember-tables.png

Posts: 138
Registered: ‎11-06-2014

Re: Understanding ZigBee neighbor/routing/association tables in Ember

Hi cdjackson,

 

What is the RequestType for your IEEE Address Request? According to the zigbee spec:

 

Request type for this command:
0x00 – Single device response
0x01 – Extended response
0x02-0xFF – reserved

 

I believe the "associated device" is only required to be in the response frame if the RequestType is 0x01 for extended response.

 

Best regards,

Yuping Xiao

Posts: 32
Registered: ‎12-11-2016

Re: Understanding ZigBee neighbor/routing/association tables in Ember

Hi,

Yes, request type is set to 1 -:

 

 

14:44:27.047  DEBUG  TX CMD: IeeeAddressRequest, nwkAddrOfInterest=0, requestType=1, startIndex=0

 

I'm reasonably sure this works fine with the TI CC2531 (although I'll double check that this is still the case).

 

Cheers

Chris

Posts: 138
Registered: ‎11-06-2014

Re: Understanding ZigBee neighbor/routing/association tables in Ember

Hi Chris,

 

Could you share your packet trace with us so that we can analyze the details? If it contains sensitive information you can share it through the support portal.

 

Thanks,

Yuping

Posts: 32
Registered: ‎12-11-2016

Re: Understanding ZigBee neighbor/routing/association tables in Ember

Hi Yuping,

Sure - what exactly do you want? Since this doesn't go over the air I don't have a capture, but I can provide the debug logs from my software (EZPS/ASH packet dumps).

 

Cheers

Chris

Posts: 138
Registered: ‎11-06-2014

Re: Understanding ZigBee neighbor/routing/association tables in Ember

Hi Chris,

 

Wait - now I'm a little confused. Do you mean you are not sending the IEEE Address Request to a remote device but to itself, and it's a local loopback? In that case wouldn't you just look up the neighbor table locally? Could you describe the transaction in more details: the source and destination of the request and response, and device types, and purpose of this request, etc.?

 

Thanks,

Yuping

Posts: 32
Registered: ‎12-11-2016

Re: Understanding ZigBee neighbor/routing/association tables in Ember

Yes - this is sent locally between the host and the NCP, and yes, I realise we could use another (EZSP) request rather than the native ZigBee ZDO messages. However in this case we're using the ZDO requests to get this information for a number of reasons, and I understand that the Ember should response to the ZDO requests (and it does).

 

 

We have a NCP application, communicating to the Ember via EZSP/ASH. The Ember is configured as a coordinator and has other devices (mainly routers) connected to it. We request the IeeeAddress, ManagementLqi and ManagementRouting requests - these all work fine - as shown in the image above we get the neighbor table, routing table, but the associations are normally empty - not always, but normally, and it's certainly not consistent between these three tables.

 

The three calls I mention above are all sent very close together (ie milliseconds apart - one after the other), so I would expect a consistent dataset?

 

These ZDO calls are sent to the Ember in the SendUnicast EZSP message.

 

As per the initial message, this all works ok with the exception that the associated device list is empty.

 

Thanks again.

 

Cheers

Chris

 

 

Highlighted
Posts: 32
Registered: ‎12-11-2016

Re: Understanding ZigBee neighbor/routing/association tables in Ember

For comparison, I used the Ember GetNeighbor call at the same time (roughly) as the ZDO message, and they are returning consistent data. See below - the first 2 lines are the Ember calls - returning a single neighbor, and the third line is the ZDO call - also returning consistent data.

 

 

 

21:05:40.594  DEBUG  EzspNeighborCountResponse [value=1]
21:05:40.610  DEBUG  EzspGetNeighborResponse [status=EMBER_SUCCESS, value=EmberNeighborTableEntry [shortId=29342, averageLqi=255, inCost=1, outCost=1, age=3, longId=000D6F00056B43CC]]

21:06:09.873  DEBUG  RX command: ManagementLqiResponse, status=SUCCESS, neighborTableEntries=1, startIndex=0, neighborTableListCount=1, neighborTableList=[NeighborTable [extendedPanId=987654321, extendedAddress=0022A300001732BF, networkAddress=0, deviceType=COORDINATOR, rxOnWhenIdle=1, relationship=PARENT, permitJoining=2, depth=0, lqi=255]]

Likewise, the routing table also seems consistent (from a quick check).

 

So, hopefully this alleviates your concern about HOW I'm getting the information, and brings us back to the original question - what does the list of associated devices returned from Ember mean?

 

I thought that this was the list of devices to which the Ember was parent, but if we look back to the image I posted at the top of this, we see that the coordinator has known routes, and neighbors, but no associated devices.

 

 

Given that these devices have joined the PAN, shouldn't they be in the associated devices list?

 

 

Posts: 138
Registered: ‎11-06-2014

Re: Understanding ZigBee neighbor/routing/association tables in Ember

@cdjackson: here is what the spec says with regard to the extended response request type:

 

"... The Remote Device shall also supply a list of all 16-bit NWK addresses in the NWKAddrAssocDevList field, starting with the entry StartIndex and continuing with whole entries until the maximum APS packet length is reached, for all devices in its nwkNeighborTable where the Device Type is 0x02 (End Device)."

 

Note that only end device children should be included in the list of associated devices; not routers. Could this explain why sometimes you see the list empty - could you confirm the coordinator does have end device children?

 

I have run some tests myself and verified that the packets over-the-air agree with what the spec requires. Specifically, in my test the coordinator has one child in its child table; a router sends IEEE address request to the coordinator with extended response request type 1 and StartIndex 0, and the coordinator does report the child in its IEEE address response.

 

Best regards,

Yuping Xiao