LoRaWAN 1.0.2 の Confirmed な message の仕様メモ

LoRaWANにはConfirmedとUnconfirmedなUplinkないしDownlinkがある。Confirmed、ということはつまりACK応答を確認するということだが、それはつまり具体的に何をしているのかのメモ書き。LoRaWAN Specification 1.0.2 に基づく。

スポンサーリンク

ざっくり概要

仕様書から読み取れることをざっくり書くと以下。なお( )内は仕様書のセクション番号。

  • LoRaWANでは6つのMAC message types(MType)が区別されている(4.2.1)
  • MTypeはMHDRの中で規定される(4.2.1)
  • MTypeのうちの2つがUnconfirmed Data UpとConfirmed Data Up confirmed data messageを受け取ったreceiverは、FHDR(Frame header)のFCtrlにあるACKのbitをたてて応答しなければならない(shall)(4.3.1.2)
  • もし、receiverに保留中のdownlinkがなければ、networkはpayloadなしのframeを生成しなければならない(shall)(18.1)
  • end-deviceは、ACKが返ってこなければ、uplinkをカウンタをインクリメントせず再送できる(may)(18.1)。

confirmedって何か

もうちょっとちゃんと見ていく。

そもそもConfirmedとはどっから出てきた言葉か。これはMAC Header(MHDR)のMAC message types(MType)にある4つのタイプだろう。MTypeは3bit、つまり8タイプ定義されている。

MTypeDescription
000Join Request
001Join Accept
010Unconfirmed Data Up
011Unconfirmed Data Down
100Confirmed Data Up
101Confirmed Data Down
110RFU
111Proprietary
Mac message types (4.2.1)

010…101の4タイプに、Confirmedという言葉がある。で、confirmed-dataとは何かというと、4.2.1.2に以下の記述。

A confirmed-data message has to be acknowledged by the receiver, whereas an unconfirmed-data message does not require an acknowledgment.

4.2.1.2 Data messages

receiverのACKが必要なのがconfirmed、必要ないのがunconfirmedということ。まぁそれはそうだろう。receiverは、uplinkならreceiverはnetwork serverだろうし、downlinkならend-deviceだろう。

何をもってconfirmedとするのか

さて、MHDRのMTypeからConfirmedなメッセージであるかどうかが確認できるわけだ。で、Confirmedなメッセージが届いたとして、receiverはいかにしてACKを返したらよいか。

4.3.1.2に、以下の記述がある。

When receiving a confirmed data message, the receiver shall respond with a data frame that has the acknowledgment bit (ACK) set.

4.3.1.2 Message acknowledge bit and acknowledgement procedure (ACK in FCtrl)

receiverはACKのbitをたてて返せ、と。ACKのbitって何かというと、これはFrame header(FHDR)のFCtrlにある。

4.3.1 Frame header(FHDR)

このbitをたてた状態で応答して、senderはACKが返ったとみなす。

ACK応答のペイロード

さて、Confirmedなuplinkを考えたとき、このACK応答はつまりdownlinkである。したがって、pendingしているdownlinkがあれば、それを返すことになる。もしない場合は?18.1には以下のように記述されている。

If there is no downlink payload pending the network shall generate a frame without a payload

18.1 Uplink Timing Diagram for Confirmed Data Messages

ペイロードなしのdownlinkを返す、と。

ACKが返ってこない時の挙動

ここまで正常系だが、実際にはACKが返ってこないこともある。というかそういうことがあるからこそのConfirmedである。で、ACKが返ってこなければsenderはどうするか。18.1には以下のように記述されている。

If an end-device does not receive a frame with the ACK bit set in one of the two receive windows immediately following the uplink transmission it may resend the same frame with the same payload and frame counter again at least ACK_TIMEOUT seconds after the second reception window.This resend must be done on another channel and must obey the duty cycle limitation as any other normal transmission.

18.1 Uplink Timing Diagram for Confirmed Data Messages

2つの受信窓のいずれも受信できなかったとき、2番目の受信窓からACK_TIMEOUT秒後に再送できる。ただし再送する時は違うチャネルで。

ということで、一定の制約にしたがって諦めずに再送してもよいよ、とのお達し。実際どうするかはsender次第か。

以上。

関連コンテンツ

関連記事

スポンサーリンク

カテゴリーIoT

コメントを残す

メールアドレスが公開されることはありません。