議詳解：從快遞比喻到ARQ重傳機制)
簡介這份資源是面向TD-LTE無線接入網(wǎng)研發(fā)、協(xié)議棧實現(xiàn)與測試人員的RLC協(xié)議中文技術文檔對應《TD-LTE數(shù)字蜂窩移動通信網(wǎng)Uu接口技術要求》第7部分由中國通信標準化協(xié)會組織制定。內(nèi)容圍繞E-UTRA RLC子層展開涵蓋RLC實體結構、上下層業(yè)務關系、AM/UM/TM三種模式的數(shù)據(jù)傳輸機制、錯誤檢測與糾正、協(xié)議數(shù)據(jù)單元格式及參數(shù)定義并對未知與錯誤協(xié)議數(shù)據(jù)的處理方式作出說明同時給出實現(xiàn)架構與測試方法方面的規(guī)定便于讀者對照3GPP TS 36.331等規(guī)范理解空中接口的可靠傳輸設計。壓縮包內(nèi)為1個doc文檔約1.74MB適合作為協(xié)議查閱與開發(fā)對照的手冊。目前已有493人學習適合需要深入掌握LTE層二協(xié)議細節(jié)的工程師與學習者參考。1. 到底什么是 RLC 協(xié)議從寄快遞說起你寄過快遞吧把東西交給快遞員他負責打包、貼單、運輸、派送最后送到收件人手里。如果包裹丟了、破了快遞公司還得負責查件、補發(fā)。在 TD-LTE 這張移動通信網(wǎng)里RLC 協(xié)議干的就是這個活兒——它夾在 MAC 層和 PDCP 層之間專門負責把上層交下來的數(shù)據(jù)“打包發(fā)出去”并且保證該到的到、該對的順序對。RLC 全稱 Radio Link Control中文叫無線鏈路控制。它屬于 Uu 接口協(xié)議棧里承上啟下的一層上面是 PDCP下面是 MAC。你手機上網(wǎng)、發(fā)消息、看視頻數(shù)據(jù)從網(wǎng)絡側一路傳到你的終端中間必須經(jīng)過 RLC 這一關。它決定了數(shù)據(jù)怎么切塊、怎么編號、丟了要不要補、補幾次、什么時候放棄。搞懂 RLC你就搞懂了 LTE 數(shù)據(jù)通道里“可靠性”這三個字到底是怎么落地的。2. RLC 為什么存在沒有它數(shù)據(jù)就是一鍋粥2.1 下層只管“送”不管“送到?jīng)]有”MAC 層和物理層負責的是“把數(shù)據(jù)塊塞進無線資源里發(fā)出去”它們關心的是調度、調制、編碼、HARQ 快速重傳。但無線信道天生不穩(wěn)定信號衰落、干擾、切換都會導致數(shù)據(jù)塊丟失或出錯。MAC 層的 HARQ 能解決一部分快速糾錯可它管不了太細——比如一個數(shù)據(jù)包被切成好幾段某一段反復傳不過去HARQ 重傳次數(shù)用完了怎么辦這時候就需要 RLC 站出來做更上層的“兜底”。打個比方MAC 層像快遞網(wǎng)點的分揀員手速快、動作麻利但只負責把包裹扔上車RLC 層像快遞公司的客服和調度中心負責記錄哪個包裹沒送到、要不要補發(fā)、補發(fā)幾次之后通知寄件人“這單我們賠”。沒有 RLC上層應用收到的數(shù)據(jù)就是亂序的、殘缺的TCP 會瘋狂重傳體驗直接翻車。2.2 三種模式對應三種“可靠性等級”RLC 最核心的設計是它提供了三種數(shù)據(jù)傳輸模式分別對應不同的業(yè)務需求。這不是隨便分的而是根據(jù)“這條數(shù)據(jù)通道需不需要保證送達、需不需要保證順序”來定的。模式全稱是否分段/級聯(lián)是否有 RLC 頭是否重傳典型承載信道TM透明模式否否否BCCH、PCCH、CCCHUM非確認模式是是否DTCHAM確認模式是是是ARQDCCH、DTCHTM 模式最“透明”上層給什么它就往下遞什么不加頭、不切塊、不重傳。廣播信道、尋呼信道、公共控制信道用這種模式因為這些信息本來就是“一發(fā)多收”不需要確認誰收到?jīng)]收到。UM 模式會切塊、加序號、接收端做重排序和重復檢測但不做重傳——丟了就丟了適合對時延敏感、能容忍少量丟包的業(yè)務比如語音通話。AM 模式最完整有發(fā)送窗口、接收窗口、狀態(tài)報告、ARQ 重傳、輪詢機制適合網(wǎng)頁瀏覽、文件下載這種“一個字節(jié)都不能少”的業(yè)務。2.3 分段、級聯(lián)、重分段把數(shù)據(jù)塞進“剛好夠大”的盒子下層 MAC 每次通知 RLC“這次傳輸機會能發(fā)這么多字節(jié)”這個大小是動態(tài)變化的。RLC 不能自己決定發(fā)多大只能根據(jù)下層給的“盒子尺寸”來調整。所以它必須能把上層交下來的大塊數(shù)據(jù)切成小段分段也能把多個小塊拼成一塊級聯(lián)AM 模式下重傳時如果盒子變小了還得把已經(jīng)切好的段再切一次重分段。通俗地說你有一堆大小不一的行李要裝進快遞箱箱子尺寸每次還不一樣。RLC 就是那個負責現(xiàn)場裁切、拼裝、重新打包的人。UM 和 AM 都支持分段和級聯(lián)TM 不支持——因為 TM 走的是廣播類信道數(shù)據(jù)塊大小相對固定不需要這套操作。3. AM 模式為什么最復雜ARQ 和狀態(tài)報告的配合3.1 發(fā)送窗口和接收窗口防止序號繞圈AM 模式用序列號SN來標識每個數(shù)據(jù)包。SN 位數(shù)有限發(fā)著發(fā)著就會繞回來所以必須用“窗口”來限定當前能發(fā)哪些、能收哪些。發(fā)送端維護 VT(A) 到 VT(MS) 的發(fā)送窗口只有落在窗口內(nèi)的 SN 才允許發(fā)出去接收端維護 VR(R) 到 VR(MR) 的接收窗口窗口外的包直接丟棄。這個設計很像停車場車位就那么多車不能無限往里開必須等前面的車走了、車位空出來后面的車才能進。窗口大小由 RRC 配置窗口卡住window stalling的時候發(fā)送端就得停下來等確認這也是為什么 AM 模式需要一套完整的確認機制來推動窗口前移。3.2 輪詢和狀態(tài)報告什么時候問“你收到?jīng)]”發(fā)送端不能干等著對方主動匯報它得在合適的時機“催”一下。RLC 的輪詢機制就是干這個的每發(fā)一定數(shù)量的 PDU 或字節(jié)或者發(fā)送緩存空了就在數(shù)據(jù)包里把輪詢比特置 1要求對端回一個狀態(tài)報告。對端收到輪詢后根據(jù)接收情況構造 STATUS PDU告訴發(fā)送端哪些收到了、哪些沒收到。這里有個關鍵定時器 t_PollRetransmit輪詢發(fā)出去之后啟動如果超時還沒收到狀態(tài)報告就認為輪詢丟了觸發(fā)重傳或者再次輪詢。另一個定時器 t_StatusProhibit 在接收端用防止狀態(tài)報告發(fā)得太頻繁把上行資源占滿。這兩個定時器一收一發(fā)配合起來才能讓 ARQ 既不漏報也不刷屏。3.3 重傳計數(shù)和最大重傳門限什么時候認輸AM 模式不是無限重傳。每個 AMD PDU 有一個 RETX_COUNT 計數(shù)器每次重傳加一達到 maxRetxThreshold 就向上層指示“已達到最大重傳”。這時候 RRC 可能會觸發(fā)重建或者上層決定放棄這條承載。這個門限的存在是為了防止一個永遠傳不過去的包把整條鏈路拖死——無線環(huán)境里確實存在“這個位置就是覆蓋盲區(qū)”的情況死磕沒有意義。4. 常見誤區(qū)RLC 和 MAC、PDCP 到底怎么分4.1 誤區(qū)一RLC 的重傳和 MAC 的 HARQ 是一回事易混點兩者都叫“重傳”都發(fā)生在數(shù)據(jù)傳輸出錯的時候。為什么混名字像位置也挨著初學者容易覺得“下面已經(jīng)重傳了上面還重傳干嘛”。怎么區(qū)分HARQ 是物理層和 MAC 層的快速重傳基于軟合并追求的是低時延、少次數(shù)通常幾次之內(nèi)就要出結果RLC 的 ARQ 是更上層的重傳基于狀態(tài)報告追求的是最終可靠性可以跨很多個傳輸機會。HARQ 解決“這一下沒傳好”ARQ 解決“這一段最終沒送到”。兩者是接力關系不是重復勞動。4.2 誤區(qū)二UM 模式不重傳所以它不可靠、沒用易混點一看到“非確認”就覺得是殘次品。為什么混“確認”和“可靠”在中文里容易被等同。怎么區(qū)分UM 的“不可靠”是相對于“保證送達”而言的但它仍然做了重排序、重復檢測、丟包檢測能保證“收到的順序是對的、重復的不會交上去”。對于語音這種業(yè)務晚到的包比丟掉的包更討厭UM 恰恰是合適的選擇?？煽啃缘燃壥菢I(yè)務需求決定的不是越高越好。4.3 誤區(qū)三TM 模式就是“什么都不做”易混點TM 沒有頭、不分段、不重傳看起來像直通。為什么混功能列表確實短。怎么區(qū)分TM 的“透明”是指對上層數(shù)據(jù)不做修改但它仍然要服從下層的傳輸機會調度仍然要在正確的邏輯信道上收發(fā)。它做的是“不加干預的搬運”而不是“不存在”。廣播信息需要的就是這種搬運方式加了頭反而浪費資源。4.4 誤區(qū)四RLC 的 SN 和 PDCP 的 SN 是一套編號易混點兩層都有序列號都用于排序和重傳判斷。為什么混都叫 SN都出現(xiàn)在包頭里。怎么區(qū)分RLC 的 SN 是“段級別”的管的是 RLC PDU 的收發(fā)和 ARQPDCP 的 SN 是“包級別”的管的是上層數(shù)據(jù)包的加密和按序遞交。一個 RLC SDU 可能被切成多個 RLC PDU每個 PDU 有自己的 SN而 PDCP 的 SN 在更上面一層RLC 看不到也不需要關心。兩者各管一段不能混用。5. 什么時候該翻這份協(xié)議什么時候別硬啃這份《TD-LTE 數(shù)字蜂窩移動通信網(wǎng) Uu 接口技術要求 第 7 部分RLC 協(xié)議》是一份標準類技術報告正文里把 RLC 的實體模型、三種模式的操作流程、狀態(tài)變量、定時器、PDU 格式、參數(shù)定義都寫得非常細。它適合什么人看如果你在做 LTE 協(xié)議棧的開發(fā)、測試、或者需要排查空口數(shù)據(jù)異常這份文檔就是案頭必備——比如你發(fā)現(xiàn)某個 AM 承載頻繁觸發(fā)最大重傳翻到 ARQ 過程和輪詢那一節(jié)對照 RETX_COUNT 和 t_PollRetransmit 的行為就能定位是狀態(tài)報告沒回來還是窗口卡住了。再比如你要確認 UM 模式下 t_Reordering 超時后接收端到底怎么更新 VR(UR)文檔里 5.1.2.2.4 節(jié)寫得明明白白比任何二手資料都準。但如果你只是想大致了解“LTE 數(shù)據(jù)怎么傳的”沒必要從這份文檔的第一頁開始硬啃。它用的是標準文本的寫法大量狀態(tài)變量和條件分支讀起來像法律條文。更合適的路徑是先建立第 2、3 章那樣的框架認知知道 TM/UM/AM 各自干什么、ARQ 和 HARQ 怎么分工然后再帶著具體問題去查對應章節(jié)。我自己的習慣是每次遇到 RLC 相關的異常先把狀態(tài)變量表抄一遍對著流程走一遍再翻文檔確認邊界條件——血淚經(jīng)驗是很多“玄學”問題最后都落在某個定時器的啟動條件上而不是協(xié)議本身寫錯了。提示讀這類標準文檔時重點關注“應”字句和狀態(tài)變量更新條件那些是強制行為帶“能”字的通常是可選能力實現(xiàn)時可以取舍。這份資料把 RLC 從架構到過程到參數(shù)一次講全適合放在手邊當查閱手冊。如果你正在跟 LTE 協(xié)議棧打交道或者想搞清楚空口可靠性到底怎么保證的拿這份中文協(xié)議對照著看比啃英文原版省不少力氣。希望幫到你。本文還有配套的精品資源點擊獲取 TD-LTE RLC協(xié)議詳解：從快遞比喻到ARQ重傳機制
簡介這份資源是面向TD-LTE無線接入網(wǎng)研發(fā)、協(xié)議棧實現(xiàn)與測試人員的RLC協(xié)議中文技術文檔對應《TD-LTE數(shù)字蜂窩移動通信網(wǎng)Uu接口技術要求》第7部分由中國通信標準化協(xié)會組織制定。內(nèi)容圍繞E-UTRA RLC子層展開涵蓋RLC實體結構、上下層業(yè)務關系、AM/UM/TM三種模式的數(shù)據(jù)傳輸機制、錯誤檢測與糾正、協(xié)議數(shù)據(jù)單元格式及參數(shù)定義并對未知與錯誤協(xié)議數(shù)據(jù)的處理方式作出說明同時給出實現(xiàn)架構與測試方法方面的規(guī)定便于讀者對照3GPP TS 36.331等規(guī)范理解空中接口的可靠傳輸設計。壓縮包內(nèi)為1個doc文檔約1.74MB適合作為協(xié)議查閱與開發(fā)對照的手冊。目前已有493人學習適合需要深入掌握LTE層二協(xié)議細節(jié)的工程師與學習者參考。1. 到底什么是 RLC 協(xié)議從寄快遞說起你寄過快遞吧把東西交給快遞員他負責打包、貼單、運輸、派送最后送到收件人手里。如果包裹丟了、破了快遞公司還得負責查件、補發(fā)。在 TD-LTE 這張移動通信網(wǎng)里RLC 協(xié)議干的就是這個活兒——它夾在 MAC 層和 PDCP 層之間專門負責把上層交下來的數(shù)據(jù)“打包發(fā)出去”并且保證該到的到、該對的順序對。RLC 全稱 Radio Link Control中文叫無線鏈路控制。它屬于 Uu 接口協(xié)議棧里承上啟下的一層上面是 PDCP下面是 MAC。你手機上網(wǎng)、發(fā)消息、看視頻數(shù)據(jù)從網(wǎng)絡側一路傳到你的終端中間必須經(jīng)過 RLC 這一關。它決定了數(shù)據(jù)怎么切塊、怎么編號、丟了要不要補、補幾次、什么時候放棄。搞懂 RLC你就搞懂了 LTE 數(shù)據(jù)通道里“可靠性”這三個字到底是怎么落地的。2. RLC 為什么存在沒有它數(shù)據(jù)就是一鍋粥2.1 下層只管“送”不管“送到?jīng)]有”MAC 層和物理層負責的是“把數(shù)據(jù)塊塞進無線資源里發(fā)出去”它們關心的是調度、調制、編碼、HARQ 快速重傳。但無線信道天生不穩(wěn)定信號衰落、干擾、切換都會導致數(shù)據(jù)塊丟失或出錯。MAC 層的 HARQ 能解決一部分快速糾錯可它管不了太細——比如一個數(shù)據(jù)包被切成好幾段某一段反復傳不過去HARQ 重傳次數(shù)用完了怎么辦這時候就需要 RLC 站出來做更上層的“兜底”。打個比方MAC 層像快遞網(wǎng)點的分揀員手速快、動作麻利但只負責把包裹扔上車RLC 層像快遞公司的客服和調度中心負責記錄哪個包裹沒送到、要不要補發(fā)、補發(fā)幾次之后通知寄件人“這單我們賠”。沒有 RLC上層應用收到的數(shù)據(jù)就是亂序的、殘缺的TCP 會瘋狂重傳體驗直接翻車。2.2 三種模式對應三種“可靠性等級”RLC 最核心的設計是它提供了三種數(shù)據(jù)傳輸模式分別對應不同的業(yè)務需求。這不是隨便分的而是根據(jù)“這條數(shù)據(jù)通道需不需要保證送達、需不需要保證順序”來定的。模式全稱是否分段/級聯(lián)是否有 RLC 頭是否重傳典型承載信道TM透明模式否否否BCCH、PCCH、CCCHUM非確認模式是是否DTCHAM確認模式是是是ARQDCCH、DTCHTM 模式最“透明”上層給什么它就往下遞什么不加頭、不切塊、不重傳。廣播信道、尋呼信道、公共控制信道用這種模式因為這些信息本來就是“一發(fā)多收”不需要確認誰收到?jīng)]收到。UM 模式會切塊、加序號、接收端做重排序和重復檢測但不做重傳——丟了就丟了適合對時延敏感、能容忍少量丟包的業(yè)務比如語音通話。AM 模式最完整有發(fā)送窗口、接收窗口、狀態(tài)報告、ARQ 重傳、輪詢機制適合網(wǎng)頁瀏覽、文件下載這種“一個字節(jié)都不能少”的業(yè)務。2.3 分段、級聯(lián)、重分段把數(shù)據(jù)塞進“剛好夠大”的盒子下層 MAC 每次通知 RLC“這次傳輸機會能發(fā)這么多字節(jié)”這個大小是動態(tài)變化的。RLC 不能自己決定發(fā)多大只能根據(jù)下層給的“盒子尺寸”來調整。所以它必須能把上層交下來的大塊數(shù)據(jù)切成小段分段也能把多個小塊拼成一塊級聯(lián)AM 模式下重傳時如果盒子變小了還得把已經(jīng)切好的段再切一次重分段。通俗地說你有一堆大小不一的行李要裝進快遞箱箱子尺寸每次還不一樣。RLC 就是那個負責現(xiàn)場裁切、拼裝、重新打包的人。UM 和 AM 都支持分段和級聯(lián)TM 不支持——因為 TM 走的是廣播類信道數(shù)據(jù)塊大小相對固定不需要這套操作。3. AM 模式為什么最復雜ARQ 和狀態(tài)報告的配合3.1 發(fā)送窗口和接收窗口防止序號繞圈AM 模式用序列號SN來標識每個數(shù)據(jù)包。SN 位數(shù)有限發(fā)著發(fā)著就會繞回來所以必須用“窗口”來限定當前能發(fā)哪些、能收哪些。發(fā)送端維護 VT(A) 到 VT(MS) 的發(fā)送窗口只有落在窗口內(nèi)的 SN 才允許發(fā)出去接收端維護 VR(R) 到 VR(MR) 的接收窗口窗口外的包直接丟棄。這個設計很像停車場車位就那么多車不能無限往里開必須等前面的車走了、車位空出來后面的車才能進。窗口大小由 RRC 配置窗口卡住window stalling的時候發(fā)送端就得停下來等確認這也是為什么 AM 模式需要一套完整的確認機制來推動窗口前移。3.2 輪詢和狀態(tài)報告什么時候問“你收到?jīng)]”發(fā)送端不能干等著對方主動匯報它得在合適的時機“催”一下。RLC 的輪詢機制就是干這個的每發(fā)一定數(shù)量的 PDU 或字節(jié)或者發(fā)送緩存空了就在數(shù)據(jù)包里把輪詢比特置 1要求對端回一個狀態(tài)報告。對端收到輪詢后根據(jù)接收情況構造 STATUS PDU告訴發(fā)送端哪些收到了、哪些沒收到。這里有個關鍵定時器 t_PollRetransmit輪詢發(fā)出去之后啟動如果超時還沒收到狀態(tài)報告就認為輪詢丟了觸發(fā)重傳或者再次輪詢。另一個定時器 t_StatusProhibit 在接收端用防止狀態(tài)報告發(fā)得太頻繁把上行資源占滿。這兩個定時器一收一發(fā)配合起來才能讓 ARQ 既不漏報也不刷屏。3.3 重傳計數(shù)和最大重傳門限什么時候認輸AM 模式不是無限重傳。每個 AMD PDU 有一個 RETX_COUNT 計數(shù)器每次重傳加一達到 maxRetxThreshold 就向上層指示“已達到最大重傳”。這時候 RRC 可能會觸發(fā)重建或者上層決定放棄這條承載。這個門限的存在是為了防止一個永遠傳不過去的包把整條鏈路拖死——無線環(huán)境里確實存在“這個位置就是覆蓋盲區(qū)”的情況死磕沒有意義。4. 常見誤區(qū)RLC 和 MAC、PDCP 到底怎么分4.1 誤區(qū)一RLC 的重傳和 MAC 的 HARQ 是一回事易混點兩者都叫“重傳”都發(fā)生在數(shù)據(jù)傳輸出錯的時候。為什么混名字像位置也挨著初學者容易覺得“下面已經(jīng)重傳了上面還重傳干嘛”。怎么區(qū)分HARQ 是物理層和 MAC 層的快速重傳基于軟合并追求的是低時延、少次數(shù)通常幾次之內(nèi)就要出結果RLC 的 ARQ 是更上層的重傳基于狀態(tài)報告追求的是最終可靠性可以跨很多個傳輸機會。HARQ 解決“這一下沒傳好”ARQ 解決“這一段最終沒送到”。兩者是接力關系不是重復勞動。4.2 誤區(qū)二UM 模式不重傳所以它不可靠、沒用易混點一看到“非確認”就覺得是殘次品。為什么混“確認”和“可靠”在中文里容易被等同。怎么區(qū)分UM 的“不可靠”是相對于“保證送達”而言的但它仍然做了重排序、重復檢測、丟包檢測能保證“收到的順序是對的、重復的不會交上去”。對于語音這種業(yè)務晚到的包比丟掉的包更討厭UM 恰恰是合適的選擇?？煽啃缘燃壥菢I(yè)務需求決定的不是越高越好。4.3 誤區(qū)三TM 模式就是“什么都不做”易混點TM 沒有頭、不分段、不重傳看起來像直通。為什么混功能列表確實短。怎么區(qū)分TM 的“透明”是指對上層數(shù)據(jù)不做修改但它仍然要服從下層的傳輸機會調度仍然要在正確的邏輯信道上收發(fā)。它做的是“不加干預的搬運”而不是“不存在”。廣播信息需要的就是這種搬運方式加了頭反而浪費資源。4.4 誤區(qū)四RLC 的 SN 和 PDCP 的 SN 是一套編號易混點兩層都有序列號都用于排序和重傳判斷。為什么混都叫 SN都出現(xiàn)在包頭里。怎么區(qū)分RLC 的 SN 是“段級別”的管的是 RLC PDU 的收發(fā)和 ARQPDCP 的 SN 是“包級別”的管的是上層數(shù)據(jù)包的加密和按序遞交。一個 RLC SDU 可能被切成多個 RLC PDU每個 PDU 有自己的 SN而 PDCP 的 SN 在更上面一層RLC 看不到也不需要關心。兩者各管一段不能混用。5. 什么時候該翻這份協(xié)議什么時候別硬啃這份《TD-LTE 數(shù)字蜂窩移動通信網(wǎng) Uu 接口技術要求 第 7 部分RLC 協(xié)議》是一份標準類技術報告正文里把 RLC 的實體模型、三種模式的操作流程、狀態(tài)變量、定時器、PDU 格式、參數(shù)定義都寫得非常細。它適合什么人看如果你在做 LTE 協(xié)議棧的開發(fā)、測試、或者需要排查空口數(shù)據(jù)異常這份文檔就是案頭必備——比如你發(fā)現(xiàn)某個 AM 承載頻繁觸發(fā)最大重傳翻到 ARQ 過程和輪詢那一節(jié)對照 RETX_COUNT 和 t_PollRetransmit 的行為就能定位是狀態(tài)報告沒回來還是窗口卡住了。再比如你要確認 UM 模式下 t_Reordering 超時后接收端到底怎么更新 VR(UR)文檔里 5.1.2.2.4 節(jié)寫得明明白白比任何二手資料都準。但如果你只是想大致了解“LTE 數(shù)據(jù)怎么傳的”沒必要從這份文檔的第一頁開始硬啃。它用的是標準文本的寫法大量狀態(tài)變量和條件分支讀起來像法律條文。更合適的路徑是先建立第 2、3 章那樣的框架認知知道 TM/UM/AM 各自干什么、ARQ 和 HARQ 怎么分工然后再帶著具體問題去查對應章節(jié)。我自己的習慣是每次遇到 RLC 相關的異常先把狀態(tài)變量表抄一遍對著流程走一遍再翻文檔確認邊界條件——血淚經(jīng)驗是很多“玄學”問題最后都落在某個定時器的啟動條件上而不是協(xié)議本身寫錯了。提示讀這類標準文檔時重點關注“應”字句和狀態(tài)變量更新條件那些是強制行為帶“能”字的通常是可選能力實現(xiàn)時可以取舍。這份資料把 RLC 從架構到過程到參數(shù)一次講全適合放在手邊當查閱手冊。如果你正在跟 LTE 協(xié)議棧打交道或者想搞清楚空口可靠性到底怎么保證的拿這份中文協(xié)議對照著看比啃英文原版省不少力氣。希望幫到你。本文還有配套的精品資源點擊獲取