RE: stds-802-16-tg1: Re: [wirelessman

1. Page 19, Line 35: You must add the downstream in the definition of the burst profile. Add the word downstream in the sentence "Set of parameters that describe the upstream transmissionŠ" .

2. Page 43, Line 15-17: There is nowhere definition of the DCC-REQ and DCC-RSP MAC Management messages.

3. Page 59, Line 8: This setting doesn't exist in the Configuration File based on the 9.2.2 section. I believe that you must delete this and also the 11.4.4 section.

4. Page 110, Line 61: There is an inconsistency between sections 6.2.3.2 and 6.2.3.4.
In section 6.2.3.2 the standard notes that "The SS achieves MAC synchronization once it has received at least one DL-MAP message. A SS MAC remains in synchronization as long as it continues to successfully receive the DL-MAP and DCD messages for its Channel".
In section 6.2.3.4 the standard notes that "The SS MAC remains in synchronization as long as it continues to successfully receive the DL-MAP, UL-MAP, DCD and UCD messages."
I believe that may be two types of synchronization.
(a) Upstream synchronization: The SS must receive periodically UCD and UL-MAP messages to retain synchronization, otherwise search for other upstream channel. The loss of this synchronization doesn't mean that the SS lose downstream synchronization.
(b) Downstream synchronization: The SS must receive periodically DCD and DL-MAP messages to retain synchronization, otherwise search for other downstream channel and of course lose not only downstream but also upstream synchronization.

5. Page 111, Line 8: I believe that the Figure 60 must include the DCD messages from the BS.

6. Page 114, Line 47: What is the meaning of the DSC-Remote and DSC-ACK here ? I believe that the text in the box must be replaced with "Increase local power" as in a previous version of the standard.

7. Page 117, Line 6: I believe that the standard must clarify which MAC management messages will be used for the implementation of the DHCP mechanisms.

8. Page 217, Line 52: The standard must clarify with details where in the downstream frame the SS is responsible to hear. It notes that: "Each SS continuously receives the entire downstream burst, decodes the data in the DS burst, and looks for MAC headers indicating data for that SS.", but the "burst" is a downstream region with specific PHY characteristics. I believe that a SS is responsible to hear the Frame Control Header and the DIUC for which is assigned to, and not to the other DIUC regions.

9. Page 219, Line 36: I believe that the sentence: "Then, p= kn + j where j is the number of integral FEC blocks that fit in the burst and is the number of PS remaining after integral FEC blocks are allocated." must be replaced with the following: "Then, p= kn + j where k is the number of integral FEC blocks that fit in the burst and j is the number of PS remaining after integral FEC blocks are allocated."

10. Page 219, Line 46: I believe that the "symbols" must be replaced with "PSs".
11. Page 219, Line 54: I believe that the "symbols" must be replaced with "PSs".

12. Page 219: I believe that in the region 8.2.1.2.7 the standard must remarks that the supporting of the Shortened FEC Block for the downlink bursts is optional as referred to the section 11.1.2.2 .

13. Page 222, Line 28: I believe that in the title of region 8.2.1.5.2 the "Upstream" must be replaced with "Downstream".

14. Page 235, Line 16: I believe that the only case to use the stuff_byte pattern is when the MAC sends the last codeword and the Last Codeword Length for this burst is fixed. Is there any case to have gaps between MAC PDUs of the same burst? Based on the Downstream Frame format there is the need to implement a buffer mechanism with 12 banks where each memory bank corresponds to one DIUC region and stores MAC PDUs for that DIUC region. There is not a reason to have gaps between the MAC PDUs of the same memory bank.

15. Page 236, Line 42: The standard must clarify when the scrambler is cleared. At the beginning of each Downstream Frame or at the beginning of each TDM burst (that is at the beginning of each modulation/FEC different region - DIUC)?

16. Page 236, Line 48: I believe that the sentence: "The sequence generator pauses while parity bites are being transmitted." must be replaced with: "The sequence generator pauses while parity bytes are being transmitted from the Reed Solomon Encoder." in order to demystify the text and to show that when the Reed Solomon transmits the check bytes the scrambler must be in a hold (not running) state.

17. Page 237, Line 48: There is an inconsistency with Table 49 where the Error correction capability is defined as R=0-32 (T=0-16).

18. Page 238, Line 1: I believe that the standard must clarify the reasons for the codeword size (K+R) to be an even number.

19. Page 238, Line 1: There is an inconsistency with Table 60 where the Error correction capability is defined as R=0-32 (T=0-16).

20. Page 279, Line 51: The text must show that the "Network Access Configuration Setting" is the same with the Network Access Control Object of the 11.4.3 Encoding.

21. Page 312: Where are these parameters come from? If the SS Capabilities Encoding stored in the SS (in a non-volatile storage) during the manufacturing phase, the standard must declare this.

22. Page 317, Line 1: I can't find this configuration setting in the REG-RSP message in the region 6.2.1.2.8 .

RE: stds-802-16-tg1: Re: [wirelessman_tg1] Comment resolution