The current configuration for permitted AMR rates on BTS level has been
choosen arbitrarily. Lets choose the possible rates so that they match the
"Config-NB-Code = 1" as defined in 3GPP TS 28.062 Table 7.11.3.1.3-2.
(The current default behavior is not changed since the MSC level
configuration only permits 5.90k by default.)
Change-Id: I916953e3fdb54168671dd13b359e78662fa31059
Related: SYS#4470
This commit breaks voice channel assignment. It results in the
Assignment Complete sent to the MSC for a voice lchan lacking
AoIP Transport Layer Address, Speech Version and Speech Codec.
Hence the MSC cannot complete the Assignment for a voice call.
Let's revisit this patch, test thoroughly and re-merge later.
This reverts commit 4d3a21269b.
Reason for revert: <INSERT REASONING HERE>
Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
This commit aims at better ordering of content in order to get rid of
sigtran stuff in gsm_data. This way we can avoid requiring
libosmo-sigtran when building ipaccess utils.
Change-Id: I8941f059d6e4eb21a971d48d2b66c29ec3355a6d
To support the 3 possible preferences, the changes needed were:
- Replace 'full_rate' bool with a 3 option enum to represent
the channels types for signalling
- Switch from _pref/_alt to using an array sorted in preference
order
Change-Id: I4c7499c8c866ea3ff7b1327edb3615d003d927d3
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When a new lchan is selected during handover, some of the properties of
the old lchan are inherited by the new lchan. At the moment S15-S0 is
not not inherited so that the value for those bits will always be 0x0000
for the new lchan. Since those bits also define the active set AMR codec
the channel activation will fail because 0x0000 is invalid (active set
with zero rates)
Change-Id: Ifd470397e99985394634da1bb13ccfc5041984d2
Related: OS#3503
When the ASSIGNMENT COMPLETE message is composed,
lchan->ch_mode_rate.s15_s0 is used to fill in the S15-S0 which are
returned to the MSC. This is not correct since the assignment process
may involve multiple lchans, so that at the point where the ASSIGNMENT
COMPLETE is generate, the stored S15-S0 may be lost already because the
lchan has changed. To prevent this, we must use
lchan->activate.info.s15_s0, which is retained throught lchan changes.
Change-Id: I9a7b3ce8646d641569eac24e202f44cdb5f67b3d
Related: OS#3503
When the MSC allocates a channel through the ASSIGNMENT REQUEST, it may
ask for a TCH/H and a TCH/F at the same time and tell which of the two
types it prefers.
The process of channel allocation currently selects, based on the BTS,
MSC and MS capabilites exactly one apropriate codec/rate (e.g. TCH/H)
and then tries to allocate it. If that allocation fails, there is no way
to try the second choice and the assignment fails.
For example: The MSC asks for TCH/F and TCH/H, prefering TCH/F, then the
channel allocator will try TCH/F and if it fails (all TCH/F are
currently in use), then TCH/H is never tried.
Since the BSC currently only trys the first best codec/rate that is
supported it also ignores the preference.
Lets fix those problems by including the preference information and both
possible codec/rate settings into the channel allocation decision.
Change-Id: I5239e05c1cfbcb8af28f43373a58fa6c2d216c51
Related: OS#3503
In some test and debug situations it is useful to have the ability to
lock certain lchans in a way that the BSC can not allocate them. One
application might be to simulate an exhaustion of all TCH/H channels in
order to force the BSC to take one of the available TCH/F.
Lets add a command to the vty which alloes us sen lchans from
LCHAN_ST_UNUSED
to LCHAN_ST_BORKEN and vice versa.
Change-Id: I397e68e26d6a1727890353fa34f4897b54795866
Related: OS#3503
handover_fsm.c accesses conn->assignment.req.s15_s0 to find out the current
lchan's AMR configuration. However, conn->assignment.* values are only valid
during an ongoing assignment. Those values may be overwritten by any failed
Assignment attempt, at any time, and hence do not reflect the currently
assigned conn->lchan. Those realms must be kept separate.
The assignment.req.s15_s0 get passed to lchan_activate(), so it makes most
sense to store these values in struct gsm_lchan once the lchan activation
succeeded.
Add gsm_lchan.s15_s0, store the s15_s0 received in lchan_activate_info during
lchan_activate().
In handover_fsm.c, use conn->lchan->s15_s0 instead of conn->assignment.*.
Change-Id: Id8018fd9d56421f2ab7be91703018f6d6f21c929
When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE,
it lets us know that the to-be-released connection related to a CSFB
call.
We as the BSC then subsequently should include the "Cell Selection
Indicator after release of all TCH and SDCCH" IE in the RR RELEASE
message sent to the MS/UE. This IE contains the LTE neighbor cells
that we're configured to broadcast in si2quater.
That in turn will make sure the MS/UE can return very quickly to
the LTE cell.
Closes: OS#3777
Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646
Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07
Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1
We meanwhile have chapters about the CTRL interface protocol as well
as the auto-generated list of CTRL interface commands/values, so
let's remove the somewhat redundant information.
Change-Id: I062d7eec3b3fc53c31726be3b3a407a2dd3b8b56
We still haven't re-introduced support for E1 based BTSs, so let's
remove the relevant chapters from the manuals. Also, make sure
we don't call anything OsmoNITB in this manual anymore.
Change-Id: I834d65836731958b6be823a18e35407183398715
It makes a lot of sense to first describe the VTY interface before
going on using it to configure something. Also, configuration related
topics relevant to operators/sysadmins should precede other content
only relevant to developers, like the details of the CTRL or Abis/IP
protocol.
Change-Id: I0872d072bbb06f9409a72b93133d136167f03b38
This adds some instructions on how to configure 3G/4G neighbor
cells within osmo-bsc. I didn't want to add a new top-level
chapter but instead chose to add it to the handover section which
describes also the configuration of 2G neighbors.
Change-Id: I81df1a453858b6fca80c8adf234b1d5b8bf5283d
In GSM specs, the entire interface between two elements is designated
with some letter, like the A interface between BSC and MSC. The
interface uses a variety of protocols stacked on each other.
In the specific case of A, there is no "A" on top of SCCP, but
there's "BSSAP" on top of SCCP.
This is followed somewhat un-orthodox by 3GPP, as "A over IP" is
a violation of that principle. It should have been called "A utilizing
IP", "A based on IP", "A with IP" or something the like.
In any case, at no point do the specs ever claim that "A" is stacked
on top of SCCP, so let's fix this.
Change-Id: Ieb0d8f6c71debe1234aff343a994c2096326da1b
Currently the VTY only displays the lchans that are currently in use
(show lchan summary). In some situations (debugging) it can be useful
to list all lchans, regardless of their state. So lets add a command
for that.
Change-Id: Ie4d763476905fa8f84b4d7cdad4cc7dd879f84a5
Related: OS#3503
* use gsm0808_create_ass_compl2() to add BSS Status IE to Assignment
Complete message
* drop local helpers
Depends-on: (libosmocore) I547c6b8707123aa8c1ef636db88908df112d90a4
Change-Id: I6916928391667cd9c345becf00e7c8561846c295
Related: OS#2487
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
The function lchan_select_by_type() will unsolicitedly select a TCH/F
when it is asked for a TCH/H but a TCH/H is not available. This behavior
is presumably a leftover from before the split. Now every fallback to
another rate must be agreed with the MSC in advance, it is a spec
violation to silently fallback to TCH/F when asked for a TCH/H.
Change-Id: I057e70bc81b3dac470f6d1d2a37533ec3a7a79d0
Related: OS#3503
The function lchan_select_by_chan_mode() is prone to select an half rate
lchan when EFR is used, even though EFR is not defined for half-rate.
Lets protect against that.
Change-Id: I961d9aaba81424053ab1dc04ce7799e716af4cd8
Related: OS#3503
The function lchan_alloc() does not exist anymore, however there is
still a prototype definition in chan_alloc.h and a comment in
abis_rsl.c. Lets remove those.
Change-Id: I36227ea306d28587ac70acbe596c7756b23d88c7
Previously LCHAN_RTP_EV_IPACC_MDCX_ACK was not permitted for
LCHAN_RTP_ST_ESTABLISHED state in lchan FSM. However this message is
normal in case of LCLS loop closed via IPA (as opposed to MGCP). Let's
permit this message and log it to make debug output easier to read.
Change-Id: Ib642df799f3405c4d707eb57b2ebc84386d7f03f
Related: OS#2487
In theroy the function T_def_get_entry() may return a nullpointer. In
this case we would run straight into a nullpointer dereference problem.
However, the requested timer is statically defined and should always be
there. However Coverity still reports this as a problem. Lets put an
OSMO_ASSERT to make clear that there is no problem here.
Fixes: CID#190403
Change-Id: If5238132d9d5a1507b9955a0b2dc4b1bced220e8
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
After this, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint.
osmo-mgw-for-bsc.cfg:
mgcp
domain bsc
osmo-bsc.cfg:
msc 0
mgw endpoint-domain bsc
Depends: Ia662016f29dd8727d9c4626d726729641e21e1f8 (osmo-mgw)
Change-Id: I492023e9dca0233ec0a077032455d9f2e3880f78
There could multiple reason for OML or RSL link towards BTS to be
dropped: ctrl command, vty, new link etc. Introduce "reason" parameter
to corresponding functions and log it on link drop to simplify
troubleshooting issues with more complex setups.
Change-Id: I8c8d8132ba67c31e40dbecdfe2e09be08c744899
Fix crash after AMR configuration fails.
The crash is due to an assertion that finds a non-NULL conn in the lchan, when
re-using an lchan that has failed in AMR configuration earlier on. That is
because the AMR config still happens in state UNUSED.
DCHAN ERROR lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) lchan allocation failed in state UNUSED: Can not generate multirate configuration IE
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) After failure handling, already in state UNUSED
...
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE (lchan_fsm.c:324)
Assert failed !lchan->conn ../../../../src/osmo-bsc/src/osmo-bsc/lchan_fsm.c:491
The FSM design idea is that when returning to the UNUSED state, all lchan state
is cleared. However, when calling lchan_activate(), a failure may happen still
in state UNUSED, so that we don't transition *back* to UNUSED properly.
So, first transition out of UNUSED before failures can happen. (Other ways to
solve this would be to invoke lchan clearing even if already in UNUSED, but
semantically, transitioning first makes more sense.)
Upon LCHAN_EV_ACTIVATE, just remember the lchan_activate_info and transition to
WAIT_TS_READY, so that on lchan_fail(), we can normally transition back to
UNUSED and clear the lchan.
Move the initial lchan activation code to lchan_fsm_wait_ts_ready_onenter().
Also, there is a bit of duplication of members of the lchan->activate (lchan
state) and the lchan_activate_info (passed to lchan_activate()) structs. The
fix for this also removes the dup:
Add struct lchan_activate_info as child struct at lchan->activate.info, drop
the other lchan->activate members that would dup .info.*. Move struct
lchan_activate_info declaration to gsm_data.h.
Apply the new '.info' member struct throughout the code.
Related: OS#3737
Change-Id: Ide665b10fa3f4583059c55346db8da833959e3cc
* use osmo_lcls struct from libosmocore
* use enum values instead of magic numbers
Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858
Related: OS#3659
According to 3GPP TS 08.58 §8.5.1 BCCH INFORMATION:
"If the Full BCCH information element is not included this indicates that
transmission of the indicated SYSTEM INFORMATION message shall be stopped."
However, some ipaccess nanoBTS firmware versions are known to not support
some SI elements and also to dislike receiving BCCH Information for those SI,
even if received with empty BCCH Information meaning they should not be used.
Upon receival of this kind of message, nanoBTS sends a Failure Report
with following text:
Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149
****
** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (325).
****
This kind of issue only appears with some fw versions, since it's known
to work fine in other ones, so let's not disable this kind of mesage by
default on all BTs of type "nanobts".
Instead, add a VTY command that allows disabling this kind of message in
order to be able to operate those nanoBTS units.
Fixes: OS#3707
Change-Id: Idec1daabc21de4eea5c55edd1dbb0e0775720fc7
Philipp Maier
Pau Espin
Neels Hofmeyr
Neels Hofmeyr
Sylvain Munaut
Harald Welte