4G Roaming

[acetcom]

Open5GS Release, Revision, or Tag

v2.6.x

Components and subsystems

SMF

Proposed functionality

P-GW address derived via DNS resolution from S-GW with resolvers configurable by PLMN ID.

Refer to : https://www.gsma.com/newsroom/wp-content/uploads//IR.88-v25.0-17.pdf

• chapter 3.2.1.3.1 about the P-GW selection

External dependencies

No response

[farhadtaheri]

Hi @acetcom, Based on the IR.88 document, DEA is one of the important network functions in 4G roaming and has a similar functionality to SEPP. Is there any plan to develop DEA in this issue? Thanks

[svinson1121]

We had a successful test of 4G roaming (home routed) Data and VoLTE. using Open5GS 2.7.0, PyHSS (as the HSS and PCRF), and freeDiameter as the DRA/DEA using the rt_default module for routing and Nick's rt_pyform module to rewrite the Realm.

https://nickvsnetworking.com/diameter-routing-agents-part-5-avp-transformations-with-freediameter-and-python-in-rt_pyform/

only issue was we had to disable the SGSAP interface as even with the NAM set to PS only the MME was trying to do a location update over the SGS interface:

01/09 19:38:57.662: [mme] WARNING: [SGSAP] LOCATION-UPDATE-REJECT (../src/mme/sgsap-handler.c:151)

[laf0rge]

only issue was we had to disable the SGSAP interface as even with the NAM set to PS only the MME was trying to do a location update over the SGS interface:

It sounds a bit like this might be a bug. Did you check the relevant specs on what is the proper behavior in this case? If no SGsAP location update should be performed for NAM = PS-only, then it might make sense to file a bug report here. The fix should be trivial. Adding @pespin in the loop.

[svinson1121]

@laf0rge @pespin I only assumed if the NAM was set to PS only the SGsAP should not be active, after reading. ETSI TS 129 118 4.1 looks like that was correct.

"The basis for the interworking between a VLR and an MME is the existence of a SGs association between those entities per UE. The SGs association is applicable to UEs which are configured to use CS fallback and SMS over SGs, or SMS over SGs only. The SGs association is not applicable if the subscriber data indicates that the subscription is for packet only. The SGs association is also not applicable if the MME is registered for SMS for the UE as specified in 3GPP TS 23.272 [7]. "

I will check and make sure PyHSS is sending the correct NAM info to the MME if so, I will open a bug report.

Thank you,

[svinson1121]

@laf0rge @pespin
I would also add contrary to the current behavior, a location LOCATION-UPDATE-REJECT from the SGsAP should only affect the SGs association, and not cause a UE attach reject. but I have not researched this. for example: if the UE has a valid account in the HSS but no account in the HLR it should be allowed to attach with no SGs association.

[svinson1121]

Has ETSI TS 129 303 Section 5.1 'Procedures for Discovering and Selecting a PGW' been implemented in the Open5GS MME?

[Runamook]

We had a successful test of 4G roaming (home routed) Data and VoLTE. using Open5GS 2.7.0, PyHSS (as the HSS and PCRF), and freeDiameter as the DRA/DEA using the rt_default module for routing and Nick's rt_pyform module to rewrite the Realm.

https://nickvsnetworking.com/diameter-routing-agents-part-5-avp-transformations-with-freediameter-and-python-in-rt_pyform/

only issue was we had to disable the SGSAP interface as even with the NAM set to PS only the MME was trying to do a location update over the SGS interface:

01/09 19:38:57.662: [mme] WARNING: [SGSAP] LOCATION-UPDATE-REJECT (../src/mme/sgsap-handler.c:151)

How did you select the home PGW in your test?

[svinson1121]

How did you select the home PGW in your test?

PyHSS allow you to set a static address for the PGW:

{ "apn": "internet", "arp_priority": 8, "nidd_mechanism": null, "ip_version": 2, "arp_preemption_capability": false, "nidd_rds": null, "pgw_address": "10.90.250.23", "arp_preemption_vulnerability": false, "nidd_preferred_data_mode": null, "sgw_address": "10.90.250.25", "charging_rule_list": "3", "last_modified": "2024-07-07T00:15:32Z", "charging_characteristics": "0800", "nbiot": false, "apn_ambr_dl": 200000000, "nidd_scef_id": null, "apn_id": 1, "apn_ambr_ul": 50000000, "nidd_scef_realm": null, "qci": 9 },

[Runamook]

How did you select the home PGW in your test?

PyHSS allow you to set a static address for the PGW:

{ "apn": "internet", "arp_priority": 8, "nidd_mechanism": null, "ip_version": 2, "arp_preemption_capability": false, "nidd_rds": null, "pgw_address": "10.90.250.23", "arp_preemption_vulnerability": false, "nidd_preferred_data_mode": null, "sgw_address": "10.90.250.25", "charging_rule_list": "3", "last_modified": "2024-07-07T00:15:32Z", "charging_characteristics": "0800", "nbiot": false, "apn_ambr_dl": 200000000, "nidd_scef_id": null, "apn_id": 1, "apn_ambr_ul": 50000000, "nidd_scef_realm": null, "qci": 9 },

So open5Gs will use a static PGW assignment from S6a. But DNS-based PGW is not supported now.

Is my understanding correct?

[svinson1121]

That's correct. I did some testing on the Open5GS-MME, and it did not appear to support DNS-based PGW selection.