/
Agenda & Meeting Notes

Agenda & Meeting Notes

For an archive of meeting notes pre-dating the Aether Project moving from ONF to LF, click here.

If you need technical help from the Linux Foundation IT staff, please submit a ticket (typically requesting a Project Service). When creating a ticket, set Product = Aether.

4-7-26 (Topics for Next Meeting)

  • SD-Core

    • Continue work to support IMS

    • Helm Charts currently do NOT include 5g-control-plane dependencies (i.e., charts for kafka and mongodb). Should we include them?

  • OnRamp

    • Completed OCUDU blueprint using a release candidate tag release_26_04_rc1

      • Tested simulation mode (ZMQ) and USRPs (B210, X310)

      • Added documentation

    • Made several updates to all OnRamp repos to make them consistent with each other

      • Why do we need to have them as sub-modules? It introduces a lot of overhead when trying to test changes and to sync-up modules

      • Can we consolidate Onramp as a single repository (move its modules from independent repos to part of OnRamp itself)?

  • Potential Contribution: https://forsway.com/

    • Charging (accounting for usage)

    • Non-Terrestrial Networks (NTN)

3-24-26 (Today’s Agenda)

3-10-26

  • Infrastructure

    • All AWS servers shutdown / No negative reports

      • Fixed a hardcoded chart in OnRamp

      • Wait a little bit longer before we turn down VMs

      • Minimal Broadband dependency (being taken care of)

      • No ONF dependency

    • Other Costs

      • IT Essentials (incl domains): $114/mo

      • Email Forwarding: $5/mo

      • Meeting Management: $18/mo

      • Mail Groups: $110 (hope to use free version)

      • Wordpress: $38/mo

      • GitHub Management: $14/mo

      • Confluence/Wiki: $50/mo

      • Cloud acct management: $110/mo (based on % of cloud spend)

      • Jenkins hosting management: $250/mo

  • SD-Core

    • Upgrade UPF/BESS to ubuntu 24.04

      • Still need to update Helm Charts to start using the new UPF version

    • Remove deadcode from codebase

    • Next steps:

      • Integrate BESS (code) into UPF

        • Currently, we build a base image called “bess-build” in the BESS repo

        • UPF repo uses bess-build as base image for the UPF-BESS

      • Drop “epc” from UPF package name

      • Rename PFCP agent image

        • Currently, the container image used for the pfcp agent is called “pfcpiface”

        • Rename it to just “pfcp” such that the UPF build 2 images: “upf-bess” and “upf-pfcp”

    • Reading of how to incorporate BSD-licensed software in Apache 2.0 source (from Claude)

      BSD-3 and Apache 2.0 are compatible licenses — you can incorporate BSD-3 licensed code into an Apache 2.0 project. Here's what you need to do:

      Keep the BSD-3 license notice intact For any BSD-3 licensed files or components you include, preserve the original copyright notice, the list of conditions, and the disclaimer. You can do this by either keeping them in the original source files or collecting them in a NOTICES or THIRD-PARTY-LICENSES file.

      Don't misrepresent the origin BSD-3's third clause prohibits using the original author's name to endorse or promote your product without permission — just don't do that and you're fine.

      Your Apache 2.0 license governs your project as a whole The combined work can be distributed under Apache 2.0. Downstream recipients will receive your code under Apache 2.0, but the BSD-3 portions retain their original notices. Apache 2.0 requires you to include a NOTICE file if one exists in the upstream project — check whether the BSD-3 library has one.

      Practical steps:

      1. Add the BSD-3 component's copyright/license text to a THIRD_PARTY_NOTICES or LICENSE-THIRD-PARTY file in your repo

      2. In that file, identify which files or library the notice applies to

      3. If the BSD-3 project has its own NOTICE file, incorporate that content into your NOTICE file (Apache 2.0 §4(d) requires this)

      4. Don't remove or alter copyright headers in any BSD-3 source files you copy directly

      What you don't need to worry about:

      • BSD-3 has no copyleft requirements, so you don't need to open-source anything extra

      • There's no patent grant clause conflict between the two licenses

      • No special permission from the original authors is needed

      The key principle is: attribute clearly, preserve notices, don't claim endorsement. That's it.

  • SD-RAN

    • …

  • OnRamp

    • Fixed hardcoded Chart links

  • …

2-24-26

  • AWS to GitHub Migration

    • Chart Registries → Done (PR for SDRAN chart should be done by end of the day)

    • Image Registries → Done (all images used by OnRamp workflows are done)

    • Docs → Done

    • Jenkins Jobs → Done

    • Next Step → Wean users off old infrastructure

      • Inform uses of change (suggest they pull latest version of OnRamp, or see most recent registry definitions)

        • Slack, Email, OnRamp Readme, Docs

      • Tag a new version of OnRamp

      • Update docs and other old links (e.g., Wiki)

      • Temporarily take AWS server (Docs & Charts) offline

      • Temporarily take AWS server (Jenkins) offline

    • Also review other Infrastructure services (e.g., Jira)

  • SD-Core

    • sdcore-helm-charts: bess-upf has a servicemonitor component (always disabled) but we also have a servicemonitor component as part of aether-amp that gets deployed when installing Grafana. Why not only using the servicemonitor from the Helm Charts instead of deploying it from aether-amp (monitoring: prometheus/grafana)

  • OnRamp

    • new aether-ocudu blueprint in progress → getting ready for OCUDU release from srsRAN in April

  • …

2-10-26

  • AWS to GitHub Migration

    • Chart Registries

      • SD-Core, ROC, and ONOS are done

      • SD-RAN still todo (Andy looking at this)

    • Image Registries

      • SD-Core amf and bess_build images are already in ghcr.io

        • bess_build is being called by the UPF to build its images (upf-bess and upf-pfcpiface)

        • amf is published but not being used

        • also reviewing PRs to be included

      • ROC is done

      • Publish is step 1 / Make changes to charts to use them is step 2 / Disable old registry is final step

    • Docs

      • Aether & SD-Core are done

      • SD-RAN still todo (Larry will look into it)

    • Jenkins Jobs

  • SD-Core

1-27-26

  • Infrastructure

    • Migrate from AWS to GitHub

      • Chart Registry → ROC done, SD-Core done, SD-RAN still todo

      • Image Registry → ROC in progress, SD-Core in progress, SD-RAN still todo

        • AMF is done, so just need to replicate for other repos

        • ROC-API is done, so just need to replicate for other repos

      • Docs → Aether Done, SD-Core in progress, SD-RAN still todo

        • Gabriel is updating Core docs at the same time (multiversion is the challenge)

      • Jenkins

      • Ownership in omec-project organization

        • It currently has 13 owners. Who should stay? → Trimmed.

        • What is the “omec-ci-triage” team for? Should we keep it or delete it? → Delete

  • SD-Core

    • Updated reusable workflows to publish charts, container images and documentation to GitHub

    • Released a new AMF container image that among other things, address issue with N2 handover

    • Enabled SBOM using SYFT for the AMF and made several improvements to Makefile and its container labels

      • Same process will be replicated across the codebase

    • IOS-MCN working on bug fixes, will submit a PR soon

  • SD-RAN

    • …

  • OnRamp

    • Made a couple updates to aether-5gc and aether-k8s repos → can now control where components get deployed in multi-host cluster; will also need to configure worker nodes to host UPF.

    • Will open a PR for aether-onramp to sync up dependencies and update sd-core charts version

  • …

1-13-26

  • Infrastructure

    • Progress weaning off of AWS

      • Chart Registries

        • Use GitHub Packages (OCI registry)

          • Old helm repo commands no longer needed

          • May impact using local helm charts (should be transparent, but let’s make sure)

        • Manually pushed existing charts to GitHub OCI registry

          • Done for SD-Core and ROC charts, but not yet for SD-RAN

        • OnRamp Updated to use new registry

        • Next step is to update Actions so new charts published to right place (PR is pending for ROC)

          • Sub-charts that are pulled in at build time are not published for independent consumption

      • Docs → Publish on GitHub

      • Images → Use GitHub Package mechanism

        • Continue to replicate on DockerHub

        • Have been publishing bess on github, but…

        • Should do this in a way that takes full advantage of the OCI registry

        • To the best of our knowledge, there is no rate limit on the GitHub registry (as there is on DockerHub)

      • Jenkins → Use GitHub Actions

        • Start by replicating quickstart.groovy

        • As part of opennetworkinglab org

        • Trigger: manually/periodically for now (may trigger when aether-onramp/vars/quickstart.yml changes)

        • What about impact of charging? → So far no charges are being billed; may be grandfathered agreement??

    • Other Cloud services

      • Plan to ditch Jira (use Issues on GitHub)

    • What is the workflow we should follow? Should we use Jira? Keep current workflow (GitHub Issues and Pull Requests)?

    • How should we publish now the SD-Core docs? Before, we were pointing to opennetworking.org but, this domain is NOT working anymore

    • What is the plan to address the GitHub Action pricing change?

  • SD-Core

    • Completed enabling OpenSSF Scorecard across all SD-Core codebase.

      • Minimum score is 8.4 (n3iwf and gnbsim components)

      • Score becomes “green” at 7.5 or higher

    • Should we integrate BESS code into UPF to simplify the building process?

      • No known justification for continuing to keep separate.

12-16-25 (Today’s Agenda)

  • TST Election

    • Elected to 2-year terms: Larry Peterson, Woojong Kim, Ajay Thakur, Sean Condon, and Aneesh Kumar

  • Infrastructure

  • SD-Core

    • Still making progress working on our OpenSSF score.

    • Still making progress on upgrade to R18.

    • Progress on multiple DNNs; PR soon.

    • Working on interface for IMS integration.

  • SD-RAN

    • No report

  • OnRamp

    • No Report

12-2-25

  • TST Election Update

    • Have 5 nominees for 5 positions; awaiting TST approval of those 5 (no election)

  • Infrastructure

    • Moving off AWS → Meeting with LF later today. See notes from 10/28/25 TST call.

    • Update about the Aether or AetherProject organizations from GitHub

      • No response from AetherProject (since public, little chance of GitHub helping)

      • Aether has nothing showing publicly, so there is a better chance GitHub would help.

  • SD-Core

    • Enable OpenSSF scorecard across the SD-Core codebase/repositories

    • Continue having progress with Release upgrade (R18)

      • Currently addressing some issues with the NF caching

  • SD-RAN

    • Someone is still using SDRAN-in-a-Box and Atomix is failing (there is a PR open)

  • OnRamp

    • What is the status update for “Make iptable entries persistent across system reboots (for 5GC)”? → Pending

    • Is there any plan for “improving” Onramp (there are a few Ansible tasks that indicate “todo”) → No

    • Plans to improve “management” practices for OnRamp-related repos

      • e.g., branch protection, OpenSSF scorecard. → Yes, a good idea.

11-18-25

  • TST Election

    • Nominations → Possibilities (someone from IOS MNC)

    • Voting Roll → Ready later today

  • Infrastructure

    • Create a new “Aether” organization in GitHub and move active repos there

    • Leave the legacy orgs with everything else

  • SD-Core

    • For new/potential users:

      • How to raise awareness of the project?

        • In the academic community?

      • Update the aetherproject.org website

      • How to avoid confusion?

        • Is “Aether” the same as “SD-Core”?

        • Should the “SD-RAN” be renamed to “SD-RIC”

    • Move SD-Core repos to a new organization (e.g., aether, or something similar)?

      • “OMEC” (omec-project) was the 4G solution, but “SD-Core” is a 5G solution

  • SD-RAN

    • Does not integrate with srsRAN

    • Known issue:

  • OnRamp

    • Move OnRamp repos to a new organization (not “linked” to its legacy name: open networking but linked to “Aether”)

  • …

11-11-25

  • Meeting canceled. Postponed one week.

10-28-25