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 18
