During the A-bis/OML bootstrapping, osmo-bsc sends Opstart to the
Radio Carrier MO twice. The first Opstart is triggered by the
State Changed Event Report, originated by the Radio Carrier itself.
The second is triggered by Software Activated Report.
According to 3GPP TS 12.21, figure 2, we shall send it only once,
after the "Attribute setting" step. Therefore, the first Opstart
is premature, and we shall not send it.
Related: SYS#5063, OS#4755
Change-Id: If69393551117266ecb726d8961153560b2b3cc59
Backwards compatibly, introduce timer groups in OsmoBSC, and move some
non-specified T timers to new X timers:
T993111 -> X3111
T993210 -> X3210
T999 -> X4
Why X4? because there already is an X3 used elsewhere in Osmocom, and I find
it less confusing if X-numbers don't repeat across programs. See
https://osmocom.org/projects/cellular-infrastructure/wiki/List_of_Timer_numbers
Drop unused timers from g_mgw_tdefs. Only X2427 has an actual effect.
(libosmo-mgcp-client recently moved T2427001 to X2427.)
Put libosmo-mgcp-client related timers to the 'mgw' group, like in osmo-msc.
This makes the MGCP timeout configurable for the first time.
Keep previous timer commands as DEFUN_HIDDEN, and also translate the moved T
timers to X timers on-the-fly. All previous VTY commands still work, and new
'timer [(net|mgw)] ...' commands are added. timer.vty shows this.
Remove the "_OPTIONAL" from the legacy "timer" and "show timer" commands, so
that they don't ambiguously overload the new "timer [(net|mgw)] ..." commands.
Related: OS#4539
Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw)
Change-Id: I4beec47502afa193dee343869c4be55dc6a4b536
The manual channel activation work in a very hackish way by sending the
CHANNAL ACTIVATION message manually using rsl_tx_chan_activ(). This
means the channel activation is not under FSM control. Also switchover
of dynamic channels does not work.
The lchan_fsm supports an activ_for in its activation info struct. The
header files define a "FOR_VTY" enum value there. However, the lchan_fsm
is not yet prepared to handle this. Lets update the lchan_fsm so that
FOR_VTY is supported and change bsc_vty to use lchan_activate() instead
of calling rsl_tx_chan_activ() directly. This will give us real channel
activation under FSM control.
Change-Id: Iffc57b7a5b7bdde06d392267791fd908e80bbb5d
Related: SYS#4910
Instead of maintaining two variables and re-calculating the bit
position on each iteration, let's use the existing field of the
bit-vector: set it to the first LSB and decrement in the loop.
Change-Id: I1b226a2d5867434c33ae04a0b971dbfd16c4688f
Related: SYS#4868, OS#4545
Before transitioning some unspecified T timers to X timers, and to introduce
timer groups, first add this timer VTY test. Changes here will illustrate that
the legacy commands will still work and redirect to new timer definitions.
Related: OS#4539
Change-Id: Ie1bc635e16dc9a4040d063e1d9a51cdc76d9d1f2
It does not make sense to set the bsc_subscr's LAC from a Paging Request,
especially since the paging code has loops that possibly kick off several
pagings.
At this point, there remains no code setting bsub->lac anywhere. We could set
it during rx of Complete Layer 3, but since there is no use for it besides a
vty dump, let's just drop the bsub->lac completely, and the vty dump of it.
Change-Id: Id017bd494d329b6fc254d7135b4074ac2b224d66
RF-locking: simply ask bsc_grace_allow_new_connection() at the start of
page_subscriber(). Before this patch, we would log an INFO of "Paging request
failed" when RF-locked, for each BTS. Instead log "RF-locked". (An upcoming
patch will introduce a LOG_PAGING() macro that will trivially add more log
context there, so not bothering now.)
Drop LAC condition: since Stefan introduced page_subscriber() starting 2018
Ic3c62ff0fccea586794ea4b3c275a0685cc9326e, matching a requested LAC to a
specific BTS is done *before* calling page_subscriber().
BTW: the msc->core_lac (config 'core-location-area-code') has not had an effect
on Paging maybe ever. I opened OS#4751.
Change-Id: Ic8696414a1db8f4b1be502d6434599f684746ed6
When the measurement bandwidth was added the calculation of the maximum
length wasn't increased.
Fixes: 27a887f666 ("gsm 04.08: encode the LTE neighbors measurement bandwindth in Channel Release")
Change-Id: Ic8132fd988140c34b8e0fd8349f4518fcbaecc31
The VTY already has a method available to activate lchans manually,
however, this method does not support proper activation of signalling
channels. Also additional commands to activate multiple lchans at once
are helpful to make labtesting simpler and more efficient.
Change-Id: I66b874736c8c456eb82ccc26d5209987d8ed706c
Related: SYS#4910
The function reduce_rach_dos() only removes the tossed channel requests
from the list, but does not free them.
Change-Id: I0a62fc897c07e118dd637b156b6f2822c44db731
Related: OS#4549
At the moment expired channel requests are dropped silently, however, it
might help to know when this happens - not only for debugging.
Change-Id: Ib49df551a4cd7d5652e85c8ce29ef132385d4ae4
Related: OS#4549
Encoding missing measurement bandwidth of LTE neighbors in Channel Release
(Cell selection indicator after release of all TCH and SDCCH value part).
The measurement bandwidth was encoded in the neighbors description transmitted in
SI2quater while missing in the Channel Release which would overwrite the
SI2quater measurement bandwidth.
Change-Id: I4847d840ba9d5ac56bd00e4f405dc47792008c0d
The spare bits were never encoded even when the spec says it must be 00.
Most caller of _chan_desc_fill_tail() initialized the struct with memset(),
but not all.
The SI4 did not initialize it.
Change-Id: Ib03d6d2cdadc49e49aa94917d17f81ef3c83f11c
Ensure that osmo-bsc would not continue to work as usual, if for
some reason we cannot encode or send System Information messages.
Introduce transitional state OM2K_TRX_S_SEND_SI, from where we
can generate and send System Information messages. Otherwise
it's confusing if we fail to do something when we're already
in state OM2K_TRX_S_DONE.
Change-Id: Ia6df539d0914c57ea80fdb29882832678b47f267
This is needed to be able to force MGW to provide an IPv4 address during
MDCX, since IPACC protocol on the BTS side only supports IPv4, but one
may need IPv6 side at the same time on the core side.
By moving the IPACC MDCX request to a later step, the BSC gains
knowledge of the local address on each side (BTS, MGW), and if they
don't match (ie. BTS uses IPv4 and MGW uses IPv6), it can then get MGW
to offer an IPv4 address during MGCP MDCX containing the BTS IPv4
address. At that point, the MGW can see the mismatch and provide an IPv4
address in the MGCP MDCX ACK, which can then finally be communicated to
the BTS during IPACC MDCX phase.
Previous order:
BSC -> MGW: CRCX
BSC <- MGW: CRCX ACK (get MGW local IP addr)
BSC -> BTS: IPACC CRCX
BSC <- BTS: IPACC CRCX ACK (get BTS local IP addr)
BSC -> BTS: IPACC MDCX (set MGW IP addr)
BSC <- BTS: IPACC MDCX ACK
BSC -> MGW: MDCX (set BTS IP addr)
BSC <- MGW: MDCX ACK
New order:
BSC -> MGW: CRCX
BSC <- MGW: CRCX ACK (get MGCP local IPv6 addr)
BSC -> BTS: IPACC CRCX
BSC <- BTS: IPACC CRCX ACK (get BTS local IPv4 addr)
BSC -> MGW: MDCX (set BTS IPv4 addr)
BSC <- MGW: MDCX ACK (here MGW changes its local addr to IPv4)
BSC -> BTS: IPACC MDCX (set MGW IPv4 addr)
BSC <- BTS: IPACC MDCX ACK
Change-Id: I4de5ea5c94c1482c9cb0b6386997a942edc60e32
Ensure that osmo-bsc would not continue to work as usual, if for
some reason we cannot encode or send System Information messages.
Change-Id: I7d3458fb10760e33411f2074a6b2df1c257438d5
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
Alexander Couzens
Pau Espin
Philipp Maier
Oliver Smith
Vadim Yanitskiy