LoRaWAN 協定規範

羅拉規範。

版權©2015羅拉聯盟有限公司保留所有權利。

注意使用和披露。

版權©羅拉聯盟,Inc .(2015)。保留所有權利。

本文檔中的資訊是羅拉的财産聯盟(“聯盟”)及其使用和披露受羅拉聯盟企業規章制度、知識産權(IPR)政策和會員協定。

羅拉聯盟規範的元素可能會受制于第三方知識産權,包括但不限于專利、版權或商标權利(第三方可能是也可能不是羅拉聯盟的一員)。聯盟不負責,不應以任何方式負責識别或未能識别任何或所有這些第三方知識産權。

這個檔案和本文所包含的資訊提供了一個“是”的基礎上,聯盟并不保證明示或默示,包括但NOTLIMITED(A)任何保修的使用資訊HEREINWILL不侵犯任何第三方的權利(包括WITHOUTLIMITATION任何知識産權包括

專利、版權或商标權利)或(B)的任何默示保證

适銷性、健身為特定目的,标題或無侵犯。

聯盟會在任何事件承擔任何損失的利潤,虧損業務,使用的資料損失,中斷工作,或其他任何直接、間接、特别或模範,INCIDENTIAL、懲罰性或任何形式的間接損害,在合同或侵權,與本文檔相關的或所包含的資訊,即使建議此類損失或損害的可能性。

上述通知,這段必須包含本文檔的所有副本。

羅拉聯盟,2400卡米諾Ramon Inc .,375套房聖拉蒙,CA 94583

注意:所有公司、品牌和産品名稱可能是商标是他們的各自的主人的唯一财産。

LoRaWAN™規範

作者:n Sornin(Semtech),m·路易斯(Semtech),t .捏(IBM),t . Kramp(IBM),O。Hersent(Actility)

版本:V1.0.1草案3    日期:2015年10月     狀态:草案

目錄

LoRaWAN 規範 1.0 （2~4章）... 4

聲明... 4

2 LoRaWAN 簡介... 4

3 實體層消息格式... 6

4 MAC 消息格式... 8

5 MAC Commands. 22

5.1 鍊路檢查 （LinkCheckReq和LinkCheckAns）... 25

5.2 速率自适應 LinkADRReq和LinkADRAns 25

5.3 終端的發射占空比（DutyCycleReq 和 DutyCycleAns）... 29

5.4 接收視窗相關參數 (RXParamSetupReq,RXParamSetupAns) 29

5.5 終端狀态（DevStatusReq, DevStatusAns）... 31

5.6 建立或修改信道（NewChannelReq, NewChannelAns）... 32

5.7 Rx和Tx之間的延遲（RXTimingSetupReq,RXTimingSetupAns）... 35

5.7 Rx和Tx之間的延遲（RXTimingSetupReq,RXTimingSetupAns）... 36

5.8 終端發射參數(TxParamSetupReq,TxParamSetupAns) 38

6 終端激活（End-Device Activation）... 39

6.1 激活成功後存儲在終端裝置的資料... 39

6.2 無線激活（Over-the-Air Activation）... 40

6.3 手動激活(Activation by Personalization) 45

7. 實體層（Physical Layer）... 45

7.1 歐洲ISM頻段 863-870MHz. 45

7.2 美國 902-928MHz ISM 頻段... 55

7.3 中國 779-787MHz ISM 頻段... 55

7.4 歐洲 902-928MHz ISM 頻段... 55

10 B類模式的上行資料幀... 56

11 下行Ping幀格式（B類）... 56

11.1 實體層幀格式... 56

11.2 單點傳播群組播MAC消息... 56

12 信标捕獲和追蹤... 58

12.1 最小無信标操作時間... 58

12.2 建立在接收上的無信标操作擴充... 59

12.3 時間漂移最小化... 59

13 B類下行時隙時間... 59

13.1 定義... 59

13.2 随機時隙... 61

LoRaWAN1.0.1_d3. 63

LoRaWAN Specification 1R0. 64

協定格式整理... 64

7. 重傳退化（Retransmissions back-off）... 65

LoRaWAN 規範 1.0 （2~4章）

聲明

本文翻譯版本已更新至LoRaWAN 1.0.2，同時修正了一些錯誤，與初始版本相比有些内容變動較大。

請注意本文中的帶上标的引用、說明

2 LoRaWAN 簡介

LoRaTM 是由Semtech開發的一種遠距離、低功耗、低速率的無線射頻技術。本文檔中，将具有比A類更多功能的裝置統一稱為 “高類終端裝置”。

原文： 

Devices implementing more than Class A are generally named “higher Class end-devices” in this document.

2.1 LoRaWAN Classes

終端雙向通信（A類）

A類的終端裝置每次發送資料後會打開兩個持續時間很短的接收視窗來接收下行資料，終端裝置通過這種方式實作雙向通信。傳輸時間間隔等于終端裝置基礎的時間間隔加上一個随機時間（ALOHA類型協定）。對終端裝置來說，A類是功耗最低的系統，隻有在發送資料後的一小段時間内接收處理伺服器發送來的資料。伺服器在其它所有時間上的下行資料必須等待節點下一次發送資料才可以下發。

通過随機時間對間隔進行微調來實作随機通路，讓所發送者平等、自由地競争信道的使用權。

低功耗，先發送後接收，發送和接收交替進行。終端隻有在發送資料後才能接收處理伺服器發送來的資料，發送資料不受接收資料的影響。收發比=1：1

具有接收時隙的終端雙向通信（B類）

B類終端裝置允許更多的接收視窗。在A類接收視窗的基礎上B類裝置還會在特定的時刻打開更多的接收視窗。而為了保證終端裝置能夠在特定的時間打開接收視窗，它會從網關接收信标來完成時間同步。這樣伺服器也就可以獲知終端裝置的所有接收視窗的時刻。

同樣是先發送後接收，不同的是每次發送後按照一定時間間隔啟動接收視窗，接收多條資料。時間間隔從網關擷取，以便伺服器知曉終端接收消息的時刻。收發比=1：N

最大接收時隙的終端雙向通信（C類）

C類終端裝置的接收視窗，除了在發送資料的時候關閉外一直處于打開狀态。C類終端功耗比A類和B類都大，但對于和伺服器之間的互動來說延遲也最低。

打開接收視窗的時間間隔很小，幾乎不間斷的接收消息。比A和B更耗能，但和伺服器互動的延遲低。

　2.2 規範

進階類的附加功能向下相容低級類。所有LoRaWAN終端必須實作A類的功能。

注意：

本規範手冊中：實體消息格式、MAC消息格式以及A類和其它進階類都具備的東西，隻在本手冊的A類部分介紹。

3 實體層消息格式

LoRa中用來區分上行和下行消息。 

3.1 上行鍊路消息

上行鍊路消息由終端發送經過一個或多個網關中轉後到達伺服器1。

它使用的LoRa無線分組顯性模式由實體頭（PHDR）和它的CRC（PHDR_CRC）校驗組成。由CRC保證荷載資料的一緻性（發送和接收的資料完全一緻，不僅僅是資料完整）。

Uplink PHY:

3.2 下行鍊路消息

下行鍊路消息由伺服器發送給終端裝置，每條消息對應的終端裝置是唯一确定的，而且隻通過一個網關2轉發。

下行鍊路消息由實體頭（PHDR）和這個頭的CRC（PHDR_CRC）組成3。

下行鍊路消息：

3.3 接收視窗

裝置終端每次發送資料完成後打開兩個收視窗。以資料發送結束作為基準進行計算接收視窗的開啟時間。

發送           |                             |                 RX1                                |                 RX2      

|<-                --------------------->|<--------------------------->|                           |      

|                        |<-                ------------------------------------------------------>|      

RECEIVE_DELAY2      

3.3.1 第一個接收視窗的開啟、使用的信道和資料速率

第一個接收視窗(RX1)使用的頻率、資料速率與上行傳輸時使用的頻率、資料速率存在映射關系。RX1在發送完成後第

RECEIVE_DELAY1

秒（+/- 20 毫秒）開啟。并且收發資料使用的資料速率和地域有關，詳情資料在文檔《LoRaWAN 區域相關參數手冊》（LoRaWAN Regional Parameters document）。預設情況下第一個接收視窗資料速率和最後一次發送資料時使用的速率相同。

3.3.2 第二個接收視窗的開啟、使用的信道和資料速率

第二個接收視窗RX2使用經過修正的可配置的 經過配置的固定的 頻率和資料速率。RX2在發送完成後第

RECEIVE_DELAY2

秒（+/- 20 毫秒）開啟。頻率和資料速率可以通過MAC指令修改（見第5章）。預設的頻率和資料速率與地域相關，詳情資料在文檔《LoRaWAN 區域相關參數手冊》（LoRaWAN Regional Parameters document）。

3.3.3 接收視窗持續時間

接收視窗的最短時間必需滿足：終端裝置的無線收發器能夠處理完下行資料的前導碼。

3.3.4 接收期間接收者的活動

無線電接收器在某個接收視窗檢測到相應的前導碼後會繼續接收，直到下行資料幀全部解調完畢。如果在第一個接收視窗檢測并完成解調，同時通過檢查位址（伺服器配置設定的位址）和MIC，确認該幀屬于本節點，終端裝置不再打開第二個接收視窗。

3.3.5 伺服器給終端裝置發送消息

伺服器必需要十分精确的在這兩個接收視窗的時間點上發送資料終端裝置才能收到。

3.3.6 接收視窗相關的重要事項

上一次發送結束後，在沒有收到資料或者第二個沒有關閉前，不能再次發送。

3.3.7 其它協定資料的收發

節點可以通過LoRaWAN收發視窗監聽或傳輸其它協定，或者做任何傳輸。收發其它協定或者在LoRaWAN收發視窗之間傳輸任何資料。 不過，終端裝置仍然要遵守當地法律法規并且遵循LoRaWAN規範。

4 MAC 消息格式

LoRa所有的上下行鍊路消息都會包含PHY負載（Payload），該負載以單位元組MAC頭（MHDR）為開始，MAC頭後面是MAC負載(MACPayload)4，結尾是4位元組的消息一緻碼（MIC）。

4.1 MAC 層 (PHYPayload)

大小（位元組）	1	1..M	4
PHYPayload	MHDR	MACPayload	MIC

MACPayload字段長度M的最大值與區域有關，詳細見第六章。

4.2 MAC 頭 (MHDR 字段)

第幾位(Bit)	7..5	4..2	1..0
MHDR	MType	RFU	Major

MAC 頭（MHDR）的 MType 表示消息類型；Major 表示LoRaWAN主版本号，指明幀格式所遵循的編碼規則。

4.2.1 消息類型 (MType 字段)

LoRaWAN自定義了六個不同的MAC消息類型：join request, join accept, unconfirmed data up/down, 以及 confirmed data up/down。

MType	說明	備注
000	Join Request	請求入網，無線激活過程使用，具體見章節6.2
001	Join Accept	同意入網，無線激活過程使用，具體見章節6.2
010	Unconfirmed Data Up	無需确認的上行消息，接收者不必回複
011	Unconfirmed Data Down	無需确認的下行消息，接收者不必回複
100	Confirmed Data Up	需要确認的上行消息，接收者必須回複
101	Confirmed Data Down	需要确認的下行消息，接收者必須回複
110	RFU	保留
111	Proprietary	用來實作自定義格式的消息，互動的裝置之間必須有相同的處理邏輯，不能和标準消息互通

4.2.1.1 請求入網和同意入網

請求入網和同意入網的消息在OTA激活過程中使用，具體見章節6.2

這裡翻譯成請求入網和同意入網，節點發送資料的動作會在下面翻譯成 入網請求。

4.2.1.2 資料

消息資料既可以傳輸MAC指令也可以傳輸應用資料，甚至可以一起發送。接收者對需要确認的消息 （confirmed-data message） 必須做出回複，而對于 不需要确認的消息（unconfirmed-data message）則不需要對其回複5。私有消息（或者說專有消息，指使用者自定義的消息，英文：Proprietary messages）用來實作 非标準 的消息，不能與标準協定格式互通，但裝置之間要都能了解這些私有擴充。

不同消息類型用不同的方法保證一緻性，下面會介紹這一點。

4.2.2 主版本号（Major 字段)

Major bits	說明
00	LoRaWAN R1
01..11	保留（RFU）

注意：

主版本号指明激活過程中使用的消息格式（章節6.2）和MAC Payload前4位元組（第4章）。終端要為每個不同的主版本号實作不同子版本的消息格式。終端使用的 主版本号 子版本号應當提前作為其它消息的一部分捎帶發送給網絡伺服器,如，作為裝置個性化資訊的一部分。

(e.g., as part of the device personalization information).

4.3 MACPayload

MAC 荷載，也就是所謂的“幀資料”，包含：幀頭（FHDR）、端口（FPort）以及幀荷載(FRMPayload），其中端口和FRMPayload可配置（可變）。

4.3.1 幀頭(FHDR)

FHDR由終端短址（DevAddr）、1個幀控制位元組（FCtrl）、2位元組的幀計數器（FCnt）以及用來傳輸MAC指令的配置字段（FOpts）組成，FOpts最多15個位元組。

FCnt 下面章節有詳細說明

大小（位元組）	4	1	2	0…15
FHDR	DevAddr	FCtrl	FCnt	FOpts

下行 資料幀幀頭的FCtrl結構如下：

第幾位	7	6	5	4	[3..0]
FCtrl	ADR	RFU	ACK	FPending	FOptsLen

上行 資料幀幀頭的FCtrl結構如下：

第幾位	7	6	5	4	[3..0]
FCtrl	ADR	ADRACKReq	ACK	RFU	FOptsLen

4.3.1.1 幀頭中的資料速率自适應控制 (FCtrl中的ADR, ADRACKReq )

LoRa網絡允許終端裝置逐一使用所有可用的資料速率。LoRaWAN協定根據該特性對靜态終端6的資料速率進行調整優化，這就是資料速率自适應(ADR)。ADR可用時，網絡會對速率進行優化，使其使用的資料速率盡可能快。

當無線電信道持續、快速地衰減時，資料速率自适可能無法使用。當網絡不能控制裝置資料速率時，裝置的應用層就要對其進行控制。建議這種情況下最好把所有資料速率都嘗試一下。應用層應該一直嘗試在給定網絡條件下，使空中時間總耗時最少。

如果ADR設定為1，伺服器可以通過MAC指令控制裝置的資料速率。如果ADR設定為0，無論接收的信号的品質如何，伺服器都不對終端的資料速率做任何調整。由終端裝置或網絡決定是否使用該位。不過，隻要條件允許就應該開啟ADR，這樣可以延長終端的電池壽命、充分利用網絡帶寬。

注意：

哪怕移動終端在大多數時間下都是不移動的。是以終端可以根據它自己移動狀态請求網絡通過ADR進行資料速率優化。

如果終端的資料速率經過網絡優化比最低速率大，那節點就要定期檢查保證伺服器仍然能夠收到上傳的資料。 終端上行的幀計數器每遞增一次（重傳時計數器不遞增）的同時，裝置的 ADR_ACK_CNT 計數器也遞增。如果 ADR_ACK_LIMIT (ADR_ACK_CNT >= ADR_ACK_LIMIT)次上行之後沒有收到下行回複，就會設定 ADR 請求響應位（将ADRACKReq 設為1）。此時要求網絡在接下來的 ADR_ACK_DELAY 次上行之内做出響應，在任何一次上行後收到下行資料，節點都會重置計數器 ADR_ACK_CNT。在此期間的下行資料不需設定ACK位，因為終端在等待接收期間收到任何應答都表示網關還能接收來自該裝置的上行資料。如果在接下來 ADR_ACK_DELAY 次之内（比如：總共發送次數 ADR_ACK_LIMIT + ADR_ACK_DELAY）沒有收到回複，就切換到更低的資料速率上，以獲得更遠的射頻傳輸距離，并重複上述過程7。終端裝置每達到 ADR_ACK_DELAY 就會再次降低自己的資料速率。如果裝置正在使用預設的資料速率就不再設定 ADRACKReq ，這種情況下傳輸距離已經最大，任何操作都不會有改善。

注意：

不要求網絡立刻回複 ADR 請求，要給網絡留出足夠的反應時間，以便網絡給出最佳的下行鍊路的排程方案。

注意：

上行傳輸時，如果 ADR_ACK_CNT >= ADR_ACK_LIMIT 并且目前資料速率比裝置的最小資料速率高，才會設定 ADRACKReq 位，其它情況下不需要。

4.3.1.2 消息确認位和确認流程 (FCtrl中的ACK)

收到confirmed類型的消息時，接收者要回複一條設定了确認位的消息（ACK 設為1）。如果發送者是終端，網絡就把确認消息發送到該終端打開的接收視窗。如果發送者是網關，确認消息的發送由終端就自行判斷。

确認消息隻會在收到消息以後作為響應發送，并且不重發。

注意：

終端處理越簡單越好、狀态越少越好，是以裝置收到需要确認的消息後要立刻回複，回複的消息要簡明扼要（最好發空消息）。回複也可以延緩，放到下一條正常消息裡面一起發送。

筆記：

這就是說Confirmed消息單獨的回複隻能是Unconfirmed，同時設定ACK标記。和正常消息一起發送的話沒有限制。

4.3.1.3 重傳機制

如果終端裝置發送一條需要确認的消息後沒有收到響應，終端就會重新發送這條消息。不同裝置間的消息重傳的次數以及傳輸的時間可能不同。

注意：

第18章給出了确認機制的時序圖

注意：

如果裝置重傳次數到限制後仍然沒收到确認消息，就會降低自身的資料傳輸速率來增加傳輸距離，并再次嘗試連接配接。該消息是再次重傳還是丢棄該消息繼續運作，由終端自己決定。

注意：

如果網絡伺服器重傳次數達到限制後仍然沒有收到确認消息，在沒有收到裝置的消息之前會認為無法與終端建立連接配接（終端不可達）。該消息的重傳或者放棄是由伺服器決定的。

注意：

上面提到的重傳期間的資料速率回歸機制在18.4有詳細介紹

4.3.1.4 幀挂起位 (FPending in FCtrl, downlink only)

幀挂起位（FPending）隻在下行互動中使用，表示網關還有資料挂起等待下發。此時要求終端盡快發送上行消息來再打開接收視窗。

FPending的詳細用法在18.3章。

4.3.1.5 計數器 (FCnt)

每個終端有兩個計數器：上行鍊路計數器（FCntUp），其值的增加由終端控制，從終端發往伺服器；下行鍊路計數器（FCntDown），其值的增加由伺服器控制，從伺服器發往終端。網絡伺服器記錄上行幀，并且為每個節點建立下行計數器。一次 JoinReq – JoinAccept 消息交換之後，或者個性化的終端裝置8重置之後，終端裝置上的計數器9以及網絡伺服器上該終端裝置對應的計數器都會重置為0。之後每次其中一方發送一條新的資料幀，發送方所控制的 FCntUp 或 FCntDown 就會加1。接收方對應的計數器在檢查通過後則會與之保持同步。在考慮到計數器復原的情況下，如果收到的增加過的計數器與本地現有計數器的值之差小于指定的值 MAX_FCNT_GAP10，則檢查通過；如果兩者之差大于 MAX_FCNT_GAP 就表示丢失了過多的資料包，（該資料幀）随後被丢棄11。不需要确認的幀多重傳輸（見參數 NbTrans 的說明）時，或者需要确認的幀沒有收到确認回執時，這兩種情況下FCnt不會增加。

筆記：

上行鍊路計數器（FCntUp），由終端産生并維護，記錄發往伺服器的幀數量；下行鍊路計數器（FCntDown），由伺服器産生并維護，記錄伺服器發往終端的幀數量。

筆記：

原文中說了 計數器之差MAX_FCNT_GAP和小于MAX_FCNT_GAP的情況怎麼處理，沒有說明等于的情況怎麼處理。不過通過閱讀節點源代碼可以知道，等于的情況與小于的情況處理方式相同，即分為 

=< MAX_FCNT_GAP

 和 

> MAX_FCNT_GAP

兩種情況。但是為了尊重原文，在這裡做出說明而不在原文譯文中改動。

LoRaWAN的幀計數器可以是16位（2位元組），也可以是32位（4位元組）。指定終端裝置需要通過帶外資料12通知網絡端裝置自己使用的幀計數器的位寬。如果使用 16位幀計數器， FCnt字段可以直接當做計數器的值，有需要的話可以通過在前面填充0（值為0）位元組來擴充。如果使用 32-bits 幀計數器，FCnt字段對應32位計數器的16個最低有效位（換句話說，FCntUp用來發送上行資料幀，FCntDown用來發送下行資料幀）。

應用會話密鑰和網絡會話密鑰不變的情況下，除重傳外，終端裝置不能重複使用同一個FCntUp。

注意：

由于 FCnt 是32位幀計數器中16個最低有效位的值，是以伺服器必須通過觀察資料互動來自己推斷幀計數器的16個最高有效位。

4.3.1.6 幀配置 (FOptsLen in FCtrl, FOpts)

幀配置長度（FOptsLen）字段位于幀的 FCtrl 部分，表示FOpts的實際長度。FOpts字段用來傳輸MAC指令，最長15位元組，可以為空。一系列MAC指令的詳細解釋在第5章。

如果FOptsLen=0，FOpts為空。如果 FOptsLen≠0 ，即MAC指令放在FOpts字段，端口号不能為0（FPort要麼為空，要麼是一個非零值）。

MAC指令不能同時出現在FRMPayload和FOpts中，萬一出現了，裝置應丢掉該幀資料。

4.3.2 端口（FPort）

幀負載資料（FRMPayload）不為空的時候端口号也不能是空。此時FPort=0表示FRMPayload中隻有MAC指令（詳情見章節4.4）。1…223（0x01…0xDF）範圍内的FPort由應用指定； FPort = 224 專門為LoRaWAN Mac層測試協定服務。

注意：

FPort = 224

 的目的是：專門用來通過無線方式在最終版本的終端裝置上進行Mac方案的合理性測試，進而在實際場景中不必依賴于特定測試版本的裝置。測試和正常操作不能同時進行，但該Mac層實作屬于裝置正常應用。測試協定使用AppSKey加密，這樣可以保證在裝置擁有者沒有參與的的情況下，網絡無法擅自開啟裝置的測試模式。如果在已經連接配接到正常網絡的裝置上運作測試，而網絡側的 測試應用 通過這種方式擷取到AppSKey，這就不屬于LoRaWAN協定的範圍了。如果在專門的測試平台（不是正常網絡）上通過OTAA進行測試，并且為了保證入網成功将AppKey告訴了測試平台，這也不屬于協定範圍。

原文： 

The purpose of Fport value 224 is to provide a dedicated Fport to run Mac compliance test scenarios over-the-air on final versions of devices, without having to rely on specific test versions of devices for practical aspects. The test is not supposed to be simultaneous with live operations, but the Mac layer implementation of the device shall be exactly the one used for the normal application. The test protocol is normally encrypted using the AppSKey. This ensures that the network cannot enable the device’s test mode without involving the device’s owner. If the test runs on a live network connected device, the way the test application on the network side learns the AppSkey is outside of the scope of the LoRaWAN specification. If the test runs using OTAA on a dedicated test bench (not a live network), the way the Appkey is communicated to the test bench, for secured JOIN process, is also outside of the scope of the specification.

225..255 (0xE1..0xFF)保留，以便未來對标準化應用進行擴充。

大小（Bytes）	7..22	0..1	0..N
MACPayload	FHDR	FPort	FRMPayload

N是FRMPayload的位元組數，N的取值範圍見LoRaWAN 區域性參數手冊。

N的範圍：

N≤M−1−length(FHDR)

其中M是MACPayload的最大長度。

length(FHDR)

是FHDR的位元組長度。

4.3.3 MAC 幀負載據加密（FRMPayload）

如果幀資料中包含payload，要先對FRMPayload進行加密，再計算消息的一緻性校驗碼（MIC）。

加密方案使用基于IEEE 802.15.4/2006 Annex B [IEEE802154] 的AES加密，秘鑰長度128位。

使用哪種加密秘鑰K取決于消息的FPort：

FPort	K	備注
NwkSKey	網絡密鑰
1..255	AppSKey	應用密鑰

加密字段： 

pld = FRMPayload

采用分組加密，算法為每條消息資料定義一個塊的序列,序列分為 k 塊，

k=ceil(len(pld)/16)

（向上取整），每組用Ai表示，i=1…k，每塊結構如下：

位元組數	1	4	1	4	4	1	1
Ai	0x01	4 × 0x00	Dir	DevAddr	FCntUp 或 FCntDown	0x00	i

方向（Dir）字段：上行幀為0，下行幀為1 

對Ai加密，得到S的塊隊列Si：

通過分割對payload進行加解密：

4.4 消息一緻性校驗碼 (MIC)

對整個消息的所有字段進行計算（AES簽名算法CMAC）得到消息一緻性校驗碼（MIC）。

msg          =                 MHDR | FHDR | FPort | FRMPayload      

• • 1
  • 1

其中 

len(msg)

 表示消息的位元組長度。

MIC算法參考RFC4493：

B0 定義如下：

大小（位元組）	1	4	1	4	4	1	1
B0	0x49	4 × 0x00	Dir	DevAddr	FCntUp 或 FCntDown	0x00	len(mgs)

方向（Dir）字段：上行幀為0，下行幀為1

本文翻譯版本已更新至LoRaWAN 1.0.2。

5 MAC Commands

網絡管理時會在網絡伺服器和終端MAC層之間傳輸一系列MAC指令。MAC層指令對應用、應用伺服器以及終端裝置上的應用永不可見。

一幀資料中可以包含任何MAC指令序列，MAC指令既可以放在FOpts中和正常資料一起發送；也可以放在FRMPayload中單獨發送，此時FPort = 0，但不能同時在兩個字段攜帶MAC指令。放在FOpts中的MAC指令不加密，并且不能超過15個位元組。放在FRMPayload中的MAC指令必須加密，同時不能超過FRMPayload的最大長度。

注意：

不想被别人截獲破解的指令要放到FRMPayload中單獨發送

一條MAC指令由一個位元組的指令ID（CID）和特定的指令序列組成，指令序列可以是空。

CID	命 令	終端發送	網關發送	簡介
0x02	LinkCheckReq	×	用于終端驗證網絡連接配接
0x02	LinkCheckAns	×	回應驗證請求， 同時包含終端接收品質相關的估算的信号功率
0x03	LinkADRReq	×	請求終端改變資料率、傳輸功率、接收率或者信道
0x03	LinkADRAns	×	LinkRateReq的應答
0x04	DutyCycleReq	×	設定裝置的最大總發射占空比
0x04	DutyCycleAns	×	DutyCycleReq的應答
0x05	RXParamSetupReq	×	設定接收時隙相關參數
0x05	RXParamSetupAns	×	RXSetupReq的應答
0x06	DevStatusReq	×	請求終端狀态
0x06	DevStatusAns	×	傳回終端裝填，即電量和解調情況
0x07	NewChannelReq	×	建立或修改無線電信道
0x07	NewChannelAns	×	NewChannelReq的應答
0x08	RXTimingSetupReq	×	設定接收時隙的時間
0x08	RXTimingSetupAns	×	RXTimingSetupReq的應答
0x09	TxParamSetupReq	x	網絡伺服器用它來設定終端裝置停留時間的最大值和最大EIRP（等效全向輻射功率），與地域相關
0x09	TxParamSetupAns	x	TxParamSetupReq指令的回複
0x0A	DlChannelReq	x	通過将下行頻率與上行頻率進行偏移，來修改下行R1的無線信道（即：建立不對稱信道）
0x0A	DlChannelAns	x	DlChannelReq指令的回複
0x80 ~ 0xFF	Proprietary	×	×	保留指令

注：

MAC指令長度不固定，這就要求MAC指令執行端必須隐式獲知。因為無法忽略不明的MAC指令，而且一旦遇到不明的MAC指令，就會導緻處理MAC指令隊列的程序終止。是以，建議遵循首先對MAC指令進行說明的LoRaWAN規範。這樣的話，所有目前版本LoRaWAN規範中實作的MAC指令都可以被更高版本的規範相容處理。

注：

終端裝置所有被網絡伺服器調整過的内容（例如：RX2，新建立或調整過的信道）僅在下次入網前有效。是以，終端裝置每次重新入網之後都會使用預設參數配置，而網絡伺服器則根據需要對這些值重新調整。

5.1 鍊路檢查 （LinkCheckReq和LinkCheckAns）

終端使用LinkCheckReq指令檢查與網絡的連通性，該指令不含荷載（payload）。

網絡伺服器收到（一個或多個）網關轉發過來的LinkCheckReq後回複一條LinkCheckAns指令。

大小(位元組)	1	1
LinkCheckAns Payload	Margin	GwCnt

Margin（解調餘量）是最近一條被成功收到的 

LinkCheckReq

 指令的鍊路預算（機關

dB

），是一個8位（bits）無符号整型，範圍 [0,254]。值為 

 表示在解調的下限（0dB或者沒有餘量）上收到了資料，值

20

表示網關在比解調下限高出 

20 dB

 的信号強度上收到了資料。

255

是保留值。

GwCnt是最近一次成功收到 

LinkCheckReq

 的網關的數量。

link margin參考：Link margin

5.2 速率自适應 

LinkADRReq

和

LinkADRAns

網絡伺服器通過發送 

LinkADRReq

 指令對終端裝置速率進行調整。

大小(位元組)	1	2	1
LinkADRReq Payload	DataRate_TXPower	ChMask	Redundancy

大小(位 bits)	[7:4]	[3:0]
DataRate_TXPower	DataRate	TXPower

資料速率（DataRate）以及TX輸出功率（TXPower）和地理區域相關，參考《LoRaWAN地域相關參數手冊》（《LoRaWAN Regional Parameters document》）。指令中的TX輸出功率指的是裝置可以使用的最大發射功率。指定一個能夠使用的比目前在使用的更高的功率的指令執行成功後，此時，終端裝置将使用盡可能大（不超過指令設定以及實體允許的範圍）的功率回複确認消息。信道掩碼（ChMask）通過對最低有效位相應的位置填

來對上行信道的可用性進行編碼，信道清單如下：

對應原文： 

An end-device will acknowledge as successful a command which specifies a higher transmit power than it is capable of using and should, in that case, operate at its maximum possible power.

表5：信道狀态表

第幾位	可用信道
Channel 1
1	Channel 2
..	..
15	Channel 16

ChMask中某位是

1

，表示啟用該位對應的上行信道（用來進行上行傳輸的信道），隻有終端裝置目前使用的資料速率可以在該信道上使用時，該信道才可以使用;如果是

，則表示對應的上行信道不可用。終端裝置目前使用的信道要設為

1

第幾位	7	[6:4]	[3:0]
Redundancy bits	RFU	ChMaskCntl	NbTrans

備援（Redundancy）位中，NbTrans表示每條上行消息重複發送的次數，僅用于 

unconfirmed

 類型的上行消息。預設值為

1

，表示每幀隻上傳一次。有效範圍 [1:15]。終端裝置收到NbTrans == 0時仍然使用預設值。網絡管理者通過控制節點的上行備援來保證給定的服務品質。終端裝置在重傳期間照常跳頻，每次重傳後也會等待接收資料，直到接收視窗過期。在RX1短暫視窗期間的任一時刻接收到下行消息都會停止該消息的重傳。對于A類來說，RX2情況與RX1相同。

信道掩碼控制（ChMaskCntl）字段負責控制ChMask的掩碼位。當網絡上信道的實作超過16個，該字段必須是一個非0值。用它來控制ChMask使用哪16個信道，還可以用它來全局性的打開或關閉指定調制方式的所有信道。該字段的具體使用和地域相關，具體見《LoRaWAN地域相關參數手冊》。

網絡伺服器可能會在一條下行消息中包含多個LinkAdrReq指令。終端裝置為了配置信道掩碼，會按照指令在下行消息中的出現的順序處理所有LinkAdrReq消息。對于指令中的這些ChMaskCntl，終端裝置要麼全部接受要麼全部拒絕，同時為它們的 LinkAdrAns 設定相同的 Channel Mask ACK。對于 DataRate、TXPower 和 NbTrans ，因為它們是全局性設定（後面的值會覆寫前面的值），是以終端裝置隻按照指令中的最後一條LinkADRReq執行。同樣，對于這些，終端裝置也會為它們在 LinkAdrAns 中各自設定相同的 ACK，來指明它們最終被接受了還是被拒絕了。

信道頻率與地域有關，具體見第六章。

終端收到 

LinkADRReq

 後回複 

LinkADRAns

 指令。

大小（位元組）	1
LinkADRAns Payload	Status

大小（位）	[7:3]	2	1
Status bits	RFU	Power ACK	Data rate ACK	Channel mask ACK

LinkADRAns Status釋義如下：

表6：

LinkADRAns

狀态位定義

字段	1
Channel mask ACK	要使用的信道未定義；或信道掩碼想關閉所有信道。忽略該指令，終端狀态不改變	設定成功
Data rate ACK	要使用的速率未定義；或者在指定的通道掩碼下，不支援該資料速率（所有在用的信道都不支援該速率）。指令被忽略，終端狀态不改變	設定成功
Power ACK	終端未定義該功率等級。指令被忽略，終端狀态不改變	設定成功

以上三個字段任意一個是0，指令就會執行失敗，節點保持之前的狀态不變。

5.3 終端的發射占空比（

DutyCycleReq

 和 

DutyCycleAns

）

DutyCycleReq

，網絡協調員使用該指令來限制終端裝置的總發射占空比的最大值。總發射占空比指所有子頻帶的發射占空比。

大小（位元組）	1
DutyCycleReq Payload	DutyCyclePL

Bits	7:4	3:0
DutyCyclePL	RFU	MaxDCycle

終端允許的發射占空比的最大值：

總發射占空比=12MaxDCycle

MaxDutyCycle有效範圍[0:15]。在沒有區域調節設定占空比限制的情況下，使用 

 表示“占空比沒有限制”，有區域限制的除外。

注意，下面這條在LoRaWAN1.0.2中被删除：

值為 

255

 時要求終端裝置立刻轉為靜默狀态，等價于遠端關閉終端。

終端收到DutyCycleReq後回複DutyCycleAns， DutyCycleAns不包含任何payload。

5.4 接收視窗相關參數 (

RXParamSetupReq

,

RXParamSetupAns

)

通過下發RXParamSetupReq指令，可以修改第二個接收視窗（RX2）使用的頻率和資料速率。該指令還可以修改下行

RX1

資料速率，使下行

RX1

的速率相對上行進行偏移。

大小（位元組）	1	3
RX2SetupReq Payload	DLsettings	Frequency

第幾位	7	6:4	3:0
DLsettings	RFU	RX1DRoffset	RX2DataRate

RX1DRoffset 用來設定終端裝置上行和下行第一個接收視窗（RX1）資料速率之間的偏移，預設值是

。基站在某些地域有最大功率密度限制，是以使用偏移，并且還可以用來均衡上行和下行的無線鍊路預算。

RX2DataRate 定義第二個接收視窗使用的資料速率，用法和 LinkADRReq 一樣（例如，

 表示

DR0/125kHz

）。Frequency 是第二個接收視窗使用的信道頻率，其頻率編碼規則的定義見NewChannelReq 指令。

終端裝置回複 RXParamSetupAns。終端裝置在沒有收到基于A類的下行資料前，會在所有上行資料的 FOpt 中攜帶 RXParamSetupAns，直到收到一次基于A類的下行資料。這樣可以保證及時上行鍊路存在丢包的情況，網絡也總能知道終端裝置使用的下行鍊路參數。

其

payload

隻有一個位元組：

大小（位元組）	1
RX2SetupAns Payload	Status

Status位結構如下：

第幾位	7:3	2	1
Status bits	RFU	RX1DRoffset ACK	RX2 Data rate ACK	Channel ACK

表 7: RX2SetupAns 的 status 含義

字段	1
Channel ACK	（對于終端）頻率不可用	RX2 信道設定成功
RX2 Data rate ACK	（對于終端）未知的資料速率	RX2 資料速率設定成功
RX1DRoffset ACK	RX1 上行/下行資料速率的偏移不在可用範圍	設定成功

3個中的任何一個是

，指令都會執行失敗并保持之前的狀态。

5.5 終端狀态（

DevStatusReq

, 

DevStatusAns

）

伺服器通過發送 DevStatusReq 擷取一個終端裝置的狀态，該指令沒有payload。終端收到DevStatusReq 之後回複DevStatusAns。

大小（位元組）	1	1
DevStatusAns payload	Battery	Margin

電池電量（Battery）上報的資料編碼如下：

表8：電池電量編碼

電量	說明
終端在使用外接電源
1..254	電池電量，1是最小值，254是最大值
255	終端裝置無法擷取電池電量

餘量（Margin）是最近一次接收成功 DevStatusReq 指令的解調信噪比，其值（四舍五入）取整，機關dB。餘量值是一個有符号整型，長度6個比特位，最小值 -32，最大值31。

占位（bits）	7:6	5:0
Status	RFU	Margin

5.6 建立或修改信道（

NewChannelReq

, 

NewChannelAns

）

NewChannelReq指令要麼用來修改已有信道的參數，要麼建立一個新的信道。該指令設定新信道的中心頻率，以及在該信道上行傳輸的資料速率範圍。

大小（位元組）	1	3	1
NewChannelReq payload	ChIndex	Freq	DrRange

信道索引（ChIndex）是新信道或者待修改信道的索引值。LoRaWAN規範中已經為不同的地域和頻段内置了預設信道，這些信道存在所有的裝置上，而且不能通過NewChannelReq（見第6章）進行修改。如果預設的信道數量是N，那預設的信道就是 

0 ~ N-1

，而 ChIndex 可用範圍就是

N ~ 15

。終端裝置至少要能處理 16 個不同的信道。在某些地域終端允許存儲超過16個信道。

頻率（Freq）是一個 24bits 無符号整型，實際信道頻率是 100 × Freq Hz（筆記：按這個說法，433.1MHz 伺服器發送的資料是 4331000），其中100MHz以下的值留待未來使用。通過這種方法可以以 100 Hz為步長，使用 100MHz~1.67GHz 之間任意的信道頻率。 Freq == 0表示不使用該信道。終端裝置必須對頻率進行檢查，保證它的射頻硬體支援将要使用的頻率，否則傳回錯誤。

資料速率範圍（DrRange）指明此信道的資料速率範圍。該字由兩個4位長的索引組成：

大小（bits）	7:4	3:0
DrRange	MaxDR	MinDR

根據章節5.2的定義，最小資料速率（MinDR）字段指定此信道最低資料速率，例如：0 表示指定 DR0/125 kHz。與之類似，最大資料速率指定最高資料速率。例如：

DrRange = 0x77

表示信道隻能使用 50kbps GFSK，

DrRange = 0x50

表示資料速率範圍是DR0 / 125 kHz 到 DR5 / 125 kHz。

建立或修改的信道一旦設定成功，可以馬上用來通信。

RX1

的下行頻率與其上行頻率相同。

終端回複

NewChannelAns

指令，其payload如下：

大小（位元組）	1
NewChannelAns Payload	Status

狀态（Status）含義如下：

大小（bits）	7:2	1
Status	RFU	Data rate range ok	Channel frequency ok

字段	1
Data rate range ok	資料速率範圍超出終端目前所允許的範圍	終端相容該資料速率範圍
Channel frequency ok	終端無法使用該頻率	可以使用

兩者之中有一個是0，就表示指令執行失敗，不會建立信道。

DlChannelReq允許伺服器将一個不同的下行頻率和

RX1

關聯起來。所有支援 NewChannelReq的地域也适用于 DlChannelReq （比如歐洲、中國，但美國和澳洲不可以，具體見《LoRaWAN地域相關參數》）

該指令會設定下行RX1的中心頻率：

大小（位元組）	1	3
DlChannelReq Payload	ChIndex	Freq

頻率（Freq）是一個 24bits 無符号整型，實際信道頻率是 100 × Freq Hz，其中100MHz以下的值留待未來使用。通過這種方法可以以 100 Hz為步長，使用 100MHz~1.67GHz 之間任意的信道頻率。 Freq == 0表示不使用該信道。終端裝置必須對頻率進行檢查，保證它的射頻硬體支援将要使用的頻率，否則傳回錯誤。

終端裝置回複DlChannelAns。終端裝置在沒有收到下行資料前，會在所有上行資料的 FOpt 中攜帶 DlChannelAns，直到收到一次下行資料。這樣可以保證及時上行鍊路存在丢包的情況，網絡也總能知道終端裝置使用的下行頻率。

Payload包含以下資訊：

大小（位元組）	1
DlChannelAns Payload	Status

Status含義如下：

Bits	7:2	1
Status	RFU	Uplink frequency exists	Channel frequency ok

1
Channel frequency ok	裝置無法使用該頻率
Uplink frequency exists	該信道的上行頻率未定義，下行頻率隻能給有效上行頻率的信道設定

5.7 Rx和Tx之間的延遲（

RXTimingSetupReq

,

RXTimingSetupAns

）

RXTimingSetupReq用來配置上行傳輸結束（一幀資料發送完成的時刻）到打開第一個接收視窗之間的時間間隔。第二個接收視窗比第一個晚1秒打開。

大小（位元組）	1
RXTimingSetupReq Payload	Settings

延遲（Delay）字段指定時間間隔，由兩個4位的索引組成：

大小（bits）	7:4	3:0
Settings	RFU	Del

延遲機關是秒（s），Del=0 表示1秒：

Del	延遲(秒)
1
1	1
2	2
3	3
…	…
15	15

終端裝置回複RXTimingSetupAns，并且不攜帶payload。

終端裝置在沒有收到下行資料前，會在所有上行資料的 FOpt 中攜帶 RXTimingSetupAns，直到收到一次下行資料。這樣可以保證及時上行鍊路存在丢包的情況，網絡也總能知道終端裝置使用的下行參數。

5.7 Rx和Tx之間的延遲（

RXTimingSetupReq

,

RXTimingSetupAns

）

RXTimingSetupReq用來配置上行傳輸結束（一幀資料發送完成的時刻）到打開第一個接收視窗之間的時間間隔。第二個接收視窗比第一個晚1秒打開。

大小（位元組）	1
RXTimingSetupReq Payload	Settings

延遲（Delay）字段指定時間間隔，由兩個4位的索引組成：

大小（bits）	7:4	3:0
Settings	RFU	Del

延遲機關是秒（s），Del=0 表示1秒：

Del	延遲(秒)
1
1	1
2	2
3	3
…	…
15	15

終端裝置回複RXTimingSetupAns，并且不攜帶payload。

終端裝置在沒有收到下行資料前，會在所有上行資料的 FOpt 中攜帶 RXTimingSetupAns，直到收到一次下行資料。這樣可以保證及時上行鍊路存在丢包的情況，網絡也總能知道終端裝置使用的下行參數。

5.8 終端發射參數(TxParamSetupReq,TxParamSetupAns)

該MAC指令隻在需要監管的區域執行，參考《LoRaWAN地域相關參數手冊》。

TxParamSetupReq指令可以用來通知終端裝置其允許的最大駐留時間，比如：一個資料包在空中持續傳輸的最大時間，以及所允許的裝置最大的EIRP（有效全向輻射功率）。

大小（位元組）	1
TxParamSetup payload	EIRP_DwellTime

EIRP_DwellTime字段的結構如下：

Bits	7:6	5	4	3:0
MaxDwellTime	RFU	DownlinkDwellTime	UplinkDwellTime	MaxEIRP

TxParamSetupReq的 [0:3] bits用來編碼 Max EIRP值，見下表：

編碼值	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Max EIRP(dBm)	8	10	12	13	14	16	18	20	21	24	26	27	29	30	33	36

裝置無線傳輸的最大功率即為EIRP的最大值。裝置不必使用該功率進行傳輸，可也不能超過該EIRP。第4、第5位定義上、下行鍊路最大的駐留時間 ，編碼如下：

編碼值	駐留時間
無限制
1	400 ms

該指令執行後，終端裝置回複TxParamSetupAns。 TxParamSetupAns不攜帶任何負載資料。如果在一個對此沒有要求的地域使用該指令，裝置不執行，并且不回複。

本文翻譯版本部分已更新至LoRaWAN 1.0.2。

6 終端激活（End-Device Activation）

所有終端裝置在正式加入LoRaWAN網絡之前必須先進行初始化并激活。有兩種激活方式： 

無線激活（Over-The-Air Activation (OTAA)），裝置部署和重置時使用; 

手動激活（Activation By Personalization (ABP)），此時初始化和激活一步完成。

6.1 激活成功後存儲在終端裝置的資料

以下資訊在激活成功後回存儲在終端裝置：裝置位址（DevAddr）、應用ID（AppEUI）、網絡會話密鑰（NwkSKey）和應用會話密鑰（AppKey）。

6.1.1 終端裝置位址（DevAddr）

DevAddr是終端在目前網絡中的識别碼，大小32bits。結構如下：

Bit	[31..25]	[24..0]
DevAddr bits	NwkID	NwkAddr

最高7位是網絡ID（NwkID），用以區分有地域重疊的不同網絡營運商和彌補有路由問題的網絡。接下來的25bits，終端裝置網絡位址（NwkAddr），該位址可以有由網絡管理者配置設定。

6.1.2 應用唯一識别ID（AppEUI）

AppEUI是 IEEE EUI64 的全球唯一應用ID，用以識别終端裝置的應用服務提供商（等等）。AppEUI在進行激活操作之前就存儲在終端裝置中了。就是說AppEUI是出廠時燒錄進去的。

6.1.3 網絡會話密鑰（NwkSKey）

NwkSKey是配置設定給終端裝置的網絡會話密鑰。網絡伺服器和裝置用它來計算和校驗所有消息的MIC（消息一緻碼），來保證收發的資料一緻。也可以用來對MAC負載（MAC指令放在Payload裡面）的消息進行加/解密。

6.1.4 應用會話密鑰（AppSKey）

AppSKey是配置設定給終端裝置的應用會話密鑰。網絡伺服器和裝置用來對 應用指定的 Payload字段進行加解密。也可以用來計算和校驗應用層MIC（可能存放在應用指定 消息的Payload中）。

6.2 無線激活（Over-the-Air Activation）

終端裝置在與網絡伺服器交流（資料交換）之前，必須先通過加入過程加入網絡伺服器。每次終端裝置會話的上下文丢失（與伺服器通信斷開）後都要重新加入。加入伺服器之前，要使用以下資訊初始化終端裝置：全局唯一裝置ID（DevEUI）、應用ID（AppEUI）、AES-128密鑰（AppKey）。 AppEUI在上面6.1.2中有介紹。

* 注意：無線激活時，網絡密鑰初不會向初始化那樣寫死到終端，而是在終端加入網絡時由網絡層衍生并分發，該密鑰用來對傳輸資料進行加密和校驗。這樣，終端裝置能很友善的在不同的網絡伺服器和應用提供商之間切換。使用網絡會話密鑰和應用會話密鑰*可以避免應用資料被網絡供應商（網絡伺服器擁有者）解析或篡改，進而接入大量的網絡伺服器。

6.2.1 終端裝置ID（DevEUI）

DevEUI是全球終端ID，符合 IEEE EUI64，用來唯一辨識終端裝置。

6.2.2 應用密鑰（AppKey）

AppKey是AES-128的應用密鑰，由應用擁有者通過 應用指定的 根密鑰衍生并配置設定給終端裝置，根密鑰隻有應用供應商知曉和掌握。終端裝置通過無線激活入網時，通過AppKey衍生會話密鑰 NwkSKey和AppSKey，并分發相應的終端裝置，用來加密和校驗網絡通訊和應用資料。

6.2.3 入網流程

從終端的角度看，和伺服器互動的入網流程包含兩個MAC消息：join request 和 join accept.

6.2.4 入網請求（Join-request message）

入網流程由終端發起，終端入網時發送入網請求，消息格式（MACPayoad）如下：

位元組數	8	8	2
Join Request	AppEUI	DevEUI	DevNonce

入網請求消息包含：AppEUI、DevEUI和終端裝置産生的2位元組的随機數（DevNonce） 

DevNonce是個随機值，終端裝置最近使用的一些(數量自定義)DevNonce會儲存在網絡伺服器（NS）。如果終端發送的入網請求中的DevNonce在NS中可以查到，該請求就會被忽略。

注意：該機制的目的是防止重播攻擊(replay attacks)，避免其它人通過發送之前的入網請求來斷開終端裝置和網絡的連接配接。

入網請求的消息一緻性校驗碼（MIC）（見第4章MAC消息部分）通過下述算法計算：

cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce)MIC = cmac[0..3]      

入網請求以明文發送。

6.2.5 接受入網消息（Join-accept）

伺服器同意終端入網後網絡伺服器（NS）會回複 接受入網 消息。接受入網使用

JOIN_ACCEPT_DELAY1

 或 

JOIN_ACCEPT_DELAY2

（而不是RECEIVE_DELAY1 和RECEIVE_DELAY2），和普通消息一樣發送。這兩種接收視窗使用的信道頻率和資料率與 RX1和RX2的接收視窗（見章節“實體層”之”接收視窗”）相同。

入網請求被拒絕則伺服器不發送任何資料。

接受入網消息包含以下字段：應用層随機數（AppNonce），3位元組；網絡ID（NetID）；終端位址（DevAddr）；介于 TX 和 RX（RxDelay） 之間的延遲；信道頻率的一系列配置（CFList）。CFList相關内容見第7章。

大小（位元組）	3	3	4	1	1	變長(16)
接受入網	AppNonce	NetID	DevAddr	DLSeting	RxDelay	CFList

AppNonce是由網絡伺服器産生的一個随機數或唯一ID，終端裝置用它來衍生兩個會話密鑰：NwkSKey和AppSKey。衍生算法如下：

NwkSKey = aes128_encrypt(AppKey,               x01                 | AppNonce |NetID | DevNonce | pad16)      

AppSKey = aes128_encrypt(AppKey,               x02                 | AppNonce | NetID | DevNonce | pad16)      

接受入網的MIC計算方式如下：

cmac = aes128_cmac(AppKey,MHDR | AppNonce | NetID | DevAddr | DLSeting | RxDelay | CFList)MIC = cmac[0..3]      

消息本身采用 AppKey 加密，加密方式如下：

aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | DLSeting | RxDelay | CFList | MIC)      

注意：網絡伺服器加密接收入網消息使用的是 AEC ECB模式的解密算法。這樣終端就不必再實作AES解密算法，隻用AES加密即可。

NetID包含：NetID的7個最低有效位稱作NwkID，即DevAddr（終端短址）的7個最高有效位。區域相鄰或重疊的網絡的NwkID不能相同。餘下的17個最高有效位由網絡營運商自由配置設定。

DLsetting字段含有下行配置：

位（Bits）	7	6:4	3:0
DLsettings	RFU	RX1DRoffset	RX2 Data rate

RX1DRoffset設定上下行資料速率之間的偏移（偏差），和終端裝置互動的首個接收時隙（RX1）。（感冒好幾天了，頭懵，不知道該怎麼翻譯） offset預設為0。下行資料速率不能比上行的大。考慮到一些地區基站的最大功率密度限制，offset用來平衡上行和下行的無線鍊路餘量。 

上行和下行鍊路資料速率之間的确切關系見章節 “實體層（Physical Layer）”

延時RxDelay規則和RXTimingSetupReq指令中的Delay字段相同。

6.3 手動激活(Activation by Personalization)

某些情況下，可以通過配置激活終端裝置，（我）稱為手動激活。手動激活跳過了(jion request-join accept) 入網過程，将一個終端裝置和指定的伺服器聯系在一起。

手動激活需要把 DevAddr、NwkSKey以及AppSKey直接存放到終端裝置，而不再需要（無線激活 （或空中激活、OTA激活、OTAA） 中的）DevEUI、AppEUI以及AppKey。終端裝置啟動時就已經具備了加入指定LoRa網絡所需要的資訊。

每一個終端裝置都有一對唯一的 NwkSKey 和 AppSKey。這些協商的裝置秘鑰不能影響其它裝置的通信安全。生成秘鑰的流程應當保證這些秘鑰不能通過公開的資訊以任何方式推導出來。（比如：節點位址）。

7. 實體層（Physical Layer）

7.1 歐洲ISM頻段 863-870MHz

7.1.1 歐洲 863-870 前導碼

同步字見下表：

調制方式	同步字	前導碼長度
LoRa	0x34	8 symbols
GFSK	0xC194C1	5 bytes

symbols參考資料： 比特速率、碼片速率和符号速率等區分

感謝群友 

@

周先生背後有隻鬼

 提供的資料 

大家誰知道 

8 symbols

 怎麼了解？

symbols

 這個專業術語始終不知道該了解成什麼，在這裡向大家求教一下。

7.1.2 歐洲863-870 ISM頻段信道頻率

歐洲的無線電頻譜的ISM頻段由ETSI[EN300.220]配置設定。

網絡營運商可以自己定義網絡通道，但任何 EU868MHz 終端裝置都必須實作下面三個預設信道。這些信道是所有網絡網關都必須一直終監聽的最小集合。

調制方式	帶寬[kHz]	信道頻率[MHz]	FSK 比特率 或 LoRa 資料率或比特率	Nb 信道	占空比
LoRa	125	868.10 868.30868.50	DR0 至 DR5 / 0.3-5kbps	3	<1%

為了通路實體層，ETSI強制規定了一些限制，發射機可以線上的最大時間或者發射機每小時内可以發送的最大時間。ETSI允許使用占空比限制或者使用所謂的Listen Before Talk Adaptive Frequency Agility (LBT AFA) 傳輸管理。為了遵守ETSI規定，現在的LoRaWAN規範僅使用占空比對傳輸做限制。

LoRaWAN強制規定每個子帶的占空比限制。給定子帶上每一幀資料的發射時間和空中傳輸時間都會被記錄下來。子帶在接下來 Toff 秒之内不能再次使用，其中：

Toff_subband=TimeOnAirDutyCycle_subband−TimeOnAir

在指定子帶不可用期間，裝置可以通過其它子帶發送資料，如果所有的子帶都不可用，裝置就隻能等待下一次傳輸。裝置根據可用子帶調整其信道調頻順序。

例如：A裝置在預設信道上隻傳輸幀資料消耗了0.5s，該信道子帶的占空比 1%，那麼A在接下來 49.5s 内不能再次使用整個子帶（868-868.6）。

49.5=0.51%−0.5=0.5×100−0.5

EU868MHz ISM 頻段的終端裝置的預設參數如下：

-預設無線傳輸的發送功率：14 dBm

EU868Mhz 頻段的終端裝置應能夠在 863~870 MHz 頻段範圍内運作，并且應有至少能存儲16個信道參數的信道資料的結構體。一個信道資料結構對應一個頻率以及一組改頻率下可用的資料速率。

前三個信道是 868.1，868.3 和 868.5MHz/ DR0 至 DR5，這些參數必須在所有（EU868MHz下使用的）終端裝置實作。這些預設信道不能通過 NewChannelReq 指令進行修改，以保證終端裝置和網關之間存在最小的信道集合。

下表給出了終端裝置用來發送入網激活請求的頻率清單，入網請求傳輸占空比絕對不能超過

0.1%

表13：EU863-870 JoinReq Channel list

解調模式	帶寬[kHz]	信道頻率[MHz]	FSK比特率或\n\rLoRa資料速率/比特率	Nb信道	占空比
LoRa	125	864.10 , 864.30 , 864.50 , 868.10 , 868.30 , 868.50	DR0-DR5/0.3-5kbps	6	<0.1%

7.1.3 EU863-870 資料速率以及 節點輸出功率的編碼

下表是資料速率（DR）和 節點輸出功率（TXPower）在 EU863-870上的編碼：

表14： 資料速率和TX功率

資料速率	配置	對應實體比特速率[bit/s]
LoRa: SF12 / 125 kHz	250
1	LoRa: SF11 / 125 kHz	440
2	LoRa: SF10 / 125 kHz	980
3	LoRa: SF9 / 125 kHz	1760
4	LoRa: SF8 / 125 kHz	3125
5	LoRa: SF7 / 125 kHz	5470
6	LoRa: SF7 / 250 kHz	11000
7	FSK: 50 kbps	50000
8..15	RFU	…

TXPower	配置
20 dBm (if supported)
1	14 dBm
2	11 dBm
3	8 dBm
4	5 dBm
5	2 dBm
6..15	RFU

7.1.4 EU863-870 JoinAccept CFList

歐洲 863-870 ISM頻段的LoRaWAN在JoinAccept消息中實作了一個16位元組的可選信道配置清單（CFlist）。

CFList由第4至第8這5個信道組成，每個信道都是3位元組的無符号整型數字，不使用的信道填充0。所有清單裡面的信道都可以使用LoRa模式的 DR0～DR5。清單最後有一個填充位元組用來湊足16位元組，該位元組暫時無意義（保留位元組）。

位元組	3	3	3	3	3	1
CFList	Freq Ch4	Freq Ch5	Freq Ch6	Freq CN7	Freq Ch8	RFU

清單中道值的機關是 100Hz，其中100Mhz以下的頻率暫時保留（待未來使用）。這就可以以100Hz為步長，在100MHz～1.67GHz之間設定任意頻率的信道。CFList是可選配置，可以通過檢查JoinAccpet消息長度來檢測它。一旦CFList出現，就會用它裡面的信道替換節點上除了3個預設信道（第6章有說明）以外的信道，新的信道立刻可用并被終端用來通信。

7.1.5 EU863-870的LinkAdrReq指令

EU863-870的LoRaWAN支援最多16個信道，此時 ChMaskCntl 字段值是0，ChMask字段挨個 打開/關閉 這16個信道。

表15：ChMaskCntl 值清單

ChMaskCntl	ChMask 控制的信道
信道 1 ～ 16
1	RFU
…	RFU
4	RFU
5	RFU
6	開啟所有信道。裝置打開所有已經定義的獨立于ChMask字段的信道
7	RFU

7.1.6 EU863-870 payload最大位元組數

MACPayload最大長度（機關：位元組）見下表。該長度受PHY層限制，考慮到可能會有中繼封裝層 PHY層依賴于有效調制速率。下表同樣給出了在沒有FOpt的情況下，應用負載最大長度的參考值（翻譯調整，感謝朋友：四渡赤水）在缺少FOpt的情況下，應用負載的最大長度（N）僅給出了供參考的資訊 （不參考前面章節根本不知道什麼斷句，這文法也是醉了）。如果FOpt字段費空，N的值可能會更小：

表 16: EU863-870 payload最大長度

DataRate	M（MACPayload長度）	N（FRMPayload長度）
59	51
1	59	51
2	59	51
3	123	115
4	230	222
5	230	222
6	230	222
7	230	222
8：15	未定義	未定義

7.1.7 EU863-870 接收視窗

第一個接收視窗RX1使用和上行（使RX1開啟的上行消息）相同的信道，資料速率是上行資料速率的一個函數，RX1DROffset 見下表。RX1DROffset的範圍是[0:5],[6:7]是保留值。

RX1DROffset上傳資料速率(列) \ 下發資料速率RX1 slot (行)	1	2	3	4	5
DR0	DR0	DR0	DR0	DR0	DR0	DR0
DR1	DR1	DR0	DR0	DR0	DR0	DR0
DR2	DR2	DR1	DR0	DR0	DR0	DR0
DR3	DR3	DR2	DR1	DR0	DR0	DR0
DR4	DR4	DR3	DR2	DR1	DR0	DR0
DR5	DR5	DR4	DR3	DR2	DR1	DR0
DR6	DR6	DR5	DR4	DR3	DR2	DR1
DR7	DR7	DR6	DR5	DR4	DR3	DR2

接收視窗 RX2 使用修改後的頻率和資料速率。預設參數是 869.525 MHz/DR0（SF12，125 kHz）

7.1.8 EU863-870 預設設定

下面是 EU863-870Mhz 頻段相應參數的推薦值

參數	推薦值
RECEIVE_DELAY1	1 s
RECEIVE_DELAY2	2 s (必須是 RECEIVE_DELAY1 + 1s)
JOIN_ACCEPT_DELAY1	5 s
JOIN_ACCEPT_DELAY2	6 s
MAX_FCNT_GAP	16384
ADR_ACK_LIMIT	64
ADR_ACK_DELAY	32
ACK_TIMEOUT	2 +/- 1 s (1 ~ 3 的随機值)

如果終端中實作的實際值和這些預設值不一樣（比如，RECEIVE_DELAY1和RECEIVE_DELAY2延遲時間更長），這些參數的值一定要通過外帶信道（out-of-band channel）通知給網絡伺服器。網絡伺服器可能會不接受與預設值不一緻的參數。

7.2 美國 902-928MHz ISM 頻段

章節7.2、7.3、7.4結構一樣，隻是帶入不同的參數，由于時間關系目前就不做重複勞動了，以後時間充裕再補充上。

（略）

7.3 中國 779-787MHz ISM 頻段

（略）

7.4 歐洲 902-928MHz ISM 頻段

（略）

目前的LoRaWAN協定（也就是lorawan 1.0.x）可以分成兩部分。

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

信标在空中傳輸的時間遠遠小于信标為網絡管理廣播幀預留的時間。 

信标視窗時間間隔分成 215=4096 個時長為 30ms 的ping slots（ping時隙），這些時隙從第0個開始，至4095個結束。 

終端裝置一旦使用第 N 個時隙，就必須精确的在信标起始之後的第 Ton 秒打開接收視窗，其中Ton計算方法如下：

Ton=beacon_reserved+N×30

N是時隙索引（第N個時隙），機關ms。

最後一個

ping slot

在上次信标開始之後的第 beacon_reserved+4095×30ms=124970 ms 或者 下次信标開始之前的第 3030ms 打開。

13.2 随機時隙

為了避免系統沖突和 

over-hearing

 (不确定是竊聽還是過載，不過根據LoRWAN的功能推斷這裡應該是過載)，使用随機的時隙索引，并且每個信标期間都要變化。

參數如下：

DevAddr	裝置單點傳播或多點傳播網絡位址，32位
pingNb	每個信标周期内的 ping slot 數量。必須是2的指數倍： 2k 其中 1≤k≤7
pingPeriod	Period of the device receiver wake-up expressed in number of slots：212pingNb
pingOffset	offset是個随機值，每次信标周期開始時通過計算獲得。範圍： 0~(pingPeriod - 1)
beaconTime	該時間在BCNPayload中，Time of the immediately preceding beacon frame 緊接在信标幀前面的時間
slotLen	一個 ping slot 的時長：30ms

為了校準（對齊）接收時隙，每個信标周期終端裝置和伺服器都會重新計算一個僞随機偏移。随機數生成使用AES加密算法，密鑰全部由0組成：

Key = 16 x 0x00Rand = aes128_encrypt(Key, beaconTime | DevAddr | pad16pingOffset = (Rand[0] + Rand[1]x 256) modulo pingPeriod      

本信标周期内使用的縫隙：

節點在以下時間點打開接收縫隙：

縫隙	開啟時刻
縫隙 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的優先處理。

使用随機化方案來避免單點傳播時隙群組播時隙之間系統級别的沖突。如果在某個信标周期出現沖突，下一個信标周期幾乎沒有發生沖突的可能性。

章節1~7、17~.

這是LoRaWAN協定的基礎，講A類和C類。 

關于第17章C類，由于相對簡單也就不特意放到前面翻譯。

章節8~13

主要講B類。A類和B類在協定格式上差別不大，這兩個除了協定包，其它變動都很大，想要在同一個邏輯裡面實作比較困難。

不少朋友留言需要源代碼，這裡建議大家盡量先自己想辦法找，理由就是對你自己有好處。

如果實在找不到，節點、網關和伺服器（都是demo）的開源代碼我也同步了一份到開源中國。

另外，建了一個群，有興趣的朋友可以加入進來一起讨論問題：

428109903

LoRaWAN1.0.1_d3

該版本是一些bug修複，協定本身沒有什麼改動。 

閱讀中文翻譯的朋友可以略過大部分改動，因為這些在翻譯過程中已經處理了。

變化如下：

• 明确 RX 視窗開啟時間
• 修正 章節NA 中 DR2 負載大小上限
• 修正 7.2.2 中的拼寫錯誤
• 對 7.2.2 中使用碼率 4/5 提出新的規定，以保證無線傳輸時間 < 400ms
• 修正 6.2.5 中的JoinAccept MIC算法
• 5.2 中的 字段名由 NbRep 改為 NbTrans
• 删掉4.3.3.2，排除 MAC層不對應用資料（Applicative payload）加密的情況。出于應用對安全的進一步要求，不管用什麼算法，需要對payload加密（這裡無關LoRaWAN協定，跟個人安全有關），然後再使用LoRaWAN中的算法在MAC層再次加密。
• 修正 FHDR 相關錯别字
• 修正 7.2.5 中 chMaskCntl 等于6或7時 ChMask 對信道的影響。
• 說明 JoinResp 消息中 RX1 的資料速率偏移
• 删除 7.2.7 中 DRoffset表的下半部分。

LoRaWAN Specification 1R0

初始版本

協定格式整理

整個協定包括LoRa和網關互動部分，伺服器隻需要帶顔色的資料。

最近有不少朋友對PHYPayload還是搞不清，再分享兩張圖檔，把整個流程都分享給大家

1 入網激活

2 接收入網

3 正常通信

4 文檔下載下傳

7. 重傳退化（Retransmissions back-off）

下述上行幀會觸發災難性的、持續的無線網絡過載：

需要網絡伺服器或者應用伺服器确認或應答的消息，裝置如果沒有收到确認或應答就會重傳。

外部事件觸發（斷電、無線幹擾、網絡中斷、地震等），導緻大量（> 100）裝置進行同步

注意：

上述情況的典型案例：一批終端裝置在網絡中斷後要重置MAC層，這批終端裝置将一起廣播入網請求 ，并且隻有在收到入網響應後才會停止。

對于那些重傳的幀來說，從RX2結束到下一次重傳開始的時間間隔應是随機值，并且每個裝置使用不同的隊列（例如：使用與裝置位址相關的僞随機數生成器）。這種重傳消息的占空比應當遵守當地規定和下述限制，以兩者之中的最大限制為準：

上電或複位後的累計時長(小時)	傳輸時間()
≥0,≤1	T0<t<T0+1	<36秒
>1,≤11	T0+1<t<T0+11	<36秒
>11，累計超過24小時	T0+11+N<t<T0+35+N,N>=0	<8.7秒/24小時