CC3235MODSF: Soft Roaming is still not working how it should

Part Number: CC3235MODSF
Other Parts Discussed in Thread: CC3235SF

Hi,

I am creating this new post, as the previous one is locked. I have recently tested soft roaming with the latest SDK release 5.10.

However, it seems like the NWP is not managing soft roaming feature correctly. Link Quality event is triggered but the NWP doesn't manage disconnect/connect sequence. The device only disconnects when the AP is very far away. Only then new connection is established with the new AP that is closer.

Please let me know what is the plan to solve this problem. Thanks.

Best,

Ogulcan

  • Hi Ogulcan,

    Thank you for posting. I can give this a try on my end with the latest release to see if I can reproduce the issue.

    I did recently check with older versions to verify that certain fixes from the past were working. As a sanity check, can you test with sp_4.8.0.8 from SDK v4.30 in your setup and let me know if you can see the device transition without being very far away and losing the connection first?

    Thank you,

    Ben M

  • Hi Ogulcan,

    I just tested soft roaming on a CC3235SF in my environment using sp_4.10.0.1 (from SDK 5.10) and I see it working as expected. I used the network_terminal application to setup a device with two saved profiles and then enabled the soft roaming feature with RSSI trigger of -65 (I also tested with -70, but I have limited space where I'm at). When I move between the two APs in my environment, the device generates the trigger event and will connect to the new AP.

    Please make sure the device is able to pick up your APs during a normal scan. Please also note that for APs supporting only 11bg connection, it may take up to 3 triggers (scan cycles) to pick up the new AP.

    Best Regards,

    Ben M

  • Hi Ben,

    Thank you very much for the fast response. However, soft roaming is also not working for me with sp_4.8.0.8 from SDK v4.30.

    Maybe there is a difference on how we interpret soft roaming feature. Soft roaming is required in locations with large spaces such as factories. Inside those locations the WiFi profiles that the device needs to switch between are the same. Therefore, I'm trying to use soft roaming with only one saved profile.

    I would like to give all details of my settings so that you can reproduce the issue.

    -Here is my scan policy and the interval value is 10:

    /* Set scan policy. */
    slRet = sl_WlanPolicySet(SL_WLAN_POLICY_SCAN, \
                             SL_WLAN_SCAN_POLICY(1,1), \
                             (_u8 *)&intervalInSeconds, \
                             sizeof(intervalInSeconds));
                             

    -Here is how I enable soft roaming:

    SlWlanRegisterLinkQualityEvents_t RegisterLinkQuality;
    memset(&RegisterLinkQuality, 0, sizeof(RegisterLinkQuality));
    RegisterLinkQuality.TriggerId = 1;
    RegisterLinkQuality.Enable = 1;
    RegisterLinkQuality.Metric = SL_WLAN_METRIC_EVENT_RSSI_BEACON;
    RegisterLinkQuality.Direction = SL_WLAN_RSSI_EVENT_DIR_LOW;
    RegisterLinkQuality.Threshold = -75;
    RegisterLinkQuality.Hysteresis = 3;
    RegisterLinkQuality.Type = SL_WLAN_RX_QUALITY_EVENT_LEVEL;
    RegisterLinkQuality.Pacing = 5000;
    sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, SL_WLAN_GENERAL_PARAM_REGISTER_LINK_QUALITY_EVENT, \
               sizeof(SlWlanRegisterLinkQualityEvents_t), (_u8 *)&RegisterLinkQuality);
    
    

    -Here is how I add the only WiFi profile that I want to connect to:

    sl_WlanProfileAdd(SSID, strlen(SSID), 0, &secParams, p_ext, 6, 0);
    

    -Lastly, here is how I enable auto connection:

    sl_WlanPolicySet(SL_WLAN_POLICY_CONNECTION, \
                     SL_WLAN_CONNECTION_POLICY(1, 0, 0, 1), \
                     NULL, 0);
                     
    

    After setting the device like this, I can see the link trigger events but the switching doesn't happen until disconnection due to distance.

    Please let me know if you can reproduce the issue. In the meantime, I will implement a scanning after link trigger event to see if the device can see new AP which is closer.

    Best,

    Ogulcan

  • Hi Ogulcan,

    Thank you for clarifying your setup and what you are trying to achieve. The soft-roaming feature is designed to enable the device to transition between two different networks, each stored in a different saved profile. 

    I believe what you are looking for is better suited to our Triggered Roaming (or Network Assisted Roaming) feature. See section 4.3.9 of our Network Processor Programmer's Guide. It is designed to enable the device to roam from one AP to another AP that is either included in a neighbor list sent by the currently serving AP or which has the same SSID as the currently serving AP (i.e. multiple profiles are not needed).

    In your case while using soft-roaming, the device should be scanning based on the RSSI trigger. However, since it sees that it is already connected to an AP that matches the stored profile it will not roam.

    Best Regards,

    Ben M

  • Hi Ben,

    It looks like Triggered Roaming is something that was introduced in October 2020 as it is not present on the document version I had(swru455l).

    First of all, the example on the documentation is wrong as sl_WlanSet function requires the address of roamingTriggeringEnable variable. So it should be "(_u8 *)&roamingTriggeringEnable".

    So just to be clear, here are my steps:

    SlWlanRegisterLinkQualityEvents_t RegisterLinkQuality;
    /* Clear variable. */
    memset(&RegisterLinkQuality, 0, sizeof(RegisterLinkQuality));
    /* trigger Id 1 is used for soft roaming trigger id 0 is for the host app usage.*/
    RegisterLinkQuality.TriggerId = 1;
    /* Disable soft roaming. */
    sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, SL_WLAN_GENERAL_PARAM_REGISTER_LINK_QUALITY_EVENT, \
               sizeof(SlWlanRegisterLinkQualityEvents_t), (_u8 *)&RegisterLinkQuality);
    RegisterLinkQuality.TriggerId = 0;
    sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, SL_WLAN_GENERAL_PARAM_REGISTER_LINK_QUALITY_EVENT, \
               sizeof(SlWlanRegisterLinkQualityEvents_t), (_u8 *)&RegisterLinkQuality);
    
    SlWlanNetworkAssistedRoaming_t roamingTriggeringEnable;
    roamingTriggeringEnable.Enable = 1;
    roamingTriggeringEnable.rssiThreshold = -65;
    return sl_WlanSet(SL_WLAN_STA_NETWORK_ASSISTED_ROAMING, SL_WLAN_ROAMING_TRIGGERING_ENABLE, \
                      sizeof(SlWlanNetworkAssistedRoaming_t ), (_u8 *)&roamingTriggeringEnable);
                      
                      

    After these steps, I receive Link Trigger callbacks with id number 1 (soft roaming), even though it has been disabled.

    Also once I am closer to the second AP with the same SSID, I receive SL_WLAN_EVENT_DISCONNECT event with SL_WLAN_DISCONNECT_USER_INITIATED as the reason, even though I have not called sl_WlanDisconnect. In the end, the device only reconnects to the AP which is closer, after if I call sl_Stop and sl_Start.

    Please let me know if this is how it is supposed to work or not?

    Best,

    Ogulcan

  • Hi Ogulcan,

    Yes, the feature was introduced late last year via a servicepack update to address the need for a network assisted roaming in certain commercial environments. It must be used with sp_4.8.0.8 or later.
    Thanks for the note on the code example. I'll file a report and make sure we get that corrected.

    Please give me a couple days to review your steps and verify.

    Best Regards,

    Ben M

  • Hi Ben,

    I wanted to ask if you were able to take a look at this.

    Best,

    Ogulcan

  • Hi Ogulcan,

    Sorry for the delay. I was out of the office the past week and have not been able to complete additional tests on this.

    I will be able to work on this again this week and will update you on Thursday at the latest.

    Best Regards,
    Ben M

  • Hi Ogulcan,

    Ok, I was able to test this in my environment and I believe I am seeing a similar result to you. I see the trigger event for the background scan begin and I see the device generate a disconnect event when I bring it close to the second AP (one that it is not currently connected to). I'm not getting the reconnect on my end with the latest firmware.

    I'll continue to debug this further to see what is happening.

    Best Regards,

    Ben M

  • Hi Ben,

    Thank you for your answer. Please let me know if you can find a fast solution for this. In the meantime, we have developed the application to force a disconnect if there is an SSID with higher RSSI and different BSSID. Only then the device reconnects to the second AP which is closer. However, this is not optimal as it draws too much current with each scan operation.

    Best,

    Ogulcan

  • Hi Ogulcan,

    I'm glad you have a temporary workaround. I'll be debugging this more today and plan to update you again tomorrow.

    Best,

    Ben M

  • Hi Ogulcan,

    Quick update, my tests didn't go as expected yesterday due to a setup issue. The devices used as the APs were incorrectly configured (somehow with the same MAC addresses) and that caused problems with my results. I'll be testing more tomorrow.

    Best Regards,

    Ben M

  • Hi Ben,

    I am kindly reminding the issue to get some update.

    Best,

    Ogulcan

  • Hi Ogulcan,

    Apologies for the delay. I don't have any specific conclusions yet. I will need more time to investigate and will make sure to update you again by the end of the week.

    Best Regards,

    Ben M

  • Hi Ogulcan,

    I was able to test this a bit more and get some pretty good logs from the network processor during the test. The disconnect event is being generated by the device as expected. The device knows which SSID it is looking for from the stored profile and the device is running a scan to find the new AP. I see multiple results show up in the scan with the same SSID and different RSSI, so the device appears to see the probe responses of the two APs. For some reason though the device doesn't think the scan results match the profile and fails to reconnect in my test.

    Could you run your scenario while collecting NWP logs and send them to me so I can make sure we are seeing the same thing?

    Collecting NWP logs from the device is described in chapter 20 of the programmer's guide if you haven't done it before: https://www.ti.com/lit/swru455

    Thanks,

    Ben M

  • Hi Ben,

    Thank you very much for the response. As your test results show, the triggered roaming does not seem to be working.

    In order to collect NWP logs, I need to run the scenario on the launchpad. This might take some time but I'll send them as soon as I can.

    In the meantime, what is the plan to fix this problem?

    Best,

    Ogulcan

  • Hi Ogulcan,

    I will need to review the scenario with our development team a bit more and debug further in order to understand root cause. In general, the plan would be to determine the root cause and then we would prioritize it for integration in a future SDK release. At this point, the next possible release to intersect would be our 3rd quarter release. Development for the 2nd quarter release is closed and it is in final testing. 

    My goal will be to make sure we can understand the issue and have a plan to fix it for that 3rd quarter release.

    Best Regards,

    Ben M