2002/09/24 IEEE 802.16-02/43r2 Carl Eklund Technical, Non-binding Type Apply edits under Comment IV from document C802.16c-02/09 Suggested Remedy Starting Page # PKM timer values are needed before the download of the configuration file. If they are different from the default they should be returned in the Auth Reply message Comment 01 Comment # Comment submitted by: P802.16c/D3 Document under Review: 0000314 Ballot Number: Comment Date Proposed Resolution Recommendation by Recommendation: Resolution of Group Decision of Group: Accepted Reason for Recommendation Reason for Group's Decision/Resolution Group's Action Items Group's Notes Editor's Actions Editor's Notes Editor's Questions and Concerns Editor's Action Items Starting Line # 6.2.2.3.9.3 Section Fig/Table#
40
Embed
IEEE P802.16c/D3 Sponsor Ballot Comment Report · downlink channel." This sentence should be clarified to explicitly include any RTG or TTG. Comment Comment #08 Comment submitted
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
2002/09/24 IEEE 802.16-02/43r2
Carl Eklund
Technical, Non-bindingType
Apply edits under Comment IV from document C802.16c-02/09Suggested Remedy
Starting Page #
PKM timer values are needed before the download of the configuration file. If they are different from the default they should be returned inthe Auth Reply message
Comment
0 1Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Resolution of Group Decision of Group: Accepted-Modified
Reason for Recommendation
Delete 11.4.9.3.1.
We agree with the need to remove these sections from IEEE 802.16.However, the content of 11.4.9.3.2 from IEEE 802.16 is already deleted by 802.16c/D3.
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
Starting Line # 11.4.9.3.1SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Carl Eklund
Technical, Non-bindingType
Fix indentation to show parameters being subcodes of SS Capabilities and change order to be as in Comment VIII in documentC802.16c-02/09
Suggested Remedy
56Starting Page #
The TLV parameter order for REG-REQ and REG-RSP are incorrectly indented. Also the order should be such that all capabilities encodingsare consecutive. All capabilities should be sent as a nested TLV
Comment
0 3Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
apply editorial instruction under Comment XI in document C802.16c-02/09Suggested Remedy
Starting Page #
The time to increase power diamond is ambiguos. Also the text suggests that power should be increased every time between transmissionsrendering the diamond moot.
Comment
0 5Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
TO: 802.16 Working GroupFROM: Jennifer LongmanDATE: 20 August 2002RE: Editorial Review of P802.16c/D3
Upon review of P802.16c/D3, I have the following comments:
1. The information now contained in the Scope and Purpose should be removed and added to the EDITORIAL NOTE. No new information should be added to theScope and Purpose, unless you are specifically modifying those clauses in the base standard.
The following is an example of from 802.1t-2001:EDITORIAL NOTE—This amendment to IEEE Std 802.1D, 1998 Edition (ISO/IEC 15802-3:1998) defines the changes necessary in order to address maintenance items that have been brought to theattention of the 802.1 Working Group. These changes are defined as a series of additions to, and modifications of, the existing text of ISO/IEC 15802-3:1998; this supplement therefore assumes allmaterial, including references, abbreviations, definitions, procedures, services and protocols defined in the base text. Text shown in bold italics in this amendment defines the editing instructionsnecessary in order to incorporate the modifications and additions into the base text. Three editing instructions are used: change, delete, and insert. Change is used to make a change to existingmaterial. The editing instruction specifies the location of the change and describes what is being changed either by using strikethrough to remove old material or underscore to add new material.Delete removes existing material. Insert adds new material without changing the existing material. Insertions may require renumbering. If so, renumbering instructions are given in the editinginstruction. Editorial notes will not be carried over into future editions of IEEE Std 802.1D.The following is an example from 802.11d-2001 showing a slightly different style:[This amendment is based on the current edition of IEEE Std 802.11, 1999 Edition and the IEEE Std 802.11a-1999 and IEEE Std 802.11b-1999 amendments.]NOTE—The editing instructions contained in this amendment define how to merge the material contained herein into the existing base standard to form the new comprehensive standard as created bythe addition of IEEE Std 802.11-1999.The editing instructions are shown in bold italic. Three editing instructions are used: change, delete, and insert. Change is used to make small corrections in existing text or tables. The editinginstruction specifies the location of the change and describes what is being changed either by using strikethrough (to remove old material) or underscore (to add new material). Delete removesexisting material. Insert adds new material without disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions are given in the editing instruction. Editorialnotes will not be carried over into future editions.
If you have any questions, please do not hesitate to contact me at any time.
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Starting Line # SectionFig/Table#
Accepted
Editor's Action Items
Resolution of Group Decision of Group:
2002/09/24 IEEE 802.16-02/43r2
Roger Marks Member
Technical, Non-bindingType
Add a new item to 802.16c that changes the sentence by adding at the end: ", including allowance for the Tx/Rx and Rx/Tx Transition Gaps".Suggested Remedy
Starting Page #
Std 802.16-2001 needs a clarification. In last sentence on p. 93. 6.2.7.2 says: "If half-duplex subscriber stations are used, the bandwidthcontroller shall not allocate uplink bandwidth for a half-duplex subscriber station at the same time that it is expected to receive data on thedownlink channel." This sentence should be clarified to explicitly include any RTG or TTG.
Comment
0 8Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Resolution of Group Decision of Group: Accepted-Modified
Reason for Recommendation
Add a new item to 802.16c that changes the sentence by adding at the end: ", including allowance for the propagation delay, Tx/Rx andRx/Tx Transition Gaps".
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
Starting Line # SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Roger Marks Member
EditorialType
Add a change to delete the extra space in the fourth line of 6.2.5.4 (p. 85) of IEEE Std 802.16-2001, Suggested Remedy
Starting Page #
In IEEE Std 802.16-2001, 6.2.5.4 (p. 85) has extra space in the fourth line.Comment
0 9Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Resolution of Group Decision of Group: Accepted-Modified
Reason for Recommendation
Delete empty page ii, or mark “This page intentionally left blank.”Set line numbers (1-65 on left column) in color to indicate that they are temporary.
Line numbers must remain in draft for commenting purposes, but will not be in published standard.
The "cancellations" must remain, since they are a fundamental part of the standard. This standard is an amendment to IEEE Standard802.16 The marks are used to indicate changes to that standard. This is explained in "Editorial instructions" on Page 5. This editorialprocedure is required by IEEE-SA.
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
Starting Line # SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Carl Eklund
EditorialType
Apply edits under Comment III from document C802.16c-02/09Suggested Remedy
Starting Page #
Figure 133 omits the pad.Comment
1 1Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
a) This is C notation. I recommend using standard Hex notationb) what is the meaning of the 'X' after the 'F'? I recommend using a notation that is more clear e.g. put a table with a bit mask
Comment
1 2Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Resolution of Group Decision of Group: Accepted-Modified
Reason for Recommendation
after 0xFX add the phrase "where 'X' means 'don't care'"
C notation is consistent with the base document, but clarification of the standard usage of X to mean don't care is agood idea.Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
15Starting Line # 6.2.2.1.1SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Carl Eklund
Technical, Non-bindingType
Delete sentence The UL-MAP defines the uplink usage in terms of the offset from the previous IE start (the length) in numbers of minislots.'Suggested Remedy
12Starting Page #
Contradiction in paragraph 6.2.7.5Comment
1 3Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Fix figure numbering throughout the document.Suggested Remedy
15Starting Page #
We need to get the figure numbering correct so it isn't confusing. Figures would be replaced by figures with the same number. Additionalinserted figures have the xxa, xxb, ... numbering.
Comment
1 4Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
The commentor was looking at older version of draft document. The current draft has corrected this issue already.Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
3Starting Line # 6.2.9.9SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Kenneth Stanwood Member
EditorialType
Make certain the order of figures is correct.Suggested Remedy
15Starting Page #
It looks like Figure 55 should be after figures 54a and 54b.Comment
1 5Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
This change simply corrects two small typographical errors in IEEE Std 802.16. If 802.16a makes technical changes to the same figure,those will take precedence over the editorial changes made here in 802.16c.
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
41Starting Line # 6.2.10SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Kenneth Stanwood Member
EditorialType
Before line 1, insert the header:
"8.2 PHY for 10-66 GHz"
Suggested Remedy
20Starting Page #
The comment on line 1 refers to a different section than the previous header that appears in the document.Comment
1 7Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
The font in sections 12 and 12.1 is smaller than in the rest of the document. The same thing occurs in the first line of section 12.1.1.3.It also occurs on page 34, lines 52 and 61.
Comment
2 3Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
The information that is being asked to be tabularized is 6 pages in length and contains a lot of information. It would be very difficult totabularize. Table 13 (in section 6.2.2.3 of IEEE Std 802.16) already lists the messages where they are defined. Section 12.1.1.4 has asubsection for each message saying how it is dealt with for this profile.
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
Starting Line # 12.1.1.4SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Jose Gutierrez Member
EditorialType
See aboveSuggested Remedy
55Starting Page #
The heading on 12.1.1.4 tries to say a lot of things. I recommend changind it for 'MAC Managemnent Services' and inside this section createa subheading with the topic of 'Parameter Transmission Order'
Comment
3 0Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Resolution of Group Decision of Group: Accepted-Modified
Reason for Recommendation
Change the title of the header to "12.1.1.4 MAC Management Message Parameter Transmission Order"
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
32Starting Line # 12.1.1.4SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Neil Shipp Member
Technical, Non-bindingType
6% (or greater ?)Suggested Remedy
64Starting Page #
Assuming that this specification applies to the output of the SS transmitter and not simply the modulator then 2% modulation accuracyunequalised implies extremely tight tolerances on transmit filter frequency and group delay response. I estimate that 2% peak error equatesto <0.5dB gain flatness in the passband.
Comment
3 1Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Resolution of Group Decision of Group: Accepted-Modified
Reason for Recommendation
delete this requirement from the tables 147, 148, 150 and 151.
We agree that 2% is too difficult to achieve without an equalizer. In fact, we believe the modulation accuracy should not be specified at allfor QAM64 without an equalizer. That is why it was not specified in IEEE 802.16.
The ETSI BRAN HIPERACCESS project has made the same decision for the same reasons.
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
55Starting Line # 12.1.2.1SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Neil Shipp Member
EditorialType
(0.5 to 2)dB and (2 to 5)dBSuggested Remedy
64Starting Page #
Tidy up the bracketsComment
3 2Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Resolution of Group Decision of Group: Accepted-Modified
Reason for Recommendation
change "Step size [0.5, 2) dB" to "0.5 dB <= Step size < 2 dB"change "Step size [2, 5) dB" to "2 dB <= Step size < 5 dB"
The above recomendation makes the requirement for a 2 dB change ambiguous. Unfortunately, the standard mathematical notation forexclusive or inclusive differs from country to country.
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
?Starting Line # 12.1.2.1SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Neil Shipp Member
Technical, Non-bindingType
6%Suggested Remedy
67Starting Page #
Assuming that this specification applies to the output of the transmitter and not simply the modulator then 2% modulation accuracyunequalised implies extremely tight tolerances on transmit filter frequency and group delay response. I estimate that 2% peak error equatesto <0.5dB gain flatness in the passband.
Same comment applies to the unequalised 64 QAM spec in Table 150 and Table 151
Comment
3 3Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Resolution of Group Decision of Group: Accepted-Modified
Reason for Recommendation
delete this requirement from the tables 147, 148, 150 and 151.
We agree that 2% is too difficult to achieve without an equalizer. In fact, we believe the modulation accuracy should not be specified at allfor QAM64 without an equalizer. That is why it was not specified in IEEE 802.16.
The ETSI BRAN HIPERACCESS project has made the same decision for the same reasons.
Reason for Group's Decision/Resolution
Group's Action Items
Group's Notes
Editor's ActionsEditor's Notes
Editor's Questions and Concerns
Editor's Action Items
30Starting Line # 12.1.2.1 Table 148SectionFig/Table#
2002/09/24 IEEE 802.16-02/43r2
Carl Eklund
Technical, Non-bindingType
Add subsectionsection as per comment VII in C802.16c-02/09Suggested Remedy
76Starting Page #
It should be made clear that an Initial Maintenence Interval equals exactly one transmission opportunity for profP1 and profP2.Comment
3 4Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Replace figure 46 by figure submitted in comment XII in C802.16c-02/09.Add two new rows to table 118:SS ,T20, Time the SS searched for preambles on a given channel, 2ms, , ,SS, T21, Time the SS searches for DL-MAP on a given channel, , , 10s
Suggested Remedy
103Starting Page #
The figure for obtaining dowlink synchronization is overly simplistic. As IEEE802.16 and ETSI BRAN HA share the same frame pre-amble itis instructive to conceptually spell out the detection of the DL-MAP after a PHY frame has been detected and introduce timeouts.
Comment
3 5Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Apply edits under Comment I from document C802.16c-02/09
Suggested Remedy
265Starting Page #
Errata : The TLV format used in the config file is different from the format for common encodings. Also the sections defining the format arewritten in a confusing manner. The pad byte and the EOF should not be considered configuration settings!
Comment
3 6Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date
Apply edits under Comment II from document C802.16c-02/09Suggested Remedy
290Starting Page #
It should not be possible to set up arbitrary SNMP MIB Objects in the configuration file as this is an unreasonable implementation burden.Also MIB should be massaged via SNMP not the config file.
Comment
3 9Comment # Comment submitted by:
P802.16c/D3Document under Review: 0000314Ballot Number: Comment Date