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
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
Vadim Yanitskiy
Alexander Couzens
Philipp Maier
Pau Espin