Split the Duranta O-DU at the O-RAN 7.2 fronthaul and drive a real, commercial O-RU instead of a USRP: the same nr-softmodem binary and OAI CN5G core, three different vendor radios, and a working end-to-end path (registration → PDU session → ping → iperf3) on two of the three.
This is the production shape of Duranta on COSMOS: the O-DU (nr-softmodem + the fhi_72/xran fronthaul transport on a DPDK-bound Intel E810 VF) carries frequency-domain IQ as eCPRI over a VLAN-4 Ethernet link to a standalone O-RU, instead of driving a USRP directly. Three commercial O-RUs are available on COSMOS, and each behaves differently enough that "the O-RU" is not one recipe:
ru_ofh.ta4_max: 1960, expert_phy.max_proc_delay: 10) — the earlier "cannot be driven by OCUDU, upstream defect" conclusion was wrong. See OCUDU (srsRAN) 5G SA — O-RAN 7.2 split: Benetel, LiteOn & Foxconn O-RUs.RRHconfig_xran.xml + activation script, no M-Plane). Cell detection and downlink are solved, but registration is blocked: the UE never accepts a RACH response. Documented here as a known-open item, not a working path. (Under OCUDU it is partly unblocked as of 2026-09-14 — the RU latches and exchanges data — but no UE attaches there either; see the OCUDU Foxconn tutorial.)If you only want a real air interface with the least moving parts, the Duranta OTA tutorial (gNB drives a USRP directly, no O-RU split) gets there faster. This tutorial is for the O-RAN 7.2 split itself — eCPRI, PTP S-plane, per-vendor U-plane quirks — with a commercial radio in the loop.
After completing this tutorial you will be able to:
rx pps, RX_LATE, associated AMF) to tell "radiating" from "configured".| Difficulty | Advanced |
| Estimated time | 90–150 min (Benetel or LiteOn); Foxconn is not currently completable |
| Domain / sandbox | osc (fronthaul-capable E810 server) + the O-RU's own console domain |
| Topic group | Cellular (4G/5G/O-RAN) |
| Last verified | 2026-09-11 — Benetel (V2.1.0 firmware) end-to-end with both a COTS Quectel modem and the Amarisoft lteue soft UE (2× Xeon Gold 6126 platform, image duranta-20260907c). LiteOn last verified 2026-09-07 with the modem only. Foxconn: DL/cell-detection solved 2026-09-05, registration still blocked — not re-tested since; treat that section as status, not a walkthrough. |
Background knowledge
ssh/ip/iperf3 on Linux.Account & access
osc E810 fronthaul server, the Quectel UE node, and the O-RU you intend to drive (they are shared instruments, not reservable per-node in the usual sense) — see Make a reservation.console.osc.cosmos-lab.org and to console.instrument.cosmos-lab.org (power control for all three O-RUs, *.instrument.orbit-lab.org) — see SSH access.Devices / nodes
| Resource | Role | Qty | Notes |
|---|---|---|---|
E810 fronthaul server (e.g. srv19.osc) |
O-DU (nr-softmodem + fhi_72) + OAI CN5G |
1 | fronthaul NIC on VLAN 4; needs cosmos-ofh-isolation applied per host |
| One vendor O-RU | commercial radio | 1 | Benetel RAN650, LiteOn FlexFi, or Foxconn RPQN-7801 — see the per-vendor table below |
| Quectel RM520N-GL | commercial 5G UE | 1 | sdr1-in3.sb1 (Benetel) or node1.osc (LiteOn); AT on /dev/ttyUSB2, QMI on /dev/cdc-wdm0 |
Per-vendor specifics
| O-RU | Management | Config on image | Bring-up script | UE / IMSI | Status |
|---|---|---|---|---|---|
| Benetel RAN650 (firmware V2.1.0+) | M-Plane (NETCONF, DU-managed session) | /root/oru/gnb-benetel.conf |
/root/benetel-bringup.sh |
001010000000032 on sdr1-in3.sb1 |
✅ working |
| LiteOn FlexFi | static config, no M-Plane | /root/oru/gnb-liteon.conf |
/root/liteon-du-bringup.sh |
001010000000033 on node1.osc |
✅ working |
| Foxconn RPQN-7801 | file mode (RRHconfig_xran.xml + activation script) |
/root/oru/gnb-foxconn-static.conf |
/root/foxconn-du-bringup.sh |
001010000000033 on node1.osc |
⚠️ DL/cell OK, registration blocked |
Disk images
| Image | Load onto | Provides |
|---|---|---|
duranta.ndz (= duranta-20260917, Duranta 2026.w37, at last verification) |
DU node | nr-softmodem with fhi_72/xran, OAI CN5G, /root/oru/ configs and per-vendor bring-up scripts, cosmos-ofh-isolation |
lte5gue.ndz |
UE node | qmicli (libqmi), modem AT helper scripts |
Software components
| Component | Version | Source |
|---|---|---|
| Duranta O-DU (OAI fork) | tag 2026.w37 + COSMOS patches |
/opt/duranta/cmake_targets/ran_build/build/nr-softmodem — no license needed |
| OAI CN5G | docker-compose | oai-{amf,smf,upf,nrf,...} via /opt/oai-cn5g/oai-cn5g-fed/docker-compose/docker-compose-basic-nrf.yaml |
linuxptp (ptp4l/phc2sys) |
distro | G.8275.1 S-plane on the DU host and the RU |
Spectrum / RF / special
dl_absoluteFrequencyPointA and initialDLBWPcontrolResourceSetZero are per-cell — do not copy one vendor's value to another.oai, UE pool 192.168.100.0/22 (gateway 192.168.100.1), internet-NAT'd.osc fronthaul fabric is shared across sandboxes; a "no signal" symptom is never an RF/antenna problem here — see the per-vendor Troubleshooting entries. O-DU + core (e.g. srv19.osc) Vendor O-RU Quectel UE
┌─────────────────────────┐ eCPRI ┌────────────────┐ n78 OTA ┌──────────────┐
│ nr-softmodem (fhi_72) │ VLAN 4 │ Benetel/LiteOn/ │ 3.75 GHz │ RM520N-GL │
│ OAI CN5G (docker) │═══════════════►│ Foxconn │────────────►│ wwan0 QMI │
│ oai-ext-dn (data anchor)│ + PTP S-plane │ │ 100 MHz │ 192.168.100.x│
└─────────────────────────┘ G.8275.1 └─────────────────┘ └──────────────┘
fronthaul NIC (VLAN 4) PTP GM = fabric switch (G.8275.1, domain 24)
Management differs per vendor (see the table above): Benetel takes its configuration from the DU over M-Plane at bring-up; LiteOn and Foxconn are configured out-of-band and the DU simply streams C/U-plane to whatever they are already set to.
ssh <username>@console.osc.cosmos-lab.org
omf load -i duranta.ndz -t <du-node> -r 0 -o 1200
omf tell -a on -t <du-node>
ssh root@<du-node> 'cosmos-ofh-isolation --apply' # derives isolcpus from the fronthaul NIC's NUMA node
sshd on an un-isolated host within seconds of starting.srv19.osc):ssh root@<du-node> 'cat /sys/devices/system/cpu/isolated'
This step is not optional and cannot be skipped between runs. It must be a power cycle: after a warm in-RU reboot the Benetel radiates and the cell comes up, but the DU sees about a third of the uplink early and a third late, and every UE drops out of sync (ulsch_DTX 100, BLER 0.92). This was measured twice on 2026-09-14, on two different servers. A warm-restarted RU that never actually powered down comes up on the wrong numerology (RU0 mu0, 15 kHz, against the DU's 30 kHz PHY) and silently never radiates — every DU-side counter still looks plausible.
# Benetel, from console.instrument.cosmos-lab.org:
omf tell -a off -t benetel-oru.instrument.orbit-lab.org; sleep 25
omf tell -a on -t benetel-oru.instrument.orbit-lab.org
Poll the M-Plane port (:830) until it reopens. ~300 s to reopen = a genuine cold cycle; ~80 s means it never powered off — repeat the off/on before continuing. (omf tell verbs here are on|off|offh|offs|reset|reboot — there is no status.) LiteOn and Foxconn use the equivalent omf tell -a offh,on -t liteon-oru.instrument.orbit-lab.org / omf tell -a reset -t foxconn-oru1.instrument.orbit-lab.org, also from console.instrument.cosmos-lab.org.
If OCUDU used the Benetel last, its RU-side settings (
compression,mimo_mode,tdd_patternin/etc/ru_config.cfg) are still OCUDU's. Before this step, re-assert Duranta's withpython3 configs/oru-profiles/oru-apply.py configs/oru-profiles/benetel-ran650.yml --stack duranta --apply(in theduranta-cosmosrepo), then do a genuine in-RUreboot— anomf tell off/onalone does not clear them (see Troubleshooting).
After several warm DU restarts the E810 VFs wedge and the bring-up script aborts at its VF-MAC gate (dmesg: iavf ... Reset never finished, VF disabled). Recover with a real power cycle, not a soft reboot:
ssh root@am-rt1 'curl -s "http://localhost:5054/cmc/power_cycle?set=<du-node>.osc.cosmos-lab.org&domain=osc"'
If you just rebuilt anything on the DU, run sync first — a hard cycle immediately after linking has left libxran.so and its object files at 0 bytes.
ssh root@<du-node>
docker compose -f /opt/oai-cn5g/oai-cn5g-fed/docker-compose/docker-compose-basic-nrf.yaml up -d
docker ps --format '{{.Names}}\t{{.Status}}' | grep oai
Eight NFs plus mysql should show Up.
Any 7.2 server (2026-09-14). The bring-up scripts no longer carry srv19's values. They derive the VF, the NUMA node, the xran and PHY cores, the softmodem CPU set and the PTP CPUs from the host itself, with
oai72-host.py. They then write a per-host config (/root/oru/gnb-<ru>.<host>.conf). This path has been validated on 2× Xeon Gold 6126, 2× Xeon Gold 6226 and AMD EPYC 9355P. Until the next image rebake, copyconfigs/oai72-host/oai72-host.pyand the two bring-up scripts from theduranta-cosmosrepo to/root/. The host needs its per-host CPU isolation: runcosmos-ofh-isolation --nic DATA1a --applyand reboot once after each image load. If OCUDU used the Benetel last,benetel-bringup.shwrites Duranta'sru_config.cfgand then stops, asking for a cold power cycle. Theduranta-72bundle stages the RU and cold-cycles it before the bring-up, so it needs no manual step.
Benetel (M-Plane; the transport library must be set to the M-Plane variant before launch):
ln -sfn liboran_fhlib_5g_mplane.so /opt/duranta/cmake_targets/ran_build/build/liboai_transpro.so
/root/benetel-bringup.sh
LiteOn (static config; no M-Plane symlink step):
/root/liteon-du-bringup.sh
Foxconn (file mode; the RU must already be latched — see Troubleshooting, this path does not currently complete):
/root/foxconn-du-bringup.sh
Healthy signs, in this order, for any of the three:
vf0 MAC 00:11:22:33:44:66
RU0 mu1
rx ... pps 79872
[PM] RX_LATE 0
associated AMF 1
cell ... is in service
associated AMF 1 = NG Setup succeeded. cell ... is in service = the cell is on air. If RX_LATE is non-zero and climbing, the RU never actually cold-cycled (back to Step 1).
ssh root@<ue-node> # sdr1-in3.sb1 (Benetel) or node1.osc (LiteOn/Foxconn)
python3 /root/ue_nr2.py # or the AT sequence below, on /dev/ttyUSB2
The sequence, if driving AT commands directly, and the order matters:
AT+COPS=2 # deregister
AT+CFUN=0
AT+CRSM=214,28539,0,0,12,"FFFFFFFFFFFFFFFFFFFFFFFF" # clear forbidden-PLMN list
AT+CGDCONT=1,"IP","oai"
AT+CFUN=1
AT+COPS=0 # automatic — FIRST
AT+QNWPREFCFG="mode_pref",NR5G # re-assert AFTER COPS=0, which reverts it
AT+COPS=1,2,"00101",12
AT+QENG="servingcell"
AT+COPS=0 silently reverts mode_pref, and there is a competing commercial 001/01 LTE cell at EARFCN 3350 in this RF space — reasserting mode_pref=NR5G after COPS=0, not before, is what keeps the modem on NR5G-SA. If the modem still won't RACH after repeated attempts, run /root/ue_nvreset.py first (AT+QPRTPARA=3) to clear a stale NAS context.
echo Y > /sys/class/net/wwan0/qmi/raw_ip; ip link set wwan0 up
qmicli -d /dev/cdc-wdm0 --wds-start-network="apn=oai,ip-type=4" --client-no-release-cid
qmicli -d /dev/cdc-wdm0 --wds-get-current-settings # read the IPv4
ip addr add <ip>/30 dev wwan0; ip link set wwan0 up
ip route replace 192.168.100.0/22 dev wwan0 # scoped only — never a default route
ping -I wwan0 -c 5 192.168.100.1 # UPF gateway
ping -I wwan0 -c 5 8.8.8.8 # internet, via UPF NAT
Use only a scoped route (
192.168.100.0/22 dev wwan0) — adefault via wwan0black-holes the UE node's own management SSH.
Throughput — iperf3 against the core-side data anchor (oai-ext-dn, 192.168.70.130):
ssh root@<du-node> 'iperf3 -s -B 192.168.70.130 &'
iperf3 -c 192.168.70.130 -B 192.168.100.2 -t 8 -R # downlink
iperf3 -c 192.168.70.130 -B 192.168.100.2 -t 8 # uplink
associated AMF 1 and cell ... is in service.+C5GREG: 0,1 on 001/01; PDU session gives an IP in 192.168.100.0/22.ping 192.168.100.1 and ping 8.8.8.8 = 0 % loss.RX_LATE at or near 0.The same DU config on a different CPU class gives different numbers (isolation width scales with core count). Every figure below is on the same platform, so it isolates the RU/config differences honestly. Two UE configurations are reported: a COTS Quectel modem (real RF frontend, single UE) and the Amarisoft lteue soft UE (cross-vendor, driven over a networked USRP — supports a UE-count sweep, see below).
| O-RU | CPU platform | UE | DL (TCP) | UL (TCP) | ping local | ping remote | measured |
|---|---|---|---|---|---|---|---|
| Benetel RAN650 (V2.1.0, TDD pattern fixed) | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | Quectel modem | 268 Mbit/s | 64.6 Mbit/s | 31.5 ms, 0 % loss | 32.1 ms, 0 % loss (123/57.5 Mbit/s remote) | 2026-09-07 |
| Benetel RAN650 (V2.1.0, TDD pattern fixed) | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | Amarisoft lteue (1 UE) |
143 Mbit/s | 57.1 Mbit/s | 31 ms, 0 % loss | — | 2026-09-11 |
| LiteOn FlexFi | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | Quectel modem | 165 Mbit/s | 28.8 Mbit/s | 31 ms, 0 % loss | 32 ms, 0 % loss (163/28.3 Mbit/s remote) | 2026-09-07 |
| Benetel RAN650 | 1× AMD EPYC 9355P, 32 cores / 32 threads | Quectel modem | 222–261 Mbit/s | 51.4–54.9 Mbit/s | 31 ms, 0 % loss | 32 ms, 0 % loss | 2026-09-14 |
| LiteOn FlexFi | 2× Intel Xeon Gold 6226, 24 cores / 24 threads | Quectel modem | 185–202 Mbit/s | 43.7–46.9 Mbit/s | 32 ms, 0 % loss | 32 ms, 0 % loss | 2026-09-14 |
| LiteOn FlexFi | 1× AMD EPYC 9355P, 32 cores / 32 threads | Quectel modem | 172–200 Mbit/s | 44.1–48.3 Mbit/s | 32 ms, 0 % loss | 32 ms, 0 % loss | 2026-09-14 |
| Benetel RAN650 | 2× Intel Xeon Gold 6226, 24 cores / 24 threads | Quectel modem | 270–287 Mbit/s | 50.0–50.2 Mbit/s | 0 % loss | — (host egress not set up) | 2026-09-14 |
| Foxconn RPQN-7801 | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | Quectel modem | not measured — registration never completes | not measured | — | — | 2026-09-05 (status only) |
Earlier Benetel baseline (before the V2.1.0 TDD-pattern fix, 2026-08-26, same platform): DL 239 / UL 12.5 Mbit/s. The 09-07 result is after the RU's own TDD pattern was corrected to match the DU (see Troubleshooting).
lteue UE-count sweep — Benetel RAN650, 2× Intel Xeon Gold 6126, 24 cores / 48 threadsTwo NULL-security bugs (NAS supported_integrity/encryption_algorithms order in the AMF config, and the gNB's own ciphering_algorithms list) plus a cross-vendor PDU-session-type mismatch (lteue defaults to ipv4v6, this SMF only serves IPv4) blocked lteue entirely until fixed — see Troubleshooting. Once fixed, single-UE registration takes ~5 s with 0 % packet loss end to end.
A UE-count × offered-load sweep (5 Mbit/s UDP per UE, cosmos-orchestration's amarisoft_sweep.py) shows registration reliability degrading before throughput does:
| UEs requested | UEs registered (60 s timeout) | Aggregate DL | Aggregate UL |
|---|---|---|---|
| 1 | 1 | 5.0 Mbit/s | 5.0 Mbit/s |
| 2 | 2 | 10.0 Mbit/s | 10.0 Mbit/s |
| 5 | 5 | 24.9 Mbit/s | 25.0 Mbit/s |
| 10 | 7 | 34.6 Mbit/s | 35.0 Mbit/s |
At 10 requested UEs, only 7 completed registration inside the timeout (the other 3 stayed in emm_state: registering, repeatedly retrying PRACH/RRC setup) — aggregate throughput tracked the number that actually attached, not a capacity ceiling (5 Mbit/s/UE was well under this cell's proven single-UE TCP ceiling of 143 Mbit/s DL). Treat 10-UE lteue registration on this rig as not yet reliable; 1/2/5 are solid.
ssh root@<du-node> 'pkill -x nr-softmodem; docker compose -f /opt/oai-cn5g/oai-cn5g-fed/docker-compose/docker-compose-basic-nrf.yaml down'
ssh root@<ue-node> 'qmicli -d /dev/cdc-wdm0 --wds-stop-network=disable-autoconnect; ip addr flush dev wwan0'
Leave the O-RU powered on unless you are done for the day — it is a shared instrument. omf save -n <du-node> only if you changed the image and want to keep the change.
| Symptom | Likely cause | Fix |
|---|---|---|
RU never radiates; RX_LATE ≈ 2× RX_ON_TIME |
RU was warm-restarted, not truly power-cycled (:830 reopened in ~80 s, not ~300 s) |
repeat the off/on cycle (Step 1) and confirm the ~300 s reopen time |
Bring-up aborts at the VF-MAC gate (iavf ... Reset never finished, VF disabled) |
E810 VFs wedged after several warm DU restarts | power-cycle the DU host itself (Step 2), don't just restart the DU process |
| Benetel only: every Msg3 fails, PRACH detects fine | RU's own ru_config.cfg TDD pattern ≠ the DU's (V2.1.0+ firmware adds RU-side TDD keys that M-Plane does NOT push) |
set tdd_pattern_1/tdd_pattern_2 = DDDSU/DDDSU, special_slots_symbols = DDDDDDGGGGUUUU in /etc/ru_config.cfg, regenerate /etc/tdd.xml, cold-cycle the RU |
Registered on one attempt, LIMSRV/stuck on another with the "same" config |
wrong UE for this O-RU — Benetel wants IMSI …032 on sdr1-in3.sb1; …033 on node1.osc completes RACH/RRC then dies ulsch_DTX 100 on Benetel |
use the UE listed in the per-vendor table; don't assume a historical "it worked" claim used the UE you're using |
| A source edit to the fronthaul code doesn't change behaviour | xran is a CMake ExternalProject and does not rebuild on source edits — ninja oran_fhlib_5g re-archives stale objects |
delete the relevant .o files and the extern_xran-{build,done,install} stamps, rebuild, then strings libxran.so \| grep <your marker> to confirm it's actually in the binary |
nr-softmodem SIGILLs on launch |
image built -march=native on a newer CPU class than this host (e.g. built on Cascade Lake Xeon 6226, run on Skylake-SP Xeon 6126) |
rebuild on the oldest CPU class you intend to run on, or bake per class |
| Cell radiates then dies the moment the DU restarts | ru_latch.sh restarted ptp4l after cuplane init |
GATE 5 in ru_latch.sh must stay read-only — restarting ptp4l post-latch kills the radio |
| Foxconn: cell up, modem camps (RSRP good), never registers | PRACH preamble is received by the RU but never accepted at the O-DU (nRxPkt<=1 / PRACH segmentation) — open, RU/DU-interop issue, not a config bug |
no known fix yet; do not re-sweep DU PRACH fields — see the linked reference below |
lteue (Amarisoft soft UE): stuck in emm_state: registering forever, RRC connects then falls back to idle on T3510 expired, lteue logs "Wrong security header type for security mode complete (0)" |
NULL security selected — two independent bugs, both must be fixed: (1) NAS-level, AMF's supported_integrity_algorithms/supported_encryption_algorithms list NIA0/NEA0 first; (2) AS/RRC-level, the gNB's own ciphering_algorithms = ( "nea0" ) only offers NULL |
reorder both AMF lists to put NIA2/NEA2 first (restart oai-amf); set the gNB's ciphering_algorithms = ( "nea2", "nea0" ) (needs a DU relaunch) |
lteue: clean registration, then PDU session establishment reject |
lteue defaults attach_pdn_type to ipv4v6; this SMF only serves IPv4 for the DNN and rejects the mismatch outright rather than downgrading |
add attach_pdn_type: "ipv4" to the UE's ue_list entry in the lteue config |
lteue: a UE-count sweep (amarisoft_sweep.py) times out registering ≥10 UEs at once, aggregate throughput lower than expected |
registration reliability, not RF/throughput — some UEs stay in emm_state: registering, repeatedly retrying PRACH/RRC setup instead of completing |
reduce the requested UE count, or budget a longer attach timeout; treat 10-UE registration on this rig as not yet reliable (1/2/5 are solid) — see the sweep table above |
lteue: RU's fronthaul ru_thread segfaults in librte_net_iavf.so under a heavy multi-UE bidirectional traffic run |
O-DU RT fronthaul TX/RX thread overrun under simultaneous heavy DL+UL load from many UEs | relaunch the DU fresh (Step 2–4) and re-run oru-apply.py --apply; prefer a single traffic direction or a lower per-UE offered load when sweeping ≥5 UEs until this is root-caused |
Quectel modem: registers, gets a PDU session and DRB cleanly, ping/iperf3 still 100 % loss — reproduced on both Duranta and OCUDU/srsRAN against this same physical modem (2026-09-12) |
Resolved 2026-09-14 — the modem's USB data path, not either gNB. The modem's USB bulk-OUT endpoint was stuck returning -EPROTO (qmi_wwan … tx throttle -71 in dmesg): wwan0 tx_errors rises by one per packet sent while tx_packets stays 0, so no uplink data ever reaches the RAN (hence bsr=0) |
a qmi_wwan unbind/rebind does not clear it; a USB device reset (USBDEVFS_RESET on the modem's /dev/bus/usb/… node) does. The tutorials' modem helpers now detect tx_errors > 0 and do this automatically (usb_heal); verified on the OCUDU path 2026-09-14 |
Shared Benetel RU handed between Duranta and OCUDU: the incoming stack's bring-up completes clean (fresh cold boot, correct registers, zero fronthaul errors) but TXMeanPower reads "No dBm" on every antenna |
the RU's /etc/ru_config.cfg (compression/mimo_mode/tdd_pattern) is still set for whichever stack used it LAST — neither bring-up script re-asserts these on its own |
run oru-apply.py --stack <target> --apply for the incoming stack, then a genuine in-RU reboot (an omf tell off/on power cycle was NOT sufficient — it left the identical stale BOOTUP TIME and stale settings twice in a row) |
Default route via wwan0 black-holes the UE node's own SSH |
a data-connection manager added a default route | use only the scoped 192.168.100.0/22 dev wwan0 route |
nr-oru on a USRP), work in progressORAN_FHI7.2_ORU_Tutorial.md in the Duranta repoomf-duranta; PHY/libconfig reference — skill oai-gnb; UE — skill quectel-5g-modem.Author(s): COSMOS team · Last verified: 2026-09-11 (Benetel, 2× Xeon Gold 6126 platform, modem + lteue); LiteOn last verified 2026-09-07 (modem only); Foxconn status as of 2026-09-05, not re-tested since · Tested image/release: duranta.ndz = duranta-20260907c, Duranta tag 2026.w36 + COSMOS patches · Tags: duranta, oai, oran, 7.2, fronthaul, benetel, liteon, foxconn, o-ru, quectel, lteue, amarisoft, 5g, sa