Skip to main content

Liaison statement
LS on RoHC utilization for Ethernet header compression

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2019-03-25
From Contact David Koziol
To Group IETF
To Contacts The IETF Chair <>
Cc The IESG <>
The IETF Chair <>
IEEE 802<>
Response Contact
Purpose For action
Deadline 2019-04-18 Action Needed
Attachments RP-182090_rev
1. Overall Description:

3GPP RAN Work Groups are at the moment performing a study on RAN support for
Industrial Internet of Things, objectives of which are described in RP-182090,
as attached. One of the goals of the study is to analyse potential enhancements
for more efficient Time Sensitive Networks (TSN) support over 5G/NR system and
one of the studied features is Ethernet header compression: c)      Ethernet
header compression (RAN2): i)      Analysis of the benefits and the scenario
(e.g. what are the formats and size of Ethernet frame to be considered, are
VLAN fields included, protocol termination etc.). ii)     Definition of the
requirements for a new header compression.

RAN2 WG has discussed the above topic and the result has been captured in the
Text Proposal intended for Technical Report of the 3GPP Study Item on NR
Industrial IoT. Since RoHC is a well-established standard for header
compression of VoIP packets in 3GPP, one of the considered options is to reuse
it also for Ethernet header compression on NR air interface. The related
description from the attached Text Proposal is copied below for convenience:

ROHC-based solution

Ethernet header compression may build on the ROHC-framework, which is currently
used for IP-header compression and applied on PDCP layer. A ROHC profile
specific to the Ethernet header would need to be defined, meaning that the
existing ROHC framework and features would be reused and do not need to be
developed. R2-1817913 analyses the benefits of this approach. For example,
robustness of compression against packet losses and in-built handling for
multiple flows. On the other hand, ROHC profiles are defined by IETF for
TCP/UDP/RTP/IP protocols, and Ethernet is defined by IEEE. It is unclear how
3GPP can define a new ROHC profile and if/how IETF/IEEE adopts such new ROHC
profile. In addition, ROHC profile identifiers may need registration with IANA
[ref]. Such collaboration/liaison with other standard bodies may add
uncertainties and could delay the work completion.

As can be seen, 3GPP RAN WG2 is not certain about the procedural aspects of
defining a new RoHC profile for Ethernet header. Therefore, 3GPP RAN WG2 would
like to ask IETF and IEEE the following questions:

Q1: Does IETF or IEEE have any concerns with 3GPP defining new RoHC profile for
Ethernet header compression? Q2: Does IEEE have any concern with 3GPP
specifying a new Ethernet header compression algorithm? Q3: In case 3GPP is
allowed to develop RoHC profile for Ethernet header compression, does it have
to be registered with IANA. If yes, how long can such process take? Q4:
According to IETF, what are the actions needed of 3GPP to specify and maintain
a ROHC profile? 3GPP RAN WG2 would like to clarify that it intends to specify
the new profile for its own purposes mainly, as described above, but would have
nothing against IETF, IEEE or any another party using the profile, once it is
defined. 3GPP RAN WG2 is open to collaboration with IETF/IEEE on new profile
definition, but would like to indicate that the target completion date of the
related work is end of 3GPP Rel-16, which is planned for Q1 of 2020.

2. Actions:
ACTION:   RAN2 respectfully asks IETF to reply to questions 1, 3 and 4 above
and provide any other guidance they see fit, if any.

ACTION:   RAN2 respectfully asks IEEE to reply to question 1 and 2 above and
provide any other guidance they see fit, if any.

3. Date of Next TSG-RAN WG2 Meetings:
3GPP RAN2#105bis        08 - 12 Apr 2019                China
3GPP RAN2#106           13 - 17 May 2019                USA