Zigbe Specification Network Specification ( 2008 - Sec 3.6.3.1 ) on routing cost indicates that link cost function is primarily decided by implementers though the initial cost estimates shall normally be based on average LQI.
Can any one tell me specifically how Z-Stack chooses to implement link cost function.
Hi Andrew,
here is a snippet from Z-stack (ZNP) code:
// LQI to Cost mapping#define MIN_LQI_COST_1 12 #define MIN_LQI_COST_2 9#define MIN_LQI_COST_3 6 #define MIN_LQI_COST_4 4 #define MIN_LQI_COST_5 2 #define MIN_LQI_COST_6 1#define MIN_LQI_COST_7 0
Regards,
Ilya
So, I understand that the Zigbee Spec says implementers can do more or less what ever they want for link cost (0..7 probability of delivery on the link), but that an average of lqi over a period is a recommended basis.
Do you know if Z-Stack JUST implements link cost based on lqi on its own OR on an average lqi. If on an average, then over what period of time / rolling average ?
Does Z-Stack add anything else to the link cost function or just use LQI?
Z-stack implements 3 modes of the LQI evaluation. You can find the brief explanation in Z-stack Developer's Guide (ZMAC LQI Adjustment).
The default mode is just linear scaling of the RSSI. In turn, the RSSI value is generated by hardware (see CC253x User's Guide, 23.10.3).
Sorry... So to clarify, my question isn't about lqi per se. Z-Stack is an implementation of Zigbee right?
Roughly... Zigbee spec seems to indicate that routing is based on path cost which is defined as the sum of each link cost (probablility 0..7 to deliver on link). Link cost function is up to the implementer (TI in the case of Z-Stack).
So what is link cost to Z-Stack ? Is it just current LQI on the link (using one of three modes) or is it average LQI (and how is that defined) or does it consider some things other than lqi as well?
Sorry.. Hope this question makes sense. And thank you so much for taking the time to answer, I really appreciate it.
In Z-stack, the lookup table is used to perform nonlinear mapping between the path cost (7 levels) and the LQI. This means, for example, for LQI>12 the path cost is equal to 1, for 9<LQI<12 the path cost is equal to 2 etc.
The LQI value can be evaluated using the RSSI, correlation and other metrics or their combinations. As the RSSI value is the result of averaging the received power (8 symbol periods), the LQI (and the corresponding path cost) is also the averaged value.
Thanks for that Ilya,
So it looks like Z-Stack basically just uses just current LQI as the zigbee link cost used for path cost, although LQI can include RSSI as a factor and RSSI is avaeraged over a short period.
Thank you.
Just to refine the issue - the mapping between LQI and the link cost is nonlinear and in the simplest scenario the LQI value is proportional to the (averaged) RSSI value.
Ok, thanks.
But, LQI is a kind of 'link' cost though isn't it not a kind of 'path' cost?
Sorry for some mess...
Of course, the path cost is a sum of link costs and the link cost is based on the LQI value.
Slightly off topic, but just curious.
I understand zigbee essentially based on aodv and I was wondering if the active route time out for z-stack is configurable at deployment or is fixed in the z-stack specification and if so to what?
The active route timeout is configurable at runtime. The value should be the same for all nodes in the network.
Right, runtime?
Not build / deployment time?
Are there any pitfalls / particular care to take here presuming Z-Stack API allows a change dynamically?
Under runtime I mean the situation when the value of timeout can be changed any moment you want (without rebuilding the firmware). It seems reasonable to name this moment 'the deployment time' as during the normal operation such a change is not required.
To avoid misoperation the value of timeout should be the same for all nodes. Another point to consider is a particular case of infinite timeout. Due to the memory constrains this setting may lead to the loss of routing capability.
Ilya,
Sorry to trouble you with just one more question.
I see from 802154 standard that LQI may be derived from signal/Noise ration. Since this may vary a great deal dependant upon traffic at the point it is taken, then my thought is that take just once and then used for an LQI which is subsequently used at the network layer to fix a routing path, it may not be a true reflection of the LQI of that link most of the time.
Do you know what the common averaging strategy is here to be able to provide an LQI that more generally reflects the quality of the link rather than at one point in time?
Hope this makes sense. You say with RSSI you use 8 symbol periods (is that very short, would it make a true reflection of the ongoing quality of that link?) what are 8 symbol epriods?
as follows from IEEE802.15.4 spec, the symbol rate for 2.4GHz PHY is equal to 62.5ksymbols/s. So, 8 symbol periods are equal to 0.128 ms and this value is the RSSI averaging time.
The RSSI itself is just the receiver ED. It includes neither (thermal) noise nor correlation but it is biased by interference (if any). The noise level is rather fixed and the SNR can be considered just as some scaled version of RSSI. In the Z-stack, the default option of the LQI estimation algorithm scales the RSSI taking into account some predefined max and min values.
In order to take into account the interference the correlation value may be included in the LQI estimate. The correlation is calculated on the PHY level (by the hardware in case of CC2530) and is also averaged over 0.128 ms.
Therefore, the NWK level can get the LQI value for every packet received. I agree that this value reflects rather a point in time than the true (mean) value of the link quality. Actually, the NWK level uses not LQI but link cost or path cost values. I suspect that the Z-stack performs averaging of LQIs before mapping to the link cost (at least for the routing purposes). Unfortunately, I couldn't find any information about this issue.