一、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、SA、Length、LLC、SNAP、FCS字段總是暴露的，因此信號監聽方便有了從這6個字段獲取信息的可能。但從發送方的角度來說，由於操作系統的限制(比如ISO或者Android)，DA、SA、LLC、SNAP、FCS五個字段的控制需要很高的控制權限，發送方一般是很難拿到的。因此只剩下Length這一字段，發送方可以通過改變其所需要發送數據包的長度進行很方便的控制。所以，只要制定出一套利用長度編碼的通信協議，就可利用802.2 SNAP 數據包中的Length字段進行信息傳遞。
在實際應用中，我們採用UDP廣播包作爲信息的載體。信息發送方向空間中發送一系列的UDP廣播包，其中每一包的長度(即Length字段)都按照Air Kiss通信協議進行編碼，信息接收方利用混雜模式監聽空間中的無線信號，並從數據鏈路層截取802.2 SNAP格式數據包，便可得到已編碼的Length字段，隨後接收方便可根據Air Kiss通信協議解析出需要的信息。整個過程如下圖所示：
二、Air Kiss通信協議
2.1. 物理層協議
在信號載體方面，採用wifi無線信號進行信息傳遞，1-14全信道支持。
在信號編碼方面，802.2 SNAP 數據包中的Length字段爲數據發送方唯一可控字段，因此Air Kiss通信協議利用發送數據包的長度進行編碼。由於受到MTU的限制，Length字段最大可編碼位數爲10bit。但實際測試過程中發現，UDP包長度與丟包率、亂序率成正比。因此本協議中，我們把Length字段編碼位數限制在9bit，即UDP廣播包的發送長度不大於512字節。
我們身處的無線網絡環境有可能及其複雜，很有可能在同一個空間中存在多個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。