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