肩颈瑜伽体式图:wcdma基本信令流程

来源:百度文库 编辑:九乡新闻网 时间:2024/04/27 15:32:35

建设我们自己的专业知识宝库
您可以自由地在线创建、修改、完善 
返回:返回上页
WCDMA基本信令流程
基本信令流程
6.1  基本概念
6.1.1  UE状态
UE有两种基本的运行模式:空闲模式和连接模式。上电开始,UE就停留在空闲模式下,通过非接入层标识如IMSI、TMSI或P-TMSI等标志来区分。UTRAN(UMTS(Universal Mobile Telecommunications System陆地无线接入网) Terrestrial Radio Access Network)不保存空闲模式UE的信息,仅能够寻呼一个小区中的所有UE或同一个寻呼时刻的所有UE。
当UE完成RRC(无线资源控制)连接建立时,UE才从空闲模式转移到连接模式:CELL_FACH(Forward Access Channel前)或CELL_DCH状态。UE的连接模式,也叫UE的RRC状态,反映了UE连接的级别以及UE可以使用哪一种传输信道。当RRC连接释放时,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状态。
FACH : Forward Access Channel前向接入信道
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。
UTRA: UTMS陆地无线接入
3. CELL_PCH 状态
PCH: Paging Channel 寻呼信道
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 :UTRAN Registration Area UTRAN 注册区
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的PCCH逻辑信道上发送寻呼请求。
在URA_PCH状态, 没有资源分配给数据传输用。因此,如果UE有数据要传送,需要首先转换到CELL_FACH状态。
6.1.2  寻呼流程
与固定通信不同,移动通信中的通信终端的位置不是固定的,为了建立一次呼叫,核心网(CN)通过Iu接口向UTRAN发送寻呼消息,UTRAN则将CN寻呼消息通过Uu接口上的寻呼过程发送给UE,使得被寻呼的UE发起与CN的信令连接建立过程。
CS:Circuit Switch电路交换
PS:Package Switch 分组交换
当UTRAN收到某个CN域(CS域或PS域)的寻呼消息时,首先需要判断UE是否已经与另一个CN域建立了信令连接。如果没有建立信令连接,那么UTRAN只能知道UE当前所在的服务区,并通过寻呼控制信道将寻呼消息发送给UE,这就是PAGING TYPE 1消息;如果已经建立信令连接,在CELL_DCH或CELL_FACH状态下,UTRAN就可以知道UE当前活动于哪种信道上,并通过专用控制信道(DCCH)将寻呼消息发送给UE,这就是PAGING TYPE 2消息。因此针对UE所处的模式和状态,寻呼可以分为以下两种类型。
1. 寻呼类型
(1) 寻呼空闲模式或PCH状态下的UE
这一类型的寻呼过程使用PCCH(寻呼控制信道)寻呼处于空闲模式、CELL_PCH或URA_PCH状态的UE,用于向被选择的UE发送寻呼信息,其作用有如下三点:
Ÿ          为了建立一次呼叫或一条信令连接,网络侧的高层发起寻呼过程;
Ÿ          为了将UE的状态从CELL_PCH或URA_PCH状态迁移到CELL_FACH状态,UTRAN发起寻呼以触发UE状态的迁移;
-            URA : 注册区
Ÿ          当系统消息发生改变时,UTRAN发起空闲模式、CELL_PCH和URA_PCH状态下的寻呼,以触发UE读取更新后的系统信息。
图6-1  寻呼空闲模式和PCH状态下的UE
UTRAN通过在PCCH上一个适当的寻呼时刻发送一条PAGING TYPE 1消息来启动寻呼过程,该寻呼时刻和UE的IMSI有关。UTRAN可以选择在几个寻呼时机重复寻呼一个UE,以增加UE正确接收寻呼消息的可能。
(2) 寻呼CELL_DCH或CELL_FACH状态下的UE
这一类型的寻呼过程用于向处于连接模式CELL_DCH或CELL_FACH状态的某个UE发送专用寻呼信息。
图6-2  寻呼CELL_DCH或CELL_FACH状态下的UE
对于处于连接模式CELL_DCH或CELL_FACH状态的UE,UTRAN通过在DCCH(专用控制信道)上发送一条PAGING TYPE 2消息来发起专用寻呼过程。这种寻呼也叫做专用寻呼过程。
2. 寻呼过程举例
1)CN发起寻呼,UE处于空闲模式
在这种情况下,UTRAN通过发送PAGING TYPE 1消息来寻呼UE。
2)CN发起寻呼,UE处于连接模式的CELL_DCH或CELL_FACH状态
在这种情况下,UTRAN通过发送PAGING TYPE 2消息来寻呼UE。
3)CN发起寻呼,UE处于连接模式的CELL_PCH或URA_PCH状态
在这种情况下,UTRAN首先通过发送PAGING TYPE 1消息将UE的状态从CELL_PCH或URA_PCH状态迁移到CELL_FACH状态,然后再发送PAGING TYPE 2消息来寻呼UE。
4)UTRAN发起寻呼,UE处于连接模式的CELL_PCH或URA_PCH状态
在这种情况下,UTRAN通过发送PAGING TYPE 1消息来寻呼UE,使得UE迁移到CELL_FACH状态。
6.2  空闲模式下的UE
6.2.1  概述
当UE开机后或在漫游中,它的首要任务就是找到网络并和网络取得联系。只有这样,才能获得网络的服务。因此,空闲模式下UE的行为对于UE是至关重要的。那么,UE是如何完成这个功能的呢?本节就来讲解这个过程。
UE在空闲模式下的行为可以细分为PLMN选择和重选,小区的选择和重选和位置登记。这三个过程之间的关系如图6-3所示。
Figure 6-3  Overall Idle Mode process
当UE开机后,首先应该选择一个PLMN。当选中了一个PLMN后,就开始选择属于这个PLMN的小区。当找到这样的一个小区后,从系统信息(广播)中就可以知道临近小区(neighboring cell)的信息,这样,UE就可以在所有这些小区中选择一个信号最好的小区,驻留下来。紧接着,UE就会发起位置登记过程(attach or location update)。成功后,UE就成功的驻留在这个小区中了。驻留的作用有4个:
Ÿ          使UE可以接受PLMN广播的系统信息。
Ÿ          可以在小区内发起随机接入过程。
Ÿ          可以接收网络的寻呼。
Ÿ          可以接收小区广播业务。
当UE驻留在小区中,并登记成功后,随着UE的移动,当前小区和临近小区的信号强度都在不断变化。UE就要选择一个最合适的小区,这就是小区重选过程。这个最合适的小区不一定是当前信号最好的小区,为什么呢?因为,比如UE处在一个小区的边缘,又在这两个小区之间来回走,恰好这两个小区又是属于不同的LA或者RA。这样,UE就要不停的发起位置更新,即浪费了网络资源,又浪费的UE的能量。因此,在所有小区中重选哪个小区是有一定规则的,这个规则会在节xxx中详细描述。
当UE重选小区,选择了另外一个小区后,发现这个小区属于另外一个LA 或者RA,UE就要发起位置更新过程,使网络获得最新的UE的位置信息。UE是如何知道LA或者RA变化了呢?在系统广播信息中的SIB1中有:CN common GSM-MAP NAS system information和CN domain system information。 CN common GSM-MAP NAS system information中的内容是:
8
7
6
5
4
3
2
1
LAC
octet 1
octet 2
PS domain system information中的内容是:
8
7
6
5
4
3
2
1
RAC
octet 1
Spare
NMO
octet 2
因此,UE是知道LAC/RAC是否改变的。
如果位置登记或者更新不成功,比如当网络拒绝UE时。或者当前的PLMN出了覆盖区,UE可以进行PLMN重选,以选择另外一个可用的PLMN。
6.2.2  PLMN选择和重选
PLMN选择和重选的目的是选择一个可用的(就是能提供正常业务的),最好的PLMN。UE通过什么来达到这一目的呢?UE会维持一个PLMN列表,这些列表将PLMN按照优先级排列,然后从高优先级向下搜索,找到的自然是最高优先级的PLMN。另外,PLMN选择和重选的模式有两种,自动和手动。 简而言之,自动选网就是UE按照PLMN的优先级顺序自动的选择一个PLMN,手动选网呢,将当前的所有可用网络呈现给用户,将权利给用户, 由用户选择一个PLMN。
在这个列表中,RPLMN (registered PLMN)优先级最高。RPLMN就是上次注册成功的PLMN。当UE关机后,怎么才能知道上次登记的是哪个PLMN? 在USIM卡中有两个文件,EFLOCI和EFPSLOCI,EFLOCI的内容是:
Bytes
Description
M/O
Length
1 to 4
TMSI
M
4 bytes
5 to 9
LAI
M
5 bytes
10
RFU
M
1 byte
11
Location update status
M
1 byte
EFPSLOCI的内容是:
Bytes
Description
M/O
Length
1 to 4
P-TMSI
M
4 bytes
5 to 7
P-TMSI signature value
M
3 bytes
8 to13
RAI
M
6 bytes
14
Routing Area update status
M
1 byte
在这两个文件中,LAI(=MCC+MNC+LAC)和/或RAI (=LAI+RAC)就记录了MCC和MNC,就是RPLMN。
无论自动选网还是手动选网,UE开机后,首先就会尝试RPLMN,成功后, 就不会有后续过程。如果不成功,UE就会生成一个PLMN列表(按照优先级):
i)        HPLMN
ii)       在USIM文件“User Controlled PLMN Selector with Access Technology”中的PLMN (这些PLMN在USIM中是按照优先级排列的);
iii)     在USIM文件“Operator Controlled PLMN Selector with Access Technology”中的PLMN (这些PLMN在USIM中是按照优先级排列的);
iv)     信号质量较好的PLMN, 这些PLMN的排列是随机的;
v)      其他的PLMN,以信号质量从高到低的顺序排列。
在USIM卡中,文件EFIMSI记录了IMSI(MCC+MNC+MSIN),UE从这个文件就可以获取HPLMN。
ii) 和 iii)分别是USIM中的文件EFPLMNwAcT和EFOPLMNwACT。iv)和v)是由UE一个频率,一个频率搜索得到的。
UE就按照上述有优先级的PLMN列表一个一个的搜索并尝试位置登记。
由于UMTS是从GSM演进过来的,但两者的接入技术截然不同(GERAN vs. UTRAN),因此对于每一个PLMN需要指明优先选用的接入技术。接入技术的优先级就在“...with Access Technology”文件中指出。如果没有指出,那么一般而言,优先选用的是GERAN。
当UE尝试与网络进行接触时,网络由于种种原因有时会拒绝UE的请求。根据拒绝原因的不同,UE的行为也会截然不同。罗列如下:
#3          Illegal MS
#6          Illegal ME
#8          GPRS services and non-GPRS services not allowed
此时,ME将SIM视为非法,直到SIM拔出或者关机。这种状态和没有SIM的状态基本上是一样的。此时UE仅能提供limited service。在这种状态下,UE仍然需要进行cell reselection,并且当失去覆盖时,进行PLMN reselection。
#2          IMSI unknown in HLR
此时,ME的电路域部分将SIM视为非法,分组域仍然有可能提供正常的业务。根据分组域的状态,UE可能进行或不进行PLMN reselection。
#7          GPRS services not allowed
此时,ME的分组域部分将SIM视为非法,电路域仍然有可能提供正常的业务。根据电路域的状态,UE可能进行或不进行PLMN reselection。
#11         PLMN not allowed
比如中国移动的用户如果尝试注册到中国联通的网络中时,就会收到这个原因。当UE收到这个原因的拒绝时,会将此PLMN加到“forbidden PLMN” 列表中。这个列表同时存在于ME的RAM和SIM卡的EFFPLMN中,在自动模式下,如果不得不选中这个PLMN (比如当前只有这个PLMN的情况),UE发现这个PLMN在“forbidden PLMN”列表中,就不会再尝试登记,节省了网络资源,但limited service还是可以获得的。为什么要将此列表保存在SIM中呢?这样当手机下一次开机时,仍然可以获得这个列表,并不会再尝试登记(自动模式下)。如果一旦中国移动和中国联通实现了漫游,如果将这个PLMN从“forbidden PLMN list”中去掉呢?这就需要使用手动模式。在手动模式下,UE会将当前有覆盖的所有的PLMN都呈现给用户,无论它是否是被禁止的,这样用户就可以选一个被禁止的PLMN。而一个被禁止的PLMN一旦登记成功,将会从“forbidden PLMN”列表中删除,包括SIM中的。
当收到这个原因时,UE就可能发起PLMN reselection以选一个可用的PLMN。
#12         Location area not allowed
#13         Roaming not allowed in this location area
收到这个原因时,UE会将这个LA分别加到“forbidden location areas for regional provision of service”和“forbidden location areas for roaming”列表中。这两个列表和“forbidden PLMN”列表处理有些不同,就是这两个列表在USIM中是不存在的。当UE关机后,这两个列表就会失去。还有一点需要注意的是,这两个原因都是针对整个LA的,包含所有的RA。
当UE收到这个原因的拒绝时,一般可以不进行PLMN reselection,而是等待用户移动,进入一个可以提供服务的LA。
还有其他情况需要进行PLMN reselection吗?有的,下面就是两种典型的情况。
1. 用户重选
无论是在自动模式还是在手动模式,用户都可以请求网络重选。网络重选时, UE也要生成一个PLMN列表,这个列表和上述列表有一些不同。具体内容如下:
在自动模式下,列表是:
i)        HPLMN ;
ii)       在USIM文件“User Controlled PLMN Selector with Access Technology”中的PLMN (这些PLMN在USIM中是按照优先级排列的);
iii)     在USIM文件“Operator Controlled PLMN Selector with Access Technology”中的PLMN (这些PLMN在USIM中是按照优先级排列的);
iv)     信号质量较好的PLMN,这些PLMN的排列是随机的;
v)      其他的PLMN,以信号质量从高到低的顺序排列;
vi)     先前选择的PLMN。
而在手动模式下,PLMN列表和前面的列表是相同的。
2. 用户登记到归属国家的VPLMN
这种情况就是,比如,中国联通的用户登记到中国移动的网络上(如果可以的话)。 由于这些网络的MCC是相同的,只是MNC不同,UE是可以判断出这种情况的。在这种情况下,用户的通信一般而言要付出更多的代价。因此, UE会尽量回到归属网络中。采取的措施是UE周期性的查找归属网络。 这个周期是有SIM规定的,在文件EFHPLMN中定义。当然,如果运营商愿意, 也可以禁止这个功能,此时文件EF HPLMN中的值就是0。
这两个过程其实是比较复杂的,因为,在进行用户重选或者HPLMN搜索时,原有的服务还要正常进行,还要可以发起呼叫或接收寻呼。这就要求UE在不是Paging Occasion的无线帧上进行搜索PLMN的过程,当用户发起呼叫或者需要接收寻呼时,要立刻切换回原来的频率提供服务。
以下图概要的说明了PLMN selection and reselection和location registration过程。为了理解下面的图,一些解释如下:
Allowable PLMN                   一个不在forbidden PLMN列表中的PLMN。
Available PLMN                                 一个满足cell selection准则的PLMN。这个准则将在xxx节描述。
Trying RPLMN                    UE正在尝试在RPLMN上进行位置登记。
On PLMN                           UE已经成功的在一个PLMN上注册。
Trying PLMN                      UE正在尝试在一个PLMN上进行位置登记。
Wait for PLMNs to appear     目前没有Available PLMN,UE正在等待一个新的PLMN出现。
HPLMN search in progress   UE正在尝试发现HPLMN是否存在。
No SIM                                                           SIM不存在,或者ME认为SIM不存在(收到特定的位置登记拒绝原因后)。
Not on PLMN                      UE在选中的PLMN上注册失败。
Updated                             位置登记成功。
Idle, No IMSI                                 UE在收到上述的拒绝原因#3,#6和#8时两个域(CS and PS)都进入,在收到#2和#7时只有相应的域进入此状态,此时,其他域的状态可能是updated,not updated or roaming not allowed。
Roaming not allowed         收到拒绝原因#11,#12和#13后进入。
Not updated                                   不是由于上述两种情况的位置登记失败。比如,其他拒绝原因或者UE无法判断网络是否收到位置登记请求等。
Figure6-4  PLMN Selection State diagram (automatic mode)
Figure6-5  PLMN Selection State diagram (manual mode)
Figure6-6  Location Registration Task State diagram
6.2.2  小区选择和重选
当PLMN选定之后,就要进行小区选择,目的是选择一个属于这个PLMN的信号最好的小区。
首先,如果UE存有这个PLMN的一些相关信息,比如频率,扰码等。UE就会首先使用这些信息进行小区搜索(Stored information cell selection)。这样就可以较快的找到网络。因为,大多数情况,UE都是在同一个地点关机和开机,比如晚上关机,早晨开机等等。这些信息保存在SIM卡中或者在手机的non-volatile memory中。
1. 小区选择
小区选择的过程大致如下:
(1) 小区搜索。
小区搜索的目的是找到一个小区,尽管它可能不属于选择的PLMN的。小区搜索的步骤如下(当然,首先要锁定一个频率):
1.       时隙同步。由于在UTRAN中所有的primary SCH的同步码都是相同的,并且在每个slot的前256chips中发送,每个slot中都是相同的。UE使用一个matched filter或者类似的技术就可以很容易获得时隙同步。
2.       时隙同步后,就要进行帧同步。帧同步是使用secondary SCH的同步码实现的。Secondary SCH的同步码一共有16个,在每个时隙中是不同的,按照在每个时隙中码字的不同形成64组码序列。这64组码序列有一个特性:他们的循环移位后的结果是唯一的。因此UE就使用这64组码序列一个一个的和接收到的信号相关,相关值最大的那个就是这个小区所用的secondary 同步序列,同时也确定了这个小区的扰码组和帧同步。
3.       获得这个小区的primary scrambling code(主扰码)。获取这个码字后,由于CPICH和PCCPCH都使用这个扰码而且他们的信道码是固定的, UE就可以读广播信道了。在上一步骤中,UE获得了本小区的扰码组。这个扰码组中有8个主扰码,UE如何知道系统到底使用了那个?通常, UE就一个一个在CPICH上试,直到找到相关结果最大的一个。这就确定了主扰码。
显然,如果UE已经知道这个小区的一些信息,比如使用那个频率,甚至主扰码,上述b,c步骤就可以大大加速。[cf.25.214,annex C;25.213, sec.5.2.1,sec.5.2.2,sec.5.2.3;25.211,sec.5.3.3.4]
(2) 读广播信道。
UE从上述(1)的步骤3.中获得了PCCPCH的扰码,而PCCPCH的信道码是已知的,在整个UTRAN中是唯一的。UE就可以读广播信道的信息了。
补充材料:
WCDMA系统消息
系统信息在小区或者PLMN范围内的所有UE进行广播,目的是用于告诉UE网络接入层和非接入层的公共信息,以便用户在发起呼叫之前了解网络的配置情况,从而采取适当的方式发起呼叫。
非接入层的信息包括运营商信息、CN域信息等;接入层信息包括位置登记区信息、小区信息、信道信息、小区选择/重选信息等。
系统信息包含MIB(Master Information Block,主信息块)、SB(Scheduling Block,调度块)、SIB(System Information Block,系统信息块)三种。
图4-1 系统信息树形结构
三种系统信息块按照树形结构组织,如图4-1所示。它们的特点和主要内容如下:
l              MIB用于承载一定数目SIB或SB (最多2个SB)的调度信息。MIB还可能包含小区支持的PLMN类型(即GSM和/或ANSI-41)和PLMN ID信息。MIB在BCH上有规则地发送,发送时刻固定。由于BCH映射在PCCPCH物理信道上,因此小区内的UE都可以读取MIB内容,通过读取MIB内容,UE可以知道是否需要更新(或者存储)系统信息。
l              SB用于承载其它SIB的调度信息,当MIB调度资源不够时采用SB调度SIB。调度信息只能存在于MIB和SB中。
l              SIB用于包含实际系统信息,总共有18种类型的SIB 。SIB的调度信息通过MIB或SB承载。
此主题相关图片如下:
图:系统信息监听机制
某一类型的SIB由性质相近的系统信息单元(IE)组合而成。包含动态参数(即变化频繁的系统参数)和静态参数(即变化很少或不变的系统参数)的IE由不同SIB承载。
l              包含动态参数的SIB(SIB7、SIB8、SIB9、SIB14、SIB17),它们的调度时机信息在MIB或SB的调度信息中描述。在每个重复的调度时机,UE都将有规律地读取包含这些动态参数的SIB。
l              包含静态参数的SIB(SIB1-SIB6、SIB10-SIB3、SIB15、SIB16、SIB18),以值标签作为标识。值标签作为调度信息的一部分,包含在MIB或SB中。UE将某类型SIB值标签与最近一次读取的同类型值标签进行比较,若值发生改变,UE将重读该SIB。因此,对于包含静态参数的SIB,UE通过监视MIB,便可以了解这些SIB是否发生了更新。
各类SIB的功能描述如下:
SIB1:包含NAS系统信息(如CN信息)和以及UE在空闲和连接模式下使用的各类定时器和计数器。范围是PLMN。
SIB2:包含URA信息。
SIB3:包含小区选择和重选参数。
SIB4:包含UE在连接模式下的小区选择和重选参数。
SIB5:包含小区公共物理信道的配置参数。
SIB6:包含UE在连接模式下的小区公共和共享物理信道的配置参数。
SIB7:包含快速变化的参数(上行干扰和动态坚持水平(Dynamic persistence level))。
SIB8:包含小区中静态的CPCH信息。仅用于FDD。
SIB9:包含小区中CPCH信息。仅用于FDD。
SIB10:包含UE的DCH由DRAC过程控制的信息。仅用于FDD。
SIB11:包含小区中测量控制信息。
SIB12:包含连接模式下UE测量控制信息。
SIB413:包含ANSI-41有关信息。
SIB14:包含公共和专用物理信道上行外环控制参数。仅用于TDD。
SIB15:包含基于UE的或者UE辅助的定位方法的有关信息。
SIB16:包含无线承载、传输信道和物理信道参数,这些参数将存储在UE(无论空闲还是连接模式)中,在UE切换到UTRAN时使用。范围是PLMN。
SIB17:包含连接模式下配置共享物理信道的快速变化参数。仅用于TDD。
SIB18:包含邻近小区的PLMN标识。
1.       MIB的scheduling information是已知的,即为SIB_POS=0,SIB_REP =8。 UE在SFN=0,8,16, ...的radio frame中就可以读到MIB。UE是如何知道SFN的呢?在SYSTEM INFORMATION消息中,如果此消息是发送在BCH(PCCPCH)上的,消息的第一个域就是SFNprime,它的值就是这个transport block对应的起始SFN。取值是(0, 2, 4, 6, ..., 4094)。     [cf. 25.331,sec.10.2.48]PER编码后它的值是(0..2047)。这样可以节省一个bit。为什么SFN的值是0, 2, 4, ...?因为BCH的TTI是20ms        [cf. 25.302,Annex A],包含两个radio frame,因此SFNprime只能以2为步长。
2.       读到MIB后,UE就可以判断当前找到的PLMN是否就是要找的PLMN,因为在MIB中有PLMN identity域[cf. 25.331, sec. 10.2.48.8.1],如果是, UE就根据MIB中包含的其他SIB的scheduling information,找到其他的SIB并获得其内容。如果不是,UE只好再找下一个频率,又要从头开始这个过程(从小区搜索开始)。
3.       如果当前PLMN是UE要找的PLMN,UE读SIB3,取得“Cell selection and re-selection info”,在这个IE(Cell selection and re-selection info for SIB3/4,25.331,sec.10.3.2.3)中,读Qqualmin,Qrxlevmin和Maximum allowed UL TX power (UE_TXPWR_MAX_RACH),然后按照下列公式计算:
其中:
Squal
Cell Selection quality value, (dB)
Not applicable for TDD cells or GSM cells.
Srxlev
Cell Selection RX level value (dB)
Qqualmeas
Measured cell quality value. The quality of the received signal expressed in CPICH Ec/N0 (dB) for FDD cells. Not applicable for TDD cells or GSM cells.
Qrxlevmeas
Measured cell RX level value. This is received signal, CPICH RSCP for FDD cells (dBm), P-CCPCH RSCP for TDD cells (dBm) and RXLEV for GSM cells (dBm).
Qqualmin
Minimum required quality level in the cell (dB). Not applicable for TDD cells or GSM cells.
Qrxlevmin
Minimum required RX level in the cell. (dBm)
Pcompensation
Max(UE_TXPWR_MAX_RACH  P_MAX, 0) (dB)
UE_TXPWR_MAX_RACH
Maximum TX power level an UE may use when accessing the cell on RACH (read in system information), (dBm)
P_MAX
Maximum RF output power of the UE, (dBm)
如果
则UE认为此小区即为一个suitable cell。驻留下来,并读其他所需要的系统信息,随后UE将发起位置登记过程。
如果不满足上述条件,UE读SIB11 measurement control system information intra-frequency measurement system information intra-frequency cell info list cell info Primary CPICH info,Reference time difference to cell和Cell Selection and Re-selection info for SIB11/12。在CPICH info中,UE可以得到primary scrambling code。UE根据邻区的primary scrambling code,由于CPICH的信道码在整个UTRAN是唯一的,又根据Reference time difference to cell (??),可以很容易测得临区的Qqualmeas和Qrxlevmeas,在IE Cell Selection and Re-selection info for SIB11/12中,UE可以知道临区的Maximum allowed UL TX power,Qqualmin和Qrxlevmin,这样UE就可以算出临区的Squal和Srxlev并判断临区是否满足上述selection criteria。
UE又可以读Inter-frequency measurement system information Inter-frequency cell info list frequency info and cell info cell info,Cell info和上面是一样的。 Frequency info中包含了UARFCN uplink(Nu)和UARFCN downlink(Nd),由这些信息,UE就可以算出邻区的Squal和Srxlev并判断临区是否满足上述selection criteria。
如果UE发现了任何一个邻区满足selection criteria,UE就驻留在此小区中,并读其他所需要的系统信息,随后UE将发起位置登记过程。
如果UE发现没有一个小区满足selection criteria。UE就认为没有覆盖,就会继续PLMN选择和重选过程。
2. 小区重选
UE在空闲模式下,要随时监测当前小区和邻区的信号质量,以选择一个最好的小区提供服务。这就是小区重选过程(cell reselection)。小区重选过程分为有HCS(hierachical cell structure)和没有HCS两种情况。有没有HCS在SIB11 measurement control system information use of HCS指出。有HCS的情况比较复杂,这里就不作介绍了。在没有HCS的情况下:
The UE shall use Squal for FDD cells and Srxlev for TDD as Sx in the following rules.
(1) If Sx  Sintrasearch, UE need not perform intra-frequency measurements.
If Sx Sintrasearch, UE shall perform intra-frequency measurements.
If Sintrasearch, is not sent for serving cell, UE shall perform intra-frequency measurements.
(2) If Sx  Sintersearch, UE need not perform inter-frequency measurements.
If Sx Sintersearch, UE shall perform inter-frequency measurements.
If Sintersearch, is not sent for serving cell, UE shall perform inter-frequency measurements.
(3) If Sx  SsearchRAT n, UE need not perform measurements on cells of RAT n.
If Sx SsearchRAT n, UE shall perform measurements on cells of RAT n.
If SsearchRATm is not sent for serving cell, UE shall perform measurements on cells of RAT m.
Sintrasearch, Sintersearch和SsearchRAT n在SIB31 Cell selection and re-selection info中指出。
当满足上述条件后,UE就要测量邻区,首先要根据“1. 小区选择”所述的方法计算所有小区(包括当前小区和临近小区)的S。在所有S>0的小区中,再按照下面的公式计算R。
其中TOn=0。
下标s表示serving cell, n表示neighbouring cell。
Cell_selection_and_reselection_quality_measure (FDD only)
Choice of measurement (CPICH Ec/N0 or CPICH RSCP) that is used to derive quality measures Qmap,n and Qmap,s, (read in system information).
Qmap,n
Quality of the neighbouring cell, after mapping function is applied, derived from CPICH Ec/N0 or CPICH RSCP for FDD cells, from P-CCPCH RSCP for TDD cells and from RXLEV for GSM cells. For FDD cells, the measurement that is used to derive the quality value is set by the Cell_selection_and_reselection_quality_measure information element.
Qmap,s
Quality of the serving cell, after mapping function is applied, derived from CPICH Ec/N0 or CPICH RSCP for FDD cells and from P-CCPCH RSCP for TDD cells. For FDD cells, the measurement that is used to derive the quality value is set by the Cell_selection_and_reselection_quality_measure information element.
Qmeas_LEV
Quality value. The quality value of the received signal expressed in CPICH_Ec/No or CPICH_RSCP_LEV for FDD cells as set by the Cell_selection_and_reselection_quality_measure information element, P-CCPCH_RSCP_LEV for TDD cells and RXLEV for GSM cells.
Qoffset1s,n
Offset value 1between the two cells considered in the evaluation (read in system information).
Qoffset2s,n,
Offset value 2 between the two cells considered in the evaluation (read in system information).
Qhyst1s
Hysteresis value of the serving cell.
Qhyst2s
Hysteresis value of the serving cell.
Treselections
Time-to-trigger for cell reselection, (s)
UE首先测量当前小区的RSCP结果记录在Qmeas_LEV中,如果SIB3 Cell selection and re-selection info mapping info存在,UE需要根据mapping info将Qmeas_LEV映射到Qmap中,为什么要映射呢?因为对于既有FDD,又有TDD, GSM的覆盖区域,不同radio access technology之间的信号强度无法直接比较, 就需要将他们映射到统一的标准上来。如果一个小区和邻区都是同一种接入技术,比如都是FDD,映射功能就不需要了,此时,Mapping info不存在, Qmap = Qmeas_LEV。根据上述方法测得的Qmap就是Qmap,s。Qmap,n的测量方法和上面是一样的。
Qhyst1s 在SIB3 Cell selection and reselection info中。
Qoffset1s,n在SIB11 Measurement control system information Intra-frequency measurement system information Intra-frequency cell info list cell info Cell Selection and Re-selection info等中。
UE根据上述公式计算出Rs和Rn,选一个值最大的小区。如果这个小区是TDD的或者是GSM的,UE就直接重选这个小区。
如果这个小区是FDD的,还要麻烦一些。UE要读当前小区的Cell_selection_and_reselection_quality_measure在SIB3 Cell selection and re-selection info中。如果Cell_selection_and_reselection_quality_measure指定的是RSCP,那么这个小区就被选择。如果Cell_selection_and_reselection_quality_measure指定的是Ec/N0,UE需要重新计算R,此时Qmeas_LEV。是Ec/N0的测量值,不再是RSCP的测量值。同时由于只是在所有FDD小区中重选,Qmap = Qmeas_LEV。 Qhyst2s和Qoffset2s,n被使用而不是Qhyst1s和Qoffset1s,n被,他们在系统信息的位置和Qhyst1s,Qoffset1s,n是一样的。
如果在Treselection时间内,上述criteria仍然得到满足,UE就选择这个小区, 驻留下来,读它的广播消息。 小区重选结束。
3. 离开连接模式的小区选择
当UE从连接模式回到空闲模式时,要做小区选择,以找一个合适的小区(suitable cell)。这个选择过程和普通的小区选择过程是一样的。不过此时候选小区就是连接模式时用到的小区。如果在这些小区中找不到合适的小区,应该使用stored information cell selection。
4. 任意小区选择
任意小区选择的意思就是随便选择一个小区,只要它满足criteria S即可。在这种情况下,UE进入limited service状态。
图5表明了小区选择和重选的大致过程。
为了理解这些过程,一些名词解释如下:
Suitable Cell:                 是一个UE可以在其中获得正常服务(normal service)的小区。
Acceptable Cell:                   满足cell selection的criteria S,但只能获得受限服务(limited service)的小区。
Camped normally                 UE驻留在小区中,可以获得normal service。这个小区一定是suitable cell。
Camped on any cell        UE驻留在小区中,可以获得limited service。这个小区一定是acceptable cell。
Figure6-7  Idle Mode Cell Selection and Reselection
In any state, a new PLMN selection causes an exit to number 1
6.2.3  位置登记
这些过程请参见MM,GMM的过程。
6.3  无线资源管理流程
6.3.1  RRC连接建立流程
UE处于空闲模式下,当UE的非接入层请求建立信令连接时,UE将发起RRC连接建立过程。每个UE最多只有一个RRC连接。
当SRNC接收到UE的RRC CONNECTION  REQUEST消息,由其无线资源管理模块(RRM)根据特定的算法确定是接受还是决绝该RRC连接建立请求,如果接受,则再判决是建立在专用信道还是公共信道。对于RRC连接建立使用不同的信道,则RRC连接建立流程也不一样。
1. RRC连接建立在专用信道上
图6-8  RRC连接建立在专用信道上
信令流程说明:
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连接建立过程结束。
2. RRC连接建立在公共信道上
当RRC连接建立在公共信道上时,因为用的是已经建立好的小区公共资源,所以这里无需建立无线链路和用户面的数据传输承载,其余过程与RRC连接建立在专用信道相似。
图6-9  RRC连接建立在公共信道
6.3.2  信令建立流程
信令建立流程是在UE与UTRAN之间的RRC连接建立成功后,UE通过RNC建立与CN的信令连接,也叫“NAS信令建立流程”,用于UE与CN的信令交互NAS信息,如鉴权、业务请求、连接建立等。
UE与CN的交互的信令,对于RNC而言,都是直传消息。RNC在收到第一条直传消息时,即:初始直传消息(Initial Direct Transfer),将建立与CN之间的信令连接,该连接建立SCCP(signalling connection control part)之上。流程如图6-10所示:
RANAPLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL:
Radio Acesss Network Aplication Part
图6-10  信令建立过程
具体流程如下:
1)      1)RRC连接建立后,UE通过RRC连接向RNC发送初始直传消息(Initial Direct Transfer),消息中携带UE发送到CN的NAS信息内容。
2)      2)RNC接收到UE的初始直传消息,通过Iu接口向CN发送SCCP连接请求消息(CR),消息数据为RNC向CN发送的初始UE消息(Inital UE Message),该消息带有UE发送到CN的消息内容。
3)      3)如果CN准备接受连接请求,则向RNC回SCCP连接证实消息(CC),SCCP连接建立成功。RNC接收到该消息,确认信令连接建立成功。
4)      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。
6.3.3  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进入通话过程。
根据无线资源使用情况(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-11  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 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建立流程。
(2) 异步重配置RL
在DCH-DCH异步情况下,不要求SRNC 、Node B与UE之间同步重配置RL:Node B与UE在接收到SRNC下发的配置消息后,将立即起用新的配置参数。
下面给出RAB建立流程中DCH-DCH异步重配置RL的例子。
图6-12  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 Bearer Assignment Response,结束RAB建立流程。
2. RACH/FACH-DCH
当UE的RRC状态在公共信道时,RNC根据RAB指配消息中的QoS参数,可以将指配的RAB建立在公共信道(RACH/FACH)或专用信道(DCH)上。下面的例子是将指配的RAB建立在专用信道上:
图6-13  RAB建立流程(RACH/FACH-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发送无线链路建立请求消息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建立流程。
3. RACH/FACH-RACH/FACH
下面给出了指配的RAB建立在公共信道上的例子:
图6-14  RAB建立流程(RACH/FACH-RACH/FACH)
信令流程说明:
1)CN向UTRAN发送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建立流程。
6.3.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-15  释放建立在专用信道上的RRC连接
流程描述:
1)      RNC向UE发送RRC连接释放消息RRC Connection Release;
2)      UE向RNC返回释放完成消息RRC Connection Release Complete;
3)      RNC向NODEB发送无线链路删除消息Radio Link Deletion,删除NODEB中的无线链路资源;
4)      NODEB资源释放完成后,向RNC返回释放完成消息Radio Link Deletion Response;
5)      RNC使用ALCAP协议发起IUB接口用户面传输承载的释放。
最后RNC再发起本端L2资源的释放。至此,RRC释放过程结束。
2. 释放建立在公共信道上的RRC连接
释放建立在公共信道上的RRC连接时,因为此时用的是小区公共资源,所以直接释放UE就可以了,无需释放NODEB的资源,当然也没有数据传输承载的释放过程。
图6-16  释放建立在公共信道上的RRC连接
6.3.5  切换流程
切换过程是移动通讯区别于固定通讯的一个显著特征之一, 当UE使用的小区或制式(FDD ,TDD)发生变化时, 我们就说UE发生了切换。 WCDMA支持的切换包括软切换, 硬切换,前向切换和系统间切换。  软切换和硬切换主要是由网络侧发起,前向切换主要是UE发起,而系统间切换既有网络侧发起的情况,又有UE发起的情况。发生切换的原因包括UE的移动,资源的优化配置,人为干预等。
1. 软切换
在WCDMA中,由于相邻小区存在同频的情况,UE 可以通过多条无线链路与网络进行通讯,在多条无线链路进行合并的时候,通过比较,选取信号较好的一条,从而达到优化通讯质量的目的,只有FDD制式才能进行软切换。根据小区之间位置的不同,软切换可以分为以下几种情况。
(1) NODEB内不同小区之间
图6-17  NODEB内部的软切换
这种情况, 无线链路可以在NODEB内,也可以到SRNC再进行合并,如果在NODEB内部就完成了合并, 我们称之为更软切换。
(2) 不同NODEB之间
图6-18  不同NODEB之间的软切换
(3) 不同RNC之间
图6-19  不同RNC之间的软切换
软切换中一个重要问题就是多条无线链路的合并,WCDMA中使用宏分集(MACRO DIVERSITY)技术对无线链路进行合并,就是根据一定的标准(如误码率)对来自不同无线链路的数据进行比较,选取质量较好的数据发给上层。
在软切换中,关于邻近小区有几个重要的概念:
1 )活动集, 指的是UE当前正在使用的小区的集合,软切换的执行结果就表现在活动集中小区增加或减少。
2 )观察集, UE根据UTRAN给的邻近小区信息,正在观察但不在活动集中的小区,UE对观察集中的小区进行测量,当测量结果符合一定的条件时,这些小区可能被加入活动集,所以有时也称为候选集;
3 )已检测集,UE已检测到,但既不属于活动集也不属于观察集的小区,UTRAN可以要求UE报告已检测集的测量结果;由于它们不属于邻近小区列表,所以有时也称之为未列出集。
软切换的过程可以分为以下几个步骤:
1 )UE根据RNC给的测量控制信息, 对同频的邻近小区进行测量,测量结果经过处理后,上报给RNC;
2 )RNC对上报的测量结果和设定的阀值进行比较,确定哪些小区应该增加,哪些应该删除;
3 )如果有小区需要增加,先通知NODEB准备好;
4 )RNC通过活动集更新消息,通知UE增加和/或删除小区;
5 )在UE成功进行了活动集更新后,如果删除了小区,则通知NODEB释放相应的资源。
在进行软切换的过程中,原来的通讯不受影响,所以能够完成从一个小区到另一个小区的平滑切换。
2. 硬切换
当邻近小区属于异频小区时,不能进行软切换,这时可以进行硬切换,硬切换过程就是先中断跟原来小区的通讯,然后再从新的小区接进来,因此它的性能不如软切换,所以一般在不能进行软切换的时候,才会考虑硬切换。
硬切换的目标小区可以没有经过测量,适合于, 紧急情况下的硬切换,失败率较高;更常见的硬切换同样也要对目标小区先进行测量,但一般UE只配一个解码器,不能同时对两个频点的信号进行解码,所以为了UE能进行异频测量,在WCDMA中引入了压缩模式技术。
图6-20  压缩模式原理图
压缩模式技术的基本原理就是,NODEB在发送某些帧(每10ms 发送的数据为一帧)的时候,加大发送速率,用少于10ms的时间发送完原来需要10ms的数据,那么空出来的时间,就让UE进行异频测量。具体采用什么方式和什么时间来加大发送速率,由RNC进行控制。
跟软切换类似,硬切换根据原小区和目标小区的位置关系,分为以下几种:
1)同一个小区内,FDD和TDD方式之间的硬切换;
2 ) NODEB内的小区之间;
3 )不同NODEB的小区之间;
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)。
下图以物理信道重配置为例给出不同NODEB之间小区硬切换的信令过程:
图6-21  硬切换流程图
信令流程描述:
1)SRNC向目标小区所在的NODEB发送消息Radio Link Setup Request,要求其建立一条无线链路;
2)目标小区所在的NODEB向SRNC应答消息Radio Link Setup Response,表明无线链路建立成功;
3)SRNC采用ALCAP协议建立SRNC和目标NODEB的IUB接口传输承载,并且进行FP同步;
4)SRNC通过下行DCCH信道向UE发送消息Physical Channel Reconfiguration,消息中给出目标小区的信息;
5)在UE从原小区切换到目标小区后,原小区NODEB会检测到无线链路失去联系,于是向SRNC发消息Radio Link Failure Indication,指示无线链路失败;
6)UE在成功切换到目标小区后,通过DCCH向SRNC发送消息Physical Channel Reconfiguration Complete,通知SRNC物理信道重配置完成;
7)SRNC向原小区所在的NODEB发送消息Radio Link Deletion Request,删除原小区的无线链路;
8)原小区所在的NODEB完成无线链路资源删除后,向SRNC应答消息Radio Link Deletion Response;
9)SRNC采用ALCAP协议释放SRNC和原小区所在NODEB的IUB接口的传输承载。
3. 前向切换
RRC连接移动性管理中,前向切换是其中的一部分。前向切换分为小区更新和URA更新,主要用于当UE位置发生改变时及时更新UTRAN侧关于UE的信息,还可以监视RRC的连接、切换RRC的连接状态,另外还有错误通报和传递信息的作用。不管是小区更新还是URA更新,更新过程均是由UE主动发起的。
Ÿ          小区更新
处于CELL_FACH、CELL_PCH或URA_PCH状态的UE都可能发起小区更新过程,对不同的连接状态,会有不同的小区更新原因,小区更新流程也不同。
1. 如果小区更新原因是周期性小区更新,且UTRAN侧不给UE分配新的CRNTI或URNTI,其流程如图6-22所示:
图6-22  小区更新过程
具体流程如下:
1)UE从CCCH向UTRAN发送CELL UPDATE消息。
2)UTRAN收到UE的CELL UPDATE消息处理完成后给UE发应答消息CELL UPDATE CONFIRM。UTRAN侧结束本次小区更新。UE收到CELL UPDATE CONFIRM消息后结束本次小区更新。
2. 如果小区更新的原因是因为有上行数据传输,或者是对寻呼的响应,UTRAN侧没有给UE分配CRNTI或URNTI,也没有指示相关物理信道信息,并且UE中保存的TFS/TFCS与系统信息中广播的PRACH/SCCPCH的TFS/TFCS相同;如果小区更新的原因是因为有上行数据,或者是对寻呼的响应,或者是小区重选,UTRAN侧给UE分配了CRNTI或URNTI,但没有指示相关物理信道信息,并且UE中保存的TFS/TFCS与系统信息中广播的PRACH/SCCPCH的TFS/TFCS相同,其流程如图6-23所示:
图6-23  小区更新过程(伴随有物理信道重配置)
具体流程如下:
1)UE从CCCH向UTRAN发送CELL UPDATE消息。
2)UTRAN收到UE的CELL UPDATE消息处理完成后给UE发应答消息CELL UPDATE CONFIRM,并等待UE的应答消息。
3)UE收到CELL UPDATE CONFIRM消息后,向UTRAN发PHYSICAL CHANNEL RECONFIGURATION COMPLETE消息,UE侧结束本次小区更新。UTRAN侧收到UE的PHYSICAL CHANNEL RECONFIGURATION COMPLETE消息后结束本次小区更新。
3. 如果小区更新的原因是因为有上行数据传输,或者是对寻呼的响应,UTRAN侧没有给UE分配CRNTI或URNTI,也没有指示相关物理信道信息,并且UE中保存的TFS/TFCS与系统信息中广播的PRACH/SCCPCH的TFS/TFCS不同;如果小区更新的原因是因为有上行数据,或者是对寻呼的响应,或者是小区重选,UTRAN侧给UE分配了CRNTI或URNTI,但没有指示相关物理信道信息,并且UE中保存的TFS/TFCS与系统信息中广播的PRACH/SCCPCH的TFS/TFCS不同,其流程如图6-24所示:
图6-24  小区更新过程(伴随有传输信道重配置)
具体流程如下:
1)UE从CCCH向UTRAN发送CELL UPDATE消息。
2)UTRAN收到UE的CELL UPDATE消息处理完成后给UE发应答消息CELL UPDATE CONFIRM,并等待UE的应答消息。
3)UE收到CELL UPDATE CONFIRM消息后,向UTRAN发TRANSPORT CHANNEL RECONFIGURATION COMPLETE消息,UE侧结束本次小区更新。UTRAN侧收到UE的TRANSPORT CHANNEL RECONFIGURATION COMPLETE消息后结束本次小区更新。
4. 如果小区更新原因是周期性,UTRAN侧给UE分配了CRNTI或URNTI,但没有指示相关物理信道信息,UE将更新其标识,其流程如图6-25所示:
图6-25  小区更新过程(伴随有RNTI重分配)
具体流程如下:
1)UE从CCCH向UTRAN发送CELL UPDATE消息。
2)UTRAN收到UE的CELL UPDATE消息处理完成后给UE发应答消息CELL UPDATE CONFIRM,并等待UE的应答消息。
3)UE收到CELL UPDATE CONFIRM消息后,向RNTI REALLOCTION COMPLETE消息,UE侧结束本次小区更新。UTRAN侧收到UE的RNTI REALLOCTION COMPLETE消息后结束本次小区更新。
Ÿ          URA更新
URA更新过程的目的是处于URA_PCH状态下的UE经过URA再选择后用现在的URA更新UTRAN;在没有URA再选择发生时该过程也可以用来监视RRC连接。一个小区中可以广播几个不同的URA ID,在一个小区中不同的UE可以属于不同的URA。当UE处于URA_PCH状态时有且仅有一个有效的URA。处于URA_PCH状态时,如果分配给UE的URA不在小区中广播的URA ID列表中,则UE将发起URA更新过程。或者UE在服务区内,但T306超时,则UE将发起URA更新过程。
1. 如果URA更新过程中UTRAN没有给UE分配新的CRNTI或URNTI其流程如图6-26所示:
图6-26  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更新。
2. 如果URA更新过程中UTRAN给UE分配了新的CRNTI或URNTI其流程如图6-27所示:
图6-27  URA更新过程(分配了新的CRNTI或URNTI)
具体流程如下:
1)UE从CCCH向UTRAN发起URA UPDATE消息。
2)UTRAN收到UE的URA UPDATE消息处理完成后给UE发应答消息URA UPDATE CONFIRM,并等待UE的消息应答。
3)UE收到URA UPDATE CONFIRM消息后,更新CRNTI或URNTI,并向UTRAN发RNTI REALLOCTION COMPLETE消息,并结束本次URA更新。UTRAN侧收到UE的RNTI REALLOCTION COMPLETE消息后,结束本次URA更新。
4. 系统间切换
WCDMA支持UE在UTRAN和现存系统(如GSM/GPRS)之间进行切换,可以分为网络控制下的切换(如GSM)和UE的小区重选(如GPRS)二种情况,它们各自又可分为入UTRAN和出UTRAN两种情况;下面我们分为四种情况对系统间切换的信令过程进行介绍,这里只介绍UTRAN中的信令。
Ÿ          迁入UTRAN
图6-28  迁入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消息。
Ÿ          迁出UTRAN
当RNC认为有必要时,可以首先进行前面提到的压缩模式控制,让UE进行异系统测量,在信号比较好的时候,进行系统间切换。
图6-29  迁出UTRAN流程图
信令流程描述:
1)UTRAN向CN发Relocation Required消息,要求对方系统为系统间切换做好准备;
2)CN向UTRAN发Relocation Command消息, 表示对方已准备好;
3)UTRAN向UE发送Inter-System Handover Command消息,要求UE进行系统间切换。
在UE进行系统间切换失败的时候,会向UTRAN 发送Inter-System Handover Failure消息,继续使用原来的信道。
Ÿ          UE小区重选出UTRAN
对于电路域,UE的小区重选在UTRAN中没有什么特殊的信令,但是对于支持无损迁移的分组域RAB,有一组信令来处理缓存的分组数组的转发。
图6-30  小区重选出UTRAN流程图
信令流程描述:
1)CN向UTRAN发送消息SRNS Context Request,要求其给出数据转发所需的GTP-U和PDCP序列号信息;
2)UTRAN向CN返回消息SRNS Context Response,其中包含为每条RAB准备的转发数据的起始序列号;
3)CN向UTRAN发送消息SRNS Data Forward Command,要求UTRAN开始启动缓存的分组数据的转发。
5. UE小区重选入UTRAN
开始的接入和正常的连接没什么区别,但在RAB指配消息中,CN会给出PDCP和GTP-U的序列号, UTRAN用这些序列号来配置用户面,以使用户面能够接收从其它系统(如GPRS)转发过来的分组数据。
补充材料:
介绍WCDMA频内测量与频间测量的区别
Active set: 激活集: 指与某个移动台建立连接的小区集合。用户信息从这些小区发送。
Monitor set 检测集:不在激活集中,但是根据UTRAN分配的相邻节点列表而被监测的小区。
Detected set 检测集:即不在激活集中,也不在检测集中的小区。
检测集的报告是由在CELL_DCH状态的UE所做的频内测量所要求的。
频内测量与频间测量区别如下:(在测试跟踪信令会出现这些内容)
频内测量内容:
1)频内测量小区信息列表
2)频内测量数值(CPICH、Ec/No、CPICH RSCP、RSSI/pathloss)
3)频内测量报告数值
4)报告小区状态
5)测量有效性(有效的UE状态)可选
6)报告准则(频内测量报告准则、周期性测量报告准则、不报告)
频内测量报告的触发事件:
1A:CELL 进入报告范围。
1B:CELL  离开报告范围。
1C:有CELL的信号优于有效集罪差CELL.
1D:最优CELL改变。
1E:一个CELL的导频信号优于绝对门限值。
1F:一个CELL的导频信号差于绝对门限值。
频间测量内容:
1)   频间测量小区信息列表
2)   频间测量数值(CPICH Ec/No、CPICH RSCP )
3)   频内测量报告数值(RSSI、频率质量估计、小区报告信息)
4)   报告小区状态
5)   测量有效性(有效的UE状态)可选
6)   频间集更新
7)   报告准则(频间测量报告准则、频内测量报告准则、周期性测量报告准则、不报告)
频间测量报告的触发事件:
2A::最佳载频发生改变,即有非当前载频的信号质量高于当前载频的信号质量
2B::当前使用的载频信号质量低于一门限值,并且一个未使用的估计质量高于一门限值。
2C::某个未使用载频的信号质量高于某一门限值。
2D:当前载频信号质量低于某个门限值。
2E:某个非当前载频信号质量低于某个门限值。
2F:当前载频信号质量高于某个门限值。
系统测量:
3A:当前使用的UTRAN频率的估计质量低于某一门限,并且其他系统的估计质量高于某一门限。(P-CPICH)
3B:其它系统的估计质量高于某一门限。(P-CPICH)
3D:其他系统内的最佳小区更新。
业务测量:
4A:RLC缓冲负荷超过某一门限。
4B:RLC缓冲负荷低于某一门限。
UE内部测量:
6A-6G,
几个概念:
CPICH RSCP:接收信号码功率,测量得到的是码字功率。如果PCPICH采用发射分集,手机对每个小区的发射天线分别进行接收码功率测量,并加权和为总的接收码功率值。(手机发起-RNC)。
CPICH Eb/No:每码片的接收能量除以带内的功率密度的值,Eb/No的值与RSCP/RSSI相同,测量对象是主CPICH。如果主CPICH采用发射分集,手机对每个小区的发射天线单独进行码片接收能量的测量,并合并为总计码片接收功率,然后进行Eb/No计算。(手机发起-RNC)
UTRA 载波RSSI:接收信号强度指示,相应信道带宽的接收功率,测量对象是UTRAN下行链路的载波。(手机发起-RNC)。
掉话原因要根据测量数据进行分析,是否进入小区切换过程或产生干扰等。  3GPP 25.133 25.101.
6.3.6  RNC迁移
RNC迁移指UE的服务RNC从一个RNC变成另一个RNC的过程,根据发生迁移时UE所处位置的不同可以分为静态迁移和伴随迁移两种情况,或者说UE不涉及的(UE Not Involved)和UE涉及的(UE Involved)。
1. 静态迁移
发生静态迁移的条件是UE从一个DRNC,而且只从一个DRNC中接入。由于迁移过程不需要UE的参与,所以也称之为UE不涉及的(UE Not Involved)迁移,下面给出一个存在两条无线链路的例子。发生迁移之后,原来的DRNC变成了SRNC,IUR接口的连接被释放,IU接口发生迁移,如图6-31所示。
图6-31  静态迁移过程
在WCDMA中由于存在两个CN域,如果在发生迁移的时候,UE和两个域都有连接,那么这两个域必须同时迁移。下面给出静态迁移的信令流程图6-32所示:
图6-32  静态迁移信令流程图
信令流图描述:
1)SRNC向SGSN(PS域的CN)发送迁移请求消息Relocation Required;
2)SRNC向MSC(CS域的CN)发送迁移请求Relocation Required;
3)SGSN向DRNC发送消息Relocation Request,要求DRNC做好迁移准备(即准备所需资源);
4)MSC向DRNC发送消息Relocation Request,要求DRNC 做好迁移准备(即准备所需资源);
5)DRNC采用ALCAP协议发起电路域IU接口用户面承载的建立;
6)DRNC向SGSN发送消息Relocation Request Acknowledge,通知SGSN迁移所需的资源已经准备好;
7)DRNC 向MSC发送消息Relocation Request Acknowledge,通知MSC迁移所需的资源已经准备好;
8)SGSN向SRNC发送消息Relocation Command,通知SRNC可以进行迁移了;
9)MSC 向SRNC发送消息Relocation Command,通知SRNC可以进行迁移了;
10)SRNC通过IUR接口向DRNC发送迁移触发消息Relocation Commit。如果存在支持无损迁移的RAB,那么数据转发所需的PDCP和GTP-U的序列号从这条消息带过去,然后SRNC就启动数据转发;
11)DRNC向SGSN发送消息Relocation Detect,通知SGSN检测到迁移触发;
12)DRNC 向MSC发送消息Relocation Detect,通知MSC检测到迁移触发;
13)DRNC向UE发送消息URNTI Reallocation,要求UE修改U-RNTI值;
14)UE向DRNC发送消息URNTI Reallocation Complete,通知DRNC修改完成, 至此,DRNC转换成SRNC的角色;
15)DRNC向SGSN发送消息Relocation Complete,通知SGSN迁移已成功结束;
16)DRNC向MSC发送消息Relocation Complete,通知MSC迁移已成功结束;
17)SGSN向原来的SRNC发送消息Iu Release Command,通知其释放PS域的Iu连接;
18)MSC向原来的SRNC发送消息Iu Release Command,通知其释放CS域的Iu连接;
19)原来的SRNC采用ALCAP协议发起IU接口用户面承载的释放。
2. 伴随迁移
伴随迁移指从UE从SRNC硬切换到目标RNC,同时IU接口发生变化的过程。由于迁移过程需要UE的参与,所以也称之为UE涉及的(UE Involved)迁移。其连接变化情况如图6-33所示:
图6-33  伴随迁移过程
能够完成硬切换的5个信令过程都可以用来完成伴随迁移,下面只给出用物理信道重配置来完成的伴随迁移信令流程图图6-34:
图6-34  伴随迁移信令流程图
信令流图描述:
1)SRNC向SGSN(PS域的CN)发送迁移请求消息Relocation Required;
2)SRNC向MSC(CS域的CN)发送迁移请求Relocation Required;
3)SGSN向DRNC发送消息Relocation Request,要求DRNC做好迁移准备(即准备所需资源);
4)MSC向DRNC发送消息Relocation Request,要求DRNC 做好迁移准备(即准备所需资源);
5)DRNC采用ALCAP协议发起电路域IU接口用户面承载的建立;
6)DRNC向SGSN发送消息Relocation Request Acknowledge,通知SGSN迁移所需的资源已经准备好,并且告知用具体用RB建立、RB释放、RB重配置、传输信道重配置、物理信道重配置过程中的哪一个过程来完成伴随迁移;
7)DRNC 向MSC发送消息Relocation Request Acknowledge,通知MSC迁移所需的资源已经准备好,并且告知用具体用RB建立、RB释放、RB重配置、传输信道重配置、物理信道重配置过程中的哪一个过程来完成伴随迁移;
8)SGSN向SRNC发送消息Relocation Command,通知SRNC可以进行迁移了;
9)MSC 向SRNC发送消息Relocation Command,通知SRNC可以进行迁移了;
10)如果存在支持无损迁移的RAB,则SRNC向SGSN发送消息Forward SRNS Context,希望SGSN把数据转发所需的GTP-U和PDCP序列号送给目标RNC,否则直接至步骤12;
11)如果SGSN收到来自SRNC的Forward SRNS Context消息,则向目标RNC发送消息Forward SRNS Context,其中包含来自SRNC的数据转发所需的GTP-U和PDCP序列号;
12)这里具体发送什么消息是由目标RNC在准备资源时就决定好的,目标通过消息Relocation Request Acknowledge告知SGSN,SGSN再通过消息Relocation Command告知SRNC,这里假设是物理信道重配置(Physical Channel Reconfiguration);
13)UE成功地接入到目标RNC后,给目标RNC发送消息Physical Channel Reconfiguration Complete,目标RNC成为UE的SRNC;
14)目标RNC向SGSN发送消息Relocation Complete,通知SGSN迁移已成功结束;
15)目标RNC向MSC发送消息Relocation Complete,通知MSC迁移已成功结束;
16)SGSN向原来的SRNC发送消息Iu Release Command,通知其释放PS域的Iu连接;
17)MSC向原来的SRNC发送消息Iu Release Command,通知其释放CS域的Iu连接;
18)原来的SRNC采用ALCAP协议发起IU接口用户面承载的释放。
6.4  电路域移动性管理
6.4.1  位置更新
位置更新过程是由HLR、MSC/VLR等实体之间逻辑配合完成。HLR记录移动用户当前位置信息和所有用户数据;VLR记录漫游到由该VLR控制位置区的移动用户的相关用户数据;MSC处理移动用户的位置登记进程,与移动用户对话并与HLR、VLR交互信息。
位置更新包括位置登记、周期性位置登记、用户数据删除等。
——位置登记
引起移动用户发生正常位置登记的条件是:移动设备开机时以及移动用户发生漫游引起位置改变。
——周期性位置登记
通过周期性位置登记(位置更新),PLMN可以保持追踪移动用户当前的状态,特别是保持长时间没有操作的用户与网络的联系。位置更新时间周期和保护时间可以由PLMN运营商根据具体话务和用户习惯来设定调整。
——用户数据删除
指将用户记录从VLR中删除,包括用户漫游产生的用户数据删除、用户长时间无操作引起的用户数据删除、以及系统管理员对无效用户记录所进行的删除。
图6-35是一个典型的位置更新流程图,基本包含了上述三个过程。
图6-35  位置更新流程图
1.       MSC/VLR接收到用户用TMSI发起的位置更新请求后,如果TMSI不认识:若携带的前位置信息为临近VLR的位置区,则发起向PVLR取识别的流程;若前位置区为非临近VLR的位置区或者到PVLR取识别失败,则发起要求手机提供IMSI的流程。要求手机提供IMSI的流程在图中没有画出。
2.       如果用户在本VLR首次位置登记,则发起到HLR的位置更新请求。
3.       HLR接收到MSC/VLR的位置更新请求后,发现如果用户漫游的MSC/VLR号码发生改变,向PVLR发起位置删除流程,删除PVLR中的用户信息。
4.       如果漫游拒绝,HLR直接向MSC/VLR发出携带拒绝信息的位置更新响应;否则首先向MSC/VLR插入用户数据,然后根据插入用户数据的结果,判断是下发位置更新接受还是位置更新拒绝。
6.4.2  去活
去活过程即移动用户关机,MS发起DETACH的流程,MSC/VLR置用户状态为IMSI分离,该流程一般不通知HLR。若该MS被拨打,MSC会将用户关机情况直接通知主叫方。其流程图相当简单,如图6-36:
图6-36  关机流程图
当MS关机时,向网络发出关机信号,MSC/VLR记录用户已经关机。另,有些型号的移动终端,在通话期间直接关电源时,也可以发起DETACH流程。
6.4.3  鉴权流程
一个成功的鉴权过程可以用流程图来表示,如图6-37所示。
图6-37  鉴权成功
鉴权流程由网络侧发起,其目的是:由网络来检查是否允许终端接入网络;提供鉴权参数五元组中的随机数数组,供终端计算出加密密钥(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-38  鉴权失败(失败原因为MAC Failure)
此时,网络侧将根据手机终端上报的用户标识来决定是否发起识别过程。如果当前的标识为TMSI(或P-TMSI),则发起识别流程,要求手机终端上报IMSI信息。然后再次发起鉴权流程。
另外一种鉴权失败的情况是手机终端检测到AUTN消息中的SQN的序列号错误,引起鉴权失败,原因值为:Synch failure!(同步失败)
图6-39  鉴权失败(原因值为Synch failure)
此时,网络侧的VLR将删除所有鉴权参数5元组,并发起到HLR的同步过程,要求HLR 重新插入鉴权参数五元组,然后再开始鉴权过程。
6.4.4  安全模式控制
安全模式控制过程是由网络侧用来向无线接入网侧发送加密信息的。在此过程中,核心网的网络侧将与无线接入网协商对用户终端进行加密的算法,使得用户在后续的业务传递过程中使用此加密算法;并且在终端用户发生切换后,尽可能的仍使用此加密算法——即用于加密的有关参数会送到切换的目的RNC。
其流程图如图6-40所示:
图6-40  安全模式控制
6.4.5  TMSI重分配
TMSI,即临时移动用户识别码,是由LAI(位置区号)和临时分配给指定用户的一串数字组成。TMSI由MSC/VLR管理,当MS首次在一个位置区注册时分配给它,并在MS离开该位置区时注销。TMSI被用来唯一识别一个位置区的MS,取代IMSI在无线信道中传输,从而防止第三方通过窃听无线信道上的信号而识别并跟踪移动用户。TMSI与IMSI(国际移动终端设备标识)的对应关系存放在管理MS当前访问位置区的VLR中,最新分配的TMSI也将存放于MS的SIM卡中。TMSI重分配的实现在用户位置更新和呼叫建立及补充业务等过程都可以执行。
在位置更新时进行的TMSI重分配流程,是与位置更新接受融合在一起的。其流程图如图6-41所示:
图6-41  位置更新时的TMSI重分配
& 说明:
在移动性管理过程中,鉴权、安全模式控制、TMSI重分配等几项流程属于选做流程。这些过程可以由网络运营商来决定是否激活或提供。
6.4.6  联合位置更新
当用户终端所处的位置区与路由区都发生改变时,将发起联合位置更新过程:同时在CS域、PS域发起位置更新。网络侧的CS域与PS域通过Gs接口相连(核心网的电路域、分组域分离组网时,下面的描述中将用MSC来代表CS域,SGSN来代表PS域)。Gs接口采用No.7信令上中的BSSAP+协议,借助Gs接口,CS域和PS域可互相更新数据库里保存的移动台的位置信息,这样可减少空中信令,而且有助于MSC通过Gs接口寻呼到正在进行GPRS业务的B类手机。
图6-42是一个典型的联合位置更新的流程图:
图6-42  联合位置更新
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-43所示。
6.5  分组域移动性管理流程
6.5.1  MM功能概述
移动性管理(MOBILITY MANAGEMENT)和会话管理(SESSION MAMAGEMENT)以及短消息(SHORT MESSAGE SERVICES)共同组成3GPP协议中的连接层,在UMTS系统中,MM处于RANAP层之上,为SM和SMS提供信令传送,实现了用户在网络中的移动性管理。 移动性管理主要完成用户的附着、分离、安全流程、路由区更新、位置更新等功能。
1. 术语介绍
Ÿ          GMM/PMM
GSM和UMTS系统分组业务的移动性管理,本文主要介绍UMTS系统中的分组域的移动性管理特性。
Ÿ          MM CONTEXT
GMM的用户上下文,包括了用户签约数据、鉴权集
GMM在协议栈中的位置
图6-43  UMTS系统下的分组域中手机和网络侧的控制面协议
图6-44  UMTS系统下的分组域移动性管理与相关单元的关系图
GMM与SM之间的原语
Ÿ          GMMSM-RELEASE-IND
Ÿ          GMMSM-UNITDATA-REQ
Ÿ          GMMSM-UNITDATA-IND
PMM和SMS之间的原语
Ÿ          PMMSMS_REL_REQ
Ÿ          PMMSMS_ERROR_IND
Ÿ          PMMSMS_UNITDATA_REQ
Ÿ          PMMSMS_UNITDATA_IND
6.5.2  移动性管理状态
UMTS系统中的分组移动性管理的状态可以分为:PMM-DETACHED、PMM-IDLE、PMM-CONNECTED;在手机侧和网络侧状态信息通过MM移动性管理上下文进行管理。
如图6-45,图中明确的表示移动性管理的状态与会话管理的状态是无关的,也就是移动性管理处在连接态,会话管理可以处在激活态或者非激活态;移动性管理处在空闲态,会话管理可以处在激活态或者非激活态。状态迁移关系描述如下:
1)PMM-DETACHED到PMM-CONNECTED
通过分组域的附着,移动性管理的状态由分离态迁移到连接态;
2)PMM-CONNECTED到PMM-IDLE
通过分组域的信令连接释放,移动性管理的状态由连接态迁移到空闲态;
3)PMM-IDLE到PMM-CONNECTED
通过分组域信令连接的建立,移动性管理的状态由空闲态迁移到连接态;
4)PMM-CONNECTED到PMM-DETACHED
通过分组域的分离或者附着拒绝、路由区更新拒绝,移动性管理的状态由连接态迁移到分离态;
5)PMM-IDLE到PMM-DETACHED
通过隐式的分组域的分离,移动性管理的状态由空闲态迁移到分离态;
6)PMM-CONNECTED到PMM-CONNECTED
在重定位过程中,移动性管理的状态保持在连接态。
注: 在某种错误影响下:可能出现MS和网络侧的状态不同步,通过路由更新过程就可以实现同步。
图6-45  UMTS系统的分组域移动性管理的状态迁移图
6.5.3  GMM的定时器功能
(1) Ready Timer
Ready Timer定时器的概念在UMTS系统中不再存在,如果用户消息中带有协商的Ready Timer定时器,网络侧将其保存,等到发生系统间改变的时候,启用。
(2) Mobile Reachable Timer
网络侧监视手机周期更新的定时器,比手机保存的周期更新定时器略长一些,如果移动性管理的状态进入连接态(PMM-CONEECTED),则该定时器立刻停止;直至移动性管理的状态进入空闲态(PMM-IDLE),重新启动移动台可及定时器。如果Mobile Reachable Timer定时器超时,用户的寻呼允许标志(PPF)被清除。
6.5.4  SGSN和MSC/VLR之间的联系
(1) SGSN和MSC/VLR之间的联系会通过以下的过程建立:
联合GPRS/IMSI附着
已经IMSI附着的用户的GPRS附着
已经GPRS附着的用户的IMSI附着(发生的是联合路由区更新)
(2) 电路域寻呼(CS Paging):
对于一个联合附着的用户,MSC/VLR可以通过SGSN发送电路域寻呼
(3) 非GPRS业务提醒(Non-GPRS Alert):
MSC/VLR要求SGSN通知MSC/VLR手机的活动情况,会将非GPRS业务提醒标志(NGAF)置位,SGSN移动性管理一旦发现该用户活动,立刻通知MSC/VLR,然后清除NGAF。
(4) MS信息过程(MS Information Procedure):
MSC/VLR需要用户的身份信息和位置信息时,可以通过Gs接口从SGSN本地获得或通过SGSN下发信息请求,取得MSC/VLR所需信息。
(5) MM信息过程(MM Information Procedure):
MSC/VLR可以通过SGSN将网络信息发送给用户,SGSN会将信息下传。
6.5.5  MM过程
在UMTS系统中,MM过程是指利用各个接口实现消息的传递,具体的有:通过Iu接口、Gr接口、Gs接口实现消息的传递等。
6.5.6  GPRS附着功能
图6-46  附着附着流程
1)用户通过发送附着请求发起附着流程。用户在附着请求消息中携带有IMSI or P-TMSI and old RAI, Core Network Classmark, KSI, Attach Type, old P-TMSI Signature, Follow On Request, DRX Parameters,如果用户没有合法的P-TMSI,用户会带上IMSI;如果用户有合法的P-TMSI,用户应该使用P-TMSI和配对的路由区标识,同时如果具有P-TMSI签名的话,也应该带上。附着类型指示用户请求执行何种附着过程,即GPRS附着、联合附着以及已经IMSI附着的GPRS附着。DRX参数指示用户是否使用非连续接收和DRX循环周期长度。SGSN可以根据Follow On Request指示,决定在附着结束后,是否释放同用户的分组业务信令连接。
2)如果用户使用P-TMSI附着,并且自上次附着改变了SGSN,新SGSN应该发送身份识别请求给老的SGSN,带上用户的P-TMSI和相应的路由区标识以及老的P-TMSI签名,如果有的话。老SGSN回应身份识别响应消息,包含用户的IMSI和鉴权集。如果用户在老SGSN未知,老SGSN回应消息带上相应的原因值;如果用户的P-TMSI和签名不匹配,老SGSN回应消息带上相应的原因值。
3)如果用户在老SGSN为未知,新SGSN应该发起身份识别请求给用户,身份类型指示IMSI。用户应该报告自己的IMSI给SGSN。
4)如果用户的移动性管理上下文在网络侧不存在,鉴权过程是必须的。如果将要重分配P-TMSI,并且网络支持加密,加密模式应该被设置。
5)移动台设备检查功能定义在身份检查流程中,此功能现均不实现。
6)如果SGSN号码自从上次分离后发生改变,或者是用户的第一次附着,SGSN应该通知HLR。
A.      SGSN发送一条UpdateLocation消息(带有SGSN号码、SGSN地址、IMSI)给HLR;
B.      HLR发送Cancel Location(带有IMSI、取消类型)消息给老的SGSN同时置取消类型为Update Procedure;
C.      老SGSN以Cancel Location Ack(带有IMSI)消息确认收到HLR的Cancel Location。如果该用户有任何正在进行中的流程,老SGSN应该等待这些流程结束,然后才能删除用户的MM上下文和PDP上下文;
D.     HLR发送插入用户签约数据消息(带有IMSI、GPRS签约数据)给新SGSN;
E.      新SGSN证实用户存在于新的路由区中,如果用户签约数据限制用户在此路由区附着,SGSN应该拒绝用户的附着请求,带以恰当的原因值,同时可以回应插入签约数据确认消息给HLR。如果签约数据检查由于其他原因失败,SGSN应该拒绝用户附着请求,带上合适的原因值,同时回应HLR插入签约数据确认消息(带有IMSI、原因值)。如果所有签约数据检查通过,SGSN为用户构造MM上下文,同时回应HLR插入签约数据确认消息(带有IMSI)。
F.      HLR在删除旧的MM上下文和插入新的MM上下文完成后,发送Update Location Ack消息给SGSN确认SGSN的Update Location消息。如果Update Location被HLR拒绝,SGSN带上合适的原因值拒绝用户的附着请求。
7)如果在步骤1中的附着类型指示已经IMSI附着的用户进行GPRS附着,或者联合附着,那么VLR应该被更新,如果配置了Gs接口的话。VLR号码可以从路由区信息导出。SGSN在上面的步骤6d),即收到HLR的第一次插入用户签约数据消息时,就可以开始Location Update流程,这将导致用户在VLR中被标记上GPRS附着。
G.     SGSN发送Location Update消息(带有新的位置区标识LAI、IMSI、SGSN号码、Location Update Type),Location Update Type指示IMSI附着,如果用户附着类型是联合附着的话;否则,Location Update Type 应该指示正常Location Update。VLR通过储存SGSN的号码创建和SGSN的关联;
H.      如果位置区更新发生在MSC之间,新的VLR发送Update Location消息(IMSI、新的VLR号码)给HLR;
I.        如果位置区更新发生于MSC之间,HLR发送Cancel Location(带有IMSI)消息给老VLR;
J.       老VLR以Cancel Location Ack消息确认(带有IMSI);
K.      如果位置区更新发生在MSC之间,HLR发送插入用户签约数据消息给新的VLR;
L.      VLR以插入签约数据确认消息(带有IMSI)确认。
M.    在完成MSC间的Location Update 流程后,HLR以Update Location Ack消息(带有IMSI)给新的VLR;
N.     VLR回应Location Update Accept(带有VLR 号码、TMSI)消息给SGSN;
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.5.7  分离功能
1. MS发起的分离
图6-47  MS发起的分离
1)用户发送分离请求消息(带有Detach Type,P-TMSI,P-TMSI Signature, Switch Off)给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. 网络侧发起的分离
图6-48  网络侧发起的分离过程
1)SGSN以分离请求消息(带有分离类型)通知用户已经被分离。分离类型指示用户是否被要求重新附着和重新激活原先分离前激活的PDP上下文。如果是,在分离完成后,附着流程将会发起。
2)SGSN通知GGSN删除PDP上下文请求消息(带有TEID),以通知GGSN去活该用户激活的PDP上下文。GGSN以删除PDP上下文响应消息确认SGSN的删除请求。
3)如果用户是联合附着,SGSN应该发送GPRS分离指示消息(带有用户IMSI)通知VLR。VLR去除和SGSN的关联,不再通过SGSN进行寻呼和位置区更新。
4)用户可能在收到SGSN的分离请求后的任何时候发送分离接受消息给SGSN。
5)在收到用户的分离接受消息后,如果分离类型不要求用户重新附着,那么SGSN将释放分组域的信令连接。
3. HLR发起的分离过程
图6-49  HLR发起的分离过程
1)如果HLR要立即从SGSN删除签约用户的MM上下文和PDP上下文,HLR应该发送Cancel Location(带有IMSI、Cancellation Type)消息给SGSN,同时置Cancellation Type 为Subscription Withdrawn。
2)SGSN以分离请求消息(带有分离类型)通知用户已经被分离。分离类型指示用户是否被要求重新附着和重新激活分离前原激活的PDP上下文。
3)SGSN通知GGSN删除PDP上下文请求消息(带有TEID),以通知GGSN去活该用户激活的PDP上下文。GGSN以删除PDP上下文响应消息确认SGSN的删除请求。
4)如果用户是联合附着,SGSN应该发送GPRS分离指示消息(带有用户IMSI)通知VLR。VLR去除和SGSN的关联,不再通过SGSN进行寻呼和位置区更新。
5)用户可能在收到SGSN的分离请求后的任何时候发送分离接受消息给SGSN。
6)SGSN应该以Cancel Location Ack消息(带有IMSI)确认MM上下文和PDP上下文的删除。
7)在收到用户的分离接受消息后,如果分离类型不要求用户重新附着,那么SGSN将释放分组域的信令连接。
6.5.8  安全流程
1. 鉴权加密
图6-50  鉴权加密
1)如果SGSN没有以前存储的UMTS五元鉴权组,向HLR发出一条发送鉴权信息(IMSI)消息。收到此消息,HLR/AUC以鉴权信息确认消息给予回应,包含顺序排放的五元组。每一个五元组包含RAND、XRES、AUTN、CK和IK。五元鉴权组的产生见3G TS 33.102.
2)在对UMTS用户进行鉴权时,SGSN选择下一组五元组并且包含属于这个五元组的RAND和AUTN于鉴权和加密请求消息中给用户。SGSN还选择一个CKSN包含于消息中。
3)在收到这个消息时,用户手机中的USIM验证AUTN,如果接受,根据协议33.102计算出RAND的签名RES。如果USIM认为鉴权成功,用户返回鉴权和加密响应消息(RES)给SGSN。同时,手机中的USIM也计算出CK、IK,这些秘钥同CKSN一起保存,直到CKSN在下一次鉴权后被更新。
如果USIM认为鉴权不成功,例如鉴权同步错误,用户返回鉴权和加密失败消息给SGSN。
2. 用户标识保密
网络通常不直接使用用户的标识IMSI,在SGSN和MS之间使用由SGSN给MS分配的PTMSI作为用户的临时标识,在MS和UTRAN之间,使用RNTI,临时标识可以通过重分配保证随机性,避免泄漏用户标识。
图6-51  PTMSI充分配
1)SGSN发送P-TMSI重分配命令(带有新的P-TMSI、P-TMSI签名、RAI)给用户。P-TMSI签名是一个可选参数,如果用户收到,应该在下一次附着或路由更新流程中使用。
2)用户返回P-TMSI重分配完成消息给SGSN。
3. 用户数据和信令的保密
图6-52  加密范围
从上图中可以看出:UMTS的加密范围比GPRS减少,仅仅在MS和UTRAN之间实现。
4. 用户标识检查
图6-53  用户标识检查
1)SGSN发送身份识别请求消息(身份类型)给用户,用户回应身份识别响应消息(用户的身份标识)。在UMTS系统中,用户可以选择发送他的加密的IMSI,即FFS。
2)如果SGSN决定检查IMEI,它发送检查IMEI消息(带有用户的IMEI)给EIR,EIR回应检查IMEI确认消息(带有用户的IMEI)。
5. 数据完整性算法
完整性算法在UTRAN和MS之间实现,通过加密模式的指定开始执行。
6.5.9  位置管理功能
1. 路由区更新
图6-54  路由区更新
1)如果没有RRC连接,先建立RRC连接。用户发送路由区更新请求消息(带有P-TMSI、老RAI、老P-TMSI签名、路由更新类型、跟随请求、classmark、DRX参数)给新的SGSN。如果用户有上传的信令或数据,跟随请求应该被置上。作为实现上的选择,SGSN可以根据跟随请求标志,决定在路由更新流程结束后是否释放Iu连接。路由区更新类型应该指示:
路由区更新--如果流程因为路由区改变引起;
周期性路由区更新--如果流程因为周期性路由区更新定时器超时引起;
联合路由区更新--如果用户是IMSI附着的,并且位置区更新应该在网络操作模式I情况下进行;
联合路由区更新伴随IMSI附着--如果用户想要在网络操作模式I下进行IMSI附着;
服务RNC应该在将消息转发给SGSN前加上用户所在位置所属的路由区标识(包括路由区编码和位置区编码)。路由区标识对应于服务RNC发给用户的MM系统信息中的RAI. ClassMark见类标处理章节的描述。DRX指示用户是否使用非连续接收模式和DRX循环周期长度。
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。老的SGSN在它的上下文中标记MSC/VLR关联、GGSN和HLR中的信息为非法。如果在未完成正在进行的路由更新前,用户发起路由更新回到老SGSN,这将引起MSC/VLR、GGSN、HLR被刷新。
5)如果是SGSN间的路由更新,并且用户处于PMM-IDLE状态,新SGSN发送修改PDP上下文请求消息(新SGSN地址、协商的QOS、TEID)给相关的GGSN。GGSN更新它的PDP上下文,回应修改PDP上下文响应消息(TEID)给SGSN。如果发起SGSN间路由区更新的用户处于PMM-CONNECTED状态,修改PDP上下文的消息见"重定位"章节描述。
6)如果是SGSN间的路由区更新,SGSN以Update Location消息(SGSN号码、SGSN地址、IMSI)通知HLR SGSN的改变。
7)如果是SGSN间的路由区更新,HLR发送Cancel Location(带有IMSI、取消类型)消息给老的SGSN同时置取消类型为Update Procedure。如果步骤2中的定时器没有运行,老SGSN清除MM上下文。否则,上下文直到定时器超时才删除。这是为了确保用户的上下文保留在老的SGSN中以防用户在完成路由区更新之前,发起另一个SGSN间的路由区更新。老的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。如果路由区更新类型是联合路由区更新伴随IMSI附着,位置区更新类型应该指示IMSI附着。否则,位置区更新类型应该指示正常位置区更新。VLR的号码是通过以RAI查询SGSN中的表得到。SGSN在上面的步骤8,即收到HLR的第一次插入用户签约数据消息时,就可以开始Location Update流程。VLR创建或者更新同SGSN的关联通过存储SGSN号码。
11)如果在VLR中的用户签约数据被标记为未被HLR证实,新VLR将通知HLR。HLR删除老的VLR的数据,插入用户签约数据到新的VLR。(这个信令同目前的GSM信令一样,包含于此处用于注解):
A.      新VLR发送Update Location消息(带有新的VLR号码)给HLR。
B.      HLR发送Cancel Location消息(IMSI)给老的VLR,删除老VLR中的数据;
C.      老VLR以Cancel Location Ack消息确认(带有IMSI);
D.     HLR发送插入用户签约数据消息(IMSI、用户签约数据)给新的VLR;
E.      VLR以插入用户签约数据确认消息(带有IMSI)确认;
F.      HLR以Update Location Ack消息(带有IMSI)给新的VLR。
12)新VLR分配新的TMSI,回应Location Update Accept(带有VLR 号码、TMSI)消息给SGSN,如果VLR没有改变,TMSI分配是可选的。
13)新SGSN证实用户存在于新的路由区中,如果签约数据限制用户在此路由区附着或者签约数据检查失败,SGSN应该拒绝用户附着请求,带上合适的原因值。如果所有签约数据检查通过,SGSN为用户构造MM上下文。新SGSN回应用户路由更新接受消息(带有P-TMSI、VLRTMSI、P-TMSI签名)。
14)用户以附着完成消息给SGSN确认新分配的TMSI。
15)如果TMSI发生改变,SGSN发生TMSI重分配完成消息给VLR以确认重分配的TMSI。
如果附着请求不能被接受,SGSN回送附着拒绝消息(带有IMSI、Cause)给用户。
注意:步骤11、12和15仅当步骤9发生时才发生。
6.5.10  重定位
1. 软切换
图6-55   SGSN之间软切换
1)源SRNC决定发起一个SRNS重定位。
2)源SRNC通过向旧SGSN发送一个RELOCATION REQUIRED 消息(Relocation Type, Cause, Source ID, Target ID, Source RNC to target RNC transparent container),开始了重定位准备阶段,源RNC将该重定位类型置为“UE NOT INVOVED”。 Source RNC to target RNC transparent container包含了重定位所需的一些必要信息,安全功能以及RRC协议上下文信息(包含UE能力)。
3)旧SGSN根据目标RNC的ID来决定是否是SGSN之间的重定位还是SGSN内部的重定位。如果是SGSN之间的重定位,旧SGSN通过向新SGSN发送Forward Relocation Request 消息(IMSI,Tunnel Endpoint Identifier Signalling,MM Context,PDP Context,Target Identification, UTRAN transparent container, RANAP Cause)开始重定位资源分配过程。同时在旧SGSN的MM上下文和PDP上下文中启动一个定时器。该消息仅在SGSN之间重定位中才有。
4)新SGSN向目标RNC发送 Relocation Request 消息(Permanent NAS UE Identity,Cause,CN Domain Indicator,Source RNC to target RNC transparent container,RABs to be setup)。对于每个要建立的RAB,RABs to be setup包含RAB ID,RAB parameters,Transport Layer Address,and Iu Transport Association等信息。The RAB ID information element 包含NSAPI value。RAB parameters information element 则给出了QoS 信息。Transport Layer Address是旧SGSN为数据传输提供的地址。Iu Transport Association对应着TEID。在所有资源分配好之后,目标RNC将向新SGSN发送Relocation Request Acknowledge 消息(RABs setup,RABs failed to setup)。
5)当新SGSN和目标RNC之间的资源分配好之后,新SGSN向旧SGSN发送重定位响应消息Forward Relocation Response 消息(Cause,RANAP Cause,and RAB Setup Information)。该消息表明目标RNC已经准备好从源RNC接受未被MS确认的下行数据,也就是,重定位资源分配过程已经成功结束。RANAP Cause是从目标RNC到源RNC的信息,RAB Setup Information包含为数据转发所需要的RNC的TEID以及IP地址。如果目标RNC或者新SGSN未能成功分配资源,则 RAB Setup Information只包含NSAPI,意味着通知源RNC释放和NSAPI 对应的资源。该消息仅用于SGSN之间的重定位。
6)旧SGSN向源RNC发送Relocation Command 消息(RABs to be released, and RABs subject to data forwarding)消息,旧SGSN根据Qos决定要转发数据的RAB。 对于每个要转发的RAB,IE包含contain RAB ID,Transport Layer Address,以及 Iu Transport Association、Transport Layer Address 和 Iu Transport Association用来转发从源RNC到目标RNC的下行N-PDU。
7)收到从PS域发送的Relocation Command 消息后,源RNC将启动定时器,当重定位准备阶段成功结束后,源SRNC通过向目标RNC发送Relocation Commit 消息(SRNS Contexts)发起执行relocation of SRNS。该流程的目标是在源和目标RNC之间传送SRNS上下文。
8)发送完Relocation Commit消息后,源RNC开始为每个要进行数据转发的RAB转发数据。 SRNS重定位的数据转发通过Iu接口,这表明在源SRNC和目标RNC转发的数据在源SRNC备份,通过IP层路由再到目标RNC。
9)当接受到重定位触发消息后,目标RNC将向新SGSN发送Relocation Detect 消息。对于重定位类型为“UE not involved”来说,重定位触发是在从Iur接口收到重定位提交消息。当发送了Relocation Detect message,目标RNC将开始SRNC操作。
10)发送完Relocation Detect 消息后,目标RNC向MS发送RNTI Reallocation 消息。消息中包含UE信息以及CN信息。 UE信息包含new SRNC identity 和 S-RNTI。CN信息包含位置区标识和路由区标识。
11)CN收到Relocation Detect 消息后,CN把用户面从源RNC转移到目标RNC。如果是SGSN之间的重定位,新SGSN将向GGSN发送Update PDP Context Request 消息(new SGSN Address,SGSN Tunnel Endpoint Identifier,QoS Negotiated)消息,GGSN更新PDP上下文,返回Update PDP Context Response 消息(GGSN Tunnel Endpoint Identifier)。
12)当MS重新组装后,向目标RNC发送RNTI Reallocation Complete 消息,然后开始交换数据。
13)当目标RNC接收到RNTI Reallocation Complete 消息后,向新SGSN发送重定位完成消息。如果是SGSN之间重定位,新SGSN向旧SGSN发送重定位完成消息,旧SGSN收到后给新SGSN响应消息。
14)当收到新SGSN的Forword Relocation Complete消息后,旧SGSN向新SGSN响应后,则向源RNC发送IU RELEASE COMMAND 消息,当RNC的数据转发定时器超时,源RNC向旧SGSN发送IU RELEASE CMP消息。
15)如果新的路由区和旧路由区不一样,MS将发起RAU过程,该重定位流程仅仅是RAU的一个子集。
2. 硬切换
图6-56  SGSN之间硬切换
1)基于UTRAN拓扑信息和测量结果,源SRNC决定发起一个联合硬切换以及SRNS重定位。
2)源SRNC通过向旧SGSN发送一个RELOCATION REQUIRED 消息(Relocation Type,Cause,Source ID,Target ID,Source RNC to target RNC transparent container),开始了重定位准备阶段,源RNC将该重定位类型置为“UE  INVOVED”。Source RNC to target RNC transparent container包含了重定位所需的一些必要信息,安全功能以及RRC协议上下文信息(包含UE能力)。
3)旧SGSN根据目标RNC的ID来决定是否是SGSN之间的重定位还是SGSN内部的重定位。如果是SGSN之间的重定位,旧SGSN通过向新SGSN发送Forward Relocation Request 消息(IMSI,Tunnel Endpoint Identifier Signalling,MM Context,PDP Context,Target Identification, UTRAN transparent container, RANAP Cause)开始重定位资源分配过程。同时在旧SGSN的MM和PDP上下文中启动一个定时器。该消息仅在SGSN之间重定位中才有。
4)新SGSN向目标RNC发送 Relocation Request 消息(Permanent NAS UE Identity,Cause,CN Domain Indicator,Source RNC to target RNC transparent container,RABs to be setup)。对于每个要建立的RAB,RABs to be setup包含RAB ID,RAB parameters,Transport Layer Address,and Iu Transport Association等信息。The RAB ID 信息单元包含NSAPI value。RAB parameters 信息单元则给出了QoS 信息。Transport Layer Address是旧SGSN为数据传输提供的地址。Iu Transport Association对应着TEID。 在所有为接受RAB的资源(包含Iu用户面)分配好之后,目标RNC将向新SGSN发送Relocation Request Acknowledge 消息(RABs setup, RABs failed to setup),目标RNC为每个要建立的RAB(由IP地址和TEID组成)既接受从源SRNC的下行PDUs,也接受从新SGSN的下行PDUs。
5)当新SGSN和目标RNC之间的资源分配好之后,新SGSN准备开始进行relocation of SRNS。新SGSN向旧SGSN发送Forward Relocation Response 消息(Cause,RANAP Cause,and RAB Setup Information)。该消息表明目标RNC已经准备好从源RNC接受未被MS确认的下行数据,也就是,重定位资源分配过程已经成功结束。 RANAP Cause是从目标RNC到源RNC的信息, RAB Setup Information包含为数据转发所需要的RNC的TEID以及IP地址。如果目标RNC或者新SGSN未能成功分配资源,则 RAB Setup Information只包含NSAPI,意味着通知源RNC释放和NSAPI对应的资源。该消息仅用于SGSN之间的重定位。
6)旧SGSN向源RNC发送Relocation Command 消息(RABs to be released, and RABs subject to data forwarding),旧SGSN根据Qos决定要转发数据的RAB。 对于每个要转发的RAB,IE包含contain RAB ID,Transport Layer Address,以及 Iu Transport Association。Transport Layer Address 和 Iu Transport Association用来转发从源RNC到目标RNC的下行N-PDU。
7)接收到Relocation Command消息后,源RNC开始启动数据转发定时器。源RNC将通过发送Physical Channel Reconfiguration 消息(UE Information Elements,CN Information Elements)来触发relocation of SRNS的执行。
8)发送完重定位提交消息后,源RNC通过旧和新SGSN向目标RNC发送 Forward SRNS Context(RAB Contexts)消息,目标RNC向其返回Forward SRNS Context Acknowledge message。
9)发送完Forward SRNS Context 消息,源SRNC开始为每个RAB转发数据。 SRNS重定位的数据转发通过Iu接口,这表明在源SRNC和目标RNC转发的数据在源SRNC备份,通过IP层路由再到目标RNC。
10)当接受到重定位触发消息后,目标RNC将向新SGSN发送Relocation Detect 消息。对于重定位类型“UE Involved”,重定位触发通过Uu接口。 当发送了Relocation Detect 消息,目标RNC将开始SRNC操作。
11)CN收到Relocation Detect消息后,CN把用户面从源RNC转移到目标RNC。如果是SGSN之间的重定位,新SGSN将向GGSN发送Update PDP Context Request 消息(new SGSN Address,SGSN Tunnel Endpoint Identifier,QoS Negotiated),GGSN更新PDP上下文,返回Update PDP Context Response 消息(GGSN Tunnel Endpoint Identifier)。
12)当MS重新组装后,向目标RNC发送RNTI Reallocation Complete 消息,然后开始交换数据。
13)当目标RNC接收到RNTI Reallocation Complete 消息后,向新SGSN发送重定位完成消息。如果是SGSN之间重定位,新SGSN向旧SGSN发送重定位完成消息,旧SGSN收到后给新SGSN响应消息。
14)当收到新SGSN的Forword Relocation Complete消息,旧SGSN向新SGSN响应后,向源RNC发送IU RELEASE  CMD消息,当RNC的数据转发定时器超时,源RNC向旧SGSN发送IU RELEASE CMP消息。
15)如果新的路由区和旧路由区不一样,MS将发起RAU过程,该重定位流程仅仅是RAU的一个子集。
3. 重定位
图6-57  联合 Cell / URA Update 重定位
1)MS在小区重选后,向UTRAN发送一个Cell Update / URA Update 消息。收到该消息后,源RNC决定向目标RNC执行combined cell / URA update and SRNS relocation。
2)源SRNC通过向旧SGSN发送一个RELOCATION REQUIRED 消息(Relocation Type,Cause,Source ID,Target ID,Source RNC to target RNC transparent container),开始了重定位准备阶段,源RNC将该重定位类型置为“UE NOT INVOVED”。Source RNC to target RNC transparent container包含了重定位所需的一些必要信息,安全功能以及RRC协议上下文信息(包含UE能力)。
3)旧SGSN根据目标RNC的ID来决定是否是SGSN之间的重定位还是SGSN内部的重定位。如果是SGSN之间的重定位,旧SGSN通过向新SGSN发送Forward Relocation Request 消息(IMSI,Tunnel Endpoint Identifier Signalling,MM Context,PDP Context,Target Identification, UTRAN transparent container, RANAP Cause)开始重定位资源分配过程。同时在旧SGSN的MM和PDP上下文中启动一个定时器。该消息仅在SGSN之间重定位中才有。
4)新SGSN向目标RNC发送Relocation Request 消息(Permanent NAS UE Identity,Cause,CN Domain Indicator,Source RNC to target RNC transparent container,RABs to be setup)。对于每个要建立的RAB,RABs to be setup包含RAB ID,RAB parameters,Transport Layer Address,and Iu Transport Association等信息。The RAB ID information element 包含NSAPI value。RAB parameters 信息单元则给出了QoS 信息。Transport Layer Address是旧SGSN为数据传输提供的地址。Iu Transport Association对应着TEID。在所有为接受RAB的资源(包含Iu用户面)分配好之后,目标RNC将向新SGSN发送the Relocation Request Acknowledge 消息(RABs setup, RABs failed to setup),目标RNC为每个要建立的RAB(由IP地址和TEID组成)既接受从源SRNC的下行PDUs,也接受从新SGSN的下行PDUs。
5)当新SGSN和目标RNC之间的资源分配好之后,新SGSN准备开始进行relocation of SRNS。新SGSN向旧SGSN发送重定位响应消息Forward Relocation Response 消息(Cause,RANAP Cause,and RAB Setup Information)。该消息表明目标RNC已经准备好从源RNC接受未被MS确认的下行数据,也就是,重定位资源分配过程已经成功结束。RANAP Cause是从目标RNC到源RNC的信息,RAB Setup Information包含为数据转发所需要的RNC的TEID以及IP地址。如果目标RNC或者新SGSN未能成功分配资源,则 RAB Setup Information只包含NSAPI,意味着通知源RNC释放和NSAPI对应的资源。该消息仅用于SGSN之间的重定位。
6)旧SGSN向源RNC发送Relocation Command 消息(RABs to be released,and RABs subject to data forwarding),旧SGSN根据Qos决定要转发数据的RAB。对于每个要转发的RAB,IE包含contain RAB ID, Transport Layer Address,以及 Iu Transport Association。Transport Layer Address 和 Iu Transport Association用来转发从源RNC到目标RNC的下行N-PDU。
7)收到从PS域发送的Relocation Command 消息后,源RNC将启动数据转发定时器,当重定位准备阶段成功结束后,源SRNC通过向目标RNC发送Relocation Commit 消息(SRNS Contexts)发起执行relocation of SRNS。该流程的目标是在源和目标RNC之间传送SRNS上下文。
8)发送完重定位提交消息后,源RNC开始为每个数据转发的RAB转发数据。SRNS重定位的数据转发通过Iu接口,这表明在源SRNC和目标RNC转发的数据在源SRNC备份,通过IP层路由再到目标RNC。
9)当接受到重定位触发消息后,目标RNC将向新SGSN发送Relocation Detect 消息。对于重定位类型为"UE not involved"来说,重定位触发是在从Iur接口收到重定位提交消息。当发送了Relocation Detect 消息,目标RNC将开始SRNC操作。
10)发送完Relocation Detect 消息后,目标RNC向MS发送Cell Update Confirm / URA Update Confirm 消息。消息中包含UE信息以及CN信息。UE信息包含new SRNC identity 和 S-RNTI。CN信息包含位置区标识和路由区标识。
11)CN收到Relocation Detect 后,CN把用户面从源RNC转移到目标RNC。如果是SGSN之间的重定位,新SGSN将向GGSN发送Update PDP Context Request 消息(new SGSN Address,SGSN Tunnel Endpoint Identifier,QoS Negotiated),GGSN更新PDP上下文,返回Update PDP Context Response 消息(GGSN Tunnel Endpoint Identifier)。
12)当MS重新组装后,向目标RNC发送RNTI Reallocation Complete 消息,然后开始交换数据。
13)当目标RNC接收到RNTI Reallocation Complete 消息后,也就是,和UE通过空口交换SRNC-ID + S-RNTI完成后,向新SGSN发送重定位完成消息。如果是SGSN之间重定位,新SGSN向旧SGSN发送重定位完成消息,旧SGSN收到后给新SGSN响应消息。
14)旧SGSN向源RNC发送Iu Release Command 消息。当RNC的数据转发定时器超时时,源RNC以Iu Release Complete消息响应。
15)MS完成Cell / URA update and RNTI重分配后,如果新RAI和旧RAI不一样,MS将发起RAU过程,该重定位流程仅仅是RAU的一个子集,因为MS处于PMM-CONNECTED状态。
6.5.11  用户管理功能
1. 插入用户数据
图6-58  插入用户数据示意图
2. 删除用户数据
图6-59  删除用户数据示意图
HLR分别通过Insert Subscriber Data和Delete Subscriber Data两条信令实现对SGSN保存的用户数据的管理
6.5.12  服务请求
1. 手机发起
图6-60  手机发起的服务请求
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接受服务请求,SGSN将回应Service Accept消息给MS,如果指明是数据类型,SGSN发送Radio Access Bearer Assignment Request (NSAPIRAB ID(s),TEID(s),QoS Profile(s),SGSN IP Address(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,i.g.“Requested Maximum Bit Rate not Available”,那么SGSN将会再发送一个Radio Access Bearer Assignment Request消息带有不同的QoS。重试的次数和新Qos的值与实现相关。
7)对每一个RAB 重建修改了的QoS ,SGSN发起一个PDP 上下文修改过程通知MS和GGSN新的协商过的QoS。
8)MS发送上行包。
如果服务类型为信令:MS在收到RRC安全模式控制消息后认为SGSN成功的收到服务请求消息。
如果服务类型为数据:如果在PMM-IDLE状态,MS在收到RRC安全模式控制消息后认为SGSN成功的收到服务请求消息;如果在PMM-CONNECTED状态,MS在收到服务接受消息后,认为SGSN成功的收到服务请求。
服务接受消息并不意味着RAB(s)重建成功。
无论任何服务类型,如果服务请求不能被接受,网络侧将会回应一个服务拒绝消息并带上合适的原因给MS。
当服务类型为数据时:如果SGSN 重建RAB(s)失败,SGSN将会发起修改过程或者将PDP去激活,具体情况根据 QoS协商决定。
2. 网络侧发起
图6-61  网络侧发起的服务请求
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 发送Radio Bearer Setup (RAB ID(s))消息给MS。MS发送Radio Bearer Setup Complete消息给RNC。RNC发送Radio Access Bearer Assignment Response(RAB ID(s),TEID(s),RNC IP Address(es))消息给SGSN,指明GTP隧道已经建立在Iu接口,并且无线接入承载已经在RNC和MS之间建立。如果RNC回应的Radio Access Bearer Assignment Response消息中的原因值是要求的QoS无法提供。e.g.“Requested , Maximum Bit Rate not Available”,那么SGSN将发送新的Radio Access Bearer Assignment Request消息携带 不同的QoS。重试的次数与新的QoS参数和产品实现相关 。
7)对于每一个RAB重建修改QoS,SGSN会发起一个PDP上下文修改过程通知MS和GGSN新的 QoS。
8)SGSN发送下行包。
如果服务类型为寻呼响应,MS在收到RRC 的安全模式控制消息后,认为服务请求已经被SGSN成功的收到了。
如果SGSN重建RAB(s)失败,SGSN将会发起一个修改过程。
6.5.13  系统间切换
1. UMTS到GSM的SGSN之内的系统间切换
图6-62  UMTS到GSM的SGSN之内的系统间切换
1)当MS漫游到一个支持GSM的小区时,MS或BSS或UTRAN决定执行系统间切换,终止向网络的数据传输。
2)MS发送路由区更新请求Routeing Area Update Request(old RAI,old P-TMSI Signature,Update Type)给2G+3G-SGSN,请求类型可以是RAU或者联合RA/LA更新或如果MS进行IMSI attach,则进行联合RA/LA 更新和IMSI附着,送往2G +3G的SGSN所经过的BSS将把(全球小区标识)CGI信息添加到收到用户消息的小区的RAC和LAC中。
3)2G+3G-SGSN发送SRNS内容请求消息SRNS Context Request (IMSI)。
4)当SRNS收到SRNS CONTEXT REQ消息后,将立刻停止给MS发送下行PDU,并开始缓存,同时SRNS向2G+3G-SGSN发应答消息SRNS Context Response (IMSI,GTP-SNDs,GTP-SNUs,PDCP-SNUs),每一个PDP上下文将包括GTP的序列号用来指示序列中的下一个发送到MS的下行PDU以及序列中下一个将被管道送到GGSN的GTP PDU。每个激活的PDP上下文使用确认模式,SRNS也包括上行的PDCP序列号(PDCP-SNU)。PDCP-SNU是在每一个无线承载中从MS以确认方式收到的下一个预期的序列中的上行包PDCP序列号,在重组中,要求不能损失,以期将它们转换到各自的2G的GPRS PDP 上下文中的SNDCP N-PDU。
5)安全功能将被执行。
6)2G+3G-SGSN向SRNS发送数据转发指令SRNS Data Forward Command(RAB ID,Transport Layer Address,Iu Transport Association),通知SRNS 2G+3G-SGSN已经做好准备接受数据包。SRNS接到SRNS Data Forward Command消息后,立刻启动数据转发定时器。
7)发送了但未收到确认的PDCP-PDUs和他们的序号以及缓存的GTP PDU按隧道方式回传给2G+3G-SGSN。 随着收到N-PDU,2G+3G-SGSN将把相应的PDCP序号的前八位去掉,转换成SNDCP PDU序号,再发送给MS。
8)当SRNS数据转发定时结束之后, 2G+3G-SGSN向SRNS发释放Iu命令Iu Release Command,SRNC返回Iu释放完成消息,
9)如果关联要被建立,i.e. 如果更新类型指明是联合RA/LA更新并且IMSI附着,或者如果在路由更新中LA 改变,那么2G+3G-SGSN将向VLR发送位置更新请求Location Update Request(new LAI,IMSI,SGSN Number,Location Update Type) ,Location Update Type是正常的位置更新,2G+3G SGSN将通过RAI得到VLR Number,VLR将通过保存SGSN Number来创建或者更新与2G+3G SGSN之间的关联。
10)如果VLR中的用户数据没得到HLR的确认,则新VLR通知HLR。HLR取消旧VLR的用户数据,插入用户数据到新VLR。
A.      新的VLR发送Update Location 给HLR。
B.      HLR通过向旧的VLR发送Cancel Location(IMSI)消息取消旧的VLR中的数据。
C.      旧的VLR以Cancel Location(IMSI)响应。
D.     HLR发送Insert Subscriber Data Ack(IMSI、GSM 用户数据)给新的VLR。
E.      新 VLR以Insert Subscriber Data Ack(IMSI)作为响应 。
F.      HLR以Update Location Ack(IMSI)作为响应给新的VLR。
11)新VLR向SGSN返回应答Location Update Accept(VLR TMSI)分配TMSI给MS。如果VLR没有改变,VLR TMSI是个可选项。
12)2G+3G-SGSN验证MS在新RA的存在,如果由于漫游限制使MS不能在该RA中执行附着功能,或者用户检查失败,SGSN将以一个适当的原因拒绝用户的路由更新。如果用户检查成功,2G+3G-SGSN更新MM and PDP contexts。一个新的PTMSI将会被分配给MS,通过2G+3G SGSN发起的建立过程,SGSN和MS之间的新的逻辑链路将被建立,路由区更新接受Routeing Area Update Accept(P-TMSI,P-TMSI Signature,Receive N-PDU Number (= converted PDCP-SNU))将会发给MS,Receive N-PDU Number包含MS使用的每一确认模式的NSAPI上的确认信息,从而验证所有的在更新发起之前MS发的N-PDUs成功的传送。
13)MS向SGSN返回路由区更新完成消息(Receive N-PDU Number)确认新分配的PTMSI。Receive N-PDU Number (= converted PDCP-SND)包含每一NSAPI上MS接受的PDCP PDU成功的确认信息,因而确认了更新发生之前MS所收成功的N-PDU。MS将PDCP-SND的头八位去掉,转换成Receive N-PDU Number。
14)如果得到MS的确认,2G+3G-SGSN向VLR发送TMSI重分配完成消息。
15)2G+3G-SGSN和BSS执行BSS Packet Flow Context过程。
如果支持CAMEL,将会在C1处发生CAMEL-GPRS-Routeing-Area-Update。
2. GSM到UMTS的SGSN之内的系统间切换
图6-63  GSM到UMTS的SGSN之内的系统间切换
1)MS或者BSS或者UTRAN决定了执行系统间切换,使得MS切换到了支持UMTS无线技术的新小区,MS终止向网络的数据传输。
2)MS发起建立RRC连接过程,然后发送RAU Request(P-TMSI,Old RA,Old P-TMSI Signature,Update Type,CM)消息给2G+3G-SGSN。更新类型表明是路由区更新,或者联合RA/LA 更新,或者当MS想执行IMSI附着时,执行的联合 RA/ LA 更新和 IMSI附着,并且MS可能带有Follow On Request标志。i.e. 如果当时有上行流量(数据或信令),SGSN将会作为一个执行的可选项加以执行,Follow On Request将决定在更新完成之后保持还是释放Iu连接。SRNS在转发这个消息时将增加一个位置标识(area identifier)用来指明消息在哪里接收的,2G+3G-SGSN停止给MS转发N-PDUS。
3)安全流程将被执行。
4)如果关联将被建立,i.e.如果更新类型(Update Type)是联合的 RA/ LA更新和IMSI附着,或者LA在路由区中发生改变,那么2G+3G-SGSN将会发送一个 Location Update Request(new LAI,IMSI,SGSN Number, Location Update Type)给VLR,如果在RAU Request消息中指明是带IMSI附着的路由区更新,此时位置更新类型将会指明IMSI附着,否则,位置更新类型将指明是正常的位置更新。2G+3G-SGSN将从RAI得到VLR 。VLR通过储存SGSN NUMBER创建或更新与2G+3G-SGSN的关联。
5)如果VLR中的签约数据没有得到HLR的确认,新VLR则通知HLR。HLR取消旧 VLR中的数据,将用户数据插入到新的VLR。
A.      新VLR 发送 Update Location(new VLR)给 HLR。
B.      HLR通过向旧的VLR发送Cancel Location(IMSI)消息取消旧的VLR中的数据。
C.      旧的VLR以Cancel Location(IMSI)响应。
D.     HLR发送Insert Subscriber Data Ack(IMSI、GSM 用户数据)给新的VLR。
E.      新 VLR以Insert Subscriber Data Ack(IMSI)作为响应 。
F.      HLR以Update Location Ack(IMSI)作为响应给新的VLR。
6)新VLR 分配了一个新 TMSI,发送一个 Location Update Accept (VLR TMSI)给2G+3G-SGSN。
7)2G+3G-SGSN验证MS在新路由区的存在, 如果由于漫游限制使MS不能在该路由区中执行附着功能,或者用户检查失败,SGSN将以一个适当的原因拒绝用户的路由更新。如果用户检查成功,2G+3G-SGSN更新MM and PDP contexts。 一个新的PTMSI将会被分配个MS,路由区更新(PTSMI、PTSMI Signature)接受将会发送给MS。
8)Ms将以Routeing Area Update Complete 消息确认新PTMSI。
9)2G+3G-SGSN 如果得到MS对TMSI的确认将会发送TMSI Reallocation Complete 消息给VLR。
10)如果MS有上行的数据或信令,MS将会发送服务请求(Service Request(PTMSI、RAI、CKSN、Service Type))消息给SGSN,服务类型指明了要求的服务,将会是信令或者数据。
11)2G+3G-SGSN向SRNS发送建立RAB请求RAB Assignment Request (RAB ID(s),QoS Profile(s),GTP-SNDs,GTP-SNUs,PDCP-SNUs)。PDCP-SNUs从PDP contexts中保存的N-PDU(SNDCP PDU)中获得。SRNS向MS 发送Radio Bearer Setup Request(PDCP-SNUs)消息,MS 将以Radio Bearer Setup Complete(PDCP-SNDs)消息作为响应。SRNS向SGSN返回应答RAB Assignment Response message。
12)流量在SGSN和SRNS之间重新恢复,SRNS 将会丢弃所有的N-PDU序号早于从MS收到的下行的N-PDU序号的N-PDUs。其余的N-PDUs 将被发送到 MS。MS将会丢弃序号早于从SRNS收到的GTP-SNU序号的数据包。如果不是这种情况,这些N-PDU将会被传送到SRNS。
13)SRNS和MS之间开始数据传输。
3. UMTS到GSM的SGSN之间的系统间切换
图6-64  UMTS到GSM的SGSN之间的系统间切换
1)MS或BSS或UTRAN决定执行系统间切换。使得MS切换到一个支持GSM的新小区中,同时停止MS与网络流量传输。
2)MS向2G-SGSN发起路由区更新请求(old RAI,old P-TMSI Signature,Update Type),更新类型将指明路由区更新或者联合RA/LA更新或者带IMSI附着的联合RA/LA更新,BSS将会在将消息送到SGSN之前将收到消息加入所在的小区的带有RAC和LAC的小区全球标识(CGI)。
3)新2G-SGSN向老的3G-SGSN发送SGSN Context Request 消息(old RAI,TLLI,old P-TMSI Signature,New SGSN Address)获取MM and PDP contexts,老的3G-SGSN验证MS的PTMSI签名,如果没有通过验证,则以适当的原因通知新SGSN,如果新SGSN收到原因是PTMSI签名不符,2G SGSN将会发起安全流程,如果通过安全流程验证MS正确,则新2G SGSN将会发送SGSN Context Request(old RAI, TLLI, MS Validated,New SGSN Address)消息,其中MS Validated将会指明MS已经经过鉴权,老的SGSN将会启动一个定时器。如果旧的SGSN不认识该MS,则会回应一个适当的错误原因。
4)如果切换之前MS处在PMM-CONNECTED状态,旧的3G-SGSN向SRNS发送SRNS Context Request(IMSI)消息, SRNS收到此消息后,开始缓存并且停止向MS发送PDUs,向老的 3G-SGSN 返回SRNS Context Response(IMSI, GTP-SNDs,GTP-SNUs,PDCP-SNUs)。SRNS将在每一个PDP上下文中包括将发送到MS的下一个GTP序列号以及下一个将被送到GGSN的上行PDU的序列号。对每一个确认模式的激活的PDP上下文,SRNS还包括了上行PDCP-SNU,PDCP-SNU是预期从MS 收到的每一个激活的无线承载的下一个按序接收的PDCP序列号。3G SGSN将去掉PDCP序号的高8位,将PDCP转换成为SNDCP的 N-PDU。
5)老的3G-SGSN向2G-SGSN发送SGSN Context Response(MM Context,PDP Contexts),对每一个PDP上下文,3G SGSN将会加入下一个上行发到GGSN的GTP PDU的GTP序列号以及下一个在序列中下行发到MS的GTP序列号。每个PDP上下文也包括给下一个将被以确认模式发送给手机的序列中的下行N-PDU的SNDCP发送 N-PDU序号(值是0),还包括给下一个将以确认模式从MS收到的序列中的上行N-PDU 的SNDCP接收N-PDU序号(通过 PDCP-SNU转换)。新3G SGSN将会忽略在先前路由区更新流程中在SGSN Context Response中的MM Context中的MS 的网络能力(Network Capability)。
6)执行安全功能
7)新的2G-SGSN向3G-SGSN发送SGSN Context Acknowledge消息,通知3G SGSN 现在2G SGSN可以接受激活的PDP 上下文的相关的数据。老的3G-SGSN将上下文中的Gs关联、GGSN、HLR的信息置为无效,这使得如果切换没有完成,MS返回老SGSN发起路由区更新时会更新HLR。
8)如果手机处于PMM-CONNECTED状态,则老的 3G-SGSN向SRNS发送数据转发命令(Data Forward Command (RAB ID, Transport Layer Address, Iu Transport Association))。SRNS发送带PDCP下行序列号(高8位已经被去掉)部分已经发送的以及发送但没有确认的PDCP-PDUs,并且开始复制和发送已缓存的GTP PDU到老的3G SGSN,SRNS将会在收到SRNS Data Forward Command后启动数据转发定时器。
9)老3G-SGSN将GTP PDUs按隧道方式传送给2G-SGSN,GTP头中的序列号(从PDCP序号得到)不应改变。
10)新2G-SGSN向每一个相关的GGSN发送Update PDP Context Request(new SGSN Address,TEID,QoS Negotiated)。GGSN更新PDP context返回应答Update PDP Context Response (TEID)。
11)新2G-SGSN发送Update GPRS Location(SGSN Number,SGSN Address,IMSI)消息通知HLR修改SGSN号。
12)HLR发送Cancel Location(IMSI)通知老的3G-SGSN取消位置。老的3G SGSN以Cancel Location Ack消息应答。老的3G-SGSN的MM和PDP Context必须在操作超时定时结束之后删除。
13)如果MS处于PMM-CONNECTED时,3G-SGSN将向RNC发出释放Iu命令Iu Release Command 消息给 SRNS ,直到数据转发定时结束之后SRNS会以Iu Release Complete消息回应。
14)HLR发送Insert Subscriber Data(IMSI,GPRS Subscription Data)消息给新2G-SGSN,2G SGSN将用户签约数据插入MM 上下文和PDP上下文并且回应Insert Subscriber Data Ack (IMSI)消息。
15)HLR确认修改完成,发送Update GPRS Location消息到2G-SGSN。
16)如果关联将被建立,i.e.如果更新类型指示联合RA/LA更新和IMSI附着,或者如果LA在路由区更新中改变,那么新2G SGSN发送Location Update Request(new LAI,IMSI,SGSN Number,Location Update Type)给VLR。位置更新类型将指明是IMSI附着如果路由区更新类型是联合RA/LA更新和IMSI附着;否则的话位置更新类型将会指明是普通位置更新。2G SGSN从RAI中得到VLR 号,2G SGSN将会在收到MAP的插入签约数据后通知新的MSC/VLR发起位置更新,VLR会通过保存SGSN号码来创建或更新关联。
17)如果MSC/VLR的数据未经HLR证实,新VLR将会通知HLR对老的3G-SGSN和新2G-SGSN的MM进行取消更新过程。
A.      新VLR 发送 Update Location(new VLR)给 HLR。
B.      HLR通过向旧的VLR发送Cancel Location(IMSI)消息取消旧的VLR中的数据。
C.      旧的VLR以Cancel Location(IMSI)响应。
D.     HLR发送Insert Subscriber Data Ack(IMSI、GSM 用户数据)给新的VLR。
E.      新 VLR以Insert Subscriber Data Ack(IMSI)作为响应 。
F.      HLR以Update Location Ack(IMSI)作为响应给新的VLR。
18)新的VLR为MS分配TMSI,发送Location Update Accept通知2G-SGSN。如果VLR没有改变,TMSI是可选的。
19)新2G-SGSN验证MS在新路由区的合法性,如果漫游限制,导致不允许用户在本路由区内附着,或者用户信息检查失败,2G SGSN将会以一个适当的原因拒绝用户的路由更新请求。如果所有的检查成功,2G SGSN给用户组建MM上下文以及PDP上下文,通过2G SGSN发起一条逻辑链路在MS和2G SGSN之间建立起来,2G SGSN回应MS一个Routeing Area Update Accept (P-TMSI,P-TMSI Signature,Receive N-PDU Number(=converted PDCP-SNU))消息,MS在每一个确认模式的NSAPI的Receive N-PDU Number的确认,保证确认了在路由区更新发起之前的MS起始的N-PDUs的成功发送。
20)MS通过发送Routeing Area Update Complete(Receive N-PDU Number (= converted PDCP-SND))消息确认新分配的PTMSI,包括了MS使用的确认模式的NSAPI的Receive N-PDU Number的确认,因而确认了在路由区更新发起之前所有成功发送给MS的N-PDUs,MS将会从PDCP-SND中取出高8位推出接收的N-PDU序号,PDCP-SND是MS的每一个无线承载的下一个预期在序列中以确认模式将被收到的下行包的PDCP序列号。
21)2G-SGSN在得到MS确认后发送消息TMSI Reallocation Complete通知VLR TMSI重新分配完成。
22)2G-SGSN 和 BSS执行BSS Packet Flow Context procedure
如果支持只能业务,将会有执行下面的步骤:
A.      CAMEL-GPRS-SGSN-Context-Acknowledge
B.      CAMEL-GPRS-Routeing-Area-Update-Session
C.      CAMEL-GPRS-Routeing-Area-Update-Context
4. GSM到UMTS的SGSN之内的系统间切换
图6-65  GSM到UMTS的SGSN之内的系统间切换
1)MS或者BSS或者UTRAN决定进行系统间切换,使得MS切入到一个支持UMTS无线技术的新小区,并通知对网络的数据传送。
2)MS发送 Routeing Area Update Request (P-TMSI,old RAI,old P-TMSI Signature,Update Type,CM,MS Network Capability)消息给新的3G-SGSN。Update Type将会指明 路由区更新或者联合 RA / LA 更新,或者,如果手机需要进行IMSI附着,发生一个联合RA / LA 更新和IMSI附着,MS可能还会带follow-on request标志,i.e. 如果MS有上行流量(signalling or data)。SGSN会将其作为一个可选项进行使用,follow on request 指明在路由更新完成之后保留或者释放Iu 连接。SRNC 在发送用户消息给SGSN之前将会加入MS所在区域的RAC和LAC的路由区标识。路由区标识符合SRNC发给MS的移动性系统信息中的路由区表示。
3)3G-SGSN会通过从手机处得到的老的路由区标识得到老的2G-SGSN地址,然后发送SGSN Context Request(old RAI,old P-TMSI,New SGSN Address)消息给老的 2G-SGSN,以期得到该用户的 MM 上下文和 PDP上下文 。老的2G-SGSN 验证旧P-TMSI签名,如果与2G SGSN所保存的PTMSI签名不符合,则回应一个适当的错误原因,如果收到不符合的原因,3G SGSN将会发起鉴权流程,如果通过鉴权,3G SGSN将会发送 SGSN Context Request(old RAI,TLLI,MS Validated,New SGSN Address)消息给老的2G-SGSN。验证标志指明3G-SGSN已经对MS进行过鉴权。如果旧 P-TMSI签名是有效的或 3G-SGSN 指示已经对MS进行过鉴权,2G-SGSN启动一个定时器,通知对MS的N-PDUs的发送。
4)旧的2G-SGSN 以 SGSN Context Response(MM Context,PDP Contexts)消息响应。每一个PDP上下文包括给下一个将被发往MS的下行的N-PDU的GTP序列号以及 将被发往GGSN的下一个上行N-PDU的GTP序列号。每一个PDP上下文同时也包括以确认模式将要发给MS的下一个下行N-PDU的SNDCP发送 N-PDU号,以及以确认模式将要从MS收到的下一个上行N-PDU的SNDCP收到的N-PDU号。3G-SGSN 将会使用GTP序列号通过Iu接口进行有序传送 。3G-SGSN将会忽略MM上下文中的 通过路由区更新流程得到的MS Network Capability。
5)发起一个安全流程。
6)3G-SGSN 发送SGSN Context Acknowledge消息给2G-SGSN。使得2G-SGSN知道3G-SGSN可以接受已激活的PDP上下文的相关数据包。老 SGSN标注上下文中的MSC/VLR 关联和GGSN以及HLR信息无效。这使得如果在此次路由区更新结束之前,MS又回到老SGSN发生路由区更新,上述的信息必须更新。
7)2G-SGSN 复制并且缓存N-PDUs并且开始将数据包发送到3G-SGSN。在定时器超时之前从GGSN额外收到的N-PDUs将被复制并被发送到3G-SGSN。在定时器超时后,将不会有N-PDUs 被发送到3G-SGSN。
8)3G-SGSN 发送 Update PDP Context Request(new SGSN Address, TEID, QoS Negotiated)消息给每一个相关的 GGSN。每个 GGSN更新其 PDP上下文并且回应Update PDP Context Response(TEID)消息。
9)3G-SGSN 通过发送Update GPRS Location (SGSN Number,SGSN Address,IMSI)消息通知 HLR 发生 SGSN 改变。
10)HLR 发送Cancel Location(IMSI,Cancellation Type)消息给旧的2G-SGSN。如果定时器超时,旧的2G- SGSN将会删除MM 上下文和PDP上下文。 2G-SGSN 发送 Cancel Location Ack(IMSI)消息回应。
11)HLR发送 Insert Subscriber Data(IMSI,GPRS Subscription Data)消息给3G-SGSN。3G-SGSN建立MM上下文并且回应 Insert Subscriber Data Ack (IMSI)消息给 HLR。
12)HLR 以Update GPRS Location by returning an Update GPRS Location Ack (IMSI)消息响应3G-SGSN。
13)如果要建立关联,如果Update Type 指明联合 RA / LA更新带 IMSI 附着,或者如果LA在路由区更新中改变,那么新SGSN发送位置更新类型(new LAI,IMSI,SGSN Number,Location Update Type)消息给VLR。位置更新类型将会指明是IMSI 附着,如果前面的更新类型指示是联合 RA / LA更新带IMSI附着;否则,位置更新类型将会指示普通位置更新。3G SGSN会通过RAI得到VLR号。3G-SGSN在收到HLR的插入用户数据时发起位置更新,VLR通过保存SGSN号创建或更新关联。
14)如果VLR中的用户数据标明没有经过HLR的确认,VLR将会通知 HLR。HLR取消旧的 VLR并且插入用户数据到新的VLR:
A.      新VLR 发送 Update Location(new VLR)给 HLR。
B.      HLR通过向旧的VLR发送Cancel Location(IMSI)消息取消旧的VLR中的数据。
C.      旧的VLR以Cancel Location(IMSI)响应。
D.     HLR发送Insert Subscriber Data Ack(IMSI、GSM 用户数据)给新的VLR。
E.      新 VLR以Insert Subscriber Data Ack(IMSI)作为响应 。
F.      HLR以Update Location Ack(IMSI)作为响应给新的VLR。
15)新VLR 分配一个新的TMSI 以Location Update Accept(VLR TMSI)消息通知3G-SGSN。 VLR TMSI分配在VLR没有发生改变时是可选的。
16)3G-SGSN在新的路由区中验证MS。如果由于漫游限制导致 MS不允许在本路由区附着,或者用户检查失败,3G-SGSN将会以一个适当的原因拒绝用户的路由区更新请求。如果通过所有的检查,3G-SGSN建立用户的MM上下文和PDP上下文。3G-SGSN发送Routeing Area Update Accept(P-TMSI, P-TMSI signature)消息给MS。
17)MS通过发送Routeing Area Update Complete消息确认新分配的PTMSI。
18)如果得到MS的确认,3G-SGSN 发送 TMSI Reallocation Complete 消息给新VLR 。
19)如果MS有上行的数据或信令,将会发送一个 Service Request(P-TMSI,RAI,CKSN,Service Type)消息给SGSN。服务类型指明要求的服务。具体的有数据或者信令。
20)如果MS已经发送了服务请求,3G-SGSN发送RAB Assignment Request (RAB ID(s),QoS Profile(s),GTP-SNDs,GTP-SNUs,PDCP-SNUs)消息要求SRNS建立一个无线接入承载。PDCP 序列号从PDP上下文中的N-PDU 序号得到。SRNS 发送Radio Bearer Setup Request(PDCP-SNUs)消息给 MS。MS以Radio Bearer Setup Complete(PDCP-SNDs)响应。SRNS 发送RAB Assignment Response 消息给SGSN。SRNS 将会丢弃所有比从MS得到的PDCP-SNDs序号早的N-PDUs,其他的N-PDUs将会发送到MS。MS将会丢弃所有的序号早与从SRNS收到的PDCP-SNUs的 N-PDUs。
如果支持只能业务,将会有执行下面的步骤:
A.      CAMEL-GPRS-SGSN-Context-Acknowledge
B.      CAMEL-GPRS-Routeing-Area-Update-Session
C.      CAMEL-GPRS-Routeing-Area-Update-Context
5.选择性路由更新
在有上行信令或数据传输时:
在STANDBY或者PMM-IDLE状态MS发生系统间改变时将不会立即通过执行路由区更新过程来启动系统间改变直到有上行数据或信令需要发送。
如果MS在与其最后一次发送数据或信令相同的接入网,那么GPRS的MS将会首先发送LLC PDU,UMTS的MS将会发送服务请求。
如果MS在与其最后一次发送数据或信令不同的接入网,那么在发送数据或信令之前会先进行路由区更新过程,如果是关机的分离,则无需进行路由区更新过程。
在有下行信令或数据传输时:
如果2G+3G-SGSN在MS处于STANDBY或PMM-IDLE状态收到用户的数据,那么SGSN将会在当前MS所在的路由区内发起寻呼,其中包括2G和3G的小区。
如果MS在与其最后一次发送信令或数据相同的接入网收到寻呼,那么在GSM小区将会发送LLC PDU;在UMTS小区将会发送服务请求消息。
如果MS在与其最后一次发送信令或数据不同的接入网收到寻呼,那么将会发生一次路由更新过程,2G+3G-SGSN将认为路由更新请求是一个有效的响应。
6.5.14  类标处理
1. 无线接入类标
1)MS无线接入能力(GSM)
MS无线接入能力包括了MS的全部的GSM无线能力,包括(i.g. multislot capability,power class)
2)UE能力(UMTS)
UE能力包括了UE的全部的UMTS无线能力,包括(power control,code resource,UE mode,ciphering,PDCP capabilities,etc.)
2. MS网络能力
MS的网络能力包括了与无线无关的能力,如GSM GPRS 加密,UMTS鉴权,和TI扩展能力等。
6.6  呼叫控制
6.6.1  移动起始呼叫建立
当MS想发起一个呼叫时,MS要使用无线接口信令与网络建立通信,并发送一个包含有被叫用户号码的消息。CN将建立一个到该MS的通信信道,并使用被叫方地址创建一个IAM消息发送到被叫方。
图6-66  移动起始呼叫建立过程
1)MS在随机访问信道上发送CHANNEL REQUEST消息给网络。
2)网络回应IMMEDIATE ASSIGNMENT消息,使得MS可占用指定的专用信道。
3)MS向CN发初始服务请求消息CM SERVICE REQUEST。
4)网络将发起鉴权和加密过程。
5)在发送SECURITY MODE COMPLETE消息之后,MS通过发送SETUP消息给移动台而发起呼叫的建立过程。
6)网络将回CALL PROCEEDING消息。
7)对于早指配,在网络发起固定网络的呼叫建立之前要为MS分配一个通信信道。
8)当被叫振铃时,网络则要向主叫MS发一个ALERTING消息。
9)当被叫方应答后,将发送一个CONNECT消息给网络,网络再将其传给主叫侧。
10)当从主叫MS回CONNECT ACKNOWLEDGE消息之后即完成了呼叫建立的过程。
6.6.2  移动终止呼叫的建立
若CN收到IAM消息后,若允许该到来的呼叫建立,则CN要使用无线接口信令寻呼MS。当MS以PAGE ACK消息回应,CN收到后即建立一个到MS的通信信道。
移动终止呼叫用于移动用户做被叫时的情况,此时由网络发起呼叫的建立过程。
图6-67  移动终止建立过程
1)CN向RNS发送一个PAGE消息,RNS在寻呼信道上广播该寻呼消息。
2)被叫MS监测到该寻呼,将向RNS发送一个信道请求,RNS回应立即指配命令,指示MS使用指定的信令信道。
3)然后MS将在该信令信道上发送一个寻呼响应消息,CN收到MS的寻呼响应消息后,将发起鉴权和加密过程。
4)CN将发送SETUP消息给RNS,该消息中包含有该呼叫的承载能力。
5)当MS从RNS接收到SETUP消息,它将回应一个CALL CONFIRMED消息。如果协商的承载能力参数有变化,则该消息中要包含有承载能力信息。
6)当CN从RNS接收到CALL CONFIRMED消息时,CN将向RNS发送RAB ASSIGNMENT REQ消息要求进行无线信道的指配,RNS将通过向MS发指配消息命令MS调节到一个指定的通信信道上,MS调到指定的信道上之后,将向RNS发送指配完成消息。
7)RNS向CN发RAB ASSIGNMENT RESP消息。
8)MS发送ALERTING消息指示被叫用户振铃。
9)当被叫用户应答时,被叫MS将发送一个CONNECT消息经过RNS到CN,
10)CN将给MS回应CONNECT ACK消息,呼叫建立过程结术。
6.6.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-68  Iu接口RAB Assingment 过程
RAB Assignment过程的目的是修改和/或释放已经建立的RAB,和/或建立新的RAB。 本过程是面向连接的。
CN首先发送RAB Assignment  Request消息给RNC,然后CN启动定时器TRABAssgt。在一条RAB Assignment Request消息中,CN可以要求UTRAN建立/修改/释放一个或几个RABs,本消息包含以下信息,主要是:
带有承载特性的需建立/修改的RAB列表;
需释放的RAB列表;
RAB ID在每一个Iu连接内是唯一的。如果RNC收到的消息中包括已经存在的RAB ID,那么RNC认为是修改该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  Request消息中涉及的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建立流程
图6-68简要的描述了在CN和UE之间经过UTRAN而建立RAB的流程。
图6-69  无线接入承载建立-(DCH-DCH 同步建立流程)
这个例子说明了当RRC连接已经建立好以后,在专用传输信道(DCH)RRC状态下建立无线接入承载RAB(DCH)的过程。
Ÿ          时机:
在电路域,在CN接受UE的业务请求(主叫SETUP,被叫的CALL CONFIRM,CONNECT等消息)后指示需要一条新的AS的承载通道来承载NAS用户数据时发送RAB Assignment Request消息启动这一过程。
Ÿ          过程描述:
1)CN根据签约用户数据、CN业务能力和UE业务请求的QoS决定采用什末样的RAB。通过RANAP消息Radio Access Bearer Assignment Request(Setup)请求建立RAB。其中的RAB ID根据SI的值来填充,在电路域重要参数有RAB参数,用户面模式,本端用户面ATM地址,IU传输标识(BINDING ID)。
2)服务RNC使用ALCAP协议初始化Iu接口数据传输承载的建立。
在电路域使用AAL2承载的情况下(在PS域这一过程不需要),AAL2连接建立过程如2.1,2.2所述。在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-70  无线接入承载释放-(DCH - DCH- 同步释放流程)
Ÿ          启动时机:
在电路域,在CC层使用该RAB的事物全部结束或RNC请求释放该RAB时启动此过程。
Ÿ           过程描述:
1)CN通过发送RANAP消息Radio Access Bearer Assignment Request。(Release)启动RAB释放过程,其中指明是哪一个RAB ID。
2)业务RNC以RANAP消息Radio Access Bearer Assignment Response来证实。
3)业务RNC使用ALCAP协议,如果是AAL2承载,使用AAL2 释放消息来启动和CN之间的Iu数据传输承载的释放(在PS域这一过程不需要)。
Q。AAL2的释放过程如3.1,3.2描述。
4)业务RNC在释放了和Node B等的链路后,发送RRC消息Radio Bearer Release给UE启动承载释放过程。
5)业务RNC在收到UE的证实RRC消息Radio Bearer Release Complete后。整个释放过程结束。
6. RAB修改流程
图6-71  无线接入承载修改(DCH-DCH 同步修改)
Ÿ          启动条件:
UE业务切换或速率调整时,CN重配置业务信道以支持业务属性的改变。
Ÿ          过程描述:
1)CN通过RANAP消息Radio Access Bearer Assignment Request(Modify)请求修改RAB。其中的RAB ID根据指明RAB 标识,在电路域重要参数有RAB参数。
2)服务RNC选择哪种参数应该被修改,哪种程序应该被启动。
3)服务RNC使用ALCAP协议修改Iu接口数据传输承载的通道特性。
如果使用AAL2承载,修改过程如3.1,3.2描述。
4)等到Iu接口传输控制面的修改过程成功后,服务RNC在和Node B等修改好无线链路后,通过RRC消息Radio Bearer Reconfiguration把RAB参数中的子流和子流组合参数和RAB ID等传给UE。
5,6 )服务RNC在收到UE的成功证实RRC消息Radio Bearer Setup Complete后向CN证实RAB成功建立。发RANAP消息Radio Bearer Assignment Response到CN。
7 )如果用户面是支持模式,报告结果后UTRAN再通过初始化Iu接口用户面。
6.6.4  寻呼流程
寻呼过程是CN向被叫发起的寻呼过程,当CN需要向和被叫用户建立连接时,首先需要通过寻呼过程找到被叫,寻呼过程的作用就是使CN能够寻呼到被叫用户,寻呼过程通过无连接信令方式建立。
CN通过向被叫发起PAGING消息来开始寻呼程,PAGING消息应该包含足够的信息以使RNC能够找到被叫,如果一次寻呼不可及,CN负责通过lu接口重复发寻呼的过程。
图6-72  成功寻呼流程
1. 寻呼过程
来自主叫的呼叫请求信息CN经过处理后,如果成功的得到了有关被叫用户的信息,寻呼过程就可以开始。CN需要知道被叫所在的位置区信息,并且取得足够的寻呼信息参数,这样,CN就可以向被叫发起寻呼。
如果CN没有得到被叫用户的位置区信息,需要通过广播过程向CN下的所有RNC发起寻呼消息。
CN下发PAGING消息是通过RANAP接口进行的, RANAP接口处理来自CN的PAGING消息,PAGING包含的参数包括寻呼是来自CS域还是PS域的,是何种原因引发的寻呼,以及被叫用户的位置区信息等。由RANAP向被叫所属位置区下RNC发寻呼消息。
当PAGING消息到达RNC后,RNC通过分析寻呼消息的参数取得被叫所在的位置区信,RNC通过PCCH传送寻呼信息给位置区的UE,如果被叫UE检测到RNC来的寻呼消息, 开始执行NAS信令过程。
如果寻呼成功,CN会得到寻呼响应消息,否则,CN需要通过lu接口重复发送寻呼消息。
以下就两个例子UE在RRC 空闲状态和RRC连接状态下的寻呼过程。
2. UE在RRC 空闲状态的寻呼过程
当RRC处于空闲状态时候,UE 可能会收到来自CS或者PS的寻呼,因为此时UE处于空闲状态,CN可以知道该UE的位置区(LA)信息,因此,寻呼会通过该位置区来下发,这里列出了LA跨越两个RNC的情况。
图6-73  RRC空闲状态下寻呼过程
1)CN通过发起的寻呼消息,跨过两个RNC到达被寻呼UE。
2)小区1 用  Paing Type1发起寻呼。
3)小区2用 paging  Type 发起寻呼。
PAGING 消息通过RANAP的到达RNC1,RNC2, RNC通过PCCH传送寻呼信息给位置区的UE, 如果被叫UE检测到RNC1或者RNC2来的寻呼消息, 开始执行NAS信令过程。
3. UE在RRC RRC连接状态下的寻呼过程
当RRC处于连接状态时候。这种情况在CN为CS域或者PS域两种情况,由于移动性管理的独立性,有两种可能的解决方案:
1)UTRAN来协调在已存在RRC连接上寻呼请求
2)UE来协调已存在RRC连接上的寻呼请求
以下例子说明在RRC连接状态(CELL_DCH 和 CELL_FACH 状态)执行寻呼UE过程的,由UTRAN在RRC连接的状态下用DCCH协调寻呼请求的情况。
图6-74  在RRC连接状态(CELL_DCH 和CELL_FACH)下寻呼UE过程
1) CN通过RANAP发送PAGING消息来对UE寻呼。
2)SRNC对RRC发送消息 Paging Tyep2。
6.6.5  呼叫释放过程
当移动用户通话完毕,主叫方或被叫方挂机的消息要通知到网络侧,进行呼叫的释放过程。网络侧通过终止GSM PLMN之间或GSM PLMN与别的网络之间的电路交换连接而释放呼叫。
图6-75  移动发起呼叫释放的成功情况
1)移动方挂机之后,移动台通过向网络发送DISCONNECT消息而发起呼叫清除;
2)网络接收到该消息之后发送一个RELEASE消息给移动台;
3)MS发RELEASE COMPLETE消息给网络,如果此时不再需要通信信道,则要执行信道的释放过程;
4)如果该呼叫是整个Iu连接上的唯一的一个呼叫,则要释放Iu连接。CN向RNS发送IU RELEASE COMMAND消息请求释放Iu连接。
6.7  分组域会话管理流程
6.7.1  SM基本概念
1. SM功能概述
会话管理是3GPP协议中连接管理层(Connection Management)的一个主要的组成部分。位于移动性管理(Mobile Management)和用户面之间,使用GMM子层提供的无应答数据传送服务,向高层----用户面提供连接管理服务。它一方面完成核心网络SGSN到GGSN之间的隧道建立、修改和释放的控制功能,另一方面完成SGSN和RNC/MS之间无线接入承载(Radio Access Bearer)建立、修改和释放的控制。
2. 术语
1)PDP CONTEXT
PDP上下文保存了用户面进行隧道转发的所有信息,包括RNC/GGSN的用户面IP地址、隧道标识和QoS等。
2)NSAPI
在MS中NSAPI用于标识一个PDP服务访问点,在SGSN/GGSN中用于表示一个会话。
3)RAB ID
在接入层标识用户的一个RAB,它的取值等于NSAPI。
4)APN解析
Access Point Name,采用标准域名格式。APN包括两部分:网络名和运营商名。在GGSN中用于标识一个指定的外部网和一种服务的ISP, 在SGSN中可根据APN通过DNS解析得到与此APN对应的GGSN地址。
5)PDP地址匹配和APN选择
一个用户可以使用多个PDP地址和APN,在激活一个会话时,用户请求的PDP地址和APN必须满足签约数据的要求。根据请求的地址和APN找到满足此要求的签约PDP CONTEXT数据的过程称为PDP地址匹配和APN选择。
6)QoS协商
会话管理在建立分组传输路由的同时,也必须指定此路由满足的QOS,会话管理过程在MS、RNC、SGSN、GGSN之间进行QoS协商,使各节点提供的服务质量保持一致。QoS协商的算法是在签约的QOS、SGSN能提供的最大QOS和其它节点满足的QOS之间取最小值。
3. SM在协议栈中的位置
图6-76  UMTS MS-SGSN的控制面协议
图6-77  SM与各协议单元的关系:
SM与其他协议单元的服务访问点说明:
RABMSM-SAP:
完成RAB激活、修改、去激活的控制功能;接口原语有:
RABMSM-ACTIVATE-IND         SM指示RABM指定NSAPI的会话已激活;
RABMSM-ACTIVATE-RSP         RABM完成创建RAB后向SM返回响应;
RABMSM-DEACTIVATE-IND    SM指示RABM指定NSAPI的会话已去激活;
RABMSM-DEACTIVATE-RSP    RABM完成去激活RAB后向SM返回响应;
RABMSM-DEACTIVATE-REQ    RABM在指配失败后向SM发起去激活请求;
RABMSM-MODIFY-IND            SM指示RABM指定NSAPI的会话已修改;
RABMSM-MODIFY-RSP            RABM完成修改RAB后向SM返回响应;
RABMSM-STATUS-REQ            RABM通知SM出错;
GMMRABM-SAP:
Service Request过程,通知RABM有上行数据传送,RABM进行RAB重建。
UL-DATA-IND 上行数据传送指示;
GMMSM-SAP:
GMM在次SAP向SM提供无应答数据透传服务,另外在Detach时通知SM释放;接口原语有:
GMMSM-RELEASE-IND            MS Detach时通知SM的释放指示;
GMMSM-UNITDATA-REQ         SM的无确认数据传送请求;
GMMSM-UNITDATA-IND         GMM向SM发送无确认的数据指示;
GTMSM-SAP:
SM与隧道管理之间的接口,完成SGSN-GGSN之间的隧道创建、修改、删除的控制功能;
GTMSM-CRT-REQ                    SM请求GTP隧道管理创建隧道;
GTMSM-CRT-RSP                     隧道管理创建GTP隧道之后向SM返回响应;
GTMSM-MDF-REQ                   SM请求GTP隧道管理修改隧道;
GTMSM-MDF-RSP                    GTP隧道管理修改隧道之后的响应;
GTMSM-DEL-REQ                    SM请求GTP隧道管理删除隧道;
GTMSM-DEL-RSP                            GTP隧道管理删除隧道之后向SM返回响应;
GTMSM-PDU-NTF-IND             GTP隧道管理通知SM有下传数据;
GTMSM-PDU-NTF-RSP             SM向GTP隧道管理返回数据通知响应;
GTMSM-PDU-NTF-REJ-REQ     SM向GTP隧道管理返回数据通知拒绝请求;
GTMSM-PDU-NTF-REJ-RSP      GTP隧道管理向SM返回数据通知拒绝响应;
GTMSM-ERR-IND                            GTP隧道管理通知SM用户面出错;
4. 与SM相关的功能实体
(1) RAB管理
RABM(RAB Management)完成RAB的创建、修改、释放和重建的管理功能。
RAB由两部分组成:RNC和SGSN之间的GTP隧道以及RNC与MS之间的无线承载(Radio Bearer)。RAB ID唯一标识用户的一个RAB。
RAB的建立、修改、释放和重建都是通过RAB ASSIGNMENT过程完成的。
图6-78  RAB管理流程图
流程说明:
1)SGSN向RNC发送RAB Assignment Request(SGSN ADDR,TEIDs,QOS)消息,请求建立、修改或释放RAB(s),在指配参数中可指定RAB的无线优先级,是否允许抢占和排队;
2)RNC建立、修改或释放无线承载;
3)RNC向SGSN发送RAB Assignment Response,如果因为QoS的原因指配失败,则要降低QoS重发指配请求。
如果RAB重建时发生QoS改变,则执行SGSN发起的PDP CONTEXT修改流程,将QoS通知MS和GGSN。
(2) 隧道管理
隧道管理的主要任务是创建SGSN到GGSN之间的GTP隧道。隧道管理包括创建隧道、修改隧道、删除隧道和网络侧发起PDP CONTEXT激活的管理。
PDP CONTEXT的激活、修改、去激活和保留过程
SM通过PDP CONTEXT的激活、修改、去激活信令流程实现会话管理。PDP CONTEXT激活流程建立用户面的分组传输路由;PDP CONTEXT修改流程修改激活的PDP CONTEXT的QOS和TFT,在发生RAU改变时,也需要修改SGSN到GGSN之间的隧道路由;PDP CONTEXT去激活流程用于拆除激活的PDP CONTEXT。SM的状态机模型如下图所示:
图6-79  PDP状态机模型
在用户进行激活流程之前,SGSN上的SM必须先进入PMM-CONNECTED状态。
一个用户可以有多个签约的PDP地址,每一个PDP地址可能包含一个或多个会话,每个对话有两种状态:激活态和非激活态(ACTIVE/INACTIVE)。非激活的会话不包含路由信息,不能进行数据的转发。
二次激活使用和一次激活相同的PDP ADDRESS、APN,但使用不同的QOS,在激活之后,二次激活的PDP CONTEXT和一次激活的PDP CONTEXT是完全对等的。发生R99到R98/97的路由区更新时,对共享地址和APN的激活的PDP CONTEXT(s),保存QOS最高的PDP CONTEXT,其它的PDP CONTEXT将被去激活。
RNC发起RAB或IU释放之后,SGSN可以保留这些激活的PDP CONTEXT,而不进行去激活。当用户发起SERVICE REQUEST过程时进行RAB的重建,恢复数据传送。
下面将分节讨论各个会话管理流程。
6.7.2  PDP Context激活功能
PDP CONTEXT激活包括MS发起的,网络发起的PDP CONTEXT激活和二次激活。
1. MS发起的PDP Context激活
图6-80  MS发起的PDP CONTEXT激活过程
1)MS向SGSN发送激活请求Activate PDP Context Request (NSAPI,TI, PDP Type,PDP Address,Access Point Name,QoS Requested)。PDP Address指出是动态地址还是静态地址。如是动态地址,则设为空。
2)执行RAB指配过程;
3)SGSN通过使用PDP Type(optional),PDP Address(optional),  Access Point Name(optional)和PDP CONTEXT签约数据来验证Activate PDP Context Request的有效性;
SGSN给PDP Context分配TEID,如果使用动态地址,则要求GGSN分配一个动态地址。 SGSN根据一定的算法选择一个APN,SGSN向GGSN发创建PDP Context请求(PDP Type,PDP Address,Access Point Name,QoS Negotiated,TEID,NSAPI,MSISDN,Selection Mode,Charging Characteristics,Trace Reference,Trace Type,Trigger Id,OMC Identity, PDP Configuration Options)。
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,QOS),SGSN将地址,Qos等信息通过Activate PDP Context Accept 发送给MS。
2. 二次激活
一个PDP地址可对应多个PDP Context,二次激活仅在相同的PDP地址和APN上有激活的PDP Context时才发起。 二次激活的PDP Context与已激活的PDP Context只有Qos profile不同,每个PDP context使用唯一的TI和NSAPI。 二次激活执行过程APN选择和地址协商不必执行,流程与PDP context Activation过程类似。
在许多PDP Context中,只允许一个PDP Context没有TFT。
传输下行N-PDU时,GGSN按TFT匹配选择合适的PDP context。MS发送数据时,按QOS选择不同的PDP context。
图6-81  二次激活流程
3. 网络发起的PDP Context激活
图6-82  网络侧发起的PDP CONTEXT激活过程
1)GGSN收到PDP PDU,向HLR发送Send Routeing Information for GPRS (IMSI),取SGSN的地址
2)如果MS可达,则HLR发送Send Routeing Information for GPRS Ack (IMSI,SGSN Address,Mobile Station Not Reachable Reason)返回SGSN的地址,否则返回错误,如果错误不是“No Paging Response”,HLR将此GGSN添加到该用户的GGSN-List。
3)如SGSN存在或错误 是“No Paging Response”,则发送PDU Notification Request(IMSI,PDP Type,PDP Address,APN)通知给SGSN;
4)SGSN返回应答PDU Notification Response(Cause),确认将要请求MS激活PDP context过程。
5)SGSN向MS发送Request PDP Context Activation(TI,PDP Type,PDP Address,APN)要求MS发起激活PDP context请求。
6)MS发起PDP CONTEXT激活过程。
6.7.3  PDP Context修改功能
PDP CONTEXT修改过程包括:
Ÿ          MS发起的PDP Context修改过程
Ÿ          SGSN发起的PDP Context修改过程
Ÿ          GGSN发起的PDP Context修改过程
Ÿ          RAB/IU释放,SGSN发起PDP CONTEXT修改流程;
修改参数包括:
Ÿ          QoS Negotiated;
Ÿ          Radio Priority;
Ÿ          Packet Flow Id;
Ÿ          PDP Address(GGSN发起的修改过程in case of the GGSN-initiated modification procedure);and
Ÿ          TFT(MS发起的修改过程)。
1.SGSN发起的PDP Context修改
SGSN发起的PDP CONTEXT修改过程包括:
HLR向SGSN插入用户数据而且会话处于激活状态,SGSN发起PDP Context修改过程。
RAB重建,发生QOS改变,SGSN发起PDP CONTEXT修改流程;
SGSN之间的路由区更新过程,如果会话处于激活状态,SGSN发起PDP CONTEXT修改流程;
MS、SGSN、GGSN发起的PDP Context修改最主要的过程就是QOS协商和路由的重新建立。
图6-83  SGSN发起的PDP CONTEXT修改过程
1)SGSN发送更新请求Update PDP Context Request(TEID,NSAPI,QoS Negotiated,Trace Reference,Trace Type,Trigger Id,OMC Identity)与GGSN协商QOS;
2)GGSN进行QOS协商,向SGSN发送Update PDP Context Response(TEID, QoS Negotiated,Cause);
3)SGSN按QOS选择无线优先级和Packet Flow Id。 向MS发送修改请求Modify PDP Context 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)如果启动BS跟踪,则要发引用跟踪消息Invoke Trace(Trace Reference, Trace Type,Trigger Id,OMC Identity)。
2. MS发起的PDP Context修改
图6-84  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协商QOS;
3)GGSN进行QOS协商,向SGSN发送Update PDP Context Response(TEID, QoS Negotiated,Cause);
4)执行RAB指配过程修改RAB;
5) SGSN向MS发送Modify PDP Context Accept。
3. GGSN发起的PDP Context修改
GGSN的修改流程的目的是改变传输路由的QoS或用户的PDP ADDRESS,有两种情况:
焈 GGSN作为DHCP中继代理,收到外部网给MS分配的IP地址;
焈 GGSN中会话的QOS发生改变;
图6-85  GGSN发起的PDP Context修改
流程说明:
1)GGSN向SGSN发送Update PDP Context Request(TEID,NSAPI,PDP Address,QoS Requested);
2)SGSN进行Qos协商,向MS发送修改PDP CONTEXT的请求Modify PDP Context Request(TI,PDP Address,QoS Negotiated,Radio Priority,Packet Flow Id);
3)如果MS接受指定的QoS,向SGSN返回修改接受Modify PDP Context Accept消息,如果拒绝接受,发起PDP CONTEXT的去激活过程;
4)执行RAB修改过程;
5)如果SGSN收到Modify PDP Context Accept ,则向GGSN发送Update PDP Context Response(TEID,QoS Negotiated),如果收到Deactivate PDP Context Request,则执行MS发起的去激活过程。
4. IU/RAB释放引起的PDP Context修改
RNC向SGSN发送IU RELEASE REQUEST或RAB RELEASE REQUEST,释放Iu/RAB成功之后:
焈 SGSN,对背景级和交互级的通信,PDP Context不改变
焈 SGSN,对流级和实时会话级的通信,PDP Context不改变,但将最大通信速率降到0,同时通知GGSN也将最大传输速率降到0
对MS失去无线覆盖之后:
Ÿ          对背景级和交互级的通信,PDP Context不改变
Ÿ          对流级和实时会话级的通信,当RRC重建失败后,PDP Context保留,但将最大通信速率降到0,在重新获得覆盖后,利用PDP Context修改过程重建PDP Context和RAB。
6.7.4  PDP Context去激活功能
PDP Context去激活流程包括MS发起的、SGSN发起的和GGSN发起的PDP Context去激活过程。
1. MS发起的PDP Context去激活
图6-86  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 CONTEXT不一致,RAB重建失败,资源不足等。
图6-87  SGSN发起的PDP Context去激活
1)SGSN向GGSN删除PDP Context请求,Delete PDP Context Request (TEID,NSAPI,Teardown Ind),Teardown Ind指示是否去激活和指定TI共享地址的激活的PDP CONTEXT。
2)GGSN向SGSN发送Delete PDP Context Response(TEID);
3)得到GGSN的删除应答后,向MS发送Deactivate PDP Context Request删除MS PDP Context,如果是DETACH引起的PDP CONTEXT去激活,不发此消息;
4)收到MS发来Deactivate PDP Context Accept ;
5)SGSN发起RAB assignment procedure释放RAB。
3. GGSN发起的PDP Context去激活
图6-88  GGSN发起的PDP Context去激活过程
过程说明:
1)GGSN向SGSN发送删除PDP CONTEXT的请求消息Delete PDP Context Request(TEID,NSAPI,Teardown Ind),Teardown Ind指示是否去激活和指定TI共享地址的激活的PDP CONTEXT。
2)SGSN 向MS发送去激活请求消息Deactivate PDP Context Request(TI, Teardown Ind)
3)MS删除本地的PDP CONTEXT,向SGSN返回去激活接受消息Deactivate PDP Context Accept(TI,Teardown Ind);
4)SGSN向GGSN发送删除PDP CONTEXT的响应消息Delete PDP Context Response(TEID),GGSN收到此消息后,如果为MS分配了动态地址,可以释放此动态地址给其他的MS使用,SGSN发送删除PDP CONTEXT响应不必等待收到MS的去激活接受消息;
5)调用RAB支配过程释放RAB。
6.7.5  保留过程和RAB重建
在RNC发起的RAB释放和IU释放时,可以不释放PDP CONTEXT,而是把PDP CONTEXT保留下来,不做任何更改,RAB将在以后的Sevice Request过程中重建。
1. MS发起Service request进行RAB重建
当MS有上行的数据传输需求,PDP CONTEXT处于激活状态而RAB不存在时,MS发起Sevice Request过程为激活的PDP CONTEXT重建RAB。过程描述如下:
图6-89  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和GGSN;
6)MS进行上行数据传送。
2. SGSN发起Service Request过程进行RAB重建
当SGSN收到下行的信令或数据包后,发现用户处于PMM-IDLE状态,则要发起寻呼。MS在收到寻呼后,发送Sevice Request请求,sevice type=“paging response"。如果是由于SGSN收到数据包引起的Service Request过程,则要调用RAB Assignment过程 进行RAB重建。
图6-90  SGSN发起Service Request过程进行RAB重建
6.7.6  Mobile IP支持
目的:支持在不同的子网,固定网和移动网,不同的PLMN之间的移动通信。
图6-91  支持Mobile IP的核心网络体系结构
使用MIP通信过程:
1)移动台接受FA的代理广播信息确定它在外部网上,可向接入网发代理请求信息。
2)移动台向FA申请一个转交地址,向HA注册。
3)发往移动节点的数据被HA截取,发往转交地址,再由转交地址发送给MS。对反向传输,以标准路由方式处理。
图6-92  注册MIP的流程图
注册MIP的流程:
1)AT Command带有建立PDP context的参数APN,TE与MT建立PPP连接
2)MT向SGSN发送激活PDP context请求,请求包含两个重要参数:APN和 "Requested PDP Address。APN=MIPv4FA,地址为空;
3)SGSN根据配置数据或通过DNS解析,得到支持MIP的GGSN的IP地址,然后请求GGSN创建PDP context。
4)GGSN返回创建应答,PDP地址设为0.0.0.0,MS的PDP地址将在MS和HA协商之后确定
5)SGSN向MS返回创建PDP Context应答消息。
6)FA发送代理广播,它是一个具有移动代理广播扩展的ICMP路由广播报文,移动代理广播消息包括移动节点需要的一个或多个转交地址。此消息在用户平面上发送。发送的目的地址为255.255.255.255.仅仅对刚到达的MS通过TID标识的隧道传送,避免广播。
7)MS选择一个转交地址,向GGSN发MIP注册请求,参数包括它的永久IP地址或包含归属网分配的NAI的临时地址。
8)GGSN/FA存储MS传来的地址和TID等参数,向HA转发MIP注册请求。
9)HA向FA返回注册应答。FA取出HA分配给MS的地址。
10)FA/GGSN向MS转发注册应答,FA/GGSN根据MS的TID和NAI或归属地址,向MS转发注册应答。GGSN发起PDP context修改过程修改IP地址。
NOTE 1. FA广播信息在返回创建Create PDP context应答后发出
NOTE 2. FA/GGSN与MS在用户面交换MIP信令消息。
时间:2007-11-06 16:49:03
  WiKi  用户登陆
邮 箱:
密 码:
 


快速查询导航
GPRS案例汇总GSM 层3信令Layer3 流程表GSM切换算法
PCU容量优化流程爱立信GSM小区功控方面参数解释第四代移动通信系统中的多天线技术
高通CDMA工程技术手册(中文版)语音质量的度量标准——MOS中兴wcdma培训
更多
访问排名
GSM小区公共参数解释2010-08-13 17:13:36
A口2010-08-12 13:40:42
cdma2010-08-12 11:34:57
EVDO2010-08-12 11:32:57
爱立信GSM小区半速率方面参数解释2010-08-12 11:20:46
爱立信常用缩写语表2010-08-11 15:38:41
CCCH2010-08-11 12:20:42
MCCCH2010-08-11 12:20:17
NUMREQEGPRSBPC2010-08-11 10:52:20
dthnamr2010-08-11 10:51:45
dthamr2010-08-11 10:51:25
dha2010-08-11 10:51:18
搬迁2010-08-10 16:05:12
tdscdma 分析2010-08-10 13:12:29
td-scdma 分析2010-08-10 13:12:25
td-scdma 协议2010-08-10 13:12:21
td-scdma 信令2010-08-10 13:12:10
td scdma 信令2010-08-10 13:12:05
tdscdma2010-08-10 13:11:52
TD-SCDMA2010-08-10 13:11:35
wcdma2010-08-10 12:32:11
wcda2010-08-10 12:31:12
WCDMA基本信令流程2010-08-10 12:30:44
软切换2010-08-10 12:29:37
pdp2010-08-10 12:29:25
软切换事件2010-08-10 12:28:42
wimax2010-08-10 09:08:44
小区 覆盖2010-08-09 22:42:24
小区分布2010-08-09 22:42:00
内环功控2010-08-09 16:25:39
热门搜索
GSM小区公共参数解释(471)  爱立信GSM小区半速率方面参数解释(303)  2007中移动中标情况(275)  PCU容量优化流程(227)  NOKIA(188)
最新活跃写手
单恋一枝花JF聪少
jonse1980易水云鹤阿莫
zzzvoooSea慕容
一份空白香樟树dhy639
jiaju9000迷茫小鹿jeplgh
更多

主编信箱   粤ICP备07004317号          留言      声明Statement
版权所有 © 2007 TELECOMER TECH CO., Ltd. 广州嘉誉通讯科技有限公司