Dear Pierre,
I am interested in this topic, I am abroad at the moment, but in a weeks time I will be
able to test it.
To point out a similar case, I had almost the same issue with OpenBTS and its
"own" transceiver, which was also created by Tom Tsou but it was not the
Osmo-TRX.
The behavior was pretty much the same: after the IMM_ASS the UE is sending the Packet
Resource Request, but the BTS never receives it and the T3168 timeout happens. It was
kinda hard to reproduce it, and we never found the root cause.There was some suspition
that the USRP SDR is somehow misses to detect the PRR, as nothing was sent to the upper
layers. Here you can find detailed protocol traces (wireshark and QXDM) and description of
what we found:
https://github.com/RangeNetworks/openbts/issues/8
Regards,
Csaba
----- Eredeti üzenet -----
Feladó: "Pierre Baudry" <pierre.baudry(a)diateam.net>
Címzett: openbsc(a)lists.osmocom.org
Elküldött üzenetek: Péntek, 2016. Május 27. 18:02:28
Tárgy: Regression in osmo-pcu with UHD trx ?
Hi all,
I have a Osmocom setup running with a Ettus B200
I noticed that since several weeks that osmo-pcu did not work as good as
previously.
The latest "good" revision I am aware of is commit
d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14)
I tried again today with commit 2fcfc29020c81891d7888ddc7ddbcd866bcd406d
(2016/05/24) and not a single handset could establish data communication
Reading osmo-pcu logs show that T6169 timeouts during TBF assignment :
Fri May 27 15:51:38 2016 DRLCMAC <0002>
bts.cpp:479 MS requests UL TBF on RACH, so we provide one:
Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:672 ********** TBF starts here
**********
Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:674 Allocating UL TBF:
MS_CLASS=0/0
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_ms.cpp:114 Creating MS object, TLLI =
0x00000000
Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:407 Searching for first unallocated
TFI: TRX=0
Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:417 Found TFI=0.
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:525 Slot
Allocation (Algorithm B) for unknown class (assuming 12)
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:560 - Rx=4 Tx=4
Sum Rx+Tx=5 Tta=2 Ttb=1 Tra=2 Trb=1 Type=1
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS
0, because not enabled
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:579 - Possible
DL/UL slots: (TS=0)".CCCCCCC"(TS=7)
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:940 - Selected UL
slots: (TS=0)"...U...."(TS=7), single
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single
slot at TS 3 for UL
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:990 - Reserved
DL/UL slots: (TS=0)"...C...."(TS=7)
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:1017 - Assigning
UL TS 3
Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:1481 PDCH(TS 3, TRX 0): Attaching
TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001.
Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:385 - Setting Control TS 3
Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_ms.cpp:267 Attaching TBF to MS object,
TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL)
Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:625 Allocated TBF(TFI=0
TLLI=0x00000000 DIR=UL STATE=NULL): trx = 0, ul_slots = 08, dl_slots = 00
Fri May 27 15:51:38 2016 DRLCMAC <0002> ./tbf.h:291 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=NULL) changes state from NULL to FLOW
Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:409 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=FLOW) starting timer 3169.
Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:523 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=FLOW) [UPLINK] START
Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:527 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=FLOW) RX: [PCU <- BTS] RACH qbit-ta=0 ra=0x7b, Fn=1607859 (28,33,19)
Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:529 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=FLOW) TX: START Immediate Assignment Uplink (AGCH)
Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:542 - TRX=0 (128) TS=3 TA=0 TSC=3
TFI=0 USF=0
Fri May 27 15:51:38 2016 DRLCMAC <0002> ./tbf.h:291 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=FLOW) changes state from FLOW to WAIT ASSIGN
Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=WAIT ASSIGN) timer 3169 expired.
Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission
Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:893 - Assignment was on CCCH
Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:899 - No uplink data received yet
Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:879 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=WAIT ASSIGN) will be freed due to timeout
Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:334 TBF(TFI=0 TLLI=0x00000000
DIR=UL STATE=WAIT ASSIGN) free
Every element of the stack is running with today's revision on master
(cheers for making it happen without specific branches by the way).
With the same setup with
osmo-pcu@d87e1d6ab747423d3668c74d16201a5d967accf0, I get solid data
rates around 40 Kbits/s.
I haven't seen anybody on the mailing list experiencing the same
behavior, making me believe that it could be specific to osmo-bts-trx /
osmo-trx users.
Can somebody confirm or reproduce this attitude ?
I will try to provide more logs and a pcap capture as soon as I get
hands back on the hardware.