Zigbee routing feature problem

[Mateus Vesuvious]

Hi guys, 

 So i have some Nordic DK board including some dongles, NRF52840 DK, NRF52833 DK running with Zigbee and thread SKD 4.1.0 and make a mesh out of them. But I have this problem with mesh topology in Zigbee relating to route discovery. I did 2 experiments

1.The first experiment is set up like this figure 

So I have a mesh of devices including some zigbee routers and 1 coordinator like in (1). I tried to move the router 1 on top away from the coordinator so that it is out of range and would send a message to the coordinator through a hop in the middle like in the (2) . From what i learn in the zigbee spec, the router will try to fix and create a new route if the destination is unreachable. I use a sniffer to monitor the network but i did not see any route request sent even after 3-4 minutes. Then, I reset the device but still nothing happened. So how can I make a out of range router to rebuild a route to the coordinator. Is it suppose to make a new route when the destination address is not in the routing table.

2.The second experiment i did is that I create a mesh with 1 coordinator and 4 routers like the figure below 

So this time, i managed to make router 1 to join through router 2( which is near router 3) and send message to coordinator like in (1). But the problem is that, when i turn off router 2. In theory Router 1 should re route to path (2). But it did not, when it sent out the message, it kept sending to the addr 0x0000 and not start to send any route request. This time i also waited for 4 minutes and reset every device in the network. But still nothing happened. 

For the firmware inside, I ran Cli zigbee example coordinator and ran a custom firmware from light bulb example on all of the routers. I will attach the firmare at the end so that you can take a look at it with all the SDK config and makefile 

Thank you for any help, the code for router is included below 

Mateus 

light_bulb.zip

[tomchy]

Hello Mateus!

Could you point out the section inside the spec that obliges the router to keep an active route to the coordinator?

I was just thinking - could you configure a periodic reporting on the mobile router and rerun your tests? The CLI sample already has all required commands, no recompilation is needed.

The idea here is that sending reports to the coordinator at constant interval will push the router to refresh the route. Additionally - you will see if the router figures out the route, based on other packets.

BR,

Tomchy

[Mateus Vesuvious]

Hi Tomchy, 

Thank you for your answer.

For the first question, may be you misunderstand the figure i do not intend to say that the router should be keeping an active route. But the dash lines just mean that each router is in within the range of each other and it is possible for the router to route pathways along different dash lines . But as i have in the attached code. I only send the data to the coordinator so the   router should find the way to relay the message to the coordinator (a) if the coordinator is not the routing table and (b) if the packet sending not receive an ACK. as in section 3.6.3.5.1 Initiation of Route Discovery of the Zigbee spec line 8981 - 8983. But i do not see that behavior in the test above. 

For the second question, i also tested the configure report a few days ago. I use a the coordinator to bind and then configure the report for every 10 sec, but the result is still the same. Do I have to lower the time to even more to see the route discovery faster? 

And for the last question, can you show me what kind of packets to expect to know if the router figure out the route. For me i only know the about route request and route reply but i did not see any of them in either of the test case above. 

Thank you very much, please reply soon.

Best regards, 

PS: I include the spec that i read with this post so you can check if i misunderstand anything.

zigbeealliance.org/.../docs-05-3474-21-0csg-zigbee-specification.pdf

Tu 

[Mateus Vesuvious]

Hi Majeris,

Thank you for your answer. I am very happy to received it and give you back some more information so that i can crack this as soon as possible.  

Did you look into the Link Status of Router 2 before removing Router 1 out of reach of the coordinator? 

- Yes i did check all of the link status of Router 1, 2, and Coordinator. Since i only place them in the vincinity of each other (about 3 meter) each of them already contain links to others and the link cost are ranging from 2-4 for both incoming and outgoing path cost. In addition, from what i saw in your answer, when the router 2 had an entry in its routing table to the destination which router 1 trying to send, then router 1 will not initiate any request to re route. I do not think that this is really the case. Correct me if I am wrong, after 3 -4 minutes of router 1 get out of range, both router 1 and coordinator will not receive any link status update. With each link status periodically send at 15s and routing table aging is 3, the entry of routing table in both of them should be erased by then and then from what i understand, router 1 should init a route request. So, I do not see any how and why router 2 having a entry in routing table which router 1 trying to send to have anything to do with router 1 realising its link is broken and trying to repair itself. So please advise me how to get router 1 to do a route discovery when it is out of range. On which kind of condition that it has to meet before being able to do route discovery since it is pretty confusing to me until this point. If it is possible, can you point out the part where the condition in my test violate the zigbee specs.

What was the Link Status in Router 1 before turning Router 2 off? Did Router 1 had Router 2 in his Link list? Why do you spect Router 1 to sent out a Route request message? Is Router 1 receiving a NLME-ROUTE-DISCOVERY.request from a higher layer? Please be more specific as what do you mean with "In theory...."? 

When i said in theory, I means that with what i read from the zigbee specs. Well, like in the exp#1, i also check for the link status, and read the log coming out of router 1 to see that it did have router 2 and 3 in its link status. Also from the log, it pop up a no parent link failure message when i turn off router 2. That is the reason why I expect to see a route request to 0x0000. But i did not. So in this case, can you implicit when will the router will initiate a route request. Does the process of forming a mesh just slow or need to acquire any specific condition before it start. If it is slow, how can i speed this up, If there is something i could do to make this faster, please enlighten me. I am very happy to receive your detail advices.

Have a good day, 

Best,

Tu

[Marjeris Romero]

Hi,

Mateus Vesuvious said:

Yes i did check all of the link status of Router 1, 2, and Coordinator. Since i only place them in the vincinity of each other (about 3 meter) each of them already contain links to others and the link cost are ranging from 2-4 for both incoming and outgoing path cost.

Perhaos you can supply some sniffer logs from your experiments? I have run your example but I am only able to test with 2 routers and 1 coordinator at the moment.

Mateus Vesuvious said:

With each link status periodically send at 15s and routing table aging is 3, the entry of routing table in both of them should be erased by then and then from what i understand, router 1 should init a route request.

Can you point to the section on the specification that backs your assumptions?

What I have found is that if a device fails to receive nwkRouterAgeLimit link status messages from a router neighbor in a row, the old outgoing cost information is discarded and the neighbor entry is considered stale and may be reused if necessary to make room for a new neighbor.

Here you have a simple snippet, that you may plug into the zigbee_cli_cmd_zdo.c file. Afterwards - you can read the internal neighbor table through zdo neighbors command to check if the neigbour entry for router 1 is considered stale or not by the coordinator:

/**

 * @brief Prints all entries of the neighbor table.

 *

 * @code

 * zdo neighbors

 * @endcode

 *

 * Example:

 * @code

 * zdo neighbors

 * @endcode

 */

static void cmd_zb_neighbors(nrf_cli_t const * p_cli, size_t argc, char **argv)

{

    uint32_t i;

    zb_ieee_addr_t ieee_addr;

    zb_uint16_t addr;

 

    if ((argc > 1) || (nrf_cli_help_requested(p_cli)))

    {

        print_usage(p_cli, argv[0], "");

        return;

    }

 

    nrf_cli_fprintf(p_cli,

                    NRF_CLI_NORMAL,

                    "\r\n[idx] "

                    "ext_addr         "

                    "short_addr "

                    "type "

                    "sleepy "

                    "lqi "

                    "age "

                    "timeout "

                    "relationship\r\n");

 

    for (i = 0; i < gc_neighbor_table_size; i++)

    {

        if ((gc_neighbor[i].used == 0) ||

            (gc_neighbor[i].ext_neighbor != 0))

        {

            continue;

        }

 

        nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, "[%3u] ", i);

 

        zb_address_ieee_by_ref(ieee_addr, gc_neighbor[i].u.base.addr_ref);

        print_eui64(p_cli, ieee_addr);

 

        zb_address_short_by_ref(&addr, gc_neighbor[i].u.base.addr_ref);

        nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " 0x%04x    ", addr);

 

        switch (gc_neighbor[i].device_type) {

            case ZB_NWK_DEVICE_TYPE_COORDINATOR:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " ZC  ");

                break;

 

            case ZB_NWK_DEVICE_TYPE_ROUTER:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " ZR  ");

                break;

 

            case ZB_NWK_DEVICE_TYPE_ED:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " ZED ");

                break;

 

            default:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " ??? ");

                break;

        }

 

        if (gc_neighbor[i].rx_on_when_idle)

        {

            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " false ");

        }

        else

        {

            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " true  ");

        }

 

        nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " %03u", gc_neighbor[i].lqi);

 

        if (gc_neighbor[i].device_type != ZB_NWK_DEVICE_TYPE_ED)

        {

            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " %03u  ---   ", gc_neighbor[i].u.base.age);

        }

        else

        {

            zb_time_t exp_time = ZB_TIME_SUBTRACT(gc_neighbor[i].u.base.time_to_expire, ZB_TIMER_GET());

            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " --- %07u", ZB_TIME_BEACON_INTERVAL_TO_MSEC(exp_time) / 1000);

        }

 

        switch (gc_neighbor[i].relationship) {

            case 0x00:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " parent");

                break;

 

            case 0x01:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " child");

                break;

 

            case 0x02:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " sibling");

                break;

 

            case 0x03:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " none");

                break;

 

            case 0x04:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " previous child");

                break;

 

            case 0x05:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " unauthenticated child");

                break;

 

            default:

                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " unknown");

                break;

        }

 

        if ((gc_neighbor[i].device_type != ZB_NWK_DEVICE_TYPE_ED) &&

            (gc_neighbor[i].u.base.outgoing_cost == 0))

        {

            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " [STALE]\r\n");

        }

        else

        {

            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, "\r\n");

        }

    }

 

    print_done(p_cli, ZB_TRUE);

}

...

    NRF_CLI_CMD(neighbors, NULL, "lists all entries from the neighbor table", cmd_zb_neighbors),

    NRF_CLI_SUBCMD_SET_END

};

Example output for an aged-out router (ZC in this case):

> zdo neighbors
[idx] ext_addr         short_addr type sleepy lqi age timeout relationship
[  0] f4ce36aaaaaaaaaa 0x0000     ZC   false  255 003  ---    parent [STALE]

You can for example check if if the entry for router 1 in the coordinator is really really out of range from the coordinator by checking if the entry is stale.

Mateus Vesuvious said:

So please advise me how to get router 1 to do a route discovery when it is out of range. On which kind of condition that it has to meet before being able to do route discovery since it is pretty confusing to me until this point.

If you have a route from Router 1 <-> Router 2 <-> Coordinator where Router 1 and you turn OFF router 2 and coordinator is out of reach you will then see a route request from Router 1 after a couple of retries when sending a ZCL command with required ack.

Mateus Vesuvious said:

Also from the log, it pop up a no parent link failure message when i turn off router 2. That is the reason why I expect to see a route request to 0x0000. But i did not.

Did you see any retries from router 1 trying to send a message to the coordinator? Just one ZCL command that doesn't reach the destination is not enough to trigger searching a new path in the stack. It can be observed in frames through the sequence number field in Zigbee Network Layer Data. The sequence number should increment while the lower layers perform the retries. After about 10-12 ZCL commands you should see a route discovery request.

Best regards,

Marjeris

[tomchy]

Hi,

Similarly to the neighbor table, you can use the memory config feature to sneak into the routing table. There is another counter there for each entry and once the entry for a route in question times out, you shall see a Route Request packet.

Essentially - it works, but it is not as fast as you may expect it to be. The thing is that for the "development" installations you would like to see a very quick route discovery, but in real installations, where routers are not that mobile, very intense and quick route recalculation may put a significant load on the network (if one router dies, it is likely that the whole section of a building runs out of mains power).

Unfortunately I cannot provide you a code snippet for that as I am quite busy right now, but I hope that with those directions you can figure that out.

BR,

Tomchy

[Mateus Vesuvious]

Hi Tomchy,

Thank you very much for your support, I will definitely look in to that and try to create a cli cmd for routing table, but i have some question for you about zigbee.

So tell me if i am wrong but after receiving route reply, the node will add the new route to the coordinaotr into the routing table and the status for that entry is going to be VALIDATION_UNDERWAY and then being used as the new path. And I just want to know what will happen if it receive a link status directly from the coordinator, Will it update the neighbor table and started to send directly to the coordinator. So in order for the route resquest to be initiate, the router should be completly out of range with the coodinator in both direction right?  

And Some time when i Turn on the many to one request, after the router can establish a new path, there is also a problem that the node go back to send directly to the coordinator withou using the new path it create. It looks like it reset the routing table somehow. Can you guess why it is happen.

Thank you and have a good day, I have attach a sniffer with it so you can look for any problem 

Problem with link status.pcapng

Mateus

[Mateus Vesuvious]

Hi Majeris, 

Thank you for your reply, i have managed to make a route request happen. But I have some questions to ask, 

So if the router 1 create a new route to coordinator but after that it receive a link status from the coordinator. Does it going to send the next packet by the new route through another router or going directly to the cordinator. In my experiment, I have this problem that after a few time making a new route, the node keep sending data to the coordinator directly. So I will a packet sniffer to you so you can take a look at it.

And I also have an other similar question with many to one request, as far as i know, It will tell the routers to reserve an entry for sending the data to the collector (which is in my case is the coordinator, right?) and the router when it send somethinng will send a route record to it to send. But when I try it, routers did not send anything, instead, after a while of sending data through the new route, when MTORR hit, the router go back to use the direct path. Can you guess why it happen?

Thank you very much, hope to hear from you soon and have a nice day,

Here is the capture 3704.Problem with link status.pcapng

Best regards,

Mateus