Subject: [rohc] Question about ROHC configuration

From: "Soyoung Lee" <[email-masked]>
Date: Fri, 30 Aug 2002 13:39:14 +0900

Dear ROHC experts,

I have some questions about ROHC implementation.

First, when I configure the ROHC parameters, shoud I always configure these parameters in the compressor and decompressor the same?
That is, the Uplink and Downlink have to be configured the same?
For voice service, I think those parameters to be configured symmetrically.
However, for streaming service (almost Downlink data), how should I do?
The UL and DL are also configured symmetrically or configured asymmetrically depending on the UL and DL condition?

In RFC3095, there is no mention about this condition.

Second, I wonder if it's possible to have several streams for one service at the same time.

Can anybody explain the my questions?

Thanks in advance.

Soyoung Lee

 ===========================
  Soyoung Lee
  LG Electronics Inc. Korea

  e-mail: [email-masked]
  phone: +82-31-450-7859
  fax: +82-31-450-7912
===========================

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 30 Aug 2002 10:03:44 +0200

Soyoung,

> First, when I configure the ROHC parameters, shoud I always
> configure these parameters in the compressor and decompressor
> the same? That is, the Uplink and Downlink have to be configured
> the same?

First of all, I am not totally sure which parameters you are
talking about. ROHC has a few parameters that must be agreed
between compressor and decompressor. These are the "Per-channel
parameters" listed in RFC3095 section 5.1.1, i.e. MAX_CID,
LARGE_CIDS, PROFILES supported, MRRU, and optionally FEEDBACK_FOR.
How these are configured/negotiated depends on the actual link
technology, where RFC3241 (ROHC-over-PPP) is a good example of
how such a negotiation can be defined.

RFC3095 (section 6.3) also lists a number of parameters suggested
as useful in an interface to a ROHC compressor or decompressor.
It should be noted that these parameters are for configuration
of a ROHC compressor OR decompressor, thus not subject to
negotiation. Remember also that the parameters listed are just
suggestions, an implementation might implement a subset of these,
an extended parameter set, or completely different parameters.
Which parameters that are useful depend of course on the actual
link technology the implementation is supposed to be used in.

Regarding your uplink/downlink question, I think that it is a
different question. RFC3095 does not consider specific link
integration, e.g. wireless links (as in your question).
For RFC3095, bi-directional communication (i.e. the fact that
you have both an "uplink" and a "downlink") has not in principle
affect the standard. RFC3095 defines how to do compression from
a compressor to a decompressor, and thus each direction 
corresponds to its own ROHC configuration. In your example, 
the downlink configuration is totally independent of the
uplink configuration, from an RFC3095 point of view. However,
this is of course a matter of how ROHC is integrated in the 
actual link technology, i.e. in the "ROHC-over-whatever"
standard applicable to your case. Note that the IETF ROHC WG
only defines ROHC-over-PPP, integration into other link
technologies must be addressed in other standard bodies.

> for one service at the same time.

ROHC can handle a certain number of concurrent packet streams,
depending on how ROHC is configured over the channel, i.e. 
whether large or small CID's are used. Small CID allows 16
concurrent streams, while large CID can support up to 16383.
With streams, we mean any packet stream compressed by a
ROHC profile, including "non-compressed" sent with ROHC
profile 0x0000.

Then, as usual, the actual link technology and implementation
restrictions might affect these limits.

Regards.
/Lars-Erik

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [email-masked]
Phone: +46 920 20 21 07
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc