發(fā)現(xiàn)沒有威望的朋友挺多，我看了一下都是文字就貼出來了，格式變了有點難受，大家復制一下看看吧，就不用下載了。

有完整的層3呼叫流程,可以和有問題的對比一下,配合路測使用,隨便看了一下才知道層3消息怎么看掉話



層3信令在路測中的應用

目 錄

1. 概述........ 理論部分
2.1一次完整的主叫流程（含切換）
2.2一次正常的LAR&RAU信令流程：
2.3 各種情況對應的信令..
2.4常見Disconnect / Release Cause Value:
2.5 兩個MS通話的流程
3. 案例介紹
3.1 MS呼叫未接通：
3.2 位置更新導致數(shù)據(jù)吞吐量為0
3.3 FTP下載中斷
3.4 沒有物理消息導致切換失敗
3.5 MS呼叫失敗
3.6 參數(shù)設(shè)置錯誤導致切換問題
3.7定時器超時， 網(wǎng)絡進行呼叫釋放
4. 感謝
5. 參考文獻
1. 概述
作為一名網(wǎng)優(yōu)工程師, 需要牢牢掌握一個完整呼叫的信令流程. 我們做GSM優(yōu)化, 主
要是對Um口要把握的更深些. 尤其是Layer3信令－也就是我們平常做路測的工程師說的層
3信令。關(guān)于層3信令，可以參考GSM規(guī)范04.08. 對層3信令的準確理解,可以幫助我們快
速分析和定位網(wǎng)絡問題.
本期議題為“請舉例說明如何結(jié)合層3信令分析路測中發(fā)現(xiàn)的問題”。討論為期一個月，移動
通信俱樂部的廣大移友獻計獻策，對該議題進入了深入細致的討論和分析，得出了大量具有
實踐意義的分析與心得。為此，特將其中精華部分加以總結(jié)歸納，形成該文檔。
2. 理論部分

2.1一次完整的主叫流程（含切換）
IDLE：
DL: SYSTEM INFORMATION TYPE 1：包括小區(qū)信道描述和RACH控制參數(shù)
DL: SYSTEM INFORMATION TYPE 2（2bis，2ter）：鄰小區(qū)BCCH頻點描述，RACH
控制信道，允許的PLMN（擴展鄰小區(qū)BCCH頻點描述+RACH控制信道；擴展鄰小區(qū)BCCH
頻點描述2）
DL: SYSTEM INFORMATION TYPE 3：CI，LAI，控制信道描述，小區(qū)選擇，小區(qū)選
擇參數(shù)，RACH控制參數(shù)
DL: SYSTEM INFORMATION TYPE 4：LAI，小區(qū)選擇參數(shù)，RACH控制參數(shù)，CBCH
信道描述，CBCH移動配置
DL: SYSTEM INFORMATION TYPE 7：小區(qū)重選參數(shù)
DL: SYSTEM INFORMATION TYPE 8：小區(qū)重選參數(shù)
UL: Channel request
DL: Immediate assignment（SDCCH）
試呼：
UL:CM service request（如果后面直接收到System Information Type1，則視為起呼失�。�
DL: CM service Request
DL: CM service accept
DL: AUTHENTICATION REQUEST
UL: AUTHENTICATION RESPONSE
DL: CIPHER MODE COMMAND
UL: CIPHER MODE COMPLETE
DL: TMSI REALLOCATION COMMAND
UL: TMSI REALLOCATION COMPLETE
UL: SETUP

DL: CALL PROCEEDING
DL: ASSIGNMENT COMMAND
UL: ASSIGNMENT COMPLETE （TCH）
DL: ALERTING

成功起呼：
DL: CONNECT（呼叫成功的標志,）
UL: CONNECT ACKNOWLEDGE
DL: SYSTEM INFORMATION TYPE 5（5bis，5ter）：鄰近小區(qū)BCCH頻點描述（擴展
鄰近小區(qū)BCCH頻點描述）
DL: SYSTEM INFORMATION TYPE 6：CI，LAI，小區(qū)參數(shù)設(shè)置
UL: MEASUREMENT REPORT
DL:Handover Command
DLhysical Information
UL:Handover Complete(切換成功的標志)
DLhysical Information
DL: SYSTEM INFORMATION TYPE 6
UL: MEASUREMENT REPORT
DLisconnect（收到該條消息或Release中的任何一條，則視為正常釋放，如果兩條消
息均未收到，而是直接收到System Information Type1，則視為一次掉話）
UL:Release
DL:Release Complete
DL:Channel Release
UL:Release Complete

2.2一次正常的LAR&RAU信令流程：
Direction Type Layer 3 Message
UL RR Channel Request
DL RR Immediate Assignment
UL MM Location Updating Request
UL RR Classmark Change
UL RR GPRS Suspension Request
DL MM Authentication Request
UL MM Authentication Response
DL MM Identity Request
UL MM Identity Respone
DL MM Location Updating accept
UL MM TMSI Realocation Complete
DL RR Channel Release
UL GPRS MM Routing Area Update Request


UL RR Channel Request
DL RR Immediate Assignment
DL GPRS MM Routing Area Update Accept
UL GPRS MM Routing Area Update Complete


2.3 各種情況對應的信令
2 掉話（既沒有Disconnect，也沒有Release，則視為掉話）： Paging Request→Channel
Request→Immediate Assignment→CM Service Request→CM Service Accept→Setup→
Assignment Command→Assignment Complete→Connect/Alerting→System Information Type1

2 通話正常結(jié)束(Disconnect和Release都有或只有其中一個都視為通話正常結(jié)束)：
Paging Request→Channel Request→Immediate Assignment→CM Service Request→CM Service
Accept→Setup→Assignment Command→Assignment Complete→Alerting→Disconnect→
Release→Release Complete→Channel Release

2 呼叫失敗： Paging Request→Channel Request→Immediate Assignment→CM
Service Request→System Information Type1（在一次呼叫過程中，若連續(xù)出現(xiàn)多個CM Service
Request，則視為一次呼叫失�。�

2 呼叫成功：Paging Request→Channel Request→Immediate Assignment→CM Service
Request→CM Service Accept→Setup→Assignment Command→Assignment Complete→
Connect/Alerting

2 切換成功：Handover Command→Handover Complete

2 切換失�。篐andover Command→Handover Failure

2.4常見Disconnect / Release Cause Value:
Cause Value
Reason
31
BSS or MSC problem
34(beforeAssignmentCommand)
TCH Blocking
34(after Assignment Complete)
MSC Blocking
41(after Assignment Command)
BSS problem, especially DRI problem
41(after Assignment Complete)
MSC problem
42
MSC Congestion
44
BSS problem, especially the CIC blocking


111
BSS or MSC problem

2.5 兩個MS通話的流程
MS1 Uplink Channel Request
MS1 Downlink Immediate Assignment
MS1 Uplink CM Service Request
MS1 Downlink CM Service Accept SDCCH分配成功
MS1 Uplink Setup
MS1 Downlink Call Proceeding
MS1 Downlink Assignment Command
MS1 Uplink Assignment Complete TCH分配成功
MS2 Uplink Channel Request
MS2 Downlink Immediate Assignment
MS2 Uplink Paging Response SDCCH分配成功
MS2 Downlink Setup
MS2 Uplink Call Confirmed
MS2 Downlink Assignment Command
MS2 Uplink Assignment Complete TCH分配成功
MS2 Uplink Alerting
MS1 Downlink Alerting
MS2 Uplink Connect
MS2 Downlink Connect Acknowledge
MS1 Downlink Connect
MS1 Uplink Connect Acknowledge
MS1 Uplink Disconnect
MS1 Downlink Release
MS1 Uplink Release Complete
MS2 Downlink Disconnect
MS2 Uplink Release
MS1 Downlink Channel Release
MS2 Downlink Release Complete
MS2 Downlink Channel Release


3. 案例介紹

3.1 MS呼叫未接通：
問題描述: 在做DT測試過程中發(fā)生了一次未接通，地點是LAC區(qū)交接處.在DT測試
的行程中，可能發(fā)生數(shù)次跨LAC區(qū)的切換，極易發(fā)生掉話或未接通情況。主要有以下三條
信令消息：
UL：CHANNEL REQUEST
DL：IMMEDIATE ASSIGNMENT
UL：CM SERVICE REQUEST
問題分析: (1)在上行的CM SERVICE REQUEST信令發(fā)出后，沒有下行的響應，通話狀
態(tài)由起呼直接轉(zhuǎn)為空閑模式（IDLE），由此可以斷定發(fā)生了一次未接通。由于上行UL：CM
SERVICE REQUEST是MS發(fā)起的對SDCCH的申請，發(fā)出申請后沒有應答，沒有出現(xiàn)標志
呼叫接通的信令消息，可以斷定發(fā)生了一次未接通情況。其原因可能為該服務小區(qū)的SDCCH
信道擁塞，也可能是由于無線環(huán)境的惡化造成SDCCH信令丟失。因為此次DT測試發(fā)生在
跨數(shù)個LAC的路段，而且是上一個通話剛剛結(jié)束，起初判斷可能是發(fā)生了一次位置更新。
(2) 位置更新信令消息如下：
DL：CHANNEL RELEASE
UL：CHANNEL REQUEST（開始位置更新）
DL：IMMEDIATE ASSIGNMENT
UL：LOCATION UPDATING REQUEST
DL：AUTHENTICATION REQUEST
UL：AUTHENTICATION RESPONSE
DL：LOCATION UPDATING ACCEPT
UL：TMSI REALLOCATION COMPLETE
DL：CHANNEL RELEASE
結(jié)合此例的第三層信令消息來看，例子中MS發(fā)出了UL：CM SERVICE REQUEST，
并不是UL：LOCATION UPDATING REQUEST，由此可以判斷出此例并非是位置更新。

3.2 位置更新導致數(shù)據(jù)吞吐量為0
問題描述: 在某路段,進行數(shù)據(jù)業(yè)務測試時,發(fā)現(xiàn)MS數(shù)據(jù)吞吐量變?yōu)?,沒有了與GPRS網(wǎng)絡的連接.
問題分析: (1) 在該路段進行語音業(yè)務測試, 確認已經(jīng)完全覆蓋.
(2) 分析當時數(shù)據(jù)業(yè)務測試的層3信令. 當時的信令為:
DL：SYSTEM INFORMATION TYPE 1
UL：LOCATION UPDATING REQUEST
UL：CHANNEL REQUEST
初步定位數(shù)據(jù)吞吐量變?yōu)?的原因是 MS執(zhí)行了一次跨路由區(qū)的小區(qū)重選

(3) 對比在當時顯示圖的信令部分可以明顯的看出該MS正在做位置更新.
3.3 FTP下載中斷
問題描述: 在DT FTP下載測試中，MS已成功登陸FTP Server，并已經(jīng)開始下載數(shù)據(jù)，F(xiàn)TP下載進度
為9％，在經(jīng)過一次小區(qū)重選后, FTP下載不能繼續(xù)進行，在一系列的Ping fail后，F(xiàn)TP掉線.
問題分析: (1) 查看層三信令,具體顯示如下：
Direction Type Layer 3 Message
UL GPRS SM Deactivate PDP Context Request
DL RR System Information Type 13
UL RR Channel Request
DL RR Immediate Assignment
DL GPRS SM Deactivate PDP Context Accept
發(fā)現(xiàn)在事件列表中有PDP Deactivated的消息，在層三消息中可以看到是手機發(fā)起的上行消息.
(2)發(fā)生這種情況可能有3種原因：
一是手機在測試過程中電纜的某個接口發(fā)生了松動，這樣手機可能會發(fā)出PDP去激活申請。
二是手機本身存在一些問題也可能導致這個問題。
三是測試用的筆記本電腦可能存在一些問題

3.4 沒有物理消息導致切換失敗
問題描述: 某地主要由4173、4081小區(qū)覆蓋，上述兩個小區(qū)及相鄰小區(qū)同屬于LAC：13588。DT測
試過程中，MS當前服務小區(qū)為4173，當檢測到有Level 更強的鄰區(qū)時，BSC指示MS切換（發(fā)起DL：
HANDOVER COMMAND），此時發(fā)生了連續(xù)的三次切換失�。║L：HANDOVER FAILURE）。雖然本例
中經(jīng)歷了連續(xù)三次切換失敗，MS仍然沒有掉話（MS還在發(fā)送測量報告），但是對連續(xù)的切換失敗應
該給予很大的重視。
問題分析: (1) 查看當時的層三信令, 具體如下:
DL：HANDOVER COMMAND
UL：HANDOVER ACCESS
UL：HANDOVER COMPLETE
UL：MEASUREMENT REPORT
UL：HANDOVER FAILURE
DL：SYSTEM INFORMATION TYPE 5
(2) 從切換的兩個小區(qū)來看，4173向4081切換，是不同步切換，所以BSC應該在MS發(fā)出UL：
HANDOVER ACCESS消息后，接著發(fā)出DL：PHYSICAL INFORMATION，指示MS切換至目標小區(qū)的
Timing Advance，即MS與切換目標小區(qū)的距離。同時，在MS發(fā)出UL：HANDOVER COMPLETE之
后，再發(fā)一條DL：PHYSICAL INFORMATION。
(3)但是在本例中BSC沒有發(fā)出這兩條消息，導致發(fā)生切換失敗。


3.5 MS呼叫失敗.
經(jīng)檢查信令發(fā)現(xiàn)有立即指派拒絕(immediate assignment reject)消息 系統(tǒng)發(fā)現(xiàn)無可用信道.很可能是
因為系統(tǒng)擁塞引起的

3.6 參數(shù)設(shè)置錯誤導致切換問題
問題描述: 某次路測中發(fā)現(xiàn)手機每當起呼占用（BCCH：554，BSIC：52，LAC：9488，CI：29403），
其只能一直切換到DCS1800網(wǎng)，通話過程中無法測量到GSM900的頻點，一直不能向GSM900網(wǎng)切
換，在測試時不單該小區(qū)自己本身不能測量到GSM900的頻點，在本次通話過程中的所涉及的所有小
區(qū)都不能測量到GSM900的頻點，導致在該路段出現(xiàn)弱信號和質(zhì)差最后導致掉話（雖然在CDD中該
小區(qū)的MBCCHNO中有GSM900的頻點）；
問題分析: (1) 在其他小區(qū)進行起呼測試,發(fā)現(xiàn)MS 切換到該小區(qū)后,則在該小區(qū)仍然能測量到GSM900
的頻點。切換正常；說明問題出在該小區(qū)。
(2) 經(jīng)仔細檢查路測試數(shù)據(jù)的第三層信息，發(fā)現(xiàn)在該小區(qū)起呼時，第三層信息沒有出現(xiàn)
UL-CLASSMARK CHANGE這條信令且在該小區(qū)的SYSTEM INFORMATION TYPE3中發(fā)現(xiàn) EARLY
SENDING ：EXPLICITY FORBIDDEN，導致系統(tǒng)認為手機為1800單頻手機；
(3)經(jīng)檢查BSC數(shù)據(jù)，發(fā)現(xiàn)該小區(qū)的ECSC 參數(shù)設(shè)為 NO，其它小區(qū)該參數(shù)設(shè)為 YES。通過調(diào)整該參
數(shù)，問題得到解決。

3.7定時器超時， 網(wǎng)絡進行呼叫釋放
問題描述: 在天津進行靜態(tài)測試， 發(fā)現(xiàn)MO呼叫30秒后自動中斷，網(wǎng)絡發(fā)送disc消息給MS，后面
進行正常的拆除過程。MT呼叫時，MS可以看到incoming call，連接后顯示進入連接狀態(tài)，但主叫端
仍然只能聽到提示音，不能進行正常通話。
問題分析: (1)MO過程如下
MS net
－－CM req--------------->
<---ciph cmd-----------
---ciph completed------->
---setup---------------->
<-----call proceding---
<------assignmend cmd----
-----assignmend complete-->
<---alerting-----------
<----connect-----------
--------connect ack---->

after 30s
<--------disc-------------
(2)因為connect ack是在FACCH上發(fā)送的， 懷疑網(wǎng)絡未能收到ack消息， 因為發(fā)送connect消息
后，網(wǎng)絡端將啟動一個為期30秒的定時器等待MS的確認，出于某種原因，ack消息未能到達網(wǎng)絡，
此定時器超時， 網(wǎng)絡進行呼叫釋放

4. 感謝

Bluealways callboy001 cmcc_cmcc Crazysoda lihj linxiaolu lyp_swit
PeterLiu rifly songlipo xlj96009 yyying 磚頭

[ 本帖最后由 zhuzhenhuazxn 于 2009-6-13 15:35 編輯 ]