In this annex, a short description is provided of the main 802.16 MAC management messages. The order of presentation is globally in the order of appearance in the book. In this annex, the broadcast, initial ranging and basic and primary management messages are presented, i.e. all the MAC management messages. It should be remembered that the secondary management messages are upper layer, not MAC, management messages. The MAC management messages cannot be carried on Transport Connections, i.e. with Transport CID values. Full detils of these messages can be found in the standards [1] and [2], specifically in Section 6.3.2.3 of the standard and the related PHYsical layers part (Section 8) and TLV encodings (Section 11). The newly added 802.16e messages related to mobility start with MOB.
Multiple access and burst profile definition Messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
0 | UCD, Uplink Channel Descriptor | Transmitted by the BS at a periodic time interval to provide the burst profiles (physical parameters sets) that can be used by an uplink physical channel during a brust in addition to other uplink channel parameters | Broadcast |
1 | DCD, Downlink Channel Descriptor | Transmitted by the BS at a periodic time interval to provide the burst profiles (physical parameters sets) that can be used by a downlink physical channel during a burst in addition to other downlink channel parameters | Broadcast |
2 | DL-MAP, Downlink MAP | Downlink access definition. In a DL-MAP, for each downlink burst, DL-MAP_IE indicates the start time and the burst profile (channel details including physical attributes) of this burst | Broadcast |
3 | UL-MAP Uplink MAP | Uplink access definition. In a UL-MAP, for each uplink burst, UL-MAP_IE indicates the start time, the duration and the burst profile (channel detailes including physical attributes) of this burst | Broadcast |
Mesh network (configuration, entry and scheduling) messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
39 | MSH-NCFG, Mesh Network Configuration | Provides a basic level of communication between nodes in different nearby networks, whether from the same or different equipment vendors or wireless operators. Among others, the Network Descriptor is an embedded data of the MESH-NCFG message. The Network Descriptor contains many channel parameters (modulation and coding schemes, threshold values, etc.) which makes it similar to UCD and DCD | Broadcast |
40 | MSH-NENT, Mesh Network Entry | Provides the means for a new node to gain synchronisation and initial network entry into a Mesh network | Basic |
41 | MSH-DSCH, Mesh Distributed Schedule | Transmitted in the Mesh mode when using distributed scheduling. In coordinated distributed scheduling, all the notes transmit a MSH-DSCH at a regular interval to inform all the neighbours of the schedule of the transmitting station | Broadcast |
42 | MSH-CSCH, Mesh Centralised Schedule | A MSH-CSCH message is created by a Mesh BS when using centralised scheduling. The BS broadcasts the MSH-CSCH message to all its neighbours and all the nodes with a hop count lower than a given threshold forward the MSH-CSCH message to neighbours that have a higher hop count. This message is used to request or grant bandwidth | Broadcast |
43 | MSH-CSCF, Mesh Centralised Schedule Configuration | A MSH-CSCF message is broadcasted in the Mesh mode when using centralised scheduling. The Mesh BS broadcasts the MSH-CSCF message to all its neighbours. All nodes forward (rebroadcast) the message according to its index number specified in the message | Broadcast |
Management of multicast polling groups messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
21 | MCA-REQ, Multicast Assignment Request | The BS may add (or remove) an SS to a multicast polling group, identified by a multicast CID, by sending an MCA-REQ message with the join (or leave) command. | Primary management |
22 | MCA-RSP, Multicast Assignment Response | Sent by the SS in response to an MCA-REQ. Contains mainly the Confirmation Code, indicating whether the request was successful | Primary management |
ARQ messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
33 | ARQ-Feedback, Standalone ARQ Feedback message | Standalone ARQ Feedback message. The ARQ-Feedback message can be used to signal any combination of different ARQ ACKs (cumulative, selective, selective with cumulative) | Basic |
34 | ARQ-Discard, ARQ Discard message | Sent by the transmitted when it wants to skip a certain number of ARQ blocks in the ARQ Transmission Window | Basic |
35 | ARQ-Reset,ARQ Reset message | Sent by the transmitter or the receiver of an ARQ-enabled transmission in order to reset the parent connection's ARQ transmitter and receiver state machines | Basic |
Ranging messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
4 | RNG-REQ, Ranging Request | Transmitted by the SS at initialisation. It can also be used at other periods to determine the network delay and to request a power and/or downlink burst profile change | Initial ranging or Basic |
5 | RNG-RSP, Ranging Response | Transmitted by the BS in response to a received RNG-REQ. It may also be transmitted asynchronously to send corrections based on measurements that have been made on other received data or MAC messages | Initial ranging or Basic |
23 | DBPC-REQ, Downlink Burst Profile Change Request | Sent by the SS to the BS on the SS Basic CID to request a change in the downlink burst profile used by the BS to transport data to the SS | Basic |
24 | DBPC-RSP, Downlink Burst Profile Change Response | Transmitted by the BS on the SS Basic CID in response to a DBPC-REQ message from the SS. If the (required) DIUC parameter is the same as requested in the DBPC-REQ message, then the request was accepted. Otherwise, the DIUC parameter of DBPC-RSP is the previous DIUC at which the SS was receiving downlink data | Basic |
Dynamic service management (creation, change and deletion) messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
11 | DSA-REQ, Dynamic Service Addition Request | Sent by an SS or BS to create a new service flow. Service flow attributes, including QoS parameters are indicated | Primary Management |
12 | DSA-RSP, Dynamic Service Addition Response | Generated in response to a received DSA-REQ; indicates whether the creation of the service flow was successful or rejected | Primary management |
13 | DSA-ACK, Dynamic Service Addition Acknowledge | Generated in response to a received DSA-RSP | Primary management |
14 | DSC-REQ, Dynamic Service Change Request | Sent by an SS or BS to change dynamically the parameters of an existing service flow | Primary management |
15 | DSC-RSP, Dynamic Service Change Response | Generated in response to a received DSC-REQ | Primary management |
16 | DSC-ACK, Dynamic Service Addition Acknowledge | Generated in response to a received DSC-RSP | Primary management |
17 | DSD-REQ, Dynamic Service Deletion Request | Sent by an SS or BS to delete an existing service flow | Primary management |
18 | DSD-RSP, Dynamic Service Deletion Response | Generated in response to a received DSD-REQ | Primary management |
30 | DSX-RVD, DSx Received Message | Generated by the BS to inform the SS that the BS has correctly received a DSx (DSA or DSC)-REQ message. The DSx-RSP message is transmitted only after the DSx-REQ is authenticated | Primary management |
SS basic capability negotiation messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
26 | SBC-REQ, SS Basic Capability Request | Transmitted by the SS during initialisation to inform the BS of its basic capabilities; mainly Physical Parameters and Bandwidth Allocation supported | Basic |
27 | SBC-RSP, SS Basic Capability Response | Transmitted by the BS in response to an SBC-REQ. Indicates the intersection of the SS and the BS capabilities | Basic |
Registration messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
6 | REG-REQ, Registration Request | Sent by the SS in order to register with the BS. Indicates supported management parameters, CS capabilities, IP mode, etc. | Primary management |
7 | REG-RSP, Registration Response | Sent by the BS in response to a REG-REQ message. Confirms or not authentication. Responds to reg-req capability indications. | Primary management |
29 | DREG-CMD, De/Re-registration Command | Transmitted by the BS to force the SS to change its access state (stop using the current channel, use it again, use it with restrictions, etc.) Unsolicited or in response to an SS DREG-REQ message | Basic |
49 | DREG-REQ, SS De-registration Request message | Sent by the SS to the BS in order to notify the BS of the SS de-registration request from the BS and the network | Basic |
SS reset message | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
25 | RES-CMD, Reset Command | Transmitted by the BS to force the SS to reset itself, reinitialise its MAC and repeat initial system access | Basic |
Configuration file TFTP transmission completee messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
31 | TFTP-CPLT, Config File TFTP Complete message | When the configuration file TFTP download has completed successfully, the SS notifies the BS by transmitting a TFTP-CPLT message | Primary management |
32 | TFTP-RSP, Config File TFTP Complete Response | In response to TFTP-CPLT, the BS (normally) sends a TFTP-RSP message with an ‘OK’ response | Primary management |
Radio resource management messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
36 | REP-REQ, channel measurement Report Request | Sent by the BS to the SS in order to require RSSI (received power level) and CINR channel measurement reports. In license-exempt bands, the REP-REQ message is also used to request the results of the DFS measurements that the BS has previously scheduled | Basic |
37 | REP-RSP, channel measurement Report Response | Contains the measurement report in accordance with the Report Request | Basic |
38 | FPC, Fast Power Control | Broadcast by the BS in order to adjust the power levels of multiple SSs simultaneously. The SSs apply the indicated change within the ‘SS downlink management message FPC processing time’. Implementation of the FPC is optional. Power control is normally realised by periodic ranging | Broadcast |
Security messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
9 | PKM-REQ, Privacy Key Management Request | Transmits a PKM (Privacy Key Management) protocol message from the PKM client, the SS to the PKM server, the BS | Primary management |
10 | PKM-RSP, Pricacy Key Management Response | Transmits a PKM protocol message from the PKM server, the BS to the PKM client, the SS | Primary management |
AAS (Adaptive Antenna System) messages | |||
---|---|---|---|
Type (8 bits) | Message name | Description (related to AAS operations) | Type of connection |
44 | AAS-FBCK-REQ | AAS Feedback Request | Basic |
45 | AAS-FBCK-RSP | AAS Feedback Response | Basic |
46 | AAS-Beam_Select | AAS Beam Select message | Basic |
47 | AAS-BEAM_REQ | AAS Beam Request message | Basic |
48 | AAS-BEAM_RSP | AAS Beam Response message | Basic |
Other | |||
---|---|---|---|
Type (8 bits) | Message name | Description | Type of connection |
28 | CLK-CMP, SS network Clock Comparison | For service flows carrying information that requires the SSs to reconstruct their network clock signals (ee.g. Bell-Labs DS1, also known as T1, 1.536Mb/s circuit transmission system), CLK-CMP messages are periodically broadcast by the BS | Broadcast |
[1]IEEE 802.16-2004, IEEE Standard for Local and Metropolitan Area Networks, Air Interface for Fixed Broadband Wireless Access Systems, October 2004.
[2]IEEE 802.16e, IEEE Standard for Local and Metropolitan Area Networks, Air Interface for Fixed Broadband Wireless Access Systems, Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1, February 2006 (Approved: 7 December 2005).