Leider unterstützen viele Telefone nicht die komfortable Art der Übergabe von Textnachrichten im Textmodus, also als
Klartext (was man, nebenbei bemerkt, mittels at+cmgf=? abfragen kann). Als praktischen Ersatz für Klartext 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 Hexadezimaldarstellung 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.
|
Zur Erläuterung der einzelnen PDU-Elemente:
- SMSC-Addresse nach TS 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 diesem Beispiel also 7 Bytes: 0x07.
Im zweiten Byte steht der TOA (Type of address) der 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. Andere Werte können natürlich verwendet werden, führen aber zu nicht vorhersehbaren Ergebnissen.
Die restlichen Bytes enthalten die Nummer des SMSC das verwendet
werden soll um die Nachricht zu verarbeiten, 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 0xF
enthalten.
| 1 Byte |
| 7 6 5 4 |
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 und diese verwendet werden soll,
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:
| 0x25 |
|
|
| 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 nach TS 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 signalisiert 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 7-Bit Zeichensatz nach TS GSM
03.38 zu verwenden sei. Man kann den
hier nachlesen
- 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 3GPP TS 23.038 aber wirklich
verstanden haben...;-)
Die 8-nach-7-Bit-Wandlung funktioniert nach folgendem Prinzip:
| Originaldaten: |
|
Bit7 abschneiden: |
|
7 Bit packen: |
| |
|
|
|
|
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 7 | 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 |
| 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.
- Der verwendete Zeichensatz für die verwendeten 7bit-Zeichen sieht so aus:
| 0x00 | 0x10 | 0x20 | 0x30 | 0x40 | 0x50 | 0x60 | 0x70 |
| 0x00 | @ | Δ | | 0 | ¡ | P | ¿ | p |
| 0x01 | £ | _ | ! | 1 | A | Q | a | q |
| 0x02 | $ | Φ | " | 2 | B | R | b | r |
| 0x03 | ¥ | Γ | # | 3 | C | S | c | s |
| 0x04 | è | Λ | ¤ | 4 | D | T | d | t |
| 0x05 | é | Ω | % | 5 | E | U | e | u |
| 0x06 | ù | Π | & | 6 | F | V | f | v |
| 0x07 | ì | Ψ | ' | 7 | G | W | g | w |
| 0x08 | ò | Σ | ( | 8 | H | X | h | x |
| 0x09 | Ç | Θ | ) | 9 | I | Y | i | y |
| 0x0A | ¹ | Ξ | * | : | J | Z | j | z |
| 0x0B | Ø | ³ | + | ; | K | Ä | k | ä |
| 0x0C | ø | Æ | , | < | L | Ö | l | ö |
| 0x0D | ² | æ | - | = | M | Ñ | m | ñ |
| 0x0E | Å | ß | . | > | N | Ü | n | ü |
| 0x0F | å | É | / | ? | O | § | o | à |
¹: ist ein Zeilenvorschub (LF, Linefeed)
²: ist ein Wagenrücklauf (CR, Carriage Return)
³: ist ein ESC. Dieses Zeichen zeigt an daß als nächstes ein Zeichen einer Zeichensatzerweiterung folgt. Es existieren Zeichensatztabellen für Türkisch, Spanisch, Portugiesisch sowie die Standarderweiterung:
| 0x00 | 0x10 | 0x20 | 0x30 | 0x40 | 0x50 | 0x60 | 0x70 |
| 0x00 | | | | | | | | | |
| 0x01 | | | | | | | | |
| 0x02 | | | | | | | | |
| 0x03 | | | | | | | | |
| 0x04 | | ˆ | | | | | | |
| 0x05 | | | | | | | € | |
| 0x06 | | | | | | | | |
| 0x07 | | | | | | | | |
| 0x08 | | | { | | | | | |
| 0x09 | | | } | | | | | |
| 0x0A | ¹ | | | | | | | |
| 0x0B | | ² | | | | | | |
| 0x0C | | | | [ | | | | |
| 0x0D | | | | ˜ | | | | |
| 0x0E | | | | ] | | | | |
| 0x0F | | | \ | | | | | |
¹: ist ein Seitenumbruch (Page Break)
²: ist ein ESC. Dieses Zeichen zeigt an daß als nächstes ein Zeichen eines erweiterten Zeichensatzes folgt.
|
