The validity time for NF Instances obtained through NF Discovery was
not properly implemented. Since the validity was 3600 seconds(1 hour),
which caused 5G Core to not work properly after 3600 seconds(1 hour).
There was an issue where an NF Instance should be deleted
when its validity time expired, but it was not working correctly
due to incorrect use of reference count.
Therefore, I have modified the Validity of NF Instances obtained
through NF Discovery to work properly.
I also changed the default value of valdityPeriod to 30 seconds.
Fixed not using Reference Count for adding/deleting NF Instances.
Up until now, NF Instances have been managed by referencing the Reference Count.
Initially, when an NF Instance is added, the Reference Count is incremented and
when it is deleted, the Reference Count is decremented.
If a UE discovers another NF Instance through the NF Discovery function,
the Reference Count is incremented. And if a UE de-registers,
the Reference Count of the discovered NF is decremented.
However, there's a problem with this approach.
When other NF is de-registered,
there is no guarantee that it will be 100% notified.
For example, if a UDM is de-registered, but an SCP is de-registered before it,
the AMF will not be notified that the UDM has been de-registered.
In situations where this is not clear, Reference Count cannot be used.
Therefore, we have modified it to not use the Reference Count method.
Also, when a UE connects, it is modified to always search
whether an NF Instance exists by NF Instance ID whenever it is discovered.
To do this, we modified lib/sbi/path.c as shown below.
```diff
@@ -281,13 +281,15 @@ int ogs_sbi_discover_and_send(ogs_sbi_xact_t *xact)
}
/* Target NF-Instance */
- nf_instance = sbi_object->service_type_array[service_type].nf_instance;
+ nf_instance = ogs_sbi_nf_instance_find(
+ sbi_object->service_type_array[service_type].nf_instance_id);
if (!nf_instance) {
nf_instance = ogs_sbi_nf_instance_find_by_discovery_param(
target_nf_type, requester_nf_type, discovery_option);
- if (nf_instance)
- OGS_SBI_SETUP_NF_INSTANCE(
- sbi_object->service_type_array[service_type], nf_instance);
+ if (nf_instance) {
+ OGS_SBI_SETUP_NF_INSTANCE_ID(
+ sbi_object->service_type_array[service_type], nf_instance->id);
+ }
}
```
A friend in the community was trying to connect an SMF made by another
manufacturer with an SBI interface and found a big problem with Open5GS.
All of the code in the part that generates the Resource URI
from HTTP.location is invalid.
For example, suppose we create a Resource URI with SMContext as below.
{apiRoot}/nsmf-pdusession/<apiVersion>/sm-contexts/{smContextRef}
In this case, Open5GS extracted the {smContextRef} part of the HTTP.location
and appended it to the beginning
{apiRoot}/nsmf-pdusession/<apiVersion>/sm-contexts/.
This implementation may not work properly if the apiRoot changes.
Consider a different port number as shown below.
<HTTP.location>
127.0.0.4:9999/nsmf-pdusession/v1/sm-contexts/1
The SMF may send an apiRoot to the AMF with a changed port number,
in which case the AMF must honor it.
Therefore, instead of extracting only the smContextRef from HTTP.location,
we modified it to use the whole thing to create a Resource URI.
We modified all NFs that use HTTP.location in the same way, not just SMFs.
The AMF will crash on the following locations when it receives a sequence
of NAS messages from a UE.
- ogs_nas_encrypt: Assertion `pkbuf->len' failed. (../lib/nas/common/security.c:86)
- gmm_state_authentication: Assertion `r != OGS_ERROR' failed. (../src/amf/gmm-sm.c:1561)
Besides the crashes found above, an incorrect protocol transition
is identified in Open5GS. Without any Registration/Attach Request message,
when the Identity Response message sent, the Core Network responds
with an Authentication Request message. According to the standard,
only the Registration/Attach Request message can start a state transition
from the 5GMM/EMM-DEREGISTERED state to the 5GMM/EMM-COMMON-PROCEDURE-INITIATED.
So I've modified the relevant code to address these issues.
* [SBI] Handle and store AMF info
* [SBI] Add "target GUAMI" discovery option
* [SBI] Handle UeContextTransfer request and response messages
* [AMF] Handle NF discovery from AMF to AMF
* [AMF] Add UE Context Transfer Request/Response from AMF to AMF
* [SCP] Handle UeContextTransfer
* Follow-up on #3052
* [AMF] force authentication after 'Ue context transfer' for now
* [AMF] force authentication after 'Ue context transfer' for now
---------
Co-authored-by: Sukchan Lee <acetcom@gmail.com>
1. HandoverRequired
2. HandoverRequest
3. HandoverFailure
4. UEContextReleaseCommand
5. HandoverPreparationFailure
If UEContextReleaseComplete is not received,
the Source-UE will have the Target-UE.
6. HandoverRequired
There may be cases where the Source UE has a Target UE
from a previous HandoverRequired process. In this case,
it is recommended to force the deletion of the Target UE information
when receiving a new HandoverRequired.
7. HandoverRequest
8. HandoverFailure
9. UEContextReleaseCommand
10. UEContextReleaseComplete
11. HandoverPreparationFailure
... Crashed ...
* [AMF/MME] UEContextReleaseCommand in Integrity (#2786)
Modified not to send UEContextReleaseCommand in Integrity Unprotected
NAS message such like Registration or Service request.
* [AMF/MME] UEContextReleaseCommand after Interity Protected (#2786)
Modified not to send UEContextReleaseCommand in Integrity Unprotected
NAS message such like Registration or Service request.
Each SMF's NfProfile can contain multiple SmfInfo items. The issue was
that AMF checked only the first SmfInfo for correct S-NSSAI/NR-TAI
information.
In case of a 5G core setup with SMF handling 2 or more slices, and UE
trying to establish multiple PDU sessions, AMF would report an error
when trying to find the correct serving SMF.
[amf] ERROR: [1:0] (NF discover) No [nsmf-pdusession] (../src/amf/nnrf-handler.c:85)
- have a more consistent naming among the NF's
- always have the same prefix (amf_/smf_/pcf_) depending on the NF
- function name is always the same, how the function calculates the load
is NF specific and internal to the function itself (but not the function
name).
TS23.007 17.4.1
19A PFCP based restart procedures
After a PFCP entity has restarted, it shall immediately update all local Recovery Time Stamps and shall clear all remote
Recovery Time Stamps. When peer PFCP entities information is available, i.e. when the PFCP Association is still alive,
the restarted PFCP entity shall send its updated Recovery Time Stamps in a Heartbeat Request message to the peer
PFCP entities before initiating any PFCP session signalling.
[AMF] Implicit Network-initiated Deregistration
Two timers are introduced (both with duration of T3512 + 4 min):
-MOBILE_REACHABLE
-IMPLICIT_DEREGISTRATION
MOBILE_REACHABLE is set when NAS connection for the UE is released.
IMPLICIT_DEREGISTRATION is set when MOBILE_REACHABLE expires.
On MOBILE_REACHABLE expiry Paging is ignored.
On IMPLICIT_DEREGISTRATION expiry:
-UE's RM_State is set to DEREGISTERED
-UE is Nudm_SDM_Unsubscribed
-UE is Nudm_UECM_Deregistered
-PDU sessions are released
-AM policies are deleted
Existing flag amf_ue->network_initiated_de_reg is used.
Two timers are introduced (both with duration of T3512 + 4 min):
-MOBILE_REACHABLE
-IMPLICIT_DEREGISTRATION
MOBILE_REACHABLE is set when NAS connection for the UE is released.
IMPLICIT_DEREGISTRATION is set when MOBILE_REACHABLE expires.
On MOBILE_REACHABLE expiry Paging is ignored.
On IMPLICIT_DEREGISTRATION expiry:
-UE's RM_State is set to DEREGISTERED
-UE is Nudm_SDM_Unsubscribed
-UE is Nudm_UECM_Deregistered
-PDU sessions are released
-AM policies are deleted
Existing flag amf_ue->network_initiated_de_reg is used.
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
The current load percentage of the NF Service Consumer is provided
in the payload body of the PATCH request when periodically
contacting the NRF (heart-beat).
AMF: ratio between currently connected ran_ue and maximum number of them
SMF: ratio between current PDU sessions and maximum available
PCF: ratio between current AM+SM policy associations and maximum available
or ratio between currently connected UEs and maximum number of them
(the load which is higher)
AUSF, UDM: ratio between currently connected UE and maximum number of them
BSF: ratio between current sessions and maximum available
NSSF: ratio between currently used NSIs and maximum number of them
NRF currently doesn't determine that the NF Profile has changed.
Expose RM metrics with labels according to ETSI TS 128 552 V16.13.0 in
AMF 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.
RegInitFail is exposed as an alternative to RegInitReq and RegInitSucc
counters so cause label can be provided. It counts rejected registrations
and rejected authentications.
Rejected authentications are counted under label cause="0".
Exposed metrics example:
-standard gauge:
fivegs_amffunction_rm_registeredsubnbr{plmnid="00101",snssai="1000009"} 1
-nonstandard counter:
fivegs_amffunction_rm_reginitfail{cause="3"} 4
AMF does not crash anymore when a new UE registration request arrives,
and there is no available space left in UE context pool. Now it just
rejects the request with an error.
Each UE context has 'current' and 'next' TMSI values. AMF first
allocates the 'next' value, before confirming it and releasing the
'previous'. This means that we potentially need pool size of 2x the
amount of maximum configured UE.
Without this change, AMF would crash in case that there are 'x'
configured maximum amount of UE, and there are already 'x' registered
UE.
[gmm] INFO: Registration request (../src/amf/gmm-sm.c:135)
[gmm] INFO: [suci-0-001-01-1234-0-1-1000000000] SUCI (../src/amf/gmm-handler.c:149)
[gmm] DEBUG: OLD TSC[UE:0,AMF:0] KSI[UE:7,AMF:0] (../src/amf/gmm-handler.c:179)
[gmm] DEBUG: NEW TSC[UE:0,AMF:0] KSI[UE:7,AMF:0] (../src/amf/gmm-handler.c:186)
[amf] FATAL: amf_m_tmsi_alloc: Assertion `m_tmsi' failed. (../src/amf/context.c:2160)
[core] FATAL: backtrace() returned 13 addresses (../lib/core/ogs-abort.c:37)
AMF subscribes to UDM for each registered UE.
At the moment, UDM does not send callback to AMF when any of the UE's
properties in the database changes.
At the moment, AMF does properly parse the ModificationNotification, but
does not do anything useful.
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.
== 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.
Sukchan Lee
Matej Gradišar
Bostjan Meglic
Gaber Stare
mitmitmitm