IEEE C802.16m-09/0521
http://ieee802.org/16
Hua.xu@motorola.com
This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups . It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16.
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< http://standards.ieee.org/guides/bylaws/sect6-7.html#6 > and
< http://standards.ieee.org/guides/opman/sect6.html#6.3
>.
Further information is located at < http://standards.ieee.org/board/pat/pat-material.html
> and
< http://standards.ieee.org/board/pat >.
1 Introduction
In this contribution, we propose MAC PDU and ARQ design. The design includes
MAC PDU formation,
MAC sequence number,
ARQ feedback mechanism, sub-sequencing scheme for ARQ re-arrangement.
2 Text Proposal
================= Start of Proposed Text ========================
15.2 Medium access control
15.2.1 MAC PDU Format
1

IEEE C802.16m-09/0521
MAC PDUs shall be of the form illustrated in Figure XXX. Each PDU shall begin with a fixed-length MAC header. The header may be followed by zero or more extended headers and Payload of the MAC PDU. If payload is present, the payload shall consist of one or more MAC SDUs and/or fragments thereof from the same flow. The MAC payload is called a MAC data block, which is also called an ARQ block when ARQ is present. The MAC data block may vary in length, so that a MAC PDU may represent a variable number of bytes. No MAC PDU CRC will be used.
Header Extended Headers Payload
Figure XXX MAC PDU Format
Multiple MAC PDUs are concatenated into a HARQ burst followed with HARQ CRC as shown in Figure YYY. Security related information may also include in the HARQ burst, which is not depicted in the figure. The security information may include security header, PN, EKS, etc.
MAC PDU #1 MAC PDU #2 … MAC PDU #n HARQ CRC
Figure YYY HARQ Burst Format
15.2.2 MAC data block sequence number (MSN)
The MAC data blocks are numbered sequentially using MAC sequence number (MSN). This is used to replace the BSN, fragmentation SN, and PDU SN, which are defined in previous version of the standards. The MSN will wrap around at
MSN_Modulus. The MSN is designed for MAC data block re-sequencing and ARQ retransmission window management. The
MSN_modulus can be set to the following set of numbers, Table XXX, depend on the nature of the traffic. If it is used for real-time traffic with small packet delay, the small MSN_Modulus number is recommended since there won’t be a lot of MAC data blocks outstanding at the same time. If ARQ is enabled and high data rate traffic is expected, large MSN_Modulus number is recommended so the ARQ_Window_Size will be large enough to prevent window stall.
Table XXX MSN_Modulus Values
MSN_Modulus Values Bits needed to represent the MSN
32 5
128
256
512
7
8
9
1024
2048
10
11
In the case that ARQ is enabled, the MSN_Modulus needs to be at least twice as large as the ARQ-Window_Size.
Packing and fragmentation of the MAC SDU may be indicated using first fragment indication (FFI) bit and packing extended header as illustrated in Figure ZZZ.
2

SDU #1 SDU #2
IEEE C802.16m-09/0521
SDU #3
SDU #3
MAC Data Block SN #
FFI
0
1
1
0
2
0
3
0
4
0
For this MAC data block, packing extended header is also needed
Figure ZZZ MAC PDU Formation
15.2.3 ARQ feedback mechanism
Two ARQ feedback mechanisms are available, polling based and timer based. When the transmitter resides at the ABS, polling is recommended for ARQ window flow control. The transmitter (at ABS) will initiate a polling message based on the status of its ARQ window. The polling message requests the receiver (at AMS) to send an ARQ feedback payload, which can be either cumulative or selective. An UL bandwidth allocation shall be placed along with the polling request for the feedback to be sent via UL. When the transmitter resides at the AMS, a periodic polling timer shall be negotiated and established between the transmitter and receiver. The receiver (at ABS) shall send feedback payload (cumulative or selective) to the transmitter (at AMS) to prevent ARQ transmission window stall. In case a temporary polling is needed from the transmitter at AMS, the AMS can send general bandwidth request and use the granted bandwidth to send polling message.
For data transmission, since HARQ is mandatory, ARQ shall utilize HARQ feedback to enable fast ARQ retransmission. HARQ
NAK shall be considered as NAK for all the MAC PDUs in the HARQ burst, therefore for all the MAC data blocks (ARQ blocks) in those MAC PDUs. The ARQ_RETRY_TIMEOUT timer shall be set accordingly to allow the completion of the HARQ retransmission process, which can be calculated as the HARQ maximum retransmission delay times the HARQ maximum number of retransmissions. These timer/parameters shall be known and negotiated between the transmitter and receiver.
.
15.2.4 Sub-sequence scheme for ARQ re-arrangement
When an ARQ block transmission fails, a retransmission may be scheduled with or without re-arrangement. In case no rearrangement is used, the same ARQ block will be re-transmitted by the lower layer, i.e., HARQ. If the re-arrangement is used, the
MAC data block or ARQ block will be reconstructed, likely will form multiple sub-blocks for lower layer retransmission. Due to this sub-fragmentation, the original MAC data block sequence number (MSN) can not be used for the sub-block re-assembly. At the receiver, in order to reassemble the sub-blocks back to the original ARQ block, a sub-sequence numbering scheme is needed. For instance, if the MSN = X fails after the HARQ process, and the MAC data block X is sub-fragmented into Y sub-blocks, the receiver needs to know which block is the sub-block of X and how many sub-blocks in total. Additionally, since no in sequence delivery capability exists at lower layer, HARQ, a sub-sequence index (SSI) for each sub-block needs to be sent to the receiver along with the sub-block.
The first SSI value equals the total number of sub-blocks. Subsequent SSI values are incremented by 1. For example, for total of Y sub-blocks, the SSIs are Y, Y+1, …, 2Y-1 . By doing this, it avoids the need to indicate in each sub-block a total number of sub-blocks since the smallest SSI implicitly indicates the total number of sub-blocks. The receiver validates that all sub-blocks by comparing the total number of sub-blocks received Z with the smallest SSI received W . If W = Z , then all of the sub-blocks of X are received, otherwise, not. An example of this sub-sequencing index scheme is illustrated in Table YYY.
Table YYY ARQ Retransmission Sub-Sequencing Index Scheme
3

Y=
SSI values:
1 2 3 4 4
1
2
3 3
4 4 4
5 5 5
6 6
7 7
W= 1 2 3 4 4
Z = 1 2 3 4 3
OK?
Y Y Y Y N
IEEE C802.16m-09/0521
4