GSM BSS 信令消息诠释-释放流程.doc

GSM BSS信令消息诠释释放流程GSM信令消息诠释释放流程目录目录11.概述32.正常释放流程33.1信令流程33.2信令流程详解43.本地释放流程103.1信令流程103.2信令流程详解11附件112附录224GSM BSS信令消息诠释释放流程骆瑛（162429）关键词：释放 协议 信令摘 要：本文内容是继GSM BSS信令消息诠释之-位置更新后的以释放为例，结合相关的协议，从字节级深入解读每条信令里的核心字段，从而理解每条信令的功能和作用，进而理解整个流程的意义。参考资料清单：0408协议0808协议0858协议BSS信令与接口分析基础M900M1800 BSS 信令分析手册1. 概述常见的释放流程有两种：正常释放和本地释放。l 正常释放是指该释放流程由MS或MSC发起。l 本地释放是指由BSC发起的释放流程。相比建立流程，即先建物理层通路，然后建层2链路再建层3链路，释放流程是相反的，即先释放层3链路，再释放层2链路，最后释放物理层。2. 正常释放流程正常释放是指该释放流程由MS或MSC发起，主叫挂机触发MS向MSC发出Disconnect消息，相应的MSC会向被叫MS发Disconnect消息。3.1 信令流程MS在正常接入以后，如果因为业务需求（如用户挂机），可以主动发起释放，其流程如图1所示。图 1 MS发起的释放流程3.2 信令流程详解(1). Disconnect通话完毕，主叫方挂机，主叫MS给MSC发送Disconnect消息，主要包括了cause字段，指示了拆线的原因；另外还有Transaction identifier字段。Transaction Identifier对属于CC(Call Control)和SS(Supplementary Service)消息，用一个字节的第5到8比特来表示Transaction identifier。它是用来唯一区别事务（Transaction）的，所以叫做Transaction Identifier(TI)。对一个给定PD和SAP的消息流来说，可以用TI来区别16种不同的双向的（bi-directional）消息流，我们称这个消息流为事务。TI的结构如下：事务是动态生成的，对应的TI值也是在生命周期里被分配，TI值是由触发一个事件的某一个接口的一侧（BSC或MSC）来分配的，当该事务结束时，对应的TI值就会被释放并被重新分配给后来的事务。当某个接口上的不同侧分别触发了一个事务，则需要用两个不同的TI来区别开，这时就用TI flag来表示：The message is sent from the side that originates the TI ：0表示本消息的是从触发该事务的一侧发送出来的，1表示本消息是被发送到触发该事务的一侧去的。 因此TI flag是唯一标识是谁给本事务分配该TI值，其唯一的作用就是用来避免同时分配一个相同的TI值时的冲突。详细请参见协议 GSM04.07。所以TI flag=0，说明本条消息是由BSC发出来的，TI值为0。CauseCause的结构如图所示本消息cause字段为Coding Standard协议对Coding Standard的定义如下，目前该字段都是11，也就是GSM PLMN定义的标准，详细请参见附件1。当本字段为11时，本消息就不没有“Recommendation”字段了。 Location协议对location字段的定义如下，0000表示是移动用户而非网络触发的该释放流程。Cause Value对应第4个字节是Cause value，比特8固定为1，比特57的值定义如下表，本消息是001：正常事件；比特14表示分属于下面不同类别更细致的原因，本消息是0000，也就是比特17为001000，对应的原因值为“Normal call clearing”，详细请参见附件1。(2). ReleaseMSC向MS发送Release消息（同时MSC会给对应的被叫下发Disconnect消息）。该消息的内容跟disconnect消息里的内容几乎完全一样。不同点如下：从消息头里能看到该消息是DTAP消息，DLCI值为0，DTAP长度为6，PD为0011，即属于CC消息。因为协议定义PD为(3). Release CompleteMS收到Release消息后，向MSC回Release Complete消息。本消息基本没有携带任何重要的内容，只说明本消息是MS向网络侧发起的RELEASE COMPLETE消息，通过（1）（3）这三条消息，MSC和手机之间的CC资源（呼叫控制管理的相关资源）就释放完了。应用层主要有CC、MM、RR，这里释放的是CC的资源，也就是说，首先释放的是呼叫控制管理层的资源。(4). Clear Command当手机和MSC之间的高层资源释放完了以后，那么MSC它就会下发一个clear command消息通知BSC释放占用的A接口资源和Um接口资源。Clear Command包括两部分内容：layer3 header information和Cause，层3消息和原因。层3头信息包括PD和TI两部分，见前面disconnect消息里的相关说明。从PD可以看出，Clear Command属于无线资源管理消息（rr-management-Protocol-Discriminator:0x6(6)。对原因，协议0808_4C1的3.2.1.21规定典型原因值如下：call control,O and M intervention,equipment failure,handover successful,protocol error between BSS and MSC.Cause value的bit5bit7为000，即Normal event，见下表所示，bit1bit4为1001，对应协议定义为Call control，见附录2.也就是说本条消息触发的原因是因为系统间（interworking）的呼叫控制（cc）而触发的。(5). Channel ReleaseBSC向MS下发Channel Release消息，要求MS和BTS释放Um接口逻辑信道，包括了RR cause字段。这条消息是由BTS透传的，它用于释放手机中RR层的相关资源。(6). DISC（Disconnect）帧MS收到Channel Release消息后，拆除上行信令链路，然后向BTS发DISC帧，表示已释放逻辑信道。(7). UA(Unnumbered Acknowledgement)帧BTS向MS发UA帧确认；MS收到UA帧后，返回CCCH信道进入空闲状态。注意：Disconnect和UA是层二的消息，用于释放手机和基站之间层二的链路资源。(8). Deactivate SACCHBSC向BTS发Deactivate SACCH消息，这条消息是用于释放BTS中的SACCH逻辑信道的,同时，也释放与SACCH相关的TCH信道的。(9). Release IndicationBTS在收到MS的DISC帧，向BSC回Release Indication消息，表明MS已经释放了Um接口的逻辑信道。通过Deactivate SACCH和Release Indication，层二被释放。主叫流程：时隙号6的TCH/F(bm-acch，即Bm + FACCH + SACCH，是指TCH/F)，而通过channel type看出，可用做FACCH或SDCCH，因为现在实际占用的是TCH，所以只能是FACCH而非SDCCH，也就是说本Release Indication是在TCH上传输的，但这时是通过偷帧用做FACCH，这也就是为什么说释放是占用的FACCH的原因。在这里做个对比：如果是位置更新的释放指示的话，如下，也就是释放的是SDCCH，从link identifier的channel type: facch or sdcch看出，本信道是SDCCH而非FACCH。对位置更新：(10). RF Channel ReleaseBSC向BTS发RF Channel Release消息，这是要释放BTS中相关的射频资源。对主叫流程：对位置更新：(11). RF Channel Release AcknowledgeBTS释放完成以后，会响应一个RF Channel Release Acknowledge，这样相关的资源就全部释放完了，该信道资源已空闲可用于再分配。通过RF Channel Release和RF Channel Release Acknowledge，底层的物理层就被完全释放了。对主叫流程：对位置更新：(12). Clear CompleteBSC向MSC回Clear Complete消息。从信令里看到：该消息属于BSSMAP协议层消息，是release 消息里的Clear complete消息，(13). RLSDMSC向BSC发RLSD消息，释放SCCP链接。(14). RLSD CompleteBSC向MSC回RLSD Complete消息，表示已释放SCCP链接。 注意：RLSD和RLSD Complete是层二的消息，用于释放A口层二的SCCP连路，对应A口层二建立SCCP连路的CC和CR。补充说明：1). 描述的是MS发起的释放过程，对于网络侧发起的释放流程，除这三条透明传输消息的方向相反之外，其余消息是一样的。2).（1）（3）为呼叫连接释放，属于CC层。（4）（14）为无线资源释放，属于RR层。3).在CC层和MM层的连接释放完毕后，网络将向BSC发出Clear Command 消息来请求释放SCCP信令链路。在该消息中携带此次呼叫清除的原因，如“Handover Successful”或“Call Control”等。4）掉话时的信令流程（见下图）： 呼叫发生异常，如由于Um接口消息失败、无线链路失败或因设备故障等导致的释放，则是由BSC向系统发出Clear Request消息申请拆线，然后MSC下发Clear Command消息，BSC再回Clear Complete确认。BSC向MSC发送Clear Request消息时，统计为掉话。 当BSC收到MSC发送的Clear Command消息，如果清除命令中的原因不是“Call control”，也不是“Handover successful”，而且，BSC在收到Clear Command之前没有发送过Clear Request消息，则统计为掉话。3. 本地释放流程3.1 信令流程在正常呼叫流程中Assignment Complete之后，BSC会启动对信令信道的本地释放流程。同样在切换完成后，BSC也会启动对旧信道的本地释放流程。其流程如0。图 2 BSC本地释放流程3.2 信令流程详解(1). Deactivate SACCH跟正常释放流程一样，BSC向BTS发Deactivate SACCH消息，这条消息是用于释放BTS中的SACCH逻辑信道的,同时，也释放与SACCH相关的TCH信道的。(2). Release RequestBSC向BTS发Release Request消息所带的原因值为Local End Release。此时的释放过程与MS无关。本消息有1个比特位为Release Mode：0为正常释放；1为本地释放。此外，还携带了请求释放的信道的时隙号和类型。(3). Release ConfirmBTS收到Release Request消息原因为Local End Release后，给BSC回Release Confirm消息，用于确认Release Request请求的时隙和信道已经完全被释放了。若BSC下发的Release Request消息带有其它原因值（也就是正常释放的原因值）时，则BTS应向MS下发DISC帧，等收到MS上报的UA（或DM帧）后，才向BSC上报Release Confirm消息。(4). RF Channel ReleaseBSC向BTS发RF Channel Release消息。(5). Channel Release AcknowledgeBTS向BSC发RF Channel Release Acknowledge消息。在我们实际的维护过程中，通常我们比较少地去分析本地端的释放流程，因为这个释放流程是在BSC内部固定完成的，做得比较完善的，通常不会出现什么问题。附件1摘自协议040810.4Message TypeThe message type IE and its use are defined in GSM04.07. Tables 10.3/GSM04.08, 10.4/GSM04.08, and 10.5/GSM04.08 define the value part of the message type IE used in the Radio Resource management protocol, the Mobility Management protocol, and the Call Control protocol.Table 10.1/GSM04.08 (page 1 of 2): Message types for Radio Resource management 8 7 6 5 4 3 2 1 0 0 1 1 1 - - - Channel establishment messages: 0 1 1 - ADDITIONAL ASSIGNMENT 1 1 1 - IMMEDIATE ASSIGNMENT 0 0 1 - IMMEDIATE ASSIGNMENT EXTENDED 0 1 0 - IMMEDIATE ASSIGNMENT REJECT 0 0 1 1 0 - - - Ciphering messages: 1 0 1 - CIPHERING MODE COMMAND 0 1 0 - CIPHERING MODE COMPLETE 0 0 1 1 0 - - - Configuration change messages: 0 0 0 - CONFIGURATION CHANGE COMMAND 0 0 1 - CONFIGURATION CHANGE ACK. 0 1 1 - CONFIGURATION CHANGE REJECT 0 0 1 0 1 - - - Handover messages: 1 1 0 - ASSIGNMENT COMMAND 0 0 1 - ASSIGNMENT COMPLETE 1 1 1 - ASSIGNMENT FAILURE 0 1 1 - HANDOVER COMMAND 1 0 0 - HANDOVER COMPLETE 0 0 0 - HANDOVER FAILURE 1 0 1 - PHYSICAL INFORMATION 0 0 0 0 1 - - - Channel release messages: 1 0 1 - CHANNEL RELEASE 0 1 0 - PARTIAL RELEASE 1 1 1 - PARTIAL RELEASE COMPLETE 0 0 1 0 0 - - - Paging and Notification messages: 0 0 1 - PAGING REQUEST TYPE 1 0 1 0 - PAGING REQUEST TYPE 2 1 0 0 - PAGING REQUEST TYPE 3 1 1 1 - PAGING RESPONSE 0 0 0 - NOTIFICATION/NCH 1 0 1 - NOTIFICATION/FACCH 1 1 0 - Reserved (see NOTE) 0 0 0 0 1 0 1 1 - NOTIFICATION RESPONSE (continued.)NOTE:This value was allocated but never used in earlier phases of the protocol.Table 10.1/GSM04.08 (page 2 of 2): Message types for Radio Resource management 8 7 6 5 4 3 2 1 0 0 0 1 1 - - - System information messages: 0 0 0 - SYSTEM INFORMATION TYPE 8 0 0 1 - SYSTEM INFORMATION TYPE 1 0 1 0 - SYSTEM INFORMATION TYPE 2 0 1 1 - SYSTEM INFORMATION TYPE 3 1 0 0 - SYSTEM INFORMATION TYPE 4 1 0 1 - SYSTEM INFORMATION TYPE 5 1 1 0 - SYSTEM INFORMATION TYPE 6 1 1 1 - SYSTEM INFORMATION TYPE 7 0 0 0 0 0 - - - System information messages: 0 1 0 - SYSTEM INFORMATION TYPE 2bis 0 1 1 - SYSTEM INFORMATION TYPE 2ter 1 0 1 - SYSTEM INFORMATION TYPE 5bis 1 1 0 - SYSTEM INFORMATION TYPE 5ter 1 0 0 - SYSTEM INFORMATION TYPE 9 0 0 0 1 0 - - - Miscellaneous messages: 0 0 0 - CHANNEL MODE MODIFY 0 1 0 - RR STATUS 1 1 1 - CHANNEL MODE MODIFY ACKNOWLEDGE 1 0 0 - FREQUENCY REDEFINITION 1 0 1 - MEASUREMENT REPORT 1 1 0 - CLASSMARK CHANGE 0 1 1 - CLASSMARK ENQUIRY 0 0 1 1 0 1 1 0 - EXTENDED MEASUREMENT REPORT 0 0 1 1 0 1 1 1 - EXTENDED MEASUREMENT ORDER VGCS uplink control messages: 0 0 0 0 1 0 0 1 - VGCS UPLINK GRANT 0 0 0 0 1 1 1 0 - UPLINK RELEASE 0 0 0 0 1 1 0 0 - UPLINK FREE 0 0 1 0 1 0 1 0 - UPLINK BUSY 0 0 0 1 0 0 0 1 - TALKER INDICATION Bit 8 is reserved for possible future use as an extension bit, see GSM04.07.Table 10.1a/GSM04.08: Message types for Radio Resource management messages using the RR short protocol discriminator 5 4 3 2 1 0 0 0 0 0 SYSTEM INFORMATION TYPE 10 0 0 0 0 1 NOTIFICATION/FACCH 0 0 0 1 0 UPLINK FREE Table 10.2/GSM04.08: Message types for Mobility Management 8 7 6 5 4 3 2 1 0 x 0 0 - - - - Registration messages: 0 0 0 1 - IMSI DETACH INDICATION 0 0 1 0 - LOCATION UPDATING ACCEPT 0 1 0 0 - LOCATION UPDATING REJECT 1 0 0 0 - LOCATION UPDATING REQUEST 0 x 0 1 - - - - Security messages: 0 0 0 1 - AUTHENTICATION REJECT 0 0 1 0 - AUTHENTICATION REQUEST 0 1 0 0 - AUTHENTICATION RESPONSE 1 0 0 0 - IDENTITY REQUEST 1 0 0 1 - IDENTITY RESPONSE 1 0 1 0 - TMSI REALLOCATION COMMAND 1 0 1 1 - TMSI REALLOCATION COMPLETE 0 x 1 0 - - - - Connection management messages: 0 0 0 1 - CM SERVICE ACCEPT 0 0 1 0 - CM SERVICE REJECT 0 0 1 1 - CM SERVICE ABORT 0 1 0 0 - CM SERVICE REQUEST 0 1 0 1 - CM SERVICE PROMPT 1 0 0 0 - CM RE-ESTABLISHMENT REQUEST 1 0 0 1 - ABORT 0 x 1 1 - - - - Miscellaneous messages: 0 0 0 0 - MM NULL 0 0 0 1 - MM STATUS 0 0 1 0 - MM INFORMATION Bit 8 is reserved for possible future use as an extension bit, see GSM04.07.Bit 7 is reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bit 7 is coded with a 0. See GSM04.07.Table 10.3/GSM04.08: Message types for Call Control and call related SS messages 8 7 6 5 4 3 2 1 0 x 0 0 0 0 0 0 escape to nationally specific message types ; see 1) below 0 x 0 0 - - - - Call establishment messages: 0 0 0 1 - ALERTING 1 0 0 0 - CALL CONFIRMED 0 0 1 0 - CALL PROCEEDING 0 1 1 1 - CONNECT 1 1 1 1 - CONNECT ACKNOWLEDGE 1 1 1 0 - EMERGENCY SETUP 0 0 1 1 - PROGRESS 0 1 0 0 - CC-ESTABLISHMENT 0 1 1 0 - CC-ESTABLISHMENT CONFIRMED 1 0 1 1 - RECALL 1 0 0 1 - START CC 0 1 0 1 - SETUP 0 x 0 1 - - - - Call information phase messages: 0 1 1 1 - MODIFY 1 1 1 1 - MODIFY COMPLETE 0 0 1 1 - MODIFY REJECT 0 0 0 0 - USER INFORMATION 1 0 0 0 - HOLD 1 0 0 1 - HOLD ACKNOWLEDGE 1 0 1 0 - HOLD REJECT 1 1 0 0 - RETRIEVE 1 1 0 1 - RETRIEVE ACKNOWLEDGE 1 1 1 0 - RETRIEVE REJECT 0 x 1 0 - - - - Call clearing messages: 0 1 0 1 - DISCONNECT 1 1 0 1 - RELEASE 1 0 1 0 - RELEASE COMPLETE 0 x 1 1 - - - - Miscellaneous messages: 1 0 0 1 - CONGESTION CONTROL 1 1 1 0 - NOTIFY 1 1 0 1 - STATUS 0 1 0 0 - STATUS ENQUIRY 0 1 0 1 - START DTMF 0 0 0 1 - STOP DTMF 0 0 1 0 - STOP DTMF ACKNOWLEDGE 0 1 1 0 - START DTMF ACKNOWLEDGE 0 1 1 1 - START DTMF REJECT 1 0 1 0 - FACILITY 1):When used, the message type is defined in the following octet(s), according to the national specification.Bit 8 is reserved for possible future use as an extension bit, see GSM04.07.Bit 7 is reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bit 7 is coded with a 0. See GSM04.07.10.5.4.11CauseThe purpose of the cause information element is to describe the reason for generating certain messages, to provide diagnostic information in the event of procedural errors and to indicate the location of the cause originator.The cause information element is coded as shown in figure10.77/GSM04.08 and tables10.85 and 10.86/GSM04.08.The cause is a type 4 information element with a minimum length of 4 octets and a maximum length of 32 octets.The cause information element may be repeated in a message. Figure 10.77/GSM04.08Cause information elementIf the default value applies for the recommendation field, octet 3a shall be omitted.Table 10.85/GSM04.0