diff --git a/onramp/blueprints.rst b/onramp/blueprints.rst index bd4c792..2fe2bcf 100644 --- a/onramp/blueprints.rst +++ b/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. diff --git a/onramp/gnb.rst b/onramp/gnb.rst index 37f7c45..4c6b39d 100644 --- a/onramp/gnb.rst +++ b/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 ` 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. diff --git a/onramp/roc.rst b/onramp/roc.rst index ed5ad4a..fd890a0 100644 --- a/onramp/roc.rst +++ b/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 diff --git a/onramp/start.rst b/onramp/start.rst index 74a2767..22674fa 100644 --- a/onramp/start.rst +++ b/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" diff --git a/operations/subscriber.rst b/operations/subscriber.rst index 173c975..7483573 100644 --- a/operations/subscriber.rst +++ b/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