我們有幸請到虎牙直播的5G首席架構師——林正顯老師，為我們介紹5G低延時的誤區和機會。本文從介紹5G低延時原理開始，一步步解開大眾對5G低延時的5個誤區，最后分享了虎牙直播在建設低延時確定性網絡技術的想法以及5G在其他場景的應用。

大家好，我叫林正顯，來自虎牙直播，今天一起聊聊5G低延遲相關的一些問題。想起談這個話題是因為虎牙在做一些5G的落地實踐時候，發現工程上的數據和宣傳上、媒體上的數據有很大差別。我們做了很多的探索和分析。今天把我們所思，所想，所見分享給大家。

我們想先講一下何為5G低延時？它是如何實現的，我會剖析一下5G低延時的誤區；另外包括MEC（多接入邊緣計算），它和5G是密切相關的；還有虎牙在5G低延時或MEC上的一些實踐；最后聊一聊虎牙在5G低延時方面的思考，以及未來的挑戰與機會。

關于5G的一些報（wu）道（dao）

在過去的一兩年，5G一直都是比較熱門的一個話題，很多媒體都做了大量的報道。左邊這個圖告訴我們，Wi-Fi在人多的時候帶寬不怎么樣，4G馬馬虎虎，但是5G非常迅速；5G另一個應用是——遠程駕駛，號稱可以利用5G超低延時，足不出戶駕駛千里之外的汽車；還有一些說5G可以大大提高下載的速度。以上這些報道，真真假假，大家聽完今天我的講解后會有自己的理解和認知。

5G延時的定義

什么是5G的低延時？在3GPP里對5G低延遲有非常明確的定義：對于URLLC（高可靠、低延時通訊場景）上下行的標準值為0.5毫秒（RTT 1毫秒）。對于eMBB（增強型移動寬帶場景）上下行的延遲各4毫秒。我們平時上網、直播、刷視頻等幾乎都是eMBB服務。

5G為何能做到低延時

5G是如何做到低延時的？在無線方面，也就是手機端到基站采用了哪些措施？在核心網內側5G和3G、4G有什么區別？

我們簡單講一下這個圖。不管是5G、4G還是3G，如果之前沒發送過數據，我們的手機要上行數據到公網或者基站，這和我們在課堂上舉手回答問題類似。首先要向基站申請一個上行的無線資源，基站根據當前負載情況合理分配，并提供一個可以發送的時間及無線資源返回給用戶，隨后用戶再完成數據發送。這個舉手的時間是一個周期性窗口，不是隨時待命的，我們稱這叫做——調度請求。

調度請求引入了延時，它在整個無線方面的延時中占比是不低的。在5G需要低延時，我們通過配置把調度的過程去除，可以認為，只要有數據抵達，在配置的時間窗口就可以直接發送，不再需要額外的申請。

另外就是Slot，5G支持的是mini-slot。Slot中文翻譯為時隙，在4G和5G中，一個時隙可以分為7個或14個symbol，一個symbol對應一個正弦波的波長周期。對于4G來說，子載波的頻寬是15khz，所以一個symbol就是1/15毫秒，整個slot就是大約1毫秒，這是4G調度基本單位。

在5G中也是如此，Slot始終是一個基本的調度單位。但是到了5G呢，它的子載波的頻寬可以更寬，達到30khz、60khz、120khz甚至240khz，那么它一個symbol的時長也會成比例下降，因此整個調度的周期就可以變得更短。所以在極端情況下，5G完整的調度周期可以低至幾十微秒。更進一步，5G可以支持mini-slot，可以只用2個symbol來做調度基本單位，這時調度周期可以控制在微秒級別。另一種情況，在使用eMBB服務時，因為調度單位是1毫秒，我正在發送eMBB的數據時，URLLC（更高優先級）的數據來了，這時可以暫停eMBB的發送，在原來無線資源的信道上，先發送URLLC的數據，這個叫做搶占式調度。這樣可以保證更高優先度的數據可以更快的發送出去。

最后一張圖描述的是傳輸的可靠性。低延時和傳輸可靠性有密切的關系，由于傳輸不可靠導致丟包重傳，客觀上會導致延時的升高。5G的做法是冗余，一份數據包作多份拷貝，通過不同的子載波，不同的信道把相同的數據發出去，這里不同的載波可能是同屬一個基站的兩個載波，甚至可能是兩個基站的不同載波，通過冗余來保證發送可靠性從而做到穩定性。此外，在極端情況下保證可靠性時，可能需要犧牲一部分無線的效率，采用抗干擾性更強的調制方式來做傳輸。比如原本可以用16QAM的調制方式，但是為了穩定性，我選擇了QPSK。在空口上大致就這些措施。

在核心網上，從3G開始，移動網絡要上公網的話會經過網關（移動網絡和公網之間的數據網關）。在WCDMA里我們叫GGSN，在4G里我們叫P-GW，而5G里叫UPF，名字雖不同，但都是網關。在3G、或4G時，網關在每個省只會在1、2個地方部署，比如在廣東省大概率就部署在廣州或深圳或東莞，其他地方即使訪問同城的服務器，也會經過基站，經過核心網以及剛才提到的網關，繞一圈之后再回到原來的服務器，過程非常曲折。

但是5G就可以把網關下沉到離我們訪問基站較近的地方，甚至就在同一個機房，我們稱為UPF的下沉。參看右圖的綠線，我們通過基站，基站連接本地UPF，直接到城域網，然后就可以訪問到本地的服務器了。不需要像黃線一樣千里迢迢跑到廣州，經過骨干網，再到城域網最后才能訪問。

如何進行分流，運營商是有策略的，通過上行分流器來做到這一點，這里我們不細講。

聽起來5G在低延時方面還是做了很多事情的，感覺上也很靠譜，5G低延時特效也被大眾津津樂道。但是非常遺憾的是大家在討論這個話題的時候，很多人的理解還是有一些偏差的。

理論極延時與實際延時混為一談

理解誤區 #01

第一，我們很容易把5G理論延時和實際延時混為一談，尤其是媒體的朋友們，有意無意地在做一些引導。

我們來詳細看看之前提到的“調度”的過程。當我們有一項數據在手機上即將產生的時候，我們并不能馬上發送出去，我們需要等一個周期性配置的“調度請求”（SR）的窗口（比如1毫秒、80毫秒），發送SR請求之后（可以理解為在紅綠燈路口按下想要通行那個按鈕的過程）基站收到請求后會判斷用戶的優先級、空口的占用狀況如何等來決定何時給手機發送“授予”grant（在何時在哪個信道上傳數據）授予的信道有可能很小，也許只夠用戶發送一個BSR（緩沖狀態報告），手機會告訴基站現在有20k的數據需要發送，基站收到后知道你有很多數據會授予更多的信道供用戶發送，這是在空口發生的一個事情，也是大部分情況會經歷的過程，無論是4G還是5G。5G的免調度只是把申請SR的過程去掉了，但是對eMBB服務來說不太可能實現，因為需要付出很大的代價。上行的調度請求周期越長，延時就會越大，因為這個過程引入的延時平均是SR周期的一半，運氣好會快一些，運氣不好SR剛過，需要等待下個周期。

如果我們周期配置的足夠小，我們的延時依然能夠保證。理論上來說，即使是4G，延時也可以到幾毫秒。

很遺憾，雖然4G延時數據理論上也能到幾毫秒，但是我們4G實測數據并不理想，虎牙在高峰時期4G用戶到同城服務器RTT超過了40毫秒，同一時刻Wi-Fi用戶到同城服務器RTT大概率在20毫秒以內。

去年有一份白皮書，列舉了很多5G to B的場景，5G在結合了UPF下沉了以后，端到端的基本延時在16~20毫秒之間，這和我們虎牙現網5G的數據也差不多。

為什么現實和理想差距那么大？我們在談論延時的時候，其實包含了處理延時、排隊延時、發送延時和傳播延時。處理延時是指對包進行有效性校驗等操作引入的延時，這時間基本可以忽略不計。傳播延時取決于光速，從A發送到B，通過光纖傳送過去，這一速度我們無法干預，距離足夠短時，這一時間也可以忽略不計。剩下的問題就在于排隊延時和發送延時，這兩個延時我們在后面會詳細展開，在做一般的理論分析時，往往會把它們忽略掉，這是造成我們現實與理想差距的主要原因。還有一個問題是丟包重傳，很多時候不是網絡RTT不好，而是偶爾的丟包導致的重傳，使得實際的延時變高。

不同技術與不同應用場景的

延時混為一談

理解誤區 #02

第二個誤區也能在媒體中經常見到。5G有很多不同的場景和技術，但是報道時，總是挑最領先的技術來說。

比如，5G有三大應用場景，eMBB（增強型無線寬帶）對應大帶寬，URLLC對應高可靠低延時的業務，還有一個mMTC海量機器類型通訊，對應物聯網的廣連接。通常來說，只有自動駕駛等場景需要用到URLLC這種極端的低延時保障，這種端到端的延時可能只有2、3毫秒。

但是有一點不能忽略，為了能夠獲得超低延時需要付出相當大的代價，坦白來說很多場景極端低延時不是必須的，比如瀏覽一個網頁，是否需要一個端到端3毫秒的低延時？因為成本差別很大，我們不可能在所有場景覆蓋低延時。另外除了成本較高的冗余、調制方式等方面的無線措施，還有端到端的低延時也需要非常嚴苛的端到端QoS保障。

4G的QoS是怎么樣的？4G在傳輸數據時有2種承載，一種叫默認承載，一種叫專有承載。默認承載有數據就有可能建立。專有承載針對不同的QoS所要求的流來建立額外的通道。這個承載本身的建立是有一定限定的消耗的。另外它的粒度比較大，因為一個手機通常只能建立幾個到十幾個專有承載。所以在日常生活中很少聽到有對4G QoS的利用，因為它往往只會出現在運營商內部業務，比如給VoLTE這類業務來做一些高優先級的保證，但現在運營商正在慢慢放開。

5G的QoS相對來說更靈活，我們可以根據不同流設置不同PCC的規則，對應不同包的計費和質量保證的規則。它不是基于承載而是基于流，流的標識通常是三元組或是其他特征。

上圖和其他5G QoS圖不太一樣，因為它有涉及多接入技術的QoS。多接入（Multi-Access），比如在3GPP AN里面，5G除了通過空口來連接到目標地址以外，還可以通過非5G，如Wi-Fi等介質同時形成多接入通道，以此保證數據接入可靠性。但是3GPP畢竟代表的是運營商或是設備商的利益，所以這一特性未必能得到廣泛的運用，比如我們在做傳輸時通常會考慮同時使用Wi-Fi、4G、5G或是MP-TCP這種特性來做多路的傳輸，這些我們通常在應用層實現。3GPP試圖在底層將這套方式封裝起來，但就我和其他應用廠商的討論，似乎沒有人愿意為這一方式買單，應用廠商更愿意自己把控這方面內容。另一個與QoS有對應關系的是切片。

這部分內容我不會詳細展開，因為內容過多。切片的目的是為了保證不同業務不同的優先級，但這項技術對手機來說是個“坑”，因為目前市面上5G手機對URSP的支持非常不足，幾乎沒有。雖然3GPP定義出來了，但是短期內，這項技術只能在to B場景應用，比如根據不同的DNN做一些不同切片的接入。對于目前的手機來說，很難從一個切片切換到另一個切片：理論上我們可以給不同的APP或是不同的流特性，映射到不同的切片享受不同的QoS保證，但是目前終端并不支持這項技術。

空口延時與網絡全鏈路混為一談

理解誤區 #03

還有一個更為常見的誤區，我們討論的5G低延遲，其實說的是它空口的延遲，但很多人會把網絡的端到端延時與之混為一談，更有甚者會把業務的端到端混在一起。

我們一直在說的5G低延時，其實說的就是手機到基站的這段低延時。而端到端的過程會經過空口到承載到核心網，從核心網再到公網，經過若干個IDC有可能換到另外一個運營商的核心網，再到接入網最后抵達空口。坦白來說，即使5G的空口可以做到零或一毫秒延時，最多也就是打平了和固網的差距。如果用有線接入的話，事實上空口這個環節怎么樣都是比不過的。我們真正需要的是端到端的低延時，剩下的部分怎么辦？

我們可以參考一下TSN（時間敏感型網絡），它在工業互聯網中是會被用到的網絡，通過這個網絡我們希望能夠得到5G來實現端到端、高穩定的超低延時方案。

最核心的點——冗余。從圖中可以看到，控制器希望控制遠端設備的時候，中間加入了5G網絡。在END STATION，我們就分成了2路，接入2個終端，分別通過不同的傳輸通道進行傳輸。在5G中有不少類似于多鏈路、多路徑的處理，這是值得我們借鑒的方式，鑒于時間原因，我無法展開更多。我想強調的是，端到端的低延時比整個空口的低延時更重要，我們可以從工業互聯網中尋找靈感。

空載延時與帶載延時混為一談

理解誤區 #04

另一個誤區是，大家會把空載（網絡較為空閑時段）的延時和帶載甚至重載時的延時混為一談。

比如在節假日時，我們的高速路口車流擁擠，這個時候我們不會指望能夠快速通行。在網絡中這對應的是排隊延時，排隊等待資源，等待上一個用戶排空緩沖，這是我們延時的一大來源。對于無線用戶來說，每個人都想上傳數據，作為一個基站需要調度數據，那就勢必會造成排隊的現象。除非我的“車道”特別寬（多），每個人都有足夠的車道，但這是難以實現的。

舉一個例子，如果大家對無線網絡感興趣，在很多地方是可以進行測試的。最經典的是在地鐵站，尤其是高峰期的地鐵站，比如北京的西二旗地鐵站。這個車站如果在高峰期測量，同城RTT有可能在200，300毫秒。即使是空載的狀態，清早或大半夜測量，會發現延時也有80毫秒。這和基站的設置是有關系的，回到前面提到的“調度周期”，通常運營商會根據基站的忙閑來對該值做些調整如果我需要保證很多人能同時接入基站，我必須在有限的控制信道內讓更多用戶接入。如此一來，調度周期一定會被拉長，這樣每個用戶才能有接入的機會。我猜想，運營商對于那個點的調度周期設置就是不低于80毫秒，這時平均的RTT就有額外的40毫秒的引入，這也是出現在地鐵站的一個非常有意思的現象。

忽略帶寬對延時的影響

理解誤區 #05

最后一個誤解，我們往往會忽略帶寬對延時的影響。比如我們處理一些小包的時候，延時還是很低的，一旦加載業務，延時就變成15毫秒甚至40毫秒，100毫秒。

在座的很多同行應該是做視頻的，除了無限GOP場景，對視頻進行編碼的時候存在I幀，后面緊接著P幀，可能還有B幀，依次循環。一個I幀很大，可能是P幀的很多倍，這取決于編碼時的參數設定。假設可用帶寬的平均碼率是10兆，如果給我們一個10兆帶寬的平滑流，我們確實可以很快的傳輸出去，但是視頻是突發的，尤其對于I幀來說。最后我們會發現，I幀的傳輸會花費很多時間，甚至阻礙了下一幀，B幀或者P幀的傳輸。這里我列舉一個數據，比如我上傳一個10兆的視頻流I幀可能會達到200kb，這時哪怕使用100兆的帶寬去傳輸，可能也需要16毫秒，這是什么概念？如果在云游戲里，假設幀率是60，2幀的間隔就是16毫秒。也就是說10兆碼流的視頻我需要使用100兆的帶寬傳輸才能讓它不影響下一幀的傳輸。

所以為什么我們說5G對于云游戲的發展是個有利優勢，因為大帶寬帶來的是低延遲。4G很難做到很大的下行速率，而現在很多云游戲的廠商會用到20兆或25兆的帶寬。

低延時與“5G+邊緣計算”

現在我們可以把前面講的所有東西串起來，來聊聊MEC。狹義的MEC我們成為移動邊緣計算，后來3GPP可能覺得不夠酷，把M改成Multi-Access（多接入邊緣計算）把它的范圍擴大了，不再僅僅針對移動。最開始的想法，是利用UPF下沉（拉近出口網關和基站的距離），這時候可以在UPF所在的機房把計算資源和存儲資源放在那里，其優勢在于在與終端用戶距離很短的時候延時會很低。把計算資源放在UPF機房和把計算資源放在中心機房，兩者的延時差距還是挺大的，特別中心機房可能和UPF機房不是同省。

虎牙在邊緣計算方面曾經做過一個嘗試，我們在直播時希望給主播的形象做一些漫畫風格的轉換。但是我們發現很多主播的直播設備性能并不是特別優異，特別是一些低端或中端的手機，所以很難在手機做一些困難的AI風格轉換。這時候我們想，能不能把計算這部分放到云端，利用低延時技術來實現。

大致過程如下，主播的頭像通過鏡頭到CMOS感光之后通過ISP的處理，然后在送到APP，APP做一些前處理，隨后編碼，通過網絡傳過去。邊緣機房的AI節點必須先解碼，隨后在做一些相應的AI處理，這時又要重新編碼一路流，隨后分發給觀眾，另外一路流返回給主播，主播收到流后經過解碼和渲染，這才能看到自己被變換過圖像；這個過程對于主播的感受來說，就像是在手機上完成的一個處理。這是一個非常美好的想法。

主播能感受到的延時就是圖上1~4的步驟。那么大家覺得我們每個階段，比如采集，編碼，傳輸，解碼，渲染延時最高的是哪個階段？其實是采集階段。安卓手機端或iphone11以下的機型，大家拿著攝像頭對著自己，敏感的人是可以感受到延遲的，即使是自己的攝像頭做本地的預覽，延遲的時間在80~120毫秒之間。手機的操作無非就是成像，成像完成以后從傳感器中讀出來，然后送到ISP處理，處理完以后送去做渲染。安卓攝像頭的管線深度和整個架構處理決定了延時的高低，這點當時被我們忽略了。在某些場景下，網絡未必是瓶頸。網絡可以做到很低延時，特別是在傳輸上，RTT20~30毫秒是可以達到的。對于一般的1080P手機編碼就需要30~40毫秒，但是采集很有可能花費3幀的時間。所以我們在嘗試邊緣計算的時候，我們要想我們的瓶頸真的是在網絡上嗎？

5G與Wi-Fi的區別

現在我想講一講虎牙對于5G低延時的思考，我們內部討論了很多關于Wi-Fi和5G的關系。通過全網數據你會發現用戶的兩個通道，一個是Wi-Fi，一個是4G，坦白來說大部分流量還是來自于Wi-Fi，來自于家庭寬帶的流量。對于手機4G用戶來說，也很少會用到運營商提供的超低延時的服務。即使到了5G，我們大概率也不會用到URLLC，也不會用MTC這種物聯網專用網絡，我們使用更多的還是eMBB的業務。

在空口中，eMBB的RTT是8毫秒，而好一點的Wi-Fi可以做到2毫秒。市面上質量較差的Wi-Fi是因為還在使用2.4G頻段（易被干擾）或Wi-Fi 4或較差的AP網關。坦白來說，如果在座各位能夠讓自己平臺所有用戶的Wi-Fi及時升級，相信能減少不少視頻卡頓率。eMBB的理論延時比Wi-Fi的實際延時還會高一些，甚至現在的Wi-Fi 6以及抗干擾的Wi-Fi 6E（使用新頻段，不會受到2.4G或5G的影響），有可能更加拉大了Wi-Fi和5G的延時差距。

我們能做的就是等待，看看5G在現網優化的情況如何，以及毫米波的應用。毫米波并未在我國廣泛使用，我們使用的是SUB-6G的頻段。毫米波覆蓋范圍有限，但是可用的頻寬資源很多，所以可以達到很大的帶寬，在未來會在我國一些熱點技術作為補強的應用。一旦毫米波進入市場，我認為有可能縮小5G和Wi-Fi低延時上的差距，當然能做的只是縮小差距，當然這只是我一家之言。那這時候有個問題就出現了，如果在延時上比不過Wi-Fi，我們如何定位5G？5G在移動性、廣域覆蓋方面比Wi-Fi有優勢，我們不可能背著Wi-Fi到處走，尤其是戶外場景。所以我們需要自己判斷，哪些業務、場景適合使用5G。5G在廣域覆蓋上的優勢值得被關注，我們需要考慮它和我們的業務是否有親和性。

我個人認為類似于AR，AR眼鏡，戶外直播等這種業務和5G就有比較好的親和性。順帶一提，我不會為5G+VR這類產品買單，因為VR和5G并沒有什么關系，VR更多的是在室內的應用，在室內Wi-Fi不比5G更好用嗎？同時5G還存在流量資費的問題。但是AR就不同了，因為我必須要走，必須和現場結合，戶外直播同理。

10毫秒級互動時代

我們還有一個思考，隨著5G技術的進步， 10毫秒級的互動時代即將到來。我們現在還有另一種5G叫F5G，就是所謂的第五代固網，也就是光纖到房間和Wi-Fi 6。它的延時一定是非常低的，而且覆蓋強，帶寬高。說回我們的5G，理論上我們布網布的好，10~20毫秒的RTT還是可以滿足的。即使到了野外，沒有Wi-Fi和5G的覆蓋，我們哪怕用低軌道衛星（300km~500km距離）也能做到20~30毫秒的RTT，也就是說整個世界都能包圍在相對低延時的網絡中。整個鏈條如果能夠建成，我們完全可以做到百毫秒級以內的端到端的延遲。如果說之前我們考慮的更多的是秒級，百毫秒級上的直播的話，現在我們就需要考慮更廣泛的10毫秒級的問題。所以未來Wi-Fi主要是在室內，5G可能主要應用在戶外、商場等。至于野外，以前我們一直很想去西藏直播，有了低軌道衛星后，這也能成為一種選擇。

虎牙的實踐主要是往兩個方向發力發展，實時內容操作和直播互動。我們認為延時會慢慢降低，互動能表現出不一樣的體驗。所以我們投入到大家熟悉的云游戲，還有多人的互動，甚至多人互動游戲結合直播場景，還有虛實結合的互動直播我們也一直在探索。

但在技術層上，我需要一張優秀的端到端的網絡來保證超低延時的互動。除了Wi-Fi（但是它的空口仍有很多優化的空間），運營商也會加大5G QoS開放的力度。我們也會依賴于5G QoS加上多接入（雙鏈路，Wi-Fi 5G同時接入）以及公網多路徑，加上類似于SDWAN的手段來構建一張LDDN的網絡（低延時確定性網絡）。

5G低延時其他落地方向

拋開直播，拋開虎牙，我們來看一看5G低延時有沒有其他場景的落地方向。to B方面我非常看好車路協同的應用，還有邊緣智能；比如視頻應用，上傳視頻到邊緣，邊緣做完處理后做一些結構化或抽取處理，做完后視頻就不會再被送到遠在千里之外的云的中心機房。不管是對于計算還是對于網絡，這都是一個比較好的資源卸載（offloading）。還有一些遠程的控制和協作，工業上AR的應用，舉個例子，我們可以坐在家里能指導歐洲的一個工人修車。當然，還有包括自動駕駛方面。

在to C上有一點要能抓住，就是要明晰5G和Wi-Fi的區別。Wi-Fi能夠做到的事情，沒有人愿意用5G。在國內90%以上家庭是擁有寬帶的，這其中94%還是光纖，所以在中國應該很少在室內需要用5G做一些寬帶的接入。我們要關注哪些應用與5G有親和性。也許未來，自動駕駛進入市場以后，無人駕駛了，那坐在車上可能需要一些娛樂，汽車只能通過無線連接，那就只能用5G。

但是5G低延時仍然存在不少問題，整個國家的5G網絡是在輕載的，現在的延遲還是馬馬虎虎，等到重載之后延遲能維持在多少需要拭目以待。毫米波有自己的優勢，但在國內何時上線？另外我們更關注業務中端到端的低延時，這依賴于整個生態鏈的成熟，我在之前舉過例子，攝像頭的采集，如果一直存在2~3幀的延遲，那端到端的延時瓶頸就很難突破。還有操作系統本身，攝像頭的延時也和操作系統本身密不可分，比如安卓手機對于相機的設置，整個pipeline的深度決定了延時的高低。另外有一個例子，安卓11 Media Codec2.0對低延時解碼做了一些增強，后面類似的案例會出現的更多。另外，我們編寫應用程序的時候是否為低延時做好了準備，我和很多開發者交流，他們的音頻播放用的還是Java層的API，如果不用openSL ES或AAudio，java那層的音頻播放延遲在手機上會達到200毫秒，這樣前面在網絡層面的一切努力都是徒勞了。

對于技術挑戰來說，前面RTC也提到過。對于虎牙來說，我們想跟進無線接入網的QoS，我們可能依賴于運營商給我們開放的QoS；同時，因為空口的優化在整個鏈路的優化上是遠遠不夠的，我們還會采用多接入（Wi-Fi 5G或Wi-Fi 4G雙鏈路）包括公網上多接入的路由，甚至是多徑的低相關的路由來保證我可靠性的傳輸。這時我構建的不是電信級的確定性的網絡，我們只需要簡配版的，足夠支撐我超低延時的就夠了。市場運營層面上，運營商不停在宣傳5G，但是5G的費用相比Wi-Fi沒有價格優勢，還存在著套餐流量不夠用的問題；此外，未來一定會有延時差異化的產品（低延時和超低延時和一般延時），這涉及到QoS如何推廣的問題。因此，運營商的策略對5G的發展影響很深。

總結

簡單做個總結：5G的延時在理論上和工程數據上是有相當的差距的，我們需要正視這個問題；我們更多的不只是需要空口的超低延時，而是端到端的低延時；5G不是萬能的，它更多的只是從空間維度擴大了你的業務，把你之前無法做到的業務擴展開來；從技術上來說，為了迎接我們的10毫秒級低延時時代，我們需要自建一條累加的低延時確定性網絡。

原文標題：5G低延時的誤區和機會——從理論到工程落地的數據差異

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq