LTE PDCCH Order

This tutorial shows how to trigger a PDCCH Order based RACH procedure from the callbox.  In live network and UE, PDCCH Order transmission would happen when  the connection gets Out of Sync and there is some data available for Network to send, but it would not be easy to create such a situation in lab settings. So in this tutorial, I will use RemoteAPI to trigger PDCCH order. The main purpose of this tutorial is to show how to configure PDCCH Order related parameters in configuration file and check if UE properly responds to the PDCCH order.

In most case, RACH is triggered by UE side decision, but there is some mechanism by which network (eNB) force UE to initiate RACH.  In idle mode, Paging is such a mechanism and in connected mode PDCCH order is such a mechanism. PDCCH order is a mechanism in which network (eNB) order UE to initiate RACH by sending a specific format of DCI. The DCI format used for this purpose is DCI Format 1A with a specific value assigned to PRACH Mask Index field.

The PRACH procedure can be an Contention Based or Contention Free. The PDCCH order instruct which type of RACH procedure should be initiated by configuring specific preamble index values.

Table of Contents

• LTE PDCCH Order
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Test 1 : Contention Based PDCCH Order
• Configuration
• Perform the Test
• Log Analysis
• Test 2 : Contention Free PDCCH Order
• Configuration
• Perform the Test
• Log Analysis

Introduction

The Physical Downlink Control Channel (PDCCH) Order-based Random Access Channel (RACH) procedure is a critical mechanism in LTE networks that allows the evolved Node B (eNB) to directly command a User Equipment (UE) to initiate random access. Unlike typical RACH procedures, which are usually triggered by the UE in response to connectivity needs or synchronization loss, the PDCCH order enables the network to take proactive control, particularly in scenarios where the UE is in RRC_CONNECTED state but has lost uplink synchronization. This mechanism is fundamental for maintaining robust network operations, ensuring timely recovery from out-of-sync conditions, and guaranteeing the delivery of downlink data. The PDCCH order utilizes a specially formatted Downlink Control Information (DCI), specifically DCI Format 1A with a defined PRACH Mask Index, to signal the UE to begin either contention-based or contention-free RACH procedures. Understanding how to configure, trigger, and verify the PDCCH order process is essential for engineers and testers working with LTE radio access networks, especially in controlled environments where replicating real-world out-of-sync scenarios can be challenging. This tutorial leverages RemoteAPI to simulate and trigger the PDCCH order from a callbox, providing hands-on experience with configuration parameters and response verification, and deepening comprehension of the LTE RACH architecture and its operational significance within the mobile network ecosystem.

• Context of the Technology
  • The PDCCH order is a core feature within the LTE radio access network, facilitating direct network-initiated random access for UEs.
  • It addresses scenarios where the UE loses uplink synchronization but remains in RRC_CONNECTED state, ensuring uninterrupted service delivery and network reliability.
  • This mechanism is especially important in automated testing and lab environments, where realistic simulation of network behaviors is required.
• Relevance and Importance of the Tutorial Topic
  • Demonstrates practical methods to trigger and observe PDCCH order-based RACH, which is otherwise difficult to reproduce in laboratory settings.
  • Equips learners with knowledge on configuring essential parameters in the callbox and test environment to mimic real network conditions.
  • Highlights the architectural role of PDCCH and RACH in LTE connectivity, network recovery, and system resilience.
• Learning Outcomes
  • Understand the technical principles and signaling involved in PDCCH order-based RACH procedures.
  • Gain hands-on experience with RemoteAPI to trigger PDCCH orders in a controlled test setup.
  • Learn how to configure and verify PDCCH order-related parameters in configuration files.
  • Acquire the ability to interpret UE responses and validate correct behavior in response to network commands.
• Prerequisite Knowledge and Skills
  • Basic understanding of LTE architecture, including eNB, UE, and radio protocol stack.
  • Familiarity with RACH procedures and LTE control channels (especially PDCCH and DCI formats).
  • Experience with network testing tools, callbox operation, and configuration file management.
  • Working knowledge of RemoteAPI or equivalent test automation frameworks is beneficial.

Summary of the Tutorial

This tutorial demonstrates two test procedures focusing on PDCCH Order-triggered RACH in LTE systems, covering both contention-based and contention-free approaches. The tests highlight configuration steps, test execution, and log analysis methodologies.

• Test 1: Contention Based PDCCH Order
  • Configuration Steps:
    • Modify enb-pdcch-order-cb.cfg (copied from the default eNB configuration).
    • Set the following key parameters:
      • pdcch_order_prach to "cb_random" to trigger contention-based RACH via PDCCH Order.
      • inactivity_timer to 600000 (10 minutes) to allow sufficient time for Remote API operations.
    • Use the default mme-ims.cfg configuration for MME.
  • Test Execution:
    • Start trace logging on the Callbox.
    • Power on the UE and allow it to complete the attach procedure.
    • While the UE is in the connected state, send the Remote API command: ./ws.js enb '{"message":"pdcch_order_prach",:enb_ue_id":1}'
    • Verify the correct enb_ue_id using the trace window.
    • Observe that the PRACH is triggered by the PDCCH Order.
  • Log Analysis:
    • Confirm that the RACH is triggered by the PDCCH order in the logs.
    • Verify that the PDCCH contains 'pdcch_order,' indicating it is intended to trigger RACH.
    • Observe the 4-step RACH procedure, which signifies a contention-based process.
• Test 2: Contention Free PDCCH Order
  • Configuration Steps:
    • Modify enb-pdcch-order-cf.cfg (copied from the default eNB configuration).
    • Set the following key parameters:
      • pdcch_order_prach to "cf_random" to trigger contention-free RACH via PDCCH Order.
      • inactivity_timer to 600000 (10 minutes).
    • Use the default mme-ims.cfg configuration for MME.
  • Test Execution:
    • Start trace logging on the Callbox.
    • Power on the UE and allow it to complete the attach procedure.
    • While the UE is in the connected state, send the Remote API command: ./ws.js enb '{"message":"pdcch_order_prach",:enb_ue_id":1}'
    • Verify the correct enb_ue_id using the trace window.
    • Observe the PRACH triggered by the PDCCH order.
  • Log Analysis:
    • Verify that the SIB2 message contains the preamble sequence index, confirming the contention-free RACH process.
    • Check the number of RA-Preambles in rach-ConfigCommon for confirmation.
    • Confirm the 'pdcch_order' indication in PDCCH and the triggered RACH procedure in the logs.

Both tests utilize the Callbox and UE setup with specific SIM card and configuration parameters. The procedures emphasize configuration changes, execution steps using Remote API, and careful log verification to validate the RACH triggering process and its contention type.

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

The UE connects to the eNB over the air. The antenna is connected only to the first SDR card, which is RF 1 / sdr 0 on the rear panel, and the other RF ports are left open since this tutorial runs a single cell.

Key Configuration Parameters

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

• pdcch_order_prach
• inactivity_timer

Test 1 : Contention Based PDCCH Order

This test is to show how to configure contention based PDCCH Order and varify it.

Configuration

I used enb-pdcch-order-cb.cfg which is copied and modified from the default eNB configuration (enb.default.cfg).

I used the default configuration mme-ims.cfg .

In enb-pdcch-order-cb.cfg, parameters are set as follows.  The required configuration is to set pdcch_order_prach to "cb_random" which indicates that Network will trigger the contention based RACH with PDCCH Order. In addition, inactivity_timer is set to 600000 (10 min) to give enough time to type in Remote API command in connected states.

pdcch_order_prach sits in the cell_default block, so it applies to every cell built from that default. With cb_random the order goes out with ra-PreambleIndex 0 and the UE picks the preamble itself, which is what makes the procedure contention based. The only other value the eNB takes is cf_given, and that is what Test 2 uses.

The timer above it is the network inactivity time in ms after which the eNB sends the RRC connection release. A UE left alone at the default value drops back to idle while you are still preparing the Remote API call, and an idle UE has no connection for the order to be sent on.

pdcch_format comes from the default file and is not specific to this test. The #if N_RB_DL == 6 branch sets it to 1 for the 1.4 MHz bandwidth and to 2 for everything else, which forces the number of CCEs of the UE specific PDCCH to 2^pdcch_format instead of letting it be computed from the reported CQI.

Perform the Test

First, Start trace logging on Callbox, Power on UE and let it complete the attach.

While call is in connected state, Send the RemoteAPI command by running ./ws.js enb '{"message":"pdcch_order_prach",:enb_ue_id":1}'

NOTE : Double check if you are using the correct enb_ue_id. The simplest way is to check the UE id in trace window

ws.js connects to 127.0.0.1:9001 and reports the endpoint it reached, name=ENB and type=ENB, before it sends anything. The exchange itself is two lines, Send message pdcch_order_prach id#1 on the way out and the reply on the way back with the same message name, message_id id#1 and the eNB time of 69.796.

enb_ue_id picks which connected UE gets the order, and it is 1 here because a single UE is attached. The reply only says that the eNB accepted the call. Whether the UE answered the order has to be read from the trace, which is the next step.

You would get the PRACH triggered by PDCCH order as shown below.

The trace is started with the t command on the eNB console and stopped with return. Two PRACH lines are in this run. The one at the top, cell=01 seq=2 ta=3 snr=26.8 dB, came from the attach. The one at the bottom, cell=01 seq=27 ta=2 snr=17.2 dB, is the one the order produced.

The rows between them are the normal per UE report for RNTI 003d on cell 001, with cqi 15 and a DL mcs around 23 to 24, and they carry on unchanged while the order is sent.

The preamble is chosen by the UE in this mode, so the seq value you get will not be 27. What matters is that a new PRACH appears right after the Remote API call and that the UE keeps the same RNTI.

Log Analysis

SampleLog

Check out the RACH procedure which is triggered by pdcch_order. In the data of PDCCH, you see 'pdcch_order' which mean this is to trigger RACH, not for scheduling and you see 4 step RACH procedure which indicates it is contention based process.

The quickest way to land on it is to type PRACH in the search box and then walk back a few lines to the PDCCH that carries the order. That PDCCH is at 07:40:19.574 with cce_index=0/12 L=4 dci=1a, and its Data pane carries pdcch_order together with preamble_index=0 and prach_mask_index=0.

preamble_index=0 is what makes this run contention based. The eNB names no preamble, the UE picks one for itself, and the one it picked is sequence_index=27 in the PRACH that arrives at 07:40:19.592 with ta=2 prb=2:6 snr=17.2.

Each step is labelled in the message column. msg1 is that PRACH, msg2 is the RAR with rapid=27 on PDSCH, msg3 is the PUSCH carrying mac_crnti=0x003d and resuming connection of ue_id=0x0001, and msg4 is the PDCCH at cce_index=4/12 L=4 dci=0. The RRC connection reconfiguration on DCCH sits between msg3 and msg4.

The MAC lines around them are worth reading too. Allocating new UE creates a temporary context for the incoming preamble, which is why msg2 and msg3 are on UE ID 2, and Freeing UE releases it once msg3 has resumed ue_id=0x0001, so the call carries on with the context it had before the order.

Test 2 : Contention Free PDCCH Order

This test is to show how to configure contention based PDCCH Order and varify it.

Configuration

I used enb-pdcch-order-cf.cfg which is copied and modified from the default eNB configuration (enb.default.cfg).

I used the default configuration mme-ims.cfg .

In enb-pdcch-order-cf.cfg, parameters are set as follows. The required configuration is to set pdcch_order_prach to "cf_random" which indicates that Network will trigger the contention free RACH with PDCCH Order. In addition, inactivity_timer is set to 600000 (10 min) to give enough time to type in Remote API command in connected states.

What changes from Test 1 is this one value. lteenb.doc lists none, cb_random and cf_given for pdcch_order_prach, cb_random being the random preamble with ra-PreambleIndex 0 and cf_given the dedicated contention free preamble that the eNB hands out itself.

Because the eNB decides the preamble, it knows which sequence index to expect back and there is no need to resolve contention on it. The index it gives out has to come from the range that SIB2 reserves for contention free access, which is the first thing checked in the log analysis of this test.

The rest of the block is the same as in Test 1, including inactivity_timer at 600000 and the pdcch_format branch that comes from the default file.

Perform the Test

First, Start trace logging on Callbox, Power on UE and let it complete the attach.

While call is in connected state, Send the RemoteAPI command by running ./ws.js enb '{"message":"pdcch_order_prach",:enb_ue_id":1}'

NOTE : Double check if you are using the correct enb_ue_id. The simplest way is to check the UE id in trace window

You would get the PRACH triggered by PDCCH order as shown below.

The first PRACH line, cell=01 seq=38 ta=3 snr=17.9 dB, is the one from the attach. The one the order produced is cell=01 seq=52 ta=3 snr=18.8 dB in the middle of the report, and the per UE rows for RNTI 003d run on either side of it.

seq=52 is not a random value here. It is the preamble the eNB assigned with the order, so the same index comes back on every run as long as the cell configuration stays the same. That is the difference you can see from the console alone, without opening the log.

Log Analysis

SampleLog

In case of contention free RACH, there should be some preamble sequence index which can be used for contention free process. You can confirm this in SIB2 message by checking numberofRA-Rreambles in rach-ConfigCommon.

The message to open is the RRC BCCH SIB at 07:59:23.658. Under radioResourceConfigCommon, rach-ConfigCommon carries preambleInfo with numberOfRA-Preambles n52. That splits the preambles in two : sequence index 0 to 51 is what a UE may pick for contention based access, and 52 to 61 is left for the contention free ones the eNB hands out.

The same block holds the rest of the RACH setup, ra-SupervisionInfo with preambleTransMax n10, ra-ResponseWindowSize sf10 and mac-ContentionResolutionTimer sf40, maxHARQ-Msg3Tx 5, and prach-Config with rootSequenceIndex 204, prach-ConfigIndex 4, highSpeedFlag FALSE, zeroCorrelationZoneConfig 11 and prach-FreqOffset 2. Those come from the default configuration and I did not change them for this test.

This is the first field to look at if a contention free order does not go through, since the eNB has nothing to give out when every preamble belongs to the contention based range.

Check out the RACH procedure which is triggered by pdcch_order. In the data of PDCCH, you see 'pdcch_order' which mean this is to trigger RACH, not for scheduling and you see 4 step RACH procedure which indicates it is contention based process.

The PDCCH carrying the order is at 07:59:50.914 with cce_index=0/12 L=4 dci=1a, and its Data pane carries pdcch_order with preamble_index=52 and prach_mask_index=0. That index comes from the range SIB2 reserves for contention free access.

The MAC line right after it reads Contention free preamble 52: Resuming ue_id=0x0001, so the eNB is already waiting for that exact preamble from that UE. msg1 arrives at 07:59:50.926 as PRACH sequence_index=52 ta=3 prb=2:6 snr=18.8, and msg2 is the RAR with rapid=52 on PDSCH.

Because the eNB assigned the index itself, the same number appears three times, in the preamble_index of the order, in the sequence_index of msg1 and in the rapid of msg2. Reading those three fields against the ones in Test 1, where the order carried preamble_index=0 and the UE answered with an index of its own, is the quickest way to tell the two modes apart in a log.