一、Air Kiss技術原理簡介

802.11是IEEE制定的無線區域網協議，802.11以802.2的邏輯鏈路控制封裝來攜帶IP封包，因此能夠以802.2 SNAP格式接收無線網路資料。如果開啟wifi晶片的混雜模式監聽空間中的無線訊號，並以802.2 SNAP格式從資料鏈路層擷取資料，就會得到如下圖所示的資料包：

DA欄位表示目標mac地址，SA欄位表示源mac地址，Length欄位表示後面資料的長度，LLC欄位表示LLC頭，SNAP欄位包括3bytes的廠商程式碼和2bytes的協議型別標識，DATA欄位為負載，對於加密通道來說是密文的，FCS欄位表示幀檢驗序列。

從無線訊號監聽方的角度來說，不管無線通道有沒有加密，DA

在實際應用中，我們採用UDP廣播包作為資訊的載體。資訊傳送方向空間中傳送一系列的UDP廣播包，其中每一包的長度(即Length

二、Air Kiss通訊協議

2.1. 物理層協議

在訊號載體方面，採用wifi無線訊號進行資訊傳遞，1-14全通道支援。

在訊號編碼方面，802.2 SNAP 資料包中的Length欄位為資料傳送方唯一可控欄位，因此Air Kiss通訊協議利用傳送資料包的長度進行編碼。由於受到MTU的限制，Length欄位最大可編碼位數為10bit。但實際測試過程中發現，

我們身處的無線網路環境有可能及其複雜，很有可能在同一個空間中存在多個AP，而這些AP又分佈在相同或者不同的通道上，這樣接收者一開始是不知道傳送方在1-14哪個通道上傳送資訊，而且同一個通道上也可能會有很多裝置在傳送UDP廣播包。在這種情況下，接收方監聽到的資料包是海量的。必須從海量的資料資訊中定位出發送方所在的通道和傳送方的mac地址。另外，由於在UDP廣播包傳送過程中，一個UDP層的資料包，要經過IP層、資料鏈路層的封裝，並且通過加密(加密方式包括WPA2、WPA、WEP三種)後才會被髮送出去，所以傳送方傳送UDP廣播包的長度與接收方監聽SNAP包中的Length欄位值存在差異，這就需要進行轉義。然而，由於底層加密方式的不確定性，使得這個差異值也具有不確定性。

為解決這兩個問題，在傳送鏈路層資料（見下節）之前，需要先發送400ms的前導域（400ms = 8*50ms，即如果裝置端以50ms的頻率切換通道，則可以覆蓋8個通道，因為一般使用者環境不用監聽14個通道，所以覆蓋8個通道足已)。前導域由4個位元組組成，其值固定為｛1,2,3,4｝。接收方在接收到這些前導域資料包後，利用SNAP包中的Length欄位與之相減，從而獲取到這個差異值。

舉個例子，接受方通過監聽，在鏈路層截獲802.2 SNAP格式的前導資料包，其Length欄位的值分別為53，54，55，56，那差異值就能確定為53-1=52。之後接收方接收到資料之後都用SNAP包的Length欄位值減去52，即能得到實際的資訊資料。

2.2. 鏈路層協議

鏈路層資料結構如下圖所示：

鏈路層資料結構可分為兩類，control欄位與data欄位，magic code、prefix code、sequence header field屬於control欄位，data field屬於data欄位。control欄位與data欄位以第8bit位（最高位）加以區別，該位為1表示data field欄位，為0表示control 欄位。在control欄位中，magic code欄位與prefix code欄位完全相同，magic code欄位與sequence header欄位通過第7bit位加以區分，該位為1表示sequence header欄位，為0表示magic code欄位。

以下分別對各個欄位進行詳細介紹。

⑴magic code欄位

magic code欄位的資料結構如下圖所示：

magic code由4個9bits組成，每個9bits的高5位為magic code欄位，低4位為information欄位。前兩個9bits的information欄位分別裝載要傳送資料長度的高4位和低4位，後面兩個9bits的information欄位分別裝載要傳送ssid的crc8值的高4位和低4位。

這裡單獨傳輸ssid的crc8欄位是對整個傳輸過程所做的優化。在研究中我們發現，在資訊傳輸之前先對AP進行掃描，通過獲取的beacon可以得知無線環境中所有非隱藏AP的ssid、rssi以及通道。在傳輸過程中，接收方先從magic code field中獲取目標AP ssid 的crc8值，然後再和事先掃描所得到的ssid的crc8值進行比對，如果發現相同值，那麼在接下來的接收過程中接收方就不用再接收ssid資訊，這就大大加快了傳輸的時間。

在傳輸過程中，需要傳送5個magic code欄位。這裡重複傳送的原因是magic code中的欄位很重要，接收端可以通過對比多次接收的結果來保證正確性。

⑵prefix code欄位

prefix code欄位的資料結構如下圖所示：

prefix code由4個9bits組成，每個9bits的高5位為magic code欄位，低4位為information欄位。前兩個9bits的information欄位分別裝載要傳送密碼的長度的高4位和低4位，後面兩個9bits的information欄位分別裝載傳送密碼長度的crc8值的高4位和低4位。

prefix code有兩個作用，首先是表示資料序列的正式開始，其次告訴接收端傳送密碼的長度，以便接收方在接收完資料後，對資料進行分割解密。

⑶sequence header欄位：

我們把待發送的資料以4為粒度進行劃分，每4個數據組成一個sequence，以sequence為單位進行資料的傳送。每個sequence都由sequence header欄位和data 欄位組成。最後一個sequence如果不夠4個數據，不用補全。

sequence header欄位由兩個9bits組成，第一個的低7位裝載的是從本sequence index開始到本sequence結束髮送的所有資料的crc8的低7位值（計算過程中不計入欄位標識位，因此sequence index最高位需補0），在接收完一個sequence的資料之後，需進行crc8值的效驗，如果不相同，證明該sequence的資料接收出錯，應該丟棄。

⑷data欄位：

data欄位的資料結構如下圖所示：

data欄位由4個9bits組成，每個9bits的第8位為控制位，固定為1，其餘的8位裝載需要傳輸的資料。

2.3. 應用層協議

送方所要傳送的資料由三部分組成：密碼、隨機數、ssid。其中隨機數的作用是，當資料接收方連上AP之後，立即傳送以該隨機數為內容的UDP廣播包，當傳送方收到該廣播包後就能確認接收方已經準確接收到所有資料。密碼和ssid都’\0’結尾，並且分別用AES進行加密，再發送。這三部分資料的傳送順序為先發送密碼，再發送隨機數，最後傳送ssid，如下圖所示：

三、Air Kiss通訊協議效能分析

3.1. 糾錯能力分析

Air Kiss技術中的通訊模型可以抽象為錯誤率為0-5%的單向的通道，所需要傳遞資訊的最大長度為68bytes。在這種情況下，如果不採用糾錯演算法，就很難保證在有限次數內完成資訊的傳送。

Air Kiss採用了累積糾錯演算法來保證在有限次內完成傳輸過程。累積糾錯演算法的理論基礎為：多輪資料傳送過程中，在同一位資料上發生錯誤的概率是很低的。因此可以累積多輪的資料傳遞結果進行分析，其中一輪中某一位錯誤資料有很大的概率能其它輪中找到其對應的正確值，這樣就能保證在有限次內完成資訊的傳送。

假定需要傳遞資訊的長度為68bytes，我們計算了在最壞的情況下，使用累積糾錯演算法與不使用累積糾錯演算法資訊傳送成功的概率與傳送次數的關係，結果如下表所示：

3.2. 基本效能分析

Air Kiss技術的傳輸速率取決於資訊傳送方UDP廣播包的傳送速率，目前廣播包的傳送頻率為5ms傳送一個，因此其傳輸速率為200bytes/s。在不計算magic code field的情況下，負載效率為66.7%。

從糾錯能力的分析可能，如果傳送資訊長度為最長的68bytes，那麼在最壞情況下，最多需要5次就可以完成資訊傳送，最大的傳輸時間需要2.039s。