8.2 MAC Addresses and MAC Frames
8.2 MAC Addresses and MAC Frames
8.2.1 MAC Addresses and Other Addresses
Each SS has a 48-bit universal MAC address, as defined in the standard [1]. This type of address is often known as the IEEE 802 MAC address. It uniquely defines the SS for all possible vendors and equipment types. It is used during the initial ranging process to establish the appropriate connections for an SS. It is also used as part of the authentication process by which the BS and SS each verify the identity of the other (see Chapter 11 for initial ranging and Chapter 15 for security). This is also the case in Mesh mode where each node has a unique IEEE 802 MAC address.
A 802.16 BS has a 48-bit Base Station ID (BSID). This is different from the MAC address of the BS. It includes a 24-bit operator indicator. The BSID can then be used for operator identification. It is used, for example, in the Downlink Channel Descriptor (DCD) MAC management message.
In the Mesh mode, another address in addition to the MAC address is used. When authorised to access, a candidate SS node receives a 16-bit Node IDentifier (Node ID) upon a request to an SS identified as the Mesh BS. The Node ID is the basis of node identification in the Mesh mode.
8.2.2 MAC Frames
A MAC PDU is known as a MAC frame. It has the general format shown in Figure 8.1. Each MAC frame starts with a fixed-length MAC header. This header may be followed by the payload of the MAC PDU (MPDU). A MPDU may contain a CRC (Cyclic Redundancy Check). If present, the MPDU payload contains one or more of the following:
-
zero or more subheaders included in the payload;
-
zero or more MAC SDUs;
-
fragment(s) of a MAC SDU.
Figure 8.1: General format of a MAC frame or MAC PDU. (From IEEE Std 802.16-2004 [1]. Copyright IEEE 2004, IEEE. All rights reserved.)
The payload information may vary in length. Hence, a MAC frame length is a variable number of bytes. This format allows the MAC to tunnel various higher-layer traffic types without knowledge of the formats or bit patterns of those messages.
8.2.3 MAC Header Format
Two MAC header formats are defined in the standard:
-
The Generic MAC Header (GMH). This is the header of MAC frames containing either MAC management messages or CS data. The CS data may be user data or other higherlayer management data. The generic MAC header frame is the only one used in the downlink.
-
The MAC header without payload where two types are defined: Type I and Type II. For MAC frames with this type of header format, the MAC header is not followed by any MPDU payload and CRC. This frame name has been introduced by the 16e amendment. Previously, in 802.16-2004, the bandwidth request header was defined to request additional bandwidths (see Chapter 10). With 16e, the bandwidth request header becomes a specific case of MAC header formats without payload.
In the uplink, the single-bit Header Type (HT) field, at the beginning of the MAC header (see below), makes the distinction between the generic MAC header and the MAC header without payload formats: zero for the GMH and one for a header without payload.
8.2.3.1 Format of the Generic MAC Header
The Generic MAC frame header format is shown in Figure 8.2 and the fields of this header in Table 8.1. In this table, the LEN (length value) field, which is the length in bytes of the MAC frame (MAC PDU), is 11 bits long. This gives a maximal length of 2048 bytes for the MAC frame. The use of encryption parameters (EKS field) will be described in Chapter 15 where WiMAX security is detailed. For both OFDM and OFDMA PHY layers, management messages must have a CRC, which is a 4-bytes field, computed as defined in IEEE Std 802.3 and appended to the payload of the MAC PDU. The CRC must be calculated after encryption. i.e. the CRC protects the GMH and the ciphered payload [1].
Figure 8.2: Header format of the Generic MAC frame [1]. The number in parentheses is the number of bits in the indicated field
| Name | Length (bits) | Description |
|---|---|---|
| HT | 1 | Header Type. Zero for generic MAC header |
| EC | 1 | Encryption Control: 0 = payload is not encrypted; 1 = payload is encrypted. For a MAC header without payload, this bit indicates whether it is Type I or II |
| Type | 6 | This field indicates the subheaders and special payload types present in the message payload (see below) |
| ESF | 1 | Extended Subheader Field. If ESF = I, the extended subheader is present and follows the generic MAC header immediately (applic(‘able in both the downlink and uplink) |
| CI | 1 | CRC Indicator: 1 = CRC is included (see MAC frame format); 0 = no CRC is included |
| EKS | 1 | Encryption Key Sequence. The index of the Traffic Encryption Key (TEK) and initialization vector used to encrypt the payload. Evidently, this field is only meaningful if the EC field is set to one |
| LEN | 11 | Length. The length in bytes of the MAC PDU including the MAC header and the CRC, if present |
| CID | 16 | Connection IDentifier (see Chapter 7) |
| HCS | 8 | Header Check Sequence. An 8-bit field used to detect errors in the header |
Open table as spreadsheet
8.2.3.2 Generic MAC Header Subheaders (Type Field)
The generic MAC frame payload may start by one or more subheaders (see Figure 8.3). The type field in the generic MAC header is a 6-bit value, where each bit has a specific meaning. as shown in Table 8.2.
Figure 8.3: Generic MAC frame may have one or many subheaders
| Type bit | Value |
|---|---|
| 5 (MSB) | Mesh subheader: I = present, 0 = absent |
| 4 | ARQ feedback payload: 1 = present, 0 = absent |
| 3 | Extended Type. Indicates whether the present packing or fragmentation subheaders is extended: 1 = extended, indicates connections where ARQ is enabled; 0 = not extended. |
| 2 | ragmentation subheader: 1 = present, 0 = absent |
| 1 | Packing subheader: 1 = present, 0 = absent |
| 0 (LSB) | Downlink: FAST-FEEDBACK allocation subheader; uplink: grant management subheader; I = present, 0 = absent |
Fragmentation and packing are two MAC functions described in Section 8.3 where the use of the corresponding type field bit is given. ARQ (Automatic Repeat reQuest) is a handshake procedure of the data link layer where the receiver asks the transmitter to send again a block of data when errors are detected (ARQ is detailed further in this chapter in Section 8.7). If the ARQ feedback payload bit in the generic MAC header type field is set to 1, the ARQ feedback payload is transported. The extended type bit (bit 3) of the generic MAC header field indicates whether the present packing or fragmentation subheaders use ARQ-enabled connections. This bit is set to 1 if packing or fragmentation is applied on connections where ARQ is enabled.
8.2.3.3 Header Format Without Payload
The header without payload (Type I and II), only used in the uplink, has the same size as the generic MAC frame header, but the fields differ. The MAC header format without payload Type I is shown in Figure 8.4 and in Table 8.3. In the MAC header without payload, the header content field (19 bits) may have different uses. Type field encodings for the MAC signalling header Type I are given in Table 8.4 (from the 802.16e amendment). In this table the Bandwidth Request (BR) comprise dedicated bandwidth request frames. The BR field indicates the number of bytes requested; the CID indicates the connection for which the uplink bandwidth is requested. Aggregate and incremental BR types will be seen in Chapter 10. The SN report header is sent by the SS in the framework of the ARQ procedure.
| Type field (3 bits) | MAC header type (with HT/EC=Ob1O) |
|---|---|
| 000 | BR incremental] |
| 001 | BR aggregate |
| 010 | PHY channel report |
| 011 | BR with UL Tx power report |
| 100 | Bandwidth request and CINR report |
| 101 | BR with UL sleep control |
| 110 | SN report |
| 111 | CQICH allocation request |
|
[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). | |
In the MAC header format without payload Type II, the header is changed with regard to Type I. It is used for some feedbacks specific to OFDMA (MIMO, etc).
Figure 8.4: Header format without payload Type I. (Based on Reference [2].)
| Name | Length (bits) | Description |
|---|---|---|
| HT | 1 | Header Type. One for the header without payload |
| EC | 1 | For a MAC header without payload, this bit indicateswhether it is Type I or II |
| Type | 3 | Indicates the type of header without payload (see below) |
| Header content | 19 | Header content, function of the Type field value |
| CID | 16 | Connection IDentifier |
| HCS | 8 | Header Check Sequence (same as for the generic MAC header) |
8.2.3.4 Generic Frames: Transport or Management Frames?
The payload can contain either a management message or transport data. Specific connections are defined as management connections (see Table 7.1). These connections carry only management messages. All other connections carry user data or secondary (upper layer) MAC management data.
8.2.4 MAC Subheaders and Special Payloads
Use of the remaining Type bits of the generic MAC frame (see Table 8.2) are now described: Grant Management subheader, FAST_FEEDBACK_Allocation and Mesh subheader. The use of the corresponding subheaders is detailed.
Bandwidth requirements are not uniquely sent with a header without payload Type I bandwidth request header frames. The Grant Management subheader, which can be present only in the uplink, is used by the SS to transmit bandwidth management needs to the BS in a generic MAC header frame. This is then the so-called ‘piggybacking request’ as the data request takes place on a frame where data are also transmitted. The bandwidth request processes are described in Chapter 10, where details are given of the use of the Grant Management subheader (specifically in Section 10.2.2).
Fast feedback slots are slots individually allocated to SS for transmission of PHY-related information that requires a fast response from the SS. This allocation is done in a unicast manner through the FAST_FEEDBACK MAC subheader and signalled by Generic Header Type field bit 0. The FAST-FEEDBACK allocation is always the last per-PDU subheader. The FAST-FEEDBACK allocation subheader can be used only in the downlink transmission and with the OFDMA PHY specification (often with MIMO).
When authorised to a Mesh network, a candidate SS node receives a 16-bit Node IDentifier (Node ID) upon a request to the Mesh BS (see Section 3.6 for the Mesh BS). Node ID is the basis for identifying nodes during normal Mesh mode operation. The Mesh subheader contains a single information, the Node ID. If the Mesh subheader is indicated, it precedes all other subheaders.
[1]IEEE 802.16-2004, IEEE Standard for Local and Metropolitan Area Networks, Air Interface for Fixed Broadband Wireless Access Systems, October 2004.
EAN: 2147483647
Pages: 124