wordsmithing
Change-Id: Ic53ed031f6bfc89b7633f373a3e92732a445563c
diff --git a/onramp/blueprints.rst b/onramp/blueprints.rst
index 775c74c..5274d87 100644
--- a/onramp/blueprints.rst
+++ b/onramp/blueprints.rst
@@ -14,8 +14,7 @@
servers required by the blueprint.
* A set of Make targets, defined in a submodule and imported into
- OnRamp's global Makefile, provides a means to install (``make
- blueprint-install``) and uninstall (``make blueprint-uninstall``)
+ OnRamp's global Makefile, provides commands to install and uninstall
the blueprint.
* (Optional) A new ``aether-blueprint`` repo defines the Ansible Roles
@@ -28,12 +27,13 @@
existing element.
* A Jenkins job, added to the set of OnRamp integration tests,
- verifies that the blueprint does not regress.
+ verifies that the blueprint successfully deploys Aether.
-By standardizing the process for adding new blueprints to OnRamp, the
-goal is to encourage the community to contribute (and maintain) new
-Aether configurations and deployment scenarios.\ [#]_ The rest of this
-section documents community-contributed blueprints to-date.
+The goal of establishing a well-defined procedure for adding new
+blueprints to OnRamp is to encourage the community to contribute (and
+maintain) new Aether configurations and deployment scenarios.\ [#]_
+The rest of this section documents community-contributed blueprints
+to-date.
.. [#] Not all possible configurations of Aether require a
blueprint. There are other ways to add variability, for
@@ -47,9 +47,9 @@
The base version of SD-Core includes a single UPF, running in the same
Kubernetes namespace as the Core's control plane. This blueprint adds
the ability to bring up multiple UPFs (each in a different namespace),
-and uses ROC to establish the *UPF -to-Slice-to-Device* bindings
-required to activate end-to-end traffic through each UPF. The
-resulting deployment is then verified using gNBsim.
+and uses ROC to establish the *UPF-to-Slice-to-Device* bindings
+required to activate end-to-end user traffic. The resulting deployment
+is then verified using gNBsim.
The Multi-UPF blueprint includes the following:
@@ -58,7 +58,8 @@
* Inventory file ``hosts.ini`` is identical to that used in the
Emulated RAN section. Minimally, SD-Core runs on one server and
- gNBsim runs on a second server.
+ gNBsim runs on a second server. (The Quick Start deployment, with
+ both SD-Core and gNBsim running in the same server, also works.)
* New make targets, ``5gc-upf-install`` and ``5gc-upf-uninstall``, to
be executed after the standard SD-Core installation. The blueprint
@@ -119,12 +120,12 @@
# core: "192.168.250.7/24"
# ue_ip_pool: "172.247.0.0/16"
-As shown above, one additional UPF is enabled (beyond the one that
-already came up as part of SD-Core, denoted ``upf-0``), 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 an IP address pool for UEs to be served by that UPF. Once
-done with the edits, launch the new UPF(s) by typing:
+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:
.. code-block::