寫給自己看的中文整理版，使用很多的 chatgpt + google 翻譯。

沒有完全照翻，沒有全翻。

圖片表格數學公式等都對照 paper，沒有放。

看了完全沒感覺不知所云的也沒放...

 

簡單講：

本文使用 Wi-Fi 搭配 SDN 提出三個演算法，將無線流量負載從延遲較高的物聯網設備轉移到負載最低的接入點 (AP)」，確保負載公平性，降低延遲率，提高吞吐量，在智慧城市中實現讓人滿意的 QoS。

 

paper: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10244031

 

ABSTRACT

Wi-Fi 網路是智慧城市物聯網 (Internet-of-Things, IoT) 中主要的無線技術。

智慧城市中運行著多種服務和應用，對服務品質 (quality of service, QoS) 的要求也各不相同，本文重點解決延遲問題。

Wi-Fi 網路搭配軟體定義網路 (Software-defined Networking, SDN) 可確保 AP (access point) 之間流量負載的公平性並降低封包延遲率。

本文中設計了三種軟體定義演算法：基於服務時間 (網路處理封包的時間)、M/G/1 分析和 AP 選擇，分別確定封包傳輸延遲、封包延遲率和選擇負載最小的目標 AP。

本文中也開發了基於 Linux 的軟體定義測試平台，以確保演算法的可信度。

所提出的方案將無線流量負載從延遲較高的物聯網設備轉移到負載最低的接入點 (AP)，與接收訊號強度指示器方案 (received signal strength indicator scheme, RSSI)、Po-Fi 方案和聚合 Wi-Fi 方案 (aggregated Wi-Fi scheme) 相比，降低延遲率並將吞吐量提高 17%、13% 和 9%。

 

1. Introduction

Wi-Fi 網路因其網路建設成本低、技術實現簡單，在生活中日益普及。

AP 提供對 Internet 的訪問，是構成 Wi-Fi 網路的主要組件。

AP 的自發部署會導致網路資源利用率不平衡 (有些可能過載，有些則無法充分利用資源)。

 

來自物聯網設備的感測器資料通過 Wi-Fi 網路傳輸到指定位置。即使封包可能位於重疊的 Wi-Fi 覆蓋區域，物聯網設備仍需要確保他們的延遲不超過某一閾值。

當有些 AP 持續接收正常的管理員流量，有些則因延遲敏感流量 (包含重要、緊急資訊，如醫療相關的流量) 而過載時，這種情況需要採用自適應網路配置，將發送延遲敏感資訊的物聯網設備連接到負載較輕的 AP [14]。而這在 IEEE 802.11 網路中難以實現。

一種新的網路架構，SDN (software define network, 軟體定義網路)，可以解決這種問題[15]。

在 SDN 中，資料平面與控制平面分離，使網路管理員能夠全面了解網路情況，可以在無需更改硬體的情況下輕鬆安裝應用程式於無線網路中。

SDN 具有根據網路條件動態配置無線網路資源的能力[16]，其簡化了無線網路的複雜性，例如未來的 6G 網路或 Wi-Fi 網路。

 

在傳統的 Wi-Fi 網路中，關聯決策是由無線設備基於接收到的訊號強度指示器 (received signal strength indicator, RSSI) 來製定，但此時訊號最強的 AP 可能已經過載，提供了最少的 Internet 訪問，故這種方式不能保證吞吐量。

在提出的工作中，關聯決策是 SDN 控制器根據負載平衡應用程式接收到的 AP 報告而製定，通過執行切換操作來確保 AP 之間的負載公平性，實現最低的封包延遲率。

智能城市設計包括多個覆蓋重疊的 AP，形成一個密集 Wi-Fi 網路場景，其中包含移動的 IoT 設備。

IoT 設備連接到支援 OpenFlow 的 AP 以訪問網際網路。

 

提出的研究介紹了基於服務時間估計、M/G/1 分析和選擇最輕負載 AP 的三種演算法。其目的是在保持 AP 之間的負載對稱性的同時減少滿足 QoS 的端到端延遲。

 

2. RELATED WORK

表2中顯示了一個詳細的比較表格。該表格將提出的方案與以前在 Wi-Fi 網路負載平衡領域進行的研究工作進行了比較。

據我們所知，這是第一個在智能城市環境中使用測試平台 (testbed)， 最小化物聯網設備傳輸到多個 AP 的封包延遲率的標準化研究。

已安裝的 APs 在多個無線電頻道上運行。 SDN 控制器負責維護從物聯網設備傳輸到 AP 的封包延遲閾值。

由於 SDN 控制器具有對網路的全面了解，它會通過將具有最高端到端延遲的 IoT 設備移交給負載最輕的 AP 來降低封包延遲。

 

3. NETWORK MODEL

所提出的網路模型中，所有 AP 都具有重疊的覆蓋範圍，用以構建一個覆蓋整個城市的密集 Wi-Fi 網路，如圖1所示。

城市中包含人類與機器生成的流量，所有流量都通過連接到 SDN 控制器的 OpenFlow 啟用的 AP 進行路由。

(不是很確定翻成啟用對不對，可能翻成支援也正確?)

 

在 SDN 中，負載平衡應用程式可確保 AP 之間的負載公平性，從而減少封包的延遲。

負載平衡應用程式的控制由應用層面負責，應用層面透過簡單網路管理協議 (simple network management protocol, SNMP) 收集來自 OpenFlow 啟用的 AP 的所有封包資訊，而後由 SDN 控制器進行與負載平衡相關的計算。

控制平面包括 SDN 控制器或多個控制器，它們通過 OpenFlow 協議與所有 AP 通信，OpenFlow 在此處充當 AP 和控制器之間資訊交換的橋樑。

資料平面生成所有無線流量的轉發設備，無線流量則是通過 AP 路由到 SDN 控制器。

在 beacon frame 的 reply and response 過程中，設備的媒體訪問控制 (media access control, MAC) 地址也通過 OpenFlow 協議傳遞給 SDN 控制器，從而允許 SDN 控制器將無線設備從一個 AP 中解除關聯，然後重新關聯到負載最輕的 AP。

 

4. ALGORITHM DESIGNS

本節描述了三種提出的演算法的設計。

第一個演算法的設計基於封包傳遞時間估算，第二個演算法的設計基於佇列分析 (queuing analysis) 理論。

通過前兩個演算法選擇具有最高的端到端延遲率的 IoT 設備後，它將被移交給 (由第三個演算法獲得的) 負載最輕的 AP。

 

A. ESTIMATION OF SERVICE TIME

IoT 設備的端到端封包延遲 = 佇列延遲 + 服務時間。

服務時間是網路處理封包的時間，佇列延遲隨服務時間和封包到達速率而變化。在提出的方案中，所有到達過程的速率都保持相同，並假定所有過程也都相似。

當網路操作區域遠離飽和區域時，佇列延遲與服務時間相比可以忽略不計。因此，端到端延遲直接取決於服務時間，服務時間越長，端到端延遲越長。

Algorithm 1 Estimation of Service Time

1: 接收封包。
2: 計算每個 IoT 設備的到達時間間隔的標準差和平均值。
3: 選擇平均到達時間最長的 IoT 設備。
4: if 有多個 IoT 設備具有最大的平均到達時間 then
5: 　選擇標準差最大的 IoT 設備。
6: 　將其切換到負載最輕的啟用 OpenFlow 的 AP。
7: else
8: 　將其切換到負載最輕的啟用 OpenFlow 的 AP。
9: 　if 平均到達時間沒有減小 then
　　　　.
10: 　 (repeat step 2) 計算每個 IoT 設備的到達時間間隔的標準差和平均值。
11:  else
12: 　　if 有新的 IoT 設備加入網路並且 AP 負載不平衡 then
　　　　　　.
13: 　　 　計算每個 IoT 設備的到達時間間隔的標準差和平均值。
14: 　　else
15: 　　 　檢查是否有新的 IoT 設備加入網路並且 AP 負載不平衡。
16: 　　end if
17: 　end if
18: end if

 

B. M/G/1 ANALYSIS

無線流量來自多個 IoT 設備。使用 Poisson arrival process 對聚合的無線流量進行近似建模。

Algorithm 2 M/G/1 Analysis

1: 接收封包。
2: 計算每個 IoT 設備的到達時間間隔的標準差和平均值。
3: 使用等式4中的 PK 公式，估算每個 IoT 設備的端到端延遲。
4: 選擇端到端延遲最高的 IoT 設備。
5: 將其切換到負載最輕的啟用 OpenFlow 的 AP。
6: if 有多個 IoT 設備具有最大的平均到達時間 then
　　 .
7: 　計算每個 IoT 設備的到達時間間隔的標準差和平均值。
8: else
9: 　if 如果有新的 IoT 設備加入網路並且 AP 負載不平衡 then
　　　　  .
10: 　　 計算每個 IoT 設備的到達時間間隔的標準差和平均值。
11: 　else
12: 　　 檢查是否有新的 IoT 設備加入網路並且 AP 負載不平衡。
13: 　end if
14: end if

 

C. FINDING THE LEAST LOADED AP

一旦找到了負載最輕的 AP，SDN 控制器就會啟動切換：將平均到達時間最長或端到端延遲最長的 IoT 設備，切換到負載最輕的 AP。

Algorithm 3 Finding the Least Loaded AP

1: 接收封包。
2: 增加從 AP 接收的封包計數，同時記錄封包來自的 AP。
3: 計算每個 IoT 設備的到達時間間隔的標準差和平均值。
4: 選擇平均到達時間最長的 IoT 設備。
5: if 有多個 IoT 設備具有最大的平均到達時間 then
　　　 .
6: 　　選擇標準差最高的 IoT 設備。
7: 　　選擇封包計數最小的 AP。
8: 　　將 IoT 設備切換到所選的啟用 OpenFlow 的 AP。
9: else
10: 　 選擇封包計數最小的 AP。
11: 　 將其切換到所選的啟用 OpenFlow 的 AP。
12: if 如果平均到達時間沒有最小化 then
　　 　.
13: 　計算每個 IoT 設備的到達時間間隔的標準差和平均值。
14: else
15: 　 if 有新的 IoT 設備加入網路並且 AP 負載不平衡 then
　　　　　  .
16: 　　　 計算每個 IoT 設備的到達時間間隔的標準差和平均值。
17: 　 else
18: 　　　 檢查是否有新的 IoT 設備加入網路並且 AP 負載不平衡。
19: 　　end if
20: 　end if
21: end if

 

5. EXPERIMENTAL PLATFORM

乾貨都在這了，看了但沒看懂。

 

6. PERFORMANCE EVALUATION

本部分介紹了三種提出的演算法的性能評估。

 

A. SD-WI-FI IMPLEMENTATION

實時測試平台與仿真 (emulation) 平台在許多方面存在差異。

在仿真平台中，通常會忽略訊號衰落和頻道干擾。然而，當涉及到測試平台時，這些因素具有重要意義。

在開發原型測試平台時需要更多的開發工作。與模擬 (simulation)/仿真 (emulation) 平台相比，製作測試平台的成本較高。

 

B. CHALLENGES AND LIMITATIONS

在本研究中，OpenFlow 標準已擴展到了無線網路，而在過去它僅用於有線網路。

為了在智能城市環境中實現 QoS，圖4中顯示了 OpenFlow 擴展訊息格式。

負載 (payload) 說明了三種提出的演算法的工作原理。

（1、2看圖即可）

用於服務時間的負載 (payload) 傳輸了來自 AP 到 SDN 控制器的標準差和到達時間資訊。

這些區塊 (field) 還攜帶了服務集標識符 (service set ID, ssid)、守護進程進程標識符 (daemon process ID, Dpid) 和接入介質控制 (media access control, MAC) 地址的資訊。

M/G/1_prefix@ 與用於服務時間的有效負載類似，不同之處在於它攜帶了 PK 公式的資訊以及平均負載等級。

最後的有效負載 AP_prefix@ 用於查找最小負載的 AP。它攜帶了關聯和取消關聯的資訊，包含了過載 AP 和最低負載 AP 的 MAC 地址及這些 AP 的 IoT 設備的 MAC 地址。

 

我們使用了每秒 400 到 600 個封包的傳輸速率，以確保 SD-Wi-Fi 處於高負載狀態，但在真實的測試平台上，IoT 設備並不總是在傳輸封包，因此需要為 IoT 設備設計額外的感知功能。 MAC 頭幀控制域 (MAC header frame control domain) 如圖5所示。

第 11 位表示重傳指示器。每當幀 (frame) 被重新傳輸時，重傳指示器就會被設為 1。 AP 通過檢查接收到的幀的重傳指示器來確定封包的重傳情況。重傳指示器也被添加到 OpenFlow 標準負載 (payloads) 中，以支持 IoT 設備的額外感知功能。

 

C. EFFECT OF SERVICE TIME ON HANDOFFS

(1) TRANSMISSION RATE OF 400 TO 500 PACKETS/S

我們使用了三個性能指標評估基於服務時間的演算法的性能。

第一個性能指標是關於端到端封包延遲與可變流量速率下的切換的比較。

圖6(a)顯示，在切換後，端到端封包延遲明顯減小，特別是當流量速率 (如 Eq.2 所解釋的那樣) 較高時。

第二個性能指標比較了端到端封包延遲和 SDN 控制器接收到的 Packet_In 事件的到達間隔時間。

圖6(b)顯示了不同流量速率的比較。

第三個性能指標驗證了實時切換所需的服務時間演算法的應用。切換的端到端延遲由終端用戶 (end user) 使用智能設備記錄（理想情況下）。

從圖6(c)中可以看出，當使用所提出的演算法時，差異百分比隨著流量速率的增加而減少，證明了該算法的可信度。

 

(2) TRANSMISSION RATE OF 500 TO 600 PACKETS/S

我們通過增加封包速率加重網路負載。

在第二組實驗中，切換前後的端到端延遲有明顯差異，如圖7(a)所示。

由於 Packet_In 事件到達 SDN 控制器的間隔時間發生變化，因此觀察到端到端延遲發生顯著差異，如圖7(b)所示。

因為減少了重新傳輸，並通過計算 Packet_In 事件的數量來估算服務時間，顯著減少了進行手動切換後物聯網設備的端到端封包延遲。

從圖6(b)和圖7(b)可以得出的另一個結論是，當流量速率保持不變時，可以通過計算在 SDN 控制器接收到的 Packet_In 事件的到達時間來計算目標物聯網設備的端到端封包延遲。

網路流量的增加會推動網路接近飽和狀態，帶來更高的退避時間，使得端到端延遲更加依賴於服務時間的變化。

 

D. EFFECT OF M/G/1 ANALYSIS ON HANDOFFS

(1) TRANSMISSION RATE OF 400 TO 500 PACKETS/S

本節透過觀察端到端延遲隨封包速率變化的情況，評估 M/G/1 Analysis 演算法的性能。

圖8(a)描述了演算法的可信度，即在切換後端到端封包延遲迅速減小。

在使用 Poisson 分佈 (distribution) 的流量來改變 SDN 控制器接收到的 Packet_In 事件的到達時間時，情況並不相同，如圖8(b)所示。

因此，在到達率保持不變的情況下，端到端封包延遲沒有太大變化，如圖6(b)所示。

 

(2) TRANSMISSION RATE OF 500 TO 600 PACKETS/S

在使用增加封包速率來加載網路的情況下，提出的演算法的性能以端到端封包延遲為評估指標，如圖9(a)和圖9(b)所示。

從圖9(a)可以看出，切換之後，端到端封包延遲減少了。增加網路流量後，切換前後，端到端封包延遲的差異相對較小。這確保了所提出的演算法實現了平滑的切換。

通過改變 SDN 控制器接收的 Packet_In 事件的到達時間，對端到端封包延遲的影響可以忽略不計，如圖9(b)所示。

由於 Poisson 流量的性質，共享的 IEEE 802.11 頻道中的佇列延遲對端到端延遲的影響大於服務時間，故：在使用 M/G/1 分析進行切換時，對於封包到達時間事件沒有影響。

 

E. HANDOFF TO A LEAST LOADED AP

圖10 (a) 和圖10 (b) 顯示了擇最低負載的 AP 的演算法的性能評估。

性能比較在所提出的演算法和通過隨機選擇目標 AP 為 IoT 設備測量切換前後端到端延遲的演算法之間進行。

從研究結果可以明顯看出，在提出的演算法中，切換前後的端到端延遲明顯優於隨機選擇目標 AP 的演算法。

SDN 控制器通過計算每個 AP 上的無線流量負載來選擇最低負載的 AP。故其決策會影響端到端封包延遲和頻道容量。而由於 IoT 設備會持續向 SDN 控制器報告其資料，因此提出的演算法不受 IoT 設備移動性的影響。

 

F. AGGREGATE THROUGHPUT

本文對提出的方案與傳統的 RSSI (Received signal strength indicator) 方案、Po-Fi 方案[36]和聚合 (aggregated) Wi-Fi 方案[37] 進行了比較。

所提出的演算法專門設計用於監視延遲性能，只有吞吐量較佳並保證訪問網際網路的目標 AP 才會使用 SDN 進行切換。

在所提出的方案中，與 RSSI、Po-Fi 和聚合 Wi-Fi 方案相比，聚合吞吐量分別提高了 17%、 13% 和 9%。

 

7. CONCLUSION

所提出的研究利用 SDN 的能力，以確保在智能城市設計中的 OpenFlow 啟用的 AP 之間的負載公平性，同時與 RSSI (Received signal strength indicator) 、Po-Fi 方案和聚合 Wi-Fi 方案相比，減少端到端封包延遲 17%、13% 和 9%，從而提高了吞吐量。

SDN 控制器上安裝了負載平衡的應用程式，該應用程式會收集 AP 報告並進行網路範圍的計算，通過執行切換來確保 AP 之間的負載公平性。

所提出的研究引入了三種基於服務時間估算、M/G/1 分析和選擇最小負載 AP 的演算法，旨在在保持 AP 之間的負載對稱性的同時，降低端到端延遲，實現滿意的 QoS。

我們期待引入人工智能 (artificial intelligence, AI) 到 OpenFlow 啟用的 AP 中，使其能夠在特定負載水平下自行進行切換決策。 AI 將有助於進行服務區分，並優先處理對控制器更為敏感的封包，從而改善延遲因素。

====================

後面幾頁有些地方不確定是真的看不懂或是原文打錯，我有自己改成 (自以為) 合理的意思。