VoLTE端到端业务详解 | 空口主要信令过程

书籍来源：艾怀丽《VoLTE端到端业务详解》

一边学习一边整理书中的笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：VoLTE端到端业务详解 | 汇总_COCOgsta的博客-CSDN博客

---

3.2.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-5为小区搜索流程。

3.2.2 随机接入

随机接入分为基于冲突的随机接入和基于非冲突的随机接入两个流程。其区别为针对两种流程选择的随机接入前缀的方式。前者为UE从基于冲突的随机接入前缀中依照一定算法随机选择一个前缀；后者是基站侧通过下行专用信令给UE指派非冲突的随机接入前缀。具体流程如下。

1.基于冲突的随机接入

如图3-6所示，基于冲突的随机接入过程包含4个步骤。

流程1：UE在RACH上发送随机接入前缀。

流程2：eNB的MAC层产生随机接入响应，并在DL-SCH上发送。

流程3：UE的RRC层产生调度请求（或RRC连接请求、跟踪区域更新、RRC连接重建请求）并在映射到UL–SCH上的CCCH逻辑信道上发送。

流程4：RRC冲突解决由eNB的RRC层产生，并映射到DL–SCH上的CCCH或者DCCH（FFS）逻辑信道上发送。

2.基于非冲突的随机接入

如图3-7所示，基于非冲突的随机接入过程包括三步。

流程0：eNB通过下行专用信令给UE指派非冲突的随机接入前缀（Non-Contention Random Access Preamble），这个前缀不在BCH上广播的集合中。

流程1：UE在RACH上发送指派的随机接入前缀。

流程2：eNB的MAC层产生随机接入响应，并在DL-SCH上发送。

3.2.3 开机附着

1.正常流程

UE刚开机时，先开始物理下行同步，搜索测量进行小区选择，选择到一个合适的或者可接受的小区后，驻留并进行附着过程。附着过程见图3-8。

流程1～5建立RRC连接，流程6、9建立S1连接，完成这些过程即标志着NAS信号连接建立完成。

流程7：UE刚开机第一次附着，使用IMSI，无用户标识获取过程；后续，如果有有效的GUTI，使用GUTI附着，核心网才会发起Identity过程（为上下行直传消息）。

流程10～12：如果流程9带了UE Radio Capability IE，则eNB不会发送UE Capability Enquiry消息给UE，即没有10～12过程；否则eNB会发送UE Capability Enquiry消息给UE，UE上报无线能力信息后，eNB再发UE Capability Info Indication，给核心网上报UE的无线能力信息。

为了减少空口开销，在空闲态下MME会保存UE Radio Capability信息，Initial Context Setup Request消息会带给eNB，除非UE在执行附着或者“first TAU following GERAN/UTRAN Attach”或“UE radio capability Update”TAU过程（也就是这些过程MME不会带UE Radio Capability信息给eNB，并会把本地保存的UE Radio Capability信息删除，eNB会向UE要能力信息，并报给MME。注：“UE radio capability Update”。

在连接态下，eNB会一直保存UE Radio Capability信息。

UE的E-UTRAN无线能力信息如果发生改变，需要先分离，再附着。

发起UE上下文释放（21～25）的条件：

• eNB触发的UE上下文释放的原因。比如，O&M Intervention（O&M干预）、Unspecified Failure（未指定失败）、User Inactivity（用户去激活）、Repeated RRC Signalling Integrity Check Failure（重复RRC信令完整性检查失败）、Release due to UE Generated Signalling Connection Release（由于UE生成信令连接释放而释放），等等；

• MME触发的UE上下文释放的原因。比如，Authentication Failure（认证失败）、Detach（去分离）等。

eNB收到msg3以后，DCM给USM配置SRB1，配置完后发送msg4给UE；eNB在发送RRC Connection Reconfiguration前，DCM先给USM配置DRB/SRB2等信息，配置完后发送RRC Connection Reconfiguration给UE，收到RRC Connection Reconfiguration Complete后，控制面再通知用户面资源可用。

流程13～15：eNB发送完消息13，并不需要等收到消息14，就可直接发送消息15。

如果发起IMSI附着，UE的IMSI与另外一个UE的IMSI重复，并且其他UE已经附着，则核心网会释放先前的UE。如果IMSI中的MNC与核心网配置的不一致，则核心网会回复拒绝附着。

流程9：该消息为MME向eNB发起的初始上下文建立请求，请求eNB建立承载资源，同时带安全上下文，可能带用户无线能力、切换限制列表等参数。UE的安全能力参数是通过附着请求消息带给核心网的，核心网再通过该消息送给eNB。如果UE的网络能力（安全能力）信息改变，需要发起TAU。

2.异常流程

（1）RRC连接建立失败流程如图3-9所示。

（2）核心网拒绝流程如图3-10所示。

如果是ESM过程导致的拒绝（比如默认承载建立失败），则会带PDN Connectivity Reject消息；如果EMM层拒绝，则只有Attach Reject消息。

常见的拒绝原因为IMSI中的MNC与核心网配置得不一致。

（3）eNB未等到Initial Context Setup Request消息流程如图3-11所示。

（4）RRC重配消息丢失或者没收到RRC重配完成消息或者eNB内部配置UE的安全参数等失败的流程如图3-12所示。

3.2.4 UE发起的Service Request

1.正常流程UE在空闲态模式下，需要发送业务数据时，发起业务请求（Service Request）流程，如图3-13所示。

2.异常流程

（1）RRC连接建立失败。

流程同第3.2.3节中的“RRC连接建立失败”场景。

（2）核心网拒绝流程如图3-14所示。

（3）eNB未等到Initial Context Setup Request消息。

流程同第3.2.3节中“eNB未等到Initial Context Setup Request消息”场景，区别在于Service Request过程失败没有重发。

（4）RRC重配消息丢失或者eNB内部配置UE的安全参数失败或者没有建立起一个非GBR承载。

同第3.2.3节中“RRC重配消息丢失或者eNB内部配置UE的安全参数失败或者没有建立起一个非GBR承载“场景，区别在于Service Request过程失败没有重发。（5）eNB建立专用承载失败。

（5）eNB建立专用承载失败。

当附着成功，建立一个专用承载后，如果RRC连接释放进入空闲态，下次UE发起数据时会发起Service Request，该过程会为默认承载和专用承载建立对应的DRB等参数。如果eNB建立专用承载失败，则回复给核心网Initial Context Setup Response消息，并带失败列表，告知核心网专用承载建立失败，核心网会在本地激活该专用承载；同时RRC Connection Reconfiguration消息也不会带该专用承载的DRB，UE收到后发现该专用承载对应的DRB没有建立起来，也会在本地激活该承载，这样UE和核心网承载保持一致。具体流程图同第3.2.4节正常流程。（6）eNB建立默认承载失败。

（6）eNB建立默认承载失败。

场景同上，当建立的这个专用承载也为非GBR承载时，eNB可能会成功建立该专用承载，而失败建立默认非GBR承载，这样回复给核心网Initial Context Setup Response消息，带失败列表。核心网发现默认承载建立失败时，会本地附着该UE；同时RRC Connection Reconfiguration消息也不会带该默认承载的DRB，UE收到后发现默认承载对应的DRB没有建立起来，也会本地去激活该默认承载，以及关联的专用承载，从而本地去附着（只有一个默认承载时），这样UE和核心网承载保持一致。流程如图3-15所示。

3.2.5 网络发起的Paging

（1）S-TMSI寻呼。

UE在空闲态下，当网络需要给该UE发送数据（业务或者信令）时，发起寻呼（Paging）过程。流程如图3-16所示。

（2）IMSI寻呼。

当网络发生错误需要恢复时（例如S-TMSI不可用），可发起IMSI寻呼，UE收到后执行本地去附着，然后再开始附着，流程如图3-17所示。

3.2.6 TAU

当UE进入一个小区，该小区所属TAI不在UE保存的TAI列表名单内时，UE发起正常TAU流程，分为空闲态和连接态（切换时）。如果TAU接收分配了一个新的GUTI，则UE需要回复TAU完成，否则不用回复。

1.正常流程

（1）空闲态下发起的。

空闲态下，如果有上行数据或者上行信令（与TAU无关的）发送，UE可以在TAU Request消息中设置一个“active”标识，来请求建立用户面资源，并且TAU完成后保持NAS信令连接。如果没有设置“active”标识，则TAU完成后释放NAS信令连接。

空闲态下发起的TAU流程也可以带EPS Bearer Context Status IE，如果UE带该IE，MME回复消息也带该IE，双方EPS承载通过IE保持同步。

空闲态下发起的不设置“active”标识的正常TAU流程如图3-18所示。

（2）连接态下发起的。

连接态下发起的TAU流程如图3-19所示，需要特别说明的内容如下。

① 如果TAU Accept未分配一个新的GUTI，则无过程6、7；

② 切换下发起的TAU，完成后不会释放NAS信令连接；

③ 连接态下发起的TAU，不能带“active”标识。

2.异常流程

异常流程同第3.2.4节。

3.2.7 去附着

1.关机去附着

UE关机时，需要发起去附着流程，通知网络释放其保存的该UE的所有资源，流程如图3-20所示。

说明：空闲态和连接态下发起的区别同上面TAU的区别。

2.非关机去附着

如图3-21和图3-22所示，非关机去附着包含空闲态和连接态两种场景。两种场景区别就是Detach-Request这条NAS消息在空闲态是否需要先随机接入，建立RRC连接。

如果是非关机去附着，则会收到MME的Detach Accept响应消息和eNB的RRC Connection Release消息。

（1）空闲态下发起的非关机去附着。

（2）连接态下发起的非关机去附着。

3.2.8 切换

当UE在连接模式下时，eNB可以根据UE上报的测量信息来判决是否需要执行切换，如果需要切换，则发送切换命令给UE，UE不区分切换是否改变了eNB。

非竞争切换流程如图3-23所示。

3.2.8.1 基站内的切换

如图3-24所示，基站内切换流程包含两步。

（1）eNB发送RRC Connection Reconfiguration消息给UE，消息中携带切换信息MobilityControlInfo，包含目标小区ID、载频、测量带宽给用户分配的C-RNTI，通用RB配置信息（包括各信道的基本配置、上行功率控制的基本信息等），给用户配置Dedicated Random Access Parameters避免用户接入目标小区时有竞争冲突。

（2）UE按照切换信息在新的小区接入，向eNB发送RRC Connection Reconfiguration Complete消息，表示切换完成，正常切入到新小区。

3.2.8.2 基站间的切换

（1）基于X2接口的切换，如图3-25所示。

（2）基于S1接口的切换，如图3-26所示。

两个eNB之间的切换，同时完成与eNB建立S1接口承载的两个MME的切换，即跨MME的切换。切换命令同eNB内部切换，携带的信息内容也一致。

3.2.9 专用承载建立

1.正常流程

专用承载建立可以由UE或者MME主动发起，eNB不能主动发起，并且只能在连接态下发起该流程。UE主动发起专用承载建立成功的流程如图3-27所示。

说明：

（1）如果是MME主动发起的承载建立流程，则无步骤1、2；

（2）UE发起的承载建立流程，核心网可以回复承载建立、修改流程。

2.异常流程

（1）核心网拒绝UE主动发起承载建立的流程如图3-28所示。

如果拒绝原因值是“Unknown EPS Bearer Context”，UE会本地去激活存在的默认承载。

（2）eNB本地建立失败（核心网主动发起的建立）。

如果eNB建立失败，会回复E-RAB Setup Response，附带失败建立的承载列表及原因，如图3-29所示。

如果eNB未等到RRC重配完成消息，即回复失败，会给核心网发UE上下文释放请求消息，如图3-30所示。

（3）UE NAS层拒绝。

如果是UE的NAS层拒绝，则核心网收到后会给eNB发送E-RAB释放消息，来释放刚刚建立的S1承载，此时不带NAS PDU。eNB收到消息后，发RRC重配给UE来释放刚建立的DRB参数，如图3-31所示。

（4）上行直传NAS消息丢失。

说明：如图3-32所示，如果核心网没有收到UE回复的NAS消息，会重发请求消息，重发4次后，如果还没收到应答则放弃。

3.2.10 专用承载修改

1.正常流程

专用承载修改可以由UE、MME主动发起，不能由eNB主动发起，只能在连接态下发起该流程。流程如图3-33所示。

（1）修改QoS。

说明：

① MME主动发起的承载建立、修改、释放，无步骤1、2；

② eNB主动发起的释放，无步骤1，步骤2改为发送E-RAB Release Indication消息给MME；

③ UE发起的承载修改流程，核心网可以回复承载建立、修改、释放流程。

（2）不修改QoS，只修改TFT。

说明：如图3-34所示，不修改QoS，只修改TFT参数时，为上下行直传消息，与eNB无关。

2.异常流程

（1）核心网拒绝流程如图3-35所示。

如果拒绝原因值是“Unknown EPS Bearer Context”，UE会本地去激活存在的专用承载。

（2）eNB回复失败。

eNB回复失败区分为“eNB本地失败，没有给UE发送RRC重配消息”和“eNB未收到RRC重配完成消息，回复失败”两种场景。

以上过程同第3.2.9节中“建立失败”对应的两个场景。

（3）UE NAS层拒绝。

过程同第3.2.9节中对应的场景。

（4）上行直传NAS消息丢失。

过程同第3.2.9节中对应的场景。

3.2.11 专用承载释放

专用承载释放可以由eNB、MME主动发起，只能在连接态下发起该流程。流程如图3-36所示。

开机附着、建立专用承载、释放专用承载、释放RRC连接的空口RRC信令如图3-37所示（与EPC相关联的信令没画出）。其中，1～2是RA过程[UE底层收到Msg4以后，通过带的UE Contention Resolution Identity MAC Control Element（UE竞争解决标识MAC控制单元）与Msg3码流匹配，如果一样，则认为RA过程成功，把Msg4送给RRC层]；3～4是RRC连接建立过程（收到消息4以后，RRC从空闲态转为连接态模式）；5～7是附着过程（附着过程完成后，UE成功注册到网络，网络有该UE信息，UE获得GUTI、TAI列表，并且默认EPS承载建立成功）；8～10是专用EPS承载建立过程（如果默认EPS承载的QoS不能满足业务需求，UE可以发起专用承载建立过程）；11～13是EPS承载释放过程（用来释放某一个专用EPS承载，或者UE对应的一个PDN下的所有EPS承载）；14是RRC连接释放过程（UE收到该消息后从连接态模式转为空闲态模式）。