feat(nfConfigApi): add guaranteed bit rate to PccQos

[midwell]

What

Adds gbrUl and gbrDl to the PccQos schema in nfConfigApi/webconsole-api.yaml and the
corresponding optional GbrUl/GbrDl fields to nfConfigApi.PccQos, beside the existing
MaxBrUl/MaxBrDl.

Why

PccQos can express a maximum bit rate per flow but not a guaranteed one, so a policy served
through this API can only ever describe a ceiling. A GBR 5QI needs both: TS 23.501 table 5.7.4-1
defines GFBR and MFBR as separate QoS parameters for GBR and delay-critical GBR resource types,
and the SMF needs the guaranteed value to populate the GBR IE toward the UPF and the QoS flow
description toward the UE.

Concretely this is what lets WebConsole publish a committed rate alongside the peak rate, so a
deployment can offer a service with a floor rather than only a cap. Both fields are optional, so a
Non-GBR flow carries neither and serialises exactly as it does today.

Note on regeneration

The models carry DO NOT EDIT, so I want to be transparent that this field was hand-written, and
about how I checked it.

The repository commits no generator configuration, script or make target, and nfConfigApi is the
only package without a README.md recording its generator version. A stock run of the generator
differs from the committed files by 40 to 91 lines in every one of the 17 models in this package:
disallowAdditionalPropertiesIfNotPresent=false is needed just to emit the AdditionalProperties
support the committed code has, and after that around 70 lines per file remain that look like
post-processing this repository applies — openapi.IsNil and openapi.MappedNullable from the
parent module in place of the package-local copies the generator emits, yaml: tags beside every
json: tag, maps.Copy in place of the generated loop, and the SPDX headers.

So regenerating would produce a large diff unrelated to this change. Instead I used the generator
as an oracle: generated the package from the spec before and after this change, diffed generated
against generated to isolate exactly what the generator emits for two optional string fields,
applied the transformations above, and compared that to the diff in this PR. They are identical,
48 lines each. Comparing deltas rather than whole files makes the check independent of generator
version, which mattered because the version available to me was 7.24.0 while the module records
7.20.0.

If maintainers would rather this came from a real regeneration, I am happy to redo it — and if the
invocation and post-processing were captured in a script, I would be glad to contribute that
separately, since it is currently not reproducible from the repository alone.

Tests

Three tests in nfConfigApi/model_pcc_qos_gbr_test.go:

• the guaranteed rate survives a JSON round trip and does not disturb the maximum rate beside it
• an unset guaranteed rate is omitted from the serialised form, like the optional fields beside it
• a gbrUl in an incoming body decodes into the field rather than landing in
  AdditionalProperties, which is what the delete() lines control

The last one is mutation-verified: removing the delete(additionalProperties, "gbrUl") line makes
it fail.

golangci-lint run reports 0 issues for the module and go test ./... -race -cover passes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GyNr6vp6JaxxzPyVcuHXTf

[gab-arrobo]

Note on regeneration

The models carry DO NOT EDIT, so I want to be transparent that this field was hand-written, and about how I checked it.

Hi @midwell, thank you for your contribution. I am going to review this PR (late) next week and provide my feedback.

Again, thanks!

[Copilot]

Pull request overview

Adds guaranteed bit rate support to the NFConfig API’s PccQos model so policies can express a committed (floor) rate alongside the existing maximum (ceiling) rate.

Changes:

• Extend PccQos OpenAPI schema with optional gbrUl / gbrDl fields.
• Extend generated Go model nfConfigApi.PccQos with optional GbrUl / GbrDl fields, including (un)marshalling and accessors.
• Add Go tests verifying round-trip serialization, omission when unset, and correct decoding (not leaking into AdditionalProperties).

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.

File	Description
nfConfigApi/webconsole-api.yaml	Adds gbrUl/gbrDl properties to the PccQos schema.
nfConfigApi/model_pcc_qos.go	Adds GbrUl/GbrDl fields plus getters/setters and JSON map/(un)marshal handling.
nfConfigApi/model_pcc_qos_gbr_test.go	Adds tests covering the new guaranteed bit rate fields’ JSON behavior.

Files not reviewed (1)

• nfConfigApi/model_pcc_qos.go: Generated file

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[gab-arrobo]

Note on regeneration

The models carry DO NOT EDIT, so I want to be transparent that this field was hand-written, and about how I checked it.

Hi @midwell, thank you for your contribution. I am going to review this PR (late) next week and provide my feedback.

Again, thanks!

@midwell, I just regenerated the code using openapi-generator and the output was the same you have in your changes/PR, of course, without the model_pcc_qos_gbr_test.go file. Given that openapi-generator does NOT automatically create the test file, is this the correct place for the test file? or should it be in the webconsole as part of its unit-tests? I am asking this because the "models" themselves do not have tests (they are primarily structs/definitions), what do you think?

[midwell]

Thanks for regenerating — good to know the generator reproduces the model exactly; that was the part I was least sure of.

On the test file: I put it here because it covers code that lives here, so if a future regeneration ever drops gbrUl/gbrDl the failure lands in this repo rather than surfacing later as a build break in webconsole. That said, your point stands that the models are otherwise untested structs, and now that you've confirmed the generator emits these fields, the risk it guards against is smaller than when I wrote it. It's your call as maintainer — I'm happy to move it to webconsole alongside the code that consumes the fields, or drop it entirely, whichever fits the repo's conventions. Just say which and I'll push the change.

I've also fixed the misleading comment Copilot flagged: that test decodes a gbrUl that is set, so "an unset guaranteed rate" described the opposite of what it asserts.

One other thing, separate from the review. I've added a second commit dropping -dev from VERSION so merging tags 2.2.1. The reason is sequencing: the webconsole and pcf changes that populate these fields are both pinned to v2.2.0 and can't be opened until the fields are in a release. If you'd rather handle the release yourself in a separate PR — the way ngap#119 did — say so and I'll drop that commit.

The CI run is waiting on maintainer approval, so the checks haven't reported yet.

[gab-arrobo]

The CI run is waiting on maintainer approval, so the checks haven't reported yet.

This is expected because this is your first contribution in this repo. After this PR is merged, your future contributions in this repo will automatically run the CI pipeline.

[gab-arrobo]

On the test file: I put it here because it covers code that lives here, so if a future regeneration ever drops gbrUl/gbrDl the failure lands in this repo rather than surfacing later as a build break in webconsole. That said, your point stands that the models are otherwise untested structs, and now that you've confirmed the generator emits these fields, the risk it guards against is smaller than when I wrote it. It's your call as maintainer — I'm happy to move it to webconsole alongside the code that consumes the fields, or drop it entirely, whichever fits the repo's conventions. Just say which and I'll push the change.

My concern about the test file is that if somebody regenerates the models in the future, the easiest way to do it might be by deleting the entire directory nfConfigApi. FYI, as you can see in the APIs directories across the entire repo, APIs do have/include tests. So, you can create a test file for the API (i.e., api_default_test.go) and as part of this, validate what you need to validate in the model_xxxxxx_test.go file. If this option does not seem reasonable for you, it would be better to move the test to some other repo such that we avoid confusion (for future maintainers and users) as to why this is the only "models_xxxxxx_test.go" if openapi-generator does NOT created and is not aligned with the rest of the repo structure. What do you think?

[gab-arrobo]

One other thing, separate from the review. I've added a second commit dropping -dev from VERSION so merging tags 2.2.1. The reason is sequencing: the webconsole and pcf changes that populate these fields are both pinned to v2.2.0 and can't be opened until the fields are in a release. If you'd rather handle the release yourself in a separate PR — the way ngap#119 did — say so and I'll drop that commit.

This change is ok to be part of your PR

[midwell]

Good point. I have taken your other suggestion and dropped the test from this PR. It costs nothing, because the consumer already covers it: webconsole's backend/nfconfig/pcc_qos_gbr_test.go exercises the same fields through buildPccQos — carried, omitted when unset, and the one-directional case — and configapi/slice_helpers_gbr_test.go covers the unit normalisation. Those arrive with the webconsole change that populates the fields, once 2.2.1 is released.

This PR is now the generated shape and the release commit only: model_pcc_qos.go, webconsole-api.yaml, VERSION.