Over-the-Air Environment Deployments
Deployment
Use the command brc install network <deployment-name>.yaml to deploy the network.
It should finish without errors and printout the Kubernetes resource names that were created.
Check for the status of the deployment using the command brc observe.
Wait until all the Elements other than the UE are in the STATUS set to
1/1 Y state.
Basic Deployment with USRP
This deployment includes a simple 5G Standalone (SA) network with OpenAirInterface (OAI) gNB using a NI/Ettus USRP B210, and OAI minimal 5GC to analyze the control plane and data plane.
apiVersion: athena.trirematics.io/v1
kind: Network
metadata:
name: bubbleran
namespace: trirematics
spec:
slices:
- plmn: "00101"
dnn: "internet"
network-mode: "IPv4"
service-type: eMBB
differentiator: 0x000000
ipv4-range: "12.1.1.0/24"
ipv6-range: "2001:db8:1::/64"
access:
- name: oai-gnb
stack: 5g-sa
model: oai-ran/monolithic-gnb
identity:
an-id: 50
radio:
device: uhd-b200
cells:
- band: n78
arfcn: 641280
bandwidth: 40MHz
subcarrier-spacing: 30kHz
tdd-config:
period: 5ms
dl-slots: 7
dl-symbols: 6
ul-slots: 2
ul-symbols: 4
core-networks:
- minimal.bubbleran
core:
- name: minimal
stack: 5g-sa
model: oai-cn/minimal
identity:
region: 0
cn-group: 4
cn-id: 5
dns:
ipv4:
default: 8.8.8.8
secondary: 8.8.4.4
This deployment does not include a terminal (UE) so it should be installed seperately. For Over-the-Air deployments you may either use:
- Quectel module (normally included with your MX-PDK) connected to one of the cluster nodes. With this option, the terminal will be deployed as a Kubernetes pod and
brc testCLI commands for generating traffic will be available. Model to be used in deployment file spec:terminal/quectel - Quectel module connected to a laptop. With this option, the terminal can be controlled with our Snap application, but traffic generation will need to be done manually (i.e., not using
brc testCLI commands). Model to be used in deployment file spec:terminal/external - A smartphone. With this option, the terminal will be controlled by the user. Model to be used in deployment file spec:
terminal/external
Quectel Deployment
apiVersion: athena.trirematics.io/v1
kind: Terminal
metadata:
name: ue01
namespace: trirematics
spec:
vendor: oai
stack: 5g-sa
model: terminal/quectel
target-cores:
- minimal.bubbleran
identity:
imsi: "001010000000001"
pin: "1234"
opc: "0xC42449363BBAD02B66D16BC975D77CC1"
key: "0xfec86ba6eb707ed08905757b1bb44b8f"
sqn: "0xff9bb4000001"
slice:
dnn: internet
network-mode: IPv4
service-type: eMBB
differentiator: 0x000000
radio:
bands:
- n78
readiness-check:
method: ping
target: google-ip
External Deployment
apiVersion: athena.trirematics.io/v1
kind: Terminal
metadata:
name: ue01
namespace: trirematics
spec:
vendor: oai
stack: 5g-sa
model: terminal/external
target-cores:
- minimal.bubbleran
identity:
imsi: "001010000000001"
pin: "1234"
opc: "0xC42449363BBAD02B66D16BC975D77CC1"
key: "0xfec86ba6eb707ed08905757b1bb44b8f"
sqn: "0xff9bb4000001"
slice:
dnn: internet
network-mode: IPv4
service-type: eMBB
differentiator: 0x000000
radio:
bands:
- n78
External terminal spec should not include a readiness check.
Deployment with monitoring xApp
This deployment includes a 5G Standalone (SA) network with OpenAirInterface (OAI) gNB using a NI/Ettus USRP B210, and OAI minimal 5GC, but this time using the F1 Split architecture. We also deploy FlexRIC as the Near-RT RIC with a monitoring xApp.
apiVersion: athena.trirematics.io/v1
kind: Network
metadata:
name: bubbleran
namespace: trirematics
spec:
slices:
- plmn: "00102"
dnn: "internet"
network-mode: "IPv4"
service-type: eMBB
differentiator: 0x000000
ipv4-range: "12.1.1.0/24"
ipv6-range: "2001:db8:1::/64"
access:
- name: oai-gnb
stack: 5g-sa
model: oai-ran/monolithic-gnb
identity:
an-id: 50
radio:
device: uhd-b200
cells:
- band: n78
arfcn: 641280
bandwidth: 40MHz
subcarrier-spacing: 30kHz
tdd-config:
period: 5ms
dl-slots: 7
dl-symbols: 6
ul-slots: 2
ul-symbols: 4
controller: flexric.bubbleran
core-networks:
- minimal.bubbleran
core:
- name: minimal
stack: 5g-sa
model: oai-cn/minimal
identity:
region: 0
cn-group: 4
cn-id: 5
dns:
ipv4:
default: 8.8.8.8
secondary: 8.8.4.4
edge:
- name: flexric
stack: 5g-sa
model: mosaic5g/flexric
- name: monitoring
stack: 5g-sa
model: mosaic5g/monitoring-python
profiles:
- rlc-sm
- pdcp-sm
- mac-sm
- gtp-sm
- slice-sm
- kpm-sm
- database
- name: sdl
stack: 5g-sa
model: mosaic5g/xapps-sdl
---
apiVersion: athena.trirematics.io/v1
kind: Terminal
metadata:
name: ue01
namespace: trirematics
spec:
vendor: ogs
stack: 5g-sa
model: terminal/quectel
target-cores:
- minimal.bubbleran
identity:
imsi: "001020000000002"
pin: "1234"
opc: "0xC42449363BBAD02B66D16BC975D77CC1"
key: "0xfec86ba6eb707ed08905757b1bb44b8f"
sqn: "0xff9bb4000001"
slice:
dnn: internet
network-mode: IPv4
service-type: eMBB
differentiator: 0x000000
radio:
bands:
- n78
readiness-check:
method: ping
target: google-ip
Deployment with 7.2 Split and LITEON RU
This deployment includes a 5G Standalone (SA) network with OpenAirInterface (OAI) gNB using a LITEON RU, and Open5GS core to analyze the control plane and data plane.
apiVersion: athena.trirematics.io/v1
kind: Network
metadata:
name: liteon-demo
namespace: trirematics
spec:
slices:
- plmn: "00101"
dnn: internet
network-mode: IPv4
service-type: eMBB
differentiator: 0x000000
ipv4-range: 12.1.1.0/24
ipv6-range: 2001:db8:1::/64
access:
- name: oai-gnb
stack: 5g-sa
model: oai-ran/monolithic-gnb-ru #cu-du-ru
identity:
an-id: 30
tracking-area: 1
radio:
device: oran-7.2
antenna:
formation: 4x4
scheduling:
nodeName: bubble3
annotations:
extras.t9s.io/pci-ids: '["0000:01:11.0", "0000:01:11.1"]'
extras.t9s.io/du-macs: '["02:11:22:33:44:68", "02:11:22:33:44:69"]'
extras.t9s.io/ru-macs: '["e8:c7:4f:25:81:d1", "e8:c7:4f:25:81:d1"]'
extras.t9s.io/mtu: '9000'
extras.t9s.io/o1-remote-ipv4: 192.168.50.13
extras.t9s.io/liteon-ru-reboot: 'true' #'true'
cells:
- band: n78
arfcn: 623328
bandwidth: 100MHz
subcarrier-spacing: 30kHz
tdd-config:
period: 2.5ms
dl-slots: 3
dl-symbols: 6
ul-slots: 1
ul-symbols: 4
core-networks:
- open5gs.liteon-demo
core:
- name: open5gs
stack: 5g-sa
model: open5gs/5gc
profiles:
- debug
identity:
region: 128
cn-group: 4
cn-id: 5
dns:
ipv4:
default: 8.8.8.8
secondary: 4.4.4.4
Deployment with 7.2 Split and Benetel RU
This deployment includes a 5G Standalone (SA) network with OpenAirInterface (OAI) gNB using a Benetel RU, and Open5GS core to analyze the control plane and data plane.
apiVersion: athena.trirematics.io/v1
kind: Network
metadata:
name: benetel-demo
namespace: trirematics
spec:
slices:
- plmn: "00101"
dnn: internet
network-mode: IPv4
service-type: eMBB
differentiator: 0x000000
ipv4-range: 12.1.1.0/24
ipv6-range: 2001:db8:1::/64
access:
- name: oai-gnb
stack: 5g-sa
model: oai-ran/monolithic-gnb-ru-benetel #cu-du-ru
identity:
an-id: 30
tracking-area: 1
radio:
device: oran-7.2
antenna:
formation: 4x4
scheduling:
nodeName: bubble2
annotations:
extras.t9s.io/pci-ids: '["0000:01:11.1", "0000:01:11.0"]'
extras.t9s.io/du-macs: '["02:11:22:33:44:67", "02:11:22:33:44:66"]'
extras.t9s.io/ru-macs: '["8c:1f:64:d1:12:f2", "8c:1f:64:d1:12:f2"]'
extras.t9s.io/mtu: '9600'
extras.t9s.io/o1-remote-ipv4: 172.20.179.186
extras.t9s.io/benetel-ru-reboot: 'false' #'true'
cells:
- band: n77
arfcn: 650016 #676320
bandwidth: 100MHz
subcarrier-spacing: 30kHz
tdd-config:
period: 5ms
dl-slots: 7
dl-symbols: 6
ul-slots: 2
ul-symbols: 4
core-networks:
- open5gs.benetel-demo
core:
- name: open5gs
stack: 5g-sa
model: open5gs/5gc
profiles:
- debug
identity:
region: 128
cn-group: 4
cn-id: 5
dns:
ipv4:
default: 8.8.8.8
secondary: 8.8.4.4
Deployment with LITEON All-In-One (AIO) Small Cell
This deployment includes a 5G Standalone (SA) network with using a LITEON All-In-One (AIO) small cell, and Open5GS core to analyze the control plane and data plane.
apiVersion: athena.trirematics.io/v1
kind: Network
metadata:
name: pro
namespace: trirematics
spec:
# LiteON AIO only supports one slice configuration
slices:
- plmn: "00101"
dnn: internet
network-mode: IPv4
service-type: eMBB
differentiator: 0x000000
ipv4-range: 12.1.1.0/24
ipv6-range: 2001:db8:1::/64
access:
# To access the AIO via the serial port, plug the USB to the control plane node and run the following command:
# sudo picocom --baud 115200 {proper-device-under-/dev/ttyUSB*}
# To exit picocom, press Ctrl+A followed by Ctrl+X.
# To access the AIO via SSH, run the following command:
# ssh user@{IP-address}
# The default password is: Usr5566#
- name: liteon
stack: 5g-sa
model: bubbleran/liteon-aio
annotations:
# In the current version only the RJ-45 interface of the LiteON AIO is supported and this is the IP
# address of the RJ-45 interface.
extras.t9s.io/o1-remote-ipv4: 192.168.50.50
identity:
an-id: 30
tracking-area: 1
radio:
device: oran-7.2
antenna:
# LiteON AIO accepts values from 0 to 24 dBm for the Tx gain and does not accept Rx gain values.
tx-gain: "24"
# Default formation for LiteON AIO is 4 DL layers and 2 UL layers and cannot be changed in this
# version.
formation: 4x2
# LiteON AIO only supports a single cell
cells:
# LiteON AIO only supports band n78, using other bands would have no effect.
- band: n78
# LiteON AIO only supports the following combination of ARFCN and bandwidth:
# - ARFCN: 625382, Bandwidth: 80MHz
# - ARFCN: 628334, Bandwidth: 50MHz
# - ARFCN: 628334, Bandwidth: 100MHz
# - ARCFN: 647484, Bandwidth: 100MHz (default)
# - ARFCN: 650000, Bandwidth: 100MHz
arfcn: 647484
bandwidth: 100MHz
subcarrier-spacing: 30kHz # LiteON AIO only supports 30kHz subcarrier spacing
# In the current version we only support the following slot configuration for LiteON AIO:
tdd-config:
period: 5ms
dl-slots: 7
dl-symbols: 0
ul-slots: 2
ul-symbols: 6
core:
- name: open5gs
stack: 5g-sa
model: open5gs/5gc
profiles:
- debug
identity:
region: 128
cn-group: 4
cn-id: 5
dns:
ipv4:
default: 8.8.8.8
secondary: 8.8.4.4
Status Assessment and troubleshooting
Healthy UE attach and data activity
pps 127488 kbps 4214777][Total Msgs_Rcvd 14284785]
[NR_PHY] [o_du0][pusch0 3225585 prach0 345632]
[NR_PHY] [o_du0][pusch1 3225592 prach1 345600]
[NR_PHY] [o_du0][pusch2 3225590 prach2 345600]
[NR_PHY] [o_du0][pusch3 3225586 prach3 345600]
[NR_MAC] Frame.Slot 256.0
UE RNTI 8f6d CU-UE-1 ID 1 in-sync PH 47 dB PCMAX 24 dBm, average RSRP -71 (32 meas)
CQI 15, RI 2, PMI (0,1)
UE 8f6d: dlsch_rounds 1278/692/678/665, dlsch_errors 597, pucch0_DTX 2632, BLER 0.54206 MCS (1) 3
UE 8f6d: dlsch_rounds 1118/117/74, dlsch_errors 3, ulsch_DTX 0, BLER 0.00000 MCS (1) 6
UE 8f6d: MAC: TX = 175737 RX = 165266 bytes
LCID 1: TX 907 RX 3878 bytes
LCID 2: TX 126 RX 28 bytes
LCID 4: TX 4371 RX 1578 bytes
- RSRP around -70 dBm (typical indoor)
- Low uplink BLER (0.00000) – good uplink channel
- Downlink BLER ~0.53 – moderate downlink quality
- MAC layer TX/RX activity confirms user-plane traffic
- On LITEON Once the gNodeB connects to RU, the
du-connectedfield should change toReadyas shown below when we run:show oru-status
Sync State : SYNCHRONIZED
RF State : Ready
DPD : Ready
DuConnected : Ready
- On Benetel Once the gNodeB connects to RU, the antena transmission can be checked using:
TXMeanPowerand if all 4 in the 4RX4TX configuration are up, one should see:
TX 1 Mean Power: 10.7029 dBm
TX 2 Mean Power: 4.37732 dBm
TX 3 Mean Power: 9.40766 dBm
TX 4 Mean Power: 10.2364 dBm
In addition, KPI measurements can be checked using: kpi.sh
Good transmission means the LATE and EARLY packet counters are zeros as shown in the example:
SAMPLE_TIME | RX_TOTAL | RX_ON_TIME | RX_EARLY | RX_LATE | RX_ON_TIME_C | RX_EARLY_C | RX_LATE_C | TX_TOTAL
10:32:25.066903 | 92959 | 83396 | -0 | -0 | 9604 | -0 | -0 | 32400
10:32:26.065888 | 92672 | 83032 | -0 | -0 | 9592 | -0 | -0 | 32400
10:32:27.065919 | 92883 | 83272 | -0 | -0 | 9596 | -0 | -0 | 32400
10:32:28.067132 | 92930 | 83136 | -0 | -0 | 9608 | -0 | -0 | 32400
10:32:29.070562 | 92837 | 83384 | -0 | -0 | 9620 | -0 | -0 | 32505
If the RX_ON_TIME counters is 0, with RX_EARLY , RX_LATE, populated as shown below:
SAMPLE_TIME | RX_TOTAL | RX_ON_TIME | RX_EARLY | RX_LATE | RX_ON_TIME_C | RX_EARLY_C | RX_LATE_C | TX_TOTAL
11:07:48.053547 | 92978 | -0 | 41868 | 41600 | -0 | 4408 | 4424 | -0
11:07:49.048914 | 92817 | -0 | 41340 | 41600 | -0 | 4392 | 4384 | -0
11:07:50.046409 | 92844 | -0 | 41720 | 41600 | -0 | 4400 | 4392 | -0
11:07:51.048411 | 92781 | -0 | 41518 | 41600 | -0 | 4400 | 4416 | -0
Resolve by checking the ptp4l and phc2sys services in the DU server; If any of them is in a failed state, restart:
sudo systemctl restart ptp4l.service
sudo systemctl restart phc2sys.service
- OAI gNB/CU-DU
Successful DU RU connection, you see the following tx rx counters in the gnb log:
[NR_PHY] [o-du 0][rx 14284785 pps 63488 kbps 2759808][tx 28684916 pps 127488 kbps 4214777][Total Msgs_Rcvd 14284785]
[NR_PHY] [o_du0][pusch0 3225585 prach0 345632]
[NR_PHY] [o_du0][pusch1 3225592 prach1 345600]
[NR_PHY] [o_du0][pusch2 3225590 prach2 345600]
[NR_PHY] [o_du0][pusch3 3225586 prach3 345600]
[NR_MAC] Frame.Slot 256.0
- If below logs is observed, with zero tx and rx counters, the
devmemcommands that set the transmission mode and the PRACH compression may not be well set. reboot the RU and reapply the devmem settings If the above devmem settings are not made, pusch and prach counters will have zeros as below;
[NR_PHY] [o-du 0][rx 0 pps 0 kbps 0][tx 1020100 pps 127488 kbps 4717971][Total Msgs_Rcvd 0]
[NR_PHY] [o_du0][pusch0 0 prach0 0]
[NR_PHY] [o_du0][pusch1 0 prach1 0]
[NR_PHY] [o_du0][pusch2 0 prach2 0]
[NR_PHY] [o_du0][pusch3 0 prach3 0]
- Errors regarding received time not matching the expected time
apply the
realtimeprofile Restart theptp4landphc2sysservices
[PHY] Received Time doesn't correspond to the time we think it is (slot mismatch, received 480.5, expected 475.8)
[PHY] Received Time doesn't correspond to the time we think it is (frame mismatch, 480.5 , expected 475.5)
[PHY] Jump in frame counter last_frame 480 => 519, slot 19
[PHY] Received Time doesn't correspond to the time we think it is (slot mismatch, received 519.19, expected 480.12)
Checking Status of CU-DU nodes
Here are the commands for CU-DU (gNB) nodes using O-RAN 7.2 to be run after each reboot.
-
Check the IP and interfaces:
ip address show -
Initialize the DPDK (after every reboot):
sudo dpdk-setup # produces the PCI addresses createdyou may view the contents of the script via:
sudo vim /bin/dpdk-setup -
Check the virtual MAC addresses
ip link show # under dpdk0, vf0 and vf1 -
Synchronization checks:
sudo systemctl status ptp4l.serviceshould show low numerical values for the diff -- Ideally -10 < x < +10
sudo systemctl status phc2sys.serviceShould show low numerical values for the diff -- Ideally -10 < x < +10
-
If restarting the services is needed, you may run:
sudo systemctl restart ptp4l.servicesudo systemctl restart phc2sys.service -
Check the journal logs for the PTP or PHC2sys
sudo journalctl --unit ptp4l --unit phc2sys --follow
Running UEs from outside the cluster
If in your over-the-air deployment you are using external UEs, in the case of using the Quectel UEs provided by BubbleRAN, you will need to connect them to an Ubuntu system (e.g. a laptop) and start it. For controlling the provided Quectel UEs, all customers get a USB stick with our UE snap which can be used for setting up the UE to connect to the deployed network.
Quectel Connection manager (CM) with Snap
You can insatll the Quectel CM snap on an Ubuntu machine to connect to the 5G network deployed on your cluster. Here are the steps:
-
Install the snap
sudo snap install --devmode new-oai-ue.snap -
check if the snap is installed
snap list -
Init the Snap
sudo oai-ue.init -
Configure the Quectel Module
sudo oai-ue.conf edit quectelEdit the file and add the desired PLMN, bands, etc.
-
Give the permission to the Snap to connect to the USB
sudo snap connect oai-ue:raw-usb -
Run the Quectel CM
sudo oai-ue.quectel -
To stop, just hoit the control ^C
Check out more about the snaps