WIFI FAST Roaming 及Ralink SDK中AutoRoaming的实现

 对于IPCamera以及smartphone这样的设备，在物联网应用中会涉及到在ESS的多个AP之间自动漫游的问题。这里以RT5350/MT7620 sdk为例，简要描述一下相关的规则。

 

一）

在RT5350 SDK的帮助文档中关于WIFI roaming可以通过如下的参数进行设置

FastRoaming

      Value：

          0：Disabled

          1：Enabled

 

RoamThreshold

Value

         0~255

 

AutoRoaming=Value

 

     Enable/Disable auto roaming mechanism

     Value：

          0：Disabled

          1：Enabled

          Default Setting is disabled。

 

但是从code分析来看，实际上控制WIFI roaming的参数目前只有“RoamThreshold”和“AutoRoaming”这两个。

MT7620SDK上的实现和这里大同小异。

 

具体分析一下代码：

首先在ralink的driver中，目前只有sta驱动才支持该功能，因此如果client模式是使用ap-client来实现的话，则无法支持该功能。

 

代码中通过struct _STA_ADMIN_CONFIG结构中的如下两个成员来保存Fast Roaming的相关配置信息            /* Fast Roaming */          BOOLEAN bAutoRoaming;       /* 0:disable auto roaming by RSSI, 1:enable auto roaming by RSSI */          CHAR dBmToRoam;                   /* the condition to roam when receiving Rssi less than this value. It's negative value. */     在code中通过RTMPSetProfileParameters函数中的如下代码段来从配置文件中获取这两个参数的配置：                       /* AutoRoaming by RSSI*/                     if (RTMPGetKeyParameter("AutoRoaming", tmpbuf, 32, pBuffer, TRUE))                     {                         if (simple_strtol(tmpbuf, 0, 10) == 0)                             pAd->StaCfg.bAutoRoaming = FALSE;                         else                             pAd->StaCfg.bAutoRoaming = TRUE;                           DBGPRINT(RT_DEBUG_TRACE, ("AutoRoaming=%d\n", pAd->StaCfg.bAutoRoaming));                     }                     /* RoamThreshold*/                     if (RTMPGetKeyParameter("RoamThreshold", tmpbuf, 32, pBuffer, TRUE))                     {                         long lInfo = simple_strtol(tmpbuf, 0, 10);                           if (lInfo > 90 || lInfo < 60)                             pAd->StaCfg.dBmToRoam = -70;                         else                                pAd->StaCfg.dBmToRoam = (CHAR)(-1)*lInfo;                           DBGPRINT(RT_DEBUG_TRACE, ("RoamThreshold=%d  dBm\n", pAd->StaCfg.dBmToRoam));                     }

 

从代码中不难看出，对于RoamThreshold，SDK将用户输入值进行转换，有效的RoamThreshold转换后为[-60dbm,-90dbm];

 

 

当用户使能了autoRoaming功能后，driver在如下代码段中定时检查所连接AP的信号强度是否太弱需要切换到其他AP上去。

 

 

在STAMlmePeriodicExec中，当WIFI模式为Infrastructure BSS时，dirver会定时检查是否需要进行roaming   if (pAd->StaCfg.bAutoRoaming)         {             BOOLEAN rv = FALSE;             CHAR    dBmToRoam = pAd->StaCfg.dBmToRoam;             CHAR    MaxRssi = RTMPMaxRssi(pAd,                                           pAd->StaCfg.RssiSample.LastRssi0,                                           pAd->StaCfg.RssiSample.LastRssi1,                                           pAd->StaCfg.RssiSample.LastRssi2);                                    if (pAd->StaCfg.bAutoConnectByBssid)                 pAd->StaCfg.bAutoConnectByBssid = FALSE;                         /* Scanning, ignore Roaming*/             if (!RTMP_TEST_FLAG(pAd, fRTMP_ADAPTER_BSS_SCAN_IN_PROGRESS) &&                 (pAd->Mlme.SyncMachine.CurrState == SYNC_IDLE) &&                 (MaxRssi <= dBmToRoam))             {                 DBGPRINT(RT_DEBUG_TRACE, ("Rssi=%d, dBmToRoam=%d\n", MaxRssi, (CHAR)dBmToRoam));                     /* Add auto seamless roaming*/                 if (rv == FALSE)                     rv = MlmeCheckForFastRoaming(pAd);                                 if (rv == FALSE)                 {                     if ((pAd->StaCfg.LastScanTime + 10 * OS_HZ) < pAd->Mlme.Now32)                     {                         DBGPRINT(RT_DEBUG_TRACE, ("MMCHK - Roaming, No eligable entry, try new scan!\n"));                         pAd->StaCfg.LastScanTime = pAd->Mlme.Now32;                         MlmeAutoScan(pAd);                     }                 }             }         }

 

pAd->StaCfg.RssiSample.LastRssi0，pAd->StaCfg.RssiSample.LastRssi1，pAd->StaCfg.RssiSample.LastRssi2分别对应几个接收天线的RSSI值，目前SDK支持1R,2R,3R三种情况，也就是支持1到3根接收天线；

从代码中可以看出，如果其中的最大值小于RoamThreshold门限时，就触发roaming操作。

 

 

typedef union _EEPROM_ANTENNA_STRUC {          struct {                    USHORT RssiIndicationMode:1;     /* RSSI indication mode */                    USHORT Rsv:1;                    USHORT BoardType:2;             /* 0: mini card; 1: USB pen */                    USHORT RfIcType:4;                           /* see E2PROM document */                    USHORT TxPath:4;                     /* 1: 1T, 2: 2T, 3: 3T */                    USHORT RxPath:4;                     /* 1: 1R, 2: 2R, 3: 3R */          } field;          USHORT word; } EEPROM_ANTENNA_STRUC, *PEEPROM_ANTENNA_STRUC;   从上面代码可知，RxPath的取值分别对应1R,2R,3R这几种接收天线的场景。   CHAR RTMPMaxRssi(     IN PRTMP_ADAPTER    pAd,     IN CHAR             Rssi0,     IN CHAR             Rssi1,     IN CHAR             Rssi2) {     CHAR    larger = -127;         if ((pAd->Antenna.field.RxPath == 1) && (Rssi0 != 0))     {         larger = Rssi0;     }       if ((pAd->Antenna.field.RxPath >= 2) && (Rssi1 != 0))     {         larger = max(Rssi0, Rssi1);     }         if ((pAd->Antenna.field.RxPath == 3) && (Rssi2 != 0))     {         larger = max(larger, Rssi2);     }       if (larger == -127)         larger = 0;       return larger; } Rssi0，Rssi1，Rssi2，分别对应3根接收天线的RSSI值；如果是1R的情况，则只有Rssi0有效。其他情况以此类推。

 

 

 二）802.11协议中关于Fast Roaming的实现方法，摘抄自如下的链接。更多信息，大家可以直接去下面的链接中获取。

http://dot11.info/index.php?title=Chapter_7_:_802.11_Fast_Secure_Roaming#802.11_Fast_Secure_Roaming

 

802.11 Fast Secure Roaming

• Client's decide when to roam.
• Access points don't tell them that
• RSSI(Received Signal Strength Indicator) thresholds tell the client when to roam
• Clients use the reassociation request frame

AP-to-AP Handoff

• As the client roams, the new AP and the old AP should communicate with each other across the distribution system
• The AP-to-AP communication is as follows
  • The New AP informs the old AP about the roam
  • The new AP requests buffered frames for the STA from the old AP
• The communication between these APs is proprietary
• Only after the original AP sends the buffered frames to the new AP, will the new AP respond to the STA with areassociation response.
• With this type of AP-to-AP communication in the case of autonomous APs, the back-end communications are proprietary. This is a problem
• IEEE created the 802.11F standard to address this and this became theInter-Access Point Protocol(IAPP).
  • However this was never ratified and is not a recommended practice.
• Another problem with autonomous AP-to-AP roaming handoffs was the latency involved with forwarding the buffered packets towards the APs.

RSNA

• 2 802.11 STAs establish procedures to authenticate and associate with each other as well as create dynamic encryption keys through the 4-way handshake process.
• A STA has to perform either 802.1X/PSK authenticate everytime it roams, but the PMK that we get from this authentication is going to be the key for the 4-way handshake between the AP and the client.
• This leads to a lot of delay~700ms.
• This called for a way to reduce this delay
• The 802.11i amendment calls for 2 fast secure roaming mechanims calledpreauthentication andPMK caching

PMKSA

• The Pairwise masker key security association(PMKSA) is a result of successful IEEE 802.1X authentication exchange between the supplicant and the AS, or from a PSK authentication.
• Once the 4-way handshake is done and the PTKs are generated, a PTKSA exists
• The RSN information can be identified through the RSNIE in the 802.11 management frames.
  • Probe response frame
  • Association request frame
  • Reassociation request frame
  • Beacon management frame.
• PMKID is the unique identifier for each PMKSA
• The PMKID can reference the following types of PMKSAs
  • A PMKSA derived from a PSK for the target AP
  • A cached PMKSA from an 802.1X/EAP authentication
  • A cached PMKSA that has been obtained through preauthentication with the target AP
• This PMKID is only found in association request frames and reassociation request frames that are sent from theclient STA to the AP.
• The client could have multiple PMKSAs , so there could be many PMKIDs in the RSNIE fields of the above mentioned frames.
• The components of a PMKSA are
  • PMK
  • PMKID
  • Authenticator MAC
  • Lifetime
    • If the lifetime is not otherwise specified, the PMK lifetime is infinite
  • AKMP
    • The authentication and key management protocol
  • Authorization parameters
• Standard statest that a STA can establish a new PMKSA during roaming, with one of four different methods
  • Complete 802.1X/EAP
  • PSK authentication
  • PMK caching
  • Preauthentication

PMK Caching

• Is a method used by APs and client stations to maintain PMKSAs for a period of time while a client station roams to a target AP and establishes a new PMKSA.
• When the client roams, the initial AP and the client maintain their old PMKSA, just in case the client decides to roam back to the original AP
• When the client station roamns back to the original AP< the client station will send a reassociation requets frame that lists multiple PMKIDs in the RSN information element.
• If the AP had cached the PMKID, it can skip the 802.1X process and head directly into the 4-way handshake?
• This causes the roaming delay to be <100ms
• This is sometimes called fast secure roam-back.
• In case the client roams to a new AP, pre-authentication needs to be configured for fast roaming to work

Preauthentication

• Establishes a new PMKSA with an AP prior to roaming to it
• Once the client has preauthenticated, a new PMK#2 is created and cached on both the client and the new target AP
• The AP can indicate to the client station that the AP is capable of preauthentication in theRSN Information element
• Preauthentication does not scale very well because every single client needs to preauthenticate with everysingle AP. This puts a huge load on the radius server
• Therefore , 802.11r was given the responsibility of defineing a more scalable,fast secure tranisition method.
• Most WLAN vendors did not wait for the 802.11-r amendment so they implemented a preview of the 802.11r mechanism calledOpportunistic key caching.

Opportunistic Key Caching

• Works in a controller based environment
• Enhancement of PMK Caching
• OKC doesn't mandate how a PMK arrives at the target AP
• OKC allows the client to use a single shared PMK shared among multiple APs.
• The steps that are followed are as follows:
  • The client authenticates with the first AP and creates the PMK and the PMKID, and they perform the 4-way handshake
  • The PMK#1 is cached on the WLAN Controller. The controloler sends this over to the target AP
  • The client calculates the PMKID#2 using the PMKID calculation formula and sends this over the target AP in the RSN IE.
  • The target AP looks at the client MAC and calculates the PMKID#2.
  • Because the PMKID#2 sent by the client is the same as the PMKID#2 calculated by the AP, 802.1X/EAP is not needed.The client uses the same old PMK
  • The target AP sends the reassociation response frame and the 4-way handshake now begins
• This situation becomes controller if it's an inter-controller roaming activity.

Fast BSS Transition(FT)

• Another name for the 802.11r amendment
• Main difference between OKC and FT is that FT defines the key hierarchy used when creating cached keys
• 802.11r operates within a mobility domain
• The first time the client associates it will perform full 802.1x Authentication. After that wherever the client roams within the mobility domain, it will only perform FT.
• 802.11r uses multiple layers of PMKs that are cached in different devices
  • Each device is assigned a key holder role to manage one or more of the multiple keys
  • For example : Refer Table 7.1 of the study guide
• 802.11r defines 3 levels of key-hierarchy
  • PMK R0
    • First level
    • Key derived from MSK
    • Cached on the WLC
  • PMK R1
    • Second level
    • Stored in the APs
  • PTK
    • Third level. used to encrypt/decrypt 802.11 data
• Also, the various levels of FT Keys are also derived and stored on the client station.
  • 802.1X/EAP creates MSK
  • MSK creates first level master key PMK-R0
    • This is cached on the supplicant.
  • The PMK-R1 and the PTK keys are generated and stored in the supplicant.
• MSK > PMK - R0 > PMK - R1 > PTK
• 802.11r does not define how the keys need to be exchanged between the controllers, APs and clients
• In the end-to-end scenario, WLAN vendors provides encryption at the controller level, the WLAN controller functions as both the pairwise master key R0 holder

(R0KH) and the pairwise master key R1 holder (R1KH).

Information Elements

• 802.11r adds 4 new IEs
  • Mobility Domain information element
    • is used to indicate the existence of a mobility domain as well as the method of fast BSS transition(over the air/over the DS)
  • Fast BSS transition IE
    • information needed to perform the FT authentication during FAST BSS Roam.

FT Initial domain association

• This is the first association in the mobility domain
• The client and the AP exchange MDIE and FTIE Information elements to indicate future use of FT procedures.
• This initial association is not that much different from a normal 802.1X supplicant authentication.
• After the first 2 messages in the 4-way handshake, 2 new methods are defined for a client to roam from 1 AP to another.

Over-the-air Fast BSS Transition

• Although our goal with FT is to not perform 802.1X everytime we roam, the initial 4 frames(Authentication, Association) is unavoidable.
• The FT process defi nes a more effi cient method that effectively combines the initial Open System authentication and reassociation frames with the 4 - Way Handshake frames. In other words, four less frames are needed when a client roams, thus speeding up the roaming process.
• Note that the authentication request/response frames and reassociation request/response frames carry an FT authentication algorithm (FTAA) along with nonces and other information needed to create the fi nal dynamic keys.
• This process is known as over-the-air fast BSS transition
• The PMK - R1 key is the seeding material for the over - the - air fast BSS transition process that creates the fi nal pairwise transient key (PTK).

Over-the-DS Fast BSS Transition

• It requires FT-Action frames to complete the PTK generation process
• The FT action frames are sent over the DS
• The FT action request frame is sent from the client to the AP, which then sends it to the target AP over the DS
• The target AP sends the FT action response to the client back through the DS and the original AP
• The client then sends the reassociation request to the target AP