长春TDSCDMA接入时长研究报告科虹.docx

长春TDSCDMA接入时长研究报告科虹.docx

《长春TDSCDMA接入时长研究报告科虹.docx》由会员分享，可在线阅读，更多相关《长春TDSCDMA接入时长研究报告科虹.docx（30页珍藏版）》请在冰豆网上搜索。

长春TDSCDMA接入时长研究报告科虹

长春TDSCDMA接入时长研究报告

目录

一、概述2

二、基础信息2

2.1长春、深圳和长沙数据2

2.2核心网和设备厂商2

2.3信令流程2

2.3.1RRC连接建立流程2

2.3.2主叫呼叫流程5

2.3.3被叫呼叫流程9

2.3.4鉴权信令流程13

2.3.5加密信令流程13

2.3.6动态信道分配14

三、三地数据对比14

3.1RRC连接建立16

3.2鉴权加密16

3.3业务信道建立时长17

3.4寻呼时延19

3.5大唐片区以华为片区数据对比21

四、结论23

五、结束语24

一、概述

由于近期长春各测试优化公司在做T网混网测试中出现T网平均接入时长较长问题。

我公司对T网平均接入时长进行分析，并与我公司在深圳、长沙宏站测试数据进行数据对比分析。

分析结果显示，长春T网平均接入时长要比深圳和长沙T网平均接入时长要长2.5s左右。

接入时长过长的主要原因主要体现在：

1.长春和长沙层三信令中都含有鉴权加密信令，深圳的信令中没有，深圳比长春节省了0.44s。

2.长春业务信道建立时长主被叫均比长沙、深圳长0.6s左右，一共就是1.2s左右。

3.寻呼时延方面长春要比深圳和长沙长2s左右。

上述三点导致接续时延增加了3.64S左右的时长。

二、基础信息

2.1长春、深圳和长沙数据

1.长春最近2次测试数据（1次全网测试数据，一次吉林大街以南测试数据）；

2.深圳最近20次（6个RNC）测试数据；

3.长沙最近20次全网测试数据。

4.华为片区数据。

2.2核心网和设备厂商

地域

TD核心网（CS域）

TD设备

长春

华为

大唐/华为

深圳

华为

中兴/华为

长沙

摩托

中兴

2.3信令流程

2.3.1RRC连接建立流程

UE处于空闲模式下，当UE的非接入层请求建立信令连接时，UE将发起RRC连接建立过程。

每个UE最多只有一个RRC连接。

当RNC接收到UE的RRCCONNECTIONREQUEST消息，由其无线资源管理模块RRM根据特定的算法确定是接受还是拒绝该RRC连接建立请求，如果接受，则再判决是建立在专用信道还是公共信道。

对于RRC连接建立使用不同的信道，则RRC连接建立流程也不一样。

ØRRC连接建立在专用信道

图3.8

信令流程说明：

（1）UE在上行CCCH上发送一个RRCConnectionRequest消息，请求建立一条RRC连接。

主要参数为：

InitialUEIdentity：

初始的UE标识，如IMSI，TMSI等参数，用来让网络识别发送该建立请求消息的UE；

Establishmentcause：

建立原因，有多种类型，但UE每次只能选择其一。

ProtocolErrorIndicator：

协议错误标识，用来标明是否有协议错误发生。

测量IE：

给出在Uu接口上的测量结果；

（2）RNC根据RRC连接建立请求的原因及系统的资源状态决定UE建立在专用信道并分配RNTI和L1，L2资源。

（一般情况下在发起电路型业务或Speech业务、以及QoS较高的分组业务时，尽可能的将RRC连接建立在DCH上）。

（3）RNC向NodeB发送RadioLinkSetupRequest消息，请求NodeB分配RRC连接所需要的特定无线链路资源。

在该消息中包含有建立无线链路所必需的参数（功率、时隙、扰码、midable码等参数）。

（4）在RL成功建立后，RNC使用ALCAP协议发起Iub接口用户面传输承载的建立（用于承载RRC信令的ATM连接，并完成RNC与NodeB同步过程。

（5）RNC在下行CCCH上向UE发送RRCConnectionSetup消息。

主要参数：

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

（6）UE在上行DCCH上向RNC发送RRCConnectionSetupComplete。

主要参数：

RRCtransactionidentifier：

RRC事务标识。

STARTlist：

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

UEradioaccesscapability：

UE无线接入特性。

UEradioaccesscapabilityextension：

UE无线接入特性扩展。

UEsystemspecificcapability：

UE系统特性。

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

ØRRC连接建立在公共信道

图3.9

信令流程说明：

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

2.3.2主叫呼叫流程

在UE发起呼叫建立时，如果之前UE没有建立RRC连接则先建立RRC连接，再通过初

始直传建立传输NAS消息的信令连接，最后建立RAB。

以下为UE处于Idle状态下发起CS呼叫的流程。

主要过程介绍如下：

建立RRC连接：

（1）UE在取得下行同步后，向NodeB发送SYNC_UL，接收到NodeB回应的FPACH信息后，在RACH信道上向RNC发送RRCConnectionRequest消息，发起RRC连接建立过程。

主要参数：

InitialUEIdentity,Establishmentcause,InitialUECapability.

（2）RNC准备建立RRC连接，分配建立RRC连接所需要的资源，并发送一条RadioLinkSetupRequest消息给NodeB。

主要参数：

Cellid,TransportFormatSet,TransportFormatCombinationSet,frequency,TimeSlots,信道码,Powercontrolinformation.

（3）NodeB配置物理信道，在新的物理信道上准备接收UE消息，并给RNC发送一条RadioLinkSetupResponse响应消息。

主要参数：

Signallinglinktermination,Transportlayeraddressinginformation（AAL2address,AAL2BindingIdentity）fortheIubDataTransportBearer.

（4）RNC通过ALCAP协议，建立Iub数据传输承载。

Iub数据传输承载通过AAL2的绑定标识与DCH绑定在一起。

建立Iub数据传输承载需要NodeB确认。

（5）（6）通过DownlinkSynchronisation和UplinkSynchronisation.控制帧，NodeB与RNC为Iub数据传输承载建立同步，此后NodeB开始DL发送。

（7）RNC在FACH信道上发送RRCConnectionSetup消息给UE。

主要参数：

InitialUEIdentity,RNTI,CapabilityupdateRequirement,TransportFormatSet,TransportFormatCombinationSet,frequency,TimeSlots,信道码,Powercontrolinformation.

（8）UE在DCCH上发送RRCConnectionSetupComplete消息给RNC，RRC连接建立完成。

主要参数：

Integrityinformation,cipheringinformation.

建立初始直传/上下行直传：

（9）UE在DCCH上给RNC发送一条InitialDirectTransfer（CMServiceRequest）消息，该消息包括了UE请求的业务类型等信息。

主要参数：

InitialNASMessage（couldforaGSMbasedCNbee.g.CMServiceRequest,LocationUpdateRequestetc.）CNnodeindicator（itindicatesthecorrectCNnodeintowhichtheNASmessageshallbeforwarded）

（10）RNC发起初始到CN的信令连接，并发送一条InitialUEMessage消息给CN，通知CN关于UE请求的业务等内容。

主要参数：

NASPDU（couldforaGSMbasedCNbee.g.CMServiceRequest,LocationUpdateRequestetc.）,CNdomainindicator（indicatingtheCNdomaintowardswhichthismessageissent）

通过初始直接传输过程后，可使用该信令连接传输UE和CN之间的NAS消息。

（11）CN发送RANAP消息DirectTransfer（AuthenticationRequest）到RNC，要求对UE进行鉴权。

（12）RNC发送RRCDownlinkDirectTransfer（AuthenticationRequest）消息给UE。

主要参数：

NASMessage

NAS消息由UTRAN透明的传输到UE

（13）UE发送RRCUplinkDirectTransferMessage（AuthenticationResponse）消息给RNC，告知网络侧UE已经按照鉴权要求完成了鉴权。

主要参数：

NASMessage

（14）RNC发送RANAP消息DirectTransfer给CN，将UE的NAS消息转发给CN。

主要参数：

NASPDU

NAS消息被透明的传输到UTRAN。

安全模式控制：

（15）CN发送RANAP消息SecurityModeCommand给RNC，要求终端进行安全模式控制。

（16）RNC在下行DCCH上发送RRCSecurityModeCommand给UE，开始/重启加密过程。

（17）UE成功应用新的加密方式后，在上行DCCH上发送RRCSecurityModeComplete给RNC

（18）RNC发送RANAP消息SecurityModeComplete给CN，双方完成安全模式控制。

建立RAB：

（19）（20）（21）（22）上行和下行的直接传输过程，NAS要求传输数据，UE向网络侧说明BearerCapability以及CalledNumber等内容。

（22）CN向RNC发送RANAP消息CommonID，告知RNC该UE的IMSI。

（23）CN向RNC发送RANAP消息RadioAccessBearerAssignmentRequest，发起RAB建立过程。

主要参数：

RadioAccessBearerparameters,UserPlaneMode,TransportAddress,IuTransportAssociation.

（24）RNC通过ALCAP协议建立Iu数据传输承载，并利用AAL2绑定标识将Iu数据传输承载和无线接入承载绑定在一起。

（25）RNC要求其NodeB准备建立DCH来承载RAB（RadioLinkReconfigurationPrepare）

主要参数：

TransportFormatSet,TransportFormatCombinationSet,Powercontrolinformation,TimeSlots,信道码.

（26）NodeB配置资源并通知RNC准备完毕（RadioLinkReconfigurationReady）

主要参数：

Transportlayeraddressinginformation（AAL2address,AAL2BindingId）forIubDataTransportBearer.

（27）RNC通过ALCAP协议建立Iub数据传输承载，并利用AAL2绑定标识将Iub数据传输承载绑定到DCH。

（28）（29）NodeB和RNC通过DownlinkSynchronisation和UplinkSynchronistionDCH-FP帧为Iub数据传输承载建立同步关系。

（30）RNC向NodeB发送NBAP消息RadioLinkReconfigurationCommit

（31）RNC向UE发送RRC消息RadioBearerSetup

主要参数：

TransportFormatSet,TransportFormatCombinationSet,TimeSlots,信道码.

（32）UE按照新的传输格式发送RRC消息RadioBearerSetupComplete给RNC。

（33）RNC发送RANAP消息RadioAccessBearerAssignmentResponse给CN，RAN建立完成。

之后进行上行和下行的直接传输过程，对方振铃后，CN通过RNC向UE发送直传消息Alerting，对方摘机后，CN通过RNC向UE发送直传消息Connect，UE回复直传消息ConnectACK消息，双方建立通话。

2.3.3被叫呼叫流程

以下说明当UE处于Idle状态时，被其他用户呼叫时的信令流程。

接上页。

接上页。

相对于UE发起呼叫的流程来说，UE被呼的流程多了寻呼的过程，寻呼过程后开始发起RRC连接过程。

寻呼过程：

（34）CN通过RANAP消息PAGING在特定区域（包括一个或多个RNC）内寻呼某个UE。

主要参数：

CNDomainIndicator,PermanentNASUEIdentity,TemporaryUEIdentity,PAGINGCause.

（35）RNC利用PAGINGType1消息寻呼UE。

如果UE检测到从RNC来的寻呼消息和自己是对应的，则执行随后的RRC信令连接建立过程。

此后再进行NAS消息的传输。

2.3.4鉴权信令流程

鉴权流程由网络侧发起，其目的是：

由网络来检查是否允许终端接入网络；提供鉴权参数五元组中的随机数数组，供终端计算出加密密钥（CK）；同时，供终端计算出与网络侧进行一致性检查的密钥（IK）；最后一个目的是可以提供终端对网络的鉴权。

与GSM的鉴权相比，3G的鉴权流程增加了一致性检查的功能及终端对网络的鉴权功能。

这些功能使3G安全特性有了进一不的增强。

（1）流程图

图3.39

（2）信令流程说明

Ø网络侧在发起鉴权前，如果VLR中还没有鉴权参数，此时将首先发起到HLR取鉴权集的过程，并等待鉴权参数的返回。

鉴权参数五元组的信息包含RAND，XRES，AUTN，CK和IK。

Ø在检测到鉴权参数存在后，网络下发鉴权请求消息。

此消息中将包含某个五元组的RAND和AUTN。

用户终端对网络进行鉴权，如果接收，USIM卡将利用RAND来计算出CK与IK和签名XRES。

如果USIM认为鉴权成功，在鉴权相应消息中将返回XRES。

Ø网络侧在收到鉴权相应消息后，比较鉴权相应消息中的XRES与存储在VLR数据库中的鉴权参数五元组的XRES,确定鉴权是否成功：

成功则继续后面的流程；不成功则会发起异常处理流程，释放网络侧与终端间的连接，并释放被占用的网络资源，无线资源。

在成功的鉴权之后，终端将会把CK（加密密钥）与IK（一致性检查密钥）存放到USIM卡中。

2.3.5加密信令流程

安全模式控制过程是由网络侧用来向无线接入网侧发送加密信息的。

在此过程中，核心网的网络侧将与无线接入网协商对用户终端进行加密的算法，使得用户在后续的业务传递过程中使用加密算法；并且在终端用户发生切换后，尽可能的仍使用此加密算法－即用于加密的有关参数会送到切换的RNC。

（1）流程图

图3.40

（2）信令流程说明

ØCN向RNC发送要求加密的指令；RNC在收到CSCN的加密指令后，向测试终端发送加密指令，启动加密。

2.3.6动态信道分配

在TD-SCDMA系统中，采用动态信道分配（DCA）方式，系统中的任何一条物理信道都是通过它的载频/时隙/扩频码的组合来标记的。

信道分配实际上就是一种无线资源的分配过程。

在DCA技术中，信道并不是固定地分给某个小区，而是被集中在一起进行分配；只要能提供足够的链路质量，任何小区都可以将该信道分给呼叫。

DCA具有频带利用率高、无需信道预规划、可以自动适应网络中负载和干扰的变化等优点。

其缺点在于，DCA算法相对于FCA（固定信道分配）来说较为复杂，系统开销也比较大。

DCA算法又分为慢速DCA和快速DCA，慢速DCA将无线信道分配至小区，而快速DCA将信道分至业务。

RNC管理小区的可用资源，并将其动态分配给用户，具体的分配方式就取决于系统负荷、业务QoS要求等参数。

因此，DCA算法有很多种。

目前使用最多的是基于干扰测量的DCA算法，这种算法根据移动台反馈的实时干扰测量结果分配信道。

好的DCA算法可提高频带的利用率，并可自适应地减轻系统负荷，同时也省去了网络规划中信道规划与分配的环节。

但是，如果采用的DCA算法与实际情况不符，则会适得其反。

三、三地数据对比

本次我司特将深圳与长沙的宏站测试数据拿来对比，长沙和深圳选取最近20次的测试数据，长春选取我司最近测试的两次数据，如下表：

序号

地域

测试时间

TD平均接入时长

地域

测试时间

TD平均接入时长

地域

测试时间

TD平均接入时长

1

长沙

2009-8-12

5.47

深圳

2009-7-1

6.27

长春

2009-11-8

8.165

2

长沙

2009-8-16

5.88

深圳

2009-7-9

5.43

长春

2009-11-13

8.64

3

长沙

2009-8-20

5.25

深圳

2009-7-15

5.26

4

长沙

2009-8-25

5.54

深圳

2009-7-20

6.02

5

长沙

2009-8-28

6.23

深圳

2009-7-25

5.40

6

长沙

2009-9-2

5.47

深圳

2009-8-1

5.46

7

长沙

2009-9-6

5.44

深圳

2009-8-7

5.45

8

长沙

2009-9-10

5.79

深圳

2009-8-12

6.33

9

长沙

2009-9-15

5.32

深圳

2009-8-18

5.99

10

长沙

2009-9-19

5.45

深圳

2009-8-25

5.47

11

长沙

2009-9-24

5.31

深圳

2009-9-1

5.87

12

长沙

2009-9-28

5.49

深圳

2009-9-7

5.67

13

长沙

2009-10-9

5.66

深圳

2009-9-14

5.67

14

长沙

2009-10-13

6.11

深圳

2009-9-20

5.37

15

长沙

2009-10-17

5.42

深圳

2009-9-28

5.64

16

长沙

2009-10-22

6.01

深圳

2009-10-9

6.37

17

长沙

2009-10-28

5.42

深圳

2009-10-17

5.24

18

长沙

2009-11-2

5.57

深圳

2009-10-25

6.08

19

长沙

2009-11-6

5.53

深圳

2009-11-2

6.14

20

长沙

2009-11-10

5.79

深圳

2009-11-12

5.60

平均值

5.61

平均值

5.74

平均值

8.40

表1

对三地数据进行信令对比，如下图：

图1三地主叫信令流程对比

图1是长春、长沙和深圳的主叫建立时长的信令流程，统计出时间如下表：

地域

主叫接入时长

被叫响应接入时长

长春

8.04s

3.49s

长沙

5.65s

2.48s

深圳

4.5s

2.2s

表2

表2长春一个主叫呼叫建立时长和被叫响应接入时长为为7.9s和3.57s，长沙为5.65s和2.48s，深圳为4.5s和2.2s，比长沙长2.39和1.01s，比深圳长3.54s和1.29s，针对该问题我们主要从一下几点进行分析。

3.1RRC连接建立

对三地数据进行分析发现，三地信令中RRC建立时间相差不大，如下图：

见下表

地域

RRC连接

建立时间

长春

0.52s

长沙

0.45s

深圳

0.56s

通过上表对比，三地的RRC连接建立时间相差不大。

3.2鉴权加密

对三地数据进行分析发现，三地信令中长春与长沙的信令中有鉴权和加密信令，深圳信令中无鉴权加密信令；

见下表

地域

主叫鉴权

加密时长

被叫加密时长

长春

0.43s

0.01s

长沙

0.53s

0.01s

深圳

0s

0s

通过上表对比，长沙T网鉴权和加密使用的时间最长，深圳T网信令中无鉴权加密信令。

3.3业务信道建立时长

对信令进行对比发现长春主、被叫业务信道建立时长均比长沙和深圳长，如下图：

见下表

地域

主叫业务信道建立时长

被叫业务信道建立时长

长春

1.13s

1.15s

长沙

0.5s

0.48s

深圳

0.59s

0.59s

通过上表对比，发现长春在主叫和被叫业务信道建立时长要比长沙长0.63s和0.67s，要比深圳长0.54s和0.56s。

整个呼叫就要比长沙多1.3s，要比深圳多1.1s。

长春业务信道建立时长比长沙和深圳建立时长长1.2s左右是长春接入时长长的一个原因。

从UE码流和UU口信令来看，我们截取了大唐UE码流信令流程，如下图

大唐UE码流信令

UU口码流信令

从UE码流和UU口码流来看，业务信道建立时间是比较长（2s），跟资源配置和算法有关。

3.4寻呼时延

对信令进行对比发现长春主叫从setup至振铃的时间要比长沙和深圳长，如下图：

见下表

地域

Setup到响铃

时间

长春

6.44s

长沙

4.31s

深圳

4.64s

通过上表可以发现，长春setup至响铃时间为6.44s左右，比长沙