GSMBSS信令消息诠释释放规程Word格式.docx

GSMBSS信令消息诠释释放规程Word格式.docx

《GSMBSS信令消息诠释释放规程Word格式.docx》由会员分享，可在线阅读，更多相关《GSMBSS信令消息诠释释放规程Word格式.docx（30页珍藏版）》请在冰豆网上搜索。

0858协议

BSS信令与接口分析基础

M900／M1800BSS信令分析手册

1.

概述

常见的释放流程有两种：

正常释放和本地释放。

●正常释放是指该释放流程由MS或MSC发起。

●本地释放是指由BSC发起的释放流程。

相比建立流程，即先建物理层通路，然后建层2链路再建层3链路，释放流程是相反的，即先释放层3链路，再释放层2链路，最后释放物理层。

2.正常释放流程

正常释放是指该释放流程由MS或MSC发起，主叫挂机触发MS向MSC发出Disconnect消息，相应的MSC会向被叫MS发Disconnect消息。

3.1信令流程

MS在正常接入以后，如果因为业务需求（如用户挂机），可以主动发起释放，其流程如所示。

图1MS发起的释放流程

3.2信令流程详解

（1）.Disconnect

通话完毕，主叫方挂机，主叫MS给MSC发送Disconnect消息，主要包括了cause字段，指示了拆线的原因；

另外还有Transactionidentifier字段。

TransactionIdentifier

对属于CC（CallControl）和SS（SupplementaryService）消息，用一个字节的第5到8比特来表示Transactionidentifier。

它是用来唯一区别事务（Transaction）的，所以叫做TransactionIdentifier（TI）。

对一个给定PD和SAP的消息流来说，可以用TI来区别16种不同的双向的（bi-directional）消息流，我们称这个消息流为事务。

TI的结构如下：

事务是动态生成的，对应的TI值也是在生命周期里被分配，TI值是由触发一个事件的某一个接口的一侧（BSC或MSC）来分配的，当该事务结束时，对应的TI值就会被释放并被重新分配给后来的事务。

当某个接口上的不同侧分别触发了一个事务，则需要用两个不同的TI来区别开，这时就用TIflag来表示：

ThemessageissentfromthesidethatoriginatestheTI：

0表示本消息的是从触发该事务的一侧发送出来的，1表示本消息是被发送到触发该事务的一侧去的。

因此TIflag是唯一标识是谁给本事务分配该TI值，其唯一的作用就是用来避免同时分配一个相同的TI值时的冲突。

详细请参见协议GSM?

04.07。

所以TIflag=0，说明本条消息是由BSC发出来的，TI值为0。

Cause

Cause的结构如图所示

本消息cause字段为

CodingStandard

协议对CodingStandard的定义如下，目前该字段都是11，也就是GSMPLMN定义的标准，详细请参见附件1。

当本字段为11时，本消息就不没有“Recommendation”字段了。

Location

协议对location字段的定义如下，0000表示是移动用户而非网络触发的该释放流程。

CauseValue

对应第4个字节是Causevalue，比特8固定为1，比特5~7的值定义如下表，本消息是001：

正常事件；

比特1~4表示分属于下面不同类别更细致的原因，本消息是0000，也就是比特1~7为001000，对应的原因值为“Normalcallclearing”，详细请参见附件1。

（2）.Release

MSC向MS发送Release消息（同时MSC会给对应的被叫下发Disconnect消息）。

该消息的内容跟disconnect消息里的内容几乎完全一样。

不同点如下：

从消息头里能看到该消息是DTAP消息，DLCI值为0，DTAP长度为6，PD为0011，即属于CC消息。

因为协议定义PD为

（3）.ReleaseComplete

MS收到Release消息后，向MSC回ReleaseComplete消息。

本消息基本没有携带任何重要的内容，只说明本消息是MS向网络侧发起的RELEASECOMPLETE消息，

通过

（1）～（3）这三条消息，MSC和手机之间的CC资源（呼叫控制管理的相关资源）就释放完了。

应用层主要有CC、MM、RR，这里释放的是CC的资源，也就是说，首先释放的是呼叫控制管理层的资源。

（4）.ClearCommand

当手机和MSC之间的高层资源释放完了以后，那么MSC它就会下发一个clearcommand消息通知BSC释放占用的A接口资源和Um接口资源。

ClearCommand包括两部分内容：

layer3headerinformation和Cause，层3消息和原因。

层3头信息包括PD和TI两部分，见前面disconnect消息里的相关说明。

从PD可以看出，ClearCommand属于无线资源管理消息（rr-management-Protocol-Discriminator:

0x6（6）。

对原因，协议0808_4C1的规定典型原因值如下：

callcontrol,

OandMintervention,

equipmentfailure,

handoversuccessful,

protocolerrorbetweenBSSandMSC.

Causevalue的bit5~bit7为000，即Normalevent，见下表所示，bit1~bit4为1001，对应协议定义为Callcontrol，见附录2.

也就是说本条消息触发的原因是因为系统间（interworking）的呼叫控制（cc）而触发的。

（5）.ChannelRelease

BSC向MS下发ChannelRelease消息，要求MS和BTS释放Um接口逻辑信道，包括了RRcause字段。

这条消息是由BTS透传的，它用于释放手机中RR层的相关资源。

（6）.DISC（Disconnect）帧

MS收到ChannelRelease消息后，拆除上行信令链路，然后向BTS发DISC帧，表示已释放逻辑信道。

（7）.UA（UnnumberedAcknowledgement）帧

BTS向MS发UA帧确认；

MS收到UA帧后，返回CCCH信道进入空闲状态。

注意：

Disconnect和UA是层二的消息，用于释放手机和基站之间层二的链路资源。

（8）.DeactivateSACCH

BSC向BTS发DeactivateSACCH消息，这条消息是用于释放BTS中的SACCH逻辑信道的,同时，也释放与SACCH相关的TCH信道的。

（9）.ReleaseIndication

BTS在收到MS的DISC帧，向BSC回ReleaseIndication消息，表明MS已经释放了Um接口的逻辑信道。

通过DeactivateSACCH和ReleaseIndication，层二被释放。

主叫流程：

时隙号6的TCH/F（bm-acch，即Bm+FACCH+SACCH，是指TCH/F），而通过channeltype看出，可用做FACCH或SDCCH，因为现在实际占用的是TCH，所以只能是FACCH而非SDCCH，也就是说本ReleaseIndication是在TCH上传输的，但这时是通过偷帧用做FACCH，这也就是为什么说释放是占用的FACCH的原因。

在这里做个对比：

如果是位置更新的释放指示的话，如下，也就是释放的是SDCCH，从linkidentifier的channeltype:

facchorsdcch看出，本信道是SDCCH而非FACCH。

对位置更新：

（10）.RFChannelRelease

BSC向BTS发RFChannelRelease消息，这是要释放BTS中相关的射频资源。

对主叫流程：

（11）.RFChannelReleaseAcknowledge

BTS释放完成以后，会响应一个RFChannelReleaseAcknowledge，这样相关的资源就全部释放完了，该信道资源已空闲可用于再分配。

通过RFChannelRelease和RFChannelReleaseAcknowledge，底层的物理层就被完全释放了。

（12）.ClearComplete

BSC向MSC回ClearComplete消息。

从信令里看到：

该消息属于BSSMAP协议层消息，是release消息里的Clearcomplete消息，

（13）.RLSD

MSC向BSC发RLSD消息，释放SCCP链接。

（14）.RLSDComplete

BSC向MSC回RLSDComplete消息，表示已释放SCCP链接。

RLSD和RLSDComplete是层二的消息，用于释放A口层二的SCCP连路，对应A口层二建立SCCP连路的CC和CR。

补充说明：

1）.描述的是MS发起的释放过程，对于网络侧发起的释放流程，除这三条透明传输消息的方向相反之外，其余消息是一样的。

2）.

（1）～（3）为呼叫连接释放，属于CC层。

（4）～（14）为无线资源释放，属于RR层。

3）.在CC层和MM层的连接释放完毕后，网络将向BSC发出ClearCommand消息来请求释放SCCP信令链路。

在该消息中携带此次呼叫清除的原因，如“HandoverSuccessful”或“CallControl”等。

4）掉话时的信令流程（见下图）：

Ø

呼叫发生异常，如由于Um接口消息失败、无线链路失败或因设备故障等导致的释放，则是由BSC向系统发出ClearRequest消息申请拆线，然后MSC下发ClearCommand消息，BSC再回ClearComplete确认。

BSC向MSC发送ClearRequest消息时，统计为掉话。

当BSC收到MSC发送的ClearCommand消息，如果清除命令中的原因不是“Callcontrol”，也不是“Handoversuccessful”，而且，BSC在收到ClearCommand之前没有发送过ClearRequest消息，则统计为掉话。

3.本地释放流程

在正常呼叫流程中AssignmentComplete之后，BSC会启动对信令信道的本地释放流程。

同样在切换完成后，BSC也会启动对旧信道的本地释放流程。

其流程如图2。

图2BSC本地释放流程

（1）.DeactivateSACCH

跟正常释放流程一样，BSC向BTS发DeactivateSACCH消息，这条消息是用于释放BTS中的SACCH逻辑信道的,同时，也释放与SACCH相关的TCH信道的。

（2）.ReleaseRequest

BSC向BTS发ReleaseRequest消息所带的原因值为LocalEndRelease。

此时的释放过程与MS无关。

本消息有1个比特位为ReleaseMode：

0为正常释放；

1为本地释放。

此外，还携带了请求释放的信道的时隙号和类型。

（3）.ReleaseConfirm

BTS收到ReleaseRequest消息原因为LocalEndRelease后，给BSC回ReleaseConfirm消息，用于确认ReleaseRequest请求的时隙和信道已经完全被释放了。

若BSC下发的ReleaseRequest消息带有其它原因值（也就是正常释放的原因值）时，则BTS应向MS下发DISC帧，等收到MS上报的UA（或DM帧）后，才向BSC上报ReleaseConfirm消息。