DE102005007552A1

DE102005007552A1 - Verfahren zum Versenden von Applikationspaketen variabler Paketlänge, sowie zugehörige Sender- und Empfängereinheit

Info

Publication number: DE102005007552A1
Application number: DE102005007552A
Authority: DE
Inventors: Jürgen Dr. Pandel; Thomas Stockhammer; Imre Dr. Varga; Wen Dr. Xu
Original assignee: Siemens AG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2005-02-18
Filing date: 2005-02-18
Publication date: 2006-08-31

Abstract

Applikationspakete (AP) variabler Paketlänge, die von einem Media-Encoder (MEN) ausgegeben werden, werden in Transportpaketen (MTP) vorgegebenen Transportpaketformats über einen Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS) versendet. Durch einen nachfolgenden paketbasierten Vorwärtsfehlerschutz für Gruppen von ein oder mehreren Transportpaketen (OTP) werden Paritätssymbole erzeugt, die in Paritätspakete (PTP) mit demselben vorgegebenen Transportpaketformat wie die Transportpakete (MTP) der Apllikationspakete (AP) eingepackt werden. Die Transportpakete (MTP) der Applikationspakete (AP) und die Paritätspakete (PTP) werden dann über einen fehlerhaften Transportkanal (PTK) übertragen, wodurch die Transportpakete (MTP) und die Paritätspakete (PTP) des vorgegebenen Transportpaketformats bei einer Empfängereinheit (RE) des Nachrichten-/Datenpaket-Transportsystems (TS) entweder komplett und fehlerfrei ankommen oder komplett verloren gehen. Das jeweilige Applikationspaket (AP) wird vor der Vorwärtsfehlerschutzeinheit (FSE) zusätzlich mit Hilfe einer Fragmentierungseinheit (FE) in mehrere Fragmente (FAP) zerlegt, die jeweils eine kleinere Länge als das ursprüngliche Applikationspaket (AP) aufweisen, wenn die Länge des Applikationspakets (AP) eine vorgegebene Obergrenze überschreitet.

Description

Die Erfindung betrifft ein Verfahren zum Versenden von Applikationspaketen variabler Paketlänge, die von einem Media-Encoder ausgegeben werden, in Transportpaketen vorgegebenen Transportpaketformats über einen Transportkanal eines Nachrichten-/Datenpaket-Transportsystems, wobei durch einen paketbasierten Vorwärtsfehlerschutz einer nachgeordneten Vorwärtsfehlerschutzeinheit für Gruppen von ein oder mehreren Transportpaketen Paritätssymbole erzeugt werden, die in Paritätspakete mit demselben vorgegebenen Transportpaketformat wie die Transportpakete der Applikationspakete eingepackt werden, und wobei die Transportpakete der Applikationspakete und die Paritätspakete über einen fehlerhaften Transportkanal übertragen werden, wodurch die Transportpakete und die Paritätspakete des vorgegebenen Transportpaketformats bei einer Empfängereinheit des Nachrichten-/Datenpaket-Transportsystems entweder komplett und fehlerfrei ankommen, oder komplett verloren gehen.

In den Mobilfunksystemen GSM und UMTS wird innerhalb der Standardisierung von MBMS (Multimedia Broadcast/Multicast Service) werden derzeit Methoden eingeführt, die es erlauben, Multicast- und Broadcast-Anwendungen zu unterstützen. Die Standardisierung ist ziemlich weit fortgeschritten. Ein großes Problem bei der Broadcastübertragung ist die mangelnde Zuverlässigkeit der Übertragung, weil Adaptionen und Rückübertragungen wegen fehlender Rückkanäle nicht möglich sind. Darum ist es notwendig, einen zusätzlichen Vorwärtsfehlerschutz im System einzuführen. Um die bestehenden paketbasierten Übertragungsmodi weitestgehend wieder verwenden zu können, wird der Fehlerschutz oberhalb des IP/UDP-Layers eingeführt. Im Folgenden wird insbesondere hauptsächlich auf sogannantes Streaming-Delivery Bezug genommen, das erlaubt, RTP-basierte Anwendungen innerhalb von MBMS zu übertragen. Im Gegensatz zu Download-Applikationen können die Pakete im Fall von Streaming-Anwendungen nicht ohne weiteres durch Paketierung angepasst werden. Im Allgemeinen ist die Länge der RTP-Pakete durch die Anwendungen vorgegeben und sie wird bereits bei der Codierung festgelegt. Vor allem bei der Videocodierung ist es so, dass die Pakete oft unterschiedliche Länge haben. Im folgenden wird insbesondere explizit auf die Übertragung von Video mit Hilfe von H.264 und dem dazugehörigen RTP Payload-Format, RFC3984, eingegangen, wobei aber eine Übertragung der erläuterten Ausführungsbeispiele zum erfindungsgemäßen Verfahren, sowie die dabei verwendeten Komponenten auf Sender- und Empfangsseite eines Nachrichten-/Daten-Transportsystems auch auf zukünftige Standards möglich ist.

Die zur Verfügung stehenden RTP-Pakete werden im Fall von MBMS nun mit Hilfe eines in 3GPP TS.26.346, Abschnitt 8, beschriebenen Verfahrens so modifiziert, dass die RTP-Pakete fast unverändert übertragen werden. Es wird nur ein Header-Feld modifiziert und der Header wird durch 1–4 bytes erweitert (die exakte Syntax wird noch spezifiziert). Diese nahezu unveränderten RTP-Pakete werden nun über das Mobilfunknetz übertragen. Zusätzlich werden aus diesen Paketen Redundanzpakete durch einen noch zu spezifizierenden Code (insbesondere entweder Reed-Solomon oder Raptor Code) erzeugt, die es erlauben, beim Verlust von Original-Paketen durch die Anwendungen eines Kanaldecoders, diese verlorenen Kanalpakete wieder zu rekonstruieren.

Im Mobilfunksystem können aber diese originalen bzw. leicht modifizierten RTP-Pakete beliebiger Länge nicht in einem Stück übertragen werden, sondern sie werden auf Radioblöcke konstanter Länge segmentiert. Im Allgemeinen gehen die Radioblöcke verloren und der Verlust eines Radioblocks führt dann zum Verlust aller in diesem Radioblock beinhalteten RTP/IP-Pakete. Die Redundanz-Pakete können dabei mit Hilfe des Verfahrens in 3GPP TS26.346 relativ flexibel in der Größe bzw. Länge gewählt werden. Zur Wahl der Größe wurde vorgeschlagen, die Segmentierung und die feste Radioblockgröße mit einzubeziehen, da mit diesem Verfahren ein günstiger Abgleich zwischen Durchsatz und Verlustwahrscheinlichkeit erzielt werden kann. Im Allgemeinen ist es günstig, die Größe der Redundanz-Pakete in etwa auf die Größe der Radioblöcke, bzw. auf ein Vielfaches der Radioblockgröße unter Berücksichtigung der Header-Daten anzupassen. Dieses flexible Verfahren hat den Vorteil, dass der Fehlerschutz und vor allem die Länge der Redundanz-Pakete adaptiv auf das Übertragungssystem, z.B. UTRAN (UMTS radio access network) oder GERAN (GSM radio access network), und auf Einstellungen im Übertragungssystem, z.B. auf das gewählte Modulations- und Codierungsschema in GPRS/EGPRS angepasst werden können. Darüber hinaus wurde in den Dokumenten S4-AHP138 und S4-AHP166 vorgeschlagen, für den Fehlerschutz die IP-Pakete variabler Länge in kürzere Symbole zu zerlegen.

Eine flexible Adaptation der Größe der originalen RTP-Pakete ist aber nicht ohne weiteres möglich, wäre aber aufgrund der Gegebenheiten aber wünschenswert.

Bisher wird das ganze so gelöst, dass entweder komplett auf die Paketierung verzichtet wurde, was in einer signifikant höheren Verlustrate resultiert. Deshalb wurde vorgeschlagen, dass bereits bei der Video-Encodierung eine reduzierte und angepasste Paketgröße verwendet wird. Die kann zum Beispiel erfolgen durch die Verwendung von sogenannten „Slices" in H.264. Der Nachteil der Verwendung von „Slices" ist aber so, dass zum einen, falls ein und derselbe Videostrom über verschiedene Netze übertragen werden soll, eine angepasste Codierung individuell für jedes Netzwerk und jeden Übertragungsmodus getätigt werden muss, was natürlich sowohl Kosten als auch Transportprobleme in Zugangsnetzwerken verursachen kann, da der Videostrom verschieden codiert, beispielsweise zweimal, einmal zu GERAN-Netzwerken, einmal zu UTRAN-Netzwerken übertragen werden muss. Zum zweiten ist die Codierung mit „Slices" ineffizient, da im Video die Prädiktionsmodi signifikant eingeschränkt sind. Je nach „Slice"-Größe kann die Bitrate für dieselbe Qualität um bis zu 30% ansteigen. Schließlich wird auch gewünscht, dass ein und dasselbe Video auch im Download-Modus übertragen werden kann, was entweder eine mehrfache Encodierung bedeuten würde oder eben die Kodiereffizienz für den Download-Modus erheblich einschränkt. Eine weitere Möglichkeit wäre eine Transcodierung, indem „Slices" erst dann eingeführt werden, wenn sie benötigt werden. Diese würde aber eine signifikante Komplexitätserhöhungen, eventuell sogar im Netzwerk, nach sich ziehen und ebenso zu Codiereffizienzverlusten aufgrund der Transcodierung führen.

Die Erfindung liegt die Aufgabe zugrund, einen Weg aufzuzeigen, wie die Rekonstruierbarkeit von Applikationspaketen variabler Länge, die in Transportpakete mit einem vorgegebenen Transportpaketformat eingepackt, und mit einem zusätzlichen Vorwärtsfehlerschutz über einen fehlerhaften Transportkanal geschickt werden, verbessert wird. Diese Aufgabe wird bei einem Verfahren der eingangs genannten Art dadurch gelöst, dass das jeweilige Applikationspaket vor der Vorwärtsfehlerschutzeinheit zusätzlich mit Hilfe einer Fragmentierungseinheit in mehrere Fragmente zerlegt wird, die jeweils eine kleinere Länge als das ursprüngliche Applikationspaket aufweisen, wenn die Länge des Applikationspakets eine vorgegebene Obergrenze überschreitet, und wobei diese resultierenden Fragmente der Applikationspakete vor der Vorwärtsfehlerschutzeinheit in die Transportpakete mit dem vorgegebenen Transportpaketformat eingepackt werden.

Durch diese zusätzliche Fragmentierung von Applikationspaketen, die in Transportpaketen vorgegebenen Transportformats über einen fehlerbehafteten Transportkanal wie z.B. einen Mobilfunkkanal gesendet werden, vor dem nachfolgenden Vorwärtsfehlerschutz wird die Rekonstruierbarkeit der Applikationspakete empfängerseitig verbessert. Ferner ist eine flexible Längenanpassungsmöglichkeit zum Einkapseln der Applikationspakete variabler Länge in Transportpakete mit unterschiedlich vorgebbarem Transportpaketformat bereitgestellt.

Die Erfindung betrifft auch ein Verfahren zum Versenden von Applikationspaketen variabler Paketlänge, die von einem Media-Encoder ausgegeben werden, in Transportpaketen vorgegebenen Transportpaketformats über einen Transportkanal eines Nachrichten-/Datenpaket-Transportsystems, wobei durch einen paketbasierten Vorwärtsfehlerschutz einer nachgeordneten Vorwärtsfehlerschutzeinheit für Gruppen von ein oder mehreren Transportpaketen Paritätssymbole erzeugt werden, die in Paritätspakete mit demselben vorgegebenen Transportpaketformat wie die Transportpakete der Applikationspakete eingepackt werden, und wobei die Transportpakete der Applikationspakete und die Paritätspakete über einen fehlerhaften Transportkanal übertragen werden, wodurch die Transportpakete und die Paritätspakete des vorgegebenen Transportpaketformats bei einer Empfängereinheit des Nachrichten-/Datenpaket-Transportsystems entweder komplett und fehlerfrei ankommen, oder komplett verloren gehen, welches dadurch gekennzeichnet ist, dass die Applikationspakete vor der Vorwärtsfehlerschutzeinheit in die Transportpakete mit dem vorgegebenen Transportpaketformat eingepackt werden, und dass das jeweilige Transportpaket vor der Vorwärtsfehlerschutzeinheit zusätzlich mit Hilfe einer Fragmentierungseinheit in mehrere Fragmente zerlegt wird, die jeweils eine kleinere Länge als das ursprüngliche Transportpaket aufweisen, wenn die Länge des Transportpakets eine vorgegebene Obergrenze überschreitet.

Weiterhin betrifft die Erfindung auch Verfahren zur Rekonstruktion von Applikationspaketen nach den Ansprüchen 20, 22 sowie zugehörige Sender- sowie Empfangseinheiten nach den Ansprüchen 23 mit 26.

Sonstige Weiterbildungen der Erfindung sind in den Unteransprüchen wiedergegeben.

Die Erfindung und ihre Weiterbildungen werden nachfolgend an Hand von Zeichnungen näher erläutert.
Es zeigen:
1 in schematischer Darstellung ein erstes Ausführungsbeispiel eines Nachrichten-/Daten-Transportsystems zum erfindungsgemäßen Encodieren und Decodieren von Applikationspaketen,
2 in schematischer Darstellung eine Abwandlung des Transportsystems von 2.
Elemente mit gleicher Funktion und Wirkungsweise sind in den 1 und 2 jeweils mit denselben Bezugszeichen versehen.
1 zeigt in schematischer Darstellung ein Nachrichten-/Daten-Transportsystem TS, bei dem eine Sendereinheit SE mit einer Empfängereinheit RE über einen Paket-Transportkanal PTK kommuniziert. Der zeichnerischen Einfachheit halber sind die Komponenten der Sendereinheit SE von den Komponenten der Empfängereinheit durch eine gestrichelte Trennlinie TR voneinander separiert. Von einem Media-Encoder MEN auf der Senderseite wird eine Vielzahl von Applikationspaketen AP erzeugt, die unterschiedliche Längen, d.h. variable Paketlängen aufweisen. Um diese Applikationspakete AP variabler Paketlänge über den physikalischen Transportkanal PTK zu senden, werden die Applikationspakete mittels einer Paketierungs- bzw. Enkapsulierungseinheit GTP in originale Transportpakete OTP umgepackt, für die ein bestimmtes Transportpaketformat variabler Länge vorgegeben ist. Die originalen Transportpakete OTP werden dann in der Sendereinheit SE einer Vorwärtsfehlerschutzeinheit FSE zugeführt, die für Gruppen von ein oder mehreren Transportpaketen OTP Paritätssymbole erzeugt. Mit Hilfe einer der Vorwärtsfehlerschutzeinheit FSE zugeordneten Paketierungseinheit KPP werden die gewonnenen Paritätssymbole in Paritätspakete PTP eingekapselt bzw. umverpackt, wobei die Paritätssymbole gegebenenfalls um Headerfelder fester Länge und/oder zusätzliche Informationsfelder fester Länge erweitert werden. Die derart erzeugten Paritätspakete am Ausgang der Paketierungseinheit KPP der Vorwärtsfehlerschutzeinheit FSE sind in der 1 mit PTP bezeichnet. Parallel zum Zuführungszweig der originalen Transportpakete OTP zur Vorwärtsfehlerschutzeinheit FSE werden diese in einem parallelen Kodierungszweig der Sendereinheit SE in einer Enkapsulierungseinheit KTP um zusätzliche Informationsfelder, insbesondere Informationsbytes, oder Headerfelder fester Länge erweitert.
Es werden somit modifizierte Quellentransportpakete MTP erzeugt, die durch Transportpakete OTP mit einem zusätzlichen Header bzw. Kopffeld fester Länge gebildet sind. Die modifizierten Transportpakete MTP und die Paritätspakete PTP werden dann sequentiell in Radioblöcke RB fester Länge eingepackt und mit diesen über den Transportkanal PTK geschickt. Dabei ist der Transportkanal PTK in der Praxis fehlerhaft, wodurch die Transportpakete MTP und die Paritätspakete PTP bei der Empfängereinheit RE entweder komplett und fehlerfrei ankommen, oder komplett verloren gehen.
Um nun zu erreichen, dass von der Empfängereinheit RE die Applikationspakete AP variabler Länge, die in den Transportpaketen MTP mit einem vorgegebenen Transportpaketformat eingepackt worden sind, und mit einem zusätzlichen Vorwärtsfehlerschutz über den fehlerhaften Transportkanal PTK geschickt worden sind, verbessert rekonstruieren zu können, wird das jeweilige Applikationspaket AP in der Sendereinheit SE vor der Vorwärtsfehlerschutzeinheit FSE zusätzlich mit Hilfe einer Fragmentierungseinheit FE in mehrere Fragmente FAP zerlegt, die jeweils eine kleinere Länge als das ursprüngliche Applikationspaket AP aufweisen, wenn die Länge des Applikationspaket AP eine vorgegebene Obergrenze überschreitet. Diese Fragmentierungseinheit FE ist also der Vorwärtsfehlerschutzeinheit FSE vorangestellt. Sie ist nach dem Media-Encoder MEN und vor der Paketierungseinheit GTP zur Generierung der originalen Transportpakete vorgesehen. Dadurch, dass Applikationspakete, deren Länge eine vorgegebene Obergrenze überschreitet, vor ihrer Beaufschlagung mit einem nachfolgenden Vorwärtsfehlerschutz zusätzlich fragmentiert werden, und dann erst diese Fragmente in Transportpakete vorgegebener Transportformats über den fehlerbehafteten Transportkanal versendet werden, wird die Rekonstruierbarkeit der Applikationspakete in der Empfängereinheit RE verbessert. Darüber hinaus ist eine flexible Längenanpassung zum Einkapseln der Applikationspakete variabler Länge in Transportpakete mit unterschiedlich vorgebbaren Transportpaketformat ermöglicht.
Im Fall, dass die Applikationspakete AP zeitlich oder räumlich getrennt von der Sendereinheit SE durch einen Media-Encoder erzeugt worden sind, kann der Media-Encoder MEN in der Sendeeinheit SE von 1 auch entfallen. Die Applikationspakete AP können dann beispielsweise in einer Speichervorrichtung der Sendeeinheit SE abgelegt werden, die der zeichnerischen Übersichtlichkeit halber in der 1 weggelassenen worden ist. Insbesondere kann die Speichervorrichtung als eine mobile Speicherkarte ausgebildet sein. Alternativ können die Applikationspakete auch über eine Datenleitung oder über einen Mobilfunkkanal der Sendeeinheit SE z.B. durch eine Basisstation eines Mobilfunksystems zugeführt werden.
In der Fragmentierungseinheit FE von 1 wird die Fragmentlänge der Fragmente FAP vorzugsweise im Wesentlichen gleich der Symbollänge oder gleich Vielfachen der Symbollänge des Vorwärtsfehlerschutzes der Vorwärtsfehlerschutzeinheit FSE eingestellt. Für den Vorwärtsfehlerschutz wird zweckmäßigerweise mindestens ein sogenannter „Eraser-Code", insbesondere ein Reed-Solomon Code oder ein Raptor-Code, zur Rekonstruktion von einem oder mehreren Transportpaketen RTP verwendet, die bei ihrer Übertragung über den fehlerhaften Transportkanal PTK verloren gehen können. Vorzugsweise können die Längen der Fragmente FAP durch die Fragmentierungseinheit FE adaptiv auf das jeweilig gewählte, d.h. jeweilig vorgegebene Transportpaketformat angepasst werden. Dabei wird von der Länge des jeweilig modifizierten Transportpakets MTP oder Paritätspakets PTP dessen Verlustwahrscheinlichkeit auf dem Transportkanal PDK beeinflusst. Der Transportkanal PTK kann beispielsweise durch einen Übertragungskanal auf mindestens einer Luftschnittstelle eines paketbasierten Mobilfunksystems, insbesondere eines UMTS (universal mobil telecommunications system), GPRS (general paket radio service), EGPRS (enhanced GPRS)-Mobilfunksystem, gebildet sein. Insbesondere kann als Transportkanal PTK ein MBMS (multimedia broadcast/multicast service)-Bearer vorgesehen sein. In diesem Anwendungsfall, dass das Transportsystem durch ein paketbasiertes Mobilfunksystem gebildet ist, wird zweckmäßigerweise die Länge der Fragmente FAP durch die Fragmentierungseinheit FE adaptiv an die jeweilig vorgegebene Radioblockgröße auf der Luftschnittstelle des jeweiligen Mobilfunksystem angepasst. Die über die Luftschnittstelle des jeweiligen Mobilfunksystems übertragenen Radioblöcke weisen dabei im Wesentlichen dieselbe konstante Blocklänge auf dem physikalischen Transportkanal auf. Vorzugsweise wird als Nachrichten-/Datenpaket-Transportsystem ein sogenanntes UTRAN (UMTS terrestrial radio access network)- oder ein GERAN (GSM radio access network)-Funknetzwerk verwendet.
Der Transportkanal PTK kann selbstverständlich auch durch Übertragungskanäle andersartiger Nachrichten-/Datentransportsysteme wie zum Beispiel durch den Übertragungskanal einer Internet-Festnetzverbindung gebildet sein.
Als Media-Encoder MEN wird vorzugsweise ein Video-encoder, insbesondere nach dem Standart H.264/AVC gewählt. Als Applikationspakete AP sind sogenannte NALs (network abstraction layer units) nach dem Standart H.264/AVC verwendet. Insbesondere wird als Transportpaketformat RTP nach RFC3550 gewählt. Die NAL-Units werden dabei auf RTP-Pakete gemäß RFC3984 gemappt bzw. abgebildet. Die Fragmentierung kann dabei vorzugsweise gemäß der Syntax von RFC 2984, Abschnitt 5.8, fragmentations units, durchgeführt werden. Für den Vorwärtsfehlerschutz wird vorzugsweise das Verfahren von TS 26346 V1.5.0, Abschnitt 8, insbesondere von RFC2733 gewählt.
Über den Pakettransportkanal PTK kommen nun bei der Empfängereinheit RE die übertragenen modifizierten Quellentransportpakete und Paritätstransportpakete an, soweit sie nicht durch Übertragungsfehler verloren gegangen sind. Dass Paritätstransportpakete aufgrund von Übertragungsfehlern auf dem Übertragungskanal PDK verloren gehen können, ist in der 1 dadurch kenntlich gemacht, dass die eingehenden bzw. empfangenen Paritätstransportpakete auf der Empfängerseite mit PTP* bezeichnet sind. Die empfangenen modifizierten Quellentransportpakete sind bei der Empfängereinheit RE mit NTP* bezeichnet, um zu verdeutlichen, dass ein oder mehrere der ursprünglich von der Sendereinheit SE abgesendeten modifizierten Quellentransportpakete auf ihrem Übertragungsweg über den Transportkanal PDK verloren gegangen sein können. Die empfangenen modifizierten Quellentransportpakete MTP* werden in Umkehrung der Funktion der Enkapsulierungseinheit KTP auf der Senderseite in der Empfängereinheit RE durch eine Dekapsulierungseinheit DKTP dekapsuliert, d.h. von zusätzlichen Informationsfeldern bzw. Headerfeldern befreit. In entsprechender Weise werden die empfangenen Paritätstransportpakete PTP* in Umkehrung der Operation zur Paketierungseinheit KPP auf der Sendeseite in der Empfängereinheit RE mittels einer Depaketierungseinheit DKPP ausgepackt und einer Rekonstruktionseinheit bzw. Decodereinheit FDEC zugeführt. Insbesondere werden aus den Paritätstransportpaketen PTP* mittels der Depaketierungseinheit DKPP die dort enthaltenden Paritätsbits für den Vorwärtsfehlerschutz ausgepackt und der Decodereinheit FDEC zur Rekonstruktion fehlender Applikationspaket- Fragmente FAP zugeführt, die bei der Übertragung der sie verpackenden Quellentransportpaketen MTP über den Transportkanal PTK verloren gegangen sind. Weiterhin werden an die Decodereinheit FDEC von der Dekapsulierungseinheit DKTP empfangene originale Transportpakete OTP übergeben. Aus dem empfangenen, entkapselten Paritätssymbolen und den empfangenen originalen Transportpaketen versucht die Decodereinheit FDEC, fehlende Transportpakete mit Hilfe ihres Vorwärtsfehlerschutzes zu rekonstruieren. Die rekonstruierten originalen Transportpakete RTP werden dann von ihren Headerfeldern oder zusätzlichen Informationselementen in einer nachgeordneten Dekapsulierungseinheit DTP entkapselt bzw, entpackt und daraus die rekonstruierten Fragmente RFAP geliefert. Die derart zurückgewonnenen Fragmente RFAP werden mit Hilfe eines Zusammensetzers DFE defragmentiert, d.h. wieder zu vollständigen Applikationspaketen RAP zusammengesetzt. Dabei entspricht die Defragmentierung des Zusammensetzers DFE der inversen Operation der Fragmentierungseinheit FE auf der Sendeseite. Die so gewonnenen Applikationspakete RAP werden schließlich einem Media-Decoder MDE in der Empfängereinheit RE zugeführt. Alternativ kann der Media-Decoder zeitlich von diesem Empfangsablauf der Empfängereinheit RE und/oder räumlich von diesem getrennt sein. Es ist also nicht erforderlich, dass der Media-Decoder Bestandteil der Empfängereinheit ist.
2 zeigt in schematischer Darstellung ein weiteres Transportsystem TS* mit einer Sendeeinheit SE* und einer Empfängereinheit RE*. Deren Aufbau und Funktion entspricht im Wesentlichen der Komponenten von 1. Im Unterschied zu 1 ist jetzt allerdings die Fragmentierungseinheit FE in der Sendeeinheit SE* erst nach der Paketierungseinheit GTP zur Generierung der Transportpakete angeordnet. Mit anderen Worten ausgedrückt heißt das, dass die Fragmentierungseinheit FE bei der Sendeeinheit SE* zwischen der Paketierungseinheit GTP und der Vorwärtsfehlerschutzeinheit FSE zwischengeschaltet bzw, angeordnet ist. Dadurch werden jetzt zunächst die Applikationspakete AP variabler Paketlänge durch die Paketierungseinheit GTP in originale Transportpakete OTP vorgegebenen Transportsformats umgepackt und dann erst diese Transportpakete mittels der Fragmentierungseinheit FE fragmentiert. Die Fragmentierungseinheit FE erzeugt also fragmentierte Transportpakete FTP, die der Vorwärtsfehlerschutzeinheit FSE zugeführt werden. Parallel dazu werden aus den fragmentierten Transportpaketen FTP durch eine Enkapsulierungseinheit MTP entsprechend der der Sendeeinheit SE von 1 modifizierte Quellentransportpakete gewonnen und sequentiell auf Radioblöcke RB fester Länge aufgeteilt. Letztere werden über den Transportkanal PTK an die Empfängereinheit RE* geschickt.
Die Empfängereinheit RE* entspricht im Wesentlichen der Empfängereinheit RE von 1. Allerdings ist jetzt die Defragmentierungseinheit DFE unmittelbar der Decodereinheit FDEC nachgeordnet, um aus den rekonstruierten fragmentierten Transportpaketen RFTP, die die Decodereinheit FDEC durch den Vorwärtsfehlerschutz zurückgewonnen hat, zu originalen Transportpaketen zusammenzusetzen. Die Applikationspakete RAP können dann durch Dekapsulierung der zurückgewonnenen originalen Transportpakete RTP in einer nachgeordneten Dekapsulierungseinheit DTP entsprechend der von 1 rekonstruiert werden und dem Media-Decoder MDE zugeführt werden.
Zusammenfassend getrachtet werden bei dem abgewandelten Transportsystem TS* von 2 auf der Senderseite Transportpakete vor der Beaufschlagung mit dem Vorwärtsfehlerschutz fragmentiert und in entsprechender Weise werden auf der Empfängerseite rekonstruierte fragmentierte Transportpakete defragmentiert. Im Unterschied dazu werden beim Transportsystem TS von 1 auf der Senderseite Applikationspakete fragmentiert, bevor die Transportpakete erzeugt werden und bevor der Vorwärtsfehlerschutz angewandt wird. In entsprechender Weise werden auf der Empfängerseite des Transportsystem TS von 1 rekonstruierte Transportpakete in rekonstruierte Fragmente mit Hilfe einer Dekapsulierungseinheit zerlegt und aus diesen Transportpaket-Fragmenten die Applikationspakete zusammengesetzt.
Allgemein betrachtet werden vom Transportsystem von 1 folgende Codierungsschritte zweckmäßigerweise durchgeführt:

• Der Media-Encoder MEN erzeugt eine Sequenz von Applikations-Paketen AP, wobei die Pakete im allgemeinen unterschiedlicher Länge sind.
• Die Applikationspakete AP werden in ein Transportformat gepackt, indem ein Header zu den Applikationspaketen hinzugefügt wird. Es entstehen Transportpakete OTP.
• Die originalen Transportpakete OTP werden nun durch zusätzliche Paritätspakete PTP geschützt.
• Dazu werden eventuell die originalen Transportpakete OTP leicht modifiziert ohne deren „Payload", d.h. Informationsinhalt, zu ändern. Eventuell können sie durch Abänderung ihres Headerfelds modifiziert und/oder an sie ein Header hinzugefügt werden.
• Auf eine Gruppe von originalen Transportpaketen OTP, wobei eine Gruppe auch nur ein einzelnes Paket repräsentieren kann, wird nun paketbasierter Fehlerschutz angewendet, indem für diese Gruppe von Paketen ein oder mehrere Paritätspakete PTP erzeugt werden.
• Beide, die eventuell modifizierten originalen Transportpakete MTP und die Paritätspakete PTP werden nun über einen Transportkanal PTK übertragen, auf dem Pakete entweder korrekt ausgeliefert werden oder komplett verloren gehen können. Im speziellen könnte es dich dabei vorzugsweise um das Internet oder um einen paketbasierten Modus in einem Mobilfunksystem handeln.
• Auf Empfängerseite werden die korrekt empfangen Pakete von beiden Typen, Paritätspakete PTP* und Quellenpakete MTP* aufgenommen und depaketiert, d.h. ausgepackt, damit sie entsprechend im nachfolgenden Vorwärtsfehlerschutz der Rekonstruktionseinheit FDEC der Empfängereinheit RE eingeordnet werden können.
• Sollten Quellenpakete innerhalb einer Gruppe verloren sein, können mittels Decodierung unter Verwendung der Paritätspakete mit Hilfe des Vorwärtsfehlerschutzes die originalen Transport-Pakete eventuell wieder rekonstruiert werden.
• Nach der Dekapsulierung der Transportpakete RTP werden aus den rekonstruierten Transportpaketen RTP komplette Applikationspakete AP ursprünglicher Länge entnommen, die dann zum Media- Decoder MDE weitergegeben werden.

Für diese Abfolge von Codierungsschritten auf der Senderseite und Decodierschritten auf der Empfängerseite ist dann zur Verbesserung des Rekonstruktionverhaltens des Transportsystems insbesondere folgendes zweckmäßig:

a) Fragmentierung von Applikationspaketen gemäß dem Transportsystem TS von 1:
• In diesem Fall werden bereits bestehenden Applikationspakete AP in kleinere Fragmente FAP fragmentiert.
• Die fragmentierten Applikationspakete FAP werden nun in ein Transportformat gepackt, indem ein Header zu den Fragmenten hinzugefügt wird.
• Dann werden diese Transportpakete OTP, die Fragmente beinhalten, in gleicher Weise behandelt wie Transportpakete, die komplette Applikationspakete beinhalten.
• Auf Empfängerseite werden nun wieder nach der Decodierung die Transportpakete RTP mittels der Rekonstruiereinheit RTP rekonstruiert.
• Diese Transportpakete RTP werden anschließend dekapsuliert, so dass sich rekonstruierte Fragmente RFAP ergeben.
• Die Fragmente RFAP eines Applikationspaketes werden zusammengefügt, so dass sich ein vollständiges Applikationspaket ergibt, das an den Medien-decoder MDE weitergegeben wird.
b) Fragmentierung von Transportpaketen gemäß dem Transportsystem von 2:
• In diesem Fall werden bereits bestehende originale Transportpakete OTP fragmentiert.
• Die fragmentierten Transportpaket FTP werden dann entsprechend behandelt wie originale Transportpakete, indem sie eventuell modifiziert werden und Vorwärtsfehlerschutz angewendet wird.
• Auf Empfängerseite werden nun wieder nach der Decodierung die fragmentierten Transportpakete RFTP rekonstruiert.
• Die fragmentierten Transportpakete werden defragmentiert, so dass sich wieder originale Transportpakete RTP ergeben.
• Die originalen Transportpakete werden dann dekapsuliert und die resultierenden Applikationspakete RAP werden an den Medien- Decoder MDE weitergegeben.

Für beide Varianten sind insbesondere nun folgende Aspekte vorteilhaft:

• Die Fragmentierung wird auf der Basis existierender Applikationspakete nach dem Media-Encoder durchgeführt. Eine Paketgrößenanpassung im Media-Encoder selbst ist somit nicht erforderlich.
• Bei der Fragmentierung wird die Zerlegung von großen Paketen in kleinere Pakete durchgeführt. Eine Aggregation von vielen kleinen Applikationspaketen in ein aggregiertes Applikationspaket wird somit vermieden.
• Die Fragmentierung passiert, bevor die Pakete in die paketbasierte Vorwärtsfehlerschutzeinheit geschrieben werden, oder besser gesagt bevor der paketbasierte Vorwärtsfehlerschutz angewendet wird.
• Die nur leicht modifizierten Quellenpakete werden nach ihrer Übertragung über den Transportkanal aufgrund der Enkapsulierungen, Verpackungen sowie dem Vorwärtsfehlerschutz entweder korrekt empfangen oder komplett ausgelöscht.

Insbesondere sind folgende vorteilhafte Weiterbildungen zweckmäßig:
Als Medien-encoder kann gewählt sein:

• Ein Video-encoder
• Noch spezieller ein Video-encoder nach H.264/AVC; in diesem Fall sind die Applikationspakete als sogenannte „NAL units" bezeichnet.

• RTP
• In Bezug auf H.264/AVC ist das entsprechende Verfahren gemäß RFC 3984 vorteilhaft verwendet.

• dass die Fragmentierung adaptiv auf den Übertragungskanal, z.B. die Radioblockgröße des Mobilfunksystems angepasst wird.

• in Bezug auf H.264/AVC nach dem entsprechenden Verfahren, das in RFC3984, Absatz 5.8 beschrieben wird, durchgeführt werden.

• entsprechend der Anordnung des Vorwärtsfehlerschutzes nach dem in TS 26.346 beschriebenen Verfahren durchgeführt werden, wobei dann die Quellenpakete nicht original übertragen werden, sondern entsprechend der Anordung im Sourceblock des Vorwärtsfehlerschutzes in ähnlicher Weise wie die Paritätspakete.

• nach RFC2733
• nach dem in TS 26.346, Abschnitt 8, beschriebenen Verfahren

• durch einen Übertragungskanal eines paketbasierten Mobilfunkssystems,
• durch einen Übertragungskanal eines paketbasierten Mobilfunksystems, bei dem längere Pakete auf kleinere Radioblöcke segmentiert werden,
• durch einen Übertragungskanal, bei dem die Verlustwahrscheinlichkeit von der Länge der Transportpakete abhängt,
• durch einen MBMS-Bearer,
• durch einen Übertragungskanal auf UMTS und GERAN

• Applikationspakete/Transportpakete verworfen werden, sobald nicht alle Fragmente empfangen sind.

Im Folgenden wird ein vorteilhaftes Ausführungsbeispiel in Bezug auf MBMS beschrieben. Die dabei durchgeführten Schritte lassen sich auch auf andere Transportsysteme übertragen.
Es wird angenommen, dass ein Video für die Auslieferung über MBMS mit H.264 codiert wird. Eine Codierung erfolgt so, dass bei der Encodierung nicht speziell Rücksicht auf das zu erwartende Netzwerk genommen wird. Z.B. wird die Codierung so durchgeführt, dass jeder Video-Frame in einer NAL unit enthalten ist, was zu maximaler Codier-Effizienz führt. Das ermöglicht zum Beispiel effizienten Transport im Download-Delivery Modus. Wird dieses Video nun im Streaming-Delivery Modus über irgendein Netzwerk ausgeliefert und mit Vorwärtsfehlerschutz kombiniert, so werden jetzt die NAL units beliebiger Länge zweckmäßigerweise fragmentiert, so dass sie unter Einbeziehung von Headern günstig auf die Segmentierung und Radioblockgröße des unterliegenden Netzwerkes angepasst sind. Zum Beispiel kann so fragmentiert werden, dass jeweils ein Fragment exakt in einen Radioblock in ähnlicher Weise wie die Paketgröße der Redundanzpakete passt. Ferner kann es günstig sein, die Fragmentierung auf die Symbollänge für den Fehlerschutz anzupassen, so dass der Padding-Overhead verkleinert wird. Andere Adaptierungen sind möglich, um die Verlustwahrscheinlichkeit für NAL units zu reduzieren. Jedes Fragment wird dann gemäß der Syntax in RFC3984 in entsprechende RTP Pakete gepackt, die dann leicht modifiziert übertragen werden, sowie entsprechend TS26.346 zur Generierung der Redundanzpakete genutzt werden. Auf der Empfängerseite werden in umgekehrter Reihenfolge die empfangenen RTP-Pakete in den Source Block des Vorwärtsfehlerschutzes eingeordnet, eine Kanaldecodierung durchgeführt, die RTP-Pakete an den Depaketierer ausgeliefert, die Fragmente depaketiert und die Fragmente wieder zu NAL units zusammengeführt. Durch diese Ablaufprozedur kann in vorteilhafter Weise die Verlustwahrscheinlichkeit der NAL units gesenkt werden, weil aufgrund der kürzeren Fragmente die Wahrscheinlichkeit, dass die Fragmente ankommen, größer ist, was die Wahrscheinlichkeit, dass der Vorwärtsfehlerschutz erfolgreich decodieren kann, erhöht. Somit können, falls zumindest einige Fragmente ankommen, alle Fragmente decodiert werden, so dass die komplette, durch die Übertragung verloren gegangene NAL unit wieder rekonstruiert werden kann. Der Verlust einzelner Fragmente führt somit nicht zwingend zum Verlust ganzer NAL units.
Die Vorteile des erfindungsgemäßen Verfahrens sowie deren Weiterbildungen sind in mehrerer Hinsicht gegeben. Zum einen kann die Gesamtperformance des Systems gesteigert werden, da durch die Fragmentierung die Verlustwahrscheinlichkeit im System gesenkt werden kann. Zum zweiten kann auf den Einsatz von Slices verzichtet werden, so dass die Kompressionseffizienz nicht durch den Einsatz dieser Fehlerrobustheitsmethoden eingeschränkt wird. Zum dritten ist die Adaption von nur einem, im allgemeinen effizient kodierten Strom auf jedes mögliche Übertragungsszenario in MBMS adaptierbar. Die Einführung der Methode benötigt keinerlei neue Syntaxelemente im Standard, sondern ist rein durch die Verpflichtung oder Empfehlung innerhalb des Standards zur Verwendung dieser Methode machbar.
In vorteilhafter Weise kann auch z.B. innerhalb des TS26.346 Verfahrens eine Fragmentierung ähnlich der Syntax von RFC 3984 eingeführt werden.
Nachfolgend wird im Detail ein zweckmäßiges Ausführungsbeispiel für eine Übertragung ohne und mit Fragmentierung erläutert. Dabei werden nicht alle Header bzw. Kopffelder im Detail betrachtet, da sonst die Übersichtlichkeit verloren gehen würde. Das Prinzip ist aber identisch. In diesem Beispiel werden Applikationspakete, in diesem Fall NAL units, mittels Fehlerschutz wie in MBMS vorgesehen über einen Mobilfunkkanal übertragen.
Im Folgenden wird beispielhaft die Codierung und Übertragung einer Gruppe von NAL units, Applikations-Pakete von H.264/AVC, TS 26.346 V1.5.0, Abschnitt 8.2.1.5: durchgeführt.
Drei H.264/AVC NAL Units bilden eine Gruppe:

• Die erste NAL unit habe 14 bytes
• Die zweite NAL unit habe 40 bytes
• Die dritte NAL Unit habe 91 bytes

Ausführungsbeispiel 1: Übertragung ohne Fragmentierung
Somit ergeben sich zusammen mit dem RTP Header Größen für die originalen RTP-Pakete:

• Das erste RTP-Paket hat somit 26 bytes,
• Das zweite RTP-Paket hat somit 52 bytes.
• Das dritte RTP-Paket hat somit 103 bytes.

Nun nehmen wir an, dass die Symbolgröße T des Vorwärtsfehlerschutzes T=16 beträgt. Die originale RTP-Paketgröße wird in den „source block" mit Benutzung eines 2 Byte-Feldes, gefolgt vom RTP-Paket, geschrieben. Falls der 2 Bit Längen-Indikator und die Länge L des Paketes nicht exakt der Zeilenlänge entsprechen, wird jedes Byte mit 0 aufgefüllt. Alle originalen RTP-Pakete werden entsprechend hintereinander in den SourceBlock eingeschrieben.
Der Source-Block, der sich nach dem Schreiben der drei beispielhaften RTP-Pakete ergibt, ist im Folgenden dargestellt.
Dabei entspricht jeder Eintrag einem Byte. Die Zeilen entsprechen einem "Source symbol" (Quellensymbol), das als eine Einheit für den Vorwärtsfehlerschutz behandelt wird. Jeder Zeile im Source Block wird eine Adresse zugeordnet, die als Encoding Symbol ID" (ESI, Zeilenadresse) im „Source Block" bezeichnet wird. Hier läuft ESI von 0 bis 20 (siehe linke Spalte). Zusätzlich wird jeder Gruppe von Quellenpaketen eine „Source Block Number" (SBN, Sequenznummer des Source Blocks) zugeordnet.
Zum einen wird nun mit Hilfe der „Encoding Symbol ID" (ESI, Zeilenadresse) im „Source Block" und einer „Source Block Number" (SBN, Sequenznummer des Source Blocks) ein enkapsuliertes Quellen-Paket erzeugt, indem die originalen RTP-Pakete so geändert werden, dass Teile des Headers modifiziert werden, um das Paket als Source RTP-Paket zu identifizieren. Zusätzlich werden nach dem Header zwei Felder eingefügt, die SBN und ESI beinhalten.
Die modifizierten Quellen-RTP-Pakete sehen dann wie folgt aus.
Zum zweiten wird innerhalb jeder Spalte der T=16 „Source Symbols" bzw. Quellensymbole ein Fehlerschutz spaltenweise durchgeführt. Die Code-Parameter im Beispielfall sind so, dass k=13 Informationssymbole auf n=21 Code-Symbole erweitert werden. Die Anzahl der Paritätssymbole beträgt damit n–k=8. Man könnte sich zum Beispiel vorstellen, dass ein verkürzter und punktierter Reed-Solomon Code verwendet wird. Dieser Code erlaubt es, die Informationssymbole wieder herzustellen, wenn nur mindestens k der n Code-Symbole am Empfänger zur Verfügung stehen. Andere Codes, z.B. Raptor Codes, mit etwas schlechteren Effizienzeigenschaften, aber z.B. kleinerer Decodier-Komplexität sind denkbar und werden auch innerhalb der MBMS-Standardisierung angedacht. Aus diesen Paritätssymbolen werden nun Paritätspakete erzeugt in der Art und Weise, dass Paritätssymbole zusammengefasst werden, wobei immer Vielfache der Symbolgröße T zusammengefasst werden, so dass jeweils ein Paritätspaket ein oder mehrere komplette Paritätssymbole beinhaltet. Paritätspakete werden zusätzlich mit einem entsprechenden RTP-Header sowie mehreren Feldern versehen, nämlich der Zeilenadresse (ESI) des ersten Paritätssymbol im RTP-Paket, der Sequenznummer (SBN), sowie der Länge der Informationssymbole k, als „Source Block Length" (SBL) bezeichnet. Auch für Encoding Symbol Größe T und „Encoding Block Length" (EBL) n könnte ein Feld spendiert werden, ist aber nicht unbedingt notwendig. Wir verwenden im Folgenden nur SBL mit einer Länge von 2 byte. Außerdem nehmen wir an, dass zwei Paritätssymbole in einem Paket zusammengefasst werden. Somit ergeben sich vier Paritätspakete, die folgendermaßen aussehen:
Nun werden alle RTP-Pakete dieser Gruppe, also modifizierte Quellen RTP-Pakete und Paritätspakete übertragen. Wir nehmen an, dass kein weiterer Header mehr eingefügt werden muss, so dass die RTP-Pakete sequentiell übertragen werden können. Das ist zwar im Allgemeinen nicht der Fall, wird aber zur vereinfachten Darstellung im Folgenden angenommen. Somit ergibt sich folgende Byte-Übertragungssequenz (mit Radioblockzuordnung):
Wir nehmen im Folgenden an, dass immer genau 40 bytes in einem Radioblock RB(siehe 1,2) übertragen werden können, so dass diese Gruppe 10 Radioblöcke umfasst. Wir gehen davon aus, dass nur Radioblock Nummer 5 bei der Übertragung über den Transportkanal verloren geht.
Nun wird die Rekonstruktion auf Empfängerseite durchgeführt. Aufgrund des Verlustes von Radioblock Nummer 5 kann am Decoder das gesamte RTP-Paket Nr. 3 und Nr.4 nicht rekonstruiert werden. Die restlichen RTP-Pakete, also die ersten beiden Quellen RTP-Pakete sowie die letzten drei Paritätspakete können aber mit der beinhalteten Information entsprechend in den „source block" am Empfänger eingeordnet werden.
Da nun insgesamt 9 Zeilen, also mehr als n–k=8 Zeilen verloren gegangen sind, kann NAL unit 3 nicht mehr rekonstruiert werden
Ergänzung zum Ausführungsbeispiel 1:
Im ersten Fall ohne Fragmentierung werden drei Applikationspakete in einen Sourceblock bzw. Quellencodierblock des Vorwärtsfehlerschutzes geschrieben, wobei für jedes Paket ein Header mitgeschrieben wird. Zusätzlich ist es möglicherweise zweckmäßig, für die Erzeugung des Fehlerschutz Füllbits einzutragen (siehe eingefügte Nullen). Dann wird Fehlerschutz angewendet. Für das Beispiel wurde angenommen, dass in einem Radioübertragungsblock (siehe RB in 1) in etwa vier Zeilen des Sourceblocks Platz haben. Nun geht bei der Übertragung ein Radioblock verloren (was durch ausgestrichene Zeilen angedeutet ist). Aufgrund des Verlustes dieses Radioblocks fallen genau 2 RTP-Pakete aus, was zu einem Verlust von vielen Zeilen im Sourceblock führt (siehe ausgestrichene Zeilen). Die Paritätsinformation reicht nicht aus, um die Zeilen rekonstruieren zu können, zwei der drei NAL units gehen verloren, nur die letzte kann rekonstruiert werden.
Ausführungsbeispiel 2: Übertragung mit Fragmentierung:
Im Folgenden wird jetzt eine vergleichende Übertragung mit Fragmentierung betrachtet. Dabei werden alle NAL units, die bei der Übertragung die Größe zweier Radio-Blöcke überschreiten würde, aufgeteilt und zwar so, dass die gut in die Struktur passen. Wie ohne Fragmentierung erläutert, erfüllen die ersten beiden NAL units diese Bedingung, nicht aber NAL unit 3, es überschreitet eine virtuelle Obergrenze von 50 bytes. Somit wird NAL unit 3 in zwei Fragmente aufgeteilt. Nach RFC3984 ist für die Fragmentierung pro Fragment ein zusätzliches Header-Byte notwendig, da die fragmentierte NAL unit signalisiert werden muss. Für das zweite Fragment und jede weitere sind somit 2 Byte Overhead notwendig. Nach der Fragmentierung haben wir somit folgende Applikationspakete:

• Die erste NAL unit habe 14 Bytes
• Die zweite NAL unit habe 40 Bytes
• Das erste Fragment der dritten NAL Unit habe 49 Bytes
• Das zweite Fragment der dritten NAL Unit habe 45 Bytes

Somit ergeben sich zusammen mit dem RTP Header Größen für die originalen RTP-Pakete als

• Das erste RTP-Paket hat somit 26 Bytes,
• Das zweite RTP-Paket hat somit 52 Bytes.
• Das dritte RTP-Paket hat somit 62 Bytes.
• Das vierte RTP-Paket hat somit 56 Bytes.

Wiederum nehmen wir an, dass die Symbolgröße T=16 beträgt. Die originale RTP-Paketgröße wird nun in den „source block" bzw. Quellenblock des Vorwärtsfehlerschutzes geschrieben durch die Benutzung eines 2-Byte Feldes, gefolgt vom RTP-Paket. Falls der 2 Byte Längen-Indikator und die Länge L des Paketes nicht exakt der Zeilenlänge entsprechen, wird jedes Byte mit 0 aufgefüllt. Alle originalen RTP-Pakete werden entsprechend hintereinander in den SourceBlock eingeschrieben.
Der beispielhafte Source-Block, der sich nach dem Schreiben der nun vier RTP-Pakete ergibt ist im Folgenden dargestellt. Man sieht, dass man durch die Fragmentierung adaptiv auf die Symbollänge anpassen kann, so dass kein Verschnitt für sogenanntes „Stuffing" entsteht.
Auf die Enkapsulierung und die Generierung der Paritysymbole wird im Folgenden nicht weiter eingegangen, da beide Operationen äquivalent zu der vorigen Operation sind. Es wird aber angemerkt, dass die Source Block Length (SBL) k jetzt 14 anstatt 13 ist.
Der Einfachheit halber behalten wir n=21 bei, was zu einer leicht erniedrigten Redundanz im Falle der Fragmentierung führt, da n–k=7 ist. Die Anzahl der Radioblöcke, die für diese Gruppe verwendet wird, erhöht sich dadurch aber nicht und ist identisch. Dieser Verlust wird sich aber für größere RTP-Pakete verringern, wegen der Darstellung verzichten wir aber auf diese Option.
Nun werden wieder alle RTP-Pakete dieser Gruppe, modifizierte Quellen RTP-Pakete und Paritätspakete übertragen. Somit ergibt sich folgende Byte-Übertragungssequenz (mit Radio Block Nummern).
Wir nehmen im Folgenden an, dass wieder genau 40 bytes in einem Radioblock übertragen werden können, so dass diese Gruppe 10 Radioblöcke umfasst. Wiederum gehen wir davon aus, dass nur Radioblock Nummer 5 verloren geht.
Nun wird die Rekonstruktion auf Empfängerseite durchgeführt. Aufgrund des Verlustes von Radioblock Nummer 5 kann am Decoder das gesamte RTP-Paket Nr. 4 nicht rekonstruiert werden. Jedoch mit Hilfe der Paritätspakete kann nun der gesamte Source Block inclusive RTP-Paket 4 rekonstruiert werden, so dass alle RTP-Pakete rekonstruiert sind. Somit sind alle Fragmente rekonstruiert und die NAL units können alle fehlerfrei ausgeliefert werden.
Dieses Beispiel zeigt auch, dass die Flexibilität der Fragmentierung eine Vielzahl von Kombinationen erlaubt, die an die Symbollänge als auch an die Radioblockgröße angepasst werden können. Insbesondere erlaubt die Kombination von Fragmentierung, Umpaketierung und Vorwärtsfehlerschutz eine verbesserte Rekonstruierbarkeit der Applikationspakete. In der Praxis können natürlich die Anzahl der kombinierten Pakete und die Sourceblöcke größer gegenüber dem Beispiel sein.
Ergänzung zum Ausführungsbeispiel 2:
Im zweiten Fall mit Fragmentierung werden dieselben Pakete über denselben Kanal übertragen. Jedoch wird vor der Übertragung eine Anpassung der Fragmente der Applikationspakete nach dem erfindungsgemäßen Verfahren auf die Übertragungsgröße der Radioblöcke durchgeführt. Somit ergeben sich anstatt drei Pakete 6 Fragmente. Diese Fragmente werden in gleicher Art und Weise behandelt wie vorher, also einschreiben in den Sourceblock und Codierung. Ein Fehler passiert an derselben Stelle, jedoch gehen aufgrund der fragmentierten Pakete weniger Daten verloren die nun durch den Vorwärtsfehlerschutz korrigiert werden können. Da alle Fragmente rekonstruiert werden können, können somit auch alle NAL units rekonstruiert werden.

Claims

Verfahren zum Versenden von Applikationspaketen (AP) variabler Paketlänge, die von einem Media-Encoder (MEN) ausgegeben werden, in Transportpaketen (MTP) vorgegebenen Transportpaketformats über einen Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS), wobei durch einen paketbasierten Vorwärtsfehlerschutz einer nachgeordneten Vorwärtsfehlerschutzeinheit (FSE) für Gruppen von ein oder mehreren Transportpaketen (OTP) Paritätssymbole erzeugt werden, die in Paritätspakete (PTP) mit demselben vorgegebenen Transportpaketformat wie die Transportpakete (MTP) der Applikationspakete (AP) eingepackt werden, und wobei die Transportpakete (MTP) der Applikationspakete (AP) und die Paritätspakete (PTP) über einen fehlerhaften Transportkanal (PTK) übertragen werden, wodurch die Transportpakete (MTP) und die Paritätspakete (PTP) des vorgegebenen Transportpaketformats bei einer Empfängereinheit (RE) des Nachrichten-/Datenpaket-Transportsystems (TS) entweder komplett und fehlerfrei ankommen, oder komplett verloren gehen, dadurch gekennzeichnet, dass das jeweilige Applikationspaket (AP) vor der Vorwärtsfehlerschutzeinheit (FSE) zusätzlich mit Hilfe einer Fragmentierungseinheit (FE) in mehrere Fragmente (FAP) zerlegt wird, die jeweils eine kleinere Länge als das ursprüngliche Applikationspaket (AP) aufweisen, wenn die Länge des Applikationspakets (AP) eine vorgegebene Obergrenze überschreitet, und wobei diese resultierenden Fragmente (FAP) der Applikationspakete (AP) vor der Vorwärtsfehlerschutzeinheit (FSE) in die Transportpakete (OTP) mit dem vorgegebenen Transportpaketformat eingepackt werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Transportpakete (OTP) unverändert oder nur mit einem zusätzlichen Header fester Länge als modifizierte Transportpakete (MTP) übertragen werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der Fragmentierungseinheit (FE) die Fragmentlänge der Fragmente (FAP) im Wesentlichen gleich der Symbollänge oder gleich Vielfachen der Symbollänge des Vorwärtsfehlerschutzes der Vorwärtsfehlerschutzeinheit (FSE) eingestellt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für den Vorwärtsfehlerschutz mindestens ein „eraser code", insbesondere ein Reed-Solomon Code oder ein Raptor-Code, zur Rekonstruktion von einem oder mehreren Transportpaketen (RTP) verwendet wird, die bei ihrer Übertragung über den Transportkanal (PTK) verloren gehen können.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Länge der Fragmente (FAP) durch die Fragmentierungseinheit (FE) adaptiv an das jeweilig vorgegebene Transportpaketformat angepasst wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von der Länge des jeweiligen Transportpakets (MTP) oder Paritätspakets (PTP) dessen Verlustwahrscheinlichkeit beeinflusst wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Transportkanal (PTK) ein Übertragungskanal, insbesondere ein MBMS(Multimedia Broadcast/Multicast Service)-Bearer, auf mindestens einer Luftschnittstelle eines paketbasierten Mobilfunksystems, insbesondere eines UMTS (universal mobile telecommunications system)-, GPRS (general packet radio service), EGPRS (Enhanced GPRS)-Mobilfunksystems, gewählt wird.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass die Länge der Fragmente (FAP) durch die Fragmentierungseinheit (FE) adaptiv an die jeweilig vorgegebene Radioblockgröße auf der Luftschnittstelle des jeweiligen Mobilfunksystems angepasst wird.
Verfahren nach einem der Ansprüche 7 oder 8, dadurch gekennzeichnet, dass als Nachrichten-/Datenpaket-Transportsystem ein UTRAN (UMTS terrestrial radio access network)- oder ein GERAN (GSM radio access network)- Funknetzwerk verwendet wird.
Verfahren nach einem der Ansprüche 1 mit 6, dadurch gekennzeichnet, dass als Transportkanal (PTK) ein Übertragungskanal auf mindestens einer Internet-Festnetzverbindung gewählt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Applikationspakete (AP) zeitlich und/oder örtlich getrennt von ihrer Fragmentierung und Übertragung vom Media-Encoder (MEN) erzeugt und in einer Speichereinheit zwischengespeichert werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von der Empfängereinheit (RE) das jeweilige Applikationspaket (AP) verworfen wird, sobald mindestens eines seiner Fragmente (FAP) durch Verlust eines zugeordneten Transportpakets (MTP) fehlt und nicht durch den Vorwärtsfehlerschutz rekonstruiert werden kann.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass in der Empfangseinheit (RE) das jeweilig verworfene Applikationspaket (AP) unter Verwendung der über den Transportkanal (PTK) übermittelten Paritätspakete (PTP*) und Transportpakete (MTP*) mittels einer Decodereinheit (FDEC) mit Vorwärtsfehlerschutz rekonstruiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Media-Encoder (MEN) ein Video-Encoder, insbesondere nach Standard H.264/AVC gewählt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Applikationspakete (AP) NAL(network abstraction layer)-units (Einheiten) nach Standard H.264/AVC verwendet werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Transportpaketformat RTP nach RFC3550 verwendet wird.
Verfahren nach Anspruch 15 und 16, dadurch gekennzeichnet, dass die NAL units auf RTP-Pakete gemäß RFC3984 gemappt werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Fragmentierung gemäß der Syntax von RFC2984, Abschnitt 5.8, Fragmentation Units, durchgeführt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Vorwärtsfehlerschutz gemäß dem Verfahren von TS 26346 V1.5.0, Abschnitt 8, insbesondere in RFC2733, durchgeführt wird.
Verfahren zur Rekonstruktion von Applikationspaketen (AP) variabler Paketlänge aus empfangenen Transportpaketen (MTP*) sowie empfangenen Paritätspaketen (PTP*) vorgegebenen Transportpaketformats mittels einer Rekonstruktionseinheit (FDEC), die über einen fehlerhaften Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS) von einer Sendereinheit (SE) geschickt worden sind, wobei die Paritätspakete durch einen paketbasierten Vorwärtsfehlerschutz für Gruppen von ein oder mehreren Transportpaketen (OTP) von der Sendereinheit (SE) erzeugt worden sind, insbesondere nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach der Rekonstruktion der originalen Transportpakete (RTP) mittels der Rekonstruktionseinheit (FDEC) aus diesen rekonstruierten Transportpaketen (RTP) Fragmente (RFAP) der Applikationspakete (RAP) mittels einer Dekapsulierungseinheit (DTP) ausgepackt werden, und dass diese zurückgewonnenen Fragmente (RFAP) mittels einer Defragmentierungseinheit (DFE) wieder zu den Applikationspaketen (RAP) zusammengesetzt werden, die dann einem Media-Decoder (MDE) zugeführt werden.
Verfahren zum Versenden von Applikationspaketen (AP) variabler Paketlänge, die von einem Media-Encoder (MEN) ausgegeben werden, in Transportpaketen (MTP) vorgegebenen Transportpaketformats über einen Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS), wobei durch einen paketbasierten Vorwärtsfehlerschutz einer nachgeordneten Vorwärtsfehlerschutzeinheit (FSE) für Gruppen von ein oder mehreren Transportpaketen (OTP) Paritätssymbole erzeugt werden, die in Paritätspakete (PTP) mit demselben vorgegebenen Transportpaketformat wie die Transportpakete (MTP) der Applikationspakete (AP) eingepackt werden, und wobei die Transportpakete (MTP) der Applikationspakete (AP) und die Paritätspakete (PTP) über einen fehlerhaften Transportkanal (PTK) übertragen werden, wodurch die Transportpakete (MTP) und die Paritätspakete (PTP) des vorgegebenen Transportpaketformats bei einer Empfängereinheit (RE) des Nachrichten-/Datenpaket-Transportsystems (TS) entweder komplett und fehlerfrei ankommen, oder komplett verloren gehen, insbesondere nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Applikationspakete (AP) vor der Vorwärtsfehlerschutzeinheit (FSE) in die Transportpakete (OTP) mit dem vorgegebenen Transportpaketformat eingepackt werden, und dass das jeweilige Transportpaket (AP) vor der Vorwärtsfehlerschutzeinheit (FSE) zusätzlich mit Hilfe einer Fragmentierungseinheit (FE) in mehrere Fragmente (FTP) zerlegt wird, die jeweils eine kleinere Länge als das ursprüngliche Transportpaket (AP) aufweisen, wenn die Länge des Transportpakets (AP) eine vorgegebene Obergrenze überschreitet.
Verfahren zur Rekonstruktion von Applikationspaketen (AP) variabler Paketlänge aus empfangenen Transportpaketen (MTP*) sowie empfangenen Paritätspaketen (PTP*) vorgegebenen Transportpaketformats mittels einer Rekonstruktionseinheit (FDEC), die über einen fehlerhaften Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS*) von einer Sendereinheit (SE) geschickt worden sind, wobei die Paritätspakete durch einen paketbasierten Vorwärtsfehlerschutz für Gruppen von ein oder mehreren Transportpaketen (OTP) von der Sendereinheit (SE) erzeugt worden sind, insbesondere nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach der Rekonstruktion fragmentierter Transportpakete (RFTP) mittels der Rekonstruktionseinheit (FDEC) aus diesen rekonstruierten fragmentierten Transportpaketen (RFTP) originale Transportpakete (RTP) mittels einer Defragmentierungseinheit (DFE) zusammengesetzt werden, und dass aus diesen zurückgewonnenen Transportpaketen (RTP) mittels einer Dekapsulierungseinheit (DTP) die zurückgewonnenen Applikationspakete (RAP) ausgepackt werden, die dann einem Media-Decoder (MDE) zugeführt werden.
Sendereinheit (SE) mit einem Media-Encoder (MEN) zum Ausgeben von Applikationspaketen (AP) variabler Paketlänge, mit einer Paketierungseinheit (GTP) zum Umverpacken der Applikationspakete (AP) in Transportpakete (OTP) vorgegebenen Transportpaketformats, mit einer paketbasierten Vorwärtsfehlerschutzeinheit (FSE) zur Erzeugung von Paritätssymbolen für Gruppen von ein oder mehreren Transportpaketen (OTP) und Umverpacken dieser Paritätssymbole in Paritätspakete (PTP), die dasselbe vorgegebene Transportpaketformat wie die Transportpakete (MTP) der Applikationspakete (AP) aufweisen, und mit einer Ausgabeeinheit (KTP, KPP) zur Übertragung der Transportpakete und Paritätspakete (PTT) über einen Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS), insbesondere nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zwischen dem Media-Encoder (MEN) und der Vorwärtsfehlerschutzeinheit (FSE) zusätzlich eine Fragmentierungseinheit (FE) zum Zerlegen des jeweiligen Applikationspakets (AP) vor der Vorwärtsfehlerschutzeinheit (FSE) in mehrere Fragmente (FAP) vorgesehen ist, die jeweils eine kleinere Länge als das ursprüngliche Applikationspaket (AP) aufweisen, wenn die Länge des Applikationspakets (AP) eine vorgegebene Obergrenze überschreitet, und dass der Ausgang der Fragmentierungseinheit (FE) auf den Eingang der Paketierungseinheit (GTP) zum Einpacken dieser resultierenden Fragmente (FAP) der Applikationspakete (AP) vor der Vorwärtsfehlerschutzeinheit (FSE) in die Transportpakete (OTP) mit dem vorgegebenen Transportpaketformat gelegt ist.
Sendereinheit (SE*) mit einem Media-Encoder (MEN) zum Ausgeben von Applikationspaketen (AP) variabler Paketlänge, mit einer Paketierungseinheit (GTP) zum Umverpacken der Applikationspakete (AP) in Transportpakete (OTP) vorgegebenen Transportpaketformats, mit einer paketbasierten Vorwärtsfehlerschutzeinheit (FSE) zur Erzeugung von Paritätssymbolen für Gruppen von ein oder mehreren Transportpaketen (OTP) und Umverpacken dieser Paritätssymbole in Paritätspakete (PTP), die dasselbe vorgegebene Transportpaketformat wie die Transportpakete (MTP) der Applikationspakete (AP) aufweisen, und mit einer Ausgabeeinheit (MTP, KPP) zur Übertragung der Transportpakete und Paritätspakete (PTT) über einen Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS*), insbesondere nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zwischen der Paketierungseinheit (GTP) und der Vorwärtsfehlerschutzeinheit (FSE) zusätzlich eine Fragmentierungseinheit (FE) zum Zerlegen des jeweiligen Transportpakets (OTP) vor der Vorwärtsfehlerschutzeinheit (FSE) in mehrere Fragmente (FTP) vorgesehen ist, die jeweils eine kleinere Länge als das ursprüngliche Transportpaket (OTP) aufweisen, wenn die Länge des Transportpakets (OTP) eine vorgegebene Obergrenze überschreitet.
Empfängereinheit (RE) mit einer Rekonstruktionseinheit (FDEC) zur Rekonstruktion von Applikationspaketen (AP) variabler Paketlänge aus empfangenen Transportpaketen (MTP*) sowie empfangenen Paritätspaketen (PTP*) vorgegebenen Transportpaketformats, die über einen fehlerhaften Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS) von einer Sendereinheit (SE) geschickt worden sind, wobei die Paritätspakete durch einen paketbasierten Vorwärtsfehlerschutz für Gruppen von ein oder mehreren Transportpaketen (OTP) von der Sendereinheit (SE) erzeugt worden sind, insbesondere nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zwischen der Rekonstruktionseinheit (FDEC) und einem nachgeordneten Media-Decoder (MDE) eine Defragmentierungseinheit (DFE) zum Zusammensetzen von mittels der Rekonstruktionseinheit (FDEC) rekonstruierten Applikationspaket-Fragmenten (RFAP) in vollständige Applikationspakete (RAP) vorgesehen ist.
Empfängereinheit (RE*) mit einer Rekonstruktionseinheit (FDEC) zur Rekonstruktion von Applikationspaketen (AP) variabler Paketlänge aus empfangenen Transportpaketen (MTP*) sowie empfangenen Paritätspaketen (PTP*) vorgegebenen Transportpaketformats, die über einen fehlerhaften Transportkanal (PTK) eines Nachrichten-/Datenpaket-Transportsystems (TS*) von einer Sendereinheit (SE*) geschickt worden sind, wobei die Paritätspakete durch einen paketbasierten Vorwärtsfehlerschutz für Gruppen von ein oder mehreren fragmentierten Transportpaketen (OTP) von der Sendereinheit (SE*) erzeugt worden sind, insbesondere nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zwischen der Rekonstruktionseinheit (FDEC) und einem nachgeordneten Media-Decoder (MDE) eine Defragmentierungseinheit (DFE) zum Zusammensetzen von mittels der Rekonstruktionseinheit (FDEC) rekonstruierten Fragmenten (RFTP) von Transportpaketen in vollständige Transportpakete (RTP) vorgesehen ist, und dass der Defragmentierungseinheit (DFE) eine Dekapsulierungseinheit (DTP) zum Auspacken der Applikationspakete (RAP) aus den rekonstruierten Transportpaketen (RTP) nachgeordnet ist.