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.
- 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.
- 1 Algıla
AP, istemci ve spektrum telemetrisi
- 2 Anla
Baseline ile karşılaştırma, anomali tespiti
- 3 Karar ver
Kanal, güç, genişlik, steering
- 4 Uygula
Kontrollü ve izlenebilir değişiklik
- 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ı
* 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.
| İşlev | Yerel anahtarlama (local forwarding) | Merkezi tünelleme (controller) | Bulut yönetimli, yerel veri düzlemi |
|---|---|---|---|
| Mevcut istemciler | Devam eder | Controller ayaktaysa devam (bulut bağlantısından bağımsız) | Devam eder |
| Yeni PSK bağlantısı | Devam eder | Controller ayaktaysa devam (bulut bağlantısından bağımsız) | Devam eder |
| Yeni 802.1X (RADIUS) | RADIUS erişilebilirse devam | Controller ayaktaysa devam (bulut bağlantısından bağımsız) | RADIUS erişilebilirse devam |
| Roaming | Mimariye/özelliğe bağlı | Controller ayaktaysa devam (bulut bağlantısından bağımsız) | Mimariye/özelliğe bağlı |
| Captive portal | Mimariye/özelliğe bağlı | Controller ayaktaysa devam (bulut bağlantısından bağımsız) | Mimariye/özelliğe bağlı |
| Politika uygulama | Devam eder | Controller ayaktaysa devam (bulut bağlantısından bağımsız) | Devam eder |
| RF optimizasyonu | Yeni karar alınamaz | Controller ayaktaysa devam (bulut bağlantısından bağımsız) | Yeni karar alınamaz |
| Telemetri | Tamponlanır / kaybolabilir | Controller 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.
| Boyut | Şablon cloud | Gelişmiş controller | Enterprise cloud/AIOps |
|---|---|---|---|
| Konfigürasyon dağıtımı | Evet | Evet | Evet |
| Telemetri | Temel | Evet | Kapsamlı |
| RF planlama | Otomatik kanal/güç | Ağ geneli RRM | RRM + tarihsel veri |
| Tarihsel baseline | Sınırlı | Değişir | Evet |
| İstemci yolculuğu | Sınırlı | Değişir | Evet |
| Kimlik doğrulama görünürlüğü | Sınırlı | Evet | Evet |
| DHCP görünürlüğü | Genelde hayır | Değişir | Evet |
| DNS görünürlüğü | Genelde hayır | Değişir | Çoğunlukla |
| Roaming görünürlüğü | Sınırlı | Evet | Evet |
| Paket düzeyinde hata ayıklama | Nadiren | Evet (AP/controller yakalama) | Değişir |
| Kök neden analizi | Genelde hayır | Kısmen | Evet |
| Otomatik aksiyon | Sınırlı | Değişir | Giderek artan |
| Doğrulama | Sınırlı | Değişir | Giderek artan |
| API | Değişir | Evet | Evet |
| RBAC | Basit | Ayrıntılı | Ayrıntılı |
| Denetim izi | Basit | Evet | Evet |
| Yüksek erişilebilirlik | Bulut bağımlı | Açık HA tasarımı | Bulut + yerel davranış |
| Destek eskalasyonu | Topluluk/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.
| Platform | Yönetim modeli | Öne çıkan odak |
|---|---|---|
| Cisco Meraki | Bulut yönetim | Basit 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 Central | Bulut / hibrit | Assurance, politika, kurumsal ölçek |
| RUCKUS One | Bulut | RF optimizasyonu, assurance, çok kiracılı yönetim |
| Cisco Catalyst (RRM) | Controller / hibrit | Kapsamlı RRM, politika, büyük kampüs |
| UniFi | Yerel / bulut controller | Kolay kurulum, geniş ürün ekosistemi |
| Ruijie Reyee Cloud | Bulut | Senaryo tabanlı kurulum, otomatik teşhis |
| TP-Link Omada | Yerel / bulut controller | SMB ve orta ölçek, düşük toplam maliyet |
| Maipu Cloud | Bulut | Merkezi 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.
- 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.
- 1 AP neden pahalı?
Chipset, RF ön uç, anten, tarama radyosu, CPU/NPU, yazılım ve destek
- 2 Chipset önemli mi?
Referans tasarım ve üreticinin RF mühendisliği
- 3 SMB mi enterprise mi?
Marka değil, işletim modeli farkı
- 4 Controller neden önemli?
Telemetri, RRM, assurance, kapalı döngü
- 5 Son soru
Hangi AP değil, hangi Wi-Fi mimarisi?