SMPP Bind Types Explained: Transmitter, Receiver and Transceiver

Before an SMPP client (an ESME) can send or receive anything, it must open a TCP connection to the SMSC and send a bind request. The kind of bind decides which operations are allowed on that session. SMPP v3.4 defines three: transmitter, receiver and transceiver, usually shortened to TX, RX and TRX.

The three bind PDUs

Each request has a matching response with the high bit set (for example bind_transceiver_resp is 0x80000009). The response carries the SMSC's own system_id and a command_status of 0 on success.

Fields in a bind request

• system_id: the login of the client account.
• password: the account password.
• system_type: an optional free-text identifier of the client application.
• interface_version: 0x34 for SMPP v3.4.
• addr_ton, addr_npi, address_range: optional routing information, often left empty.

What each bind allows

Transmitter (TX)

A TX session is for sending. It can submit messages (submit_sm, submit_multi, data_sm) and query or cancel them, but the SMSC will not push deliver_sm to it. Use TX when you only send and receive your delivery reports somewhere else, or when you want to separate the send path from the receive path for load reasons.

Receiver (RX)

An RX session is for receiving. The SMSC sends deliver_sm PDUs to it: delivery receipts for messages you submitted, and mobile-originated messages where the service supports them. The client must answer each one with deliver_sm_resp. It cannot submit messages on this session.

Transceiver (TRX)

A TRX session does both on a single connection. It was introduced in SMPP v3.4 and is the simplest choice for most applications: one socket, one window of outstanding requests, one enquire_link keep-alive. Some older SMSCs support only TX and RX, so a client that must work everywhere should be able to open a TX plus RX pair.

When to use which

1. Default to TRX if both sides support it. It is easier to operate and monitor.
2. Use TX + RX when the SMSC does not support TRX, or when you want separate connections, for example to scale receipt handling independently from sending.
3. Use TX only for fire-and-forget sending where reports are not needed, and set registered_delivery to 0.
4. Use RX only for a component that only consumes reports or incoming messages.

Common bind errors to test

A useful test for any client is to send a PDU on the wrong bind type and check that the client reads the ESME_RINVBNDSTS error instead of retrying forever. Also verify that the client rebinds and resumes after the connection drops and that it answers every enquire_link from the SMSC.

Session behavior after the bind

A bind is only the start of the session. Once bound, both sides should keep the session healthy and close it cleanly:

• Send enquire_link at a regular interval and treat a missing enquire_link_resp as a dead connection.
• Limit the number of requests waiting for a response (the window size), because an SMSC can answer with ESME_RTHROTTLED (0x58) when you send too fast.
• Close the session with unbind and wait for unbind_resp before dropping the TCP connection.
• Reconnect with a growing pause between attempts, so a failing SMSC is not flooded with bind requests.

Testing bind types with a simulator

Bind behavior is easy to test against a simulator because you can create as many accounts and credentials as you need. In Maxi you connect to a single SMPP port (4444) with a Transmitter (TX), Receiver (RX) or Transceiver (TRX) connection. You send messages via TX, receive delivery reports via RX, or do both via TRX. Each client SMPP connection gets its own session, and each connection needs its own login and password with the connecting IP address added to the account. See how to configure it step by step.

Want to check your client against all three bind types? Register for the free trial period or contact us. For what happens after the bind, read about SMPP delivery receipts.