IEEE C802.16p-11/0025

Project / IEEE 802.16 Broadband Wireless Access Working Group <
Title / Quick capability negotiation procedure to improve M2M support in 16p
Date Submitted / 2011-03-06
Source(s) / Bin Chen, Erik Colban, George Calcev
Huawei / E-mail:


*<
Re: / Call for contributions from802.16, M2M
Abstract / This contribution proposes to simplify the capability negotiation in network entry procedure for 802.16pto support M2M service better.
Purpose / To be discussed and adopted by 802.16p TG
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 <
Further information is located at < and <

Quick capability negotiation procedure to improve M2M support in 16p

Bin Chen, Erik Colban, George Calcev
Huawei

Introduction

This contribution proposes to enhance the Capability Index in capability negotiation message (AAI-SBC-REQ/AAI-SBC-RSP) to simplify the capability negotiation procedure, so that to speed up network entry.

In M2M capable wireless communication system, there will be a large number of M2M devices belong to a subscriber, for example, smart meter of a utility company. An important characteristic of these M2M devices is that they have same or highly similar wireless communication capability. Another important characteristic of them is that their hardware will not update for a long time, for example, several years. So, it is not necessary that all these M2M devices do whole capability negotiation with BS during network entry. The capability negotiation procedure will take at least 10ms, and each capability negotiation message has many bytes which introduce more signaling overhead (for example, in 16m, the AAI-SBC-REQ is at least 20 bytes, while at 16e, it is at least 60 bytes). When a burst of network entry happy, capability negotiation procedure will add to network and air interface congestion in both throughput and time domain.

Proposal Approach

Set a 16 bits or 32 bits parameter to indicate capability configuration set in M2M devices, which we could call it capability indicator or other names. This capability indicator can be sent on RNG-REQ message, and BS responds a same value on the RNG-RSP, and then the subsequent SBC-REQ/SBC-RSP can be passed over. If the BS cannot recognize it, it will respond a null indicator, and then the subsequent SBC-REQ/SBC-RSP procedure shall be processed as normal.

A problem is that how to create the mapping between capability indicator and capability configuration set. One method is that the subscriber sends the capability configurations to the network operator, and the latter allocate capability identifiers for them and input the mapping to the system. Since a network operator will not have too many enterprises user and an enterprise user has a large number of same M2M devices, this process is not a big burden. Another method is that WiMAX forum (e.g. TWG/CWG) define several typical M2M device capability configuration and public the mapping. The M2M subscribers follow it.

I think there shall be other better methods to solve this problem, and would suggest 16p colleagues to discuss it.

Proposed Text

------Start of Proposed Text ------

16.2.3.1 AAI-RNG-REQ

Table 678—AAI-RNG-REQ message Field Description

Syntax / Size (bit) / Description/Notes
Ranging Purpose Indication / 4 / …
CMAC indicator / 1 / Indicate whether this message is protected by CMAC tuple
0b0: not protected
0b1: protected / Shall always be present
…
for (j=0; j<N_CSG_IDs; j++) { / N_CSG_IDs is the number of CSG
IDs belongs to this Operator ID.
CSGID / variable / The CSGID within the Operator ID. It
may be part of the BS ID, with certain
bits inside indicating its length. If the CSG has single BS, it may be of maximum length which is the LSB-24-bits of the full BS ID.
}
}
Capability Indicator / 16 or 32 / Indicate which capability configuration set the MS has. / Optional.

16.2.3.2 AAI-RNG-RSP

Table 679—AAI-RNG-RSP message Field Description

Syntax / Size (bit) / Description/Notes
Ranging Abort / 1 / Set to 1 when an ABS rejects the
AMS / Presented when an ABS
rejects an AMS
If (Ranging Abort == 1) {
…
SFID / 32 / FID in MZone should be assigned as
defined in section 16.2.6.4.1.3.1 per
each DL/UL connections.
}
} //End of else (Ranging
Abort==1)
Capability Indicator / 16 or 32 / Indicate which capability configuration set the MS has. / Optional. If the MS attached Capability Indicator on the RNG-REQ, but the BS response with null capability indicator, that means the BS does not recognize the capability indicator the MS attached. The MS may need to go through the sequent capability negotiation procedure.

------End of Proposed Text ------