Continue to Site
))Nokia 6110 Serial Protocol
Here are some of the details that I've observed while monitoring the protocol Nokia Cellular Data Suite uses to talk over a serial cable to the 6110. The information is fairly sketchy at the moment with lots of gaps, especially in the basic frame format. It is, however, a start.
Snooping was performed over a wired connection. It is assumed that if infra red is used that much the same data is sent, but it may be wrapped up in a low level IrDA format.
Serial Communication
Speed: 115.2 kbps
Bits: 8
Parity: None
Stopbits: 1
Unlike the 21xx series and Nokia Cellularware, data is sent over the FBUS which has both Rx and Tx lines.
Basic Packet Format
In a similar manner to the 21xx protocol. Packets sent from the 'phone must be acknowledged by the PC via a special packet and vice versa.
Most communication takes the form of:
* PC sends some type of "request" or command packet
* 6110 sends an acknowledgement
* 6110 sends some response to the request packet
* PC sends acknowledgment
Format of packets from PC:
+--+--+--+----+--+---+----------+-+--+--+----+----+
|1e|00|0c|type|00|len|...body...|n|sq|0?| chk |
+--+--+--+----+--+---+----------+-+--+--+----+----+
type: some indication of message type:
( 1, 2, 4, 10, 11, 13, 14, 64 seen)
len: length in bytes from following byte to sq inclusive
n: if this packet is part of a group (i.e. long sms) indicates
how many more messages, including this one, there are
sq: packet sequence number,
least significant nibble: incremented in range 0..7 for each
new packet
most significant nibble: ? seems to be normally 4, but appears
to be 0 if this is not the first packet
in a group. 6 has also been seen
0?: 0x00, only included if len is odd
chk: 16 bit xor of all preceding 16 bit words
Format of ack from PC:
+--+--+--+--+--+---+----+--+----+----+
|1e|00|0c|7f|00|len|type|sq| chk |
+--+--+--+--+--+---+----+--+----+----+
type: corresponds to original message type
len: length in bytes, always 2
sq: last 3 bits indicate sequence number of packet being
acknowledged, most significant nibble is normally 0,
8 for sequence error?
chk: 16 bit xor of all preceding 16 bit words.
Format of packets from 6110:
+--+--+--+----+--+---+----------+-+--+--+----+----+
|1e|0c|00|type|00|len|...body...|n|sq|0?| chk |
+--+--+--+----+--+---+----------+-+--+--+----+----+
type: some indication of message type
(1, 2, 4, 10, 11, 13, 14, 64 observed)
len: length in bytes from following byte to id inclusive
n: if this message is part of a group (i.e. long sms) indicates
how many more messages, including this one, there are
sq: packet sequence number,
least significant nibble: incremented in range 0..7 for each
new packet
most significant nibble: ? seems to be 4 normally, but appears
to be 0 if this is not the first packet
in a group. 6 has also been seen
0?: 00, only included if len is odd
chk: 16 bit xor of all preceding 16 bit words.
Format of ack from 6110:
+--+--+--+--+--+---+----+--+----+----+
|1e|0c|00|7f|00|len|type|sq| chk |
+--+--+--+--+--+---+----+--+----+----+
type: corresponds to original message type
len: length in bytes, always 02
sq: last 3 bits indicate sequence number of packet being
acknowledged, most significant nibble is normally 0,
8 for sequence error?
chk: 16 bit xor of all preceding 16 bit words.
Format of SMS-SUBMIT from PC:
Referring to GSM 03.40 will make the following fields
clearer. It should be noted that the format of the data
in this packet is different to the SMS-SUBMIT TPDU. The fields
are, however, the same. GSM 03.38 shows how the message itself
is packed. This packet format is only valid as long as len < 0x41
if the message length would force the packet to be longer then the
message is split across multiple packets. I'll post that
information shortly.
+--+--+--+--+--+---+--+--+--+--+--+--+--+--+-------+--+--+--+--+
|1e|00|0c|02|00|len|00|01|00|01|02|00|sl|st|..sca..|fo|00|pi|dc|
+--+--+--+--+--+---+--+--+--+--+--+--+--+--+-------+--+--+--+--+
+--+--+--+--------+------+---------+--+--+--+-------+
|ml|dl|dt|...da...|..vp..|...msg...|01|sq|0?| chk |
+--+--+--+--------+------+---------+--+--+--+-------+
len: packet length from following byte to sq inclusive
sl: SMSC number len in octets including st
st: SMSC number type e.g. 0x81-unknown 0x91-international 0xa1-national
sca: SMSC number. This is packed in BCD format ie. 2 digits per octet
it is a 10 byte field whether the number is 20 digits or not.
fo: first octet of TPDU, holds flas such as validity period format
pi: pid, protocol id
dc: dcs, data coding scheme
ml: message length in 7 bit chars
dl: destination address (da) length in used semi-octets,
dt: da type eg. 81-unknown 91-international a1-national
da: destination number packed as BCD ie. 2 digits per octet
this is a 10 byte field. Unused octets can sometimes hold
rubbish.
vp: validity period (1 integer byte or 7 octets - vpf) 7 byte field
msg: 7 bit chars packed into bytes (see GSM 03.38)
sq: packet sequence number,
least significant nibble: incremented in range 0..7 for each
new packet
most significant nibble: ? seems to be 4 normally, but appears
to be 0 if this is not the first packet
in a group. 6 has also been seen
0?: pad bye, only present if len is odd
chk: 6 bit xor of all preceding 16 bit words.
Example:
SMS sent to 987654321 via SMSC 12345678. First octet of TPDU
(fo) = 0x11, Validity Period (vp) = 0xa7,
Data Coding Scheme (dcs) = 0 and Protocol Identifier (pid) = 0.
Message reads "hello" - 0xe8 0x32 0x9b 0xfd 0x06 in packed format:
1e 00 0c 02 00 31 00 01 00 01 02 00 06 81 21 43 65 87 f9 63 a8 00 00
00 11 00 00 00 05 09 81 89 67 45 23 f1 b8 81 20 15 63 a7 00 00 00 00
00 00 e8 32 9b fd 06 01 44 00
Phonebook Packet Format
In the following descriptions, ME = mobile equipment (i.e. the phone or it's memory) and SM = sim card.
PC reading phonebook entry:
+--+--+--+--+--+---+--+--+--+--+--+--+--+--+--+--+---+
|1e|00|0c|03|00|len|00|01|00|01|st|ix|00|01|sq|0?|chk|
+--+--+--+--+--+---+--+--+--+--+--+--+--+--+--+--+---+
st: storage type e.g. 02-ME 03-SM etc.
ix: index
e.g. to read location with index 1 from the sim:
1e 00 0c 03 00 09 00 01 00 01 03 01 00 01 46 00 57 0a
6110 responding to a phonebook read:
+--+--+--+--+--+---+--+--+--+--+--+--+----+--+---+--+--+--+--+--+---+
|1e|0c|00|03|00|len|01|08|00|02|00|tl|text|nl|num|05|00|01|sq|0?|chk|
+--+--+--+--+--+---+--+--+--+--+--+--+----+--+---+--+--+--+--+--+---+
tl: name text length
text: entry name text in ASCII
nl: number len (in digits)
num: number in ASCII
e.g. response to reading sim location 1 containing
"Action Line", 0345888444:
1e 0c 00 03 00 20 01 08 00 02 00 0b 41 63 74 69 6f 6e 20 4c 69 6e 65
0a 30 33 34 35 38 38 38 34 34 34 05 00 01 44 5d 18
Reading empty location 1 from the phone returns (as expected):
1e 0c 00 03 00 0b 01 08 00 02 00 00 00 05 00 01 47 00 58 0a
i.e. text and number lengths are 0 and there are no actual text
or number fields
PC writing a phonebook entry:
+--+--+--+--+--+---+--+--+--+--+--+--+--+----+--+---+--+--+--+--+---+
|1e|00|0c|03|00|len|00|01|00|04|st|ix|tl|text|nl|num|ff|01|sq|0?|chk|
+--+--+--+--+--+---+--+--+--+--+--+--+--+----+--+---+--+--+--+--+---+
st: storage type 02-ME 03-SM etc.
ix: index
tl: name text length
text: entry name text in ASCII
nl: number len (in digits)
num: number in ASCII
e.g. writing an entry "Test", 1234 to location index 2 to the phone memory:
1e 00 0c 03 00 13 00 01 00 04 02 02 04 54 65 73 74 04 31 32 33 34 ff 01 47 00 bf 33
6110 responding to phonebook write:
Success:
1e 0c 00 03 00 06 01 08 00 05 01 46 1e 42
^^-indicates success?
Failure due to index being out of range:
1e 0c 00 03 00 07 01 08 00 06 74 01 43 00 28 07
indicates failure---^^ ^^--indicates reason?
PC requesting storage parameters:
+--+--+--+--+--+---+--+--+--+--+--+--+--+--+---+
|1e|00|0c|03|00|len|00|01|00|07|st|01|sq|0?|chk|
+--+--+--+--+--+---+--+--+--+--+--+--+--+--+---+
st: storage type
e.g. requesting parameters for the sim card:
1e 00 0c 03 00 07 00 01 00 07 03 01 43 00 52 03
6110 responding with storage parameters:
+--+--+--+--+--+---+--+--+--+--+--+--+--+--+--+--+---+
|1e|0c|00|03|00|len|01|08|00|08|st|fr|us|01|sq|0?|chk|
+--+--+--+--+--+---+--+--+--+--+--+--+--+--+--+--+---+
st: storage type
fr: number of free locations
us: number of used locations
e.g. responding for the sim storage which has 90 locations
59 of which are used:
1e 0c 00 03 00 09 01 08 00 08 03 1f 3b 01 43 00 64 18BTW why you don't Try to Spy a Nokia Software (logomanager)??