22100175040000clause67commentresolutionford4文档格式.docx

1、This document contains resolutions for the following comments:77, 78, 84, 94, 128, 134, 136, 141, 142, 145, 165, 259 Text modification for comment resolution is indicated in bold and italics encapsulated in square brackets. For some comments there is more than one modification required.R0 is an amen

2、dment to resolutions to comments against D4, that are updated against the numbering of the D5 draft （editorial instructions in R1 are against numbering/pagination in D5）, in addition to resolution for a couple of new comments in Clause 7.R1-R3 detail comment resolution modifications discussed in the

3、 November 2010 plenary.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 contr

4、ibutor（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 copyr

5、ight 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 contrib

6、ution 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 statement IEEE standards may include the known use of patent（s）, including patent applications, provided the IEEE receives assurance from t

7、he 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 develo

8、pment process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair Apurva Mody as early as possible, in written or electronic form, if patented technology （or technology under patent application） might be incorporated into a draft standard

9、being developed within the IEEE 802.22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .Comment 77/78/84Several comments are related to consolidating the fragmentation/packing subheader. The resolution to this comment is provided to facilitate discussion of t

10、he design of the new subheader. The other comments related to this will then be resolved in turn.There are two major modifications to the Fragmentation/Packing subheader. One, is the consolidation of the two subheaders. Two, it is removal for support of two different counting methods for counting fr

11、agments. We have two methods for counting fragments, one used for when ARQ is applied and when when ARQ isnt applied. It is of the opinion of the MAC ad-hoc chair that we dont need two different methods. Referring back to 802.16-2009, the 3bit counting method is optional. So, the recommendation is t

12、o remove it. We should note that if a Fragmentation/Packing subheader is added to a PDU mapped to a connection using ARQ, the then Type field Bit2 （Extended Type） shall be set to 1.Also, note that the ARQ feedback subheader is independent of the fragmentation/packing process. If purpose of new Fragm

13、entation/Packing, is set to packing （i.e. set to 1）, then the ARQ Feedback subheader is the 1st packed item. This is stated in 6.8.1.2.4.modify Section 6.8.1.2.2 as follows-Start of text Modification-6.8.1.2.2 Fragmentation/Packing SubheaderTable 6 Fragmentation/Packing subheader formatSyntaxSizeNot

14、esFragmentation_Subheader_Format（） Purpose1 bit0 = Fragmentation subheader1 = Packing subheaderFC2 bitsIndicates the fragmentation state of the payload:00 = no fragmentation01 = last fragment10 = first fragment11 = continuing （middle） fragmentif （ARQ-enabled Connection） BSN10 bitsSequence number of

15、the first block in the current SDU fragmentElse FSNSequence number of the current SDU fragment. This field increments by one （modulo 1024） for each fragment, including unfragmented SDUs. If （Purpose = 1） Length11 bitsLength of SDU fragment being packed Else/if （Purpose = 0） Reserved3 bits -End of te

16、xt Modification-modify Table 110, pg 87 line 1 as followsElement IDLength（bytes）ValueScope21Bit 0: Ability to receive requests piggybacked with data Bits 1-7: reserved （set to zero）CBC-REQ, CBC-RSPComment 134This comment reflects reformatting some tables associated with the configuration of SCM rela

17、ted message parameters. modify Tables 166-173 as followsTable 166 SCM EAP Start - Message AttributesKey Sequence Number4 bitsAK Sequence NumberTable 167 SCM EAP Transfer - Message AttributesLength of EAP Payload16 bitsLength of EAP Payload （in octets）EAP PayloadVariableContains EAP authentication Da

18、taTable 168 SCM Key-Request attributesAK sequence numberSAIDSecurity association identifier - GSAID for multicast or broadcast serviceGroup Key Indicator0 = this key request is for a TEK1 = this request is for a GTEK, only applicable if SAID refers to a GSA.CPE Random64 bitsA 64 bit random number ge

19、nerated in the CPE.Table 169 SCM Key-Reply attributesKey Sequence Number AK sequence number SAID Security association identifier - GSAID for multicast or broadcast service. Older TEK/GTEK 128 bitsOlder generation TEK/GTEK relevant to SAID/GSAID Older TEK/GTEK Sequence NumberSequence Number for older

20、 generation of TEK/GTEK. This maps to the value EKS field is set to in GMH of PDU encrypted with this TEK/GTEK.Remaing Lifetime for Older TEK/GTEK24 bitsRemaining time for older TEK/GTEK in units of 10ms frames.Newer TEK/GTEK Newer generation TEK/GTEK, relevant to SAID/ GSAID. New TEK/GTEK Sequence

21、Number Sequence Number for newer generation of TEK/GTEK. This maps to the value EKS field is set to in GMH of PDU encrypted with this TEK/GTEK.Remaing Lifetime for New TEK/GTEKRemainging time for older TEK/GTEK in units of 10ms frames.CPE Random The same random number included in the SCM Key Request

22、 message BS Random Random # generated by the BSTable 170 SCM Key-Reject attributesSecurity association identifier Confirmation Code 8 bitsError code （see 6.10.24） identifying reason for rejection of the SCM Key-Request message.A same random number included in the SCM Key Request message Table 171 SC

23、M GSA-Add attributesMulticast SID9 bitsSID of multicast groupSAID for GSA applied to the mutlicast groupCryptographic Suite for GTEK application & transportCryptographic suite that controls how GTEK is applied and transported to CPE. This can be either 0x03 or 0x04 （see Table 194）.Cryptographic Suit

24、e for GKEK/GTEK GenerationCryptographic suite that controls how GKEK & GTEK is generated at BS. This can be either 0x06 or 0x07 （see Table 194）.GKEK GKEK for GSA used to protect GTEK when transported to CPE in Key-Reply. This field is protected with the KEK associated with the AK.Remainging GKEK Lif

25、etimeRemaining lifetime in which GKEK can be used to protect GTEKs in SCM Key-Reply messages. In units of 10ms frames.Table 172 SCM GSA-Remove attributesNumber of SAID“N” Number of SAIDs for GSA （GSAIDs） that are to be removedSAID（s）N * 16 bitsList of SAIDs for GSAs that are to be removedTable 173 S

26、CM TEK-Invalid attributesSecurity Association Identifier Error code （see 6.10.24） identifying reason for SCM TEK-Invalid message. Comment 136This comment reflects harmonizing the Message Response Code numbers in Table 176 and Table 79. A new message response code table is propose to be moved to the end of Section 6.10.remove the text on lines 11-12 and Table 78 on pg 73remove section 6.10.21.9insert new section at the end of sec