UPF does not send Service Request if the NOCP flag is set the second time

[sysarch-repo]

UPF build:
imageName: oai-spgwu-tiny
imageFolder: rdefosseoai
imageVersionTag: 'v1.2.0'

To deactivate the DL, the SMF modifies an existing N4 session by sending PFCP Session Modification Request and modifies the FAR rule for DL to DROP the received packets and to notify the SMF about received DL data (for MT access / Paging). This works as expected for MT access during the first CM-IDLE mode of the UE:

Upon the Session Report sent by the UPF, the SMF updates the FAR rule to FORW and includes the Forwarding parameters:

The DL traffic flows as expected.

But during the second CM-IDLE phase, once the DL FAR of the same N4 session is again modified to DROP the received packets and to notify the SMF about received DL data (for MT access / Paging), there is no Session Report sent by the UPF to the SMF anymore.

Note, the UL and DL PDRs are using QER rule with both gates (UL/DL) set to OPEN for the duration of the session. My understanding is that the QER rule should not impact the deactivation (DROP/NOCP) and activation (FORW) of the DL traffic forwarding by the means of the FAR rule, i.e. the DL gate does not have to be CLOSED for the duration of the DL flow deactivation.

Network setup:

ubuntu@domainmgr1:~$ kubectl exec -it -n free-5gc -c debug f5gc-upf-85b94f7bdd-pkg6j -- sh
/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if1793: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
    link/ether 4a:52:bb:0b:c3:97 brd ff:ff:ff:ff:ff:ff
    inet 10.233.109.178/32 brd 10.233.109.178 scope global eth0
       valid_lft forever preferred_lft forever
4: eth1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:88:88:bd brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.202/24 brd 10.10.20.255 scope global eth1
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 500
    link/[65534]
    inet 12.1.0.1/16 scope global tun0
       valid_lft forever preferred_lft forever
/ # ip rule list
0:      from all lookup local
32765:  from 10.10.20.202 lookup 100
32766:  from all lookup main
32767:  from all lookup default
/ # ip r list table 100
default via 10.10.20.1 dev eth1
10.10.20.0/24 dev eth1 scope link  src 10.10.20.202
/ # ip r
default via 169.254.1.1 dev eth0
12.1.0.0/16 dev tun0 scope link  src 12.1.0.1
169.254.1.1 dev eth0 scope link

There is nothing suspicious seen in the UPF trace during the processing of the last session modification request:

[2022-03-30T15:18:37.451179] [spgwu] [spgwu_sx ] [info ] TIME-OUT event timer id 149
[2022-03-30T15:18:37.453721] [spgwu] [spgwu_sx ] [info ] TIME-OUT event timer id 150
[2022-03-30T15:18:37.453797] [spgwu] [spgwu_sx ] [info ] PFCP HEARTBEAT PROCEDURE hash 3457419786 starting
[2022-03-30T15:18:37.455509] [spgwu] [spgwu_sx ] [info ] handle_receive(16 bytes)
[2022-03-30T15:18:37.455592] [spgwu] [spgwu_sx ] [info ] Received SX HEARTBEAT RESPONSE
[2022-03-30T15:18:38.795860] [spgwu] [spgwu_sx ] [info ] handle_receive(33 bytes)
[2022-03-30T15:18:38.796152] [spgwu] [spgwu_app] [info ] Received SXAB_SESSION_MODIFICATION_REQUEST seid 0x1
[2022-03-30T15:18:42.454298] [spgwu] [spgwu_sx ] [info ] TIME-OUT event timer id 153
[2022-03-30T15:18:42.455789] [spgwu] [spgwu_sx ] [info ] TIME-OUT event timer id 154
[2022-03-30T15:18:42.455861] [spgwu] [spgwu_sx ] [info ] PFCP HEARTBEAT PROCEDURE hash 3457419786 starting
[2022-03-30T15:18:42.457895] [spgwu] [spgwu_sx ] [info ] handle_receive(16 bytes)
[2022-03-30T15:18:42.457998] [spgwu] [spgwu_sx ] [info ] Received SX HEARTBEAT RESPONSE