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.
<nf>/init.c:<nf>_main() :
ogs_pollset_poll() receives the time of the expiration of next timer as
an argument. If this timeout is in very near future (1 millisecond),
and if there are multiple events that need to be processed by
ogs_pollset_poll(), these could take more than 1 millisecond for
processing, resulting in the timer already passed the expiration.
In case that another NF is under heavy load and responds to an SBI
request with some delay of a few seconds, it can happen that
ogs_pollset_poll() adds SBI responses to the event list for further
processing, then ogs_timer_mgr_expire() is called which will add an
additional event for timer expiration. When all events are processed
one-by-one, the SBI xact would get deleted twice in a row, resulting in
a crash.
0 __GI_abort () at ./stdlib/abort.c:107
1 0x00007f9de91693b1 in ?? () from /lib/x86_64-linux-gnu/libtalloc.so.2
2 0x00007f9de9a21745 in ogs_talloc_free (ptr=0x7f9d906c2c70, location=0x7f9de960bf41 "../lib/sbi/message.c:2423") at ../lib/core/ogs-memory.c:107
3 0x00007f9de95dbf31 in ogs_sbi_discovery_option_free (discovery_option=0x7f9d9090e670) at ../lib/sbi/message.c:2423
4 0x00007f9de95f7c47 in ogs_sbi_xact_remove (xact=0x7f9db630b630) at ../lib/sbi/context.c:1702
5 0x000055a482784846 in amf_state_operational (s=0x7f9d9488bbb0, e=0x7f9d90aecf20) at ../src/amf/amf-sm.c:604
6 0x00007f9de9a33cf0 in ogs_fsm_dispatch (fsm=0x7f9d9488bbb0, event=0x7f9d90aecf20) at ../lib/core/ogs-fsm.c:127
7 0x000055a48275b32e in amf_main (data=0x0) at ../src/amf/init.c:149
8 0x00007f9de9a249eb in thread_worker (arg=0x55a483d41d90) at ../lib/core/ogs-thread.c:67
9 0x00007f9de8fd2b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
10 0x00007f9de9063bb4 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
Other NF instances are obtained through NRF
or created directly through configuration files.
Other NFs created by the config file should not be passed
through NRF discovery or anything like that.
Since self-created NF Instances do not have an ID,
they are implemented to exclude them from NRF Discovery.
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
== 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.
When a UE that requests slices tries to connect and there are no slices configured, the reject message is:
5GMM cause = 0x7 (5GS Services not allowed)
however it should be:
5GMM cause = 0x3e (No network slices available)
All 5GMM cause value in reject message is reviewed in this commit
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.
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.
1. UE registered and PDU established.
2. PCF does not receive Heartbeat.
- PCF De-registered state.
- Since PDU is established, SMF should not remove NF instance
3. PCF re-registered.
- HERE, WE NEED TO INCREASE NF REFERENCE COUNT.
Otherwise, NF instance will be removed if PCF is de-registered state
4. UE sends PDU release request.
5. Because SMF knows PCF NF instance, SMF can send PCF delete
* [CORE] tlv: Store mode in ogs_tlv_t
This allows specifying the format of the IE for each individual IE,
hence allowing messages containing IEs formatted in different ways.
This is needed in order to support parsing GTPv1-C, since messages
contain IEs with different structure (TLV vs TV). Hence, this is a
preparation patch to add support for parsing TVs in ogs-tlv.c/.h.
* [CORE] tlv: Support parsing msg with both TLV and TV in it
IEs of type TV are sometimes used in GTPv1-C. Current tlv parser/builder
doesn't provide with ways to parse messages which contain TV formatted
IEs. This patch adds the relevant types and ways to encode/decode them.
Furthermore, the current parser/builder allows parsing/building messages
containing the exact same format in all its IEs. A new parser function
is added which allows parsing messages of different types (TV, TLV)
mixed in the same message. In order to be able to do so, it uses the
general msg_mode passed to it in order to know the general TLV format
(in essence, the length of the Tag field, and also the length of the
Length field if applicable each IE).
Looking up the instance in the TLV description is left undone and
hadcoded to 0, since the only user so far requiring this API is GTPv1-C,
which has no instances.
* [CORE] tlv: Support repeated tag+instance parsing TLV message
In GTPv2C, repeated IEs (same tag) are easily differentiated by the
Instance byte, which provides info to match different decoded
structures. In GTPv1C though, there's no Instance byte, and we still
encounter repeated IEs (like GSN Address in Create PDP Context Request).
Hence, the TLV decoder needs to be updated to track count of IEs found
(identified by tag+instance, where instance is always 0 in GTPv1C) and
get the proper description index + offset into the decoded structure.
* [GTP]: Move GTPv2-C specifics to its own libgtp subdir
This will allow adding GTPv1-C code by the side. Most GTPv2 code is left
in this patch as "gtp" instead of renaming it to "gtp2" in order to
avoid massive changes. It can be done at a later stage if wanted.
* [GTP] Support generating GTPv1-C messages
* [SMF] Add Gn interface support
This patch introduces GTPv1C support to open5gs-smfd. With it,
open5gs-becomes a GGSN too, where SGSN can connect to, hence supporting
GERAN and UTRAN networks.
The network access mode of HSS has been changed to 0 (Packet and Circuit).
Versions of MME prior to v2.4.2 did not use this value. Open5GS set
the attach result of Attach Complete message as it is by looking
at the attach type of the Attach Request message.
Now, if the network access mode of HSS is set to 2 (Only Packet),
this value is affected by MME from v2.4.3. Regardless of the attach type
of the Attach Request, the MME will set EPS Only to the attach result
of Attach Complete.
3GPP TS 24.501 version 16.6.0 Release 16
4.4 NAS security
4.4.6 Protection of initial NAS signalling messages
1) the UE needs to send non-cleartext IEs in a REGISTRATION REQUEST
or SERVICE REQUEST message, the UE includes the entire REGISTRATION
REQUEST or SERVICE REQUEST message (i.e. containing both cleartext IEs
and non-cleartext IEs) in the NAS message container IE and shall cipher
the value part of the NAS message container IE. The UE shall then send
a REGISTRATION REQUEST or SERVICE REQUEST message containing
the cleartext IEs and the NAS message container IE;