Requirements and Architecture for Zero-Byte Header Compression Pete McCann & Tom Hiller December 13, 2000 draft-mccann-rohc-gehcoarch-00.txt

2 Zero-Byte Header Compression Outline n Wireless link technologies n Zero byte header compression n IP stack architecture n Standardized interfaces n Conclusion

3 Zero-Byte Header Compression Wireless Link Technologies n Voice –Isochronous, 20 millisecond frames –Vocoders output frame sizes that exactly match air interface –No retransmission n Data –Retransmitting Radio Link Protocol (RLP) –Presents a reliable octet stream to upper layers –Gets error rate down into range –Adds variable amount of delay, could be on the order of 1 second n Services should be used appropriately –Voice over non-retransmitting bearer channel –Data (PPP) over retransmitting bearer channel voice data

4 Zero-Byte Header Compression n Any headers add unacceptable overhead –1 byte per vocoded frame = 12% spectrum loss based on EVRC activity –ROHC frames are variable sized »ROHC segmentation (per draft-06) introduces another 1 byte, plus CRC »Or some other method is required to delimit ROHC frames n Solution: Use the existing voice physical layer unchanged –Header stripping/regeneration –Requires tight real-time coupling of some components –Not just for wireless! »Techniques to reduce OS latency are also useful on wired, non-lossy links n But use basic ROHC whenever –Delay-intolerant service –No air-interface support for the codec being used

5 Zero-Byte Header Compression IP Stack Architecture Other NRT VOIP GEHCO Apps Control Control \ \ | IP Protocol | Stack / | / Header Strip Data Link--+ Peer Regeneration\ Layer System \___ | | \ | | Audio Codec \ >Physical<----+ Hardware Impl Channel(s)<--+

6 Zero-Byte Header Compression Interface: Full Header Signaling n Sent from compressor to decompressor –Includes full RTP header –Indicates which physical layer epoch is represented –Indicates the physical channel number (voice bearer) being used –Sent over data RLP connection and should be explicitly acknowledged n Action: Standardize in IETF –Generic frame type –Specific mapping onto PPP

7 Zero-Byte Header Compression Interface: VOIP Control API n Application (SIP, H.323 client) informs the compressor about the transport endpoints –IP addresses –UDP ports –RTP parameters (payload type, CSRC, SSRC) n Could be a 1-line addition to existing code n OS installs packet filter for the connection n Action: Standardize an API in some other industry forum

8 Zero-Byte Header Compression Interface: Real-time Connection Establishment n Data link opens over-the-air voice channel n Synchronize internal time reference with physical channel –First frame time offset –Handoff time indications n Number frames since connection established or handed off –Use this sequence number in full header packets n Action: Standardize in ITU or TIA

9 Zero-Byte Header Compression Interface: Real-time Bearer Traffic n Serial connection for relay model terminal –Real-time escapes n Integrated network model phone –DMA channels/other n Action: Standardize in ITU or TIA

10 Zero-Byte Header Compression Conclusions n Zero-byte header compression is necessary for spectral efficiency n OS and applications will evolve to support low-latency communication n New interfaces should be standardized, at least one in the IETF