Bug #3332
closedosmo-bsc doesn't allocate "larger" channels
100%
Description
If a MS is requesting a channel indicating a SDCCH type (e.g. for LU or SMS), osmo-bsc currently will fail if no SDCCH are available.
It's questionable whether this is a good idea, if at the same time we have plenty of TCH/H or TCH/F sitting idle. A "larger" channel would also allow the MS to complete the related SMS/LU/USSD, i.e. we are rejecting a sequest for a given service despite being able to fulfill it.
The current behavior prioritizes holding traffic channels available for MT voice calls over providing chnanels for new MO services. There is some logic to it, but I think it's flawed: We don't yet know if any of those idle channels will ever be needed for MT calls, and on that basis we're denying service to other requests?
Maybe it should be a VTY option, with the default to use "larger" channels if no SDCCH are available.
Updated by neels almost 6 years ago
- Assignee set to neels
I know exactly how to solve this, in rsl_rx_chan_rqd() add a
if (!lchan && lctype == GSM_LCHAN_SDCCH) {
LOGP(DRSL, LOGL_NOTICE, "(bts=%d) CHAN RQD: no resources for %s "
"0x%x, retrying with %s\n",
msg->lchan->ts->trx->bts->nr,
gsm_lchant_name(GSM_LCHAN_SDCCH), rqd_ref->ra,
GSM_LCHAN_TCH_F);
lchan = lchan_select_by_type(bts, GSM_LCHAN_TCH_F);
}
maybe needed for TCH_F and for TCH_H separately...
(lchan_select_by_type() is the new chan_alloc() after current osmo-bsc refactoring on neels/inter_bsc_ho)
Updated by neels almost 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 90
Implemented in I2fcf9e9baa7d03974a367763f3f52f59dfc2cc51 (currently only on osmo-bsc branch neels/inter-bsc-ho)
Updated by laforge over 5 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
patch has been merged
