1. 一张LTE核心网的骨架EPC各网元的职责与协作方式1.1 一张网两块域E-UTRAN与EPC的分工做LTE维护这些年被问得最多的一句话就是“为什么手机信号明明是满格却上不了网”每次听到这个问题我都知道提问的人大概率是只盯着空口侧在看。其实你手机上那格信号只代表你跟基站之间的无线链路是通的它跟“能不能访问互联网”之间还隔着整整一张核心网。LTE整个网络架构按3GPP的定义分成两个大块。一块是你看得见摸得着的无线接入网叫E-UTRAN也就是宏站、室分、微微站这些设备它们的核心角色是eNodeB基站。另一块就是你平时看不见、但所有业务数据都要穿过的核心网叫EPCEvolved Packet Core演进分组核心网。EPC的职责往大了说就三件事让终端能找到网络并完成登记移动性管理、让终端能被网络找到寻呼与位置管理、让终端的数据能跑到互联网上会话与承载管理。这三件事分别由不同的网元承担互相之间通过标准接口通信。理解了这张“分工表”后面再看入网流程就顺畅多了。1.2 四大核心网元MME、SGW、PGW、HSS各管什么EPC里最常见的网元是以下四个做架构设计或故障排查时基本绕不开它们。先说MMEMobility Management Entity移动性管理实体。它是整个核心网里最忙的“大脑”。终端的附着Attach、跟踪区更新TAU、切换时的移动性管理、鉴权、寻呼这些控制信令全部要经过MME处理但它不转发任何业务数据。你把它理解成机场的值机柜台——它负责核对身份、安排登机口但它本人不搬行李。然后是SGWServing Gateway服务网关和PGWPDN Gateway分组数据网关。这两个网元业务上经常合设但逻辑上必须拆开看。SGW是用户面数据在接入网侧的锚点终端在基站之间切换时数据通道不中断靠的就是SGW兜底。PGW则是终端通往外部数据网络比如互联网、企业专网的出口终端上网用的IP地址就是PGW分配的。一句话SGW管“内部交通”PGW管“出入境”。最后是HSSHome Subscriber Server归属用户服务器。它是一本大账本存着每个用户的签约信息、鉴权参数、当前所在的MME地址。终端能不能用LTE、能开多大的带宽、能不能漫游都由HSS里那条签约数据说了算。入网流程里最关键的鉴权环节就是MME跟HSS配合完成的。除了这四个还有**PCRF策略与计费控制功能**负责下发QoS策略和计费规则。在承载建立时PGW会向PCRF查询用户应该用哪个QCI、多大的AMBR这个动作也贯穿在入网流程里。1.3 为什么控制面和用户面要分开走这张网里最值得琢磨的设计是把控制信令和业务数据彻底分开走。MME走的是控制面Signaling PlaneSGW/PGW走的是用户面User Plane。两者之间的通道是逻辑隔离的物理上可以共用传输也可以各自独立部署。这样设计的好处有两个。第一可以独立扩容。如果一个区域里用户话务量不大但信令量很大比如大量物联网终端频繁上报那单独扩容MME就行不用动SGW/PGW。反过来如果视频业务流量暴涨可以只扩用户面设备。第二故障隔离更干净。用户面设备出故障时控制面还活着终端不会被踢下线可以继续做位置更新控制面出问题时至少已建立的业务面通道还能把当前流量走完。我见过不少刚入行的兄弟试图把MME和SGW“绑在一起”理解结果一遇到跨厂家组网就晕。实际组网里MME经常是一个厂家的SGW/PGW是另一个厂家的中间通过S11标准接口互通彼此不认识对方的内部实现只看标准消息。这套“松耦合”的设计是电信网络能支撑亿万终端的关键。2. 入网前的预备环节终端怎么看懂一张LTE网2.1 开机第一件事PLMN选择和小区驻留一部手机从冷启动到注册上网不是直接就给核心网发消息的。它得先搞明白周围有哪些网络哪个是自己能用的。这个动作叫PLMN选择。PLMNPublic Land Mobile Network公共陆地移动网络就是运营商的“身份证”由MCC移动国家码 MNC移动网络码组成。在国内就是460开头的那个组合。终端开机后会读SIM卡里存的PLMN列表等效PLMN列表、运营商控制PLMN列表等然后扫频搜索周围小区找到一个广播的PLMN能跟SIM卡匹配上的就停下来继续读系统消息。系统消息里会携带小区是否被禁止接入cellBarred、最小接收电平q-RxLevMin等参数终端据此做小区选择。S准则计算涉及RSRP和最低门限实际优化中常用这个标准来“锁”终端优先驻留某个频点或某个小区。这一步完成之后终端才在无线侧站稳了脚。但请注意这时候它跟核心网还没有任何逻辑连接在核心网眼里它只是一个“潜在用户”还不是“在线用户”。2.2 从系统消息里读出TAC和Cell ID终端驻留小区之后接下来这一步就是入网流程里跟核心网产生关联的第一个关键点读取系统消息中的TAC和Cell ID。我们需要把这两个标识物搞清楚。先说TACTracking Area Code跟踪区码在系统消息SIB1里广播跟PLMN合在一起组成TAITracking Area Identity跟踪区标识。TAC是核心网做寻呼的最小粒度单位——网络想把一个终端叫醒会在它上次登记的“一片区域”里发寻呼消息这片区域由一个或多个TA组成而不是全城广播。再说Cell ID小区ID。这里的Cell ID在LTE里更准确的说法是ECIE-UTRAN Cell IdentifierE-UTRAN小区标识符总共28比特通常由20比特的eNodeB ID和8比特的本地小区ID组成。它跟PLMN拼在一起就是ECGI这是一个小区的全球唯一身份。日常路测软件里看到的“小区PCI”虽然也重要但那只在空口无线层有局部意义只有ECGI才是全局可寻址的身份证。TAC和Cell ID会在终端发起附着时由基站原封不动地捎带给MME。核心网一看TAC就知道你现在在哪个跟踪区一看Cell ID就知道你精确到具体哪个小区——这一组信息就是核心网对终端的“第一印象”。2.3 TAC和Cell ID谁先谁后寻呼粒度与定位粒度的差别很多人把TAC和Cell ID当成一回事其实它们解决的完全是不同尺度的问题。核心网存着终端当前的TA级别位置。你来电话时网络不知道你在哪个小区只知道你在哪个TA范围里于是就让这个TA覆盖的所有小区一起发寻呼。TAC范围设得越大寻呼成功率越高但寻呼信道开销和基站负荷也越大TAC范围设得越小寻呼精准但终端移动时触发位置更新的频率就高信令负担又上去了。Cell ID则是更细的一级定位。核心网在收到终端上报的测量报告或者信令消息时能精确到你在哪座基站、哪个扇区下。这个粒度服务于切换判决、话单计费、基于MR的定位等场景。一句话总结TAC管的是“呼叫时去哪儿找你”Cell ID管的是“你现在具体在哪”。两者服务于核心网不同层级的功能缺一不可。3. 附着流程全链路拆解从Attach Request到Attach Accept3.1 空口侧的第一跳随机接入与RRC连接终端确认自己可以驻留在当前小区后就要向网络发起真正的“入网申请”了。这个申请在LTE协议里叫Attach附着。整个过程的第一步是终端先在空口跟基站建立一条RRC无线资源控制连接。空口建立连接要走四步随机接入终端发前导码Preamble基站回随机接入响应RAR终端发RRC连接建立请求RRC Connection Request基站回RRC连接建立RRC Connection Setup。这几步发生在几十毫秒量级用户无感知。但RRC连接本身只是“信道”真正让核心网感兴趣的是终端在RRC建立完成消息里携带的那个NAS消息——Attach Request。NASNon-Access Stratum非接入层是终端跟核心网之间的“悄悄话”基站对NAS消息只是透传完全看不懂内容。这种设计很巧妙基站只负责把NAS消息原封不动端到端传给MME翻译和决策全部由MME来做。3.2 核心网的第一次知情Initial UE Message基站收到RRC连接建立完成里的NAS消息后会通过S1接口向MME发送一条Initial UE MessageS1AP消息。这条消息是核心网第一次“看见”这个终端的关键节点。可别小看这条消息它除了携带终端上行的Attach Request之外还携带着基站侧自动填好的几个重要参数TAC、Cell ID、eNodeB ID、终端在空口的临时标识。也就是说MME收到这条消息的瞬间就同时知道了两件事一是这个终端想入网二是这个终端当前躲在哪个小区的哪个扇区下。核心网是“谁服务谁接单”的逻辑。基站在S1接口建立时已经被配置了一组MME的IP和权重。它向哪个MME发这条消息是根据MME Pool的负荷分配算法决定的——通常按权重轮询或者基于容量配比。实际维护中如果出现过某台MME信令拥塞而其它MME相对空闲的情况先查基站的MME权重配置多半能发现问题。3.3 先验明正身鉴权与NAS安全MME收到Attach Request后第一件事不是立刻安排上网通道而是先确认“你到底是谁”。终端在Attach Request里会带上自己的身份标识如果有GUTI全球唯一临时标识就优先用GUTI没有GUTI就带上IMSI。GUTI是MME上次分配的一个临时“马甲”用于减少IMSI在空口暴露的风险。如果终端带来的GUTI不属于当前MME管辖比如从另一个MME区域漫游过来MME向终端发起Identity Request要求它上报真正的IMSI。拿到IMSI后MME向HSS发起鉴权数据请求Authentication Information RequestHSS返回一组鉴权向量RAND、AUTN、XRES、CK、IK。随后MME向终端下发Authentication Request终端侧USIM卡验证AUTN通过后计算出RES回给MME。MME比对RES和XRES一致才认定身份合法。这一步做完MME和终端会各自推演出NAS层的加密密钥和完整性保护密钥后续所有NAS消息都是“上了锁”的。我见过不少对附着失败的分析到最后定位是在鉴权环节——有的情况是HSS里该用户的鉴权算法配置跟USIM卡不一致比如老的Milenage算法没更新有的情况是多次鉴权失败触发了安全保护锁死。这类问题从空口侧怎么查都查不出来只查核心网信令才能发现。3.4 关键一跳默认承载的建立鉴权通过后MME开始给这个用户准备“上网通道”。这个通道在LTE里叫默认承载Default Bearer它提供最基本的IP连通性对应QCIQoS Class Identifier通常为9属于比特率不保证的大流量类业务。MME先向HSS发Update Location Request做位置更新HSS登记“该用户当前在哪个MME下”并把用户的签约数据APN配置、QCI、AMBR、漫游限制等返回给MME。如果这个终端之前注册在另一个MME上HSS还会通知旧MME删除该用户的上下文。接着MME向SGW发Create Session RequestS11接口SGW再向PGW发Create Session RequestS5/S8接口。PGW在这个环节里做三件事给终端分配一个IP地址来自APN对应的地址池、向PCRF查询用户的策略控制规则、建立EPS承载的实体通道。完成后响应消息按原路径逐层返回。这个环节有个极易踩的坑在APN的上联DNS解析。PGW选择是靠MME根据APN名称去DNS里解析PGW的地址完成的如果DNS记录配错或者漏配Create Session会响应失败终端就会卡在附着流程后半段——表现为“能识别SIM卡、能收到网络信号但始终注册不上”。3.5 Attach Accept下行与终端的最后一步承载建好了IP地址拿到了MME要向终端下达“批准入网”的通知。这条消息是Attach Accept但注意它不是直接单独发下去而是打包在一条Initial Context Setup RequestS1AP消息里发给基站由基站对终端执行RRC连接重配置建立无线侧的数据无线承载DRB再无线下发Attach Accept。终端收到Attach Accept后会带着消息里的默认承载信息完成无线侧数据承载建立然后回一条Attach Complete。基站把这条NAS消息用Uplink NAS Transport再转发给MME。MME收到后会向SGW发Modify Bearer Request把S1-U用户面通道的隧道端点信息确认下来。至此一条完整的数据通路才算全部打通终端 - 基站S1-U - SGW - PGW - 互联网。整个过程从终端角度看只用了两三秒但中间经过了空口、S1AP、NAS、DiameterS6a、GTP-CS11/S5五层协议栈的接力。排查问题时把这五层拆开看每一层检查哪些消息有没有出现其实比看整体结论高效得多。4. 位置更新与TAU入网之后的持续登记4.1 TAU从哪里来触发条件与消息格式附着只是入网的第一步。终端移动起来之后核心网需要持续掌握它的位置不然电话打进来时都不知道去哪儿寻呼它。这个持续登记的动作就是TAUTracking Area Update跟踪区更新。TAU有三种触发场景最常见。第一种是周期性TAU——终端内部有个定时器通常在网络下发的T3412里配置时间一到就主动向网络报到一次。第二种是跨TA的移动——终端发现自己当前所处小区的TAC不在网络给它分配的TA List里就触发TAU。第三种是能力或参数变化——比如终端从2G/3G重选到LTE、或者UE网络能力发生变化也会触发。TAU Request消息里会带上终端当前的身份标识GUTI、旧TAI、上一次TAU的TAC等信息。核心网收到后先判断这个终端的旧位置是不是在同一个MME的辖区里然后才决定要做轻量级的位置更新还是跨MME迁移用户上下文。实际维护中最容易被忽略的一点是TAU Request也可能被拒绝。网络侧通过TAU Reject携带Cause Code告诉终端“你的TAU不被接受”终端收到后可能变成受限服务状态甚至脱网。这类问题出现时往往意味着TAC规划和MME配置之间已经产生了矛盾。4.2 跨MME的TAU上下文迁移和HSS位置更新如果终端从一个MME区域移动到了另一个MME区域TAU就复杂了。新MME收到TAU Request后从终端带的旧GUTI里解析出旧MME的地址GUTI里包含MME Group ID和MME Code然后向旧MME发Context Request把这个用户的移动性上下文和承载上下文全部拉过来。旧MME收到请求后会核对完整性保护通过后把上下文推给新MME同时旧MME侧的SGW/PGW通道要做切换。新MME再根据承载上下文决定是让SGW不变、只切PGW侧还是整体迁移。最后新MME向HSS发起更新位置请求HSS把“用户当前归属MME”的指针改到新MME并触发旧MME侧的位置删除。这一串流程里最容易出现的问题是上下文不完整——比如旧MME侧用户已经因超时被删除了上下文新MME拉取时得到空响应终端就只能重新走一次完整的附着流程。从用户感知上看就是“从一个片区开车到另一个片区突然断网了几秒钟”。4.3 TA List长度与TAU风暴的博弈现在回到跟TAC规划相关的一个标志性问题TAU风暴。网络给终端分配的不是一个TAC而是一串TA List跟踪区列表。只要终端在TA List覆盖的范围内移动就不触发TAU。TA List的长短是个双刃剑给长了终端移动时不频繁TAU但单个终端的寻呼范围变大给短了寻呼范围精准但终端频繁跨区就会产生大量TAU信令。我曾经处理过一个地市级的信令风暴某MME的TAU请求量在高峰时段比其他MME高出三倍。查下去发现这个MME接入的基站区域被规划成了十几个零散TAC终端在这片区域里开车十分钟就要触发七八次TAU。最后是重新梳理了这片区域的TAC划分把相邻的归属同一寻呼区的小区合并成一个大TACTAU量立刻降下来了。所以做TAC规划时的经验法则是先看地形和移动路径再看基站拓扑。高铁沿线、跨江大桥、快速路两侧的TAC边界要尽量顺着人流方向切避免让用户在一个长直路上反复横穿多个TAC。这个活儿在图纸上画线很容易但真到路测和投诉分析阶段才见真章。4.4 一个典型TAU异常案例的排查过程最后分享一个我实际处理过的案例。某片区用户投诉手机显示LTE信号满格但不能上网开关飞行模式后恢复正常过一会儿又上不了网。从空口侧看驻留、接收功率、信噪比全部正常。打开核心网信令跟踪发现终端的行为是附着成功后不久就频繁发起TAU Request但每次都收到TAU Reject原因是#12Tracking area not allowed。顺着这个原因码查发现该片区基站的SIB1广播配置里TAC被误配成了另一个相邻片区规划的编号而核心网MME侧对小区的配置表还是旧的。终端按SIB1里广播的TAC做位置登记MME查表发现该TAC不在允许列表里直接拒绝。每次终端重启后重新附着能成功是因为附着流程里MME基于Cell ID做了小区级别允许判断但TAU走的是TA级别判断导致一个矛盾的结果。最后在基站侧把TAC配置改回规划值问题半小时内消失。这个案例说明一个道理TAC和Cell ID这些标识必须空口、基站、MME、HSS全链路保持一致任何一侧配错都会以很隐蔽的方式反馈成用户不可用。5. 从核心网侧排查入网失败的完整思路5.1 定位之前先分层问题到底在哪一段排查入网失败最忌讳一上来就盯着某个网元日志翻。我自己的习惯是先把问题分层切段每一段确认“通了还是没通”。分成四层看第一层是空口驻留层看终端能不能读到系统消息、能不能驻留小区问题表现为无服务或反复搜索网络第二层是RRC/S1层看RRC连接能不能建立、Initial UE Message有没有到MME第三层是NAS层看附着请求、鉴权、位置更新有没有通过第四层是承载层看GTP-C会话创建、默认承载建立是否成功。这四层对应四种不同的排查动作。空口驻留问题找无线参数和干扰RRC/S1问题找基站和传输链路NAS问题找MME和HSS承载问题找SGW/PGW和DNS。按这个顺序逐一排除基本能把80%的附着失败问题定位到单个网元。我在带新人时反复强调一个观点网络是分层的图谱是标准的出问题时不要相信“怪哪个网元就修哪个网元”的说法要做的是从终端侧沿着信令路径一层层确认。哪一层断了问题就在哪一层。5.2 拒绝原因码最快上手的判断工具如果附着失败核心网一定会回一条NAS层面的拒绝消息并且带上一个Emphasis原因值Cause Value。这个原因值是排查的“第一提示”非常值得背熟几个常用的。**Cause #2IMSI unknown in HSS**表示HSS里查不到这个IMSI的签约记录。常见于新开卡用户、SIM卡数据未写入HSS、或HSS数据库同步出问题。**Cause #3Illegal UE**表示IMSI被列入了黑名单常见于挂失卡或欠费停机用户。**Cause #7EPS services not allowed**表示用户签约不允许使用EPS业务常见于纯语音套餐卡尝试LTE数据业务。**Cause #11PLMN not allowed和Cause #12Tracking area not allowed**属于位置归属类拒绝一般情况下是TAC规划或签约数据里的允许区域没配好。**Cause #13Roaming not allowed**是漫游签约限制多见于异地用户漫游到不允许的区域。**Cause #15No suitable cells in tracking area**则意味着终端所在的TA里没有可选小区。还有一个高频的Cause #22Congestion代表MME或SGW/PGW侧过载。出现这个原因时先别急着改数据优先看该MME对应的信令负荷和各网元CPU负载。5.3 一个典型的S6a链路问题排查过程有一次外省同事求助一个新开局的站点所有终端附着失败原因集中为**#2IMSI unknown in HSS**但HSS侧查询该IMSI数据明明是正常的。从信令路径看MME通过S6a口Diameter协议向HSS请求鉴权数据。MME日志显示Authentication Information Request消息发出后一直没收到响应超时后MME就上报了#2。HSS侧日志却显示根本没收到这条Diameter请求。问题就锁定在两端之间的链路层。实际检查后发现S6a链路配置里MME侧的Diameter主机名Origin-Host跟HSS侧配置的白名单对不上HSS把这条消息当非法来源丢弃了。这类问题从业务数据上看不出来只有在抓包或对端日志里才发现。整个过程验证了一个经验“数据不存在”和“数据提取不到”是两回事前者查业务后者查链路。5.4 日常维护中的三个检查清单最后整理几个我在日常维护中固定执行的关键检查项。第一项是检查MME和HSS之间S6a链路时除了关注连通性还要关注Diameter的厂商ID和产品名是否匹配——很多异厂家组网场景下S6a两端的AVP属性值对定义存在细微差异不匹配时会出现“偶发失败”。第二项是关注全网基站的TAC配置一致性。建议做一个脚本每天定时比对SIB1广播的TAC、基站OMC配置的TAC、MME侧小区表里的TAC三个值不一致时直接告警。这个检查在扩容、割接、基站数据修改后特别有效。第三项是关注MME上的GUTI重复分配问题。GUTI是临时标识MME重启后如果序列号管理不当可能把同一个GUTI分配给两个用户导致附着时上下文冲突。所以每次MME倒换后建议主动观察一段时间内的附着成功率并核对GUTI重分配日志。做核心网维护这些年我最大的体会是LTE的架构虽然复杂但每一个流程环节都能在标准协议里找到准确定义。入网流程更是如此——它像一场接力赛空口、基站、MME、HSS、SGW、PGW各跑一段交接棒就是那几条标准消息。把每一步消息的走向和每个标识的作用吃透再复杂的故障也能拆成一个个可以单独验证的小问题。这套方法对刚入行的兄弟和做了几年维护的老手都同样适用。