Larry Peterson | def1b67 | 2023-08-07 14:06:24 -0700 | [diff] [blame] | 1 | Physical RAN |
| 2 | --------------- |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 3 | |
| 4 | We are now ready to replace the emulated RAN with physical gNBs and |
| 5 | real UEs. You will need to edit ``hosts.ini`` to reflect the Aether |
| 6 | cluster you want to support, where just a single server is sufficient |
| 7 | and there is no reason to include nodes in the ``[gnbsim_nodes]`` set. |
Larry Peterson | 5dc197c | 2023-10-02 14:31:06 -0700 | [diff] [blame] | 8 | |
| 9 | In addition to the server(s) in your cluster, bringing up a physical |
| 10 | RAN requires the following hardware: |
| 11 | |
| 12 | * One or more 5G small cell radios (e.g., MOSO CANOPY 5G INDOOR SMALL CELL). |
Larry Peterson | cebca8d | 2023-10-26 07:24:27 -0700 | [diff] [blame] | 13 | * One or more 5G-capable UEs (e.g., unlocked Motorola Moto G 5G). |
Larry Peterson | 5dc197c | 2023-10-02 14:31:06 -0700 | [diff] [blame] | 14 | * A SIM reader/writer and associated software (e.g., OYEITIMES MCR3516). |
Larry Peterson | cebca8d | 2023-10-26 07:24:27 -0700 | [diff] [blame] | 15 | * A set of programmable SIM cards (blank cards likely included with reader/writer). |
Larry Peterson | 5dc197c | 2023-10-02 14:31:06 -0700 | [diff] [blame] | 16 | |
| 17 | There are multiple options for each component, but finding a |
| 18 | combination that works together can be challenging. This section makes |
| 19 | several recommendations based on working end-to-end systems. For |
| 20 | simplicity, we pared the above list back to a single example for each |
| 21 | item, but these should not be interpreted as the only possibility. |
| 22 | |
Larry Peterson | cebca8d | 2023-10-26 07:24:27 -0700 | [diff] [blame] | 23 | Note also that our example relies on the availability of spectrum in |
| 24 | the CBRS band, which is available in the United States. Spectrum |
| 25 | options are likely to be different in other countries. |
| 26 | |
Larry Peterson | 5dc197c | 2023-10-02 14:31:06 -0700 | [diff] [blame] | 27 | .. admonition:: Troubleshooting Hint |
| 28 | |
| 29 | We are tracking community experience with different hardware in the |
| 30 | ``#aether-onramp`` channel of the `ONF Workspace |
Larry Peterson | 9abaff0 | 2023-10-19 09:02:50 -0700 | [diff] [blame] | 31 | <https://onf-community.slack.com/>`__, with summaries of different |
| 32 | combinations people have tried reported in the OnRamp |
| 33 | `Troubleshooting Wiki Page |
| 34 | <https://github.com/opennetworkinglab/aether-onramp/wiki/Troubleshooting>`__. |
Larry Peterson | 5dc197c | 2023-10-02 14:31:06 -0700 | [diff] [blame] | 35 | |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 36 | This blueprint assumes you start with a variant of ``vars/main.yml`` |
| 37 | customized for running physical 5G radios. This is easy to do: |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 38 | |
| 39 | .. code-block:: |
| 40 | |
| 41 | $ cd vars |
| 42 | $ cp main-gNB.yml main.yml |
| 43 | |
Larry Peterson | cebca8d | 2023-10-26 07:24:27 -0700 | [diff] [blame] | 44 | This section focuses on bringing up a single gNB, and assumes that gNB |
| 45 | is on the same L2 network as the Aether cluster. In our running |
| 46 | example, this implies both are on subnet ``10.76.28.0/24``. |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 47 | |
Larry Peterson | 8b1ed83 | 2023-08-29 12:06:06 -0700 | [diff] [blame] | 48 | .. admonition:: Troubleshooting Hint |
| 49 | |
Larry Peterson | cebca8d | 2023-10-26 07:24:27 -0700 | [diff] [blame] | 50 | Be aware that enterprise and campus networks have been known to |
| 51 | filter packets in ways that impact gNB-to-Core connectivity. |
| 52 | Fortunately, physical gNBs connect to SD-Core (both the AMF in the |
| 53 | control plane and the UPF in the user plane) in exactly the same way |
| 54 | as external instances of gNBsim. Going through the process of |
| 55 | bringing up gNBsim in a second server, as described in the previous |
| 56 | section, is a good way to validate that your Core is "gNB-ready". |
Larry Peterson | 8b1ed83 | 2023-08-29 12:06:06 -0700 | [diff] [blame] | 57 | |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 58 | Modify Configuration |
| 59 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
| 60 | |
| 61 | Modify the ``core`` section of ``vars/main.yml`` to match the |
| 62 | following, substituting your local details for ``ens18`` and |
| 63 | ``10.76.28.113``. Of particular note, setting ``ran_subnet`` to the |
| 64 | empty string indicates that the gNB is connected to the same physical |
| 65 | L2 network as your Aether cluster, and the new ``values_file`` is |
| 66 | tailored for a physical RAN rather than the emulated RAN we've been |
| 67 | using. |
| 68 | |
| 69 | .. code-block:: |
| 70 | |
| 71 | core: |
| 72 | standalone: "true" |
| 73 | data_iface: ens18 |
| 74 | values_file: "deps/5gc/roles/core/templates/radio-5g-values.yaml" |
| 75 | ran_subnet: "" |
| 76 | helm: |
| 77 | chart_ref: aether/sd-core |
| 78 | chart_version: 0.12.6 |
| 79 | upf: |
| 80 | ip_prefix: "192.168.252.0/24" |
| 81 | amf: |
| 82 | ip: "10.76.28.113" |
| 83 | |
| 84 | |
| 85 | Prepare UEs |
| 86 | ~~~~~~~~~~~~ |
| 87 | |
Larry Peterson | d3294df | 2023-09-13 10:35:38 -0400 | [diff] [blame] | 88 | When selecting UEs to connect to Aether, be aware that not all phones |
| 89 | support the CBRS frequency bands that Aether uses. For band n78, |
| 90 | Aether is known to work with recent iPhones (11 and greater), Google |
| 91 | Pixel phones (4 and greater), OnePlus phones, and Moto G 5G |
| 92 | phones. For band n48, Aether is known to work with Moto G 5G and |
| 93 | OnePlus phones; Pixel 7 phones are purported to work as well. Another |
| 94 | option is to use a 5G dongle connected to a Raspberry Pi as a |
| 95 | demonstration UE. This makes it easier to run diagnostic tests from |
| 96 | the UE. For example, we have used `APAL's 5G dongle |
| 97 | <https://www.apaltec.com/dongle/>`__ with Aether. |
| 98 | |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 99 | 5G-connected devices must have a SIM card, which you are responsible |
Larry Peterson | 5dc197c | 2023-10-02 14:31:06 -0700 | [diff] [blame] | 100 | for programming and inserting. You will need a SIM card writer, such |
| 101 | as the *OYEITIMES MCR3516* (available on Amazon), which comes with |
| 102 | five blank cards. You will need to set the PLMN identifier |
| 103 | (constructed from a valid MCC/MNC pair), the IMSI, and two secret keys |
| 104 | for each SIM card. As working examples, we have used two different |
| 105 | PLMN ids: ``315010`` constructed from MCC=315 (US) and MNC=010 (CBRS), |
| 106 | and ``00101`` constructed from MCC=001 (TEST) and MNC=01 (TEST). You |
| 107 | should use whatever values are appropriate for your local environment, |
| 108 | where we use the following as a running example throughout this |
| 109 | section: |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 110 | |
| 111 | * IMSI: each one is unique, matching pattern ``315010*********`` (up to 15 digits) |
| 112 | * OPc: ``69d5c2eb2e2e624750541d3bbc692ba5`` |
| 113 | * Key: ``000102030405060708090a0b0c0d0e0f`` |
| 114 | |
Larry Peterson | 505d4b3 | 2023-08-21 14:39:45 -0700 | [diff] [blame] | 115 | Note that the actual config files distributed with OnRamp have IMSIs |
| 116 | constructed using PLMN id ``00101``. Both sets of examples are taken |
Larry Peterson | 5d6b3b3 | 2023-09-05 15:11:55 -0700 | [diff] [blame] | 117 | from working deployments (``315010`` for a 4G/eNB and ``00101`` for a |
| 118 | 5G/gNB), so in principle either should work as a model you can emulate |
| 119 | in your deployment. As a practical matter, however, it is certainly |
| 120 | easiest (and safest) to start with the existing code. |
Larry Peterson | 505d4b3 | 2023-08-21 14:39:45 -0700 | [diff] [blame] | 121 | |
Larry Peterson | d3294df | 2023-09-13 10:35:38 -0400 | [diff] [blame] | 122 | After inserting the SIM card into the device and powering it up, log |
Larry Peterson | 077f588 | 2023-09-20 16:14:30 -0700 | [diff] [blame] | 123 | into the phone, select ``Network Settings > SIMs`` and create a new |
| 124 | *Access Point Name (APN)*, configured as shown in :numref:`Figure %s |
| 125 | <fig-apn>`. The entry name (``TEST SIM`` in the example) is arbitrary |
| 126 | and the MCC/MNC pair is set automatically based on the newly inserted |
| 127 | SIM card. The important value is the APN, which is set to |
| 128 | ``internet``. This value corresponds to variable ``dnn`` (*Data |
| 129 | Network Name*) defined in |
| 130 | ``deps/5gc/roles/core/templates/radio-5g-values.yaml``. Loosely |
| 131 | speaking, the role the APN plays in the mobile network is similar to |
| 132 | the role an SSID plays in a WiFi network. |
| 133 | |
| 134 | .. _fig-apn: |
| 135 | .. figure:: figures/Slide26.png |
| 136 | :width: 400px |
| 137 | :align: center |
| 138 | |
| 139 | Configure an Access Point Name (APN) for the new SIM card on the UE. |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 140 | |
| 141 | Finally, modify the ``subscribers`` block of the |
| 142 | ``omec-sub-provision`` section in file |
| 143 | ``deps/5gc/roles/core/templates/radio-5g-values.yaml`` to record the IMSI, |
| 144 | OPc, and Key values configured onto your SIM cards. The block also |
| 145 | defines a sequence number that is intended to thwart replay |
| 146 | attacks. For example, the following code block adds IMSIs between |
| 147 | ``315010999912301`` and ``315010999912310``: |
| 148 | |
| 149 | .. code-block:: |
| 150 | |
| 151 | subscribers: |
| 152 | - ueId-start: "315010999912301" |
| 153 | ueId-end: "315010999912310" |
| 154 | plmnId: "315010" |
| 155 | opc: "69d5c2eb2e2e624750541d3bbc692ba5" |
| 156 | key: "000102030405060708090a0b0c0d0e0f" |
| 157 | sequenceNumber: 135 |
| 158 | |
| 159 | Further down in the same ``omec-sub-provision`` section you will find |
| 160 | two other blocks that also need to be edited. The first, |
| 161 | ``device-groups``, assigns IMSIs to *Device Groups*. You will need to |
| 162 | reenter the individual IMSIs from the ``subscribers`` block that will |
| 163 | be part of the device-group: |
| 164 | |
| 165 | .. code-block:: |
| 166 | |
| 167 | device-groups: |
| 168 | - name: "5g-user-group1" |
| 169 | imsis: |
| 170 | - "315010999912301" |
| 171 | - "315010999912302" |
| 172 | - "315010999912303" |
| 173 | |
| 174 | The second block, ``network-slices``, sets various parameters |
| 175 | associated with the *Slices* that connect device groups to |
| 176 | applications. Here, you will need to reenter the PLMN information, |
| 177 | with the other slice parameters remaining unchanged (for now): |
| 178 | |
| 179 | .. code-block:: |
| 180 | |
| 181 | plmn: |
| 182 | mcc: "315" |
| 183 | mnc: "010" |
| 184 | |
| 185 | Aether supports multiple *Device Groups* and *Slices*, but the data |
| 186 | entered here is purposely minimal; it's just enough to bring up and |
| 187 | debug the installation. Over the lifetime of a running system, |
| 188 | information about *Device Groups* and *Slices* (and the other |
| 189 | abstractions they build upon) should be entered via the ROC, as |
| 190 | described the section on Runtime Control. When you get to that point, |
| 191 | Ansible variable ``standalone`` in ``vars/main.yml`` (which |
| 192 | corresponds to the override value assigned to |
| 193 | ``provision-network-slice`` in ``radio-5g-values.yaml``) should be set |
| 194 | to ``false``. Doing so causes the ``device-groups`` and |
| 195 | ``network-slices`` blocks of ``radio-5g-values.yaml`` to be |
| 196 | ignored. The ``subscribers`` block is always required to configure |
| 197 | SD-Core. |
| 198 | |
| 199 | |
| 200 | Bring Up Aether |
| 201 | ~~~~~~~~~~~~~~~~~~~~~ |
| 202 | |
| 203 | You are now ready to bring Aether on-line. We assume a fresh install |
Larry Peterson | def1b67 | 2023-08-07 14:06:24 -0700 | [diff] [blame] | 204 | by typing the following: |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 205 | |
| 206 | .. code-block:: |
| 207 | |
| 208 | $ make aether-k8s-install |
| 209 | $ make aether-5gc-install |
| 210 | |
| 211 | You can verify the installation by running ``kubectl`` just as you did |
| 212 | in earlier stages. Note that we postpone bringing up the AMP until |
| 213 | later so as to have fewer moving parts to debug. |
| 214 | |
| 215 | |
| 216 | gNodeB Setup |
| 217 | ~~~~~~~~~~~~~~~~~~~~ |
| 218 | |
| 219 | Once the SD-Core is up and running, we are ready to bring up the |
| 220 | physical gNB. The details of how to do this depend on the specific |
| 221 | device you are using, but we identify the main issues you need to |
Larry Peterson | 5d6b3b3 | 2023-09-05 15:11:55 -0700 | [diff] [blame] | 222 | address using SERCOMM's 5G femto cell (as distributed by MosoLabs) as |
| 223 | an example. That particular device uses either the n48 or n78 band and |
Larry Peterson | d3294df | 2023-09-13 10:35:38 -0400 | [diff] [blame] | 224 | is on the ONF MarketPlace, where you can also find a User's Guide that |
| 225 | gives detailed instructions about configuring the gNB. |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 226 | |
| 227 | .. _reading_sercomm: |
| 228 | .. admonition:: Further Reading |
| 229 | |
Larry Peterson | 5d6b3b3 | 2023-09-05 15:11:55 -0700 | [diff] [blame] | 230 | `MOSO CANOPY 5G INDOOR SMALL CELL |
| 231 | <https://opennetworking.org/products/moso-canopy-5g-indoor-small-cell/>`__. |
| 232 | |
| 233 | .. admonition:: Troubleshooting Hint |
| 234 | |
| 235 | The product data sheet shows support for frequency bands |
| 236 | n78/n48/n77, but individual devices do not necessarily support all |
| 237 | three. For example, we have experience with an n78 device and an n48 |
Larry Peterson | 5dc197c | 2023-10-02 14:31:06 -0700 | [diff] [blame] | 238 | device, with the latter (n48) becoming the preferred band (due in |
| 239 | part to less risk of interfering with Radio Altimeters). For n48, |
| 240 | PLMN id ``00101`` is currently recommended. |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 241 | |
| 242 | For the purposes of the following description, we assume the gNB is |
| 243 | assigned IP address ``10.76.28.187``, which per our running example, |
| 244 | is on the same L2 network as our Aether server (``10.76.28.113``). |
Larry Peterson | def1b67 | 2023-08-07 14:06:24 -0700 | [diff] [blame] | 245 | :numref:`Figure %s <fig-sercomm>` shows a screenshot of the SERCOMM |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 246 | gNB management dashboard, which we reference in the instructions that |
| 247 | follow: |
| 248 | |
| 249 | .. _fig-sercomm: |
| 250 | .. figure:: figures/Sercomm.png |
| 251 | :width: 500px |
| 252 | :align: center |
| 253 | |
| 254 | Management dashboard on the Sercomm gNB, showing the dropdown |
David Ferguson | 2990dd0 | 2024-01-31 16:16:58 -0800 | [diff] [blame] | 255 | ``Settings`` menu overlaid on the ``NR Cell Configuration`` page |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 256 | (which shows default radio settings). |
| 257 | |
| 258 | |
| 259 | 1. **Connect to Management Interface.** Start by connecting a laptop |
| 260 | directly to the LAN port on the small cell, pointing your laptop's |
| 261 | web browser at the device's management page |
| 262 | (``https://10.10.10.189``). You will need to assign your laptop an |
| 263 | IP address on the same subnet (e.g., ``10.10.10.100``). Once |
| 264 | connected, log in with the credentials provided by the vendor. |
| 265 | |
| 266 | 2. **Configure WAN.** Visit the ``Settings > WAN`` page to configure |
| 267 | how the small cell connects to the Internet via its WAN port, |
| 268 | either dynamically using DHCP or statically by setting the device's |
| 269 | IP address (``10.76.28.187``) and default gateway (``10.76.28.1``). |
| 270 | |
| 271 | 3. **Access Remote Management.** Once on the Internet, it should be |
| 272 | possible to reach the management dashboard without being directly |
| 273 | connected to the LAN port (``https://10.76.28.187``). |
| 274 | |
| 275 | 4. **Connect GPS.** Connect the small cell's GPS antenna to the GPS |
| 276 | port, and place the antenna so it has line-of-site to the sky |
| 277 | (i.e., place it in a window). The ``Status`` page of the management |
| 278 | dashboard should report its latitude, longitude, and fix time. |
| 279 | |
| 280 | 5. **Spectrum Access System.** One reason the radio needs GPS is so it |
| 281 | can report its location to a Spectrum Access System (SAS), a |
| 282 | requirement in the US to coordinate access to the CBRS Spectrum in |
| 283 | the 3.5 GHz band. For example, the production deployment of Aether |
| 284 | uses the `Google SAS portal |
| 285 | <https://cloud.google.com/spectrum-access-system/docs/overview>`__, |
| 286 | which the small cell can be configured to query periodically. To do |
| 287 | so, visit the ``Settings > SAS`` page. Acquiring the credentials |
| 288 | needed to access the SAS requires you go through a certification |
| 289 | process, but as a practical matter, it may be possible to test an |
| 290 | isolated/low-power femto cell indoors before completing that |
| 291 | process. Consult with your local network administrator. |
| 292 | |
| 293 | 6. **Configure Radio Parameters.** Visit the ``Settings > NR Cell |
| 294 | Configuration`` page (shown in the figure) to set parameters that |
| 295 | control the radio. It should be sufficient to use the default |
| 296 | settings when getting started. |
| 297 | |
| 298 | 7. **Configure the PLMN.** Visit the ``Settings > 5GC`` page to set |
| 299 | the PLMN identifier on the small cell (``00101``) to match the |
| 300 | MCC/MNC values (``001`` / ``01`` ) specified in the Core. |
| 301 | |
| 302 | 8. **Connect to Aether Control Plane.** Also on the ``Settings > 5GC`` |
| 303 | page, define the AMF Address to be the IP address of your Aether |
| 304 | server (e.g., ``10.76.28.113``). Aether's SD-Core is configured to |
| 305 | expose the corresponding AMF via a well-known port, so the server's |
| 306 | IP address is sufficient to establish connectivity. The ``Status`` |
| 307 | page of the management dashboard should confirm that control |
| 308 | interface is established. |
| 309 | |
| 310 | 9. **Connect to Aether User Plane.** As described in an earlier |
| 311 | section, the Aether User Plane (UPF) is running at IP address |
| 312 | ``192.168.252.3``. Connecting to that address requires installing a |
| 313 | route to subnet ``192.168.252.0/24``. How you install this route is |
| 314 | device and site-dependent. If the small cell provides a means to |
| 315 | install static routes, then a route to destination |
| 316 | ``192.168.252.0/24`` via gateway ``10.76.28.113`` (the server |
| 317 | hosting Aether) will work. If the small cell does not allow static |
| 318 | routes (as is the case for the SERCOMM gNB), then ``10.76.28.113`` |
| 319 | can be installed as the default gateway, but doing so requires that |
| 320 | your server also be configured to forward IP packets on to the |
| 321 | Internet. |
| 322 | |
Larry Peterson | d3294df | 2023-09-13 10:35:38 -0400 | [diff] [blame] | 323 | .. admonition:: Troubleshooting Hint |
| 324 | |
| 325 | For the SERCOMM gNB, if you elect to enable GPS, then ``Setting > |
| 326 | Sync_Settings > Sync_Mode`` should be set to ``TIME``. With GPS and |
| 327 | PTP disabled, ``Setting > Sync_Settings > Sync_Mode`` should be set |
| 328 | to ``FREE_RUNNING``. |
| 329 | |
| 330 | .. admonition:: Troubleshooting Hint |
| 331 | |
| 332 | For the SERCOMM gNB, we recommend the following when the gNB's |
| 333 | addresses is acquired via DHCP, assuming that address is unlikely to |
| 334 | change. When configuring the WAN (via the LAN), start with DHCP |
| 335 | enabled. Note the IP address the gNB has been assigned, and then |
| 336 | after disconnecting from the LAN, connect to the GUI via this |
| 337 | address. You will be on the same L2 subnet as the Aether server, |
| 338 | which you should be able to ping using the gNB’s diagnostic tool. |
| 339 | The default gateway DHCP returns does not know how to route data |
| 340 | packets to the UPF. To fix this, modify the WAN settings to use a |
| 341 | static IP, with the DHCP-provided IP used as the gNB's static |
| 342 | address. Then set the default gateway to the IP address of your |
| 343 | Aether server. |
| 344 | |
llp | b353464 | 2023-08-02 09:23:52 -0700 | [diff] [blame] | 345 | Run Diagnostics |
| 346 | ~~~~~~~~~~~~~~~~~ |
| 347 | |
| 348 | Successfully connecting a UE to the Internet is not a straightforward |
| 349 | exercise. It involves configuring the UE, gNB, and SD-Core software in |
| 350 | a consistent way; establishing SCTP-based control plane (N2) and |
| 351 | GTP-based user plane (N3) connections between the base station and |
| 352 | Mobile Core; and traversing multiple IP subnets along the end-to-end |
| 353 | path. |
| 354 | |
| 355 | The UE and gNB provide limited diagnostic tools. For example, it's |
| 356 | possible to run ``ping`` and ``traceroute`` from both. You can also |
| 357 | run the ``ksniff`` tool described in the Networking section, but the |
| 358 | most helpful packet traces you can capture are shown in the following |
| 359 | commands. You can run these on the Aether server, where we use our |
| 360 | example ``ens18`` interface for illustrative purposes: |
| 361 | |
| 362 | .. code-block:: |
| 363 | |
| 364 | $ sudo tcpdump -i any sctp -w sctp-test.pcap |
| 365 | $ sudo tcpdump -i ens18 port 2152 -w gtp-outside.pcap |
| 366 | $ sudo tcpdump -i access port 2152 -w gtp-inside.pcap |
| 367 | $ sudo tcpdump -i core net 172.250.0.0/16 -w n6-inside.pcap |
| 368 | $ sudo tcpdump -i ens18 net 172.250.0.0/16 -w n6-outside.pcap |
| 369 | |
| 370 | The first trace, saved in file ``sctp.pcap``, captures SCTP packets |
| 371 | sent to establish the control path between the base station and the |
| 372 | Mobile Core (i.e., N2 messages). Toggling "Mobile Data" on the UE, |
| 373 | for example by turning Airplane Mode off and on, will generate the |
| 374 | relevant control plane traffic. |
| 375 | |
| 376 | The second and third traces, saved in files ``gtp-outside.pcap`` and |
| 377 | ``gtp-inside.pcap``, respectively, capture GTP packets (tunneled |
| 378 | through port ``2152`` ) on the RAN side of the UPF. Setting the |
| 379 | interface to ``ens18`` corresponds to "outside" the UPF and setting |
| 380 | the interface to ``access`` corresponds to "inside" the UPF. Running |
| 381 | ``ping`` from the UE will generate the relevant user plane (N3) traffic. |
| 382 | |
| 383 | Similarly, the fourth and fifth traces, saved in files |
| 384 | ``n6-inside.pcap`` and ``n6-outside.pcap``, respectively, capture IP |
| 385 | packets on the Internet side of the UPF (which is known as the **N6** |
| 386 | interface in 3GPP). In these two tests, ``net 172.250.0.0/16`` |
| 387 | corresponds to the IP addresses assigned to UEs by the SMF. Running |
| 388 | ``ping`` from the UE will generate the relevant user plane traffic. |
| 389 | |
| 390 | If the ``gtp-outside.pcap`` has packets and the ``gtp-inside.pcap`` |
| 391 | is empty (no packets captured), you may run the following commands |
| 392 | to make sure packets are forwarded from the ``ens18`` interface |
| 393 | to the ``access`` interface and vice versa: |
| 394 | |
| 395 | .. code-block:: |
| 396 | |
| 397 | $ sudo iptables -A FORWARD -i ens18 -o access -j ACCEPT |
| 398 | $ sudo iptables -A FORWARD -i access -o ens18 -j ACCEPT |
Larry Peterson | def1b67 | 2023-08-07 14:06:24 -0700 | [diff] [blame] | 399 | |
| 400 | Support for eNBs |
| 401 | ~~~~~~~~~~~~~~~~~~ |
| 402 | |
| 403 | Aether OnRamp is geared towards 5G, but it does support physical eNBs, |
| 404 | including 4G-based versions of both SD-Core and AMP. It does not |
Larry Peterson | 782fec3 | 2023-10-09 12:30:57 -0700 | [diff] [blame] | 405 | support an emulated 4G RAN. The 4G blueprint uses all the same Ansible |
| 406 | machinery outlined in earlier sections, but starts with a variant of |
Larry Peterson | def1b67 | 2023-08-07 14:06:24 -0700 | [diff] [blame] | 407 | ``vars/main.yml`` customized for running physical 4G radios: |
| 408 | |
| 409 | .. code-block:: |
| 410 | |
| 411 | $ cd vars |
| 412 | $ cp main-eNB.yml main.yml |
| 413 | |
| 414 | Assuming that starting point, the following outlines the key |
| 415 | differences from the 5G case: |
| 416 | |
| 417 | 1. There is a 4G-specific repo, which you can find in ``deps/4gc``. |
| 418 | |
| 419 | 2. The ``core`` section of ``vars/main.yml`` specifies a 4G-specific values file: |
| 420 | |
| 421 | ``values_file: "deps/4gc/roles/core/templates/radio-4g-values.yaml"`` |
| 422 | |
| 423 | 3. The ``amp`` section of ``vars/main.yml`` specifies that 4G-specific |
| 424 | models and dashboards get loaded into the ROC and Monitoring |
| 425 | services, respectively: |
| 426 | |
| 427 | ``roc_models: "deps/amp/roles/roc-load/templates/roc-4g-models.json"`` |
| 428 | |
| 429 | ``monitor_dashboard: "deps/amp/roles/monitor-load/templates/4g-monitor"`` |
| 430 | |
| 431 | 4. You need to edit two files with details for the 4G SIM cards you |
| 432 | use. One is the 4G-specific values file used to configure SD-Core: |
| 433 | |
| 434 | ``deps/4gc/roles/core/templates/radio-4g-values.yaml`` |
| 435 | |
| 436 | The other is the 4G-specific Models file used to bootstrap ROC: |
| 437 | |
| 438 | ``deps/amp/roles/roc-load/templates/radio-4g-models.json`` |
| 439 | |
| 440 | 5. There are 4G-specific Make targets for SD-Core (e.g., ``make |
| 441 | aether-4gc-install`` and ``make aether-4gc-uninstall``), but the |
| 442 | Make targets for AMP (e.g., ``make aether-amp-install`` and ``make |
| 443 | aether-amp-uninstall``) work unchanged in both 4G and 5G. |
| 444 | |
| 445 | The Quick Start and Emulated RAN (gNBsim) deployments are for 5G only, |
| 446 | but revisiting the other sections—substituting the above for their 5G |
| 447 | counterparts—serves as a guide for deploying a 4G version of Aether. |
| 448 | Note that the network is configured in exactly the same way for both |
| 449 | 4G and 5G. This is because SD-Core's implementation of the UPF is used |
| 450 | in both cases. |