LoRaWAN 1.1 版本封稿很久了也沒有完整啃過一遍，最近邊啃邊翻譯，趁着這個機會把它碼下來。
如果覺得哪里有問題，歡迎留言斧正。
翻譯不易，轉載請申明出處和鏈接。
4 MAC 幀格式
所有的LoRa 上下行消息都攜帶PHY負載(Payload)，PHY負載以單字節的MAC頭(MHDR)開始，緊跟着一個MAC負載(MACPayload)1，最終以4字節的完整性校驗(MIC)結尾。
無線電PHY層:
| Preamble | PHDR | PHDR_CRC | PHYPayload | CRC* |
PHY負載：
| MHDR | MAYPayload | MIC |
| MHDR | Join-Request 或 Rejoin-Request |
MIC |
| MHDR | Join-Accept2 |
MAC負載:
| FHDR | FPort | FRMPayload |
FHDR:
| DevAddr | FCtrl | FCnt | FOpts |
4.1 MAC 層(PHYPayload)
| Size(bytes) | 1 | 7..M | 4 |
| PHYPayload | MHDR | MACPayload | MIC |
MAC負載字段的最大長度(M)以不同區域不同特性地被定義在第6章節
4.2 MAC頭(MHDR字段)
| Bit# | 7..5 | 4..2 | 1..0 |
| MHDR bits | MType | RFU | Major |
MAC頭規定了消息類型(MType),以及根據LoRaWAN規范的主版本號(Major)對該幀進行編碼。
1更詳細的最大負載長度定義在第6章節
2對於Join-Accept幀，MIC字段是與負載加密而不是單獨的一個字段
4.2.1 消息類型(Mtype 位字段)
LoRaWAN定義了8中不同的MAC消息類型：入網請求(join request)，重新入網請求(rejoin request)，入網許可(join accept)， 非確認上行/下行幀 (unconfirmed data up/down) ，確認上行/下行幀,以及私有協議消息。
| MType | Description |
| 000 | Join Request |
| 001 | Join Accept |
| 010 | Unconfirmed Data Up |
| 011 | Unconfirmed Data Down |
| 100 | Confirmed Data Up |
| 101 | Confirmed Data Down |
| 110 | Rejoin Request |
| 111 | Proprietary |
join-request、rejoin-request和join-accept都用於空中激活流程和漫游，具體詳見第6.2章節。
4.2.1.2 Data messages
Data messages 用來傳輸MAC命令和應用數據，這兩種數據也可以合並進一個消息里。確認幀(confirmed-data message)接收者應該應答，而非確認幀(unconfirmed-data message)則不需要應答1。私有消息(Proprietary message) 用來處理非標准格式的消息，這不能和標准消息互通，但只能用在使用同一種私有協議的設備間。當終端設備或者網絡服務器接收到未知的proprietarry message，應該選擇丟棄掉不處理。
4.2.2 數據消息的主版本(Major字段)
| Major bits | Description |
| 00 | LoRaWAN R1 |
| 01..11 | RFU |
注意：Major定義了入網過程(join procedure)的消息格式(見第6.2章節)和MAC Payload 的前四個字節(見第四章節)。對於每個主版本號，終端設備可以實現不同次版本號的幀格式，終端設備在使用次版本號之前應該在使用完頻點前提前通知網絡服務器(例如作為設備的定制化消息)。當設備或者網絡服務器收到帶有未知或不支持的版本號的LoRaWAN消息時，那么應該選擇丟棄掉不處理。
1ACK應答機制的時序圖在第19章節有詳細的描述。
4.3 數據消息的MAC Payload(MACPayload)
數據消息的MAC Payload包含：幀頭(FHDR)、端口(FPort)、幀負載(FRMPayload)，其中端口和幀負載是可選的。
4.3.1 幀頭(FHDR)
幀頭包含終端設備的短地址(DevAddr)、單字節的幀控制(FCtrl)、雙字節的幀計數器(FCnt)和用來傳輸MAC指令的幀選項(FOpts,最多可以15個字節)。如果FOpts存在，那么這個字段應該使用NwkSEncKey密鑰來加密，這在4.3.1.6章節有描述。
| Size(bytes) | 4 | 1 | 2 | 0..15 |
| FHDR | DevAddr | FCtrl | FCnt | FOpts |
下行幀的FCtrl字段內容如下:
| Bit# | 7 | 6 | 5 | 4 | [3..0] |
| FCtrl bits | ADR | RFU | ACK | FPending | FOptsLen |
上行幀的FCtrl字段內容如下:
| Bit# | 7 | 6 | 5 | 4 | [3..0] |
| FCtrl bits | ADR | ADRACKReq | ACK | ClassB | FOptsLen |
4.3.1.1 幀頭的自適應數據速率控制(ADR, ADRACKReq in FCtrl)
LoRa網絡允許終端設備單獨使用所有的數據速率和發射功率。LoRaWAN利用這一特性來調節和優化靜態終端設備的數據速率和發射功率。這被稱為自適應數據速率(ADR)，當這個位使能時，網絡會優化使用最快的數據速率。
當無線信道衰減過快或過於頻繁，ADR控制不應該使用。當網絡服務器不能控制設備的數據速率時，設備的應用層應該控制該字段。在這種情況下推薦使用不同的數據速率。應用層都應該在既有的網絡狀況下嘗試減少總的飛行時間。
當上行的ADR位使能，網絡服務器將通過相應的MAC指令來控制終端設備的數據速率和發射功率。當ADR位失能，網絡服務器不管收到的信號質量如何，也不會嘗試去控制終端設備的數據速率和發射功率。網絡服務器仍可以發送指令來修改頻道掩碼(channel mask)和幀重傳次數(frame repetition)等參數。
當下行的ADR位使能，則告知終端設備，網絡服務器可以發送ADR命令。這時設備可以使能/失能上行幀的ADR位。
當下行的ADR位失能，則告知終端設備，由於無線信道的快速變化，網絡服務器暫時不能預估到最好的數據速率，在這種情況下設備可以：
- 失能上行ADR位，使用自身的上行數據速率策略
- 忽略網絡服務器失能的這種情況(讓上行ADR位保持使能)，在沒有下行ADR指令時，使用正常的數據速率遞減。一個固定的終端設備應該采用這種典型的策略。
終端設備或網絡服務器按實際需求來使能/失能ADR位。不管怎樣，ADR機制都應該使用，以便幫助終端延長電池壽命和擴大網絡容量。
注意：即便移動終端設備，可能在大部分時間都實際處於靜止狀態的。因此終端設備根據自身的移動狀態，通過上行ADR位來請求網絡優化自身的數據速率。
缺省發射功率就是最大的發射功率，這關乎設備自身的能力以及不同區域管控的限制。設備應該使用這一功率，直到網絡服務器通過LinkADRReq 這條MAC指令來要求減少功率。
如果終端設備收到網絡優化的數據速率比自身缺省的數據速率高，或發射功率比自身缺省的發射功率低，那么它需要定期檢查下網絡仍能否收到上行幀。每次上行幀計數器都會增加(這是對於每條新的上行幀，而重傳幀不再增加該計數器)，設備增加一個ADR_ACK_CNT計數器。當ADR_ACK_LIMIT次上行幀(ADR_ACK_CNT >= ADR_ACK_LIMIT)沒有收到下行回復時,將會使能ADR應答請求位(ADRACKReq)。網絡服務器必須在下一次的ADR_ACK_DELAY幀之前回復一個下行幀，上行之后收到任何的下行幀都要重置ADR_ACK_CNT計數器。在終端設備的接收間隙收到的下行幀沒有使能ACK位，表明網關仍然收到該設備的上行幀。如果在下一次的ADR_ACK_DELAY上行幀之前沒有收到回復（換言之，在總的ADR_ACK_LIMIT + ADR_ACK_DELAY時間之前）,終端設備必須切換到缺省發射功率（即最大發射功率）、以及可能的話切換到下一個更低的速率使得能夠獲得更遠得傳輸距離，來重新連接網絡。終端設備如果在每次ADR_ACK_DELAY到了之后依舊沒收到ACK，那么就需要每次逐步降低數據速率。假如一旦設備到達了最低的速率，那么設備必須重新開啟所有缺省的頻道。
如果終端使用默認的數據速率和發射功率，那么ADRACKReq不應該設置，因為這種情況無法幫助提高鏈路距離。
注意：ADR確認請求(ADRACKReq)不需要立馬被回復，這樣可以讓網絡服務器有靈活的最佳的下行機制。
注意：在上行傳輸時,如果ADR_ACK_CNT >=ADR_ACK_LIMIT並且當前數據速率大於設備定義的最小數據速率亦或者發射功率小於默認的發射功率，亦或者當前的頻道掩碼只是默認頻道的一部分，ADRACKReq位才需要被使能，否則其他情況不需要設置。
下表提供了數據速率回退的例子，這里假設ADR_ACK_LIMIT和ADR_ACK_DELAY參數均位32。
| ADR_ACK_CNT# | ADRACKReq bit | Data Rate | TX power | Channel Mask |
| 0 to 63 | 0 | SF11 | Max-9dBm | Single channel enabled |
| 64 to 95 | 1 | Keep | Keep | Keep |
| 96 to 127 | 1 | Keep | Max | Keep |
| 128 to 159 | 1 | SF12 | Max | Keep |
| >= 160 | 0 | SF12 | Max | All channels enabled |
4.3.1.2 消息應答位和應答流程(ACK in FCtrl)
當收到確認幀時，接收端應該回復一條應答幀(ACK位置位)，如果發送端是終端設備，那么網絡服務器就使用終端發送操作完成后打開的兩個接收窗口的其中一個來進行回復。如果發送端是網關，終端就自行決定是否發送應答（參見下面的注意）。
應答消息只會在收到消息后回復，並且不會重發。
注意：為了讓終端盡可能的簡單，盡可能減少狀態，在收到確認幀需要回復時，可以立即發送一條顯式的應答幀(有可能內容為空),也可以延時發送，在下一次發送數據幀時帶上應答位。
4.3.1.3 重傳流程
下行幀：
下行確認或非確認幀不應該使用相同的幀計數器值來重傳，在下行確認幀的情況，如果沒有收到應答信號，會通知應用服務器來決定是否重新發送一條新的確認幀。
上行幀:
上行確認和非確認幀在沒有收到有效的下行幀之前會重傳"NbTrans"次(參照5.2章節)，網絡管理器使用NbTrans參數來控制節點上行的冗余，以此達到給定的服務質量。終端設備應該在重傳時也像往常一樣使用跳頻。終端設備應該在每一個重傳后進行等待，直到接收窗口過期。兩次重傳之間的時間間隔可以由終端設備自行決定，每一個設備都可以不相同。
如果設備收到相應的下行應答幀，那么應該停止再次重傳確認上行幀。
不管什么時候，如果設備在RX1接收窗口內收到有效的單播下行幀， Class B和C類型的設備應該停止再次重傳非確認上行幀。
不管什么時候，如果設備在RX1或者RX2 接收窗口內收到有效的下行幀， Class A類型的設備應該停止再次重傳非確認上行幀。
如果網絡服務器收到多於NbTrams次數的相同的上行幀，這有可能是受到了回復攻擊，或者是設備端的故障，因此網絡服務器不應該處理這些額外的幀。
注意：如果網絡服務器偵察到一個回復攻擊，那么可能需要采取一些其他的措施，例如把NbTrams參數設置為1，或者丟棄掉早前相同幀的頻點發上來的上行幀，亦或者采取其他的機制。
4.3.1.4 幀掛起位(FPending in Fctrl, 只有下行有效)
幀掛起位(FPending)只在下行傳輸中使用，表明網絡服務器還有掛起數據等待下發，因此要求終端設備盡快發送上行消息來打開另外的接收窗口。
FPending的准確用法在第19.3章節有詳細的描述。
4.3.1.5 幀計數器(FCnt)
每個終端設備有三個計數器來跟蹤數據幀的個數，一個是發給網絡服務器的上行鏈路計數器(FCntUp)，一個是網絡服務器發送下行給設備的下行鏈路計數器(FCntDown)。
在下行方向，有兩種不同的幀計數器機制存在；一個是單獨計數器機制，即當設備運行在LoRaWAN的協議為1.0時，所有端口都使用相同的下行幀計數器FCntDown。另外一個是雙計數器機制，即當設備運行在LoRaWAN的協議為1.1時，一個單獨的NFCntDown在端口為0且沒有FPort域時用作MAC通訊，另一個AFCntDown用在除了FPort為0以外的其他所有端口上。
在雙計數器機制下，NFCntDown是由網絡服務器來管理，而AFCntDown是由應用服務器來管理的。
注意：LoRaWAN1.0或者更早版本只支持一個FCntDown計數器（所有端口都使用這個），網絡服務器應該支持比LoRaWAN v1.1版本之前的設備。
無論何時，OTAA設備成功處理完join-accept消息后，終端設備端的上行幀計數器(FCntup)和相對於該設備的網絡服務器端的幀計數器(NFCntDown 和 AFCntDown)都重置為0。
ABP設備在開始階段就把它的所有幀計數器設置為0。對於ABP設備，幀計數器在設備使用期限應該從不重置。如果終端設備在使用期限因電量低而受到影響(例如更換電池)，幀計數器在這種情況應該跟之前一致。
FcntUP隨着每個上行幀增加。NFCntDown隨着每個Fport為0時或者沒有FPort域的下行幀增加。AFCntDown隨着每個除了0端口以外的下行幀增加。在接收端，相對應的計數器與接收到的數值保持同步，這會讓接收到的數值比當前數值有所增加，並且消息的MIC和使用相應的網絡會話密鑰算出來的MIC值一致。FCnt在多次重傳確認或非確認幀時不會增加(看NbTrans的參數)，網絡服務器應該拋棄重傳幀的應用負載並且只推送一次給應用服務器。
幀計數器為32位，FCnt字段對應於32位幀計數器的低16位(換言之，FCntUp對應的上行幀和AFCntDown/NFCntDown對應的下行幀)。
終端設備應該從不處理重傳的相同的下行幀。因此重傳應該在處理的時候忽略掉。
注意：這意味着設備只對下行確認幀作一次應答。類似地，設備收到帶有掛起位的幀時只產生一條上行幀。
注意： 因FCnt字段只帶有32位幀計數器中的低16位，所以網絡服務器應該從相互的通訊中推斷出32位幀計數器中的高16位。