Platform

The radio site and the campus core.

A CableFree SC-418 provides the relocatable 5G access network. Amarisoft runs on the small cell; Open5GS and campus services remain on the university network.

Physical platform

Inspect the setup. Explore the wagon.

Switch between the real setup, its antenna adapter and connector panel, then explore the proposed mobile platform.

Hardware · Connections · WagonInteractive 3D

Loading the hardware model…

Drag horizontally to rotate

Today: a speaker tripod carries the antenna through a metal adapter. The SC-418 sits nearby. This view reconstructs the photographed setup; the bracket and tripod dimensions are approximate.

Model basis: photos of the current setup and the antenna mechanical drawing (600 × Ø89 mm). The small-cell enclosure uses the 325 × 210 × 156 mm reference from the CableFree product-family datasheet. Exact SC-418 enclosure, bracket and wagon geometry still require verification.

Inside the lab

The real setup

The CableFree SC-418 sits on the lab bench beside the omnidirectional antenna on a height-adjustable tripod. Two antenna cables connect the radio hardware to the antenna.

The photograph shows the current setup at Hochschule RheinMain. A shared wagon with an adjustable mast is the next development step.

Small cell and antenna in the current lab setup.

Small cell and antenna in the current lab setup.

CableFree SC-418 on a lab bench beside a cylindrical omnidirectional antenna with a metal bracket on a black tripod by the window.
Equipment

What runs where?

The small cell and its antenna form the transportable radio site. The core, monitoring services, and application endpoints stay on campus. Moving the radio site requires a backhaul path to that stationary side.

Radio hardware

CableFree SC-418

Emerald Outdoor small cell with an integrated 5G NR gNB and radio unit.

Radio antenna

CF-6MXE-360F-02

Two-port, 360° omni antenna specified by CableFree for 3300–3800 MHz.

Software on SC-418

Amarisoft gNB

The SC-418 runs Amarisoft gNB software under its LTE service.

Software on VM

Open5GS

AMF, SMF, UPF and supporting network functions run on the stationary campus VM.

Architecture

Separate network paths, one system.

N2 carries control signalling to the AMF. N3 carries encapsulated user traffic to the UPF. After decapsulation, the N6 side connects the UE data path to campus services. Management and monitoring are separate.

Scroll sideways to explore the diagram, or open the full-size version.

Platform overview: smartphones, modems and IoT routers connect over 5G to the SC-418. N2 connects to the AMF, N3 to the UPF, N4 links SMF and UPF, and N6 reaches campus services.
Simplified platform overview based on the thesis architecture and implemented network paths. End devices vary by use case. Dashed red lines show signalling and control; solid purple lines show user traffic. Open full-size diagram ↗

N2

The gNB exchanges control signalling with the AMF.

N3

The gNB sends encapsulated user traffic to the UPF.

N6

The UPF forwards decapsulated packets toward campus services.

Connection modes

Two backhaul options.

Both modes keep the radio site relocatable and the Open5GS core stationary. The local cabling and transport path change; the 5G roles stay the same.

01

Direct campus Ethernet

Two prepared campus LAN outlets connect SC-418 management and its tagged N2/N3 path.

02

Campus WLAN via OpenWrt

The SC-418 connects locally to an OpenWrt router. The router reaches the campus VM over campus WLAN and WireGuard.

Scroll sideways to explore the diagram, or open the full-size version.

Backhaul comparison: direct campus Ethernet carries N2 to the AMF and N3 to the UPF. In WLAN mode, OpenWrt answers the small cell’s local ARP requests using proxy ARP and routes N2/N3 over WireGuard and campus WLAN to the core VM. Return routes lead back to the small cell; ARP stays local. Management is separate.
Two logical backhaul options based on the thesis: direct campus Ethernet, or OpenWrt with a shared N2/N3 WireGuard tunnel over campus Wi-Fi. Open full-size diagram ↗
Compare the modes in the wiki ↗
Observability

Observability: connect the evidence across the network.

The observability environment combines core and VM metrics, subscriber and session states, service logs and traffic metadata. Grafana helps correlate events across the network and investigate faults.

Scroll sideways to explore the diagram, or open the full-size version.

Observability flow: AMF and SMF InfoAPIs feed the custom exporter; Open5GS and host metrics feed Prometheus; Zeek and service logs flow through Alloy into Loki; Grafana presents both sources.
Website adaptation of the thesis observability diagram. The highlighted InfoAPI exporter was developed in the project. Arrows indicate data flow; Prometheus scrapes metrics and Grafana queries Prometheus and Loki. Open full-size diagram ↗

Designed and integrated in the project

The thesis covers measurement-point selection, scrape and data-source configuration, versioned Grafana dashboards and a custom InfoAPI exporter. The exporter combines AMF and SMF states and exposes subscribers, gNB connectivity and PDU sessions as Prometheus metrics.

The live page shows selected aggregate values. Internal Grafana dashboards provide the detailed diagnostic view.

01

Metrics and dashboards

Prometheus collects native core metrics, host metrics and the project InfoAPI exporter. Grafana supports detailed internal inspection.

02

Logs and events

Alloy and Loki collect service logs so registration, session setup and operational changes can be traced.

03

The user-data path

Passive Zeek observation at ogstun complements endpoint tests. Detailed records stay in the researcher tools; the website shows allowlisted aggregates.

Running a session?

The researcher wiki covers the permitted location, cabling, radio service, commissioned SIM, UE setup and checks at the core.

Open quick start ↗