Make sure that in generate_si4() we do not corrupt other SI buffers
by limiting maximum length of the Mobile Allocation to 2 octets.
This would preserve at least 2 octets for the Rest Octets, what
should be enough to encode at least GPRS Indicator.
Change-Id: I2e3553865096faecda6bb22fc25b83fd47b738c4
Related: SYS#4868, OS#4545
If for instance "mgw remote-ip ::1" is configured, the MGCP IPA proxy
socket towards the MGW will use ::1 as the destination address, but it
was being created as AF_INET. Let's use AF_UNSPEC instead and let
osmo_sock_init2 decide the best socket type to create.
Moreover, change the default local address from "0.0.0.0" to NULL to
also let osmo_sock_init2 pick an IPv6 address if necessary.
Change-Id: Ide88c7358a38702ef11c84145518794e75870ef8
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. If
an emergency call is established while all channels are busy, an
arbitrary lchan is picked and freed. When freeing the lchan is done,
the queue is checked again and the emergency call is put on the free
lchan (TCH/H or TCH/F).
Change-Id: If8651265928797dbda9f528b544931dcfa4a0b36
Related: OS#4549
According to 3GPP TS 44.018, table 10.5.2.21.1 "Mobile Allocation
information element", in the cell allocation frequency list the
absolute RF channel numbers are placed in increasing order, except
that ARFCN 0, if included in the set, is put in the last position.
This basically means that the last bit of the Mobile Allocation
(MSB on the wire) corresponds to ARFCN 0, if it's included in
the cell allocation frequency list, or the last channel otherwise.
Recently introduced TTCN-3 test cases uncover the following problems:
a) ARFCN 0 is encoded twice: as MSB and LSB of the bit-mask,
b) ARFCN 0 is encoded one bit off its expected location.
Change-Id: I264a66a1405e72940a79e9e20ad6ad8f269a7bbc
Related: SYS#4868, OS#4545
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 messeages, but the FSMs do not support a mode
modify yetm
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
In commit [1], I replaced the way the CBSP link is configured in the VTY. But
that configuration was already part of a release, hence I should only have
deprecated the old commands. Re-add the legacy config as deprecated.
Try to make the legacy commands take a similar effect as they previously would
be intended for, i.e. switching to server/client/disabled modes, and take
effect immediately when commands are read from telnet.
[1] 641f7f0845
Icaa2775cc20a99227dabe38a775ff808b374cf98
"CBSP: rewrite the CBSP link setup and 'cbc' VTY section"
Related: OS#4702
Change-Id: If6b742f28191b3f19ff1d87a217037a305133f4b
According to 3GPP TS 44.018, section 9.1.36.2, the CBCH Mobile
Allocation IE shall be present if CBCH Channel Description IE
indicates frequency hopping. For some reason it was missing.
This change makes BSC_Tests.TC_fh_params_si4_cbch pass.
Change-Id: I8dce506a07d9d291b631b44fa2177c9deff6aa88
Related: SYS#4868, OS#4545
A similar problem has already been fixed in [1]:
- include GSM48_IE_MA_AFTER instead of GSM48_IE_MA_BEFORE,
- fix position of the Mobile Allocation (after time) IE.
This problem was uncovered by (not yet merged) TTCN-3 test case
verifying handling of the hopping parameters [2]. This change
makes it pass.
[1] I43ef66c109b107ebcaa1cb6197637701b13b3787
[2] BSC_Tests.TC_fh_params_handover_cmd
Change-Id: I7569eead9760b6fd4bb91fc2d8d0b8200bebe374
Related: SYS#4868, OS#4545
IPACC protocol supports only IPv4 addresses, so make sure if an IPv6
address (or whatever malformed address) is caught is not sent without
noticing. Prior to this patch, faulty addresses would be sent over the
wire as 255.255.255.255 (-1 returned from inet_addr()).
Change-Id: Iee84e8b40cdede1cacd8e8a9e26dda0d85383ec8
If the feature is not enabled there's no real use in displaying default
values for it.
Related: SYS#4912
Change-Id: I759eb0c31dd3c9b6f5f3d2bf57c6efc9ac5f74f1
Restart the CBSP link from the VTY only from telnet sessions, not when reading
in the config file. When reading the config file, link startup might happen too
early and twice -- rather rely only on the CBSP startup invoked from main().
This is fixing a bug introduced recently in
"CBSP: rewrite the CBSP link setup and 'cbc' VTY section"
commit 641f7f0845
Change-Id Icaa2775cc20a99227dabe38a775ff808b374cf98
Change-Id: Ia0bb507c8468048789a446df09185ad8565c5ad8
Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the
test passes for the wrong reason. The ambiguous cell identification should be
the cause for the handover error, but the log shows that instead a handover is
attempted to BTS 3 which is not connected.
find_handover_target_cell() first tries to find a precise match of values, and
in a second pass applies wildcards like BSIC_ANY and
NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous
matches.
Use the same code for both passes, by encapsulating in a loop of two, which
first runs with exact_match == true and then false.
Proper detection of the ambiguous target cell identification in
TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count,
see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks).
Related: OS#4736
Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks)
Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1
An inter-BSC-OUT handover ends with a Clear Command, which HO_OUT_ST_WAIT_CLEAR
waits for. Actually tell the handover_fsm.c about an incoming Clear Command, so
that the inter-BSC-OUT success can be counted.
Similarly, count failing handover results for an unexpected Clear Command from
the MSC.
Related: OS#4736
Change-Id: I0c489838a99f930e2104619ca745191d2a736f1b
During handover cleanup due to a Clear Command from the MSC, do not send
another Clear Request to the MSC. Only send that when no Clear Command was
received yet.
Add a flag rx_clear_command per gscon instance, indicating whether a Clear
Command was received, and exit early in gscon_bssmap_clear() when true.
This is part of patches fixing the rate counters around handover, which uncover
some bugs:
- Another patch enables proper handover result handling when receiving a Clear
Command.
- After that, the handover_end() handling would always cause sending a Clear
Request, even if a Clear Command was already received.
- This patch removes the extraneous Clear Request, for this scenario and for
all other corner cases that might still exist.
Related: OS#4736
Change-Id: Iab82cac0a7ffa7d36338c8ff7c0618a813025f13
So far, during inter-BSC outgoing handover, when receiving an RR Handover
Failure from the MS, it would be counted as 'error'. Instead, add the 'failed'
counter like for all other HO types.
It may make sense to omit the 'failed' counter for inter-BSC *incoming*
handover, because then we won't receive an RR Handover Failure message. I
probably got those two mixed up during initial development.
Related: OS#4736
Change-Id: I9a61d5cc7273a830ba4e66e43e4aac6cdb707471
To handle cases of unknown handover type (like failure to find the target
cell), return -1 as counter code; treat -1 as skipping in ho_count_bsc() and
ho_count_bts().
The handover:* counters indicate overall counts, without knowing whether inter-
or intra-BSC, or whether the target ARFCN even exists. So they need to be
counted separately, and must not serve as fallback category in
result_counter_bsc() and result_counter_bts().
Related: OS#4736
Change-Id: Ie311e599d7bd35d33cf471c6c63e649246e8396a
Move initial 'handover:attempted' counts from bsc_subscr_conn_fsm.c to
handover_fsm.c, where all the other counters are handled.
Add missing increments for the overall 'handover:*' counts.
Related: OS#4736
Change-Id: I783bdedafc0eb8f2df9ea100792846fecc7ccbf7
Currently osmo-bsc encodes the IAR Rest Octets as follows:
IAR Rest Octets
0... .... = Extended RA: Not Present
.0.. .... = Extended RA: Not Present
..1. .... = Extended RA: Present
...0 1011 = Extended_RA: 11
0... .... = Extended RA: Not Present
.L.. .... = Additions in Rel-13: Not Present
Padding Bits: default padding
This is not really critical, but still may look confusing as this
is only relevant for the PS domain (11-bit RA), while osmo-bsc is
responding to a CHANNEL REQUEST in the CS domain.
Change-Id: I30a43efc70345a4bb0571127c239a24422b7fd2c
Firstly, make CBSP server and client mutually exclusive: Do not allow osmo-bsc
to be configured as CBC client *and* CBC server at the same time.
cbsp_link.c expects at most one CBSP link to be established, and, upon sending
CBSP messages, probes whether to send the message to a CBSP server or client
link. When both listen-port and remote-ip are configured (regardless of an
actual CBSP connection), osmo-bsc gets confused about where to send CBSP
messages.
One solution would be more accurate probing for an actual established TCP
connection. But the simpler and less confusing solution is to force the user to
configure only server or only client mode, never both.
Introduce 'cbc' / 'mode (server|client|disabled)'.
Secondly, clarify the 'cbc' config structure into distinct 'server' and
'client' subnodes. Refactor the 'cbc' VTY node in such a way that the IP
addresses for server and client mode can remain configured when the CBSP link
is switched between server/client/disabled modes.
To implement the above, switch the struct bsc_cbc_link to use osmo_sockaddr_str
for address configuration.
Related: OS#4702
Related: I7eea0dd39de50ed80af79e0f10c836b8685d8644 (osmo-ttcn3-hacks)
Related: I9e9760121265b3661f1c179610e975cf7a0873f1 (docker-playground)
Change-Id: Icaa2775cc20a99227dabe38a775ff808b374cf98
As 3GPP TS 48.058 clearly states, an RLL RELease INDication is only
sent if the datalink is released by the MS. Thre's no cause value
giving further diagnostics, but if the MS releases the link, it is
clearly not the BSS's fault, and hence "BSS not equipped" is wrong.
Change-Id: I38222e60071841abcd06046a472ddb35907164a4
Related: OS#4728
The tx TRAP callback is triggered through a signal which is never sent in
osmo-bsc code, and never was as far as I can tell going quite far in the
logs.
In the meanwhile, the msc_connection_status was left in favour of
multi-msc msc.X.connection_status CTRL variable, so let's prepre the cb
function to work for that onei too, dropping global variables which may lead
to wrong output in multi-msc environments, and simply use msc->nr==0 for
the old variable "msc_connection_status".
The signal is now triggered in a_reset when the A conn becomes connected
or disconnected. As a result, a user waiting for the disconnect event
may notice that the status may be changed with a noticeable delay, since
the A conn may be reset only due to high layer timeouts after several
repeated failures (T4, BAD_CONNECTION_THRESOLD).
Related: OS#2623
Related: OS#4701
Related: SYS#5046
Change-Id: I645d198e8e1acd0aba09d05cb3ae90443946acf8
"127.0.0.1" is changed to "localhost" to let local NSS decide whether to
use IPv4 or IPv6. In newish systems, IPv6 ::1 will be selected since
IPv6 takes precedence over IPv4.
Similarly, the default source addr needs to be changed from NULL to "localhost"
since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns
first IPv4 "0.0.0.0" and later "::", which is inconsistent with
getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and
dst=IPv6(::1), which is incompatible and will fail. In any case, since
the default remote address is a local one and it's the client side,
there's no real logical change since the kernel would anyway should have
taken a local address anyway.
Change-Id: Ic93be6c47403e65b7c338604728570f23bc3de12
Normally, each ETWS CMD instructing to broadcast triggers a five second
etws_timer to send a zero-payload ETWS CMD that stops broadcasting, five
seconds later. Before this patch, this lingered past an ETWS RESET instruction.
Instead, clear the etws_timer on ETWS RESET, and make sure that all ETWS PN
broadcast is stopped by sending a zero payload ETWS CMD to the BTSes
immediately.
This will cause all CBSP ttcn3 tests to fail unless
Ifee313369a433a6a638c5fffdedee5363b8e47c2 is merged to osmo-ttcn3-hacks at the
same time.
Related: Ifee313369a433a6a638c5fffdedee5363b8e47c2 (osmo-ttcn3-hacks)
Change-Id: I925a041936c6163483d70fe6d158af368ec8c444
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
In some (error-) cases we might be unable to determine which BTS to use
when counting handover events. We don't want to loose these events
because then ctr(bsc) == sum(ctr(bsc->bts)) would not be true anymore.
Those events are now counted by a counter in struct gsm_network which
uses an index that is out of range for regular BTS (65536).
Change-Id: Ic0f3edd5dc014c4eac5e8423133633a3e5d4c13e
Related: SYS#4877
Currently the counters don't distinguish between intra-cell and
intra-bsc handover.
Add _CTR_INTRA_CELL_HO_ and _CTR_INTRA_BSC_HO_ counters to track
intra-cell/bsc handover separately.
Change-Id: I3a1195640b99813036c9f1426ee5f07548e26547
Related: SYS#4877
Our current handover counters only count success/failures per BSC. It
would be nice to also count which BTS is part of a (successful/failed)
handover.
This patch duplicates the BSC counters for the BTS and changes the
ho_count and related macros to also count per BTS. If a BTS is NULL
(when conn->lchan is NULL) counting for the BTS is ignored.
Change-Id: I025ef14e2cfd2eea8880212c9406372ce0bf9296
Related: SYS#4877
by reading the code, I notice that a refcount on the subscr would be leaked if
there were no bts. That is not realistically happening, but nevertheless rather
rejigger so that no leak is possible, ever.
Change-Id: I0b804b8136cd78a777ca02667f696cdefa90c4a9
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
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
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
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: Ia5a656567d212fa265aef1375d714d0c5fee5dd6
We don't want to fprintf directly, and we want to make sure to always
log as much context as possible.
Change-Id: I29ec935669175a08cb42e1666559b681c50a6e72
When we introduced the timeslot FSMs in
I82e3f918295daa83274a4cf803f046979f284366, the BS-11 stopped to work, as
the timeslot FSMs are never brought out of NOT_INITIALIZED stage.
Closes: OS#4666
Change-Id: I557cb105247552887ca47a0f2c1b06b71bca6cac
There are a number of OML messages which are not seen on IP based
BTSs. Those are perfectly normal and expected on E1 based BTS.
Change-Id: Icd87fc9f3652b21f9d569af2572d080c9ac89e8b
Closes: OS#4665
In rest_octets.c append_earfcn(), the unconditional bits added are 40, not 25.
Removing only 25 bits from the budget resulted in malformed SI2quater starting
with 4 configured EARFCNs, by adding more EARFCNs than fit in 20 bits.
These malformed SI2quater were also expected in gsm0408_test.c. Update the
expected SI2quater to what is being generated now. This patch passes the ttcn3
testing added in I45382f88686ca60e68569e93569fc4cfb63a0e0d, which provides some
confidence that the coding expected in gsm0408_test.c is now correct.
Related: OS#4652
Change-Id: I5df269f713456a6ccbb874d6b7faac4a6f123c67
According to 3GPP TS 44.018, section 9.1.2.4, if at least one of
the Channel Description IEs indicates frequency hopping, one and
only one of the following IEs shall be present:
- Mobile Allocation, after time (see 10.5.2.21);
- Frequency List, after time (see 10.5.2.13).
For some reason, osmo-bsc includes the GSM48_IE_MA_BEFORE instead
of GSM48_IE_MA_AFTER - fix this.
According to section 9.1.2.6 of the same document, if any of the
Mobile Allocation IEs (before/after time) is present, then the
network must ensure that either the MS has already received the
the proper reference cell frequency list (CA), or that the Cell
Channel Description IE (see 10.5.2.1b) is present.
Without this IE, the phone I was using in my testing setup sends
RR Status message with cause #100 "conditional IE error".
Fortunately, we already have generate_cell_chan_list(), since we
also need to include the Cell Channel Description in SI Type 1.
Change-Id: I43ef66c109b107ebcaa1cb6197637701b13b3787
Related: SYS#4868, OS#4545, OS#4546
Refactor osmo_bsc_sigtran_init(): invoke osmo_sccp_simple_client_on_ss7_id()
exactly once per cs7 instance.
When introducing MSC pooling to the ttcn3-bsc-tests, it became apparent that
osmo-bsc rapidly huts down and re-creates the SCTP link for each configured
MSC. This manifested in an osmo-stp crash (fixed in libosmo-sccp
I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa). I first tried to fix it by only
restarting an ASP when it wasn't found in the AS yet, but that created obscure
problems described in OS#4635 which in turn completely broke ttcn3-msc-tests.
This solution keeps osmo_sccp_simple_client_on_ss7_id() unchanged and instead
invokes it exactly once per cs7 instance.
Keep the same auto-config logic, but change and improve the mechanisms to
achieve it:
Replace the fail_on_next_invalid_cfg flag with a more accurate check against
remote PC collisions between configured MSCs. Before this patch, the code made
sure that at most one MSC lacks an explicit remote address (and cs7 instance),
so that no two MSCs get the same default remote PC. This patch more accurately
checks that no two MSCs use the same remote PC on the same cs7 instance,
period, whether implicitly or explicitly configured.
Before this patch, the logic amounted to creating cs7 instance 0 implicitly,
but it was not very obvious: If an 'msc' has an msc-addr configured, it is
associated with the cs7 instance that has this addr in its address book. If it
has no msc-addr configured, then msc->a.cs7_instance_valid == false. In that
case, msc->a.cs7_instance is still 0 (from talloc_zero) and hence
osmo_sccp_simple_client_on_ss7_id(ss7_id = 0) created cs7 instance 0. In this
patch, that logic remains unchanged, but is written out more explicitly: if any
msc has no cs7 instance associated, make sure to create cs7 instance 0
beforehand.
Then iterate all osmo_ss7_instances. If at least one MSC uses it, set up the
SCCP client on it and connect all MSCs as appropriate.
Related: OS#4625 OS#4635
Change-Id: I16f4f7f447f69525a2f57c4649ab295112904d6a
The IPACC protocol is an extension to the conventional RSL protocol
to negotiate ip address and port for RTP/VoIP. This protocol is BTS
specific (sysmobts, ip-access nanobts) and not used with E1 BTSs
The bsc VTY is able to trigger certain IPACC functions for debug
purposes. Some of those commands do not check if the BTS is really of
type IP-access before trying to send an IPACC command. Let's add
checks to prevent IPACC messages to be sent to E1 or otherwise
incompatible BTSs models.
Change-Id: I9ee78b6b1d342abaccc09a87dee6af79e76e5468
Related: OS#2547
According to 3GPP TS 48.058 (version 15.0.0), section 9.3.5, the
3GPP TS 24.008 "Mobile Allocation" shall for compatibility reasons
be included but empty, i.e. the length shall be zero. Therefore,
no matter if frequency hopping is in use or not, send it empty.
Change-Id: Ie224a45f10522332eac653fa371564f022108c3f
Related: OS#4545, OS#4546
In the state LCHAN_RTP_ST_WAIT_MGW_ENDPOINT_CONFIGURED, the event
LCHAN_RTP_EV_ROLLBACK is allowed and also handled in the action
callback, which causes a change to LCHAN_RTP_ST_ROLLBACK. However,
LCHAN_RTP_ST_ROLLBACK is missing from the out_state_mask.
Change-Id: Ifca3892901c8389beee6e4f0fea03c33cfbdc265
We assume the SI shall be re-sent because something has changed. This
means that change_mark should be incremented. Let's call
gsm_bts_set_system_infos() which already does the trick.
Change-Id: I73d9bd3cddc561f3a7af8bcc225fac126dca3f78
Closes: OS#3679
This recently merged patch introduced a new bad segfault in bsc_compl_l3() by
dereferencing conn->sccp.msc before it was set to the actual msc pointer:
commit 6281d4f869
"fix crashes due to OSMO_ASSERT(conn->lchan)"
Change-Id Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
Fix that by moving the new checks back further down in bsc_compl_l3(), to where
conn->sccp.msc actually points at the msc.
Change-Id: Ic5832da7c58fce583caa504a90f18c334fc234f2
Found while playing with "rf_locked 1" on a 2TRX setup with channel
allocator descend. After applying the setting, the 1st TRX is still used
to allocate the channels. After this patch is applied, the BSC correctly
allocates channels from TRX0.
Change-Id: I5201d2749363c9cbd0706177bde09117b163cbe3
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
osmo-bts (in combination with osmo-pcu) has been supporting paging
for CS services via PCU/PACCH for a very long time. Let's make sure
this is reflected by the correct BSS_PAGING_COORDINATION bit.
Change-Id: I0e80ca5afc06737273b6699bde6e325e454b57f6
Requires: libosmocore.git Ifb2e83eaf05dd36e5b203ed2de1a74864b039e38
Related: OS#2406
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
Particularly on BS-11 with only one TRX installed, this will improve
the output of bs11_config from
PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: unknown 0x8 Abis-link: Down
to
Change-Id: I10a77315d537681985f8390b838a4cabfb7d27f3
PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: Not equipped Abis-link: Down
For historical reasons we had bsc_vty.c and osmo_bsc_vty.c. Ever since the
osmo-nitb split, there is no reason to keep these files separate. Merge
osmo_bsc_vty.c into bsc_vty.c (because osmo_bsc_vty.c is smaller).
I noticed this particularly because adding the NRI configuration required
adding things like #define NRI_STR in two separate files: once for the
'network' level vty, and once for the 'msc' level.
Change-Id: I7fd2ee631b22e38f3d96d8159dc1deaaca6a7013
This message may contain optional IEs (HSN, MAIO, ARFCN list),
so we cannot know the final length in advance. Let's set both
msg->{l2h,l3h} pointers and use msgb_l3len() to get the length.
Change-Id: I948ad4b847921324794a6eabd95d5583324da6e4
Related: OS#4545
3GPP TS 12.21 defines coding of 'ARFCN List' attribute as follows:
+---------------------------+--------------------+
| Attribute Identifier | 1st octet |
+---------------------------+--------------------+
| Length | 2-3 octets |
+---------------------------+--------------------+
| ARFCN1 | 4-5 octets |
+---------------------------+--------------------+
| ... | ... |
+---------------------------+--------------------+
| ARFCNn | (n * 2 - 3) octets |
+---------------------------+--------------------+
so this is basically TL16V, where L16 is the length of V.
In the Siemens dialect of OML coding rules are different though:
+---------------------------+--------------------+
| Attribute Identifier | 1st octet |
+---------------------------+--------------------+
| ARFCN count | 2nd octet |
+---------------------------+--------------------+
| ARFCN1 | 4-5 octets |
+---------------------------+--------------------+
| ... | ... |
+---------------------------+--------------------+
| ARFCNn | (n * 2 - 2) octets |
+---------------------------+--------------------+
so this is TCV, where C is the amount of ARFCNs in V.
This change fixes encoding of 'ARFCN List' for other dialects,
in particular encoding of the 'Length' field (1 vs 2 octets).
I verified the results in Wireshark (generic 3GPP TS 12.21
and ip.access dialect), everything looks good.
Change-Id: Iec1826f55459ac8e9355328a1a6bb0949874db60
Related: OS#4545
Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f
(osmo-ttcn3-hacks).
Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
In the ttcn3 tests, the MSC round robin algorithm is affected by what tests ran
before, so an osmo-bsc test needs this to reset the round robin to get
predictable behavior to test against.
Change-Id: I2155d906505a26744966f442ffb1e87a6a9b494c
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
At this time, no MSC has been selected for handling this subscriber, so DMSC is
clearly the wrong logging category.
Change-Id: I9c6373e5f28c9c69a0609889188ef28ade11da3d
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
Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: I316efedb2c1652791434ecf14a1e261367cd2fb7
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 value of the feature vector can not only be greater, but also
shorter than size of the buffer! This would potentially result
in a buffer overrun. Let's fix this.
Change-Id: I65e3228022865ea73de2e4821985df3097b9448b
This is unlikely to cause any problems, but having a NULL-pointer
that can potentially be dereferenced is dangerous. Fix this.
Change-Id: Icf594604f69023d1483e897edb811e51774b5b8e
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
Tweak return code handling: also return a failure code when dispatching the
GSCON_EV_A_CONN_REQ event failed.
Change-Id: I939e8a9a865250033e4837439a6b9ec251e5ce4c
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
Whether to forward the message or not to an SCCP connection is
an internal question for the GSM 04.08 code. Unlike errors with
the message decoding, memory allocation and other critical errors,
this not an error which should be reported to the caller.
abis_rsl_rx_rll() (the caller) shouldn't know about the message
routing decisions and should only care about actual errors.
This code path is hit in production very often because we frequently
receive a Classmark Change message from a phone right after the MSC
has shut the SCCP connection but before we close the lchan on the BTS.
Change-Id: I2d430ebc894a2345bebaa1841a75e94a3b45eae2
conn->fi might be NULL and thus can't be safely dereferenced.
E.g. we're checking if it's NULL or not just a few lines above. so we
should here as well.
Here is a backtrace for the crash:
(gdb) bt
0 0x000055b948002772 in gscon_forget_lchan (conn=0x55b949c6b870, lchan=lchan@entry=0x7f00ae9ade68) at bsc_subscr_conn_fsm.c:718
1 0x000055b948036c84 in lchan_fsm_wait_rf_release_ack_onenter (fi=<optimized out>, prev_state=<optimized out>) at lchan_fsm.c:1040
2 0x00007f00afc6a599 in state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, keep_timer=keep_timer@entry=false, timeout_ms=2000, T=3111, file=<optimized out>, line=1344) at fsm.c:699
3 0x00007f00afc6aa5d in _osmo_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, timeout_secs=<optimized out>, T=<optimized out>, file=<optimized out>, line=<optimized out>)
at fsm.c:748
4 0x00007f00afc78e62 in _osmo_tdef_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, state=state@entry=8, timeouts_array=timeouts_array@entry=0x55b9482b56a0 <lchan_fsm_timeouts>, tdefs=<optimized out>,
default_timeout=140730455622800, default_timeout@entry=5, file=file@entry=0x55b948079d39 "lchan_fsm.c", line=1344) at tdef.c:346
5 0x000055b9480341eb in lchan_fsm_timer_cb (fi=0x55b949bcfe10) at lchan_fsm.c:1344
6 0x00007f00afc6b84a in fsm_tmr_cb (data=0x55b949bcfe10) at fsm.c:325
7 0x00007f00afc65926 in osmo_timers_update () at timer.c:257
8 0x00007f00afc65cda in _osmo_select_main (polling=0) at select.c:260
9 0x00007f00afc66526 in osmo_select_main_ctx (polling=<optimized out>) at select.c:291
10 0x000055b947fdcadf in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953
(gdb) p conn->fi
$1 = (struct osmo_fsm_inst *) 0x0
Change-Id: I2427266ef4660935cde899462fa6df8d785c420e
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
osmo-bsc has crashed with the following backtrace:
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007f0bc49b38db in __GI_abort () at abort.c:100
2 0x00007f0bc581ba30 in osmo_panic () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
3 0x00005648ceeced69 in conn_get_bts (conn=<optimized out>) at ../../include/osmocom/bsc/gsm_data.h:1392
4 0x00005648cef37164 in conn_get_bts (conn=0x5648cf769e80) at osmo_bsc_filter.c:87
5 bsc_patch_mm_info (conn=conn@entry=0x5648cf769e80, data=<optimized out>, length=<optimized out>) at osmo_bsc_filter.c:48
6 0x00005648cef371b6 in bsc_scan_msc_msg (conn=conn@entry=0x5648cf769e80, msg=msg@entry=0x5648cf77ead0) at osmo_bsc_filter.c:159
7 0x00005648cef33988 in dtap_rcvmsg (msg=0x5648cf72b2f0, length=40, conn=0x5648cf769e80) at osmo_bsc_bssap.c:1215
8 bsc_handle_dt (conn=conn@entry=0x5648cf769e80, msg=0x5648cf72b2f0, len=40) at osmo_bsc_bssap.c:1299
9 0x00005648cef3b2b7 in handle_data_from_msc (msg=<optimized out>, conn=0x5648cf769e80) at osmo_bsc_sigtran.c:152
10 sccp_sap_up (oph=0x5648cf72b378, _scu=<optimized out>) at osmo_bsc_sigtran.c:267
11 0x00007f0bc5813c03 in _osmo_fsm_inst_dispatch () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
12 0x00007f0bc51a8935 in sccp_scoc_rx_from_scrc (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scoc.c:1695
13 0x00007f0bc51a62f3 in scrc_rx_mtp_xfer_ind_xua (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scrc.c:459
14 0x00007f0bc51a9545 in mtp_user_prim_cb (oph=0x5648cf7681f8, ctx=0x5648cf6a8d60) at sccp_user.c:182
15 0x00007f0bc51a09c6 in m3ua_rx_xfer (xua=0x5648cf764a80, asp=0x5648cf45f540) at m3ua.c:586
16 m3ua_rx_msg (asp=asp@entry=0x5648cf45f540, msg=msg@entry=0x5648cf71e880) at m3ua.c:739
17 0x00007f0bc51b0763 in xua_cli_read_cb (conn=0x5648cf441ed0) at osmo_ss7.c:1761
18 0x00007f0bc55fab53 in osmo_stream_cli_read (cli=0x5648cf441ed0) at stream.c:232
19 osmo_stream_cli_fd_cb (ofd=<optimized out>, what=1) at stream.c:321
20 0x00007f0bc580edcf in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
21 0x00007f0bc580f526 in osmo_select_main_ctx () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
22 0x00005648ceecfb2f in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953
Apparently, there is no lchan allocated at this moment, so
conn_get_bts() crashes. But we only use it to get to "network" which
we can do much easier and safer by doing conn->network.
Change-Id: Id3f7b3efba60c0f050c1be98e5e539f1dab4cd57
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
Not sure why this specific message is ERROR while similar ones around
are DEBUG. So let's fix this disparity by demoting this message level.
Change-Id: I655d4555f037def354aacbc5f089794f5fe811ed
The "CHAN RQD: reason" message is purely informational and is a part
of normal operation. Nothing to NOTICE there. Let's demote this to
DEBUG.
Change-Id: I325f2beb3248ed8eb25d1d8494c3868c5be4b758
We're sending multiple RESET messages to establish a conection with
an MSC and MSC can (and often will) respond with multiple RESET ACK
messages. We should not treat this as an ERROR as it used to be
in the original code.
Change-Id: I109d638d5167e24f0357e3541415b9e7269aa5d1
The "new SIGTRAN connection" message is sent on every new transaction
between an MS and MSC, i.e. A LOT during normal operation. Let's
demote it to INFO and clarify that this is about SCCP connection
instead of a generic SIGTRAN term.
Change-Id: I711b70ae84aa98f43ea3f807ea5c8464b71ca6bb
"Paging request failed" message can be logged e.g. when we're already
paging this subscriber which means we get hundreds of these messages
in a perfectly normal situation. Let's demote this to INFO and adjust
the wording.
Change-Id: I97214796906ac599338e87b2b4b5465ab6b2447a
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 should be fine if we receive PDCH_ACT_ACK late. We should just go
into the PDCH state as normal.
Change-Id: If816b681e0b2e76fb7122cf211e15eeee92451ee
In the lchan_fsm_borken() we request to change the state to
LCHAN_ST_WAIT_RF_RELEASE_ACK in response to a late
LCHAN_EV_RSL_CHAN_ACTIV_ACK event but this transition is prohibited
by the FSM definition, so the channels stay in the BORKEN state
forever. :(
Change-Id: I17a9b935a116eb842fd0239ef53d73bef35e6511
Explanation from Harald:
There are plenty of things that can happen above the bare SCTP/M3UA
connection which can happen, such as SCCP or MTP level routing
problems.
The fact that a MSC responds to a BSSMAP reset tells us that all of
the underlying SS7 transport network is operational and the MSC
responds to us.
Go draw an IP analogy: Saying "SIGTAN connection up" here is like
saying "Ethernet link up" when you get an ICMP response.
Change-Id: If9d37c94f2f2b6cffef97f445774766993f538db
Parts of Osmo-BSC want to see the NM state as valid ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I0db11819d23e40272c4aa6fd093365b9c13f7bcf
It's useful to know how many BTS are actually configured to compare
it to a number of connected BTS's.
Change-Id: I41cb60f9cb962003227e4a7b63db05acbcdb6f4c
I originally assumed that after a complete scan with llist_for_each_entry
the loop counter would be either NULL or a valid entry. That's just not
the case.
Fixes: CID#210256
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iad647b74771c4ac406a88effd371ed7748c8847e
From the CS perspective, there is no difference whether this is
a dynamic TS in NONE/PDCH mode or a static TCH in UNUSED mode since
BSC can switch into USED mode at any moment. So we should count
dynamic timeslots in the "total" count.
A bit of a challenge here is that GSM_PCHAN_TCH_F_TCH_H_PDCH
timeslots could be either switched to a single TCH/F or to
two TCH/H, so the total can't be calculated reliably beforehand.
In this code we assume TCH/F since this gives a lower total
count.
Change-Id: Iabd70e8adbf15eb3b7a7be597281ea99b352317b
The OM2K link "per-trx" only comes up after MCTR is setup. So that means
we need to wait for it before trying to boot the TRX itself.
He we simply apply a "dumb" 5 sec timeout as this is the most reliable
way I found to get this working reliably.
Tracking the link state proved difficult and unreliable:
- Multiple TRX can be present with their link coming up in random
order.
- They can already be up at the start (BTS already initialized from
a previous boot) and so the link may actually come up, down, and
up again.
- All of theses transitions might happens before/after we get to the
OM2K_BTS_S_WAIT_TRX state depending on how the LAPD timeout
expire, if the BTS config was actually changed or not and how much
time it takes to apply the new config.
So all in all, what we must do is wait for the link to stabilize ...
hence just waiting 5 second.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I55a06e08b9c52ff6e97e8c72f2d55770809eba51
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
* OM2K_DEI_FREQ_SPEC_RX:
(hop << 15) | (rx_addr << 10) | arfcn
. hop Hopping marker
. rx_addr is not really the TRX number, it's just a sequential number
different for all TRX, doesn't need to be 'in-order' of TRX
. arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency')
* OM2K_DEI_FREQ_SPEC_TX:
(hop << 15) | (tx_id << 10) | arfcn
tx_id Pretty much same as rx_id except here we know that the order
doesn't have to match TRX order. It seems to even vary from one
reboot to another on some real-world capture we got.
. hop Hopping marker
. tx_addr Same as 'rx_addr' above but for TX
. arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency')
* OM2K_DEI_FREQ_LIST:
Groups of 3 bytes (24 bits), 1 per frequency used.
(tx_addr << 20) | (rx_addr << 16) | (is_c0 << 10) | arfcn
. tx_addr See above
. rx_addr See above
. is_c0 Must be 1 if that ARFCN hosts the C0. (first TRX of a MCTR)
. arfcn The ARFCN number
(Note MAIO must also be set properly on the different TRX/TS sharing
a frequency ... )
The way we generate theses here is what we gathered from real-world
traces:
- Each 'TX' of each TRX is set to the ARFCN set in that TRX config
- Each 'RX' of each TRX is configures as 'hopping'
(which I assume means it will just pick the appropriate freq ?)
- For each TS, we use :
. tx_addr of the TRX that has the ARFCN we want to TX on
. rx_addr of the TRX where the TS we're configuring is
. arfcn The actual ARFCN we want to add to the list
This is incomplete but will work for the 1 MCTR case.
Config for multiple MCTR or multiple virtual-bts still need to be
handled but it's not yet known exactly how those need to be
configured.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie39a857543adaa11d1822346d8563ce3718412c8
During the configuration of the TS object through OML we must use
pchan_from_config since it's too early to use anything else.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iecdc911a79b66d8f3d746347710ad697cb288174
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
This is probably a fault report of some kind, but didn't get any
confirmation or naming from anywhere for it yet.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I8333093d09f27f61094c7f5854573aa16e4bf28c
Thoses messages IDs are 16 bits and the upper 8 bits are sort of
important :D
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ifcc1a01fdbf66a0f6f44cf8fed60dc19e72dd56a
* In superchannel mode, those 3 are required.
* In normal mode, "Config Type" is optional and the two others are
forbidden.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: If02d02c067ae8af8ce693ddfb8747212f3f4e441
slashes are invalid so we can't use om2k_mo_name() directly, so we just
build it manually with dashes.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I3cfc19670e6d7bb607d796cabcee5e86a15d1985
Make various internally used timers negative, to indicate that they are
Osmocom specific. A follow-up patch will make them configurable.
Change-Id: I6f8be40ea54a3083f4b21ab938cc1723fc67c2ef
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 logging category has been removed in [1], what caused test
case execution failures on our Jenkins (since build #930). The
problem is that configuration files may still contain this
category in 'logging' section (see [2], [3], [4]), and
osmo-bsc would refuse to start because of that.
[1] Id965295dfe04f8bd5ce831db70c86f67b8dc290b
[2] Ie2afacfc15589c26238214cddc00baaf80e993c1
[3] I266d6f6ed54d1457b1ca63b87fc1c29f6dd40caf
[4] If02272c08ba2df37d1295d09c104d11f96abbe1e
Change-Id: I111362d19aba325889bada5a46eea62343c30033
This dates back to a time where osmo-bsc_nat was in the same repository,
which is a long time ago.
Change-Id: Id965295dfe04f8bd5ce831db70c86f67b8dc290b
If, as before this patch we call initCDKScreen() before
attempting to bind the socket, then the socket bind fails,
we exit and the terminal needs a reset.
Attempt to open the socket before initCDKScreen()
so we don't end up with a messed up terminal if the socket
call fails.
Change-Id: Ia5148d9ef386df314bc2837b3cb672150250bd2a
The measurement tools use libosmocore socket functions that will
use logging if the socket cannot be opened, but the tools did
not initialise logging, resulting in
Assert failed osmo_log_info logging.c:235
backtrace() returned 9 addresses
[.....]
Initialise logging so that we get a nicer and more informative
message, such as:
unable to bind socket:(null):8888: Address already in use
no suitable addr found for: (null):8888
Change-Id: Ib3b3558723682defcee22e7ea2d8bf5c2cff1278
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
Use the extra bts pointer instead of mb->trx->bts, which does not point
to an allocated bts.
Related: OS#1605
Change-Id: Ie61512f5690763fa380bdf0e7fb4763dbda019d2
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
Calling osmo_tdef_vty_write() twice: with and without the 'timer '
prefix definitely looks like a bug. After setting any timer to a
custom (non-default) value, config_write_net() would generate an
incorrect configuration file:
$ osmo-bsc -c /tmp/osmo-bsc.cfg
There is no such command.
Error occurred during reading the below line:
T10 10
Change-Id: I5cc893fb2077bb21f1f661e30a7ab2af1b9bd561
The loglevels of DNM, DFILTER and DPCU are set to low, lets set them all
to NOTICE
Change-Id: I03a5426b341e9908ffc89240f97d6d3ea791b4a8
Related: OS#2577
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
gsm_04_80_utils.c: In function ‘bsc_send_ussd_release_complete’:
gsm_04_80_utils.c:37:9: warning: ‘gsm0480_create_ussd_release_complete’ is deprecated: Use gsm0480_create_release_complete() instead. [-Wdeprecated-declarations]
37 | struct msgb *msg = gsm0480_create_ussd_release_complete();
| ^~~~
CC gsm_data.o
In file included from gsm_04_80_utils.c:22:
/usr/local/include/osmocom/gsm/gsm0480.h:120:14: note: declared here
120 | struct msgb *gsm0480_create_ussd_release_complete(void)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The commit is not changing the existing logic/assumption: TID 0 should
not be in use by anything else at the point the USSD is generated.
Change-Id: I739158dec62cd5f0c2080fbb426af9c024baef87
After sending of NM_MT_IPACC_RSL_CONNECT message, we start a timer,
and stop it on receipt of NM_MT_IPACC_RSL_CONNECT_{ACK,NACK}. When
running a multi-trx setup, one can see the following warnings:
DRSL NOTICE abis_nm.c:2852 (bts=0,trx=1) RSL connection request timed out
DRSL NOTICE abis_nm.c:2852 (bts=0,trx=2) RSL connection request timed out
even despite NM_MT_IPACC_RSL_CONNECT is actually being acknowledged.
The problem is in abis_nm_rx_ipacc(): we cannot just use sign_link->trx,
because the message itself was received over the OML link, so this
pointer always gives us C0/TRX0. Instead, we must find a TRX by its
number from the FOH header using gsm_bts_trx_by_nr().
Change-Id: Ib4b9a198da11c88a51cfa78ffb7e7235a6365ef4
This way we can avoid the runtime overhead of checking whether or not
it is initialized over and over again. It also brings this code more
in line with other users of osmo_fsm_register().
Change-Id: I3c7220491cf6ffb1361e7259c0344df64a013a0a
Since osmo-bsc uses the MGCP client FSMs, it is required to enable this new
feature to guarantee safe operation. The issue is described in detail in commit
logs linked below.
Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore),
I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore)
Related: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 (osmo-mgw)
Change-Id: Ib7fce7b7d54dfb87af97544796680919e5929a50
Lots of times, the MS power class is unknown until after the first
channel has been activated, at which point the MS power class is
received in messages such as LU update or CM Service Requet.
Since the MS Power level is sent upon CHAN ACT, the only way to
communicate the change of maximum MS Power (based on MS power class)
after CHAN ACT is to send a MS Power Control msg. Let's do that.
Related: OS#4244
Change-Id: I3d6b75578e5cb9b2ad474a0ad01362d846ebe135
As can be seen from include/osmocom/bsc/gsm_data.h:
- pchan_from_config - channel configuration from the VTY/config
(can be changed from the VTY at runtime, should not affect
the existing RSL/OML connections);
- pchan_on_init - channel configuration after the OML link is
established (pchan_from_config is copied here);
- pchan_is - the *actual* channel configuration currently active.
Since we call bootstrap_bts() during the initialization, even before
establishing any OML/RSL connections, neither pchan_on_init nor
pchan_is can be used. Let's use pchan_from_config instead.
This change fixes the problem discovered by @mqng2 and reported
together with https://gerrit.osmocom.org/c/osmo-bsc/+/15909:
CCCH_CONF in System Information Type 3 does not reflect the
actual channel configuration, and always indicates a single
CCCH combined with SDCCH. This also misleads the lchan
allocation algorithm during the MO connection establishment.
Change-Id: I8f9d7aa27f24b55732a4de933bc834ed930806fd
Do not count the number of additional CCCHs if TS0 is using combined
channel configuration (CCCH+SDCCH4), because they are only allowed
if TS0 is not combined with SDCCH.
Get rid of the 'switch' statement using the following formula:
CCCH_CONFIG = (N << 1)
where N is the number of additional CCCHs.
Change-Id: I1430500999389e9b30e55ea89a8a5ea5071f7957
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
Since MS Power Param IE content is operator dependant, it's currently
not known which kind of content non-osmocom BTS support/allow, so let's
avod possibily breaking those BTS until each BTS has been checked
separately.
Related: OS#1622
Change-Id: If44121222042bdac06c2a5e70f7b35a88b00b27c
Further accesses will be addter in forthcoming commit, so let's first
store the pointers in variables to clean up the code.
Change-Id: Ie5ea0f44dfb5731cab7e8e5a3dd3d791ee703df7
Vadim Yanitskiy
Pau Espin
Philipp Maier
Neels Hofmeyr
Daniel Willmann
Harald Welte
Sylvain Munaut
Oliver Smith
Keith Whyte
Martin Hauke