尧图网页设计 
简介这份长期演进协议原理电子文档面向移动通信专业学生、四代网络工程师及协议初学者用于系统理解长期演进系统的协议架构、无线帧结构与各层功能。整包共1个PDF文件压缩后大小1.72MB内容紧凑适宜随时查阅。目前已有97人浏览学习可作课程同步参考或自学补充资料。文档先介绍长期演进整体架构区分用户平面与控制平面再逐层讲解协议栈物理层包含无线帧结构、物理信道、传输信道及相互映射数据链路层详细说明媒体接入控制子层的逻辑信道与关键功能并介绍无线链路控制子层的透明模式、非确认模式、确认模式及协议数据单元结构。目录层级清晰从系统概述到协议细节循序渐进能帮助读者建立从物理传输到高层控制的完整认知适合正式学习前导览与考前系统回顾。1. LTE协议原理这份PDF到底在讲什么、适合谁读刚转4G领域的人拿到《LTE协议原理》PDF很容易被3GPP那几千页标准文档吓退。这份讲义的优势在于它是一套按授课顺序组织的课程材料从整体架构讲到物理层、数据链路层、RRC/NAS最后落到六条典型信令流程目的不是让你背标准而是让你在最短时间内建立起“LTE协议到底怎么运转”的框架。它适合三类人刚转LTE的协议测试、负责覆盖优化的网优以及做modem或核心网信令分析却始终没把协议栈串起来的人。读完这份讲义你能说清eNodeB和EPC的接口关系、一个无线帧里特殊子帧的作用、MAC/RLC/PDCP各管哪一段以及开机附着时UE和网络先后交换了什么。这是后面看实网log、跟问题单的基础。2. 从整体架构到协议栈为什么LTE把网络拍扁了2.1 E-UTRAN与EPC接口、网元和扁平化的理由讲义第1章给出的拓扑图是整份文档最值得先吃透的一张图。LTE/SAE把无线网和核心网分别叫做E-UTRAN和EPC整个系统称为EPSEvolved Packet System。无线侧只剩一个网元eNodeB它把UMTS里NodeB和RNC的职责几乎全包了物理层、MAC层、RRC层外加调度、接入控制、承载控制、移动性管理和小区间无线资源管理。核心网侧的MME/S-GW被看作边界节点类似UMTS里的SGSN但它已经不再管理无线资源。理解LTE架构关键是先理解“拍扁”这件事。UMTS是NodeB加RNC两级结构RNC集中控制一批NodeB好处是调度集中、干扰协调方便坏处是网元多、部署重、用户面时延大RNC本身还容易成为单点瓶颈。LTE把RNC的功能全部下沉到eNodeBeNodeB之间用X2接口直接互通形成Mesh型逻辑网络每个eNodeB再用S1接口连接MME/S-GWS1也是全部或部分Mesh一个eNodeB可以连多个MME/S-GW反过来也成立。原UMTS的Iub、Iur、Iu接口在LTE里被大幅度简化对应关系如下表原UMTS接口LTE对应变化说明IubNodeB到RNC消失RNC职能并入eNodeB不再有独立RNCIurRNC到RNCX2eNodeB之间互联负责切换与干扰协调IuRNC到核心网S1eNodeB到MME/S-GW分S1-MME和S1-U读这段时别急着背接口名先问自己三个问题用户面数据从基站出来后走哪条路径控制面信令走哪条路径切换时两个基站之间要交换什么把这三个问题回答清楚接口自然就记住了。实际工作中做基站间切换排查时S1-MME和X2是最容易混淆的后面避坑章我会展开讲。扁平化带来的收益讲义写得很直接一共三条网络扁平化让系统时延明显减小用户体验和实时业务表现变好网元数目减少部署更简单、维护更容易取消RNC集中控制避免单点故障。做网优的人会额外在意最后一条因为小区间无线资源管理被放到了X2接口上相邻eNodeB之间直接协商干扰控制的思路和UMTS时代完全不同。2.2 用户面与控制面协议栈各层是谁的活协议栈按用途分成用户面和控制面这是后续所有章节的地图。用户面从上到下依次是PDCP、RLC、MAC、PHY这些子层在网络侧全部终止于eNodeB控制面在用户面基础上增加了RRC层和NAS层其中RRC终止于eNodeBNAS终止于MME。这句话决定了LTE控制面的边界也是排查信令问题时判断消息归属的依据。协议层控制面终止点主要职责NASMMEEPS承载管理、鉴权、空闲态移动性处理、寻呼消息、安全控制RRCeNodeB广播、寻呼、RRC连接管理、无线承载控制、移动性、测量上报和控制PDCPeNodeBROHC头压缩、加密与完整性保护RLCeNodeB分段与重组、ARQ重传、按序投递MACeNodeB逻辑信道到传输信道的映射、调度、HARQ、复用PHYeNodeB编解码、调制解调、MIMO天线处理、射频处理这里有个容易被忽略的细节控制面里的PDCP、RLC、MAC执行的功能和用户面完全一致。也就是说RRC/NAS信令同样要经过加密、分段、调度和物理层处理只是内容不是IP数据包而是控制消息。很多做信令分析的人把RRC和NAS看成挂在协议栈之外的“特殊消息”其实它们走的同样是PDCP到MAC到PHY这条流水线只是承载它们的SAP不同。按照我的习惯读协议栈最好的方式是“顺着一条消息走一遍”。以RRC连接建立请求为例UE的RRC层组装消息交给PDCP做加密和完整性保护再经RLC分段MAC把分段后的数据拼进传输块最后PHY调制成无线信号发出去。这条链路走通之后后面所有信令流程读起来都是顺的不会再觉得每一章是独立的知识点。2.3 从IP包到天线一整套下行处理流水线讲义第1章给出的下行数据处理框图值得反复看。IP包进入PDCP之后第一步做ROHC头压缩把IPv6那40字节的头压到几个字节VoLTE这类小包业务收益最明显随后做加密和完整性保护。RLC拿到数据后做分段和连接传输块大小是调度决定的IP包不一定刚好匹配分段就是为了把数据塞进当前分配的资源AM模式下RLC还负责ARQ重传。MAC层做逻辑信道的复用和优先级处理多个无线承载的数据按优先级拼进一个传输块同时通过HARQ做快速重传。PHY层最后做Turbo编码、调制、天线映射和资源映射把数据真正送到空口。接收端的处理正好反向PHY解调译码MAC解复用并把HARQ的软合并结果交给RLCRLC做重组和按序投递PDCP解头压缩、解密最后还原成IP包。这套流水线正好对应讲义后面的每一章PDCP管头压缩和安全RLC管分段和重传MAC管复用、调度和HARQPHY管无线传输。我读这份讲义时的方法很简单每学完一层回到这张流水线图把对应环节标一遍避免只看单层细节丢掉整体。这也是我带转岗同事时反复强调的先有流水线再抠层内部细节。3. 物理层关键参数帧结构、带宽、调制编码和信道映射物理层章节是整份讲义里参数最密集的部分也是很多人读“懂”了却答不出题的部分。核心问题只有三个无线帧在时域上怎么切资源块在频域上多宽数据从哪个传输信道走到哪个物理信道把这三件事抓住物理层就算立住了。3.1 无线帧结构10ms、半帧、子帧与特殊子帧时域上的所有时间定义都以基本时间单位Ts1/30720000s为基准系统中的所有时隙都是这个基本单位的整数倍。每个无线帧Tframe10ms等于307200个Ts每帧分成10个1ms的子帧也就是30720个Ts每个子帧内部是两个0.5ms的时隙。帧与帧之间进一步分成两个5ms的半帧每个半帧由4个数据子帧和1个特殊子帧组成。特殊子帧总长度1ms包含三个特殊时隙DwPTS下行导频时隙、GP保护间隔、UpPTS上行导频时隙。TDD模式下特殊子帧的配置决定上下行转换点的位置GP的作用是避免下行信号到达UE时UE自己的上行发射造成干扰——GP越长可支持的覆盖半径越大。这是我在现场最常被问到的地方也是为什么讲义里要把长短两套CP方案和GP放在一起讲。帧结构建议这样记先记10ms和1ms两个数再补一个30720Ts剩下的半帧、特殊子帧、时隙都是从这两个数推出来的。时间线画成一行10ms等于两个5ms半帧每个半帧里4个数据子帧加1个特殊子帧特殊子帧拆成DwPTS、GP、UpPTS三段。频域概念另起一行画两条线错开不容易混淆。时间单位数值换算关系基本时间单位Ts1/30720000秒系统所有时隙的基准无线帧10ms307200 Ts半帧5ms153600 Ts子帧1ms30720 Ts时隙0.5ms15360 Ts特殊子帧1msDwPTS GP UpPTS提示面试和考试里最常被追问的是“为什么是30720”因为1秒除以1/30720000正好是307200001ms是它的千分之一就是30720。这个数不是玄学是定义推导。3.2 频域与调制参数1.4MHz到20MHz带宽怎么配出来的频域参数集中在几个数字上。子载波间隔15kHz最小资源块RB是180kHz也就是12个子载波宽度通过合理配置子载波数量系统支持1.4MHz到20MHz的灵活带宽配置。20MHz对应100个RB这是LTE最常见的满配做吞吐测试时一看带宽和RB数量就能估算理论峰值。下行用OFDMA上行用SC-FDMA。选SC-FDMA不是因为性能更好而是因为单载波方案的峰值平均功率比PAPR低终端功放可以做得更小、更省电这是从终端体积和成本出发的工程选型。CP有两种长度短CP是基本配置抗多径能力够用长CP用于大范围小区覆盖和多小区MBMS广播覆盖半径可以做到接近100km代价是每个OFDM符号能承载的数据变少。调制、编码和天线参数可以压成一张速查表参数取值说明子载波间隔15kHzOFDM符号的频域间隔资源块RB180kHz12个子载波最小调度单位系统带宽1.420MHz通过RB数量灵活配置双工方式FDD / TDD帧结构不同TDD带特殊子帧调制方式QPSK、16QAM、64QAM上下行均支持信道编码Turbo码R1/3两个8状态子编码器加内部交织器MIMO天线下行2×2上行1×2最大4×4支持发射分集、空间复用、预编码读这些参数的标准动作是“互相推导”12个子载波乘15kHz等于180kHz100个RB乘180kHz约等于18MHz加上保护带宽就是20MHz所以20MHz系统配100个RB1ms等于30720个Ts一个RB在时域上占1ms时正好是12个子载波乘以7个OFDM符号。能自己推出来比背参数表有用得多。3.3 传输信道与物理信道映射关系是物理层的核心地图讲义把信道从功能上切成了两层传输信道描述“以什么特征传数据”物理信道描述“实际在空口上用什么资源传数”。这个区分是理解后面调度、寻呼、随机接入的前提。下行传输信道有四个BCH固定的预定义传输格式在整个小区覆盖区域内广播DL-SCH支持HARQ、链路自适应、波束成形、DRX和MBMS传输PCH在全小区发送寻呼支持UE的DRX省电MCH支持MBSFN多小区MBMS传输合并。上行传输信道有两个UL-SCH支持通过调整发射功率和调制编码格式实现动态链路自适应支持HARQ和动态/半动态资源分配RACH承载有限控制信息支持冲突碰撞解决。物理信道这侧下行有PDSCH、PBCH、PMCH、PDCCH、PCFICH、PHICH上行有PUSCH、PUCCH、PRACH。映射关系用一句话概括DL-SCH映射到PDSCHBCH映射到PBCHPCH映射到PDSCH上的动态资源MCH映射到PMCHRACH映射到PRACHUL-SCH映射到PUSCH。传输信道物理信道方向典型内容BCHPBCH下行MIB主信息块DL-SCHPDSCH下行用户数据、SIB、寻呼、切换消息PCHPDSCH动态资源下行寻呼消息MCHPMCH下行MBMS业务UL-SCHPUSCH上行用户数据、上行信令RACHPRACH上行随机接入前导特别注意PDCCH、PCFICH、PHICH这三个纯控制信道它们没有对应的传输信道传的是下行调度指令、控制格式指示和HARQ反馈。有人把PDCCH当成传输信道去背后面看调度时基本全乱。4. 数据链路层与控制面MAC/RLC/PDCP三子层加上RRC/NAS从这一章开始讲义从“无线电怎么传”过渡到“数据怎么管”。L2的三子层加上控制面RRC/NAS其实只有一条主线无线承载从PDCP往下走逻辑信道进MAC做复用传输信道进PHY控制面和用户面共享这条流水线只是消息内容不同。4.1 MAC子层逻辑信道、复用、HARQ与调度MAC层夹在RLC和物理层之间向下建立“RLC业务到物理层之间有效的连接”。核心功能有八个逻辑信道与传输信道之间的映射传输格式选择比如传输块大小和调制方案要作为输入参数提供给物理层一个UE或多个UE之间逻辑信道的优先级管理通过HARQ做纠错填充RLC PDU的复用与解复用业务量的测量与上报。它和UMTS MAC最大的区别是LTE每个小区只有一个MAC实体所有逻辑信道映射、复用和优先级判决都集中在一个实体里完成排查问题时反而更容易定位。逻辑信道按内容分两类。控制信道五个BCCH广播系统控制信息PCCH传寻呼信息网络不知道UE小区位置时使用CCCH在UE与网络没有RRC连接时传控制信息MCCH传MBMS调度和控制信息DCCH在UE有RRC连接时传专用控制信息。业务信道两个DTCH是点到点的专用业务信道MTCH是网络向UE传MBMS业务数据的点到多点下行信道。逻辑信道到传输信道的映射可以浓缩成几条规则逻辑信道映射到传输信道典型场景BCCHBCH 或 DL-SCH系统消息广播PCCHPCH寻呼CCCH / DCCH / DTCHDL-SCH / UL-SCH业务与控制数据共享MCCH / MTCHMCHMBMS业务HARQ是MAC层最重要的机制之一它和上层的ARQ配合工作HARQ做快速重传响应一般在几个毫秒内完成适合应对瞬时误码ARQ做最终纠错更可靠但更慢。做吞吐优化时这两层都要盯HARQ失败率高丢包和时延就上去了RLC重传率持续偏高基本可以断定空口质量已经出了问题这时查覆盖和干扰比调参数更有用。4.2 RLC子层TM/UM/AM三种模式怎么选RLC位于PDCP之下、MAC之上职责是分段与重组、重传处理和按序投递按工作模式分为TM、UM、AM三种。选哪个模式由业务决定这是看RLC配置的第一原则。模式特点适用场景关键行为TM透传不加任何RLC头广播、寻呼、SRB0原样透传头开销最小UM分段重组无重传VoLTE语音、实时视频丢包直接丢优先保证延迟AM有ARQ重传、分段连接、按序投递网页、TCP业务、信令承载可靠优先用延迟换可靠性TM模式最容易忽略的一点是“不做任何处理”广播消息和RRC连接建立前的公共控制信道走TM因为接收方这时候还没有建立RLC实体也解析不了复杂头。UM模式带序列号支持分段和重组但不重传AM在UM基础上加了ARQ机制接收端通过状态报告驱动发射端重传所以AM的PDU里除了数据PDU还有承载状态报告的控制PDU。实际看配置时最直接的入口是把RLC模式和业务对上SRB0一定是TMSRB1和大部分SRB2是AMVoLTE的承载要看部署策略普通数据承载几乎都是AM。做VoLTE问题分析时如果发现UM承载配置但频繁丢包第一反应应该是查覆盖和调度而不是查重传——因为UM模式下根本没有重传机制。4.3 PDCP子层ROHC头压缩与加密/完整性保护PDCP位于协议栈最上层直接为无线承载服务每个终端的每个无线承载对应一个PDCP实体。两项核心功能一是ROHC头压缩减少无线接口必须传送的比特流量二是加密和完整性保护。头压缩在VoLTE场景收益最大。一条VoLTE语音包通常是RTP加UDP加IPv6头加起来60字节左右语音载荷往往只有30多字节ROHC把头压到几个字节之后同样的资源块能承载的用户数明显增加这在容量受限的小区里有实际意义。做VoLTE容量评估的人会特别关注ROHC开启率和实际压缩效率不是开了就行还要看压缩率有没有达到预期。加密和完整性保护是两条线用户面PDCP做加密控制面PDCP除了加密还做完整性保护所以控制面CPU开销更高。实网里解密失败、完整性校验失败通常表现为PDCP层计数器异常排查时先查密钥协商是否正常——AS密钥由NAS层鉴权过程产生再查PDCP序列号连续性和重建立次数。系统内切换时PDCP实体要重建丢包和乱序大多发生在这个瞬间这也是切换性能优化的常见切入点。PDCP PDU结构里有大量比特位定义读的时候抓一个核心字段就够序列号SN。它决定接收端能否按序投递也决定解密时能否对齐加密参数。SN长度可配置常见12位或18位配置错了会直接影响吞吐量。4.4 RRC与NAS控制面的边界与六条典型信令流程控制面分两层处理RRC终止于eNodeBNAS终止于MME。RRC管无线侧状态和信令NAS管核心网侧的会话和移动性。LTE的RRC状态精简成RRC_IDLE和RRC_CONNECTED两个比UMTS那套CELL_FACH、URA_PCH简洁得多这也是协议演进里最明显的简化之一。RRC层功能包括广播系统信息、寻呼、RRC连接管理、无线承载RB控制、移动性管理、UE测量上报和控制。基本信令流程有六个广播、寻呼、RRC连接建立、RRC连接重配、RRC连接重建、RRC连接释放。其中连接建立的关键在于CCCH上透传TM模式的RRC Connection Request网络侧回RRC Connection SetupUE再回RRC Connection Setup Complete一条SRB1才算正式可用。NAS层负责EPS承载管理、鉴权、空闲态移动性处理、寻呼消息和安全控制基本流程与业务一一对应开机附着做注册和默认承载建立Service Request把UE从空闲态拉回连接态开始传数据TAU做跟踪区更新跨MME还涉及核心网路由切换去附着分关机去附着和网络发起两类切换按X2和S1分两大类。关键流程可以压成一张对照表流程谁发起关键消息主要作用开机附着UEAttach Request / Attach Accept注册加默认承载建立Service RequestUEService Request / Initial Context Setup空闲态到连接态寻呼S-TMSIMMEPagingS-TMSI找空闲态的UE寻呼IMSIMMEPagingIMSIUE状态异常时兜底TAUIDLE下UETAU Request / TAU Accept跟踪区更新TAUConnected下eNodeB/MMETAU连接态连接态下的TAU去附着UE/网络Detach Request注销并释放承载X2切换eNodeBHandover Request / Handover Command基站间无缝切换读信令流程的建议每个流程画一条时间轴把UE、eNodeB、MME三条泳道拉开每条消息标上所属协议层再标状态变化。第一遍这样画完之后看实网信令时就很容易对上每条消息的位置。5. 避坑与排查读LTE协议最容易搞混的五个点这五个坑都是我带人时高频翻车的点每条按现象、原因、解决的顺序整理希望你别再踩一遍。5.1 坑一帧结构的时间基准全混在一起现象把半帧、子帧、时隙、特殊子帧当成四个并列概念答不出“一个子帧等于多少个Ts”也说不清十分钟1.4MHz带宽的小区里一个RB能放多少符号。原因讲义先讲10ms帧、再讲1ms子帧、最后讲30720Ts信息是顺序给出的但缺少横向对照稍不留意就把Ts当成可选项忽略掉。解决抄一张三层递进表写死推演关系10ms等于307200Ts1ms等于30720Ts基本时间单位Ts等于1/30720000秒。做时延预算时这些数字会被反复使用建议贴在工作台旁边。无论看SIB里的帧配置还是算HARQ往返时间先把这三个数摆出来基本就不会错。5.2 坑二PDCCH是信道但不是传数据的信道现象把PDCCH当成“下行控制数据的传输信道”甚至和PDSCH混为一谈看调度log时半天找不到数据在哪。原因讲义物理层章节先列物理信道、再列传输信道PDCCH没有对应的传输信道很容易被误解为“某种传输信道”。解决记一条口诀PDCCH从来不下传用户数据它传的是下行调度指令DCIDownlink Control Information。传输信道表里只有BCH、DL-SCH、PCH、MCH、UL-SCH、RACH这六个PDCCH不在其中。看真实log时第一步就是分清PDCCH上的调度指令和PDSCH上的实际数据两者混在一起后面所有分析都是白做。5.3 坑三RLC三种模式的选型逻辑没接上业务现象背住了TM透传、UM不重传、AM有ARQ但到了现场拿到一份配置仍然分不清这个承载应该配哪个模式。原因只背模式特性不背业务对应关系不知道SRB0用TM、VoLTE可能用UM、数据承载基本用AM。解决用业务容忍度来推断——丢一包语音没关系但延迟不能拖所以VoLTE用UM或按部署策略做选择网页和信令不能被丢所以AM广播和连接建立前的公共控制消息没有反馈通道只能TM。看到RLC配置先问业务类型再对照模式比死记三种模式的行为更管用。5.4 坑四RRC和NAS的边界模糊现象以为RRC连接建立之后NAS就不存在了或者把RRC信令当NAS信令去看抓包分析时定位错层。原因协议栈图上RRC和NAS画在一起但一个终止在eNodeB、一个终止在MME“终止点”这个概念没被强调是最常见的混淆根源。解决用问题判断——这条消息从UE发出去后是停在基站被处理还是要继续传向MME停基站的就是RRC路过基站继续上送MME的就是NAS。附着流程里Attach Request是NAS消息它被封装在RRC消息里发向MME做信令分析时看到层二容器要能把这层封装剥出来再决定下一步查RRC还是查NAS。5.5 坑五六条信令流程靠背不靠画现象每条流程单独读都读得懂遇到实际log或面试画图时把消息顺序画反最常见的错误是把Security Mode Command放到Initial Context Setup后面。原因前面几章是“先概念后细节”的读法流程这章是“先时序后消息”沿用老读法等于没读。解决每个流程只画一次三泳道时序图把关键消息按真实顺序放进去顺序画错一次就重画一次。反复出错的位置就是Initial Context Setup和Security Mode Command它俩几乎总是连着出现先激活安全再建立上下文。能不看讲义画出一张正确的附着流程图这一章才算真正过关。6. 把讲义落地成本地速查手册一页纸帧结构与三泳道流程卡读完一遍还不够我一般会把这份PDF的内容压成自己能“用”的形式一共三步每一份协议类PDF我都这么处理成速查工具。6.1 把协议栈和帧结构压到一页纸第一步是重画第1、2章的两张图不要照抄改成自己理解的版本。顶部横排放用户面协议栈四层和终止点标注eNodeB下面另起一行画控制面在PDCP右侧补上RRC停eNodeB和NAS上送MME再往下画一条10ms时间轴标半帧、子帧、特殊子帧的DwPTS/GP/UpPTS。旁边写三个最常算的数307200Ts、30720Ts、12乘15kHz等于180kHz。画完这页纸解读实网log的最小背景就有了看到一条RRC Setup消息能立刻知道它在第几层、该不该有加密、流程走到哪一步。6.2 六条信令流程改成三泳道卡片第二步把第6章的六条流程——开机附着、Service Request、S_TMSI/IMSI寻呼、IDLE/Connected下的TAU、去附着、X2切换——每条画成一张卡片。格式固定时间从上往下左到右三条泳道分别是UE、eNodeB、MME每条消息标注协议层粒度到RRC/NAS/MAC即可不需要标物理信道。做完这步你会发现结论和背文字完全不同。附着流程的核心是“Attach Request从RRC消息里剥出来送给MMEMME回Attach Accept后再去建立默认承载”S_TMSI寻呼的本质是“MME不知道你在哪只能让基站喊你你用Initial Context Setup响应来回答‘我在’”。6.3 拿实网log做交叉验证第三步是拿一份真实log或信令追踪随便挑一条流程把卡片往信令消息上一套。没有实网设备时公开的LTE信令捕获或者仿真平台输出也可以核心是把每条你画的箭头和真实消息对应起来。对不上的地方多数时候不是log错了而是哪一步状态转换没画对。从那以后我每拿一份协议类文档都是先把“一页纸加流程卡”做完才放回书架。遇到问题翻文档是检索不是重新读一遍带新人时让他画一遍帧结构也比讲十遍有效。这套方法对任何PDF格式的技术文档都通用。这份《LTE协议原理》的资料就在资源包里下载后按上面的步骤走一遍框架立起来很快希望帮到你。本文还有配套的精品资源点击获取 LTE协议原理核心解读：网络架构、协议栈与信令流程
简介这份长期演进协议原理电子文档面向移动通信专业学生、四代网络工程师及协议初学者用于系统理解长期演进系统的协议架构、无线帧结构与各层功能。整包共1个PDF文件压缩后大小1.72MB内容紧凑适宜随时查阅。目前已有97人浏览学习可作课程同步参考或自学补充资料。文档先介绍长期演进整体架构区分用户平面与控制平面再逐层讲解协议栈物理层包含无线帧结构、物理信道、传输信道及相互映射数据链路层详细说明媒体接入控制子层的逻辑信道与关键功能并介绍无线链路控制子层的透明模式、非确认模式、确认模式及协议数据单元结构。目录层级清晰从系统概述到协议细节循序渐进能帮助读者建立从物理传输到高层控制的完整认知适合正式学习前导览与考前系统回顾。1. LTE协议原理这份PDF到底在讲什么、适合谁读刚转4G领域的人拿到《LTE协议原理》PDF很容易被3GPP那几千页标准文档吓退。这份讲义的优势在于它是一套按授课顺序组织的课程材料从整体架构讲到物理层、数据链路层、RRC/NAS最后落到六条典型信令流程目的不是让你背标准而是让你在最短时间内建立起“LTE协议到底怎么运转”的框架。它适合三类人刚转LTE的协议测试、负责覆盖优化的网优以及做modem或核心网信令分析却始终没把协议栈串起来的人。读完这份讲义你能说清eNodeB和EPC的接口关系、一个无线帧里特殊子帧的作用、MAC/RLC/PDCP各管哪一段以及开机附着时UE和网络先后交换了什么。这是后面看实网log、跟问题单的基础。2. 从整体架构到协议栈为什么LTE把网络拍扁了2.1 E-UTRAN与EPC接口、网元和扁平化的理由讲义第1章给出的拓扑图是整份文档最值得先吃透的一张图。LTE/SAE把无线网和核心网分别叫做E-UTRAN和EPC整个系统称为EPSEvolved Packet System。无线侧只剩一个网元eNodeB它把UMTS里NodeB和RNC的职责几乎全包了物理层、MAC层、RRC层外加调度、接入控制、承载控制、移动性管理和小区间无线资源管理。核心网侧的MME/S-GW被看作边界节点类似UMTS里的SGSN但它已经不再管理无线资源。理解LTE架构关键是先理解“拍扁”这件事。UMTS是NodeB加RNC两级结构RNC集中控制一批NodeB好处是调度集中、干扰协调方便坏处是网元多、部署重、用户面时延大RNC本身还容易成为单点瓶颈。LTE把RNC的功能全部下沉到eNodeBeNodeB之间用X2接口直接互通形成Mesh型逻辑网络每个eNodeB再用S1接口连接MME/S-GWS1也是全部或部分Mesh一个eNodeB可以连多个MME/S-GW反过来也成立。原UMTS的Iub、Iur、Iu接口在LTE里被大幅度简化对应关系如下表原UMTS接口LTE对应变化说明IubNodeB到RNC消失RNC职能并入eNodeB不再有独立RNCIurRNC到RNCX2eNodeB之间互联负责切换与干扰协调IuRNC到核心网S1eNodeB到MME/S-GW分S1-MME和S1-U读这段时别急着背接口名先问自己三个问题用户面数据从基站出来后走哪条路径控制面信令走哪条路径切换时两个基站之间要交换什么把这三个问题回答清楚接口自然就记住了。实际工作中做基站间切换排查时S1-MME和X2是最容易混淆的后面避坑章我会展开讲。扁平化带来的收益讲义写得很直接一共三条网络扁平化让系统时延明显减小用户体验和实时业务表现变好网元数目减少部署更简单、维护更容易取消RNC集中控制避免单点故障。做网优的人会额外在意最后一条因为小区间无线资源管理被放到了X2接口上相邻eNodeB之间直接协商干扰控制的思路和UMTS时代完全不同。2.2 用户面与控制面协议栈各层是谁的活协议栈按用途分成用户面和控制面这是后续所有章节的地图。用户面从上到下依次是PDCP、RLC、MAC、PHY这些子层在网络侧全部终止于eNodeB控制面在用户面基础上增加了RRC层和NAS层其中RRC终止于eNodeBNAS终止于MME。这句话决定了LTE控制面的边界也是排查信令问题时判断消息归属的依据。协议层控制面终止点主要职责NASMMEEPS承载管理、鉴权、空闲态移动性处理、寻呼消息、安全控制RRCeNodeB广播、寻呼、RRC连接管理、无线承载控制、移动性、测量上报和控制PDCPeNodeBROHC头压缩、加密与完整性保护RLCeNodeB分段与重组、ARQ重传、按序投递MACeNodeB逻辑信道到传输信道的映射、调度、HARQ、复用PHYeNodeB编解码、调制解调、MIMO天线处理、射频处理这里有个容易被忽略的细节控制面里的PDCP、RLC、MAC执行的功能和用户面完全一致。也就是说RRC/NAS信令同样要经过加密、分段、调度和物理层处理只是内容不是IP数据包而是控制消息。很多做信令分析的人把RRC和NAS看成挂在协议栈之外的“特殊消息”其实它们走的同样是PDCP到MAC到PHY这条流水线只是承载它们的SAP不同。按照我的习惯读协议栈最好的方式是“顺着一条消息走一遍”。以RRC连接建立请求为例UE的RRC层组装消息交给PDCP做加密和完整性保护再经RLC分段MAC把分段后的数据拼进传输块最后PHY调制成无线信号发出去。这条链路走通之后后面所有信令流程读起来都是顺的不会再觉得每一章是独立的知识点。2.3 从IP包到天线一整套下行处理流水线讲义第1章给出的下行数据处理框图值得反复看。IP包进入PDCP之后第一步做ROHC头压缩把IPv6那40字节的头压到几个字节VoLTE这类小包业务收益最明显随后做加密和完整性保护。RLC拿到数据后做分段和连接传输块大小是调度决定的IP包不一定刚好匹配分段就是为了把数据塞进当前分配的资源AM模式下RLC还负责ARQ重传。MAC层做逻辑信道的复用和优先级处理多个无线承载的数据按优先级拼进一个传输块同时通过HARQ做快速重传。PHY层最后做Turbo编码、调制、天线映射和资源映射把数据真正送到空口。接收端的处理正好反向PHY解调译码MAC解复用并把HARQ的软合并结果交给RLCRLC做重组和按序投递PDCP解头压缩、解密最后还原成IP包。这套流水线正好对应讲义后面的每一章PDCP管头压缩和安全RLC管分段和重传MAC管复用、调度和HARQPHY管无线传输。我读这份讲义时的方法很简单每学完一层回到这张流水线图把对应环节标一遍避免只看单层细节丢掉整体。这也是我带转岗同事时反复强调的先有流水线再抠层内部细节。3. 物理层关键参数帧结构、带宽、调制编码和信道映射物理层章节是整份讲义里参数最密集的部分也是很多人读“懂”了却答不出题的部分。核心问题只有三个无线帧在时域上怎么切资源块在频域上多宽数据从哪个传输信道走到哪个物理信道把这三件事抓住物理层就算立住了。3.1 无线帧结构10ms、半帧、子帧与特殊子帧时域上的所有时间定义都以基本时间单位Ts1/30720000s为基准系统中的所有时隙都是这个基本单位的整数倍。每个无线帧Tframe10ms等于307200个Ts每帧分成10个1ms的子帧也就是30720个Ts每个子帧内部是两个0.5ms的时隙。帧与帧之间进一步分成两个5ms的半帧每个半帧由4个数据子帧和1个特殊子帧组成。特殊子帧总长度1ms包含三个特殊时隙DwPTS下行导频时隙、GP保护间隔、UpPTS上行导频时隙。TDD模式下特殊子帧的配置决定上下行转换点的位置GP的作用是避免下行信号到达UE时UE自己的上行发射造成干扰——GP越长可支持的覆盖半径越大。这是我在现场最常被问到的地方也是为什么讲义里要把长短两套CP方案和GP放在一起讲。帧结构建议这样记先记10ms和1ms两个数再补一个30720Ts剩下的半帧、特殊子帧、时隙都是从这两个数推出来的。时间线画成一行10ms等于两个5ms半帧每个半帧里4个数据子帧加1个特殊子帧特殊子帧拆成DwPTS、GP、UpPTS三段。频域概念另起一行画两条线错开不容易混淆。时间单位数值换算关系基本时间单位Ts1/30720000秒系统所有时隙的基准无线帧10ms307200 Ts半帧5ms153600 Ts子帧1ms30720 Ts时隙0.5ms15360 Ts特殊子帧1msDwPTS GP UpPTS提示面试和考试里最常被追问的是“为什么是30720”因为1秒除以1/30720000正好是307200001ms是它的千分之一就是30720。这个数不是玄学是定义推导。3.2 频域与调制参数1.4MHz到20MHz带宽怎么配出来的频域参数集中在几个数字上。子载波间隔15kHz最小资源块RB是180kHz也就是12个子载波宽度通过合理配置子载波数量系统支持1.4MHz到20MHz的灵活带宽配置。20MHz对应100个RB这是LTE最常见的满配做吞吐测试时一看带宽和RB数量就能估算理论峰值。下行用OFDMA上行用SC-FDMA。选SC-FDMA不是因为性能更好而是因为单载波方案的峰值平均功率比PAPR低终端功放可以做得更小、更省电这是从终端体积和成本出发的工程选型。CP有两种长度短CP是基本配置抗多径能力够用长CP用于大范围小区覆盖和多小区MBMS广播覆盖半径可以做到接近100km代价是每个OFDM符号能承载的数据变少。调制、编码和天线参数可以压成一张速查表参数取值说明子载波间隔15kHzOFDM符号的频域间隔资源块RB180kHz12个子载波最小调度单位系统带宽1.420MHz通过RB数量灵活配置双工方式FDD / TDD帧结构不同TDD带特殊子帧调制方式QPSK、16QAM、64QAM上下行均支持信道编码Turbo码R1/3两个8状态子编码器加内部交织器MIMO天线下行2×2上行1×2最大4×4支持发射分集、空间复用、预编码读这些参数的标准动作是“互相推导”12个子载波乘15kHz等于180kHz100个RB乘180kHz约等于18MHz加上保护带宽就是20MHz所以20MHz系统配100个RB1ms等于30720个Ts一个RB在时域上占1ms时正好是12个子载波乘以7个OFDM符号。能自己推出来比背参数表有用得多。3.3 传输信道与物理信道映射关系是物理层的核心地图讲义把信道从功能上切成了两层传输信道描述“以什么特征传数据”物理信道描述“实际在空口上用什么资源传数”。这个区分是理解后面调度、寻呼、随机接入的前提。下行传输信道有四个BCH固定的预定义传输格式在整个小区覆盖区域内广播DL-SCH支持HARQ、链路自适应、波束成形、DRX和MBMS传输PCH在全小区发送寻呼支持UE的DRX省电MCH支持MBSFN多小区MBMS传输合并。上行传输信道有两个UL-SCH支持通过调整发射功率和调制编码格式实现动态链路自适应支持HARQ和动态/半动态资源分配RACH承载有限控制信息支持冲突碰撞解决。物理信道这侧下行有PDSCH、PBCH、PMCH、PDCCH、PCFICH、PHICH上行有PUSCH、PUCCH、PRACH。映射关系用一句话概括DL-SCH映射到PDSCHBCH映射到PBCHPCH映射到PDSCH上的动态资源MCH映射到PMCHRACH映射到PRACHUL-SCH映射到PUSCH。传输信道物理信道方向典型内容BCHPBCH下行MIB主信息块DL-SCHPDSCH下行用户数据、SIB、寻呼、切换消息PCHPDSCH动态资源下行寻呼消息MCHPMCH下行MBMS业务UL-SCHPUSCH上行用户数据、上行信令RACHPRACH上行随机接入前导特别注意PDCCH、PCFICH、PHICH这三个纯控制信道它们没有对应的传输信道传的是下行调度指令、控制格式指示和HARQ反馈。有人把PDCCH当成传输信道去背后面看调度时基本全乱。4. 数据链路层与控制面MAC/RLC/PDCP三子层加上RRC/NAS从这一章开始讲义从“无线电怎么传”过渡到“数据怎么管”。L2的三子层加上控制面RRC/NAS其实只有一条主线无线承载从PDCP往下走逻辑信道进MAC做复用传输信道进PHY控制面和用户面共享这条流水线只是消息内容不同。4.1 MAC子层逻辑信道、复用、HARQ与调度MAC层夹在RLC和物理层之间向下建立“RLC业务到物理层之间有效的连接”。核心功能有八个逻辑信道与传输信道之间的映射传输格式选择比如传输块大小和调制方案要作为输入参数提供给物理层一个UE或多个UE之间逻辑信道的优先级管理通过HARQ做纠错填充RLC PDU的复用与解复用业务量的测量与上报。它和UMTS MAC最大的区别是LTE每个小区只有一个MAC实体所有逻辑信道映射、复用和优先级判决都集中在一个实体里完成排查问题时反而更容易定位。逻辑信道按内容分两类。控制信道五个BCCH广播系统控制信息PCCH传寻呼信息网络不知道UE小区位置时使用CCCH在UE与网络没有RRC连接时传控制信息MCCH传MBMS调度和控制信息DCCH在UE有RRC连接时传专用控制信息。业务信道两个DTCH是点到点的专用业务信道MTCH是网络向UE传MBMS业务数据的点到多点下行信道。逻辑信道到传输信道的映射可以浓缩成几条规则逻辑信道映射到传输信道典型场景BCCHBCH 或 DL-SCH系统消息广播PCCHPCH寻呼CCCH / DCCH / DTCHDL-SCH / UL-SCH业务与控制数据共享MCCH / MTCHMCHMBMS业务HARQ是MAC层最重要的机制之一它和上层的ARQ配合工作HARQ做快速重传响应一般在几个毫秒内完成适合应对瞬时误码ARQ做最终纠错更可靠但更慢。做吞吐优化时这两层都要盯HARQ失败率高丢包和时延就上去了RLC重传率持续偏高基本可以断定空口质量已经出了问题这时查覆盖和干扰比调参数更有用。4.2 RLC子层TM/UM/AM三种模式怎么选RLC位于PDCP之下、MAC之上职责是分段与重组、重传处理和按序投递按工作模式分为TM、UM、AM三种。选哪个模式由业务决定这是看RLC配置的第一原则。模式特点适用场景关键行为TM透传不加任何RLC头广播、寻呼、SRB0原样透传头开销最小UM分段重组无重传VoLTE语音、实时视频丢包直接丢优先保证延迟AM有ARQ重传、分段连接、按序投递网页、TCP业务、信令承载可靠优先用延迟换可靠性TM模式最容易忽略的一点是“不做任何处理”广播消息和RRC连接建立前的公共控制信道走TM因为接收方这时候还没有建立RLC实体也解析不了复杂头。UM模式带序列号支持分段和重组但不重传AM在UM基础上加了ARQ机制接收端通过状态报告驱动发射端重传所以AM的PDU里除了数据PDU还有承载状态报告的控制PDU。实际看配置时最直接的入口是把RLC模式和业务对上SRB0一定是TMSRB1和大部分SRB2是AMVoLTE的承载要看部署策略普通数据承载几乎都是AM。做VoLTE问题分析时如果发现UM承载配置但频繁丢包第一反应应该是查覆盖和调度而不是查重传——因为UM模式下根本没有重传机制。4.3 PDCP子层ROHC头压缩与加密/完整性保护PDCP位于协议栈最上层直接为无线承载服务每个终端的每个无线承载对应一个PDCP实体。两项核心功能一是ROHC头压缩减少无线接口必须传送的比特流量二是加密和完整性保护。头压缩在VoLTE场景收益最大。一条VoLTE语音包通常是RTP加UDP加IPv6头加起来60字节左右语音载荷往往只有30多字节ROHC把头压到几个字节之后同样的资源块能承载的用户数明显增加这在容量受限的小区里有实际意义。做VoLTE容量评估的人会特别关注ROHC开启率和实际压缩效率不是开了就行还要看压缩率有没有达到预期。加密和完整性保护是两条线用户面PDCP做加密控制面PDCP除了加密还做完整性保护所以控制面CPU开销更高。实网里解密失败、完整性校验失败通常表现为PDCP层计数器异常排查时先查密钥协商是否正常——AS密钥由NAS层鉴权过程产生再查PDCP序列号连续性和重建立次数。系统内切换时PDCP实体要重建丢包和乱序大多发生在这个瞬间这也是切换性能优化的常见切入点。PDCP PDU结构里有大量比特位定义读的时候抓一个核心字段就够序列号SN。它决定接收端能否按序投递也决定解密时能否对齐加密参数。SN长度可配置常见12位或18位配置错了会直接影响吞吐量。4.4 RRC与NAS控制面的边界与六条典型信令流程控制面分两层处理RRC终止于eNodeBNAS终止于MME。RRC管无线侧状态和信令NAS管核心网侧的会话和移动性。LTE的RRC状态精简成RRC_IDLE和RRC_CONNECTED两个比UMTS那套CELL_FACH、URA_PCH简洁得多这也是协议演进里最明显的简化之一。RRC层功能包括广播系统信息、寻呼、RRC连接管理、无线承载RB控制、移动性管理、UE测量上报和控制。基本信令流程有六个广播、寻呼、RRC连接建立、RRC连接重配、RRC连接重建、RRC连接释放。其中连接建立的关键在于CCCH上透传TM模式的RRC Connection Request网络侧回RRC Connection SetupUE再回RRC Connection Setup Complete一条SRB1才算正式可用。NAS层负责EPS承载管理、鉴权、空闲态移动性处理、寻呼消息和安全控制基本流程与业务一一对应开机附着做注册和默认承载建立Service Request把UE从空闲态拉回连接态开始传数据TAU做跟踪区更新跨MME还涉及核心网路由切换去附着分关机去附着和网络发起两类切换按X2和S1分两大类。关键流程可以压成一张对照表流程谁发起关键消息主要作用开机附着UEAttach Request / Attach Accept注册加默认承载建立Service RequestUEService Request / Initial Context Setup空闲态到连接态寻呼S-TMSIMMEPagingS-TMSI找空闲态的UE寻呼IMSIMMEPagingIMSIUE状态异常时兜底TAUIDLE下UETAU Request / TAU Accept跟踪区更新TAUConnected下eNodeB/MMETAU连接态连接态下的TAU去附着UE/网络Detach Request注销并释放承载X2切换eNodeBHandover Request / Handover Command基站间无缝切换读信令流程的建议每个流程画一条时间轴把UE、eNodeB、MME三条泳道拉开每条消息标上所属协议层再标状态变化。第一遍这样画完之后看实网信令时就很容易对上每条消息的位置。5. 避坑与排查读LTE协议最容易搞混的五个点这五个坑都是我带人时高频翻车的点每条按现象、原因、解决的顺序整理希望你别再踩一遍。5.1 坑一帧结构的时间基准全混在一起现象把半帧、子帧、时隙、特殊子帧当成四个并列概念答不出“一个子帧等于多少个Ts”也说不清十分钟1.4MHz带宽的小区里一个RB能放多少符号。原因讲义先讲10ms帧、再讲1ms子帧、最后讲30720Ts信息是顺序给出的但缺少横向对照稍不留意就把Ts当成可选项忽略掉。解决抄一张三层递进表写死推演关系10ms等于307200Ts1ms等于30720Ts基本时间单位Ts等于1/30720000秒。做时延预算时这些数字会被反复使用建议贴在工作台旁边。无论看SIB里的帧配置还是算HARQ往返时间先把这三个数摆出来基本就不会错。5.2 坑二PDCCH是信道但不是传数据的信道现象把PDCCH当成“下行控制数据的传输信道”甚至和PDSCH混为一谈看调度log时半天找不到数据在哪。原因讲义物理层章节先列物理信道、再列传输信道PDCCH没有对应的传输信道很容易被误解为“某种传输信道”。解决记一条口诀PDCCH从来不下传用户数据它传的是下行调度指令DCIDownlink Control Information。传输信道表里只有BCH、DL-SCH、PCH、MCH、UL-SCH、RACH这六个PDCCH不在其中。看真实log时第一步就是分清PDCCH上的调度指令和PDSCH上的实际数据两者混在一起后面所有分析都是白做。5.3 坑三RLC三种模式的选型逻辑没接上业务现象背住了TM透传、UM不重传、AM有ARQ但到了现场拿到一份配置仍然分不清这个承载应该配哪个模式。原因只背模式特性不背业务对应关系不知道SRB0用TM、VoLTE可能用UM、数据承载基本用AM。解决用业务容忍度来推断——丢一包语音没关系但延迟不能拖所以VoLTE用UM或按部署策略做选择网页和信令不能被丢所以AM广播和连接建立前的公共控制消息没有反馈通道只能TM。看到RLC配置先问业务类型再对照模式比死记三种模式的行为更管用。5.4 坑四RRC和NAS的边界模糊现象以为RRC连接建立之后NAS就不存在了或者把RRC信令当NAS信令去看抓包分析时定位错层。原因协议栈图上RRC和NAS画在一起但一个终止在eNodeB、一个终止在MME“终止点”这个概念没被强调是最常见的混淆根源。解决用问题判断——这条消息从UE发出去后是停在基站被处理还是要继续传向MME停基站的就是RRC路过基站继续上送MME的就是NAS。附着流程里Attach Request是NAS消息它被封装在RRC消息里发向MME做信令分析时看到层二容器要能把这层封装剥出来再决定下一步查RRC还是查NAS。5.5 坑五六条信令流程靠背不靠画现象每条流程单独读都读得懂遇到实际log或面试画图时把消息顺序画反最常见的错误是把Security Mode Command放到Initial Context Setup后面。原因前面几章是“先概念后细节”的读法流程这章是“先时序后消息”沿用老读法等于没读。解决每个流程只画一次三泳道时序图把关键消息按真实顺序放进去顺序画错一次就重画一次。反复出错的位置就是Initial Context Setup和Security Mode Command它俩几乎总是连着出现先激活安全再建立上下文。能不看讲义画出一张正确的附着流程图这一章才算真正过关。6. 把讲义落地成本地速查手册一页纸帧结构与三泳道流程卡读完一遍还不够我一般会把这份PDF的内容压成自己能“用”的形式一共三步每一份协议类PDF我都这么处理成速查工具。6.1 把协议栈和帧结构压到一页纸第一步是重画第1、2章的两张图不要照抄改成自己理解的版本。顶部横排放用户面协议栈四层和终止点标注eNodeB下面另起一行画控制面在PDCP右侧补上RRC停eNodeB和NAS上送MME再往下画一条10ms时间轴标半帧、子帧、特殊子帧的DwPTS/GP/UpPTS。旁边写三个最常算的数307200Ts、30720Ts、12乘15kHz等于180kHz。画完这页纸解读实网log的最小背景就有了看到一条RRC Setup消息能立刻知道它在第几层、该不该有加密、流程走到哪一步。6.2 六条信令流程改成三泳道卡片第二步把第6章的六条流程——开机附着、Service Request、S_TMSI/IMSI寻呼、IDLE/Connected下的TAU、去附着、X2切换——每条画成一张卡片。格式固定时间从上往下左到右三条泳道分别是UE、eNodeB、MME每条消息标注协议层粒度到RRC/NAS/MAC即可不需要标物理信道。做完这步你会发现结论和背文字完全不同。附着流程的核心是“Attach Request从RRC消息里剥出来送给MMEMME回Attach Accept后再去建立默认承载”S_TMSI寻呼的本质是“MME不知道你在哪只能让基站喊你你用Initial Context Setup响应来回答‘我在’”。6.3 拿实网log做交叉验证第三步是拿一份真实log或信令追踪随便挑一条流程把卡片往信令消息上一套。没有实网设备时公开的LTE信令捕获或者仿真平台输出也可以核心是把每条你画的箭头和真实消息对应起来。对不上的地方多数时候不是log错了而是哪一步状态转换没画对。从那以后我每拿一份协议类文档都是先把“一页纸加流程卡”做完才放回书架。遇到问题翻文档是检索不是重新读一遍带新人时让他画一遍帧结构也比讲十遍有效。这套方法对任何PDF格式的技术文档都通用。这份《LTE协议原理》的资料就在资源包里下载后按上面的步骤走一遍框架立起来很快希望帮到你。本文还有配套的精品资源点击获取