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

  1. 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):

 

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

  1. 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?

    1. 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 .

  2. 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

    1. 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

  3. 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?

    1. 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

  4. 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

    1. 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.

    2. 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

      1. 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?

        1. 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.

          1. Got tired of finding out where the diff between eNB.patch and build_helper comes from, so applied changes manually.

          2. 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

  5. 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

  6. 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.

    1. 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

      1. Laurent,

        Thanks for replying. I double checked, my CPU is i5-3230M, 2 cores. Look forward to getting into cpu shielding.

  7. 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.

    1. 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

  8. 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

    1. 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

  9. 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

    1. 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

  10. 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

      1. 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

  11. 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.

        1. 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

          1. 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. 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

  12. 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

  13. 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.

  14. 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

    1. 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

      1. 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

        1. 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

  15. 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

  16. 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

  17. 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.

  18. 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

    1. 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

  19. 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

    1. 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

      1. Hello,

        I got the same error message and it works after carefully recheck the IP addresses in “openairinterface5g/targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.100PRB.usrpb210.conf” following this guide.

        Nghia Nguyen.

  20. 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!

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

  21. 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

  22. 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

    1. 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

      1. Hi,

        I got the same problem with Alexandre, and I didn’t find the solution.
        Could you please offer a link to the solution? Lots of thanks.

        Regards,
        Candice

        1. Hi,

          So, the new problem it started somewhere after kernel revision 4.15.23 (ubuntu 18.04 update now installs a more recent kernel).

          This recent kernel refuses SCTP connect from eNB even if the MME is running.
          Forcing IPv4 (so replace AF_INET6 by AF_INET) in mme source: src/sctp/sctp_primitives_server.c:352 seems ok.

          The root error is still to be found: OAI IPv6 implementation contains bugs, maybe the kernel refuses for good reasons.

          Regards,
          Laurent

          1. Hi,

            Thanks for your reply. But I’m still confused. What exactly should I do to fix this problem?
            Should I change my kernel version? Please give me some specific suggestions.

            Regards,
            Candice

  23. Hi, Laurent,

    By following the tutorial above, but still we have this kind of error (as also reported by someone else earlier):
    “`
    [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…
    “`
    And as you have replied earlier:
    “`
    Maybe the origin of the issue is in the sctp: Connection refused:111
    I would suggest to recheck MME connection parameters.
    Regards,
    Laurent
    “`
    And, yes, we do observed “SCTP abort!” message from the communication between EPC and eNB.
    Could you specify more clearly how I should configure MME? (we have already followed the tutorial above…)

    Sorry for bothering.

    1. Hi,
      So, maybe you use Ubuntu 18.04 up-to-date.
      In this case, something is wrong either in the kernel or in OAI, see above the fix to set in the mme code.
      Regards,
      Laurent

Leave a Reply

Your email address will not be published. Required fields are marked *