Align docs with the standardized 5G PLMN and consolidated core values

onramp/blueprints.rst

@@ -524,9 +524,7 @@ section:
       mode: dpdk			# Options: af_packet or dpdk
       # If mode set to 'dpdk':
       #    - make sure at least two VF devices are created out of 'data_iface'
-      #      and these devices are attached to vfio-pci driver;
-      #    - use 'sdcore-5g-values.yaml' for the default profile or
-      #      'radio-5g-values.yaml' for the radio profile.
+      #      and these devices are attached to vfio-pci driver.
 
 Note the VF device requirement in the ``upf`` block comments. The
 ``core`` block continues to point at the standard SD-Core values file,
@@ -685,7 +683,7 @@ option is to reuse the values file also used by the :doc:`Physical RAN
 
 .. code-block::
 
-   values_file: "deps/5gc/roles/core/templates/radio-5g-values.yaml"
+   values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml"
 
 That file should be edited, as necessary, to match your configuration.
 
@@ -833,7 +831,7 @@ option is to reuse the values file also used by the :doc:`Physical RAN
 
 .. code-block::
 
-   values_file: "deps/5gc/roles/core/templates/radio-5g-values.yaml"
+   values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml"
 
 That file should be edited, as necessary, to match your configuration.
 
@@ -978,7 +976,7 @@ option is to reuse the values file also used by the :doc:`Physical RAN
 
 .. code-block::
 
-   values_file: "deps/5gc/roles/core/templates/radio-5g-values.yaml"
+   values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml"
 
 That file should be edited, as necessary, to match your configuration.
 
@@ -1143,7 +1141,7 @@ option is to reuse the values file also used by the :doc:`Physical RAN
 
 .. code-block::
 
-   values_file: "deps/5gc/roles/core/templates/radio-5g-values.yaml"
+   values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml"
 
 That file should be edited, as necessary, to match your configuration.
 

onramp/gnb.rst

@@ -74,7 +74,7 @@ using.
     core:
       standalone: true                # set to false to place under control of ROC
       data_iface: ens18
-      values_file: "deps/5gc/roles/core/templates/radio-5g-values.yaml"
+      values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml"
       ran_subnet: ""                  # set to empty string to get subnet from 'data_iface'
       helm:
          local_charts: false         # set chart_ref to local path name if true
@@ -138,7 +138,7 @@ and the MCC/MNC pair is set automatically based on the newly inserted
 SIM card. The important value is the APN, which is set to
 ``internet``. This value corresponds to variable ``dnn`` (*Data
 Network Name*) defined in
-``deps/5gc/roles/core/templates/radio-5g-values.yaml``. Loosely
+``deps/5gc/roles/core/templates/sdcore-5g-values.yaml``. Loosely
 speaking, the role the APN plays in the mobile network is similar to
 the role an SSID plays in a WiFi network.
 
@@ -151,7 +151,7 @@ the role an SSID plays in a WiFi network.
 
 Finally, modify the ``subscribers`` block of the
 ``omec-sub-provision`` section in file
-``deps/5gc/roles/core/templates/radio-5g-values.yaml`` to record the IMSI,
+``deps/5gc/roles/core/templates/sdcore-5g-values.yaml`` to record the IMSI,
 OPc, and Key values configured onto your SIM cards. The block also
 defines a sequence number that is intended to thwart replay
 attacks. For example, the following code block adds IMSIs between
@@ -201,9 +201,9 @@ abstractions they build upon) should be entered via the ROC, as
 described in the :doc:`Runtime Control </onramp/roc>` section. When
 you get to that point, Ansible variable ``standalone`` in
 ``vars/main.yml`` (which corresponds to the override value assigned to
-``provision-network-slice`` in ``radio-5g-values.yaml``) should be set
+``provision-network-slice`` in ``sdcore-5g-values.yaml``) should be set
 to ``false``. Doing so causes the ``device-groups`` and
-``network-slices`` blocks of ``radio-5g-values.yaml`` to be
+``network-slices`` blocks of ``sdcore-5g-values.yaml`` to be
 ignored. The ``subscribers`` block is always required to configure
 SD-Core.
 

onramp/roc.rst

@@ -18,7 +18,7 @@ values to load the ROC database, saving us from a laborious GUI
 session.
 
 Somewhat confusingly, the *Device-Group* and *Slice* information is
-duplicated between ``deps/5gc/roles/core/templates/radio-5g-values.yaml``
+duplicated between ``deps/5gc/roles/core/templates/sdcore-5g-values.yaml``
 and this ``radio-5g-models.json`` file. This makes it possible to bring
 up the SD-Core without the ROC, which simplifies the process of
 debugging an initial installation, but having two sources for this
@@ -28,7 +28,7 @@ avoided.
 To this end, Aether treats the ROC as the "single source of truth" for
 *Slices*, *Device Groups*, and all the other abstract objects it
 defines, so we recommend using the GUI or API to make changes over
-time, and avoiding the override values in ``radio-5gc-values.yaml``
+time, and avoiding the override values in ``sdcore-5g-values.yaml``
 once you've established basic connectivity. And if you want to save
 this bootstrap state in a text file for a possible restart, we
 recommend doing so in ``radio-5g-models.json`` (although this is not a
@@ -41,11 +41,11 @@ setting it to ``false``. This variable indicates whether we want
 SD-Core to run in *Stand Alone* mode, which has been the default
 setting up to this point. Disabling ``standalone`` causes the SD-Core
 to ignore the ``device-groups`` and ``network-slices`` blocks of the
-``omec-sub-provision`` section in ``radio-5gc-values.yaml``, and to instead
+``omec-sub-provision`` section in ``sdcore-5g-values.yaml``, and to instead
 retrieve this information from the ROC.
 
 The next step is to edit ``radio-5g-models.json`` to record the same
-IMSI information you added to ``radio-5gc-values.yaml`` in the
+IMSI information you added to ``sdcore-5g-values.yaml`` in the
 previous section.  This includes modifying, adding and removing
 ``sim-card`` entries as necessary. Note that only the IMSIs need to
 match the earlier data; the ``sim-id`` and ``display-name`` values are

onramp/start.rst

@@ -411,7 +411,7 @@ microservices discussed is `Chapter 5
 
 If you are interested in seeing the details about how SD-Core is
 configured, look at
-``deps/5gc/roles/core/templates/radio-5g-values.yaml``.  This is an
+``deps/5gc/roles/core/templates/sdcore-5g-values.yaml``.  This is an
 example of a *values override* file that Helm passes along to
 Kubernetes when launching the service. Most of the default settings
 will remain unchanged, with the main exception being the
@@ -512,13 +512,13 @@ block defines a set of parameters for ``pdusessest`` (also known as
     enable: true
     gnbName: gnb1
     execInParallel: false
-    startImsi: 208930100007487
+    startImsi: 001010100007487
     ueCount: 5
     defaultAs: "{{ ping_target }}"
     perUserTimeout: 100
     plmnId:
-       mcc: 208
-       mnc: 93
+       mcc: 001
+       mnc: 01
     dataPktCount: 5
     opc: "981d464c7c52eb6e5036234984ad0bcf"
     key: "5122250214c33e723a5dd523fc145fc0"

operations/subscriber.rst

@@ -43,13 +43,13 @@ include the new Device IMSIs:
       subscribers:
       - ueId-start: 123456789123458
          ueId-end: 123456789123458
-         plmnId: 20893
+         plmnId: 00101
          opc: 8e27b6af0e692e750f32667a3b14605d
          key: 8baf473f2f8fd09487cccbd7097c6862
          sequenceNumber: 16f3b3f70fc2
       - ueId-start: 123456789123460
          ueId-end: 123456789123465
-         plmnId: 20893
+         plmnId: 00101
          opc: 8e27b6af0e692e750f32667a3b14605d
          key: 8baf473f2f8fd09487cccbd7097c6862
          sequenceNumber: 16f3b3f70fc2