Amarisoft

LTE CMAS

This tutorial shows how to test LTE CMAS on Amari Callbox with a commercial phone. CMAS stands for Commercial Mobile Alert System. It is a type of PWS (Public Warning System). Basic RAN Process of LTE CMAS is as follows :

In real deployment, this process is controlled by CMAS server in core network side.  It is the CMAS server and Core Network which are triggering the whole CMAS process and RAN to transmit the message.

NOTE :  In 2G/3G, there was similar feature like PWS. It is called CBS (Cell Broadcasting System). The logic on core network side logic in CBS would be similar to PWS in LTE, but RAN side implementation of CBS is different from PWS in LTE. In LTE, we don't use any specifically dedicated channel for this and just use one of the existing channel (BCCH - PDSCH) whereas we use specially dedicated channel (CTCH - FACH-SCCPCH) for CBS.

NOTE :  Amarisoft does not support any of 2G/3G (i.e, GSM,CDMA,WCDMA,HSPA) and 2G/3G related function.

Table of Contents

Introduction

The Commercial Mobile Alert System (CMAS) is a critical component of modern Public Warning Systems (PWS), enabling authorities to disseminate urgent alerts such as severe weather warnings, AMBER alerts, or national emergencies to mobile users over wireless networks. In LTE (Long-Term Evolution) networks, CMAS leverages the radio access network (RAN) to deliver these broadcast messages efficiently and reliably. The primary mechanism involves transmitting System Information Block Type 12 (SIB12) containing the CMAS message, followed by a paging procedure to notify User Equipment (UE), such as commercial smartphones, to decode and display the alert. In a real-world deployment, the orchestration of these procedures is managed by the CMAS server within the core network, which triggers the RAN to execute the broadcast. Unlike legacy 2G/3G technologies that relied on the Cell Broadcasting System (CBS) and dedicated channels (e.g., CTCH over FACH-SCCPCH), LTE implements PWS using existing broadcast channels, specifically the Broadcast Control Channel (BCCH) mapped to the Physical Downlink Shared Channel (PDSCH), optimizing both efficiency and spectrum usage. The Amari Callbox, an advanced LTE network emulator, enables controlled, repeatable testing of CMAS functionality with commercial handsets, providing valuable insights into end-to-end system behavior and compliance. Notably, Amarisoft's solution focuses exclusively on LTE and does not support legacy 2G/3G technologies, making it ideal for modern wireless alerting system validation. Mastery of LTE CMAS testing with the Amari Callbox is essential for network engineers, test designers, and service providers aiming to ensure robust public warning capabilities in next-generation mobile networks.

Summary of the Tutorial

This tutorial details the step-by-step procedures for conducting a CMAS (Commercial Mobile Alert System) test over LTE, including system setup, configuration, test execution, and log analysis. The summary below encapsulates the main test procedures and methodologies as presented in the tutorial.

This process ensures that the LTE system is correctly configured to broadcast CMAS messages and that UEs can properly receive and alert on those messages, with complete verification via log analysis and signaling inspection.

Test Setup

Test setup for this tutorial is as shown below.  

TestSetup Callbox UE 1sdr 01

Key Configuration Parameters

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

Configuration

I used the enb.default.cfg (LTE default configuration) as it is without changing any contents in it. Basically you can use any kind of enb configuration. eNB does not require any specific configuration for CMAS.

LTE CMAS Config 01

I also used mme-ims-cmas.cfg which was copied and modified from mme-ims.cfg.

LTE CMAS Config 02

In mme-ims-cmas.cfg I have added the following configuration. pws_msgs is the parameter where you can configure the details of CMAS.

The pws_msgs parameter is where the PWS warning message is defined, and in this example it is used to configure one CMAS test message. local_identifier: 2 is the local identifier used internally for this warning message entry, message_identifier: 0x1112 indicates the CMAS message type, serial_number: 0x3000 identifies this specific warning message instance, and data_coding_scheme: 0x0f defines the character coding scheme used for the warning text. The actual CMAS message text is configured under warning_message, and in this example the UE is expected to receive and display the text “this is a CMAS test message”.

The configured block is placed in the MME configuration file because CMAS/PWS message control is handled from the core-network side and then delivered toward the LTE RAN. Once this configuration is loaded, the Amarisoft system can generate the corresponding LTE warning message procedure, where SIB12 carries the CMAS message contents and Paging is used to notify the UE that a warning message is available.

LTE CMAS Config 03

Perform the test

Start the LTE service and check the basic cell configuration. Any LTE cell configuration can be used for this test as long as the cell is properly running and the commercial UE can camp on it. In this example, the command cell phy shows that cell 0x001 is configured as an LTE cell on Band 7 with 5 MHz bandwidth, DL ARFCN 3350, UL ARFCN 21350, 2 DL antennas, 2 UL antennas, 15 kHz subcarrier spacing, 256QAM for downlink, and 64QAM for uplink. This confirms that the LTE PHY layer is active with a valid FDD LTE radio configuration.

Then check the higher-level cell configuration with the cell command. In this example, the output shows PLMN=00101, eNB ID=0x1a2d0, TAC=0x0001, EARFCN=3350, PCI=1, PRACH sequence index=204, DL gain=0.0, and ul_dis=N. The important point here is not the specific band, EARFCN, PCI, or TAC value, but that the LTE cell is active and broadcasting a valid PLMN so that the UE can detect the cell, camp on it, and receive the CMAS-related SIB and Paging messages.

LTE CMAS Run 01

Power on the UE and let the UE attach to the LTE cell. After the UE detects the cell and starts the access procedure, run the t command on the eNB console to monitor the live UE trace. In this example, the trace first shows a PRACH detection from cell 01 with sequence 23, timing advance value ta=2, and SNR around 22 dB, which means the UE has transmitted random access preamble and the eNB has detected it successfully.

After the UE is connected, the trace shows one active UE entry with RNTI 003d. The downlink and uplink statistics are continuously updated, including CQI, RI, MCS, retransmission count, throughput, SNR, PUCCH quality, received OK/NOK counters, PH, path loss, and timing advance. The important point in this step is not the exact throughput or MCS value, but that the UE has successfully attached to the LTE cell and has a valid RNTI. Once the UE is attached and reachable from the eNB side, it is ready to receive the CMAS-related Paging and SIB12 transmission.

LTE CMAS Run 02

Confirm that the UE is attached to the MME by running the ue command on the MME console. In this example, the UE is listed with SUPI 001010123456789 and IMEISV 8690570563562913, and CN shows EPC, which confirms that the UE is attached through LTE EPC. The REG field is Y, meaning the UE is registered, and the M-TMSI value 0x52c3793f shows that the UE has been assigned a temporary identity by the network. The output also shows TAC 0x1, two bearers, and assigned IP addresses such as 192.168.3.2 and 192.168.4.2. The important point in this step is that the UE is not only connected at the radio level, but also successfully registered to the core network, so the CMAS/PWS procedure can be triggered toward this UE through the LTE system.

LTE CMAS Run 03

Send the CMAS message using the pws_write command on the MME console. In this example, the command is pws_write 2, where the value 2 corresponds to local_identifier: 2 configured under pws_msgs in mme-ims-cmas.cfg. This means the MME selects the CMAS/PWS message entry whose local identifier is 2 and triggers the warning message transmission procedure for that configured message.

Once this command is executed, Amarisoft starts the CMAS delivery procedure toward the LTE RAN. The eNB then broadcasts the CMAS warning contents through SIB12 and sends Paging to notify the UE that a warning message is available. The important point is that pws_write does not directly contain the warning text itself; it only points to the preconfigured pws_msgs entry, and the actual message contents such as message_identifier, serial_number, data_coding_scheme, and warning_message are taken from the configuration file.

LTE CMAS Run 04

Check the UE screen and confirm that the CMAS message is received as shown below. In this example, the UE displays a Presidential alert popup, and the message body shows the configured warning text, “this is a CMAS test message”. This confirms that the CMAS message configured in pws_msgs was successfully delivered to the UE and decoded by the phone.

You should also confirm that the UE generates the alert sound. For CMAS testing, it is not enough to check only the text popup on the screen. The expected UE behavior is to display the warning message and generate the emergency alert sound. Therefore, both the visible CMAS text message and the audible alarm sound should be verified as part of the test result.

LTE CMAS Run 06

You can stop the active CMAS message using the pws_kill command on the MME console. In this example, the command is pws_kill 2, where the value 2 corresponds to local_identifier: 2 configured under pws_msgs in mme-ims-cmas.cfg. This tells the MME to terminate the warning message associated with that local identifier.

This command is useful when you want to stop the currently active CMAS/PWS transmission after confirming that the UE received the message and generated the alert. As with pws_write, the number used in pws_kill is not the message identifier or serial number. It is the local identifier used by Amarisoft to select the specific pws_msgs entry from the configuration file.

LTE CMAS Run 05

Log Analysis

Sample Log

Since the CMAS message is delivered through LTE system information, the first step of CMAS log analysis is to capture the log with BCCH and RRC enabled. BCCH is required because SIB12 is transmitted as a broadcast system information message, and RRC is required because the decoded SIB contents and the related RRC-level signaling can be checked from the log. In the Amarisoft Web GUI, open the ENB log configuration and make sure that BCCH is enabled and that RRC logging is also enabled with payload capture. Without BCCH logging, you may not see the SIB12 broadcast clearly, and without RRC payload logging, it may be difficult to confirm the actual CMAS message contents carried in the system information.

For this test, the most important log points are Paging and SIB12. Paging is used to notify the UE that the system information has changed or that warning message information is available, and SIB12 carries the CMAS warning message itself. Therefore, during log analysis, you should first check whether Paging is transmitted after the pws_write command, and then check whether SIB12 is broadcast with the CMAS message configured in pws_msgs. If both Paging and SIB12 are observed in the log, and the UE displays the alert popup with the correct message text, it confirms that the CMAS procedure is working correctly from both the network side and the UE side.

LTE CMAS Log 01

Set the log layer filter as shown below to make CMAS log analysis easier. Since the complete log may contain many PHY, MAC, NAS, S1AP, and other protocol messages, it is useful to narrow down the displayed layer to the messages that are most relevant to CMAS. For this test, RRC and SBCAP are the most useful layers. RRC is needed to check Paging and SIB12 transmission from the LTE RAN side, and SBCAP is useful to check the warning message control procedure between the MME and the eNB.

In the example, the layer filter menu shows several protocol layers such as MAC, NAS, PDCP, PHY, RLC, RRC, S1AP, S6, and SBCAP. For CMAS analysis, selecting RRC allows you to focus on the radio-side messages such as Paging and BCCH/SIB transmission, while selecting SBCAP allows you to check the PWS-related control messages such as Write Replace Warning Request, Allocate Warning Context, and Free Warning Context. This filtering does not change the actual test procedure; it only makes the log easier to read by hiding unrelated messages and allowing you to focus on the CMAS delivery flow.

LTE CMAS Log 02

When you send the CMAS message using the pws_write command, the core network starts the CMAS/PWS delivery procedure as shown below. In the log, the first important message is the SBCAP Write Replace Warning Request from the MME to the eNB. This message carries the CMAS warning information that was configured under pws_msgs in mme-ims-cmas.cfg.

In the decoded SBCAP message, id-Message-Identifier shows 1112H, which corresponds to message_identifier: 0x1112 in the configuration. id-Serial-Number shows 3001H in this log, which identifies this specific warning message instance. id-Repetition-Period is set to 10, and id-Number-of-Broadcasts-Requested is set to 65535, meaning the warning message is requested to be broadcast repeatedly. id-Data-Coding-Scheme is 0FH, which corresponds to data_coding_scheme: 0x0f in the configuration. id-Warning-Message-Content carries the encoded warning text, and this is the part that eventually becomes the CMAS message displayed on the UE.

After receiving the Write Replace Warning Request, the eNB allocates the warning context and sends Write Replace Warning Response back to the MME. In the log you can also see Allocate Warning Context and Free Warning Context around the SBCAP exchange. After this SBCAP procedure, the RRC log shows repeated Paging messages on PCCH and SIB transmissions on BCCH. This means the core network has delivered the CMAS request to the eNB, and the eNB has started the LTE radio-side broadcast procedure so that the UE can be notified by Paging and read the CMAS contents from SIB12.

LTE CMAS Log 03

When the core network sends the CMAS request to the eNB, the eNB starts sending Paging with cmas-Indication. This is the radio-side notification step that tells the UE that CMAS warning information is available and that the UE should read the related system information.

In the RRC log, the selected message is Paging on PCCH. In the decoded Paging message, you can see nonCriticalExtension and cmas-Indication-r9 true. This field is the key indication for CMAS. It does not carry the CMAS text message itself. Instead, it informs the UE that a CMAS message is being broadcast, so the UE should acquire the corresponding SIB, especially SIB12, to decode the actual warning message contents.

The important point in this log is that the eNB sends Paging immediately after the SBCAP Write Replace Warning Request procedure. This confirms that the core-network CMAS request has been converted into the LTE air-interface notification procedure. After receiving this Paging with cmas-Indication, the UE checks the broadcast system information and reads SIB12 to obtain the CMAS warning message.

LTE CMAS Log 04

The CMAS message is broadcast through SIB12. SIB12 carries the actual CMAS warning contents that were configured by the pws_msgs parameter in the configuration file. In this log, the selected RRC message is a BCCH SIB message, and the decoded contents show sib12-v920. Inside SIB12, messageIdentifier-r9 is 1112H, serialNumber-r9 is 3001H, warningMessageSegmentType-r9 is notLastSegment, warningMessageSegmentNumber-r9 is 0, warningMessageSegment-r9 contains the encoded warning message text, and dataCodingScheme-r9 is 0FH. These values correspond to the CMAS message configuration in pws_msgs.

The important point is that Paging with cmas-Indication only tells the UE that CMAS warning information is available, but the actual CMAS message is delivered by SIB12. Therefore, if you want to modify the CMAS message text, message identifier, serial number, data coding scheme, or other SIB12-related CMAS contents for testing, you should modify the corresponding fields under pws_msgs in the configuration file. After changing the configuration and restarting or reloading the related service as needed, the updated CMAS information will be reflected in the SIB12 broadcast.

LTE CMAS Log 05

RRC / NAS Signaling

SIB 12

: This is the SIB 12 message sent by eNB  to configure CMAS. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

{

  message c1: systemInformation: {

    criticalExtensions systemInformation-r8: {

      sib-TypeAndInfo {

        sib12-v920: {

          messageIdentifier-r9 '1112'H,

          serialNumber-r9 '3001'H,

          warningMessageSegmentType-r9 notLastSegment,

          warningMessageSegmentNumber-r9 0,

          warningMessageSegment-r9 '0174747A0E4ACF4161D0B0199C82E8E5391DD42ECFE7E1731900000000000000'H,

          dataCodingScheme-r9 '0F'H

        }

      }

Paging

: This is the Paging message sent by eNB  to Notify that CMAS is transmitted. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

 

{

  message c1: paging: {

    nonCriticalExtension {

      nonCriticalExtension {

        cmas-Indication-r9 true

      }

    }

  }

}

© 2025 All rights reserved | Legal notice |