Protocol++® (Protocolpp®)  v5.6.2
jwimax Class Reference

#include "include/jwimax.h"

Detailed Description

WiMax Protocol (WiMax)

See IEEE802.16e-2005 and IEEE802.16-2004 for the following

WiMAX MAC PDUS (See Joint Source-Channel Decoding Appendix Z)

As seen in Section Z.2, in DL subframes, several MAC PDUs are aggregated in bursts. Section 8.3, page 232, presents techniques for performing a reliable burst segmentation in the presence of noise. The content of each MAC PDU is introduced below.

Each MAC PDU begins with a fixed-size header, followed by a variable length payload and an optional CRC.There are two types of MAC PDU headers

  • The generic MAC header (GMH) is the header of MAC frames containing either MAC management messages or CS data.The CS data may be user data or other higher layer management data. The generic MAC header frame is the only one used in downlink
  • The bandwidth request header (BRH) is not followed by any MAC PDU payload or CRC. This frame name has been introduced by the 802.16e amendment. Previously, in 802.16-2004, the BRH was defined to request additional bandwidths. The content of these headers is presented in what follows.

Generic MAC Header (IEEE802.16-2004)

As we are considering only the downlink case, where the connection is already established and MAC PDUs inside the BS contain only CS data, so only the

Generic MAC Header (GMH) for WiMax Packets

GMH is possible inside BB. Format of GMH as specified in IEEE 802.16-2004 (IEEE, 2004) is illustrated in Figure Z.2. The various fields of a GMH are as follows

  • The Header Type (HT) consists of a single bit set to 0 for GMH
  • The Encryption Control(EC) field specifies whether the payload is encrypted or not and is set to 0 when the payload is not encrypted and to 1 when it is encrypted
  • The Type field indicates the subheaders and special payload types present in the message payload (five possible subheader types)
  • The Reserved (Rsv) field is of one bit and is set to 0
  • The CRC Indicator (CI) field is a single bit set to 1 if a CRC is included and is set to 0 if no CRC is included
  • The Encryption Key Sequence (EKS) field is two bits. It is the index of the Traffic Encryption Key (TEK) and initialization vector used to encrypt the payload. Obviously, this field is only meaningful if the EC field is set to 1
  • The Reserved (Rsv) field is of one bit and is set to 0
  • The Length (LEN) field is 11 bits long. It specifies the length in bytes of the MAC PDU including the MAC header and the CRC, if present
  • The Connection IDentifier (CID) field is 16 bits long and represents the connection identifier of the user
  • The Header Check Sequence (HCS) field is 8 bits long and is used to detect errors in the header.

Generic MAC Header (IEEE802.16e-2005 with ESF bit)

As we are considering only the downlink case, where the connection is already established and MAC PDUs inside the BS contain only CS data, so only the

ESF Bit Usage in WiMax Packets

GMH is possible inside BB. Format of GMH as specified in IEEE 802.16-2004 (IEEE, 2004) is illustrated in Figure Z.2. The various fields of a GMH are as follows

  • The Header Type (HT) consists of a single bit set to 0 for GMH
  • The Encryption Control(EC) field specifies whether the payload is encrypted or not and is set to 0 when the payload is not encrypted and to 1 when it is encrypted
  • The Type field indicates the subheaders and special payload types present in the message payload (five possible subheader types)
  • The Extended Subheader Field(ESF) field consists of a single bit set to 1 if the extended subheader is present and follows the GMH immediately (applicable in both the downlink and uplink)
  • The CRC Indicator (CI) field is a single bit set to 1 if a CRC is included and is set to 0 if no CRC is included
  • The Encryption Key Sequence (EKS) field is two bits. It is the index of the Traffic Encryption Key (TEK) and initialization vector used to encrypt the payload. Obviously, this field is only meaningful if the EC field is set to 1
  • The Reserved (Rsv) field is one bit and is set to 0
  • The Length (LEN) field is 11 bits long. It specifies the length in bytes of the MAC PDU including the MAC header and the CRC, if present
  • The Connection IDentifier (CID) field is 16 bits long and represents the connection identifier of the user
  • The Header Check Sequence (HCS) field is 8 bits long and is used to detect errors in the header.

Bandwidth Request Header

Bandwidth request headers, shown in Figure Z.3, have the same size as generic MAC frame headers, but their content differs. A bandwidth request PDU consists only of a header and does not contain any payload. The fields of the header are provided below.

Header format for Bandwidth Request Packets in WiMax
  • The HT field is a single bit set to 1 for BRHs.
  • The EC is a single bit set to 0, indicating no encryption
  • The type field is 3 bits long and indicates the type of BRH. It can take two values, namely 000 for incremental and 001 for aggregate bandwidth request
  • The bandwidth request(BR) field is 19 bits long and indicates the number of bytes requested
  • The CID field is 16 bits long and represents the CID of the connection for which uplink bandwidth is requested
  • The HCS field is 8 bits long and is used to detect errors in the header.

Flow identifier (FID)

See IEEE802.16.1-2012 for the following

Each AMS connection is assigned a 4-bit FID that uniquely identifies the connection within the AMS. FIDs identify control connection and unicast transport connections. The FID for E-MBS connection is used along with a 12-bit E-MBS ID to uniquely identify a specific E-MBS flow in the domain of an E-MBS zone (see 6.9.3.2). The FID for multicast connection is used along with a 12-bit Multicast Group ID to uniquely identify a specific multicast flow in the domain of an ABS. DL and UL Transport FIDs are allocated from the transport FID space as defined in Table 6-1. An FID that has been assigned to one DL transport connection shall not be assigned to another DL transport connection belonging to the same AMS. An FID that has been assigned to one UL transport connection shall not be assigned to another UL transport connection belonging to the same AMS. An FID that has been used for a DL transport connection can be assigned to another UL transport connection belonging to the same AMS, or vice versa. Some specific FIDs are preassigned. The values of 0000 and 0001 are used to indicate control FIDs. The values of 0010 and 0011 are used to indicate the FID for the signaling header and the FID for the default service flow, respectively. See Table 6-1 for the specific allocation of FIDs. An FID in combination with an STID uniquely identifies any connection in an ABS

Flow Identifier (FID) for WiMax Packets

MAC header formats

There are three defined MAC header formats: the advanced generic MAC header, the Short-Packet MAC header, and the MAC signaling header. At any connection, only one of the following formats shall be used: advanced generic MAC header, short-packet MAC header, and MAC signaling header

Advanced generic MAC header (AGMH)

The AGMH format is defined in Table 6-2. For E-MBS services, the FID shall be ignored by the receiver. For multicast service, the multicast-specific FID associated with Multicast Group ID shall be used in the FID field of AGMH

Advanced Generic MAC Header for WiMax Packets

Short-packet MAC header (SPMH)

The SPMH is defined to support applications, such as Voice over IP (VoIP), that utilize small data packets and non-ARQ connections. The extended header group may be piggybacked on the SPMH, if allowed by its length field. The SPMH is identified by the specific FID that is provisioned statically, or created dynamically via AAI-DSA-REQ/RSP

Formatting for Short-Packet MAC Header (SPMH) in WiMax

MAC signaling header

The signaling header shall be sent standalone or concatenated with other MAC PDUs in either DL or UL. One FID is reserved for the MAC signaling header. The value of FID for the MAC signaling header is 0010

All MAC signaling header formats follow the layout defined in Table 6-4.

Formatting of MAC Signaling Header in WiMax

Cryptographic methods (See IEEE802.16.1-2012)

Payload encryption methods

AES-CCM [refer to NIST Special Publication 800-38C and FIPS 197 Advanced Encryption Standard (AES)] shall be used as an encryption method when PDUs on the unicast control connection are encrypted. Unicast transport connections may be encrypted with AES-CTR (refer to NIST Special Publication 80038A) or AES-CCM.

AES-CCM PDU payload format

The MAC PDU payload shall be prepended with a 2-bit EKS and a 22-bit PN (Packet Number). The EKS and PN shall not be encrypted. The plaintext PDU shall be encrypted and authenticated using the active TEK, according to the CCM specification. This includes appending an integrity check value (ICV) to the end of the payload and encrypting both the plaintext payload and the appended ICV where the size of ICV is decided by either 4 bytes or 8 bytes during the key agreement procedure in network entry. The processing yields a payload that is 7 bytes or 11 bytes longer than the plaintext payload.

Packet number (PN)

The PN associated with an SA shall be set to 0x000001 for DL and 0x200001 for UL when the SA is established and when a new TEK is installed. After each PDU transmission, the PN shall be incremented by 1. Any pair value of {PN, TEK} shall not be used more than once for the purposes of transmitting data. The AMS shall ensure that a new TEK is derived on both sides before the PN paired with either TEK for downlink or TEK for uplink reaches maximum value 0x1FFFFF or 0x3FFFFF, respectively. If the PN reaches maximum value without new TEKs being installed, transport communications on that SA shall be halted until new TEKs are installed.

CCM algorithm

NIST Special Publication 800-38C defines a number of algorithm parameters. Those parameters shall be fixed to specific values as follows:

  • The payload, P, shall be the connection payload, i.e., the PDU excluding the MAC header and any extended headers as well as the EKS, PN, and the Integrity Check Value (ICV) fields (refer to Figure 6-11)
  • The message authentication code, T, is referred herein as the ICV. The length of T in bytes, t, is either 4 or 8
  • The cipher block key, K, is the current TEK as defined herein
  • The associated data, A, is the empty string. The length of the associated data, a, is zero.

The nonce, N, shall be as shown in Table 6-112. The MAC header, which fills bytes 1 and 2, may be the AGMH or the SPMH. If the STID or the FID has not been assigned, then the corresponding field shall be set to all zeroes. When payloads with different FIDs are multiplexed into the MAC PDU, the FID field of the nonce shall be set to the FID of the first payload connection.

Format of NONCE in WiMax Security Packets

The block cipher algorithm, CIPHK, is AES as specified in FIPS 197 Advanced Encryption Standard (AES).

The formatting function and the counter generation function are specified in NIST Special Publication 800-38C, Appendix A. In adopting Appendix A, the Length field Q shall be 2 bytes long; i.e., the octet length of the Length field, q, is 2. It follows that the Flags byte in the initial block, B0, has value 0x09 if a 4-byte ICV is used, or 0x19 if an 8-byte ICV is used. The initial block B0 is shown in Figure 6-21.

Format of BZERO Field for WiMax Security Packets

The j-th counter block, Ctrj, is shown in Figure 6-22. Note that the Flags byte in the counter blocks, which is different from the Flags byte in the initial block B0, has constant value 0x01.

Format of CNTR0 Field for WiMax Security Packets

Receive Processing rules

On receipt of a PDU, the receiving AMS or ABS shall decrypt and authenticate the PDU consistent with the NIST CCM specification configured as specified previously. Packets that are found to be not authentic shall be discarded. Receiving ABSs or AMSs shall maintain a record of the highest value PN received for each SA.

The receiver shall maintain a PN window whose size is specified by the PN_WINDOW_SIZE parameter for SAs. Any received PDU with a PN lower than the beginning of the PN window shall be discarded as a replay attempt. The receiver shall track PNs within the PN window. Any PN that is received more than once shall be discarded as a replay attempt. Upon reception of a PN, which is greater than the end of the PN window, the PN window shall be advanced to cover this PN.

TEK update should be completed before MAC PDUs with ICV error are detected over the MaxInvalid times for the same TEK. If AMS recognizes that TEKDLE update is required due to ICV errors, it initiates TEK update by sending a PKMv3 TEK-Invalid message to the ABS. On receiving the PKMv3 TEK-Invalid message, the ABS discards current TEKDLE and uses TEKULE as TEKDLE, and derives a new TEK for TEKULE.

If ABS recognizes that TEKULE update is required due to ICV errors, it discards current TEKDLE and uses TEKULE as TEKDLE, and derives a new TEK for TEKULE. After recognizing ABS’s TEK update, AMS performs the TEK update procedure. To expedite the TEK update procedure, the ABS may transmit the PKMv3 TEK-invalid message.

When the ABS detects that EKS is not synchronized yet, the ABS transmits the PKMv3 TEK-Invalid message in order for the AMS to send the PKMv3 TEK-Request message to the ABS. On receiving the PKMv3 TEK-Request message, the ABS responds with a PKMv3 TEK-reply message notifying the current TEKs.

AES-CTR

The MAC PDU payload shall be prepended with a 2-bit EKS and a 22-bit PN. The EKS and PN shall not be encrypted. Construction of the counter blocks is the same as that for counter blocks of AES-CCM (i.e., the counter blocks CTRj and NONCE are formatted as shown in Figure6-22 and Figure6-21, respectively).

Calculation of cipher-based message authentication code (CMAC)

An ABS or AMS may support MAC control message integrity protection based on CMAC, together with the AES block cipher. The CMAC construction as specified in NIST Special Publication 800-38B shall be used.

The calculation of the keyed hash value contained in the CMAC Digest attribute and the CMAC Tuple shall use the CMAC algorithm with AES. The DL authentication key CMAC_KEY_D shall be used for authenticating messages in the DL direction. The UL authentication key CMAC_KEY_U shall be used for authenticating messages in the UL direction. UL and DL message authentication keys are derived from the CMAC-TEK prekey (see 6.2.5.2.1.1.3 for details).

The CMAC Packet Number Counter, CMAC_PN_*, is a 3-byte sequential counter that is incremented for each MAC Control Message that contains a CMAC Tuple or CMAC Digest in the context of UL messages by the AMS, and in the context of DL messages by the ABS.

If STID or TSTID is not assigned yet, then the STID field shall be stuffed with zeroes. The CMAC_PN_* is part of the AK context and shall be unique for each MAC control message with the CMAC tuple or digest. Any tuple value of {CMAC_PN_*, CMAC_KEY_*} shall not be used more than once. The reauthorization process should be initiated (by the ABS or the AMS) to establish a new PMK/AK before the CMAC_PN_* reaches the end of its number space.

The CMAC value shall be calculated over a field consisting of the AK ID followed by the CMAC_PN_*, expressed as an unsigned 24-bit number, followed by the 12-bit STID and 4-bit FID on which the message is sent, followed by 24-bit zero padding (for the header to be aligned with AES block size) and followed by the entire ASN.1 encoded MAC control message.

The LSB 64-bit of the outcome of AES-CMAC calculation shall be used for CMAC value.

NOTE—This is different from the recommendation in NIST Special Publication 800-38B where the MSB is used to derive the CMAC value.10

In other words, if CMAC_KEY_* is derived from CMAC-TEK prekey:

CMAC value ≤ Truncate(CMAC (CMAC_KEY_*, AK ID | CMAC_PN |STID|FID|24-bit zero padding | ASN.1 encoded MAC_Control_Message), 64), where STID ‘000000000000’ should be used if STID is not assigned yet.

Only the MAC control message of CMAC_PN that arrives in order at the receiver side can be accepted. MAC control messages with out-of-order CMAC_PN shall be discarded

For API Documentation:

See also
ProtocolPP::jprotocol
ProtocolPP::jmodes
ProtocolPP::jwimaxsa
ProtocolPP::jwimax

For Additional Documentation:

See also
jprotocol
jmodes
jwimaxsa
jwimax
Protocol++® (ProtocolPP®) written by : John Peter Greninger • © John Peter Greninger 2015-2024 • All Rights Reserved
All copyrights and trademarks are the property of their respective owners

The source code contained or described herein and all documents related to the source code (herein called "Material") are owned by John Peter Greninger and Sheila Rocha Greninger. Title to the Material remains with John Peter Greninger and Sheila Rocha Greninger. The Material contains trade secrets and proprietary and confidential information of John Peter Greninger and Sheila Rocha Greninger. The Material is protected by worldwide copyright and trade secret laws and treaty provisions. No part of the Material may be used, copied, reproduced, modified, published, uploaded, posted, transmitted, distributed, or disclosed in any way without prior express written consent of John Peter Greninger and Sheila Rocha Greninger (both are required)

No license under any patent, copyright, trade secret, or other intellectual property right is granted to or conferred upon you by disclosure or delivery of the Materials, either expressly, by implication, inducement, estoppel, or otherwise. Any license under such intellectual property rights must be express and approved by John Peter Greninger and Sheila Rocha Greninger in writing

Licensing information can be found at www.protocolpp.com/license with use of the binary forms permitted provided that the following conditions are met:

  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution
  • Any and all modifications must be returned to John Peter Greninger at GitHub.com https://github.com/jpgreninger/protocolpp for evaluation. Inclusion of modifications in the source code shall be determined solely by John Peter Greninger. Failure to provide modifications shall render this license NULL and VOID and revoke any rights to use of Protocol++®
  • Commercial use (incidental or not) requires a fee-based license obtainable at www.protocolpp.com/shop
  • Academic or research use requires prior written and notarized permission from John Peter and Sheila Rocha Greninger

Use of the source code requires purchase of the source code. Source code can be purchased at www.protocolpp.com/shop

  • US Copyrights at https://www.copyright.gov/
    • TXu002059872 (Version 1.0.0)
    • TXu002066632 (Version 1.2.7)
    • TXu002082674 (Version 1.4.0)
    • TXu002097880 (Version 2.0.0)
    • TXu002169236 (Version 3.0.1)
    • TXu002182417 (Version 4.0.0)
    • TXu002219402 (Version 5.0.0)
    • TXu002272076 (Version 5.2.1)
    • TXu002383571 (Version 5.4.3)

The name of its contributor may not be used to endorse or promote products derived from this software without specific prior written permission and licensing

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

The documentation for this class was generated from the following file: