本檔案將詳細說明無線電資源管理(RRM)的功能和運作,並深入討論此功能背後的演演算法。
思科建議您瞭解以下主題:
輕量型存取點通訊協定(LWAPP)
常見的無線區域網路(WLAN)/射頻(RF)設計考量(知識與Planet 3無線CWNA認證相當)
注意:客戶端主動負載均衡和惡意檢測/遏制(及其他Cisco入侵檢測系統[IDS]/Cisco IOS®入侵防禦系統[IPS]功能)不屬於RRM的功能,並且不在本文檔的討論範圍之內。
本文件所述內容不限於特定軟體和硬體版本。
如需文件慣例的詳細資訊,請參閱思科技術提示慣例。
在CLI中,檢查:
show advanced [802.11b|802.11a] txpower
新的預設值為-70dbm。如果已經過修改,請回覆成預設值,因為這個新值已顯示在一定條件下是最佳的。RF組中所有控制器的該值必須相同。請記得在進行更改後儲存配置。
若要變更此值,請發出以下命令:
config advanced [802.11b|802.11a] tx-power-control-thresh 70
在CLI中,檢查:
show advanced [802.11a|802.11b] profile global
結果應為:
802.11b Global coverage threshold.............. 12 dB for 802.11b 802.11a Global coverage threshold.............. 16 dB for 802.11a
如果結果不同,則使用以下命令:
config advanced 802.11b profile coverage global 12 config advanced 802.11a profile coverage global 16
客戶端SNR截止引數,用於確定客戶端是否違規,以及如果Coverage Hole演算法的緩解啟動,則應將名為Coverage的恢復為預設值以獲得最佳結果。
在CLI中,檢查:
show load-balancing
當前負載均衡的預設狀態為Disabled。如果啟用,預設視窗現在是5。這是在進行關聯時的負載均衡之前,需要與無線電關聯的客戶端數量。負載均衡在高密度客戶端環境中非常有用,而且必須讓管理員決定該功能的使用,以便瞭解客戶端關聯和分配行為。
秘訣:
確保共用RF組名稱的所有控制器上的Tx功率閾值配置相同。
在低於4.1.185.0的版本中,預設Tx功率閾值為-65dBM,但對於大多數部署而言,此閾值-65dBm可能太「熱」。將此閾值設定為-68dBm到-75dBm時,觀察到更好的結果。對於版本4.1.185.0,預設Tx功率閾值現在為-70dBm。在4.1.185.0或更高版本中,強烈建議使用者將Tx功率閾值更改為-70,並驗證結果是否令人滿意。這是一個強烈的建議,因為各種RRM增強功能現在可能導致您的當前設定不理想。
原因:
RF組名稱是每個無線LAN控制器(WLC)配置的ASCII字串。分組演算法將選擇RF組領導者,RF組領導者將依次計算整個RF組的發射功率控制(TPC)和動態通道分配(DCA)。例外是涵蓋範圍空洞演演算法(CHA),它每WLC執行。由於RF分組是動態的,並且演算法預設以600秒的間隔運行,因此可能存在偵聽新鄰居(或不再偵聽現有鄰居)的例項。這會導致RF組發生更改,從而可能導致選擇新的領導者(針對一個或多個邏輯RF組)。在這種情況下,TPC演算法中使用新組領導的Tx功率閾值。如果共用同一RF組名的多個控制器之間此閾值的值不一致,則這會導致TPC運行時所產生的Tx功率水準不一致。
提示:
將大多數部署的覆蓋範圍度量(預設為12dB)設定為3dB。
注意:對於版本4.1.185.0,Tx加電控制以及使用者可配置的SNR配置檔案違反閾值客戶端數等增強功能,802.11b/g的預設值為12dB,802.11a的預設值為16dB。
原因:
預設情況下,覆蓋範圍測量為12 dB,用於達到每個客戶端的最大可接受SNR。如果客戶端SNR超過此值,並且即使有一個客戶端超過此值,CHA將由其存取點(AP)檢測到SNR差的客戶端的WLC觸發。如果存在傳統客戶端(這些客戶端的漫遊邏輯通常較差),將可容忍的噪音下限調整為3dB結果可提供短期修復(4.1.185.0或更高版本中不需要此修復)。
此問題在覆蓋空洞檢測與消除演算法部分的粘滯客戶端通電注意事項中進行了詳細說明。
秘訣:
傳送鄰居消息之間配置的間隔越長,整個系統的收斂/穩定時間就越慢。
如果20分鐘內未偵聽現有鄰居,則該AP將從鄰居清單中刪除。
注意:對於版本4.1.185.0,現在會延長鄰居清單修剪間隔,以使在最多60分鐘內未收到鄰居資料包的鄰居繼續存在。
原因:
預設情況下,每60秒傳送一次鄰居消息。此頻率由Auto RF頁上Monitor Intervals部分下的Signal Measurement(在4.1.185.0及更高版本中稱為Neighbor Packet Frequency)控制(請參閱圖15以獲取參考)。必須瞭解鄰居消息會傳達AP偵聽的鄰居清單,然後這些鄰居將傳達到其各自的WLC,而這些WLC又形成RF組(這假設RF組名稱配置相同)。RF收斂時間完全取決於鄰居消息的頻率,必須適在地設定此引數。
提示:
使用On-Demand按鈕進行更精細的控制和確定性RRM行為。
注意:在版本4.1.185.0中,可以使用DCA的錨點時間、間隔和靈敏度配置來實現可預測性。
原因:
對於希望對整個系統的演算法更改進行可預測性的使用者,RRM可以在按需模式下運行。使用時,RRM演演算法會計算在接下來的600秒間隔要套用的最佳通道和電源設定。然後,演算法將休眠,直到下一次使用按需選項;系統處於凍結狀態。有關詳細資訊,請參閱圖11和圖12以及各自的說明。
提示:
負載平衡的預設設定為ON,負載平衡窗口設定為0。此窗口應更改為更高的數字,例如10或12。
注意:在4.1.185.0及更新版本中,負載平衡的預設設定是「關閉」,如果啟用,則視窗大小預設為5。
原因:
雖然與RRM無關,但主動負載均衡可能導致漫遊邏輯差的舊客戶端漫遊結果欠佳,從而使其成為粘滯客戶端。這會對CHA產生不良影響。WLC上的預設負載平衡窗口設定為0,這不是一件好事。這被解釋為負載均衡機制啟動之前應該在AP上的最小客戶端數量。內部研究和觀察已表明應將此預設值更改為更實用的值,例如10或12。當然,每個部署都有不同的需求,因此應適在地設定窗口。以下是指令行語法:
(WLC) >config load-balancing window ? <client count> Number of clients (0 to 20)
在密集的生產網路中,控制器已經過驗證,在負載均衡為ON且窗口大小設定為10的情況下,控制器可以最佳運行。在實踐中,這意味著負載均衡行為僅在以下情況下啟用:一大群人聚集在會議室或開放區域(會議或課程)中。在這種方案中,負載均衡非常有助於將這些使用者分佈在各種可用的AP之間。
注意:使用者絕不會「丟棄」無線網路。負載均衡僅在關聯時發生,系統將嘗試鼓勵客戶端使用負載更輕的AP。如果客戶端是永久性的,則允許它加入,並且不會擱置。
隨著WLAN技術採用率的顯著提高,部署問題也隨之增加。802.11規範最初的設計主要是考慮到家庭的單蜂窩使用。考慮單個AP的通道和功率設定是一個小動作,但隨著無處不在的WLAN覆蓋成為使用者期望之一,確定每個AP的設定需要進行全面的站點調查。由於802.11的頻寬具有共用性,現在透過無線網段運行的應用正在推動客戶轉向更注重容量的部署。增加無線區域網路的容量與有線網路不同之處在於,有線網路的常見做法是藉由頻寬來解決問題。需要額外的AP才能增加容量,但如果配置不正確,實際上由於干擾和其他因素而可能會降低系統容量。隨著大規模、高密度的WLAN成為常態,管理員不斷面臨這些可能增加運營成本的射頻配置問題。如果處理不當,則可能導致WLAN不穩定和終端使用者體驗不佳。
由於頻譜有限(非重疊通道的數量有限),並且由於RF天生希望透過牆壁和地板進行滲透,因此設計任何規模的WLAN一直都是一項艱鉅的任務。即使進行完美的現場勘測,射頻也千變萬化。某個時刻,最佳的AP通道和功率方案可能會被證明無法正常工作。
輸入Cisco的RRM。RRM允許思科的統一WLAN架構持續分析現有RF環境,自動調整AP的功率水準和通道配置,以幫助緩解共通道干擾和訊號覆蓋問題等情況。RRM減少了執行全面站點勘察的需要,提高了系統容量,並提供了自動自我修復功能以彌補RF死區和AP故障。
讀者應完全理解本文檔中使用的以下術語:
訊號:任何機載射頻能量。
dBm:RF訊號強度的絕對對數數學表示。dBm與毫瓦直接相關,但通常用於以無線網路中常見的極低值來表示輸出功率。例如,-60 dBm的值等於0.000001毫瓦特。
接收訊號強度指示器(RSSI):訊號強度的絕對數字度量。並非所有802.11無線電都報告RSSI相同,但在本文檔中,假設RSSI與接收訊號直接相關,如dBm所示。
雜訊:任何無法解碼為802.11訊號的訊號。這可能來自非802.11源(例如微波或藍芽裝置)或訊號因衝突或其他訊號延遲而失效的802.11源。
背景雜訊:接收訊號難以理解的現有訊號水準(用dBm表示)。
SNR:訊號強度與背景雜訊之比。此值為相對值,因此以分貝(dB)表示。
干擾:同一頻段中不需要的射頻訊號,可能導致服務降級或丟失。這些訊號可以來自802.11或非802.11源。
在詳細瞭解RRM演算法如何工作之前,首先必須瞭解RRM系統如何合作形成RF分組的基本工作流程,並瞭解何處進行RF計算。下面概述了Cisco統一解決方案在學習、分組和計算所有RRM功能方面執行的步驟:
控制器(其AP需要將RF配置計算為單個組)使用相同的RF組名稱進行調配。RF組名稱是每個AP將用來確定它們聽到的其他AP是否屬於同一系統的ASCII字串。
AP定期傳送鄰居消息,共用有關自己、其控制器及其RF組名稱的資訊。然後,這些鄰居消息可以由共用相同RF組名的其他AP進行身份驗證。
可以聽到這些鄰居消息並根據共用RF組名對其進行身份驗證的AP,將此資訊(主要包括控制器IP地址以及傳輸鄰居消息的AP資訊)傳遞到它們所連線的控制器。
控制器現在瞭解哪些其他控制器將成為RF組的一部分,然後形成一個邏輯組以共用此RF資訊,並隨後選擇一個組領導。
RF組領導中會運行一系列旨在最佳化AP配置的RRM演算法(覆蓋空洞檢測與糾正演算法除外,此演算法在AP本地的控制器上運行),這些演算法可提供RF組中每個AP的RF環境的詳細資訊:
DCA
TPC
註:RRM(和RF分組)與控制器間移動性(和移動性分組)是分開的功能。唯一的相似之處是在初始控制器配置嚮導期間,使用分配給兩個組名稱的通用ASCII字串。這是為了簡化設定程式而完成的,稍後可以變更。
注意:多個邏輯RF組存在是正常的。只有在AP可以聽到來自另一個控制器的另一個AP時,指定控制器上的AP才能幫助將其控制器與另一個控制器連線。在大型環境和大學校園中,多個射頻組存在是正常的,這些射頻組橫跨小型建築群,但並不橫跨整個域。
以下是這些步驟的圖形表示:
圖1:來自AP的鄰居消息為WLC提供全系統的RF檢視,以便進行通道和功率調整。表1:功能細分參考
功能 | 執行時間/執行者: |
---|---|
RF分組 | WLC選舉組領導 |
動態通道分配 | 群組領導者 |
傳輸功率控制 | 群組領導者 |
覆蓋空洞檢測與糾正 | WLC |
RF組是控制器的群集,不僅共用相同的RF組名稱,而且其AP相互偵聽。
AP邏輯配置,以及控制器RF分組,由AP接收其他AP的鄰居消息來確定。這些消息包括有關傳送AP及其WLC的資訊(以及其他在表1中詳細介紹的資訊),並透過雜湊進行身份驗證。
表2:「鄰居消息」包含一些資訊元素,使接收控制器瞭解傳送AP及其連線的控制器。欄位名稱 | 說明 |
---|---|
無線電識別符號 | 具有多個無線電的AP使用此資訊來標識哪個無線電正在用於傳輸鄰居消息 |
群組ID | WLC的計數器和MAC地址 |
WLC IP地址 | 射頻組長的管理IP地址 |
AP的通道 | AP服務客戶端的本地通道 |
鄰居消息通道 | 傳輸鄰居資料包的通道 |
強化 | 目前未使用 |
天線模式 | 目前未使用 |
當AP收到鄰居消息(每60秒在所有服務通道上以最大功率和最低支援的資料速率傳送)時,它會將該幀傳送到其WLC,透過驗證嵌入式雜湊確定AP是否屬於同一RF組。傳送無法解密的鄰居消息(表示正在使用外部RF組名)或根本不傳送鄰居消息的AP被確定為非法AP。
圖2:每60秒將鄰居消息傳送到組播地址01:0B:85:00:00:00。
假設所有控制器共用相同的RF組名稱,為了形成RF組,WLC只需要一個AP偵聽另一個WLC的一個AP(有關詳細資訊,請參見圖3至圖8)。
圖3:AP傳送和接收鄰居消息,然後這些鄰居消息轉發到其控制器以形成RF組。
接收AP及其WLC會使用鄰居消息來確定如何建立WLC間RF組,以及建立邏輯RF子組,這些RF子組僅包括能夠聽到彼此消息的AP。這些邏輯RF子組的RRM配置是在RF組領導處完成的,但由於它們沒有RF子組之間的無線連線,因此彼此獨立(請參見圖4和圖5)。
圖4:所有AP在邏輯上連線到單個WLC,但形成兩個單獨的邏輯RF子組,因為AP 1、2和3無法聽到來自AP 4、5和6的鄰居消息,反之亦然。圖5:同一邏輯RF子組中的AP可以共用單個WLC,每個都位於單獨的WLC上,或者位於混合的WLC上。RRM功能在全系統級別執行,只要AP可以聽到彼此的聲音,其控制器將自動分組。在本示例中,WLC A和B位於同一個RF組中,而它們的AP位於兩個不同的邏輯RF子組中。
在擁有許多WLC和許多AP的環境中,並非所有AP都需要相互偵聽才能使整個系統形成單個RF組。每個控制器必須至少有一個AP偵聽來自任何其他WLC的另一個AP。因此,RF分組可以跨多個控制器進行,而不管每個控制器對相鄰AP以及WLC的本地檢視(請參見圖6)。
圖6:在本示例中,連線到WLC A和C的AP無法聽到彼此的鄰居消息。WLC B可以偵聽WLC A和C,然後與它們共用對方的資訊以便形成單個RF組。為可以相互傳送鄰居消息的每組AP建立獨立的邏輯RF子組。
在多個控制器配置了相同的RF組名稱,但各自的AP無法聽到彼此的鄰居消息的情況下,會形成兩個獨立的(頂級)RF組,如圖7所示。
圖7:雖然WLC共用相同的RF組名,但其AP無法相互偵聽,因此形成了兩個獨立的RF組。
RF分組發生在控制器級別,這意味著,一旦AP將所聽到的其他AP(以及這些AP所連線的控制器)的資訊報告給其控制器,則每個WLC將直接與其他WLC通訊以形成全系統分組。在單個系統範圍組或RF組中,許多AP子集的RF引數會彼此分開設定:考慮一個中央WLC,其中遠端站點有單獨的AP。因此,每個AP會與其他無線存取點分開設定其RF引數,因此當每個AP屬於同一個控制器RF分組時,每個單獨的AP(在本例中)將處於自己的邏輯RF子組中(參見圖8)。
圖8:每個AP的RF引數與其他無線存取點分開設定,因為它們無法聽到彼此的鄰居消息。
每個AP編譯並維護一個最多包含34個鄰接AP(每個無線電)的清單,然後報告給其各自的控制器。每個WLC都會維護一個清單,其中每個AP從每個AP傳送的鄰居消息中接收每個AP無線電24個鄰居。在控制器層級之後,會修剪此每個AP、每個無線電鄰居清單,其中最多可包含34個AP,這會丟棄訊號最弱的10個AP。然後,WLC將每個AP鄰居清單轉發到RF組領導者(由RF組選擇的WLC)以執行所有RRM配置決策。
這裡必須注意,RF分組對每個無線電型別都有作用。分組演算法分別針對802.11a和802.11b/g無線電運行,這意味著它針對每個AP、每個無線電運行,因此每個AP無線電負責填充鄰居清單。為了限制抖動,從而可能經常在此清單中增加和修剪AP,WLC會將鄰居增加到其清單中,因為偵聽的頻率大於或等於-80 dBm,並且僅當其訊號降至-85 dBm以下時才將其刪除。
註:使用無線區域網控制器軟體版本4.2.99.0或更高版本,RRM最多支援一個RF組中的20個控制器和1000個存取點。例如,一個Cisco WiSM控制器支援最多150個存取點,因此一個RF組中最多可以有6個WiSM控制器(150個存取點乘以6個控制器= 900個存取點,少於1000個)。同樣,4404控制器支援多達100個存取點,因此一個RF組中最多可以有10個4404控制器(100乘以10 = 1000)。基於2100系列的控制器最多支援25個存取點,因此一個RF組中最多可以有20個此類控制器。此AP的1000限制不是與控制器相關聯的AP的實際數量,而是根據該特定控制器型號可支援的AP最大數量進行計算。例如,如果有8個WiSM控制器(4個WiSM),每個控制器有70個AP,則實際AP數為560。但是,演算法計算為8*150= 1200(150是每個WiSM控制器支援的最大AP數)。因此,將控制器分成兩組。一個群組有6個控制器,另一個群組有2個控制器。
由於充當RF組領導者的控制器執行兩者,即DCA演算法和TPC演算法,因此當另一個控制器上的AP預計會偵聽其鄰居消息時,必須為控制器配置RF組名稱。如果AP(位於不同控制器上)在地理位置上相隔,則至少在-80dBm或更好的範圍內無法聽到來自它們的鄰居消息,則將其控制器配置為RF組是不切實際的。
如果達到RF分組演算法的上限,組領導控制器將不允許任何新控制器或AP加入現有組或參與通道和功率計算。系統會將這種情況視為新的邏輯RF子組,並將新成員增加到使用相同組名配置的此新邏輯組中。如果環境恰好是動態的,在射頻波動的本質上,鄰居的觀察方式會定期改變,那麼組成員改變和後續組長選舉的可能性就會增加。
RF組領導者是RF組中選定的控制器,負責按邏輯RF組分析AP的RF資料,並負責配置AP的功率電平和通道設定。覆蓋空洞檢測與糾正基於客戶端的SNR,因此是在每個本地控制器上執行的唯一RRM功能。
每個控制器基於每個鄰居消息中的組識別符號資訊元素確定哪個WLC具有最高組領導優先順序。在每個Neighbor消息中通告的組識別符號資訊元素包括計數器值(每個控制器維護一個16位計數器,該計數器從0開始,並在諸如RF組的退出或WLC重新引導等事件後遞增)和控制器MAC地址。每個WLC將首先根據此計數器值確定來自其鄰居的組識別符號值的優先順序,然後在出現計數器值連線時根據MAC地址確定組識別符號值的優先順序。每個WLC將選擇一個具有最高組識別符號值的控制器(鄰接WLC或自身),之後每個控制器將與其他控制器協商,以確定哪個控制器的組ID最高。然後,該WLC將被選舉為RF組領導者。
如果RF組領導離線,則整個組將被解散,現有RF組成員將重新運行Group Leader選擇過程,並選擇一個新領導。
RF組領導每10分鐘會輪詢組中的每個WLC以獲取AP的統計資訊,以及它們收到的所有鄰居消息資訊。透過此資訊,組長可以瞭解整個系統的射頻環境,然後可以使用DCA和TPC演算法連續調整AP的通道和電源配置。Group Leader每10分鐘運行一次這些演算法,但與「覆蓋盲區檢測和糾正」演算法一樣,僅在確定必要時才進行更改。
DCA演算法由RF組領導運行,在每個RF組的基礎上應用,以確定所有RF組的AP的最佳AP通道設定(由於訊號不重疊這一事實,本文檔中稱為邏輯RF子組的每組AP都獨立於其他邏輯RF子組完成了其通道配置)。在DCA過程中,領導者會考慮一些特定於AP的指標,這些指標在確定必要的通道更改時會被考慮在內。這些度量包括:
負載測量— 每個AP測量傳送或接收802.11幀佔用總時間的百分比。
雜訊 — AP計算在每條接受服務的通道的雜訊值。
干擾 — AP報告造成干擾的802.11傳輸(可能來自來自外部AP以及非鄰居的重疊訊號)所佔據介質的百分比。
訊號強度— 每個AP偵聽所有接受服務的通道的鄰居消息,並記錄偵聽這些消息時的RSSI值。此AP訊號強度資訊是DCA計算通道能量時考慮的最重要度量。
然後,組領導使用這些值來確定另一個通道模式是否會導致效能最差的AP至少改善5dB (SNR)或更多。對AP在其操作通道上的權重進行分配,以便通道調整在本地進行,抑制更改以防止多米諾效果,從而單個更改將觸發整個系統的通道更改。還根據利用率(從每個AP的負載測量報告得出)為AP提供首選項,以便在需要更改時,使用率較低的AP發生通道更改的可能性更高(與使用率高的鄰居相比)。
注意:每當AP通道發生更改,客戶端都會短暫斷開連線。客戶端可以重新連線到同一個AP(在其新通道上),也可以漫遊到附近的AP,這取決於客戶端的漫遊行為。快速、安全的漫遊(由CCKM和PKC提供)有助於減少這種短暫的中斷,因為有相容的客戶端。
註:當AP首次啟動(開箱即用)時,它們會在所支援的頻帶中的第一個非重疊通道上傳輸(11b/g的通道1和11a的通道36)。當AP重新通電時,它們會使用先前的通道設定(儲存在AP的記憶體中)。隨後將根據需要進行DCA調整。
TPC演算法預設以固定的10分鐘間隔運行,RF組領導使用TPC演算法來確定AP的RF鄰接並下調每個頻段的發射功率水準,以限制過度小區重疊和同通道干擾。
注意:TPC演算法僅負責降低功率水準。傳輸功率的增加是覆蓋空洞檢測與消除演算法功能的一部分,將在後續部分中說明。
每個AP都會報告所有相鄰AP的RSSI排序清單,如果AP有三個以上的相鄰AP (若要讓TPC運作,您必須有至少4個AP),RF群組領導會針對每個頻段、每個AP套用TPC演演算法,以向下調整AP的功率傳輸層級,如此便可在訊號層級-70dBm (預設值或設定的值)或更低的訊號層級聽到第三個最響的相鄰AP,並滿足TCP滯後條件。因此,TCP會經歷以下階段,這些階段會決定是否有必要更改傳輸功率:
確定是否存在第三個鄰居,以及該第三個鄰居是否高於發射功率控制閾值。
使用以下公式確定發射功率:給定AP的Tx_Max +(Tx功率控制閾值-閾值之上的第三高鄰居的RSSI)。
將步驟2中的計算與當前Tx功率電平進行比較,並驗證它是否超過TPC滯後。
如果需要降低Tx功率:必須滿足至少6dBm的TPC遲滯。或
如果需要增加Tx功率:必須滿足3dBm的TPC滯後。
TPC演算法中所用邏輯的示例可以在發射功率控制演算法工作流示例部分中找到。
註:當所有AP首次啟動(開箱即用)時,它們將以最大功率水準傳輸。當AP重新通電時,它們會使用之前的電源設定。隨後將根據需要進行TPC調整。有關支援的AP發射功率水準的資訊,請參閱表4。
注意:使用TPC演演算法可觸發兩個主要Tx電源增加案例:
沒有第三個鄰居。在這種情況下,AP會預設返回Tx_max,並立即執行此操作。
還有第三個鄰居。TPC方程式實際上會評估建議的Tx在Tx_max和Tx_current之間的某個位置(而不是低於Tx_current),例如在第三個鄰居「離開」且有新的可能的第三個鄰居時。這會導致Tx功率增加。
TPC誘導的Tx減少逐漸發生,但Tx增加可能立即發生。但是,對於如何隨著覆蓋空洞演算法增加Tx功率採取了額外的預防措施,每次提高一級。
覆蓋空洞檢測與糾正演算法旨在首先根據客戶端訊號電平的品質確定覆蓋空洞,然後增加這些客戶端所連線的AP的發射功率。由於此演算法與客戶端統計資訊有關,因此它在每個控制器上獨立運行,而不是在RF組領導上全系統運行。
當客戶端的SNR水平低於給定的SNR閾值時,該演算法確定是否存在覆蓋空洞。SNR閾值是根據單個AP來考慮的,並且主要基於每個AP的發射功率電平。AP的功率水準越高,與客戶端訊號強度相比,容忍的雜訊就越多,這意味著容忍的SNR值越低。
此SNR閾值取決於兩個值:AP發射功率和控制器覆蓋範圍配置檔案值。具體來說,閾值由每個AP發射功率(以dBm表示)減去常數值17dBm減去使用者可配置的覆蓋範圍配置檔案值來定義(該值預設為12 dB,詳見第20頁)。客戶端SNR閾值是該等式結果的絕對值(正數)。
覆蓋盲區SNR閾值公式:
客戶端SNR截止值(|dB|) = [AP發射功率(dBm) -常數(17 dBm) -覆蓋配置檔案(dB)]
一旦配置的使用者端平均SNR數量在至少60秒內下降到此SNR閾值以下,這些使用者端的AP發射功率將增加以緩解SNR違規,從而糾正覆蓋盲區。每個控制器每三分鐘對每個AP上的每個無線電運行覆蓋空洞檢測與糾正演算法(可以更改預設值180秒)。必須注意的是,不穩定環境可能會導致TPC演算法在後續演算法運行時關閉電源。
「粘滯客戶端」啟動注意事項:
傳統客戶端驅動程式中的漫遊實施會導致客戶端「貼上」到現有的AP,即使存在其他AP,而對於RSSI、吞吐量和整體客戶端體驗而言,AP更佳。反過來,這種行為可能會對無線網路造成系統性的影響,從而使用者端會被認為經歷較差的SNR(因為他們無法漫遊),最終導致覆蓋空洞檢測。在這種情況下,演算法會加電AP的發射功率(以便為表現不佳的客戶端提供覆蓋),這將導致不期望的(並且高於正常的)發射功率。
在漫遊邏輯本身得到改善之前,可透過增加客戶端Min來緩解這種情況。例外狀況層級調高到較高的值(預設值為3),同時增加可容許的使用者端SNR值(預設值為12 dB,當變更為3 dB時會有改善)。如果使用代碼版本4.1.185.0或更高版本,則預設值可在大多數環境中提供最佳結果。
注意:雖然這些建議基於內部測試,且因個別部署而異,但修改這些建議背後的邏輯仍然適用。
有關觸發中涉及的邏輯的示例,請參閱覆蓋空洞檢測與消除演算法示例部分。
註:覆蓋空洞檢測與消除演算法還負責檢測因AP故障導致的覆蓋盲區以及根據需要啟動附近的AP。這允許網路在服務中斷時進行修復。
瞭解RRM和演算法後,下一步就是瞭解如何解釋和修改必要的引數。本節詳細介紹RRM的配置操作,並概述基本報告設定。
配置RRM的第一步是確保每個WLC都配置相同的RF組名。如果選擇Controller | General,然後輸入一個共用的Group Name值,即可透過控制器的Web介面完成此操作。同一RF組中的WLC之間的IP連線也是必要的。
圖9:RF組是根據使用者指定的「RF網路名稱」(在本文檔中也稱為RF組名稱)值形成的。參與全系統的RRM操作所需的所有WLC應共用此字串。
以下部分中的所有配置說明和示例透過WLC圖形介面執行。在WLC GUI中,轉到Wireless的主標題,並為左側的WLAN standard of choice選擇RRM選項。接下來,在樹中選擇Auto RF。後續的段落會參照結果頁面[無線] | 802.11a或802.11b/g RRM | 自動RF...]。
Group Mode —透過Group Mode設定可停用RF分組。停用此功能可防止WLC與其他控制器分組以執行系統範圍的RRM功能。已停用,所有RRM決策都將是控制器的本地決策。預設情況下,RF分組已啟用,並且同一RF組中的其他WLC的MAC地址列在Group Mode覈取方塊的右側。
Group Update Interval —此組更新間隔值指示運行RF分組演算法的頻率。這是僅供顯示的欄位,無法修改。
Group Leader —此欄位顯示當前作為RF組領導的WLC的MAC地址。因為RF分組是每個AP、每個無線電執行的,所以對於802.11a和802.11b/g網路,此值可以不同。
Is this controller a Group Leader —當控制器為RF組領導時,此欄位值將為「Yes」。 如果WLC不是領導者,則上一個欄位將指示組中哪個WLC是領導者。
Last Group Update — RF分組演算法每600秒(10分鐘)運行一次。此欄位只指示自上次運行演算法以來的時間(秒),而不一定表示上次選擇新的RF組領導的時間。
Channel Assignment Method— 可以將DCA演算法配置為以下三種方式之一:
Automatic —這是預設配置。啟用RRM時,DCA演算法每600秒(10分鐘)運行一次,如有必要,將在此間隔進行通道更改。這是僅供顯示的欄位,無法修改。請注意附錄A中的4.1.185.0選項。
On Demand —這樣將阻止DCA演算法運行。按一下「立即呼叫通道更新」按鈕可以手動觸發該演算法。
注意:如果選擇按需,然後按一下立即呼叫通道更新,假設必須更改通道,則將在下一個600秒間隔時運行DCA演算法並應用新的通道計畫。
Off —此選項停用所有DCA功能,不推薦使用此選項。這通常是在執行手動站點勘察並隨後單獨配置每個AP通道設定時停用的。儘管沒有關聯,但通常也會在修正TPC演算法時一併進行。
Avoid Foreign AP Interference —透過此欄位可在DCA演算法計算中加入同通道干擾指標。預設會啟用此欄位。
Avoid Cisco AP Load —透過此欄位,可以在確定哪個AP的通道需要更改時考慮AP的利用率。AP負載是一個經常更改的度量,在RRM計算中可能並不總是需要包含它。因此,預設會停用此欄位。
Avoid non-802.11b Noise —透過此欄位,可以讓每個AP的非802.11雜訊水準作為對DCA演算法的一個影響因素。預設會啟用此欄位。
Signal Strength Contribution — DCA計算中總是加入相鄰AP的訊號強度。這是僅供顯示的欄位,無法修改。
Channel Assignment Leader —此欄位顯示當前作為RF組領導的WLC的MAC地址。因為RF分組是每個AP、每個無線電執行的,所以對於802.11a和802.11b/g網路,此值可以不同。
Last Channel Assignment — DCA演算法每600秒(10分鐘)運行一次。此欄位只指示自上次運行演算法以來經過的時間(秒),而不一定表示最後一次分配新通道的時間。
Power Level Assignment Method —可以將TPC演算法配置為以下三種方式之一:
Automatic —這是預設配置。啟用RRM時,TPC演算法每十分鐘(600秒)運行一次,如有必要,將在此間隔更改電源設定。這是僅供顯示的欄位,無法修改。
On Demand —這樣將阻止TPC演算法運行。如果按一下Invoke Channel Update Now按鈕,則可以手動觸發該演算法。
註:如果選擇On Demand,然後按一下Invoke Power Update Now,假設必須更改功率,則將在下一個600秒間隔時運行TPC演算法並應用新的功率設定。
Fixed —此選項停用所有TPC功能,不推薦使用此選項。這通常是在執行手動現場勘測並隨後單獨配置每個AP電源設定時停用的。雖然不相關,但這通常與停用DCA演算法同時執行。
Power Threshold —此值(以dBm為單位)是TPC演算法將下調功率水準時的截止訊號水準,這樣此值即成為偵聽到AP的第三強鄰居時的強度。在已認為RF環境太「熱」的某些罕見場合(即在密度可能太高的場景中的AP以高於期望的發射功率水準進行發射)中,可使用config advanced 802.11b tx-power-control-thresh命令允許下調功率。這使AP能夠聽到其第三個鄰居的更大程度的RF分離,從而使得相鄰AP能夠以更低的功率水準進行傳輸。此引數在軟體版本3.2之前是不可修改的。新的可配置值範圍從-50dBm到-80dBm,只能從控制器的CLI進行更改。
Power Neighbor Count —要運行TPC演算法,AP必須擁有的最少鄰居數。這是僅供顯示的欄位,無法修改。
Power Update Contribution —當前不使用此欄位。
Power Assignment Leader —此欄位顯示當前作為RF組領導的WLC的MAC地址。因為RF分組是每個AP、每個無線電執行的,所以對於802.11a和802.11b/g網路,此值可以不同。
Last Power Level Assignment — TPC演算法每600秒(10分鐘)運行一次。此欄位只指示自上次運行演算法以來經過的時間(秒),而不一定表示最後一次進行新的功率分配的時間。
配置檔案閾值(在無線控制系統(WCS)中稱為RRM閾值)主要用於報警。當超過這些值時,陷阱會向上傳送到WCS(或任何其他基於SNMP的管理系統),以便輕鬆診斷網路問題。這些值僅用於發出警報,對RRM演算法的功能沒有任何影響。
圖13:預設警報配置檔案閾值。
Interference (0 to 100%) -觸發警報之前造成干涉的802.11訊號所佔據無線介質的百分比。
Clients (1到75) -每個頻段、每個AP的客戶端數量,超過此數量後控制器將生成SNMP陷阱。
Noise (-127 to 0 dBm) -當本底雜訊升高超過所設定的水準時用於生成SNMP陷阱。
覆蓋範圍(3到50 dB) -每個客戶端的最大可接受SNR水準。此值用於生成覆蓋異常級別和客戶端最小異常級別閾值的陷阱。(4.1.185.0及更高版本中的部分覆蓋空洞演算法子部分)
Utilization (0 to 100%) -指示AP的無線用於傳送和接收的時間所佔最大預期百分比的警報值。這有助於跟蹤一段時間內的網路利用率。
Coverage Exception Level (0到100%) — AP的無線中運行於所需Coverage閾值(定義如上)之下的客戶端的最大所需百分比。
Client Min Exception Level — SNR低於覆蓋閾值(如上所述)的每個AP所允許的最小預期客戶端數(4.1.185.0及更高版本中覆蓋空洞演算法子部分的一部分)。
Cisco AP提供客戶端資料服務,並定期掃描RRM(和IDS/IPS)功能。允許AP掃描的通道是可配置的。
通道清單:使用者可以指定AP將定期監控的通道範圍。
All Channels —此設定將讓AP在掃描週期中包括每個通道。這主要對IDS/IPS功能(在本文檔範圍之外)有幫助,並且與「國家/地區通道」設定相比,在RRM過程中不提供附加值。
Country Channels — AP將僅掃描每個WLC的監管區域配置中明確支援的那些通道。這意味著AP將定期花時間偵聽本地管理機構允許的每個通道(這可能包括重疊通道以及常用的非重疊通道)。這是預設組態。
DCA Channels —此選項將AP的掃描限制在將根據DCA演算法向其分配AP的那些通道中。這意味著在美國,預設情況下802.11b/g無線電僅掃描通道1、6和11。這基於一種觀點,即掃描僅側重於提供服務的通道,而非法AP則不值得考慮。
注意:DCA演算法使用的通道清單(用於通道監控和分配)可以在WLC代碼版本4.0或更高版本中更改。例如,在美國,DCA演算法預設僅使用1、6和11的11b/g通道。為了增加通道4和8,並從此DCA清單中刪除通道6(此配置只是一個示例,不推薦使用),需要在控制器CLI中輸入以下命令:
(Cisco Controller) >config advanced 802.11b channel add 4 (Cisco Controller) >config advanced 802.11b channel add 8 (Cisco Controller) >config advanced 802.11b channel delete 6
透過掃描更多通道(如All Channels選項),用於服務資料客戶端的總時間會略有減少(與掃描過程中包含的通道數減少時相比)。但是,可以獲取更多通道的資訊(與DCA通道設定相比)。應使用國家/地區通道的預設設定,除非IDS/IPS需要選擇「所有通道」,或者閾值配置檔案警報和RRM演算法檢測和修復不需要有關其他通道的詳細資訊。在這種情況下,DCA通道是適當的選擇。
圖14:雖然「Country Channels」是預設選項,但RRM監控通道可以設定為「All」或「DCA」通道。
所有基於Cisco LWAPP的AP都向使用者提供資料,同時定期離開通道進行RRM測量(以及執行IDS/IPS和位置任務等其他功能)。這種通道外掃描對使用者是完全透明的,並且效能最多只限制為1.5%,此外內建智慧功能,可在語音隊列中存在最近100毫秒的流量時延遲掃描到下一個間隔。
調整監控間隔將更改AP進行RRM測量的頻率。控制RF組形成的最重要計時器是訊號測量欄位(在4.1.185.0及更高版本中稱為鄰居資料包頻率)。指定的值與鄰居消息的傳輸頻率直接相關,但EU和其他802.11h域(其中也考慮雜訊測量間隔)除外。
無論管理範圍為何,整個掃描過程大約需要50毫秒(每個無線電、每個通道)並以預設的180秒間隔運行。此間隔可以透過更改「覆蓋測量」(Coverage Measurement)(在4.1.185.0及更高版本中稱為通道掃描持續時間)值來更改。每個通道上的偵聽時間是無法配置的50毫秒掃描時間(加上切換通道所需的10毫秒)和要掃描的通道數的函式。例如,在美國,所有11個802.11b/g通道(包括將資料傳送到客戶端的一個通道)將在180秒間隔內掃描每個50毫秒。這意味著(在美國,802.11b/g)每16秒將花費50毫秒偵聽每個掃描的通道(180/11 = ―16秒)。
圖15: RRM監視間隔及其預設值
可以調整雜訊、負載、訊號和覆蓋測量間隔,為RRM演算法提供或多或少粒度資訊。除非Cisco TAC另有說明,否則應保留這些預設值。
注意:如果更改其中任何掃描值以超出RRM演算法運行的間隔(DCA和TPC為600秒,覆蓋空洞檢測和修復為180秒),RRM演算法仍將運行,但可能具有「過時」資訊。
注意:當WLC配置為使用鏈路聚合(LAG)繫結多個千兆乙太網介面時,覆蓋測量間隔用於觸發使用者空閒超時功能。同樣,在啟用LAG的情況下,使用者空閒超時的執行頻率僅取決於覆蓋測量間隔所指定的頻率。這只適用於執行4.1之前韌體版本的WLC,因為在4.1版本中,閒置逾時處理會從控制器移至存取點。
要將RRM值重置為預設設定,請按一下頁面底部的Set to Factory Default按鈕。
透過啟用必要的SNMP陷阱,可以輕鬆監控RRM所做的更改。可以從WLC GUI中的Management —> SNMP —> Trap Controls標題訪問這些設定。本節中詳細介紹的所有其他相關SNMP陷阱設定都位於Management下 | SNMP標題,其中可以找到Trap Receivers、Controls和Logs的連結。
圖16:預設情況下啟用自動RF通道和電源更新陷阱。
在RF組領導者(和DCA演算法)建議、應用和最佳化通道模式後,可以透過Trap Logs子選單輕鬆監控更改。以下為此類補漏白的範例:
圖17:通道更改日誌條目包含無線電的MAC地址和新的運行通道。
為了檢視統計資訊,詳細顯示AP在DCA更改之間保持其通道設定的時間,此CLI專用命令按控制器提供通道停留時間的最小值、平均值和最大值。
(Cisco Controller) >show advanced 802.11b channel Automatic Channel Assignment Channel Assignment Mode........................ AUTO Channel Update Interval........................ 600 seconds Anchor time (Hour of the day).................. 0 Channel Update Contribution.................... SNI. Channel Assignment Leader...................... 00:16:46:4b:33:40 Last Run....................................... 114 seconds ago DCA Senstivity Level: ....................... MEDIUM (15 dB) Channel Energy Levels Minimum...................................... unknown Average...................................... unknown Maximum...................................... unknown Channel Dwell Times Minimum...................................... 0 days, 09 h 25 m 19 s Average...................................... 0 days, 10 h 51 m 58 s Maximum...................................... 0 days, 12 h 18 m 37 s Auto-RF Allowed Channel List................... 1,6,11 Auto-RF Unused Channel List.................... 2,3,4,5,7,8,9,10
可以在控制器CLI上使用以下命令驗證當前TPC演算法設定(包括前面介紹的tx-power-control-thresh)(本示例中顯示802.11b):
(Cisco Controller) >show advanced 802.11b txpower Automatic Transmit Power Assignment Transmit Power Assignment Mode................. AUTO Transmit Power Update Interval................. 600 seconds Transmit Power Threshold....................... -70 dBm Transmit Power Neighbor Count.................. 3 APs Transmit Power Update Contribution............. SNI. Transmit Power Assignment Leader............... 00:16:46:4b:33:40 Last Run....................................... 494 seconds ago
如本文前面所述,密集部署的地區導致蜂窩重疊的情況增加,這又會因大量的同通道干擾而導致大量衝突和很高的幀重試率,實際上會降低客戶端的吞吐量水準,這些情況說明有必要使用新引入的tx-power-control-thresh命令。在這樣的非典型或異常場景中,AP彼此的偵聽能力(假設訊號傳播特性保持不變)要優於客戶端偵聽能力。
縮小覆蓋區域,從而減少同通道干擾和雜訊底限,可有效改善客戶端體驗。但是,執行此命令時必須仔細分析系統中的AP(DCA中考慮有問題的AP)上的症狀:重試率高、衝突計數高、客戶端吞吐量級別較低以及共通道干擾總體增加。內部測試顯示,在排除此類事件的故障時將第三個鄰居的感知RSSI修改為-70 dBm是開始進行故障排除的可接受值。
與發生通道更改時生成的陷阱類似,TPC更改也會生成陷阱,從而清楚地指示與新更改相關聯的所有必要資訊。範例補漏白會顯示在這裡:
圖18: Tx電源陷阱日誌指示指定無線電的新功率操作級別。
根據TPC演算法中定義的三個步驟/條件,本部分中的示例說明如何計算確定AP的發射功率是否需要更改。在此範例中,會假設這些值:
Tx_Max為20
當前傳輸功率為20 dBm
配置的TPC閾值為-65 dBm
第三個鄰居的RSSI為-55 dBm
將其插入TPC演算法的三個階段,將導致:
條件一:由於存在第三個鄰居,並且高於傳輸功率控制閾值,因此已驗證。
條件二:20 + (-65 - (-55)) = 10
條件三:由於功率必須降低一個等級,且條件2的十值滿足TPC滯後,Tx功率會降低3dB,從而使新的Tx功率降至17dBm。
在TPC演算法的下一次迭代中,AP的Tx功率將進一步降低到14dBm。這假設所有其他條件都保持不變。不過,必須注意的是,Tx功率不會進一步降低(保持一切不變)至11dBm,因為14dBm的邊界不是6dB或更高。
為了說明覆蓋空洞檢測與糾正演算法中使用的決策過程,下面的示例首先概述了單個客戶端的較差接收SNR水準,以及系統如何確定是否需要更改以及可能的功率更改。
記住覆蓋盲區SNR閾值等式:
客戶端SNR截止值(|dB|) = [AP發射功率(dBm) -常數(17 dBm) -覆蓋配置檔案(dB)]
假設客戶在地板覆蓋較差的區域中可能會遇到訊號問題。在這種情況下,以下情況可能確實如此:
客戶端的SNR為13dB。
其所連線的AP配置為以11 dBm(功率電平4)進行傳輸。
該AP的WLC的覆蓋範圍配置檔案閾值設定為預設值12 dB。
為了確定客戶端的AP是否需要通電,這些數字會插入覆蓋空洞閾值等式,從而導致:
客戶端SNR截止值= 11dBm(AP發射功率) - 17dBm(常值) - 12dB(覆蓋閾值) = |-18dB|。
由於客戶端13dB的SNR違反了當前18dB的SNR截止值,因此覆蓋空洞檢測與糾正演算法會將AP的發射功率增加到17dBm。
利用覆蓋空洞SNR閾值方程,可以明顯看出,17dBm的新發射功率將產生12dB的客戶端SNR截止值,滿足客戶端13dBm的SNR水準。
這是上一步的算術:客戶端SNR截止值= 17dBm(AP發射功率) - 17dBm(常值) - 12dB(覆蓋閾值) = |-12dB|。
表4列出了802.11b/g頻帶中支援的電源輸出級別。要確定802.11a的電源電平輸出,可以運行以下CLI命令:
show ap config 802.11a
表4:1000系列AP支援高達5的電源,而1100和1200系列AP支援高達802.11b/g頻帶的電源8電平。
支援的電源等級 | 發射功率(dBm) | 發射功率(mW) |
---|---|---|
1 | 20 | 100 |
2 | 17 | 50 |
3 | 14 | 25 |
4 | 11 | 12.5 |
5 | 8 | 6.5 |
6 | 5 | 3.2 |
7 | 2 | 1.6 |
8 | -1 | 0.8 |
airewave-director debug命令可用於進一步對RRM行為進行故障排除和驗證。以下顯示debug airewave-director命令的頂級命令列層次結構:
(Cisco Controller) >debug airewave-director ? all Configures debug of all Airewave Director logs channel Configures debug of Airewave Director channel assignment protocol error Configures debug of Airewave Director error logs detail Configures debug of Airewave Director detail logs group Configures debug of Airewave Director grouping protocol manager Configures debug of Airewave Director manager message Configures debug of Airewave Director messages packet Configures debug of Airewave Director packets power Configures debug of Airewave Director power assignment protocol radar Configures debug of Airewave Director radar detection/avoidance protocol rf-change Configures logging of Airewave Director rf changes profile Configures logging of Airewave Director profile events
以下小節將介紹幾個重要的命令。
使用debug airewave-director all命令將呼叫所有可以幫助標識何時運行RRM演算法、這些演算法使用什麼資料以及做出了什麼更改(如果有)的RRM調試。
在本例中,(debug airewave-director all命令的輸出已修剪為僅顯示動態通道分配過程),該命令在RF組領導上運行以瞭解有關DCA演算法內部工作的資訊,並可分為以下四個步驟:
收集並記錄將透過演演算法執行的目前統計值。
Airewave Director: Checking quality of current assignment for 802.11a Airewave Director: 802.11a AP 00:15:C7:A9:3D:F0(1) ch 161 (before -86.91, after -128.00) Airewave Director: 00:15:C7:A9:3D:F0(1)( 36, -76.00)( 40, -81.75)( 44, -81.87) ( 48, -81.87) Airewave Director: 00:15:C7:A9:3D:F0(1)( 52, -81.87)( 56, -81.85)( 60, -79.90) ( 64, -81.69) Airewave Director: 00:15:C7:A9:3D:F0(1)(149, -81.91)(153, -81.87)(157, -81.87) (161, -86.91)
建議新的通道結構描述並儲存建議的值。
Airewave Director: Searching for better assignment for 802.11a Airewave Director: 802.11a AP 00:15:C7:A9:3D:F0(1) ch 161 (before -86.91, after -128.00) Airewave Director: 00:15:C7:A9:3D:F0(1)( 36, -76.00)( 40, -81.75)( 44, -81.87) ( 48, -81.87) Airewave Director: 00:15:C7:A9:3D:F0(1)( 52, -81.87)( 56, -81.85)( 60, -79.90) ( 64, -81.69) Airewave Director: 00:15:C7:A9:3D:F0(1)(149, -81.91)(153, -81.87)(157, -81.87) (161, -86.91)
將目前的值與建議的值進行比較。
Airewave Director: Comparing old and new assignment for 802.11a Airewave Director: 802.11a AP 00:15:C7:A9:3D:F0(1) ch 161 (before -86.91, after -86.91) Airewave Director: 00:15:C7:A9:3D:F0(1)( 36, -76.00)( 40, -81.75)( 44, -81.87) ( 48, -81.87) Airewave Director: 00:15:C7:A9:3D:F0(1)( 52, -81.87)( 56, -81.85)( 60, -79.90) ( 64, -81.69) Airewave Director: 00:15:C7:A9:3D:F0(1)(149, -81.91)(153, -81.87)(157, -81.87) (161, -86.91)
如有必要,請套用變更,讓新的通道結構描述生效。
Airewave Director: Before -- 802.11a energy worst -86.91, average -86.91, best -86.91 Airewave Director: After -- 802.11a energy worst -86.91, average -86.91, best -86.91
此命令可用於獲取運行該命令的控制器上RRM功能的詳細即時檢視。以下是相關訊息的說明:
傳送到組成員的保持連線消息以維護組層次結構。
Airewave Director: Sending keep alive packet to 802.11a group members
正在報告的鄰居上計算的負載統計資訊。
Airewave Director: Processing Load data on 802.11bg AP 00:13:5F:FA:2E:00(0) Airewave Director: Processing Load data on 802.11bg AP 00:0B:85:54:D8:10(1) Airewave Director: Processing Load data on 802.11bg AP 00:0B:85:23:7C:30(1)
顯示偵聽鄰居消息的強度以及透過AP偵聽的AP。
Airewave Director: Neighbor packet from 00:0B:85:54:D8:10(1) received by 00:13:5F:FA:2E:00(0)rssi -36 Airewave Director: Neighbor packet from 00:0B:85:23:7C:30(1) received by 00:13:5F:FA:2E:00(0)rssi -43
在報告無線電處計算的雜訊和干擾統計資料。
Airewave Director: Sending keep alive packet to 802.11bg group members Airewave Director: Processing Interference data on 802.11bg AP 00:0B:85:54:D8:10(1) Airewave Director: Processing noise data on 802.11bg AP 00:0B:85:54:D8:10(1) Airewave Director: Processing Interference data on 802.11bg AP 00:0B:85:54:D8:10(1) Airewave Director: Processing Interference data on 802.11bg AP 00:0B:85:23:7C:30(1) Airewave Director: Processing noise data on 802.11bg AP 00:0B:85:23:7C:30(1) Airewave Director: Processing Interference data on 802.11bg AP 00:0B:85:23:7C:30(1)
debug airewave-director power 命令必須運行在為覆蓋空洞修復監視的AP的本地WLC。出於本示例的目的,已修剪了命令的輸出。
正在監視為802.11a運行的覆蓋空洞演算法
Airewave Director: Coverage Hole Check on 802.11a AP 00:0B:85:54:D8:10(0) Airewave Director: Found 0 failed clients on 802.11a AP 00:0B:85:54:D8:10(0) Airewave Director: Found 0 clients close to coverage edge on 802.11a AP 00:0B:85:54:D8:10(0) Airewave Director: Last power increase 549 seconds ago on 802.11a AP 00:0B:85:54:D8:10(0) Airewave Director: Set raw transmit power on 802.11a AP 00:0B:85:54:D8:10(0) to ( 20 dBm, level 1)
正在監視為802.11b/g運行的覆蓋空洞演算法
Airewave Director: Coverage Hole Check on 802.11bg AP 00:13:5F:FA:2E:00(0) Airewave Director: Found 0 failed clients on 802.11bg AP 00:13:5F:FA:2E:00(0) Airewave Director: Found 0 clients close to coverage edge on 802.11bg AP 00:13:5F:FA:2E:00(0) Airewave Director: Last power increase 183 seconds ago on 802.11bg AP 00:13:5F:FA:2E:00(0) Airewave Director: Set raw transmit power on 802.11bg AP 00:13:5F:FA:2E:00(0) to ( 20 dBm, level 1) Airewave Director: Set adjusted transmit power on 802.11bg AP 00:13:5F:FA:2E:00(0) to ( 20 dBm, level 1)
要瞭解哪些AP與其他AP相鄰,請從控制器CLI中使用命令show ap auto-rf。在此命令的輸出中,有稱為Nearby RADs的欄位。此欄位提供有關附近AP MAC地址以及dBm中AP之間的訊號強度(RSSI)的資訊。
以下是命令的語法:
show ap auto-rf {802.11a | 802.11b} Cisco_AP
範例如下:
> show ap auto-rf 802.11a AP1 Number Of Slots.................................. 2 Rad Name......................................... AP03 MAC Address...................................... 00:0b:85:01:18:b7 Radio Type..................................... RADIO_TYPE_80211a Noise Information Noise Profile................................ PASSED Channel 36................................... -88 dBm Channel 40................................... -86 dBm Channel 44................................... -87 dBm Channel 48................................... -85 dBm Channel 52................................... -84 dBm Channel 56................................... -83 dBm Channel 60................................... -84 dBm Channel 64................................... -85 dBm Interference Information Interference Profile......................... PASSED Channel 36................................... -66 dBm @ 1% busy Channel 40................................... -128 dBm @ 0% busy Channel 44................................... -128 dBm @ 0% busy Channel 48................................... -128 dBm @ 0% busy Channel 52................................... -128 dBm @ 0% busy Channel 56................................... -73 dBm @ 1% busy Channel 60................................... -55 dBm @ 1% busy Channel 64................................... -69 dBm @ 1% busy Load Information Load Profile................................. PASSED Receive Utilization.......................... 0% Transmit Utilization......................... 0% Channel Utilization.......................... 1% Attached Clients............................. 1 clients Coverage Information Coverage Profile............................. PASSED Failed Clients............................... 0 clients Client Signal Strengths RSSI -100 dBm................................ 0 clients RSSI -92 dBm................................ 0 clients RSSI -84 dBm................................ 0 clients RSSI -76 dBm................................ 0 clients RSSI -68 dBm................................ 0 clients RSSI -60 dBm................................ 0 clients RSSI -52 dBm................................ 0 clients Client Signal To Noise Ratios SNR 0 dBm................................. 0 clients SNR 5 dBm................................. 0 clients SNR 10 dBm................................. 0 clients SNR 15 dBm................................. 0 clients SNR 20 dBm................................. 0 clients SNR 25 dBm................................. 0 clients SNR 30 dBm................................. 0 clients SNR 35 dBm................................. 0 clients SNR 40 dBm................................. 0 clients SNR 45 dBm................................. 0 clients Nearby RADs RAD 00:0b:85:01:05:08 slot 0................. -46 dBm on 10.1.30.170 RAD 00:0b:85:01:12:65 slot 0................. -24 dBm on 10.1.30.170 Channel Assignment Information Current Channel Average Energy............... -86 dBm Previous Channel Average Energy.............. -75 dBm Channel Change Count......................... 109 Last Channel Change Time..................... Wed Sep 29 12:53e:34 2004 Recommended Best Channel..................... 44 RF Parameter Recommendations Power Level.................................. 1 RTS/CTS Threshold............................ 2347 Fragmentation Threshold...................... 2346 Antenna Pattern.............................. 0
鄰居清單「修剪計時器」
在WLC軟體4.1的第一個維護版本之前,AP會將其他AP保留在鄰居清單中,從上次偵聽它們起最多保留20分鐘。如果RF環境發生臨時更改,則可能有有效鄰居從給定AP的鄰居清單中刪除的可能性。為了對RF環境提供這樣的臨時更改,AP鄰居清單的修剪計時器(自上次聽到鄰居消息以來的時間)已增加到60分鐘。
通道分配方法
在自動模式下,4.1.185.0之前的DCA的預設行為是每10分鐘計算並應用(如有必要)通道計畫。動盪的環境可能會在一天之內發生許多通道變化。因此,需要對DCA的頻率進行高級、更精細的控制。在4.1.185.0及更高版本中,使用者希望更好地控制頻率,可以配置以下功能:
錨點時間 -使用者希望更改預設的10分鐘,可在領導組將在啟動模式下執行時選擇錨點時間。「啟動」模式定義為DCA每10分鐘運行前10次迭代(100分鐘)的週期,DCA靈敏度為5dB。這是在版本4.1中增加RRM計時器之前的正常操作模式。這可以使網路在初始階段和快速穩定。啟動模式結束後,DCA會以使用者定義的間隔執行。啟動模式操作透過show advanced 802.11[a|b]命令在WLC CLI中明確指示:
(Cisco Controller) >show advanced 802.11a channel Automatic Channel Assignment Channel Assignment Mode........................ AUTO Channel Update Interval........................ 600 seconds [startup] Anchor time (Hour of the day).................. 0 Channel Update Contribution.................... SNI. Channel Assignment Leader...................... 00:16:46:4b:33:40 Last Run....................................... 203 seconds ago DCA Senstivity Level: ....................... MEDIUM (5 dB) Channel Energy Levels Minimum...................................... unknown Average...................................... unknown Maximum...................................... unknown Channel Dwell Times Minimum...................................... unknown Average...................................... unknown Maximum...................................... unknown Auto-RF Allowed Channel List................... 36,40,44,48,52,56,60,64,100, ............................................. 104,108,112,116,132,136,140, ............................................. 149,153,157,161 Auto-RF Unused Channel List.................... 165,20,26
間隔- 間隔值,以小時定義單元,允許使用者可預測網路,並且通道計畫評估僅在配置的間隔下進行計算。例如,如果配置的間隔為3小時,則DCA每3小時計算一次新的通道計畫並對其進行評估。
區分 -如DCA演算法部分中所述,演算法中計算的5dB滯後評估是否透過運行演算法改進通道計畫。允許的組態為「低」、「中」或「高」,其設定值為「低」表示演演算法非常不敏感,而設定值為「高」則表示演演算法非常敏感。兩個頻帶的預設敏感度等級為「中」。
對於802.11a,靈敏度值等於:低(35dB)、中(20dB)和高(5dB)。
對於802.11b/g,靈敏度值等於:低(30dB)、中(15dB)和高(5dB)
預設傳輸功率控制閾值
發射功率控制閾值始終負責AP如何偵聽其鄰居,而鄰居的偵聽結果將在適當時候用來決定AP的發射功率。由於WLC軟體的4.1維護版本對RRM演演算法進行了整體增強功能,因此也重新考慮了預設值-65dBm。因此,對於大多數部署而言,被視為過熱的預設值已調整為-70dBm。這可以在大多數開箱即用的室內部署中實現更好的蜂窩重疊。但是,此預設值只會影響新安裝,因為控制器從4.1.171.0或更早版本升級時,會維持先前設定的值。
在4.1.185.0之前,只需要一個客戶端滿足條件(SNR閾值比配置值差,或者802.11a的預設值是16dB,802.11b/g的預設值是12dB),即可檢測到覆蓋盲區並啟動緩解機制。Client Minimum Exception Level欄位現在直接與CHA關聯(並適當定位在新建立的CHA子部分中),其中配置的值將定義必須達到覆蓋空洞緩解機制(增加AP發射功率)的SNR閾值的客戶端數量。必須注意的是,大多數部署都應以預設值開始(802.11b/g為12dB,802.11a為16dB,客戶端最小異常級別為3),並僅在必要時進行調整。
圖19:涵蓋範圍空洞演演算法子區段,與「設定檔臨界值」分開,其預設值可在大部分安裝中提供最佳結果
除了允許需要違反覆蓋空洞緩解操作的客戶端數量啟動外,演算法還進行了改進,以智慧方式考慮AP發射功率增加。雖然將傳輸功率增加到最大可能是確保充分緩解和重疊的安全選擇,但因為存在漫遊實施不佳的客戶端,所以它確實會產生不良影響。客戶端與其將關聯更改至一個不同的AP(通常為可提供最強訊號的存取點),而是始終與與其相距較遠的同一舊AP關聯。因此,該客戶端不再從關聯的AP接收良好訊號。漫遊不佳導致的故障客戶端是可能誤報覆蓋盲區的示例。漫遊不佳並不表示存在真正的覆蓋盲區。潛在的覆蓋盲區是真實的,如果:
它位於預定的覆蓋區域內,並且
即使在此覆蓋孔中的客戶端改變其與任何其他可用AP的關聯,客戶端將接收的下行鏈路訊號,並且來自客戶端的在這樣一個備選AP的上行鏈路訊號仍將低於覆蓋閾值。
為了避免和緩解此類情況,AP發射功率一次僅提高一個等級(每次迭代),這允許真正的覆蓋盲區從功率的增加中受益,而不會使網路產生過熱(從而避免同通道干擾)。
在通道更改時生成的SNMP陷阱已得到增強,可提供詳細資訊,說明實施新通道計畫的原因。如本圖所示,增強型陷阱包括DCA演算法中使用的before和after度量,以及這些度量中的哪一個導致給定AP的通道更改。
圖20:改進的DCA陷阱顯示了通道更改背後的原因
為了簡化配置和提高可用性,我們為CHA建立了新的子部分,它與Profile Threshold子部分分離,後者直接控制SNMP Trap生成的觸發器。
監控間隔子部分下的訊號測量和覆蓋測量術語也已修改以反映其適當含義:相鄰資料包頻率和通道掃描持續時間。
4.1.185.0及更高版本的負載均衡的預設設定為OFF。啟用後,負載平衡窗口將預設為5個客戶端。
(Cisco Controller) >show load-balancing Aggressive Load Balancing........................ Disabled Aggressive Load Balancing Window................. 5 clients
此功能改進了QoS與RRM掃描延遲功能的互動方式。在使用某些省電客戶端的部署中,有時需要推遲RRM正常的通道外掃描,以避免丟失來自低流量客戶端的重要資訊,例如使用省電模式並定期傳送遙測資訊的醫療裝置。
您可以使用使用者端的WMM UP標籤,讓存取點在接收到標籤為UP的封包時,將通道外掃描延遲一段可設定的時間。若要為特定WLAN設定此功能,請使用以下控制器CLI指令:
config wlan channel-scan defer-priority priority [enable | disable] WLAN-id
其中priority = 0到7表示使用者優先順序。在客戶端和WLAN上,此值必須設定為6。
使用此命令可配置在隊列中的UP資料包之後延遲掃描的時間量:
config wlan channel-scan defer-time msec WLAN-id
輸入時間值(毫秒)。有效範圍是100 (預設)到60000 (60秒)。此設定必須符合無線LAN上的裝置要求。
您也可以在控制器GUI上設定此功能。選擇WLAN,然後編輯現有的WLAN或建立一個新的WLAN。在「WLANs > Edit」頁上,按一下Advanced頁籤。在Off Channel Scanning Defer下,選擇掃描延遲優先順序,然後輸入延遲時間(以毫秒為單位)。
注意:通道外掃描對於RRM的操作非常重要,RRM收集有關替代通道選擇的資訊,例如雜訊和干擾。此外,通道外掃描負責欺詐檢測。需要延遲通道外掃描的裝置必須儘可能經常使用相同的WLAN。如果存在許多此類裝置,並且存在使用此功能可以完全停用通道外掃描的可能性,則必須實施本地AP通道外掃描的替代方案,例如監控存取點或相同位置中未分配此WLAN的其他存取點。
將QoS策略(銅牌、銀牌、金牌和白金)分配給WLAN會影響從存取點到下行鏈路連線的標籤方式,無論從客戶端上行鏈路收到資料包的方式如何。UP=1,2是最低優先順序,UP=0,3是下一個較高優先順序。以下是每個QoS策略的標籤結果:
銅牌標籤所有下行鏈路流量至UP= 1
銀色標籤所有下行鏈路流量至UP= 0
Gold標籤所有下行鏈路流量至UP=4
白金標籤所有下行鏈路流量至UP=6
修訂 | 發佈日期 | 意見 |
---|---|---|
1.0 |
07-Feb-2014 |
初始版本 |