SAP SMS 365, enterprise service SMTP Technical Specification October 2013

SAP SMS 365, enterprise service SMTP Technical Specification October 2013

TABLE OF CONTENTS 1 INTRODUCTION... 5 2 SENDING SMTP MESSAGES... 5 2.1 MSISDN Section... 5 2.1.1 List... 5 2.2 Message Section... 5 2.2.1 Text... 6 2.2.1.1 Latin character set... 6 2.2.1.2 Chinese character set... 6 2.2.2 Binary... 6 2.2.3 Length... 6 2.3 Setup Section... 7 2.3.1 Class... 7 2.3.2 2.3.2 DCS (Data Coding Scheme)... 7 2.3.3 PID (Protocol Identifier)... 7 2.3.4 MobileNotification... 7 2.3.5 MailAckType... 7 2.3.6 ValidityPeriod... 8 2.3.6.1 Coding:... 8 2.3.7 DestinationPort... 8 2.3.8 OriginatorPort... 9 3 DELIVERY NOTIFICATIONS... 10 3.1 Delivery Notifications Returned by the SMTP Interface... 10 3.1.1 What is a Temporary Positive Notification Status?... 13 3.1.2 What is a Final Positive Notification Status?... 13 3.1.3 What is a Temporary Negative Notification Status?... 13 3.1.4 What is a Final Negative Notification Status?... 13 3.1.5 What is a Retriable Status?... 13 4 RECEIVING SMTP MESSAGES... 14 4.1 Message Format... 14 4.1.1 SERVICE Section... 14 4.1.2 MSISDN Section... 14 4.1.3 Message Section... 14 4.1.4 Parameters Section... 14 4.1.4.1 DCS (Data Coding Scheme)... 14 4.1.4.2 ReceivedTime... 14 4.1.4.3 Coding:... 14 5 APPENDIX A: GSM DEFAULT ALPHABET... 15 6 APPENDIX B: ISO-8859-1 TO GSM 3.38 ALPHABET TRANSLATION... 16 7 APPENDIX C: CREATING BINARY CONTENT... 27 7.1 Ringtone Format... 27 7.1.1 Ringtone Creation... 27 7.1.2 RTTL... 28 7.1.3 MIDI... 28 7.1.4 Mail Transfer Format... 28 7.1.5 Ports... 28 7.2 Operator Logo Format... 28 7.2.1 Format Coding... 29 7.2.2 Ports... 29 2

7.2.3 Payload Explanation... 29 7.2.4 Ports... 30 7.3 Picture Messaging... 30 7.3.1 Picture Coding... 30 7.3.2 Adding a Text Message to the Picture... 30 7.3.3 Ports... 31 7.4 MIME vcard... 31 7.5 MIME vcalendar... 31 7.6 TTML... 32 8 APPENDIX D: ERROR MESSAGES RETURNED DURING MESSAGE SENDING... 33 9 REFERENCES... 35 3

IMPORTANT NOTICE: The information in this document is subject to change without notice and should not be construed as a commitment by SAP. SAP assumes no responsibility for any errors that may appear in this document. 4

1 INTRODUCTION The SAP SMS 365, enterprise service, SMTP interface is intended for Content Providers (CPs) connecting into SAP messaging gateway for: Mobile Terminated (MT) Services Mobile Originated (MO) Services Detailed explanations and samples will be given throughout the document. 2 SENDING SMTP MESSAGES The structure of SMTP messages dispatched to SAP for onward transmission over SMS is illustrated below. [MSISDN] List= [MESSAGE] Text= Binary= Length= [SETUP] Class= DCS= PID= MobileNotification= MailAckType= ValidityPeriod= DestinationPort= OriginatorPort= [END] Note: The SMTP message must be sent in plain-text format. An HTML email will not be allowed by the mail server. 2.1 MSISDN Section 2.1.1 List The MSISDN section contains the phone number(s) of the recipient(s) of the short message. The phone number(s) shall be given in international format (i.e., + followed by the international country code phone number). Phone numbers are separated by commas. The maximum number of phone numbers that can be specified in a single request is 200. To achieve optimal performance, we recommend that you specify up to 20 phone numbers per request. Example: [MSISDN] List=+44777123123,+39789432445 Note: This field is mandatory. No spaces are allowed between the comma and the phone number. 2.2 Message Section The Message section contains either the text to be displayed on the mobile phone or binary data used for Smart Messaging. 5

2.2.1 Text This field specifies the text that will be sent to a mobile phone. This field is mandatory if you send a text message, and in this case the Binary field should not be present. Two character sets are accepted: Latin and Chinese (see below). 2.2.1.1 Latin character set Coded in Latin-1 (ISO-8859-1) format, the maximum permitted length for this field is 160 characters. All the characters defined in the ISO-8859-1 format and not permitted by the GSM 3.38 characters will be transformed as described in Appendix B - ISO-8859-1 to GSM 3.38 alphabet translation. Use the specific marker <LF> to insert the line feed character. The use of the <CR> (carriage return) is not recommended, as most handsets are incompatible with this feature. The list of permitted characters is shown in Appendix A - GSM Default Alphabet. Example: [MESSAGE] Text=This is a text message. <LF> Courtesy of SAP. Note: In this example, the text following the <LF> marker will be displayed on a new line regardless of the width of the handset's display. 2.2.1.2 Chinese character set Coded in BIG5, the maximum permitted length is 70 characters. The DCS field has to be specified with the appropriate value (BIG5). The specific markers <CR> and <LF> are also available. Example: [MESSAGE] Text= [SETUP] DCS=BIG5 2.2.2 Binary This field contains the binary data to be submitted, such as ringtones or logos. The maximum length is 512 bytes (i.e., 1,024 ASCII characters, spaces being omitted). Each hexadecimal value of the binary data shall be encoded in ASCII code in order to allow the correct transfer over the Internet (see example below). This field can also contain a Chinese message (UCS2 binary data encoded in ASCII). In this case, the DCS field must be set to UCS2. 2.2.3 Length The length is mandatory when binary data is submitted and is only used in this case. The length indicated is the size of the binary data before encoding (i.e., the number of bytes). Example: [MESSAGE] Binary=024A3A4000 Length=5 Note: In this example, each four-bit word of the original message is encoded in ASCII before being sent. Example (Chinese message): [MESSAGE] Binary=4F60597D55CE003F Length=8 6

[SETUP] DCS=UCS2 Note: For Chinese messages, the DCS field must be set to UCS2. For other binary messages, the DCS will be automatically set to 8b. 2.3 Setup Section This section defines the parameters of the message to be sent. All fields are optional. If a field is not present, a default value will be used. 2.3.1 Class This field defines the class of the short message to be sent. The following are the possible values: 0: Class 0. The message will be displayed immediately on the handset, but will be erased after the first keypad entry. 1: Class 1. The message will be displayed on the screen or stored in the SIM card, depending on the handset. 2: Class 2. The message will be stored in the SIM card of the handset. Usually, the user will be notified with a beep and/or an icon on the screen. This is the default value. The Class values are described in GSM TS 03.38 [1]. 2.3.2 2.3.2 DCS (Data Coding Scheme) This field specifies how the text of the short message is encoded. When the message contains text, the value is automatically set to 7b (standing for 7 bits default alphabet). When the message contains binary data, this field is automatically set to 8b (standing for 8 bits binary data). When sending a Chinese message, this field is mandatory. The possible values are UCS2 or BIG5. The Data Coding Scheme values are described in GSM 03.38 [1]. 2.3.3 PID (Protocol Identifier) The only permitted value is Type0, which stands for short message type 0. A short message type 0 indicates that the mobile phone must acknowledge receipt of the short message. 2.3.4 MobileNotification This field indicates whether a delivery notification from the handset is requested or not. The handset delivery information is operator dependent. The possible values are Yes or No. The default value is No. See section 4 below for the set of delivery notifications returned by the SAP365 messaging gateway. 2.3.5 MailAckType This field indicates the level of reporting that SAP will send back to the originator of the incoming message. The following values are allowed: Order: When this option is set, SAP will only acknowledge the receipt of the message by giving an order identifier and the number of messages generated. This is the default value. Message: When this option is set, SAP will return a delivery notification acknowledging the message was: Delivered to the operator s SMS-C Delivered to the user/handset (where supported by the destination operator) Failed delivery The table below summarizes the results obtained depending on the two notification options. 7

Table 1: MailAck Type Options MailAckType Mobile Notification Result Order No Client receives only SAP reception notification Yes Client receives only SAP reception notification Message No Client receives notification of SAP and SMS-C reception Yes Client receives notification of SAP and handset reception (where the Handset Ack is supported by the destination operator). 2.3.6 ValidityPeriod Each short message submitted to SAP is assigned a Validity Period setting the maximum time that the short message is retained in SAP s network and/or in the network of the corresponding wireless operator. Failure to deliver the short message successfully within the short message lifetime (if the subscriber is out of coverage for instance) leads to those messages being purged. Setting specific short message Validity Periods is important for many SMS-based applications. For example, a daily short message informing you of a stock quotation at the end of the day would have a 24-hour Validity Period. In this case, the information is not necessarily relevant when received a day after having been sent. The validity period defined when sending an SMTP message to SAP is independent of the maximum validity period allowed on each specific wireless network. The validity period is counted from the moment SAP receives the message. 2.3.6.1 Coding: ValidityPeriod=n [w d h m] Where: n stands for the number of units w stands for week d stands for day h stands for hour m stands for minute Example: ValidityPeriod=2w ; Two weeks ValidityPeriod=3d ; Three days ValidityPeriod=10m ; Ten Minutes 2.3.7 DestinationPort This field contains the receiving port used for specific applications such as Smart Messaging. This field is mandatory when binary data is submitted and only used in this case. The hexadecimal value is sent. Example: DestinationPort=1581 ; Nokia Ringtones 8

2.3.8 OriginatorPort This field contains the sending port used for specific applications like Smart Messaging. This field is mandatory when binary data are submitted and only used in this case. The hexadecimal value is sent. Example: OriginatorPort=1581; Nokia Ringtones 9

3 DELIVERY NOTIFICATIONS Delivery Notifications are message acknowledgments sent from the SAP network to customers. When delivering messages through our network, customers can request to receive the following three levels of acknowledgment: SAP Ack, SMS-C Ack, and Handset Ack. For unsuccessful delivery attempts, SAP will return a negative acknowledgment (NACK) outlining the failure reason. 3.1 Delivery Notifications Returned by the SMTP Interface The following table captures the Delivery Notifications (both Positive and Negative acknowledgments) returned by the SAP messaging gateway. Table 2: Delivery Notifications Returned by the SMTP Interface Notification Status Notification Code Notification Indicates Message Sent to Customer Customer Receives (Example) Notification Retriable? Temporary Positive 450E SAP SMS 365 Ack Your message has been correctly processed. <NBROFMESS > message(s) have been generated with the order Id <ORDERID>. Your message has been correctly processed. 1 message(s) has(have) been generated with the order Id 1887176643. N 450A SMS-C Ack, waiting for Handset Ack Message <MESSID> of the order <ORDERID> at destination of <MSISDNNBR > has been sent at <TIME> (CET) on the <DATE>. Message 1 of the order 1887176643 at destination of +6598457560 has been sent at 09:33:15 (CET) on the 11-05-2005. N Final Positive 450A SMS-C Ack, not waiting for Handset Ack Message <MESSID> of the order <ORDERID> at destination of <MSISDNNBR > has been sent at <TIME> (CET) on the <DATE>. Message 1 of the order 1887197305 at destination of +6598457560 has been sent at 10:09:38 (CET) on the 11-05-2005. N 10

Notification Status Notification Code Notification Indicates Message Sent to Customer Customer Receives (Example) Notification Retriable? 451A Handset Ack Message <MESSID> of the order <ORDERID> at destination of <MSISDNNBR > has been received at <TIME> (CET) on the <DATE>. Message 1 of the order 1887176643 at destination of +6598457560 has been received at 09:33:15 (CET) on the 11-05- 2005. N Temporary Negative DBF3 SAP is retrying delivery <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR >: Mobileway retrying. Error dbf3: Message 1 of orderid 1887176643 for number +6598457560: Mobileway retrying N Final Negative 4524 MSISDN is blacklisted Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > has been filtered on customer request. Message 1 of orderid 1887176643 for number +6598457560 has been filtered on customer request. N DB05 Call barred by operator <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by destination operator. Error db05: Message 1 of orderid 1887176643 for number +6598457560 rejected by destination operator N 11

Notification Status Notification Code Notification Indicates Message Sent to Customer Customer Receives (Example) Notification Retriable? DB52 Failed Message Delivery <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. Error db52: Message 1 of orderid 1887176643 for number +6598457560 rejected by Operator N DB76 Subscriber profile does not permit service <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. MSISDN account is barred. Error db76: Message 1 of orderid 1887176643 for number +6598457560 rejected by Operator. MSISDN account is barred. N DB99 Ported Number <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. Error db99: Message 1 of orderid 1887176643 for number +6598457560 rejected by Operator N DB62 Failed Message Delivery <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. Error db62: Message 1 of orderid 1887176643 for number +6598457560 rejected by Operator Y 12

Notification Status Notification Code Notification Indicates Message Sent to Customer Customer Receives (Example) Notification Retriable? DB65 Validity Period Expired <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. Error db65: Message 1 of orderid 1887176643 for number +6598457560 rejected by Operator Y DB78 Subscriber is temporarily out of credit <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > does not have sufficient credit. Error db78: Message 1 of orderid 1887176643 for number +6598457560 does not have sufficient credit Y 3.1.1 What is a Temporary Positive Notification Status? A temporary positive notification indicates to a customer an interim delivery confirmation, with a final delivery confirmation yet to be returned. 3.1.2 What is a Final Positive Notification Status? A final positive notification is returned when the message has been delivered to the operator s SMS-C (when no Handset Ack is requested, or the operator does not support Handset Ack) or to the handset (when a Handset Ack is requested). In both cases, the status is final and no additional notifications will be sent for that message. 3.1.3 What is a Temporary Negative Notification Status? A temporary negative notification is returned when SAP is attempting a retry on a message that previously failed to deliver. When this happens, customers should expect a final status to be sent at the conclusion of the retry process, whether positive or negative. Until a final status is received, customers should not be initiating their own retry, as it could potentially result in duplicate messages arriving at the handset. 3.1.4 What is a Final Negative Notification Status? A final negative notification is returned when SAP could not deliver a particular message and will not attempt a retry. The returned status code will indicate to the customer whether the message is retriable or not, in which case the customer can initiate their own retry process. There are no additional notifications sent after a final negative status. 3.1.5 What is a Retriable Status? A retriable status means that SAP will allow the customer to retry delivery of the message, although SAP itself will not be attempting the retry. 13

4 RECEIVING SMTP MESSAGES This section describes the format of SMTP messages exchanged from SAP SMS 365, enterprise service, to a third party upon reception of mobile originated short messages (SMS MO). The reception by SAP of SMS MO at destination of a registered CP will generate an SMTP message complying with this specification. 4.1 Message Format Below is the framework of the body of the SMTP messages sent by SAP: [SERVICE] Destination= [MSISDN] Phone= [MESSAGE] Text= [PARAMETERS] DCS= ReceivedTime= 4.1.1 SERVICE Section The SERVICE section contains the phone number or the shortcode of the destination of the SMS. The destination is a phone number given in international format (i.e., + International Country Code Phone Number). 4.1.2 MSISDN Section The MSISDN section contains the phone number of the originator of the SMS. The phone number is given in international format (i.e., + International Country Code Phone Number). Example: [MSISDN] Phone=+44777123123 4.1.3 Message Section The Message section contains the text sent by the mobile subscriber. The maximum length for this field is 160 characters when using DCS=7b. The specific markers <CR> (carriage return) and <LF> (line feed) are used to insert the special characters. 4.1.4 Parameters Section This section shows parameters of the message sent by the mobile subscriber. 4.1.4.1 DCS (Data Coding Scheme) This field specifies how the text of the short message is encoded. The value is given in decimal format. The Data Coding Scheme values are described in GSM 03.38 [1]. 4.1.4.2 ReceivedTime This field contains the reception date and time of the short message by SAP's network. 4.1.4.3 Coding: ReceivedTime=ddd, dd mm yyyy hh:mm:ss +GMT Where ddd stands for day (Mon) dd stands for day mm stands for month yyyy stands for year hh stands for hour mm stands for minute 14

ss stands for second Example: ReceivedTime= Wed, 3 Jul 2001 20:37:19 +0100 5 APPENDIX A: GSM DEFAULT ALPHABET The following list shows all authorized characters in a SMS message according to the GSM 03.38 specification. Some of these characters may not be available on all networks. The message text shall be coded using the Latin-1 format (ISO-8859-1). @ SP 0 i P p! 1 A Q a q $ 2 B R b r # 3 C S c s è 4 D T d t é % 5 E U e u ù & 6 F V f v ì 7 G W g w ò ( 8 H X h x (1) Ç ) 9 I Y i y LF * : J Z j z Ø + ; K Ä k ä ø, < L Ö l ö CR - = M Ñ m ñ Å. > N Ü n ü å /? O o à (1) This character is uppercase. The lowercase version of this character is not accepted by the GSM 3.38 specification. 15

6 APPENDIX B: ISO-8859-1 TO GSM 3.38 ALPHABET TRANSLATION An automatic translation is done when an unauthorized character is given in the text message. All the information of this translation is given in the ISO-8859-1 character set table below. Ch Dec Hex Description GSM 3.38 Default 032 20 Space No change! 033 21 Exclamation Point No change " 034 22 Double Quote No change # 035 23 Number/Pound No change $ 036 24 Dollars No change % 037 25 Percent No change & 038 26 Ampersand No change ' 039 27 Single Quote No change ( 040 28 Left Parenthesis No change ) 041 29 Right Parenthesis No change * 042 2a Asterisk No change + 043 2b Plus No change, 044 2c Comma No change - 045 2d Hyphen No change. 046 2e Period No change / 047 2f Forward Slash No change 0 048 30 Digit 0 No change 1 049 31 Digit 1 No change 2 050 32 Digit 2 No change 16

Ch Dec Hex Description GSM 3.38 3 051 33 Digit 3 No change 4 052 34 Digit 4 No change 5 053 35 Digit 5 No change 6 054 36 Digit 6 No change 7 055 37 Digit 7 No change 8 056 38 Digit 8 No change 9 057 39 Digit 9 No change : 058 3a Colon No change ; 059 3b Semicolon No change < 060 3c Less Than No change = 061 3d Equals No change > 062 3e Greater Than No change? 063 3f Question Mark No change @ 064 40 Commercial At No change A 065 41 Uppercase A No change B 066 42 Uppercase B No change C 067 43 Uppercase C No change D 068 44 Uppercase D No change E 069 45 Uppercase E No change F 070 46 Uppercase F No change G 071 47 Uppercase G No change 17

Ch Dec Hex Description GSM 3.38 H 072 48 Uppercase H No change I 073 49 Uppercase I No change J 074 4a Uppercase J No change K 075 4b Uppercase K No change L 076 4c Uppercase L No change M 077 4d Uppercase M No change N 078 4e Uppercase N No change O 079 4f Uppercase O No change P 080 50 Uppercase P No change Q 081 51 Uppercase Q No change R 082 52 Uppercase R No change S 083 53 Uppercase S No change T 084 54 Uppercase T No change U 085 55 Uppercase U No change V 086 56 Uppercase V No change W 087 57 Uppercase W No change X 088 58 Uppercase X No change Y 089 59 Uppercase Y No change Z 090 5a Uppercase Z No change [ 091 5b Left Bracket No change \ 092 5c Backslash / 18

Ch Dec Hex Description GSM 3.38 ] 093 5d Right Bracket No change ^ 094 5e Caret (Circonflex) No change _ 095 5f Underscore - ` 096 60 ASCII Grave ' a 097 61 Lowercase a No change b 098 62 Lowercase b No change c 099 63 Lowercase c No change d 100 64 Lowercase d No change e 101 65 Lowercase e No change f 102 66 Lowercase f No change g 103 67 Lowercase g No change h 104 68 Lowercase h No change i 105 69 Lowercase i No change j 106 6a Lowercase j No change k 107 6b Lowercase k No change l 108 6c Lowercase l No change m 109 6d Lowercase m No change n 110 6e Lowercase n No change o 111 6f Lowercase o No change p 112 70 Lowercase p No change q 113 71 Lowercase q No change 19

Ch Dec Hex Description GSM 3.38 r 114 72 Lowercase r No change s 115 73 Lowercase s No change t 116 74 Lowercase t No change u 117 75 Lowercase u No change v 118 76 Lowercase v No change w 119 77 Lowercase w No change x 120 78 Lowercase x No change y 121 79 Lowercase y No change z 122 7a Lowercase z No change { 123 7b Left Curly Bracket ( 124 7c Broken Vertical Bar / } 125 7d Right Curly Bracket ) ~ 126 7e Tilde - 128 80 (unassigned) E 129 81 (unassigned) Space 130 82 (unassigned) Space ƒ 131 83 (unassigned) Space 132 84 (unassigned) Space 133 85 (unassigned) Space 134 86 (unassigned) Space 135 87 (unassigned) Space 20

Ch Dec Hex Description GSM 3.38 ˆ 136 88 (unassigned) Space 137 89 (unassigned) Space Š 138 8a (unassigned) Space 139 8b (unassigned) Space Œ 140 8c (unassigned) Space 141 8d (unassigned) Space Ž 142 8e (unassigned) Z 143 8f (unassigned) Space 144 90 (unassigned) Space 145 91 (unassigned) Space 146 92 (unassigned) Space 147 93 (unassigned) Space 148 94 (unassigned) Space 149 95 (unassigned) Space 150 96 (unassigned) Space 151 97 (unassigned) Space 152 98 (unassigned) Space 153 99 (unassigned) Space š 154 9a (unassigned) Space 155 9b (unassigned) Space œ 156 9c (unassigned) Space 21

Ch Dec Hex Description GSM 3.38 157 9d (unassigned) Space ž 158 9e (unassigned) z Ÿ 159 9f (unassigned) Y 160 a0 Hard space Space 161 a1 Inverted Exclamation Point No change 162 a2 Cent c 163 a3 Pound/Sterling No change 164 a4 General Currency Symbol No change 165 a5 Yen No change 166 a6 Broken Vertical Bar I 167 a7 Section Sign No change 168 a8 Diaeresis Space 169 a9 Copyright C ª 170 aa Feminine Spanish Ordinal Space «171 ab Left Double Guillemet " 172 ac Logical Not Space 174 ae Registered Trademark R 175 af Beginning of Line Space 176 b0 Ring Space ± 177 b1 Plus or Minus Space ² 178 b2 Power of 2 Space 22

Ch Dec Hex Description GSM 3.38 ³ 179 b3 Power of 3 Space 180 b4 Acute Space µ 181 b5 mu Space 182 b6 Paragraph Sign Space 183 b7 Small Centre Dot Space 184 b8 Cedilla Space ¹ 185 b9 Power of 1 Space º 186 ba Masculine Spanish Ordinal» 187 bb Right Double Guillemet Space " ¼ 188 bc 1/4 Space ½ 189 bd 1/2 Space ¾ 190 be 3/4 Space 191 bf Inverted Question Mark No change À 192 c0 A Grave A Á 193 c1 A Acute A Â 194 c2 A Circumflex A Ã 195 c3 A Tilde A Ä 196 c4 A Diaeresis No change Å 197 c5 A Ring No change Æ 198 c6 AE Digraph No change Ç 199 c7 C Cedilla No change 23

Ch Dec Hex Description GSM 3.38 È 200 c8 E Grave E É 201 c9 E Acute No change Ê 202 ca E Circumflex E Ë 203 cb E Diaeresis E Ì 204 cc I Grave I Í 205 cd I Acute I Î 206 ce I Circumflex I Ï 207 cf I Diaeresis I Ð 208 d0 Uppercase Eth Space Ñ 209 d1 N Tilde No change Ò 210 d2 O Grave O Ó 211 d3 O Acute O Ô 212 d4 O Circumflex O Õ 213 d5 O Tilde O Ö 214 d6 O Diaeresis No change 215 d7 Multiply (x) * Ø 216 d8 O Slash No change Ù 217 d9 U Grave U Ú 218 da U Acute U Û 219 db U Circumflex U Ü 220 dc U Diaeresis No change 24

Ch Dec Hex Description GSM 3.38 Ý 221 dd Y Acute Y Þ 222 de Uppercase Thorn Space ß 223 df German Double s No change à 224 e0 a Grave No change á 225 e1 a Acute a â 226 e2 a Circumflex a ã 227 e3 a Tilde a ä 228 e4 a Diaeresis No change å 229 e5 a Ring No change æ 230 e6 ae Digraph No change ç 231 e7 c Cedilla Ç è 232 e8 e Grave No change é 233 e9 e Acute No change ê 234 ea e Circumflex e ë 235 eb e Diaeresis e ì 236 ec i Grave No change í 237 ed i Acute i î 238 ee i Circumflex i ï 239 ef i Diaeresis i ð 240 f0 Lowercase Eth o ñ 241 f1 n Tilde No change 25

Ch Dec Hex Description GSM 3.38 ò 242 f2 o Grave No change ó 243 f3 o Acute o ô 244 f4 o Circumflex o õ 245 f5 o Tilde o ö 246 f6 o Diaeresis No change 247 f7 Division / ø 248 f8 o Slash No change ù 249 f9 u Grave No change ú 250 fa u Acute u ü 252 fc u Diaeresis No change ý 253 fd y Acute y þ 254 fe Lowercase Thorn Space ÿ 255 ff y Diaeresis y 26

7 APPENDIX C: CREATING BINARY CONTENT 7.1 Ringtone Format The conversion process depends on the source of the ringtone format used. For Nokia phones, Midi or RTTL formats may be used as the source format. The output format for SMS is the OTA format. 7.1.1 Ringtone Creation With the Nokia Data Suite, launch the PC Composer tool and create/edit the desired ringtone(s) with it. When ready, save it as an.ott message. When viewed with a hex format editor, the resulting file should look something like the following: 024A3A51D195CDD008001B205505906105605585505485408208499000 The first 3 bytes code the smart messaging ringtones command information: 02 stands for 2 command parts 4A stands for the first command part: ringtone programming 3A stands for the second command part: sound The subsequent few bytes encode the song title (name of the.ott file), while the remaining bytes encode the ringtone content as follows: Bit string Description Value 01 <basic song type> 0100 <song title length> 4 characters (ISO-8859-1) 01110100 The first character T 01100101 The second character E 0111001 The third character S 01110100 The fourth character T 00000010 <song sequence length> 2 song patterns 000 <pattern header> Pattern header id 00 <pattern id> A-part 0000 <loop value> no loop 00001101 <pattern specifier> <length of the new pattern> 13 pattern instructions 100 <tempo instruction id> 27

Bit string Description Value 10000 <beats per minute> 160 (i.e. length of 1/4 note = 0,38 sec.) 001 <note instruction id> 0101 <note value> note E 010 <note duration> ¼ note 00 <note duration specifier> no special duration 001 <note instruction id>......... 0000000 <command end> 7.1.2 RTTL If the RTTL format is being used as the source format. The file will need to be converted to the MIDI format. 7.1.3 MIDI The MIDI file needs to be converted to an OTA file before being sent over SMS. Nokia PC Composer found in Nokia Data Suite 3.0 includes a MIDI-to-OTA converter. Note: Thirty-second notes from a MIDI file are replaced by eighteen-second notes in the OTA file. The tempo of the music may also be modified. To test the resulting ringtone with different mobile phones, use the phone s serial cable or infrared link and the Data Suite compatible with the target phone. This allows you to test the ringtone quality or length without actually sending it over SMS. If variations are noticed between MIDI and OTA files, you can modify either of them using the Nokia PC Composer music editor. 7.1.4 Mail Transfer Format Before sending the OTA file through SMTP, it has to be converted to ASCII-coded hexadecimal format. 7.1.5 Ports For this application, both the originating port and destination port values are 1581. The length value depends on the length of the ringtone. 7.2 Operator Logo Format The operator logo can be sent over SMS using the binary field, the specific originating port and the destination port. 28

7.2.1 Format Coding The NLM format looks like the following: 4E4C4D20010000480E0100000000000000000000000000000000000000000000000000000000000000038 0000000000000001C4000000000000003E0200000000001FFFC0020018000000600000010024000000000 000010044000000000000010183000000000000010E0300000000000000F00100000000000000000100000 0000000000001000 The first six bytes relate to the NLM coding. These bytes are removed by the LOGOTOASCII utility. The subsequent bytes form the PDU of the OTA bitmap. Inside this PDU, the first 4 bytes (the blue text above) contain bitmap data information. The first byte ("00") is the info-field of the smart messaging. The second byte ("48"), meaning 72 in decimal, is the pixel width of the bitmap. The third byte ("0E"), meaning 12 in decimal, is the pixel height of the bitmap. An operator logo bitmap is always 72*12 pixels. The fourth byte is the depth of the bitmap (the number of gray scales). All subsequent bytes encode the OTA bitmap data. Three other bytes must be added in front of the OTA PDU (following the Smart Messaging Specifications document from Nokia) they encode the operator s information. The first two bytes indicate the MCC (Mobile Country Code) of the operator. The third byte indicates the MNC (Mobile Network Code) of the operator. Each of these three bytes is coded in little-endian BCD filled with "F." For example, if the operator MCC = 208 and its MNC = 01, the three coded bytes are "02F810." The PDU corresponding is then the following: 02F81000480E01000000000000000000000000000000000000000000000000000000000000000380000000 000000001C4000000000000003E0200000000001FFFC00200180000006000000100240000000000000100 44000000000000010183000000000000010E0300000000000000F001000000000000000001000000000000 000001000 7.2.2 Ports For this application, both the originating port and destination port values are 1582. The length value is always 133. 7.2.3 Payload Explanation The NLM format looks like this: 4E4C4D20010000480E0100000000000000000000000000000000000000000000000000000000000000038 0000000000000001C4000000000000003E0200000000001FFFC0020018000000600000010024000000000 000010044000000000000010183000000000000010E0300000000000000F00100000000000000000100000 0000000000001000 The first six bytes provide the NLM coding. These bytes are removed by LOGOTOASCII utility. The subsequent bytes form the PDU of the OTA bitmap. Inside this PDU, the four first bytes (the blue text above) contain bitmap data information. The first byte ("00") is the info-field of the smart messaging. The second byte ("48"), meaning 72 in decimal, is the width of the bitmap. The third byte ("0E"), meaning 12 in decimal, is the height of the bitmap. A caller group logo bitmap is always 72*12 pixels. The fourth byte is the depth of the bitmap (the number of gray scales). All subsequent bytes form the OTA bitmap data. No other bytes need to be added in front of the OTA PDU. The overall PDU is therefore the following: 00480E01000000000000000000000000000000000000000000000000000000000000000380000000000000 001C4000000000000003E0200000000001FFFC00200180000006000000100240000000000000100440000 29

00000000010183000000000000010E0300000000000000F001000000000000000001000000000000000001 000 7.2.4 Ports For this application, both the originating port and destination port values are 1583. The length value is always 130. 7.3 Picture Messaging Picture messaging is a Smart Messaging feature defined in the Smart Messaging Specifications and in the Graphic Message Services (GMS) documents. Picture messaging is based on the transmission of a 72*24 pixel picture (i.e., larger than the operator logo or CLI one) together with an associated text (maximum 120 characters). It requires therefore the formatting of both the picture and text, and assembling them together in a long binary sequence. A picture messaging message is always longer than one short message. 7.3.1 Picture Coding An example of payload format is: 00481C01000000000000000000000000100000000000000000107E0000000000000039FF8000000000000 03BFF800000000000003FFFC00000000000003FF3C00000000000007FF3800000000000007FFF8000000 00000007FFFC0000000000000F7FFC0000000000000C7FFC000000000000103FF80101000000000000C6 39E53924E4800000AA4515452414800000AA45157D54F4800000924515415514800000924515448913000 0008239E53888F200000000000000000200000000000000000C000 Inside this PDU, the first 4 bytes (the blue text above) provide bitmap data information. The first byte ("00") is the info-field of the smart messaging. The second byte ("48"), meaning 72 in decimal, is the width of the bitmap. The third byte ("1C"), meaning 24 in decimal, is the height of the bitmap. A picture messaging bitmap is always 72*24 pixels. The fourth byte is the depth of the bitmap (the number of gray scales). All subsequent bytes form the OTA bitmap data. Four other bytes must be added in front of the OTA PDU (following the Graphic Message Services document from Nokia), which encode the GMS header. The first byte indicates the GMS version "30." The second byte indicates the type of the GMS item. OTA bitmap in the picture messaging stands for "02." The following two bytes indicate the size of the bitmap. For picture messaging, it is always 256 bytes "0100." The resulting overall PDU is therefore the following: 3002010000481C01000000000000000000000000100000000000000000107E0000000000000039FF80000 0000000003BFF800000000000003FFFC00000000000003FF3C00000000000007FF3800000000000007FF F80000000000000000000000000000000000000820105000000000000820101000000000000C6010100000 0000000C639E53924E4800000AA4515452414800000AA45157D54F480000092451541551480000092451 54489130000008239E53888F200000000000000000200000000000000000C000 7.3.2 Adding a Text Message to the Picture The coding of the message is the common ASCII representation of the text. In order to add text to the picture, the GMS header must come before the ASCII coding of the text. The GMS header is coded as follows: The first byte stands for the GMS version: 30. The second byte stands for the type of GMS item: 00 for ISO-8859-1 char. The two other bytes indicate the length of the text (in bytes). When text is added to the picture message, it must be added in front of the OTA bitmap. Moreover, the GMS version is only indicated one time in the message (relates to the two GMS items). For example, if we add the text AAA to the previous picture, the message will become the following: 3000000341414102010000481C01000000000000000000000000100000000000000000107E000000000000 0039FF800000000000003BFF800000000000003FFFC00000000000003FF3C00000000000007FF3800000 30

00000000000000000000000000000000000000000000000000820105000000000000820101000000000000 C60101000000000000C639E53924E4800000AA4515452414800000AA45157D54F4800000924515415514 8000009245154489130000008239E53888F200000000000000000200000000000000000C000 The GMS version is the first byte. The three following bytes encode the first GMS item (i.e., the text) noted in red. The ASCII coded text follows. After the text, is the GMS header (composed of three bytes noted in red) of the picture. Finally the 256 bytes of the picture itself appear at the end of the message. 7.3.3 Ports For this application, both the originating port and destination port values are 158A. 7.4 MIME vcard With a text editor, prepare the phone book entry with the following encoding format (see Smart Massaging Specifications [3]): BEGIN:VCARD N:<surname firstname> TEL:+<international phone number> END:VCARD For example : BEGIN:VCARD N:SAP Mobile Services TEL:+1555123456 END:VCARD This message must be translated in hexadecimal ASCII format and forms the PDU to be sent. For this application, both the originating port and destination port values are 00E2. 7.5 MIME vcalendar With a text editor, prepare the calendar entry with the following encoding format (see Smart Massaging Specifications [3]): BEGIN: VCALENDAR VERSION:1.0 BEGIN:EVENT DESCRIPTION:<text> DTSTART:<date>T<time> DTEND: <date>t<time> AALARM: <date>t<time>;;; END:VEVENT END:VCALENDAR For example : BEGIN:VCALENDAR VERSION:1.0 BEGIN:EVENT DESCRIPTION:SAP Mobile Services meeting DTSTART:20000906T090000 DTEND:20000906T120000 AALARM:20000906T084500;;; END:VEVENT END:VCALENDAR This message must be translated in hexadecimal ASCII format and forms the PDU to be sent. 31

For this application, both the originating port and destination port values are 00E4. 7.6 TTML TTML specifies downlink messages (from server to mobile) and uplink messages (from mobile to server). Concatenation of downlink messages is supported, but uplink TTML requests must be sent with only one SM. A TTML format always has the following syntax:..page name Message to appear on the mobile phone.>question.>*choice_1.>*choice_2.>*choice_x <<question with digit answer <question with alphanumeric entry ><Rmessage appearing for sending form Note: the ><R symbol used in the last line is for sending back the form. In the following example, the customer is given several choices from which (s)he needs to make a selection before sending the form back...example in TTML Have time for a few questions? >.Choose your service :.>*Weather info.>*traffic info.>*flight info <<Enter your code : ><Rready to send the form? This message just has to be converted in hexadecimal ASCII format and forms the PDU to be sent.for this application, both the originating port and destination port values are 15CC. 32

8 APPENDIX D: ERROR MESSAGES RETURNED DURING MESSAGE SENDING Value Message Text What to do? 5001 5001 Server currently unavailable to process your message, please try later. 5002 5002 Server currently unavailable to process your message, please try later. 5003 5003 Server currently unavailable to process your message, please try later. 5004 5004 Server currently unavailable to process your message, please try later. 5005 5005 Server currently unavailable to process your message, please try later. 5006 5006 Server currently unavailable to process your message, please try later. send an email to service.desk@sybase.com send an email to service.desk@sybase.com send an email to service.desk@sybase.com send an email to service.desk@sybase.com send an email to service.desk@sybase.com send an email to service.desk@sybase.com 600F 600F Authentication failure send an email to service.desk@sybase.com 6010 6010 Bad format for field DCS in section SETUP. check syntax of DCS field 6011 6011 Bad format for field PID in section SETUP. check syntax of PID field 6012 6012 Bad format for field MobileNotify in section SETUP. check syntax of MobileNotify field 6013 6013 Bad format for field MailAckType in section SETUP. check syntax of MailAckType field 6017 6017 Bad format or missing mandatory value for field Text in section MESSAGE. 6018 6018 Bad format or missing mandatory value for field List in section MSISDN. Text or Binary field must be fulfilled List field must be fulfilled 6019 6019 Bad format for field List in section MSISDN. check syntax of MSISDN field (coma separated) 601A 601A Bad format for field Class in section SETUP. check syntax of Class field 6024 6024 Bad format for field ValidityPeriod in section SETUP. check syntax of ValidityPeriod field 6026 6026 Bad format or missing mandatory value for field DestinationPort in section SETUP. DestinationPort= empty field 33

Value Message Text What to do? 6028 6028 Bad format or missing mandatory value for field Length in section MESSAGE. 6029 6029 Bad format or missing mandatory value for field Binary in section MESSAGE. must have Length when Binary field binary message must be prepended by Binary= 602A 602A The message contained an invalid character. check the message compared to GSM 3.38 table 602B 602B The message contained a an invalid binary string length. compare the length of binary field and Length= 6030 6030 Error when processing the message. send an email to service.desk@sybase.com 6100 6100 Error when processing the message. check message syntax 8000 8000 Server currently unavailable to process your message please try later. send an email to service.desk@sybase.com 34

9 REFERENCES [1] GSM TS 03.38: Digital cellular telecommunications system (Phase 2+); Alphabets and language-specific information (GSM 03.38 version 5.5.1) [2] GSM TS 03.40: Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS); Point-to-Point (PP) (GSM 03.40 version 5.7.1) [3] Smart Messaging Specification, Revision 2.0.0 Nokia Mobile Phones Ltd [4] Graphic Message Service Syntax, Revision 1.0.0 Nokia Mobile Phones Ltd Nokia FAQ: http://www.forum.nokia.com/ 35

www.sap.com 2013 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ( SAP Group ) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.