Smpp Interface Manual-En

VIDEOSMS SMPP Interface Manual v. 1.2

VideoSMS

VIDEOSMS SMPP Interface Manual How to interconnect your SMPP server

with MCTEL SMS gateway

Version: 1.2

Date: August 25, 2004

MONACO TELEMATIQUE MC-TEL

25, boulevard d'Italie, B.P. 225, MC 98004 MONACO Cedex Phone: (+377) 9216 8888

Fax: (+377) 9216 8865 SMS technical support email: [email protected] sales email: [email protected]

Web: http://www.mctel.net and http://www.smsfax.com

Monaco Telematique MCTEL 1 August 2004

mailto:[email protected]

mailto:[email protected]

http://www.mctel.net/

http://www.smsfax.com/


Other documents This manual is part of the VideoSMS documentation. VideoSMS is an integrated mobile messaging and server solution allowing the sending of SMS and other message types (fax, telex, email, voice), the checking of their successful transmission, the building of Premium SMS applications with high value added contents. Other manuals of the VideoSMS documentation include:

• the manuals of the client/server SMS interface and development tools: o The HTTP/HTML Interface is described in the "VideoSMS HTTP/HTML

Interface Manual". o The FTP/XML Interface is described in the "VideoSMS FTP/XML Interface

Manual". o The VideoSMS Application Programming Interface is described in the

"VideoSMS Application Programming Interface Functions Manual" and in the guide "How to develop with VideoSMS Interfaces and API".

• the VideoSMS/Gateway SMS server and messaging platform has its own complete documentation set (installation, management, development tools).

Monaco Telematique MCTEL also supplies other messaging and network software:

• Fax gateways (VideoTelefax), telex gateways (Videotélex), pagers (VideoAlphaPage). • Videotex servers (VideoNet) and gateways (VTX/Gate), multimedia servers

(EuroVemmi). • Advanced firewall solutions (WebAccess).

Proprietary Information The information contained in this document is the property of Monaco Telematique MCTEL and may be the subject of patents pending or granted, and must not be copied or disclosed without prior written permission. Monaco Telematique MCTEL endeavours to ensure that the information in this document is correct but does not accept liability for any error or omission. The development of Monaco Telematique MCTEL products and services is continuous and published information may not be up to date. It is recommended to check the latest manual release with Monaco Telematique MCTEL or on http://www.smsfax.com

Document Revision

Rev Date By Detail 1.0 01-MAR-04 DM First release 1.1 15-MAY-04 DM Minor changes and improvements 1.2 25-AUG-04 DM, EL Individual manual for SMPP interface




Contents

Other documents........................................................................................................................ 2

Proprietary Information............................................................................................................ 2

Document Revision.................................................................................................................... 2

Contents ..................................................................................................................................... 3

Introduction ............................................................................................................................... 5

Introduction .......................................................................................................................... 5

The SMPP Protocol.............................................................................................................. 5

Other SMS development tools............................................................................................. 6 SMPP Protocol ................................................................................................................... 7 HTTP/HTML Web Interface.............................................................................................. 7 The FTP/XML FPI (File Programming Interface)............................................................. 7 The SMS API (Application Programming Interface) ........................................................ 7 SMTP email Interface ........................................................................................................ 8 VIDEOSMS/PC Software .................................................................................................. 8

Glossary................................................................................................................................. 8

SMPP setup and validation..................................................................................................... 10

Prerequisites for SMPP interconnect ............................................................................... 10

Validation phase ................................................................................................................. 10

Using MCTEL SMPP Gateway .............................................................................................. 12

SMPP SMS Gateway configuration.................................................................................. 12 MCTEL SMSC architecture............................................................................................. 12 Firewall............................................................................................................................. 12

Supported versions and PDUs........................................................................................... 13

Supported TLV................................................................................................................... 14

Connecting to the MCTEL SMS SMPP Gateway........................................................... 15 TCP/IP connection ........................................................................................................... 15 X.25 connection ............................................................................................................... 16

SMPP binding..................................................................................................................... 16

Keep-alive............................................................................................................................ 16

Burst traffic and throttling................................................................................................ 17

Parameters for submit_sm PDU ....................................................................................... 17

Sending large size SMS...................................................................................................... 19

Using character sets ........................................................................................................... 19

Specifying sender identification ........................................................................................ 20

Delivery Notification Format ............................................................................................ 20



ID...................................................................................................................................... 20 Status ................................................................................................................................ 20 Error ................................................................................................................................. 21 Status and error information TLV.................................................................................... 21

Unbinding............................................................................................................................ 21

SMS-MO management when Receiver/Transceiver not connected .............................. 21

Examples ............................................................................................................................. 22

Data security ....................................................................................................................... 22 Firewalls to access smppgateway.mctel.com................................................................... 22 User Authentication.......................................................................................................... 22 Data Encryption................................................................................................................ 22

Appendix 1: Example of SMPP requests................................................................................ 24

Appendix 2 – Error status listing ............................................................................................ 26

Appendix 3 – GSM default alphabet....................................................................................... 28

The 7 bits default GSM alphabet ...................................................................................... 28 GSM 7 bit default alphabet extension table ................................................................. 29

Converting ISO 8859-1 (International Reference Alphabet IRA) to GSM .................. 29



Introduction

Introduction Using MCTEL offer, integrating SMS features to any computer application or Web service is very easy and could be setup almost immediately. Several methods could be used to send the SMS (all documents could be downloaded from http://www.smsfax.com ):

• SMPP protocol between your server and MCTEL SMS gateway, described in this document.

• FTP/XML file interface, described in the "VideoSMS FTP/XML Interface Manual". • HTTP/HTML Web interface, documented in the "VideoSMS HTTP/HTML Interface

Manual". • SMTP email interface. • The VideoSMS Application Programming Interface (API), described in the

"VideoSMS Application Programming Interface Functions Manual". This manual is destined to specialized readers having already a good knowledge of mobile networks and SMS. Please refer to other MCTEL documents for more general information about SMS.

Purpose The purpose of this document is to guide MCTEL customers on the SMPP requirements whilst connecting to the MCTEL SMPP gateways.

Scope The scope of the document is to define how MCTEL SMPP implementation (offered by VIDEOSMS/Gateway SMPP Interface) compare to the SMPP specifications (v. 3.3 to v.5.0).

The SMPP Protocol SMPP stands for Short Message Peer to Peer. It is an open industry standard messaging protocol, relatively easy to implement, allowing a SMS client system to connect to a SMS Gateway (e.g. MCTEL gateway) to access mobile networks in order to send and receive SMS messages to/from mobile recipients. SMPP is widely used in the mobile telecommunications industry, several versions are available, all supported by MCTEL software:

• SMPP version 3.3: "Short Message Peer to Peer (SMPP) Interface Specification", v.3.3, 14-Jan-1996, Aldiscon Ltd (now Logica plc.).




• SMPP version 3.4: "Short Message Peer to Peer Protocol Specification", v3.4, 12-Oct-1999, Issue 1.2, SMPP Developers Forum.

• SMPP version 5.0: "Short Message Peer to Peer Protocol Specification", version 5.0, 19-Feb-2003, SMS Forum.

All those specifications are available from http://smsforum.net/doc/public/Spec MCTEL recommends using SMPP protocol in the following cases:

• you already have a SMPP interface linked to an operator and want to keep the existing architecture.

• you have purchased a SMPP software from a well-known supplier (e.g. MCTEL). • you intend to connect to several SMS gateways (such MCTEL gateway and other)

simultaneously and want to use a single standardized protocol for all of them.

Figure 1: Example of SMPP usage in a SMS network (reprinted from SMPP Specification v. 5.0)

Other SMS development tools Several development tools are at your disposal to process SMS :

• the SMPP protocol described in this document. It requires you run a SMPP compatible SMS server software on your host system.

• the FTP/XML file interface described in the "VideoSMS FTP/XML Interface Manual". • the HTTP/HTML Web interface, documented in the "VideoSMS HTTP/HTML

Interface Manual". • the SMTP email interface. • The VideoSMS Application Programming Interface (API), described in the

"VideoSMS Application Programming Interface Functions Manual".


http://smsforum.net/doc/public/Spec


• the VideoSMS/PC Desktop SMS sender, with Outlook and Exel integration, is also available.

SMPP Protocol The SMPP protocol describe the interworking between a SMPP server and a SMPP gateway in order to allow the SMPP server to send SMS-MT messages to mobile users through the SMPP gateway and to receive SMS-MO incoming messages from mobile users. Several SMPP versions exist (3.3, 3.4, 5.0) and are currently in operation.

HTTP/HTML Web Interface This interface is very simple to use, either from a computer application or a Web service: a simple HTTP GET or POST request with appropriate attributes to the MCTEL SMS Gateway allows either to send a SMS message or to check its successful transmission. Please refer to the "VideoSMS HTTP/HTML Interface Manual" for this interface specification.

The FTP/XML FPI (File Programming Interface) This interface is well suited to the one-time bulk transmission of numerous SMS. Data specifying the SMS to be transmitted are store in XML format text files, easy to create from any computer application. The text files are transmitted by FTP to the VideoSMS FTP gateway. Please refer to the "VideoSMS FTP/XML Interface Manual" for this interface specification.

The SMS API (Application Programming Interface) The VideoSMS Application Programming Interface includes functions to be linked with your computer applications, complete documentation, include files, and examples. Releases are available for each supported operating systems:

• Windows. • Unix:

o Linux. o HP HP-UX o HP/Compaq/Digital True64 Unix. o IBM AIX o Sun Solaris o Unix-SCO

• OpenVMS: Alpha, VAX or Itanium. The VideoSMS Application Programming Interface is described in the "VideoSMS Application Programming Interface Functions Manual" and in the guide "How to develop with VideoSMS Interfaces and API".



SMTP email Interface You could also send SMS directly by email using the VideoSMS STMP Gateway, from any mail sender.

VIDEOSMS/PC Software If you do not want to integrate SMS features in your computer application or Web service, but simply use an easy to use PC application with Outlook integration to send SMS, you could download and install the free VideoSMS/PC SMS Desktop sender from www.smsfax.com.

Glossary

• Alias : in several countries, on Premium SMS services, the user mobile number (MSISDN) is masked by the operator and replaced by an unique alias number, in order to avoid the creation of unauthorized mobile numbers databases for marketing purposes byh the information provider.

• EMSE = External Short Message Entity: Network element sending and/or receiving SMS by interworking (e.g. with SMPP) with mobile network SMS-C.

• Short code : abbreviated number (usually from 4 to 6 digits) allocated to a SMS server running Premium SMS applications and allowing the user to send his/her message to a short code easy to remember instead of a 10 digits full mobile number.

• OTA (Over the Air) : this technology is used to download binary data to a mobile phone, for example : logos, ringtones, email or Wap configuration download by the mobile operator, SIM card customization by mobile network operator.

• PDU: Protocol Data Unit: request or answer SMPP command block. • Push-SMS : sending an unsolicited SMS-MT to a mobile user. • SMS = Short Message Service : short text or binary message exchanged between two

mobile phones1 or a mobile phone and a computer application. • SMS-C : SMS Service Center : is the SMS transmission platform run by the mobile

operator. It uses a specific protocol to exchange SMS messages between mobile phones and the VIDEOSMS software (either installed on a customer system or run by the Monaco Telematique shared host center). The SMS-C use a store and forward technology allowing it to store a message until a given mobile phone becomes reachable. Monaco Telematique VIDEOSMS software is able to interwork with any SMS-C worldwide.

• SMS-MO (Mobile Originated) : SMS sent from a mobile phone. • SMS-MT (Mobile Terminated) : SMS sent to a mobile phone. • TLV: Tag/Length/Value, optional parameter for SMPP PDU. • UDH = User Data Header: binary header at the beginning of the SMS User Data

field used to specify network or message options. • UDHI = User Data Header Indicator: flag set to specify the SMS message include at

the beginning a valid UDH. • WAP = Wireless Application Protocol

1 In numerous countries, it is also possible to send and receive SMS message from ordinary or advanced phones connected to the switched telephonic network.






SMPP setup and validation

Prerequisites for SMPP interconnect The following prerequisites must be met before using SMPP protocol between your server and MCTEL SMS Gateway:

• your server must have a SMPP-compliant SMS software server installed. • you must be a MCTEL customer and have subscribed as a LA (Large Account). Only

corporate large accounts are allowed to connect using SMPP protocol. • your SMPP software must be:

o either provided by a major manufacturer in the field (e.g. Logica, MCTEL, and so on.).

o or already tested and operational over links to another SMS operator or first checked by MCTEL over a temporary link to our test SMPP gateway.

• If your network is secured by a firewall, it must be configured to allow SMPP outgoing calls to the SMPP SMS gateway of Monaco Telematique, on the SMPP port supplied by MCTEL.

• MCTEL must also open the TCP/IP address of the calling system in our firewalls.

SMPP Request/Response

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

VAX 6240

SMPP Indication/Confirm

Customer client SMPP application

MCTEL VIDEOSMS SMPP Gateway

Figure 2: MCTEL VideoSMS gateway communication using SMPP protocol

Validation phase If your SMPP software has not been supplied by MCTEL or other well-known manufacturer and validated in a running environment, you will have first to undergo a validation phase on our test SMPP gateway before being allowed to connect to our live gateways, in order to eliminate any obvious problem. The test SMPP gateway will allow you to send messages but offer a lower throughput. The following conditions are tested during the compliance test:



• the SMPP client software binds correctly to the gateway using either bind_transmitter or bind_tranceiver.

• the client software issues a single bind attempt for a tranceiver or a couple of transmitter/receiver (multiple binds not allowed).

• the client software manage correctly a disconnection from our SMPP server and will automatic rebind when disconnected from our gateway in a timeframe < 5 mn.

• the enquire_link interval is set to 60 seconds (less than 90 seconds). • correct management of SMPP sequence numbers. • correct PDU formatting, PDU exchange and SMPP client sofware behavior for at least

the following PDU: o bind/unbind. o enquire_link/enquire_link_resp. o submit_sm/submit_sm_resp. o deliver_sm/deliver_sm_resp.

Those tests will be followed by a 1 week stability period of the application on the validation SMPP Gateway. If problem become apparent during this cycle, MCTEL may recommend that the application be returned to the development phase.



Using MCTEL SMPP Gateway

SMPP SMS Gateway configuration

MCTEL SMSC architecture The connectivity to the MCTEL and international SMSCs is provided via the MCTEL Mobile Gateway Access (MGA) which is responsible for loadsharing the messages and determining the routing of the messages. The options available to connect to the SAG are via a fixed line, an X.25 connection or the Internet (usually Internet is used). In normal operation, all SMS gateways carry live traffic at any time.

SMSC1

Service Provider

SMSC2

MGA

SMSC3

Internet

F/W

SMPP Transmitter PDUSMPP Receiver PDU

The MGA consists of a pair of clustered servers, with a network of routers and switches thus presenting a single IP address to the customers and allowing service resiliency in case of failure.

Internet Access through Firewalls For the Service Provider to be able to connect into the SMPP gateway, access for the Service Provider’s server IP address must be set up in the MCTEL Firewall(s). The customer must also configure its own firewall(s) in order to allow outgoing access to MCTEL SMPP server address.



It is the responsibility of the Service Provider to notify MCTEL of any change in the public IP address of the Service Provider server. At least one-week notice prior to the change must be given to have guaranteed access after the switch over.

SMSCRouter

TCP/I P

Customer LAN

SMS Serverrunning SMPP

applicat ion

TCP/I P

MCTELfirewall

Internet TCP/I PTCP/I P

Customer firewall

Router

X.25 Access The customer may also access MCTEL SMPP SMS Gateway through an X.25 line, providing his SMPP software supports native X.25 links.

SMSC

X.25 interface

PC/Serverrunning SMPP

application

X.25modem

X.25Public X.25 network

X.25X.25

X.25modem

Supported versions and PDUs When using the SMPP protocol, the customer computer application will communicate with MCTEL SMPP SMS Gateway by exchanging SMPP PDU (Protocol Data Units) with the requests to be processed. Requests are available to perform various kind of operations:

• authentication • sending and receiving SMS messages. • retrieving detailed status of a SMS message previously submitted.

The table below lists the supported PDU for all supported SMPP versions. Supported PDU are marked with a , the PDUs that do not exist in a given SMPP version are filled with grey.



PDU 3.3 3.4 5.0 Comments Client to server

bind_transmitter bind_receiver bind_transceived Use of bind_transceiver is recommended

(please note this PDU is not supported by SMPP 3.3 protocol).

submit_sm submit_multi enquire_link Set the enquire_link interval to 60 secondsdeliver_sm_resp query_last_message This command is now obsolete query_sm cancel_sm replace_sm data_sm broadcast_sm and broadcast ancillary operations alert_notification unbind

Server to client bind_transmitter_resp bind_receiver_resp bind_transceiver_resp submit_sm_resp submit_multi_resp enquire_link_resp deliver_sm query_sm_resp cancel_sm_resp replace_sm_resp data_sm_resp broadcast_sm_resp and broadcast ancillary operations generic_nack

Supported TLV The following optional TLV are supported (TLV mechanism have been introduced only from SMPP 3.4, TLV must not be specified when using a lower SMPP version).



TLV Usage Comments additional_status_info_text textual description of the

meaning of a response PDU used to convey detailed information about errors

billing_identification contains the billing information for this message

SMPP v. 5.0 only

dest_addr_subunit mainly used to specify flash messages

destination_port destination address port number message_payload contains the user data to be

transmitted Use of message_payload is mandatory when message size exceed 254 octets

message_state final message state for an SMSC delivery receipt

network_error_code indicate the actual network error code for a delivery failure

receipted_message_id ID of the message being receipted in an SMSC delivery receipt

match the message identifier returned by the submit_sm_resp PDU, also specified in the delivery receipt text

sar_msg_ref_num sar_total_segments sar_segment_seqnum

used to specify concatenation information

Usually not needed as the SMPP gateway will manage by itself the message splitting and concatenation and built appropriate UDH

sc_interface_version specify the SMPP version supported

value and SMPP behavior adjusted automatically to match caller SMPP version

source_port source application port number user_message_reference private reference assigned by

sender application

Connecting to the MCTEL SMS SMPP Gateway

TCP/IP connection The client should open a SMPP link to the VIDEOSMS SMPP Gateway and wait for the gateway response before issuing the SMPP bind_transmitter or bind_transceiver command. The following address is used to connect to the gateway:

• smppgateway.mctel.fr The calls should be made to the symbolic DNS name of the SMPP gateway (smppgateway.mctel.fr) instead of its IP address because several systems offering load balancing and fault tolerant configuration and used and because furthermore the IP address of the gateways are subject to change without prior notice.


http://smppgateway.mctel.fr/


Optionally, a Virtual Private Network (VPN) may be setup between your network and MCTEL network in order to provide additional safety using data encryption.

X.25 connection On request, the connection may also be performed over X.25 network for better performances and additional data confidentiality.

SMPP binding Only one Receiver/Transmitter pair or one Transceiver per SMPP account can be bound into the SMPP MCTEL Gateway at any time. Multiple connections are not allowed. MCTEL recommends you use when possible a single Transceiver connection instead of a pair of Receiver/Transmitter connections. The SMPP login on the gateway performed by the bind_transmitter or bind_transceived command must use the username and password supplied to you by MCTEL. The addr_range parameter must be set to NULL (x00). The MCTEL SMPP Gateway simultaneously supports SMPP version 3.3, 3.4 and 5.0 and will automatically exchange the corresponding PDU according the value of the interface_version parameter in the bind operation:

• interface_version < 0x34: SMPP v. 3.3 • interface_version = 0x34: SMPP v. 3.4 • interface_version = 0x50: SMPP v. 5.0

The time-out for a connection request should be set to at least 30s. For other commands not mentioned in this section, the time-out suggested is 10s. If a connection request fails, it should be re-attempted every minute for five minutes and then every five minutes thereafter. The failure to connect should be alarmed and if thought to be due a fault with MCTEL’s infrastructure, it should reported through the agreed support channels.

Keep-alive Upon binding in the Receiver/Transmitter/Transceiver, the session should be kept alive and its integrity monitored by sending enquire_link messages are regular intervals. The enquire_link time should be set to 60 secondes. This means that enquire_link commands should be sent after every 60 seconds on inactivity in the session (the SMPP Gateway timeout is set to 120 seconds by default and the client timer must be lower to take in account possible delays during transmission over TCP/IP or X.25 networks). If the enquire_link_resp response is not received within a certain period (we suggest 15s), the connection should be assumed terminated and should be closed then reinitiated.



Burst traffic and throttling The MCTEL Gateway offers windowing (default window = 5) and each customer SMPP client is throttled by default at 5 messages/second. That means the Service Provider must not broadcast MT messages from its applications to different handsets with rates higher than 5 message/second. The effective rate may be lower depending on the speed and quality of the link between MCTEL and the customer. For some applications (ex: real time Premium voting applications), the SMS-MO and SMS-MT throughput must be higher. In this case, the throttling value of the account could be adjusted. A subscription extension must be purchased from MCTEL and also usually from the network operator(s) onto the Premium shortcodes are connected.

Parameters for submit_sm PDU The following parameters must be set for the submit_sm PDU, optional TLV could be specified:

Parameter Value Comments Mandatory Parameters

service_type = 0 Do not use source_addr_ton Type of Number = 1 0: Unknown or not specified

1: International numberic address 5: Alphanumeric

source_addr_npi Not used source_address Not needed. However, you could

specify either a numeric address (source_addr_ton = 1 and source_addr_npi = 1) or an alpha tag of up to 11 alphanumeric characters (source_addr_ton = 5 and source_addr_npi = 0).

Transmission of such a customized sender address is not warranted and depends of the network and route used. In some cases, the specification of this information may increase the SMS cost, as a more expensive route may have to be selected for SMS transmission in order to ensure transmission of this information.

dest_addr_ton Type of Number: • 1: International number: to be

used for all non-Premium operation

• 2: only used for Premium National aliased number

Use always 1 as type for all non-Premium Push-SMS operation, where destination_address is specified in international format. Type 2 must be used for Premium operations with aliased numbers.

dest_addr_npi Numbering plan indicator = 1 Usually 1 (may be 4 for Telex) destination_address Recipient mobile number in

international format (may also be a fax number)

Preceded by country code without + or 00, for example 33612345678. For Premium requests using aliased number, specify the complete alias number without country code.



esm_class The following bits may be positionned:

• bit 6 (64): UDHI indicator: the message includes at the beginning a User Data Header built be the application

Application is responsible for building a valid UDH. In this case, it is prohibited to use TLV for specification of the concatenation information or port numbers, all these informations are to be correctly encoded in the supplied UDH.

protocol_id Type of message to send : • 0 : SMS (default) • 1 : Telex • 2: Fax (G3) • 14: email

The SMPP center has fax and telex capabilities (the LA account must have access to those features enabled).

priority_flag = 0 Not used schedule_delivery_time Deferred delivery date/time for

deferred messages, format SMPP time.

validity_period Message expiration date : the message will be discarded if the delivery could not succeed before the expiration date. Encoded as above

SMSC default validity period is usually 3 days (72 hours)

registered_delivery Delivery receipt : • 0: no SMSC delivery receipt

requested • 1: SMSC delivery receipt

requested where final delivery outcome is delivery success or failure.

Usually set to 1

replace_if_present_flag = 0 Not used data_coding Encoding alphabet:

• 0: SMS • 1: ISO 8859-1 (Iso Latin 1) • 2: binary data

Usually 1

sm_default_msg_id = 0 Not used sm_length Length of short_message, up to 254

octets. For messages larger than 254 octets, store the message content in the message_payload TLV and set the sm_length to 0.

short_message Content of the message : • Text message, encoded

according selected character set.

• Message with binary payload

The SMPP gateway will return a submit_sm_resp PDU with the unique systemwide message_id of 32 hexadecimal characters assigned to the message (when SMPP 3.3 is used, the message_id only contains 8 hexadecimal characters and is not unique systemwide but customer specific). The optional TLV are supported by the submit_sm command:

• dest_addr_subunit: for example, set to 1 to display the SMS in flash mode. • dest_port and source_port are used for binary messages.



• the use of concatenation TLV is possible but not recommended as the SMPP gateway manage the concatenation itself.

Sending large size SMS A single text SMS message could not exceed 160 characters (80 when Unicode alphabet is used for non-latin language), and a single binary SMS message could not exceed 140 bytes. It is nevertheless possible to send bigger SMS messages: they will be automatically split into several smaller messages and concatenated by the recipient mobile phone. The SMPP gateway will automatically take charge of the SMS splitting and concatenation and build the needed UDH including concatenation information: there is no need for the application to split the message in several parts. A single SMS of large size will be supported by the gateway, up to 254 characters may be transmitted in the short_message field, for larger messages the data must be passed in the message_payload TLV (SMPP v. 3.4 minimum needed). Regarding SMS message size :

• A single SMS message may contain up to 160 alphanumeric characters encoded to GSM format2. If the message size is greater, the message will be split in several parts transmitted as separated SMS. The recipient mobile phone will automatically concatenate the received parts in order to reconstitute the original complete message. On most phones, up to 3 parts are supported, allowing a maximum message size of 469 characters (less than 160 x 4, because for concatenated messages, 7 header bytes are used to store concatenation information).

• A binary SMS could contain up to 140 bytes. It is also to split a greater message to transmit up to 384 bytes in 3 SMS messages.

Number of SMS

messages Alphanumeric characters size Binary data size

1 1 to 160 1 to 133 2 161 to 206 134 to 256 3 207 to 469 257 to 384 43 470 to 623 385 to 512

In order for an application to be able to send a large message, the easier way is to send to the mobile a Wap Push SMS message enabling the recipient to automatically connect and display a Wap page containing the data (provided the recipient subscription and phone are Wap enabled).

Using character sets

2 If the SMS alphabet encoding used is Unicode, usually used for non-latin alphabets (arabic, japanese, chineese), the size of a single SMS message could not exceed 70 Unicode characters. 3 Numerous phones does not support the sending of more than 3 concatenated messages. Except if the recipient phone is known to support them, it is therefore not recommended to send messages of more than 469 alphanumeric characters 384 binary bytes.



• Try to use Ascii ISO 8859-1 (IsoLatin 1) characters also present in the GSM character set. If you use ISO 8859-1 characters not existing in the GSM character set (for example sparsely used accented characters), they will be replaced by their nearest equivalent (e.g.: â by a) or if no equivalent cound be found by a '?'. The Appendix 2 shows the GSM character set along with the ISO 8859-1 to GSM translation.

• If needed, you could use Unicode alphabet to transmit non-latin characters (arabic, russian, greek4, japanese, chineese, etc.). Using the Unicode alphabet will limit the number of characters for a single SMS to 70 instead of 160.

Specifying sender identification Depending on the country and mobile network operator of the recipient and your account profile, the SMS you will send may bear your mobile phone identification number, your company alphanumeric identifier, or may be sent from a generic SMS short id. When the SMS is sent from a generic short id, you must include within the SMS text the needed information allowing the recipient to understand whom has sent him a message. Usually, this information is presented either at the beginning of the message (e.g.: MCTEL: message body) or at the end of the message (e.g. send from MCTEL).

Delivery Notification Format When requested, the delivery notifications regarding transmitted SMS are returned to the Service Provider in a deliver_sm PDU with esm_class set to SMSC Delivery Receipt (bit 3 set = 4). The notification is stored in the deliver_sm short_message field. The SMPP protocol specification states the format of the Delivery Receipt message is vendor specific. The layout is explained in detail in this section. “id:<ID> sub:nnn dlvrd:nnn submit date:<DDMMYYhhmmss> done date: <DDMMYYhhmmss> stat:<status> err:<error> text:<text> ...”

ID The "message id" returned by the submit_sm_resp PDU is encoded on 32 hexadecimal characters (except in the case of SMPP v3.3 where the message id is encoded on 8 hexadecimal characters).

Status The values for the <status> field are:

4 Instead of using Unicode character set for Greek messages, the best solution is usually to take advantage of the Greek characters included in the GSM character set, however only uppercase characters will be available.



ENROUTE : Message en route to intended recipient (may have been received on some networks that does not return always the delivery receipt).

DELIVRD : Message delivered to destination RETRYIN : Message cannot be delivered – retrying SCHEDLD : Message scheduled for delivery (e.g. delayed SMS) UNDELIV : Message cannot be delivered and has been discarded. Refer to the

precise error cause for explanation. EXPIRED : Message validity period expired – message deleted DELETED : Message deleted REJECTD : Message rejected by the gateway for network-specific reasons UNKNOWN : Status unknown

Error The error field encode on 5 digits the error cause, encoded as specified in Appendix 4.

Status and error information TLV In order to offer a better interworking between SMPP systems, when SMPP v3.4 or more is used, the message state and error code are also returned encoded in numeric format in the message_state and network_error_code TLV that are included in the delivery report. They are more easy to decode than the text notification described above. It remain usually necessary to decode the text notification to extract the done date field when the mobile reception timestamp is needed.

Unbinding When the Service Provider wishes to disconnect the SMPP Receiver/Transmitter/Transceiver for whatever reason, the SMPP unbind PDU must be issued conforming to SMPP specifications. However in all cases the disconnection will be managed properly even if this PDU is not issued (e.g. network link layer going down).

SMS-MO management when Receiver/Transceiver not connected If a Mobile Originated message is sent to the Service Provider number (either short code or long number) at a time when the Receiver is not bound into the SMPP Gateway, then the message will be buffered by the SMSC and retried at certain intervals. Especially when managing incoming SMS-MO requests, it is the nature of SMPP connections to be connected at all times, in order to offer a good quality of service to the customer. However, if a SMPP receiver is not connected all the messages will be buffered until either SMS expiration time or Receiver/Transceiver connection.



All SMS-MO messages accepted by the SMSC will be stored for maximum 3 days, during which time the SMSC will attempt to deliver the message. If it’s still not delivered after this time the message will be expired and deleted. Depending on the error and expiration time assigned to it, the message can expire before 3 days.

Examples Refer to Annex 1.

Data security

Firewalls to access smppgateway.mctel.com The customer firewall(s) must be configured to allow outgoing SMPP calls to the SMPP port assigned to the customer by MCTEL. If needed, configure your company firewall in order to allow outgoing requests to smppgateway.mctel.com, on the SMPP port specified by MCTEL. At account configuration, MCTEL will configure your TCP/IP address in MCTEL firewalls.

User Authentication The standard user authentication use standard SMPP username/password mechanism:

• By default (see below), those identifiers are not encrypted. • Additionally, we check TCP/IP caller address and only authorized addresses could

pass through our firewall to access our SMPP servers. • If needed and for large corporate accounts, additional security mechanisms (HTTPS

encryption, Virtual Private Network (VPN) between customer computer and MCTEL gateway) may be setup if needed.

Data Encryption When TCP/IP network is used, data exchanged using SMPP are not encrypted. When transmitting sensitive data, we recommend either:

• to setup a VPN (Virtual Private Network) or a VPN Tunnel with data encryption between your network and MCTEL network.

• or to use X.25 as transport network.

Fault Finding In the event of a connection or message sending problem, the following checks should be done before calling for support:





• Is general internet access affected (or X.25 access if relevant)? • Can the MCTEL IP address be “pinged” successfully?

MCTEL support will also require:

• Name of third party • Name of service (or application) if third party has more than one connection • Confirmation that no application or firewall changes have been made by the third

party that may have affected the service • Nature of problems – e.g. persistent connections and disconnections, messages failing

to be submitted, messages failing to be delivered etc. - the more specific the better. The application should also have the ability to sink and source test messages if required, in order to facilitate fault finding and testing.



Appendix 1: Example of SMPP requests Here is some examples of SMPP requests.

Binding to MCTEL Gateway

bind_transceiver PDU Sample PDU (Values are shown in Hex format): 00 00 00 2F 00 00 00 09 00 00 00 00 00 00 00 01 53 4D 50 50 33 54 45 53 54 00 73 65 63 72 65 74 30 38 00 53 55 42 4D 49 54 31 00 34 01 01 00 The 16-octet header would be decoded as follows: 00 00 00 2F => Command Length 0x0000002F 00 00 00 09 => Command ID 0x00000009 (bind_transceiver) 00 00 00 00 => Command Status 0x00000000 00 00 00 01 => Sequence Number 0x00000001 The remaining data represents the PDU body (which in this example relates to the bind_transceiver PDU). This is diagnosed as follows: 53 4D 50 50 33 54 45 53 54 00 system_id (“SMPP3TEST”) 73 65 63 72 65 74 30 38 00 password (“secret08”) 53 55 42 4D 49 54 31 00 system_type (“SUBMIT1”) 34 interface_version (0x34 “V3.4 compliant”) 01 addr_ton (0x01) 01 addr_npi (0x01) 00 addr_range (NULL)

bind_transceiver_resp PDU In answer, the MCTEL SMPP returns a bind_transceiver PDU: 00 00 00 1E 80 00 00 09 00 00 00 00 00 00 00 01 53 4D 50 50 54 45 53 54 4D 43 54 45 4C 00 It can be broken down into the following sections: Header: 00 00 00 1E => command_length 80 00 00 09 => command_id => TRANSCEIVER_RESP 00 00 00 00 => command_status (x0000000 = OK) 00 00 00 01 => sequence_number (the sequence number must be identical to the value set for the operation)



Body: 53 4D 50 50 54 45 53 54 4D 43 54 45 4C 00 => system_id => 'SMPPTESTMCTEL'(server identifier)



Appendix 2 – SMPP error codes listing

Status code Hex value Description ESME_ROK 0x00000000 No Error.

Specified in a response PDU to indicate the success of the corresponding request

ESME_RINVMSGLEN 0x00000001 Message Length is invalid. short_message field or message_payload TLV has an invalid length (usually too long for the given MC or underlying network technology).

ESME_RINVCMDLEN 0x00000002 Command Length is invalid. ESME_RINVCMDID 0x00000003 Invalid Command ID.

Command ID is not recognised, either because the operation is not supported or unknown.

ESME_RINVBNDSTS 0x00000004 Incorrect BIND Status for given command ESME_RALYBND 0x00000005 ESME Already in Bound State ESME_RINVPRTFLG 0x00000006 Invalid Priority Flag. ESME_RINVREGDLVFLG 0x00000007 Invalid Registered Delivery Flag. ESME_RSYSERR 0x00000008 System Error. ESME_RINVSRCADR 0x0000000A Invalid Source Address ESME_RINVDSTADR 0x0000000B Invalid Destination Address. ESME_RINVMSGID 0x0000000C Message ID is invalid. ESME_RBINDFAIL 0x0000000D Bind Failed. ESME_RINVPASWD 0x0000000E Invalid Password. ESME_RINVSYSID 0x0000000F Invalid System ID. ESME_RMSGQFUL 0x00000014 Message Queue Full. ESME_RINVSERTYP 0x00000015 Invalid Service Type. ESME_RINVSUBREP 0x00000042 Illegal submit w/replace request ESME_RINVESMCLASS 0x00000043 Invalid esm_class field data. ESME_RSUBMITFAIL 0x00000045 Generic failure error for submission operations ESME_RINVSRCTON 0x00000048 Invalid Source address TON. ESME_RINVSRCNPI 0x00000049 Invalid Source address NPI. ESME_RINVDSTTON 0x00000050 Invalid Destination address TON. ESME_RINVDSTNPI 0x00000051 Invalid Destination address NPI. ESME_RINVSYSTYP 0x00000053 Invalid system_type field. ESME_RINVREPFLAG 0x00000054 Invalid replace_if_present flag. ESME_RTHROTTLED 0x00000058 Throttling error (ESME has exceeded allowed

message limits in a given timeframe). ESME_RINVSCHED 0x00000061 Invalid Scheduled Delivery Time. ESME_RINVEXPIRY 0x00000062 Invalid message validity period ESME_RX_T_APPN 0x00000064 ESME Receiver Temporary App Error Code.

Rx or Trx ESME is unable to process a delivery due to a temporary problem and is requesting that the message be retried at some future point

ESME_RX_P_APPN 0x00000065 ESME Receiver Permanent App Error Code. Rx or Trx ESME is unable to process a delivery due to a permanent problem relating to the given destination address and is requesting that the message and all other messages queued to the same destination should NOT be retried any further

ESME_RX_R_APPN 0x00000066 ESME Receiver Reject Message Error Code. Rx or Trx ESME is unable to process delivery due



to a problem relating to the given message and is requesting that message is rejected and not retried. This does not affect other messages queued for the same ESME or destination address.

ESME_RQUERYFAIL 0x00000067 query_sm request failed. ESME_RINVTLVSTREAM 0x000000C0 Error decoding optional TLV ESME_RTLVNOTALLWD 0x000000C1 TLV not allowed. ESME_RINVTLVLEN 0x000000C2 Invalid Parameter Length. ESME_RMISSINGTLV 0x000000C3 Expected TLV missing. ESME_RINVTLVVAL 0x000000C4 Invalid TLV Value. ESME_RUNKNOWNERR 0x000000FF Unknown Error. ESME_RPROHIBITED 0x00000101 ESME Prohibited from using specified operation. ESME_RINVDCS 0x00000104 Invalid Data Coding Scheme. SMSNOCARRIER 0x00000400 No route to this destination SMSQUOTAEXCEEDED 0x00000402 Maximum credit exceeded SMSUSERIDLOCKED 0x00000410 User subaccount suspended SMSCOMPANYLOCKED 0x00000411 Company account suspended



Appendix 3 – GSM default alphabet

The 7 bits default GSM alphabet The GSM 7 bits default character table is specified below: there is a base table (where each characters is encoded on 1 byte) and an extension table where each character is encoded on 2 bytes (the escape code from base table and the extension table character, for example € symbol). The ISO 8859-1 without GSM equivalent will be translated on the nearest equivalent character or otherwise to a "?" character. b7 0 0 0 0 1 1 1 1

b6 0 0 1 1 0 0 1 1

b5 0 1 0 1 0 1 0 1

b4 b3 b2 b1 0 1 2 3 4 5 6 7

0 0 0 0 0 @ ∆ SP 0 ¡ P ¿ p

0 0 0 1 1 £ _ ! 1 A Q a q

0 0 1 0 2 $ Φ " 2 B R b r

0 0 1 1 3 ¥ Γ # 3 C S c s

0 1 0 0 4 è Λ ¤ 4 D T d t

0 1 0 1 5 é Ω % 5 E U e u

0 1 1 0 6 ù Π & 6 F V f v

0 1 1 1 7 ì Ψ ' 7 G W g w

1 0 0 0 8 ò Σ ( 8 H X h x

1 0 0 1 9 Ç Θ ) 9 I Y i y

1 0 1 0 10 LF Ξ * : J Z j z

1 0 1 1 11 Ø 1) + ; K Ä k ä

1 1 0 0 12 ø Æ , < L Ö l ö

1 1 0 1 13 CR æ - = M Ñ m ñ

1 1 1 0 14 Å ß . > N Ü n ü

1 1 1 1 15 å É / ? O § o à

NOTE 1): This code is an escape code to the extension table specified next page.



GSM 7 bit default alphabet extension table

b7 0 0 0 0 1 1 1 1

b6 0 0 1 1 0 0 1 1

b5 0 1 0 1 0 1 0 1

b4 b3 b2 b1 0 1 2 3 4 5 6 7

0 0 0 0 0 |

0 0 0 1 1

0 0 1 0 2

0 0 1 1 3

0 1 0 0 4 ^

0 1 0 1 5 €

0 1 1 0 6

0 1 1 1 7

1 0 0 0 8

1 0 0 1 9

1 0 1 0 10 3)

1 0 1 1 11 1)

1 1 0 0 12 [

1 1 0 1 13 ~

1 1 1 0 14 ]

1 1 1 1 15 \

In the event that a mobile receives a code where a symbol is not represented in the above table then the mobile shall display the character shown in the main GSM 7 bit default alphabet table in clause 6.2.1.

Converting ISO 8859-1 (International Reference Alphabet IRA) to GSM The HTTP/HTML Web interface allows to specify any text using the ISO 8859-1 (Iso Latin 1, International Reference Alphabet) if another encoding alphabet has not been specified. In this case, the VideoSMS gateway will perform the conversions described below if some characters not included in the GSM alphabet are present in the SMS text string.



Converting IRA (ISO 8859-1) to GSM

00 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0 00 - - 20 30 00 50 - 70 - - - - 411 - 7F - 01 - - 21 31 41 51 61 71 - - 40 - 412 5D 6120 7D 02 - - 22 32 42 52 62 72 - - - - 413 4F12 6121 08 03 - - 23 33 43 53 63 73 - - 01 - 414 4F13 6122 6F29

04 - - 02 34 44 54 64 74 - - 24 - 5B 4F14 7B 6F30

05 - - 25 35 45 55 65 75 - - 03 - 0E 4F15 0F 6F31

06 - - 26 36 46 56 66 76 - - - - 1C 5C 1D 7C 07 - - 27 37 47 57 67 77 - - 5F - 09 - 0923 - 08 - - 28 38 48 58 68 78 - - - - 455 0B 04 0C 09 - - 29 39 49 59 69 79 - - - - 1F 5516 05 06 0A LF - 2A 3A 4A 5A 6A 7A - - - - 456 5517 6524 7532

0B - - 2B 3B 4B - 6B - - - - - 457 5518 6525 7533

0C - - 2C 3C 4C - 6C - - - - - 498 5E 07 7E 0D CR - 2D 3D 4D - 6D - - - - - 499 5919 6926 7934

0E - - 2E 3E 4E - 6E - - - - - 4910 - 6927 - 0F - - 2F 3F 4F 11 6F - - - - 60 4911 1E 6928 7935

1 :À A 2 :Á A 3 :Â A 4 :Ã A 5 :È E

6 :Ê E 7 :Ë E 8 :Ì I 9 :Í I 10 :Î I

11 :Ï I 12 :Ò O 13 :Ó O 14 :Ô O 15 :Õ O

16 :Ù U 17 :Ú U 18 :Û U 19 :Ý Y 20 :á a

21 :â a 22 :ã a 23 :ç Ç 24 :ê e 25 :ë e

26 :í i 27 :î i 28 :ï i 29 :ó o 30 :ô o

31 :õ _ o 32 :ú u 33 :û u 34 :ý y 35 :ÿ y



Appendix 4 – MCTEL error codes The following MCTEL error codes may be returned by the SMPP interface, in the err: field of the text delivery notification (returned by deliver_sm) and in the optional network_error_code TLV.

Code Signification 00000 No error signalled 00001 Success 00002 Generic error code when a more specific error code is not available 00024 No route available to transmit this message to the specified country/operator 00036 User does not have enough unit balance on his account 00051 Invalid or unknown mobile number 00053 Call barred 00054 Mobile offline or outside coverage area 00055 Mobile network operator SMSC is down 00056 Target phone number is redlisted 00057 Target phone number is blacklisted (e.g. has send STOP request) 00058 Number ported by another operator 00065 Internal error 00068 Message has been deleted by an operator 00099 Other unspecified error 00100 The delivery failed, could not be accepted by mobile (e.g. SIM full) 00101 Mobile subscriber not equipped to receive SMS 00102 SMS has not been provisioned 00103 Error in subscriber mobile phone equipment 00104 Closed User Group reject 00105 The message has expired 00106 Reverse charging legitimation failure 00107 Invalid MSISDN number format for the specified country


Documents

Smpp Interface Manual-En