轉載：https://www.cnblogs.com/gierwu-wirelessIoT/p/8596057.html

1 概述

　　WiFI TDMA領域，2009年Sam  Leffler在《TDMA for Long Distance Wireless Networks》首次系統提出了TDMA技術方案，並在FreeBSD上，基於Atheros公司的AR5212晶片，成功實現了IBSS架構的TDMA Demo。

　    I. Hussain，N. Sarma和D. K. Saikia與2014年在《TDMA MAC Protocols for WiFi-based Long Distance --Networks: A Survey》中，對當時已有的WiFi TDMA進行總結，並歸納如下：

　　此外，市場上支援TDMA類的WiFi產品，成功的有UBNT的Airmax、Cambium的 TDD和Mikrotik的NV2；另外，LogicWave的iPoll技術，也包含有TDMA的部分功效。

       基於公開的資料，具體說來，基於Soft MAC的TDMA技術為主流，它們都強調嚴格TDMA規範，所以在時隙劃分、時間同步以及現有WiFi的DCF功能修改上工作量特別大；而網上可查詢到的基於Openwrt工程程式碼的TDMA技術文件，均在陷入超幀、時隙與時隙機會、靜默與活動的處理中，最終出來的是基於一個固定速率、固定包長的ns2 Demo或openwrt Demo，無法融入商用產品。

　　更惱火的是，主流的WiFi晶片方案商，長久以來都沒有推出成熟的TDMA功能，或選擇性的僅支援少量客戶開發自己的TDMA。從而導致TDMA over WiFi這個簡單且實用的技術在諸多WiFi產品中難實現。直到最近的QCA在其新一代的11AC WaveII 晶片上，終於推出了一個PCF版的功能外掛，部分實現了TDMA。但對於老方案，該PCF功能並不能起作用。由此導致，基於方案商的SDK專案程式碼，開發不出TDMA功能。

　　為了區別於現有的WiFi TDMA技術，本系列文件中將TDMA規範強制挪動到WiFi驅動的實現方式為“Fat TDMA WiFi”，而我們將研究和開發出來的為“Fit TDMA WiFi”。所謂的“Fit TDMA WiFi”，就是在SDK專案程式碼上，實現TDMA WiFi功能，不大幅度修改現有驅動程式碼，能持續保留現有的核心功能：如支援802.11n和802.11ac，支援速率協商等；可直接商用。

2 Fit TDMA WiFi 願景

• 單點排程

        TDMA_er為排程者，迴圈排程各TDMA_ee， 預設地，TDMA_er由AP承擔，TDMA_ee由CPE承擔，且AP僅能排程已關聯到其上的CPE。

• 排程方式

　　“加權公平排程”，所謂“公平排程”，就是TDMA_er公平地排程各TDMA_ee，如每輪排程，確保每個TDMA_ee都能被排程1次，且時間窗均等；所謂“加權”，就是讓不同通訊鏈路質量的TDMA_ee，有不同的排程次數，從而能持續維持訊號質量高的終端具有更佳地通訊體驗。

• 相容TDMA與嚴格TDMA策略

　　相容TDMA策略下，非TDMA終端允許接入本Fit TDMA WiFi，TDMA_er不丟棄源自非活動TDMA_ee的資料報文；嚴格TDMA策略下，非TDMA終端不允許接入Fit TDMA WiFi，且TDMA_er直接丟棄源自非活動TDMA_ee的資料報文。

　　綜述，Fit TDMA WiFi本質就是一個收發資料報文的排程機制，所以它不會被現有的TDMA思維所限制，是可基於SDK驅動程式碼實現的。

3 收發流程分析與改進

　　收發流程分析涉及到具體程式碼，屬於SDK驅動內容，不能完全公開，僅供參考，本系列文件中涉及到具體功能或程式碼時，請在自己的驅動程式碼中查詢。

　　QCA驅動從9.5開始，將原來的htc的功能重構了一下，分成Direct Attach（DA）和Offload（OL）兩大部分，前者支援Mips架構的所有SOC，以及非11AC 網絡卡；後者支援ARM體系的SOC，以及11AC網絡卡。

　　本內容主要以DA架構為主，OL架構只提及，OL架構的收發流程在MAC層上與DA架構類似。

3.1 流程簡述

　　本小節僅涉及資料報文收發流程中與Fit-TDMA相關的關鍵部分，不重複QCA PDF中tx和rx flow。　　

• TX流程簡述

　　TX起始於dev_xmit_queue，然後會走到ath_tx_send_normal或ath_tx_send_ampdu，在ath_tx_send_XXX（normal或ampdu）中，直接呼叫ath_tx_txqaddbuf直接提交到HAL的硬體佇列，由硬體傳送；或者有ath_tx_queue_tid臨時快取到tid佇列中，通過ath_txq_schedule，將報文提交的HAL的硬體佇列傳送。所述tid佇列為軟佇列，一共有17個，其中0~15與DSCP域值對應，而16為管理與控制幀佇列（不包含信標幀）。所述硬體佇列，一共有10，其中0-3號與17個tid佇列對映，也就是0-3號佇列為資料佇列，它們的優先順序與WMM的4個AC的優先等級一一對應；9號佇列為信標幀佇列；隊號越高，在硬體中的傳送優先順序越高。

　　TX傳送完畢後，由ath_tx_complete_buf負責完成收尾工作，如更新統計、回收資源等。

• RX流程簡述

　　RX起始於ath_intr，然後走到ath_rx_process，再然後走到Ieee80211_input，最後會osif_receive處理，是提交的網路協議棧還是直接完成報文接收。在此流程中，資料報文會被ath_net80211_rx處理。

3.2 流程修改

　　基於TX流程，直接傳送函式是ath_tx_send_normal和ath_tx_send_ampdu，直接排程函式是ath_txq_schedule（內部直接呼叫ath_tx_sched_aggr或ath_tx_sched_normal）。為了實現Fit-TDMA排程，需要將這3個發現相關的核心功能函式。此外，驅動還有個APONLY的巨集，啟用了該巨集後，報文會從UMA直接跳轉到HAL，繞過了這3個核心函式，因此，在啟用Fit-TDMA功能時，需要關閉此巨集。

　　在ath_tx_send_XXX中，現有邏輯是：如果可直接傳送，則立即呼叫ath_tx_txqaddbuf，將報文直接提交到HAL層傳送。而Fit-TDMA是傳送報文統一排程，因此，我們需要將這個功能關閉，強制報文先進入tid佇列，然後通過ath_txq_schedule來排程。而在ath_txq_schedule中，現有邏輯是：如果待排程的tid未阻塞，則將該tid的報文，通過ath_tx_sched_aggr 或ath_tx_sched_normal提交的HAL傳送之。顯然，在tid粒度級上的排程，是不符合Fit-TDMA排程預期的。Fit-TDMA排程是目標終端級粒度的排程。因此，在ath_txq_schedule中，在驗證當前tid為非阻塞後，還需要測試tid->an->an_node所指向的目標終端，是否可以傳送（即是否為Fit-TDMA Active態），如果不能傳送，則同樣要將此tid插入paused_tid_q，等待下次排程。

　　進一步地，在實際測試中發現，管理類幀最好不要延時傳送，故在具體實施時，僅當tidno小於16，且ac的qnum小於4時，才測試報文目標終端的狀態；此外，有部分報文的目標終端是VAP自己、或一個廣播地址，這類報文最好也直接放行。另外，如果一個終端已經下線了，但快取的報文還未傳送時，需要直接將該tid所包含的報文空間釋放，並將tid資源回收。

　　此外，還需要注意此狀況：觸發ath_txq_schedule的txq的tid是一個數據包，但因為其目標終端的Fit-TDMA狀態為“等待”，故該報文不能被立即排程到HAL層。此時，如果AP處於低流量工作狀態，例如管理的終端數小於5個，且只是簡單Ping終端。則下一個同tid排程ath_txq_schedule會來的比較慢，導致回包不及時。這樣就會看到ping包時斷時續。簡單的對策是：如果觸發排程的tid是個資料包，但本次排程，未能成功下發一個數據報文時，則立即排程該sc的中sc_txq{0,1,2,3}佇列中其它佇列。這樣，可能會出現：要麼外發一個數據報文，要麼就不能外發資料報文。當不能外發資料報文，則表明當前Fit-TDMA Active態的終端沒有待下發資料報文，應立即通知Fit-TDMA 排程者，請求它將活動令牌傳遞給下一個輪詢終端。

　　最後，為了通知終端可傳送報文，Fit-TDMA 排程者在完成本地活動令牌輪轉後，立即通過管理幀通知目標終端可傳送報文到AP。

　　基於RX流程，直接在ath_net80211_rx函式中處理Fit-TDMA接收邏輯，如果啟用“嚴格TDMA策略“，則針對資料報文，首先驗證發端是否為Fit-TDMA Active態，如果驗證為否，則直接釋放接收到的wbuf。如果啟用“相容TDMA策略“，則繼續啟用現有邏輯。

　　在實際測試中，如果直接丟棄wbuf，則針對無重發保證的網路應用，會造成大量通訊中斷。如ping包會丟得一沓糊塗。

　　OL架構中，傳送修改點在ol_tx_send函式中，接收修改點在ol_rx_indication_handler，因為網絡卡級的收發均在黑盒子的FW中，所以目前在offload目錄下的驅動修改效果均不好，留待繼續改進或換方案。

4 TDMA 排程者

　　TDMA排程者為Fit-TDMA的決策功能體，屬於新開發功能模組，分排程員和被排程者2種角色，其中前者執行在AP等匯聚裝置上，後者執行在CPE等接入類裝置上；後者必須與前者配合才能工作，而前者可以無需後者獨立執行。

　　TDMA排程者適宜作為UMAC模組的的一個子功能，LMAC層通過sc的函式指標呼叫TDMA功能。這樣實現可以簡化難度、提高能效，同時也不破壞現有的驅動架構。

4.1  狀態機

　　TDMA排程功能需要儲存各終端或自己的當前狀態，不同狀態偵聽不同的事件，可以執行不同的行為，因此，需要引入FSM機制。具體的，AP側的FSM描述如下：

　　一共有3種狀態：等待、活動和下線狀態。等待狀態的終端，可以別調度到活動狀態，從而允許將報文傳送到該終端；同時，活動狀態的終端在不同事件後，可變更為等待狀態或下線狀態。處於下線狀態的終端，不會被排程。下線狀態主要用於LMAC層直接丟棄報文、以及TDMA排程模組無需頻繁刪除和生產終端節點。

　　CPE端的狀態機描述如下：

　　同樣地，CPE側也包含3種狀態：等待、活動和下線狀態。顯然地，只有處於活動狀態，CPE才能向AP傳送資料報文；在轉換為離線狀態後，LMAC層可以將預期傳送次數超過閾值的資料報文丟棄掉，也可以將全部資料報文都直接丟棄。

4.2 核心資料結構

        TDMA排程員和被排程者的核心資料結構是不區分的，具體描述如下：

　　TDMA的核心就是傳送排程，因此排程相關的邏輯結構是最核心的資料結構。在Fit TDMA中，排程鏈共有5級，其中1級為基礎資料級，STA的資訊均包含在此鏈上，為了提高增刪效率，採用雙向鏈結構；第2級到第5級鏈的節點均包含了指向基數資料的指標，採用單向鏈結構，因為針對此類鏈的變更操作不是特別頻繁。排程時，針對每個排程鏈，均是從頭排程到尾，然後在從更高一級的鏈頭開始排程；在L5鏈排程完畢後，再轉Sta鏈頭。這樣可實現：所有節點均能被排程到，且傳送速率更快的節點，可以獲得更多的排程機會。Hash表主要用於查詢，查詢功能用得非常多，而連結串列的查詢效率低，所以增加HASH表來提升查詢速率。LMAC在ath_txq_schedule中需要查詢報文目的節點的狀態、在資料報文傳送成功後更新該節點的傳送速率等，均用到了查詢。

　　關於定時器，AP端和CPE端是不同的，AP端只有一個主定時時間間隔，就是為所有的終端一次排程，均分配4ms時間片，超過此時間片後，定時操作函式會立即排程下一個終端；而CPE的定時時間間隔至少有2個，長時間和短時間。長時間用於等待狀態，因為無法預知活動令牌指示何時到達、或者就是活動令牌指示會未收到但又收到了AP的資料報文，所以，在等待狀態下，還需要定時來觸發檢測工作；短時間週期主要用於活動態，它的主要作用就是向AP傳送返回令牌，同時讓自己進入等待狀態。

 5 Fit TDMA效果

　　在開放環境下，基於QCA9342  HT20模式，每終端跑4條流，啟用Fit TDMA功能後，ping 包時延會由1ms增加到5ms左右，單臺CPE或網絡卡的吞吐量依舊是93Mbps左右，上下行差距不到1M；2臺終端時，吞吐量與1臺終端相同；10臺終端時，總吞吐量降低到90Mpbs；20臺終端時，總吞吐量降低到88Mbps；32臺終端時，總吞吐量降低到84Mbps左右。而如果關閉Fit TDMA功能後，32臺終端的總吞吐量不超過75Mbps。因此，啟用Fit TDMA在多使用者場景下確實有明顯地效果。

　　進一步地，人工造異常，在10臺終端模式下，讓其中的2臺終端摘去天線，並用金屬板蓋住，但同時又保證它能有1-2M的流量。此時，其它8臺終端的流量還能各自維持在8.5M左右，不會越跑越慢；而一旦關閉Fit TDMA，則整體吞吐量會越來越慢，低速終端拖慢全域性流量效果非常明顯。

6 其它

　　在ath_txq_schedule以及HASH查詢中，每增加一條printk列印，ping包時延會增加2-3ms，故在除錯完畢後，請立即關閉此類列印；ah_txq_schedule是帶鎖執行的，不要在類函式中呼叫其他帶鎖執行的函式，除非你能確認不會死鎖；最好不要在現有傳送流程中再次增加需要排程的報文。

　　CPE在啟用Fit TDMA後，未收到AP的活動令牌通知訊息時，是不能向AP傳送資料報文的。故最好遵循：1）AP側將新節點插入到活動排程指標的後邊，這樣保證它會被立即排程，從而能加快DHCP過程；2）CPE側在確認對端AP是支援Fit TDMA後，才是能TDMA。

　　在安全性上，為了防止惡意第3方，AP的Fit TDMA支援信元應與AP和CPE的MAC地址相關，CPE在收到該信元后，基於AP和CPE的MAC地址，利用同樣的演算法，確認信元真實可靠，才能開啟Fit TDMA。