Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 1 | Other Blueprints |
| 2 | ----------------------- |
| 3 | |
| 4 | The previous sections describe how to deploy four Aether blueprints, |
| 5 | corresponding to four variants of ``var/main.yml``. This section |
| 6 | documents additional blueprints, each defined by a combination of |
| 7 | Ansible components: |
| 8 | |
| 9 | * A ``vars/main-blueprint.yml`` file, checked into the |
| 10 | ``aether-onramp`` repo, is the "root" of the blueprint |
| 11 | specification. |
| 12 | |
| 13 | * A ``hosts.ini`` file, documented by example, specifies the target |
| 14 | servers required by the blueprint. |
| 15 | |
| 16 | * A set of Make targets, defined in a submodule and imported into |
Larry Peterson | 87cd577 | 2023-10-18 13:02:36 -0700 | [diff] [blame] | 17 | OnRamp's global Makefile, provides commands to install and uninstall |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 18 | the blueprint. |
| 19 | |
| 20 | * (Optional) A new ``aether-blueprint`` repo defines the Ansible Roles |
| 21 | and Playbooks required to deploy a new component. |
| 22 | |
| 23 | * (Optional) New Roles, Playbooks, and Templates, checked to existing |
Larry Peterson | ea30875 | 2023-10-10 09:54:27 -0700 | [diff] [blame] | 24 | repos/submodules, customize existing components for integration with |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 25 | the new blueprint. To support blueprint independence, these elements |
| 26 | are intentionally kept "narrow", rather than glommed onto an |
| 27 | existing element. |
| 28 | |
Larry Peterson | ea30875 | 2023-10-10 09:54:27 -0700 | [diff] [blame] | 29 | * A Jenkins job, added to the set of OnRamp integration tests, |
Larry Peterson | 87cd577 | 2023-10-18 13:02:36 -0700 | [diff] [blame] | 30 | verifies that the blueprint successfully deploys Aether. |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 31 | |
Larry Peterson | 87cd577 | 2023-10-18 13:02:36 -0700 | [diff] [blame] | 32 | The goal of establishing a well-defined procedure for adding new |
| 33 | blueprints to OnRamp is to encourage the community to contribute (and |
| 34 | maintain) new Aether configurations and deployment scenarios.\ [#]_ |
| 35 | The rest of this section documents community-contributed blueprints |
| 36 | to-date. |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 37 | |
Larry Peterson | ad3c7f8 | 2023-10-10 11:37:16 -0700 | [diff] [blame] | 38 | .. [#] Not all possible configurations of Aether require a |
| 39 | blueprint. There are other ways to add variability, for |
| 40 | example, by documenting simple ways to modify an existing |
| 41 | blueprint. Disabling ``core.standalone`` and selecting an |
| 42 | alternative ``core.values_file`` are two common examples. |
| 43 | |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 44 | Multiple UPFs |
| 45 | ~~~~~~~~~~~~~~~~~~~~~~ |
| 46 | |
| 47 | The base version of SD-Core includes a single UPF, running in the same |
| 48 | Kubernetes namespace as the Core's control plane. This blueprint adds |
| 49 | the ability to bring up multiple UPFs (each in a different namespace), |
Larry Peterson | 87cd577 | 2023-10-18 13:02:36 -0700 | [diff] [blame] | 50 | and uses ROC to establish the *UPF-to-Slice-to-Device* bindings |
| 51 | required to activate end-to-end user traffic. The resulting deployment |
| 52 | is then verified using gNBsim. |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 53 | |
| 54 | The Multi-UPF blueprint includes the following: |
| 55 | |
| 56 | * Global vars file ``vars/main-upf.yml`` gives the overall |
| 57 | blueprint specification. |
| 58 | |
| 59 | * Inventory file ``hosts.ini`` is identical to that used in the |
| 60 | Emulated RAN section. Minimally, SD-Core runs on one server and |
Larry Peterson | 87cd577 | 2023-10-18 13:02:36 -0700 | [diff] [blame] | 61 | gNBsim runs on a second server. (The Quick Start deployment, with |
| 62 | both SD-Core and gNBsim running in the same server, also works.) |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 63 | |
| 64 | * New make targets, ``5gc-upf-install`` and ``5gc-upf-uninstall``, to |
| 65 | be executed after the standard SD-Core installation. The blueprint |
| 66 | also reuses the ``roc-load`` target to activate new slices in ROC. |
| 67 | |
| 68 | * New Ansible role (``upf``) added to the ``5gc`` submodule, including |
| 69 | a new UPF-specific template (``upf-5g-values.yaml``). |
| 70 | |
| 71 | * New models file (``roc-5g-models-upf2.json``) added to the |
| 72 | ``roc-load`` role in the ``amp`` submodule. This models file is |
| 73 | applied as a patch *on top of* the base set of ROC models. (Since |
| 74 | this blueprint is demonstrated using gNBsim, the assumed base models |
| 75 | are given by ``roc-5g-models.json``.) |
| 76 | |
Larry Peterson | 1fc4cba | 2023-12-14 14:00:44 -0700 | [diff] [blame^] | 77 | * Two nightly integration tests that validate the Multi-UPF blueprint |
| 78 | can be viewed on Jenkins (assuming you are a registered user): |
| 79 | `single-server test |
| 80 | <https://jenkins.aetherproject.org/view/Aether%20OnRamp/job/AetherOnRamp_QuickStart_Multi-UPF/>`__, |
| 81 | `two-server test |
| 82 | <https://jenkins.aetherproject.org/view/Aether%20OnRamp/job/AetherOnRamp_2servers_Multi-UPF/>`__. |
| 83 | |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 84 | To use Multi-UPF, first copy the vars file to ``main.yml``: |
| 85 | |
| 86 | .. code-block:: |
| 87 | |
| 88 | $ cd vars |
| 89 | $ cp main-upf.yml main.yml |
| 90 | |
| 91 | Then edit ``hosts.ini`` and ``vars/main.yml`` to match your local |
| 92 | target servers, and deploy the base system (as in previous sections): |
| 93 | |
| 94 | .. code-block:: |
| 95 | |
| 96 | $ make k8s-install |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 97 | $ make roc-install |
| 98 | $ make roc-load |
Larry Peterson | ea30875 | 2023-10-10 09:54:27 -0700 | [diff] [blame] | 99 | $ make 5gc-core-install |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 100 | $ make gnbsim-install |
| 101 | |
| 102 | You can also optionally install the monitoring subsystem. Note that |
Larry Peterson | ad3c7f8 | 2023-10-10 11:37:16 -0700 | [diff] [blame] | 103 | because ``main.yml`` sets ``core.standalone: "false"``, any models |
Larry Peterson | ea30875 | 2023-10-10 09:54:27 -0700 | [diff] [blame] | 104 | loaded into ROC are automatically applied to SD-Core. |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 105 | |
| 106 | At this point you are ready to bring up additional UPFs and bind them |
| 107 | to specific slices and devices. This involves first editing the |
| 108 | ``upf`` block in the ``core`` section of ``vars/main.yml``: |
| 109 | |
| 110 | .. code-block:: |
| 111 | |
| 112 | upf: |
| 113 | ip_prefix: "192.168.252.0/24" |
| 114 | iface: "access" |
| 115 | helm: |
| 116 | chart_ref: aether/bess-upf |
| 117 | values_file: "deps/5gc/roles/upf/templates/upf-5g-values.yaml" |
| 118 | additional_upfs: |
| 119 | "1": |
| 120 | ip: |
| 121 | access: "192.168.252.6/24" |
| 122 | core: "192.168.250.6/24" |
| 123 | ue_ip_pool: "172.248.0.0/16" |
| 124 | # "2": |
| 125 | # ip: |
| 126 | # access: "192.168.252.7/24" |
| 127 | # core: "192.168.250.7/24" |
| 128 | # ue_ip_pool: "172.247.0.0/16" |
| 129 | |
Larry Peterson | 87cd577 | 2023-10-18 13:02:36 -0700 | [diff] [blame] | 130 | As shown above, one additional UPF is enabled (beyond ``upf-0`` that |
| 131 | already came up as part of SD-Core), with the spec for yet another UPF |
| 132 | commented out. In this example configuration, each UPF is assigned a |
| 133 | subnet on the ``access`` and ``core`` bridges, along with the IP |
| 134 | address pool for UEs that the UPF serves. Once done with the edits, |
| 135 | launch the new UPF(s) by typing: |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 136 | |
| 137 | .. code-block:: |
| 138 | |
| 139 | $ make 5gc-upf-install |
| 140 | |
| 141 | At this point the new UPF(s) will be running (you can verify this |
| 142 | using ``kubectl``), but no traffic will be directed to them until UEs |
| 143 | are assigned to their IP address pool. Doing so requires loading the |
| 144 | appropriate bindings into ROC, which you can do by editing the |
| 145 | ``roc_models`` line in ``amp`` section of ``vars/main.yml``. Comment |
| 146 | out the original models file already loaded into ROC, and uncomment |
| 147 | the new patch that is to be applied: |
| 148 | |
| 149 | .. code-block:: |
| 150 | |
| 151 | amp: |
| 152 | # roc_models: "deps/amp/roles/roc-load/templates/roc-5g-models.json" |
| 153 | roc_models: "deps/amp/roles/roc-load/templates/roc-5g-models-upf2.json" |
| 154 | |
| 155 | Then run the following to load the patch: |
| 156 | |
| 157 | .. code-block:: |
| 158 | |
| 159 | $ make roc-load |
| 160 | |
| 161 | At this point you can bring up the Aether GUI and see that a second |
| 162 | slice and a second device group have been mapped onto the second UPF. |
| 163 | |
| 164 | Now you are ready to run traffic through both UPFs, which because the |
| 165 | configuration files identified in the ``servers`` block of the |
| 166 | ``gnbsim`` section of ``vars/main.yml`` align with the IMSIs bound to |
| 167 | each Device Group (which are bound to each slice, which are in turn |
| 168 | bound to each UPF), the emulator sends data through both UPFs. To run |
| 169 | the emulation, type: |
| 170 | |
| 171 | .. code-block:: |
| 172 | |
| 173 | $ make gnbsim-simulator-run |
| 174 | |
Larry Peterson | 1fc4cba | 2023-12-14 14:00:44 -0700 | [diff] [blame^] | 175 | SD-RAN |
| 176 | ~~~~~~~~~~~~~~~~~~~~~~ |
| 177 | |
| 178 | This blueprint runs SD-Core and SD-RAN in tandem, with RANSIM |
| 179 | emulating various RAN elements. (The OnRamp roadmap includes plans to |
| 180 | couple SD-RAN with other virtual and physical RAN elements, but RANSIM |
| 181 | is currently the only option.) |
| 182 | |
| 183 | The SD-RAN blueprint includes the following: |
| 184 | |
| 185 | * Global vars file ``vars/main-sdran.yml`` gives the overall |
| 186 | blueprint specification. |
| 187 | |
| 188 | * Inventory file ``hosts.ini`` is identical to that used in the Quick |
| 189 | Start deployment, with both SD-RAN and Sd-Core co-located on a |
| 190 | single server. |
| 191 | |
| 192 | * New make targets, ``aether-sdran-install`` and |
| 193 | ``aether-sdran-uninstall``, to be executed after the standard |
| 194 | SD-Core installation. |
| 195 | |
| 196 | * A new submodule ``deps/sdran`` (corresponding to repo |
| 197 | ``aether-sdran``) defines the Ansible Roles and Playbooks required |
| 198 | to deploy SD-RAN. |
| 199 | |
| 200 | * A nightly integration test that validates the SD-RAN blueprint can |
| 201 | be viewed on `Jenkins |
| 202 | <https://jenkins.aetherproject.org/view/Aether%20OnRamp/job/AetherOnRamp_QuickStart_SDRAN/>`__ |
| 203 | (assuming you are a registered user). |
| 204 | |
| 205 | To use SD-RAN, first copy the vars file to ``main.yml``: |
| 206 | |
| 207 | .. code-block:: |
| 208 | |
| 209 | $ cd vars |
| 210 | $ cp main-sdran.yml main.yml |
| 211 | |
| 212 | Then edit ``hosts.ini`` and ``vars/main.yml`` to match your local |
| 213 | target servers, and deploy the base system (as in previous sections), |
| 214 | followed by SD-RAN: |
| 215 | |
| 216 | .. code-block:: |
| 217 | |
| 218 | $ make aether-k8s-install |
| 219 | $ make aether-5gc-install |
| 220 | $ make aether-sdran-install |
| 221 | |
| 222 | Use ``kubectl`` to validate that the SD-RAN workload is running, which |
| 223 | should result in output similar to the following: |
| 224 | |
| 225 | .. code-block:: |
| 226 | |
| 227 | $ kubectl get pods -n sdran |
| 228 | NAME READY STATUS RESTARTS AGE |
| 229 | onos-a1t-68c59fb46-8mnng 2/2 Running 0 3m12s |
| 230 | onos-cli-c7d5b54b4-cddhr 1/1 Running 0 3m12s |
| 231 | onos-config-5786dbc85c-rffv7 3/3 Running 0 3m12s |
| 232 | onos-e2t-5798f554b7-jgv27 2/2 Running 0 3m12s |
| 233 | onos-kpimon-555c9fdb5c-cgl5b 2/2 Running 0 3m12s |
| 234 | onos-topo-6b59c97579-pf5fm 2/2 Running 0 3m12s |
| 235 | onos-uenib-6f65dc66b4-b78zp 2/2 Running 0 3m12s |
| 236 | ran-simulator-5d9465df55-p8b9z 1/1 Running 0 3m12s |
| 237 | sd-ran-consensus-0 1/1 Running 0 3m12s |
| 238 | sd-ran-consensus-1 1/1 Running 0 3m12s |
| 239 | sd-ran-consensus-2 1/1 Running 0 3m12s |
| 240 | |
| 241 | Note that the SD-RAN workload includes RANSIM as one of its pods; |
| 242 | there is no separate "run simulator" step as is the case with gNBsim. |
| 243 | To validate that the emulation ran correctly, query the ONOS CLI as |
| 244 | follows: |
| 245 | |
| 246 | Check ``onos-kpimon`` to see if 6 cells are present: |
| 247 | |
| 248 | .. code-block:: |
| 249 | |
| 250 | $ kubectl exec -it deployment/onos-cli -n sdran -- onos kpimon list metrics |
| 251 | |
| 252 | Check ``ran-simulator`` to see if 10 UEs and 6 cells are present: |
| 253 | |
| 254 | .. code-block:: |
| 255 | |
| 256 | $ kubectl exec -it deployment/onos-cli -n sdran -- onos ransim get cells |
| 257 | $ kubectl exec -it deployment/onos-cli -n sdran -- onos ransim get ues |
| 258 | |
| 259 | Check ``onos-topo`` to see if ``E2Cell`` is present: |
| 260 | |
| 261 | .. code-block:: |
| 262 | |
| 263 | $ kubectl exec -it deployment/onos-cli-n sdran -- onos topo get entity -v |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 264 | |