The ra_id as well as the cell_id are already present in struct
gbproxy_cell which is reachable from bvc->cell. Remove the ra_id in
struct gbproxy_bvc and also remove some unused/unneeded code. The FSM
reset_notif callback already takes care of updating the cell.
Related: OS#4894
Change-Id: Ibc9f42a60706612c17e5f8f0468c7faced5ae4c8
Handle SGSN BVCs that are gone from the BSS differently.
The previous patch removed the gbproxy_bvc on the SGSN-side after it was
gone on the BSS-side. This caused a STATUS response to BVC_BLOCK_ACK messages
that should be valid. Instead of removing the BVC this patch marks it as
inactive so we can still handle BVC_BLOCK_ACK correctly, but ignore
other messages - especially BVC_RESET from the SGSN.
Related: SYS#5628. OS#5236
Change-Id: Ic9f34a27412d6e15ca1198ee140f66a076b5c6b6
This patch adds gbproxy_cell_cleanup_bvc() which removes the bvc pointer
to the cell. If the BSS BVC of this cell is removed it frees the whole
cell (removing all the SGSN BVC pointers to the cell). The SGSN-side
BVCs are blocked at this point and will only be reestablished if this
BVC is reset again from the BSS.
Before this patch cells were never freed and might accumulate over time.
They would only be reused if the bvci matched that of a previous cell.
Related: OS#4960
Change-Id: Ib874cbebcea58fa4bf15e1ff40fe11601573e531
This is only used for the imsi cache entries for now. Further uses will
be added in subsequent commits.
Related: OS#4472
Change-Id: I4a4b8c99eb97f6bb5387d0f26aecd861e07d9914
If an SGSN in a pool is down we expect the messages to instead be sent
to a different SGSN in the pool. That SGSN will not necessarily know
what to do with those messages, but it should (implicitly) detach that
UE so that it can reattach at the new SGSN. Otherwise UEs on a failed
SGSN would simply stop working as the messages would never be forwarded
anywhere.
Fixes: OS#4952
Change-Id: I3f794659866e1f31496a39ca631b3b042a60aa27
Prepare tracking the SDU from NS. Initialize with a conservative default.
The value is not yet updated, that will happen in a later patch.
Related: OS#4889
Depends: I5016b295db6185ec131d83089cf6c806e34ef1b6 (libosmocore.git)
Depends: I9bb82ead27366b7370c9ff968e03ca2113ec11f0 (libosmocore.git)
Change-Id: Ic1080abde942ec5a2ae7cdee0ffe716a2fbddb1e
pass raid and cell id directly as parameter to gbproxy_cell_alloc so
that we do not need to fill tas parameter to gbproxy_cell_alloc so that
we do not need to fill the struct members later.
Change-Id: Ic7deae5ccf839b941d70557d28451d52f32cebbb
Related: SYS#5103
Instead of storing the raw ra_id in its unparsed binary form, store it
as a parsed struct. Also store the cell-id on cell allocation for later
use.
Change-Id: Ib58b9188e3ce4bd3fdadb03f158d56b29778387c
Related: OS#4894
Adjust the build system, packaging etc. to split osmo-gbproxy into its
own git repository. Remove tests and configs that aren't related to
osmo-gbproxy.
Related: OS#4992
When SGSN pooling is enabled we need to route some responses based on
IMSI back to the correct SGSN, e.g. PAGING_PS_REJECT.
The IMSI cache keeps track of this IMSI <-> NSE(SGSN) mapping.
Change-Id: If0a8d6cc1d63f2fb2c395cc5d4373a915bc2cb87
Related: OS#4951, OS#4472
When routing a SUSPEND/RESUME we need to keep track of where it came
from so we can send the (N)ACK back to the correct BSS. Use the TLLI
which is present in both messages to cache and retrieve the correct BSS.
A timer runs every two seconds and expires entries that are older than
the timeout (hardcoded to 5 seconds for now).
Related: SYS#4865, OS#4472
Change-Id: I42adf70f560d2bb358a9e1c7614281e8d2967568
This is useful for logging and configuration to identify an SGSN by name
Change-Id: I2a3410dd9bebb242957e13a63ed70e447204203c
Related: SYS#5115, OS#4472
In order to support SGSN pooling we need to configure the various NRI
parameters such as the bitlen, NULL NRI, and which NRIs are assigned to
which SGSN.
Related: OS#4890, OS#4472
Change-Id: Id67592aa7712e5e04e7264b2fb8f26d57eb7e69e
When there are multiple SGSNs inside a pool, we need to decide
how much of the per-BVC capacity advertised by the BSS in its
BVC-FLOW-CONTROL we should announce to each of the pool members.
A conservative approach would be to advertise 1/num_sgsn, but
there may also be use case where over-provisioning (announcing more
than an equal share of the capacity) is useful.
Hence, let's introduce "pool bvc-flow-control-ratio <1-100>" in order
to allow the administrator to decide.
Related: OS#4891
Change-Id: Ibe5addf657e7237499ca0205bacfe999ecd1e771
Rewrite of a large part of osmo-gbproxy in order to prepare
for SGSN pool support. The amount of changes are of such fundamental
nature that it doesn't make sense to try to split this into hundreds
of individual changesets.
Related: OS#4472
Change-Id: Ie0746f17927a9509c3806cc80dc1a31d25df7937
Those features were introduced a long time ago for one specific use
case at one specific user, and they are not needed anymore. They
complicate the code base significantly and are hard to maintain with
all the upcoming modifications regarding SGSN pool supoprt.
Change-Id: Id9cc2e1c63486491ac5bb68876088a615075fde6
For the common lookup-by-bvci, this should reduce the computational
complexity significantly.
Depends: libosmocore.git I8ef73a62fe9846ce45058eb21cf999dd3eed5741
Change-Id: Ic8e9279fd61a3c514fc3203429f36a468f0e81d3
For the common lookup-by-nsei, this should reduce the computational
complexity significantly.
Depends: libosmocore.git I8ef73a62fe9846ce45058eb21cf999dd3eed5741
Change-Id: Idbb6a362332bb6e3ce22102e7409ae80d0980f44
We will soon also have a list of sgsn-side NSEs, and we need to
differentiate those.
Change-Id: If5accec0c70c01b88927ea07beba6f6488bd9d5a
Related: OS#4472
I cannot really read the code while it contains its historical weird
naming. A "peer" used to be a strange amalgamation of NSE + BVC,
while in reality we can have any number of BVC on top of each NSE.
We recently started to split the peer into a gbproxy_nse_peer + gbproxy_peer.
This takes it one step further and renames gbproxy_peer to gbproxy_bvc,
as that's really what it is.
Change-Id: Iae01067282a6401f6af4cab731202872d2cdb080
Since gbproxy doesn't use bssgp_rcvmsg from libosmocore we need to
implement our own filtering.
Change-Id: I4d1b57b89990945d307f27a58a7f630be0253d5b
Related: SYS#5232
We want this level of indirection to support multiple BVCs per NSE. The
current code assumes that an NSE only has one BVC which breaks messages
on the signalling BVC which should only be sent once to an NSE
regardless of the number of BVCs it contains.
Change-Id: I97cc6c8f8c0f1b91577ab8f679c4ae217cc88076
Related: SYS#5226
Since NS2 has a different abstraction we mock up the prim send/recv
functions and don't test NS like the old tests did.
Related: SYS#4998
Change-Id: Iecfd0408a35a11638d254c1db3c1d477b1a11524
When the patching and routing features were introduced, a lot of the
new structures were not documented at the same level as the pre-existing
code. Let's fix that.
Change-Id: I61bdd3b1cec037bce825c234a8a274b70629adc8
This timer allows periodically cleaning up stale links in link-list of
each gbproxy_peer. Previous to this patch, this kind of cleanup
(gbproxy_remove_stale_link_infos) was being done only as a consequence
of external events being triggered, such as a message from that peer
being received.
It was found in a production network agreggating several BSS that some
of them were offline for a longtime but gbproxy was still caching big
amounts of really old link_info for the NSEI assigned to those BSS,
because since they were probably turned off abruptely, no new messages
were received from it which would trigger the cleanup.
As a consequence, it has been observed that a timer to periodically
clean up old entries (link-list max-age) is requird in case w don't
receive messages from that NSEI periodically.
Related: SYS#4431
Change-Id: Ic777016f6d4f0e30fb736484774ca46878f17b7a
It was discovered in some prod setups that some TLLIs can maintain quite
long queues of msgb in case its IMSI is not acquired and the tlli is not
pruned due to link-list max-{age,length} being set to 0. As a result,
the osmo-gpbroxy steadly increases the list size of maintained TLLIs, and
some TLLI was found without IMSI catching already 1211 msgb.
Let's allow setting a maxiumum length for the queue storing those msgb
in a per TLLI base. If the limit is reached, oldest msgb are removed
before adding a new one.
Depends: libosmocore Change-Id I33b501e89a8f29e4aa121696bcbb13d4b83db40f
Related: SYS#4297
Change-Id: I4473be8604f80302df03ffdd5a13280dc072f824
This patch adds a control interface to osmo-gbproxy as well as the first
two commands to query the state of each NSVC and gbproxy peer.
The "nsvc-state" command replies with
nsei, nsvci, local state, role, remote state of all NSVCs.
The "gbproxy-state" command replies with
nsei, bvci, mcc, mnc, lac, rac, and state of each peer.
Entries are separated by a newline '\n' character. If there are no
entries an empty list is returned. This behaviour is similar to that of
the subscriber-list-active-v1 command in osmo-sgsn.
$ ./osmo_ctrl.py -d 127.0.0.1 -p 4263 -g nsvc-state
Got message: b'GET_REPLY 23 nsvc-state 101,101,DEAD,BLOCKED,SGSN,DEAD,UNBLOCKED\n'
$ ./osmo_ctrl.py -d 127.0.0.1 -p 4263 -g gbproxy-state
Got message: b'GET_REPLY 4871085901306801158 gbproxy-state '
Change-Id: I82c74fd0bfcb9ba4ec3619d9fdaa0cae201b3177
Ticket: OS#3281, SYS#4235
Sponsored-by: On-Waves ehf
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
Note that in gbproxy_test.ok, 0-0 changes to 000-000 instead of 000-00, because
the parsed ra buffer is 000000 which results in 000-000, while 00f000 would
result in 000-00. IOW this is expected.
Change-Id: I7437dfaa586689e2bef0d4be6537e5577a8f6c26