At a glance
What matters first
- What it is
- Public engineering release of my bachelor thesis O-RAN xApp lifecycle lab.
- My role
- Built the lab workflow, automation path, switching method, observability setup, and repository release.
- Core stack
- Ansible, K3s, O-RAN SC Near-RT RIC, kpimon-go, e2sim, Istio, Prometheus, Grafana, Kiali.
- Best evidence
- Repository with architecture notes, switching notes, observability notes, citation metadata, and validation checks.
What I Built
I turned the reusable path from my bachelor thesis into a public lab repository for O-RAN xApp lifecycle work. The lab prepares a single-VM K3s environment, deploys O-RAN SC Near-RT RIC, onboards kpimon-go, drives e2sim E2SM-KPM input, and inspects service behavior during switching experiments.
Workflow
The workflow starts with Ansible and ends with a checkable lab path. Host preparation, RIC deployment, xApp onboarding, e2sim input, switching, and monitoring are documented as one lifecycle rather than separate setup notes.
The interactive workflow below shows the path at a system level. Each state keeps the focus on one flow instead of compressing every service into one topology.
Lifecycle workflow
O-RAN lab path
What The Repository Shows
The repository gives reviewers a concrete entry point: README orientation, architecture notes, time-window switching notes, observability notes, citation metadata, and make check validation.
Public release inventory
- Architecture notesRIC lab structure and boundaries
- Switching notesTime-window method and validation limits
- Observability notesPrometheus, Grafana, Kiali, and mesh visibility
- Citation metadataPublic reference record
Time-Based Switching compares two kpimon-go variants over full traffic windows. In thesis-era validation, that workflow preserved throughput continuity while convergence latency remained the main bottleneck.
Time-window switching
- Context
- RMR and persistent service connections made percentage splitting the wrong public explanation for the lab.
- Decision
- Alternate complete traffic windows between variants and document what Istio can and cannot observe.
- Result
- The repository keeps the method inspectable while naming convergence latency and image pinning as repeatability limits.
Engineering Constraints
The lab is a single-VM research testbed. Istio supports sidecar-observed TCP/RMR service behavior around the xApp services, while SCTP/E2 traffic remains outside native Istio sidecar telemetry. The mutable splicer3/e2sim:latest image should be pinned for repeatable comparisons.