NR Rrc Inactive

The purpose of this tutorial is to show you how to test RrcInactive status.  In this tutorial, I assume that you are familiar with basic operations of callbox and I would not explain the very basic operational procedure. I will just explain about the important configurations and how you can confirm on those configuration from the log.

RrcInactive in NR is a mechanism to park the communication in a kind of dormant mode without releasing RRC. The advantage of putting the communication into this mode comparing to releasing RRC is that it can switch back to the normal communication mode much more quickly then the case of RrcRelease.

Overall procedure (statemachine) for switching back and forth between RRC Connected and RRC Inactive is as follows.

Image Source : Sharetechnote

Table of Contents

• NR Rrc Inactive
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Configuration
• Perform the Test
• Log Analysis
• RRC / NAS Signaling
• RrcRelease (SA)
• Paging (SA)
• RrcResumeRequest (SA)
• RrcResume (SA)
• RrcResumeComplete (SA)

Introduction

RRC Inactive is a pivotal feature introduced in 5G New Radio (NR) systems, designed to enhance both user experience and network efficiency by introducing a new state in the Radio Resource Control (RRC) state machine. Unlike legacy LTE systems, where mobile devices transition between RRC Connected and RRC Idle states, 5G NR leverages the RRC Inactive state to allow User Equipment (UE) to remain in a semi-dormant mode, conserving signaling overhead and reducing latency for state transitions. Architecturally, this innovation addresses the need for ultra-fast resumption of data sessions while minimizing battery consumption and network resource utilization, especially in scenarios characterized by frequent but sporadic data exchanges such as IoT applications or instant messaging. The RRC Inactive state maintains essential UE context at both the gNodeB (next-generation NodeB) and the Access and Mobility Management Function (AMF), enabling rapid state transitions without the need for full connection establishment procedures. This mechanism is crucial in supporting 5G use cases that demand high mobility, low latency, and efficient network operation. Understanding and testing RRC Inactive status is therefore essential for engineers and network operators aiming to optimize 5G deployments, troubleshoot state transition behaviors, and ensure compliance with 3GPP standards. This tutorial provides an in-depth examination of the RRC Inactive state, focusing on the procedural aspects, configuration parameters, and log verification techniques necessary for effective testing in a controlled environment.

• Context and Background
  • RRC Inactive is a new state introduced in the 5G NR RRC state machine to bridge the gap between RRC Connected and RRC Idle.
  • It is designed to optimize signaling efficiency, reduce energy consumption, and enable fast state transitions for UEs.
  • The architecture relies on maintaining UE context at both the gNodeB and the core network (AMF), allowing session resumption without complete re-establishment procedures.
• Relevance and Importance of This Tutorial
  • Testing RRC Inactive status is critical for verifying network implementations and UE behavior in compliance with 5G standards.
  • Proper understanding and configuration of RRC Inactive improves network efficiency, reduces latency, and enhances user experience.
  • Operators and engineers benefit from reduced signaling load and improved battery life for connected devices.
• What You Will Learn
  • Key configuration parameters involved in enabling and testing RRC Inactive state on a callbox environment.
  • Procedural steps for transitioning UEs between RRC Connected and RRC Inactive, and methods for confirming state transitions using logs.
  • Best practices for interpreting log data to verify correct network and UE behavior during state transitions.
  • Architectural insights into how RRC Inactive supports advanced 5G use cases and optimizes network resource management.
• Prerequisite Knowledge
  • Familiarity with basic callbox operations and test equipment procedures.
  • Understanding of 5G NR architecture, including gNodeB, AMF, and RRC protocol fundamentals.
  • Ability to interpret network logs and basic troubleshooting skills in a radio access network environment.

Summary of the Tutorial

This tutorial demonstrates the test procedure for verifying the NR RRC Inactive feature using a callbox and a UE (User Equipment). The process involves configuring both the gNB and MME, connecting the UE, and observing RRC state transitions, particularly focusing on the RRC Inactive and Resume mechanisms.

• Test Setup:
  • Use the provided SIM card unless configuration change is required.
  • Refer to the Configuration Guide for any changes to the setup.
• Key Configuration Parameters:
  • Configure rrc_inactive and its associated parameters in the gNB configuration file, including:
    • use_full_resume_id
    • rna_cell_list (with plmn and cell_id_list)
    • rna_ranac_list (with tac and ranac_list)
    • ran_paging_cycle
    • t380_mins
    • inactivity_timer
    • release_timer_mins
  • In the MME configuration, enable cn_assistance_info_support to support RRC Inactive.
• Configuration Steps:
  • Start from gnb-sa.cfg and modify it to create gnb-sa-rrc-inactive.cfg with the necessary RRC Inactive settings.
  • Edit mme-ims.cfg to produce mme-ims-cn-assistance.cfg and set cn_assistance_info_support to true.
  • Add the rrc_inactive object in the gNB configuration, ensuring cell_id_list is correctly set (28-bit binary from concatenated gNB and Cell IDs).
• Test Execution Procedure:
  • Verify cell configuration using cell phy and cell commands, and ensure compatibility with the UE.
  • Power on the UE and ensure it attaches to the cell.
  • Confirm the UE is registered to the MME and has at least one IP address assigned.
  • Wait for the UE to enter the RRC Inactive state when there is no traffic; this is indicated by "[inactive]" in the trace log.
  • Trigger RRC Resume by initiating user data (e.g., ping command) from the callbox. The first ping reply may be delayed due to the Resume process, which includes RAN Paging and other procedures.
  • Observe the RRC Resume process, where the UE transitions back to RRC Connected upon user data activity.
• Log Analysis:
  • Check the UE capability information to ensure RRC Inactive support is advertised.
  • If no higher layer data traffic is present for the configured duration, the network triggers the switch to RRC Inactive (RrcRelease with suspendConfig).
  • While in RRC Inactive, triggering data traffic (e.g., ping) initiates the Resume process. Proper ue-Identity must be used, matching the suspendConfig.
  • Upon paging, the UE sends a Resume Request (with resumeIdentity matching suspendConfig).
  • The gNB responds with an RRC Resume message, containing all necessary configuration to reestablish the connection.
  • If the UE receives and applies the RRC Resume message, it sends an RRC Resume Complete message.
  • Repeated inactivity will again transition the UE to RRC Inactive; subsequent user activity will repeat the resume process.

Key Points:

• Correct configuration of both the gNB and MME is essential for RRC Inactive functionality.
• UE capability for RRC Inactive must be verified before running the test.
• The test validates the state transitions between RRC Connected, RRC Inactive, and back to Connected, triggered by user data activity and network inactivity timers.
• Log analysis focuses on confirming state transitions and matching identities used throughout the suspend and resume procedures.

Test Setup

Test setup for this tutorial is as shown below.  (NOTE: Since TDD UL/DL configuration gets configured into SIB1 message and you may not need to get UE connected to the callbox if you just want to check the SIB1 as in this tutorial)

• 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

Key Configuration Parameters

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

• rrc_inactive : In this link, you will get the descriptions for all items listed below.
• use_full_resume_id
• rna_cell_list
• plmn
• cell_id_list
• rna_ranac_list
• tac
• ranac_list
• ran_paging_cycle
• t380_mins
• inactivity_timer
• release_timer_mins

Configuration

I used the configuration gnb-sa-rrc-inactive.cfg which is copied from gnb-sa.cfg and modified for this tutorial.

I have used mme-ims-cn-assistance.cfg which is copied from mme-ims.cfg and modified. RRC Inactive involves core network feature as well as gNB configuration, so I created a special configuration file for mme configuration as well.

In gnb-sa-rrc-inactive.cfg, add rrc_inactive object as shown below. In this configuration, rna_cell_list, inactivity_timer, and release_timer_mins are the important parameters. The rna_cell_list defines the RNA, or RAN Notification Area, where the UE can stay in RRC Inactive state. The inactivity_timer defines how long the UE can remain without user-plane activity before the network moves it to RRC Inactive. The release_timer_mins defines how long the suspended UE context can be kept before it is finally released.

Inside rna_cell_list, cell_id_list defines the cell identity included in the RNA. This value should be a 28-bit cell identity in binary representation. You can create this value by concatenating the gNB ID and the Cell ID. This is the same cell identity that is broadcast in SIB1.

In this example, use_full_resume_id is set to false. This means the UE uses the short resume identity instead of the full resume identity during the resume procedure.

The ran_paging_cycle is set to 32. This defines the RAN paging cycle used when the network needs to page the UE while it is in RRC Inactive state.

The inactivity_timer is set to 5000. This means that if there is no activity for this timer duration, the gNB can suspend the RRC connection and move the UE to RRC Inactive by sending RRC Release with suspendConfig.

The release_timer_mins is set to 1000. This means the gNB can keep the suspended UE context for this duration. If the context is still not resumed within this time, the context can be released and the UE may need to perform a normal RRC connection establishment again.

In mme-ims-cn-assistance.cfg , add the parameter cn_assistance_info_support as show below.  This parameter should be set to true in order to enable RRC Inactive functionality.

When cn_assistance_info_support is set to true, the AMF sends Core Network Assistance Information to the gNB during the Initial Context Setup procedure. This information is needed by the gNB to support RRC Inactive operation properly.

In RRC Inactive, the UE context is not fully released. Instead, part of the UE context is kept so that the UE can resume the connection quickly later. For this mechanism to work, the gNB needs assistance information from the core network. Therefore, this parameter should be enabled on the core network side as well as configuring rrc_inactive on the gNB side.

In this example, the following line is added in the MME/AMF configuration.

cn_assistance_info_support: true,

After this is configured, you can check the log and confirm that the network sends Core Network Assistance Information in the Initial Context Setup message. This confirms that the core network side is prepared to support RRC Inactive.

Perform the Test

First, check the basic cell configuration using the cell phy and cell commands. Make sure that the cell is configured as expected and that the values match your UE capability.

From the cell phy output, you can confirm the basic NR cell configuration such as band, bandwidth, ARFCN, antenna configuration, subcarrier spacing, and modulation. In this example, the cell is configured as NR band n78 with 20 MHz bandwidth. The DL and UL ARFCN are both 632628, and the subcarrier spacing is 30 kHz.

You also need to check the gNB ID and Cell ID because these values are used to create the cell_id_list value in the rrc_inactive configuration. In this example, the gNB ID is 0x12345 and the Cell ID is 0x001.

The cell_id_list value is created by concatenating the gNB ID and the Cell ID. This value should match the NR Cell Identity broadcast in SIB1. Therefore, before testing RRC Inactive, you should confirm that the gNB ID and Cell ID shown by the cell command are the same as the values used in the configuration file.

In this example, the cell command shows the same cell ID, 0x001, and the same gNB ID, 0x12345. This means the value used in cell_id_list is consistent with the actual cell configuration.

Power on the UE and wait until the UE attaches to the cell.

You can start the real-time trace by running the t command from the eNB/gNB console. Once the UE starts accessing the cell, you should see PRACH detection first. In this example, PRACH is detected on cell 01 with sequence index 1. The timing advance is 5 and the PRACH SNR is around 20.4 dB, which confirms that the gNB has detected the UE’s random access preamble.

After the UE completes the access procedure, you can see the UE information in the trace output. The UE is assigned UE_ID 1 and C-RNTI 0x4601 on cell 001. This indicates that the UE is now connected to the cell.

From the trace, you can also check basic radio quality and data activity. In this example, the downlink CQI is 12, rank indicator is 2, and the downlink SNR is around 37 dB. The output also shows downlink and uplink MCS, retransmission count, transport block rate, power headroom, path loss, and timing advance.

At this point, the UE is attached and in RRC Connected state. This is the starting condition before testing the transition from RRC Connected to RRC Inactive.

Make sure that the UE is registered to the MME/AMF. You should also confirm that at least one IP address is assigned to the UE.

You can check this using the ue command from the MME console. In this example, the UE with SUPI 001010123456789 is registered to the core network. The REG field is set to Y, which means the UE registration is completed successfully.

The output also shows that the UE is connected through 5GC and has one bearer established. The IP_ADDR field shows 192.168.2.2, which means an IP address has been assigned to the UE.

This confirms that the UE is not only connected at the radio side, but also properly registered at the core network side. At this point, the UE is ready for the RRC Inactive test.

When there is no traffic for the duration configured by inactivity_timer, the gNB moves the UE from RRC Connected to RRC Inactive.

You can confirm this from the real-time trace. When the UE is in normal RRC Connected state, the trace shows normal DL and UL radio information such as CQI, RI, MCS, bitrate, SNR, power headroom, path loss, and timing advance.

After the inactivity timer expires, the UE state changes to RRC Inactive. In the trace log, this is shown by the [inactive] print. In this example, UE_ID 13 with C-RNTI 0x460d enters RRC Inactive state, and the trace repeatedly shows [inactive] instead of normal traffic information.

This confirms that the RRC connection has not been fully released. Instead, the UE context is suspended and the UE is kept in RRC Inactive state.

When the UE needs to send or receive data again, it resumes the connection. In the trace, you can see PRACH again when the UE resumes from RRC Inactive. After that, normal DL and UL traffic information appears again in the trace. This indicates that the UE has switched back from RRC Inactive to RRC Connected state.

So, the important confirmation points are as follows. First, [inactive] should be printed in the trace after the inactivity period. Second, when traffic starts again, PRACH should be observed. Third, after the resume procedure, normal radio statistics should appear again, confirming that the UE has returned to connected state.

When the UE is in RRC Inactive state, you can trigger the resume procedure from the callbox side by sending ping traffic to the UE IP address.

In this example, ping is sent from the callbox to 192.168.3.2. Since the UE is already in RRC Inactive state, the first ping packet cannot be delivered immediately in the same way as in RRC Connected state. The network first needs to bring the UE back from RRC Inactive to RRC Connected.

Because of this, the time value for the first ping reply is usually much longer than the following ping replies. In this example, the first reply takes 483 ms, while the later replies are much shorter, such as 22.5 ms, 21.2 ms, 40.3 ms, and so on.

This long delay for the first ping is expected. It includes the time required for the resume procedure. During this process, the network may perform RAN paging, the UE responds and resumes the RRC connection, and a few additional signaling steps are completed before user-plane traffic can continue.

After the resume procedure is completed, the UE returns to RRC Connected state. Then the following ping packets can be delivered with normal latency. This is why only the first ping reply usually shows a large delay, while the later ping replies become much faster.

RRC resumes when user traffic is triggered. In this example, the trigger is ping data sent to the UE.

Before the traffic starts, the UE is in RRC Inactive state. In the trace log, this is shown by the repeated [inactive] print for the UE. This means the UE context is suspended, but the UE is not fully released to RRC Idle.

When higher-layer traffic is generated, the UE needs to resume the RRC connection before the user data can be exchanged. During this resume procedure, you can see that the RACH process is triggered again in the trace log.

In this example, after the [inactive] state, PRACH is detected again with sequence index 3, timing advance 5, and SNR around 17.3 dB. This PRACH detection indicates that the UE has started the resume procedure to return from RRC Inactive to RRC Connected.

After the resume procedure, normal DL and UL radio statistics are printed again. The trace shows CQI, RI, MCS, bitrate, SNR, power headroom, path loss, and timing advance. This confirms that the UE has resumed the connection and switched back to RRC Connected state.

One thing to note is that the C-RNTI may change after the resume procedure. In this example, the UE was shown with C-RNTI 0x4610 before resume, and after PRACH it is shown with C-RNTI 0x4611. This indicates that the UE has gone through the access and resume process and is now active again with a new radio context in the trace.

Log Analysis

Sample Log

First, check whether the UE supports RRC Inactive from the UE Capability Information message. This is one of the most important points to confirm before analyzing the RRC Inactive procedure.

In the log, open the UE Capability Information message and check whether inactiveState is included in the UE capability. If the UE reports inactiveState supported, it means the UE can support NR RRC Inactive operation.

This check is important because RRC Inactive is not triggered only by the gNB configuration. Even if rrc_inactive is configured correctly in the gNB configuration file and cn_assistance_info_support is enabled in the core network configuration, the network may not move the UE to RRC Inactive if the UE does not report this capability.

In this example, the UE Capability Information message includes inactiveState supported. This confirms that the UE supports RRC Inactive. Therefore, the gNB can proceed with the RRC Inactive procedure when the inactivity condition is met.

So, the first checkpoint in log analysis is to confirm inactiveState supported in the UE Capability Information message. Without this capability, the RRC Inactive procedure may not be triggered.

NOTE : This is very important to check. If the UE does not notify this capability, gNB will not trigger RRC Inactive state even if all the configuration is correctly set in the configuration file.

If there is no higher-layer data traffic for the duration configured by inactivity_timer, the network triggers the transition from RRC Connected to RRC Inactive.

In the log, this transition is shown by an RRC Release message sent from the gNB to the UE. This RRC Release is different from a normal release to RRC Idle because it includes the suspendConfig IE.

The suspendConfig IE provides the information required for the UE to suspend the current RRC context and resume the connection later. In this example, the RRC Release message includes suspendConfig, and inside it you can see important resume-related parameters such as fullI-RNTI, shortI-RNTI, ran-PagingCycle, ran-NotificationAreaInfo, t380, and nextHopChainingCount.

The fullI-RNTI and shortI-RNTI are used to identify the UE when it later resumes the connection. The ran-PagingCycle defines the paging cycle used while the UE is in RRC Inactive. The ran-NotificationAreaInfo provides the RNA information, including the PLMN identity and the RAN area cell list. This tells the UE the area where it can remain in RRC Inactive without performing a full registration or connection establishment again.

In this example, the presence of RRC Release with suspendConfig confirms that the network is not simply releasing the UE to RRC Idle. Instead, the network is suspending the RRC connection and moving the UE into RRC Inactive state.

If you trigger data traffic while the UE is in RRC Inactive state, the network starts the resume procedure. In this example, the trigger is ping traffic sent from the callbox side to the UE.

Since the UE is in RRC Inactive state, the gNB cannot send the user-plane data directly in the same way as in RRC Connected state. First, the gNB sends a Paging message to wake up the UE and trigger the resume procedure.

In the log, you can see the Paging message sent from the gNB. Inside the pagingRecordList, the ue-Identity is included. This UE identity should match the identity that was provided earlier in the suspendConfig IE of the RRC Release message.

In this example, the Paging message includes ue-Identity fullI-RNTI 1234504601H. This is the same UE identity that was assigned in the suspendConfig when the UE was moved to RRC Inactive. This confirms that the network is paging the correct suspended UE context.

After receiving this paging, the UE starts the resume procedure. The following messages in the log show RRC Resume Request, then RRC Resume, and finally RRC Resume Complete. This confirms that the paging successfully triggered the UE to resume from RRC Inactive back to RRC Connected state.

In response to the Paging message, the UE sends an RRC Resume Request message to the gNB.

In the RRC Resume Request message, you can check the resumeIdentity IE. This identity is associated with the I-RNTI that was assigned earlier in the suspendConfig IE of the RRC Release message.

In this example, the RRC Resume Request includes resumeIdentity 504601H. This value is related to the shortI-RNTI that was provided to the UE when the UE was moved to RRC Inactive state.

The message also includes resumeMAC-I. This is used by the network to verify that the resume request is coming from the correct UE context. In this example, resumeMAC-I is F474H.

The resumeCause is shown as mt-Access. This means the resume procedure was triggered by mobile-terminated access. This matches the test scenario because the callbox side generated ping traffic toward the UE while the UE was in RRC Inactive state.

So, this log confirms that the UE received the paging, recognized that it should resume the suspended connection, and sent RRC Resume Request using the resume identity associated with the previously assigned suspendConfig information.

The callbox sends an RRC Resume message with the necessary RRC configuration to move the UE back to RRC Connected state.

The sequence is as follows. First, the UE is in RRC Inactive state. When downlink user traffic is triggered, the gNB sends Paging to the UE. After receiving the Paging message, the UE sends RRC Resume Request. When the gNB receives the RRC Resume Request and verifies the resume identity, it sends the RRC Resume message to the UE.

Functionally, the RRC Resume message is similar to the RRC Setup message used during initial connection establishment. However, in this case, the UE is not starting from RRC Idle. It is resuming a previously suspended RRC context. Therefore, the message carries the radio configuration needed to re-establish the connection and continue normal communication.

In the RRC Resume message, you can see radio protocol configuration information such as SRB/DRB related configuration, masterCellGroup configuration, MAC cell group configuration, physical cell group configuration, and uplink configuration. These parameters allow the UE to restore the radio bearers and resume communication with the gNB.

In this example, after the RRC Resume Request, the gNB sends the RRC Resume message on DCCH-NR. This confirms that the gNB accepted the resume request and provided the required RRC configuration for the UE to return to RRC Connected state.

If the UE properly receives the RRC Resume message and successfully applies all the radio configuration parameters included in the message, the UE sends RRC Resume Complete.

This message is the final confirmation from the UE side. It tells the gNB that the UE has completed the resume procedure and is ready to continue normal communication in RRC Connected state.

In the log, you can see RRC Resume Complete sent from the UE to the gNB on DCCH-NR. This comes right after the RRC Resume message from the gNB. This sequence confirms that the UE accepted the resume configuration and completed the transition from RRC Inactive back to RRC Connected.

In this example, the RRC Resume Complete message includes selectedPLMN-Identity. This indicates the PLMN selected by the UE during the resumed connection.

So, the successful resume procedure can be confirmed by the following message flow: first Paging is sent by the gNB, then the UE sends RRC Resume Request, then the gNB sends RRC Resume, and finally the UE sends RRC Resume Complete. After this point, the UE is back in RRC Connected state and normal user traffic can continue.

If there is no higher-layer data traffic for the duration configured by inactivity_timer, the network triggers another transition from RRC Connected to RRC Inactive.

In the log, this transition is again indicated by the RRC Release message from the gNB to the UE. The important point is that this RRC Release message includes suspendConfig. This means the UE is not being released to normal RRC Idle. Instead, the RRC context is suspended so that the UE can resume the connection quickly later.

In this example, the RRC Release message includes suspendConfig with fullI-RNTI, shortI-RNTI, ran-PagingCycle, ran-NotificationAreaInfo, t380, and nextHopChainingCount. These parameters are used by the UE and the network during the later resume procedure.

The ran-NotificationAreaInfo includes the PLMN identity and the RAN area cell list. This defines the area where the UE can stay in RRC Inactive state while keeping the suspended context valid.

So, this log confirms that after the resumed connection becomes inactive again, the network can move the UE back to RRC Inactive by sending another RRC Release with suspendConfig. This shows that the UE can repeatedly move between RRC Connected and RRC Inactive depending on the traffic condition.

If the UE triggers data traffic while it is in RRC Inactive state, the UE sends RRC Resume Request to start the resume procedure.

This case is different from the previous example where the callbox triggered downlink traffic and the gNB first sent Paging. In this example, the traffic is triggered from the UE side, such as web browsing. Since the UE itself has uplink data to send, it does not need to wait for Paging from the network. Instead, the UE directly starts the resume procedure.

In the log, you can see that the UE first performs the random access procedure. After PRACH and RAR, the UE sends RRC Resume Request on CCCH-NR. This indicates that the UE wants to resume the suspended RRC connection.

Inside the RRC Resume Request message, you can see resumeIdentity, resumeMAC-I, and resumeCause. The resumeIdentity is associated with the I-RNTI that was assigned earlier in the suspendConfig IE of the RRC Release message. The resumeMAC-I is used by the network to verify the suspended UE context.

In this example, resumeCause is mo-Data. This means the resume procedure was triggered by mobile-originated data. This matches the test scenario because the UE generated user traffic while it was in RRC Inactive state.

So, this log confirms that when uplink user traffic is generated from the UE side, the UE can trigger the resume procedure by sending RRC Resume Request with resumeCause set to mo-Data.s

RRC / NAS Signaling

RrcRelease (SA)

: This is the RrcRelease message sent by gNB  to switch to Rrc Inactive Status. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

{

  message c1: rrcRelease: {

    rrc-TransactionIdentifier 0,

    criticalExtensions rrcRelease: {

      suspendConfig {

        fullI-RNTI '1234504601'H,

        shortI-RNTI '504601'H,

        ran-PagingCycle rf32,

        ran-NotificationAreaInfo cellList: {

          {

            plmn-Identity {

              mcc {

                0,

                0,

                1

              },

              mnc {

                0,

                1

              }

            },

            ran-AreaCells {

              '001234501'H

            }

          }

        },

        t380 min30,

        nextHopChainingCount 0

      }

    }

  }

}

Paging (SA)

: This is the Paging message sent by gNB  to trigger UE to wake up from the inactive status. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

 

{

  message c1: paging: {

    pagingRecordList {

      {

        ue-Identity fullI-RNTI: '1234504601'H

      }

    }

  }

}

RrcResumeRequest (SA)

: This is the RrcResumeRequest message sent by UE  to trigger UE to wake up from the inactive status. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

{

  message c1: rrcResumeRequest: {

    rrcResumeRequest {

      resumeIdentity '504601'H,

      resumeMAC-I 'F474'H,

      resumeCause mt-Access,

      spare '0'B

    }

  }

}

RrcResume (SA)

: This is the RrcResume message sent by gNB  to setup RRC. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

{

  message c1: rrcResume: {

    rrc-TransactionIdentifier 0,

    criticalExtensions rrcResume: {

      radioBearerConfig {

        ..

      },

      masterCellGroup {

        cellGroupId 0,

        rlc-BearerToAddModList {

          ..

        },

        mac-CellGroupConfig {

          ..

        },

        spCellConfig {

          spCellConfigDedicated {

            uplinkConfig {

              initialUplinkBWP {

                pucch-Config setup: {

                  ..

                  },

                  resourceToReleaseList {

                    ..

                  },

                  schedulingRequestResourceToAddModList {

                    ..

                  }

                },

                srs-Config setup: {

                  ...

                }

              }

            },

            csi-MeasConfig setup: {

              ...

            },

            tag-Id 0

          }

        }

      }

    }

  }

}

RrcResumeComplete (SA)

: This is the RrcResumeComplete message sent by UE. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

{

  message c1: rrcResumeComplete: {

    rrc-TransactionIdentifier 0,

    criticalExtensions rrcResumeComplete: {

      selectedPLMN-Identity 1

    }

  }

}