Define a Transport Protocol over CAN/ FD for compressing the useful data

Define a Transport Protocol over CAN/ FD for compressing the useful data.
This should be a simple and fast algorithm for both compression/decompression
methods.
From the CAN message structure one of the bits r0 / r1 from the "Control Field" -
bits which "are reserved for future use" - can be used in order to memo if the data
can or cannot be compressed.

https://www.google.ro/search?q=vector+can+protocol+reference+chart
+pdf&biw=1920&bih=979&tbm=isch&tbo=u&source=univ&sa=X&sqi=2&ved=0CEIQsARqFQoTCIvTusjkrcgCFYcYLAodvTUIDg#%3A

In case the data can be compressed then for these message a new byte structure
should be defined.
The first byte of each CAN message should be used in order to memo if the values
can/cannot be compressed and other information all these only for the partial data
not for the cases when a complete message can be compressed in this case this first
byte will store part of the compressed data.

A 1-bit CAN signal can be set in order to show if the values that should be packed in
a message can/cannot be compressed with this algorithm.
A new bit should be used in order to specify if all data from a message or only a part
of it can be compressed.
In case of only a part of message can be compressed 3 bits + 3 bits should be again
used for storing the byte & bit position + a new byte for storing the length of the
compressed sequence.
The algorithm can be an arithmetic method based only on additions - the
compression and substraction - the decompression method.
This algorithm can use the Calkin-Wilf Tree paths(like input from original CAN data)
and generate fractions like compressed information.

This algorithm can be used and produces fractions with nominator and denominator
with less bits that the original path from the tree only for messages with many
0x00/0xFF or paths that can be found on the exterior of the Calkin-Wilf Tree. For
the sequence of bits that form the paths from the interior of this tree so path or
sequence of bits like 010101010101.. there is no gain achieved by this compression
method.
Using this fast & simple compression/decompression algorithm also the CAN
arbitration phase can be changed in order to take into account if the compressed
data are completely finished or not.
In case the compressed data was sent and it's length is less than 8 bytes during
the remaining bits that remained - so not relevant, a new arbitration phase can be
started and some speed of the entire communication can also be gained in such
cases.
Also using a compression method for the CAN data an other approach can be the
possibility to add multiplexed values so new signals on the positions gained with the
compression.
ECU can decompress and send at Vehicle CAN the un-compressed messages.
In this way the overall communication between ECUs can be increased in speed.