1. January 2011
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Proposed Comment resolution to Letter Ballot#66 for P standard/D02]
Date Submitted: [12 January, 2011]
Source: [Hind Munzer-Chebbo]
[Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya]
Company: [Fujitsu Laboratories of Europe Limited]
[Fujitsu Laboratories Limited]
Address: [Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K]
[Fujitsu Laboratories Limited, YRP R&D Center, 5-5, Hikari-no-Oka, Yokosuka-Shi, Kanagawa , Japan]
Re: [Letter Ballot #66 comment resolution for P standard/D02.]
Abstract: [To address -end-to-end acknowledgement in Two-Hop Topology Extension in IEEE ]
Purpose: [To address -end-to-end acknowledgement in Two-Hop Topology Extension in IEEE ]
Notice: This document has been prepared to assist the IEEE P 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.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

2. End-To-End ACK proposed comment resolution for IEEE802.15.6
January 2011
End-To-End ACK proposed comment resolution for IEEE
Hind Munzer-Chebbo,
Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya
Fujitsu
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

3. Content Comment Proposed Solutions January 2011
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

4. January 2011
Comment
To introduce end-to-end Acknowledgment in Two hop Topology Extension
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

5. Proposed Solutions Two alternatives solutions:
January 2011
Proposed Solutions
Two alternatives solutions:
1. Using I-Ack with optional modification Preferred
2. Using to T-poll with optional modification
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

6. 1. Using I-ACK – Optional Modification
January 2011
1. Using I-ACK – Optional Modification
Octets 1 1
MAC
Header
Sequence
Number
Frame Status Bitmap
FCS
Sequence Number field is the sequence number of the last frame received successfully by the hub or node Outer sequence number of frames sent by the node or hub
Frame Status Bitmap field is the status of the frames received by the node /hub before and including the last frame, starting from lowest significant bit
It is desired that the relaying Node does not re-send.
Hub and Relayed node shall recover the order of the received frames, because the sequence number of the frames might not be in order. -> The order recovery shall be made at least for the length of the bitmap ( in the example above, the bitmap is 1octet, so it is 8 frames)
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

7. 1. Using I-ACK –Optional modification
January 2011
1. Using I-ACK –Optional modification
In cases where a node returns from the RTT operation (direct communication between Hub and node) or where a two-hop returns to a one-hop or where the node changes the relaying node to the another one, the sequence number of the frames that have been received by the Hub is attached as shown below.
Frame
Status IE
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

8. Using I-ACK -Optional modification
January 2011
Using I-ACK -Optional modification
Frame Status IE Format
Sequence number is the sequence number for the last frame that was successful.
Sequence Number refers to sequence numbers between hub and relayed node Inner Sequence Number
Octets
Length
Frame Status Bitmap
Element ID
Frame Subtype
Sequence
Number 1 4
b0-b3
Reserved 8
b0-b7
Frame
Status
... 3
L-R
Bits
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

9. 1. Using I-ACK - Description
January 2011
1. Using I-ACK - Description
Scheduled Uplink/Downlink/Bilink Allocation
Target
Hub
I-Ack
I-Ack
I-Ack
The sequence number of the last frame that was successful.
I-Ack for the first frame of the bilink allocation should be as follows:
Sequence number=n+2
Bitmap=0b
D/M
D/M
D/M
Old
Relaying
Node
I-Ack
I-Ack
I-Ack
I-Ack
I-Ack
I-Ack
T-Poll(unicast)
T-Poll(unicast) #n
#n+1
#n+2 ～ #n
#n+1
#n+2
D/M
D/M
D/M
D/M
D/M
D/M
Relayed
Node
Scheduled Bilink Allocation
Scheduled Bilink Allocation
The outer sequence number of the encapsulated frames
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

10. 1. Using I-ACK - Description
January 2011
1. Using I-ACK - Description
Scheduled Uplink/Downlink/Bilink Allocation
Scheduled Uplink/Downlink/Bilink Allocation
Target
Hub
D/M
D/M
D/M
D/M
Even if there is no data to be sent, at least one data or Management Frame (Ack Policy=I-Ack) shall be sent. #n
#n+1
#n+2
Relaying
Node
I-Ack
I-Ack
I-Ack
T-Poll(unicast)
D/M
D/M
D/M
I-Ack
I-Ack for the first frame of the Scheduled Allocation should be as follows:
Sequence number=n+2
Bitmap=0b
Relayed
Node
I-Ack
I-Ack
I-Ack
Scheduled Bilink Allocation
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

11. 2. Using T-Poll – Optional Modification
January 2011
2. Using T-Poll – Optional Modification 1 1
Sequence
Number
Frame Status Bitmap
Sequence Number field is the sequence number of the last frame received successfully by the hub Outer sequence number of frames sent by the node
Frame Status Bitmap field is the status of the frames received by the node /hub before the last frame, starting from lowest significant bit
End-to-end Acknowledgement is only available for the uplink not for the downlink
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

12. 2. Using T-Poll - Description
January 2011
2. Using T-Poll - Description
Scheduled Uplink/Downlink/Bilink Allocation
Target Hub
Relaying
Node
(unicast)
T-Poll
Relayed
Node
In RTT operation, this bilink allocation is necessary.
-> A T-Poll is always sent to the relayed node.
-> So, it would be good to make this T-Poll carry the forwarding information as shown in the next slide.
Scheduled Bilink Allocation
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

13. 2. Using T-Poll - Description
January 2011
2. Using T-Poll - Description
Scheduled Uplink/Downlink/Bilink Allocation
Target
Hub
I-Ack
I-Ack
I-Ack
The sequence number of the last frame that was successful.
I-ACK will be used for acknowledgement of transmission in each link (just like in star topology).
Sequence number=n+2
Bitmap=0b
D/M
D/M
D/M
Old
Relaying
Node
I-Ack
I-Ack
I-Ack
T-Poll(unicast)
T-Poll(unicast) #n
#n+1
#n+2 ～
D/M
D/M
D/M
Relayed
Node
Scheduled Bilink Allocation
Scheduled Bilink Allocation
Outer sequence number
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

14. January 2011
THE END
Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu