ASN.1 Editor

ASN.1 editor is a new software tool supported from 2023-08-22 release. It is a tool by which you can create a signaling message in ASN.1 format in GUI (Graphical User Interface). Once the creation is done, it can be saved in the format of JER (JSON representation) and the tool can import the ready made jer (JSON text file) as well.

RUN ASN.1 Editor from tech-academy

Table of Contents

• ASN.1 Editor
• Introduction
• Summary of the Tutorial
• How to Run
• Icons
• Creating a New ASN.1
• Automatic Mandatory IE Creation
• Ready-Made Templates
• Tips
• Compatibility between *.jer and *.asn file
• Conversion between *.jer and *.asn file

Introduction

ASN.1 Editor is a sophisticated software tool introduced in the 2023-08-22 release, designed to streamline the creation and manipulation of signaling messages using the Abstract Syntax Notation One (ASN.1) standard. ASN.1 is a widely adopted, platform-independent notation that specifies data structures for cross-system communication, particularly in telecommunications, networking, and secure communications protocols. The ASN.1 Editor provides an intuitive Graphical User Interface (GUI), enabling users to visually construct complex ASN.1 messages without the need for manual coding. The editor supports seamless conversion between ASN.1 and JER (JSON Encoding Rules), empowering users to save messages in a standardized JSON representation or import pre-existing JER files for further editing. This tool enhances productivity, reduces errors in message definition, and bridges the gap between binary ASN.1 encoding and human-readable JSON formats. By integrating ASN.1 Editor into system development workflows, engineers and testers can accelerate the design, verification, and troubleshooting of protocol messages, ensuring interoperability and compliance across diverse platforms and applications.

• Context and Background
  • ASN.1 (Abstract Syntax Notation One) is a formal language for describing data structures used in communication protocols and data serialization.
  • The editor leverages ASN.1s universality to support applications in telecom, networking, security, and data interchange standards.
  • JER (JSON Encoding Rules) is a standardized method to represent ASN.1 data in JSON format, facilitating integration with web technologies and modern software stacks.
  • The tool is developed and maintained by tech-academy, reflecting ongoing innovation in protocol engineering tooling.
• Relevance and Importance
  • Automates and simplifies the construction of ASN.1 messages, significantly reducing manual workload and potential for syntax errors.
  • Bridges the gap between traditional ASN.1 encoding and modern JSON-based workflows, enhancing interoperability and ease of debugging.
  • Essential for developers, testers, and protocol engineers working in environments where ASN.1 is the data interchange standard.
• What You Will Gain from This Tutorial
  • Comprehensive understanding of how to create, edit, and manage ASN.1 messages using the ASN.1 Editor.
  • Ability to import existing JER files and export constructed messages in JER format for use in broader system integration or testing.
  • Insight into best practices for ASN.1 message definition and practical experience with GUI-based ASN.1 tooling.
  • Enhanced skills in managing protocol messages for telecommunications, networking, and security applications.
• Prerequisite Knowledge and Skills
  • Familiarity with ASN.1 syntax and data modeling concepts is recommended for maximum benefit.
  • Basic understanding of JSON and its role in data interchange will aid in leveraging JER features.
  • Experience in protocol development or testing is helpful but not mandatory; this tutorial is also accessible to beginners seeking to learn ASN.1 tooling.

Summary of the Tutorial

This tutorial describes procedures related to using the ASN.1 editor tool for LTE message creation and configuration. The following test and operational procedures are outlined:

• Running the ASN.1 Editor Tool:
  • Access the tool via a web browser at http://<ip>/lte/asn1.html from a callbox or UEsim, or launch the editor from the Tech Academy platform.
  • Alternatively, use the provided shortcut link for direct access from Tech Academy.
• Understanding Icons and Editor Navigation:
  • The editor displays various icons indicating actions or item types; users should refer to these icons and the [Info] field for guidance at each step.
• Manual ASN.1 Message Creation:
  • ASN.1 messages use a tree structure, allowing multiple creation paths.
  • Users should follow the [Info] field prompts and perform the indicated actions until the field is cleared, indicating completion.
  • Manual creation is recommended initially to familiarize users with the editor before utilizing automated features.
• Automatic Mandatory IE Creation:
  • The editor provides a feature to automate the insertion of mandatory Information Elements (IEs) with a single button click, streamlining routine message construction.
• Using Ready-Made Templates:
  • Users can load example ASN.1 files (such as SIB1, SIB2, MeasConfig-A3, etc.) provided in the tutorial, modify them as necessary, and use them as templates for new messages.
• Compatibility Testing between *.jer and *.asn Files:
  • Open a *.asn configuration file in the ASN Editor GUI and verify error-free loading.
  • Save the file as *.jer format using the editor.
  • Reference the *.jer file in an LTE configuration file and specify content type as "application/json." Set parameters such as si_periodicity as needed.
  • Restart the LTE service and confirm there are no errors during service initialization.
• File Format Conversion Test:
  • Convert between *.asn (gser format) and *.jer (jer format) using the lte_toolbox command-line utility:
  • • To convert *.asn to *.jer: ./lte_toolbox asn1-convert /tmp/sib1_orig.asn sib gser jer > /tmp/sib1_orig.jer
    • To convert *.jer to *.asn: ./lte_toolbox asn1-convert /tmp/sib1.jer sib jer gser > /tmp/sib1.asn

Overall, the tutorial provides a comprehensive workflow for operating the ASN.1 editor, creating and modifying ASN.1 messages, ensuring compatibility between file formats, and performing format conversion for integration into LTE configurations.

How to Run

You can run the Amarisoft ASN.1 editor either directly from your Callbox or UEsim, or you can run it from the Amarisoft Tech-Academy web page. In most test environments, running it from the Callbox or UEsim is convenient because the tool is already available on the equipment and you can access it from a normal web browser without installing any additional software.

If you want to run the ASN.1 editor from your own Callbox or UEsim, open a web browser and enter the following URL.

         http://<ip>/lte/asn1.html

Here, <ip> should be replaced with the IP address of your Callbox or UEsim. For example, if the IP address of your equipment is 192.168.100.15, you can access the editor by entering http://192.168.100.15/lte/asn1.html in the browser address bar. Once the page is loaded, you should see the ASN.1 editor screen with the Open, Save, and New buttons at the top-left side. The version information of the editor is usually shown at the top-right side of the page.

You can also run the same ASN.1 editor from the Amarisoft Tech-Academy page. This is useful when you do not have immediate access to a Callbox or UEsim, or when you simply want to check or edit an ASN.1 message from a PC connected to the internet. In this case, open the Tech-Academy ASN.1 editor page directly from the browser, or simply click the provided link in the tutorial.

In both cases, the basic operation is the same. The editor runs inside the browser, so you do not need to install a separate ASN.1 decoding tool on your PC. You can open an existing ASN.1 message, create a new one, edit the decoded fields in a structured form, and then save or copy the resulting message depending on your test purpose. For Amarisoft testing, this is especially useful when you want to generate or modify RRC/NAS-related ASN.1 structures without manually editing the full encoded message by hand.

You can run the ASN.1 editor from tech academy as shown below or simply click on this.

Icons

The ASN.1 editor shows different icons and input fields depending on where you are in the ASN.1 message tree. These icons are useful because they tell you what kind of operation is available for the currently selected item. In many cases, you do not need to manually remember the full ASN.1 structure. Instead, you can follow the available icons and menu items shown by the editor.

The Add missings button creates all mandatory IEs for the message or structure that you are currently editing. This is useful when you start from an empty or partially created message, because the editor can automatically insert the mandatory fields that are required by the ASN.1 definition. However, this does not mean that all values are already correct for your test case. It only creates the required structure, so you still need to check and fill in the actual values properly.

The Add element field is used when a new item can be added under the current ASN.1 node. When you click this field, the editor usually shows a dropdown list, and you can select one of the allowed elements from that list. This is commonly used when the current IE supports optional fields or a sequence of multiple elements.

The Add all mandatory properties option creates all mandatory fields for the specific IE that you selected. This is similar to Add missings, but the scope is usually more local. It applies to the selected IE rather than the whole message. This is useful when you add a new IE and want the editor to automatically populate the required child fields under that IE.

The red X icon removes the corresponding item from the ASN.1 tree. You need to be careful with this icon because it may remove not only one small value, but also a large branch with many child fields under it. If you accidentally delete a large structure, you may lose changes that took a long time to create. So before clicking the red X, always check which tree item the icon belongs to.

The green plus icon adds a new item in a sequence-type IE. This is used when the ASN.1 field can contain multiple entries, such as a list of cells, a list of DRBs, a list of measurement objects, or any other repeated structure. When you click this icon, the editor creates another entry with the same type under the selected sequence.

The up and down arrow icons move an item within the tree. These icons are used when the order of items in a sequence can be changed. In many ASN.1 messages, the order is either fixed by the encoding rule or handled by the editor, but for sequence-type lists, moving an item up or down can be useful when you want to organize the structure or adjust the order of repeated entries.

The green check and red minus toggle icons indicate a field that can have two different states, such as enabled/disabled, present/absent, true/false, or another binary status depending on the ASN.1 definition. When you click the icon, the value toggles to the other state. This kind of field is convenient because you do not need to type the value manually.

The blue circular arrow icon creates all mandatory IEs recursively for the selected IE. This means it does not only add mandatory fields directly under the selected item, but also continues adding mandatory child fields under those newly created fields. This can quickly generate a complete nested structure. It is useful when you want to build a valid ASN.1 branch quickly, but you should still review the generated fields carefully because mandatory structure creation does not automatically choose test-specific values for you.

Creating a New ASN.1

The overall flow of creating a new ASN.1 message in the Amarisoft ASN.1 editor is to start from an empty message, select the top-level ASN.1 type, and then keep building the tree by following the guidance shown in the Info column. ASN.1 messages are tree-structured, so there can be several different ways to reach the same final structure. The exact sequence of clicks may also look slightly different depending on the ASN.1 editor version or the message type you selected. Therefore, the most important thing is not to memorize every click, but to understand how to read the editor screen and how to react to the missing-item or validation messages shown in the Info column.

First, click the New button and select the ASN.1 type that you want to create. In this example, EUTRA BCCH-DL-SCH-Message is selected because the target message is LTE SIB1. After the top-level BCCH-DL-SCH-Message node is created, the editor shows Add element... in the Value field and reports Missing message element in sequence in the Info column. This means that the next required IE is message, so you open the dropdown in the Value field and select message.

After message is added, the editor reports Missing choice. This means the current node is an ASN.1 CHOICE type, and you need to select one of the available branches. In this example, c1 is selected because SIB1 is carried under the normal c1 branch. Then the editor reports Missing choice again because c1 itself contains another CHOICE. At this point, select systemInformationBlockType1, because the purpose of this example is to create SIB1. Now the basic message path is created as BCCH-DL-SCH-Message → message → c1 → systemInformationBlockType1.

Once systemInformationBlockType1 is created, the editor begins to guide you through the mandatory fields inside SIB1. For example, it first reports Missing cellAccessRelatedInfo element in sequence, so you select cellAccessRelatedInfo from the dropdown. Then it reports other missing mandatory fields such as cellSelectionInfo, plmn-IdentityList, freqBandIndicator, schedulingInfoList, si-WindowLength, and systemInfoValueTag. You can add these in a slightly different order, but it is usually easier to keep working from the first missing item shown in the Info column until that part is cleared. This gives you a simple rule to follow: whenever the Info column says Missing something element in sequence, add that item from the Value dropdown.

Some fields are list-type fields, and for those fields the editor may say that at least one element is required in sequence. In this case, you need to click the green plus icon to add an entry into the list. For example, schedulingInfoList requires at least one sequence entry, and plmn-IdentityList also requires at least one PLMN identity entry. After the entry is created, the editor continues to guide you into the child fields of that sequence. This is why the tree gradually expands level by level as you keep following the Info column.

Inside plmn-IdentityList, the editor asks for plmn-Identity, and inside plmn-Identity it asks for MCC and MNC. Since MCC and MNC are also represented as digit sequences, you need to add the required number of digit entries using the green plus icon. For MCC, the editor requires three digits, so you add three entries. For MNC, the editor requires at least two digits, so you add two entries. You may enter the real MCC and MNC values immediately, but during the first tree-building stage, it is also acceptable to leave default values temporarily and focus on clearing the structural requirements first.

After all mandatory nodes are created, the remaining messages in the Info column are often value-related errors rather than missing-node errors. For example, trackingAreaCode may show Bit string too short, field requires 16 bits, cellIdentity may show Bit string too short, field requires 28 bits, and q-RxLevMin may show a range error such as the value must be at most -22. These messages mean that the required fields already exist in the ASN.1 tree, but the current values are not valid. In this case, you do not add another child IE. You simply type a valid value directly into the Value field.

You may also add optional IEs after the mandatory structure is created. Optional fields are not always required for the ASN.1 message to be valid, so whether you add them depends on the purpose of your test. In this example, optional or configurable items such as p-Max, freqBandIndicator, and schedulingInfoList are included. The editor allows you to add these items from the dropdown when they are supported under the selected node.

The key point is to distinguish between two types of problems shown in the Info column. If the Info column says Missing element, Missing choice, or At least one element in sequence is required, it usually means that you need to add a node, select a CHOICE branch, or add a sequence entry. If the Info column says Bit string too short or shows a numeric range error, it means the node already exists but its value is invalid. Once you understand this difference, creating an ASN.1 message becomes a repetitive and predictable process: add missing nodes, select required choices, add sequence entries, and finally correct the leaf values until the remaining errors are cleared.

Although the editor provides shortcut functions that can automatically create many mandatory fields with one button click, it is strongly recommended to go through this manual process at least once. The manual process helps you understand how ASN.1 trees are structured and how the editor uses the Info column to guide you. After you become familiar with this flow, you can use the shortcut method to create the same structure much faster and then focus mainly on modifying the values for your specific test scenario.

NOTE : At this point, large portions of the message creation process can be automated by single button click. Check out this section.  I would recommend you to go through the manual process at least once to get yourself familiar with how the editor works. Later on, you can just go to this shortcut.

Automatic Mandatory IE Creation

You might have noticed from the previous manual procedure that a large part of ASN.1 message creation is simply adding mandatory IEs one by one. Since these IEs are mandatory, there is usually no design decision involved at this stage. You just have to create the required branches mechanically until the message tree satisfies the ASN.1 structure. The Amarisoft ASN.1 editor can automate this process by using the Add missings button.

In this example, the message tree has already been created up to EUTRA BCCH-DL-SCH-Message → message → c1 → systemInformationBlockType1. At this point, the Info column still shows Missing cellAccessRelatedInfo element in sequence, and the top area of the editor also indicates that there are several missing properties. Instead of manually adding cellAccessRelatedInfo, plmn-IdentityList, cellSelectionInfo, q-RxLevMin, schedulingInfoList, si-WindowLength, and other mandatory items one by one, you can click the Add missings button.

When you click Add missings, the editor automatically creates the mandatory IEs under the current message structure in a single operation. In the screenshot, you can see that the tree is expanded automatically and many required fields are created at once, including cellAccessRelatedInfo, plmn-IdentityList, plmn-Identity, mnc, cellReservedForOperatorUse, trackingAreaCode, cellIdentity, cellBarred, intraFreqReselection, csg-Indication, cellSelectionInfo, q-RxLevMin, freqBandIndicator, schedulingInfoList, si-Periodicity, sib-MappingInfo, and si-WindowLength. This saves a lot of repetitive clicking compared to the manual method.

However, Add missings does not mean that the message is completely finished. It mainly creates the mandatory ASN.1 structure. Some values may still be missing, invalid, or only filled with default values. For example, trackingAreaCode may still show Bit string too short because it requires a 16-bit value, and cellIdentity may still show Bit string too short because it requires a 28-bit value. These are not missing-IE problems anymore. They are value-entry problems. The required fields already exist, but you still need to type valid values into those fields.

This is why the automatic method should be understood as a structure-generation shortcut, not as a complete SIB1 configuration generator. It creates the mandatory ASN.1 nodes quickly, but it does not know your intended PLMN, TAC, cell identity, frequency band, cell selection parameters, SIB scheduling, or other test-specific settings. After using Add missings, you should still review the generated tree carefully and modify the actual values according to your test scenario.

The recommended way to learn the editor is to create the message manually at least once, as shown in the previous section. That manual process helps you understand how the Info column guides you, how CHOICE and SEQUENCE fields work, and how missing-node errors are different from invalid-value errors. Once you understand that flow, you can use Add missings as a shortcut. In normal usage, this is much faster: create the top-level message path, click Add missings to generate the mandatory structure, and then focus on correcting the remaining values and adding any optional IEs required for your test.

Ready-Made Templates

In addition to creating a new ASN.1 message from scratch, you can also start from a ready-made template. This is often the easiest way to use the ASN.1 editor in a real test environment because many ASN.1 messages have a large tree structure, and creating every branch manually can take time. The templates listed here are example ASN.1 files that were created from working configurations or decoded from working logs, so they are practically meaningful starting points rather than artificial examples.

You can open one of these template files in the ASN.1 editor and modify only the fields that are important for your test. For example, if you want to create or modify LTE SIB1, you can start from the LTE - SIB1 template instead of building BCCH-DL-SCH-Message, message, c1, systemInformationBlockType1, cellAccessRelatedInfo, cellSelectionInfo, schedulingInfoList, and all other required branches manually. After opening the template, you can change values such as PLMN, TAC, cell identity, q-RxLevMin, frequency band, scheduling information, or other test-specific parameters.

The same idea applies to other templates as well. LTE - SIB2 and LTE - SIB23 can be used when you want to study or modify system information messages. LTE - MeasConfig-A3 can be used as a starting point for measurement configuration related to Event A3. LTE - MeasConfig-CGI-LteIoT can be useful when you want to look into CGI-related measurement configuration. NB IoT - SIB1 provides an NB-IoT SIB1 example. Cat M - SIB2,3 : 2CE Levels provides an example related to LTE-M coverage enhancement levels. Redirection Carrier Info - NR can be used when you want to study or modify LTE-to-NR redirection-related ASN.1 information.

Using a template does not mean you can skip validation. A template may be structurally valid, but some values may still need to be changed according to your own test setup. For example, PLMN, EARFCN/ARFCN, PCI-related assumptions, TAC, cell identity, frequency band, bandwidth, SIB scheduling, measurement object, report configuration, or redirection target information may be different in your environment. So after opening a template, you should still check the Info column and make sure there are no remaining errors or invalid values.

In normal usage, templates are the fastest method. The manual method is useful for learning how the ASN.1 tree is built, and the Add missings button is useful for automatically creating mandatory IEs. But once you understand the structure, a ready-made template is usually the most practical starting point. You can open the closest matching example, modify only the necessary fields, save the revised ASN.1 file, and then use it for your Amarisoft test scenario.

• LTE - SIB1
• LTE - SIB2
• LTE - SIB23
• LTE - MeasConfig-A3
• LTE - MeasConfig-CGI-LtoL
• NB IoT - SIB1
• Cat M - SIB2,3 : 2CE Levels
• Redirection Carrier Info - NR

Tips

Compatibility between *.jer and *.asn file

In the Amarisoft ASN.1 editor, a *.jer file means the file saved by the ASN.1 Editor GUI, and a *.asn file usually means the ASN.1 message file used directly by Amarisoft configuration files, for example the *.asn files located under /root/enb/config. These two formats are compatible in practice, so you can open an existing *.asn file in the ASN.1 editor, modify it in the GUI, save it as a *.jer file, and then use that saved file again from the Amarisoft configuration.

One important point is that when you use a *.jer file in the Amarisoft configuration, you should specify the content type as application/json. This is because the file saved from the ASN.1 Editor GUI is JSON-based. The ASN.1 contents are still representing the same ASN.1 message structure, but the file format used by the editor is different from the plain *.asn file format used in some original configuration examples.

You can try the following procedure to confirm the compatibility. First, open an existing ASN.1 file such as sib2_3.asn from /root/enb/config in the ASN.1 Editor GUI. If the file is compatible and the message is valid, the editor should load it without an error and show the decoded tree structure. Then save the same message from the ASN.1 Editor GUI as a new file, for example sib2_3.jer. After that, specify this newly saved *.jer file in the LTE configuration file such as enb.default.cfg.

For example, the SIB scheduling configuration may look as follows.

• i) Open sib2_3.asn (located in /root/enb/config) in ASN Editor GUI (You should see that the file is read without any error)
• ii) Save it to a file (e.g, sib2_3.jer) in ASN Editor GUI
• iii) Specify sib2_3.jer in any lte configuration file (e.g, enb.default.cfg) as follows.

sib_sched_list: [       {         filename: "sib2_3.jer",  /* the file created by ASN Editor GUI */         content_type: "application/json", /* Specify the contents type when you using *.jer file */         si_periodicity: 16, /* frames */       },     ],

• iv) Run lte service ('service lte restart') and confirm there is no error in (enb) screen

After modifying the configuration, restart the LTE service by running service lte restart and check the eNB screen or log to confirm that there is no ASN.1 loading or parsing error. If the service starts normally and no error is reported, it means the *.jer file saved by the ASN.1 editor is being accepted correctly by the Amarisoft configuration.

This compatibility is useful because you do not have to manually edit complicated ASN.1 files in text form. You can start from an existing working *.asn file, open it in the GUI editor, modify the fields in a structured tree view, save it as *.jer, and then reference the new file from the Amarisoft configuration. This gives you a much safer workflow, especially for large messages such as SIB2/SIB3, measurement configuration, redirection carrier information, or NB-IoT and LTE-M system information.

Conversion between *.jer and *.asn file

If you want to explicitly convert a file between *.jer and *.asn format, you can use the lte_toolbox program located under /root/ots. This is useful when you want to move between the GUI-friendly ASN.1 editor format and the format commonly used in Amarisoft configuration examples.

For example, if you have an original ASN.1 file named sib1_orig.asn and you want to convert it into a *.jer file that can be opened or reused with the ASN.1 editor, you can run the following command.

      ./lte_toolbox asn1-convert /tmp/sib1_orig.asn sib gser jer > /tmp/sib1_orig.jer

In this command, /tmp/sib1_orig.asn is the input file, sib indicates the ASN.1 message type, gser indicates the input format, and jer indicates the output format. The output is redirected to /tmp/sib1_orig.jer. In other words, this command converts the original *.asn file from GSER format into the JER format used by the ASN.1 editor.

If you want to convert in the opposite direction, from *.jer back to *.asn, you can run the following command.

     ./lte_toolbox asn1-convert /tmp/sib1.jer sib jer gser > /tmp/sib1.asn

In this case, /tmp/sib1.jer is the input file, sib is again the ASN.1 message type, jer is the input format, and gser is the output format. The result is saved as /tmp/sib1.asn. This command converts the JSON-based JER file back into the GSER-style ASN.1 file.

The important point is the order of the last two parameters. In the first example, gser jer means the input is GSER and the output is JER. In the second example, jer gser means the input is JER and the output is GSER. So if the conversion does not work as expected, first check whether the input file format and the last two parameters are matched correctly.

This conversion is useful when you want to combine both workflows. You can take an existing *.asn file from /root/enb/config, convert it to *.jer, edit it more conveniently in the ASN.1 Editor GUI, and then either use the *.jer file directly in the Amarisoft configuration with content_type: "application/json", or convert it back to *.asn if you prefer to keep the original GSER-style configuration file format.

./lte_toolbox asn1-convert /tmp/sib1_orig.asn sib gser jer > /tmp/sib1_orig.jer    ==> Convert *.asn to *.jer (Convert gser format to jer format) ./lte_toolbox asn1-convert /tmp/sib1.jer sib jer gser > /tmp/sib1.asn  ==> Convert *.jer to *.asn (Convert jer format to gser format)