Subject: [lp-wan] Idea for SCHC rules rearrangement

From: Philippe Clavier <[email-masked]>
Date: Wed, 21 Jun 2017 08:40:04 +0000

Dear all,

I have been thinking about some ways to rearrange the format for the compression rules which might be more efficient.
I have attached an example for the arrangement of the rules in a text file.

Using the new arrangement uniquely decodable rule IDs can be defined avoiding the need to repeat the same field compression in different rules (and the necessity for many rules). For example, in the worst case (in which all possible field compressions are evaluated) the first format would require to evaluate 42 possibilities. Where in the new format, it would require only 18 possible field compressions to be evaluated. This difference drastically grows if it is required to define more field compressions. Also, this new arrangement allows more compressions to be done. For example, with the new format a message with DEVport from Rule 0 and APPport from Rule 1 could be compressed.

One way for obtaining a uniquely decodable code for the rule IDs from the FCIDs could be, for example, by indexing the permutations of possible compressions. If there is only one compression for a given field the FCID will have no value, and will add no more possibilities of compression.

In the example given before the encoding for the rule IDs would be:

    0000 ( UDP DEVport 0 - UDP DEVport 0 )
    0001 ( UDP DEVport 0 - UDP DEVport 1 )
    0010 ( UDP DEVport 0 - UDP DEVport 2 )
    0011 ( UDP DEVport 1 - UDP DEVport 0 )
    0100 ( UDP DEVport 1 - UDP DEVport 1 )
    0101 ( UDP DEVport 1 - UDP DEVport 2 )
    0110 ( UDP DEVport 2 - UDP DEVport 0 )
    0111 ( UDP DEVport 2 - UDP DEVport 1 )
    1000 ( UDP DEVport 2 - UDP DEVport 2 )

In this case, there are 3 * 3 = 9 possible compressions, so 4 bits would be required for the Rule ID.
In the previous format, there are only 3 possible compressions, so 2 bits would be required for the Rule ID.

To conclude, advantages of using the new format are that less memory is required to store the rules, less computational complexity is required to evaluate the matching of every field and its compression, and furthermore it makes it easier to implement later changes in the rules, as it the previous arrangement it will be required to change all the different rules that contain that same field compression.

The disadvantage of this is that the Rule ID obtained will be larger as it considers all possible permutations. The new format considers more possibilities for compression which may not be required and (if not needed) would add extra unnecessary bits to the representation of the Rule IDs. Nevertheless, this problem could be tackled by a later encoding of the rule IDs in an uniquely decodable optimal code. In such way that most used rules would require less bits than the rules less used.

I hope my explanations were clear, I am looking forward to your opinions on the matter.

Regards,
Philippe Clavier