非常实用
在WCDMA系统中具有的各种各样的信令流程中，从协议栈的层面来说，可以分为接入层的信 令流程和非接入层的信令流程；从网络构成的层面来说，可以分为电路域的信令流程和分
组域的信令流程。
所谓接入层的流程和非接入层的流程，实际是从协议栈的角度出发的。在协议栈中，RRC和
RANAP层及其以下的协议层称为接入层，它们之上的MM、SM、CC、SMS等称为非接入层。简 单地说，接入层的流程，也就是指无线接入层的设备RNC、NodeB需要参与处理的流程。非
接入层的流程，就是指只有UE和CN需要处理的信令流程，无线接入网络RNC、NodeB是不需 要处理的。举个形象的比喻，接入层的信令是为非接入层的信令交互铺路搭桥的。通过接
入层的信令交互，在UE和CN之间建立起了信令通路，从而便能进行非接入层信令流程了。
接入层的流程主要包括PLMN选择、小区选择和无线资源管理流程。无线资源管理流程就是
RRC层面的流程，包括RRC连接建立流程、UE和CN之间的信令建立流程、RAB建立流程、呼叫 释放流程、切换流程和SRNS重定位流程。其中切换和SRNS重定位含有跨RNC、跨SGSN/MSC的 情况，此时还需要SGSN/MSC协助完成。所以从协议栈的层面上来说，接入层的流程都是一
些底层的流程，通过它们，为上层的信令流程搭建底层的承载。
非接入层的流程主要包括电路域的移动性管理，电路域的呼叫控制，分组域的移动性管理
、分组域的会话管理。
6.1.2 基本信令流程总体介绍
接下来我们对基本的信令流程进行简单的总体介绍。
我们首先看一下用户在不移动的情况下，从开机、进行业务到关机的整个业务流程。
图6-1 主叫业务流程
(1) 用户UE开机，首先进行接入层的信令交互。此时首先进行PLMN选择，选择某个运营商 的网络，接着进行小区选择，驻留一个合适的小区，然后进行RRC连接建立，Iu接口的信令
连接建立。至此，通过这些接入层的信令流程，在UE和CN之间搭建起了一条信令通道，为
非接入层的信令流程做好了准备。
(2) 接着UE和CN之间便开始进行非接入层的移动性管理流程了。此时用户会进行附着流程
，其中包括鉴权、加密、位置更新等小流程。
(3) 当通过鉴权等流程后，UE便进行非接入层的业务相关流程了。包括电路域的呼叫连接
流程，分组域的会话管理流程。通过这些流程为进行业务搭建好了业务承载的链路。随后
用户就可以开始打电话，上网了。
(4) 当用户结束业务后，同样会进行电路域的呼叫连接流程，分组域的会话管理流程，拆
除业务承载链路。
(5) 此时如果用户关机的话，则UE和CN之间进行非接入层的移动性管理流程，进行电路域
、分组域的分离。
(6) 等非接入层的信令交互结束后，系统会进行接入层的信令流程，拆除之前建立的Iu信
令连接，以及RRC信令连接。
至此，一个用户在不移动的情况下，从开机，进行业务，到关机的整个流程便结束了。其
中可以看到，这个业务过程是需要接入层的信令流程和非接入层的信令流程互相配合完成
的。接入层的流程为非接入层的流程搭建信号承载。
接下来我们再看一下用户进行被叫的一个业务流程。
(1) 用户UE处在待机状态。此时从网络侧对其进行寻呼；
(2) 如果没有现存的UE与CN之间的信令连接，则UE、RNC、CN之间会进行接入层的信令流 程，建立RRC连接和Iu接口信令连接；
(3) 接下来可能会进行移动性管理的鉴权加密流程；
(4) 随后通过电路域的呼叫连接流程、分组域的会话管理流程，建立其业务的承载链路，
从而就可以进行业务了。
(5) 结束业务后，再拆除相关的业务承载链路。
(6) 接着释放接入层的信令连接，包括Iu接口的信令连接和RRC连接。
上面的两个流程主要从总体上介绍了用户在不产生位置变化的情况下进行业务的情况。这
只是一个总体上的简单描述。详细的各种流程将在后续章节中进行描述。
由于移动通信具有移动性的特点，所以由此就产生了很多处理移动性相关的流程。比如，
当用户不进行业务的时候产生了位置改变，由此便产生了位置更新等移动性管理的流程；
当用户进行业务的时候发生了位置变化，由此便产生了切换、SRNS重定位等流程。
6.2 UE的状态与寻呼流程
6.2.1 UE状态
UE有两种基本的运行模式：空闲模式和连接模式。上电开始，UE就停留在空闲模式下，通
过非接入层标识如IMSI、TMSI或P-TMSI等标志来区分。UTRAN不保存空闲模式UE的信息，仅 能够寻呼一个小区中的所有UE或同一个寻呼时刻的所有UE。
当UE完成RRC连接建立时，UE才从空闲模式转移到连接模式：CELL_FACH或CELL_DCH状态。 UE的连接模式，也叫UE的RRC状态，反映了UE连接的级别以及UE可以使用哪一种传输信道。 当RRC连接释放时，UE从连接模式转移到空闲模式。
图6-3 UE运行模式
UE在连接模式下，一共有如下4种状态：
1. CELL_DCH状态
CELL_DCH状态有如下特征：
* 在上行和下行给UE分配了一个专用物理信道
* 根据UE当前的活动集可以知道UE所在的小区
* UE可以使用专用传输信道、下行/上行共享传输信道或这些传输信道的组合
UE进入CELL_DCH状态有如下2种方法：
1） UE在空闲模式下，RRC连接建立在专用行道上，因此UE从空闲模式进入CELL_DCH状态；
2） UE处于CELL_FACH状态下使用公共传输信道，通过信道切换后使用专用传输信道，UE从 CELL_FACH状态进入到CELL_DCH状态。
2. CELL_FACH状态
CELL_FACH状态具有如下特征：
* 没有给UE分配专用传输信道
* UE连续监听一个下行FACH信道
* 为UE分配了一个默认的上行公共信道或上行共享传输信道（例如，RACH），使之能够在
接入过程中的任何时间内使用
* UE的位置在小区级为UTRAN所知，具体为UE最近一次发起小区更新时报告的小区
在CELL_FACH子状态，UE执行下面的动作：
监听一个FACH
* 监听当前服务小区的BCH传输信道，解码系统信息消息
* 在小区变为另一个UTRA小区时，发起一个小区更新过程
* 除非选择了一个新小区，否则使用在当前小区中分配的C-RNTI作为公共传输信道上的UE
标识
* 在RACH上传送上行控制信令和小数据包
在CELL_FACH状态下，如果数据业务在一段时间里未被激活，UE将进入CELL_PCH状态，以减 少功率的损耗。并且，当UE暂时脱离CELL_PCH状态执行小区更新，更新完成后，如果UE和 网络侧均无数据传输需求，它将返回CELL_PCH。
3. CELL_PCH 状态
CELL_PCH状态具有如下特征：
* 没有为UE分配专用信道
* UE使用非连续接收（DRX）技术，在某个特定的寻呼时刻监听PCH传输信道上的信息
* 不能有任何上行的活动
UE的位置在小区级为UTRAN所知，具体为UE在CELL_FACH状态时最近一次发起小区更新时所 报告的小区
在CELL_PCH状态，UE进行以下活动：
根据DRX 周期监听寻呼时刻，并接收PCH上的寻呼消息
监听当前服务小区的BCH传输信道，以解码系统信息
当小区改变时发起小区更新过程
在该状态下不能使用DCCH逻辑信道。如果网络试图发起任何活动，它需要在UE所在小区的
PCCH逻辑信道上发送一个寻呼请求。
UE转换到CELL_FACH状态的方式有两个，一是通过UTRAN寻呼，二是通过任何上行接入。
4. URA_PCH状态
URA_PCH状态具有如下特征：
* 没有为UE分配专用信道
* UE使用DRX技术，在某个特定的寻呼时刻监听PCH传输信道上的信息
* 不能有任何上行的活动
* UE的位置在URA级为UTRAN所知，具体为UE在CELL_FACH状态时最近一次发起URA更新时所 报告的URA
在URA_PCH状态，UE进行以下活动：
* 根据DRX周期监听寻呼时刻，并接收PCH上的寻呼消息
* 监听当前服务小区的BCH传输信道，以解码系统信息
* 当URA改变时发起URA更新过程
在该状态下不能使用DCCH逻辑信道。如果网络试图发起任何活动，它需要在UE所在URA的P CCH逻辑信道上发送寻呼请求。
在URA_PCH状态， 没有资源分配给数据传输用。因此，如果UE有数据要传送，需要首先转 换到CELL_FACH状态。
6.2.2 寻呼流程
与固定通信不同，移动通信中的通信终端的位置不是固定的，为了建立一次呼叫，核心网
（CN）通过Iu接口向UTRAN发送寻呼消息，UTRAN则将CN寻呼消息通过Uu接口上的寻呼过程 发送给UE，使得被寻呼的UE发起与CN的信令连接建立过程。
当UTRAN收到某个CN域（CS域或PS域）的寻呼消息时，首先需要判断UE是否已经与另一个C
N域建立了信令连接。如果没有建立信令连接，那么UTRAN只能知道UE当前所在的服务区， 并通过寻呼控制信道将寻呼消息发送给UE，这就是PAGING TYPE 1消息；如果已经建立信令
连接，在CELL_DCH或CELL_FACH状态下，UTRAN就可以知道UE当前活动于哪种信道上，并通 过专用控制信道将寻呼消息发送给UE，这就是PAGING TYPE 2消息。因此针对UE所处的模式 和状态，寻呼可以分为以下两种类型：
(1) 寻呼空闲模式或PCH状态下的UE
这一类型的寻呼过程使用PCCH（寻呼控制信道）寻呼处于空闲模式、CELL_PCH或URA_PCH状 态的UE，用于向被选择的UE发送寻呼信息，其作用有如下三点：
* 为了建立一次呼叫或一条信令连接，网络侧的高层发起寻呼过程；
* 为了将UE的状态从CELL_PCH或URA_PCH状态迁移到CELL_FACH状态，UTRAN发起寻呼以触发
UE状态的迁移；
* 当系统消息发生改变时，UTRAN发起空闲模式、CELL_PCH和URA_PCH状态下的寻呼，以触 发UE读取更新后的系统信息。
图6-4 寻呼空闲模式和PCH状态下的UE
UTRAN通过在PCCH上一个适当的寻呼时刻发送一条PAGING TYPE 1消息来启动寻呼过程，该 寻呼时刻和UE的IMSI有关。UTRAN可以选择在几个寻呼时机重复寻呼一个UE，以增加UE正确 接收寻呼消息的可能。
(2) 寻呼CELL_DCH或CELL_FACH状态下的UE
这一类型的寻呼过程用于向处于连接模式CELL_DCH或CELL_FACH状态的某个UE发送专用寻呼 信息。
图6-5 寻呼CELL_DCH或CELL_FACH状态下的UE
对于处于连接模式CELL_DCH或CELL_FACH状态的UE，UTRAN通过在DCCH（专用控制信道）上 发送一条PAGING TYPE 2消息来发起寻呼过程。这种寻呼也叫做专用寻呼过程。
6.3 空闲模式下的UE
6.3.1 概述
当UE开机后或在漫游中，它的首要任务就是找到网络并和网络取得联系。只有这样，才能
获得网络的服务。因此，空闲模式下UE的行为对于UE是至关重要的。那么，UE是如何完成 这个功能的呢？本节就来讲解这个过程。
UE在空闲模式下的行为可以细分为PLMN选择和重选，小区的选择和重选和位置登记。这三
个过程之间的关系如下图所示。
图6-6 空闲模式下的UE
当UE开机后，首先应该选择一个PLMN。当选中了一个PLMN后，就开始选择属于这个PLMN的 小区。当找到这样的一个小区后，从系统信息（广播）中就可以知道临近小区（neighbor
ing cell）的信息，这样，UE就可以在所有这些小区中选择一个信号最好的小区，驻留下
来。紧接着，UE就会发起位置登记过程（attach or location update）。成功后，UE就驻
留在这个小区中了。驻留的作用有4个：
* 使UE可以接收PLMN广播的系统信息。
* 可以在小区内发起随机接入过程。
* 可以接收网络的寻呼。
* 可以接收小区广播业务。
当UE驻留在小区中，并登记成功后，随着UE的移动，当前小区和临近小区的信号强度都在
不断变化。UE就要选择一个最合适的小区，这就是小区重选过程。这个最合适的小区不一
定是当前信号最好的小区，为什么呢？因为，比如UE处在一个小区的边缘，又在这两个小
区之间来回走，恰好这两个小区又是属于不同的LA或者RA。这样，UE就要不停的发起位置
更新，即浪费了网络资源，又浪费的UE的能量。因此，在所有小区中重选哪个小区是有一
定规则的，这个规则会在后面详细描述。
当UE重选小区，选择了另外一个小区后，发现这个小区属于另外一个LA 或者RA，UE就要发 起位置更新过程，使网络获得最新的UE的位置信息。UE通过系统广播信息中的SIB1发现 L A或者RA的变化。
如果位置登记或者更新不成功，比如当网络拒绝UE时。或者当前的PLMN出了覆盖区，UE可 以进行PLMN重选，以选择另外一个可用的PLMN。
6.3.2 PLMN选择和重选
PLMN选择和重选的目的是选择一个可用的（就是能提供正常业务的），最好的PLMN。UE通
过什么来达到这一目的呢？UE会维护一个PLMN列表，这些列表将PLMN按照优先级排列，然 后从高优先级向下搜索，找到的自然是最高优先级的PLMN。另外，PLMN选择和重选的模式
有两种，自动和手动。简而言之，自动选网就是UE按照PLMN的优先级顺序自动的选择一个
PLMN，手动选网呢，将当前的所有可用网络呈现给用户，将权利给用户， 由用户选择一个
PLMN。
6.3.3 小区选择和重选
当PLMN选定之后，就要进行小区选择，目的是选择一个属于这个PLMN的信号最好的小区。
首先，如果UE存有这个PLMN的一些相关信息，比如频率，扰码等。UE就会首先使用这些信 息进行小区搜索（Stored information cell selection）。这样就可以较快的找到网络。
因为，大多数情况，UE都是在同一个地点关机和开机，比如晚上关机，早晨开机等等。这
些信息保存在SIM卡中或者在手机的non-volatile memory中。
1. 小区选择
小区选择的过程大致如下：
1） 小区搜索
小区搜索的目的是找到一个小区，尽管它可能不属于选择的PLMN的。小区搜索的步骤如下
（当然，首先要锁定一个频率）：
通过primary SCH，UE获得时隙同步。时隙同步后，就要进行帧同步。帧同步是使用seco
ndary SCH的同步码实现的。这一过程同时也确定了这个小区的扰码组。然后， UE通过对
扰码组中的每一个扰码在CPICH上相关，直到找到相关结果最大的一个。这就确定了主扰码
。
显然，如果UE已经知道这个小区的一些信息，比如使用哪个频率，甚至主扰码，上述步骤
就可以大大加速。
2） 读广播信道
UE从上述1）的步骤c中获得了PCCPCH的扰码，而PCCPCH的信道码是已知的，在整个UTRAN中 是唯一的。UE就可以读广播信道的信息了。
* 读到MIB后，UE就可以判断当前找到的PLMN是否就是要找的PLMN，因为在MIB中有PLMN i dentity域，如果是， UE就根据MIB中包含的其他SIB的调度信息（scheduling informati on），找到其他的SIB并获得其内容。如果不是，UE只好再找下一个频率，又要从头开始这
个过程（从小区搜索开始）。
* 如果当前PLMN是UE要找的PLMN，UE读SIB3，取得“Cell selection and re-selection
info”，通过获取这些信息，UE计算是否满足小区驻留标准。如果满足，则UE认为此小区
即为一个suitable cell。驻留下来，并读其他所需要的系统信息，随后UE将发起位置登记
过程。
如果不满足上述条件，UE读SIB11，获取临区消息，这样UE就可以算出并判断临区是否满足 小区选择驻留标准。
如果UE发现了任何一个临区满足小区驻留标准，UE就驻留在此小区中，并读其他所需要的
系统信息，随后UE将发起位置登记过程。
如果UE发现没有一个小区满足小区驻留标准。UE就认为没有覆盖，就会继续PLMN选择和重 选过程。
2. 小区重选
UE在空闲模式下，要随时监测当前小区和临区的信号质量，以选择一个最好的小区提供服
务。这就是小区重选过程（cell reselection）。如果在Treselection时间内，小区重选
条件得到满足，UE就选择这个小区， 驻留下来，读它的广播消息。 小区重选结束。
3. 离开连接模式的小区选择
当UE从连接模式回到空闲模式时，要做小区选择，以找一个合适的小区（suitable cell）
。这个选择过程和普通的小区选择过程是一样的。不过此时候选小区就是连接模式时用到
的小区。如果在这些小区中找不到合适的小区，应该使用stored information cell sele
ction。
6.3.4 位置登记
这些过程请参见MM，GMM的过程。
6.4 无线资源管理流程
6.4.1 RRC连接建立流程
UE处于空闲模式下，当UE的非接入层请求建立信令连接时，UE将发起RRC连接建立过程。每 个UE最多只有一个RRC连接。
当SRNC接收到UE的RRC CONNECTION REQUEST消息，由其无线资源管理模块（RRM）根据特 定的算法确定是接受还是拒绝该RRC连接建立请求，如果接受，则再判决是建立在专用信道
还是公共信道。对于RRC连接建立使用不同的信道，则RRC连接建立流程也不一样。
1. RRC连接建立在专用信道上
图6-7 RRC连接建立在专用信道上
信令流程说明：
1）UE在上行CCCH上发送一个RRC Connection Request消息，请求建立一条RRC连接；
2）SRNC根据RRC连接请求的原因以及系统资源状态，决定UE建立在专用信道上，并分配RN TI和L1、L2资源；
3）SRNC向Node B发送Radio Link Setup Request消息，请求Node B分配RRC连接所需的特 定无线链路资源；
4）Node B资源准备成功后，向SRNC应答Radio Link Setup Response消息；
5）SRNC使用ALCAP协议发起Iub接口用户面传输承载的建立，并完成RNC于Node B之间的同 步过程；
6）SRNC在下行CCCH向UE发送RRC Connection Setup消息；
7）UE 在上行DCCH向SRNC发送RRC Connection Setup Complete消息。
至此，RRC连接建立过程结束。
2. RRC连接建立在公共信道上
当RRC连接建立在公共信道上时，因为用的是已经建立好的小区公共资源，所以这里无需建
立无线链路和用户面的数据传输承载，其余过程与RRC连接建立在专用信道相似。
6.4.2 信令建立流程
信令建立流程是在UE与UTRAN之间的RRC连接建立成功后，UE通过RNC建立与CN的信令连接， 也叫“NAS信令建立流程”，用于UE与CN的信令交互NAS信息，如鉴权、业务请求、连接建 立等。
UE与CN的交互的信令，对于RNC而言，都是直传消息。RNC在收到第一条直传消息时，即： 初始直传消息（Initial Direct Transfer），将建立与CN之间的信令连接，该连接建立S
CCP之上。流程如下图所示：
图6-8 信令建立过程
具体流程如下：
1）RRC连接建立后，UE通过RRC连接向RNC发送初始直传消息（Initial Direct Transfer） ，消息中携带UE发送到CN的NAS信息内容。
2）RNC接收到UE的初始直传消息，通过Iu接口向CN发送SCCP连接请求消息（CR），消息数 据为RNC向CN发送的初始UE消息（Initial UE Message），该消息带有UE发送到CN的消息内 容。
3）如果CN准备接受连接请求，则向RNC回SCCP连接证实消息（CC），SCCP连接建立成功。 RNC接收到该消息，确认信令连接建立成功。
4）如果CN不能接受连接请求，则向RNC回SCCP连接拒绝消息（CJ），SCCP连接建立失败。 RNC接收到该消息，确认信令连接建立失败，则发起RRC释放过程。
信令连接建立成功后，UE发送到CN的消息，通过上行直传消息（Uplink Direct Transfer
）发送到RNC，RNC将其转换为直传消息（Direct Transfer）发送到CN；CN发送到UE的消息 ，通过直传消息（Direct Transfer）发送到RNC，RNC将其转换为下行直传消息（Downlin
k Direct Transfer）发送到UE。
6.4.3 RAB建立流程
RAB是指用户平面的承载，用于UE和CN之间传送语音、数据及多媒体业务。UE首先要完成R RC连接建立，然后才能建立RAB。
RAB建立是由CN发起，UTRAN执行的功能，基本流程为：
* 首先由CN向UTRAN发送RAB指配请求消息，请求UTRAN建立RAB；
* UTRAN中的SRNC发起建立Iu接口与Iub接口（Iur接口）的数据传输承载；
* SRNC向UE发起RB建立请求；
* UE完成RB建立，向SRNC回应RB建立完成消息；
* SRNC向CN应答RAB指配响应消息，结束RAB建立流程。
当RAB建立成功以后，一个基本的呼叫即建立，UE进入通话过程。
根据无线资源使用情况（RRC连接建立时的无线资源状态与RAB建立时的无线资源状态），
可以将RAB的建立流程分成以下三种情况：
1）DCH-DCH：RRC使用DCH，RAB准备使用DCH；
2）RACH/FACH-RACH/FACH：RRC使用CCH，RAB准备使用CCH；
3）RACH/FACH-DCH：RRC使用CCH，而RAB准备使用DCH。
下面给出以上第一种情况下的RAB建立流程的具体过程描述。
1. DCH-DCH
UE当前的RRC状态为专用传输信道（DCH）时，指配的RAB只能建立在专用传输信道上。根据 无线链路（RL）重配置情况，RAB建立流程可分为同步重配置RL（DCH-DCH）与异步重配置
RL（DCH-DCH）两种情况，二者的区别在于Node B与UE接收到SRNC下发的配置消息后，能否
立即启用新的配置参数：
* 同步情况下，Node B与UE在接收到SRNC下发的配置消息后，不能立即启用新的配置参数 ，而是从消息中获取SRNC规定的同步时间，在同步时刻，同时启用新的配置参数；
* 异步情况下，Node B与UE在接收到SRNC下发的配置消息后，将立即启用新的配置参数。
(1) 同步重配置RL
在DCH-DCH同步情况下，需要SRNC 、Node B与UE之间同步重配置RL：
* Node B在接收到SRNC下发的重配置RL消息后，不能立即启用新的配置参数，而是准备好 相应的无线资源，等待接收到SRNC下发的重配置执行消息，从消息中获取SRNC规定的同步 时间；
* UE在接收到SRNC下发的配置消息后，也不能立即启用新的配置参数，而是从消息中获取
SRNC规定的同步时间；
* 在SRNC规定的同步时刻，Node B与UE同时启用新的配置参数。
下面给出RAB建立流程中DCH-DCH同步重配置RL的过程。
图6-9 RAB建立流程（DCH-DCH，同步）
信令流程说明：
1）CN向UTRAN发送RANAP协议的RAB指配消息Radio Access Bearer Assignment Request， 发起RAB建立请求；
2）SRNC接收到RAB建立请求后，将RAB的QoS参数映射为AAL2链路特性参数与无线资源特性 参数，Iu接口的ALCAP根据其中的AAL2链路特性参数发起Iu接口的用户面传输承载建立过程 ；
3）SRNC向属下的Node B发送NBAP协议的无线链路重配置准备Radio Link Reconfiguratio n Prepare消息，请求属下的Node B准备在已有的无线链路上增加一条（或多条）承载RAB 的专用传输信道（DCH）；
4）Node B分配相应的资源，然后向所属的SRNC发送Radio Link Reconfiguration Ready消 息，通知SRNC无线链路重配置准备完成；
5）SRNC中Iub接口的ALCAP发起Iub接口的用户面传输承载建立过程， Node B与SRNC通过交 换DCH帧协议的上下行同步帧建立同步；
6）SRNC向属下的Node B发送无线链路重配置执行消息Radio Link Reconfiguration Comm it；
7）SRNC向UE发送RRC协议的RB建立消息Radio Bearer Setup；
8）UE执行RB建立后，向SRNC发送无线承载建立完成消息Radio Bearer Setup Complete；
9）SRNC接收到无线承载建立完成的消息后，向CN回应RAB指配响应消息Radio Access Bea rer Assignment Response，结束RAB建立流程。
(2) 异步重配置RL
在DCH-DCH异步情况下，不要求SRNC 、Node B与UE之间同步重配置RL：Node B与UE在接收 到SRNC下发的配置消息后，将立即起用新的配置参数。
下面给出RAB建立流程中DCH-DCH异步重配置RL的例子。
图6-10 RAB建立流程（DCH-DCH， 异步）
信令流程说明：
1）CN向UTRAN发送RANAP协议的RAB指配消息Radio Access Bearer Assignment Request，
发起RAB建立请求；
2）SRNC接收到RAB建立请求后，将RAB的QoS参数映射为AAL2链路特性参数与无线资源特性 参数，Iu接口的ALCAP根据其中的AAL2链路特性参数发起Iu接口的用户面传输承载建立过程 ；
3）在异步情况下，无线重配置无需同步，SRNC向属下的Node B发送NBAP协议的无线链路重 配置请求Radio Link Reconfiguration Request消息，请求属下的Node B在已有的无线链 路上建立新的专用传输信道（DCH）；
4）Node B接收到无线链路重配置请求消息后，即分配相应的资源，然后向所属的SRNC发送 Radio Link Reconfiguration Response消息，通知SRNC无线链路重配置完成；
5）SRNC中Iub接口的ALCAP发起Iub接口的用户面传输承载建立过程， Node B与SRNC通过交 换DCH帧协议的上下行同步帧建立同步；
6）SRNC向UE发送RRC协议的无线承载建立消息Radio Bearer Setup；
7）UE执行RB建立后，向SRNC发送无线承载建立完成消息Radio Bearer Setup Complete；
8）SRNC接收到无线承载建立完成的消息后，向CN回应RAB指配响应消息Radio Access Bea rer Assignment Response，结束RAB建立流程。
6.4.4 呼叫释放流程
呼叫释放流程也就是RRC连接释放流程。RRC连接释放流程分为两种类型：UE发起的释放和 CN发起的释放。两种释放类型的区别主要在于高层的呼叫释放请求消息由谁先发出，但最
终的资源释放都是由CN发起的。
当CN决定释放呼叫后，将向SRNC发送IU RELEASE COMMAND消息。SRNC收到该释放命令后， 有如下操作步骤：
1 ）向CN返回IU RELEASE COMPLETE消息；
2 ）发起IU接口用户面传输承载的释放；
3 ）释放RRC连接。
RRC释放就是释放UE和UTRAN之间的信令链路以及全部无线承载。根据RRC连接所占用的资源 情况，可进一步划分为两类：释放建立在专用信道上的RRC连接和释放建立在公共信道上的
RRC连接。
1. 释放建立在专用信道上的RRC连接
图6-11 释放建立在专用信道上的RRC连接
流程描述：
1) RNC向UE发送RRC连接释放消息RRC Connection Release；
2) UE向RNC返回释放完成消息RRC Connection Release Complete；
3) RNC向Node B发送无线链路删除消息Radio Link Deletion，删除Node B中的无线链路资 源；
4) Node B资源释放完成后，向RNC返回释放完成消息Radio Link Deletion Response；
5) RNC使用ALCAP协议发起IUB接口用户面传输承载的释放。
最后RNC再发起本端L2资源的释放。至此，RRC释放过程结束。
2. 释放建立在公共信道上的RRC连接
释放建立在公共信道上的RRC连接时，因为此时用的是小区公共资源，所以直接释放UE就可 以了，无需释放Node B的资源，当然也没有数据传输承载的释放过程。
6.4.5 切换流程
切换过程是移动通信区别于固定通信的一个显著特征之一， 当UE使用的小区或制式（FDD
，TDD）发生变化时，我们就说UE发生了切换。 WCDMA支持的切换包括软切换，硬切换， 前向切换和系统间切换。软切换和硬切换主要是由网络侧发起，前向切换主要是UE发起，
而系统间切换既有网络侧发起的情况，又有UE发起的情况。发生切换的原因包括UE的移动
，资源的优化配置，人为干预等。
1. 软切换
在WCDMA中，由于相邻小区存在同频的情况，UE 可以通过多条无线链路与网络进行通信，
在多条无线链路进行合并的时候，通过比较，选取信号较好的一条，从而达到优化通信质
量的目的，只有FDD制式才能进行软切换。根据小区之间位置的不同，软切换可以分为几种
情况。第一种情况， Node B内不同小区之间。这种情况，无线链路可以在Node B内，也可 以到SRNC再进行合并，如果在Node B内部就完成了合并，我们称之为更软切换；第二种情 况，同一RNC内不同Node B之间；还有不同RNC之间。
软切换中一个重要问题就是多条无线链路的合并，WCDMA中使用宏分集（MACRO DIVERSITY ）技术对无线链路进行合并，就是根据一定的标准（如误码率）对来自不同无线链路的数
据进行比较，选取质量较好的数据发给上层。
在软切换中，关于邻近小区有几个重要的概念：
1 ）活动集，指的是UE当前正在使用的小区的集合，软切换的执行结果就表现在活动集中
小区增加或减少。
2 ）观察集，UE根据UTRAN给的邻近小区信息，正在观察但不在活动集中的小区，UE对观察 集中的小区进行测量，当测量结果符合一定的条件时，这些小区可能被加入活动集，所以
有时也称为候选集；
3 ）已检测集，UE已检测到，但既不属于活动集也不属于观察集的小区，UTRAN可以要求U E报告已检测集的测量结果；由于它们不属于邻近小区列表，所以有时也称之为未列出集。
软切换的过程可以分为以下几个步骤：
1 ）UE根据RNC给的测量控制信息， 对同频的邻近小区进行测量，测量结果经过处理后，
上报给RNC；
2 ）RNC对上报的测量结果和设定的阈值进行比较，确定哪些小区应该增加，哪些应该删除
；
3 ）如果有小区需要增加，先通知Node B准备好；
4 ）RNC通过活动集更新消息，通知UE增加和/或删除小区；
5 ）在UE成功进行了活动集更新后，如果删除了小区，则通知Node B释放相应的资源。
在进行软切换的过程中，原来的通信不受影响，所以能够完成从一个小区到另一个小区的
平滑切换。
2. 硬切换
当邻近小区属于异频小区时，不能进行软切换，这时可以进行硬切换，硬切换过程就是先
中断跟原来小区的通信，然后再从新的小区接进来，因此它的性能不如软切换，所以一般
在不能进行软切换的时候，才会考虑硬切换。
硬切换的目标小区可以没有经过测量，适合于紧急情况下的硬切换，失败率较高；更常见
的硬切换同样也要对目标小区先进行测量，但一般UE只配一个解码器，不能同时对两个频
点的信号进行解码，所以为了UE能进行异频测量，在WCDMA中引入了压缩模式技术。
图6-12 压缩模式原理图
压缩模式技术的基本原理就是，Node B在发送某些帧（每10ms 发送的数据为一帧）的时候
，加大发送速率，用少于10ms的时间发送完原来需要10ms的数据，那么空出来的时间，就 让UE进行异频测量。具体采用什么方式和什么时间来加大发送速率，由RNC进行控制。
跟软切换类似，硬切换根据原小区和目标小区的位置关系，分为以下几种：
1）同一个小区内，FDD和TDD方式之间的硬切换；
2 ） Node B内的小区之间；
3 ）同一RNC内不同Node B的小区之间；
4 ）不同RNC的小区之间。
通常不同RNC之间发生硬切换时，两个RNC之间都存在IUR接口，否则就需要通过伴随迁移（ RELOCATION）来完成硬切换。
Uu接口有5个信令过程都能够完成硬切换：
1 ）物理信道重配置（PHYSICAL CHANNEL RECONFIGURATION ）；
2 ）传输信道重配置（TRANSPORT CHANNEL RECONFIGURATION）；
3 ）RB建立过程（RADIO BEAR SETUP ）；
4 ）RB释放过程（RADIO BEAR RELEASE）；
5 ）RB重配置过程（RADIO BEAR RECONFIGURATION）。
下图以物理信道重配置为例给出不同Node B之间小区硬切换的信令过程：
图6-13 硬切换流程图
信令流程描述：
1）SRNC向目标小区所在的Node B发送消息Radio Link Setup Request，要求其建立一条无 线链路；
2）目标小区所在的Node B向SRNC应答消息Radio Link Setup Response，表明无线链路建 立成功；
3）SRNC采用ALCAP协议建立SRNC和目标Node B的IUB接口传输承载，并且进行FP同步；
4）SRNC通过下行DCCH信道向UE发送消息Physical Channel Reconfiguration，消息中给出 目标小区的信息；
5）在UE从原小区切换到目标小区后，原小区Node B会检测到无线链路失去联系，于是向S RNC发消息Radio Link Failure Indication，指示无线链路失败；
6）UE在成功切换到目标小区后，通过DCCH向SRNC发送消息Physical Channel Reconfigur ation Complete，通知SRNC物理信道重配置完成；
7）SRNC向原小区所在的Node B发送消息Radio Link Deletion Request，删除原小区的无 线链路；
8）原小区所在的Node B完成无线链路资源删除后，向SRNC应答消息Radio Link Deletion Response；
9）SRNC采用ALCAP协议释放SRNC和原小区所在Node B的IUB接口的传输承载。
3. 前向切换
RRC连接移动性管理中，前向切换是其中的一部分。前向切换分为小区更新和URA更新，主
要用于当UE位置发生改变时及时更新UTRAN侧关于UE的信息，还可以监视RRC的连接、切换 RRC的连接状态，另外还有错误通报和传递信息的作用。不管是小区更新还是URA更新，更
新过程均是由UE主动发起的。
(1) 小区更新
处于CELL_FACH、CELL_PCH或URA_PCH状态的UE都可能发起小区更新过程，对不同的连接状 态，会有不同的小区更新原因，小区更新流程也不同。
* 如果小区更新原因是周期性小区更新，且UTRAN侧不给UE分配新的CRNTI或URNTI，其流程 如图所示：
图6-14 小区更新过程
具体流程如下：
1）UE从CCCH向UTRAN发送CELL UPDATE消息。
2）UTRAN收到UE的CELL UPDATE消息处理完成后给UE发应答消息CELL UPDATE CONFIRM。UT
RAN侧结束本次小区更新。UE收到CELL UPDATE CONFIRM消息后结束本次小区更新。
* 如果小区更新的原因是因为有上行数据传输，或者是对寻呼的响应，UTRAN侧没有给UE分 配CRNTI或URNTI，也没有指示相关物理信道信息，并且UE中保存的TFS/TFCS与系统信息中 广播的PRACH/SCCPCH的TFS/TFCS相同；如果小区更新的原因是因为有上行数据，或者是对 寻呼的响应，或者是小区重选，UTRAN侧给UE分配了CRNTI或URNTI，但没有指示相关物理信 道信息，并且UE中保存的TFS/TFCS与系统信息中广播的PRACH/SCCPCH的TFS/TFCS相同，其 流程中伴随有物理信道重配置。
* 如果小区更新的原因是因为有上行数据传输，或者是对寻呼的响应，UTRAN侧没有给UE分 配CRNTI或URNTI，也没有指示相关物理信道信息，并且UE中保存的TFS/TFCS与系统信息中 广播的PRACH/SCCPCH的TFS/TFCS不同；如果小区更新的原因是因为有上行数据，或者是对 寻呼的响应，或者是小区重选，UTRAN侧给UE分配了CRNTI或URNTI，但没有指示相关物理信 道信息，并且UE中保存的TFS/TFCS与系统信息中广播的PRACH/SCCPCH的TFS/TFCS不同，则 其流程中伴随有传输信道重配置。
* 如果小区更新原因是周期性，UTRAN侧给UE分配了CRNTI或URNTI，但没有指示相关物理信 道信息，UE将更新其标识，即流程中伴随有RNTI重分配。
(2) URA更新
URA更新过程的目的是处于URA_PCH状态下的UE经过URA再选择后用现在的URA更新UTRAN；在 没有URA再选择发生时该过程也可以用来监视RRC连接。一个小区中可以广播几个不同的UR
A ID，在一个小区中不同的UE可以属于不同的URA。当UE处于URA_PCH状态时有且仅有一个 有效的URA。处于URA_PCH状态时，如果分配给UE的URA不在小区中广播的URA ID列表中，则 UE将发起URA更新过程。或者UE在服务区内，但T306超时，则UE将发起URA更新过程。 * 如果URA更新过程中UTRAN没有给UE分配新的CRNTI或URNTI其流程如图所示：
图6-15 URA更新过程（没有分配新的CRNTI或URNTI）
具体流程如下：
1）UE从CCCH向UTRAN发起URA UPDATE消息。
2）UTRAN收到UE的URA UPDATE消息处理完成后给UE发应答消息URA UPDATE CONFIRM，并结
束UTRAN侧本次URA更新。UE收到URA UPDATE CONFIRM消息后，结束本次URA更新。
* 如果URA更新过程中UTRAN给UE分配了新的CRNTI或URNTI则其流程中伴随有UE发给UTRAN的
RNTI REALLOCATION COMPLETE消息。
4. 系统间切换
WCDMA支持UE在UTRAN和现存系统（如GSM/GPRS）之间进行切换，可以分为网络控制下的切 换（如GSM）和UE的小区重选（如GPRS）二种情况，它们各自又可分为入UTRAN和出UTRAN两 种情况；这里仅以网络控制下的切换入UTRAN为例详细介绍流程。这里只介绍UTRAN中的信 令。
* 迁入UTRAN
图6-16 迁入UTRAN流程图
具体流程如下：
1）CN 用Relocation Request消息通知UTRAN有UE需要迁入；
2）UTRAN在准备好资源之后，向CN发送Relocation Request Acknowledge消息，在这条消
息中又带着Handover To UTRAN Command消息，由对方系统把Handover To UTRAN Command 消息发送给UE；
3）UE在成功接入UTRAN之后， 向UTRAN发送Handover To UTRAN Complete消息。
6.4.6 SRNS重定位
RNC重定位指UE的SRNC从一个RNC变成另一个RNC的过程，根据发生迁移时UE所处位置的不同 可以分为静态迁移和伴随迁移两种情况，或者说UE不涉及的（UE Not Involved）和UE涉及 的（UE Involved）。
1. 静态迁移
发生静态迁移的条件是UE从一个DRNC，而且只从一个DRNC中接入。由于迁移过程不需要UE 的参与，所以也称之为UE不涉及的（UE Not Involved）迁移，下面给出一个存在两条无线
链路的例子。发生迁移之后，原来的DRNC变成了SRNC，IUR接口的连接被释放，IU接口发生 迁移，如图所示。
图6-17 静态迁移过程
在WCDMA中由于存在两个CN域，如果在发生迁移的时候，UE和两个域都有连接，那么这两个 域必须同时迁移。
2. 伴随迁移
伴随迁移指UE从SRNC硬切换到目标RNC，同时IU接口发生变化的过程。由于迁移过程需要U E的参与，所以也称之为UE涉及的（UE Involved）迁移。其连接变化情况如图所示：
图6-18 伴随迁移过程
能够完成硬切换的5个信令过程都可以用来完成伴随迁移。
6.5 电路域移动性管理
6.5.1 位置更新
位置更新过程是由HLR、MSC/VLR等实体之间逻辑配合完成。HLR记录移动用户当前位置信息 和所有用户数据；VLR记录漫游到由该VLR控制位置区的移动用户的相关用户数据；MSC处理 移动用户的位置登记过程，与移动用户对话并与HLR、VLR交互信息。
位置更新包括位置登记、周期性位置登记、用户数据删除等。
1. 位置登记
执行MAP操作里的Update Location操作，可以通过Update Location Request消息里的Upd ate Location Type来区分不同类型的位置登记。
引起移动用户发生正常位置登记的条件是：
移动设备开机时以及移动用户发生漫游引起位置改变。其中移动设备开机时Update Locat
ion Type指示为IMSI Attach，漫游时Update Location Type指示为Normal Updating。
移动设备主要是通过自身记录的LAI与收到的广播消息里的LAI对比，相同则发起IMSI Att
ach过程，不同则发起Normal Updating操作。
2. 周期性位置登记
执行MAP操作里的Update Location操作，此时Update Location Request消息里的Update Location Type指示为Periodic Updating。
通过周期性位置登记（位置更新），PLMN可以保持追踪移动用户当前的状态，特别是保持
长时间没有操作的用户与网络的联系。位置更新时间周期和保护时间可以由PLMN运营商根
据具体话务和用户习惯来设定调整。
3. 用户数据删除
执行MAP操作里的Cancel Location操作。
指将用户记录从VLR中删除，包括用户漫游产生的用户数据删除、用户长时间无操作引起的
用户数据删除、以及系统管理员对无效用户记录所进行的删除。
用途是位置更新时HLR删除前VLR的用户信息，或用户数据修改引发的独立位置删除，以及
操作人员删除用户位置信息。
下图是一个典型的位置更新流程图，基本包含了上述三个过程。
图6-19 位置更新流程图
(1) MSC/VLR接收到用户用TMSI发起的位置更新请求后，如果TMSI不认识：
A、若携带的前位置信息为临近VLR的位置区，则发起向PVLR取识别的流程，参见上图 中的SEND IDENTIFICATION流程；
B、若前位置区为非临近VLR的位置区或者到PVLR取识别失败，则发起要求手机提供IM SI的流程，上图中没有列出该流程，要求手机提供IMSI的流程参见下面章节。
(2) 如果用户在本VLR首次位置登记，则发起到HLR的位置更新请求。否则直接进入LOCAT ION UPDATING ACCEPT流程。
(3) HLR接收到MSC/VLR的位置更新请求后，发现如果用户漫游 的MSC/VLR号码发生改变， 向PVLR发起位置删除流程，删除PVLR中的用户信息。
(4) 如果漫游拒绝，HLR直接向MSC/VLR发出携带拒绝信息的位置更新响应；否则首先向M SC/VLR插入用户数据，然后根据插入用户数据的结果，判断是下发位置更新接受还是位置
更新拒绝。
6.5.2 分离
分离过程即移动用户关机，UE发起IMSI Detach的过程，MSC/VLR置用户状态为IMSI分离， 值得注意的是该过程不通知HLR。这和Purge过程不同，因为在HLR中是没有用户Detach/At
tach状态指示位的，但是Purge有，这可以参见后面对于Purge操作的详细描述。
如果该用户做被叫，则HLR会通过Provide Roaming Number过程到VLR取漫游号码，此时因 为用户为Detach状态，所以取Roaming Number失败，返回原因值为Absent Subscriber，主 叫MSC根据该原因值给主叫UE放用户已关机提示音。
流程图如图
图6-20 关机流程图
有些型号的移动终端，在通话期间直接关电源时，也可以发起Detach 过程。
6.5.3 身份识别
身份识别过程在Iu接口发生，用于网络向移动设备要求提供IMEI或IMSI信息，身份识别执
行Identity过程。
Identity过程有两种：
* VLR里没有移动设备的IMEI时，将强制执行一个Identity过程，网络侧通过Identity
Request向移动设备发起请求IMEI的操作，移动设备在Identity Response里给网络侧提供 IMEI。
典型的情况有用户的第一次位置更新、VLR记录的用户IMEI无效（注意由于目前没有使用I
MEI鉴权，所以不会影响用户使用）。
* 由于位置更新时TMSI不识别，将强制执行一个Identity过程， 网络侧通过Identity R
equest向移动设备发起请求IMSI的操作，移动设备在Identity Response里给网络侧提供I MSI。
典型的情况有用户漫游到不使用TMSI的区域等。
图6-21 IDENTITY流程图
6.5.4 用户清除
用户清除就是VLR发起移动用户删除过程，即MAP的PurgeUE过程，用于VLR向HLR报告VLR的 用户删除操作。和上一节的IMSI Detach过程不同，PurgeUE过程要通知HLR，收到PurgeUE 消息以后，在HLR中将把该用户的UE Purge Flag标志置位，指示该用户已经在VLR中清除了 。
如果该用户做被叫，则当主叫UE通过Send Routing Information过程到HLR时，HLR会查询 UE Purge Flag标志，由于是置位状态，所以HLR将会给MSC返回Absent Subscriber的失败 原因值，主叫MSC根据该原因值给主叫UE放用户已关机提示音。该过程没有HLR到VLR的Pro vide Roaming Number操作。
图6-22 PURGE流程图
6.5.5 鉴权流程
一个成功的鉴权过程可以用流程图来表示，如图所示。
图6-23 鉴权成功
鉴权流程由网络侧发起，其目的是：由网络来检查是否允许终端接入网络；提供鉴权参数
五元组中的随机数数组，供终端计算出加密密钥（CK）；同时，供终端计算出与网络侧进
行一致性检查的密钥（IK）；最后一个目的是可以提供终端对网络的鉴权。
与GSM的鉴权流程相比，3G的鉴权流程增加了一致性检查的功能及终端对网络的鉴权功能。 这些功能使3G的安全特性有了进一步的增强。
网络侧在发起鉴权前，如果VLR内还没有鉴权参数五元组，此时将首先发起到HLR取鉴权集
的过程，并等待鉴权参数五元组的返回。鉴权参数五元组的信息包含RAND、XRES、AUTN、 CK和IK。
在检测到鉴权参数五元组的存在后，网络侧下发鉴权请求消息。此消息中将包含某个五元
组的RAND和AUTN。用户终端在接收到此消息后，由其USIM验证AUTN，即终端对网络进行鉴 权，如果接受，USIM卡将利用RAND来计算出CK与IK和签名XRES。如果USIM认为鉴权成功， 在鉴权响应消息中将返回XRES。
网络侧在收到鉴权响应消息之后，比较此鉴权响应消息中的XRES与存储在VLR数据库中的鉴 权参数五元组的XRES，确定鉴权是否成功：成功，则继续后面的正常流程；不成功，则会
发起异常处理流程，释放网络侧与此终端间的连接，并释放被占用的网络资源、无线资源
。
在成功的鉴权之后，终端将会把CK（加密密钥）与IK（一致性检查密钥）存放到USIM卡中
。
有些情况下，终端会在收到鉴权请求消息后，上报鉴权失败！典型的鉴权失败的原因有下
面两种：
手机终端在对网络鉴权时，检查由网络侧下发的鉴权请求消息中的AUTN参数，如果其中的
“MAC”信息错误，终端会上报鉴权失败消息，原因值为MAC Failure。
图6-24 鉴权失败（失败原因为MAC Failure）
此时，网络侧将根据手机终端上报的用户标识来决定是否发起识别过程。如果当前的标识
为TMSI（或P-TMSI），则发起识别流程，要求手机终端上报IMSI信息。然后再次发起鉴权
流程。
另外一种鉴权失败的情况是手机终端检测到AUTN消息中的SQN的序列号错误，引起鉴权失败 ，原因值为：Synch failure!（同步失败）
图6-25 鉴权失败（原因值为Synch failure）
此时，网络侧的VLR将删除所有鉴权参数5元组，并发起到HLR的同步过程，要求HLR 重新插 入鉴权参数五元组，然后再开始鉴权过程。
6.5.6 安全模式控制
安全模式控制过程是由网络侧用来向无线接入网侧发送加密信息的。在此过程中，核心网
的网络侧将与无线接入网协商对用户终端进行加密的算法，使得用户在后续的业务传递过
程中使用此加密算法；并且在终端用户发生切换后，尽可能的仍使用此加密算法——即用
于加密的有关参数会送到切换的目的RNC。
图6-26 安全模式控制
6.5.7 TMSI重分配
TMSI，临时移动用户识别码，是由和临时分配给指定用户的一串数字（4个BYTE）组成。T
MSI由MSC/VLR管理，一般来说是当用户首次在一个位置区注册时分配给它，并在用户离开 该位置区时注销。TMSI被用来唯一识别一个位置区的移动台，取代IMSI在无线信道中传输
，从而防止第三方通过窃听无线信道上的信号而识别并跟踪移动用户。所以其主要作用就
是增加移动台的安全性。
TMSI与IMSI（国际移动终端设备标识）的对应关系存放在管理移动台当前访问位置区的VL
R中，最新分配的TMSI也存放于移动台的SIM卡中。所以TMSI是VLR和SIM卡里两处保存的。
TMSI重分配的实现在用户位置更新和呼叫建立及补充业务等业务过程都可以执行。这在MS
C的MAP功能流程里选择是否执行TMSI的重新分配流程即可实现。
在位置更新时进行的TMSI重分配流程，是与位置更新接受融合在一起的。其流程图如图所
示：
图6-27 位置更新时的TMSI重分配
& 说明：
在移动性管理过程中，鉴权、安全模式控制、TMSI重分配等几项过程属于可选过程
。这些过程可以由网络运营商来决定是否激活或提供。
如MSC9800里是通过MAP功能流程配置参数来实现的。
6.5.8 联合位置更新
当用户终端所处的位置区与路由区都发生改变时，将发起联合位置更新过程：同时在CS域
、PS域发起位置更新。网络侧的CS域与PS域通过Gs接口相连（核心网的电路域、分组域分
离组网时，下面的描述中将用MSC来代表CS域，SGSN来代表PS域）。Gs接口采用No.7信令上 中的BSSAP+协议，借助Gs接口，CS域和PS域可互相更新数据库里保存的移动台的位置信息 ，这样可减少空中信令，而且有助于MSC通过Gs接口寻呼到正在进行GPRS业务的B类手机。
下图是一个典型的联合位置更新的流程图：
图6-28 联合位置更新
(1) SGSN接收到手机的路由区更新请求后，如果需要则发起到HLR的位置更新。
(2) 如果SGSN和MSC/VLR之间配置有Gs接口，则SGSN发起到MSC/VLR的联合位置更新，否则 直接下发路由区更新接受。
(3) MSC/VLR接收到SGSN的位置更新请求后，执行MSC/VLR的位置更新处理和并记录关联数 据。
(4) MSC/VLR接收到HLR的位置更新接受后，通过Gs接收向SGSN发出位置更新接受消息。
(5) SGSN接收到MSC/VLR的位置更新接受消息后，置关联数据，下发路由区更新接受。如
果进行了TMSI重分配，则SGSN把手机上报的TMSI重分配完成转发给MSC/VLR完成联合位置更 新流程。
6.6 分组域移动性管理流程
6.6.1 MM功能概述
移动性管理（MOBILITY MANAGEMENT）的主要作用就是为了在本PLMN或是其他PLMN中，对用 户的当前位置进行跟踪。 比如用户想登录到GPRS网络，就必需首先执行附着（ATTACH）过 程（它移动性管理的一个基本流程），使之相关信息在核心网络中进行注册。MM和会话管
理SM（SESSION MANAGEMENT）、短消息SMS（SHORT MESSAGE SERVICES）共同组成了3GPP协
议中的连接层，在UMTS系统中，MM处于RANAP层之上，为SM和SMS提供信令传送。它的其他
功能还包括用户的分离、安全流程、路由区更新、位置更新等。
1. 术语介绍
* GMM/PMM
GMM：GPRS Mobility Management GPRS移动性管理（主要用来区别于CMM Circuit Mobil ity Management）
PMM：Packet Mobility Management 分组移动性管理
在这里，我们可以简单认为GMM和PMM分别指的是GSM和UMTS系统中的移动性管理，本文主要 介绍UMTS系统中分组域的移动性管理特性。
* RANAP
Radio Access Network Application Part 无线接入网络应用部分。RANAP协议层封装、
传输更高层的信令，处理3G-SGSN和UTRAN之间的信令，管理IU接口的GTP连接。
* MM CONTEXT
MM的用户上下文，包括了用户签约数据、鉴权集。
GMM在协议栈中的位置如图所示。
图6-29 UMTS系统分组域手机和网络侧的控制面协议
6.6.2 移动性管理状态
UMTS系统中的分组移动性管理的状态可以分为：PMM-DETACHED、PMM-IDLE、PMM-CONNECTE D。
* PMM DETACHED State
在该状态下，MS和3G-SGSN之间没有通讯，没有有效的位置信息和路由信息。MS不可达，M S位置不可知。
* PMM IDLE State
MS位置可知，但处于空闲状态
* PMM CONNECTED State
MS位置可知，PS信令连接已经被建立。
具体PMM的状态迁移关系描述如下图所示。从图中，我们还可以看出移动性管理处在连接态
，会话管理可以处在激活态或者非激活态；移动性管理处在空闲态，会话管理可以处在激
活态或者非激活态。也就是说MM状态只与GPRS的移动性管理活动有关，和PDP上下文的状态 、数量没有任何联系。
注： 在某种错误影响下，可能出现MS和网络侧的状态不同步，通过路由更新过程就
可以实现同步。
图6-30 UMTS系统分组域移动性管理的状态迁移图
6.6.3 SGSN和MSC/VLR之间的联系
在UMTS系统中，规定了SGSN和MSC/VLR之间的Gs接口。他们之间的关联关系会通过以下的过 程建立：
* 联合GPRS/IMSI附着/分离；
* 已经IMSI附着的用户的GPRS附着；
* 已经GPRS附着的用户的IMSI附着（发生的是联合路由区更新）。
建立了Gs接口的联系后，系统便可以进行以下流程：
(1) 电路域寻呼（CS Paging）：
对于一个联合附着的用户，MSC/VLR可以通过SGSN发送电路域寻呼。
(2) 非GPRS业务提醒（Non-GPRS Alert）：
MSC/VLR要求SGSN通知MSC/VLR手机的活动情况，会将非GPRS业务提醒标志（NGAF）置位， SGSN移动性管理一旦发现该用户活动，立刻通知MSC/VLR，然后清除NGAF。
(3) MS信息过程（MS Information Procedure）：
MSC/VLR需要用户的身份信息和位置信息时，可以通过Gs接口从SGSN本地获得或通过SGSN下 发信息请求，取得MSC/VLR所需信息。
(4) MM信息过程（MM Information Procedure）：
MSC/VLR可以通过SGSN将网络信息发送给用户，SGSN会将信息下传。
6.6.4 联合的 GPRS / IMSI 附着过程
图6-31 附着流程
注： 图中的C1为CAMEL点，可触发或进行智能业务。本章以下流程图中出现的C1、C
2、C3等均为CAMEL点，不再注释。
1）用户通过发送附着请求消息发起附着流程。用户在附着请求消息中携带有IMSI or P-T
MSI and old RAI，Attach Type， old P-TMSI Signature， Follow On Request等参数， 如果用户没有合法的P-TMSI，用户会带上IMSI；如果用户有合法的P-TMSI，用户应该使用
P-TMSI和配对的路由区标识，同时如果具有P-TMSI签名的话，也应该带上。附着类型指示
用户请求执行何种附着过程，即GPRS附着、联合附着以及已经IMSI附着的GPRS附着。SGSN 可以根据Follow On Request指示，决定在附着结束后，是否释放同用户的分组业务信令连
接。
2）如果用户使用P-TMSI附着，并且自上次附着改变了SGSN，新SGSN应该发送身份识别请求 给老的SGSN，带上用户的P-TMSI和相应的路由区标识以及老的P-TMSI签名，如果有的话。 老SGSN回应身份识别响应消息，包含用户的IMSI和鉴权集。如果用户在老SGSN未知，老SG SN回应消息带上相应的原因值；如果用户的P-TMSI和签名不匹配，老SGSN回应消息带上相 应的原因值。
3）如果用户在老SGSN为未知，新SGSN应该发起身份识别请求给用户，身份类型指示IMSI ，用户应该报告自己的IMSI 给SGSN。
4）如果用户的移动性管理上下文在网络侧不存在，鉴权过程是必须的。如果将要重分配P
-TMSI，并且网络支持加密，加密模式应该被设置。
5）移动台设备检查功能定义在身份检查流程中，此功能现均不实现。
6）如果SGSN号码自从上次分离后发生改变，或者是用户的第一次附着，SGSN应该通知HLR 。具体过程如下：
SGSN发送一条UpdateLocation消息（带有SGSN号码、SGSN地址、IMSI）给HLR；HLR发送C ancel Location（带有IMSI、取消类型）消息给老的SGSN同时置取消类型为Update Proce
dure；老SGSN以Cancel Location Ack（带有IMSI）消息确认收到HLR的Cancel Location； HLR发送插入用户签约数据消息（带有IMSI、GPRS签约数据）给新SGSN；新SGSN证实用户存 在于新的路由区中，如果用户签约数据限制用户在此路由区附着，SGSN应该拒绝用户的附
着请求，带以恰当的原因值，同时可以回应插入签约数据确认消息给HLR。如果签约数据检
查由于其他原因失败，SGSN应该拒绝用户附着请求，带上合适的原因值，同时回应HLR插入 签约数据确认消息（带有IMSI、原因值）。如果所有签约数据检查通过，SGSN为用户构造
MM上下文，同时回应HLR插入签约数据确认消息（带有IMSI）。HLR在删除旧的MM上下文和
插入新的MM上下文完成后，发送Update Location Ack消息给SGSN确认SGSN的Update Loca tion消息。如果Update Location被HLR拒绝，SGSN带上合适的原因值拒绝用户的附着请求 。
7）如果在步骤1中的附着类型指示已经IMSI附着的用户进行GPRS附着，或者联合附着，那 么VLR应该被更新，如果配置了Gs接口的话。VLR号码可以从路由区信息导出，即收到HLR的 第一次插入用户签约数据消息时，就可以开始Location Update流程，这将导致用户在VLR
中被标记上GPRS附着。
8）SGSN选择Radio Priority SMS，发送附着接受消息（带有P-TMSI、VLR号码、TMSI、P- TMSI 签名、Radio Priority SMS）给用户。如果重新分配了P-TMSI，应该在消息中带上。
9）如果P-TMSI 或者TMSI 改变，用户以附着完成消息给SGSN确认新分配的TMSI。
10）如果TMSI发生改变，SGSN发生TMSI重分配完成消息给VLR以确认重分配的TMSI。 如果附着请求不能被接受，SGSN回送附着拒绝消息（带有IMSI、Cause）给用户。
6.6.5 分离功能
分离过程包括MS发起的、SGSN发起的和HLR发起的分离过程（本文只介绍MS发起和SGSN发起 的分离过程）。
1. MS发起的分离
图6-32 MS发起的分离
1）用户发送分离请求消息（带有Detach Type，P-TMSI，P-TMSI Signature， Switch Of f）给SGSN，从而发起分离流程。Detach Type指示将要进行何种类型的分离流程，即GPRS 分离、IMSI分离、联合分离。 Switch Off指示用户的分离是否是因为关机。分离请求消息
带有用户的P-TMSI和P-TMSI签名，签名是用来检查用户分离消息的合法性的。如果用户的
签名不合法或者没有带，SGSN应该发起鉴权。
2）如果是GPRS分离，存在于GGSN中属于该用户的激活的PDP上下文的去活，是通过SGSN向 GGSN发送删除PDP上下文请求消息（带有TEID）来实现的。GGSN以删除PDP上下文响应消息 予以确认。
3）如果是IMSI分离，SGSN应该发送IMSI分离指示消息给VLR。
4）如果用户需要在GPRS分离同时保留IMSI附着，SGSN应该发送GPRS分离指示消息给VLR。 VLR删除和SGSN的关联，并且不再通过SGSN发起寻呼和Location Update。
5）如用户不是因为关机发起分离，SGSN应该回应分离接受消息给用户。
6）如果用户发起GPRS分离，SGSN释放PS域信令连接。
2. SGSN发起的分离
图6-33 SGSN发起的分离过程
1）SGSN以分离请求消息（带有分离类型）通知用户已经被分离。分离类型指示用户是否被
要求重新附着和重新激活原先分离前激活的PDP上下文。如果是，在分离完成后，附着流程
将会发起。
2）SGSN通知GGSN删除PDP上下文请求消息（带有TEID），以通知GGSN去活该用户激活的PD
P上下文。GGSN以删除PDP上下文响应消息确认SGSN的删除请求。
3）如果用户是联合附着，SGSN应该发送GPRS分离指示消息（带有用户IMSI）通知VLR。VL R去除和SGSN的关联，不再通过SGSN进行寻呼和位置区更新。
4）用户可能在收到SGSN的分离请求后的任何时候发送分离接受消息给SGSN。
5）在收到用户的分离接受消息后，如果分离类型不要求用户重新附着，那么SGSN将释放分
组域的信令连接。
6.6.6 安全流程（鉴权加密）
图6-34 鉴权加密
1）如果SGSN没有以前存储的UMTS五元鉴权组，向HLR发出一条发送鉴权信息（IMSI）消息 。收到此消息，HLR/AUC以鉴权信息确认消息给予回应，包含顺序排放的五元组。每一个五
元组包含RAND、XRES、AUTN、CK和IK。五元鉴权组的产生见3G TS 33.102。
2）在对UMTS用户进行鉴权时，SGSN选择下一组五元组并且包含属于这个五元组的RAND和A UTN于鉴权和加密请求消息中给用户。SGSN还选择一个CKSN包含于消息中。
3）在收到这个消息时，用户手机中的USIM验证AUTN，如果接受，根据协议33.102计算出R AND的签名RES。如果USIM认为鉴权成功，用户返回鉴权和加密响应消息（RES）给SGSN。同 时，手机中的USIM也计算出CK、IK，这些密钥同CKSN一起保存，直到CKSN在下一次鉴权后 被更新。
如果USIM认为鉴权不成功，例如鉴权同步错误，用户返回鉴权和加密失败消息给SGSN。
6.6.7 位置管理功能（路由区更新）
图6-35 路由区更新
1）如果没有RRC连接，先建立RRC连接。用户发送路由区更新请求消息（带有P-TMSI、老R AI、老P-TMSI签名、路由更新类型、跟随请求等）给新的SGSN。如果用户有上传的信令或 数据，跟随请求应该被置上。作为实现上的选择，SGSN可以根据跟随请求标志，决定在路
由更新流程结束后是否释放Iu连接。路由区更新类型应该指示：
路由区更新－－如果流程因为路由区改变引起；
周期性路由区更新－－如果流程因为周期性路由区更新定时器超时引起；
联合路由区更新－－如果用户是IMSI附着的，并且位置区更新应该在网络操作模式I 情况
下进行；
联合路由区更新伴随IMSI附着－－如果用户想要在网络操作模式I下进行IMSI附着；
服务RNC应该在将消息转发给SGSN前加上用户所在位置所属的路由区标识（包括路由区编码 和位置区编码）。
2）如果路由区更新是跨越SGSN间的，并且用户处于PMM-IDLE状态，新SGSN发送SGSN上下文 请求消息（带有用户老的P-TMSI、老的RAI、老的P-TMSI签名）给老的SGSN，以得到用户的 MM上下文和PDP上下文。老SGSN检验用户的P-TMSI和签名，如果不匹配回应合适的原因值。 这将导致新SGSN发起安全流程。如果安全流程鉴权用户通过，新SGSN应该发送SGSN上下文 请求消息（带有IMSI、老的RAI、用户已经验证标志）给老的SGSN。用户已经验证标志指示 新SGSN已经对用户进行鉴权。如果用户的签名合法或者经过新SGSN鉴权成功，老SGSN回应 SGSN上下文响应消息（Cause、IMSI、MM上下文、PDP上下文）。如果用户在老SGSN中为未 知，老SGSN回应以适当的原因值。老SGSN启动定时器。
3）安全流程可以在此处进行。如果鉴权失败，路由更新请求将被拒绝，新SGSN应该发送拒
绝指示给老SGSN。老SGSN应该继续如同没有收到过SGSN上下文请求消息一样。
4）如果是SGSN间的路由区更新，新SGSN应该发送SGSN上下文确认消息给老的SGSN。老的S GSN在它的上下文中标记MSC/VLR关联、GGSN和HLR中的信息为非法。如果在未完成正在进行 的路由更新前，用户发起路由更新回到老SGSN，这将引起MSC/VLR、GGSN、HLR被刷新。
5）如果是SGSN间的路由更新，并且用户处于PMM-IDLE状态，新SGSN发送修改PDP上下文请 求消息（新SGSN地址、协商的QoS、TEID）给相关的GGSN。GGSN更新它的PDP上下文，回应 修改PDP上下文响应消息（TEID）给SGSN。
6）如果是SGSN间的路由区更新，SGSN以Update Location消息（SGSN号码、SGSN地址、IM SI）通知HLR SGSN的改变。
7）如果是SGSN间的路由区更新，HLR发送Cancel Location（带有IMSI、取消类型）消息给 老的SGSN同时置取消类型为Update Procedure。老的SGSN以Cancel Location Ack消息（带 有IMSI）向HLR进行确认。
8）如果是SGSN之间的路由区更新，HLR发送插入签约数据消息（带有IMSI、GPRS签约数据 ）给新SGSN；新SGSN证实用户存在于新的路由区中，如果签约数据限制用户在此路由区附 着，SGSN应该拒绝用户的附着请求，带以恰当的原因值，同时可以回应插入用户签约数据
确认消息给HLR。如果签约数据检查由于其他原因失败，SGSN应该拒绝用户附着请求，带上 合适的原因值，同时回应HLR插入用户签约数据确认消息（带有IMSI、原因值）。如果所有
签约数据检查通过，SGSN为用户构造MM上下文，同时回应HLR插入用户签约数据确认消息（ 带有IMSI）。
9）如果是SGSN间的路由区更新，HLR在删除旧的MM上下文和插入新的MM上下文完成后，发 送Update Location Ack消息给SGSN确认SGSN的Update Location消息。
10）如果路由更新类型是联合路由更新伴随IMSI附着，或者位置区发生改变，SGSN和VLR之 间的关联必须建立。新SGSN发送Location Update Request 消息（带有新的位置区标识、 IMSI、SGSN号码、位置区更新类型）给VLR。如果路由区更新类型是联合路由区更新伴随I MSI附着，位置区更新类型应该指示IMSI附着。否则，位置区更新类型应该指示正常位置区
更新。VLR的号码是通过以RAI查询SGSN中的表得到。SGSN在上面的步骤8，即收到HLR的第 一次插入用户签约数据消息时，就可以开始Location Update流程。通过存储SGSN号码，V LR创建或者更新同SGSN的关联。
11）如果在VLR中的用户签约数据被标记为未被HLR证实，新VLR将通知HLR。HLR删除老的V LR的数据，插入用户签约数据到新的VLR。
12）新VLR分配新的TMSI，回应Location Update Accept（带有VLR 号码、TMSI）消息给S GSN，如果VLR没有改变，TMSI分配是可选的。
13）新SGSN证实用户存在于新的路由区中，如果签约数据限制用户在此路由区附着或者签
约数据检查失败，SGSN应该拒绝用户附着请求，带上合适的原因值。如果所有签约数据检
查通过，SGSN为用户构造MM上下文。新SGSN回应用户路由更新接受消息（带有P-TMSI、VL RTMSI、P-TMSI签名）。
14）用户以附着完成消息给SGSN确认新分配的TMSI。
15）如果TMSI发生改变，SGSN发生TMSI重分配完成消息给VLR以确认重分配的TMSI。 如果附着请求不能被接受，SGSN回送附着拒绝消息（带有IMSI、Cause）给用户。
注：步骤11、12和15仅当步骤10发生时才发生。
6.6.8 服务请求
1. 手机发起的服务请求
图6-36 手机发起的服务请求
1）如果没有CS通路，MS建立RRC连接。
2）MS发送Service Requset （P-TMSI，RAI，CKSN，Service Type）消息给SGSN。服务类 型定义了所需要的服务。服务类型是数据和信令中的一个。此时，SGSN可能会发起一个鉴
权过程。
如果服务类型指明是数据：那么MS和SGSN之间的信令连接将被建立，同时为激活的PDP预留 资源。
如果服务类型指明是信令：那么为上层信令传送的MS和SGSN之间的信令连接将被建立 。
3）如果MS在PMM-IDLE状态发起服务请求，SGSN将发起安全流程。
4）如果网络侧在PMM-CONNECTED状态，并且服务类型是数据，如果SGSN接受服务请求，SG SN将回应Service Accept消息给MS，如果指明是数据类型，SGSN发送Radio Access Beare r Assignment Request （NSAPIRAB?ID(s)，TEID(s)，QoS Profile(s)，SGSN IP Addres s(es)）消息重建无线接入承载给每一个激活的PDP上下文。
5）RNC 指示 MS 已经建立新的无线接入承载标识和相应的 RAB?ID 。
6）SRNC 发送消息 Radio Access Bearer Assignment Response （RAB?ID(s)， TEID(s) ，QoS Profile(s)，RNC IP Address(es)）消息响应。GTP 隧道已经在Iu接口上建立，如
果RNC回应Radio Access Bearer Assignment Response 消息，其中的原因值指明无法提供 要求的QoS，“Requested Maximum Bit Rate not Available”，那么SGSN将会再发送一个 Radio Access Bearer Assignment Request消息带有不同的QoS。重试的次数和新QoS的值 与实现相关。
7）对每一个RAB 重建修改了的QoS ，SGSN发起一个PDP 上下文修改过程通知MS和GGSN新的 协商过的QoS。
8）MS发送上行包。
服务接受消息并不意味着RAB(s)重建成功。
无论任何服务类型，如果服务请求不能被接受，网络侧将会回应一个服务拒绝消息并带上
合适的原因给MS。
当服务类型为数据时：如果SGSN 重建RAB(s)失败，SGSN将会发起修改过程或者将PDP去激 活，具体情况根据 QoS协商决定。
2. 网络侧发起的服务请求
图6-37 网络侧发起的服务请求
1）SGSN收到处在PMM-IDLE的MS的下行PDP PDU。
2）SGSN发送寻呼消息给RNC，RNC寻呼通过发送寻呼消息寻呼MS。
3）如果没有CS通路MS建立RRC连接。
4）MS发送Service Request（P-TMSI，RAI，CKSN，Service Type）消息给SGSN。服务类型 为寻呼响应。此时，SGSN 可能发起一个鉴权。SGSN 知道下行包是否需要RAB重建。
5）SGSN 指定加密模式。
6）如果PDP上下文的资源重建，SGSN 发送Radio Access Bearer Assignment Request （ RAB?ID(s)，TEID(s)，QoS Profile(s)，SGSN IP Address(es)）消息给RNC。RNC 发送Ra dio Bearer Setup （RAB?ID(s)）消息给MS。MS发送Radio Bearer Setup Complete消息给 RNC。RNC发送Radio Access Bearer Assignment Response（RAB?ID(s)，TEID(s)，RNC I P Address(es)）消息给SGSN，指明GTP隧道已经建立在Iu接口，并且无线接入承载已经在
RNC和MS之间建立。如果RNC回应的Radio Access Bearer Assignment Response消息中的原
因值是要求的QoS无法提供。“Requested Maximum Bit Rate not Available”，那么SGS N将发送新的Radio Access Bearer Assignment Request消息携带 不同的QoS。重试的次数 与新的QoS参数和产品实现相关 。
7）对于每一个RAB重建修改QoS，SGSN会发起一个PDP上下文修改过程通知MS和GGSN新的 Q oS。
8）SGSN发送下行包。
如果服务类型为寻呼响应，MS在收到RRC 的安全模式控制消息后，认为服务请求已经被SG
SN成功的收到了。
如果SGSN重建RAB(s)失败，SGSN将会发起一个修改过程。
6.7 呼叫控制
6.7.1 移动起始呼叫建立
当UE想发起一个呼叫时，UE要使用无线接口信令与网络建立通信，并发送一个包含有被叫
用户号码的消息，即Iu接口上的SETUP消息。CN将建立一个到该UE的通信信道，并使用取到 的被叫方UERN创建一个IAM/IAI消息发送到被叫方（值得注意的是本局内呼叫无IAM/IAI， 该消息只存在于E接口）。
图6-38 移动起始呼叫建立过程
1）UE在随机访问信道上发送CHANNEL REQUEST消息给网络。
2）网络回应IMMEDIATE ASSIGNMENT消息，使得UE可占用指定的专用信道。
3）UE向CN发初始服务请求消息CM SERVICE REQUEST。
4）网络将发起鉴权和加密过程。
5）在发送SECURITY MODE COMPLETE消息之后，UE通过发送SETUP消息给移动台而发起呼叫 的建立过程。
6）网络将回CALL PROCEEDING消息。
7）对于早指配，在网络发起固定网络的呼叫建立之前要为UE分配一个通信信道。
8）当被叫振铃时，网络收到被叫的振玲消息ALERTING以后，则要向主叫UE发一个ALERTIN G消息，同时给主叫送回铃音。
9）当被叫方应答后，将发送一个CONNECT消息给网络，网络再将其传给主叫侧。
10）当从主叫UE回CONNECT ACKNOWLEDGE消息之后即完成了呼叫建立的过程。
6.7.2 移动终止呼叫的建立
移动终止呼叫用于移动用户做被叫时的情况，此时由网络发起呼叫的建立过程。
若CN收到IAM/IAI消息或在本局内取到MSRN以后，如果允许该到来的呼叫建立，则CN要使用 无线接口信令寻呼UE。当UE以PAGING RESPONSE消息回应，CN收到后即建立一个到UE的通信 信道。
图6-39 移动终止建立过程
1）CN向RNS发送一个PAGING消息，RNS在寻呼信道上广播该寻呼消息。可以参考6.6.4的寻 呼过程。
2）被叫UE监测到该寻呼，将向RNS发送一个信道请求，RNS回应立即指配命令，指示UE使用 指定的信令信道。
3）然后UE将在该信令信道上发送一个寻呼响应消息，CN收到UE的寻呼响应消息后，将发起 鉴权和加密的安全过程（请注意这两个安全过程是可选的，可以由MAP功能流程进行配置）
。
4）CN将发送SETUP消息给RNS，该消息中包含有该呼叫的承载能力及发起此次呼叫的主叫号 码。
5）当UE从RNS接收到SETUP消息，它将回应一个CALL CONFIRMED消息。如果协商的承载能力 参数有变化，则该消息中要包含有承载能力信息。
6）当CN从RNS接收到CALL CONFIRMED消息时，CN将向RNS发送RAB ASSIGNMENT REQ消息要求
进行无线信道的指配，RNS将通过向UE发指配消息命令UE调节到一个指定的通信信道上，U E调到指定的信道上之后，将向RNS发送指配完成消息。
7）RNS向CN发RAB ASSIGNMENT RESPONSE消息。
8）UE发送ALERTING消息指示被叫用户振铃。
9）当被叫用户应答时，被叫UE将发送一个CONNECT消息经过RNS到CN，
10）CN将给UE回应CONNECT ACKNOWLEDGE消息，呼叫建立过程结束。
6.7.3 RAB流程
1. RAB管理功能
RAB（Radio Access Bearer）定义在UE和CN之间建立。根据签约用户数据、CN业务能力和 UE业务请求的QoS的不同而使用不同的RAB。
RAB ID与NAS绑定信息有关。例如，在电路域，RANAP 层的RAB ID与CC子层的SI在数值上相 同。SI由UE来分配，CN在分配RAB ID时把SI和RAB ID一一对应起来。对一个UE来说，RAB ID在RB（Radio Bearer）和Iu承载上是全局的，而且一个RAB ID对应一个唯一的用户面连 接的实例（一个Iu UP实例）。
CN控制RAB的建立、修改和释放。RAB建立、修改和释放是CN发起的功能。RAB建立、修改和 释放是UTRAN执行的功能。RAB释放请求是UTRAN发起的功能（当UTRAN不能与UE保持RAB时触
发该功能）。
在RAB建立时CN把RAB映射到Uu接口承载上。UTRAN把RAB映射到Uu接口传输承载和Iu接口传
输承载上。
在CS域如果使用AAL2承载，UTRAN负责发起AAL2连接建立和释放。
RAB的优先级由CN根据签约信息、QoS信息等内容决定。CN在请求RAB建立、修改消息中指定 优先级、预占能力和排队特性。UTRAN执行RAB排队和资源预占。
2. RAB接入控制
当CN接收到请求建立或修改RAB时（在R99电路域规范中RAB QoS用BC IE来映射），CN验证 是否该用户允许使用请求参数的RAB，根据验证CN将接受或拒绝该请求。
当UTRAN从CN接收到建立或修改RAB的请求时，准入控制实体根据当时的无线资源条件的分 析判断是否接受或拒绝。
3. RAB建立，释放，修改控制流程
图6-40 Iu接口RAB Assignment 过程
RAB Assignment过程的目的是修改和/或释放已经建立的RAB，和/或建立新的RAB。 本过程 是面向连接的。
CN首先发送RAB Assignment Request消息给RNC，然后CN启动定时器TRABAssgt。在一条R AB Assignment Request消息中，CN可以要求UTRAN建立/修改/释放一个或几个RABs，本消 息包含以下信息，主要是：
带有承载特性的需建立/修改的RAB列表；
需释放的RAB列表；
RAB ID在每一个Iu连接内是唯一的。如果RNC收到的消息中包括已经存在的RAB ID，那么R NC认为是修改该RAB（释放除外）。
RNC随时接收释放RAB的消息，并总是响应。如果RNC正在建立/修改某RAB，然后又收到释放 该RAB的消息，那么RNC将停止RAB配置过程，释放与该RAB有关的所有资源并返回响应。
UTRAN侧收到消息后将执行请求的RAB配置，然后UTRAN发送RAB Assignment Response消 息给CN报告请求结果。在一条RAB Assignment Response消息中可以包含一个或几个RAB的 信息，主要是：
成功建立/修改/释放的RABs；
不成功建立/修改/释放的RABs；
排队的RABs。
如果没有RABs被排队，则CN就停止TRABAssgt，然后RAB Assignment过程就结束于UTRAN侧 。
当请求建立/修改的RABs被排队后，UTRAN就启动定时器TQUEUING，该定时器指定排队等候 建立/修改的最大时间，且监督所有排队的RABs。排队的RABs有如下可能的结果：
建立或修改成功；
建立或修改失败；
由于定时器TQUEUING超时而失败。
在第一条RAB Assignment Response响应消息中，UTRAN报告所有在RAB ASSIGNMENT Req uest消息中涉及的RAB的状态。UTRAN接着在随后的RAB Assignment Response响应消息中报 告排队的RAB状态，除了TQUEUING超时的RAB。当知道所有排队的RAB建立/修改已经成功/失 败后，UTRAN停止TQUEUING，RAB Assignment过程同时结束于CN与UTRAN。
当CN接收到RAB被排队的响应，CN期望在TRABAssgt超时前UTRAN提供排队RAB的结果；否则 ，CN认为RAB Assignment过程结束，并且认为没有报告的RAB配置失败。
在定时器TQUEUING超时的情况下，在UTRAN所有的排队RABs都结束排队，UTRAN在一条RAB Assignment Response消息中报告所有的排队RAB状态。同时在CN侧停止该过程。
4. RAB建立流程
下图简要的描述了在CN和UE之间经过UTRAN而建立RAB的流程。
图6-41 无线接入承载建立-（DCH-DCH 同步建立流程）
这个例子说明了当RRC连接已经建立好以后，在专用传输信道（DCH）RRC状态下建立无线接 入承载RAB（DCH）的过程。
* 时机：
在电路域，在CN接受UE的业务请求（主叫SETUP，被叫的CALL CONFIRM，CONNECT等消息） 后指示需要一条新的AS的承载通道来承载NAS用户数据时发送RAB Assignment Request消息 启动这一过程。
* 过程描述：
1）CN根据签约用户数据、CN业务能力和UE业务请求的QoS决定采用什末样的RAB。通过RAN AP消息Radio Access Bearer Assignment Request（Setup）请求建立RAB。其中的RAB ID 根据SI的值来填充，在电路域重要参数有RAB参数，用户面模式，本端用户面ATM地址，IU 传输标识（BINDING ID）。
2）服务RNC使用ALCAP协议初始化Iu接口数据传输承载的建立。
在电路域使用AAL2承载的情况下（在PS域这一过程不需要）。在AAL2的连接建立请求中使
用SUGR参数将BINDING ID透传给CN，用它完成RAB和数据传输承载的绑定，这一消息中的重 要参数还有：
对端ATM地址，通路识别（PATH ID），通道识别（CID），通路特性，通道特性等。
3）服务RNC在和Node B等重配置好无线链路，完成上下行链路同步后，通过RRC消息Radio Access Bearer Setup 把RAB参数中的子流和子流组合参数和RAB ID等传给UE。
4）服务RNC在收到UE的成功证实RRC消息Radio Bearer Setup Complete和ALCAP过程的成功 建立后向CN证实RAB成功建立。发RANAP消息Radio Bearer Assignment Response到CN。
5）如果用户面是支持模式，报告结果后UTRAN再通过初始化Iu接口用户面。
& 说明：
对于其中和Drfit RNC，Drift Node B的交互的流程，图中没有描述。
对于RACH/FACH - DCH，RACH/FACH - RACH/FACH以及分组域的非同步方式，过程类似。
5. RAB释放流程
图6-42 无线接入承载释放-（DCH - DCH- 同步释放流程）
* 启动时机：
在电路域，在CC层使用该RAB的事物全部结束或RNC请求释放该RAB时启动此过程。
* 过程描述：
1）CN通过发送RANAP消息Radio Access Bearer Assignment Request。（Release)启动RA B释放过程，其中指明是哪一个RAB ID。
2）业务RNC以RANAP消息Radio Access Bearer Assignment Response来证实。
3）业务RNC使用ALCAP协议，如果是AAL2承载，使用AAL2 释放消息来启动和CN之间的Iu数 据传输承载的释放（在PS域这一过程不需要）。
4）业务RNC在释放了和Node B等的链路后，发送RRC消息Radio Bearer Release给UE启动承 载释放过程。
5）业务RNC在收到UE的证实RRC消息Radio Bearer Release Complete后。整个释放过程结 束。
6. RAB修改流程
图6-43 无线接入承载修改（DCH-DCH 同步修改）
* 启动条件：
UE业务切换或速率调整时，CN重配置业务信道以支持业务属性的改变。
* 过程描述：
1）CN通过RANAP消息Radio Access Bearer Assignment Request（Modify）请求修改RAB。 其中的RAB ID根据指明RAB 标识，在电路域重要参数有RAB参数。
2）服务RNC选择哪种参数应该被修改，哪种程序应该被启动。
3）服务RNC使用ALCAP协议修改Iu接口数据传输承载的通道特性。
4）等到Iu接口传输控制面的修改过程成功后，服务RNC在和Node B等修改好无线链路后， 通过RRC消息Radio Bearer Reconfiguration把RAB参数中的子流和子流组合参数和RAB ID 等传给UE。
5，6 ）服务RNC在收到UE的成功证实RRC消息Radio Bearer Setup Complete后向CN证实RA
B成功建立。发RANAP消息Radio Bearer Assignment Response到CN。
7 ）如果用户面是支持模式，报告结果后UTRAN再通过初始化Iu接口用户面。
6.7.4 寻呼流程
寻呼过程是CN向被叫发起的寻呼过程，当CN需要向和被叫用户建立连接时，首先需要通过
寻呼过程找到被叫，寻呼过程的作用就是使CN能够寻呼到被叫用户，寻呼过程通过无连接
信令方式建立。
CN通过向被叫发起PAGING消息来开始寻呼程，PAGING消息应该包含足够的信息以使RNC能够 找到被叫，如果一次寻呼不可及，CN负责通过lu接口重复发寻呼的过程。一般来说，重复
发寻呼的次数已经他们之间的时间间隔可以在CN处控制。
图6-44 成功寻呼流程
1. 寻呼过程
来自主叫的呼叫请求信息CN经过处理后，如果成功的得到了有关被叫用户的信息，寻呼过
程就可以开始。CN需要知道被叫所在的位置区信息，并且取得足够的寻呼信息参数，这样
，CN就可以向被叫发起寻呼。
如果CN没有得到被叫用户的位置区信息，需要通过广播过程向CN下的所有RNC发起寻呼消 息。
CN下发PAGING消息是通过RANAP接口进行的， RANAP接口处理来自CN的PAGING消息，PAGIN G包含的参数包括寻呼是来自CS域还是PS域的，是何种原因引发的寻呼，以及被叫用户的位 置区信息等。由RANAP向被叫所属位置区下RNC发寻呼消息。
当PAGING消息到达RNC后，RNC通过分析寻呼消息的参数取得被叫所在的位置区信，RNC通 过PCCH传送寻呼信息给位置区的UE，如果被叫UE检测到RNC来的寻呼消息， 开始执行NAS信 令过程。
如果寻呼成功，CN会得到寻呼响应消息，否则，CN需要通过lu接口重复发送寻呼消息。
2. UE在RRC 空闲状态的寻呼过程
当RRC处于空闲状态时候，UE 可能会收到来自CS或者PS的寻呼，因为此时UE处于空闲状态 ，CN可以知道该UE的位置区（LAI)信息，因此，寻呼会通过该位置区来下发，这里列出了
LA跨越两个RNC的情况。
图6-45 RRC空闲状态下寻呼过程
1）CN通过发起的寻呼消息，跨过两个RNC到达被寻呼UE。注意此时在IU接口上看到的就是 CN连续发两条PAGING消息，里面所携带的LAI都是一样的，只是DPC分别为两个RNC而已。
2）小区1用Paging?Type 1发起寻呼。
3）小区2用Paging Type 1发起寻呼。
PAGING 消息通过RANAP的到达RNC1，RNC2， RNC通过PCCH传送寻呼信息给位置区的UE， 如 果被叫UE检测到RNC1或者RNC2来的寻呼消息， 开始执行NAS信令过程。
3. UE在RRC连接状态下的寻呼过程
当RRC处于连接状态时候。这种情况在CN为CS域或者PS域两种情况，由于移动性管理的独立 性，有两种可能的解决方案：
1）UTRAN来协调在已存在RRC连接上寻呼请求
2）UE来协调已存在RRC连接上的寻呼请求
以下例子说明在RRC连接状态（CELL_DCH 和 CELL_FACH 状态)执行寻呼UE过程的，由UTRA
N在RRC连接的状态下用DCCH协调寻呼请求的情况。
图6-46 在RRC连接状态（CELL_DCH 和CELL_FACH)下寻呼UE过程
1）CN通过RANAP发送PAGING消息来对UE寻呼。
2）SRNC（Sercing RNC）对RRC（UE）发送消息 Paging Type 2。
& 说明：
Paging Type 1是用于UE空闲时从PCCH上下发；Paging Type 2是用于RRC连接状态时 从DCCH下发，典型情况如UE在PS业务时下发CS的寻呼消息就用Paging Type 2，不过Pagin g Type是由RNC控制的，CN无需知道。
6.7.5 呼叫释放过程
当移动用户通话完毕，主叫方或被叫方挂机的消息要通知到网络侧，进行呼叫的释放过程
。网络侧通过终止PLMN之间或PLMN与别的网络之间的电路交换连接而释放呼叫。
图6-47 移动发起呼叫释放的成功情况
1）移动台挂机之后，移动台通过向网络发送DISCONNECT消息而发起呼叫清除；此时消息里 的释放原因是：Normal Call Clearing。
2）网络接收到该消息之后发送一个RELEASE消息给移动台；
3）移动台发RELEASE COMPLETE消息给网络，如果此时不再需要通信信道，则要执行信道的 释放过程；
4）如果该呼叫是整个Iu连接上的唯一的一个呼叫，则要释放Iu连接。CN向RNS发送IU REL EASE COMMAND消息请求释放Iu连接。
6.8 分组域会话管理流程
6.8.1 SM基本概念
1. SM功能概述
会话管理（SM）的主要目的就是建立、修改和释放分组域承载。它是3GPP协议中连接管理
层（Connection Management）的一个主要的组成部分，位于移动性管理（Mobile Manage ment）和用户面之间，使用GMM子层提供的无应答数据传送服务，向高层----用户面提供连 接管理服务。它一方面完成核心网络SGSN到GGSN之间的隧道建立、修改和释放的控制功能 ，另一方面完成SGSN和RNC/MS之间无线接入承载（Radio Access Bearer）建立、修改和释 放的控制。
2. 术语
1）PDP CONTEXT/PDP ADDRESS
PDP上下文保存了用户面进行隧道转发的所有信息，包括RNC/GGSN的用户面IP地址、隧道标 识和QoS等。
每个GPRS 签约数据包含一个或多个PDP地址，每个PDP地址由MS、SGSN、GGSN中的一个或多 个PDP Context 描述，每个PDP Context存在两种状态（INACTIVE状态和ACTIVE状态），其 状态转换关系见下图。PDP状态指示该PDP地址的数据是否可以传送。 非激活的会话不包含
路由信息，不能进行数据的转发。用户的所有PDP Context都与该用户的MM Context相关联 。
图6-48 PDP状态机模型
2）NSAPI
在MS中NSAPI用于标识一个PDP服务访问点，在SGSN/GGSN中用于标识一个会话。其取值等于
接入层用来标识用户RAB的RAB ID
4）APN解析
Access Point Name，采用标准域名格式。APN包括两部分：网络名（NI）和运营商名（OI
）。在GGSN中用于标识一个指定的外部网和一种服务的ISP，在SGSN中可根据APN通过DNS解 析得到与此APN对应的GGSN地址。
5）QoS协商
会话管理在建立分组传输路由的同时，也必须指定此路由满足的QoS，会话管理过程在MS、
RNC、SGSN、GGSN之间进行QoS协商，使各节点提供的服务质量保持一致。QoS协商的算法是 在签约的QoS、SGSN能提供的最大QoS和其它节点满足的QoS之间取最小值。
3. SM在协议栈中的位置
图6-49 UMTS MS-SGSN的控制面协议
4. 与SM相关的功能实体
(1) RAB管理
RABM（RAB Management）完成RAB的创建、修改、释放和重建的管理功能。
RAB由两部分组成：RNC和SGSN之间的GTP隧道以及RNC与MS之间的无线承载（Radio Bearer ）。RAB ID唯一标识用户的一个RAB。
RAB的建立、修改、释放和重建都是通过RAB ASSIGNMENT过程完成的。
图6-50 RAB管理流程图
流程说明：
1）SGSN向RNC发送RAB Assignment Request（SGSN ADDR，TEIDs，QoS）消息，请求建立、 修改或释放RAB(s)，在指配参数中可指定RAB的无线优先级，是否允许抢占和排队；
2）RNC建立、修改或释放无线承载；
3）RNC向SGSN发送RAB Assignment Response，如果因为QoS的原因指配失败，则要降低Qo S重发指配请求。
如果RAB重建时发生QoS改变，则执行SGSN发起的PDP CONTEXT修改流程，将QoS通知MS和GG
SN。
(2) 隧道管理
隧道管理的主要任务是创建SGSN到GGSN之间的GTP隧道。隧道管理包括创建隧道、修改隧道 、删除隧道和网络侧发起PDP CONTEXT激活的管理。
SM通过PDP CONTEXT的激活、修改、去激活信令流程实现会话管理。PDP CONTEXT激活流程 建立用户面的分组传输路由；PDP CONTEXT修改流程修改激活的PDP CONTEXT的QoS和TFT， 在发生RAU改变时，也需要修改SGSN到GGSN之间的隧道路由；PDP CONTEXT去激活流程用于 拆除激活的PDP CONTEXT。
RNC发起RAB或IU释放之后，SGSN可以保留这些激活的PDP CONTEXT，而不进行去激活。当用 户发起SERVICE REQUEST过程进行RAB的重建时，可以立刻恢复数据传送。
6.8.2 PDP Context激活功能
PDP CONTEXT激活包括MS发起的，网络发起的PDP CONTEXT激活和二次激活（本文只介绍MS 发起的PDP激活流程）。
1. MS发起的PDP Context激活
图6-51 MS发起的PDP CONTEXT激活过程
1）MS向SGSN发送激活请求Activate PDP Context Request （NSAPI，TI， PDP Type，PD P Address，Access Point Name，QoS Requested）。PDP Address指出是动态地址还是静 态地址。如是动态地址，则设为空。
2）执行RAB指配过程；
3）SGSN通过使用PDP Type（optional），PDP Address（optional）， Access Point N
ame（optional）和PDP CONTEXT签约数据来验证Activate PDP Context Request的有效性 ；
SGSN给PDP Context分配TEID，如果使用动态地址，则要求GGSN分配一个动态地址。 SGSN 根据一定的算法选择一个APN，然后向GGSN发创建PDP Context请求。
GGSN为PDP context分配动态地址，计费ID，协商QoS。如果MS要求外部网分配IP地址，则 设为0.0.0.0，在以后外部网分配地址后，执行GGSN发起的PDP CONTEXT修改过程；
4）收到GGSN的CREATE PDP CONTEXT RESPONSE（NSAPI，PDP ADDR，GGSN ADDR，TEID，Qo
S），SGSN将地址，QoS等信息通过Activate PDP Context Accept 发送给MS。
注：在R99的激活流程中，如果GGSN已经降低Qos，并不通知RNC，那么在SGSN的两侧资源使 用并不一致，空口处的资源可能比网络分配的资源还要高，造成空口资源浪费。R4中，SG
SN先与GGSN交互，创建GTP隧道，然后再建立RAB，建完RAB后，是一个可选的更新GGSN流程 （如果在RAB中建立过程中降低QOS，则发起更新流程，将SGSN两侧的资源同步）。
6.8.3 PDP Context修改功能
PDP CONTEXT修改过程包括MS发起的PDP Context修改过程、SGSN发起的PDP Context修改过 程、GGSN发起的PDP Context修改过程和由于RAB/IU释放，SGSN发起PDP CONTEXT修改流程 （本文只介绍MS发起的PDP Context修改过程和SGSN发起的PDP Context修改过程）；修改 参数包括QoS Negotiated、Radio Priority、Packet Flow Id、PDP Address（GGSN发起的 修改过程in case of the GGSN-initiated modification procedure）和TFT（MS发起的修 改过程）。
1. SGSN发起的PDP Context修改
图6-52 SGSN发起的PDP CONTEXT修改过程
1）SGSN发送更新请求Update PDP Context Request（TEID，NSAPI，QoS Negotiated，Tr ace Reference，Trace Type，Trigger Id，OMC Identity）与GGSN协商QoS；
2）GGSN进行QoS协商，向SGSN发送Update PDP Context Response（TEID， QoS Negotiat ed，Cause）；
3）SGSN按QoS选择无线优先级和Packet Flow Id。 向MS发送修改请求Modify PDP Contex t Request（TI，QoS Negotiated，Radio Priority，Packet Flow Id）；
4）MS接受QoS，则向SGSN发送Modify PDP Context Accept，如MS不接受QoS，则发起去活 PDP context过程；
5）执行RAB指配过程修改RAB；
6）如果启动BSS跟踪，则要发引用跟踪消息Invoke Trace（Trace Reference， Trace Ty
pe，Trigger Id，OMC Identity）。
2. MS发起的PDP Context修改
图6-53 MS发起的PDP CONTEXT修改过程
MS发起修改流程的目的是为了改变PDP CONTEXT的QoS或TFT。
1）MS向SGSN发送Modify PDP Context Request（TI，QoS Requested， TFT）消息，请求 修改PDP CONTEXT；
2）SGSN进行QoS协商，发送更新请求Update PDP Context Request（TEID， NSAPI，QoS Negotiated，Trace Reference，Trace Type，Trigger Id，OMC Identity）与GGSN协商Q oS；
3）GGSN进行QoS协商，向SGSN发送Update PDP Context Response（TEID， QoS Negotiat ed，Cause）；
4）执行RAB指配过程修改RAB；
5） SGSN向MS发送Modify PDP Context Accept。
6.8.4 PDP Context去激活功能
PDP Context去激活流程包括MS发起的、SGSN发起的和GGSN发起的PDP Context去激活过程 （本文只介绍MS发起的PDP Context去激活过程和SGSN发起的PDP Context去激活过程）。
1. MS发起的PDP Context去激活
图6-54 MS发起的PDP Context去激活过程
1）MS向SGSN发送去激活请求Deactivate PDP Context Request（TI， Teardown Ind）， Teardown Ind指示是否去激活和指定TI共享地址的激活的PDP CONTEXT。
2）SGSN收到MS的去激活请求，向GGSN发送Delete PDP Context Request （TEID，NSAPI， Teardown Ind）删除GGSN PDP Context；
3）GGSN向SGSN发送Delete PDP Context Response（TEID）；
4）收到Delete PDP Context Response后，然后向MS发送去激活接受应答；
5）SGSN调用RAB指配过程释放RAB；
2. SGSN发起的PDP Context去激活
SGSN发起的去激活通常由于MM释放或各种异常情况引起，例如MS、SGSN、GGSN之间PDP CO NTEXT不一致，RAB重建失败，资源不足等。
图6-55 SGSN发起的PDP Context去激活
1）SGSN向GGSN删除PDP Context请求，Delete PDP Context Request （TEID，NSAPI，Te ardown Ind），Teardown Ind指示是否去激活和指定TI共享地址的激活的PDP CONTEXT。
2）GGSN向SGSN发送Delete PDP Context Response（TEID）；
3）得到GGSN的删除应答后，向MS发送Deactivate PDP Context Request删除MS PDP Cont ext，如果是DETACH引起的PDP CONTEXT去激活，不发此消息；
4）收到MS发来Deactivate PDP Context Accept ；
5）SGSN发起RAB assignment procedure释放RAB。
6.8.5 保留过程和RAB重建
在RNC发起的RAB释放和IU释放时，可以不释放PDP CONTEXT，而是把PDP CONTEXT保留下来 ，不做任何更改，RAB将在以后的Sevice Request过程中重建。
1. MS发起Service request进行RAB重建
当MS有上行的数据传输需求，PDP CONTEXT处于激活状态而RAB不存在时，MS发起Sevice R equest过程为激活的PDP CONTEXT重建RAB。过程描述如下：
图6-56 MS发起Service request进行RAB重建
1）如果没有RRC连接，建立RRC连接；
2）MS向SGSN发送Service Request（P-TMSI，RAI，CKSN，Service Type）消息，Service Type=data；
3）执行安全流程；
4）SGSN向MS发送Service Accept，对用户每个处于激活状态但RAB已释放的PDP CONTEXT进 行RAB的重新建立；
5）如果建立的RAB的QoS发生改变，执行SGSN发起的PDP CONTEXT修改流程将QoS通知MS和G
GSN；
6）MS进行上行数据传送。
2. SGSN发起Service Request过程进行RAB重建
当SGSN收到下行的信令或数据包后，发现用户处于PMM-IDLE状态，则要发起寻呼。MS在收 到寻呼后，发送Sevice Request请求，sevice type=“paging response"。如果是由于SG
SN收到数据包引起的Service Request过程，则要调用RAB Assignment过程 进行RAB重建。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
RRC连接建立流程 RRC连接建立流程 UE处于空闲模式下 处于空闲模式下， UE的非接入层请求建立信令 UE处于空闲模式下，当UE的非接入层请求建立信令 连接时，UE将发起RRC连接建立过程 每个UE 将发起RRC连接建立过程。 UE最多 连接时，UE将发起RRC连接建立过程。每个UE最多 只有一个RRC连接。 只有一个RRC连接。 RRC连接 SRNC接收到UE的 接收到UE REQUEST消 当SRNC接收到UE的RRC CONNECTION REQUEST消 由其无线资源管理模块(RRM) 息，由其无线资源管理模块(RRM)根据特定的算 法确定是接受还是决绝该RRC连接建立请求， RRC连接建立请求 法确定是接受还是决绝该RRC连接建立请求，如果 接受，则再判决是建立在专用信道还是公共信道。 接受，则再判决是建立在专用信道还是公共
信道。 对于RRC连接建立使用不同的信道，则RRC连接建立 对于RRC连接建立使用不同的信道， RRC连接建立 RRC连接建立使用不同的信道 流程也不一样。 流程也不一样。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
1. RRC连接建立在专用信道 连接建立在专用信道 UE NodeB 1. RRC CONNECTION REQUES T
上
S RNC
3. RL S ETUP REQUES ES T
2. 分分RNTI, L1,L2参参
4. RL S ETUP RES PONS E
5. ALCAP建建建同同
6. RRC CONNECTION S ETUP 7. RRC CONNECTION S ETUP COMPLETE
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
信令流程说明： 1)UE在上行CCCH上发送一个RRC Connection Request消 息，请求建立一条RRC连接； 2)SRNC根据RRC连接请求的原因以及系统资源状态，决定 UE建立在专用信道上，并分配RNTI和L1、L2资源； 3)SRNC向Node B发送Radio Link Setup Request消息，请 求Node B分配RRC连接所需的特定无线链路资源； 4)Node B资源准备成功后，向SRNC应答Radio Link Setup Response消息； 5)SRNC使用ALCAP协议发起Iub接口用户面传输承载的建立 ，并完成RNC于NodeB之间的同步过程； 6)SRNC在下行CCCH向UE发送RRC Connection Setup消 息； 7)UE 在上行DCCH向SRNC发送RRC Connection Setup Complete消息。 至此，RRC连接建立过程结束。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
2. RRC连接建立在公共信道上 连接建立在公共信道上 当RRC连接建立在公共信道上时，因为用的是已经建立好的小区公共资源，所 以这里无需建立无线链路和用户面的数据传输承载，其余过程与RRC连接建立 在专用信道相似。 UE N o d eB 1. RRC C O N N EC T IO N REQ U EST 2. 分 分 RN T I, L1,L2 参 参
SRN C
3. RRC C O N N EC T IO N SET U P 4. RRC C O N N EC T IO N SET U P C O M PLET E
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
3.信令建立流程 信令建立流程 信令建立流程是在UE与UTRAN之间的RRC连接建立成功后， UE通过RNC建立与CN的信令连接，也叫“NAS信令建立流程 ”,用于UE与CN的信令交互NAS信息，如鉴权、业务请求、 连接建立等。 UE与CN的交互的信令，对于RNC而言，都是直传消息。RNC 在收到第一条直传消息时，即：初始直传消息(Initial
Direct Transfer),将建立与CN之间的信令连接，该连接建立SCCP 之上。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
UE
S RNC
CN
1.RRC:INITIAL DIRECT TRANSFER 2.RANAP: INITIAL UE MESSAGE(CR) 3.SCCP:CC (Success) 3.SCCP:CC (Failure)
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
具体流程如下： 1)RRC连接建立后，UE通过RRC连接向RNC发送初始直传消息(Initial Direct Transfer),消息中携带UE发送到CN的NAS信息内容。 2)RNC接收到UE的初始直传消息，通过Iu接口向CN发送SCCP连接请求消息 (CR),消息数据为RNC向CN发送的初始UE消息(Inital UE Message),该 消息带有UE发送到CN的消息内容。 3)如果CN准备接受连接请求，则向RNC回SCCP连接证实消息(CC),SCCP 连接建立成功。RNC接收到该消息，确认信令连接建立成功。 4)如果CN不能接受连接请求，则向RNC回SCCP连接拒绝消息(CJ),SCCP 连接建立失败。RNC接收到该消息，确认信令连接建立失败，则发起RRC释放 过程。 信令连接建立成功后，UE发送到CN的消息，通过上行直传消息(Uplink Direct Transfer)发送到RNC,RNC将其转换为直传消息(Direct Transfer )发送到CN;CN发
送到UE的消息，通过直传消息(Direct Transfer)发送 到RNC,RNC将其转换为下行直传消息(Downlink Direct Transfer)发送到 UE。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
4.RAB建立流程 4.RAB建立流程 RAB RAB是指用户平面的承载，用于UE和CN之间传送语音、 数据及多媒体业务。UE首先要完成RRC连接建立，然 后才能建立RAB。 RAB建立是由CN发起，UTRAN执行的功能，基本流程 为： 首先由CN向UTRAN发送RAB指配请求消息，请求UTRAN 建立RAB; UTRAN中的SRNC发起建立Iu接口与Iub接口(Iur接口) 的数据传输承载； SRNC向UE发起RB建立请求； UE完成RB建立，向SRNC回应RB建立完成消息； SRNC向CN应答RAB指配响应消息，结束RAB建立流程。 当RAB建立成功以后，一个基本的呼叫即建立，UE进 入通话过程。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
根据无线资源使用情况(RRC连接建立时的无 线资源状态与RAB建立时的无线资源状态), 可以将RAB的建立流程分成以下三种情况： 1)DCH-DCH:RRC使用DCH,RAB准备使用 DCH; 2)RACH/FACH-RACH/FACH:RRC使用CCH, RAB准备使用CCH; 3)RACH/FACH-DCH:RRC使用CCH,而RAB 准备使用DCH。 下面给出以上不同情况下的RAB建立流程的具 体过程描述
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
4.1DCH4.1DCH-DCH UE当前的RRC状态为专用传输信道(DCH)时，指配 的RAB只能建立在专用传输信道上。根据无线链路 (RL)重配置情况，RAB建立流程可分为同步重配置 RL(DCH-DCH)与异步重配置RL(DCH-DCH)两种情 况，二者的区别在于Node B与UE接收到SRNC下发的配 置消息后，能否立即启用新的配置参数： 同步情况下，Node B与UE在接收到SRNC下发的配置消 息后，不能立即启用新的配置参数，而是从消息中获 取SRNC规定的同步时间，在同步时刻
,同时启用新的 配置参数； 异步情况下，Node B与UE在接收到SRNC下发的配置消 息后，将立即启用新的配置参数。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
4.1.1同步重配置RL 4.1.1同步重配置RL 同步重配置 在DCH-DCH同步情况下，需要SRNC 、Node B 与UE之间同步重配置RL: Node B在接收到SRNC下发的重配置RL消息后， 不能立即启用新的配置参数，而是准备好相 应的无线资源，等待接收到SRNC下发的重配 置执行消息，从消息中获取SRNC规定的同步 时间； UE在接收到SRNC下发的配置消息后，也不能 立即启用新的配置参数，而是从消息中获取 SRNC规定的同步时间； 在SRNC规定的同步时刻，Node B与UE同时启 用新的配置参数。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
下面给出RAB建立流程中DCH-DCH同步重配置RL的过程 UE NodeB S RNC 2. ALCAP建建
CN
1.RANAP: RAB AS IGNMENT REQUES S T 3.RL RECONFIG PRE 4.RL RECONFIG READY 5.ALCAP建建、同同
6.RL RECONFIG COMMIT 7.RRC: RB S ETUP 8.RRC: RB S ETUP COMPLETE 9.RANAP: RAB AS IGNMENT RES S PONS E
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
信令流程说明： 1)CN向UTRAN发送RANAP协议的RAB指配消息Radio Access Bearer Assignment Request,发起RAB建立请求； 2)SRNC接收到RAB建立请求后，将RAB的QoS参数映射为AAL2链路特性参数与 无线资源特性参数，Iu接口的ALCAP根据其中的AAL2链路特性参数发起Iu接口的 用户面传输承载建立过程； 3)SRNC向属下的Node B发送NBAP协议的无线链路重配置准备Radio Link Reconfiguration Prepare消息，请求属下的Node B准备在已有的无线链路上增加 一条(或多条)承载RAB的专用传输信道(DCH); 4)Node B分配相应的资源，然后向所属的SRNC发送Radio Link Reconfiguration Ready消息，通知SRNC无线链路重配置准备完成； 5)SRNC中Iub接口的ALCAP发起Iub接口的用户面传输承载建立过程， Node B 与SRNC通过交换DCH帧协议的上下行同步帧建立同步； 6)SRNC向属下的Node B发送无线链路重配置执行消息Radio Link Reconfiguration Commit; 7)SRNC向UE发送RRC协议的RB建立消息Radio Bearer Setup; 8)UE执行RB建立后，向SRNC发送无线承载建立完成消息Radio Bearer Setup Complete;
9)SRNC接收到无线承载建立完成的消息后，向CN回应RAB指配响应消息Radio Access Bearer Assignment Response,结束RAB建立流程。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
在DCH-DCH异步情况下，不要求SRNC 、Node B与UE之间同步重配置RL: Node B与UE在接收到SRNC下发的配置消息后，将立即起用新的配置参数。
4.1.2异步重配置RL 4.1.2异步重配置RL 异步重配置 NodeB
UE
S RNC 2. ALCAP建建
CN
1. RANAP: RAB AS IGNMENT REQUES S T 3.RL RECONFIG REQ 4.RL RECONFIG RES P 5. ALCAP建建、同同
6.RRC: RB S ETUP 7. RRC: RB S ETUP COMPLETE 8. RANAP: RAB AS IGNMENT RES S PONS E
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
信令流程说明： 1)CN向UTRAN发送RANAP协议的RAB指配消息Radio Access Bearer Assignment Request,发起RAB建立请求； 2)SRNC接收到RAB
建立请求后，将RAB的QoS参数映射为AAL2链路特性参数 与无线资源特性参数，Iu接口的ALCAP根据其中的AAL2链路特性参数发起Iu接 口的用户面传输承载建立过程； 3)在异步情况下，无线重配置无需同步，SRNC向属下的Node B发送NBAP协 议的无线链路重配置请求Radio Link Reconfiguration Request消息，请求属下 的Node B在已有的无线链路上建立新的专用传输信道(DCH); 4)Node B接收到无线链路重配置请求消息后，即分配相应的资源，然后向所 属的SRNC发送Radio Link Reconfiguration Response消息，通知SRNC无线链路 重配置完成； 5)SRNC中Iub接口的ALCAP发起Iub接口的用户面传输承载建立过程， Node B 与SRNC通过交换DCH帧协议的上下行同步帧建立同步； 6)SRNC向UE发送RRC协议的无线承载建立消息Radio Bearer Setup; 7)UE执行RB建立后，向SRNC发送无线承载建立完成消息Radio Bearer Setup Complete; 8)SRNC接收到无线承载建立完成的消息后，向CN回应RAB指配响应消息 Radio Access Bearer Assignment Response,结束RAB建立流程。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
4.2RACH/FACH-DCH RACH/FACHRACH/FACH 当UE的RRC状态在公共信道时，RNC根据RAB指配消息中的QoS参数，可以将指配的 RAB建立在公共信道(RACH/FACH)或专用信道(DCH)上。下面的例子是将指配的 RAB建立在专用信道上：
UE
NodeB
S RNC 2. ALCAP建建
CN
1. RANAP: RAB AS IGNMENT REQUES S T 3. RL S ETUP REQ 4. RL S ETUP RES P 5. ALCAP建建、同同
6. RRC: RB S ETUP 7. RRC:RB S ETUP COMPLETE 8. RANAP: RAB AS IGNMENT RES S PONS E
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
信令流程说明： 1)CN向UTRAN发送RANAP协议的RAB指配消息Radio Access Bearer Assignment Request,发起RAB建立请求； 2)SRNC接收到RAB建立请求后，将RAB的QoS参数映射为AAL2链路特性参 数与无线资源特性参数，Iu接口的ALCAP根据其中的AAL2链路特性参数发起 Iu接口的用户面传输承载建立过程； 3)SRNC向属下的Node B发送无线链路建立请求消息Radio Link Setup Request,建立新的无线链路； 4)Node B分配相应的资源后，向所属的SRNC发送无线链路建立响应消息 Radio Link Setup Response,通知SRNC无线链路建立完成； 5)SRNC中Iub接口的ALCAP发起Iub接口的用户面传输承载建立过程； Node B与SRNC通过交换DCH帧协议的上下行同步帧建立同步； 6)SRNC向UE发送RRC协议的无线承载建立消息Radio Bearer Setup; 7)UE执行RB建立后，向SRNC发送无线承载建立完成消息Radio Bearer Setup Complete; 8
)SRNC接收到无线承载建立完成的消息后，向CN回应RAB指配响应消息 Radio Access Bearer Assignment Response,结束RAB建立流程。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
4.3RACH/FACH4.3RACH/FACH-RACH/FACH UE NodeB S RNC 2. ALCAP建建
CN
1. RANAP: RAB AS IGNMENT REQUES S T
3 . RRC:RB S ETUP 4 . RRC:RB S ETUP COMPLETE 5 . RANAP:RAB AS IGNMENT RES S PONS E
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
信令流程说明： 1)CN向UT
RAN发送RANAP协议的RAB指配消息Radio Access Bearer Assignment Request,发起RAB建立请求； 2)SRNC接收到RAB建立请求后，将RAB的QoS参数映 射为AAL2链路特性参数与无线资源特性参数，Iu接口 的ALCAP根据其中的AAL2链路特性参数发起Iu接口的用 户面传输承载建立过程； 3)SRNC向UE发送RRC协议的无线承载建立消息Radio Bearer Setup; 4)UE执行RB建立后，向SRNC发送无线承载建立完成 消息Radio Bearer Setup Complete; 5)SRNC接收到无线承载建立完成的消息后，向CN回 应RAB指配响应消息Radio Access Bearer Assignment Response,结束RAB建立流程
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
5.RRC连接释放流程 5.RRC连接释放流程
呼叫释放流程也就是RRC连接释放流程。RRC连接释放 流程分为两种类型：UE发起的释放和CN发起的释放。 两种释放类型的区别主要在于高层的呼叫释放请求消息 由谁先发出，但最终的资源释放都是由CN发起的。 当CN决定释放呼叫后，将向SRNC发送IU RELEASE COMMAND消息。SRNC收到该释放命令后，有如下操 作步骤： 1 )向CN返回IU RELEASE COMPLETE消息； 2 )发起IU接口用户面传输承载的释放； 3 )释放RRC连接。 RRC释放就是释放UE和UTRAN之间的信令链路以及全部 无线承载。根据RRC连接所占用的资源情况，可进一步 划分为两类：释放建立在专用信道上的RRC连接和释放 建立在公共信道上的RRC连接。
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
5.1. 释放建立在专用信道上的 释放建立在专用信道上的RRC连接 连接 UE NodeB S RNC
1. RRC:RRC CONNECTION RELEAS E 2. RRC:RRC CONNECTION RELEAS COMPLETE E 3. RL DELETION 4. RL DELETION RES PONS E 5. ALCAP释释
WCDMA非常详细的信令流程,包括信令流程图,信令流程说明。
流程描述： RNC向UE发送RRC连接释放消息RRC Connection Release; UE向RNC返回释放完成消息RRC Connection Release Complete; RNC向NODEB发送无线链路删除消息Radio Radio Deletion,删除NODEB中的无线链路资源； Link Deletion NODEB资源释放完成后，向RNC返回释放完成 消息Radio Link Deletion Response; RNC使用ALCAP协议发起IUB接口用户面传输承 载的释放。 最后RNC再发起本端L2资源的释放。至此， RRC释放过程结束。
