Here is a list of reported errors. The first 21, as noted, have been approved by the IEEE 802.16 Working Group as an interpretation of the standard. The rest have not been confirmed or approved by IEEE 802.16; the errors are as reported, though editing for clarity may have taken place.
These errata will be submitted for balloting and adoption in amendment 802.16c to IEEE Std 802.16. The PAR for 802.16c offers the opportunity to ballot these corrections, since its scope statement includes "Errors and inconsistencies in IEEE Std 802.16-2001 will also be corrected."
To submit additional errata reports, please follow the instructions in "Call for Contributions: IEEE 802.16 Task Group c on 10-66 GHz System Profiles".
Technical issues with IEEE standards may be addressed through the use of interpretations. These need to be approved by Working Group 802.16.
See also: IEEE P802.16/D5 Errata Reports
|Comment Number||First Name||Last Name||Starting Page Number||Starting Line Number||Subclause||Comment||Remedy||Approved
|1||Roger||Marks||1||1.2.1||The air interface needs a name in order to accommodate new air interface names under development in P802.16a.||Insert a second paragraph: "The single-carrier modulation air interface specified herein for 10-66 GHz shall be known as the "WirelessMAN-SC" air interface.||Yes|
|2||5||3.3||Error in definition of "Basic Connection", per 220.127.116.11.||In definition of "Basic Connection", change "initial subscriber station registration" to: "ranging".||Yes|
|3||Roger||Marks||34||18.104.22.168.2||"CS pass through" is not defined or referred to elsewhere in the text.||Delete "CS pass through," [Line 9]||Yes|
|4||36||6.2.1||Paragraph 1 is inconsistent with 6.2.9.||Paragraph 1, Line 3:
change "registration" to "initial ranging"
|5||36||6.2.1||Inconsistency in Paragraph 3, Line 1; the MAC layer is involved in connection setup.||Paragraph 3, Line 1:
change "higher layers of the BS set up" to "BS initiates the set-up of"
|6||Antonis||Karvelas||44||22.214.171.124||There is an inconsistency about the Connection ID of the MCA-REQ and MCA-RSP messages. In Table 13, the MCA-REQ and MCA-RSP messages use the Basic CID. But on page 98, line 27 and page 99, line 4 the MCA-REQ and MCA-RSP messages use the Primary Management CID.||In Table 13, Lines marked "21" and "22", in the column "Connection":
change "Basic" to "Primary Management"
|7||85||6.2.6||Paragraph 1, Line 1:
change "at registration" to: ", in initial system access, "
|8||Carl||Eklund||95||126.96.36.199||The sentence "The UL-MAP defines the uplink usage in terms of the offset from the previous IE start (the length) in numbers of minislots." incorrectly reflects the actual definition of the offset, which is detailed in 188.8.131.52.2.||Paragraph 1, Line 1:
Change first sentence to "The UL-MAP defines the uplink usage in terms of the offset, in units of minislots, of the burst relative to the Allocation Start Time (184.108.40.206.2)."
|9||Roger||Marks||131||220.127.116.11.1||"Configuration of provisioned Service Flows follows the Registration process. When this is complete, the BS passes service flow encodings to the SS in multiple DSA-REQ messages." suggests that DSA-REQ messages IMMEDIATELY follow Registration. However, this leaves out steps (g), (h), and (i) on page 128.||Paragraph 1, Line 2:
Change "Configuration of provisioned Service Flows follows the Registration process." to: "Configuration of connections enabling Service Flows for provisioned services follows the transfer of the operational parameters, as shown Fig. 45."
|10||132||18.104.22.168.2||Paragraph 1, Line 2:
change "Registration process outlined above" to "procedure outlined in 22.214.171.124.1."
|11||154||126.96.36.199.4||Paragraph 8, Lines 5-7:
Change "If a Service Flow that was provisioned during registration is deactivated, the provisioning information for that Service Flow shall be maintained until the Service Flow is reactivated." to "If a Service Flow for a provisioned service is deactivated, the provisioning information for that service is maintained until the Service Flow is reactivated."
|12||165||188.8.131.52.5||Paragraph 1, Lines 3-6:
Change "reregister. Also, if a Service Flow that was provisioned during registration is deleted, the provisioning information for that Service Flow is lost until the SS reregisters. However, the deletion of a provisioned Service Flow shall not cause an SS to re-register. Therefore, care should be taken before deleting such Service Flows." to: "re-initialize. Also, if a Service Flow for a provisioned service is deleted, the ability to re-establish the Service Flow for that service is network management dependent. Therefore, care should be taken before deleting such Service Flows. However, the deletion of a provisioned Service Flow shall not cause an SS to re-initialize."
|13||Stanley||Wang||185||184.108.40.206||Item [5-E](a) is a copy-and-paste typo. It makes no sense to clear Key Request retry timer in step (a), since it is set to Operational Wait Timeout in (c) anyway. Instead, when TEK Invalid message is sent, "TEK refresh timer" needs to be cleared (just as in Line 23) so that it will not cause unnecesary timeout.||Correct [5-E](a) to read "a) clear TEK refresh timer".||Yes|
|14||Roger||Marks||221||220.127.116.11.1||The phrase "modulation scheme in use" is ambiguous. There may be many modulation schemes in use. Presumably, this refers to the burst following the preamble. If so, then we still have an ambiguity in the case of the Frame Start Preamble, since the burst may contain several modulation schemes.
While this ambiguity should be resolved for the sake of clarity, the resolution has no technical implications. In the constant peak power scheme, what matters is not the "modulation scheme in use" but the power of the "outermost constellation points of the modulation scheme in use". That's the same for all modulation schemes. Likewise, in the constant mean power scheme, all that matters is the "mean power of the constellation points of the modulation scheme in use", and that is the same for all modulation schemes.
|Paragraph 2, Lines 5 and 7:
change both instances of "modulation scheme in use" to "modulation scheme(s) in the burst".
|15||Lars||Lindh||231||18.104.22.168.3||The next to last sentence of 22.214.171.124.3 implies that the randomization is applied only to the first bit of each burst. This is definitely not the case, as is clear from the remainder of the subclause; it would make no sense as a randomization. Clearly, the intent was for the randomization to be applied to each bit, beginning with the first.||Next to last sentence of 126.96.36.199.3:
Change "The seed value shall be used to calculate the randomization bit, which is combined in an XOR with the first bit of data of each burst." to "The seed value shall be used to calculate the randomization bits, which are combined in an XOR operation with the serialized bit stream of each burst."
|16||Carl||Eklund||249||188.8.131.52.2||Description of Null IE requires clarification, parallel to statement regarding downlink (Table 91).||In Table 108, under "Description" column of "Null IE" row, change text to: "Ending offset of the previous grant. Indicates the first minislot after the end of the UL allocation. The burst profile is well known and shall not be included in the UCD message. Used to bound the length of the last actual interval allocation."||Yes|
Delete "Bit#:". Also, change "9-15" to "9-255"
|18||306||184.108.40.206||Paragraph 1, Line 1: change "type" to "pcst"
Table Header, Line 1: change "Type" to "pcst"
Table: delete "[24/25]" from all 5 rows
Add 4 rows to end of table:
104 Packet IPV4 over 802.3
105 Packet IPV6 over 802.3
106 Packet IPV4 over 802.1Q VLAN
107 Packet IPV6 over 802.1Q VLAN
|19||307||220.127.116.11||Change second and third sentences to: "The packet convergence sublayer specific type is denoted in the tables in the following sections by the variable "pcst", which takes its value from the table in 18.104.22.168 (e.g., 100, 101, ) depending upon the exact packet CS used for the service."||Yes|
|20||307||22.214.171.124||In all tables of 126.96.36.199:
change ".100." to ".pcst."
|21||Roger||Marks||321||12.1||ARQ cannot be an option since 6.2.4 disallows ARQ.||Next to last line:
Delete line "ARQ is optional."
|22||6||3.25||Definition of "management connection" is obsolete.||Delete definition of "management connection" (3.25).|
|23||8||3.42||Definitions of "service flow class" and "service flow name" are obsolete.||Delete definitions of "service flow class" (3.42) and "service flow name" (3.44).|
|24||Vladimir||Yanover||74||188.8.131.52.24||There is no need for Confirmation Code in Table 50. All capabilities are encoded as bit masks and the text below (under Bandwidth Allocation Support) confirms that it is considered sufficient for the handshake between SS and BS: "The BS response to the subset of SS capabilities present in the SBC-REQ message". The BS responds to the SS capabilities to indicate whether they may be used. If the BS does not recognize an SS capability, it shall return this as "off" in the SBC-RSP. Only capabilities set to "on" in the SBC-REQ may be set "on" in the REG-RSP as this is the handshake indicating that they have been successfully negotiated.||Remove Confirmation Code from Table 50.|
|25||Carl||Eklund||296||11.4.3||There are several errors in the paragraph at the top of Page 296. The REG-REQ/RSP explains the parameter usage in the messages; it is used as a subfield of the messages including "Vendor-specific QoS parameters" (184.108.40.206).||(a) Replace the first paragraph on Page 296 with:
"When used as a subfield of the TLVs Vendor-specific information,Vendor-specific QoS parameters,Vendor specific classifier parameters, or Vendor-specific PHS parameters, the Vendor ID encoding identifies the Vendor ID of the SSs which are intended to use this information."
(b) In the table, change the scope to:
"REG-REQ (see 220.127.116.11.7), DSx-REQ, DSX-RSP, DSx-ACK, and Configuration File"
|26||Roger||Marks||115||6.2.10||Note 2 is confusing because of bad grammar.||Add the word "If" to the start of the note.|
|27||Roger||Marks||115||18.104.22.168||There is a typo in "the BS shall send DSA-REQ messages to the BS".||Change "to the BS" to "to the SS".|
|28||Claude||Albo||116||6.2.10||In Figure 55, "Remote SS" must be a typographical error. If the RNG-RSP responds with success, the BS should remove the SS from the polling list.||Change "Remote SS" to "Remove SS".|
|29||Claude||Albo||147||22.214.171.124.3.2||"DSC-Remote Begin" is the wrong name for the top state symbol because Figure 76 deals with DSA - Local DSA-RSP Pending and should continue Figure 75.||Change name of top state symbol from "DSC-Remote Begin" to "DSA - Local DSA-RSP Pending".|
|30||Claude||Albo||147||126.96.36.199.3.2||"DSC-Local Holding Down" is the wrong name for the bottom state symbol because Figure 76 deals with DSA."||Change name of bottom state symbol from "DSC-Local Holding Down" to "DSA - Local Holding Down"|
|31||Claude||Albo||158||188.8.131.52.4.3||"DSC-Remote Begin" is the wrong name for the top state symbol because Figure 85 deals with DSC - Local DSC-RSP Pending and should continue Figure 84.||Change name of top state symbol from "DSC-Remote Begin" to "DSC - Local DSC-RSP Pending"|
|32||Claude||Albo||151||184.108.40.206.3.2||Poor alignment of vertical line/arrow in Figure 80.||Move arrow to the right for better alignment.|
|33||Claude||Albo||251||220.127.116.11||Typo in third paragraph of subclause: "is in the in the middle"||Change to "is in the middle".|
|34||Claude||Albo||169||18.104.22.168.5.3||The "DSD - Remotely Initiated Transaction Holding State Flow Diagram" is missing from the document.||Insert new figure: "DSD - Remotely Initiated Transaction Holding Down State Flow Diagram" (see C802.16c-02/01).|
|35||Claude||Albo||211||22.214.171.124.2||RXSTATUS missing in the relevant "Semantics of the service primitive" under general subclause 8.1.3. Currently it is not clear in all the PHY SAP management definition subclause how the RXSTATUS reaches the MAC layer. Therefore intuitively the full information held in the PHY is actual at the moment the RX ends.||Insert new line between the opening and closing parenthesis with the content "RXSTATUS". Effectively, MAC layer will then receive as returned status all Rx status information as defined in Table 83 ("RXSTATUS for 10-66 GHz PHY").|
|36||Roger||Marks||101||6.2.9||Lettered list beginning after "phases:" is improperly formatted.||After "phases:", "Scan for downlink channel and establish synchronization with the BS" should be item (a). Following items [(c)-(k)] should be re-lettered as (b)-(j).|
|37||Vladimir||Yanover||27||126.96.36.199.2||There is a problem in the definition of MAC_CREATE_CONNECTION.request primitive. When the BS CS is requesting the MAC to establish a connection, it should specify the destination of the connection/service flow. As the CS is unaware of CIDs, the only identification available is the 48-bit universal MAC address of the SS. So this parameter should be added to the MAC_CREATE_CONNECTION.request primitive.||
In the parameter list for the MAC_CREATE_CONNECTION.request primitive, add the line:
as the first line (before the line "scheduling service type,")
In the Registration Response (REG-RSP) message, we find:
:The following parameters shall be included in the Registration Response:
However, there is no definition of the TLV fomat for the encoding of the Secondary Management CID.
|Insert new subclause 11.1.6 ("REG-RSP message encodings") as specified in C802.16c-02/06).|
|39||Roger||Marks||217||188.8.131.52||Table 84 provides for frame durations of 0.5, 1, and 2 ms. However, Table 212 (p. 255), which seems to be normative on the whole, indicates a Frame Duration of 1 ms. Users of the standard may be confused as to whether the 0.5 and 2 ms frame durations are permitted.||Delete the 0.5 and 2 ms frame durations from Table 84.|