• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 43 subscribers
  • Views 3190 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

WL1271 Slow Roaming Times

Ryan Thome
Prodigy 80 points
Other Parts Discussed in Thread: WL1271

Current testing shows the 1271 is staying connected to a low signal AP too long prior to roaming to a better signal AP.  Additionally, roaming times are 10-25 seconds for slow roam conditions (1dB/1sec change) and 3-6 seconds for fast roam conditions (5dB/1sec).  What roaming parameters would be best to manipulate to reduce roaming times and/or make quicker roaming decisions?  The goal would be roaming times ~1 second or less.  Is there a roaming application note that we can use to best tailor the roaming algorithm for our packet traffic patterns (50kbps bandwidth, 4 packets / 1 sec)?

  • 0
    Expert 2800 points

    Hi,

    The command line interface (CLI) can be used to configure the TI WLAN driver and to perform functional (roaming, etc) configurations in the driver.

    The following link will help you out in understanding roaming menu and configuring roaming feature.

    http://processors.wiki.ti.com/index.php/OMAP35x_Wireless_Connectivity_WL1271_Command_Line_Interface_(CLI)_User%27s_Guide#roaminG_.5Bg.5D_Menu

    After the CLI is running, the Root menu appears. Type the following letters to retrieve the currently configured roaming settings.

    / g g

    The default settings are as below:

    ===========================================================================================

    \> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, poWer/, eVents/, Bt coexsistance/, Report/, dEt
    / g g
    \> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, poWer/, eVents/, Bt coexsistance/, Report/, dEt
    .../roaminG> Enable, Disable, Low pass filter, Quality threshold, Get , Thresholds/
    Roaming is: Disabled
     
     lowPassFilterRoamingAttempt = 30 sec,
     apQualityThreshold = -70
     Roaming Triggers' thresholds are:
     dataRetryThreshold = 20,
     lowQualityForBackgroungScanCondition = -80,
     lowRssiThreshold = -80,
     lowSnrThreshold = 0,
     normalQualityForBackgroungScanCondition = -80,
     numExpectedTbttForBSSLoss = 10,
     txRateThreshold = 2

    ===========================================================================================

     

    Thanks,

    Sinoj

     

  • 0 in reply to sinoj issac
    Prodigy 80 points

    Hi Sinoj,

    The roam times reported above are with Roaming already enabled from the CLI.  While using the default roaming settings the wireless client seemed to be too "sticky", i.e. it would not disconnect from its current AP and roam until it had almost completely lost a signal from the current AP.

    A few quick tests with changing from the default roaming parameters (generally decreasing the thresholds to try and initiate a roam event earlier) did not yield results that were significantly different.

     

    -Ryan

     

  • 0 in reply to Ryan Thome
    TI__Prodigy 190 points

    Hi all

    In order to preform Roaming please type the following comands at the CLI:

    / g g

    / a p s

    It will enable the roaming and store the default scan policy, in order to view roaming candidates

    please type at the cli:

    / a p t

    Also please look at the below link for better understanding of the Roaming process

    http://processors.wiki.ti.com/index.php/OMAP35x_Wireless_Connectivity_FAQ#How_to_enable_roaming.3F

  • 0 in reply to Gil Moskovitch
    TI__Prodigy 190 points

     

    Hi all

    Sorry for my typo In order to preform Roaming please type the following comands at the CLI:

    / g e

    / a p s

    It will enable the roaming and store the default scan policy, in order to view roaming candidates

    please type at the cli:

    / a p t

  • 0 in reply to Gil Moskovitch
    Prodigy 170 points

    I am taking over this case from Ryan Thome here. The behavior we are observing is with roaming enabled, and a signal attenuator performing a roam test where one AP is attenuated at 1 dB/sec and another is de-attenuated at 1 dB/sec.

    The expected result is to see the client hopping to the new access point as the signals get cross-faded. However, what we see is that the client hangs on to the attenuating access point until the connection completely drops, THEN associates with the stronger access point. It seems as though roaming functionality is broken.

    Thanks,
    - Chris Hammond 

  • 0 in reply to Chris Hammond
    TI__Prodigy 190 points

    Hi Chris

    Sorry for late respond here are my comments:

    The answer for this issue is little bit complicated .The device driver layer holds the entire configuration for the roaming parameters .In the firmware layer in terms of RSSI level the last incoming packet (management packets like beacons or data packets have different weights) has ~10% from the averaging measured RSSI, upon configured threshold s at the driver layer the roaming can occurs. For example if device under test doesn’t cross the low RSSI threshold or another roaming threshold s then it will not roam  to different AP even if the other AP  signals will be received much stronger . The following 3 triggers are the most common triggers to test with

    dataRetryThreshold = 20 (List the numbers of retries  of data packets that if exceed it ,then the device under test will trig the roaming to another AP)

     numExpectedTbttForBSSLoss = 10 (List the number of continues missed beacon that will trig the roaming to another AP)

      lowRssiThreshold = -80 (List the lower RSSI value of beacons  that will trig the roaming to another AP)

    In general we recommend the following steps

    1)      Try to tune-up the roaming triggers in order to reach roaming thresholds much faster.

    For example set lowRssiThreshold = -60

    2)      Do you have any air trace log of the problem? If yes can you please send it to us?

    3)      What is the driver / firmware version currently you are using (/ u from the cli menu)

    Regards

    Gil

  • 0 in reply to Gil Moskovitch
    Prodigy 170 points

    I have been playing with the various parameters, and have some more details for you, and another question.

    I lowered the rssi threshold to -50, and the behavior does not change (there is complete dropout, then scanning and reassociation with new AP), but the driver is now spitting out these messages continuously whenever the rssi is below -50:

    RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'tiwlan0' added
Wireless event: cmd=0x8c02 len=164

    It seems like the driver recognizes that the trigger has been satisfied, but is unable to actually complete the roaming, for some unknown reason. These are the settings I have to reproduce this behavior:

    Roaming is: Enabled
 lowPassFilterRoamingAttempt = 5 sec,
 apQualityThreshold = -65
 Roaming Triggers' thresholds are:
 dataRetryThreshold = 20,
 lowQualityForBackgroungScanCondition = -60,
 lowRssiThreshold = -50,
 lowSnrThreshold = 20,
 normalQualityForBackgroungScanCondition = -60,
 numExpectedTbttForBSSLoss = 5,
 txRateThreshold = 2

    I also have another question: does roaming work better when the two access points are on the same channel, or different ones? Is there a difference in how regular scan vs. background scan works?

    Thanks,
    - Chris Hammond 

  • 0 in reply to Chris Hammond
    TI__Prodigy 275 points

    Hi Chris,

    For the further investigation I to align with you about the following items:

    1. What is the platform you are working with ?

    2. What is the SW package you are using as base?

    3. Please specify which WLAN driver version and Firmware version you are using.

    3. Does the wlan run on top of plain Linux or Android?

    4. Did you modify TI SW package? If so, which part?

     

    Thanks,

    Yuri

     

  • 0 in reply to Yury Shvatsburd
    Prodigy 170 points

    Hi Yuri,

    The platform I am working with is the OMAP35x EVM board, with WL1271 daughter card, running plain Linux.

    The software version we are using is the "WL1271 SDK Demo Package based on SDK v2.01.03.11-WL6.1.3.1" without modifications.

    Driver version: WiLink_Driver_6.1.3.01.5_NOCCX 
    Firmware version: Rev 6.1.3.01.5

     

    I have made some more progress diagnosing the problem since my last post. When the module is under ideal conditions, and I trigger a roam manually, I can get it to handoff in under 100ms. However, when the signal strength gets low and it is spewing retransmissions, it seems like the driver does not perform background scans at the 10 second interval. It will stay connected to the bad AP until it finally gets off a scan (sometimes 30 seconds after the last packet went through), and then it will immediately roam.

    I can't tell why it is doing this, but it seems like the driver is just too busy retransmitting constantly to remember to background scan and roam. I have even forced the module into constant discovery mode, but this does not help.

    Thanks,
    - Chris Hammond 

  • 0 in reply to Chris Hammond
    TI__Prodigy 275 points

    Hi Chris,

    Thanks for the info.

    Can you please provide you scan policy configuration and sniffer capture from roaming session?

    This information would be helpful in order to verify the STA scan & roaming behaviour.

     

    Best Regards,

    Yuri

     

  • 0 in reply to Yury Shvatsburd
    Prodigy 170 points

    Here are the roaming and scan configurations:

     

    Roaming is: Enabled
 lowPassFilterRoamingAttempt = 2 sec,
 apQualityThreshold = -70
 Roaming Triggers' thresholds are:
 dataRetryThreshold = 20,
 lowQualityForBackgroungScanCondition = -51,
 lowRssiThreshold = -55,
 lowSnrThreshold = 0,
 normalQualityForBackgroungScanCondition = -50,
 numExpectedTbttForBSSLoss = 5,
 txRateThreshold = 2


Scan Policy:
Normal scan interval: 10000, deteriorating scan interval: 5000
Max track attempt failures: 3
BSS list size: 16, number of BSSes to start discovery: 16
Number of configured bands: 1

Band: 2.4 GHz
RSSI Threshold: -80 dBm
Number of channels for each discovery interval: 3

Tracking Method:
Scan type: Active Normal Scan
Max channel dwell time: 30000, Min channel dwell time: 15000
ET condition: ET disabled  , ET number of frames: 0
Probe request number: 3, probe request rate: Auto    , TX level: 205

Discovery Method:
Scan type: Active Normal Scan
Max channel dwell time: 30000, Min channel dwell time: 15000
ET condition: ET disabled  , ET number of frames: 0
Probe request number: 3, probe request rate: Auto    , TX level: 205

Immediate Scan Method:
Scan type: Active Normal Scan
Max channel dwell time: 30000, Min channel dwell time: 15000
ET condition: ET disabled  , ET number of frames: 0
Probe request number: 3, probe request rate: Auto    , TX level: 205

Channel list:   1   6  11

     

    Here is an OmniPeek capture from a roaming test wherein 3 roams were performed, taking 5.54, 12.36, and 0.03 seconds respectively:

    https://spreadsheets.google.com/pub?key=0AlBWdP4-1dfbdG5aUk45bVlfWXRYUlQtdWE0VkJnSGc&hl=en&output=html

    At 0:32.68, the module stops performing background scans until 1:04.72 when it roams into channel 6. Then, as the attenuation is increased on channel 6, it stops performing background scans at 1:20.06 and gets flooded with retransmissions until 1:51.47 when it finally scans and roams back to channel 1.

    At 2:45.35 it uneventfully roams back to channel 6. 

    Thanks,
    - Chris Hammond