[Zigbee-mesh] How to initiate the route discovery manually?

[Tu Hoang]

Hi everyone,

I am making a zigbee mesh with just coordinator and routers only. I intended to have the mesh to cover a very large areas with nodes that can be moved (not frequently). I am using SDK4.1.0, for coordiantor , i uploaded the CLI example inside and for the router  i used the exact same example of lilght bulb with the only change is that i exclude every parts relating to notification led or button.

Tell my if i am wrong but from what i learn, when the nodes send a message to another node, without having the address in the routing table it will initalise the route discovery by (1) sending route request or (2) after some time out when it did not received a MAC ACK from the node it try to send to. My expectation is that i will work like a charm since it is almost the same as the example but it did not. It has a really annoying that even with the router is very far from the coordinator, even with very low LQI and miss a lot of MAC ACKs, it still persistently try to send to the coordinator and not every try to broadcast route requeset. And for the first condition to start a route discovery, when the router send route requests, the coordinator can definitely hear it (i have a sniffer just right by coorfinator side).

So my question is that i want to start the route discovery manually to have better control over the mesh. is there any way i can do that. If not, is there any solution for the route discovery. 

Thank you in advances,

Best regards,

Tu

[Marte Myrvold]

Hi Tu,

I do not know of any functions to manually initiate route discovery that are visible to the application in our SDK. A lot of the NWK management and functions are internal parts of the ZBOSS stack, and thus not available to use. I have asked our developers if they know of any way to do this.

I also have some questions to help me better understand your set up. Was the router originally in range of the coordinator, had it in it's neighbor table, and were able to communicate with it, before you moved it out of range? What kind of messages are the router trying to send to the coordinator? 

And for the first condition to start a route discovery, when the router send route requests, the coordinator can definitely hear it

 Could you clarify this for me? Is the router sending route request commands to the coordinator, but the command is not received on the coordinator's side? From further up in your description it seemed like the problem is that the router does not try to initiate route discovery, even though the router is out of range and does not receive the packets, but now you are saying the router is sending a route request command and the coordinator is in range to receive this (but does not for some reason)?

Best regards,

Marte

[Tu Hoang]

Hi Marte,

Here are some more elaborate infomation about my set up

"Was the router originally in range of the coordinator, had it in it's neighbor table, and were able to communicate with it, before you moved it out of range? "   

-Yes, they can communicate with the coordinator before they get out of range. For the neigbor table, i investigate the link status message of each and every one of the node, all of them have link to every other nodes. but the incomming cost and outgoing cost  of some links are very bad like 6 or 7.

---

"What kind of messages are the router trying to send to the coordinator?"

-i try to send a report attribute message made with  the function zb_aps_send_user_payload(). I just made up some data (data send, cluster, atrribute, etc) to do it. 

---

"Is the router sending route request commands to the coordinator, but the command is not received on the coordinator's side? "  " Could you clarify this for me?"

- Sorry for confusing you with my bad writing. So as I said i'd learnt that there are 2 cases for the router to start a route discovery, so i try to test them one by one. So, so for the first case, when the link status of the router is not having the link to coordinator(addr 0x0000), it did send route request. that is what i mean by "And for the first condition to start a route discovery, when the router send route requests, the coordinator can definitely hear it"

But with the second case when i try to move the router out of range so that the message it sent does not have any MAC ACK return and the LQI very low (<20). I wait for about 2 mins and then i reset the device but notthing happen, no route request send.

---

So for some more information, i only used the board as pca10059, pca10100, pca10056 with Zigbee SDK 4.1.0 The code for coordinator i used is the zigbee cli and the code for the router and the sdk_config is attach below

/**
 * Copyright (c) 2018 - 2020, Nordic Semiconductor ASA
 *
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 *
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 *
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 *
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 *
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 */
/** @file
 *
 * @defgroup zigbee_examples_light_bulb main.c
 * @{
 * @ingroup zigbee_examples
 * @brief Dimmable light sample (HA profile)
 */

#include "sdk_config.h"
#include "zboss_api.h"
#include "zboss_api_addons.h"
#include "zb_mem_config_med.h"
#include "zb_ha_dimmable_light.h"
#include "zb_error_handler.h"
#include "zb_nrf52_internal.h"
#include "zigbee_helpers.h"
#include "nrf_timer.h"
#include "bsp.h"
#include "boards.h"
#include "app_pwm.h"
#include "app_timer.h"

#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"

#include "nrf_802154.h"


#undef ZB_NWK_LINK_STATUS_PERIOD
#define ZB_NWK_LINK_STATUS_PERIOD 0xa

#undef ZB_NWK_ROUTER_AGE_LIMIT 
#define ZB_NWK_ROUTER_AGE_LIMIT 1

#define MAX_CHILDREN                      10                                    /**< The maximum amount of connected devices. Setting this value to 0 disables association to this device.  */
#define IEEE_CHANNEL_MASK                 (1l << ZIGBEE_CHANNEL)                /**< Scan only one, predefined channel to find the coordinator. */
#define HA_DIMMABLE_LIGHT_ENDPOINT        10                                    /**< Device endpoint, used to receive light controlling commands. */
#define ERASE_PERSISTENT_CONFIG           ZB_FALSE                              /**< Do not erase NVRAM to save the network parameters after device reboot or power-off. */
#define BULB_PWM_NAME                     PWM1                                  /**< PWM instance used to drive dimmable light bulb. */
#define BULB_PWM_TIMER                    2                                     /**< Timer number used by PWM. */

/* Basic cluster attributes initial values. */
#define BULB_INIT_BASIC_APP_VERSION       01                                    /**< Version of the application software (1 byte). */
#define BULB_INIT_BASIC_STACK_VERSION     10                                    /**< Version of the implementation of the Zigbee stack (1 byte). */
#define BULB_INIT_BASIC_HW_VERSION        11                                    /**< Version of the hardware of the device (1 byte). */
#define BULB_INIT_BASIC_MANUF_NAME        "Nordic"                              /**< Manufacturer name (32 bytes). */
#define BULB_INIT_BASIC_MODEL_ID          "Dimable_Light_v0.1"                  /**< Model number assigned by manufacturer (32-bytes long string). */
#define BULB_INIT_BASIC_DATE_CODE         "20180416"                            /**< First 8 bytes specify the date of manufacturer of the device in ISO 8601 format (YYYYMMDD). The rest (8 bytes) are manufacturer specific. */
#define BULB_INIT_BASIC_POWER_SOURCE      ZB_ZCL_BASIC_POWER_SOURCE_DC_SOURCE   /**< Type of power sources available for the device. For possible values see section 3.2.2.2.8 of ZCL specification. */
#define BULB_INIT_BASIC_LOCATION_DESC     "Office desk"                         /**< Describes the physical location of the device (16 bytes). May be modified during commisioning process. */
#define BULB_INIT_BASIC_PH_ENV            ZB_ZCL_BASIC_ENV_UNSPECIFIED          /**< Describes the type of physical environment. For possible values see section 3.2.2.2.10 of ZCL specification. */

#ifdef  BOARD_PCA10059                                                          /**< If it is Dongle */
#define IDENTIFY_MODE_BSP_EVT             BSP_EVENT_KEY_0                       /**< Button event used to enter the Bulb into the Identify mode. */
#define ZIGBEE_NETWORK_STATE_LED          BSP_BOARD_LED_0                       /**< LED indicating that light switch successfully joind Zigbee network. */
#else
#define IDENTIFY_MODE_BSP_EVT             BSP_EVENT_KEY_3                       /**< Button event used to enter the Bulb into the Identify mode. */
#define ZIGBEE_NETWORK_STATE_LED          BSP_BOARD_LED_2                       /**< LED indicating that light switch successfully joind Zigbee network. */
#endif
#define BULB_LED                          BSP_BOARD_LED_3                       /**< LED immitaing dimmable light bulb. */

#if (APP_BULB_USE_WS2812_LED_CHAIN)
#define LED_CHAIN_DOUT_PIN                NRF_GPIO_PIN_MAP(1,7)                 /**< GPIO pin used as DOUT (to be connected to DIN pin of the first ws2812 led in chain) */
#endif

/* Declare endpoint for Dimmable Light device with scenes. */
#define ZB_HA_DECLARE_LIGHT_EP(ep_name, ep_id, cluster_list)                         \
ZB_ZCL_DECLARE_HA_DIMMABLE_LIGHT_SIMPLE_DESC(ep_name, ep_id,                       \
  ZB_HA_DIMMABLE_LIGHT_IN_CLUSTER_NUM, ZB_HA_DIMMABLE_LIGHT_OUT_CLUSTER_NUM);      \
ZBOSS_DEVICE_DECLARE_REPORTING_CTX(reporting_info## device_ctx_name,               \
 ZB_HA_DIMMABLE_LIGHT_REPORT_ATTR_COUNT);        \
ZBOSS_DEVICE_DECLARE_LEVEL_CONTROL_CTX(cvc_alarm_info## device_ctx_name,           \
 ZB_HA_DIMMABLE_LIGHT_CVC_ATTR_COUNT);       \
ZB_AF_DECLARE_ENDPOINT_DESC(ep_name, ep_id, ZB_AF_HA_PROFILE_ID,                   \
  0,     \
  NULL,                 \
  ZB_ZCL_ARRAY_SIZE(cluster_list, zb_zcl_cluster_desc_t),\
  cluster_list,                                          \
  (zb_af_simple_desc_1_1_t*)&simple_desc_##ep_name,      \
  ZB_HA_DIMMABLE_LIGHT_REPORT_ATTR_COUNT,                \
  reporting_info## device_ctx_name,                      \
  ZB_HA_DIMMABLE_LIGHT_CVC_ATTR_COUNT,                   \
  cvc_alarm_info## device_ctx_name)

#if !defined ZB_ROUTER_ROLE
#error Define ZB_ROUTER_ROLE to compile light bulb (Router) source code.
#endif

APP_TIMER_DEF(timer);

/* Main application customizable context. Stores all settings and static values. */
typedef struct
{
  zb_zcl_basic_attrs_ext_t         basic_attr;
  zb_zcl_identify_attrs_t          identify_attr;
  zb_zcl_scenes_attrs_t            scenes_attr;
  zb_zcl_groups_attrs_t            groups_attr;
  zb_zcl_on_off_attrs_ext_t        on_off_attr;
  zb_zcl_level_control_attrs_t     level_control_attr;
} bulb_device_ctx_t;

typedef struct
{
    zb_uint16_t     attr_id;  /**< Attribute ID specific to cluster */
    zb_uint8_t      attr_type; /**< Attribute type (see @ref zb_zcl_attr_type_t) */
    zb_uint8_t      *data_p;   /**< Attribute data */
    zb_uint16_t     *data_p_16;   /**< Attribute data */
    zb_uint32_t     *data_p_32;   /**< Attribute data */
} attr_info_t;

typedef struct {
    zb_uint8_t      src_endpoint;  /*!< Source endpoint */
    zb_uint8_t      dst_addr_mode; /*!< Destinition address mode*/
    zb_addr_u       dst_addr;       /*!< Destinition address */
    zb_uint8_t      dst_endpoint;  /*!< Destinition endpoint */
    zb_uint16_t     profile_id;   /*!< Profile ID for reporting */
    zb_uint16_t     cluster_id;   /*!< Cluster ID for reporting */
    attr_info_t     attr_info[10];
} reporting_info_t;

static bulb_device_ctx_t m_dev_ctx;

ZB_ZCL_DECLARE_IDENTIFY_ATTRIB_LIST(identify_attr_list, &m_dev_ctx.identify_attr.identify_time);


ZB_ZCL_DECLARE_GROUPS_ATTRIB_LIST(groups_attr_list, &m_dev_ctx.groups_attr.name_support);

ZB_ZCL_DECLARE_SCENES_ATTRIB_LIST(scenes_attr_list,
  &m_dev_ctx.scenes_attr.scene_count,
  &m_dev_ctx.scenes_attr.current_scene,
  &m_dev_ctx.scenes_attr.current_group,
  &m_dev_ctx.scenes_attr.scene_valid,
  &m_dev_ctx.scenes_attr.name_support);

ZB_ZCL_DECLARE_BASIC_ATTRIB_LIST_EXT(basic_attr_list,
 &m_dev_ctx.basic_attr.zcl_version,
 &m_dev_ctx.basic_attr.app_version,
 &m_dev_ctx.basic_attr.stack_version,
 &m_dev_ctx.basic_attr.hw_version,
 m_dev_ctx.basic_attr.mf_name,
 m_dev_ctx.basic_attr.model_id,
 m_dev_ctx.basic_attr.date_code,
 &m_dev_ctx.basic_attr.power_source,
 m_dev_ctx.basic_attr.location_id,
 &m_dev_ctx.basic_attr.ph_env,
 m_dev_ctx.basic_attr.sw_ver);

/* On/Off cluster attributes additions data */
ZB_ZCL_DECLARE_ON_OFF_ATTRIB_LIST_EXT(on_off_attr_list,
  &m_dev_ctx.on_off_attr.on_off,
  &m_dev_ctx.on_off_attr.global_scene_ctrl,
  &m_dev_ctx.on_off_attr.on_time,
  &m_dev_ctx.on_off_attr.off_wait_time);

ZB_ZCL_DECLARE_LEVEL_CONTROL_ATTRIB_LIST(level_control_attr_list,
 &m_dev_ctx.level_control_attr.current_level,
 &m_dev_ctx.level_control_attr.remaining_time);

ZB_HA_DECLARE_DIMMABLE_LIGHT_CLUSTER_LIST(dimmable_light_clusters,
  basic_attr_list,
  identify_attr_list,
  groups_attr_list,
  scenes_attr_list,
  on_off_attr_list,
  level_control_attr_list);

ZB_HA_DECLARE_LIGHT_EP(dimmable_light_ep,
 HA_DIMMABLE_LIGHT_ENDPOINT,
 dimmable_light_clusters);

ZB_HA_DECLARE_DIMMABLE_LIGHT_CTX(dimmable_light_ctx,
 dimmable_light_ep);


/**@brief Function for initializing the application timer.
 */
static void timer_init(void)
{
  uint32_t error_code = app_timer_init();
  APP_ERROR_CHECK(error_code);
}

/**@brief Function for initializing the nrf log module.
 */
static void log_init(void)
{
  ret_code_t err_code = NRF_LOG_INIT(NULL);
  APP_ERROR_CHECK(err_code);

  NRF_LOG_DEFAULT_BACKENDS_INIT();
}


void zboss_signal_handler(zb_bufid_t bufid)
{
    /* Update network status LED */
  zb_zdo_app_signal_hdr_t  * p_sg_p      = NULL;
  zb_zdo_app_signal_type_t   sig         = zb_get_app_signal(bufid, &p_sg_p);
    /* No application-specific behavior is required. Call default signal handler. */
  switch (sig)
  {
    default:
    ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));
    break;
  }

  if (bufid)
  {
    zb_buf_free(bufid);
  }
}


void _my_own_handler (void *p_context)
{
  // static zb_bufid_t last_bufid = 0;
  // if(last_bufid != 0) zb_buf_free(last_bufid);
  zb_bufid_t bufid;
  bufid = zb_buf_get_out_func();
  if(bufid == 0 || bufid == 28) {
    zb_buf_free(bufid);
    return;
  }
  zb_addr_u addr = {
    .addr_short = 0x0000,
  };
  
  NRF_LOG_INFO("bufid %d", bufid);
  zb_uint8_t payload[8] = {0x08, 0, 0x0a, 0x55, 0x00, 0x21, 0x03, 0x00};
  payload[1] = bufid;
  if(ZB_JOINED() == 1)
    zb_aps_send_user_payload(bufid, addr, 0x0104, 0x55, 1, 1, 2, ZB_FALSE, payload, sizeof(payload));
  app_timer_start(timer, APP_TIMER_TICKS(6000), NULL);
}
/**@brief Function for application main entry.
 */
int main(void)
{
  zb_ret_t       zb_err_code;
  zb_ieee_addr_t ieee_addr;

    /* Initialize timer, logging system and GPIOs. */
  timer_init();
  log_init();

    /* Initialize Zigbee stack. */
  ZB_INIT("led_bulb");
    /* Set Zigbee stack logging level and traffic dump subsystem. */
  ZB_SET_TRACE_LEVEL(ZIGBEE_TRACE_LEVEL);
  ZB_SET_TRACE_MASK(ZIGBEE_TRACE_MASK);
  ZB_SET_TRAF_DUMP_OFF();

    /* Set device address to the value read from FICR registers. */
  zb_osif_get_ieee_eui64(ieee_addr);
  zb_set_long_address(ieee_addr);

    /* Set static long IEEE address. */
  zb_set_network_router_role(IEEE_CHANNEL_MASK);
  //zb_set_max_children(MAX_CHILDREN);
    zb_set_max_children(3);
  zigbee_erase_persistent_storage(ZB_FALSE);
  zb_set_keepalive_timeout(ZB_MILLISECONDS_TO_BEACON_INTERVAL(3000));

    /* Initialize application context structure. */
  UNUSED_RETURN_VALUE(ZB_MEMSET(&m_dev_ctx, 0, sizeof(m_dev_ctx)));
    /* Register callback for handling ZCL commands. */
    //ZB_ZCL_REGISTER_DEVICE_CB(zcl_device_cb);

    /* Register dimmer switch device context (endpoints). */
  ZB_AF_REGISTER_DEVICE_CTX(&dimmable_light_ctx);
    /** Start Zigbee Stack. */
  zb_err_code = zboss_start_no_autostart();
  ZB_ERROR_CHECK(zb_err_code);
  app_timer_create(&timer, APP_TIMER_MODE_SINGLE_SHOT, _my_own_handler);
  app_timer_start(timer, APP_TIMER_TICKS(5000), NULL);


  while(1)
  {
    zboss_main_loop_iteration();
    UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());
  }
}


/**
 * @}
 */

8510.sdk_config.h

Thank you for your support

Best regards,

Tu

[Tu Hoang]

Hi Marte,

I want to give you some update on this problem. So, this time, follow your instruction, i decided to be more patient with the route discover and yes, after 12 no-ACKs packets, the route discovery did happen. Each packets i wait for 20s to send so it is about 4 minutes. Not bad at all, isn't it.

But this time there is another problem when the router receive route reply there will be some packets sending through that route until the next link status sent. I check for the link status, it is only having 1 link to the node that reply the route request. I guess that the link status somehow reset the routing table or temperary routing table.  I am still using the custom user message. So, I capture the result and send it to you.

In my mind i have some suspection that need your help. Is there something wrong with the route request/ route reply in my capture because when i read the command option in replay, all of the bit is false. Or is it because that there is some link status message of the coordinator reaching the router without the sniffer sniffing so the routing table was update.

Thank you and please reply soon, here is the packet sniffer capture you can apply the filter (zbee_nwk.src == 0xf392) || (zbee_nwk.dst == 0xf392) to check the data. Also, the network key is 660413b435c99c87763e8bc10c7abc49. route_request_after_12_no_ack_packet. .pcapng

Best regards,

Tu

[Marte Myrvold]

Hi,

I have started looking at your sniffer capture, but I have not been able to figure out the problem yet, so I will keep looking. Is the problem the additional NWK addr req messages, the APS Acks, and the additional Route Requests before the Link Status message from the router?

Tu Hoang said:

Or is it because that there is some link status message of the coordinator reaching the router without the sniffer sniffing so the routing table was update.

The Coordinator should not receive any Link Status messages from the router if they are not in range of each other without going through other routers. This message is a one-hop broadcast message, so it will only be broadcasted to neighbors with a radius of 1. It will not be forwarded to other devices in the network.

Best regards,

Marte

[Tu Hoang]

Hi Marte,

Sorry I just click the wrong button.

So to answer your question let me sum up the way route discovery happen in my case. After about 10-12 no ACK packets, the route request started to send. Then a nearby node reply and a new route is formed. But for about 20 secs usually after the link status message, the connection is broken. I have a wild guess that may be when the coordinator send the link status, some how the router receive it So it realise that the coordinator is in the neighbor and try to send packets.

I did retry the experiment but this time with the addition of Many To one Route Request sent at every minute. The problem here is that everytime the Many To One Route Request is sent, it is like the router delete the entry in routing table of 0x0000. So I guess there is something going on with the routing table that cause this behavior.

Thank you in advance,

PS: Can you still be noticed about the update of this ticket. I am very sorry of any inconvinient. Please tell me if i need to create a new thread to continue.

Tu

[Marte Myrvold]

Hi Tu,

I am still notified about updates on this, so you do not have to worry about that. If the questions are no longer relevant to the original topic in the ticket, we prefer that customers create new tickets, but this is still very relevant, so there is no need to create a new ticket. No inconvenience at all, I am just happy to help.

From what I can see in the sniffer it does not look like either the router or the coordinator believes the other to be a neighbor. I looked through some of the Link Status messages, both from the router and the coordinator, and none of them had the other in the link status list field. This field contains the list of all router neighbors, including the coordinator. The only neighbor the router had in the link list was 0x1b67, so it should not think the coordinator is a neighbor. The link list seems to be correct for 0x1b67 and the coordinator as well.

I am sorry, but I have not been able to see why the connection is broken. I have forwarded your sniffer capture to our developers to see if they can find anything.

Best regards,

Marte

[Tu Hoang]

Hi Marte,

Thank you very much for your kindness. I want to update something to you. So I found this answer that help me to see the neighbor table of a device

https://devzone.nordicsemi.com/f/nordic-q-a/70780/nrf52840-zigbee-router-s-neighbour-table-management-lqi-is-not-updating-even-if-the-end-device-is-disconnected.

So I did a similar jobs based on the code snippet for getting the routing table but i notice something very weird about the struct zb_nwk_routing_t, which should have all the field contained in the routing table. It does but there is mismatch with next_hop_addr_ref where in the zigbee spec (here) it is 2 octes but in the zboss_api_internal.h it is only maximum 8 bits. So is it because I have an old version of zigbee spec that the structure of routing table change? Or is it because of they are different parameter? Does this have something to do with some routing table malfunction? Also, a similar problem with status bit, in the document they use 3 bits but in the struct only 2 bits is used.

In addition, i have another question, so if I modified gc_neighbor_table, will it change directly the routing table that the stack used, and what gc stands for. And I also notice that when I print out the neighbor table of a node connected directly to the coordinator, all entry by default will have the destination address is 0x0000 along every others parameters in zb_nwk_routing_t is 0, Is it means that they are not currently using any route from the routing table? If the answer is yes then, when an new route is create, the device can know to use the new route by looking at status bit or used bit to choose the path the transmit data. 

Thank you and please inform me if there is something new.

Best regards,

Tu