[srslte-users] enb falling apart for n_prb>50

Fri Mar 26 14:07:50 UTC 2021

Thanks, I will look into it.

Now, I am facing another issue, and this even with low n_prb and with CPU
consumption staying reasonable (but pushing the transfer to its maximum, I
guess, since I am using iperf3)...

The one below is the stdout... all ends up hanging with this message
GTPC_MSG_TYPE_DOWNLINK_DATA_NOTIFICATION_FAILURE_INDICATION which repeats
over and over and over again...
I did a fair amount of research, but did not find an answer to the
meaning...

Thanks for any help you might give me.

Built in Release mode using commit ff84d7779 on branch fixing_enb_20_10.

---  Software Radio Systems EPC  ---

Reading configuration file /home/bts/.config/srslte/epc.conf...
HSS Initialized.
MME S11 Initialized
MME GTP-C Initialized
MME Initialized. MCC: 0xf001, MNC: 0xff01
SPGW GTP-U Initialized.
SPGW S11 Initialized.
SP-GW Initialized.
Received S1 Setup Request.
S1 Setup Request - eNB Name: srsenb01, eNB id: 0x19b
S1 Setup Request - MCC:001, MNC:01
S1 Setup Request - TAC 7, B-PLMN 0xf110
S1 Setup Request - Paging DRX v128
Sending S1 Setup Response
Initial UE message: LIBLTE_MME_MSG_TYPE_ATTACH_REQUEST
Received Initial UE message -- Attach Request
Attach request -- IMSI: 901700000044980
Attach request -- eNB-UE S1AP Id: 1
Attach request -- Attach type: 2
Attach Request -- UE Network Capabilities EEA: 11100000
Attach Request -- UE Network Capabilities EIA: 11100000
Attach Request -- MS Network Capabilities Present: true
PDN Connectivity Request -- EPS Bearer Identity requested: 0
PDN Connectivity Request -- Procedure Transaction Id: 1
PDN Connectivity Request -- ESM Information Transfer requested: true
Downlink NAS: Sending Authentication Request
UL NAS: Received Authentication Response
Authentication Response -- IMSI 901700000044980
UE Authentication Accepted.
Generating KeNB with UL NAS COUNT: 0
Downlink NAS: Sending NAS Security Mode Command.
UL NAS: Received Security Mode Complete
Security Mode Command Complete -- IMSI: 901700000044980
Sending ESM information request
UL NAS: Received ESM Information Response
ESM Info: APN srsapn
ESM Info: 2 Protocol Configuration Options
Getting subscription information -- QCI 7
Sending Create Session Request.
Creating Session Response -- IMSI: 901700000044980
Creating Session Response -- MME control TEID: 1
Received GTP-C PDU. Message type: GTPC_MSG_TYPE_CREATE_SESSION_REQUEST
SPGW: Allocated Ctrl TEID 1
SPGW: Allocated User TEID 1
SPGW: Allocate UE IP 172.16.0.3
Received Create Session Response
Create Session Response -- SPGW control TEID 1
Create Session Response -- SPGW S1-U Address: 127.0.1.100
SPGW Allocated IP 172.16.0.3 to IMSI 901700000044980
Adding attach accept to Initial Context Setup Request
Sent Initial Context Setup Request. E-RAB id 5
Received Initial Context Setup Response
E-RAB Context Setup. E-RAB id 5
E-RAB Context -- eNB TEID 0x1; eNB GTP-U Address 127.0.1.1
UL NAS: Received Attach Complete
Unpacked Attached Complete Message. IMSI 901700000044980
Unpacked Activate Default EPS Bearer message. EPS Bearer id 5
Received GTP-C PDU. Message type: GTPC_MSG_TYPE_MODIFY_BEARER_REQUEST
Sending EMM Information
Initial UE message: NAS Message Type Unknown
Received Initial UE message -- Service Request
Service request -- S-TMSI 0x1d5630e7
Service request -- eNB UE S1AP Id 2
Service Request -- Short MAC valid
There are active E-RABs, send release access bearers request
Received GTP-C PDU. Message type:
GTPC_MSG_TYPE_RELEASE_ACCESS_BEARERS_REQUEST
Service Request -- User is ECM DISCONNECTED
UE previously assigned IP: 172.16.0.3
Generating KeNB with UL NAS COUNT: 3
UE Ctr TEID 0
Sent Initial Context Setup Request. E-RAB id 5
Received UE Context Release Complete. MME-UE S1AP Id 1
No UE context to release found. MME-UE S1AP Id: 1
Received Initial Context Setup Response
E-RAB Context Setup. E-RAB id 5
E-RAB Context -- eNB TEID 0x2; eNB GTP-U Address 127.0.1.1
Initial Context Setup Response triggered from Service Request.
Sending Modify Bearer Request.
Received GTP-C PDU. Message type: GTPC_MSG_TYPE_MODIFY_BEARER_REQUEST
Initial UE message: LIBLTE_MME_MSG_TYPE_TRACKING_AREA_UPDATE_REQUEST
Received Initial UE message -- Tracking Area Update Request
Tracking Area Update Request -- S-TMSI 0x1d5630e7
Tracking Area Update Request -- eNB UE S1AP Id 3
Warning: Tracking area update requests are not handled yet.
Received UE Context Release Request. MME-UE S1AP Id 2
There are active E-RABs, send release access bearers request
Received GTP-C PDU. Message type:
GTPC_MSG_TYPE_RELEASE_ACCESS_BEARERS_REQUEST
Received UE Context Release Complete. MME-UE S1AP Id 2
UE Context Release Completed.
Found UE for Downlink Notification
MME Ctr TEID 0x1, IMSI: 901700000044980
Received UE Context Release Request. MME-UE S1AP Id 3
No UE context to release found. MME-UE S1AP Id: 3
T3413 expired -- Could not page the ue.
Received GTP-C PDU. Message type:
GTPC_MSG_TYPE_DOWNLINK_DATA_NOTIFICATION_FAILURE_INDICATION
Found UE for Downlink Notification
MME Ctr TEID 0x1, IMSI: 901700000044980
T3413 expired -- Could not page the ue.
Received GTP-C PDU. Message type:
GTPC_MSG_TYPE_DOWNLINK_DATA_NOTIFICATION_FAILURE_INDICATION
Found UE for Downlink Notification
MME Ctr TEID 0x1, IMSI: 901700000044980

On Fri, 26 Mar 2021 at 04:58, J Giovatto <jgiovatto at adjacentlink.com> wrote:

> OK,
>
> I have not already looked into it kachegrind can help pinpoint the "big
> hitters".
>
> http://kcachegrind.sourceforge.net/html/Home.html
>
> Joe
>
>
> On 3/25/21 4:42 PM, Andrea Valori wrote:
>
> Joe,
> Many thanks!
> Indeed, the CPU is suffering bad time... it saturates just after starting
> to stream data, but very soon after the connection drops (and therefore the
> CPU goes back to low usage). I did try to check the CPU beforehand, but
> probably I was missing the "spike" and therefore did not consider it as a
> culprit...
>
> Thanks for making me check more thoroughly.
>
> Andrea
>
>
>
> On Thu, 25 Mar 2021 at 16:00, J Giovatto <jgiovatto at adjacentlink.com>
> wrote:
>
>> First off I'd check the cpu utilization at the different rates, the
>> higher rates can be very demanding.
>>
>> Joe
>>
>>
>> On 3/25/21 10:36 AM, Andrea Valori wrote:
>>
>> Dear All,
>>
>> I was trying to monitor the performances of the enb varying the n_prb
>> parameter.
>> In theory, for my understanding, the bandwidth and transfer should go UP
>> increasing n_prb. This is what I see up to n_prb=50, but with 75 or 100 I
>> am struggling to attach the UEs and they drop the connection very quickly
>> making it impossible to conclude an iperf test...
>>
>> What can it be in your opinion? Tx/Rx interference? PC and/or SDR board
>> performance?
>>
>> Something that I noticed is a weird sequence in the stout (see below):
>> For n_prb<=50 the " ==== eNodeB started === " message is at the end of all
>> the messages (after actual clock rate and setting frequency).
>> For the n_prb=75 (and same for 100) these messages are inverted and seem
>> that the eNodeB is started before setting the frequency?
>> Could this be a hint of wrong timings somewhere?
>>
>> Cheers
>>
>> ---------------------------------------------------------------------------------------------------------
>>
>> bts at bts-ThinkPad-L460:~$ sudo srsenb --enb.n_prb 50
>>
>> [sudo] password for bts:
>>
>> ---  Software Radio Systems LTE eNodeB  ---
>>
>>
>>
>> Reading configuration file /home/bts/.config/srslte/enb.conf...
>>
>>
>>
>> Built in Release mode using commit ff84d7779 on branch fixing_enb_20_10.
>>
>>
>>
>> /home/bts/srsLTE/srsenb/src/enb_cfg_parser.cc.890: Force DL EARFCN for
>> cell PCI=1 to 2525
>>
>>
>>
>> Opening 1 channels in RF device=default with args=default
>>
>> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501;
>> UHD_3.15.0.0-62-g7a3f1516
>>
>> [INFO] [LOGGING] Fastpath logging disabled at runtime.
>>
>> Opening USRP channels=1, args: type=b200,master_clock_rate=23.04e6
>>
>> [INFO] [B200] Detected Device: B200
>>
>> [INFO] [B200] Operating over USB 3.
>>
>> [INFO] [B200] Initialize CODEC control...
>>
>> [INFO] [B200] Initialize Radio control...
>>
>> [INFO] [B200] Performing register loopback test...
>>
>> [INFO] [B200] Register loopback test passed
>>
>> [INFO] [B200] Asking for clock rate 23.040000 MHz...
>>
>> [INFO] [B200] Actually got clock rate 23.040000 MHz.
>>
>> Setting frequency: DL=881.5 Mhz, UL=836.5 MHz for cc_idx=0
>>
>>
>>
>> ==== eNodeB started ===
>>
>> Type <t> to view trace
>>
>> q
>>
>> Stopping ..
>>
>> ---  exiting  ---
>>
>> bts at bts-ThinkPad-L460:~$ sudo srsenb --enb.n_prb 75
>>
>> ---  Software Radio Systems LTE eNodeB  ---
>>
>>
>>
>> Reading configuration file /home/bts/.config/srslte/enb.conf...
>>
>>
>>
>> Built in Release mode using commit ff84d7779 on branch fixing_enb_20_10.
>>
>>
>>
>> /home/bts/srsLTE/srsenb/src/enb_cfg_parser.cc.890: Force DL EARFCN for
>> cell PCI=1 to 2525
>>
>>
>>
>> Opening 1 channels in RF device=default with args=default
>>
>> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501;
>> UHD_3.15.0.0-62-g7a3f1516
>>
>> [INFO] [LOGGING] Fastpath logging disabled at runtime.
>>
>> Opening USRP channels=1, args: type=b200,master_clock_rate=23.04e6
>>
>> [INFO] [B200] Detected Device: B200
>>
>> [INFO] [B200] Operating over USB 3.
>>
>> [INFO] [B200] Initialize CODEC control...
>>
>> [INFO] [B200] Initialize Radio control...
>>
>> [INFO] [B200] Performing register loopback test...
>>
>> [INFO] [B200] Register loopback test passed
>>
>> [INFO] [B200] Asking for clock rate 23.040000 MHz...
>>
>> [INFO] [B200] Actually got clock rate 23.040000 MHz.
>>
>> [INFO] [B200] Asking for clock rate 61.440000 MHz...
>>
>>
>>
>> ==== eNodeB started ===
>>
>> Type <t> to view trace
>>
>> [INFO] [B200] Actually got clock rate 61.440000 MHz.
>>
>> Setting frequency: DL=881.5 Mhz, UL=836.5 MHz for cc_idx=0
>>
>> q
>>
>> Stopping ..
>>
>> ---  exiting  ---
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> srslte-users mailing listsrslte-users at lists.softwareradiosystems.comhttp://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>
>>
>> _______________________________________________
>> srslte-users mailing list
>> srslte-users at lists.softwareradiosystems.com
>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20210326/2ddce15c/attachment.htm>