Home

SMPP v.5.0

Contents

1. Al 00111 Latin Hebrew ISO 8859 8 ELLIS Table 4 42 data_coding Values Notes a These coding schemes are common to GSM TDMA and CDMA The SMPP protocol allows ESME applications to use the same DCS value i e the GSM 03 38 value for all three technologies b In cases where a Data Coding Scheme is defined for TDMA and or CDMA but not defined for GSM SMPP uses GSM 03 38 reserved values c There is no default setting for the data_coding parameter d The data_coding parameter will evolve to specify Character code settings only Thus the recommended way to specify GSM MWI control is by specifying the relevant settings in the optional parameters ms_msg_wait_facilities and ms_validity e The data_coding parameter will evolve to specify Character code settings only Thus the recommended way to specify GSM message class control is by specifying the relevant setting in the optional parameter dest_addr_subunit SMPP V5 0 Draft06 SMS Forum 104 of 127 CA ZC www smsforum net MS FORUM 4 5 23 sm_default_msg_id The sm_default_msg_id parameter specifies the SMSC index of a pre defined canned message sm_default_msg_id Value Meaning reserved 1 254 Allowed values Table 4 43 sm_default_msg_id Values 4 5 24sm_length The sm_length parameter specifies the length of the short_message parameter in octets The sm_length should be set to 0 in the submit_sm submit_multi and deliver_sm PDUs if the me
2. Message Center Network Connection bind_transmitter seq 1 bind_transmitter_resp seq 1 submit_sm seq 2 submit_sm seq 3 submit_sm seq 4 submit_sm seq 5 submit_sm seq 6 gt lt t submit_sm_resp seq 2 submit_sm seq 7 query_sm seq 8 lt t sub mit_sm_resp seq 3 lt query_sm_resp seq 8 Su bm tt em resp seq 4 Su bm It em resp seq 7 lt t Y sub mit_sm_resp seq 5 lt sub mit_sm_resp seq 6 unbind seq 9 unbind_resp seq 9 Connection Closed Figure 2 13 Asynchronous Transmitter Session The asynchronous behaviour of both the ESME and Message Center is evident in the above session The ESME issues 5 submit_sm requests to the MC before receiving its first submit_sm_resp Note that the order in which the MC acknowledges these requests is by no means guaranteed to match the transmission order of the original requests A Message Centre because of it using a distributed architecture or because it is in fact SMPP Routing Entity and is distributing the ESME requests to other Message Centres is likely to acknowledge requests in the order they are completed Some requests may be distributed to busier parts of the system than others and as such may take longer to process The result is that the asynchronous sequence of acknowledgements returned to the ESME may not carry the same order as used bye the requests The same applies for
3. Services D cml H S gt Notification VA SMPP L1 Applications S 3 can ED y i DS SE VS GE A SMPP Se Services E S in A 4 SZ gt Telemetry A Applications SMPP Ba Av H wn E gt Velicle Tracking Set Ge d mimi Fa Other L eg USSD CBC Systems eg H e S CL2 Figure 1 1 SMPP Network Diagram SMPP V5 0 Draft06 SMS Forum 10 of 127 CA ZC www smsforum net MS FORUM 1 1 Scope Of This Document This document defines Version 5 0 of the SMPP protocol It is intended for designers and implementers of an SMPP v5 0 interface between Message Centres Routing Entities RE and External Short Message Entities ESME CL3 1 2 SMPP Overview The following sub sections overview the basic concepts and characteristics of SMPP Many of these characteristics will be discussed in greater detail throughout the document 1 2 1 Supported Cellular Technologies SMPP is designed to support short messaging functionality for any cellular technology and has specific applications and features for technologies such as e GSM e IS 95 CDMA e ANSI 136 TDMA e iDEN 1 2 2 Typical Applications of SMPP There is no end to the applications of SMPP and SMS in general Wireless Operators Message Centre vendors Infrastructure Providers and application developers are constantly developing new applications for SMS SMPP is ideal as an access protocol for these
4. Table 4 66 user_response_code TLV 4 6 4 19 language_indicator The language_indicator parameter is used to indicate the language of the short message CH Size octets Type Description Parameter Tag Woeger 0x020D at Length P nteger Length of value part in octets Value Integer 0 unspecified default 4 german 5 Portuguese refer to CMT 136 for other alues Table 4 67 language_indicator TLV 4 6 4 20 source_port The source_port parameter is used to indicate the application port number associated with the source address of the message Field Size octets Type Description Parameter Tag _ Integer 0x020A Length P nteger Lengthof value part in octets Value RB Integer All values allowed Table 4 68 source_port TLV SMPP V5 0 Draft06 SMS Forum 115 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 21 destination_port The destination_port parameter is used to indicate the application port number associated with the destination address of the message Field Size octets Type Description Parameter Tag _ Integer 0x020B Length P Jteger Lengh of value part in octets Value 2 Integer All values allowed Table 4 69 destination_port TLV 4 6 4 22 sar_msg_ref_num The sar_msg_ref_num parameter is used to indicate the reference number for a particular concatenated short message The concatenation related parameters are sar_msg_ref_num sar_total_segments and sar_segment_seqnum Where th
5. Session State Open Outbound Bound_TX Bound_RX Bound_TRX Unbound SMPP Entity ON PUREEEEEE ON PDU bind transmiter e bind transmiter resp bnd recever bnd recever resp bind transceiver bind transceiver resp oun F mwm y Si umbad resp J rsubmitsm IL submit sm re submit sm mi submit sm multi resp asm O os sme deliver sn IL deliver ane aen sm SSCs quey sme engl sm IL enee anze rreplace sm replace sm resp Penquire nk o enquire ink rep alert notification generic nak E HH Jl H HUTH HEITE PUREE EEL Jl UHT AEEA EA e e AEA Table 1 5 Operation Matrix SMPP V5 0 Draft06 SMS Forum 17 of 127 CNA ZC www smsforum net SMS FORUM 1 3 Glossary Definition HEADER Message Centre A generic term used to describe various types of SMS Gateways MSC NACK NSAP PSSR Routing Entityicts ooo O Message Bureau This is typically an operator message bureau Routing Entity cL8 SME SMPP USSN USSR VoiceMail Aer O VoiceMail Alert Voice Processing System TIA Telecommunications Industry Association WAP Wireless Application Protocol http www wapforum org WCMP Wireless Control Message Protocol WDP Wireless Datagram Protocol Table 1 6 Glossary ESME ETSI HEADER _ MSC NACK NSAP PSSD Deen SME__ SMSC SMPP__ UDHI USSN_
6. The 16 octet header would be decoded as follows 00 00 00 2F Command Length 0x0000002F 00 00 00 02 Command ID 0x00000002 bind_transmitter 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_transmitter 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 System_type secret08 53 55 42 4D 49 54 31 00 Password SUBMIT1 00 Interface_version 0x00 01 addr_ton 0x01 01 addr_npi 0x01 00 addr_range NULL SMPP V5 0 Draft06 SMS Forum 46 of 127 CA ZC www smsforum net MS FORUM 4 SMPP PDU Definitions This section defines the various Operation PDUs that make up the SMPP protocol The Operations are described in 4 categories Session Management Message Submission Message Delivery and Anciliary Operations 4 1 Session Management Operations 4 1 1 Bind Operation The purpose of the SMPP bind operation is to register an instance of an ESME with the SMSC system and request an SMPP session over this network connection for the submission or delivery of messages Thus the Bind operation may be viewed as a form of SMSC login request to authenticate the ESME entity wishing to establish a connection As described previously an ESME may bind to the SMSC as a Transmitter called ESME Transmitter a Receiver called ESME Receiver or a Trans
7. This message type is unique to Interactive Teleservice defined by the Korean CDMA Carriers Organization It is sent by a MS based SME to indicate the unexpected termination of an interactive session A Conversation Abort may be carried in a deliver_sm or data_sm PDU SMPP V5 0 Draft06 SMS Forum 82 of 127 CA ZC www smsforum net MS FORUM 4 4 Ancillary Operations 4 4 1 Cancel em Operation This command is issued by the ESME to cancel one or more previously submitted short messages that are still pending delivery The command may specify a particular message to cancel or all messages for a particular source destination and service_type are to be cancelled If the message_id is set to the ID of a previously submitted message then provided the source address supplied by the ESME matches that of the stored message that message will be cancelled If the message_id is NULL all outstanding undelivered messages with matching source and destination addresses given in the PDU are cancelled If provided service_type is included in this matching Where the original submit_sm data_sm or submit_multi source address is defaulted to NULL then the source address in the cancel_sm command should also be NULL SMPP V5 0 Draft06 SMS Forum 83 of 127 CNA ZC www smsforum net SMS FORUM 4 4 1 1 Cancel em Syntax Field Name Size Type Description Ref octets ommand_length A integer Set to overall length of PDU V equence_number I
8. 3 SMPP Parameter and PDU Format 3 4 Parameter Type Definitions 0 ec ceeeteeeeeeneeeeeeneeeeeeenaeeeeeenaes 3 1 1 NULL SettingS AA 3 1 2 SMPP Parameter Field Size Notation ceeeeeeeeee 3 2 General PDU Format 3 2 1 PDU Format ccc nice cctv siete SERA EEEEERdEEEAEEE EEN deg 3 2 1 1 Command _length cccecccceeeeeeneeeeeeeeseaeetsaeeeeneeeeaes 3 2 1 2 COMMaN TA EE 3 2 1 3 COMMANC_ status ccccccccccceesseaeceeeeeeeesseeeeeeeeeeeeesees 3 2 1 4 Deouence number 3 2 1 5 Standard Parameters ccccecceesceceeeeseeeeesseeeeeeeeeees E tunes 29 Senger 31 3 of 127 CO CO www smsforum net SMS FORUM 3 2 1 6 TLV Parameters ericsson aaa i EEAS AE EA 45 oaa A sample POU steet reegt ebebegg eege et ege Ee degt ege 46 d SMPP PDU Definitions vaiicccicdeivsetcesevescccenesiecodete dee d geed Eege AERCH 47 4 1 Session Management Operations ccccceceeececeeeeeceeeeeeaeeeeeeeseeeeeseaeeeeaeeneeeeee 47 4 1 1 Bind Operations EE 47 4 1 1 1 bind_transmitter Syntax cceccccccceeeceeeeeeeeceeeeecceeeeaaeeeeeeeseeeeeaeeteneeseeeees 48 4 1 1 2 bind_transmitter_resp Syntax ccccceecceeceeeeeeceeeeeeaeeeeeeeseeeeeaeeseeeseeeee 49 4 1 1 3 bind_receiver Syntax occ ceeecceececeeee cee eeeeeeeeeeee eae eeeaaeseeeeeseaeeseaaeeseeeseeeee 50 4 1 1 4 bind_receiver_resp Syntax ecccccccccceeeeneeceeeeeceeeeeeeaeeeeeeeseteeeeaeeeeeeeeeeee 51 4 1 1 5 bind_transceiver Gvntax rese nesrnss
9. Integer 0x0427 Length _ Integer Length of value part in octets Table 4 83 message_state TLV SMPP V5 0 Draft06 SMS Forum 121 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 36 callback_num The callback_num parameter associates a call back number with the message In TDMA networks it is possible to send and receive multiple callback numbers to from TDMA mobile stations Field Size octets Type Description Parameter Tag 0x0381 Length BR _ integer____ Length of Value part in octets Var Octet String 4 19 0000000D OOOOOTTT OOOONNNN XXXXXXXX XXXXXXXX octet N The originating SME can set a Call Back Number for the receiving Mobile Station The first octet contains the Digit Mode Indicator Bit D 0 indicates that the Call Back Number is sent to the mobile as DTMF digits encoded in TBCD Bit D 1 indicates that the Call Back Number is sent to the mobile encoded as ASCII digits The 2nd octet contains the Type of Number TON Encoded as in section 5 2 5 The third octet contains the Numbering Plan Indicator NPI Encoded as specified in section The remaining octets contain the Call Back Number digits encoded as ASCII characters Table 4 84 callback_num TLV SMPP V5 0 Draft06 SMS Forum 122 of 127 CA ZC www smsforum net MS FORUM 4 6 4 37 callback_num_pres_ind Field Size octets Type Description Length 0x0302 Integer Length of Value part in octets 1 Bit mask 0000ppss This para
10. Table 4 45 dest_flag Values Table 4 46 message_state Values Table 4 47 TLV Tag Value Ranges Table 4 48 TLV Tag Definitions Table 4 49 dest_addr_subunit TLV Table 4 50 source_addr_subunit TLV Table 4 51 dest_network_type TLV Table 4 52 source_network_type TLV Table 4 53 dest_bearer_type TLV Table 4 54 source_bearer_type TLV Table 4 55 dest_telematics_id TLV Table 4 56 source_telematics_id TLV Table 4 57 gos_time_to_live TLV Table 4 58 payload_type TLV Table 4 59 additional_status_info_text TLV Table 4 60 receipted_message_id TLV Table 4 61 ms_msg_wait_facilities TLV Table 4 62 privacy_indicator TLV Table 4 63 source_subaddress TLV Table 4 64 dest_subaddress TLV Table 4 65 user_message_reference TLV Table 4 66 user_response_code TLV Table 4 67 language_indicator TLV Table 4 68 source_port TLV Table 4 69 destination_port TLV Table 4 70 sar_msg_ref_num TLV Table 4 71 sar_total_ segments TLV Table 4 72 sar_segment_seqnum TLV Table 4 73 sc_interface_version TLV Table 4 74 display_time TLV Table 4 75 ms_validity TLV Table 4 76 dpf_result TLV Table 4 77 set_dpf TLV Table 4 78 ms_availability_status TLV Table 4 79 network_error_code TLV Table 4 80 message_payload TLV Table 4 81 delivery_failure_reason TLV Table 4 82 more_messages_to_send TLV Table 4 83 message_state TLV Table 4 84 callback_num TLV Table 4 85 callback_num_pres_ind TLV Table 4 86 callback_num_atag TLV Table 4 87 number_of_messages TLV Table 4 88 sms_signal TLV
11. This operation is used by the SMSC to signal an ESME to originate a outbind request to the SMSC The format of the SMPP outbind PDU is defined in the following table Field Name Size Type Description Ref Octets command_length 4 Integer Defines the overall length of the PDU V 4 4 4 ar 16 ar system_id C Octet SMSC identifier 4 5 5 max String Identifies the SMSC to the ESME Password V C Octet The password may be used by the 4 5 max 9 String ESME for security reasons to authenticate the SMSC originating the loutbind Table 4 7outbind PDU SMPP V5 0 Draft06 SMS Forum 54 of 127 CA ZC www smsforum net MS FORUM 4 1 1 8 unbind Syntax The purpose of the SMPP unbind operation is to deregister an instance of an ESME from the SMSC and inform the SMSC that the ESME no longer wishes to use this network connection for the submission or delivery of messages Thus the unbind operation may be viewed as a form of SMSC logoff request to close the current SMPP session The format of the SMPP unbind PDU is defined in the following table Field Name Size Type Description Ref Integer Defines the overall length of the PDU octets command_length sequence_number 4 Integer Set to a unique sequence number 4 5 4 an he associated unbind_resp PDU will a echo the same sequence number Table 4 8 unbind PDU 4 1 1 9 unbind resp Syntax The SMPP unbind_resp PDU is used to reply to an unbind request It com
12. addr_ton Integer Type of Number TON for ESME address es served via this SMPP transceiver session Set to NULL Unknown if not known addr_npi Integer Numbering Plan Indicator NPI for 4 ESME address es served via this SMPP transceiver session Set to NULL Unknown if not known address_range V C Octet A single ESME address or a range of 4 5 11 max 41 String ESME addresses served via this SMPP transceiver session This field may be used by the SMSC for authentication verification or routing purposes Set to NULL if not known Table 4 5 bind_transceiver PDU 5 6 7 8 9 9 SMPP V5 0 Draft06 SMS Forum 52 of 127 CA ZC www smsforum net MS FORUM 4 1 1 6 bind_transceiver_resp Syntax The format of the SMPP bind_transceiver_resp PDU is defined in the following table Field Name Size Type Description Ref octets command_length 4 Integer Defines the overall length of the PDU command_status 4 Integer Indicates status Success or error code of original bind_transceiver request sequence_number 4 Integer Gei to sequence number of original 4 5 4 bind_transceiver request system_id Var C SMSC identifier 4 5 5 max 16 Octet identifies the SMSC to the ESME String Optional TLVs sc_interface_version TN SMPP version supported by SMSC 4 6 4 25 Table 4 6 bind_transceiver_resp PDU SMPP V5 0 Draft06 SMS Forum 53 of 127 CNA ZC www smsforum net SMS FORUM 4 1 1 7 outbind Syntax
13. user_response_code A user response code The actual response codes are i implementation specific display_time Provides the receiving MS with a display time associated 4 6 4 26 ith the message sms_signal Indicates the alerting mechanism when the message is received by an MS ms_validity Indicates validity information for this message to the recipient MS ms_msg_wait_facilities his parameter controls the indication and specifies the message type of the message associated with the MWI at the mobile station number_of_messages _ Indicates the number of messages stored in a mail box alert_on_msg_ delivery Request an MS alert signal be invoked on message delivery language _indicator Indicates the language of an alphanumeric text message d its_reply_type he MS user s reply method to an SMS delivery message received from the network is indicated and controlled by his parameter jts_session_info Session control information for InteractiveTeleservice ussd_service_op his parameter is used to identify the required USSD Service type when interfacing to a USSD system Table 4 19 Message Submission Request TLVs SMPP V5 0 Draft06 SMS Forum 68 of 127 CA ZC www smsforum net MS FORUM 4 2 5 Message Submission Response TLVs The following table contains TLVs that can be returned in a submit_sm_resp or data_sm_resp PDU All TLVs are relevant to transaction message mode only ref 4 2 10 4 TLV Name Description delivery_failure_rea
14. Table 4 89 alert_on_message_delivery TLV Table 4 90 its_reply_type TLV Table 4 91 its_session_info TLV Table 4 92 ussd_service_op TLV Table 4 93 congestion_state TLV Table 5 1 Change Log SMPP V5 0 Draft06 SMS Forum 8 of 127 CA ZC www smsforum net MS FORUM List Of Figures Figure 1 1 SMPP Network Diagram ccc ccceccceeceeeeeeeeeeeeeeceaeeeeaeeesaaeseeeeeeeaeeesaeeeeaaeseeeeesaas 10 Figure 2 1 Application Layer Communication Between ESME and M A 20 Figure 2 2 Open State isise cccssaevvencevsseccadybgvacexssueecuaesaccevnigelcasvayCaagespiyeea esha eaach paueedevaasendeep 21 Figure 2 3 Bound TX State sieniin aaien aiii a edain 21 Figure 2 4 Bound RX State sisii aiaa iae aaa aiaia an 22 Figure 2 5 Bound TRX State rsin einernie aetan kaaa Aa RAAEN aa 22 Figu re 2 6 Qutbou nd KE 23 Figure 2 7 Bound_RX State from Outbound State 0 ccceeeeeeceeeeeeeeeeeeeeseeeeeeeaeeeeeeeeeeeeeeas 23 Figure 2 8 Example Transmitter Session cc ccceeeceeeeeeeeeeceeeeeceaeeesaaeeeeeeeseeeesaeeneneeeeaes 24 Figure 2 9 Example Receiver Gesslon nren 25 Figure 2 10 Example Transceiver Session ccc ccceeeeeeeeeeeeeeeeeeeeeeaaeeeeaeeseeeeseaeeesaeeeneeeseas 26 Figure 2 11 Example Outind Session cccccccceeeeceeeeeeeeeeeeeeeeeeceaeeeeaaeseeaeeseeeeseaeeeeaeseeneesaas 27 Figure 2 12 Transceiver Session demonstrating PDU Geouencing 28 Figure 2 13 Asynchronous Transmitter Session sseesseesseesseeesrres
15. then that ESME will be issuing its 100 PDU within the session 2 5 3 Sequence Numbers Across Sessions Sequence numbers are designed for use within a single session The recommended approach is to begin each session with a sequence number of 1 and increase monotonically from that point The numbers used will not affect any other sessions that may already exist between the ESME and MC Nor can PDUs from one session be acknowledged through another If the ESME MC connection is closed or lost then the expected recovery would be that the ESME or MC may re establish the session All unacknowledged PDUs from the lost session will not be acknowledged in the new recovery session i e if the session was lost at a point where the MC had yet to send a submit_sm_resp to the ESME then a new session established between the ESME and MC will not result in this response PDU being returned Instead the ESME is expected to begin numbering PDUs from 1 The same expectation applies for the Message Center SMPP V5 0 Draft06 SMS Forum 29 of 127 CO CO www smsforum net SMS FORUM 2 5 4 Synchronous Vs Asynchronous SMPP is an asynchronous protocol This means that an ESME or MC can send several requests at a time to the other party The PDU sequence number plays a crucial role in supporting the asynchronous nature of SMPP All example sessions shown in the previous sections have been synchronous Here is an example of an asynchronous session
16. validity_period The validity period of this message Set to NULL if not available Integer Indicator to signify if an SMSC delivery receipt or an SME acknowledgement is required Integer Flag indicating if delivered message should replace an existing message Integer Defines the encoding scheme of the short message user data registered_delivery replace_if_present_flag data_coding sm_default_msg_id 4 i i i N O sm_length Integer Length in octets of the 4 5 24 short_message user data short_message Octet Up to 255 octets of short 4 5 25 String message user data The exact physical limit for short_message size may vary according to the underlying network Applications which need to Send messages longer than 255 octets should use the message_payload parameter In this case the sm_length field should be set to zero Table 4 21 deliver_sm PDU Integer Indicates the short message to send from a list of pre defined canned short messages stored on the SMSC Set to NULL If not known SMPP V5 0 Draft06 SMS Forum 78 of 127 CA ZC www smsforum net MS FORUM 4 3 1 2 deliver_sm_resp Syntax Field Name Size Type Description Ref octets command_length 4 Integer Set to overall length of PDU command_status Integer Indicates outcome of 4 5 3 deliver_sm request 4 sequence_number 4 Integer Get to sequence number of 4 original deliver_sm PDU message_id Var C
17. 0x1380 CDMA Table 4 48 TLV Tag Definitions SMPP V5 0 Draft06 SMS Forum 108 of 127 CA ZC www smsforum net MS FORUM 4 6 2 TLV Length This is a 2 octet field used to specify the length of the Value field within a TLV 4 6 3 TLV Value This is a variable size field used to contain the TLV payload for each specific TLV 4 6 4 TLV Definitions 4 6 4 1 dest_addr_subunit The dest_addr_subunit parameter is used to route messages when received by a mobile station for example to a smart card in the mobile station or to an external device connected to the mobile station ack Size octets Type Description Parameter Tag integer 0x0005 aa Length ___B__Iinteger Length of Value part in octets Value Integer 0x00 Unknown default 0x01 MS Display 0x02 Mobile Equipment 0x03 Smart Card 1 expected to be SIM if a SIM exists in the MS 0x04 External Unit 1 5 to 255 reserved Table 4 49 dest_addr_subunit TLV 4 6 4 2 source_addr_subunit The source_addr_subunit parameter is used to indicate where a message originated in the mobile station for example a smart card in the mobile station or an external device connected to the mobile station Field Size octets Type Description Parameter Tagl2 Integer 0x000D Length P Jteger Length of Value part in octets ee 4 6 4 1 Table 4 50 source_addr_subunit TLV SMPP V5 0 Draft06 SMS Forum 109 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 3 dest_network_t
18. 4 sequence_number A sequence number allows a response PDU to be correlated with a request PDU The associated SMPP response PDU must preserve this field The allowed sequence_number range is from 0x00000001 to Ox7FFFFFFF In the event of a session using the full range of values for the sequence_number the ESME or MC should wrap around to 0x00000001 The value 0x00000000 is recommended for use when issuing a generic_nack where the original PDU was deemed completely invalid and its PDU header was not used to derive a sequence_number for the response PDU Detailed information on how PDU sequencing works is available in section 2 5 4 5 5 system_id The system_id parameter is used to identify an ESME or an SMSC at bind time An ESME system_id identifies the ESME or ESME agent to the SMSC The SMSC system_id provides an identification of the SMSC to the ESME 4 5 6 password The password parameter is used by the SMSC to authenticate the identity of the binding ESME The Service Provider may require ESME s to provide a password when binding to the SMSC This password is normally issued by the SMSC system administrator The password parameter may also be used by the ESME to authenticate the identity of the binding SMSC e g in the case of the outbind operation 4 5 7 system_type The system_type parameter is used to categorize the type of ESME that is binding to the SMSC Examples include VMS voice mail system and OTA over the
19. 82 4 3 4 4 SME Manual User Acknowledgement ssseesseesseesse essensen essensen nsen reen nees 82 4 3 4 5 Conversation Abort c cccecccceeceeseeeceeeeeeeeeeecaeeeeaaesteneeseeeeeeaaesteaeeeeeeees 82 4 4 Ancillary Operations ccccceceeeceeececeeeeeceaeeeeaaeseeeeecaeeeseaesseneeseeeeeseaeeesaeseaaeseenees 83 4 4 1 cancel em Operation 83 SMPP V5 0 Draft06 SMS Forum 4 of 127 www smsforu m net SMS FORUM BIER 4 4 1 1 CANCE sm SYMAX EE 84 4 4 1 2 Cancel em resp Syntax eecceceeeeeee cece eects ceaeeeeeaeeeeeeeseeeesaeeseaeeeeeeeees 85 4 4 1 3 QUETY_SM Operation 86 4 4 1 4 query SIN SYM EE 87 4 4 1 5 query sm resp SYMAx seiniin iienaa iaa ianiai 88 4 4 2 replace sm Operation 89 4 4 2 1 replace Ssmi NEE egerdetegeght vi eudee ekh ainainen aiia aaaea 89 4 4 2 2 replace_sm_resp Syntax eeccecceceeeeeceeeeceeeeeceaeeeeeaeeeeneeseaeeessaeseeneeesenees 90 4 5 PDU Field Detpteng ccc eccaess vessetsdeccnuets de dancas eesaetaaFesdice decanted yedanden Cettetaarendaadess 91 4 5 1 command We E 91 4 5 2 COMIMAMNG Ne WEE 91 4 5 3 command STATUS ctesics cccceetccczencs Sonecdihcwcecvien snes caeheved eves dcaccauhdeuscvas tans Vavseand eves bees os 92 4 5 4 e Ee 95 ADD Sytem Id TEE 95 4 5 6 PASS WONG D 95 Enn Be 95 4 5 8 interface VEISION os dese gedeien lee SE 95 4 5 9 addr_ton source_addr_ton dest_addr_ton esme adr Ton 96 4 5 10 addr_npi source_addr_npi dest_addr_npi esme adr mp 96 ALD Al Addres
20. Bits Meaning Rt Ol No SMSC Delivery Receipt requested default SMSC Delivery Receipt requested where final x xX XxX xX x x 0 1 R delivery outcome is delivery success or failure SMSC Delivery Receipt requested where the final XXxXxxxx10 R i delivery outcome is delivery failure SMSC Delivery Receipt requested where the final x X xX xX x x lil e delivery outcome is success CL22 No recipient SME acknowledgment requested x x x x 0 0 x x default SME Delivery Acknowledgement requested Sees SME Manual User Acknowledgment requested x x x x 1 0 x x Both Delivery and Manual User Acknowledgment x x x x 1ixx requested No Intermediate notification requested default x xX xX O x x xX x Intermediate notification requested Scot ee ede Bee Support for Intermediate Notification Functionality is specific to the MC implementation and is beyond the scope of the SMPP Protocol Specification Table 4 40 registered_delivery Values SMSC Delivery Receipt bits 1 and 0 E NO FE Sog DD S es os H Ke x gt nO lt Intermediate Notification bit 5 SMPP V5 0 Draft06 SMS Forum 102 of 127 CA ZC www smsforum net MS FORUM 4 5 21 replace_if_present_flag The replace_if_present_flag parameter is used to request the SMSC to replace a previously submitted message that is still pending delivery The SMSC will replace an existing message provided that the source address destination address and servic
21. Broadcast cellcast 9 to 255 reserved Table 4 53 dest_bearer_type TLV SMPP V5 0 Draft06 SMS Forum 110 of 127 CA ZC www smsforum net MS FORUM 4 6 4 6 source_bearer_type The source_bearer_type parameter indicates the wireless bearer over which the message originated Field Size octets Type Description Parameter Tagl2 Integer 0x000F Length P Jteger Length of Value part in octets ee 4 6 4 5 Table 4 54 source_bearer_type TLV 4 6 4 7 dest_telematics_id This parameter defines the telematic interworking to be used by the delivering system for the destination address This is only useful when a specific dest_bearer_type parameter has also been specified as the value is bearer dependent In the case that the receiving system e g SMSC does not support the indicated telematic interworking it may treat this a failure and return a response PDU reporting a failure Field Size octets Type Description 2 Integer ox0008 Length 2 _ Integer Length of Value part in octets o be defined Table 4 55 dest_telematics_id TLV 4 6 4 8 source_telematics_id The source_telematics_id parameter indicates the type of telematics interface over which the message originated Field Size octets Type Description Parameter Tab __ Integer 0x0010 Length 2 Integoer Length of Value part in octets ee 4 6 4 7 Table 4 56 source_telematics_id TLV 4 6 4 9 qos me to live This parameter defines the number of seconds whi
22. Code CRs BTC ussd_service_op CR for addition of specified TLV to deliver_sm and data_sm operations FC amp CA CR Network Error Code Enhancement CR Table 5 1 Change Log SMS Forum 127 of 127
23. Length of value part in octets Integer 0 Temporary 1 Default default 2 Invoke values 3 to 255 are reserved Table 4 74 display_time TLV SMPP V5 0 Draft06 SMS Forum 117 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 27 ms_validity The ms_validity parameter is used to provide an MS with validity information associated with the received short message Field Size octets Type Description Parameter Tag 0x1204 Length P Irtegoer Length of value part in octets Integer 0 Store Indefinitely default 1 Power Down 2 SID based registration area 3 Display Only values 4 to 255 are reserved Table 4 75 ms_validity TLV 4 6 4 28 dpf_result The dpf_result parameter is used in the data_sm_resp PDU to indicate if delivery pending flag DPF was set for a delivery failure of the short message If the dot result parameter is not included in the data em resp PDU the ESME should assume that DPF is not set Currently this parameter is only applicable for the Transaction message mode Field Size octets Type Description Parameter Tag __ Integer 0x0420 Length P Integer Length of value part in octets Value 1 Integer 0 DPF not set 1 DPF set values 2 to 255 are reserved Table 4 76 dpf_result TLV SMPP V5 0 Draft06 SMS Forum 118 of 127 CA ZC www smsforum net MS FORUM 4 6 4 29 set_dpf An ESME may use the set_dpf parameter to request the setting of a delivery pending fl
24. Numbering Plan Indicator for 4 5 10 Source address If not Known set to NULL Unknown source_addr V C Octet Address of SME which 4 5 12 max 21 String originated this message If not known set to NULL Unknown SMPP V5 0 Draft06 SMS Forum 63 of 127 CO CO www smsforum net SMS FORUM number of _dests 1 Integer Number of destination addresses indicates the number of destinations that are 0 follow A maximum of 255 destination addresses are allowed Note Set to 1 when submitting o one SME Address or when ubmitting to one Distribution List dest_address i SME Format Destination Address Composite field dest_flag Integer 0x01 SME Address dest_addr_ton Integer Type of Number for destination dest_addr_npi Integer Numbering Plan Indicator for destination destination_addr C Octet Destination address of this String hort message For mobile erminated messages this is he directory number of the recipient MS dest_address Distribution List Format Destination Address Composite Field dest_flag Integer 0x02 Distribution List d name f C Octet Name of Distribution List String dest_address Additional destination address delimited by the number_of_dests field esm_class Integer Indicates Message Mode and 4 5 16 Message Type Integer Protocol Identifier 4 5 17 Network specific field Integer Designates the priority level of 4 5 18 he message or17 C Octet The short message is to be 4 5 19 1 S
25. SMSC time at which delivery of this message will be attempted by the SMSC It can be specified in either absolute time format or relative time format 4 5 19 2 validity_period The validity_period parameter indicates the SMSC expiration time after which the message should be discarded if not delivered to the destination It can be defined in absolute time format or relative time format 4 5 19 3 Absolute Time Format This is the default format used by SMPP Scheduled delivery times and expiry times are specified in their global UTC format including the quarter hour offset and direction symbol or Absolute time is formatted as a 16 character string encoded as a 17 octet C octet String YYMMDDhhmmsstnnp where Meaning last two digits of the year 00 99 month 01 12 day 01 31 hour 00 23 minute 00 59 second 00 59 tenths of second 0 9 an Time difference in quarter hours between local time as expressed in the first 13 octets and UTC Universal Time Constant time 00 48 Local time is in quarter hours advanced in relation to UTC time Local time is in quarter hours retarded in relation to UTC time Table 4 38 Absolute UTC Time Format SMPP V5 0 Draft06 SMS Forum 100 of 127 CA ZC www smsforum net MS FORUM 4 5 19 4 Relative Time Format Relative Time can be indicated by setting the UTC orientation flag to R instead of or In this for
26. Var C Octet Message ID of the 4 5 26 Max 65 String message to be replaced This must be the SMSC assigned Message ID allocated to the original short message when Submitted to the SMSC by the submit_sm data_sm or Submit_multi command and returned in the response PDU by the SMSC 1 A source_addr_ton Integer Type of Number for source 4 5 9 address used in original message If not known set to NULL Unknown source_addr_npi Integer Numbering Plan Indicator 4 5 10 for source address of original message If not known set to NULL Unknown source_addr C Octet Address of SME which 4 5 12 String _joriginated this message If not known set to NULL Unknown schedule_delivery_time C Octet The short message is tobe 4 5 19 1 String scheduled by the SMSC for delivery Set to NULL for immediate message delivery SMPP V5 0 Draft06 SMS Forum 89 of 127 CNA ZC www smsforum net SMS FORUM Field Name Size Type Description octets validity period 1 or 17 C Octet The validity period of this String message Set to NULL to request the SMSC default validity period registered_delivery 1 Integer Indicator to signify if an SMSC delivery receipt or an SME acknowledgement is required 1 sm_default_msg_id Integer Indicates the short message to send from a list of pre defined canned short messages stored on the SMSC If not using an SMSC canned message set to NULL sm_length Integer Length in
27. Version 23 040 Message Service SMS 4 4 0 CL9 Release 4 BGPP TS Alphabets and language specific 3GPP Version 23 038 information Release 4 4 3 0 CL10 BGPP TS Mobile Application Part MAP 3GPP Version 23 038 Specification Release 4 4 5 0 CL11 Table 1 7 References SMPP V5 0 Draft06 SMS Forum 19 of 127 CO CO www smsforum net SMS FORUM 2 SMPP Sessions As described earlier earlier the ESME and MC communication is based on an SMPP session This section describes this in detail 2 1 Application Layer Communication The Open Systems Interconnect model or OSI stack as it is more commonly known defines a layered approach to data communications working form the most basic electronic data communications physical up to link level communication involving the transmission of octets and onwards to fully formed network packets network and ultimately to transport layers that manage packets and the reliable transport of data ensuring the appropriate resending of packets that are not properly received at the remote end SMPP is an application layer protocol using the same underlying communications as protocols such as well known services like telnet ftp http etc An application layer connection is typically presented as a buffer through which an application can send and receive data The transport of this data between one peer and another is completely hidden from the ESME or MC In fact nowhere in SMPP is there any
28. address shall be encoded using the preferred binary encoding specified in ITUT X 213 In this case the subaddress field contains the Authority and Format Identifier A User Specified subaddress is encoded according to user specification subject to a maximum of 22 octets Table 4 63 source_subaddress TLV 4 6 4 16 dest_subaddress The dest_subaddress parameter specifies a subaddress associated with the destination of the message Field Size octets Type Description Parameter Tag 0x0203 Length BR _Jinteger____ Length of Value part in octets ee eee pee String Bee 4 6 4 15 for parameter encoding 2 23 Table 4 64 dest_subaddress TLV The dest_subaddress parameter is not supported in the SMPP submit_multi PDU SMPP V5 0 Draft06 SMS Forum 114 of 127 CA ZC www smsforum net MS FORUM 4 6 4 17 user_message_reference A reference assigned by the originating SME to the short message Field Size octets Type Description Parameter Tag __si Integer 0x0204 Length P Jteger Length of value part in octets Value RB Integer All values allowed Table 4 65 user_message_reference TLV 4 6 4 18 user_response_code A response code set by the user in a User Acknowledgement Reply message The response codes are application specific CH Size octets Type Description ParameterTag2 integer 0x0205 Ge Length P nteger Length of value part in octets Value Integer 0 to 255 IS 95 CDMA O to 15 GMT 136 TDMA
29. an entity using an older version of the protocol The following guidelines must be followed in SMPP implementations to ensure that this process is implemented successfully and consistently e Existing SMPP PDUs must not be removed from the protocol e The effect of receiving any existing message in a new modified format must be same as that in previous versions Thus the addition of new parameters or parameter values is purely additive e Optional parameters shall not become mandatory parameters e Mandatory parameters shall not become optional parameters e Additional mandatory parameters shall not be added to an existing SMPP PDU e Existing mandatory parameters shall not be removed from an existing SMPP PDU e The meaning of any existing parameter value shall not be changed in the new version of the protocol As the concept of Optional Parameters was first introduced V3 4 of the protocol the following special guidelines were defined e An SMSC that implements SMPP V3 4 or a later version of this protocol must not send optional parameters to an ESME that implements an earlier SMPP version e g V3 3 An SMSC shall determine the SMPP version supported by an ESME during the bind operation An ESME supporting SMPP V3 3 or earlier will set the interface_version parameter in the bind operation to a value less than 0x34 or equal to 0x00 e An SMSC supporting V3 4 or later should return the SMPP version it supports in the sc_interface_ver
30. bind_receiver or bind_transceiver request to the SMSC An example of where such a facility might be applicable would be where the SMSC had outstanding messages for delivery to the ESME ESME Message Center Network Connection outbind Initiated by Message Center Figure 2 6 Outbound State The following diagram illustrates the concept of Outbind when used to request a receiver or transceiver ESME to bind Message Center Network Connection outbind bind_receiver bind_receiver_resp Figure 2 7 Bound_RX State from Outbound State SMPP V5 0 Draft06 SMS Forum 23 of 127 www smsforum net 2 4 Sample Sessions CONICO 4 MS FORUM To help explain the context of SMPP operations and their related states the following examples illustrate typical dialogues for the three types of ESME 2 4 1 Example Transmitter Session Message Center Network Connection bind_transmitter lt bind_transmitter_resp Bound_TX submit sm lt submit sm_resp submit_sm a submit_sm_resp cancel_sm cancel_sm_resp Connection Closed SMPP V5 0 Draft06 Figure 2 8 Example Transmitter Session SMS Forum 24 of 127 www smsforum net 2 4 2 Example Receiver Session CN ZO a MS FORUM Network Connection bind_receiver lt a bind_receiver_resp Bound_RX A deliver sm deliver_sm_resp 3 deliver_sm deliver_sm_resp unbind
31. client A single SME address may also be specified in the address_range parameter UNIX Regular Expression notation should be used to specify a range of addresses Refer to Appendix A Messages addressed to any destination in this range shall be routed to the ESME Notes For IP addresses it is only possible to specify a single IP address A range of IP addresses is not allowed IP version 6 0 is not currently supported in this version of the protocol SMPP V5 0 Draft06 SMS Forum 96 of 127 CA ZC www smsforum net MS FORUM 4 5 12 source_addr Specifies the address of SME which originated this message An ESME which is implemented as a single SME address may set this field to NULL to allow the SMSC to default the source address of the submitted message Notes An IP address is specified in aaa bbb ccc ddd notation IP version 6 0 is not supported in V3 4 of the SMPP protocol 4 5 13 destination_addr Specifies the destination SME address For mobile terminated messages this is the directory number of the recipient MS Notes An IP address is specified in aaa bbb ccc ddd notation IP version 6 0 is not supported in V3 4 of the SMPP protocol 4 5 14esme_addr Specifies the address of an ESME address to which an alert_notification should be routed Notes An IP address is specified in aaa bbb ccc ddd notation IP version 6 0 is not supported in V3 4 of the SMPP protocol 4 5 15 service_type The se
32. fault for sending a non standard PDU Typical responses will depend on how the malformed PDU is detected If the command_id the reason for rejection the receiving peer should respond with a generic_nack and command status set to ESME_RINVCMDID If the command_length of the PDU appeared too large suggesting that it was invalid the ESME or MC should respond with a generic_nack and command status set to ESME_RINVCMDLEN Invalid Field Length If any PDU field is to long or too short then the PDU is essentially malformed but an ESME or MC may indeed recognise the PDU and as such will respond with a submit_sm_resp or whatever is the appropriate PDU to use and set the command status to the appropriate error For example if an ESME submits a message with a 20 character scheduled delivery time the rejection should be a command_status set to ESME_RINVSCHED The PDU data is unexpected and deemed invalid this type of rejection tends to be very application specific and an absolute list of causes is well beyond the scope of this document These types of rejections are not protocol non compliance issues rather application errors An example of such a scenario could be an Email gateway that provides a service to convert Mobile originated SMS messages into emails The email addressing might be based on the text content of the message If the ESME found that the message forwarded by the MC did not contain the correct formatting it would reject the message Th
33. for source 4 5 9 address If not known set to NULL Unknown source_addr_npi Integer Numbering Plan Indicator for 4 5 10 ource address If not known set to NULL Unknown 5 9 dest_addr_ton Integer ype of Number for 4 destination dest_addr_npi Integer Numbering Plan Indicator for 4 5 10 destination destination adr C Octet Destination address of this 4 5 13 max String hort message For mobile erminated messages this is he directory number of the recipient MS SMPP V5 0 Draft06 SMS Forum 61 of 127 4 4 4 4 Var 1 1 source_addr Var C Octet Address of SME which 4 5 12 max String _joriginated this message 21 If not known set to NULL Unknown 1 1 Var 21 CNA ZC www smsforum net SMS FORUM Field Name Size Type Description octets esm_class Integer Indicates Message Mode and 4 5 16 Message Type registered_delivery Integer Indicator to signify H an SMSC 4 5 20 delivery receipt or an SME acknowledgement is required data_coding Integer Defines the encoding scheme of the short message user Message Submission TLVs Table 4 15 data em PDU 4 2 2 2 data sm resp Syntax Field Name Size Type Description Ref octets command_length E to overall length of PDU command id id 4 integer 0x80000103 03 4 45 2 2 Ee status Ge Ee outcome of E 5 3 submit_sm request sequence_number Integer Get to Sequence number of original submit_sm PDU message_id Var C Octet This field c
34. in turn will respond with a deliver_sm_resp PDU as a means of acknowledging the delivery Some operations are specific to an ESME with others specific to the MC Others may be specific to a given session type Referring to the submit_sm and deliver_sm examples above an ESME may send a submit_sm to a MC only if it has established a TX or TRX session with that Message Centre Likewise a MC may send a deliver_sm PDUs only to ESMEs that have established RX or TRX sessions A RE has been established to allow operations to be passed between MCs The RE has the ability to translate a deliver_sm from a source MC to a submit_sm destined for a destination MC CL6 Operations are broadly categorised into the following groups e Session Management Operations designed to enable the establishment of SMPP sessions between an ESME and MC and provide means of handling unexpected errors e Message Submission Operations geared specifically towards the submission of messages from ESMEs to the MC e Message Delivery Operations will enable the MC to deliver messages to the ESME e Ancillary Operations Operations designed to provide enhance features such as cancellation query or replacement of messages The following sub sections list each category and its associated operations SMPP V5 0 Draft06 SMS Forum 13 of 127 CO CO www smsforum net SMS FORUM 1 2 4 1 Session Management Operations SMPP PDU Name Description bind_transmitter Authenticatio
35. next request However this is not the case 2 5 1 The PDU Sequence Number Each SMPP PDU has an identifier called a sequence number that is used to uniquely identify the PDU in the context of the SMPP session The resulting response PDU is expected to mirror the sequence number of the original request The following diagram illustrates the use of sequence numbers Message Center Network Connection bind_transceiver seq 1 bind_transceiver_resp seq 1 a deliver_sm seq 1 deliver_sm_resp seq 1 deliver_sm seq 2 deliver_sm_resp seq 2 submit_sm seq 2 lt q sub mit_sm_resp seq 2 query_sm seq 3 lt query_sm_resp seq 3 unbind seq 4 unbind_resp seq 4 Connection Closed Figure 2 12 Transceiver Session demonsirating PDU Sequencing Referring to the above example sequence numbers are uniquely issued per request PDU This means that for every PDU request issued by an ESME it must use a different sequence number The recommended approach is to use monotonic increasing sequence numbers starting at 1 The first issued PDU request has a sequence number of 1 the next uses 2 and soon Each response PDU must carry the sequence number used in the matching request In the above example the MC responded with a bind_transceiver_resp carrying a sequence number of 1 simply because the bind_transceiver request had a sequence number of 1 The next reques
36. of combinations of Integer C Octet Strings and Octet Strings that form the basic layout of any PDU body These fields are always present even if specified in NULL form 3 2 1 6 TLV Parameters Tagged Length Value TLV parameters as described in section 3 1 are identified by a tag length and value and can be appended to a PDU in any order The only requirement is that the PDU s standard fields are first encoded and then followed by the TLV parameters Otherwise the PDU decoding by the peer would be unable to decode the PDU TLVs were originally referred to as Optional Parameters in SMPP V3 4 In Version 5 0 of the protocol the term Optional Parameter applies only to TLVs that are not mandatory within a PDU Therefore TLVs are described in the context of a PDU as Mandatory TLVs and Optional TLVs The Term Optional Parameter is no longer used The reason for the change of terminology is that some new PDUs now feature TLVs as mandatory fields that must always be present In this context generally referring to these fields as Optional Parameters is misleading hence the change of terminology SMPP V5 0 Draft06 SMS Forum 45 of 127 CO CO www smsforum net SMS FORUM 3 2 2 A sample PDU The following PDU example illustrates how an SMPP PDU is decoded Sample PDU Values are shown in Hex format 00 00 00 2F 00 00 00 02 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 00 01 01 O00
37. process of binding into the MC This PDU can be sent by the ESME or MC as a means of initiating the termination of an SMPP session unbind_resp This PDU can be sent by the ESME or MC as a means of acknowledging the receipt of an unbind request After sending this PDU the MC typically closes the network connection enquire_link An ESME or MC as a means of testing the network connection sends this PDU The receiving end is expected to acknowledge the PDU as a means of verifying the test enquire_link_resp This PDU is used to acknowledge an enquire_link request sent by an ESME or MC generic_nack This PDU can be sent by an ESME or MC as a means of indicating the receipt of an invalid PDU The receipt of a generic_nack usually indicates that the remote peer either cannot identify the PDU or has deemed it an invalid PDU due to its size or content Table 1 1 Session Management Operations SMPP V5 0 Draft06 SMS Forum 14 of 127 CA ZC www smsforum net MS FORUM 1 2 4 2 Message Submission Operations SMPP PDU Name Description submit_sm A transmitter or transceiver ESME wishing to submit a short message can use this PDU to specify the sender receiver and text of the short message Other attributes include message priority data coding scheme validity period etc XXXX submit_sm_resp The MC response to a submit_sm PDU indicating the success or failure of the request Also included is a MC message_id that can be used in subsequ
38. smsforum net MS FORUM 3 1 2 SMPP Parameter Field Size Notation The following notation style is used throughout Note that some SMPP strings are optional and others mandatory Size Type Description of String type specified octets 1 Integer Fixed size integer field In this example the integer is of size 8 bits 1 octets 2 Integer Fixed size integer field In this example the integer is of size 16 bits 2 octets 4 Integer Fixed size integer field In this example the integer is of size 32 bits 4 octets Var C Octet This string is of variable length from 1 15 ASCII characters Max 16 String followed by an octet containing the NULL terminator An empty string is encoded as a single octet containing the NULL character 0x00 Fixed C Octet This string has two possible lengths 1or17 String 1 octet containing the NULL character or a fixed number of characters terminated with the NULL character in this example 16 characters plus the NULL character Octet Variable size octet string field In this example the size of the 0 254 String octet string field can vary from 0 to 254 octets Table 3 3 SMPP PDU Parameter Type Size Notation 3 2 General PDU Format The general format of an SMPP PDU consists of a PDU header followed by a body as outlined in the following SMPP PDU PDU Header mandatory PDU Body Optional Command Command Command Sequence PDU Body length id status number 4 octets 4 octets 4 octets 4 octets Length C
39. unbind_resp Connection Closed Message Center Figure 2 9 Example Receiver Session SMPP V5 0 Draft06 SMS Forum 25 of 127 www smsforum net 2 4 3 Example Transceiver Session CONICO 4 MS FORUM Message Center Network Connection bind_transceiver bind_transceiver_resp Bound_TRX lt _ deliver sm deliver_sm_resp deliver_sm deliver_sm_resp submit_sm SU bm ft am resp query_sm HM query_sm_resp unbind unbind_resp Unbound Connection Closed Figure 2 10 Example Transceiver Session SMPP V5 0 Draft06 SMS Forum 26 of 127 www smsforum net 2 4 4 Example Outbind Session This example depicts an outbind session that results in the binding of a receiver ESME Network Connection outbind bind_receiver lt a bind_receiver_resp Bound_RX lt q _ deliver sm deliver_sm_resp q deliver sm deliver_sm_resp unbind unbind_resp Connection Closed Message Center Figure 2 11 Example Outind Session SMPP V5 0 Draft06 SMS Forum 27 of 127 CO CO www smsforum net SMS FORUM 2 5 PDU Sequencing Up to now we have referred to PDUs by name and indicating the request response pairs in the form of the session diagrams The impression can be formed that SMPP is a handshake protocol where each request is first acknowledged before issuing the
40. 0 4 6 4 4 SOUICO_MOtWOPk_tyPO see eeeeceecccceeeeeceeeeeeeceeeenseceeeeaeeeeesneeceeeeneeeeenenneees 110 4 6 4 5 Gest bearer ty PO vec veicvs eve ieesviice ve niece AS 110 4 6 4 6 Spure Dearer TYPO aoso sda raia gege gedd 111 4 6 4 7 dest telematics EE 111 4 6 4 8 Source telematics jd 111 4 6 4 9 GOS time WT 111 4 6 4 10 payload e 112 4 6 4 11 Additional StatUS INFO_tOXt ccc ccccceceeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeenes 112 SMPP V5 0 Draft06 SMS Forum 5 of 127 CO CO www smsforum net SMS FORUM 5 4 6 4 12 4 6 4 13 4 6 4 14 4 6 4 15 4 6 4 16 4 6 4 17 4 6 4 18 4 6 4 19 4 6 4 20 4 6 4 21 4 6 4 22 4 6 4 23 4 6 4 24 4 6 4 25 4 6 4 26 4 6 4 27 4 6 4 28 4 6 4 29 4 6 4 30 4 6 4 31 4 6 4 32 4 6 4 33 4 6 4 34 4 6 4 35 4 6 4 36 4 6 4 37 4 6 4 38 4 6 4 39 4 6 4 40 4 6 4 41 4 6 4 42 4 6 4 43 4 6 4 44 4 6 4 45 Change Log receipied message Idee 112 ms_msg_wait_facilities eee cece ennnen eeens ee ee eeaeeeeeeeeesecaaeaeeeeeeeeeeeeaaees 113 PMIVACY MdG sicz a cvcdisnes telaudevadad vues opteuparshduwenr a 113 Gelee e 114 d st SuUbAddIeSS oresenin ih EE 114 User message reterence see eee ceeeecee cece ee eeeeeeeeaeceeeeeeeeeeaeaeeeeeeeeeeeeaaees 115 USEF response Code ionin raiinn annan nat aai aian aiiai aaa 115 language Te EE 115 Source Poll erapr e a a a e aat 115 COSTIMATION DOE betdeseddAEEEE eege eoid ar Aa EE 116 sat ue E Ce E E 116 Sar_total segomente siesati niaii anaie 116 s r s gment S
41. 10 3 Datagram Message Mode The Datagram Message Mode emulates the datagram paradigm used in other data communication protocols such as UDP datagram packet transfer and focuses on high message throughput without the associated secure storage and retry guarantees of Store and Forward Message Mode In Datagram Message Mode the message originator i e the ESME does not receive any form of delivery acknowledgement In Datagram Message Mode typical SMSC functions such as scheduled delivery registered delivery etc do not apply Datagram Message Mode is designed for high throughput applications that may not require the highly secure delivery functionality offered by the Store and Forward message mode It is ideally suited for applications where the data content is transient in nature for example vehicle tracking applications Message ESME Center Bound_TX SME submit_s m gt gt datagram mode STEE submit_sm resp delivery attempt made Network Delivery Attempt NACK failure store amp forward submit_sm mode submit_sm _resp Multiple delivery attempts made until message is delivered or expires Network Delivery Attempt lt a _ NACK failure Network Delivery Attempt gt ACK success Figure 4 3 Datagram Message Mode SMPP V5 0 Draft06 SMS Forum 74 of 127 www smsforum net 4 2 10 4 Transaction Message Mode Tran
42. 120 sec XXX XXX_resp congestion_state 85 120 sec XXX XXX_resp congestion_state 83 120 sec XXX XXX_resp congestion_state 86 XXX_resp congestion_state 88 XXX 120 sec ra XXX_resp congestion_state 94 100 sec XXX 100 sec XXX_resp congestion_state 88 Nearing Congestion Figure 2 15 Flow Control amp Congestion Avoidance using the congestion_state TLV The above diagram shows a session where an ESME is transmitting PDUs at a rate of 50 second On recognising the congested_state TLV and its below Optimum value the ESME increased its rate until the congestion_state enters an optimum range At this point the ESME maintains the 120 PDUs second until the congestion_state enters Nearing Congestion at which time the ESME relaxes the messaging rate to return the congestion_state to an optimum level CL12 SMPP V5 0 Draft06 SMS Forum 36 of 127 CA ZC www smsforum net MS FORUM 2 9 Session Security and Encryption SMPP itself does not define any native encryption mechanisms The content exchanged across an SMPP session is open to hacking if it is transmitted across an open medium such as the Internet There are two recommended approaches to securing SMPP sessions 2 9 1 Secure Transport Layer The well known Secure Socket Layer SSL and its standardised form TLS provide an excellent means of securing a connection between two peers by using a variety of encryption ciphers and authent
43. 19 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 31 network_error_code The network_error_code parameter is used to indicate the actual network error code for a delivery failure The network error code is technology specific Field Size octets Type Description Parameter Tag 0x0423 Length EB _ Integer____ Length of value part in octets Octet String Sub field Type Network Type Integer Error Code Integer The first octet indicates the network type The following values are defined 1 ANSI 136 Access Denied Reason 2 IS 95 Access Denied Reason 3 GSM 4 ANSI 136 Cause Code 5 IS 95 Cause Code 6 ANSI 41 Error Z7 SMPP Error 8 Message Centre Specific All other values reserved The remaining two octets specify the actual network error code appropriate to the network type CL24 Table 4 79 network_error_code TLV 4 6 4 32 message_payload The message_payload parameter contains the user data Its function is to provide an alternative means of carrying text lengths above the 255 octet limit of the short_message field Field Size octets Type Description Parameter Ta9b _ Integer____ 0x0424 Length BR Irteger Beta length of user data Table 4 80 message_payload TLV SMPP V5 0 Draft06 SMS Forum 120 of 127 CA ZC www smsforum net MS FORUM 4 6 4 33 delivery_failure_reason The delivery_failure_reason parameter is used in the data_sm_resp operation to indicate the outcome of the mes
44. 2 e international International format from a mobile usually involves an international dial out prefix or the symbol followed by the country code operator code and mobile number International numbers usually carry a TON value of 1 However it is important to note that the character is never actually encoded in the source_adar or dest _adar fields For example a mobile sending a message to 4467811223344 is in fact using a TON 1 and dest_addr 4467811223344 e Alphanumeric Alphanumeric addressing provides a means of using human readable names for addresses In SMPP an alphanumeric address can carry any digit 0 9 and alphabetical character a z or A Z For example a voice mail server may send VoiceMail as a alphanumeric source address and as a means of indicating this it will set the TON 5 Some mobiles are capable of sending alphanumeric numbers and accomplish this by means of a TON value of 5 4 2 6 2 NPI NPI is generally set to 1 by all mobile devices Its purpose is to specify the numbering plan of the target device but because these all tend to be mobiles the value is generally set to 1 SMPP V5 0 Draft06 SMS Forum 69 of 127 CO CO www smsforum net SMS FORUM 4 2 6 3 ESME Addresses Specifying addresses for ESMEs is very much prone to the network operator s preferences and the message center implementation An ESME will typically use one of the following approaches e Service Short Code Short code
45. 21 submit_multi_resp 0x80000021 Reserved Ox00000022 0x000000FF SMPP V5 0 Draft06 SMS Forum 91 of 127 e e ub ell nb nb ep an R ut R nq mit_sm iver_sm ind ind_resp lace_sm cel_sm 0x00000008 served bind served uire_link served CNA ZC www smsforum net SMS FORUM Value 0x80000022 0x800000FF 0x00000100 0x80000100 0x00000101 0x80000101 alert_notification 0x00000102 0x80000102 0x00000103 Reserved for SMPP extension 0x00000104 OxOOOOFFFF kemmer Reserved 0x00010000 0x000101FF parson Reserved for SMSC Vendor 0x00010200 0x000102FF eee fers cence Table 4 30 command_id Values 4 5 3 command_status The command_status field of an SMPP message response indicates the success or failure of an SMPP request It is relevant only in the SMPP response message and should be set to NULL in SMPP request messages The SMPP Error status codes are returned by the SMSC in the command_status field of the SMPP message header and in the error_status_code field of a submit_multi_resp message The complete set of SMPP Error Codes and their associated values are defined in the following table Command Status Name WET Description eserved eserved SMPP V5 0 Draft06 SMS Forum 92 of 127 CA ZC www smsforum net MS FORUM Command Status Name WENA Description Reserved Ree Reserved Pee ES ESME_RINVSUBREP 0x00000042 Invalid submit with replace request i e submit_sm with repl
46. 6 SMS Forum 86 of 127 CA ZC www smsforum net MS FORUM 4 4 1 4 query_sm Syntax Field Name Size Type Description Ref octets ommand_length Integer Set to overall length of PDU rea e O E a e e ommend ss p equence_number Integer Setto a unique sequence number The 4 5 4 associated query em resp PDU should echo the same sequence number message_id Var C Octet Message ID of the message whose state 4 5 26 Max 65 String is to be queried This must be the SMSC assigned Message ID allocated to the original short message when submitted to the SMSC by the submit_sm data em or submit_multi command and returned in the response PDU by the SMSC ource_addr_ton fi Integer Type of Number of message originator 4 5 9 This is used for verification purposes and must match that supplied in the original request PDU e g submit_sm If not known set to NULL Source adr mp fi Integer Numberng Plan Identity of message 4 5 10 originator This is used for verification purposes and must match that supplied in the original request PDU e g submit_sm If not known set to NULL ource_addr Var C Octet Address of message originator 4 5 12 Max 21 String This is used for verification purposes and must match that supplied in the original request PDU e g submit_sm If not known set to NULL Table 4 26 query_sm PDU SMPP V5 0 Draft06 SMS Forum 87 of 127 CNA ZC www smsforum net SMS FORUM 4 4 1 5 query_sm_resp Synt
47. C RE and is usually initiated by the ESME CL5 There are three types of ESME initiated session Transmitter TX when authenticated as a transmitter an ESME may submit short messages to the MC for onward delivery to Mobile Stations MS A transmitter session will also allow an ESME cancel query or replace previously submitted messages Messages sent in this manner are often called mobile terminated messages Receiver RX A receiver session enables an ESME to receive messages from a MC These messages typically originate from mobile stations and are referred to as mobile originated messages Transceiver TRX A TRX ESME is a combination of TX and RX such that a single SMPP session can be used to submit mobile terminated messages and receive mobile originated messages Additionally the Message Centre can establish an SMPP session by connecting to the ESME This is referred to as an Outbind Session SMPP V5 0 Draft06 SMS Forum 12 of 127 CA ZC www smsforum net MS FORUM 1 2 4 Protocol Operations and PDUs The SMPP protocol is basically a set of operations each one taking the form of a request and response Protocol Data Unit PDU For example if an ESME wishes to submit a short message it may send a submit_sm PDU to the MC The MC will respond with a submit_sm_resp PDU indicating the success or failure of the request Likewise if a MC wishes to deliver a message to an ESME it may send a deliver_sm PDU to an ESME which
48. Description Ref octets command _length Integer Set to overall length of PDU Ee command_status Integer Indicates outcome of 4 5 3 submit_multi request sequence_number Integer Gei to sequence number of 4 5 4 original submit_multi PDU 4 4 4 4 message_id Var C Octet This field contains the SMSC 4 5 26 max 65 Strin message ID of the submitted g message It may be used at a later stage to query the status of a message cancel or replace the message no_unsuccess 1 Integer The number of messages to destination SME addresses that were unsuccessfully submitted to the SMSC This is followed by the specified number of unsuccessful SMEs each Specified in a unsuccess_ sme field Var Additional unsuccess_sme fields can be specified as delimited b the no_unsuccess field Message Submission Response TLVs unsuccess sme Unsucessful SME Composite Field dest_addr_ton Integer Type of number for destination dest_addr_npi Integer Numbering Plan Indicator for SME destination_addr C Octet Destination Address of SME String error_status_code Integer Indicates the success or failure of the submit_multi request to this SME address Table 4 18 submit_multi_resp PDU SMPP V5 0 Draft06 SMS Forum 66 of 127 CA ZC www smsforum net MS FORUM 4 2 4 Message Submission Request TLVs This section lists TLVs that may be used for message submission operations ba TLV Name Description ef luser_message_r
49. Draft06 SMPP V5 0 Draft06 Description Added Change Log to end of document for generalising various changes across draft versions Incorporated changes from Chris Wright to include definition of REs and rewording of introductary chapter to suit This includes a newly modified network diagram to depict the ESMEs MCs amp REs Modified network_error_code TLV to include details from enhancement CR and comments from Seattle Plenary Modified TLV definitions to include actual TLV tag value in Hex instead of TLV name Change based on similar approach taken with command_id in PDU definitions 3GPP references as provided by Edwin Sandberg added to references section Made several wording corrections spelling capitalisation and grammar corrections throughout document Removed HEADER BODY side columns from PDUs as these were causing problems with PDU formatting Something else possibly shading or heavy borders will have to be added to provide this separation Added Message Delivery TLVs section under data_sm and deliver_sm definition Added submit_multi and replace_sm PDU definitions Incorporated CRs e Minor SAR TLV clarification e Data em short_message message_payload error This was not incorporated as specified as document structure has separated deliver ACKs and other message content away from submit_sm data_sm where it is discussed more generally and in a non short_message oriented manner AT amp T 2 Error
50. Indication Active The Type of Message associated with the MWI is encoded in bits 0 and 1 as follows 00 Voicemail Message Waiting 01 Fax Message Waiting 10 Electronic Mail Message Waiting 11 Other Message Waiting Table 4 61 ms_msg_wait_facilities TLV 4 6 4 14 privacy_indicator Field Size octets Type Description 0x0201 Length 2 _ Integer Length of value part in octets Integer 0 Privacy Level 0 Not Restricted default 1 Privacy Level 1 Restricted 2 Privacy Level 2 Confidential Privacy Level 3 Secret alues 4 to 255 are reserved Table 4 62 privacy_indicator TLV The privacy_indicator indicates the privacy level of the message SMPP V5 0 Draft06 SMS Forum 113 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 15 source_subaddress The source_subaddress parameter specifies a subaddress associated with the originator of the message Field Size octets Type Description Parameter Tag Var Octet String The first octet of the data field is a Type of 2 23 Subaddress tag and indicates the type of subaddressing information included and implies the type and length of subaddressing information which can accompany this tag value in the data field Valid Tag values are 00000001 Reserved 00000010 Reserved 10000000 NSAP Even ITUT X 213 10001000 NSAP Odd ITUT X 213 10100000 User Specified All other values Reserved The remaining octets contain the subaddress A NSAP
51. MPP DEVELOPERS FORUM SHALL NOT BE LIABLE FOR ANY EXPENSES COSTS OR DAMAGE THAT MAY RESULT FROM THE USE OF THE INFORMATION CONTAINED HOWSOEVER ARISING IN THIS DOCUMENT OR ANY DERIVATIVE THEREOF NOTE 1 THE INFORMATION CONTAINED IN THE WITHIN DOCUMENT AND ANY DERIVATIVE THEREOF IS SUBJECT TO CHANGE WITHOUT NOTICE NOTE 2 THE CORPORATE NAME OF SMPP DEVELOPERS FORUM IS NORTHGROVE LIMITED COMPANY NUMBER 309113 REGISTERED OFFICE GARDNER HOUSE WILTON PLACE DUBLIN 2 SMPP V5 0 Draft06 SMS Forum 2 of 127 www smsforum net Table Of Contents 1 1 1 1 2 1 1 1 1 SMPP V5 0 Draft06 SMS Forum lte Leer Le Scope Of This Document SMPP OVEIrVICW 00 e ccceeccceceeeeeseeceeeeeceaeeeeaeeseeneeseaeeeeaaesteneeenaes EN Supported Cellular Technologies ssseesseesseeese eseese ensenen 2 2 Typical Applications of MPP EC El EE 2 4 Protocol Operations and PDUS ssssseesseesseesseeeeeseereresensns 2 4 1 Session Management Operations seese eseese 1 2 4 2 Message Submission Operations ccceeeeeeee 1 2 4 3 Message Delivery Operatons 1 2 4 4 Anciliary Operattons 1 2 4 5 Operation Matrix ecceeeeeeeceeeeeeeeeeeeeeseneeesnaeeeeeeseaes 1 3 GIOSS ANY sissies ec see 1 4 eet egene AA Eege E 2 OMPP S SSIONS tiseectessev eet ts seectevaeveudtivenlvsaehidisvenvdeededd tannins 2 1 Application Layer Communication sssseeeeeeeeeeeeeeeeeesreen 2 2 Establishing an SMPP Session sesesseese
52. Maximum length is 256 octets Table 4 59 additional_status_info_text TLV 4 6 4 12 receipted_message_id The receipted_message_id parameter indicates the ID of the message being receipted in an SMSC Delivery Receipt This is the opaque SMSC message identifier that was returned in the message_id parameter of the SMPP response PDU that acknowledged the submission of the original message Field Size octets Type Description ParameterTagle _ Integer____ 0x001E Length BR Irieger Lenot of Value part in octets Vale bh Sp C Octet String SMSC handle of the message being receipted Table 4 60 receipted_message_id TLV SMPP V5 0 Draft06 SMS Forum 112 of 127 CA ZC www smsforum net MS FORUM 4 6 4 13 ms_msg_wait_facilities The ms_msg_wait_facilities parameter allows an indication to be provided to an MS that there are messages waiting for the subscriber on systems on the PLMN The indication can be an icon on the MS screen or other MMI indication The ms_msg_wait_facilities can also specify the type of message associated with the message waiting indication Field Size octets Type Description Parameter Tagl2 Integer 0x0030 Length PB integer Length of Value part in octets Bit mask IOOOOOTT This parameter controls the indication and specifies the message type of the message associated with the MWI at the mobile station The Indicator is encoded in bit 7 as follows 0 Set Indication Inactive 1 Set
53. OU esdeEEEEEEEE ENEE a aa a 117 sc interface VErSION cic ege dee a a a a ee 117 dieplay ln 117 ER e TT 118 CDE TE 118 Stl E 119 Ms_availability Status ccccccceeeseecece cece eeeeeeenaeeeeeeeeesecaeaeeeeeeeeeeeeaees 119 nehwork emor Code 2 ccceccccccccccceceeeceeeeeeeeeeeeeeeeeeeeeseeseeeeeeeeeeeeseseeeneeeeees 120 message PaylOad E 120 delivery failure reason ssssssssrsenseesssssrnrnsssertnnnnnnsstertnnnnnnentnnnnn nnee 121 More _ MESSAGES Io send 121 MESSAGE EE 121 Callback POP erences EE eege Edge 122 Callback num Drees md 123 callback num oata0g cece eeeeeeeaeaeeeeeeesesaaeaeeeeeeeeeeennaeeeeeeeess 123 number of messages sssssssssssrrenstestrtnnrtestttrn nn nntesttnnn nannten nn nnna 124 sme Signal EE 124 alert_on_message_delivery 0 cece eee eeeeeee cece ee eeeeeeaeeeeeeeeeeeeecneeeeeeeeeeee 124 te reply E 124 EE ln Me ME 125 USS service OD MET 125 CONGESTION EC 126 SMPP V5 0 Draft06 SMS Forum 6 of 127 www smsforum net List Of Tables Table 1 1 Session Management Operations Table 1 2 Message Submission Operations Table 1 3 Message Delivery Operations Table 1 4 Anciliary Operations Table 1 5 Operation Matrix Table 1 6 Glossary Table 1 7 References Table 2 1 SMPP Session Timers Table 3 1 SMPP PDU Parameter Types Table 3 2 SMPP PDU Parameter Type NULL Settings Table 3 3 SMPP PDU Parameter Type Size Notation Table 3 4 SMPP PDU Format Table 3 5 SMPP PDU Format
54. Octet This field is unused and should 4 5 26 Max 65 String be set to NULL Message Delivery Var TLV 4 3 Response TLVs Table 4 22 deliver_sm_resp PDU 4 3 4 3 2 data_sm Operation The data_sm operation is symmetrically used for delivery as it is used to submit messages For detail on the specification of data_sm refer to section 4 2 2 CL15 4 3 3 Message Delivery TLVs The following table lists TLVs appropriate for message delivery using deliver_sm or data_sm operations isource_port Indicates the application port number associated with the 4 6 4 20 ource address of the message This parameter should be present for WAP applications isource_addr_subunit he subcomponent in the destination device which reated the user data destination_port Indicates the application port number associated with the 4 6 4 21 TLV Name Description Ref 4 4 ef user_message_reference ESME assigned message reference number 6 4 17 6 4 2 destination address of the message This parameter should be present for WAP applications dest_addr_subunit he subcomponent in the destination device for which the 14 6 4 user data is intended msg_ he reference number for a particular concatenated short 4 6 4 22 message Indicates the total number of short messages within the 4 6 4 23 oncatenated short message sar_segment_seqnum Indicates the sequence number of a particular short 4 6 4 24 message fragment within the concatenated short messa
55. SMS short Message Peer to Peer Protocol Specification Version 5 0 Draft06 CO CO www smsforum net SMS FORUM Short Message Peer to Peer Protocol Specification v5 0 Draft06 11 Dec 2001 1999 2001 SMPP Developers Forum COPYRIGHT All rights reserved This document or any part thereof may not without the prior written consent of SMPP Developers Forum be copied reprinted or reproduced in any material form including but without prejudice to the foregoing and not by way of exception photocopying transcribing transmitting or storing in any medium or translating into any language in any form or by any means including but not limited to electronic mechanical xerographic optical magnetic digital or other methodology DISCLAIMER WHILST THE GREATEST CARE HAS BEEN TAKEN TO ENSURE THE ACCURACY OF THE INFORMATION AND DATA CONTAINED HEREIN SMPP DEVELOPERS FORUM DOES NOT WARRANT THE ACCURACY OR SUITABILITY OF SAME FOR ANY SPECIFIC USE SMPP DEVELOPERS FORUM EXPRESSLY DISCLAIMS ALL AND ANY LIABILITY TO ANY PERSON WHETHER A PURCHASER OR OTHERWISE IN RESPECT OF ANY CONSEQUENCES OF ANYTHING DONE OR OMITTED TO BE DONE BY ANY SUCH PERSON IN PARTIAL OR TOTAL RELIANCE UPON THE WHOLE OR ANY PART OF THE CONTENTS OF THIS PUBLICATION OR ANY DERIVATIVE THEREOF THE INFORMATION CONTAINED HEREIN IS BELIEVED TO BE ACCURATE AND RELIABLE HOWEVER SMPP DEVELOPERS FORUM ACCEPTS NO RESPONSIBILITY FOR IT S USE BY ANY MEANS OR IN ANY WAY WHATSOEVER S
56. SSR indication 2 USSR request 3 USSN request 4 to 15 reserved 16 PSSD response 17 PSSR response 18 USSR confirm 19 USSN confirm 20 to 31 reserved 32 to 255 reserved for vendor specific USSD operations Table 4 92 ussd_service_op TLV SMPP V5 0 Draft06 SMS Forum 125 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 45 congestion_state The congestion_state parameter is used to pass congestion status information between ESME and MC as a means of providing flow control and congestion avoidance capabilities to the sending peer The TLV can be used in any SMPP operation response PDU as a means of passing congestion status from one peer to another Typical uses of this would in submit_sm submit_sm_resp sequences where an ESME would drive a batch of submissions at a high rate and use continual tracking of the returned congestion_state values as a means of gauging the congestion increasing decreasing the rate as required to maintain the balance in the Optimum range CL25 Field Size octets Type Description 0x0428 Length 2 Integer Length of Value part in octets Integer 30 49 Medium Load 50 79 High Load 80 90 Optimum Load 90 99 Nearing Congestion 100 Congested Maximum Load All other values reserved Table 4 93 congestion_state TLV SMPP V5 0 Draft06 SMS Forum 126 of 127 www smsforum net 5 Change Log Version Change V5 0 Draft04 V5 0 Draft05 V5 0 Draft05 V5 0
57. Table 4 1 bind_transmitter PDU Table 4 2 bind_transmitter_resp PDU Table 4 3 bind_receiver PDU Table 4 4 bind_receiver_resp PDU Table 4 5 bind_transceiver PDU Table 4 6 bind_transceiver_resp PDU Table 4 7outbind PDU Table 4 8 unbind PDU Table 4 9 unbind_resp PDU Table 4 10 enquire_link PDU Table 4 11 enquire_link_resp PDU Table 4 12 generic_nack PDU Table 4 13 submit_sm PDU Table 4 14 submit_sm_resp PDU Table 4 15 data_sm PDU Table 4 16 data_sm_resp PDU Table 4 17 submit_multi PDU Table 4 18 submit_multi_resp PDU Table 4 19 Message Submission Request TLVs Table 4 20 Message Submision Response TLVs Table 4 21 deliver_sm PDU Table 4 22 deliver_sm_resp PDU Table 4 23 Message Delivery TLVs Table 4 24 cancel_sm PDU Table 4 25 cancel_sm_resp PDU Table 4 26 query_sm PDU Table 4 27 query_sm_resp PDU Table 4 28 replace_sm PDU Table 4 29 replace_sm_resp PDU Table 4 30 command_id Values Table 4 31 command_status Values Table 4 32 interface_version Values Table 4 33 TON Values Table 4 34 NPI Values Table 4 35 service_type Values Table 4 36 esm_class Bit Values Table 4 37 priority_flag Values Table 4 38 Absolute UTC Time Format Table 4 39 Relative Time Format Table 4 40 registered_delivery Values Table 4 41 replace_if_present Values Table 4 42 data_coding Values Table 4 43 sm_default_msg_id Values Table 4 44 sm_length Values SMPP V5 0 Draft06 SMS Forum CONAC a M S FORUM 7 of 127 www smsforum net
58. _ USSR SMPP V5 0 Draft06 SMS Forum 18 of 127 CA ZC www smsforum net MS FORUM 1 4 References f Document Title Document Number Version Number Re GSM 03 40 Technical Realisation of the GSM 03 40 v5 7 1 Short Message Service Point to http www etsi fr Point GSM 03 38 Digital Cellular GSM 03 38 telecommunications system http Awww etsi fr Phase 2 Alphabets and language specific information GSM MAP GSM Mobile Application Part GSM MAP 09 02 v5 11 0 09 02 http www etsi fr IS637 Short Message Service for TIA EIA IS 637 A RevA Spread Spectrum Systems TSAR Teleservice Segmentation and TIA EIA 136 620 Rev 0 Reassembly TSAR CMT 136 Short Message Service Cellular TIA EIA 136 710 A RevA Messaging Teleservice GUTS General UDP Transport Service TIA EIA 136 750 Rev 0 GUTS WAPARCH Wireless Application Protocol WAP Forum Version Architecture Specification http www wapforum org 30 Apr 1998 WCMP Wireless Control Message WAP Forum Version Protocol Specification htto www wapforum org 12 June 1998 W DP Wireless Datagram Protocol WAP Forum Version Specification http www wapforum org 10 Feb 1999 ITUT X 213 Open Systems Interconnection ITUT X 213 11 95 Net work Service Definition KOR ITS PCS operators common PCS standardization 1 06 Rev standards for handset SMS committee 99 04 30 functionalities PCS SMS 97 05 28 BGPP TS Technical Realization of the Short 3GPP
59. _id sequence_number 4 Integer Gei to the same sequence number of 4 5 4 original enquire_link PDU Table 4 11 enquire_link_resp PDU SMPP V5 0 Draft06 SMS Forum 56 of 127 CA ZC www smsforum net MS FORUM 4 1 3 Generic NACK Operation 4 1 3 1 generic pack Syntax Following is the format of the SMPP generic_nack PDU It comprises the SMPP message header only Field Name Size Type Description Ref octets command_length Integer Defines the overall length of the PDU sequence_number command_status 4 Integer Error code corresponding to reason for 4 5 3 ending the generic_nack Integer Set to sequence number of original 4 5 4 PDU or to NULL if the original PDU annot be decoded Table 4 12 generic_nack PDU SMPP V5 0 Draft06 SMS Forum 57 of 127 CNA ZC www smsforum net SMS FORUM 4 2 Message Submission Operations 4 2 1 submit_sm Operation This operation is used by an ESME to submit a short message to the SMSC for onward transmission to a specified short message entity SME 4 2 1 1 submit_sm Syntax Field Name Size Type Description Ref octets command_length il fen to overall length of PDU sequence_number 4 Integer Get to a Unique sequence 4 5 4 number The associated submit_sm_resp PDU will echo this sequence number service_type C Octet The service_type 4 5 15 Var String parameter can be used to indicate the SMS max 6 ee Application service associated with the message Specif
60. ace_if_present_flag Reserved E EE SS nvalid replace_if_present flag nvalid number of messages hrottling error ESME has exceeded allowed message limits Reserved Poe ESME_RINVSCHED ESME_RINVEXPIRY 0x00000062 _ Invalid message validity period Expiry time ESME_RX_T_APPN 0x00000064 ESME Receiver Temporary App Error Code ESME_RX_P_APPN 0x00000065 ESME Receiver Permanent App Error Code ESME_RX_R_APPN 0x00000066 ESME Receiver Reject Message Error Code Reserved Pee EE SS Invali S ESME_RMISSINGOPTPARAM 0x000000C3 Expected Optional Parameter missing ESME_RINVOPTPARAMVAL 0x000000C4 Invalid Optional Parameter Value Reserved Ox000000C5 Reserved 0x000000FD ESME_RDELIVERYFAILURE 0x000000FE Delivery Failure used for data_sm_resp ESME_RUNKNOWNERR 0x000000FF ESME_RSERTYPUNAUTH 0x00000100 ESME Not authorised to use specified service_type CL18 ESME_RPROHIBITED 0x00000101 ESME Prohibited from using specified operation CL19 SMPP V5 0 Draft06 SMS Forum 93 of 127 CNA ZC www smsforum net SMS FORUM Command Status Name EUTG Description ESME_RSERTYPUNAVAIL 0x00000102 Specified service_type is unavailable CL20 ESME_RSERTYPDENIED 0x00000103 Specified service_type is denied due to inappropriate message content wrt Selected service_type CL21 Ox000003FF Specific errors Ox000004FF OxFFFFFFFF Table 4 31 command_status Values SMPP V5 0 Draft06 SMS Forum 94 of 127 CA ZC www smsforum net MS FORUM 4 5
61. address 4 5 11 eee ee see rmomestonas Table 4 1 bind_transmitier PDU interface_version Integer Indicates the version of the SMPP protocol supported by the ESME system_type Var C Octet Identifies the type of ESME system 4 max 13 String requesting to bind as a transmitter with the SMSC ENN 5 5 0 6 0 7 5 8 EK 5 9 SMPP V5 0 Draft06 SMS Forum 48 of 127 CA ZC www smsforum net MS FORUM 4 1 1 2 bind_transmitter_resp Syntax The SMPP bind_transmitter_resp PDU is used to reply to a bind_transmitter request The format of the SMPP bind_transmitter_resp PDU is defined in the following table Field Name Size Type Description Ref command_length 4 Integer Defines the overall length of the lbind_transmitter_resp PDU command_status 4 Integer Indicates status Success or error 4 5 3 code of original bind_transmitter request sequence_number 4 Integer Get to sequence number of original bind_transmitter request system_id Var C Octet SMSC identifier max 16 String identifies the SMSC to the ESME Optional TLVs SMPP version supported by SMSC 4 6 4 25 Table 4 2 bind_transmitter_resp PDU octets 4 4 4 EN 5 4 0 5 SMPP V5 0 Draft06 SMS Forum 49 of 127 CNA ZC www smsforum net SMS FORUM 4 1 1 3 bind_receiver Syntax The format of the SMPP bind_receiver PDU is defined in the following table Field Name Size Type Description Ref Integer Defines the overall length of the PDU 4 in oct
62. ag DPF for certain delivery failure scenarios such as MS is unavailable for message delivery as indicated by the HLR The SMSC should respond to such a request with an alert_notification PDU when it detects that the destination MS has become available The delivery failure scenarios under which DPF is set is SMSC implementation and network implementation specific If a delivery pending flag is set by the SMSC or network e g HLR then the SMSC should indicate this to the ESME in the data_sm_resp message via the dpf_result parameter Field Size octets Type Description 0x0421 Length 2 _ Integer length of value part in octets Integer 0 Setting of DPF for delivery failure to MS noi requested 1 Setting of DPF for delivery failure requested default values 2 to 255 are reserved Table 4 77 set_dpf TLV 4 6 4 30 ms_availability_status The ms_availability_status parameter is used in the alert_notification operation to indicate the availability state of the MS to the ESME If the SMSC does not include the parameter in the alert_notification operation the ESME should assume that the MS is in an available state Field Size octets Type Description 0x0422 Length 2 _ Integer Length of value part in octets Integer 0 Available Default 1 Denied e g suspended no SMS capability etc 2 Unavailable values 3 to 255 are reserved Table 4 78 ms_availability_status TLV SMPP V5 0 Draft06 SMS Forum 1
63. air activation system Specification of the system_type is optional some SMSCs may not require ESME s to provide this detail In this case the ESME can set the system_type to NULL 4 5 8 interface_version This parameter is used to indicate the version of the SMPP protocol The following interface version values are defined Interface Version Value Indicates that the EMSE supports version 3 3 or earlier of the SMPP protocol 0x00 0x33 Indicates that the ESME is supporting SMPP version 3 4 Indicates that the ESME is supporting SMPP version 5 0 ll other values reserved Table 4 32 interface_version Values SMPP V5 0 Draft06 SMS Forum 95 of 127 CNA ZC www smsforum net SMS FORUM 4 5 9 addr_ton source_addr_ton dest_addr_ton esme_addr_ton These fields define the Type of Number TON to be used in the SME address parameters The following TON values are defined TON Value Subscriber Number 00000100 00000110 Table 4 33 TON Values 4 5 10 addr_npi source_addr_npi dest_addr_npi esme_addr_npi These fields define the Numeric Plan Indicator NPI to be used in the SME address parameters The following NPI values are defined NPI Value ld t WAP Client o bel 00010010 defined by WAP Forum All other values reserved Table 4 34 NPI Values 4 5 11 address_range The address_range parameter is used in the bind_receiver and bind_transceiver command to specify a set of SME addresses serviced by the ESME
64. another field indicate the length of the Octet String field An example of this is the short_message field of the submit_sm PDU which is Octet String encoded and its length is specified by the previous message_length field Tagged Length Value A Tagged Length Value Field is a special composite field TLV that comprises or three parts A 2 octet Integer Tag A 2 octet Integer Length An Octet String Value The Tag identifies the parameter The Length indicates the size of the Value field in octets An example of a TLV is the dest_bearer_type Its Tag is 0x0007 and had a value size of 1 octet The value 0x04 indicates USSD as a bearer type In its encoded form this TLV would be as follows 0x0007000104 the first 2 octets 0x0007 identifies the Tag dest_bearer_type The next two octets 0x0001 indicate the 1 octet length of the value field The value field 0x04 indicates USSD ref XXXX Table 3 1 SMPP PDU Parameter Types SMPP V5 0 Draft06 SMS Forum 41 of 127 www smsforum net 3 1 1 NULL Settings SMS When we refer to a NULL setting for a field we imply that the field is not carrying a value However it must still be encoded in the PDU The following examples indicate how NULL settings are handled for each of the SMPP PDU Parameter Types Parameter Type Integer C Octet String Octet String Tagged Length Value TLV NULL Setting Encoding 1 Octet 0X00 2 Octet 0X0000 4 Octet 0X00000000 A NULL
65. applications The following summarises common applications of SMPP CL4 e Voicemail alerts originating from a VPS Voice Processing System indicating voice messages at a customer s mailbox This is arguably one of the first ESME based applications of SMS and is still heavily used in the industry e Numeric and alphanumeric paging services With an SMS capable phone the need to carry both pager and phone is drastically reduced e Information services For example an application that enables mobile subscribers to query currency rates or share price information from a database or the WWW and have it displayed as a short message on the handsets e Calls directly dialled or diverted to a message bureau operator who forwards the message to the SMSC for onward delivery to a subscriber s handset e Directory services For example a subscriber calls a directory service requesting information on restaurants in a given area The operator lists out available restaurants and sends the appropriate information as an SMS to the caller e Location based services These include applications that use mobile hardware to send GPS or cell data across SMS and using an SMSC relay these messages to an ESME The may then use the collected data to manage services such as taxi assignment stolen vehicle tracking logistics control e Telemetry applications For example a household meter that transmits a short message to a utility company s billing system t
66. ax Field Name Size Type Description Ref octets ommand_length fnteger Set to overall length of PDU equence_number 4 Integer Set to sequence number of original query_sm PDU message_id e E Octet SMSC Message ID of the message 4 5 26 max x65 maros Sino hose state is being queried inal_date 1or17 C Octet Date and time when the queried message String reached a final state For messages hich have not yet reached a final state his field will contain a single NULL octet Ira state T Specifies the status of the queried short 14 5 31 message error seg e here appropriate this holds a network error code defining the reason for failure of message delivery Table 4 27 query_sm_resp PDU SMPP V5 0 Draft06 SMS Forum 88 of 127 CA ZC www smsforum net MS FORUM 4 4 2 replace_sm Operation This command is issued by the ESME to replace a previously submitted short message that is still pending delivery The matching mechanism is based on the message_id and source address of the original message Where the original submit_sm source address was defaulted to NULL then the source address in the replace_sm command should also be NULL 4 4 2 1 replace_sm Syntax Field Name Size Type Description Ref octets command _length il fen to overall length of PDU 4 4 5 sequence_number Integer Get to a Unique sequence 4 5 4 number The associated submit_sm_resp PDU will echo this sequence number 5 message_id
67. ax 65 1 7 ar 1 CA ZC www smsforum net MS FORUM dest_addr_npi 1 Integer Numbering Plan Indicator of destination SME address of the message s to be ancelled his is used for verification purposes and must match that supplied in the original message submission request PDU May be set to NULL when the message_id is provided destination_addr War C Octet Destination address of message s to be 4 5 13 max 21 String ancelled his is used for verification purposes and must match that supplied in the original message submission request PDU May be set to NULL when the message_id is provided Table 4 24 cancel_sm PDU 4 4 1 2 Cancel em resp Syntax The cancel_sm_resp PDU is used to reply to a cancel_sm request It comprises the SMPP message header only Field Name Size Type Description Ref octets ommand Length to overall length of PDU a e proar paeas outcome of cancel_sm request 45 3 5 3 PDU Table 4 25 cancel_sm_resp PDU SMPP V5 0 Draft06 SMS Forum 85 of 127 CO CO www smsforum net SMS FORUM 4 4 1 3 query_sm Operation This command is issued by the ESME to query the status of a previously submitted short message The matching mechanism is based on the SMSC assigned message_id and source address Where the original submit_sm data_sm or submit_multi source address was defaulted to NULL then the source address in the query_sm command should also be set to NULL SMPP V5 0 Draft0
68. back_num parameter then this parameter must occur an equal number of instances and he order of occurrence determines the particular callback_num_atag which corresponds to a particular callback_num isource_subadadress he sub address of the message originator dest_subaddress he sub address of the message destination user_response_code A user response code The actual response codes are implementation specific display_time Provides the receiving MS with a display time associated 4 6 4 26 ith the message isms_signal Indicates the alerting mechanism when the message is received by an MS ms_validity his parameter controls the indication and specifies the message type of the message associated with the MWI at the mobile station inumber_of_messages Indicates the number of messages stored in a mail box alert_on_msg_delivery Request an MS alert signal be invoked on message delivery language _indicator Indicates the language of an alphanumeric text message SMPP V5 0 Draft06 SMS Forum 80 of 127 CA ZC www smsforum net MS FORUM TLV Name Description Ref its_reply_type he MS user s reply method to an SMS delivery message 4 6 4 42 received from the network is indicated and controlled by his parameter i Session control information for InteractiveTeleservice 4 6 4 43 his parameter is used to identify the required USSD 4 6 4 44 Service type when interfacing to a USSD system CL16 its session_info i ussd_servic
69. ce address destination address and optional service_type field as a means of cancelling a range of messages sent from one address to another cancel_sm_resp The MC returns this PDU to indicate the success or failure of a cancel_sm PDU replace_sm The replace_sm PDU is used by an ESME to pass a message of a previously submitted message along with several other fields used to update the text validity period and other attributes of the message replace_sm_resp The replace_sm_resp PDU indicates the success or failure of a replace_sm PDU Table 1 4 Anciliary Operations SMPP V5 0 Draft06 SMS Forum 16 of 127 CA ZC www smsforum net MS FORUM 1 2 4 5 Operation Matrix When we consider the various SMPP operations and states where ESMEs and MCs alike are allowed to use these operations we fully appreciate the concept of SMPP Session States The following table lists each SMPP operation PDU by name and the appropriate Session states for its usage indicating in terms of ESME and MC which peer can issue the PDU Note An SMPP Routing Entity RE is capable of emulating an ESME and MC at the same time and therefore all MC or ESME operations listed below are also simultaneously applicable to a RE For example a RE may issue a bind_transmitter to a MC while a session is in an open state RE binding to Message Center Additionally the RE may return a bind_transmitter_resp PDU to an ESME with an open state session ESME binding to RE CL7
70. ceiver called ESME Transceiver There are three SMPP bind PDUs to support the various modes of operation namely bind_transmitter bind_transceiver and bind_receiver The command_id field setting specifies which PDU is being used An ESME may bind as both an SMPP Transmitter and Receiver using separate bind_transmitter and bind_receiver operations having first established two separate network connections Alternatively an ESME can also bind as a Transceiver having first established a single network connection SMPP V5 0 Draft06 SMS Forum 47 of 127 CNA ZC www smsforum net SMS FORUM 4 1 1 1 bind_transmitter Syntax The format of the SMPP bind_transmitter PDU is defined in the following table Field Name Size Type Description Ref octets Integer Defines the overall length of the 4 bind_transmitter PDU command_length sequence_number 4 Integer Set to a unique sequence number 4 5 4 The associated bind_transmitter_resp PDU will echo the same sequence number system_id Var C Octet Identifies the ESME system max 16 String requesting to bind as a transmitter with the SMSC password Var C Octet The password may be used by the max 9 String SMSC to authenticate the ESME requesting to bind addr_ton 1 Integer Indicates Type of Number of the ESME address epee If not Known set to NULL addr_npi 1 Integer Numbering Plan Indicator for ESME 4 address IT If not known set to NULL address_range Var C Octet The ESME
71. ch the sender requests the SMSC to keep the message if undelivered before it is deemed expired and not worth delivering If the parameter is not present the SMSC may apply a default value ield Size octets Type Description F Integer 0x0017 L I L Value Length RB Integer Length of Value part in octets nteger Integer number of seconds for message to be retained by the receiving system Table 4 57 gos_time_to_live TLV SMPP V5 0 Draft06 SMS Forum 111 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 10 payload_type The payload_type parameter defines the higher layer PDU type contained in the message payload Field Size octets Type Description Parameter Tag Integer 0 Default In the case of a WAP application the default higher layer message type is a WDP message See WDP for details 1WCMP message Wireless Control Message Protocol ormatted data See WCMP for details alues 2 to 255 are reserved Table 4 58 payload_type TLV 4 6 4 11 additional_status_info_text The additional_status_info_text parameter gives an ASCII textual description of the meaning of a response PDU It is to be used by an implementation to allow easy diagnosis of problems Field Size octets Type Description Parameter Tag Integer 0x001D Length 2 Integer Length of Value part in octets Value 1 256 C Octet String Free format text to allow implementations to supply the most useful information for problem diagnosis
72. dges each request it will immediately find another request waiting If the MC has the ability to dispatch several PDUs at one time for processing then again the benefit of asynchronous transmission will ensure greater throughput If the ESME is synchronous and can only send a single PDU at a time then as soon as the MC acknowledges the PDU the SMPP session is idle until the response PDU is received by the ESME and the next request is dispatched and received by the MC If we consider the transport time from ESME to MC to take a microseconds then the overall idle time per operation is 2a This is the elapsed idle time while the response is in transit to the ESME and when the next request is in transit to the MC An entria asynchronous window of requests effectively avoids this inefficiency SMPP V5 0 Draft06 SMS Forum 31 of 127 www smsforum net 2 6 Session Timers SMS SMPP operations are based on the exchange of operation PDUs between ESME and MC In order to control the amount of time spent waiting for a response to arrive or particular operation to occur the following timers are defined Required Action on expiration SMPP Session State Session Init Timer Open The network connection Outbound should be terminated Enquire Link Timer Open An enquire_link request Unbound should be initiated Outbound Bound_TX Bound_RX Bound_TRX SMPP V5 0 Draft06 SMS Forum Description This timer specifies the time lapse allow
73. e typical error code would be ESME_RX_R_APPN which is a means of rejecting a message and ensuring that it is not retried at a later point The PDU is not allowed in the current session state This is a violation of the rules of the SMPP sessions and a simple example would be an ESME in Bound_RxX state attempting to submit a message by sending a submit_sm PDU or by attempting to submit a message across an Open State session without first binding The expected command status in the submit_sm_resp PDU would be ESME_RINVBNDSTS The ESME or MC is restricting the use of certain PDUs or features SMPP has a broad scope of functionality and some Message Centres or ESMEs may deliberately provide mechanisms to disable certain features For example if an operator configured a message centre to reject attempts by ESMEs to request delivery receipts for messages it would force the MC to reject the message with a command status set to ESME_RINVREGDLVEFLG Although the field may not incorrectly encoded its usage is disabled and the MC is authorised to reject the message using that error code SMPP V5 0 Draft06 SMS Forum 34 of 127 CA ZC www smsforum net MS FORUM 2 8 Flow Control and Congestion Avoidance It is a common misconception that windowing provides full flow control However all that is gained is a finite limit to an asynchronous window and as already discussed section 2 5 4 asynchronous transmission has many advantages in the area of maximisin
74. e_op message_state Should be present for SMSC Delivery Receipts and 4 6 4 35 Intermediate Notifications network_error_code May be present for delivery receipts and Intermediate 4 6 4 31 Notifications receipted_message_id SMSC message ID of message being receipted Should 4 6 4 12 be present for MC Delivery Receipts and Intermediate Notifications Table 4 23 Message Delivery TLVs 4 3 4 Delivery Message Types There are a number of different types of message that can be delivered to an ESME Receiver or Transceiver These are as follows e Normal Message This can be any normal message originally submitted by a mobile phone or another ESME e MC Delivery Receipt e Intermediate Notification e SME User Manual Acknowledgement e SME Delivery Acknowledgement e Conversation Abort e MC MC Handover Message 4 3 4 1 MC Delivery Receipt This message type is used to carry a MC delivery receipt The MC on detecting the final state of a registered message ref 4 5 20 would normally generate a new receipt message addressed to the originator of the first message The MC Delivery Receipt is then delivered to the ESME in a deliver_sm or data_sm operation The following fields are relevant in the deliver_sm and data_sm operations when used for transmitting delivery receipts e source address i e source_addr_ton source_addr_npi source adr The source address will be taken from the destination address of the original short message whic
75. e_type match the same fields in the new message WELT Meaning o Don t replace default Replace Table 4 41 replace_if_present Values ESME applications that use this SMSC messaging function should use the same service_type and set the replace_if_present_flag parameter consistently to 1 for all messages including the first message This ensures that the SMSC has at most one message pending per destination SME for a particular application e g voice mail notification SMPP V5 0 Draft06 SMS Forum 103 of 127 CNA ZC www smsforum net SMS FORUM 4 5 22 data_coding The following values are defined for this field data_coding Bits Meaning 76543210 00000 SMSC Default Alphabet 00001 IA5 CCITT T 50 ASCII ANSI X3 4 0 0 oO O jo CO Les i i GI Oo O OI El 00100 Octet unspecified 8 bit binary O jo 00110 Cyrllic ISO 8859 5 CH L000 UCS2 ISO IEC 10646 L Pictogram Encoding 0 ISO 2022 JP Music Codes 00101 JIS X 0208 1990 OIl e A O a OI O CH HE CH l Reserved Reserved L Extended Kanji JIS X 0212 1990 KS C 5601 reserved GSM MWI control see GSM 03 38 l10O01xx xx GSM MWI control see GSM 03 38 GSM message class control see GSM 03 38 l a CH CH CH jo Les Ge jo O CH jo oO O H CO Les oO ECH oO fo oO CH oO CH fo I o I Les H oO H ae oe al e D oy
76. ed between a network connection being established by an ESME and a bind_transmitter bind_receiver or bind_transceiver request being sent to the MC The timer can also be used by a MC supporting Outbind and applied to the time interval between an Outbind request being sent to an ESME and its response with a bind request This timer can also be used by an ESME supporting Outbind where an ESME will close the MC initiated connection within the defined period if the MC fails to send an Outbind request This timer should always be active on the MC and on ESMEs supporting Outbind This timer specifies the time lapse allowed between operations after which an SMPP entity should interrogate whether it s peer still has an active session This timer may be active on either side of the SMPP session i e MC or ESME 32 of 127 CA ZC www smsforum net MS FORUM Required Action on expiration Description SMPP Session State Inactivity Timer Bound_TX The SMPP session This timer specifies the Bound_RX should be dropped maximum time lapse Bound_TRX allowed between transactions after which period of inactivity an SMPP entity may assume that the session is no longer active The resulting behaviour is to either close the session or issue an unbind request This timer may be active on the MC or ESME side of the session Response Timer Open The entity which This timer specifies the time Unbound originated the SMPP la
77. ed in a single octet with the value 0x05 A 2 octet integer with the decimal value of 41746 would be encoded as 2 octets with the value 0xA312 A 4 octet integer with the decimal value of 31022623 would be encoded as 4 octets with the value 0x1D95E1F C Octet String A C Octet String is a sequence of ASCII characters terminated with a NULL octet 0x00 The string Hello would be encoded in 6 octets 5 characters of Hello and NULL octet as follows 0x48656C6C6F00 Two special variants exist for use within SMPP These are C octet String Decimal and C Octet String Hexadecimal which are used to carry decimal and hexadecimal digit sequences respectively These fields are encoded the same way as any ASCII string but are specifically used to designate decimal and hexadecimal numbers when presented in string format A Decimal C Octet String 123456789 would be encoded as follows 0x31323334353637383900 A Hexadecimal C Octet String A2F5ED278FC would be encoded as follows 0x413246354544323738464300 SMPP V5 0 Draft06 SMS Forum 40 of 127 CA ZC www smsforum net MS FORUM Parameter Type Description Octet String An Octet String is a sequence of octet not necessarily terminated with a NULL octet Such fields using Octet String encoding typically represent fields that can be used to encode raw binary data In all circumstances the field will be either a fixed length field or explicit length field where
78. ed messages is to provide for birthday services or SMS based reminder applications that pre populate the MC with various scheduled messages for a user 4 2 9 3 Pre defined A pre defined message is a canned message that is provisioned on a MC The ESME specifies the message by providing its ID in the default_msg_id field ref 4 5 23 The purpose of the predefined message is to relieve the ESME from specifying the actual text allowing the operator control over what goes to the subscriber 4 2 10 Message Modes The esm_class field ref 4 5 16 provides a Message Mode feature which if supported on the SMSC allows an ESME to select the SMSC message submission delivery mechanism Theses options are as follows e Default Message Mode This can be any of the following three modes but usually maps to Store and Forward mode e Datagram Mode Message delivery is attempted only once e Transaction Mode Message delivery is attempted once delaying the submit_sm_resp or data_sm_resp until the delivery attempt has been made e Store and Forward Mode The message is stored in the MC message database These Message Modes are described in more detail in the following sections 4 2 10 1 Default Message Mode Te concept of a default message mode rates to scenarios where an ESME does not specifically request a message mode In this scenario bits 0 1 of the esm_class are both set to 0 However a message mode will apply and is usually dep
79. eference ESME assigned message reference number source_port Indicates the application port number associated with the 4 6 4 20 ource address of the message This parameter should be present for WAP applications source_addr_subunit he subcomponent in the destination device which reated the user data destination_port Indicates the application port number associated with the 4 6 4 21 destination address of the message This parameter Should be present for WAP applications dest_addr_subunit he subcomponent in the destination device for which the 14 6 4 user data is intended sar_msg_ref_num he reference number for a particular concatenated short 4 6 4 22 message sar_total_segments Indicates the total number of short messages within the DA oncatenated short message sar_segment_seqnum Indicates the sequence number of a particular short 4 6 4 24 message fragment within the concatenated short message more_messages_to_send Indicates that there are more messages to follow for the destination SME o See ime to live as a relative time in seconds from submission 4 6 4 9 type 4 6 4 17 4 6 4 2 4 6 4 23 4 6 4 34 os_time_ payload type eines the type of payload e g WDP WCMP etc 6 4 message_payload Contains the extended short message user data Up to 64K octets can be transmitted Note The short message data should be inserted in either he short_message or message_payload fields Both fields Should not be used simul
80. endent on the Message Centre and possibly deployment strategy of the operator SMPP V5 0 Draft06 SMS Forum 72 of 127 www smsforum net S CONAC a M S FORUM 4 2 10 2 Store and Forward Message Mode The conventional approach to SMS has been to store the message in a MC storage area e g message database before forwarding the message for delivery to the recipient SME With this model the message remains securely stored until the MC has made all delivery attempts This mode of messaging is commonly referred to as store and forward The following diagram illustrates store and forward mode The message is first accepted by the Message Center and acknowledged with the submit_sm_resp PDU that is returned to the ESME The message center then makes an attempt to deliver the message which fails due to some network error Several retry attempts may occur until the message is finally delivered to the subscriber Store and forward is based on the concept of giving the message to the MC and relying on the MC to do a best effort attempt to deliver the message to its destination ESME Message Center SME Bound_TX submit_sm submit_sm _resp Network Delivery Attempt lt 4 NACK failure Network Delivery Attempt gt gt a ACK success SMPP V5 0 Draft06 Figure 4 2 Store and Forward Mode SMS Forum 73 of 127 CO CO www smsforum net SMS FORUM 4 2
81. ent operations to query cancel or replace the contents of an undelivered message submit_sm_multi A variation of the submit_sm PDU that included support for up to 255 recipients for the given message submit_sm_multi_resp The MC response to a submit_multi PDU This is similar to the submit_sm_resp PDU The main difference is that where some of the specified recipients were either invalid or rejected by the Message Centre the PDU can specify the list of failed recipients appending a specific error code for each one indicating the reason the recipient was invalid Also included is a MC message_id that can be used in subsequent operations to query cancel or replace the contents of an undelivered message data_sm Data_smis a streamlined version of the submit_sm operation designed for packet based applications that do not demand extended functionality normally available in the submit_sm operation ESMEs implementing WAP over SMS typically use this operation data_sm_resp The MC response to a data_sm PDU indicating the success or failure of the request Also included is a MC message_id that can be used in subsequent operations to query cancel or replace the contents of an undelivered message Table 1 2 Message Submission Operations 1 2 4 3 Message Delivery Operations SMPP PDU Name Description deliver_sm Deliver_sm is the symmetric opposite to submit_sm and is used by a MC to deliver a message to a receiver or transceiver ESME de
82. ese are present the other parameters of the message should remain unchanged for each short message fragment which forms part of a mobile terminated concatentated short message with the exception of those parameters for which it makes sense to change them such as the user data in the short_message parameter CL23 Field Size octets Type Description Parameter Tag Integer This parameter shall contain an originator generated reference number so that a segmented short message may be reassembled into a single original message This allows the parallel transmission of several segmented messages This reference number shall remain constant or every segment which makes up a particular oncatenated short message hen present the PDU must also contain the ar_total_segments and sar_segment_seqnum parameters Otherwise this parameter shall be ignored Table 4 70 sar_msg_ref_num TLV 4 6 4 23 sar_total_segments The sar_total_segments parameter is used to indicate the total number of short messages within the concatenated short message Field Size octets Type Description Integer This parameter shall contain a value in the range 1 to 55 indicating the total number of fragments within the oncatenated short message The value shall start at 1 and remain constant for every short message which makes up the concatenated short message hen present the PDU must also contain the ar_msg_ref_num and sar_segment_seqnum parameters Otherwise this pa
83. eseesresresrresrssn 2 3 Session States ceecceccecceeeeeceeececeeeeesaeeeeaaeeeeeeeseaeeseaaeseeaeeseeees 2 3 1 OPE Mehran aaae gees EES 2 3 2 Bound FX GE 2 3 3 BOUNGARX annern aa 2 3 4 Bound NR 2 3 5 DOUG EE ECH WE ele EE 237 eu e ln EE 2 4 Sample Sessions cccccccceceeeenceceeeeeceaeeeenaeseeeeeseaeeeeaaesteneeesaees 2 4 1 Example Transmitter Session ssseesseesee eese eeee erer reen reenn 2 4 2 Example Receiver Session cccccceseeceeeeseeeeeeeeeeeeeeeeees 2 4 3 Example Transceiver Geselon eerie rere eses 2 4 4 Example Outbind Session ccccceeecceceeeeeeeeeeeeseeteeeeesaes 2 5 PDU Sequencing EE 2 5 1 The PDU Sequence Number 2 5 2 Why MonotonicH 2 5 3 Sequence Numbers Across Gesong 2 5 4 Synchronous Vs Aevnchronous ereere 2 5 5 Why Asynchronous cecececeeeceeeeeeeeeeeeeeeeceeeesaeeeeaaeeeeees 2 6 SESSION TIMETS erdire teinana i ta hdres 2 7 Error Handlinga Aa A 2 7 1 Handling Connection Failure ccccceececeeeeeeesseeeeeseeteeeees 2 7 2 Operation Falure 2 8 Flow Control and Congestion Avoidance 2 9 Session Security and Encryption ssessssesseesseeseeseeeeesereeeeeee 2 9 1 Secure Transport Layer 2 9 2 Secure Tunnel wi222 ci selenite 2 10 Forward and Backward Compatibility 0 ccccceeeeeseeeeeees 2 10 1 Forward Compatibility ccc ccceeeeeeseeceeeeeseeeeeeeaeeeeeeenaees 2 10 2 Backward Compatibility 2 0 0 0 cc ceeceeeeeceteeeeeeeeeeeeeeeeeenees
84. ets 5 1 sequence_number Integer Get to a unique sequence number 4 5 4 The associated bind_receiver_resp PDU will echo the same sequence number system_id Var C Octet Identifies the ESME system 4 5 5 max 16 String requesting to bind as a receiver with the SMSC password Var C Octet The password may be used by the 4 5 6 max 9 String SMSC for security reasons to authenticate the ESME requesting to bind system_type Var C Octet Identifies the type of ESME system 4 5 7 max 13 String requesting to bind as a receiver with the SMSC 5 9 octets command_length command_id interface_version addr_ton 1 Type of Number TON for ESME address es served via this SMPP receiver session Set to NULL if not known addr_npi 1 Numbering Plan Indicator NPI for 4 ESME address es served via this SMPP receiver session Set to NULL if not known address_range Var C Octet A single ESME address or a range of 4 5 11 max 41 String ESME addresses served via this SMPP receiver session The parameter value is represented in UNIX regular expression format see Appendix A Set to NULL if not known Table 4 3 bind_receiver PDU Integer ldentifies the version of the SMPP protocol supported by the ESME SMPP V5 0 Draft06 SMS Forum 50 of 127 CA ZC www smsforum net MS FORUM 4 1 1 4 bind_receiver_resp Syntax The format of the SMPP bind_receiver_resp PDU is defined in the following table Field Name Size Type Descriptio
85. fines the following Parameter Tag blocks TLV Tag Range Meaning 0x0000 Reserved 0x0001 OxOOFF SMPP defined optional parameters 0x0100 0x01FF Reserved 0x0200 0x05FF SMPP defined optional parameters 0x1200 0x13FF SMPP defined optional parameters 0x1400 Ox3FFF Reserved for SMSC Vendor specific optional parameters Table 4 47 TLV Tag Value Ranges The SMPP supported Optional Parameters and their associated Tag Values are listed as follows 0x0600 Ox10FF Reserved for SMPP Protocol Extension CT Value Wireless Network Technology dest_addr_subunit 0x0005 GM dest_network_type 0x0006 Generic dest_bearer_type 0x0007 Generic dest_telematics_id 0x0008 GM source_addr_subunit 0x000D GM isource_network_type 0x000E Generic isource_bearer_type 0x000F Generic source_telematics_id 0x0010 GM gos_time_to_live 0x0017 Generic payload_type 0x0019 Generic additional_status_info_text 0x001D Generic receipted_message_id Ox001E Generic ms_msg_wait_facilities 0x0030 SMPP V5 0 Draft06 SMS Forum 107 of 127 CNA ZC www smsforum net SMS FORUM destination_port D Generic sar_segment_seqnum Du Generic i 0x0420 Generic set_dpf 0x0421 Generic ms_availability_status Danz Generic network_error_ code Danz Generic message payload _ fx0424 Generic delivery failure reason 0x0425 Generic 0x1201 CDMA TDMA 0x1203 TDMA 0x1204 ICDMA TDMA alert_on_message_delivery 0x130C CDMA its_reply_type
86. g throughput Flow control relates to the concept of a receiver informing the sender that it can t accept any more data In TCP this concept is supported by a receiver buffer advertisement which can be passed with every packet acknowledgement The sender uses this data as a means of judging how much data can be sent in subsequent transmissions This mechanism works fine for TCP given that congestion is based mostly on volumes of data being sent across busy networks or to a congested receiver In terms of SMPP if an ESME or MC submits delivers messages at a rate that exceeds the capabilities of its peer congestion may occur Relying on windowing to solve the problem is not enough The ESME will continue to top up its Window of unacknowledged requests keeping the MC under load to process these requests To better assist a peer ESME or MC in avoiding congestion we would need to provide a means for the receiving peer to indicate to the sending peer its state of congestion This is accomplished with the addition of an optional congestion_state TLV This parameter may be optionally included in any response PDU sent between ESME and MC This TLV contains a simple integer from 0 100 to indicate the Congestion state ranging from idle to congested Refer to 4 6 4 45 for details on the values acceptable for this TLV The ESME or MC can use this value as a means of detecting increased load scenarios on its peer and take the appropriate act
87. ge payload_type defines the type of payload e g WDP WCMP etc 4 6 4 10 SMPP V5 0 Draft06 SMS Forum 79 of 127 CNA ZC www smsforum net SMS FORUM Description Ref message_payload Contains the extended short message user data Up to 4 6 4 32 64K octets can be transmitted Note The short message data should be inserted in either he short_message or message_payload fields Both fields hould not be used simultaneously he sm_length field should be set to zero if using the message_payload parameter Note In the case of data_sm the message_payload TLV is the only means of specifying text set_dpf Indicator for setting Delivery Pending Flag on delivery 4 6 4 29 ailure privacy_indicator ndicates the level of privacy associated with the message 4 6 4 14 callback ou A callback number associated with the short message 4 6 4 36 his parameter can be included a number of times for multiple calloack addresses callback_num_pres_ind_ Defines the callback number presentation and screening d If this parameter is present and there are multiple instances of the callback_num parameter then this parameter must occur an equal number of instances and he order of occurrence determines the particular callback_num_pres_ind which corresponds to a particular callback_num callback_num_atag Associates a displayable alphanumeric tag with the allback number If this parameter is present and there are multiple instances of the call
88. h generated the delivery receipt The receipt appears as if it emanated from the recipient of the original registered message e destination address i e dest adr on dest adr np destination_addr The destination address will be taken from the source address of the original short message which generated the delivery receipt The receipt is addresses to the SME that originally sent the first registered message e eem Class Bit 2 of the esm_ciass is set to 1 to indicate that the message is a delivery receipt SMPP V5 0 Draft06 SMS Forum 81 of 127 CO CO www smsforum net SMS FORUM e message_state TLV This TLV indicates the final state of the original message Remember a receipt will be sent e network_error_code TLV e receipted_message_id TLV Note Many pre V3 4 interfaces and Message Centers supporting V3 3 are likely to have a means of passing receipt information within the short_message field The format specifics of this information is product specific and beyond the scope of this specification Note The returning of a message receipt is not always guaranteed The criteria used to control the returning of a receipt depend on the value set in the registered_delivery field ref 4 5 20 of the original message CL17 4 3 4 2 Intermediate Notification An intermediate notification is a special form of message that the MC may send to an ESME for a mobile terminated message delivery It provides an intermediate status of a mes
89. his sequence number service_type C Octet The service_type parameter 4 5 15 Va String Can be used to indicate the iiax SMS Application service associated with the message Specifying the service_type allows the ESME to avail of enhanced messaging services such as replace by service type to control the teleservice used on the air interface Set to NULL if not known by SMSC 5 1 Integer Type of Number for source 4 5 9 address Integer Numbering Plan Indicator 4 5 10 for source address C Octet Address of SME which 4 5 12 String loriginated this message 5 9 r source_addr r max 21 dest_addr_ton 1 Integer Type of Number for 4 destination r dest_addr_npi Integer Numbering Plan Indicator 4 5 10 for destination destination _addr Va C Octet Destination address of this 4 5 13 max 21 String Short message For mobile terminated messages this is the directory number of the recipient MS esm_class 1 Integer Indicates Message Mode 4 5 16 and Message Type protocol_id 1 Integer Protocol Identifier 4 5 17 Network specific field priority_flag 1 Integer Designates the priority level 4 5 18 of the message SMPP V5 0 Draft06 SMS Forum 77 of 127 CNA ZC www smsforum net SMS FORUM Field Name Size Type Description octets schedule_delivery_time 1or17 C Octet The short message is to be String scheduled by the SMSC for delivery Set to NULL if message not known or message is not
90. ication certificates SSL TLS is the backbone of how E commerce is managed and has provedn itself very reliable Many commercial and some open source libraries exist to facilitate the adaptation of SSL TLS based transport layers into applications The ESME or MC in supporting the SSL TLS approach would connect using the SSL TLS mechanism first establishing a secure and authenticated conenction before commencing the SMPP session 2 9 2 Secure Tunnel Another approach to securing an SMPP session is to use a secure tunnel This is where the ESME MC connection is not made directly from one peer to another but by connecting to a secure tunnel server The tunnel server is configured to match a particular insecure connection from an ESME with a secure connection to another tunnel usually located in the peers network The remote tunnel then matches the incoming connection with another insecure connection onwards to the other peer The result is that an ESME and MC combination unable to suport direct SSL TLS can still be secured for Internet ready communication by means the tunnel servers Message Center Wi 3 Insecure SMPP Session Insecure SMPP Session Secure Tunnel Server Secure Session Message Center ESME Netw ork Netw ork Figure 2 16 ESME MC SMPP session using a secure tunnel SMPP V5 0 Draft06 SMS Forum 37 of 127 CO CO www s
91. ion Response TN 69 4 2 6 Source and Destination Addressing ccccceecceeeeeeeeeeeeeeeeeeeeeeeseaeeeeaeeeeneeeaas 69 4 2 6 1 TOWN EE 69 4 2 6 2 NR E E A A A 69 4 2 6 3 ESME AddrEsS S niini aa aa a aa ai a aces 70 4 2 7 Message Replace operation in SUDMIt_SIM eeecceeeeeeeeeeeesteeeeeenaeeeeeenaeeeenenas 70 4 2 8 Message Lengtes user ENEE Reeder 70 4 2 9 Message TPOS rsa gesteet deen E 71 4 2 9 1 IS E E 71 4 2 9 2 SCNOGUISO s s sicsssecases caneadealidebareesseddsacd iann edoira siari aaia soia 71 4 2 9 3 Predelne EE 72 4 2 10 Message Modes ANERER 72 4 2 10 1 Default Message Mode AA 72 4 2 10 2 Store and Forward Message Mode 73 4 2 10 3 Datagram Message Mode AA 74 4 2 10 4 Transaction Message Mode sseesssseeesrnesssrneseenneernnnnsrennesrnnneneenneennnnnnne 75 4 3 Message Delivery Operations ccceccceceeeeeeeeeeeneeceeeeeeeaeeeeaeeseeeeesaeeteaaesseneeeaas 76 4 3 1 Celiver_SM Operation ccceccesecceceeeeeseaeeeeeeeceeeeecaeeeeaaeseeneeseaeeeeaeseeneesseneeaas 76 4 3 1 1 deliver sm Gvntax kA 77 4 3 1 2 deliver em resp Gwntan A 79 4 3 2 data em Operation 79 4 3 3 Message Delivery TVe een 79 4 3 4 Delivery Message Types c cccccceesseeceeeeeeeeeeseneeeeeaneeeeeneneeeeeneeaeeeensnaeeeeneaees 81 4 3 4 1 MC Delivery Receipt ccceeeceeeeeeeceeeeeeaeeeeaeeeeeeeeseaeeesaaeseeeesteneeeeeeee 81 4 3 4 2 Intermediate Notification sssrds iinn aai 82 4 3 4 3 SME Delivery Acknowledogement nees
92. ion to reduce its input rates In order to get the maximum throughput from the transfer of messages the MC or ESME should try to maintain the Congestion state between 80 90 Optimum Load When commencing an SMPP session the ESME or MC would begin transmission of requests with a maximum window of N If the ESME or MC supports the Congestion_State TLV then as the responses arrive the ESME MC can increase decrease its transmission rate according to the indicated Congestion state of its peer If the Congestion _State TLV is supported then the Window of N can actually be discarded as the Congestion_State itself acts as a better indicator and preventative measure of congestion avoidance If the TLV is not present in response PDUs then the simple windowing is the only means of applying flow control within the session The advantage of using congestion_state over a fixed window is that the ESME can avail of the most optimum performance available at a particular time instead of predetermining some window limit and using this consistently This recognises that a MC or ESME may be under varying levels of stress and that predetermined performance is not always guaranteed SMPP V5 0 Draft06 SMS Forum 35 of 127 www smsforum net SMS ESME Message Center Bound_TX 50 sec XXX XXX_resp congestion_state 40 80 sec XXX XXX_resp congestion_state 55 XXX_resp congestion_state 72
93. it_sm operation also facilitates replacement of a short message which has been previously submitted but has not yet been delivered to the designated destination This feature is designed for applications needing the ability to update an underlivered message The most common application of this feature is with voicemail systems The first message may read You have 1 message in your mail box If the mobile is unavailable the message will remain undelivered and in retry within the message center If another message is left for the same subscriber the voicemail server will send another message with the updated text You have 2 messages in your mail box If the replace_flag of the submit_sm PDU is set to 1 then this message should replace the underlivered first message The result is that the subscriber gets the latest message instead of all messages Alternatively an SMSC administrator may define a specific service_type to provide replace if present functionality In this case the replace function can be activated in the submit_sm PDU by setting the service_type field to the defined value For both methods of replacing a message using the submit_sm operation the data contained in the short message found in the SMSC whose source and destination addresses and service_type match those addresses specified in the latest submit_sm operation will be replaced with the text contained in the short_message field of that latest submit_sm opera
94. liver_sm_resp This PDU indicates the ESMEs acceptance or rejection of the delivered message The error returned by the ESME can cause the message to be retried at a later date or rejected there and then data_sm Data_sm can also be used for message delivery from Message Centre to the ESME ESMEs implementing WAP over SMS typically use this operation The ESME response to a data_smPDU indicating the success or failure of the MC initiated delivery request altering it to the availability of an SME Table 1 3 Message Delivery Operations SMPP V5 0 Draft06 SMS Forum 15 of 127 CO CO www smsforum net SMS FORUM 1 2 4 4 Anciliary Operations SMPP PDU Name Description query_sm This PDU is used to query the state of a previously submitted message The PDU contains the source address of the original message and the message_id returned in the original submit_sm_resp submit_multi_resp or data_sm_resp PDU query_sm_resp The MC returns a query_sm_resp PDU as a means of indicating the result of a message query attempt The PDU will indicate the success or failure of the attempt and for successful attempts will also include the current state of the message cancel_sm This PDU is used to cancel a previously submitted message The PDU contains the source address of the original message and the message_id returned in the original submit_sm_resp submit_multi_resp or data_sm_resp PDU This PDU may also omit the message_id and instead contain a sour
95. m the SMSC interprets the time format as the number of years months days hours minutes and seconds from the current SMSC time Values for tenths of seconds t and UTC offset nn are ignored and should be set to 0 and 00 respectively Absolute time is formatted as a 16 character string encoded as a 17 octet C octet String YYMMDDhhmmsstnnp where Digits Meaning year 00 99 month 01 12 oo rors hh hour 00 23 minute 00 59 second 00 59 Unused Should be set to 0 Unused Should be set to 00 In R Local time is relative to the current SMSC time Table 4 39 Relative Time Format For example the following time format 020610233429000R would be interpreted as a relative period of 2 years 6 months 10 days 23 hours 34 minutes and 29 seconds from the current SMSC time An SMSC operator may choose to impose a limit on relative time offsets thus either rejecting a message that exceeds such a limit or reducing the offset to the maximum relative time allowed For example a typical validity period might be 7 days and a typical scheduled delivery times might be 14 days from the submission time SMPP V5 0 Draft06 SMS Forum 101 of 127 CNA ZC www smsforum net SMS FORUM 4 5 20 registered_delivery The registered_delivery parameter is used to request an SMSC delivery receipt and or SME originated acknowledgements The following values are defined registered_delivery
96. m a buffer by extracting the first 4 octets assuming these to represent the command_length and then deduce from the value the overall size of the PDU Considering that 4 octets have been read from the buffer the deduced value is decremented by 4 to indicate the remaining PDU data to extract from the buffer An alternative approach to this is to view each SMPP PDU as a mandatory block of 16 octets representing the PDU header So an application wishing to decode a PDU for processing must wait until there are at least 16 octets available in the network connection buffer or continually read octets of data until 16 octets have been read This can now be broken down into the four 4 octet fields that make up the PDU Header By subtracting 16 from command_length value the application can evaluate the size of the PDU Body and use the same means of reading data form its buffers until the remaining data has been received 3 2 1 2 Command_id The command_id identifies the SMPP operation and although we refer to these operations by name in the form of submit_sm bind_transmitter etc in PDU format these operations are represented by numerical ids Command_ids for request PDUs are allocated from a range of numbers 0x00000000 to 0x000001FF Command_ids for response PDUs are allocated from a range of numbers 0x80000000 to 0x800001FF The relationship between the command_id for a request PDU and its associated response PDU is that bit 31 is cleared for
97. m request sequence_number Integer Get to sequence number of original submit_sm PDU message_id Var C Octet This field contains the SMSC 4 5 26 max 65 Strin message ID of the submitted g message It may be used at a later stage to query the status of a message cancel or replace the message Message Submission Var TLV 4 2 5 Response TLVs Table 4 14 submit_sm_resp PDU SMPP V5 0 Draft06 SMS Forum 60 of 127 CA ZC www smsforum net MS FORUM 4 2 2 data_sm Operation The data_sm operation is similar to the submit_sm in that it provides a means to submit a mobile terminated message However data_sm is specifically geared towards packet based applications such as WAP in that it features a reduced PDU body containing fields relevant to WAP or packet based applications 4 2 2 1 data em Syntax Field Name Size Type Description Ref octets command _length Integer Set to overall length of PDU sequence_number Integer Set to a Unique sequence 4 5 4 number The associated ubmit_sm_resp PDU will echo this sequence number service_type C Octet The service_type parameter 4 5 15 String an be used to indicate the max 6 SMS Application service associated with the message Specifying the service_type allows the ESME to avail of enhanced messaging services uch as replace by service ype to control the teleservice used on the air interface Set o NULL for default SMSC ettings source_addr_ton Integer ype of Number
98. messages delivered by the SMPP V5 0 Draft06 SMS Forum 30 of 127 CA ZC www smsforum net MS FORUM MC to the ESME The MC must support the ability to process response PDUs in a skew order The PDU sequence numbers make the request response matching possible So regardless of when an asynchronous response arrives it can be immediately matched to the original request PDU It is for this reason alone that each PDU request should use a unique sequence number within the context of the session 2 5 5 Why Asynchronous Synchronous behaviour may appear the easier route to take when developing an application Sending at most one PDU request waiting for the response before sending the next can be an easy alternative over the management of an entire window of PDUs which may be acknowledged in a skew order However for an application to efficiently utilise the SMPP session asynchronous transmission can make significant improvements The following diagram helps explain the reasoning for using the protocol in an asynchronous manner Message Center cl Network Connection Figure 2 14 Asychronous Windowing The above example shows 5 PDUs asynchronously transmitted across the SMPP session from the ESME to MC If the MC can process only one PDU at a time then the benefit of asynchronous transmission is actually not lost In this situation the window of PDUs becomes a queue of requests for the MC As soon as the MC acknowle
99. meter controls the presentation indication and screening of the CallBackNumber at the mobile station If present the callback_num parameter must also be present The Presentation Indicator is encoded in bits 2 and 3 as follows 00 Presentation Allowed 01 Presentation Restricted 10 Number Not Available 11 Reserved The Screening Indicator is encoded in bits 0 and 1 as follows 00 User provided not screened 01 User provided verified and passed 10 User provided verified and failed 11 Network Provided Table 4 85 callback_num_pres_ind TLV Value 4 6 4 38 callback_num_atag The callback_num_atag parameter associates an alphanumeric display with the call back number Field Size octets Type Description Parameter Tag 0x0303 Length PB Integer Length of Value part in octets EEEEEE octet 1 XXXXXXXX octet 2 XXXXXXXX octet N he first octet contains the encoding scheme of the Alpha Tag display characters This field contains the same values as for Data Coding Scheme see section 5 2 19 he following octets contain the display characters here is one octet per display character for 7 bit and 8 bit encoding schemes here are two octets per display character for 16 bit encoding schemes Table 4 86 callback_num_atag TLV SMPP V5 0 Draft06 SMS Forum 123 of 127 CNA ZC www smsforum net SMS FORUM 4 6 4 39 number_of_messages The number_of_messages parame
100. msforum net SMS FORUM 2 10 Forward and Backward Compatibility SMPP is an evolving protocol and V5 0 represents another version of the protocol The previous versions that are commonly used are V3 3 and V3 4 Version 3 4 introduced many new features that enhanced existing PDUs to support optional parameters To preserve backwards compatibility for older V3 3 compliant applications V3 4 required the bind operations to set the interface_version to 0x34 V5 0 continues this approach and requires the interface_version to be set to 0x50 2 10 1 Forward Compatibility Forward Compatibility procedures allow a functional entity i e MC or ESME using one version of the SMPP protocol to easily communicate with an entity using a later more enhanced version of the protocol Hence new enhancements to existing SMPP PDUs are implemented using TLVs The following guidelines must be followed in SMPP implementations to ensure that this process is implemented successfully and consistently e f an SMPP entity receives an unrecognized PDU command it must return a generic_nack PDU indicating an invalid command_id in the command_status field of the header e The SMPP entity receiving a message which includes Optional Parameters shall first inspect the Tag field of the Operational Parameter as follows o Ifthe Optional Parameter Tag is recognized and supported by the receiving SMPP entity for the particular SMPP operation the Optional Parameter shall be pr
101. n PDU used by a transmitter ESME to bind to the Message Centre The PDU contains identification information and an access password for the ESME bind_transmitter_resp Message Centre response to a bind_transmitter PDU This PDU indicates the success or failure of the ESME s attempt to bind as a transmitter bind_receiver Authentication PDU used by a transmitter ESME to bind to the Message Centre The PDU contains identification information an access password for the ESME and may also contain routing information specifying the range of addresses serviced by the ESME bind_receiver_resp Message Centre response to a bind_receiver PDU This PDU indicates the success or failure of the ESME s attempt to bind as a receiver bind_transceiver Authentication PDU used by a transceiver ESME to bind to the Message Centre The PDU contains identification information an access password for the ESME and may also contain routing information specifying the range of addresses serviced by the ESME bind_transceiver_resp Message Centre response to a bind_transceiver PDU This PDU indicates the success or failure of the ESME s attempt to bind as a transceiver outbind Authentication PDU used by a Message Centre to Outbind to an ESME to inform it that messages are present in the MC The PDU contains identification and access password for the ESME If the ESME authenticates the request it will respond with a bind_receiver or bind_transceiver to begin the
102. n Ref octet s command_length Ter E r the overall length of the PDU command_status 4 Integer lndicates status Success or error 4 5 3 code of original bind_receiver request sequence_number 4 Integer Get to sequence number of original 4 5 4 lbind_receiver request system_id Var C Octet SMSC identifier 4 5 5 max String identifies the SMSC to the ESME Optional TLVs sc_interface_version TLV EMP version supported by SMSC 4 6 4 25 Table 4 4 bind_receiver_resp PDU SMPP V5 0 Draft06 SMS Forum 51 of 127 CNA ZC www smsforum net SMS FORUM 4 1 1 5 bind_transceiver Syntax The format of the SMPP bind_transceiver PDU is defined in the following table Field Name Size Type Description Ref fel Integer Defines the overall length of the PDU sequence_number 4 Integer Get to a unique sequence number 4 5 4 Wm associated bind_transceiver_resp PDU will echo the same sequence number V V V octets command_length system_id ar C Octet Identifies the ESME system max 16 String requesting to bind as a transceiver ith the SMSC password ar C Octet The password may be used by the max 9 String SMSC to authenticate the ESME requesting to bind system_type ar C Octet Identifies the type of ESME system max 13 String requesting to bind as a transceiver ith the SMSC 1 1 1 ar 4 5 4 5 4 5 4 5 4 5 5 interface_version Integer ldentifies the version of the SMPP protocol supported by the ESME
103. nal parameters sar_msg_ref_num sar_total_segments sar_segment_seqnum or port addressing related optional parameters source_port destination_port cannot be used in conjunction with encoded User Data Header in the short_message user data field This means that the above listed optional parameters cannot be used if the User Data Header Indicator flag is set SMPP V5 0 Draft06 SMS Forum 98 of 127 CA ZC www smsforum net MS FORUM 4 5 17 protocol_id GSM Set according to GSM 03 40 GSM 03 40 ANSI 136 TDMA For mobile terminated messages this field is not used and is therefore ignored by the SMSC For ANSI 136 mobile originated messages the SMSC should set this value to NULL IS 95 CDMA For mobile terminated messages this field is not used and is therefore ignored by the SMSC For IS 95 mobile originated messages the SMSC should set this value to NULL 4 5 18 priority_flag The priority_flag parameter allows the originating SME to assign a priority level to the short message Priority Level GSM ANSI 136 IS 95 All other values reserved Table 4 37 priority_flag Values SMPP V5 0 Draft06 SMS Forum 99 of 127 CNA ZC www smsforum net SMS FORUM 4 5 19 scheduled_delivery_time and validity period 4 5 19 1 scheduled_delivery_time This parameter specifies the scheduled time at which the message delivery should be first attempted It defines either the absolute date and time or relative time from the current
104. ncoded as follows in the submit_sm submit_multi and data em ESME gt SMSC PDUs esm_class Bits Meaning Pa a EH Forward i e Transaction mode x xX xxx xil1il Store and Forward mode use to select Store and Forward mode if Default SMSC Mode is non Store and Forward Default message Type i e normal message Short Message contains SMSC Delivery Receipt x x 1000xx Short Message contains Intermediate Delivery Notification x x 0010xx Short Message contains ESME Delivery Acknowledgement x x 0100xx Short Message contains ESME Manual User Acknowledgement x x 0110xx Short Message contains Conversation Abort Korean CDMA No specific features selected UDHI Indicator only relevant for MT short messages Set Reply Path only relevant for GSM network lixx xx xx Set UDHI and Reply Path only relevant for GSM network Table 4 36 esm_class Bit Values Messaging Mode bits 1 0 bits 2 and 5 o 2 gt He o D o Ka o S ANSI 41 Specific bits 5 2 GSM Specific bits 7 6 The default setting of the esm_class parameter is 0x00 Notes If an ESME encodes GSM User Data Header information in the short message user data it must set the UDHI flag in the esm_class field If the SMSC delivers a short message that contains GSM User Data Header information encoded in the short_message or message_payload parameter it must set the UDHI flag in the esm_class field For GSM networks the concatenation related optio
105. nsceiver is authorised to use all operations supported by a Transmitter ESME and a Receiver ESME A transceiver ESME is effectively the combination of Transmitter and Receiver Thus an ESME bound as a transceiver may send short messages to an SMSC for onward delivery to a Mobile Station or to another ESME and may also receive short messages from an SMSC which may be originated by a mobile station by another ESME or by the SMSC itself for example an SMSC delivery receipt Message ESME g Center Network Connection bind_transceiver bind_transceiver_resp Figure 2 5 Bound_TRX State SMPP V5 0 Draft06 SMS Forum 22 of 127 CA ZC www smsforum net MS FORUM 2 3 5 Unbound An ESME bound as a TX RX or TRX ESME has issued an unbind request to the MC requesting termination of the SMPP session The MC may also issue an unbind request to the ESME The receiving peer will then respond with an unbind_resp PDU acknowledging the request to end the session 2 3 6 Closed The ESME or SMSC has closed the network connection This typically results as a follow on to an Unbound state where one peer has requested termination of the session Closed state can also result from either peer terminating the connection unexpectedly or due to a communications error within the underlying network that results in termination of the network connection 2 3 7 Outbound The purpose of the outbind operation is to allow the SMSC signal an ESME to originate a
106. nteger Gei to a unique sequence number The 4 5 4 associated cancel_sm_resp PDU should echo the same sequence number ervice_type C Octet Bet to indicate SMS Application service 4 5 15 max 6 String if cancellation of a group of application service messages is desired Otherwise set to NULL message_id C Octet Message ID of the message to be 4 5 26 String ancelled This must be the SMSC assigned Message ID of the original message Set to NULL if cancelling a group of messages source_addr_ton Integer ype of Number of message originator 4 5 9 his is used for verification purposes and must match that supplied in the original message submission request PDU If not known set to NULL i mp Integer Numberng Plan Identity of message Originator his is used for verification purposes land must match that supplied in the original message submission request PDU If not known set to NULL ource_addr C Octet Source address of message s to be max 21 String ancelled This is used for verification purposes and must match that supplied in the original message submission request PDU s dest_addr_ton Integer ype of number of destination SME address of the message s to be ancelled his is used for verification purposes land must match that supplied in the original message submission request PDU e g submit_sm May be set to NULL when the message_id is provided SMPP V5 0 Draft06 SMS Forum 84 of 127 V m V ar ar
107. o automatically record customer usage e Security applications such as alarm systems that can use SMS services for remote access and alerting purposes For example a parent receives an SMS from his security company to inform him that his daughter has arrived home and keyed in her access code SMPP V5 0 Draft06 SMS Forum 11 of 127 CO CO www smsforum net SMS FORUM e WAP Proxy Server A WAP Proxy Server acts as the WAP gateway for wireless Internet applications A WAP Proxy Server may select an SMS or USSD bearer for sending WDP datagrams to and receiving WDP datagrams from a mobile station e Online Banking Share Dealing and E Commerce A mobile user could use SMS to send messages to an ESME requesting the purchase of products shares etc Likewise a subscriber may use SMS to access banking services such as bill payment and funds transfer e Gaming and SMS Chat Mobile users can interact with each other by means of a central server ESME and use this interaction as a means of playing wireless games dating or SMS chat services similar to the concept of instant messaging and Internet room These services have already appeared in the form of SMS TV and SMS Radio services 1 2 3 SMPP Sessions In order to make use the SMPP protocol an SMPP session must be established between the ESME and Message Centre or SMPP Routing Entity where appropriate The session is based on an application layer TCP IP or X 25 connection between the ESME and M
108. ocessed o If an Optional Parameter Tag is recognized but not expected for the particular SMPP operation the optional parameter shall be ignored e If the Optional Parameter Tag is unrecognized or unsupported by the receiving SMPP entity that particular Optional Parameter shall be ignored and the next Optional Parameter in the sequence shall be processed e An SMPP entity receiving a parameter value defined as reserved should use the default value if a default setting is defined otherwise the parameter should be ignored e If the Parameter value is otherwise unrecognized or invalid the SMPP entity should return an error indicating the Parameter Value is invalid e An SMPP entity detecting that an Optional Parameter which is required in the context of the operation is not present should return a response message with an Expected Optional Parameter missing error e A Variable length field Parameter may have it s maximum length definition extended in subsequent versions of the SMPP protocol An SMPP entity receiving a variable length Parameter whose length is greater than the maximum length the entity supports for that Parameter should reject the Parameter with an error indicating invalid parameter length SMPP V5 0 Draft06 SMS Forum 38 of 127 CA ZC www smsforum net MS FORUM 2 10 2 Backward Compatibility Backward Compatibility procedures allow a functional entity using one version of the SMPP protocol to communicate with
109. octets of the 4 5 24 short_message user data 1 short_message Var Octet Up to 255 octets of short 4 5 25 0 255 String message user data The exact physical limit for Short message size may vary according to the underlying network Applications which need to Send messages longer than 254 octets should use the message_payload parameter In this case the ism_length field should be set to zero Table 4 28 replace_sm PDU 4 4 2 2 replace_sm_resp Syntax Field Name Size Type Description Ref octets Integer Set to overall length of PDU command_length command_status 4 Integer Indicates outcome of 4 5 3 replace_sm request sequence_number Integer Get to sequence number of 4 5 4 original replace_sm PDU Table 4 29 replace_sm_resp PDU SMPP V5 0 Draft06 SMS Forum 90 of 127 CA ZC www smsforum net MS FORUM 4 5 PDU Field Definitions 4 5 1 command_length This 4 octet integer represents the overall length of a PDU This is described in detail in section 3 2 1 1 4 5 2 command_id The complete set of SMPP Command IDs and their associated values are defined in the following table Command ID Value 0x00000004 S u 0x00000006 u 0x80000006 ri 0x00000007 CG O e bind_transceiver_resp 0x80000009 0x0000000A 0x8000000A 0x0000000C 0x00000014 0x8000000B 0x80000014 0x00000015 enquire_link_resp 0x80000015 Re 0x00000016 0x00000020 0x80000016 0x80000020 submit_multi 0x000000
110. ommand Length value 16 octets Table 3 4 SMPP PDU Format The 16 Octet SMPP Header is a mandatory part of every SMPP PDU and must always be present The SMPP PDU Body is optional and may not be included with every SMPP PDU SMPP V5 0 Draft06 SMS Forum 43 of 127 CO CO www smsforum net SMS FORUM 3 2 1 PDU Format SMPP PDU Field Size Type Description Octets command _length Integer Overall size of PDU including header and body command id id Identifies the PDU sequence_number 4 Integer Used to uniquely identify an SMPP PDU in the context of an SMPP session Standard var mixed The Body part of a PDU differs Parameters from PDU to PDU and in some TLV Parameters cases there is no body at all Table 3 5 SMPP PDU Format The layout of every SMPP PDU consists of a mandatory 16 octets representing the PDU header The above fields are now explained in detail x Lu Q lt w I D Q a gt Q O m 3 2 1 1 Command_length SMPP is a binary protocol and also supports asynchronous transmission This means that an ESME or MC must support the ability to decode a PDU from a network connection buffer that may contain several PDUs and not just one The key to achieving the means of decoding each PDU within a buffer is based on the knowledge of how big each PDU is The command _length represents the first field of a PDU and its value contains the overall size of the PDU An application can easily decode a PDU fro
111. ontains the SMSC 4 5 26 max 65 Strin message ID of the submitted g message It may be used at a later stage to query the status of a message cancel or replace the message Message Submission Var TLV 4 2 5 Response TLVs Table 4 16 data_sm_resp PDU SMPP V5 0 Draft06 SMS Forum 62 of 127 CA ZC www smsforum net MS FORUM 4 2 3 submit_multi Operation The submit_multi operation is an enhanced variation of submit_sm designed to support up to 255 different destinations instead of the default single destination It provides an efficient means of sending the same message to several different subscribers at the same time 4 2 3 1 submit_multi Syntax Field Name Size Type Description Ref octets command_length Integer Set to overall length of PDU ae sequence_number Integer Eet to a Unique sequence 4 5 4 number The associated ubmit_sm_resp PDU will echo this sequence number 4 4 4 4 service_type C Octet The service_type parameter 4 5 15 Var String can be used to indicate the iti SMS Application service ax 6 associated with the message Specifying the service_type allows the ESME to avail of enhanced messaging services such as replace by service pe to control the teleservice used on the air interface Set o NULL for default SMSC settings 1 1 ar command_status source_addr_npi source_addr_ton Integer Type of Number for source 4 5 9 address If not Known set to NULL Unknown Integer
112. or X 25 connection No identification details have yet been exchanged Message Center Network Connection Initiated by ESME Figure 2 2 Open State 2 3 2 Bound_TX A connected ESME has requested to bind as a Transmitter by issuing a bind_transmitter PDU and has received a bind_transmitter_resp PDU from the SMSC authorising its bind request An ESME bound as a transmitter may send short messages to an SMSC for onward delivery to a Mobile Station or to another ESME The ESME may also replace query or cancel a previously submitted short message Message ESME g Center Network Connection bind_transmitter bind_transmitter_resp Figure 2 3 Bound_TX State SMPP V5 0 Draft06 SMS Forum 21 of 127 CO CO www smsforum net SMS FORUM 2 3 3 Bound_RX A connected ESME has requested to bind as a Receiver by issuing a bind_receiver PDU and has received a bind_receiver_resp PDU from the SMSC authorising its Bind request An ESME bound as a receiver may receive short messages from an SMSC which may be originated by a mobile station by another ESME or by the SMSC itself for example an SMSC delivery receipt Center N etwork Connection bind_receiver bind_receiver_resp Figure 2 4 Bound_RX State 2 3 4 Bound_TRX A connected ESME has requested to bind as a Transceiver by issuing a bind_transceiver PDU and has received a bind_transceiver_resp PDU from the SMSC authorising its Bind request An ESME bound as a Tra
113. prises the SMPP message header only The format of the SMPP unbind_resp PDU is defined in the following table Field Name Size Type Description Ref octets command_length 4 Integer Defines the overall length of the PDU 4 Integer Indicates outcome of original unbind 4 5 3 request sequence_number 4 Integer Set to sequence number of original 4 5 4 unbind request Table 4 9 unbind_resp PDU SMPP V5 0 Draft06 SMS Forum 55 of 127 CNA ZC www smsforum net SMS FORUM 4 1 2 Enquire Link Operation This message can be sent by either the ESME or SMSC and is used to provide a confidence check of the communication path between an ESME and an SMSC On receipt of this request the receiving party should respond with an enquire_link_resp thus verifying that the application level connection between the SMSC and the ESME is functioning The ESME may also respond by sending any valid SMPP primitive 4 1 2 1 Enquire_link Syntax Field Name Size Type Description Ref octets command _length 4 Integer Set to overall length of PDU sequence_number 4 Integer Gei to a unique sequence number 4 5 4 The associated enquire_link_resp PDU should echo the same sequence number Table 4 10 enquire_link PDU 4 1 2 2 Enquire_link_resp Syntax The enquire_link_resp PDU is used to reply to an enquire_link request Field Name Size Type Description Ref octets command_length 4 Integer Set to overall length of PDU 4 command
114. pse allowed between an Outbound Request may assume SMPP request and the Bound_TX that Request has not corresponding SMPP Bound_RX been processed and response Bound_TRX should take the This timer may be active on appropriate action for the either communicating particular SMPP SMPP entity i e SMSC or operation in question ESME Table 2 1 SMPP Session Timers 2 7 Error Handling This section addresses typical error scenarios that can occur and how an ESME or MC should go about handling such scenarios 2 7 1 Handling Connection Failure An ESME or MC may experience a failed connection attempt or may suddenly lose its connection to the other peer This can be due to any of the following reasons e The IP address and port or X 25 details are incorrect for failed connection attempts e The remote MC or ESME is down or unable to accept the connection e The network between the two hosts is down The recommended approach is to continually try to connect or reconnect again at intervals Many ESME systems provide crucial services to an SMS network If a network or Message Centre becomes unavailable causing ESMEs to lose their SMPP connections then as long as an ESME enters a mode whereby it attempts to reconnect at intervals of say five seconds then as soon as the network or Message Centre service is restored the ESME will be quickly reconnected to resume service Most SMPP sessions will be ESME initiated but as we have seen from Ou
115. rameter shall be ignored Table 4 71 sar_total_segments TLV SMPP V5 0 Draft06 SMS Forum 116 of 127 CA ZC www smsforum net MS FORUM 4 6 4 24 sar_segment_seqnum The sar_segment_seqnum parameter is used to indicate the sequence number of a particular short message within the concatenated short message ield Size octets Type Description F Parameter Tag 2 Length Integer 0x020F Integer Length of value part in octets Value 1 Integer This octet shall contain a value in the range 1 to 255 indicating the sequence number of a particular message ithin the concatenated short message The value shall tart at 1 and increment by one for every message sent ithin the concatenated short message hen present the PDU must also contain the sar_total_segments and sar_msg_ref_num parameters Otherwise this parameter shall be ignored Table 4 72 sar_segment_seqnum TLV 4 6 4 25 sc_interface_version The sc_interface_version parameter is used to indicate the SMPP version supported by the SMSC It is returned in the bind response PDUs Field Size octets Type Description 0x0210 Length 2 _ Integer Length of value part in octets Value 1 Integer values as per 5 2 4 interface_version Table 4 73 sc_interface_version TLV 4 6 4 26 display_time The display_time parameter is used to associate a display time of the short message on the Field Size octets Type Description Parameter Tag __ Integer 0x1201 2 Integer
116. rnesrresrrssrnssrrnsrrssrrssrnssnne 30 Figure 2 14 Asychronous Wmdowing sisssssssisvsssssisuissensenssnassvun aisis sanide kaisinan ani 31 Figure 2 15 Flow Control amp Congestion Avoidance using the congestion _state TLV 36 Figure 2 16 ESME MC SMPP session using a secure tunnel ccceecceeeeeeeeeeeeeeeeeeeeeeaees 37 Figure 4 1 Registered Delivery c ccccceecccceeeeeceeeeeeeeeeeeeeeaeeeeeaaaeeseeeaeeesseaaeeseeaaaeeseeeaaenees 71 Figure 4 2 Store and Forward Mode 73 Figure 4 3 Datagram Message Mode sessssssssssssirsssrrssrirnsstirnsstinnnntinnntinnnntnnnnntnnnnnnnn nanena 74 Figure 4 4 Transaction MOde cccecesscceesecceeeeeeeeeeeeeeeeeeeeeeneeseeeaeseseesaeeeseeaaeeseeeeneeeeeseneeees 75 SMPP V5 0 Draft06 SMS Forum 9 of 127 CO CP www smsforum net SMS FORUM 1 Introduction The SMS Forum a non profit organisation dedicated to the promotion of SMS within the wireless industry manages the Short Message Peer to Peer SMPP protocol The specification and related documentation is available from the SMS Forum Website http www smsforum net Support for SMPP is available via email at support smsforum net or via online discussion at the SMS Forum website http Avwww smsforum net SMPP is an open industry standard protocol designed to provide a flexible data communications interface for the transfer of short message data between External Short Message Entitys ESME Routing Entities RE and Me
117. rnssrnssrnssrnssrnssrnssrssrene 52 4 1 1 6 bind_transceiver_resp Gvmtax 53 4 1 1 7 ee ele EE UK EE 54 4 1 1 8 unbind SYNTAX EE 55 4 1 1 9 unbind resp SYMAX occ ceecccecceececeeeeeaeeeeneeseeeeecaeeeeaaeseeeeeseaeeesaeeeeeeseeeeeeaas 55 4 1 2 Enquire Link Operation 56 4 1 2 1 ENQuire MAK SVIMAX asasinii saninin a aniisi aiaa 56 4 1 2 2 Enquire_link_resp Syntax 0 cccccccccseceenceceeeeeeeaeeeeeaeseeeeeceaeeeeaeeeeaaeseaneeeaas 56 4 1 3 Generic NACK Operation ceccceeeceeeeeeeeeeeeeeeeceaeeeeeaeseeeeeseeeeesaeeeeaaesseneeee 57 4 1 3 1 generic nack Syntak sissseisisaeshiead t innana aai iiaeaa 57 4 2 Message Submission Operations cccccccccsseceeceeceeeeeceeeeseeeeeeeeeseaeeesaeeeeeeeeaes 58 4 2 1 SUDMIt_SIM OperatiOn 0 ccccceceeceeceeeeeeceeeeaaeeeeneeceaeeeeaaeseeaeeseeeesaeeeeaaeeseneeesaees 58 4 2 1 1 SUDMIl SIM SYIMAX eu shsve csedeed adecesevte eedansteceapinadesdancesdezzealaeedansta dgiten deeds 58 4 2 1 2 SUDMIt_SM_reSp Syntax ceccccceeceeeeceeeeeceeeeeeeaeeeeaeeseeeeesaeeesaeeseaeeeeaees 60 4 2 2 data em Operation eresineiicrrinirisnadiieniinenio iadnn edadia daii tia awia aas 61 4 2 2 1 data RE EE 61 4 2 2 2 data sm resp Syntax ecccceeececeeeeeeneeceeeeeceeeeeeaaeseeaeeeeeeeesaeeseaaeseeneeesaees 62 4 2 3 submit multi Operation 63 4 2 3 1 SUBMIT mutt SYMtaX ssis eirinen iiaiai aiiai 63 4 2 3 2 submit_multi_resp Gwrtax 66 4 2 4 Message Submission Request TIVe 67 4 2 5 Message Submiss
118. rvice_type parameter can be used to indicate the SMS Application service associated with the message Specifying the service_type allows the ESME to e Avail of enhanced messaging services such as replace_if_present by service type generic to all network types e Control the teleservice used on the air interface e g ANSI 136 TDMA IS 95 CDMA SMSCs may implicitly associate a replace if present function from the indicated service_type in a message submission operation i e the SMSC will always replace an existing message pending delivery that has the same originating and destination address as the submitted message For example an SMSC can ensure that a Voice Mail System using a service_type of VMA has at most one outstanding notification per destination MS by automatically invoking the replace if present function The following generic service_types are defined Service Type Description Voice Mail Notification Voice Mail Alerting Wireless Application Protocol USSD Unstructured Supplementary Services Data Table 4 35 service_type Values All other values are carrier specific and are defined by mutual agreement between the SMSC Service Provider and the ESME application SMPP V5 0 Draft06 SMS Forum 97 of 127 CNA ZC www smsforum net SMS FORUM 4 5 16 esm_class The esm_class parameter is used to indicate special message attributes associated with the short message The esm_class parameter is e
119. s TANG TEE 96 45 12 SOUNCE Le EE 97 45438 destination addi lt ccs c cccdsesicesaseeeed Haves E E Nai 97 a I E 0 EEE E E A E E dese ee 97 AOIG SEVICE TYPO rere E a a E AE S E 97 A516 ESM Be EE 98 A517 procol Idoiari e Ea adusiiecanuenc saguads E 99 4518 pioni ag EE 99 4 5 19 scheduled_delivery_time and validity Geo 100 4 5 19 1 scheduled_delivery_time cccccecceceeeeeeeeeeceeceeeeeseeenaeeeeeteeseeenenaeees 100 4 5 19 2 validity penod eencnecuriar diene eitedvnes 100 4 5 19 3 Absolute Time Format rssi annan AAEN 100 4 5 19 4 Relative Time Formal essersi ina A EA 101 4 5 20 registered_delivery cecccceceeceeeeeseeeeeeeeeeeeeeeeeneeseeeneeseeneneeseeneeeeeeneeeeeeenees 102 4 5 21 replace_if_present_flag eccecceceeseeceeeeseeeeeeeeeeeeeeeneneeeeeneeeeeeeseneeeesseeeeeenenaes 103 4 5 22 data Coding EE 104 4 5 23 em deiaubt msg jd 105 A524 SM e EE 105 45 25 shon E e EE 105 Tu Le EL EE 105 4527 per Of deEStS eegend Seege eege eet geen 105 45 28 dest TAG ET 106 45 29 MO le Ee 106 45 30 TN un CN 106 4 5 31 message EE 106 4 6 POU LV Definitions csc c ccctes eke ENEE eari E 107 4 6 1 RBE le D 107 4O22 TUV Ee EE 109 4 6 3 TE Malget eegen tege Ee eg EAR 109 4 6 4 VE deu te EE 109 4 6 4 1 d st addr SUBUNIT cesccccciescts cece de ERR vecsnct aariin riea 109 4 6 4 2 source ACA subunnt ee cccccccccececeeeceeeeeeeeeeseeeeeeeeeeeeeseeeeeeeseeeeeseseees 109 4 6 4 3 dest network Ivpe Nun 11
120. s are small and often easy to remember Operators providing services that allow a subscriber avail of stock quotes lotto results etc will often configure the service to respond to a short digit sequence such as 1234 The subscriber will mobile originate a message addressed to 1234 TON 2 and the message center routing will deliver this to an ESME receiver or transceiver In responding to the message the ESME will usually set the source address to the short code making it easy for the recipient to reply to the message if another request is desired e International Number With more and more subscribers roaming internationally with their mobiles ESME services that they use need to accessible regardless of location One approach to supporting this accessibility is for the ESME to use an international number in the source address of the message TON 1 NPI 1 e NULL Address An ESME Transmitter may enter NULL values in the source address fields In this event the SMSC may then substitute a default address for that particular ESME This feature is designed for interfaces that are not normally familiar with the notion of a source address for a short message e g paging systems voice mail systems which developed long before the advent of SMS technologies and were based on one way paging hence the lack of a source address 4 2 7 Message Replace operation in submit_sm Though SMPP offers a dedicated replace_sm operation the subm
121. saction Message Mode allows the ESME message originator to receive a form of delivery acknowledgment that indicates if the message has been successfully or unsuccessfully delivered to the destination MS within the SMPP response PDU Transaction Message Mode is designed for applications that involve real time messaging where an ESME requires a synchronous end to end delivery outcome without the need for long term SMSC storage SMS ESME Message Center transaction mode One network delivery attempt made Response to ESME delayed until delivery outcome is known transaction mode using data_sm Bound_TX Network Delivery Attempt NACK failure Network Delivery Attempt ACK success SME SMPP V5 0 Draft06 Figure 4 4 Transaction Mode SMS Forum 75 of 127 CO CO www smsforum net SMS FORUM 4 3 Message Delivery Operations 4 3 1 deliver_sm Operation The deliver am is issued by the SMSC to send a message to an ESME Using this command the SMSC may route a short message to the ESME for delivery SMPP V5 0 Draft06 SMS Forum 76 of 127 CA ZC www smsforum net MS FORUM 4 3 1 1 deliver_sm Syntax Field Name Size Type Description Ref octets command _length Integer Set to overall length of PDU Integer 0x00000005 4 5 2 sequence_number Integer Set to a Unique sequence 4 5 4 number The associated deliver_sm_resp PDU will echo t
122. sage delivery attempt Typical uses are to report the outcome of delivery attempts made during the messages retry lifetime within the MC This could be used to track the various reasons why a message is not delivered to its destination and use this profile the subscriber s availability In such cases the following TLVs would be of importance e message_state TLV e network_error_code TLV e receipted_message_id TLV However support for Intermediate Notification functionality is specific to the MC implementation and the MC Service Provider and is beyond the scope of this specification 4 3 4 3 SME Delivery Acknowledgement Despite its name an SME Delivery Acknowledgement is not an indication that the short message has arrived at the SME but rather an indication from the recipient SME that the user has read the short message For an MS based SME an SME Delivery Acknowledgement is sent when the MS user or MS application has read the message from the SMS storage unit e g SIM card For a fixed SME i e ESME the circumstances in which an SME Delivery Acknowledgement may be sent are beyond the scope of this specification 4 3 4 4 SME Manual User Acknowledgement A Manual User Acknowledgement is an application generated reply message sent in response to an application request message For example this message type could contain a selected menu item number from a menu list sent in an application request message 4 3 4 5 Conversation Abort
123. sage delivery attempt only applicable for transaction message mode If a delivery failure due to a network error is indicated the ESME may check the network_error_code parameter if present for the actual network error code ack Size octets Type Description ParameterTag integer 0x0425 at Length ___B__Iinteger Length of value part in octets Value Integer 0 Destination unavailable 1 Destination Address Invalid e g suspended no SMS capability etc 2 Permanent network error Temporary network error alues 4 to are 255 reserved Table 4 81 delivery _failure_reason TLV The delivery_failure_reason parameter is not included if the delivery attempt was successful 4 6 4 34 more_messages_to_send The more_messages_to_send parameter is used by the ESME in the submit_sm and data_sm operations to indicate to the SMSC that there are further messages for the same destination SME The SMSC may use this setting for network resource optimization Field Size octets Type Description 0x0426 Length 2 Integoer Length of value part in octets 0 No more messages to follow 1 More messages to follow default alues 2 to 255 are reserved Table 4 82 more_messages_to_send TLV 4 6 4 35 message_state The message_state optional parameter is used by the SMSC in the deliver_sm and data_sm PDUs to indicate to the ESME the final message state for an SMSC Delivery Receipt Field Size octets Type Description Parameter Tag
124. sion parameter of the bind response PDU If a bind response does not contain the sc_interface_version parameter then the ESME should assume that the SMSC does not support the use of optional parameters e An ESME that implements SMPP V3 4 or a later version of this protocol must not send optional parameters to an SMSC that implements an earlier version of this protocol The ESME shall determine the SMSC version support from the SMPP bind response PDU e An SMSC that implements SMPP V3 4 or later must not generate message IDs greater than 8 octets when communicating with an ESME that supports SMPP V3 3 or earlier SMPP V5 0 Draft06 SMS Forum 39 of 127 CO CO www smsforum net SMS FORUM 3 SMPP Parameter and PDU Format This section defines the various types used to build SMPP PDUs It also describes the layout of a PDU and how it appears when encoded 3 1 Parameter Type Definitions All SMPP PDUs comprise of organised sets of parameters These parameters can have any of the following formats Note Values depicted with a Ox prefix are in Hexidecimal format meaning that each digit represents 4 binary bits In short a 2 digit hex number is actually only 1 octet of data Parameter Type Description Integer An unsigned integer value which can be 1 2 or 4 octets in size The octets are always encoded in Most Significant Byte MSB first order otherwise known as Big Endian Encoding A 1 octet Integer with a value 5 would be encod
125. son Include to indicate reason for delivery4 6 4 33 failure network_error_code Error code specific to a wireless network 4 6 4 8431 Gadon SE ASCII text giving a description of thek Sec meaning of the response dot result Indicates whether the Delivery Pending4 6 4 28 Flag was set Table 4 20 Message Submision Response TLVs 4 2 6 Source and Destination Addressing The submit_sm and data_sm PDUs include provision for both source address message sender and destination address message recipient The common concept of a source or destination address is a sequence of digits representing a mobile or fixed line number However the reality is more complex Both addresses comprise of three parts namely the TON Type of Number NPI Numbering Plan Indicator and Address Digit sequence Every time a message is sent either to or from a mobile the source and destination addresses comprise of the three parts This three part relationship is visible in the PDUs in the form of source_addr_ton source_addr_npi source_addr dest_addr_ton dest adr opt and destination_adar fields 4 2 6 1 TON TON is used to specify the number type While there are several values defined for TON the most common values are e National A national number consists of a mobile or fixed line operators prefix followed by the mobile number itself When a mobile originates a message to a national number the TON value of the address is usually set to
126. ssage Centers A Message Center MC is a generic term used to describe systems such as a Short Message Service Centre SMSC GSM Unstructured Supplementary Services Data USSD Server and Cell Broadcast Centre CBC An ESME typically represents a fixed network SMS client such as a WAP Proxy Server E Mail Gateway and Voice Mail Server A Routing Entity RE is a generic term for a network element that is utilized for MC to MC and ESME to MC message routing A RE has the ability to emulate the functionality associated with both a MC and an ESME To an ESME a RE appears as a MC and to a MC an RE appears as an ESME A carrier may utilise REs to hide a network of Message Centres presenting only the REs as the external interface point for ESMEs CL1 The following diagram illustrates the context of SMPP in a mobile network me f mm QQ TCP IP e TCP IP paws ESME or X 25 ee or X 25 ee Hoi Networks ii Networks entres Drinks Fi Wu A N D Wl a es K gt Mobile a Dy Bi E far S a Commerce Te e z GC A Mobile 5 P P SMPP Ss gt Mobile Banking g e Network Va N gt E Mail Gateway 1 m E Si RE i eene ls gt Information SMSC A 1 SMPP
127. ssage_payload parameter is being used to send user data larger than 254 octets sm_length Value Meaning no user data in short message field 255 not allowed Table 4 44 sm_length Values 4 5 25 short_message The short_message parameter contains the user data A maximum of 254 octets can be sent ESME s should use the optional message_payload parameter in submit_sm submit_multi and deliver_smto send larger user data sizes 4 5 26 message_id The unique message identifier reference assigned by the SMSC to each submitted short message It is an opaque value and is set according to SMSC implementation It is returned by the SMSC in the submit_sm_resp submit_multi_resp deliver_sm_resp and data_sm_resp PDUs and may be used by the ESME in subsequent SMPP operations relating to the short message e g the ESME can use the query_sm operation to query a previously submitted message using the SMSC message_id as the message handle 4 5 27 number_of_dests The number_of_dests parameter indicates the number of dest_address structures that are to follow in the submit_multi operation A maximum of 254 destination address structures are allowed SMPP V5 0 Draft06 SMS Forum 105 of 127 CNA ZC www smsforum net SMS FORUM 4 5 28 dest_flag Flag which will identify whether destination address is a Distribution List DL name or SME address dest_flag Value Meaning Distribution List Name Table 4 45 dest_flag Values 4 5 29 no_
128. string is encoded as 0x00 A NULL Octet String is not encoded The explicit length field that indicates its length should be set to NULL There are two types of NULL encoding for a TLV The first is a TLV that may not carry a value part An example of such a TLV is alert_on_message_delivery This TLV is typically used as in indicator only i e its function is driven by its very presence in the PDU No data is typically present However it can carry up to XXX octets of data if required CL13 Here are two examples of how this TLV can be encoded the first example caries a value the second example does not Tag 0x130C Length 0x0002 Value 0x0102 Encoded Format 0x130C00020102 Tag 0x130C Length 0x0000 Value NULL Encoded Format 0x130C0000 Note Only the Tag and Length are encoded No NULL octets are specified for the zero length Value field If the TLV itself is not required then it is not encoded at all The very absence of the TLV from the PDU is the means by which we set the values to NULL Note Encoding C Octet strings in TLVs carries a certain exception case Where a TLV specifies only a C Octet string in the value part or specifies a format where the last encoded part is a C Octet String then it is perfectly acceptable to exclude the NULL octet and leave the TLV dimensioning terminate the data flow CL14 Table 3 2 SMPP PDU Parameter Type NULL Settings SMPP V5 0 Draft06 SMS Forum 42 of 127 CA ZC www
129. support for parity CRC checking or any other form of corruption detection This is all automatically handled by the application layer functionality of TCP IP or X 25 The only assumption made by an SMPP based application ESME or MC is that the remote peer conforms to the protocol and that a PDU sent from one peer to another is fully recignisable as an SMPP PDU Message Center Application Application Physical Physical Netw ork Cable Serial Link Wireless Interface Figure 2 1 Application Layer Communication Between ESME and MC SMPP V5 0 Draft06 SMS Forum 20 of 127 CA ZC www smsforum net MS FORUM 2 2 Establishing an SMPP Session Establishing a Session first requires the ESME to connect to the MC This is achieved using a TCP IP or X 25 connection The MC will typically be listening for connections one one or more TCP IP ports or X 25 interfaces X 25 programmatic interfaces DTE addresses and X 25 protocol Ids For TCP IP IANA has standardised port 2775 for SMPP However this will vary across MC vendors and operators 2 3 Session States As already described an ESME begins a session by connecting to the MC across TCP IP or X 25 This connection is referred to as an SMPP session and can have several states 2 3 1 Open An ESME has established a network connection to the SMSC but has not yet issued a Bind request The MC is only aware of the TCP IP
130. t issued by the ESME was the submit_sm PDU and it carried a sequence number of 2 The third and forth request PDUs to be sent by the ESME further incremented this value to 3 and 4 respectively SMPP V5 0 Draft06 SMS Forum 28 of 127 CA ZC www smsforum net MS FORUM At the same time all deliver_sm requests issued by the MC use monotonic increasing numbers These can very easily match those issued by the ESME But the confusion is avoided by the context of a PDU Basically every request must emanate from either the ESME or MC and the resulting response must emanate from the other party So in effect each SMPP session involves two sets of sequence numbers the set used by the ESME for ESME originated requests and the set used by the MC for MC originated requests They can cross over each other in value but will or should not be confused with each other 2 5 2 Why Monotonic While the recommendation is that sequence numbers should be monotonically increased this is not a mandatory requirement and some ESMEs or MCs may deliberately select random numbers or value based on some predetermined sequence Either way the responding party is expected to honour these values and use the same sequence number in the response PDU Monotonic increasing sequence numbers are easy to implement and handle and also have the additional characteristic of providing a running operation count for the session If the next sequence number to be used by an ESME is 100
131. taneously he sm_length field should be set to zero if using the message_payload parameter Note In the case of data_sm the message_payload TLV is the only means of specifying text eet dot Indicator for setting Delivery Pending Flag on delivery DA ailure privacy indicator Jdcaies the level of privacy associated with the message 4 6 4 14 callback_num A callback number associated with the short message DA his parameter can be included a number of times for multiple callback addresses D ol D IW DA o N O E D P CO O SMPP V5 0 Draft06 SMS Forum 67 of 127 CNA ZC www smsforum net SMS FORUM Description callback_num_pres_ind Defines the callback number presentation and screening If this parameter is present and there are multiple instances of the callback_num parameter then this parameter must occur an equal number of instances and he order of occurrence determines the particular callback_num_pres_ind which corresponds to a particular callback_num callback_num_atag Associates a displayable alphanumeric tag with the allback number If this parameter is present and there are multiple instances of the callback_num parameter then this parameter must occur an equal number of instances and he order of occurrence determines the particular callback_num_atag which corresponds to a particular callback_num he sub address of the message originator dest_subaddress he sub address of the message destination
132. tbind the MC can itself be in a position to connect to an ESME that is configured for Outbind The likely reason for attempting an Outbind is that messages for the ESME have arrived in the MC If the connection attempt fails it is recommend that the MC use a similar mechanism of periodically attempting to Outbind to the ESME This may be driven by a retry sequence that controls the frequency of delivery attempts made for a given message Every time the ESMEs message is scheduled for retry the MC attempts to Outbind to the ESME SMPP V5 0 Draft06 SMS Forum 33 of 127 CO CO www smsforum net SMS FORUM 2 7 2 Operation Failure There are a number of reasons why a MC or ESME may reject an operation request PDU These are The PDU is unrecognised this is one of the most common reasons for rejecting a PDU It can result from an ESME or MC sending a PDU that the receiving peer does not recognise The typical response in this scenario is a generic_nack PDU being returned to the sender with the sequence number of the offending PDU The command status is usually ESME_RINVCMDID which indicates that the ESME or MC cannot recognise the PDU In this situation the error is with the receiving peer and is effectively a non compliance scenario However some ESMEs and MCs will not support all operations and will usually provide this information in their SMPP PICS document The PDU is malformed when this happens it indicates that the sending entity is at
133. teger Length of Value part in octets Integer 0 Digit 1 Number Telephone No 3 Password 4 Character Line 5 Menu 6 Date 7 Ti alues 9 to 255 are reserved Table 4 90 jts_reply_type TLV SMPP V5 0 Draft06 SMS Forum 124 of 127 CA ZC www smsforum net MS FORUM 4 6 4 43 its_session_info The its_session_info parameter is a required parameter for the CDMA Interactive Teleservice as defined by the Korean PCS carriers KORITS It contains control information for the interactive session between an MS and an ESME ak Size octets Type Description ParameterTag integer 0x1383 at Length R nteger Length of Value part in octets Value Octet String SSSSSSSS octet 1 NNNNNNNE octet 2 Octet 1 contains the session number 0 255 encoded in binary The session number remains constant for each session The sequence number of the dialogue unit as assigned by the ESME within the session is encoded in bits 7 1 of octet 2 The End of Session Indicator indicates the message is the end of the conversation session and is encoded in bit 0 of octet 2 as follows 0 End of Session Indicator inactive 1 End of Session Indicator active Table 4 91 its_session_info TLV 4 6 4 44 ussd_service_op The ussd_service_op parameter is required to define the USSD service operation when SMPP is being used as an interface to a GSM USSD system Field Size octets Type Description Integer 0 PSSD indication 1 P
134. ter is used to indicate the number of messages stored in a mailbox Field Size octets Type Description Parameter Tag2 Integer 0x0304 Length PB iteger Length of Value part in octets Value 1 Integer 0 to 99 allowed values values 100 to 255 are reserved Table 4 87 number_of_messages TLV 4 6 4 40 sms_ signal The sms_signal parameter is used to provide a TDMA MS with alert tone information associated with the received short message Field Size octets Type Description Parameter Tag _ Integer 0x1203 Length P Integer Length of Value part in octets Value RB Integer Encoded as per CMT 136 Table 4 88 sms_signal TLV 4 6 4 41 alert_on_message_delivery The alert_on_message_delivery parameter is set to instruct a MS to alert the user in a MS implementation specific manner when the short message arrives at the MS Field Size octets Type Description Parameter Tag _ Integer 0x130C Length R Integer Length of Value part in octets 0 Value D ____ There is no Value part associated with this parameter Table 4 89 alert_on_message_delivery TLV 4 6 4 42 its_reply_type The its_reply_type parameter is a required parameter for the CDMA Interactive Teleservice as defined by the Korean PCS carriers KORITS It indicates and controls the MS user s reply method to an SMS delivery message received from the ESME Field Size octets Type Description Parameter Tag integer 0x1380_ Length E In
135. the request and set for the response For example replace_sm has a command_id 0x00000007 and is response PDU replace_sm_resp has a command_id 0x80000007 SMPP V5 0 Draft06 SMS Forum 44 of 127 CA ZC www smsforum net MS FORUM 3 2 1 3 Command_status The command_status represents the means by which an ESME or MC sends an error code to its peer This field is only relevant in response PDUs There is no sense in issuing a request to submit a message and at the same time include an error code with the request So every PDU request always has this field set to NULL 0x00000000 Note When a response PDU carries a non NULL command_status field it is indicating some form of error or rejection of the original request PDU In such circumstances a PDU body should not be included in the PDU and the command_length of the PDU should therefore be set to 16 0x00000010 However some ESMEs or Message Centers may always include a PDU body regardless of the command_status being returned In such circumstances the receiving ESME or MC should decode the PDU body but ignore its contents based on the knowledge that the original request failed 3 2 1 4 Sequence_number Sequence_number as already described in section 2 5 represents a means of uniquely identifying each PDU within an SMPP session It also provides a means of correlating request and response PDUs based on matching sequence number 3 2 1 5 Standard Parameters Standard Parameters consist
136. this 4 5 19 2 String message Set to NULL to request the SMSC default validity period registered_delivery 1 Indicator to signify if an 4 5 20 SMSC delivery receipt or an SME acknowledgement is required 1 Flag indicating if submitted 4 5 21 message should replace an existing message data_coding 1 Defines the encoding 4 5 22 scheme of the short message user data replace_if_present_flag sm_default_msg_id Indicates the short 4 5 23 message to send from a list of pre defined canned short messages stored on the SMSC If not using an SMSC canned message set to NULL Integer Length in octets of the 4 5 24 Short message user data sm_length SMPP V5 0 Draft06 SMS Forum 59 of 127 CNA ZC www smsforum net SMS FORUM Field Name Size Type Description octets short_message Var Octet Up to 255 octets of short 0 255 String message user data The exact physical limit for short_message size may vary according to the underlying network Applications which need to send messages longer than 254 octets should use the message_payload parameter In this case the sm_length field should be set to zero Message Submission Var TLV 4 2 4 TLVs Table 4 13 submit_sm PDU 4 2 1 2 submit_sm_resp Syntax Field Name Size Type Description Ref octets command _length pmr pe to overall length of PDU command id id 4 Integer 0x80000004 4 45 2 2 EE Status E ee outcome of Ee 5 3 submit_s
137. tion If the submit_sm PDU is used to replace an as yet undelivered message in the SMSC and a matching message is not found in the SMSC a new short message will be submitted to the SMSC If a matching message is not found when using the replace_sm operation the replace_sm operation will not result in a new message being submitted to the SMSC an SMPP error will be returned to the ESME in the replace_sm_resp PDU 4 2 8 Message Length SMPP V5 0 Draft06 SMS Forum 70 of 127 CA ZC www smsforum net MS FORUM Each network variation is limited to some fixed maximum length This may be further affected by data coding scheme In the case of GSM a message can have a maximum length of 140 octets 8 bits each However if the message is being sent using the standard GSM 7 bit alphabet or one of the supported 7 bit alphabets 160 characters can be encoded The ANSI 41 technologies CDMA and TDMA are more complicated in defining limits on the text length Both technologies encode the text in a generic bearer data field that is also used to populate other optional fields The restriction on text is based on the amount of optional attributes included with the message The SMSC depending on configuration may also reject or truncate messages that exceed the network allowed maximum 4 2 9 Message Types 4 2 9 1 Registered The registered_delivery field ref 4 5 20 allows an ESME request a delivery receipt for the message Under normal circ
138. tring scheduled by the SMSC for delivery Set to NULL for immediate message delivery validity_period 1or17 C Octet The validity period of this 4 5 19 2 String message Set to NULL to request the SMSC default validity period registered_delivery 1 Integer Indicator to signify if an SMSC 4 5 20 delivery receipt or an SME acknowledgement is required SMPP V5 0 Draft06 SMS Forum 64 of 127 priority_flag schedule_delivery_time CA ZC www smsforum net MS FORUM replace_if_present_flag 1 4 5 21 message should replace an existing message data_coding Integer Defines the encoding scheme 4 5 22 sm_default_msg_id 1 Integer jlIndicates the short message to 4 5 23 end from a list of pre defined canned short messages Stored on the SMSC If not using an SMSC canned message set to NULL sm_length Integer Length in octets of the 4 5 24 Short message user data short_message Var Octet Up to 255 octets of short 4 5 25 0 255 String message user data he exact physical limit for hort_message size may vary according to the underlying network Applications which need to send messages longer than 54 octets should use the message_payload parameter In this case the sm_length field hould be set to zero Message Submission Var TLV 4 2 4 TLVs Table 4 17 submit_multi PDU SMPP V5 0 Draft06 SMS Forum 65 of 127 CNA ZC www smsforum net SMS FORUM 4 2 3 2 submit_multi_resp Syntax Field Name Size Type
139. umstances a receipt is typically sent to the ESME when the message reached a final delivery state regardless of whether the message was actually delivered or not However the registered_delivery field provides a number of settings that dictate the requirements for generating the receipt One such example is the value of 2 which requests a receipt only if the message is not delivered when it reaches its final state The following diagram illustrates the use of registered delivery as a means of obtaining a delivery confirmation Message Center ESME Bound_TX Bound_RX SME submit_sm submit_sm _resp Network Delivery Attempt lt a NACK failure Network Delivery Attempt gt ACK success deliver_sm receipt deliver_sm_resp Figure 4 1 Registered Delivery 4 2 9 2 Scheduled A scheduled message is one that is not immediately dispatched for delivery to the destination SME Instead the scheduled date provided with the message ref 4 5 19 1 dictates the time that the message will become eligible for delivery Typical uses of this feature include timed services such as news reports that a user wishes to receive at a certain time The newsagent SMPP V5 0 Draft06 SMS Forum 71 of 127 CO CO www smsforum net MS FORUM ESME may submit batches of messages every few hours each message scheduled according to the preferences of the recipient Another use of schedul
140. unsuccess The number of unsuccessful SME destinations to which delivery was attempted for a submit_multi operation 4 5 30 dl_ name The reference name for a distribution list provisioned on the SMSC Distribution list names are defined by mutual agreement between the SMSC and the ESME 4 5 31 message_state The following is a list of allowable states for a short message The message_state value is returned by the SMSC to the ESME as part of the query_sm_resp PDU Message State Value Description ENROUTE UNDELIVERABLE 5 Message is undeliverable ACCEPTED Message is in accepted state i e has been manually read on behalf of the subscriber by customer service UNKNOWN 7 Message is in invalid state REJECTED 8 Message is in a rejected state Table 4 46 message_state Values SMPP V5 0 Draft06 SMS Forum 106 of 127 CA ZC www smsforum net MS FORUM 4 6 PDU TLV Definitions TLV fields may be optionally included in an SMPP message TLVs must always appear at the end of an SMPP PDU However they may be included in any convenient order and need not be encoded in the order presented in this document For a particular SMPP PDU the ESME or SMSC may include some all or none of the defined optional parameters as required for the particular application context For example a paging system may in an SMPP submit_sm operation include only the callback number related optional parameters 4 6 1 TLV Tag The SMPP protocol de
141. ying the Service Jupe allows the ESME to avail of enhanced messaging services such as replace by service type to control the teleservice used on the air interface Set to NULL for default SMSC settings source_addr_ton 1 Integer Type of Number for source 4 5 9 address If not known set to NULL Unknown source_addr_npi 1 Integer Numbering Plan Indicator 4 5 10 for source address If not known set to NULL Unknown source_addr Var C Octet Address of SME which 4 5 12 max 21 String _joriginated this message If not known set to NULL Unknown 1 dest_addr_ton Integer Type of Number for 4 5 9 destination dest_addr_npi 1 Integer jNumbering Plan Indicator 4 5 10 for destination SMPP V5 0 Draft06 SMS Forum 58 of 127 CA ZC www smsforum net MS FORUM Field Name Size Type Description octets destination_addr Var C Octet Destination address of this 4 5 13 max 21 String Short message For mobile terminated messages this is the directory number of the recipient MS esm_class 1 Integer Indicates Message Mode 4 5 16 and Message Type protocol_id 1 Integer Protocol Identifier 4 5 17 Network specific field priority_flag 1 Integer Designates the priority level 4 5 18 of the message schedule_delivery_time 1or17 C Octet The short message is tobe 4 5 19 1 String scheduled by the SMSC for delivery Set to NULL for immediate message delivery validity_period 1or17 C Octet The validity period of
142. ype The dest_network_type parameter is used to indicate a network type associated with the destination address of a message In the case that the receiving system e g SMSC does not support the indicated network type it may treat this a failure and return a response PDU reporting a failure ield Size octets Type Description Integer 0x0006 ength of Value part in octets nte F Parameter Tag Value 1 Integer 0x00 Unknown 0x01 GSM 0x02 ANSI 136 TDMA 0x03 IS 95 CDMA 0x04 PDC 0x05 PHS 0x06 iDEN 0x07 AMPS 0x08 Paging Network 9 to 255 reserved Table 4 51 dest_network_type TLV 4 6 4 4 source_network_type The source_network_type parameter is used to indicate the network type associated with the device that originated the message Field Size octets Type Description Length 2 _ Integer Length of Value part in octets Value sft Integer see 5 3 2 3 Table 4 52 source_network_type TLV 4 6 4 5 dest_bearer_type The dest_bearer_type parameter is used to request the desired bearer for delivery of the message to the destination address In the case that the receiving system e g SMSC does not support the indicated bearer type it may treat this a failure and return a response PDU reporting a failure Field Size octets Type Description Integer 0x00 Unknown 0x01 SMS 0x02 Circuit Switched Data CSD 0x03 Packet Data 0x04 USSD 0x05 CDPD 0x06 DataTAC 0x07 FLEX ReFLEX 0x08 Cell

Download Pdf Manuals

Related Search

Related Contents

Sony CP-ELS Marketing Specifications  User Manual  Kohler K-16111 User's Manual  HP K20 User's Manual  Samsung SP-M220 用户手册  IT Manuale utente  AMX MXT-2001-PAN  none TV90CH520S00 Instructions / Assembly  the product installation manual  Netwwork Digital Signage Play User`s Manual - I  

Copyright © All rights reserved. Failed to retrieve file