NAS Reject
The purpose of this tutorial is to show you how to Reject a NAS message that you specified. This tutorial shows two different ways of testing NAS reject : One with configuration file and the other one with Remote API. There are roughly two ways of performing NAS Reject in Amarisoft Callbox as listed below.
- Reject through configuration file
- Reject through Remote API
This tutorial shows both ways.
Table of Contents
- NAS Reject
- Test Setup
- Key Configuration Parameters
- Test 1 : Attach Reject with the cause # 14 (LTE)
- Test 2 : Attach Reject with the cause # 14 with Remote API (LTE) - attach_reject_filter
- Test 3 : Reject Periodic Registration with the cause # 22 and t3512with Remote API (NR SA)
- Test 4 : Attach Reject with the cause # 20 and then Attach Accept(removing reject) with Remote API (LTE) - emm_procedure_filter
- Test 5 : PDN Connectivity Reject with the cause # 27 with Remote API (LTE) - esm_procedure_filter
- Test 6 : Initial Registration Reject with the cause # 22 with Remote API (NR SA)
- Test 7 : Attach Reject/TAU Reject with the cause # 22 with Remote API (LTE) - T3412, T3402
Introduction
In the context of cellular network simulation and testing, the ability to manipulate and control Non-Access Stratum (NAS) message flows is essential for robust device validation, troubleshooting, and protocol behavior analysis. NAS forms a critical layer in the 3GPP protocol stack, operating above the Radio Resource Control (RRC) layer to manage key signaling procedures such as authentication, security, mobility, and session management between the User Equipment (UE) and the core network. With the proliferation of 4G and 5G networks, tools like Amarisoft Callbox play a significant role in emulating base stations (eNB/gNB) and core network functionalities for end-to-end testing. One commonly required test scenario involves forcing NAS message rejections to observe and validate UE behavior under failure or abnormal conditions. Amarisoft Callbox provides two primary mechanisms for implementing NAS message rejections: through static configuration files and via its flexible Remote API. Each approach offers distinct advantages depending on whether static, repeatable scenarios or dynamic, real-time control is desired. This tutorial is designed to provide detailed, step-by-step guidance on both methods, ensuring that engineers and testers can effectively simulate NAS rejections, understand their implications, and leverage Amarisoft's capabilities to achieve comprehensive protocol testing coverage.
-
Context of the Technology
- NAS (Non-Access Stratum) is a crucial signaling layer in mobile networks, responsible for procedures like registration, authentication, and session management between the UE and core network.
- Amarisoft Callbox serves as a powerful and flexible platform for simulating 4G/5G base stations and core networks, enabling controlled testing of UE protocol behavior.
- Testing NAS reject scenarios is vital for protocol compliance, UE robustness assessment, and ensuring proper error handling mechanisms are implemented in devices.
-
Relevance and Importance of the Tutorial
- Demonstrates practical methods to simulate NAS message rejection, a key test case for device certification and troubleshooting.
- Highlights both static (configuration file-based) and dynamic (Remote API-based) approaches, covering a wide range of testing requirements.
- Addresses real-world scenarios where UEs must handle NAS failures gracefully and in compliance with 3GPP standards.
-
Learning Outcomes
- Understand the architectural role of NAS in cellular networks and its interaction with Amarisoft Callbox components.
- Gain hands-on experience in configuring NAS rejection via configuration files for repeatable test cases.
- Learn to leverage Amarisoft’s Remote API for real-time, programmable control over NAS message handling.
- Acquire insights into typical UE responses to NAS rejections, including retry behaviors and compliance considerations.
-
Prerequisite Knowledge
- Familiarity with cellular network architecture, including the roles of eNB/gNB, UE, and core network elements.
- Basic understanding of the 3GPP protocol stack, especially NAS and RRC layers.
- Experience with Amarisoft Callbox environment and its configuration workflows.
- Some exposure to scripting or programming (for Remote API usage) is beneficial but not strictly required.
Summary of the Tutorial
This tutorial demonstrates various test procedures for simulating network-initiated rejection of NAS procedures (such as Attach, Registration, PDN Connectivity, and TAU) in LTE and NR SA environments using both direct configuration and Remote API commands. The procedures focus on configuring rejection filters, performing tests, and observing UE behavior under different rejection scenarios.
-
Test 1: Attach Reject with Cause #14 (LTE)
- Configure the network (eNB/MME) to reject all attach requests from any UE using specific parameters in the configuration file (e.g., mme-ims-nas-reject.cfg).
- Set attach_reject_filter and attach_reject_error for the desired cause value.
- Power on the UE and observe protocol logs to verify that the Attach is rejected with the specified cause.
- To revert to accepting requests, use RemoteAPI to remove the reject filter.
-
Test 2: Attach Reject with Cause #14 using Remote API (LTE)
- Without modifying configuration files, use the RemoteAPI to set up attach_reject_filter and attach_reject_error before powering on the UE.
- Start trace logging, execute the RemoteAPI command, then power on the UE to trigger and observe the rejection.
-
Test 3: Reject Periodic Registration with Cause #22 and t3512 using Remote API (NR SA)
- Use RemoteAPI commands to configure the periodic registration rejection and set t3512 timer.
- First, set the t3512 value to control UE retry interval.
- Then, reject periodic registration using 5gmm_procedure_filter and registration_mobility_periodic_error.
- Power on the UE and use WebGUI to verify the expected periodic registration rejection behavior.
-
Test 4: Attach Reject with Cause #20, then Attach Accept using Remote API (LTE)
- Configure rejection of Attach requests through emm_procedure_filter and attach_reject_error using RemoteAPI before UE power-on.
- To change behavior and allow Attach requests, send another RemoteAPI command to set the filter to "treat".
- Verify in protocol logs that Attach requests are rejected or accepted according to the filter settings.
-
Test 5: PDN Connectivity Reject with Cause #27 using Remote API (LTE)
- Use RemoteAPI to reject PDN Connectivity requests for a specific APN via pdn_list and esm_procedure_filter.
- To revert to acceptance, set pdn_connectivity to "treat" for the relevant APN through RemoteAPI.
- Observe logs for rejection and subsequent acceptance after filter modification.
-
Test 6: Initial Registration Reject with Cause #22 using Remote API (NR SA)
- Set up rejection of initial registration by configuring 5gmm_procedure_filter for registration_initial and specifying registration_initial_reject_error via RemoteAPI.
- Issue RemoteAPI commands before powering on UE; after observing rejection, allow registration by changing the filter to "treat".
- Confirm behavior in WebGUI and protocol logs, power cycling UE as needed.
-
Test 7: Attach Reject/TAU Reject with Cause #22 using Remote API (LTE) – T3412, T3402
-
Sub test 1: Attach Reject with #22, default T3402
- Configure network to reject Attach with cause #22 using attach_reject_filter and attach_reject_error.
- Verify UE retry behavior based on default T3402 timer after multiple rejections.
-
Sub test 2: TAU Reject with #22, user-specified T3402
- Set specific t3412 and t3402 values with RemoteAPI.
- Configure emm_procedure_filter to reject Tracking Area Update and specify the reject cause.
- Observe UE retry behavior for TAU requests based on the configured timers and compare responses between commercial UE and Amarisoft UEsim.
-
Sub test 1: Attach Reject with #22, default T3402
General Methodology:
- For all tests, a single UE and cell configuration is sufficient.
- RemoteAPI is used extensively to dynamically apply and remove rejection filters and error causes without modifying static configuration files.
- Tests are typically performed by starting trace logs, applying configuration or RemoteAPI changes, and then powering on the UE to observe NAS/EMM/ESM behavior.
- Verification is done through protocol trace logs and WebGUI, focusing on the UE's behavior in response to network rejections and timer settings.
Test Setup
This tutorial does not require any special test setup. Just to have one cell configuration with one UE connection is enough.
Key Configuration Parameters
Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.
- config_set
- registration_initial
- registration_initial_reject_error
- registration_mobility_periodic
- registration_mobility_periodic_error
- emm_procedure_filter
- attach_reject_error
- pdn_list
- esm_procedure_filter
Test 1 : Attach Reject with the cause # 14 (LTE)
In this test, I will configure in such a way that eNB reject every attach request from every UE with the cause #14
Configuration
You can use any of LTE configuration for this tutorial (e.g, enb.default.cfg).
I used mme-ims-nas-reject.cfg which is copied and modified from mme-ims.cfg
Add attach_reject_filter: {"*", 0, "imsi": 1 } and attach_reject_error : error code in mme-ims-nas-reject.cfg as shown below.
Perform the Test
Power on UE and check the protocol log to see if the Attach is rejected as intended. You see that 'Attach Reject' is sent and check out the EMM cause as intended.
Depending on the type of reject cause, UE may retry the NAS request. The number of retry would vary depending the type of the reject cause. If you configure the reject filter in the configuration file, all of the NAS request set in the configuration will be rejected regardless of how may times it is requested. If you want to remove the reject and accept the request, you need to use RemoteAPI.
Test 2 : Attach Reject with the cause # 14 with Remote API (LTE) - attach_reject_filter
Basically what this test does is same as Test 1, but in this test I will not change any configuration in mme-ims.cfg file. I will setup the reject filter using Remote API (NOTE : If you are not familiar with RemoteAPI, please check out this tutorial and make some basic practice first about Remote API and then try this).
Configuration
You can use any of LTE configuration for this tutorial (e.g, enb.default.cfg).
I used mme-ims.cfg without any modification.
Perform the Test
Start the trace log. Do not power on UE yet. Run the remote API before powering on UE in this case because what you are trying to do in this test is to reject the initial attach. The reject should be configured before UE attempts the initial attach.
Send RemoteAPI command as shown below : ./ws.js mme '{"message": "config_set","attach_reject_filter":{"*": 0,"001010123456789": 1}, "attach_reject_error": 14}'
Test 3 : Reject Periodic Registration with the cause # 22 and t3512with Remote API (NR SA)
I will setup the reject filter using Remote API (NOTE : If you are not familiar with RemoteAPI, please check out this tutorial and make some basic practice first about Remote API and then try this).
Configuration
You can use any of NR SA for this tutorial (e.g, gnb-sa.cfg).
I used mme-ims.cfg without any modification.
Perform the Test
Start the trace log. Do not power on UE yet. Run the remote API before powering on UE in this case because what you are trying to do in this test is to reject the initial attach. The reject should be configured before UE attempts the initial attach.
Run this remoteAPI command as shown below : ./ws.js mme '{"message": "config_set","t3512":30}'. This commend is to let UE retry periodically when the registration gets rejected.
Run this Remote API command as shown below : ./ws.js mme '{"message": "config_set","5gmm_procedure_filter":{"registration_mobility_periodic":"reject"},"registration_mobility_periodic_error":22}'
Now power on UE and check the behavior in WebGUI.
You would notice that T3512 is set as configured.
After some time in idle mode, UE attemps periodic registration.
The periodic registration is rejected with the cause as configured by the RemoteAPI.
Test 4 : Attach Reject with the cause # 20 and then Attach Accept(removing reject) with Remote API (LTE) - emm_procedure_filter
Basically what this test does is same as Test 2, but with different RemoteAPI command. An advantage of using this command is that you can change the filter so that eNB accept Attach request again if you like.
I will setup the reject filter using Remote API (NOTE : If you are not familiar with RemoteAPI, please check out this tutorial and make some basic practice first about Remote API and then try this).
Configuration
You can use any of LTE configuration for this tutorial (e.g, enb.default.cfg).
I used mme-ims.cfg without any modification.
Perform the Test
Start the trace log. Do not power on UE yet. Run the remote API before powering on UE in this case because what you are trying to do in this test is to reject the initial attach. The reject should be configured before UE attempts the initial attach.
Send RemoteAPI command as shown below : ./ws.js mme '{"message": "config_set","emm_procedure_filter":{"attach":"reject"},"attach_reject_error":20}'
You may let eNB accept the Attach after a few rejection. In that case, you can let it accept using following RemoteAPI command.
./ws.js mme '{"message": "config_set","emm_procedure_filter":{"attach":"treat"}}'
You can verify the operation in the log as shown below. While "attach" is set to "reject", all the Attach Request gets rejected. When "attach" is set to "treat", the Attach Request is accepted.
Test 5 : PDN Connectivity Reject with the cause # 27 with Remote API (LTE) - esm_procedure_filter
This test show you how to reject PDN Connectivity Request for a certain APN and how to remove the rejected condition and accept the message again.
I will setup the reject filter using Remote API (NOTE : If you are not familiar with RemoteAPI, please check out this tutorial and make some basic practice first about Remote API and then try this).
Configuration
You can use any of LTE configuration for this tutorial (e.g, enb.default.cfg).
I used mme-ims.cfg without any modification.
Perform the Test
Start the trace log. Do not power on UE yet. Run the remote API before powering on UE in this case because what you are trying to do in this test is to reject the initial attach. The reject should be configured before UE attempts the initial attach.
Send RemoteAPI command as shown below : ./ws.js mme '{"message": "config_set", "pdn_list":[{"apn":"ims","esm_procedure_filter":{"pdn_connectivity":"reject"}}],"pdn_connect_reject_error":27}'
You may let eNB accept the Attach after a few rejection. In that case, you can let it accept using following RemoteAPI command.
./ws.js mme '{"message": "config_set", "pdn_list":[{"apn":"ims","esm_procedure_filter":{"pdn_connectivity":"treat"}}]}'
'
You can verify the operation in the log as shown below. While "pdn_connectivity" is set to "reject", all the PDN Connectivity Request messages get rejected.
After you set "pdn_connectity" to "treat" by RemoteAPI, you see the PDN Connectivity Request gets accepted.
Test 6 : Initial Registration Reject with the cause # 22 with Remote API (NR SA)
I will setup the reject filter using Remote API (NOTE : If you are not familiar with RemoteAPI, please check out this tutorial and make some basic practice first about Remote API and then try this).
Configuration
You can use any of NR SA for this tutorial (e.g, gnb-sa.cfg).
I used mme-ims.cfg without any modification.
Perform the Test
Start the trace log. Do not power on UE yet. Run the remote API before powering on UE in this case because what you are trying to do in this test is to reject the initial attach. The reject should be configured before UE attempts the initial attach.
Before powering on UE, run this Remote API command as shown below : ./ws.js mme '{"message": "config_set","5gmm_procedure_filter":{"registration_initial":"reject"},"registration_initial_reject_error": 22}' and confirm that the initial registration get rejected. '
Now power on UE and check the behavior in WebGUI. You see the registration got rejected with the cause of 22.
Now tun the following command as below : ./ws.js mme '{"message": "config_set","5gmm_procedure_filter":{"registration_initial":"treat"}}'. This let mme to allow registration.
Confirm that registration gets accepted. (
Test 7 : Attach Reject/TAU Reject with the cause # 22 with Remote API (LTE) - T3412, T3402
The purpose of this test is to show how to configure Attach Reject and TAU Reject and see how follow up sequence goes on depending on T3402.
Configuration
You can use any of LTE configuration for this tutorial (e.g, enb.default.cfg).
I used mme-ims.cfg without any modification.
Sub test 1 : Attach Reject with #22 - default T3402
The purpose of this sub test is to verify if UE retries Attach Request based on T3402 in response to Attach Reject with #22. Overall verification sequence is
i) Network does not configure T3402 meaning that UE should use the default value of 12 min
ii) UE send attach request
iii) Network send attach reject with #22
iv) repeat ii)~iii) 4 more times
v) UE wait for t3402 expiration without retrying
vi) UE send attach request again
Perform the Test
Start the trace log. Do not power on UE yet. Run the remote API before powering on UE in this case because what you are trying to do in this test is to reject the initial attach. The reject should be configured before UE attempts the initial attach.
Send RemoteAPI command as shown below : ./ws.js mme '{"message": "config_set","attach_reject_filter":{"*": 0,"001010123456789": 1}, "attach_reject_error": 22}''
And then Power on UE and check out the log to see if UE works as expected
UE send Attach Request.
Network send Attach Reject with the cause of #20(0x16) and UE start retry Attach Request
After 5 times of retry of Attach Request and Reject, UE wait for t3412 expiration and then retry on t3412 expiration. In this case, Network didn't send any message(e.g, Attach Accept) with t3412 value. so UE applies the default t3412 value(12 min).
Sub test 2 : TAU Reject with #22 - user specified T3402
The purpose of this sub test is to verify if UE retries Tracking Area Update Request based on T3402 in response to Tracking Area Update Reject with #22. Overall verification sequence is
i) UE send Attach Request
ii) Network send attach accept with user specified T3412 and T3402
iii) UE send Tracking Area Update Request on T3412 expiration
iv) Network send Tracking Area Update Reject with #22
v) check UE behavior and see if it works as expected
- Amarisoft UEsim : Worked as expected (To make this work as expected, I needed to shorten inactivity_timer of enb.cfg. I tried with 10 sec, 5 sec and 3 sec of inactivity_timer and 3 sec inactivity_timer worked the best)
- Commercial UE : Keep retrying Tracking Area Update Request with the interval of 10 sec and never wait for T3402 value
Perform the Test
Start the trace log. Do not power on UE yet. Run the remote API before powering on UE in this case because what you are trying to do in this test is to reject the initial attach. The reject should be configured before UE attempts the initial attach.
Send RemoteAPI command as shown below : ./ws.js mme '{"message": "config_set","t3412":120}'
Send RemoteAPI command as shown below : ./ws.js mme '{"message": "config_set","t3402":60}'
Send RemoteAPI command as shown below : ./ws.js mme '{"message": "config_set","emm_procedure_filter":{"tracking_area_updating":"reject"},"tracking_area_update_reject_error": 22}'
And then Power on UE and check out the log to see if UE works as expected
UE send Attach Request.
Network send Attach Accept with both t3412 (2min) and t3402(one min).
After attach complete, UE wait for t3412 expiration (2 min in this case) and start sending Tracking Area Update Request.
Network send Tracking Area Update Reject with #22 (0x16).
Following is the Amarisoft UEsim log from the same test. The good thing about UEsim log for UEtimer test is that it shows Timer status in the log. If you are using commercial UE for this test, you need to get measure to check out the UE log showing Timer status, otherwise troubleshoot (finding the root cause of the problem) is impossible.
