Support for Multiple DNNs per Device Group with a Single UPF #929

anaswarac-dac · 2025-07-16T12:09:12Z

📌 Description:
This PR introduces support for associating multiple DNNs to a single device group in the 5G Core, enabling flexible and scalable configurations in deployments with a single UPF.

✅ Key Highlights:
Introduced configuration support for multiple DNNs per IMSI range in the sdcore-5g-values.yml file.

Each DNN can have its own:

IP pool

MTU

DNS

UE QoS profile (including MBR uplink/downlink and traffic class)

Validated end-to-end traffic flow for both ims and internet DNNs over the same UPF.

📂 Configuration Changes (in sdcore-5g-values.yml):

✅ device-groups Section:

ip-domains list now includes multiple DNNs (ims, internet) under a single group (gnbsim-user-group1).
ip-domain-expanded changed to ip-domains
Each DNN is mapped to a different ue-ip-pool and ue-dnn-qos.
device-groups:
- name: "gnbsim-user-group1"
imsis:
- "208930100007487"
- "208930100007488"
- "208930100007489"
- "208930100007490"
- "208930100007491"
- "208930100007492"
- "208930100007493"
- "208930100007494"
- "208930100007495"
- "208930100007496"
ip-domain-name: "pool1"
ip-domains:
- dnn: ims
dns-primary: "8.8.8.8"
mtu: 1400
ue-ip-pool: "172.252.0.0/16"
ue-dnn-qos:
dnn-mbr-downlink: 2400
dnn-mbr-uplink: 1200
bitrate-unit: Kbps
traffic-class:
name: "platinum"
qci: 5
arp: 1
pdb: 100
pelr: 6
- dnn: internet
dns-primary: "10.176.0.11"
mtu: 1460
ue-ip-pool: {{ core.upf.default_upf.ue_ip_pool }}
ue-dnn-qos:
dnn-mbr-downlink: 1000
dnn-mbr-uplink: 1000
bitrate-unit: Mbps
traffic-class:
name: "platinum"
qci: 9
arp: 6
pdb: 300
pelr: 6
site-info: "enterprise"

✅ Userplane Section:
Defined dnn_list with individual DNNs and their respective ue_ip_pool.
cpiface:
dnn_list:
- dnn: "ims"
ue_ip_pool: "172.252.0.0/16"
- dnn: "internet"
ue_ip_pool: "172.250.0.0/16" # Must match slice DNN
hostname: "upf"
enable_ue_ip_alloc: false

Signed-off-by: anaswara <anaswara.n@cdac.in>

gab-arrobo

Based on my preliminary testing and the changes, this PR should be independent of the other PRs you opened, correct? If so, we could proceed to merge it after the comments/suggestions have been addressed

gab-arrobo · 2025-07-16T17:13:09Z

conf/upf.jsonc

+        "dnn_list": [
+            {
+                "dnn": "internet",
+                "ue_ip_pool": "10.250.0.0/16"


Given that now you have the ue_ip_pool here, should not it be removed from below?

// "hostname": "upf-0", "ue_ip_pool": "10.250.0.0/16" },

gab-arrobo · 2025-07-16T17:16:58Z

conf/upf.jsonc

+        "dnn_list": [
+            {
+                "dnn": "internet",
+                "ue_ip_pool": "10.250.0.0/16"


Also, can we please update this to use a private IP range/pool?

@gab-arrobo Isn't it like 10.0.0.0/8 is complete Class A private IP address range. So 10.250.0.0/16 is part of private IP address range.

@gab-arrobo Isn't it like 10.0.0.0/8 is complete Class A private IP address range. So 10.250.0.0/16 is part of private IP address range.

My bad. I misread this... for some reason I thought it was 172.250.0.0/16 (as it was in OnRamp before). @anaswarac-dac please disregard this comment

gab-arrobo · 2025-07-16T17:30:02Z

pfcpiface/config.go

+	HTTPPort        string    `json:"http_port"`
+	DnnList         []DNNInfo `json:"dnn_list"`
+	EnableUeIPAlloc bool      `json:"enable_ue_ip_alloc"`
+	UEIPPool        string    `json:"ue_ip_pool"`


Given that you are moving the UEIPPool to inside DNNInfo, should not it be removed from here?

Suggested change

UEIPPool string `json:"ue_ip_pool"`

Yes we should remove UEIPPool config from here and also look at the functionality of enable_ue_ip_alloc flag.

gab-arrobo · 2025-07-16T17:32:26Z

pfcpiface/messages_session.go

 		if p.UPAllocateFteid {
 			var fteid uint32
+			if pConn.upf.fteidGenerator == nil {
+				logger.PfcpLog.Warnf("fteid is nill")


Suggested change

logger.PfcpLog.Warnf("fteid is nill")

logger.PfcpLog.Warnf("fteid is nil")

gab-arrobo · 2025-07-16T17:34:11Z

pfcpiface/up4.go


-	up4.ueIPPool = MustParseStrIP(conf.CPIface.UEIPPool)
+	if len(conf.CPIface.DnnList) > 0 {
+		up4.ueIPPool = MustParseStrIP(conf.CPIface.DnnList[0].UEIPPool)


Does this mean that a device group can support multiple DNNs (which includes dnn itself and UE IP pool) but only the IP pool for the first dnn is actually used?

it seems like up4 should support multiple IP pools now ?

@patriciareinoso as far as I see we do not have any active user for UP4. @gab-arrobo are you aware about any users?

Well, we need to decide what to do with that code (whether maintain it or remove it) because, as far as I know, we are not supporting UP4 anymore. So, I would say that we should remove it. Probably this is something we should bring to the TST meeting

@gab-arrobo When we added multiple DNNs, the integration test for UP4 failed.

gab-arrobo · 2025-07-16T17:36:20Z

pfcpiface/upf.go

+	for _, dnnInfo := range conf.CPIface.DnnList {
+		dnns = append(dnns, dnnInfo.DNN)
+		if ippoolCidr == "" {
+			ippoolCidr = dnnInfo.UEIPPool


In relation to my previous comment, here it actually looks like the UE IP pool for the last DNN is used, correct? or am I overlooking something?

gab-arrobo · 2025-07-16T17:37:45Z

ptf/config/upf.jsonc

+        "dnn_list": [
+            {
+                "dnn": "internet",
+                "ue_ip_pool": "10.250.0.0/16"


Same comment as in the other jsonc file. Should not the ue_ip_pool be removed from below (new line 168)

gab-arrobo · 2025-07-16T17:38:38Z

test/integration/conf.go

-		UEIPPool:        UEPoolUPF,
+		DnnList: []pfcpiface.DNNInfo{
+			{
+				UEIPPool: UEPoolUPF,


Any reason why you are not setting the DNN here?

gab-arrobo · 2025-07-16T17:38:57Z

test/integration/conf.go

-		UEIPPool: UEPoolCP,
+		DnnList: []pfcpiface.DNNInfo{
+			{
+				UEIPPool: UEPoolCP,


Any reason why you are not setting the DNN here?

gab-arrobo · 2025-07-16T17:39:03Z

test/integration/conf.go

-		UEIPPool:        UEPoolUPF,
+		DnnList: []pfcpiface.DNNInfo{
+			{
+				UEIPPool: UEPoolUPF,


Any reason why you are not setting the DNN here?

patriciareinoso · 2025-07-17T09:47:43Z

pfcpiface/upf.go

 	ippool            *IPPool
 	peers             []string
-	dnn               string
+	dnn               []string


Suggested change

dnn []string

dnns []string

i think that making it plural would represent the multiple dnns better

patriciareinoso · 2025-07-17T09:55:46Z

pfcpiface/config.go

-		if err != nil {
-			return ErrInvalidArgumentWithReason("conf.UEIPPool", conf.CPIface.UEIPPool, err.Error())
+		for _, dnn := range conf.CPIface.DnnList {
+			_, _, err := net.ParseCIDR(dnn.UEIPPool)


should we check that dnn is not an empty string?

Hmm. It seems good idea to check the pool validity. But see we have error handling as well. so that will indirectly handle the configuration error?

patriciareinoso · 2025-07-17T10:16:47Z

ptf/config/upf.jsonc

        "peers": ["148.162.12.214"],
        // [Optional] Below parameters
-        "dnn": "internet",
+        "dnn_list": [


these parameter are marked as optionals but in pfcpiface/up4.go there is a fatal log if the IP pool is not present. Is the dnn_list mandatory?

if we set the dnn_list, should we make sure that both the dnn and ip pool are set ?

patriciareinoso · 2025-07-17T10:22:15Z

conf/upf.jsonc

    // Control plane controller settings
    "cpiface": {
        "peers": ["148.162.12.214"],
        // [Optional] Below parameters


same comment as in ptf/config/upf.jsonc

patriciareinoso · 2025-07-17T10:27:25Z

pfcpiface/config.go

 		if _, ok := validModes[conf.Mode]; !ok {
 			return ErrInvalidArgumentWithReason("conf.Mode", conf.Mode, "invalid mode")
 		}
 	}


in this function there are 2 checks over the DnnList that seem redundant. One is done if EnableUeIPAlloc is true and the other if EnableP4rt is true.
Later on in the code, the information in DnnList seems to be used regardless of these 2 conditions being true or false.
Should the checks be done once here in this function, even if the 2 conditions are false?

patriciareinoso

Please update https://github.com/omec-project/upf/blob/main/docs/configuration-guide.md
I added some comments to better understand the approach that will be used. I have some concerns regarding the possibility of setting multiple IP pools but in fact only using one
What happens if 2 device groups within the same network slice share the same DNN ? does it mean that they need to use the same IP pool?

thakurajayL · 2025-07-18T01:07:55Z

2 Generic comments

Consider updating README file with multi-dnn support
It would be great if we start adding Tests to cover this change.

thakurajayL · 2025-07-18T00:56:59Z

pfcpiface/config.go

+	HTTPPort        string    `json:"http_port"`
+	DnnList         []DNNInfo `json:"dnn_list"`
+	EnableUeIPAlloc bool      `json:"enable_ue_ip_alloc"`
+	UEIPPool        string    `json:"ue_ip_pool"`


Yes we should remove UEIPPool config from here and also look at the functionality of enable_ue_ip_alloc flag.

thakurajayL · 2025-07-18T00:57:33Z

pfcpiface/config.go

+
+type DNNInfo struct {
+	DNN      string `json:"dnn"`
+	UEIPPool string `json:"ue_ip_pool"`


Please add enable_ue_ip_alloc flag in this structure and see the flow around this flag.

thakurajayL · 2025-07-18T00:59:03Z

pfcpiface/config.go

-		if err != nil {
-			return ErrInvalidArgumentWithReason("conf.UEIPPool", conf.CPIface.UEIPPool, err.Error())
+		for _, dnn := range conf.CPIface.DnnList {
+			_, _, err := net.ParseCIDR(dnn.UEIPPool)


Hmm. It seems good idea to check the pool validity. But see we have error handling as well. so that will indirectly handle the configuration error?

thakurajayL · 2025-07-18T01:02:01Z

pfcpiface/fteid.go


 // Allocate and return an id in range [minValue, maxValue]
 func (idGenerator *FTEIDGenerator) Allocate() (uint32, error) {
+	if idGenerator == nil {


This change is redundant. Everytime we create upf object we assign/create FTEID Generator block. Perhaps you saw crash and that is the reason you want to add this nil check. But remember there is likely chance that we are masking some other bug by adding this nil check.

@anaswarac-dac - please confirm why this change is needed. As I said this is likely not required. Issue could be something else.

You're right — ideally the FTEIDGenerator should never be nil, as it's initialized during UPF object creation. However, I added this nil check because during testing I encountered a crash due to a nil dereference in this function.

thakurajayL · 2025-07-18T01:05:23Z

pfcpiface/messages_conn.go

 func (pConn *PFCPConn) associationIEs() []*ie.IE {
 	upf := pConn.upf
-	networkInstance := string(ie.NewNetworkInstanceFQDN(upf.dnn).Payload)
+	networkInstance := string(ie.NewNetworkInstanceFQDN(strings.Join(upf.dnn, ",")).Payload)


Could you please help me understand why this change is needed. It seems you are trying to add more DNNs in single message?

@thakurajayL ,Currently, the PFCP Association Setup Request is initiated by the SMF. The UPF responds with only one DNN. After that, no further PFCP Association Setup Request is triggered by the SMF, which means there's no opportunity to send additional DNNs separately. Because of this limitation, we include all required DNNs in a single PFCP Association Setup Request to ensure that the SMF receives the full list in one go.

I would like to know which version of 29.244 you are referring to. As specification around this area has changed drastically in release 15/16/17.

@thakurajayL ,We are following 3GPP TS 29.244 v16.5.0 (Release 16), and as per this version, User Plane IP Resource Information (IE Type 116) was removed. Instead, we are required to use UE IP Address Pool Information (IE Type 123) in the PFCP Association Setup Response.

As Per Section 7.2.2.2 of the spec, this IE allows the UPF to report multiple DNN and IP pool mappings to the SMF in a single response by including multiple UE IP Address Pool Information IEs, each containing:

DNN (Network Instance),

UE IP Pool Identity,

and IP version.

This change is necessary because:

The PFCP Association Setup Request is sent only once by the SMF to the UPF.

The UPF must respond once with all supported DNNs and corresponding UE IP pools.

If we send only one DNN in the PFCP Association Setup Response, the SMF won’t be aware of other available DNNs/pools, and there's no further opportunity to send them due to the single-shot nature of the PFCP association procedure.

Spec Reference:

TS 29.244 v16.5.0, Section 6.2.6.2.2:
"Optionally one or more UE IP address Pool Information IE which contains a list of UE IP Address Pool Identities per Network Instance, S-NSSAI and IP version."

DNN | Pool | IP Version

ims | ims-pool | IPv4
internet | internet-pool | IPv4

Will Update the code based on this?

anaswarac-dac · 2025-07-18T13:41:52Z

@gab-arrobo , @thakurajayL , @patriciareinoso I have made the changes based on your comments. However, I'm currently unable to build because the integration-test-up4 and integration-test-bess are failing. I'm debugging the issue and will proceed with testing using COTS UEs once it's resolved.

gab-arrobo · 2025-08-18T01:45:28Z

@anaswarac-dac,
Please rebase your PR

Feat: Multiple DNN

be21356

Signed-off-by: anaswara <anaswara.n@cdac.in>

anaswarac-dac force-pushed the feat-multiple-dnn branch from cb22dba to be21356 Compare July 16, 2025 12:41

gab-arrobo requested changes Jul 16, 2025

View reviewed changes

patriciareinoso reviewed Jul 17, 2025

View reviewed changes

patriciareinoso suggested changes Jul 17, 2025

View reviewed changes

thakurajayL self-assigned this Jul 18, 2025

thakurajayL added the enhancement New feature or request label Jul 18, 2025

thakurajayL requested changes Jul 18, 2025

View reviewed changes

	logger.PfcpLog.Warnf("fteid is nill")
	logger.PfcpLog.Warnf("fteid is nil")

Support for Multiple DNNs per Device Group with a Single UPF #929

Are you sure you want to change the base?

Support for Multiple DNNs per Device Group with a Single UPF #929

Conversation

anaswarac-dac commented Jul 16, 2025

Uh oh!

gab-arrobo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

patriciareinoso Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

patriciareinoso left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thakurajayL commented Jul 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anaswarac-dac Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

patriciareinoso Jul 17, 2025 •

edited

Loading

patriciareinoso left a comment •

edited

Loading

anaswarac-dac Jul 18, 2025 •

edited

Loading

anaswarac-dac Jul 21, 2025 •

edited

Loading