Do not Set Origin-Hosts with fd_msg_rescode_set before potential use of ogs_diam_message_experimental_rescode_set. This results in multiple Origin-Host/Realm AVPs.
- 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.
Found no support for HSS provided charging characteristics. Following TS32.251 A.4:
- Use PDN level CC, if one wasn't provided then use subscription level CC
- Don't send CC in S11 if it wasn't included
For HSS's which do not include the NAM, the MME should not treat this as a fatal error. MME should just assume PACKET_AND_CIRCUIT (0), as was decided in a previous PR.
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.
The issue was introduced with the commit, which builds Open5GS from
local sources instead of downloading them each time from Github.
Fixes: d2cbcf711 ("[build] Use local sources to build applications (#1583)")
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
UDM may send a Deregistration Notification to AMF, to deregister
specific UE from the network - Network-Initiated Deregistration.
Deregistration procedure includes sending Deregistration Request to UE,
starting a timer T3522, releasing PDU sessions from SMF, releasing PCF
policies from PCF, and waiting for Deregistration Accept from UE.
Not yet implemented is:
- to prevent deregistration of UE in case it has any emergency sessions,
- page UE when UE is in IDLE mode.
According to TS 23.502, 4.2.2.2.2, AMF sends Registration event to UDM
in the following cases:
- If the AMF has changed since the last Registration procedure, or
- if the UE provides a SUPI which doesn't refer to a valid context in
the AMF,
- or if the UE registers to the same AMF it has already registered
to a non- 3GPP access (i.e. the UE is registered over a non-3GPP access
and initiates this Registration procedure to add a 3GPP access).
In case that UE re-registers to the network with a GUTI, it bypasses
authentication check to the AUSF. In this case, AMF does not send
Registration event to UDM.
Consequently, when UE deregisters again, AMF would send a Deregistration
Event to a UDM, which does not have a context for it.
3GPP standard does not say when AMF sends Deregistration Event to UDM,
only that it is optional.
These (De-)Registration events are for (de-)registering AMF to the UDM
for serving the UE. And not for (de-)registering UE itself for purpose
of tracking when UE is registered on the network.
This partially reverts commit 7be7029ac4
Don't attempt to restart systemd-networkd if systemd is not running
(e.g. installing open5gs inside a chroot).
Fix for:
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
dpkg: error processing package open5gs-upf:amd64 (--configure):
installed open5gs-upf:amd64 package post-installation script subprocess returned error exit status 1
Static code analysis can be executed with following commands:
meson build
ninja -C build analyze-cppcheck
ninja -C build analyze-clang-tidy
These commands are available only if additional tools are installed:
- cppcheck
- clang-tidy
- clang-tools is optional if you want to paralelize the clang-tidy
In case of cppcheck analysis, a file called build/cppchecklog.log is
created with the analysis results.
In case of clang-tidy analysis, some checks are disabled. See file
.clang-tidy, and reenable them if you see fit.
Also it does not scan all the files in the project, since some of them
are imported from other sources. It does not scan any sources under:
- subprojects/
- lib/asn1c/
- lib/ipfw/
Sukchan Lee
jmasterfunk84
Bostjan Meglic
Oliver Smith
Networkmama