The MSC may at any time send a BSSMAP CommonID message via a
SCCP connection to inform us of the IMSI of the subscriber. Let's
make use of that information by associating a related bsc_subscr
and updating the identity of the bsc_subscr_conn_fsm for improved
logging / filtering.
Closes: OS#2969
Change-Id: I52c43fb940f0db796adf4c0adb2260321c721c39
When the BTS is is not an ipaccess BTS, the BTS can only be an E1 bts.
In that case E1 endpoints must be used and there will be no RTP stream
setup towards the BTS.
Change-Id: I4f1f39bf90b0a7c9ea448dab255daf99cd36bb4a
Related: OS#2547
Prior to this patch, ACC ramping was only used to go 0->N in the
number of allowed ACCs during BTS startup. It could optionally
dynamically stretch or extend the ramping time based on channel load.
With this patch, ACC ramping is kept alive during the entire time the
BTS is active, and subset of allowed ACCs can now be incresed or
decreased based on channel load. A new VTY command
"access-control-class-ramping-chan-load" is added to configure a lower
and an upper threshold. Channel load under the low threshold will
potentially trigger an increment of the subset size of allowed ACCs,
while a channel load over the upper threshold will potentially trigger
the opposite (a decrease in size).
The time between checks is kept fixed per VTY command (reusing old
"access-control-class-ramping-step-size"), but the "dynamic" option
is deprecated and ignored from now on since it provides nothing valuable
in the new implementation, because the size always dynamically changes
based on channel load (configured thresholds).
Related: SYS#4912
Change-Id: Id17f947c92cdfc0eb9541a9bf066338169caaeb5
See updated documentation section in manuals/chapters/bts.adoc regarding
an explanation on how the system works.
Related: SYS#4911
Change-Id: I952c9eeae02809c7184078c655574ec817902e06
With upcoming next commit, the file will contain far more code that
simply ramping, so rename it to be more generic.
Change-Id: I8c368ab87e264439dea4ccf556821a44664cdbb0
In the big mess of gsm_data we reached a point where we have multiple
functions doing the same thing, most probably because it's hard finding
stuff in there. Let's drop one of them (the one which less callers) and
move it to bts.*, where it belongs.
Change-Id: I9071a0ab250844619280fbe2be63ed99f2c87eb1
Place all code related to the object into the related file.
Having all the data model in one file made sense in early stage of
development to make progress quickly, but nowadays it hurts more than
helps, due to constantly growing size and more and more bits being
added to the model, gaining in complexity.
Currently, having lots of different objects mixed up in gsm_data.h is a hole
of despair, where nobody can make any sense were to properly put new stuff
in, ending up with functions related to same object in different files
or with wrong prefixes, declarations of non-existing functions, etc.
because people cannot make up their mind on strict relation to objects
in the data model.
Splitting them in files really helps finding code operating on a
specific object and helping with logically splitting in the future.
Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
In various places that receive an error cause from RSL and place it in
lchan.release.rsl_error_cause, translate it to an RR cause and place that in
the recently added lchan.release.rr_cause. Hence the RR Channel Release message
now reflects more specific error causes when the reason for the error was
received in an RSL message's cause value.
Change-Id: I46eb12c91a8c08162b43dd22c7ba825ef3bbc6ac
In lchan.release, add 'cause_rr', and set RR Channel Release message's cause
value to lchan.release.cause_rr.
In lchan_release(), do not set lchan.release.rsl_error_cause to the RR cause
value, these are unrelated. Store in new lchan.release.cause_rr instead. The
rsl_error_cause is apparently only used for logging, except for one place in
lchan_fsm_wait_activ_ack() that compares it to RSL_ERR_RCH_ALR_ACTV_ALLOC, so
there should not be a functional difference by this fix.
Propagate the BSSMAP Clear Command cause to the RR Channel Release:
Add struct gscon_clear_cmd_data as event data for GSCON_EV_A_CLEAR_CMD -- so
far it sent the is_csfb flag, add the gsm0808_cause; invoking the event happens
in bssmap_handle_clear_cmd().
Adjust event handling in gscon_fsm_allstate(); there, pass the cause to
gscon_release_lchans(). In gscon_release_lchans(), pass the cause to
gscon_release_lchan(), and then lchan_release(), which sets the new
lchan.release.cause_rr to the passed cause value.
As soon as the lchan FSM enters the proper state, it calls
gsm48_send_rr_release(). There, set the cause value in the encoded message to
lchan.release.cause_rr.
Interworking with osmo-msc: so far, osmo-msc fails to set the Clear Command
cause code for normal release, it just passes 0 which amounts to
GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE. Before this patch, osmo-bsc
always sent GSM48_RR_CAUSE_NORMAL in the RR Channel Release, and after this
patch it will receive 0 == GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE from
osmo-msc and more accurately translate that to GSM48_RR_CAUSE_PROT_ERROR_UNSPC.
This means in practice that we will now see an error cause in RR Channel
Release instead of GSM48_RR_CAUSE_NORMAL when working with osmo-msc. For
changing osmo-msc to send GSM0808_CAUSE_CALL_CONTROL instead (which translates
to GSM48_RR_CAUSE_NORMAL), see OS#4664 and change-id
I1347ed72ae7d7ea73a557b866e764819c5ef8c42 (osmo-msc).
A test for this is in Ie6c99f28b610a67f2d59ec00b3541940e882251b
(osmo-ttcn3-hacks).
Related: SYS#4872
Change-Id: I734cc55c501d61bbdadee81a223b26f9df57f959
Up to 16 SI2quater are multiplexed; each fits 3 EARFCNS, so the practical
maximum is 48 (of course depending on how many bits are used by other SI2quater
elements).
Change-Id: Iabeed10053ee5899b4def3509aedd25abb2410a9
Starting from ttcn3-bsc-test-sccplite build #777, it was noticed
that osmo-bsc crashes with the following message:
Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376
The cause of this is a recently merged patch that calls conn_get_bts() during
assignment_fsm rate counter dispatch:
"Count assignment rates per BTS as well"
commit b5ccf09fc4
Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a
The root cause being that the assignment_fsm attempts to count an Assignment
event for a BTS after the lchan has already been released and disassociated
from the conn.
The assertion is found in conn_get_bts(), which is used in various places. In
fact, each caller is a potential DoS risk -- though most are in code paths that
are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the
relatively volatile presence of an lchan is not a good idea for osmo-bsc's
stability and error resilience.
- Change conn_get_bts() to return NULL in the lack of an lchan.
- Adjust all callers of conn_get_bts() to gracefully handle a NULL return val.
- Same for cgi_for_msc() and callers, closely related.
Here is a backtrace:
Program received signal SIGABRT
pwndbg> bt
0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376
0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758
0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325
0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257
0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260
0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291
0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953
0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6
0x0000555555b61bbe in _start ()
In the case of the assignment_fsm counter, we now miss a chance to increase a
BTS counter for a failed Assignment, but this is a separate problem. The main
point of this patch is that osmo-bsc must not crash.
Related: OS#4620, OS#4619
Patch-by: fixeria
Tweaked-by: neels
Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
If the BTS downlink CCCH (PCH + AGCH) queue is full, it sends
us an RSL DELETE INDICATION. So far, osmo-bsc logs this as
<0004> abis_rsl.c:2026 Unimplemented Abis RSL TRX message type 0x14
which is not very helpful. Instead, make the log message more
descriptive and add a rate counter for monitoring.
Change-Id: I9bd2966db90e39ccca442d6bc9abc91e9a9147d4
Closes: OS#3190
Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f
(osmo-ttcn3-hacks).
Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
As in 3GPP TS 23.236, to offload an MSC, the BSC must be able to avoid
attaching new subscribers to it:
4.5a.1: "UEs being moved from one CN node are stopped from registering to the
same CN node again by an O&M command in BSCs and RNCs connected to the pool."
Change-Id: I6249201c15d0f6565aca643c21d2375c9ca58584
Use the new osmo_mobile_identity API to shed some code dup and simplify.
gsm48_paging_extract_mi() is now unused, drop.
(More refactoring to use osmo_mobile_identity follows in subsequent patch.)
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore)
Change-Id: Id6cccaac64392b737b3bba8f3a22a88009adb23b
This adds the assignment counters for the BTS as well and changes the
assignment_count() macro to increase both the counters for the BSC as
well as the BTS.
Related: SYS#4877
Change-Id: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Prepare for MSC pooling by NRI. Before introducing actual NRI decoding and MSC
matching, fix the bsc_find_msc() implementation.
(Indicate the places relevant for NRI by "TODO" comments).
bsc_find_msc() puts an MSC to the end of the internal list of MSCs when it was
used. This has problems:
- Modifying the list affects VTY output, e.g. 'show running-config' and
'show mscs' change their order in which MSCs are shown, depending on how
often a round-robin selection has taken place.
- Emergency calls and normal calls potentially pick quite different sets of
eligible MSCs. When the round-robin choices between these sets affect each
other, the choice is not balanced. For example, if only the first MSC is
allow_emerg == true, every emergency call would reset the round-robin state
to the first MSC in the list, also for normal calls. If there are regular
emergency calls, normal calls will then tend to load more onto the first few
MSCs after those picked for emergency calls.
Fix: Never affect the ordering of MSCs in the internal list of MSCs. Instead,
keep a "next_nr" MSC index and determine the next round-robin target like that.
Keep a separate "next_emerg_nr" MSC index so that emergency call round-robin
does no longer cause normal round-robin to skip MSCs.
Further problems in current bsc_find_msc():
- The "blind:" label should also do round-robin.
- The "paging:" part should not attempt to use disconnected MSCs.
- Both should also heed NRI matches (when they are added).
Fix: instead of code dup, determine Paging Response matching with an earlier
Paging Request right at the start. If that yields no usable MSC, continue into
the normal NRI and round-robin selection.
The loop in this patch is inspired by the upcoming implementation of MSC
pooling by NRI, as indicated by the two TODO comments. The point is that, in
the presence of an NRI from a TMSI identity, we always need to iterate all of
the MSCs to find possible NRI matches. The two round-robin sets (Emergency and
non-Emergency) are determined in the same loop iteration for cases that have no
or match no NRI, or where a matching MSC is currently disconnected.
Change-Id: Idf71f07ba5a17d5b870dc1a5a2875b6fedb61291
The separate struct osmo_bsc_data is like another separate struct gsm_network
for no reason. It is labeled "per-BSC data". These days, all of this is a
single BSC and there will not be different sets of osmo_bsc_data.
Drop struct osmo_bsc_data, move its members directly into gsm_network.
Some places tested 'if (net->bsc_data)', which is always true. Modify those
cases to rather do checks like 'if (net->rf_ctrl)', which are also always true
AFAICT, to keep as much unmodified logic as possible in this patch.
Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
Another legacy feature. All that this setting effectively does is prevent MSCs
from being contacted for non-emergency calls. To select which MSCs shall handle
emergency calls, there is the allow_emerg flag.
Change-Id: I7fc630d9c35be9a69a0d378d3de2b2312c69690d
The BSC is the wrong network component to originate USSD messaging, as can be
seen in the hacks in the USSD code: for example, the BSC would send a CM
Service Accept message as if an MSC had accepted the connection, dispatch a
USSD and directly send some RR release message (without proper tear down
messaging like the lchan_fsm does these days). This made sense in the osmo-nitb
world, but by now we are aiming for solid 3GPP compliance. The BSC shall not
originate USSD messages.
Deprecate all VTY and CTRL commands related to USSD:
VTY
[no] bsc-welcome-text
[no] bsc-msc-lost-text
[no] bsc-grace-text
[no] missing-msc-text
(the commands with 'no' are ignored, without 'no' lead to an error)
CTRL
ussd-notify-v1
Drop (already unused) ussd.h.
Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code.
Drop "RF grace" notification, where osmo-bsc was able to notify active
subscribers that the RF was being turned off.
Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
It is not entirely clear to me what this used to do once, but I've stumbled
upon this before. By now I am certain that this is a non-standard legacy
feature. The BSC does *not* redirect connections during CC transactions.
Along with this, a bunch of legacy utility functions can be dropped. All of
this is unused code.
(Preparing for MSC pooling.)
Change-Id: Id54afe8ccf0e11b9121a733224054c9565eafb58
Filtering by IMSI in osmo-bsc is a legacy use case with questionable
usefulness. Remove.
Do not keep deprecated VTY commands: those could be dangerous, since
(presumably non-existing) users might assume that the filtering would still be
in place. Rather fail to start osmo-bsc for config with an IMSI ACL.
The IMSI filtering did, if present, provide the logging with an IMSI to print
for the bsc_subscriber. TMSIs should have ended up in logging likewise, which
has never been implemented. The proper way to learn the IMSI would be by the
Common Id message from the MSC. Furthermore, the upcoming MSC pooling feature
will extract the mobile identity again, and will hence make sure that both IMSI
and TMSI identities, as available, end up in the bsc_subscriber and will be
logged again.
So long, IMSI ACL, and thanks for all the fish.
Change-Id: I89727af5387e8360362e995fdee959883c37d89a
The bsc_msc_data->rtp_base has been unused ever since we introduced the exernal
MGW in osmo-bsc [1]. The vty command also still exists. Deprecate the vty
command, remove the member.
[1] "mgcp: use osmo-mgw to switch RTP streams"
commit 39c609b7c9
Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a
Change-Id: Id14fa3066ca5d472a817593074a6222f159168a8
We decode the mesage and print it to the log files at ERROR log level.
We also count it in the BSSMAP message counters. There is not much
else we could do about it.
Depends: If8afd2d096fb66c6c2f255a08fc1129de3d09cec (libosmocore)
Change-Id: Ib4cd94f185f751b2384842222678ff671ac413c4
This is a corner case but still we should count the events to
know when is this happening. And for the number of paging requests
to match the number of paging responses.
Change-Id: I1755be40d29980b75353cb4b8087d1ce0d92854a
We already have counters for Rx side, now we also count Tx side.
See comments in the msc_ctr_description array implementation for
the details.
Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
It's useful to know how many BTS are actually configured to compare
it to a number of connected BTS's.
Change-Id: I41cb60f9cb962003227e4a7b63db05acbcdb6f4c
Currently only supports a single MCTR with fixed configuration
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I96b8bb2c01c05bf153fc924f62bd6aafa96725ee
Starting from G12R13 the MCTR swiches to BSC controlled mode. And
although we think we know how to configure it (via MCTR Conf Req),
something doesn't work right and the timeslot configuration is not
accepted. (TS Conf Result shows "Data not according to request").
So as a workaround for now, we use this version of the protocol where
we don't configure the MCTR (it's in "BTS controlled mode") and with
this protocol, the BTS accepts our timeslot config and we can bring
the system up.
This commit add a generic option to limit either OML or RSL IWD
version to any value. It also keeps track of the actual negotation
version so we can react to it in other places of the code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I8f0b0ba72056ea4250fe490e7a38630c77c04f65
better version limit
Change-Id: Ia789f8ede3eab7eeca6c759da0109e0b53398f60
The existing Nokia *Site code destroyed the LAPD SAP instance for OML
while processing an OML message. Once the stack frame returned back
to the LAPD code, the LAPD SAP was gone -> segfault.
Let's work around this by moving deletion of the LAPD SAP out-of-line
by starting a timer 0ms in the future. Not particularly nice, but
effective.
Change-Id: I6270c7210f600e53f845561898245d2fd30a368d
Closes: OS#1761
/usr/bin/ld: bsc_subscr_conn_fsm.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: multiple definition of `mr'; abis_rsl.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: first defined here
See also https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000649.html
Change-Id: Ic21af84f2a6de48d220940f30dad02a0e7683ce8
According to 3GPP TS 44.060, section 12.24, GPRS Cell Options IE
contains two parameters related to 11 bit Access Burst support:
- ACCESS_BURST_TYPE - whether the 8 or 11 bit format shall be
used in the PACKET CHANNEL REQUEST message, the PTCCH/U block,
PACKET CONTROL ACKNOWLEDGMENT and the PS HANDOVER ACCESS
messages on the PRACH (if present).
- EGPRS_PACKET_CHANNEL_REQUEST - whether EGPRS capable MSs shall
use EGPRS PACKET CHANNEL REQUEST message for Uplink TBF
establishment on the RACH or on the PRACH (if present).
The VTY option 'gprs 11bit_rach_support_for_egprs' actually controls
the second parameter - EGPRS_PACKET_CHANNEL_REQUEST, though it may
be hard to understand this from its name and description.
This patch is actually a group of tightly related changes:
- deprecate 'gprs 11bit_rach_support_for_egprs (0|1)':
- update its description to avoid any possible confusion,
- print a warning if it's used in non-EGPRS mode,
- print a warning if it's still used;
- introduce '[no] gprs egprs-packet-channel-request':
- ensure that it can only set / printed in the EGPRS mode;
- take a chance to clean-up / rename the related struct members:
- 'supports_egprs_11bit_rach' -> bool 'egprs_pkt_chan_request',
- remove 'supports_egprs_11bit_rach' from 'gprs_cell_options'
because we already have 'ext_info.use_egprs_p_ch_req' there.
Change-Id: Ied5bd10a806aeeac65ef32339d4ab0e3700e5da9
This dates back to a time where osmo-bsc_nat was in the same repository,
which is a long time ago.
Change-Id: Id965295dfe04f8bd5ce831db70c86f67b8dc290b
Save OML failure reports from each BTS. Add a VTY command to display them
conveniently and optionally clear the list.
OsmoBSC> show bts 0 fail-rep
[2020-03-23 14:51:22] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY
[2020-03-23 14:51:19] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY
Related: OS#1605
Change-Id: I18aa17a721cd5eb1c98926dc2367229c0a50bc78
Separate raw input parsing from handling the failure report. A follow-up
patch will use the new parsing function to print saved failure reports
to the VTY.
While at it, put struct tlv_parsed inside struct nm_fail_rep_signal_data
instead of a pointer, so we don't need an additional alloc. Also add
error handling to the abis_nm_tlv_parse() call.
Related: OS#1605
Change-Id: Ia51004faf620aa4d40435d58c70d758c9d0054d8
Refuse to start with mutually exclusive codec settings, unless
allow-unusable-timeslots is set in the network section of the config.
The checks were already implemented and fill the error log if the config
is invalid.
Related: OS#3739
Change-Id: I3ccfc3b0a8641400cb97a23b24d7ed92d2ad25cd
OM2000 is not only used for the venerable RBS2000 family, but also
for the more modern RBS6000 family, specifically the DUG 20 GSM
baseband unit.
In RBS6000, there are some protocol extensions which are not yet fully
understood. However, we are understanding some bits around the MCTR
(multi carrier transceiver?), a new MO that appears to be present for
every physical RUS (Radio Unit) attached to the DUG 20.
Let's add what we have learned so far.
Thanks to Sylvain Munaut for his help with this.
Change-Id: Ib868358eca12b94c4fcca58e94ec8ab1a4edfda2
Let's not just pass around the raw msgb, but also all other metadata,
such as the decoded parts of the TS 12.21 message.
As there's no current consumer of that signal, this creates no
compatibility issues.
Change-Id: I5d4d9d422b4e23348ffbe69c6e87a31d5574f90d
As per 3GPP TS 45.002, section 3.3.2.3, and table 3 of clause 7,
the following limitations apply mapping of CCCH/BCCH channels:
- TS0/C0 shall be configured as CCCH/BCCH (optionally combined);
- combined CCCH (CCCH+SDCCH4) can only be used on TS0;
- additional CCCHs can be on TS2, TS4, and TS6;
- additional CCCHs are not allowed if TS0 is combined.
Let's make sure that OsmoBSC is properly configured before starring.
Change-Id: I758ef80f7884ba35cdf59d671ee30222ffb9d68b
In addition to transmission of the ETWS Primary Notification via all
dedicated channels, we also need to send it to the BTS for transmission
via PCH (P1 Rest Octets) and for forwarding to PCU for PACCH
transmission.
Change-Id: I7e45b0373458a4348b12b92dd92861062532548b
As soon as we have received an ETWS primary notification message from
the CBC, we should transmit it as "RR Application Information" to all
dedicated channels.
Change-Id: I913d0237cffdcb95037da8489acef5f32a7fc02e
This adds code to handle CBSP (Cell Broadcast Service Protocol)
from the CBC (Cell Broadcast Centre), as well as BSC-internal data
structures for scheduling the various SMSCB on the CBCH of each BTS.
There are currently one known shortcoming in the code: We don't yet
verify if keepalives are received within repetition period.
Change-Id: Ia0a0de862a104d0f447a5d6e56c7c83981b825c7
Fix neighbor config to match OsmoBSC manual: implement the plan for neighbor
configuration that was so far only described in the manual without actually
being in operation.
This first allows re-using ARFCN+BSIC pairs in and across BSS.
So far the handover_start() code always looked for handover target cells across
*all* local cells, even if they were not listed as neighbors to a source cell.
Imply all cells as neighbors only as long as there are no explicit neighbors
configured. As soon as the first 'neighbor' line appears in a 'bts' config,
only the listed neighbors are regarded as handover target cells. (The
'neighbor-list' commands are not related to this, only the relatively new
'neighbor (bts|lac|cgi|...)' commands affect actual handover procedures.)
TTCN3 tests TC_ho_neighbor_config_1 thru _7 play through the various aspects of
neighbor configuration: both the legacy implicit all-cells-are-neighbors as
well as allowing only explicit neighbors by config.
Related: OS#4056
Related: osmo-ttcn3-hacks Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc
Change-Id: I29bca59ab232eddc74e0d4698efb9c9992443983
The struct member struct bsc_msc_data->is_authenticated is set to true
permanently. This is a leftover from the sccplite implementation and can
be removed now.
Change-Id: I966a48b383c85345c92c9a1fec791150e96cd7b9
Related: OS#3112
It's quite ugly to have manual "bts=%d" printf-statements all over
the BSC code. Let's change this to use shared logging helper functions
all over the place, whenever we need to log something related to one
BTS or one TRX.
This can also help us as the first step to later add alternative logging
of BTS identities, e.g. by printing the Cell Global Identifier or
LAC+CI, or even a human-readable/vty-defined 'name' of the BTS, rather
than its numeric bts number. With this change in place, we can
introduce such changes at a single location in the code.
Change-Id: I4a7814d164384eecfb6913c31802cf2faead6e6c
Clarify some in-code comments.
Fix descriptions of some handover timers, which still talked of "MO" and "MT"
handover -- which we now call "inter-BSC out" or "inter-BSC in" instead.
Change-Id: I8429a830edd0325893ac90f22fcc05309617bd2d
bsc_clear_request() is in fact used only within gsm_08_08.c, make it static to
that file.
Since the gscon FSM, "real" BSSMAP Clear are sent only by gscon_bssmap_clear().
bsc_clear_request() remains in use for legacy code paths in gsm_08_08.c:
- the bsc_filter, i.e. for IMSI filtering;
- in move_to_msc(), from handle_cc_setup(), a code path that is in fact not
entirely clear to me. It seems to be an old functionality to serve multiple
MSCs?
Both of which I personally haven't seen in use, are not tested and should
probably be completely removed.
For now contain legacy code in the static context.
Adjust comment.
Change-Id: Ic89d0afad42e4b11183a13d2dc6b7bbf0b822fd9
Old osmo-bsc-sccplite already supported this, but in the migration
over to libosmo-sigtran and to real 3GPP AoIP, this functionality
got lost.
We now create a UDP proxy socket. Any MGCP commands received via IPA
from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on
this socket. Any responses back from the MGW received on the UDP
socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA
multiplex.
Closes: OS#2536
Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
The library has the declarations since 2011, so it's time to
get them removed from here.
Depends: libosmocore d61d517a2e35f482519561bd325652ee7144679a
Change-Id: I5c8d02605a78c6792f616ad423b4491b83f42545
Having the helper makes it easier to read/find for transport type checks. It
will be ifurther re-used in forthcoming commits.
Change-Id: Ic0ee4c472e29ec3092049e5e23b744395613616d
Add a new VTY command "ccch load-indication-threshold <0-100>"
by which the user can configure the threshold after which the BTS
shall send CCCH LOAD IND. It used to be hard-coded to a
default value of 10.
Change-Id: I059fe4627438e26a06e00d84e342b736ab7af440
Now that OsmoBTS understands about extended CBCH, let's at least
update the BSC side function to allow for other code to generate
such messages.
Change-Id: I77a16b75ce311d63fb022475c8ff25fbbcee7f55
The Osmux CID obtained from the MSC is passed to the co-located BSC MGW
to configure the MSC-side MGW conn of a call leg.
Depends on: osmo-mgw.git I73b4c62baf39050da81d65553cbea07bc51163de
Change-Id: I86e7e13fc7921e3209fb764c0e7797e7ec09b79e
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is
done establishing. For AoIP, the local RTP address towards the MSC already
needs to be known before the Handover Request Acknowledge is sent, so the AoIP
Transport Layer Address IE can be included. This patch only modifies the
handover FSM, a subsequent patch adds the IE.
Change-Id: I00c18b78573386145af71c4b39f7f22aec24579b
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
Originally merged as Change-Id I4c7499c8c866ea3ff7b1327edb3615d003d927d3,
reverted because the change broke voice calls. Re-submitting with the fix:
don't forget to set conn->assignment.requires_voice_stream.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I7513d2cbe8b695ba6f031ad11560c63a6535cf2d
osmo-mgw.git also includes fixes of the MGW endpoint FSM, for example
I92a9944acc96398acd6649f9c3c5badec5dd6dcc.
Depends: I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I03e6b48d9b0a5370310d5f56809259ff7909cf9d
Move the T_defs API to libosmocore as osmo_tdefs: remove the local T_defs API
and use libosmocore's osmo_tdef* API instead.
The root reason is moving the mgw_endpoint_fsm to libosmo-mgcp-client to be
able to use it in osmo-msc for inter-MSC handover.
When adding osmo_tdef, the new concept of timer groups was added to the API. It
would make sense to apply group names here as well, but do not modify the VTY
configuration for timers. The future might bring separate groups (or not).
Depends: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 (libosmocore)
Change-Id: I66674a5d8403d820038762888c846bae10ceac58
This reverts commit 94c9324fe0.
Multiple ttcn3 handover tests were broken due to this commit. Let's
merge this once all the other commits pertaining to that fix can be
merged as well.
Fixes: OS#3942
Change-Id: I01d93778fb19c601c21f99ec4d2a3ab8a4a48f67
This variable does not seem to be used anywere in OsmoBSC, seems to be a
remnant from OpenBSC times.
Change-Id: I5e4aa352fa5f16f6ff64738f25afd1a844fa4fcb
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is
done establishing. For AoIP, the local RTP address towards the MSC already
needs to be known before the Handover Request Acknowledge is sent, so the AoIP
Transport Layer Address IE can be included. This patch only modifies the
handover FSM, a subsequent patch adds the IE.
Change-Id: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff
During inter-BSC-incoming, the MSC sends the chosen encryption algorithm in the
Handover Request message. Actually parse this Chosen Encryption Algorithm IE.
Place the chosen algorithm and the CK into lchan_activate_info->encr so that
the new lchan will use the same ciphering on this new BSS as it did on the old
BSS.
Change-Id: I5b269f50bd2092516bfdf87746196983d3ac49d1
For intra-BSC handover, the previous encryption is copied from the old lchan,
which of course is not available during inter-BSC handover. Hence the lchan
activation info needs to include an explicit encryption information, and we
must not rely on the presence of the previous lchan to copy encryption
information from.
Add struct lchan_activate_info.encr to allow passing encryption info through
lchan_activate() without requiring a previous struct gsm_lchan to be present.
Instead of copying from the old lchan, always copy encryption info to
lchan_activate_info, and during activation, just before sending the Channel
Activation, copy the lchan_activate_info.encr to the new lchan.
This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which
obtains the encryption information from an intra-BSC-incoming Handover Request
message.
Related: OS#3842
Related: I5b269f50bd2092516bfdf87746196983d3ac49d1
Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
MGCP/SDP provides fmtp parameters in order to signal which of the two
available AMR framing modes (octet-aligned or bandwith-efficient) should
be used on the link between BSS and core network. osmo-bsc currently
does not set up this mode which means that the RTP packets from the BTS
are forwared without inspection/modification, which may lead to
malfunction when a BTS is using a framing mode that is not supported by
the other end.
- Add VTY option to setup the framing mode
- Generate related fmtp parameters in SDP
Depends: osmo-mgw I622c01874b25f5049d4f59eb8157e0ea3cbe16ba
Change-Id: If6d40b2407b87aad2227ea7f15533ef01a3771b3
Related OS#3807
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 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
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
* 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
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
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
The idea is to have a base static value which is set like before "timer
t3113 [seconds]", but now have a part of this timeout calculated
dynamically based on BTS channel configuration and channel load.
This patch only implements initial support to calculate based on channel
configuration, but doesn't include code to calculate based on channel
load. To implement the later part, we probably need to keep track of BTS
paging queues per paging group, which we don't do nowadays.
Dynamic calculation is enabled by default, and default static base value
is decreased accordingly. This way, in a typical setup were the default
10 seconds were used, now the calculated final value is 11 seconds.
That's intended because it was observed experimentally in osmo-gsm-tester with
a similar channel setup that sometimes paging response can arrive slightly
later than 10 seconds.
Related: OS#3680
Change-Id: I4fb2969b690151415038631fb6ad059aa6835c7f
It will be used further in follow-up patches. It also provides a place
to document its (intricate) logic around it and its possible uses.
Change-Id: Ia1d4bdbfca6b9719f54ee609b6bfadf7f3a4bb43
Set flag lchan->activate.immediate_assignment_sent to true when sending, and
omit a reject after that.
lchan->activate gets completely zeroed in lchan_reset(), which sets that flag
back to false whenever an lchan becomes inactive.
Related: OS#3709
Change-Id: I9ad094d272254d7aee9b0a676201d4ed8cd727ca
Add LCLS variant where the loop is closed on BTS level instead of
MGW. The main difference is the handling of connection-related
messages (we use IPA RSL instead of MGCP), the configuration and
correlation logic remains the same.
Change-Id: I7e8379f31037f2c48da69a01919701919a3066a2
Related: OS#3659
In preparation for upcoming LCLS changes we have to split IPA RSL MDCX
generation into separate function with the ability to set destination
explicitly instead of just using the value from lchan which will be used
in follow-up patches.
Change-Id: Iffe2f4f10e841fc36965cce02b4e5f017a5ae6c8
Related: OS#3659
This signal can be used for tools willing to request and parse Attribute Response
and do something with the information. ipaccess-config tool will use
this signal in later patch Change-Id Ida416a969a3309868d6f4e50f34b34f224c32dd6.
Related: OS#3624
Change-Id: I9a121bbfe1b96904d4e16845abc90bb6ef20d2c9
Some nanoBTS firmwares (if not all) are known to not work properly with
SI2ter. If BSC enables SI2ter through RSL, SI3 bit announcing SI2ter
available will be forwarded by nanoBTS to MS, but will still only send
SI2 message instead of expected SI2ter during TC=5 (see GSM 05.02 sec 6.3.4 "Mapping
of BCCH data"). As a result, some MS won't allow registering to the
network.
To avoid this kind of scenario, enable force-combined-si by default on
nanoBTS while still allowing to overwrite the feature through VTY. Other
BTS models are kept with force-combined-si disabled by default as
usually, since they seems to be working fine when SI2ter is enabled.
Related: OS#3063
Change-Id: Ide6e8967de0eedc9e2bcaf4414aaa537b009d72d
Put all lchan release related flags and settings in a sub-struct named
'release' to better indicate what those fields are for. There is no functional
change.
Change-Id: Icfddc6010e5d7c309f1a7ed3526b5b635ffeaf11
If an lchan is being released and had a SACCH active, there is no reason to
omit the Deact SACCH message ever. All of the callers that passed
do_deact_sacch = false did so for no good reason.
Drop the do_deact_sacch flag everywhere and, when the lchan type matches and
SAPI[0] is still active, simply always send a Deact SACCH message.
The do_deact_sacch flag was carried over from legacy code, by me, mainly
because I never really understood why it was there. I do hope I'm correct now,
asserting that having this flag makes no sense.
Change-Id: Id3301df059582da2377ef82feae554e94fa42035
After commit [1], the code makes sure to disassociate lchan and conn before
invoking the lchan release. However, we only send RR Release if a conn is
present, which clearly is nonsense after [1].
[1] commit 8b818a01b0
"subscr conn: properly forget lchan before release"
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Manage sending of RR Release via a flag, set during invoking lchan release.
Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In
lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care
whether a conn is still associated (because it won't ever be since [1]).
That way we can intelligently decide what release process makes sense (whether
the lchan terminates the subscriber connection or whether the connection goes
on at another lchan), and still disassociate lchan and conn early.
BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the
f_expect_chan_rel() don't care whether an RR Release happens or not. This is
being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845.
So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear.
Related: OS#3413
Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
The function cgi_for_msc() provides an easy way to get a cell global id
for an msc/bts combination. This function is currently statically
defined in gsm_08_08.c. Lets move it to gsm_data.c and make it publicly
available.
Change-Id: I301fac6e83a429ae59b5c586aa283ad7ba54053d
Related: OS#3645
These indicators are a legacy of early handover_decision_2.c work, where there
were no separate handover1 and handover2 config commands. No need to restate
the abundantly obvious anymore.
Change-Id: Id4d29542f7dd5bd125d6f10c7783569f13092612
Print IDs and IPs of recently rejected BTS devices. Example output:
OsmoBSC> show rejected-bts
Date Site ID BTS ID IP
------------------- ------- ------ ---------------
2018-10-25 09:36:28 1234 0 192.168.1.37
Related: OS#2841
Change-Id: Iba3bfe8fc9432b7ae8f819df8bd71b35b3ec507e
The function gsm48_multirate_config() generates the multirate
configuration IE, that is sent via RSL to configure the active set of
AMR codecs inside the BTS. The function already works, but it does not
check the input data for consistancy. Lets add some consistancy check to
make sure that inconsistant parameters are rejected. Also allow the
output pointer to be NULL, so that the function can be used to perform
a dry run to be able to verify parameters.
- Check for invalid / inconsistant configuration parameters
- Perform a dry-run when lv pointer is set to NULL
Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4
Related: OS#3529
The function check_codec_pref() currently only does a basic check over
the general codec configuration of bts and msc. However, it does not yet
check if the amr codec rate settings for the BTSs contradict the
allowed/forbidden amr codec rates of the MSC. When the two settings do
contradict AMR would not work, even when everything else is correctly
configured. We need to check this on startup to spot configuration
problems quickly.
- Add function to calculate intersections of struct
gsm48_multi_rate_conf variables.
- Calculate the intersection between the multi rate config of
each BTS with the one of the MSC
Change-Id: I3537d1c89e2520d35cc0e150ba8e6d3693e06710
Related: OS#3529
In networks with a couple of different BTSs it may be likely that one
accidently sets up a codec configuration (codec-support)) that will be
mutually exclusive towards the codec configuration for the MSC
(codec-list). We need a check that validates the configuration before
start to catch such configuration flaws quickly.
- Add a check that checks each MSC codec-list against each BTS
codec-support setting.
Change-Id: Ice827896bab1a2330741e0fccc731a04f1a07d38
Related: OS#3625
Opposed to all other codecs that are common in GSM, AMR requires a codec
configuration that is expressed by a bitmask (S0 to S15) in the speech
codec list in the ASSIGNMENT REQUEST. Also the BSC acknowledges those
configuration in the ASSIGNMENT COMPLETE message.
At the moment osmo-bsc ignores all incoming configuration bits. The bits
in the ASSIGNMENT COMPLETE speech codec (choosen) field are hardcoded.
- Store the configuration bits while parsing the ASSIGNMENT COMPLETE
- Create an intersection with the configuration that is actually
supported by the BSS
- Return the resulting (chosen) configuration bits with the assignment
complete message.
- Use the (highest of the) agreed codec rates in RSL channel activation.
Change-Id: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
Related: OS#3529
The COMPLETE LAYER 3 INFORMATION message lacks the Codec List (BSS Supported)
information element. This information element is mandatory for networks
that use an IP based user plane (AoIP).
- Add function to generate the speech codec list from the current codec
settings (Available codecs)
- Generate and embed information element in L3 Compl. message
Depends: libosmocore I4e656731b16621736c7a2f4e64d9ce63b1064e98
Change-Id: Id6f2af3fdab45bf05f06aec03e222734d7a4cf70
Related: OS#3548
If the MSC sends a BSSMAP Classmark Request, send an RR Classmark Enquiry to
the MS.
(The reverse direction, i.e. sending a BSSMAP Classmark Update back to the MSC,
is already implemented.)
Related: OS#3043 (A5/3 encryption)
Related: osmo-ttcn3-hacks Idaab4d568cf986b4897ba008f6262c839d1592fb
Change-Id: If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf
Remove unused gsm_subscriber_connection.user_plane.chan_mode.
There is only one VTY command that displays it along other
parameters, but it is used no where else. Lets remove it.
It was forgotten to be removed in:
commit 31f525e756
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
change-id I82e3f918295daa83274a4cf803f046979f284366
Change-Id: I10049c14ea206a4daafbdad01634d57c72a79d7c
Remove unused member gsm_subscriber_connection.user_plane.full_rate.
It was forgotten to be removed in:
commit 31f525e756
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
change-id I82e3f918295daa83274a4cf803f046979f284366
Change-Id: I3a14efe0039ff4690e27e3b083eb23c1b2a616c3
In case a given channel combination contains a CBCH, it replaces sub-slot 2
with a CBCH, i.e. we must not attempt to allocate the same for SDCCH.
On timeslot initialization, immediately place such an lchan FSM into new state
LCHAN_ST_CBCH, so that it never appears unused and never is picked during
lchan_select(). Also set lchan->type = GSM_LCHAN_CBCH.
Verified by configuring CBCH timeslots and watching 'show lchan summary'.
Immediately after RSL and OML are up, these pchan types show lchan 2 in state
CBCH:
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
With a 'phys_chan_config ccch+sdcch4+cbch' and three phones simultaneously
requesting USSD, I see:
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 0, Type SDCCH, State ESTABLISHED - L1 MS Power: 14 dBm RXL-FULL-dl: -53 dBm RXL-FULL-ul: -47 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 1, Type SDCCH, State ESTABLISHED - L1 MS Power: 30 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 3, Type SDCCH, State ESTABLISHED - L1 MS Power: 16 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm
With 'phys_chan_config SDCCH8+CBCH' and three phones simultaneously attaching,
I see:
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 0, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 1, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 3, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
i.e. in all cases the CBCH lchan remains occupied and is not allocated as
SDCCH.
Detaching and re-attaching the BTS reliably brings back the CBCH state. Also
verified that changing the osmo-bsc config from telnet vty and dropping oml
followed by the BTS re-attaching brings back the CBCH state.
Change-Id: I2bafc5f696e818e38f8907ad0c8f38494df0623d
gsm48_lchan2chan_desc_as_configured() is similar to gsm48_lchan2chan_desc(),
but uses the *configured* channel combination, rather than the currently
active one.
Change-Id: Id4043218fb770e8420f19a4ef9428680ecdfd286
Related: OS#3532
The function is defined in gsm_data.c, so it should be declared
in gsm_data.h and not in gsm_04_08_rr.h
Change-Id: I5200063fb43c857a984ea8e41a8485d796e49cde
The flag lchan->activate.concluded prevents entering the
lchan_on_fully_established()/lchan_on_activation_failure() more than once. So
far it was checked by callers, instead place in the functions themselves.
There is a potential functional change here, since during lchan_fail(), the
concluded flag was set only after entering lchan_on_activation_failure(). Now
it is already set at the start and prevents multiple re-entry beyond doubt.
This patch is not a result of an actual observed faulty behavior, just from
reading the code and seeing the slight loophole.
Change-Id: I0c906438b05442d66255203eb816453b7193a6d8
Use libosmo-mgcp-client's new X-Osmo-IGN header to indicate that CallIDs are
allowed to mismatch.
Add VTY commands 'msc' / 'mgw x-osmo-ign call-id' and 'no mgw x-osmo-ign' to
switch this behavior explicitly.
For SCCPlite MSCs, unless a specific config was issued, always send
'X-Osmo-IGN: C' by default, to ignore CallID mismatches.
Depends: Id7ae275ffde8ea9389270cfe3db087ee8db00b51 (osmo-mgw)
Change-Id: I257ad574d8060fef19afce9798bd8a5a7f8c99fe
ipaccess_drop_oml was being called inside an osmo_fd cb context, were
-EBADF must be returned if the structure holding the osmo_fd is freed.
In the middle of the path (see OS#3495 for path tree) it goes through a
signal dispatch, so it's impossible to make sure we return some value to
the osmo_fd cb. As a result, it is required to defer dropping the OML
Link from current code path and do it through a timer.
Fixes following ASan report:
20180822124927913 <0004> abis_nm.c:787 OC=RADIO-CARRIER(02) INST=(00,00,ff): CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed
20180822124927913 <0004> osmo_bsc_main.c:186 Got CHANGE ADMINISTRATIVE STATE NACK going to drop the OML links.
20180822124927913 <0015> bts_ipaccess_nanobts.c:406 (bts=0) Dropping OML link.
...
=================================================================
==17607==ERROR: AddressSanitizer: heap-use-after-free on address 0x62e000060a68 at pc 0x7f5ea8e27086 bp 0x7ffde92b6d80 sp 0x7ffde92b6d78
READ of size 8 at 0x62e000060a68 thread T0
#0 0x7f5ea8e27085 in handle_ts1_write input/ipaccess.c:371
#1 0x7f5ea8e27085 in ipaccess_fd_cb input/ipaccess.c:391
#2 0x7f5ea9147ca8 in osmo_fd_disp_fds libosmocore/src/select.c:217
#3 0x7f5ea9147ca8 in osmo_select_main libosmocore/src/select.c:257
#4 0x555813ab79d6 in main osmo-bsc/osmo_bsc_main.c:922
#5 0x7f5ea76d02e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#6 0x555813ab84e9 in _start (/bin/osmo-bsc+0x34d4e9)
Fixes: OS#3495
Change-Id: I7c794c763481c28e8c35dc9b11d27969e16feb3c
The intention was to use the file's basename, but __BASE_FILE__ means "the root
file that is being parsed and contains #include statements".
If we had a function using __BASE_FILE__ and that was defined in an #included
file, __BASE_FILE__ would indicate the first file where the #include is, and
not the file where the function is defined. __BASE_FILE__ works for us because
we don't ever include function definitions that log something, so __BASE_FILE__
always coincides with __FILE__ for our logging; but still __BASE_FILE__ is
semantically the wrong constant.
Related: OS#2740
Change-Id: Ic6d9dafc96c9d467ae53be2cd41adcf26a4e5125
Harald Welte
Philipp Maier
Pau Espin
Neels Hofmeyr
Vadim Yanitskiy
Daniel Willmann
Sylvain Munaut
Oliver Smith
Martin Hauke
Neels Hofmeyr