Lab 2: Deploying your xApp through a network blueprint

In Lab 1 you packaged the RAN-slicing xApp into an image and a CompositionModel named after your org (with a ran-slicing mode). In this lab you deploy it the way BubbleRAN xApps are deployed: as an Element in a Network blueprint.

This is the same scenario as xApp Training — Lab 5 (rf-sim gNB + minimal 5GC + FlexRIC + a RAN-slicing xApp) — except the xApp is no longer started manually on bare-metal. It is declared once in the blueprint and BubbleRAN's SMO runs it, restarts it, and connects it to the RIC for you.

Prerequisites

• You completed Lab 1: the image is pushed and the CompositionModel is installed (brc list model shows your <org> model).
• You know your model reference: <org>/ran-slicing (<org> is your cluster name).

Step 1 — Add your xApp to the network's edge

Take the Lab 5 network and add your CDK-built model to the edge: section. The only change versus Lab 5 is the extra edge Element pointing at <org>/ran-slicing.

open-ran-cdk.yaml

apiVersion: athena.trirematics.io/v1
kind: Network
metadata:
    name: bubbleran
    namespace: trirematics
spec:
    slices:
        -   plmn: "00101"
            dnn: "internet"
            network-mode: "IPv4"
            service-type: eMBB
            differentiator: 0x000000
            ipv4-range: "12.1.1.0/24"
            ipv6-range: "2001:db8:1::/64"
    access:
        -   name: oai-gnb
            stack: 5g-sa
            model: oai-ran/monolithic-gnb
            identity:
                an-id: 50
            radio:
                device: rf-sim
            cells:
                -   band: n78
                    arfcn: 641280
                    bandwidth: 40MHz
                    subcarrier-spacing: 30kHz
                    tdd-config:
                        period: 5ms
                        dl-slots: 7
                        dl-symbols: 6
                        ul-slots: 2
                        ul-symbols: 4
            controller: flexric.bubbleran
            core-networks:
                - minimal.bubbleran
    core:
        -   name: minimal
            stack: 5g-sa
            model: oai-cn/minimal
            identity:
                region: 0
                cn-group: 4
                cn-id: 5
    dns:
        ipv4:
            default: 8.8.8.8
            secondary: 8.8.4.4
    edge:
        -   name: flexric
            stack: 5g-sa
            model: mosaic5g/flexric
        # ── your CDK-built xApp ──────────────────────────────────────────────
        -   name: ran-slicing
            stack: 5g-sa
            model: <org>/ran-slicing      # the CompositionModel from Lab 1
---
apiVersion: athena.trirematics.io/v1
kind: Terminal
metadata:
    name: ue1
    namespace: trirematics
spec:
    vendor: oai
    stack: 5g-sa
    model: terminal/nr-rfsim
    preferred-access: oai-gnb.bubbleran
    target-cores:
        - minimal.bubbleran
    identity:
        imsi: "001010000000001"
        pin: "1234"
        opc: "0xc42449363bbad02b66d16bc975d77cc1"
        key: "0xfec86ba6eb707ed08905757b1bb44b8f"
        sqn: "0xff9bb4000001"
    slice:
        dnn: "internet"
        network-mode: "IPv4"
        service-type: eMBB
        differentiator: 0x000000
    radio:
        bands:
            - n78

Replace <org>

Set model: <org>/ran-slicing to your actual model name from brc list model (it matches your cluster/kubeconfig name). The ran-slicing suffix is the deployment-mode created from your entry-point file in Lab 1.

Your xApp's metrics go to VictoriaMetrics automatically

The xApp SDK can write its KPM/MAC metrics natively to VictoriaMetrics, the platform's observability backend. When you deploy through the CDK the CompositionModel's config template — rendered by the Athena manager at deploy time — wires your xApp to the cluster's VictoriaMetrics for you. Your samples land in vmsingle and are immediately queryable and ready to dashboard in Grafana. See the Data Storage and Observability guide.

Step 2 — Deploy

brc install network open-ran-cdk.yaml

It should print the created Kubernetes resources without errors. Watch the rollout:

brc observe

Wait until every Element other than the UE reaches 1/1 Y, including your ran-slicing xApp.

Step 3 — Verify the xApp is running and connected

Your xApp pulled its image from the cluster-local registry and connected to the FlexRIC declared in the same network — no manual update_conf.py, no manual run. Check its logs:

kubectl -n trirematics logs deploy/ran-slicing.ran-slicing.bubbleran -c xapp --tail=20

You should see the same KPM subscription and RC slicing-control activity you saw on bare-metal in Lab 5 — for example periodic throughput readings and dedicated_prb control acknowledgements — but now produced by a managed Element:

... E42 SETUP-RESPONSE rx
... Connected E2 Node(s) 1
... RIC_SUBSCRIPTION_RESPONSE rx RAN_FUNC_ID 2
ue_thp_kbs 72742.99
... E42_RIC_CONTROL_REQUEST RAN_FUNC_ID 3 tx
... CONTROL ACK rx
dedicated_prb 28

Outcome

	Bare-metaldevelopment (xApp training)	Integrated xApp (this lab)
How it runs	./build/labs/lab5 conf/xapp.yaml on bare-metal	Network Element from a CompositionModel
RIC connection	manual (update_conf.py writes the RIC IP)	Automatically done by the manager
Lifecycle	Manual: you start/stop it	Automatic: declared in the same blueprint as the rest of the network elements, same lifecycle
Portability	Tied to bare-metal host environment	Deployable on any cluster with the model

Iterating

When you change your xApp, rebuild and re-roll it:

brc cdk image build && brc cdk image push   # new image (same :latest tag)
brc cdk model patch                          # re-roll the model so the Pod restarts

model patch stamps a fresh annotation on the deployment-modes so Athena restarts the xApp Pod even though the image tag (:latest) is unchanged.

You have now taken an xApp all the way from development (xApp Training) to a declarative, cluster-managed deployment — using only the CDK and the Network CRD.