Overview
This application note explains how legacy modem applications that previously used Circuit Switched Data (CSD) or SMS over 2G and 3G networks can be migrated to modern 4G and 5G communication methods.It focuses on practical migration from old modem communication models, such as dial-up data calls and SMS command messages, to packet-based communication using LTE, 5G, TCP/IP sockets, cloud services and IMS-based messaging.
The guide includes example AT command flows, application architecture guidance and practical design considerations for engineers updating existing field devices, telemetry systems, remote monitoring products and industrial IoT applications.
It also explains the two main ways TCP/IP socket data can be handled through a modem: transparent online data mode, which behaves most like a legacy dial-up CSD connection, and command-mode socket sending, where data is sent and received using specific AT commands such as
AT#SSENDandAT#SRECV.
¶ Applicable Products
| Product Type | Relevance |
|---|---|
| Cellular Modems | Used to provide serial, USB or embedded modem connectivity for legacy and modern telemetry applications. |
| Industrial Routers | Used to provide IP connectivity, VPN access, remote management and cloud communication for field systems. |
| Embedded Cellular Modules | Used in OEM devices migrating from 2G/3G modem behaviour to LTE, LTE-M, NB-IoT, 5G or IP-based operation. |
| Telemetry and Remote Monitoring Systems | Often contain legacy protocols originally designed around dial-up modem calls or SMS command messages. |
| Industrial IoT Gateways | Used to convert serial protocols, local data and device events into TCP/IP, MQTT, HTTP or cloud-based services. |
¶ Objectives
This application note explains:
- Why legacy CSD and SMS applications need to be reviewed as 2G and 3G networks are withdrawn.
- The difference between circuit-switched, SMS-based and packet-switched communication.
- How CSD-style applications can be migrated to TCP/IP socket connections.
- How SMS command and alarm applications can be migrated to IP data or IMS-supported messaging.
- How to compare old modem commands with modern LTE and 5G command flows.
- How transparent online data mode can be used as a close replacement for legacy CSD behaviour.
- How command-mode socket sending can be used when the application needs more controlled packet handling.
- How
AT#SD,AT#SSEND,AT#SRECVandAT#SHfit into a modern socket-based application. - How to structure an existing application so it can support both old and new communication methods during migration.
- How to avoid common migration mistakes when replacing CSD or SMS behaviour.
Expected Result
At the end of this guide, the reader should understand how to move a legacy modem application from 2G/3G CSD or SMS operation to a modern 4G/5G-ready architecture using packet data, TCP/IP services and appropriate messaging methods.
¶ Why Migration Is Required
Many older telemetry and machine-to-machine systems were designed when 2G and 3G networks were the normal cellular technologies available for remote equipment.
These systems often used:
- Circuit Switched Data, or CSD.
- SMS command messages.
- SMS alarm reporting.
- Dial-up modem behaviour.
- Serial modem replacement.
- Point-to-point data calls.
- Basic store-and-forward messaging.
These methods were effective for many years because they were simple, widely available and easy to integrate with embedded controllers.
However, modern cellular networks are primarily designed around packet-switched IP data.
4G LTE and 5G networks are IP-based systems. They are intended to carry data using packet services rather than traditional circuit-switched modem calls.
This means that applications relying on CSD or legacy SMS behaviour should be reviewed and, where necessary, redesigned for LTE, LTE-M, NB-IoT, 5G or IP-based operation.
¶ Legacy Communication Methods
¶ Circuit Switched Data
Circuit Switched Data is a dial-up style data service.
It behaves in a similar way to a traditional modem call.
A device dials another number, the network establishes a dedicated circuit, and data is exchanged over that circuit while the call remains connected.
Typical characteristics include:
- Dialled telephone number.
- Point-to-point connection.
CONNECTresponse when the call is established.- Serial data transferred after connection.
- Escape sequence or hang-up command to terminate the call.
- Low data rate compared with modern packet data.
- Dependency on 2G or 3G circuit-switched network support.
A simplified CSD session may look like this:
AT
OK
AT+CREG?
+CREG: 0,1
OK
ATD01234567890
CONNECT
<application data passes transparently>
+++
OK
ATH
OK
In this model, the application often treats the modem as if it were a transparent cable once the call is connected.
The modem is not being asked to send individual packets with a separate command. Instead, once the CSD call has returned CONNECT, the application data passes through the modem until the session is escaped and closed.
This behaviour is important because many legacy applications were written around this simple flow:
Dial → CONNECT → send data → receive data → escape → hang up
When migrating to TCP/IP, the closest replacement is usually a TCP socket opened in transparent online data mode.
¶ SMS Command and Alarm Messaging
SMS-based applications use text messages to send commands, status updates or alarms.
Typical examples include:
- Remote relay control.
- Alarm notifications.
- Configuration commands.
- Meter readings.
- Device status updates.
- Restart commands.
- Simple acknowledgements.
A simplified SMS command flow may look like this:
AT+CMGF=1
OK
AT+CMGS="+441234567890"
> PUMP=ON
+CMGS: 23
OK
SMS is still widely used in some systems, but it should not be treated as a direct replacement for IP data in new designs.
SMS delivery may be delayed, filtered, blocked, roaming-dependent or changed by network policy. On LTE and 5G networks, SMS may be delivered using IMS-based mechanisms or other operator-specific interworking methods rather than the old 2G/3G signalling path.
For new or redesigned telemetry systems, SMS should normally be considered as:
- A compatibility method.
- A fallback method.
- A low-frequency alert method.
- A migration bridge for legacy systems.
For regular telemetry, command handling, diagnostics and cloud integration, IP-based communication is usually more suitable.
¶ Modern Communication Methods
Modern LTE and 5G systems use packet-switched IP connectivity.
Instead of dialling a telephone number, the modem attaches to the mobile network, activates a packet data context and communicates with a remote server using an IP protocol.
Common modern communication methods include:
- TCP socket connection.
- UDP socket connection.
- HTTP or HTTPS request.
- MQTT publish/subscribe messaging.
- TLS-secured cloud connection.
- VPN tunnel.
- Private APN connection.
- Fixed public IP or private routed IP service.
- IMS-supported SMS or voice services where required by the operator.
For many CSD and SMS migrations, the most direct replacement is usually:
Legacy CSD data call → TCP client socket connection
Legacy SMS command → IP message, MQTT topic, HTTPS API or controlled SMS-over-IMS fallback
Legacy SMS alarm → MQTT publish, HTTPS POST, TCP packet or event message
¶ Migration Paths from Legacy Services to IP and Cloud
Move from circuit-switched and SMS services on 2G/3G to IP data and IMS on 4G/5G using a Siretta modem.
¶ CSD vs TCP/IP
The key difference between CSD and TCP/IP is the way the connection is created.
| Feature | CSD / Legacy Dial-Up | TCP/IP / Packet Data |
|---|---|---|
| Connection target | Telephone number | IP address, DNS hostname and port number |
| Network type | 2G/3G circuit-switched network | 4G/5G packet-switched network |
| Application model | Dial, connect, stream data, hang up | Attach, activate data context, open socket, exchange data, close socket |
| Remote endpoint | Modem, dial-in server or data terminal | TCP server, cloud platform, broker, API endpoint or gateway |
| Addressing | MSISDN telephone number | APN, IP address, DNS name and port |
| Data path | Transparent serial data over a circuit | Transparent online socket data or command-mode packet sending |
| Data handling | Application data passes after CONNECT |
Data may pass after CONNECT in online mode, or be sent using AT#SSEND in command mode |
| Scalability | Limited by dial-in ports and call handling | Scales through server sockets, cloud services, brokers and APIs |
| Security options | Limited | TLS, VPN, private APN, authentication and application-layer security |
¶ SMS vs IP Messaging
SMS and IP messaging are also different.
| Feature | SMS | IP-Based Messaging |
|---|---|---|
| Transport | Mobile network SMS service | TCP/IP data session |
| Addressing | Telephone number | Server URL, IP address, hostname, topic or API endpoint |
| Payload size | Limited message size | Application-defined payload size, subject to protocol and network limits |
| Delivery model | Store-and-forward message | Live connection, queued messaging, brokered messaging or request/response |
| Delivery confirmation | Delivery reports may be available but are not always reliable across networks | Application-level acknowledgement can be designed into the protocol |
| Data submission method | Message is submitted using SMS commands such as AT+CMGS |
Payload can be streamed through an open socket or sent as a controlled packet using AT#SSEND |
| Security | Limited application security unless payload encryption is added | TLS, authentication tokens, certificates, VPNs and private APNs can be used |
| Best use | Simple alerts, fallback control or legacy compatibility | Modern telemetry, command, diagnostics, cloud integration and scalable IoT systems |
¶ Understanding IMS
IMS stands for IP Multimedia Subsystem.
In LTE and 5G networks, IMS is commonly used by mobile operators to provide services such as voice over LTE, voice over 5G and SMS support over an IP-based network core.
For migration planning, the important point is that IMS is normally part of the operator-controlled service layer.
It is not usually something that an industrial application should use as a general-purpose data transport.
In practical terms:
- SMS may still be available on 4G or 5G through IMS or operator interworking.
- IMS support depends on the module, SIM, network operator and device configuration.
- IMS is not a direct replacement for a CSD data call.
- IMS SMS is not the same as designing a robust IP application protocol.
- For telemetry and machine data, TCP/IP, MQTT, HTTP/HTTPS or UDP are usually more appropriate.
- Where SMS is retained, the application should still be designed so that SMS is not the only method of communication.
Important Note
Use IMS-based SMS only where SMS remains a deliberate requirement. Do not design a new telemetry system around SMS simply because SMS may still exist on LTE or 5G. For most modern M2M and IoT systems, application data should move over packet data.
¶ Old Commands vs New Commands
The exact AT commands vary by modem family, firmware version and manufacturer.
The examples below use Telit AT command flows because these are commonly used in modem documentation. Telit-style documentation includes AT commands for SMS, PDP context activation and socket operation, including +CMGS, +CGDCONT, #SGACT, #SCFG, #SD, #SSEND, #SRECV and #SH.
Important Note
Always check the AT command manual for the exact module and firmware version being used. Command syntax, supported parameters, PDP context behaviour, socket modes and IMS features can vary between modem families.
¶ Legacy CSD Call
A traditional CSD-style flow is based on dialling a remote telephone number:
AT
OK
AT+CREG?
+CREG: 0,1
OK
ATD01234567890
CONNECT
<transparent application data>
+++
OK
ATH
OK
In this model:
ATconfirms the modem is responding.AT+CREG?checks circuit-switched network registration.ATD...dials the remote number.CONNECTindicates that the circuit-switched call has connected.- Application data is then passed transparently.
+++escapes from data mode.ATHhangs up the call.
The important behaviour is that the application sends data directly after CONNECT. The modem is not asked to send a specific message block. The serial interface effectively becomes the data path.
¶ Modern TCP Client Socket: Transparent Online Data Mode
Transparent online data mode is the closest TCP/IP equivalent to a legacy CSD data call.
The modem attaches to the LTE or 5G network, activates packet data, opens a TCP socket, then enters a data mode where the application can pass data through the modem.
Example flow:
AT
OK
AT+CPIN?
+CPIN: READY
OK
AT+CEREG?
+CEREG: 0,1
OK
AT+CGDCONT=1,"IP","your.apn.here"
OK
AT#SGACT=1,1
#SGACT: "10.123.45.67"
OK
AT#SD=1,0,5000,"server.example.com",0,0,0
CONNECT
<application data passes transparently>
+++
OK
AT#SH=1
OK
AT#SD=1,0,5000,"server.example.com",0,0,0
The third '0,0,0' specifies the transparent socket!
In this model:
AT+CPIN?confirms the SIM is ready.AT+CEREG?checks LTE EPS registration.AT+CGDCONTdefines the packet data context and APN.AT#SGACTactivates the data context.AT#SDopens a TCP socket.CONNECTindicates that the socket is open and the modem has entered online data mode.- Application data is passed directly through the modem.
+++escapes from online data mode back to AT command mode.AT#SHcloses the socket.
This approach can be useful where the existing application was written for CSD and expects the modem to behave like a transparent serial pipe after connection.
¶ Modern TCP Client Socket: Command Mode with AT#SSEND
Command-mode socket sending is different from transparent online data mode.
In this model, the modem opens the TCP socket but remains in AT command mode. The application then sends data using a specific send command and receives data using a specific receive command.
Example flow:
AT
OK
AT+CPIN?
+CPIN: READY
OK
AT+CEREG?
+CEREG: 0,1
OK
AT+CGDCONT=1,"IP","your.apn.here"
OK
AT#SGACT=1,1
#SGACT: "10.123.45.67"
OK
AT#SCFG=1,1,1500,90,600,50
OK
AT#SD=1,0,5000,"server.example.com",0,0,1
OK
AT#SSEND=1
> HELLO DEVICE 12345
OK
AT#SRECV=1,1500
#SRECV: 17
ACK DEVICE 12345
OK
AT#SH=1
OK
AT#SD=1,0,5000,"server.example.com",0,0,1
The third '0,0,1' specifies the command mode socket!
In this model:
AT#SDopens the TCP socket.- The modem remains in AT command mode.
AT#SSENDsends a defined payload to the open socket.AT#SRECVreads data received from the socket.AT#SHcloses the socket.
This method is useful where the application needs to control individual messages, define packet boundaries, log sent data, wait for acknowledgements or recover cleanly after communication problems.
¶ Transparent Mode vs AT#SSEND Command Mode
Both methods use packet-switched IP data.
The difference is how the local application exchanges data with the modem after the socket has been opened.
| Feature | Transparent Online Data Mode | Command Mode with AT#SSEND |
|---|---|---|
| Application behaviour | Application sends and receives data directly after CONNECT. |
Application sends and receives data using AT commands. |
| Closest legacy equivalent | Legacy CSD dial-up connection. | SMS-style or packet-style message submission. |
| How data is sent | Data is written directly to the serial interface after socket connection. | Data is sent using AT#SSEND. |
| How data is received | Data appears directly on the serial interface while in online data mode. | Data is read using AT#SRECV or by handling socket receive indications where supported. |
| Session escape | Typically uses +++ to escape back to command mode. |
Usually remains in command mode, so escape is not normally required. |
| Best for | Legacy applications that expect a transparent serial data pipe. | Structured telemetry, event messages, controlled retries and message acknowledgements. |
| Debugging | Can be harder to inspect because the application stream passes directly through the socket. | Easier to log and debug because each send and receive action is command-driven. |
| Migration effort | Often lower for applications already built around CSD behaviour. | May require more software changes, but gives better control of the communication process. |
Practical Note
When migrating from CSD, transparent online data mode may be the fastest migration route because it behaves most like the original dial-up connection. However, command mode usingAT#SSENDandAT#SRECVoften gives the application better control and may be easier to debug, log and recover after network interruptions.
¶ Command Mapping Examples
The following table shows how legacy CSD or SMS concepts can be translated into modern IP-based modem behaviour.
| Legacy Requirement | Old Method | Modern Transparent Socket Equivalent | Modern Command-Mode Equivalent |
|---|---|---|---|
| Check modem responds | AT |
AT |
AT |
| Check SIM is ready | AT+CPIN? |
AT+CPIN? |
AT+CPIN? |
| Check 2G/3G registration | AT+CREG? |
AT+CEREG? |
AT+CEREG? |
| Dial or connect to remote system | ATD01234567890 |
AT#SD=1,0,5000,"server.example.com",0,0,0 |
AT#SD=1,0,5000,"server.example.com",0,0,1 |
| Connection established | CONNECT |
CONNECT |
OK, followed by command-mode socket sending |
| Send data after connection | Transparent data after CONNECT |
Transparent data after socket CONNECT |
AT#SSEND=1 followed by payload |
| Receive data after connection | Transparent data from remote modem | Transparent data from remote server | AT#SRECV=1,1500 |
| Escape from data session | +++ |
+++ |
Not usually required because the modem remains in command mode |
| Hang up or close connection | ATH |
AT#SH=1 |
AT#SH=1 |
| Send command by SMS | AT+CMGS |
Send command text through an open TCP socket | AT#SSEND=1 with application command payload, or modem HTTP/MQTT commands where supported |
¶ Migrating a CSD Application
A CSD application normally expects a simple model:
Dial number → wait for CONNECT → send serial data → receive serial data → hang up
A TCP/IP application can be structured in one of two ways.
The first option is transparent online data mode:
Register on network → activate data context → open socket → CONNECT → send transparent data → escape → close socket
The second option is command-mode packet sending:
Register on network → activate data context → open socket → send packet with AT#SSEND → read response with AT#SRECV → close socket
¶ CSD Dial-Up vs TCP/IP Packet Data Flow
Compare the legacy circuit-switched dial-up sequence with the modern LTE/5G packet data process used to activate an IP context, open a socket and exchange application data.
¶ AT#SSEND Command-Mode Packet Flow
Figure 3 shows the alternative command-mode method where the modem opens a socket, remains under AT command control, and uses AT#SSEND and AT#SRECV to exchange application data.
¶ Recommended Migration Approach
- Identify the old CSD data payload.
- Identify whether the legacy application expects transparent streaming or discrete messages.
- Separate the application protocol from the modem dial-up behaviour.
- Decide whether transparent online data mode or command-mode socket sending is the best migration route.
- Replace telephone-number addressing with server hostname, IP address and port.
- Add APN and packet data configuration.
- Add connection state handling.
- Add application-level acknowledgement.
- Add timeout and retry logic.
- Add security where required.
- Test behaviour during signal loss, network reconnection and server failure.
¶ Example CSD Payload Reuse
In many systems, the application data itself does not need to change immediately.
For example, a legacy CSD payload may be:
DEVICE=12345;TEMP=18.7;ALARM=0
Instead of sending this payload after a CSD CONNECT, the application can send the same payload through a TCP socket.
In transparent online data mode, the payload is sent directly after socket connection:
AT#SD=1,0,5000,"server.example.com",0,0,0
CONNECT
DEVICE=12345;TEMP=18.7;ALARM=0
+++
OK
AT#SH=1
OK
In command mode, the same payload is sent using AT#SSEND:
AT#SD=1,0,5000,"server.example.com",0,0,1
OK
AT#SSEND=1
> DEVICE=12345;TEMP=18.7;ALARM=0
OK
AT#SH=1
OK
This allows the first migration step to focus on transport replacement rather than rewriting the complete application protocol.
¶ Migrating an SMS Application
An SMS application normally expects a store-and-forward model:
Send SMS → wait for delivery or reply → process response
An IP-based application should normally use a more structured messaging model:
Create event → connect to server or broker → send payload → receive acknowledgement → retry if required
SMS migration is usually different from CSD migration because SMS messages are already discrete payloads.
For this reason, command-mode socket sending with AT#SSEND may be a natural fit for many SMS migration projects.
A legacy SMS command or alarm can be treated as a message payload and sent to a TCP server, MQTT broker, HTTPS endpoint or cloud application.
¶ Legacy SMS Example
AT+CMGF=1
OK
AT+CMGS="+441234567890"
> ALARM DEVICE=12345 INPUT=1
+CMGS: 42
OK
¶ IP Message Equivalent Using Command Mode
The same alarm can be sent to a server as an application message using AT#SSEND:
AT#SD=1,0,5000,"server.example.com",0,0,1
OK
AT#SSEND=1
> ALARM DEVICE=12345 INPUT=1
OK
AT#SRECV=1,1500
#SRECV: 3
ACK
OK
AT#SH=1
OK
In this model:
- The application creates the alarm message.
- The modem opens a TCP socket.
AT#SSENDsends the message to the server.AT#SRECVreceives the acknowledgement.AT#SHcloses the socket when complete.
This is often easier to manage than transparent streaming when the application is sending individual alarm messages, status updates or command responses.
¶ IP Message Equivalent Using Transparent Mode
Transparent online data mode can also be used where the application already expects to stream serial data.
AT#SD=1,0,5000,"server.example.com",0,0,0
CONNECT
ALARM DEVICE=12345 INPUT=1
ACK
+++
OK
AT#SH=1
OK
This model is closer to CSD, but may be less controlled for applications that need defined message boundaries or structured retry behaviour.
¶ Structured Payload Example
The SMS payload can also be converted into a structured format:
{
"deviceId": "12345",
"event": "alarm",
"input": 1,
"state": "active"
}
This can then be sent using HTTPS, MQTT or another application protocol supported by the device.
Practical Note
SMS migration often benefits from command-mode packet sending because SMS messages are already discrete messages. CSD migration often benefits from transparent online data mode because CSD applications often expect a continuous serial data pipe.
¶ Application Architecture for Migration
The most important design principle is to separate the application logic from the communication transport.
Figure 4 shows the separate application logic from the communication transport to support legacy CSD, transparent TCP sockets, command-mode packet sending, MQTT, HTTPS and other modern IP services and a legacy system could be rewritten like this:
| Software Layer | Responsibility | Migration Benefit |
|---|---|---|
| Application logic | Reads inputs, controls outputs and creates messages. | Can remain mostly unchanged during transport migration. |
| Message formatter | Creates text, binary, JSON or protocol-specific payloads. | Allows payloads to be reused or gradually modernised. |
| Transport abstraction | Selects CSD, SMS, transparent TCP socket, command-mode TCP socket, MQTT, HTTP or another communication method. | Allows old and new transports to coexist during rollout. |
| Modem driver | Handles AT commands, responses, timeouts, modem state, socket state and data mode transitions. | Keeps modem-specific command differences isolated. |
| Data mode handler | Manages transparent online data mode, escape sequences and socket closure. | Supports CSD-like behaviour over a modern TCP/IP connection. |
| Packet send handler | Uses commands such as AT#SSEND and AT#SRECV to send and receive defined payloads. |
Supports controlled message-based communication over TCP/IP. |
| Retry and store-and-forward logic | Queues messages when the network is unavailable. | Improves reliability compared with direct send-and-forget behaviour. |
¶ Recommended Modern Data Architecture
For most modern telemetry systems, the device should connect outwards to a known server, broker or cloud endpoint.
This is usually easier than trying to contact the device directly from the server, because cellular devices are often behind carrier NAT or private APN addressing.
Recommended options include:
| Architecture | How It Works | Best Suited For | Typical Modem Data Method |
|---|---|---|---|
| Device TCP client to server | The field device opens a TCP connection to a known server IP address or hostname. | Closest replacement for many CSD-style applications. | Transparent online data mode or command mode with AT#SSEND. |
| MQTT client to broker | The device publishes telemetry and subscribes to command topics. | Modern IoT systems requiring scalable messaging and two-way communication. | Modem MQTT commands where supported, or application-layer MQTT over socket data. |
| HTTPS API | The device sends data using HTTPS POST requests and receives structured responses. | Cloud integration, REST APIs and event-based data reporting. | Modem HTTP commands where supported, or application-managed HTTPS. |
| Private APN with routed IP | The SIM connects into a private network where devices can be addressed through controlled routing. | Industrial systems requiring private addressing, security and managed access. | Transparent socket, command-mode socket, VPN or routed IP service. |
| VPN tunnel | The router or gateway creates a secure tunnel back to the customer network. | Remote access, legacy serial server replacement and secure industrial connectivity. | Usually handled by a router or gateway rather than a simple modem AT socket interface. |
¶ TCP Client vs TCP Server Mode
When replacing a dial-up modem system, it is important to choose the correct connection direction.
A legacy CSD system may allow either side to dial the other using a telephone number.
With IP data, this is less straightforward because many cellular connections use private addressing or carrier-grade NAT.
| Mode | Description | Practical Recommendation |
|---|---|---|
| Device as TCP client | The modem or field device opens an outbound connection to a server. | Recommended for most cellular applications because outbound connections usually work through NAT. |
| Device as TCP server | The modem listens for an incoming TCP connection. | Only practical where the device has a reachable IP address, private APN, VPN or suitable port forwarding arrangement. |
| Server as command broker | The device connects out, then the server sends queued commands over the established connection. | Recommended replacement for many systems that previously sent SMS commands to the device. |
For either TCP client or TCP server operation, the application must still decide whether it will use:
- Transparent online data mode.
- Command-mode sending with
AT#SSEND. - A higher-level protocol such as MQTT or HTTP where supported.
¶ Handling Acknowledgements
CSD and SMS applications often relied on simple behaviours:
- CSD: if the call connected, the path was assumed to exist.
- SMS: if the message was sent, delivery was often assumed.
- SMS reply: a response message was treated as confirmation.
Modern IP applications should use explicit application-layer acknowledgements.
Example:
Device sends:
MSG,12345,ALARM,INPUT1,ACTIVE
Server replies:
ACK,12345,ALARM,2026-09-11T12:00:00Z
This acknowledgement can be handled in either data mode.
In transparent online data mode, the acknowledgement is received directly in the data stream:
CONNECT
MSG,12345,ALARM,INPUT1,ACTIVE
ACK,12345,ALARM,2026-09-11T12:00:00Z
In command mode, the acknowledgement can be read using AT#SRECV:
AT#SSEND=1
> MSG,12345,ALARM,INPUT1,ACTIVE
OK
AT#SRECV=1,1500
#SRECV: 38
ACK,12345,ALARM,2026-09-11T12:00:00Z
OK
This allows the device to know that the server has received and processed the message.
If the acknowledgement is not received, the device can:
- Retry immediately.
- Retry after a delay.
- Store the message for later.
- Switch to a backup server.
- Report a local fault.
- Use SMS fallback if still required and supported.
¶ Security Considerations
Legacy CSD and SMS applications often had limited security.
They may have relied on:
- Obscure phone numbers.
- Caller ID checks.
- Simple passwords in SMS.
- Closed dial-in systems.
- Private knowledge of command syntax.
These protections are not sufficient for modern IP-connected systems.
Modern systems should consider:
- TLS encryption.
- Certificate validation.
- Device authentication.
- API keys or tokens.
- Username and password authentication.
- Private APN.
- VPN.
- Firewall rules.
- Server-side rate limiting.
- Replay protection.
- Message signing where required.
Security must also be considered when choosing between transparent data mode and command-mode packet sending.
Transparent online data mode may be simpler for legacy applications, but the application must still manage protocol framing, authentication and encryption if these are required.
Command-mode sending may make it easier to add controlled message IDs, acknowledgements, retry counters and logging.
Important Note
Moving from CSD or SMS to IP data can improve capability and scalability, but it can also expose the application to wider network risks if security is not designed correctly.
¶ Migration Strategy
A practical migration plan should reduce risk by separating the transport change from the application change.
¶ Stage 1: Audit the Existing System
Identify:
- Which devices use CSD.
- Which devices use SMS.
- Which networks and SIMs are used.
- Which commands are sent.
- Which payloads are exchanged.
- Whether the application expects transparent streaming.
- Whether the application sends discrete messages.
- Whether delivery acknowledgement exists.
- Whether the backend is dial-in, SMS gateway, server-based or manually operated.
- Whether data must be real-time or can be queued.
- Whether remote commands are safety-critical.
¶ Stage 2: Preserve the Payload Where Possible
Where practical, keep the existing payload format during the first migration.
For example:
LEVEL=54;BAT=12.1;ALARM=0
This can be sent over TCP/IP before it is later converted into JSON, MQTT or a modern API format.
In transparent online data mode:
CONNECT
LEVEL=54;BAT=12.1;ALARM=0
In command mode:
AT#SSEND=1
> LEVEL=54;BAT=12.1;ALARM=0
OK
This reduces the number of variables being changed at the same time.
¶ Stage 3: Replace the Transport
Replace:
Dial-up call or SMS transport
With:
Packet data context + TCP/IP connection
At this stage, the focus is on reliable connection establishment, timeout handling, retries and server reachability.
¶ Stage 4: Choose the Socket Data Handling Method
Choose either:
Transparent online data mode
or:
Command mode using AT#SSEND and AT#SRECV
The choice should be based on the behaviour of the existing application.
Use transparent online data mode where:
- The legacy application expects a serial pipe after
CONNECT. - The existing software already handles its own framing.
- The data stream is continuous.
- Minimum application change is required.
Use command mode with AT#SSEND where:
- Data is sent as individual messages.
- The application needs controlled send and receive operations.
- The system benefits from explicit acknowledgements.
- Logging and debugging are important.
- Retry handling needs to be precise.
¶ Stage 5: Add Application-Level Acknowledgement
Do not assume that a socket send means the application server has processed the message.
Add explicit acknowledgement from the server.
¶ Stage 6: Add Security
Add TLS, VPN, private APN or application authentication depending on the application risk.
¶ Stage 7: Optimise the Application Protocol
Once the new transport is stable, consider improving the payload format.
Possible improvements include:
- JSON.
- MQTT topics.
- Binary protocol framing.
- Message IDs.
- Timestamps.
- Checksums.
- Device identifiers.
- Command sequence numbers.
- Firmware and configuration version reporting.
¶ Example Legacy-to-Modern Conversion
¶ Original SMS Control Message
PUMP1 ON
¶ Modern Equivalent Payload
{
"deviceId": "PUMP-STATION-001",
"command": "setOutput",
"output": "PUMP1",
"state": "ON",
"messageId": "CMD-000123"
}
¶ Original CSD Telemetry Payload
ID=12345,TEMP=18.7,VIN=12.2,ALARM=0
¶ Modern TCP Payload
{
"deviceId": "12345",
"temperature": 18.7,
"supplyVoltage": 12.2,
"alarm": false,
"messageId": "TEL-987654"
}
The modern payload can be sent in transparent online data mode:
CONNECT
{
"deviceId": "12345",
"temperature": 18.7,
"supplyVoltage": 12.2,
"alarm": false,
"messageId": "TEL-987654"
}
Or it can be sent in command mode:
AT#SSEND=1
> {"deviceId":"12345","temperature":18.7,"supplyVoltage":12.2,"alarm":false,"messageId":"TEL-987654"}
OK
Practical Note
The payload does not have to be converted to JSON immediately. A staged migration can send the original text payload over TCP/IP first, then modernise the message format later.
¶ Common Migration Problems
| Problem | Cause | Recommended Fix |
|---|---|---|
| The modem registers but cannot send data | APN, PDP context or data activation is incorrect. | Check SIM, APN, registration state and context activation response. |
| The socket opens but the server receives nothing | Wrong socket mode, wrong send method, missing line ending, firewall issue or server-side protocol mismatch. | Check whether the application is using transparent mode or AT#SSEND, then confirm payload format, server logs and firewall rules. |
| Application sends data but modem treats it as AT commands | The modem is still in command mode rather than transparent online data mode. | Use AT#SSEND for command-mode sending, or open the socket in the correct mode for transparent data operation. |
| Cannot enter AT commands after sending data | The modem is still in transparent online data mode. | Use the escape sequence, such as +++, then close or manage the socket from command mode. |
| Incoming connections to the device do not work | Device is behind carrier NAT or does not have a reachable IP address. | Use outbound client connections, private APN, VPN or broker-based command delivery. |
| Commands are duplicated | Retries occur without message IDs or idempotent command handling. | Add unique message IDs and server-side duplicate detection. |
| Messages are lost during poor signal conditions | No store-and-forward queue exists in the device application. | Queue unsent messages locally and retry when network service returns. |
| Old SMS commands are insecure | Commands rely on phone number or plain text passwords. | Move to authenticated IP commands or add strong application-layer validation. |
| Migration changes too many things at once | Transport, payload, server and security model are all changed together. | Use a staged migration to isolate and test each change. |
¶ Testing Checklist
Before deploying a migrated application, test the following:
- SIM registration on the intended network.
- Correct APN and PDP context configuration.
- Packet data activation.
- DNS resolution if using hostnames.
- TCP socket connection to the server.
- Transparent online data mode, if used.
- Escape sequence behaviour, if transparent mode is used.
- Command-mode sending with
AT#SSEND, if used. - Command-mode receive handling with
AT#SRECV, if used. - Data send and receive behaviour.
- Line endings and payload framing.
- Server acknowledgement.
- Retry logic.
- Socket closure and reconnection.
- Network loss and recovery.
- Roaming behaviour where applicable.
- Low signal operation.
- Power cycling during unsent messages.
- Duplicate message handling.
- Security authentication.
- TLS or VPN operation where used.
- SMS fallback if retained.
- Long-duration soak testing.
¶ Best Practice Summary
When migrating CSD and SMS applications to IP data:
- Do not wait until the legacy network service is withdrawn.
- Audit existing CSD, SMS and dial-up behaviours.
- Separate application payloads from modem transport behaviour.
- Decide whether the application needs transparent online data mode or command-mode packet sending.
- Use transparent online data mode where the legacy system expects a CSD-like serial pipe.
- Use
AT#SSENDandAT#SRECVwhere the application needs controlled message handling. - Use outbound TCP/IP connections where possible.
- Replace telephone-number addressing with hostname, IP address and port.
- Use APN and packet data context configuration correctly.
- Add application-layer acknowledgements.
- Add retry and store-and-forward logic.
- Use MQTT, HTTPS or TCP depending on the application requirement.
- Treat IMS SMS as a compatibility service, not a general-purpose data transport.
- Add security when moving to IP-connected systems.
- Test failure conditions, not only successful connections.
- Check the AT command manual for the exact modem and firmware version.
¶ Conclusion
Legacy CSD and SMS applications were effective for many 2G and 3G telemetry systems, but modern cellular networks are moving towards LTE, 5G and packet-switched IP communication.
CSD-style modem calls should normally be migrated to TCP/IP socket connections, VPNs, private APNs or modern cloud communication services.
There are two common socket migration paths.
The first is transparent online data mode, where the TCP socket behaves most like a legacy CSD connection. The application waits for CONNECT, sends and receives data through the modem, then escapes and closes the socket.
The second is command-mode socket sending, where the application opens a socket and then uses commands such as AT#SSEND and AT#SRECV to send and receive defined payloads.
SMS command and alarm systems should be reviewed carefully. Some SMS functionality may remain available through IMS or operator interworking, but new telemetry systems should normally use IP-based messaging such as TCP, MQTT or HTTPS.
The safest migration strategy is to separate the application payload from the modem transport. This allows the existing application data to be reused while the connection method is updated from dial-up or SMS to packet data.
A well-designed migration should include:
- Correct modem and SIM selection.
- Proper APN and packet data configuration.
- Reliable TCP/IP or cloud communication.
- A deliberate choice between transparent data mode and command-mode packet sending.
- Application-level acknowledgement.
- Store-and-forward retry behaviour.
- Appropriate security.
- Thorough testing under real network conditions.
The goal is not simply to replace one AT command with another.
The goal is to move from a legacy circuit-switched or SMS-dependent system to a robust, supportable and future-ready IP communication architecture.