2022年GSMBSS信令消息诠释-释放流程.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值时的冲突。详细请参见协议 GSM 04.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 GSM 04.07. Tables 10.3/GSM 04.08, 10.4/GSM 04.08, and 10.5/GSM 04.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/GSM 04.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/GSM 04.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 GSM 04.07.Table 10.1a/GSM 04.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/GSM 04.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 GSM 04.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 GSM 04.07.Table 10.3/GSM 04.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 REJEC