I’m building CorePulse, an MIT-licensed Go project for controlled fault experiments in a local Open5GS + UERANSIM Kubernetes lab. I’ve opened six scoped issues for people who want to help with Go, documentation, or telecom observability.
The result that changed the recovery checks
In a recent isolated UPF pod replacement experiment, Kubernetes made the replacement ready, but six subsequent UE-to-UPF gateway checks still lost both packets. Resource telemetry and the experiment interval were recorded. A green deployment badge was only one part of the recovery result.
The reset procedure now stops UE, gNB, SMF and UPF, waits for the old pods to disappear, then starts UPF, SMF, gNB and UE in order. In the pinned lab, routing PFCP through a separate headless service let SMF resolve the current UPF pod directly. After the reset, UE registration and PDU session establishment returned, two consecutive gateway checks passed, and the unchanged lab verifier passed all 16 deployments and 5/5 external ping replies.
This is a local result for the tested chart and image versions. It does not establish a general root cause for Kubernetes PFCP failures. The integration notes include the failed attempts and limits.
What works today
The Go CLI and local dashboard support guarded AMF/UPF pod deletion, real Kubernetes CPU/memory collection, explicit normal-run collection, run records and repeated packet-path checks. Curated CSV exports include only qualifying run intervals; unscoped or unverified samples are excluded.
There is no trained detector yet. The current curated dataset has 12 normal and 12 fault rows across five qualifying runs, which is much too small for a meaningful model evaluation. Registration, session and PFCP log events still need a structured feature pipeline.
Where you can help
Two tasks are labeled good first issue and need no Kubernetes cluster:
- Reject negative and non-finite resource quantities (#1): a focused Go validation change with fixture tests.
- Write a complete offline contributor quickstart (#2): help someone build, test and preview the dashboard before setting up a lab.
Four help wanted tasks go deeper:
- Persist fault checkpoints before recovery finishes (#3).
- Make baseline collection cancellable (#4).
- Distinguish missing metrics from measured zeros in CSV (#5).
- Parse timestamped registration, session and PFCP events (#6).
Each issue includes starting files, acceptance criteria and validation expectations. Comment on the one you want to tackle with a short approach so we can coordinate. The contribution guide covers checks and lab boundaries.
Development and this write-up have been assisted by AI tools. The lab observations above come from actual runs; the project’s limitations remain documented.
If you work with Open5GS or UERANSIM, I’d also welcome a review of the recovery procedure and which protocol events would be most useful to collect next.
Top comments (0)