What’s here?

On this page you’ll learn how to send and receive Short Message Service (SMS) packets using External Short Message Entity (ESME) client connections.

Introduction

This page describes the implementation requirements for ESME client connections to Aeris’s Short Message Peer-to-Peer (SMPP) protocol servers to transceive SMS packets.

This page should be read with the Short Message Peer-to-Peer Protocol Specification v3.4, available from the SMS Forum at http://www.smsforum.net.

These requirements apply when an Aeris Customer (“Customer”) uses the SMPP protocol and Aeris SMPP servers (“SMPP servers”) to access the Aeris SMSDirect™ Network Ser­vice for CDMA Devices, or uses it to access standard SMS service for GSM Devices. All ESMEs are required to pass certification prior to connecting to the production SMPP servers. This ensures that the ESMEs implementation of the SMPP protocol meets the Aeris requirements.

Terminology and Release

Terminology

Term or AcronymDefinition
MO-SMSMobile-Originated SMS
MT-SMSMobile-Terminated SMS
NPINumbering Plan Indicator
RxReceiver
TLVType Length Value
TONType of Number
TxTransmitter
XcvrTransceiver
Table 1: SMPP Terminology

External Short Message Entity (“ESME”)

For this demonstration, an ESME is an SMPP client program.

In the SMPP specification, an ESME is a general term describing the external entity (corporation, program, client, etc.) that transmits and receives SMS messages to Devices, via SMPP servers. In this section, however, the term ESME represents your software client that uses the messages defined in the SMPP specification to connect and communicate with the SMPP servers over a TCP/IP link.

SMPP Release

Aeris uses message formats from SMPP Release v3.4. The ESME must accept the message responses in the SMPP Release v3.4 formats.

The Aeris SMPP servers support key elements of SMPP as defined in Short Message Peer-to-Peer Protocol Specification v3.4. Therefore, your ESME implementations must adhere to the requirements of SMPP Release v3.4.

The SMPP Release v3.4 specification must be read in conjunction with this Aeris document.

This section (i.e. the ESME SMPP Connections To Aeris Specification) does not repeat the information that is covered in Short Message Peer-to-Peer Protocol Specification v3.4. Therefore, if you develop ESME clients you must understand the concepts, details and information that are covered in the SMPP protocol specification, as well as this page.

Requirements topics

Supported SMPP Messages

Supported SMPP Messages lists the specific SMPP messages supported by the SMPP servers and the messages to which the ESME is required to respond. The associated response messages are also supported by the SMPP servers.
MessageReleaseMandatory or Optional
Enquire_Linkv3.4Mandatory
Generic_Nackv3.4Mandatory
Unbindv3.4Mandatory
Bind_Transmitterv3.4Optional
Bind_Receiverv3.4Optional
Bind_Transceiverv3.4Optional
Deliver_SMv3.4Optional
Submit_SMv3.4Optional
Table 2: Supported SMPP Messages

Detailed information on each message listed in Table 2 is provided in Short Message Peer-to-Peer Protocol Specification v3.4.

The Bind_Transceiver is the strongly-preferred bind method, although using Bind_Receiver and Bind_Transmitter (as a pair) is supported.

Using Bind_Transceiver is much more efficient than using separate Bind_Receiver and Bind_Transceiver binds because it only requires a single open connection and a single Unbind on termination.

Network Connections

Connection Methods

ESMEs connect to the SMPP servers via TCP/IP on a Virtual Private Network (VPN) connection.

IP Connections

Bind to SMSC IP 10.84.202.71 over port 9525

Number of SMPP Binds

Normally, only single binds are expected. Multiple binds may be allowed by prior agreement using either unique system_IDs, or multiple instances of the same system_ID.

With prior agreement, the SMPP servers allow up to 5 binds per customer.

Because the number of binds per customer is limited, using Bind_Transceiver is a better option than separate binds using Bind_Receiver and Bind_Transceiver.

Asynchronous Mode Required

All ESMEs must use asynchronous mode for Tx, Rx and Xcvr connections.

Socket Buffer Size

The size of the socket receive buffers in the ESME particularly the Rx and the Xcvr must be large enough to properly handle high volume applications without an overflow.

Aeris strongly recommends using a 64 kByte, or larger, socket buffer size to ensure that high message rates do not cause errors.

Unrecognized Messages

Once the bind is established, the typical messages sent from the SMPP servers are Deliver_SM, Submit_SM_Resp, Enquire_Link, Enquire_Link_Resp, Unbind and Unbind_Resp.

If the ESME receives a message that cannot be deciphered, it can return a Generic_Nack.

It is never allowed for the ESME to Unbind on receiving an unrecognized message.

Optional Parameters

In some messages, the SMPP server may include optional parameters in TLV format, as allowed in Short Message Peer-to-Peer Protocol Specification v3.4, see sections 3.2.4 and 5.3.

The ESME must accept and decode all optional parameters, including those reserved for SMSC Vendor specific optional parameters.

For more information on SMSC Vendor specific optional parameters, see Short Message Peer-to-Peer Protocol Specification v3.4, section 5.3.1.

Binding and Monitoring

Bind Credentials

At initial connection setup, Aeris provides you a system_ID and password for use with the SMPP servers.

Address_range

The address_range field in the various Bind_* messages (i.e., Bind_Receiver, Bind_Transmitter and Bind_transceiver) must be null.

Establishing An ESME To SMPP Connection

A connection must have been established and an authenticated bind request must be successfully acknowledged, before messages can be exchanged.

Connection Management

You are responsible to ensure that your ESME binds are connected at all times. It is not allowed for ESMEs to bind in only when they have MT-SMS traffic to send.

Aeris does not alarm on loss of binds.

Excessive Bind_*/Unbind messages per day is not allowed. The ESME is required to implement sound bind management methods, typically by using IP session monitoring and the Enquire_Link.

More than 10 Bind_*/Unbind messages per day is flagged for corrective action.

Heartbeats

The Enquire_Link and Enquire_Link_Resp are used to maintain confidence in the con­nections. Connections that do not respond to an Enquire_Link must be deemed unreli­able and dropped. The ESME must immediately respond to an Enquire_Link from the SMPP servers, with an Enquire_Link_Resp.

The SMPP servers use inactivity timers; when there is no activity for two to ten minutes on the connection, the SMPP servers send an Enquire_Link to the ESME. Other message traffic serve as a substitute for inactivity timers any valid message received by the SMPP servers resets the timers.

If the ESME does not respond to an Enquire_Link (with an Enquire_Link_Resp) within 15 seconds, the SMPP servers drop the connection.

The ESME must also use Enquire_Link to actively manage their connections. The SMPP servers respond with the Enquire_Link_Resp to any received Enquire_Link.

If the SMPP servers do not respond with the Enquire_Link_Resp within 15 seconds, the ESME must assume the connection is unreliable. The ESME must send an Unbind before dropping the connection, and may then proceed with establishing a new session and another establishing a new bind.

Terminating ESME To SMPP Connection

When an ESME needs to terminate communications with the SMPP servers, it must issue an Unbind (and, if possible, wait for an Unbind_Resp) prior to dropping the IP session.

If the socket connection is dropped too soon after transmitting the Unbind, it is possible that the IP stack may not deliver the Unbind to the SMPP servers.

Sending the Unbind notifies the SMPP servers that a shutdown has been requested, and enables the SMPP servers to terminate communications in an orderly fashion. Otherwise, the SMPP servers may take up to 90 seconds to determine that the bind is gone attempts to rebind during this time may result in the ESME already bound error (0x05).

The ESME must respond to an Unbind with an Unbind_Resp.

If the connection is up, the ESME must attempt to send an Unbind_Resp upon receiving an Unbind the SMPP servers attempt the same and note the attempt into log files. Although the response may not be sent by the stack or received remotely depending on the state of the connection, the presence (of the receipt of the Unbind and the response attempt) in log files is informative during debugging.

Acceptable Reasons For Terminating Connections

The SMPP connections must be maintained at all times.

Allowed Reasons for Terminating a Connection:

The ESME is taken down for maintenance and updates.

The ESME determines the bind is lost.

The ESME does not get a response to Enquire_Link within 15 seconds.

Disallowed Reasons for Terminating a Connection:

Time out on a Submit_SM_Resp.

Receiving a Generic_Nack from the SMPP servers.

Receiving any type of error code in a Submit_SM_Resp.

Use of a modem-style timer on transmitter binds (e.g. "disconnect after 5 minutes if no more MT-SMS to send").

Bind Attempt Failures

The ESME must wait for 60 seconds for the response to a bind request. If a response is not received from the SMPP servers in that time, then the ESME must drop the connection and establish a new connection before retransmitting the bind request.

When an SMPP error is returned (see Table 4, "Aeris SMPP Status Codes" ), the ESME must only retry for temporary errors.

If the ESME does retry, it must not retry more often than once per minute.

No retry is strongly preferred, even for temporary bind errors however, the ESME must notify the Customer personnel to take corrective actions.

If the ESME receives a permanent bind error, it must set an alarm, and the Customer's operations staff must contact Aeris Customer Support to resolve the bind credential issue. Retries do not resolve permanent bind error issues and the ESME must not retry a bind upon such errors the Customer must contact Aeris Customer Support for assistance.

Unbind

The ESME must send an Unbind whenever the bind is taken down.

The SMPP servers sends an Unbind to the ESME when the servers are taken out of service, but this may not be successfully delivered depending on the connection state.

The ESME must attempt to rebind no more often than once every minute.

ESME Prohibited

Aeris Customer Support personnel may place ESME binds into the Prohibit mode. If the ESME is bound, placing the bind in Prohibit mode causes the bind and the TCP/IP session to be dropped. Reasons for putting ESMEs into prohibit mode may be business related, in which case Aeris attempts to contact the Customer ahead of this action to resolve the issues.

Aeris Customer Support personnel may also put ESME binds into Prohibit mode tempo­rarily during maintenance or emergency activity.

The ESME is advised to attempt to rebind for 15 minutes before setting an alarm and con­tacting Aeris Customer Support.

Mobile-Terminated Messages topics

Sequence_number

The sequence_number in the message header must be generated by the ESME, and must never be zero (i.e., null). This signed long integer number (between 1 and the maximum length of a signed long integer) must be monotonically incremented with each new request (as recommended by Short Message Peer-to-Peer Protocol Specification v3.4). The sequence number is used by the SMPP servers in the response corresponding to the request.

Service_type

Unless instructed otherwise by Aeris Customer Support personnel, service_type in Submit_SM must be null.

Source_addr_ton

The source_addr_ton of any message is required to be 0 (representing "Unknown").

Source_addr_npi

The source_addr_npi of any message is required to be 1 (representing "E-164").

Source_addr

The source_addr must be set to null. The SMPP uses the connection and Device identifi­cation information to determine whether to deliver the SMS to the Device.

Dest_addr_ton

The dest_addr_ton of all Submit_SM messages is required to be either 1 (representing "International") or 2 (representing "National").

Dest_addr_npi

The dest_addr_npi of all Submit_SM messages is required to be set to 1 (representing "E-164").

Destination_addr

The destination_addr is the MDN or MSISDN of the Device.

Protocol_id

The protocol_id must be set to 0x00.

Validity_period

A null value in the validity_period field results in a 72-hour message life for GSM Devices and 5 minutes for CDMA Devices larger values are reduced to those limits.

If the validity_period is used, then it must be a relative time period.

Absolute time for this field is not supported, as the target Device and Aeris may operate in different time zones.

Delivery Receipts

The request for a Delivery Receipt is specified in registered_delivery. When the value is 0, a Delivery Receipt is not requested; when the value is 1, a Delivery Receipt is requested. The Delivery Receipt is returned to the ESME in a Deliver_SM once the message is deliv­ered, expired, or rejected; since Aeris attempts to deliver messages for up to 72 hours for GSM Devices, it may be three days before the Delivery Receipt is returned. The value of esm_class in the Deliver_SM determines whether it is a MO-SMS or a Delivery Receipt (see Short Message Peer-to-Peer Protocol Specification v3.4, section 5.2.12 for more information).

The receipted_message_id is sent in the Delivery Receipt it is set to the value previously returned in Submit_SM_Resp (to a Submit_SM request from the ESME).

Data_coding

The data_coding must be set to 0x00. Aeris SMSC uses 8-bit encoding by default. ESME can set data coding flag in the SMPP PDU if required. Please refer to the table below:
Data Coding FlagData Coding Requested by ESMEData coding implemented by SMSC
0x00SMSC Default Alphabet8-bit
0x01IA5/ASCII7-bit
0x02Octet Unspecified8-bit
0x04Octet Unspecified8-bit
0x08UCS216-bit
Anything elseAnything else8-bit
Table 3: Data Coding

Replace_if_present_flag

The replace_if_present_flag must be set to 0x00.

SMS Length

The maximum length for the SMS is one hundred and sixty 7-bit characters, or one hun­dred and forty 8-bit characters. If the length of the SMS is 0, then it is assumed to be a wake up request (also called a "shoulder-tap") for the Device. Upon receiving a shoulder-tap, the actions taken by the Device are Application-dependent.

Submit_SM_Resp Wait Time

The SMPP servers respond to each Submit_SM with a Submit_SM_Resp within a maxi­mum of 2 minutes. Thus, although this response time is typically less than one second, the latency to check status may be up to 2 minutes (120 seconds). If the response is not received in 130 seconds, the ESME must queue the message and retry after 30-60 seconds. A maximum of 3 attempts is recommended.

It is never allowed for an ESME to Unbind on a time-out of an MT-SMS response.

Mobile Terminated Message Throttling

The SMPP server throttles messages via a "maximum number of in-process" mobile-terminated messages sent to the Customer's Devices. Each ESME is setup with a maximum message rate limit that is based on the Customers forecast message volume. The ESME must pace itself and control the transmission to send messages at a rate below the limit. The Customer can contact Aeris Customer Support and request that the limit be increased if traffic increases, or is forecasted to increase. The rate limit applies across all of the Customer's binds. If the ESME exceeds the maximum allowed sending rate, the SMPP servers return a throt­tling error command_status to the ESME.

Upon receiving a throttling error, the ESME must stop sending any messages (new or queued) for 15 seconds, before resuming message submissions.

The throttling error is defined in Short Message Peer-to-Peer Protocol Specification v3.4.

Single Device Mobile Terminated Message Throttling

To avoid generating network and data delivery errors when a given Device is already pro­cessing an MT-SMS message, the SMPP servers limit the rate at which messages can be sent to the same Device. Thus, the ESME must not transmit MT-SMS requests faster than the allowed rate to the same Device.

For a CDMA Device, this rate is one MT-SMS message every 10 seconds, and for a GSM Device, this rate is one MT-SMS message every 15 seconds. These values are subject to change without notice (for example, when Aeris detects excessive errors).

If the ESME exceeds the maximum sending rate to a single Device, the SMPP servers return a throttling error command_status to the ESME.

Mobile-Terminated SMS Error Handling Guidelines

If an error occurs during SMS delivery (as received by the SMPP servers from the net­work), the Submit_SM_Resp has a non-zero value in the command_status field. Table 4, "Aeris SMPP Status Codes," identifies the reason for the error.

Error codes not listed in Table 4, "Aeris SMPP Status Codes," must be treated as permanent errors.

ESMEs must discard any messages that receive permanent error codes.

It is never allowed for an ESME to Unbind on any type of MT-SMS error code.

Mobile-Originated Messages topics

Mobile-Origination Requirements

MO-SMS messages are routed to the correct ESME (and, hence, the correct Customer) based on the MDN ownership in the Aeris systems. Any ESME that has a receiver (or transceiver) bind must be prepared to receive:

Unexpected MO-SMS messages

MO-SMS messages from unexpected sources (perhaps because of destination address typos by mobile users)

Asynchronous delivery of MO-SMS messages

Short codes may be required to route the MO-SMS messages through the cellular network to Aeris, for delivery to a Customer.

In Aeris's Network Services, the requirement to use MO-SMS short codes depends on the cellular technology of the Radio Module used for the transmission (please contact Aeris Customer Support for more information).

MO-SMS Rate

The Aeris SMS network does not limit the rate of MO-SMS messages that it sends to Cus­tomer ESMEs; therefore, it is possible for an ESME to receive a burst of MO-SMS messages in a very short period of time. The ESME must be designed to accommodate these bursts.

Deliver_SM_Resp

The ESME must accept all Deliver_SM messages, and provide Deliver_SM_Resp responses to all Deliver_SM messages.

The ESME must send Deliver_SM_Resp within 5 seconds of receiving Deliver_SM.

TON And NPI Values

The SMPP servers generally set TON to 2 and NPI to 1, but the values may change depend­ing on the cellular network that the MO-SMS originated on.

The ESMEs must accept any value for TON and NPI that is allowed by the SMPP protocol.

Service_type

The service_type value in Deliver_SM is set to null. The ESME must ignore the value in this variable.

sequence_numberp

The sequence_number contained in Deliver_SM_Resp must correspond to the sequence_number used in the Deliver_SM.

The ESME must ensure that this rule is strictly followed.

esm_class

The esm_class is used in Deliver_SM to distinguish between a true MO-SMS (sent from a Device) and a Delivery Receipt (to an MT-SMS request). When esm_class is 0x00, the Deliver_SM is a MO-SMS; when the esm_class is 0x04, it is a Delivery Receipt for an earlier MT-SMS.

Message Receipt Time TLV

Aeris uses a vendor-specific TLV variable to provide the time of receipt of MO-SMS mes­sages at the SMPP servers. This TLV is provided in Deliver_SM as shown in the following table:
FieldSize (octets)TypeDescription
Parameter Tag2IntegerAeris_Received_Timestamp (0x1400)
Length2IntegerLength of Value part in octets
Value1-21C octet stringTimestamp receipt of the MO-SMS
Table 4: Message Receipt Time TLV

The timestamp is provided as a C octet string (i.e., it contains a terminating NUL byte) containing a double floating-point number, representing the number of seconds since 1970-01-01 00:00:00Z, including fractional seconds.

Thus, Value can be decoded using a C/C++ format string of "%0.3f".

The timestamp is specified in UTC.

For more information on time formats, please see Aeris Standard Date and Time Format Specification.

Status Codes topics

The following table shows the codes returned by the SMPP servers in command_status within responses. These values are within the range designated for vendor-specific error codes (see Short Message Peer-to-Peer Protocol Specification v3.4, section 5.1.3 for more information).

These values are in addition to the values specified in Short Message Peer-to-Peer Protocol Specification v3.4.

Thus, ESME developers must also implement the status codes specified in the SMPP protocol specification.
StatusCodeDescription
AERIS_CS_NOT_MDN_OWNER0x00000400The client does not own the Device specified in the command.
AERIS_CS_SMS_NOT_AUTHORIZED0x00000401The specified Device is not authorized to use SMS.
AERIS_CS_LOCATION_UNKNOWN0x00000402The remote Device location (Point Code in ANSI-41 and Service SMSC in GSM) is unknown.
AERIS_CS_COMMAND_BIND_TYPE_MISMATCH0x00000403The command is not compatible with the bind type. For example, a Submit_SM command sent using a Receiver bind.
AERIS_CS_INVALID_SHORT_MESSAGE_LENGTH0x00000404The short message length is invalid.
AERIS_CS_EXCEEDED_TERM_REQUEST_LIMIT0x00000405The maximum number of in-process mobile termi­nated commands has been exceeded.
AERIS_CS_INVALID_DESTINATION_TON0x00000406The destination Type Of Number ("TON") value must be either 1 (International) or 2 (National).
AERIS_CS_INVALID_DESTINATION_NPI0x00000407The destination Numbering Plan Indicator ("NPI") value must be 1, i.e., in E.164 format.
AERIS_CS_INVALID_DESTINATION_ADDR0x00000408The destination address is invalid. For example, if the destination type-of-number if 1 (International) then the destination address must begin with a "1", the North American Numbering Plan Area.

This error value is also returned if the destination address is an empty string or contains non-digits.
AERIS_CS_GARBLED_COMMAND0x00000409The command was garbled and could not be unpacked to create a valid SMPP command. This com­mand status is sent to the ESME in a Generic_Nack.
AERIS_CS_INSANE_COMMAND_LENGTH0x0000040aThe client sent a command with an insane command length (< 16 bytes or > 65536 bytes). This command status value is sent to a client in a Generic_Nack com­mand.

The SMPP server terminates the connection whenever this situation occurs.
Table 5: Aeris SMPP Status Codes

SMS Data Encoding Methods topics

Terminology

Interfaces for SMS Data

One of the Aeris API's for transceiving SMS data from/to Devices for Customers is the SMPP protocol described in Short Message Peer-to-Peer Protocol Specification v3.4. Another protocol for transceiving SMS data (in addition to other message types) is the API described in Aeris System Interface Specification. This API includes the Message Server ("MS") processes on Aeris systems) and Message Client ("MC") processes at the Cus­tomer systems, that communicate via this protocol. The third protocol for transceiving SMS data (also in addition to other message types) is described in AerFrame Web Services System Interface Specification. This includes the Web Ser­vices Server ("WS") processes on Aeris systems and the Web Services Client ("WC") processes at the Customer systems, that communicate via this protocol.

External Short Message Entity (ESME)

Aeris uses message formats from SMPP Release v3.4. The ESME must accept the message responses in the SMPP Release v3.4 formats.

In Short Message Peer-to-Peer Protocol Specification v3.4, an "ESME" is a general term describing the external entity (corporation, program, client, etc.) that transmits and receives SMS messages to their Devices, via SMPP servers. In this document, however, the term "ESME" represents the software client at the Cus­tomer that uses the messages defined in the SMPP protocol specification to connect, and bidirectionally communicate, with SMPP servers over a TCP/IP link.

Connections

Host Systems/Protocols
The Host connects to the Aeris systems via three protocols (any may be used) for SMS data:

An ESME-SMPP connection, using the SMPP messages described in Short Message Peer-to-Peer Protocol Specification v3.4, and ESME SMPP Connections To Aeris Specification. SMPP is an industry-standard protocol used for SMS text messaging.

An MC-MS connection, using the Aeris MS System Interface protocol described in Aeris System Interface Specification. The Customer Message Client ("MC") is the process that communicates with the Aeris Message Server ("MS") process. The MS System Interface is an Aeris-defined proprietary protocol.

A WC-WS connection, using the Aeris WS System Interface protocol described in Aer-Frame Web Services System Interface Specification. The Customer Web Services Client ("WC") is the process that communicates with the Aeris Web Services Server ("WS") process. The protocol uses industry-standard extensible Markup Language ("XML") and Simple Object Access Protocol ("SOAP") transports.

You can transceive SMS data from/to CDMA and GSM Devices on any of the above interfaces.

Logical Elements

The figure below shows the logical elements and connections for transceiving data from/to Hosts and Devices.

The interface for the WS-WC connection shows two processes since both a server and a client are required at Aeris and the Host for this transport.

The table below describes each connection's purpose and protocol.
ConnectionProtocolDescription
ASMPPTransceives SMS from/to the Customer Host systems and the Aeris Servers using SMPP version 3.4.
BMS - MCTransceives SMS from/to the Customer Host systems and the Aeris Servers, using the Aeris MS System Interface protocol.
C1, C2WS - WCTransceives SMS from/to the Customer Host systems and the Aeris Servers, using the Aeris WS System Interface protocol.
D, F, H, JSS7Aeris Servers transceive SMS from/to CDMA Carriers using SS7 and SMPP.
E, G, I, KSMPPAeris Servers transceive SMS from/to GSM Carriers using SMPP.
LCDMA RANThe SMS is transceived from/to the Radio Module ("Module") using the CDMA Radio Access Network ("RAN").
MGSM RANThe SMS is transceived from/to the Radio Module ("Module") using the GSM Radio Access Network ("RAN").
N, ODevice PortSMS communication between the CDMA/GSM Radio Modules ("Module") and the Processor in the Device. (Typically over a serial port. The specific protocol depends on the manufacturer of the module.)
Table 6: Connection Protocol and Description

The remainder of this page references only connections 'A', 'B', 'C(1)' and 'C(2)', as they are the interfaces your hosts connect with.

Connections 'N' and 'O' depend on the specific Module and are not described. Please refer to the documentation provided by the Manufacturer of the Module to determine the pro­tocol and commands to support MO-SMS and MT-SMS data encoding requirements. All the other connections are internal to Aeris and Carrier systems/transports and are also not described.
Connection 'A'...ESME-SMPP
The table below describes the results expected at the Host and Device, when transceiving SMS on the ESME-SMPP interface.
TechnologyDirectionSourceDestination
FromDataCodingToDataCoding
GSMMT-SMSHost7 bit (a)7 bitDevice7 bit (c)7 bit
8 bit8 bit
MO-SMSDevice7 bit7 bitHost8 bit (b)SMSC Default Alphabet
8 bit8 bit8 bit (d)
Table 7: ESME SMPP Interface Results

(a) - Within an SMPP octet array.

(b) - High bit is 0b0.

(c) - Important: Only 0x20 to 0x7E plus 0x0A and 0x0D, is delivered. All other values are altered to 0x60 by the GSM Carrier networks.

(d) - Important: This is Carrier-dependent. Some GSM Carriers do not deliver 8 bit MO-SMS data to Aeris at all ... the MO-SMS is discarded.
Connection 'B'...MC-MS Interface
The table below describes the results expected at the Host and Device, when transceiving SMS on the MC-MS interface.
TechnologyDirectionSourceDestination
FromDataCodingToDataCoding
GSMMT-SMSHost7 bit8 bit (a)Device7 bit (c)7 bit
8 bit
MO-SMSDevice7 bit7 bitHost8 bit (b)8 bit (a)
8 bit8 bit8 bit (d)
Table 8: MC-MS Interface Results

(a) - Data is in 8 bit unsigned char array.

(b) - High bit is 0b0.

(c) - Important: Only 0x20 to 0x7E plus 0x0A and 0x0D, is delivered. All other values are altered to 0x60 by the GSM Carrier networks.

(d) - Important: This is Carrier-dependent. Some GSM Carriers do not deliver 8 bit MO-SMS data to Aeris at all ... the MO-SMS is discarded.
Connection 'C(1)' and 'C(2)'...WC-WS Interface
The table below describes the results expected at the Host and Device, when transceiving SMS on the WC-WS interface.
DirectionSourceDestination
FromDataCodingToDataCoding
MT-SMSHost7 bit8 bit (a)Device8 bit (b)Octet
8 bit8 bit
MO-SMSDevice7 bit7 bitHost8 bit (b)8 bit (a)
8 bit8 bit8 bit
MT-SMSHost7 bit8 bit (a)Device7 bit (c)7 bit
8 bit
MO-SMSDevice7 bit7 bitHost8 bit (b)8 bit (a)
8 bit8 bit8 bit (d)
Table 9: WC-WS Interface Results

(a) - Data is in 8 bit unsigned char array.

(b) - High bit is 0b0.

(c) - Important: Only 0x20 to 0x7E plus 0x0A and 0x0D, is delivered. All other values are altered to 0x60 by the GSM Carrier networks.

(d) - Important: This is Carrier-dependent. Some GSM Carriers do not deliver 8 bit MO-SMS data to Aeris at all ... the MO-SMS is discarded.