Remote API - Modify EPS Bearer

The purpose of this tutorial is to show you how to change Modify EPS Bearer using Remote API.  If you are not familiar with the basic operation of Remote API, I would suggest you to look into this tutorial first.

The purpose of the Modify EPS Bearer command in LTE is to modify certain parameters of an existing EPS Bearer. Followings are some of the importants contents of Modify EPS Bearer message (based on 24.301-Table 8.3.18.1).

• Quality of service (QoS)
• QoS Class Identifier (QCI),
• Maximum Bit Rate
• Guranteed Bit Rate
• Traffic Flow Template (TFT)
• Radio Priority
• Packet Flow Identifier
• Protocol Configuration Options (PCO)

Table of Contents

• Remote API - Modify EPS Bearer
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Configuration
• Perform the test

Introduction

In Long Term Evolution (LTE) mobile networks, the Evolved Packet System (EPS) Bearer serves as a fundamental concept for managing end-to-end IP connectivity and ensuring differentiated Quality of Service (QoS) for various types of data traffic. Modifying an EPS Bearer is a critical network operation that allows dynamic adjustment of bearer parameters, such as bandwidth allocation, QoS class, and flow characteristics, in response to changing service requirements or network policies. This tutorial focuses on leveraging a Remote API to perform EPS Bearer modification, enabling operators, test engineers, and developers to programmatically alter bearer attributes in a controlled and automated manner. Utilizing the Remote API abstracts the underlying signaling complexity, providing a flexible interface to interact with network functions responsible for bearer management. This capability is essential in scenarios such as real-time traffic adaptation, service optimization, and network slicing, where dynamic resource allocation and service assurance are paramount. Understanding how to modify EPS Bearers through a Remote API not only deepens your comprehension of LTE network architecture but also equips you with practical skills to optimize mobile broadband services in modern cellular ecosystems.

• Context of the Technology
  • EPS Bearers are logical channels established between the User Equipment (UE) and the Packet Data Network Gateway (P-GW) to transport user data with specific QoS guarantees.
  • In LTE architecture, bearer management is central to supporting diverse applications, ranging from voice and video to IoT services, each with unique network performance requirements.
  • Remote APIs provide programmatic access to core network functions, enabling automation, testing, and orchestration of network operations such as bearer modification.
• Relevance and Importance of the Tutorial Topic
  • Dynamic modification of EPS Bearer parameters is crucial for maintaining optimal network performance and user experience.
  • Enables efficient handling of network congestion and service differentiation by adjusting QoS, bit rates, and flow templates on demand.
  • Supports advanced network features such as policy control, service chaining, and network slicing in 4G/5G environments.
• What Learners Will Gain
  • Comprehensive understanding of EPS Bearer concepts and their role in LTE networks.
  • Hands-on experience using a Remote API to interact with and modify bearer attributes.
  • Practical insights into automating network management tasks and enhancing service delivery.
  • Ability to analyze and troubleshoot bearer modification procedures for network optimization.
• Prerequisite Knowledge and Skills
  • Familiarity with basic LTE/EPC architecture, including the concepts of bearers, QoS, and network nodes (e.g., eNB, MME, S-GW, P-GW).
  • Understanding of IP networking and general telecommunications principles.
  • Basic experience with APIs and programming concepts is recommended for following practical exercises.
  • Prior exposure to Remote API operation will be beneficial; refer to the introductory Remote API tutorial if needed.

Summary of the Tutorial

This tutorial provides step-by-step procedures for testing the modification of an LTE EPS bearer using a Remote API in an Amarisoft test environment. The primary focus is on altering QoS parameters (specifically the QCI value) for a connected UE and verifying the successful bearer modification.

• Test Setup:
  • A callbox and a UE (User Equipment) are connected as shown in the provided setup diagram.
• Key Configuration Parameters:
  • Essential parameters include imsi, imei, erab_id, and QoS settings such as qci, priority_level, pre_emption_capability, and pre_emption_vulnerability.
  • Other relevant parameters are filters, llc_sapi, radio_priority, packet_flow_identifier, sm_qos, p_cscf, and dns.
• Configuration:
  • Any standard LTE configuration (e.g., enb.default.cfg) can be used for this procedure.
• Test Procedure:
  1. Power on the UE and wait until it completes the Attach procedure. Verify that the UE has acquired at least one IP address.
  2. Retrieve the current UE bearer information using the relevant Remote API command. Note the imsi and erab_id values from the response for use in the modification step.
  3. Identify the current QCI value assigned to the bearer (e.g., QCI = 9).
  4. Prepare and execute a Remote API call to modify the bearer. The procedure typically involves:
     • Setting the imsi, imei, and erab_id based on the information retrieved in the previous step.
     • Modifying QoS parameters, such as changing the qci value (e.g., from 9 to 6), and specifying other related QoS fields (priority_level, pre_emption_capability, pre_emption_vulnerability).
  5. Upon successful execution, confirm that a positive response is received from the Remote API.
  6. Verify in the system log that the bearer modification took place as intended. This includes checking for the corresponding request and confirmation that the new QoS settings have been applied.

The methodology emphasizes verification at each step: ensuring UE attachment, collecting necessary identifiers, executing the API with correct parameters, and confirming the outcome both via API response and log inspection.

Test Setup

This tutorial needs one callbox and one UE. The bearer modification is driven from the MME side over the Remote API, so the UE only has to attach and stay reachable. No traffic generator is needed.

The antenna is connected only to the first sdr card, RF 1 / sdr 0, and the UE talks to the eNB over the air. One cell is enough here. The test modifies a bearer that already exists on the attached UE.

Key Configuration Parameters

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

• ue_modify_bearer : In this link, you will get the description for all the items listed below.
• imsi
• imei
• erab_id
• qos
• qci
• priority_level
• pre_emption_capability
• pre_emption_vulnerability
• gbr
• filters
• llc_sapi
• radio_priority
• packet_flow_identifier
• sm_qos
• p_cscf
• dns
• ue_get : This is the Remote API used to read the values that ue_modify_bearer needs.
• imsi
• ue_list
• bearers
• erab_id
• erabs : In this link, you will get the description for all the items listed below.
• qci
• priority_level
• pre_emption_capability
• pre_emption_vulnerability

Configuration

You can use any of LTE configuration for this tutorial (e.g, enb.default.cfg).

Perform the test

Power on UE and wait until Attach is complete as below (run the command 'ue' in (mme) screen to get this result). Make it sure that at least one or more IP address is assigned to UE.

The SUPI column carries the IMSI of the UE. Here it is 001010123456789, and IMEISV shows 8690570563562913. The CN column reads EPC, so the UE is on the LTE core. REG is Y, and that is the flag telling you the Attach has finished.

#BEARER is 2 and the IP_ADDR column lists 192.168.3.2, 192.168.4.2 and an IPv6 address starting with 2001:468:3000:1::. The TAC column shows the PLMN 00101 and the tracking area code 0x1.

If REG is still empty, or if no address is listed, the Attach is not complete. The modify command then has no bearer to act on.

Execute the following Remote API to get the basic information that you need for ue_modify_bearer

The command is ws.js sending the message ue_get to the mme instance. It is run from the doc directory, which is where ws.js is installed.

No filter is given in the message, so the answer lists every UE the MME currently knows. ue_get also accepts an optional imsi or imei to return only one UE. With a single UE attached the plain form is enough.

You will get the result as shown below if UE is properly attached. Remember imsi and erab_id because it will be used in the RetmoteAPI command to modify the bearer.

The two values to take from this answer are imsi 001010123456789 and, inside the bearers array, erab_id 5. Both go into the ue_modify_bearer command in the next step.

registered is true, which is the same information as the REG column of the ue command. The bearer with erab_id 5 has ip 192.168.3.2 and apn internet, so this is the default bearer created during Attach. ue_aggregate_max_bitrate_dl and ue_aggregate_max_bitrate_ul are the UE-AMBR values and this test does not touch them.

ue_modify_bearer also asks for imei, and ue_get returns imeisv instead. imeisv here is 8690570563562913. The imei used in the command is 869057056356291. That is the first 14 digits of imeisv plus the check digit.

For now, QCI is assigned to be 9 as shown in the log. In this test, I will change this QCI value to 6 using a Remote API.

Open the Attach accept sent to the UE and read the decoded message on the right. The ESM message container inside it is the Activate default EPS bearer context request, and the EPS bearer identity is 5. That is the same bearer as erab_id 5 in the ue_get answer.

The EPS QoS block of that request carries QCI = 9. The access point name is internet.mnc001.mcc001.gprs and the PDN address is the IPv4 address 192.168.3.2, which matches what ue_get reported.

Nothing has to be edited at this point. This step only shows you the value that the Remote API call is going to replace.

Run the RemoteAPI command as shown below. (NOTE : the "imsi", "imei","erab_id" should be set accordingly based on your specific test.)

./ws.js mme '{"message": "ue_modify_bearer","imsi":"001010123456789","imei":"869057056356291","erab_id":5,

    "qos":

        {

          "qci": 6,

          "priority_level": 15,

          "pre_emption_capability": "shall_not_trigger_pre_emption",

          "pre_emption_vulnerability": "not_pre_emptable"

        }

       }'

 

The message name is ue_modify_bearer, and imsi, imei and erab_id say which bearer of which UE is changed. imsi and erab_id are the two values read from the ue_get answer. erab_id 5 is the default bearer, so this call modifies the bearer the UE received at Attach.

The qos object is what actually changes. qci is set to 6 and replaces the 9 the bearer was given at Attach. priority_level 15 is the lowest priority and it is also the default value. pre_emption_capability is shall_not_trigger_pre_emption, so this bearer will not push other bearers out. pre_emption_vulnerability is not_pre_emptable, so it cannot be pushed out itself.

qos itself is optional in ue_modify_bearer. It is used here because a QoS change is the point of this test. The same command also takes filters, llc_sapi, radio_priority and packet_flow_identifier. Use filters instead of qos when you want to modify the traffic flow template rather than the QoS.

 

If your command has been successfully processed, you will get the response as follows.

ws.js first connects to 127.0.0.1:9000 and reports the peer as name=MME, type=MME. That confirms the command went to the MME and not to the eNB.

The request is sent as ue_modify_bearer id#1 and the answer arrives about 0.4 seconds later. It repeats the message name and returns erab_id 5, so the bearer you asked for is the one that was modified. message_id id#1 matches the request, which is useful when several calls are in flight.

This answer only means that the MME accepted the command. Whether the UE really took the new QoS is checked in the next step.

Confirm that the Bearer is changed as intended in the log. In this example, you see that 'Modify EPS bearer context request' is sent to UE with 'New EPS QoS' IE as specified in the Remote API.

The new value sits in the New EPS QoS IE and it reads QCI = 6. The EPS bearer identity is still 5, so the existing bearer was modified and no new bearer was created. The message type is 0xc9.

The UE was idle when the command was issued. Paging comes first, then the Service request and the RRC connection setup. Only after that does the MME send the Modify EPS bearer context request.

A few lines below there is a Modify EPS bearer context accept coming back from the UE. That is the line confirming the UE applied the new QoS. If it is missing, the request was sent but never answered.