Skip to content

Commit c0f4f75

Browse files
committed
clarified multi-upf
Signed-off-by: Larry Peterson <[email protected]>
1 parent 3be8f58 commit c0f4f75

File tree

2 files changed

+21
-10
lines changed

2 files changed

+21
-10
lines changed

onramp/blueprints.rst

Lines changed: 18 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -100,7 +100,8 @@ To use Multi-UPF, first copy the vars file to ``main.yml``:
100100
$ cp main-upf.yml main.yml
101101
102102
Then edit ``hosts.ini`` and ``vars/main.yml`` to match your local
103-
target servers, and deploy the base system (as in previous sections):
103+
target servers, and deploy the base system (as in previous sections).
104+
You can also optionally install the monitoring subsystem.
104105

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

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

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

148149
.. code-block::
149150
@@ -184,6 +185,15 @@ the emulation, type:
184185
185186
$ make gnbsim-simulator-run
186187
188+
To verify that both UPFs were functional, you will need to look at the
189+
``summary.log`` file from both instances of gNBsim:
190+
191+
.. code-block::
192+
193+
$ docker exec -it gnbsim-1 cat summary.log
194+
$ docker exec -it gnbsim-2 cat summary.log
195+
196+
187197
SD-RAN
188198
~~~~~~~~~~~~~~~~~~~~~~
189199

onramp/gnbsim.rst

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -143,8 +143,9 @@ to run gNBsim, and then type
143143
$ docker exec -it gnbsim-1 cat summary.log
144144
145145
Note that container name ``gnbsim-1`` is constructed from the
146-
``prefix`` variable defined in the ``docker`` section of
147-
``vars/main.yml``, with ``-1`` indicating the first container.
146+
``gnbsim.docker.prefix`` variable defined in ``vars/main.yml``, with
147+
``-1`` indicating the first container, ``-2`` indicating the second
148+
container, and so on.
148149

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

0 commit comments

Comments
 (0)