Perpustakaan Digital ITB

Implementasi core network pada teknologi 5G Standalone (SA) berbasis Service-Based Architecture (SBA) mengharuskan infrastruktur yang fleksibel. Adopsi arsitektur cloud-native menggunakan container menawarkan fleksibiliras tinggi, namun memiliki trade-off berupa overhead komputasi serta sifat IP container yang dinamis. Tugas Akhir ini bertujuan merancang, mengimplementasikan, dan menganalisis performa end-to-end platform 5G Standalone Testbed berbasis Kubernetes K3s menggunakan Open5GS, dengan deployment secara bare metal sebagai baseline. Metodologi pengujian dilakukan pada infrastruktur multi-node cluster yang melibatkan empat unit PC dibandingkan dengan satu unit PC bare metal dengan total kapasitas CPU yang setara (16 thread). Hasil validasi fungsional menunjukkan seluruh fungsi control plane berhasil terintegrasi melalui proxy Service Communication Proxy (SCP). Pengujian control plane menggunakan HP komersial sukses menyelesaikan prosedur registrasi dan session establishment untuk domain srsapn dan ims. Analisis performa kuantitatif menunjukkan kesesuaian dengan standar 3GPP, di mana download speed mencapai hingga 120,68 Mbps dan upload speed sebesar 59,88 Mbps. Perbedaan kapasitas throughput antara arsitektur K3s dan bare-metal berada pada margin yang sangat tipis dengan nilai latency konstan yang berhasil ditekan di bawah 13 ms pada kedua sistem. Pengujian performa pada arsitektur cloud-native berbasis K3s menunjukkan stabilitas throughput yang konsisten antara pengujian speed test di lingkungan lokal dan publik dengan rata-rata download speed mencapai 120 Mbps dan upload speed 59 Mbps, meskipun terjadi lonjakan latency yang signifikan dari 12,47 ms menjadi 37,32 ms saat terhubung ke jaringan publik akibat faktor eksternal. Lebih lanjut, pengujian auto-scaling menggiring kepada temuan terkait keterbatasan Service LoadBalancer bawaan Kubernetes dalam menginspeksi parameter Tunnel Endpoint Identifier (TEID) pada enkapsulasi GTP-U Layer 4. Sebagai langkah penyelesaian, diterapkan skema workaround dengan mengikat traffic data plane secara langsung menuju Node IP fisik eksternal. Berdasarkan hasil implementasi solusi alternatif tersebut, cluster berhasil melakukan scale-out i dengan CPU detection delay selama 21 detik, stabilization window selama 13 detik, dan HPA Scheduling selama 18 detik, sehingga stabilitas transmisi data plane seluruh user tetap terjaga secara kontinu tanpa mengalami pemutusan session. Evaluasi kapasitas pada arsitektur cloud-native dengan 4 node UPF menunjukkan adanya trade-off performa yang signifikan, di mana skenario 16 UE mampu mencapai throughput puncak sebesar 3108 Mbps namun memicu ketimpangan distribusi akibat saturasi buffer switch fisik, sedangkan skenario 400 UE menghasilkan pembagian workload yang merata antar-pod tetapi kapasitas maksimumnya terdegradasi drastis menjadi hanya 401 Mbps akibat tingginya beban pensinyalan kontrol dan sinkronisasi massal. Selain itu, evaluasi self-healing membuktikan User Plane Function (UPF) mampu pulih dalam waktu 3,2 detik karena bersifat stateless, sementara komponen control plane membutuhkan waktu 32 hingga 33 detik akibat mekanisme termination grace period bawaan Kubernetes.