LTE IMS SMS

This tutorial shows how to test SMS over IMS with a commercial UE on Amari Callbox. We have been using SMS in every radio technology (i.e, 3G, 4G, 5G) and user interface on commercial mobile phone would look same whatever radio technology is used, but the detailed protocol behind the SMS differs with the radio access technology being used.

• 3G : SMS go through NAS messages carried by CS(Circuit Switch) channel
• LTE : Two different ways are used
• SG SMS : SMS go through NAS message  // check out this tutorial for SG SMS
• SM over IMS : SMS go through IMS  // this is the topic for this tutorial.
• 5G : SMS goes through IMS

One common thing regardless of the method listed above is that the way SMS message is being encoded and protocols at the level of session menagement (i.e, CP-DATA, CP-ACK etc).  Putting it other way, same format of SMS and session layer protocol is encapsulated in different way (i.e, NAS message or IMS) depending on different radio technology.

NOTE :  In most of the cases, the user interface on commericial phone would look same regardless of what kind of technology is used. Usually the UI on mobile phone select what type of technology to use depending on protocols status at the specific moment. So when you want to test a specific type of SMS, you need to know how to configure your UE(DUT) to apply the specific SMS technology you want to test.

If you are using the USIM card from Amarisoft, you don't need to change any settings in the default configuration (You just need to understand about the settings on default configuration) The setting change for this test would be mainly with UE side configuration setting.

Table of Contents

• LTE IMS SMS
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Configuration
• Perform the test
• MO SMS
• MT SMS
• Log Analysis
• MO SMS over IMS
• MT SMS over IMS

Introduction

Short Message Service (SMS) has been a fundamental communication service across multiple generations of mobile network technologies, including 3G, LTE, and 5G. While the end-user experience of sending and receiving SMS remains largely unchanged, the underlying protocol mechanisms and message delivery paths vary significantly depending on the radio access technology in use. With the advent of LTE and 5G, SMS delivery has transitioned from the traditional Circuit Switched (CS) domain to the Packet Switched (PS) domain, leveraging new transmission methods such as SMS over IP Multimedia Subsystem (IMS). IMS is a critical architectural framework within modern mobile networks, enabling the delivery of rich multimedia communication services—such as voice, video, and messaging—over IP networks. In the context of SMS over IMS, the message is encapsulated and transported using SIP (Session Initiation Protocol) and related IMS protocols, rather than being carried over legacy NAS (Non-Access Stratum) signaling. This technical evolution not only streamlines SMS service continuity in all-IP environments but also aligns with the broader industry shift toward unified, converged communications on 4G and 5G networks. Understanding the protocol architecture, session management concepts, and configuration requirements for SMS over IMS is essential for network engineers, testers, and developers who aim to validate and troubleshoot SMS functionality on commercial User Equipment (UE) using advanced testing platforms like the Amari Callbox. This tutorial provides comprehensive guidance on configuring, testing, and analyzing SMS over IMS workflows, highlighting the significance of protocol selection, UE configuration, and the impact of network settings on SMS delivery in the contemporary mobile ecosystem.

• Context and Background
  • SMS is a legacy service present across 3G, LTE, and 5G, but the protocol stack and message transport mechanisms differ as network technologies evolve.
  • In 3G networks, SMS is transmitted via NAS messages over the Circuit Switched (CS) channel.
  • LTE introduces two SMS transmission methods:
    • SG SMS: SMS messages are carried across the NAS signaling stack.
    • SMS over IMS: SMS messages are delivered using IMS protocols, leveraging SIP signaling for message transport.
  • 5G networks exclusively utilize SMS over IMS, reflecting the transition to fully IP-based service delivery architectures.
  • Despite protocol differences, the SMS message format and session management (e.g., CP-DATA, CP-ACK) remain consistent, with only the encapsulation and transmission method varying by technology.
• Relevance and Importance
  • Demonstrates how SMS services are maintained and evolved in modern, all-IP mobile network architectures.
  • Highlights the need for testing and validating SMS over IMS, particularly as operators phase out legacy CS infrastructure.
  • Addresses practical aspects of configuring and testing commercial UEs on platforms like Amari Callbox to ensure SMS service continuity and interoperability.
• What Learners Will Gain
  • In-depth understanding of SMS protocol architecture across 3G, LTE, and 5G networks.
  • Practical knowledge of configuring UEs for SMS over IMS testing scenarios.
  • Familiarity with protocol session management and encapsulation techniques relevant to SMS delivery.
  • Hands-on experience utilizing the Amari Callbox for protocol analysis and troubleshooting.
• Prerequisite Knowledge and Skills
  • Basic understanding of mobile network architecture (3G, LTE, 5G).
  • Familiarity with mobile device configuration and SIM/USIM concepts.
  • Awareness of signaling protocols such as NAS and IMS (SIP-based signaling).
  • Experience with network testing tools and UE configuration is advantageous but not mandatory.

Summary of the Tutorial

This tutorial describes the procedures and methodologies for testing SMS over IMS (IP Multimedia Subsystem) in an LTE environment using the Amarisoft Callbox. The tests cover both Mobile Originated (MO) and Mobile Terminated (MT) SMS scenarios. Below is a step-by-step summary of the test procedures, configuration steps, and analysis methods as described in the tutorial.

• Test Setup
  • Use the SIM card provided with the system. For custom configurations, refer to the Configuration Guide.
  • The setup includes the Amarisoft Callbox, a test UE, and the relevant configuration files for eNB, MME, and IMS functionalities.
• Key Configuration Parameters
  • Ensure correct impi, impu, and domain values in the configuration, as per Amarisoft documentation.
• Configuration Steps
  • Use default configuration files:
    • enb.default.cfg for LTE eNB
    • ims.default.cfg and ue_db-ims.cfg for IMS and UE DB
  • In MME configuration, ensure ue_db-ims.cfg is referenced as the user database.
  • On the UE side:
    • Verify that the ims APN is configured. If not, configure it manually.
    • Enable the VoLTE option to allow IMS registration.
  • Remember or note the 'tel' numbers for SMS testing, as these will be used for MO and MT SMS procedures.
• MO (Mobile Originated) SMS Test Procedure
  • Start LTE service and verify basic cell configuration (any LTE cell is acceptable).
  • Power on the UE and confirm successful network registration.
  • Ensure the UE is assigned an IMS PDN. There should be at least two or more bearers established, including separate IP addresses for internet and IMS APNs.
  • Check IMS registration status through the system interface; ensure the UE is listed as registered. If IMS registration is not successful, troubleshoot before proceeding.
  • Verify that SMS over VoLTE is supported and note the 'tel' number to be used as the recipient.
  • Send an SMS from the UE to the 'tel' number. Upon successful transmission, the Callbox (serving as the SMS Center) will echo the message back to the UE, confirming the operation.
  • Note: On the UE side, the procedure for sending SMS over SG and IMS appears the same, but the underlying technical process differs.
• MT (Mobile Terminated) SMS Test Procedure
  • Ensure the same preconditions as for MO SMS: LTE service running, UE registered, IMS PDN assigned, and IMS registration complete.
  • Use the Callbox command interface to send an SMS to the UE:
    sms <tel> <message> (e.g., sms 600 "Test for MT SMS over IMS")
  • Confirm the SMS is received on the UE, verifying successful reception of MT SMS over IMS.
• Log Analysis Methodology
  • Enable NAS, SIP, and IMS logs in the WebGUI for both MO and MT SMS testing.
  • Filter logs to focus on NAS, SIP, and IMS messages for clarity.
  • For MO SMS:
    • Verify IMS registration completion before the SMS attempt.
    • Identify SIP 'MESSAGE' messages that carry the SMS over IMS. Confirm the message is received and echoed by the Callbox (indicating successful SMS Center operation).
  • For MT SMS:
    • IMS registration verification is the same as MO SMS.
    • Identify SIP 'MESSAGE' indicating incoming SMS to the UE. Confirm the message is marked as sent, indicating MT SMS delivery.

Note: The tutorial assumes familiarity with the Amarisoft Callbox environment, LTE/IMS configuration files, and basic SMS over IMS concepts. Precondition for all tests is successful IMS registration of the UE.

NOTE : For some additional / summarized tips on SG SMS testing, refer to this wiki.

Test Setup

Test setup for this tutorial is as shown below.  

• SIM Card used in this tutorial is the one delivered with the system as it is.
• If you want to change the configuration, The tutorial Configuration Guide would help

Key Configuration Parameters

Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.

• impi
• impu
• domain

Configuration

I used the enb.default.cfg (LTE default configuration) as it is without changing any contents in it.

I also used the default configuration for mme as shown below. Since this test is to send / receive SMS via IMS, ims.cfg and ue_db-ims.cfg is important configurations. Unless your DUT(UE) requires any specific configuration, the default configuration (i.e, ims.default.cfg and ue_db-ims.cfg) would work.

In mme-ims.cfg file, you would notice that ue_db-ims.cfg is used as ue db.  "include ue_db-ims.cfg" tells the MME to load the UE subscriber database from a separate file.

In this IMS SMS test setup, mme-ims.cfg defines the main MME and EPC behavior, but the actual UE subscription information is kept in ue_db-ims.cfg. This usually includes UE identity and authentication information such as IMSI, key, OP or OPc, and APN-related settings.

This separation makes the configuration easier to manage. The MME configuration can stay focused on network behavior, while ue_db-ims.cfg defines which UEs are allowed to attach and what kind of service profile they have.

For IMS-based SMS, this is important because the UE must attach successfully first and then establish the proper IMS-related bearer or APN before SIP-based SMS can work.

In this tutorial, I am using Anritsu Test USIM. Remember tel number since these will be used for SMS. If you are using any other test USIM/ISIM, change the parameters accordingly. For SMS test, remember 'tel' numbers specified here since the numbers will be used to send SMS in this test. So, for this SMS test, remember the tel numbers configured here. If you later send an SMS to tel:600 or tel:0600000000, Amarisoft IMS uses these values to map the SMS destination to this UE profile.

On the UE side, make sure the ims APN is configured.

In many phones, internet and ims APNs may already be created automatically from the SIM profile or carrier configuration. But in some test setups, especially with Test USIM, the ims APN may not appear in the GUI. In that case, it should be added manually.

The internet APN is used for normal packet data service. The ims APN is used for IMS signaling, such as SIP registration and SIP MESSAGE based SMS over IMS.

Also make sure that VoLTE is enabled on the UE. Even though this tutorial is for SMS over IMS and not for a VoLTE voice call, many commercial UEs use the VoLTE option as a trigger to start IMS registration. If VoLTE is turned off, the UE may attach to LTE successfully but may not try to register to the IMS server.

So the important UE-side preparation is to have the ims APN available and to enable VoLTE. After this, the UE can establish the IMS PDN or bearer and then perform IMS registration, which is required before SMS over IMS can be tested.

Perform the test

With Amarisoft Callbox, you can test both MO SMS and MT SMS over IMS.

MO SMS means Mobile Originated SMS. In this case, the UE sends an SMS to the network. The message starts from the UE, goes through IMS signaling, and is handled by the Amarisoft IMS/SMS server.

MT SMS means Mobile Terminated SMS. In this case, the SMS is sent from the network side toward the UE. The Amarisoft Callbox generates or delivers the SMS to the UE through IMS.

So the same IMS SMS test setup can be used in both directions. For MO SMS, you check whether the UE can send SMS through IMS. For MT SMS, you check whether the UE can receive SMS through IMS.

MO SMS

MO SMS test starts after the LTE service is running and the basic cell configuration is confirmed.

The cell phy command shows the physical layer configuration of the LTE cell. In this example, the cell is running as LTE Band 7 with 5 MHz bandwidth. The downlink ARFCN is 3350 and the uplink ARFCN is 21350. The cell uses one antenna layer for downlink and one antenna layer for uplink. This confirms that the LTE radio cell is active and ready for UE attachment.

The cell command shows the higher-level cell configuration. For IMS-based SMS testing, the exact LTE cell configuration is not the most important part. Any valid LTE cell configuration can be used as long as the UE can camp on the cell, attach successfully, and establish the required PDN connection for IMS.

So this step is mainly a sanity check. Before testing MO SMS, first confirm that the LTE cell is on air and that the UE can see and attach to this cell.

Power on the UE and check whether it is registered to the LTE cell.

The ue command shows the UE currently connected to the Amarisoft eNB.

In this example, one UE is registered. The UE has RAN_UE_ID 1 and CN_UE_ID 100. The Cell value 0x001 shows that the UE is connected to cell 0x001. The RNTI value 0x003d is the radio identifier assigned by the eNB to this UE.

This confirms that the UE has successfully attached or at least established an active RRC connection with the LTE cell. After this step, you can continue with IMS registration checking and then MO SMS testing.

Make sure that the UE is assigned an IMS PDN after it attaches to LTE.

The mme ue command shows the UE registration status and the bearer/IP assignment from the core network side.

In this example, REG is Y, so the UE is registered to the EPC. The number of bearers is 2. This usually means that one bearer is used for the normal internet APN and another bearer is used for the IMS APN.

The IP_ADDR field shows multiple IP addresses assigned to the UE. Usually, the first IPv4 address is for the internet APN. The second IPv4 address and the IPv6 address are for the IMS APN.

This is an important checkpoint for IMS-based SMS. SMS over IMS cannot work only with LTE attach. The UE also needs the IMS PDN, and then it should complete IMS registration over that IMS connection. Once you see multiple bearers and IMS-related IP addresses, you can continue to check SIP registration and SMS signaling.

Following is indicating that UE is registered to IMS server.(NOTE : To test SMS over IMS, this is precodition for the test. If you don't see any users shown here, you cannot do SMS over IMS. So if you don't see any user here, troubleshoot IMS registration process first.)

Make it sure that sms volte option is supported and remember 'tel' number because it is the number you need to use to send SMS to.

In this example, one UE is registered to IMS. The IMPI value is the IMS private identity used for IMS authentication. The SIP Binding section shows the SIP contact address currently used by the UE. This means the UE has completed SIP registration and the IMS server knows how to reach this UE.

The Options field includes sms volte. This is an important point for this test. sms means SMS over IMS is supported, and volte means the UE is registered with VoLTE capability. For SMS over IMS test, sms should be shown here. If sms is not shown, the UE may be IMS-registered, but SMS over IMS may not work.

The IMPU field shows the public identities assigned to this UE. In this example, it includes the SIP URI and tel numbers. The tel numbers are the numbers you should use when sending SMS to this UE.

This is a required checkpoint before running the SMS test. If no user appears in ims users, the UE is not registered to the IMS server yet. In that case, SMS over IMS cannot be tested, and IMS registration should be debugged first.

Send SMS from UE and you will get the result as follows. (NOTE : In terms of SMS operation on UE side, you would not see any difference between SMS over SG and SMS over IMS. But in the background, different procedure is used on depending on UE status and UE internal implemenation)

You should send a SMS message to 'tel' number that you see in the result of '(ims) users' command. If the message is successfully send to SMS center of Callbox, you will get the echo back from the server (NOTE : In Amarisoft callbox, IMS server functions as SMS Center)

In this example, the UE sends the message to 600. This number comes from the IMPU list of the IMS-registered user. So the destination number used on the phone should match one of the tel identities configured in the IMS user profile.

When the UE sends the SMS, the message is delivered over IMS signaling to the Amarisoft IMS server. In the Amarisoft Callbox setup, the IMS server also works as the SMS center. So, when the server receives the SMS successfully, it sends the same message back to the UE as an echo.

The received message on the UE confirms that MO SMS over IMS is working. It shows that the UE could send the SMS through IMS and that the Callbox could receive it and return it back to the UE.

MT SMS

For MT SMS, the initial preparation is the same as MO SMS..(NOTE : To test SMS over IMS, this is precodition for the test. If you don't see any users shown here, you cannot do SMS over IMS. So if you don't see any user here, troubleshoot IMS registration process first.)

Before sending an SMS from the network side to the UE, make sure the UE is registered to the IMS server.

The ims users command shows the IMS-registered UE. If the UE appears here, it means SIP registration has completed and the IMS server knows the current SIP contact address of the UE.

The Options field should include sms. This indicates that SMS over IMS is supported for this registered UE.

The IMPU field shows the public identities of the UE. The tel numbers shown here are important because they are the destination numbers used when sending MT SMS from the Callbox side to the UE.

If no UE is shown in ims users, MT SMS over IMS cannot be tested yet. In that case, debug IMS registration first before checking SMS delivery.

For MT SMS, the SMS is sent from the Amarisoft IMS screen.

The command format is:

           sms tel message

In this example, the command sends an SMS to tel number 600 with the message Test for MT SMS over IMS.

The number 600 should match one of the tel identities shown in the ims users result. This is how the IMS server knows which registered UE should receive the SMS.

After this command is executed, the Amarisoft IMS server generates an SMS over IMS message and delivers it to the UE through the current SIP binding. If the UE is properly registered to IMS and supports SMS over IMS, the message should appear in the UE messaging application.

After the sms command is sent from the Amarisoft IMS screen, the UE should receive the SMS in the phone messaging application.

In this example, the received message is shown from Amarisoft. The message body is Test for MT SMS over IMS, which is the same text that was entered in the Callbox IMS command.

This confirms that MT SMS over IMS is working. It means the Amarisoft IMS server could find the registered UE using the tel number, deliver the SMS through IMS signaling, and the UE could receive and display the message correctly.

At this point, both the IMS registration and the MT SMS delivery path are verified.

Log Analysis

MO SMS over IMS

Sample Log

Enable at least NAS, SIP, IMS in WebGUI log. Filter it out with NAS, SIP, IMS for convenience

First make sure that the UE has completed IMS registration.

In the Amarisoft Web GUI log, the SIP registration procedure can be seen in the IMS layer. The UE first sends SIP REGISTER to the IMS server. The server responds with 401 Unauthorized, which is normal in IMS registration. This response is used to trigger IMS authentication.

After that, the UE sends another SIP REGISTER with authentication information. The IMS server verifies it and returns 200 OK. This means the UE is successfully registered to the IMS server.

You may also see SUBSCRIBE and NOTIFY messages after registration. These are normal IMS signaling messages used for service status and registration event handling.

This step is important before testing SMS over IMS. If SIP REGISTER does not complete with 200 OK, the UE is not IMS-registered yet. In that case, MO SMS and MT SMS over IMS will not work, even if LTE attach and bearer setup are already successful.

The SIP MESSAGE is the SIP message that carries the SMS payload over IMS.

In this log, the MESSAGE is sent from the UE toward the IMS server. This is the MO SMS case because the SMS is originated by the mobile UE.

The IMS line shows SMS src=0600000000 dst=600 received. Here, src is the sender number and dst is the destination number. The word received means that the Amarisoft IMS server has received the SMS from the UE.

The right-side panel shows the decoded SMS contents. In this example, the decoded text is Test sms. This confirms that the SIP MESSAGE was not only received at the IMS server, but also decoded correctly as an SMS message.

So this log confirms the MO SMS path. The UE sent an SMS over IMS using SIP MESSAGE, and the Amarisoft IMS server received and decoded it successfully.

Right after the Amarisoft IMS server receives the MO SMS from the UE, it sends the same SMS message back to the UE.

In this setup, the Amarisoft IMS server also works as the SMS center. So when it receives the SMS from the UE, it generates an echo message and sends it back toward the UE.

In the log, SMS src=0600000000 dst=600 received shows the message received from the UE. Immediately after that, SMS src=0600000000 dst=600 sending shows the echoed message being sent back from the Callbox side.

The right-side panel shows the decoded SMS text. The text is Test sms, which is the same message that the UE originally sent.

This confirms that the MO SMS was successfully delivered to the Callbox SMS center and that the Callbox generated the echo SMS back to the UE.

MT SMS over IMS

Sample Log

MT SMS over IMS uses the same IMS registration procedure as MO SMS over IMS.

The important difference is the direction of the SMS message. In this case, the SMS is generated by the Amarisoft Callbox and sent toward the UE.

In the log, the IMS SMS line shows SMS src=Amarisoft dst=600 sent. The word sent indicates that this is an MT SMS case. It means the IMS server sent the SMS to the UE. The SIP MESSAGE line is the SIP message that actually carries the SMS payload over IMS. The right-side panel shows the decoded SMS contents. In this example, the text is Test for MT SMS over IMS. So this log confirms that the Callbox generated an SMS over IMS message, delivered it to the UE using SIP MESSAGE, and the UE received it successfully.