1 概述对信令的理解和熟悉有助于在网络规划和优化过程中定位问题，因此是网络优化的必备能力。通常遇到问题，大家需要结合网络侧（后台信令跟踪）和终端侧两边的信令，共同分析。 本文首先先容了LTE网络架构及各个接口；接着详细描述了TDD-LTE的空口的信令流程，希翼对读者学习LTE有所帮助。 2 TDD-LTE网络结构概述LTE的系统架构分成两部分，包括演进后的核心网EPC（MME/S-GW）和演进后的接入网E-UTRAN。演进后的系统仅存在分组交换域。 LTE接入网仅由演进后的节点B（evolved NodeB）组成，提供到UE的E-UTRA控制面与用户面的协议终止点。eNB之间通过X2接口进行连接，并且在需要通信的两个不同eNB之间总是会存在X2接口。LTE接入网与核心网之间通过S1接口进行连接，S1接口支撑多—多联系方式。 与3G网络架构相比，接入网仅包括eNB一种逻辑节点，网络架构中节点数量减少，网络架构更加趋于扁平化。扁平化网络架构降低了呼叫建立时延以及用户数据的传输时延，也会降低OPEX与CAPEX。 由于eNB与MME/S-GW之间具有灵活的连接（S1-flex），UE在移动过程中仍然可以驻留在相同的MME/S-GW上，有助于减少接口信令交互数量以及MME/S-GW的处理负荷。当MME/S-GW与eNB之间的连接路径相当长或进行新的资源分配时，与UE连接的MME/S-GW也可能会改变。
2.1 EPC与E-UTRAN功能划分与3G系统相比，由于重新定义了系统网络架构，核心网和接入网之间的功能划分也随之有所变化，需要重新明确以适应新的架构和LTE的系统需求。针对LTE的系统架构，网络功能划分如下图：
eNB功能： 1） 无线资源管理相关的功能，包括无线承载控制、接纳控制、连接移动性管理、上/下行动态资源分配/调度等； 2） IP头压缩与用户数据流加密； 3） UE附着时的MME选择； 4） 提供到S-GW的用户面数据的路由； 5） 寻呼消息的调度与传输； 6） 系统广播信息的调度与传输； 7） 测量与测量报告的配置。 MME功能： 1） 寻呼消息分发，MME负责将寻呼消息按照一定的原则分发到相关的eNB； 2） 安全控制； 3） 空闲状态的移动性管理； 4） SAE承载控制； 5） 非接入层信令的加密与完整性保护。 服务网关功能： 1） 终止由于寻呼原因产生的用户平面数据包； 2） 支撑由于UE移动性产生的用户平面切换。 2.2 E-UTRAN接口的通用协议模型E-UTRAN接口的通用协议模型如下图所示，适用于E-UTRAN相关的所有接口，即S1和X2接口。E-UTRAN接口的通用协议模型继承了UTRAN接口的定义原则，即控制面和用户面相分离，无线网络层与传输网络层相分离。继续保持控制平面与用户平面、无线网络层与传输网络层技术的独立演进，同时减少了LTE系统接口标准化工作的代价。
2.3 S1接口S1接口是MME/S-GW网关与eNB之间的接口，S1接口与3G UMTS系统Iu接口的不同之处在于，Iu接口连接包括3G核心网的PS域和CS域，S1接口只支撑PS域。 2.3.1 S1接口的用户平面用户平面接口位于E-NodeB和S-GW之间，S1接口用户平面（S1-UP）的协议栈如下图所示。S1-UP的传输网络层基于IP传输，UDP/IP之上的GTP-U用来传输S-GW与eNB之间的用户平面PDU。
GTP-U协议具备以下特点： 1） GTP-U协议既可以基于IPv4/UDP传输，也可以基于IPv6/UDP传输； 2） 隧道端点之间的数据通过IP地址和UDP端口号进行路由； 3） UDP头与使用的IP版本无关，两者独立。 S1用户面无线网络层协议功能： 1） 在S1接口目标节点中指示数据分组所属的SAE接入承载； 2） 移动性过程中尽量减少数据的丢失； 3） 错误处理机制； 4） MBMS支撑功能； 5） 分组丢失检测机制； 2.3.2 S1接口控制面S1控制平面接口位于E-NodeB和MME之间，传输网络层是利用IP传输，这点类似于用户平面；为了可靠的传输信令消息，在IP曾之上添加了SCTP；应用层的信令协议为S1-AP。S1接口控制面协议栈如下图所示：
S1控制面功能： 1） SAE承载服务管理功能（包括SAE承载建立、修改和释放）； 2） S1 接口UE上下文释放功能； 3） LTE_ACTIVE状态下UE的移动性管理功能（包括Intra-LTE切换和Inter-3GPP-RAT切换）； 4） S1接口的寻呼； 5） NAS信令传输功能； 6） S1接口管理功能（包括复位、错误指示以及过载指示等）； 7） 网络共享功能； 8） 漫游于区域限制支撑功能； 9） NAS节点选择功能； 10） 初始上下文建立过程； 11） S1接口的无线网络层不提供流量控制和拥塞控制功能。 2.4 X2接口X2接口是eNB与eNB之间的接口。X2接口的定义采用了与S1接口一致的原则，体现在X2接口的用户平面协议结构与控制平面协议结构均与S1接口类似。 2.4.1 X2接口用户平面X2接口用户平面提供eNB之间的用户数据传输功能。X2-UP的协议栈结构如下图所示，X2-UP的传输网络层基于IP传输，UDP/IP协议之上采用GTP-U来传输eNB之间的用户面PDU。
2.4.2 X2接口控制平面X2接口控制平面协议栈如下图所示，LTE系统X2接口的定义采用了与S1接口一致的原则，其传输网络层控制平面IP层的上面也采用了SCTP，为信令提供可靠的传输。应用层信令协议表示为X2-AP。
X2接口应用层协议功能： 1） 支撑LTE_ACTIVE状态下UE的LTE接入系统内的移动性管理功能； 2） X2接口自身的管理功能，如错误指示等； 3） 上行负荷管理功能。 3 典型信令流程分析3.1 小区搜索小区搜索过程是UE和小区取得时间和频率同步，并检测小区ID的过程。E-UTRA系统的小区搜索过程与UTRA系统的主要区别是她能够支撑不同的系统带宽（1.4~20MHZ）。小区搜索通过若干下行信道实现，包括同步信道（SCH）、广播信道（BCH）和下行参考信号（RS）。SCH又分成主同步信道（PSCH）和辅同步信道（SSCH），BCH又分成主广播信道（PBCH）和动态广播信道（DBCH）。除PBCH是以正式“信道”出现的；PSCH和SSCH是纯粹的L1信道，不用来传送L2/L3控制信令，而只用于同步和小区搜索过程；DBCH最终承载在下行共享传输信道（DL-SCH），没有独立的信道。下图为小区搜索流程：
3.2 随机接入流程随机接入分为基于冲突的随机接入和基于非冲突的随机接入两个流程。其区别为针对两种流程其选择随机接入前缀的方式。前者为UE从基于冲突的随机接入前缀中依照一定算法随机选择一个随机前缀；后者是基站侧通过下行专用信令给UE指派非冲突的随机接入前缀。具体流程如下： 基于冲突的随机接入：
1) UE在RACH上发送随机接入前缀； 2) ENb的MAC层产生随机接入响应，并在DL-SCH上发送； 3) UE的RRC层产生RRC Connection Request 并在映射到UL –SCH上的CCCH逻辑信道上发送； 4) RRC Contention Resolution 由ENb的RRC层产生，并在映射到DL –SCH上的CCCH or DCCH(FFS)逻辑信道上发送。 基于非冲突的随机接入
1) ENb 通过下行专用信令给UE指派非冲突的随机接入前缀（non-contention RandomAccess Preamble ），这个前缀不在BCH上广播的集合中。 2) UE在RACH上发送指派的随机接入前缀。 3) ENb的MAC层产生随机接入响应，并在DL-SCH上发送。 3.3 开机附着流程3.3.1 正常流程UE刚开机时，先进行物理下行同步，搜索测量进行小区选择，选择到一个suitable或者acceptable小区后，驻留并进行附着过程。附着流程图如下：
说明： 1) 步骤1～5会建立RRC连接，步骤6、9会建立S1连接，完成这些过程即标志着NAS signalling connection建立完成，见24.301。 2) 消息7的说明：UE刚开机第一次attach，使用的IMSI，无Identity过程；后续，如果有有效的GUTI，使用GUTI attach，核心网才会发起Identity过程（为上下行直传消息）。 3) 消息10~12的说明：如果消息9带了UE Radio Capability IE，则eNB不会发送UECapabilityEnquiry消息给UE，即没有10~12过程；否则会发送，UE上报无线能力信息后，eNB再发UE Capability Info Indication，给核心网上报UE的无线能力信息。 Ø 为了减少空口开销，在IDLE下MME会保存UE Radio Capability信息，在INITIAL CONTEXT SETUP REQUEST消息会带给eNB，除非UE在实行attach或者"firstTAU following GERAN/UTRAN Attach" or "UE radio capabilityupdate" TAU过程（也就是这些过程MME不会带UE Radio Capability信息给eNB，并会把本地保存的UE Radio Capability信息删除，eNB会问UE要能力信息，并报给MME。注："UE radio capabilityupdate" TAU is only supported for changes of GERAN and UTRAN radiocapabilities in ECM-IDLE.）。 Ø 在CONNECTED下，eNB会一直保存UE RadioCapability信息。 Ø UE的E_UTRAN无线能力信息如果发生改变，需要先detach，再attach。 4) 发起UE上下文释放（即21～25）的条件： - eNodeB-initiatedwith cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, RepeatedRRC signalling Integrity Check Failure, Release due to UE generated signallingconnection release, etc.; or - MME-initiatedwith cause e.g. authentication failure, detach, etc. 5) eNB收到msg3以后，DCM给USM配置SRB1，配置完后发送msg4给UE；eNB在发送RRCConnectionReconfiguration前，DCM先给USM配置DRB/SRB2等信息，配置完后发送RRCConnectionReconfiguration给UE，收到RRCConnectionReconfigurationComplete后，控制面再通知用户面资源可用。 6) 消息13~15的说明：eNB发送完消息13，并不需要等收到消息14，就直接发送消息15。 7) 如果发起IMSI attach时，UE的IMSI与另外一个UE的IMSI重复，并且其他UE已经attach，则核心网会释放先前的UE。如果IMSI中的MNC与核心网配置的不一致，则核心网会回复attach reject。 8) 消息9的说明：该消息为MME向eNB发起的初始上下文建立请求，请求eNB建立承载资源，同时带安全上下文，可能带用户无线能力、切换限制列表等参数。UE的安全能力参数是通过attach request消息带给核心网的，核心网再通过该消息送给eNB。UE的网络能力（安全能力）信息改变的话，需要发起TAU。 3.3.2 异常流程3.3.2.1 RRC连接建立失败
3.3.2.2 核心网拒绝
1) 如果是ESM过程导致的拒绝（比如默认承载建立失败），才会带PDN CONNECTIVITY REJECT消息；EMM层拒绝，只有ATTACHREJECT消息。 2) 常见的拒绝原因有：IMSI中的MNC与核心网配置的不一致。 3.3.2.3 eNB未等到Initial context setuprequest消息 3.3.2.4 RRC重配消息丢失或者没收到RRC重配完成消息或者eNB内部配置UE的安全参数等失败
3.4 UE发起的service request流程3.4.1 正常流程UE在IDLE模式下，需要发送业务数据时，发起service request过程，流程图如下： 3.4.2 异常流程3.4.2.1 RRC连接建立失败处理同3.3.2.1。 3.4.2.2 核心网拒绝
3.4.2.3 eNB未等到Initial context setuprequest消息处理同3.3.2.3， 区别在于service request过程失败没有重发。 3.4.2.4 RRC重配消息丢失或者eNB内部配置UE的安全参数失败或者没有建立起来一个非GBR承载同3.3.2.4， 区别在于service request过程失败没有重发。 3.4.2.5 eNB建立专用承载失败当attach成功，建立一个专用承载后，如果RRC连接释放进入了IDLE，下次UE发起数据时会发起service request，该过程会为默认承载和专用承载建立对应的DRB等参数。如果eNB建立专用承载失败，则回复给核心网Initial contextsetup response，带失败列表，告知核心网专用承载建立失败，核心网会本地去激活该专用承载；同时RRCConnectionReconfiguration消息也不会带该专用承载的DRB，UE收到后发现该专用承载对应的DRB没有建立起来，也会本地去激活该承载，这样UE和核心网承载保持一致。 流程图同3.4.1正常流程。 3.4.2.6 eNB建立默认承载失败场景同上，当建立的这个专用承载也为非GBR承载时，eNB可能会成功建立该专用承载，而失败建立默认非GBR承载，这样回复给核心网Initial context setupresponse，带失败列表，核心网发现默认承载建立失败时，会本地detach该UE；同时RRCConnectionReconfiguration消息也不会带该默认承载的DRB，UE收到后发现默认承载对应的DRB没有建立起来，也会本地去激活该默认承载，以及关联的专用承载，从而本地detach（只有一个默认承载时），这样UE和核心网承载保持一致。 流程图如下：
3.5 网络发起的paging流程3.5.1 S_TMSI寻呼UE在IDLE模式下，当网络需要给该UE发送数据（业务或者信令）时，发起寻呼过程，流程图如下：
3.5.2 IMSI寻呼当网络发生错误需要恢复时（例如S-TMSI不可用），可发起IMSI寻呼，UE收到后实行本地detach，然后再开始attach。
3.6 TAU流程当UE进入一个小区，该小区所属TAI不在UE保存的TAI list内时，UE发起正常TAU流程，分为IDLE和CONNECTED（即切换时）下。如果TAU accept分配了一个新的GUTI，则UE需要回复TAU complete，否则不用回复。 3.6.1 正常流程3.6.1.1 IDLE下发起的IDLE下，如果有上行数据或者上行信令（与TAU无关的）发送，UE可以在TAU request消息中设置an "active"标识，来请求建立用户面资源，并且TAU完成后保持NAS信令连接。如果没有设置"active"标识，则TAU完成后释放NAS信令连接。 IDLE下发起的也可以带EPS bearer context status IE，如果UE带该IE，MME回复消息也带该IE，双方EPS承载通过这个IE保持同步。 Ø IDLE下发起的不设置"active"标识的正常TAU流程图如下：
3.6.1.2 CONNECTED下发起的说明： 1）如果TAU accept未分配一个新的GUTI，则无过程6、7； 2）切换下发起的TAU，完成后不会释放NAS信令连接； 3）CONNECTED下发起的TAU，不能带"active"标识。 3.6.2 异常流程异常流程同3.4.2。 3.7 去附着3.7.1 关机去附着UE关机时，需要发起去附着流程，来通知网络释放其保存的该UE的所有资源，流程图如下： 说明： 1) IDLE和CONNECTED下发起的区别同上面TAU的区别； 2) 如果是非关机去附着，则会收到MME的Detach Accept响应消息和eNB的RRC Connection Release消息。 3.7.2 非关机去附着3.7.2.1 IDLE下发起的非关机去附着
3.7.2.2 CONNECTED下发起的非关机去附着
3.8 切换流程当UE在CONNECTED模式下时，eNodeB可以根据UE上报的测量信息来判决是否需要实行切换，如果需要切换，则发送切换命令给UE，UE不区分切换是否改变了eNodeB。非竞争切换流程图如下：
3.9 专用承载建立流程3.9.1 正常流程专用承载建立可以由UE或者MME主动发起，eNB不能主动发起，并且只能在connected下发起该流程。
说明： 1）如果是MME主动发起的承载建立流程，则无步骤1、2； 2）UE发起的承载建立流程，核心网可以回复承载建立、修改流程； 3）可以同时建立多个专用承载，但目前还不支撑。 3.9.2 异常流程3.9.2.1 核心网拒绝
如果拒绝原因值是"unknownEPS bearer context"，UE会本地去激活存在的默认承载。 3.9.2.2 eNB本地建立失败（核心网主动发起的建立）如果eNB建立失败，会回复E-RABSETUP RESPONSE，带失败建立的承载列表，并带原因值，核心网应该根据原因值处理（目前eNB的实现是： 如果eNB本地建立失败，即还没有给UE发送RRC重配消息，这时eNB会发送NAS NONDELIVERY INDICATION给MME）。但目前核心网没有查看原因值，都给UE下发了Deactivate EPS bearer context request消息（与协议不符），UE查找不到该承载，也回复DeactivateEPS bearer context accept。
3.9.2.3 eNB未等到RRC重配完成消息，回复失败
eNB未收到RRC重配完成消息时，会给核心网发UE上下文释放请求消息。 3.9.2.4 UE NAS层拒绝如果是UE的NAS层拒绝，则核心网收到后会给eNB发送E-RAB释放消息，来释放刚刚建立的S1承载，此时不带NAS PDU。eNB收到消息后，发RRC重配给UE来释放刚建立的DRB参数。
3.9.2.5 上行直传NAS消息丢失
说明：如果核心网没有收到UE回复的NAS消息，会重发请求消息，重发4次后，如果还没收到应答则放弃。 3.10专用承载修改流程3.10.1 正常流程专用承载修改可以由UE 、MME主动发起，不能由eNB主动发起，只能在connected下发起该流程。流程图如下： 3.10.1.1 修改QoS
说明： 1）MME主动发起的承载建立/修改/释放无步骤1、2； 2）eNB主动发起的释放，无步骤1，步骤2改为发送E-RAB RELEASE INDICATION消息给MME； 3）UE发起的承载修改流程，核心网可以回复承载建立、修改、释放流程。 3.10.1.2 不修改QoS，只修改TFT
说明： 不修改QoS，只修改TFT参数时，为上下行直传消息，与eNB无关。 3.10.2 异常流程3.10.2.1 核心网拒绝如果拒绝原因值是"unknown EPS bearer context"，UE会本地去激活存在的专用承载。 3.10.2.2 eNB回复失败eNB回复失败区分为： eNB本地失败，没有给UE发送RRC重配消息； eNB未收到RRC重配完成消息，回复失败。 以上过程同3.9.2.2和3.9.2.3。 3.10.2.3 UE NAS层拒绝同3.9.3.4。 3.10.2.4 上行直传NAS消息丢失同3.9.2.5。 3.11专用承载释放流程专用承载释放可以由eNB 、MME主动发起，只能在connected下发起该流程。 流程图如下： 3.12空口RRC信令
开机attach、建立专用承载、释放专用承载、释放RRC连接的空口RRC信令见上图（与EPC的信令没画出）。 其中，1～4是RA过程（UE底层收到Msg4以后，通过带的UE Contention ResolutionIdentity MAC control element与Msg3码流匹配，如果一样，则认为RA过程成功，把Msg4送给RRC层）；1～5是RRC连接建立过程（收到消息4以后，RRC从IDLE转为CONNECTED模式）；5～7是attach过程（attach过程完成后，UE成功注册到网络，网络有该UE信息，UE获得GUTI、TAI list，并且默认EPS承载建立成功）；8～10是专用EPS承载建立过程（如果默认EPS承载的QoS不能满足业务需求，UE可以发起专用承载建立过程）；11～13是EPS承载释放过程（用来释放某一个专用EPS承载，或者UE对应的一个PDN下的所有EPS承载）；14是RRC连接释放过程（UE收到该消息后从CONNECTED转为IDLE模式）。
注：他人资料，为了下载论坛资料而上传，莫怪。 谢谢。
| 
发表于 2015-5-8 16:34:09
