Saha Notu: iOS Cihazlarının 6 GHz Bant ve BSSID Seçimi

Şikayet: aynı AP'ye bazı iPhone'lar 6 GHz'den, bazıları 5 GHz'den bağlanıyor

Kurumsal bir ofiste Wi-Fi 6E destekleyen aynı AP altyapısına bağlanan farklı iPhone modelleri, aynı masada otururken farklı bantlardan ilişkilendi. Bazı cihazlar 6 GHz BSS'e katılırken komşu masadaki aynı modeldeki cihaz 5 GHz'de kaldı; her ikisi de aynı SSID'yi görüyordu ve sinyal seviyeleri benzerdi. BT ekibi önce AP tarafında bir yapılandırma hatası aradı, ancak aynı AP'ye bağlanan Android cihazların tamamı tutarlı biçimde 6 GHz'i tercih ediyordu. Bu ayraç, sorunu AP yapılandırmasından çok iOS'un bant/BSSID seçim mantığına yöneltti.

İlk adım, etkilenen ve etkilenmeyen cihazların iOS sürümlerini, donanım modellerini ve ‘Özel Wi-Fi Adresi’ (Private Wi-Fi Address) ayarının açık/kapalı durumunu kaydetmek oldu. Sahada iddia edilen sürüm aralığında (örnek olarak bir 17.x alt sürümünde) bazı cihazların 6 GHz'e geçişte daha isteksiz davrandığı gözlemlendi; ancak bu gözlem, üreticinin resmî bir değişiklik notuyla doğrulanmadan kesin bir sürüm kusuru olarak sunulmamalıdır. Önemli olan, sürüm iddiası ne olursa olsun teşhisin AP yapılandırması yerine istemci tarafı keşif ve seçim davranışına odaklanması gerektiğidir.

RNR ve Preferred Scanning Channels'ın rolü

6 GHz ağlarda doğrudan tüm kanalları pasif taramak güç ve zaman açısından verimsiz olduğundan istemciler, 2,4 veya 5 GHz bandındaki beacon'lara eklenen Reduced Neighbor Report (RNR) bilgisini kullanarak aynı ağın 6 GHz BSS'ini keşfeder. Bu alan AP'nin 6 GHz'de hangi kanalda, hangi BSSID ile yayın yaptığını önceden bildirir. iOS cihazların 6 GHz'i görmesi için önce 5 GHz (veya 2,4 GHz) BSS'e bir şekilde maruz kalması ve bu BSS'in RNR'yi doğru taşıması gerekir. Sahada RNR içeriği eksik veya tutarsız yapılandırılmış bir AP profili tespit edildiğinde, bazı istemcilerin 6 GHz'i hiç keşfetmediği, bazılarının ise RNR dışı bağımsız tarama yöntemleriyle yine de bulduğu görüldü; bu da üreticiler arası tarama agresifliğinin farklı olduğunu gösterdi.

Preferred Scanning Channels (PSC) kümesi, 6 GHz'de taramayı hızlandırmak için önerilen alt kanal listesidir. AP'nin PSC dışı bir kanalda yayın yapması, bazı istemcilerin varsayılan tarama davranışında o kanalı atlamasına ve dolayısıyla 6 GHz ağını hiç bulamamasına yol açabilir. Sahada iOS cihazların, PSC dışı kanalda yayın yapan bir 6 GHz BSS'e bağlanma oranının belirgin biçimde düştüğü gözlemlendi; AP kanalı PSC listesine taşındığında bağlanma oranı arttı. Bu nedenle 6 GHz tasarımında kanal seçimini yalnız girişimden kaçınma kriteriyle değil, istemci keşif uyumluluğuyla birlikte yapmak gerekir.

Özel Wi-Fi adresi ve bant/BSSID tercihinin kurumsal etkisi

iOS'un her ağ için ayrı rastgele MAC adresi üretebilen Özel Wi-Fi Adresi özelliği, gizlilik açısından faydalı olsa da kurumsal ortamda iki doğrudan etkisi vardır. Birincisi, MAC tabanlı erişim listeleri veya cihaz tanıma sistemleri, aynı fiziksel cihazı her bağlantıda farklı bir kimlikle görebilir; bu da envanter ve sorun takibini zorlaştırır. İkincisi, bazı yapılandırmalarda özel adresin ağ başına değil periyodik olarak yenilenmesi seçiliyse, aynı cihazın zaman içinde farklı bir ‘yeni istemci’ gibi görünüp roaming geçmişini ve öğrenilmiş bant tercihini sıfırlaması mümkündür. Sahada bu durum, bazı cihazların önceki oturumda 6 GHz'de kalırken yeniden bağlandığında 5 GHz'e düşmesi şeklinde yorumlandı; kök neden MAC adresinin değişmesiyle istemci tarafı geçmişin sıfırlanmasıydı.

Bant/BSSID seçiminde iOS, yalnız anlık sinyal seviyesine değil geçmiş bağlantı deneyimine, tahmini kapasiteye ve aktif roaming eşiklerine birlikte bakar; bu seçim mantığı üretici tarafından ayrıntılı biçimde yayımlanmaz ve sürümler arasında değişebilir. Bu nedenle ‘iOS her zaman 6 GHz'i tercih eder’ gibi kesin bir kural varsaymak hatalıdır. Kurumsal ağ tasarımında güvenli varsayım şudur: 6 GHz bandı sunulsa bile bir kısım istemci büyük ihtimalle 5 GHz'de kalacaktır, dolayısıyla kapasite planlaması yalnız 6 GHz'e yüklenmemeli, 5 GHz hücreleri de yeterli kapasiteyle tasarlanmalıdır. 6 GHz'i ‘herkes otomatik geçecek’ varsayımıyla 5 GHz radyo sayısını azaltmak, 6 GHz'i az tercih eden cihazlar için kapasite açığı yaratır.

Sahada doğrulama ve tasarım önerisi

Doğrulama için önerilen yöntem, etkilenen alanda hem 5 GHz hem 6 GHz beacon'larını ve ilişkilendirme çerçevelerini yakalayıp hangi istemcinin hangi BSSID'e, hangi RNR bilgisiyle, hangi kanaldan bağlandığını satır satır kaydetmektir. Bu kayıt, iOS sürümü ve özel adres ayarıyla eşleştirildiğinde, sorun gerçekten bir istemci davranışı mı yoksa AP tarafı RNR/PSC eksikliği mi olduğu netleşir. Tek bir cihazla yapılan gözlemden genel sonuç çıkarmak yanıltıcıdır; en az birkaç farklı iOS sürümü ve model kombinasyonuyla aynı testin tekrarlanması gerekir. Sürüm bazlı davranış farkları zamanla değişebileceğinden, bulgular üreticinin ilgili sürüm notlarıyla karşılaştırılmalı ve kesin bir ‘şu sürümde şu kusur var’ iddiası resmî kaynak olmadan rapora kesin dille yazılmamalıdır.

F2 yaklaşımında 6 GHz tasarımı yalnız bant açmakla bitmez: AP'lerin RNR ve PSC uyumlu kanal seçimi yapılandırılır, kapasite planlaması 5 GHz'i de güçlü tutacak şekilde yapılır ve kurumsal cihaz yönetiminde özel Wi-Fi adresi politikası (ağ başına sabit mi, periyodik mi) bilinçli olarak seçilir. Sorun raporlarında cihaz modeli, işletim sistemi sürümü, özel adres ayarı, bağlanılan BSSID ve kanal birlikte tutulmalı; bu kayıt olmadan ‘iOS 6 GHz'e bağlanmıyor’ gibi genel ifadeler sahada tekrar teşhis gerektirir. Değişiklik sonrası doğrulama, farklı model ve sürüm kombinasyonlarıyla tekrarlanmalı ve yalnız anlık bağlanma değil, zaman içindeki roaming ve oturum kalıcılığı da izlenmelidir.

• iOS cihazların 6 GHz'i her zaman otomatik tercih ettiğini varsaymayın; 5 GHz kapasitesini buna göre düşürmeyin.
• AP'nin RNR bilgisini ve 6 GHz kanalının PSC listesinde olup olmadığını doğrulayın; eksiklik keşfi doğrudan engelleyebilir.
• Özel Wi-Fi adresi politikasını (ağ başına sabit/periyodik) kurumsal cihaz yönetiminde bilinçli seçin ve etkisini test edin.
• Sorun raporlarında cihaz modeli, iOS sürümü, özel adres ayarı, BSSID ve kanalı birlikte kaydedin.
• Sürüm bazlı davranış iddialarını üreticinin güncel resmî notlarıyla doğrulamadan kesin kusur olarak sunmayın.