空間邊緣計算：需求、架構及關鍵技術

虞志剛 馮 旭 戴 天 陸 洲

(中國電子科技集團公司電子科學研究院 北京 100041)

1 引言

隨著人類活動疆域從陸地向深海、深空的不斷擴展，為切實保障遠洋航行、空間探測等領域網絡通信需求，世界各國紛紛布局以低軌星座為代表的空間信息網絡建設，構建全球無縫覆蓋、服務無處不在的網絡能力[1–3]。

與此同時，隨著航天電子技術的迅猛發展，宇航級計算、存儲設備能力逐步增強，如圖1所示，以中央處理器(Central Processing Unit, CPU)為例，隨著CPU主頻逐步提升，星載計算能力也獲得較大的躍升[4]。除此之外，隨著商業航天的快速推動，商業貨架器件被廣泛應用，部分地面高性能、低成本器件經過簡單的加固之后運行在空間環境[5]，星載計算能力得到了大幅提升。

圖1 宇航級CPU主頻與處理能力增長曲線

未來通信衛星將突破傳統的“轉發器”概念，具備較強星載計算能力，將部分計算、存儲、通信、網絡與感知任務沉降到衛星邊緣完成在軌處理，實現通信、計算有效融合，可以有效提高服務響應速度、降低各種數據回傳造成的通信壓力[6]，擺脫對地面系統依賴。

以星鏈(Starlink)為例，公開資料顯示，美國太空探索公司(SpaceX)每發射60顆衛星包含4000多臺Linux計算機，截至2021年6月，SpaceX已經發射星鏈衛星1737顆，在軌1638顆[7]。據此推算，已發射出116000臺Linux計算機。一方面，分散在太空中的巨量Linux計算機將產生大量數據，若這些數據全部傳回地面將給星間鏈路產生壓力；另一方面，大量Linux計算機聚合構建強大算力資源，完成單顆衛星難以完成的任務[8]，避免數據回傳。

通常受功耗、體積、重量等限制，單顆衛星能夠搭載的資源類型和數量仍將有限，導致單顆衛星的星載計算能力也將有限[9]。面向未來廣泛的計算能力需求，迫切需要多顆衛星之間或衛星與地面之間通過星間/星地鏈路臨機自組織成集群，最終構成空間分布協同的“云”計算環境–空間邊緣計算環境，實現資源相助、任務協同，獲得倍增效應。

因此，在空間網絡高動態、窄帶寬、長時延約束下，如何高效地調動物理分散的星載計算資源，分布式協同完成計算任務成為一個亟待解決的關鍵問題。目前，面向空間網絡的邊緣協同計算理論研究方面尚處于起步階段，本文從空間邊緣計算的需求分析與發展現狀出發，并在此基礎上總結分析，提出一種空間邊緣計算架構，以期能夠為后續空間邊緣計算的研究提供有價值的建議和參考。

2 需求分析

空間邊緣計算的發展受應用和技術雙輪驅動，下面將分別從應用和技術兩個方面進行需求分析。

2.1 應用需求

(1)服務快速響應的需求。隨著星上處理能力的提升，將原始在地面進行存儲、計算、處理、分發的任務，直接搬移到衛星上，將會極大地服務響應的速度。如遙感成像、目標監視、態勢分發等實時類應用，如圖2(a)所示，通過直接在衛星上進行態勢感知與情報生成，可以大幅縮減星地回傳的時間，提高服務響應速度[6]。以高軌衛星為例，星地之間的單向時延在120 ms左右，相較于地面處理，星上處理可以節約兩個星地傳輸延遲，即240 ms。

(2)擺脫地面依賴的需求。空間邊緣計算將會使“空間信息基礎設施”發展成為一個可以自治、自演進的獨立的功能體[10,11]，如圖2(b)所示，既可以在地面中心的控制下，星地協同工作，又可以在失去地面控制情況下，獨立運行工作，擺脫地面依賴，在極端情況下，可以提高系統的可靠性。

圖2 空間邊緣計算應用場景

(3)節約星地帶寬的需求。隨著星上處理能力的增強，衛星外部感知的感知數據以及衛星節點自身狀態產生的狀態數據均將是海量的，傳統計算架構下，數據必須通過饋電鏈路回傳地面中心進行數據處理，勢必會給星地帶寬帶來極大的壓力[6]。以海上目標搜救為例，如果采用星上對圖像數據直接處理，發現目標即確認，星上生成情報信息直接通知相關搜救船只，可以減少大量原始數據回傳地面帶來的帶寬壓力，同時節約寶貴的星地傳輸帶寬。

2.2 技術需求

(1)多星協同計算需求。考慮到衛星平臺對重量、功耗、體制以及空間輻照環境的限制，相較于地面環境，衛星單節點能力、資源等各方面均十分有限[8]：(a)計算能力有限，面向較大計算或存儲能力需求，唯有通過多點協同(多星協同)方能實現能力倍增；(b)計算資源有限，受限于衛星節點的限制，單節點難以配備全套現場可編程門陣列(Field Programmable Gate Array, FPGA)、圖形處理器(Graphics Processing Unit, GPU)、CPU、張量處理器(Tensor Processing Unit,TPU)等異構計算資源，為了使應用采用合適硬件進行處理加速，必須通過多點協同方能實現資源互補。

(2)星地協同計算需求。雖然大量商用貨架產品(Commercial Off-The-Shelf, COTS)器件已經在衛星上開始使用，但星上計算能力仍然難以與地面的算力相比，空間信息基礎設施更像是地面計算環境的“縮小版”，面向空間難以處理的計算任務，仍可通過星地協同的方式來滿足算力需求[11,12]。

3 發展現狀

圍繞空間邊緣計算，國內外均開展了大量的探索實踐：一方面為了提高衛星網絡的韌性，支持自主運行，星上具有較強的計算處理能力已經成為衛星網絡發展的新趨勢；另一方面，宇航級CPU、FPGA等芯片的計算處理能力的穩步提升，以及隨著商業航天的快速推動，商用貨架器件廣泛應用于低軌航天器，星載計算能力大幅提升，也為空間邊緣計算奠定了基礎。

3.1 星載處理成為衛星網絡發展的新趨勢

如表1所示，2018年7月，美國國防高級研究計劃局(Defense Advanced Research Projects Agency, DARPA)提出黑杰克(Blackjack)計劃，計劃發展由60～200顆衛星組成的低軌星座，星座能自主運行，支持衛星之間數據共享、相互協作，黑杰克上搭載“Pit Boss”載荷[13]，具有自主控制及自主決策等在軌計算能力。

表1 國內外典型衛星網絡

2020年，美國太空發展局(Space Development Agency, SDA)面向太空日益凸顯的戰略作用，提出了靈活、彈性、敏捷的國防太空架構(National Defense Space Architecture, NDSA)[14]，分為傳輸層、跟蹤層、監管層、威懾層、導航層、管理層、支持層等7層，其中管理層具有較強處理能力，支持基于人工智能的分布式管理、指揮、控制和通信等功能。

與此同時，國內各單位也在積極探索。2018年11月，中國科學院軟件所研制的“天智一號”發射升空[15]，采用“開放架構、模塊集成、軟件定義、一星多能”設計理念，搭載小型高性能星載計算平臺；與此同時，支持有效載荷即插即用、應用軟件按需加載，可以通過不同應用軟件，實現不同任務。目前，該星已經實現星上實時智能云檢測及圖像質量判讀，以及APP指揮衛星等功能。

2021年9月，中國電科38所發布了商業SAR天仙星座計劃[16]，每顆衛星均具有4種模式成像功能，按需成像，同時搭載一顆強大的計算處理系統，支持星上即可完成圖像預處理，快速識別圖像內容和信息傳輸。2021年12月，北京郵電大學與天儀研究院合作研制的天算星座1號衛星發射升空，搭載了開源的云原生環境，支持與地面協同推理[17]。

3.2 宇航級處理芯片的性能獲得大幅提升

近年來，隨著航天技術和信息技術的迅猛發展，宇航級CPU,FPGA等芯片的能力獲得大穩步提升[16]。以CPU為例，美國宇航局和歐空局始終處于世界領先水平。如表2所示，1998年歐空局研制了基于SPARC(Scalable Processor ARChitecture)架構的TSC695F芯片，主頻25 MHz；2001年美國宇航級的火星任務系統采用了基于飛思卡爾半導體片上系統處理器架構的CPU RAD750，主頻200 GHz，可提供高達400 DMIPS的算力。2016年以來，歐空局和美國宇航局紛紛拋棄基于傳統SPARC架構的宇航級CPU和基于傳統PPC(Performance optimization with enhanced risc – Performance Computing)架構的宇航級CPU，轉型研發基于ARM(Advanced RISC Machine)架構的宇航級CPU(歐空局的DAHLIA(Deep sub-micron microprocessor for spAce rad-Hard appLIcation Asic)芯片以及美國宇航局的HPSC(High Performance Scalable Computing)芯片)。其中DAHLIA由4個ARM Cortex-R52通過設計加固構成，計算處理性能可達4000 DMIPS；HPSC芯片主處理器由8個ARM Cortex A53處理器經過設計加固構成。

表2 國內外典型宇航級CPU芯片

國產宇航級CPU的計算能力達到了美國同等水平，初步具備自主可控的研發能力。2021年12月，北京微電子技術研究所發布了第3代國產抗輻射SPARC架構處理器BM3883MARH，該芯片為8核處理器，主頻可達1 GHz，定點運算性能可達16 GIPS，浮點運算性能可達32 GFlops，配備神經網絡處理加速引擎，支持智能處理。A R M 架構方面，2022年1月，歐比特公司披露自主研發的玉龍810A芯片正在等待批產，其主處理器采用4核ARM A9，協處理器包括GPU和NNA單元，浮點處理能力可達64 GFlops，定點處理能力12 Tops。綜上可以發現宇航級CPU性能已經告別“單片機”時代。

另外，2017年8月，惠普公司自主設計研發的第1代空間超級計算機(Spacebourne Supercomputer-1)搭載SpaceX公司的獵鷹9號火箭被送往國際空間站[5]，運行常規Linux系統，采用軟件加固消除空間惡劣環境的影響而非傳統的硬件加固。經過兩年的在軌運行之后，2019年該計算機已經被帶回地球開展嚴格的檢查以分析其在太空軌道上的受損情況，將有助于打造未來的空間超級計算機，為深空探測任務提供技術支撐。

3.3 問題與挑戰

綜上可見，無論國外還是國內，星上計算處理成為當前衛星的“標配”，通過星上搭載處理能力，可以有效地降低對星地帶寬的依賴，同時提供服務響應速度。然而，在空間網絡高動態、窄帶寬、長時延約束下，如何高效地調動廣域分散的星載計算資源、協同完成計算任務成為一個亟待解決的問題。主要包括6個方面：

(1)時變性挑戰。空間網絡(特別是中低軌)拓撲處于動態時變之中，如何在拓撲頻繁變化的條件下調動分散計算資源協同計算具有極大的挑戰性；

(2)移動性挑戰。低軌衛星高速運動會導致用戶-網絡節點的雙重移動性，如何在高速移動的場景下提供不間斷服務及自主服務遷移具有難度；

(3)長時延挑戰。空間網絡的跨度大，導致衛星節點間傳輸時延至少幾毫秒，比地面超級計算機/數據中心等集群節點之間微秒級傳輸時延高出多個數量級，提高了通信成本，如何進行有效的任務拆分和部署將是一個亟待研究的新問題。

(4)窄帶寬挑戰。截至目前，星間鏈路/星地鏈路傳輸帶寬通常為Gbps量級，相對地面光纖差距較大，難以大規模數據搬移，給分布式計算帶來挑戰。

(5)高成本挑戰。衛星相對地面普通節點來說仍然屬于高價值資產，具有較高的成本且功耗受限，進行任務分配時必須要考慮衛星的功耗紅線。

(6)計算理論挑戰。為了實現全球覆蓋，低軌星座通常具有幾百、幾千甚至上萬顆衛星規模，在規模龐大、拓撲動態、能力分散的條件下，缺乏分布式協同計算的架構、模型理論以及相應編程模型。

4 空間邊緣計算架構設想

針對空間邊緣計算存在的問題與挑戰，本文提出了一種空間邊緣計算的架構，并分別從物理、功能、軟件以及業務流程等多個方向闡述內涵。

空間邊緣計算是將分散在衛星上的計算資源通過衛星網絡協同組織起來，構建多星協同、星地協同的分布式計算環境，實現資源相助、任務協同，獲得倍增效應。通過與地面云中心以及用戶終端協同，形成云-邊-端協同的計算環境，如圖3所示。

圖3 空間邊緣計計算環境

4.1 物理架構

物理組成方面，空間邊緣計算由空間邊緣云、地面中心云以及用戶終端3部分組成，如圖4所示。

(1)空間邊緣云：是由若干承載在衛星上的星載處理單元通過星間鏈路組網臨機自組織成集群，構成衛星邊緣“云”計算環境，如圖4所示，支持資源統一調度與管理，滿足實時感知、通信、計算等任務，具備自治、自學習以及自演進能力。其中，星載處理單元是“云化”的智能計算組件，由CPU/GPU/FPGA/DSP/TPU等星載處理資源構成[24]，通過虛擬化技術構建一體化處理資源池，實現資源統一表征與管理，分布式移動的星載處理單元高效協同構建空間邊緣云。

圖4 空間邊緣計算物理架構圖

(2)地面中心云：可以是由分布式部署在地面信關站、移動信關站以及運控中心等地面通用處理平臺通過地面網絡互聯而成；也可以是商用云計算環境；或者兩個混合構成的多云環境。不同于空間邊緣云，地面云中心不受宇航器件、體積和功耗等約束，可以裝配較強的處理資源，提供充沛算力。

(3)用戶終端：主要包括陸海空各類用戶終端，獲取空間邊緣計算架構對外提供的各類服務。

4.2 功能架構

參考歐洲衛星電信標準化協會(European Telecommunications Standard Institute, ETSI)多接入邊緣計算(Multi-access Edge Computing, MEC)架構[25,26]，提出一種面向空間分布式計算環境的功能架構，如圖5所示，主要由星載處理單元和管理控制單元組成。

其中，星載處理單元分為兩個層次，一是資源層：包括虛擬化基礎設施、星載運行平臺以及星載APP，分別提供軟件即服務(Software as a Service,SaaS)、平臺即服務(Platform as a Service, PaaS)和基礎設施即服務(Infrastructure as a Service,IaaS)等服務；二是管理層：包括負責星載處理單元管理的虛擬化基礎設施管理系統以及單顆星載運行管理系統。管理控制單元負責全系統/跨星的運行管理與控制，主要由運行支撐系統、協同編排系統組成，具體功能如圖5所示。

圖5 空間邊緣計算功能架構

4.2.1 星載處理單元

(1)虛擬化基礎設施：根據星載處理單元提供的CPU/GPU/DSP/FPGA/TPU/存儲/接口等硬件資源利用虛擬化技術形成計算、存儲、網絡、安全等各類虛擬化基礎資源，提供IaaS服務能力。

(2)星載運行平臺：一組基礎的功能軟件的集合，一方面為上層的星載APP提供運行環境，支撐星載APP的服務發現、注冊等；另一方面，從星載運行管理系統那里接收指令并相應配置虛擬化基礎設施，并對跨平臺任務協作提供通信支持，提供PaaS服務。

(3)星載APP：運行在星載運行環境之上的目標識別、數據壓縮等各類APP，支持第三方開發，構建星載的應用程序倉庫(APP Store)，形成空間分布式計算的服務窗口。

(4)虛擬化基礎設施管理系統：負責分配、管理和釋放虛擬化基礎設施的虛擬化資源，包括計算、存儲、網絡資源，為服務的部署準備虛擬化基礎資源組件，收集和報告虛擬化資源的性能和錯誤信息。

(5)星載平臺管理系統：接收運行支撐系統的平臺配置文件以及任務編排器下發的服務規則文件，按要求生成在軌處理平臺資源配置的具體指令，對星載處理平臺上需要運行的本地服務進行生命周期管理，并將服務運行的狀態信息上報給任務編排器。

4.2.2 管理控制單元

(1)協同編排系統：將應用請求拆分為由若干服務組成的服務鏈，根據自身部署的策略將服務發布至指定平臺，當網絡結構發生變化時該模塊會將服務進行重定向以保證用戶端體驗的穩定性。除此之外，協同編排系統還負責構建并維護分布式協同環境的整體資源視圖。

(2)運行支撐系統：所有需要與用戶進行交互的功能均部署于該模塊中，用戶接入操運行支持系統后可直接申請使用平臺提供的應用，第三方開發機構可申請獲取平臺對外開放的部分能力以獲取數據處理、協同感知等服務。運行支撐系統負責應用的實例化以及用戶權限核準，被批準的請求將移交給協同編排系統與星載平臺管理系統作下一步處理。

4.2.3 運行模式

空間邊緣云可以與地面云中心協同運作，如圖6所示，在條件允許的情況下，向地面云中心上報感知數據、狀態數據和能力數據，同時獲得信息支援、決策支持和行動指導，可以用于增強數據共享、任務遷移、資源調度、冗余備份和容錯抗毀能力；也可以自主智能運作，通過利用衛星邊緣側獲得的海量數據，借助人工智能技術更好地提高數據分析、場景感知、實時決策和自主協同等智能化服務。

圖6 星地協同運行模式示意

4.2.4 功能部署

根據管理控制單元部署位置的不同，空間邊緣云將會呈現不同的運行模式：

(1)管理控制單元部署在地面。此時為一種集中式架構，管理控制面位于地面，星上僅需要裝載數據面功能以及單星的管理控制功能。優點是可以很好地適應星上資源、功耗受限約束；缺點是所有的任務請求都需要傳輸到地面進行處理，地面管理控制單元將成為系統的瓶頸，同時空間邊緣云的自治能力比較弱。

(2)管理控制單元部署在衛星。此時為一種分布式架構，所有的衛星都部署星載處理單元以及管理控制單元，根據星座構型或者軌道分布，通過某種機制選舉某些衛星作為運維管控的錨定點。優點是無須受到地面約束，在星地鏈路干擾情況下也可以自主運行、自主決策；缺點是要求衛星具有較強的計算存儲能力，能夠部署全套的功能，另外如何選舉合適衛星成為錨定點也是難點。

4.3 軟件架構

空間邊緣計算軟件可以劃分為基礎資源層、操作系統層、虛擬化層、平臺層、應用層、管理控制層6層，如圖7所示。

(1)基礎資源層：包括CPUGPUFPGADSPTPU等異構星載處理資源、網絡設備、接口設備及數據庫等基礎設施資源；

(2)操作系統層：與基礎資源層對接，實現各類硬件的驅動，提供軟件部署基礎環境，負責星載資源發現、接入以及納管，是平臺資源的管家，任務部署過程中的資源申請及釋放也集成在該層；

(3)虛擬化層：利用容器技術對衛星網絡中物理資源進行虛擬化抽象處理，在該層部署虛擬化、容器化、遠程調用等軟件實體，形成存儲、通信、計算等功能分類且彈性的資源池；

(4)平臺層：參考云計算、邊緣計算理念，借鑒K8S, KubeEdge等開源軟件架構[10,11]，提供輕量級、開放、通用跨平臺的開發框架，提供良好的用戶開發環境，支持應用軟件按需加載、第三方應用的開發部署，提供應用服務與云端的接口，提供服務的基礎和保障；

(5)應用層：提供各類應用服務APP，包括衛星導航、目標探測、衛星通信和目標跟蹤等業務類應用，也包括用于平臺管理等基礎APP，形成空間分布式計算的服務窗口。

(6)管理控制層：負責各種資源與控制，包括單星資源管理、多星協同管理、星地協同管理等層級，同時也是應用服務與云端的接口，提供服務的基礎和保障，在該層部署服務監測、任務編排、服務調度等軟件實體。

4.4 服務范式

參考云計算的架構，空間邊緣計算架構可以進一步劃分為IaaS, PaaS, SaaS 3種服務范式，如圖7所示，其中基礎資源層、操作系統層、虛擬化層協作，打造云化的基礎設施，對外提供IaaS服務；平臺層提供基礎的軟硬件與開發環境，對外提供PaaS服務；應用層提供各類應用服務APP，對外提供SaaS服務[12,13]。

圖7 空間邊緣計算架構體系

4.5 服務流程

空間邊緣計算服務流程按照管理控制單元的部署位置不同可以劃分為自主運行、星地協同兩種服務模式，前者衛星具有管理控制功能，后者地面統一管理控制，但其基本流程相似，此處我們以星地協同模式為例介紹服務流程，如圖8所示。

圖8 空間邊緣計算服務流程

(1)用戶APP(用戶終端或第三方服務)向最近的地面云中心–管理控制單元發送請求參數，如位置信息、目標圖像、通信服務等；

(2)運行支撐系統收到用戶請求參數后，對用戶權限以及數據完整性進行校驗，確認無誤后激活相關星載應用，并向協同編排系統發送應用請求參數，如服務類型、服務質量(Quality of Service, QoS)需求、可靠性參數等；

(3)管理控制單元–協同編排系統收到應用請求參數后，通過服務協同編排軟件將請求匹配至不同的服務，并將服務分配至不同的星載平臺管理系統，服務分配還需要在服務出現異常狀態時對服務進行重定向；

(4)收到服務請求參數的星載平臺管理系統生成本地的配置文件，包括待激活服務類型、服務生效時間、服務生效規則等，生成的配置文件發送至星載運行平臺；

(5)星載運行平臺根據配置文件在本地激活相應服務，不同服務會調用不同虛擬化基礎設施資源；

(6)虛擬化基礎設施的資源被調用后，會將自身的資源占用情況上報至虛擬化基礎設施管理系統；

(7)虛擬化基礎設施管理系統定期向星載平臺管理系統更新資源使用狀態；

(8)資源分配完畢后，星載平臺管理系統會收到服務響應數據，并將其發送至協同編排系統；

(9)協同編排系統收到全部服務響應數據后即可得到應用響應數據，并將其發送至運行支撐系統；

(10)運行支撐系統收到應用響應數據后會得到用戶響應數據，并將其發送至用戶；

(11)用戶得到用戶響應數據，服務結束。

5 關鍵技術

5.1 空間分布式協同計算范式

當前，分布式計算/云計算以及并行計算理論和方法往往面向室內場景，具有相對穩定和富足的傳輸帶寬。然而，面向拓撲時變、帶寬有限、鏈路斷續的空間環境，以及異構、廣域分散、能力有限的空間資源，結合不同的任務對響應速度、計算能力的需求，迫切需要構建統一空間分布式計算模型，設計多星協同、星地協同的分布式計算處理架構，為空間邊緣計算理論提供理論支撐。目前關于空間邊緣計算的研究要集中在架構方面[27]，關于分布式協同計算范式與理論模型方面研究比較少。

5.2 時變網絡的確定性路由

面向在軌多源信息融合處理、廣域交通控制等時間敏感類應用對網絡傳輸的確定性需求，以及空間網絡動態拓撲特征帶來的時變性、不確定性[28,29]，迫切需要研究時變網絡場景下的確定性路由技術，充分利用衛星運行軌道的軌位信息以及規律性，通過在時變網絡資源模型基礎上構建相對確定性的路由模型，解決空間網絡天然不確定性與應用的確定性需求之間的矛盾。目前，關于空間網絡的路由算法研究較多，然而如何試驗有保證的時間確定性路由仍然是一個新問題。

5.3 高移動場景下服務遷移

針對衛星高速移動帶來的網絡拓撲時變、用戶頻繁切換，以及復雜電磁環境帶來的衛星或鏈路故障，均對空間邊緣計算帶來諸多挑戰，迫切需要研究高移動場景下的服務自主遷移技術，包括服務流程分析、服務遷移架構和策略，綜合考慮遷移前后時延、帶寬、算力以及能耗的關系，尋找最佳的遷移衛星節點及遷移路徑[30]。目前，地面邊緣計算領域的服務遷移有較多的研究，而關于空間場景下的服務遷移研究較少。

5.4 在軌資源智能協同編排

衛星節點的異構性帶來了計算資源的異構性和不均衡性，空間網絡的動態性帶來了資源連接關系以及計算資源關系的時變性[16]。與此同時，多樣化的任務對資源和算力有差異化需求。那么，如何在空間網絡特征下，在功耗、時延等成本約束下，智能協同編排廣域分散的算力資源滿足差異化的應用需求是一個迫切需要解決的關鍵問題。

6 結束語

隨著星載計算處理能力增強，通過將廣域分散的星載計算資源通過星間鏈路臨機自組織形成空間分布式協同的邊緣計算環境，可以有效擺脫對地面的依賴、提高服務響應速度。梳理了空間邊緣計算的應用需求、發展現狀以及存在的問題與挑戰，并在此基礎上總結分析，提出一種空間邊緣計算架構，分別從物理架構、功能架構、軟件架構以及服務流程等多維角度進行了闡述；最后對涉及的關鍵技術進行了概述和分析，以期能夠為后續空間邊緣計算的研究提供有價值的參考。