In case there are multiple AMF registered to NRF, SMF would pick only
the first AMF from the list.
In the case of sending PDU Session Establishment Accept from SMF to
AMF, this would mean a high chance of failure since the AMF might
be different than the original requester, and would not know about a
particular UE.
Modify SMF to use ServingNfId field from original request
SmContextCreateData from AMF to determine to which AMF should it send
PDU Session Establishment Accept message.
3GPP TS 29.244 7.2.2.4.2 documents that the peer will set SEID=0 in the
response when we request something for a session not existing at the peer.
If that's the case, we still want to locate the local session which
originated the request, so let's store the local SEID in the xact when
submitting the message, so that we can retrieve the related SEID and
find the session if we receive SEID=0.
It was spotted that if DeleteSessionReq sent by SMF is answered by UPF
with cause="Session context not found", then it contains SEID=0 (this is
correct as per specs). Hence, since SEID=0 session is not looked up, so
sess=NULL.
A follow up commit improves the situation by looking up the SEID in the
originating request message in that case.
* [SMF] Avoid abort() if gtp_node mempool becomes full
Related: https://github.com/open5gs/open5gs/issues/1621
* [SMF] metrics: Add new ctr tracking gtp_node allocation failures
This metrics is useful to track whether at some point the mempool went
full, so that config needs to be updated to increase the mempool size.
Gy (3GPP TS 32.299 ) refers to AVP in DCCA (RFC4006).
RFC4006 5.1.2:
"[...] by including the Multiple-Services-Indicator AVP in the first
interrogation."
Nokia's infocenter documentation also states it's sent during Initial CCR
only: "(CCR-I only)".
smf_gtp_node_pool were properly freed.
However, the seqence was wrong, so we got a warning message.
To solve this problem, I've moved smf_gtp_node_alloc/free
from gtp_path.[ch] to context.[ch]
* Initial metrics support based on Prometheus
This commit introduces initial support for metrics in open5gs.
The metrics code is added as libogsmetrics (lib/metrics/), with a well
defined opaque API to manage different types of metrics, allowing for
different implementations for different technologies to scrap the
metrics (placed as lib/metrics/<impl>/. The implementation is right now
selected at build time, in order to be able to opt-out the related dependencies
for users not interested in the features. 2 implementations are already
provided in this commit to start with:
* void: Default implementation. Empty stubs, acts as a NOOP.
* prometheus: open5gs processes become Prometheus servers, offering
states through an http server to the Prometheus scrappers. Relies on
libprom (prometheus-client-ci [1] project) to track the metrics and format
them during export, and libmicrohttpd to make the export possible through
HTTP.
[1] https://github.com/digitalocean/prometheus-client-c
The prometheus-client-c is not well maintained nowadays in upstream, and
furthermore it uses a quite peculiar mixture of build systems (autolib
on the main dir, cmake for libprom in a subdir). This makes it difficult
to have it widely available in distros, and difficult to find it if it
is installed in the system. Hence, the best is to include it as a
meson subproject like we already do for freeDiameter. An open5gs fork is
requried in order to have an extra patch adding a top-level
CMakeList.txt in order to be able to includ eit from open5gs's meson
build. Furthermore, this allows adding bugfixes to the subproject if any
are found in the future.
* [SMF] Initial metrics support
* [SMF] Add metrics at gtp_node level
* docs: Add tutorial documenting metrics with Prometheus
* [SMF] Gn: Drop unreachable return line
* [SMF] Avoid crash if Create{Session,PdpContext}Resp fails to be sent
Crash spotted in a running open5gs-smfd process, triggered by:
ERROR: ogs_gtp_sendto() failed (1:Operation not permitted) (../lib/gtp/path.c:119)
ERROR: ogs_gtp_xact_commit: Expectation `rv == OGS_OK' failed. (../lib/gtp/xact.c:730)
ERROR: smf_gtp2_send_create_session_response: Expectation `rv == OGS_OK' failed. (../src/smf/gtp-path.c:451)
FATAL: smf_gsm_state_wait_pfcp_establishment: Assertion `OGS_OK == smf_gtp2_send_create_session_response( sess, gtp_xact)' failed. (../src/smf/gsm-sm.c:676)
* [SMF] Avoid crash if Delete{Sesson,PdpContext}Resp fails to be sent
Let's simply continuing with release of the session, there's not much we
can do about it. Peer will eventually realize the conn is no longer
there.
According to the following standards the response to the endpoint
/nudm-sdm/${supi}/sm-data should be an array of
SessionManagementSubscriptionData objects, instead of only one object.
TS 29.503 version 16.6.0
TS 29.505 version 16.4.0
UDR now responds to the request with only item in the array.
UDM copies all items as is.
SMF uses only the first item in the array, even if there are more
present.
AN-Trusted AVP is only relevant for non-3GPP access networks e.g. WLAN.
This commit adds a check for non-3GPP access network in order to include
AN-Trusted AVP in CCR or not.
Also, clears the M bit for AN-trusted AVP as per TS 29.212 version 16.4.0, Table 5.4.0.1
A problem occurred when there was one SGWU/UPF and multiple SGWC/SMF.
When SGWU and UPF create a session, if the SEID is the same,
the existing session information is used without creating an additional session.
These problems were solved by using the F-SEID including IP information
in the process of checking the existing session.
For video in VoNR, multiple QosFlow is required in one session.
In the past, since only one Session Modification Message was supported,
QoS-Flow was put into several Session Messages one by one and processed.
Now that multiple QoS-Flows can be supported,
it is optimized to process one session modification message.