July 2010
doc.: IEEE 802.22-10/0114r05
IEEE P802.22 Motions at the July Plenary EC Meeting
IEEE P802.22 Wireless RANs
Date: 2010-07-16
Authors:
Name
Company
Address
Phone
email
Apurva N.
Mody
BAE Systems
P. O. Box 868,
MER 15-2350,
Nashua, NH 03061
1-404-8190314, 1-603885-2621
apurva.mody@baesyst
ems.com,
apurva_mody@yahoo.
com
Gerald
Chouinard
Communications
Research Center,
Canada
1-613-9982500
Gerald.chouinard@crc
.ca
Notice: This document has been prepared to assist IEEE 802.22. 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 grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE
Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.22.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures http://standards.ieee.org/guides/bylaws/sb-bylaws.pdf including the
statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to
patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard
is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
Apurva N. Mody < apurva.mody@ieee.org > as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a
draft standard being developed within the IEEE 802.22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at patcom@iee.org.
>
Submission
Slide 1
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion 1
Motion for a Conditional Approval to forward the
IEEE P802.22.1 to the IEEE SA RevCom
Submission
Slide 2
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the
IEEE P802.22.1 to the IEEE SA RevCom
Rules
Motions requesting conditional approval to forward
when the prior ballot has closed shall be accompanied
by:
• Date the ballot closed
• Vote tally including Approve, Disapprove and
Abstain votes
• Comments that support the remaining disapprove
votes and Working Group responses.
• Schedule for confirmation ballot and resolution
meeting.
Submission
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 to the IEEE SA RevCom
Number of People in the Sponsor Ballot Pool = 174
IEEE
Sponsor /
Re-circ
Ballot
Respo
nse
Ratio
Approval
Ratio
Negative
Votes
Number of
Negative
Comments
Received
Sponsor
Ballot #1
Open – Feb 5
2009, Closed
– Mar 23,
2009
77%
91%
10 negative
votes with
comments, 1
negative vote
without
comments
= 41
Comments P802.22
addressed .1 Draft
& resolved
7
prepared
Sponsor
Ballot Recirc #1
Open – Jun
7, 2010,
Closed Jun
22, 2010
79%
8 negative
votes with
comments,1
negative vote
without
comments
13
Comments P802.22
addressed .1 Draft
& resolved 8 being
prepared
Submission
with 15
abstains
93%
with 16
abstains
Slide 4
No new
disapproves
Comment
Resolutio
n Status
Draft
Status
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Negative Comments and Commentor Details
• 13 Comments were received from Peter Ecclestine during the P802.22.1 Draft 7
Sponsor Ballot Re-circ #1
• Remaining 7 Negative Voters did not submit any comments during Re-circ #1
• The Comments were addressed and resolved. The comment resolutions are
incorporated here-in entirely and can also be found at
https://mentor.ieee.org/802.22/dcn/10/22-10-0104-03-0001-tg1-sponsor-ballotcomments-d7.xls
• Negative comments resolved but carried forward from the SB and the comment
resolutions are also included in the references at the end of this presentation.
• The comment resolutions were circulated in the WG Electronic Confirmation
ballot and we received >75% approval ratio for the proposed resolutions
• Peter Ecclestine and Shulan Feng have agreed to change their Dis-approve vote
to APPROVE, based on the comment resolutions and the changes to the draft
during SB and Re-circ #2.
Submission
Slide 5
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Negative Comments from Peter Ecclestine Received During SB Re-circ #1 and
the P802.22 WG Responses
Vote
Category
Disapprove Technical
Disapprove
Editorial
Submission
Must Be
Comment
Satisfied
No
I disagree with the resolution to Initial
SB comment 47 on the use of "Shall",
"Should", "Must" and "May" as the
2009 IEEE Standards Style Manual
clause 13 Word usage defines the use
of these words in IEEE standards, and
gives sample text for inclusion in the
standard. The comment was agreed to
, with resolution "To be added", but it
was not added.
Yes
I disagree with the resolution to Initial
SB comment 49 - renumber all
occurrances of 802.22 to P802.22, as
a published standard does not have
the "P", and in most cases the
references are to devices compliant
with the approved IEEE Std. 802.22<year>, and there is no compliance
(nor approved PICS) to an unapproved
draft.
Proposed Change
Resolution Detail
Add "Word usage"
paragraph per 2009
IEEE Standards Style
Manual 13.1.
The reason why the Comment Resolution Committee disagrees with this
comment is because:
This type of indication is not present in other published standards by IEEE
802.
Resolution
Status
Disagree
Previous circulation promised to implement this, however, such "Word
usage" is not present in other 802 Standards.
E-mail from IEEE SA Sr. Program Manager - Michele Turner m.d.turner@ieee.org - "Comment # 1 The definition of shall, must, and
should does not have to be added to the standard. The style manual gives
guidance on the verbs however it is not a requirement to add them to the
document."
Only use P802.22
All occurrences of 802.22 should have a P in front of it.
when referring to the Apurva has scanned the document and there is no such occurrence of
draft standard, not the 802.22 without a P in front of it.
published standard or
standards-compliant
devices.
Slide 6
Agree in
Principle
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Negative Comments from Peter Ecclestine Received During SB Re-circ #1 and
the P802.22 WG Responses
Disapprove Technical
Submission
Yes
At www.secg.org, SEC 4 is not a
published standard, rather it is a draft
document. SECG patent policy seems
circumspect
http://www.secg.org/index.php?action
=secg,about_patents about what the
status of IPR in an unapproved SEC
document are.
Replace Certicom
SEC 4 ECQV Implicit
Certificate Scheme
with TLS ECDHE
ECDSA with a nonencumbered NIST
Suite B ECC that
conforms to FIPS-1402.
This comment has been made for the section of the draft that does not
Out of scope
have red lines and that has not changed from Draft D6 to D7. Neither any
and
related comment was made during the Sponsor Ballot. So this comment is Disagree
Out of Scope.
The technical reasons why the Comment Resolution Committee disagreed
with this comment are as follows:
1) TLS use of ECDHE or ECDSA as specified in RFC 4492 "Elliptic Curve
Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)" is
not unencumbered. Implementers of that RFC require a copy of IPR
disclosure that Certicom filed with IETF Secretariat. The details of this
filing can be found at https://datatracker.ietf.org/ipr/1154/. IEEE 802.22 has
also obtained a LOA from Certicom for similar purposes to allow
implementors of 802.22.1 to make use of the ECC technology. The LOA
can be found on the 802.22 Web site <www.802.22.org/22> under the
Letter of Assurance section. Commentor's point/issue with regard to IPR
issues is no longer valid.
2) Furthermore, the method the commentor is prescribing would result in
usage of an authentication credential that is much larger in size (on the
order of kB), and would not be feasible for implementation in a device with
limited power for processing and limited data channel bandwidth for
transmission. Performing a TLS ECDHE-ECDSA key exchange would add
considerable protocol overhead.
3) Also, ECDHE-ECDSA, as specified in for TLS, is used to negotiate a
session key, possibly mutual authenticated key agreement.
4) 802.22.1 use of certificates and signatures is for the purpose of
authenticating messages by way of digital signatures. The techniques
selected ECQV and ECPVS are the most efficient bandwidth wise and
computationally.
5)The ECC implicit certificate mechanism is more appropriate to the
capabilities of the radio to be used for transmitting the beacon. The implicit
Slide 7
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Negative Comments from Peter Ecclestine Received During SB Re-circ #1 and
the P802.22 WG Responses
Disapprove
Editorial
Yes
"An IEEE P802.22.1/D6 device"
should be ""An IEEE 802.22.1compliant device", to be correct after
this standard is published.
Per comment, also
Introduction page iii
line 3, 3.3, 7.4.5 and
many places in Annex
C.
E-mail from IEEE SA Sr. Program Manager - Michele Turner m.d.turner@ieee.org - The letter P needs to be there in front of 802.22.1
since the standard has not been approved to go to the RevCom. The IEEE
staff will remove the letter P in front of 802.22.1 before the standard goes to
the RevCom. Michelle - "When referring to the technology it is ok to leave
as is. However, I would suggest leaving as is without the word 'compliant',
since it is already implied that it is compliant. "
Agree in
Principle
Action: Replace "IEEE P802.22.1/D6" by "IEEE P802.22.1"
Disapprove Technical
Submission
Yes
I agree with Comment 67 on the initial
ballot, "Due to the fact that there is no
gap in the operation of the beacon in
Figure 2 (b), the 802.22 CPE will not
have an opportunity to report to the BS
that there is a beacon present. That
is, the beacon continuously "jams"
without any respite.". I disagree with
the approved comment resolution
"Monique to reitterate previous
rejection rationale."
I suggest leaving some
interval, likely more
than a 802.22 WRAN
frame and possibly 2
frames to solve the
alignment issue, so
that CPE can report
the presence of the
beacon.
On the downstream, the CPE will receive a 6 MHz wide signal from the BS
which, if interfered by a narrowband beacon signal (77 kHz), survive the
beacon signal due to the narrow-band nature of the interference. On the
upstream, the likelihood of the beacon creating interference at the BS is
unlikely because the beacon is located close to the CPE but far from the
BS. The beacon is transmitted at a much lower power than the CPE
upstream. In case where the beacon is close to the BS, the BS will detect
it and abide by the Policies 4, 5 and 6 as defined in the IEEE P802.22 D3
base standard in Table 251.
The gist of the policies is that the CPE should not be allowed to transmit if
it is not registered to the BS since it would interfere with the wireless
microphones that it tries to protect, however, if the CPE is already
registered with the BS, then the CPE shall send a UCS to alert the BS of
the presence of the detected signal in its coverage even if it did not plan to
transmit because of the potential interference from the downstream
transmission.
Slide 8
Disagree
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Negative Comments from Peter Ecclestine Received During SB Re-circ #1 and
the P802.22 WG Responses
Disapprove
Editorial
No
Disapprove Technical
Yes
Disapprove
Yes
Editorial
There are two periods at the end of the Per comment
first sentence.
I disagree with the resolution to Initial
SB comment 1 about the NPD
codewords - "The RTS codewords that
were chosen have been voted by the
task group and approved by the
working group." - the draft is in
Sponsor Ballot, it is proper to
comment on the complexity of
implementation, and the Comment
Resolution Committee is charged with
responding to comments, the
response should reference the
decision of the CRC.
"An IEEE P802.22.1/D6 PHY" should
be ""An IEEE 802.22.1-compliant
PHY", to be correct after this standard
is published.
Agree in
Principle
Bring back the RTS
codewords in Draft
2.0, which has been
shown by simulation
results that it can fulfill
the requirement
sufficiently, and with a
very simple
implementation
complexity.
The RTS code words were changed in Draft D4 and since then the code
words have remained the same, with no technical changes made to this
section. The RTS codewords that were chosen have been voted by the
task group and approved by the working group because of their superior
synchronization performance as compared to the other codewords that
were proposed.
Disagree
Per comment
When 802.22.1 is qualifying a device, the word "compliant" is needed. If it
is a portion of the Standard like the "PHY", the word "compliant" is not
needed.
Agree in
Principle
E-mail from IEEE SA Sr. Program Manager - Michele Turner m.d.turner@ieee.org - The letter P needs to be there in front of 802.22.1
since the standard has not been approved to go to the RevCom. The IEEE
staff will remove the letter P in front of 802.22.1 before the standard goes to
the RevCom.
Action: Replace "IEEE P802.22.1/D6 PHY" by "IEEE P802.22.1 PHY"
Pile-on comment from Shulan Feng from the SB. Since then, Shulan has agreed to
change his vote from Disapprove to Approve for this comment.
Submission
Slide 9
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Negative Comments from Peter Ecclestine Received During SB Re-circ #1 and
the P802.22 WG Responses
Disapprove Technical
Submission
Yes
The cryptographic mechanisms should
use a non-encumbered NIST Suite B
ECC that conforms to FIPS-140-2,
rather than the Certicom SEC 4 ECQV
Implicit Certificate Scheme.
Replace Certicom
SEC 4 ECQV Implicit
Certificate Scheme
with TLS ECDHE
ECDSA with an
unencumbered suite
that can achieve FIPS140-2 certification.
This comment has been made for the section of the draft that does not
Out of scope
have red lines and that has not changed from Draft D6 to D7. Neither any
and
related comment was made during the Sponsor Ballot. So this comment is Disagree
Out of Scope.
The technical reasons why the the Comment Resolution Committee
disagreed with this comment are as follows:
1) For same reasons as response to Comment ID 3 (9218800023), We
reject this comment on the technical basis.
2) ECDHE-ECDSA as specified for TLS is used to negotiate a session
key, possibly mutual authenticated key agreement. 802.22.1 use of
certificates and signatures is for the purpose of authenticating messages
by way of digital signatures. The techniques selected ECQV and ECPVS
are the most efficient bandwidth wise and computationally.
3) Suite B implementations require licensing from Certicom as well. Suite
B is not unencumbered. In fact, Suite B licenses are only freely available
for certain elliptic curve configurations if implementor is building a system
for US federal government or US DoD. Other entities must negotiate
directly with Certicom. Suite B is a suite of technology, that also implies
other technologies (e.g. SHA-2, AES-256) which are not appropriate or
necessary for the 802.22.1 beacon.
4) The ECC implicit certificate mechanism is more appropriate to the
capabilities of the radio to be used for transmitting the beacon. The implicit
certificate provides for a more compact credential so it can fit in the data
channel for transmission, while not sacrificing security. In short they are
providing different services and are not an even swap.
Slide 10
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Negative Comments from Peter Ecclestine Received During SB Re-circ #1 and
the P802.22 WG Responses
Disapprove Editorial
Yes
All references to 802.22.1 should be in
the correct tense for reading after
publication, not before. Rewrite,
removing text about the 802.22.1 Task
Group, as the draft is in the hands of
the Sponsor.
Remove reference to See resolution of comment #2.
Task Group and draft
standard everywhere, Action: scan the Draft and align tense and remove reference to "Task
including Annex E.2 Group".
p125 line 119.
Agree in
Principle
Disapprove Editorial
Yes
Yes
Either renumber the Action: Renumber the references as G1, G2, etc.
items as G1, G2, etc.
or move this to be
Annex
and
RemoveAuncited
All references in Bibliography that do not exist in draft, should be removed.
references from
Action: Remove Bibliography references that are not referred to: B7, B9,
Bibliography.
B10, B13, B16, B17 or B18
Action: Change the "B-s" to "G's" and re-order those references that exist
in the text. (i.e., change B1 -> G1, B2 -> G2, B3->G3, B4->G4, B5->G5,
B6->G6, B8->G7, B11->G8, B12->G9, B14->G10 in the main text and in
Annex G.)
Agree in
Principle
Disapprove Editorial
My comment 86 in the initial SB was
agreed to, but no change to renumber
the items in the bibliography was
made.
There are no text references to B7,
B9, B10, B13, B16, B17 or B18.
Submission
Slide 11
Agree in
Principle
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Time-line for the Launch of IEEE SB Re-circ #2
• July 26th - Issue IEEE P802.22.1 Draft 8.0
• July 26th – August 9th – Re-circulation #2
Submission
Slide 12
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
WG Motion
P802.22 WG Motion 8 – Document – 22-10-0127 Rev2
Motion: Request that the IEEE P802.22.1 Task Group Chair issue the
P802.22.1 Draft 8.0 by July 26th and launch a 15 day Sponsor Ballot
Recirculation #2 based on the modifications to P802.22.1 Draft v7.0 based
on the comment resolutions as contained in 22-10-0104 Rev 3, to start by
July 26th, 2010 and that the WG Chair request Conditional Approval to
forward P802.22.1 to the IEEE SA RevCom.
Move: Gerald Chouinard
Second: Victor Tawil
For: 12
Against: 0
Abstain: 0
Submission
Slide 13
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for a Conditional Approval to forward the IEEE
P802.22.1 Draft Standard to the IEEE SA RevCom
Motion to grant conditional approval as per the IEEE 802
Operations Manual to forward IEEE P802.22.1 to the IEEE
Standards Review Committee.
Move: Apurva N. Mody,
Second: _________________
For: ___________
Against: __________
Abstain: _________
Motion Passes / Fails
Submission
Slide 14
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion 2
Motion to Extend the PAR of the IEEE
P802.22 Standard by Two Years
Submission
Slide 15
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
IEEE P802.22 Current Status of the Draft
IEEE WG
Letter
Ballot
WG LB #1
(P802.22 Draft
v1.0)
WG LB #2
(P802.22 Draft
v2.0)
WG LB #3
(P802.22 Draft
v3.0)
Launch Respo
nse
Date
Approval
Ratio
# of
Comments
Received
Comment
Resolution
Status
Draft
Status
Ratio
April
2008
59%
<75%
978 (526 T,
452 E)
Comments were
addressed and
Resolved
P802.22
Draft v2.0
Prepared
July
2009
80%
<75%
1383 (942
T, 707 E)
Comments were
addressed and
Resolved
P802.22
Draft v3.0
Prepared
March
2010
76%
78%
725 (432 T,
286 E)
Comments are
being addressed
and Resolved
P802.22
Draft v4.0
Being
Prepared
Based on the Resolution to the Comments as contained in Document 22-10-0078 Rev 13
As per the IEEE P802.22 WG P&P as contained in 22-04-0001 Rev 0
IEEE P802.22 is ON TRACK to reach the Sponsor Ballot in
Nov 2010
Submission
Slide 16
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Reasons why Extension is Requested
• The IEEE P802.22 WG is responsible for three Projects.
P802.22 (WG Letter Ballot Stage), P802.22.1 (Sponsor Ballot
Re-circ Stage and likely to be sent to IEEE RevCom this year),
P802.22.2 (Contributions Stage) – We have made progress.
• The regulatory rules for the targeted spectrum are still
evolving and not finalized as yet –
• IEEE P802.22 has had two changes in leadership since the
beginning.
• IEEE P802.22 is ON TRACK to reach the Sponsor Ballot by
Nov. 2010
Submission
Slide 17
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
WG Motion
P802.22 WG Motion 2 – Document – 22-10-0127 Rev2
Move to authorize the P802.22 WG Chair to make a motion during the IEEE 802 Executive
Committee Meeting to extend the IEEE P802.22 PAR by a duration of 2 years.
Move: Gerald Chouinard
Second: Tom Gurley
For: 12
Against:0
Abstain: 0
P802.22 WG Motion 4 – Document – 22-10-0127 Rev2
Move to approve Document 22-10-0117 Rev 3 as the P802.22 WG response to the P802.22 PAR
Extension Request Form.
Move: Winston Caldwell
Second: Victor Tawil
For: 11
Against: 0
Abstain: 1
Submission
Slide 18
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for Extension of the IEEE P802.22 PAR by Two
Years and Submission of the PAR Extension Request
Form (Doc: 22-10-0117 Rev2) to IEEE NESCOM
• Move: Apurva N. Mody,
• Second: _________________
• For: ___________
• Against: __________
• Abstain: _________
• Motion Passes / Fails
Submission
Slide 19
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion 3
Motion to Extend the PAR of the IEEE
P802.22.2 Standard by Three Years
Submission
Slide 20
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Reasons why Extension is Requested
• The development of IEEE P802.22.2 is dependent upon
the advancement of IEEE P802.22 Standard
• The regulatory rules for the targeted spectrum are still
evolving and not finalized as yet
• IEEE P802.22.2 plans to launch its WG Letter
Ballot 1.0 in August 2010.
• We talked to Lisa Yacone from IEEE-SA and she
advised us to ask for a three year extension for this
standard
Submission
Slide 21
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
WG Motion
P802.22 WG Motion 3 – Document – 22-10-0127 Rev2
Move to authorize the P802.22 WG Chair to make a motion during the IEEE 802 Executive
Committee Meeting to extend the IEEE P802.22.2 PAR by a duration of 3 years.
Move: Winston Caldwell
Second: Jerry Kalke
For: 12
Against: 0
Abstain: 0
P802.22 WG Motion 5 – Document – 22-10-0127 Rev2
Move to approve Document 22-10-0120 Rev 2 as the P802.22 WG response to the P802.22.2
PAR Extension Request Form.
Move: Tom Gurley
Second: Charles Einolf
For: 11
Against: 0
Abstain: 1
Submission
Slide 22
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
Motion for Extension of the IEEE P802.22.2 PAR by
Three Years and Submission of the PAR Extension
Request Form (Doc: 22-10-0120 Rev2) to IEEE
NESCOM
• Move: Apurva N. Mody,
• Second: _________________
• For: ___________
• Against: __________
• Abstain: _________
• Motion Passes / Fails
Submission
Slide 23
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 - Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Commentor
# of Comments
Stephen Berger
7
Peter Ecclestine
5
Tom Gurley
2
Shulan Feng
1
Victor Hou
4
Charles Einolf
3
Marianna Goldhammer
1
Dan Lubar
3
Steve Methley
1
George Vlantis
13
Submission
Slide 24
Changed
or intend
to change
Disappro
ve to
Approve
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 - Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Berger, H Disappro
Stephen ve
Submission
Yes
Technical
1.1
1
1
IEEE standards are international
and should not be market specific.
While it is useful to write a
standard to test to FCC rules the
document should be drafted so
that other regulators with similar or
identical rules can adopt the
standard.
Slide 25
In this section and throughout the
Principle
document wording like:
"The Federal Communications
Commission (FCC) in the United
States of America has proposed to
allow
license-exempt devices to operate
on a non-interfering basis within the
portions of the TV spectrum that are
not used for broadcasts or required
to remain unused in order to protect
broadcast stations from
interference."
Should be changed (in the body):
"National regulators are advancing
regulations that allow
license-exempt devices to operate
on a non-interfering basis within the
portions of the TV spectrum that are
not used for broadcasts or required
to remain unused in order to protect
broadcast stations from
interference."
Then in a footnote state:
"This version of the standard
proposes tests for the Federal
Communications Commission
(FCC) in the United States of
America (cite section of the FCC
rules). Future versions may address
other comparable national
regulations as they become
available."
The footnote alludes to "tests" that are
not a part of the Draft Standard.
Making the body text more
internationally generic with text such
as proposed (e.g. "National regulators
are advancing regulations that allow
license-exempt devices to operate on a
non-interfering basis within the portions
of the TV spectrum that are
not used for broadcasts or required to
remain unused in order to protect
broadcast stations from interference.")
seems reasonable.
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Berger, H Disappro
Stephen ve
Yes
Technical
2
2
Einolf,
Charles
Yes
General
2
3
Disappro
ve
Submission
14 IEEE 1900.1 and 1900.2 should
be added as references and
appropriate changes made to
harmonize these standards.
Add to references:
Disagree
1900.1-2008 IEEE Standard
Definitions and Concepts for
Dynamic Spectrum Access:
Terminology Relating to Emerging
Wireless Networks, System
Functionality, and Spectrum
Management
1900.2-2008 IEEE Recommended
Practice for the Analysis of In-Band
& Adjacent Band Interference and
Coexistence Between Radio
Systems
The document P802.22.1/D6
Complete standards document
Disagree
must, by its very nature, reference P802.22 prior to final acceptance
document P802.22 since
and approval of specifications
P802.22.1/D6 serves to protect
contained within P802.22.1/D6.
incumbent licensed devices from
interference caused by devices
speicified in document P802.22.
Consequently, document P802.22
must be completed prior to
approval of P802.22.1/D6 so that
all references to any aspect of
document P802.22 within
P802.22.1/D6 are correct and
appropriate.
Slide 26
These changes are unnecessary, since
P802.22.1 is intended to be a standalone standard.
The scope of the P802.22.1 PAR is not
limited to protecting licensed devices
from only P802.22. The PAR states
that completion of P802.22.1 is not
dependent on the completion of any
other document. (Essentially the
same comment was submitted in WG
ballot and rejected for the same
reasons.) However, P802.22 is
including an Annex which explains how
to decode the P802.22.1 beacon and
what to do with that information to
assure protection to the licensed
devices in question.
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Ecclesine Disappro
, Peter
ve
No
Editorial
3.3
5
13
Ecclesine Disappro
, Peter
ve
No
Editorial
4
7
30
Berger, H Disappro
Stephen ve
Yes
Editorial
Methley,
Steven
Yes
Technical
Disappro
ve
Submission
Yes
Technical
Change all body text references
from P802.22.1/D6 to P802.22.1
Agree
Changes made tgo document
Remove IC - Industry Canada
Agree
Completed
Add titles to annexes in the ToC.
Agree
Completed
53
"on a given occupied TV channel".
Occupied by what? Specifically
here and in general in the rest of
the document, confusion could
easily arise since what the TV
channel is occupied by is often
not specified. Is it TV, a beacon or
a wireless mic which is on the
channel under discussion?
Don't ask the reader to assume
which channel or signal is being
talked about, when simply being
specific would be quite easy and
very helpful. The whole standard is
about which signal is on (or thought
to be on) which channel after all. I
hope this helps.
Agree
Change the sentence to read "on a
given TV channel occupied by an
incumbent licensed wireless
microphone or other licensed low
power devices."
39
Results that the super-frame
duration is aprox. 100ms. This
creats a problem to TVBDs which
provide time-sensitive services.
The problem is amplified due to
lack of synchronization with the
absolute time, such that the
silence and sensing interval have
to be much longer
1. Introduce fragmentation such that Disagree
every burst will be no longer than
3ms.
2. Introduce synchronization with
the absolute time
8
5.3
9
Steve Methley, Changed his
vote from Disapprove to
Approve
Goldhame Disappro
r, Mariana ve
The reference should be to the
approved standard, not D6. Also
5.2, 6.7.1, etc.
The Acronym "IC" Industry
Canada is not used in the draft
standard, and could be spelled out
were it to occur.
Title of Annexes are not being
picked up in the table of contents,
making it difficult to survey the
structure of the annexes.
5.3
10
Slide 27
The P802.22.1 beacon standard was
developed to allow asynchronous
detection of the beacon over different
timeframes, for example 8-chip PN
sequence can be detected
asynchronously in a period of 2.8 ms
and the sync burst and the index can
be detected with a period of 5.1 ms.
Only when additional information is
desired to be decoded to further verify
the presence, location, and validity of a
beacon is it necessary for a system
using the P802.22.1 beacon to open a
longer quiet period to decode that
information. The system was designed
this way to minimize its impact on
QoS for time/jitter sensitive services.
(To further understand these sequential
decoding options, see the relevant
P802.22 Annex currently embodied in
document 22-07-0491r6)
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Vlantis,
George
Disappro
ve
No
Technical
5.3
11
33
Vlantis,
George
Disappro
ve
Yes
Technical
5.3.2
12
17
Submission
Due to the fact that there is no
gap in the operation of the beacon
in Figure 2 (b), the 802.22 CPE
will not have an opportunity to
report to the BS that there is a
beacon present. That is, the
beacon continuously "jams"
without any respite.
Referring to the entire subclause
"5.3.2 Beacon frame structure"
and the associated Figure 4, the 3
MAC subframes (MSF1-MSF3)
are 34 (1:2 encoded), 51, and 33
octets, respectively.
We learn in 6.1.2 "Modulation
rates and beacon offset location
for ATSC DTV regions" that
because 1/140 * the ATSC symbol
rate is used, the bit rate for
transmissioin is approximately
9.6091 kBaud/s = 1201.14
kbytes/s.
For the 3 subframes, this
translates to 28.3msec,
42.5msec, and 27.5msec,
respectively. But to read MSF2
correctly, MSF1+MSF2 must be
read. And to read MSF3 correctly,
MSF1+MSF2+MSF3 must be
read. Therefore the three windows
sizes required to read the 3
frames are 28.3msec, 70.8msec,
and 98.0msec (not including
header).
Because the integrity of the
reception of the subframes relies
on the CRC field, the subframes
must be received in their entirety.
When the 802.22 WRANs are
allocating quiet periods in integral
number of frames, this implies that
Slide 28
I suggest leaving some interval,
Disagree
likely more than a 802.22 WRAN
frame and possibly 2 frames to
solve the alignment issue, so that
CPE can report the presence of the
beacon.
Monique to reitterate previous rejection
rationale.
Please provide a Remedy.
Doubling the chip rate while keeping
the bit rate fixed will not shorten the
MSF1. Shortening the bit duration will
degrade sensitivity of the beacon. We
have already determined that we
cannot afford to degrade sensitivity and
maintain the link margin needed to
guarantee detection. The current
design represents the best tradeoffs
against multiple requirements. Normal
detection of the TG1 beacon is for the
burst and index, which requires 5.1 ms
which fits in the normal 10ms 802.22
transmission frame. The actual
process to decode the entier PPDU is
to move out of the channel and task
CPEs to revisit the channel during idle
times to decode the entire beacon
payload for authentication and payload.
Since this is done outside of the
operating channel, QoS will not be
affected. (see document 22-07-0491r6
for more explaination) This comment
was also rejected in WG LB#1 for the
same reasons.
Disagree
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Ecclesine Disappro
, Peter
ve
Yes
Technical
5.3.2
12
20
The MSF 1 portion should contain
FCC Identifying information
15.711(e) - FCC Type ID and
Serial Number and location.
Add Regulatory Type ID and Serial
Number fields to MSF 1, and define
in 7.2.1.x so that the fields work
across the Table 45 regions.
Disagree
Vlantis,
George
Disappro
ve
Yes
Technical
5.5.1
15
12
I haven't a clue.
Disagree
Vlantis,
George
Disappro
ve
Yes
Technical
5.5.1
15
12
I haven't a clue.
Disagree
This is beyond the scope of P802.22.1
and will most likely become a
regulatory requirment on the database
operator because of license issues.
Vlantis,
George
Disappro
ve
Yes
Technical
5.5.2
15
37
How do 802.22 nodes (BSs or
CPEs), or any other deployed
device for that matter, access the
trusted authority's database?
The public-private key pair
approach is a good one. How does
a manufacturer of 802.22.1
devices enter the MAC address
and public key into the trusted
authorities database? Who
operates the database? What is
the form of the data expected?
etc.
As pointed out in this subclause,
it is true that repeatedly
broadcasting messages with the
same public key is not a good
idea. Furthermore, the format of
the plaintext message being
encrypted is known to the attacker
by virtue of this specification. It's
not clear from the explanation
whether 1-3 years cited from the
NIST publication is for plaintext
data that changes or plaintext
data that remains relatively
constant. Given that machines
exist that crack 64-bit keys for
DES keys in relatively short time
frame (on the order of a day), I'm
finding it difficult to believe that
112 bits will be good enough for 13 years.
I haven't a clue. Please cite what
the assumptions are for the
referenced table.
Disagree
withdrawn by voter,
Submission
Slide 29
These devices are intended to be
operated in the US as licensed
devices, not as unlicensed TVWS
devices. The identifier is a MAC
address carried in MSF1 that is
associated with a license. This
correspondence can be validated
through the security mechanisms
inherent in the system to prevent
"spoofing" of beacons.
This is beyond the scope of P802.22.1
and will be addressed in P802.22.
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Einolf,
Charles
Disappro
ve
Submission
Yes
General
6
17
The operation of the P802.22.1/D6
compliant beacon device may
actually cause interference to the
incumbent licensed broadcasting
services. The FCC Office of
Engineering and Technology in its
report (FCC/OET 07-TR-1003),
dated March 30, 2007 and entitled
"Interference rejection thresholds
of consumer digital television
receivers available in 2005 and
2006" demonstrates the problem.
The FCC "found that pairs of
undesired signals placed on
channels N+K and N+2K, where K
is a positive or negative integer,
created an opportunity for thirdorder intermodulation (IM3)
occurring in the DTV tuner to
create spectral products that fall in
the desired channel N. The FCC
had anticipated paired-signal IM3
effects would be significant only at
high signal levels; however,
detailed measurements on one
DTV receiver demonstrated that
such effects can constitute a
dominant interference
susceptibility even at desired
signal levels very near the
minimum signal threshold for the
TV, when such signal pairs exist."
Consider the case in which a
Slide 30
Include a subsection in 6.8 which
Disagree
addresses the above issue providing
channel exclusions for required
beacon operation based upon
interference scenarios. This
subsection should also reference
P802.22 which must provide
protection to licensed services from
these same interference
mechanisms.
Since P802.22.1 devices are intended
to operate within the same regulatory
limits as wireless microphones, in the
same channel as the wireless
microphones they are intended to
protect, and will be under the complete
control of the licensed incument
operators, it is believed that this is a
non-problem. Furthermore, the
intermodulation performance of
consumer digital television receivers is
beyond the scope of this standard.
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Einolf,
Charles
Disappro
ve
Submission
Yes
Technical
6
17
The operation of the P802.22.1/D2
compliant beacon device may
actually cause interference to the
incumbent licensed broadcasting
services. The FCC Office of
Engineering and Technology in its
report (FCC/OET 07-TR-1003),
dated March 30, 2007 and entitled
"Interference rejection thresholds
of consumer digital television
receivers available in 2005 and
2006" demonstrates the problem.
The FCC "found that pairs of
undesired signals placed on
channels N+K and N+2K, where K
is a positive or negative integer,
created an opportunity for thirdorder intermodulation (IM3)
occurring in the DTV tuner to
create spectral products that fall in
the desired channel N. The FCC
had anticipated paired-signal IM3
effects would be significant only at
high signal levels; however,
detailed measurements on one
DTV receiver demonstrated that
such effects can constitute a
dominant interference
susceptibility even at desired
signal levels very near the
minimum signal threshold for the
TV, when such signal pairs exist."
Consider the case in which a
Slide 31
Include a subsection in 6.8 which
Disagree
addresses the above issue providing
channel exclusions for required
beacon operation based upon
interference scenarios. This
subsection should also reference
P802.22 which must provide
protection to licensed services from
these same interference
mechanisms.
This is a duplicate comment that refers
to a Draft (D2) from WG ballot. This
comment was rejected there for
essentially the same reasons as
comment #31 above.
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Vlantis,
George
Disappro
ve
No
Editorial
6.1.4
18
Vlantis,
George
Disappro
ve
No
Editorial
6.1.4
18
Vlantis,
George
Disappro
ve
Yes
Editorial
6.2
19
Vlantis,
George
Disappro
ve
Yes
Technical
6.2
19
Submission
37 Since the text states that, "The
See comment
definitions in Table 2 are
referenced by subclauses
elsewhere in the standard", the
only place I get find a reference
was in 6.8.6 which is entitled
"Receiver sensitivity". Wouldn't it
make sense to just move Table 2
to Clause 6.8.6, or move the text
from subclause 6.8.6 here and
move Table 2 directly below?
37 Given that Table 2 is orphaned in See comment
the next subclause (and the next
page), wouldn't it make sense to
put Table 2 under the explanatory
text?
24 Globally search and replace "byte" See comment
with "octet".
Disagree
It ws felt by the group that this
information should appear early in this
section.
Principle
If the layout can be efficiently modified,
this can be done.
Agree
Refer to the Editor for appropriate
editorial remedy.
24 The seeming contraction for the
See comment
byte length of MSF1 in Table 2 (17
bytes) and the byte length of
MSF1 in Figure 4 (34 bytes) can
be explained by the usage of 1:2
encoding on MSF1. However, it
would be helpful to know when we
are talking about encoded bytes
and unencoded bytes, so the
reader isn't confused
Agree
Refer to the Editor for appropriate
editorial remedy. Add/edit text as
required to make it clear when bytes
(should be octets) being referred to are
encoded or not to eliminate such
potential for confusion.
Slide 32
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Feng,
Shulan
Disappro
ve
Yes
General
6.5.1
29
26 Section 6.5.1, In Table 17, The
RTS codewords generated by
(16,5,8) block codes is much
more complicated than the RTS
codewords in Draft 2.0; and there
is no simulation results show that
this code has better performance
than the one in Draft 2.0.
48 I have a friend who lives in
Vanuatu and who wants to sell
802.22.1 beacon technolgy to
tourists who go fishing and get
lost. Vanuatu was originally
settled by the Portuguese, but has
been a possession of England and
France at various times. Before
being liberated by the American's
in the 1940's, it was a joint
possession of England and France
under the British-French
Condominium (sic). The obvious
question: what value does he use
for the value of "aRegion"?
Seriously, if there's no definition of
the value of "aRegion" it should be
deleted. Also this impacts Table
19, where no guidance is given on
how "aRegion" is used to index
into some database.
Shulan Feng, Sent an E-mail that he
would like to Change his vote from
Disapprove to Approve
Vlantis,
George
Disappro
ve
Submission
Yes
Technical
6.6.1
32
Slide 33
Bring back the RTS codewords in
Disagree
Draft 2.0, Which has been shown by
simulation results that it can fulfill
the requirement sufficiently, and
with a very simple implementation
complexity
The RTS codewords that were chosen
have been voted by the task group and
approved by the working group.
Eliminate "aRegion" in Table 18 and Principle
its unidentified usage in Table 19.
The value of aRegion is a placeholder
for future channel aggregation. This
has yet to be defined and is the task of
a tiger team. To simplify channel
aggregation, it is useful to know the
country / region in which the
beacondevice is operating. Text shall
be added to this extent. Greg to
provide text.
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Vlantis,
George
Disappro
ve
Yes
Technical
6.8.1
37
47 Here in subclause 6.8.1 and in
Please specify the operating
subclause 6.7.1.6 the center
temperatures for this device, as
frequency tolerance is specified to most other IEEE standards do.
be within 2ppm. However, the
temperature range of this
accuracy is not specified. Crystals
are very, very accurate when
temperature is held constant (with
only slight variations to due drive
current, aging, etc.). The biggest
source of drift is temperature. I
would like the 802.22.1 beacon to
operate properly, whether it's
being used to protect the filming of
the Iditarod or whether it's being
used to film the Saudia Arabian
National cricket team.
Agree
The device shall maintain the specified
freqeuncy tolerance over an operating
temperature range of -30 to +50
degrees Centrigrade.
Vlantis,
George
Disappro
ve
Yes
Technical
6.8.4
39
23 In Equation (12), the subscript to
the summation should be j-1.
resolved by inspection
Agree
change document
Vlantis,
George
Disappro
ve
Yes
Technical
7.2
52
30 Please include in Annex A an
example of the encoding (or lack
thereof) of an entire MPDU
(including padding) and the proper
CRCs with correct bit ordering.
Please include in Annex A an
Principle
example of the values assigned to
various fields within the 3 MSFs and
the resulting frame that results in
preparation for I-Q transmission. If
you can output the I-Q values, so be
it.
Submission
Slide 34
withdrawn by voter after discussion
with security team.
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Ecclesine Disappro
, Peter
ve
Yes
Technical
7.2.1
53
4
Gurley,
Thomas
Yes
Technical
7.4.5.1
68
45
Disappro
ve
The MSF 1 should contain the two Add fields for Regulatory Type ID
Disagree
transmitter identifying information and Serial Number, so both US and
fields that FCC 08-260 require future foreign regulations are met.
the FCC Type ID and serial
number of the beaconing device.
These should appear in every
MAC beacon frame, and together
with the location field satisfy
15.711(e).
The beacon device is not operated
under Part 15; rather, it is a Part 74
device in the US and does not require
transmission of this information. If, in
other regions, such information is
required, it can easily be
accommodated in the channel map
field of MSF2. See 7.2.2.1.1: When
Bits 0 and 1 are set to 0 and 1
respectively, the remaining bits of the
40 bit field may be used for
manufacturer-specific information. This
information can also accommodate
data required by a specific jurisdiction
and is reserved for such purpose.
The draft should be revised to
permit the use of cross-channel
aggregation in this version of the
standard.
Modify the sentence to read: Crosschannel aggregation, which is the
process of combining data from two or
more PDs that operate on different TV
channels, shall not be employed in this
version of the standard but shall be
revisited in future versions of the
802.22.1standard. In addition, all
information neccessary to provide
future cross-channel aggregation shall
be retained in the 802.22.1 standard.
Remove the restriction on crossPrinciple
channel aggregation by deleting the
second paragraph under Sub-clause
7.4.5.1
Tom Gurley, Changed his vote
from Disapprove to Approve
Lubar,
Daniel
Disappro
ve
Submission
No
Editorial
D.2
107
33
On page 142 in the PDF (and pg
107 in the document) In
Informative Annex D, "Section D.2
The next higher layer" might do
well to contain a forward reference
to section D.7's specific examples
(ie use-cases) of how the NHL
interactions will work. Such a
reference would be of value for
readers of this document
interested in perusing cross-layer
or layer 3 or above interaction with
this PD Standard.
Add the following brief paragraph
Agree
after the 1st paragraph in D.2..
For specific examples or use cases
of how a NHL interactions work,
please see section "D.7 NPD
behaviors" that contains a number of
them.
Slide 35
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Gurley,
Thomas
Disappro
ve
Yes
Technical Table 57 114
Tom Gurley, Changed his vote from
Disapprove to Approve
Lubar,
Daniel
Disappro
ve
No
Editorial
Ecclesine Disappro
, Peter
ve
Yes
Editorial
Submission
129
Annex
G
131
6
This recommended value should
be set consistent with removal of
the restriction on cross-channel
aggregation in this version of the
standard.
34 In the informative titled "Annex E.3
Location Information" there is
specified "several methods" to
obtain location information -including one that appears to
describing a "by hand" direct entry
of location info. Would you want to
also want to explicitly specify a
secure machine to machine
method? (..for some form of
secure regulatory database
location provisioning of a "licensed
use" of a 22.1 device?)
8
Delete or revise text recommending Principle
value of 0 for this version of the
standard (no change due to
aggregation).
revise text in table; completed
Change the text of #5 from:
Disagree
"Proprietary methods of location
derivation such as time of arrival,
etc."
To:
"Proprietary methods of specifying
location information which might
include M2M or other form of secure
communications, or a calculated or
derived location info--such as time of
arrival, etc."
Participants in the 802.22.1 task group
voted to incude only the listed
methods. Broadcasters objected to
expanding the scope by which location
could be obtained beyond the listed
methods.
The IEEE Style Manual 10.7.1
Either renumber the items as G1,
Agree
requires that the Bibliography be G2, etc. or move this to be Annex A
the first or last annex. The items and renumber items as A1, A2, etc.
in it are numbered with the Annex
letter - G1, G2, G3, etc. Suggest
moving this to become Annex A,
as the items will never need
renumbering again.
Slide 36
Will be renumbered to be "G1, G2
through Gn"
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Berger, H Disappro
Stephen ve
Yes
Technical
Lubar,
Daniel
Disappro
ve
Yes
General
Berger, H Disappro
Stephen ve
Yes
Technical
Submission
Annex
G
131
21 Should not the IEEE dictionary be
a reference in that those
definitions are the mandatory
definitions unless superceded by
citations in the definitions or
glossary section?
Why does this draft (in section
5.5) make such a good treatment
of security (ie cryptographic,
device, cert etc) and yet does
nothing to try to put a "license
plate on the vehicle" as it were? Is
operator or some non-generic &
specific regulatory information
something that can be optionally
included in either the MIB or PIB
frame data? ..such data might
simply take the form of an
assigned "regulatory designator
code" or other unique identifier.
IEEE 1900.2 in its Annex F,
"Sample analysis&#9135;lowpower radios operating in the TV
band", uses the methodology of
1900.2 to analyze the problem
being addressed in this standard.
It would be helpful to cite that
analysis in this standard, which
provides a remedy for the issues
identified. Alternately if this
committee, with the benefit of
greater insight into the issues and
new information, cares to improve
the analysis, that should be done
to assure that the body of IEEE
standards are current and
accurate.
Slide 37
Move citation of IEEE 100 to the
reference section.
Agree
Completed
Providing a standard means to, in
some way, specify the identify a
user or responsible party operating
or deploying a 22.1 device would
seem a logical addition to the PHY
PIB table 19 or maybe in the MAC
via Table 37. Operational
transparency in a shared spectrum
world is always a good thing to
provide.
Disagree
The MAC address of the TG1 device is
clearly sent in MSF1. Since this is not
an unlicensed device, individual
jurisdictions may impose additional
identification requirements in which
case adequate space has been
provided in the "user defined" space of
the "40 bit field".
Cite 1900.2 Annex F either as is, if
it is found acceptable, or with
revisions, if improvements are
recommended.
Disagree
IEEE 802.22.1 was specified as a
standalone standard
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Berger, H Disappro
Stephen ve
Submission
Yes
Technical
No guidance is given regarding the
potential for interference to
medical devices, particularly
implantable medical devices such
as pacemakers. AAMI PC69, the
standard for immunity of
implantable medical devices
contains an annex that provides
some guideance. In general a
waveform that demodulates
significant energy below 200 Hz
has the potential for mimicing a
biologic signature and causing
inappropriate action in a medical
device. Demoduations below 20
kHz can produce audio
interference with hearing aids and
other devices. Guidance should be
added to avoid waveforms and
operating modes that could result
in such interference.
Cite the AAMI PC69 annex or, with
permission, include it as an annex
in this document. Provide guidance
on how to avoid interference with
medical devices.
Slide 38
Disagree
Medical telemetry devices are now
required to operate on Channel 37 on
which no TVWS operation is allowed
nor would a beacon ever be utilized.
Other channels may be utilzied but the
FCC no longer provides protection of
these devices out side of the use of CH
37. More specifically, AAMI PC69
specifies succesptability of medical
implants to devices operating in the
frequency range 450 through 3GHz as
follows: "For frequencies of 450 MHz
through 3,000 MHz, the standard
specifies testing at 120 mW net power
into a dipole antenna to simulate a
hand-held wireless transmitter 15 cm
from the implant. An optional
characterization test is described that
uses higher power levels to simulate a
hand-held wireless transmitter placed
much closer to the implant." The
maximum power level of the beacon is
250mW; approximately 3dB greater
than the level used for test. However,
the deployment guide in Annex D
clearly specifies a recommended
practice that would place the beacon
antenna further from a human than
15cm. Since the induced power falls
at a rate of at least square law, the
3dB difference would amount a
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Berger, H Disappro
Stephen ve
Yes
Technical
Hou,
Victor
Yes
General
Disappro
ve
Submission
The definiitons of interference and
harmful interference in 1900.2
should be used in this standard
also. In addition the concept of an
interference event should be
implimented. See the definitions,
glossary and particulary Sec. 4 of
1900.2 for an explanation of these
concepts.
This standard should recognize
interference as any measurable
impact from one device to antoher,
but an interference event is when
such measurable impact arises to
a level that the standard judges to
be signfiicant, given its purpose.
Harmful interference is when
interference events rise to an
unacceptable level. These
thresholds should be clearly
stated so that the reader can
understand the rationale for them.
There is virtually no discussion on
how this standard relates to
802.22. There are just a very few
references to license-exempt
devices specified by P802.22,
where 802.22 is just used merely
as an example of a type of device
that could utilize 802.22.1. But
somehow, I was expecting more
discussion of the relationship
between this document and the
base 802.22, still in progress.
Slide 39
A review of this document is needed Disagree
with modifications to the use of the
terms interference and harmful
interference, as needed to use
those terms consistently with
1900.2.
This is a licensed device; it only needs
to comply with regulations pertaining to
the region of operation. It is also a
stand-alone standard unabridged to
other proposed standards with the
exception of 802.22.
Provide some more explanation in
Disagree
the document about the relationship
between this document and the
base 802.22, still in progress.
The 802.22.1 standard was
intentionally (as mandated in the PAR)
to be independent of 802.22. It
designed to be "indifferent" and not tied
to parameters of 802.22 to provide
protection of devices either licensed or
protected by local regulation from
interference created by unlicensed
devices. This is not limited to 802.22;
the 802.22.1 standard may be used to
protect such devices from all
unlicensed devices operating in TVWS.
Apurva N. Mody, BAE Systems
July 2010
doc.: IEEE 802.22-10/0114r05
References
• P802.22.1 Negative Comments from SB that were resolved but where the
commentors have maintained their negative vote during SB Re-circ #1
Hou,
Victor
Disappro
ve
No
Editorial
There are some uses of "802.22"
and others of "P802.22." There
should be consistency.
Use either "802.22" or "P802.22"
consistently.
Hou,
Victor
Disappro
ve
Yes
General
This is somewhat tied into another
comment of mine but still different.
It is not very clear what features of
the standard and protocol are
mandatory versus optional. On the
other hand, the overall
specification appears "heavy" in
terms of features, and if there are
optional items, perhaps, they
should be better highlighted.
Perhaps, clarification of terms such Disagree
as "shall," "should", and "may"
could accomplish much of this. But
in addition, some introductory text
up front may better provide an
overview of what is mandatory vs. an
optional feature of the protocol.
This is a rigid standard and it is clear
that all but the 40 bit field must be
satisified. If the 40 bit field is not
utilized, guidence is given on how to
preload this field.
Hou,
Victor
Disappro
ve
Yes
General
The document appears to have
judicious use of "shall" vs.
"should" vs. "may" and even one
"must." However, there is no
section on "Requirements
Language" or "Normative
Language" that provides
explanation of what these terms
actually mean.
The document needs to provide
clarification of what "shall" vs.
"should" vs. "may" vs "must" mean
with respect to implementation of
and compliance with the standard.
In many documents, there is a
section that explains all that, but
there does not appear to be one
here.
To be added
Submission
Slide 40
Agree
Agree
All circumstances will be relisted as
P802.22
Apurva N. Mody, BAE Systems