LoRaWAN 規範1.0 （章節10~13）
最近在做LoRa， LoRaWAN協議略微複雜，邊讀邊翻譯，現在把部分關鍵的翻譯分享給各位做物聯網的同行。
當然裏面摻雜了一些我的個人筆記，希望對大家有所幫助。
如果哪裏有問題，歡迎應各位留言或者郵件指正。翻譯很辛苦，轉載請註明出處和源鏈接
- 英文原文鏈接： 《LoRaWAN Specification 1R0》
- LoRaWAN版本歷史及協議格式說明
- 翻譯原文鏈接：
章節10~13詳細講解B類相關的知識，當然下面幾章也是
10 B類模式的上行數據幀
除了幀頭中FCtrl字段的保留（RFU）位，B類和A類的上行數據幀一樣。B類使用A類中沒有使用的RFU位：
| 第幾位 | 7 | 6 | 5 | 4 | 3…0 |
|---|---|---|---|---|---|
| FCtrl | ADR | ADRACKReq | ACK | ClassB | FOptsLen |
上行數據中的 ClassB 位設爲1，來告訴網絡服務器：設備已經轉換爲B類模式，已經準備在照預定時間接收下行ping。
下行數據的 FPending 位意義不變，仍然表示服務器上有等待發送給設備的消息。如果下行數據使用該標記，設備應當按照A類的規範來接收數據。
11 下行Ping幀格式（B類）
11.1 物理層幀格式
和A類下行幀格式一致，不過可能要按照不同的信道頻率規劃。
11.2 單播和組播MAC消息
消息可以是單播，也可以是組播。給一個終端設備單獨發送消息使用單播，給多個終端設備發送使用組播。組播時屬於同一組的設備必須使用相同的組播地址和加密密鑰。LoRaWAN B類規範並沒有指定這些，這就是說要遠程設置組播的組，或者安全地分發組播需要的密鑰相關的信息。這些信息必須要設置，要麼在節點手動激活的時候一起配置，要麼通過應用層配置（遠程）。
11.2.1單播的MAC消息格式
單播時的，下行Ping的MAC負載（MAC payload）遵循A類規範，終端設備處理數據的方式完全相同。同時也使用相同的幀計數器，無論下行數據使用B類的 ping slot 還是使用A類的 “piggy-back” slot，計數器都會增加。
11.2.2組播的MAC消息格式
組播幀和單播幀的格式只有一些微小差別：
- 禁止攜帶MAC命令，不論在FOpt還是在payload（port=0）：因爲組播和單播的驗證穩健性不同。
- ACK 和 ADRACKReq 必須爲0，MType必須使用不需要回復的類型（Unconfirmed Data Down）。
- 此處的FPending表示還有組播數據需要發送。一旦使用，下一次組播的接收時隙會發送一個數據幀；如果不使用，下一個組播可以帶數據也可以不帶數據。當接收時隙衝突時，終端可以用它來評估優先級。
12 信標捕獲和追蹤
終端設備由A類切換到B類之前要先接收一次網絡的信標，來校正它的內部時序。終端設備進入B類模式以後，爲了關閉和網絡時間不一致（時基發生漂移）的內部時鐘，要定期搜尋、接收網絡信標。使用B類的終端有時可能會接收不到信標（超出網關連接範圍、有干擾等等），
這種情況下終端設備就必須逐步擴大其信標的範圍，而且 ping slots 的接收窗口也要考慮到內部時鐘漂移的情況。
注：
例如，一個設備，其內部時鐘精度 10ppm ，那麼每個信標週期就可能會漂移 +/-1.3ms。10ppm——每秒誤差百萬分之十秒，表示一天會有 10×24×60×60=0.864s的誤差。
12.1 最小無信標操作時間
設備在沒有信標的情況下，會維持B類模式2小時（距最後一次收到信標120分鐘），這種臨時的沒有信標的B類操作稱作“無信標”操作，這些操作都依賴終端設備自身的時鐘計時。
在無信標期間，爲了適應終端可能出現的時鐘漂移，單播、組播和信標的接收時隙必須要逐步擴大。
12.2 建立在接收上的無信標操作擴展
在120分鐘“無信標”期間，終端接收到任何信標，都會重置“無信標”時間（重新從0計算）。終端設備會通過接收到的信標來修正時間漂移，並重置接收時隙的時間長度。
12.3 時間漂移最小化
終端設備可以使用信標（如果可以的話）的精度週期性的校準它們的內部時鐘，並降低內部時鐘頻率的誤差。由於定時振盪器的時間偏移與溫度相關，並且可以計算出來，因此可以通過使用溫度傳感器進一步降低時間漂移。
13 B類下行時隙時間
13.1 定義
爲保證B類終端設備操作成功，必須要在精確的時間點開啓接收時隙，該時間點與基礎信標有關。本節會詳細介紹這些時間。
兩個信標起點之間的時間間隔稱作信標週期。信標以 BEACON_RESERVED 的起點作爲數據傳輸的起始時刻。每個信標的前面都有一段守護時間，守護時間內部不會有任何 ping slot。守護時間的時間長度和所允許的最長幀在空中的傳輸時間一致，以此來保證守護時間之前任何時刻開始的下行數據都能被接收完，並且不會和接收信標發生衝突。ping slot的可用時間範圍：從信標預留時間的結束時刻開始，到下一個信標守護時間的起始時刻結束。
表35：信標時間
| 名稱 | 時間長度 |
|---|---|
| Beacon_period | 128 s |
| Beacon_reserved | 2.120 s |
| Beacon_guard | 3.000 s |
| Beacon-window | 122.880 s |
信標在空中傳輸的時間遠遠小於信標爲網絡管理廣播幀預留的時間。
信標窗口時間間隔分成
終端設備一旦使用第 N 個時隙，就必須精確的在信標起始之後的第 Ton 秒打開接收窗口，其中Ton計算方法如下：
N是時隙索引（第N個時隙），單位ms。
最後一個ping slot在上次信標開始之後的第
13.2 隨機時隙
爲了避免系統衝突和 over-hearing (不確定是竊聽還是過載，不過根據LoRWAN的功能推斷這裏應該是過載)，使用隨機的時隙索引，並且每個信標期間都要變化。
參數如下：
| DevAddr | 設備單播或組播網絡地址，32位 |
|---|---|
| pingNb | 每個信標週期內的ping slot數量。必須是2的指數倍： |
| pingPeriod | Period of the device receiver wake-up expressed in number of slots： |
| pingOffset | offset是個隨機值，每次信標週期開始時通過計算獲得。範圍： 0~(pingPeriod - 1) |
| beaconTime | 該時間在BCNPayload中，Time of the immediately preceding beacon frame |
| slotLen | 一個ping slot的時長：30ms |
爲了校準（對齊）接收時隙，每個信標週期終端設備和服務器都會重新計算一個僞隨機偏移。隨機數生成使用AES加密算法，密鑰全部由0組成：
Key = 16 x 0x00
Rand = aes128_encrypt(Key, beaconTime | DevAddr | pad16
pingOffset = (Rand[0] + Rand[1]x 256) modulo pingPeriod本信標週期內使用的縫隙：
pingOffset + N x pingPeriod 其中 N=[0:pingNb-1]節點在以下時間點打開接收縫隙：
| 縫隙 | 開啓時刻 |
|---|---|
| 縫隙 1 | Beacon_reserved + pingOffset x slotLen |
| 縫隙 2 | Beacon_reserved + (pingOffset + pingPeriod) x slotLen |
| 縫隙 3 | Beacon_reserved + (pingOffset + 2 x pingPeriod) x slotLen |
| … | … |
| 縫隙 n | Beacon_reserved + (pingOffset + (n-1) x pingPeriod) x slotLen |
如果終端設備同時提供一個單播以及一個或多個組播縫隙，那麼在一個新的信標週期開始時，要進行多次這種計算。爲單播地址計（節點網絡地址:DevAddr）算一次，爲每個組播地址計算一次。
單播和組播的 縫隙 衝突時，終端設備的接收器優先處理組播。如果多個組播接收縫隙衝突，上次FPending標記位非0的優先處理。
使用隨機化方案來避免單播時隙和組播時隙之間系統級別的衝突。如果在某個信標週期出現衝突，下一個信標週期幾乎沒有發生衝突的可能性。
PS
看到有些夥伴提問問題，由於本人的CSDN一般不在線。
爲了方便交流，附個郵箱，有問題或者想法的朋友可以 
本文由 qingchuwudi 譯製，除非另有聲明，在不與原著版權衝突的前提下，本作品採用知識共享署名 3.0 中國大陸許可協議進行許可。