Re: [rohc] encoding section

["Lars-Erik Jonsson" <lars-erik.jonsson@ericsson.com>]

Hi Zhigang,

 

This was a very good initiative and in general I think this new chapter 4.5 is well structured and includes what should be there. As you proposed, current chapter 5.8 could then be removed.

 

However, I have a number of comments to the various sections. Below you will find comments on chapter 4.5.1-4.5.2. Comments on the other sections will follow.

 

Nice work!!!

 

Cheers,

/L-E

 

 

 

4.5.1.  Least Significant Bits (LSB) encoding

 

Least Significant Bits (LSB) encoding can be used for a header field whose values are usually subject to small changes. In simplest terms, k least significant bits of the field value are sent by the compressor instead of the original field value, where k is a positive integer. After receiving the k LSBs, the decompressor derives the original value using a previously received value as reference (v_ref).

 

Skip the sentence: "where k is a positive number" (at least I do not know what a negative number of bits is)

 

 

The scheme is guaranteed to be correct if the compressor and the decompressor agree on an interpretation interval in which 1) the original value resides and 2) is the only value that has the exact same k LSBs as transmitted in the compressed packet. (It will be shown later that this statement can actually be relaxed) The interval can be described as a function f(v_ref, k). Without loosing generality, we choose the function as

 

2) is not a correct sentence. "...interval in which is the only value that..." I do not understand the purpose of 2) at all.

 

f(v_ref, k) = [v_ref – p, v_ref + (2^k – 1) - p], where p is an integer

 

Could add note that the interval is of size 2^k

 

   <-------------- interpretation interval -------------->
   |-------------+---------------------------------------|
v_ref – p        v_ref                        v_ref + (2^k-1) - p

 

  Note that function f has a good property: for any value k, k LSBs will uniquely identify a value in the interval. This is referred to as the uniqueness property of function f, which satisfies the condition 2) above.

 

I still do not see the purpose of 2) Is not that obvious???

 

The parameter p is introduced so that the interpretation interval can be shifted with respect to v_ref. A good value of p can yield more efficient encoding for fields with certain characteristics. For example, if a field value observed by the compressor is always increasing, p should be set to 0, and thus gives an interval [v_ref, v_ref + 2^k – 1]. Because LSB encoding will be applied in rohc to header fields whose values normally increases except some uncommon situations (e.g. packet misordering, RTP TS for video, etc), only two values will be assigned to p: p1 = 0 or p2 = 2^(k-2) – 1. The latter gives an interpretation interval [v_ref – (2^(k-2) – 1), v_ref + 3*2^(k-2)] which can handle negative changes but still gives more space for the positive changes. See packet format section for more details.

 

Following is a simplified procedure of compression and decompression:

 

1) The compressor (decompressor) always uses as v_ref_c (v_ref_d) the last value that has been compressed (decompressed);

1) is not true since you will chose a reference within a sliding window. It would be ok to say this if you clarify that it is an example of a reference. Interpretation is not the only basis for choosing number of bits, robustness is an other one.

 

2) When compressing a value v, the compressor simply calculates the minimal (for efficiency) but sufficient (for correctness) value of k such that v falls into the interval (interval_c) as defined by function f with v_ref = v_ref_c. Let's represent this procedure as a function k = g(v, v_ref). Note that more than k LSBs may be sent to fit the packet format (see packet format section);
3) When receiving m LSBs, the decompressor will derive the interpretation interval (interval_d) as defined by f with k = m and v_ref = v_ref_d. Then it picks as the decompressed value the one in interval_d whose LSBs match the received ones.

 

The scheme is complicated by two factors: packet loss between the compressor and decompressor, and transmission errors undetected by the lower layer. In the former case, the compressor and decompressor will lose the synchronization of v_ref, and thus the one of the interpretation interval. If v is still covered by the intersection(interval_c, interval_d), the decompression will be correct. Otherwise, incorrect decompression will happen. The next section will address this issue.

 

As to the latter case, the corrupted LSB will give incorrectly decompressed value that will be used later as v_ref, which in turn will probably lead to damage propagation. This can be solved by the idea of secure reference, i.e. a reference value whose correctness can be verified by a CRC calculated over it. Consequently, the procedure 1) above is modified as following: the compressor always uses as v_ref_c the last value that has been compressed and sent with a CRC. The decompressor always uses as v_ref_d the last correctly (as proven by CRC) decompressed value.

 

4.5.2  Window-based LSB encoding

 

Describe the problem this mechanism solves. The simplification above where the last value sent is used as v_ref_c will not provide robustness.

 

The idea is very simple. Although the compressor cannot determine the exact value of v_ref_d that will be used by decompressor for a particular value v, it knows or can make assumptions about the 'candidate' set of values from which the decompressor may choose the v_ref_d. Obviously, such candidate set is a subset of all the values that have been sent by the compressor before v. The compressor then calculates the value of k such that no matter which v_ref_d the decompressor uses, the resulted interval_d covers v.

 

Do not say that the last value sent will be used when it will not. It could be used, but as we know we have this because using the last value sent will not provide robustness.

Because of the order introduced by the fact that the compressor (decompressor) always uses the last sent (received) value with a CRC as the reference, the compressor actually maintains a sliding window (VSW) rather than a set. VSW is initially empty. Below are the operations performed on VSW by the compressor:

 

1) After sending a value v (either compressed or uncompressed) with a CRC, the compressor adds v to the head of the VSW;
2) For each value v being compressed, the compressor chooses k = max(g(v, v_min), g(v, v_max)), where v_main and v_max are the minimal and maximal value in VSW, and g is the function defined in previous section;
3) The sliding window is advanced when the compressor has sufficient confidence that values that are older (at the tail of VSW) than a certain value will be no longer used by the decompressor as v_ref_d. The confidence may be obtained by various means, e.g., an ACK from the decompressor if operating in R mode, in which case values older than the ACKed one can be removed from VSW. In the case of U/O mode, since there is a CRC to verify correct decompression, a VSW with certain depth will be used. The window depth is an optimization parameter determined during implementation. A special case is set it to 1.

 

Skip the last sentence since that case will probably not be used more than any other.

 

 Note that the decompressor follows the same procedure as described in previous section, except that it MUST ACK each value received with a CRC (refer to compression/decompression logic section for details).

 

Hmmm...the decompressor do not apply this sliding window at all. The decompressor just takes the bits and apply the based on the interpretation interval used. I think the last paragraph should be removed.