Scalability in Open5Gs Charts

[kirankumar-Athirala]

Hi Borjis

I am planning to deploy the Open5G core using helm chart in my standalone Kubernetes environment. I seek clarification on the chart's capability to auto-configure manually scaled AMF and SMF functionalities.

Specifically, if I manually scale the AMF functionality, will the newly launched AMF container be able to connect seamlessly to the Open5G core and operate with the existing configuration without any manual intervention? Additionally, will both the original and new AMF instances function correctly with the shared configuration?

I see loadbalancer is configured , is loadbalancer can take care of the replicas ? could you please explain how load balancer here useful for scalability ?

If this is possible, could you please explain the process to achieve this so that I can implement it accordingly? If it is not feasible, I would appreciate any guidance or modifications required to achieve this functionality.

Thank you for your assistance.

Best regards, kirankumar athirala

[Borjis131]

Hi @kirankumar-Athirala, Open5GS is not an stateless implementation of the 5G core so I didn't pay attention to the scalability part of Kubernetes.

If, lets say, you deploy a new AMF, this newly created AMF won't have the contexts created on the previously existing one.

There is lots of work to be done testing what would happen if you manually scale the AMF but from the start I see that you will need to change some parts of the amf.yaml config file like the amf_id in the guami section. This kind of customizations were ignored deliberately in the helm charts provided for the sake of simplicity.

It could be an interesting test to perform this AMF scalability and see if it can be performed but currently I am unable to put some time on it.

If you are willing to perform those tests, keep me informed!

[kirankumar-Athirala]

I tried deploying it in kuberenetes using your helm chat and default values to test this out, But all the pods except webui and db are in CrashLoopBackOff.

when i see the logs its failing to create log fails

it seems all those are failling because of this.

[Borjis131]

Ups, the logs should be pointing to /var/log/open5gs/<nf>.log instead of that path. Let me push a commit to change the path and it should work properly.

Thanks for pointing that out!

[Borjis131]

Should be fixed with this commit. Please remove the helm charts and download them again.

[kirankumar-Athirala]

The commit fixed CrashLoopBackOff for all the NF's except nssf.

[Borjis131]

Thank you again, it was a small error while creating the config file for the NSSF. It is fixed in this commit. Pull the helm charts again and it should work, I have tested it on my kubernetes setup.

[kirankumar-Athirala]

Hi Good Afternoon,

Thanks for your quick response, I was able to deploy it without any issues. I dont see any charts for deploying gnb and ues so I used gradiant/5g charts to deploy gnb and ue with updated values which you are using .

I am able deploy it and its connected to AMF but , the UEs are losing the connection

The amf also lost the connection amf-log.txt

when i checked web ui log , webui is not able to connect with DB.

it seems the service endpoints exposed by db as folows open5gs-db-service NodePort 10.111.153.16 27017:30007/TCP 66m app=db

so the web ui needs to connect to 30007 instead of default port 27017 ? correct me if i am wrong

sorry for bothering you . your help is much appreciated.

Thanks

[Borjis131]

Hi @kirankumar-Athirala, I will try to answer to all your questions: 1) No, I did not publish helm charts for the gNB or UE so you will have to rely on other projects for that. 2) From the logs that you posted I can see the UEs losing the connection and the same in the AMF logs but I am not sure why is happening. 3) In my deployment there is no issue regarding WebUI and the DB. Even though the service created for the WebUI is type NodePort you can see that Kubernetes assigns a ClusterIP to it in the CLUSTER-IP section of the services. So that service should be reachable from the NodePort from outside your Kubernetes node and from the ClusterIP for the other services, there is no need to change any address or port.

The WebUI helm chart gets configured like this: It uses the mongodb://{{ .Release.Name }}-db-service/open5gs address to reach your deployed database.

[kirankumar-Athirala]

Hi Good Evening,

1. I am able to run the WebUI pod without crashing by manually editing the deployment config file. Specifically, I updated the environment variable:

env:

• name: DB_URI value: mongodb://open5gs-db-service/open4gs to env:
• name: DB_URI value: mongodb://nodeportIP:27017/open4gs

2. I updated the values.yaml file and deployed Open5GS core using the following configuration:

   mobileNetwork: name: Open5GS plmn: mcc: "999" mnc: "70" tac: 1 s_nssai:

   • sst: 1 sd: "0x111111" With this configuration, the gNB and UEs are registering, but the UDR pod is crashing. Here is an image showing the crash:

3. Despite this issue, I am able to manually scale the AMF, and both AMF instances are working and registering gNBs.

4. If the UDR works without crashing, I plan to scale the UPF, PCF, and SMF and observe the network flow. I noticed that only the AMF and UPF are currently configured to use a load balancer. Do we also need to configure a load balancer for the PCF and SMF to properly check and manage scaling?

Can you please assist with resolving the UDR crashing issue?

Thanks and Regards kirankumar

[Borjis131]

Hi @kirankumar-Athirala, are you using the docker-open5gs without modifications apart from the values.yaml that you showed me?

Let me answer one by one:

1. The open4gs in the DB_URI: mongodb://nodeportIP:27017/open4gs is a typo or did you change something in the DB in order to set it to it?

2. I am not sure how YAML parses the scalar string but having something surrounded by quotes and then adding the 0x at the beggining like if it is an numeric scalar seems quite odd. I suggest you to use this notation:

   sdString: "000001"
   sdNumber: 000001

   But do not mix both. Again, I am not a 100% this is causing an issue but it is something to keep in mind.

3. The issue with the UDR seems to be related to the preemption capabilities of the UE. I don't know how you registered the UEs but maybe it has something to do with that? Maybe the database is outdated in some way? I would need more info to check this, I never found this error.

4. The LoadBalancers in the AMF and the UPF are being used to expose the NGAP and GTPU protocols, this is because how kubernetes is designed. AMF uses NGAP (SCTP 38412) and UPF uses GTPU (UDP 2152), so this is the only way to expose specific ports in a kubernetes node. If not, you will have to rely on NodePorts which only expose ports above the port 30000 and the Network Functions are expecting the NGAP and GTPU protocols to run on those ports.

Hope it helps!

[Borjis131]

Hi @kirankumar-Athirala are you still working on this? Any news?

If not, I will close this issue and you can open a new one when needed.