IoT LTE Cat - M1 UEsim
The purpose of this tutorial is to show you how to do basic connectivity test between a UEsim and Amari Callbox with LTE Cat-M1. The motivation of CatM1 is to implement a device that can achieve reliableconnection in low cost, low energy consumption. Followings are major technologies in Cat-M1 to achieve this goal.
- Reliable Connection : Repetitive transmission of Control and Data Channels
- Low Cost : Narrow Band, Low throughput requirement
- Low Energy Consumption : Long DRX
Table of Contents
Introduction
LTE Cat-M1, also known as LTE-M, is a pivotal cellular technology standard designed specifically for the fast-growing Internet of Things (IoT) ecosystem. Cat-M1 operates within the LTE network infrastructure and provides a tailored solution for low-power, low-cost devices that require reliable connectivity, such as smart meters, asset trackers, and wearable health monitors. Leveraging features such as reduced bandwidth (1.4 MHz), optimized signaling, and extended Discontinuous Reception (DRX) cycles, Cat-M1 enables devices to maintain extended battery life while supporting essential data transmission and mobile functionality. The Amari Callbox is a comprehensive LTE test platform that emulates network conditions and provides a controlled environment for evaluating the performance and interoperability of User Equipment simulators (UEsim) under Cat-M1 specifications. This tutorial guides you through the process of performing a basic connectivity test between a UEsim and an Amari Callbox, focusing on core Cat-M1 technologies that achieve reliability, cost-efficiency, and energy savings. Understanding and validating these connectivity mechanisms are crucial steps in the development and deployment of robust IoT solutions within the LTE landscape.
-
Context and Background
- LTE Cat-M1 Overview: A 3GPP standard designed for IoT devices, Cat-M1 provides a balance between cost, energy efficiency, and reliable connectivity, leveraging existing LTE networks with modifications for narrowband operation and power optimization.
- Amari Callbox: An LTE test system capable of simulating eNodeB and core network functionalities, allowing for comprehensive connectivity and performance testing in a controlled lab environment.
- UEsim: A User Equipment simulator that emulates LTE Cat-M1 device behavior, facilitating device-network interaction analysis without the need for physical hardware prototypes.
-
Relevance and Importance
- Validation of Cat-M1 Features: Ensures that IoT devices can reliably connect and operate within LTE networks while meeting stringent requirements for low power consumption and cost.
- Critical for IoT Deployments: Connectivity testing is essential for verifying device interoperability and network compliance, directly impacting device reliability in real-world applications.
-
Tutorial Objectives and Learning Outcomes
- Step-by-Step Connectivity Testing: Learn to configure and execute a basic Cat-M1 connectivity test between UEsim and Amari Callbox.
- Understanding Cat-M1 Technologies: Gain practical knowledge of repetitive transmission, narrowband operation, and DRX mechanisms for reliable, low-cost, and low-energy communication.
- Hands-On Skills: Develop the ability to analyze test results and troubleshoot common connectivity issues in Cat-M1 deployments.
-
Prerequisite Knowledge and Skills
- Basic Understanding of LTE Architecture: Familiarity with LTE network components, signaling, and device registration procedures is highly recommended.
- Experience with LTE Test Equipment: Prior exposure to tools like Amari Callbox and UEsim will be beneficial for following the tutorial effectively.
- Fundamental Networking Concepts: Knowledge of IP connectivity, wireless communication, and IoT device requirements will enhance comprehension.
Summary of the Tutorial
This tutorial outlines the step-by-step procedures for setting up and testing a Cat M1 UE simulator (UE sim) in conjunction with a call box (network simulator), with a focus on proper configuration, execution, and log analysis to validate the UE attach and registration process.
-
Test Setup and Configuration
- Ensure proper matching between UE sim configuration (ue-catm1.cfg) and Call box configuration (enb-catm1.cfg), using the provided configuration files without modification.
- If connecting to a different network or simulator, configure the UE sim to match the network's settings.
- Verify SIM information matches between UE sim and Call box.
-
Service Status Validation
- Check that the LTE service is running on the Call box by executing service lte status. If issues are detected, restart with service lte restart.
-
Screen Mode Operations
- Attach to screen sessions using screen -r for both UE sim and Call box consoles to facilitate simultaneous interaction.
- Familiarize with the command-line operations within screen mode for both UE sim and Call box as these will be used for most test procedures.
-
UE Attach Procedure
- Start tracing on the Call box to monitor the attach process.
- Power on the UE via UE sim and observe cell detection and SIB decoding messages.
- Once SIBs are decoded, monitor for successful initial attach on the Call box trace screen.
- Use cells command to verify cell registration and ue command on both (enb) and (mme) screens to check UE connectivity information.
-
Log Analysis
- Open /tmp/ue0.log on UE sim and /tmp/enb0.log on Call box for log review, using text editors such as nano.
- Analyze RRC and NAS signaling messages to confirm proper registration events and troubleshoot failures:
- SIB1 & SIB2: Examine for correct cell and radio resource configuration for Cat M1.
- Attach Request: Validate the UE's NAS capabilities and request parameters.
- RrcConnectionSetup: Confirm dedicated radio resource configuration for Cat M1 is sent by eNB.
- UE Capability Information: Verify the reported RRC capabilities of the UE.
- Attach Accept: Ensure network acceptance and activation of the default EPS bearer, including APN and PDN information.
- Use the log analysis to identify critical attach events and troubleshoot issues as needed. For detailed lower-layer analysis, the use of WebGUI is recommended.
In summary, the tutorial provides a comprehensive methodology for configuring, executing, and validating a Cat M1 UE attach procedure using a UE simulator and call box, with emphasis on configuration accuracy, service validation, hands-on test execution, and thorough log analysis for troubleshooting and verification purposes.
Test Setup
Test setup for this tutorial is as shown below.
Configuration
An important thing in using UE sim is to do proper matching between UE sim configuration and Call box configuration In this tutorial, I used the ue-catm1.cfg and and enb-catm1.cfg without any change
If you use other Network (e.g, other network simulator or real network), you have to make it sure to configure UE sim according to the settings on network side
On UEsim side I use the provided ue-catm1.cfg configuration with almost no modification.
On the Callbox side, I use the provided enb-catm1.cfg configuration.
On the Callbox core-network side, I use the provided mme-ims.cfg configuration without modification.
In the /root/mme/config/mme-ims.cfg file on the Callbox, the UE subscriber database is included with: 'include "ue_db-ims.cfg"',
This means the MME loads the subscriber information from ue_db-ims.cfg. Since this tutorial uses ue_db-ims.cfg without modification, the existing subscriber database configuration can be reused directly for the Cat-M1 UE connection test.
In this tutorial, the following SIM information is configured in the ue-catm1.cfg file on UEsim. The imsi parameter is set to 001010123456789 and the authentication key K is set to 00112233445566778899aabbccddeeff.
The UE is configured with as_release = 13 and ue_category = 13. UE category 13 corresponds to LTE Cat-M1, so this setting makes the simulated UE operate with the Cat-M1 capability profile.
The ue_count parameter is set to UE_COUNT, which determines the number of simulated UEs created from this configuration. For this basic connectivity test, the important values to match with the Callbox subscriber database are the IMSI and authentication key.
On the Callbox side, the basic LTE Cat-M1 cell configuration is defined in enb-catm1.cfg. In this example, TDD is set to 0, so the cell operates in FDD mode. N_RB_DL is set to 25, corresponding to a 5 MHz LTE carrier.
The N_COVERAGE_LEVEL parameter is set to 1, selecting one coverage level. The transmit and receive antenna configurations are both set to SISO with N_ANTENNA_DL = 1 and N_ANTENNA_UL = 1. CHANNEL_SIM is set to 0, so the channel simulator is disabled for this basic connectivity test.
In the cell_list block, plmn_list is set to 00101, which matches the PLMN portion of the IMSI configured on UEsim.
Since TDD is set to 0, the FDD configuration under the #else section is used. In this example, dl_earfcn is set to 3350, corresponding to a 2680 MHz downlink center frequency in LTE Band 7. The other dl_earfcn values shown in the configuration are alternative examples for different LTE bands but are commented out.
For this tutorial, the important point is that dl_earfcn = 3350 selects LTE Band 7 operation for the Cat-M1 cell.
On the UEsim side, the basic Cat-M1 radio configuration is defined in ue-catm1.cfg. TDD is set to 0, so the UE operates in FDD mode. CELL_BANDWIDTH is set to 5, corresponding to a 5 MHz LTE carrier and matching the Callbox configuration.
N_ANTENNA_DL and N_ANTENNA_UL are both set to 1, so the simulated UE uses a SISO configuration for both downlink and uplink. UE_COUNT is set to 1, meaning that one Cat-M1 UE is simulated in this test.
In the cell_groups block, group_type is set to "cat_m1", which configures this cell group for LTE Cat-M1 operation. The cells block then defines the radio parameters used by the simulated Cat-M1 UE.
Since TDD is set to 0, the FDD configuration is selected and dl_earfcn is set to 3350, corresponding to a 2680 MHz downlink center frequency in LTE Band 7. The bandwidth parameter uses CELL_BANDWIDTH, which was previously set to 5 MHz, while n_antenna_dl and n_antenna_ul use N_ANTENNA_DL = 1 and N_ANTENNA_UL = 1, resulting in SISO operation.
The multi_ue parameter is enabled, allowing several simulated UEs to be handled within the same cell group and supporting dynamic UE creation through the remote API.
Check if LTE service is Running
Before starting the Cat-M1 connectivity test, first confirm that the LTE service is running on both the Callbox and UEsim systems. The service status can be checked with:
service lte status
The output should show Active: active (running), confirming that the Amarisoft LTE service has started successfully. If the service is not running, the subsequent Cat-M1 connection test cannot proceed correctly
# service lte restart
Getting into Screen Mode
If it is confirmed that the lte service is running, go to screen mode by running 'screen -r' and follow through the steps as shown below. The steps shown here is the procedure that you would use for almost every test and it is highly recommended to get familiar with these steps. For further commands you can use in this screen mode, refer to the tutorial : Command Line Command
On the UEsim system, run the following command to reconnect to the existing Amarisoft screen session: screen -r This opens the running UEsim console so that you can monitor the Cat-M1 UE operation and check the connection procedure in real time.
After reconnecting to the screen session, the UEsim console is displayed. The startup output confirms that the UE is configured for LTE Band 7 with dl_freq = 2680.000 MHz and ul_freq = 2560.000 MHz.
The output also shows dl_ant = 1 and ul_ant = 1, confirming the SISO antenna configuration. At this point, UEsim is running with the Cat-M1 configuration and is ready to search for and connect to the Callbox cell.
On the Callbox system, run the following command to reconnect to the existing Amarisoft screen session: screen -r. This opens the running Callbox console, where you can monitor the LTE Cat-M1 cell operation and observe the UE connection procedure.
After reconnecting to the Callbox screen session, the ENB console is displayed. The startup output confirms that the Callbox is configured for LTE Band 7 with dl_freq = 2680.000 MHz and ul_freq = 2560.000 MHz, matching the UEsim configuration. The output also shows dl_ant = 1 and ul_ant = 1, confirming SISO operation.
The Callbox screen session contains several modules that can be selected independently. Press Ctrl+A first, then press the corresponding number key to switch modules. For example, Ctrl+A followed by 0 selects the MME screen, Ctrl+A followed by 1 selects the ENB screen, Ctrl+A followed by 3 selects IMS, and Ctrl+A followed by 4 selects MBMSGW. The currently selected module is indicated in yellow at the bottom of the screen.
Attach UE
Now perform UE attach procedure. This would be a little bit busy process since you need to switch back and forth between Callbox screen and UEsim screen.
On the Callbox ENB screen, enter the t command to start message tracing: t
After tracing starts, the console displays Press [return] to stop the trace. Keep the trace running while starting the Cat-M1 UE connection procedure so that the signaling exchange between the UE and the Callbox can be observed and analyzed.
On the UEsim screen, enter the power_on command to start the simulated Cat-M1 UE. power_on
The UE begins cell search and initiates the LTE access procedure toward the Callbox. Since tracing has already been enabled on the Callbox, you can now observe the Cat-M1 signaling sequence generated during UE attachment and registration.
After the UE is powered on, it starts searching for the configured LTE cell and decoding the broadcast system information. Once the cell is detected and the required SIBs are successfully decoded, the UEsim console displays: Cell 0: SIB found
This confirms that the Cat-M1 UE has successfully detected the Callbox cell and acquired its system information.
Once SIB decoding is completed, the UE starts the initial access and attach procedure. On the Callbox trace, you can first observe the PRACH transmission, showing that the Cat-M1 UE has initiated random access toward the cell.
After successful access, the UE appears in the trace with an assigned C-RNTI and the Callbox starts reporting downlink and uplink PHY statistics. In this example, UE_ID 1 is connected with C-RNTI 0x0961. The trace also shows parameters such as CQI, MCS, retransmission counters, bitrate, SNR, PUCCH quality, PHR, path loss, and timing advance, confirming that the Cat-M1 UE has successfully accessed the cell and is actively communicating with the Callbox.
After the initial attach is completed, you can use the 'cells' command on UEsim to check the serving-cell information
In this example, Cell #0 is identified as LTE-M and operates in FDD mode with PCI = 1. The output shows DL EARFCN = 3350 and UL EARFCN = 21350, with 25 resource blocks configured for both downlink and uplink. This confirms that the Cat-M1 UE has successfully registered on the expected LTE cell and is using the configured Band 7 carrier.
On the Callbox ENB screen, use the 'ue' command to check the UE currently connected to the cell.
The output lists the UE identifiers maintained by the Callbox. In this example, the connected UE has RAN_UE_ID = 5, CN_UE_ID = 104, is connected to Cell 0x001, and has RNTI = 0x0965. This confirms that the Cat-M1 UE has successfully completed the connection procedure and is registered in the Callbox UE context.
On the Callbox MME screen, use the 'ue' command to check the core-network registration information for the connected Cat-M1 UE.
The output shows the UE SUPI as 001010123456789, matching the IMSI configured in ue-catm1.cfg. REG is shown as Y, confirming that the UE is successfully registered with the core network. The output also shows PLMN 00101, TAC 0x1, one established bearer, and the assigned UE IP address 192.168.2.2.
This confirms that the Cat-M1 UE has completed the initial attach procedure and obtained a user-plane IP address from the Callbox core network.
Log Analysis
In this section, you will see how to confirm if UE registration is complete from trace log. You can use the same method to find any issues (e.g, registration failure) for troubleshooting. When UE registration fails, you may use this tutorial to figure out the point of the failure and troubleshoot
NOTE : This section is just to check quickly some important points in the log, but it may be a little bit tricky to do the detailed log analysis (especially for lower layer log analysis). In that case, I strongly recommend you to use WebGUI for the log analysis. You may refer to WebGUI Tutorial
To inspect the detailed signaling exchanged during the Cat-M1 connection procedure, open the UEsim log file /tmp/ue0.log with a text editor. In this tutorial, nano is used: nano /tmp/ue0.log
The log contains decoded protocol messages such as RRC signaling. In the example shown here, the log displays the BCCH SIB1 message received by the UE, including information such as the PLMN identity.
In the same way, you can inspect the Callbox eNB log by opening /tmp/enb0.log on the Callbox. This is useful when you need to analyze the connection procedure in more detail than what is shown in the real-time console trace.
In the SIB1 log, the parameters under bandwidthReducedAccessRelatedInfo-r13 are particularly important for LTE Cat-M1 operation.
The hyperSFN-r13 field provides the Hyper SFN information used for extended timing cycles. eDRX-Allowed-r13 = true indicates that eDRX operation is permitted in the cell. si-WindowLength-BR-r13 = ms40 defines a 40 ms system-information window for bandwidth-reduced UEs, while si-RepetitionPattern-r13 = every4thRF specifies the repetition pattern used for the Cat-M1 system information.
The schedulingInfoList-BR-r13 block provides the scheduling information for bandwidth-reduced system information. In this example, si-Narrowband-r13 = 1 identifies the narrowband used for the SI transmission, and si-TBS-r13 = b504 specifies the transport block size used for that system-information transmission.
These fields confirm that the cell is broadcasting LTE Cat-M1-specific system information in SIB1 and provide the UE with the information required to receive the corresponding bandwidth-reduced SI messages.
In the SIB2 log, you can check several LTE Cat-M1-specific parameters related to random access and uplink transmission.
The rach-CE-LevelInfoList-r13 block defines the random access configuration for coverage enhancement. In this example, firstPreamble-r13 = 0 and lastPreamble-r13 = 63 allow the full PRACH preamble range to be used for this CE level. ra-ResponseWindowSize-r13 = sf50 gives the UE a 50-subframe window to receive the Random Access Response, while mac-ContentionResolutionTimer-r13 = sf80 defines an 80-subframe contention resolution timer. preambleTransMax-CE-r13 = n10 allows up to 10 preamble transmissions for the coverage-enhanced random access procedure.
The PUSCH configuration also includes Cat-M1-related uplink settings. Here, n-SB = 1 indicates one uplink narrowband, hoppingMode is set to interSubFrame, and pusch-HoppingOffset is set to 8. These parameters control how the Cat-M1 UE uses the reduced-bandwidth uplink resources and frequency hopping for PUSCH transmission.
In this SIB2 section, several LTE Cat-M1 parameters define repetition and coverage-enhanced random access behavior.
For paging, mpdcch-NumRepetition-Paging-r13 is set to r1, meaning that MPDCCH paging is transmitted without additional repetition. For data transmission, pdsch-maxNumRepetitionCEmodeA-r13 = r16 allows up to 16 repetitions for PDSCH in CE Mode A, while pusch-maxNumRepetitionCEmodeA-r13 = r8 allows up to 8 repetitions for PUSCH. These repetition mechanisms are important for improving link reliability under weak coverage conditions.
The prach-ConfigCommon-v1310 block defines Cat-M1 PRACH operation. In this example, mpdcch-startSF-CSS-RA-r13 is set to v1 for FDD. The PRACH configuration uses prach-ConfigIndex-r13 = 4, prach-FreqOffset-r13 = 4, and prach-StartingSubframe-r13 = sf2. maxNumPreambleAttemptCE-r13 = n3 allows up to three CE preamble attempts, while numRepetitionPerPreambleAttempt-r13 = n1 means each preamble attempt is transmitted once. mpdcch-NarrowbandsToMonitor-r13 is set to narrowband 1, and mpdcch-NumRepetition-RA-r13 = r1 configures one MPDCCH repetition for the random access response scheduling.
In this SIB2 section, the pucch-ConfigCommon-v1310 block defines Cat-M1-specific PUCCH repetition behavior. The pucch-NumRepetitionCE-Msg4-Level0-r13 parameter is set to n1, meaning that one PUCCH repetition is configured for the Msg4-related HARQ acknowledgement at coverage enhancement level 0.
The ue-TimersAndConstants block also includes the Release 13 extended timers t300-v1310 and t301-v1310. In this example, both are set to ms5000, extending T300 and T301 to 5 seconds for Cat-M1 operation. These longer timer values give the bandwidth-reduced UE more time to complete connection establishment and re-establishment procedures, which can take longer when repetitions or coverage-enhancement mechanisms are used.
The NAS log shows the UE sending an EMM Attach Request as part of the initial LTE registration procedure. The EPS attach type is set to EPS attach, and the UE identifies itself with IMSI 001010123456789, matching the IMSI configured in ue-catm1.cfg.
The UE network capability field indicates the security algorithms and LTE capabilities supported by the simulated UE. Of particular interest for Cat-M1, the capability information shows CIoT-related indicators such as ePCO = 1, while CP CIoT and UP CIoT are not enabled in this configuration.
The Attach Request also carries an ESM PDN Connectivity Request. In this example, the UE requests an IPv4v6 PDN connection, which is used to establish packet-data connectivity during the attach procedure. This confirms that, after acquiring the Cat-M1 cell, the UE has progressed from RRC access into the NAS registration and PDN connectivity procedure.
The RRC log shows the UE sending an RRCConnectionRequest on CCCH to start the RRC connection establishment procedure.
In this message, ue-Identity is provided as a randomValue, which is typically used when the UE does not have a valid S-TMSI available for this access attempt. The establishmentCause is set to mo-Signalling, indicating that the connection is being established for mobile-originated signaling.
This is the first RRC message sent by the UE after successful random access and is followed by the RRCConnectionSetup procedure from the eNB.
The RRC log shows the eNB responding with RRCConnectionSetup, which provides the dedicated radio configuration required for the Cat-M1 UE to enter RRC Connected mode.
The highlighted mpdcch-Config-r13 block configures the Release 13 MPDCCH used by LTE Cat-M1. In this example, csi-NumRepetitionCE-r13 = sf1 configures the CSI-related repetition parameter, mpdcch-pdsch-HoppingConfig-r13 is disabled, mpdcch-StartSF-UESS-r13 is set to v1 for FDD, mpdcch-NumRepetition-r13 = r1 configures one MPDCCH repetition, and mpdcch-Narrowband-r13 = 1 selects narrowband 1 for MPDCCH operation.
The message also configures ce-Mode-r13 = ce-ModeA, indicating that the UE operates using Coverage Enhancement Mode A. This confirms that the dedicated RRC configuration delivered during connection establishment contains LTE Cat-M1-specific control-channel and coverage-enhancement settings.
The UE then sends RRCConnectionSetupComplete on DCCH to confirm that the RRC connection setup has been successfully applied.
The selectedPLMN-Identity field is set to 1, indicating the selected PLMN entry. More importantly, the dedicatedInfoNAS field carries the initial NAS signaling toward the core network. In this case, the NAS payload contains the Attach Request together with the embedded PDN Connectivity Request.
This message therefore completes the basic RRC connection establishment procedure and simultaneously transfers the UE's initial NAS registration request from the UE to the eNB for forwarding to the MME.
The next NAS exchange performs UE authentication. The MME first sends an Authentication Request containing the RAND challenge and AUTN authentication token. Using the SIM credentials configured in ue-catm1.cfg, the UE calculates the expected authentication result and returns an Authentication Response.
In this example, the UE successfully sends the Authentication Response with the calculated response parameter, indicating that the SIM credentials on UEsim match the subscriber information configured in the Callbox core network.
If the UE instead receives an Authentication Reject, one of the first items to check is whether the SIM authentication parameters, especially the IMSI and authentication key K, are consistent between ue-catm1.cfg and the Callbox subscriber database.
After successful authentication, the MME sends a Security Mode Command to activate NAS security. In this example, the selected NAS security algorithms are EEA0 for ciphering and EIA2 for integrity protection, as indicated by Selected NAS security algorithms = 0x02 (EEA0, EIA2).
The UE verifies the command and responds with Security Mode Complete. This confirms that the NAS security context has been successfully established between the UE and the MME.
The Security Mode Complete message also carries the IMEISV requested by the network. At this point, authentication and NAS security setup are complete, and the attach procedure can continue toward final registration and bearer establishment.
After NAS security is established, the eNB performs the RRC Security Mode procedure to activate security on the radio interface. The eNB sends an RRC SecurityModeCommand specifying cipheringAlgorithm = eea0 and integrityProtAlgorithm = eia2.
The UE applies the configured RRC security algorithms and responds with SecurityModeComplete. This confirms that AS security has been successfully activated between the UE and the eNB.
At this point, both NAS security toward the MME and RRC/AS security toward the eNB have been established, allowing the connection procedure to continue with protected signaling.
After RRC security is established, the eNB sends a UECapabilityEnquiry message to request the UE radio capability information. In this example, ue-CapabilityRequest contains eutra, so the UE is requested to report its LTE/E-UTRA capabilities.
The message also shows rrc-SegAllowed-r16 = enabled. This allows the UE capability information to be segmented when necessary, which is useful when the capability container becomes too large to be carried in a single RRC message.
The UE will respond with a UECapabilityInformation message containing its supported LTE features, including the Cat-M1-related capabilities configured in UEsim.
The UE responds with UECapabilityInformation containing its LTE/E-UTRA capability profile. Several fields in this message are especially relevant to Cat-M1 operation.
ue-CategoryDL-v1310 = m1 and ue-CategoryUL-v1310 = m1 confirm that the UE supports LTE Cat-M1 for both downlink and uplink. The ce-Parameters-r13 block shows ce-ModeA-r13 = supported, confirming support for Coverage Enhancement Mode A.
The mac-Parameters-v1310 block shows extendedLongDRX-r13 = supported, indicating support for extended DRX, which is one of the important Cat-M1 power-saving features.
The later capability extensions also show tm9-CE-ModeA-r13 = supported and tm6-CE-ModeA-r13 = supported, indicating support for these transmission modes when operating in CE Mode A.
Together, these capability fields confirm that the simulated UE is advertising the expected LTE Cat-M1 functionality to the eNB.
After the UE capability exchange, the eNB sends an RRCConnectionReconfiguration message to complete the UE configuration for the connected state.
In this example, the message contains dedicatedInfoNASList, which carries a NAS message from the core network transparently through the RRC layer to the UE. At this stage of the attach procedure, this NAS payload typically contains the Attach Accept together with the Activate Default EPS Bearer Context Request.
Therefore, this RRCConnectionReconfiguration message is an important step where the network delivers the final NAS registration and bearer-establishment information to the Cat-M1 UE.
The UE responds with RRCConnectionReconfigurationComplete to confirm that the configuration received in the preceding RRCConnectionReconfiguration message has been successfully applied.
The matching rrc-TransactionIdentifier = 0 associates this response with the corresponding reconfiguration command. At this point, the RRC reconfiguration procedure is complete, and the UE can continue with the remaining NAS attach and EPS bearer establishment steps.
The MME then sends an Attach Accept to confirm successful EPS registration. In this example, EPS attach result = 1 indicates EPS-only attachment.
The T3412 timer is set to 30 minutes. This timer controls periodic Tracking Area Update behavior and is related to how long the UE may remain registered before performing a periodic TAU; in IoT operation, related timer mechanisms are important for reducing unnecessary signaling and power consumption.
The Attach Accept also contains an Activate Default EPS Bearer Context Request. Here, EPS bearer identity 5 is created with QCI = 9, and the APN is default.mnc001.mcc001.gprs. The network assigns IPv4 address 192.168.2.2 to the UE, establishing the default packet-data connection.
The message also provides protocol configuration information such as the DNS server address 8.8.8.8. At this point, the UE has been accepted by the network and the default EPS bearer and IP connectivity parameters have been assigned.
The UE then sends an Attach Complete message to confirm successful completion of the EPS attach procedure.
The Attach Complete also contains an Activate Default EPS Bearer Context Accept for EPS bearer identity 5. This confirms that the UE has accepted the default EPS bearer configuration received in the Attach Accept message.
At this point, the Cat-M1 UE is fully registered with the EPC, the default EPS bearer is established, and the UE can use the assigned IP connection for user-plane data communication.
RRC / NAS Signaling
SIB1
: This is the SIB1 sent by eNB to configiture Cat M1 (
{
message c1: systemInformationBlockType1: {
cellAccessRelatedInfo {
plmn-IdentityList {
{
...
},
...
}
},
...
},
cellSelectionInfo {
...
},
p-Max 10,
freqBandIndicator 7,
schedulingInfoList {
...
},
si-WindowLength ms40,
systemInfoValueTag 0,
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
cellAccessRelatedInfo-v1250 {
},
nonCriticalExtension {
hyperSFN-r13 '0000001111'B,
eDRX-Allowed-r13 true,
bandwidthReducedAccessRelatedInfo-r13 {
si-WindowLength-BR-r13 ms40,
si-RepetitionPattern-r13 every4thRF,
schedulingInfoList-BR-r13 {
{
si-Narrowband-r13 1,
si-TBS-r13 b504
}
},
startSymbolBR-r13 3,
si-HoppingConfigCommon-r13 off
}
SIB2
: This is the SIB2 sent by eNB to configiture Cat M1 (
{
message c1: systemInformation: {
criticalExtensions systemInformation-r8: {
sib-TypeAndInfo {
sib2: {
radioResourceConfigCommon {
rach-ConfigCommon {
...
},
maxHARQ-Msg3Tx 5,
preambleTransMax-CE-r13 n10,
rach-CE-LevelInfoList-r13 {
{
preambleMappingInfo-r13 {
firstPreamble-r13 0,
lastPreamble-r13 63
},
ra-ResponseWindowSize-r13 sf50,
mac-ContentionResolutionTimer-r13 sf80,
rar-HoppingConfig-r13 off
}
}
},
bcch-Config {
...
},
pcch-Config {
...
},
prach-Config {
rootSequenceIndex 648,
prach-ConfigInfo {
prach-ConfigIndex 4,
highSpeedFlag FALSE,
zeroCorrelationZoneConfig 11,
prach-FreqOffset 4
}
},
pdsch-ConfigCommon {
...
},
pusch-ConfigCommon {
...
},
pucch-ConfigCommon {
...
},
soundingRS-UL-ConfigCommon setup: {
...
},
uplinkPowerControlCommon {
...
},
ul-CyclicPrefixLength len1,
pusch-ConfigCommon-v1270 {
enable64QAM-v1270 true
},
bcch-Config-v1310 {
modificationPeriodCoeff-v1310 n64
},
pcch-Config-v1310 {
paging-narrowBands-r13 1,
mpdcch-NumRepetition-Paging-r13 r1
},
freqHoppingParameters-r13 {
interval-ULHoppingConfigCommonModeA-r13 interval-FDD-r13: int1
},
pdsch-ConfigCommon-v1310 {
pdsch-maxNumRepetitionCEmodeA-r13 r16
},
pusch-ConfigCommon-v1310 {
pusch-maxNumRepetitionCEmodeA-r13 r8
},
prach-ConfigCommon-v1310 {
rsrp-ThresholdsPrachInfoList-r13 {
0
},
mpdcch-startSF-CSS-RA-r13 fdd-r13: v1,
prach-ParametersListCE-r13 {
{
prach-ConfigIndex-r13 4,
prach-FreqOffset-r13 4,
prach-StartingSubframe-r13 sf2,
maxNumPreambleAttemptCE-r13 n3,
numRepetitionPerPreambleAttempt-r13 n1,
mpdcch-NarrowbandsToMonitor-r13 {
1
},
mpdcch-NumRepetition-RA-r13 r1,
prach-HoppingConfig-r13 off
}
}
},
pucch-ConfigCommon-v1310 {
n1PUCCH-AN-InfoList-r13 {
38
},
pucch-NumRepetitionCE-Msg4-Level0-r13 n1
}
},
ue-TimersAndConstants {
t300 ms200,
t301 ms200,
t310 ms200,
n310 n6,
t311 ms10000,
n311 n5,
t300-v1310 ms5000,
t301-v1310 ms5000
},
freqInfo {
additionalSpectrumEmission 1
},
timeAlignmentTimerCommon infinity
},
Attach Request
: This is the AttachRequest sent by UE to inform UE capability for IoT NAS feature (
Protocol discriminator = 0x7 (EPS Mobility Management)
Security header = 0x0 (Plain NAS message, not security protected)
Message type = 0x41 (Attach request)
EPS attach type = 1 (EPS attach)
NAS key set identifier:
TSC = 0
NAS key set identifier = 7
Old GUTI or IMSI:
IMSI = 001010123456789
UE network capability:
0xe0 (EEA0=1, 128-EEA1=1, 128-EEA2=1, 128-EEA3=0, EEA4=0, EEA5=0, EEA6=0, EEA7=0)
0xe0 (EIA0=1, 128-EIA1=1, 128-EIA2=1, 128-EIA3=0, EIA4=0, EIA5=0, EIA6=0, EIA7=0)
0x00 (UEA0=0, UEA1=0, UEA2=0, UEA3=0, UEA4=0, UEA5=0, UEA6=0, UEA7=0)
0x00 (UCS2=0, UIA1=0, UIA2=0, UIA3=0, UIA4=0, UIA5=0, UIA6=0, UIA7=0)
0x00 (ProSe-dd=0, ProSe=0, H.245-ASH=0, ACC-CSFB=0, LPP=0, LCS=0, 1xSRVCC=0, NF=0)
0x80 (ePCO=1, HC-CP CIoT=0, ERw/oPDN=0, S1-U data=0, UP CIoT=0, CP CIoT=0, ProSe-relay=0, ProSe-dc=0)
ESM message container:
Protocol discriminator = 0x2 (EPS Session Management)
EPS bearer identity = 0
Procedure transaction identity = 1
Message type = 0xd0 (PDN connectivity request)
Request type = 1 (initial request)
PDN type = 3 (IPv4v6)
Protocol configuration options:
Ext = 1
Configuration protocol = 0
Protocol ID = 0x8021 (IPCP)
Data = 01 00 00 10 81 06 00 00 00 00 83 06 00 00 00 00
Protocol ID = 0x0001 (P-CSCF IPv6 Address Request)
Data =
Protocol ID = 0x0003 (DNS Server IPv6 Address Request)
Data =
Protocol ID = 0x000a (IP address allocation via NAS signalling)
Data =
Protocol ID = 0x000c (P-CSCF IPv4 Address Request)
Data =
Protocol ID = 0x000d (DNS Server IPv4 Address Request)
Data =
Voice domain preference and UE's usage setting = 0x05 (IMS PS Voice only, Data centric)
MS network feature support = 0x01 (MS supports the extended periodic timer in this domain)
RrcConnectionSetup
: This is the RrcConnectionSetup sent by eNB to configiture Cat M1 (
{
message c1: rrcConnectionSetup: {
rrc-TransactionIdentifier 0,
criticalExtensions c1: rrcConnectionSetup-r8: {
radioResourceConfigDedicated {
srb-ToAddModList {
...
},
mac-MainConfig explicitValue: {
...
},
physicalConfigDedicated {
...
},
soundingRS-UL-ConfigDedicated release: NULL,
schedulingRequestConfig setup: {
...
},
epdcch-Config-r11 {
config-r11 setup: {
setConfigToAddModList-r11 {
{
setConfigId-r11 0,
transmissionType-r11 distributed,
resourceBlockAssignment-r11 {
numberPRB-Pairs-r11 n2,
resourceBlockAssignment-r11 'E'H
},
dmrs-ScramblingSequenceInt-r11 1,
pucch-ResourceStartOffset-r11 0,
mpdcch-config-r13 setup: {
csi-NumRepetitionCE-r13 sf1,
mpdcch-pdsch-HoppingConfig-r13 off,
mpdcch-StartSF-UESS-r13 fdd-r13: v1,
mpdcch-NumRepetition-r13 r1,
mpdcch-Narrowband-r13 1
}
}
}
}
},
ce-Mode-r13 setup: ce-ModeA
}
UE Capability Information
: This is the UE Capability Information sent by UE to inform RRC capability for Cat M1 (
{
message c1: ueCapabilityInformation: {
rrc-TransactionIdentifier 0,
criticalExtensions c1: ueCapabilityInformation-r8: {
ue-CapabilityRAT-ContainerList {
{
rat-Type eutra,
ueCapabilityRAT-Container {
accessStratumRelease rel13,
ue-Category 1,
pdcp-Parameters {
...
}
},
phyLayerParameters {
...
},
rf-Parameters {
...
},
measParameters {
bandListEUTRA {
...
}
},
featureGroupIndicators '4E001002'H /*
2: PUCCH 2a/2b, abs TPC, RB alloc type 1 for PDSCH, Periodic CQI/PMI/RI reporting on PUCCH: Modes 2-0 and 2-1
5: Long DRX cycle, DRX Mac CE
6: Prioritized bit rate
7: RLC UM
20: SRB1 and SRB2 for DCCH + 8x DRB
31: MFBI
*/,
interRAT-Parameters {
},
nonCriticalExtension {
phyLayerParameters-v920 {
},
interRAT-ParametersGERAN-v920 {
},
csg-ProximityIndicationParameters-r9 {
},
neighCellSI-AcquisitionParameters-r9 {
},
son-Parameters-r9 {
},
nonCriticalExtension {
lateNonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
ce-Parameters-v1370 {
tm9-CE-ModeA-r13 supported
},
nonCriticalExtension {
ce-Parameters-v1380 {
tm6-CE-ModeA-r13 supported
},
fdd-Add-UE-EUTRA-Capabilities-v1380 {
ce-Parameters-v1380 {
}
},
tdd-Add-UE-EUTRA-Capabilities-v1380 {
ce-Parameters-v1380 {
}
...
},
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
pdcp-Parameters-v1130 {
},
phyLayerParameters-v1130 {
tdd-SpecialSubframe-r11 supported
},
rf-Parameters-v1130 {
},
measParameters-v1130 {
},
interRAT-ParametersCDMA2000-v1130 {
},
otherParameters-r11 {
},
nonCriticalExtension {
nonCriticalExtension {
rf-Parameters-v1180 {
freqBandRetrieval-r11 supported
},
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
ue-CategoryDL-v1310 m1,
ue-CategoryUL-v1310 m1,
pdcp-Parameters-v1310 {
},
rlc-Parameters-v1310 {
},
mac-Parameters-v1310 {
extendedLongDRX-r13 supported
},
ce-Parameters-r13 {
ce-ModeA-r13 supported
},
interRAT-ParametersWLAN-r13 {
},
wlan-IW-Parameters-v1310 {
},
lwip-Parameters-r13 {
}
....
},
nonCriticalExtension {
nonCriticalExtension {
ue-RadioPagingInfo-r12 {
ue-CategoryDL-v1310 m1,
ce-ModeA-r13 true
}
Attach Accept
: This is the AttachAccept sent by UE to inform NW capability for IoT NAS feature and Activate Default EPS Bearer(
Protocol discriminator = 0x7 (EPS Mobility Management)
Security header = 0x2 (Integrity protected and ciphered)
Auth code = 0x63483d18
Sequence number = 0x01
Protocol discriminator = 0x7 (EPS Mobility Management)
Security header = 0x0 (Plain NAS message, not security protected)
Message type = 0x42 (Attach accept)
EPS attach result = 1 (EPS only)
T3412 value:
Value = 30
Unit = 1 (1 minute)
TAI list:
Length = 6
Data = 00 00 f1 10 00 01
ESM message container:
Protocol discriminator = 0x2 (EPS Session Management)
EPS bearer identity = 5
Procedure transaction identity = 1
Message type = 0xc1 (Activate default EPS bearer context request)
EPS QoS:
QCI = 9
Access point name = "default.mnc001.mcc001.gprs"
PDN address:
PDN type = 1 (IPv4)
IPv4 = 192.168.2.2
ESM cause = 0x32 (PDN type IPv4 only allowed)
Extended protocol configuration options:
Ext = 1
Configuration protocol = 0
Protocol ID = 0x8021 (IPCP)
Data = 03 00 00 0a 81 06 08 08 08 08
Protocol ID = 0x000d (DNS Server IPv4 Address)
Data = 8.8.8.8
GUTI:
MCC = 001
MNC = 01
MME Group ID = 32769
MME Code = 1
M-TMSI = 0x275be002
Emergency number list:
Length = 8
Data = 03 1f 19 f1 03 1f 11 f2
EPS network feature support:
0x01 (CP CIoT=0, ERw/oPDN=0, ESRPS=0, CS-LCS=0, EPC-LCS=0, EMC BS=0, IMS VoPS=1)
0x08 (15 bearers=0, IWK N26=0, RestrictDCNR=0, RestrictEC=0, ePCO=1, HC-CP CIoT=0, S1-U data=0, UP CIoT=0)