*

LoRaWAN 1.0の仕様を翻訳してみる

公開日: : 最終更新日:2017/08/27 LoRaWAN

LoRaWAN102-20161012_1398_1.pdf
を翻訳(意訳)します。

LoRaWAN Specification
Version: V1.0.2
Date: 2016 July
Status: Final

1 2.2 Specification scope
2 This LoRaWAN specification describes the additional functions differentiating an end-device
3 higher Class from one of Class A. A higher Class end-device shall also implement all the
4 functionality described in the LoRaWAN Class A specification.

クラスAのデバイスとその他の上位クラスのデバイスを区別する追加機能について説明します。

5 NOTE: Physical message format, MAC message format, and other
6 parts of this specification that are common to both end-devices of
7 Class A and higher Classes are described only in the LoRaWAN
8 Class A specification to avoid redundancy.

NOTE:クラスAと上位クラスで共通の仕様(Physical message formatとMAC message format等)については、重複を避けるためにクラスAでのみ説明します。

1 CLASS A – ALL END-DEVICES
2 All LoRaWAN end-devices must implement Class A features.

すべてのLoRaWANデバイスはクラスAの機能を実装しなければいけません。

1 3 Physical Message Formats
メッセージのフォーマットについて

2 The LoRa terminology distinguishes between uplink and downlink messages.
LoRaの用語アップリンクメッセージとダウンリンクメッセージとを区別する。

3 3.1 Uplink Messages
4 Uplink messages are sent by end-devices to the network server relayed by one or many
5 gateways.
デバイスから送られたUplinkは一つもしくは多くのGW経由してNetworkServerへ送られる。

6 Uplink messages use the LoRa radio packet explicit mode in which the LoRa physical
7 header (PHDR) plus a header CRC (PHDR_CRC) are included. The integrity of the payload
8 is protected by a CRC.
9 The PHDR, PHDR_CRC and payload CRC fields are inserted by the radio transceiver.
アップリンクは、LoRa物理ヘッダ(PHDR)とCRC(PHDR_CRC)を含みます。
ペイロードの整合性はCRCによって保護されています。
PHDR、PHDR_CRCおよびペイロードCRCフィールドは、無線トランシーバによって挿入されます。
Uplink PHY:
| Preamble | PHDR | PHDR_CRC | PHYPayload | CRC |

12 3.2 Downlink Messages
13 Each downlink message is sent by the network server to only one end-device and is
14 relayed by a single gateway.
15 Downlink messages use the radio packet explicit mode in which the LoRa physical header
(PHDR) and a header CRC (PHDR_CRC) are included.
ダウンリンクについて
各ダウンリンクはNetworkServerによって一つのGWを経由し一つのデバイスへ送られます。
ダウンリンクは、LoRa物理ヘッダ(PHDR)とCRC(PHDR_CRC)を含みます。
Downlink PHY:
   | Preamble | PHDR | PHDR_CRC | PHYPayload |

19 3.3 Receive Windows
20 Following each uplink transmission the end-device opens two short receive windows. The
21 receive window start times are defined using the end of the transmission as a reference.
レシーブウィンドウについて
アップリンクの後にデバイスは短い間隔のレシーブウィンドウを2回開きます。
レシーヴウィンドウの開始時間は、送信終了からの時間を基準点に定義されます。

3 3.3.1 First receive window channel, data rate, and start
最初のレシーブウィンドウ チャネル、データレート
4 The first receive window RX1 uses a frequency that is a function of the uplink frequency and
5 a data rate that is a function of the data rate used for the uplink. RX1 opens RECEIVE_DELAY1
6 seconds (+/- 20 microseconds) after the end of the uplink modulation.
7 The relationship between uplink and RX1 slot downlink data rate is region specific and
8 detailed in the LoRaWAN Regional Parameters document [PARAMS]. By default the first
9 receive window datarate is identical to the datarate of the last uplink.
最初のレシーブウィンドウRX1 はアップリンクで使われた周波数とデータレートを使います。
アップリンクの後にRX1はRECIEVE_DELAY1を1秒(+/- 20 msec)後にオープンします。
アップリンクとRX1スロットのダウンリンクデータレートは、地域固有のものであり、その説明は
LoRaWAN Regional Parameters文書[PARAMS]に詳述されています。
デフォルトでは、最初の受信ウィンドウのデータレートは最後のアップリンクのデータレートと同じです。

10 3.3.2 Second receive window channel, data rate, and start
11 The second receive window RX2 uses a fixed configurable frequency and data rate and
12 opens RECEIVE_DELAY21 seconds (+/- 20 microseconds) after the end of the uplink
13 modulation. The frequency and data rate used can be modified through MAC commands
14 (see Section 5).The default frequency and data rate to use are region specific and detailed
15 in the LoRaWAN Regional Parameters document [PARAMS].
2番目のレシーブウィンドウ チャネル、データレート
2番目のレシーブウィンドウは設定された周波数とデータレートを使います。また、アップリンクが終わった後
RECIEVE_DELAY2を2秒(+/- 20 msec)後にオープンします。
その周波数とデータレートはMACコマンドを通して設定可能です。(Section 5をみてください)
周波数とデータレートの初期値は地域固有のものであり、その説明はLoRaWAN Regional Parameters文書[PARAMS]
に詳述されています。

16 3.3.3 Receive window duration
17 The length of a receive window must be at least the time required by the end-device‘s radio
18 transceiver to effectively detect a downlink preamble.
レシーブウィンドウの間隔
ダウンリンクのプリアンブルを効率よく検出するためには、
レシーブウィンドウの長さは少なくともデバイスの無線トランシーバーから要求される時間分は必要です。

19 3.3.4 Receiver activity during the receive windows
20 If a preamble is detected during one of the receive windows, the radio receiver stays active
21 until the downlink frame is demodulated. If a frame was detected and subsequently
22 demodulated during the first receive window and the frame was intended for this end-device
23 after address and MIC (message integrity code) checks, the end-device does not open the
24 second receive window.
レシーブウィンドウ中の受信部の動作
プリアンブルが1つのレシーブウィンドウの間で検出された場合、
無線受信部(RX1)は、ダウンリンクフレームが復調されるまでアクティブの状態を保ちます。
ダウンリンクフレームを検出し、最初の受信ウィンドウの間でフレームを復調し、
アドレスとMIC(メッセージ完全性コード)をチェックして
当エンドデバイス向けのダウンリンクフレームだと確認がとれた場合、
エンドデバイスは2番目の受信ウィンドウを開きません。

25 3.3.5 Network sending a message to an end-device
26 If the network intends to transmit a downlink to an end-device, it will always initiate the
27 transmission precisely at the beginning of one of those two receive windows.
ネットワーク側からデバイスにメッセージを送る場合
もしネットワーク側からデバイスにダウンリンクを送りたい場合、
2つの受信ウィンドウのうちの1つの受信ウィンドウがオープンするとともに送信を開始します。

1 3.3.6 Important notice on receive windows
2 An end-device shall not transmit another uplink message before it either has received a
3 downlink message in the first or second receive window of the previous transmission, or the
4 second receive window of the previous transmission is expired.
レシーブウィンドウについて重要なこと
1番目もしくは2番目のレシーブウィンドウでダウンリンクを完全に受け取りきる前に、
デバイスは次のアップリンクを送ることはありません。

5 3.3.7 Receiving or transmitting other protocols
6 The node may listen or transmit other protocols or do any transactions between the
7 LoRaWAN transmission and reception windows, as long as the end-device remains
8 compatible with the local regulation and compliant with the LoRaWAN specification.
他のプロトコルの受信または送信について
  デバイスがローカルの規格と互換性があり、LoRaWAN仕様に準拠している限り、
ノードはLoRaWAN送信ウィンドウと受信ウィンドウとの間で他のプロトコルを聴いたり、
送信したり、トランザクションを行うことができます。

1 4 MAC Message Formats
2 All LoRa uplink and downlink messages carry a PHY payload (Payload) starting with a
single-octet MAC header (MHDR), followed by a MAC payload (MACPayload)1
3 , and ending
4 with a 4-octet message integrity code (MIC).

すべてのLoRaアップリンクおよびダウンリンクメッセージは、1オクテットのMACヘッダー(MHDR)、
MACペイロード(MACPayload)、4オクテットのメッセージ完全性コード(MIC)で始まるPHYペイロード
(ペイロード)を伝送します。
Radio PHY layer:
| Preamble | PHDR | PHDR_CRC | “PHYPayload” | CRC* |
CRC* is only available on uplink messages

PHYPayload:
| MHDR | “MACPayload” | MIC |
or
| MHDR | Join-Request | MIC |
or
| MHDR | Join-Response | MIC |

MACPayload:
| “FHDR”| FPort | FRMPayload |

FHDR:
| DevAddr | FCtrl | FCnt | FOpts |

17 4.1 MAC Layer (PHYPayload)
18
Size (bytes) 1 1..M 4
PHYPayload | MHDR | MACPayload | MIC |
19
20 The maximum length (M) of the MACPayload field is region specific and is specified in
21 Chapter 6.
MACペイロードのフィールドの最大長は地域の規格によります。Chapter 6でも解説します。

22 4.2 MAC Header (MHDR field)
23
  Bit#    7..5   4..2 1..0
MHDR bits | MType | RFU | Major |
24
1 The MAC header specifies the message type (MType) and according to which major version
2 (Major) of the frame format of the LoRaWAN layer specification the frame has been
3 encoded.
MACヘッダーは、メッセージタイプ(MType)を指定し、LoRaWANレイヤー仕様のフレームフォーマットの
メジャーバージョン(メジャー)がエンコードされているかどうかによってフレームをエンコードします。(?)

4 4.2.1 Message type (MType bit field)
5 The LoRaWAN distinguishes between six different MAC message types: join request, join
6 accept, unconfirmed data up/down, and confirmed data up/down.
LoRaWANには6つのMACメッセージタイプがあります。それは、join request, join accept,
unconfirmed data up/down, and confirmed 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 RFU
111 Proprietary

8 4.2.1.1 Join-request and join-accept messages
9 The join-request and join-accept messages are used by the over-the-air activation procedure
10 described in Chapter 6.2.
Join-request と join-acceptはデバイスのOTAアクティベーションをするときの手続きで使われます。
Chapter 6.2で説明します。

11 4.2.1.2 Data messages
12 Data messages are used to transfer both MAC commands and application data, which can
13 be combined together in a single message. A confirmed-data message has to be
14 acknowledged by the receiver, whereas an unconfirmed-data message does not require
an acknowledgment.1
15 Proprietary messages can be used to implement non-standard
16 message formats that are not interoperable with standard messages but must only be used
17 among devices that have a common understanding of the proprietary extensions.
18 Message integrity is ensured in different ways for different message types and is described
19 per message type below.
データメッセージはMACコマンドとアプリケーションデータの両方を送信するのに使われており、それらは
結合して一つのメッセージ内で送ることが可能です。
confirmedメッセージはレシーバー側でAckを返す。
一方unconfirmedメッセージに対してはAckを必要ではありません。
独自のメッセージを送るには標準的なメッセージとは互換性のないメッセージフォーマットを
実装する必要があるため、独自のフォーマットをDeviceの双方で実装する必要があります。
メッセージの完全性は、さまざまなメッセージタイプに対して異なる方法で保証され、
以下のメッセージタイプごとに説明されています。

4.2.2 Major version of data message (Major bit field)
Major bits | Description
00 |LoRaWAN R1
01..11 | RFU

23 Note: The Major version specifies the format of the messages
24 exchanged in the join procedure (see Chapter 6.2) and the first four
25 bytes of the MAC Payload as described in Chapter 4. For each major
26 version, end-devices may implement different minor versions of the
27 frame format. The minor version used by an end-device must be made
28 known to the network server beforehand using out of band messages
29 (e.g., as part of the device personalization information).

メジャーバージョンのデータメッセージ
Note:メジャーバージョンでは、joinの手続き(Chapter6.2を参照)と
MAC Payload(Chapter 4を参照)の初めの4バイトで交換されるメッセージの形式を
定義しています。メジャーバージョンが変わるたびに、Deviceはフレームフォーマットについて
毎回違ったマイナーバージョンを実装すると思います。Deviceに使われるマイナーバージョンは
あらかじめネットワークサーバーに知らせる必要があります。知らせるにはネットワークサーバーに
Deviceの個別情報の一部として事前登録しておくことなどが考えられます。

1 4.3 MAC Payload of Data Messages (MACPayload)
2 The MAC payload of the data messages, a so-called “data frame”, contains a frame header
3 (FHDR) followed by an optional port field (FPort) and an optional frame payload field
4 (FRMPayload).

MACPayloadについて
MACPayloadはデータフレームと呼ばれ、FportとFRMPayloadにつづくフレームヘッダーを含みます。

5 4.3.1 Frame header (FHDR)
6 The FHDR contains the short device address of the end-device (DevAddr), a frame control
7 octet (FCtrl), a 2-octets frame counter (FCnt), and up to 15 octets of frame options (FOpts)
8 used to transport MAC commands.

Frame header (FHDR)
FHDRは
Deviceのアドレス(DevAddr)、
フレームコントロールオクテット(FCtrl)、
2オクテットのフレームカウンター(FCnt)、
MACコマンドを転送するための最大15オクテットのフレームオプション(FOpts)を含む。
(オクテット:8bit)

Size (bytes) | 4 | 1 | 2 | 0..15 |
FHDR |DevAddr| FCtrl |FCnt |FOpts |

10 For downlink frames the FCtrl content of the frame header is:
DownlinkのフレームのFCtlのフレームヘッダの内容
Bit# |7 |6 |5 |4 |[3..0] |
FCtrl bits |ADR |RFU | ACK |FPending |FOptsLen |

11 For uplink frames the FCtrl content of the frame header is:
UplinkのフレームのFCtlのフレームヘッダの内容
Bit# |7 | 6 | 5 | 4 | [3..0] |
FCtrl bits |ADR |ADRACKReq |ACK |RFU |FOptsLen |

12 4.3.1.1 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl)
13 LoRa network allows the end-devices to individually use any of the possible data rates. This
14 feature is used by the LoRaWAN to adapt and optimize the data rate of static end-devices.
15 This is referred to as Adaptive Data Rate (ADR) and when this is enabled the network will be
16 optimized to use the fastest data rate possible.
フレームヘッダ内でのデータレート調整について(FCtl内のADR、ADRACKReq)
LoRaのネットワークでは可能なデータレートならどれでも使えます。LoRaWANではこの特性を利用してデバイスのデータレートを調整して最適化します。これをADRと呼びます。ADRが利用可能な場合、ネットワークは可能な限りもっとも早いデータレートを使うように最適化されます。

17 Adaptive Data Rate control may not be possible when the radio channel attenuation
18 changes fast and constantly. When the network is unable to control the data rate of a device
19 , the device‘s application layer should control it. It is recommended to use a variety of
20 different data rates in this case. The application layer should always try to minimize the
21 aggregated air time used given the network conditions.
無線周波数の減衰量が度々変わるとADRのコントロールはできなくなるでしょう。ネットワークがDeviceのデータレートをコントロールできない場合、DeviceのアプリケーションレイヤーでADRをコントロールすべきです。この場合、様々なデータレートを使うことが推奨されます。与えられたネットワーク環境でアプリケーションレイヤーは常にair time を短くするようにすべきです。

22 If the ADR bit is set, the network will control the data rate of the end-device through the
23 appropriate MAC commands. If the ADR bit is not set, the network will not attempt to control
24 the data rate of the end-device regardless of the received signal quality. The ADR bit may
25 be set and unset by the end-device or the Network on demand. However, whenever
26 possible, the ADR scheme should be enabled to increase the battery life of the end-device
27 and maximize the network capacity.
ADRビットがセットされている場合、ネットワークはDeviceのデータレートを適切なMACコマンドを使ってコントロールするでしょう。しかし、ADRビットがセットされていない場合、ネットワークは受信した信号の質に関わらずデータレートをコントロールすることはありません。Deviceやネットワークが必要に応じてADRビットをセットしたりセットしなかったりできます。しかし、可能なかぎり、ADR機能は利用した方がよいです。Deviceの電池寿命をふやし、ネットワークのキャパシティを最大化するからです。

28 Note: Even mobile end-devices are actually immobile most of the time.
29 So depending on its state of mobility, an end-device can request the
30 network to optimize its data rate using ADR.
NOTE: 携帯用のDeviceでも実際は多くの時間動くことはありません。そのため、Deviceが移動しているかどうかに応じて、DeviceはネットワークにADRを使ったデータレートの最適化を要求するでしょう。

31 If an end-device whose data rate is optimized by the network to use a data rate higher than
32 its lowest available data rate, it periodically needs to validate that the network still receives
33 the uplink frames.
Deviceのデータレートはネットワークによって利用可能なもっとも低いデータレートからより高いデータレートを使うよう最適化される場合、ネットワークが依然同じようにUplinkデータを受け取れていることを確認することが周期的に必要です。

33 Each time the uplink frame counter is incremented (for each new uplink,
34 repeated transmissions do not increase the counter), the device increments an
35 ADR_ACK_CNT counter. After ADR_ACK_LIMIT uplinks (ADR_ACK_CNT >=
36 ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request
37 bit (ADRACKReq). The network is required to respond with a downlink frame within the
38 next ADR_ACK_DELAY frames, any received downlink frame following an uplink frame
1 resets the ADR_ACK_CNT counter.
Uplinkデータのカウントがインクリメントされるタイミングで(新しいUplink来るたびです、再送の場合はカウントは増やさずそのままです)、Deviceは ADR_ACK_CNT のカウンターをインクリメントします。ADR_ACK_LIMIT に達するuplinksが来てかつDownlinkの応答がない状態のとき、(ADR_ACK_CNT >= ADR_ACK_LIMIT)DeviceはADR acknowledgment の要求(ADRACKReq)を送ります。ネットワークは次のADR_ACK_DELAY frames を含んだDownlinkフレームで応答することを要求され、受信した全てのDownlinkのあとのUplinkフレームではADR_ACK_CNTのカウントはリセットされます。

1 The downlink ACK bit does not need to be set as any
2 response during the receive slot of the end-device indicates that the gateway has still
3 received the uplinks from this device. If no reply is received within the next
4 ADR_ACK_DELAY uplinks (i.e., after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the
5 end-device may try to regain connectivity by switching to the next lower data rate that
6 provides a longer radio range. The end-device will further lower its data rate step by step
7 every time ADR_ACK_DELAY is reached. The ADRACKReq shall not be set if the device
8 uses its lowest available data rate because in that case no action can be taken to improve
9 the link range.
Deviceの受信スロットの間の全ての応答はゲートウェイがまだDeviceからのUplinkを受信していることを示すのでDownlinkのACKビットがセットされる必要がありません。次のADR_ACK_DELAY uplinksを含んだ応答を受け取っていない場合、(ADR_ACK_LIMIT + ADR_ACK_DELAYの合計のあと)Deviceは使用可能なより長い無線範囲で低いデータレートに変更することで再接続を試みます。毎回ADR_ACK_DELAYに達するたびにDeviceはさらに低いデータレートを使うでしょう。Deviceは使用可能なもっとも低いデータレートを使う場合、ADRACKReqはセットされない。なぜならこの場合だと接続範囲を改善することができないためだからです。
10 Note: Not requesting an immediate response to an ADR
11 acknowledgement request provides flexibility to the network to
12 optimally schedule its downlinks.

NOTE: Downlinkの送信スケジュールを最適化するため、ADR acknowledgement requestにすぐに応答を要求しないことはネットワークに柔軟性をもたらします。

14 Note: In uplink transmissions the ADRACKReq bit is set if
15 ADR_ACK_CNT >= ADR_ACK_LIMIT and the current data-rate is
16 greater than the device defined minimum data rate, it is cleared in
17 other conditions.
NOTE: Uplinkの送信時ADR_ACK_CNT >= ADR_ACK_LIMITのときにADRACKReqビットがセットされ、現在設定されているデータレートがDeviceに定義されている最低のデータレートより高い場合、他の条件でクリアされます。

admax_area



関連記事

no image

AppSKeyを使ってpayloadをdecrypt

https://github.com/jieter/python-lora サクッと使えるのがすで

記事を読む

admax_area



Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

admax_area



PAGE TOP ↑