1 / 14

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

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 ]

Antony
Télécharger la présentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

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

  4. 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: • 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 1 1 Octets 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 Nodedoes 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 • 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. 1 0 1 0 3 L-R 3 L-R Frame Status Length Element ID ... Frame Status 8 b0-b7 4 b0-b3 4 b0-b3 8 b0-b7 Frame Subtype Reserved Sequence Number Frame Status Bitmap 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 Bits Hind Munzer-Chebbo, Ichirou Ida, Kaoru Yokoo, Kikuzuki Tatsuya - Fujitsu

  9. 1. Using I-ACK - Description Scheduled Uplink/Downlink/Bilink Allocation I-Ack I-Ack I-Ack Target Hub 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

  10. 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 T-Poll(unicast) I-Ack I-Ack I-Ack D/M D/M D/M 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

  11. 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 Scheduled Uplink/Downlink/Bilink Allocation Target Hub Relaying Node T-Poll (unicast) 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 Scheduled Uplink/Downlink/Bilink Allocation I-Ack I-Ack I-Ack Target Hub 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

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

More Related