doc.: IEEE <doc#>

Slides:



Advertisements
Similar presentations
Doc.: IEEE Submission Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Drafting of IEEE e.
Advertisements

Submission Title: [Resolution on comment #20,22 and 30]
<month year> <doc.: IEEE doc> May 2015
doc.: IEEE <doc#>
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<month year> doc.: IEEE < e>
<May,2009> doc.: IEEE <doc .....> <July 2009>
September 2016 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Comment resolution for i-024 and i-151.
doc.: IEEE <doc#>
Submission Title: Example of P2P route discovery
September 2015 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposal for IEEE e – MAC:Superframe.
doc.: IEEE <doc#>
Submission Title: [Proposed resolution to MIMO CES]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
September 2016 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Comment resolution for i-024 and i-151.
September 2016 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Comment resolution for i-16] Date Submitted:
Submission Title: [Common rate resolution]
Submission Title: [Resolution on comment #20,22 and 30]
September 2015 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposal for IEEE e – MAC:Superframe.
September 2016 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Comment resolution for i-022] Date Submitted:
September 2016 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Comment resolution for i-022] Date Submitted:
doc.: IEEE <doc#>
Submission Title: [Resolutions for CID 85, 86, and 87]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Submission Title: [Proposed resolution to CID#133]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE /XXXr0 Sep 19, 2007 June 2009
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Submission Title: [Frame and packet structure in ]
doc.: IEEE <doc#>
Submission Title: [Proposed resolution to CID#133]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<month year> doc.: IEEE < e>
<month year> <doc.: IEEE doc> January 2016
doc.: IEEE <doc#>
doc.: IEEE <doc#1>
<month year> doc.: IEEE s March 2019
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Submission Title: [Proposed resolution to cid#1064]
July 2010 <month year> doc.: IEEE g Doc.: IEEE g
June, 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [OFDM PHY Mode Representation] Date Submitted:
September 2016 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Comment resolution for i-024 and i-151]
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
<month year> <doc.: IEEE doc> September 2015
Doc.: IEEE Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Summary.
Submission Title: [Common rate resolution]
Submission Title: [Common rate resolution]
Submission Title: TG9ma Agenda for September Meeting
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: CID 422 Proposal Date Submitted: 14 August,
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: More LB156 Comment Resolution Date Submitted:
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: MLME-SOUNDING and MLME-CALIBRATE comment.
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: More LB156 Comment Resolution Date Submitted:
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: CID 422 Proposal Date Submitted: 14 August,
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: MLME-SOUNDING and MLME-CALIBRATE comment.
Jan 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TeraHertz Closing Report Date Submitted: January.
Presentation transcript:

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> <Mar. 2016> Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution on comment #27] Date Submitted: [25 May 2016] Source: [Kiyoshi Toshimitsu and Ko Togashi] Company: [Toshiba Corporation] Address1: [1-1-1 Shibaura, Minato-ku, Tokyo 108-8001] E-Mail1: [kiyoshi.toshimitsu@toshiba.co.jp, ko.togashi@toshiba.co.jp] Re: [In response to 15-16-0162-01-003e-lb114-consolidated-comments] Abstract: [This document presents a resolution on comment #27 in 15-16-0162-01-003e-lb114- consolidated-comments.] Purpose: [Resolving the comment #27] 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 contributors acknowledge and accept that this contribution becomes the property of IEEE and may be made publicly available by P802.15. Toshimitsu, et al. (Toshiba) <author>, <company>

Comment and the resolution <Mar. 2016> Comment and the resolution Comment #27 and 1067 Page Sub-clause Line # Proposed Change 56 7.3a.1 2 (1) For PPC, what is the behavior when ACK is not received after sending an Association Response? (2) For DEV, what is the behavior when ACK is not received after sending an ACK to PPC in reply to an Association Response? (1) PPC should change the state to Asynchronous phase and resend Association Response after a RIFS period. (2) DEV should change the state to Asynchronous phase and resend ACK after a RIFS period. Toshimitsu, et al. (Toshiba)

<Mar. 2016> Resolution In Sec.7.3a.1, insert the text at the end of last sentence as follows: The HRCP PNC determines that the association procedure has completed when it either receives: a) a Stk-ACK in response to the Association Response, as shown in Figure 7-20b, or b) a data frame from an already-approved DEV, as shown in Figure 7-20c. The DEV that receives an Association Response from the HRCP PNC determines that the association procedure has completed and transmits a Stk-ACK in response to the Association Response. When a Stk-ACK or data frame is not received by the HRCP PNC after sending an Association Response, the HRCP PNC should change the state to Asynchronous phase, and resend the Association Response after a RIFS period, as shown Figure 7-20d and 7-20e. For the case of Figure 7-20f, the DEV sends the last correctly received sequence number to the HRCP PNC, since the DEV could only read the MAC header of the last frame. The HRCP PNC then transmits the same Association Response again. Toshimitsu, et al. (Toshiba)

Association PNC Data Resp. (SN=0) Stk- ACK DEV <Mar. 2016> HRCP PNC Association Resp. (SN=0) Data Stk- ACK DEV SIFS SIFS Last Received Sequence Number = 0 Figure 7-20b - DEV receives Association Response from the HRCP PNC correctly Noda, et al. (Sony)

PNC Association Resp. (SN=0) Stk- ACK Stk- ACK Data DEV <Mar. 2016> PNC sends Stk-ACK after waiting one RIFS. Last Received Sequence stays at  0 HRCP PNC Association Resp. (SN=0) RIFS Stk- ACK (Error) Stk- ACK Data DEV SIFS SIFS Last Received Sequence Number = 0 Last Received Sequence Number is incremented = 0 By receiving data, PNC deduces that DEV has correctly received Association Response even though the Stk-ACK did not arrive. Figure 7-20c - DEV receives Association Response correctly, but HRCP PNC does not receive Stk-ACK. Toshimitsu, et al. (Toshiba)

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> <Mar. 2016> PNC sends Stk-ACK. Last Received Sequence Number is not incremented  0 retransmit HRCP PNC Association Resp.(SN=0) RIFS Stk- ACK Association Resp.(SN=0) (Error) Stk- ACK DEV SIFS SIFS Last Received Sequence Number is not incremented  0x3FF Figure 7-20d - DEV receives Association Response correctly, but HRCP PNC does not receive Stk-ACK (MAC Header Error). PNC sends Stk-ACK. Last Received Sequence Number is not incremented  0 HRCP PNC Association Resp. (SN=0) RIFS Stk- ACK Data (Error) Stk- ACK Stk- ACK DEV SIFS SIFS SIFS Last Received Sequence Number = 0 Last Received Sequence Number is incremented = 0 Figure 7-20e - DEV receives Association Response correctly, but HRCP PNC does not receive Stk-ACK (MAC Header Error). Toshimitsu et al. (Toshiba) <author>, <company>

PNC Association Resp.(SN=0) Association Resp.(SN=0) Stk- ACK DEV <Mar. 2016> retransmit HRCP PNC Association Resp.(SN=0) Association Resp.(SN=0) (Partial Error) Stk- ACK DEV SIFS SIFS Last Received Sequence Number is not incremented  0x3FF Figure 7-20f - DEV does not receive Association Response, but does receive the MAC Header part correctly. Toshimitsu, et al. (Toshiba)

<Mar. 2016> END Toshimitsu, et al. (Toshiba)