DE60308195T2

DE60308195T2 - Optimierte Übertragung von Textbeispiel-Formatbeschreibungen für "streaming timed text"

Info

Publication number: DE60308195T2
Application number: DE60308195T
Authority: DE
Inventors: Jose Luis Rey; Rolf Hakenberg
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp
Priority date: 2003-11-06
Filing date: 2003-11-06
Publication date: 2006-12-28
Anticipated expiration: 2023-11-07
Also published as: JP2007520914A; ATE339055T1; US20070123236A1; ES2271455T3; EP1530337B1; EP1530337A1; US8027669B2; CN1902884A; WO2005046159A1; DE60308195D1

Description

Sachgebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Senden von formatiertem Text von einem Streaming-Server zu einem mobilen Client unter Verwendung eines RTP-Protokolls in einem Mobilkommunikationssystem. Der formatierte Text kann mindestens ein Textmuster aufweisen, das eine zugeordnete Textmuster-Formatbeschreibung besitzt. Weiterhin bezieht sich die vorliegende Erfindung auf den Streaming-Server, der den formatierten Text sendet, wobei der mobile Client einen zu einem Datenstrom geformten, formatierten Text empfängt, und auf ein System, das den Streaming-Server und den mobilen Client aufweist.
Hintergrund
Das 3GPP (3^rd Generation Partnership Project) wendet IETF (Internet Engineering Task Force) standardisierte Protokolle, ähnlich RTP, UDP, IP für den Transport und paket-geschaltete Codecs ähnlich AMR (Adaptive Multi-Rate) und H.264 (MPEG 4 part 10) für codierende Medien, an. Die 3GPP Packet Switched Streaming Services (siehe "Universal Mobile Telecommunications System (UMTS); Transparent end-to-end streaming service; Protocols and codecs", 3GPP TS 26.234 Version 5.6.0 Release 5, September 2003, erhältlich unter http://www:3gpp.org) verwenden den RTP/UDP-Protokoll-Stapel, um Audio/Video-Text-Medien zu einer Datenfolge zu formen.
RTP ist ein Real-Time Transport Protocol (siehe Schulzrinne et al., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, Juli 2003, alle RFCs erhältlich unter http://www.ietf.org), das hauptsächlich für eine Realzeit oder nahezu Realzeit-Kommunikation verwendet wird, d.h. einer Kommunikation mit freizügigen Verzögerungs-Beschränkungen. Es liefert Informationen über die Zeitabstimmung des Mediums, das es führt, und ermöglicht auch eine Umordnung und eine Neuzusammenstellung an dem Empfänger.
Ein integrierter Teil des Protokolls ist RTCP (Real Time Control Protocol), das minimale Empfangs-Informationen und eine lockere Gruppen-Mitgliedschaft bereitstellt. RTP wird allgemein zusammen mit dem RTP/AVP-Profil (siehe Schulzrinne et al., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, Juli 2003) verwendet, das die Verwendung der RTP-Header-Felder und Auflistungs-Tabellen für Payload-Typen, neben einfachen RTCP-Rückführ-Zeitabstimmungsregeln, definiert.
UDP (Postel, "User Datagram Protocol", RFC 768, August 1980) ist das User Datagram Protocol, das dazu verwendet wird, RTP-Pakete zu transportieren. UDP wird herkömmlich dann verwendet, wenn eine unzuverlässige Kommunikation für das gegebene Medium geeignet ist, wie in dem Fall für Streaming-Anwendungen. Der Protokoll-Stapel RTP/UDP wird verwendet, da die Zeitabstimmungs-Beschränkungen der Medien gewöhnlich keine zuverlässige Kommunikation zulassen, z.B. unter Verwendung von TCP (Transmission Control Protocol).
In RTP werden Paketbildungs-Schemata (Payload-Formate) für existierende Medien-Formate (Codecs) in der Internet Engineering Task Force Audio/Video Transport Working Group (IETF AVT WG) spezifiziert. Dabei ist zum Beispiel ein Payload-Format für durch AMR codierte Sprach-Daten, und ein anderes für H.264 Video, vorhanden.
Das Payload-Format, das in Hellstrom, "RTP Payload for Text Conversation", RFC 2793, Mai 2000, definiert ist, kann verwendet werden, um einen Konversationstext zu senden, allerdings lässt das Format nicht ein Führen irgendwelcher zusätzlicher Informationen über die Dekoration der Text-Zeichen zu. Die Dekoration ist zum Beispiel der Zeichensatz, der verwendet wird, die Hintergrundfarbe, die Ablauf- oder Karaoke-Bewegung. Sie ermöglicht keine räumliche Synchronisation mit anderen Medien, wie dies zum Beispiel für eine Unterbetitelung von Video-Folgen benötigt wird. Zusammengefasst bietet der über 3GPP Zeit abgestimmte Text (siehe 3GPP TS 26.234, insbesondere Appendix D.8a) einen viel weiteren Bereich an Funktionalitäten, der nicht durch andere, standardisierte Codecs unterstützt wird.
Rey et al., "RTP Payload Format for 3GPP Timed Text", draft-ray-avt-3gpp-tt-01.txt, IETF AVT WG, September 2003, erhältlich unter http://www.ietf.org, schlägt ein Payload-Format für das Senden eines Zeit abgestimmten Texts unter Verwendung von RTP vor. Allerdings liefert das Payload-Format nur Mittel für ein Senden außerhalb des Bands von Muster-Beschreibungs-Informationen und wendet sich nicht dem Problem eines In-Band-Sendens von Muster-Beschreibungs-Informationen im Detail zu. Das In-Band-Senden einer Muster-Beschreibung, vorgeschlagen von Rey et al., erfordert ein Senden jeder Mus ter-Beschreibung zusammen mit deren zugeordnetem Textmuster, und kann deshalb nicht die Probleme, die nachfolgend angegeben sind, lösen.
Im Rahmen der vorliegenden Erfindung kann "In-Band" in dem Zusammenhang eines signalisierenden Kanals verstanden werden. Allgemein stellen Muster-Beschreibungen reine Signalisierungs-Informationen oder Metadaten dar. Der Text kann als die tatsächlichen Daten angesehen werden. Demzufolge bedeutet "In-Band", dass das Signalisieren, d.h. die Muster-Beschreibungen, in derselben Sitzung wie die Daten gesendet wird, das heißt die Textmuster. Es ist anzumerken, dass die Textmuster nicht SPLDESC, THDR oder FHDR Header umfassen, sondern nur Textfolgen und Modifizierer-Kästen (siehe 3GPP TS 26.234) werden gesendet. Ein Signalisieren außerhalb des Bands kann deshalb als ein Senden der Muster-Beschreibung unter Verwendung einer anderen Sitzung oder eines anderen Protokolls als das eine, das zum Senden der Daten verwendet wird, z.B. SDP, verstanden werden.
Wenn ein 3GPP Timed Text einem Streaming unterworfen wird, ist dies typischerweise der Fall, dass sich die einem Streaming unterworfenen Textmuster auf ein und dieselben Muster-Beschreibungseintritte beziehen. Nach einer gegebenen Zeitdauer sind alle möglichen Muster-Beschreibungen bereits mindestens einmal gesendet worden. Die Textmuster beziehen sich wiederholt auf diese Muster-Beschreibungen und so müssen die Muster-Beschreibungen immer wieder von dem Sender zu dem Empfänger übertragen werden, da dem Sender nicht bekannt ist, welche Datenpakete durch den Empfänger empfangen wurden. Weiterhin erfordern 3GPP TS 26.2.34 und das Verfahren, das in Rey et al., "RTP Payload Format for 3GPP Timed Text" vorgeschlagen ist, beide, dass jedes Textmuster immer zusammen mit dessen zugeordneter Muster-Beschreibung übertragen wird. Demzufolge ist in herkömmlichen Systemen das Sende-Overhead aufgrund eines Sendens aller Muster-Beschreibungen einer 3GPP Datei groß. Weiterhin ist dieses Overhead insbesondere in dem Fall unerwünscht, dass ein Streaming zu einem mobilen Client über eine Funkverbindung, die in ihren Ressourcen knapp ist, bereitgestellt wird.
Zusammenfassung der Erfindung
Demzufolge ist es die Aufgabe der vorliegenden Erfindung, ein Sende-Overhead herkömmlicher Systeme zu verringern, wenn ein einem Streaming unterworfener Text von einem Streaming-Server zu einem mobilen Terminal bzw. Endgerät oder einem Client in einem drahtlosen Kommunikationssystem, wie beispielsweise UMTS, unter Verwendung von RTP, gesendet wird.
Die Aufgabe der vorliegenden Erfindung wird durch den Gegenstand der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen der vorliegenden Erfindung sind Gegenstand der abhängigen Ansprüche.
Gemäß einer ersten Ausführungsform der vorliegenden Erfindung wird ein Verfahren zum Senden von formatiertem Text von einem Streaming-Server zu einem mobilen Client unter Verwendung eines RTP-Protokolls in einem Mobilkommunikationssystem geschaffen. Der formatierte Text kann mindestens ein Textmuster aufweisen, das eine zugeordnete Textmuster-Formatbeschreibung besitzt. Der Streaming-Server kann bestimmen, ob eine Textmuster-Formatbeschreibung für ein Textmuster, das gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist. Falls dies der Fall ist, kann nur das Textmuster, das gesendet werden soll, zu mindestens einem Datenpaket, das gesendet werden soll, hinzugefügt werden. Falls nicht, kann das Textmuster, das gesendet werden soll, und dessen zugeordnete Textmuster-Formatbeschreibung zu zumindest einem Datenpaket, das gesendet werden soll, hinzugefügt werden. Das mindestens eine Datenpaket kann dann zu dem mobilen Client gesendet werden.
Gemäß dieser Ausführungsform kann der Streaming-Server, der einen formatierten Text, z.B. von einer 3GPP Datei, präpariert, die Textmuster-Formatbeschreibungen der unterschiedlichen Textmuster vor einem Senden analysieren. Bei dieser Verarbeitung kann der Streaming-Server bestimmen, welche der Muster-Beschreibungen bereits zu dem Client gesendet worden sind oder welche davon bereits zu (einem) RTP-Paket (Paketen), um zu dem Client gesendet zu werden, hinzugefügt worden sind. In Abhängigkeit von diesem Bestimmungsvorgang kann der Streaming-Server nicht die Textmuster-Formatbeschreibungen in Datenpaketen hinzufügen müssen, in dem Fall, dass dieselben bereits bereitgestellt worden sind. Demzufolge kann das Sende-Overhead verringert werden, da ein (erneutes) Senden von duplizierten Informationen verhindert werden kann.
Weiterhin sollte angemerkt werden, dass es auch möglich ist, dass ein Datenpaket mindestens einen Text nur einer Muster-Formatbeschreibung aufweist. Z.B. können in dem Fall, dass die maximale Größe eines einzelnen Datenpakets bereits durch mindestens eine Textmuster-Formatbeschreibung, die enthalten ist, erreicht ist, keine zusätzlichen Textmuster darin vorhanden sein. Demzufolge können die unterschiedlichen Ausfüh rungsformen der vorliegenden Erfindung, die in den nachfolgenden Absätzen angegeben sind, auch dann anwendbar sein, wenn Datenpakete nur Textmuster-Formatbeschreibungen aufweisen.
Dabei können zwei Möglichkeiten vorhanden sein, in denen der Streaming-Server nicht die Textmuster-Formatbeschreibung eines Textmusters, die gesendet werden soll, senden kann: die Textmuster-Formatbeschreibung, die bereits bereitgestellt ist, ist entweder zu dem mobilen Client in einem früheren Datenpaket gesendet worden, oder die Textmuster-Formatbeschreibung, die bereits bereitgestellt ist, ist bereits zu dem mindestens einem Datenpaket zugeführt worden, als ein früheres Textmuster verarbeitet wurde.
Der Streaming-Server kann, wenn das Textmuster, das gesendet werden soll, zu zumindest einem Datenpaket hinzugefügt wird, weiterhin mindestens einen Musteridentifizierer zu dem mindestens einem Datenpaket hinzufügen. Der Muster-Identifizierer kann eine Auflistung zwischen einer Textmuster-Formatbeschreibung und deren zugeordnetem Textmuster in dem mindestens einen Datenpaket bereitstellen. Demzufolge kann, unter Verwendung eines Identifizierers, jedes Textmuster zu einer Textmuster-Formatbeschreibung korreliert werden.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung kann der Streaming-Server Informationen über Textmuster-Formatbeschreibungen, bereitgestellt für den mobilen Client, in den gesendeten Datenpaketen beibehalten. Die beibehaltenen Informationen können Daten über die bereitgestellten Textmuster-Formatbeschreibungen, Daten über mindestens ein Datenpaket, in dem die Textmuster-Formatbeschreibung gesendet worden ist, und den mindestens einen Identifizierer aufweisen.
Falls bestimmt worden ist, dass eine Textmuster-Formatbeschreibung für ein Textmuster, das gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist, kann es notwendig sein, zu bestimmen, welches der Datenpakete, das zu dem Client gesendet ist, die Textmuster-Formatbeschreibung umfasste. Die Informationen, die in dem Streaming-Server beibehalten werden, können dazu verwendet werden, das mindestens eine, gesendete Datenpaket zu bestimmen, da dasselbe Informationen über die Textmuster-Formatbeschreibungen, die gesendet sind, aufweisen kann, und das Datenpaket (die Datenpakete), in denen dieselben gesendet worden sind oder gesendet werden.
Falls der Streaming-Server bestimmte, dass eine Textmuster-Formatbeschreibung für ein Textmuster, das gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist, d.h. in diesem Fall ist es bereits zu einem Client gesendet worden, kann es erwünscht sein zu prüfen, ob das mindestens eine Datenpaket, das die Textmuster-Formatbeschreibung aufweist, durch den mobilen Client bestätigt worden ist. Falls dies der Fall ist, kann der Muster-Identifizierer, der in dem bestimmten, mindestens einen Datenpaket für die Auflistung des Textmusters, das zu einer bereitgestellten Textmuster-Formatbeschreibung gesendet werden soll, wieder verwendet werden. D.h. der Muster-Identifizierer, verwendet für die bereits gesendete Textmuster-Formatbeschreibung, kann dem Textmuster zugeordnet werden, das gesendet werden soll, und kann in das mindestens eine Datenpaket, in dem das Textmuster, das gesendet werden soll, eingeschlossen werden wird, eingeschlossen werden.
Falls bestimmt worden ist, dass das bestimmte, mindestens eine Datenpaket nicht durch den mobilen Client bestätigt worden ist, kann sowohl das Textmuster, das gesendet werden soll, als auch dessen zugeordnete Textmuster-Formatbeschreibung zu dem mindestens einen Datenpaket hinzugefügt werden, da nicht sichergestellt werden kann, dass der mobile Client erfolgreich die notwendige Textmuster-Formatbeschreibung in dem Datenpaket (den Datenpaketen), die früher gesendet sind, empfangen hat.
Weiterhin kann das mindestens eine Datenpaket einen Header und einen Payload-Abschnitt aufweisen. Der Header eines Datenpakets kann den wieder verwendeten Identifizierer aufweisen, wenn bestimmt worden ist, dass eine Textmuster-Formatbeschreibung für ein Textmuster, die gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist. In dieser beispielhaften Ausführungsform der vorliegenden Erfindung kann ein Header in einem RTP-Paket den Muster-Identifizierer, der für eine Textmuster-Formatbeschreibung verwendet ist, um die Wiederverwendung der Textmuster-Formatbeschreibung zu dem empfangenden Client anzuzeigen, aufweisen. Weiterhin kann das Textmuster, das das Format, spezifiziert in der Textmuster-Formatbeschreibung, erfordert, auch zu dem selben Identifizierer zugeordnet werden, so dass der Client das Textmuster zu seiner zugeordneten Textmuster-Formatbeschreibung auflisten kann.
Weiterhin sollte angemerkt werden, dass mindestens ein Datenpaket eine Mehrzahl von Textmustern und Textmuster-Formatbeschreibungen aufweisen kann. Es sollte verständlich werden, dass ein einzelnes Datenpaket nur ein einzelnes Textmuster und/oder Textmuster-Formatbeschreibung oder sogar nur Fragmente davon aufweisen kann. In ähnlicher Weise kann ein einzelnes Datenpaket eine Mehrzahl von Textmustern und/oder Textmuster-Formatbeschreibungen aufweisen.
Falls bestimmt worden ist, dass eine Textmuster-Formatbeschreibung für ein Textmuster, die gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist, kann der Header eines Datenpakets mindestens einen Muster-Identifizierer und mindestens eine Textmuster-Formatbeschreibung aufweisen.
In dem alternativen Fall kann der Header eines Datenpakets mindestens einen Muster-Identifizierer aufweisen, da die Textmuster-Formatbeschreibung weggelassen werden kann, da sie bereits früher zu dem Client bereitgestellt worden ist.
Wie vorstehend angegeben ist, weist das mindestens eine Datenpaket einen Header und einen Payload-Abschnitt auf. Weiterhin kann der Payload-Abschnitt mindestens einen Muster-Identifizierer und mindestens ein Textmuster aufweisen. Demzufolge kann, durch Zuordnen des Muster-Identifizierers und des Textmusters des Payload-Abschnitts und der Benutzung des Muster-Identifizierers für die Textmuster-Formatbeschreibung eine Auflistung durch den Client durchgeführt werden, um korrekt das Textmuster zu formatieren.
Die Bestimmung, ob eine Textmuster-Formatbeschreibung für ein Textmuster, die gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist, kann, z.B., auf den aufrechterhaltenen Informationen basiert werden.
Eine andere Ausführungsform der vorliegenden Erfindung wendet sich der Speicherverwaltung zum Cache-Speichern der Muster-Beschreibungs-Informationen in dem Client zu, um die Speichergröße, die für ein Caching benötigt wird, zu steuern. Um die Größe eines erforderlichen Speichers zu verringern, kann nur eine vorbestimmte Anzahl von Identifizierern verwendet werden. Demzufolge kann, falls bestimmt worden ist, dass eine Textmuster-Formatbeschreibung für ein Textmuster, das gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist, und falls alle verfügbaren Identifizierer für ein Auflisten von Textmustern zu Textmuster-Formatbeschreibungen verwendet sind, ein Muster-Identifizierer wieder für die Bereitstellung einer neuen Textmuster-Formatbeschreibung und des entsprechenden Textmusters zu dem mobilen Client verwendet werden.
Dementsprechend ist es von Vorteil, dass die aufrechterhaltenden Informationen über bereitgestellte Textmuster-Formatbeschreibungen unter Wiederverwendung eines Identifizierers aktualisiert werden können.
Um zu entscheiden, welcher Muster-Identifizierer wieder verwendet werden sollte, können die beibehaltenden Informationen weiterhin einen Zeitstempel für jeden Muster-Identifizierer aufweisen, der das späteste Einsetzen eines Muster-Identifizierers in ein gesendetes Datenpaket anzeigt. Demzufolge kann, gemäß einer anderen Ausführungsform der vorliegenden Erfindung, der Muster-Identifizierer mit dem frühesten Zeitstempel wieder für das Senden einer neuen Textmuster-Formatbeschreibung zu dem mobilen Client verwendet werden.
Weiterhin sollte angemerkt werden, dass mindestens ein Datenpaket nur mindestens eine Textmuster-Formatbeschreibung aufweisen kann.
In einer anderen Ausführungsform schafft die vorliegende Erfindung einen Streaming-Server in einem Mobilkommunikationssystem, das einen formatierten Text zu einem mobilen Client unter Verwendung des RTP-Protokolls sendet. Der formatierte Text kann mindestens ein Textmuster aufweisen, das eine zugeordnete Textmuster-Formatbeschreibung besitzt. Der Streaming-Server kann eine ein Paket bildende Einrichtung zum Bilden mindestens eines Datenpakets, eine Verarbeitungseinrichtung zum Bestimmen, ob eine Textmuster-Formatbeschreibung für ein Textmuster, die gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist, und eine Sendeeinrichtung zum Senden des mindestens einen Datenpakets zu dem mobilen Client aufweisen.
Die Paketbildungseinrichtung kann so angepasst sein, um das Textmuster, das gesendet werden soll, zu mindestens einem Datenpaket, das gesendet werden soll, hinzuzufügen, wenn die Verarbeitungseinrichtung bestimmt hat, dass eine Textmuster-Formatbeschreibung für ein Textmuster, das gesendet werden soll, bereits für ein früheres Textmuster bereitgestellt worden ist. Weiterhin kann die das Paket bildende Einrichtung so angepasst sein, um das Textmuster, das übertragen werden soll, und dessen zugeordnete Textmuster-Formatbeschreibung zumindest zu einem Datenpaket, das gesendet werden soll, hinzuzufügen, wenn die Verarbeitungeinrichtung bestimmt hat, dass eine Textmuster-Formatbeschreibung für ein Textmuster, das gesendet werden soll, nicht bereits für ein früheres Textmuster bereitgestellt worden ist.
Weiterhin kann der Streaming-Server so angepasst sein, um das Verfahren gemäß den unterschiedlichen Ausführungsformen, wie sie vorstehend beschrieben sind, auszuführen.
In einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines mobilen Clients in einem Mobilkommunikationssystem, um einen formatierten Text von einem Streaming-Server, unter Verwendung des RTP-Protokolls, zu empfangen, geschaffen. Wiederum kann der formatierte Text mindestens ein Textmuster aufweisen, das eine zugeordnete Textmuster-Formatbeschreibung besitzt. Der mobile Client kann mindestens ein Datenpaket von dem Streaming-Server empfangen, wobei das mindestens eine Datenpaket mindestens ein Textmuster aufweisen kann. Als nächstes kann der Client bestimmen, ob für ein jeweiliges eines des mindestens einen Textmusters das mindestens eine Datenpaket weiterhin mindestens eine zugeordnete Textmuster-Formatbeschreibung aufweist.
Falls dies der Fall ist, kann der Client die zugeordnete Textmuster-Formatbeschreibung für das jeweilige Textmuster, das in mindestens einem Datenpaket enthalten ist, direkt von dem Datenpaket auswählen. Falls dies nicht der Fall ist, kann eine Textmuster-Formatbeschreibung für das jeweilige Textmuster von Textmuster-Formatbeschreibungen ausgewählt werden, die bereits an dem mobilen Client verfügbar sind, da angenommen werden kann, oder dem Client angezeigt ist, dass die erforderliche Muster-Beschreibung bereits dem Client früher bereitgestellt worden ist. Indem das geeignete Format ausgewählt ist, d.h. eine Textmuster-Formatbeschreibung, kann das jeweilige Textmuster unter Verwendung der ausgewählten Textmuster-Formatbeschreibung formatiert werden.
Gemäß einer weiteren Ausführungsform weist das mindestens eine Datenpaket weiterhin mindestens einen Muster-Identifizierer auf, der mindestens ein Textmuster zu seiner zugeordneten Textmuster-Formatbeschreibung auflistet.
Um in der Lage zu sein, die geeignete Auflistung von Textmustern zu einer Textmuster-Formatbeschreibung (die früher empfangen ist) bereitzustellen, kann der Client Informationen über die Textmuster-Formatbeschreibungen beibehalten, die in den empfangenen Datenpaketen bereitgestellt sind. Die beibehaltenden Informationen können deshalb Daten über die bereitgestellte, mindestens eine Textmuster-Formatbeschreibung, und deren mindestens einen Muster-Identifizierer, aufweisen, um in der Lage zu sein, die Auflistung zu den Textmustern durchzuführen.
Wenn die zugeordnete Textmuster-Formatbeschreibung für ein Textmuster ausgewählt wird, kann der Muster-Identifizierer, der dem Textmuster zugeordnet ist, dazu verwendet werden, die zugeordnete Textmuster-Formatbeschreibung in dem mindestens einen Datenpaket und in den Textmuster-Formatbeschreibungen, die bereits an dem mobilen Client verfügbar sind, zu identifizieren.
In dem Fall, dass der Client eine neue Textmuster-Formatbeschreibung, die einem Muster-Identifizierer zugeordnet ist, empfängt, die bereits zu einer anderen Textmuster-Formatbeschreibung in den aufrechterhaltenden Informationen zugeordnet ist, können die beibehaltenden Informationen basierend auf einer neuen Textmuster-Formatbeschreibung aktualisiert werden.
Um dem Streaming-Server zu ermöglichen, zu bestimmen, ob eine Textmuster-Formatbeschreibung erfolgreich durch den mobilen Client empfangen ist, kann derselbe das mindestens eine, empfangene Datenpaket bestätigen.
Weiterhin kann ein Datenpaket, das durch den mobilen Client empfangen ist, nur mindestens eine Textmuster-Formatbeschreibung aufweisen, und der mobile Client kann die mindestens eine Textmuster-Formatbeschreibung, die empfangen ist, speichern. Demzufolge kann es möglich sein, Pakete, die nur Muster-Beschreibungen aufweisen, zu senden/zu empfangen, und dieselben für eine spätere Benutzung zu speichern, wenn ein zugeordnetes Textmuster formatiert wird.
Eine andere Ausführungsform der vorliegenden Erfindung bezieht sich auf einen mobilen Client zum Empfangen eines formatierten Textes von einem Streaming-Server unter Verwendung des RTP-Protokolls. Der mobile Client kann eine Empfangseinrichtung zum Empfangen mindestens eines Datenpakets von dem Streaming-Server aufweisen, wobei das mindestens eine Datenpaket mindestens ein Textmuster, eine Verarbeitungseinrichtung zum Bestimmen, ob dies für ein jeweiliges eines des mindestens einen Textmusters gilt, wobei das mindestens eine Datenpaket weiterhin mindestens eine zugeordnete Textmuster-Formatbeschreibung aufweist, und eine Textformatiereinrichtung zum Formatieren des jeweiligen Textmusters unter Verwendung der ausgewählten Textmuster-Formatbeschreibung aufweisen.
Die Auswahleinrichtung kann so angepasst sein, um die zugeordnete Textmuster-Formatbeschreibung für das jeweilige Textmuster, das in dem mindestens einen Datenpaket enthalten ist, auszuwählen, falls bestimmt ist, dass für ein jeweiliges eines des mindestens einen Textmusters das mindestens eine Datenpaket weiterhin mindestens eine zugeordnete Textmuster-Formatbeschreibung aufweist. Weiterhin kann die Auswahleinrichtung so angepasst sein, um eine Textmuster-Formatbeschreibung für das jeweilige Textmuster von den Textmuster-Formatbeschreibungen, die bereits an dem mobilen Client verfügbar sind, auszuwählen, falls bestimmt ist, dass, für ein jeweiliges eines des mindestens einen Textmusters, das mindestens eine Datenpaket nicht mindestens eine zugeordnete Textmuster-Formatbeschreibung aufweist.
Weiterhin kann der mobile Client so angepasst sein, um die unterschiedlichen Ausführungsformen des Verfahrens, das vorstehend beschrieben ist, durchzuführen.
Gemäß einer weiteren Ausführungsform schafft die vorliegende Erfindung ein Streaming-System, das mindestens einen Streaming-Server und mindestens einen mobilen Client aufweist.
Kurze Beschreibung der Figuren
Nachfolgend wird die vorliegende Erfindung in weiterem Detail unter Bezugnahme auf die beigefügten Figuren und Zeichnungen beschrieben. Ähnliche oder entsprechende Details in den Figuren sind mit denselben Bezugszeichen bezeichnet.
1 stellt eine architekturmäßige Übersicht des Streaming-Systems gemäß einer Ausführungsform der vorliegenden Erfindung dar,
2 stellt ein Payload-Header-Format für RTP gemäß einer Ausführungsform der vorliegenden Erfindung dar,
3 stellt ein Muster-Beschreibungsfeld des Payload-Headers, dargestellt in 2, gemäß einer Ausführungsform der vorliegenden Erfindung dar,
4 stellt das Payload-Header-Format für RTP gemäß 2 dar, das eine wieder verwendete Textmuster-Formatbeschreibung und eine Textmuster-Formatbeschreibung, die in dem Header umfasst ist, gemäß einer Ausführungsform der vorliegenden Erfindung, besitzt, und,
5 stellt eine verbesserte Version des Payload-Header-Formats für RTP, dargestellt in 3, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Detaillierte Beschreibung
Obwohl die nachfolgende Beschreibung hauptsächlich unter Bezugnahme auf ein 3GPP Zeit abgestimmtes Text-Streaming erläutert wird, ist anzumerken, dass die Prinzipien, die diese Erfindung unterlegen, einfach bei anderen Text-Streaming-Systemen in Mobilkommunikationssystemen angewandt werden können, in denen ein Text und dessen Format-Beschreibungen einem Streaming unterworfen werden.
1 stellt eine Übersicht der System-Architektur gemäß einer Ausführungsform der vorliegenden Erfindung dar. Der Streaming-Server 100 stellt einen einem Streaming unterworfenen, formatierten Text zu dem mobilen Client 101 hin bereit. In der beispielhaften Architektur, die dargestellt ist, werden die einem Streaming unterworfenen Daten über das Internet, d.h. über ein auf IP basierendes Netzwerk (Internet), geführt, bevor sie in ein drahtloses Netzwerk, wie beispielsweise das UMTS 102, eintreten. In dem Beispiel, das dargestellt ist, stellt der GGSN 105 (Gateway GPRS Support Node) das Gateway dar, das das UMTS-Kernnetzwerk (CN) 103 mit dem Internet verbindet. Die Daten werden über das CN 103 (über Serving GPRS Support Node SGSN 106) und über das Zugangs-Netzwerk, hier UTRAN 104, zu dem mobilen Client 101 über eine drahtlose Schnittstelle geführt. Der unterbrochene Pfeil in der Figur zeigt die Zuführung der einem Streaming unterworfenen Daten zu dem mobilen Client 101 über den CN 103 und das UTRAN 104 an. Es sollte angemerkt werden, dass die vorliegende Erfindung nicht auf die Ausführungsform, die in 1 dargestellt ist, beschränkt ist. Der Streaming-Server kann z.B. auch innerhalb des UMTS-Netzwerks 102 angeordnet sein, wobei Daten nicht notwendigerweise über ein auf IP basierendes Netzwerk zugeführt werden müssen, so dass andere Mobilkommunikationssysteme als UMTS verwendet werden können, usw..
Gemäß einem Aspekt der vorliegenden Erfindung kann der Streaming-Server 100 eine Liste von gesendeten Paketen und eine bestimmte Aufzeichnung der Muster-Beschreibungs-Informations-Einträge, die in jedem RTP-Paket gesendet sind, z.B. eine Liste von SIDX-Werten, die in jedem Paket gesendet sind, aufrechterhalten. Der Streaming-Server 100 kann, indem diese beibehaltenden Informationen verfügbar sind, die Muster-Beschreibungen der Textmuster, die momentan zum Senden verarbeitet werden, mit solchen vergleichen, die in den gesendeten Datenpaketen umfasst sind. Der Client kann ein Feedback zu dem Server für diese Datenpakete bereitstellen, um ein Rücksenden dieser Muster-Formatbeschreibungen zu vermeiden. Weiterhin kann der Client eine Liste von empfangenen Muster-Beschreibungs-Einträgen ausarbeiten und deren entsprechende Muster-Beschreibungswerte speichern. Diese Aufzeichnung von empfangenen Muster-Einträgen kann eine minimale Lebensdauer gleich zu der Dauer der Streaming-Sitzung haben.
Die nachfolgende Tabelle wird ein Beispiel für die Liste oder Informationen, die durch den Streaming-Server 100 aufrechterhalten werden, angeben, um die Zuordnung zwischen Muster-Identifizierern SIDX, Muster-Beschreibungen und Datenpaketen, in denen die Muster-Beschreibungen vorhanden sind (gesendet werden müssen), zu bestimmen.
Die Informationen, die durch den Streaming-Server 100 über bereitgestellte Muster-Beschreibungen gesammelt sind, können die Muster-Beschreibung und die RTP-Pakete aufweisen, in denen dieselben zu dem mobilen Client 101 gesendet worden sind oder gerade gesendet werden. Darüber hinaus können die Informationen weiterhin einen Muster-Identifizierer aufweisen, der das Auflisten zwischen Muster-Beschreibungen und Textmustern erleichtert. Weiterhin können, in einer anderen Ausführungsform der vorliegenden Erfindung, die Informationen, die aufrechterhalten werden, weiterhin anzeigen, ob alle RTP-Pakete, die Muster-Beschreibungen führen, gesendet worden sind (TX), oder ob dieselben für eine erneute Übertragung anhängig sind, d.h. momentan für ein Senden präpariert werden. Zusätzlich kann der Bestätigungs-Status (ACK) von Datenpaketen, in denen die Muster-Beschreibungen gesendet worden sind, auch angezeigt werden.
Das Beispiel, das in der Tabelle vorstehend angegeben ist, stellt dar, dass z.B. die Muster-Beschreibung SPLATTR#1 einen zugeordneten Muster-Identifizierer SIDX#1 besitzt. Weiterhin ist die Muster-Beschreibung in einem einzelnen RTP-Paket, das z.B. durch seine Folge-Nummer SN#1 identifiziert ist, zu dem Client gesendet worden. Entsprechend dem Bestätigungs-Status ist das Datenpaket SN#1 gesendet worden und ist erfolgreich durch den Client empfangen worden. Demzufolge muss eine Muster-Beschreibung eines neuen Textmusters, das durch den Streaming-Server 100 gesendet werden soll, unter Bereitstellung derselben Muster-Beschreibung SPLATTR#1, nicht durch den Server erneut gesendet werden.
Unter Heranziehen der nächsten Muster-Beschreibungen SPLATTR#2 und SPLATTR#3, als ein Beispiel, ist dasselbe in einem RTP-Datenpaket (SN#2) gesendet worden. Weiterhin ist dieses Datenpaket auch gesendet worden und durch den Client bestätigt worden. Dieses Beispiel zeigt, dass auch mehrere Muster-Beschreibungen in einem RTP-Datenpaket gesendet werden können.
Als nächstes ist die Muster-Beschreibung SPLATTR#4 in einem einzelnen Datenpaket (SN#3) gesendet worden, das bis jetzt noch nicht durch den Client bestätigt worden ist. In dem Fall, dass eine Muster-Beschreibung identisch zu SPLATTR#4 für ein nächstes Textmuster, das gesendet werden soll, bereitgestellt ist, kann der Streaming-Server 100 die Muster-Beschreibung erneut senden (zurücksenden), da das Datenpaket, in dem es zu dem Client gesendet worden ist, bis jetzt noch nicht bestätigt worden ist.
Alternativ kann, gemäß einer anderen Ausführungsform dieser Erfindung, der Streaming-Server 100 nicht die Muster-Beschreibung erneut zurücksenden, unter der Annahme, dass alle Pakete erfolgreich durch den Client empfangen sind, d.h. auch die RTP-Pakete, die durch SN#3 identifiziert sind, werden erfolgreich empfangen werden. Allerdings sollte angemerkt werden, dass dann, wenn Datenfolgen in einem paketmäßig geschalteten Netzwerk, wie das Internet, zugeführt werden, nicht sichergestellt werden kann, dass Datenpakete an dem Client in der Reihenfolge ankommen, in der sie durch den Server gesendet worden sind. Demzufolge kann, in dieser Ausführungsform, eine Muster-Beschreibung, die vor einem Textmuster gesendet ist, unter Verwendung der Muster-Beschreibung, – in der Theorie – an dem empfangenden Client später als das Textmuster ankommen.
Unter Betrachtung der Muster-Beschreibung SPLATTR#5 stellt die Tabelle vorstehend dar, dass die Muster-Beschreibung, aufgeteilt in zwei Datenpaketen, SN#3 und SN#4, gesendet worden ist. Beide RTP-Pakete sind gesendet worden, allerdings kann, da mindestens das Paket SN#3 nicht bestätigt worden ist, die Muster-Beschreibung nicht als durch den Server verfügbar angesehen werden.
Weiterhin ist, unter Heranziehen der Muster-Beschreibung SPLATTR#X, anzumerken, dass diese Beschreibung durch den Muster-Identifizierer SIDX#X identifiziert ist. Weiterhin ist das Datenpaket SN#Y, in dem die Muster-Beschreibung enthalten ist, momentan für ein Senden anhängig (ANHÄNGIG). Demzufolge kann das RTP-Paket ein Paket sein, das durch den Server für ein Senden in eine Warteschlange gestellt ist, oder kann ein RTP-Paket sein, das momentan durch den Streaming-Server 100 zusammengestellt wird, d.h. ein Datenpaket, das momentan mit Informationen gefüllt wird.
In dem Fall, dass das Datenpaket SN#Y bereits aufgebaut worden ist, allerdings noch für ein Senden anhängig ist, können zwei Möglichkeiten für den Streaming-Server 100 vorhanden sein, um zu arbeiten. Er kann entweder annehmen, dass er das Datenpaket SN#Y erfolgreich empfangen kann und das Senden der Muster-Beschreibung für ein neues Textmuster unter Verwendung davon weglassen kann, oder kann die Muster-Beschreibung zu einem neuen RTP-Paket erneut hinzufügen, wenn ein Textmuster die Beschreibung SPLATTR#X erneut verwendet. Unter der Annahme, dass die Muster-Beschreibung SPLATTR#X aus demselben RTP-Paket wie eine neue Muster-Beschreibung, die gesendet werden soll, unter Verwendung derselben Beschreibung, zusammengesetzt ist, kann das Senden (Zurücksenden) der Muster-Beschreibung für das neue Textmuster weggelassen werden.
Um die empfangenen Textmuster korrekt zu formatieren, kann der mobile Client 101 eine ähnliche Liste, die die Daten der ersten zwei Spalten der Tabelle vorstehend aufweist, aufrechterhalten. Ein Aufrechterhalten der Informationen über Muster-Identifizierer und zugeordnete Muster-Beschreibungen können dem Client ermöglichen, eine Auflistung von empfangenen Textmustern zu der geeigneten Muster-Beschreibung bereitzustellen. Das Letztere kann möglich sein, da jedes Textmuster, das in dem Payload eines RTP-Pakets empfangen ist, einen Muster-Identifizierer aufweisen kann, der das empfangene Textmuster zu einer zugeordneten Muster-Beschreibung auflistet.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung können sowohl der Streaming-Server 100 als auch der empfangende Client verbesserte Rückführ-Fähigkeiten umsetzen, z.B. wie dies in Ott et al., "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" (draft-ietf-avt-rtcp-feedback-07.txt, IETF AVT WG, Juni 2003), oder Friedmann et al., "RTP Control Protocol Extended Reports" (draft-ietf-avt-rtcp-reportextns-06.txt, IETF AVT WG, Mai 2003), beide erhältlich über http://www.ietf.org, beschrieben ist. Insbesondere können der "Loss RLE Report Block im Abschnitt 4.1 des Konzepts von Friedmann und die ACK/NACK Messages des Konzepts von Ott verwendet werden, um den Server über eine exakte Verlust/Empfangs-Spur von Datenpaketen zu informieren, d.h. welche empfangen wurden oder verloren gingen. Durch Einsetzen dieser "Erweiterungen" in Bezug auf das übliche RTP-Protokoll können einzelne Pakete bestätigt werden, so dass ein Server, der die Bestätigungen empfängt, die Muster-Beschreibungen verfolgen kann. (Textmuster-Formatbeschreibungen), die zu dem Client gesendet sind, der die in dem Server aufrechterhaltene Liste, wie sie vorstehend beschrieben ist, einsetzt. Demzufolge kann der Streaming-Server 100, der mit einer Rückführung über erfolgreich empfangene Datenpakete an dem Client ausgestattet ist, redundante Informationen in neueren RTP-Paketen unterdrücken. Der Streaming-Server 100 kann vor einem Einschließen von Muster-Beschreibungs-Informationen in RTP-Pakete prüfen, ob die gegebenen Muster-Beschreibungen in vorherigen RTP-Paketen gesendet worden sind oder ob sie bereits zu RTP-Paketen hinzugefügt worden sind, die gerade durch den Streaming-Server 100 gesendet werden. Um sicherzustellen, dass eine Muster-Beschreibung, die in einem früheren RTP-Paket gesendet ist, bereits durch den Client empfangen worden ist, kann der Streaming-Server 100 weiterhin prüfen, ob RTP-Pakete, die solche Einträge führen, durch den Client bestätigt worden sind. In dem letzteren Fall ist das Einschließen der Einträge in das neue RTP-Paket redundant und kann demzufolge vermieden werden. Ansonsten können die Muster-Beschreibungs-Informationseinträge so eingeschlossen werden, wie dies in dem Konzept "RTP Payload Format for 3GPP Timed Text" von Rey et al., vorgeschlagen ist.
Nachfolgend wird ein beispielhaftes Format zum Senden der Textmuster-Formatbeschreibungen in einem neuen Payload-Header für RTP unter Bezugnahme auf 2 diskutiert. 2 stellt einen SPLDESC (SamPleDESCripton) Payload-Header für RTP gemäß einer Ausführungsform der vorliegenden Erfindung dar. Der Header weist ein Anfangs-Eintritts-Zählfeld, gefolgt durch eine Anzahl von Muster-Identifizierern SIDX und Muster-Attribut-SPLATTR-Paaren, auf. Demzufolge kann dieser Header dazu verwendet werden, Textmuster-Formatbeschreibungen von Textmustern zu einem empfangenden Client zu transportieren. Der Payload-Abschnitt eines RTP-Pakets, das diesen Header aufweist, kann optional mindestens ein Textmuster aufweisen. Das Textmuster kann einem Muster-Identifizierer SIDX zugeordnet sein, der das Textmuster zu einer spezifischen Muster-Beschreibung, die denselben Muster-Identifizierer SIDX besitzt, auflistet.
Die Eingangszählung kann eine Anfangsfolge aus Bits sein, die die Anzahl von Eintritten in dem Header anzeigt. In dem Beispiel, das dargestellt ist, können zwei (0×02) Einträge in dem Header (siehe 3) umfasst sein. Ein Eintrag kann als ein Paar definiert sein, das ein SIDX Feld und ein SPLATTR Feld aufweist. Die Einträge können einem bestimmten Textmuster, das zu dem Client übertragen ist, entsprechen.
Das SIDX kann den Muster-Beschreibungs-Index oder den Muster-Identifizierer, der dazu verwendet wird, die Muster-Attribute in dem SPLATTR Feld zu einem oder mehreren Textmuster(n) aufzulisten, darstellen. Das SPLATTR Feld kann die Muster-Beschreibungs-Attribute, die in dem SPLDESC Header gesendet sind, aufweisen. Dieses Feld kann die Textmuster-Voreinstellungs-Attribute umfassen, wie dies, z.B., in dem "tx3g" Muster-Eintrag von Anhang D.8a.16 in 3GPP TS 26.234 dargestellt ist. Die Länge dieses Felds kann variabel sein.
Weiterhin kann das Feld ein Anfangs-Byte mit 1-Bit Zeichen enthalten. Jedes Zeichen zeigt an, wenn das entsprechende Feld in den folgenden Bits vorhanden ist. Ein Beispiel für das SPLATTR Feld, in dem alle Zeichen eingestellt sind, ist in 3 zu Erläuterungszwecken dargestellt. Das R (1 Bit) kann ein reserviertes Bit anzeigen, D (1 Bit) kann ein displayFlags Zeichen anzeigen, H (1 Bit) kann ein horizontales Einstellungs-Zeichen anzeigen, V (1 Bit) kann ein vertikales Einstellungs-Zeichen anzeigen, B (1 Bit) kann ein Hintergrund-RGBA-Farb-Zeichen anzeigen, T (1 Bit) kann ein Voreinstellungs-Text-Kasten-Zeichen anzeigen, S (1 Bit) kann ein Voreinstellungs-Stil-Zeichen anzeigen, und F (1 Bit) kann ein Schriftzeichen-Tabellen-Zeichen anzeigen.
Die Werte für dieses "displayFlags" Feld (z.B. 16 Bits) können Anzeige-Optionen des Texts anzeigen: Hereinlaufenlassen/Herauslaufenlassen, Laufrichtung, Karaoke oder vertikaler Text. Wenn das H(V) Bit eingestellt ist, ist das horizontale(vertikale) Einstellungs-Feld (8 Bits) in dem SPLATTR Feld vorhanden. Weiterhin können z.B. vier Acht-Bit- Zeichen (Oktetts) (32 Bits) die RGBA-Hintergrund-Farbe anzeigen, wenn das B Bit eingestellt ist. Die Reihenfolge der Oktetts kann Rot, Grün, Blau und Alpha (Transparenz) sein.
Wenn das T Bit eingestellt ist, ist das Voreinstellungs-Text-Kasten-Feld (z.B. 64 Bits) vorhanden. Dieses Feld kann vier 16-Bit-Werte (oben, links, unten, rechts) aufweisen, die die Position des Text-Kastens in Pixel relativ zu dem Textbereich-Ursprungsbereich definieren. Ein S Bit, eingestellt in dem Feld, zeigt das Vorhandensein eines Voreinstellungs-Stil-Kasten-Felds an. Um anzuzeigen, welche Felder vorhanden sind, kann ein zusätzliches Byte (siehe die Figur vorstehend) aus Zeichen verwendet werden.
Wenn das F Bit eingestellt ist, ist die Schriftzeichen-Tabelle (variable Größe, 10 Bytes in diesem Beispiel) vorhanden. Die Schriftzeichen-Tabelle kann ein Eintrag-Zählfeld (16 Bits), gefolgt durch eine Zahl von Schriftzeichen-Einträgen, aufweisen. Ein Schriftzeichensatz-Eintrag kann eine Schriftzeichensatz-Identifizierer Schriftzeichensatz-ID (16 Bits) von der Schriftzeichensatz-Tabelle, eine Schriftzeichensatz-Namen-Länge (8 Bits, die die Länge des Schriftzeichensatz-Namens in Bytes, den Schriftzeichensatz-Namen, z.B. ausgedrückt als eine Folge von 8-Bit UTF-8 Zeichen, bereitstellen), aufweisen. Die Folge kann eine mit Komma getrennte Liste von Schriftzeichensatz-Namen, um als alternativer Schriftzeichensatz, in einer bevorzugten Reihenfolge, verwendet zu werden, sein.
Wie in den vorherigen Abschnitten erläutert ist, kann sich, während einer 3GPP Timed Text-Sitzung, der Streaming-Server 100 nicht über die Datenpakete, die durch den Client, in einem allgemeinen Fall, empfangen sind, bewusst sein. Dies ist nicht der Fall dann, wenn der Client zusätzliche Rückführ-Fähigkeiten, wie sie vorstehend diskutiert sind, umsetzt. Mit diesen verbesserten Rückführ-Fähigkeiten kann der Client in der Lage sein, den Server über jedes einzelne Paket, das empfangen ist, zu informieren. Mit diesem Teil an Informationen und einer Liste hält der Server die gesendeten SIDX-Werte in jedem Paket bei, so dass es möglich ist, die empfangenen Pakete zu empfangenen SIDXs aufzulisten. Der Server kann dann nur solche Muster-Beschreibungen in neuen Datenpaketen umfassen, die bis jetzt noch nicht empfangen worden sind. Demzufolge kann das Overhead für den Fall, wenn Textmuster-Formatbeschreibungen gesendet werden, wesentlich verringert werden. Ein Zeichen-Byte in dem SPLATTR Feld des SPLDESC Payload-Headers kann auf Null'en für Muster-Beschreibungen (oder SIDX-Werten) gesetzt werden, um einem empfangenden Client anzuzeigen, dass das mit Attri but versehene Muster-Format bereits durch den Client empfangen worden ist. Eine beispielhafte Format-Konfiguration ist in 4 dargestellt. Es ist anzumerken, dass, nur zu erläuternden Zwecken, eine Größe von 8 Bits für die Länge des SIDX Felds und das Eintrag-Zählfeld verwendet wird.
Das Eintrag-Zählfeld zeigt an, dass zwei Einträge, d.h. zwei SIDX-SPLATTR Feld-Paare, in dem Header umfasst sind. Das SIDX#1 Feld ist zu einer Muster-Beschreibung mit dem Muster-Identifizierer 0×01 in Bezug gesetzt, der bereits empfangen worden ist oder nicht gegenüber den Voreinstellungen unterschiedlich ist. Dies wird dadurch angezeigt, dass das SPLATTR Feld auf eine vorbestimmte Bit-Kombination eingestellt wird, z.B. um alle Bits des Fels auf 0 (SPLATTR#1=0×00) einzustellen. Das SIDX#2 Feld identifiziert zum Beispiel eine Muster-Beschreibung mit einer Index-Nummer 0×02, deren horizontale und vertikale Einstellungswerte sich von den Voreinstellungen (SPLATTR#1=0×18=00110000₂) unterscheiden. Die zwei Oktetts (0×00, 0×00), die folgen, werden auf Null gesetzt und zeigen die obere, linke Einstellung an (siehe auch 3).
Weiterhin können, für ein In-Band-Senden einer Textmuster-Beschreibung, die folgenden Regeln auf das Codieren der Felder angewandt werden: SIDX-Werte, die in Textmustern des RTP-Payloads vorhanden sind, können in einem SPLDESC Header desselben Pakets eingeschlossen werden. Demzufolge weist, in diesem Fall, das RTP-Paket nicht nur die Text-Format-Attribute auf, sondern auch das Textmuster der Attribute, die dazu gehören. Es sollte angemerkt werden, dass auch mehr als ein Textmuster in dem Payload einem SIDX-Wert in dem Header zugeordnet werden kann. Das entsprechende Format der Textmuster, d.h. SPLATTR Feld-Inhalte, können vorhanden sein, ohne dass der Client die SPLATTR Inhalte für das gegebene SIDX gespeichert hat. In dem letzteren Fall können sowohl SIDX als auch SPLATTR weggelassen werden, da die Verwendung der erweiterten Rückführung ermöglichen kann, dass der Streaming-Server 100 bestimmt, welche RTP-Pakete durch den Client empfangen werden und demzufolge welche Textmuster-Formatbeschreibungen an dem mobilen Client 101s verfügbar sind.
Alle SIDX Werte, die in dem SPLDESC Header eines RTP-Pakets vorhanden sind, können in mindestens einem der Textmuster in dem Payload vorhanden sein.
Zusätzlich können die RTP-Pakete nur Muster-Beschreibungen ohne irgendwelche Textmuster führen. Für den letzteren Fall, und unter Verwendung derselben Werte, wie vorstehend, ist eine Rückwärts-Kompatibel-Struktur des SPLDESC Headers in 5 dargestellt.
Die Eintrag-Zählung kann 7 Bits aufweisen, wie dies dargestellt ist. Das neue F Bit kann auf 1 gesetzt werden, wenn das RTP-Paket nur Muster-Beschreibungs-Informationen, ohne dass irgendwelche Textmuster folgen, führt. Die Eintrags-Zählung ist identisch zu derjenigen, die in 3 dargestellt ist, wenn das Bit F auf 0 gesetzt ist, und demzufolge kann das RTP-Paket sowohl Muster-Beschreibungen als auch deren zugeordnete Textmuster, die mit den Regeln, die vorstehend angegeben sind, übereinstimmen, umfassen.
Diese Optimierung des Mechanismus für ein Senden der Muster-Beschreibung, die angegeben ist, kann die Möglichkeit bieten, das Overhead in dem RTP-Paket-Senden zu verringern, indem der Streaming-Server 100 über solche Teile an Informationen informiert wird, die der Streaming-Client bereits besitzt, und die nicht erneut gesendet werden müssen.
Dies ermöglicht auch nur das Senden von Muster-Beschreibungs-Informationen, ohne dass es notwendig ist, die zugeordneten Textmuster einzuschließen. Dies ermöglicht weiterhin dem Server, speziell den Empfang solcher wichtigen Informationen unter Verwendung von Wiederholungs-Schemata oder Vorwärts-Fehler-Korrektur-Techniken zu schützen oder sicherzustellen, wie dies durch Rosenberg et al., in "An RTP Payload Format for Generic Forward Error Correction" RFC 2733, Dezember 1999, beschrieben ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung kann nur eine vorbestimmte Zahl von Muster-Identifizierern verwendet werden. Dies kann wesentlich die Puffergröße für Muster-Beschreibungen an dem mobilen Client 101 verringern. Dies kann zum Beispiel dann relevant sein, wenn ein als Datenfolge gebildeter Text eine große Vielfalt von Textmuster-Formatbeschreibungen verwendet. In dem letzteren Fall kann der Client alle Muster-Beschreibungen speichern müssen, wenn das Verfahren, das vorstehend beschrieben ist, verwendet wird. Um zwischen einer Verringerung des Sende-Overheads und einer Vergrößerung des Speichers, der zum Speichern der Muster-Beschreibungen benötigt wird, abzuwägen, kann vorgesehen werden, die Anzahl von verfügbaren SIDX-Werten zu begrenzen, um dadurch die Speicherkapazität, die für Muster-Beschreibungen in dem Client benötigt wird, zu begrenzen.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung kann der Streaming-Server 100 nur eine vorbestimmte Anzahl von Muster-Identifizierern verwenden, um Muster-Beschreibungen zu zugeordneten Textmustern aufzulisten. Unter der Annahme, dass N Muster-Identifizierer verfügbar sind, kann es für den Streaming-Server 100 erforderlich sein, einen der Muster-Identifizierer unter Verarbeitung eines neuen Textmusters, das der N+1-ten Muster-Beschreibung zugeordnet ist, erneut zu verwenden. In diesem Fall kann der Streaming-Server 100 unterschiedliche Strategien verwenden, um den Muster-Identifizierer, der wieder verwendet werden soll, auszuwählen. Das einfachste Schema würde dasjenige sein, die verfügbaren Muster-Identifizierer zyklisch wieder zu verwenden. Zum Beispiel können, indem dieselben Muster-Identifizierer SIDX#1 bis SIDX#N verwendet sind, die Muster-Beschreibungen des Muster-Identifizierers SIDX#1 überschrieben werden, d.h. wieder verwendet werden, indem alle verfügbaren Identifizierer zu den Muster-Beschreibungen zugeordnet worden sind.
Alternativ kann der Streaming-Server 100 Informationen über die letzte Verwendung einer Muster-Beschreibung aufrechterhalten, d.h. einen Muster-Identifizierer, und kann z.B. den Muster-Identifizierer wieder verwenden, der nicht für das längste Zeit-Intervall verwendet worden ist. Deshalb kann der Streaming-Server 100 eine Liste von Informationen aufrechterhalten, wie dies nachfolgend dargestellt ist.
Die Tabelle vorstehend entspricht hauptsächlich der Tabelle, die in einem vorherigen Abschnitt dargestellt ist. Deshalb wird die Beschreibung der entsprechenden Elemente weggelassen werden. In dem Beispiel vorstehend bedeutet X ein vorgegebener Wert.
In der Tabelle ist eine Spalte, die die letzte Benutzung des Textmusters mittels eines Zeitstempels anzeigt, hinzugefügt worden. Unter der Annahme, dass TS#2 der früheste Zeitstempel in der Liste ist, kann der Streaming-Server 100 SIDX#2 für eine neue Muster-Beschreibung wieder verwenden und kann das SPLATTR#2 Feld mit der neuen Muster-Beschreibung in dem Fall aktualisieren, in dem keine anderen "leere" SIDX Identifizierer verfügbar sind.
Die Wiederverwendung eines Muster-Identifizierers kann z.B. durch einfaches Senden einer neuen Muster-Beschreibung unter Verwendung eines verwendeten SIDX Identifizierers eingerichtet werden, d.h. Zuordnen des Muster-Identifizierers zu einer neuen Beschreibung. Die Auswahlkriterien für den Muster-Identifizierer, um wieder verwendet zu werden, können weiterhin berücksichtigen, dass Textmuster, die dem wieder verwendeten Muster-Identifizierer zugeordnet sind, und die vor der Wiederverwendung des Identifizierers gesendet worden sind, durch den Client unter Verwendung der "alten" Muster-Beschreibung formatiert werden sollten. Demzufolge kann ein Zeitstempel-Kriterium, wie dies vorstehend erläutert ist, ein gutes Maß für diese Situationen erzielen.
Weiterhin sollte angemerkt werden, dass der Client nicht die Wiederverwendungs-Kriterien der Muster-Identifizierer protokollieren muss. Sobald wie der Client eine Muster-Beschreibung zusammen mit einem zugeordneten Identifizierer empfangen hat, werden die aufrechterhaltenden Informationen an dem Client aktualisiert, d.h. der Identifizierer und die entsprechende Muster-Beschreibung können unabhängig davon gespeichert werden, ob der Muster-Identifizierer bereits verwendet worden ist oder nicht.

Claims

Verfahren zum Senden von formatiertem Text von einem Streaming-Server (100) zu einem mobilen Client (101) unter Verwendung eines RTP-Protokolls in einem Mobilkommunikationssystem (102), wobei der formatierte Text eine Vielzahl von Textmustern umfasst, die mit wenigstens einer Textmusterformat-Beschreibung verknüpft sind, die wenigstens eine Textmuster-Formatbeschreibung durch Inband-Signalisierung zu dem Client (101) übertragen wird und das Verfahren, das durch den Streaming-Server (100) durchgeführt wird, die folgenden Schritte umfasst: Feststellen, ob eine Textmuster-Formatbeschreibung, die mit einem zu sendenden Textmuster verknüpft ist, dem Client (101) für ein anderes früheres Textmuster in wenigstens einem zu sendenden Datenpaket bereitgestellt wird, wenn die Textmuster-Formatbeschreibung dem Client (101) für ein anderes früheres Textmuster in dem wenigstens einen zu sendenden Datenpaket bereitgestellt wird, Hinzufügen des zu sendenden Textmusters zu dem wenigstens einen zu sendenden Datenpaket, und Senden des wenigstens einen Datenpaketes zu dem mobilen Client (101), dadurch gekennzeichnet, dass wenn die Textmuster-Formatbeschreibung dem Client (101) für ein anderes früheres Textmuster in dem wenigstens einen zu sendenden Datenpaket nicht bereitgestellt wird, Feststellen, ob eine Textmuster-Formatbeschreibung, die mit einem zu sendenden Textmuster verknüpft ist, dem Client (101) bereits für ein anderes früheres Textmuster in wenigstens einem gesendeten Datenpaket bereitgestellt worden ist, wenn die Textmuster-Formatbeschreibung dem Client (101) für ein anderes früheres Textmuster in dem wenigstens einen gesendeten Datenpaket bereitgestellt worden ist, Hinzufügen des zu sendenden Textmusters zu dem wenigstens einen zu sendenden Datenpaket, wenn die Textmuster-Formatbeschreibung dem Client (101) für ein anderes früheres Textmuster in dem wenigstens einen gesendeten Datenpaket nicht bereitgestellt worden ist, Hinzufügen des zu sendenden Textmusters und der damit verknüpften Textmuster-Formatbeschreibung zu wenigstens einem zu sendenden Datenpaket.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die bereits bereitgestellte Textmuster-Formatbeschreibung beim Verarbeiten des früheren Textmusters zu dem wenigstens einen Datenpaket bereits vor seinem Senden hinzugefügt worden ist.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Schritt des Hinzufügens des zu sendenden Textmusters zu wenigstens einem Datenpaket des Weiteren das Hinzufügen wenigstens einer Muster-Kennung zu dem wenigstens einen Datenpaket umfasst, wobei eine Muster-Kennung ein Mapping zwischen einer Textmuster-Formatbeschreibung und dem damit verknüpften Textmuster in dem wenigstens einen Datenpaket bereitstellt.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass es des Weiteren den Schritt des Führens von Informationen über dem mobilen Client (101) bereitgestellte Textmuster-Formatbeschreibungen in den gesendeten Datenpaketen umfasst.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die geführten Informationen Daten über die bereitgestellten Textmuster-Formatbeschreibungen, Daten über das wenigstens eine Datenpaket, in dem die Textmuster-Formatbeschreibung gesendet worden ist, und die wenigstens eine Kennung umfassen.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass es des Weiteren den Schritt des Feststellens des wenigstens einen gesendeten Datenpaketes, in dem die Textmuster-Formatbeschreibung zu dem mobilen Client (101) gesendet worden ist, auf Basis der geführten Informationen umfasst, wenn festgestellt worden ist, dass eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster bereits für ein früheres Textmuster bereitgestellt worden ist.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass es des Weiteren den Schritt des Feststellens, ob das wenigstens eine Datenpaket von dem mobilen Client (101) quittiert worden ist, und wenn dies der Fall ist, des Wiederverwendens der gleichen Muster-Kennung, die in dem festgestellten wenigstens einen Datenpaket verwendet worden ist, zum Mapping des zu sendenden Textmusters auf eine bereitgestellte Textmuster-Formatbeschreibung umfasst.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass das zu sendende Textmuster und die damit verknüpfte Textmuster-Formatbeschreibung zu dem wenigstens einen Datenpaket hinzugefügt werden, wenn festgestellt worden ist, dass das festgestellte wenigstens eine Datenpaket von dem mobilen Client (101) nicht quittiert worden ist.
Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass das wenigstens eine Datenpaket einen Header und einen Nutzdatenabschnitt umfasst, und wobei der Header eines Datenpaketes die wiederverwendete Kennung umfasst, wenn festgestellt worden ist, dass eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster bereits für ein früheres Textmuster bereitgestellt worden ist.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass das wenigstens eine Datenpaket eine Vielzahl von Textmustern und Textmuster-Formatbeschreibungen umfasst.
Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass der Header eines Datenpaketes wenigstens eine Muster-Kennung und wenigstens eine Textmuster-Formatbeschreibung umfasst, wenn festgestellt worden ist, dass eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster noch nicht für ein früheres Textmuster bereitgestellt worden ist.
Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass der Header eines Datenpaketes wenigstens eine Kennung umfasst, wenn festgestellt worden ist, dass eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster bereits für ein früheres Textmuster bereitgestellt worden ist.
Verfahren nach einem der Ansprüche 1 bis 10, wobei das wenigstens eine Datenpaket einen Header und einen Nutzdatenabschnitt umfasst.
Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass der Nutzdatenabschnitt wenigstens eine Muster-Kennung und wenigstens ein Textmuster umfasst.
Verfahren nach einem der Ansprüche 4 bis 14, dadurch gekennzeichnet, dass der Schritt des Feststellen, ob eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster bereits für ein früheres Textmuster bereitgestellt worden ist, auf den geführten Informationen basiert.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass eine vorgegebene Anzahl von Kennungen verwendet wird, und eine Muster-Kennung für die Bereitstellung einer neuen Textmuster-Formatbeschreibung und des entsprechenden Textmusters für den mobilen Client (101) wiederverwendet wird, wenn festgestellt worden ist, dass eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster für ein früheres Textmuster noch nicht bereitgestellt worden ist, und wenn alle verfügbaren Kennungen für das Mapping von Textmustern auf Textmuster-Formatbeschreibungen verwendet werden.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die geführten Informationen über bereitgestellte Textmuster-Formatbeschreibungen bei Wiederverwendung einer Kennung aktualisiert werden.
Verfahren nach einem der Ansprüche 16 oder 18, dadurch gekennzeichnet, dass die geführten Informationen des Weiteren einen Zeitstempel für jede Muster-Kennung umfassen, der die letzte Einfügung der Muster-Kennung in ein gesendetes Datenpaket anzeigt.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass es des Weiteren den Schritt des Wiederverwendens der Muster-Kennung mit dem frühesten Zeit stempel für das Senden einer neuen Textmuster-Formatbeschreibung zu dem mobilen Client (101) umfasst.
Verfahren nach einem der Ansprüche 1 bis 18, dadurch gekennzeichnet, dass das wenigstens eine Datenpaket nur wenigstens eine Textmuster-Formatbeschreibung umfasst.
Streaming-Server (100), der formatierten Text zu einem mobilen Client (101) über ein Mobilkommunikationssystem (102) unter Verwendung des RTP-Protokolls sendet, wobei der formatierte Text eine Vielzahl von Textmustern umfasst, die mit wenigstens einer Textmuster-Formatbeschreibung verknüpft sind, die wenigstens eine Textmuster-Formatbeschreibung durch Inband-Signalisierung zu dem Client (101) übertragen wird und der Streaming-Server (100) umfasst: eine Paketherstellungseinrichtung, die wenigstens eine Datenpaket herstellt, eine Verarbeitungseinrichtung, die feststellt, ob eine Textmuster-Formatbeschreibung, die mit einem zu sendenden Textmuster verknüpft ist, dem Client (101) bereits für ein anderes früheres Textmuster in dem wenigstens einen Datenpaket bereitgestellt worden ist, und wobei die Paketherstellungseinrichtung so eingerichtet ist, dass sie das zu sendende Textmuster zu wenigstens einem zu sendenden Datenpaket hinzufügt, wenn die Verarbeitungseinrichtung festgestellt hat, dass eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster bereits für ein früheres Textmuster in dem wenigstens einen zu sendenden Datenpaket bereitgestellt worden ist, und eine Sendeeinrichtung, die das wenigstens eine Datenpaket zu dem mobilen Client (101) sendet, dadurch gekennzeichnet, dass die Verarbeitungseinrichtung so eingerichtet ist, dass sie feststellt, ob eine Textmuster-Formatbeschreibung, die mit einem zu sendenden Textmuster verknüpft ist, dem Client (101) bereits für ein anderes früheres Textmuster in wenigstens einem gesendeten Datenpaket bereitgestellt worden ist, die Paketherstellungseinrichtung so eingerichtet ist, dass sie das zu sendende Textmuster zu wenigstens einem zu sendenden Datenpaket hinzufügt, wenn die Verarbeitungseinrichtung festgestellt hat, dass eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster bereits für ein früheres Textmuster in dem wenigstens einen gesendeten Datenpaket bereitgestellt worden ist, und die Paketherstellungseinrichtung so eingerichtet ist, dass sie das zu sendende Textmuster und die damit verknüpfte Textmuster-Formatbeschreibung zu wenigstens einem zu sendenden Datenpaket hinzufügt, wenn die Verarbeitungseinrichtung festgestellt hat, dass eine Textmuster-Formatbeschreibung für ein zu sendendes Textmuster noch nicht für ein früheres Textmuster in dem wenigstens einen gesendeten Datenpaket bereitgestellt worden ist.
Streaming-Server (100) nach Anspruch 22, dadurch gekennzeichnet, dass der Streaming-Server (100) so eingerichtet ist, dass er das Verfahren nach einem der Ansprüche 1 bis 20 durchführt.
Verfahren zum Betreiben eines mobilen Client (101) in einem Mobilkommunikationssystem (102) zum Empfangen von formatiertem Text von einem Streaming-Server (100) unter Verwendung des RTP-Protokolls, wobei der formatierte Text eine Vielzahl von Textmustern umfasst, die mit wenigstens einer Textmuster-Formatbeschreibung verknüpft sind, und das Verfahren die folgenden Schritte umfasst: Empfangen eines Datenpaketes von dem Streaming-Server (100), wobei das Datenpaket wenigstens ein Textmuster umfasst, Feststellen, ob für ein jeweiliges des wenigstens einen Textmusters das Datenpaket des Weiteren eine verknüpfte Textmuster-Formatbeschreibung umfasst, wenn das Datenpaket die mit dem jeweiligen einen des wenigstens einen Textmusters verknüpfte Textmuster-Formatbeschreibung umfasst, Auswählen der verknüpf ten Textmuster-Formatbeschreibung für das jeweilige Textmuster, das in dem Datenpaket enthalten ist, und Formatieren des jeweiligen Textmusters unter Verwendung der ausgewählten Textmuster-Formatbeschreibung, dadurch gekennzeichnet, dass wenn das Datenpaket nicht die mit dem jeweiligen einen des wenigstens einen Textmusters verknüpfte Textmuster-Formatbeschreibung umfasst, Feststellen, ob für das jeweilige eine des wenigstens einen Textmusters eine verknüpfte Textmuster-Formatbeschreibung in einem früher empfangenen Datenpaket enthalten gewesen ist, und wenn die mit dem jeweiligen einen des wenigstens einen Textmusters verknüpfte Textmuster-Formatbeschreibung in dem früher empfangenen Datenpaket enthalten gewesen ist, Auswählen einer Textmuster-Formatbeschreibung für das jeweilige Textmuster aus den Textmuster-Formatbeschreibungen, die bei dem mobilen Client (101) bereits von dem früher empfangenen Datenpaket verfügbar ist.
Verfahren nach Anspruch 23, dadurch gekennzeichnet, dass das wenigstens eine Datenpaket des Weiteren wenigstens eine Muster-Kennung umfasst, die wenigstens ein Textmuster auf der damit verknüpften Textmuster-Formatbeschreibung abbildet.
Verfahren nach Anspruch 24, dadurch gekennzeichnet, dass es des Weiteren den Schritt des Führens von Informationen über die in empfangenen Datenpaketen bereitgestellten Textmuster-Formatbeschreibungen umfasst.
Verfahren nach Anspruch 25, dadurch gekennzeichnet, dass die geführten Informationen Daten über die bereitgestellte wenigstens eine Textmuster-Formatbeschreibung und ihre wenigstens eine Kennung umfassen.
Verfahren nach einem der Ansprüche 23 bis 26, dadurch gekennzeichnet, dass in dem Schritt des Auswählens der verknüpften Textmuster-Formatbeschreibung für ein Textmuster die Muster-Kennung, die mit dem Textmuster verknüpft ist, verwendet wird, um die verknüpfte Textmuster-Formatbeschreibung aus dem wenigstens einen Datenpaket oder aus Textmuster-Formatbeschreibungen, die bereits an dem mobilen Client (101) verfügbar sind, zu identifizieren und auszuwählen.
Verfahren nach einem der Ansprüche 23 bis 27, dadurch gekennzeichnet, dass es des Weiteren den Schritt des Aktualisierens der geführten Informationen auf Basis einer neuen Textmuster-Formatbeschreibung umfasst, wenn das wenigstens eine Datenpaket die neue Textmuster-Formatbeschreibung umfasst, die mit einer Muster-Kennung verknüpft ist, die bereits mit einer anderen Textmuster-Formatbeschreibung in den geführten Informationen verknüpft ist.
Verfahren nach einem der Ansprüche 23 bis 28, dadurch gekennzeichnet, dass es des Weiteren den Schritt des Sendens einer Quittung für das wenigstens eine empfangene Datenpaket zu dem Streaming-Server (100) umfasst.
Verfahren nach einem der Ansprüche 23 bis 29, dadurch gekennzeichnet, dass ein durch den mobilen Client (101) empfangenes Datenpaket nur wenigstens eine Textmuster-Formatbeschreibung umfasst, und wobei das Verfahren des Weiteren Speichern der wenigstens einen empfangenen Textmuster-Formatbeschreibung umfasst.
Mobiler Client (101) zum Empfangen von formatiertem Text von einem Streaming-Server (100) unter Verwendung des RTP-Protokolls, wobei der formatierte Text eine Vielzahl von Textmustern umfasst, die mit wenigstens einer Textmuster-Formatbeschreibung verknüpft sind, die wenigstens eine Textmuster-Formatbeschreibung durch Inband-Signalisierung zu dem Client (101) übertragen wird und der mobile Client (101) umfasst: eine Empfangseinrichtung, die ein Datenpaket von dem Streaming-Server (100) empfängt, wobei das Datenpaket wenigstens ein Textmuster umfasst, eine Verarbeitungseinrichtung, die feststellt, ob für ein jeweiliges des wenigstens einen Textmusters das Datenpaket des Weiteren eine verknüpfte Textmuster-Formatbeschreibung umfasst, eine Auswähleinrichtung, die die verknüpfte Textmuster-Formatbeschreibung für das jeweilige Textmuster auswählt, das in dem wenigstens einen Datenpaket enthalten ist, wenn festgestellt wird, dass für das jeweilige eine des wenigstens einen Textmusters das Datenpaket des Weiteren die verknüpfte Textmuster-Formatbeschreibung umfasst, und eine Textformatiereinrichtung, die das jeweilige Textmuster unter Verwendung der ausgewählten Textmuster-Formatbeschreibung formatiert, dadurch gekennzeichnet, dass die Verarbeitungseinrichtung so eingerichtet ist, dass sie feststellt, ob für das jeweilige des wenigstens einen Textmusters die verknüpfte Textmuster-Formatbeschreibung in einem früher empfangenen Datenpaket enthalten gewesen ist, wenn festgestellt wird, dass für das jeweilige eine des wenigstens einen Textmusters das Datenpaket des Weiteren nicht die verknüpfte Textmuster-Formatbeschreibung umfasst, und die Auswähleinrichtung so eingerichtet ist, dass sie die verknüpfte Textmuster-Formatbeschreibung für das jeweilige Textmuster auswählt, das in dem früher empfangenen Datenpaket enthalten ist, wenn festgestellt wird, dass für das jeweilige eine des wenigstens einen Textmusters das früher empfangene Datenpaket die verknüpfte Textmuster-Formatbeschreibung umfasst.
Mobiler Client (101) nach Anspruch 31, dadurch gekennzeichnet, dass der mobile Client (101) zum Durchführen des Verfahrens nach einem der Ansprüche 23 bis 30 eingerichtet ist.
Streaming-System, das wenigstens einen Streaming-Server (100) nach Anspruch 21 oder 22 und wenigstens einen mobilen Client (101) nach Anspruch 31 oder 32 umfasst.