Wie Header-Komprimierung in LTE

Eine der Hauptfunktionen der PDCP-Header-Komprimierung ist die Verwendung des robusten Header-Komprimierungsprotokolls (ROHC), das von der IETF (Internet Engineering Task Force) definiert wurde. Bei LTE ist die Header-Komprimierung sehr wichtig, da der Transport von leitungsvermittelten Sprachdomänen (CS) nicht unterstützt wird. Um daher Sprachdienste (PS) bereitzustellen, müssen Domänenpakete auf eine Art und Weise umgeschaltet werden, die normalerweise mit CS-Diensten verbunden ist, ohne IP/UDP/RTP3-Kompatibilität, die normalerweise für Voice-over-IP-Dienste (VoIP) verwendet wird.

Spezifiziert im IETF „RFC 4995“, einem Framework, das eine Reihe von „Profilen“ unterschiedlicher Header-Komprimierung unterstützt (z. B. Regelsätze und Parameter für die Durchführung der Komprimierung). Unterstützte Header-Komprimierungsprofile für LTE sind in der Tabelle aufgeführt. Das bedeutet, dass die EU eines oder mehrere der ROHC-Profile umsetzen kann. Es ist wichtig zu beachten, dass die Profile bereits früher in der IETF definiert wurden, „RFC 3095“ wurde in RFC 4995 neu definiert, um die Stärke in einigen Fällen zu erhöhen. Die Effizienz von RFC 3095 und RFC 4995 ist ähnlich, und UMTS Unterstützt nur RFC 3095.

Supported header compression protocols in lTE

Unterstützung von ROHC ist obligatorisches UE, mit Ausnahme von UES, das VoIP unterstützt. UES, die VoIP unterstützen, müssen mindestens ein RTP-Komprimierungsprofil, UDP und IP unterstützen. Die eNodeB RRC-Signalisierung steuert, dass die vom UE unterstützten ROHC-Profile verwendet werden dürfen. UE ROHC-Kompressor und eNodeB erkennen dann dynamisch IP-Flüsse mithilfe einer bestimmten Konfiguration der IP-Header-Komprimierung und wählen ein geeignetes Profil aus zulässigen und unterstützten Profilen aus.

Die

ROHC-Header-Komprimierung funktioniert, indem sie es sowohl dem Sender als auch dem Empfänger ermöglicht, den Status des Headers (z. B. IP-Adressen des Senders/Empfängers) zu speichern und sie nur zu aktualisieren, wenn sie sich ändern. Darüber hinaus werden die dynamischen Komponenten (z. B. RTP-Zeitstempel außerhalb) komprimiert und von der Übertragungsnummer abweichend ein Referenztakt beibehalten.
Da dies nicht der Fall ist, werden die Header geändert, sobald der Dekomprimierungserfolg vom ordnungsgemäßen Empfang abhängt. Daher wird das Feedback verwendet, um den korrekten Empfang der Initialisierungsinformationen für die Header-Dekomprimierung zu bestätigen. Darüber hinaus wird die ordnungsgemäße Dekomprimierung der APRIM PDCP PDU regelmäßig durch Paketverluste bestätigt.

Wie oben erwähnt, ist VoIP der wichtigste Anwendungsfall für ROHC. Typischerweise werden für den Transport eines VoIP-Pakets, das eine Nutzlast von 32 Byte enthält, dem Header 60 bis 40 Byte für IPv6 und IPv4 hinzugefügt, d. h. ein Top-Head von 188 % bzw. 125 %. Durch die ROHC, die Header-Kompressionseinheiten, kann dieser Overhead auf vier bis sechs Bytes und damit auf eine relative Richtung von 12,5-18,8 % komprimiert werden. Diese Berechnung gilt für aktive Zeiträume, aber in Friedenszeiten ist die Größe weniger nützlich, da der relative Overhead groß ist.

Recent Updates

Related Posts