5g網絡建設預測（淺談5G及邊緣計算接入網絡的治理）

2023-05-27 18:54:51

內容來源：2021年10月23日，由邊緣計算社區主辦的全球邊緣計算大會·上海站圓滿落幕。會上，虎牙5G首席架構師林正顯受邀發表了主題為《淺談5G及邊緣計算接入網絡的治理》的演講。

分享嘉賓：虎牙 5G首席架構師 林正顯

整理編輯：上海大學 劉含

出品：邊緣計算社區

淺談5G及邊緣計算接入網絡的治理

——無線環境下APP網絡質量調優思考與實踐

林正顯：謝謝還在場堅持的朋友們。什麼叫邊緣計算，前面的講師都分享過了，我不再多講。邊緣計算的網絡倒是可以講一下，邊緣計算網絡無非就是邊緣計算節點下沉到邊緣之後，我們的端和邊緣節點之間聯繫的網絡，或者是邊緣節點之間的網絡，或者是邊緣節點到雲之間的網絡。我今天主要講的是端到邊之間的那段網絡，而且側重的是無線側的東西。

我個人是在2C行業做的，虎牙直播。這兩年虎牙一直在實時內容創作和直播互動等領域發力，做了很多拓展和研究工作。虎牙採用的是端-邊-雲的網絡架構。端邊之間通過有線或者是無線的接入，今天談的主要是無線接入那一塊，包括WIFI、4G和5G。SD-WAN也好，還是雲邊通訊也好，這一塊大家講得比較多，但是我發現對於接入側，不管是邊緣計算社區還是我之前參加的其他社區，大家都講得比較少。今天我會把虎牙今年在做的一些實踐經驗和教訓跟大家分享一下。

我們來看一些常見的問題，如果是做網絡的同行應該比較清楚我在上面列的是什麼。

圖1-場景1

如場景1所示，看起來雜亂無章的圖，整個來說它的RTT會非常低，但是它的丟包比較高，而且看起來沒有任何規律可言；其實沒有規律也是一種規律，它對應了一種場景。

圖1-場景2

第二種是什麼呢？第二種是一個很怪異的現象，你會發現它的RTT一會兒高一會兒低，但是它的可用網絡前面切得很平，後面掉下去，這個代表的是另外的模式。

圖1-場景3

第三種是丟包非常低，幾乎沒有丟包，但是RTT一直在抖。

圖1-場景4

第四種是RTT和丟包都非常非常糟糕。

事實上這幾種情況都代表著在線上的一些不同的故障模式。

會有什麼樣的原因呢？

我們先看兩個圖，圖2是抓取的一個在西藏做戶外直播的主播的RSRP，也就是他的參考信號接收強度，這代表的就是他的無線接收強度的信息。可以看得到有一半的情況下，這個主播一定是開播質量非常糟糕。因為它的RSRP很多時候都低於-110dBm，這個時候的網絡會很差。

圖2: 主播RSRP顯示圖

圖3是在公司找的一個角落裡測的一個圖。那個角落的信號強度不是特別好，而且不知道為什麼，還存在很強的上行的幹擾，所以會導致上行的傳輸誤碼比會很高，然後呢，手機肯定會把發送功率調大。一直增大、增大，最後到了23dBm，也就大概對應著200毫瓦的功率，幾乎已經是國家規定的手機最大發射功率，這個時候最大上行帶寬是多少呢？才0.1mbps。

圖3: 測試信號相關結果圖

這是兩個例子，對於我們的接收網絡來說還有很多不同原因。

比如大家在地下室裡面就會體會得到，信號很弱。還有一種信號不弱但是周圍幹擾比較強，噪聲比較大，這是強幹擾的情況。還有就是我們可能信號也很好，也沒有幹擾，但是網絡是擁塞的，比方說在一個萬人演唱會或者是幾萬人的體育場，那麼多觀眾，這個時候就幾個基站的覆蓋往往不能支持幾萬人的正常使用。還有一種是限速，很多主播或者觀眾用的流量非常誇張，哪怕是無限流量套餐，它也會有一個流量閾值，過了這個閾值就會被運營商限速，很多時候每秒鐘不能超過1Mbps。

最後是一個亂序的問題，亂序是怎麼產生的？

比如5G、4G用了MIMO和HARQ的技術；如果我們的RLC層或者PDCP層沒有做一些按序遞送的操作，那最後上層拿到的東西就有可能是亂序的。

上述這些五花八門的原因導致什麼結果？

導致了業務需求和可用帶寬的供給兩者之間存在比較大的矛盾，簡單來講就是供需矛盾。既然存在供需矛盾，我們的解決方案是什麼呢？要麼擴大供給，要麼就是把需求給縮減。

3.1 多接入（Multi-Access）

現在看一下擴大供給，就是開源節流的開源邏輯，會有哪些方案？

一個是多鏈路的接入，還有QoS機制，再一個就是網絡切片（大家可能多多少少聽說過這個名詞，叫5G網絡切片），還有另外一種，雖然成本很低但是見效非常好的，那就是簡單升級一下你的設備和通訊標準。我們會一個個去稍微講細一點。

圖4是5G的ATSSS的一個示意圖。

圖4: ATSSS示意圖

實際上更多想表現的是針對一個終端，我可以通過WIFI和運營商的5G網絡或者4G網絡同時接入運營商的網關，再通過一些去重的操作，再達到一個比較可靠的傳輸鏈路。這個在實現上本身分了兩種，一個是Low Layer，另一個是基於MP-TCP，但是這兩個東西實際來說對應用層是不可見的。我跟很多運營商的朋友有交流過，因為其實我自己也挺想用那個技術，但是挺遺憾，我得到的反饋是，運營商不太可能會去開放這個能力給我們用。但是我們不妨參考這個3GPP定義的能力，去把這個想法轉移到我們的應用上去。在3GPP定義之前，很多人也已經做過了一些MIFI設備、多鏈路聚合的設備或者WIFI、4G聚合的設備，這樣做的好處是什麼呢？

就是一路如果不行了，不管是它的網絡不通還是帶寬不夠，兩路三路四路總歸是OK的。利用APP主導的多鏈路接入以保證上行的穩定性，是比較常見的做法，比如說，如果傳輸的要求比較高，從一路移動的線路再加上電信、聯通的線路，三路上去傳輸的是同一份數據，總比單路傳輸可靠的。還有就是通過廠商提供的API在應用層調用Wi-Fi/4G/5G雙鏈路接入技術。

圖5: ATSSS的多鏈路聚合

3.2 無線QoS

QoS是一個比較古老的話題，我大概2000年的時候做IP QoS的時候就接觸過這個東西。下圖這個是3GPP定義的5G的一個QoS的架構。和4G不同的地方在於：4G需要建立多個專用承載為UE提供具有不同QoS保障的業務。

圖6: 無線QoS圖

但是5G裡面不同的QoS會把它放在同一個PDU的會話裡面。然後再通過PCC的QoS rules把不同的IP流映射到不同的QoS Flow裡面,然後不同的QoS Flow再映射到不同的DRB裡面,不同的DRB有不同的優先級的處理。

大家會想QoS的效果怎麼樣？先拿兩個五六月份做的例子看一下。這個例子是一個主播，這是它的幀率。額定幀率大概是每秒24幀，但這個主播開始啟用QoS之前，它的上行幀率非常糟糕，這個情況下視頻基本不可用，卡得非常厲害。

圖7: 上行幀率

當把QoS打開了之後，整個上行的幀率變得比較理想，這是一個例子。還有一個例子：在打開QoS之前，這個主播上行的RTT非常非常的差。理論上來講，我們會覺得百毫秒以下是比較理想的上行延遲，而這個用戶是幾秒鐘的級別。可以看到，當我們打開了QoS之後，整個傳輸質量得到比較明顯的改善。

圖8: 啟用QoS對比圖

● 無線QoS：存在的問題

你可能會想，QoS這麼好的效果，為什麼沒有聽到業界說有非常大規模的應用呢？特別是無線的QoS。是因為它其實還是存在一些問題。

什麼問題呢？

就是接下來的第一個圖所示，我刻意沒有標哪個是成功率，哪個是失敗率或者失敗是什麼原因。我只想告訴大家說現在成功率還是一個問題。這個成功率裡面，失敗率裡面有一個非常大的佔比就是右邊那個圖的橙色部分，某些運營商在某些省或者城市裡面它的支持還不夠。這是一個QoS現在使用的失敗率很高的主要原因。

圖9: 成功率餅狀圖

第二個原因是什麼呢？我們使用了QoS之後如果發現了網絡的問題，我們想去排查，發現困難非常大，因為鏈條很長，我得去跟運營說我這個QoS打開了，你也反饋說開通成功了，最後為什麼質量還是那麼差；但查了半天，有可能會不了了之。所以說這個排查難度比較大，因為它不完全受控於應用層。

大規模應用的另一個障礙是網絡本身負載就高，特別是在4G的時候，5G可能還好，5G整個網絡還是比較輕載；比如說4G在廣州地區，整個網絡負載就非常重，這個時候如果要求把一部分流量再分給要求更高的視頻，對於運營商來說非常吃力。此外，如果大家是做網絡，也會比較好理解，那就是無線的覆蓋對QoS的效果會有比較大的影響。如果我的信號很差，就算你給我最高的優先級，我也沒有辦法傳更多的數據。

另外一個，就是GBR和MBR關係的問題。這裡GBR是指保證速率，MBR是最大速率。理論上說我開通QoS服務，運營商應該給我保底的GBR，比如說4M每秒的流量給我，MBR的流量應該更高，網絡一旦空閒，給我10M、20M理論上都是不過分的。但是往往在實踐中運營商給的GBR和MBR是一樣的！

這會導致什麼呢？

導致我的一些應用特別是視頻應用在有碼率突變的時候，這個GBR和MBR的限定就特別難受，比如我的編碼是VBR，我的編碼碼率抖動是非常厲害的。所以說，QoS這個東西在概念上已經說了很多年，在實現上特別是無線的實現上在應用上還是有一些不太成熟的地方，當然用還是可以慢慢用起來的。

3.3 5G網絡切片

再來說一下大家應該聽到比較多的5G網絡切片。

下圖也是3GPP定義的一個示意圖。切片的概念是什麼呢？無非是把一個物理的網絡把它隔離成多個邏輯上相互獨立的網絡，使得可以獨立運維，質量也互不影響，比如說切片A不會受切片B的影響，這是切片的概念。這在2B的場景大家聽得比較多，例如我們可以給政府機關，或者軍方、警方單獨開放一個切片出來。

圖10: 網絡切片示意圖

但是在我們2C的場景會怎麼樣？在2C場景下，我們用到一個URSP的規則，這個規則URSP是用戶設備路由選擇策略的規則。它是根據流量的特徵來把你的流量映射到相應的PDU會話，簡單來講符合流量特徵A的映射到切片A，符合流量特徵B的映射到切片B。這個映射關係怎麼確定呢？通常是根據我的APPID或者是訪問的域名或者是IP的三元組或者是APN（在5G我們叫DNN），我不知道大家在有沒有在手機上設過APN，現在中國移動大概能用的就是Internet或者MMS的APN。

圖11: URSP規則

我們在2B的時候可以講切片講得比較多，2C的時候基本上沒法去用。問題是什麼呢？因為到現在為止，我的手機作業系統和MODEM、還有應用層之間根本沒有打通。所以如果有人跟你吹說他在2C的時候很好的用了切片，不管是雲遊戲還是其它場景，大概率是在吹牛。

比如說APPID的定義，現在都沒搞清楚，對於安卓來說到底APPID是一個PackageName，還是PackageName加籤名，還是應用市場APPID，現在都沒有統一起來。此外，作業系統也沒有任何接口給你設置這些東西，作業系統就算提供了接口，作業系統和MODEM之間的傳遞談妥了嗎？好像也沒有完全談妥。

這是現在導致我們在2C領域，比如我們用一個手機想去接入某個切片的時候很大的問題。然後我附這個圖是什麼呢？是前段時間我突然發現，安卓12冒出了對URSPRule的支持，也許意味著對安卓來說，安卓12才有機會把5G切片功能給用上去。

QoS與切片的使用建議（TOC場景）

不管是使用QoS還是切片，事實上我們想做的都是提升用戶的接入質量。這兩個東西使用還是有一些講究的。比如說，最大的問題是什麼呢？不管是開通了QoS還是開通了切片，成本是一個非常大的問題。我肯定是希望我網絡接入質量不夠的時候才會去打開QoS或者是使用網絡切片。

其他時候就用普通的服務就OK了。所以說，我覺得我們如果以後在用的時候一定要考慮怎麼動態的來開和關QoS或切片的問題。另外除了成本之外還有我剛才提到的GBR和MBR關係的問題。

這裡有一個實際例子，是吃雞遊戲的一個主播使用VBR編碼的時候，因為畫面的變動非常大，編碼碼率變化得也就比較大，使用2M的編碼碼率，輸出碼率有時候會衝到8M或者10M。這個時候如果申請QoS，在GBR和MBR相等的情況下，我申請的就不是2M或者4M，而是10M的碼率，成本非常驚人。

圖12: 碼率變化圖

所以說，對成本的考量，會決定我們一定是在有需要的時候才會去打開QoS或者切片。至於怎麼判斷要不要打開、什麼時候去打開或關閉QoS或者切片，也是有講究的。時間關係，就不細講了。

3.4 設備或者技術的升級換代

在擴大供給方面，還有一個成本比較低的做法，那就是對我們的設備或者是我們的通信標準進行升級。

●設備或者技術的升級換代（1）：從4G到5G

比如說，我們從4G到5G的升級。

很多人都在談5G，虎牙現在也有超過20%的用戶是在使用5G的手機和網絡。那麼實際情況是怎麼樣呢？總體來講從卡頓率的角度來看，使用5G的主播的質量不見得比4G有多大的提升，為什麼呢？

我們分析到很多用戶發現，其實5G的網絡覆蓋比起4G來說還是有一些差距。這是特別大的一個原因，如果覆蓋搞不定，那戶外開播肯定沒辦法去做得很順暢，這是一個問題。第二個問題也比較普遍，是什麼呢？我們很多主播就是帶寬，哪怕買了無限流量的，播了幾天就超過了限速閾值，後面運營商給你最小的帶寬，大概是700K~800K左右，不管是4G還是5G，優勢體現不出來。

5G好歹投入那麼大，我們看到好的地方是什麼呢？RTT方面看到5G在RTT方面稍微有一些優勢，比如說我們在同城的話，我們的4G移動終端和同城伺服器之間大概是40毫秒這樣的RTT。換到5G可能是20毫秒，RTT稍微會有一些優勢。另外一個就是在高碼率的時候5G的穩定性確實漂亮一些，我們可以看到當碼率升到4M或者8M的時候，使用4G來支撐開播，可用帶寬或者RTT會比較抖，使用5G會好不少。當然這個我不排除現在5G網絡負載還比較輕的原因。

總體而言，5G要在這個行業要比較好的應用，我覺得它的覆蓋還得進一步的加強。

相信以後如果隨著VR或者其他大碼率的直播出現，可能4G真的扛不住了。這個時候也許用5G替代4G的動力才會更足。

●設備或者技術的升級換代（2）：WI-FI

還有一個WIFI的事情。

我這裡列了三個例子，這個綠色的線是指我們用戶手機或者是移動終端到他們家WIFI網關之間的RTT，你可以看到，其實之間的距離可能就幾米，但它的RTT就是幾十毫秒或者幾百毫秒。

圖13: WIFI鏈路信息-用戶A

用戶A質量非常差，用戶B是非常漂亮的，基本上就是兩三個毫秒的RTT。用戶C是時好時壞，而且這個用戶很典型，因為它的終端到WIFI-AP之間的質量跟觀眾能夠感受到的視頻質量完全是正相關的。

圖14: WIFI鏈路信息-用戶B

圖15: WIFI鏈路信息-用戶C

你會發現在主播C這個例子裡面，如果改善了開播設備到他家裡AP那段的通信，對這個場景來說，整個端到端就是非常漂亮的。

●設備或者技術的升級換代（3）：WIFI的代差

所以，我經常在不同場合講，最簡單的去把網絡質量搞好的一個做法是：提示我們的用戶，升級他的手機或者升級AP。

我在我家架了兩個設備，一個是WIFI-4的網關，另外一個是WIFI-5的網關，然後我用兩臺手機去測，手機當時是空載的，空載的時候RTT會偏高，我估計空載的時候手機會降頻。但不管怎麼樣，從總體來看，WIFI-4的網關比WIFI-5的網關延遲會有相當的差距。

圖16: 手機A和B的數據

這個差距有兩方面的原因，第一個是WIFI-4的網關已經是十年前買的，處理器的能力肯定比現在的網關處理能力差很多。另外一個是WIFI代差的區別，WIFI-4和WIFI-5的代差，這個圖可以明顯看到差別很明顯。

圖17: WIFI網關信息數據

如果我們做直播平臺，讓我去幫用戶升級他的網關或者手機，可能做不到，但是去提示他這個總該可以吧。這個對平臺方來說，可能是成本最低的，可以迅速把質量拉升上去的一個做法吧。

我們講完開源，再講一下節流的事情。節流我們可能聽得比較多的是：「擁塞控制」，以及網絡不行時的降幀率、降碼率的措施。但這是被動的做法，它損傷的是視頻質量和開播質量。

有一些偏主動的，或者說能夠儘可能的不去降太多質量的做法，現在業界也在做。

比如說，我們要去研究6G的東西，6G提出來的是什麼呢？其中有一項是語義通信，或者叫語義的提取、編碼和通訊。我們是希望它能夠打破香農公式的極限，但其實不是打破，畢竟香農公式給出的是數據傳輸信道的容量極限，數據再上一層才是語義。

不管我們的1G到5G，我們做的都是數據的通信。我們能不能有一天讓網絡傳輸的是我們的意思而不是數據本身。就意味著什麼呢？意味著網絡兩端通信雙方可能要有一些共通的知識庫，針對數據的理解，再把它提取到語義，傳輸的是語義。

這有兩個好處，一個有可能是傳輸量變得特別小；第二個是什麼呢？有可能我對糾錯的算法有不同的做法。這個是這一兩年業界逐漸在考慮的東西。也有人想把它推到物聯網那邊去，大家可以關注一下。

還有一個是基於AI的編解碼算法。例如大家應該聽說過谷歌的Lyra，聲稱是3kbps可以達到比較流暢的語音交互，這樣一來對網絡的依賴就減輕了很多。

當然還有其他的一些做法，像虎牙用得比較多的是服務端的超分，我可能上行的時候上去的碼率比較低，但我做一個漂亮的超分之後，會讓整個畫質得到比較好的增強，下發給觀眾端更清晰的畫面。總的來說，如果管道不夠好的時候，千方百計想怎麼去提升它所傳輸的數據的表達效率，以此達到最終質量不會降得特別多的結果。

不管是開源還是節流，其實特別依賴同一個東西。我必須得清楚地知道當前網絡發生了什麼，當前網絡到底有多少帶寬是可以用的。如果帶寬不夠的時候，我可能要去申請用更多的帶寬，這時候想方設法做開源；或者當謀求不到更多資源的時候，這個時候得考慮節流。

它的基礎是必須要對現在網絡狀況有比較好的預測和估計，這就是帶寬估計的邏輯。帶寬估計的概念或者帶寬預測的概念也是比較古老的問題。

在實時音視頻方面，有GCC等類似的算法，也有人在研究的基於AI的帶寬估計算法，這方面的探索一直在做，而事實上做得比較好的也沒有幾家。BBR對文件傳輸類比較好，但是應用於音視頻通信就比較差強人意，實時或準實時音視頻對帶寬估計的要求比文件傳輸要高。這一塊每家還得繼續去再發力。這個話題可以作為一個專題來講，今天不展開。

我大概講一下我們的做法。

我們基於吞吐率、RTT以及丟包率，再加上我們對一些特定的模式的判斷，還有引入應用層等方面的跨層信息，構建了針對視頻傳輸的帶寬估計的算法，測試結果還算是比較讓人滿意。

圖18: 帶寬估計

時間關係，我就不細說了。帶寬估計還有另外一個思路，我們為什麼要估計？因為我們不知道網絡上發生了什麼。但是有人是最清楚網絡上到底發生了什麼的，運營商就有很多的信息。

他知道這個基站現在所有用戶上行信道質量是什麼樣的，有多少PRB可分配，有多少用戶是要優先處理的。這些信息運營商或者基站它是知道的。如果哪一天把信息開放出來了，對整個帶寬估計會有很大的作用。

比如我現在有一個安卓手機，我想方設法的去採集一些RSRP或SINR的數據，但是對蘋果手機完全沒有任何這方面的信息，因為蘋果不給。如果運營商開放一個接口出來，把無線信道信息和PBR分配的信息給我，哪怕不直接告訴我有多少帶寬，自己能大致能推導出來這個上行可以達到多少帶寬。

我覺得這是帶寬估計最靠譜或者說是最簡單的一種做法，我們現在用很多的方法去做估算、做濾波，做人工智慧的訓練，如果結合運營商的數據可能會更精準。

當然無線網絡優化還有一些其他的措施。我們知道邊緣計算會導致非常多的海量數據產生，如果不能把數據都傳上網的時候，能不能做一些本地卸載的東西？

事實上是有很多的，比方說，4G已經定義了LTE-Direct，5G的時候叫D2D，主要看你有什麼應用場景。D2D意味著我兩個用戶的通信的數據通道不會再依賴於基站，而是直接點到點的兩個設備之間的通訊，但是用的還是運營商的頻譜。還有另外一個事情，就是無線是有廣播的特性，可以想想怎麼用好廣播的特性。

比如我以前想的例子，在大規模賽事直播的情況下，完全可以用多媒體多播廣播系統（MBMS）來發送信號，我只是在廣播信道發送了一路視頻，所有用戶去監聽該廣播信道，他就可以看到同樣的視頻；當然，前提是這個基站下是希望看同樣視頻的人足夠多，廣播的特性或者優勢才能夠體現出來。

還有一個，實在沒辦法了，我解決不了，那就繞過去。我最近去看一些LoRa或者類似無線技術的東西，發現還挺好玩的，它的速率在國內被限制到不超過5kbps，但是你會發現基於LoRa的對講機做得非常小，但是通話距離又蠻大。

在一些物聯網的場景，當NB-IOT和CAT1不適合的時候，也許我們能夠去考慮其他的方案，LoRa只是一個例子。

剛才講的無線接入網絡，尤其是4G/5G的接入網絡，是端到端網絡裡面總體來講質量比較差的一段，差到什麼程度？

我們有一個數據：在使用4G的虎牙主播裡，上行質量不好的主播佔比會超過10%，而其中因為信號不好導致了質量差的佔比是多少呢？只佔了20%；也就是說質量差的4G主播裡面，有80%左右的比例是網絡擁塞或者限速或者其他非覆蓋原因導致，所以這一塊可優化空間還是蠻大的。我們剛才談到的主要從開源和節流兩方面去談優化思路。

「開源」大致對應著運營商經常講的「網隨業動」，我的網絡要隨著業務來變動，如果業務需求量大，網絡供給變得更大一些，這是運營商的底層邏輯。

但是我們在2C場景下做，就得在業務層做這個事情。如果是網絡沒法給我提供更多的帶寬，這時候做的就是節流或者是「業隨網動」，網絡給了你多少帶寬，你的業務就跟著網絡帶寬的供給來變化。這個邏輯大家都比較清楚。

開源節流的一個基礎是精準的帶寬估計，這個話題挺有意思的。我原來一直覺得帶寬估計這個事我做起來應該不難。但是後來發現理論上還行，真正在工程上去做一個對音視頻非常準的帶寬估計，還有很多工作去做。

我們再展望一下，不管是正在慢慢起來的5G或者是2030年的6G，我們這個優化的思路還會不會存在？現在6G大家都在考慮，比如我們的可見光通信、我們的太赫茲、我們的陸海空全域覆蓋，這些都是一些不斷把我們的管道做大的一些措施，因為我們大家都能看得到，隨著物聯網還有其他一些諸如XR業務的興起，流量越來越大，對管道的需求也會越來越大。當然，應用的需求也會跟著越來越大，所以流量治理和優化的需求一定還會存在，也仍然存在一些不同優先級的業務，怎麼去跟其他業務去搶佔的問題。所以我認為剛才講的那些開源節流邏輯還是存在。

另外節流那一塊，我個人對AI和語義通信這兩個領域比較感興趣一些。在座如果有人是做音視頻和做傳統網絡相關的話，這些領域可以關注一下。

順便說說MEC。大家應該聽到別人跟你灌輸MEC邊緣計算的各種好處，車聯網怎麼受益於MEC的東西。大家有沒有想過一個簡單的問題，聯通的車怎麼跟移動的車通信？在同一個運營商裡面，UPF可以下沉到地市，也可以在UPF旁邊建一個MEC，這對於運營商來說沒問題，但兩個運營商之間的MEC怎麼對通，需要經過全國那十幾個互聯節點嗎？

進一步地，算力等資源如何調度和分配，以及是通過邊緣容器還是邊緣FAAS服務來承載，算力節點之間如何通信等等，其實都是會影響到整個產業真正落地的一些點。存在著一個趨勢，就是資源的融合，且它可能會再進一步的得到增強。這個資源包含雲和網的資源。這個趨勢對網絡治理的要求同樣值得我們關注。