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