Osmocom's Base Station Controller for 2G mobile networks
https://osmocom.org/projects/osmobsc
Neels Hofmeyr
8d9c3e7f30
On rsl_rx_chan_rqd(), so far osmo-bsc tried to preferably assign the lchan type that was asked for in the RACH. Firstly, this contained a bug, and secondly, it does not make sense to heed that preference, since we do late assignment. Ignore the preference for the MS' TCH kind. We do late assignment to avoid codec mismatches. In the "old days", we would heed the MS' TCH channel kind, even if the MSC or BSC didn't actually allow or prefer that channel kind. Hence, in the presence of both TCH/F and TCH/H, the MS could ask for TCH/F (which we would grant on the MO side) and the BSC or MSC could prefer TCH/H (which we would apply on the MT side), and hence fabricate a codec mismatch. Instead, since quite some time now, we *always* assign an SDCCH first, and only later on do another Assignment to hand out a proper voice lchan that heeds the MS capability bits as well as MSC's and BSC's preferences. By completely ignoring the channel kind the MS asked for in the RACH, we also eliminate this bug in rsl_rx_chan_rqd(): - If the first "lchan_select_by_type(GSM_LCHAN_SDDCH)" fails (all SDDCH in use), we should try to fall back to any TCH instead, to serve as SDCCH. - the first "if (!lchan && lctype != GSM_LCHAN_SDCCH)" was an attempt to prefer a fallback to the lchan type the MS requested. - the remaining two "if (!lchan && lctype == GSM_LCHAN_SDCCH)" were obviously only applied if the MS asked for an SDCCH, and skipped if the type was TCH/*. - hence, missing was: if the MS asked for a TCH, to also try the *other* TCH kind that the MS did not ask for. (Example: all SDCCH in use, MS asks for TCH/F, but BSC has only TCH/H lchans; we should assign TCH/H as SDCCH, instead we said "no resources") Change-Id: Ie3684cf071751f9528183d761c588102936e498c Related: OS#3503 |
||
|---|---|---|
| contrib | ||
| debian | ||
| doc | ||
| include | ||
| m4 | ||
| src | ||
| tests | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| AUTHORS | ||
| COPYING | ||
| Makefile.am | ||
| README | ||
| README.vty-tests | ||
| configure.ac | ||
| git-version-gen | ||
| osmoappdesc.py | ||
README
About OsmoBSC ============= OsmoBSC originated from the OpenBSC project, which started as a minimalistic all-in-one implementation of the GSM Network. In 2017, OpenBSC had reached maturity and diversity (including M3UA SIGTRAN and 3G support in the form of IuCS and IuPS interfaces) that naturally lead to a separation of the all-in-one approach to fully independent separate programs as in typical GSM networks. OsmoBSC was one of the parts split off from the old openbsc.git. Before, it worked as a standalone osmo-bsc binary as well as a combination of libbsc and libmsc, i.e. the old OsmoNITB. Since the standalone OsmoMSC with a true A interface (and IuCS for 3G support) is available, OsmoBSC exists only as a separate standalone entity. OsmoBSC exposes - A over IP towards an MSC (e.g. OsmoMSC); - Abis interfaces towards various kinds of BTS; - The Osmocom typical telnet VTY and CTRL interfaces. Find OsmoBSC issue tracker and wiki online at https://osmocom.org/projects/osmobsc https://osmocom.org/projects/osmobsc/wiki OsmoBSC-NAT is a specialized solution to navigating RTP streams through a NAT. (Todo: describe in more detail)