簡介:時下大熱的5G和邊緣計算有什麼關係,它們的契合點在哪裡?網際網路IT域和通訊網CT域如何融合?什麼是雲網一體化?阿里巴巴達摩院XG實驗室高階技術專家南書、邊緣計算團隊高階技術專家屹平分享5G下,邊緣計算的更多可能。
5G所強調的三大特性也就是5G的核心能力,即低時延,高頻寬和大連線。
低時延
5G所承諾的低時延是1毫秒,但需要強調的是這裡的1毫秒只是空口的時延,對於終端使用者來說大家可能更關注的是端到端的時延,端到端時延最簡單的計算邏輯就是距離,距離產生的時延基本就是光纖傳輸時延,大概就是100公里1毫秒。所以在5G時代,端到端時延的本質就是距離所產生的光傳輸時延。
我們用這個思路再對照看下之前的2/3/4G的情況。根據OpenSignal的一份測試報告顯示,在2G時代,光纖傳輸時延在整體端到端佔比是微不足道的,也意味著空口時延佔了大頭。
而在5G時代,這個比例高達60%,光纖傳輸也就是地理位置將會極大地影響端到端的時延,進而影響到使用者體驗。因此,5G低時延的特性如果需要得到更好的發揮,就必須通過更近的業務部署來降低傳輸在整體時延中的佔比,而在IT領域的邊緣計算技術就能很好的契合這樣的需求,成為促進移動邊緣計算髮展的驅動力之一。
高頻寬
5G的另一個特性就是高頻寬。5G高達10G的峰值速率,一方面能讓使用者看到更清晰的視訊,享受沉浸式的業務體驗,但另一方面,也會給業務方傳統的集中雲部署方式帶來可能翻數倍的流量成本,當然也給運營商整體的網路頻寬建設提出了挑戰。這就需要我們重新來審視一下網路架構,考慮流量從集中雲到邊緣雲的解除安裝。在這裡,再一次找到了5G和邊緣計算的契合點,通過業務的邊緣部署,降低了回傳鏈路的頻寬消耗,降低成本的同時還降低了時延。
大連線
在一個標準的物聯網場景下,可能會生成海量的資料,如果這些資料都集中到雲上去做處理就可能造成資源的浪費。如果在中間位置進行資料預處理,一方面可以儘快的進行下行反饋,形成物聯網的系統閉環,另一方面可以做上行的資料聚合,形成物聯網的群體智慧。
這樣的中間位置就是邊緣計算的部署點,因此結合上面對5G特性,也就是5G核心能力的分析,我們就可以得出這樣的結論:5G的核心能力將成為移動邊緣計算髮展的最大驅動力。
如果僅僅從資源更近這個角度來思考5G下的邊緣計算,那就太簡單了。從本質上來說,邊緣計算是屬於網際網路IT域的概念,而5G是屬於通訊網CT(CommunicationTechnology)域的概念,要想把5G下的邊緣計算用好就必須進行IT和CT的融合,而不是簡單的1+1。這裡的融合分為架構融合、部署融合和排程融合。
架構融合:獨立標準設計走向融合架構設計
從架構融合來講,5G包括UPF(User Plane Function,使用者面功能)核心網這些支撐邊緣計算功能網元和系統的架構規劃都放在了3GPP(3rd Generation Partnership Project,第三代合作伙伴計劃)這個國際化組織,而邊緣計算的整體架構則歸屬在ETSI(European Telecommunications Sdandards Institute,歐洲電信標準協會),各組織都在自己的方向上獨立演進,因此首先要融合的就是架構,形成一體化,融合的架構設計。
部署融合:雙車道獨立部署走向一體化部署
部署融合裡的部署重點關注的就是UPF和MEC(Multi-access Edge Computing,多接入邊緣計算)節點的部署。UPF作為移動網的網元,運營商會根據自己的規劃進行部署,而MEC節點則歸屬於網際網路公司,結合自己的應用場景、受眾來部署,兩者歸屬不同車道,因此可能會存在部署不一致的問題,進而讓邊緣計算的收益大打折扣。所以我們需要從雙車道的獨立部署走向一體化部署。這也就關聯到了第三個融合,就是排程融合。
排程融合:互不感知的域內排程走向全域排程
由於UPF和MEC節點所服務的使用者不同,造成兩者的流量模型產生很大的差異,承載服務所需要的網路指標也不盡相同。雙方為了兼顧效能、容量、成本和服務品質等因素,在各自系統中部署自己獨立的排程系統,如果這樣的系統做不到互相感知,就會造成彼此流量走向的不一致,其後果不僅會讓排程效果大打折扣,更可能出現事與願違的情況。因此,我們需要從互不感知的域內排程走向全域排程。
綜上,5G時代的邊緣計算首先要考慮的就是融合。
通常意義上的邊緣計算我們都會簡單地等同於IP流量排程。到了5G時代,大家也會簡單類比UPF到MEC節點就是牽引一條IP資料流,把感興趣的流量牽引過來即可。但實際上5G下的邊緣計算可以做更多。
從面向流量演化為面向服務
第一就是可以從面向流量的經營增強為面向服務的經營。我們牽引過來的不僅僅是流量,而是流量上面所承載的服務,服務將會賦予流量更多的意義,因此在進行排程的時候,更多需要考慮的是流量所承載服務的要求而不是單純的資料流。所以5G下的邊緣計算需要從面向流量演化為面向服務。
從面向服務的角度出發,5G邊緣計算如果僅僅是作為一種離使用者更近的服務部署來定位的話,那就降低了5G邊緣計算的價值。除了近所帶來的更低時延這個顯而易見的優勢之外,我們需要進一步關注和實現服務增強。
從服務更近演化為服務更強
由於行動網路本身的架構特性,相對於傳統的固網架構,移動網採用的是使用者面流量和控制面管控兩條腿走路的模式。邊緣計算牽引的是使用者面流量,但還可以通過與移動網互動從而獲得更多控制面的資訊,比如SINR,Cell Load等資料。這些控制面的資料可以給服務更多的能力組合,進一步增強邊緣計算的對外服務能力,甚至能開拓出新的業務場景。比如在牽引流量的同時,帶上控制面所看到的整體小區負荷、訊號強度等資料,這些資料可以用於伺服器端進行更好地擁塞控制,從而讓上層業務適應到對應的無線環境,進一步提升了使用者體驗。
**從通用服務演化為5G邊緣服務
**
最後,由於有了邊緣計算的存在,原來網際網路普遍的「使用者端/伺服器」的架構也會變成「使用者端/邊緣端/伺服器端」的架構,因此必須考慮到邊緣在整體鏈路中的角色,考慮到5G帶來的增強服務。在5G時代,邊緣部署的服務不能只是簡單的雲服務的就近部署,必須從通用服務演化為5G邊緣服務,只有這樣才能真正用好5G邊緣計算。
首先,我們強調一個前提,邊緣計算一定不是孤立的,我們將邊緣計算視為雲端計算的延伸,拓展雲的邊界。邊緣作為終端與雲中心之間的資料紐帶,對形成「雲-邊-端」一體的計算形態至關重要。
雲端計算最大的優勢就是規模化的計算集約,因此能夠獲得巨大的降本增效收益,但是把全部的計算都集中在一個點顯然不現實,除了計算成本之外,另外一個影響計算分佈形態的至關重要的因素就是資料的傳輸成本。「雲-邊-端」一體的計算協同形態,其實就是資料在網路中的傳輸成本和計算集約收益之間形成的動態平衡狀態。在這個形態下,我們通過不斷地網路基礎設施和技術能力革新,去影響計算集約的分佈狀態。
分佈在全球的數十個中心雲Regions是雲端計算的核心大腦,基於大規模集中的計算資源提供超強、高效的算力。資源集約化,也大幅降低了單位算力的成本,同時相對而言,到終端的平均資料傳輸成本也比較高。
從雲中心往外下沉延伸,是運營商網路,連線著數以百計的運營商資料中心,這也是第一層邊緣計算分佈節點,提供中小規模集中算力,用於覆蓋省一級的就近計算和流量排程。同時,在這一層邊緣計算節點基於大量廣分佈的資料中心構建一個SD-WAN(軟體定義廣域網)網路,負責回雲加速、邊到邊加速,提供「雲-邊」和「邊-邊」協同能力,遮蔽中心雲與邊緣雲之間因網際網路傳輸的網路波動對業務層資料傳輸造成的影響。相比中心雲,在這一層計算節點,計算集約帶來的收益相對變小,但與終端之間的資料傳輸成本也顯著降低。
5G,讓邊緣計算繼續下沉延伸到運營商地市都會網路,將來會連線著數以萬計的MEC節點,這是第二層邊緣計算分佈節點,提供小微規模集中算力,用於覆蓋地市一級的就近計算和流量排程。因為MEC節點距離終端更近了一步,更低的時延和更低的成本,讓更多原本只能在終端進行的計算能夠上移至邊緣,從而形成算力集約,最終帶來成本收益。而且,5G釋放出來更多的終端到邊緣之間的網路傳輸品質管控能力,可以讓我們基於場景來優化「端-邊」的網路服務品質,達到降低成本的同時並未降低使用者體驗。
綜上,通過一個整體的從雲到邊再到端的網路體系,形成雲網一體化的能力,讓不同業務場景能夠在這樣一體化的形態中找到最適合自己的計算分佈形態。
在雲網一體化的能力中,業務場景除了成本之外,最關注的就是網路QoS(Quality of Service,服務品質)。「雲-邊-端」這樣一個長鏈路下,不同分段所採用的QoS策略也不盡相同。
這裡列舉了三種不同的資料傳輸場景:
分解一下全鏈路的QoS分段,可以分為以下三段:
在5G核心網/MEC這個範圍內,QoS策略的管控,需要基於運營商5G能力對接來實現,這一段QoS保障可以大幅度提升終端接入這一段的網路品質。
在MEC到資料中心這一段,是運營商網際網路的範疇,我們在這一段網路中基於廣分佈的資料中心資源構建一張Overlay SD-WAN網路,從而實現對網際網路波動的遮蔽和業務流量管控排程。
在資料中心到雲中心之間,在運營商網際網路的基礎上,輔以運營商專線來進一步改善回雲傳輸鏈路的網路品質。
最終,將這三段網路的QoS管控排程能力整合,為上層業務應用提供端到端全鏈路一體化的QoS保障能力,從而大幅降低業務應用層面運維複雜度。
邊緣計算,促使計算形態發生變化,讓更多的業務場景落地成為可能,但同時計算形態和分佈的多樣性也大幅度提升了技術複雜度。5G並不只是讓邊緣計算更近,阿里雲的邊緣計算,要為業務遮蔽複雜的計算分佈和資料協同,從而幫助更多的業務場景落地到「雲-邊-端」一體的計算形態中,實現收益/成本最大化。
原文連結:https://developer.aliyun.com/article/775642?
版權宣告:本文內容由阿里雲實名註冊使用者自發貢獻,版權歸原作者所有,阿里雲開發者社群不擁有其著作權,亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協定》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容,填寫侵權投訴表單進行舉報,一經查實,本社群將立刻刪除涉嫌侵權內容。