The RAN INFORMATION RELAY message has no associated response, and hence
it should not start T3-RESPONSE timer to retrigger retransmissions.
TS 29.060 11.1:
"The Error Indication, Version Not Supported, RAN Information Relay,
Supported Extension Headers Notification and the SGSN Context Acknowledge
messages shall be considered as Responses for the purpose of this clause"
TS 29.060 7.5.14.1:
"For handling of protocol errors the RAN Information Relay message is treated as a
Response message."
* Cancel Location while Idle Fix
* Forgot about SGSAP on MME Change.
Added "action" to sgsap_send_detach..
* Make handle_clr uniform with other handlers
* Added Robustness for Any Detach Type
* Memory wasn't freed upon CLR for unknown IMSIs
* Moving MME Detach to new PR
* CLR while idle is broken after 7031856cd7
Cancel Location Request arriving while UE is idle will not proceed to paging due to this check for S1 connection. Using new flag "isAnswer" to bypass this check to allow paging to occur when we are not doing a AIA/ULA related procedure.
* No Context Setup is required when sending the detach request. If the paging was due to wanting to send a Detach Request to the UE, then we fast track to sending the detach request.
* emm-sm.c:
In the case of MME initiated detach while UE is idle, there is no initial conext setup. We go right from the service request after paging into sending the detach request. TS23.401
mme-path.c:
Using nas_eps.type in the case of MME Initiated Detach while UE is idle does not work. nas_eps.type would represent the service request.
mme-s11-handler.c:
After S11 action, no action should be taken. We want to wait for the detach accept from the UE before proceeding with the S1 release (detach).
* InitialContextSetup should occur for detach.
- Added diameter dictionary definitions for Cancel Location
- Cancel Location will completely remove UE from MME, allow for a fresh IMSI attach to occur on next attempt.
- T3422 is used for detach request.
- Added new handling for s6a events in mme-sm, as not all s6a messages are at attach now. Maybe there's something in a state machine I should've been using here instead of a new flag?
- Testing was completed with UE in idle and connected. With CLR flags indicating re-attach required and without. Also sending CLR after UE detach. And then sending again when mme_ue is empty.
* 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
In the past only GTPv2C was supported, and had the "gtp" generic prefix.
Later on, GTPv1C support was added, and "gtp1" prefix was used.
Let's move GTPv2C specific bits to have "gtp2" prefix too, and leave
"gtp" prefix for generic stuff among different GTP versions.
