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
RANAP RESET, the first message an SGSN usually receives from an RNC,
contain the GlobalRNC-ID we can already use to register the iu_rnc
object.
This allows keeping track of peers since first message, before first
InitialUE message is received.
Once we start tracking peer RNC state within osmo-sgsn (as we already do
in other osmo-* programs), this will be needed.
Change-Id: Iaf31271feb4d88881382ed8594d0d8e20e22b194
* 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 of Routing Areas for Iu, split
off mmctx related events into an own function.
All mmctx related events must contain a valid ctx or are
otherwise invalid.
Change-Id: Ie6f131d29da299f09e897240ec5c39a395ce6f1b
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
The libgtp includes contain all the prefix osmocom/gtp.
The old non-prefix was used in the old OpenGGSN code base.
Change-Id: I5ea50c9766f719e1eea89cbf6783fafc2093773d
When the MS Network Capability is empty, expect to support at least
unencrypted communications.
This shouldn't be empty at all, as the minimum length of it is 2 when
the MS/UE is doing an Attach Request.
But when receiving a MS/UE SGSN Context via Gn, the field
is optional.
The MS/UE shall include it into the Routing Area Request,
but not must.
Change-Id: Ieef2e3eeaaadc90c35fff6f20d47bd36aaa4b9e6
It is related to the mmctx and should be in mmctx.c instead
of the GMM message parsing or handling.
Change-Id: I198a3c9d49667c70e8995808b3fcb5ea26e8f17a
Use an uint16 instead of an pointer with an unknown length.
Also encode the current active PDP context (e.g. on 2G/4G
mobilty this could change). It resynchronizes the UE with the SGSN
state.
Change-Id: I12d3110c9365132f96ef7ff8a1be22a431682c81
The IE is optional, but if it is present, it must be 11 byte long
containing a 8 byte IMEISV. If IMEI is unknown the SGSN
would add an empty IMEISV IE which is invalid.
Change-Id: I812af1e702e77214244f32ae65663c1a03b23962
A RAU Request can actually be 14 bytes long:
"""
GSM A-I/F DTAP - Routing Area Update Request
Protocol Discriminator: GPRS mobility management messages (8)
.... 1000 = Protocol discriminator: GPRS mobility management messages (0x8)
0000 .... = Skip Indicator: No indication of selected PLMN (0)
DTAP GPRS Mobility Management Message Type: Routing Area Update Request (0x08)
Update Type
.... 0... = Follow-on request pending: False
.... .000 = Update type: RA updating (0)
Ciphering Key Sequence Number
0... .... = Spare bit(s): 0
.111 .... = key sequence: No key is available (MS to network) (7)
Routing Area Identification - Old routing area identification - RAI: 262-42-13135-0
Routing area identification: 262-42-13135-0
Mobile Country Code (MCC): Germany (262)
Mobile Network Code (MNC): Vodafone GmbH (42)
Location Area Code (LAC): 0x334f (13135)
Routing Area Code (RAC): 0x00 (0)
MS Radio Access Capability
Length: 4
MS RA capability 1
0001 .... = Access Technology Type: GSM E --note that GSM E covers GSM P (1)
.... 0001 111. .... = Length in bits: 0x0f (15)
...0 01.. RF Power Capability, GMSK Power Class: Not specified (1)
A5 Bits: Same values apply for parameters as in the immediately preceding Access capabilities field within this IE (0)
.... ...1 = Controlled early Classmark Sending: Implemented
0... .... = Pseudo Synchronisation: Not Present
.0.. .... = Voice Group Call Service: no VGCS capability or no notifications wanted
..0. .... = Voice Broadcast Service: no VBS capability or no notifications wanted
...1 .... = Multislot capability struct: Present
HSCSD multislot class: Bits are not available (0)
GPRS multislot class: Bits are not available (0)
SMS_VALUE (Switch-Measure-Switch): Bits are not available (0)
ECSD multislot class: Bits are not available (0)
EGPRS multislot class: Bits are not available (0)
DTM GPRS Multi Slot Class: Bits are not available (0)
"""
Change-Id: I49210a04b16e6e2fc9d799b99c2fa415f28ddbba
