Skip to content

Commit

Permalink
Merge pull request #27 from opennetworkinglab/maintenance
Browse files Browse the repository at this point in the history
clarified multi-upf
  • Loading branch information
llpeterson authored Oct 1, 2024
2 parents f441084 + c0f4f75 commit 96c79db
Show file tree
Hide file tree
Showing 2 changed files with 21 additions and 10 deletions.
26 changes: 18 additions & 8 deletions onramp/blueprints.rst
Original file line number Diff line number Diff line change
Expand Up @@ -100,7 +100,8 @@ To use Multi-UPF, first copy the vars file to ``main.yml``:
$ cp main-upf.yml main.yml
Then edit ``hosts.ini`` and ``vars/main.yml`` to match your local
target servers, and deploy the base system (as in previous sections):
target servers, and deploy the base system (as in previous sections).
You can also optionally install the monitoring subsystem.

.. code-block::
Expand All @@ -110,13 +111,13 @@ target servers, and deploy the base system (as in previous sections):
$ make 5gc-install
$ make gnbsim-install
You can also optionally install the monitoring subsystem. Note that
because ``main.yml`` sets ``core.standalone: "false"``, any models
loaded into ROC are automatically applied to SD-Core.
Note that because ``main.yml`` sets ``core.standalone: "false"``, any
models loaded into ROC are automatically applied to SD-Core.

At this point you are ready to bring up additional UPFs and bind them
to specific slices and devices. This involves first editing the
``upf`` block in the ``core`` section of ``vars/main.yml``:
to specific slices and devices. An example configuration that brings
up second UPF is included in the ``upf`` block in the ``core`` section
of ``vars/main.yml``:

.. code-block::
Expand All @@ -142,8 +143,8 @@ As shown above, one additional UPF is enabled (beyond ``upf-0`` that
already came up as part of SD-Core), with the spec for yet another UPF
commented out. In this example configuration, each UPF is assigned a
subnet on the ``access`` and ``core`` bridges, along with the IP
address pool for UEs that the UPF serves. Once done with the edits,
launch the new UPF(s) by typing:
address pool for UEs that the UPF serves. To launch this second UPF,
type:

.. code-block::
Expand Down Expand Up @@ -184,6 +185,15 @@ the emulation, type:
$ make gnbsim-simulator-run
To verify that both UPFs were functional, you will need to look at the
``summary.log`` file from both instances of gNBsim:

.. code-block::
$ docker exec -it gnbsim-1 cat summary.log
$ docker exec -it gnbsim-2 cat summary.log
SD-RAN
~~~~~~~~~~~~~~~~~~~~~~

Expand Down
5 changes: 3 additions & 2 deletions onramp/gnbsim.rst
Original file line number Diff line number Diff line change
Expand Up @@ -143,8 +143,9 @@ to run gNBsim, and then type
$ docker exec -it gnbsim-1 cat summary.log
Note that container name ``gnbsim-1`` is constructed from the
``prefix`` variable defined in the ``docker`` section of
``vars/main.yml``, with ``-1`` indicating the first container.
``gnbsim.docker.prefix`` variable defined in ``vars/main.yml``, with
``-1`` indicating the first container, ``-2`` indicating the second
container, and so on.

In addition to scaling up the workload you put on the Core, you can
also experiment with the emulation settings defined in any or all of
Expand Down

0 comments on commit 96c79db

Please sign in to comment.