IEEE C802.16m-09/2269r1
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Enhanced EH Format (section 15.2.2.2)
Date
Submitted
2009-11-06
Source(s)
Anil Agiwal, Youngbin Chang, Sungjin, Lee, anilag@samsung.com, yb.chang@samsung.com,
Rakesh Taori, Jungje Son, Youngkyo Baek
*<http://standards.ieee.org/faqs/affiliationFAQ.h
Samsung Electronics
tml>
Re:
IEEE 802.16-09/0057, IEEE 802.16 Working Group Letter Ballot Recirc #30a / Topic:
Enhanced EH Format (Section 15.2.2.2)
Abstract
This contribution proposes text for enhanced EH format
Purpose
Notice
Release
Patent
Policy
To be discussed and adopted by TGm for P802.16m/D3.
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/2269r1
Enhanced EH Format (section 15.2.2.2)
Anil Agiwal, Youngbin Chang, Rakesh Taori, Jungje Son, Youngkyo baek
Samsung Electronics
1 Introduction
This contribution summarizes the changes needed (with editorial instructions) for the proposal in the slides
S802.16m-09/2269.pdf.
Proposed Text Change1: EH format change to incorporate EH length
Proposed Text Change 2-6: FPEH/FEH change to FPSH/FSH
Proposed Text Change 7-11: FID for encryption
2 Proposed text
Blue/Underline: Text Added
Red/Strikeout: Text Deleted
[Change 1: Modify the section 15.2.2.2, page 18 (line 60-65), page 19 (line 1-26) as shown
below]
---------------------------------------------------Text Start--------------------------------------------15.2.2.2 Extended header formats
The inclusion of Extended Header group is indicated by EH bit in MAC Header. The extended header group
(see figure xxx), when used, shall always appear immediately after the MAC header. Extended header group
shall not be encrypted. The fields of the Eextended header group format is are defined in Table 655— and will
be used unless specified otherwise.
Extended Header Group Length (8 bits)
EH Type 1 (TBD)
EH Body 1
(variable length)
EH Type 2 (TBD)
Extended Header
Group Length
EH Body 2
(variable length)
EH Type n (TBD)
EH Body n
(variable length)
Figure xxx Extended Header Group Format
2
IEEE C802.16m-09/2269r1
Table 655 – Extended Header Group Format Fields
Syntax
Size
(bit)
Notes
Extended Headers {
Last
1
EH Group Length
Type
Body Contents
TBD
Last Extended Header indication:
0 = one or more extended header follows the
current extended header unless specified
otherwise;
1 = this extended header is the last extended
header unless specified otherwise
Extended header Length
Type of extended header
Variable Type dependent content
}
Extended header Group Length
8
Extended header Type
TBD
Extended header Body
variable
The Extended header Group Length field
indicates the total length of the extended header
group, including all the extended headers and the
Extended header Group length byte.
Type of extended header as defined in Table 656.
The size of the extended header is determined by
extended header type as specified in Table 656.
The extended header including the extended
header type is byte aligned.
---------------------------------------------------Text End---------------------------------------------
[Change 2: Insert the section shown below after section 15.2.2.2]
---------------------------------------------------Text Start---------------------------------------------
15.2.2.x MAC Subheaders
Two types of subheaders, FSH & FPSH may be present in a MAC PDU.
------------------------------------------Text End (Change -2)---------------------------------------------
3
IEEE C802.16m-09/2269r1
[Change 3: Modify section 15.2.2.2.1, page 19-22, as follows]
---------------------------------------------------Text Start--------------------------------------------15.2.2.2.1 15.2.2.x.1 Fragmentation and packing extended subheader (FPESH)
The FPESH shall be used when MAC PDU contains payload from single transport connection. The FPEH exists
before the SDU/SDU fragments of the transport connection in the MAC PDU. The presence of FPSH in a MAC
PDU with single transport connection payload is illustrated in figure xxx. The presence of FPSH in a MAC
PDU with multiplexing is illustrated in figure yyy. after the last extended header (i.e. the extended header with
'Last' = '1') if 'EH' in AGMH set to '1' or after the AGMH if 'EH' in AGMH set to '0'. The FPESH format is
defined in Table 657. 'RI' in FPESH is used for indicating whether the payload contains ARQ sub-blocks or not.
If 'RI' bit set to '1', 'LSI' and 'SSN' shall be included in FPESH.
Un encrypted
AGMH
Extended Headers
(if any)
Payload
One or more SDU/SDU fragments of
transport connection
FPSH
a) FPSH location in absence of payload encryption
AGMH
Extended Headers
(if any)
Payload
Encrypted
PN,
EKS
FPSH
One or more SDU/SDU fragments of
transport connection
ICV
b) FPSH location in presence of payload encryption
Figure xxx FPSH location in a MAC PDU with a transport connection payload
AGMH
MEH
Payload
PN
FPSHx
SDU/SDU
fragments of
connection x
FPSHy
SDU/SDU
fragments of
connection y
Encrypted
Figure yyy FPSH location in a MAC PDU with multiplexing
4
ICV
IEEE C802.16m-09/2269r1
Table 657 – FPESH Format
Syntax
Size
(bit)
Notes
FPEH() {
RI
1
Re-arrangement information indicator
SN
10
FC
AFI
2
1
AFP
1
SN is maintained per connection. For non ARQ
connection, ‘SN’ represents the MAC PDU Payload
Sequence Number and the ‘SN’ value increments by one
(modulo 1024) for each MAC PDU. For ARQ
connection, ‘SN’ represents the ARQ block sequence
number.
Fragmentation Control bits (see Table 659)
ARQ feedback IE indicator
0 = ARQ feedback IE is not present in the MAC PDU
1 = ARQ feedback IE follows after FPESH
ARQ feedback poll indicator
0 = No ARQ feedback poll
1 = ARQ feedback poll for the connection indicated in
GMH
if (RI == 1) {
LSI
1
SSN
}
Do {
End
if (End == 0) {
Length
TBD
Last ARQ sub-block indicator
0 = indicating the last ARQ sub-block from the single
ARQ block is not included in this MAC PDU
1 = indicating the last ARQ sub-block from the single
ARQ block is included in this MAC PDU
SUB-SN of the first ARQ sub-block
1
Indication of more information
0 = Indicating another ‘Length’ and ‘End’ fields are
followed
1 = Indicating no more ‘Length’ and ‘End’ fields are
followed
11
MAC PDU with single connection payload:
This field indicates the length of SDU or SDU fragment
in the MAC PDU payload. If a the MAC PDU payload
consists of 'N' SDU/SDU fragments, N-1 'Length' fields
are present in FPEH. These represent the length of first
'N-1' SDU/SDU fragments in MAC PDU payload. The
length of the last SDU or SDU fragment in the MAC
PDU payload is = MAC PDU payload length (after
decryption) - sum of 'N-1' length fields in FPESH. where
MAC PDU payload length (after decryption) = Length of
5
IEEE C802.16m-09/2269r1
MAC PDU (given by length field in GMH) - Length of
GMH(2 bytes) - sum of length of all extended headers
present in MAC PDU - Length of PN& EKS (3bytes, if
present) - Length of ICV ( 8 bytes, if present) – Length of
FPSH.
MAC PDU with multiple connections payload:
MAC PDU payload consists of multiple connection
payload. This field indicates the length of SDU or SDU
fragment in the connection payload corresponding to this
FPSH. If the connection payload consists of 'N'
SDU/SDU fragments, N-1 'Length' fields are present in
FPSH. These represent the length of first 'N-1' SDU/SDU
fragments in connection payload. The length of the last
SDU or SDU fragment in the connection payload is =
Connection payload length (see table 661, MEH format) sum of 'N-1' length fields in FPSH.
}
} while (!End)
Reserved
Variable
Reserved bits are added at the end of FPESH for byte
alignment.
}
Table 658 FPEH Fields
[Delete table 658]
Table 659 Encoding of FC Field
[No change, keep it as it is]
------------------------------------------Text End (Change -3) -------------------------------------------[Change 4: Modify section 15.2.2.2.2, page 22-23, as follows]
---------------------------------------------------Text Start--------------------------------------------15.2.2.2.2 15.2.2.x.2 Fragmentation extended subheader (FESH)
The FESH shall be used when MAC PDU contains payload from a single management control connection. The
FSH exists before the unfragmented control message or control message fragment in the MAC PDU. The
presence of FSH in a MAC PDU with single control connection payload is illustrated in figure ppp. The
6
IEEE C802.16m-09/2269r1
presence of FSH in a MAC PDU with multiplexing is illustrated in figure qqq. that are The FESH format is
defined in Table 660.
AGMH
Payload
FSH
Control message or control
message fragment
a) FSH location in absence of payload encryption
AGMH
Payload
PN,
Control message or control
FSH
EKS
message fragment
ICV
b) FSH location in presence of payload encryption
Figure ppp FSH location in a MAC PDU with a control connection payload
AGMH
MEH
Payload
PN
FSHx
Control message or
control message
fragment, connection x
FPSHy
SDU/SDU
fragments of
connection y
Encrypted
Figure qqq FSH location in a MAC PDU with multiplexing
Syntax
FESH () {
EC
Table 660 FESH Format
Size
(bit)
1
SN Indicator
1
If (SN Indicator = 0) {
Reserved
67
Notes
Encryption Control indicator
0 = Payload is not encrypted
1 = Payload is encrypted
0 = no FC and sequence number
1= FC and sequence number are followed
For byte alignment
7
ICV
IEEE C802.16m-09/2269r1
} else {
Polling
1
FC
SN
Reserved
2
8
34
0 = no acknowledgement required
1 = acknowledge required upon receiving the MAC
message
Fragmentation control (see <<<table TBD>>>)
Payload sequence number
For byte alignment
}
}
------------------------------------------Text End (Change-4) -------------------------------------------[Change 5: Delete ‘Last’ field from table 661, 662, 664, 665, 666 and 667]
[Change 6: Delete fragmentation extended header and fragmentation and packing
extended header from table 656 on page 19]
[Change 7: Modify section 15.2.10.1, page 172, line 37-47 as follows]
---------------------------------------------------Text Start--------------------------------------------15.2.10.1 Management connections
Two One pairs of bi-directional unicast management control connections - basic connection and primary
management connection, are is automatically established when an AMS performs initial network entry. The
basic connection is used by the ABS MAC and AMS MAC to exchange short, time-urgent MAC control
messages. The primary management connection is used by the ABS MAC and AMS MAC to exchange longer,
more delay-tolerant MAC control messages. FID with value 0 and 1 are reserved for unicast control connection.
FID with value 0 is used when MAC PDU contains unencrypted control connection payload. FID with value 1 is
used when MAC PDU contains encrypted control connection payload. these two management connections
respectively. The mapping for MAC control messages to connection shall be static based on Table 673.
------------------------------------------Text End (Change -7) -------------------------------------------[Change 8: Modify table 652, page 16-17 as follows]
---------------------------------------------------Text Start--------------------------------------------Value
0000
Description
Basic management FID Control connection FID; used when MAC
PDU contains unencrypted control message or control message
fragment
8
0001
0010
0011
0100-1111
IEEE C802.16m-09/2269r1
Primary management FID Control connection FID; used when
MAC PDU contains encrypted control message or control
message fragment
Signaling Header indicator
Pre provisioned Transport connection for BE Service
Transport FID
------------------------------------------Text End (Change-8) -------------------------------------------[Change 9: Modify text in section 15.2.3, page 32, line 43-59 as follows]
---------------------------------------------------Text Start--------------------------------------------15.2.3 MAC Control messages
The peer-to-peer protocol of MAC layers in ABS and AMS communicate using the MAC control messages to
perform the control plane functions. MAC control messages shall be carried in a MAC PDU to be transported in
broadcast, unicast or random access connections. There is a single unicast Control connection. HARQ shall be
enabled for MAC control messages sent on the unicast Control connection. Encryption may be enabled for
unicast MAC control messages. MAC control messages may be fragmented. MAC control messages shall not be
sent using multiplexing extended header. Table 673 lists the MAC control messages that shall be defined in the
ASN.1 format, as shown in <<<Appendix X>>>. The indication to the receiver whether the PDU is encrypted is
indicated by the EC=1 in FEH extended header FID in the AGMH. Whether the encryption is applied on a
management message or not shall be determined by the message type and MAC procedure context, which is
define in <<Table TBD>>. A messages included in a PDU whose EC bit FID value does not match the
combined message type and corresponding context defined in the <<Table TBD>> shall be discarded.
Encrypted and non encrypted MAC control messages shall not be sent in the same PDU.
------------------------------------------Text End (Change-9) -------------------------------------------[Change 10: Modify text in section 15.2.5.2.5, page 111, line 24-28 as follows]
---------------------------------------------------Text Start--------------------------------------------The fragment extended header is used only for management flows. The EC bit FID in the Fragment extended
header AGMH is used to indicate whether the PDU contains control message encrypted based on security level.
Whether each control message is encrypted or not is decided based on the security level which the message is
associated with.
------------------------------------------Text End (Change-10) -------------------------------------------[Change 11: Modify text in section 15.2.5.4.2, page 115, line 52-58 as follows]
---------------------------------------------------Text Start--------------------------------------------9
IEEE C802.16m-09/2269r1
The selective confidentiality protection over control messages is indicated by the FID EC bit in the AGMH FEH.
Contrary to the transport flows where the established SA is applied to all data, the SA is selectively applied to
the management flows. Security extended header is used only for management flows to indicate whether PDU
contains the control message that is encrypted based on control message type and its usage. In particular,
whether control message is encrypted or not is decided on the security level with which the message is
associated.
------------------------------------------Text End (Change-11) --------------------------------------------
3 Reference
[1] IEEE P802.16m/D2, “DRAFT Amendment to IEEE Standard for Local and metropolitan area networks Part
16: Air Interface for Broadband Wireless Access Systems”
1
0