[计算机软件及应用]RAN高层异常信令分析.doc

1 呼叫信令流程及典型信令流程41.1 MOC过程41.1.1 MOC正常信令流程41.1.2 随机接入过程（RRC信令连接建立过程）71.1.3 初始直传和鉴权、安全模式子过程151.1.4 呼叫建立子过程171.1.5 RAB建立子过程181.1.6 振铃接听子过程241.2 GPRS附着261.2.1 GPRS附着正常流程261.2.2 GPRS附着异常流程261.3 GPRS去附着291.3.1 GPRS去附着正常流程291.3.2 GPRS去附着异常流程301.4 PDP Context激活过程311.4.1 PDP激活正常过程311.4.2 PDP激活异常流程321.5 PDP Context去激活过程341.5.1 PDP Context去激活正常过程341.5.2 PDP Context去激活异常流程342 移动性管理过程352.1 位置区更新352.1.1 位置区更新正常过程352.1.2 位置区更新异常流程362.2 路由区更新372.2.1 路由区更新正常过程372.2.2 路由区更新异常流程372.3 小区/URA更新392.3.1 小区更新过程392.3.2 URA更新过程422.4 切换过程442.4.1 Intra-Node B切换442.4.2 Inter-NB /Intra-RNC切换502.4.3 Inter-RNC切换573 无线链路失败分析与处理663.1 UE侧检测无线链路失败663.1.1 无线链路失败准则663.1.2 无线链路失败后UE的行为663.2 Node B侧检测无线链路失败663.2.1 Radio Link Failure Indication过程的典型原因673.2.2 Radio Link Failure Indication过程的典型应用67附录A：文档修订记录68第 2 页 共 68 页1 呼叫信令流程及典型信令流程1.1 MOC过程1.1.1 MOC正常信令流程以下为UE处于Idle状态下发起CS呼叫的流程。具体信令流程的解释请参见RAN高层信令过程学员手册，这里不再赘述。下面就针对MOC的六个子过程分别进行。图 1.11 MOC正常呼叫流程1.1.2 随机接入过程（RRC信令连接建立过程）UE处于空闲模式下，当UE的非接入层请求建立信令连接时，UE将首先发起RRC连接建立过程。每个UE最多只能建立一个RRC连接。RNC接收到UE的RRC CONNECTION REQUEST消息，对于RRC连接建立在DCH或FACH上，是根据当前网络的无线资源状态，系统的负荷情况，以及用户建立该连接的原因等方面综合考虑的。如果RNC接受该RRC连接建立请求，则再判决是将RRC连接建立在专用信道还是公共信道上。对于RRC连接建立使用不同的信道，RRC连接建立流程也不同。1.1.2.1 异常流程1信令连接建立在DCH失败，NodeB无线链路建立失败在为一个用户建立信令连接时，在Uu接口的无线资源分配成功后，首先为该用户需建立一条承载RRC信令的无线链路，但是由于NodeB的原因（硬件原因、协议错误、其他错误），从而导致空中接口的RRC连接无法建立，最终导致信令连接的建立失败。图 1.12 信令连接建立在DCH失败，由于NodeB无线链路建立失败异常流程说明及实体处理方法：（1） 当Node B不能按照要求为该用户建立RL时，向RNC返回RL Setup Failure消息，并包含失败原因。（2） RNC收回内部为该用户分配的无线资源。（3） RNC组织Uu接口标准消息，向该用户发送RRC Connection Reject消息，拒绝用户接入。信令连接建立失败，该过程结束。1.1.2.2 异常流程2信令连接建立在DCH失败，Iub接口AAL2建立失败为一个用户建立信令连接时，在无线资源满足的前提下，成功的为用户建立了无线链路，在建立Iub接口上承载该信令连接的ATM承载时，发生失败（硬件原因、协议错误、其他错误），从而导致空中接口的RRC连接无法建立，最终导致信令连接的建立失败。图 1.13 Iub接口AAL2建立失败异常流程说明及实体处理方法：（1） 信令连接建立过程中，当RNC与Node B之间RL建立成功后，RNC向Node B发送ALCAP的Establish Request消息，发起AAL2连接建立过程，用于在Iub接口承载RRC信令。（2） RNC实体的ALCAP与Node B实体的ALCAP进行协商，Node B实体拒绝建立该接口上的AAL2连接。（3） 收到AAL2建立失败消息后，RNC收回内部为该用户分配的无线资源。（4） RNC与Node B交互，释放该用户的无线链路。（5） RNC组织Uu接口标准消息，向该用户发送RRC Connection Reject消息，拒绝用户接入。（6） 信令连接建立失败，该过程结束。1.1.2.3 异常流程3信令连接建立在DCH失败，网络拒绝RRC连接建立在为一个用户建立信令连接时，在无线资源满足的前提下，成功的为用户建立了无线链路，建立了Iub接口上承载该信令连接的ATM承载，在申请本地业务资源时，由于没有足够的本地资源，或其他原因导致本地分配失败或逻辑连接建立失败，从而导致空中接口的RRC连接无法建立，最终导致信令连接的建立失败。本节中以本地资源分配为例描述该消息流程及相关实体的异常处理。图3.1.6图 1.14 RRC连接建立在DCH上时，RNC本地资源分配失败异常流程说明及实体处理方法：（1） 信令连接建立过程中，当承载信令连接的RL以及AAL2建立成功后，RNC实体内部申请本地业务资源，由于资源不够或其它原因导致本地资源分配失败。（2） RNC收回内部为该用户分配的无线资源。（3） RNC与Node B交互，释放该用户的无线链路。（4） RNC与Node B交互，释放局间AAL2链路。（5） RNC组织Uu接口标准消息，向该用户发送RRC Connection Reject消息，拒绝用户接入。信令连接建立失败，该过程结束。1.1.2.4 异常流程4信令连接建立在FACH失败，网络拒绝RRC连接建立信令连接建立在FACH上时，由于没有足够的本地资源，或其他原因导致本地分配失败或逻辑连接建立失败，从而导致空中接口的RRC连接无法建立，最终导致信令连接的建立失败。图 1.15 RRC连接建立在FACH上时，RNC本地资源分配失败异常流程说明及实体处理方法：（1） 当RNC确定要将该用户的RRC连接建立在公共信道时，为用户分配无线资源后进行本地资源的分配。（2） RNC由于业务负荷或其它逻辑资源不能建立成功等原因本地资源分配失败。（3） RNC收回内部为该用户分配的无线资源。（4） RNC组织Uu接口标准消息，向该用户发送RRC Connection Reject消息，拒绝用户接入。（5） 信令连接建立失败，该过程结束。1.1.2.5 异常流程5Uu接口定时器超时，UE无响应信令连接建立在DCH或FACH两种情况下，各实体针对Uu接口定时器超时的处理方法类似，本流程列举了信令连接建立在DCH时Uu接口定时器超时后各实体的处理方法，RRC连接建立在FACH时处理Uu接口超时更简单一些，不需要处理RL、AAL2资源。在RNC内完成了RRC连接所需要的配置，在给UE发送了相应的配置后，直至定时器超时RNC仍没有收到用户的响应信息（由于移动或无线环境的恶化等），则释放为该用户分配的无线资源，此次信令连接建立失败。 图 1.16 RRC连接建立在DCH上，Uu接口定时器超时，UE无响应异常流程说明及实体处理方法：（1） RNC进行本地资源分配、Iub接口RL建立、在Uu接口向UE发送配置消息的过程参见图 1.11中信令流程说明的（1）（5）。（2） RNC在等待UE的RRC连接建立完成响应时，定时器超时。（3） RNC与Node B执行Iub接口的RL释放过程。（4） RNC与Node B释放Iub接口的AAL2连接。（5） RNC收回内部为该用户分配的无线资源。（6） RNC释放本地资源。（7） 信令连接建立失败，该过程结束。1.1.2.6 异常流程6UE收到无效的配置信息该过程描述的是，在RNC内完成了RRC连接所需要的配置，但是由于UE的原因（协议参数错误，UE的性能不支持等原因），导致信令连接建立失败。图 1.17 RRC连接建立在DCH上，UE收到无效的配置信息异常流程说明及实体处理方法： （1） RNC进行本地资源分配、Iub接口RL建立、在Uu接口向UE发送配置消息的过程参见图 1.11中信令流程说明的（1）（5）。（2） UE由于协议参数错误，UE的性能不支持等原因发起RRC连接的重建。（3） RNC在收到UE的重新建立RRC连接请求时，应对重新建立原因进行分析，以提高系统的处理效率；如果此次重建原因是由于空中接口质量过差，造成UE没有收到刚才网络侧的配置请求，则将配置参数重新传输给UE，以便UE按此要求进行配置；如果此时重新建立RRC连接的原因为CELL_UPDATE，则刚才的配置则全部失效，应在新的小区为该用户建立新的连接，释放原小区的所有资源；如果为UE的性能不支持该配置，则RNC应结合UE的性能信息，释放旧的连接，为该用户重新分配资源，以建立适合该用户的信令连接；当然根据原因的不同，应结合不同的处理，原则是要么拒绝该用户，要么接入该用户，在本节图中仅是给出了一种原因，其他原因的处理流程不在一一列出。（4） RNC与Node B执行Iub接口的RL释放过程。（5） RNC与Node B释放Iub接口的AAL2连接。（6） RNC收回内部为该用户分配的无线资源。（7） RNC释放本地资源。（8） 重新开始RRC连接建立过程。1.1.2.7 异常流程7网络侧无响应该过程描述的是当UE请求建立RRC连接时，由于Uu信号质量、RAN设备异常、逻辑资源分配等原因，导致超时后UE仍没有接收到网络侧的接受或拒绝消息，最终导致信令连接建立失败。此类异常流程及处理对于信令连接建立在DCH或FACH上两种情况都适用。图 1.18 网络侧无响应异常流程说明及实体处理方法： （1） UE向RNC发送RRC_CONNECTION_REQUEST消息，发起该过程；当UE的非接入层请求处于空闲模式下的UE建立一条信令连接,或UE收到寻呼时，要求建立RRC连接,则UE启动该过程。（2） UE等待网络侧的RRC连接建立响应。当定时器T300超时后仍没有收到网络侧接受或拒绝消息，则UE侧判断若发送RRC Connection Request的次数变量V300小于或等于N300次，UE重新组织RRC Connection Request消息并向Uu接口发送，V300+1，重新发起RRC连接建立。（3） 重复前面步骤，若V300大于N300，UE回到空闲模式。（4） 信令连接建立失败，该过程结束。1.1.3 初始直传和鉴权、安全模式子过程1.1.3.1 异常流程1鉴权过程中发生RRC连接失败当网络端发起鉴权请求之后，在收到鉴权响应之前检测到RRC连接失败，此时网络释放所有的MM连接，并且忽略后续的MM过程。1.1.3.2 异常流程2鉴权失败，原因是MAC failure 或GSM authentication unacceptable。当UE收到网络侧发起的“鉴权请求”之后，会进行鉴权计算过程，如果鉴权不通过，则会向网络侧发起“鉴权失败”消息，原因是MAC failure or GSM authentication unacceptable。如下图所示：图 1.19 MAC failure or GSM authentication unacceptable 鉴权失败异常流程说明及实体处理方法：1 UE收到网络侧发起的“鉴权请求”之后，会进行鉴权计算过程，如果鉴权不通过，则会向网络侧发起“鉴权失败”消息，原因是MAC failure or GSM authentication unacceptable。并启动定时器T3214。2 收到UE的“鉴权失败”请求后，网络侧发起“身份认证请求”，要求获得终端的IMSI号，并将鉴权时使用的TMSI与终端的IMSI进行比较。3 网络侧重新发起鉴权请求，重新进行鉴权过程。如果定时器T3214超时后，UE没有收到网络侧发起的鉴权请求或者收到请求中不能获得MAC值，则UE将发起RRC信令连接释放请求。1.1.3.3 异常流程3鉴权失败，原因是“同步失败”当UE收到鉴权请求之后，发现“同步失败”，会响应鉴权失败消息，原因是同步失败。如下图所示：图 1.110 “Synch failure”鉴权失败异常流程说明及实体处理方法：1 当UE检测到同步失败之后，会响应鉴权失败消息，原因是“同步失败”。并且启动定时器T3216。2 网络侧收到UE的失败响应之后，利用消息中的AUTS参数重同步本地的参数值。3 当重同步完成后，网络测重新发起鉴权请求消息，重新进行鉴权过程。4 如果定时器T3214超时后，UE没有收到网络侧发起的鉴权请求，则UE发起RRC连接释放请求以释放存在信令连接。1.1.3.4 安全模式启动过程异常流程在下图的失败情况中，描述的原因仅因为由于UE不支持所配置的加密模式而引起，当然在RNC本地的L2层配置过程中，L2层也可能不支持这种加密模式，导致安全控制模式失败，最终也会导致本次加密失败。由于这两个过程内容差别不大，在本文当中对于这种情况并没有进行穷举，仅通过典型流程来说明这种功能的实现流程。图 1.111 安全模式控制异常流程异常流程说明及实体处理方法：（1） UE收到Security Mode Command消息后，按照消息的内容进行L2层配置的过程中，L2层不支持这种加密和完整性保护模式，导致安全控制模式失败，向RNC响应Security Mode Failure消息。RNC收到UE的安全模式失败消息后，向CN发送Security mode Reject消息，本次安全模式控制失败。1.1.4 呼叫建立子过程1.1.4.1 异常流程1呼叫建立过程失败，原因是呼叫信息无效UE通过SETUP消息发起呼叫建立请求，网络侧收到后，如果发现收到的呼叫信息无效，例如被叫号码无效，网络侧发起呼叫清除过程。如下图所示：图 1.112 被叫号码无效处理过程：1 网络侧收到UE的SETUP消息后，如果发现收到的呼叫信息无效，例如被叫号码无效，则会发起RELEASE消息，其中的原因是unassigned (unallocated) number,no route to destination,number changed,invalid number format (incomplete number).2 UE收到网络侧发起的释放命令后，响应RELEASE COMPLETE消息，并清楚本地的NAS层的连接。1.1.4.2 异常流程2呼叫建立过程失败，原因是业务没授权或无效当终端申请的业务并没有被授权或者申请的业务无效时，网络侧发起呼叫清除过程。如下图所示：图 1.113 所请求的业务没有授权或者业务无效异常流程说明及实体处理方法：1. 网络侧收到UE的SETUP消息后，发现终端申请的业务并没有被授权或者申请的业务无效，则会发起RELEASE消息，其中的原因是operator determined barring,bearer capability not authorized,bearer capability not presently available,service or option not available, unspecified, or bearer service not implemented”.2. UE收到网络侧发起的释放命令后，响应RELEASE COMPLETE消息，并清楚本地的NAS层的连接。1.1.5 RAB建立子过程1.1.5.1 正常流程 图 1.114 RAB建立正常流程1.1.5.2 异常流程1Node B无线链路重配置失败RNC从Iu接口收到RAB建立请求后，需要首先在Iub接口对承载Uu接口用户面的无线链路进行重配置，但是由于NodeB的原因（硬件原因、协议错误、其他错误）RL重配置过程失败，从而导致空中接口的无线承载无法建立，RAB建立失败。 图 1.115 RAB建立在DCH，Node B无线链路重配置失败异常流程说明及实体处理方法：（1） 当Node B不能按照要求为该用户重新配置RL时，向RNC返回RL Reconfiguration Failure消息，并包含失败原因。（2） RNC向CN发送 RAB Assignment Response消息，指示RAB建立失败，并包含失败原因，如UTRAN侧产生原因、无线接口过程失败等。（3） RNC收回内部为该用户分配的无线资源。（4） RNC与UE释放Uu接口RRC连接。（5） 若为CS域RAB，Iu接口需释放AAL2数据传输承载。（6） RAB建立失败，该过程结束。1.1.5.3 异常流程2Iub接口AAL2建立失败RNC从Iu接口收到RAB建立请求后无线资源满足的前提下，在Iub接口成功的为用户重配了无线链路，在建立Iub接口上承载该信令连接的ATM承载时，发生失败（硬件原因、协议错误、其他错误），从而导致空中接口的RB无法建立。图 1.116 RAB建立在DCH，Iub接口AAL2建立失败异常流程说明及实体处理方法：（1） RB建立过程中，当RNC与Node B之间RL建立成功后，RNC向Node B发送ALCAP的Establish Request消息，发起AAL2连接建立过程，用于在Iub接口承载用户信息。（2） RNC实体的ALCAP与Node B实体的ALCAP进行协商，Node B实体拒绝建立该接口上的AAL2连接。（3） 收到AAL2建立失败消息后，RNC收回内部为该用户分配的无线资源。（4） RNC与Node B交互，释放该用户的无线链路。（5） RNC与Node B交互，释放局间AAL2链路。（6） 若无其它用户数据传输，RNC组织Uu接口标准消息，向该用户发送RRC Connection Release消息，释放该用户的RRC连接。（7） RNC向CN发送 RAB Assignment Response消息，指示RAB建立失败，并包含失败原因，如UTRAN侧产生原因、无线接口过程失败等。（8） 若为CS域RAB，Iu接口需释放AAL2数据传输承载。（9） RAB建立失败，该过程结束。1.1.5.4 异常流程3Uu接口RB建立失败RNC向UE发送RB Setup消息发起Uu接口无线承载的建立。由于一些错误原因导致UE向RNC发送RB建立失败的响应。导致UE发送失败响应的原因可能为： UE收到的消息协议错； RB Setup消息中包含无效的配置信息； RB Setup消息中包含UE不支持的配置信息； 配置信息不匹配； UE物理信道配置失败； 重配过程中无线链路失败等。图 1.117 RAB建立在DCH，Uu接口RB建立失败异常流程说明及实体处理方法：（1） 当Iub接口无线链路以及AAL2连接建立完成以后，RNC向UE发送RB Setup消息建立Uu接口无线承载。当上述某项原因出现时，UE向RNC返回无线承载建立失败。（2） RNC收回内部为该用户分配的无线资源。（3） RNC与Node B释放Iub接口的RL。（4） RNC与Node B释放Iub接口的AAL2连接。（5） RNC与UE释放Uu接口RRC连接。（6） RNC向CN发送 RAB Assignment Response消息，指示RAB建立失败，并包含失败原因，如UTRAN侧产生原因、无线接口过程失败等。（7） 若为CS域RAB，Iu接口需释放AAL2数据传输承载。（8） RAB建立失败，该过程结束。1.1.5.5 异常流程3Iu接口RAB建立失败RNC收到RAB指派请求后，向CN响应RAB指派失败消息。可能的原因为： Iu接口本地资源分配失败； Iu接口用户面配置失败； Iu接口AAL2建立失败；图 1.118 RAB建立在DCH，Iu接口RAB建立失败异常流程说明及实体处理方法：当RNC由于上述原因响应RAB指派失败，则分别进行本地相关资源的释放，不再分别描述。1.1.6 振铃接听子过程1.1.6.1 异常流程1终端没有收到ALERTING消息。当终端收到Call Progress之后，启动定时器T310，如果被叫侧的业务建立失败，当T310超时后，UE没有收到网络侧的ALERTING消息，则发起NAS层的释放过程，释放过程如图。图 1.119 UE没有收到ALERTING消息1.1.6.2 异常流程2网络侧没有收到UE的CONNECT ACKNOWLEDGE消息。当定时器超时，网络侧没有收到UE的CONNECT ACK消息，网络侧发起释放过程，如图所示。图 1.120 终端没有响应CONNECT ACK消息1.2 GPRS附着1.2.1 GPRS附着正常流程GPRS附着正常过程如下图所示，对于过程的详细解释请参见RAN高层信令过程学员手册，这里不再赘述。图 1.21 GPRS附着正常流程图1.2.2 GPRS附着异常流程1.2.2.1 异常流程1由于接入等级控制，小区禁止接入，如果小区由于接入等级控制，终端申请的GPRS业务被禁止接入，此时终端不会发起GPRS附着请求。1.2.2.2 异常流程3ATTACH ACCEPT收到之前，T3310超时 当UE发起ATTACH REQUEST之后，启动定时器T3310，如果ATTACH ACCEPT收到之前，T3310超时，UE重新启动T3310，并重发ATTACH REQUEST消息。重传四次后，T3310依然超时，UE将发起PS Signalling Connection Release。图 1.22 T3310超时，UE重新发起附着请求1.2.2.3 异常流程4GPRS附着过程中，同一RA中的小区发生改变在UE发起GPRS附着过程中，经常会出现正在跨越小区的情况，并且这两个小区属于相同的RA如果。在GPRS附着过程中，同一个RA中发生小区改变，此时应先进行完小区更新过程，再继续GPRS附着过程。图 1.23 跨越小区的GPRS过程1.2.2.4 异常流程5GPRS附着过程中，不同的RA中的小区发生改变在UE发起GPRS附着过程中，经常会出现正在跨越小区的情况，并且这两个小区属于不同的RA。此种情况下，对于终端侧而言，应分GPRS附着的进行情况分别对待。A）、如果ATTACH ACCEPT收到之前，UE正在跨越小区，此时应该停止正在进行的附着过程，小区更新后立即重新发起附着请求。图 1.24 跨越路由区的GPRS附着过程1B）、如果ATTACH ACCEPT已经收到，但是ATTACH COMPLETE消息还没有发送，此时应该停止附着过程，进行路由区更新过程。如果附着过程种重新分配了P-TMSI和P-TMSI签名，则P-TMSI和P-TMSI签名应应用在路由区更新过程中。图 1.25跨越路由区的GPRS附着过程21.2.2.5 异常流程6GPRS附着过程中，UE发起DETACH请求。当UE还处在GMM的注册状态，此时UE又发起了DETACH请求，UE应该停止附着过程，进行DETACH过程。1.2.2.6 异常流程7ATTACH REQUEST消息中携带协议错误，网络侧返回ATTACH REJECT消息如果UE发起的ATTACH REQUEST消息中携带有协议错误，网络将返回ATTACH REJECT消息，原因可以为：Mandatory information element error; Information element non-existent or not implemented;Conditional IE error; Protocol error, unspecified。终端收到ATTACH REJECT之后，将发起PS signaling connection release消息请求信令连接释放。图 1.26 ATTACH REQUEST消息中携带协议错误1.2.2.7 异常流程8ATTACH COMPLETE消息收到之前，定时器T3350超时当网络测收到UE发起的ATTACH REQUEST消息之后，会响应ATTACH ACCEPT消息。如果ATTACH ACCEPT消息中给UE重新分配了P-TMSI，则网络侧启动定时器T3350。如果T3350超时，网络侧未收到UE响应的ATTACH COMPLETE消息，网络侧将重新发送ATTACH ACCEPT，如此重复响应4次，如果一直未响应ATTACH COMPLETE消息，将停止附着过程。新旧P-TMSI和P-TMSI签名网络侧均认为是有效性。图 1.27 ATTACH COMPLETE消息收到之前，定时器T3350超时1.2.2.8 异常流程9网络侧收到多条ATTACH REQUEST消息。当附着进行过程中，网络侧收到UE发起的多条ATTACH REQUEST消息，此时网络应该停止前面的附着过程，根据最新的请求消息触发新的附着过程。图 1.28网络侧收到多条ATTACH REQUEST消息1.3 GPRS去附着1.3.1 GPRS去附着正常流程当UE与网络侧发生GPRS分离时，UE发起GPRS去附着过程；或者当UE关机时，将发起去附着过程，如图所示：图 1.31 UE发起的去附着过程1.3.2 GPRS去附着异常流程1.3.2.1 异常流程1UE收到DETACH ACCEPT消息之前定时器超时当UE发起DETACH REQUEST消息之后，启动定时器T3321。如果在收到网络侧响应的DETACH ACCEPT消息之前，T3321超时，UE将重新发起去附着请求，如此进行4次，如果一直未得到网络侧的响应，去附着过程将被停止，UE进入NULL状态。图 1.32 UE重新发起去附着请求1.3.2.2 异常流程2去附着和其他的GMM过程冲突 当UE在进行去附着的过程中，又发生了其他GMM过程。如果其他GMM过程是鉴权过程，则先进行完鉴权过程再继续进行去附着过程；如果其他过程是“power off”， “P-TMSI REALLOCATION COMMAND”,“GMM STATUS,” or “ GMM INFORMATION message”，则这些过程将被忽略，继续进行去附着过程。1.3.2.3 异常流程3GPRS去附着过程中，同一RA中的小区发生改变在UE发起GPRS去附着过程中，经常会出现正在跨越小区的情况，并且这两个小区属于相同的RA。在GPRS去附着过程中，同一个RA中发生小区改变，此时应先进行完小区更新过程，再继续GPRS去附着过程。1.3.2.4 异常流程4GPRS去附着过程中，不同的RA中的小区发生改变在UE发起GPRS去附着过程中，经常会出现正在跨越小区的情况，并且这两个小区属于不同的RA。如果DETACH ACCEPT收到之前，UE正在跨越小区，此时应该停止正在进行的去附着过程，小区重选后立即重新发起去附着请求。图 1.33 GPRS去附着过程中，发生路由区更新过程1.4 PDP Context激活过程1.4.1 PDP激活正常过程对一个UE发起的PDP上下文激活过程来说，如果之前UE没有建立RRC连接则先建立RRC连接，再通过初始直传建立传输NAS消息的信令连接，最后建立RAB。图 1.41 UE发起的PDP激活请求图 1.42 网络侧发起的PDP激活请求1.4.2 PDP激活异常流程1.4.2.1 异常流程1UE收倒PDP激活接收之前，定时器T3380超时当UE发起PDP业务激活请求后，启动定时器T3380。但是由于各种原因（例如用户请求的业务不支持，或者网络发生异常），在定时器T3380超时之前，没有收到网络响应的PDP激活接收消息。此时UE重新发起PDP激活请求，最多可重发4次。如果UE一直未得到网络侧响应，则UE释放为本次激活所分配的所有资源。图 1.43 定时器超时1.4.2.2 异常流程2UE发起的PDP业务请求与网络侧已存在的PDP业务冲突如果网络侧收到UE发起的PDP激活请求，但是此UE请求业务的APN, PDP 类型and PDP address 在网络侧已经存在或者业务的NSAPI与已激活的PDP相同。此时网络侧将本地释放已经存在的PDP连接，不通知UE，继续受理UE发起的PDP激活请求业务。图 1.44 UE发起的PDP业务请求与网络侧已存在的PDP业务冲突1.4.2.3 异常流程3网络侧发起的PDP业务请求与UE已存在的PDP业务冲突如果UE收到网络侧发起的REQUEST PDP CONTEXT ACTIVATION，但是此业务的APN, PDP 类型and PDP address 在UE侧已经存在。此时UE将本地释放已经存在的PDP连接，不通知网络侧，继续受理网络侧发起的REQUEST PDP CONTEXT ACTIVATION。图 1.45网络侧发起的PDP业务请求与UE已存在的PDP业务冲突1.5 PDP Context去激活过程1.5.1 PDP Context去激活正常过程图 1.51 UE发起的PDP去激活正常过程图 1.52 网络侧发起的PDP去激活正常过程1.5.2 PDP Context去激活异常流程1.5.2.1 异常流程1PDP去激活的过程中定时器超时网络侧/UE侧发起PDP去激活请求，如果在定时器超时前，没有得到对方的响应，此时网络侧/UE侧重新发起PDP去激活请求，重新发起的最大次数为4次，如果一直未得到对方的响应，则各自释放与PDP业务相关的资源，释放PDP业务相关的数据。图 1.53 PDP去激活的过程中定时器超时1.5.2.2 异常流程2UE和网络侧发起的PDP去激活请求冲突如果UE和网络侧同时发起PDP去激活请求，此时UE和网络侧分别响应对方DEACTIVATE PDP CONTEXT ACCEPT消息。图 1.54 UE和网络侧发起的PDP去激活请求冲突2 移动性管理过程2.1 位置区更新位置更新包括正常位置更新，周期性位置更新，IMSI Attach。这三类更新的触发条件是不同的。IMSI attach过程一般发生在开机或重新返回信号覆盖区或SIM卡被重新插入，同时需要满足以下条件：1) 在RRC接收到的NAS系统消息中，ATT标志指示需要IMSI Attach过程；2) 更新状态是“UPDATED”；3) 驻留的LAI与USIM中保存的LAI相同；在其它所有需要做位置更新的情况下，除了因为周期位置更新定时器T3212超时，同时MM更新状态为“UPDATED”时进行周期位置更新外，其它都是进行正常位置更新。2.1.1 位置区更新正常过程图 2.11 位置区更新正常过程2.1.2 位置区更新异常流程2.1.2.1 异常流程1由于接入等级控制，小区禁止接入，如果UE在一个非注册网络（并没有在此小区注册），此时此小区禁止此用户接入。或者UE的接入等级被限制。此时UE不会发起位置区更新请求。2.1.2.2 异常流程2UE发起的LOCATION UPDATING REQUEST消息中协议错误。如果UE发起的LOCATION UPDATING REQUEST消息中存在协议错误，网络侧将回复终端LOCATION UPDATING REJECT消息。原因可以分别为： Mandatory information element error，Information element non-existent or not implemented，Conditional IE error，Protocol error, unspecified。之后网络侧发起释放过程。图 2.12 由于协议错误的位置区更新拒绝流程2.1.2.3 异常流程3网络侧响应UE LOCATION UPDATING REJECT消息当网络侧收到UE发起的LOCATION UPDATING REQUEST之后，返回UELOCATION UPDATING REJECT消息，根据消息中携带的拒绝原因不同，UE的处理策略也不同：IMSI在HLR处未知、违法的MS、违法的ME。此时UE将更新状态设置为ROAMING NOT ALLOWED，删除TMSI、存储的LAI和密钥序列码，并认为SIM无效。PLMN未允许。UE将更新状态设置为ROAMING NOT ALLOWED，删除TMSI、存储的LAI和密钥序列码，并将此PLMN id存储在forbidden PLMN list中。位置区未允许：UE将更新状态设置为ROAMING NOT ALLOWED，删除TMSI、存储的LAI和密钥序列码，并将此PLMN id存储在forbidden location areas for regional provision of service中。当UE回到MM IDLE状态时进行小区选择。位置区未允许漫游：UE将LAI存储在forbidden location areas for roaming中，当UE回到MM IDLE状态时进行PLMM选择而不是小区选择。位置区中没有合适的小区。UE将LAI存储在forbidden location areas for roaming中，并且在同一个PLMN的不同LA中重新选择小区。图 2.13 位置区更新拒绝流程2.2 路由区更新2.2.1 路由区更新正常过程图 2.21 路由区更新正常流程2.2.2 路由区更新异常流程2.2.2.1 异常流程1由于接入等级控制，小区禁止接入，如果UE所在的小区接入等级控制，此UE禁止进行路由区更新过程。此时UE不会发起路由区更新请求。2.2.2.2 异常流程2UE收到ROUTING AREA UPDATE ACCEPT之前，低层发生失败或者定时器超时。如果在进行路由区更新的过程中，UE侧低层发生失败（例如RRC层，RLC层，PHY层等）或者定时器超时，此次路由区更新过程将中止，UE重新发起路由区更新请求，重发的最大次数为4次。如果重传次数大于4次，仍未成功，UE将发起PS signaling connection release消息。图 2.22低层发生失败或者定时器超时2.2.2.3 异常流程3路由区更新和GPRS去附着过程冲突在终端移动的过程中，经常出现路由区更新和GPRS去附着冲突的情况。这种情况又可分为两种情况进行考虑。如果GPRS DETACH REQUEST消息的类型为re-attach required或者 re-attach not required，则中止路由区更新过程，继续去附着过程。图 2.23路由区更新和GPRS去附着过程冲突1如果GPRS DETACH REQUEST消息的类型为IMSI detach，则继续进行路由区更新过程，忽略GPRS去附着过程。图 2.24路由区更新和GPRS去附着过程冲突22.2.2.4 异常流程4路由区更新和P-TMSI重分配过程冲突如果UE在进行路由区更新过程中收到P-TMSI重分配命令，此时UE忽略P-TMSI重分配命令，继续进行路由区更新过程。图 2.25路由区更新和P-TMSI重分配过程冲突2.2.2.5 异常流程5网络侧收到ROUTING AREA UPDATE COMPLETE之前，低层失败如果由于低层发生失败，网络侧未收到UE响应的ROUTING AREA UPDATE COMPLETE消息。此时网络侧则认为新分配和原先的P-TMSI和P-TMSI签名均有效。2.3 小区/URA更新2.3.1 小区更新过程(1) 通知UTRAN，处于CELL_PCH或CELL_FACH状态的UE重新进入了服务区；(2) 通知UTRAN，UE的AM RLC实体发生了不可恢复的RLC错误；(3) 周期性小区更新可作为CELL_PCH或CELL_FACH状态下的UE监管机制；(4) 通知UTRAN，处于CELL_PCH或CELL_FACH状态下的UE发生小区重选后所在的小区；(5) 用于处于CELL_DCH状态下的UE发生无线链路故障时的处理；(6) 用于UE 发送UE CAPABILITY INFORMATION消息失败时的处理；(7) 通知UTRAN，处于CELL_PCH状态下的UE收到寻呼或需要发送上行数据，需要将其状态转移到CELL_FACH状态；URA更新过程的主要功能如下：(1) 周期性URA更新可作为URA_PCH状态下的UE监管机制；(2) 用于UE重选到非当前URA的小区时，更新获取新的URA 标识号。2.3.1.1 小区更新正常流程1. 小区更新过程中网络侧要求UE进行无线承载释放。图 3.3.17 小区更新，网络侧要求UE释放无线承载2. 小区更新过程中网络侧要求UE进行无线承载重配置。图 3.3.18 小区更新，网络侧要求UE进行无线承载重配置3. 小区更新过程中网络侧要求UE进行传输信道重配置。图 3.3.19 小区更新，网络侧要求UE进行传输信道重配置4. 小区更新过程中网络侧要求UE进行物理信道重配置。图 3.3.20 小区更新，网络侧要求UE进行物理信道重配置5. 小区更新过程中网络侧的响应消息中包含UTRAN移动性信息。图 3.3.21 小区更新，网络侧要求UE进行传输UTRAN移动性信息6. 小区更新过程基本流程，网络侧除确认小区更新外不包含任何附加信息。图 3.3.22 小区更新基本过程2.3.1.2 小区更新异常流程1图3.3.23 小区更新异常，网络侧释放RRC连接异常流程说明及实体处理方法：（1） 当UE的AM RLC实体发生了不可恢复的RLC错误而发起小区更新时，RNC向UE发送RRC Connection Release消息发起RRC连接释放。2.3.1.3 小区更新异常流程2UE收到的CELL UPDATE CONFIRM消息，若UE未能成功地完成CELL UPDATE CONFIRM消息中所指示的物理信道的建立，或者若UE不支持消息CELL UPDATE CONFIRM中的配置，或者无效配置，或者不兼容的同时重配置等，此时如果V302N302,UE将进入空闲状态。图 2.31 小区更新异常流程2.3.2 URA更新过程2.3.2.1 URA更新正常流程1. URA更新过程中网络侧的响应消息中包含UTRAN移动性信息。图 2.32 URA更新，网络侧要求UE进行传输UTRAN移动性信息2. URA更新过程基本流程，网络侧除确认小区更新外不包含任何附加信息。图 2.33 URA更新基本过程2.3.2.2 URA更新异常流程1图 2.34 URA更新异常，网络侧要求释放RRC连接异常流程说明及实体处理方法：当UE的AM RLC实体发生了不可恢复的RLC错误而发起URA更新时，RNC向UE发送RRC Connection Release消息发起RRC连接释放。2.4 切换过程切换过程是移动通信区别于固定通信的一个显著特征之一，在如今的蜂窝结构的无线移动通信系统中，当正在使用网络服务的用户从一个小区移动到另外一个小区的过程中，为了保证通信的连续性，用户与原小区的通信链路要转移到新的小区或因为一些别的原因（网络负载和操作维护等）也会触发切换流程。TD-SCDMA支持的切换类型包括硬切换，接力切换两种。 硬切换概述与别的系统中的硬切换流程相比，TD-SCDMA系统中的硬切换同样采用了“先断后接”的流程。“断”指断开与原基站的专用信道的连接；“接”指建立与目标基站的专用信道的连接。在TD-SCDMA系统中，由于UE能够预先同目标小区建立同步，切换过程所用的时间将会大大减少，从而能够降低由切换引起的掉话率。 接力切换概述接力切换(Baton Handover)是TD-SCDMA移动通信系统的核心技术之一。其设计思想是利用TDD系统特点和上行同步技术，在切换测量期间，利用开环技术进行并保持上行预同步，即UE可提前获取切换后的上行信道发送时间、功率信息；在切换期间，可以不中断业务数据的传输，从而达到减少切换时间，提高切换的成功率、降低切换掉话率的目的。2.4.1 Intra-Node B切换Intra-Node B切换发生在同一Node B配置N（N1）扇区的情况。2.4.1.1 硬切换正常流程图 2.41 Intra-Node