Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka <[e-mail]>]

Thank you, Tero!

> The TG4md documents can be found from [1] and there is
> consolidated comments from the last letter ballot [2], and from there
> you can find the CID 93 that is talking about the frame pending bit on
> TSCH.

Yes, I found CID 93. Nice.

> This rewrite will most likely add some more text there specifying what
> link scheduled means, and when to send the pending bit and so on, I
> will make sure it also covers the case where there is no ACK.

That is great. It will be helpful!

My question is about a frame loss in the following case:

[at ASN n]
- a transmitter sends a frame having the pending bit on
- the receiver receives the frame and sends backan ACK to the transmitter
- the receiver decides to stay on the same physical channel in the next slot (because "there is no link scheduled")
- the transmitter receives the ACK and decides to send a next frame on the same physical channel in the next slot

[at ASN n+1]
- the transmitter sends the second frame
- the transmitter doesn't receive an ACK; it sees the frame is lost

> The transmitter has no idea which of those two things happened, thus
> only safe thing it can do is to abort also and continue normal
> schedule.

I agree!

My point here is that, it's unclear if the transmitter should start the TSCH retransmission algorithm by the loss of the latter frame. The condition to start the process in the current test is:

   "When a packet is transmitted on a shared link for which an acknowledgment is expected and none is received, the transmitting device shall invoke the TSCH retransmission algorithm." (Section 6.2.5.3 of IEEE 802.15.4-2015)

The latter frame is not transmitted on a shared link nor on a dedicated link. There is no link scheduled :-)

Best,
Yatch


> On Oct 6, 2018, at 3:28, Tero Kivinen <[e-mail]> wrote:
> 
> Yasuyuki Tanaka writes:
>> I came across another question on the retransmission algorithm.
>> Could you help...? 
>> 
>> What should we do when a frame sent in an un-scheduled slot is not
>> acknowledged? 
>> 
>> As you know, with the frame pending bit, we can send a frame even if
>> we don't have a cell scheduled at that time (Section 7.2.1.3 of IEEE
>> 802.15.4-2015). While I don't think the back-off wait is necessary
>> in this case, this topic is not covered by IEEE 802.15.4-2015... 
> 
> The frame pending bit operations in TSCH is bit underspecified in the
> 802.15.4-2015. We do have comment CID 93 about that in the current
> letter ballot. The TG4md documents can be found from [1] and there is
> consolidated comments from the last letter ballot [2], and from there
> you can find the CID 93 that is talking about the frame pending bit on
> TSCH.
> 
> This rewrite will most likely add some more text there specifying what
> link scheduled means, and when to send the pending bit and so on, I
> will make sure it also covers the case where there is no ACK.
> 
> My guess is that if there is no ACK, then you abort sending further
> frames, and move to the normal TSCH operation, i.e., the
> retransmission happens using normal rules.
> 
> The reason why we do not have ACK, could be:
> 
> 1) Transmitted frame did not reach recipient. In this case recipient
> will time out as it is not receiving any frames in timeslot even when
> the frame pending bit was on on previous frame, so it should most
> likely stop listening on that channel and resume operations.
> 
> 2) Transmitted frame did reach other end, but the ACK did not reach
> back. In this case the recipient will process the frame, and if that
> frame it received has frame pending bit on, it will stay on this
> channel for next frame.
> 
> The transmitter has no idea which of those two things happened, thus
> only safe thing it can do is to abort also and continue normal
> schedule.
> 
> But, that is just my guess what should happen, I am not sure what
> implementations do, and I do not think we have text in standard
> describing exactly what to do.
> 
> [1] https://mentor.ieee.org/802.15/documents?is_group=04md
> [2] https://mentor.ieee.org/802.15/dcn/18/15-18-0433-06-04md-lb150-consolidated-comments.xlsx
> -- 
> [e-mail]