Change PFCP node search order, fix typo, add feature to disable RR for a node

[kbarlee]

Hey @acetcom - another one for you!

The first commit deals with the first point in #559, flipping the search order from TAC/APN/cell_ID to APN/ cell_ID/ TAC

This means the logic for (eg) the SMF is now:

1. Search through node list to see if any are dedicated to support the APN
   -- round robin between nodes that support the APN && are PFCP associated
   -- if there are none, move to 2

2. Search through node list to see if any are dedicated to support the e_cell_ID
   -- round robin between nodes that support the e_cell_ID && are PFCP associated
   -- if there are none, move to 3

3. Search through node list to see if any are dedicated to support the nr_cell_ID
   -- round robin between nodes that support the nr_cell_ID && are PFCP associated
   -- if there are none, move to 4

4. Search through node list to see if any are dedicated to support the TAC
   -- round robin between nodes that support the TAC && are PFCP associated
   -- if there are none, move to 5

5. Round robin full list. Use next PFCP associated node.

---

Second commit is fixing a copy paste typo in the SGWC config file

---

Third implements a feature to disable RR for a particular node. This deals with this situation described in in #559 where you want to avoid a dumb RR choice:

In full list RR mode...

After PR #556 merge we now select the next PFCP associated node and call it a day. This is sound logic, but could end up making a dumb choice, as it may choose a userplane server that is at the end of a very slow broadband line, or one where the firewall is not set up to receive incoming connections, or there is no VPN in place to connect from an eNB/gNB to the userplaneserver.

So I would propose a feature here, where we add an optional flag to the node list (that would be parsed in lib/pfcp/context.c) to disable full list RR mode for a particular node:

By default, RR is still enabled for every node. So if you miss the variable from the PFCP node list it doesn't make any difference. After running through the tests for matching APN, then cell_ID, then TAC and we go into full list round robin, all PFCP associated nodes are eligible for use.

If we add the additional flag, rr: 0 to a node, when we are in this full list round robin mode, the node will be skipped. This is to avoid the dumb choice I was talking about.

    pfcp:

      - addr: 127.0.1.4  # userplaneserver1 for IMS (centralised)
        apn: ims

      - addr: 127.0.2.4  # userplaneserver2 for TAC 1 region
        tac: 1

      - addr: 127.0.3.4  # userplaneserver3 for TAC 2 region
        tac: 2

      - addr: 127.0.4.4  # userplaneserver4 at cell site
        e_cell_id: 123
        nr_cell_id: 321
        rr: 0            # do not allow this userplaneserver to be selected when performing full list RR, 
                         #  as there is no S1U/N3 VPN to other eNB/gNBs

      - addr: 127.0.5.4  # userplaneserver5 at cell site
        e_cell_id: 456
        nr_cell_id: 654
        rr: 0            # do not allow this userplaneserver to be selected when performing full list RR, 
                         #  as there is no S1U/N3 VPN to other eNB/gNBs

      - addr: 127.0.6.4  # userplaneserver6 for edge compute use case 1
        apn: mec1

      - addr: 127.0.7.4  # userplaneserver7 for edge compute use case 2
        apn: mec2

      - addr: 127.0.8.4  # userplaneserver8 at cell site, also used for edge compute use case 3
        e_cell_id: 789
        nr_cell_id: 897
        apn: mec3

I've tested this with the SGWC, SMF and x4 SGWU/UPF servers, and it all seems to hold up.

Cheers
Kenny

[acetcom]

@kbarlee

That's a really good idea. I have merged your work.

Thank you very much!
Sukchan

[kbarlee]

No worries! I'm just thinking through issues I will encounter in my own deployment scenarios!