IEEE P802.22

Wireless RANs

I. Attendance

II. 2010-05-24 Teleconference

II.A Agenda

1) Record Attendance

2) Ask if everyone is familiar with the IEEE patent policy:

http://standards.ieee.org/board/pat/pat-slideset.pdf

3) Approve the agenda.

4) Review/propose comment resolutions for comments in the MAC section (Clause 6) from the latest comment database:

∙ DCN# 22-10/78r5: https://mentor.ieee.org/802.22/dcn/10/22-10-0078-05-0000-wran-draft-3-0-ballot-comments-database.xls

5) Other business.

II.B Notes (2010-05-24)

1) R Reddy recorded the attendance at 20:05 EDT.

2) A citation to the IEEE patent policy was provided with the announcement of the meeting. When asked, no one notified the chairman that they were unfamiliar with the IEEE patent policy.

3) The was no formal agenda provided prior to the meeting, next week’s announcement will be more thorough.

4) Review/propose the resolutions for the following comments in the database: 22-10/78r5.

CID 141:

In 802.16, they create a MAC PDU with a GMH with CID = Padding CID. It was decided to go with the simpler approach (in 802.22), by padding the extra space with 0’s which are then fed into a scrambler, which is then modulated by the DIUC or UIUC of the last burst of the subframe in question.

Resolution: Accept

CID 226:

R Reddy proposed that one of the possible changes is to restructure the DS-MAP IE to make them the same length.

G Chounaird, It was found to be unnecessary. Even without the extended DIUCs, the total count is 37 bit which would require 3 bits padding for each IE. With 50 IEs, for example, this padding would represent 150 bits. It is better to pad it once at the end of the DS-MAP.

Resolution: Counter

Action: Add padding bits to Table 35, and remove the padding bits from Tables 36, 38, and 39.

CID 227:

Based on discussion for CID 226, we decided to accept this modification at face value.

Resolution: Accept

CID 231:

Based on discussion for CID 226, we decided to accept this modification at face value.

Resolution: Accept

CID 249:

Group decided to adopted the same approach for US-MAP and US-MAP IEs as was adopted for DS in resolution to CID 226/227/231.

Resolution: Counter

Action: Add padding bits to Table 46, and remove the padding bits from Tables 47, 49, 50, 51, and 52.

CID 262:

Based on our resolution to CID 249, we decided to accept this comment.

Resolution: Accept

CID 267:

Based on our resolution to CID 249, we decided to accept this comment.

Resolution: Accept

CID 263:

The group decided that the order of the US-MAP IEs (and corresponding UIUCs) should be Table 48 followed by the explanation of EIRP UIUC=9 for US-MAP EIRP Control IE, then CBP UIUC which is already referenced in Table 48 under UIUC=0, then CDMA UIUC which is already referenced in Table 48 under UIUC=7 (10-12 are still reserved) and then the extended UIUC and the last sub-section being the Dummy Extended UIUC.

Resolution: Counter

Action: G Chouinard to produce text modification to Table 48 and renumbering of US-MAP IE related sections

CID 260:

Based on discussion for CID 263, also agreed to dedicated a specific UIUC for Initial Ranging ( = 8). Agree with inclusion of new UIUC = 8 for the initial ranging allocation. Keep the extended UIUC with Table 50 and the Dummy application with Table 51 for test purposes.

Resolution: Counter

Action: G Chouinard to modify Table 48 as discussed.

CID 229:

Discussion led group to agree to keep the Extended and Dummy IEs for DS-MAP to accommodate future expansion. With regard to this comment no new modifications are required to Tables 37, 38, and 39. Table 40 will be handled by resolution to comment 228.

Resolution: Counter

CID 228/230:

Group had previously agreed to accept new CID management approach originally proposed in DCN# 22-09/112r1. It was agreed in principle to remove the "IF(Include_CID)" row and

remove "N_CID" row and remove the "for loop" row since no clear application was found for the use of multiple CIDs for a DS-MAP IE. Also remove the CID Switch extended CID, that is section 6.10.2.1.2.2 and Table 40. A new DCN# 22-09/112r2 needs to be uploaded by R Reddy, that will indicate all the specific modifications to draft that will be required. One such modification is will be to the structure of DS-MAP IE.

Resolution: Pending

5) Other Business (further discussion via Email):

CID 226:

In the case of the DS-MAP in Table 35, we no longer need the 4 reserved bits on row 4 if the padding bits to the octet boundary is added at the end of the Table. Also, the two extended DIUC IEs (generic and Dummy in Table 38/39) should express their total lengths in bits with an 8 bit Length parameter and the padding bits should be removed from Table 38 and 39.

Resolution: Counter, apply this new resolution for CID 226.

CID 252:

G Chounaird: US-MAP CBP Channel IE is a variable size IE and should either include 5 padding bits before the “Length” parameter and the “CBP IEs relay flag” should be brought forward before the “Length” parameter if we want to keep the length in octets. Otherwise, the “Length” should be expressed in bits with at least 7 bits. What is the preference?

R Reddy: My preference, based on what we discussed last night is the latter. Expresse the length in bits. But is 2^7=128 enough? The CBP burst is a total of 836 bits. Accounting for CBP MAC PDU header, I still the length >128. Plus I have some issues with CBP, that I want to bring up during the Coexistence and next MAC calls. We can initiate another email discussion for that.

G Chounaird: Agree with the length in bits. However, this IE only transmits the CBP IEs that need to be included to the CBP at the CPE, not the entire CBP. I suggest 8 bits for the length, which would gives us up to 31 CBP IEs to be added to the CBP. That should be plenty. I will align all the other lengths to 8 bits in # of bits.

R Reddy: However, Gerald, regarding the US-MAP CBP Channel lE. I know that CURRENTLY this is to specify how many CBP IEs are being given to the CPE to use to construct a CBP Burst. Frankly, this is a feature that I'm not entirely comfortable with. I would be more in favor of the BS constructing the CBP burst and and just using the CPE as a dumb terminal to relay it. This would simplify the CPE, e.g. allow concentration of CBP burst tx logic and CBP security at the BS. This has been brought in CID 169 - Apurva (discussed in Beijing) and CID 408 - myself. 169 has been countered and the principle behind it was accepted. So, as far as the CBP Channel IE is concerned, it should really cover the length of the CBP burst minus CBP MAC PDU header (hoping that CBP MAC PDU header doesn't have variable length).

Resolution: Defer.

Action: Need to come to final decision of functionality of CBP transmission and subsequently the specifics of the US-MAP CBP Channel IE. This will also affect the resolution of CID 252, if not others.

CID 260:

The EIRP Control IE for US-MAP is fixed in length at 20 bits, but length needs to expressed in bits to be consistent.

Resolution: Counter, apply this new resolution for CID 260.

CID 263:

R Reddy and G Chounaird had further discussion via email. The CBP Channel and CDMA Initial Allocation IE are already referenced with specific UIUCs in Table 47, so we don’t need to transfer them to UIUC 10 and 11, respectively. Also for the Extended and Dummy IEs, we should reflect their length usings 8bits for the total length of the IE.

Resolution: Counter, apply this new resolution for CID 263.

CID 269:

R Reddy and G Chounaird had further discussion via email. Additionally, if CID 269 proposed resolution is approved, CDMA Initial Allocation IE will have length of 20 instead of 32. Appropriate modification to Table 47 is required.

Resolution: Counter.

Action: Bring up CID 269 during next MAC call and accept this resolution.

III. 2010-05-31 Teleconference

III.A Agenda

1) Record Attendance

2) Ask if everyone is familiar with the IEEE patent policy:

http://standards.ieee.org/board/pat/pat-slideset.pdf

3) Approve the agenda.

4) Approve the previous meeting minutes:

∙ DCN: 22-10/80r1: https://mentor.ieee.org/802.22/dcn/10/22-10-0080-01-0000-mac-ad-hoc-conference-call-minutes-for-D3-ballot.doc

5) Review/propose comment resolutions for comments in the MAC section (Clause 6) from the latest comment database:

∙ DCN# 22-10/78r6: https://mentor.ieee.org/802.22/dcn/10/22-10-0078-06-0000-wran-draft-3-0-ballot-comments-database.xls

6) Other Business

III.B Notes (2010-05-31)

1) R Reddy recorded the attendance at 20:05 EDT.

2) A citation to the IEEE patent policy was provided with the announcement of the meeting. When asked, no one notified the chairman that they were unfamiliar with the IEEE patent policy.

3) Approve the agenda.

4) Approve the last meeting minutes.

5) Review/propose resolutions for the following comments in the latest database 22-10/78r6:

CID 253:

Initiated some discussion on email. Waiting for ETRI comments on notification method and window design. CDMA method is slower for UCS than opportunisitic method. So does size of method depend on window.

Resolution: Defer.

CID 254:

Since group decided a UIUC for Initial ranging was specified was necessary. See last week’s resolution to CID 260.

Resolution: Accept.

CID 255:

Explanation in suggested resolution is acceptable. However, do we have to support up to 100km-away CPEs, all the time. See Resolution to CID 256.

Resolution: Accept

CID 256:

The normal case is to accommodate a 50km cell with a 1 symbol and signal a 100km cell with a 2 symbol buffer using a 1bit flag.

Resolution: Counter

CID 257:

Change in table is not the only change that has to be made. Several other changes to the title of Section 6.10.4.1.3, caption for Table 53, the name of the IE in table 48. However, there is still some question as to the specific use of this IE. G Chounaird to verify the specific use of the IE.

Resolution: Pending

Action: G Chounaird to verify the specific use of this IE. Pending that discovery, naming of this IE as “initial” may not be appropriate.

CID 258:

Accept to align with use of Transaction ID throughout rest of draft.

Resolution: Accept.

CID 268:

Keeping Pending based on our discussion of CID 257.

Resolution: Pending resolution of CID 257.

CID 271:

Group discussion agrees with this proposal, it makes sense.

Resolution: Accept.

CID 272:

I Reede still on board with going to Method 2 in 22-09/114. Method 1 is difficult to implement. Privacy is still kept because MAC address of FCC ID, serial # are not transmitted in the same burst.

Resolution: Accept.

CID 273:

Element IDs are scoped to a particular message. Action to assign a specific # for the IEs in question.

Resolution: Accept.

Action: Editorial action to renumber element IDs in Table 55.

CID 274:

This was an oversight, so group accepts, to be consistent with DIUC specification.

Resolution: Accept.

CID 275:

(1) of the comment has been addressed as far as R Reddy is concerned, we’ll leave the MAC address in. For (2), R Reddy suggests to keep it pending to give time to implement CID privacy (Method 2 in 22-09/114) and management methods (22-09/112r2).

Resolution: Pending

CID 276:

G Chounaird is suggesting is to treat TU as a specific value, instead of a delta from ranging message to message. Simple editorial change needed to remove text in square brackets. I Reede suggested to make this a “unsigned” timing advance value.

Resolution: Counter

CID 277:

Group accepts this, proposed change makes sense.

Resolution: Accept

CID 278:

This IE may be redundant because DIUC/UIUC is indicated in the MAPs. Keeping it, allows the BS to signal to CPE what MCS it can use in the future. This may not work because we can’t predict fading or multipath in the future, so TPC adaptive MCS (signaled through MAPs) are used to compensate. Group decided to accept this IE.

Resolution: Accept

CID 279:

Group is deciding to go with CPE privacy method 2 in 22-09/114.

Resolution: Reject

CID 281:

Group is deciding to go with CPE privacy method 2 in 22-09/114.

Resolution: Reject

6) Other Business (discussion via email):

CID 257:

After verification, this comment should be rejected since this parameter is not only used for initial ranging purpose. See comment 268

Resolution: Reject

CID 268:

G Chounaird verified that the CDMA Allocation IE is used for other purposes besides initial ranging.

Resolution: Counter. Implement changes as follows:

After verification, the word "Initial" should not appear in the title of the section and the introductory sentence should read: "This IE is used by the BS to assign a US bandwidth allocation to a new CPE that signalled its wish to either associate through the Initial Ranging CDMA burst, to signal the presence of an incumbent through by the CDMA UCS Notification or to request a BW allocation through the CDMA BW Request burst."

CID 269:

G Chounaird verified that the CDMA Allocation IE is used for other purposes besides initial ranging.

Resolution: Counter. Implement changes in comment resolution, with the modification that “for initial ranging” in Row 3 Table 53 should be deleted.

IV. 2010-06-14 Teleconference

IV.A Agenda

1) Record Attendance

2) Ask if everyone is familiar with the IEEE patent policy:

http://standards.ieee.org/board/pat/pat-slideset.pdf

3) Approve the agenda.

4) Approve the previous meeting minutes:

∙ DCN: 22-10/80r2: https://mentor.ieee.org/802.22/dcn/10/22-10-0080-02-0000-mac-ad-hoc-conference-call-minutes-for-D3-ballot.doc

5) Review/propose comment resolutions for comments in the MAC section (Clause 6) from the latest comment database:

∙ DCN# 22-10/78r8: https://mentor.ieee.org/802.22/dcn/10/22-10-0078-08-0000-wran-draft-3-0-ballot-comments-database.xls

6) Other Business

IV.B Notes (2010-06-14)

1) R Reddy recorded the attendance at 20:07 EDT.

2) A citation to the IEEE patent policy was provided with the announcement of the meeting. When asked, no one notified the chairman that they were unfamiliar with the IEEE patent policy.

3) Approve the agenda. Modified agenda to reflect 22-10/78r8 as latest version of comment database, approved with no contest.

4) Approve the last meeting minutes. Minutes approved with no contest

5) Review/propose resolutions for the following comments in the latest database 22-10/78r8:

Note: R Reddy suggests to have a 2nd MAC call Wednesday, G Chounaird agrees. Same telecon bridge will be used.

CID 281:

R Reddy wants to modify solution so that CPE is not capable of both. G Chounaird agrees. W Caldwell says that are other functional requirements for a CPE has to support, so that switiching modes may not be possible. For example, fixed devices have permanently installed antenna. G Chounaird states that with the smart antenna chip providing gain, the CPE could “reset” itself upon grabbing new gain. We have to consider practical implications of supporting multi-mode CPEs when concerned with implementation.

Resolution: Counter. Remove “and/”, remove the setting 0x02=both, and change Reserved to 0x02-0xFF. G Chounaird, suggests also chaninging “capable” to “to be operated as”.

CID 282:

R Reddy has yet to produce new version to 22-09/112 to make sure all other references to CID in draft (not related to MAPs, MAC management messages) are properly handled.

Resolution: Pending.

CID 287:

Does Table 69 need to reflect supporting inter- or intra-frame sensing explicitly? G Chounaird sees it that when CPE registers it should declare it’s capability; signal level/threshold, and time required. R Reddy, is there anything in Table 69 specifying that multiple periods. G Chounaird yes, but how would CPE know thresholds. R Reddy, CPE doesn’t could put some default value, and BS could adjust sensing period parameters along the CPE’s capabilities (e.g. increase number of periods, duration). I Reede, how are QPs synchronized between WRAN cells, signals beteen -95dBm - -115dBm will be a problem. G Chounaird, no ont really because sensing device should be able to pull the signal from that low a level. I Reede is asking to verify that we can sensing requirement that sensing 20dB below signal level is possible. G Chounaird, for WRANs close enough SCH and CBP can be heard and used to synchronize QPs.

Resolution: Reject. Table 69 contains all the parameters to properly characterize the CPE sensing.

CID 288:

Does this need to be even specified? The BS couldn’t care less how many interfaces for sensing/data usage is needed.

Resolution: Accept

Action: To remove the “Dedicated Interface” field of Table 69

CID 289:

Aggreed to remove.

Resolution: Supercede with resolution to CID 290

CID 290:

Converted to TR. Table already exists in Section 9. Aggreed to remove.

Resolution: Counter

Action: Change text in note for STA field in table 69 to refer to Table 254, then delete table 70.

CID 292:

In discussion of 293, we decided to keep the Gain value. Annex A has the channel index (e.g. channels 2-84).

Resolution: Pending

Action: Cognitive Radio Capabilities Adhoc to resolve comments and develop text that describes storage of antenna gain information in the EEPROM that will be the interface to the antenna

CID 293:

G Chounaird BS does not need to know antenna Gain. I Reede, false. BS could use this info determine which channels should be on its candidate channel list so it avoid losing CPEs who don’t have sufficient gain on some channels. G Chounaird, disagrees because we’re adjusting EIRP, and the level of EIRP would be known by BS. I Reede, since we have at most 80 channels, we can simplify this signaling and make it more efficient. G Chounaird, in clause 8 we define minimum sensitivity, but it seems like I Reede says that this may change channel to channel. We could remove it on Tx side because of EIRP, but on Rx sensitivity can change.

Resolution: Reject

6) Other Business: None

V. 2010-06-16 Teleconference

V.A Agenda

1) Record Attendance

2) Ask if everyone is familiar with the IEEE patent policy:

http://standards.ieee.org/board/pat/pat-slideset.pdf

3) Approve the agenda.

4) Approve the previous meeting minutes:

∙ DCN: 22-10/80r3: https://mentor.ieee.org/802.22/dcn/10/22-10-0080-03-0000-mac-ad-hoc-conference-call-minutes-for-D3-ballot.doc

5) Review/propose comment resolutions for comments in the MAC section (Clause 6) from the latest comment database:

∙ DCN# 22-10/78r8: https://mentor.ieee.org/802.22/dcn/10/22-10-0078-08-0000-wran-draft-3-0-ballot-comments-database.xls

6) Other Business

V.B Notes (2010-06-16)

1) R Reddy recorded the attendance at 20:18 EDT.

2) A citation to the IEEE patent policy was provided with the announcement of the meeting. When asked, no one notified the chairman that they were unfamiliar with the IEEE patent policy.

3) Approve the agenda. Modified agenda to reflect 22-10/78r8 as latest version of comment database, approved with no contest.

4) Approve the last meeting minutes. Minutes approved with no contest

5) Review/propose resolutions for the following comments in the latest database 22-10/78r8:

CID 300:

R Reddy what’s the purpose of this message. It can be accomplished by periodic ranging. I Reede agrees, the CPE could be much simpler. Group agrees message is redundant, can be deleted. Also page 166, line 22-23 in Section 6.18.1 needs to be updated as well.

Resolution: Counter. Update pg 166, line 22-23 as recorded in minutes to replace “DBPC” with “RNG”. Remove section 6.10.11 and 6.10.12

CID 301:

Discussion of CID 300, we’ve decided to accept.

Resolution: Superseded.

CID 302:

See CID 310. Accept in principle, based on acceptance of CID 310.

Resolution: Superseded.

CID 310:

Slight modification to proposed resolution. Modify text change for code 0x04, remove text after ‘;’. Add “on current operating channel” to text for action code 0x05. Remove 6.10.13. Also change range in Table 127 for reserved to be 0x06-0xFF.

Resolution: Counter

CID 303:

Erroneous comment. Nothing needs to be changed. Proper type field for Table 120 is 24.

Resolution: Reject.

CID 304:

From 802.16-2009, this IE is used in CBC-REQ/RSP to indicate support for H-FDD or FDD. Since FDD is not supported in 802.22 this IE is not needed.

Resolution: Counter

Action: G Chounaird, modify sentence preceding text in 6.10.14.3. Text modification recorded in comment database.

CID 306:

See resolution of CID 214. PHY adhoc group to review 214 and comment on this issue.

Resolution: Defer

CID 307:

R Reddy does this need to be negotiated during basic capabilities? G Chounaird, not that urgent, could be moved during REG-REQ/RSP. Add this message as a new subsection under 6.10.7.3, which describes the set of IEs for REG-REQ/RSP.

Resolution: Pending

Action: G Chounaird to provide text under a new subsection after 6.10.7.3.6.7.

CID 308:

Related to comment 232, that needs to be reviewed by PHY adhoc.

Resolution: Defer

CID 311:

G Chounaird the technical content of message as defined is inconsistent. CPE doesn’t need to advise BS of the next channel it would attempt access on. R Reddy this message may be unnecessary. If CPE needs to shutdown, it will vacate its context on its own. If BS doesn’t hear from CPE (e.g. periodic ranging) or CPE Registration Timer expires, it will vacate it’s context of CPE anyway. Modified text change to definition of code 0x04 as proposed for CID 310

Resolution: Defer

Action: Delete 6.10.16, modified text change to definition of code 0x04 as proposed for CID 310

CID 312:

G Chounaird, some fields in CHT-REQ refer to capabilities, e.g. channel bonding, that don’t exist. R Reddy, do we even need this message. G Chounaird is this only way to move cell. R Reddy there should be, but DREG-CMD is only unicast on Basic CID. G Chounaird this message is for indicating a specific subset up to a whole cell worth of CPEs that have to switch. R Reddy do we need Terminate Count field? G Chounaird, yes because this allows BS to schedule switch for a time when CPEs can support. This would allow the ability to allow BS to “ease” channel switch in an effort to support QoS.

Resolution: Accept

CID 313:

R Reddy, CHS-REQ is message is redundant with CHT-REQ. Only difference is the scope, CHT-REQ is defined over primary management, multicast management, and broadcast CID. CHS-REQ is defined over primary management and broadcast management.

Resolution: Defer

Action: G Chounaird and R Reddy to look at use of this messages and determine which message is to be kept.

6) Other Business:

Note: R Reddy to send notes and attendance from June Interim MAC sessions to A Mody & G Chounaird.

Note: There was some more discussion via email on CID 310-313. New/modified resolutions to those comments are as follows:

CID 310:

We decided to not remove section 6.10.16. In addition to the resolution discussed above, remove the “Next Channel Number” field in Table 126

Resolution: Counter

CID 311:

Modify the text for action code = 0x04 in Table 127 as follows: “CPE shall terminate current Normal Operations with the BS and shutdown.; tThe BS shall transmit this action code only in response to any CPE DREG-REQ message or when directed to by a governing policy (See Table 251)." Also remove “Next Channel Number” and “Information Element IEs” in Table 128. In Table 128, modify “Notes” field for “De-Registration Request Code” as follows: “0x00 = CPE de-registration requests de-registration from BS 0x01-0xFF = reserved”

Resolution: Counter

CID 312:

We decided to remove the CHT-REQ message, because it’s functionality could be handled by the DREG-CMD. Remove 6.10.20.1, 6.10.20.2, and references to CHT-REQ/RSP in Table 29.

Resolution: Counter

CID 313:

We decided to remove the CHT-REQ message, because it’s functionality could be handled by the DREG-CMD. We decided to keep CHS-REQ message, but we just delete rows 5 & 6 in Table 134.

Resolution: Counter

VI. 2010-06-21 Teleconference

VI.A Agenda

1) Record Attendance

2) Ask if everyone is familiar with the IEEE patent policy:

http://standards.ieee.org/board/pat/pat-slideset.pdf

3) Approve the agenda.

4) Approve the previous meeting minutes:

∙ DCN: 22-10/80r5: https://mentor.ieee.org/802.22/dcn/10/22-10-0080-05-0000-mac-ad-hoc-conference-call-minutes-for-D3-ballot.doc

5) Review/propose comment resolutions for comments in the MAC section (Clause 6) from the latest comment database:

∙ DCN# 22-10/78r9: https://mentor.ieee.org/802.22/dcn/10/22-10-0078-09-0000-wran-draft-3-0-ballot-comments-database.xls

6) Other Business

VI.B Notes (2010-06-21)

1) R Reddy recorded the attendance at 20:00 EDT.

2) A citation to the IEEE patent policy was provided with the announcement of the meeting. When asked, no one notified the chairman that they were unfamiliar with the IEEE patent policy.

3) Approve the agenda. Modified agenda to reflect 22-10/78r9 as latest version of comment database, approved with no contest.

4) Approve the last meeting minutes. Minutes approved with no contest

5) Review/propose resolutions for the following comments in the latest database 22-10/78r9:

CID 314:

R Reddy suggest we keep this message to update QP configuration for non-coexistence cases.

Resolution: Reject

CID 316:

R Reddy suggest we keep this message to update QP configuration for non-coexistence cases.

Resolution: Reject

CID 315:

R Reddy, thinks that I Reede is missing the point. The purpose of the message is to only quiet down .22 devices in the channel to facilitate (best-effort) detection of non-.22 devices in the channel. The typical SNR to meet the -114 dBm sensing threshold is -19 dB. This can be result from thermal noise or any other RF device in band.

Resolution: Reject

CID 318:

Group has already decided to use CHO-UPD as a subtractive raster of channels that sensing that don’t need to be needed. Related comments are 220, 317, 351, 464, 466, 615, 616, 618, and 628.

Resolution: Counter, name of message change to “incumbent disallowed channel” updated, IDC-UPD.

CID 319:

Move this to the Security ad-hoc.

CID 320:

Move this to the Security ad-hoc.

CID 321:

R Reddy in resolution of 362 will handle this point. Said timer will be named and a new contribution to be updated soon.

Resolution: Pending

CID 322:

Related to CID 175, which a resolution has been agreed to (but not confirmed). Proposed resolution is consistent with CID 175.

Resolution: Accept

CID 323:

To modify table, a new table needs to be created.

Resolution: Pending

CID 324:

802.22 doesn’t support HARQ. The only representations of HARQ in D3 are in 6.12.3.4.

Resolution: Accept

CID 325:

To be consistent with 175 and 322, the group suggests to accept.

Resolution: Accept

CID 326:

R Reddy, suggests to withdraw. Not technically important to resolve this comment

Resolution: Withdraw

CID 326:

R Reddy, suggests to withdraw. Not technically important to resolve this comment

Resolution: Withdraw

CID 328:

R Reddy, related 175, 322, and 325.

Resolution: Accept

CID 329:

The sentence in question is erroneous because multicast and broadcast or DS only services.

Resolution: Accept

CID 334:

The proper reference is 6.17.2.6.3, already handled as an editorial comment.

Resolution: Accept

CID 335:

A Mody, since we had portability added to PAR there are specific changes. W Caldwell, CID 361 references a CID 402 from previous ballot whose text modification wasn’t handled properly.

Resolution: Pending

Action: R Reddy to review 22-09/225r0 when developing contribution to resolve 362. If solution to 362 can be grafted onto 22-09/225r0, then a new revision of that document will be created. If not, then R Reddy will be generate a new contribution

CID 336:

Removal of this figure is already suggested in 22-10/97 latest revision that is in response to CID 393, 397, 400-403

Resolution: Pending

CID 339:

Discussion during Beijing meeting, all similar comments from R Reddy have already been rejected. See comments 97, 554, 559, et al.

Resolution: Reject

CID 340:

R Reddy, why was this comment entered here. G Chounaird, this comment is non-actionable. BS/system designed to only operate more than one channel. A Mody, related to CID 4 and 5, earlier sessions have removed support for channel bonding. This doesn’t prevent operators from using sectorization or reduced coverage to support this kind of operation.

Resolution: Reject

CID 341:

G Chounaird, this has discussed previously, does text exist to describe what a professional installation means? W Caldwell, maybe we’ve had discussions, but not words put down into the draft. R Reddy, 6.17.1.1 is the appropriate place to put a clearer definition of the term.

Resolution: Pending

Action: W Caldwell, to provide new text for 6.17.1.1

CID 342:

G Chounaird, not comfortable with this. Current figure is more accurate than assuming a database always exists. In the policy table, if the database always exists, it has priorities over sensing, if database doesn’t exist sensing has priority. So, always assuming database operates precludes use of sensing. Current design of SM in Clause 9 already assumes a database exists.

Resolution: Reject

6) Other Business:

Note: R Reddy to send notes and attendance from June Interim MAC sessions to A Mody & G Chounaird.

VI. 2010-06-28 Teleconference

VI.A Agenda

1) Record Attendance

2) Ask if everyone is familiar with the IEEE patent policy:

http://standards.ieee.org/board/pat/pat-slideset.pdf

3) Approve the agenda.

4) Approve the previous meeting minutes:

∙ DCN: 22-10/80r6: https://mentor.ieee.org/802.22/dcn/10/22-10-0080-06-0000-mac-ad-hoc-conference-call-minutes-for-D3-ballot.doc

5) Review/propose comment resolutions for comments in the MAC section (Clause 6) from the latest comment database:

∙ DCN# 22-10/78r10: https://mentor.ieee.org/802.22/dcn/10/22-10-0078-10-0000-wran-draft-3-0-ballot-comments-database.xls

6) Other Business

VI.B Notes (2010-06-28)

1) R Reddy recorded the attendance at 20:00 EDT.

2) A citation to the IEEE patent policy was provided with the announcement of the meeting. When asked, no one notified the chairman that they were unfamiliar with the IEEE patent policy.

3) Approve the agenda. Modified agenda to reflect 22-10/78r10 as latest version of comment database, approved with no contest.

4) Approve the last meeting minutes. Minutes approved with no contest

5) Review/propose resolutions for the following comments in the latest database 22-10/78r10:

._________________________