November 2008 doc.: IEEE November 2008

Slides:



Advertisements
Similar presentations
Doc.: IEEE g Submission November, 2010 Roberto Aiello, ItronSlide 1 Project: IEEE P Working Group for Wireless Personal Area.
Advertisements

<January 2002> doc.: IEEE <02/139r0> 10/3/2017
Submission Title: [LB 28 Results] Date Submitted: [14 March 2005]
Project: IEEE Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposals for adding a version number and for the treatment.
Project: IEEE Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposals for adding a frame version number and for the.
Submission Title: [Add name of submission]
doc.: IEEE <doc#>
Name - WirelessHD doc.: IEEE g July 2010
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
doc.: IEEE <doc#>
Submission Title: [WG-Treasurer’s Report July04]
Submission Title: [Beacon scheduling MAC hooks]
doc.: IEEE <doc#>
Submission Title: [WG-Treasurer’s Report Sept04]
May 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Resolution To The FCC Part
NOV 01 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Application Specific Information Element] Date.
Project: IEEE Wireless Personal Area Networks (WPANs)
Submission Title: [WG-TG3 Closing Report Nov03]
March 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Toumaz response to TG6 Call for Applications]
<May,2009> doc.: IEEE <doc .....> <July 2009>
doc.: IEEE <doc#>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution of CID 139] Date Submitted:
Submission Title: [Compromise Proposal] Date Submitted: [12Sept2004]
Submission Title: [802.11n Liaison Report May 2009]
doc.: IEEE <doc#>
<month year> doc.: IEEE <xyz> January 2001
Doc.: IEEE /XXXr0 Sep 19, 2007 Nov 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)‏ Submission Title: [Comment.
Submission Title: [Common rate resolution]
<month year> <doc.: IEEE doc> March 2015
Submission Title: [Bluetooth SIG Liaison Report]
Submission Title: [Resolutions for CID 85, 86, and 87]
Submission Title: [WG WNG Liaison Report January08]
Submission Title: [Compromise Proposal] Date Submitted: [12Sept2004]
Submission Title: TGe Liaison Repor
Submission Title: [TG3a Closing Report September 2005]
Submission Title: IEEE : Power Save Proposal
<month year> doc.: IEEE <xyz> November 2000
<month year> doc.: IEEE / January 2005
doc.: IEEE <doc#>
doc.: IEEE /XXXr0 Sep 19, 2007 June 2009
Submission Title: [WG-TG3b Closing Report May04]
doc.: IEEE <doc#>
Submission Title: [Frame and packet structure in ]
doc.: IEEE <doc#>
November 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Simplified geometry for the usage model.
<January 2002> doc.: IEEE <02/139r0> Nov, 2008
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#1>
September 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Discussion on MAC functionalities Date.
doc.: IEEE <doc#>
Submission Title: [WG-TG3 closing Report Jan02]
Submission Title: [WG-RR TAG Liaison Report January08]
July 2010 <month year> doc.: IEEE g Doc.: IEEE g
Submission Title: [LB 28 Results] Date Submitted: [14 March 2005]
January 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [17.
June, 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [OFDM PHY Mode Representation] Date Submitted:
November 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [15.
September 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Suggested TG3c PAR Changes] Date Submitted:
May 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Resolution To The FCC Part
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
May 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [15 May.
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> March 2015
Submission Title: [Common rate resolution]
Submission Title: [Common rate resolution]
Submission Title: Security Suite Compromise
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: CID 422 Proposal Date Submitted: 14 August,
Submission Title: [TG3a Compromise Direction]
Presentation transcript:

November 2008 doc.: IEEE 802.15-08-0787-01 November 2008 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution of CID 139] Date Submitted: [11 Nov 2008] Source: [John R. Barr] Company [Motorola, Inc.] Address [1303 E. Algonquin Road, Schaumburg, IL, 60010, USA] Voice:[847-962-5407], FAX: [847-576-6758], E-Mail:[John.Barr@Motorola.com] Re: [] Abstract: [Rationale and editorial changes addressing CID 139 from LB47] Purpose: [Instruct technical editor on necessary changes to accept comment.] 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. John R. Barr, Motorola, Inc. John R. Barr, Motorola, Inc.

November 2008 CID 139 Comment I see no reason for requiring both CMS and MLR for SC devices. Since the CMS is the base rate for the SC PHY, it can be used for all coexistence and interoperability messages. This should allow devices to be built that guarantee coexistence while being cost effective for certain use cases. If necessary, require that al least one mode with data rate > 1 Gbps is also included. If the text in 12.2.2.5 indicating that only CMS is mandatory does not also include MLR, then the specification will be consistent with necessary use cases. John R. Barr, Motorola, Inc.

CID 139 Proposed Resolution November 2008 CID 139 Proposed Resolution On Page 67,Line 6 in clause 12.2 change: "There are two mandatory MCSs for all SC devices, The common mode signaling (CMS) and the mandatory low rate (MLR)." to "The common mode signaling (CMS) MSC shall be mandatory for all SC devices." On line 28 change: "The RS(255,239) and the shortened RS(33,17) block codes are mandatory, ..." "The RS(255,239) block code is mandatory, ...". Also, change any other place where both CMS and MLR are mandatory to just indicate CMS as mandatory. John R. Barr, Motorola, Inc.

Rationale for Accepting CID 139 November 2008 Rationale for Accepting CID 139 There are accepted requirements for low cost devices. Reducing number of required modes reduces implementation cost Clause 12.1.10 indicates that only CMS is required to enable interoperability: “The role of CMS is to enable interoperability among different PHY modes. CMS may be used for both interference mitigation and data transmission purposes.” John R. Barr, Motorola, Inc.

CID 139 Accept in Principle (First) November 2008 CID 139 Accept in Principle (First) On Page 67, Line 6 in clause 12.2 change: "There are two mandatory MCSs for all SC devices, The common mode signaling (CMS) and the mandatory low rate (MLR)." to "The common mode signaling (CMS) MSC shall be mandatory for all SC devices.” On line 28 change: "The RS(255,239) and the shortened RS(33,17) block codes are mandatory, ..." "The RS(255,239) block code is mandatory, ...” Add the following at the end of the first paragraph of clause 12.2: The mandatory low rate (MLR) or a low complexity mode employing OOK/DAMI shall be included in any PNC-capable SC DEV. John R. Barr, Motorola, Inc.

CID 139 Accept in Principle (Option 1) November 2008 CID 139 Accept in Principle (Option 1) On Page 67, Line 6 in clause 12.2 change: "There are two mandatory MCSs for all SC devices, The common mode signaling (CMS) and the mandatory low rate (MLR)." to “The mandatory MSCs for an SC device shall be either a combination of common mode signaling (CMS) and the mandatory low rate (MLR), or, alternatively, a low complexity mode employing OOK/DAMI.” Add the following at the end of the paragraph in clause 12.1.10: All PNC-capable DEVs shall implement the CMS MSC. John R. Barr, Motorola, Inc.

CID 139 Accept in Principle (Option 2) November 2008 CID 139 Accept in Principle (Option 2) On Page 67, Line 6 in clause 12.2 change: "There are two mandatory MCSs for all SC devices, The common mode signaling (CMS) and the mandatory low rate (MLR)." to “There are two mandatory MCSs for all SC devices except for low complexity mode devices, the common mode signaling (CMS) and the mandatory low rate (MLR). OOK/DAMI modes are allowed for low complexity SC devices.” Add the following rules to clause 12.1.8: An OOK/DAMI PNC-capable DEV, when operating as a PNC, shall transmit an OOK/DAMI beacon and a CMS sync frame in every superframe. An OOK/DAMI PNC-capable DEV shall be able to receive the CMS sync frame and command frames. Note: It is still possible to implement OOK/DAMI PNC-capable device that uses CMS and MLR modes. John R. Barr, Motorola, Inc.

CID 139 Accept in Principle (Final) November 2008 CID 139 Accept in Principle (Final) On Page 67, Line 6 in clause 12.2 change: "There are two mandatory MCSs for all SC devices, The common mode signaling (CMS) and the mandatory low rate (MLR)." to “There are two mandatory MCSs for all SC devices except for low complexity mode devices, the common mode signaling (CMS) and the mandatory low rate (MLR). OOK/DAMI modes are allowed for low complexity SC devices.” Note: It is still possible to implement OOK/DAMI PNC-capable device that uses CMS and MLR modes. John R. Barr, Motorola, Inc.