Hello Aether Team,
We are trying to integrate components from a modern 5G core (in my case, the Open5GS UDM) with the Aether platform and have encountered a critical incompatibility in the NRF's NF
registration process.
The Problem
The issue seems to stem from a difference in the data models used for NF profiles.
- When the Open5GS UDM attempts to register with the NRF, it sends a profile containing the nfServiceList member, which is compliant with recent 3GPP specifications.
- However, the Aether NRF, upon successful registration, returns a profile that omits the nfServiceList. It appears to be operating based on an older specification that uses the
now-deprecated nfServices member.
As noted in 3GPP technical specifications (e.g., TS 29.510), the nfServices attribute has been deprecated in favor of nfServiceList.
Impact
This discrepancy results in the NRF returning an incomplete profile for the UDM. Consequently, other Network Functions cannot correctly discover or communicate with the UDM, ultimately
preventing User Equipment (UE) from connecting to the network.
Question & Possible Solution
We suspect this issue might be because the Aether NRF's API endpoints were generated from an older version of the 3GPP OpenAPI schemas.
Could you please confirm if this is the case? Are there any plans on your roadmap to update the NRF's data model to align with the current 3GPP specifications and support nfServiceList?
Thank you for your great work on this project and for your attention to this matter.
Hello Aether Team,
We are trying to integrate components from a modern 5G core (in my case, the Open5GS UDM) with the Aether platform and have encountered a critical incompatibility in the NRF's NF
registration process.
The Problem
The issue seems to stem from a difference in the data models used for NF profiles.
now-deprecated nfServices member.
As noted in 3GPP technical specifications (e.g., TS 29.510), the nfServices attribute has been deprecated in favor of nfServiceList.
Impact
This discrepancy results in the NRF returning an incomplete profile for the UDM. Consequently, other Network Functions cannot correctly discover or communicate with the UDM, ultimately
preventing User Equipment (UE) from connecting to the network.
Question & Possible Solution
We suspect this issue might be because the Aether NRF's API endpoints were generated from an older version of the 3GPP OpenAPI schemas.
Could you please confirm if this is the case? Are there any plans on your roadmap to update the NRF's data model to align with the current 3GPP specifications and support nfServiceList?
Thank you for your great work on this project and for your attention to this matter.