Split out of #89, where it surfaced.
What happens
ggsn_gn:handle_request/5 for a secondary PDP context (Create PDP Context with a Linked NSAPI) adds {'Access', NSAPI} to the bearer map, CP-allocates a TEID for it, runs one PFCP Session Modification and returns that TEID in the Create PDP Context Response.
No PDR is ever created for that NSAPI. PDRs are built from PCC rules, and smf_gsn_lib:resolve_access_bearer/2 binds a rule to {'Access', EBI} only through a {qci_arp, QCI, ARP} entry or a bearer-id. The secondary PDP context path registers neither:
$ grep -n "qci_arp\|bearer_id," apps/smf_core/src/ggsn_gn.erl
(no output)
So the GGSN advertises a GTP-U TEID that no PDR matches. Uplink packets the MS sends on the secondary context should not match anything in the UPF.
Why it has gone unnoticed
The CP-assigned TEID makes the control plane look correct end to end: the response is well formed and ggsn_SUITE:secondary_pdp_context_create passes, because it asserts on the GTP-C exchange and never sends user-plane traffic on the secondary NSAPI.
How it surfaced
While fixing #89 I switched this path to the FTUP CHOOSE placeholder, the way the primary context and (since #88) additional Create Session bearers already do. With no PDR for the bearer, the UP never allocates, the placeholder survives into the GTP-C response, and encoding fails:
gtp send failed with error:badarg
[{gtp_packet,encode_v1_element,1,
... cause => {1,integer,type,{upf,{'Access',6}}}
That badarg is the symptom; the missing PDR is the defect. It is why #89's "recoverable in place" plan for this site does not work — allocation mode is moot for a bearer with no PDR.
What a fix needs
Decide what binds a rule to the secondary context's NSAPI. TS 23.060 has the secondary PDP context carry its own TFT and QoS profile, so the natural analogue of the EPS dedicated bearer is to register {qci_arp, QCI, ARP} => NSAPI from the requested QoS profile and let the matching rule bind — but that presumes a rule at that QCI exists, which for a purely MS-requested secondary context may not be true. Worth checking pdp-context-lifecycle-gprs.md and gn-gp-eps-interoperation.md on what the GGSN is required to install.
Test gap
ggsn_SUITE:secondary_pdp_context_create should assert that traffic on the secondary NSAPI reaches the UPF, not just that the response is well formed. Without that, any fix here is unverifiable.
Related: #89 (F-TEID allocation mode), #88 (the same shape of defect on the Create Session multi-bearer path).
Split out of #89, where it surfaced.
What happens
ggsn_gn:handle_request/5for a secondary PDP context (Create PDP Context with a Linked NSAPI) adds{'Access', NSAPI}to the bearer map, CP-allocates a TEID for it, runs one PFCP Session Modification and returns that TEID in the Create PDP Context Response.No PDR is ever created for that NSAPI. PDRs are built from PCC rules, and
smf_gsn_lib:resolve_access_bearer/2binds a rule to{'Access', EBI}only through a{qci_arp, QCI, ARP}entry or a bearer-id. The secondary PDP context path registers neither:So the GGSN advertises a GTP-U TEID that no PDR matches. Uplink packets the MS sends on the secondary context should not match anything in the UPF.
Why it has gone unnoticed
The CP-assigned TEID makes the control plane look correct end to end: the response is well formed and
ggsn_SUITE:secondary_pdp_context_createpasses, because it asserts on the GTP-C exchange and never sends user-plane traffic on the secondary NSAPI.How it surfaced
While fixing #89 I switched this path to the FTUP CHOOSE placeholder, the way the primary context and (since #88) additional Create Session bearers already do. With no PDR for the bearer, the UP never allocates, the placeholder survives into the GTP-C response, and encoding fails:
That badarg is the symptom; the missing PDR is the defect. It is why #89's "recoverable in place" plan for this site does not work — allocation mode is moot for a bearer with no PDR.
What a fix needs
Decide what binds a rule to the secondary context's NSAPI. TS 23.060 has the secondary PDP context carry its own TFT and QoS profile, so the natural analogue of the EPS dedicated bearer is to register
{qci_arp, QCI, ARP} => NSAPIfrom the requested QoS profile and let the matching rule bind — but that presumes a rule at that QCI exists, which for a purely MS-requested secondary context may not be true. Worth checkingpdp-context-lifecycle-gprs.mdandgn-gp-eps-interoperation.mdon what the GGSN is required to install.Test gap
ggsn_SUITE:secondary_pdp_context_createshould assert that traffic on the secondary NSAPI reaches the UPF, not just that the response is well formed. Without that, any fix here is unverifiable.Related: #89 (F-TEID allocation mode), #88 (the same shape of defect on the Create Session multi-bearer path).