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
So far, we had no pfcp.vty test, because PFCP support is built
conditionally, and the pfcp.vty test would always fail without PFCP
support.
Add a pfcp test for the VTY, conditionally: use suffix .vty.with_pfcp to
identify tests that need PFCP support, and run those only when
configured with --enable-pfcp.
Related: SYS#5895
Change-Id: Ibb1797bb43a18f26fc693e0c8920cfd1f5fb9ede
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
A typical OS imposed limit is 1024 open FD, which is too low when there
are thousands of HNB.
In systemd service file, set a super high limit of 65536.
In osmo-hnbgw's user manual, add section 'Configure limits' describing
this in detail.
Related: OS#6256
Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71
Change-Id: I5333765199cf9e3e5a570f85b85d2b7423d34a4d
It was found in the field that some peers sends an X.213 IP address
consisting of 7 bytes (1byte IDP/AFI, 2byte ICP, 4 byte IPv4 address) insetad
of 20 bytes. This was until recently failing in osmo-hnbgw due to
missing decoding functionalitit in osmo-iuh.git. Cover it here.
Related: SYS#6623
Depends: osmo-iuh.git I507fb1605d976bd8573162e4fa81721245330184
Change-Id: I71323018d79a4f5778dc6e49488d75ae7c2c4cdc
Pau Espin
Harald Welte
Neels Hofmeyr
Oliver Smith
Andreas Eversberg