IEEE C802.16m-09/0981
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Proposed Text on Construction & Transmission of MAC PDU section for AWD
Date
Submitted
2009-04-27
Source(s)
Anil Agiwal, Youngbin Chang, Sungjin Lee, anilag@samsung.com
Rakesh Taori, Jungje Son
yb.chang@samsung.com,
Samsung Electronics
*<http://standards.ieee.org/faqs/affiliationFAQ.h
tml>
Re:
“802.16m AWD”:
IEEE 802.16m-09/0020, “Call for Contributions on Project 802.16m Amendment Working
Document (AWD) Content”. Target topic: MAC PDU formats
Abstract
This contribution proposes text for construction and transmission of MAC PDU section to be
included in the 802.16m amendment working document.
Purpose
Notice
Release
Patent
Policy
To be discussed and adopted by TGm for 802.16m amendment working document.
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
IEEE C802.16m-09/0981
Construction & Transmission of MAC PDU in 16m
Anil Agiwal, Youngbin Chang, Sungjin Lee, Rakesh Taori, Jungje Son
Samsung Electronics
1 Introduction
This contribution proposes the text for construction and transmission of MAC PDU based on SDD [2].
2 Outline of Construction & Transmission of MAC PDU in 16m
15.2. x Construction and Transmission of MAC PDUs
15.2.x.1 Multiplexing
15.2.x.2 Concatenation
15.2.x.3 Fragmentation
15.2.x.3.1 Transport Connections
15.2.x.3.1.1 Non-ARQ Transport Connections
15.2. x.3.1.2 ARQ-enabled Transport Connections
15.2.x.3.2 Management Connections
15.2.x.3.2.1 Best Effort Management Messages
15.2.x.3.2.2 Reliable Management Messages
15.2.x.4 Packing
15.2.x.4.1 Packing for non-ARQ Connections
15.2.x.4.1.1 Packing fixed length MAC SDUs
15.2.x.4.1.2 Packing variable length MAC SDUs
15.2.x.4.2 Packing for ARQ Connections
15.2.x.5 Encryption of MAC PDUs
15.2.x.6 Padding
2
IEEE C802.16m-09/0981
3 Text Proposal for inclusion in the 802.16m amendment working document
---------------------------------------------------------Start of the Text----------------------------------------------------------
[Insert the texts in subclause 15.2.x as follows:]
15.2.x Construction and Transmission of MAC PDUs
The figure xx illustrates the various functional blocks involved in the construction of MAC PDU, input and
output of each functional block, and sequence in which these functional blocks are applied during the
construction of MAC PDUs of various types of connections i.e. ARQ connection, non ARQ connection and
management connection. The construction of a MAC PDU is illustrated in figure yy below.
Convergence Sublayer
MAC Common Part
Sublayer &
Security Sublayer
(Control Plane)
Classification
Header Suppression
MSDUs
MSDUs
MSDUs
MSDUs
MSG
MSG
Fragmentation
SDU Fragmentation/Packing Function
MPDU Payload
MPDU
Payload
MPDU
Payload
MPDU Payload
MPDU Payload
MPDU Payload
ARQ
MPDU Formation
Security (Encryption/
Authentication)
Multiplexing
MPDUs
Concatenation Function
One or more
concatenated MPDUs
PHY Layer
MAC CPS Data Path
Functional Blocks
Management Connection
Transport Connections (ARQ)
Transport Connections (non ARQ)
Figure xx Data Path Functional Blocks involved in construction of MAC PDUs
3
IEEE C802.16m-09/0981
START
Pack
SDUs?
Yes
No
No
No
Yes
Yes
No
Fragment
SDU; Add
fragment
Fragment
Needed?
Yes
Fragment
Needed?
No
Yes
Fragment the
SDU; Add
fragment to
payload
Add SDU to
payload
Capacity for
more SDUs?
Yes
Fragment in
queue?
Fragment
/SDU fits?
(NOTE)
Add SDU/
SDU
Fragment
NOTE: “Fragment/SDU fits?”
means: “Does the fragment left
over from the last time, or the next
SDU if no fragment was left over, fit
in the available bandwidth?”
Fragment the
SDU fragment;
Add fragment
to payload
Add SDU
fragment to
payload
No
Multiplex connection
payloads?
No
Yes
Append connection payload to
previous connection payload
Yes
Capacity for
more connection
payloads? *
No
Prepare GMH
Prepare MEH
or FPEH **
* Payload of connection which
belong to same SA
** MEH is prepared if there is
more than one connection payload
in MAC PDU, otherwise FPEH is
prepared
No
Encrypt
Payload?
Yes
Encrypt
Apply GMH &
MEH or FPEH**
Concatenate PDU to
Up/Down link burst
Figure yy Construction of MAC PDU
15.2.x.1 Multiplexing
Multiple connections’ payload (one or more SDU/SDU fragments) associated with same security association
can be multiplexed together in a MAC PDU. The GMH (as defined in section TBD) and the MEH (as defined in
section TBD) provides the details about connection payloads as well as the SDU/SDU fragments in each
connection payload. For example multiple connections’ payloads which are encrypted using AES CCM can be
multiplexed in a MPDU or multiple connections’ payloads which are not encrypted can be multiplexed in a
MPDU. The figure zz illustrates the multiplexing of two connection payloads which are associated with same
security association (i.e. AES CCM).
4
IEEE C802.16m-09/0981
Convergence Sublayer
MSDUs for
FlowID = x
MSDUs for
FlowID = y
Plaintext Payloadx
PN, EKS
Plaintext Payloady
Ciphertext Payloadx
Ciphertext Payloady
Un-Encrypted
Encrypted
GMH MEH Other EHs PN,EKS
(if any)
ICV
Ciphertext Payloadx
Un-Encrypted
Ciphertext Payloady
ICV
Encrypted
Figure zz Multiplexing of connection payload associated with same SA
15.2.x.2 Concatenation
Multiple MAC PDUs may be concatenated into a single transmission in either the UL or DL directions. For
AMS attached to ABS, each MPDU in UL/DL burst is uniquely identified by Flow ID.
Figure xxx illustrates the concept for an UL burst transmission. Since the MAC SDUs in MAC PDU are
indentified by the Flow ID in the GMH and MEH ( in case of multiplexing), the receiving MAC entity is able to
present the MAC SDU (after reassembling the MAC SDU from one or more received MAC PDUs) to the
correct instance of the MAC SAP. MAC management messages, user data (from one or more connections), and
BR MAC PDUs may be concatenated into the same transmission.
UL Burst #n
User MPDU
(1 connection)
BR
MPDU
FlowID = 0x5 FlowID = 0x7
UL Burst #n+1
Management
MPDU
BR
MPDU
User MPDU
FlowID=0x1
FlowID=0x8
FlowID=0x6,
0x4
(2 connection)
UL Burst #n+2
User MPDU
User MPDU
(2 connection of
SA1)
FlowID=0x6,
0x4
(2 connection of
SA2)
FlowID=0x8,
0x9
SA1: Security Association 1
(for e.g AES CCM)
SA2: Security Association 2
( for e.g. no protection)
Figure xxx MAC PDU concatenation showing example Flow IDs
15.2.x.3 Fragmentation
Fragmentation is the process by which a MAC SDU (or MAC management message) is divided into one or
more MAC PDUs. This process is undertaken to allow efficient use of available bandwidth relative to the QoS
requirements of a connection’s service flow. Capabilities of fragmentation and reassembly are mandatory.
5
IEEE C802.16m-09/0981
FPEH (as defined in section TBD) or MEH(as defined in section TBD) in the MAC PDU provides the
information about the SDU fragment. SN in FPEH or MEH (in case of multiplexing) is used for sequencing the
SDU fragments and Fragmentation control (FC) bits in FPEH or MEH, are used to tag the SDU fragments with
respect to their position in the parent SDU.
15.2.x.3.1 Transport Connections
15.2.x.3.1.1 Non-ARQ Transport Connections
For non-ARQ transport connections, fragments are transmitted once and in sequence. The SN assigned to each
connection PDU carrying SDU fragment allows the receiver to recreate the original payload and to detect the
loss of any intermediate fragments. A connection may be in only one fragmentation state at any given time.
Upon loss, the receiver shall discard all SDU fragments on the connection until a new first SDU fragment is
detected or a non-fragmented SDU is detected.
15.2.x.3.1.2 ARQ-enabled Transport Connections
For ARQ connections, fragments are transmitted in sequence. The SN assigned to each ARQ PDU carrying
SDU fragment allows the receiver to recreate the original payload and to detect the loss of any intermediate
fragments.
15.2.x.3.2 Management Connections
Only one management message can be in fragmentation state at any given time.
15.2.x.3.2.1 Best Effort Management Messages
The fragments of best effort management messages are transmitted once and in sequence. The SN assigned to
each management connection PDU carrying management message fragment allows the receiver to recreate the
original payload and to detect the loss of any intermediate fragments. Upon loss, the receiver shall discard all
the best effort management message fragments on the connection until a new first best effort management
message fragment is detected or a new non-fragmented management message is detected or a new reliable
management message fragment is detected.
15.2.x.3.2.2 Reliable Management Messages
The fragments of reliable management messages are transmitted more than once. The SN assigned to each
management connection PDU carrying management message fragment allows the receiver to recreate the
original payload and to detect the loss of any intermediate fragments. Upon loss, the receiver shall wait for the
lost reliable management message fragments until a new first best effort management message fragment is
detected or a new non-fragmented management message is detected or a new first reliable management message
fragment is detected.
15.2.x.4 Packing
MAC may pack multiple MAC SDUs into a single MAC PDU. Packing makes use of the connection attribute
indicating whether the connection carries fixed-length or variable-length packets. The transmitting side has full
discretion whether to pack a group of MAC SDUs in a single MAC PDU. The capability of packing and
6
IEEE C802.16m-09/0981
unpacking is mandatory. The packing and fragmentation mechanisms for both the ARQ and non-ARQ
connections are specified in 15.2.x.4.1 and 15.2.x.4.2 respectively.
15.2.x.4.1 Packing for non-ARQ Connections
15.2.x.4.1.1 Packing fixed length MAC SDUs
For connections that do not use ARQ and are indicated by the fixed-length versus variable-length SDU
indicator, to carry fixed-length MAC SDUs, the packing procedure described in this subclause may be used. For
all other non-ARQ connections, the variable-length packing algorithm described in 15.2.x.4.1.2 shall be used.
For packing with fixed-length blocks, the Request/Transmission Policy shall be set to allow packing and
prohibit fragmentation, and the SDU size shall be included in DSA-REQ message when establishing the link.
The length field of the MAC header implicitly indicates the number of MAC SDUs packed into a single MAC
PDU. If the MAC SDU size is n bytes, the receiving side can unpack simply by knowing that the length field in
the MAC header will be n×k, where k is the number of MAC SDUs packed into the MAC PDU and n is the size
of each SDU. A MAC PDU containing a packed sequence of fixed-length MAC SDUs would be constructed as
in Figure yyy. Note that there is no added overhead due to packing in the fixed-length MAC SDU case, and a
single MAC SDU is simply a packed sequence of length 1.
Mac
Header
LEN =
n*k
Fixed
Fixed
Fixed
Length
Length
Length
MAC
MAC
MAC
SDU
SDU
SDU
Length =n Length =n Length =n
Fixed
Length
MAC
SDU
Length =n
Figure yyy Packing fixed-length MSDUs into a single MAC PDU
15.2.x.4.1.2 Packing variable length MAC SDUs
When packing variable-length SDU connections, the n×k relationship between the MAC header’s Length field
and the higher layer MAC SDUs no longer holds. This necessitates indication of where one MAC SDU ends
and another begins. In the variable-length MAC SDU case, the MAC attaches a FPEH (defined in section TBD)
or a MEH ( defined in section TBD, in case of multiplexing) in the MPDU. A MAC PDU containing a packed
sequence of variable-length MAC SDUs is constructed as shown in Figure zzz. Note that non-fragmented MAC
SDUs and MAC SDU fragments may both be present in the same MAC PDU.
FPEH
k MAC SDUs
Packing Packing
Mac
Info-1
Info-2
SN
Header
End = 0 End = 0
FC = 00
LEN = y
Length= a Length= b
2 bytes
Packing
Info-k
End = 1
x bytes
Variable Variable
Length
Length
MAC
MAC
SDU
SDU
Length =a Length =b
Variable
Length
MAC
SDU
Length =c
y bytes
Figure zzz Packing variable length MSDUs into a single MAC PDU
7
IEEE C802.16m-09/0981
Simultaneous fragmentation and packing allows efficient use of the air link, but requires guidelines to be
followed so it is clear which MAC SDU is currently in a state of fragmentation. The fragmentation control bits
should be set according to the rules defined in Table TBD. The packing with fragmentation is illustrated in
figure xxxx.
FPEH
r MAC SDUs
Packing Packing Packing
Mac
Info-1
Info-2
Info-3
SN = x
Header
End = 0 End = 0 End = 0
FC = 11
LEN = y1
Length= a Length= b Length= c
Packing
Info-k
End = 1
Last
UnUnFragment
fragmented fragmented
of MAC
MAC SDU MAC SDU
SDU
Length =b Length =c
Length =a
First
Fragment
of MAC
SDU
Length =d
s-r+1 MAC PDUs
Mac
Packing Continuing
SN =
Header
Info-1 Fragment of
x+1
LEN = y2
End = 1 MAC SDU
FC = 11
=e
Length =e
Mac
Packing Continuing
SN =
Header
Info-1 Fragment of
x+2
LEN = y3
End = 1 MAC SDU
FC = 11
=f
Length =f
Mac
SN = sHeader
r+x+1
LEN = y4
FC = 11
=g
FPEH
Mac
SN = sHeader
r+x+2
LEN = y5 FC = 10
Packing Continuing
Info-1 Fragment of
End = 1 MAC SDU
Length =g
t MAC SDUs
Packing
Packing Packing
Info-1
Info-2
Info-3
End = 0
End = 0 End = 0
Length= h Length= i Length= j
Packing
Info-k
End = 1
FPEH
Last
UnUnFragment
fragmented fragmented
of MAC
MAC SDU MAC SDU
SDU
Length =i Length =j
Length =h
Unfragmented
MAC SDU
Length =k
FPEH
Mac
Packing
UnSN = sHeader
Info-1 fragmented
r+x+3
LEN = y6
End = 1 MAC SDU
FC = 00
=b
Length =b
Packing
Packing
UnUnMac
SN = s- Info-1
Info-2 fragmented fragmented
Header
r+x+4 End = 0
End = 1 MAC SDU MAC SDU
LEN = y7 FC = 00 Length=
Length =b Length =b
b
FPEH
Packing
First
Packing
UnMac
SN = s- Info-1
Fragment
Info-1 fragmented
Header
r+x+5 End = 0
of MAC
End = 1 MAC SDU
LEN = y8 FC = 01 Length=
SDU
Length =b
b
Length =j
Figure xxxx Packing with fragmentation
15.2.x.4.2 Packing for ARQ Connections
The use of FPEH for ARQ-enabled connections is similar to that for non-ARQ connections as described
15.2.x.4.1. The transmitting side has full discretion whether to pack a group of MAC SDUs and/or fragments in
a single MAC PDU. The SN of the FPEH or MEHB (in case of multiplexing) shall be used by the ARQ
protocol to identify and retransmit ARQ blocks.
15.2.x.5 Encryption of MAC PDUs
When transmitting a MAC PDU on a connection that is mapped to an SA, the sender shall perform encryption
and data authentication of the MAC PDU payload as specified by that SA. When receiving a MAC PDU on a
connection mapped to an SA, the receiver shall perform decryption and data authentication of the MAC PDU
8
IEEE C802.16m-09/0981
payload, as specified by that SA.
The generic MAC header shall not be encrypted. The receiver determines whether the payload in the MAC PDU
is encrypted or not from the Flow ID in the GMH. The encryption information needed to decrypt a payload at
the receiving station is present at the beginning and at the end of the connection payload. For e.g. in case of AES
CCM, PN & EKS are present at the beginning of connection payload and ICV is appended at the end of the
connection payload in MAC PDU as shown in figure xxxxx. . In case of AES CTR, ICV at the end of
connection payload is not present.
MAC PDU
GMH
(Transport
Connection FID)
Extended Headers
(if any)
Transport Connection Payload with security
information
EKS
PN
2
bits
22
bits
Transport Connection
Payload
ICV
Encrypted
Figure xxxx MAC PDU with Transport Connection Payload– Authenticated & Encrypted using AES
CCM
If multiple connection payloads are transmitted in same burst and the connections are mapped to same SA then
multiple connection payload are multiplexed (as explained in section ) before encryption and multiplexed
payload is encrypted together. The receiver shall perform the decryption and data authentication on the
multiplexed payload, as specified by the SA. The generic MAC header shall not be encrypted. The receiver
determines whether the payloads in the MAC PDU is encrypted or not from the Flow ID in the GMH. The
encryption information needed to decrypt the multiplexed payload at the receiving station is present at the
beginning of the first connection payload and at the end of the last connection payload. For e.g. in case of AES
CCM, PN & EKS are present at the beginning of connection payload 1 and ICV is appended at the end of the
connection payload n in MAC PDU as shown in figure yyyyy. In case of AES CTR, ICV at the end of
connection payload n is not present.
MAC PDU
GMH
(Transport
Connection FID)
MEH
Other Extended
Headers (if any)
Transport Connection Payloads with security information
EKS
PN
2
bits
22
bits
Transport Connection Payloads
ICV
Encrypted
Payload Payload
1
2
Payload
n
Figure yyyyy MAC PDU with Multiple Transport Connection Payloads– Authenticated & Encrypted
using AES CCM
9
IEEE C802.16m-09/0981
15.2.x.6 Padding
Within the data burst, the unused portion shall be initialized to a known state. If the size of the unused portion is
only one byte then the unused byte is set to 0xFF. If the size of the unused portion is greater than or equal to two
bytes, the unused region is initialized by formatting the unused space as an MPDU. When doing so, the MAC
header FID field shall be set to the value of padding FID (See table TBD), the EH and Length field shall be set
to zero.
4 Reference
[1] IEEE 802.16m-09/0010r1a, “802.16m Amendment Working Document (AWD)”
[2] IEEE 802.16m-08/003r8, “802.16m System Description Document (SDD)”
1
0