企业官网建设流程全解析

简介：这份长期演进协议原理电子文档，面向移动通信专业学生、四代网络工程师及协议初学者，用于系统理解长期演进系统的协议架构、无线帧结构与各层功能。整包共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，整个系统称为EPS（Evolved Packet System）。无线侧只剩一个网元eNodeB，它把UMTS里NodeB和RNC的职责几乎全包了：物理层、MAC层、RRC层，外加调度、接入控制、承载控制、移动性管理和小区间无线资源管理。核心网侧的MME/S-GW被看作边界节点，类似UMTS里的SGSN，但它已经不再管理无线资源。

理解LTE架构，关键是先理解“拍扁”这件事。UMTS是NodeB加RNC两级结构，RNC集中控制一批NodeB，好处是调度集中、干扰协调方便，坏处是网元多、部署重、用户面时延大，RNC本身还容易成为单点瓶颈。LTE把RNC的功能全部下沉到eNodeB，eNodeB之间用X2接口直接互通，形成Mesh型逻辑网络；每个eNodeB再用S1接口连接MME/S-GW，S1也是全部或部分Mesh，一个eNodeB可以连多个MME/S-GW，反过来也成立。原UMTS的Iub、Iur、Iu接口在LTE里被大幅度简化，对应关系如下表：

读这段时别急着背接口名，先问自己三个问题：用户面数据从基站出来后走哪条路径？控制面信令走哪条路径？切换时两个基站之间要交换什么？把这三个问题回答清楚，接口自然就记住了。实际工作中做基站间切换排查时，S1-MME和X2是最容易混淆的，后面避坑章我会展开讲。

扁平化带来的收益讲义写得很直接，一共三条：网络扁平化让系统时延明显减小，用户体验和实时业务表现变好；网元数目减少，部署更简单、维护更容易；取消RNC集中控制，避免单点故障。做网优的人会额外在意最后一条，因为小区间无线资源管理被放到了X2接口上，相邻eNodeB之间直接协商，干扰控制的思路和UMTS时代完全不同。

2.2 用户面与控制面协议栈：各层是谁的活

协议栈按用途分成用户面和控制面，这是后续所有章节的地图。用户面从上到下依次是PDCP、RLC、MAC、PHY，这些子层在网络侧全部终止于eNodeB；控制面在用户面基础上增加了RRC层和NAS层，其中RRC终止于eNodeB，NAS终止于MME。这句话决定了LTE控制面的边界，也是排查信令问题时判断消息归属的依据。

这里有个容易被忽略的细节：控制面里的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的软合并结果交给RLC，RLC做重组和按序投递，PDCP解头压缩、解密，最后还原成IP包。这套流水线正好对应讲义后面的每一章：PDCP管头压缩和安全，RLC管分段和重传，MAC管复用、调度和HARQ，PHY管无线传输。我读这份讲义时的方法很简单：每学完一层，回到这张流水线图把对应环节标一遍，避免只看单层细节丢掉整体。这也是我带转岗同事时反复强调的：先有流水线，再抠层内部细节。

3. 物理层关键参数：帧结构、带宽、调制编码和信道映射

物理层章节是整份讲义里参数最密集的部分，也是很多人读“懂”了却答不出题的部分。核心问题只有三个：无线帧在时域上怎么切？资源块在频域上多宽？数据从哪个传输信道走到哪个物理信道？把这三件事抓住，物理层就算立住了。

3.1 无线帧结构：10ms、半帧、子帧与特殊子帧

时域上的所有时间定义都以基本时间单位Ts=1/30720000s为基准，系统中的所有时隙都是这个基本单位的整数倍。每个无线帧Tframe=10ms，等于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三段。频域概念另起一行画，两条线错开，不容易混淆。

提示：面试和考试里最常被追问的是“为什么是30720”，因为1秒除以1/30720000正好是30720000，1ms是它的千分之一，就是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符号能承载的数据变少。

调制、编码和天线参数可以压成一张速查表：

读这些参数的标准动作是“互相推导”：12个子载波乘15kHz等于180kHz；100个RB乘180kHz约等于18MHz，加上保护带宽就是20MHz，所以20MHz系统配100个RB；1ms等于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映射到PDSCH，BCH映射到PBCH，PCH映射到PDSCH上的动态资源，MCH映射到PMCH；RACH映射到PRACH，UL-SCH映射到PUSCH。

特别注意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业务数据的点到多点下行信道。

逻辑信道到传输信道的映射可以浓缩成几条规则：

HARQ是MAC层最重要的机制之一，它和上层的ARQ配合工作：HARQ做快速重传，响应一般在几个毫秒内完成，适合应对瞬时误码；ARQ做最终纠错，更可靠但更慢。做吞吐优化时这两层都要盯：HARQ失败率高，丢包和时延就上去了；RLC重传率持续偏高，基本可以断定空口质量已经出了问题，这时查覆盖和干扰比调参数更有用。

4.2 RLC子层：TM/UM/AM三种模式怎么选

RLC位于PDCP之下、MAC之上，职责是分段与重组、重传处理和按序投递，按工作模式分为TM、UM、AM三种。选哪个模式由业务决定，这是看RLC配置的第一原则。

TM模式最容易忽略的一点是“不做任何处理”：广播消息和RRC连接建立前的公共控制信道走TM，因为接收方这时候还没有建立RLC实体，也解析不了复杂头。UM模式带序列号，支持分段和重组，但不重传；AM在UM基础上加了ARQ机制，接收端通过状态报告驱动发射端重传，所以AM的PDU里除了数据PDU，还有承载状态报告的控制PDU。

实际看配置时，最直接的入口是把RLC模式和业务对上：SRB0一定是TM，SRB1和大部分SRB2是AM，VoLTE的承载要看部署策略，普通数据承载几乎都是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终止于eNodeB，NAS终止于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 Setup，UE再回RRC Connection Setup Complete，一条SRB1才算正式可用。

NAS层负责EPS承载管理、鉴权、空闲态移动性处理、寻呼消息和安全控制，基本流程与业务一一对应：开机附着做注册和默认承载建立；Service Request把UE从空闲态拉回连接态开始传数据；TAU做跟踪区更新，跨MME还涉及核心网路由切换；去附着分关机去附着和网络发起两类；切换按X2和S1分两大类。关键流程可以压成一张对照表：

读信令流程的建议：每个流程画一条时间轴，把UE、eNodeB、MME三条泳道拉开，每条消息标上所属协议层，再标状态变化。第一遍这样画完，之后看实网信令时就很容易对上每条消息的位置。

5. 避坑与排查：读LTE协议最容易搞混的五个点

这五个坑都是我带人时高频翻车的点，每条按现象、原因、解决的顺序整理，希望你别再踩一遍。

5.1 坑一：帧结构的时间基准全混在一起

现象：把半帧、子帧、时隙、特殊子帧当成四个并列概念，答不出“一个子帧等于多少个Ts”，也说不清十分钟1.4MHz带宽的小区里一个RB能放多少符号。

原因：讲义先讲10ms帧、再讲1ms子帧、最后讲30720Ts，信息是顺序给出的，但缺少横向对照，稍不留意就把Ts当成可选项忽略掉。

解决：抄一张三层递进表，写死推演关系：10ms等于307200Ts，1ms等于30720Ts，基本时间单位Ts等于1/30720000秒。做时延预算时，这些数字会被反复使用，建议贴在工作台旁边。无论看SIB里的帧配置还是算HARQ往返时间，先把这三个数摆出来，基本就不会错。

5.2 坑二：PDCCH是信道，但不是传数据的信道

现象：把PDCCH当成“下行控制数据的传输信道”，甚至和PDSCH混为一谈，看调度log时半天找不到数据在哪。

原因：讲义物理层章节先列物理信道、再列传输信道，PDCCH没有对应的传输信道，很容易被误解为“某种传输信道”。

解决：记一条口诀：PDCCH从来不下传用户数据，它传的是下行调度指令（DCI，Downlink 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消息里剥出来送给MME，MME回Attach Accept后再去建立默认承载”；S_TMSI寻呼的本质是“MME不知道你在哪，只能让基站喊你，你用Initial Context Setup响应来回答‘我在’”。

6.3 拿实网log做交叉验证

第三步是拿一份真实log或信令追踪，随便挑一条流程，把卡片往信令消息上一套。没有实网设备时，公开的LTE信令捕获或者仿真平台输出也可以，核心是把每条你画的箭头和真实消息对应起来。对不上的地方，多数时候不是log错了，而是哪一步状态转换没画对。

从那以后，我每拿一份协议类文档，都是先把“一页纸加流程卡”做完才放回书架。遇到问题翻文档是检索，不是重新读一遍；带新人时让他画一遍帧结构，也比讲十遍有效。这套方法对任何PDF格式的技术文档都通用。这份《LTE协议原理》的资料就在资源包里，下载后按上面的步骤走一遍，框架立起来很快，希望帮到你。

本文还有配套的精品资源，点击获取