Moc krasne, i pres to, ze je to nemecky jsem cosi pochopil, to ze ty
data jsou 7mi bitova mi bylo jasne hned, ale jak lze vysvetlit toto:
Prazdny text
0791246030500200110000810000FF00
to je jasne (zacatek me ani tak moc nezajima)
Text '1'
0791246030500200110000810000FF0131
to je taky docela jasne (i kdyz ne tolik, kdyz to ma byt 8mi bitove
poslana 7mi bitova '1' tak bych si to prestavoval jako '62')
Text '11'
0791246030500200110000810000FF02B118
ale jak tady dostal 'B118' to teda opravdu nevim, ze by to nebylo tak
jednoduche?
Miloslav Kazda
miloslav.kazda@volny.cz
Friday, April 13, 2001, 8:24:22 AM, Jan Pruha wrote:
> Nevim jak to vyleze na druhe strane, ale tady je popis PDU formatu.
> H.
> Kurznachrichten auf die perverse Art
> Leider unterstützen viele Telefone nicht die komfortable Art der Übergabe von
> Textnachrichten im Textmodus, also als Klartext. Als praktischen Ersatz dafür haben die
> Erfinder des mobilen Telefonierens den PDU-Modus geschaffen. Der sieht so aus:
> at+cmgs=17
> > 079194712272000021000C9194711232547600110441E19008
> +CMGS: 37
> OK
> Der Vorteil des Textmode wäre: man kanns lesen. Der Vorteil des PDU-Mode ist: man hat
> volle Kontrolle darüber, was passiert und was nicht. Und wie das geht, das sehen wir
> jetzt.
> Zum generellen Verständnis einiger Merkwürdigkeiten sollte man eines immer im Hinterkopf
> behalten:
> Die Bitanordnung der Hexdarstellung ist wie gewohnt von Bit 7 bis Bit 0 (b7 b6 b5 b4 b3
> b2 b1 b0).
> Die Bits werden aber im Netz beginnend mit Bit 0 übertragen, also quasi von hinten nach
> vorne.
> Dies führt an einigen wesentlichen Stellen, namentlich der Darstellung der Rufnummern
> und der Textdaten, zu recht ungewohnten Betrachtungsweisen.
> Aufbau der PDU zum Nachrichtenversand
> Die an das Telefon zu übergebende PDU zum Versand einer Kurznachricht besteht aus 2
> wesentlichen Teilen:
> der Adresse des zu verwendenden SMSC (optional)
> der eigentlichen SMS-SUBMIT-PDU, wie sie auch im Netz übertragen wird
> die sich wie folgt zusammensetzen:
> 07
> 91947122720000
> 21
> 00
> 0C
> 91947112325476
> 00
> F1
> 04
> 41E19008
> oder
> 00
> 21
> 00
> 0C
> 91947112325476
> 00
> F1
> 04
> 41E19008
> Aber jetzt zur Erläuterung der einzelnen PDU-Elemente:
> SMSC-Address gem. GSM 04.11:
> 07
> 91947122720000
> Im ersten Byte dieses Informationselements steht die Länge der gelieferten Adressdaten
> in Bytes (!), in o.g. Beispiel also 7 Bytes.
> Im zweiten Byte steht der TOA (Type of address) der gelieferten SMSC-Adresse, der sich
> wie folgt zusammensetzt:
> Bit 7: Immer 1
> Bit 6,5,4: TON (type of number) entweder 001 ('international number', Nummer
> beginnt mit der Landesvorwahl) oder 000 (unknown, alles andere)
> Bit 3,2,1,0: NPI (numbering plan identifier), immer 0001 (E.164/E.163)
> was also genau 2 Möglichkeiten gibt: 0x91 für Nummern im internationalen Format oder
> 0x81 für Nummern im nationalen Format mit Ortsvorwahl oder Nummern ohne Vorwahl.
> Die restlichen Bytes enthalten die Nummer des SMSC, das verwendet werden soll, und zwar
> BCD-kodiert, also je 4 Bit ergeben eine Ziffer der Nummer. Die Nummer beginnt im zweiten
> Halbbyte des ersten Bytes, ein eventuell nicht benutztes Halbbyte an der letzten Stelle
> muß unter allen Umständen 0xF enthalten.
> 1 Byte
> Bits 7 6 5 4
> Bits 3 2 1 0
> zweite Ziffer
> erste Ziffer
> vierte Ziffer
> dritte Ziffer
> sechste Ziffer
> fünfte Ziffer
> ...
> ...
> 1 1 1 1
> letzte Ziffer
> Die +49172123456 würde also so dargestellt:07919471123254F6, die 1212 so: 03812121
> 00
> Wichtig: Wenn im Telefon bereits eine SMSC-Nummer konfiguriert ist, dann kann die Angabe
> der SMSC-Adresse entfallen. Hierzu wird einfach als Längenbyte 0x00 übergeben.
> Message Flags:
> 21
> effizienterweise sind hier in einem Byte gleich 6 Parameter untergebracht:
> 0x21
> 0
> 0
> 1
> 00
> 0
> 01
> TP-MTI
> Message Type Indication: 01 für 'SMS-SUBMIT MS to SMSC'
> TP-RD
> Reject Duplicates: 0 für 'aus', 1 für 'ein'
> TP-VPF
> Validity Period: 00 für kein VP-Feld vorhanden
> TP-SRR
> Status Report Request: 0 für 'aus', 1 für 'ein'
> TP-UDHI
> User Data Header Ind.: 0 für 'no UDH'
> TP-RP
> Reply Path: 0 für 'aus', 1 für 'ein'
> Message Reference Number:
> 00
> eine lokal verwendete Referenznummer für die zu verschickende Kurznachricht.
> Zustellbestätigungen oder Fehlermeldungen enthalten diese Referenznummer und können
> damit der ursächlichen Nachricht zugeordnet werden. Das S10 vergibt selbständig eine
> eigene Referenznummer, deshalb hier 0x00.
> Destination Address gem. GSM 03.40:
> 0C
> 91947112325476
> das erste Byte dieses Informationselements gibt die Anzahl Ziffern (!) der Zieladresse
> an. Der Rest der Nummer wird wie bei 'SMSC-Address' kodiert wobei hier der TON nicht vom
> Längenbyte mitgezählt wird.
> Protocol Identifier:
> 1F
> ein simples 0x00 würde es hier auch tun. Besser ist aber 0x1F, was lt. GSM 03.40 den
> Defaultwert darstellt.
> Data Coding Scheme:
> F1
> dieses Byte bedeutet dem empfangenden Telefon, wie die Kurznachricht zu verstehen ist:
> Bits 7-4: 1111xxxx bedeutet, daß in Bit 3 das Messageencoding und in den Bits 0 und
> 1 die Messageclass versteckt ist
> Bit 3: xxxx0xxx ist 'reserved', muß also '0' sein
> Bit 2: unterscheidet den Zeichensatz, in dem die Nachricht codiert ist. xxxxx0xx
> bedeutet 'default encoding' nach GSM 03.38 (ein weiteres Schmankerl), xxxxx1xx
> bedeutet '8bit encoding'.
> Bits 1-0: enthalten die 'message class'. xxxxxx00 ist Class 0 und sollte bewirken,
> daß die Kurznachricht sofort angezeigt und nicht gespeichert wird, xxxxxx01 ist
> Class 1, eine 'normale' Kurznachricht.
> User Data:
> 04
> 41E19008
> und wieder ein Längenbyte: das erste Byte gibt an, wie viele Zeichen (!) Nutzdaten
> folgen. Man sollte hierbei beachten, daß ein Zeichen nur 7Bit lang ist, zur Übertragung
> 8*7Bit jedoch in 7 Byte verpackt werden. Die folgenden Bytes enthalten dann die
> Nachricht, Zeichensatz wenn nicht anders definiert wie in GSM 03.38 definiert, die
> einzelnen Zeichen gepackt wie beschrieben. Und zwar so:
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 1
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 2
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 3
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 4
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> 5
> 6
> 5
> 4
> 3
> 2
> 1
> 0
> 6
> Nicht benutzte Bits im letzten Byte sollten auf '0' gesetzt
> werden. Eine Übersicht über den verwendbaren Zeichensatz gibts
> bei den AT-Befehlen bei AT+CSCS.
> ? by N. Hüttisch (nobbi@nobbi.com)