1.概述

1.1.為什麼需要跳頻

WLAN和基於IEEE 802.11規範的無線裝置與藍芽一樣，在無需許可的2.4 GHz ISM（工業，科學和醫療）無線電頻段中執行。為了改善在該環境中的相同規範裝置的通訊效能，SIG引入了自適應跳頻的技術AFH（advance frequence hopping），以減少這種干擾的影響。該跳頻技術可以通過各種方法實現，每種方法都有其固有的優點和缺點。

在AFH解決方案出現之前開發的藍芽產品採用另一種形式的跳頻，其跳頻在設計上是隨機的。 這些第一代藍芽裝置使用2.4 GHz頻段中的83.5個可用頻道中的79個，以隨機方式跳過這些頻道，速率為每秒1600次。 一旦將另一個無線裝置引入環境中，這種型別的跳躍就會導致偶爾的衝突。 沒有AFH藍芽缺乏避免這些衝突的能力，從而適應其環境。 結果如下圖所示，顯示了藍芽（BT）和無線LAN（WLAN）都在執行的環境。

與上述相反，自適應跳頻AFH允許藍芽通過識別固定的干擾源並將其從可用通道列表中排除來適應環境。 這種重新對映過程還涉及減少藍芽使用的通道數量。 藍芽規範要求至少20個通道的最小集合。 下圖顯示了與上圖相同的環境，但現在使用了自適應跳頻後的藍芽通訊通道。

2.Classic 跳頻

經典藍芽跳頻框架如下所示：有一個Channel map，即為跳頻表，一個跳頻階躍；根據跳頻表和跳頻階躍和當前通訊頻點，即可計算出主從機下一次資料通訊的頻點。

藍芽跳頻表演算法各家的演算法略有不同，但都需要解決兩個問題

1. 通道評估：

SIG規範沒有規定如何識別不良通道，目前有兩種主要的方法用於執行具有自適應跳頻的通道評估：RSSI（接收訊號強度指示）和PER（分組錯誤率）。
RSSI和PER都是眾所周知的用於確定哪些通道可能已被佔用的技術。然而，當涉及監聽當前通道狀態時，這兩種方法不同。 PER用於反覆測試和重新評估不良通道的方法不如RSSI準確，並且可能導致臨時挫折。然而，在使用RSSI時還存在許多其他問題，例如RSSI消耗的功率大於PER。當缺少可用的時隙時，RSSI還可以要求從其他功能獲取頻寬。

2. 同一通道資料通訊：

藍芽AFH規定，主裝置和從裝置都通過同一頻道進行通訊。 這樣做是為了避免主裝置在“好”通道上傳送而從裝置響應“壞”通道（反之亦然）的情況，因為這將導致多次重傳（其他協議AFH的資料收發是在不同通道，會產生髮資料正常，接收通道干擾導致無法響應主產生的多次重傳）。由於主裝置和從裝置在相同頻率上傳送接收資料，因此通道跳頻率降低50％至每秒800次。 雖然這可以使藍芽裝置對來自其他藍芽裝置的干擾更敏感，但迄今為止所帶來的好處超過了這個小缺點。 

3.AFH

3.1.AFH 的原理

AFH 技術是對原始藍芽跳頻序列的一種改進, 它允許藍芽裝置縮減跳頻點的數量, 其基本原理是將通道分成unknown, bad or good三類, 從而避免使用bad 通道, 減少受干擾的程度。當藍芽微微網進入AFH 狀態後, 其跳頻序列可使用的跳頻點N 的數量是動態變化的, 但規定必須有一個最小值Nmin , 即Nmin≤N≤79。 Bluetooth 協議中將Nmin定義為20。 AFH 只用於連線狀態, 而不會改變尋呼、查詢等狀態時的跳頻序列。自適應跳頻選擇機制的實現是基於原79 跳系統的頻率選擇核心, 在其基礎上增加了AFH_mode和AFH _channel _map 兩個引數( 圖2.12) 。 AFH_mode 指出當前選頻核心是否可以使用自適應跳頻序列; AFH_channel_map 中指明哪些通道是可用的, 哪些通道是不可用的。首先, 原選頻核心生成一個通道, 如果這個通道是AFH_channel _map 中定義的可用通道, 則不作任何調整, 直接作為跳頻序列的輸出; 如果此通道包含在不可用通道中, 則通過重定位函式將其對映成一個可用的通道。這種對映關係是一一對應的 , 就是說, 如果給定了藍芽地址、時鐘以及AFH_channel_map, 一個不可用的射頻通道將被唯一地轉換為一可用通道, 這樣保證了在同一微微網中使用AFH 機制的主從裝置能夠保持跳頻序列的同步。

在這種實現機制下, 非自適應的79 跳系統的跳頻序列等於將全部通道設為可用的AFH 選頻核心產生的頻率序列, 這一屬性使得可以方便地與原非AFH 裝置保持相容。 AFH 技術的另一點改變是: 在原跳頻系統中, 主從裝置分別採用不同的頻率傳送資料; 當處於AFH 狀態時, 在一次主從對話期間, Slave使用與Master相同的射頻通道向Master響應資料包, 這被稱作AFH 的相同通道機制。使用相同通道機制主要是由於在網中存在干擾的情況下, 減少跳頻可以防止Slave在傳送響應分組時跳到可能發生衝突的通道上, 保證至少在一次主從對話的過程中資料不易受到干擾, 達到提高吞吐率的目的。

3.2.AFH狀態的控制

由於一個微微網中的跳頻序列完全是由主裝置決定的, 因此, 主裝置也負責控制微微網跳頻序列自適應狀態的啟用和停止, 並需要定期地更新可用通道資訊。當系統希望進入AFH 狀態時, 主裝置首先要進行裝置識別和初始化操作, 該過程主要在LMP( 鏈路管理協議) 層進行。 主裝置先向其所有從裝置傳送詢問訊息, 通過檢視從裝置的屬性檢查是否具有支援AFH 機制的能力。如果主從裝置都支援AFH, 則主裝置傳送LMP_set _AFH 的PDU 資料分組, 此PDU中包括AFH_mode 和AFH_channel_map 等引數, 將可用和不可用的通道通告給從裝置。主裝置對AFH 狀態的進入、退出和更新都使用此PDU 型別, 傳送AFH 命令之後, 主裝置將等待確認資訊的返回。 如果在規定的某個時刻( AFH_instant) 之前收到確認資訊,則整個微微網順利改變AFH 狀態;

如果是進行更新通道資訊操作, 在AFH_instant 之前未收到確認資訊的情況下, 主裝置將恢復使用全部通道作為可用通道的跳頻序列,並繼續向從裝置傳送AFH 命令直到收到響應, 方可以使用更新後的自適應跳頻序列。

3.3.可用通道的確定

AFH_channel_map 引數中的可用通道是由以下幾點共同確定的:
(1) 主裝置本身對於干擾的測量。其主要依據有分組包丟失率(PLR)、接收訊號強度(RSSI)、迴圈冗餘糾錯(CRC)、混合糾錯(HEC)、前向糾錯(FEC)等。
(2) Host端可以通過HCI命令HCI_set_AFH_Channel_Classification向藍芽裝置宣告通道狀態資訊。
(3) 從裝置也可以把其掌握的通道資訊通過LMP 層的PDU 報告給主裝置。
主裝置將對這些資訊資源進行理的分析和推算並最終生成一個可信賴的AFH_channel_map, 但無論如何可用通道的數量一定要大於最小通道數Nmin (20) 。 假設推算得到可用的good通道數為NG, 若NG ≥Nmin , 則可以使用全部good通道; 若Nmin > NG, 則必須使用部分unknown/bad 通道。

4.CSA#1(BLE 4.x)

4.1.演算法流程

CAS#1跳頻演算法用於資料連線中，資料通道共37個，跳頻公式如下： unmappedChannel = (lastUnmappedChannel + hopIncrement) mod 37。
fn+1=(fn+hop) mod 37, hop是一個5~16的隨機值，在每次鏈路建立之後固定。協議規定第一次連線事件中fn=0，fn+1=(0+hop) mod 37，也就是hop通道編號

4.2.舉例

假設主機 ChanelMap = 00011110 00000000 11100000 00000110 00000000b，最右邊為第 1 通道，最左邊為第 40 通道。那麼使用到的通道為 9, 10, 21, 22, 23, 33, 34, 35, 36。
usedChannel[] = {9,10,21,22,23,33,34,35,36}, 即numUsedChannel(N) = 9
Last Unmapped Channel 的初值值為 0(之後為每次計算出來的unmappedChannel)；
假設輸入 hopIncrement = 7, 則
unmappedChannel = (0+7)mod37 = 7，而 7 通道不是一個可用的通道，那麼就要重對映, N=9
remappingIndex = 7mod N = 7
又 usedChannel[7] = 35
所以 data channel index = 35.

4.3.usedChannel

在上面的論述中，我們假設了ChanelMap,但在實際過程中如何得到。
1.系統在啟動後會將所有資料通道(37)都設定為可用。
2.在隨後的使用過程中會對通道狀態進行評估，非常的類似於AFH機制的通道評估(可以看做簡化版的AFH)。
3.評估的輸入引數有兩個，1)裝置對自身的評估結果；2)來自host的評估結果。最終通過一系列演算法確定除usedChannel map.
4.在鏈路建立時，initiating端會發送CONNECT_REQ,會將channel_map填充ChM欄位,同時會置上一個timer(device_channel_map_update_timer)，用於之後定期更新該channel_map(使用LL_CHANNEL_MAP_IND)
5.其次當host通過hci cmd傳送host的通道評估結果時，也需要更新channel_map;

本地如何對通道進行評估？？
其實與classic相似，其主要依據有分組包丟失率(PLR)、迴圈冗餘糾錯(CRC)。所以可以看做是簡化版的AFH.

5.CSA#2(BLE 5.0)

CSA＃2是更復雜和更難跟蹤用於獲得下一個連線事件的通道索引的演算法。特別是在高通量使用情況下，避免干擾和多路徑衰落效應，使得藍芽可以在超過10dBm的發射功率情況下獲取全世界不同國家的無線電認證（單點發射功率過高肯定是難過歐美無線電認證，必須通過跳頻方式使得產品平均低於當地政府要求，CSA #2的演算法下，藍芽產品在整個工作頻段的平均功率較CSA #1要低）。

5.1.輸入引數

1.ChannelIdentifier = (Access Address31-16) XOR (Access Address15-0)
2.The 16-bit input counter changes for each event.
For data connections it is the connection event counter connEventCounter defined in Section 4.5.1.
對於M && S，每一個次CE,connEventCounter+=1;
For periodic advertising it is the event counter paEventCounter defined in
Section 4.4.3.4. (The initial value of this counter is implementation specific. The counter shall be incremented by one for each AUX_SYNC_IND PDU; the paEventCounter shall wrap from 0xFFFF to 0x0000. AUX_SYNC_IND PDUs shall use the Channel Selection Algorithm #2 (see Section 4.5.8.3) with this event counter.)

5.2.隨機數prn_e的生成過程

5.2.1.PERM

5.2.2.MAM

output = (17 x a + b) mod 216

5.3.重對映

5.4.舉例

假設主機使用到的通道為 9,10,21,22,23,33,34,35,36。
usedChannel[]={9,10,21,22,23,33,34,35,36}
Access Address 假設為 0x364F10C1, Access Address[31~0] = {0011 0110 0100 1111 0001 0000 1100 0001}
第一步：
ChannelIdentifier = {0011 0110 0100 1111}XOR{0001 0000 1100 0001}= {0010 0110 1000 1110} (十進位制 9870)
第二步：
A 點： ChannelIdentifier XOR counter, 初始時刻 counter=0；
A = {0010 0110 1000 1110} XOR {0000 0000 0000 0000}={0010 0110 1000 1110}
B 點 PERM ,交換位元位;
B = {0110 0100 0111 0001} (十進位制 25713)
C 點 MAM， Multiply, Add, and Modulo;
C = (2571317+9870)MOD(2^16) = 53775 {1101 0010 0000 1111}
同理：
D = {0100 1011 1111 0000}(十進位制 19440)
E = (1944017+9870)MOD (2^16) = 12670 {0011 0001 0111 1110}
F = {1000 1100 0111 1110} (35966)
G = (3596617+9870)MOD(2^16) = 31468{0111 1010 1110 1100}
prn_e = G XOR ChannelIdentifier = {0101 1100 0110 0010}(23650)
第三步：
unmappedChannel = prn_e MOD 37 = 7
第四步：
判斷， 7 通道不是一個可用的通道，那麼就要重對映, N=9
remappingIndex = floor(923650/2^16) = 3
又 usedChannel[3] = 22
所以 data channel index = 22.

5.5.小結

CSA #2和CSA #1一樣的地方是都有一張約定的跳頻表；不一樣的是跳頻階躍的值，CSA #1的跳頻階躍值是固定的，CSA #2的跳頻階躍是通過演算法計算出來的。
另外一個不一樣的是CSA #2可以用在廣播通道和連線通道，CSA #1只適用於連線通道。

6.總結

經典藍芽跳頻AFH演算法最為複雜，需要實時監聽壞通道，更新跳頻表，對MCU資源要求較高，BLE 4.x是AFH的簡化版，跳頻表隨機，跳頻階躍固定，藍芽5的BLE部分使用新的CSA #2演算法，跳頻階躍通過演算法計算得到，避免干擾和多路徑衰落效應。