RRC Reject

The purpose of this tutorial is to show you how to Reject a RRC message that you specified.  This tutorial shows two different ways of testing RRC reject : One with configuration file and the other one with Remote API. There are roughly two ways of performing RRC Reject in Amarisoft Callbox as listed below.

• Reject through configuration file
• Reject through Remote API

This tutorial shows both ways.

NOTE : In most case, when UE get the RRC Reject message the UE retries a certain number of times and then give up if every retry fails. How may times the UE retries before it gives up usually depends on the type of RRC message.

Table of Contents

• RRC Reject
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Test 1 : RRC Connection Reject (LTE)
• Configuration
• Perform the Test
• Test 2 : RRC Connection Reject (LTE) with a specified retry count
• Configuration
• Perform the Test
• Test 3 : RRC Connection Reject (LTE) with Remote API
• Configuration
• Perform the Test

Introduction

Radio Resource Control (RRC) is a critical protocol layer in cellular networks, responsible for the establishment, configuration, maintenance, and release of radio bearers between user equipment (UE) and the network. RRC operates within the control plane, enabling key procedures such as connection setup, mobility management, paging, and security activation. In testing and development environments, such as with the Amarisoft Callbox, it is often necessary to simulate and evaluate the UE’s response to RRC reject scenarios. This is essential for verifying UE robustness, compliance with 3GPP standards, and network resilience. The Amarisoft Callbox provides flexible mechanisms to trigger RRC reject messages, either through static configuration files or dynamically using a Remote API. Understanding how to control and test RRC reject behaviors is important for protocol engineers, testers, and developers working on network equipment and UE integration. This tutorial addresses practical methods for inducing RRC reject responses, highlights their significance in network testing, and demonstrates how these techniques integrate with the Amarisoft Callbox architecture without delving into detailed message formats or protocol data. By mastering these approaches, practitioners can ensure comprehensive and efficient protocol validation in a controlled test environment.

• Context and Background
  • RRC is a fundamental protocol in LTE and 5G networks, managing signaling between UE and the network’s radio access components.
  • The Amarisoft Callbox is a versatile testing platform widely employed for simulating network behavior and verifying UE compliance.
  • RRC reject scenarios are critical for testing UE response to network rejections, covering use cases such as connection denial or handover failures.
• Relevance and Importance
  • Evaluating how UEs handle RRC rejections helps ensure network stability, security, and user experience.
  • Network operators and device manufacturers rely on such tests to verify that devices conform to specification and react appropriately under failure conditions.
  • The ability to trigger rejections via configuration or API allows for repeatable, automated, and comprehensive test coverage.
• Tutorial Learning Outcomes
  • Gain practical experience in configuring the Amarisoft Callbox to simulate RRC reject conditions.
  • Understand the operational differences between using static configuration files and dynamic Remote API commands for RRC reject testing.
  • Develop proficiency in integrating RRC reject testing into larger automation or validation workflows.
• Prerequisite Knowledge and Skills
  • Familiarity with cellular network architecture (especially LTE/5G)
  • Basic understanding of RRC procedures and signaling concepts
  • Experience working with the Amarisoft Callbox environment
  • General knowledge of configuration file syntax and use of APIs for remote control

Summary of the Tutorial

This tutorial demonstrates various methods for testing RRC Connection Reject procedures in an LTE environment using Amarisoft eNB, focusing on different configuration approaches and the use of remote API. The test environment requires only a single cell and one UE connection; no special setup is needed.

• Test 1: RRC Connection Reject (LTE)
  • Configuration:
    • A configuration file (enb-rrcfilter-request-reject.cfg) is created by modifying the default configuration.
    • rrc_procedure_filter is set in the cell’s configuration to reject all rrc_connection_request messages, causing the eNB to send a reject response to every UE attempting to establish a connection.
  • Test Procedure:
    • Configure the cell parameters (band, bandwidth, etc.) as compatible with the DUT.
    • Power on the UE and observe that call establishment fails at the early stage as indicated by trace logs.
    • Verify in WebGUI log files that each RRC Connection Request is indeed being rejected as configured.
• Test 2: RRC Connection Reject (LTE) with a Specified Retry Count
  • Configuration:
    • A configuration file (enb-rrcfilter-request-reject-ttl.cfg) is prepared, modified from the default configuration.
    • rrc_procedure_filter is set to reject rrc_connection_request a specified number of times (e.g., 4 times) using the ttl parameter, after which subsequent requests are accepted.
  • Test Procedure:
    • Set up the cell as required for the DUT.
    • Power on the UE and monitor the trace log to observe that initial connection attempts fail as expected.
    • After the specified number of rejected attempts, observe that the UE is able to successfully connect, confirming the correct functioning of the retry logic.
    • Log files in WebGUI can be used to verify the rejection and subsequent acceptance of requests.
• Test 3: RRC Connection Reject (LTE) with Remote API
  • Configuration:
    • The default configuration file (enb.default.cfg) is used without modification.
  • Test Procedure:
    • Start the eNB and ensure the cell is configured appropriately for the DUT.
    • Before powering on the UE, issue a remote API command to dynamically set rrc_procedure_filter to reject rrc_connection_request messages (this is done using a command such as ./ws.js enb ...).
    • Power on the UE and observe that the call setup fails, as connection requests are being rejected according to the remote command.
    • To allow the connection, send another remote API command to set rrc_connection_request handling back to accept (e.g., treat).
    • Confirm that the UE is now able to complete call setup successfully.
    • Log files in the WebGUI confirm the dynamic rejection and acceptance of RRC Connection Requests in line with the remote commands sent.

Key configuration parameters used in these procedures include rrc_procedure_filter and its associated options such as action and ttl, as well as the use of remote API for dynamic updates. Each method allows for flexible testing of connection rejection and acceptance behaviors in a controlled LTE environment.

Test Setup

This tutorial does not require any special test setup. Just to have one cell configuration with one UE connection is enough.

Key Configuration Parameters

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

• rrc_procedure_filter
• action
• ttl
• remote API
• rrc_procedure_filter
• action
• ttl

Test 1 : RRC Connection Reject (LTE)

In this test, I will configure in such a way that eNB reject every RrcConnectionRequest from every UE

Configuration

In this test, I created a configuration file named enb-rrcfilter-request-reject.cfg which is copied and modified from enb.default.cfg

Then configure rrc_procedure_filter in the rool location in cell_list as you like (In this test, I set the filter for rrc_connection_request for reject (i.e, rejecting RRCConnectionRequest and sending RRCConnectionReject)

Perform the Test

Following is the cell configuration (BAND, BW etc) but this doesn't matter. You can configure the cell in anyway as long as your DUT is compatible with it.

Then power on UE and you will see the trace log something like this. This indicates that the call establishment has failed at the very early stage. But just from this trace, it is not possible to figure out exactly at which step the call failed. You need to check out the log file for further details.

Now check out the log file on WebGUI and you can confirm that every RRC Connection Request is rejected as shown below.

Sample Log

Test 2 : RRC Connection Reject (LTE) with a specified retry count

In this test, I will configure in such a way that eNB reject  RrcConnectionRequest for the specified number of time and accept it after the specified number of retrial.

Configuration

In this test, I created a configuration file named enb-rrcfilter-request-reject-ttl.cfg which is copied and modified from enb.default.cfg

Then configure rrc_procedure_filter in the rool location in cell_list as you like (In this test, I set the filter for rrc_connection_request for reject (i.e, rejecting RRCConnectionRequest and sending RRCConnectionReject and then reject it only 4 times and accept it after that)

Perform the Test

Following is the cell configuration (BAND, BW etc) but this doesn't matter. You can configure the cell in anyway as long as your DUT is compatible with it.

Then power on UE and you will see the trace log something like this. This indicates that the call establishment has failed at the very early stage. But just from this trace, it is not possible to figure out exactly at which step the call failed. You need to check out the log file for further details.

Now check out the log file on WebGUI and you can confirm that every RRC Connection Request is rejected as shown below.

Sample Log

Test 3 : RRC Connection Reject (LTE) with Remote API

In this test, I will not change/configure anything in configuration file. Instead I will use RemoteAPI and change the configuration on the fly to reject RrcConnectionRequest and accept it as I want.

Configuration

In this test, I created a configuration file named enb.default.cfg without any modification.

Perform the Test

Following is the cell configuration (BAND, BW etc) but this doesn't matter. You can configure the cell in anyway as long as your DUT is compatible with it.

Before powering on UE, you will be at the trace log as shown below.

At this point, send a remote API command as shown below (run this command at /root/enb directory). This is to reject RRC connection request. (NOTE : The exact timing you need to send the command would vary depending on the type of the command. In this case, I sent the command before powering on because the task that I want to do is reject RRC connection Request and the RrcConnectionRequest is the first RRC message after the power on)

Following is the text version of the command that I used. This is to help you copy and paste it for your own purpose.

./ws.js enb '{"message":"config_set","cells": {"1", {"rrc_procedure_filter":{"rrc_connection_request":"reject"}}}}'

Now you see that call setup keep failing. This indicates that the call establishment has failed at the very early stage. But just from this trace, it is not possible to figure out exactly at which step the call failed. You need to check out the log file for further details.

Now let's send another remote API command to accept the RRC Connection Request as shown below.

Following is the text version of the command so that you can copy and paste.

./ws.js enb '{"message":"config_set","cells": {"1", {"rrc_procedure_filter":{"rrc_connection_request":"treat"}}}}'

And then you see that the call setup gets completed as shown below.

Now check out the log file on WebGUI and you can confirm that every RRC Connection Request is rejected when you send the "rrc_connection_frequest":"reject" and get accepted when you send the "rrc_connection_frequest":"treat".