IEEE C802.16m-10/10630700

Project / IEEE 802.16 Broadband Wireless Access Working Group < / Device class and related capability negotiationparameters during Network Entry/Re-entry
Sections: 16.2.15, 16.2.3
Date Submitted / 2010-07-05
Source(s) / Shaocheng Wang
Sassan Ahmadi
Muthaiah Venkatachalam
Xiangying Yang
Intel Corporation / E-mail: ; ; ; ;
Re: / Call for SB on “ P802.16m/D6”:
Target topic: “sections16.2.15 and 16.2.3”
Abstract / This contribution proposes a new structure for capability negotiation parameters during network entry/re-entry to minimize the use of radio resources for transmission of unnecessary parameters that otherwise must be supported by default. We further categorize the parameters to be negotiated based on pre-authentication or post-authentication to ensure encryption and protection of those parameters that are directly pertained to the user or device identity and credentials.
Purpose / Adopt the proposed text.
Notice / 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.
Release / 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.
Patent Policy / The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
and < information is located at < and < class and related capability negotiation parameters during Network Entry/Re-entry

Shaocheng Wang, Sassan Ahmadi, Muthaiah Venkatachalam, Xiangying Yang

Intel Corporation

  1. Introduction

Since the large SBC-REQ/RSP MAC management message was a bottleneck in the reliability and accessibility of the legacy system, the goal of this proposal is to organize and reduce the number of configuration parameters that are negotiated between the base station and the mobile station in order to reduce unicast messaging overhead in the system.

This contribution proposes a new structure for capability negotiation parameters during network entry/re-entry to minimize the use of radio resources for transmission of unnecessary parameters that otherwise must be supported by default. We further categorize the parameters to be negotiated based on pre-authentication or post-authentication to ensure encryption and protection of those parameters that are directly pertained to the user or device identity and credentials. Since the large SBC-REQ/RSP MAC management message was a bottleneck in the reliability and accessibility of the legacy system, the goal of this proposal is to organize and reduce the number of configuration parameters that are negotiated between the base station and the mobile station in order to reduce unicast messaging overhead in the system.

WiMAX Forum Technical Working Group has recently initiated an effort to define device classes for release 2 of mobile WiMAX profiles. Depending on maximum downlink/uplink data rate (maximum encoding and decoding capability), MIMO and multi-carrier capabilities of the mobile station, different device classes are defined, where each device class targets a specific market or consumer hardware platform. While user equipment category concept has been around in cellular industry for some years, the concept of device class is new to mobile WiMAX and will affect the configuration parameters that are negotiated during network entry or re-entry. On the other hand, unlike its predecessor, IEEE 802.16m specifies several mandatory functionalities and default parameters that do not need to be negotiated and are required to be supported in all device classes.

If the parameters associated with a specific device class as well as the default parameters corresponding to the mandatory functions specified by the standard, the remainder of the parameter set required for the network entry or re-entry can be negotiated between the base station and the mobile station as part of capability negotiation and registration procedures.

A device class represents the hardware limitations of a client device implementation. The device class shall not be confused with the capability class concept defined in the standard. A capability class is defined as a unique set of functions, configuration parameters, air-interface protocol revision, and/or services that can uniquely describe a mobile station implementation or configuration while operating in the network. Each capability class is indicated by its corresponding CAPABILITY_INDEX. The AMS, by default, shall support the basic capabilities associated with Capability Class 0 (i.e., CAPABILITY_INDEX = 0).

In addition to the parameters that are set by the device class and capability class, there are additional parameters and configurations that are signaled via A-MAP IE and are not negotiable. The following is an example of device class mapping in Reference [1].

Table 1. Device Categorization from the perspective of User Peak Throughput (TDD)

Device Category
TDD / Total BW
(MHz) / Aggregation / No of streams
[Rx, Tx] / UL 64QAM / Max bits per subframe per device
(See Assumption) / Peak System Throughput
Mbps / User buffer size/max number of soft bits
DL / UL / DL / UL / DL / UL
T1 / 20 / 20 / [2, 1] / No / 123648 / 43792 / 106.91 / 23.50
T2 / 20 / 20 or (10+10) / [2, 2] / No / 123648 / 82432 / 106.91 / 44.24
T3 / 20 / 20 / [2, 2] / No / 123648 / 82432 / 106.91 / 44.24
T4 / 20 / 20 / [2, 2] / No / 123648 / 82432 / 106.91 / 44.24
T5 / 20 / 20 or (10+10) / [4, 2] / Yes / 242880 / 123648 / 203.67 / 66.36
T6 / 20 / 20 or (10+10) / [4, 2] / Yes / 242880 / 123648 / 203.67 / 66.36
T7 / 20 / 20 / [4, 4] / Yes / 242880 / 242880 / 203.67 / 127.18
T8 / 40 / 20+20 / [4, 4] / Yes / 242880x2 / 242880x2 / 203.67x2 / 127.18x2

Table 2. Device Categorization from the perspective of User Peak Throughput (FDD)

Device Category
FDD / Total BW / No of streams [Rx, Tx] / UL 64QAM / Max bits per subframe per device
(See Assumption) / Peak System Throughput
Mbps / User buffer size/max number of soft bits
DL / UL / DL / UL / DL / UL
F1 / 2x20 MHz / [2, 1] / No / 168.66 / 62.67
F2 / 2x20 MHz / [2, 2] / No / 168.66 / 117.96
F3 / 2x20 MHz / [2, 2] / No / 168.66 / 117.96
F4 / 2x20 MHz / [2, 2] / Yes / 168.66 / 176.95
F5 / 2x20 MHz / [4, 4] / Yes / 322.56 / 339.15

As a result, Tthe following is an example list of parameters we propose to delete due to introduction of device class parameterthat are specified once the device class of the mobile station is identified or are specified via A-MAP IE control signaling. This type of parameters shall be excluded from the negotiation list.

-Uplink modulation scheme (part of device class definition)

-# of RX/TX antenna (part of device class definition)

-TTI (DL/UL) (signaled via A-MAP IE where both default and long TTI must be supported by all devices to ensure sufficient uplink link budget)

-Multi-carrier capability (part of device class definition)

The parameters that need to be negotiated are categorized into two groups: pre-authentication and post-authentication configuration parameters, where the former group consists of parameters that are not related to user identity and the latter group comprises parameters that are related to user identity and thus must be negotiated after security establishment (i.e., following AAI_PKM-REQ/RSP messaging).

  1. Text Proposal

[Remedy #1]

------Start of the proposed text------

[Please see if any necessary text about device class needed to for NE text, i.e. 16.2.15]

[Note to Editor] In section 16.2.3.4 under AAI_SBC-REQ modify Table 682, 683 and, 684, and 685with following table (entries that are crossed out are existing parameters that we suggest to remove; entries in blue text are new parameters we suggest to add)

Table 682—AAI_SBC-REQ message Field Descriptions

M/O / Attributes / Array of attributes / Size (bits) / Value / Note / Conditions
M / CAPABILITY_INDEX / 85 / It refers to the "Capability Class" that the AMS can support
OM / DEVICE_CLASS / 3 / It refers to the "Device Class" that the AMS can support

Table 683—AMS Capabilities to be transmitted to ABS

Nego parameters / value
Long TTI for UL / If Bit#0 =1,it supports
Long TTI for DL / If Bit#0 =1,it supports
Modulation Scheme / If Bit#0 =1, DL QPSK supports
If Bit#1 =1, DL 16QAM supports
If Bit#2 =1, DL 64 QAM supports
If Bit#13 =1, , UL QPSK supports
If Bit#4 =1, UL 16QAM supports
If Bit#5=1, UL 64 QAM supports

Table 684—AAI_SBC-RSP Field Descriptions

M/O / Attributes / Array of attributes / Size (bits) / Value / Note / Conditions
M / CAPABILITY_INDEX / 85 / It refers to the "Capability Class" that the ABS has allowed the AMS to use.
OM / DEVICE_CLASS / 3 / It refers to the "Device Class" that the ABS has allowed the AMS to use.

Table 685—AMS Capabilities to be confirmedby ABS

Nego parameters / value
Long TTI for UL / If Bit#0 =1,it supports
Long TTI for DL / If Bit#0 =1,it supports
Modulation Scheme / If Bit#0 =1, DL 64 QAM supports
If Bit#1 =1, UL 64 QAM supportsIf Bit#0 =1, DL QPSK supports
If Bit#1 =1, DL 16QAM supports
If Bit#2 =1, DL 64 QAM supports
If Bit#3 =1, UL QPSK supports
If Bit#4 =1, UL 16QAM supports
If Bit#5=1, UL 64 QAM supports

------End of the proposed text------

------Start of the proposed text------

[Note to Editor] In section 16.2.3.7 under AAI_REG-REQ modify Table 687 and Table 688 with following table (entries that are crossed out are existing parameters that we suggest to remove)

Table 687—AAI_REG-REQ message Field Descriptions

M/O / Attributes / Array of attributes / Size (bits) / Value / Note / Conditions
M / AMS MAC address / 48 / This is used to derive security keys
O / Multicarrier capabilities / 2 / 0b00: No MC modes
0b01: Basic MC mode
0b10: Multicarrier Aggregation
0b11: Multicarrier Switching
0b100: Both Multicarrier Aggregation and Multicarrier Switching

Table 688—AAI_REG-RSP message Field Descriptions

M/O / Attributes / Array of attributes / Size (bits) / Value / Note / Conditions
O / Multicarrier capabilities / 2 / 0b00: No MC modes
0b01: Basic MC mode
0b10: Multicarrier Aggregation
0b11: Multicarrier Switching
0b100: Both Multicarrier Aggregation and Multicarrier Switching

------End of the proposed text------

------Start of the proposed text------

[Note to Editor] In section 16.2.3.4 under AAI_SBC-REQ modify Table 682, 683, 684, and 685 with following table (entries that are crossed out are existing parameters that we suggest to remove; entries in blue text are new parameters we suggest to add)

------End of the proposed text------

1