1 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM RTP Header Compression using RObust Header Compression (ROHC) Keith Miller Nokia Inc March 27, 2001 Notice ©2001 NOKIA Incorporated. All rights reserved. The information contained in this contribution is provided for the sole purpose of promoting discussion within the 3GPP2 and its Organization Partners and is not binding on the contributor. The contributor reserves the right to add to, amend, or withdraw the statements contained herein. NOKIA Incorporated grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include portions of the contribution; and at the Organization Partner's sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner's standards publication. The contributor may hold one or more patents or copyrights that cover information contained in this contribution. A license will be made available to applicants under reasonable terms and conditions that are demonstrably free of any unfair discrimination. Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent, whether or not the use of information herein necessarily employs an invention of any existing or later issued patent, or copyright. The contributor reserves the right to use all material submitted in this contribution for his own purposes, including republication and distribution to others.. 3GPP2-C12# ?

2 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM Why RTP Header Compression? IP/UDP/RTP header is at least 40 bytes (IPv4), or 60 bytes (IPv6) Payload with 20 or fewer bytes of actual data common for VoIP For limited bandwidth links (like cellular), this overhead is intolerable! Published compression scheme (IETF RFC 2508) not suitable poor performance at high error rates (10 -3 BER) or when delay is long (200 mS) error propagation (one bad packet can cause loss of next 'N' good ones) A New Robust & Efficient Header Compression scheme is needed: Full transparency: regenerates original header exactly Robustness: to errors and error bursts Efficiency: produces a very small compressed header size IP header (20 in v4, 40 in v6)UDP header (8)RTP header (12)Payload (~20 to 30)

3 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM Voice sample Header Compression: Functional Diagram Header Compressor Radio More L2/L1 Radio More L2/L1 Header Decompressor IP UDP RTP IPUDPRTP Voice sample Air interface VoIP Client Voice sample CH IP/UDP/RTP Header Reproduced Exactly Functions Performed by e.g. PDCP Layer In 3GPP Cellular probably between UDP/PPP in 3GPP2

4 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM IETF ROHC Working Group IETF BOF on Robust Header Compression, November 1999 IETF ROHC (RObust Header Compression) Working Group formed in March 2000 to "define an efficient/robust Header Compression scheme for wireless links" ROHC WG Charter: ROHC Requirements: Work done primarily through - last few months especially have seen many exchanges (original deadline for work completion was 9/00) ROHC WG archives: Latest ROHC WG Draft: In last call in IETF

5 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM Robust Header Compression The good news: Most fields in the headers don't change from packet-to-packet Only need to send them once, at the beginning of session Fields that change tend to behave with a certain 'pattern' When pattern not followed, need to send a few more bits to represent irregularity In most cases, only a few of the many protocol header fields have to be 'worried about': RTP-SN (RTP sequence number) RTP-TS (RTP time stamp) IP-ID (IPv4 only, for fragmentation and reassembly) RTP Marker bit indicates start or end of some event (e.g. talkspurt) IP TOS, TTL, and UDP Checksum are other potentially problematic fields RTP CSRC and IPv6 Header Extension Fields

6 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Compressor Operation Compressor Functions in 3 possible states (lowest to highest): Initiation and Refresh (IR), First Order (FO), and Second Order (SO) Compressor starts in lowest state and progresses to highest Compressor always tries to operate in highest possible state IR state: initializes or refreshes static header info at decompressor FO state: communicates irregularities in packet stream to decompressor SO state: optimal state; essentially only a small sequence number is sent Transitions to higher states occur when compressor has some confidence that decompressor has received some information 'N' transmissions ('N' based on expected channel conditions) decompressor feedback IR StateFO StateSO State

7 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM Context: information associated with a packet stream used by compressor/ decompressor to compress original header/decompress compressed header Typically consists of uncompressed version of last header processed, plus additional information about header's expected 'pattern' of change Decompressor must maintain a context consistent with the compressor's! Decompressor state driven by amount of 'context' information it has Decompressor states: No Context, Static Context, and Full Context state No Context: at initialization, prior to successful decompression of any packet Static Context: after static header info (e.g., 'IR header') is received correctly from compressor Full Context: after all information needed to decompress optimally compressed headers ('SO headers') has been received (e.g., 'FO header' data obtained) ROHC Decompressor Operation No ContextStatic ContextFull Context

8 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Modes of Operation (1/2) ROHC scheme has 3 modes of operation Unidirectional Mode no feedback path periodic refreshes/timeouts, since no decompressor feedback CRC sent in every compressed header Bidirectional Optimistic Mode feedback path, 'normal' channel conditions expected CRC sent in every compressed header if decompression fails, explicit request sent from decompressor to compressor on feedback path; reactive approach good robustness characteristics under 'typical' cellular radio conditions, but can have poor performance characteristics when the radio link significantly degrades Bidirectional Reliable Mode feedback path, no special channel conditions assumed decompressor periodically sends ACKs on feedback path to indicate it's current state; proactive approach almost complete robustness against lost packett, but also introduces a small amount of additional overhead in some cases

9 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Modes of Operation (2/2) Transitioning between the three modes is allowed Which mode is used depends on the compressor's environment Presence of a feedback path or not Link error rate and distribution ALL modes are required to be implemented Operation begins in the unidirectional mode and proceeds based on the type of feedback received (or lack thereof)

10 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Encoding Methods (1/2) Many Encoding Methods used to optimize ROHC efficiency LSB Encoding send k LSBs of value, which are applied to a maintained reference at the decompressor problem if there is excessive loss (possible ambiguity at decompressor) Window-Based LSB Encoding 'robustized' version of above sends number of bits 'k' based on knowledge of possible references decompressor might use (values are kept in a 'window' at compressor) window is 'shrunk' based on decompressor feedback (or by fixing window size) Scaled RTP Timestamp Compression RTP timestamp changes occur in units of 'TS-Stride' (change = N*TS-Stride) TS-Stride depends on codec (20 mS voice codec has TS-Stride = 160); communicated to decompressor ahead of time Send only value 'N' when timestamp needs to be communicated

11 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Encoding Methods (2/2) Timer-Based RTP Timestamp Compression Due to Transmitter/Receiver timing relationship, wall-clock at receiver can be used to approximate RTP Timestamp value send 'm' bits to represent possible timing jitter and regenerate exact timestamp timestamp 'jumps' due to silence representable in a fixed number of bits Offset IP-ID Encoding: For IPv4; used if IP-ID increments sequentially with each outgoing packet In this case, IP-ID always increments by at least one if RTP sequence number (RTP-SN) is also known to increment by one with each packet, it is more efficient to code difference in IP-ID and RTP-SN List-Based Compression: In some cases, header fields associated with a packet can be modeled as an 'ordered list' Fields are occasionally added to or deleted from the list Compression encodes only these additions and deletions Particularly useful for some RTP header fields and for IPv6 extension headers

12 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM Exp. Performance - 'Reliable' mode RTP/UDP/IPv4 No UDP Checksum Window-Based LSB Timer-Based RTP-TS

13 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM Additional Details

14 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Unidirectional Mode Unidirectional (U-mode) when a reliable feedback path isn't available, or performance of FB is poor compressor state transitions based on periodic timeouts and irregularities observed in incoming packet header fields is the least efficient state, due to periodic refreshes (no feedback, so don't know decompressors situation) CRC transmitted with every compressed header, used to verify correct decompression A ROHC compressor always starts in this state

15 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Optimistic Mode Bidirectional optimistic (O-mode) very similar to U-mode, but used when a reliable FB path is available FB used to send error recovery requests; requests should be only occasional - reactive approach to error handling CRC transmitted with every compressed header, used to verify correct decompression provides reasonable level of robustness as long as radio channel behaves 'normally'; but performance is can be poor at high error rates

16 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Reliable Mode Bidirectional reliable (R-mode) quite different in concept from U/O modes more intensive use of FB channel to send ACKs; all changes in context ACKed - proactive approach CRC used only for 'critical' information exchanges (e.g., at transitions from one operating state to another) ACK transmission on FB channel is the primary mechanism for robustness almost complete robustness achieved; scheme is effective even when error rates are very high

17 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Header Field Encoding LSB Encoding LSB (Least Significant Bit) Encoding Used to encode small changes in header fields Idea: transmit only the 'k' least signficant bits Value represented by k bits is applied to a reference at the decompressor in order to regenerate original header field value Fault: 'excessive' packet loss could result in k bits not being enough - ambiguity at the receiver and incorrect decompression

18 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Header Field Encoding Window-Based LSB Encoding Window -Based LSB Encoding 'Robustizes' basic LSB, which can fail under some conditions Idea: compressor always uses a number of bits 'k' such that there is little/no chance of ambiguity at receiver Value of k used is picked based on compressor knowledge of all possible references that decompressor might use Compressor keeps these possible references in a 'window' Occasional ACKs from decompressor indicate when values can be 'removed' from the window (alternatively, window can have fixed size)

19 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Header Field Encoding Window-Based LSB Encoding - Example Example: Suppose packets with header fields 279, 280, 281, 282, and 283 have been sent, and 279 and 283 are fields of potential reference packets. So the current window, W, is {279, 283}. Assume a packet with field value = 284 is received next. Window-Based LSB Encoding proceeds as follows: New Value VMax VMin Max # LSBs needed max[| |,| |]=5 4 Where #LSBs needed = ceiling {log 2 (2*Max + 1)} The window is unmodified if we assume the new packet {284} is not a potential reference. The field is encoded using 4 bits in this case, and the actual encoded value is the 4 least significant bits of 284 ( ) which = 1100.

20 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Header Field Encoding Scaled RTP Timestamp Encoding Scaled RTP-TimeStamp Encoding Issue: RTP timestamp tends to change in increments which correspond to Sampling rate (for voice codecs); e.g., 20 mS means RTP timestamp increment of 160 Frame rate (video codec) Call this increment TS-Stride Idea: When representing an irregular change in RTP timestamp, represent the change in units of TS-Stride instead of the actual change in field value Example: 2 second silence interval in voice produced by 20 mS voice codec (e.g. AMR) produces a jump of would require n=14 bits to represent. With Scaled RTP-TS Encoding, represent change in units of TS-Stride; = 100 units, representable in only 7 bits Some special handling when RTP-TS value wraps around is required

21 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Header Field Encoding Timer-Based Timestamp Compression (1/2) Compress RTP TS exploiting the fact that RTP TS is of the form TS0 + n * TS_stride TS0 = time offset TS_stride = timestamp delta can use n (= 'packed' RTP TS) as a more concise form of RTP TS, without loss of information RTP TS can be approximated by wall-clock ---> can use local clock at the decompressor to obtain an approximation Transmission jitter (from packet source to decompressor) can introduce error in the approximation To offset the error, compressor sends k least significant bits of packed RTP TS, where the value of k is calculated based on jitter

22 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM ROHC Header Field Encoding Timer-Based Timestamp Compression (2/2) The Decompressor Approximates the current packed RTP TS = packed RTP TS of reference packet + time elapsed since reference packet reference packet is last correctly decompressed packet Refines approximation by choosing the value closest to the approximation whose k LSBs match the received k bits; k is calculated by the compressor using a sliding window similar to the one in Window-Based LSB Encoding Very useful for voice traffic with silence suppression since the number of bits in compressed RTP TS does not increase with silence period