NRF does not notify SMF of previously registered UPFs
Scenario
Please see attached PCAP. It is from the slicing scenario. The NRF is the NRF for slice 1 and 2.
NRF Slice 1/2: 192.168.70.136
SMF Slice 1: 192.168.70.139
SMF Slice 2: 192.168.70.140
UPF Slice 1: 192.168.70.142
UPF Slice 2: 192.168.70.143
- Packet 55: UPF Slice 2 registers on NRF
- Packet 104: SMF Slice 2 registers its UPF subscription on NRF
- Packet 112: SMF Slice 2 registers on NRF
- Packet 134: SMF Slice 1 registers its UPF subscription on NRF
- Packet 147: NRF sends notification about UPF Slice 2 towards SMF Slice 1
- Packet 211: UPF Slice 1 registers on NRF
- Packet 224: NRF sends notification about UPF Slice 1 towards SMF Slice 2
- Packet 228: NRF sends notification about UPF Slice 2 towards SMF Slice 1
The issue here now is that SMF Slice 1 has both UPFs in its graph and is able to select based on NSSAI.
SMF Slice 2 however has only UPF Slice 1 and therefore, the PDU session establishment fails.
Fix
A potential fix is to send all NFs which are already stored upon SMF subscription, so it would immediately become available. Currently, NRF only "reacts" to a UPF registration when the SMF subscription is already there.
A quick fix for the slicing tutorial is to add depends_on, but we should get rid of these.
Issue
These scenarios are quite hard to debug and we should not introduce these dependencies between NFs. I only tested it using HTTP/2
Discussion
I did not read the standard about this, but in my opinion the fix described here makes the most sense, but maybe there is another trigger we have to activate on SMF. @tien-thinh.nguyen @arora @defosseu @kharade Any opinions on this? Let us discuss this in our next meeting.