All in one OpenAirInterface, August 22nd

(Sept 7th 2017: small update for more recent eNB git commit version in develop branch)

This post is a full re-test with latest August 22nd versions:
Ubuntu 17.04 all packages upgraded, uhd last commit, OAI last commit

Modifications

Latest commits
Fix a issue in mme that crash mme with some phones in the attach-request procedure
If you want to fix only this issue, pick files:
src/nas/emm/Attach.c
src/nas/ies/SupportedCodecList.c
in the hereafter tar file
The issue is: mme wrong decoding of smartphone codec list
Full re-test, from disk install of Ubuntu 17.04 to commercial UEs throughput measurement (Android 5 and Android 6)

This document explains how to install and configure OAI EPC+eNB on one single Ubuntu 17.04 64 bits machine connected with a regular UE, routing the UE traffic to internet.

The description uses a USRP B210 board, a Lime SDR page is provided separately.

We also explain how to simplify, fix existing issues, to make a single computer as a full LTE network: EPC+eNB.

Known limitations fixed in the hereafter description

OAI EPC require kernel >= 4.7, so we have to use Ubuntu 17.04
- We already pushed some enhancements in OAI, nevertheless some more are required (Ubuntu 16.04.3 is almost same as 17.04)
GTP UDP ports are in conflict for eNB and SGW
Useless link between OAI and the Ubuntu/Linux hostname removed
Several simplifications and precisions to make easier and reliable installations

Install Ubuntu

Prepare a machine: a 4 actual cores, no hyper-threading.
All other configuration in OAI Wiki (C1 states, …) describes is about useless.
Download Ubuntu 17.04 64 bits version iso file
create a usb key to boot on it
install Ubuntu: choose to install Third party SW, and to upgrade all packages while installing
do: apt update; apt upgrade until the machine is up-to-date

install git and configure your identification in git:

 sudo apt install git 
 git config --global user.name "Laurent"
 git config --global user.email "laurent.thomas@open-cells.com"

Add the OAI repository as authorized remote system

echo -n | openssl s_client -showcerts -connect gitlab.eurecom.fr:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt

if you are upset with sudo password, add this line in /etc/sudoers
- xxxxxx ALL=(ALL) NOPASSWD: ALL (xxxxxx is your login name)
- sudo will not ask anymore for a password

Install USRP drivers

We prefer to use UHD driver from source:

sudo apt-get install libboost-all-dev libusb-1.0-0-dev python-mako doxygen python-docutils python-requests cmake build-essential
git clone git://github.com/EttusResearch/uhd.git
cd uhd; mkdir host/build; cd host/build
cmake -DCMAKE_INSTALL_PREFIX=/usr ..
make -j4
sudo make install
sudo ldconfig
sudo /usr/lib/uhd/utils/uhd_images_downloader.py

Download our modifications

download: patches extract the data:

cd
tar xf Downloads/opencells-mods-20170823.tgz

Download & Compile the eNB on 17.04

git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
cd openairinterface5g
git checkout develop

We tested with commit 17b9a9e917ce2a3a8c7004c7b9a221c350ddfe17

We already merged in develop most of updates for Ubuntu 17.04, so we need only to add in build_helper file the Ubuntu 17.04 support

cp ~/opencells-mods/cmake_targets/tools/build_helper cmake_targets/tools

Now, you should be able to build as usual the eNB

source oaienv  
./cmake_targets/build_oai -I       # install SW packages from internet
./cmake_targets/build_oai  -w USRP --eNB --UE # compile eNB

Download and patch EPC

Clone OAI EPC:

# maybe go back to home directory (leave openairinterface5g directory)
git clone https://gitlab.eurecom.fr/oai/openair-cn.git
cd openair-cn
git checkout develop

We tested with commit: 724542d0b59797b010af8c5df15af7f669c1e838

Apply the patch:

git apply ~/opencells-mods/EPC.patch

The new version of the source files are also in the tar, if you want to merge with another version of OpenAir EPC

What is in the patch file:

Add Ubuntu 17.04 for compilation and fix some bugs
- build/tools/build_helper
- src/common/common_defs.h
- src/oai_hss/utils/hss_config.c
Remove link between Linux host name and LTE diameter protocol configuration
- src/s6a/s6a_peer.c
Add usage of the input address for the SGW input socket
- src/gtpv1-u/gtp_mod_kernel.c
- src/gtpv1-u/gtp_mod_kernel.h
- src/gtpv1-u/gtpv1u_task.c

No kernel module patch is required anymore: generic Ubuntu kernel 17.04 works fine with OAI

Install third party SW for EPC

cd openair-cn; source oaienv; cd scripts
./build_hss -i

set your MySQL password and remember it!
Answer yes to install: freeDiameter 1.2.0
phpmyadmin:
- choose light or apache as you prefer
- Configure database for phpmyadmin with dbconfig-common: yes
- password: same as MySQL for simplicity
- We don’t use phpmyadmin later in this procedure, nevertheless we tested successfully also with it

Install 3PP SW for mme and spgw

./build_mme -i

Do you want to install freeDiameter 1.2.0: no
Do you want to install asn1c rev 1516 patched? <y/N>: no
Do you want to install libgtpnl ? <y/N>: yes
wireshark permissions: as you prefer

 ./build_spgw -i

Do you want to install libgtpnl ? <y/N>: no

Compile the EPC nodes

No difficulty found in this phase.

cd openair-cn; source oaienv; cd scripts
./build_hss
./build_mme
./build_spgw

Our Network setup description

I’ve made a simple configuration for this all-in-one setup.

Each node is on a separate IP address, this address is used for all it’s interfaces. In our case of all-in-one, we take addresses on the loopback: this will be fine on all your machines.

HSS is on localhost: 127.0.0.1
eNB is on 127.0.0.10
MME is on 127.0.0.20
SPGW is on 127.0.0.30

The LTE diameter configuration is now isolated from Linux hostname.

realm for our EPC: “OpenAir5G.Alliance”, so, full distinguish names (FQDN) are: hss.OpenAir5G.Alliance, mme.OpenAir5G.Alliance

Install this configuration for eNB

In your eNB configuration file, the network is now fixed, as lo interface always exists and our computer internal addresses also:

////////// MME parameters:
 mme_ip_address = ( { ipv4 = "127.0.0.20";
 ipv6 = "192:168:30::17";
 active = "yes";
 preference = "ipv4";
 }
 );

NETWORK_INTERFACES : 
 {
 ENB_INTERFACE_NAME_FOR_S1_MME = "lo";
 ENB_IPV4_ADDRESS_FOR_S1_MME = "127.0.0.10/8";

 ENB_INTERFACE_NAME_FOR_S1U = "lo";
 ENB_IPV4_ADDRESS_FOR_S1U = "127.0.0.10/8";
 ENB_PORT_FOR_S1U = 2152; # Spec 2152
 };

In the eNB config file, you need also to set the MCC and MNC as per your SIM card:

tracking_area_code = “1”;
mobile_country_code = “208”;
mobile_network_code = “92”;

And obviously, your radio parameters.

Wwe tested with USRP B210 20MHz band, Huawei E3272 UE, elephone P6000 (android 5), a cavity duplexer a simple antenna, about 1 meter distance UE/eNB antenna with this file: ~/opencells-mods/enb.10MHz.b200

derivated from: openairinterface5g/targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.100PRB.usrpb210.conf

Install this configuration for EPC

For the EPC, we install in OAI default directory: /usr/local/etc/oai

sudo mkdir -p /usr/local/etc/oai
sudo cp -rp ~/opencells-mods/config_epc/* /usr/local/etc/oai

cd openair-cn; source oaienv; cd scripts
./check_hss_s6a_certificate /usr/local/etc/oai/freeDiameter hss.OpenAir5G.Alliance
./check_mme_s6a_certificate /usr/local/etc/oai/freeDiameter mme.OpenAir5G.Alliance

Only the SGi output to internet need to be configured.
In /usr/local/etc/oai/spgw.conf,
your should set the Ethernet interface that is connected to Internet, and,
to tell to the PGW to implement NAPT for the UE traffic

 PGW_INTERFACE_NAME_FOR_SGI = "enp3s0"; 
 PGW_MASQUERADE_SGI = "yes";

For the SIM card, you’ll have more to do:

SIM MCC/MNC should be duplicated in a couple of files
- eNB: See above in eNB configuration chapter
- MME file: /usr/local/etc/oai/mme.conf to update

GUMMEI_LIST = ( MCC="208" ; MNC="92"; MME_GID="4" ; MME_CODE="1"; } );
TAI_LIST = ({MCC="208" ; MNC="92"; TAC = "1"; } );

- HSS
  - Configure the password for MySQL
    - in /usr/local/etc/oai/hss.conf, set password as the password you created during MySQL installation
  - A HSS database in text is in: ~/opencells-mods/opencells_db.sql
    - We don’t use phpmyadmin: we load the database from a ascii file
    - It is pre-configured with the
      - mme id
      - 10 users is network 208/92 (a French test network) are also created (don’t use 3GPP test network: 001/01: the mme fails when MCC starts by “0”)
    - Each time you import this db, it erases the entire database
      (example: you set mysql password to “linux”)

./hss_db_import 127.0.0.1 root linux oai_db ~/opencells-mods/opencells_db.sql

- - - We use to modify the db by updating this file with regular text editor,
      then we re-load the entire database,
      but, if you prefer, usage of http://localhost/phpmyadmin is fine
    - The important values to set are:
      - table pdn:
        
        all IMSI are listed, with the APN: these values are in UE/USIM
      - table users:
        
        all IMSI, key (Ki) and OPc must be the same in USIM card
        
        Sqn increments automatically when the UE authenticate in both USIM and HSS DB: it should be set as per USIM internal incrementation
  - SIM card update
    - Open cells UICC and card reader will be supported

Final test and verification

open 4 terminal windows

in each window

cd openair-cn; source oaienv; cd scripts; ./run_hss

cd openair-cn; source oaienv; cd scripts; ./run_mme

cd openair-cn; source oaienv; cd scripts; sudo -E ./run_spgw

sudo bash
cd openairinterface5g; source oaienv
./cmake_targets/lte_build_oai/build/lte-softmodem -O <your config file>

Connect the UE, it should attach to network and be able to reach internet through OAI network.

If the UE attaches, but you don’t have internet access, verify phone configuration: enable data in config->sim and verify the APN value

Issues related to CPU power

If you reach performance issues: USRP/UHD prints “LLLLL” or the process exits “problem with samples”, OVERFLOW, …

The first case is to verify the USRP dialogs over USB3 (not USB2): the process must report:

Found USRP B200
-- Detected Device: B200
-- Operating over USB 3.

For OAI source code, we wrote improvements and some hints for UE performance last year. The Linux/Ubuntu advises can be applied to the eNB:

https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/setup-for-real-time-performance

We may make later a post for eNB (OAI/eNB can reach much better performance than today develop branch, but it require to enhance parts of the source code).

We re-built this procedure from scratch and tested two machines: i5-4570 and i5-6600K.

On the i5-4570, at maximum traffic, the eNB is stable on 10MHz band at full user data speed.

On the i5-6600K, we obtained stable performance at maximum traffic over 20MHz, transmission mode 1 (SISO), one single UE over-the-air 1 meter distance (not re-tested since July version):

55 thoughts on “All in one OpenAirInterface, August 22nd”

wynter says:

August 25, 2017 at 2:51 am

Hi, Laurent,
I ran the eNB and EPC successfully. And my board is Limesdr, but I have also met some problem.
Build the lte-softmodem,like this:
./cmake_targets/build_oai -c -w LMSSDR –eNB –UE
run lte-softmodem:
sudo ./cmake_targets/lte_build_oai/build/lte-softmodem -O ./targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.50PRB.usrpb210.conf –rf-config-file ./targets/ARCH/LMSSDR/LimeSDR_above_1p8GHz_1v4.ini

But I can not get the tx signal when I checked the frequency of nearby neighborhoods by professional equipment. Can you help me out please?

Reply
1. laurent says:
  
  August 25, 2017 at 1:01 pm
  
  Hi,
  Maybe try first to follow our LimeSDR guide (see the dedicated post)
  We didn’t try LimeSDR for a while, I’ll run a test soon.
  Regards,
  Laurent
  
  Reply
2. Mohammad says:
  
  October 5, 2017 at 7:53 am
  
  Hi i had the same problem , i changed tx_gain to 100 in enb.band7.tm1.50PRB.lmssdr.conf file and now carrier is visible .
  
  But i can’t see base station in my phone , phone is nexus 5x and i know it support LTE band7 without problem .
  
  i even set mnc and mcc according to my sim card in enb.band7.tm1.50PRB.lmssdr.conf and mme.conf .
  
  Reply
reza says:

August 29, 2017 at 10:37 am

Hi Dear Laurent
Could you please help me regarding a problem that occures in the execution of lte-softmodem
That error is:

[MAC][I][eNB_dlsch_ulsch_scheduler] UE rnti 72c : in synch, PHR 36 dB CQI 15
[RRC][I]UE rnti 72c failure timer 0/20000
[PHY][I]rx_rf: rfdevice timing drift of -1 samples (ts_off 62698675)
[PHY][I]UE 0 : rnti 72c
[MAC][I][eNB_dlsch_ulsch_scheduler] UE rnti 72c : in synch, PHR 38 dB CQI 15
[RRC][I]UE rnti 72c failure timer 0/20000
[PHY][I]UE 0 : rnti 72c
[MAC][I][eNB_dlsch_ulsch_scheduler] UE rnti 72c : in synch, PHR 38 dB CQI 15
[RRC][I]UE rnti 72c failure timer 0/20000

Reply
1. laurent says:
  
  September 7, 2017 at 8:04 am
  
  Reza,
  There is no error in this: [I] trace is “information”
  It tells you the UE is attached, and no failure timer occured.
  the 0/20000 means that after 20000 errors, the eNB will abort the UE connexion
  Regards,
  Laurent
  
  Reply
Bakarime Diomande says:

August 29, 2017 at 2:39 pm

Hi Laurent!
Thank you for the detailed steps it worked fine, however I have tested a different setup, I considered epc on one machine (I have used the patch you have provided) and enb + oaisim on another machine(I run one enb and one user). As a result the enb could not connect to the epc’s mme leading to the ue not being able to attach to epc’s hss+mme. Do you have any suggestions?

Reply
1. laurent says:
  
  September 4, 2017 at 9:22 am
  
  Hello,
  We never work with OAISIM.
  We will publish a separte channel simulator that will work with regular OAI UE and OAI eNB,
  nevertheless, as it is free, we do it in “best effort” work.
  Regards,
  Laurent
  
  Reply
Dmitry Polpudenko says:

September 3, 2017 at 10:19 pm

Hi, Laurent

Could you please give a hint as to why after command

~/openairinterface5g$ git checkout develop

I get error message when trying to apply the patch?

git apply ../opencells-mods/eNB.patch
error: patch failed: cmake_targets/tools/build_helper:551
error: cmake_targets/tools/build_helper: patch does not apply

Reply
1. Dmitry Polpudenko says:
  
  September 4, 2017 at 5:07 am
  
  Actual commit is commit 1fb76157c838819587a4a5bd0c214fc100b7fbaf. ‘Though it says that it has merged the commit 17b9a9e917ce2a3a8c7004c7b9a221c350ddfe17 that you tested against, later build_oai -I for eNB fails with ‘oai doesn’t support ubuntu 17.04’ message.
  
  Reply
2. Dmitry Polpudenko says:
  
  September 5, 2017 at 11:43 am
  
  Below is git apply in verbose mode.
  
  ~/openairinterface5g$ git apply -v ../opencells-mods/eNB.patch
  Checking patch cmake_targets/tools/build_helper…
  error: while searching for:
  pydb \
  libyaml-dev \
  wget \
  libxpm-dev
  
  $SUDO update-alternatives –set liblapack.so /usr/lib/atlas-base/atlas/liblapack.so
  
  #Remove old gnutls/nettle installation that was done from sources
  remove_nettle_from_source
  
  $SUDO apt-get install -y nettle-dev nettle-bin
  remove_gnutls_from_source
  
  $SUDO apt-get install -y libgnutls-dev
  elif [[ “$OS_BASEDISTRO” == “fedora” ]]; then
  if [[ “$OS_DISTRO” == “rhel” ]] || [[ “$OS_DISTRO” == “centos” ]]; then
  if rpm -q epel-release > /dev/null; then
  
  error: patch failed: cmake_targets/tools/build_helper:551
  error: cmake_targets/tools/build_helper: patch does not apply
  
  Reply
  1. Dmitry Polpudenko says:
    
    September 5, 2017 at 1:47 pm
    
    I am not a linux nerd, but libgnutls-dev library is compatible with previous release of Ubuntu, 16.04. 17.04 utilizes libgnutls30 library only. Do you think it could be the reason for the patch to fail? If yes, how one can fix it?
    
    Reply
    1. Dmitry Polpudenko says:
      
      September 5, 2017 at 2:09 pm
      
      As per description of git apply error, the patch couldn’t find the line of code in question. It could have been added by earlier commits.
      
      Reply
      1. Dmitry Polpudenko says:
        
        September 5, 2017 at 6:08 pm
        
        Got tired of finding out where the diff between eNB.patch and build_helper comes from, so applied changes manually.
      2. laurent says:
        
        September 7, 2017 at 8:25 am
        
        Dmitry,
        Thanks to point out the latest develop git branch commit refuses to merge our patch.
        I’m a bit lost in your trials:
        – works fine with the version we tested
        => if you do git checkout 17b9a9e917ce2a3a8c7004c7b9a221c350ddfe17
        the patch works fine
        – for the latest commit, as you discovered, the command “git apply eNB.patch” fails
        => the merge fails for a small detail
        instead of git apply, replace the file we need to patch by our version:
        cp ../opencells-mods/cmake_targets/tools/build_helper cmake_targets/tools/build_helper
        
        I tested: the following compilation works, nevertheless someone will have to perform a full test with a UE.
        
        I’ll do a new patch version later (we’ll try to maintain this tutorial up to date with latest commits about once per month).
        
        Regards,
        Laurent
Ankita Kohli says:

September 6, 2017 at 10:18 am

Hi Laurent,
i am getting following error while executing ./run_spgw:
Initializing GTPV1U interface
Creating new listen socket on address 127.0.0.30 and port 2123
Inserting new descriptor for task 6, sd 31
Received 1 events
rmmod: ERROR: Module gtp is not currently loaded
ERROR in loading gtp kernel module (check if built in kernel)
Initializing GTPv1-U ERROR
Function sgw_init (&spgw_config) has failed
returning -1

i am using Ubuntu 17.04 (GNU/Linux 4.10.0-33-generic x86_64), i have applied the patches given above. could you please help me out here?

Regards,
Ankita

Reply
1. laurent says:
  
  September 7, 2017 at 8:01 am
  
  Ankita,
  I would guess you are not “root”.
  Only root can load kernel modules.
  Could you try: sudo ./run_spgw
  Laurent
  
  Reply
Dmitry Polpudenko says:

September 23, 2017 at 3:24 pm

Hi, Laurent,
I have succesfully compiled eNB+EPC, my RF board is limeSDR. No issues, your instructions are excellent, code is great, components of the system start smoothly, except eNB. I get LLLLL soon after the start of the eNb. My system is Ubuntu 17.04, CPU i5-3260, 4 cores (MacBook Pro 2013+Retina). Applying cpu improvement instructions make things even worse. So my question to you is should i opt for a more powerfull HW or there are code enhancement opportunities yet to be realized that will make the code run on a weaker system? Could moving mme+hss+spgw to a different machine help my cpu handle eNB processing load? I’d appreciate you giving a piece of advice.

Reply
1. laurent says:
  
  September 25, 2017 at 11:31 am
  
  Dmitry,
  
  About the CPU, i don’t find this reference, maybe it is a i5-3360M.
  Anyway, it is likely a 2 cores CPU + hyperthreading.
  You can verify with:
  grep -i core /proc/cpuinfo
  grep siblings /proc/cpuinfo
  
  If the cores have siblings, it means hyperthreading is running and you see two cores whereas only one exists (this is not two cores, but one core with two sets of registers).
  
  I saw many people on the mailing list complaining OAI doesn’t run well on such (even recent) 2 cores CPUs (Intel released even “i7” with two actual cores).
  
  Today, I don’t think OAI runs nicely (even 5MHz/SISO) on such 2 cores CPU, but it should (if we pay enough effort in optimization).
  The best you can do right now: isolate the second core in a shield (probably core 1 and 3 are siblings)
  Run the EPC out of the shielded core
  Run the softmodem in the shielded domain.
  
  I don’t think running the EPC on another machine will make it significantly better, but you can try.
  For this separate EPC, change the IPs in the all config files to use the Ethernet interface ones.
  (If it is not that simple, I’ll make a post on separate eNB/EPC configuration).
  
  In next months, we need is to improve the softmodem to run well with less CPU.
  Open cells implemented pieces of code, for that purpose.
  We didn’t release it because we wait a major update that will come soon in develop branch to merge our improvements.
  It is hard to estimate when we will release our work: there is overlap between the near future huge commit in develop branch and what we did.
  So, we expect a complex “merge” that will partially erase what we did.
  
  Furthermore, we have to deliver first the work we are paid for.
  This is also why we didn’t progress during August on our LimeSDR tests: we do such free open source in best effort mode.
  
  Regards,
  Laurent
  
  Reply
  1. Dmitry Polpudenko says:
    
    September 26, 2017 at 5:05 am
    
    Laurent,
    
    Thanks for replying. I double checked, my CPU is i5-3230M, 2 cores. Look forward to getting into cpu shielding.
    
    Reply
ldle says:

November 1, 2017 at 2:20 am

Hi Laurent,
Recently, my friends told me a way to solve the “LLLLL…” in eNB.
In system settings->software& updates->Additional Drivers ,we select “Do not use the device ” instead of “Using processor microcode …….”, restart the computer, then it works. that’s all, thank you.

Reply
1. laurent says:
  
  November 2, 2017 at 9:29 am
  
  Hello,
  This is a very important remark that need to be qualified better.
  This package is made by Intel, only Intel know what is in, but we know the purpose.
  The motherboard bios contains a version of Intel microcode (a microcode must be loaded in the CPU).
  The Debian/Ubuntu package runs a Intel code that updates this microcode if needed.
  
  So, you found at least a case where the updated microcode is worse than the one in the bios.
  
  Could you provide us with more information: CPU type, mother board reference and bios version where this situation occurs?
  
  thanks for this discovery
  Laurent
  
  Reply
ldle says:

November 8, 2017 at 2:58 am

Hello,
I’m sorry to reply you so late.
my computer is (DELL)3668-R2938/R1938
and CPU type is i7-7700
bios version 1.1.0
Before I change it, it prints out the “LLL…” every time when I run eNB.

thanks

Reply
1. laurent says:
  
  November 10, 2017 at 3:05 pm
  
  Hi,
  The source of microcode seems to be:
  https://downloadcenter.intel.com/download/26925/Linux-Processor-Microcode-Data-File
  in the tar file, the file releasenote explains how is done the root integration in Linux.
  
  Ubuntu/Debian seems to only repackage this from Intel delivery, believing they will put better version than the MB bios one.
  In your case it seems a mistake to perform this update.
  
  Linux boot trace gives us the microcode version:
  dmesg | grep microcode:
  
  If microcode update in enabled, the output has a line like:
  [ 0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
  
  In all cases, the microcode version is given like:
  [ 0.963620] microcode: sig=0x506e3, pf=0x2, revision=0xba
  
  Could you check the versions you have in each case?
  Regards,
  Laurent
  
  Reply
ldle says:

November 14, 2017 at 3:24 pm

Hi Laurent,
after I run “dmesg | grep microcode”,I got the output as follows;
[ 0.086702] mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1510484689 SOCKET 0 APIC 0 microcode 48
[ 0.086704] mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1510484689 SOCKET 0 APIC 0 microcode 48
[ 0.086707] mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1510484689 SOCKET 0 APIC 0 microcode 48
[ 0.086709] mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1510484689 SOCKET 0 APIC 0 microcode 48
[ 0.818583] microcode: sig=0x906e9, pf=0x2, revision=0x48
[ 0.818766] microcode: Microcode Update Driver: v2.2.
I don’t know what it means, could you figure it out for me, thank you.

ldle

Reply
1. laurent says:
  
  November 16, 2017 at 10:28 am
  
  Hi
  mce => machine check exception
  Means your machine have a HW fault (or the SW wrongly detects HW fault)
  there is package to obtain more details:
  apt install mcelog mcelog --client
  
  Do you have this log for both cases: with “microcode enabled” in ubuntu drivers?
  Regards,
  Laurent
  
  Reply
brieftime says:

December 12, 2017 at 4:53 am

Hi Laurent:
when i run “./cmake_targets/lte_build_oai/build/lte-softmodem -O “,the result is ok,but when i run “./cmake_targets/lte_build_oai/build/lte-softmodem -O -d”,it whill occure an error(core dump) like below:

[PHY][I]lte_parms.c: Setting N_RB_DL to 50, ofdm_symbol_size 1024
Scope thread has priority 2
Scope thread created, ret=0
Segmentation fault (core dumped)

I don’t know what it means, could you figure it out for me, thank you.

brieftime

Reply
1. brieftime says:
  
  December 12, 2017 at 4:55 am
  
  that means:I add a parameter “-d”,occure core dump
  
  Reply
  1. laurent says:
    
    December 12, 2017 at 3:41 pm
    
    Hello,
    I guess you use new develop (commit after October 23rd).
    In this version and all above major regressions exist(see the mail from Cédric “IMPORTANT NOTICE: new versions of master and develop branches” when this update has been done).
    If i’m right, please complain on OAI mailing list about all defects that appeared in this commit and after).
    Regards,
    Laurent
    
    Reply
Aram says:

December 12, 2017 at 12:53 pm

Hi Laurent
I’m running the program with configurations given in opencells-cells/enb.10MHz.b200 file on USRP B210.
when my phone found the 4G network I’ve got the following error messages:

[OSA][E]Mismatch found in integrity for algorithm 2,
got 8c.83.1c.b4, expecting 00.00.00.00
[PDCP][E][OSA][RB 1] eNB failed to validate MAC-I of incoming PDU
…
[S1AP][E][s1ap_eNB_task] Received unhandled message: 94:S1AP_INITIAL_CONTEXT_SETUP_FAIL
…
[PHY][E]ERROR: Format 1A: rb_alloc (7ff) > RIV_max (4fa)
…
[PHY][E][eNB 0] Frame 982: Unknown UE_id for rnti 7931

and after 10-20 seconds fails to Internet connection, but stay to show the 4G sign on my phone.
Thanks in advance.

Reply
1. laurent says:
  
  December 12, 2017 at 3:38 pm
  
  Hi,
  S1AP fails to create the link for an issue in the cyphering keys: what is your phone and what SIM card do you use?
  Laurent
  
  Reply
  1. Aram says:
    
    December 13, 2017 at 11:18 am
    
    Hi Laurent
    My phone is ZTE Axon 7 and I use Sysmocom sysmoUSIM-SJS1 simcard
    Thanks Aram
    
    Reply
    1. laurent says:
      
      December 13, 2017 at 1:40 pm
      
      Hi Aram,
      This is a problem of security keys: likely the phone is working well, maybe you didn’t program well the sysmoUSIM-SJS1 or the core network is not working.
      I would suspect the EPC: are you using OAI EPC?
      Regards,
      Laurent
      
      Reply
      1. Aram says:
        
        December 13, 2017 at 2:03 pm
        
        I used exactly the same way mentioned in Your artice above.
        
        I’ve added in the config file the following settings:
        srs_enable = “ENABLE”;
        srs_BandwidthConfig = 2;
        srs_SubframeConfig = 7;
        srs_ackNackST = “DISABLE”;
        srs_MaxUpPts = “DISABLE”;
        
        And felt a little bit advance in connection time, but gives the following errors and connection lost:
        [MAC][E][initiate_ra_proc] [eNB 0][RAPROC] FAILURE: CC_id 0 Frame 558 Initiating RA procedure for preamble index 52
        
        Regards,
        Aram.
      2. laurent says:
        
        December 14, 2017 at 12:09 pm
        
        Hi Aram,
        
        So, you use OAI eNB, OAI EPC and the HSS is loaded with the database from our tutorial.
        I don’t think it is a radio or low layer issue: it should be a authentication issue between the SIM and the HSS, then the derivated keys are wrong.
        
        In this case, I guess the SIM card is not well configured: set it to milenage (not XOR) algorithm.
        Please test the authentication (as in the Sysmocom manual).
        
        Regards,
        Laurent
James says:

December 13, 2017 at 10:38 am

Thank you for nice description!
Can I follow this procedure exactly on Ubuntu 16.04? will it cause any problems?

My OS is Ubuntu 16.04 LTS and kernel is 4.10.0-40-generic

Reply
1. laurent says:
  
  December 13, 2017 at 1:01 pm
  
  James,
  Yes, I saw reports from other users that made the same on recent flavor of 16.04 (you have the same if your kernel is 16.04).
  Laurent
  
  Reply
Aram says:

December 18, 2017 at 8:10 am

Hi Laurent
I’ve used the program “sysmo-usim-tool.sjs1.py” to test the authentication
and it prints the follows:

Reading Authentication parameters…
* Initalizing…
* Reading…
* Current algorithm setting:
2G: 3=COMP128v1
3G: 1=MILENAGE

so it seems that our algorithm is MILENAGE, but the issue still remains.
Regards,
Aram.

Reply
1. laurent says:
  
  December 18, 2017 at 10:20 am
  
  Aram,
  I don’t know.
  Maybe you can spend 10€ buying us a programmed SIM card, nevertheless I’m not 100% sure the issue is the SIM card.
  Regards,
  Laurent
  
  Reply
ubaid ahmad says:

December 19, 2017 at 9:24 am

Hi Laurent,

Thank you for such a detailed guide.
Everything worked fine.

In my setup I am using LimeSDR as eNB and for UE its Huawei E3276-s.
When I attach UE to eNB the MME crashes.

I am trying to follow your comment:
Fix a issue in mme that crash mme with some phones in the attach-request procedure (maybe Android 6 phones)
If you want to fix only this issue, pick files:
src/nas/emm/Attach.c
src/nas/ies/SupportedCodecList.c
in the hereafter tar file
The issue is: mme wrong decoding of smartphone codec list

Is there a file missing or do I need to replace the Attach.c ?

Regards,
Ubaid

Reply
1. laurent says:
  
  December 22, 2017 at 8:05 am
  
  Ubaid,
  E3276-s works fine with OAI, the issue is not this one.
  The most common reason is some parameters are not correct, so the MME reach one of it’s bugs.
  Could you try the same with a USRP ?
  Regards,
  Laurent
  
  Reply
  1. ubaid ahmad says:
    
    December 26, 2017 at 6:37 am
    
    Hi Laurent,
    
    I do not have a USRP unfortunately only LimeSDR.
    I also tried with a samsung s6 edge (android 7). I can ping from eNB to UE. The data rate is too low around 170Bytes/sec. When I use s6 edge the MME does not crash while the spw crashes.
    
    I see this on the terminal running spgw:
    000649 00189:566373 7F121DABB700 TRACE GTPv2- 2-c/nwgtpv2c-0.11/src/NwGtpv2c.c:1243 Leaving nwGtpv2cProcessUlpReq() (rc=0)
    000650 00189:566379 7F121E2BC700 DEBUG UDP /src/udp/udp_primitives_server.c:0088 Looking for task 6
    000651 00189:566382 7F121E2BC700 DEBUG UDP /src/udp/udp_primitives_server.c:0091 Found matching task desc
    000652 00189:566385 7F121E2BC700 DEBUG UDP /src/udp/udp_primitives_server.c:0309 [31] Sending message of size 18 to 127.0.0.20 and port 2123
    000653 00189:566403 7F121E2BC700 DEBUG UDP /src/udp/udp_primitives_server.c:0187 Received 1 events
    000654 00193:566382 7F121DABB700 DEBUG S11 aug/openair-cn/src/s11/s11_sgw.c:0212 Received event TIMER_HAS_EXPIRED for timer_id 0x7f121400a6d0 and arg 0x7f12140041c0
    000655 00193:566401 7F121DABB700 TRACE GTPv2- 2-c/nwgtpv2c-0.11/src/NwGtpv2c.c:1315 Entering nwGtpv2cProcessTimeout()
    000656 00193:566430 7F121DABB700 DEBUG GTPv2- nwgtpv2c-0.11/src/NwGtpv2cTrxn.c:0113 Duplicate request hold timer expired for transaction 0x0x7f1214000aa0
    000657 00193:566436 7F121DABB700 DEBUG GTPv2- /nwgtpv2c-0.11/src/NwGtpv2cMsg.c:0146 Purging message 7f1214000bb0!
    000658 00193:566441 7F121DABB700 DEBUG GTPv2- nwgtpv2c-0.11/src/NwGtpv2cTrxn.c:0328 Purging transaction 0x0x7f1214000aa0
    000659 00193:566446 7F121DABB700 TRACE GTPv2- 2-c/nwgtpv2c-0.11/src/NwGtpv2c.c:1367 Leaving nwGtpv2cProcessTimeout() (rc=0)
    
    Any help would be great.
    Can you kindly also suggest any changes I can make to MME?
    
    Regards,
    Ubaid
    
    Reply
    1. laurent says:
      
      December 26, 2017 at 9:04 am
      
      Hello,
      
      I tried a LimeSDR a few days ago: it succeeded to attach to the OAI network.
      Then, my lab have problems with RF signal quality (even with USRP), so I didn’t manage to get stable traffic.
      So, I got almost the same as you.
      
      I used OpenAir CN with our patches, our SIM, our duplexer, OAI eNB, 10MHz, band 7.
      
      My SPGW didn’t crash, nevertheless known issues exists when the UE re-attach.
      
      My assumption is the radio quality is not good, so the UE attach, reattach, …
      
      The OAI code contains numerous bugs, so to obtain stable traffic, for now, we need good radio conditions.
      
      I’ll try to make a good setup, in the next two weeks.
      
      Regards,
      Laurent
      
      Reply
Vladimir says:

December 26, 2017 at 1:58 pm

Hello Laurent,
I’m trying to get this config up and running on 16.04.3 machine. Succeeded to build everything by your instruction, now trying to run: hss and mme started up OK, but spgw complains (see log below). Seems that it’s missing gtp module, but at wich stage should it be built? Is it an external module? I checked build logs in openair-cn, all looks good, except for couple messages “Didn’t find any information element for message: S1ap-PrivateMessageIEs”. Start log follows (this goes right after big nw-gtpv2c copyright notice, no errors indicated until this point):

000134 00001:104316 7F1F8A69C700 DEBUG S11 enb/openair-cn/src/s11/s11_sgw.c:0244 Tx UDP_INIT IP addr 127.0.0.30
000135 00001:104324 7F1F8A69C700 DEBUG S11 enb/openair-cn/src/s11/s11_sgw.c:0301 Initializing S11 interface: DONE
000136 00001:104326 7F1F8A69C700 DEBUG SPGW-A nb/openair-cn/src/sgw/sgw_task.c:0148 Initializing SPGW-APP task interface
000137 00001:104328 7F1F8A69C700 DEBUG GTPv1- air-cn/src/gtpv1-u/gtpv1u_task.c:0096 Initializing GTPV1U interface
000138 00001:104331 7F1F86764700 DEBUG UDP /src/udp/udp_primitives_server.c:0126 Creating new listen socket on address 127.0.0.30 and port 2123
000139 00001:104639 7F1F86764700 DEBUG UDP /src/udp/udp_primitives_server.c:0171 Inserting new descriptor for task 6, sd 31
000140 00001:104660 7F1F86764700 DEBUG UDP /src/udp/udp_primitives_server.c:0187 Received 1 events
rmmod: ERROR: Module gtp is not currently loaded
modprobe: FATAL: Module gtp not found in directory /lib/modules/4.4.0-104-generic
000141 00001:107330 7F1F8A69C700 CRITI GTPv2- air-cn/src/gtpv1-u/gtpv1u_task.c:0105 ERROR in loading gtp kernel module (check if built in kernel)
000142 00001:107344 7F1F8A69C700 ALERT SPGW-A nb/openair-cn/src/sgw/sgw_task.c:0151 Initializing GTPv1-U ERROR
Function sgw_init (&spgw_config) has failed
returning -1

Reply
Vladimir says:

December 26, 2017 at 2:24 pm

Laurent,

Just found your note about gtp in previous version of this post. So, as far as I got it, the best way is update the kernel to 4.10, right?

Vladimir

Reply
1. laurent says:
  
  December 26, 2017 at 6:00 pm
  
  Vladimir,
  Yes, whatever flavor: ubuntu 16.04.3 or 17.04
  Regards,
  Laurent
  
  Reply
Akeem says:

December 27, 2017 at 12:26 pm

Hi Laurent,
Thanks for your painstaking efforts in providing excellent instruction for the implementation of All in one OpenAirInterface. I have made attempts to follow the steps in https://open-cells.com/index.php/2017/08/22/all-in-one-openairinterface-august-22nd/. The hss, mme and spgw were loaded with success, but I have issues with the eNB as the UE could not establish connection to the internet and reported thefollowing message when I issue the command “./cmake_targets/lte_build_oai/build/lte-softmodem -O enb.band7.tm1.50PRB.usrpb210.conf”:

[CONFIG] get parameters from libconfig /home/ranadmin/openairinterface5g/targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.50PRB.usrpb210.conf
.
.
.
Sending sync to all threads
got sync (ru_thread)
[CONFIG] calling config module end function…
[CONFIG] free 1 config parameter pointers
[CONFIG] free 12 config value pointers
TYPE TO TERMINATE
Entering ITTI signals handler
[PHY][I]Time in secs now: 37398604
[PHY][I]Time in secs last pps: 30657425
[PHY][I]RU 0 rf device ready
[PHY][I]RU 0 no asynch_south interface
[HW][I][SCHED][eNB] eNB_thread_prach_br started on CPU 2, sched_policy = SCHED_FIFO , priority = 99, CPU Affinity= CPU_0 CPU_1 CPU_2 CPU_3
[PHY][I]prach_I0 = 2.1 dB
[PHY][I]max_I0 42, min_I0 34
ULLLLLLLLLLLLLLLLLLLLLLLLLLLLLLULLLUULLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLULL[PHY][I]prach_I0 = 17.4 dB
[PHY][I]max_I0 44, min_I0 33

Is there any thing I missed out or did wrongly that is preventing the UE from having access to the internet? ..and how can I fix the “ULLLL…” issue?
Details are in the attached eNB log, also enclosed with this email are logs for hss, mme, spgw.
Please I need your to fix these problems
Thank you and happy new year in advance.

Best Regards.

Reply
Cihan Esen says:

April 24, 2018 at 11:28 am

Hi Laurent,

I wanna try OAI with lime SDR. In this post you mention that there would be a seperate post about a setup with Lime. Did you publish such post anywhere?

If not, are there any specific differences trying USRP and Lime with OAI?

regards,

Cihan

Reply
1. laurent says:
  
  April 24, 2018 at 2:04 pm
  
  Hi Cihan,
  The post was not visible because the menu was too short, it is on https://open-cells.com/index.php/2017/05/10/limesdr-installation/
  
  I didn’t try again for a while to use Lime, I will do but I don’t know when.
  
  It is very similar to USRP in term of SW interface, the main issue is to calibrate properly the RF.
  There was issues inside the LimeSDR driver, at least the Tx part have been fixed.
  For OAI part, you need to set the proper radio power values.
  
  Also, note the maximum output power is 10dB lower than USRP, so the range will be shorter.
  
  I’ll try to have a look in it on Friday with a R&S analyzer.
  Laurent
  
  Reply
Nate says:

May 14, 2018 at 1:47 pm

Hi,

Thank you for this excellent guide. I’m trying to follow this it using a BladeRF x40. My system is 64 bit Ubuntu 17.04 with Intel® Core™ i7-5500U Processor (4M Cache, 2.4GHz, Turbo Boost up to 3.0 GHz).

At the very end of the guide, when I try to launch the lte-softmodem, it hangs on “Waiting for eNB application to be ready.”

I’m using the bladerf file (https://gitlab.eurecom.fr/oai/openairinterface5g/blob/master/targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.bladerfx40.conf), with small edits suggested by the configuration file here (MNC = 92, downlink_frequency = 2630000000L, different mme_ip_address and NETWORK_INTERFACES). I also changed the one line in this tutorial to:

./cmake_targets/build_oai -w BLADERF –eNB –UE

The running MME output shows that there are no connected eNBs, and the dmesg output is below.

Before it hangs, there’s an error, which I’m not sure if it’s related.

[SCTP][I][sctp_eNB_read_from_socket] Received notification for sd 41, type 32769
[SCTP][I][sctp_eNB_read_from_socket] Client association changed: 4
[SCTP][I][sctp_eNB_flush_sockets] Found data for descriptor 41
[SCTP][I][sctp_eNB_read_from_socket] An error occured during read
*[SCTP][E][sctp_eNB_read_from_socket] sctp_recvmsg (fd 41, len -1 ): Connection refused:111*
[RRC][I][FRAME 00000][eNB][MOD 00][RNTI 0] Init…

Here is the dmesg output:
[ 2046.470992] usb 3-3: reset SuperSpeed USB device number 3 using xhci_hcd
[ 2046.491610] usb 3-3: LPM exit latency is zeroed, disabling LPM.
[ 2173.599956] gtp: GTP module unloaded
[ 2173.632364] gtp: GTP module loaded (pdp ctx size 80 bytes)
[ 2180.042042] perf: interrupt took too long (4066 > 4058), lowering kernel.perf_event_max_sample_rate to 49000
[ 2195.646291] usb 3-3: reset SuperSpeed USB device number 3 using xhci_hcd
[ 2195.666874] usb 3-3: LPM exit latency is zeroed, disabling LPM.

The full output of the lte-softmodem command is here: https://ufile.io/zlwwc – any pointers would be helpful. I know the processor only has 2 cores – is this the source of the problem?

Thank you,
Nate

Reply
1. laurent says:
  
  May 22, 2018 at 5:40 am
  
  Hi Nate,
  The problem is not the 2 cores.
  gtp unlaod/load and most of messages are ok.
  
  Maybe the origin of the issue is in the sctp: Connection refused:111
  I would suggest to recheck MME connection parameters.
  Regards,
  Laurent
  
  Reply
Summer says:

June 22, 2018 at 7:03 am

Hi Laurent,

It was a really nice instruction. In my case, I am using a bladeRFx40 as the eNB. And I can see the network in my phone which is a Huawei P9. But when I want to connect my phone to the mme, it fails all the time because the authentication request is rejected. I checked all the certificates that I had installed and I think the problema is not this. Do you know what is happening here? Thank you very much!

Reply
1. Summer says:
  
  June 22, 2018 at 9:46 am
  
  The following informations are from after the compilation of MME:
  001331 00334:528706 7F40DF0B2700 TRACE NAS-EM -cn/src/nas/emm/Authentication.c:0477 001332 00334:528729 7F40DF0B2700 WARNI NAS-EM -cn/src/nas/emm/Authentication.c:0487 001333 00334:528735 7F40DF0B2700 TRACE NAS-EM -cn/src/nas/emm/Authentication.c:0559 001334 00334:528738 7F40DF0B2700 INFO NAS-EM ir-cn/src/nas/emm/emm_data_ctx.c:0534 001335 00334:528741 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/LowerLayer.c:0352 001336 00334:528745 7F40DF0B2700 DEBUG NAS-EM nair-cn/src/nas/emm/LowerLayer.c:0398 001337 00334:528747 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/LowerLayer.c:0405 001338 00334:528754 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_sap.c:0110 001339 00334:528773 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0175 001340 00334:528778 7F40DF0B2700 INFO NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0181 001341 00334:528781 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0923 001342 00334:528783 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:1267 001343 00334:528785 7F40DF0B2700 INFO NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:1270 001344 00334:528788 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0734 001345 00334:528790 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0786 001346 00334:528795 7F40DF0B2700 TRACE NAS-EM ir-cn/src/nas/emm/sap/emm_send.c:0905 001347 00334:528798 7F40DF0B2700 INFO NAS-EM ir-cn/src/nas/emm/sap/emm_send.c:0908 001348 00334:528801 7F40DF0B2700 TRACE NAS-EM ir-cn/src/nas/emm/sap/emm_send.c:0935 001349 00334:528804 7F40DF0B2700 INFO NAS-EM ir-cn/src/nas/emm/emm_data_ctx.c:0534 001350 00334:528806 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0815 001351 00334:528828 7F40DF0B2700 TRACE NAS rc/nas/api/network/nas_message.c:0540 001352 00334:528831 7F40DF0B2700 TRACE NAS rc/nas/api/network/nas_message.c:0852 001353 00334:528835 7F40DF0B2700 TRACE NAS rc/nas/api/network/nas_message.c:0885 001354 00334:528838 7F40DF0B2700 TRACE NAS rc/nas/api/network/nas_message.c:0913 001355 00334:528842 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/msg/emm_msg.c:0271 001356 00334:528851 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/msg/emm_msg.c:0420 001357 00334:528856 7F40DF0B2700 TRACE NAS rc/nas/api/network/nas_message.c:0933 001358 00334:528859 7F40DF0B2700 TRACE NAS rc/nas/api/network/nas_message.c:0623 001359 00334:528862 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0851 001360 00334:528864 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:1353 001361 00334:528866 7F40DF0B2700 DEBUG NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0968 001362 00334:528880 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0973 001363 00334:528883 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_as.c:0243 001364 00334:528885 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_sap.c:0143 001365 00334:528917 7F40DF0B2700 INFO NAS-EM -cn/src/nas/emm/Authentication.c:0605 001366 00334:528920 7F40DF0B2700 TRACE NAS-EM -cn/src/nas/emm/Authentication.c:0609 001367 00334:528922 7F40DF0B2700 TRACE NAS-EM -cn/src/nas/emm/Authentication.c:0509 001368 00334:528934 7F40DC8AD700 TRACE MME-AP /src/mme_app/mme_app_transport.c:0057 001369 00334:528965 7F40DC8AD700 TRACE MME-AP /src/mme_app/mme_app_transport.c:0098 001370 00334:528975 7F40DD0AE700 TRACE S1AP c/s1ap/s1ap_mme_nas_procedures.c:0344 001371 00334:529004 7F40DD0AE700 NOTIC S1AP c/s1ap/s1ap_mme_nas_procedures.c:0399 001372 00334:529015 7F40DD0AE700 TRACE S1AP c/s1ap/s1ap_mme_nas_procedures.c:0409 001373 00334:529023 7F40DE8B1700 DEBUG SCTP rc/sctp/sctp_primitives_server.c:0277 001374 00334:529179 7F40DE8B1700 DEBUG SCTP rc/sctp/sctp_primitives_server.c:0288 001375 00337:030373 7F40BFFFF700 DEBUG SCTP rc/sctp/sctp_primitives_server.c:0476 001376 00337:030477 7F40DD0AE700 TRACE S1AP r-cn/src/s1ap/s1ap_mme_decoder.c:0050 001377 00337:030499 7F40DD0AE700 DEBUG S1AP /CMakeFiles/r10.5/s1ap_decoder.c:5574 001378 00337:030524 7F40DD0AE700 TRACE S1AP r-cn/src/s1ap/s1ap_mme_decoder.c:0144 001379 00337:030527 7F40DD0AE700 TRACE S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0645 001380 00337:030533 7F40DD0AE700 DEBUG S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0659 001381 00337:030536 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0414 001382 00337:030538 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0428 001383 00337:030540 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0469 001384 00337:030550 7F40DD0AE700 TRACE S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0716 001385 00337:030558 7F40DC8AD700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:1049 001386 00337:030564 7F40DC8AD700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:1102 001387 00337:030571 7F40DF0B2700 TRACE NAS-EM an/openair-cn/src/nas/nas_proc.c:0495 001388 00337:030574 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_sap.c:0110 001389 00337:030576 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_cn.c:0451 001390 00337:030577 7F40DF0B2700 INFO NAS-EM nair-cn/src/nas/emm/sap/emm_cn.c:0452 001391 00337:030580 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_cn.c:0201 001392 00337:030581 7F40DF0B2700 DEBUG NAS-EM nair-cn/src/nas/emm/sap/emm_cn.c:0202 001393 00337:030583 7F40DF0B2700 TRACE NAS-EM /openair-cn/src/nas/emm/Detach.c:0224 001394 00337:030585 7F40DF0B2700 INFO NAS-EM /openair-cn/src/nas/emm/Detach.c:0228 001396 00337:030593 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_sap.c:0110 001397 00337:030595 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_reg.c:0106 001398 00337:030597 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_fsm.c:0256 001399 00337:030599 7F40DF0B2700 INFO NAS-EM air-cn/src/nas/emm/sap/emm_fsm.c:0263 001400 00337:030602 7F40DF0B2700 TRACE NAS-EM ap/EmmCommonProcedureInitiated.c:0090 001401 00337:030605 7F40DF0B2700 ERROR NAS-EM ap/EmmCommonProcedureInitiated.c:0192 001402 00337:030608 7F40DF0B2700 TRACE NAS-EM ap/EmmCommonProcedureInitiated.c:0196 001403 00337:030611 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_fsm.c:0271 001404 00337:030613 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_reg.c:0119 001405 00337:030614 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_sap.c:0143 001406 00337:030616 7F40DF0B2700 TRACE NAS -cn/src/nas/nas_itti_messaging.c:0442 001407 00337:030621 7F40DF0B2700 TRACE NAS -cn/src/nas/nas_itti_messaging.c:0460 001408 00337:030623 7F40DF0B2700 INFO NAS-EM ir-cn/src/nas/emm/emm_data_ctx.c:0807 001409 00337:030632 7F40DF0B2700 TRACE NAS-ES air-cn/src/nas/esm/sap/esm_sap.c:0158 001410 00337:030634 7F40DF0B2700 INFO NAS-ES air-cn/src/nas/esm/sap/esm_sap.c:0168 001411 00337:030637 7F40DF0B2700 TRACE NAS-ES m/EpsBearerContextDeactivation.c:0139 001412 00337:030639 7F40DF0B2700 INFO NAS-ES m/EpsBearerContextDeactivation.c:0144 001413 00337:030642 7F40DF0B2700 TRACE NAS-ES m/EpsBearerContextDeactivation.c:0145 001414 00337:030645 7F40DF0B2700 TRACE NAS-ES air-cn/src/nas/esm/sap/esm_sap.c:0273 001415 00337:030648 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_fsm.c:0176 001416 00337:030650 7F40DF0B2700 INFO NAS-EM air-cn/src/nas/emm/sap/emm_fsm.c:0182 001417 00337:030654 7F40DF0B2700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:1014 001418 00337:030656 7F40DF0B2700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:1033 001419 00337:030658 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_fsm.c:0194 001420 00337:030660 7F40DF0B2700 DEBUG NAS-EM ir-cn/src/nas/emm/emm_data_ctx.c:0603 001421 00337:030662 7F40DF0B2700 DEBUG NAS-EM ir-cn/src/nas/emm/emm_data_ctx.c:0622 001422 00337:030664 7F40DF0B2700 DEBUG NAS-EM ir-cn/src/nas/emm/emm_data_ctx.c:0194 001423 00337:030667 7F40DF0B2700 TRACE NAS-EM /openair-cn/src/nas/emm/Detach.c:0291 001424 00337:030668 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_cn.c:0205 001425 00337:030670 7F40DF0B2700 TRACE NAS-EM nair-cn/src/nas/emm/sap/emm_cn.c:0494 001426 00337:030672 7F40DF0B2700 TRACE NAS-EM air-cn/src/nas/emm/sap/emm_sap.c:0143 001427 00337:030674 7F40DF0B2700 TRACE NAS-EM an/openair-cn/src/nas/nas_proc.c:0499 001428 00337:030682 7F40DC8AD700 TRACE MME-AP mme_app/mme_app_itti_messaging.h:0042 001429 00337:030684 7F40DC8AD700 TRACE MME-AP -cn/src/mme_app/mme_app_detach.c:0127 001430 00337:030688 7F40DD0AE700 TRACE S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0811 001431 00337:030691 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0414 001432 00337:030693 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0428 001433 00337:030695 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0469 001434 00337:030697 7F40DD0AE700 TRACE S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0743 001435 00337:030734 7F40DD0AE700 DEBUG S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0796 001436 00337:030736 7F40DD0AE700 TRACE S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0798 001437 00337:030738 7F40DD0AE700 TRACE S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0831 001438 00337:030746 7F40DE8B1700 DEBUG SCTP rc/sctp/sctp_primitives_server.c:0277 001439 00337:030920 7F40DE8B1700 DEBUG SCTP rc/sctp/sctp_primitives_server.c:0288 001440 00337:045581 7F40BFFFF700 DEBUG SCTP rc/sctp/sctp_primitives_server.c:0476 001441 00337:045639 7F40DD0AE700 DEBUG S1AP /CMakeFiles/r10.5/s1ap_decoder.c:3702 001442 00337:045661 7F40DD0AE700 TRACE S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0845 001443 00337:045670 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0414 001444 00337:045673 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0428 001445 00337:045676 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0469 001446 00337:045694 7F40DD0AE700 TRACE S1AP n/openair-cn/src/s1ap/s1ap_mme.c:0595 001447 00337:045698 7F40DD0AE700 DEBUG S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0876 001448 00337:045701 7F40DD0AE700 TRACE S1AP -cn/src/s1ap/s1ap_mme_handlers.c:0877 001449 00337:045709 7F40DC8AD700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:0972 001450 00337:045713 7F40DC8AD700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:0662 001451 00337:045715 7F40DC8AD700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:0667 001452 00337:045718 7F40DC8AD700 DEBUG MME-AP cn/src/mme_app/mme_app_context.c:0988 001453 00337:045721 7F40DC8AD700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:0677 001454 00337:045726 7F40DC8AD700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:0721 001455 00337:045729 7F40DC8AD700 TRACE MME-AP cn/src/mme_app/mme_app_context.c:1003 Entering _authentication_t3460_handler()
  EMM-PROC – T3460 timer expired, retransmission counter = 3
  Entering _authentication_request()
  EMM-CTX – get UE id 0x00000002 context 0x7f40d4000b10
  Entering emm_as_set_security_data()
  NO Valid Security Context Available
  Leaving emm_as_set_security_data()
  Entering emm_sap_send()
  Entering emm_as_send()
  EMMAS-SAP – Received primitive EMMAS_SECURITY_REQ (201)
  Entering _emm_as_send()
  Entering _emm_as_security_req()
  EMMAS-SAP – Send AS security request
  Entering _emm_as_set_header()
  Leaving _emm_as_set_header() (rc=139916596680880)
  Entering emm_send_authentication_request()
  EMMAS-SAP – Send Authentication Request message
  Leaving emm_send_authentication_request() (rc=36)
  EMM-CTX – get UE id 0x00000002 context 0x7f40d4000b10
  Entering _emm_as_encode()
  Entering nas_message_encode()
  Entering _nas_message_header_encode()
  Leaving _nas_message_header_encode() (rc=1)
  Entering _nas_message_plain_encode()
  Entering emm_msg_encode()
  Leaving emm_msg_encode() (rc=36)
  Leaving _nas_message_plain_encode() (rc=36)
  Leaving nas_message_encode() (rc=36)
  Leaving _emm_as_encode() (rc=36)
  Leaving _emm_as_security_req() (rc=263)
  EMMAS-SAP – Sending msg with id 0x107, primitive EMMAS_SECURITY_REQ (201) to S1AP layer for transmission
  Leaving _emm_as_send() (rc=0)
  Leaving emm_as_send() (rc=0)
  Leaving emm_sap_send() (rc=0)
  EMM-PROC – Timer T3460 (1) expires in 6 seconds
  Leaving _authentication_request() (rc=0)
  Leaving _authentication_t3460_handler() (rc=0)
  Entering mme_app_handle_nas_dl_req()
  Leaving mme_app_handle_nas_dl_req() (rc=0)
  Entering s1ap_generate_downlink_nas_transport()
  Send S1AP DOWNLINK_NAS_TRANSPORT message ue_id = 0x00000002 MME_UE_S1AP_ID = 0x00000002 eNB_UE_S1AP_ID = 0x6FE0DC
  Leaving s1ap_generate_downlink_nas_transport() (rc=0)
  [40][91] Sending buffer 0x7f40c40081c0 of 62 bytes on stream 1 with ppid 18
  Successfully sent 62 bytes on stream 1
  [91][40] Msg of length 27 received from port 36412, on stream 1, PPID 18
  Entering s1ap_mme_decode_initiating()
  Decoding message S1ap_UEContextReleaseRequestIEs (/home/ikerlan/openair-cn/build/mme/build/CMakeFiles/r10.5/s1ap_decoder.c:5574)
  Leaving s1ap_mme_decode_initiating() (rc=0)
  Entering s1ap_mme_handle_ue_context_release_request()
  UE CONTEXT RELEASE REQUEST with Cause_Type = Radio Network and Cause_Value = 21
  Found ue_ref 0x7f40c4007c20 mme_ue_s1ap_id 0x00000002
  Found ue_ref 0x7f40c4007c20 mme_ue_s1ap_id 0x00000002
  Return ue_ref 0x7f40c4007c20
  Leaving s1ap_mme_handle_ue_context_release_request() (rc=0)
  Entering _mme_app_handle_s1ap_ue_context_release()
  Leaving _mme_app_handle_s1ap_ue_context_release()
  Entering nas_proc_implicit_detach_ue_ind()
  Entering emm_sap_send()
  Entering emm_cn_send()
  EMMCN-SAP – Received primitive EMMCN_IMPLICIT_DETACH_UE (406)
  Entering _emm_cn_implicit_detach_ue()
  EMM-PROC Implicit Detach UE0x00000002
  Entering emm_proc_detach_request()
  EMM-PROC – Detach type = EPS (0) requested (ue_id=0x00000002)001395 00337:030588 7F40DF0B2700 INFO NAS-EM ir-cn/src/nas/emm/emm_data_ctx.c:0534 EMM-CTX – get UE id 0x00000002 context 0x7f40d4000b10
  Entering emm_sap_send()
  Entering emm_reg_send()
  Entering emm_fsm_process()
  EMM-FSM – Received event DETACH_REQ (8) in state COMMON-PROCEDURE-INITIATED
  Entering EmmCommonProcedureInitiated()
  EMM-FSM – Primitive is not valid (8)
  Leaving EmmCommonProcedureInitiated() (rc=-1)
  Leaving emm_fsm_process() (rc=-1)
  Leaving emm_reg_send() (rc=-1)
  Leaving emm_sap_send() (rc=-1)
  Entering nas_itti_detach_req()
  Leaving nas_itti_detach_req()
  EMM-PROC – Stop timer T3460 (1)
  Entering esm_sap_send()
  ESM-SAP – Received primitive ESM_EPS_BEARER_CONTEXT_DEACTIVATE_REQ (10)
  Entering esm_proc_eps_bearer_context_deactivate()
  ESM-PROC – EPS bearer context deactivation: No Valid context
  Leaving esm_proc_eps_bearer_context_deactivate() (rc=0)
  Leaving esm_sap_send() (rc=0)
  Entering emm_fsm_set_status()
  UE 0x00000002 EMM-FSM – Status changed: COMMON-PROCEDURE-INITIATED ===> DEREGISTERED
  Entering mme_ue_context_update_ue_emm_state()
  Leaving mme_ue_context_update_ue_emm_state()
  Leaving emm_fsm_set_status() (rc=0)
  EMM-CTX – Remove in context 0x7f40d4000b10 UE id 0x00000002
  EMM-CTX – Remove in ctx_coll_imsi context 0x7f40d4000b10 UE id 0xD4000B10 imsi 901700000023531
  ue_id=0x00000002 cleared IMSI
  Leaving emm_proc_detach_request() (rc=0)
  Leaving _emm_cn_implicit_detach_ue() (rc=0)
  Leaving emm_cn_send() (rc=0)
  Leaving emm_sap_send() (rc=0)
  Leaving nas_proc_implicit_detach_ue_ind() (rc=0)
  Leaving mme_app_itti_ue_context_release()
  Leaving mme_app_handle_detach_req()
  Entering s1ap_handle_ue_context_release_command()
  Found ue_ref 0x7f40c4007c20 mme_ue_s1ap_id 0x00000002
  Found ue_ref 0x7f40c4007c20 mme_ue_s1ap_id 0x00000002
  Return ue_ref 0x7f40c4007c20
  Entering s1ap_mme_generate_ue_context_release_command()
  Started S1AP UE context release timer for UE id 2
  Leaving s1ap_mme_generate_ue_context_release_command() (rc=0)
  Leaving s1ap_handle_ue_context_release_command() (rc=0)
  [40][91] Sending buffer 0x7f40c4003aa0 of 23 bytes on stream 1 with ppid 18
  Successfully sent 23 bytes on stream 1
  [91][40] Msg of length 21 received from port 36412, on stream 1, PPID 18
  Decoding message S1ap_UEContextReleaseCompleteIEs (/home/ikerlan/openair-cn/build/mme/build/CMakeFiles/r10.5/s1ap_decoder.c:3702)
  Entering s1ap_mme_handle_ue_context_release_complete()
  Found ue_ref 0x7f40c4007c20 mme_ue_s1ap_id 0x00000002
  Found ue_ref 0x7f40c4007c20 mme_ue_s1ap_id 0x00000002
  Return ue_ref 0x7f40c4007c20
  Removing UE enb_ue_s1ap_id: 0x6FE0DC mme_ue_s1ap_id:0x00000002 in eNB id : 3584
  Removed UE 0x00000002
  Leaving s1ap_mme_handle_ue_context_release_complete() (rc=0)
  Entering mme_app_handle_s1ap_ue_context_release_complete()
  Entering mme_notify_ue_context_released()
  Leaving mme_notify_ue_context_released()
  Deleting UE context associated in MME for mme_ue_s1ap_id 0x00000002
  Entering mme_remove_ue_context()
  Leaving mme_remove_ue_context()
  Leaving mme_app_handle_s1ap_ue_context_release_complete()
  
  Reply
Alexandra says:

July 5, 2018 at 12:11 pm

Hello,

I used a bladeRF instead of a USPR, for now, I can register in my network, the problem appears when I want to stablish internet connection using my phone, it is not stable, the internet works rarely. In the logs of eNB, I can see the following errors:

[MAC][E][schedule_ulsch] scheduled retransmission in forbidden RBs
[DEBUG @”/build/bladerf-zjSF8E/…./libusb.c”:1339]Non-blocking buffer submission requested, but no transfers are currently available.

I don’t know if the failure of the internet is due to these errors o not.

Thanks
Alexandra

Reply
Alexandre Ferreira says:

July 6, 2018 at 12:59 pm

Hi,

I started facing some problems to have the eNB connected to the MME after an Ubuntu update. The following log is the log after the starting procedure of eNB:
…
[MAC][E][rrc_mac_config_req_eNB] RC.mac:0x7fef08002080 mib:0x7fef08003108
…
[SCTP][E]sctp_recvmsg (fd 41, len -1 ): Connection refused:111
…
[PHY][E]config_mib() dl_BandwidthP:3
…
[MAC][E][rrc_mac_config_req_eNB] rrc_mac_config_req_eNB() /home/lcrr-032553/openairinterface5g/openair2/LAYER2/MAC/config.c:967 RC.mac[Mod_idP]->if_inst->PHY_config_req:0x56048265e570
…
[PHY][E]***DJP*** removed assert on preamble fp->prach_emtc_config_common.prach_ConfigInfo.prach_numRepetitionPerPreambleAttempt[0]:0 expecting >0 /home/lcrr-032553/openairinterface5g/openair1/PHY/INIT/lte_init.c:259
…
[PHY][E]DJP – delete code above this /home/lcrr-032553/openairinterface5g/targets/RT/USER/lte-ru.c:2399
…
[PHY][E][INIT] phy_init_RU() RC.nb_L1_inst:1
…

Can you help me, please?

Regards,
Alexandre

Reply
1. laurent says:
  
  July 9, 2018 at 3:42 pm
  
  Dear Alexandre,
  
  The line sctp_recvmsg (fd 41, len -1 ): Connection refused:111 indicates the eNB can’t connect to the mme.
  One possibility is the diameter certificate expired: renew it with
  
  cd openair-cn; source oaienv; cd scripts ./check_hss_s6a_certificate /usr/local/etc/oai/freeDiameter hss.OpenAir5G.Alliance ./check_mme_s6a_certificate /usr/local/etc/oai/freeDiameter mme.OpenAir5G.Alliance
  
  I guess you have more explanation in the mme log.
  
  Please try and report to continue this diagnosis
  Laurent
  
  Reply