1 / 13

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: [ Resolution of TG6 comments: S6-524, S7-123, S7-124, S7-129, S7-135, S7-144, S7-140, S7-144, S7-145 , S7-156 , S7-157 ] Date Submitted: [ 05 September, 2010 ]

farrah
Download Presentation

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: [Resolution of TG6 comments: S6-524, S7-123, S7-124, S7-129, S7-135, S7-144, S7-140, S7-144, S7-145 , S7-156 , S7-157] Date Submitted: [05 September, 2010] Source: [Rick Powell] Company [Zarlink] Address [15822 Bernardo Center Dr, Ste B, San Diego, CA, 92127] Voice:[+1 858-675-3485], FAX: [+1 858-675-3450], E-Mail:[rick.powell@zarlink.com] Re: [Proposed Resolution of D0 Comments S6-524, S7-123, S7-124, S7-129, S7-135, S7-144, S7-140, S7-144, S7-145 , S7-156 , S7-157]Abstract: [Comment resolution for letter ballot 55 for S6-524, S7-123, S7-124, S7-129, S7-135, S7-144, S7-140, S7-144, S7-145 , S7-156 , S7-157] Purpose: [Propose Resolution of D0 Comment S6-524, S7-123, S7-124, S7-129, S7-135, S7-144, S7-140, S7-144, S7-145 , S7-156 , S7-157] 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. <Rick Powell>, <Zarlink>

  2. Proposed Resolution of D0 Comment S6-524, S7-123, S7-124, S7-129, S7-135, S7-144, S7-140, S7-144,S7-145 , S7-156 , S7-157 <Rick Powell>, <Zarlink>

  3. D0 Comment S6-524 • Page 60, Sub-clause 6.7.3, Line 27 • Comment: Downlink Access Mode is redundant to BiLink Access Mode. In BiLink Access, the Hub may perform a Post at the beginning of the Allocation Interval, which is the same as a Downlink. Downlink Access Mode provides no advantage or capability that is not already present in BiLink Mode. • Proposed Change: Either: 1) Justify why Downlink access mode is required and cannot be satisfied with other modes, and that it is worth the additional complexity. Or: 2) Remove Downlink Access Mode, Downlink Request IE, and Downlink Assignment IE. • Analysis: Scheduled Bilink post allocations are identical to Scheduled Downlink allocations. In both cases, the hub is allowed to send a poll in response to the node setting the More Data bit in the Ack frames sent to the Hub. However BiLink is designed to send polls in addition to posts, which may not be needed on most allocations for downlink allocations. • Proposed Resolution: 1) Remove Downlink Access Mode, Downlink Request IE, and Downlink Assignment IE. • 2) Add a bit in the BiLink Allocation Request IE and the Delayed BiLink Allocation Request IE that requests only downlink frames to be sent to the node unless the node sets the More Data bit to one in an I-Ack or B-Ack frame to the hub. <Rick Powell>, <Zarlink>

  4. D0 Comment S7-123 • Page 61, Sub-clause 6.7.4, Line 1 • Comment: In the Bilink Allocation Request, there is no way for the node to indicate if this allocation is primarily for uplink or downlink, and if the first transaction should be a Post or a Poll. • Proposed Change: Add a bit in the Bilink Allocation Request that indicates that a node requests the first transaction to be a Poll or a Post. In the case of a Post, the Post would only be made if there is a pending downlink frame for the node. In the case when there is no pending downlink, then the first transaction would always be either a Poll or T-Poll. • Proposed Resolution: Add a bit in the Bilink Allocation Request IE and the Delayed Bilink Allocation Request IE which indicates that the node wants the first transaction to be either a post or a poll. If the request is set to a post first, the post would only be sent it the hub has a management/data frame for the hub, with no need to send a null management/data frame when no management/data frame is available. <Rick Powell>, <Zarlink>

  5. D0 Comment S7-124 • Page 61, Sub-clause 6.7.4, Line 1 • Comment: How does a node request the need for a T-Poll in a Bilink or Delayed Bilink Allocation Request? • Proposed Change: Either: Add a bit in the Bilink Allocation Request that indicates that a node requires a T-Poll when the poll does not occur at the beginning of the allocation period. • Proposed Resolution: Add a bit in the Bilink Allocation Request IE and the Delayed Bilink Allocation Request IE which indicates that the node wants a T-Poll for the first Poll of a BiLink Allocation Interval if the “On-Time” bit is not set to one on the first frame from the Hub on an a BiLink Allocation Interval or Delayed BiLink Allocation Interval. <Rick Powell>, <Zarlink>

  6. D0 Comment S7-129 • Page 72, Sub-clause 7.2.7, Line 19 • Comment: What is the correct behavior when an Acknowledgement is sent by the Node but not received at the Hub? Can the Node go to sleep after is sends the Acknowledgement? • Proposed Change: After determining that the Node is not transmitting, the Hub may attempt to retransmit the previous frame. There may be several indications by the Hub that the Ack failed. It may be no RSSI level above RSSImin, it may be bad HCS, or it may be bad FCS. The Hub may need to know the reason for no-Ack to determine when to retransmit. After a node sends an Ack frame to the Hub, and no additional data is expected from the Hub, the node shall wait pSISF+Delta to verify that the Hub is not attempting to retransmit the previous frame??? • Analysis: This issue applies to scheduled downlink, and scheduled and unscheduled posts. If the hub does not receive the expected acknowledgement frames, then there needs to be a definition of when it may attempt a retransmission while avoiding a collision with the node. <Rick Powell>, <Zarlink>

  7. D0 Comment S7-129 (continued) Proposed Resolution: Add the following to the “use of” scheduled downlink allocations and scheduled and unscheduled polled allocations: The hub may start a new transmission or retransmission of a management/data frame pSIFS plus some delta, after the end of the expected acknowledgement frame when the acknowledgement frame is not received by the hub. The hub may start a new transmission of a management/data frame pSIFS, after the end of the expected acknowledgement frame when the acknowledgement frame is received by the hub. <Rick Powell>, <Zarlink>

  8. D0 Comment S7-135 • Page 75, Sub-clause 7.2.7.4, Line 2 • Comment: Figure 55 show an uplink frame being transmitter after a B-Ack without a Poll during a scheduled uplink allocation. Figure 66 on Page 86 shows a B-Ack+Poll sent before the Node resumes uplink frames. Which is correct and where is this defined? May a Node transmit a Frame after an I-Ack or B-Ack without receiving a Poll? This is inconsistent with other access modes.?. • Proposed Change: During a Scheduled Uplink Allocation Interval, once the Node receives either a B-Ack or I-Ack, it must wait for a Poll before resuming uplink frames. If the Ack policy is either L-Ack or N-Ack in the uplink frame, then the node may transmit another uplink frame no earlier than pMIFS after the previous frame, and no later than pMIFS + Delta??? after the previous frame without receiving a Poll. Correct figure 55 to show a B-Ack+Poll before the Node resumes uplink frames during a scheduled uplink allocation • Proposed Resolution : The proposed change is rejected. However, Figure 66 needs description information added to the text to describe why a B-Ack+Poll occurs within a scheduled uplink allocation. <Rick Powell>, <Zarlink>

  9. D0 Comment S7-140 • Page 76, Sub-clause 7.3.1, Line 15 • Comment: Figures 57, 58 and 59 show no period for broadcast/multicast frames, and no period for unscheduled polling. • Proposed Change: Modify drawing to show periods for broadcast/multicast frames and for unscheduled polling. • Proposed Resolution : Broadcast and Multicast frames occur within the superframe for T-Poll frame transmission to allow connection requests from unconnected nodes. By the current draft definition, these may occur anywhere within the superframe. Diagrams for unscheduled polling are provided in IEEE Doc # IEEE 802.15-10-0xxx-0-0006. <Rick Powell>, <Zarlink>

  10. D0 Comment S7-144 • Page 77, Sub-clause 7.3.2, Line 21 • Comment: In a Beaconless Mode with Superframe boundaries, how are the contention periods known to nodes attempting to connect to the network? Are B2 Frames required in a Beaconless Mode with Superframe boundaries? Is this mode only used with implants in the MICS band? • Proposed Change: Either explain, or remove Beaconless Mode with Superframe boundaries. • Analysis: Beaconless Mode with Superframe boundaries is not an efficient mode, and is not required in the MICS band. • Proposed Resolution: Remove Beaconless Mode with Superframe Boundaries. For MICS, use Beaconed mode with Superframe boundaries or use non-superframe mode with T-Polls. <Rick Powell>, <Zarlink>

  11. D0 Comment S7-145 • Page 77, Sub-clause 7.3.2, Line 21 • Comment: In Figure 59, there is no Frame Structure defined. There is no EAP1/2, no RAP1/2, no CAP, no B2, no period for broadcast/multicast frames, no period for unscheduled polling. • Proposed Change: Show structure and options for superframe structure in Beaconless Mode with Superframe boundaries. Clarify if this mode has restrictions, such as use only for MICS band operation. • Proposed Resolution : Accepted in principal. Additional information needs to be provided. <Rick Powell>, <Zarlink>

  12. D0 Comment S7-156 • Page 89, Sub-clause 7.7.2, Line 14 • Comment: How does the hub know if it needs to provide a T-Poll time reference update to the node? Is there a mechanism for a node to indicate that it requires the hub to provide it a time reference? It is not clear when a T-Poll is required or when a Poll is allowed.. • Proposed Change: Add a Table to define when a T-Poll is required or when a Poll is allowed. Add a bit in the Connection request to indicate that a node needs T-Polls. • Proposed Resolution : Same as S7-124. <Rick Powell>, <Zarlink>

  13. D0 Comment S7-157 • Page 91, Sub-clause 7.7.2, Line 7 • Comment: At what time if it permissible for the node to go to sleep. In the case where the node has sent an Ack frame, if the Hub does not receive the Ack, the Hub may attempt to retransmit. Is the Node required to wait a minimum amount of time after sending an Ack before going to sleep to see if the Hub is retransmitting? • Proposed Change: After a node sends an Ack frame to the Hub, and no additional data is expected from the Hub, the node shall wait pSISF+Delta to verify that the Hub is not attempting to retransmit the previous frame??? • Proposed Resolution : Accept. Add the following to the “Using” sections of Scheduled Uplink and Scheduled Bilink: After a node sends an Ack frame to the Hub, and no additional data is expected from the Hub, the node shall wait pSISF+Delta to verify that the Hub is not attempting to retransmit the previous frame before going to sleep. <Rick Powell>, <Zarlink>

More Related