RE: [rohc] Supporting multiple compression contexts

[khiem.le@nokia.com]

Hi,

Since I am not sure everybody is aware of it, back in June, in response to
an action point from the Stockholm interim meeting, I sent to the ROHC
mailing list some material on context relocation at handover. Refer to my
mail of 6/16, titled "Contribution on handover and relocation".
You can find it at 
http://www.cdt.luth.se/robhc/msg00508.html. 

Khiem



-----Original Message-----
From: EXT Krister Svanbro [mailto:krister.svanbro@lu.erisoft.se]
Sent: Monday, July 31, 2000 9:08 PM
To: rajeev.koodli@nokia.com
Cc: rohc@cdt.luth.se
Subject: Re: [rohc] Supporting multiple compression contexts


Some comments below.

Cheers,   Krister

> > This assumes that there is a need to move the context at e.g.
> > handover.
> > In WCDMA system for example, the compression algorithm is
> > located at the
> > RNC, which handles several Node B (base stations). Hence, the
> > compression point is above (or at the same place as) the handover
> > combining point. Hence, there is no need to transfer the
> > context at soft
> > and softer handovers, which are by far the most usual handover events.
> > At RNC relocation, the context might be moved, but if this
> > happens very
> > seldom, as I believe it will do, it could be just as easily to simply
> > restart the compression scheme. Hence, I would not say that a
> > compression context transfer mechanism is mandatory to standardize. It
> > might sence in some cases and in some systems, in others it does not.
> > Futher, I believe it is very important that such a eventual transfer
> > mechanism is really fast, fast enough to make sense for a real-time
> > service as voice.
> >
> 
> Regardless of where exactly the context is located, you will have the need
> to relocate it, e.g., during RNC relocation as you mention above. It seems
> that on one hand you are saying there is no need to relocate the context,
on
> the other hand you mention the context relocation has to be really fast! I
> would go with the latter.

I'm sorry if I was fuzzy :-( I was trying to say that I am not sure if a
separate mechanism for doing context relocation (apart from the header
compression scheme) is needed. And IF it is needed, it has to be fast.

> 
> A particular architecture may present itself favorably to infrequent
context
> relocations, which BTW would also be good for an IP-based solution!, but a
> generic mechanism must exist since an IETF solution impacts many different
> types of networks.
> 
> > >
> > > Based on past discussions, rohc needs to define what (context)
> > > information needs to be transferred and how the old and new
> > compression
> > > entities act before, during, and after handover. The exact
> > transmission
> > > mechanism itself is a separate issue. Mobile IP can be one of the
> > > mechanisms.
> >
> > I am not sure that it is within the scope of ROHC to standardize the
> > actual transfer of the context. We should instead focus on the
> > compression scheme and the tight time schedule we have to
> > complete this.
> 
> Right. But, rohc has to provide a definition of a context for transfer
> purposes. And, I believe that this context would depend on the compression
> profile type. For starters, it would be just fine to start with one
profile
> and define a context.

Yes, it is good if we could do this. This is probably also needed for
eventual work on context relocation on the link layer level.


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