IEEE 802.16m CS Layer
Document Number: IEEE C802.16m-09/1002
Date Submitted: 2009-04-27
Source:
Aran Bergman (aran.bergman@intel.com)
Muthaiah Venkatachalam (muthaiah.venkatachalam@intel.com)
Venue: Re: Call for contributions on CS
Intel Corporation
Base Contribution:
Purpose: Discussion and approval of the proposal into the IEEE 802.16m AWD
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:
<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 >.
SDD Text
• 10.7 Convergence Sublayer
IPCS or GPCS is used to transport packet data over the
air interface. For GPCS the classification is assumed
to take place on layers above the CS. Relevant
information for performing classification are
transparently transported during connection setup or
change.
2
Current Problems
• HO implications
– Need to handle HO between 16e and 16m (or between LZone to
MZone) and vice-versa
• Signaling
– IPCS signaling for classification and PHS rules is well defined in
16e. This is not the case for GPCS – need to transport signaling
to the higher layer.
• CRC
– To support IEEE 802-2001 requirements, we may need to add
CRC per SDU.
• Implementation Issues
– Classification needs to know about the SFIDs available / active
3
Proposed Solution
• Support IPCS only
– Use Raw IP CS type (defined in Rev2) that
will be able to transport both IPv4 and IPv6
(based on the version nibble at the
beginning of the packet). RoHC will be
supported on a different connection than
IPv4 and IPv6.
– Another option – adding a “protocol type”
field to each packet in a new “multiplex” CS
type.
4
Raw IP CS
• Rev2 defines CST 113 – (Raw) Packet IP (no
version)
– Can carry both IPv4 and IPv6 on the same connection,
based on the version field of the IP packet
– Classification rules can be applied according to the
version of the packet and the length of the addresses,
or
– Classification rules can be applied according to a
match between the version of the packet and the cst of
the rule
5
Protocol ID
• To multiplex several protocols (Ethernet, IPv4,
IPv6, RoHC and/or others)
– add a Protocol ID field at the beginning of the
SDU (after PHS/RoHC) that identifies the protocol
• Needed so the receiver will parse the SDU correctly
(e.g., forward the packet to the RoHC decompressor)
– Requires to add a new CS type (multiplex CS?)
Protocol ID
SDU
6
CRC added by CS/MAC Layer
• IEEE 802-2001 requires the following error rates for wireless
physical media:
– Within a single access domain, the probability that a MAC Service Data Unit
(MSDU) is not delivered correctly at an MSAP of an intended receiving MAC
service user, due to the operation of the Physical layer and the MAC protocol,
shall be less than 8e-8 per octet of MSDU length.
– The probability that an MSDU delivered at an MSAP contains an undetected
error, due to operation of the MAC service provider, shall be less than 5e-14
per octet of MSDU length
• Current PHY CRC16 (on entire burst) does not support these error
rates
– Either we support CRC added and checked at the CS layer (per SDU) , which
reduces overhead for UL cell-edge scenarios, or
– at the MAC layer (per PDU).
7
CRC at the CS Layer – Cell-Edge Scenarios
• In UL cell-edge scenarios, the MS fragments
large SDUs into a large number of fragments
(since allocations are small)
– Using CRC per PDU would increase total
overhead per SDU. For 1500 byte SDUs which are
fragmented into 25 fragments, we add 100 bytes
(which are 6.7% of the original SDU).
– Using CRC per SDU keeps overhead small
(0.27%)
8
Proposed Text
• No need to add/change anything to support IP
CS (TLV [145.146].28 with a value of 14
covers this option).
• To support multiplexing several protocols over
the same connection:
– See contribution#1001
9