Overview of IEEE 802.22 Standard

Overview of IEEE 802.22 Standard

March 2011 doc.: IEEE 802.22-11/0042r00 IEEE P802.22 Motions at the March Plenary EC Meeting IEEE P802.22 Wireless RANs Date: 2011-03-17 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 [email protected] ems.com, [email protected] com Gerald Chouinard Communications Research Center, Canada 1-613-9982500 [email protected] .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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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 < [email protected] > 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 [email protected]

> Submission Slide 1 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Motion Motion for a Conditional Approval to forward the IEEE P802.22 to the IEEE SA RevCom Submission Slide 2 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Motion for a Conditional Approval to forward the IEEE P802.22 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 March 2011 doc.: IEEE 802.22-11/0042r00 Motion for a Conditional Approval to forward the IEEE P802.22 to the IEEE SA RevCom Number of People in the Sponsor Ballot Pool = 155 IEEE Sponsor / Re-circ Ballot Respo nse Ratio Approval Ratio Negative

Votes Number of Negative Comments Received Sponsor Ballot #1 Open Dec 16 2010, Closed Jan 15, 2011 83% 92% 9 negative votes with comments 64 Comments P802.22 addressed /D 2.0 & resolved prepared - 22-110040r5 84% 94% 5 negative votes with no comments,1 negative vote with 3 TR comments 3 Comments P802.22 addressed /D3.0 & resolved being 22-11- prepared 0040r5 Sponsor Ballot Recirc #1 Open Feb. 25th, 2011, Closed March 12, 2011 Submission (10% abstain)

(9% abstain) Slide 4 Comment Resolutio n Status Draft Status Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were resolved but where the commentors have maintained their negative vote during SB Re-circ #1 Commentor # of TR/ ER Comments during SB #1 and SB Recirc #1 Status After Sponsor Ballot Recirc #1 Diamond, Patrick 2 and 0 Approve (Vote Change) Ecclesine, Peter 4 and 0 Disapprove (No New Comments) Gurley, Tom 2 and 0 Approve (Vote Change) Hu, Wendong 5 and 0 Disapprove (No New Comments) Kennedy, Richard 5 and 0 Disapprove (No New Comments) Mccann, Stephen 13 and 0

Disapprove (No New Comments) Methley, Steven 1 and 0 Approve (Vote Change) Riegel, Maximilian 5 and 0 Disapprove (No New Comments) Struik, Rene 27 and 3 Abstain Submission Slide 5 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Negative Comments and Commentor Details 3 TR Comments were received from Rene Struik during the P802.22/D2.0 Sponsor Ballot Re-circ #1 Remaining 5 Negative Voters did not submit any comments during Re-circ #1 Two of the three comments from Rene Struik were the same as the comments from Sponsor Ballot #1 (Hence these were not new issues). Based on the telecon during AM1 on March 15th, in Singapore, the Commentor was willing to withdraw all the three of his TR comments, however, the Comment Resolution Committee decided to address and resolve Comment #63 (New Comment based on a New Issue) and go for another round of re-circulation. The comment resolutions are incorporated here-in entirely and can also be found at https://mentor.ieee.org/802.22/dcn/11/22-11-0040-05-0000-p802-22-d2-sponsor-ballot-co mments-database.xls Negative comments resolved but carried forward from the SB and the comment resolutions are also included in the reference section at the end of this presentation. Rene Struik has agreed to change his Dis-approve vote to APPROVE/ ABSTAIN, based on the comment resolutions and the changes to the draft during SB and Re-circ #2. Submission Slide 6

Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Negative Comments and Resolution Details Comment #61 Document 22-11-40 Rev5 Commenter: Rene Struik Comment: (TR) Clause 2, p. 4, l. 43: RFC 2437 (PKCS#1, v2.0), if so, this would allow RSA MultiPrime and, thereby, RSA schemes with different cryptographic properties than the original scheme. It is unclear whether this is intended. Moreover, NIST SP 800-56 explicitly rules out support for MultiPrime, thus making it a less suitable choice to support in case this standard would also be used by US Government agencies. Suggested remedy: Refer to a specific version of PKCS#1 - early enough version without support for RSA MultiPrime. Resolution Status: Out of Scope (Withdraw) Resolution Detail: Comment is the same as the previous comment #100 submitted by Rene Struik during the Sponsor Ballot #1 for P802.22/D1.0 so this comment is not related to a new Issue based on the changes made to the Draft during the Sponsor Ballot Comment Resolution. The Comment Resolution Committee had a telecon with the commentor on Tuesday, March 15th, during the AM1 session in Singapore, where the commentor decided to 'Withdraw' this comment. Rene: The version of the RFC 2437 referred to in the 802.22 Draft should not allow support for the MultiPrime feature. Based on the Comment #100 during Sponsor Ballot #1, P802.22/D2 was modified to refer to Version 2.0 (October 1998) of the RFC 2437. It was confirmed that this version does not include the MultiPrime support. Rene agreed that this was the case. Rene Struik (email: 13 March 2011, 19:09:06 -0400): "Those are indeed the correct references and I confirm I will withdraw #1 you quoted below." This sentence referred to this comment #61. Submission Slide 7 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Negative Comments and Resolution Details Negative Comments and Commentor Details - Comment #62 Document 22-11-40 Rev5 Commenter: Rene Struik Comment: (TR) Clause 2, p. 5, l-12: To my knowledge, the SEC4 specification is only a draft specification and, thereby, may be subject to change. A standard should not reference external specifications as normative references, it the latter are only draft standards. Suggested remedy: Create an Annex that specifies the full details of the SEC4 scheme as used in the IEEE 802.22 standard, so as to be independent of any changes made by an external standards body. Please note here that the latest draft on the SECG website is v0.91 (dated November 18, 2008) and, although the final specification was supposed to be published prior to end of February 2011, this did not happen. Note: Please note also IACR ePrint 2009-620. Is it known that the composition of ECQV and ECPVS is secure (I have seen convincing papers on these individually, but not a compositional proof). Suggested remedy: Create an Annex that specifies the full details of the SEC4 scheme as used in the IEEE 802.22 standard, so as to be independent of any changes made by an external standards body. Please note here that the latest draft on the SECG website is v0.91 (dated November 18, 2008) and, although the final specification was supposed to be published prior to end of February 2011, this did not happen. Resolution Status: Out of Scope (Withdraw) Resolution Detail: Comment is the same as Comment #125 from the Sponsor Ballot #1 for P802.22/D1.0, so this is Not a New Issue based on the changes made to the Draft. The commentor has decided to 'Withdraw' this comment for the following reasons. The comment resolution committee had a telecon with the commentor on Tuesday, March 15th, during the AM1 meeting in Singapore, and asked the commentor the nature of this comment. The commentor clarified that this should really be an Editorial comment. In response, the chair asked for clarification from Michelle Turner (IEEE-SA chief editor):"IEEE 802.22 is planning to refer to the SEC4 Standard which is a Draft Standard under development as a normative reference. Micheller Turner's response: "The reference to

the draft is fine. However, please make sure when it's referenced it includes the date and version of the draft. Also, please make sure the draft is readily available, because we will need to footnote how the draft can be obtained." The CRC wanted further clarification on whether the IEEE SA can store the draft SEC4 standard being referred - Michelle provided this further clarification as follows: "The draft will be placed on file with the IEEE. So the issue of the possibility of it not being at the website years from now, doesn't matter because we will have it. During publication prep, we would include the appropriate footnotes, so the user will know how to obtain the draft. Hopefully this was helpful. As a further clarification, the Chair asked the IEEE -SA Sr. Program Manager if the IEEE -SA will take care of keeping this Draft Standard in their repository and will provide it to whoever asks for it. Please find the e-mail exchange below: Based on this, the commentor agreed to Withdraw his comment. Submission Slide 8 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Negative Comments and Resolution Details Comment #63 Document 22-11-40 Rev5 Commenter: Rene Struik Comment: (TR) Clause 8.6.2.3, p. 299, Table 135: This table suggests the use of elliptic curves of bitsize 163-bits, thus offering a cryptographic strength of just 80-bits. This would not be allowed according to key management guidelines of NIST SP 800-57, since 80-bit crypto strength is not to be endorsed from 2011 onwards. Suggested remedy: specify an elliptic curve with higher cryptographic bit strength. Resolution Status: Princilple Resolution Detail: On Tuesday, March 15th, AM1 Session in Singapore, the comment resolution committee had a telecon with the commentor. During the telecon, the commentor elaborated his reasons for submitting this comment: In certain applications, one is no longer allowed to use crypto strength of 80 bits (e.g., US Gov't requires a crypto strength of more than 80 bits for government's applications (NIST SP 800-57)). While the cryptographic construct strength used in this specification is deemed to be adequate for industrial/commercial applications right now, it is realized that in the future, more flexibility and higher-crypto bit strengths may be warranted. The commentor is okay if this issue is addressed in a future amendment of the 802.22 specification and he was willing to withdraw this comment. However, the Comment Resolution Committee decided to accept this comment in principle and provided the resolution to this comment, which can be found in contribution (22-22-0041r1). Higher strength crypto elliptical curve was selected: K-233 or B-233 elliptic curves defined in FIPS 186-3 will be used rather than the K-163 and B-163. Necessary changes were made to the Draft as indicated in document 22-11-0041r1. Submission Slide 9 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 E-mail Exchange with Commenter Rene Struik Re: Rene: Confirmation for your Comment Resolutions From:Rene Struik View ContactTo:apurva mody Cc:Gerald Chouinard ; apurva mody Hi Apurva: As previously indicated, I hereby confirm that I withdraw all technical ("TR") comments I submitted during the 802.22 sponsor ballot recirculation that ended Sat March 12, 2011, 11:59pm EST. Please record my corresponding vote as Abstain. Best regards, Rene ___________________________________________________________________________________________________________________ On 15/03/2011 7:33 PM, apurva mody wrote:

Dear Rene, Thank you very much for all your comments to improve the quality of the IEEE 802.22 Draft Standard as well as participating in the comment resolution process.We know that you have re-iterated your wish to 'Withdraw' your comments over our past e-mail exchanges as well as during our telecon that was held on Tuesday, March 15th AM1 session in Singapore. However, the IEEE-SA staff wants us to get a clear confirmation from you that you have indeed withdrawn all the 3 of your submitted comments during the Sponsor Ballot Re-circulation #1 for the P802.22/D2 Standard. Especially Comment #63 since that pertains to a new issue based on the changes made to the draft. So, 1. Can you please confirm that you wish to 'Withdraw' all the three of your TR comments submitted during the Sponsor Ballot Re-circulation #1 for the P802.22/D2 Standard: as a result of the telecon that was held on Tues. March 15th, AM 1 Session in Singapore and based on the Comment Resolutions as proposed in the following spreadsheet: https://mentor.ieee.org/802.22/dcn/11/22-11-0040-03-0000-p802-22-d2-sponsor-ballot-comments-database.xls 2. Can you also let us know how you wish your vote to be counted for the P802.22/D2 Draft Standard - Approve / Disapprove / Abstain? Many thanks Apurva ___________________________________________________________ Apurva N. Mody, Ph. D. Chair, IEEE 802.22 Standard Working Group Cell: 404-819-0314 E-mail: [email protected] Submission Slide 10 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Motion for a Conditional Approval to forward the IEEE P802.22 Draft Standard to the IEEE SA RevCom Time-line for the Launch of IEEE SB Re-circ #2 March 24th - Issue IEEE P802.22/D3.0 March 24th April 7th Re-circulation #2 Submission Slide 11 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 P802.22 WG Motions WG Motion #2 Document 22-11-0043 Rev0 Motion #2 Request that the IEEE P802.22 Working Group Chair issue the P802.22/ D3.0 on or before March 24th and launch a 15 day Sponsor Ballot Recirculation #2 based on the modifications to P802.22/D 2.0 as a result of the comment resolutions as contained in 22-11-0040 v6.0. Move: Ivan Reede Second: Jerry Kalke For: 8

Against: 0 Abstain: 0 Motion passes unanimously Submission WG Motion #3 Document 22-110043 Rev0 The IEEE 802.22 Working Group authorizes the WG Chair to seek Conditional Approval from the IEEE 802 Executive Committee to forward P802.22/D3.0 to the IEEE SA RevCom. Move: Ivan Reede Second: Dr. Hiroshi Harada For: 9 Against: 0 Abstain: 0 Motion passes unanimously Slide 12 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Motion for a Conditional Approval to forward the IEEE P802.22 Draft Standard to the IEEE SA RevCom Motion to grant conditional approval as per the IEEE 802 Operations Manual to forward IEEE P802.22 to the IEEE Standards Review Committee. Move: Apurva N. Mody, Second: _________________ For: ___________ Against: __________ Abstain: _________ Motion Passes / Fails Submission Slide 13 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References Submission Slide 14 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors

have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 Comment # 1 Name Mccann, Stephen Category Comment Technical I think its necessary to define the word"professional" in the context of this specification. On one hand it could mean installation by a specialist company charging fees, and on the other someone who is mearly competant to do this. I'm concerned that the use of this word in an IEEE 802 standard is potentially leading the market for such devises in a certain direction for certification purposes, i.e. only certified products can be installed by a professional company joe-bloggs who charges $xxxx. Submission Must Be Satisfied Yes Proposed Change A footnote to clarify the word "professional" would be useful, e.g. (professional as defined by "FCC 10-174 clause 3"). Slide 15 Resolution Status Resolution Detail Principle The Comment Resolution Committee agreed in principle with the commentor and initially decided to change the sentence to "a professionally installed fixed base station". Add: "(see Annex A" at the end of the paragraph. However, the IEEE SA staff asked the Comment Resolution Committee that the title, scope and purpose in the draft need to be exactly specified as that in the PAR with no changes to the words. So the end result was that we could not make the change as proposed by the commentor. However, the Comment Resolution Committee decided to create the following table in Annex A. Create a new Table xx in Annex A containing 3 columns: "Regulatory domain", "Professional installation required", and a definition of "professional installer" for the USA regulatory domain as follows: "A professional installer is a competent individual or team of individuals with experience in installing radio communications equipment and who normally provides service on a fee basis such an individual or team can generally be expected to be capable of ascertaining the geographic coordinates of a site and entering them into the device for communication to a database." Add a reference to Annex A, Table xx every time professional installation is mentioned in the text. Apurva N. Mody, BAE Systems

March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 2 Mccann, Stephen Technical There is no definition of "Cognitive Plane" Yes Please provide a definition for this term 4 Mccann, Stephen Technical Within Figure 2 there are two representations of WLAN technology, i.e. IEEE 802.11 and IEEE 802.11a. I think this is an outdated view of WLAN technology, as IEEE 802.11y covers the 3.5 GHz band, whilst IEEE 802.11ad covers 60 GHz. I think a single mention of "IEEE 802.11" somewhere between the 2.4 and 5 GHz annuli will be more appropriate. Yes As per comment Submission Slide 16 Principle Add the following definition to section 3: "Cognitive plane: The cognitive plane consists of all the entities in the 802.22 reference architecture that relate to cognitive functions. These cognitive functions are the spectrum manager/spectrum automaton, spectrum sensing function, the geolocation function and the security sub-layer 2. The spectrum manager/spectrum automaton reside at the same level as the MAC common part sub-layer in the data plane whereas the SSF and the geolocation function reside at the same level as the PHY in the data plane. Principle Remove the last paragraph of page 2 and Figure 2. Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 5 Mccann, Stephen Technical On first seeing Figure 5, I assumed that "US Classification Rules" actuallly meant "United States Classification Rules" as opposed to "Up Stream." In addition US is used extensively in Annex A to mean "United States." Also see "BS, CPE" towards the bottom of Table 271.

Yes You may want to disambiguate "US" from "U.S." and also the use of "US" in Annex A. You could adopt the terms downlink (DL) and uplink (UL) instead. 6 Mccann, Stephen Technical I think Clause 5 requires more of an introduction. It's quite a shock to read it following the definitions. Clause 6 is a better example of an introduction to what the standard is trying to do. Yes Soften the impact of Clause 5 on non-IEEE 802.22 readers by providing an Principle It was decided to insert sections 6.2 and 6.3 on Architecture architectural overview and some guidance as to how the purpose (in clause as a new section 5 and renumber the later sections (see 1.2) is met. "Say what you're going to say, say it, then say what you said". resolution of comment #126). Note that there is an inversion of the references to Figures 6 and 7. Inserting 6.2 and 6.3 and modify the first two sentences of clause 5 as follows: "The packet Convergence Sublayer (CS) resides on top of the MAC Common Part Sublayer (CPS). The CS shall perform the following functions utilizing classification (see 5.3.2) governed by rules (see 5.3.3 or 5.3.4) defined by the implementer/operator to process higher layer SDUs so they can be sent and received by the 802.22 BS and CPE. This process can be broken down into four steps, each utilizing the services of the MAC:" 5) Move Clause 5 to clause 6. 6) Renumber Figure 3-9 (if need be) and update any references to them. Submission Slide 17 Principle Change 2-character ISO country codes to 3-character ISO country codes in Annex A. Change US to USA, UK to GBR and CA to CAN in Annex A. Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 7 Mccann, Stephen Technical Figure 7 looks like a "poster paper" for IEEE 802.22. Please break it down into smaller parts. Yes Split the two diagrams within Figure 7 into two new figures. Remove the abbreviation key at the bottom and move those terms into clause 4. Agree

8 Mccann, Stephen Technical The values N-1 and N+1 are only appropriate for a constrained set of N. Does N-1 make sense when N=0? Yes Consider a range for N, e.g. N-1 when N > 0 11 Mccann, Stephen Technical There appear to be two definitions of channel used in the document. "Channel" refers to a frequency set used by an IEEE 802.22 device, whilst "TV Channel" refers to a frequency set used by an incumbent TV service. However, in some places these definitions become muddled, for example in 6.2.3.1, the in-band sensing should be using "TV" Channels N and N+-1. There is a similar issue with "database service" and "TV bands database service"; are these the same entity? Yes If my assumption is correct about the two definitions of channel, then I suggest that every occurance of the word "channel" in the document be checked for its correct context (e.g. "Channel" or "TV Channel". Otherwise, the definition of "TV Channel" should be removed. Additionally the use of "database service" needs to be checked. Disagree Usage of N-1 and N+1 is well understood in normal broadcast operating parlance and used also by the regulators. Special cases at the extremities of the ranges of channels are well understood and do not need to be explicitely described in the definition. Note that the TV band is constituted of many segments (e.g., channels 2-6, 7-13, 14-36, 38-51 in the USA and condition N>0 may not work. Principle Agree to remove "TV" Action: Update def 3.31 to remove "TV" "3.66 channel: Refers to a specific physical channel, a contiguous segment of spectrum in the TV broadcast frequency bands which may be 6, 7 or 8 MHz wide, depending on the relevant regulatory domains . See also: Logical channel." Action: scan "database service" and remove "TV band". The relationship between the " sub-channel" and the "logical channel" has to be clarified. The definition of "sub-channel " needs to be updated as follows: "Sub-channel: The basic unit of the logical channel used for subcarrier allocation in both downstream and upstream. A sub-channel is composed of 28 subcarriers (24 data and 4 pilot subcarriers). Submission Slide 18 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00

References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 12 Mccann, Stephen Technical What is an "official database service"? By whom is it officiated? Yes Change the phrase to read "regulators database service" Principle Remove all occurences (5) of the word "official" in front of "database service". Copy the definition of "database service" from section 3 to section 9.2.2, page 359, line 17. 13 Mccann, Stephen Technical What use is the "Database Service IPx Address" within this primitive? If "higher layers such as IP (P359L17)" are used to access the database, then why does the primitive need to know the IP source (Base Station) and destination (Database) addresses. Surely this information is already present in the IP transport datagram for this primitive? Yes Either remove or clarify why the IP source and destination have to be present in this primitive? Principle The current text has been improved for clarity. The Comment Resolution Committee has decided that the MIB will include the destination URL (i.e., Database Service URL) because it will allow remote management of this information in the BS via SNMP. If not needed, a null address could be put. The CRC decided that the BS URL field should be contained in the MIB table to give the option to specify the inbound address. If not needed, a null address could be put. The BS URL is needed because, if the connection to the Database service has been quiet long enough, the routers may have flushed the IP address/port back to the BS. For the Database service to contact the BS once the BS has provided its inbound URL a first time (e.g., push technology), the Database service needs this BS URL which is to be provided in the payload. For example, it is needed for "push" technology. For this purpose, the BS URL will need to be a public IP address with a specific port by which the BS is accessible. Furthermore, there is a need to declare an inbound URL for station management. Action: Remove the "IF"structures for the Database Service and BS URL's (see attached document). Keep the 5 first rows, 9 and 10, 21-22, 31-32. On row 7, make

the following modification: " Database Service URL Length". Add the following sentence to row 7: "This is used to set the Locator for the Database service." Modify row 21 as follows: 1st column: "Base Station Submission Slide 19 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 15 Mccann, Stephen Technical The "Status" field is only 2 bits long, so that hex "0x" encoding of the values is incorrect. Yes Change the value/description to: 00: INVALID_REQUEST 01: INVALID_SIGNAL_TYPES 10: Reserved 11: SUCCESS 16 Mccann, Stephen Editorial In Figure 33, what does "DTV" refer to. Yes The definition for "Digital Television" needs to be added somewhere in the document. Principle In Figure 33, change DTV for "Television". Add the following definition in section 3: "Digital Television: RF transmission of audio and video by digital signals (e.g., ATSC, DVB-T, ISDB-T)" Add the following definition in section 3: "Analog Television: RF transmission of audio and video by analog signals (e.g., NTSC, PAL, SECAM, ) 22 Mccann, Stephen Technical In Table 78, it's not clear what value is being specified. Yes Explain what value is being defined here. Principle Table 78 is an enumeration of all the combinations of 3 bits and how they correspond to the application of the QoS parameter set. Modify the sentence in section 6.9.8.9.4 as follows: "The format of the QoS parameter set type is defined in Table 77 as the 3 first bits of the octet, and Table 78 enumerates all

the combinations for these 3 bits that define controls for how QoS parameter sets are applied to the service flow that is being configured." Submission Slide 20 Agree Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 25 Diamond, Patrick Technical This excludes other proven methods of delivering the UTC coorelated pps instant such as ieee 1588-2008 from being implemented. Yes eliminate lines 10 - 12. This allows the BS to use any delivery mechanism for the coorelated gps derived clock that meets the time and frequency requirements noted, +/- 2ppm & +/- 2uS pps. 26 Diamond, Patrick Editorial sub-clause 6.26.1 does not exist Yes change to 6.25.1 27 Methley, Steven Technical Location accuracy is normally stated as [email protected]%, for example. In other words a confidence level is required. I realise the FCC R&O does not do this either but other FCC docs do, such as the E911 spec. Confidence in location is important as it is the basis for confidence in not causing interference. Simply relying on 'GPS accuracy' is not sufficient as this will vary in multipath conditions such as dense urban. GPS can be several hundred meters out in these cases - and the standard GPS receiver cannot detect such multipath errors. Furthermore neither GPS nor cell ranging accuracy have been characterised at high confidence levels in nonideal environments yet in the literature - This is because until now there has been no need. Yes No consumer location system is capable of confirming location to +/-50m at Principle The WG agrees in principle with the commentor. However, as the 100% confidence under all conditions as implied in the draft the way it the commentor has indicated, the FCC ruling (2nd MO&O)

is written. Better to specify a realistic confidence level - which ideally ought specifies the accuracy but not the confidence level. As a to be derived from the non-interference confidence level required of the result, the WG has decided to add an additional Table in application. See the FCC E911 specs for examples of how to do this. Annex A specifying the location accuracy and confidence for various regulatory domains. In case of the USA domain, the location accuracy shall be 50 m radius and no value will be specified for the confidence level. As a result of this comment, some further changes have been identified and need to be made to harmonize the content of the Draft as follows: Section 9.5: "The geolocation technology shall detect if any device in the network moves by a distance greater than the values specified in Table xy in Annex A." In section 6.16.2.10, the current wording which came from E911 should be modified as follows: "The BS shall determine the location of the transmitting antenna of each associated CPE with the accuracy as specified in Table xy in Annex A for the specific regulatory domain ." In Table 229, policy 8, change "default +/-25 m" to "default 50 m radius". A new Table needs to be inserted in Annex A specifying the "regulatory domain", "location accuracy", "confidence level" and "distance threshold for the portable device". Note that the distance threshold is smaller than the specified location Submission Slide 21 Principle Remove the title of the sub-section 6.25.1. Add the following sentence at the end of the second paragraph: "Although 802.22 specification requires the presence of a GPS receiver, other techniques (e.g., IEEE 1588-2008) may be considered as long as they meet the required tolerance." Principle Remove the title of the sub-section 6.25.1. Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 65 hu, wendong Technical The text of IEEE 802.22.1 states that the IEEE 802.22.1 superframe shall always have a period equal to (8*124) bits/9609.1 Hz = 103.24 ms. Yes In order to receive the IEEE 802.22.1 superframe in full it requires that a receiving IEEE 802.22 WRAN system stops its data transmission for a least 103.24ms whenever a beacon is detected. Such lengthy interruption of WRAN services is harmful to the timing sensitive WRAN application such as VoIP and video services which require a maximum (MAC-to-MAC) delay of 20ms. Without an appropriate solution for this problem in the 802.22

standard, having a superframe size of 103.24ms renders the timeing sensitive applications (VoIP, video, etc.) not being able to be supported by the 802.22 WRAN systems. 66 67 hu, wendong hu, wendong Disagree An corresponding solution in 802.22 standard should be designed appropriately to resolve this problem if the size of each continous transmission burst of the superframe can not be reduced to less than 20ms. Dynamic Frequency Hopping protocol as adopted in IEEE 802.22 Draft 0.1, which allows an IEEE 802.22 device to perform out-of-band channel sensing while conducting in-band data transmision and seamlessly switch to a candidate clean channel from an in-band operating channel, may be a feasible solution. Technical Specifications for On-demand Frame Contention (ODFC) are incomplete and may be problematic. Yes Technical SCW scheduling shall be designed to enable reliable and efficient communications among the coexisting network cells in order to facilitate effective coexistence operations Yes Submission Please clarify how the QoS problem mentioned above can be resolved given the 802.22.1 beacon superframes in 103.24ms are required to be received by the 802.22 systems. (A) Adopt the specifications for On-demand Frame Contention (ODFC) as adopted in IEEE 802.22 Draft v2.1. (B) In addition to text as suggested in A), more specifications will be needed to fully define the ODFC protocol. Disagree To access the SCWs (collectively as a shared resource) among the coexistence networks for a variety of coexistence communication purposes: a) SCW access should be independent of data frame access, i.e. SCWs should be considered as an independent logical "Control Channel", whereas data frames function as an independent logical "Data Channel". b) Access methods of SCWs should be a hybrid Reservation-Contention SCW access for achieving the best from the two. Disagree Slide 22 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)." Additional Comments: If a P802.22.1 beacon is detected then the communications system needs to vacate the channel. Decoding the payload is not necessary. Note that P802.22.1 requires a receiver that is different from a P802.22 receiver. P802.22.1 beacon was not intended to be decoded by an OFDM / OFDMA based receiver such as the one used in 802.22 . Please see Document 22-09-0093 Rev0. If "Dynamic Frequency Hopping" means that the BS would move to a different channel after detected a TG1 sync burst and scheme would tryasto specified capture the payload through out-of-band The in the current Draft has been developed based on the version that the commentor suggests and has built upon it. The group feels that the current scheme as specified in the Draft is complete and does not need any further change. The current mechanism covers the requirement. It is functionally equivalent (see section 6.7.1 on SCH, Table 1, SCW section and 6.22.1.2. The SCW can only be used for control channel. The contention-based SCW is independent from the data transmission. The reservation-based SCW means that the SCW belongs to the BS using the same frame. There is no need for further action. Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 68 hu, wendong Technical SCW scheduling shall be designed to enable reliable and efficient communications among the coexisting network cells in order to facilitate effective coexistence operations: SCW classification. Yes Classify SCW slots in a super-frame into different types: 1) Reservation (R)

Slots, which are reserved (in a distributed manner) for a "In-band" network cell to perform "contention-free" CBP transmissions; A "in-band" network cell may "own" one or multiple reservation SCW slots in a super-frame (enabling periodic reservation). 2) Free-to-use (F) Slots, which are accessible to all "in-band" network cells, employing a contention-based medium access mechanism (e.g., CSMA). One or multiple "F" slot can be available in a super-frame. 3) Joining (J) Slots, which are accessible to all "out-of-band" network cells and "newly starting" network cells to communicate with the "in-band" network cells, employing a contention-based medium access mechanism (e.g., CSMA). One or multiple "J" slots can be deterministically available in each super-frame (e.g. the last SCW slot in a super-frame). All network cells not transmitting in a "J" slot shall monitor such "J" slot. Principle 69 hu, wendong Technical SCW scheduling shall be designed to enable reliable and efficient communications among the coexisting network cells in order to facilitate effective coexistence operations: Announcement of the allocation of SCW slots. Yes Allocation of SCW slots (SCW-MAP) is announced by each of the network cells using coexistence beacons. SCW slots should include R, F, J types. Principle Submission Slide 23 Wendong: It would be a good idea to differentiate the F and J slots. This would provide better performance. The joining slot could be used by anybody. One way to cover the concern, we could add the policy for the slot on the last frame, we could have a higher priority for joining out-of-channel networks compared to in-channel networks. Higher priority should be given to the out-of-channel contending BSs. Such priority would be adjusted by the parameter of the back-off mechanism. Jianfeng: It would seem better (nice to have) to adjust the back-off parameters to differentiate the priority between the inband network and a new network if we want to give higher priority to a new network. Action: Jianfeng to propose a sentence adjusting the back-off parameters to differentiate the priority between the in-band network and a new network coming on the channel, the latter requiring a higher priority thus a shorter backoff range. Action: In section 6.22.1.2, page 224, line 55, at the end the paragraph ending with: " ... the sixth available contention based SCWs from the transmission of the US-MAP IE.", append the following sentence: "A new base station shall have higher priority to access contention-based SCWs by using smaller backoff window. When a new BS attempts to transmit CBPs via contentionJianfeng: The current mechanism includes the reservationbased and contention-based slots but there is no J type slot. We announce the reservation-based and contention-based slots in the SCH, also transmitted in the CBP.

The contention-based slots can be used by in-channel networks and out-of-channel networks. The current specification covers the needs. At least one contention-based slot has to be scheduled per super-frame in the last frame. See resolution of comment #68. Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 84 Gurley, Thomas Technical In order for users of this standard to build an interface between a nonintegrated antenna and the CPE that will be interoperable among different vendors, the digital storage means and the electrical and timing parameters of the digital signal must be specified. The data elements, their corresponding storage addresses, and the protocol for communicating these data between the antenna and the CPE must also be specified. See also 9.7.6. Yes Specify electrical and timing parameters of the digital signal. Principle Ivan proposed to develop a generic interface based on RS232. Gerald, Tom, Ivan, Ranga worked to propose the resolution to this comment as specified in doc. 22-11-23r3 and 22-11-32r1 85 Gurley, Thomas Technical It is not at all clear how this essential antenna information is provided. Does the antenna possess intelligence to parse requests from the CPE and generate appropriate responses, or does it contain merely data storage (e.g., an EEPROM)? If the latter, then the data must be mapped to specific addresses, so the CPE knows where to access it in the antenna EEPROM. For the interface between a non-integrated antenna and the CPE to be interoperable among different vendors, this mapping must be part of the standard. Yes Provide mapping between antenna data and storage addresses. Principle See resolution of Comment #84. Reading the memory, it would be simpler to make an entire dump to the CPE or a specified dump related to the regulatory domain requested by the CPE. UART (RS-232) interfaces are known and well understood. Winston: Not convinced that there is no need to know how the antenna gain will be provided. We just need to define the primitives. A micro-controller can be programmed to check the validity of the data, for example adding a CRC at the end of the data burst.

With the micro-controller approach, we don't need to specify the memory map. We need to define some instructions. See doc. 22-11-32r1. Submission Slide 24 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 88 Kennedy, Richard Technical Why is Professional Installation in a section on MAC Common Part Sublayer Yes I don't believe that installation, professional or amateur, belongs in a standard, and certainly not as part of the MAC description. The section should probably be part of a Recommended Practice, or in an annex dedicated to regulatory requirements, if professional installation is a regulatory requirement. Principle Include "(see Annex A, Table xx)" after the word "regulations" in the first paragraph. Remove the second paragraph of section 6.16.1.1. Create a new Table xx in Annex A containing 3 columns: "Regulatory domain", "Professional installation required", and a definition of "professional installer" for the USA regulatory domain as follows: "A professional installer is a competent individual or team of individuals with experience in installing radio communications equipment and who normally provides service on a fee basis such an individual or team can generally be expected to be capable of ascertaining the geographic coordinates of a site and entering them into the device for communication to a database." Add a reference to Annex A, Table xx every time professional installation is mentioned in the text. 89 Kennedy, Richard Technical "...shall be professionally installed" may be a regulatory requirement, but does should not bew a MAC Common Sublayer normative statement. Yes I don't believe that installation, professional or amateur, belongs in a standard, and certainly not as part of the MAC description. The section

should probably be part of a Recommended Practice, or in an annex dedicated to regulatory requirements, if professional installation is a regulatory requirement. Principle See resolution of Comment #88. Include "(see Annex A, Table xx)" after the word "regulations" in the first paragraph. Remove the second paragraph of section 6.16.1.1. Create a new Table xx in Annex A conrtaining 3 columns: "Regulatory domain", "Professional installation required", and a definition of "professional installer" for the USA regulatory domain as follows: "A professional installer is a competent individual or team of individuals with experience in installing radio communications equipment and who normally provides service on a fee basis such an individual or team can generally be expected to be capable of ascertaining the geographic coordinates of a site and entering them into the device for communication to a database." Add a reference to Annex A, Table xx every time professional installation is mentioned in the text. Submission Slide 25 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 90 Kennedy, Richard Technical For the most part, the Cognitive Radio Capability section is more like a whitepaper on cognitive radio than a standard, and as its requirement is regulatory domain dependent, should be delegated to a regulatory annex or recommended practice. Yes Regulatory domain dependent functions should be clearly separated from general requirements in the standard. 91 Kennedy, Richard Technical "Satellite-based geolocation is mandatory" is based on regulatory requirements. Yes Regulatory domain dependent functions should be clearly separated from general requirements in the standard. 92 Kennedy, Richard

General Throughout the standard, functions that are dependent upon the regulatory domain in which the devices are operated are mixed in with general requirements: the standard fails to separate these requirements from the general requirements. As additional regulatory domains define their requirements for operation in the TVWS, this standard will require wholesale rewrites to keep it viable. Yes Separate all regulatory domain dependent functions from the general requirements so that as TVWS usage is allowed in more and more countries around the world, the entire document does not have to be rewritten. Submission Slide 26 Unresolvable This comment does not have an actionable proposed change and is more of a style question. Hence we disagree but we are prepared to consider specific changes, acceptable to the chair, that the commentor may be willing to provide by February 4th 2011. Action: Apurva to contact the commentor on Jan 22nd. Apurva sent an e-mail below to the commentor on Jan 22nd 2011, but no response was received: Disagree Having satellite geolocation is an internal 802.22 requirement. Unresolvable The 802.22 Comment resolution committee disagrees with this comment. The 802.22 WG devised Annex A to cover the diffferent regulatory domains requirements and the main body of the standard refers to this Annex. Only Annex A is expected to be modified to include additional regulatory requirements. As it stands, the comment is not actionable. Hence we disagree but we are prepared to consider specific changes, acceptable to the chair, that the commentor may be willing to provide by February 4th 2011. Action: Apurva to contact the commentor by January 22nd. Apurva sent an e-mail below to the commentor on Jan 22nd 2011, but no response was received: Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 93 Ecclesine, Peter General I object to the phrase "The BS shall be professionally installed by a professional" without qualification. There are many qualified individuals that may perform pro bono installations, and that should not be precluded by this standard. The BS might be charitably installed or installed for a religious use by qualified installers who receive no money or professional compensation. 94

Ecclesine, Peter General I object to the title "Professional Installation". The BS might be charitably Yes Change to "Installation to required standards" here, in Figure 32 above. installed or installed for a religious use by qualified installers who receive no money or professional compensation. 95 Ecclesine, Peter General Considering the reference application to low population density regions, I object to the characterization "a professional fixed base station", as the fixed base station may be for educational or religious use. Submission Yes Change to "The BS shall be installed by a professional installer" Yes Delete the word "professional" Slide 27 Principle See resolution of Comment #88.Include "(see Annex A, Table xx)" after the word "regulations" in the first paragraph. Remove the second paragraph of section 6.16.1.1. Create a new Table xx in Annex A containing 3 columns: "Regulatory domain", "Professional installation required", and a definition of "professional installer" for the USA regulatory n asution fol ows: Disagree domai See resol of Comment #89. Note that the definition of "Professional Installer" is consistent with that given by the FCC in the R&O 10-174, clause 3, para. 150. Part 15.711 (b 1 1) indicates that it should be installed professionally." Disagree The Comment Resolution Committee agreed in principle with the commentor and initially decided to change the sentence to "a professionally installed fixed base station". Add: "(see Annex A" at the end of the paragraph. However, the IEEE SA staff asked the Comment Resolution Committee that the title, scope and purpose in the draft need to be exactly specified as that in the PAR with no changes to the words. So the end result was that we could not make the change as proposed by the commentor. However, the Comment Resolution Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 96 Ecclesine, Peter Technical The figure depicts "IEEE 802.11a", but after the 802.11REVma rollup to

IEEE Std 802.11-2007, the proper reference is to the clause 17 OFDM PHY of IEEE 802.11-2007. Needless to say, all versions of the 802.11 clause 17 OFDM PHY have range greater than 33 meters. In the IEEE 802.11-2007 standard, a half-clocked version is specified with twice the cyclic prefix, for use in 4.9 GHz band, and subsequently by 802.11j, 802.11p and 802.11y approved amendments to IEEE 802.11-2007. 802.11y-2008 added quarterclocked 5 MHz version with four times the cyclic prefix protection that is also used by 802.11p-2009. IEEE 802.11n-2009 uses 40 MHz bandwidth as well as 20 MHz bandwidth in 2.4 GHz, and achieves datarates up to 600 Mbps. Check the stores for 11n 3 x 2, 3 x 3 and 4 x 4 are coming this year. Yes Remove the IEEE 802.11a and 802.11 elements from the figure, or fix the bandwidth, range, rate and approved cyclic prefix protections and supply a normative reference in Clause 2. Principle Remove the last paragraph of page 2 and Figure 2. 97 Riegel, Maximilian Technical It is not appropriate for a new standard to be released after the exhausting of the IPv4 address space to make IPv6 support optional. Yes Remove line 20 Principle Modify the sentence on line 20 of page 16 as follows: "IPv6 CS requirements are only applicabley if IPv6 support is enabled during registration." The WG intends to investigate IPv6 support during the maintenance PAR. 98 Riegel, Maximilian General The last sentence of the paragraph starting with 'For IP packets with ...' is out of scope for this section. IEEE802.3 and VLAN parameters belong to section 5.3.2 Yes Remove last sentence of 5.4.2 starting with 'For IP packets with...' Principle Delete the sentence but move the references: "(6.9.8.9.18.3.8 through 6.9.8.9.18.3.12)" to page 16, line 16. Submission Slide 28 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors

have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 99 100 Struik, Rene Struik, Rene Technical (T) Clause 2, p. 4, l. 2-4: It seems imprudent to refer to undated standards, since while a referenced standard may be suitable at time of publication of an IEEE 802.22, this may not longer hold for updates hereof (since these may have created incompatibilities in behavior of other inadvertent sideeffects that may impact usefulness). Suggested remedy: Only refer to specific standards (such as to avoid ambiguity altogether), while adding language to the extent that "At the time of publication, the editions indicated were valid. All standards and specifications are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the references listed below. Yes Technical (TR) Clause 2, p. 4, l. 42: With the PKCS1 reference, it is unclear (to me) whether, e.g., v1.5 is allowed (witness the crystal ball remark in l. 2-4): if so, this would allow RSA MultiPrime and, thereby, RSA schemes with different cryptographic properties than the original scheme. It is unclear whether this is intended. Suggested remedy: Refer to a specific version of PKCS1 (i.e., including version number). Yes Submission Suggested remedy: Only refer to specific standards (such as to avoid ambiguity altogether), while adding language to the extent that "At the time of publication, the editions indicated were valid. All standards and specifications are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the references listed below." Principle Need to date every Standard listed. Suggested remedy: Refer to a specific version of PKCS#1 (i.e., including version number). Principle Suggest to use Version 2.0 if Multiprime is needed.. If Multiprime is not used, refer to the most recent version. RSA Multiprime is not needed, thus referring to the most current version. Not using RSA Multiprime allows aligning with NIST. Ranga is to specify the version of RFC that does not support Multiprime and revise doc. 22-11-0012r3 t rev4. See resolution in doc. 22-11/0012r4 Slide 29 Replace the last sentence of the first paragraph by the proposed sentence. Same sentence to be added to the Bibliography. "At the time of publication, the editions indicated were valid. All standards and specifications are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent

editions of the references listed below." See doc. 22-11-0012r4. These sentences also need to be included at the beginning of the Bibliography. A few other corrections were identified and are to be included in revision 1 of the document. Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 101 Struik, Rene 102 Struik, Rene 103 Struik, Rene Technical (TR Clause 2, p. 4, l. 50-51: To my knowledge, the Key Wrap Specification (November 2001) has never been published as an official NIST standard (official standards usually have the denomer FIPS, NIST SP x-y, etc.). BTW - the NIST Key Wrap web link is broken. More importantly, the NIST key wrap has been criticized by crypto community, e.g., in the paper Key Wrap - Provable Security Treatment of (Phil Rogaway, Thomas Shrimpton, IACR ePrint 2006-221). This calls into question whether this scheme should be used at all. Suggested remedy: Refer to an official (non draft) NIST document that specifies NIST Key Wrap (unfortunately, I could not find this and the NIST CSRC website also does not give conclusive evidence here); Consider replacing the NIST key wrap by another crypto construct.) Yes Editorial (E) Clause 2, p. 5, l. 44-45: The FIPS 180-1 reference is really out of date. Suggested remedy: Replace this reference by FIPS Pub 180-3 (October 2008). Technical (TR) Clause 7: The specification uses SHA-1, which is a hash function that was found to be much less secure against collisions than previously thought in 2005. By now, it is supposed to be phased out and no longer used at all in new applications. The same should apply to a standard that has not been finalized yet, me thinks! Suggested remedy: Abandon SHA-1 throughout the specification and replace by, e.g., another member of the SHA-2 hash function family, with security level consistent with that of the signature algorithm used (SHA-256 with 256-bit prime curve, etc.). Yes Suggested remedy: Replace this reference by FIPS Pub 180-3 (October 2008). Agree Yes

Suggested remedy: Abandon SHA-1 throughout the specification and replace by, e.g., another member of the SHA-2 hash function family, with security level consistent with that of the signature algorithm used (SHA-256 with 256-bit prime curve, etc.). Agree Submission Suggested remedy: Refer to an official (non draft) NIST document that specifies NIST Key Wrap (unfortunately, I could not find this and the NIST CSRC website also does not give conclusive evidence here); Consider replacing the NIST key wrap by another crypto construct. Principle Action: Ranga to identify an official version for this key wrap. Action: Rene to send an email to NIST whether there is a number associated with the key wrap and the reference document, and to get the URL for this document. Considering another key wrap would involve changing a portion of section 7. See do for the resolution to this comment: 22-11-0012r4. Slide 30 Replace all 7 references to SHA1 to SHA-256 in section 7.5. Add a reference to: (FIPS Pub 180-3) Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 104 Struik, Rene Editorial (E) Clause 7.4.3, p. 285, l. 23-26: The referenced RFC documents seem to be partially out of date or may become so in the course of sponsor ballot. Considering Clause 2, p. 5, l. 2-4, does this now also mean that authentication services shall be based on subsequent versions here? Suggested remedy: make references up-to-date (this comment thus more serves as a reminder; however, be aware of potential inconsistencies with old versions introduced by newer versions). Yes Suggested remedy: make references up-to-date (this comment thus more serves as a reminder; however, be aware of potential inconsistencies with old versions introduced by newer versions). The 4 RFCs in section should stay in section 2 unlike indicated in resolution of Comment #10. See resolution in doc 22-11-12r4. 105 Struik, Rene

Editorial (E) Clause 7.5.1, p. 286, l. 2: Replace "RSA of ECC" by "RSA or ECC". Suggested remedy: Implemented as suggested. Yes Suggested remedy: Implemented as suggested. 106 Struik, Rene Technical (TR) Clause 7.5.1, p. 286, l. 6-9: This paragraph suggests that "almost any elliptic curve domain parameter set goes". This seems to be a recipe for incompatibilities and too many options. Moreover, how is one to provide support for efficient implementations if one does not even know yet whether the curve in question would be a prime curve, binary curve? Why not pick a small set of domain parameters (e.g., NIST P-256, P-384, P-521) instead? Suggested remedy: Specify a very limited set of curves to be used here (e.g., Suite B NIST prime curves corresponding to crypto bit strength 128, 192, 256). Yes Suggested remedy: Specify a very limited set of curves to be used here (e.g., Suite B NIST prime curves corresponding to crypto bit strength 128, 192, 256). Submission Principle Rene: This RFC 5246 has been updated by another RFC. This is then not the latest version. Doc 12r1 did not address this reference. Action: Ranga provided the correct references to the RFC's in doc. 22-11-0012r2. Agree Principle Action: Ranga will narrow down the list of possible elliptic curves and enumerate the short list of curves that will be used to reduce the options and compatibility. Prime number versus binary based ECC. Binary is computationally efficient whereas prime number is more secure. Concern expressed about complexity and the impact on the cost of the CPEs. ECC is not that demanding in memory and computing cycles. The binary approach is preferred by the group to reduce the complexity. Action: Ranga to produce text to update this paragraph to reduce the number of curves to also cover comment # 110, 227 and 228. See resolution in doc. 22-11-28r1. Slide 31 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors

have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 107 Struik, Rene Technical (TR) Clause 7.5.1, p. 286, l. 8-9: It is suggested that domain parameters produce keys of between 160-256 bits in length. This language is highly ambiguous, since it is not clear whether private keys or public keys are meant here. Assuming private keys and prime curves, this limits the crypto bit strength of the resulting ECC scheme to between 80-128 bits; with binary curves a little bit less. (With public keys, the crypto bit strength would be completely inadequate, since at most 64 bits.) Moreover, why this 256-bit upper limit? Suggested remedy: Rewrite this paragraph, so as to make this more precise. Yes Suggested remedy: Rewrite this paragraph, so as to make this more precise. Principle Remove the following sentence: "Domain parameters sets that are selected will produce keys of no less than 160 and no greater than 256 bits in length." 108 Struik, Rene Yes Suggested: Fix accordingly. Principle Remove the following sentence: "Restrictions posed on the certificate values are described in 7.5.1." 109 Struik, Rene Technical (T) Clause 7.5.1, p. 286, l. 11: This sentence seems to be a circular reference (since referring to the Clause it is at the end of). Suggested: Fix accordingly. Technical (TR) Clause 7.5.1.3.2, p. 287, l. 23-25: With ECDSA, one can considerably speed-up signature verification for prime curves and binary non-Koblitz curves. For those curves speed-ups of the incremental cost of ECDSA signature verification of 40% are possible (SAC 2005 result). Cf. also IETF78 meetings. To reap these benefits, simply add the following sentence at l. 29: "When the ephemeral public key R:=(x1,y1):=kG that is generated during the ECDSA signature generation algorithm has an odd valued ycoordinate y1,the ECDSA signature component s SHALL be changed towards the integer -s (modulo n), where n is the prime order of the cyclic subgroup of the elliptic curve in question." Note that this extra postprocessing step can be executed by any party and that using accelerated methods for signature verification is (of course) entirely optional. Note also that this does not jeopardize compliance with any existing ECDSA formats. Suggested remedy: Add this sentence, as suggested. Yes Suggested remedy: Add this sentence, as suggested. Principle Add the following sentence after line 29, page 287: "When the ephemeral public key R:=(x1,y1):=kG that is generated during the ECDSA signature generation algorithm has an odd valued "y-" coordinate "y1", the ECDSA signature component "s"

SHALL be changed towards the integer "-s" (modulo n), where "n" is the prime order of the cyclic subgroup of the elliptic curve in question. Note that this extra post-processing step can be executed by any party and that using accelerated methods for signature verification is (of course) entirely optional." Submission Slide 32 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 110 Struik, Rene Technical (TR) Clause 7.5.1.5.2, p. 290, l. 17-19: This seems to suggest that any implementation has to support compressed elliptic curve points. If so, this may present a burden to some implementers. Why not offer less choice and always mandate affine representation of elliptic curve points (or, generate points so that the y-coordinate is always uniquely determined from knowledge of the x-coordinate only). Suggested remedy: Reduce choice here, as suggested. Yes Suggested remedy: Reduce choice here, as suggested. Principle Action: Modify the following sentence: "ECPoint represents the base point of an elliptic curve and can take on two forms, compressed and uncompressed [defined in ANSI X9.62-2005]. For certificates the encoding of ECPoint shall be supported by the uncompressed form. The compressed form may (optionally) be used instead." See resolution of Comment #106 and 107. Action: Ranga to provide the same list of specific parameters specified for the two previous comments Action: Ranga to produce text to update this paragraph to reduce the number of curves to also cover comment # 106, 227 and 228. See resolution in doc. 22-11-28r1. 111 Struik, Rene Technical (TR) Clause 7.6.2, Figure 125, p. 295: This figure is highly unclear and suggests that private keying material is communicated during protocol flows. Why would this be secure? What is the benefit of using an implicit certificate scheme if one has to ship private keys to devices as part of this? Suggested remedy: Please carefully explain. I should be able to help (since I know the implicit certificate scheme itself by heart).

Submission Yes Suggested remedy: Please carefully explain. I should be able to help (since I know the implicit certificate scheme itself by heart). Slide 33 Principle This comment is related to Comment #113 and 114. The commentor participated during the 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments. Rene: Figure 125 is unclear. Ranga: Figure is not intended to demonstrate the security of the protocol but how the certificates are distributed. Rene: There is not enough information at the BS to generate the necessary keys and certificates for the CA. There is a need for authentication as well. Does it imply a private key on a public key? Ranga: Private key re-construction would be more appropriate but there are missing informations. Action: Rene to look at the text and propose modifications. Discuss over email. Figure 125 may need to be changed as well as the text preceding it. Ranga will modify the Figure. Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 112 Struik, Rene Technical (TR) Clause 7.6.2, p. 294, l. 25-26: This statement seems incorrect: One can view implicit certificates (as specified in draft SEC4), as certificates where the public key and the signature are "super-imposed", thus removing all redundancy. As a result, one cannot verify the correctness of an implicit certificate by itself (since there is no redundancy, in constrast to, e.g., ECDSA certs); one has to find out by using the reconstructed public key in an application instead. Suggested remedy: Please modify this description accordingly. I would be happy to help. Yes Suggested remedy: Please modify this description accordingly. I would be happy to help. Principle The commentor participated during the 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments. Resolution: Modify the one-before-last sentence as follows: "If the receiving BS supports the CBP protection, and has the

key that can be used to verify the signature, the signature verification process is started." See resolution in doc. 22-11-28r1. 113 Struik, Rene Technical (TR) Clause 7.6.2, p. 294, l. 28-32: It is unclear how this scheme works and what the benefits of using implicit certificates over "explicit" certificates are. Once again, it is not possible to verify implicit certificates by themselves, so the language needs to be cleaned up here. Suggested remedy: Correct incorrect description and clarify the use case. I would be happy to help. Yes Suggested remedy: Correct incorrect description and clarify the use case. I would be happy to help. Principle The commentor participated during the 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments.Action: Rene to investigate this more and report to the WG during telecons. 114 Struik, Rene Technical (TR) Clause 7.6.2.1, p. 295, l. 7: The format of BS certificates in Table 192 seems to be highly inconsistent with that for ECDSA and RSA certificates (which are all specified in X509 format - cf., e.g., Clause 7.5.1.5). Suggested remedy: Make the certificate formats in the specification consistent. I would be happy to help. Yes Suggested remedy: Make the certificate formats in the specification consistent. I would be happy to help. See commentor document 22-1-28r1 for the finaltheresolution. Disagree The participated during 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments.The format of the current implicit certificate is inconsistent with the ECDSA and RSA certifcates (which are all specified in X509 format - cf., e.g., Clause 7.5.1.5) because of the serious size constraint that needs to be imposed on these certificates to reduce the overhead and avoid unnecessary transmissions. At this time the Comment Resolution Committee does not see any need to adhere to the X509 format and reduced size of the certificate as specified in the Draft is preferred. Submission Slide 34

Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 115 Struik, Rene Technical (TR) Clause 7.6.2.1, p. 296, Step 3), l. 4: The specification is incomplete, if only because it is not clear what representation is used to specify the Implicit Certificate Public Key. Suggested remedy: Clarify. Yes Suggested remedy: Clarify. 116 Struik, Rene Technical (TR) Clause 7.6.2.1, p. 296, Step 3): It is completely unclear why the public key is fed through a kdf function here. It seems that the result of the latter is used in a symmetric-key cryptographic mode of operation (GCM mode). If so, this suggests that anyone can "sign", since the "signature" does only require access to public information (thereby, breaking the entire security). Suggested remedy: Provide evidence that this construct is secure! Yes Suggested remedy: Provide evidence that this construct is secure! 117 Struik, Rene Technical (TR) Clause 7.6.2, p. 296: With Mode 2, the CA generates public/private key pairs for the base stations. If so, the advantage of implicit certificates over many other schemes (namely, that the CA does not learn anything about the base stations's private key) goes away. Suggested remedy: Please clarify the use case. Yes Suggested remedy: Please clarify the use case. Submission Slide 35 Principle The commentor participated during the 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments.Section 7.6.2.5.2 describe the signature generation process. A reference should be added.In NIST Sec4, section 2.2 of v0.91, there is a set of requisites. There is a need to refer to item 6 in this section.

Action: Ranga to include appropriate text and reference to the SECG document: SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), during v0.91. the 802.22 interim meeting Principle The commentor participated in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments.See resolution in doc. 22-11-28r1. Principle The commentor participated during the 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments.Resolution: The difference is how the device is loaded with the certificate. The ultimate goal is to have a small certificate. It is not known at this time if these are other schemes that can use as small certificate. There are 2 entities initiating the transactions that seem to be collapsed. Another entity besides the CA should be identified Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 118 Struik, Rene Technical (TR) Clause 7.6.2, p. 296, l. 18: With Mode 2, it is suggested that the public-private key pair is distributed via an out-of-band channel ("SIM card"). If so, key distribution seems to be left as an exercise to implementers. Does this now require implementers to come up with a plethora of mutually incompatible "key inject" solutions (USB slot, PINs, wire, etc.)? Again, not clear how this would fit the use case then. Suggested remedy: Provide specification of key distribution scheme in this case that does not create these incompatibility problems noted above. Yes Suggested remedy: Provide specification of key distribution scheme in this case that does not create these incompatibility problems noted above. Principle The commentor participated during the 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments.Resolution: There is a need to describe the procedure for key distribution and to generate the certificates. Rene: Solution 1: leave the mechanism outside the Standard. However, different solutions will be developed. Solution 2: Only allow this to be distributed by wireless means between base stations. However different communications means may

be used. Solution 3: preclude Mode 2 because it cannot be communicated by the wireless link. Action: Ranga to prepare some text to cover this concern and circulate by email. Since this is only BS-to-BS, it should not be that difficult. General procedure can be descrivbed in the Standard and more details would be made available from the Recommended Practice. See resolution in doc. 22-11-28r1. 119 Struik, Rene Technical (TR) Clause 7.6.2.2, p. 296, Step 5: The use of the word "signature" is misleading, since one uses a symmetric-key construct for this and it is unclear which security properties (if any) are provided here. Suggested remedy: Use nomenclature that is well-defined. Yes Suggested remedy: Use nomenclature that is well-defined. Principle The commentor participated during the 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments. Resolution: The word "signature " is inappropriate. It should be "message integrity code" (MIC). Action: Ranga to identify the IE's that need to be modified to align with this new name as well as to scan section 7 for the changes. 14 Feb: Ranga: received Rene's input. There is an issue with mode 1. Signature is rather long for the small data field. Can the signature truncated? Can it be hashed to make it shorter? Could 8 octets be used rather than 32? Text is needed to clarify how this works. Action: Ranga to update the text in the section and verify with Rene off line. See resolution in doc. 22-11-28r1. Submission Slide 36 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 120 Struik, Rene Technical (TR) Clause 7.6.2.3, p. 297, Table 192: Why not use an offset for the Key Validity Date? This would allow shaving off at least 8 bits (1 year is roughly 25-bit seconds, so 33 bits are sufficient to describe 256 years here, with base year 2011. Suggested remedy: Compress representation accordingly.

Yes Suggested remedy: Compress representation accordingly. 121 Struik, Rene Technical (TR) Clause 7.6.2.3, p. 297, Table 192: It does not seem to make sense to have validity periods with granularity of 1/2 year, whereas key validity starttime with granularity of seconds. Suggested remedy: Better align granularity of different elements of the certificate policy fields. Yes Suggested remedy: Better align granularity of different elements of the certificate policy fields. Technical (TR) Clause 7.6.2.4.1, p. 298, Step 5, l. 21-23: It is unclear how one could limit the key validity period of operator CA root certificates. Suggested remedy: Please specify. Yes 122 Struik, Rene Submission Suggested remedy: Please specify. Slide 37 Principle The commentor participated during the 802.22 interim meeting in Los Angeles as well as over the telecons. We appreciate the help from the commentor to resolve the comments. Resolution: Same Table appears in section 6 as well. A way to shave off bits in the representation, one can use a different start year, e.g., 2011 could be used as the first year. Counting seconds in a year needs 25 bits counter. Action: Make the field "Key Validity Data" 32 bits. Modify the first indent in the description as follows: " 2000 + x where x encoded by 7bits Add a new 4th row as follows: "Version number flag: 1 bit. 0: Current version 1: reserved for future use." Tablefor18a smaller in sectionvalidity 6. period for the certificate? Out of Scope Update Is there the a need It has to do with the time to re-use a certificate, i.e., the number of certificates that are in reserve. Ranga: 6 months seem to be a good balance. Comment was withdrawn. No further action needed. Principle The format of the CA root certificate has not been specified. This is needed. If an operator has behaved badly, there is a need to revoque his certificate. Action: Ranga to consider defining it based on Table 192. See resolution in doc. 22-11-28r1.

Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 123 Struik, Rene Technical (TR) Clause 7.6.2.4.2, p. 298, Step 1, l. 25-32: It is unclear whether the initiator is allowed the reuse ephemeral keying material (e.g., in case the protocol aborts prematurely). If not, this may impose a considerable burden on the initiator device, due to expense of public key generation and, more importantly, prospect of DoS attacks that could trigger premature abortion of the protocol. Suggested remedy: Please specify clearly. 124 Struik, Rene Technical (TR) Clause 7.6.2.4.3, p. 299, Step 4: This suggests that shooting-in a CA Yes Suggested remedy: Provide over-the-air method that securely installs a root Out of Scope Rene Struik joined the IEEE 802.22 session during the Los root key is out of scope and presumably done out-of-band. This seems to CA key into a device. I would be happy to help here. Angeles interim and also multiple telecons. We are greatful to be a recipe for incompatibility and inflexibility (who would ever install another Rene for his assistance. Ranga: This is going to the BS, not root CA key if the procedures are different or non-existent, depending on to the individual CPEs. The suggested over-the-air method vendor?). Suggested remedy: Provide over-the-air method that securely would not be appropriate. installs a root CA key into a device. I would be happy to help here. Rene: Is there a way to update the root CA otherwise? Ranga: It is done over the NCMS. This comment was Submission Yes Suggested remedy: Please specify clearly. Slide 38 Principle On page 298, at the end of line 30, insert the following sentence: "An ephemeral key pair shall never be re-used." Also add periods to both bullets. See resolution in doc. 22-11-28r1. Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 125 Struik, Rene Technical (TR) Clause 2, p. 5, l-12: To my knowledge, the SEC4 specification is only a draft specification and, thereby, may be subject to change. A standard should not reference external specifications as normative references, it the

latter are only draft standards. Suggested remedy: Create an Annex that specifies the full details of the SEC4 scheme as used in the IEEE 802.22 standard, so as to be independent of any changes made by an external standards body. Please note here that the latest draft on the SECG website is v0.91 (dated November 18, 2008), with prior version dated November 15, 2006. The version referenced in 802.22 (from June 2006) is neither of these. Yes Suggested remedy: Create an Annex that specifies the full details of the SEC4 scheme as used in the IEEE 802.22 standard, so as to be independent of any changes made by an external standards body. Please note here that the latest draft on the SECG website is v0.91 (dated November 18, 2008), with prior version dated November 15, 2006. The version referenced in 802.22 (from June 2006) is neither of these. Principle Need to refer to the right version of the Standard: November 15, 2006 Could refer to the Web site re. version of November 15, 2006 Send a note to the SECG to clarify. We are referring to a Draft document from SECG to be issued in a few weeks. The choice is to include the material as an annex or assume that that draft will be formally adopted by SECG and the reference can be updated as an editorial change. The Comment Resolution Committee decided to keep the reference to the draft document. See the final resolution in doc. 22-11-13r4. 126 Riegel, Maximilian Technical The chapter 6.2 Reference Architecture and 6.3 Management Reference Architecture are exceeding the scope of Chapter 6, MAC Common Part Sublayer Yes Section 6.2 and 6.3 should be moved out of Chapter 6 into section 1 or a new section before section 5. Principle Insert 6.2 and 6.3 under a new section 5 entitled: "System Architecture", Renumber sections 5 to 12 to 6 to 13. 127 Riegel, Maximilian Technical Concurrent support of IP-CS and ETH-CS violates the design principles of RFC4830. When a CPE supports both ETH-CS and IP-CS, it should be ensured that concurrent operation is not allowed. Yes Add note to Table 50: 'Concurrent operation of ETH-CS and IP-CS in the same CPE is not supported'. Principle Remove option "0x02: Both Ethernet and IP CS" from Table 50. Change 0x00 to 0x02. Add 0x00:reserved. Make changes in the previous paragraph accordingly: change IE=0 to IE=2.

Submission Slide 39 Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 References P802.22 - Negative Comments from SB that were addressed and resolved but where the commentors have maintained their negative vote during SB Re-circ #1: Document 22-11-0040 Rev5 128 Riegel, Maximilian Technical The CS Parameter Encodings are overly redundant and complex; Three encodings are ful y sufficient. Submission Yes Only 3 encodings are required: no CS, IP-CS, ETH-CS. Remove all encodings and introduce 2 new parameters for ETH-CS (802.3/VLAN w/ IPv4, IPv6) and IP-CS (IPv4, IPv6) Slide 40 Agree Make the fol owing changes to Table 99: 0x00: No CS 0x01: IP CS (IPv4, IPv6) 0x02: ETH-CS (802.3/VLAN with IPv4, IPv6) 0x03-0xFF: Reserved Apurva N. Mody, BAE Systems March 2011 doc.: IEEE 802.22-11/0042r00 Contingency Motion 802.22 WG Motion #4 Document 22-11-0043 Rev 0 In case another round of re-circulation is needed after the Sponsor Ballot Re-circulation #2 for Draft P802.22/D3.0 The IEEE 802.22 Working Group authorizes the WG Chair to conduct telecons to address and resolve the comments, prepare the new Draft P802.22/D4.0 and launch the Sponsor Ballot Re-circulation. The IEEE 802.22 WG also authorizes the WG Chair to forward P802.22/ D4.0 to the IEEE SA RevCom and conduct any business that the Chair may require to progress the approval of the standard. Move: Gwangzeen Ko Second: Sasaki Shigenobu For: 9 Against: 0 Abstain: 0 Motion passes unanimously Submission Slide 41 Apurva N. Mody, BAE Systems

Recently Viewed Presentations

  • IEEE Update for Continua - ITU

    IEEE Update for Continua - ITU

    IEEE 11073 Personal Health Devices work group update Daidi Zhong, Michael J. Kirwan Working Group Co-Chair 28th Nov, 2013 Membership 319 members 206 organizations Weekly conference calls (Thursday 8:15 AM Pacific) Last for 90 min Face to face meetings planned...
  • WELCOME [s3.amazonaws.com]

    WELCOME [s3.amazonaws.com]

    Fall - Boys & Girls Cross Country . Football . Girls Swimming & Diving. Payment on line at time of registration. Cut sports pay fees after teams are selected. Fall - Boys Soccer . Girls Tennis . Girls Volleyball. Boys...
  • i am redeemed 7th Annual Camp Caleb 2013

    i am redeemed 7th Annual Camp Caleb 2013

    i am redeemed 7th Annual Camp Caleb 2013 October 25th-27th
  • Accounting in Business Chapter 1 PowerPoint Editor: Beth

    Accounting in Business Chapter 1 PowerPoint Editor: Beth

    Every account is an asset, a liability, or a subset of equity. There are four subsets of equity. Owner investments and revenues increase equity, and owner withdrawals and expenses decrease equity. Each asset account, along with its balance, appears directly...
  • CHEMISTRY - The World of Teaching

    CHEMISTRY - The World of Teaching

    CHEMISTRY Form 2 [email protected] (Mauritius) Objectives To recall the term CFC (Chlorofluorocarbon) To use the periodic table to list the elements found in CFC To describe the importance of the ozone layer To search for information on CFC and ozone...
  • Tech Que: &quot;Shake It Up&quot; Title Graphic

    Tech Que: "Shake It Up" Title Graphic

    Tech Que: "Shake it Up" Title Graphic. Hundreds of years before it even happened, God told His people about an event that was going to shake the world. Ever since Adam and Eve first disobeyed, God's people had to offer...
  • The Student Conservation Association

    The Student Conservation Association

    The Student Conservation Association changing lives through service to nature Kassy Theobald, FIREMON Project Leader - Coeur d'Alene Tribe T H E S T U D E N T C O N S E R V A T I O...
  • Review for Midterm II Spring 2004 - uml.edu

    Review for Midterm II Spring 2004 - uml.edu

    Were none of the above. Sample Primary Source Passages "I have ventured to bring together various dicta ["sayings"] of the holy fathers, as they came to mind, and to formulate certain questions which were suggested by the seeming contradictions in...