Skip to content

Refactor SMF PFCP associations to always use UPF info

Stefan Spettel requested to merge pfcp_refactor into develop

Logical changes

  • Each UPF has now a UPF profile associated
  • in case there is no UPF profile (not in config or UPF-initiated PFCP association): Create a default UPF profile with an assumed N3 and N6 interface
  • Reason: We had many cases where we differentiate if upf profile is set, now we can delete all these checks
  • Preparation for a further UPF graph / edge / QoS flow refactor

Fixes / Implements

  • Implements #47
  • Implements #22 -> We can now have different UPF config (e.g. enable URR and disable) for different UPFs. IN THEORY we could even run OAI-UPF, VPP-UPF and SD Fabric together
  • Should implement #6 (@tien-thinh.nguyen can you confirm this?)
  • UPF is now not resolved immediately upon SMF start, but we try it 10 times every 2 seconds
  • Also SMF does not crash anymore if UPF could not be resolved, but just does not initiate a PFCP association
  • @arora the last two changes are interesting for docker-compose and k8s -> It is much more stable now and the order of NFs is not that strict anymore

Refactorings

  • regenerated NotificationData and associated model classes

    • will be moved to common-src in a further refactor (as they come from NRF)
    • use OpenAPI model class for noficationData within SMF
  • Simplify handling of NF UPF notifcation and UPF assocation start a bit in smf_app

  • Remove unnecessary code in smf_config.hpp

Tests

Edited by Stefan Spettel

Merge request reports