Een van de belangrijkste functies van de PDCP-headercompressie is het gebruik van het robuuste ROHC-protocol (Header Compression), gedefinieerd door IETF (Internet Engineering Task Force). In LTE is headercompressie erg belangrijk omdat er geen ondersteuning is voor het transport van spraakcircuitgeschakelde domeinen (CS). Dus om spraakdiensten (PS) aan te bieden, moet het domein Packet – Overgeschakeld naar een manier die deficiënt benadert die normaal gesproken wordt geassocieerd met CS-diensten buiten het IP/UDP/RTP3-compliment vallen dat meestal wordt gebruikt voor Voice over IP (VoIP)-diensten.
Gespecificeerd in de IETF “RFC 4995,” een raamwerk dat een aantal “profielen” ondersteunt voor verschillende headercompressie (bijv. sets met regels en parameters voor het uitvoeren van compressie). Ondersteunde headercompressieprofielen voor de LTE staan vermeld in de tabel. Dit betekent dat de EU een of meer van de ROHC-profielen kan implementeren. Het is belangrijk op te merken dat de profielen eerder in de IETF zijn gedefinieerd, “RFC 3095” is opnieuw gedefinieerd in RFC 4995, om in sommige gevallen de sterkte te vergroten. De efficiëntie van RFC 3095 en RFC 4995 is vergelijkbaar, en UMTS ondersteunt alleen RFC 3095.
Ondersteuning van ROHC is verplicht UE, behalve UES die VoIP ondersteunt. UES die VoIP ondersteunt, moet ten minste één RTP-compressieprofiel ondersteunen, UDP en IP. De eNodeB RRC-signalering bestuurt de ROHC-profielen die worden ondersteund door de UE en mogen worden gebruikt. UE ROHC-compressor en eNodeB detecteren vervolgens dynamisch IP-stromen met behulp van een bepaalde configuratie IP-headercompressie en kiezen een geschikt profiel van toegestane en ondersteunde profielen.
ROHC-headercompressie werkt doordat zowel de afzender als de ontvanger de status van de header (bijvoorbeeld IP-adressen van de afzender/ontvanger) kunnen opslaan en deze alleen kunnen bijwerken als deze veranderen. Bovendien worden de dynamische componenten (bijvoorbeeld RTP-tijdstempel buiten) gecomprimeerd vanaf het transmissienummer, waarbij een referentieklok wordt aangehouden.
Als onderdeel niet – dus het wijzigen van de headers wordt verzonden zodra het succes van de decompressie afhangt van de juiste ontvangst. Daarom wordt de feedback gebruikt om de correcte ontvangst van de initialisatie-informatie voor header-decompressie te bevestigen. Bovendien wordt de juiste decompressie APRIM PDCP PDU periodiek bevestigd door pakketverliezen.
Zoals hierboven vermeld, is VoIP de belangrijkste use-case voor ROHC. Voor het transport van een VoIP-pakket, dat een payload van 32 bytes bevat, wordt de header doorgaans toegevoegd aan 60 bytes tot 40 bytes voor IPv6- en IPv4-gevallen – dat wil zeggen een tophead van respectievelijk 188% en 125%. Door de ROHC, de headercompressie-entiteiten, kan deze overhead worden gecomprimeerd tot vier tot zes bytes, en dus een relatieve richting van 12,5-18,8%. Deze berekening geldt voor actieve perioden, maar in tijden van vrede is de omvang minder nuttig, omdat de relatieve overhead groot is.