| 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=28
> 079194712272303325000C91947112325476000008D4F29C4E2FE3E9
+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.
Wem das alles deutlich zu kompliziert ist und dafür seinen PC verwenden
möchte, dem sei PDUspy ans Herz gelegt. Gibts auf der
Downloadseite. |
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 |
91947122723033 |
25 |
00 |
0C |
91947112325476 |
00 |
00 |
0B |
D4F29C4E2FE3E9BA4D19 |
oder
| 00 |
25 |
00 |
0C |
91947112325476 |
00 |
00 |
0B |
D4F29C4E2FE3E9BA4D19 |
|
Aber jetzt zur Erläuterung der einzelnen PDU-Elemente:
SMSC-Address gem. GSM 04.11:
Im ersten Byte dieses Informationselements steht die Länge der gelieferten
Adressdaten (also die Länge der SMSC-Adresse) 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
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:
effizienterweise sind hier in einem Byte gleich 6 Parameter untergebracht:
| 0x21 |
|
|
| 0 |
0 |
1 |
00 |
1 |
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:
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 Telefon vergibt selbständig eine eigene Referenznummer, falls
keine angegeben wird, deshalb hier 0x00. |
Destination Address gem. GSM 03.40:
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 im Längenbyte mitgezählt wird. |
Protocol Identifier:
gibt an, welches Protokoll den verschickten Daten zugrunde liegt. Ein simples
0x00
genügt im Allgemeinen hier, was lt. GSM 03.40 den Defaultwert darstellt. |
Data Coding Scheme:
dieses Byte bedeutet dem empfangenden Telefon, wie die Daten der Kurznachricht
zu decodieren sind. Ein simples 0x00 genügt auch hier
den meisten Erfordernissen:
-
Bits 7-4: 0000xxxx enthalten die 'coding group' und geben
damit Aufschluss darüber, wie die Bits 3 bis 0 zu verstehen sind.
-
Bit 3-0: xxxx0000 enthalten in diesem Fall lediglich den
Hinweis, dass der genormte Zeichensatz nach TS GSM 03.38 zu verwenden sei.
|
User Data:
und wieder ein Längenbyte: das erste Byte gibt an, wie viele Zeichen
(!) Nutzdaten folgen, und zwar nach dem decodieren der Nachricht. 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. Wers gerne testen möchte: die o.a. Nachricht sollte
'Testtext:€' ergeben. Dazu muss man die TS GSM 03.38 aber
wirklich verstanden haben...;-)
Die 8-nach-7-Bit-Wandlung sieht übrigends so aus:
| 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. |
|