Zusammenfassung

  • RFC 3095 verlangte den Start jedes ROHC-Kontexts im unidirektionalen Modus, in dem periodische Auffrischung einen fehlenden Rückkanal ersetzte.
  • Der Dekompressor konnte danach den optimistischen oder zuverlässigen bidirektionalen Modus verlangen; bestätigt wurde der Kompressionskontext, nicht die Ende-zu-Ende-Zustellung.

Das erste Paket durfte keine Antwort voraussetzen

Auf einer Funkstrecke konnten IP-, UDP- und RTP-Header größer sein als eine kleine Sprachlast. Konstante oder vorhersagbare Felder wegzulassen sparte Kapazität, zwang den Empfänger aber zur Rekonstruktion aus gemeinsamem Zustand. Ging ein Update verloren, konnten spätere, korrekt übertragene Pakete unbrauchbar werden.

RFC 3095 trennte Zustand und Modus. IR-, FO- und SO-Zustände beschrieben das Wissen des Kompressors; No Context, Static Context und Full Context beschrieben die Möglichkeiten des Dekompressors. Der Modus beantwortete eine andere Frage: Welche Rückkanal-Autorität existierte tatsächlich?

Die Anfangsregel war vorsichtig. Kompression musste in U-mode starten. Ohne Rückweg stieg der Kompressor nach dem optimistischen Prinzip auf, wenn er genügend Information wiederholt zu haben glaubte. Zeitgeber, periodische Updates und unregelmäßige Feldänderungen führten zurück zu reicheren Formaten. Plausible Zuversicht begrenzte das Schweigen; sie bewies keinen Empfang.

Der Dekompressor öffnete die bidirektionalen Modi

Der Kompressor konnte einen Rückkanal nicht herbeierklären. Nach Empfang eines Pakets konnte der Dekompressor Feedback mit dem gewünschten Modus senden und den Wechsel zu O-mode oder R-mode anstoßen.

Die Richtung war sachgerecht. Der Kompressor sah seine Sendung; der Dekompressor sah den Erfolg der Rekonstruktion. Wer den unmittelbaren Kontextfehler beobachtete, forderte eine andere Disziplin von der Seite an, die das nächste Format wählte.

RFC 4815 stellte später klar, dass der Übergang beide Seiten mit einem Dreiwege-Handshake kohärent bewegen sollte. Pakete an der Bestätigungsgrenze mussten noch nach der richtigen alten oder neuen Regel dekodiert werden. Der Name „zuverlässig“ ersetzte das Verfahren nicht.

Der optimistische Modus sparte Feedback

O-mode nutzte den Rückweg für Wiederherstellungsanforderungen und optional für Bestätigungen bedeutender Kontextupdates. Reine Sequenznummernupdates wurden anders behandelt; periodische Auffrischungen entfielen. Ziel waren hohe Effizienz und sparsames Feedback.

Das verschob das Risiko. Erkannte Schäden konnten repariert werden, doch lange Verlust- oder Fehlerbursts konnten den Kontext häufiger ungültig machen als in R-mode. Ein NACK beschrieb den lokalen Rekonstruktionszustand, nicht verständliche Sprache, Annahme durch die Anwendung oder Nutzererfolg.

Der zuverlässige Modus schützte Referenzen

R-mode verwendete den Rückkanal intensiver und strengere Logik. Alle Kontextupdates einschließlich der Sequenznummer wurden bestätigt, obwohl nicht jedes Paket den Kontext änderte. Nach dem sicheren Referenzprinzip durften nur Pakete mit sieben- oder achtbittiger CRC den Kontext aktualisieren und spätere Referenz werden.

Diese Zuverlässigkeit war begrenzt und präzise: Verlust- und Schadensfortpflanzung bei beschädigten Headern oder Rückmeldungen reduzieren. Restfehler blieben möglich. R-mode zertifizierte weder Nutzlast noch Anwendung noch den gesamten Pfad.

Der Rückweg gehörte in die Kostenrechnung

RFC 3096 nannte hohe Fehlerraten, lange Umlaufzeiten sowie WCDMA, EDGE und CDMA-2000. Der rekonstruierte Header musste semantisch dem Original entsprechen, andernfalls war das Paket zu verwerfen. Fehlerfortpflanzung sollte minimiert werden.

Hilfs- und Feedbackkanäle mussten in den Overhead eingehen. Ein winziger Hinweg-Header war nicht die ganze Rechnung, wenn Bestätigungen und Reparatur zurückflossen. RFC 3409 machte die Abhängigkeit explizit: U-mode brauchte kein Feedback; O-mode und R-mode benötigten dessen Transport durch die untere Schicht.

Textentwicklung bewies keinen Betrieb

RFC 4815 sammelte Korrekturen. RFC 4995 trennte Rahmen und Profile und hielt fest, dass Implementierer Teile von RFC 3095 komplex oder unklar fanden, während die Definitionen kompatibel blieben. RFC 5225 definierte vereinfachte ROHCv2-Profile für Verlust und Umordnung. RFC 3241 standardisierte die Aushandlung über PPP.

Das belegt Spezifikationsarbeit, nicht den Einsatz bei einem benannten Betreiber, gemessene Spektrumersparnis, gelungenen Handover oder Interoperabilität bestimmter Produkte.

Die historische Grenze ist wertvoller: RFC 3095 behandelte Feedback als gerichtete, kostentragende Fähigkeit mit einem Beobachter. Es trennte Vorhersage des Kompressors, lokale Bestätigung des gemeinsamen Kontextes und das Ergebnis, das nur Ende-zu-Ende-Messung belegen kann.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3095.html
  2. https://www.rfc-editor.org/info/rfc3095
  3. https://datatracker.ietf.org/doc/rfc3095/
  4. https://www.rfc-editor.org/rfc/rfc3096.html
  5. https://www.rfc-editor.org/info/rfc3096
  6. https://datatracker.ietf.org/doc/rfc3096/
  7. https://www.rfc-editor.org/rfc/rfc1144.html
  8. https://www.rfc-editor.org/rfc/rfc2508.html
  9. https://www.rfc-editor.org/rfc/rfc3241.html
  10. https://www.rfc-editor.org/rfc/rfc3409.html
  11. https://www.rfc-editor.org/rfc/rfc4815.html
  12. https://www.rfc-editor.org/info/rfc4815
  13. https://www.rfc-editor.org/rfc/rfc4995.html
  14. https://www.rfc-editor.org/rfc/rfc5225.html