The way subnet is set up has changed as shown below.
```
<OLD Format>
smf:
session:
- subnet: 10.45.0.1/16
<NEW Format>
smf:
session:
- subnet: 10.45.0.0/16
gateway: 10.45.0.1
```
For more information, please refer to Pull Request #2975.
Move the config to the sgsn node instead of having a specific route with
specific format "default: route", since anyway internally it's already
applied to the sgsn object.
* [MME] Introduce aging timers
* Creating three new timers
* mirroring work done by gstaa on the AMF
* Implicit detach procedures added
* Fix for detach from unknown UE
* no Purge Timer, no config, expanded code
o Generate the private key as below.
$ openssl genpkey -algorithm X25519 -out /etc/open5gs/hnet/curve25519-1.key
$ openssl ecparam -name prime256v1 -genkey -conv_form compressed -out /etc/open5gs/hnet/secp256r1-2.key
o The private and public keys can be viewed with the command.
The public key is used when creating the SIM.
$ openssl pkey -in /etc/open5gs/hnet/curve25519-1.key -text
$ openssl ec -in /etc/open5gs/hnet/secp256r1-2.key -conv_form compressed -text
In ausf/udm.yaml
hnet:
o Home network public key identifier(PKI) value : 1
Protection scheme identifier : ECIES scheme profile A
- id: 1
scheme: 1
key: /etc/open5gs/hnet/curve25519-1.key
o Home network public key identifier(PKI) value : 2
Protection scheme identifier : ECIES scheme profile B
- id: 2
scheme: 2
key: /etc/open5gs/hnet/secp256r1-2.key
o Home network public key identifier(PKI) value : 3
Protection scheme identifier : ECIES scheme profile A
- id: 3
scheme: 1
key: /etc/open5gs/hnet/curve25519-1.key
o Home network public key identifier(PKI) value : 4
Protection scheme identifier : ECIES scheme profile B
- id: 4
scheme: 2
key: /etc/open5gs/hnet/secp256r1-2.key
Related to #1779
Expose metrics with labels according to ETSI TS 128 552 V16.13.0 in
PCF by using hash.
The metrics are named respecting the rule:
<generation>_<measurement_object_class>_<measurement_family_name>_<metric_name_as_in_TS_128_552>
Since slice itself is not unique, the plmnid label is exposed in
addition to snssai.
AM policy:
fivegs_pcffunction_pa_policyamassoreq and
fivegs_pcffunction_pa_policyamassosucc do not expose snssai label
since it is not available at the time of exposure.
plmnid is defined during AM policy processing, so not to lose the
difference to ...succ, the basic metric
fivegs_pcffunction_pa_policyamassoreq is preserved.
SM policy:
snssai is defined during SM policy processing, so not to lose the
difference to ...succ, the basic metric
fivegs_pcffunction_pa_policysmassoreq is preserved.
Those 2 basic metrics retain their position but are exposed with empty
labels.
Metrics with labels are called later, when the label values are known.
Exposed metrics example:
-standard counters:
fivegs_pcffunction_pa_policyamassoreq{plmnid=""} 3
fivegs_pcffunction_pa_policyamassoreq{plmnid="99970"} 3
fivegs_pcffunction_pa_policyamassosucc{plmnid="99970"} 3
fivegs_pcffunction_pa_policysmassoreq{plmnid="",snssai=""} 3
fivegs_pcffunction_pa_policysmassoreq{plmnid="99970",snssai="1000009"} 3
fivegs_pcffunction_pa_policysmassosucc{plmnid="99970",snssai="1000009"} 3
-nonstandard gauge (added for controlling purposes -
same metric as existing metric on AMF and SMF):
fivegs_pcffunction_pa_sessionnbr{plmnid="99970",snssai="1000009"} 0
Expose metrics with labels according to ETSI TS 128 552 V16.13.0 in
UPF by using hash.
The metrics are named respecting the rule:
<generation>_<measurement_object_class>_<measurement_family_name>_<metric_name_as_in_TS_128_552>
5qi is not available in UPF.
To present 5qi to the user, MN will have to maintain a table qfi->5qi
for each QoS flow (will have to get information from SMF).
So UPF has to expose qfi. qfi itself is not useful. When used, UPF will
have to expose additional label to define the session (e.g. source
interface).
Label dnn is set to value of APN/DNN received in Establishment.
Since SMF does not add APN/DNN to Establishment, the label is empty.
When APN/DNN will be set by SMF, it should be added to sess in UPF
and used in metrics on Modification and Deletion.
Both datavolumeqosleveln3upf are exposed in bytes.
MN is providing the transformation to kbits.
fivegs_upffunction_upf_qosflows should expose the number of QFIs used in
sessions, but exposes number of QER rules, which is currently equal to
QFIs.
The label snsssai is not provided since the slice is not available on UPF.
Exposed metrics example:
Standard counters:
fivegs_ep_n3_gtp_indatapktn3upf 28637
fivegs_ep_n3_gtp_outdatapktn3upf 14729
fivegs_upffunction_sm_n4sessionestabreq 4
fivegs_upffunction_sm_n4sessionestabfail{cause="66"} 1
fivegs_upffunction_sm_n4sessionestabfail{cause="71"} 68
fivegs_upffunction_sm_n4sessionestabfail{cause="68"} 4
fivegs_upffunction_sm_n4sessionestabfail{cause="72"} 15
fivegs_upffunction_sm_n4sessionestabfail{cause="75"} 3
fivegs_upffunction_sm_n4sessionestabfail{cause="65"} 4
fivegs_upffunction_sm_n4sessionreport 0
fivegs_upffunction_sm_n4sessionreportsucc 0
fivegs_ep_n3_gtp_indatavolumeqosleveln3upf{qfi="1"} 39792997
fivegs_ep_n3_gtp_outdatavolumeqosleveln3upf{qfi="1"} 737548
Nonstandard gauge (added for controlling purposes -
same metric as existing metric on AMF and SMF):
fivegs_upffunction_upf_sessionnbr 1
Standard gauge:
fivegs_upffunction_upf_qosflows{dnn=""} 1
Without this change, using metrics with core setup configurations
(configs/vonr.yaml for example) would not be possible. Having one
metrics section for whole config file causes every NF to start metrics
server on same port causing an abort.
* [HSS] Enable Change Streams
* Enable Events and Timers in HSS
* Integrate change streams in dbi
* mongodb should be configured with replica sets enabled to use feature
* Change streams are optional in HSS
* Timer will poll change stream for changes in the database
* As changes are detected, event is created to perform the correct
action
* Changes made as suggested
== Known limitation ==
Placing npcf-smpolicycontrol and pcf-policyauthorization
in different NFs is not supported. Both npcf-smpolicycontrol
and pcf-policyauthorization should be placed in the same NF.
* configs: use proper default IP address for metrics server
Let's use the IP address assigned to each process by default when
configuring the HTTP Prometheus server. Otherwise having several
processes listening on 0.0.0.0 cause collisions.
* configs: mme.yaml: Fix trailing whitespace
* 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
The use of the Gy interface (SMF acting as CTF towards an OCS node) is
mandated through configuration file. Default value "enable: auto" will
only make use of it in case a Diameter peer announcing support for the
Credit-Control Application is found.
Upon subscriber session creation, and after auth check over Gx, the SMF
will create a Gy session with the OCS and only after that step the SMF
will accept the session back to the subscriber.
The OCS may then grant some traffic volumes/time and ask to be notified
back with updated measurements.
In order to get the measurements, the SMF relies on PFCP URR configured
to the UPF through Session Repoort Request messages.
When closing the subscriber session, the SMF will also terminate the Gy
session at the OCS.
So far only some specifics parts of the Gy interface as well as the PFCP
side are implemented. Those should be enough to at least have
volume/time thresholds granted by the OCS, which then will be able to
track subsriber resource use.
This patch doesn't implement the OCS side of the Gy interface, that's
left as a future exercise. The interface was tested using an OCS
emulator implemented in TTCN-3 [1]
[1] https://cgit.osmocom.org/osmo-ttcn3-hacks/
Oliver Smith
Sukchan Lee
Pau Espin
Shigeru Ishida
mitmitmitm
jmasterfunk84
Gaber Stare
Bostjan Meglic
Carlos Giraldo