IEEE C802.16maint-08/198
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
ROHC Classification Changes
Date
Submitted
2008-04-19
Source(s)
Muthaiah Venkatachalam
Intel Corp.
Phillip Barber
Huawei Technologies Co.
E-mail:
muthaiah.venkatachalam@intel.com
Guenhwi Lim, Jicheol Lee
Samsung
geunhwi.lim@samsung.com
jicheol.lee@samsung.com
Peretz Feder
pfeder@alcatel-lucent.com
pbarber@huawei.com
Alcatel Lucent
vladimir.yanover@alvarion.com
Vladimir Yanover
Alvarion
Re:
P802.16Rev2/D4
Abstract
Purpose
Notice
Release
Patent
Policy
Adoption toward REV2/D5
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.
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.
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>.
ROHC Classification Changes
Muthaiah Venkatachalam,Phillip Barber, Jicheol Lee, Geunhwi Lim, Peretz Feder, and Vladimir
Yanover
Intel Corp., Huawei Technologies Co. Samsung Electronics, Alcatel-Lucent, and Alvarion
Problem:
1
IEEE C802.16maint-08/198
Connections can be set up to transfer regular IP packet or Compressed IP packets (ROHC). So transmitter (BS
or MS) need to classify all inbound IP packets whether it shall compress them or not. The IEEE 802.16 standard
is already describing one to one mapping between ROHC channel and an SF ID (see the section 5.2.7.2), and
each service flow has classification rules when it is created. Therefore the classification rules of the relevant
service flow shall be used for classifying IP packets to be compressed by corresponding ROHC channel.
This contribution clarifies that how SS and BS exchanges the IP classification rules when SS or BS creates
ROHC enforced connection and the exchanged IP classification rules shall be used for classifying IP packets to
be compressed.
Additionally, this contribution includes informative description on the interface between ROHC compressor and
CS SAP for ROHC packets to make ROHC operation easy for understanding and implementation.
2
IEEE C802.16maint-08/198
Remedy 1:
Since ROHC channel has one-to-one relationship between the associated service flow, the classification from
ROHC PDU to the associated service flow is not required to be transferred over the air. However, when PCC
based system is used for indicating which IP flows to be mapped to ROHC SF, IP classification Rule is required
to be transferred.
In P802.16REV2/D4, page 39, line 26, modify the text as:
5.2.7.2 Compressed-IP-header classification rules
The term ‘ROHC channel’ is defined in RFC3095 and further clarified in RFC3759. The 802.16 standard
does not attempt to redefine the definition of ‘ROHC Channel’.
A single ROHC channel, which may have multiple ROHC contexts, shall have a one-to-one mapping to a single
service Flow (SFID) flow. Since there is a one-one-mapping between a ROHC channel and an SF ID, there is no
need to have any additional classifiers associated with that Service Flow. The method of associating a ROHC
channel with a Service Flow is left to the implementation. One or more ROHC channels can be established for
an SS.
For a service flow mapped to a ROHC Channel, the ROHC parameters associated with the ROHC Channel shall
be negotiated by including the ROHC Parameter Payload TLV (11.13.38) in the DSADSx-REQ/RSP
messages(for a new Service Flow creation) or the DSC-REQ/RSP messages (for an existing Service Flow).
Note: The associated service flow which is mapped to a ROHC channel is called as an ROHC service
flow.
In order to classify IP packets to be compressed, when the ROHC service flow is created, the service flow
encodings transmitted to create the service flow shall include those IP specific classification parameters
(11.13.19.3.4.2 through 11.13.19.3.4.7, and 11.13.19.3.4.16) necessary to assist the higher layer application in
formulating classification rules if the BS is required to indicate those IP classification parameters for the uplink
connection in order for the MS to apply the IP classification rule, or MS is required to indicate those IP
classification parameters for the downlink connection in order for the BS to apply the IP classification rule.
If the MS has an alternative way to get its own IP classification rule for the ROHC service flow, those IP
specific classification doesn’t have to be transmitted to the MS.
3
IEEE C802.16maint-08/198
Remedy 2:
Add the informative definition of ROHC-SAP into the Annex C.2. ROHC-SAP is implementation specific
hence all definitions and operations for ROHC-SAP are informative.
In P802.16REV2/D4, page 1730, line 1 insert the following:
C.2 ROHC SAP
ROHC SAP is implementation specific. This section describes an example of ROHC SAP.
C.2.1 ROHC Classifier
ROHC Classifier is an entity which receives inbound IP packets and classifies whether the IP packet shall be
compressed by ROHC or not. The classification rules should be given by a connection creator. The ROHC
classifier function may reside within ROHC CS or separately depending on implementation. ROHC
classification should be done before actual ROHC compression. If a packet is classified as to be compressed by
ROHC, the packet should be sent to ROHC compressor.
C.2.2 ROHC Compressor
ROHC Compressor is an entity which receives classified IP packets and compresses it using ROHC. The ROHC
Compressor send a ROHC compressed packet to ROHC SAP.
C.2.3 ROHC De-compressor
ROHC De-compressor is an entity which receives ROHC compressed packets from ROHC CS and decompresses it. The de-compressed IP packet is forwarded to upper layer.
C.2.4 ROHC SAP parameters
The ROHC_SAP parameters enable the ROHC compressor to pass information to the ROHC CS so that ROHC
CS does not need to interpret inbound ROHC compressed IP protocol headers in order to map the compressed
IP data packets into proper 802.16 MAC connections.
The ROHC SAP parameters also enable ROHC Classifier to pass information to the ROHC Compressor so that
ROHC Compressor may identify SFID of inbound IP Packet to be compressed and tag correct SFID.
Service flow ID (SFID)
Unique identifier to identify a unidirectional service flow for an SS. The higher layer application shall
map the combination of SFID and SS MAC Address directly to a MAC connection ID. During
connection/service flow establishment, the 802.16 control plane function shall provide the higher layer
application the mapping information.
ROHC channel ID
ROHC Compressor and De-compressor may have multiple ROHC channels. The ROHC channel
indicated by the ROHC channel ID handles compressed IP packet or raw IP packet for compression or
de-compression.
SS MAC Address:
48-bit unique identifier used by SS.
LENGTH:
Number of bytes in DATA.
DATA:
The payload delivered by the ROHC compressor to the ROHC CS, or by the ROHC CS to the ROHC
compressor.
4
IEEE C802.16maint-08/198
5