22100080040000macadhocconferencecallminutesford3ballot.docx

1、22100080040000macadhocconferencecallminutesford3ballotIEEE P802.22Wireless RANsMAC Ad-Hoc Conference Call Minutes for D3 BallotDate: 2010-06-14Author(s):NameCompanyAddressPhoneemailRanga ReddyUS Armyranga.reddyieee.orgAbstractThis document contains the minutes for 802.22 MAC Ad-hoc teleconferences,

2、resolving D3 ballot comments:R0 has the minutes for the teleconference held on Monday May 24th 2010 at 20:00 EDT. R1 is an update to the minutes of the telecon held on Monday May 24th 2010 at 20:00 EDT. R2 has the minutes for the teleconference held on Monday May 31st 2010 at 20:00 EDT.R3 has the mi

3、nutes for the teleconference held on Monday June 14th 2010 at 20:00 EDT.R4 has the minutes for the teleconference held on Monday June 16th 2010 at 20:00 EDT.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 i

4、ndividual(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 incorpor

5、ate 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 r

6、eproduce 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 , including the state

7、ment 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 Work

8、ing 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 as early as possible, in written or ele

9、ctronic 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 . I. AttendanceNameAffiliation24 May 201031 May 20

10、1014 June 201016 June 2010Gerald ChouinardCRCXXXXWinston CaldwellFOXXXXApurva ModyBAE SystemsXXXXRanga ReddyUS ArmyXXXXIvan ReedeAmerisysXXXJason LiWi-LANXX II. 2010-05-24 Teleconference II.A Agenda1) Record Attendance2) Ask if everyone is familiar with the IEEE patent policy:http:/standards.ieee.or

11、g/board/pat/pat-slideset.pdf3) 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.xls5) Other business.

12、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

13、to the meeting, next weeks 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 t

14、he extra space with 0s 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: AcceptCID 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

15、, 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: CounterAction: Add padding b

16、its 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: AcceptCID 231: Based on discussion for CID 226, we decided to accept this modification at face value.Resolution: AcceptCI

17、D 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: CounterAction: 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 d

18、ecided to accept this comment.Resolution: AcceptCID 267: Based on our resolution to CID 249, we decided to accept this comment.Resolution: AcceptCID 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-

19、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: CounterAction: G Choui

20、nard to produce text modification to Table 48 and renumbering of US-MAP IE related sectionsCID 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 wi

21、th Table 50 and the Dummy application with Table 51 for test purposes.Resolution: CounterAction: 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 modifi

22、cations are required to Tables 37, 38, and 39. Table 40 will be handled by resolution to comment 228.Resolution: CounterCID 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

23、 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

24、specific modifications to draft that will be required. One such modification is will be to the structure of DS-MAP IE.Resolution: Pending5) 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

25、 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 resolu

26、tion 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 “Leng

27、th” 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 27=128 enough? The CBP burst is a total of 836 bits. Accounting for CBP MAC PDU header, I still the length 128

28、. 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 en

29、tire 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

30、CBP IEs are being given to the CPE to use to construct a CBP Burst. Frankly, this is a feature that Im 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 conce

31、ntration 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 doesnt 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