5.2.5.2. Segmentation protocol
Segment Packet
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 1 | F |
+---+---+---+---+---+---+---+---+
/ Segment / variable length
+---+---+---+---+---+---+---+---+
F: Final bit. If set, it indicates that this is the last segment of
a reconstructed unit.
The segment header may be preceded by padding octets and/or feedback.
It never carries a CID.
All segment header packets for one reconstructed unit have to be sent
consecutively on a channel, i.e., any non-segment-header packet
following a nonfinal segment header aborts the reassembly of the
current reconstructed unit and causes the decompressor to discard the
nonfinal segments received on this channel so far. When a final
segment header is received, the decompressor reassembles the segment
carried in this packet and any nonfinal segments that immediately
preceded it into a single reconstructed unit, in the order they were
received. The reconstructed unit has the format:
Reconstructed Unit
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| |
/ Reconstructed ROHC packet / variable length
| |
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+
The CRC is used by the decompressor to validate the reconstructed
unit. It uses the FCS-32 algorithm with the following generator
polynomial: x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 +
x^12 + x^16 + x^22 + x^23 + x^26 + x^32 [HDLC]. If the reconstructed
unit is 4 octets or less, or if the CRC fails, or if it is larger
than the channel parameter MRRU (see 5.1.1), the reconstructed unit
MUST be discarded by the decompressor.
----------------------------------------------------------------[Page 50]
If the CRC succeeds, the reconstructed ROHC packet is interpreted as
a ROHC Header, optionally followed by a payload. Note that this
means that there can be no padding and no feedback in the
reconstructed unit, and that the CID is derived from the initial
octets of the reconstructed unit.
(It should be noted that the ROHC segmentation protocol was inspired
by SEAL by Steve Deering et al., which later became ATM AAL5. The
same arguments for not having sequence numbers in the segments but
instead providing a strong CRC in the reconstructed unit apply here
as well. Note that, as a result of this protocol, there is no way in
ROHC to make any use of a segment that has residual bit errors.)
5.2.6. ROHC initial decompressor processing
The following packet types are reserved at the framework level in the
ROHC scheme:
1110: Padding or Add-CID octet
11110: Feedback
11111000: IR-DYN packet
1111110: IR packet
1111111: Segment
Other packet types can be used at will by individual profiles.
The following steps is an outline of initial decompressor processing
which upon reception of a ROHC packet can determine its contents.
1) If the first octet is a Padding Octet (11100000),
strip away all initial Padding Octets and goto next step.
2) If the first remaining octet starts with 1110, it is an Add-CID
octet:
remember the Add-CID octet; remove the octet.
3) If the first remaining octet starts with 11110, and an Add-CID
octet was found in step 2),
an error has occurred; the header MUST be discarded without
further action.
4) If the first remaining octet starts with 11110, and an Add-CID
octet was not found in step 2), this is feedback:
find the size of the feedback data, call it s;
remove the feedback type octet;
----------------------------------------------------------------[Page 51]
remove the Size octet if Code is 0;
send feedback data of length s to the same-side associated
compressor;
if packet exhausted, stop; otherwise goto 2).
5) If the first remaining octet starts with 1111111, this is a
segment:
attempt reconstruction using the segmentation protocol
(5.2.5). If a reconstructed packet is not produced, this
finishes the processing of the original packet. If a
reconstructed packet is produced, it is fed into step 1)
above. Padding, segments, and feedback are not allowed in
reconstructed packets, so when processing them, steps 1),
4), and 5) are modified so that the packet is discarded
without further action when their conditions match.
6) Here, it is known that the rest is forward information (unless the
header is damaged).
7) If the forward traffic uses small CIDs, there is no large CID in
the packet. If an Add-CID immediately preceded the packet type
(step 2), it has the CID of the Add-CID; otherwise it has CID 0.
8) If the forward traffic uses large CIDs, the CID starts with the
second remaining octet. If the first bit(s) of that octet are not
0 or 10, the packet MUST be discarded without further action. If
an Add-CID octet immediately preceded the packet type (step 2),
the packet MUST be discarded without further action.
9) Use the CID to find the context.
10) If the packet type is IR, the profile indicated in the IR packet
determines how it is to be processed. If the CRC fails to verify
the packet, it MUST be discarded. If a profile is indicated in
the context, the logic of that profile determines what, if any,
feedback is to be sent. If no profile is noted in the context,
no further action is taken.
11) If the packet type is IR-DYN, the profile indicated in the IR-DYN
packet determines how it is to be processed.
a) If the CRC fails to verify the packet, it MUST be discarded.
If a profile is indicated in the context, the logic of that
profile determines what, if any, feedback is to be sent. If no
profile is noted in the context, no further action is taken.
----------------------------------------------------------------[Page 52]
b) If the context has not been initialized by an IR packet, the
packet MUST be discarded. The logic of the profile indicated
in the IR-DYN header (if verified by the CRC), determines what,
if any, feedback is to be sent.
12) Otherwise, the profile noted in the context determines how the
rest of the packet is to be processed. If the context has not
been initialized by an IR packet, the packet MUST be discarded
without further action.
The procedure for finding the size of the feedback data is as
follows:
Examine the three bits which immediately follow the feedback packet
type. When these bits are
1-7, the size of the feedback data is given by the bits;
0, a Size octet, which explicitly gives the size of the
feedback data, is present after the feedback type octet.
5.2.7. ROHC RTP packet formats from compressor to decompressor
ROHC RTP uses three packet types to identify compressed headers, and
two for initialization/refresh. The format of a compressed packet
can depend on the mode. Therefore a naming scheme of the form
<modes format is used in>-<packet type number>-<some property>
is used to uniquely identify the format when necessary, e.g., UOR-2,
R-1. For exact formats of the packet types, see section 5.7.
Packet type zero: R-0, R-0-CRC, UO-0.
This, the minimal, packet type is used when parameters of all SN-
functions are known by the decompressor, and the header to be
compressed adheres to these functions. Thus, only the W-LSB
encoded RTP SN needs to be communicated.
R-mode: Only if a CRC is present (packet type R-0-CRC) may the
header be used as a reference for subsequent decompression.
U-mode and O-mode: A small CRC is present in the UO-0 packet.
Packet type 1: R-1, R-1-ID, R-1-TS, UO-1, UO-1-ID, UO-1-TS.
This packet type is used when the number of bits needed for the SN
exceeds those available in packet type zero, or when the
parameters of the SN-functions for RTP TS or IP-ID change.
----------------------------------------------------------------[Page 53]
R-mode: R-1-* packets are not used as references for subsequent
decompression. Values for other fields than the RTP TS or IP-ID
can be communicated using an extension, but they do not update the
context.
U-mode and O-mode: Only the values of RTP SN, RTP TS and IP-ID can
be used as references for future compression. Nonupdating values
can be provided for other fields using an extension (UO-1-ID).
Packet type 2: UOR-2, UOR-2-ID, UOR-2-TS
This packet type can be used to change the parameters of any SN-
function, except those for most static fields. Headers of packets
transferred using packet type 2 can be used as references for
subsequent decompression.
Packet type: IR
This packet type communicates the static part of the context,
i.e., the value of the constant SN-functions. It can optionally
also communicate the dynamic part of the context, i.e., the
parameters of the nonconstant SN-functions.
Packet type: IR-DYN
This packet type communicates the dynamic part of the context,
i.e., the parameters of nonconstant SN-functions.
5.2.8. Parameters needed for mode transition in ROHC RTP
The packet types IR (with dynamic information), IR-DYN, and UOR-2 are
common for all modes. They can carry a mode parameter which can take
the values U = Unidirectional, O = Bidirectional Optimistic, and R =
Bidirectional Reliable.
Feedback of types ACK, NACK, and STATIC-NACK carry sequence numbers,
and feedback packets can also carry a mode parameter indicating the
desired compression mode: U, O, or R.
As a shorthand, the notation PACKET(mode) is used to indicate which
mode value a packet carries. For example, an ACK with mode parameter
R is written ACK(R), and an UOR-2 with mode parameter O is written
UOR-2(O).
----------------------------------------------------------------[Page 54]
5.3. Operation in Unidirectional mode
5.3.1. Compressor states and logic (U-mode)
Below is the state machine for the compressor in Unidirectional mode.
Details of the transitions between states and compression logic are
given subsequent to the figure.
Optimistic approach
+------>------>------>------>------>------>------>------>------+
| |
| Optimistic approach Optimistic approach |
| +------>------>------+ +------>------>------+ |
| | | | | |
| | v | v v
+----------+ +----------+ +----------+
| IR State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | Timeout | | Timeout / Update | |
| +------<------<------+ +------<------<------+ |
| |
| Timeout |
+------<------<------<------<------<------<------<------<------+
5.3.1.1. State transition logic (U-mode)
The transition logic for compression states in Unidirectional mode is
based on three principles: the optimistic approach principle,
timeouts, and the need for updates.
5.3.1.1.1. Optimistic approach, upwards transition
Transition to a higher compression state in Unidirectional mode is
carried out according to the optimistic approach principle. This
means that the compressor transits to a higher compression state when
it is fairly confident that the decompressor has received enough
information to correctly decompress packets sent according to the
higher compression state.
When the compressor is in the IR state, it will stay there until it
assumes that the decompressor has correctly received the static
context information. For transition from the FO to the SO state, the
compressor should be confident that the decompressor has all
parameters needed to decompress according to a fixed pattern.
----------------------------------------------------------------[Page 55]
The compressor normally obtains its confidence about decompressor
status by sending several packets with the same information according
to the lower compression state. If the decompressor receives any of
these packets, it will be in sync with the compressor. The number of
consecutive packets to send for confidence is not defined in this
document.
5.3.1.1.2. Timeouts, downward transition
When the optimistic approach is taken as described above, there will
always be a possibility of failure since the decompressor may not
have received sufficient information for correct decompression.
Therefore, the compressor MUST periodically transit to lower
compression states. Periodic transition to the IR state SHOULD be
carried out less often than transition to the FO state. Two
different timeouts SHOULD therefore be used for these transitions.
For an example of how to implement periodic refreshes, see [IPHC]
chapters 3.3.1-3.3.2.
5.3.1.1.3. Need for updates, downward transition
In addition to the downward state transitions carried out due to
periodic timeouts, the compressor must also immediately transit back
to the FO state when the header to be compressed does not conform to
the established pattern.
5.3.1.2. Compression logic and packets used (U-mode)
The compressor chooses the smallest possible packet format that can
communicate the desired changes, and has the required number of bits
for W-LSB encoded values.
5.3.1.3. Feedback in Unidirectional mode
The Unidirectional mode of operation is designed to operate over
links where a feedback channel is not available. If a feedback
channel is available, however, the decompressor MAY send an
acknowledgment of successful decompression with the mode parameter
set to U (send an ACK(U)). When the compressor receives such a
message, it MAY disable (or increase the interval between) periodic
IR refreshes.
5.3.2. Decompressor states and logic (U-mode)
Below is the state machine for the decompressor in Unidirectional
mode. Details of the transitions between states and decompression
logic are given subsequent to the figure.
----------------------------------------------------------------[Page 56]
Success
+-->------>------>------>------>------>--+
| |
No Static | No Dynamic Success | Success
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+--------------+ +----------------+ +--------------+
| No Context | | Static Context | | Full Context |
+--------------+ +----------------+ +--------------+
^ | ^ |
| k_2 out of n_2 failures | | k_1 out of n_1 failures |
+-----<------<------<-----+ +-----<------<------<-----+
5.3.2.1. State transition logic (U-mode)
Successful decompression will always move the decompressor to the
Full Context state. Repeated failed decompression will force the
decompressor to transit downwards to a lower state. The decompressor
does not attempt to decompress headers at all in the No Context and
Static Context states unless sufficient information is included in
the packet itself.
5.3.2.2. Decompression logic (U-mode)
Decompression in Unidirectional mode is carried out following three
steps which are described in subsequent sections.
5.3.2.2.1. Decide whether decompression is allowed
In Full Context state, decompression may be attempted regardless of
what kind of packet is received. However, for the other states
decompression is not always allowed. In the No Context state only IR
packets, which carry the static information fields, may be
decompressed. Further, when in the Static Context state, only
packets carrying a 7- or 8-bit CRC can be decompressed (i.e., IR,
IR-DYN, or UOR-2 packets). If decompression may not be performed the
packet is discarded, unless the optional delayed decompression
mechanism is used, see section 6.1.
5.3.2.2.2. Reconstruct and verify the header
When reconstructing the header, the decompressor takes the header
information already stored in the context and updates it with the
information received in the current header. (If the reconstructed
header fails the CRC check, these updates MUST be undone.)
----------------------------------------------------------------[Page 57]
The sequence number is reconstructed by replacing the sequence number
LSBs in the context with those received in the header. The resulting
value is then verified to be within the interpretation interval by
comparison with a previously reconstructed reference value v_ref (see
section 4.5.1). If it is not within this interval, an adjustment is
applied by adding N x interval_size to the reconstructed value so
that the result is brought within the interpretation interval. Note
that N can be negative.
If RTP Timestamp and IP Identification fields are not included in the
received header, they are supposed to be calculated from the sequence
number. The IP Identifier usually increases by the same delta as the
sequence number and the timestamp by the same delta times a fixed
value. See chapters 4.5.3 and 4.5.5 for details about how these
fields are encoded in compressed headers.
When working in Unidirectional mode, all compressed headers carry a
CRC which MUST be used to verify decompression.
5.3.2.2.3. Actions upon CRC failure
This section is written so that it is applicable to all modes.
A mismatch in the CRC can be caused by one or more of:
1. residual bit errors in the current header
2. a damaged context due to residual bit errors in previous headers
3. many consecutive packets being lost between compressor and
decompressor (this may cause the LSBs of the SN in compressed
packets to be interpreted wrongly, because the decompressor has
not moved the interpretation interval for lack of input -- in
essence, a kind of context damage).
(Cases 2 and 3 do not apply to IR packets; case 3 does not apply to
IR-DYN packets.) The 3-bit CRC present in some header formats will
eventually detect context damage reliably, since the probability of
undetected context damage decreases exponentially with each new
header processed. However, residual bit errors in the current header
are only detected with good probability, not reliably.
When a CRC mismatch is caused by residual bit errors in the current
header (case 1 above), the decompressor should stay in its current
state to avoid unnecessary loss of subsequent packets. On the other
hand, when the mismatch is caused by a damaged context (case 2), the
decompressor should attempt to repair the context locally. If the
local repair attempt fails, it must move to a lower state to avoid
----------------------------------------------------------------[Page 58]
delivering incorrect headers. When the mismatch is caused by
prolonged loss (case 3), the decompressor might attempt additional
decompression attempts. Note that case 3 does not occur in R-mode.
The following actions MUST be taken when a CRC check fails:
First, attempt to determine whether SN LSB wraparound (case 3) is
likely, and if so, attempt a correction. For this, the algorithm of
section 5.3.2.2.4 MAY be used. If another algorithm is used, it MUST
have at least as high a rate of correct repairs as the one in
5.3.2.2.4. (This step is not applicable to R-mode.)
Second, if the previous step did not attempt a correction, a repair
should be attempted under the assumption that the reference SN has
been incorrectly updated. For this, the algorithm of section
5.3.2.2.5 MAY be used. If another algorithm is used, it MUST have at
least as high a rate of correct repairs as the one in 5.3.2.2.5.
(This step is not applicable to R-mode.)
If both the above steps fail, additional decompression attempts
SHOULD NOT be made. There are two possible reasons for the CRC
failure: case 1 or unrecoverable context damage. It is impossible to
know for certain which of these is the actual cause. The following
rules are to be used:
a. When CRC checks fail only occasionally, assume residual errors in
the current header and simply discard the packet. NACKs SHOULD
NOT be sent at this time.
b. In the Full Context state: When the CRC check of k_1 out of the
last n_1 decompressed packets have failed, context damage SHOULD
be assumed and a NACK SHOULD be sent in O- and R-mode. The
decompressor moves to the Static Context state and discards all
packets until an update (IR, IR-DYN, UOR-2) which passes the CRC
check is received.
c. In the Static Context state: When the CRC check of k_2 out of the
last n_2 updates (IR, IR-DYN, UOR-2) have failed, static context
damage SHOULD be assumed and a STATIC-NACK is sent in O- and R-
mode. The decompressor moves to the No Context state.
d. In the No Context state: The decompressor discards all packets
until a static update (IR) which passes the CRC check is received.
(In O-mode and R-mode, feedback is sent according to sections
5.4.2.2 and 5.5.2.2, respectively.)
----------------------------------------------------------------[Page 59]
Note that appropriate values for k_1, n_1, k_2, and n_2, are related
to the residual error rate of the link. When the residual error rate
is close to zero, k_1 = n_1 = k_2 = n_2 = 1 may be appropriate.
5.3.2.2.4. Correction of SN LSB wraparound
When many consecutive packets are lost there will be a risk of
sequence number LSB wraparound, i.e., the SN LSBs being interpreted
wrongly because the interpretation interval has not moved for lack of
input. The decompressor might be able to detect this situation and
avoid context damage by using a local clock. The following algorithm
MAY be used:
a. The decompressor notes the arrival time, a(i), of each incoming
packet i. Arrival times of packets where decompression fails are
discarded.
b. When decompression fails, the decompressor computes INTERVAL =
a(i) - a(i - 1), i.e., the time elapsed between the arrival of the
previous, correctly decompressed packet and the current packet.
c. If wraparound has occurred, INTERVAL will correspond to at least
2^k inter-packet times, where k is the number of SN bits in the
current header. On the basis of an estimate of the packet inter-
arrival time, obtained for example using a moving average of
arrival times, TS_STRIDE, or TS_TIME, the decompressor judges if
INTERVAL can correspond to 2^k inter-packet times.
d. If INTERVAL is judged to be at least 2^k packet inter-arrival
times, the decompressor adds 2^k to the reference SN and attempts
to decompress the packet using the new reference SN.
e. If this decompression succeeds, the decompressor updates the
context but SHOULD NOT deliver the packet to upper layers. The
following packet is also decompressed and updates the context if
its CRC succeeds, but SHOULD be discarded. If decompression of
the third packet using the new context also succeeds, the context
repair is deemed successful and this and subsequent decompressed
packets are delivered to the upper layers.
f. If any of the three decompression attempts in d. and e. fails, the
decompressor discards the packets and acts according to rules a)
through c) of section 5.3.2.2.3.
Using this mechanism, the decompressor may be able to repair the
context after excessive loss, at the expense of discarding two
packets.
----------------------------------------------------------------[Page 60]
5.3.2.2.5. Repair of incorrect SN updates
The CRC can fail to detect residual errors in the compressed header
because of its limited length, i.e., the incorrectly decompressed
packet can happen to have the same CRC as the original uncompressed
packet. The incorrect decompressed header will then update the
context. This can lead to an erroneous reference SN being used in
W-LSB decoding, as the reference SN is updated for each successfully
decompressed header of certain types.
In this situation, the decompressor will detect the incorrect
decompression of the following packet with high probability, but it
does not know the reason for the failure. The following mechanism
allows the decompressor to judge if the context was updated
incorrectly by an earlier packet and, if so, to attempt a repair.
a. The decompressor maintains two decompressed sequence numbers: the
last one (ref 0) and the one before that (ref -1).
b. When receiving a compressed header the SN (SN curr1) is
decompressed using ref 0 as the reference. The other header
fields are decompressed using this decompressed SN curr1. (This
is part of the normal decompression procedure prior to any CRC
test failures.)
c. If the decompressed header generated in b. passes the CRC test,
the references are shifted as follows:
ref -1 = ref 0
ref 0 = SN curr1.
d. If the header generated in b. does not pass the CRC test, and the
SN (SN curr2) generated when using ref -1 as the reference is
different from SN curr1, an additional decompression attempt is
performed based on SN curr2 as the decompressed SN.
e. If the decompressed header generated in b. does not pass the CRC
test and SN curr2 is the same as SN curr1, an additional
decompression attempt is not useful and is not attempted.
f. If the decompressed header generated in d. passes the CRC test,
ref -1 is not changed while ref 0 is set to SN curr2.
g. If the decompressed header generated in d. does not pass the CRC
test, the decompressor acts according to rules a) through c) of
section 5.3.2.2.3.
----------------------------------------------------------------[Page 61]
The purpose of this algorithm is to repair the context. If the
header generated in d. passes the CRC test, the references are
updated according to f., but two more headers MUST also be
successfully decompressed before the repair is deemed successful. Of
the three successful headers, the first two SHOULD be discarded and
only the third delivered to upper layers. If decompression of any of
the three headers fails, the decompressor MUST discard that header
and the previously generated headers, and act according to rules a)
through c) of section 5.3.2.2.3.
5.3.2.3. Feedback in Unidirectional mode
To improve performance for the Unidirectional mode over a link that
does have a feedback channel, the decompressor MAY send an
acknowledgment when decompression succeeds. Setting the mode
parameter in the ACK packet to U indicates that the compressor is to
stay in Unidirectional mode. When receiving an ACK(U), the
compressor should reduce the frequency of IR packets since the static
information has been correctly received, but it is not required to
stop sending IR packets. If IR packets continue to arrive, the
decompressor MAY repeat the ACK(U), but it SHOULD NOT repeat the
ACK(U) continuously.
5.4. Operation in Bidirectional Optimistic mode
5.4.1. Compressor states and logic (O-mode)
Below is the state machine for the compressor in Bidirectional
Optimistic mode. The details of each state, state transitions, and
compression logic are given subsequent to the figure.
Optimistic approach / ACK
+------>------>------>------>------>------>------>------>------+
| |
| Optimistic appr. / ACK Optimistic appr. /ACK ACK |
| +------>------>------+ +------>--- -->-----+ +->--+
| | | | | | |
| | v | v | v
+----------+ +----------+ +----------+
| IR State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | STATIC-NACK | | NACK / Update | |
| +------<------<------+ +------<------<------+ |
| |
| STATIC-NACK |
+------<------<------<------<------<------<------<------<------+
----------------------------------------------------------------[Page 62]
5.4.1.1. State transition logic
The transition logic for compression states in Bidirectional
Optimistic mode has much in common with the logic of the
Unidirectional mode. The optimistic approach principle and
transitions occasioned by the need for updates work in the same way
as described in chapter 5.3.1. However, in Optimistic mode there are
no timeouts. Instead, the Optimistic mode makes use of feedback from
decompressor to compressor for transitions in the backward direction
and for OPTIONAL improved forward transition.
5.4.1.1.1. Negative acknowledgments (NACKs), downward transition
Negative acknowledgments (NACKs), also called context requests,
obviate the periodic updates needed in Unidirectional mode. Upon
reception of a NACK the compressor transits back to the FO state and
sends updates (IR-DYN, UOR-2, or possibly IR) to the decompressor.
NACKs carry the SN of the latest packet successfully decompressed,
and this information MAY be used by the compressor to determine what
fields need to be updated.
Similarly, reception of a STATIC-NACK packet makes the compressor
transit back to the IR state.
5.4.1.1.2. Optional acknowledgments, upwards transition
In addition to NACKs, positive feedback (ACKs) MAY also be used for
UOR-2 packets in the Bidirectional Optimistic mode. Upon reception
of an ACK for an updating packet, the compressor knows that the
decompressor has received the acknowledged packet and the transition
to a higher compression state can be carried out immediately. This
functionality is optional, so a compressor MUST NOT expect to get
such ACKs initially.
The compressor MAY use the following algorithm to determine when to
expect ACKs for UOR-2 packets. Let an update event be when a
sequence of UOR-2 headers are sent to communicate an irregularity in
the packet stream. When ACKs have been received for k_3 out of the
last n_3 update events, the compressor will expect ACKs. A
compressor which expects ACKs will repeat updates (possibly not in
every packet) until an ACK is received.
5.4.1.2. Compression logic and packets used
The compression logic is the same for the Bidirectional Optimistic
mode as for the Unidirectional mode (see section 5.3.1.2).
----------------------------------------------------------------[Page 63]
5.4.2. Decompressor states and logic (O-mode)
The decompression states and the state transition logic are the same
as for the Unidirectional case (see section 5.3.2). What differs is
the decompression and feedback logic.
5.4.2.1. Decompression logic, timer-based timestamp decompression
In Bidirectional mode (or if there is some other way for the
compressor to obtain the decompressor's clock resolution and the
link's jitter), timer-based timestamp decompression may be used to
improve compression efficiency when RTP Timestamp values are
proportional to wall-clock time. The mechanisms used are those
described in 4.5.4.
5.4.2.2. Feedback logic (O-mode)
The feedback logic defines what feedback to send due to different
events when operating in the various states. As mentioned above,
there are three principal kinds of feedback; ACK, NACK and STATIC-
NACK. Further, the logic described below will refer to different
kinds of packets that can be received by the decompressor;
Initialization and Refresh (IR) packets, IR packets without static
information (IR-DYN) and type 2 packets (UOR-2), or type 1 (UO-1) and
type 0 packets (UO-0). A type 0 packet carries a packet header
compressed according to a fixed pattern, while type 1, 2 and IR-DYN
packets are used when this pattern is broken.
Below, rules are defined stating which feedback to use when. If the
optional feedback is used once, the decompressor is REQUIRED to
continue to send optional feedback for the lifetime of the packet
stream.
State Actions
NC: - When an IR packet passes the CRC check, send an ACK(O).
- When receiving a type 0, 1, 2 or IR-DYN packet, or an IR
packet has failed the CRC check, send a STATIC-NACK(O),
subject to the considerations at the beginning of section
5.7.6.
SC: - When an IR packet is correctly decompressed, send an ACK(O).
- When a type 2 or an IR-DYN packet is correctly decompressed,
optionally send an ACK(O).
- When a type 0 or 1 packet is received, treat it as a
mismatching CRC and use the logic of section 5.3.2.2.3 to
decide if a NACK(O) should be sent.
----------------------------------------------------------------[Page 64]
- When decompression of a type 2 packet, an IR-DYN packet or an
IR packet has failed, use the logic of section 5.3.2.2.3 to
decide if a STATIC-NACK(O) should be sent.
FC: - When an IR packet is correctly decompressed, send an ACK(O).
- When a type 2 or an IR-DYN packet is correctly decompressed,
optionally send an ACK(O).
- When a type 0 or 1 packet is correctly decompressed, no
feedback is sent.
- When any packet fails the CRC check, use the logic of
5.3.2.2.3 to decide if a NACK(O) should be sent.
5.5. Operation in Bidirectional Reliable mode
5.5.1. Compressor states and logic (R-mode)
Below is the state machine for the compressor in Bidirectional
Reliable mode. The details of each state, state transitions, and
compression logic are given subsequent to the figure.
ACK
+------>------>------>------>------>------>------>------+
| |
| ACK ACK | ACK
| +------>------>------+ +------>------>------+ +->-+
| | | | | | |
| | v | v | v
+----------+ +----------+ +----------+
| IR State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | STATIC-NACK | | NACK / Update | |
| +------<------<------+ +------<------<------+ |
| |
| STATIC-NACK |
+------<------<------<------<------<------<------<------<------+
5.5.1.1. State transition logic (R-mode)
The transition logic for compression states in Reliable mode is based
on three principles: the secure reference principle, the need for
updates, and negative acknowledgments.
5.5.1.1.1. Upwards transition
The upwards transition is determined by the secure reference
principle. The transition procedure is similar to the one described
in section 5.3.1.1.1, with one important difference: the compressor
----------------------------------------------------------------[Page 65]
bases its confidence only on acknowledgments received from the
decompressor. This ensures that the synchronization between the
compression context and decompression context will never be lost due
to packet losses.
5.5.1.1.2. Downward transition
Downward transitions are triggered by the need for updates or by
negative acknowledgment (NACKs and STATIC_NACKs), as described in
section 5.3.1.1.3 and 5.4.1.1.1, respectively. Note that NACKs
should rarely occur in R-mode because of the secure reference used
(see fourth paragraph of next section).
5.5.1.2. Compression logic and packets used (R-mode)
The compressor starts in the IR state by sending IR packets. It
transits to the FO state once it receives a valid ACK for an IR
packet sent (an ACK can only be valid if it refers to an SN sent
earlier). In the FO state, it sends the smallest packets that can
communicate the changes, according to W-LSB or other encoding rules.
Those packets could be of type R-1*, UOR-2, or even IR-DYN.
The compressor will transit to the SO state after it has determined
the presence of a string (see section 2), while also being confident
that the decompressor has the string parameters. The confidence can
be based on ACKs. For example, in a typical case where the string
pattern has the form of non-SN-field = SN * slope + offset, one ACK
is enough if the slope has been previously established by the
decompressor (i.e., only the new offset needs to be synchronized).
Otherwise, two ACKs are required since the decompressor needs two
headers to learn both the new slope and the new offset. In the SO
state, R-0* packets will be sent.
Note that a direct transition from the IR state to the SO state is
possible.
The secure reference principle is enforced in both compression and
decompression logic. The principle means that only a packet carrying
a 7- or 8-bit CRC can update the decompression context and be used as
a reference for subsequent decompression. Consequently, only field
values of update packets need to be added to the encoding sliding
windows (see 4.5) maintained by the compressor.
Reasons for the compressor to send update packets include:
1) The update may lead to a transition to higher compression
efficiency (meaning either a higher compression state or smaller
packets in the same state).
----------------------------------------------------------------[Page 66]
2) It is desirable to shrink sliding windows. Windows are only
shrunk when an ACK is received.
The generation of a CRC is infrequent since it is only needed for
an update packet.
One algorithm for sending update packets could be:
* Let pRTT be the number of packets that are sent during one
round-trip time. In the SO state, when (64 - pRTT) headers have
been sent since the last acked reference, the compressor will
send m1 consecutive R-0-CRC headers, then send (pRTT - m1) R-0
headers. After these headers have been sent, if the compressor
has not received an ACK to at least one of the previously sent
R0-CRC, it sends R-0-CRC headers continuously until it receives a
corresponding ACK. m1 is an implementation parameter, which can
be as large as pRTT.
* In the FO state, m2 UOR-2 headers are sent when there is a
pattern change, after which the compressor sends (pRTT - m2)
R-1-* headers. m2 is an implementation parameter, which can be
as large as pRTT. At that time, if the compressor has not
received enough ACKs to the previously sent UOR-2 packets in
order to transit to SO state, it can repeat the cycle with the
same m2, or repeat the cycle with a larger m2, or send UOR-2
headers continuously (m2 = pRTT). The operation stops when the
compressor has received enough ACKs to make the transition.
An algorithm for processing ACKs could be:
* Upon reception of an ACK, the compressor first derives the
complete SN (see section 5.7.6.1). Then it searches the sliding
window for an update packet that has the same SN. If found, that
packet is the one being ACKed. Otherwise, the ACK is invalid and
MUST be discarded.
* It is possible, although unlikely, that residual errors on the
reverse channel could cause a packet to mimic a valid ACK
feedback. The compressor may use a local clock to reduce the
probability of processing such a mistaken ACK. After finding the
update packet as described above, the compressor can check the
time elapsed since the packet was sent. If the time is longer
than RTT_U, or shorter than RTT_L, the compressor may choose to
discard the ACK. RTT_U and RTT_L correspond to an upper bound
and lower bound of the RTT, respectively. (These bounds should
be chosen appropriately to allow some variation of RTT.) Note
that the only side effect of discarding a good ACK is slightly
reduced compression efficiency.
----------------------------------------------------------------[Page 67]
5.5.2. Decompressor states and logic (R-mode)
The decompression states and the state transition logic are the same
as for the Unidirectional case (see section 5.3.2). What differs is
the decompression and feedback logic.
5.5.2.1. Decompression logic (R-mode)
The rules for when decompression is allowed are the same as for U-
mode. Although the acking scheme in R-mode guarantees that non-
decompressible packets are never sent by the compressor, residual
errors can cause delivery of unexpected packets for which
decompression should not be attempted.
Decompression MUST follow the secure reference principle as described
in 5.5.1.2.
CRC verification is infrequent since only update packets carry CRCs.
A CRC mismatch can only occur due to 1) residual bit errors in the
current header, and/or 2) a damaged context due to residual bit
errors in previous headers or feedback. Although it is impossible to
determine which is the actual cause, case 1 is more likely, as a
previous header reconstructed according to a damaged packet is
unlikely to pass the 7- or 8-bit CRC, and damaged packets are
unlikely to result in feedback that damages the context. The
decompressor SHOULD act according to section 5.3.2.2.3 when CRCs
fail, except that no local repair is performed. Note that all the
parameter numbers, k_1, n_1, k_2, and n_2, are applied to the update
packets only (i.e., exclude R-0, R-1*).
5.5.2.2. Feedback logic (R-mode)
The feedback logic for the Bidirectional Reliable mode is as follows:
- When an updating packet (i.e., a packet carrying a 7- or 8-bit CRC)
is correctly decompressed, send an ACK(R), subject to the sparse
ACK mechanism described below.
- When context damage is detected, send a NACK(R) if in Full Context
state, or a STATIC-NACK(R) if in Static Context state.
- In No Context state, send a STATIC-NACK(R) when receiving a non-IR
packet, subject to the considerations at the beginning of section
5.7.6. The decompressor SHOULD NOT send STATIC-NACK(R) when
receiving an IR packet that fails the CRC check, as the compressor
will stay in IR state and thus continue sending IR packets until a
valid ACK is received (see section 5.5.1.2).
----------------------------------------------------------------[Page 68]
- Feedback is never sent for packets not updating the context (i.e.,
packets that do not carry a CRC)
A mechanism called "Sparse ACK" can be applied to reduce the feedback
overhead caused by a large RTT. For a sequence of ACK-triggering
events, a minimal set of ACKs MUST be sent:
1) For a sequence of R-0-CRC packets, the first one MUST be ACKed.
2) For a sequence of UOR-2, IR, or IR-DYN packets, the first N of
them MUST be ACKEd, where N is the number of ACKs needed to give
the compressor confidence that the decompressor has acquired the
new string parameters (see second paragraph of 5.5.1.2). In case
the decompressor cannot determine the value of N, the default
value 2 SHOULD be used. If the subsequently received packets
continue the same change pattern of header fields, sparse ACK can
be applied. Otherwise, each new pattern MUST be treated as a new
sequence, i.e., the first N packets that exhibit a new pattern
MUST be ACKed.
After sending these minimal ACKs, the decompressor MAY choose to ACK
only k subsequent packets per RTT ("Sparse ACKs"), where k is an
implementation parameter. To achieve robustness against loss of
ACKs, k SHOULD be at least 1.
To avoid ambiguity at the compressor, the decompressor MUST use the
feedback format whose SN field length is equal to or larger than the
one in the compressed packet that triggered the feedback.
Context damage is detected according to the principles in 5.3.2.2.3.
When the decompressor is capable of timer-based compression of the
RTP Timestamp (e.g., it has access to a clock with sufficient
resolution, and the jitter introduced internally in the receiving
node is sufficiently small) it SHOULD signal that it is ready to do
timer-based compression of the RTP Timestamp. The compressor will
then make a decision based on its knowledge of the channel and the
observed properties of the packet stream.
5.6. Mode transitions
The decision to move from one compression mode to another is taken by
the decompressor and the possible mode transitions are shown in the
figure below. Subsequent chapters describe how the transitions are
performed together with exceptions for the compression and
decompression functionality during transitions.
----------------------------------------------------------------[Page 69]
+-------------------------+
| Unidirectional (U) mode |
+-------------------------+
/ ^ \ ^
/ / Feedback(U) \ \ Feedback(U)
/ / \ \
/ / \ \
Feedback(O) / / Feedback(R) \ \
v / v \
+---------------------+ Feedback(R) +-------------------+
| Optimistic (O) mode | ----------------> | Reliable (R) mode |
| | <---------------- | |
+---------------------+ Feedback(O) +-------------------+
5.6.1. Compression and decompression during mode transitions
The following sections assume that, for each context, the compressor
and decompressor maintain a variable whose value is the current
compression mode for that context. The value of the variable
controls, for the context in question, which packet types to use,
which actions to be taken, etc.
As a safeguard against residual errors, all feedback sent during a
mode transition MUST be protected by a CRC, i.e., the CRC option MUST
be used. A mode transition MUST NOT be initiated by feedback which
is not protected by a CRC.
The subsequent subsections define exactly when to change the value of
the MODE variable. When ROHC transits between compression modes,
there are several cases where the behavior of compressor or
decompressor must be restricted during the transition phase. These
restrictions are defined by exception parameters that specify which
restrictions to apply. The transition descriptions in subsequent
chapters refer to these exception parameters and defines when they
are set and to what values. All mode related parameters are listed
below together with their possible values, with explanations and
restrictions:
Parameters for the compressor side:
- C_MODE:
Possible values for the C_MODE parameter are (U)NIDIRECTIONAL,
(O)PTIMISTIC and (R)ELIABLE. C_MODE MUST be initialized to U.
- C_TRANS:
Possible values for the C_TRANS parameter are (P)ENDING and
(D)ONE. C_TRANS MUST be initialized to D. When C_TRANS is P,
it is REQUIRED
----------------------------------------------------------------[Page 70]
1) that the compressor only use packet formats common to all
modes,
2) that mode information is included in packets sent, at least
periodically,
3) that the compressor not transit to the SO state,
4) that new mode transition requests be ignored.
Parameters for the decompressor side:
- D_MODE:
Possible values for the D_MODE parameter are (U)NIDIRECTIONAL,
(O)PTIMISTIC and (R)ELIABLE. D_MODE MUST be initialized to U.
- D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING and (D)ONE. D_TRANS MUST be initialized to D. A
mode transition can be initiated only when D_TRANS is D. While
D_TRANS is I, the decompressor sends a NACK or ACK carrying a
CRC option for each received packet.
5.6.2. Transition from Unidirectional to Optimistic mode
When there is a feedback channel available, the decompressor may at
any moment decide to initiate transition from Unidirectional to
Bidirectional Optimistic mode. Any feedback packet carrying a CRC
can be used with the mode parameter set to O. The decompressor can
then directly start working in Optimistic mode. The compressor
transits from Unidirectional to Optimistic mode as soon as it
receives any feedback packet that has the mode parameter set to O and
that passes the CRC check. The transition procedure is described
below:
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_MODE = O
| +-<-<-<-<-<-<-<-+ |
C_MODE = O |-<-<-<-+ |
| |
If the feedback packet is lost, the compressor will continue to work
in Unidirectional mode, but as soon as any feedback packet reaches
the compressor it will transit to Optimistic mode.
----------------------------------------------------------------[Page 71]
5.6.3. From Optimistic to Reliable mode
Transition from Optimistic to Reliable mode is permitted only after
at least one packet has been correctly decompressed, which means that
at least the static part of the context is established. An ACK(R) or
a NACK(R) feedback packet carrying a CRC is sent to initiate the mode
transition. The compressor MUST NOT use packet types 0 or 1 during
transition. The transition procedure is described below:
Compressor Decompressor
----------------------------------------------
| |
| ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = R | |
|->->->-+ IR/IR-DYN/UOR-2(SN,R) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = R
| ACK(SN,R) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ R-0*, R-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
As long as the decompressor has not received an UOR-2, IR-DYN, or IR
packet with the mode transition parameter set to R, it must stay in
Optimistic mode. The compressor must not send packet types 1 or 0
while C_TRANS is P, i.e., not until it has received an ACK for a
UOR-2, IR-DYN, or IR packet sent with the mode transition parameter
set to R. When the decompressor receives packet types 0 or 1, after
having ACKed an UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
5.6.4. From Unidirectional to Reliable mode
The transition from Unidirectional to Reliable mode follows the same
transition procedure as defined in section 5.6.3 above.
5.6.5. From Reliable to Optimistic mode
Either the ACK(O) or the NACK(O) feedback packet is used to initiate
the transition from Reliable to Optimistic mode and the compressor
MUST always run in the FO state during transition. The transition
procedure is described below:
----------------------------------------------------------------[Page 72]
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_MODE = O
|->-.. |
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
As long as the decompressor has not received an UOR-2, IR-DYN, or IR
packet with the mode transition parameter set to O, it must stay in
Reliable mode. The compressor must not send packet types 0 or 1
while C_TRANS is P, i.e., not until it has received an ACK for an
UOR-2, IR-DYN, or IR packet sent with the mode transition parameter
set to O. When the decompressor receives packet types 0 or 1, after
having ACKed the UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
5.6.6. Transition to Unidirectional mode
The decompressor can force a transition back to Unidirectional mode
if it desires to do so. Regardless of which mode this transition
starts from, a three-way handshake MUST be carried out to ensure
correct transition on the compressor side. The transition procedure
is described below:
----------------------------------------------------------------[Page 73]
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN/UOR-2(SN,U) |
| +->->->->->->->-+ |
|->-.. +->->->-|
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D, D_MODE= U
After ACKing the first UOR-2(U), IR-DYN(U), or IR(U), the
decompressor MUST continue to send feedback with the Mode parameter
set to U until it receives packet types 0 or 1.
Next To :: RObust Header Compression - Part 4
Credits
-- UnKnown --
|