RE: [rohc] Comments on Implementation parameters

[khiem.le@nokia.com]

Hi Krister,

> -----Original Message-----
> From: EXT Krister Svanbro [mailto:krister.svanbro@lu.erisoft.se]
> Sent: Monday, October 23, 2000 12:01 PM
> To: khiem.le@nokia.com
> Cc: rohc@cdt.luth.se
> Subject: Re: [rohc] Comments on Implementation parameters
> 
> 
> Comments below.
> 
> / Krister
> 
> khiem.le@nokia.com wrote:
> > 
> > Hi Krister,
> > 
> > Comments below.
> > 
> > Khiem
> > 
> > > -----Original Message-----
> > > From: EXT Krister Svanbro [mailto:krister.svanbro@lu.erisoft.se]
> > > Sent: Thursday, October 19, 2000 10:49 AM
> > > To: khiem.le@nokia.com
> > > Cc: rohc@cdt.luth.se
> > > Subject: Re: [rohc] Comments on Implementation parameters
> > >
> > >
> > > Khiem,
> > >
> > > Some comments below.
> > >
> > > / Krister
> > >
> > > khiem.le@nokia.com wrote:
> > > >
> > > > Hi,
> > > >
> > > > Section 6.3.1, CONTEXT_REFRESH: "This parameter may for
> > > instance be used
> > > > to do context relocation at e.g. a cellular handover that
> > > result in a change
> > > > of compression point in the radio access network." It is
> > > not a good idea to
> > > > send IR at handover, for the following reasons:
> > > > It is always bad when IRs (or IR-DYNs) have to be sent.
> > > Either the system
> > > > must be able to cope with the surge in bandwidth demand
> > > (when the header
> > > > size jumps from a few octets to a few tens of octets), or
> > > it has to steal
> > > > bits or even complete frames from the payload. In the
> > > latter case, the media
> > > > (e.g. voice) quality will be affected. In some cases, the
> > > payload will have
> > > > to be completely muted to make room for the larger header.
> > > On top of that,
> > > > the IR will have to be repeated a certain number of times,
> > > for robustness
> > > > reasons. If the voice is muted, then the break in
> > > communications is longer
> > > > than if there were no header compression, which 
> violates the ROHC
> > > > requirement on handover. Not to mention the impact on 
> compression
> > > > efficiency. Handovers should be seen as intrinsic part 
> of the normal
> > > > cellular operation. Therefore, solution for handover should
> > > not introduce by
> > > > design any impairment when it can be avoided. Keep in 
> mind that the
> > > > frequency of handovers can be significant in systems with
> > > small cell radius.
> > > > IRs and IR-DYNs do introduce impairments, they should be
> > > used only to
> > > > recover from error conditions, like we have defined so 
> far in ROHC.
> > >
> > > This points to an optional alternative to handle handover 
> without any
> > > other mechanism outside ROHC. Then I guess it is another question
> > > whether there need to be a more complex  context 
> relocation. However,
> > > this does however provide the simplest possible solution,
> > > restart ROHC.
> > 
> > KL: There are two options: full reinitialization of the 
> ROHC process at
> > handover by sending IRs, or seamless continuation by doing 
> context transfer.
> > I think it should be clear in the ROHC document that ROHC 
> does not preclude
> > any of these options. That was my point. I commented 
> because the sentence
> > you proposed mentioned the first option, while nothings was 
> said about the
> > second option. I don't have any problem if the text I sent 
> on handover and
> > context transfer 
> (http://www.cdt.luth.se/rohc/msg01274.html) is included in
> > the document as well. That will make clear that the second 
> option exists.
> 
> -KS- Yes there are two options, however in my mind the second option,
> context relocation between RNS is clearly link layer dependent. WCDMA
> will do in one way, CDMA2000 will do another, etc. However, context
> transfer using IR-header is independent of system, hence, it should be
> in the ROHC draft. Regarding the second option, I am sure that it is
> forgotten about :-) However, it is for other bodies to standardize in
> their specific systems, if we are not going to use mobile IP for it...

KL: WCDMA may do context relocation differently from CDMA 2000. However,
systems that will use ROHC can be classified in two categories: those that
do not transfer the context, and reinitialize with IRs, and those that
transfer the context. For systems belonging to the second category, it is
very useful to point out the pitfalls and suggest some solution approaches,
especially if they are common. That is the intent of my text. Note that it
does not make any assumption about the transport or protocol used between
the old and new compressor/decompressor points to transfer the context (BTW,
what is the relevance of your reference to Mobile IP?). It just specifies
some necessary actions/behavior of the old and new compressor/decompressor
during the transfer to ensure proper operation. 

> 
> It would be nice to see the cost associated with these two 
> options in a
> realistic system environment, to see how big an issue this really is,
> what the gain of a more complex scheme is.
> 
> > 
> > >
> > > The channel will need to cope with IR headers anyway,
> > if a system must
> > > do framstealing
> > 
> > KL: The fact that the channel will have to cope with IRs 
> does not mean that
> > IRs should be used if there is a better way to handle 
> handovers. IR and
> > framestealing should be a last resort and used only to 
> recover from severe
> > events such as context invalidation, etc.
> > 
> > then I guess that it would also be able to
> > > choose and or
> > > design which context relocation mechanism to use. 
> Further, it seems as
> > > you assume that context relocation will be frequent, however
> > > that is of
> > > course difficult to know. However, if the compressor resides
> > > in a radio
> > > network controller with many base stations, then these context
> > > relocations will be very infrequent. I am pretty sure that
> > > this will be
> > > the case in the roll-out of 3g systems such as e.g. WCDMA.
> > 
> > KL: We don't know yet how the WCDMA system with ROHC will 
> be architected.
> > Even if it turned out that the frequency of context 
> relocations in WCDMA is
> > low, ROHC is not designed just for WCDMA. WCDMA is a 
> primary case of ROHC
> > application, but not the only one. What about other systems 
> besides 3G?
> 
> -KS- I would say that ROHC over WCDMA is a very important 
> case. Further,
> systems are usually designed to avoid serving RNC relocations 
> as far as
> possible simply since it is complex and cost transmission resources.

> 
> > 
> > >
> > > >
> > > > The alternative is to transfer the context from the old
> > > compression point to
> > > > the new compression point, to jump start the
> > > compression/decompression
> > > > process at the new point. With the context transfer, in
> > > most cases, the new
> > > > point an resume where the old point left off. That is, if
> > > the old point was
> > > > in SO (FO) state, the new will continue in SO (FO) state, etc.
> > >
> > > Yes, that is an alternative for the kind of links/systems 
> that would
> > > require that technique. That is a possible topic for ROHC 
> over X docs,
> > > and the parameter above does not preclude that. It is simply an
> > > alternative.
> > 
> > KL: I agree. That is why I provided that text on handover 
> and context
> > transfer, so the ROHC users are aware of all the alternatives.
> 
> -KS- OK

KL: If you agree we should describe both options in the ROHC document, we
don't need to spend any more time on this.

> 
> > 
> > >
> > > >
> > > > I sent a contribution to the ROHC mailing list to describe
> > > the context
> > > > transfer process on June 16
> > (http://www.cdt.luth.se/rohc/msg00508.html) as a
> > > result of an action point from the Stockholm meeting, and 
> I did not see
> > any
> > > comment or objection.  The intent is not to specify the 
> actual procedure
> > and
> > > protocols used to transfer (which is system dependent), 
> but point out some
> > > key issues and pitfalls related to context transfer and 
> outline possible
> > > solutions. In particular, the behavior of the old and new
> > > compressor/decompressor at some key points of the context 
> transfer can be
> > > described. I'll develop a shorter version of the original 
> contribution (to
> > > be sent in 1 or 2 days) that I propose to include in section 6.
> > >
> > > Section 6.3.2, TIMER_BASED_TS_COMPRESSION: When the 
> parameter is set to
> > YES,
> > > why is it "SHOULD" and not "MUST"? Does it mean the 
> parameter has a fuzzy
> > > interpretation? I can understand that some decompressors 
> may not have a
> > > clock (although I really cannot visualize that in 
> practice), but then it
> > > should be reflected in the value of the parameter. Once 
> the parameter is
> > set
> > > to YES, it must unambiguously use timer-based.
> > 
> > If the clock is not good enough, too much jitter etc, then the
> > times-based scheme should not be used, hence, there is a 
> possibility to
> > turn of the scheme if i fails. Hence, the SHOULD.
> > 
> > KL: If you don't want or cannot use the timer-based 
> compression, why don't
> > you set the variable to NO?
> 
> -KS- Because you don't before you start the compression scheme whether
> the timer-based scheme will work. You hope so, start and if 
> it fails you
> must have the possibility to backoff.

KL: Why don't set it to YES and then to NO if you have to back off? Better
still, use the variable propsoed by Zhigang.

> > 
> > >
> > > Khiem
> > >
> > > ---
> > > Mailing list for Robust Header Compression WG
> > > Archive: http://www.cdt.luth.se/rohc/
> > ---
> > Mailing list for Robust Header Compression WG
> > Archive: http://www.cdt.luth.se/rohc/
>