RE: [rohc] operating assumptions (section 4.1)

[khiem.le@nokia.com]

Hi Micke,
 
I have not followed very closely the latest discussions on the ROHC mailing
list, so it could be that I have missed something, but I was wondering where
does that 1e-5 figure for error rate come from? The last time I saw some
data related to error rate was in the july 8 mail from Juha, giving some
answers from TSG RAN WG2 (excerpt below). Based on that mail, I think we
should set the worst case error rate (the one that lower layer MUST not
exceed) at 1e-2.
 
Khiem
 
------------------ Excerpt from Juha's mail of July 8
---------------------------------

Moi,

The TSG RAN WG2 (RAN2) discussed the questions presented by ROHC working

group in meeting #14, 3 - 7 July, Paris, France. The answers that RAN2 come

up are presented below after each copied question.

Q1: What range of residual bit error rate can be expected in compressed

RTP/UDP/IP headers? What is the residual bit error rate of a worst case were

error detection is provided but with the smallest possible link layer

checksum?

Lower layer of the UMTS are flexible and they can be configured by

several different ways. E.g. CRC length can be 0, 8, 12, 16 or 24 bits.

Furthermore, the RAN typically deals with the block error rate instead of

residual BER. However, RAN2 assume that real time traffic could be run over

a radio bearer which would produce residual BER in the range of 10-2 to

10-6. The RTP/UDP/IP header compression algorithm produced by ROHC should be

capable of operating in different conditions providing different residual

BER.

----------------------------------------------------------------------------
----------

Khiem

-----Original Message-----
From: EXT Mikael Degermark [mailto:micke@cs.arizona.edu]
Sent: Friday, September 08, 2000 12:41 PM
To: zhigang.liu@nokia.com
Cc: rohc@cdt.luth.se
Subject: Re: [rohc] operating assumptions (section 4.1)



Zhigang & others, 

I am going over the document right now, and have changed section 4.6 into
the 
following. I'll attempt a merge with 4.1.

Micke

4.6.  Requirements on lower layers

This chapter lists general ROHC requirements on an underlying link layer.
See also the ROHC lower layer requirements document [LLG].

Framing


The link layer MUST provide framing, which makes it possible to distinguish
individual frames. 

Length 

The link layer MUST indicate the length of frames to the decompressor. There
is no length information in compressed packet headers. 

Error protection 

The ROHC scheme has been designed to cope with residual errors in the
headers delivered to the decompressor. However, the lower layer MUST NOT
deliver a residual bit error rate larger than 1e-5. 



It is RECOMMENDED that at least the header part of frames are protected
using strong checksums. The error protection SHOULD ensure that packets with
errors in the header part are never delivered. 

Negotiation 

In addition to the packet handling mechanisms above, the link layer MUST
provide a way to negotiate header compression parameters. 

At 09:52 AM 9/8/00 -0500, zhigang.liu@nokia.com wrote:
>Hello Folks,
>
>In the current rohc draft (ver 01), there are two sections that seem
>to be redundant to each other: 4.1. Operating assumptions and 
>4.6. Requirements on lower layers.
>
>I guess it's probably an unintentional result of on-going editorial 
>work when we merged different proposals, as the case for many other 
>sections. Since lower layer guideline will address the issues in a 
>separate draft, I'd like to suggest that we keep the section 4.1 
>"operating assumptions" and remove section 4.6.
>
>I list at the end of this email some assumptions that are at least 
>needed for rohc protocol. Please give comments on whether they are 
>sufficient, so that we can finalize this section.
>
>I'm also working on the 4.5 encoding methods (merging texts addressing
>the same issue, adding some text e.g. offset IP-ID encoding, etc). It
>will probably be ready next Monday. 
>
>Br,
>Zhigang
>
>------------------------------------------------------------------
>
>4.1.  Operating assumptions
>
>packet length: the link layer can provide the length of a compressed
packet.
>
>(it is beneficial but not required to provide the length of a feedback
>packet)
>
>error detection: the link layer can provide reasonably good error detection

>for compressed headers and feedback packets. (Error protection is 
>beneficial but not required.)
>
>in order delivery: the link layer between the compressor and decompressor 
>preserves the order of packets being transmitted, i.e. the decompressor 
>(compressor) will receives the packets in the order they were sent by the 
>compressor (decompressor). (Note that packet misordering before compressor
>can be handled by rohc protocol)
>---
>Mailing list for Robust Header Compression WG
>Archive: http://www.cdt.luth.se/rohc/ <http://www.cdt.luth.se/rohc/> 
> --- Mailing list for Robust Header Compression WG Archive:
http://www.cdt.luth.se/rohc/