This page groups reported tests in 5G SA open source systems with commercial UEs

Please comment on this page, the moderator will integrate your input in the page

Starting point

A UICC, with Milenage authentication, HSS/UDR with same data: IMSI, Ki, OPc

The DNN is to set in the phone, according to the DNN in the 5GC

All UEs should work with any USIM, any PLMN, any UE HW supported bands, see Ericsson paper:

https://www.ericsson.com/en/blog/2020/1/5g-security-sim-card

These Rel 99+ USIMs can be used to access every generation of mobile networks, including 5G. Such backward and forward compatibility is achieved by the carefully designed offloading of some computations and storage to mobile phones.

It is E/// above document and 3GPP standard: any card should work, except the pure GSM ones (before 1999)

Now, we can face difficulties with today smartphones, that are NOT COMPLIANT (shame on them)

Voice over xxx

Many phones try to connect to IMS server: open a second PDU session on “ims” DNN/APN name.

Then connect to a IMS/SIP server (with open cells cards, see the FAQ for the SIP identifiers in 3GPP).

But, if this fails, some UEs simply abort all the radio link, including the default PDU session to internet.

So, if this is available in the phone menu, disable voice over xxx is a good idea for 99% of our use cases.

UEs table

RM500QGLABR11A06M4G_02.200.02.200

M.2 modules based on Qualcomm, usage with Linux

Access to AT commands

sudo screen /dev/ttyUSB2

Linux connection

sudo ip link set wwan0 down
echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip
sudo ip link set wwan0 up

sudo qmicli --device=/dev/cdc-wdm0 --device-open-proxy --dms-set-operating-mode=low-power
sudo qmicli --device=/dev/cdc-wdm0 --device-open-proxy --dms-set-operating-mode=online
sudo qmicli --device=/dev/cdc-wdm0 --device-open-proxy --wds-start-network="ip-type=4,apn=oai" --client-no-release-cid
sudo udhcpc -q -f -n -i wwan0

Swap airplane/normal mode

Add a data bearer to DNN “oai”

query the module to add IP address on the interface

SRSlte project page can help

This tutorial explains how to connect 2 UEs to a eNB, with simulated RF board, on same machine.

It reuse the other tutorials we published in a quite complex IP addresses configuration

Constrains

1. 50 RB (10MHz) as it seems current commit in develop branch doesn’t work well on 100RB
2. Full mode, with EPC: the noS1 mode seems to not work with two UEs

Let’s go

RF simulator and OAI UE tutorial

Do this tutorial, with the UE on same machine option.

To install EPC, eNB, use all-in-one tuto, with latest commit in develop branch

• • • you can add –ninja on ./build_oai … and replace all “make” by “ninja” that will be faster compilation for same result

you should reach one UE in traffic, all on one machine

Now, we will add the second UE

Make a second SIM

The UE always use the current directory files for SIM files
( hidden files: .usim.nvram0,  .ue.nvram0, .ue_emm.nvram0)

so we make a second directory and create the files in this directory

cd ..
mkdir build2
cd build2
cp ~/opencells-mods/sim.conf sim2.conf
# edit the file: change only the msin: MSIN="0100001112";
../../nas_sim_tools/build/conf2uedata -c sim2.conf -o .

Make a second network namespace

sudo ip netns delete ueNameSpace2
sudo ip link delete v-eth2
sudo ip netns add ueNameSpace2 
sudo ip link add v-eth2 type veth peer name v-ue2
sudo ip link set v-ue2 netns ueNameSpace2
sudo ip addr add 10.201.1.1/24 dev v-eth2 
sudo ip link set v-eth2 up 
sudo iptables -t nat -A POSTROUTING -s 10.201.1.0/255.255.255.0 -o enp0s31f6 -j MASQUERADE 
sudo iptables -A FORWARD -i enp0s31f6 -o v-eth2 -j ACCEPT 
sudo iptables -A FORWARD -o enp0s31f6 -i v-eth2 -j ACCEPT 
sudo ip netns exec ueNameSpace2 ip link set dev lo up 
sudo ip netns exec ueNameSpace2 ip addr add 10.201.1.2/24 dev v-ue2 
sudo ip netns exec ueNameSpace2 ip link set v-ue2 up 
sudo ip netns exec ueNameSpace2 bash

Run the second UE

cd build2
ip netns exec ueNameSpace2 bash
./lte-uesoftmodem -C 2685000000 -r 50 --rfsim --rfsimulator.serveraddr 10.201.1.1

Traffic test

In one more window, launch some traffic in the second UE

ip netns exec ueNameSpace2 bash
ping -I oaitun_ue1 10.201.1.1

version: update July, 23rd 2020

Tutorial to run 5G OpenAir, from current develop branch.

OAI 5G is very partial, only a fixed scheduler, for one UE, no network entry (no radio network entry, no upper layers network entry).

We can use “phy-test” mode, that hard code a permanent UL and DL shared channel (means a data channel dedicated to one UE in 3GPP jargon).

Of course there is no core network in this very special “phy-test” mode and some upper layer pieces are still 4G (PDCP for example).

Please read the 4G tutorial for more information on how to make initial installation of OpenAir.

Then, you can compile and run 5G tests

To compile:

./build_oai --gNB --nrUE

Run the gNB in one windows

sudo ./nr-softmodem -O ../../../ci-scripts/conf_files/gnb.band78.tm1.106PRB.usrpn300.conf --parallel-config PARALLEL_SINGLE_THREAD --rfsim --phy-test --rfsimulator.serveraddr server --noS1 -d

If you use the same machine for the UE, we have the same IP address problem as in 4G (see our post rf-simulator-and-oai-ue-tutorial)

so, create a new Linux namespace as in this tutorial

In the namespace, run

sudo ./nr-uesoftmodem -d --rrc_config_path . --nokrnmod --phy-test --rfsim --rfsimulator.serveraddr 10.200.1.1 --noS1

If it runs fine, you should see this graph:

If the graph doesn’t show working PDSCH, restart the UE as there is a random bug in UE initial synchronization.

Then, open one more text window and set it in the UE network name space

sudo ip netns exec ueNameSpace bash

It is now possible to ping the gNB output interface

ping -I oaitun_ue1 10.0.1.1 -s 1000

Sends in both directions packets of 1000 bytes.

Ping also checks the packet content is the same.

What is today available on top of this simple tutorial:

• If you make IP routing configuration, any IP traffic can get through the pair UE+gNB
• if you run the UE on another machine, it is also fine (no need of network namespaces)
• Ettus RF board may also work, if the machine is fast enough

Version 0: initial writing

This tutorial explains how to run OpenAir EPC+eNB+UE with a RF card simulator.

Starting point: the all-in-one tutorial has been run, so the system is installed and running.

Setup the UE

The all-in-one tutorial already compiled the UE, even if we didn’t use it yet.

Our patch file also contains the needed configuration files.

We need now to add a virtual SIM card in binary form to our directory:

../../nas_sim_tools/build/conf2uedata -c ~/opencells-mods/sim.conf -o .

conf2uedata command compiles a OpenAir ascii description of a SIM card into binary files that the OpenAir UE can read.

The hss dump file we provided contains the same SIM card.

Two machines: UE on a second machine

Assuming here you have a separate machine for the UE, you have to install OAI again, nevertheless the next step is easy.

On eNB machine, run the eNB as with RF board, but adding “–rfsim” and some parameters in the configuration file (see “rfsimulator” section we added in ~/opencells-mods/enb.10MHz.b200).

sudo ./lte-softmodem –rfsim -O ~/opencells-mods/enb.10MHz.b200 –log_config.hw_log_level error

“–log_config.hw_log_level error” is there to show how you can change the log level per component on the command line. This is possible for all parameters. We will use the same for UE, because the UE doesn’t have a configuration file.

Lets’ run the UE on the second machine

./lte-uesoftmodem -C 2685000000 -r 50 --rfsim --rfsimulator.serveraddr a.b.c.d

a.b.s.d is the eNB machine IP address.

The UE is now running, any IP traffic can be routed by the LTE network: UE+eNB+EPC

One machine UE + SGi interface

3GPP networks tunnel the UE IP address to the SGi.

SGi is in the PGW for regular LTE, maybe in the eNB in OpenAir noS1 mode.

The UE can’t run directly on the same “machine” because both UE and the 3GPP network border (PGW, or eNB in all cases where eNB performs local connection to internet (OAI nS1, LIPA, SIPTO, …)) will try to route the same IP address.

One solution is to run the UE in a virtual machine.

A lighter solution is to create only a network namespace for the UE (a component of a “virtual machine”)

In case of previous trails, delete the already created network namespaces

assuming enp0s31f6 is your network interface to internet, and that network 10.200.1.0 can be used freely in your intranet.

ip netns delete ueNameSpace
ip link delete v-eth1
ip netns add ueNameSpace  
ip link add v-eth1 type veth peer name v-ue1
ip link set v-ue1 netns ueNameSpace
ip addr add 10.200.1.1/24 dev v-eth1  
ip link set v-eth1 up  
iptables -t nat -A POSTROUTING -s 10.200.1.0/255.255.255.0 -o enp0s31f6 -j MASQUERADE  
iptables -A FORWARD -i enp0s31f6 -o v-eth1 -j ACCEPT  
iptables -A FORWARD -o enp0s31f6 -i v-eth1 -j ACCEPT 
ip netns exec ueNameSpace ip link set dev lo up   
ip netns exec ueNameSpace ip addr add 10.200.1.2/24 dev v-ue1  
ip netns exec ueNameSpace ip link set v-ue1 up 

Set your window in the new namespace:

ip netns exec ueNameSpace bash

Run the UE

./lte-uesoftmodem -C 2685000000 -r 50 --rfsim --rfsimulator.serveraddr 10.200.1.1

you need now to transfer all ip packets in the namespace to the IP interface created by the OpenAir UE

route add default oaitun_ue1

Now, you can run any application in the UE namespace: all IP traffic will go through the UE+eNB+EPC

ip netns exec ueNameSpace bash

ping 8.8.8.8

DNS in the UE namespace

DNS resolv is convenient to use in the UE namespace.

If your DNS configuration uses a gateway on lo (a address starting by 127.0.0 as do Ubuntu by default), resolv won’t work because you have another lo interface inside the network namespace (so the DNS query won’t reach the resolver outside of the namespace).

The simplest is to add a routable DNS server in your Linux configuration for also this namespace, example using the google DNS server:

sudo echo 'nameserver 8.8.8.8' >> /etc/resolv.conf

We wrote a tutorial on the OAI SW internal design for the last workshop

It introduces for new developpers how to enter inside the OAI code: datamodel, SW design

https://open-cells.com/d5138782a8739209ec5760865b1e53b0/OAI-general.pdf

Dielectric duplexers

We consider to make dielectric duplexers.

We would like some feedback on this post from interested future customers (no commitment).

The early prototype is like this with SMA connectors

This is much cheaper and smaller than cavity duplexers.

The technical specifications are also a bit lower: insertion loss is about 2dB, rejection between channels is around 50dB, maximum power near 2 watts

Target price would be 50€/piece,
shipping will also be low cost as the device is small.

We consider these 3 bands

Band3:1710-1785/1805-1880MHz

Band7:2500-2570/2620-2690MHz

Band13:777-787/746-756MHz

Connectors can be SMA or U.FL (we will supply also the cables if needed).

We actually need some feedback to decide to produce these devices

If you need some other devices on top of USRP, Lime, … you can also feedback in this post.

We use the latest commit in https://github.com/myriadrf/LimeSuite.git

Ubuntu 18.04

LimeSDR (HW: V1.4) flashed with latest firmware (Limeutil –update)

Scope: LTE SISO downlink signal

We use a custom OpenAirInterface version

The LimeSDR interface code is:

LMS_Open(&lms_device,list[0],NULL);
 LMS_Init(lms_device);
 LMS_Reset(lms_device);

LMS_EnableCalibCache(lms_device,false);
 LMS_LoadConfig(lms_device, );
 LMS_SetSampleRate(lms_device,4), “”); //rate is LTE standard one, so a division of 30720MS/s
 LMS_SetLOFrequency(lms_device,LMS_CH_RX, 0); // several feq tested 700MHz-3600MHz
 LMS_SetLOFrequency(lms_device,LMS_CH_TX, 0); // Tx/Rx freq are different, gap is defined by 3GPP
 LMS_SetGaindB(lms_device, LMS_CH_TX, 0, MyGain);
 LMS_SetGaindB(lms_device, LMS_CH_RX, 0, MyGain);
 //value is 0…70, we saw the today limitation: it is not actually in dB, but still the range is 0…70
 LMS_SetLPFBW(lms_device,LMS_CH_RX,0,ChosenLTEBand); // 5MHz or 10MHz or 20MHz
 LMS_SetLPFBW(lms_device,LMS_CH_TX,0,ChosenLTEBand);
 LMS_Calibrate(lms_device,LMS_CH_RX,0,ChosenLTEBand,0);
 LMS_Calibrate(lms_device,LMS_CH_TX,i,ChosenLTEBand,0)

First observation is: the API calls often fails: calibration reports failures

With some ini files, it is simply impossible to run successfully the above sequence.

With “good” ini files, we have to power-off the board before each trial.

The key problem is to make a decent .ini file, that is good only in a specific case: RF band, modulated band, power, …

Then, even with a good ini file, the result of the calibration is not repeatable, and often fails randomly (need to power off the LimeSDR board).

Measuring this DL signal

A USRP B210 output:

The best of LimeSDR can be close to this

Even in this best result, the DC offset is not well calibrated

Also it is not repeatable, and depend heavily of the .ini file we use

or non repeatable results

At lower frequency, LimeSDR is globally better

We released our software to program UICC/SIM/USIM cards.

We tested and support it only with our cards and our card reader, nevertheless it is GPL license open source.

Please provide us with enhancements source code, as per GPL license rules

uicc-software

We offer support as comments on this blog page, and a FAQ

(if your question is very confidential, send us a mail)

Signed kernel module: how to

• Compilation of a kernel module like this example
  • cd opencells-mods/gtp_mod
  • make -C /lib/modules/$(uname -r)/build M=$PWD
  • sudo cp gtp.ko /lib/modules/$(uname -r)/kernel/drivers/net/gtp.ko
• But, despite we just compiled it successfully,  the module can’t be loaded
  • modprobe gtp
  • ERROR: could not insert ‘gtp’: Operation not permitted

your kernel boot is in “secure boot”, the module can’t be loaded

This issue occurs also with other modules in AOI, like ue_ip.kp

• Solution 1
  • • Remove “secure boot” entirely
    • depends on UEFI bios
    • Can be done by

    • sudo apt install mokutil
      
      sudo mokutil --disable-validation

    • After this, reboot  the computer, the UEFI bios should ask for the password you set with “mokutil”, then ask to accept to disable secure boot
• Solution 2
  • Sign your modules
  • add you own signature to valid signatures
    • create ciphering keys

    • openssl req -new -x509 -newkey rsa:2048 -keyout OCP.priv -outform DER -out OCP.der -nodes -days 36500 -subj "/CN=OpenCells/"

    • keep the two files OCP.der, OCP.priv as you’ll need it to sign your kernel modules
    • import it in UEFI boot

    • sudo mokutil --import OCP.der

    • It asks for a password: put any string, you’ll need it once, at next reboot, to secure the new ciphering enrolling
    • You need to reboot the machine to enroll this new key
  • Now you can sign your modules
    • each time you compile a module, you have to sign it
    • (after: sudo cp gtp.ko /lib/modules/`uname -r`/kernel/drivers/net/gtp.ko)

  • sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./OCP.priv ./OCP.der $(modinfo -n gtp)

  • now “sudo modprobe gtp”  should not complain anymore
• You’ll need to compile and update the module after each Ubuntu kernel upgrades