1. New Connection Identifier Approach
June 2009
doc.: IEEE yy/xxxxr0
June 2009
New Connection Identifier Approach
IEEE P Wireless RANs Date: xx
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
Carl R. Stevenson as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
>
Ranga Reddy, US Army
Ranga Reddy, US Army

2. June 2009
doc.: IEEE yy/xxxxr0
June 2009
Abstract
This contribution proposes a new way to treat connection identifier (CIDs) in the MAC. The purpose of this method is to reduce overhead, optimize processing, and reduce storage requirements for maintaining CPE context at both the BS and CPE.
Ranga Reddy, US Army
Ranga Reddy, US Army

3. Current (in v2.0) CID Description (where m = max # of supported CPEs)
June 2009
Current (in v2.0) CID Description (where m = max # of supported CPEs)
CID
Value
Description
Initial Ranging CID
0x000
Used by CPE and BS during initial ranging
Basic CID
0x001 - m
The same value is assigned to both the DS and US connection.
Primary Management CID
m+1 – 2m
Multicast Management CID
2m+1 – 3m
Shall only be used in the DS direction by the BS. Allows management commands to be addressed to a group of CPEs
Transport CIDs and Secondary Management CIDs
3m+1 – 0xEFE
For the secondary management connection, the same value is assigned to both the DS and US connection.
Multicast Polling CIDs
0xF00 – 0xFFD
A CPE may be included in one or more multicast polling groups for the purposes of obtaining bandwidth via polling . Theses connections have no SF.
Padding CID
0xFFE
Used for transmission of padding info by CPE or BS.
Broadcast CID
0xFFF
Used for broadcast information transmitted on the downstream to all CPEs.
Ranga Reddy, US Army

4. New Method for Treating CID
June 2009
doc.: IEEE yy/xxxxr0
June 2009
New Method for Treating CID
Proposal is to break up the CID into 2 entities:
Station ID (9 MSB): ID that is unique to CPE or multicast group
Flow ID (3 LSB): ID that identifies a traffic flow that is mapped to a particular Station ID
The figure below depicts this breakdown
Ranga Reddy, US Army
Ranga Reddy, US Army

5. Station ID Station ID is broken down as follows...
June 2009
Station ID
Station ID is broken down as follows...
Station ID space split up between CPEs and Multicast Groups, using m, the maximum # of CPEs supported in a cell.
With a 9-bit Station ID, 512 stations are possible.
CPE Station ID: 0x001 – m
Multicast Group ID: m+1 – 0x200
Station ID = 0x000 (see Slide 8), we’ll call this the Cell Station ID
Ranga Reddy, US Army

6. June 2009
Flow ID
Flow ID is 3 bits long. It’s treated differently, based on whether or not the Station ID is a CPE (Unicast) Station ID or a Multicast Station ID.
When Station ID is Unicast:
000 = Basic Flow
001 = Primary Management Flow
= Unicast Transport Flows
111 = Secondary Management Flow if Secondary Management connection is enable, or reserved for vendor/operator specific use
When Station ID is Multicast:
000 = Multicast Polling Flow
001 = Multicast Management Flow
= Multicast Transport Flow
111 = Padding Flow ID, when Station ID = 0x000, otherwise reserved
Ranga Reddy, US Army

7. What happened to “Well Known” CIDs in Table 299?
June 2009
What happened to “Well Known” CIDs in Table 299?
CIDs are constructed from the Station ID + Flow ID
CPE Basic CID
Unicast Station ID || Basic Flow ID (000)
CPE Primary Management CID
Unicast Station ID || Primary Management Flow ID (001)
CPE Transport CID
Unicast Station ID || Unicast Transport Flow ID ( )
Multicast Polling CID
Multicast Station ID || Multicast Polling Flow ID (000)
Multicast Management CID
Multicast Station ID || Multicast Management Flow ID (001)
Multicast Transport CID
Multicast Station ID || Multicast Transport Flow ID ( )
Ranga Reddy, US Army

8. What happened to “Well Known” CIDs in Table 299? (continued)
June 2009
What happened to “Well Known” CIDs in Table 299? (continued)
Broadcast, Initial Ranging, and Padding CID are based off the “Cell Station ID” alluded to on slide 5
Broadcast CID
= Cell Station ID || Multicast Management Flow ID (001) = 0x001
Initial Ranging CID
= Cell Station ID || Multicast Polling Flow ID (000) = 0x000
Padding CID
= Cell Station ID || Padding Flow ID (111) = 0x007
Ranga Reddy, US Army

9. Why use this new approach?
June 2009
Why use this new approach?
The new approach is an attempt to reduce overhead and optimize use of system resources:
Reduce size of GMH (by 9 bits). This may not seem like much, but over many PDUs it could add up.
Bursts are then identified by signaling the Station ID in the DS/US-MAP IE
We’re suggesting using only maximum of 5 Transport CIDs per CPE, one per service class. All SF’s pertaining to (unicast/multicast) traffic can be mapped onto one of these Flow IDs. If there is prioritization differentiation within a service class, this requires the CPE, when transmitting data to take into account is current bandwidth allocation and QoS context when deciding how to pack/fragment MAC SDUs into PDUs for transmission
The new behavior is optimized, so BS’s and CPE’s only have to maintain as much information about the connections. This may be useful when handling certain operations such as Timeout or performing HO (a potential future capability), as well as reducing the memory/storage/processing requirements for a CPE’s connections at both the CPE & BS.
Ranga Reddy, US Army

10. June 2009
Text Proposal
If the WG decides to adopt this approach then text modification in many areas throughout the draft are required. A contribution or set of contributions with the actual text modifications will be brought in at a later date.:
Introduce Station ID and Flow ID terms into Clause 3
GMH in Table 3, Section ; CID field changed to Flow ID and size reduced to 3 bits
DS-MAP IE in Table 37, Section ; Remove brackets around “IF (INCLUDE_CID)” block, change CID to Station ID and change size to 9 bits
Remove CID Switch Extended IE, section
US-MAP IE in Table 48; change CID to Station ID and change size to 9 bits
RNG-RSP IEs in Table 59, Section ; remove Basic CID and Primary Management CID & replace with Station ID
Review MAC management messages and adjust references to CID to match Station ID or Flow ID accordingly
Review references to CID in draft and make sure they align with the new usage as defined by this contribution
Ranga Reddy, US Army

11. June 2009
References
Hamiti, Shkumbin, “IEEE m System Description Document [Draft]”, IEEE m-08/003r9a, May 2009.
Ranga Reddy, US Army