Una delle funzioni principali della compressione dell’intestazione PDCP è l’utilizzo del robusto protocollo ROHC (Header Compression) definito da IETF (Internet Engineering Task Force). In LTE, la compressione dell’intestazione è molto importante perché non è disponibile il supporto per il trasporto del dominio vocale a commutazione di circuito (CS). Pertanto, per fornire servizi vocali (PS), il pacchetto di dominio – Passato a un modo che si avvicina a quello carente normalmente associato ai servizi CS deve essere esterno al complemento IP/UDP/RTP3 che viene solitamente utilizzato per i servizi Voice over IP (VoIP).
Specificato nell’IETF “RFC 4995”, un framework che supporta una serie di “profili” di diversa compressione dell’intestazione (ad es. insiemi di regole e parametri per eseguire la compressione). I profili di compressione dell’intestazione supportati per LTE sono elencati nella tabella. Ciò significa che l’UE può implementare uno o più profili ROHC. È importante notare che i profili sono stati definiti in IETF in precedenza, “RFC 3095” è stato ridefinito in RFC 4995, al fine di aumentarne la robustezza in alcuni casi. L’efficienza di RFC 3095 e RFC 4995 è simile, e UMTS supporta solo RFC 3095.
Il supporto di ROHC è obbligatorio per UE, ad eccezione di UES che supportano VoIP. L’UES che supporta VoIP deve supportare almeno un profilo di compressione RTP, UDP e IP. La segnalazione eNodeB RRC controlla che i profili ROHC supportati dall’UE possano essere utilizzati. Il compressore UE ROHC e eNodeB rilevano quindi dinamicamente i flussi IP utilizzando una determinata compressione dell’intestazione IP di configurazione e scelgono un profilo adatto tra i profili consentiti e supportati.
La compressione dell’intestazione
ROHC funziona consentendo sia al mittente che al destinatario di memorizzare lo stato dell’intestazione (ad esempio gli indirizzi IP del mittente/destinatario) e di aggiornarli solo quando cambiano. Inoltre, i componenti dinamici (ad esempio, timestamp RTP esterno) vengono compressi dal numero di trasmissione diverso da un orologio di riferimento mantenuto.
Come parte non – quindi la modifica delle intestazioni viene inviata una volta che il successo della decompressione dipende dalla corretta ricezione. Pertanto, il feedback viene utilizzato per confermare la corretta ricezione delle informazioni di inizializzazione per la decompressione dell’intestazione. Inoltre, la corretta decompressione APRIM PDCP PDU è confermata periodicamente dalle perdite di pacchetti.
Come accennato in precedenza, il caso d’uso più importante per ROHC è il VoIP. In genere, per il trasporto di un pacchetto VoIP, che contiene un payload di 32 byte, l’intestazione verrà aggiunta da 60 a 40 byte per i casi IPv6 e IPv4, ovvero un top head rispettivamente del 188% e 125%. Tramite il ROHC, l’entità di compressione dell’intestazione, questo sovraccarico può essere compresso da quattro a sei byte e quindi una direzione relativa del 12,5-18,8%. Questo calcolo è valido per i periodi attivi, ma in tempi di pace la dimensione è meno utile, ad esempio il sovraccarico relativo è elevato.