gab-arrobo · Sep 9, 2026 · Sep 9, 2026 · Sep 9, 2026 · Sep 9, 2026 · Sep 9, 2026
@@ -5,6 +5,10 @@
 ROC Development
 ===============
 
+.. warning:: ROC is being archived and is no longer part of the OnRamp
+    install/uninstall workflow. This page is retained for historical
+    reference only and no longer reflects a supported configuration.
+
 ROC implements Aether's runtime control API. It is implemented on top
 of `µONOS <https://github.com/onosproject>`_, a microservice-based
 redesign of the ONOS SDN Controller. Of particular note, ROC generates

@@ -32,11 +32,12 @@ radios.
 
 Other Aether guides available on this site include:
 
-* :doc:`Developing for Aether </developer/roc>`: Learn how to
+* :doc:`Developing for Aether </developer/contributing>`: Learn how to
   contribute back to Aether.
 
-* :doc:`Runtime Operations </operations/gui>`: Learn how
-  to operate Aether's 5G connectivity service.
+* :doc:`Runtime Operations </operations/gui>`: Historical documentation
+  of the now-archived ROC GUI for operating Aether's 5G connectivity
+  service.
 
 Note that Aether was originally deployed as a centrally-managed cloud
 service with a dedicated ops team. The expectation was that
@@ -62,9 +63,10 @@ available at:
 * :doc:`SD-Core Documentation <sdcore:index>`
 * :doc:`SD-RAN Documentation <sdran:index>`
 
-A third component, *ROC (Runtime Operational Control)*, is part of the
-Aether Management Plane. This Guide documents how operators use ROC to
-control Aether (see the NAV bar). ROC builds on µONOS (specifically
+A third component, *ROC (Runtime Operational Control)*, was part of the
+Aether Management Plane, historically used to control Aether's runtime
+connectivity configuration (see the NAV bar). ROC is being archived and
+is no longer installed by OnRamp; ROC built on µONOS (specifically
 the ``onos-config`` microservice), with additional documentation for
 developers available at:
 

@@ -58,9 +58,9 @@ Multiple UPFs
 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 user traffic. The resulting deployment
-is then verified using gNBsim.
+requiring the *UPF-to-Slice-to-Device* bindings to be established
+manually via the SD-Core webui to activate end-to-end user traffic.
+The resulting deployment is then verified using gNBsim.
 
 The Multi-UPF blueprint includes the following:
 
@@ -74,18 +74,11 @@ The Multi-UPF blueprint includes the following:
   in the same server, may also work, but is not actively maintained.)
 
 * New make targets, ``5gc-upf-install`` and ``5gc-upf-uninstall``, to
-  be executed after the standard SD-Core installation. The blueprint
-  also reuses the ``amp-roc-load`` target to activate new slices in ROC.
+  be executed after the standard SD-Core installation.
 
 * New Ansible role (``upf``) added to ``deps/5gc``, including a new
   UPF-specific template (``upf-5g-values.yaml``).
 
-* New models file (``roc-5g-models-upf2.json``) added to the
-  ``roc-load`` role in ``deps/amp``. This models file is applied as a
-  patch *on top of* the base set of ROC models. (Since this blueprint
-  is demonstrated using gNBsim, the assumed base models are given by
-  ``roc-5g-models.json``.)
-
 * The OnRamp integration test suite validates the Multi-UPF
   blueprint.
 
@@ -103,13 +96,12 @@ You can also optionally install the monitoring subsystem.
 .. code-block::
 
    $ make k8s-install
-   $ make amp-roc-install
-   $ make amp-roc-load
    $ make 5gc-install
    $ make gnbsim-install
 
-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"``, the
+Device Groups and Slices bound to SD-Core must be entered manually via
+the SD-Core webui rather than being provisioned automatically by simapp.
 
 At this point you are ready to bring up additional UPFs and bind them
 to specific slices and devices. An example configuration that brings
@@ -155,25 +147,11 @@ type:
 At this point the new UPF(s) will be running in their own namespaces
 (you can verify this using ``kubectl get pods --all-namespaces``), but
 no traffic will be directed to them until UEs are assigned to their IP
-address pool. Doing so requires loading the appropriate bindings into
-ROC, which you can do by editing the ``roc_models`` line in ``amp``
-section of ``vars/main.yml``. Comment out the original models file
-already loaded into ROC, and uncomment the new patch that is to be
-applied:
-
-.. code-block::
+address pool. Doing so requires manually configuring a second Device
+Group, Slice, and UPF binding via the SD-Core webui so that the new IP
+address pool is associated with the second UPF.
 
-   amp:
-      # roc_models: "deps/amp/roles/roc-load/templates/roc-5g-models.json"
-      roc_models: "deps/amp/roles/roc-load/templates/roc-5g-models-upf2.json"
-
-Then run the following to load the patch:
-
-.. code-block::
-
-   $ make amp-roc-load
-
-At this point you can bring up the Aether GUI and see that a second
+At this point you can bring up the SD-Core webui and see that a second
 slice and a second device group have been mapped onto the second UPF.
 
 Now you are ready to run traffic through both UPFs, which because the
@@ -388,22 +366,15 @@ differences from the 5G case:
   ``values_file: "deps/4gc/roles/core/templates/radio-4g-values.yaml"``
 
 * The ``amp`` section of ``vars/main.yml`` specifies that 4G-specific
-  models and dashboards get loaded into the ROC and Monitoring
-  services, respectively:
-
-  ``roc_models: "deps/amp/roles/roc-load/templates/roc-4g-models.json"``
+  dashboards get loaded into the Monitoring service:
 
   ``monitor_dashboard:  "deps/amp/roles/monitor-load/templates/4g-monitor"``
 
-* You need to edit two files with details for the 4G SIM cards you
-  use. One is the 4G-specific values file used to configure SD-Core:
+* You need to edit the 4G-specific values file used to configure
+  SD-Core with details for the 4G SIM cards you use:
 
   ``deps/4gc/roles/core/templates/radio-4g-values.yaml``
 
-  The other is the 4G-specific Models file used to bootstrap ROC:
-
-  ``deps/amp/roles/roc-load/templates/radio-4g-models.json``
-
 * There are 4G-specific Make targets for SD-Core (e.g., ``make
   aether-4gc-install`` and ``make aether-4gc-uninstall``), but the
   Make targets for AMP (e.g., ``make aether-amp-install`` and ``make

@@ -15,7 +15,8 @@ are referred to documentation for the respective subsystems:
 
 * To develop SD-RAN, see the :doc:`SD-RAN Guide <sdran:index>`.
 
-* To develop the ROC-based API, see :doc:`ROC Development </developer/roc>`.
+* ROC is being archived; see :doc:`ROC Development </developer/roc>`
+  for historical background on the runtime control API.
 
 * To develop Monitoring Dashboards, see :doc:`Monitoring Development </developer/monitoring>`.
 
@@ -200,18 +201,12 @@ primarily take care of bookkeeping; automating bookkeeping tasks
 
 Finally, keep in mind that in using SD-Core to illustrate how to build
 a customized modify-and-test loop, this section doesn't address some
-of the peculiarities of the other components. As one example, ROC has
-prerequisites that have to be installed before the ROC itself. These
-prereqs are identified in the ROC installation playbook, and include
-``onos-operator``, which in turn depends on ``atomix``.
-
-As another example, the ROC and monitoring services allow you to
-program new features by loading alternative "specifications" into the
-running pods (in addition to installing new container images).  This
-approach is described in the :doc:`ROC Development </developer/roc>`
-and :doc:`Monitoring Development </developer/monitoring>` sections,
-respectively, and implemented by the ``roc-load`` and ``monitor-load``
-roles found in ``deps/amp/roles``.
+of the peculiarities of the other components. For example, the
+monitoring service allows you to program new features by loading
+alternative "specifications" into the running pods (in addition to
+installing new container images). This approach is described in the
+:doc:`Monitoring Development </developer/monitoring>` section, and
+implemented by the ``monitor-load`` role found in ``deps/amp/roles``.
 
 
 

@@ -72,7 +72,7 @@ using.
 .. code-block::
 
     core:
-      standalone: true                # set to false to place under control of ROC
+      standalone: true                # set to false to manage device groups/slices manually via the SD-Core webui
       data_iface: ens18
       values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml"
       ran_subnet: ""                  # set to empty string to get subnet from 'data_iface'
@@ -197,9 +197,8 @@ Aether supports multiple *Device Groups* and *Slices*, but the data
 entered here is purposely minimal; it's just enough to bring up and
 debug the installation. Over the lifetime of a running system,
 information about *Device Groups* and *Slices* (and the other
-abstractions they build upon) should be entered via the ROC, as
-described in the :doc:`Runtime Control </onramp/roc>` section. When
-you get to that point, Ansible variable ``standalone`` in
+abstractions they build upon) can instead be entered via the SD-Core
+webui. When you get to that point, Ansible variable ``standalone`` in
 ``vars/main.yml`` (which corresponds to the override value assigned to
 ``provision-network-slice`` in ``sdcore-5g-values.yaml``) should be set
 to ``false``. Doing so causes the ``device-groups`` and

@@ -13,67 +13,24 @@ tool to trace the flow of packets into and out of SD-Core.
 Install AMP
 ~~~~~~~~~~~~~~~
 
-The Aether Management Platform (AMP) is implemented by two Kubernetes
-applications: *Runtime Operational Control (ROC)* and a *Monitoring
-Service*.\ [#]_ AMP can be deployed on the same cluster as SD-Core by
-executing the following Make target:
+The Aether Management Platform (AMP) provides a *Monitoring
+Service* with Dashboards showing different aspects of Aether's
+runtime behavior. AMP can be deployed on the same cluster as SD-Core
+by executing the following Make target:
 
 .. code-block::
 
    $ make aether-amp-install
 
-Once complete, ``kubectl`` will show the ``aether-roc`` and
-``cattle-monitoring-system`` namespaces running in support of these
-two services, respectively, plus new ``atomix`` pods in the
-``kube-system`` namespace.  Atomix is the scalable key-value store
-that keeps the ROC data model persistent.
+Once complete, ``kubectl`` will show the ``cattle-monitoring-system``
+namespace running in support of this service.
 
-.. [#] Note that what the implementation calls ROC, `Chapter 6
-        <https://5g.systemsapproach.org/cloud.html>`__ refers to
-        generically as *Service Orchestration*.
-
-You can access the dashboards for the two subsystems,
-respectively, at
+You can access the Monitoring dashboard at
 
 .. code-block::
 
-   http://<server_ip>:31194
    http://<server_ip>:30950
 
-The programmatic API underlying the Control Dashboard, which was
-introduced in `Section 6.4
-<https://5g.systemsapproach.org/cloud.html#connectivity-api>`__, can
-be accessed at ``http://10.76.28.113:31194/aether-roc-api/`` in our
-example deployment (where Aether runs on host ``10.76.28.113``). Note
-that if you visit that URL from a browser, OpenAPI will show you
-example GET, DELETE, and POST requests. Those examples assume the
-prefix ``http://10.76.28.113:31194/aether-roc-api/`` (not just
-``http://10.76.28.113:31194``), so for example, to GET the resource
-corresponding to ``site-1``, you would need to use the following URL:
-
-.. code-block::
-
-   http://10.76.28.113:31194/aether-roc-api/aether/v2.1.x/the-enterprise/site/site-1
-
-There is much more to say about the ROC and the Aether API, which we
-return to in the :doc:`Runtime Control </onramp/roc>` section. For
-now, we suggest you simply peruse the Control Dashboard by starting
-with the dropdown menu in the upper right corner. For example,
-selecting `Devices` will show the set of UEs registered with Aether,
-similar to the screenshot in :numref:`Figure %s <fig-roc>`. In an
-operational setting, these values would be entered into the ROC
-through either the GUI or the underlying API. For the Quick Start
-scenario we're limiting ourselves to in this section, these values are
-loaded from ``deps/amp/5g-roc/templates/roc-5g-models.json``.
-
-.. _fig-roc:
-.. figure:: figures/ROC-Dashboard.png
-    :width: 700px
-    :align: center
-
-    Screenshot of the ROC dashboard, showing known *Devices*. The
-    dropdown menu on the right lists other available pages.
-
 Turning to the Monitoring Dashboard, you will initially see
 Kubernetes-related performance stats. Select the *5G Dashboard* option
 to display information reported by SD-Core. Similar to :numref:`Figure
@@ -98,18 +55,8 @@ to tear it down:
    $ make aether-amp-uninstall
 
 Finally, while we have been using a single Make target to install
-(uninstall) AMP as a whole, there are per-component targets for both
-ROC and Monitoring if you are interested in only one or the other. For
-ROC:
-
-.. code-block::
-
-   $ make amp-roc-install
-   $ make amp-roc-load
-   $  ...
-   $ make amp-roc-uninstall
-
-and for Monitoring:
+(uninstall) AMP as a whole, there is also a per-component target if
+you want finer-grained control:
 
 .. code-block::
 
@@ -118,13 +65,11 @@ and for Monitoring:
    $  ...
    $ make amp-monitor-uninstall
 
-In both cases, installing the component is a two-step process: first
-the microservices that implement the component are instantiated on
-Kubernetes and then service-specific data is loaded into the running
-containers. For ROC, that data populates the models that define the
-API. For Monitoring, that data specifies the dashboard panels. In
-general, there are per-component targets for all of the Aether-wide
-(``aether-*``) targets; see the Makefile for details.
+Installing the Monitoring component is a two-step process: first
+the microservices that implement it are instantiated on Kubernetes,
+and then dashboard panel data is loaded into the running
+containers. In general, there are per-component targets for all of
+the Aether-wide (``aether-*``) targets; see the Makefile for details.
 
 View Logs
 ~~~~~~~~~~~~~~~~

@@ -214,7 +214,7 @@ sections, but for a summary, see the :doc:`Quick Reference </onramp/ref>`.
 .. code-block::
 
     core:
-        standalone: true				# set to false to place under control of ROC
+        standalone: true				# set to false to manage device groups/slices manually via the SD-Core webui
         data_iface: ens18
         values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml"
         ran_subnet: "172.20.0.0/16"		# set to empty string to get subnet from 'data_iface'

@@ -87,7 +87,8 @@ the list is not comprehensive.
      - Overlay subnet connecting Core to RAN when gNBs run in a container; set to empty string ("") when gNBs are directly connected via `core.data_iface`.
    * - `core.standalone`
      - `true`
-     - Core to run standalone, initialized from values file; set to `false` when Core is to be initialized by ROC.
+     - Core to run standalone with simapp-managed subscribers; set to
+       `false` to manage device groups/slices via SD-Core webui.
    * - `core.data_iface`
      - `ens18`
      - Network interface used by UPF; same as `gnbsim.data_iface` when co-located on a single server.
@@ -184,8 +185,6 @@ substitute custom config files.
      - Default Path Name
    * - `amp.monitor_dashboard`
      - `deps/amp/roles/monitor-load/templates/5g-monitoring/`
-   * - `amp.roc_models`
-     - `deps/amp/roles/roc-load/templates/roc-5g-models.json`
    * - `core.values_file`
      - `deps/5gc/roles/core/templates/sdcore-5g-values.yaml`
    * - `gnbsim.servers`
@@ -288,9 +287,9 @@ Quick Start Blueprint.
    * - `aether-gnbsim-run`
      - Run gNBsim containers; may rerun multiple times without reinstalling.
    * - `aether-amp-install`
-     - Installs and initializes both ROC and Monitoring workloads.
+     - Installs and initializes the Monitoring workload.
    * - `aether-amp-uninstall`
-     - Uninstalls both ROC and Monitoring workloads.
+     - Uninstalls the Monitoring workload.
 
 Other blueprints define component-specific targets, as listed in the
 following table. (The Aether-wide targets can also be used for all
@@ -301,12 +300,6 @@ other blueprints.)
 .. list-table::
    :widths: 25 50
 
-   * - `amp-roc-install`
-     - Install ROC workload.
-   * - `amp-roc-load`
-     - Load model values into ROC; assumes ROC already deployed.
-   * - `amp-roc-uninstall`
-     - Uninstall ROC workload.
    * - `amp-monitor-install`
      - Install Monitor workload.
    * - `amp-monitor-load`

@@ -1,6 +1,11 @@
 Runtime Control
 -----------------------------------
 
+.. warning:: The ROC (Runtime Operational Control) subsystem described in
+    this section is being archived and is no longer installed, loaded, or
+    supported by OnRamp (``amp-roc-install``/``amp-roc-load`` targets have
+    been removed). This page is retained for historical reference only.
+
 Aether defines an API (and associated GUI) for managing connectivity
 at runtime. This stage brings up that API/GUI, as implemented by the
 *Runtime Operational Control (ROC)* subsystem, building on the

@@ -7,6 +7,11 @@
 Application Management
 ======================
 
+.. warning:: This section documents application management via the ROC
+    web GUI. ROC is being archived and is no longer installed or
+    supported by OnRamp. This page is retained for historical reference
+    only.
+
 Aether allows configuration of the application endpoints that a device
 is allowed to connect to. You can configure not only whether or not an
 application endpoint is reachable, but also what maximum bitrate and