Subject: [rohc] Insufficient bits to send Unscaled TS in UO-1-ID + ext3

From: [email-masked] (Sukanta Kumar Hazra)
Date: Fri, 11 Oct 2002 01:41:16 +0800

Hi!

I am faced with the problem that a maximum of 29 bits of TS can be sent
using UO-1-ID + ext3.

Here is my understanding of RFC 3095 (Profile 1) and ROHC implementors
guide.

UO-1-ID + ext3 is used to compress a transient change in packet stream,
without updating the context (except TS, IP-ID and SN).

I want to send Unscaled TS using ext3 for a UO-1-ID packet. However it
is only possible to send maximum of 29 bits. If I make use of another
packet type (UOR-2-TS) it will result in context update. How then does
the compressor send the Unscaled TS.

Thanks for any suggestions.

Regards,
Sukanta

-- 
--------------------------------------------------------------------
Sukanta Kumar Hazra <[email-masked]>      
Institute for Communications Research
PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc
PGP-ID: 0x8E084AD5 
Key-Fingerprint: 9C0D B00C C62A 7059 5314  99FC CE90 478A 8E08 4AD5
--------------------------------------------------------------------
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Vicknesan Ayadurai <[email-masked]>
Date: Fri, 11 Oct 2002 09:47:47 +0200 (CEST)

Hi Sukanta,

> without updating the context (except TS, IP-ID and SN).

From my understanding, in U/O modes, all ROHC packets should update
the context. This is especially the case at the compressor end.

At the decompressor, some elements of the context are explictly
conveyed (such as SN in a UO-0 pkt), while the rest are implcitly
conveyed via the CRC i.e., these (such as ID and TS) can be
interpolated from the above element(s). The ENTIRE context here is
then updated ONLY when the CRC of the rebuilt header is correct.

Hence, sending a (UO-1-ID + ext3) or a (UOR-2-TS) would have the same
context-updating effect. If you need to send 32-bits of unscaled TS,
sending and IR-DYN could be one (perhaps less-efficient) solution.

Regards,
vick.
+----------------------------------------------------+
 Vicknesan AYADURAI <[email-masked]>
 SwitchLab, Ericsson Research - Stockholm, Sweden
 Phone :  +46 8 5087 8084 / Fax:  +46 8 5087 8090
+----------------------------------------------------+

---

From: [email-masked] (Sukanta Kumar Hazra)
Date: Fri, 11 Oct 2002 18:26:54 +0800

Hi! vick,

> sending and IR-DYN could be one (perhaps less-efficient) solution.

If sending a UO-1-ID and UOR-2-TS have the same context updating effect
at the decompressor side. How can we encode a transient change in a
field's value? The compressor would have to send the fields original
value again, until it is confident that the decompressor has the value.
This step would have been needless if the value was not changed in the
context at the decompressor side.

Someone please explain section 4.9 and 4.10 of the implementor's guide.

My understanding is that if a value such as the TTL changes while the
compressor is in FO state, then the new TTL value can be sent to the
decompressor using UO-1-ID + ext3. This would not modify the value
of TTL in the context at the decompressor side. Once the TTL value has
returned to the original one, the compressor does NOT need to go through
the confidence building phase, by sending the TTL value again.

Regards,
Sukanta