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
Since we verify the cause code of the RSL channel release in ttcn3-bsc-tests,
BSC_Tests.TC_chan_act_ack_est_ind_noreply shows an invalid release cause code
of 127. Fix that.
On gscon timeout, don't send the unrelated RSL code RSL_ERR_INTERWORKING, but a
proper RR cause code. GSM48_RR_CAUSE_ABNORMAL_TIMER is defined as the proper
cause for an expired timer (3GPP TS 44.018 10.5.2.31).
Should fix this error in BSC_Tests.TC_chan_act_ack_est_ind_noreply:
BSC_Tests.ttcn:1590 Dynamic test case error: Assigning invalid numeric value 127 to a variable of enumerated type @GSM_RR_Types.RR_Cause.
Change-Id: Ic2e4b692e78f7b134fe57d1077a08adb48398e06
If a CHAN RQD indicates an emergency call on a BTS that does not allow
emergency calls, then respond with an IMMEDIAGE ASSIGNMENT REJECT
message to deny the emergency call early.
Related: OS#4548
Change-Id: I148c540269bffd703f38233a1e689e863c175e97
Before this patch FSM instances of configured but not connected BTS's
look like this:
FSM Instance Name: 'timeslot[0x612000004a20]', ID: '(null)'
Log-Level: 'DEBUG', State: 'NOT_INITIALIZED'
Now they look like this:
FSM Instance Name: 'timeslot(0-0-7-NONE)[0x612000004a20]', ID: '0-0-7-NONE'
Log-Level: 'DEBUG', State: 'NOT_INITIALIZED'
which makes it possible to attribute them to where they belong.
Otherwise, they look like lingering or leaking unattributed FSM
instances.
Change-Id: Idc74ea142b96323b48826f8a52e13e45d535512a
I beleive MSC split is finished a long time ago and everything is
already re-wired for the A-interface.
Change-Id: If2a0b15e360c44abc92fdeb9004be7ccc0537cdd
If the BSC configuration is set up to deny emergency calls, make sure
that an EMERGENCY SETUP will not be passed to the MSC, instead ensure
that the call is released.
Change-Id: Ia6eb38370ce4165d221d2ffbe1cd105c0628313c
Related: OS#4548
The MGCP endpoint name, that is generated when an E1 endpoint is
selected does have a hardcoded trunk id number, which is permanantly set
to 1. Lets use the E1 line number instead.
Related: OS#2547
Change-Id: Ic5447bb4426e31d119667bdfddfd2c91fd591fc6
The hard-coded per-BTS feature vector for osmo-bts currently lacks
BTS_FEAT_HOPPING, and this is unlikely to change, because only the
recent osmo-bts-trx does support freq. hopping, while the other
(DSP based) back-ends do not seem to be capable of doing it.
Let's allow enabling freq. hopping regardless of the feature vector,
so either it would work if it's supported, or the BTS would reject
Set Channel Attributes message by sending NACK on the A-bis/OML.
Change-Id: Iff23109cacb5d314f7bcbf34b25e89af9281ce40
Related: SYS#4868, OS#4546
Instead of logging a hex value for the met requirements, fully expand the "ABC"
flags for both TCH/F and TCH/H.
From HO_CANDIDATE_FMT/_ARGS, split off into REQUIREMENTS_FMT/_ARGS and use that
when logging the chosen HO candidates.
Also change the RX level to dBm, to match general logging and reduce confusion
between rxlev number variants in the log.
Change-Id: I1b30a6e98bdb4bd92e72864fafdd2f4f3ae3134c
When check_requirements() returns zero, do not keep such an entry in the
candidates list at all. This removes logging confusion, where some "candidates"
are still listed even though not meeting any handover requirements.
Change-Id: I12e48292d5731cb601165c870b9570003bc488ec
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
The functions lchan_rtp_fsm_timer_cb() and lchan_rtp_fsm_cleanup() only
used in lchan_rtp_fsm.c, lets make them static.
Change-Id: I31940aff166ccd7a9612574536674e4e483a3cb9
On a TS 12.21 spec compliant BTS, each Um traffic channel must be mapped
to an E1 sub-slot on the terrestrial back-haul. This happens via
the CONNECT TERRESTRIAL TRAFFIC message.
We always had code to sen that message, but it got deactivated when
ts->pchan_is / ts->pchan_from_config was introduced. Of course,
while we are bringing up OML, there is no 'pchan_is' set yet. We only
have 'pchan_from_config' and must use it.
Change-Id: I8988a027b0e897bd9dda460590f974d6be34a4fa
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
[ 160s] acc.c: In function 'get_highest_allowed_acc':
[ 160s] acc.c:117:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 160s] for (int i = 9; i >= 0; i--) {
[ 160s] ^
[ 160s] acc.c:117:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
[ 160s] acc.c: In function 'get_lowest_allowed_acc':
[ 160s] acc.c:127:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 160s] for (int i = 0; i < 10; i++) {
[ 160s] ^
[ 160s] Makefile:617: recipe for target 'acc.o' failed
Change-Id: I03722854634b2d6d6f1abac7c7553762b5fc6890
The files have been used successfully in the past weeks to bring up a
variety of different combinations of Ericsson DUG20 + RUS.
Change-Id: I046f786d68f7cd3fd21693142bd1315bf40696f5
See updated documentation section in manuals/chapters/bts.adoc regarding
an explanation on how the system works.
Related: SYS#4911
Change-Id: I952c9eeae02809c7184078c655574ec817902e06
The RLL ERR IND is sent by the BTS in any number of casese that lead
to a disconnect of a radio link layer, for example due to bad RF
conditions. The lchan FSM currnently prints error messages about
this event not being permitted, leading to confusion among users.
Let's ignore this event, I don't think the lchan FSM should or could
be doing anything as a result. We could also simply remove that event,
but let's keep it in case we should need it in the future.
Change-Id: I07aad62d25566d6068a95797915bb97fc3c66328
With upcoming next commit, the file will contain far more code that
simply ramping, so rename it to be more generic.
Change-Id: I8c368ab87e264439dea4ccf556821a44664cdbb0
Those adoc files are only used by osmo-bsc.git and openbsc.git
(osmo-nitb), and the later is deprecated and no longer maintained, which
means new features are only added to BSC. Hence it makes no sense to
keep the doc shared between both.
Change-Id: I20aa60d2f4111d66e922f3e2a73a20352ec1f7e4
CentOS is happy with the spec file as-is, but OpenSuSE is more strict:
[ 62s] osmo-bsc-1.6.0.191.bd5b-lp152.1.1.x86_64.rpm: directories not owned by a package:
[ 62s] - /usr/share/doc/packages/osmo-bsc/examples/osmo-bsc/ericsson
[ 62s] - /usr/share/doc/packages/osmo-bsc/examples/osmo-bsc/nokia
[ 62s] - /usr/share/doc/packages/osmo-bsc/examples/osmo-bsc/siemens
Change-Id: I40ad5d38b968db847cf5f733f82163ecac1151e0
The function initializes the struct owned by a bts, so it makes sense to
have it done there instead of somewhere else later.
It was most probably put in bsc_vty when it was initially introduced
because of all the data structure and object file mess I untangled
during last set of patches.
Change-Id: I66c4b208583e92070793183b83b3a7b7edf6ba00
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
3GPP 44.018 10.5.2.1e defines the EARFCNs encoded in the 'Cell selection
indicator after release of all TCH and SDCCH IE' as follows:
<Cell Selection Indicator after release of all TCH and SDCCH value part> ::=
[...]
| 011 { 1 <E-UTRAN Description : < E-UTRAN Description struct >> } ** 0
So after a 3-bit discriminator of '3' there can be multiple E-UTRAN
Descriptions, and each of them starts with a '1' bit to indicate that another
item follows. Finally there is a '0' bit to indicate the list end.
Before this patch, osmo-bsc only encoded the first '1' bit, and failed to
repeat this before each following E-UTRAN Description. Fix that by moving the
'1' encoding into the loop.
The final '0' was missing. Add it.
With these changes, adjust the size calculation in
CELL_SEL_IND_AFTER_REL_MAX_BITS to match.
Also fix CELL_SEL_IND_AFTER_REL_MAX_BYTES by using OSMO_BYTES_FOR_BITS()
instead of the inaccurate (n/8)+1.
A test for this is in I882c5e1f70bcc4833fc837a95c900ce291919cc5
(osmo-ttcn3-hacks).
Related: SYS#4871 SYS#4872
Change-Id: I59e427e4ebb1c6af99b27a15c40fed82457ac8ab
This adds osmo-bsc config files for Ericsson RBS2308, Siemens BS-11 and
Nokia InSite which were working in July 2020 to get the BTS initialized,
recognized by MS and up to signalling.
Voice/TRAU support is still missing in OsmoBSC, but should be added
relatively soon.
Change-Id: I1fe15cc3654025e52fc1110ac3052fb1f7a009a0
Depends: osmo-python-tests I896b99032d94ba0cdd340a8eed7c7b625661ad69
Closes: OS4651
Vadim Yanitskiy
Harald Welte
Neels Hofmeyr
Philipp Maier
Pau Espin