藍牙基礎知識進階——鏈路控制操作
七鏈路控制操作
鏈路控制操作就是用來描述一個設備是如何加入piconet又是如何從一個piconet中退出的。當然我們肯定不會忘記介紹一個設備是如何在多個piconet中夾縫生存的，呵呵~~
Q1：在加入和退出一個piconet的過程中是否有類似狀態轉換的定義啊？
這個問題不錯，的確爲了更好地描述這樣的一個過程，我們把設備在這個過程中的轉換分成了三個主要狀態和七個子狀態，這些狀態的定義在對整個藍牙操作的描述中是非常重要的。
三個主要狀態分別爲：
STANDBY:這個狀態是一個設備的默認狀態，可以認爲是初始的狀態。
CONNECTION:也就是處於連接的狀態，可以進行數據的交互。我們可以認爲它是正常工作的狀態。
PARK:就是設備不需要進行什麼操作，但又暫時不想退出piconet，這種狀態我們就稱之爲park的狀態。也就是一個pionet中除了active的slave之外的那些設備所處的狀態。目前在實際應用中，PARK狀態是不會使用的。
七個子狀態分別爲：
Page：這個子狀態就是我們通常稱爲的連接，進行連接/激活對應的slave的操作我們就稱爲page。
Page scan：這個子狀態是和page對應的，它就是等待被page的slave所處的狀態，換句話說，若想被page到，我們就要處於page scan的狀態。
inquiry：這就是我們通常所說的掃描狀態，這個狀態的設備就是去掃描周圍的設備。
inquiry scan：這就是我們通常看到的可被發現的設備。體現在上層就是我們在android系統中點擊設備可被周圍什麼發現，那設備就處於這樣的狀態。
slave response：這個就是在page的過程中，slave收到了master的page msg，它會迴應對應的pageresponse msg，同時自己就進入到了slave response的狀態。
master response：master收到slaveresponse的msg後，他就會進入到master response的狀態，同時他會發送一個FHS的packet。
inquiry response：就是在inquiry scan的設備在收到inquiry的msg後，就會發送inquiryresponse的msg，在這之後它就會進入到了inquiry response的狀態了。
Q2：這些狀態之間是如何轉換的啊？
一般而言，我們來解釋狀態的轉換都是通過狀態圖來描述的，這次我們仍然不例外。只要能清晰地讀懂這個狀態的轉換圖，我想整個工作的機理應該也就瞭然於胸了。
圖7-1 鏈路控制的狀態轉換圖
我們從最右邊往最左邊來一個個分析這個狀態的轉換。
standby->inquiry：當一個設備需要去掃描周圍是否有別的設備的時候，就會從standby轉變到inquiry的狀態。到了這個狀態之後，他就會重複地發送inquiry的msg，inquiry msg並沒有標明任何和source相關的信息，但是它可能包含哪一類的設備應當響應這個msg。處於inquiry scan的設備，就可以響應inquiry的msg了，但是spec中說並不是所有處於inquiryc scan的設備都必須響應inquiry的msg。所以，還是有一定的自主權的，哈哈~~。
在inquiry狀態的設備會收到被搜索到的設備發回的response，需要注意的是inquiry狀態的設備並不需要對這個response做出任何形式的迴應。因爲一段時間內進行inquiry的頻點範圍是有限的，若想搜索到所有頻點的設備，需要保證inquiry的最短時間是10.24s。這一點是尤爲重要的，這也是爲什麼我們通常看到一些設備如Android他的搜索時間都是設爲10.24s，就是這個原因。
inquiry->connection:在搜索到一個設備之後，就可以根據搜索到的信息進行連接該設備，從而進入到connection的狀態。
inquiry->standby:若是不進行連接或者沒有搜索到任何設備，在一定時間之後，仍然會回覆到standby的狀體。
connection->inquiry:和standy->inquiry比較類似，唯一的差別在於standby到inquiry可以集中全部的能力去進行inquiry，而connection到inquiry則因爲有別的事情需要做，需要做一些善後的工作，比如把ACL link置到sniff狀態，若是有SCO或者ESCO，則會比inquiry的優先級更高，先保證SCO或者ESCO的傳輸，在空隙時間才能進行inquiry。
standby->inquiry scan:若是一個設備想被發現，則會進入到inquiryscan的狀態。在此狀態若是收到inquiry的msg就可以進行迴應了。
inquiry scan->inquiry response：在收到inquiry的msg後，就可以迴應對應的inquiry的msg，從而進入到inquiryresponse的狀態。迴應的inquiry response有兩種情況，一種就是很單純地只回應對應的FHS的packet，另外一種就是有EIR（Entended Inquiry Result） data。是否有EIR data是FHS中的一個標誌位來決定的。
inquiry response->inquiry scan: 這有兩種情況，一種是我們下面要去和master建立連接從而進入到connection狀態，必須要經過inquiry scan狀態後才行，而不是直接就進入到conneciton狀態。另外一種就是回到原來的standby狀態，同樣的，我們仍然要經過這個inquiry scan的狀態。
inquiry scan->connection:這個和inquiry到connection狀態是類似，就不多說了。
connection->inquiry scan:這個狀態的變化和standy->inquiryscan是類似的，也不多說了。
standy->page scan:若是一個設備想被page到則需要進入到pagescan狀態。
page scan->slave response:在收到page的msg後，page scan的設備就會發送對應的responsemsg，然後進入到slave response的狀態。
slave response->connection:在第一次迴應response之後，maste和slave的交互並沒有完全結束。他們仍然還有別的msg的交互，在master收到slave的response之後，他會發送對應的FHS packet過來，這個時候slave response狀態的設備需要再次回覆一個response。在master收到這第二個response的時候，他會發送一個poll的packet下來，從這個時間點開始，slave正式進入到conneciton的狀態（step5）。具體可以參見下面圖7-2.
圖7-2 第一次page就恢復response的示意圖
這裏強調一點，就是response有可能在第二個page纔回復，這個在之前有講過就不再另外介紹了。
slave response->page scan:這個就是上面這個過程出問題了，就會回到pagescan的狀態。
page scan->connection:需要注意這不是一個正常的流程，它發生在connection->pagescan後page失敗，他就會返回到connection狀態，而不是從standy->page scan->connection。和page scan到standy類似。
page scan->standby:page失敗，返回之前的standby狀態。
connection->page scan:和standy到page scan類似。
standy/connection->page:若想page到一個設備，就需要進入到page的狀態。
page->standy/connection:同樣的page失敗回覆對應的初始狀態。
page->master response:在收到slave的response之後，就回應對應的FHSpacket，從而進入到master response的狀態。
master response->connection:和slaveresponse到connection是同步類似的，不詳細解釋。
master response->page: 同樣的是在上面出問題了，就回到page的狀態了。
connection->standby:這個就是斷開連接了，建立連接要走很多中間步驟，斷開連接就沒有這麼麻煩了，直接搞定。當然理論上還是需要通過reset或者detach命令進行的。
Q3：我們假定的master和slave的角色在整個過程中是否有機會改變啊
是的，有機會改變的。我們不能總是讓一家獨大，至少表面上還是要民主的，讓slave也是有機會去翻身做主人的。這個過程是通過role switch來實現的。一般來說可以通過如下方式來進行role switch。一個就是主動去page，我們會把主動page的設備定義爲master。另外一個就是重建一個piconet，這樣他就可以把自己當成master，而把原來的master定義成slave了，當然原來的master在原來的piconet中仍然扮演着master的角色。當然在有connection建立的時候，我們也可以通過上層發送的這樣的命令來進行switch的請求。
Q4：什麼是sniffmode，他是如何做到low power的
正常工作情況下，slave需要在每一個master的tx點進行監聽。而sniffmode則是通過增加這個監聽的週期來實現low power的。如下圖7-3所示，slave會在特定的間隔監聽master的tx，所以master也只要在相應的間隔再發送對應的數據即可。這個間隔就是圖中所示的Tsniff。slave就是隻在圖中所示的sniff anchor point時監聽。sniff mode只能應用於異步傳輸，不能應用於同步邏輯傳輸。
圖7-3 sniff的狀況示意圖
Q5: 什麼是sniff subrating mode，它和sniff mode有什麼關係
所謂的sniffsubrating mode就是使用更少的sniff anchor point，可以理解爲監聽的間隔更長了。他需要首先在sniff mode，然後有一個timeout，若是在這個timeout內沒有ACL-C和ACL-U的data傳輸，就會進入到sniff subrating mode，若是中間有了，則會重啓這個timer。反之，若是想從sniff subrating mode到sniff mode，只要有收到ACL的data，就需要退出到sniff mode，而且若是此時你發送的packet需要回應，那麼在迴應未到達的情況下，你仍然需要處於sniff mode。如下圖7-4
所示。
圖7-4 sniff和sniffsubrating的變換圖
八 Audio
語音在藍牙應用中是極爲關鍵的一個部分，藍牙耳機也在我們現實生活中起着極爲重要的作用。
Q1：目前藍牙傳輸的語音信息都有哪些格式？
在空氣中，目前有兩種語音信息格式是比較常見的，一種是64kb/s的對數 PCM一種是64kb/s的CVSD。我們在線路接口上的語音編碼的質量應當不能比64kb/s的對數PCM差。
Q2：語音若是有錯誤是如何處理的？
在環境不是很好的情況下，語音傳輸的質量取決於編碼格式的穩定性。當然，若是eSCO，則會有重傳來保證語音的質量。相對而言，CVSD對白噪聲不太敏感，不過不管怎麼說，因爲access code或者HEC的測試出錯，或者crc校驗有問題而導致pacekt被拒絕的話，需要有相應的策略來填補這個丟失的語音部分。
比如說對HV1的格式是1/3的FEC糾錯，我們就假設頂多有一個bit是錯的，這樣就可以“恢復”錯誤了。對於HV2和EV4這種2/3的FEC糾錯來說，若是有錯誤，10bit的信息還是要保存的。
文章來源：https://blog.csdn.net/u011960402/article/details/18546969