IEEE Std 802.16-2001: Errata Reports

IEEE Std 802.16 was published on 8 April 2002.

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.

IEEE Std 802.16-2001: Errata Reports

Comment Number First Name Last Name Starting Page Number Starting Line Number Subclause Comment Remedy Approved
Interpretation

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 6.2.9.5. In definition of "Basic Connection", change "initial subscriber station registration" to: "ranging". Yes

3 Roger Marks 34
6.1.1.11.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" Yes

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" Yes

6 Antonis Karvelas 44
6.2.2.3 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" Yes

7

85
6.2.6
Paragraph 1, Line 1:
change "at registration" to: ", in initial system access, " Yes

8 Carl Eklund 95
6.2.7.5 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 8.2.6.1.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 (8.2.6.1.2)." Yes

9 Roger Marks 131
6.2.13.7.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." Yes

10

132
6.2.13.7.2
Paragraph 1, Line 2:
change "Registration process outlined above" to "procedure outlined in 6.2.13.7.1." Yes

11

154
6.2.13.8.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." Yes

12

165
6.2.13.8.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." Yes

13 Stanley Wang 185
7.2.5.5 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
8.2.5.1.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". Yes

15 Lars Lindh 231
8.2.5.4.3 The next to last sentence of 8.2.5.4.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 8.2.5.4.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." Yes

16 Carl Eklund 249
8.2.6.1.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

17

296
11.4.5.1

Delete "Bit#:". Also, change "9-15" to "9-255" Yes

18

306
11.4.9.2
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 Yes

19

307
11.4.9.3
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 11.4.9.2 (e.g., 100, 101, …) depending upon the exact packet CS used for the service." Yes

20

307
11.4.9.3
In all tables of 11.4.9.3:
change ".100." to ".pcst." Yes

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." Yes

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
6.2.2.3.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" (11.4.8.10). (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 6.2.2.3.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
6.2.9.13 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
6.2.13.8.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
6.2.13.8.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
6.2.13.8.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
6.2.13.8.3.2 Poor alignment of vertical line/arrow in Figure 80. Move arrow to the right for better alignment.

33 Claude Albo 251
7.2.5.1 Typo in third paragraph of subclause: "is in the in the middle" Change to "is in the middle".

34 Claude Albo 169
6.2.13.8.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
8.1.3.27.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
6.1.1.1.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:
MAC Address,
as the first line (before the line "scheduling service type,")

38 Vladimir Yanover 53
6.2.2.3.8 In the Registration Response (REG-RSP) message, we find:
:The following parameters shall be included in the Registration Response:
...
Secondary Management CID
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
8.2.3.1 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.

Comment Number	First Name	Last Name	Starting Page Number	Subclause	Comment	Remedy	Approved Interpretation
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 6.2.9.5.	In definition of "Basic Connection", change "initial subscriber station registration" to: "ranging".	Yes
3	Roger	Marks	34	6.1.1.11.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"	Yes
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"	Yes
6	Antonis	Karvelas	44	6.2.2.3	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"	Yes
7			85	6.2.6		Paragraph 1, Line 1: change "at registration" to: ", in initial system access, "	Yes
8	Carl	Eklund	95	6.2.7.5	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 8.2.6.1.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 (8.2.6.1.2)."	Yes
9	Roger	Marks	131	6.2.13.7.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."	Yes
10			132	6.2.13.7.2		Paragraph 1, Line 2: change "Registration process outlined above" to "procedure outlined in 6.2.13.7.1."	Yes
11			154	6.2.13.8.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."	Yes
12			165	6.2.13.8.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."	Yes
13	Stanley	Wang	185	7.2.5.5	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	8.2.5.1.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".	Yes
15	Lars	Lindh	231	8.2.5.4.3	The next to last sentence of 8.2.5.4.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 8.2.5.4.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."	Yes
16	Carl	Eklund	249	8.2.6.1.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
17			296	11.4.5.1		Delete "Bit#:". Also, change "9-15" to "9-255"	Yes
18			306	11.4.9.2		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	Yes
19			307	11.4.9.3		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 11.4.9.2 (e.g., 100, 101, …) depending upon the exact packet CS used for the service."	Yes
20			307	11.4.9.3		In all tables of 11.4.9.3: change ".100." to ".pcst."	Yes
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."	Yes
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	6.2.2.3.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" (11.4.8.10).	(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 6.2.2.3.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	6.2.9.13	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	6.2.13.8.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	6.2.13.8.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	6.2.13.8.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	6.2.13.8.3.2	Poor alignment of vertical line/arrow in Figure 80.	Move arrow to the right for better alignment.
33	Claude	Albo	251	7.2.5.1	Typo in third paragraph of subclause: "is in the in the middle"	Change to "is in the middle".
34	Claude	Albo	169	6.2.13.8.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	8.1.3.27.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	6.1.1.1.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: MAC Address, as the first line (before the line "scheduling service type,")
38	Vladimir	Yanover	53	6.2.2.3.8	In the Registration Response (REG-RSP) message, we find: :The following parameters shall be included in the Registration Response: ... Secondary Management CID 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	8.2.3.1	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.

Return to 802.16 TG1 Page