Avoid transmitting a RANAP paging message to an RNC if we already know
it's not currently available over SCCP.
Take into account that information when deciding/printing whether the
paging could be sent or not.
Take the chance to clean up the iu paging function helpers inherited
from osmo-iuh iu_client.c to better fit the data domain in osmo-sgsn
(iu_rnc).
Change-Id: I24e5446bcf4c958028577230b231960acea9e5b9
This FSM is similar to the already existing ran_peer_fsm in osmo-msc,
which already had better logic around SCCP and RANAP state handling.
Similarly, osmo-sgsn's struct ranap_iu_rnc maps to osmo-msc's struct ran_peer.
With this FSM we can currently track the RANAP link state towards a given
RNC peer:
* Reject (RANAP Error Indication) all UE-related messages until a RANAP
RESET from RNC is received first.
* Tear down all subsriber connections whenever the RANAP peer sends us a
RESET message.
* Tear down all subscriber connections whenever the SCCP link towards
RNC becomes unavailable.
* Send a RESET towards RNC peer once the SCCP link towrdards it becomes
available again.
This commit only implements so far the Rx path of the FSM, ie. when
receiving events/messages from a peer over SCCP and pushing them locally
up the stack (RANAP). The Tx side will be implemented in a follow-up
commit, which will allow discarding messages if the lower layers towards
a given RNC are known to be down.
Related: OS#3403
Change-Id: I18b7803500163e78ff6a684095194174b0fb6ee1
This is a preparation commit to introduce iu_rnc_fsm in follow-up patch.
The helper API will be used whenever the entire RNC is considered reset.
* Code inside handle_notice_ind() is moved to its own function
iu_rnc_discard_all_ue_ctx().
* Dependent helper ue_ctx_link_invalidated_free() API is properly
prefixed/renamed to ue_conn_ctx_link_invalidated_free(), where methods
for ue_conn_ctx object are placed.
* ue_conn_ctx_find() is properly prefixed/renamed to
sgsn_scu_iups_ue_conn_ctx_find() and made available to functions in
other files.
Change-Id: Ie3a4732a85a69d115dd5756bfa64b296e9e5edd2
* Verify the CN Indicator is set to PS to avoid reacting on content from
unexpected peers (eg. IuCS). If none is set, be permissive on rx and
assume PS.
* If GlobalRNC-ID IE is missing, reject the RESET with an Error
Indication towards the peer to notify about the rejection.
Same if we couldn't decode properly it.
* Introduce Tx helpers for generic SCCP UNITDATA.req and RANAP Error
Indication helpers to simplify code and avoid duplication.
Depends: osmo-iuh.git Change-Id I58c75b3e0e0f33f48d077385ffac820a6b2be59e
Change-Id: I2a53e10c3903992a42d081e3ec300fbdb9b3c34c
Split lookup+allocation from RAI updating.
This will be needed once we start creating iu_rnc objects upon SCCP
rx RANAP RESET messages, which hold Global RNC-ID but no RAI
information.
Change-Id: I3761cc539c63a7ed680b04bb8136a43d397c10aa
Move and rename functions acting on mmctx to mmctx.{c,h}.
From there, call functions acting on ranap ue_ctx.
Change-Id: I4acdbc857df36b7409c8210d364758192dfdb0bb
Use the osmo-iuh ranap_cn_rx_*_decode2() APIs directly. This
allows getting rid of extra "ctx" temporary structs and another level of
cb indirection.
Take the chance to update most pointers consitfying them.
Depends: osmo-iuh.git Change-Id I667dc2ef377c1ceb5b11315458f00b282c143c81
Change-Id: Ib3c00b5105b7ba4bb1a2dad1a14bea233a03c358
* iu_rnc is easily spotted as an object class in the data domain which
can be put into its own file, handling its specific logic and data.
* SCCP code can also be moved into own specific file, which eases
self-containment of the layer logic and data.
* As a result, lots of RANAP Rx/Tx code in iu_client.{c,h} can also be
moved to the already existing gprs_ranap.{c,h}.
All these changes improve a lot readibility of code and makes it a lot
easier to improve/extend the different layers/objects in future patches.
Change-Id: I4c792ae665720460b5a954b5c7cbfe5acbc37473
It's used nowhere, not even defined in the initialization array of
categories, because IuCS has no place in SGSN.
Change-Id: I0f7c6bedaf3b7f909c3e27175ca99967492ab7c3
While moving the iu_client into osmoSGSN, it's not allowed to have
the same global symbols in the library as in osmoSGSN.
Change-Id: I2af29b38f110b80f69ef598c8e2700ff323a9d7c
iu_client was original written to have an abstraction
for Iu. However the MSC stopped using iu_client a long
time ago because the abstraption didn't fit well.
There was never time to rewrite SGSN to direct talk RANAP
using the primitives.
Adopt iu_client for now, but with the plan to rewrite
it in a similar way as osmo-msc is doing IuCS.
Adopted from osmo-iuh:
1631c8ac5a2f ("iu_client: fix linter issues")
Related: OS#5487
Change-Id: I9c0d9667ddcb57b52eae34da942acfc1688c1418
When a PCU sends a BVC Reset over BSSGP on the Signal BVC,
all cells which has been set up previously via PtP BVCs
has to be removed.
They might be introduced after the Signal BVC reset procedure
has finished.
Change-Id: I380c8f9ef90d8c7face5c380d923ab5168f5b484
The second argument mmctx can't made const because of the paging info,
which uses non-const fields.
Change-Id: I21d7e66e433f2b891c94bae91697aa46198fb20c
If the RA is the same, return the RA, but if the ran type is different,
return NULL instead of allocating a second RA in the other
RAT.
Change-Id: I6955a09d9d8f3ba4dc3a14d7ed5cd9798d929c61
A Routing Area should be uniquely identified by the RAI.
Following this, it is forbidden to have a RAI which is valid
in both, GERAN and UTRAN.
Change-Id: I59c35f1a4912ff11574bb31e4fe424816993548c
In preparation to route SGSN Context Req/Resp/Ack the SGSN
need to route GTP messages based on the MME GroupId and MME Code.
Change-Id: I881aeba904fb6ca815842d36e466a2459ad81913
It is related to the mmctx and should be in mmctx.c instead
of the GMM message parsing or handling.
Change-Id: I198a3c9d49667c70e8995808b3fcb5ea26e8f17a
gprs_gmm.c is huge. Further split the general validation
and parsing of the message into an own function.
Change-Id: I413da1b6b4b7c0c4781393acd8564661bc74ce2d
gprs_gmm_attach_req_ies() isn't specific for the attach request.
It also did not cover the full message because of a fixed message length
when comparing both messages.
A diff of the old and new GMM message is required to figure out
if the MS/UE is retransmitting an old message or starting
a new procedure.
Change-Id: Ie698d3a6894a5796663c22c8bfd12b47acda57e6
Previous the SGSN would not support multiple BSS within the
same routing area.
Add support paging of a whole routing area.
Change-Id: I181da9f656e394ccfcb8999021a5b7e13ca0419f
The new modern osmo_routing_area_id is more flexible
and allow to access PLMN, LAC more convient.
Depends: Iaef54cac541913534af00f40483723e9952a6807 (libosmocore)
Change-Id: Ia41eb8f51d3836b1bc65325ff1ec6bdb16e20c7e
If an MS which had an MMCTX at the SGSN sent RAU update with an
unexpected Old RA field, the RAU was rejected and LLME (LLC layer)
unassigned (freed), because no MMCTX was found matching the wrong old
RA.
However, an MMCTX may actually exist pointing to that LLME, and hence
when the LLME is freed, it stayed unnoticed with a dangling pointer to
the freed LLME in ctx->gb.llme.
Let's try to harder to avoid this kind of bugs which make osmo-sgsn
crash.
Once we properly split the code into separate independent layers (LLC,
MMCTX, etc.) each holding their own structs, this kind of bugs shouldn't
happen anymore.
Related: OS#6441
Change-Id: I5a4328c6e945b85dd815215724feecadba59c435
The gtp header of ggsn have been moved to osmocom/gtp/gtp.h for a while.
Use the full path to prevent clashs with older versions
Change-Id: I764644110c0f332b18117e1e8311ddc55eafd5fa
GGSN informed us that it received an Error Indication when sending DL data to the RNC.
This probably means the RNC lost its state, aka crashed or was rebooted.
Mark the subscriber as PMM-IDLE, release Iu and point GTPU back to SGSN.
Then page the UE so it hopefully re-creates the state at the RNC.
Related: OS#6512
Related: OS#6519
Related: SYS#5435
Depends: osmo-ggsn.git Change-Id Ic80a9a928c55b6ff85be96014920bb42793cb943
Change-Id: I76d4c387730fdbfb9e7e0dd23a5afb9e762228b1
When the UE/RNC closes the Iu conn (while keeping the PDP Context
activated), the SGSN updates the GGSN to point the GTPU tunnel to
itself. Unfortunately, only the IP address was being updated while the
TEID was kept the same (the one from the RNC).
As a result, when new MT data arrived at the GGSN, it would forward it
over GTPU to the SGSN using the incorrect RNC TEID, which the libgtp
stack at osmo-sgsn would silently drop due to not being known (because
it was >PDP_MAX=1024).
The issue can be triggered in test SGSN_Tests_Iu.TC_pmm_idle_rx_mt_data.
Related: OS#5773
Related: SYS#5435
Change-Id: I782aa43c71569922a945bd44544bb1388bf8c878
Scenario: UE activates a PDP context, then after a while goes PMM IDLE
(Iu conn is destroyed but PDP is kept).
When UE connects through Iu again, it sends eg. RAU or ServiceRequest
with pdp_status bitmask statis the active NSAPIs.
If some NSAPI (PDP context) is enabled at SGSN but doesn't show up in
the bitmask, SGSN will destroy the PDP context with GGSN
(DeletePDPContextReq) towards GGSN prior to re-creating it.
When SGSN receives the DeletePDPContextResp, it would forward a
DeactivatePDPContextReq to the UE for a PDP context which was not known
by the UE anymore, this is wrong.
With this patch, the state of the NSAPI/PDP at the UE side is tracked,
and used to know whether when the PDP gets deleted on the GGSN side then
it needs to also be deleted on the Iu side.
Change-Id: I0ccd9228d71c29248b5f510356dbfdb09565dc30
This also makes sure it doesn't compile against older libosmogsm gsup
versions which would break ABI.
Change-Id: I0d03d368e73ab62ec631420769f6af91f2ff9987
Related: OS#6091
Depends: libosmocore.git Change-Id 70be3560659c58f24b8db529c4fc85da4bb0ec04
At the moment we parse the RAN TRANSPARENT CONTAINER to look at the
destination RIM ROUTING INFORMATION. This is not correct. The SGSN
should not decode the RAN TRANSPARENT CONTAINER and use the RIM ROUTING
ADDRESS / RIM ROUTING ADDRESS DISCRIMINATOR IE to make the routing
decision.
Related: OS#6095
Depends: libosmocore.git Ibca1f08906c4ffeecdae80d4e91c6c7b05fe4f8a
Change-Id: Ifd2b915ed2f05130cff8ee77714b82005c17de3d
There is no point in checking the MME any further. When the message has
reached this code path it is about to be forwarded to BSSGP, so the MME
does not play a role in the following code pathes.
The check also relys on the source RIM ROUTING INFORMATION IE inside the
RAN TRANSPARENT CONTAINER, which we are not supposed to decode.
Change-Id: I97c89aeb11537ae54d1fbea48c75619d8a92af61
Related: OS#6095
The load of plugins will eventually be moved to libosmo-gprs
implementation, and path will be passed as a parameter. Once it's moved
inside libosmo-gprs, it will be more strict on load failures, which can
cause internally if the path doesn't exist (unless NULL is passed).
Hence, add a VTY config to allow configuring the right path, and have it
disabled by default.
Change-Id: I4f965c7afafa193f4d7486750dd3e43cca22bb65
Some level of split already existed, like sgsn_auth.c, but headers were
entangled together.
Let's clearly separate application centric code (sgsn.c/h), auth related
code (auth.c/h) and mmctx related code (mmctx.c/h).
Change-Id: I048a082851c1275c959649942904205b02acce2a
