{ Back to SiSMS Homepage }

Siemens SMI/SMO File Structure


SMI/SMO files are archived SMS messages, generated by Siemens mobile phones (presently BenQ-Siemens). Those files are created when moving SMS message to the phone archive folder. SMI files represent incoming SMS messages and SMO files are outgoing SMS messages (either Draft or Sent/Unsent). SMI/SMO files are binary encoded and as such cannot be viewed with common text viewer.


SMI/SMO files have very simple structure. They consist of header file information including file signature, message parts counter, message type/status and date/time stamp. The body part of these files is a representation of the actual PDU (Protocol data unit) structure (called segment). Note, that in this document, segment has been used not as a synonym of PDU (as ETSI does), but as the set of some PDU-identifying fields and the PDU itself. Each segment consists of a segment status byte, SMS center address and PDU structure. The PDU structure contains the actual short message as transferred to/from the mobile device to the GSM network and consist of message-related information (message type, sender/receiver number, etc.) and the SMS body itself. Later versions of SMI/SMO files can contain more than one segment as required by EMS (Enhanced Messaging Service), which allows a multi-part concatenated short message longer than 160 symbols.

In this document SMI/SMO files are distinguished by file versions which are based on the Siemens mobile phone model that generated these files. In general, phone models vary from series to series and have been united as follows:

For ease of use, I have numbered these series with versions - 0 for SL4X, 1 for X45 and 2 for X55.

Please, note that the models listed above have been tested and it has been confirmed that they produce analogous SMI/SMO files. Note that at the time of writing of this document, BenQ-Siemens has been releasing new generation S/SX/SXG75 mobiles, which tend to change the file format for archived SMS messages, so as for the 75 series no exact information can be given.

In all of the examples below, byte values are given in hexadecimal format unless otherwise stated. Additionally, the terms octet and semi-octet are used. Octet is identical to byte. Semi-octet means each one of the the two halves (4 bit long each) in a hexadecimally represented byte. Most important is that each semi-octet value is in decimal format and its halves are additionally reversed - meaning that hex 12 means decimal 21 and values as 5C are not allowed. Important exception is that 'F's are used as fill semi-octets, so 06F1 means "three digits long value 601".

When numbering byte/bit order, positions are 0-indexed. That is, the first byte in the file or given structure has position number of 0 (zero), the second has position number 1, and so on.

For the questions of indexing, octets and address/time representation, refer to the fore-mentioned ETSI document "Technical realization of the Short Message Service (SMS)".

Note: None of the information below has been officially stated by Siemens or in any other way published on the Internet or hard-printed. Everything given below is the result of a try-and-guess work and is not to be used as a formal guideline, draft, standard or requirement. The sole exception is PDU structure, which is defined by the European Telecommunications Standards Institute (ETSI), which is the official body controlling the standardization of communications in Europe. Visit http://www.etsi.org for additional information, and pay special attention to the document titled "Technical realization of the Short Message Service (SMS)" (go for 3GPP TS 23.040 - the technical specification for SMS in UMTS networks).

Structure outline

Here is a table for the general SMI/SMO file structure. It represents the file part and whether this part is present in the files generated by the corresponding mobile phone.

Mobile phone model
Field name (Length in bytes) Siemens SL4x Siemens X45 Siemens X55/X65/X75
File signature (hexadecimal) (5 bytes) Yes Yes Yes
SMS parts (2 bytes) No Yes Yes
SMS type (1 byte) No Yes Yes
SMS status (1 byte) No Yes Yes
Date/time stamp (7 bytes) No Yes Yes
Waste byte (1 byte) No No Yes
Segment status/type (1 byte) Yes Yes Yes
SMSC address (variable length) Yes Yes Yes
PDU structure (variable length) Yes Yes Yes
Fill bytes (alwas 0xFF) (variable length) Yes Yes Yes

File features are as follows:

File signature

File signature is in the very beginning of the SMI/SMO file and is 5 bytes long. It determines the file structure and varies through the different Siemens mobile phone series.

File signature value (5 bytes)
Siemens SL4X X55/ME45 X65/X75
Field value (hexadecimal) 0B, 0B, 00, 00, 00 0B, 0B, 01, 01, 00 0B, 0B, 02, 0C, 00

Shown in the table above are the values of the file signature through phone series.

SMS parts

(Not for version 0) The SMS parts field is 2 bytes long. It indicates the SMS segments count in the given SMI/SMO file. The first byte indicates the supposed count of the SMS segments. The second byte shows the number of SMS segments actually stored in the SMI/SMO file; that is it is the Segment_count in the file length formula given above. If the two numbers differ, this means that some of the segments have not been received by the mobile device, i.e. SMI/SMO file is corrupt and though it can still be processed, a premature file end can be encountered.

SMS type

(Not for version 0) SMS type byte indicates whether the message is outgoing or incoming. That is, it determines the type of the PDU(s) in the message file. PDUs are of six types, but only two of them are used in SMI/SMO files: SMS-DELIVER (for incoming messages; SMI files) and SMS-SUBMIT (outgoing messages; SMO files). This byte is analogous to the file extension, but unlike the extension, cannot be easily changed by the common user. Values are as follows:

SMS type value
PDU(s) type

SMS status

(Not for version 0) SMS status byte indicates the message status - it gives information whether the SMS has or has not been read (for incoming messages) or whether it has or has not been sent (for outgoing messages). Values are:

SMS/PDU type SMS status value
Message status
SMI; Incoming (SMS-DELIVER) 00 Read
01 Unread
SMO; Outgoing (SMS-SUBMIT) 03 Sent
04 Unsent

Message date/time stamp

(Not for version 0) Message date/time stamp is 7 bytes long. It represents the date/time when the message has been sent/received. The first 3 bytes are for the date, then come 3 bytes for time, and then comes one byte for time zone calculation (that is which zone the has been set up on the mobile device). This stamp is in semi-octet representation, meaning that each one of the value bytes for date and time entries are swapped. For example, July is stored as 70 (hexadecimal) and not as 07. Message date/time stamp sector structure is as follows:

Byte position Byte meaning Explanation
0 Year Two-digits representation of year. Example: 50 stands for 2005, and not for 1905 - there were no GSMs at that time, after all ;-)
1 Month Two-digits representation of month. Example: 90 stands for September
2 Day Two-digits representation of the day of the month
3 Hour Two-digits representation of the hour in 24-hours format. For example: 41 means 14 o'clock (2 PM).
4 Minute Two-digits representation of the minute.
5 Second Two-digits representation of the second.
6 Time zone Two-digits semi-octet representation of the time zone difference.

Of these additional explanation is needed for the Time zone byte. It represents the difference, in quarters of the hour, between local time and GMT (Greenwich Mean Time). After semi-octet swapping, time zone byte should be treated as a common signed integer value (with the last bit 7 indicating the sign: 0 is for positive and 1 for negative values). For example, value of 84 should be swapped to 48; 4 is bit represented as 1000, meaning the number is negative, 8 means "8 quarters of an hour"; so, 84 is translated as -2 hours to GMT".

Waste byte

(Not for version 0 and 1) In all of the SMI/SMO files this byte has always been 00. So it's function cannot be properly determined. It is possible that it is simply used to easily differentiate version 2 files by size (with the waste byte present, these are 193 bytes, instead 192 for version 1).

Segment status/type

This byte is presented in all version of SMI/SMO files. It is in fact SMS type and SMS status bytes combined in one. It's meanings are:

Segment status/type value Segment meaning
01 Incoming/read
03 Incoming/unread
05 Outgoing/sent
07 Outgoing/unsent

Note, that a value of 03 could not be actually encountered on version 0 and some of the version 1 files. This is because older Siemens phones do not allow a SMS message to be archived before being read.

SMSC address

SMS Center (SMSC) address is a field of variable length but is always greater than one. The address-length byte comes first and indicates the number of the bytes following this first byte. After the address-length byte there follows the actual address of the SMS center, where the first byte is the address-type and then there comes the address in semi-octet representation. Important consideration is that if the SMSC number is odd, then the last semi-octet has the value 'F'. See the table below:

Byte position Byte meaning
0 SMSC address-length in bytes (hexadecimal)
1 SMSC address-type (hexadecimal)
2..x SMSC address (semi-octets)

As explained SMSC address-length gives the length of the SMSC address-type + SMSC address (in bytes). SMSC address-type shows whether the address-number is national, international, whether it is ISDN, telex number and so on. (See the ETSI specifications for details - "Digital cellular telecommunications system (Phase 2+); Numbering, Addressing and Identification"). After the SMSC address-type byte there comes the number itself, which length in bytes is the value of SMSC address-length value minus 1 (for the SMSC address-type byte).

For example: 07 91 94 02 89 61 51 F7 is translated as follows: 7-bytes long address; international ISDN numbering plan; SMSC number (+)49209816157 (the 'F' is stripped after semi-octet swapping).


PDUs are the heart of any SMI/SMO file. The PDU structures are always 176 bytes long. There are two PDU types used. SMS-DELIVER is for SMI messages with SMS type 00 (Incoming) or Segment status/type of 01 and 03 (for file version 0). SMS-SUBMIT is for SMO messages with SMS type of 03 (Outgoing) or Segment status/type of 05 and 07 (for file version 0). Describing in details SMS-DELIVER and SMS-SUBMIT is beyond the scope of this document, so please refer to ETSI's "Technical realization of the Short Message Service (SMS)" part 9.2 for more information. What is important to be noted here is that although the actual SMS-DELIVER/SMS-SUBMIT structure is of variable length, Siemens mobiles always fill up to the maximum 176 bytes allowed by the GSM standard with 'F's.

Message concatenation

After and including version 1 of SMI/SMO files, there has been added the feature of multi-part SMSs being concatenated and displayed as one message. This is achieved by setting SMS parts field to the according segments count. The overall SMI/SMO file represents repeated Segment status/type field, PDU structure and Fill bytes for each new segment. Multi-part SMI/SMO files looks like this:

SMI/SMO filed (length of field) Value / Meaning
SMS signature (5 bytes) 0B 0B 01 01 00 or 0B 0B 02 0C 00
SMS parts (2 bytes) N N (where N is any hex one-byte number)
... Other SMI/SMO file fields
Segment status/type for PDU1 (one byte) Any valid value
SMSC address for PDU1 (variable length) Any valid value
PDU1 (variable length) Actual SMS-DELIVER or SMS-SUBMIT structure
Fill bytes (176 - PDU1 length) 'FF' (in case previous SMS-DELIVER or SMS-SUBMIT structure is not of maximum length, which is 176 bytes)
Segment status/type for PDU2 (one byte) Value should be identical to the one for PDU1
SMSC address  for PDU2 (variable length) Any valid value
PDU2 (variable length) Actual SMS-DELIVER or SMS-SUBMIT structure
Fill bytes (176 - PDU2 length) 'FF' (in case previous SMS-DELIVER or SMS-SUBMIT structure is not of maximum length, which is 176 bytes)
.. ..

If you have any questions - ask SiSMS Support.

SourceForge.net Logo
Hosted by SF.net
View My Stats