• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 56 subscribers
  • Views 617 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2538: Rounting request delivery issue

Nalves
Intellectual 880 points
Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK

Hi everyone!

I'm working with a Z-Stack 1.2.1 to program a group of devices that communicates in mesh network one with each other. In this group of devices there is a strong possibility of changing locations. Which to continue to communicate without fail and without problems need to make changes in routing in unicast communications. 

As I already detected some problems and failures in the consistency in the triggering of the routing request when a communication fails, I decided to force a routing request, to the target device when at the application layer, in the event AF_DATA_CONFIRM_CMD, I receive a failure status in the delivery of the message.
Basically, what I do, is to call the function Status = NLME_RouteDiscoveryRequest (RREQdstAddr, 0x00, 0x0F), with the parameters RREQdstAddr, with the address of the device for who the communication failed, the options parameter at 0x00 (routing request in unicast) and with a radius at 15.

When this function is called, the source device broadcasts the message but does not get any router response from any device.

As an example of what I am reporting, I have created a network with 5 router devices and a coordinator. I create network and fixed devices in strategic locations. After the network stabilizes and all communication routes from the routers to the coordinator and vice versa are defined, move the device closer to the coordinator to the farthest place so that it is necessary to resort to jumps to communicate with the device. After a few minutes of waiting, in order for the new handset's neighboring devices to detect it, I forced an communication from coordinator to moved  router.
The following image shows a collection performed by the packet sniffer to demonstrate the message sequence exchanged. Between packet 6 and packet 13 we can see the direct communication attempts of the coordinator (0x0000) to communicate with the moved device (0x229C), making the two retries and in the end sending a routing request, from which we did not obtain any response of any device!

I can't understand why the neighborhood coordinator device, don't broadcast and response at the routing request , trying to help it to defines a new route for the moved device.

Please someone can help me?

Best regards

Nalves

  • 0
    TI__Guru**** 202096 points
    Hi Nalves,

    How many routing devices are within radio range of the ZC when this route request is sent and what neighbors are reported by its link status? Can you provide the full sniffer log for further evaluation? It appears that at least 0x4A60 re-broadcasts this route request but perhaps as a non-member multicast message, notice the broadcast radius of 0x01. I can't see the proper NWK payload which has the route request option for including the Destination IEEE address (0x20). Please re-evaluate your NLME_RouteDiscoveryRequest API command.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 880 points

    Hi Ryan.

    Thank you for your feedback.

    I repeat the tests that I described in first post but exchange the device that I move to another one. In this example I try to communicate wit another router with short address 0x5E7B.

    You can check the packet sniffer log from a sequence of communications of my network in the link below.

    Routing_Issue_to_0x5E7B.psd 

    This log have some packets acquisitions, of the devices that are in the radio range of ZC, because they are near one each other. 

    In the logs you can check packets with Broadcast Radius at 0x01, that are the link status of the devices that send the packets. The Broadcast Radius at 0x0C sended periodicaly by coordinator are the MTO Routing request.  the Broadcast radius  at 0x1E are the default radius of a data packet sended by devices.

    I can communicate with ZC by USB serial with an application to get some information from it. One of the information that I can get it are the Associated device list table, neighbor table, routing table and routing source table. With this tables I can know what are the devices that are in the range using the field "Age" of the associated device list or neighbor tables. You can check below that ZC can receive link status from 0x4A60, 0xBA36, 0x5A40 and 0xA598, because the age is less then 02. 

    the ZC have the next information on the Routing source table:

    The ZC Routing table is empty.

    After get this information from tables of ZC, I try to send a message to 0x5E7B, that is not on the range of ZC and don't have any entry on the ZC routing table. One important note, the destiny device (0x5E7B) are in the range of 0xC2B1, 0x5A40 and 0xA598, because in the neighbord tables of each this devices the Age of 0x5E7B is valid (less then 0x01).

    In the Packet sniffer log above, you can check after the packet nr 27 ZC try to send the message directlly to device (that don't have direct connection). Before that, in packet 26, the ZC sends an routing request, as expected, however it does not receive routers response from any neighboring device. Here is my doubt with this issue. Why is it that neighboring devices, which are within radio range and even have a connection with the destination device, do not respond to ZC routing requests?

    If you need more specific information, please feel free to ask me.

    Best regards.

    Nalves

  • 0 in reply to Nalves
    Intellectual 880 points

    Hi Ryan,

    I have new information to share about this issue.

    Considering the same network configuration and devices that I specified in my last post, I kept trying to communicate from the ZC to the ZR device (0x5E7B) and I still had the same response I presented in the packet sniffer log. However, I decided to reboot one of the ZRs closer from the ZC, the device (0x4A60). After doing a reboot to this device, I tried again to communicate with the device 0x5E7B through the ZC and finally, even if the 0x4A60 device is not within reach of the target device (0x5E7B), it has sent the RREQ sent by the ZC. As you can see on nex log packet number 4.

    RReq_Issue_2.psd


    This makes me think that over time the number of RREQ and RREP submissions are being limited, because at the end of some time or the number of attempts, I do not know yet when time passed or how many attempts were made, node 0x4A60 left to transmitter the RREQs sent by the coordinator.


    Is there any variable or parameter that sets a RREQ limit at the counter or time level?

    Best regards

    Nalves

  • 0 in reply to Nalves
    TI__Guru**** 202096 points
    Hi Nalves,

    I recommend reviewing the Z-Stack Overview: Routing and Network Configuration sections of the User's Guide:

    dev.ti.com/.../z-stack-overview.html
    dev.ti.com/.../network_configuration.html

    ROUTE_EXPIRY_TIME, MAX_RTG_ENTRIES, and MAX_RREQ_ENTRIES should be investigated and you may consider using MTO routing. Granted this documentation is for Z-Stack as part of the SimpleLink CC13x2/CC26x2 SDK and will vary from the Legacy Z-Stack 1.2.1.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 880 points

    Hi Ryan,

    Your feedback was relevant and was one of the first questions to ask to analyze this problem. 

    I believe that the parameters you refer are configured with correct values and do not interfere with the cause of the problem, for you can check the parameters have the next values:

    ROUTE_EXPIRY_TIME = 240

    MAX_RTG_ENTRIES = 40

    MAX_RREQ_ENTRIES = 8

    The MTO is still implemented in my networks. The concentrator is the network coordinator and send MTO routing request every 60 secounds (CONCENTRATOR_DISCOVERY_TIME = 60 only implemented on coordinator).

    All in all, in order for me to diagnose the problem and reach its cause, I would need some more promising support from Texas Instruments members who have access to the source code of the layer that manages communications routing. I would like to know what parameter, procedure, or conditions (available on the Z-Stack 1.2.0 and 1.2.1) that blocks the broadcast of routing request messages sent by a source device in an attempt to communicate with a target device that it can not see in its neighborhood, even if it is a neighboring device of the source device and with good signal quality.

    Best regards.

    Nalves

  • 0 in reply to Nalves
    Genius 3415 points

    Hi Nalves,

    Is your device still able to send Link Status and MTO Route Request and not able to send route discovery?

  • 0 in reply to Jose Maria Alvarez
    Intellectual 880 points

    Greetings,

    I hev found the causes of my problem.

    I will share here the solution for everyone that have similar issues can check this out.

    Giving a brief description of my problem, the networks I created, after some time of operation whenever a device intended to communicate with another device (ZC or ZR) and doesn't have route to it or if the route had already expired, it would send a routing request. In my case, the route request (RREQ) that was broadcast from the source device to the target device was not forwarded by neighboring devices, which would make it impossible to resume communications with that target device.

    I've been looking at neighbors table, routing tables, and routing source tables to try to figure out why neighboring devices do not broadcast the RREQ of the device that spawned it. The explanation is simple, by checking the "options" field of the rtgTable of the neighboring device with input to the target device, it had the value 0x09 or 0x0D or 0x17, which indicates that the routings for these devices were as MTO. In this scenario, if the destination node is saved as MTO, any unicast RREQ that the neighboring or intermediate device receives is completely ignored.

    The reason the "options" field was saved with the valid MTO bit mask was due to a side-effect that I applied to the stack application, which forced a route request whenever a communication failed for the target device. to send a route request, it used the NLME_RouteDiscoveryRequest (uint16 DstAddress, byte options, uint8 radius) function; with the options field with the value 0x01, which induced me in error, the value options, to send a RREQ in unicast must have the 0 and not 1.

    The error had been inserted by me, for lack of knowledge of the routing operation.
    Even so, I thank you for your help.

    Best regards

    Nalves