Remote API - Changing SIB contents

The purpose of this tutorial is to show you how to change the contents of SIB message using Remote API. Not all SIB IE can be changed by Remote API. There are a certain set of SIB IEs that is allowed to be changed by remote API and they are documented in lteenb.pdf. If you are not familiar with the basic operation of Remote API, I would suggest you to look into this tutorial first.

In general, Amarisoft allows IE (information element) changes in this way mainly for SIB1, SIB2 and small numbers of IEs for other SIBs. For IE changes for other SIBs, it is recommended to manually change the asn file. Regarding the SIB changes with asn file, refer this tutorial.

NOTE :  There are two different way ot chaning IEs of SIB message with remote API. First one is to change a specific IE explicitely(explicit IE change) with the message format  '{"message":"sib_set","cells":{"cell_id":{"sib":{IE setting}}}} as shown in Test 1' and the other one is to change the entire payload of the SIB (payload change) with the message format  '{"message":"sib_set","cells":{"cell id":{"sib":{ "type": "hex", "payload" : "Hex string of the entire sib message"}}}}' as shown in  Test 2'

NOTE :  Not every SIB IE can be changed by the explicit IE changes. There are only small number of IEs that can be changed in this way. Refer to this document and check which IE of which SIB can be changed in this way.

NOTE : Not every SIB IE can be changed by the payload change. The SIB should provide 'type', 'payload' parameter for this type of manipulation. Refer to this document and check which SIB support these parameters.

Table of Contents

• Remote API - Changing SIB contents
• Introduction
• Summary of the Tutorial
• Test 1 : Changing p-Max in SIB1
• Configuration
• Perform the test
• Test 2 : Changing whole contents of a SIB3
• Configuration
• Perform the test

Introduction

System Information Blocks (SIBs) are critical components in LTE networks, serving as structured containers that broadcast essential configuration and operational parameters from the eNodeB to user equipment (UE). These parameters include cell access information, scheduling, mobility management, and radio resource configuration, allowing UEs to establish, maintain, and optimize connectivity within the cellular infrastructure. Amarisoft’s LTE platform enables dynamic manipulation of SIB contents through its Remote API, providing operators and developers with the flexibility to adjust specific Information Elements (IEs) of SIBs in real time. This capability is particularly significant during network optimization, automated testing, and field trials, where controlled changes to the broadcasted system information accelerate validation and troubleshooting processes. The architecture of the Remote API is designed to abstract the underlying complexity of protocol message encoding, offering standardized JSON-based commands for explicit IE modification or full SIB payload replacement. However, not all SIBs or their constituent IEs are eligible for remote modification due to protocol and implementation restrictions; only a subset—mainly within SIB1, SIB2, and select IEs in other SIBs—can be altered via the API, as detailed in vendor documentation. Understanding the mechanisms, limitations, and safe practices for modifying SIBs is essential for network engineers and developers working to maintain network reliability and compliance. This tutorial provides a comprehensive guide to changing SIB message contents using the Amarisoft Remote API, emphasizing the supported methods, practical considerations, and the broader context of system information management in LTE networks.

• Context and Background
  • System Information Blocks (SIBs) are standardized containers in LTE that convey critical configuration and operational information from the eNodeB to UEs, forming the backbone of initial access and ongoing connectivity management.
  • Amarisoft’s LTE platform provides a programmable interface (Remote API) that allows for dynamic SIB content manipulation, facilitating rapid adaptation and experimentation in testbeds and live networks.
  • The Remote API abstracts protocol intricacies, enabling targeted changes to SIB Information Elements or complete payload replacements through structured, JSON-formatted commands.
  • Modification capabilities are intentionally limited to protect network integrity, with only specific IEs in SIB1, SIB2, and a minor subset in other SIBs being eligible for remote updates.
• Relevance and Importance
  • The ability to modify SIBs in real time is crucial for network optimization, automated testing, validation, and troubleshooting, reducing operational downtime and accelerating deployment cycles.
  • Dynamic SIB modification empowers engineers to simulate diverse network scenarios, evaluate device behavior, and validate configuration changes without manual intervention or service disruption.
  • Understanding the practical limits and safe usage of the Remote API ensures compliance with protocol standards and mitigates risks of misconfiguration that could adversely affect network performance.
• Tutorial Learning Outcomes
  • Learners will gain a deep understanding of how to use the Remote API to modify SIB contents, including both explicit IE changes and full payload replacement strategies.
  • The tutorial provides hands-on guidance on identifying which SIBs and IEs are modifiable, referencing official documentation for supported parameters and message formats.
  • By the end of this guide, users will be able to confidently apply SIB modifications within the constraints of the Amarisoft platform, ensuring safe and effective changes in both development and production environments.
• Prerequisite Knowledge and Skills
  • Familiarity with LTE system architecture, SIB structures, and the role of system information in cellular networks.
  • Basic understanding of Amarisoft Remote API operations and JSON-formatted configuration commands.
  • Access to the lteenb.pdf or related documentation for reference on which SIBs/IEs support remote modification.
  • General knowledge of network configuration management and safe change procedures in live or test LTE environments.

Summary of the Tutorial

This tutorial demonstrates two LTE test procedures focused on modifying SIB (System Information Block) contents using Remote API commands. The tests do not require any DUT (UE) and are based on observing the effects through the lte service and WebGUI. Details of each test are summarized below, preserving the original formatting and structure.

• Test 1 : Changing p-Max in SIB1
  • Objective: Illustrate how to change a specific Information Element (IE), such as p-Max, within SIB1 using the Remote API.
  • Key Considerations:
    • Not all IEs in every SIB can be changed via this method; only a limited subset is supported.
    • Reference the sib_set document to identify which IEs are modifiable.
  • Configuration:
    • Any LTE configuration can be used (e.g., enb.default.cfg).
  • Procedure:
    • Start the lte service (service lte restart).
    • Observe the initial value of the target IE (p-Max in SIB1) via WebGUI.
    • Execute the RemoteAPI command to change the p-Max value:
      ./ws.js enb '{"message":"sib_set","cells":{"1":{"sib1":{"p_max":20}}}}'
    • Verify via WebGUI that the eNB sends paging with systemInfoModification.
    • Confirm that the p-Max value is updated as per the RemoteAPI command.
• Test 2 : Changing whole contents of a SIB3
  • Objective: Demonstrate how to change the complete contents of SIB3 by sending the entire payload (in hex string format) through the Remote API.
  • Key Considerations:
    • Not every SIB supports this operation; the SIB must allow 'type' and 'payload' parameters.
    • Refer to the sib_set document to check SIB compatibility.
  • Configuration:
    • Any LTE configuration can be used (e.g., enb.default.cfg).
  • Procedure:
    • Start the lte service (service lte restart).
    • Verify the initial contents of SIB3 via WebGUI.
    • Send the RemoteAPI command to overwrite SIB3 with a new payload:
      ./ws.js enb '{"message":"sib_set","cells":{"1":{"sib3":{ "type": "hex", "payload" : "000c16043f95aa0007ae"}}}}'
    • Verify that the eNB sends paging with systemInfoModification.
    • Confirm, again via WebGUI, that the SIB3 contents have been updated as per the specified payload.

Both tests emphasize the importance of proper command syntax when using the RemoteAPI and highlight the need to cross-reference supporting documents to determine which SIBs and IEs are eligible for such modifications. The procedures rely on service restarts and WebGUI verification, with no UE involvement.

Test 1 : Changing p-Max in SIB1

This test shows how to change a specific IE (information elements) of a SIB with Remote API. As an example, I will show you how to change p-Max in SIB1. You can use the same logic for other IEs in other SIBs. However, not all IEs in every SIBs can be changed this way. There are only small portions of IEs that can be changed this way. Refer to sib_set document to figure out which IE of which sib can be changed this way.

NOTE :  Not every SIB IE can be changed by this method (i.e, explicit IE changes). There are only small number of IEs that can be changed in this way. Refer to this document and check which IE of which SIB can be changed in this way.

Configuration

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

Perform the test

In this tutorial, you don't need any DUT(UE) for testing. Just running the lte service and verify the result in WebGUI is enough.

Run lte service ([service lte restart]) and check the IE in the SIB before you send RemoteAPI command. In this tutorial, I will change the p-Max IE in SIB1

In the WebGUI log window I picked one of the SIB1 lines carried on BCCH, and the decoded SIB1 is listed on the right side.

The IE to watch is p-Max, and it sits inside cellSelectionInfo. Before the Remote API command it reads 23. q-RxLevMin in the same block is -70. The rest of SIB1 is the usual set for the default configuration, with cellIdentity '1A2D001'H, trackingAreaCode '0001'H, freqBandIndicator 7 and cellBarred notBarred.

Take note of systemInfoValueTag as well. It is 2 at this point. The eNB increments this tag whenever it rebuilds the system information, so it is an easy second check that the change really went through.

Send RemoveAPI command as shown below. Be careful about the syntaix. It would not be easy to figure out the correct syntax just by reading lteenb.pdf

                            ./ws.js enb '{"message":"sib_set","cells":{"1":{"sib1":{"p_max":20}}}}'

The JSON is nested three levels deep and each level has a job. cells selects the cell by its cell_id, so "1" here. sib1 names the SIB to be modified. p_max is the IE itself, set to 20. The single quotes around the whole JSON keep the shell from eating the double quotes.

ws.js connects to the eNB on 127.0.0.1:9001 and sends the message tagged as id#1. The reply echoes back the same message name and the same message_id, plus a time value. There is no error field in the reply, and that is how you know the eNB accepted the command. The tool tells you nothing about the resulting SIB contents, so the actual result still has to be checked in the WebGUI.

If the RemoteAPI command is properly processed, you will see the eNB send paging with systemInfoModication.

The paging appears on PCCH at 06:23:57.641 in this run. It is not a single message but a short burst of them on consecutive occasions. Before that point the log carries only the BCCH SIB and SIB1 lines.

Selecting one of the paging lines shows the decoded content. It is message c1: paging with systemInfoModification true and nothing else. There is no paging record list, because no UE is being paged here. The flag on its own is what tells a camped UE that the system information has changed and has to be read again.

Then you can confirm that the p-Max value is changed as configured in the RemoteAPI command .

The SIB1 to look at is the first one after the paging burst, at 06:23:57.707 in this run. p-Max in cellSelectionInfo now reads 20, which is exactly the value given to p_max in the command.

systemInfoValueTag has moved from 2 to 3 at the same time. Everything else in SIB1 is left alone. q-RxLevMin is still -70, freqBandIndicator is still 7 and cellIdentity is still '1A2D001'H. Only the IE named in the command changed.

If you want a different value, change the number after p_max and send the command again. The lte service does not need to be restarted.

Test 2 : Changing whole contents of a SIB3

This test shows how to change the whole contents of a specified SIB. As an example, I will show you how to change the whole contents of SIB3 in LTE. Refer to sib_set document to figure out which sib can be changed in this way.  The idea is to send the entire payload hex string) of the message via RemoteAPI.

NOTE : Not every SIB IE can be changed by the payload change. The SIB should provide 'type', 'payload' parameter for this type of manipulation. Refer to this document and check which SIB support these parameters.

Configuration

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

Perform the test

In this tutorial, you don't need any DUT(UE) for testing. Just running the lte service and verify the result in WebGUI is enough.

Run lte service ([service lte restart]) and check the contents of the SIB3 before you send RemoteAPI command.

SIB3 is not sent on its own here. Select a BCCH line marked SIB rather than SIB1, then scroll the decoded pane down past the sib2 content until you reach the sib3 block.

Write down what is in it before you change anything. cellReselectionInfoCommon has q-Hyst dB2. cellReselectionServingFreqInfo has s-NonIntraSearch 3, threshServingLow 2 and cellReselectionPriority 6. intraFreqCellReselectionInfo has q-RxLevMin -61, p-Max 23, s-IntraSearch 5, presenceAntennaPort1 TRUE, neighCellConfig '01'B and t-ReselectionEUTRA 1.

This whole block is what the hex payload in the next step replaces. The replacement is not a merge. Any IE you still want broadcast has to be encoded into the new payload as well.

Send RemoveAPI command as shown below. Be careful about the syntaix. It would not be easy to figure out the correct syntax just by reading lteenb.pdf

                            ./ws.js enb '{"message":"sib_set","cells":{"1":{"sib3":{ "type": "hex", "payload" : "000c16043f95aa0007ae"}}}}'

The outer part of the JSON is the same as in Test 1. cells picks the cell by cell_id "1", and sib3 names the SIB. The inner object is what differs. There is no IE name in it at all. Instead there is type set to "hex" and payload set to the encoded SIB3 content, 000c16043f95aa0007ae, which is 10 bytes.

You have to produce that hex string yourself. It is the encoded SIB3 body, so an ASN.1 encoder is the practical way to build it. Note that the payload holds the SIB3 body only, not the SI message that carries it.

The reply has the same shape as in Test 1, with the message name echoed back and message_id id#1. No error field comes back, so the eNB took the payload. That does not mean the payload decodes into what you intended. The next steps are where you find that out.

If the RemoteAPI command is properly processed, you will see the eNB send paging with systemInfoModication.

The paging starts at 22:18:50.526 in this run, right after the last BCCH line, and runs as a burst over the following occasions. The one selected here is on cell #1 at frame 1.146.5.

The decoded content is paging with systemInfoModification true, the same single flag as in Test 1. Replacing a whole SIB payload and changing one IE are notified to the UEs in exactly the same way. There is nothing in the paging message that says which SIB changed.

Then you can confirm that the contents is changed as configured in the RemoteAPI command .

Select a BCCH SIB line after the paging burst and scroll down to the sib3 block again. Six values have moved. q-Hyst is now dB0 instead of dB2. threshServingLow is 0 instead of 2. q-RxLevMin is -26 instead of -61. presenceAntennaPort1 is FALSE instead of TRUE. neighCellConfig is '00'B instead of '01'B. t-ReselectionEUTRA is 2 instead of 1. cellReselectionPriority is the only one that stayed at 6.

Three IEs that were broadcast before have disappeared: s-NonIntraSearch, p-Max and s-IntraSearch. They are optional in SIB3 and the payload I sent simply does not contain them. This is the part that catches people out. The payload replaces the SIB3 body as a whole, so anything left out of the hex string stops being broadcast.

The sib2 content above the sib3 block is untouched. Only the SIB3 body was replaced, even though SIB2 and SIB3 are carried in the same SI message.