LTE - CDRX

The purpose of this tutorial is to show you how to configure CDRX. CDRX is one of the mechanisms that are designed to save energy consumpion on UE side. The general logic is to allow UE to go to sleep when there is no data to be received and transmit for a certain time duration. While UE is in sleep (i.e, turning off large portions of PHY process), it can save the energy consumption.

Then what if there is some data to be received short after it gets into the sleep ? CDRX is bascially operate in cylic mode repeating sleep and wake-up. If there is any data to be received by UE while it is in sleep mode, eNB will schedule it in next wake-up cycle. If there is continuous data to be received during the wake-up time, UE would not get into the sleep mode until all the continuous data are received.

This is just to show how to configure CDRX parameters, but it is almost impossible to verify that it is really working as expected. The verification of CDRX should be done on UE side. A few typical ways to verify the CDRX operation on UE side are as follows.

• Check UE log especially on Clocks and PHY processing : When UE gets into sleep mode, a lot of clocks (usually PHY processing related clocks) stops and PHY/MAC processing gets minimized.
• Measure the current consumption : The surest way is to measure the current consumption on UE with high sample rate test equipment. If UE really gets into DRX sleep mode, you may get the current consumption profile something like this.

Image Source : Sharetechnote

Table of Contents

• LTE - CDRX
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Test 1 : CDRX - Long/Short Cycle
• Configuration
• Perform the Test
• Log Analysis

Introduction

Connected Discontinuous Reception (CDRX) is a sophisticated energy-saving mechanism employed within modern wireless communication systems, particularly in LTE and 5G networks. Its primary objective is to reduce power consumption on the User Equipment (UE) side by strategically alternating between active (wake) and inactive (sleep) states based on data transmission needs. Architecturally, CDRX is built into the radio resource control protocol layer, enabling the UE to temporarily power down substantial portions of its physical layer (PHY) processing circuitry when there is no data to be transmitted or received. This process operates in a cyclic manner: the UE periodically wakes at predefined intervals to check for incoming data, then returns to a low-power state if no activity is detected. The eNodeB (eNB) or gNodeB (gNB) coordinates the scheduling of downlink data, ensuring that transmissions are aligned with the UE’s active periods. If data arrives during a sleep phase, it is buffered at the network side and delivered in the next scheduled wake-up cycle. This mechanism is crucial for extending battery life in mobile devices, especially in scenarios where data traffic is intermittent. However, the configuration and optimization of CDRX parameters—such as sleep and wake timers—require careful balancing to avoid negative impacts on latency and user experience. Due to its operation at the lower layers and the complexity of real-world wireless environments, direct verification of CDRX functionality is challenging and typically conducted through device-side logging and current consumption measurements. Configuring CDRX effectively is fundamental for network engineers and device manufacturers aiming to maximize UE energy efficiency without sacrificing connectivity or quality of service.

• Context of CDRX Technology
  • Energy Efficiency in Modern Wireless Networks: CDRX is a key feature in LTE and 5G designed to optimize UE battery life by minimizing unnecessary PHY and MAC processing.
  • Operational Principles: Utilizes a cyclic sleep-wake pattern, orchestrated by the eNB/gNB, to balance energy savings with timely data delivery.
  • Architectural Placement: Implemented at the radio resource control and PHY layers, integrating deeply with scheduling and power management frameworks.
• Relevance and Importance of This Tutorial
  • Practical Configuration Guidance: Demonstrates how to configure CDRX parameters to achieve optimal trade-offs between power efficiency and network responsiveness.
  • Industry Significance: Essential for device OEMs, network engineers, and field testers responsible for deploying and optimizing LTE/5G solutions.
  • Real-World Impact: Proper CDRX configuration can substantially extend device battery life, especially in IoT and mobile broadband applications.
• Learning Outcomes
  • Understand CDRX Operation: Gain in-depth knowledge of how CDRX cycles function and interact with both the UE and network infrastructure.
  • Master CDRX Parameter Tuning: Learn to configure and fine-tune sleep, wake, and inactivity timers for specific network scenarios.
  • Verification Techniques: Acquire practical skills for verifying CDRX functionality using UE logging and current measurement methodologies.
  • Troubleshooting: Identify common pitfalls and remedies when configuring or testing CDRX in lab and field environments.
• Prerequisite Knowledge and Skills
  • Technical Background: Familiarity with LTE/5G cellular architecture, including concepts such as eNB/gNB, PHY, MAC, and RRC layers.
  • Protocol Understanding: Basic knowledge of radio resource management and power-saving mechanisms in mobile networks.
  • Analytical Skills: Ability to interpret device logs and analyze power consumption profiles.
  • Equipment Proficiency: Experience with test equipment for current measurement and UE logging tools is beneficial for practical verification.

Summary of the Tutorial

This tutorial details the procedures for testing Connected Mode Discontinuous Reception (CDRX) with both Long and Short DRX cycles in LTE using Amarisoft equipment. The summary below highlights the necessary configuration steps, test execution, and log analysis methodology.

• Test 1: CDRX - Long/Short Cycle
  • Configuration Steps:
    • Begin by copying and modifying the enb.default.cfg to create enb-cdrx.cfg. For the MME, use mme-ims.cfg without modifications.
    • Set up the LTE cell with your preferred configuration (e.g., FDD mode, 5 MHz bandwidth with N_RB_DL = 25), but ensure consistency with your test requirements.
    • Enable CDRX by configuring the drx_config parameter in mac_config. Key parameters include:
    • on_duration_timer
    • drx_inactivity_timer
    • drx_retransmission_timer
    • long_drx_cycle
    • short_drx_cycle
    • drx_short_cycle_timer
    • Optionally, increase the inactivity_timer to prevent the eNB from releasing the RRC connection before the test concludes.
  • Test Execution:
    • Check the physical configuration of the cell using the cell phy command to ensure all settings are correct.
    • Power on the User Equipment (UE) and verify successful cell attachment.
    • Confirm that the CDRX configuration is applied by reviewing the logs.
  • Log Analysis:
    • Use trace logs to verify UE registration and diagnose any issues, such as registration failures.
    • For in-depth analysis, utilize the WebGUI as recommended in the tutorial.
    • Prior to testing, confirm that the UE supports CDRX in its capabilities, specifically in the featureGroupIndicator (FGI) of the UE capability information.
    • If the UE does not indicate CDRX support in its capabilities, the Amarisoft eNB will not enable CDRX, regardless of the configuration file settings.
    • Initially, CDRX will not be configured during RRC connection setup (as indicated by drx-Config release in mac-MainConfig IE).
    • Once UE capability is confirmed, and if both UE and eNB support CDRX, the eNB enables CDRX through RRC Connection Reconfiguration (visible as drx-Config of mac-MainConfig IE).

This test procedure ensures thorough validation of CDRX configuration and operation by combining systematic setup, execution, and comprehensive log analysis.

Test Setup

Test setup for this tutorial is as shown below.

Key Configuration Parameters

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

• drx_config: In this link, you would get the descriptions for all the items listed below
• on_duration_timer
• drx_inactivity_timer
• drx_retransmission_timer
• drx_ul_retransmission_timer
• long_drx_cycle
• short_drx_cycle
• drx_short_cycle_timer

Test 1 : CDRX - Long/Short Cycle

This Test is to show how to configure CDRX with both Long and Short DRX cycle in LTE.

Configuration

In this tutorial, I used enb-cdrx.cfg which is copied and modified from enb.default.cfg.

For mme, I used mme-ims.cfg without any change.

Following is the configuration in enb-cdrx.cfg

This part is not directly related to CDRX, but it defines the radio condition for this test. In this example, the test uses the default LTE configuration with FDD mode and 5 MHz bandwidth, so the CDRX behavior can be checked in a simple baseline setup.

N_CELL is set to 2 and should not be changed because the same value is also used in rf_driver/config.cfg. TDD is set to 0, meaning the cell operates in FDD mode. N_RB_DL is set to 25, which corresponds to 5 MHz LTE bandwidth. N_ANTENNA_DL and N_ANTENNA_UL are both set to 1, so this is a SISO configuration. CHANNEL_SIM is set to 0, meaning the channel simulator is disabled. CQI_CONFIG is set to 1, meaning aperiodic CQI is used.

Overall, this configuration creates a simple LTE FDD 5 MHz SISO cell. After this baseline cell configuration is fixed, the later part of the file can focus on the actual CDRX parameters such as Long DRX cycle, Short DRX cycle, onDurationTimer, and drx-InactivityTimer.

To enable CDRX, drx_config should be configured inside mac_config. This block defines how long the UE stays awake, how long it waits before entering DRX after traffic stops, and how the UE moves between Short DRX and Long DRX cycle.

In this example, on_duration_timer is set to 6, which defines the wake-up duration where the UE monitors PDCCH in each DRX cycle. drx_inactivity_timer is set to 1920, meaning the UE keeps monitoring PDCCH for this duration after the last scheduling activity before it can enter DRX operation. drx_retransmission_timer is set to 16, which keeps the UE awake for possible retransmission-related scheduling. long_drx_cycle is set to 1280 and this defines the longer sleep/wake-up repetition cycle used for stronger power saving. short_drx_cycle is set to 10 and drx_short_cycle_timer is also set to 10, meaning the UE can first use a shorter DRX cycle for a limited time before moving into the Long DRX cycle.

Overall, this configuration enables both Short DRX and Long DRX. After traffic becomes inactive, the UE does not immediately go into the longest sleep cycle. It first follows the Short DRX cycle, and if there is still no further scheduling activity, it finally moves into the Long DRX cycle for better power saving.

This configuration is not mandatory for enabling CDRX, but it is useful for the test. The inactivity_timer is extended to 60000 ms so that the eNB does not release the RRC connection too early while you are trying to observe CDRX behavior.

Without this change, the UE may be released from RRC Connected state before the CDRX test is completed, and then it becomes difficult to confirm whether the UE is entering Short DRX or Long DRX properly. By keeping the RRC connection alive longer, the UE can remain in connected mode and the DRX operation can be tested more reliably.

Perform the Test

Before starting the actual CDRX test, first check whether the physical cell configuration is applied as intended by using the cell phy command. This command shows the current LTE cell configuration from the PHY point of view, so it is useful to confirm basic settings such as RAT, bandwidth, antenna configuration, ARFCN, subcarrier spacing, and modulation capability.

In this example, the cell is shown as LTE with bandwidth 5 MHz, which matches N_RB_DL = 25 in the configuration. The downlink ARFCN is 3350 and the uplink ARFCN is 21350. The antenna configuration also shows 2 downlink antennas and 1 uplink antenna in this runtime output. This is the actual configuration currently applied by the system, so it is always better to confirm with this command rather than relying only on the configuration file. Once the cell PHY configuration looks correct, you can proceed with UE attach and CDRX behavior verification.

Power on the UE and make sure the UE attach procedure is completed. After the UE is attached, start the eNB trace with the t command and check whether the UE is active in the runtime log. This trace does not directly prove CDRX operation yet, but it confirms that the UE is connected and that downlink/uplink scheduling information is being reported.

In this example, PRACH is detected first, which means the UE has started random access toward the cell. After attach, the UE appears with UE_ID 1, cell 001, and RNTI 003d. The table shows downlink and uplink runtime status such as CQI, rank indicator, MCS, retransmission count, bitrate, SNR, PUCCH power, uplink MCS, timing advance, and buffer-related information. Seeing continuous entries for the UE means the eNB has successfully created the UE context and is monitoring the UE in connected mode.

For checking whether the CDRX configuration is applied, you should also check the eNB log in addition to this runtime trace. The trace confirms that the UE is attached and active, but the actual DRX configuration is usually confirmed from the RRC reconfiguration message or related log entries where drx_config is included. Once the UE attach is complete and the DRX configuration is confirmed in the log, you can proceed to the next step and observe how the UE behaves when traffic becomes inactive.

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

Before running the CDRX test, it is strongly recommended to check the UE capability and confirm that the UE supports CDRX. This can be checked in the UE Capability Information message, especially in the featureGroupIndicators IE.

In this example, the UE capability information shows that both Short DRX cycle and Long DRX cycle / DRX MAC CE are supported. This is important because Amarisoft eNB does not enable CDRX only based on the configuration file. The UE also has to report CDRX support in its capability information. If the UE does not indicate CDRX support in featureGroupIndicators, the eNB may ignore the configured DRX parameters and may not include CDRX in the RRC Connection Reconfiguration message.

So before debugging the actual DRX behavior, first make sure that the UE capability includes CDRX support. Otherwise, even if drx_config is correctly configured in enb-cdrx.cfg, the expected Short DRX or Long DRX operation may not be applied to the UE.

NOTE : If UE does not notify the supportability of CDRX in this IE, Amarisoft eNB would not enable it even if you configured in the configuration file.

In the RRC Connection Setup message, CDRX is not configured yet. You can see this from mac-MainConfig where drx-Config is set to release. This means the UE is still being brought into RRC Connected state without applying DRX operation at this stage.

This is expected behavior. Amarisoft eNB does not configure CDRX immediately during RRC Connection Setup because it has not yet confirmed whether the UE supports CDRX. The eNB first needs to receive and decode UE Capability Information. After the UE reports CDRX support in featureGroupIndicators, the eNB can apply the configured DRX parameters later through RRC Connection Reconfiguration.

So at this point, drx-Config release does not mean the CDRX configuration is wrong. It only means CDRX has not been applied yet. The important check is whether CDRX appears later in RRC Connection Reconfiguration after UE capability exchange is completed.

If the UE reports CDRX support in UE Capability Information and the eNB configuration includes drx_config, Amarisoft eNB enables CDRX later by sending RRC Connection Reconfiguration. In this message, you can check mac-MainConfig and confirm that drx-Config is changed from release to setup.

In this example, drx-Config setup includes onDurationTimer psf6, drx-InactivityTimer psf1920, drx-RetransmissionTimer psf16, longDRX-CycleStartOffset sf1280:35, shortDRX-Cycle sf10, and drxShortCycleTimer 10. This confirms that the CDRX parameters configured in enb-cdrx.cfg are actually applied to the UE through RRC signaling.

So the overall flow is that CDRX is not configured during the initial RRC Connection Setup. The eNB first checks UE capability, and if the UE indicates support for Short DRX and Long DRX, the eNB applies the CDRX configuration by RRC Connection Reconfiguration. This RRC message is the main place to verify that the CDRX configuration has really been delivered to the UE.