when an emergency call arrives while all TCH are busy, the BSC should
pick an arbitrary (preferably the longest lasting) call / lchan and
release it in favor of the incoming emergancy call.
The release of the existing call is a process that can not be done
synchronously while the ChanRQD is handled sonce multiple messages are
exchanged between BTS and MSC and multiple FSMs need to do their work.
To be able to release one lchan while handling a ChanRQD a queue is
implemented in which the incomming channel requests are collected. The
queue is checked regulary for incoming requests. If one of the requests
is for an emergency call and if all channels are busy one channel is
picked and released. It is also made sure that the incoming emergency
call directly gets the TCH that was just released.
Change-Id: If8651265928797dbda9f528b544931dcfa4a0b36
Related: OS#4549
osmo-nitb supports the modification of an lchan if the lchan is
compatible but in the wrong mode. This feature was dropped in the
transition to AoIP/bsc-split. However, osmo-bsc still has code to
generate and parse the messages, but the FSMs do not support a mode
modify yet
Lets add handling for mode-modify to the lchan_fsm and assignment_fsm in
order to support mode modify again
Change-Id: I2c5a283b1ee33745cc1fcfcc09a0f9382224e2eb
Related: OS#4549
The functions lchan_fsm_allstate_action, lchan_fsm_allstate_action and
lchan_fsm_cleanup are only used internally in lchan_fsm.c, lets make
them static
Change-Id: If1ceb69d14a7840e1f753b0dd911726257125e99
There are some preperations and checks done before calling
lchan_mr_config(), those checks could also be done from inside
lchan_mr_config(), so lets merge them into lchan_mr_config()
Change-Id: I068aadda53b2c3a85ed4fb1e513b17bf9870bd50
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
Philipp Maier
Daniel Willmann
Pau Espin
Vadim Yanitskiy
Harald Welte
Neels Hofmeyr