Project

General

Profile

Bug #1775

LC15: No PDCH allocation across two TRX

Added by mqng2 over 4 years ago. Updated 2 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
-
Start date:
07/12/2016
Due date:
% Done:

80%

Spec Reference:

Description

I am currently testing GPRS with PDCH configuration across two TRX, i.e. TS3 - TS7 are configured as PDCH in TRX0, TS0-TS3 are configured as PDCH in TRX1.
Two MS are used for surfing the Web. I have noticed that the both MS always use TS3-TS7 of the TRX0 for DL TBF, they never use TS0-TS3 of the TRX1 for DL TBF.

Is it the limitation of the multi-TRX PCU implementation?

FYI: If I configure TS0-TS7 as PDCH in the TRX1, 8 PDCH will be used for both MS (4 PDCH of DL TBF each MS)


Related issues

Related to OsmoPCU - Feature #1553: Multi-TRX support of PCUClosed02/23/2016

Related to OsmoBTS - Feature #1648: Verify Multi-TRX support for osmo-bts-trxClosed03/11/2016

Related to OsmoPCU - Feature #2282: uplink multi-slot allocationsStalled05/22/2017

Related to OsmoPCU - Bug #2603: Review the various incomplete and never merged changes in radisys branchNew10/29/2017

History

#1 Updated by laforge over 4 years ago

  • Assignee set to msuraev

Hi Max,

can you please quickly comment on whether this is the expected behavior or not? Also, if it is expected, what is needed to have it changed?

#2 Updated by msuraev over 4 years ago

I'm not quite sure what should be the proper behavior in this case. I could re-test but the firmware of hw which we have is not compatible with the latest changes for litecell in osmo-bts master.

This was discussed as part of RT#4600. Are there any updates with regards to this?

#3 Updated by msuraev over 4 years ago

  • Status changed from New to In Progress

I can reproduce this on our device with both ascending and descending channel allocators. Not sure what's the root cause yet.

#4 Updated by msuraev over 4 years ago

#5 Updated by msuraev over 4 years ago

Note: build osmo-pcu with ENABLE_TS_ALLOC_DEBUG to gather additional info.

#6 Updated by msuraev about 4 years ago

  • Related to Feature #1648: Verify Multi-TRX support for osmo-bts-trx added

#7 Updated by msuraev about 4 years ago

  • % Done changed from 0 to 10

Note to self: try to reproduce with osmo-bts-trx.

#8 Updated by msuraev about 4 years ago

Also - reproduce with edge instead of gprs: currently one of the test phones (MTK-based) fails to bring up DL TBF for some reason.

#9 Updated by msuraev about 4 years ago

While trying to reproduce with osmo-trx:

Osmo-PCU# show tbf all
UL TBFs
TBF: TFI=0 TLLI=0xc6e23633 (valid) DIR=UL IMSI=001640000076847
created=1476457106 state=00000006 1st_TS=7 1st_cTS=7 ctrl_TS=7 MS_CLASS=12/12
TS_alloc=7! CS=CS-1 WS=64 V(Q)=13 V(R)=13

TBF: TFI=1 TLLI=0xc29225ff (valid) DIR=UL IMSI=001640000005666
created=1476457099 state=00000006 1st_TS=6 1st_cTS=6 ctrl_TS=6 MS_CLASS=10/10
TS_alloc=6! CS=CS-1 WS=64 V(Q)=38 V(R)=38

DL TBFs
TBF: TFI=1 TLLI=0xc6e23633 (valid) DIR=DL IMSI=001640000076847
created=1476457094 state=0000004a 1st_TS=5 1st_cTS=7 ctrl_TS=7 MS_CLASS=12/12
TS_alloc=5 6 7! CS=CS-4 WS=64 V(A)=118 V(S)=22 nBSN=-1

TBF: TFI=0 TLLI=0xc29225ff (valid) DIR=DL IMSI=001640000005666
created=1476457061 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=10/10
TS_alloc=4 5 6! 7 CS=CS-4 WS=64 V(A)=82 V(S)=90 nBSN=84

On following configuration with 2 trx:
trx 0
rf_locked 0
arfcn 876
nominal power 23
max_power_red 0
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config PDCH
hopping enabled 0
timeslot 5
phys_chan_config PDCH
hopping enabled 0
timeslot 6
phys_chan_config PDCH
hopping enabled 0
timeslot 7
phys_chan_config PDCH
hopping enabled 0
trx 1
rf_locked 0
arfcn 880
nominal power 23
max_power_red 0
rsl e1 tei 0
timeslot 0
phys_chan_config PDCH
hopping enabled 0
timeslot 1
phys_chan_config PDCH
hopping enabled 0
timeslot 2
phys_chan_config PDCH
hopping enabled 0
timeslot 3
phys_chan_config PDCH
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0⏎

#10 Updated by msuraev about 4 years ago

Note: might be good idea to try with dynamic channels once it's tested in multiTRX configuration.

#11 Updated by msuraev almost 4 years ago

  • Status changed from In Progress to Stalled

#12 Updated by arvind.sirsikar almost 4 years ago

  • Status changed from Stalled to In Progress
  • Assignee changed from msuraev to arvind.sirsikar

#13 Updated by wirelesss almost 4 years ago

Arvind please update this ticket. Thank you!

#14 Updated by msuraev over 3 years ago

Gerrit 1512 has patch for this under review.

#15 Updated by msuraev over 3 years ago

  • Status changed from In Progress to Stalled

#16 Updated by laforge about 3 years ago

#17 Updated by laforge about 3 years ago

  • Assignee changed from arvind.sirsikar to sysmocom

#18 Updated by msuraev about 3 years ago

#19 Updated by msuraev almost 3 years ago

  • Related to Bug #2603: Review the various incomplete and never merged changes in radisys branch added

#20 Updated by laforge about 2 years ago

#21 Updated by laforge over 1 year ago

  • Assignee changed from sysmocom to lynxis

#22 Updated by laforge 10 months ago

  • Assignee deleted (lynxis)

#23 Updated by laforge 9 months ago

  • Assignee set to daniel

#24 Updated by pespin 5 days ago

  • Status changed from Stalled to In Progress
  • Assignee changed from daniel to pespin

I submitted a TTCN3 test in osmo-ttcn3-hacks.git branch "pespin/pcu" which allocates up to 8 UL TBFs from different MS, and indeed all go to the same TRX.
It's even so broken that the 8th one is actually rejected because there's no more USFs available.

As per current implementation, is totally expected that first all TFIs in first TRX are allocated, and only then the next ones are taken (which may actually never happen due to the error described above).

See osmo-pcu.git src/gprs_rlcmac_ts_alloc.cpp tfi_find_free() which calls BTS::tfi_find_free() where the loop through TRX happens.

I'll be trying to improve the situation. I guess a good first step would be to have the 8th MS to successfuly register. Next step may be to start iterating on Nth TRX instead of first one, in a round-robin way. This way the load is spread among TRX.

#25 Updated by pespin 2 days ago

  • % Done changed from 10 to 80

Should be fixed by:
https://gerrit.osmocom.org/c/osmo-pcu/+/20919 alloc_algo_b: Select TRX with least assigned TFIs during TBF alloc

Tested by:
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20917 pcu: Assign different ARFCN numbers to each PCU TRX [NEW]
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20918 pcu: Introduce test TC_multitrx_multims_alloc [NEW]

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)