et to "on." [1] The BS responds with a capability negotiation response message with the intersection of the mobile station's and the base station's capabilities set to "on." The problem with this way of capability negotiation in IEEE 802.16- 2009 standard is that the length of the messages can grow excessively large without the possibility of fragmentation (this problem has been fixed for some MAC management messages that can be frag- mented in the latest revision of the standard [1]), resulting in increasing error probability and reliability 4.1 IEEE 802. 16m mobile station state diagrams issues for the cell-edge users. Furthermore, the BS and the MS are unnecessarily required to negotiate some capabilities and parameters that are required for normal operation of the system, resulting in inefficient use of radio resources, increased network entry/re-entry latency, and compromising reliability. The IEEE 802.1 16m simplifies the capability negotiation step by assuming that the MS, by default, is expected to support the baseline capabilities. 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 identified by its corresponding CAPABILITY_INDEX. If the MS is capable of supporting higher revisions of physical layer or medium access control layer protocols or further wishes to use enhanced features, it sends a capability negotiation request message to the BS indicating the highest CAPABILITY_INDEX that it can support. The CAPABILITY_INDEX = 0 indicates the default capability index and basic feature set or configuration parameters and may not need to be signaled. Upon receipt of the capability negotiation request message containing the CAPA- BILITY_INDEX from the MS, the BS determines whether it could allow or could support the requested feature set or the MAC and/or PHY protocol revisions. If the BS does sup