Repository navigation
Align docs with the standardized 5G PLMN and consolidated core values - #92
Merged
gab-arrobo merged 1 commit intoSep 9, 2026
Merged
Conversation
OnRamp standardized the 5G PLMN on 001/01 (00101) and consolidated the core values files: radio-5g-values.yaml folded into sdcore-5g-values.yaml and radio-5g-values-ims.yaml renamed to sdcore-5g-values-ims.yaml. Bring the docs in line: - PLMN examples 20893 -> 00101 (gnbsim profile, subscriber provisioning). - References to the removed radio-5g-values.yaml (and the radio-5gc-values spelling) -> sdcore-5g-values.yaml. - Drop the now-inapplicable default-vs-radio values_file note. The 4G/CBRS example PLMN (315/010) is unchanged. Signed-off-by: Benjamin Grewell <benjamin.grewell@intel.com>
There was a problem hiding this comment.
🟡 Changes recommended
The updated docs introduce YAML examples with leading-zero identifiers (PLMN/MCC/MNC/IMSI) left unquoted, which can be parsed incorrectly when copied.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR updates the OnRamp/operations documentation to match the standardized 5G PLMN (001/01 → 00101) and the consolidated SD-Core values override file naming introduced in the referenced onramp change, preventing docs from pointing to outdated PLMN examples or removed filenames.
Changes:
- Update 5G PLMN examples to
00101(including gnbsim and subscriber provisioning examples). - Replace references to the removed/renamed
radio-5g-values.yaml/radio-5gc-values.yamlwithsdcore-5g-values.yaml. - Remove the blueprint note that differentiated “default vs radio profile” values files (no longer applicable after consolidation).
File summaries
| File | Description |
|---|---|
| operations/subscriber.rst | Updates subscriber provisioning example PLMN to 00101. |
| onramp/start.rst | Updates gnbsim profile example PLMN/IMSI and SD-Core values file reference. |
| onramp/roc.rst | Updates values file references in ROC guidance to the consolidated filename. |
| onramp/gnb.rst | Updates values file references used in gNB/UE setup examples. |
| onramp/blueprints.rst | Removes obsolete “default vs radio profile” note and updates values file references. |
Review details
Suppressed comments (1)
operations/subscriber.rst:52
- Same issue as above:
00101should be quoted to avoid YAML numeric/octal parsing and preserve the leading zeros.
plmnId: 00101
- Files reviewed: 5/5 changed files
- Comments generated: 3
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| gnbName: gnb1 | ||
| execInParallel: false | ||
| startImsi: 208930100007487 | ||
| startImsi: 001010100007487 |
Comment on lines
519
to
+521
| plmnId: | ||
| mcc: 208 | ||
| mnc: 93 | ||
| mcc: 001 | ||
| mnc: 01 |
| - ueId-start: 123456789123458 | ||
| ueId-end: 123456789123458 | ||
| plmnId: 20893 | ||
| plmnId: 00101 |
gab-arrobo
pushed a commit
that referenced
this pull request
Sep 10, 2026
* Quote leading-zero PLMN values in 5G examples PR #92 updated the PLMN examples in the docs to 001/01 but left the new leading-zero values unquoted in the code-block snippets. As displayed, plmnId: 00101 parses as octal 65, and mcc: 001 / mnc: 01 both collapse to 1, so a reader copying these examples into their own values file silently provisions the wrong PLMN. This affects the rendered examples only. The actual override files in aether-onramp already quote these correctly (sdcore-5g-values.yaml, gnbsim-default.yaml); the docs are being brought in line with them. Addresses the review feedback left on #92. Signed-off-by: Benjamin Grewell <benjamin.grewell@intel.com> * Update stale gNBsim startImsi to match provisioned range The profile2 example still showed startImsi 001010100007487. That value was retired upstream by aether-onramp#219 ("Align IMSI floor (ueID-start) to 7500"), which was never reflected here, so it predates #92 -- that PR only swapped the 20893 prefix onto an already-stale suffix. 001010100007487 falls outside both provisioned subscriber ranges (7500-7509 and 7510-7599) in sdcore-5g-values.yaml, so the example as printed would fail authentication if used as-is. Update it to 001010100007510, matching profile2 in gnbsim-default.yaml. Signed-off-by: Benjamin Grewell <benjamin.grewell@intel.com> * Fix YAML examples that fail to parse when copied Several example blocks could not be pasted into a values file as-is: - onramp/start.rst: the profile2 mapping keys were not nested under the list item, so the block raised a ScannerError. Also restores dnn and sNssai, which are part of profile2 in gnbsim-default.yaml but were omitted here without an elision marker. - onramp/gnb.rst: the device-groups block mis-indented imsis under the list item, raising a ParserError. - onramp/{gnbsim,network,blueprints}.rst: literal tabs before inline comments. YAML forbids tabs, so these blocks failed to parse. The corresponding files in aether-onramp use spaces. Comment columns are preserved. No values are changed. Signed-off-by: Benjamin Grewell <benjamin.grewell@intel.com> * Correct gNBsim profile count and typos gnbsim-default.yaml defines eight profileTypes; the list here named seven and omitted nwreqpdusessrelease. Also fixes two typos in the surrounding prose: pdusettest -> pdusessest, and PLMD -> PLMN. Signed-off-by: Benjamin Grewell <benjamin.grewell@intel.com> * Use upstream indentation style for the imsis list Indent the imsis sequence under its key, matching device-groups in sdcore-5g-values.yaml. Both forms parse identically -- a block sequence may sit at the same indentation as its parent mapping key -- but this keeps the example consistent with the file it is documenting. Signed-off-by: Benjamin Grewell <benjamin.grewell@intel.com> --------- Signed-off-by: Benjamin Grewell <benjamin.grewell@intel.com> Co-authored-by: Benjamin Grewell <benjamin.grewell@intel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to opennetworkinglab/aether-onramp#241, which standardized the 5G PLMN on 001/01 (00101) and consolidated the SD-Core values files (folded
radio-5g-values.yamlintosdcore-5g-values.yaml, and renamedradio-5g-values-ims.yamltosdcore-5g-values-ims.yaml). This brings the docs in line so nothing points at a PLMN or a file that no longer exists.Changes
20893->00101(the gnbsim traffic profile instart.rst, and the subscriber-provisioning example insubscriber.rst).radio-5g-values.yaml(and theradio-5gc-values.yamlspelling) ->sdcore-5g-values.yaml, acrossstart.rst,gnb.rst,roc.rst, andblueprints.rst.blueprints.rst(there's a single core values file now).Scope / left intentionally
315/010) is unchanged — that stack wasn't touched.roc.rststill names the ROC modelradio-5g-models.json; I didn't rename that file in #241, so I left it. If that name is itself a pre-existing typo it can be a separate cleanup.A note on verification
I don't have the Sphinx toolchain set up locally, so I couldn't do a docs build to confirm it renders. That said, every change here is a pure text/path substitution inside existing prose and code-blocks — no directive/role/structure changes — so I'd expect it to build identically to
main. Happy to fix up anything CI flags.