任君玉，祝長鴻，廖棟森，萬海斌，覃團發(fā)

1.華南理工大學 電子與信息學院，廣州510641

2.廣西大學 行健文理學院，南寧530005

3.廣西大學 計算機與電子信息學院，南寧530004

4.廣西多媒體通信與網絡技術重點實驗室，南寧530004

近幾年，隨著物聯網（Internet of Things，IoT）技術的發(fā)展，其底層技術無線傳感網（Wireless Sensor Networks，WSN）得到了快速發(fā)展。作為生物和智慧醫(yī)療領域的一種特殊類型的無線傳感網，無線體域網（Wireless Body Area Network，WBAN）已經得到了社會各個部門，包括學術界、工業(yè)界及政府部門的廣泛關注[1-2]。體域網一般由部署在體內、體表或體表附近的傳感器構成，這些傳感器可以獲取人體的體溫、血壓、血氧、腦電圖、心電圖等各項生理參數[3]。各個傳感器將收集到的生理參數通過無線通信發(fā)送到體域網網關設備HUB（典型設備如手機），HUB再通過蜂窩網或者因特網發(fā)給急救中心或醫(yī)生以進一步采取診療方案。

體域網所采集的是人體健康生理參數，因此對系統(tǒng)可靠性有較高要求；另外，體域網數據時延敏感，尤其當病人情況緊急的時候，對系統(tǒng)時延有極高要求；并且，體域網傳感器由于需要周期性采集人體生理數據，數據量巨大。但是，由于體域網網關節(jié)點資源有限，導致其不方便對所收集的大量人體生理數據進行存儲，更無法對計算密集型任務進行分析。因此，體域網作為智慧醫(yī)療系統(tǒng)的底層網絡架構，必須引入新的范式及有效的解決方案以完成體域網海量數據可靠、實時的存儲與分析。目前，云計算、霧計算技術已經成為研究熱點，這為基于體域網的智慧醫(yī)療系統(tǒng)的研究與落地應用提供了機遇。

云計算技術相對比較成熟，可以提供無限的計算和存儲能力，目前已經有不少工作將云計算與IoT技術相結合進行研究，以解決來自IoT設備的海量數據存儲與處理問題。體域網作為IoT技術的一個具體應用，可以將云計算與體域網技術結合起來，以解決體域網海量數據的存儲問題及體域網的大數據分析與處理，輔助完成遠程醫(yī)療診斷及病人身體狀況與疾病的預測及分析[4-9]。但是，由于云的地理位置較遠，數據傳輸時延大，導致其無法對體域網數據進行實時處理與分析，這對于時延敏感的醫(yī)療健康應用系統(tǒng)尤其是緊急情況下的數據分析與處理帶來巨大挑戰(zhàn)。

霧計算介于云層與終端設備層之間，并且在地理位置上更靠近于用戶終端設備。霧計算技術本質上是將云的計算和存儲能力擴展到網絡的邊緣，通過計算卸載可以為低時延任務執(zhí)行提供解決方案[10-12]。因此，在時延敏感的IoT系統(tǒng)中利用霧計算技術，可以有效解決數據實時傳輸與處理的問題。文獻[13]針對將霧計算技術應用到醫(yī)療物聯網生態(tài)系統(tǒng)中存在的技術和挑戰(zhàn)問題進行了綜述。文獻[14]采用基于云、霧結合的網絡架構，主要解決危重病人的數據處理時延問題，根據人體生理參數臨界值，本地處理單元采用博弈論討價還價的方法對體域網傳感器數據的傳輸進行決策，決定數據傳輸到云還是霧，與基于傳統(tǒng)的云計算方法相比，該方法無論在功耗還是數據傳輸時延方面都更低。文獻[15]研究人體生理指標參數特征提取問題，通過在智能網關設備中集成霧計算層進行心電圖特征提取，可以獲得更快的系統(tǒng)響應，滿足低時延處理需求。

此外，在霧計算輔助的IoT環(huán)境下，如何合理有效地利用霧計算資源也是目前的一個研究熱點，相關的工作大多是關于任務卸載策略優(yōu)化問題的研究。根據不同的應用特點及需求，設計不同的任務卸載策略，很多研究工作利用博弈論的方法進行策略優(yōu)化。然而，目前基于霧計算的體域網任務卸載相關研究尚不多見。

將體域網與霧計算技術進行結合，可以滿足體域網的低時延需求。在這種情況下，資源受限的體域網網關節(jié)點可將其收集的病人體內的生理數據處理成可卸載任務，然后按照一定的策略將任務與數據卸載到霧計算節(jié)點，由霧計算節(jié)點完成相應的任務處理和數據存儲，最終將結果提供給相關的醫(yī)療機構及體域網用戶進行讀取以對疾病進行輔助診療。文獻[16]提出基于霧計算輔助的體域網數據交付協議，根據該協議，體域網網關設備選擇時延低與可靠性高的霧節(jié)點進行數據交付。但是該方法的參數權值不能自適應調節(jié)，尤其是沒有考慮到病人在緊急狀態(tài)時對數據處理時延的高度敏感性，因此不適用于緊急情況。

受以上工作啟發(fā)，本文提出基于霧計算輔助的體域網任務卸載方法以降低體域網數據處理時延。為了滿足緊急任務的高度時延敏感性，在本方案中，對緊急任務采用搶占式任務調度，從而避免了由于排隊帶來的時延；同時，目標霧節(jié)點將分配全部CPU資源對該任務進行處理，以降低緊急任務總時延。因而，對于緊急任務，本文所設計方案的總時延大大降低。此外，所設計的方案可以根據任務的不同（緊急與否），自適應調整目標節(jié)點評價尺度，當任務緊急時，以時延及負載最低為評價尺度進行優(yōu)化選擇目標評價霧節(jié)點；當任務非緊急時，以時延及可靠性為目標節(jié)點評價尺度，選擇最佳目標霧節(jié)點，從而確保系統(tǒng)的實時性及可靠性。因此，相對文獻[16]，本文所設計的方案不僅能夠很好地適應緊急情況下的低時延應用需求而且還可以根據任務是否緊急，自適應調整優(yōu)化目標以選擇最佳任務處理目標霧節(jié)點。

本文的主要貢獻有三個方面：

（1）提出霧計算輔助的體域網智慧醫(yī)療系統(tǒng)架構。利用霧計算技術實現體域網人體生理參數的實時處理，設計了相應的體域網任務卸載算法并進行仿真分析，仿真結果與理論分析結果一致。

（2）設計了目標霧節(jié)點的多目標選擇評價算法。算法綜合引入時延、接收信號強度、負載作為目標節(jié)點評價尺度，能夠根據任務的緊急性自適應調節(jié)相關評價尺度。

（3）根據來自體域網網關節(jié)點的任務的不同特征，目標霧計算節(jié)點采取不同的任務處理策略。如果任務緊急，則對該任務進行搶占式優(yōu)先調度；否則，需要按照先到先服務（First Come First Served，FCFS）的調度策略進行排隊，只有等目標霧計算節(jié)點隊列中的任務處理完后才可以對該任務進行處理。

1 系統(tǒng)模型及工作原理

下面將對本文方案所采用的系統(tǒng)模型、工作原理及算法進行介紹。

1.1 系統(tǒng)模型

假設系統(tǒng)中有K個霧計算服務節(jié)點F,F={Fj|j=1,2,…,K}，HUB為體域網網關節(jié)點，系統(tǒng)模型如圖1所示。

圖1 系統(tǒng)模型Fig.1 System model

1.2 系統(tǒng)工作原理

當病人的體域網網關節(jié)點Hi的任務需要卸載時，按如下步驟選擇任務處理目標霧節(jié)點。為了更加直觀表示，圖2給出了系統(tǒng)工作流程圖。

圖2 系統(tǒng)工作流程Fig.2 System working flow

（1）廣播HELLO消息，格式為HELLO：(Di,Tth)。其中，Di代表卸載任務的數據量，Tth代表超時時間閾值。

（2）周圍的霧節(jié)點Fj收到消息以后，檢查其存儲空間是否足夠。若，則不回復消息；若則向Hi發(fā)送ECHO消息。其格式為其中，RSSIj代表接收到的信號強度，Bj代表剩余帶寬，代表Fj的計算能力（每秒CPU周期數），LFj代表Fj的位置坐標；表示Fj的任務執(zhí)行隊列中的第l個任務Ql所需要的CPU周期數，代表Fj對第l個任務Ql所分配的CPU比率，Lj代表Fj中正在排隊的任務數；代表Fj分配給該任務的CPU比率，λj表示Fj節(jié)點提供服務的價格指數（為方便分析，本文假定所有霧節(jié)點的價格指數均為1，即λj=λ=1）。

（3）Hi對Tth時間之內回復ECHO消息的節(jié)點進行統(tǒng)計，建立節(jié)點集合Si={Fj|j∈Z+}。

（4）Hi按照式（1）計算Si中的每個節(jié)點Fj(j=1,2,…,num(Si))處理請求任務的耗時，num(Si)表示集合Si的大小。

其中，Ci代表執(zhí)行Hi節(jié)點的任務所需要的CPU周期數，Di代表卸載任務的數據量表示Hi到霧節(jié)點Fj的數據傳輸速率：

其中，pHi表示HUB的發(fā)射功率，σ2表示噪聲干擾功率表示來自其他移動終端的干擾，Hij代表Hi與Fj之間的信道增益：

其中，αMj代表小規(guī)模衰減系數，dij代表移動體域網網關節(jié)點Hi與霧計算節(jié)點Fj之間的距離，βM代表Hi的信道衰減指數，dmax代表Hi的最大通信距離。

式（1）中的三部分分別對應任務排隊時延、任務處理時延及任務上傳時延（任務處理結果數據量很小，因而任務處理結果的回傳時延很小，此處忽略不計）。其中，ei代表緊急標志位。若任務緊急(ei=1)，該任務在霧計算節(jié)點中進行搶占調度，此時式（1）中的第1項變?yōu)?，因而對于緊急任務而言，可以避免由于排隊造成的時延；并且此時，式（1）的第2項變?yōu)镃i/fjCPU，代表霧節(jié)點將分配全部CPU資源對該緊急任務進行處理，緊急任務的處理時延也因此得到降低。當任務非緊急(ei=0)時，則采用FCFS方式對該任務進行調度，因而非緊急任務存在排隊時延，并且此時式（1）的第2項變?yōu)镃i/εM fjCPU，代表霧節(jié)點僅將εM(εM<1)比率的CPU資源用于該非緊急任務的處理。可見，緊急任務與非緊急任務的時延主要差別來自于排隊時延與處理時延，而傳播時延（式（1）的第3部分）與任務的緊急與否無關，只與任務對應的數據量及HUB節(jié)點的數據傳輸速率有關。

（5）Hi比較各個霧計算節(jié)點處理時延與任務期限TExp的關系。若TExp

（6）分別對Si內的各個霧節(jié)點的時延TT、信號強度RSSI及任務負載按由小到大進行排序，得到對應的集合

其中，TTmin及TTmax分別表示中TT的最小及最大值。

其中，RSSImin及RSSImax分別表示中RSSI的最小及最大值。

（9）按照式（6）對SQ i中各霧節(jié)點隊列中的任務負載總量進行歸一化，得到Q*j：

（10）按照式（7）計算Si中每個霧節(jié)點的適應度函數：

（11）按照式（8）選擇目標霧節(jié)點Ft：

2 仿真與分析

2.1 仿真環(huán)境設置

假設霧節(jié)點均勻分布于5 km×3 km的平面區(qū)域內，體域網網關節(jié)點HUB隨機移動。采用MATLAB對所提出的算法進行仿真。分別對不同節(jié)點的時延、系統(tǒng)可靠性、吞吐量指標進行仿真分析，仿真參數設置如表1所示。

表1 仿真參數Table 1 Simulation parameters

2.2 能耗分析

當任務在體域網網關節(jié)點HUB本地執(zhí)行時，其能耗Elocal為：

其中，pexec為手機執(zhí)行功率，Texec為任務執(zhí)行時間，fHUB為HUB的CPU頻率。

當將任務卸載到霧節(jié)點時，HUB的能耗Eoff為：其中，Talg為算法1運行時間，在本文場景下，仿真可得Talg≈1 ms，由于算法引起的能耗很低，相對于任務處理時間，此處忽略不計。

由式（9）、（10），定義卸載因子：

其中，ρ為能效系數，當fHUB、pexec、Rb及pH一定時ρ為常數。參照文獻[17]，可取pexec=0.5 W；同時，假設pH=0.2 W,Rb=4 Mbit/s,此時當γ≥1(Ci≥100Di)時，即任務對于CPU計算資源的要求更高，相對而言，對于數據傳輸所帶來的信道資源要求較低，此任務可定義為計算密集型任務。對體域網網關HUB而言，此時任務在本地執(zhí)行的能耗高于卸載時的能耗，因而應將任務卸載到霧節(jié)點進行處理；反之，當0<γ<1(0

2.3 仿真結果分析

圖3 代表時延與任務所需周期數Ci的關系，并分別給出了霧節(jié)點及目標節(jié)點Ft在緊急(ei=1)及非緊急(ei=0)共4種情況下所對應的曲線圖。

圖3 時延與Ci的關系Fig.3 Relationship of delay with Ci

從圖3中可以看出，隨著Ci的增大，Ft及霧節(jié)點在所有情況下的時延都呈明顯的增大趨勢。同時，對于目標節(jié)點Ft而言，在兩種情況下的時延差別明顯，即在ei=1時的時延明顯低于在ei=0的時延；相對而言，普通霧節(jié)點在ei=1與ei=0兩種情況下的時延相差不太明顯（緊急時的時延均值比非緊急時略低）。并且，無論任務是否緊急，目標節(jié)點Ft的平均時延均低于霧節(jié)點的時延。主要原因在于，當任務緊急時，節(jié)點需要對任務采用搶占式調度方式進行處理，因此無論霧節(jié)點的任務隊列大小，均優(yōu)先進行該任務的處理，這將大大降低緊急任務的處理時延，并且CPU資源全部用于執(zhí)行該任務，也將進一步降低任務時延。而當任務非緊急時，進入霧節(jié)點的任務按照FCFS方式進行調度。此時，隊列中的任務負荷量將直接決定任務處理時延，并且節(jié)點對排隊任務按照一定的比例進行CPU計算資源分配。而在緊急情況下，所有CPU周期將優(yōu)先分配給緊急任務進行處理。

圖4 代表時延與任務數據量Di的關系。圖4（a）、（b）分別給出了當Di變化時，在任務緊急(ei=1)及非緊急(ei=0)兩種情況下，霧節(jié)點及目標霧節(jié)點Ft的時延變化趨勢。

圖4 時延與Di的關系Fig.4 Relationship of delay with Di

由圖4可以得到以下結論：

（1）時延隨機波動。這是由于體域網網關節(jié)點HUB的位置隨機變化，引起HUB與霧節(jié)點之間數據傳輸速率發(fā)生隨機變化，導致隨著Di的增長，任務時延并非按直線規(guī)律線性增長，而是隨機起伏，但總體呈上升趨勢。并且，當Di較小時，時延的變化趨勢并不明顯。但是隨著Di的增大，無論是滿足條件的集合中的霧節(jié)點還是目標霧節(jié)點Ft，其時延總體上都呈現較為明顯的增長趨勢。這是因為，當Di增長到一定程度以后，由其帶來的時延增長將在很大程度上克服系統(tǒng)隨機性所帶來的時延波動，使時延呈總體上升趨勢。

（2）圖4（a）中的時延明顯低于圖4（b）中對應節(jié)點的時延。圖4（a）中，目標霧節(jié)點Ft的時延均值約為3.2 s，霧節(jié)點的時延均值約為6.1 s；圖4（b）中，Ft節(jié)點的時延均值約為4.9 s，霧節(jié)點的時延均值為11.6 s。可見：無論任務是否緊急，目標節(jié)點Ft的時延都小于普通霧節(jié)點的時延，這與理論分析是一致的。并且，在緊急情況下的時延均小于非緊急情況下的時延，主要原因有兩點：第一，緊急時，所有節(jié)點時延主要取決于任務周期數Ci及任務數據量Di，當Ci保持不變，增大Di將從總體上導致時延的增加；在非緊急情況下，節(jié)點時延除了與Ci、Di的值有關，還與節(jié)點隊列中的任務負載量有關系，因此在相同的情況下，若考慮任務負載，相對于緊急情況，必然引起節(jié)點更大的時延。第二，在緊急時算法是以時延最低為主要優(yōu)化目標，而在非緊急時，以時延及可靠性為主要優(yōu)化目標，相當于對時延目標進行了松弛。

（3）對比圖4（a）及圖4（b）可以發(fā)現，隨著Di的增大，Ft節(jié)點在緊急情況相對于非緊急情況下的時延增長速度明顯加快。這是因為節(jié)點將對緊急任務采用搶占式任務處理方式進行調度，不需要由于任務排隊而帶來額外耗時，數據傳輸耗時將在很大程度上影響節(jié)點時延，而在數據傳輸速率一定的情況下，數據傳輸耗時主要取決于任務數據量Di的大小，因此隨著數據量Di的增長，系統(tǒng)時延明顯增大。

圖5 代表當Ci與Di保持不變時，進行多輪仿真得到的時延情況。圖5（a）、（b）分別給出了在任務非緊急(ei=0)及緊急(ei=1)兩種情況下，霧節(jié)點及目標Ft節(jié)點的時延變化情況。不難發(fā)現，在兩種情況下，Ft節(jié)點的時延均明顯低于霧節(jié)點的平均時延；同時，所有節(jié)點在緊急情況下的時延均低于在非緊急情況下的時延；此外，所有節(jié)點的時延隨著仿真的進行而發(fā)生隨機波動，這是由體域網網關節(jié)點HUB的隨機移動性及霧節(jié)點參數在一定范圍內的隨機性所導致的。

圖5 節(jié)點時延對比Fig.5 Comparison of node delay

圖6 為系統(tǒng)時延及吞吐量與任務期限TExp之間的關系曲線。圖中，左軸代表系統(tǒng)時延，右軸代表系統(tǒng)吞吐量。

圖6 時延及吞吐量與任務期限TExp的關系Fig.6 Relationship of delay and throughput with TExp

由圖6可見，系統(tǒng)吞吐量與延時呈反比關系。當TExp<6 s時，系統(tǒng)時延幾乎呈垂直上升趨勢增長到無窮大，這是由于當TExp設置太小時，導致滿足條件的節(jié)點集合為空。而在將近6 s時，系統(tǒng)中至少出現了一個滿足條件的節(jié)點，因此系統(tǒng)時延急劇下降。由吞吐量公式Throu=Di/Tt可知，吞吐量Throu與任務數據量Di及任務處理總時間Tt有關。因此，在6 s以前，當系統(tǒng)時延為無窮大時，系統(tǒng)吞吐量為0（見右軸），而當接近6 s，當系統(tǒng)時延陡然下降時，系統(tǒng)吞吐量急劇上升。而后，在TExp>6 s的情況下，增大TExp并不會顯著改變系統(tǒng)時延及吞吐量，這是因為理論上TExp的改變只會改變滿足條件的霧節(jié)點的個數Ns，不管Ns多大，最終的最佳目標霧節(jié)點只有一個，因此系統(tǒng)吞吐量并不會隨著TExp的增長而呈明顯的增大趨勢。但是系統(tǒng)的隨機性導致最終目標節(jié)點Ft的時延的隨機性，因此當TExp>6 s以后，系統(tǒng)時延呈隨機起伏，且由于吞吐量與時延的反比關系，導致其反方向隨機波動。

圖7 為節(jié)點的接收信號強度RSSI（Received Signal Strength Indicator）值在不同情況下的對比。

從圖7中可以看出：

圖7 節(jié)點RSSI在不同情況下的比較Fig.7 Comparison of node RSSI in different cases

（1）在ei=0（非緊急）的情況下，目標節(jié)點Ft的RSSI值明顯高于普通霧節(jié)點的RSSI值。這是因為在非緊急情況下，RSSI值是目標Ft節(jié)點選取的重要尺度，此時系統(tǒng)更傾向于選擇RSSI高及時延低的節(jié)點作為目標節(jié)點。

（2）目標節(jié)點Ft在ei=0時的接收信號強度RSSI值明顯高于其在ei=1時的值。這是因為，在非緊急情況下，系統(tǒng)將同時考慮時延及可靠性尺度，通過多目標優(yōu)化選取最終的目標節(jié)點Ft；而在緊急情況下，系統(tǒng)以時延為主要尺度尋優(yōu)選取目標節(jié)點Ft；同樣，對于普通霧節(jié)點也有相似的結論，不同的是，對于普通霧節(jié)點而言，其RSSI值在緊急與非緊急兩種情況下相差不大，當ei=1時，其均值約為4.58 pW，而當ei=0時，其均值約為4.74 pW，比ei=1時的值略小。

總之，對于Ft而言，ei=0時的RSSI值高于ei=1時的RSSI值，而RSSI值將直接影響系統(tǒng)丟包率的大小。因此，相對而言，系統(tǒng)在ei=0時的可靠性更高，這與理論分析是一致的。

圖8 所示為節(jié)點在不同情況下的負載情況對比。圖中，橫坐標表示仿真輪數，縱坐標表示節(jié)點隊列的任務負載量。

圖8 節(jié)點負載在不同情況下的對比Fig.8 Comparison of node load in different cases

由圖8可以得到如下結論：

（1）在緊急情況下(ei=1),Ft節(jié)點的任務數在0~1之間波動，平均值接近于0；而在非緊急情況(ei=0)下，Ft的任務數最大達到10，平均值約4.5。由此可見，對于目標節(jié)點Ft而言，緊急時候的任務負載量明顯低于非緊急時候的任務負載量。這是因為，在緊急情況下，系統(tǒng)以時延最低為目標優(yōu)化選取最佳目標節(jié)點Ft。由式（1）可見，當ei=1時，由于霧節(jié)點采用搶占式調度方式，此時任務時延看似與任務負載無關，但是HUB需要為所分配的優(yōu)先服務而付出代價，具體代價大小與任務負載Q成正比關系（見式（7））。因此，ei的值直接決定了目標節(jié)點的選取是否與任務負載Q有關。即當ei=1時，任務負載Q與Ft的選取有關，并且此時Q與時延指標T的權重系數都為1，即兩個參數的重要程度相同，各對Ft的選取起1/2的影響作用。

（2）在非緊急情況下(ei=0)，由式（7）可見，目標節(jié)點Ft的選取受時延指標TT、節(jié)點的接收信號強度RSSI的影響，并且其權重系數相同，各對Ft的選取起1/2的影響作用。由式（1）可見，此時任務隊列Q及任務所需CPU周期數Ci及任務數據量Di三者權重系數相同，共同決定總時延的大小，因此綜合來看，在最終Ft的選擇中Q占據了1/6比重。

（3）在多目標優(yōu)化中，參數的重要性系數越大，其對結果的影響作用越明顯。因此，綜合上述兩條結論可知，ei=1時，Q對目標節(jié)點的選取將起到更為顯著的作用。即當ei=1時，經過優(yōu)化選擇的目標霧節(jié)點的負載水平Q在ei=1概率上必然低于其在ei=0時的負載水平，這說明仿真結果與理論分析是一致的。

（4）不難發(fā)現，當ei=1時，普通霧節(jié)點與目標霧節(jié)點Ft的負載值有較大差異，Ft節(jié)點負載的最大值為1，均值為0.1，而霧節(jié)點負載的最大值約為6，均值約為5。由此可見，當任務緊急時，目標霧節(jié)點的負載值明顯低于霧節(jié)點的負載平均值，與理論分析是一致的。

3 總結

本文提出了一種基于霧計算輔助的體域網目標霧節(jié)點關聯及任務卸載方法。通過將計算密集型任務卸載到霧計算節(jié)點進行處理，本文方法可以降低體域網網關節(jié)點的功耗，同時利用霧計算節(jié)點強大的數據處理能力，可以大大降低任務處理時延，滿足時延敏感的體域網應用需求，尤其是在緊急情況下的應用。本文方法可以根據數據及任務的不同情況，自適應調整系統(tǒng)的優(yōu)化目標函數的評價尺度，當任務緊急時，由于對時延的要求極高，算法以低時延為主要優(yōu)化目標尋優(yōu)選擇最佳目標霧節(jié)點；而當任務非緊急時，同時考慮系統(tǒng)的時延及可靠性，對系統(tǒng)進行多目標優(yōu)化。仿真結果表明，本文方法能夠兼顧系統(tǒng)的時延及可靠性指標需求，對于緊急情況下的應用，能夠大大降低系統(tǒng)時延，對于非緊急情況下的應用，系統(tǒng)時延及可靠性都可以得到保證，滿足了基于體域網的智慧醫(yī)療系統(tǒng)對系統(tǒng)實時性及可靠性的要求。但是，如果網絡中節(jié)點緊急任務較多，則本文所提方案需要進一步針對任務的不同屬性劃分優(yōu)先級，對高優(yōu)先級的任務進行優(yōu)先調度，同時設計合理的機制防止低優(yōu)先級及非緊急任務饑餓，這將是下一步的研究方向。