Has anyone tested the maximum number of registration and deregistration operations for a single UE/gNB in UERANSIM?

[madankumar9676]

Hello, I’m interested to know if anyone has tested the maximum number of registration and deregistration operations that a single UE/gNB process can handle in UERANSIM. Specifically:

Has anyone performed stress testing limit of registration and deregistration cycles for a single UE connected to a gNB?
What is the maximum number of these operations that UERANSIM can support without issues?
Any insights or guidance on this would be helpful for performance and stress-testing purposes.

Thank you!

[dbursztynowski]

Hi, just have been sitting on related stuff although not exactly having stress tests in mind. I'm using the containerized version of Open5GS/UERANSIM from Gradiant. The first thing is to be able to effectively register/deregister ues at all. Here go my personal (!) remarks regarding the latter.

You may know it, but basically, deregistration can be done using nr-cli tool, e.g.:

nr-cli imsi-999700000000011 --exec "deregister switch-off"

(in Kubernetes, this can be done from both the the inside as well as the outside of the container)

Theoretically, there are four options available to deregister (actually, I'm not sure if they have correspondence in the standards, but anyway). According to the original hint from nr-cli tool you can:

Perform a de-registration by the UE
Usage:
deregister <normal|disable-5g|switch-off|remove-sim>

Here go my notes based on the experiments I've done to understand these options:

• normal seems to have no effect (ping -I operates normally on respective tun interface); NOT RECOMMENDED
• disable-5g removes tun interface and leaves imsi visible in nr-cli --dump; the left imsi is orphaned: it can not be deleted (subsequent "switch-off" takes no effect) and re-registration of the imsi creates new ue with duplicated imsi and new tun interface; ping -I ... works fine on the new interface; NOT RECOMMENDED
• switch-off typically successfully removes the imsi id and the tun interface; subsequent nr-ue -c ... registers the ue creating the tun interface and given msi, and all works fine; RECOMMENDED, although I've faced situations when switch-off did not remove imsi from the nr-cli --dump list and re-registration led to duplicated imsi (orphaning)
• remove-sim removes tun interface, but the imsi... is orphaned (as above); NOT RECOMMENDED

Other notes

• applying the NOT RECOMMENDED options as above multiple times and interleaving them with re-registration of the imsi using the nr-ue command may result, in addition to the above, in the inability to even switch-off (i.e., delete the tun and the imsi) previously untouched or recently re-created and perfectly operating ue/imsi
• I have not checked yet if the effects of the flaws indicated above are visible somehow on the N1 or N2 interfaces
• there's also a Youtube video addressing a DoS by registration storm from UERANSIM. Maybe it can be helpful for you: https://www.youtube.com/watch?v=sn-mKIcHEfo

Conclusion (according to my experience):

• Consequently, it is recommended to only use "deregister switch-off" to deregister ues, at least in the containerized environment. And even this should be used with care. It's safer not to touch the remaining options. Registration is to be emulated using nr-ue -c ...

If you find out something more/else or have other suggestions, please do not hesitate to share it.

[madankumar9676]

Hi,
Thanks for your suggestion on how to do registration and deregistration by using the CLI and thanks for the listing out the suggested ways.

But still i'm curious to know the how many register and deregister cycles possible to do with the single UE processes connected with the gNB followed by the CORE.

Problem statement:
Currently, i'm doing the stress testing through one script, which automatically triggers register and deregister(doing as you suggested). Issue is at some point i'm facing the memory related issue(Here goes the detailed explanation, after reaching to the certain point of register and deregister, the amount of memory utilisation by the UE is going very high and due to that system is slowing down)

Problem debugging
I ran the UE node through valgrind and find out some leaks during the register and deregister. Hope, if you know any better way to find out the leakages and better way to test it please suggest to me and thanks in advance.

[dbursztynowski]

In containerized/gradiant environment, each command nr-ue -c ... launches a new process in the ues container (with Gradiant implementation, ues container emulates user terminals; another container emulates gnb node) and that process is responsible for handling newly created ues (i.e., respective tun interfaces and handling their communication as, e.g., ping -I ueransim0 8.8.8.8). So, if you create several groups of ues running several instances of the nr-ue command in sequence, several processes will be fired and will run until they are deleted (e.g., ps kill or equivalent). A question arises as to whether deregistering all subordinate ues (using the switch-off options that seems to work from time to time ;-) ) deletes respective nr-ue process automatically (strangely enough, but I have not checked that so far, maybe I should do it!). But if those processes are not destroyed, that can explain memory leakages. Which on the other hand could undermine the validity of the stress test at all unless you explicitly delete those processes from your script (it may be difficult to identify which process is responsible for which ues, though). Under the youtube link I provided, memory utilization overload is achieved, but I'm not sure if that is exactly your case. At the moment I have not better explanations/hints regarding Ueransim. To make any progress, I need to check what actually happens to those processes. But as an alternative, you can consider a tool from HP named packetrusher https://github.com/HewlettPackard/PacketRusher. Unfortunately, it does not launch correctly in containerized version (at least in my environment) so I have not much experience here. But maybe you will be more successful. Based on HP claims, it may turn out to be perfect for you.