Subject: [rohc] Synchronization of ROHC compressors for single frequency network operation

From: "Kumar Vinod-A20689" <[email-masked]>
Date: Wed, 23 May 2007 13:09:18 +0800

Hi All,
 
3GPP, as part of its long term evolution (LTE) work,  is currently
discussing single frequency network (SFN) operation for offering
multicast and broadcast multimedia services (MBMS) . In SFN operation,
all the eNBs (base stations) of the SFN area transmit identical content
of an MBMS service over identical air interface resources (i.e., on
identical time-frequency slots). The clocks at all the eNBs of the SFN
area are synchronized.
 
One of the issues is the location of ROHC for SFN operation. For MBMS,
U-mode is currently the preferred mode of operation. If ROHC compressor
is placed in a centralized node above the eNBs, then all the eNBs will
receive identical packets so that content synchronization over-the-air
can be achieved. However, if ROHC compressors are located at the eNBs,
then it is important to ensure that all ROHC compressors in the SFN area
choose identical packet types with identical content at all times. Note
that packet losses may occur over the backhaul where some eNBs may
receive a particular packet while others do not receive it. During such
occurences, the ROHC compressors must continue to choose identical
packet types for subsequent packets. In other words, the ROHC
compressors must operate synchronously at all times. 
 
I would like to know if synchronizing the ROHC compressors (with
potentially different implementations) for U-mode is feasible. If yes,
are there some good solutions?
 
Thanks,
Vinod
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Biplab Sarkar <[email-masked]>
Date: Wed, 23 May 2007 11:40:24 +0530

Vinod,

I think in case of adopting ROHC at the eNBs, one has to ensure the
following things.

[1] When some compressor detects a packet loss (By RTP-SN) it should ask
for a context updation from other eNBs before trying to compress any
further packet. The context updation needs to have enough information to
re-create the missing packets impacts.
[2] Another solution would be to force all eNBs' ROHC contexts to fall
down to the IR-STATE. This might be a simple solution with lower
compression ratio.

So depending upon the probability of packet loss in the backhaul one
might think of having either type of solutions for the ROHC-at-eNB or
fallback to the other alternative of having ROHC above eNBs.

Thanks
Biplab

On Wed, 2007-05-23 at 13:09 +0800, Kumar Vinod-A20689 wrote:
> all the eNBs (base stations) of the SFN area transmit identical
> content of an MBMS service over identical air interface resources
> (i.e., on identical time-frequency slots). The clocks at all the eNBs
> of the SFN area are synchronized.
>  
> U-mode is currently the preferred mode of operation. If ROHC
> compressor is placed in a centralized node above the eNBs, then all
> the eNBs will receive identical packets so that content
> synchronization over-the-air can be achieved. However, if ROHC
> compressors are located at the eNBs, then it is important to ensure
> that all ROHC compressors in the SFN area choose identical packet
> types with identical content at all times. Note that packet losses may
> occur over the backhaul where some eNBs may receive a particular
> packet while others do not receive it. During such occurences, the
> ROHC compressors must continue to choose identical packet types for
> subsequent packets. In other words, the ROHC compressors must operate
> synchronously at all times. 
>  
> potentially different implementations) for U-mode is feasible. If
> yes, are there some good solutions?
>  
> Thanks,
> Vinod
>

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Wed, 23 May 2007 10:12:54 +0200

Hi Vinod,

I do not consider it feasible to have multiple independent ROHC
implementations produce bitwise identical output
(even if there are *no* losses before the compression point(s)).

The ROHC standard leaves a lot of flexibility up to the 
implementation and therefore you can *never* guarantee that two
ROHC compressors will behave identically even when they get
identical input.
All you can know is that they will interoperate, but not more
than that.

BR,
   Kristofer

Kumar Vinod-A20689 <mailto:[email-masked]> wrote on den 23 maj
2007 07:09 :

> Hi All,
> 
> 3GPP, as part of its long term evolution (LTE) work,  is
> currently discussing single frequency network (SFN) operation
> for offering multicast and broadcast multimedia services
> (MBMS) . In SFN operation, all the eNBs (base stations) of
> the SFN area transmit identical content of an MBMS service
> over identical air interface resources (i.e., on identical
> time-frequency slots). The clocks at all the eNBs of the SFN
> area are synchronized.
> 
> One of the issues is the location of ROHC for SFN operation.
> For MBMS, U-mode is currently the preferred mode of
> operation. If ROHC compressor is placed in a centralized node
> above the eNBs, then all the eNBs will receive identical
> packets so that content synchronization over-the-air can be
> achieved. However, if ROHC compressors are located at the
> eNBs, then it is important to ensure that all ROHC
> compressors in the SFN area choose identical packet types
> with identical content at all times. Note that packet losses
> may occur over the backhaul where some eNBs may receive a
> particular packet while others do not receive it. During such
> occurences, the ROHC compressors must continue to choose
> identical packet types for subsequent packets. In other
> words, the ROHC compressors must operate synchronously at all times.
> 
> I would like to know if synchronizing the ROHC compressors
> (with potentially different implementations) for U-mode is
> feasible. If yes, are there some good solutions?
> 
> Thanks,
> Vinod

---

From: Biplab Sarkar <[email-masked]>
Date: Wed, 23 May 2007 14:26:38 +0530

Vinod/Kristofer,

Might be by enforcing extra constrains one might achieve this to some
extent.

Constraints like:
[1] No feedback.
[2] Only WLSB based encoding
[3] No packet out of order delivery at the input of the compressor.
[4] Same set of attributes to control the different compressors.

Keeping all these restrictions will keep the compressors to run in
unison 

Thanks
Biplab