Project

General

Profile

Bug #3332

osmo-bsc doesn't allocate "larger" channels

Added by laforge 7 days ago. Updated 7 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
06/11/2018
Due date:
% Done:

0%

Estimated time:
Spec Reference:

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.

History

#1 Updated by neels 7 days 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)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)