[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] Comments on Implementation parameters
Moi Krister,
A comment to the frequency of relocations. If the user is located close to
the border of two RNS (radio network subsystem, Node B's controlled by one
RNC) the relocations can be rather frequent irrespective if the size of RNS.
-jk-
> -----Original Message-----
> From: EXT Krister Svanbro [mailto:krister.svanbro@lu.erisoft.se]
> Sent: 19. lokakuuta 2000 18:49
> 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.
>
> The channel will need to cope with IR headers anyway, if a system must
> do framstealing 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.
>
> >
> > 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.
>
> >
> > 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.
>
>
>
> >
> > 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/
>