GSM信令消息诠释——释放流程
目录
目录 (1)
1.概述 (3)
2.正常释放流程 (3)
3.1信令流程 (3)
3.2信令流程详解 (4)
3.本地释放流程 (11)
3.1信令流程 (11)
3.2信令流程详解 (12)
附件1 (14)
附录2 (25)
GSM BSS信令消息诠释－释放流程
骆瑛（162429）
关键词：释放协议信令
摘要：本文内容是继GSM BSS信令消息诠释之-位置更新后的以释放为例，结合相关的协议，从字节级深入解读每条信令里的核心字段，从而理解每条信令的功能和作用，进而理解整个流程的意义。
参考资料清单：
0408协议
0808协议
0858协议
BSS信令与接口分析基础
M900／M1800 BSS 信令分析手册
1. 概述
常见的释放流程有两种：正常释放和本地释放。 ● 正常释放是指该释放流程由MS 或MSC 发起。 ● 本地释放是指由BSC 发起的释放流程。
相比建立流程，即先建物理层通路，然后建层2链路再建层3链路，释放流程是相反的，即先释放层3链路，再释放层2链路，最后释放物理层。
2. 正常释放流程
正常释放是指该释放流程由MS 或MSC 发起，主叫挂机触发MS 向MSC 发出Disconnect 消息，相应的MSC 会向被叫MS 发Disconnect 消息。
3.1 信令流程
MS 在正常接入以后，如果因为业务需求（如用户挂机），可以主动发起释放，其流程如图1所示。
BTS
BSC
MSC
MS
图 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。
Cause
Cause的结构如图所示
本消息cause字段为
Coding Standard
协议对Coding Standard的定义如下，目前该字段都是11，也就是GSM PLMN定义的标准，详细请参见附件1。当本字段为11时，本消息就不没有“Recommendation”字段了。
Location
协议对location字段的定义如下，0000表示是移动用户而非网络触发的该释放流程。
Cause Value
对应第4个字节是Cause value，比特8固定为1，比特5~7的值定义如下表，本消息是001：正常事件；比特1~4表示分属于下面不同类别更细致的原因，本消息是0000，也就是比特1~7为001000，对应的原因值为“Normal call clearing”，详细请参见附件1。
(2). Release
MSC向MS发送Release消息（同时MSC会给对应的被叫下发Disconnect消息）。该消息的内容跟disconnect消息里的内容几乎完全一样。不同点如下：
从消息头里能看到该消息是DTAP消息，DLCI值为0，DTAP长度为6，PD为0011，即属于
CC消息。因为协议定义PD
(3). Release Complete
MS收到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的bit5~bit7为000，即Normal event，见下表所示，bit1~bit4为1001，对应协议定义为Call control，见附录2.
也就是说本条消息触发的原因是因为系统间（interworking）的呼叫控制（cc）而触发的。
(5). Channel Release
BSC向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 SACCH
BSC向BTS发Deactivate SACCH消息，这条消息是用于释放BTS中的SACCH逻辑信道的,同时，也释放与SACCH相关的TCH信道的。
(9). Release Indication
BTS在收到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 Release
BSC向BTS发RF Channel Release消息，这是要释放BTS中相关的射频资源。
(11). RF Channel Release Acknowledge
BTS释放完成以后，会响应一个RF Channel Release Acknowledge，这样相关的资源就全部释放完了，该信道资源已空闲可用于再分配。通过RF Channel Release和RF Channel Release Acknowledge，底层的物理层就被完全释放了。
(12). Clear Complete
BSC向MSC回Clear Complete消息。
从信令里看到：该消息属于BSSMAP协议层消息，是release 消息里的Clear complete消息，(13). RLSD
MSC向BSC发RLSD消息，释放SCCP链接。
(14). RLSD Complete
BSC向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。
BTS BSC
MSC
MS
图 2 BSC 本地释放流程
3.2 信令流程详解
(1). Deactivate SACCH
跟正常释放流程一样，BSC 向BTS 发Deactivate SACCH 消息，这条消息是用于释放BTS 中的SACCH 逻辑信道的,同时，也释放与SACCH 相关的TCH 信道的。 (2). Release Request
BSC 向BTS 发Release Request 消息所带的原因值为Local End Release 。此时的释放过程与MS 无关。
本消息有1个比特位为Release Mode ：0为正常释放；1为本地释放。 此外，还携带了请求释放的信道的时隙号和类型。 (3). Release Confirm
BTS 收到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 Release
BSC向BTS发RF Channel Release消息。
(5). Channel Release Acknowledge
BTS向BSC发RF Channel Release Acknowledge消息。
在我们实际的维护过程中，通常我们比较少地去分析本地端的释放流程，因为这个释放流程是在BSC内部固定完成的，做得比较完善的，通常不会出现什么问题。
附件1
摘自协议0408
10.4 M essage Type
The 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
┌───────────────────────────────────────────────────┐
│87654321 │
││
│00111---C h a n n e l e s t a b l i s h m e n t m e s s a g e s: │
│ 011-A D D I T I O N A L A S S I G N M E N T │
│ 111-I M M E D I A T E A S S I G N M E N T │
│ 001-I M M E D I A T E A S S I G N M E N T E X T E N D E D │
│ 010-I M M E D I A T E A S S I G N M E N T R E J E C T │
││
│00110--- C i p h e r i n g m e s s a g e s: │
│ 101-C I P H E R I N G M O D E C O M M A N D │
│ 010-C I P H E R I N G M O D E C O M P L E T E │
││
│00110---C o n f i g u r a t i o n c h a n g e m e s s a g e s: │
│000 -C O N F I G U R A T I O N C H A N G E C O M M A N D │
│ 001-C O N F I G U R A T I O N C H A N G E A C K. │
│ 011-C O N F I G U R A T I O N C H A N G E R E J E C T │
││
│00101--- H a n d o v e r m e s s a g e s:│
│ 110-A S S I G N M E N T C O M M A N D │
│ 001-A S S I G N M E N T C O M P L E T E │
│ 111-A S S I G N M E N T F A I L U R E │
│ 011-H A N D O V E R C O M M A N D │
│ 100-H A N D O V E R C O M P L E T E│
│ 000-H A N D O V E R F A I L U R E │
│ 101-P H Y S I C A L I N F O R M A T I O N │
││
│00001---C h a n n e l r e l e a s e m e s s a g e s: │
│ 101-C H A N N E L R E L E A S E │
│ 010-P A R T I A L R E L E A S E │
│ 111-P A R T I A L R E L E A S E C O M P L E T E │
││
│00100---P a g i n g a n d N o t i f i c a t i o n m e s s a g e s:│
│ 001 -P A G I N G R E Q U E S T T Y P E1 │
│ 010-P A G I N G R E Q U E S T T Y P E2 │
│ 100-P A G I N G R E Q U E S T T Y P E3 │
│ 111-P A G I N G R E S P O N S E │
│ 000-N O T I F I C A T I O N/N C H│
│ 101-N O T I F I C A T I O N/F A C C H │
│ 110-R e s e r v e d(s e e N O T E) │
│00001011-N O T I F I C A T I O N R E S P O N S E │
││
└───────────────────────────────────────────────────┘
(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
┌───────────────────────────────────────────────────┐
│87654321 │
││
│00011---S y s t e m i n f o r m a t i o n m e s s a g e s: │
│ 000-S Y S T E M I N F O R M A T I O N T Y P E8 │
│ 001-S Y S T E M I N F O R M A T I O N T Y P E1 │
│ 010-S Y S T E M I N F O R M A T I O N T Y P E2 │
│ 011-S Y S T E M I N F O R M A T I O N T Y P E3 │
│ 100-S Y S T E M I N F O R M A T I O N T Y P E4 │
│ 101-S Y S T E M I N F O R M A T I O N T Y P E5 │
│ 110-S Y S T E M I N F O R M A T I O N T Y P E6 │
│ 111-S Y S T E M I N F O R M A T I O N T Y P E7 │
││
│00000---S y s t e m i n f o r m a t i o n m e s s a g e s: │
│ 010-S Y S T E M I N F O R M A T I O N T Y P E2b i s │
│ 011 -S Y S T E M I N F O R M A T I O N T Y P E2t e r │
│ 101-S Y S T E M I N F O R M A T I O N T Y P E5b i s │
│ 110-S Y S T E M I N F O R M A T I O N T Y P E5t e r │
│ 100-S Y S T E M I N F O R M A T I O N T Y P E9 │
││
│00010---M i s c e l l a n e o u s m e s s a g e s: │
│ 000-C H A N N E L M O D E M O D I F Y │
│ 010-R R S T A T U S │
│ 111-C H A N N E L M O D E M O D I F Y A C K N O W L E D G E│
│ 100-F R E Q U E N C Y R E D E F I N I T I O N │
│ 101-M E A S U R E M E N T R E P O R T │
│ 110-C L A S S M A R K C H A N G E │
│ 011-C L A S S M A R K E N Q U I R Y │
│ 0 0 1 1 0 1 1 0 - EXTENDED MEASUREMENT REPORT │ │
00110111 -E X T E N D E D M E A S U R E M E N T O R D E R │
││
│ V G C S u p l i n k c o n t r o l m e s s a g e s: │
││
│00001001-V G C S U P L I N K G R A N T│
│00001110-U P L I N K R E L E A S E │
│00001100-U P L I N K F R E E │
│00101010-U P L I N K B U S Y │
│00010001-T A L K E R I N D I C A T I O N │
└───────────────────────────────────────────────────┘
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
┌───────────────────────────────────────────────────┐
│54321 │
││
│00000 S Y S T E M I N F O R M A T I O N T Y P E10 │
│00001 N O T I F I C A T I O N/F A C C H │
│00010 U P L I N K F R E E │
││
└───────────────────────────────────────────────────┘
Table 10.2/GSM 04.08: Message types for Mobility Management ┌───────────────────────────────────────────────────┐
││
│87654321 │
││
│0x00----R e g i s t r a t i o n m e s s a g e s: │
│ 0001-I M S I D E T A C H I N D I C A T I O N│
│ 0010-L O C A T I O N U P D A T I N G A C C E P T │
│ 0100-L O C A T I O N U P D A T I N G R E J E C T │
│ 1000-L O C A T I O N U P D A T I N G R E Q U E S T │
││
│0x01---- S e c u r i t y m e s s a g e s: │
│ 0001-A U T H E N T I C A T I O N R E J E C T │
│ 0010-A U T H E N T I C A T I O N R E Q U E S T │
│ 0100-A U T H E N T I C A T I O N R E S P O N S E │
│ 1000-I D E N T I T Y R E Q U E S T │
│ 1001 -I D E N T I T Y R E S P O N S E │
│ 1010-T M S I R E A L L O C A T I O N C O M M A N D │
│ 1011-T M S I R E A L L O C A T I O N C O M P L E T E │
││
│0x10----C o n n e c t i o n m a n a g e m e n t m e s s a g e s: │
│ 0001 -C M S E R V I C E A C C E P T │
│ 0010-C M S E R V I C E R E J E C T │
│ 0011-C M S E R V I C E A B O R T │
│ 0100-C M S E R V I C E R E Q U E S T │
│ 0101-C M S E R V I C E P R O M P T│
│ 1000-C M R E-E S T A B L I S H M E N T R E Q U E S T │
│ 1001-A B O R T │
││
│0x11----M i s c e l l a n e o u s m e s s a g e s: │
│ 0000-M M N U L L│
│ 0001-M M S T A T U S │
│ 0010-M M I N F O R M A T I O N │
└───────────────────────────────────────────────────┘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
┌───────────────────────────────────────────────────┐│87654321 ││0x000000 e s c a p e t o n a t i o n a l l y s p e c i f i c ││ m e s s a g e t y p e s;s e e1)b e l o w ││││0x00----C a l l e s t a b l i s h m e n t m e s s a g e s: ││ 0001-A L E R T I N G ││ 1000-C A L L C O N F I R M E D ││ 0010-C A L L P R O C E E D I N G ││ 0111-C O N N E C T ││ 1111-C O N N E C T A C K N O W L E D G E ││ 1110-E M E R G E N C Y S E T U P ││ 0011-P R O G R E S S ││ 0100-C C-E S T A B L I S H M E N T ││ 0110 -C C-E S T A B L I S H M E N T C O N F I R M E D ││ 1011-R E C A L L ││ 1001-S T A R T C C ││ 0101-S E T U P ││││0x01----C a l l i n f o r m a t i o n p h a s e m e s s a g e s:││ 0111-M O D I F Y ││ 1111-M O D I F Y C O M P L E T E ││ 0011-M O D I F Y R E J E C T ││ 0000-U S E R I N F O R M A T I O N││ 1000-H O L D ││ 1001-H O L D A C K N O W L E D G E ││ 1010-H O L D R E J E C T ││ 1100-R E T R I E V E ││ 1101-R E T R I E V E A C K N O W L E D G E ││ 1110-R E T R I E V E R E J E C T ││││0x10----C a l l c l e a r i n g m e s s a g e s: ││ 0101-D I S C O N N E C T ││1101 -R E L E A S E ││ 1010-R E L E A S E C O M P L E T E ││││0x11----M i s c e l l a n e o u s m e s s a g e s: ││ 1001-C O N G E S T I O N C O N T R O L││ 1110-N O T I F Y ││ 1101-S T A T U S ││ 0100-S T A T U S E N Q U I R Y ││ 0101-S T A R T D T M F ││ 0001-S T O P D T M F││ 0010-S T O P D T M F A C K N O W L E D G E ││ 0110-S T A R T D T M F A C K N O W L E D G E ││ 0111-S T A R T D T M F R E J E C T ││ 1010-F A C I L I T Y │└───────────────────────────────────────────────────┘
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 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.
10.5.4.11 Cause
The 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 figure 10.77/GSM 04.08 and tables 10.85 and 10.86/GSM 04.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/GSM 04.08
Cause information element
If the default value applies for the recommendation field, octet 3a shall be omitted.
Table 10.85/GSM 04.08: Cause information element
1．1 位置更新流程 在GSM系统中有三个地方需要知道位置信息，即HLR、VLR和MS。当这个信息发生变化时，需要保持三者的一致，由位置更新流程实现。位置更新流程是位置管理中的主要流程，总是由MS发起。位置更新流程是一个通用流程，在如下三类位置更新流程中要使用到：正常位置更新、周期性位置更新、IMSI附着位置更新流程。 正常位置更新用于更新网络侧对于MS的位置区信息，LOCATION UPDATING REQUEST消息中包含位置更新流程的类型信息。在网络侧VLR判定MS为未知用户时，会启动正常位置更新流程，作为MM连接建立请求的响应。为限制位置更新尝试次数，位置更新失败时要使用位置更新attempt counter 计数器。在MS 开机或SIM卡刚插入时，该计数器清零。 MS中要保持一个"forbidden location areas for roaming"表和一个"forbidden location areas for regional provision of service"表。MS关机或SIM卡拔出时，将这两个表删除。当MS收到位置更新拒绝消息，其原因值为"Roaming not allowed in this location area"或"Location Area not allowed"时，从BCCH上收到的LAI信息触发位置更新请求的LAI要加到相应的表中。这两个表的容量至少要有10个表项，当表项数目超过表的容量时，最早的表项内容删除。成功的进行位置更新后，MS在SIM卡中置UPDATED状态位（UPDATED状态表明最后一次位置更新请求成功，同时此时LAI、TMSI，加密的密钥和加密序列号都应该保存在SIM卡中），并存储新的位置区信息。 正常位置更新、周期性位置更新和IMSI附着位置更新流程基本相同（不同之处在下面各小节中详细描述），流程如下图： 图1 位置更新流程 (1) MS在空中接口的接入信道上向BTS发送Channel Request（该消息内含接入原因值为位置更新）； (2) BTS向BSC发送Channel Required消息；
第4章位置更新 4.1 概述 在GSM系统中有三个地方需要知道位置信息，即HLR、VLR和MS。当这个信息发生变化时，需要保持三 者的一致，由位置更新流程实现。位置更新流程是位 置管理中的主要流程，总是由MS发起。 位置更新流程是一个通用流程，在如下三类位置更新流程中要使用到：正常位置更新、周期性位置更 新、IMSI附着位置更新流程。 正常位置更新用于更新网络侧对于MS的位置区信息，LOCATION UPDATING REQUEST消息中包含位置更新 流程的类型信息。 在网络侧VLR判定MS为未知用户时，会启动正常位置更新流程，作为MM连接建立请求的响应。
为限制位置更新尝试次数，位置更新失败时要使用位置更新attempt counter 计数器。在MS开机或SIM卡刚插入时，该计数器清零。 MS中要保持一个"forbidden location areas for roaming"表和一个"forbidden location areas for regional provision of service"表。MS关机或SIM 卡拔出时，将这两个表删除。当MS收到位置更新拒绝消息，其原因值为"Roaming not allowed in this location area"或"Location Area not allowed"时，从BCCH上收到的LAI信息触发位置更新请求的LAI要加到相应的表中。这两个表的容量至少要有10个表项，当表项数目超过表的容量时，最早的表项内容删除。 成功的进行位置更新后，MS在SIM卡中置UPDATED 状态位（UPDATED状态表明最后一次位置更新请求成
短消息业务优化思路及方案 1短消息业务实现原理及关键网元介绍 短消息业务（SMS）是当前最流行的一种消息技术。短消息的内容可以是纯粹的文本信息、图形和声音文件（如铃声）。SMS信息长度有一定限制，每条SMS信息不能超过160 B，对于稍长的E-mall或新闻等，必须把信息切断为数条SMS信息进行多次发送。SMS的实现原理是采用短消息中心（SMC）的存储转发机制。如果用户不在服务区内，短消息就被存储在SMC，等用户重新接入MSC后再次发送。SMS信息的发送和接收可以在网络上与语音、数据和传真服务同时进行，而不会对彼此产生任何干扰，SMS还支持漫游。 SMS有3类基本方式：移动台发起（MO）的点到点SMS，移动台接收（MT）的点到点SMS，广播SMS。SMS 收发流程见图1。 如图1所示，SMS所涉及的关键网元有SMC、MSC、BSC、BTS和MS等，SMS是MS上的一个应用和SMC 上的一个应用之间的短消息传递，而MSC和BSS相当于为这两个应用提供短消息输送的通道；但为了使短消息传送者能够重发未能成功发送的短消息，MSC和BSS网络将对短消息是否成功发送作出通知。 2 基于网元分析的优化思路及措施
SMS所涉及的关键网元有SMC、MSC、BSC、BTS、和MS等，所以这些网元的发送机制和工作状态都会对短消息产生影响，调整发送机制和优化参数配置是确保SMS畅通的必要措施。下面详细描述这些网元的发送机制和参数配置情况及优化措施。 2.1 短消息中心（SMC） SMC具备处理短消息的提交、存储、合成、分解、下发、定时重发等能力；还提供群发、重发机制和前推机制来保证短消息的及时性和成功率。由于SMC群发和重发机制对网络各网元支撑能力的要求更高，对用户感受、系统负荷和KPI指标影响较大。这里侧重描述这两个机制并提出优化措施。 2.1.1 短消息重发机制对用户感受、网络负荷及KPI指标的影响 SMC具有重发机制，对未成功下发给终端的短消息会继续存储在SMC中，并保留一定时间（可根据不同业务类型设定保留时长）。根据设置的时间间隔，或MSC、或HLR触发短消息下发通知到达时，SMC就重新向目标终端发送一次短消息。一般交换机在短消息寻呼失败后，会保持有短消息等待的标志位，当MSC检测到用户重新接入网络注册、或有位置更新、或主被叫时，就会向SMC发送MSC触发短消息下发通知。SMC可以针对每一个未成功下发而返回值CAUSE，来设定重发次数和时间间隔。 短消息重发机制设置不合理，会对用户感受、网络负荷和开销，以及KPI指标产生负面影响，所以需要对常见CAUSE 类型进行分析，再合理设置每个CAUSE类型的重发次数和时间间隔。常用的返回值有： a）交换延期发送； b）手机内存满； c）其他网络问题； d）无寻呼响应； e）无确认消息； f）服务终端拒绝。 如对于CAUSE=32（原因：无寻呼响应），若重发次数少、重发时间间隔长，则无法保证把短消息及时发送给目标用户，而导致用户有延迟过长的不满投诉；反之，则容易给NSS和BSS网络增加系统负荷和开销，而且降低了KPI 指标中的寻呼成功率。再如对CAUSE=35（原因：手机内存满），因当用户在手机收件箱溢出时删除了一条短消息之后，手机将生成一条移动用户内存可用消息并且向MSC上报，从而触发SMC再次下发短消息。所以建议其重发机制为重发次数少、时间间隔短、或不重发，一定程度上减少了网络系统负荷和开销。 所以，合理设置短消息重发机制，既能改善用户的感受满意度，降低系统负荷和开销，也能有效提高短消息寻呼成功率。 2.1.2 群发机制对用户感受、网络负荷及KPI指标的影响 SMC具有群呼机制，可以对整个号段所有手机都群发一遍短消息；也可以按一定规律号码顺序群发短消息、预设置群发时间段。随着短消息应用不断拓展，群发短消息的量也相当庞大，如天气预报、欠费催缴、开机通知的小信使等服务，而每种服务有不同级别的及时性要求。所以短消息群发机制设置不合理，同样会对用户感受、网络负荷及KPI指标产生负面影响。有些典型区域（如集团用户群所在基站）会因群发短消息促使大量手机同一时间进行寻呼响应，而导致基站接入信道拥塞，影响接入成功率，最终体现在寻呼成功率不高上，影响到短消息下发效率，增加了重发数量而导致了网络系统的负荷和开销；如若在网络语音话务高峰期群发，容易造成无线网络拥塞和系统负荷过载，同时影响KPI 指标。 鉴于短消息群发带来的负面影响，建议SMC群发短消息时间段避开网络话务高峰期（如晚忙时），或同时采取一些其他策略，如根据业务及时性分等级发送，或不按号段顺序而按一定位数错开发送。 2.1.3 SMC平台相关参数设置对短消息业务的影响
VoLTE信令流程
内容 VoLTE总体流程 1 VoLTE注册流程 2 VOLTE基本呼叫流程 3
总体流程—承载 ?VoLTE的信令IMS消息使用QCI为5的Non-GBR QoS、语音使用QCI为1的GBR、视频使用QCI为2的GBR QCI Resourc e Type Priority Packet Delay Budget Packet Error Loss Rate Example Services 1 GBR 2 100 ms 10-2Conversational Voice 2 4 150 ms 10-3Conversational Video (Live Streaming) 5 No-GBR 1 100 ms 10-6IMS Signalling 不支持VoLTE的 UE 支持VoLTE的UE 未进行VoLTE会话进行VoLTE语音通话进行VoLTE视频通话 QCI9 QCI5+QCI9 QCI1 + QCI5 + QCI9 QCI1 +QCI2+QCI5+QCI9 ?终端业务承载建立对应关系：
VOLTE总体流程
内容 VoLTE总体流程 1 VoLTE注册流程 2 VOLTE基本呼叫流程 3
VOLTE注册流程—EPS attach（1） ?VoLTE首先在EPS进行联合attach，与普通CSFB一致，再建立QCI5承载： Default bearer (GBR) QCI=8/9 Internet APN Default bearer (Non-GBR) QCI=5 IMS APN ?UE在attach Req中携带SRVCC能力及VOLTE能力： ?EPC在attach Acp中通知UE，网络侧具有VOLTE-IMS，决定UE紧接下来是否发起QCI5承载建立：
1、主叫信令流程 移动用户做主叫时的信令过程从MS向BTS请求信道开始，到主叫用户TCH指配完成为止。一般来说，主叫经过几个大的阶段：接入阶段，鉴权加密阶段，TCH指配阶段，取被叫用户路由信息阶段。 接入阶段主要包括：信道请求，信道激活，信道激活响应，立即指配业务请求等几个步骤。经过这个阶段，手机和BTS BSC 建立了暂时固定的关系。 鉴权加密阶段主要包括：鉴权请求，鉴权响应，加密模式命令，加密模式完成，呼叫建立等几个步骤。经过这个阶段，主叫用户的身份已经得到了确认，网络认为主叫用户是一个合法用户允许继续处理该呼叫。 TCH指配阶段主要包括：指配命令，指配完成。经过这个阶段，主叫用户的话音信道已经确定，如果在后面被叫接续的过程中不能接通，主叫用户可以通过话音信道听到MSC的语音提示。 取被叫用户路由信息阶段主要包括：向HLR请求路由信息，HLR向VLR请求漫游号码，VLR回送被叫用户的漫游号码，HLR向MSC回送被叫用户的路由信息（MSRN）。MSC收到路由信息后，对被叫用户的路由信息进行分析，可以得到被叫用户的局向。然后进行话路接续。 主叫接入阶段、鉴权阶段主要信令： 当用户输入被叫号码完毕按下发射按纽后，手机（以下以MS代替）将进行一系列动作，首先MS将在随机接入信道（RACH ）向BSS发送信道请求消息，以便申请一个专用信道（SDCCH ），BSC为其分配相应的信道成功后，在接入允许信道(AGCH)中通过立即分配消息通知MS为其分配的专用信道，随后MS将在为其分配的SDCCH上发送一个层三消息 ---CM业务请求消息，在该消息中CM业务类型为移动发起呼叫，该消息被BSS透明的传送至MSC，MSC收到CM业务请求消息后，通过处理接入请求消息通知VLR处理此次MS的接入业务请求，（同时，由于在BSC和MSC之间用到了SCCP有连接服务，为建立SCCP连接，MSC还将向BSC回连接确认消息），收到业务接入请求后，VLR将首先查看在数据库中该MS是否有鉴权三参组，如果有将直接向MSC下发鉴权命令，否则向相应的HLR/AUC请求鉴权参数，从HLR/AUC得到三参组，然后再向MSC下发鉴权命令。MSC收到VLR发送的鉴权命令后，通过BSS向MS下发鉴权请求，在该命令中含有鉴权参数，MS收到鉴权请求后，利
GS_SP01_C2_0 点对点短消息信令流程介绍课程目标： z掌握短消息中心MAP标准信令流程 z掌握预付费用户短消息信令处理流程 z了解其它短消息处理流程 参考资料 z《NO.7信令系统》北京邮电大学出版社
3 第1章 信令处理流程 知识点 z 短消息信令处理标准流程。 z 预付费用户短消息信令处理流程。 z 其它用户短消息信令处理。 1.1 短消息信令处理基本流程 根据点对点短消息业务的种类，信令处理基本流程分为以下两种：移动台发起的 短消息业务和移动台终止的短消息业务。分别介绍移动台向短消息中心发送短消 息的信令流程和移动台从短消息中心接收短消息的信令流程。 1.1.1 移动台发送短消息的信令流程 移动台发送短消息可以有两条路径：通过MSC ／VLR 向短消息中心发送短消息， 以及通过SGSN 向短消息中心发送短消息。 1.1.1.1 移动台通过MSC ／VLR 向短消息中心发送短消息的信令流程 移动台通过MSC ／VLR 向短消息中心发送短消息的信令流程如图3.1-1所示。 图1.1-1 移动台通过MSC ／VLR 发送短消息的信令流程图
CSUA-040-C1 NO.7信令系统 4 如图1.1-1所示，移动台发送短消息涉及的功能实体包括MS 、MSC 、VLR 、IWMSC 和SC 。起点为MS ，途经发送短消息的移动台所在的MSC 和VLR ，IWMSC （短 消息进入短消息中心的关口局），终点为SC 。 8 说明： IWMSC 与SC 合设。但是为了更加清楚地描述信令流程，我们将它们分开描述， 但是仍以虚框表示合设结构。 通过MSC ／VLR 进行短消息起呼的信令流程的（1）~（12）表示移动台发送短 消息的12个步骤。 （1） MS 向MSC 发起接入请求，其中包含MS 的IMSI 或TMSI 号码。 （2） MSC 向VLR 发起接入请求，VLR 在接入处理过程中可进行鉴权和加密。 （3） VLR 向MSC 回送接入证实消息。 （4） MSC 向MS 回送接入证实消息，允许MS 进入GSM 网络通讯。 （5） MS 向MSC 发送一条短消息，其中包含短消息的内容、目的SC 地址。 （6） MSC 向VLR 查询MS 是否可以发送短消息。 （7） VLR 在确认MS 具有短消息业务且没有被禁止后，通知MSC 当前MS 可 以发送短消息，并提供MSISDN 号码。 （8） MSC 向IWMSC 转发短消息，其中包含该条短消息的内容、源MS 的 MSISDN 号码、目的SC 地址。 （9） IWMSC 向SC 转发短消息，其中包含该条短消息的内容、源MS 的MSISDN 号码、目的SC 地址。 （10）S C 通知IWMSC 已接受短消息。 （11） I WMSC 通知MSC 已接收短消息。 （12）M SC 通知MS 短消息发送成功。 移动台向短消息中心提交短消息成功，即进入下面的短消息中心向移动台转发短 消息过程。
TDD-LTE 基本信令流程图
1 概述 本文主要针对TD-LTE端到端信令流程图进行分解，为端到端平台提供分析流程呈现依据。由于部分流程无S1口信令支撑，当前根据相关文档进行的绘制，后续具备条件后进行补充调整。
2 TDD-LTE网络结构概述 LTE的系统架构分成两部分，包括演进后的核心网EPC（MME/S-GW）和演进后的接入网E-UTRAN。演进后的系统仅存在分组交换域。 LTE接入网仅由演进后的节点B（evolved NodeB）组成，提供到UE的E-UTRA控制面与用户面的协议终止点。eNB之间通过X2接口进行连接，并且在需要通信的两个不同eNB之间总是会存在X2接口。LTE接入网与核心网之间通过S1接口进行连接，S1接口支持多—多联系方式。 与3G网络架构相比，接入网仅包括eNB一种逻辑节点，网络架构中节点数量减少，网络架构更加趋于扁平化。扁平化网络架构降低了呼叫建立时延以及用户数据的传输时延，也会降低OPEX与CAPEX。 由于eNB与MME/S-GW之间具有灵活的连接（S1-flex），UE在移动过程中仍然可以驻留在相同的MME/S-GW上，有助于减少接口信令交互数量以及MME/S-GW的处理负荷。当MME/S-GW与eNB之间的连接路径相当长或进行新的资源分配时，与UE连接的MME/S-GW 也可能会改变。 E-UTRAN
2.1 EPC 与E-UTRAN 功能划分 与3G 系统相比，由于重新定义了系统网络架构，核心网和接入网之间的功能划分也随之有所变化，需要重新明确以适应新的架构和LTE 的系统需求。针对LTE 的系统架构，网络功能划分如下图： eNodeB 功能： 1） 无线资源管理相关的功能，包括无线承载控制、接纳控制、连接移动 性管理、上/下行动态资源分配/调度等； 2） IP 头压缩与用户数据流加密； 3） UE 附着时的MME 选择； 4） 提供到S-GW 的用户面数据的路由； 5） 寻呼消息的调度与传输； 6） 系统广播信息的调度与传输； 7） 测量与测量报告的配置。 MME 功能： 1） 寻呼消息分发，MME 负责将寻呼消息按照一定的原则分发到相关的 eNB ； 2） 安全控制； E-UTRAN
TD-LTE信令流程及信令解码 本文主要就PS业务建立流程和LTE系统内切换的信令及信令解码进行重点IE分析，并加以标注，所有信令为eNB侧跟踪的信令。 PS业务建立流程： 1.1RRC Connection Request UE上行发送一条RRC Connection Request消息给eNB,请求建立一条RRC连 接，该消息携带主要IE有： -ue-Identity :初始的UE标识。如果上层提供S-TMSI，侧该值为S-TMSI； 否则从0…240-1中抽取一个随机值，设置为ue-Identity。 -establishmentCause:建立原因。该原因值有emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, spare3, spare2, spare1。其中“mt”代表移动终端，“mo”代表移动始端。 信令解码如下： -RRC-MSG : |_msg : |_struUL-CCCH-Message : |_struUL-CCCH-Message : |_message : |_c1 : |_rrcConnectionRequest : |_criticalExtensions : |_rrcConnectionRequest-r8 : |_ue-Identity : |_establishmentCause : ---- highPriorityAccess(1) |_spare : ---- '0'B(00 ) 04 53 14 97 b7 8c 32 1.2RRC Connection Setup UE初始标识，此处因为上层没有提供S-TMSI,所以为随机值。 建立原因，此处 highPriorityAcces s指的是AC11~AC15
短消息处理流程 MO流程 MO（Mobile Originated），即移动台始发的短消息，指的是移动台MS向短消息中心提交短消息，到收到短消息中心返回的应答消息的过程。 具体流程如下。 1.移动台MS向VLR提交访问请求和可选的鉴权请求（Access request and possible authentication）。 2.移动台MS向MSC提交短消息（Message Transfer）。 3.MSC向SMC提交短消息（Message Transfer）。 4.SMC向MSC回送应答（Success or Error）。 5.MSC向MS回送应答（Success or Error）。 MT流程 MT（Mobile Terminated），移动台终止的短消息，指的是短消息中心按一定的规则把短消息发送给目的移动台MS，到收到移动台MS返回的应答消息的过程。 SMC根据目的手机号码找到目的手机归属的HLR，并且发送消息到该HLR查询目的手机当前所在的MSC的地址。得到该地址后，SMC发送消息到目的手机所在MSC，由该MSC将短消息转发到该目的手机。目的手机收到短消息后给SMC回送应答消息。
具体流程如下。 1.SMC向HLR查询发送路由（SendRoutingInfo_For_ShortMessage），从HLR 取回用户的IMSI号码和目前用户所在的MSC的地址。 2.SMC向MSC前传短消息（Forward_ShortMessage）。 3.MSC向VLR查询发送路由（SendInfoFor_MT_SMS），从VLR取回当前手机 用户所在的小区位置信息。 4.MSC向移动台MS发送短消息（Message Transfer）。 5.MS向MSC回送MT消息的ACK消息。 6.MSC向SMC回送转发报告（Delivery report）。 MT的流程较为复杂，以上仅为正常下发流程，现在将非正常下发流程说明如下。 ?如果用户不在服务区或用户手机短消息内存已满，则SMC会发信令消息到HLR置MNRF（Mobile Not Reachable Flag）或MCEF（Memory Capacity Exceeded Flag）标志，信令名称为Delivery Status Report。 ?当SMC去HLR取路由时，如果HLR内MNRF或MCEF已被置位，则HLR除发送路由信息，还要发送Inform SC信令到SMC（如果HLR为PHASE1版本，则无此过程），通知该用户不可用，此时如果下发的短消息为普通优先级，则SMC不再下发，如果短消息为高优先级，则SMC尝试下发该短消息，如 果发送不成功则下发结束，如果下发成功，则发信令消息到VLR清除MNRF 或MCEF标志，如果清除成功，HLR发送Alert_SC消息到SMC，如果该用 户仍有短消息未发出，则SMC会保持与MSC的会话，然后继续下发短消息，直到发完或出错为止。 ?每次成功下发后，SMC检测短消息是否是MO短消息且要求状态报告。如果是，则下发状态报告短消息到提交用户。 Alert_SC流程 当HLR检测到手机不可接收短消息的原因（如用户关机、存储区满等）解除时（如该移动台开机、移动台内存可用等），会主动向SMC发Alert_SC消息，SMC收到后立即尝试向该手机重发短消息。 手机开机的呼叫流程如下： 手机开机后，通过BTS和BSC向MSC请求接入。如果该手机是第一次在该MSC 管辖的区域内开机，则VLR内没有该手机的相关信息。这时MSC会根据手机号码的前7位找到该手机归属的HLR，并且发送消息到该HLR查询该手机的相关信息。HLR将相关的信息发送到MSC后，如果MSC认为该用户是合法的，则接受该手机的登录请求。在这个过程中，HLR也记录了该手机当前所在的MSC的地址。 当手机开机后，HLR就会发送Alert_SC消息给SMC，提醒SMC将存储的消息发给该手机，这就是Alert_SC过程。 具体流程如下。
LTE信令流程
目录 第一章协议层与概念 (5) 1.1控制面与用户面 (5) 1.2接口与协议 (5) 1.2.1NAS协议（非接入层协议） (7) 1.2.2RRC层（无线资源控制层） (7) 1.2.3PDCP层（分组数据汇聚协议层） (8) 1.2.4RLC层（无线链路控制层） (8) 1.2.5MAC层（媒体接入层） (9) 1.2.6PHY层（物理层） (10) 1.3空闲态和连接态 (12) 1.4网络标识 (13) 1.5承载概念 (14) 第二章主要信令流程 (16) 2.1 开机附着流程 (16) 2.2随机接入流程 (19) 2.3 UE发起的service request流程 (23) 2.4寻呼流程 (26) 2.5切换流程 (27) 2.5.1 切换的含义及目的 (27) 2.5.2 切换发生的过程 (28) 2.5.3 站内切换 (28) 2.5.4 X2切换流程 (30) 2.5.5 S1切换流程 (32) 2.5.6 异系统切换简介 (34) 2.6 CSFB流程 (35) 2.6.1 CSFB主叫流程 (36) 2.6.2 CSFB被叫流程 (37) 2.6.3 紧急呼叫流程 (39) 2.7 TAU流程 (40) 2.7.1 空闲态不设置“ACTIVE”的TAU流程 (41)
2.7.2 空闲态设置“ACTIVE”的TAU流程 (43) 2.7.3 连接态TAU流程 (45) 2.8专用承载流程 (46) 2.8.1 专用承载建立流程 (46) 2.8.2 专用承载修改流程 (48) 2.8.3 专用承载释放流程 (50) 2.9去附着流程 (52) 2.9.1 关机去附着流程 (52) 2.9.1 非关机去附着流程 (53) 2.10 小区搜索、选择和重选 (55) 2.10.1 小区搜索流程 (55) 2.10.1 小区选择流程 (56) 2.10.3 小区重选流程 (57) 第三章异常信令流程 (60) 3.1 附着异常流程 (61) 3.1.1 RRC连接失败 (61) 3.1.2 核心网拒绝 (62) 3.1.3 eNB未等到Initial context setup request消息 (63) 3.1.4 RRC重配消息丢失或eNB内部配置UE的安全参数失败 (64) 3.2 ServiceRequest异常流程 (65) 3.2.1 核心网拒绝 (65) 3.2.2 eNB建立承载失败 (66) 3.3 承载异常流程 (68) 3.3.1核心网拒绝 (68) 3.3.2 eNB本地建立失败（核心网主动发起的建立） (68) 3.3.3 eNB未等到RRC重配完成消息，回复失败 (69) 3.3.4 UE NAS层拒绝 (70) 3.3.5上行直传NAS消息丢失 (71) 第四章系统消息解析 (72) 4.1 系统消息 (73) 4.2 系统消息解析 (74) 4.2.1 MIB （Master Information Block）解析 (74) 4.2.2 SIB1 （System Information Block Type1）解析 (75) 4.2.3 SystemInformation消息 (77) 第五章信令案例解析 (83) 5.1实测案例流程 (84)
（流程管理）位置更新具体信令流程
位置更新 4.1 概述 于GSM系统中有三个地方需要知道位置信息，即HLR、VLR和MS。当 这个信息发生变化时，需要保持三者的壹致，由位置更新流程实现。位置 更新流程是位置管理中的主要流程，总是由MS发起。 位置更新流程是壹个通用流程，于如下三类位置更新流程中要使用到：正 常位置更新、周期性位置更新、IMSI附着位置更新流程。 正常位置更新用于更新网络侧对于MS的位置区信息， LOCATIONUPDATINGREQUEST消息中包含位置更新流程的类型信息。 于网络侧VLR判定MS为未知用户时，会启动正常位置更新流程，作为 MM连接建立请求的响应。 为限制位置更新尝试次数，位置更新失败时要使用位置更新 attemptcounter计数器。于MS开机或SIM卡刚插入时，该计数器清零。 MS中要保持壹个"forbiddenlocationareasforroaming"表和壹个 "forbiddenlocationareasforregionalprovisionofservice"表。MS关机 或SIM卡拔出时，将这俩个表删除。当MS收到位置更新拒绝消息，其 原因值为"Roamingnotallowedinthislocationarea"或 "LocationAreanotallowed"时，从BCCH上收到的LAI信息触发位置更 新请求的LAI要加到相应的表中。这俩个表的容量至少要有10个表项， 当表项数目超过表的容量时，最早的表项内容删除。 成功的进行位置更新后，MS于SIM卡中置UPDATED状态位（UPDATED 状态表明最后壹次位置更新请求成功，同时此时LAI、TMSI，加密的密钥 和加密序列号均应该保存于SIM卡中），且存储新的位置区信息。 4.2 位置更新流程 正常位置更新、周期性位置更新和IMSI附着位置更新流程基本相同（不 同之处于下面各小节中详细描述），流程如下图： 图4-1位置更新流程 (1) MS于空中接口的接入信道上向BTS发送ChannelRequest（该消 息内含接入原因值为位置更新）；
LTE空口信令流程详解以及相关优化案例汇总1、附着信令流程 1.1 、Attach附着信令流程 （统计时延：红色的为开始和结束信令） EPS MM Attach request EPS MM Unknown(0x0734) UL CCCH rrcConnectionRequest DL CCCH rrcConnectionSetup UL DCCH rrcConnectionSetupComplete DL DCCH rrcConnectionReconfiguration DL DCCH dlInformationTransfer UL DCCH rrcConnectionReconfigurationComplete EPS MM Security protected NAS message EPS MM Authentication request EPS MM Authentication response EPS MM Unknown(0x077B) UL DCCH ulInformationTransfer DL DCCH dlInformationTransfer EPS MM Security protected NAS message EPS MM Security mode command EPS MM Security mode complete EPS MM Unknown(0x0790) UL DCCH ulInformationTransfer DL DCCH ueCapabilityEnquiry UL DCCH ueCapabilityInformation DL DCCH securityModeCommand DL DCCH rrcConnectionReconfiguration UL DCCH rrcConnectionReconfigurationComplete EPS MM Security protected NAS message EPS MM Attach accept EPS SM Activate default EPS bearer context request EPS SM Activate default EPS bearer context accept EPS MM Attach complete EPS MM Unknown(0x072D) UL DCCH ulInformationTransfer DL DCCH rrcConnectionReconfiguration UL DCCH rrcConnectionReconfigurationComplete
LTE信令流程之开机附着、去附着流程分析 开机附着流程 开机附着流程说明： ?N0010处在RRC_IDLE态的UE进行Attach过程，发起随机接入过程，即MSG1消息； ?N0020eNB检测到MSG1消息后向UE发送随机接入响应消息，即MSG2消息；
?N0030UE收到随机接入响应后，根据MSG2的TA调整上行发送时机，向eNB发送RRCConnectionRequest消息申请建立RRC连接； ?N0040eNB向UE发送RRCConnectionSetup消息，包含建立S RB1信令承载信息和无线资源配置信息； ?N0050 UE完成SRB1信令承载和无线资源配置，向eNB发送RRC ConnectionSetupComplete消息，包含NAS层Attach request信息； ?N0060eNB选择MME，向MME发送INITIAL UE MESSAGE 消息，包含NAS层Attach request消息； ?N0070 MME向eNB发送INITIAL CONTEXT SETUP REQUES T消息，包含NAS层Attach Accept消息； ?N0080eNB接收到INITIAL CONTEXT SETUP REQUEST消息，如果不包含UE能力信息，则eNB向UE发送UECapabilityEnquiry消息，查询UE能力； ?N0090 UE向eNB发送UECapabilityInformation消息，报告UE能力信息； ?N0100 eNB向MME发送UE CAPABILITY INFO INDICATION消息，更新MME的UE能力信息； ?N0110 eNB根据INITIAL CONTEXT SETUP REQUEST消息中UE支持的安全信息，向UE发送SecurityModeCommand消息，进行安全激活； ?N0120 UE向eNB发送SecurityModeComplete消息，表示安全激活完成； ?N0130 eNB根据INITIAL CONTEXT SETUP REQUEST消息中的ERAB 建立信息，向UE发送RRCConnectionReconfiguration消息进行UE资源重配，包括重配SRB1信令承载信息和无线资源配置，建立SRB2、DRB（包括默认承载）等； ?N0140 UE向eNB发送RRCConnectionReconfigurationComplete消息，表示无线资源配置完成； ?N0150 eNB向MME发送INITIAL CONTEXT SETUP RESPONSE响应消息，表明UE上下文建立完成； ?N0160 UE向eNB发送ULInformationTransfer消息，包含NAS层Attach C omplete、Activate default EPS bearer context accept消息；
Issue 3.3 课程说明 课程介绍 GSM通信流程包括两方面的内容：呼叫基本流程，信令基本流程。其中，呼叫流程主要包含：移动主叫流程，移动被 叫流程，汇接呼叫流程。信令基本流程主要包含：鉴权流程，位置登记流程，呼叫重建流程，BSC内部切换流程，BSC 间切换流程，MSC间切换流程，移动始发短消息流程，移动终结短消息流程，定向重试流程。 这些流程从系统的角度描述了移动用户经常发生的行为，描述了GSM的几个组成部分在呼叫流程、信令流程中的相互 关系，对移动性特征做重点说明。 课程目标 本课程的重点是介绍GSM系统的协同工作过程，涉及内容包含：呼叫、位置更新、切换、短消息。对流程的介绍突出 了移动特征，具体的信令细节本课程不做描述，可以参考ETSI的GSM规范获得更加详细的内容。 通过学习本课程，可以基本掌握： ?移动用户做位置登记的信令过程； ?移动用户做主叫的信令过程； ?移动用户做被叫的信令过程； 1
Issue 3.3 ?MSC做汇接呼叫的信令过程； ?BSC内切换信令过程； ?BSC间切换的信令过程； ?MSC间切换的信令过程； ?呼叫重建的信令过程； ?定向重试的信令过程。 对这些信令流程学习之后，对GSM系统的原理会有更加深刻的了解，对每个功能实体（MS，BTS，BSC，MSC，VLR， HLR）的功能有更加深刻的体会。 相关资料 ETSI关于GSM的规范，主要是：GSM0408，GSM0808，GSM0902。 2
Issue 3.3 第一节呼叫过程的信令分析 对一次发生在移动用户间的呼叫来说，信令流程可以分为三个相对独立的部分： ?主叫移动用户部分 ?被叫移动用户部分 ?拆线部分 1.1 主叫信令流程 移动用户做主叫时的信令过程从MS向BTS请求信道开始，到主叫用户TCH指配完成为止。一般来说，主叫经过几个大 的阶段：接入阶段，鉴权加密阶段，TCH指配阶段，取被叫用户路由信息阶段。 ?接入阶段主要包括：信道请求，信道激活，信道激活响应，立即指配，业务请求等几个步骤。经过这个阶段，手机 和BTS（BSC）建立了暂时固定的关系。 ?鉴权加密阶段主要包括：鉴权请求，鉴权响应，加密模式命令，加密模式完成，呼叫建立等几个步骤。经过这个阶 段，主叫用户的身份已经得到了确认，网络认为主叫用户是一个合法用户，允许继续处理该呼叫。 ?TCH 指配阶段主要包括：指配命令，指配完成。经过这个阶段，主叫用户的话音信道已经确定，如果在后面被叫 接续的过程中不能接通，主叫用户可以通过话音信道听到MSC的语音提示。 3
信令流程与GT翻译详解 MSC与HLR、MSC间进行通信，用到MTP、SCCP、TCAP、CAP各层协议栈，其中MTP层只识别各设备的信令点，SCCP层只识别MSC/VLR/GCR/SSP、HLR/AuC、SCP、SMSC等各个网元的设备识别码（俗称设备号），IMSI、MSISDN等。所以如果要实现MSC与HLR、MSC、SCP（智能网）等网元的通讯（信令流程传递的过程）。就要把SCCP层识别的MSC/VLR/GCR/SSP、HLR/AuC、SCP、SMSC设备识别码、IMSI、MSISDN翻译成相应网元信令点，实现个网元之间的通信和业务通信，即所谓的GT翻译（GT指向）。如下图所示即各个网元间的协议通信模型。 下面用位置更新流程中使用的IMSI，被叫分析流程中使用的MSISDN以及在各网元传递消息时使用的MSC/VLR/GCR/SSP、HLR/AuC、SCP、SMSC识别码，结合信令流程特点分析各网元间的GT翻译（即把各类转换成相应设备的信令点）是如何实现的。
图1：新用户开机位置更新与相关号码GT 翻译对应关系流程分析 1、新用户第一次开机，收到该小区的广播消息中携带的LAI+CGI 值，向网络侧发起位置更新请求消息，消息中携带IMSI 号码，LAI+CGI 信息。 2、MSC/VLR 根据手机上报的IMSI 号码，进行GT 翻译，找到该IMSI 所对应的归属HLR 信令点。并存储移动台的LAI （IMSI 号码对HLR 信令点的GT 翻 译） 、MSC 根据IMSI 翻译出的HLR 信令点向HLR 请求识别号，IMSI 、MSISDN 号码 4、HLR 记录该MSC/VLR 识别码，并建立该移动台IMSI 、MSISDN 号码与 MSC/VLR 识别码的对应关系。以便进行语音呼叫。（即移动台完成了HLR 里的位置登记） 图2 ：跨局位置更与相关号码对应关系流程分析 1、移动台漫游到MSC/VLR （2）局，收到该小区BCCH 信道广播消息中携带的LAI+CGI 值，发现与本移动台存储的LAI 值不符，触发位置更新请求，向MSC/VLR （2）请求位置更新，消息中携带该移动台的IMSI 号码 2、MSC/VLR （2）根据移动台上报的IMSI 号码，进行GT 翻译，找到该IMSI 所对应的归属HLR 信令点。并存储移动台的LAI 、MSC （2）向HLR 请求该用户的用户MSC/VLR IMSI 、MSISDN 号码 4、HLR 记录该MSC/VLR （2 ）识别码，并建立该移动台IMSI 、MSISDN 号码与（2）识别码的对应关系。以5、HLR 把该MSC/VLR （2）识别号码翻译成MSC/VLR （2）的信令点，找到该MSC/VLR （2），向MSC/VLR 插入该用户的用户数据。并在消息中携带该HLR 的识别号。 6、MSC/VLR （2)把HLR 识别号码翻译成HLR 信令点，向HLR 发送插入数据响应消息8、HLR 5、HLR 把该MSC/VLR 翻译成MSC/VLR 的信令点，找到该MSC/VLR ，向MSC/VLR 插入该用户的用户数据（HLR 中需要做的MSC/VLR 识别号与 MSC/VLR 信令点的GT 翻译） 7、HLR 根据记录的MSC/VLR （1）识别号，翻译成MSC/VLR （1）的信令点，向MSC(1)发送删除用户数据的消息。消息中携带HLR 识别号。
Layer 3信令分析及流程详解汇编
Layer 3信令是看网络运行情况的信息层，从第三层可以看到网络的各种动作：如：呼叫流程、拥塞、用户忙、位置更新等，并且可以对路测中的各种问题如掉话、切换失败等网络事件的原因进行准确的分析。 系统信息一般有8个类型，分别是1、2、3、4、5、6、7、8，Type 1～4只出现在待机状态下，Type 5～6只出现在通话状态下，明白这点，对以后的分析至关重要。其中2中含有：2、2bis、2ter，5中含有5、5bis、5ter，所以总共有12种系统信息，系统信息1仅用于跳频，所以称为选择项。其中1、2、3、4、2bis、2ter 、7、8都在BCCH上发送，由IDLE模式下的移动台接收。5、5bis、5ter、6在SACCH上发送，由ACTIVE模式下的移动台接收。一般来说所有系统信息在连续的8个51复帧中发送完，如下图示： 上图中的TC表示复帧序列号，可以看出，当TC=4、5时，发送的内容是可选的，其它是固定的。 TC=0固定发送跳频信息，当出现上图示的1（3）时，表示跳频时发类型1，不跳频时发类型3 当类型4中发送的关于小区重选信息不够完整时，由类型7、8补充。且在TC=7、3时发送（上图示） 对于类型5、6在下行的SACCH上发送，并没有复帧规范，除非切换完成后要立即发送类型5、6。 1、System Information Type1
说明：系统信息类型1 （频率信息） 此类型仅用于跳频时，发送内容为： 第一、小区信道描述。用于通知移动，小区采用的频带与可以供跳频用的频点。对于GSM900与GSM1800采用的格式是不同的。对于GSM900： 有一个BIT MAP 0（比特位图）用于描述两方面信息，分别为： CA-NO，取值分别为：0、1、2，代表，GSM900、GSM1800、GSM1900。 CA-ARFCN，采用的有效射频频点，当为GSM900，将有一个相应于124个频点的124位图，当某个频点被采用时，相应的比特位被置为1，否则将被置为0. 对于GSM1800情况点不同。由于频点太多，不用位图，而用别的编码方式，FORMAD-IND=？来描述编码方式，后面跟一串编码比特来表示。 第二、RACH控制参数，描述的两个数据为；ACC、EC，ACC称为接入控制等级，分为0-9与11-15，0-9表示普通级，所有移动台被定义为0-9，11-15为优先级，10表示EC，如果此位取0，表示所有移动台允许进行紧急呼叫，取1时，只有11-15优先级的移动台可以进行紧急呼叫。 CB——小区禁止标志，用一个比特表示。