—·
Dorongan OCUDU menggeser otomasi RAN dari sekadar demo ke mekanisme produksi: SON, alur spektrum, zero-touch provisioning, dan loop RIC yang terkelola.
Pada Maret 2026, Linux Foundation mengumumkan pembentukan OCUDU Ecosystem Foundation untuk “mempercepat inovasi AI-RAN open source,” sekaligus memposisikan OCUDU sebagai platform referensi bagi perangkat lunak open CU/DU. (https://www.linuxfoundation.org/press/linux-foundation-announces-ocudu-ecosystem-foundation-to-accelerate-open-source-ai-ran-innovation)
Bagi operator, perubahan yang benar-benar penting bukanlah demo baru—melainkan apakah otomasi dapat dijalankan sebagai sistem yang terkendali lintas vendor. Otomasi RAN tingkat produksi pada 2026 bergantung pada seberapa standar antarmuka orkestrasi, alur lifecycle, dan postur keamanan agar perubahan dapat diorkestrasi, diurungkan (roll back), dan diaudit dalam skala besar.
Kerangka platform referensi OCUDU menargetkan kendala utama yang muncul ketika otomasi harus diskalakan pada komponen-komponen yang terdisagregasi: basis perangkat lunak CU/DU akan menentukan seberapa andal otomasi bisa direplikasi, diuji, dan dikelola. Pada saat yang sama, O-RAN WG6 tengah menormalisasi koreografi lifecycle antara SMO (Service Management and Orchestration) dan O-Cloud melalui kesamaan O2 APIs. (https://public.o-ran.org/display/WG6)
Jadi, bagi praktisi: Perlakukan OCUDU dan O-RAN WG6 bukan sekadar “kemajuan standar,” melainkan masukan untuk keputusan yang konkret: apakah toolchain otomasi berbicara dengan antarmuka orkestrasi dan lifecycle yang stabil hari ini—atau setiap rollout multi-vendor justru menambah risiko integrasi tersembunyi dan kontrol perubahan (change-control) yang rumit?
OCUDU digambarkan oleh Linux Foundation sebagai inisiatif open-source yang mempercepat inovasi wireless melalui “portable, open-source CU/DU software stack” dengan tata kelola yang netral. (https://www.linuxfoundation.org/press/linux-foundation-announces-ocudu-ecosystem-foundation-to-accelerate-open-source-ai-ran-innovation)
Titik awal ini penting karena zero-touch provisioning dan manajemen lifecycle hanya seterministik artefak perangkat lunak yang dideploy. Jika pipeline otomasi tidak mampu menjamin perilaku CU/DU yang konsisten lintas lokasi—dan lintas vendor—maka pipeline akan macet saat kebutuhan paling besar muncul: ketika melakukan scale-out, upgrade perangkat lunak, dan rollback. Pendekatan ekosistem OCUDU ditujukan untuk menekan variabilitas dengan menggeser “integrasi via adapter” menuju komponen fondasi bersama.
Pembaruan OCUDU pada Maret 2026 juga terhubung dengan momentum di luar lapisan CU/DU. Misalnya, pelaporan tentang rilis perdana OCUDU menunjukkan adanya upaya transisi untuk srsRAN CU/DU di bawah Linux Foundation serta pergeseran menuju tata kelola netral. (https://the-mobile-network.com/2026/03/ocudu-moves-into-big-time-with-major-vendor-backing/)
Jadi, bagi praktisi: Saat menyusun roadmap otomasi RAN, jadikan OCUDU sebagai primitif tata kelola (governance primitive). Jadikan provenance build CU/DU yang dapat direplikasi serta kompatibilitas lifecycle sebagai kriteria “siap-otomasi,” bukan sekadar pikiran belakangan.
Salah satu cara efektif untuk menghentikan perdebatan tentang apakah otomasi RAN itu “mungkin” adalah mengubahnya menjadi empat langkah yang terlihat oleh operator—langkah yang langsung dikenali oleh dewan kontrol perubahan, tim keamanan, dan tim SRE.
SON (Self-Organizing Networks) distandardisasi sebagai rangkaian fungsi otomatis untuk self-configuration dan self-optimization jaringan. 3GPP mendeskripsikan SON sebagai kemampuan untuk self-configuration dan self-optimization, termasuk perilaku serupa pemulihan (recovery-like) ketika stasiun pangkal tetangga melakukan re-konfigurasi saat sebuah sel gagal. (https://www.3gpp.org/technologies/son)
Yang sering hilang dalam rollout “otomasi SON” adalah rollback operasional. Perubahan SON menyentuh parameter radio yang berdampak pada cakupan, interferensi, dan perilaku handover. Dalam lingkungan multi-vendor, operator memerlukan (a) pagar pengaman (guardrails) atas rentang parameter, (b) jalur rollback berbasis versi untuk konfigurasi, dan (c) observabilitas untuk memastikan aksi SON benar-benar meningkatkan KPI yang ditargetkan—bukan sekadar menukar satu masalah dengan masalah lain.
Kebutuhan rollback perlu diterjemahkan dari konsep ke prosedur. Minimal, lampirkan empat elemen pada setiap peristiwa perubahan SON: (1) parameter diff, (2) input model “reason”, (3) definisi KPI target beserta time window, dan (4) mekanisme revert yang deterministik. Bagian deterministik penting karena “revert ke last known good” hanya sebaik snapshot last-known-good terakhir. Jika workflow SON tidak dapat menunjuk ke versi konfigurasi tertentu (misalnya, bundel parameter yang tersimpan atau revisi konfigurasi yang didefinisikan vendor) dan mengaplikasikannya kembali melalui jalur lifecycle yang sama, rollback berubah menjadi intervensi manual yang hanya bersifat best-effort.
Kedisiplinan juga dibutuhkan pada KPI. Kegagalan SON yang tipikal tidaklah halus: rebalancing neighbor yang terlalu agresif dapat menaikkan rasio kegagalan handover dan memicu ping-pong handovers meskipun metrik cakupan terlihat membaik. Praktisi perlu mewajibkan keluarga KPI yang eksplisit seperti handover success rate, handover failure ratio, RRC setup success rate, serta PRB utilization / interference proxy untuk sel-sel yang terdampak, disertai window pemicu rollback (misalnya, “jika ada KPI memburuk melewati ambang dalam X menit/jam”). Intinya bukan pada ambang itu sendiri; melainkan kontrak KPI dan logika pemicunya harus dikodekan serta bisa diaudit di lapisan orkestrasi.
3GPP juga telah mengembangkan kemampuan SON lintas rilis; misalnya, Ericsson menjelaskan enhanced SON features pada 3GPP Release 17 yang dirancang untuk mengumpulkan dan menggunakan data yang diperlukan dari user equipment serta node jaringan lain. (https://www.ericsson.com/en/blog/2022/12/rel-17-enhanced-son-features)
Jadi, bagi praktisi: Implementasikan SON sebagai workflow yang terkendali dengan state eksplisit “approve, deploy, validate, rollback”—tetapi wajibkan bukti artefaknya: (1) referensi revisi parameter/konfigurasi yang tersimpan untuk setiap aksi SON, (2) KPI contracts dengan metrik bernama serta window evaluasi, dan (3) rollback trigger yang dapat mengembalikan secara otomatis melalui jalur antarmuka yang sama seperti saat deployment (bukan runbook operator).
Manajemen spektrum otomatis bukan hanya soal memilih frekuensi; ia adalah pengambilan keputusan berbasis kebijakan yang terhubung dengan umpan balik pengukuran. Jika SON fokus pada optimasi neighbor dan cakupan, otomatisasi spektrum cenderung bergantung pada policy serta measurement feedback loops yang menyetel cara sumber daya dialokasikan.
Risiko operasional utama pada “closed-loop spectrum” adalah kualitas pengukuran yang bising (noise), batasan regulasi yang spesifik wilayah, serta tindakan kontrol yang bisa tidak dapat dibatalkan pada momen tertentu jika tidak ada jejak keputusan yang dapat diulang (replayable decision trace). Karena itu, di produksi, loop otomasi spektrum semestinya didefinisikan dalam tiga lapisan: telemetry inputs, policy constraints, dan actuation targets—masing-masing dengan jejak (traceability) di tingkat antarmuka.
Telemetry inputs memerlukan provenance yang jelas: pengukuran mana yang dipakai (dan dengan tingkat granularity seperti apa), bagaimana data dinormalisasi (per-carrier, per-cell, per time slice), serta seberapa cepat ia mengalir ke lapisan kontrol. Policy constraints harus mencakup safety envelopes (misalnya laju perubahan daya pancar maksimum, daftar band/channel yang dilarang, dan aturan mitigasi interferensi) serta batas regulasi (alokasi spektrum lokal dan kewajiban coexistence yang spesifik operator). Bahkan bila operator sudah memahami batasan-batasan tersebut, otomasi tetap harus mengenkodenya dengan cara yang bisa diaudit di kemudian hari—terutama ketika keputusan kontrol diperdebatkan (misalnya, “Mengapa channel X dipilih pada 14:05?”).
Actuation targets harus dibatasi dan dapat dibalik. Loop yang hanya “menyetel” lewat perubahan konfigurasi ad hoc akan sulit memberikan rollback yang dapat diaudit. Yang diperlukan adalah aksi kontrol spektrum yang memetakan ke operasi orkestrasi yang berbasis versi (deploy/update/rollback), sehingga perintah yang sama di bidang control-plane bisa diulang kembali atau diurungkan. Dalam praktiknya, ini berarti lapisan orkestrasi/kontrol harus mencatat decision ID, versi kebijakan, snapshot telemetry yang dipakai, serta hasil dari perintah actuation.
Arsitektur O-RAN relevan karena ia membingkai kontrol closed-loop pada control layers berbasis RIC, di mana kebijakan dan telemetry dapat digabungkan untuk mengarahkan optimasi. Dokumentasi ETSI tentang O-RAN menjelaskan O2 interface sebagai penghubung SMO dan O-Cloud untuk manajemen lifecycle sumber daya dan deployment, serta menjelaskan fungsi-fungsi O-RAN di sekitar RIC dan orkestrasi. (https://www.etsi.org/deliver/etsi_TS/104100_104199/104104/09.01.00_60/ts_104104v090100p.pdf)
Pada praktiknya, itu berarti pipeline otomasi spektrum perlu cara standar untuk (1) menyerap data pengukuran dan fault ke lapisan orkestrasi/kontrol, (2) menerapkan policy constraints (safety envelopes, batas regulasi), dan (3) mendorong perubahan konfigurasi dengan versioning serta audit trails.
Jadi, bagi praktisi: Perlakukan otomasi spektrum sebagai masalah “kebijakan + pengukuran + antarmuka orkestrasi,” dan paksa vendor untuk menentukan (1) stream telemetry mana yang memberi makan tiap keputusan, (2) versi kebijakan serta set constraint mana yang diterapkan, dan (3) bagaimana setiap actuation bisa diurungkan melalui lifecycle/versioned commands.
Zero-touch provisioning adalah janji operasional bahwa onboarding lokasi atau perubahan konfigurasi bisa dieksekusi dengan intervensi manusia yang minimal. Dalam konteks O-RAN, implementasi ini diwujudkan melalui interaksi manajemen lifecycle antara SMO dan O-Cloud melalui O2 APIs.
Arah kerja O-RAN WG6 secara eksplisit menargetkan “lifecycle flows dan commonality O2 APIs antara SMO dan O-Cloud.” Dokumen itu menggambarkan RAN multi-vendor yang terdisagregasi sebagai kebutuhan akan API bersama yang netral vendor untuk discovery managed element, manajemen lifecycle, dan orkestrasi lintas network functions. (https://public.o-ran.org/display/WG6)
Untuk panduan implementasi yang konkret, dokumentasi O-RAN Software Community tersedia untuk SMO O2. Situs dokumentasi proyek O-RAN SC SMO O2 menyediakan pointer dokumentasi API dan antarmuka O2 yang terstruktur. (https://docs.o-ran-sc.org/projects/o-ran-sc-smo-o2/en/latest/index.html)
Operator juga secara terbuka membahas hasil “zero touch” yang terkait otomasi O-RAN. Vodafone menyatakan tengah mengerjakan otomasi Open RAN “untuk memberikan konektivitas pelanggan dalam satu klik,” menjelaskan konsep “E2E Distributed Zero Touch Deployment,” serta menyebut harapan mempercepat waktu onboarding situs dan layanan baru “sebesar 75%.” (https://www.vodafone.com/news/newsroom/technology/open-ran-automation-provide-customers-connectivity-in-one-click)
Jadi, bagi praktisi: Petakan langkah onboarding dan lifecycle ke lifecycle APIs yang diekspos O2. Jika proses “zero-touch” tidak dapat ditelusuri ke operasi lifecycle tertentu serta pemanggilan antarmuka yang spesifik, proses itu tidak akan bertahan pada audit ataupun ekspansi multi-vendor.
Model RIC (RAN Intelligent Controller) dalam O-RAN lazim dibagi ke dalam timescales: non-real-time (untuk operasi closed-loop yang lebih lambat seperti optimasi dan assurance) serta near-real-time (untuk kontrol radio berkecepatan tinggi). Dokumentasi ETSI menjelaskan keterkaitan fungsi SMO dan RIC serta layanan terkait O2 dengan deployment dan lifecycle management. (https://www.etsi.org/deliver/etsi_gr/NFV-IFA/001_099/046/05.02.01_60/gr_nfv-ifa046v050201p.pdf)
Masalah operasional utamanya adalah governance. Perubahan kontrol pada near-real-time bergerak cepat untuk menyetel parameter radio. Kontrol non-real-time mengubah perilaku layanan dan kebijakan optimasi secara lebih pelan. Bagaimanapun, otomasi wajib dapat diaudit: perlu diketahui kebijakan mana yang memutuskan, telemetry apa yang dipakainya, komponen apa yang dikendalikannya, serta jalur rollback yang tersedia.
Detail yang memungkinkan hal ini adalah keselarasan antarmuka lintas lapisan. WG6 menekankan commonality O2 API agar orkestrasi dan lifecycle management bisa berperilaku konsisten. (https://public.o-ran.org/display/WG6)
Blueprint operasional dan deskripsi platform juga menunjukkan bahwa orkestrasi berbasis RIC bisa diinsinyurkan ke arsitektur SMO. White paper Ericsson tentang “SMO enabling intelligent RAN operations” menjelaskan rApps yang memanfaatkan fungsi non-RT RIC dan menerangkan bahwa O2 mendukung orkestrasi manajemen O-Cloud seperti inventory, monitoring, software management, dan lifecycle management. (https://www.ericsson.com/en/reports-and-papers/white-papers/smo-enabling-intelligent-ran-operations)
Jadi, bagi praktisi: Governance loop kontrol harus memiliki identitas kebijakan yang jelas, versioning, serta semantik deploy/rollback—dan audit trail harus menjadi kebutuhan antarmuka tingkat pertama, bukan latihan kepatuhan yang dilakukan belakangan.
Vodafone menggambarkan otomasi Open RAN yang ditujukan untuk onboarding situs dan layanan lewat “one-click,” serta mengklaim target “peningkatan 75%” pada waktu untuk mendepploy situs dan layanan baru. (https://www.vodafone.com/news/newsroom/technology/open-ran-automation-provide-customers-connectivity-in-one-click)
Lebih dari sekadar headline. Vodafone mengharapkan otomasi menekan bottleneck perubahan manusia: waktu dan persetujuan yang diperlukan saat mendepploy komponen jaringan dari banyak vendor. Ini juga menandai penyelarasan tujuan otomasi dengan antarmuka orkestrasi end-to-end—bukan skrip konfigurasi radio yang berdiri sendiri.
Yang perlu diverifikasi dalam rollout sendiri: bandingkan baseline “time-to-first-on-air” dan “time-to-change-approval” sebelum dan sesudah standardisasi panggilan lifecycle O2. Pernyataan Vodafone adalah target, sehingga bukti internal semestinya berupa metrik kontrol yang dapat diaudit.
Rakuten Symphony mengumumkan deployment platform RIC buatan sendiri di jaringan Open RAN Rakuten Mobile untuk 4G dan 5G di Jepang. Pengumuman itu menyebut RIC tersebut memungkinkan optimasi dan pengambilan keputusan berbasis AI, sekaligus mengklaim penghematan konsumsi daya “sekitar 20%.” (https://symphony.rakuten.com/newsroom/rakuten-mobile-and-rakuten-symphony-deploy-intelligent-ai-powered-ric-platform-in-rakutens-4g-and-5g-open-ran-network-in-japan-setting-the-stage-for-sustainable-mobile-connectivity)
Rilis kedua Rakuten Symphony/Rakuten Mobile melaporkan demonstrasi di mana model AI/ML memungkinkan penghematan energi “hingga 25%” melalui antarmuka ke RIC yang mengonfigurasi penggunaan antena. (https://symphony.rakuten.com/newsroom/rakuten-mobile-rakuten-symphony-demonstrate-25-energy-savings-through-ai-model-on-ran-intelligent-controller)
Secara bersama, temuan ini mengisyaratkan otomasi berbasis RIC bisa bergeser dari “eksperimen model energi” menjadi “operasi control-plane” yang memengaruhi perilaku jaringan yang sedang berjalan.
Batasan penting: hasil tersebut adalah laporan vendor. Operator semestinya menuntut metodologi pengukuran independen, termasuk bagaimana baseline didefinisikan dan apakah penghematan mencakup semua perubahan operasional yang relevan (pendinginan, transport, komposisi trafik). Bukti yang disajikan bersifat indikatif, bukan otomatis dapat diperbandingkan lintas operator.
Deutsche Telekom mempublikasikan hasil uji multi-vendor yang menjelaskan non-real time RIC dan konsep rApp untuk mengotomasi serta mengoptimalkan RAN terdisagregasi. Uji ini memanfaatkan solusi berbasis O-RAN SC Non-RT RIC serta menjelaskan adanya kerangka SMO yang dikembangkan sendiri. Pengumuman juga membingkai non-RT RIC sebagai enabler aplikasi pihak ketiga untuk otomasi closed-loop. (https://www.telekom.com/en/media/media-information/archive/non-real-time-ran-optimization-1048264)
Upaya uji ini berkaitan dengan lapisan governance: loop non-real-time mengubah kebijakan dan pengaturan optimasi. Perspektif multi-vendor penting karena rantai otomasi produksi harus tetap bertahan ketika sebuah komponen berpindah vendor atau versi.
Capgemini mengumumkan kesepakatan dengan Deutsche Telekom untuk menginsinyur platform terbuka yang menyatukan bagi otomasi RAN cerdas. Pengumuman ini menyatakan secara eksplisit bahwa SMO yang dikembangkan akan beroperasi secara konsisten di lingkungan O-RAN dan legacy RAN untuk segmen Eropa Deutsche Telekom. (https://www.capgemini.com/us-en/news/press-releases/capgemini-and-deutsche-telekom-engineer-an-open-platform-for-intelligent-ran-automation/)
Pengumuman itu juga menyebut kapabilitas bertumpu pada deployment RIC, dan SMO yang dibangun membawa otomasi lintas lingkungan Open RAN maupun legacy radio access network. (https://www.capgemini.com/us-en/news/press-releases/capgemini-and-deutsche-telekom-engineer-an-open-platform-for-intelligent-ran-automation/)
Mengapa ini layak masuk dalam editorial otomasi RAN: ini sinyal ekonomi bagi operator. Jika otomasi tidak mampu berkoordinasi lintas jaringan lintas generasi dan lintas vendor, penghematan akan “kebocoran” ke pekerjaan integrasi dan bottleneck change-control.
Operator menurunkan biaya bukan karena AI “ada,” melainkan karena intervensi manusia berkurang. Dalam program otomasi, buku besar ekonomi biasanya memuat tiga pos biaya yang berulang: (1) pekerjaan konfigurasi dan provisioning manual, (2) waktu peninjauan change-control untuk perubahan konfigurasi, dan (3) pengujian regresi integrasi saat komponen multi-vendor bergeser.
Fokus O-RAN WG6 pada lifecycle flows dan common O2 APIs menargetkan pos #1 dan #3 langsung dengan upaya orkestrasi yang netral vendor untuk managed element discovery, lifecycle management, serta orkestrasi. (https://public.o-ran.org/display/WG6)
Sementara itu, target “one-click” Vodafone dan kisah penghematan Rakuten menyediakan narasi ROI yang bisa dihubungkan praktisi ke biaya operasional. Kerangka “peningkatan 75%” yang diharapkan Vodafone pada durasi onboarding mengubah problem penjadwalan dan kebutuhan tenaga kerja ketika workflow automation berjalan. (https://www.vodafone.com/news/newsroom/technology/open-ran-automation-provide-customers-connectivity-in-one-click)
Contoh lain adalah penghematan konsumsi daya “sekitar 20%” dari Rakuten, yang memperlihatkan bagaimana otomasi berbasis RIC bisa menjadi tuas efisiensi energi yang terukur di produksi. (https://symphony.rakuten.com/newsroom/rakuten-mobile-and-rakuten-symphony-deploy-intelligent-ai-powered-ric-platform-in-rakutens-4g-and-5g-open-ran-network-in-japan-setting-the-stage-for-sustainable-mobile-connectivity)
Cara praktis memahami ekonomi dalam program adalah menerjemahkan otomasi menjadi tiga KPI operasional yang dapat dipertahankan dalam rapat governance: (1) time-to-change (termasuk change-control lead time), (2) time-to-rollback dan rollback success rate, serta (3) jam operasional yang dihemat per workflow yang terotomasi—dinormalisasi dengan jumlah situs.
Jadi, bagi praktisi: Investasikan standardisasi antarmuka lifecycle sejak awal (SMO O2 APIs, jalur deployment yang diorkestrasi). Pekerjaan inilah yang membuat penghematan tahan lama saat vendor kedua dan ketiga masuk ke proyek.
Governance otomasi sering diperlakukan sebagai keamanan defensif: authentication dan authorization. Dalam otomasi RAN multi-vendor, pertanyaan keamanan menjadi lebih luas—perlu memastikan otomasi terkendali (constrained), terverifikasi (verifiable), dan dapat dipulihkan (recoverable).
Rilis O-RAN dan laporan terkait telah menekankan pelaporan teknis keamanan untuk SMO serta aplikasi lifecycle management. Misalnya, blog O-RAN sendiri tentang implementasi Release 3 menyoroti “security technical reports” yang mencakup output threat and risk analysis untuk application lifecycle management, log management, service management dan orchestration. (https://www.o-ran.org/blog/o-ran-release-3-implements-features-with-58-new-or-updated-technical-documents)
Lebih langsung, dokumentasi ETSI menjelaskan peran O2 interface dalam cloud resource management dan workload management, serta mengaitkan layanan-layanan terkait O2 dengan deployment lifecycle management—di mana auditability menjadi memungkinkan. Jika aksi orkestrasi dipetakan ke standardized lifecycle services, aksi tersebut bisa dicatat secara konsisten. (https://www.etsi.org/deliver/etsi_TS/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf)
Terakhir, dokumentasi untuk O-RAN SC SMO O2 serta keberadaan API documentation mendukung gagasan bahwa governance dapat digerakkan oleh antarmuka—bukan hanya “proses-driven.” (https://docs.o-ran-sc.org/projects/o-ran-sc-smo-o2/en/latest/index.html)
Jadi, bagi praktisi: Pastikan setiap kapabilitas otomasi mencakup (1) identity dan versi untuk logika otomasi, (2) orchestration actions yang bisa diaudit dan dipetakan ke lifecycle APIs, serta (3) rollback yang diuji di staging dan disiapkan (rehearsed) untuk change windows produksi.
Berdasarkan bukti, jalur operasional sudah jelas: upaya OCUDU dan O-RAN WG6 mengarah pada standardized lifecycle dan orkestrasi, tetapi operator tetap harus menerjemahkannya menjadi implementation checklist serta outcome yang bisa diukur.
Pada siklus pengadaan dan arsitektur berikutnya, operator perlu mewajibkan vendor otomasi dan integrator menyerahkan tiga artefak yang selaras dengan O-RAN orchestration mechanics:
Agar konkret, pihak yang dapat dipengaruhi adalah pemilik platform SMO atau prime integrator. Kaitan acceptance criteria pada perilaku interface O2 dan semantik rollback yang bisa diaudit, serta minta bukti dari uji coba staging yang meniru komposisi multi-vendor yang digunakan di produksi. Arah standar untuk kebutuhan ini konsisten dengan fokus WG6 pada O2 API commonality dan lifecycle flows. (https://public.o-ran.org/display/WG6)
Dalam 6 hingga 12 bulan ke depan, pergeseran dari “automation demonstrations” menuju “automation yang bisa digovern” akan dipercepat—meski tidak merata. Alasannya adalah kesiapan antarmuka harus sinkron: SMO O2 APIs dan tooling lifecycle perlu matang pada ritme rilis yang sama ketika operator mendepploy platform.
Proyeksi yang masuk akal: pada Q4 2026, banyak program operator akan mampu mengotomasi site onboarding end-to-end secara terkendali, sementara otomasi untuk self-optimizing radio parameter loops (SON dan spectrum tuning) akan menuntut guardrails yang lebih ketat serta rollback yang lebih sering direhears. Ini selaras dengan cara upaya orkestrasi dan lifecycle commonality disusun pada level antarmuka, serta bagaimana pengumuman operator menekankan penurunan waktu onboarding dan deployment platform RIC. (https://public.o-ran.org/display/WG6)
Aksi yang paling menentukan: Jadikan lifecycle auditability yang selaras O2 dan bukti pengujian rollback sebagai gerbang kontraktual pada deployment otomasi 2026—dan otomatisasi RAN multi-vendor akan berubah dari janji menjadi sistem produksi yang benar-benar dapat dioperasikan.