-
Die vorliegende Erfindung betrifft ein Verfahren zur mobilen
Datenübertragung, insbesondere ein Verfahren zur Übertragung
multimedialer Daten auf ein mobiles Teilnehmer-Endgerät, ein
Computerprogrammerzeugnis und ein Kommunikationssystem.
-
Verfahren und Vorrichtungen zur mobilen Übertragung
verschiedener Formen oder Formate von Daten sind bekannt. Dabei wird
unter dem Begriff der Daten im Rahmen der vorliegenden
Erfindung auch jede Art von Information verstanden, die aus
einzelnen Bestandteilen zusammengesetzt ist. Diese einzelnen
Bestandteile oder Elemente können dabei nach unterschiedlichen
Standards aufgebaut, organisiert und/oder codiert sein.
Demnach können in diesem Sinne Daten auch eine multimediale
Nachricht darstellen, die diverse Elemente verschiedener
Standards umfaßt. Unter dem Begriff einer mobilen Übertragung
wird im Weiteren eine Übertragung verstanden, die auch eine
Übertragung von Daten von und/oder an mindestens einen
mobilen Teilnehmer zuläßt.
-
Ein Mobilfunksystem nach dem Global System for Mobile
Communications Standard, kurz GSM, bietet beispielsweise neben der
Sprachtelephonie auch die Möglichkeit, Information in Form
kurzer Textnachrichten von bis zu 160 Zeichen Länge zu
versenden bzw. zu empfangen. Dieser Dienst wird als Short
Message Service bezeichnet, kurz SMS.
-
Für das Mobilfunksystem der nächsten Generation, das
Universal Mobile Telecommunication System UMTS, wird zur Zeit eine
multimediafähige Variante eines mobilen Nachrichtendienstes
standardisiert, der so genannte Multimedia Messaging Service
MMS, siehe 3GPP TS 23.140 version 4.1.0, Release 4; 3rd
Generation Partnership Project; Technical Specification Group
Terminals; Multimedia Messaging Service (MMS); Functional
Description; Stage 2 und 3GPP TS 22.140 v.4.0.1 (Juli 2000),
3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; Service Aspects; Stage 1
Multimedia Messaging Service.
-
Informationen als Nachrichten mit multimedialen Inhalten
werden im Folgenden zur besseren Abgrenzung von den
Textnachrichten des SMS nur noch als Multimedianachricht bzw.
Multimedia Message bezeichnet, kurz mm. Im Gegensatz zu dem SMS
entfällt bei dem Multimedia Message Service MMS die
Beschränkung auf reine Textinhalte. In einem MMS wird es auch möglich
sein, Texte dem individuellen Geschmack entsprechend zu
formatieren, sowie beliebige Inhalte in eine Nachricht
einzubetten. Dazu zählen z. B. Audio- und Videoinhalte, Standbilder,
Grafiken, Texte, u. a.. Die nachfolgend offenbarte Lehre
bezieht sich generell auf Datenmengen, die aus einzelnen
Elementen von Text- und/oder Bilddaten mit oder ohne Ton
zusammengesetzt und jeweils nach gleichen oder unterschiedlichen
Standards codiert sind, auch wenn in Anwendungen nach dem
vorstehend genannten Standard ein wesentliches Einsatzfeld
für die vorliegende Erfindung zu sehen ist.
-
Nach dem bisherigen Stand der Technik ist eine
Implementierung von MMS lediglich über das Wireless Application Protocol
WAP realisierbar. Zur Überbrückung der Luftschnittstelle
zwischen einem MMS-tauglichen Endgerät und dem WAP Gateway ist
die Benutzung des WAP Wireless Session Protocol WSP
vorgesehen, siehe WAP-209-MMS Encapsulation, Wireless Application
Protocol; WAP Multimedia Messaging Service; Message
Encapsulation; MMS Approved version, June 2001 und 3GPP TS 23.140
version 4.3.0, Release 4, June 2001; 3rd Generation
Partnership Project; Technical Specification Group Terminals;
Multimedia Messaging Service (MMS); Functional Description; Stage
2.
-
Eine MM umfaßt in der Regel mehrere Teile mit in weiten
Grenzen frei definierbarem Inhalt, der sich aus diversen Formaten
zusammensetzen kann. Dabei besteht eine mm grundsätzlich aus
einem Kopfteil und einem Datenteil. Der Kopfteil bzw. Header
setzt sich aus definierten Kopf-Feldern zusammen und enthält
allgemeine Informationen zur mm. Der Datenteil einer mm kann
ein oder mehrere Elemente unterschiedlicher Datentypen und
Datenformate in beliebiger Reihenfolge enthalten.
-
Zur Übertragung sind ein Sender und ein gewünschter Empfänger
miteinander über eine Netzstruktur verbunden, wobei die
Teilnehmer-Endgeräte jeweils über Luftschnittstellen mit einer
senderseitigen und einer empfängerseitigen Netzwerkeinheit
verbunden sind. Die Netzwerkeinheiten selber sind jedoch zur
Datenübertragung miteinander über ein Festnetz verbunden, das
nach einem Internet-Protokoll organisiert ist. Durch den
Wechsel von der Übertragung via Luftschnittstelle mit binärer
Codierung auf eine Festnetzverbindung mit textueller
Codierung ist eine Umcodierung erforderlich. Besondere Bedeutung
kommt in diesem Zusammenhang der Umcodierung der Kopf-Felder
zu. Sie fungieren als Steuerelemente zur Datenorganisation
innerhalb einer mm und müssen zur Strukturanpassung an das
IP-Netz eMail-artig aufgebaut sein. Ohne Kenntnis der Kopf-
Felder ist ein angehängter Datenteil nicht mehr zu
verarbeiten.
-
Wie bereits aus dem EDV-Bereich bekannt kommen fast ständig
neue Datenformate auf, deren Bezeichnung, Erkennung und/oder
Verarbeitung und Umcodierung eine fortlaufende Erneuerung
bzw. ein Update des Systems erfordert. Da in naher Zukunft
noch mehr verschiedenartige Teilnehmer-Endgeräte mindestens
teilweise miteinander über Mobilfunknetze kommunizieren
werden ist mit einer großen Zahl verschiedenster neuer
Codierungen und Kennzeichnungen zu rechnen. Bei einem Verfahren zur
mobilen Datenübertragung und einem dementsprechenden
Kommunikationssystem gestaltet sich eine derartige fortlaufende
Erneuerung u. a. aufgrund der Vielzahl der Netzwerkeinheiten als
fast unmöglich durchführbar.
-
Nach dem Stand der Technik wird für den MMS speziell in der
Spezifikation WAP 209 - MMS Encapsulation, Approved version,
eine binäre Codierung der Headerfelder festgelegt, d. h.
explizit eine binäre Codierung der Headerfeldnamen,
Headerfeldwerte und eventuelle Parameter. Die Art der Codierung basiert
auf der im "Wireless Session Protocol", WSP, WAP-203 Wireless
Session Protocol, definierten Codierung, bei der für die
definierten Headerfeldnamen und Headerfeldwerte jeweils ein
binärer Code in Form eines 8-Bit-Wertes bzw. eines Octets
festgelegt wird. Mit diesen Werten können die Header codiert und
decodiert werden. Die binäre Codierung wird zwischen der MMS
Verbindungseinheit und der MMS Nutzeranwendung bzw. MMS
Client verwendet, d. h. sie wird z. B. in einem Mobilfunksystem
auf der Luftschnittstelle eingesetzt. Zusätzlich sind auch
Mechanismen zur textuellen Codierung weiterer Headerfelder
spezifiziert, die kompatibel zu Internet Email gemäß RFC822
sind.
-
Vom 3rd Generation Partnership Project 3GPP ist in der
Technical Specification 23.140 v4.3.0, Rel-4: Multimedia
Messaging Service; Functional Description; Stage 2 für die
Darstellung von Multimedianachrichten die zwischen MMS-
Verbindungseinheiten bzw. MMS Proxy/Relay-Stationen in dem
Netzwerk ausgetauscht werden die textuelle Codierung der
Nachrichten im MIME-Format vorgeschrieben. Diese Vorschrift
ist in der RFC 2045-RFC 2049 als Erweiterung der RFC822
niedergelegt.
-
Nur wenn alle an einer Übertragung der Multimedianachricht
beteiligten Einrichtungen, d. h. alle beteiligten
MMS-Verbindungseinheiten und MMS-Nutzeranwendungen, dieselbe Version
implementieren, ist die Kommunikation zwischen den Einheiten
problemlos möglich. Falls jedoch unterschiedliche Versionen
der Spezifikationen implementiert sind, kann es z. B. dazu
kommen, daß eine Einheit eine Nachricht mit unbekannten
binären Codes empfängt. Soll die empfangene Nachricht in die
textuelle Form umgewandelt werden, treten Probleme auf, da die
textuelle Codierung des binären Codes nicht bekannt ist. Die
Umwandlung des binären Codes ist in einem solchen Fall nicht
möglich. Die empfangende Einheit hat dann lediglich die
Optionen, den unbekannten Code zu ignorieren oder die
Transformation nicht auszuführen und statt dessen der sendenden Einheit
mit einer Fehlermeldung zu antworten. Eine Weiterleitung der
Nachricht in textueller Form inklusive der mit binären Codes
dargestellten Informationen des Datenteils ist nicht möglich.
-
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein
Verfahren zur mobilen Übertragung multimedialer Daten, ein
Computerprogrammerzeugnis und ein Kommunikationssystem
vorzuschlagen, in denen auch unbekannte Codes ohne systembedingte
Übertragungsprobleme und insbesondere vorwärtskompatibel
verarbeitet werden können.
-
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren mit
den Merkmalen des Anspruchs 1 gelöst. Ferner sind ein
Kommunikationssystem mit den Merkmalen des Anspruchs 9 und ein
Computerprogrammerzeugnis mit den Merkmalen von Anspruch 10
Lösungen dieser Aufgabe. Die Unteransprüche definieren
jeweils bevorzugte und vorteilhafte Ausführungsformen der
vorliegenden Erfindung.
-
Ein erfindungsgemäßes Verfahren zeichnet sich dadurch aus,
daß Daten in einer Netzwerkeinheit zwischen einer binären
Darstellung und einer textuellen Darstellung von Information
umgewandelt werden, indem Elemente der Daten, die ein
unbekanntes Code-Wort beinhalten, markiert übertragen werden. Die
Markierung erfolgt in einem senderseitigen MMS-Proxy/Relay
und schützt ein unbekanntes Code-Wort vor einer
Fehlinterpretation durch den empfängerseitigen MMS-Proxy/Relay,
insbesondere vor einer Interpretation als Übertragungsfehler.
-
Ein markiertes unbekanntes Code-Wort wird vorteilhafterweise
unverändert übertragen. Ein unbekanntes Code-Wort kann als
Daten ein Kopf-Feld multimedialer Daten umfassen, die
erfindungsgemäß umcodiert werden. Ein Kopf-Feld einer
multimedialen Nachricht besteht dabei aus einem Feldnamen und einem
Feldwert. Zur Übertragung und erfindungsgemäßen Codierung
eines unbekannten Feldwertes wird in einer Weiterbildung der
Erfindung in eine textuelle Form ein Schlüsselwort eingefügt.
Der resultierende Code enthält dann den unbekannten binären
Code als zusätzlichen Parameter. Bei der Codierung eines
unbekannten Namens eines Kopf-Feldes in eine textuelle Form
wird hingegen vorteilhaft ein Schlüsselwort als neuer
Headerfeldname verwendet. So sind in einfacher Weise auch ein
unbekannter Kopf-Feldname und ein zugehöriger, ebenfalls
unbekannter Feldwert sicher zu codieren und zu übertragen, wobei
die Umcodierung kompatibel insbesondere zu einem MIME-Format
ausgeführt wird.
-
In einer Ausführungsform der Erfindung wird bei der Codierung
eines Feldwertes in eine textuelle Form der Text
"UnknownBinaryValue" als Schlüsselwort verwendet. In der Struktur dazu
passend wird bei der Codierung eines Namens eines Kopf-Feldes
in eine textuelle Form vorzugsweise der Text "X-Mms-
UnknownHeaderFieldName" als Schlüsselwort verwendet.
-
So ist in einfacher Weise ein Kommunikationssystem in
Anpassung auf heutige Standards aufzubauen und/oder zu erweitern,
in dem die Netzwerkeinheiten zur Umsetzung eines Verfahrens
mit einem oder mehreren der vorhergehenden Merkmale
ausgebildet sind. Ein erfindungsgemäß erweitertes Verfahren kann
dabei in Form eines Computerprogrammerzeugnisses sehr schnell
und ökonomisch vertrieben werden. Das
Computerprogrammerzeugnis umfaßt dann insbesondere ein computerlesbares
Speichermedium, auf dem ein entsprechendes Programm gespeichert ist.
Das Programm ermöglicht es wiederum einer
Datenverarbeitungsanlage nach dem Laden in einen Speicher in einem
angeschlossenen Kommunikationssystem und insbesondere einem
Mobilfunknetz an den zu übertragenden Daten eine Umcodierung der
vorstehend beschriebenen Art zu veranlassen.
-
Die Erfindung löst das Problem also insgesamt durch eine
kompatible Codierung der in einer Netzwerkeinheit unbekannten
binären Codes in den textuellen Header-Feldern des MIME-
Formates. Diese Lösung ist mit den angewendeten Standards in
der Struktur verträglich und erfordert einen erfreulich
geringen Aufwand.
-
Die Codierung erfolgt nach den nachstehend zu
Ausführungsbeispielen der Erfindung beschriebenen Mechanismen. Dabei ist
entscheidend, daß die Codierungsmechanismen von WAP MMS es
gestatten, auch unbekannte, binär codierte Headerfeldtypen
aus einer Nachricht zu extrahieren. Der Feldname wird mit
einem Octet, d. h. einem 8-Bit-Wert codiert. Der Feldwert wird
entweder mit einem einzigen Octet oder mit einem Text, der
mit dem Octet "00" abgeschlossen sein muß, oder mit einem
anderen Typ codiert, der dann mit einer Längenangabe beginnen
muß. Dadurch ist sichergestellt, daß ein beliebiges Feld in
seinen Namen und seinen Wert zerlegt werden kann, ohne daß
der Typ des Feldes oder die Struktur des Wertes dem Decoder
bekannt sein müssen. Somit wird nachfolgend anhand von
Ausführungsbeispielen eine strukturverträgliche Umcodierung der
Kopf-Felder zur Einbettung der unverändert binären
Datenkörper in ein IP Netz vorgestellt.
-
Die vorliegende Erfindung wird nachfolgend unter Bezugnahme
auf die beigefügte Zeichnung anhand eines bevorzugten
Ausführungsbeispiels erläutert. Die einzige Abbildung der Zeichnung
zeigt ein vereinfachtes Blockschaltbild zur Realisierung
einer bekannten Übertragung multimedialer Daten von einem
mobilen Sender A zu einem mobilen Empfänger B.
-
Die Figur stellt ein WAP MMS Transaction Flow Diagramm als
schematische Abbildung von einer Datenübertragung mit
zugeordneten Sendungen gemäß dem Wireless Application Protocol
bzw. WAP-Standard zwischen verschiedenen Ebenen dar. Das im
folgenden zugrunde gelegte Kommunikationssystem 1 umfaßt
mindestens drei Ebenen, nämlich eine Ebene 2 als Ebene eines
Senders der Daten bzw. mm, eine Provider-Ebene 3 und eine
Ebene 4 eines Empfängers, der die mm auf einem Teilnehmer-
Endgerät 5 bzw. als MMS Client bezeichneten
Telekommunikationsgerät aufbereitet erhält. Die Provider-Ebene 3 ist hier in
zwei Ebenen aufgespalten worden, um zwischen einem für den
Versender A zuständigen MMS Proxy/Relay A und einem für den
Empfänger B zuständigen MMS Proxy/Relay B unterscheiden zu
können. Diese beiden MMS Proxy/Relays sind miteinander über
ein IP Netz nach einem Internet-Protokoll verbunden, in dem
zur reinen Übertragung der mm und der dargestellten Rückdaten
eine Umcodierung der Header-Felder von binärer in textuelle
Codierung vorgenommen wird, was für den Gegenstand der
vorliegenden Erfindung von wesentlichem Belang ist und
anschließend im Detail ausgeführt wird.
-
In dem Ausführungsbeispiel ist die Anwendung der Erfindung
auf ein Kommunikationssystem 1 für den WAP-Standard
beschrieben, wie es in der Übertragung von multimedialen Daten in dem
Universal Mobile Telecommunication System UMTS, Verwendung
finden wird. Es versteht sich, daß die Erfindung auch auf
andere Standards übertragbar ist. Insbesondere sind hier auch
gemischte Kommunikationssysteme gemeint, die neben
Mobilfunkstrecken auch Festnetzverbindungen o. ä. umfassen.
-
Wie bereits eingangs beschrieben ist im UMTS-Standard
vorgesehen, zusätzlich zum bisherigen Short Message Service SMS
einen sogenannten Multimedia Messaging Service MMS für die
Übertragung komplexer Nachrichten, den Multimedia messages
MMs, vorzusehen. Damit können auch formatierte Texte und
Bilder mit und ohne Ton übertragen werden. Die im SMS vorhandene
Beschränkung auf eine Nachrichtenlänge von 160 Zeichen
entfällt. Eine Übertragung u. a. von mehrteiligen und/oder
miteinander gekoppelten Audio- und Videonachrichten ist möglich.
MMS ist über die Nutzung von WAP realisierbar.
-
Das Kommunikationssystem 1 umfaßt die Ebene 2 des
Datenversenders, auch als MMS Client A bezeichnet. Weiter ist die
Ebene 3 eines Providers vorgesehen, dessen Netzelement den
Service ausführt und nachfolgend als senderseitige MMS-
Verbindungseinheit bzw. MMS Proxy/Relay A bezeichnet wird.
Schließlich ist die Ebene 4 als die Ebene des Empfängers B
vorgesehen, der als MMS Client B bezeichnet ist.
Selbstverständlich ist es möglich, daß in der Ebene 3 auch mehrere
Provider auftreten. Das ist beispielsweise dadurch möglich,
daß der Datenversender A und der gewählte Empfänger B
unterschiedliche Provider nutzen. Zudem können diese
unterschiedlichen Provider noch durch dritte Provider als Netzbetreiber
des IP-Netzes miteinander verbunden sein.
-
Ein Austausch der WAP Messages ist zwischen vier beteiligten
Instanzen, MMS Client A, MMS Proxy/Relay A, MMS Proxy/Relay B
und MMS Client B, bei Versand bzw. Empfang einer mm in der
Abbildung der Figur dargestellt. Unter MMS Client versteht
man eine Applikation auf einem Teilnehmer-Endgerät, das die
MMS-Funktionalität realisiert. Ein MMS Proxy/Relay ist ein
Netzelement bei einem MMS Service Provider, das den MMS
Clients die MMS-Funktionalität zur Verfügung stellt. Die
Ebene 2 des Datenversenders umfaßt mindestens ein Teilnehmer-
Endgerät oder Telekommunikationsgerät 5, ebenso umfaßt auch
die Ebene 4 des Empfängers ein Teilnehmer-Endgerät oder
Telekommunikationsgerät 6. Diese Telekommunikationsgeräte 5, 6
können beispielsweise als übliche Handies oder als Geräte mit
weiteren Eingabe- oder Anzeigefunktionen, wie etwa Laptops,
ausgebildet sein.
-
Es wird nun die Abfolge einzelner Signale in dem vorstehend
beschriebenen Kommunikationssystem 1 erläutert, die zum
Versenden einer mm von MMS Client A über den MMS Proxy/Relay
A und MMS Proxy/Relay B hin zum MMS Client B im PULL-Modus
notwendig ist:
-
Eine in dem Telekommunikationsgerät 5 des Versenders verfaßte
oder über dieses weiterzuleitende Multimedia message mm kann
ein oder mehrere Elemente oder Datensätze enthalten,
beispielsweise einzelne Bilder, Filmsequenzen, Texte oder
ähnliches. Die mm wird zunächst als Anfrage-Sendung, die im WAP-
Protokoll den Namen M-Send.req trägt, von der Ebene 2 an den
Provider MMS Proxy/Relay A in der Ebene 3 versandt. Von dort
wird die eingegangene Sendung mit einer Rücksendung M-
send.confan den Versender der Ebene 2 quittiert.
-
Über ein IP-Netzwerk wird die Nachricht mm von MMS
Proxy/Relay A an MMS Proxy/Relay B versandt, wobei auch eine
Umcodierung der Nachricht mm erfolgt. In dem IP-Netzwerk wird
in diesem Ausführungsbeispiel nach dem Simple Mail Transfer
Protocol SMTP gearbeitet, das eine eMail-artige
Datenorganisation verlangt bzw. eine textuelle Codierung der Kopf-Felder
voraussetzt. Diese Voraussetzung gilt im übrigen für alle im
Zuge des MM-Versandes auftretende Nachrichten und
Benachrichtigungen, auch wenn sie nur WAP-intern sein sollten.
-
Der MMS Service Provider des Empfängers B hat im allgemeinen
Kenntnis darüber, welche Medientypen, z. B. Standbild, und
Medienformate, z. B. JPEG, das MMS Client B des Empfängers B
verarbeiten bzw. darstellen kann. Derartige Informationen
werden während einer Anmeldung eines MMS Clients B bei dem
zuständigen MMS Service Provider ausgetauscht und in dessen
Zuständigkeitsbereich, dem Multimedia Messaging Service
Environment MMSE, gespeichert. Wenn ein MMS Service Provider eine
mm erhält, bestehend aus einem Element von einem Medientyp
oder Medienformat, den bzw. das der adressierte MMS Client B
nicht zu verarbeiten und/oder wiederzugeben in der Lage ist,
kann eine Transcodierung bzw. Konvertierung eines Datei-Typs
oder Datei-Formates vor der Auslieferung dieser mm im MMSE
des MMS Service Providers des Empfängers B stattfinden.
Zeitlich darauffolgend wird von dem Provider MMS Proxy/Relay B
eine Information M-Notification.ind an den Empfänger MMS
Client B in Ebene 4 gesandt, mit der dieser darüber
informiert wird, daß für ihn eine Nachricht beim Provider MMS
Proxy/Relay B zum Herunterladen bereitliegt.
-
Hierüber erhält der Provider MMS Proxy/Relay B hier
automatisch eine quittierende Rückmeldung M-NotifyResp.req von dem
Telekommunikationsgerät 6 des Empfängers B aus Ebene 4 hin
zur Ebene 3 zurückgesendet. Erst auf Anforderung durch den
Empfänger B mit einer Sendung WSP-GET wird von dem Provider
MMS Proxy/Relay B die mm mit einer Sendung M-Retrieve.conf an
den Empfänger MMS Client B weitergeleitet. Eine Nachricht M-
Acknowledge.ind quittiert den Empfang der mm in der Ebene 4.
Eine abschließende Nachricht M-Delivery.ind gibt eine
Empfangsbestätigung von der Ebene 3 an den Versender MMS Client
A in Ebene 2 zurück.
-
Zur Verwaltung der vorstehend genannten Sendungen dienen sog.
Kopf- oder Header-Felder, also den einzelnen Elementen der mm
vorangestellte Felder, in denen Informationen über die
Herkunft, Sendezeit, Dateiformat, Dateigröße und weitere Details
enthalten sein können, die den MMS-Proxy/Relays nicht alle
bekannt sein müssen oder bekannt sein können, weil sie neu
eingeführt worden sind. Um nicht als Übertragungsfehler oder
sonstiger Fehler behandelt und folglich nicht oder nicht
korrekt übertragen zu werden sind gemäß vorliegender Erfindung
verschiedene Maßnahmen vorgesehen, die nun anhand zweier
Ausführungsformen dargestellt und diskutiert werden:
1. Codierung unbekannter Headerfeldwerte
-
Unbekannte Headerfeldwerte werden erfindungsgemäß in
textueller Form codiert, indem ein Schlüsselwort als Headerfeldwert
eingefügt wird, das den unbekannten binären Code als
zusätzlichen Parameter enthält. Als Beispiel dient das Headerfeld
X-Mms-Status: Forwarded
das in binärer WAP Codierung z. B. in hexadezimaler
Darstellung als 95 85 darstellbar wäre. Dabei ist 95 der
hexadezimale Wert für den bekannten Feldnamen und 85 der Wert für den
in der Version 1.0 der WAP MMS Message Encapsulation noch
nicht enthaltenen Statuswert "Forwarded". Wird nun dieses
Headerfeld in binärer Form z. B. von einer Netzwerkeinheit
empfangen, d. h. es kommt der Code hexadezimal 95 85 an, kann
die empfangende Einheit den Wert 85 nicht in den
entsprechenden Text umwandeln, weil dieser nicht bekannt ist.
-
Eine textuelle Codierung dieser Information kann nun
erfindungsgemäß folgendermaßen ausgeführt werden:
X-Mms-Status: UnknownBinaryValue = 85
-
Durch das Schlüsselwort "UnknownBinaryValue" wird der
unbekannte binäre Wert angekündigt, der dann dem
Gleichheitszeichen folgt. Die Codierung nach dem vorliegenden Schema kann
auch von einer Einheit vorgenommen werden, die den Statuswert
85, nämlich in diesem Beispiel das Wort "Forwarded", nicht
kennt.
-
Aus der hier vorgeschlagenen textuellen Darstellung ist in
einer nächsten Einheit eine Rückkonvertierung in die binäre
Darstellung problemlos möglich. Es muß lediglich die Syntax
der binären Codierung befolgt werden und der Wert 85
verwendet werden. Damit können auch MMS-
Netzwerkverbindungseinheiten bzw. MMS Proxy/Relay Stationen für den Transport der
ihnen unbekannten binären Codes verwendet werden.
2. Codierung unbekannter Headerfeldnamen und Headerfeldwerte
-
Unbekannte Headerfeldnamen und -werte werden erfindungsgemäß
in textueller Form codiert, indem ein Schlüsselwort als neuer
Headerfeldname verwendet wird. Da unbekannte Headerfelder
auch nur unbekannte Headerfeldwerte enthalten können, werden
auch diese wie oben beschrieben durch ein Schlüsselwort
codiert, dem der unbekannte binäre Code als zusätzlicher
Parameter folgt. Als Beispiel dient das Headerfeld
X-Mms-UnknownHeaderFieldName: Unknown-Value
-
In binärer WAP Codierung könnte dieses Feld z. B. mit den
Werten C0 80 hexadezimal dargestellt werden. Dabei ist C0 der
hexadezimale Wert für den unbekannten Feldnamen "X-Mms-
UnknownHeaderFieldName" und 80 der Wert für den in der
Version 1.0 der WAP MMS Message Encapsulation Spezifikation noch
nicht enthaltenen Wert "Unknown-Value".
-
Nach Erhalt der hexadezimalen Codes C0 80 kann eine Einheit
dieses Headerfeld in textueller Codierung erfindungsgemäß wie
folgt darstellen:
X-Mms-UnknownBinaryFieldName: C0; UnknownBinaryValue = 80
-
Durch das Schlüsselwort "X-Mms-UnknownBinaryFieldName" wird
der unbekannte Headerfeldname angekündigt, der sich dann in
Textform als Wert "C0" anschließt. Der unbekannte binäre
Feldwert wird anschließend als Parameter in demselben Header-
Feld mit dem Schlüsselwort "UnknownBinaryValue" signalisiert.
Es folgt ein Gleichheitszeichen und der binäre Wert an sich.
In diesem Beispiel der textuell dargestellte Wert 0 × 80.
Die Codierung nach dem vorgeschlagenen Schema kann auch von
einer Einheit vorgenommen werden, die den binären Wert für
den Feldnamen 0 × C0 sowie den Feldwert 0 × 80 nicht kennt. Eine
Rückkonvertierung in die binäre Darstellung ist problemlos
möglich. Damit können auch MMS-Netzwerkverbindungseinheiten
für den Transport der ihnen unbekannten binären Codes
verwendet werden.
-
Ein weiteres Beispiel soll die universelle Eignung der
erfindungsgemäß neuen Codierung verdeutlichen:
-
Basis ist noch einmal obiges Beispiel mit einem unbekannten
Feldnamen und einem unbekannten Feldwert nach dem Schema:
X-Mms-UnknownHeaderFieldName: Unknown-Value
-
Diesmal ist der Feldname codiert durch den binären Code D1
und der Feldwert ist ein Text, z. B. "Text", der in binärer
Form codiert folgende hexadezimale Darstellung hat: 54 65 78
74 00. Dies ist die hexadezimale Darstellung der ASCII-Werte
für die Buchstaben. Die abschließende Null, "00" in
hexadezimaler Darstellung, steht als Abschluß der Zeichenkette und
signalisiert damit das Ende des Feldwertes. Erfindungsgemäß
wird dieses Header-Feld dargestellt durch folgendes Textfeld:
X-Mms-UnknownBinaryFieldName: D1; UnknownBinaryValue = 54 65 78 74 00
-
Durch das Schlüsselwort "X-Nms-UnknownBinaryFieldName" wird
der unbekannte Headerfeldname angekündigt, der sich dann in
Textform als Wert "D1" anschließt. Der unbekannte binäre
Feldwert wird anschließend als Parameter in demselben Header-
Feld mit dem Schlüsselwort "UnknownBinaryValue" signalisiert.
Es folgt ein Gleichheitszeichen und der binäre Wert an sich.
In diesem Beispiel die textuell dargestellten hexadezimalen
Werte der ASCII-Zeichen 54 65 78 74 00 inklusive der
abschließenden Null. Wird dieses Header-Feld empfangen, kann es
problemlos in das originale binär codierte Header-Feld
zurückgewandelt werden.
Bezugszeichenliste/Abkürzungsliste
GSM: Global System for Mobile Communication
MM: Multimedianachricht (Multimedia Message)
MMS: Multimedia Messaging Service
SMS: Short Message Service
UMTS: Universal Mobile Telecommunication System
WAP: Wireless Application Protocol
1 Kommunikationssystem
2 Ebene eines Datenversenders
3 Ebene 3 eines Providers
4 Ebene eines Empfängers
5 Teilnehmer-Endgerät / Telekommunikationsgerät
6 Teilnehmer-Endgerät / Telekommunikationsgerät
MMS spezifische Abkürzungen
MMS Client A Sender einer MM
MMS Client B Empfänger einer MM
MMS Proxy/Relay MMS Verbindungseinheit/Provider
M-Send.req MMS Sendeanfrage
M-Send.conf MMS Sendebestätigung
M-Notification.ind MMS Empfängerbenachrichtigung
M-NotifyResp.req MMS Empfängerbenachrichtigungsbestätigung
WSP GET MMS Zustellanfrage
M-Retrieve.conf MMS Zustellnachricht
M-Acknowledge.ind MMS Zustellungsbestätigung
M-Delivery.ind MMS Zustellstatusbenachrichtigung
IP IP Netz, Netz nach einem Internet-Protokoll