01RANAP.docx

01RANAP.docx

《01RANAP.docx》由会员分享，可在线阅读，更多相关《01RANAP.docx（28页珍藏版）》请在冰豆网上搜索。

01RANAP

第1章RANAP

1.1概述

无线接入网络应用部分（RadioAccessNetworkApplicationPart，RANAP）是七号信令系统（SS7）用户层信令，是UMTS陆地无线接入网（UTRAN）与核心网（CN）之间的电路域控制面接口（即Iu-CS接口）协议。

1.1.1Iu-CS接口定义及功能

Iu接口是UMTS陆地无线接入网（UTRAN）与核心网（CN）之间的接口。

根据提供服务性质的不同，CN（CoreNetwork）分为：

CS（CircuitSwitched）域、PS（PacketSwitched）域和BC（Broadcast）域。

CS域为用户提供电路型业务，PS域提供分组型业务，BC域则提供广播类业务。

与这三个逻辑上独立的CN域对应的Iu接口分别标记为Iu-CS、Iu-PS、Iu-BC。

Iu接口基本结构如图1-1所示。

图1-1Iu接口基本结构

对于RNC与CN之间的Iu接口定义如下：

（2）一个RNC与CS域的CN之间最多存在一个Iu-CS接口；

（3）一个RNC与PS域的CN之间最多存在一个Iu-PS接口；

（4）一个RNC与BC域之间可以存在多个Iu-BC接口。

Iu接口实现的主要功能有：

●无线接入承载（RAB）管理功能

●无线资源管理功能

●速率适配功能

●Iu连接管理功能

●Iu接口用户面管理功能

●移动性管理功能

●安全性管理功能

●业务和网络接入功能

●Iu协调功能（寻呼协调和重定位协调）

MSOFTX3000作为核心网电路域功能实体，通过Iu-CS接口实现与UTRAN的连接，其接口运行RANAP协议。

1.1.2协议结构

3GPP规范25.410描述的Iu-CS接口协议结构如图1-2所示。

图1-1Iu-CS协议结构

根据Iu-CS协议垂直平面结构，Iu-CS接口协议包括：

●控制面：

包括控制面信令RANAP（TS25.413）和信令承载（TS25.412）

●用户面：

包括用户面协议IuUP（TS25.415）和数据承载（TS25.414）

●传输网络控制面：

包括数据承载控制信令ALCAP（ITU-TQ.2630.1和ITU-TQ.2630.2）和信令承载（TS25.414）进行描述。

1.1.3RANAP在MSOFTX3000中的应用

MSOFTX3000在UMTS系统中用作MSCServer，是核心网控制面设备。

RANAP协议应用于MSOFTX3000与无线网络控制器（RNC）之间的接口上，该接口在UMTS定义为Iu-CS接口，如图1-3所示。

图1-1RANAP协议在MSOFTX3000中的应用

由于MSOFTX3000应用于分离网关体系的控制层，对外提供信令控制接口，所以Iu-CS接口在MSOFTX3000只体现在控制面协议：

RANAP。

用户面协议（IuUP）则体现在媒体网关（MGW）与RNC的接口上。

1.1.4Iu-CS协议栈结构

Iu-CS协议栈结构如图1-4所示，MSOFTX3000支持两种信令承载方式：

基于ATM的宽带SS7信令系统（SAAL-NNI、MTP3b、SCCP）和基于IP承载的信令传输系统（IP、SCTP、M3UA）。

图1-1Iu-CS接口协议栈结构

Iu-CS接口协议栈从层次上可以分为两部分：

一部分是无线网络层的无线接入网应用协议，采用RANAP协议（TS25.413）；一部分是信令承载，位于传输网络层。

1.2RANAP协议介绍

1.2.1RANAP基本过程分类

RANAP负责Iu-CS接口CN和RNC之间的信令交互，它是由一个或多个基本过程（ElementaryProcedures，简称EPs）组合构成上节所述的各种功能。

下面从应答方式和消息传送方式对这些基本过程（EPs）进行分类。

1.从应答方式分

RANAP的基本过程从应答方式上可以分为三类：

CLASS1、CLASS2和CLASS3。

●CLASS1：

有应答（成功/失败）。

这种类型应答的“成功”指基本过程成功执行并收到对端成功应答；“失败”指过程执行失败并收到对端失败应答或者定时器超时而未收到应答。

还有一种“成功和失败”的结果，是指过程发出的不同请求得到不同的成功或失败的应答，也属于有应答的一种。

●CLASS2：

无应答。

这种类型的基本过程被假定为总是执行成功的。

●CLASS3：

多应答（一个或多个应答）。

这种类型包含多种应答，包括对基本过程发起的请求的成功或失败的不同执行结果和此请求的临时状态信息的应答报告。

RANAP的3类基本过程的相关消息如表1-1～表1-3所示。

表1-1Class1（有应答）

基本过程

起始消息

应答消息

成功结果

失败结果

IuRelease

IURELEASECOMMAND

IURELEASECOMPLETE

RelocationPreparation

RELOCATIONREQUIRED

RELOCATIONCOMMAND

RELOCATIONPREPARATIONFAILURE

RelocationResourceAllocation

RELOCATIONREQUEST

RELOCATIONREQUESTACKNOWLEDGE

RELOCATIONFAILURE

RelocationCancel

RELOCATIONCANCEL

RELOCATIONCANCELACKNOWLEDGE

SRNSContextTransfer

SRNSCONTEXTREQUEST

SRNSCONTEXTRESPONSE

SecurityModeControl

SECURITYMODECOMMAND

SECURITYMODECOMPLETE

SECURITYMODEREJECT

DataVolumeReport

DATAVOLUMEREPORTREQUEST

DATAVOLUMEREPORT

Reset

RESET

RESETACKNOWLEDGE

ResetResource

RESETRESOURCE

RESETRESOURCEACKNOWLEDGE

表1-2Class2（无应答）

基本过程

消息

RABReleaseRequest

RABRELEASEREQUEST

IuReleaseRequest

IURELEASEREQUEST

RelocationDetect

RELOCATIONDETECT

RelocationComplete

RELOCATIONCOMPLETE

SRNSDataForwardingInitiation

SRNSDATAFORWARDCOMMAND

SRNSContextForwardingfromSourceRNCtoCN

FORWARDSRNSCONTEXT

SRNSContextForwardingtoTargetRNCfromCN

FORWARDSRNSCONTEXT

Paging

PAGING

CommonID

COMMONID

CNInvokeTrace

CNINVOKETRACE

CNDeactivateTrace

CNDEACTIVATETRACE

LocationReportingControl

LOCATIONREPORTINGCONTROL

LocationReport

LOCATIONREPORT

InitialUEMessage

INITIALUEMESSAGE

DirectTransfer

DIRECTTRANSFER

OverloadControl

OVERLOAD

ErrorIndication

ERRORINDICATION

表1-3Class3（多应答）

基本过程

起始消息

应答消息

RABAssignment

RABASSIGNMENTREQUEST

RABASSIGNMENTRESPONSExN（N>=1）

2.从消息传送方式分

从消息传送方式分，RANAP的基本过程可以分为两类：

面向连接型和无连接型。

前者在属于特定UE的专用信令连接上传送，后者在共同的信令连接上传送。

其中，复位（Reset）、复位资源（ResetResource）、流量控制（OverloadControl）、寻呼（Paging）采用SCCP无连接业务进行传递；错误指示（ErrorIndication）按具体情况决定采用无连接业务还是面向连接业务；其它流程采用面向连接业务。

面向连接的消息都是特定UE与网络间的消息，如UE的位置更新流程，呼叫流程；无连接消息是与系统维护管理有关的消息，影响部分或所有的UE用户。

RANAP无连接消息大多是可以上下行双向的（PAGING消息除外），面向连接的消息大多是单向的（ERRORINDICATION和DIRECTTRANSFER消息除外）。

1.2.2RANAP基本过程描述

1.RAB指配（RadioAccessBearerAssignment）

RAB指配由CN侧发起，但CN只是确定RABID的值和相关的RAB参数，由RNC执行请求，分配用户面资源，并利用一个或多个应答向CN返回结果。

消息流程如图1-5所示。

图1-1RAB指配消息流程

说明：

*：

Q.2630.1消息只有在Iu-CS接口才有，Iu-PS接口是没有的。

**：

表示可能有多个响应。

具体流程如下：

（2）CN发出请求（可在一个消息中对多个RAB进行请求），并启动定时器TRABAssgt。

RNC接到请求后，执行请求，把暂时不能处理的请求放入队列，在第一个返回的RAB指配响应中必须包含CN请求的RAB的情况。

（3）如果队列中没有RAB，CN在接到第一个RAB指配响应后终止TRABAssgt，并结束无线接入承载分配过程；如果有队列，RNC启动定时器TQEUING，并将RAB排队的执行结果通过RAB指配响应返回给CN（可以一个一个返回或一次返回多个RAB的结果）

（4）若RNC在TQEUING到之前执行完排队的RAB，则停止TQEUING计时，返回RAB指配响应，结束无线接入承载分配过程；若TQEUING到而RNC未执行完队列中的RAB分配请求，则RNC结束队列执行，返回RAB指配响应，结束无线接入承载分配过程。

（5）若CN在TRABAssgt到之前收到所有的排队的RAB的执行结果，则停止TRABAssgt计时，结束无线接入承载分配过程；若TRABAssgt到而未收到所有的排队RAB的执行结果，结束无线接入承载分配过程，并认为未返回结果的RAB执行失败。

2.RAB释放请求（RABReleaseRequest）

RNC使用该过程向CN请求对相应RAB资源的释放，属于无应答、面向连接型基本过程。

消息流程如图1-6所示。

当RNC侧检测到RABID对应的用户面资源发生了故障，一般情况下会向CN发起RAB释放请求消息。

图1-1RAB释放请求消息流程

3.Iu释放请求（IuReleaseRequest）

该过程用于RNC向CN请求释放和特定UE连接的Iu资源。

这是由于UTRAN的原因引起的，如“操作用户干预”、“用户休止”、“RNC和UE的连接丢失”等。

Iu释放请求过程属于无应答、面向连接型。

消息流程如图1-7所示。

图1-1Iu释放请求消息流程

若一个UE存在两个Iu连接，则该消息发给和要释放的Iu连接相对应的CN域。

4.Iu释放（IuRelease）

该过程用于释放Iu连接以及与此Iu连接有关的UTRAN端的资源，属于有应答、面向连接型。

此过程由CN发起，发起原因至少包含如下：

●UE和CN间事务结束；

●CN接收到了IuReleaseRequest消息；

●SRNS的重定位结束。

该过程的消息流程如图1-8所示。

图1-1Iu释放消息流程

5.SRNS的重定位（Relocation）

该过程用于将SRNS（ServingRNS）从一个RNS重定位到另一个RNS，这个过程可以分为重定位准备、重定位资源分配、重定位检测、重定位完成几个阶段，另外还包括重定位取消过程。

（1）重定位准备（RelocationPreparation）

重定位消息流程如图1-9、图1-10所示。

图1-1重定位准备流程（成功情况）

图1-2重定位准备流程（失败情况）

具体流程解释如下：

●成功情况

SourceRNC向CN发出RELOCATIONREQUIRED消息请求重定位并告之原因，启动定时器TRELOCprep。

CN端成功处理请求后，返回RELOCATIONCOMMAND消息，终止这个重定位准备过程。

如果此时SourceRNC已经准备好，它就可以触发这个SRNS的重定位执行动作。

●失败情况

若CN或目标RNC（TargetRNC）不能接受这个重定位请求或者这个过程中任何环节失败，则CN向SRNC返回RELOCATIONPREPARATIONFAILURE消息，如果CN与TargetRNC已经建立了Iu连接，则CN向TargetRNC发送Iu释放消息，原因为“重定位取消”。

终止该过程，继续使用以前的Iu连接。

若SourceRNC在TRELOCprep到而未收到CN对RELOCATIONREQUIRED消息的响应，则向CN开始重定位取消过程。

（2）重定位资源分配（RelocationResourceAllocation）

该过程用于为某一重定位过程分配目标RNS资源，协调与特定UE的Iu连接资源，属于有应答、面向连接型过程。

消息流程如图1-11、图1-12所示。

图1-1重定位资源分配流程（成功情况）

图1-2重定位资源分配流程（失败情况）

具体流程解释如下：

●成功情况：

CN向TargetRNC发起重定位请求，此请求中带有一系列TargetRNC所需建立的资源参数，启动TRELOCalloc。

TargetRNC检查CN所请求资源的可用性，然后进行资源的建立，当所有的资源包括用户面的设置都已经成功建立后，返回重定位请求证实消息（RELOCATIONREQUESTACKNOWLEDGE），终止该过程。

●失败情况：

若TargetRNC不能接受这个重定位请求或者这个过程中任何环节失败，则TargetRNC返回重定位失败消息（RELOCATIONFALIURE），CN接收此消息后，终止TRELOCalloc，并释放与TargetRNC相关的资源。

（3）重定位检测（RelocationDetect）

该过程用于TargetRNC向CN指示已经检测到重定位的执行，属于无应答、面向连接型过程。

消息流程如图1-13所示。

图1-1重定位检测流程

当TargetRNC收到重定位执行触发后，向CN发重定位检测消息（RELOCATIONDETECT），并开始SRNC角色。

CN收到重定位检测消息后，将用户面从SRNC切换到TargetRNC。

（4）重定位完成（RelocationComplete）

该过程用于RNC向CN指示已经完成SRNS重定位，属于无应答、面向连接型过程。

消息流程如图1-14所示。

图1-1重定位完成流程

当新的SRNC-ID和S-RNTI（ServingRNCRadioNetworkTemporaryIdentity）已经通过无线协议成功地与UE交换时，TargetRNC将向CN返回重定位完成消息，并终止整个重定位过程。

CN收到重定位完成消息后，开始释放与SRNC的连接。

（5）重定位取消（RelocationCancel）

该过程用于源RNC取消一个正在进行的SRNS重定位过程，发生在重定位准备过程后，属于有应答、面向连接型过程。

该基本过程有两个发起原因：

●若源RNC在TRELOCprep到而未收到重定位请求消息，则向CN开始重定位取消过程；

●由于UE的原因，源RNC主动发出该消息。

源SRNC发出重定位取消消息后终止Relocation过程；CN收到重定位取消消息后，终止RelocationPrepare过程。

消息流程如图1-15所示。

图1-1重定位取消流程

6.寻呼（Paging）

该过程用于CN对一个特定的UE发寻呼消息，属于无应答、无连接型。

当UE处于空闲模式时，将利用公共的寻呼信道进行寻呼；当UE已经有RRC（RadioResourceControl）连接时，将在其专用的RRC连接上进行寻呼。

消息流程如图1-16所示。

图1-1寻呼流程

7.公共ID（CommonID）

该过程用于在UE建立RRC连接之后，将UE的通用标识符（如IMSI）与RRC连接相关联并在RNC中保存起来，便于以后寻呼消息在RRC连接上的传输，属于无应答、面向连接型。

消息流程如图1-17所示。

图1-1COMMONID流程

在RNC与CN建立连接之后，CN要尽快将UE的公共ID通知给RNC。

这样，当UE与CN中的一个域（如PS域）已经建立呼叫之后，若另一个域（如CS域）要寻呼此UE，RNC就通过此UE的COMMONID找到对应的PS域的RRC连接（对于同一个UE来说，PS与CS总是共用同一个RRC连接的），然后在此RRC连接专用信道上将此PAGING消息下发给UE。

若RNC不支持此功能，在上述情况下，RNC就将PAGING从公共寻呼信道下发，这样，UE检测不到此PAGING消息，就导致寻呼失败。

8.对UE活动的追踪（CNInvokeTrace）

该过程用于通知RNC对特定UE的活动进行追踪，并将结果报告给指定的操作维护中心（OMC），属于无应答、面向连接型过程。

消息流程如图1-18所示。

图1-1UE活动的追踪流程

9.安全模式控制（SecurityModeControl）

该过程用于CN向UTRAN传送进行加密和一致性保护的信息。

UTRAN在之后的RAB连接建立、重定位等过程中将使用这些算法。

该过程属于有应答、面向连接型。

消息流程如图1-19、图1-20所示。

图1-1安全模式控制流程（成功情况）

图1-2安全模式控制流程（失败情况）

10.UE位置报告控制（LocationReportingControl）

该过程用于CN要求RNC提供对特定UE的位置报告，控制参数包括开始报告、修改报告和停止报告等类型，属于无应答、面向连接型过程。

消息流程如图1-21所示。

图1-1UE位置报告控制流程

11.UE位置报告（LocationReport）

该过程用于RNC向CN报告与CN有连接的UE位置，报告由位置报告控制消息（LOCATIONREPORTCONTROLmessage）来进行控制，属于无应答、面向连接型过程。

消息流程如图1-22所示。

图1-1UE位置报告流程

12.UE初始数据传输（InitialUEMessage）

该过程用于当Iu信令连接由RNC建立时，RNC用该消息把从UE传来的第三层的空中接口初始消息（NAS-PDU）透明传输给CN，属于无应答、面向连接型过程。

消息流程如图1-23所示。

图1-1UE初始数据传输流程

RNC不分析该初始化消息的内容，只是在其上添加一些信息，形成初始UE消息（INITIALUEmessage）后再传给CN。

13.直接传输（DirectTransfer）

该过程用于UTRAN将UE与CN之间的信令消息透明地通过Iu接口传输，RNC不作任何处理。

UE-CN的信令消息作为直接传输消息（DIRECTTRANSFERmessage）的一个参数来传送。

该过程属于无应答、面向连接型过程。

消息流程如图1-24、图1-25所示，包括CN发起和UTRAN发起两种直接传输过程。

图1-1CN发起的直接传输流程

图1-2UTRAN发起的直接传输流程

14.流量控制（OverloadControl）

当RNC和CN间的信令流量过载时，由过载方发起该过程，对方根据一定的算法进行信令流量的控制，如限制UE的呼叫接入或限制下发寻呼或切换请求等消息，以适当减少RNC或CN的业务处理量，保证系统的正常运行。

在此控制过程中RNC与CN处于平等地位，即两侧都可以发起此过程。

该过程分为CN侧过载流量控制和UTRAN侧过载流量控制两种情况，属于无应答、无连接型。

消息流程如图1-26、图1-27所示。

图1-1CN侧过载流量控制流程

图1-2UTRAN侧过载流量控制流程

CN侧的流量控制主要控制处理器的过载；UTRAN侧流量控制主要控制处理器的过载和UE传送信令能力的过载。

15.复位（Reset）

复位（Reset）只针对RNC或CN上所有的Iu接口的事务处理。

当发生复位后，所有的呼叫连接都被拆除（已经建立的或正在建立的），并且在复位保护时间内不接受UE的呼叫消息。

消息流程如图1-28、图1-29所示。

图1-1CN发起的复位流程

图1-2UTRAN发起的复位流程

源端发出RESET消息，同时启动定时器T（RafC）或T（RafR）；对端接收到RESET消息后，接收端将释放被影响的RABs，然后返回复位确认消息。

16.复位资源（ResetResource）

复位资源是针对RNC（或CN）上的部分Iu连接。

当RNC或CN发现一些连接状态异常时，就发起复位资源流程。

消息流程如图1-30、图1-31所示。

图1-1CN发起的复位资源流程

图1-2RNC发起的复位资源流程

17.错误指示（ErrorIndication）

当一个节点对接收到的消息出错但无法以适当的失败信息表达时，它就启动这个错误指示过程用于报告在收到的信息中检测的到的错误。

如果错误情况的出现是由于接收到专用信令的消息，则此过程属于无应答、有连接型；否则是无应答、无连接过程。

消息流程如图1-32、图1-33所示。

图1-1CN发起的错误指示流程

图1-2UTRAN发起的错误指示流程

18.对UE活动的追踪（CNInvokeTrace）

该过程用于通知RNC对特定UE的活动进行追踪，并将结果报告给指定的操作维护中心（OMC），属于无应答、面向连接型过程。

消息流程如图1-18所示。

19.CN去活跟踪（CNDeactivateTrace）

该过程用于通知RNC对特定UE的活动停止追踪，属于无应答、面向连接型过程。

消息流程如图1-34所示。

图1-1CN去活跟踪流程

1.3RANAP典型流程

本节在RANAP基本流程的基础上对Iu接口上的几个典型流程信令综合描述，使读者对RANAP基本过程的应用有所了解。

下面将分别给出电路域位置更新、移动主叫、移动被叫、重定位和重定位失败等典型流程的描述。

1.Iu-CS接口位置更新流程

图1-35是一个典型的位置更新流程。

位置更新流程是面向连接的流程。

图1-1Iu接口位置更新流程

位置更新流程的作用：

（2）将UE在HLR中的用户签约信息插入VLR中：

如用户签约的