Phy Sap Api

OFDMA PHY SAP Interface Specification
for 802.16 Broadband Wireless Access

Base Stations
Revision: 2.31
Date: June 15, 2007
OFDMA PHY SAP Interface Specification for 802.16 Broadband Wireless Access Base Stations
Disclaimers
INTEL CORPORATION MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE. INTEL CORPORATION ASSUMES NO RESPONSIBILITY FOR ANY ERRORS THAT
MAY APPEAR IN THIS DOCUMENT. INTEL CORPORATION MAKES NO COMMITMENT TO UPDATE NOR TO
KEEP CURRENT THE INFORMATION CONTAINED IN THIS DOCUMENT.
THIS SPECIFICATION IS COPYRIGHTED BY AND SHALL REMAIN THE PROPERTY OF INTEL CORPORATION.
NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE TO ANY INTELLECTUAL PROPERTY
RIGHTS IS GRANTED HEREIN.
INTEL DISCLAIMS ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PROPRIETARY
RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. INTEL DOES NOT
WARRANT OR REPRESENT THAT SUCH IMPLEMENTATIONS WILL NOT INFRINGE SUCH RIGHTS.
NO PART OF THIS DOCUMENT MAY BE COPIED OR REPRODUCED IN ANY FORM OR BY ANY MEANS
WITHOUT PRIOR WRITTEN CONSENT OF INTEL CORPORATION.
INTEL CORPORATION RETAINS THE RIGHT TO MAKE CHANGES TO THESE SPECIFICATIONS AT ANY TIME,
WITHOUT NOTICE.
Legal Notices
Intel software products are copyrighted by and shall remain the property of Intel Corporation. Use,
duplication or disclosure is subject to restrictions stated in the Software License Agreement from Intel,
or in the case of software delivered to the government, in accordance with the software license
agreement as defined in FAR 52.227-7013.
Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries
in the United States and other countries.
* Other names and brands may be claimed as the property of others.
Revision History
Date Description Rev.
12/17/2004 Initial draft for OFDMA PHY SAP 2.00
11/16/2005 Updates from 16eD12 (Table 3-6 FEC Code Type 2.23
Coding) Improved support for HARQ. Changed packet
length definition in Chapter 7. Added corrected figures
in Chapter 3
12/10/2005 Editorial changes. Added support for HARQ flush 2.24

operation at PHY.
12/15/2005 Expected length (taken from RXVECTOR) is reported 2.25

by PHY even for unreadable (invalid) bursts - section
5.10. Added HARQ ACK Subchannel structure
01/11/2006 Modified Section 4.3 – the Type field now mandatory 2.26
in all message segments; small editorial changes in
Sections 3 and 5.
04/27/2006 Editorial changes – text clarifications 4.3, 5.1, 5.4, 2.27

5.7;RSSI per subcarrier dynamic range extended 5.12,
5.10. Added clarifications to distinguish between AAS
Page 2 of 75 Intel Corporation

and general beamforming. Moved placement of AAS

handle within DL- and UL- burst definition structures
for greater flexibility (modified tables 3-15, 3-17, 3-18
3-25, 3-34 and 3-35). Added support for sounding
(modified tables 3-31 and 3-35, added table 3-39) and
fast feedback channel (modified table 3-37 and section
5-10). Frame number used by PHY reported to MAC
via TXSTART.ind; UL PUSC zone can have
subchannel rotation disabled. Clarified segmentation
rules for TXSTART.req, TXSDU.req, RXSTART.req
and RXSDU.ind. Defined new method for coding
zone/burst/sub-burst numbers in TXSDU.req and
TXSDU.conf. Updated figures 4-2 and 4-3.
05/22/2006 Sub-bursts descriptors include modulation/coding 2.28

(tables 3-18 and 3-40). Modified initial LW offset in
Table 3-42.
09/06/2006 Added Initial Frame Number clarification in Section 2.29

5.3. Extended PHY_TXEND.ind primitive in Section
5.6. Added HARQ data burst Indication type in
Section 5.9. Proposed new MAC addressing
convention for PHY SAP Ethernet encapsulation in
Section 7. Removed unused SNR field from
PHY_RXSDU.ind (Section 5.10) and RXCDMA.ind
(Section 5.12) status data
02/07/2007 Added new Burst Type, ‘Control Command’ to 2.30

Downlink (3.4.3) and Uplink (3.5.3) descriptors.
Changed range and coding of the RSSI.
Extended MIMO-related definitions
03/30/2007 Extended PAPR/Safety Zone Channel Specific Part of 2.31

Uplink Burst Parameter Structure (Table 3-32).
Number of slots fields extended from 8 to 10 bit –
affected Tables 3-14; 3-19, 20, 21 and 22; 3-35; 3-43.
UL sub-bursts allocation scheme is time-first now.
Setting ‘dedicated pilots’ elevated to Generic Part of
Downlink Zone Parameter Structure – affected Tables
3-8, 9, 10, 11 and 12.
Table 3-7 and 3-23 – added PHY SAP version stamp
Intel Corporation Page 3 of 75

Contents
1 Purpose of this Specification ....................................................................................................... 9
1.1 Abbreviations ........................................................................................................................9
2 PHY SAP Introduction................................................................................................................12
2.1 Overview.............................................................................................................................12
2.1.1 Base Station Reference Model .....................................................................................12
2.1.2 MAC-PHY Protocol Overview .......................................................................................13
2.2 Assumptions .......................................................................................................................14
3 Base Station Frame Descriptors.................................................................................................15
3.1 Frame Structure ..................................................................................................................15
3.1.1 Downlink Subframe Structure .......................................................................................16
3.1.1.1 Downlink Zones.....................................................................................................16
3.1.1.2 Downlink Bursts ....................................................................................................16
3.1.1.2.1 FCH ..................................................................................................................16
3.1.1.2.2 Downlink Maps..................................................................................................16
3.1.1.2.3 Normal Data Bursts ...........................................................................................17
3.1.1.2.4 Uplink Map ........................................................................................................17
3.1.1.2.5 PAPR Allocation ................................................................................................17
3.1.1.2.6 Sub-Allocation Data Bursts................................................................................17
3.1.2 Uplink Subframe Structure ...........................................................................................18
3.1.2.1 Uplink Zones .........................................................................................................18
3.1.2.2 Uplink Bursts.........................................................................................................18
3.1.2.2.1 HARQ ACK Channel .........................................................................................18
3.1.2.2.2 Fast Feedback Channel.....................................................................................19
3.1.2.2.3 Ranging Regions...............................................................................................19
3.1.2.2.4 PAPR/Safety Zone ............................................................................................19
3.1.2.2.5 Sounding Zone..................................................................................................20
3.1.2.2.6 Noise Floor Allocation........................................................................................20
3.1.2.2.7 Normal Data Burst .............................................................................................20
3.1.2.2.8 Sub-Allocation Data Burst..................................................................................21
3.1.2.2.9 Mini-Subchannel Burst.......................................................................................21
3.1.2.2.10 HARQ ACK Subchannel ..................................................................................23
3.2 Frame Descriptors Hierarchy...............................................................................................24
3.2.1 Parameter Structure Formats .......................................................................................26
3.3 Common Parameter Definitions...........................................................................................27
3.3.1 FEC Code Type Field Coding.......................................................................................27
3.4 Downlink Descriptors (TXVECTOR) ....................................................................................30
3.4.1 Downlink Subframe Parameter Structure......................................................................30
3.4.2 Zone Parameters Structures.........................................................................................30
3.4.3 Burst Parameter Structures ..........................................................................................33
3.4.3.1 Optional Burst Parameters ....................................................................................35
3.4.4 Sub-Burst Parameter Structures...................................................................................36
3.4.4.1 Optional Sub-Burst Parameters .............................................................................38

3.4.5 Downlink Frame Descriptor Usage Notes .....................................................................39

3.4.5.1 FCH Handling .......................................................................................................39
3.4.5.2 Sub-Allocation Bursts ............................................................................................39
3.4.5.3 AAS Bursts............................................................................................................39
3.4.5.4 HARQ Bursts ........................................................................................................39
3.4.5.5 MBS Bursts...........................................................................................................39
3.5 Uplink Descriptors (RXVECTOR) ........................................................................................39
3.5.1 Uplink Subframe Parameter Structure ..........................................................................39
3.5.2 Zone Parameter Structures ..........................................................................................40
3.5.3 Burst Parameter Structures ..........................................................................................42
3.5.3.1 Optional Burst Parameters ....................................................................................46
3.5.4 Sub-Burst Parameter Structures...................................................................................47
3.5.4.1 Optional Sub-Burst Parameters .............................................................................48
3.5.5 Uplink Frame Descriptor Usage Notes..........................................................................52
3.5.5.1 Sub-Allocation Bursts ............................................................................................52
3.5.5.2 Mini Subchannel Bursts.........................................................................................52
3.5.5.3 AAS Bursts............................................................................................................52
3.5.5.4 HARQ Bursts ........................................................................................................52
3.5.5.5 CDMA Allocation (UIUC=14) .................................................................................52
3.5.5.6 Fast_Ranging_IE Allocations.................................................................................52
4 Protocol Description ...................................................................................................................53
4.1 PHY SAP Primitives ............................................................................................................53
4.2 MAC – PHY Communication ...............................................................................................53
4.2.1 PHY Initialization..........................................................................................................54
4.2.2 General PDU and SDU handling between MAC and PHY Layers .................................54
4.2.3 Downlink and Uplink Burst Profiles Setup .....................................................................55
4.2.4 Downlink Subframe Setup ............................................................................................55
4.2.5 PHY SDU Transmission from BS MAC to PHY .............................................................56
4.2.6 Uplink Subframe Setup.................................................................................................57
4.2.7 PHY PDU Reception from BS PHY to MAC ..................................................................58
4.2.8 CDMA Codes Reception ..............................................................................................58
4.3 Generic Message Header, Format, and Coding...................................................................59
4.3.1 Message Type Field Coding .........................................................................................60
4.3.2 Error Code Field Coding...............................................................................................61
5 PHY SAP Primitives ...................................................................................................................62
5.1 PHY_TXSTART.request......................................................................................................62
5.2 PHY_TXSTART.confirmation ..............................................................................................62
5.3 PHY_TXSTART.indication...................................................................................................63
5.4 PHY_TXSDU.request..........................................................................................................63
5.5 PHY_TXSDU.confirmation ..................................................................................................64
5.6 PHY_TXEND.indication.......................................................................................................65
5.7 PHY_RXSTART.request .....................................................................................................66
5.8 PHY_RXSTART.confirmation ..............................................................................................66
5.9 PHY_RXSTART.indication ..................................................................................................67
5.10 PHY_RXSDU.indication...................................................................................................67
5.11 PHY_RXEND.indication...................................................................................................70
5.12 PHY_RXCDMA.indication................................................................................................71

6 PHY SAP Messages over SPI ....................................................................................................73

7 PHY SAP Messages over Ethernet ............................................................................................74
Figures
Figure 2-1: BS Reference Model .......................................................................................................12
Figure 2-2: Example BS implementations..........................................................................................13
Figure 3-1: Typical OFDMA TDD frame format ..................................................................................15
Figure 3-2: DL map allocations..........................................................................................................17
Figure 3-3: Downlink sub-allocation data burst ..................................................................................18
Figure 3-4: Ranging allocation...........................................................................................................19
Figure 3-5: Normal data burst allocations in the uplink.......................................................................20
Figure 3-6: Sub-alloc type allocations in the uplink ............................................................................21
Figure 3-7: Mini-subchannels (Ctype = 0) ..........................................................................................22
Figure 3-10: Mini-subchannels (Ctype = 3) ........................................................................................23
Figure 3-11: Frame descriptor hierarchy............................................................................................24
Figure 4-1: MAC PDU transmission...................................................................................................55
Figure 4-2: Example of using PHY_TXSDU for BS transmitting .........................................................57
Figure 4-3: Example of using PHY_RXSDU for BS receiving.............................................................58
Figure 7-1: PHY SAP Ethernet encapsulation....................................................................................74
Tables
Table 3-1: Subframe descriptor format ..............................................................................................24
Table 3-2: Zone descriptor format......................................................................................................25
Table 3-3: Burst descriptor format .....................................................................................................25
Table 3-4: Sub-burst description format.............................................................................................26
Table 3-5: Parameter structure template ...........................................................................................26
Table 3-6: FEC code type coding ......................................................................................................27
Table 3-7: Downlink subframe parameter structure format .................................................................30
Table 3-8: Generic Part of Downlink Zone Parameter Structure .........................................................31
Table 3-9: Normal and AAS Calibration Zone-Specific Part of Downlink Zone Parameter Structure ...32
Table 3-10: STC Zone -Specific Part of Downlink Zone Parameter Structure .....................................32
Table 3-11: AAS Zone -Specific Part of Downlink Zone Parameter Structure .....................................32

Table 3-12: Common Sync Symbol-Specific Part of Downlink Zone Parameter Structure...................33
Table 3-13: Generic Part of Downlink Burst Parameter Structure.......................................................33
Table 3-14: Map Data Burst-Specific Part of Downlink Burst Parameter Structure..............................34
Table 3-15: Normal Data Burst-Specific Part of Downlink Burst Parameter Structure .........................35
Table 3-16: PAPR Allocation-Specific Part of Downlink Burst Parameter Structure ............................35
Table 3-17: AAS-Specific Part of Downlink Optional Burst Parameters ..............................................35
Table 3-18: MIMO-Specific Part of Downlink Optional Burst Parameters............................................36
Table 3-19: Common Part of Downlink Sub-Burst Parameter Structure..............................................36
Table 3-20: No HARQ-Specific Part of Downlink Optional Sub-Burst Parameters ..............................38
Table 3-21: HARQ Chase Combining-Specific Part of Downlink Optional Sub-Burst Parameters ......38
Table 3-22: MIMO Chase Combining-Specific Part of Downlink Optional Sub-Burst Parameters .......38
Table 3-23: Uplink Subframe Parameter Structure Format.................................................................39
Table 3-24: Generic Part of Uplink Zone Parameter Structure ...........................................................40
Table 3-25: Normal Zone -Specific Part of Uplink Zone Parameter Structure .....................................41
Table 3-26: AAS Zone -Specific Part of Uplink Zone Parameter Structure..........................................41
Table 3-27: Generic Part of Uplink Burst Parameter Structure ...........................................................42
Table 3-28: HARQ ACK Channel Specific Part of Uplink Burst Parameter Structure ..........................43
Table 3-29: Fast Feedback Channel Specific Part of Uplink Burst Parameter Structure .....................43
Table 3-30: Initial Ranging/Handover Ranging Allocation Specific Part of Uplink Burst Parameter
Structure....................................................................................................................................44
Table 3-31: Periodic Ranging/Bandwidth Request Allocation Specific Part of Uplink Burst Parameter
Structure....................................................................................................................................44
Table 3-32: PAPR/Safety Zone Channel Specific Part of Uplink Burst Parameter Structure ...............44
Table 3-33: Sounding Zone Allocation Specific Part of Uplink Burst Parameter Structure...................45
Table 3-34: Noise Floor Calculation Allocation Specific Part of Uplink Burst Parameter Structure ......45
Table 3-35: Normal Data Burst Specific Part of Uplink Burst Parameter Structure..............................46
Table 3-36: AAS-specific part of Uplink Optional Burst Parameters....................................................46
Table 3-37: MIMO-specific part of Uplink Optional Burst Parameters .................................................47
Table 3-38: Common Part of Uplink Sub-Burst Parameter Structure ..................................................47
Table 3-39: Mini-Subchannel Allocation-Specific Part of Uplink Sub-Burst Parameter Structure.........48
Table 3-40: Fast Feedback Allocation-Specific Part of Uplink Sub-Burst Parameter Structure............48
Table 3-41: HARQ ACK Subchannel Allocation-Specific Part of Uplink Sub-Burst Parameter Structure
..................................................................................................................................................49
Table 3-42: Sounding Signal -Specific Part of Uplink Sub-Burst Parameter Structure.........................49
Table 3-43: Sub-Allocation -Specific Part of Uplink Sub-Burst Parameter Structure ...........................50
Table 3-44: No HARQ-Specific Part of Uplink Optional Sub-Burst Parameters...................................51

Table 3-45: HARQ Chase Combining-Specific Part of Uplink Optional Sub-Burst Parameters ...........51
Table 3-45: MIMO Chase Combining-Specific Part of Uplink Optional Sub-Burst Parameters ...........51
Table 4-1: PHY SAP Primitives .........................................................................................................53
Table 4-2: 802.16 PHY SAP Message Header ..................................................................................59
Table 4-3: Type Field Coding ............................................................................................................60
Table 4-4: Error Code (ERRORCODE) Field Coding .........................................................................61
Table 5-1: PHY_TXSTART.request ...................................................................................................62
Table 5-2: PHY_TXSTART.confirmation............................................................................................62
Table 5-3: PHY_TXSTART.indication................................................................................................63
Table 5-4: PHY_TXSDU.request .......................................................................................................63
Table 5-5: PHY_TXSDU.confirmation................................................................................................64
Table 5-6: PHY_TXEND.indication ....................................................................................................65
Table 5-7: PHY_RXSTART.request...................................................................................................66
Table 5-8: PHY_RXSTART.confirmation ...........................................................................................66
Table 5-9: PHY_RXSTART.indication................................................................................................67
Table 5-10: PHY_RXSDU.indication..................................................................................................67
Table 5-11: HARQ ACK channel data format.....................................................................................69
Table 5-12: Fast Feedback channel data format................................................................................70
Table 5-13: PHY_RXEND.indication..................................................................................................70
Table 5-14: PHY_RXCDMA.indication...............................................................................................71

1 Purpose of this Specification

The purpose of this specification is to define PHY SAP for 802.16 Base Stations MAC – OFDMA PHY
communication. In particular, it aims at:
• Clear separation of MAC- and PHY-level processing.
• Definition of low-latency data-plane level MAC-PHY communication for in-band control and
data transmission, supporting a number of concurrently serviced PHY entities.
• Enabling parallel design, implementation, and testing of the 802.16 MAC and the 802.16 PHY.
• Giving support for simulation of an 802.16 PHY to perform stand-alone 802.16 MAC
verification testing.
• Providing support of MAC-level interoperability testing (BS-SS) without PHY.
• Making possible seamless integration of an 802.16 MAC implementation with an 802.16 PHY
implementation.
• Providing definition of the assumptions and constraints for the MAC and PHY interface.
1.1 Abbreviations
AAS Advanced Antenna System
ACID HARQ channel ID
AI_SN HARQ Sequence Number
ACK Acknowledgement
ADC Analog-to-Digital Converter
AGC Automatic Gain Control
AMC Adaptive Modulation-Coding
ARQ Automatic Repeat reQuest
ASIC Application-Specific Integrated Circuit
BF Beamforming
BS Base Station
BTC Block Turbo Code
BW bandwidth
CC Convolutional Code
CDMA Code Division Multiple Access
CID Connection IDentifier
CINR Carrier-to-Interference-and-Noise Ratio
CP Cyclic Prefix
CRC Cyclic Redundancy Check
CTC Convolutional Turbo Coding
DAC Digital-to-Analog Converter
DCD Downlink Channel Descriptor
DIUC Downlink Interval Usage Code
DL downlink
DLFP DownLink Frame Prefix
DSP Digital Signal Processor

EOP End Of Packet

FCH Frame Control Header
FDD Frequency Division Duplex
FEC Forward Error Correction
FFT Fast Fourier Transform
FHDC Frequency Hopping Diversity Coding
FPGA Field-Programmable Gate Array
FUSC Full Usage of SubChannels
HARQ Hybrid ARQ
HCS Header Check Sequence
IANA Internet Assigned Numbers Authority
IE Information Element
I/F inteface
IFFT Inverse Fast Fourier Transform
ISSID Internal SS IDentifier
IR Incremental Redundancy
LDPC Low Density Parity Check
LNA Low-Noise Amplifier
lsb Least Significant Bit(s)
LW Long Word (32bits)
MAC Medium Access Control layer
MBS Multicast / Broadcast Services
MIMO Multiple Input Multiple Output
MRC Maximum Ratio Combining
msb Most Significant Bit(s)
MSF Media Switch Fabric
NACK (or NAK) Negative ACK
OFDMA Orthogonal Frequency Division Multiple Access
PAPR Peak-to-Average Power Ratio
PCI Peripheral Component Interconnect
PDU Protocol Data Unit
PUSC Partial Usage of SubChannels
PHY physical layer
PRBS Pseudo-Random Binary Sequence
PS Physical Slot
QAM Quadrature Amplitude Modulation
QPSK Quadrature Phase-Shift Keying
RF Radio-Frequency transceiver
RSSI Receive Signal Strength Indicator
RTG Receive/transmit Transition Gap

Rx receiver
SAP Service Access Point
SDMA Spatial Division Multiple Access
SDU Service Data Unit
SISO Single Input Single Output
SM Spatial Multiplexing
SNR Signal-to-Noise Ratio
SOP Start Of Packet
SPI System Packet Interface
SS Subscriber Station
STC Space Time Coding
STTD Space Time Transmit Diversity
TDD Time Division Duplex
TTG Transmit/receive Transition Gap
TUSC Tile Usage of SubChannels
Tx transmitter
UCD Uplink Channel Descriptor
UEP Unequal Error Protection
UIUC Uplink Interval Usage Code
UL uplink
XID cross-IDentifier
ZT Zero-Tailing

2 PHY SAP Introduction

2.1 Overview
2.1.1 Base Station Reference Model

Figure 2-1 shows a reference model of a Base Station (BS). The Reference Point C represents the
interface between the MAC and the PHY. This document defines a protocol and data structures for
communication across this reference point for an 802.16 MAC and an 802.16 OFDMA PHY.
Reference Points:
A External Distribution
IP Networking (Standard optical I/F)
IP Routing Capability (or ATM)
Internal MAC
B
802.16 Candidate for Standard
MAC (Control plane access)
MAC + Scheduler
Functionality C Low Speed -
(Candidate for standard)
Symbol Rate
D High Speed
(No value in standardizing)
High-Rate
Baseband Processing
Smart Antenna Interface
E’ (Exists only when doing AAS, etc.)
Antenna
Pre - Processing
Digitized RF
E (Candidate for a standard)
Includes Antennas, LNA,

Filters and DAC/ADC RF
External RF
F (Standard OFDMA)
Figure 2-1: BS Reference Model
Figure 2-2 illustrates at a high level the hardware in a multi-sector and single sector BS.
• The multi-sector BS contains a PHY processor (can be implemented as one or more ASICs,
FPGAs or DSPs) for each sector. There is one or more RF entities for each sector, depending
on the number of antennas deployed in each sector, one MAC processor on which the MAC
instances corresponding to each of the sectors are deployed and there is a common physical
link that connects the PHY processors and the MAC processor.
• In the single-sector BS, there is a single PHY processor, one or more RF processors and one
MAC processor. The MAC and PHY are connected via a point-to-point link.
Other configurations are possible, but from the perspective of the MAC-PHY interface, these two
configurations represent the major cases that need to be handled by a MAC-PHY protocol.

Multi-Sector Base Station
RF
RF PHY
RF Processor
Processor Processor
Processor
MAC
RF Processor
RF PHY
RF Processor
Processor Processor
Processor
RF
RF PHY
RF Processor
Processor Processor
Processor
Single-Sector Base Station
RF
RF PHY MAC
RF Processor
Processor Processor Processor
Processor
Figure 2-2: Example BS implementations
2.1.2 MAC-PHY Protocol Overview

The MAC-PHY protocol defined in this document is designed to handle both of the cases illustrated in
Figure 2-2. There is a separate instance of the protocol for each instance of the PHY and logical MAC
instance. The MAC-PHY protocol is composed of separate protocols for transmit - within the downlink
(DL) subframe and for receive – within the uplink (UL) subframe, so a full-duplex operation is
supported. The protocol primitives are PHY-type-agnostic. Supporting missing features and new PHY
types requires mainly modification of the TXVECTOR/RXVECTOR structures.
The downlink protocol consists of the following major interactions:
• The MAC sends the PHY a description of the current DL subframe (TXVECTOR). This
description provides all of the information that the PHY needs to encode/modulate the data
bursts to be sent as part of the subframe.
• The MAC sends the PHY the burst data for the current DL subframe.
• The PHY (optionally) confirms buffering of the burst data and finally provides to the MAC the
status of the overall transmit operation in the DL subframe.
• The MAC sends the PHY a description of the next DL subframe, etc.
The uplink protocol consists of the following major interactions:
• The MAC sends the PHY a description of the current UL subframe (RXVECTOR). This
description provides all of the information that the PHY needs to demodulate/decode the data
bursts that are to be received as part of the subframe.
• The PHY sends the MAC the burst data for the current UL subframe.
• Certain types of data burst may require longer processing by the PHY and the PHY can send
them to the MAC separately from the data bursts for the current UL subframe.
• The MAC sends the PHY a description of the next UL subframe, etc.

The MAC-PHY protocol is defined using a layered approach. The document defines a set of messages
that achieve the communications described above independently of the structure of the frame
descriptors and types of data bursts.
The messages can be mapped to various underlying transports such as Ethernet or SPI-3 bus.
2.2 Assumptions
The following assumptions have been made:
1. There is a clean separation between the PHY and the MAC. All MAC operations (such as
ARQ and the scheduling of airlink resources) are implemented outside the PHY. The PHY
does not need to have any information about the internal operation of the MAC. In addition,
the PHY does not need to inspect the contents of any MAC PDUs to obtain control
information.
2. The PHY does not need to understand the UCD/DCD or the burst profiles. The MAC specifies
the modulation, FEC type, and repetition coding directly, so that the PHY does not need to
deal with UIUC and DIUC numbers to determine the modulation/code rate.
3. The PHY does not need to understand the structure of the DL and UL maps. The MAC
provides information to the PHY about the contents of each frame (zones, bursts, etc.) in a
software-friendly format.
4. The bandwidth of the physical link over which the MAC-PHY protocol operates is provisioned
to handle the MAC-PHY protocol traffic for the supported channel bandwidth and number of
SDMA users.
5. The PHY SAP is defined to allow a single MAC to control/support multiple PHY entities over a
shared physical link.
6. The physical link over the MAC-PHY protocol operates offers reliable delivery of MAC-PHY
protocol messages – every message sent over the bus will be delivered to the other side
without error and messages will not be misordered. To ensure detection of PHY or MAC
problems, missing or errored primitives are detected by PHY and MAC Rx/Tx state machines
and cause corrective actions, including PHY and/or MAC reset.
7. Both PHY and MAC sides implement hardware flow control.
8. It is assumed that MAC processing is much faster than this of the PHY; therefore, PHY cannot
overflow MAC (which is not true in the opposite direction). Some of the defined ‘.confirmation’
primitives (related to TXSDU requests) can be omitted if buffering at PHY is fast enough to
accept all related requests within single frame. If not, the ‘.confirmation’ primitives serve for
protocol-level flow control between MAC and PHY.
9. Both the MAC and the PHY devices are able to buffer a number of PHY_xxx messages
prepared to be sent to the other side. In the event that the MAC/PHY must drop protocol
messages due to lack of space in the buffer, PHY_TXSDU.request / RXSDU.indication
messages are dropped before any other PHY_xxx messages.
10. The PHY will not be changed on the fly without restarting the MAC (no hot swap). Because of
this, there is no need to specify the PHY type in the MAC-PHY protocol messages.
11. The PHY SAP is focused on BS side; it may be used both on BS and SS side, but the SS side
requires some modifications to the present specification. The current description defines the
BS primitives only.

3 Base Station Frame Descriptors

This section focuses on the BS version of Downlink and Uplink Frame Descriptors.
The downlink descriptor is also referred to as the TXVECTOR and the uplink descriptor is also referred
to as the RXVECTOR. The Frame Descriptors are used by the MAC to communicate the structure of
individual frames to the PHY. The Downlink Frame Descriptor describes the structure of and burst
allocations in a DL subframe, while the Uplink Frame Descriptor describes the structure of and burst
allocations in the UL subframe.
The information in the frame descriptors is a subset of the information that the BS MAC encodes into
the DL and UL maps that are broadcast to the SSs. The structure of the frame descriptors does not
mirror precisely that of the maps. The information in the frame descriptors is limited to the information
that the PHY requires to process the data within given subframe. Each type of allocation is described
in a single way in the descriptors, even though there may be multiple ways to describe the allocation in
the maps.
The frame descriptors defined in this document are intended to cover all of the different types of
allocations allowed by the OFDMA PHY in the 802.16e standard. They have been structured to try to
anticipate future extensions.
3.1 Frame Structure

This section describes the structure of an 802.16 OFDMA PHY frame and the different types of
allocations that can be created by the MAC.
Figure 3-1: Typical OFDMA TDD frame format

Figure 3-1 shows a typical OFDMA TDD frame. The frame is divided into a DL subframe and UL
subframe.
3.1.1 Downlink Subframe Structure

The first symbol within the DL subframe contains a preamble. The structure and processing of the
preamble by the base station is specified in the standard. It does not change on a frame-by-frame
basis, so the preamble is assumed to exist in the first symbol of the frame and is not explicitly
described in the downlink frame descriptor.
3.1.1.1 Downlink Zones

The DL subframe is divided into one or more zones. A zone is a region of the subframe starting at one
symbol and ending at another. Associated with each zone is the subchannelization scheme used
within the zone. There are three types of downlink zones. In normal zones, data is transmitted using a
single antenna. In STC zones, data is transmitted using STC (Alamouti), general beamforming or
MIMO coding using two or more antennas. In AAS zones, data is transmitted using specific
beamforming techniques. It should be noted that the standard uses the same information element (IE)
to describe normal and STC zones in the DL map, but in the frame descriptor they are differentiated.
The standard also defines an optional common sync symbol, which can be transmitted as the last
symbol of the downlink, in every fourth frame. Although the common sync symbol is technically not a
zone, the slot structure of the frame may require that additional symbols preceding the common sync
symbol are left unused. It is convenient to describe the common sync symbol as a type of zone in the
frame descriptors.
A special AAS calibration zone may also be needed – to be allocated on demand. PHY can signal a
need of a proper AAS calibration action and MAC should allocate a proper number of ending symbols
within DL subframe, at some future time.
3.1.1.2 Downlink Bursts

Within each zone, the transmission resources are allocated in bursts. Bursts are not allowed to cross
zones. The following subsections describe the different types of bursts that exist in the downlink.
3.1.1.2.1 FCH
The FCH always occupies a rectangular region, constituting the first burst in the first zone. The FCH
contains information about the code rate and modulation level of the DL map and its length. It is
always encoded using a specified code rate and modulation level. There are two different formats of
FCH, for 128FFT and for the remaining FFT sizes. For FFT sizes other than 128, the first 4 slots
contain 48 bits modulated by QPSK with coding rate ½ and repetition coding of 4. For FFT-128, the
first slot is dedicated to FCH and repetition is not applied.
3.1.1.2.2 Downlink Maps

Following the FCH (in the same symbol and the next logical subchannel) is the DL map. The standard
defines multiple types of DL and DL/UL maps. The basic DL map always begins after the FCH, but
other types of maps, such as the Sub-DL-UL-Map can begin at other places in the downlink subframe.
There can be up to three Sub-DL-UL-Maps per frame. Sub-DL-UL-Map message is used only with
compressed DL and appended UL Map structure.
The allocation of slots for all of the different types of maps is performed in the same way. Figure 3-2
illustrates map allocations in the first zone of the DL subframe. The different map allocations are
numbers from 1 to 4. Each map allocation begins in a slot at a given subchannel and symbol offset.
The size of the allocation is defined by the number of slots occupied by the map. The slots are always
allocated along the frequency axis first. When the last subchannel is reached, the allocation wraps up
to the lowest number subchannel in the next slot time. In the figure, map allocations 2 and 4 are
examples of how the allocation wraps to the next slot time.

Sub UL Map
Compressed DL Map and Compressed UL Map
Sub UL Map
Sub DL Map
Subchannel logical number
Preamble
Sub UL Map
Sub DL Map
Sub DL Map
Figure 3-2: DL map allocations
3.1.1.2.3 Normal Data Bursts

Normal data bursts are allocated rectangular regions within the subframe. Such regions are described
by a starting subchannel and symbol offset and a number of subchannels and symbols. There are a
number of examples of normal data bursts in Figure 3-1. They are labeled DL burst #1 through DL
burst #8.
3.1.1.2.4 Uplink Map

The standard defines the UL Map as a normal data burst (when compressed DL and appended UL
Map structure is not used), so the allocation for the UL map is a normal data burst. The UL-Map is
placed always in the first DL burst.
3.1.1.2.5 PAPR Allocation

A PAPR allocation can be created anywhere within the subframe to allow the PHY to minimize the
peak to average power ratio within each symbol of the frame, by transmitting specially chosen data
that minimize this ratio. The BS MAC must tell the BS PHY the location of such an allocation, even
though the allocation is not described in the DL Map, as none of the SSs needs to receive/process the
data in this allocation. For the purposes of the frame descriptor, PAPR allocations are defined to be
rectangular allocations.
3.1.1.2.6 Sub-Allocation Data Bursts

The standard defines a second type of allocation for data bursts, meant to support the situation where
the data for each subscriber must be sent in a separate burst (this type of allocation was defined

specifically for HARQ-enabled data, but the standard does not require that this type of allocation be
used exclusively for HARQ bursts).
Figure 3-3 illustrates this type of allocation. In this type of allocation, there is an “outer allocation”
(labeled “downlink allocation” in the figure) which is defined as a rectangular region in the subframe,
much like a normal data burst. Sub-allocations are defined within this “outer allocation”. Sub
allocations are specified by the starting symbol and subchannel offset and the number of slots. Slots
are allocated in a frequency first fashion in a way similar to maps. The first three sub-allocations within
the outer allocation are shown in the figure (the suballocations are labeled “HARQ sub-bursts” in the
figure). For the middle sub-allocation the starting symbol and subchannel is identified together with the
order in which slots are allocated.
Figure 3-3: Downlink sub-allocation data burst
3.1.2 Uplink Subframe Structure

3.1.2.1 Uplink Zones
The uplink subframe is divided into one or more zones. A zone is a region of the subframe starting at
one symbol and ending at another. Associated with each zone is the subchannelization scheme used
within the zone.
The standard defines two types of zones in the uplink subframe. Bursts transmitted within non-AAS
zones can be received using a single antenna or using multiple antennas (MRC, general beamforming
or MIMO). Within AAS zones, bursts are received at the base station using specific beamforming
techniques.
3.1.2.2 Uplink Bursts

Within each zone, the transmission resources are allocated in bursts. Bursts are not allowed to cross
zones. The following subsections describe the different types of bursts that exist in the uplink.
3.1.2.2.1 HARQ ACK Channel

HARQ ACK Channels are defined as rectangular regions in the subframe. They have a specific
structure, where a slot carries the ACKs for two different HARQ channels from different subscriber
stations. The individual ACKs are defined as HARQ ACK Subchannels (sub-bursts of HARQ ACK
Channel – see Section 3.1.2.2.10).

3.1.2.2.2 Fast Feedback Channel

Fast feedback channels are defined as rectangular regions in the subframe. They also have a specific
structure, in which slots are shared by multiple channels. The slots within a fast feedback allocation
can carry different types of data. Normal fast feedback channels carry 4 bits of information, enhanced
fast feedback channels carry 6 bits of information in one slot, or 3 bits in ½ slot. Primary/secondary
channels carry 6 bits and 4 bits respectively. Slots are allocated dynamically to subscribers by BS
periodically for limited or unlimited time.
3.1.2.2.3 Ranging Regions

There are several types of contention based regions used for ranging and bandwidth request
purposes. These are initial ranging, handover ranging, periodic ranging, and bandwidth request. There
are two types of contention based region allocations. The first type is used for initial ranging and
handover ranging. They are referred to as Initial Ranging/Handover Ranging Allocations. The second
type of allocation is for periodic ranging and bandwidth request. They are referred to as Periodic
Ranging/Bandwidth Request Allocations. It should be noted that in the standard, both types of
allocations are allocated using the same information element (IE), but it is convenient for the sake of
the frame descriptors to make a distinction between these two types of allocations.
Both Initial Ranging/Handover Ranging Allocations and Periodic Ranging/Bandwidth Request
Allocations are defined as rectangular allocations. Each allocation consists of one or more ranging
slots. Figure 3-4 illustrates a ranging opportunity that contains multiple ranging slots. The dimensions
of a slot depend on the type of allocation (initial/handover or period/bandwidth request) and on the
specified number of symbols over which ranging is performed. For initial ranging/handover ranging the
choices are 2 or 4 symbols, while for periodic ranging/bandwidth request the choices are 1 or 3
symbols. The unused area at the end of the region allocation can exist if the number of symbols in the
allocation is not a multiple of the number of symbols in the region. In the figure below, the number of
symbols required to transmit the appropriate ranging/BW request code (1, 2, 3 or 4 symbols), is
denoted as N1. N2 denotes the number of subchannels required to transmit a ranging code (6 in the
case of PUSC and TUSC1 and 8 in the case of Optional PUSC, TUSC2, and AMC).
Figure 3-4: Ranging allocation
3.1.2.2.4 PAPR/Safety Zone

PAPR/Safety Zone allocations are rectangular allocations. PAPR allocations are used to allow the
subscriber stations to insert tones to minimize the PAPR of the symbols that they transmit. Safety

channels are used by adjacent base stations to designate specific frequencies/time slots for limiting
the interference in 1x frequency reuse scenario.
3.1.2.2.5 Sounding Zone

Sounding Zone allocations are also rectangular. In the UL Map, they are allocated using the same IE
as the PAPR/Safety Channels, but it is convenient to describe them as separate allocations in the
frame descriptor. In a Sounding Zone there can be one or more sounding signals arriving from
different subscribers at the same time.
3.1.2.2.6 Noise Floor Allocation

In order to measure the noise (and interference) floor, the base station MAC may want to create an
empty allocation in the UL Map and instruct the PHY to measure the noise received in this “empty”
allocation. For this purpose, the Noise Floor Allocation is defined. This allocation is rectangular. Since
calculation of the noise floor is a local base stations issue, this allocation does not correspond to any
specific IE in the UL Map structure.
3.1.2.2.7 Normal Data Burst

Normal data bursts in the uplink are defined by a starting subchannel and symbol offset and by a
duration expressed in number of slots. The allocations are created by allocating slots along the time
axis until the end of the zone and then wrapping to the first symbol/slot in the next subchannel and
processing along the time axis. Figure 3-5 illustrates several normal data burst allocations within a
zone (labeled “UL burst #1” through “UL burst #4”). The order in which slots are allocated is shown by
the arrows that overlay UL burst #2.
Figure 3-5: Normal data burst allocations in the uplink

3.1.2.2.8 Sub-Allocation Data Burst

The standard defines a second type of allocation for data bursts, meant to support the situation where
the data for each subscriber must be sent in a separate burst. (This type of allocation was defined
specifically for HARQ-enabled data, but the standard does not require that this type of allocation be
used exclusively for HARQ bursts).
In this type of allocation, there is an “outer allocation” that is defined in the same way as a normal data
burst allocation. Sub-allocations are defined within this “outer allocation”. Sub allocations are specified
by the starting symbol and subchannel offset and the number of slots. Slots are allocated in a time first
fashion.Figure 3-6 illustrates this type of allocation. In the figure, one of the sub-allocation allocations
within “UL burst #2” is shown. The arrows indicate the order in which slots are assigned to the sub-
allocation from within the outer allocation.
Figure 3-6: Sub-alloc type allocations in the uplink
3.1.2.2.9 Mini-Subchannel Burst

Mini-subchannel allocations allow a number of users to share an allocation by splitting up the tiles that
make up each slot and allocating them to the users that share the allocation. This allows a given user
to transmit on a smaller number of tones than is otherwise possible.
The dimensions of Mini-subchannel allocations are specified in the same way as normal data
allocations in the uplink. A parameter called CType identifies the type of mini-subchannel. There are
four types. Two types are shared by two users. The difference is how the tiles within a slot are shared
between the users. The other two types are shared by 3 and 6 users. Each user is identified by a user
id.
The following figures illustrate the four different types of mini-subchannels. In each of the figures, the
allocation is shown using the red outline. The manner in which the slots are split between the users
that share the allocation (the mini-subchannels) is indicated using different colors.

Symbol k Symbol k+3 Symbol k+6 Symbol k+9

Start symbol /
subchannel 3 tiles
Subchannel 0
Subchannel 1
Subchannel 2
Number of slots
User Burst 1 Data
User Burst 2 Data
Figure 3-7: Mini-subchannels (Ctype = 0)

Start symbol /
subchannel individual tiles
Subchannel 0
Subchannel 1
Subchannel 2
Number of slots
User Burst 1 Data
User Burst 2 Data


Start symbol /
individual tiles
subchannel
Subchannel 0
Subchannel 1
Subchannel 2
Number of slots
User Burst 1 Data User Burst 3 Data
User Burst 2 Data

Start symbol /
subchannel individual tiles
Subchannel 0
Subchannel 1
Subchannel 2
Number of slots
User Burst 1 Data User Burst 2 Data User Burst 3 Data
User Burst 4 Data User Burst 5 Data User Burst 6 Data
3.1.2.2.10 HARQ ACK Subchannel

HARQ ACK Subchannel looks much like Mini-subchannel Ctype = 1 (see Figure 3-8). The subchannel
occupies half of the slot, so a slot can be shared between two subscribers. The even half subchannel
consist of Tile(0), Tile(2) and Tile(4). The odd half subchannel consist of Tile(1), Tile(3) and Tile(5).
HARQ ACK subchannel 2n is the first half of slot n; HARQ ACK subchannel (2n+1) is the second half
of slot n.

3.2 Frame Descriptors Hierarchy

The downlink subframe and uplink subframe of each frame is described by a frame descriptor
(TX/RXVECTOR). The frame descriptors for the downlink and uplink are similar in structure, but the
specific parameters are different. In this section, the top-level structure of a frame descriptor is
described, for both the downlink and uplink. The following figure shows the descriptor hierarchy.
Figure 3-11: Frame descriptor hierarchy
The description of the subframe is divided into zones. The frame descriptor consists of a series of
zone descriptions. Each zone description contains a zone descriptor that describes the zone and a list
of burst descriptors. Each burst descriptor describes one burst within the associated zone. Table 3-1
shows the format of a frame descriptor. Table 3-2 shows the structure of a zone description. Each
Burst can be further subdivided into Sub-Bursts as shown in Table 3-3. At each level (subframe, zone,
burst, sub-burst) each descriptor is identified by a type value, unique within a subframe (UL and DL
subframe type values may overlap).
Note: Unlike the convention used in the definition of the DL- and UL-Map (which was devised to save
precious air bandwidth), the frame descriptors utilize explicit parameters, even when the same
parameter is repeated for multiple bursts. For example, DL/UL Map would use default <parameter 1>
valid for subsequent map IEs, until the value is changed explicitly to some another value <parameter
2>, which in turn would remain in force until explicitly revoked or changed. In the descriptors, each
descriptor must be given together with either <parameter 1> or <parameter 2>, as appropriate.
Table 3-1: Subframe descriptor format
LW Bits Size Description
64 bits Subframe Parameter Structure (see Table 3-7 for DL

and Table 3-23 for UL)
8 bits Number of Zone Descriptors

(3 bits used)
24 bits Padding to align on 32 bit boundary

variable Zone Descriptor for zone 1 (see Table 3-2)
variable Zone Descriptor for zone 2
variable Zone Descriptor for zone n
Table 3-2: Zone descriptor format
variable Zone Parameter Structure (see sections 3.4.2 for DL

and 3.5.2 for UL zone parameter definitions)
8 bits Number of Burst Descriptors in this zone
24 bits Reserved (padding to align on 32 bit boundary)
variable Burst Descriptor for Burst 1 (See Table 3-3)
variable Burst Descriptor for Burst 2
variable Burst Descriptor for Burst n
Table 3-3: Burst descriptor format
variable Burst Parameter Structure (see sections 3.4.3 for DL

and 3.5.3 for UL zone parameter definitions)
8 bits Number of Sub-Burst Descriptors in this burst
24 bits Reserved (padding to align on 32 bit boundary)
variable Sub-Burst Descriptor for Sub-Burst 1 (See Table 3-4)
variable Sub-Burst Descriptor for Sub-Burst 2
variable Sub-Burst Descriptor for Sub-Burst n

Table 3-4: Sub-burst description format
variable Sub-Burst Descriptor Structure (see sections 3.4.3 for

DL and 3.5.3 for UL zone descriptor definitions)
3.2.1 Parameter Structure Formats

The zone, burst and sub-burst parameter structures are defined in a manner that allows for the
addition of structures for new types of zones, bursts and sub-bursts in the future. A zone/burst
parameter structure template is shown in Table 3-5. The structure begins with a structure type, which
indicates which type of zone or burst is being described. First three bits of the type (yyy) are used to
specify nesting level of a given descriptor. The next 5 bits are used to define specific type within the
nesting level. The zone/burst sequential number is used for verification / internal mapping purposes.
Following are the parameters that are common to all zones or bursts. Finally, are the specific
parameters that describe the specific zone/burst that is being described. There is a separate structure
for the specific parameters for each Structure Type. In order to allow for variable size descriptors and
for modification/expansion of the descriptors in the future, the type specific parameters are preceded
by a parameter giving the number of lower-level descriptors. Padding is added, so that all structures
are aligned on a 32-bit boundary.
Table 3-5: Parameter structure template
8 bits Structure Type

yyy00000 : First Structure Type
yyy00001 : Second Structure Type
8 bits sequential number of this structure within the parent structure
variable Structure Parameters
The zone, burst, and sub-burst descriptors are different for the downlink and uplink. Type values
assignments are unique within downlink and uplink subframes (but not globally). Downlink descriptors
are defined in section 3.4 and uplink descriptors are defined in section 3.5.

3.3 Common Parameter Definitions
3.3.1 FEC Code Type Field Coding

The following Forward Error Correction (FEC) code types are used in the DL and UL burst and sub-
burst descriptors.
1
Table 3-6: FEC code type coding
Value Description
0 QPSK (CC) 1/2
1 QPSK (CC) 3/4
2 16-QAM (CC) 1/2
3 16-QAM (CC) 3/4
4 64-QAM (CC) 1/2
5 64-QAM (CC) 2/3
6 64-QAM (CC) 3/4
7 QPSK (BTC) 1/2
8 QPSK (BTC) 3/4
9 16-QAM (BTC) 3/5
10 16-QAM (BTC) 4/5
11 64-QAM (BTC) 5/8
12 64-QAM (BTC) 4/5
13 QPSK (CTC) 1/2
14 Reserved
15 QPSK (CTC) 3/4
16 16-QAM (CTC) 1/2
17 16-QAM (CTC) 3/4
18 64-QAM (CTC) 1/2
19 64-QAM (CTC) 2/3
20 64-QAM (CTC) 3/4
1
State: as of IEEE 802.16-2005 specification

Value Description
21 64-QAM (CTC) 5/6
22 QPSK (ZT CC) 1/2
23 QPSK (ZT CC) 3/4
24 16-QAM (ZT CC) 1/2
25 16-QAM (ZT CC) 3/4
26 64-QAM (ZT CC) 1/2
27 64-QAM (ZT CC) 2/3
28 64-QAM (ZT CC) 3/4
29 QPSK (LDPC) 1/2
30 QPSK (LDPC) 2/3 A code
31 QPSK (LDPC) 3/4 A code
32 16-QAM (LDPC) 1/2
33 16-QAM (LDPC) 2/3 A code
35 64-QAM (LDPC) 1/2
38 QPSK (LDPC) 2/3 B code
39 QPSK (LDPC) 3/4 B code
40 16-QAM (LDPC) 2/3 B code
44 QPSK (CC with optional interleaver) 1/2
45 QPSK (CC with optional interleaver) 3/4
46 16-QAM (CC with optional interleaver) 1/2

Value Description
50 QPSK (LDPC) 5/6
51 16-QAM(LDPC) 5/6
52 64-QAM(LDPC) 5/6
53..255 reserved

3.4 Downlink Descriptors (TXVECTOR)
3.4.1 Downlink Subframe Parameter Structure

This is the top-level descriptor for downlink subframe.
Table 3-7: Downlink subframe parameter structure format
0 31:24 8 bits Subframe Type (000xxxxx)

00000001 – Downlink Subframe
(00000011-00011111 – reserved :
101xxxxx-111xxxxx – reserved)
0 23:16 8 bits Frame Number
0 15:8 8 bits reserved
0 7:0 8 bits 231(decimal) – PHY SAP version number
1 31:0 32 bits (18 Downlink reserved (=0)

bits)
Note: <LW> in the following tables are given relative to Zone Descriptor start within the Subframe
Descriptor.
3.4.2 Zone Parameters Structures

In the downlink, there are the following types of Zone Parameter Structures:
• Normal – This type of structure is used to define a zone in which neither STC/MIMO, general
beamforming nor AAS is performed. Data is transmitted using one antenna, with no special
coding in this type of zone.
• STC – This type of structure is used to define a zone in which STC/MIMO encoding is used to
transmit the data, using multiple antennas. Note that this zone can also be used with general
beamforming. In the DL MAP, this type of zone is indicated using a STC_Zone IE with the
STC type of “No STC” and permutation with dedicated pilots.
• AAS – This type of structure is used to define a zone where a specific beamforming is used to
transmit the data using between 2 and 12 antennas.
• Common Sync Symbol – This type of structure is used to define a region of the subframe
between 1 and 3 symbols wide in which the last symbol is used to transmit the common sync
symbol. The common sync symbol is technically not a zone in the subframe, but it is
convenient to define it as such in the frame descriptor. The common sync symbol zone may
be more than one symbol wide because the slot structure of the different subchannelization
schemes requires that symbols be allocated to zones in groups of 1, 2, or 3.
• AAS Calibration Zone – PHY can signal a need of a proper AAS calibration action and MAC
should allocate a proper number of ending symbols (across all subchannels) within DL
subframe in a form of AAS Calibration Zone, not later than suggested by the PHY.
The common part of the zone parameter structure has the parameters specified in the Table 3-8. Each
zone parameter structure in the DL frame descriptor contains this generic part and one of the specific
parts. The specific parts of the structure are defined in the tables that follow.

Table 3-8: Generic Part of Downlink Zone Parameter Structure
0 31:24 8 bits Zone Type (001xxxxx)

00100000 : Normal Zone Parameters
00100001: STC Zone Parameters
00100010: AAS Zone Parameters
00100011: Common Sync Symbol Parameters
00100100: AAS Calibration Zone
(00100101-00111111: reserved)
0 23:16 8 bits Zone Number (unique within DL subframe, starting from 0)
0 15:8 8 bits Start Symbol Offset (from beginning of DL subframe)
0 7:0 8 bits End Symbol Offset (from beginning of DL subframe)
1 31:24 8 bits Permutation Type

(4 bits
0000: PUSC
used)
0001: FUSC
0010: Optional FUSC
0011: AMC – 1 x 6
0100: AMC – 2 x 3
0101: AMC – 3 x 2
0110: TUSC1
0111: TUSC2
1000-1111: reserved
1 23:16 8 bits Use all subchannels indicator

(1 bit
0: use only subchannels specified in PHY configuration register 2
used)
(implementation specific)
1: use all subchannels
1 15:8 8 bits DL_PermBase

(5 bits
used)
1 7:0 8 bits PRBS_ID – used with PUSC zones, in which ‘use all subchannels’
(2 bits indicator is set
used)
2 31:24 8 bits Dedicated pilots

(1 bit
0: pilots are broadcast
used
1: pilots are dedicated
2
How segments are defined and how the subchannel allocation is performed at the initialization time is
beyond the scope of this specification

2 23:0 24 bits Reserved (padding to align on 32 bit boundary)
variable Zone Specific Data (per Zone Parameter Structure Type)
Table 3-9: Normal and AAS Calibration Zone-Specific Part of Downlink Zone Parameter
Structure
3 (empty)
Table 3-10: STC Zone -Specific Part of Downlink Zone Parameter Structure
3 31:24 8 bits STC type

(3 bits
000: STC using 2 antennas
used)
011: FHDC using 2 antennas
100-111: reserved
3 23:16 8 bits Matrix Indicator

(2 bits
00: Matrix A
used)
01: Matrix B
10: Matrix C
11: reserved
3 15:8 8 bits Midamble presence

(1 bit
0: not present
used)
1: present
3 7:0 8 bits Midamble boosting

(1 bit
0: no boosting
used)
1: boosting
Table 3-11: AAS Zone -Specific Part of Downlink Zone Parameter Structure
3 31:24 8 bits Preamble configuration

(2 bits
00: 0 symbols (preambles not supported)
used)


01: 1 symbol
10: 2 symbols
11: 3 symbols
3 23:16 8 bits SDMA supported indication

(1bit
0: SDMA not supported
used)
1: SDMA supported
variable Algorithm Specific Information (per Zone Type)
Algorithm-specific information is used to allow the MAC to provide the AAS processing part of the PHY
with additional information that is specific to the weight calculation/selection algorithm used by the
system, (e.g., a position index within a fixed grid, obtained at receive as part of status information).
Table 3-12: Common Sync Symbol-Specific Part of Downlink Zone Parameter Structure
3 (empty) No Zone type specific data
3.4.3 Burst Parameter Structures

There are the following types of downlink data burst parameter structures.
• Map Data Burst Parameter Structure
• Normal Data Burst Parameter Structure
• PAPR Allocation Parameter Structure
Table 3-13 shows the common downlink burst parameter structure. Table 3-14 – Table 3-16 describe
the burst type specific structures.
Table 3-13: Generic Part of Downlink Burst Parameter Structure
0 31:24 8 bits Burst Type (010xxxxx):

01000000 : Map Data Burst
01000001: Normal Data Burst
01000010: Control Command3
01000011 PAPR Allocation
(01000100-01011111: reserved)
3
If present, this pseudo-burst decription shall be present as the first in the first zone description only.
Only the Burst Type field is relevant, the remaining fields shall be set to zero.

0 23:16 8 bits Burst Type extension:

00000000: no extended data:
00000001: AAS v1
00000010: MIMO v1
(00000011-01111111:Reserved by Intel
10000000-11111111:User-defined)
0 15:8 8 bits Burst Number (used to correlate burst data, counted within a zone,
starting from 0)
0 7:0 8 bits Modulation/FEC Code Type

See Table 3-6 for an enumeration of the types.
1 31:0 32 bits Burst Data Length in bytes (if no sub-bursts)
2 31:24 8 bits OFDMA Symbol offset (from start of DL subfame)
2 23:16 8 bits Subchannel offset

(6 bits
used)
2 15:8 8 bits Boosting

(3 bits
000: normal
used)
001: +6dB
010: -6dB
011: +9dB
100: +3dB
101: -3dB
110: -9 dB
111: -12 dB
2 7:0 8 bits Repetition coding indication

(2 bits
00: No repetition coding
used)
01: Repetition coding of 2
variable Burst Type Specific Descriptor (per Burst Descriptor Type)
Table 3-14: Map Data Burst-Specific Part of Downlink Burst Parameter Structure
3 31:16 16 bits
(10 bits Number of slots (duration) after repetition code is applied.
used)

Table 3-15: Normal Data Burst-Specific Part of Downlink Burst Parameter Structure
3 31:24 8 bits Number of Symbols
3 23:16 8 bits Number of Subchannels

(6 bits
used)
3 15:0 16 bits AAS Handle (to enable AAS info update at PHY; null if not used or not
known). Ignored if sub-bursts are present
variable Optional Burst Parameters (see section 3.4.3.1)
Table 3-16: PAPR Allocation-Specific Part of Downlink Burst Parameter Structure

(6 bits
used)
3.4.3.1 Optional Burst Parameters

Optional Burst Parameters are used to specify additional parameters that apply to the different types of
bursts, but are optional depending on whether the burst is a MIMO or AAS burst. The presence or
absence of these additional parameters is indicated by the value of the Burst Type extension
parameter (see Table 3-13). The data structures for the optional burst parameters are having the same
layout as the zone and burst descriptors. There are separate definitions for the common parameters in
a common structure and there are type-specific parameters in type specific structures. For the
moment, the optional burst parameters are defined for AAS and MIMO.
Table 3-17: AAS-Specific Part of Downlink Optional Burst Parameters
4 31:24 8 bits Preamble Modifier Type

(1 bit
0: frequency shifted preamble
used)
1: time shifted preamble
4 23:16 8 bits Preamble Shift index (frequency shift when PM type = 0 and time shift
(4 bits when PM type = 1)


used
variable Algorithm specific Information (per Burst Type extension)
The SDMA is supported by allowing multiple overlapping AAS allocations. PHY, when detecting such
allocations will process them as SDMA.
The purpose of algorithm specific information is to allow for a way for specific PHY/MAC to pass
information that is specific to the AAS algorithm that is being employed. Some examples of algorithm
specific information might be the beam on which to transmit the data (in a beam steering system), or
information to correlate this burst to an uplink burst received in an earlier frame, whose weights should
be used as the basis of the weights for this burst.
Table 3-18: MIMO-Specific Part of Downlink Optional Burst Parameters
4 31:24 8 bits Matrix indicator

(2 bits
00: Matrix A
used)
01: Matrix B
10: Matrix C
11: reserved
4 23:16 8 bits Layer index

(2 bits
used
3.4.4 Sub-Burst Parameter Structures

There are the following types of downlink data burst descriptors.
• Sub-Allocation Data Burst Descriptor
Table 3-19 shows the common downlink sub-burst descriptor parameters
Table 3-19: Common Part of Downlink Sub-Burst Parameter Structure
0 31:24 8 bits Sub-Burst Type (011xxxxx)

01100000: No HARQ
01100001: HARQ Chase Combining
01100010: HARQ IR-CTC
01100011: HARQ IR-CC


01100100: MIMO Chase Combining
01100101: MIMO IR-CTC
01100110: MIMO IR-CC
01100111: MIMO-STC
(01101000-01111111: reserved)
0 23:16 8 bits Sub-Burst number (unique for the sub-bursts of a burst, starting from
0)
0 15:8 8 bits (6 Symbol Offset (from start of DL subfame)

bits
used)
0 7:0 8 bits (6 Subchannel Offset

bits
used)
1 31:16 16 bits Number of slots in this sub-burst

(10 bits
used)
1 15:0 16 bits Reserved

2 15:0 16 bits
ISSID (MAC-internal SS id – used by PHY in case of HARQ)
(signed)
known)
3 15:8 8 bits (3 Boosting

bits
000: normal
used)
001: +6dB
010: -6dB
011: +9dB
100: +3dB
101: -3dB
110: -9 dB
111: -12 dB
3 7:0 8 bits (2 Repetition coding indication

bits
used)


4 31:0 32 bits Sub-Burst Data Length in bytes (including 2 bytes for CRC-16 if
HARQ)
variable Optional parameters (structure depends on Sub-Burst type; see

3.4.4.1 for definition)
3.4.4.1 Optional Sub-Burst Parameters
Table 3-20: No HARQ-Specific Part of Downlink Optional Sub-Burst Parameters
5 No specific parameters
Table 3-21: HARQ Chase Combining-Specific Part of Downlink Optional Sub-Burst Parameters 4
5 31:24 8 bits HARQ channel id (ACID)

(4 bits
used)
5 23:16 8 bits HARQ sequence number (AI_SN) – this value enables to differentiate
(1 bit new transmissions from retransmissions
used)
5 15:8 8 bits 00 – no flush action

(2 bits
10 – flush request to PHY for the ISSID/ACID
used)
11 – flush request to PHY for the given ISSID (ACID and AI_SN fields
above are irrelevant in this case)
5 7:0 8 bits Reserved (padding to align on 32-bit boundary)
Table 3-22: MIMO Chase Combining-Specific Part of Downlink Optional Sub-Burst Parameters 5

(4 bits
used)
(1 bit new transmissions from retransmissions
4
This sub-burst type can be present in Normal Data Burst or in Control Command Type
5


used)

(2 bits
used)

(2 bits
used
3.4.5 Downlink Frame Descriptor Usage Notes

3.4.5.1 FCH Handling
The FCH is described by a Normal Data Burst. The MAC is assumed to perform duplication of the 24
bits long FCH to make it 48 bits - so that the data that the MAC passes to the PHY looks like a normal
data burst. Note that - as an exception - for 128FFT the FCH is shorter, it contains just 12 bits.
3.4.5.2 Sub-Allocation Bursts

The Sub-allocation bursts are described using two levels of descriptors. The burst parameter structure
describes the “outer” allocation, while the sub-burst descriptors are used to describe each of the sub-
allocations within an outer allocation (being a normal burst).
3.4.5.3 AAS Bursts

AAS bursts are described using the normal or sub-allocation burst descriptors along with AAS Optional
Burst Parameters.
3.4.5.4 HARQ Bursts

HARQ bursts are described using the Sub-allocation burst descriptor, with the optional HARQ
parameters included. It is assumed that MAC has full control over HARQ action at PHY.
3.4.5.5 MBS Bursts

Multicast and Broadcast Service bursts are described using normal data burst descriptors.
3.5 Uplink Descriptors (RXVECTOR)
3.5.1 Uplink Subframe Parameter Structure

This is the top-level descriptor portion for uplink subframe.
Table 3-23: Uplink Subframe Parameter Structure Format
0 31:24 8 bits Subframe Type (000xxxxx)

00000010 – Uplink Subframe
(00000011-00011111 – reserved :
101xxxxx-111xxxxx – reserved)

0 23:16 8 bits Frame Number
0 7:0 8 bits 231(decimal) – PHY SAP version number
1 31:0 32 bits (18 Allocation start time in PS (counted from start of the DL
bits) subframe described by most recent TXVECTOR)
Note: <LW> in the below tables are given relative to Zone Descriptor start within the Subframe
Descriptor.
3.5.2 Zone Parameter Structures

In the uplink, there are the following types of Zone Parameter Structures:
• Normal – This type of structure is used to define a zone in which AAS is not used (note this
type can be used also with general beamforming).
• AAS – This type of structure is used to define a zone where specific beamforming is used to
receive data.
Table 3-24: Generic Part of Uplink Zone Parameter Structure
0 31:24 8 bits Zone Type (001xxxxx)

00100000 : Normal Zone Parameters
00100001: reserved
00100010: AAS Zone
00100011: reserved
(00100011-00111111 reserved)
0 23:16 8 bits Zone Number (unique within UL subframe, starting from 0)
0 15:8 8 bits Start Symbol Offset (from start of UL subframe)
0 7:0 8 bits End Symbol Offset (from start of UL subframe)
1 31:24 8 bits Permutation Type

(3 bits
000: PUSC
used)
001: Optional PUSC
010: AMC – 1 x 6
011: AMC – 2 x 3
100: AMC – 3 x 2
101-111: reserved
1 23:20 4 bits Use all subchannels indicator

(1 bit
0: use only subchannels specified in PHY configuration register
used)
(implementation specific)


1: use all subchannels
1 19:16 4 bits Disable PUSC subchannel rotation

(1 bit 0: rotation enabled
used) 1: rotation disabled
1 15:8 8 bits UL_PermBase

(7 bits
used)
1 7:0 8 bits Rx AGC range extension

(1 bit
0 – default range
used)
1 – range to cover SS very close to BS
variable Zone Type Specific Data (per Zone Descriptor Type)
Table 3-25: Normal Zone -Specific Part of Uplink Zone Parameter Structure
Table 3-26: AAS Zone -Specific Part of Uplink Zone Parameter Structure
2 31:24 8 bits Preamble configuration

(2 bits
00: 0 symbols (preambles not supported)
used)
01: 1 symbol
10: 2 symbols
11: 3 symbols
2 23:16 8 bits Preamble type

(1 bit
used)
2 15:8 8 bits SDMA supported indication

(1bit
0: SDMA not supported
used)
1: SDMA supported
variable Algorithm Specific Information (per Zone Type)

3.5.3 Burst Parameter Structures

In the uplink, there are the following types of Data Burst Parameter Structures:
• HARQ ACK Channel Allocation Parameter Structure
• Fast Feedback Channel Allocation Parameter Structure
• Initial Ranging/Handover Ranging Allocation Parameter Structure
• Periodic Ranging/Bandwidth Request Allocation Parameter Structure
• PAPR/Safety Zone Allocation Parameter Structure
• Sounding Zone Allocation Parameter Structure
• Noise Floor Calculation Allocation Parameter Structure
• Normal Data burst Allocation Parameter Structure
Table 3-27 shows the common downlink burst parameters. Table 3-28 –describe the burst type
specific structures.
Table 3-27: Generic Part of Uplink Burst Parameter Structure
0 31:24 8 bits Burst Type (010xxxxx):

01000000: HARQ ACK Channel allocation
01000001: Fast Feedback Channel allocation
01000010: Initial Ranging/Handover Ranging region
01000011: Periodic Ranging/Bandwidth Request region
01000100: PAPR/Safety Zone allocation
01000101: Sounding Zone allocation
01000110: Noise Floor Calculation allocation
01000111: Normal Data burst
01001000: Control Command6
01001001: reserved
01001010 – 01001111: reserved
0 23:16 8 bits Burst Type extension:

00000000: no extended data:
00000001: AAS v1
00000010: MIMO v1
(00000011-01111111:Reserved by Intel
10000000-11111111:User-defined)
0 15:8 8 bits Burst Number (used to correlate burst data, unique within a zone,
starting from 0)

6
If present, this pseudo-burst decription shall be present as the first in the first zone description only.
Only the Burst Type field is relevant, the remaining fields shall be set to zero.

1 31:0 32 bits Burst Data Length in bytes (if no sub-bursts)
2 31:24 8 bits OFDMA Symbol offset (from start of UL subframe)
2 23:16 8 bits Subchannel offset

(6 bits
used)

(2 bits
used)
3 31:16 16 bits ISSID (MAC-internal SS id – used by MAC to match incoming .indication

(signed) with specific SS) – normal data burst with no sub-bursts. Ignored when
sub-bursts are present.
known). Ignored when sub-bursts are present
variable Burst Type Specific Descriptor (per Burst Descriptor Type)
Table 3-28: HARQ ACK Channel Specific Part of Uplink Burst Parameter Structure

(6 bits
used)
Table 3-29: Fast Feedback Channel Specific Part of Uplink Burst Parameter Structure

(6 bits
used)

Table 3-30: Initial Ranging/Handover Ranging Allocation Specific Part of Uplink Burst
Parameter Structure

(6 bits
used)
4 15:8 8 bits Ranging method

(1 bit
0: ranging over 2 symbols
used)
5 31:16 16 bits Zone XID (Used by MAC for matching future CDMA code with current
allocation region; used with RXCDMA.indication only)
Table 3-31: Periodic Ranging/Bandwidth Request Allocation Specific Part of Uplink Burst
Parameter Structure

(6 bits
used)
4 15:8 8 bits Ranging method

(1 bit
0: ranging over 1 symbol
used)
5 31:16 16 bits Zone XID (Used by MAC for matching future CDMA code with current
allocation region; used with RXCDMA.indication only)
Table 3-32: PAPR/Safety Zone Channel Specific Part of Uplink Burst Parameter Structure

(6 bits


used)
4 15:8 8 bits 0 – UL PAPR reduction

(1 bit
1 – UL Safety zone
used)
Table 3-33: Sounding Zone Allocation Specific Part of Uplink Burst Parameter Structure

(6 bits
used)
4 15:8 8 bits Sounding type (0 = Type A, 1 = Type B)

(1 bit
used)
4 7:0 8 bits Separability type (0 = all subcarrierrs, 1 = decimated subcarrierrs in a

(1 bit band; used if Sounding type = 0)
used)
Max Cyclic Shift Indx (used if Separability = 0)
5 31:24 8 bits
000: P=4;
(3 bits
001: P=8;
used)
010: P=16,
011: P=32
100: P=9;
101: P=18;
110-111: reserved
Decimation value (used if Separability = 1)
5 31:24 8 bits
Sound every Dth subcarrier within the sounding allocation. Decimation
(3 bits
value D is 2 to the power of (1 plus this value), hence 2,4,8,… up to
used)
maximum of 128, and 111 means decimation of 5.
5 23:16 8 bits Decimation offset randomization (0 = no randomization,
(1 bit 1 = randomization)
used)
Table 3-34: Noise Floor Calculation Allocation Specific Part of Uplink Burst Parameter
Structure

(6 bits


used)
Table 3-35: Normal Data Burst Specific Part of Uplink Burst Parameter Structure
4 31:16 16 bits Number of slots (duration)

(10 bits
used)
variable Optional Burst Parameters (see section 3.5.3.1)
3.5.3.1 Optional Burst Parameters

Optional Burst Parameters are used to specify additional parameters that apply to the different types of
bursts, but are optional depending on whether the burst is a MIMO or AAS burst. The presence or
absence of these additional parameters is indicated by the value of the Burst Type Extension
parameter (see Table 3-27). The data structures for the optional burst parameters are having the same
layout as the zone and burst descriptors. The common parameters are specified in a common
structure and the type-specific parameters are specified in type specific structures. The current
version of this document defines optional burst parameters for AAS and MIMO.
Table 3-36: AAS-specific part of Uplink Optional Burst Parameters
5 31:24 8 bits Preamble Modifier Type

(1 bit
used)
5 7:0 8 bits Preamble Shift index (frequency shift when PM type = 0 and time shift
(4 bits when PM type = 1)
used)
The purpose of algorithm specific information is to allow for a way for specific PHY/MAC to pass
information that is specific to the beamforming algorithm that is being employed. Some examples of
algorithm specific information might be the beam on which to transmit the data (in a beam steering
system), or information to correlate this burst to an uplink burst received in an earlier frame, whose
weights should be used as the basis of the weights for this burst.

Table 3-37: MIMO-specific part of Uplink Optional Burst Parameters
5 31:24 8 bits Matrix indicator (dual antenna SS)

(2 bits
00: Matrix A (STTD)
used)
01: Matrix B (SM)
10: Reserved
11: Reserved
5 23:16 8 bits Pilot patterns

(4 bits 0001: pattern A
used 0010: pattern B
0100: pattern C
1000: pattern D
5 15:12 4 bits Collaborative MIMO control

(1 bit 0: non-collaborative
used) 1: collaborative
5 11:8 4 bits 0: Single TX antenna SS

(1 bit 1: Dual TX antenna SS
used)

(2 bits
used)
3.5.4 Sub-Burst Parameter Structures

In the uplink, there are the following types of Data Burst Descriptors:
• Sub-Alloc Data Burst Allocation Descriptor
• Mini-Subchannel Burst Allocation Descriptor
• Fast Feedback Allocation Descriptor
• Sounding Signal Allocation Descriptor
Table 3-38 shows the common uplink sub-burst descriptor parameters.
Table 3-38: Common Part of Uplink Sub-Burst Parameter Structure
0 31:24 8 bits Sub-Burst Type (011xxxxx)

01100000: No HARQ
01100001: HARQ Chase Combining
01100010: HARQ IR-CTC
01100011: HARQ IR-CC
01100100: MIMO Chase Combining
01100101: MIMO IR-CTC
01100110: MIMO IR-CC


01100111: MIMO-STC
01101000: Mini-subchannel
01101001: Fast Feedback channel
01101010: HARQ ACK subchannel
01101011: Sounding signal
(01101100-01111111: reserved)
0 23:16 8 bits Sub-Burst number (unique within the burst, starting from 0)

(signed) with specific SS)
known). For sounding signal, AAS Handle helps PHY associate given
signal with subsequent correlated UL burst.
variable Optional information (per Sub-Burst Type extension)
3.5.4.1 Optional Sub-Burst Parameters
Table 3-39: Mini-Subchannel Allocation-Specific Part of Uplink Sub-Burst Parameter Structure
2 31:24 8 bits CType

(2 bits
00: 2 mini-subchannels adjacent tiles
used)
01: 2 mini subchannels interleaved tiles
10: 3 mini subchannels
11: 6 mini subchannels
2 23:16 8 bits Mini-subchannel Index of this allocation

(3 bits
used)
Table 3-40: Fast Feedback Allocation-Specific Part of Uplink Sub-Burst Parameter Structure
2 31:24 8 bits Feedback type coding (to be returned to MAC together with feedback)
00000001: 3 bit-MIMO Fast-feedback
00000010: Enhanced FAST_FEEDBACK
00000100: reserved
00001000; reserved


00010000: UEP fast-feedback
00100000: A measurement report shall be performed on the last
DL burst7
01000000: Primary/Secondary FAST_FEEDBACK
10000000: DIUC-CQI Fast-feedback
2 23:23 1 bit Reserved = 0
2 22:20 3 bits Feedback sub-type

0 – CQI (CINR) measurement
1 – Control feedback
2 19:8 12 bits CQICH_ID (to be returned to MAC together with feedback)

(up to 9
bits
used)
2 5:0 6 bits Slot offset
Table 3-41: HARQ ACK Subchannel Allocation-Specific Part of Uplink Sub-Burst Parameter
Structure
2 31:28 4 bits ACID (to be returned to MAC together with ACK)
Table 3-42: Sounding Signal -Specific Part of Uplink Sub-Burst Parameter Structure8
2 31:24 8 bits Sounding symbol index within Sounding zone

(3 bits
used)
Power assignment method
2 23:16 8 bits
00 = equal power;
(2 bits
01 = Reserved;
used)
10 = Interference dependent. Per subcarrier power limit;
11 = Interference dependent. Total power limit.
2 15:8 8 bits Power boost (0 = no boost, 1 = boost)
(1 bit
used)
7
See IEEE 802.16-2005 specification, section 8.4.5.4.10.1
8
Defined currently for Sounding type A only

2 7:0 8 bits Allocation mode (0 – Normal, 1- Band AMC)

(1 bit
used)
3 31:24 8 bits Start frequency band (if Allocation mode = 0)

(7 bits
used)
3 23:16 8 bits Number of frequency bands (if Allocation mode = 0)

(7 bits
used)
3 31:16 16 bits Band bit map (if Allocation mode = 1)

(12 bits
used)
3 15:8 8 bits Cyclic time shift index (if Separability type = 0)

(5 bits
used)
3 15:8 8 bits Decimation offset (if Separability type = 1)

(6 bits
used)
The below table describes the remaining Sub-Burst types.
Table 3-43: Sub-Allocation -Specific Part of Uplink Sub-Burst Parameter Structure
2 31:24 8 bits Symbol Offset (from start of UL subframe)
2 23:16 8 bits Subchannel Offset

(6 bits
used)
2 15:0 16 bits Number of slots in this sub-allocation

(10 bits
used)
3 31:0 32 bits Sub-Burst Data Length in bytes

(2 bits
used)


variable Optional parameters (structure depends on Sub-BurstType parameter,

see below)
Table 3-44: No HARQ-Specific Part of Uplink Optional Sub-Burst Parameters
Table 3-45: HARQ Chase Combining-Specific Part of Uplink Optional Sub-Burst Parameters 9

(4 bits
used)
(1 bit new receives from re-submitted receives
used)

(2 bits
used)
Table 3-46: MIMO Chase Combining-Specific Part of Uplink Optional Sub-Burst Parameters 10

(4 bits
used)
(1 bit new receives from re-submitted receives
used)

(2 bits
used)
9
10

5 7:0 8 bits Matrix (dual antenna SS)

(1 bit 0: Matrix A
used) 1: Matrix B
3.5.5 Uplink Frame Descriptor Usage Notes

3.5.5.1 Sub-Allocation Bursts
The Sub-allocation burst descriptor is used to describe each of the sub-allocations within an outer
allocation (being a normal burst). The MAC creates a sub-allocation burst descriptor for each of the
sub-allocations.
3.5.5.2 Mini Subchannel Bursts

The mini-subchannel burst descriptor is used to describe the mini-subchannel allocation for each of
the users of the mini-subchannel. The MAC creates a mini-subchannel burst descriptor for each of the
users. Each of these describe the same allocation (being a normal burst) and differ only in the mini-
subchannel index parameter.
3.5.5.3 AAS Bursts

AAS bursts are described using the normal or sub-allocation burst descriptors along with AAS Optional
Burst Parameters.
3.5.5.4 HARQ Bursts

HARQ bursts are described using the Sub-allocation burst descriptor, with the optional HARQ
parameters included. It is assumed that MAC has full control over HARQ action at PHY.
3.5.5.5 CDMA Allocation (UIUC=14)

CDMA Allocations are described using normal data bursts allocation descriptors. They are allocated in
the same zone as the former UIUC=12 allocation took place.
3.5.5.6 Fast_Ranging_IE Allocations

Contention-based Ranging allocations described with UUIC=12 are described using Initial/Handover
Ranging or Periodic Ranging/Bandwidth Request Burst Allocation Descriptors.
Non-contention-based Ranging allocations described by the Fast_Ranging_IE with UIUC=15 and
Extended UIUC=9 are described using Normal Data Burst Allocation Descriptors.

4 Protocol Description
The MAC and the PHY communicate by exchanging PHY SAP primitives. These primitives allow the
MAC to pass control information and data to be transmitted to the PHY and allow the PHY to pass
status information and received data to the MAC. The control information that is passed with these
primitives consists mainly of the frame descriptor structures presented earlier in this document.
The protocol is message-based, in which the maximum size of a message is specified as part of the
configuration of the interface. Primitives can be fragmented to fit into the maximum message size. The
message header facilitates segmentation / reassembly process. It is assumed that within the same
PHY entity the primitive fragments will arrive not intermixed with other primitives fragments.
Messages can be encapsulated into packets for transport across the physical link. Encapsulations for
SPI-3 and Ethernet are defined later in this document.
4.1 PHY SAP Primitives

The following set of primitives is defined for PHY SAP:
Table 4-1: PHY SAP Primitives
Description Reference chapter
PHY_TXSTART.request 5.1
PHY_TXSTART.confirmation 5.2
PHY_TXSTART.indication 5.3
PHY_TXSDU.request 5.4
PHY_TXSDU.confirmation 5.5
PHY_TXEND.indication 5.6
PHY_RXSTART.request 5.7
PHY_RXSTART.confirmation 5.8
PHY_RXSTART.indication 5.9
PHY_RXSDU.indication 5.10
PHY_RXEND.indication 5.11
PHY_RXCDMA.indication 5.12
The primitives are described later in this document (see chapters 4.3 and 5).
4.2 MAC – PHY Communication

The major data plane communication that occurs between the MAC and the PHY is described in the
following subsections. Not all of communication with PHY occurs over the PHY SAP (using the PHY
SAP primitives) – the communication with control plane is implementation specific. It is mentioned here
for the sake of completeness.

4.2.1 PHY Initialization

Note: this section is informative only.
It is assumed that PHY initialization and configuration is not performed using PHY SAP, but using
some other method which is PHY specific. The PHY initialization process typically involves
communication between PHY sub-system and the Control Plane sub-system through the PCI bus (or
other means) connection. The managing interface provides the information about the underlining PHY
operation and default PHY parameter values which are pertinent to the MAC and PHY interaction.
After the PHY sub-system is powered up, the Control Plane downloads the PHY firmware into the PHY
sub-system and also populates specific PHY parameters and PHY profiles for that particular PHY sub-
system. The parameters and profiles can include the following:
• PHY entity ID – identify this particular PHY with respect to multiple sectors (including
segments), multiple antennas and multiple carriers (the value is assigned by Control Plane).
• PHY profile – this profile information specifies the characteristic and the performance of this
particular PHY sub-system including the following:
• Channel bandwidth
• Frame duration selection
• Number of used sub-carriers
• Sampling factor
• Channel coding selection
• Pilot modulation
• Interleaving mechanism
• Preamble selection
• Modulation selection
• Frame structure
• Duplex method, TDD/FDD.
• Ratio of CP to useful time, G – 1/4, 1/8, 1/16 or 1/32
• AAS, MIMO, HARQ, etc. options.
4.2.2 General PDU and SDU handling between MAC and PHY Layers
The MAC – PHY communication is done using the PHY SAP interface.
As defined in the IEEE 802.16 spec, data transferred via the MAC and PHY protocol layers undergo a
number of transformations. Figure 4-1 shows only the most important ones (note that PHY SDU
mapping to FEC blocks is simplified). We describe here transmit processing only. Receive processing
is the reverse of transmit processing
The MAC Layer prepares data from MAC management messages or data SDUs for transmission. The
MAC performs either fragmentation, or packing (or neither) while forming MAC PDUs. The formed
MAC PDUs are concatenated into bursts and presented to the PHY Layer as PHY SDUs for
transmission in the next frame, along with control information describing how they are to be handled
(contained in TXVECTOR). In the BS case, this control information is equivalent to the DL-Map
message, and contains data such as:
• FEC code type – identifying a burst profile,
• Preamble present flag,
• Start time of a burst.
Note that the mapping between the MAC PDUs and PHY SDUs is not 1:1 . In Figure4-1, we show an
example in which MAC PDU 1, MAC PDU 2 and MAC PDU 3 are concatenated to become PHY SDU
1.
The PHY layer computes the SDU byte length by summing up the PHY_TXSDU.request message
segment lengths, so it is able to correctly construct the PHY PDUs – i.e., subsequent FEC block(s).

At the BS, the preparation of PHY PDUs includes adding preambles (where required), combining PHY
SDUs into OFDMA symbols and providing padding at FEC blocks for each processed burst (to fill
whole OFDMA slots). It is the receiving SS MAC responsibility to discard the padding. FEC blocks are
constructed according to modulation and coding connected with a given burst profile. The PHY SDU
has a (1:1) mapping to the DL burst. Bursts have (many:many) mapping to OFDMA symbols.
The BS MAC Layer DL scheduler is responsible of grouping MAC PDUs into bursts. The PHY will
therefore perform a simple sequential processing of the transmitted MAC PDU groups.according to the
TXVECTOR contents (equivalent to the current DL Map).
At the SS, the preparation of PHY PDUs includes the adding of preambles (where required), and
providing padding at FEC blocks for each processed PHY SDU (to fill whole OFDMA slots). It is the
responsibility of the receiving BS MAC to discard the padding. FEC blocks are constructed according
to modulation and coding connected with a given burst profile as defined in received UL-MAP for the
current frame. The PHY SDU has a 1:1 mapping to the UL burst.
The SS MAC Layer UL scheduler is responsible for grouping MAC PDUs into sets forming bursts at
the PHY Layer. The PHY will therefore perform a simple sequential processing of the transmitted MAC
PDU groups, according to TXVECTOR contents (equivalent to received UL Map).
MAC Message SDU SDU 1 SDU 2
PHY SAP Fragmentation Packing
MAC PDU 1 MAC PDU 2 MAC PDU 3 MAC PDU 4 MAC PDU 5
Concatenation
PHY SDU 1 PHY SDU 2 PHY SDU 3 PHY SDU 4
Bursts P FEC Block1 FEC Block2 FEC Block3 FEC Block4 FEC Block5 F
FEC Block6 FEC Block7
P Preamble F Filler
Figure 4-1: MAC PDU transmission
4.2.3 Downlink and Uplink Burst Profiles Setup

The set up of Downlink and Uplink Burst profiles is accomplished by the MAC layers of the BS. The
base station PHY layer does not have direct involvement for these tasks and is not aware of the burst
profiles.
4.2.4 Downlink Subframe Setup

At the BS, the MAC sends a PHY_TXSTART.request primitive to the BS PHY. This primitive conveys
the structure of the downlink subframe (in the form of TXVECTOR), including all information required
by the PHY that is encoded into the DL Map. After receiving the PHY_TXSTART.request primitive, the
BS PHY responds with the PHY_TXSTART.confirmation to acknowledge the reception of the
PHY_TXSTART.request.

The scenario is shown in Figure 4-2 along with the corresponding SS receiver setup. Note that the
exchange of PHY_TXSTART.request and .confirmation primitives occurs before the start of frame
transmission. If the RX_START.request primitive is segmented, the .confirmation is expected after the
reception of the last .request segment.
4.2.5 PHY SDU Transmission from BS MAC to PHY

After receiving the PHY_TXSTART.confirmation primitive, as illustrated in Figure 4-2, the BS MAC
sends the BS PHY a PHY_TXSDU.request primitive for each data burst contained in the current DL
subframe. Each PHY_TXSDU.request primitive corresponds to one of the bursts described in the
subframe description (TXVECTOR) sent as part of the PHY_TXSTART.request primitive. The
PHY_TXSDU.request primitive carries the burst data and control information to allow the PHY to
correlate this burst with the corresponding description in the PHY_TXSTART.request. It should be
noted that the FCH, DL Map, and UL Map are all considered data bursts and are send to the PHY in a
PHY_TXSDU.request primitive.
The protocol can operate in one of two modes. In the first mode, the PHY, after buffering the last
segment of received PHY_TXSDU.request, responds with the primitive PHY_TXSDU.confirmation to
indicate that the data have been buffered for transmission. This .confirmation message is used to
implement message-level flow control between the MAC and PHY. When running in this mode, the
MAC does not send the next PHY_TXSDU.request until it has received the PHY_TXSDU.confirmation
for the last request. In the second mode, PHY_TXSDU.confirmation messages are not used. In this
mode the MAC is free to send PHY_TXSDU.request messages at whatever rate it wishes.
The PHY_TXSTART.indication is sent at the beginning of each downlink subframe. The
PHY_TXSTART.indication is used to provide coarse synchronization between the PHY and the MAC.
It allows the MAC to track the start of each DL frame.
After transmitting the last symbol of the DL subframe, the PHY sends a PHY_TXEND.indication
primitive to the MAC to indicate the end of transmission for this particular frame. This scenario is
shown in Figure 4-2. Note that an abbreviated form of the primitives names is used.
Note: Possible .request message segmentation not shown. The .confirmation (if used) is expected
after the last .request segment.

Figure 4-2: Example of using PHY_TXSDU for BS transmitting
4.2.6 Uplink Subframe Setup

At the start of each frame before the PHY is to begin receiving data, the BS MAC sends a
PHY_RXSTART.request primitive to the PHY. This primitive contains a description of the structure and
expected contents of the UL subframe (in the form of the RXVECTOR). The RXVECTOR includes all
information contained in the UL Map required by the PHY in order to received and decode the bursts
contained in the subframe. The MAC is responsible for sending the PHY_RXSTART.request message
early enough to allow the PHY to decode its contents in time to begin receiving the first symbol of the
UL subframe. After receiving the PHY_RXSTART.request primitive, the PHY responds with the
PHY_RXSTART.confirmation primitive. The scenario is shown in Figure 4-3 along with SS
transmission setup. Note that an abbreviated form of the primitives names is used. Note also that the
exchange of PHY_RXSTART.request and .confirmation primitives can occur before the BS PHY
receiver is ready to begin receiving the frame.
Note: Possible .request message segmentation not shown. The .confirmation is expected after the last
.request segment.

4.2.7 PHY PDU Reception from BS PHY to MAC

Having received the PHY_RXSTART.request primitive, the BS PHY knows the structure and precise
start time of bursts within the UL subframe. The PHY receives symbols from the UL subframe and
demodulates/decodes the bursts contained within the subframe. For each uplink burst, PHY sends the
PHY_RXSDU.indication primitive along with payload data and status information that allows the MAC
to identify this burst within the subframe and access receiver information such as timing, frequency
offset, etc. In the event that a burst cannot be decoded due to errors, the PHY sends a
PHY_RXSDU.indication primitive with no burst data, indicating that there was an error receiving this
particular burst.
Protocol-level flow control is not defined for the transmission of PHY_SDU.indication primitives. It is
assumed that the MAC can receive all of the primitives for a UL subframe at line rate, and the PHY is
free to send the primitives as they become available. The scenario is shown in Figure 4-3.
Note: Possible .indication message segmentation not shown.
Figure 4-3: Example of using PHY_RXSDU for BS receiving
When the BS PHY begins to receive UL subframe data, it sends the PHY_RXSTART.indication
primitive to the MAC to indicate the timing of this event. After sending the last PHY_RXSDU.indication
primitive associated with the current UL subframe, the PHY sends the PHY_RXEND.indication
primitive to indicate the end of the subframe. These scenarios are also shown in Figure 4-3.
4.2.8 CDMA Codes Reception

An SS transmits CDMA codes for ranging and bandwidth allocation purposes, in contention slots
allocated by BS. Processing of CDMA codes at the BS PHY is time-consuming, and may last longer

than one subframe. The RX_CDMA.indication primitive is sent to the BS MAC outside the context of
the PHY_RXSTART.request primitive and the corresponding PHY_RXEND.indication primitive.
Because transmission slots for CDMA are not granted per particular SS, but rather are allocated for an
‘anonymous’ subscriber, the communication SS – BS using the CDMA code is performed in a different
way as compared to a regular data bursts exchange. To correctly react to a particular CDMA code, BS
must maintain history of previous allocations (containing frame number, zone type, etc.). The arriving
CDMA code is placed by BS PHY into RXCDMA.indication together with information enabling the BS
MAC to associate the CDMA code with the previous allocation, and correctly react (in some cases by
generating a response to the sender of a particular CDMA code). This requires that PHY keeps
information about allocated CDMA regions (as defined in RXVECTOR) until all CDMA codes from a
given frame are processed. The MAC must maintain information on previous CDMA allocations for
some time (implementation specific), to correctly interpret the incoming RXCDMA.indication. To
facilitate this processing, MAC assigns ZoneXID for UIUC 12 allocation area, and PHY reports with
RXCDMA.indication this ZoneXID.
4.3 Generic Message Header, Format, and Coding

All PHY SAP primitives are translated into messages by prefixing the segmentation header, as defined
in Table 4-2. Each segment contains appropriate message type field, uniquely identyfying given PHY
SAP primitive.
Table 4-2: 802.16 PHY SAP Message Header
0 31:26 6 bits PHY entity ID (sector, antenna, carrier, etc.)
0 25:24 2 bits Message Segmentation bits

00: Middle segment of the message segment sequence
01: Last segment of the message segment sequence
10: First segment of the message segment sequence
11: The entire message is contained in this segment
0 23:16 8 bits Message type
0-… … … Message body fragment
The PHY entity ID is supplied by the Control Plane during the initialization to both MAC and PHY
layers. This identifier allows the MAC to communicate with multiple PHY instances.
The message type values are known to both PHY and MAC. The segmentation bits are used to
correctly reassemble fragmented messages. It is recommended that payload is split into fragments at
32 bits boundary.
In the case of the Intel® IXP2XXX product line of network processors, the messages are always
transferred over IXP2XXX Media Switch Fabric (MSF) as single SOP/EOP segments. This is true both
in the case of ‘native’ transfer (i.e., when PHY is connected directly to IXP2XXX via SPI) and in the
case when messages are sent encapsulated via Ethernet. Each such segment holds either entire
message or a portion of the message. The Message Segmentation bits in the message header convey
the information which logical message segment is being transferred in the MSF segment (entire
message, first, middle, or last).
The IXP2XXX network processor offers just a few (configurable) MSF segment sizes which can be
either 64, 128 or 256 bytes. The used MSF segment length is arbitrary; a commonly used value is 128
bytes. When a message spans more than a single segment, it is allowed to transfer within each
segment a portion of the message shorter than the MSF segment length (i.e., it is not required that first
and middle segments fill the MSF segment completely). Some PHY implementations may require the
intermediate segments to be multiples of 16-bit or 32-bit words, however. Note that SPI interface

provides to a receiver the length of just received data segment – this is the basic method of learning
the message segment length. The Ethernet encapsulation carries the segment length information in
the Payload Length field of the encapsulation header.
4.3.1 Message Type Field Coding

Each primitive is assigned a unique message type, specified in Table 4-3.
Table 4-3: Type Field Coding
Value Description
0 Reserved
1 PHY_TXSTART.request
2 PHY_TXSTART.confirmation
3 PHY_TXSTART.indication
4 PHY_TXSDU.request
5 PHY_TXSDU.confirmation (optional)
6 PHY_TXEND.indication
7 PHY_RXSTART.request
8 PHY_RXSTART.confirmation
9 PHY_RXSTART.indication
10 PHY_RXSDU.indication
11 PHY_RXEND.indication
12-14 Reserved (OFDM)
15 PHY_RXCDMA.indication
16-17 Reserved (OFDMA SS)
18-255 Reserved
The confirmations marked as ‘optional’ must be configured in the same way on both sides (PHY and
MAC) as either enabled or disabled and cannot be changed at run-time.

4.3.2 Error Code Field Coding

In this document, the following error code (ERRORCODE) are defined, to provide the cause of errors
that occur in communications between the MAC and the PHY. The error code is generic and can be
applied to applicable PHY SAP primitives. The ERRORCODE is an 8-bit value.
Table 4-4: Error Code (ERRORCODE) Field Coding
Value Description
0 Success
1 Primitive is not supported (for requests); Restart flag (for TXSTART.indication)
2 FEC code type is not supported
3 Overrun
4 Underrun
5 Transport Media Error
6 TX data size do not match TXVECTOR
7 Invalid RX/TX VECTOR format
8-255 Reserved

5 PHY SAP Primitives

In this section we specify the format of each of the primitives exchanged across the PHY SAP
interface. The message segmentation header is shown with each primitive for convenience.
5.1 PHY_TXSTART.request
Table 5-1: PHY_TXSTART.request
0 31:24 8 bits Message Segmentation Header
0 23:16 8 bits Message type = 1
0 15:0 16 bits Length of TXVECTOR
TXVECTOR
This primitive is issued by the MAC to request the BS PHY to start the transmission of PHY PDUs in
the nearest DL subframe, and carries all the control information needed for the local PHY, such as
start and end times of transmission and PHY parameters for multiple bursts, types of preambles, etc.
As a result of the reception of this primitive, the PHY sends a confirmation primitive, and at the proper
moment, starts transmission of the PHY PDUs or performs requested actions as defined by the control
information contained in TXVECTOR. The TXVECTOR corresponds to the DL-Map currently being
sent to remote SS. The TXVECTOR contains only those DL-Map parameters which are necessary for
PHY to perform correct transmit actions.
The BS version of the TXVECTOR is formatted as shown in Section 3.4.
As a convention, the first BS expected burst, containing FCH (DLFP) is numbered as 0 (zero); the next
bursts, holding PHY SDUs are numbered starting from 1. For each subsequent zone the numbering of
bursts is restarted from 1. The Length field contains entire TXVECTOR length and is replicated in all
segments of the PHY_TXSTART.request message.
PHY randomization is done using the OFDMA Symbol Offset and Subchannel Offset fields.
5.2 PHY_TXSTART.confirmation
Table 5-2: PHY_TXSTART.confirmation
0 15:8 8 bits Status

Success = 0
Fail = ERRORCODE
0 3:0 4 bits Next Frame Number (lsb) – from TXVECTOR

This primitive issued by the PHY confirms reception of PHY_TXSTART.request primitive and provides
the command execution status to the MAC. If the PHY was not able to process the
PHY_TXSTART.request primitive it returns an error code (ERRORCODE) to indicate the issue. Note
that the PHY_TXSTART.confirmation is sent after the last segment of received
PHY_TXSTART.request. This confirmation is mandatory. The Frame Number field is typically used by
TX state machine to trace events regarding the given frame.
5.3 PHY_TXSTART.indication
Table 5-3: PHY_TXSTART.indication

Success = 0 (normal operation) or 1 (during initialization)
Fail = ERRORCODE
0 7:4 4 bits Extended frame number if == 1; if == 0 only LW 0 is present
0 3:0 4 bits Current Frame Number (lsb) – from TXVECTOR
1 23:0 24 bits Initial Frame Number (from PHY)
This primitive is issued by the PHY to indicate to the MAC that the DL subframe has just started. This
primitive is sent once per frame. It is used to enforce and maintain synchronization between the PHY
and MAC on a frame by frame basis.
This primitive is also used to achieve initial synchronization between the PHY and the MAC. After the
PHY is initialized (or restarted) it periodically transmits this primitive at frame start time of each frame.
The PHY sets the status field to a value of 1 to indicate that this is an initial synchronization event.
Until PHY enters normal operation mode, it should continue sending just TXSTART.ind with status = 1
(and Current Frame Number = 0). The PHY enters normal operation mode after receiving first
PHY_TXSTART.request from the MAC. From this time on, subsequent PHY_TXSTART.indications are
normally sent with a status field value of 0 and Current Frame Number field taken from TXVECTOR.
The Current Frame Number field is typically used by MAC TX state machine to trace events regarding
the given frame.
When using extended frame number format, PHY can provide Initial Frame Number, which can be
used by MAC to initialize its Frame Number counter.
This primitive may signal an Underrun error, in the case that the expected PHY_TXSTART.request, or
related PHY_TXSDU.request primitives do not arrive on time.
5.4 PHY_TXSDU.request
Table 5-4: PHY_TXSDU.request

0 15:13 3 bits DL zone number (counted from 0)
0 12:10 3 bits Sub-burst/burst split point (from msb to lsb)

000: all 10 bits for burst number
001: 1 bit sub-burst and 9 bits burst number
0 9:0 10 bits DL sub-burst/burst number in this zone (starting from 0)
1-… … … PHY SDU
This primitive issued by MAC transfers a PHY SDU to the PHY and requests the transmission of this
SDU within the nearest DL frame. It is generated after the corresponding PHY_TXSTART.request
primitive. The PHY should accumulate the total length of each burst (summarizing PHY SDU segment
lengths from PHY messages) and compare it with the length taken from the TXVECTOR. If it detects
unexpected difference it should indicate an error in the PHY_TXEND.indication primitive. The first
burst (number 0) in the first zone contains the FCH (DLFP). Subsequent bursts carry regular PHY
SDUs. The zone/burst/sub-burst numbering field is present in all segments of PHY_TXSDU.request
message.
5.5 PHY_TXSDU.confirmation
Table 5-5: PHY_TXSDU.confirmation
0 15:13 3 bits DL zone number (counted from 0)
0 12:10 3 bits Sub-burst/burst split point (from msb to lsb)

000: all 10 bits for burst number
0 9:0 10 bits DL sub-burst/burst number in this zone (starting from 0)
1 31:16 16 bits Reserved empty field (=0) for long word alignment
1 15:8 8 bits status


Success = 0
Fail = ERRORCODE
1 3:0 4 bits Next Frame Number (lsb) – from TXVECTOR
The PHY_TXSDU.request primitives are serviced in one of two modes. The mode in which the PHY
and MAC operate is selected at initialization time and it not changed during run time. In the case that a
single MAC controls more than one PHY entity, all PHY entities are required to operate in the same
mode.
In the first mode, the PHY_TXSDU.confirmation primitive is issued by the PHY after receiving the last
segment of a PHY_TXSDU.request primitive. It confirms that the PHY is ready to receive the next
PHY_TXSDU.request primitive. The status parameter may represent “success” or “failure.” The
“failure” may appear, for example, in the case when the PHY runs out of a buffer space (this is typically
considered as a ‘hard error’). The error code is included in the primitive to indicate the problem. The
Frame Number field is typically used by TX state machine to trace events regarding the given frame.
In the second mode, the MAC sends PHY_TXSDU.request primitives at whatever rate is convenient
(without any flow control from the PHY). In this mode, the PHY_TXSDU.confirmation primitive is not
used.
5.6 PHY_TXEND.indication
Table 5-6: PHY_TXEND.indication

Success = 0
Fail = ERRORCODE
0 7:4 4 bits PHY request (LW 1)

0000 – LW 1 not present
0001 – AAS calibration request present in LW 1
0 3:0 4 bits Current Frame Number (lsb)
1 31:24 8 bits Requested AAS Calibration Zone size (in symbols, at end of DL
subframe)
1 23:20 4 bits Requested AAS Calibration Zone allocation deadline (in seconds)
1 19:16 4 bits Number of consecutive frames with AAS Calibration Zone allocation

This primitive is issued by the PHY to indicate the transmission of the last symbol in the DL subframe
(at PHY DSP level) triggered by the PHY_TXSTART.request primitive. The error code is set to indicate
possible transmission problems within DL subframe. The Frame Number field is typically used by TX
state machine to trace events regarding the given frame. This primitive can also be used by PHY to
request scheduling of a calibration action from MAC (the calibration can be made over several
consecutive frames).
5.7 PHY_RXSTART.request
Table 5-7: PHY_RXSTART.request
0 15:0 16 bits Length of RXVECTOR
RXVECTOR
This primitive is issued by the MAC to request the BS PHY to start the reception of the nearest UL
subframe, as defined by AllocationStartTime contained in the RXVECTOR (see Table 3-23). The
RXVECTOR carries all of the control information required by the PHY to receive and decode the UL
data bursts. After receiving this primitive, the PHY sends a confirmation primitive and at the proper
moment begins to receive and decode UL symbols. The RXVECTOR corresponds to the the UL-Map
sent to the remote SSs in the previous frame. It contains only those UL-Map parameters which are
necessary for the PHY to perform correct receive actions. In particular, PHY is given absolute FEC
code types corresponding to current UCD mapping. Note that for the first frame the RXVECTOR is
empty.
The BS version of the RXVECTOR is formatted as specified in Section 3.5.
The RXVECTOR elements correspond to the uplink bursts provided by PHY for reception. As a
convention, the expected bursts holding PHY SDUs are numbered starting from 1. For each
subsequent zone the numbering is restarted from 1. The Length field contains entire RXVECTOR
length and is replicated in all segments of the PHY_RXSTART.request message.
PHY randomization is done using the OFDMA Symbol Offset and Subchannel Offset fields.
5.8 PHY_RXSTART.confirmation
Table 5-8: PHY_RXSTART.confirmation
0 15:8 8 bits Success = 0

Fail = ERRORCODE
0 3:0 4 bits Frame Number (lsb) – from RXVECTOR (BS: Next frame in air )

This primitive is generated by the PHY after it has received and processed a complete
PHY_RXSTART.request primitive. It provides a confirmation of the reception of the request the
command execution status to the MAC. If the execution is not successful, the PHY returns an error
code (ERRORCODE) to indicate the issue. This confirmation is mandatory. The Frame Number field is
typically used by RX state machine to trace events regarding the given frame.
5.9 PHY_RXSTART.indication
Table 5-9: PHY_RXSTART.indication

Success = 0
Fail = ERRORCODE
This primitive is issued by the PHY to indicate to the MAC the actual start of the UL subframe. The
PHY generates this primitive in normal operation mode (after receiving first PHY_RXSTART.request
from the MAC). The Frame Number field is used by RX state machine to trace events regarding the
given frame.
5.10 PHY_RXSDU.indication
Table 5-10: PHY_RXSDU.indication

(signed) with specific SS11),
1 31:31 1 bits Integrity 0 (valid data), 1 (invalid data) – meaningful for HARQ data
bursts only
1 30:0 31 bits Number of bytes received (including possible padding) or planned to be

received (when ‘invalid data’)
11
If PHY does not support this feature, alternatively this field can contain UL zone/burst/sub-burst
number in this zone – coding utilize convention as described in section 5.4

2 31:24 8 bits RSSI per subcarrier level (-150dBm to -22.5dBm), unsigned, 0.5 dBm
step size [0..255]
2 23:16 8 bits CINR (-10 dB to 53 dB), signed, 0.5 dB step size [-20..+106]
2 7:0 8 bits Power Offset (-31.75 dB to +31.75 dB), signed, 0.25 dB step size [-
127..+127]
3 31:28 4 bits Current Frame Number (lsb) copied from RXVECTOR
3 27:24 4 bits ACID for HARQ data bursts; 0 otherwise
3 23:20 4 bits Indication Type (0 = Data burst, 1= HARQ ACK channel, 2 = Fast
Feedback Channel, 3 = HARQ data burst, 4 = MIMO data burst, 5 =
MIMO HARQ data burst, other values reserved)12
3 19:17 3 bits Zone Permutation Type

000: PUSC
001: Optional PUSC
010: AMC – 1 x 6
011: AMC – 2 x 3
100: AMC – 3 x 2
101-111: reserved
3 16:16 1 bits Update AAS handle in MAC (if = 1)
3 15:0 16 bits AAS Handle (NULL if not known/assigned; used for TX)
4 31:0 32 bits Time deviation in units of 1/Fs: signed
5 31:0 32 bits Frequency deviation in Hz: signed
6-… … … Indication Type-dependent data (PHY SDU if Indication Type = 0)
The primitive is generated by the PHY to send the contents of a received PHY SDU from the PHY to
the MAC. The PHY generates this primitive in normal operation mode (after receiving first
PHY_RXSTART.request from the MAC). The ‘UL burst number in this frame’ (if present) contains the
UL burst number as assigned for regular data bursts for a given zone in RXVECTOR.
The primitive includes a set of PHY indicators that figure the result of the whole PHY activity triggered
by this particular UL burst, including the received signal quality. This status information is used by the
BS-implemented link adaptation and power control algorithms.
The ISSID field is present in all segments of the PHY_RXSDU.indication, while the remaining status
fields are present in the first (or only) message segment.
12
This field can be used to speed-up Rx processing at MAC, if supported by PHY. MAC can still
retrieve the type information from the current RXVECTOR, but such approach takes more processing
cycles on Rx.

The PHY_RXSDU.indication primitive is sent to the MAC for every UL burst even when the burst could
not be decoded. This ensures proper protocol handshaking between the MAC and PHY. The Frame
Number field is typically used by RX state machine to trace events regarding the given frame.
The received PHY SDU data is sent in one of the following formats, depending on the type of burst.
• Data burst – Received data is passed as an array of bytes in network byte order.
• HARQ ACK Channel – data is passed as an array of structures where each structure contains
an ACK/NACK indication from one channel in the allocation. The order of the ACK/NACK
indications in the array matches the order of the HARQ ack channels as specified in the
standard.
• Fast Feedback Channel - – data is passed as an array of structures where each structure
contains the feedback received in one channel in the allocation. The order of the feedback
items in the array matches the order of the fast feedback allocations as specified in the
standard.
The different types of burst formats carry the following specific parameters (in addition to the common
ones):
• Special Channel
• Burst data (decoded according to the standard) MAC must parse out the individual
channels.
• Data burst
• Number of bytes received
• RSSI
• CINR
• Frequency Offset
• Time of Arrival Offset
• Power Offset
• Burst Data
Table 5-11 shows the HARQ ACK channel data format.
Table 5-11: HARQ ACK channel data format
6 31:16 16 bits ISSID

(signed)
6 15:12 4 bits ACID
6 9:9 1 bit ACK Valid: 0 (valid data), 1 (invalid data)
6 8:8 1 bit 1 = ACK; 0 = NAK
7 (next items from the HARQ ACK channel, if any)
Table 5-12 shows the Fast Feedback channel data format.

Table 5-12: Fast Feedback channel data format
6 31:16 16 bits ISSID

(signed)
6 15:0 16 bits CQICH_ID

(up to 9
bits
used)
7 31:24 8 bits Feedback type coding

00000001: 3 bit-MIMO Fast-feedback
00000010: Enhanced FAST_FEEDBACK
00000100: reserved
00001000; reserved
00010000: UEP fast-feedback
13
00100000: A measurement report performed on the last DL burst
01000000: Primary/Secondary FAST_FEEDBACK
10000000: DIUC-CQI Fast-feedback
7 23:23 1 bit Feedback Valid: 0 (valid data), 1 (invalid data)
7 22:20 3 bits Feedback sub-type

0 – CQI (CINR) measurement
1 – Control feedback
7 7:0 8 bits Feedback value (number of bits used depends on feedback type)
8 (next items from the Fast Feedback channel, if any)
5.11 PHY_RXEND.indication
Table 5-13: PHY_RXEND.indication

Success = 0
Fail = ERRORCODE
0 7:4 4 bits PHY AAS report present
13
See IEEE 802.16-2005 specification, section 8.4.5.4.10.1


0000 – not present (only LW 0 is significant)
0001 – AAS info aged out report present
1 31:24 8 bits Number of affected SS
1 15:0 16 bits ISSID of the SS for which the AAS info has been aged out
(signed)
…(next ISSIDs if any)
This primitive is issued by the PHY to indicate that no more RXSDU.indications sent from PHY to MAC
can be expected for this particular UL subframe (as defined by the proceeding
PHY_RXSTART.request). The status for this primitive applies to the entire UL subframe, not to any
individual UL burst. The error code and the statistics for each UL burst are sent to MAC in the
PHY_RXSDU.indication primitive. The primitive may contain a list of ISSIDs of the SS for which their
AAS info has aged out. The Frame Number field is typically used by RX state machine to trace events
regarding the given frame.
5.12 PHY_RXCDMA.indication
Table 5-14: PHY_RXCDMA.indication
0 15:0 16 bits ZoneXID
1 31:24 8 bits CDMA code
1 23:16 8 bits CDMA symbol
1 7:0 8 bits CDMA subchannel
2 31:24 8 bits RSSI per subcarrier level (-150dBm to -22.5dBm), unsigned, 0.5 dBm
step size [0..255]
2 23:16 8 bits CINR (-10 dB to 53 dB), signed, 0.5 dB step size [-20..+106]
2 7:0 8 bits Power Offset (-31.75 dB to +31.75 dB), signed, 0.25 dB step size [-
127..+127]
3 31:28 4 bits Current Frame Number (lsb) copied from RXVECTOR

3 15:0 16 bits AAS Handle (NULL if not known/assigned; used for TX)
4 31:0 32 bits Time deviation in units of 1/Fs: signed
5 31:0 32 bits Frequency deviation in Hz: signed
The primitive is issued by the BS PHY to indicate to the MAC that a CDMA code has been received in
a specific ranging slot. The PHY generates this primitive in normal operation mode (after receiving first
PHY_RXSTART.request from the MAC). This primitive includes a set of PHY indicators that are used
for the CDMA type ranging or bandwidth reservation process. The Frame Number field is typically
used by RX state machine to trace events regarding the given frame.
ZoneXID helps MAC placing the next UIUC=14 allocation in the same zone where the originating
UIUC=12 allocation was performed.
In the UL there are the following types of CDMA Burst Formats:
• Initial Ranging/Handover Ranging/Periodic Ranging
• Bandwidth Request

6 PHY SAP Messages over SPI

The PHY SAP natively uses the IXP2XXX MSF SPI interface as transport. In this case no additional
special encapsulation is needed and the max message size equals to the MSF selected segment size.

7 PHY SAP Messages over Ethernet

As mentioned in the previous chapter, the PHY SAP natively uses the MSF SPI interface as transport.
There are, however, certain cases when passing the PHY SAP messages over Ethernet would be
beneficial. For example, an external PHY simulator may be utilized to perform verification testing of the
802.16 MAC layer. It can also be used as the basic medium for MAC-PHY communication.
The Ethernet II format has been selected for PHY SAP message encapsulation. The Ethertype field is
set to 0x08FF, indicating PHY SAP v 2.xx encapsulation (i.e., the OFDMA version). To avoid
problems with frames shorter than 60 bytes (Ethernet II limitation), an additional 2 byte field was
introduced. It carries information about the packet length. This encapsulation is depicted in Figure 7-1.
Note that the encapsulated PHY SAP message segment must not exceed the selected MSF segment
length. Therefore, the max. allowed message segment length is different with and without the Ethernet
encapsulation:
• Without encapsulation, the max PHY SAP segment length equals to MSF segment length
• With encapsulation, the max PHY SAP segment length equals to MSF segment length – 16
Note the MSF segment holds entire Eth packet without 4-byte FCS (which is generated by Eth MAC
hardware).
A description of the Ethernet encapsulation header contents (total 16 bytes) is as follows:
• Ethernet Dst MAC address [6 bytes] – address of 802.16 MAC or PHY
• Ethernet Src MAC address [6 bytes] – address of 802.16 PHY or MAC
• Ethernet Type [2 bytes], fixed value 0x08FF (the number currently unused at IANA)
• Packet Length [2 bytes]: includes 16-byte encapsulation header and PHY SAP message
segment length.
Payload, holding PHY SAP message segment can contain from 1 to (MSF segment length –16) bytes.
In order to ease the task of distinguishing RX primitives from TX primitives (at simulated or real PHY),
different MAC addresses are proposed for each primitives group. The default Ethernet MAC Address
values are given below.
• RX primitives: 802.16 MAC Eth Address = xx:xx:xx:xx:yy:03
and 802.16 PHY Eth Address = xx:xx:xx:xx:yy:01
• TX primitives: 802.16 MAC Eth Address = xx:xx:xx:xx:yy:02
and 802.16 PHY Eth Address = xx:xx:xx:xx:yy:00
The ‘xx:xx:xx:xx’ address part is user selectable. The ‘yy’ is set equal to PHY entity ID. The final byte
of the address identifies MAC or PHY side and RX or TX primitives.
Figure 7-1: PHY SAP Ethernet encapsulation


Phy Sap Api

Uploaded by

Copyright:

Available Formats

Phy Sap Api

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Phy Sap Api

Uploaded by

Copyright:

Available Formats

OFDMA PHY SAP Interface Specification

for 802.16 Broadband Wireless Access

12/17/2004 Initial draft for OFDMA PHY SAP 2.00

12/10/2005 Editorial changes. Added support for HARQ flush 2.24

12/15/2005 Expected length (taken from RXVECTOR) is reported 2.25

04/27/2006 Editorial changes – text clarifications 4.3, 5.1, 5.4, 2.27

Page 2 of 75 Intel Corporation

and general beamforming. Moved placement of AAS

05/22/2006 Sub-bursts descriptors include modulation/coding 2.28

09/06/2006 Added Initial Frame Number clarification in Section 2.29

02/07/2007 Added new Burst Type, ‘Control Command’ to 2.30

03/30/2007 Extended PAPR/Safety Zone Channel Specific Part of 2.31

Intel Corporation Page 3 of 75

Page 4 of 75 Intel Corporation

3.4.5 Downlink Frame Descriptor Usage Notes .....................................................................39

Intel Corporation Page 5 of 75

6 PHY SAP Messages over SPI ....................................................................................................73

Page 6 of 75 Intel Corporation

Intel Corporation Page 7 of 75

Page 8 of 75 Intel Corporation

1 Purpose of this Specification

Intel Corporation Page 9 of 75

EOP End Of Packet

Page 10 of 75 Intel Corporation

Intel Corporation Page 11 of 75

2 PHY SAP Introduction

2.1.1 Base Station Reference Model

Includes Antennas, LNA,

Figure 2-1: BS Reference Model

Page 12 of 75 Intel Corporation

Multi-Sector Base Station

Single-Sector Base Station

Figure 2-2: Example BS implementations

2.1.2 MAC-PHY Protocol Overview

Intel Corporation Page 13 of 75

Page 14 of 75 Intel Corporation

3 Base Station Frame Descriptors

3.1 Frame Structure

Figure 3-1: Typical OFDMA TDD frame format

Intel Corporation Page 15 of 75

3.1.1 Downlink Subframe Structure

3.1.1.1 Downlink Zones

3.1.1.2 Downlink Bursts

3.1.1.2.2 Downlink Maps

Page 16 of 75 Intel Corporation

Figure 3-2: DL map allocations

3.1.1.2.3 Normal Data Bursts

3.1.1.2.4 Uplink Map

3.1.1.2.5 PAPR Allocation

3.1.1.2.6 Sub-Allocation Data Bursts

Intel Corporation Page 17 of 75

Figure 3-3: Downlink sub-allocation data burst

3.1.2 Uplink Subframe Structure

3.1.2.2 Uplink Bursts

3.1.2.2.1 HARQ ACK Channel

Page 18 of 75 Intel Corporation

3.1.2.2.2 Fast Feedback Channel

3.1.2.2.3 Ranging Regions

Figure 3-4: Ranging allocation