路测信令讲解.docx
- 文档编号:25041936
- 上传时间:2023-06-04
- 格式:DOCX
- 页数:23
- 大小:26.73KB
路测信令讲解.docx
《路测信令讲解.docx》由会员分享,可在线阅读,更多相关《路测信令讲解.docx(23页珍藏版)》请在冰豆网上搜索。
路测信令讲解
1.某地主要由4173、4081小区覆盖,上述两个小区及相邻小区同属于LAC:
13588。
DT测试过程中,MS当前服务小区为4173,当检测到有Level更强的邻区时,BSC指示MS切换(发起DL:
HANDOVERCOMMAND),此时发生了连续的三次切换失败(UL:
HANDOVERFAILURE)。
虽然本例中经历了连续三次切换失败,MS仍然没有掉话(MS还在发送测量报告),但是对连续的切换失败应该给予很大的重视。
导致连续的切换失败的原因可能是目标小区的TCH信道拥塞,也可能是目标小区的BCCH载频与TCH载频的发射功率没有调平,导致BCCH与TCH的Level值相差很大而造成切换失败。
第三层信令消息流程:
DL:
HANDOVER COMMAND
UL:
HANDOVER ACCESS
UL:
HANDOVER COMPLETE
UL:
MEASUREMENT REPORT
UL:
HANDOVER FAILURE
DL:
SYSTEM INFORMATION TYPE 5
从切换的两个小区来看,4173向4081切换,是不同步切换,所以BSC应该在MS发出UL:
HANDOVERACCESS消息后,接着发出DL:
PHYSICALINFORMATION,指示MS切换至目标小区的TimingAdvance,即MS与切换目标小区的距离。
同时,在MS发出UL:
HANDOVERCOMPLETE之后,再发一条DL:
PHYSICAL INFORMATION。
在本例中BSC没有发出这两条消息,这也是导致发生切换失败的原因之一。
2.MS呼叫失败.
经检查信令发现有立即指派拒绝(immediateassignmentreject)消息系统发现无可用信道.很可能是因为系统拥塞引起的
3.一次正常的LAR&RAU信令流程如下:
Direction
Type
Layer3Message
UL
RR
ChannelRequest
DL
RR
ImmediateAssignment
UL
MM
LocationUpdatingRequest
UL
RR
ClassmarkChange
UL
RR
GPRSSuspensionRequest
DL
MM
AuthenticationRequest
UL
MM
AuthenticationResponse
DL
MM
IdentityRequest
UL
MM
IdentityRespone
DL
MM
LocationUpdatingaccept
UL
MM
TMSIRealocationComplete
DL
RR
ChannelRelease
UL
GPRSMM
RoutingAreaUpdateRequest
UL
RR
ChannelRequest
DL
RR
ImmediateAssignment
DL
GPRSMM
RoutingAreaUpdateAccept
UL
GPRSMM
RoutingAreaUpdateComplete
4.掉话(既没有Disconnect,也没有Release,则视为掉话):
PagingRequest→ChannelRequest→ImmediateAssignment→CMServiceRequest→CMServiceAccept→Setup→AssignmentCommand→AssignmentComplete→Connect/Alerting→SystemInformationType1
通话正常结束(Disconnect和Release都有或只有其中一个都视为通话正常结束):
PagingRequest→ChannelRequest→ImmediateAssignment→CMServiceRequest→CMServiceAccept→Setup→AssignmentCommand→AssignmentComplete→Alerting→Disconnect→Release→ReleaseComplete→ChannelRelease
呼叫失败:
PagingRequest→ChannelRequest→ImmediateAssignment→CMServiceRequest→SystemInformationType1(在一次呼叫过程中,若连续出现多个CMServiceRequest,则视为一次呼叫失败)
呼叫成功:
PagingRequest→ChannelRequest→ImmediateAssignment→CMServiceRequest→CMServiceAccept→Setup→AssignmentCommand→AssignmentComplete→Connect/Alerting
切换成功:
HandoverCommand→HandoverComplete
切换失败:
HandoverCommand→HandoverFailure
5.我们遇到了一个问题,在天津进行静态测试,发现MO呼叫30秒后自动中断,网络发送disc消息給MS,后面进行正常的拆除过程。
MT呼叫时,MS可以看到incomingcall,连接后显示进入连接状态,但主叫端仍然只能听到提示音,不能进行正常通话。
MO过程如下
MS net
--CMreq--------------->
<---ciphcmd-----------
---ciphcompleted------->
---setup---------------->
<-----callproceding---
<------assignmendcmd----
-----assignmendcomplete-->
<---alerting-----------
<----connect-----------
--------connectack---->
after30s
<--------disc-------------
因为connectack是在FACCH上发送的,怀疑网络未能收到ack消息,因为发送connect消息后,网络端将启动一个为期30秒的定时器等待MS的确认,出于某种原因,ack消息未能到达网络,此定时器超时,网络进行呼叫释放
6.某次路测中发现手机每当起呼占用(BCCH:
554,BSIC:
52,LAC:
9488,CI:
29403),其只能一直切换到DCS1800网,通话过程中无法测量到GSM900的频点,一直不能向GSM900网切换,在测试时不单该小区自己本身不能测量到GSM900的频点,在本次通话过程中的所涉及的所有小区都不能测量到GSM900的频点,导致在该路段出现弱信号和质差最后导致掉话(虽然在CDD中该小区的MBCCHNO中有GSM900的频点);
但如果测试时,起呼占用的不是本小区,而是由起它小区起呼,再切换到该小区,则在该小区仍然能测量到GSM900的频点。
切换正常;说明问题出在该小区。
经仔细检查路测试数据的第三层信息,发现在该小区起呼时,第三层信息没有出现UL-CLASSMARKCHANGE这条信令且在该小区的SYSTEMINFORMATIONTYPE3中发现EARLYSENDING:
EXPLICITYFORBIDDEN,导致系统认为手机为1800单频手机;经检查BSC数据,发现该小区的ECSC参数设为NO,其它小区该参数设为YES。
通过调整该参数,问题得到解决。
7.对于L3的信令问题,本人认为重要的不是信令本身而是应该了解这个信令是说明了什么东西.所以最重要的还是需要大家在工作过程中学习呼叫流程以及GPRS等数据业务的信令过程,然后才能够更加准确的分析问题,而不是简单的去认识几个缩写是什么英语单词这么简单.
8.
常见Disconnect/ReleaseCauseValue:
CauseValue
Reason
31
BSSorMSCproblem
34(beforeAssignmentCommand)
TCHBlocking
34(afterAssignmentComplete)
MSCBlocking
41(afterAssignmentCommand)
BSSproblem,especiallyDRIproblem
41(afterAssignmentComplete)
MSCproblem
42
MSCCongestion
44
BSSproblem,especiallytheCICblocking
111
BSSorMSCproblem
9.MS1UplinkChannelRequest
MS1DownlinkImmediateAssignment
MS1UplinkCMServiceRequest
MS1DownlinkCMServiceAcceptSDCCH分配成功
MS1UplinkSetup
MS1DownlinkCallProceeding
MS1DownlinkAssignmentCommand
MS1UplinkAssignmentCompleteTCH分配成功
MS2UplinkChannelRequest
MS2DownlinkImmediateAssignment
MS2UplinkPagingResponseSDCCH分配成功
MS2DownlinkSetup
MS2UplinkCallConfirmed
MS2DownlinkAssignmentCommand
MS2UplinkAssignmentCompleteTCH分配成功
MS2UplinkAlerting
MS1DownlinkAlerting
MS2UplinkConnect
MS2DownlinkConnectAcknowledge
MS1DownlinkConnect
MS1UplinkConnectAcknowledge
MS1UplinkDisconnect
MS1DownlinkRelease
MS1UplinkReleaseComplete
MS2DownlinkDisconnect
MS2UplinkRelease
MS1DownlinkChannelRelease
MS2DownlinkReleaseComplete
MS2DownlinkChannelRelease
MS1&MS2的流程
10.在LAC39280下的BSC126进行针对寻呼的测试,该BSC挂接在华为软交换下,测试中发现下列两次异常情况。
两次呼叫情况相同,在被叫响应寻呼后,一直到connect都正常进行,可是接下来没有ACKnowledge而直接Disconnect。
其中拆链原因为:
Switchingequipmentconqestion(交换设备拥塞),具体情况如下所示:
时间:
12:
28:
46.25
问题描述:
Disconnect提示交换设备拥塞
问题分析:
如下图所示,在12:
28:
39.62MS1占用小区40361(六团砖场-1)的信号呼叫MS2,此时MS2占用小区40363(六团砖场-3)的信号,此时MS1接收电平较高,而MS2接收电平较差,只有-92dbm,呼叫未正常拆链。
下面从信令流程来看,如下图所示,MS2在收到寻呼消息后,立即申请信道,接着下行发送ImmediateAssigment,MS2上行寻呼相应pagingresponse.一直到上行发送Connect都很正常,然而在MS2发送connect后没有ACKnowledge直接Disconnect,而Disconnect的原因是Switchingequipmentconqestion(交换设备拥塞)
被叫MS2信令流程如下图所示:
主叫MS1信令流程如下图所示:
MS1在完成AssignmentComplete之后Alerting接着紧跟着一个切换,然后下行Channelrelease。
Channelrelease为正常事件。
2.时间:
17:
15:
04.61
问题描述:
Disconnect提示交换设备拥塞
问题分析:
如下图所示,MS1占用小区40133的信号呼叫MS2,MS2占用小区40022的信号,接收电平及话音质量良好,呼叫未正常拆链。
11.
一次完整的主叫流程(含切换)
IDLE:
DL:
SYSTEMINFORMATIONTYPE1:
包括小区信道描述和RACH控制参数
DL:
SYSTEMINFORMATIONTYPE2(2bis,2ter):
邻小区BCCH频点描述,RACH控制信道,允许的PLMN(扩展邻小区BCCH频点描述+RACH控制信道;扩展邻小区BCCH频点描述2)
DL:
SYSTEMINFORMATIONTYPE3:
CI,LAI,控制信道描述,小区选择,小区选择参数,RACH控制参数
DL:
SYSTEMINFORMATIONTYPE4:
LAI,小区选择参数,RACH控制参数,CBCH信道描述,CBCH移动配置
DL:
SYSTEMINFORMATIONTYPE7:
小区重选参数
DL:
SYSTEMINFORMATIONTYPE8:
小区重选参数
UL:
Channelrequest
DL:
Immediateassignment(SDCCH)
试呼:
UL:
CMservicerequest(如果后面直接收到SystemInformationType1,则视为起呼失败)
DL:
CMserviceRequest
DL:
CMserviceaccept
DL:
AUTHENTICATIONREQUEST
UL:
AUTHENTICATIONRESPONSE
DL:
CIPHERMODECOMMAND
UL:
CIPHERMODECOMPLETE
DL:
TMSIREALLOCATIONCOMMAND
UL:
TMSIREALLOCATIONCOMPLETE
UL:
SETUP
DL:
CALLPROCEEDING
DL:
ASSIGNMENTCOMMAND
UL:
ASSIGNMENTCOMPLETE(TCH)
DL:
ALERTING
成功起呼:
DL:
CONNECT(呼叫成功的标志,)
UL:
CONNECTACKNOWLEDGE
DL:
SYSTEMINFORMATIONTYPE5(5bis,5ter):
邻近小区BCCH频点描述(扩展邻近小区BCCH频点描述)
DL:
SYSTEMINFORMATIONTYPE6:
CI,LAI,小区参数设置
UL:
MEASUREMENTREPORT
DL:
HandoverCommand
DL:
PhysicalInformation
UL:
HandoverComplete(切换成功的标志)
DL:
PhysicalInformation
DL:
SYSTEMINFORMATIONTYPE6
UL:
MEASUREMENTREPORT
DL:
Disconnect(收到该条消息或Release中的任何一条,则视为正常释放,如果两条消息均未收到,而是直接收到SystemInformationType1,则视为一次掉话)
UL:
Release
DL:
ReleaseComplete
DL:
ChannelRelease
UL:
ReleaseComplete
12.某地优化工程中发现SPC=255-5-253到SPC=255-5-248无法切换的问题,从信令流程可以看到MSC(SPC=255-5-253)发送UDT格式的MAP_PREPARE_HANDOVER消息后,SCCP_RETURN_CAUSE=notranslationforanaddressofsuchnature(0)
信令流程可以看到MSC(SPC=255-5-253)发送UDT格式的MAP_PREPARE_HANDOVER消息后,直接以UDTS格式的同一消息作为应答,并且SCCP层的弹回原因如下:
SCCP_RETURN_CAUSE=notranslationforanaddressofsuchnature(0)
说明该消息在对端交换机(SPC=255-5-248)的SCCP分析过程中存在一定的问题,即对端交换机无法做正确的GT翻译。
可以看到被叫号码的格式为13090953,而SPC=255-5-248相关的GT数据只定义了格式为8613090953,而没有定义不加86的数据。
由此可以看出该问题的根本原因还是数据原因导致的
令跟踪数据分析:
通过对BSC05PCM45/46/47/48下16时隙的所有呼叫进行分析发现:
BSC收到AssignmentRequest20至30ms后向MSC回送AssignmentFailure,
问题处理结果:
检查BSC05、MSCA接口电路配置发现:
BSC05和BSC53的A接口电路中,16时隙除了用作信令链路外都不进行配置,而在MSC侧将新增加的8条电路的16时隙配置的TCH信道,导致在MSC指配到16时隙而BSC侧并不识别产生分配失败。
在MSC侧将新增加的8条电路的16时隙锁定后,问题解决。
14.
抛砖引玉!
例:
MS呼叫未接通:
在做DT测试过程中发生了一次未接通,地点是LAC区交接处,在DT测试的行程中,可能发生数次跨LAC区的切换,极易发生掉话或未接通情况。
主要有以下三条信令消息:
UL:
CHANNELREQUEST
DL:
IMMEDIATEASSIGNMENT
UL:
CMSERVICEREQUEST
在上行的CMSERVICEREQUEST信令发出后,没有下行的响应,通话状态由起呼直接转为空闲模式(IDLE),由此可以断定发生了一次未接通。
由于上行UL:
CMSERVICEREQUEST是MS发起的对SDCCH的申请,发出申请后没有应答,没有出现标志呼叫接通的信令消息,可以断定发生了一次未接通情况。
其原因可能为该服务小区的SDCCH信道拥塞,也可能是由于无线环境的恶化造成SDCCH信令丢失。
因为此次DT测试发生在跨数个LAC的路段,而且是上一个通话刚刚结束,起初判断可能是发生了一次位置更新。
15.位置更新信令消息:
DL:
CHANNELRELEASE
UL:
CHANNELREQUEST(开始位置更新)
DL:
IMMEDIATEASSIGNMENT
UL:
LOCATIONUPDATINGREQUEST
DL:
AUTHENTICATIONREQUEST
UL:
AUTHENTICATIONRESPONSE
DL:
LOCATIONUPDATINGACCEPT
UL:
TMSIREALLOCATIONCOMPLETE
DL:
CHANNELRELEASE
结合此例的第三层信令消息来看,例子中MS发出了UL:
CMSERVICEREQUEST,并不是UL:
LOCATIONUPDATINGREQUEST,由此可以判断出此例并非是位置更新。
由于字节限制,只能简单点。
某次测试中发现DT测试路段有无覆盖地段,导致MS数据吞吐量变为0,没有与GPRS网络的连接,
但是该路段做GSM网络DT测试时并没有发现有无覆盖地段,
经过分析,其原因可能是MS执行了一次跨路由区的小区重选
(在显示图的信令部分可以明显的看出该MS正在做位置更新)。
跟踪当前信令为:
DL:
SYSTEMINFORMATIONTYPE1
UL:
LOCATIONUPDATINGREQUEST
UL:
CHANNELREQUEST
一次正常的LAR&RAU信令流程如下:
Direction
Type
Layer3Message
UL
RR
ChannelRequest
DL
RR
ImmediateAssignment
UL
MM
LocationUpdatingRequest
UL
RR
ClassmarkChange
UL
RR
GPRSSuspensionRequest
DL
MM
AuthenticationRequest
UL
MM
AuthenticationResponse
DL
MM
IdentityRequest
UL
MM
IdentityRespone
DL
MM
LocationUpdatingaccept
UL
MM
TMSIRealocationComplete
DL
RR
ChannelRelease
UL
GPRSMM
RoutingAreaUpdateRequest
UL
RR
ChannelRequest
DL
RR
ImmediateAssignment
DL
GPRSMM
RoutingAreaUpdateAccept
UL
GPRSMM
RoutingAreaUpdateComplete
17.在DTFTP下载测试中,MS已成功登陆FTPServer,并已经开始下载数据,FTP下载进度为9%,在经过一次小区重选后,发现在事件列表中有PDPDeactivated的消息,在层三消息中可以看到是手机发起的上行消息,之后的FTP下载不能继续进行,在一系列的Pingfail后,FTP掉线。
层三信令显示如下:
DirectionTypeLayer3Message
ULGPRSSMDeactivatePDPContextRequest
DLRRSystemInformationType13
ULRRChannelRequest
DLRRImmediateAssignment
DLGPRSSMDeactivatePDPContextAccept
发生这种情况可能有3种原因:
一是手机在测试过程中电缆的某个接口发生了松动,这样手机可能会发出PDP去激活申请。
二是手机本身存在一些问题也可能导致这个问题。
三是测试用的笔记本电脑可能存在一些问题
18.第三层信息(GSMLayer3)
|-zUz-~*@$J_3G网络优化|GSM网络优化|网络规划|CDMA网络优化|通信资料|通信论坛|资料下载|移动通信技术|3GSM|WCDMA|TD-SCDMA|UMTS|GSM|移动
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 路测信令 讲解