基本信令流程说明在看0401.docx

基本信令流程说明在看0401.docx

《基本信令流程说明在看0401.docx》由会员分享，可在线阅读，更多相关《基本信令流程说明在看0401.docx（20页珍藏版）》请在冰豆网上搜索。

基本信令流程说明在看0401

基本信令流程

1概要：

本文档结合外场测试各种情况，对各种信令流程进行了说明。

2接入流程

2.1RNC信令跟踪

如图5-1是UE随机接入RNC信令跟踪

图5-1UE随机接入RNC信令跟踪

为了便于理解，结合图5-1的每个步骤，对信令进行说明。

2.2信令流程说明

2.2.1RRC链接请求（rrcConnectionRequest）

由UE通过专用信道PRACH或者公共信道发起，目前采用PRACH发起（这两者的区别是：

当RRC连接建立在公共信道上时，因为用的是已经建立好的小区公共资源，所以无需建立无线链路和用户面的数据传输承载，其余过程与RRC连接建立在专用信道相似。

），此前UE已经通过UpPTS和FPACH通过了上行初始同步和签名，并且通过FPACH获得PRACH的初始发射功率及发射时间。

PRACH（SF＝4，8，16，UE从BCH相应的广播消息得到）携带信息：

UE呼叫的第一条消息（RRC-ConnectionRequest）。

其他：

Node-B需要在收到UE消息后的4个子帧（20ms）内完成SS域和TPC控制消息的发送（FPACH）。

否则UE视此次同步建立的过程失败，在一定时间后将重新启动上行同步过程（可以重新发送，最大重复发送次数：

sync_ul发送次数：

8次，上行同步重复最大次数2次）。

UE在收到系统对上行同步请求的控制后，两帧之后在P-RACH信道上开始发送UE呼叫的第一条消息（RRC-ConnectionRequest），请求与系统建立RRC连接。

该消息使用P-RACH信道，发送时间和功率按照系统新的要求。

在发送这条消息时，UE与Node-B之间已经有很高的同步精度。

（1/8chip）

UE可用的P-RACH资源也与SYNC_UL有对应关系，在系统消息中说明。

在发送SYNC_UL时，UE已经知道为这次接入需要使用哪些F-PACH、P-RACH、CCPCH资源。

接下来的处理过程与GSM系统类似，UE与系统之间逐步建立完成RR连接建立、鉴权、加密、呼叫建立请求（Setup）等过程。

2.2.2RL建立（RadioLinkSetupMessage）

RNC收到UE发起的“RRC-ConnectionRequest”,向NodeB发送RLsetup消息，同样NodeB需要回一个RLsetup消息。

发送的内容，本文档不讨论。

2.2.3RRC链接建立（rrcConnnectionSetup）

RNC收到NodeB发的RLsetup消息后，RNC通过FACH（CCCH）信令给UE发送“rrcConnectionSetup”消息，主要参数：

UEIE，RBIE，TrCHIE，上行传输信道，下行传输信道，物理信道IE，UL无线资源和DL无线资源。

2.2.4RL恢复（RadioLinkRestore）

NodeB给RNC发送RL恢复消息，这个过程由NodeB用于通知一或多个无线链路或无线链路集的上行链路同步的到达和再到达。

（问题：

物理层又发了一次同步吗？

还是原来的同步出了问题？

是否与物理层有关？

理解，可能是为RRC完成提供RL链路，因为“RRCconnectionsetup”在FACH上，而“RRCconnectionsetupcomplete”在DCCH上）

2.2.5RRC链接建立完成（RRCConnectionSetupComplete）

由UE通过上行DCCH3.4kps发给RNC，“RRCConnectionSetupComplete”。

主要参数：

RRCtransactionidentifier：

RRC事务标识。

STARTlist：

开始列表，包含CN域标识和开始值列表信息。

UEradioaccesscapability：

UE无线接入特性。

UEradioaccesscapabilityextension：

UE无线接入特性扩展。

UEsystemspecificcapability：

UE系统特性。

至此RRC连接建立过程结束。

2.2.6初始直传（InitialDirectTransfer）

该信令为NAS信令，是UE与UTRAN之间的RRC连接建立成功之后，UE通过RNC建立与CN的信令链接，用于UE与CN交互NAS信息。

UE与CN之间的信令交互，对RNC都是直传消息，RNC在收到第一条直传消息时，即：

初始直传消息（InitialDirectTransfer），将建立与CN之间的信令连接，该连接建立在SCCP之上。

2.2.7UE初始消息（InitialUEMessage）

RNC接收到UE的初始直传消息，通过Iu接口向CN发送SCCP连接请求消息（CR），消息数据为RNC向CN发送的初始UE消息（InitialUEMessage），该消息带有UE发送到CN的消息内容。

2.2.8直传（DirectTransferMessage）

CN将“Authenticationrequest”通过直传的方式发给RNC

2.2.9下行直传（downlinkDirectTransfer）

RNC将“Authenticationrequest”通过下行直传的方式发给UE。

（应该在3.4k信令上传）

2.2.10上行直传（uplinkDirectTransfer）

UE将“Authenticationresponse”通过上行直传的方式发给RNC。

2.2.11直传（DirectTransferMessage）

RNC将UE的“Authenticationresponse”通过直传方式给CN。

CN对UE进行身份识别“Identityrequest”。

2.2.12下行直传（downlinkDirectTransfer）

RNC将信令“Identityrequest”以下行直传的方式发给UE。

2.2.13上行直传（uplinkDirectTransfer）

UE将“identityresponse”消息以上行直传的方式回给RNC。

2.2.14直传（DirectTransferMessage）

同样，RNC将该“identityresponse”以直传方式反馈给CN，并通过Iu接口向CN发送SCCP连接请求消息（PD_CC:

SETUP）,

如果CN准备接受连接请求，则向RNC回SCCP连接证实消息（CC），SCCP连接建立成功。

RNC接收到该消息，确认信令连接建立成功。

如果CN不能接受连接请求，则向RNC回SCCP连接拒绝消息（CJ），SCCP连接建立失败。

RNC接收到该消息，确认信令连接建立失败，则发起RRC释放过程。

2.2.15下行直传（downlinkDirectTransfer）

如果CN接收请求，RNC给UE回接收消息。

2.2.16RAB指派（RAB_AssignmentMessage）

RAB是指用户平面的承载，用于UE和CN之间传送语音，数据及多媒体业务。

RAB建立是由CN发起，UTRAN执行的功能，基本流程：

Ø首先由CN向UTRAN发送RAB指配请求消息，请求UTRAN建立RAB；

ØRNC发起建立Iu接口与Iub接口的数据承载；

ØRNC向UE发起RB建立请求；

ØUE完成RB建立，向RNC回应RB建立完成消息；

ØRNC向CN应答RAB指配响应消息，结束RAB建立流程。

具体如下：

2.2.16.1RAB指派（RAB_AssignmentMessage）

用户在初次建立信令连接后（其中空中接口的RRC连接建立在DCH上），CN根据其业务类型，为用户请求建立CS域上的业务承载；在CN发送的RAB_ASSIGNMENT中可一次要求在该域上为该用户建立一个或多个RAB的处理流程。

2.2.16.2RL同步重配置准备（SynchronisedRadioLinkReconfigurationPreparation）

根据无线链路重配置情况，RAB建立流程可分为同步重配置RL（DCH-DCH）与异步重配置RL（DCH-DCH）两种情况，二者的区别在于NodeB与UE接收到RNC下发的配置消息后，能否立即启用新的配置参数。

同步情况下，NodeB与UE在接收到RNC下发的配置消息后，不能立即启用新的配置参数，而是从消息中获取RNC规定的同步时间，在同步时刻，同时启用新的配置参数。

NodeB在接收到RNC下发的重配置RL消息后，不能立即启用新的配置参数，而是准备好相应的无线资源，等待接收RNC下发的重配置执行消息，从消息中获取RNC规定的同步时间。

UE在接收到RNC下发的配置消息后，也不能立即启用新的配置参数，而是从消息中获得RNC规定的同步时间。

RNC规定的同步时刻，NodeB与UE同时启用新的配置参数。

在图中的具体信令解释为：

（1）RNC向属下的NodeB发送协议的无线链路重配置准备RadioLinkReconfigurationPrepare消息，请求属下的NodeB准备在已有的无线链路上增加一条（或多条）承载RAB的专用传输信道（DCH）

（5）NodeB分配相应的资源，然后向所属的RNC发送RadioLinkReconfigurationReady消息，通知RNC无线链路重配置准备完成。

2.2.16.3RB建立（RadioBearerSetup）

RNC向UE发送RRC协议的RB建立消息RadioBearerSetup。

2.2.16.4RL同步重配置完成（SynchronisedRadioLinkReconfigurationCommit）

RNC向属下的NodeB发送无线链路重配置执行消息RadioLinkReconfigurationCommit。

2.2.16.5RL恢复（RadioLinkRestoreIndicationMessage）

与前面的RL恢复理解相似。

2.2.16.6RB建立完成（RadioBearerSetupComplete）

UE执行RB建立后，向RNC发送无线承载建立完成消息RadioBearerSetupComplete。

2.2.16.7RAB指派（RAB_AssignmentMessage）

RNC接收到无线承载建立完成的消息后，向CN回应RAB指配相应消息RadioAccessBearerAssignmentResponse，结束RAB建立流程。

2.2.17测量控制（measurementControl）

测量控制过程可以通过系统信息广播，也可以通过测量控制消息进行，图中的测量控制由UTRAN发起，UTRAN通过DCCH信道使用AMRLC模式MEASUREMENTCONTROL消息，UE只是被动接收。

LCRUE支持的七类测量类型：

频内测量（Intra-frequencymeasurement）：

测量与激活集相同频率的下行物理信道。

测量对象为一个小区。

频间测量（Inter-Frequencymeasurement）：

测量与激活集不同频率的下行物理信道。

测量对象为一个小区。

Inter-RAT测量（Inter-RATmeasurement）：

测量其他无线接入系统（如GSM）的下行物理信道。

测量对象为一个小区。

业务量测量（Trafficvolumemeasurement）：

测量上行链路的业务量。

测量对象为一个小区。

质量测量（Qualitymeasurement）：

测量下行链路专用传输信道的质量参数有两种：

下行BLER：

测量对象为一个下行传输信道；下行SIR（TDD）：

测量对象为下行专用（或共享）CCTrCH所对应各个时隙。

UE内部测量（UEinternalmeasurement）：

测量UE的发射功率、接收信号强度及TADV；

UE定位测量（UEpositioningmeasurement）：

测量UE的位置。

这里发起的测量估计主要是质量测量，为功控和同步服务。

2.2.18直传（DirectTransferMessage）

CN将“alerting”（主叫回铃）以直传方式发给RNC。

2.2.19下行直传（downlinkDirectTransfer）

RNC将“alerting”以下行直传方式发给UE。

（如果被叫也是在相同RNC下的UE，则可以看到两个alerting给不同的UE）

2.2.20直传（DirectTransferMessage）

CN以直传方式发送“CONNECT”给RNC。

（可能是被叫摘机）

2.2.21下行直传（downlinkDirectTransfer）

RNC以下行直传方式将“CONNECT”发送给UE。

2.2.22上行直传（uplinkDirectTransfer）

UE以上行直传方式将“CONNECTACKNOWLEDGE”给RNC。

2.2.23直传（DirectTransferMessage）

RNC将“CONNECTACKNOWLEDGE”以直传方式给CN。

图2是两个UE在相同RNC下的信令流程

3正常挂机流程

3.1挂机由主叫UE发起：

3.1.1RNC信令流程抓图

3.1.2简单说明

UE挂机后，通过DCCH（3.4kps）向RNC发起上行直传消息，RNC将“DISCONNECT”消息直传给CN，CN作出“RELEASE”消息给RNC，RNC将该信令下行直传给UE，UE通过DCCH上行直传“RELEASECOMPLETE”消息给RNC，RNC通过直传给CN确认，CN发起Iu链接释放给RNC，RNC需要作出响应。

RNC收到CN发起的Iu释放后，向UE发起RRC链接释放消息，UE收到后需要响应RNC，并完成RRC链接释放。

RNC收到UE上报的“rrcconnectionreleasecomplete”消息后，删除RNC与NodeB之间的RL。

3.2挂机由网络（CN）发起：

3.2.1RNC信令流程抓图

3.2.2简单说明

过程与UE挂机相似，所不同的是“DISCONNECT”由CN发起。

4硬切换流程

为了说明硬切换的流程，在此结合RNC信令跟踪的结果，对完整的接入、接通保持、切换流程进行说明。

（同一个RNC下的切换）

4.1主叫接入

主叫号码：

460060532001036，所在小区3631，时间：

16:

32:

35:

203

4.2被叫振铃

被叫号码：

460060532001033，所在小区3631，被叫振铃时间：

16:

32:

46:

421

4.3被叫接续

时间：

16:

32:

49:

546，序号：

139

4.4UE上报测量结果，准备切换

4.5物理信道重配

4.6RL恢复

4.7物理信道重配完成

4.8源小区RL删除

4.9关于硬切换流程的简单说明：

步骤1：

在硬切换过程中，UE首先进行将测量结果上报RNC（在RNC会给出每个NodeB的相邻小区的配置情况，这些相邻小区配置情况会在广播消息中通知UE，以便于UE进行切换前的邻区测量），见4.4。

步骤2：

RNC根据测量结果判断是否进行切换，如果满足切换条件，则通过3.4kps的信令通知UE进行物理信道重配，见4.5。

步骤3：

UE收到RNC发的物理信道重配后，在指定的码道向目标小区发送SB，（可以不收源小区的DPCH，此时，源小区的DPCH还是存在的），同时接收目标小区NodeB发送的下行SB（在目标小区没有收到上行SB的情况下，目标小区应该不会发送下行SB，但是如果NodeB上下行间通信有问题，目标小区可能会发送先发送下行SB，UE需要在相应的码道检测目标小区NodeB的下行SB）。

步骤4：

目标小区NodeB收到正确的SB（正确的TFCI）后，认为UE与目标小区的NodeB进行了同步，则目标小区NodeB给RNC发RL恢复消息，见4.6。

步骤5：

目标小区NodeB收到UE上行SB后，发送下行SB，用于UE下行同步。

步骤6：

UE收到目标小区发送的SB后（这个SB应该携带UE发送需要的TPC，SS提示），在指定码道通过目标小区NodeB向RNC发起物理信道重配完成消息，见4.7。

步骤7：

RNC收到UE通过目标小区NodeB发送的物理信道重配完成消息后，将源小区的RL删除，至此，正常的硬切换流程结束。

5异常流程及可能的原因

在测试中发现一些非正常的流程，可能是空口质量变差造成，需要引起注意。

5.1RB完成没有反馈，CN发起的非正常挂断，接入失败

5.1.1现象：

UEC0280000在收到RNC发出的“RBsetup”消息后，在规定的时间内（1.6s）需要完成RBsetup,并且向RNC反馈“RBsetupcomplete”消息，但是RNC侧没有收到该消息，导致接入失败。

5.1.2原因：

UE可能没有做RBsetup的响应，响应超时，或者UE没有收到RBsetup消息，RNC发给UE“RBsetup”后，UE要在1.6s内完成RB建立并作出响应，否则超时后CN将发出“DISCONNECT”信息，导致呼叫失败。

5.2小区更新导致接入失败

5.2.1现象

UE在接入过程中发起位置更新，CN接收该位置更新申请后，将释放对应的Iu口，导致接入失败。

5.2.2原因

UE在接入阶段，RNC对UE的位置更新申请没有做特殊处理，此处RNC可能需要做适当的修改。

5.3路由区更新导致接入失败

5.3.1现象

UE在接入过程中发起路由区更新，CN不接收该路由区更新申请，释放对应的Iu口，导致接入失败。

5.3.2原因

UE在接入阶段，RNC对UE的路由区更新申请没有做特殊处理，此处RNC可能需要做适当的修改。

5.4物理信道重配置失败导致切换失败

5.4.1现象

UE在切换过程中收到RNC下发的“物理信道重配”消息，但是UE反馈一个“物理信道重配失败”的消息给RNC，导致切换失败。

5.4.2原因

从流程看，UE应该是收到了目标NodeB下发的SB，但是目标NodeB可能没有收到UE上发的SB，目标小区与RNC没有进行RL恢复。

与正常的切换流程比较，出现这种情况可能是UE收到SB时已经超时，正常流程如下，其时间大约有0.6s时间，而“物理信道重配失败”情况下，时间为1.5s。

5.5无法正常接入

暂时没有抓屏

6其他

6.1测量上报的结果

从测量上报中可以看到UE端测量的相邻小区标识以及相应的RSCP值，这个值需要减去116dBm，（理解：

这个116dBm可能是UE端的放大增益）。