You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current goal: implement UP initiated Assotiation Setup Request.
A detailed description of the progress on this issue can be found in its pull request: #497
Faced some problems while setting up associations in open5gs kubernetes environment.
Problem №1
All interactions in open5gs kubernetes are meant to happens through services (because pods can restart and change their IPs). In that case, two associations are established: one initiated from SMF and one initiated from UPF. These associations are treated as different because in both SMF and UPF the primary key to an association is the address, from which request/responce was received. So, UPF establishes association with SMF service, and SMF establishes association with UPF service. Both of them are working.
Problem №2
We can change a primary key to PFCP association from address to Node ID (a field in PFCP Association Setup Request/Response), as it was said in 3GPP specification. However, in such case two subproblem appear:
2.1. Heartbeats. When we get Heartbeat Request, how can we find specific association to that Heartbeat?
2.2. How can UPF understand when it should stop sending Requests? In config we set a service alias to connect to. But when UPF gets Response from SMF, there will be a Node ID of a SMF itself. For example, service name is "open5gs-smf-pfcp", and Node ID is some "10.244.1.24". So the question is: How can UPF know if it should sending Requests to a service?
Good solution!
UPF actually saves only one association.
But I suspect that SMF is storing two of them (with eUPF service and eUPF pod).
An evidence:
After the association initiated by UPF was established:
2023/12/15 17:10:18 INF Got Association Setup Response with CPFunctionFeatures from: 10.233.78.77. CPFunctionFeatures: 0
UPF receives an additional request from SMF (a later timestamp):
2023/12/15 17:10:21 INF Got Association Setup Request from: 10.233.78.77
Activity
[-]PFCP: Association Release support[/-][+]UP initiated association setup/release[/+]kade-ddnkv commentedon Nov 29, 2023
Association Setup Procedure
free5gc: "incomplete" support
open5gs: supports
Association Update Procedure
free5gc: doesn't support
open5gs: doesn't support
Association Release Procedure
free5gc: supports in its own way, no specification
open5gs: doesn't support
It turns out that the feature release is meaningless
kade-ddnkv commentedon Dec 9, 2023
The current goal: implement UP initiated Assotiation Setup Request.
A detailed description of the progress on this issue can be found in its pull request: #497
kade-ddnkv commentedon Dec 14, 2023
Current status:
Faced some problems while setting up associations in open5gs kubernetes environment.
Problem №1
All interactions in open5gs kubernetes are meant to happens through services (because pods can restart and change their IPs). In that case, two associations are established: one initiated from SMF and one initiated from UPF. These associations are treated as different because in both SMF and UPF the primary key to an association is the address, from which request/responce was received. So, UPF establishes association with SMF service, and SMF establishes association with UPF service. Both of them are working.
Problem №2
We can change a primary key to PFCP association from address to Node ID (a field in PFCP Association Setup Request/Response), as it was said in 3GPP specification. However, in such case two subproblem appear:
2.1. Heartbeats. When we get Heartbeat Request, how can we find specific association to that Heartbeat?
2.2. How can UPF understand when it should stop sending Requests? In config we set a service alias to connect to. But when UPF gets Response from SMF, there will be a Node ID of a SMF itself. For example, service name is "open5gs-smf-pfcp", and Node ID is some "10.244.1.24". So the question is: How can UPF know if it should sending Requests to a service?
PapaySail commentedon Dec 15, 2023
✔ Solution for setting up associations in open5gs kubernetes environment.
To set open5gs-smf-pfcp service as Headless
spec.clusterIP: Nonemanifest for headless service
kubectl apply -f <file>OK. Deployed with success. Fully testetd with 0-scenario.
Logs. SMF was started before UPF
SMF log:
eUPF start log:
eUFP log when UE is connected
kade-ddnkv commentedon Dec 19, 2023
Good solution!
UPF actually saves only one association.
But I suspect that SMF is storing two of them (with eUPF service and eUPF pod).
An evidence:
After the association initiated by UPF was established:
UPF receives an additional request from SMF (a later timestamp):
kade-ddnkv commentedon Dec 19, 2023
Both SMF and UPF services set to
ClusterIP: Nonemode.In such case UPF doesn't receive an Association Setup Request from SMF.
Only Response.
Logs (sorry for the encoding problems)
SMF logs:
eUPF logs:
[-]UP initiated association setup/release[/-][+]UP initiated association setup[/+]