This commit adds EMM Cause to Attach accept message when
Attach Request has COMBINED EPS IMSI ATTACH but the HSS
Network-Access-Mode is configure for EPS ONLY.
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/
TODO:
* Use an event for the report, like SMF_EVT_N4_TIMER?
* Properly set Service identifier in Gy CCR
* SMF: Properly set pkt/octet volumes in Gy CCR
** Update when receiving PFCP Modify Response.
* Figure out best way to require Gy through config file in open5gs-smfd.
* Create a new sess-sm.c which handles smf_sess_t state through
Gx+Gy+PFCP creation, modification and tear down. This way we can do
stuff in parallel, for instance Gx+Gy. It will alsoavoid duplicating
some code paths due to Gy being optional.
This commit adds required blocks in lib/diameter to be able to handle Gy
messages later in open5gs apps.
The Gy interface is mainly decribed in 3GPP TS 32.299 and 3GPP TS
32.251, which in turn refers to Diameter protcols defined in RFC4006.
This interface allows charging managment through an external OCS node.
The "Report Triggers" is sent SMF->UPF to tell in which situations a
report should be sent.
The "Usage Report Trigger" is sent UPF->SMF to indicate which situation
triggered the report.
Catch Origin-Host during CCA and set it as Destination-Host during
subsequent CCRs. This way we ensure UPDATE/TERMINATION Requests are sent
back explicitly to the same Diameter peer. Moreover, it seems
freediameter relies on this AVP to properly send the message over the
correct SCTP association when several diameter peers are available.
* [PFCP] Fix trailing whitespace in message generation files
* [PFCP] message gen: Support multiple URR ID IEs in Create PDR group
* [PFCP] Support associating multiple URRs to a PDR
According to 3GPP TS 29.244:
"""
A PDR shall contain:
- zero, one or more URRs, which contains instructions related to traffic measurement and reporting.
"""