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タイプ定義されている。
| 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 |
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にある。
この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次第か。
以上。
コメント