It is interesting to know if a release was normal (as expected/requested
by the NAS layer, typically indicating a user-requested call end) or
abnormal (radio failure, pre-emption or whatever other event that the
user did not expect).
Related: SYS#6773
Change-Id: Idd2f845b7db448064b693ac1efdc8db006a47a11
Whenever we receive a message and cannot decode the most basic IEs,
or receive an unknown/unsupported procedure code, we should respond
with an ErrorIndication in order to inform the peer.
Change-Id: I7aaa66f83f62ee1b5ba5204248e9f4cc754263ed
If we receive a procedure (like UE-REGISTER) in a state
where it's not permitted (e.g. HNB not registered), we should
send a UE-REGISTER-REJ with proper cause value, rather than not
sending any response at all.
Change-Id: I300db368a3d1d2fb5967f69f2ed4ac90ecf85e75
We always should respond to a UE-REGISTER-REQ. Either it's an ACK
or we must send a REJ. There should not be any "quiet" error cases
where we don't respond at all:
* send general Error Indication at a point where we cannot decode the
UE-Identity-IE (which is mandatory in UE-REGISTER-REJECT)
* send UE-REGISTER-REJECT with matching cause value whenever we have
the decoded UE Identity around
Change-Id: I5338a1324545b2c6d31fb45f1e69fee45842e207
When we reject the HNB-REGISTER-REQ, let's use an as specific as possible
cause value to let the peer know why we rejected registration.
Change-Id: Iadddd26b751a9fd80c829068792aa93cd538c43d
This way the caller can provide the cause value to be used during
reject.
Requires: osmo-iuh I7db92b51847c282d23d568970dfd2bedecdea486
Change-Id: Ic83674523c0326a7ae51fb176bddfd6641ed3ac4
Prior to this patch we always decoded CS RANAP, but only decoded PS
RANAP in case PFCP support was enabled. This meant that PS KPIs
were only counted when PFCP was enabled, too.
Let's move to a mode where we unconditionally decode RANAP and always
call the KPI module for updating the rate counters.
Change-Id: I6054b6efcc202ebd71cd6e135e49c279ba616a01
Usually, a hnb_context still has a hnb_persistent associated at release
time. But that is not guaranteed.
See also further below, where the function tests for ctx->persistent
correctly.
Change-Id: I77ddd627ebfe96c7674c6a197af8b2c4b1a4024c
Add rate_ctr based statistics for RAB activation, deactivation and
failures. This requires us to parse RANAP in both uplink and downlink
and to iterate deep into the setup/modify/release/failure lists.
Given the way how the protocol works, the only way to distinguish an
activation from a modification is because sender and recipient know
whether a given RAB is already active at the time of the message. So we
also need to track the activation state of each RAB.
Depends: osmo-iuh.git Change-Id I328819c650fc6cefe735093a846277b4f03e6b29
Change-Id: I198fa37699e22380909764de6a0522ac79aa1d39
The mgw_fsm only supports CS RABs in the CS domain; let's add some
ASSERTs to make sure the impossible doesn't happen.
Change-Id: I264c4b3da17b6f59ebcdd02031318402a483041a
In uplink we use *ranap_rx_udt_ul*, so let's use the same naming
pattern for processing dowlink unit-data messages to make things more
consistent. Also, make sure udt is always part of functions that only
handle unitdata - not to be confused with connection-oriented messages.
Change-Id: I1792e4c2cdce145ae906c181898163bcda36328d
Adding counters for number of paging succeeded is much harder,
as we currently don't parse connection-oriented DL RANAP and/or any
L3 NAS in it.
Change-Id: I7648caa410dba8474d57121a8128579ba200b18f
Let's not make the functions appear more generic than they are: They
all explicitly only support uplink so far.
Change-Id: I7db0d933a8f17f8c410141f43dab12b8c19fc8ae
Those functions have always been handling only unit-data in uplink
direction, so let's reflect that in the function name to prevent
anyone assuming they process connection-oriented RANAP and/or
the downlink direction.
Change-Id: I29e8176ac19b2e7390e5950b8d0944c8961e491f
Let's keep track of the various unit-data messages we receive from
CN-link peers: RESET, RESET-ACK, PAGING, UNKNOWN, UNSUPPORTED,
OVERLOAD_IND, ERROR_IND.
Change-Id: Ibe4c73b0288ea20ca3d54519b42bc7cb0e9e61b2
Ever since the ancient days of OpenBSC, we've always had macros to
abbreviate the cumbersome 'rate_ctr_inc(rate_ctr_group_get_ctr(...))'
construct. Somehow this was missed here.
Also, since 2018 (libosmocore.git 175a4ae93aaf1068b61041dca12962059d65ed55)
we have rate_ctr_inc2() to make it even simpler...
Change-Id: I5b9e6b2069eed533c472cea8483a370f7fcc8e74
Ever since the ancient days of OpenBSC, we've always had macros to
abbreviate the cumbersome 'rate_ctr_inc(rate_ctr_group_get_ctr(...))'
construct. Somehow this was missed here.
Also, since 2018 (libosmocore.git 175a4ae93aaf1068b61041dca12962059d65ed55)
we have rate_ctr_inc2() to make it even simpler...
Change-Id: I2754d7aa9d6c3e333bd729bc6e924c502b40cdad
Let's add a per-hnb rate_ctr and stat_item group. Only one initial
counter (number of Iuh establishments) and one initial stat_item
(uptime/downtime) is implemented.
Related: SYS#6773
Change-Id: I26d7c3657cdaf7c6ba5aa10a0677381ab099f8dd
The previous commit was missing the assignment of hnb_persistent->ctx
during successful HNB REGISTER REQ.
Related: SYS#6773
Fixes: Change-Id Ife89a7a206836bd89334d19d3cf8c92969dd74de
Change-Id: I18fe0e5aa968a1095c72e6bf32d08b031b342ac6
This allows us to add a new "hnb-policy closed", which means we do not
accept any random HNB connection anymore, but only those whose identity
is pre-configured explicitly using administrative means.
Furthermore, this new data structure will allow us (in future patches)
to keep persistent data like uptime / downtime of each HNB.
Related: SYS#6773
Change-Id: Ife89a7a206836bd89334d19d3cf8c92969dd74de
We are about to introduce the stringified UMTS cell identifier to the
VTY, and for that we need to not only print but also parse the related
string.
Related: SYS#6773
Change-Id: I6da947d1f2316241e44e53bb6aaec4221cfaa2c0
I just wanted to get a talloc report from osmo-hnbgw by sending SIGUSR1
and the process terminated. Clearly not the desired behaviour...
Change-Id: I1209a2fadacf62afd5027480426285f527249788
Printing the PLMN 001-01 as "1-1" like the existing code is just weird,
and also doesn't differentiate between 2-digit and 3-digit MNC in the
output.
Change-Id: I015ad84a6f61b4420f6bfdaa60e8e1b53a71589c
I'm not sure why so many files (particularly written by Philipp)
did contain a GPLv2+ header, instead of the AGPLv3+ which is the
actual overall project license. I consider it a mistake.
In any case, any copyrightable contribution to those files was done by
sysmocom employees, so I as managing directory can legally make a
license change, whther or not it was a mistake early on or not.
Change-Id: I42ea544ae4e5c4d3bedad12ddb55cf3c26a30919
Allow configuring specific Network Instance names for the Core and
Access sides, to send to the UPF, to allow the UPF to pick the proper
network interface to create GTP tunnels on.
Add VTY cfg 'hnbgw' / 'pfcp' / 'netinst (access|core) NAME' to allow
configuring Network Interface values to send in PFCP. These are "dotted"
domain name strings, as in APN.
Add these Network Interface names to the PFCP messages' detection as
well as forwarding rules, each one indicating the side that it is
detecting on or forwarding to.
This helps lift osmo-hnbgw's PFCP support out of lab situations to a
proper production scenario, where the core and access networks are in
separate subnets, with osmo-hnbgw + UPF as the gateway.
For example, in osmo-hnbgw, configure
hnbgw
pfcp
netinst access my-ran
netinst core my-core
and in osmo-upf, configure
netinst
add my-ran 10.9.8.7
add my-core 1.2.3.4
In effect, all GTP tunnel endpoints towards the Access side will be
bound on 10.9.8.7, and all GTP tunnel endpoints towards the Core side
will be bound on 1.2.3.4.
Related: SYS#5895
Change-Id: Ief53dbfacf1645c32a07847d590c4884d4c8ca56
Do not update the Core-facing Forwarding Action Rule with the Access
side's remote TEID, update the Access-facing FAR as we should.
This is a seemingly small but very grave bug in osmo-hnbgw's PFCP
implementation, and proof that no-one anywhere has tested osmo-hnbgw's
PFCP support properly yet.
Related: SYS#5895
Change-Id: I596f1785d280d7e53e0cef649d6bb5df01ebf648
This adds a line to the output showing DISCONNECTED or CONNNECTED
state for each cnlink during the 'show cnlink' VTY command.
Closes: SYS#6741
Change-Id: I6ab7d08fcd0631d31a12418f950c5901a93db43a
It helps in a pretty complex situation seen in the field.
A third-party MSC releases SCCP in one fell swoop, not waiting for the
Iu Release Complete to come back from RAN as the specs would suggest.
The result is this odd sequence, where late rx of RUA Disconnect
actually causes a new SCCP connection to be established and torn down
again:
RAN HNBGW MSC
|--active-RUA-ctx----|--active-sccp------|
| |<--IU-Release-Cmd--|
|<--IU-Release-Cmd---| |
| |<--SCCP-RLSD-------| (too soon)
|...<-RUA-Disconnect-| x (the consequence)
| x
|--RUA-Disconnect--->| (IU Release Complete)
x <create-new-ctx>
|-SCCP-CR---------->|
|-IU-Release-Compl->|
|<--CREF------------|
x x
This patch is a relatively simple practical improvement of above
situation that is logically obvious:
Validate the correct message type for creating a new RUA-to-SCCP
context: RUA Connect.
That means the IU Release Complete is ignored:
RAN HNBGW MSC
|--active-RUA-ctx----|--active-sccp------|
| |<--IU-Release-Cmd--|
|<--IU-Release-Cmd---| |
| |<--SCCP-RLSD-------| (too soon)
|...<-RUA-Disconnect-| x (the consequence)
| x
|--RUA-Disconnect--->| (IU Release Complete)
x <error>
x
Related: SYS#6602
Change-Id: Ie359fcada98fb19f56015cf462e6d8c039f5fce5
Allow IP address renegotation between HNB and MGW:
* Upon MGCP MDCX ACK received from the RAN-side conn, if the IP address/port
changes, then restart the RAB-Ass-Req+Resp procedure on Iuh.
* Upon RAB-Ass-Resp received from the HNB, if the IP address/port changes,
then go through another MDCX + MDCX ACK prcoedure on MGCP.
An MDCX counter is introduced to avoid infinite loops where the HNB and
the MGW keep changing their IP address triggered by the change on the
other side, eg. due to incorrect network/routing setup.
The counter is also used to track count in order to make sure that
always at least 1 MDCX is transmitted, in order to change conn_mode to
SEND_RECV.
Related: OS#6127
Change-Id: I936a50fed38a201c4a8da99b40f07082049e5157
In general, the HNBs end up binding its IuUP/RTP streams to the same IP
address used for Iuh signalling.
When receiving a RAB-Ass-Req from CN, osmo-hnbgw creates an endpoint in
its co-located MGW and creates 2 MGCP conns on it, one facing the RAN
side and one facing the CN side. At that point, the remote CN IuUP IP address
is known (was include din the received RAB-Ass-Req), but the RAN one is
not yet known. Hence, the CRCX on the RAN-side conn contained no remote
IP address, which means MGW has to blindly guess a good local IP address
if "ip probing" is enabled.
As a result, when RAB-Ass-Resp comes back from the hNodeB containing the
allocated remote IuUP IP address and MGW is updated through MGCP MDCX,
it may happen that MGW rebinds to a better fitting local IP address and
returns it in MDCX. This has several downfalls:
1- We don't yet support updating the hNodeB about the changed IP address
(see mgw_fsm_mdcx_hnb). For that, we'd need to send a RAB-Modify-Req+Resp.
2- Even if we supported it, in the general case we'd be delaying call
establishment because an extra roundtrip is needed to update
RAB-Modify-Req+Resp.
In general, the HNBs end up binding its IuUP/RTP streams to the same IP
address used for the Iuh signalling. Hence, use this assumption to
announce the Iuh IP address as a remote IuUP IP address when
transmitting the MGCP CRCX at the RAN-side conn to the MGW. This way
the MGW can potentially select a proper local IuUP IP address from the
start, so no RAB-Modify-Req is required later on.
The logic to transmit RAB-Modify-Req is left unimplemented in this
commit and is left as a later improvement.
Related: SYS#6657
Change-Id: Icf43e3a1cde809d844f17ef2d0600efe64bc3dfe
In the field, we've encountered a so far unsupported scenario: after a
RAB Assignment Request and Response have successfully set up an RTP
stream, the CN sends *another* RAB Assignment Request to modify some SDU
parameters, omitting the transportLayerInformation IE (not modifying the
RTP address).
Directly forward all RAB Assignment Requests that have no RTP
information. This covers above use case, and also generally applies: no
RTP info means nothing to tell the MGW about.
Do not (yet?) support modifying the RTP address/port.
Related: osmo-ttcn3-hacks Iadaba0e5e82ad6d163ad509904ede213e2462d5c
Related: SYS#6624
Change-Id: I25bf19981cd75a87a7ceb3382dae1ec626ae475c
The actual scope is larger than just a stale release. Every RUA and SCCP
context map FSM state that has a timeout uses X31. (Seems I intended to
add more timers but forgot to follow up when I wrote it.)
Related: SYS#6602
Change-Id: I75a25f9065bc651e7ba8feda6db03c49a3b75c5e
This was being triggered recently by
HNBGW_Tests.TC_ranap_cs_mo_disconnect in osmo-ttcn3-hacks.git.
Change-Id: Idaad11eaa3c2e56de792f80bab1f1d8435ef9b68
It was spotted that in some deploys with satellite links and heavy load,
the roundtrip times for CR and CC can go slightly over 12 seconds, so
better increase the default value to 15 seconds to be on a safer place
and avoid operation problems with default configuration.
Related: SYS#6602, SYS#6616
Change-Id: I24225cfc0addf326c239ec658a27b93b83a3e751
The HNBGW in correctly assumes that no ss7->sccp instance is allocated
until the same function calls osmo_sccp_simple_client_on_ss7_id().
This assumption is wrong, since ss7 may create its own ss7->sccp
instance internally as a result of vty configuration, eg. when "sccp
max-optional-data 124" is placed in osmo-hnbgw.cfg file.
In this scenario, simply removing the assert is enough, since
osmo_sccp_simple_client_on_ss7_id() just calls osmo_ss7_ensure_sccp(),
the same that the libmoso-sccp code called to allocate the pointer.
Related: SYS#6566
Fixes: f3caea850b
Change-Id: I1221c165156e9625324cf0080836a8ed2bad4e9c
Due to ip probing used at MGW and specific/complex routing in place
between RAN and CN, it may happen that, on the RAN-side endpoint connection,
the MGW first selects a local IP address.
Then, after the HNBGW signalling it to the HNB with the patched RabAssReq
and receiving the HNB local IP address through RabAssResp, then applying
it to MGW through MDCX, it can happen that the MDCX ACK contains a changed
local IP address at the MGW, due to IP probing after learning the remote
address.
This change is so far not announced to the HNB in anyway, ending up in the
HNB sending IuUP packets to the wrong IP/port, which is rejected with ICMP
due to osmo-mgw having no socket open there anymore.
We should at least, in osmo-hnbgw, if detecting the local MGW IP address
changed during MDCX, tear down the call setup. This patch does precisely
that.
Related: OS#6127
Change-Id: I32c4a7f838ceb5077bec7945e7976ce455d6b025
Pau Espin
Harald Welte
Neels Hofmeyr