Blueprints
This section contains various test Blueprints that can be used for validation and integration testing of MX-PDK features. The blueprints covered in this section are normally included in your Control-Plane node of your MX-PDK.
The network and Terminal blueprints shown here come from the public
BubbleRAN blueprints repository, at the falcon release tag.
Clone it to get every file at once:
git clone --branch falcon https://github.com/bubbleran/blueprints.git
Each blueprint shows its path in the repository. Blueprints with a soft UE (RF simulator, ZMQ, NTN) include their
Terminal, and the over-the-air blueprints end with the preferred-access and target-cores to use for the UE.
The Non-Terrestrial Network (NTN) blueprints are experimental.
Kubernetes Concept Review
Before we get started, let's review some Kubernetes concepts.
Namespaces
In Kubernetes, your cluster is divided into logical domains called namespace.
Each namespace has its own set of resources, and you can create multiple namespaces.
When working with the CLI the default namespace is trirematics and when working with Kubectl the default namespace is
default.
To change the default namespace, use the --namespace or -n flags in either of the CLI or Kubectl.
If you are looking for a resource and can't find it, verify the namespace you are in.
You could equivalently use the environment variable CLI_NAMESPACE to set the default namespace for the CLI.
YAML files
Kubernetes understands YAML files.
YAML is a human-readable data-serialization language, a superset of JSON.
YAML files are used to define the desired state of your cluster and Kubernetes expresses the status of your cluster
in the same format.
Each YAML file may contain several YAML documents, separated by ---.
When you install a network, all the resources defined in the YAML files are created in the cluster, one per document.
Declarative and Idempotent
Trirematics' operations are idempotent. This means that if you run the same command twice, the second time will have no effect and your cluster will remain in a perfectly valid state.
Trirematics' design is declarative, which means that you define the desired state of your cluster and Trirematics will make the cluster match that state. You don't need to know how to do that, Trirematics will figure it out. You simply express your intentions.