---
title: LoRaWAN規範閱讀筆記 - Ch. 4
description: 基於LoRaWAN規範V1.1的閱讀筆記
# image: https://hackmd.io/screenshot.png
tags: LoRaWAN
# robots: noindex, nofollow
langs: zh-Hant
---

# LoRaWAN規範閱讀筆記 - Ch. 4

基於[LoRaWAN規範 V1.1]的閱讀筆記。

[LoRaWAN規範 V1.1]: https://lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf

規範參考文獻：
- [[IEEE802154]]: IEEE Standard for Local and Metropolitan Area Networks—Part 15.4: Low Rate Wireless Personal Area Networks (LR-WPANs), IEEE Std 802.15.4TM-2011 (Revision of IEEE Std 802.15.4-2006), September 2011.
- [[RFC4493]]: The AES-CMAC Algorithm, June 2006.
- [[PHY]]: LoRaWAN Regional parameters v1.1, LoRa Alliance
- [[BACKEND]]: LoRaWAN backend Interfaces specification v1.0, LoRa Alliance

# 4. MAC訊息格式
所有LoRa上行鏈路和下行鏈路訊息攜帶著PHY payload(**Payload**)，以1個位元組的MAC標頭(**MHDR**)開始，接著是MAC payload(**MACPayload**)，並以4個位元組的訊息完整性代碼(**MIC**)結束
> MAC payload大小是區域特定的，詳見第6章

**Radio PHY layer:**

digraph PHY_layer {
	node[shape=record]
    PHY_layer [
    label="Preamble|PHDR|PHDR_CRC|PHYPayload|CRC*"
    ];
}

**PHYPayload:**

digraph PHYPayload {
	node[shape=record]
    PHYPayload [
    label="MHDR|MACPayload|MIC"
    ];
}

or

digraph PHYPayload {
	node[shape=record]
    PHYPayload [
    label="MHDR|Join-Request\nor\nRejoin-Request|MIC"
    ];
}

or

digraph PHYPayload {
	node[shape=record]
    PHYPayload [
    label="MHDR|Join-Accept"
    ];
}

> 對於Join-Accept框，MIC字段伴隨著有效負載被加密，而不是單獨的字段

**MACPayload:**

digraph MACPayload {
	node[shape=record]
    MACPayload [
    label="FHDR|FPort|FRMPayload"
    ];
}

**FHDR:**

digraph FHDR {
	node[shape=record]
    FHDR [
    label="DevAddr|FCtrl|FCnt|FOpts"
    ];
}

## 4.2 MAC標頭 (MHDR field)
|Bit#|7..5|4..2|1..0|
|:-:|:-:|:-:|:-:|
|MHDR bits|MType|RFU|Major|

MAC標頭指定訊息類型(MType)，並根據LoRaWAN層規範的訊框格式的主要版本(Major)對訊框進行編碼。
> RFU is Reserved for Future Usage

### 4.2.1 訊息類型 (MType bit field)
LoRaWAN區分8種不同的MAC訊息類型：

|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|

#### 4.2.1.1
**join-request**，**Rejoin-request**和**join-accept**訊息由第6.2章中描述的無線啓動過程使用，用於漫遊目的。

#### 4.2.1.2
數據訊息用於傳輸MAC命令和應用程序數據，它們可以在單個訊息中組合在一起。 **confirmed-data**訊息 **“必須”** 由接收方確認，而**unconfirmed-data**訊息不需要確認。**Proprietary(專有)** 訊息可用於實現與標準訊息不可互操作的非標準訊息格式，但只能在對專有擴展有共同理解的設備之間使用。當終端設備或網路服務器收到未知的專有訊息時，它 **“必將”** 以靜默方式丟棄它。

對於不同的訊息類型，以不同的方式確保訊息完整性，並且在下面的訊息類型中描述。

### 4.2.2 數據訊息的主要版本 (Major bit field)
|Major bits|Description|
|:-:|:-:|
|00|LoRaWAN R1|
|01..11|RFU|

> RFU is Reserved for Future Usage

> **注意**：Major版本指定了在連接過程中交換的訊息的格式(參見第6.2章)和MAC Payload的前四個位元組，如第4章所述。對於每個主要版本，終端設備可以實現不同的次要版本的訊框格式。必須事先使用帶外訊息(例如，作為設備個性化訊息的一部分)使網路服務器知道終端設備使用的次要版本。當設備或網路服務器收到攜帶未知或不受支持的LoRaWAN版本的訊框時，它 **“必將”** 以靜默方式丟棄它。

## 4.3 MAC Payload of Data Messages (MACPayload)
數據訊息的MAC Payload包含訊框標頭(**FHDR**)，後跟可選的端口字段(**FPort**)和可選的訊框Payload字段(**FRMPayload**)。具有有效FHDR，無Fopts(FoptsLen = 0)，無Fport且無FRMPayload的訊框是有效訊框。

### 4.3.1 訊框標頭 (FHDR)
**FHDR**包含終端設備的短設備地址(**DevAddr**)，訊框控制位元組(**FCtrl**)，2個位元組訊框計數器(**FCnt**)，以及用於傳輸MAC命令的最多15個訊框的訊框選項(**FOpts**)。如果存在，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網路允許終端設備單獨使用任何可能的數據速率和Tx功率。LoRaWAN使用此功能來調整和優化靜態終端設備的數據速率和Tx功率。這稱為自適應數據速率(**ADR**)，當啟用此功能時，網路將進行優化，以盡可能使用最快的數據速率。

當無線電信道衰減快速且不斷變化時，可能無法進行自適應數據速率控制。當網路服務器無法控制設備的數據速率時，設備的應用層應該控制它。在這種情況下，建議使用各種不同的數據速率。應用層 **“應該”** 總是盡量減少在網路條件下使用的聚合空中時間(aggregated air time)。

如果設置了上行鏈路ADR位元，網路將通過適當的MAC命令控制終端設備的數據速率和Tx功率。如果未設置ADR位元，則無論接收信號質量如何，網路都不會嘗試控制數據速率和終端設備的發送功率。網路仍然 **“可以”** 發送命令來改變信道掩碼或訊框重複參數。

當下行鏈路ADR位元被設置時，它通知終端設備網路服務器處於發送ADR命令的位置。設備 **“可以”** 設置/取消上行鏈路ADR位元。

當下行鏈路ADR位元未設置時，它向終端設備發信號通知由於無線電信道的快速變化，網路暫時無法估計最佳數據速率。在這種情況下，設備可以選擇：
- 取消設置ADR上行鏈路位元，並按照自己的策略控制其上行鏈路數據速率。這 **“應該”** 是移動終端設備的典型策略。
- 忽略它(保持上行鏈路ADR位元設置)並在沒有ADR下行鏈路命令的情況下應用正常數據速率衰減。這 **“應該”** 是固定式終端設備的典型策略。

ADR位元可以由終端設備或網路按需設置和取消設置。但是，只要有可能，應該啟用ADR方案以延長終端設備的電池壽命並最大化網路容量。
> **注意**：即使移動終端設備在大多數情況下實際上也是不動的。 因此，根據其移動狀態，終端設備可以請求網路使用ADR上行鏈路位元來優化其數據速率。

默認Tx功率是考慮設備功能和區域監管限制的設備允許的最大傳輸功率。 設備應使用此功率級別，直到網路通過LinkADRReq MAC命令請求更少。

如果網路優化終端設備的數據速率以使用高於其默認數據速率的數據速率，或者低於其默認TXPower的TXPower，則它週期性地需要驗證網路是否仍然接收上行鏈路訊框。每次上行鏈路訊框計數器遞增時(對於每個新上行鏈路，重複傳輸不增加計數器)，設備遞增**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**時，終端設備 **“必須”** 逐步降低其數據速率。一旦設備達到最低數據速率，它 **“必須”** 重新啟用所有默認上行鏈路頻率信道。

如果設備使用其默認數據速率和傳輸功率，**“必將不”** 設置**ADRACKReq**，因為在這種情況下，不能採取任何措施來改善鏈路範圍。

> **注意**：不請求立即響應ADR確認請求可為網路提供靈活性，以便最佳地調度其下行鏈路。

> **注意**：在上行鏈路傳輸中，如果**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.3），除非在其中一次傳輸之後接收到有效的下行鏈路。網路管理器可以使用“**NbTrans**”參數來控制節點上行鏈路的冗餘以獲得給定的服務質量。終端設備 **“必將”** 像往常一樣在重複傳輸之間執行跳頻，它 **“必將”** 在每次重複之後等待，直到接收窗口到期為止。重傳之間的延遲由終端設備決定，並且每個終端設備 **“可以”** 不同。

如果接收到相應的下行鏈路確認訊框，則設備 **“必將”** 停止上行鏈路“確認”訊框的任何進一步重傳

只要在RX1時隙窗口期間接收到有效的單播下行鏈路訊息，B&C類 **“必將”** 停止上行鏈路“未確認”訊框的任何進一步重傳。

每當在RX1或RX2時隙窗口期間接收到有效的下行鏈路訊息時，A類設備 **“必將”** 停止上行鏈路“未確認”訊框的任何進一步重傳。

如果網路接收到多於相同上行鏈路訊框的**NbTrans**傳輸，則這可能是重放攻擊或故障設備的指示，因此網路 **“必將不”** 處理額外訊框。

> 注意：檢測重放攻擊的網路可能採取其他措施，例如將**NbTrans**參數減少為1，或丟棄通過早先傳輸相同訊框的信道接收的上行鏈路訊框，或者通過其他一些未指明的機制

#### 4.3.1.4 訊框聽候位元 (FPending in FCtrl, downlink only)
訊框聽候位元(**FPending**)僅用於下行鏈路通信，表示網路有更多待發送的數據，因此要求終端設備通過發送另一個上行鏈路訊息盡快打開另一個接收窗口。第19.3節描述了**FPending**位元的確切用法。

#### 4.3.1.5 訊框計數器 (FCnt)
每個終端設備有三個訊框計數器，用於跟踪上行鏈路發送到網路服務器(**FCntUp**)的數據訊框數，並從網路服務器向設備發送下行鏈路(**FCntDown**)。

在下行鏈路方向上存在兩種不同的訊框計數器方案; 單個計數器方案，其中所有端口在設備作為LoRaWAN1.0設備運行時共享相同的下行鏈路訊框計數器**FCntDown**，以和一個雙計數器方案，其中單獨的**NFCntDown**用於端口0上的MAC通信和FPort字段丟失時，當設備作為LoRaWAN1.1設備運行時，另一個**AFCntDown**用於所有其他端口。

在兩個計數器方案中，**NFCntDown**由網路服務器管理，而**AFCntDown**由應用服務器管理。

> 注意：LoRaWAN v1.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參數）。 網路服務器 **“必將”** 刪除重新傳輸的訊框的應用程序payload，並僅將單個實例轉發到應用程序服務器。

訊框計數器是32位元寬，FCnt字段對應於32位訊框計數器的最低有效16位元（即用於發送上行鏈路的數據訊框的FCntUp和用於下行鏈路發送的數據訊框的AFCntDown / NFCntDown）。

終端設備 **“必將不”** 應重複使用相同的FCntUp值和相同的應用程序或網路會話密鑰，除了重傳相同的已確認或未確認的訊框。

終端設備 **“必將不”** 處理相同下行鏈路訊框的任何重傳。不經處理 **“必將”** 忽略後續重傳。

> **注意**：這意味著一旦接收到下行鏈路確認訊框，設備將僅確認，類似地，設備將僅在接收到設置了FPending位元的訊框之後生成單個上行鏈路。

> **注意**：由於**FCnt**字段僅攜帶32位元訊框計數器的最低有效16位元，因此服務器必須從流量觀察中推斷出元計數器的16個最高有效位元。

#### 4.3.1.6 訊框選項 (FOptsLen in FCtrl, FOpts)
**FCtrl**位元組中的訊框選項長度字段(**FOptsLen**)表示訊框中包括的訊框選項字段(**FOpts**)的實際長度。

**FOpts**最大長度為15個位元組的傳輸MAC命令，這些命令被搭載到數據訊框上;有關有效MAC命令的列表，請參閱第5章。

如果**FOptsLen**為0，則不存在**FOpts**字段。 如果**FOptsLen**與0不同，即如果**FOpts**字段中存在MAC命令，則不能使用端口0（**FPort**必須不存在或不同於0）。

MAC命令不能同時出現在payload字段和訊框選項字段中。如果發生這種情況，設備 **“必將”** 忽略該訊框。

如果訊框標頭攜帶**FOpts**，則 **“必須”** 在計算消息完整性代碼(**MIC**)之前對**FOpts**進行加密。

所使用的加密方案基於IEEE 802.15.4 / 2006附錄B [[IEEE802154]]中描述的通用算法，其使用密鑰長度為128位的AES。

使用的密鑰K是上行鏈路和下行鏈路方向上的**Fwpts**字段的**NwkSEncKey**。

加密的字段是：$pld = FOpts$

對於每條訊息，算法定義一個區塊A：
|Size (bytes) |1 |4 |1 |4 |4 |1 |1|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|A |0x01 |4 x 0x00 |Dir |DevAddr |FCntUp or NFCntDwn |0x00 |0x00|

方向字段(**Dir**)對於上行鏈路訊框為0，對於下行鏈路訊框為1。

區塊A被加密以獲得區塊S：
$$
S = aes128\_encrypt(K, A)
$$

通過將$(pld | pad16) ~\mathbf{xor}~ S$截斷到第一個$len(pld)$位元組來完成**FOpts**的加密和解密。

#### 4.3.1.7 Class B
在上行鏈路中設置為1的B類位元向網路服務器發信號通知該設備切換到B類模式並且現在準備接收預定的下行鏈路ping。有關B類規範，請參閱文檔的B類部分。

### 4.3.2 Port field (FPort)
如果訊框payload字段不為空，則 **“必須”** 存在端口字段。如果存在，則**FPort**值為`0`表示**FRMPayload**僅包含MAC命令，並且具有這種**FPort**的任何接收訊框應由LoRaWAN實現處理; 有關有效MAC命令的列表，請參閱第5章。**FPor**值`1..223(0x01..0xDF)`是特定於應用程序的，並且具有這種**FPort**的任何接收訊框都 **“必將”** 由LoRaWAN實現提供給應用程序層。FPort值224專用於LoRaWAN MAC層測試協議。 LoRaWAN實現 **“必將”** 丟棄來自**FPort**值不在1..224範圍內的應用層的任何傳輸請求。

> **注意**：FPort值224的目的是提供專用的FPort，以便在最終版本的設備上通過無線方式運行MAC一致性測試場景，而無需在實際方面依賴於設備的特定測試版本。該測試不應與實時操作同時進行，但設備的MAC層實現應完全是用於正常應用的實現。通常使用**AppSKey**加密測試協議。這可確保網路服務器無法在不涉及設備所有者的情況下啟用設備的測試模式。如果測試在實時網路連接設備上運行，則網路側測試應用程序學習**AppSKey**的方式超出了LoRaWAN規範的範圍。如果測試在專用測試平台（不是實時網路）上使用OTAA運行，則**AppKey**與測試平台通信的方式，對於安全的JOIN過程，也不在規規範範圍內。在應用層運行的測試協議是在LoRaWAN規範之外定義的，因為它是一個應用層協議。

**FPort**值`225..255(0xE1..0xFF)`保留用於將來的標準化應用程序擴展。

|Size (bytes) |7..22 |0..1 |0..N|
|:-:|:-:|:-:|:-:|
|MACPayload |FHDR |FPort |FRMPayload|

N是應用程序Payload的位元組數。 N的有效範圍是特定於區域的並在[[PHY]]中定義。

N **“必須”** 等於或小於：

N ≤ M - 1 - (length of FHDR in octets)

其中M是最大MAC Payload長度

### 4.3.3 MAC訊框Payload加密 (FRMPayload)
如果數據訊框攜帶Payload，則必須在計算消息完整性代碼(**MIC**)之前對**FRMPayload**進行加密。

所使用的加密方案基於IEEE 802.15.4 / 2006附錄B [[IEEE802154]]中描述的通用算法，其使用密鑰長度為128位的AES。

使用的密鑰K取決於數據消息的**FPort**：
|0 |Uplink/downlink |NwkSEncKey|
|:-:|:-:|:-:|
|1..255 |Uplink/downlink |AppSKey|

加密的字段是：$pld = FRMPayload$

對於每個數據消息，算法為$i = 1..k$定義區塊$A_i$的序列，其中$k=ceil(len(pld)/16)$：
|Size (bytes) |1 |4 |1 |4 |4 |1 |1|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|Ai |0x01 |4 x 0x00 |Dir |DevAddr |FCntUp or NFCntDwn or AFCntDnw |0x00 |i|

方向字段(**Dir**)對於上行鏈路訊框為0，對於下行鏈路訊框為1。

區塊$A_i$被加密以獲得區塊$S_i$的序列$S$：
$$
\begin{gathered}
Si = aes128\_encrypt(K, A_i) ~\text{for}~ i = 1..k\\
\\
S = S1 | S2 | .. | Sk
\end{gathered}
$$

有效載荷的加密和解密通過截斷到第一個$len(pld)$位元組來完成
$$
(pld | pad16) ~\mathbf{xor}~ S
$$

## 4.4 訊息完整性代碼 (MIC)
訊息完整性代碼（MIC）是在訊息中的所有字段上計算的。
$$
msg = MHDR | FHDR | FPort | FRMPayload
$$

其中$len(msg)$表示以位元組為單位的訊息長度。

### 4.4.1 下行鏈路訊框
下行鏈路訊框的**MIC**計算如下[[RFC4493]]：
$$
\begin{gathered}
cmac = aes128\_cmac(S \textbf{NwkSIntKey}, B_0 | msg) \\
\\
\textbf{MIC} = cmac[0..3]
\end{gathered}
$$

其中區塊$B_0$定義如下：
|Size (bytes) |1 |2 |2 |1 |4 |4 |1 |1|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|$B_0$ |0x49 |ConfFCnt |2 x 0x00 |Dir = 0x01 |DevAddr |AFCntDwn or NFCntDwn |0x00 |len(msg)|

如果設備連接到LoRaWAN1.1網路服務器並且下行鏈路訊框的ACK位元被設置，意味著該訊框正在確認上行鏈路“已確認”訊框，則**ConfFCnt**是訊框計數器值$\mod 2^{16}$的“已確認”的上行鏈路訊框正在被確認。在所有其他情況下，`ConfFCnt = 0x0000`。

### 4.4.2 上行鏈路訊框
上行鏈路訊框的**MIC**通過以下過程計算：

區塊$B_0$定義如下：
|Size (bytes) |1 |4 |1 |4 |4 |1 |1|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|$B_0$ |0x49 |0x0000 |Dir=0x00 |DevAddr |FCntUp|0x00 |len(msg)|

區塊$B_1$定義如下：
|Size (bytes) |1 |2 |1 |1 |1 |4 |4 |1 |1|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|$B_1$ |0x49 |ConfFCnt |TxDr |TxCh |Dir = 0x00 |DevAddr |FCntUp |0x00 |len(msg)|

- TxDr是用於傳輸上行鏈路的數據速率
- TxCh是用於傳輸的信道的索引。
- 如果設置了上行鏈路訊框的ACK位元，意味著該訊框正在確認下行鏈路“確認”訊框，則ConfFCnt是正被確認的“已確認”下行鏈路訊框的$\mod 2^{16}$的訊框計數器值。在所有其他情況下，`ConfFCnt = 0x0000`。

$$
\begin{gathered}
cmacS = aes128\_cmac(S \textbf{NwkSIntKey}, B_1 | msg)\\
\\
cmacF = aes128\_cmac(F \textbf{NwkSIntKey}, B_0 | msg)
\end{gathered}
$$

如果設備連接到LoRaWAN**1.0**網路服務器，則：
$$
\textbf{MIC} = cmacF[0..3]
$$

如果設備連接到LoRaWAN**1.1**網路服務器，則：
$$
\textbf{MIC} = cmacS[0..1] ~|~ cmacF[0..1]
$$

[IEEE802154]: https://standards.ieee.org/standard/802_15_4-2011.html
[RFC4493]: https://tools.ietf.org/html/rfc4493
[PHY]: https://lora-alliance.org/sites/default/files/2018-04/lorawantm_regional_parameters_v1.1rb_-_final.pdf
[BACKEND]: https://lora-alliance.org/sites/default/files/2018-04/lorawantm-backend-interfaces-v1.0.pdf