{ Back to SiSMS Homepage }

Siemens SMI/SMO File Structure

Preface

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.

General

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:

• SL4x Series (SMI/SMO file version 0): Siemens SL42, SL45
• X45 Series (version 1): Siemens ME/S45 and  C55
• X55 Series (version 2): All of the Siemens 55 series models (except C55), 65 series models (such as C/CX65, M65, S/SL65) and M/ME/C75/CX75

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.

File features are as follows:

• Version 0: These files are the most simple in structure. They consist of file signature, PDU status/type, SMSC address and PDU structure. They allow no SMS concatenation and have no date/time stamp except the date/time stamps of the corresponding file (creation, accessed and modified date). Do not confuse date/time stamp on the file with the message date/time stamp on later file versions. File stamp is supported and operated by the file-system and is the date/time the SMI/SMO file was created (saved) to the archive. Message date/time stamp is recorded in the file itself and shows when the message was sent/received by the mobile phone. Since file version 0 is supported by SL42/SL45 phones that do not support EMS, it is not expected EMS elements (font size, font type, pictures, etc.) to be present in these files. Version 0 files are 181 bytes long.
• Version 1: This version adds more information to the file. It allows concatenated SMS messages. Additionally, there is support for EMS elements. Version 1 adds PDU segments count, dedicated SMS type and SMS status bytes. It also features SMS message date/time stamp field (which is only set for SMI files; for SMO files it is 00s). Version 1 file length varies according to the segments count in the message, but it is calculated with the formula 192 + 176 x Segment_count.
• Version 2: It is generally the same as version 1, but it has one more waste byte. Message date/time stamp is present also for SMO files, but for mobiles later than Series 65. Version 2 file length is calculated in the following way 193 + 176 x Segment_count.

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.

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 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:

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:

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:

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:

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).

PDU

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:

If you have any questions - ask SiSMS Support.

Hosted by SF.net

View My Stats