Subject: [rohc] ROHC and re-ordering channels

From: Pete McCann <[email-masked]>
Date: Tue, 07 Mar 2006 14:13:43 -0600

Hi,

I understand that part of the new ROHC profiles specification
will deal with channels that can mis-order packets, but that
there has been little information on what kind of real-world
scenarios can cause this behavior.

In the HRPD air interface specification at:

http://www.3gpp2.org/Public_html/specs/C.S0024-A_v2.0_050727.pdf

see especially section 13.2.2.4 and 13.3.1.3.2.2.4.

In an HRPD system, there is retransmission at the physical layer,
the MAC layer, and the RLP layer.  Retransmissions at the
MAC and RLP layer can be enabled or disabled on a per-flow
basis and for voice-over-IP are likely to be turned off.

At the physical layer, however, the Hybrid ARQ scheme works
by sending any NACKed packets up to 3 additional times during
interlace periods that consist of 3 packets each.  That
is, we can have the following sequence of packets transmitted
in the worst case:

123 (1st interlace, 2 & 3 ACKed but 1 NACKed)
145 (2nd interlace, 4 & 5 ACKed but 1 NACKed again)
167 (3rd interlace, 6 & 7 ACKed but 1 NACKed again)
189 (4th interlace, 1 finally ACKed and delivered along with 8 and 9)

Thus, the maximum out-of-order would be 7 - 1 = 6.

The MAC retransmission could introduce additional out-of-order
delivery to the RLP layer.  Note that each of the packets above
contain an RLP sequence number but RLP re-ordering would be
turned off for voice-over-IP flows.  This sort of re-ordering
should be done end-to-end at the RTP layer to reduce the total
amount of delay in the system.

Anyway, I hope the above discussion clarifies the need for
a ROHC that handles channels with mis-ordering.  Hopefully
we will see the new profiles draft soon that handles this.

-Pete

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc