In IPA/SCCPlite, we have to use the CIC to construct the MGCP
endpoint name instead of the usual dynamic endpoint allocation.
Change-Id: I03e2cdbc8e40169e52df3720c40b66734e880525
Also: Move mgcp_timeslot_to_port() next to it, as they are
more or less the inverse transformation of each other.
Change-Id: Ica908e2bb8fc4e59e0d146b428c93a9efc385688
We used to have hard-coded M3UA. Let's allow the user to configure
this per MSC using a new "asp-protocol (m3ua|sua|ipa)" VTY command.
For SUA this should just work 1:1 without any trouble. For IPA,
this of course only changes the underlying transport without reflecting
the various differences in terms of BSSMAP ASSIGNMENT, MGCP handling,
etc.
Change-Id: I0800c709e574cedd7f5dd98be81c78782245cd13
Related: OS#2544
In gscon_fsm_wait_mdcx_bts() we try to allocate conn->user_plane.fi_msc
but then check whether conn->user_plane.fi_bts is set, possibly due to
a copy+paste error. Let's fix that.
Change-Id: I1f515910f67492257866791588f32b350fadf815
Use memcpy() to avoid unaligned access, instead of writing through a
pointer cast to uint32_t. Problem spotted by address sanitizer:
abis_nm.c:2802:24: runtime error: store to misaligned address 0x7ffc95396706
for type 'uint32_t', which requires 4 byte alignment
0x7ffc95396706: note: pointer points here
81 0b bb 80 00 00 00 00 ed 79 28 56 00 00 e0 9c 00 00 a0 61 00 00 ...
^
Related: OS#3196
Change-Id: I8e591a56ae522b371da01ea968151a7e6fa24bb9
The state ST_WAIT_MODE_MODIFY_ACK can never be reached by the
current FSM model.
- Remove ST_WAIT_MODE_MODIFY_ACK and all related code
Change-Id: Iacaae2ee50ca1956066b7dce4517bbc9c2b0897e
Related: OS#2762
* Check the message length once at the start, before any other actions.
* Use only one local gsm48_hdr pointer.
* Read the cause value once near the top, re-use it.
* Log "ASSIGNMENT COMPLETE" always, not only during handover.
* Fully initialize local struct lchan_signal_data.
Change-Id: Idcfd932d3dfb0b621ed6d8c4f92c0231abcdcec8
bsc_api.c notoriously lacks log context. Provide gsm_lchan_name() and/or
bsc_subscr_name() in roughly a million instances, using new LOGPLCHAN macro.
Add LOGPLCHAN() to gsm_data.h, to encourage use of it in other .c files.
Change-Id: If469defcc6fe8950dac5df61db3f39d297893318
Default usage values are defined in mgcp node, and can be per-BSC
overriden on each bsc node.
This commit is a forward-port of openbsc.git Change-Id
Ibf3932adc07442fb5e9c7a06404853f9d0a20959.
Depends on osmo-mgw.git Change-Id Ie19a64ac09f9d51f2434ad0d7925610fc919a90e.
Change-Id: Ie07b8a577caf731d59d68e3b3510ae2f9fd3dc93
Add a global counter to the BSC which shows the number of failed
connections attempts due to a unit_id mismatch between the BSC
and the BTS.
Change-Id: I58866aff36a1c8463bf84b4392a5124ffeaa32ea
Related: OS#3245
The 'show statistics' VTY command was not showing all counters
maintained by osmo-bsc. Instead of printing just two counters
related to paging, print all available counters in a generic way.
Adjust descriptions of some counters for nicer display.
After startup (all counters are zero) is now looks like this:
OsmoBSC# show statistics
handover:attempted: 0 Received handover attempts.
handover:no_channel: 0 Sent no channel available responses.
handover:timeout: 0 Timeouts of timer T3103.
handover:completed: 0 Received handover completed.
handover:failed: 0 Received HO FAIL messages.
paging:attempted: 0 Paging attempts for a subscriber.
paging:detached: 0 Paging request send failures because no responsible BTS was found.
paging:responded: 0 Paging attempts with successful response.
OsmoBSC#
Change-Id: I58ae04e1960774d760e3ebb54a4f307c9f753655
Related: OS#3245
The function a_reset_free() is not used anywhere at the code. The
reason for this is that a BSC instance is never cleared once it
is started up. Also the timer number is not according to the spec.
- Remove a_reset_free()
- Fix timer identification number (T4)
- use fi->priv to hold context info
- Fix sourcecode formatting
Change-Id: I72095d52304c520e383755eee6c889bce492cbd4
Related: OS#3102
Reshuffle the decision not to activate PDCH when GPRS is off:
Even though all current callers should avoid passing a PDCH activation in case
GPRS is off, it's a better idea to not assert on it and crash osmo-bsc.
Move the decision to omit PDCH activation and logging about it into the actual
functions that do PDCH activation. If PDCH activation is skipped, the lchan
then just stays as it was, and that's what it should anyway be doing.
Change-Id: Ib26642f08044d71a2469e6dbabf1e6fbcb02044d
In osmo-nitb, the way TCH lchans were assigned often resulted in mismatching
TCH kinds, causing problems in the lack of transcoding. Hence
dyn_ts_allow_tch_f was introduced as a workaround.
Now however, we always assign an SDCCH to a requesting MS first, and only later
assign a TCH channel, which then adheres to the codec list configured at 'msc'
in the vty config. Hence it is now considerably harder to obtain a mismatch.
Furthermore, forcing specific codecs is possible by simply omitting the
unwanted ones from the msc config's codec-list. The equivalent of
'dyn_ts_allow_tch_f 0' could be e.g. 'codec-list hr3 hr2 hr1'.
Change-Id: Ib2335d02ea545aff837aadd49f15b2fdb418c46e
In rsl_chan_activate_lchan(), remove a condition to also allow switching pchan
modes when not in PDCH mode, which is actually not needed and would hinder
switching from pchan=NONE or between TCH/F <-> TCH/H.
Refactor the part where lchan_alloc() decides to switch a pchan mode into a
separate function, ts_usable_as_pchan(), which transparently checks both dyn TS
kinds for:
- Already in switchover? (missing check for ip.access style dyn TS)
- Is the lchan->state in error? (missing check for ip.access style dyn TS)
- Switch from pchan=NONE? (missing feature for Osmocom style dyn TS, for proper
handling with gprs mode none)
- Switch between TCH/F <-> TCH/H when all subslots are unused?
(missing feature for Osmocom style dyn TS, also useful for gprs mode none)
Always pass the desired pchan in the dyn_as_pchan argument to the _lc_find_*
functions to make switchover decisions transparent. Use the _lc_dyn_find_bts()
function for ip.access style dyn TS for the same reason.
Related: OS#3244
Change-Id: I72d5d833b186b1e1925d513885b405d8c19aa496
Recent Icf6e25ff068e8a2600562d52726ead65e864ec02 changed the dyn_ts_init() hook
from bootstrap_rsl() to the Channel OPSTART ACK, but this is not sufficient.
Now RBS2k never calls dyn_ts_init(), and we may need to wait for RSL:
Dyn TS should actually be initialized only when *both* OML opstart and RSL link
are established. To that end, introduce a generalized API to query OML and RSL
status and to trigger a timeslot init at the appropriate time.
Add gsm_ts_check_init() to be called both when RSL and OML opstart are
established: trigger gsm_ts_init() only when both are given.
Add gsm_bts_trx_ts->initialized flag to mark whether initialization has already
taken place. Add gsm_bts_mark_all_ts_uninitialized() to conveniently clear this
flag for all TS in a BTS.
Add gsm_bts_model.oml_is_ts_ready() callback so that each BTS implementation
can return the OML status of a timeslot in its own OML implementation.
Actually, currently all BTS models that need this init mechanism store the TS'
OML status in ts->mo.nm_state. While we would in practice correctly init dyn TS
by just looking at ts->mo.nm_state, semantically, the decision whether the TS
is ready is up to the BTS models' specific OML implementations.
From bootstrap_rsl(), call gsm_ts_check_init(), in case the TS OML Opstart has
happened before RSL is established -- applies to all BTS models.
For all BTS models:
- call gsm_{bts,trx}_mark_all_ts_uninitialized() when OM is torn down, to make
sure the TS init mechanism will work a second time.
For all BTS models supporting dyn TS, i.e. osmo-bts, nanobts and RBS2k:
- implement oml_is_ts_ready().
- call gsm_ts_check_init() when a Channel OM is taken into operation.
Any BTS models that don't set oml_is_ts_ready() will see a ts init as soon as
RSL is bootstrapped (incidentally, the old dyn TS behavior before recent
Icf6e25ff068e8a2600562d52726ead65e864ec02).
This firstly fixes dyn TS for RBS2k by re-adding the initial switch to PDCH,
and furthermore does so only after both OML TS opstart and RSL are through.
This fixes the ttcn3-bsc-tests around dyn TS, since for the osmo-bts-virtual,
the RSL is established only after OML opstart on the TS, which was broken by
Icf6e25ff068e8a2600562d52726ead65e864ec02.
Nokia Site and Siemens BS11 practically do not require this init mechanism,
since all that happens there so far is dyn TS init, and these BTS models do not
support dyn TS of any kind. A future patch may add oml_is_ts_ready().
Related: OS#3205
Change-Id: I99f29d2ba079f6f4b77f0af12d9784588d2f56b3
Previously the MGW configuration was ignored during writing
of the MSC configuration. Let's fix this by calling the
mgcp_client_config_write() function.
Change-Id: I7d1eedb782a4f30bd089838969ce54f27cde060d
Typically, an lchan that is released should no longer be associated with
subscriber connection. If that is the case, an S_LCHAN_UNEXPECTED_RELEASE is
triggered, which aborts, e.g., an ongoing assignment.
However, with dynamic timeslots, we may set lchan->conn and then start to
switch over from PDCH to a TCH mode, in which case it is perfectly fine to
release an lchan that is associated to a conn.
In lchan_free(), do not fire S_LCHAN_UNEXPECTED_RELEASE for a dyn TS that is
currently in switchover.
This is the second and last part to fix dynamic timeslots handling of the
gscon.
Related: OS#3211
Change-Id: Id7d9dd06451722eb328db77bb586826c954bd85c
Set lchan->state to LCHAN_S_ACT_REQ in rsl_chan_activate_lchan(), not in
handle_new_assignment().
This is the first part of a fix for dynamic timeslots handling in the gscon.
Rationale:
In rsl_chan_activate_lchan(), we may choose to set the lchan state to
LCHAN_S_REL_REQ and wait for dyn TS switchover from PDCH.
So the caller from bsc_api.c handle_new_assignment() must not bluntly set the
state to LCHAN_S_ACT_REQ, which is not accurate in the case of dyn TS
switchover.
In case of dyn TS switchover, a later release ack received from the BTS will
cause rsl_chan_activate_lchan() to be called again, at which point we may
accurately set state LCHAN_S_ACT_REQ, and continue the Assignment.
Related: OS#3211
Change-Id: Iedb4fb63bf1959d5f1d2c6edb6a7f5097ff16bd7
Sending PDCH activation upon RSL bootstrap is too early. Introduce OPSTART ACK
handling to call dyn_ts_init() only when the dynamic timeslot is indeed ready
to receive a PDCH activation.
Related: OS#3205
Change-Id: Icf6e25ff068e8a2600562d52726ead65e864ec02
At this point, meas-feed is usable again, however, osmo-bsc is not able to
include the IMSI in every report like osmo-nitb did.
In consequence, the meas-vis and meas-web tools are unable to handle the
current measurement reports: these so far use the IMSI to list reports, and all
reports without an IMSI are collapsed onto the same line, swapping values.
So though osmo-bsc now sends usable measurement reports via meas-feed, two
avenues to improve should be pursued:
OS#3192: the visualization tools should use bts,ts,ss numbers, not IMSI.
OS#2969: osmo-bsc should always know a mobile identity.
Related: OS#2968
Change-Id: I186c7a995dd2b81746c32a58b55da64ed195a1ce
gsm0808_assign_req() checks if the new channel mode is compatible
with the new mode. If it is, it does a gsm48_lchan_modify(), but
it does not actually check if the new mode is equal to the current
mode.
- skip when the channel is compatible and the new mode is equal to
the old mode.
- send the ASSIGNMENT COMPLETE directly from ST_ACTIVE when no
mode modify was necessary.
Change-Id: I86a2d52836c54d2dbd77441b182f757327ec7262
Related: OS#2936
meas_feed.c used to live in libmsc, to send out measurement reports to external
entities for evaluation. When splitting osmo-bsc and osmo-msc from openbsc.git,
meas_feed.c should have moved to osmo-bsc.git, but was dropped with libmsc.
Re-add the old meas_feed.c now into libbsc. This is the latest version that
existed in libmsc, and will not compile as-is here. Modifications to
incorporate in the osmo-bsc build will follow with subsequent patches.
Change-Id: Ic070d82e61c122061fe7297a8c5aabbbcef6b301
Flush the paging queue if the link to TRX 0 is dropped from a BTS.
This should prevent stale paging requests sent to the BTS when it
disconnects or reconnects, as seen in the TTCN3 BSC_Tests test suite.
Also, add entries to the log when RSL or OML links are dropped so
that related error messages in the log can be interpreted in context.
Change-Id: If4401c1139cd01faf5ff374301a9a701898c3777
Related: OS#2901
Move to its own function, store pointer to proper header format and use
the already defined IE define from libosmocore instead of using
hardcoded values.
Depends on: Change-Id I7cb65f3ff1cfdbe4eee97b7545bcd13a38c72e25
Change-Id: I845fd3f0c6ff31f268f68a31e1d55981f7ec6129
If the OML link is found down while a paging request is issued,
no paging message is sent. However, we were still counting such
pagings as an actual attempt, and counted them towards the number
of available slots on the paging request queue.
Move the OML link check to the caller of page_ms() where the
accounting steps can be properly skipped as they should be.
Change-Id: I5b6db681da7d45c49e1f2f99d7789c8a29372ef3
Related: OS#2901
On the assignmen of signalling channels, the voice related fields
do not play a role. However the function send_ass_compl() that
generates the assignment complete message is very strict about the
presence of those voice related parameters.
- Add a parameter to function send_ass_compl() to generate the
different types of assignment complete messages
Change-Id: I316ebcb1f27b668e17fe48fff028e047aac47f76
Related: OS#2762
Since libosmocore 7c0031fc8063771e604976233fb7b46d2b85c077, the cmd
param passed to handlers in ctrl_handle_msg is always freed afterwards,
thus it is owned by the same function. Avoid keeping it alive and
accessing it later when it has already been freed.
Related: OS#3157
Change-Id: I764917f641b170597e405f1865b0f7b94bae1597
The SUBSCR_CONN (GSCON) fsm starts a timer (993210, 20sec.) when the
CR to the MSC is made. When the timer reaches its timeout, then the
SUBSC_CONN FSM terminates. Such a timeout event is also an indicator
for a bad SCCP connection so we should call a_reset_conn_fail() to
inform the A-RESET FSM about the event in order to cause a BSSMAP
reset when too many timeouts occurr consecutively
- Call a_reset_conn_fail() when 993210 expires
Change-Id: I836a552f2ad37c160081246579f842d104d0dd35
Related: OS#3102
Take both the operative and administrative states into account
when deciding whether to start ACC ramping, and examine old/new
state values to avoid triggering ramping for a no-op state change.
This requires a fix to gsm_trx_lock_rf(): This function overwrote
the old administrative state of a trx before enqueuing a state
change request towards the BTS.
The BTS will confirm this request with an ACK, at which time a
signal is generated which the ACC ramp code listens to. We must
not overwrite the old state value until the signal has been handled,
otherwise the signal handler cannot tell what the old state was.
Tested with a virtphy setup, nanobts, and osmo-bts.
Change-Id: Ib3291439655598fb5ddc891a3e4cc35b0bad250f
Related: OS#2591
Starting an ACC ramping process while TRX 0 is unusable or locked is
pointless. For instance, after loading a config with 'rf_locked 1'
for trx 0, the ramping process was started as soon as the BTS
established RSL, even though the air interface was still down.
ACC ramping should instead be triggered once TRX 0 is unlocked.
Change-Id: I054829a936f0aa1e3fa34fad6466a1cd6150e307
Related: OS#2591
Trigger ACC ramping not only when an Administrative State Change
ACK is received from a BTS, but also when an administrative state
change is reported for TRX 0 in a State Changed Event Report.
This should allow ACC ramping to work with any BTS which reports
an administrative state change to 'unlock' using either of these
OML messages.
Tested with a sysmobts and a nanobts.
The sysmobts only reports TRX locked/unlock changes in Administrative
State Change ACKs, not via State Changed Event Reports.
The nanobts is known to send both of these OML messages in quick
succession, so do not re-trigger ramping if it's already in progress.
Change-Id: I097a113a3a63de02bcb8277020beb59cf485b176
Related: OS#2591
The word 'enabled' was used in two contexts: Whether ACC ramp is
enabled as a feature, and whether a particular access control class
is permantly allowed/disallowed via VTY configuration.
Rename some helper functions to avoid the use of the word 'enabled'
in the latter context.
Change-Id: Ia67e84270cd50f4c55b8cf616ca38b00482f765c
Related: OS#2591
Make ACC ramping listen to network management signals and trigger
or abort ACC ramping based on the RF locked state of TRX 0.
This works as expected with a virtphy setup when RF lock state is
changed via VTY. However, this change still needs to be tested with
a nanobts. It's also not quite clear yet whether operational state
changes, as opposed to administrative ones, should be taken into
account as well.
Change-Id: I4124f1da3dadec003de45c1da8435506ee8f0a34
Depends: Ia25bff85d9e5c277da76bffa11d31972e9fdc323