LoRaWAN 規範 1.0（2~4章）

最近在做LoRa， LoRaWAN協議略微複雜，邊讀邊翻譯，現在把部分關鍵的翻譯分享給各位做物聯網的同行。
當然裏面摻雜了一些我的個人筆記，希望對大家有所幫助。
如果哪裏有問題，歡迎應各位留言或者郵件指正。

翻譯很辛苦，轉載請註明出處和源鏈接

鑑於本人在閱讀現代國人的譯文時的所感所想：

在本文檔的譯文中不會出現任何音譯，也儘量減少讓人不懂的直譯，轉成符合中國人邏輯的文字。我不懂或者不確定的地方會將原文一起放上，如果有誤還請大家指出來。

• LoRaWAN版本歷史及協議格式說明
• 翻譯原文鏈接：
  
  • LoRaWAN 規範 1.0 （章節2~4）
  • LoRaWAN 規範 1.0 （章節5）
  • LoRaWAN 規範 1.0 （章節6）
  • LoRaWAN 規範 1.0 （章節7）
  • LoRaWAN 規範 1.0 （章節10~13）

LoRaWAN 規範 1.0 （2~4章）

聲明

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

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

2 LoRaWAN 簡介

LoRa^TM 是由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_DELAY1             |                           |
|                        |<------------------------------------------------------->|
                                                            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	備註
  0	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

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

PS

看到有些夥伴提問問題，由於本人的CSDN一般不在線。

爲了方便交流，附個郵箱，有問題或者想法的朋友可以

---

本文由 qingchuwudi 譯製、整理，除非另有聲明，在不與原著版權衝突的前提下，本作品採用知識共享署名 3.0 中國大陸許可協議進行許可。

---

1. See the LoRa radio transceiver datasheet for a description of LoRa radio packet implicit/explicit modes. ↩
2. 本文檔對”服務器發往多個節點的組播消息的傳輸“不做說明。 ↩
3. 空載數據的一致性校驗在本層完成，使消息的發送時間儘可能短，使它在任何佔空比下對ISM頻段的影響降低都到最低。 ↩
4. payload大小的最小值在第六章有詳細介紹。 ↩
5. 確認機制詳細的時序圖在第18章 ↩
6. 靜態終端指的是靜止狀態的終端設備，位置不發生變化。與位置經常變化的移動終端相對。 ↩
7. 原文說的是 “regain connectivity” ，可能是重新入網也可能是重新發送正常數據。閱讀節點源碼，這裏是“重新發送正常數據”。 ↩
8. JoinReq – JoinAccept 也就是OTAA入網成功，個性化終端設備也就是各項參數通過人工配置進行激活的終端設備，即我之前翻譯中的 手動激活 的設備。 ↩
9. 這裏使用複數，而沒有指明上行計數器還是下行計數器，說明兩個計數器都會被影響。 ↩
10. MAX_FCNT_GAP、 RECEIVE_DELAY1 以及 RECEIVE_DELAY2 的值 可以從 * LoRaWAN1.0.2參數文檔 * 找到。鬼知道原文備註的“Error! Reference source not found. for EU863-870 or Error! Reference source not found. for US902-928.” 是不是超鏈接的時候沒找到。 ↩
11. 這裏之前翻譯爲 “這條以及後面的數據就被丟掉”，不太準確。因爲在考慮到DevAddr可能重複的情況下，錯誤數據可能來自另一個節點，而隨後本節點真正過來的數據不一定是錯誤的。目前LoRaWAN開發者（包括公司）各自開發，Network ID隨意設置並沒有遵循LoRa聯盟的規則，因此不同的節點DevAddr是有可能相同的。哪怕不考慮這些，DevAddr中的NetID只取7位，才128個不同的DevAddr地址空間，理論上也是可能出現重複的。 ↩
12. Out-Of-Band維基百科、Out-Of-Band百度百科 ↩