İletişim

Okuma: ~4 dk

Cloud Wi-Fi Yönetimi, Ücretsiz Controller ve Enterprise WLAN Controller Aynı Şey mi?

Her üretici 'cloud managed' diyor; ama cloud'da bir arayüz bulunması cloud zekası anlamına gelmiyor. Provisioning'den kapalı döngü AIOps'a beş seviyeli modelle platformları ayırıyoruz.

  • Teknik inceleme bekliyor
  • F2 mühendislik yorumu
  • Son doğrulama: Ekim 2026

Piyasanın en büyük kavram karmaşası

Bugün neredeyse her Wi-Fi üreticisi ürününü 'cloud managed' olarak pazarlıyor. Bu ifade doğrudur ama çok az şey anlatır. Bir web arayüzünden SSID ve şifre dağıtmak da cloud yönetimdir, binlerce AP'den toplanan telemetriyle RF planını sürekli yeniden hesaplamak da. İkisi arasındaki fark, sahada yaşanan deneyim açısından devasa olabilir.

Aynı karmaşa 'controller' kelimesinde de vardır. Controller, ekranda SSID şablonu dağıtan bir yazılım değildir. Gerçek bir WLAN controller, ister donanım kutusu ister sanal makine ister cloud servisi olsun, ağın davranışını gözlemleyen ve değiştiren bir kontrol düzlemidir. Bu yazıda platformları teslim şekline göre değil, yaptıkları işe göre sınıflandırıyoruz.

F2 Wireless Platform Maturity Model

F2 mühendislik yorumu

Aşağıdaki beş aşamalı model F2'nin eğitim amaçlı geliştirdiği bir çerçevedir; IEEE veya başka bir kuruluşun standardı değildir. Markaları tek bir "seviye 2 / seviye 5" numarasıyla sıralamak için kullanılmamalıdır: aynı platform bir yetenekte ileri, başka bir yetenekte sınırlı olabilir. Doğru kullanım, yetenek yetenek değerlendirmektir.

Birinci seviye provisioning cloud'dur: SSID, şifre, VLAN, firmware, AP yeniden başlatma ve şablon. Temelde bir konfigürasyon dağıtım sistemidir. İkinci seviye izleme cloud'udur: istemci sayısı, RSSI, trafik, kanal kullanımı ve alarmlar eklenir; artık ağın ne yaptığını görebilirsiniz ama platform buna müdahale etmez.

Üçüncü seviye ağ kontrolüdür. Platform veri toplar ve ağın davranışını değiştirir: kanal, Tx gücü, bant, kanal genişliği, yük dengeleme ve istemci yönlendirme kararları verir. Dördüncü seviye assurance'tır. Platform 'AP çalışmıyor' demek yerine 'Bu kullanıcı neden kötü Wi-Fi deneyimi yaşıyor?' sorusunu cevaplamaya çalışır; kimlik doğrulama, ilişkilendirme, DHCP, DNS, RF, roaming ve throughput aşamalarını ilişkilendirir.

Beşinci seviye AIOps ve kapalı döngü optimizasyondur. İdeal yapı algıla, anla, karar ver, uygula ve doğrula döngüsünü sürekli çalıştırır. Son adım, yani yapılan değişikliğin gerçekten iyileşme sağladığını doğrulamak, platformların en çok ayrıştığı yerdir.

F2 Wireless Platform Maturity Model (F2 çerçevesi)
  • 1 · ProvisioningSSID, VLAN, firmware, şablon dağıtımı
  • 2 · İzlemeİstemci, RSSI, trafik, kanal kullanımı, alarm
  • 3 · Ağ kontrolüKanal, güç, bant, genişlik, steering kararı
  • 4 · AssuranceAAA/DHCP/DNS/RF/roaming korelasyonu
  • 5 · AIOpsAlgıla → anla → karar ver → uygula → doğrula

Kapalı döngü: asıl fark burada

Gelişmiş platformların ortak noktası, AP'lerden sürekli RF telemetrisi toplayıp bunu karar mekanizmasına beslemeleridir. Cisco Meraki AutoRF, AP'lerden topladığı RF verisiyle kanal ve güç kararları verir; güncel AI-RRM yaklaşımı tarihsel RF verisini de karar modeline dahil eder. Juniper Mist, AP'lerdeki ayrı tarama radyolarından kapasite, girişim ve kullanım verisi toplayarak RRM kararlarını bu telemetri üzerinden oluşturur.

HPE Aruba tarafında AirMatch, AP telemetrisini kullanarak kanal, güç ve kanal genişliği planı üretir; Central platformu istemci ve AP sorunlarına yönelik içgörüler sağlayabilir. RUCKUS'ta AI destekli RRM, RF girişimini değerlendirip konfigürasyon değişiklikleri önerir; RUCKUS One ise assurance ve AIOps katmanını sağlar. Bu örneklerin ayrıntıları ve sürüm kapsamları üreticiden üreticiye ve lisans seviyesine göre değişir; tasarım öncesinde güncel üretici belgeleriyle doğrulanmalıdır.

Kapalı döngü optimizasyon
  1. 1 Algıla

    AP, istemci ve spektrum telemetrisi

  2. 2 Anla

    Baseline ile karşılaştırma, anomali tespiti

  3. 3 Karar ver

    Kanal, güç, genişlik, steering

  4. 4 Uygula

    Kontrollü ve izlenebilir değişiklik

  5. 5 Doğrula

    Deneyim gerçekten iyileşti mi?

Cloud, Controller ve Data Plane Aynı Şey Değildir

"Cloud yönetimli" ve "controller tabanlı" ifadeleri çoğu zaman üç ayrı katmanı birbirine karıştırır. Yönetim düzlemi (management plane) yapılandırmanın, izlemenin ve yönetimin yapıldığı yerdir. Kontrol düzlemi (control plane) RF, politika, mobilite ve ağ kararlarının verildiği yerdir. Veri düzlemi (data plane) ise istemci trafiğinin gerçekten aktığı yoldur.

Bu üç düzlem farklı yerlerde çalışabilir. Bir platformun yönetimi bulutta, RF kararları kısmen AP'de, istemci trafiği ise AP'de yerel olarak anahtarlanıyor olabilir. Başka bir mimaride tüm trafik merkezi bir controller'a tünellenir. Bu yüzden bulut bağlantısı kesildiğinde Wi-Fi'ın durup durmayacağı sorusunun tek bir cevabı yoktur: mevcut istemcilerin devam edip etmeyeceği, yeni istemcilerin kimlik doğrulayıp doğrulayamayacağı, roaming'in, yerel anahtarlamanın, merkezi tünelin, RADIUS'un, captive portalın, politika uygulamasının, RF optimizasyonunun ve telemetrinin ne olacağı mimariye bağlıdır.

Üç düzlem ve bulut bağlantısı

Yönetim düzlemiÇalışmaya devam eder*Konfigürasyon, izleme, raporlama · Bulut / controller arayüzü
Kontrol düzlemiÇalışmaya devam eder*RF, politika, mobilite kararları · Controller, bulut veya AP
Veri düzlemiÇalışmaya devam eder*İstemci trafiğinin aktığı yol · AP'de yerel anahtarlama veya merkezi tünel

* Yerel veri düzlemi olan mimarilerde. Merkezi tünelleme yapan mimaride veri düzlemi, tünelin bittiği controller'a bağlıdır. Kavramsal gösterimdir.

Cloud kesintisi ≠ WLAN kesintisi

Aşağıdaki tablo üç örnek mimaride hangi işlevlerin genellikle sürdüğünü ve hangilerinin zayıfladığını gösterir. Bulutta barındırılan captive portal veya bulut üzerinden yapılan RADIUS proxy gibi özellikler bu davranışı değiştirir.

Cloud yönetim bağlantısının kesilmesi, Wi-Fi'ın mutlaka durduğu anlamına gelmez.

İşlevYerel anahtarlama (local forwarding)Merkezi tünelleme (controller)Bulut yönetimli, yerel veri düzlemi
Mevcut istemcilerDevam ederController ayaktaysa devam (bulut bağlantısından bağımsız)Devam eder
Yeni PSK bağlantısıDevam ederController ayaktaysa devam (bulut bağlantısından bağımsız)Devam eder
Yeni 802.1X (RADIUS)RADIUS erişilebilirse devamController ayaktaysa devam (bulut bağlantısından bağımsız)RADIUS erişilebilirse devam
RoamingMimariye/özelliğe bağlıController ayaktaysa devam (bulut bağlantısından bağımsız)Mimariye/özelliğe bağlı
Captive portalMimariye/özelliğe bağlıController ayaktaysa devam (bulut bağlantısından bağımsız)Mimariye/özelliğe bağlı
Politika uygulamaDevam ederController ayaktaysa devam (bulut bağlantısından bağımsız)Devam eder
RF optimizasyonuYeni karar alınamazController ayaktaysa devam (bulut bağlantısından bağımsız)Yeni karar alınamaz
TelemetriTamponlanır / kaybolabilirController ayaktaysa devam (bulut bağlantısından bağımsız)Tamponlanır / kaybolabilir

Örnek mimariler; gerçek davranış üreticiye, yazılım sürümüne ve özelliğin (ör. bulutta barındırılan portal veya RADIUS proxy) nerede çalıştığına bağlıdır.

Ücretsiz platformlara haksızlık etmeyelim

'Ücretsiz eşittir basit' diye bir kural yoktur. Örneğin Reyee Cloud bugün yapay zeka destekli ısı haritası, otomatik teşhis, ağ sağlığı ve senaryo tabanlı kurulum gibi yetenekler sunuyor. UniFi ve Omada gibi platformlar da her sürümde yeni izleme ve optimizasyon özellikleri ekliyor. Dolayısıyla karşılaştırmayı ücretsiz ve ücretli olarak yapmak yanıltıcıdır.

Doğru soru ücretsiz mi ücretli mi değil, şudur: Platform hangi veriyi topluyor, hangi kararları verebiliyor ve ağ davranışını ne kadar derinlemesine açıklayabiliyor? Aşağıdaki matris markasız bir kavram tablosudur; her ürünü bu sorularla kendi sahanızda sınamanızı öneririz.

Platform yetenek matrisi (markasız, örnek)
BoyutŞablon cloudGelişmiş controllerEnterprise cloud/AIOps
Konfigürasyon dağıtımıEvetEvetEvet
TelemetriTemelEvetKapsamlı
RF planlamaOtomatik kanal/güçAğ geneli RRMRRM + tarihsel veri
Tarihsel baselineSınırlıDeğişirEvet
İstemci yolculuğuSınırlıDeğişirEvet
Kimlik doğrulama görünürlüğüSınırlıEvetEvet
DHCP görünürlüğüGenelde hayırDeğişirEvet
DNS görünürlüğüGenelde hayırDeğişirÇoğunlukla
Roaming görünürlüğüSınırlıEvetEvet
Paket düzeyinde hata ayıklamaNadirenEvet (AP/controller yakalama)Değişir
Kök neden analiziGenelde hayırKısmenEvet
Otomatik aksiyonSınırlıDeğişirGiderek artan
DoğrulamaSınırlıDeğişirGiderek artan
APIDeğişirEvetEvet
RBACBasitAyrıntılıAyrıntılı
Denetim iziBasitEvetEvet
Yüksek erişilebilirlikBulut bağımlıAçık HA tasarımıBulut + yerel davranış
Destek eskalasyonuTopluluk/bayiÜretici TACÜretici TAC

Kavram modelini gerçek platformlara eşlemek

Markasız modeli gerçek ürünlere uygularken dikkatli olmak gerekir: aynı platform, lisans seviyesine ve sürüme göre farklı seviyelerde çalışabilir. Aşağıdaki eşleme, platformların tipik konumlandırmasını gösteren genel bir çerçevedir; bir yetenek sıralaması ya da test sonucu değildir.

Platformların tipik konumlandırması (genel çerçeve)
PlatformYönetim modeliÖne çıkan odak
Cisco MerakiBulut yönetimBasit işletim, merkezi görünürlük, çok lokasyon
Juniper Mist (HPE)Bulut + AIOpsİstemci deneyimi ölçümü, yapay zeka destekli teşhis
HPE Aruba CentralBulut / hibritAssurance, politika, kurumsal ölçek
RUCKUS OneBulutRF optimizasyonu, assurance, çok kiracılı yönetim
Cisco Catalyst (RRM)Controller / hibritKapsamlı RRM, politika, büyük kampüs
UniFiYerel / bulut controllerKolay kurulum, geniş ürün ekosistemi
Ruijie Reyee CloudBulutSenaryo tabanlı kurulum, otomatik teşhis
TP-Link OmadaYerel / bulut controllerSMB ve orta ölçek, düşük toplam maliyet
Maipu CloudBulutMerkezi provisioning ve izleme

Son soru: hangi AP değil, hangi mimari?

Bu dört yazılık serinin ortak sonucu tek bir cümlede toplanıyor: 'Hangi AP'yi almalıyım?' değil, 'Hangi Wi-Fi mimarisini işletmem gerekiyor?' AP fiyatı donanım ve yazılım mühendisliğinin toplamıdır; chipset bu zincirin yalnızca bir halkasıdır; SMB ve enterprise ayrımı marka değil işletim modeli farkıdır; controller zekası ise toplanan verinin kalitesi ve bu veriyle verilen kararların doğrulanabilirliğiyle ölçülür.

F2 olarak her üretici karşılaştırmasında aynı yedi katmanlı modeli kullanıyoruz: silikon, RF, anten, firmware, kontrol, zeka ve operasyon. Bu sayede Cisco, HPE Aruba, RUCKUS, Juniper Mist, UniFi, Ruijie, Huawei, Maipu veya Omada arasında veri sayfası tartışması yerine sahaya uygunluk tartışması yapabiliyoruz. Ağınızın hangi seviyede bir platforma ihtiyaç duyduğunu birlikte ölçerek belirleyelim.

F2 Wi-Fi Ürün Mimarisi Modeli (7 katman — F2 çerçevesi, standart değildir)
  • SilikonChipset / SoC / radyo kaynakları
  • RFFront-end, filtreleme, kalibrasyon
  • AntenDesen, izolasyon, yerleşim
  • FirmwareSürücü, scheduler, rate adaptation
  • KontrolController, şablonlar, politika, RRM
  • ZekaAssurance, analitik, AIOps
  • OperasyonHA, TAC, yaşam döngüsü, yönetişim

Dört yazının tek öğrenme akışı

Bu seri birbirine bağlı dört adımdan oluşur. Hangi yazıdan başlarsanız başlayın, akış sizi aynı soruya getirir.

Serinin öğrenme akışı
  1. 1 AP neden pahalı?

    Chipset, RF ön uç, anten, tarama radyosu, CPU/NPU, yazılım ve destek

  2. 2 Chipset önemli mi?

    Referans tasarım ve üreticinin RF mühendisliği

  3. 3 SMB mi enterprise mi?

    Marka değil, işletim modeli farkı

  4. 4 Controller neden önemli?

    Telemetri, RRM, assurance, kapalı döngü

  5. 5 Son soru

    Hangi AP değil, hangi Wi-Fi mimarisi?