January 2011 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Comment resolution to Letter Ballot#66 for P802.15.6 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 239-0847, Japan] E-Mail: [hind.chebbo@uk.fujitsu.com] [ida.ichirou@jp.fujitsu.com, yokoo@labs.fujitsu.com, kikuzuki@labs.fujitsu.com] Re: [Letter Ballot #66 comment resolution for P802.15.6 standard/D02.] Abstract: [To address -end-to-end acknowledgement in Two-Hop Topology Extension in IEEE802.15.6] Purpose: [To address -end-to-end acknowledgement in Two-Hop Topology Extension in IEEE802.15.6] Notice: This document has been prepared to assist the IEEE P802.15. 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 P802.15. Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

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

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

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

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

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

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

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

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=0b11111101 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

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=0b11111101 Relayed Node I-Ack I-Ack I-Ack Scheduled Bilink Allocation Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

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

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

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=0b11111101 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

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