Membongkar jaringan: Pergeseran menuju operasi otonom berbasis maksud

insinyur di tempat kerja

Industri telekomunikasi, landasan konektivitas global, telah mengalami kebangkitan teknologi selama beberapa waktu, didorong oleh inovasi seperti 5G, IoT, komputasi cloud, dan AI. Akibatnya, jaringan menjadi semakin sulit dikelola. Ada kebutuhan akan otomatisasi untuk menangani tugas-tugas rutin, memantau kesehatan jaringan, dan menanggapi masalah secara real-time. Namun, keahlian yang ada di dalam penyedia layanan komunikasi (CSP) mungkin tidak sejalan dengan tuntutan yang berkembang dari lingkungan yang dinamis ini. Untuk berhasil dalam era modern, CSP membutuhkan tim serbaguna, termasuk ilmuwan data untuk interpretasi dan operasi data, pengembang perangkat lunak untuk otomatisasi melalui antarmuka pemrograman aplikasi vendor (API), dan insinyur jaminan layanan untuk merancang siklus tertutup guna memastikan keandalan layanan.

Sementara CSP menjembatani kesenjangan dengan membangun tim dengan pengalaman yang beragam, dalam waktu bersamaan mereka juga mendapat manfaat dari kemajuan signifikan pada tren yang muncul bersamaan. Bahasa pemrograman telah berkembang menuju paradigma kode rendah/no-code dan dengan munculnya AI generatif, kita berada pada titik di mana model dasar dapat menghasilkan kode formal berdasarkan deskripsi bahasa alami dari tugas. Hal ini memberikan perspektif baru pada konsep jaringan berbasis maksud (IBN), di mana administrator manusia mengekspresikan tujuan jaringan tingkat tinggi dalam bahasa alami yang dikenal sebagai "maksud" dan bahwa maksud manusia ini secara otomatis diterjemahkan ke dalam kebijakan dan konfigurasi jaringan. IBN memiliki potensi untuk meningkatkan manajemen jaringan dan dapat menjadi terobosan dalam mengatasi kesenjangan talenta di perusahaan telekomunikasi. Mengambil langkah lebih jauh, jaringan otonom (AN) berjanji akan memanfaatkan maksud sebagai input untuk secara otonom mengonfigurasi sendiri, mengoptimalkan sendiri, dan menyembuhkan sendiri jaringan seiring dengan perkembangan kondisinya.

Meskipun kita dapat membayangkan masa depan yang cerah untuk IBN dan AN, masih ada kekhawatiran yang terus berlanjut tentang kelayakan dan aplikasi program mereka termasuk ekspresi maksud, terjemahan yang akurat ke dalam konfigurasi jaringan, transparansi dan kompleksitas sistem, dan lain-lain. Dalam blog ini, kami menyelami berbagai area di mana aplikasi praktis mereka memiliki potensi dan menganalisis tantangan yang mungkin mereka hadapi di sepanjang prosesnya.

Kasus yang memotivasi: memperkenalkan layanan baru tanpa maksud

Untuk memahami kebutuhan merampingkan interaksi antara tim CSP dan jaringan, kami akan menggunakan penerapan layanan baru sebagai contoh.

Kami berasumsi bahwa operasi jaringan CSP diotomatiskan sesuai spesifikasi yang diuraikan dalam Panduan Pengenalan TMF 1230 (IG1230) tentang Arsitektur Teknis Jaringan Otonom. Dalam konteks tersebut, OSS CSP memiliki (1) pengatur untuk penyediaan layanan, penyediaan otomatis, dan pengujian otomatis, (2) sistem jaminan dengan inventaris jaringan yang mengumpulkan data, menciptakan insight tentang status jaringan dan karenanya memfasilitasi pengambilan keputusan berbasis data dalam konteks kontrol siklus tertutup, dan (3) manajer kebijakan yang mengarahkan perilaku jaringan dengan menggunakan kebijakan yang telah ditetapkan, memastikan keselarasan dengan kebijakan CSP yang lebih luas. Singkatnya, operasi otomatis berkisar pada penggabungan layanan yang ketat dengan deskriptor layanan TOSCA yang dirancang manusia, konfigurasi, kebijakan, dan alur kerja imperatif, di mana kecerdasan dan pengambilan keputusan ditambahkan oleh perancang layanan selama waktu desain. Perancang layanan harus secara proaktif memperkirakan berbagai kondisi yang mungkin terjadi dalam jaringan dan memberikan instruksi terperinci tentang bagaimana mereka harus diatasi—pengalaman tanpa sentuhan dapat dicapai selama kondisi masa depan telah diperkirakan dan ada kebijakan untuk menanganinya.

Kami menggunakan istilah Hari ke-0, Hari ke-1, dan Hari ke-2 untuk tahapan siklus proses layanan yang berbeda, yaitu desain layanan, instantiasi layanan, dan jaminan layanan secara berturut-turut.

  • Desain layanan terdiri dari pengembangan berbagai aset layanan seperti yang digambarkan dalam Gambar 1. Ini adalah tugas tim desain layanan, yang perlu memahami operasi Hari 1 dan Hari 2 dari layanan dan menghasilkan alur kerja dan skrip yang diperlukan. Garis merah dalam Gambar 2 menggambarkan proses penyediaan layanan untuk layanan baru, memastikan bahwa layanan tersebut sekarang dapat dipesan.
Proses Desain Layanan Hari ke-0 – Desain Aset Layanan

Gambar 1: Proses Desain Layanan Hari 0 – Desain Aset Layanan

  • Instantiasi layanan terjadi ketika pesanan layanan tiba, mengikuti permintaan pelanggan. Hari ini di CSP pesanan layanan biasanya tiba melalui antarmuka TMF 641 dari manajer pesanan layanan (SOM). Ketika menerima pesanan layanan, pengatur layanan memastikan bahwa alur kerja dijalankan dan bahwa konfigurasi pemantauan yang diminta, model, dan kebijakan PM/FM diterapkan dan dijalankan. Kami menunjukkan instantiasi layanan dalam Gambar 2 dengan garis hijau.
  • Jaminan layanan mengikuti pendekatan loop tertutup di mana kondisi layanan yang diterapkan menjalani pemantauan berkelanjutan dan tindakan siklus hidup otomatis. Kami menunjukkan loop tertutup jaminan pada Gambar 2 dalam garis biru.
Interaksi Hari ke-0/Hari ke-1/Hari ke-2

Gambar 2: Interaksi Hari ke-0/Hari ke-1/Hari ke-2

Singkatnya, ini adalah fase desain yang melibatkan sejumlah besar pekerjaan manual, karena perlu melengkapi jaringan dengan instruksi untuk layanan baru.

Apa itu maksud?

Dalam IBN, maksud mengacu pada tujuan tingkat tinggi yang ingin dicapai CSP dalam jaringannya. Alih-alih berurusan dengan konfigurasi jaringan tingkat rendah yang kompleks selama operasi Hari ke-0 seperti yang dibahas di atas, tim teknik mengekspresikan tujuan dengan maksud dan logika yang mendasari maksud, menerjemahkannya ke dalam konfigurasi jaringan yang diperlukan yang memenuhi tujuan maksud.

Setelah aplikasi konfigurasi ke jaringan, AN kemudian terus memantau layanan yang diterapkan dan menyesuaikan konfigurasi untuk memastikan bahwa operasi tetap selaras dengan maksud yang ditentukan. AN memperluas penggunaan maksud ke dalam operasi Hari ke-2.

Perspektif IBN dan AN

Selanjutnya, kami memberikan beberapa aspek di mana maksud berpotensi merombak praktik yang sudah mapan dari era sebelum maksud:

  • Operasi Hari 0:
    • Persiapan untuk layanan baru – Memanfaatkan AI generatif untuk memproses input bahasa alami untuk melengkapi persyaratan layanan secara mandiri.
    • Pengenalan layanan baru – Menentukan layanan baru menggunakan bahasa alami, seperti "memberikan solusi konektivitas yang disesuaikan untuk komunikasi yang aman di dalam institusi layanan kesehatan" atau "mengaktifkan komunikasi perangkat IoT di seluruh infrastruktur kota pintar", dan memanfaatkan AI generatif untuk menghasilkan aset layanan yang diperlukan secara otomatis.
    • Pembuatan otomatis pendorong sumber daya khusus vendor ­– Memanfaatkan AI generatif untuk membuat pendorong sumber daya khusus vendor, berdasarkan dokumentasi vendor.
  • Operasi Hari ke-1:
    • Penyederhanaan pesanan layanan – Memungkinkan pelanggan untuk meminta layanan menggunakan bahasa alami. Pendekatan yang mudah digunakan ini memungkinkan pengalaman pemesanan layanan yang baru, seperti memadupadankan penawaran dari katalog.
    • Pemeriksaan kelayakan – Merampingkan pemeriksaan validasi saat pelanggan mengekspresikan maksud mereka dengan menilai faktor-faktor penting seperti ketersediaan jalur optik serat secara efisien. Hasilnya adalah berkurangnya beban Insinyur Jaringan, validasi layanan yang lebih cepat dan tangkas, dan penerapan yang responsif.
  • Operasi Hari ke-2:
    • Jaminan layanan dinamis – Memungkinkan jaringan merespons perubahan kondisi dan kebutuhan pengguna secara cerdas. Kebijakan berbasis maksud yang fleksibel meningkatkan ketangkasan, memastikan keandalan dan daya tanggap layanan jaringan secara real-time.

Tantangan dengan IBN dan AN

Ada dua tantangan utama yang harus diatasi:

  1. Bagaimana cara mengekspresikan dan menyampaikan maksud?
  2. Bagaimana mengeksekusi niat: seperti apa penangan maksud terlihat?

TM Forum memperkenalkan API Jaringan berbasis Maksud TMF921, yang menawarkan kerangka kerja terstruktur untuk mendefinisikan maksud jaringan tingkat tinggi. TM Forum mendefinisikan maksud sebagai berikut: "Maksud adalah spesifikasi formal dari semua ekspektasi termasuk persyaratan, tujuan, dan batasan yang diberikan kepada sistem teknis". Namun, spesifikasi formal bagian ini menimbulkan kekhawatiran: teknisi jaringan perlu membiasakan diri dengan bahasa formal ini untuk memanfaatkan potensi penuh dari konsep maksud. Terlebih lagi, maksud dengan spesifikasi formal tidak serta-merta mengurangi jumlah parameter yang harus disediakan. Aspek ini menantang perampingan manajemen jaringan yang diantisipasi yang biasanya dikaitkan dengan IBN.

Lebih jauh lagi, dengan menstandarkan spesifikasi maksud, penangan maksud, komponen inti IBN yang memegang logika untuk interpretasi maksud, menjadi sekadar penerjemah deterministik dari bahasa formal maksud. Pertanyaannya adalah bagaimana kita mengembangkan penangan maksud menjadi sistem otonom dengan cara operasi deklaratif di mana manusia tidak perlu mengantisipasi setiap kondisi jaringan yang potensial dan memberikan instruksi khusus untuk penyelesaiannya. Jika tidak, operasi sistem tidak dapat berhasil beralih dari otomatis ke otonom (TMF IG1230).

Dalam blog mendatang kami akan membahas tantangan dan peluang IBN dan AN secara lebih terperinci. Ingin mempelajari selengkapnya?

 

Penulis

Maja Curic

Telco Network Cloud Architect at IBM

Chris van Maastricht

Associate Partner & Industry Expert - Network & OSS Transformation

IBM Consulting

Thomas Tattis

VP and Senior Partner Global Telco & Media Industry CoE IBM Consulting

IBM Consulting