ARM-Callbox
This tutorial shows how to port Amarisoft callbox onto a ARM based embedded board. It is a good use case for low power and more portable solution like Small Cell or any other types of embedded system with cellular network functionality.
Table of Contents
- ARM-Callbox
Test Setup
Test setup for this tutorial is as shown below.
- SIM Card used in this tutorial is the one delivered with the system as it is.
- If you want to change the configuration, The tutorial Configuration Guide would help
The embedded board used in this tutorial is SolidRun Honeycomb board as shown below. (
Following is the entire setup for this tutorial. In this tutorial, SDR 100 is used but it can work with SDR 50 as well.
Key Configuration Parameters
Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.
Configuration
Once the pasic preparation for the installation and callbox software is installed properly, configuration for the test is exactly same as with regular callbox. You can do most of test that can be done by regular Amarisoft callbox (
For a simple test, I used the gnb-sa-100Mhz-2x2.cfg which is modified from gnb-sa.cfg
Configure gnb-sa-100Mhz-2x2.cfg as follows.
Specify Duplex method (NR_TDD), Channel Bandwidth (NR_BANDWIDTH) and MIMO Scheme(N_ANTENNA_DL). One thing that was configured specially for this test is the bandwidth. I set it to 100Mhz which is the maximum bandwidth for the single cell and it was to see the performance of the board is good enough for such a wide band.
RF driver setting is same as default (regular) setting. (
For this test, a basic TDD band is used as default setting.
Perform the test
Start LTE service and check basic cell configuration.
Now try out 'cell' and 'cell phy' to check if the cell is configured as intended.
Power on UE and let UE attach to the cell.
You can try to flood high level IP data to get more clear idea on end-to-end performance.
Log Analysis
First check on overall log text to see if the initial attach properly went through.
Then check out the throughput plot. This is physical layer throughput.
It would be good idea to check on SNR and EPRE to check radio link quality. You may adjust parameters (e.g, rx_gain, tx_gain, the direction of antenna and distance between UE and gNB antenna etc) to get the SNR/EPRE profile as good as possible.
You can check out the physica layer scheduling state with RB map as shown below. In this test, we flooded UDP in downlink and didn't inject any traffic in uplink. So you see most of the PDSCH slot are fully loaded and uplink slot is mostly empty.
Limitations
We are at relatively early stages of evaluating our software at ARM and Embedded board. We have faced some limitations with this kind of system which in most case understandable considering that the setup has an embedded system which has limited physical resources and lower performing CPUs comparing to high end PC. In this section, I will collect a list of limitations and restrictions that we faced during the evaluation.
Number of SDR Cards
Obviously this comes from the number of PCI slots available on the system. There is only one PCI slots on this board which means you can put only one SDR card on the system. This would cause various different limitations depending on whether you use SDR50 or SDR100.
- SDR50 : SDR50 can support only upto 2x2 MIMO and support only one cell with one sdr card. So if you use sdr50 with the board used in this tutorial, you will have these limination tied to SDR50.
- SDR100 : SDR100 can support upto 4x4 MIMO (4x4 MIMO single cell) and support up to 2 cells (each cell upto 2x2 MIMO) with one sdr card. So if you use sdr50 with the board used in this tutorial, "theoretically" you should be able to run 4x4MIMO single cell, but as far as I tried 4x4 MIMO causes underflow issues with bhe bandwidth goes very wide (like 100Mhz).
Performance
- Throughput : As of now, we achieved the full downlink throughput for NR SA 100Mhs Bandwidth with 2x2 downlink MIMO.
- Logging : Without WebGUI running turing the test, you would achieve full stack logging with full throughput, but a considerable amount of low layer logging would be skipped(i.e, not collected) if you are collecting the log with WebGUI