Jedną z głównych funkcji kompresji nagłówka PDCP jest użycie solidnego protokołu Header Compression (ROHC) zdefiniowanego przez IETF (Internet Engineering Task Force). W LTE kompresja nagłówka jest bardzo ważna, ponieważ nie ma obsługi transportu domeny głosowej z komutacją łączy (CS). Zatem, aby świadczyć usługi głosowe (PS), pakiet domenowy — przełączony na sposób zbliżony do braków zwykle kojarzonych z usługami CS, musi znajdować się poza komplementem IP/UDP/RTP3, który jest zwykle używany w usługach Voice over IP (VoIP).
Określony w IETF „RFC 4995”, framework obsługujący wiele „profili” różnej kompresji nagłówków (np. zestawy reguł i parametrów do wykonywania kompresji). Obsługiwane profile kompresji nagłówka dla LTE są wymienione w tabeli. Oznacza to, że UE może wdrożyć jeden lub więcej profili ROHC. Należy zauważyć, że profile zostały wcześniej zdefiniowane w IETF, „RFC 3095” zostało na nowo zdefiniowane w RFC 4995, aby w niektórych przypadkach zwiększyć wytrzymałość. Wydajność RFC 3095 i RFC 4995 jest podobna, a UMTS obsługuje tylko RFC 3095.
Wsparcie ROHC jest obowiązkowe w UE, z wyjątkiem UES obsługującego VoIP. UES obsługujący VoIP musi obsługiwać co najmniej jeden profil kompresji RTP, UDP i IP. Sygnalizacja eNodeB RRC kontroluje, czy można używać profili ROHC obsługiwanych przez UE. Kompresor UE ROHC i eNodeB następnie dynamicznie wykrywają przepływy IP przy użyciu określonej konfiguracji kompresji nagłówka IP i wybierają odpowiedni profil dozwolonych i obsługiwanych profili.
Kompresja nagłówka
ROHC polega na tym, że zarówno nadawca, jak i odbiorca przechowują stan nagłówka (np. adresy IP nadawcy/odbiorcy) i aktualizują je tylko w przypadku ich zmiany. Ponadto komponenty dynamiczne (na przykład zewnętrzny znacznik czasu RTP) są kompresowane na podstawie numeru transmisji innego niż utrzymywany zegar referencyjny.
Częściowo nie – w ten sposób zmieniające się nagłówki są wysyłane, gdy powodzenie dekompresji zależy od prawidłowego odbioru. Dlatego też informacja zwrotna jest wykorzystywana w celu potwierdzenia prawidłowego otrzymania informacji inicjującej dla dekompresji nagłówka. Dodatkowo prawidłowa dekompresja APRIM PDCP PDU jest okresowo potwierdzana utratą pakietów.
Jak wspomniano powyżej, najważniejszym przypadkiem użycia ROHC jest VoIP. Zwykle w przypadku transportu pakietu VoIP, który zawiera 32-bajtowy ładunek, nagłówek zostanie dodany od 60 do 40 bajtów w przypadku IPv6 i IPv4 – to znaczy górny nagłówek odpowiednio 188% i 125%. Za pomocą ROHC, jednostek kompresji nagłówka, ten narzut może zostać skompresowany do czterech do sześciu bajtów, a zatem względny kierunek 12,5-18,8%. To obliczenie dotyczy aktywnych okresów, ale w czasach pokoju rozmiar jest mniej przydatny, np. względny narzut jest duży.