21-06-07xx-00-0000

1

IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-06-07xx-00-0000

Title: Benefits of MIH Link Transmission Events (LB Comment #260)

Date Submitted: July, 2006

Presented at IEEE 802.21 session #15 San Diego

Authors or Source(s):

  Qiaobing Xie

Abstract: Explain the importance and benefits of MIH Link Transmission Events

21-06-07xx-00-0000

2

IEEE 802.21 presentation release statementsThis document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21.

The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html > 

21-06-07xx-00-0000

3

LB Comments #260

Comment:

Link Transmission events: It is not clear why we need this. For example, is this hop-by-hop link transmission information or end-to-end? If it is not end-to-end, providing this indication will not help much. Upper layer still requires end-to-end infromation.

Suggested Remedy:

Either discuss this more details or delete this event.

Response:• 1. Link transmission events are ***local only*** (see line 47, page

38, in Table 3), so the first part of the question should be answered already.

• 2. The usefulness of local transmission events is fully explained in the current text (see line 26, page 35).

• 3. It is never the intention nor a design objective of link transmission events to replace any upper layer end-to-end transmission status information.

• 4. Upper layer end-to-end transmission status indication can not serve the same purpose as the link transmission events, as explained clearly in the current text (line 22, page 35).

21-06-07xx-00-0000

4

Without Link Transmission Events

data senderdata

receiverAN 1

AN 2CN

in1in2

data senderdata

receiverAN 1

AN 2CN

in1in2

handover

unsent SDUsin MAC queue

unsent SDUs“flushed”

data senderdata

receiverAN 1

AN 2CN

in1in2

end-to-end report of lost SDUs

data senderdata

receiverAN 1

AN 2CN

in1in2

Upper layer now tries to re-send lost SDUs

Sometime later (e.g., TCP timeout)…

Upper layer has already experienced data loss!

21-06-07xx-00-0000

5

With Link Transmission Events

data senderdata

receiverAN 1

AN 2CN

in1in2

data senderdata

receiverAN 1

AN 2CN

in1in2

handover

unsent SDUsin MAC queue

unsent SDUs “flushed” and upper layer immediately gets indication about failed transmission

data senderdata

receiverAN 1

AN 2CN

in1in2

Upper layer immediately re-sends lost SDUs, without waiting for e2e indication

data senderdata

receiverAN 1

AN 2CN

in1in2

If the re-send is quick enough, the receiver may never notice data loss ever occurred.

21-06-07xx-00-0000

6

• It is easier to see the benefit of link transmission status indication when "failure" is reported.

• Assuming an upper layer is doing end-to-end reliable data transfer and using a timer plus retransmission buffer mechanism as you mentioned above to achieve the e2e data reliability. And we assume the device has two interface Link_A and Link_B and it is now using Link_A.

• When Link_A starts to go down (say, the user moves away from Link_A coverage), we will get a Link_A_down event at some point of time. Then the upper layer will do a handover and switch the service to Link_B. So far so good.

• However, when Link_A goes down, there may very likely still be some PDUs in Link_A MAC ARQ which have not been acked (MAC ARQ de-queues data already acked by its peer MAC ARQ). Typically, the MAC ARQ of Link_A will "flush" (ie, discard) the un-acked data from its queue after the link is down.

• Now these PDUs discarded by Link_A MAC ARQ will never reach their destination and the upper layer will have no idea the PDUs were discarded at its own MAC layer until the upper layer's own retransmission timer expires or a NACK comes back over Link_B from the far-end upper layer. In either case, the time between the data is lost at the local MAC and the upper layer finds out could be several seconds long, depending on the situation. Of cause, the upper layer will then try to re-send the lost PDUs and so on.

• Now the benefit of a local link transmission status indication should become clear - when Link_A MAC ARQ "flushed" the un-acked PDUs, the upper layer is immediately informed by one or more link transmission status indication, telling it which PDUs have failed to be transmitted. Knowing this information, the upper layer can immediately re-send those PDUs once Link_B is up and working, without waiting for a retranmission timer expiration or a NACK from its peer endpoint. If the re-send by the upper layer is done quick enough, the far-end peer may never know that those PDUs were once discarded and re-sent. Thus, optimally the in-flight data loss from the far-end receiver's view is avoided (or reduced). At the minimal, the delay for re-sending the lost data will be reduced, so as to lower the disruption to the data flow due to the handover.

Benefits of MIH Link Transmission Events