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

#include "include/jwimaxsa.h"

Detailed Description

WiMax Protocol Security Association (WiMax SA)

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 and Formatting 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.

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 (AGMH) 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 Packets

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 for MAC Signaling Header in WiMax Packets

For API Documentation:

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

For Additional Documentation:

See also
jprotocol
jsecass
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: