TD-SCDMA信令分析指导手册_第1页
TD-SCDMA信令分析指导手册_第2页
TD-SCDMA信令分析指导手册_第3页
TD-SCDMA信令分析指导手册_第4页
TD-SCDMA信令分析指导手册_第5页
已阅读5页,还剩62页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

信令分析优化手册TDSCDMA网络质量提升项目内容包括接入/切换/掉话信令的详细解译及异常信令优化措施汇总,信令中包含的各类算法的讲解及运用,网络中的潜在问题的挖掘及协议不完善之处。20110110目录1接入类信令411电路域正常接入信令4111信令流程图4112信令解译612电路域异常接入信令8121RRC建立失败8122鉴权加密失败10123RAB指配失败1113分组域正常接入信令13131信令流程图13131信令解译1414分组域异常接入信令15141RRC建立失败15142鉴权加密失败17143RAB指配失败182切换类信令2621正常切换信令26211RNC内切换26212RNC间切换28213系统间切换3022异常切换信令37221RNC内切换37222RNC间切换39223系统间切换413释放类信令4631正常释放信令46311电路域释放过程46312分组域释放过程4632异常释放信令48321电路域掉话48322分组域掉线514信令算法应用6241切换小区换算62411测量报告62412物理信道重配置63413异系统切换目标小区6342资源分配换算645信令深入挖掘6551并发业务6552协议问题6553频繁失步6654注册失败671接入类信令11电路域正常接入信令111信令流程图主叫被叫主叫被叫112信令解译RRCCONNECTIONREQUEST(上行)UE上行发送一个RRCCONNECTIONREQUEST消息,请求建立一条RRC连接。RADIOLINKSETUPREQUESTRNC向NOTEB请求建立无线链路。RADIOLINKSETUPRESPONSENOTEB响应RNC,建立无线链路。RRCCONNECTIONSETUP(下行)RNC在下行CCCH上向UE发送RRCCONNECTIONSETUP消息。主要参数UEIE,RBIE,TRCHIE,上行传输信道,下行传输信道,物理信道IE,UL无线资源和DL无线资源。RADIOLINKRESTOREINDICATIONNOTEB检测到UE的同步信息,返回给RNC。RRCCONNECTIONSETUPCOMPLETE(上行)UE完成同步后,上发至RNC,标志RRC的建立成功。MEASUREMENTCONTROL(下行)RNC向UE发生1G、2A的测量报告。INITIALDIRECTTRANSFER(CMSERVICEREQUEST)(上行)RRC连接建立后,UE通过RRC连接向RNC发送初始直传消息(INITIALDIRECTTRANSFER),消息中携带UE发送到CN的NAS信息内容。INITIALUEMESSAGERNC把消息发至CN。AUTHENTICATIONREQUEST(下行)此消息为CN发起的鉴权请求消息,可选。如果CN侧鉴权打开,一般收到UE发起的INITIALDIRECTTRANSFER后,就发起鉴权请求。AUTHENTICATIONRESPONS(上行)此消息是UE对CN发起的AUTHENTICATIONREQUEST的响应。COMMONDIDCN把IMSI消息发给RNCSECURITYMODECOMMAND(下行)CN向UTRAN发送此消息而启动本过程,这个消息将规定加密算法(如果有的话)和用于UTRAN的完整性保护算法,也要通知RNCIK和CK,并且指出秘钥的状态新或旧。SECURITYMODECOMPLETE(上行)此步驟根据RNC下发的加密算法和参数计算出相关数据后把数据返回RNC。IDENTITYREQUEST(下行)这是CN向UE发送,用于身份请求认证的IDENTITYRESPONSE(上行)UE向CN发送,响应身份认证。SETUP上行当UE发起一个呼叫的时候,UE的应用层(MMIMANMACHINEINTERFACE,人机界面)将首先发起一个呼叫建立的请求。如果是发起一个普通呼叫,CC实体将首先向网络发送一条SETUP消息。CALLPROCEEDING(下行)CALLPROCEEDING消息表示网络已经收到了UE发出的建立呼叫所需的全部信息,并且正在处理这些信息。RABASSIGNMENGTREQUESTCN请求RNC为UE建立业务信道。RADIOLINKRECONFIGURATIONPREPARERNC请求NOTB为UE重配无线链路。RADIOLINKRECONFIGURATIONREADYNOTEB告诉RNC已经准备好无线链路的资源RADIOBEARERSETUP(下行)RNC发送给UE使用新的物理信道。RADIOLINKRECONFIGURATIONCOMMITRNC发送给NOTEB开始启动新的配置。RADIOLINKRESTOREINDICATIONNOTEB告诉RNC已完成上行同步。RADIOBEARERSETUPCOMPLETE(上行)UE告诉RNC已使用新的物理信道。ALERTING(下行)ALERTING消息表示被叫方已经开始振铃。CONNECT(下行)CONNECT消息表示被叫方已经接受呼叫,即用户已经摘机。CONNECTACKNOWLEDGE(上行)UE向网络返回一条CONNECTACKNOWLEDGE消息,当网络收到此确认消息以后,就意味着整个MOC建立已经完成,呼叫双方可以进行通信,CC实体进入激活(ACTIVE)状态。标注被叫与主叫稍有区别寻呼RRC原因初始直传PAGINGRESPONSESETUP方向相反CALLCONFIRMED振铃和接听,接听确认的方向相反12电路域异常接入信令121RRC建立失败1211一类情景后台异常信令截图(以时间节点为准)分析优化思路对比正常信令发现,RNC下发RRCCONNECTIONSETUP后,未收到RRCCONNECTIONSETUPCOMPLETE,后台会统计为NOREPLY,思考原因,考虑以下几种情况。最常见的是NOTEB下发RRCCONNECTIONSETUP,但是由于下行无线环境恶劣,UE无法解出信息,导致UE在T300定时器超时后继续上发RRCCONNECTIONSETUPREQUEST,发送N300次后,UE释放资源。对于这类情况应该以优化无线环境为主,包括功率的调整、接入门限调整、干扰的排查等。还有极少情况由于UE与NOTEB未完成上行同步,所以反映到前台就是UE没有发RRCCONNECTIONSETUPCOMPLETE。此类问题有一部分由于终端异常导致,除此之外,NOTEB遇到上行干扰,也会导致NOTEB无法解出UE的消息,应该核查其UPPCH、TS1、TS2时隙的干扰。基站传输闪断问题也会导致这种现象的出现,但是概率极小,一般为RRC一次都无法建立。1212二类场景后台异常信令截图(以时间节点为准)分析优化思路RNC收到UE上发的RRCCONNECTIONSETUPREQUEST,请求NOTEB建立无线链路,之后马上又删除无线链路,并下发RRCCONNECTIONREJECT,这种情况极少出现,为设备出现BUG。1213三类场景后台异常信令截图(以时间节点为准)分析优化思路RNC收到UE上发的RRCCONNECTIONSETUPREQUEST,之后RNC直接判决RRCCONNECTIONREJECT。这种一般是由于基站的码资源或者功率资源不足导致,可以提取BRU利用率来验证。122鉴权加密失败1221一类情景后台异常信令截图(以时间节点为准)分析优化思路RNC向UE发送SECURITYMODECOMMAND,UE未返回任何信令,超时后导致未接通,一般此种情况多数是由于无线环境导致。可能是UE未收到SECURITYMODECOMMAND,导致加密超时,对于这种问题应该考虑是否存在下行干扰或电平值较低,从覆盖及排查干扰着手解决。可能是UE收到SECURITYMODECOMMAND,也上发了SECURITYMODECOMPLETE,但是RNC没有收到,这个可以从UE发射功率查看上行无线环境如何,也可以跟踪其TS1、ST2时隙的ISCP。可能是UE收到SECURITYMODECOMMAND,但是没有上发SECURITYMODECOMPLETE,这种极少发生,为终端异常。1222二类情景后台异常信令截图(以时间节点为准)分析优化思路RNC向UE发送SECURITYMODECOMMAND,UE返回SECURITYMODEFAILURE,因为现网还没有启动加密机制,只是启动数据的完整性保护,但是终端不支持完整性保护算法的时候会上报SECURITYMODEFAILURE。123RAB指配失败1231一类情景后台异常信令截图(以时间节点为准)分析优化思路RNC发出RADIOBEARERSETUP命令,没有收到UE上行的RADIOBEARERSETUPCOMPLETE,超时后触发RAB建立超时,造成未接通。对于这种首先应该考虑无线原因,可能是下行无线环境恶劣,导致UE没有收到RADIOBEARERSETUP,此信令RRC层是不重发的,所以UE不会回应RNC,造成RAB建立超时。对于这种情况首先应该排查干扰及弱覆盖的问题,其次应该考虑小区分配的载频存在故障,这样也会造成RRC建立成功,RB建立失败。对于UE收到RNC发出RADIOBEARERSETUP命令,但是由于上行干扰,导致RNC没有收到UE上行的RADIOBEARERSETUPCOMPLETE,导致超时。对于这种情况,可以核查小区的UPPCH、TS1、TS2时隙的ISCP是否正常。1232二类情景后台异常信令截图(以时间节点为准)分析优化思路RNC发出RADIOBEARERSETUP命令,收到UE上行的RADIOBEARERSETUPFAILURE,造成未接通。目前现网中存在最多的RAB指配失败的情况,实质原因在于用户拨打后进行挂机操作,由于3GPP协议对此没有具体的规定,导致高层释放,底层却连接,上下层协议冲突,导致RAB建立失败,返回无效配置。1233三类情景后台异常信令截图(以时间节点为准)分析优化思路RNC向NOTEB发送无线链路重配置准备的命令,NOTEB返回无线链路重配置失败,这种问题是主要是NOTEB存在故障或者告警,导致无线链路建立失败,继而RNC向CN发送RAB指配失败。13分组域正常接入信令131信令流程图131信令解译RRCCONNECTIONREQUEST(上行)UE上行发送一个RRCCONNECTIONREQUEST消息,请求建立一条RRC连接。RADIOLINKSETUPREQUESTRNC向NOTEB请求建立无线链路。RADIOLINKSETUPRESPONSENOTEB响应RNC,建立无线链路。RRCCONNECTIONSETUP(下行)RNC在下行CCCH上向UE发送RRCCONNECTIONSETUP消息。主要参数UEIE,RBIE,TRCHIE,上行传输信道,下行传输信道,物理信道IE,UL无线资源和DL无线资源。RADIOLINKRESTOREINDICATIONNOTEB检测到UE的同步信息,返回给RNC。RRCCONNECTIONSETUPCOMPLETE(上行)UE完成同步后,上发至RNC,标志RRC的建立成功。MEASUREMENTCONTROL(下行)RNC向UE发生1G、2A的测量报告。INITIALDIRECTTRANSFER(GMMSERVICEREQUEST)(上行)RRC连接建立后,UE通过RRC连接向RNC发送初始直传消息(INITIALDIRECTTRANSFER),消息中携带UE发送到CN的NAS信息内容。INITIALUEMESSAGERNC把消息发至CN。AUTHENTICATIONANDCIPHERINGREQUEST(下行)此消息为CN发起的鉴权请求消息,可选。如果CN侧鉴权打开,一般收到UE发起的INITIALDIRECTTRANSFER后,就发起鉴权请求。AUTHENTICATIONANDCIPHERINGRESPONSE(上行)此消息是UE对CN发起的鉴权的响应。COMMONDIDCN把IMSI消息发给RNCSECURITYMODECOMMAND(下行)CN向UTRAN发送此消息而启动本过程,这个消息将规定加密算法(如果有的话)和用于UTRAN的完整性保护算法,也要通知RNCIK和CK,并且指出秘钥的状态新或旧。SECURITYMODECOMPLETE(上行)此步驟根据RNC下发的加密算法和参数计算出相关数据后把数据返回RNC。DEACTIVATEPDPCONTEXTREQUEST上行UE的SM实体向网络发送一条DEACTIVATEPDPCONTEXTREQUEST消息而触发该过程,消息中包含了TI、原因值以及拆卸指示(TEARDOWNINDICATOR)等参数,拆卸指示参数用来描述UE发起的PDP上下文去激活所针对的对象,即过程是针对该消息中TI值所对应的那个PDP上下文,还是和该PDP上下文使用相同PDP地址的所有PDP上下文。RABASSIGNMENGTREQUESTCN请求RNC为UE建立业务信道。RADIOLINKRECONFIGURATIONPREPARERNC请求NOTB为UE重配无线链路。RADIOLINKRECONFIGURATIONREADYNOTEB告诉RNC已经准备好无线链路的资源RADIOBEARERSETUP(下行)RNC发送给UE使用新的物理信道。RADIOLINKRECONFIGURATIONCOMMITRNC发送给NOTEB开始启动新的配置。RADIOLINKRESTOREINDICATIONNOTEB告诉RNC已完成上行同步。RADIOBEARERSETUPCOMPLETE(上行)UE告诉RNC已使用新的物理信道。DEACTIVATEPDPCONTEXTACCEPT(下行)当UE收到来自网络的DEACTIVATEPDPCONTEXTACCEPT消息后,表示网络已接受了UE的请求,PDP上下文去激活成功,相关的NSAPI和TI值被释放,并且可以被重新分配给其他的PDP上下文。SM将进入非激活状态。14分组域异常接入信令141RRC建立失败1411一类情景后台异常信令截图(以时间节点为准)分析优化思路对比正常信令发现,RNC下发RRCCONNECTIONSETUP后,未收到RRCCONNECTIONSETUPCOMPLETE,后台会统计为NOREPLY,思考原因,考虑以下几种情况。最常见的是NOTEB下发RRCCONNECTIONSETUP,但是由于下行无线环境恶劣,UE无法解出信息,导致UE在T300定时器超时后继续上发RRCCONNECTIONSETUPREQUEST,发送N300次后,UE释放资源。对于这类情况应该以优化无线环境为主,包括功率的调整、接入门限调整、干扰的排查等。还有极少情况由于UE与NOTEB未完成上行同步,所以反映到前台就是UE没有发RRCCONNECTIONSETUPCOMPLETE。此类问题有一部分由于终端异常导致,除此之外,NOTEB遇到上行干扰,也会导致NOTEB无法解出UE的消息,应该核查其UPPCH、TS1、TS2时隙的干扰。基站传输闪断问题也会导致这种现象的出现,但是概率极小,一般为RRC一次都无法建立。1412二类场景后台异常信令截图(以时间节点为准)分析优化思路RNC收到UE上发的RRCCONNECTIONSETUPREQUEST,请求NOTEB建立无线链路,之后马上又删除无线链路,并下发RRCCONNECTIONREJECT,这种情况极少出现,为设备出现BUG。1413三类场景后台异常信令截图(以时间节点为准)分析优化思路RNC收到UE上发的RRCCONNECTIONSETUPREQUEST,之后RNC直接判决RRCCONNECTIONREJECT。这种一般是由于基站的码资源或者功率资源不足导致,可以提取BRU利用率来验证。1414四类场景(用切换时的RLSETUP代替)后台异常信令截图(以时间节点为准)分析优化思路RNC请求NOTEB建立无线链路,NOTEB返回无线链路建立失败,原因为HARDWARE_FAILURE。遇到这种问题一般都是小区的硬件板卡出现故障,通过核查告警来确定问题,可以尝试重启基站,如果没有效果就需要更换相应的硬件设备。142鉴权加密失败1421一类情景后台异常信令截图(以时间节点为准)分析优化思路RNC向UE发送SECURITYMODECOMMAND,UE未返回任何信令,超时后导致未接通,一般此种情况多数是由于无线环境导致。可能是UE未收到SECURITYMODECOMMAND,导致加密超时,对于这种问题应该考虑是否存在下行干扰或电平值较低,从覆盖及排查干扰着手解决。可能是UE收到SECURITYMODECOMMAND,也上发了SECURITYMODECOMPLETE,但是RNC没有收到,这个可以从UE发射功率查看上行无线环境如何,也可以跟踪其TS1、ST2时隙的ISCP。可能是UE收到SECURITYMODECOMMAND,但是没有上发SECURITYMODECOMPLETE,这种极少发生,为终端异常。1422二类情景后台异常信令截图(以时间节点为准)分析优化思路RNC向UE发送SECURITYMODECOMMAND,UE返回SECURITYMODEFAILURE,因为现网还没有启动加密机制,只是启动数据的完整性保护,但是终端不支持完整性保护算法的时候会上报SECURITYMODEFAILURE。143RAB指配失败1431一类情景后台异常信令截图(以时间节点为准)分析优化思路RNC发出RADIOBEARERSETUP命令,没有收到UE上行的RADIOBEARERSETUPCOMPLETE,超时后触发RAB建立超时,造成未接通。对于这种首先应该考虑无线原因,可能是下行无线环境恶劣,导致UE没有收到RADIOBEARERSETUP,此信令RRC层是不重发的,所以UE不会回应RNC,造成RAB建立超时。对于这种情况首先应该排查干扰及弱覆盖的问题,其次应该考虑小区分配的载频存在故障,这样也会造成RRC建立成功,RB建立失败。对于UE收到RNC发出RADIOBEARERSETUP命令,但是由于上行干扰,导致RNC没有收到UE上行的RADIOBEARERSETUPCOMPLETE,导致超时。对于这种情况,可以核查小区的UPPCH、TS1、TS2时隙的ISCP是否正常。1432二类情景后台异常信令截图(以时间节点为准)分析优化思路RNC发出RADIOBEARERSETUP命令,收到UE上行的RADIOBEARERSETUPFAILURE,造成未接通。目前现网中存在最多的RAB指配失败的情况,实质原因在于用户进行上网后进行挂机操作,由于3GPP协议对此没有具体的规定,导致高层释放,底层却连接,上下层协议冲突,导致RAB建立失败,返回无效配置。1433三类情景后台异常信令截图(以时间节点为准)分析优化思路RNC向NOTEB发送无线链路重配置准备的命令,NOTEB返回无线链路重配置失败,这种问题是主要是NOTEB存在故障或者告警,导致无线链路建立失败,继而RNC向CN发送RAB指配失败。1434四类情景后台异常信令截图(以时间节点为准)分析优化思路CN向RNC发送RAB建立请求,但是由于码资源或者功率资源不足,RNC向CN返回RAN指派失败,可以从原因只看出为物力资源不足导致,后续出现PDP连接被拒绝。对于以上情况,可以查看小区的告警情况,通过LMT核查其BRU利用率来判断是否存在拥塞的现象。RRC建立TOP小区依托于信令分析案例南屏T31话统数据分析近期KPI走势开始时间服务小区名称电路域RRC建立尝试次数(业务相关)次电路域RRC建立失败次数(业务相关)次电路域RRC建立成功率分组域RRC建立尝试次数(业务相关)次分组域RRC建立失败次数(业务相关)次分组域RRC建立成功率20101101南屏T328312957628111960920101102南屏T33331695202865982520101103南屏T32721295592835982320101104南屏T333113960732710969420101105南屏T33421894742606976920101106南屏T32531693683167977820101107南屏T32341394442945983020101108南屏T32866979034710971220101109南屏T33519714854952920101110南屏T326116938742813969620101111南屏T33191994043663991820101112南屏T333516952228016942920101113南屏T3310239258456131712720101114南屏T3343997384094990220101115南屏T330724921840655864520101116南屏T336017952834779798观察南屏T3半月的走势,其电路域及分组域的RRC建立成功率均较差,其中11月9日的RRC请求次数较少。失败原因统计可以看到此小区RRC建立失败的原因基本为NOREPLY,即RNC发出RRCCONNECTIONSETUP后,UE无响应造成,具体原因需要查看RNC侧信令。电平值分布RRC建立超时电平值分布开始时间服务小区名称RSCP95DBM次95DBMRSCP90DBM次90DBMRSCP85DBM次85DBMRSCP80DBM次80DBMRSCP75DBM次75DBMRSCP70DBM次2010111南屏T32466322010112南屏T30637052010113南屏T33444202010114南屏T32763212010115南屏T33651442010116南屏T33863302010117南屏T31524312010118南屏T32316222010119南屏T372735020101110南屏T3410526120101111南屏T328532120101112南屏T3210753420101113南屏T37661263320101114南屏T322610220101115南屏T36994553通过查看发现,各个电平值的失败比例与尝试次数比例一致,可以排查由于弱覆盖导致的大量RRC建立失败。2后台信令分析第一类,UE收到了RRCCONNECTIONSETUP,但是未与基站建立上行同步导致未发出RRCCONNECTIONSETUPCOMPLETE,这种情况占了绝大部分。第二类,UE收到了RRCCONNECTIONSETUP,并与基站建立上行同步导致,但是RNC没有收到RRCCONNECTIONSETUPCOMPLETE,这种情况占了一小部分。第三类,UE收到了RRCCONNECTIONSETUP,并与基站建立上行同步导致,但是下行未同步导致上发RRCCONNECTIONRELEASECOMPLETE,这种情况占了极小部分,属于UE异常。综述通过查看后台信令基本定位问题,排查了主频点干扰原因。3物理位置分析由物理位置可以看到不存严重同频干扰的情况,综合分析可以判断并非下行无线环境恶劣导致UE无法收到RRCCONNECTIONSETUP所引起,可以把范围缩小至上行无线环境及基站问题,经核查发现上行的ISCP值正常。4优化实施方案针对南屏T3小区RRC建立成功率较低的问题,拟优化方案如下A调整南屏T3主频点10120为10080。B调整其软接纳初始功率修正值下行为3DB,即由0DB改为3DB。C调整其软接纳初始功率修正值上行为5DB,即由5DB改为10DB。D重启基站。5优化成果开始时间服务小区名称电路域RRC建立尝试次数(业务相关)次电路域RRC建立失败(业务相关)次电路域RRC建立成功率分组域RRC建立尝试次数(业务相关)次分组域RRC建立失败次数(业务相关)次分组域RRC建立成功率20101125南屏T329715949527514949120101126南屏T336112966827619931220101127南屏T3343129654801297520101128南屏T3233398733616983720101129南屏T3265398882703989020101130南屏T329419966234398732010/12/1南屏T3349010000321299382010/12/2南屏T3302199673290100002010/12/3南屏T331919969462299572010/12/4南屏T3371199736430100002010/12/5南屏T3400199754110100002010/12/6南屏T3366299454290100002010/12/7南屏T3378199745390100002010/12/8南屏T333349880370199732010/12/9南屏T333029939487698772010/12/10南屏T338019974526399432010/12/11南屏T34350100002450799712010/12/12南屏T343129954946199892010/12/13南屏T3441010000768499482010/12/14南屏T3370010000615399512010/12/15南屏T33431997140601000011月28日中午完成参数的修改,可以看到指标对比以前有了较大的提升,证明了优化的效果。2切换类信令21正常切换信令211RNC内切换2111信令流程图前台信令后台信令2112信令解译MEASUREMENTREPORT(上行)UE触发事件条件,发出切换的请求;RADIOLINKSETUPREQUEST(RNCNOTEB)(下行)RNC判决进行切换后向NB发送无线链路增加请求,为目标小区建立无线链路;RADIOLINKSETUPRESPONSE(NOTEBRNC)上行目标小区收到无线链路建立请求后,配置相应链路资源,配置完成后组织无线链路响应消息发往RNC;PHYSICALCHANNELRECONFIGURATION(下行)RNC收到目标小区的响应消息后,为目标小区建立IUB传输承载;并使用源小区的信道向UE发送PHYSICALCHANNELRECONFIGURATION消息,通知UE进行切换;RADIOLINKRSTOREINDICATION(NOTEBRNC)上行UE收到切换命令后,发送突发脉冲,NOTEB检测到上行同步后,向RNC返回;PHYSICALCHANNELRECONFIGURATIONCOMPLETE(下行)UE与目标小区建立同步后,向RNC发送此消息,并开始使用全新的配置。RADIOLINKDELETIONREQUEST(RNCNOTEB)(下行)RNC请求源小区释放链路资源。RADIOLINKDELETIONRESPONSE(NOTEBRNC)上行NOTEB响应RNC的命令,删除链路资源。MEASUREMENTCONTRL(下行)RNC收到物理信道重配置完成后,删除源小区的无线链路和IUB传输承载并向UE发送新的测量信息。212RNC间切换2121信令流程图前台信令后台信令由于跟踪CT是按着RNC去记录,所以可以分为源RNC和目标RNC的。源RNC目标RNC2122信令解译MEASUREMENTREPORT(上行)UE触发事件条件,发出切换的请求;RELOCATIONREQUIRED(SRNCCN)(上行)SRNC判决进行切换(目标小区属于另一个RNC)后向CN发送RELOCATIONREQUIRED;RELOCATIONREQUEST(CNTRNC)(下行)CN在TRNC侧建立SCCP连接,并向TRNC发送RELOCATIONREQUEST;RADIOLINKSETUPREQUEST(RNCNOTEB)(下行)TRNC收到该消息后向目标基站发送无线链路建立请求,为目标小区建立无线链路;RADIOLINKSETUPRESPONSE(NOTEBRNC)(上行)目标小区收到无线链路建立请求后,配置相应链路资源;RELOCATIONREQUESTACKNOWLEGETRNCCN上行TRNC收到目标小区的响应消息后,在目标小区侧分别建立IUB口和IU口的ALCAP传输承载;建完传输承载后,TRNC向CN响应RELOCATIONREQUESTACK,表明目标RNC侧已准备好;RELOCATIONCOMMANDRNCCN(下行)CN向SRNC发送RELOCATIONCOMMAND,指示SRNC开始进行重定位;RADIOBEARERRECONFIGURATION(下行)SRNC通过源小区的信道向UE发送RADIOBEARERRECONFIGURATION消息,通知UE进行切换;RADIOLINKRSTOREINDICATION(NOTEBTRNC)上行UE收到切换命令后,发送突发脉冲,NOTEB检测到上行同步后,向TRNC返回;RADIOBEARERRECONFIGURATIONCOMPLETE(上行)UE与目标小区建立同步后,向TRNC发送此消息,并开始使用全新的配置。RELOCATIONCOMPLETE(TRNCCN)(上行)TRNC收到后发送RELOCATIONCOMPLETE消息给CN,说明目标侧重定位过程已完成;IURELEASECOMMANDCNSRNC(下行)CN向SRNC下发释放IU资源命令。IURELEASECOMPLETE(SRNCCN)(上行)SRNC侧释放IU口资源;RADIOLINKDELETIONREQUEST(RNCNOTEB)(下行)RNC请求源小区释放链路资源。RADIOLINKDELETIONRESPONSE(NOTEBRNC)上行NOTEB响应RNC的命令,删除链路资源。除上述外,目前现网中加入了对终端能力的检验。UECAPABITYENQUIRY(下行)TRNC要求UE上报终端的能力。UECAPABITYENQUIRYINFORMATION(上行)UE按着RNC的要求上报终端能力。UECAPABITYENQUIRYINFORMATIONCONFIRM(下行)RNC对UE上报的终端能力进行确认。213系统间切换系统间的切换,电路域与分组域流程以及模式完成不同,因此分为两个部分,分别讲述。2131信令流程图A电路域前台信令B电路域后台信令由于系统间切换关系到GSM信令,但是GSM无法提取后台信令,所以用示意图表示。电路域TD侧总体示意图UESOURCENDBRNCMEASURMENTCOTRLPOCEDURMEASURMENTCOTRLANDREPOTHANDOVERCISONTGTLGSMRELOCATINREQUIDANPRELOCATINOMADRANP2GMSCTARGETBSC3GMSCRANPRNAPM/EMAP/E/EMAP/ERAEHNDOVERSPONREPAHNDOVERBSBSMAPHNDOVERQUSTACKNOWLEDGAEALSETPRCERRCCONETISETP,CURITYMECNTRL,RABSETUP,TCCRCHANDOVERFMUTRANCOMDINCLUDIGHADVETARGETBSSYNCHROIZATNPROCEDUR,TCWITHARGETBTSSMAPBSMAPHANDOVERTCRRHANDOVERCMPLETBSAPBSAPHANDOVERCMPLETMAP/EM/EMAP/EMAP/ESNDESIGNALRESPONSNDESIGNALREQUTIURELASPROCEDURIELAS、RCCONETIONRELASC分组域前台信令D分组域后台信令总体示意图UERNC2GSNTARGETBS3GSNSGNCOTEXRQUESTCELHANGEORDFOMUTRANROUTINGAREUPDATERQUTGSNHLRNEWMSC/VLROLDMSC/VLRIURELASCOMPLETIANDROUTINGAREUPDATECPTPDCONTEXUPDATEPROCDURE,GPRSLOCATINUPDATEPROCDURE,LOCATINUPDATE,CUEANDBSPACKTEFLOWCNTEXPROCEDURSRNCOTEXRUETSPONSRNDATFORWADCOMANDFPKETSSECURITYFNCTIOANDOMCESROCEDUR,TCWITHARGETBSHANDOVERCISONTGTLGSMEASURMENTCOTRLPOCEDURCANPTPSETPPROCEDRRCNETISETP,CURITYMODECNTROL,RABSETUP,TCGNCOTEXRSPONEGCOTEXACKNOWLEDGFORWADPCKETSPDC无损传输2132信令解译A电路域MEASUREMENTREPORT(上行)UE触发事件条件,发出切换的请求;RELOCATIONREQUIRED(RNCCN)(上行)RNC判决进行切换(目标小区属于另一个MSC)后向CN发送RELOCATIONREQUIRED;PREPAREHANDOVER(3GMSC2GMSC)3GMSC向2GMSC发送切换准备,并等待回应。HANDOVERREQUEST(2GCNBSC)2G的MSC向其BSC发送切换请求,下发建立的业务类型(话音业务)和速率核查是否有可用的资源。HANDOVERREQUESTACKONWLEGE(BSC2GCN)BSC确定自由有相应的资源后,向MSC返回切换相应。PREPAREHANDOVERRESPONSE(2GMSC3GMSC)2G的MSC确定其有可用资源后,向3G的MSC发送已经完成切换的准备工作。RELOCATIONCOMMAND(CNRNC)(下行)3G的MSC下发重定位命令。HANDOVERFROMUTRANCOMMANDGSM(下行)RNC向UE发送切换命令,UE开始从TD切入GSM网络。HANDOVERDETECT(BSCMSC)2G的BSC向2GMSC发送切换的检测。HANDOVERCOMPLETE(UEBSC)UE完成与GSM网络的同步后,向GSM的BSC返回切换完成。HANDOVERCOMPLETE(BSCMSC)BSC向MSC返回已完成切换。SENDENDSIGNALREQUEST(2GMSC3GMSC)2G的MSC向3G的MSC发送切换完成。IURELEASECOMMANDCNSRNC(下行)CN向RNC下发释放IU资源命令。IURELEASECOMPLETE(SRNCCN)(上行)RNC侧释放IU口资源;RADIOLINKDELETIONREQUEST(RNCNOTEB)(下行)RNC请求源小区释放链路资源。RADIOLINKDELETIONRESPONSE(NOTEBRNC)上行NOTEB响应RNC的命令,删除链路资源。SENDENDSIGNALRESPONSE(3GMSC2GMSC)3G的MSC响应2GMSC。B分组域分组的异系统切换不同于电路域,不存在重定位,性质属于重选。MEASUREMENTREPORT(上行)UE触发事件条件,发出切换的请求;CELLCHANGEORDERFROMUTRAN下行RNC通过判决,向UE发送切换命令。ROUTINGAREAUPDATEREQUEST(UEGSM)UE完成重选后,在GSM下上报路由区更新。SGSNCONEXTREQUEST2GSGSN3GSGSN2GSGSN向3GSGSN请求TMSI对应的IMSI等信息。SGSNCONEXTRESPONSE3GSGSN2GSGSN3GSGSN返回2G所需要的信息。SGSNCONEXTACKOWNLEGE(2GSGSN3GSGSN2GSGSN进行信息的确认。FORWARDPACKETS3GSGSN2GSGSN3GSGSN把切换过程中的传输数据发送给2GSGSN,这样就实现了无损传输,但是由于重选需要较长时间,所以给造成了用户面的掉坑。IURELEASECOMMANDCNSRNC(下行)CN向RNC下发释放IU资源命令。IURELEASECOMPLETE(SRNCCN)(上行)RNC侧释放IU口资源;ROUTINGAREAUPDATEACCEPT(GSMUE)GSM核心网接受路由区的更新,路由去更新完成。RADIOLINKDELETIONREQUEST(RNCNOTEB)(下行)RNC请求源小区释放链路资源。RADIOLINKDELETIONRESPONSE(NOTEBRNC)上行NOTEB响应RNC的命令,删除链路资源。22异常切换信令221RNC内切换2211一类情景后台异常信令截图(以时间节点为准)分析优化思路对比正常信令发现,RNC下发PHYSICALCHANNELRECONFIGURATION后,收到PHYSICALCHANNELRECONFIGURATIONFAILURE,后台会统计为PHYSICALCHANNELFAILURE,这类占了最多数,思考原因,考虑以下几种情况。最常见的现象是由于目标小区存在同频干扰,导致UE无法与目标小区建立同步,继而回滚到源小区,并上报物理信道重配置失败,解决这部分一般以排查干扰为主,可以通过LMT查看其上行ISCP,通过测试核查其下行干扰,修改频点或调整天馈来解决。另有由于同频虚高,导致开环功率计算错误,功率过小无法与目标小区建立同步,对于这类可以通过合理设置切换带,优化邻区配置来解决。最后小区的时钟告警、传输告警、通道告警都会引起此类切换失败,可以通过对实时及历史的告警的核查来核实这个问题。2212二类场景后台异常信令截图(以时间节点为准)分析优化思路对比正常信令发现,RNC下发PHYSICALCHANNELRECONFIGURATION后,未收到任何信息,随后由于超时删除目标小区的无线链路,后台会统计为NOREPLY,这类占了较多,思考原因,考虑以下几种情况。首先可能UE没有收到RNC下发的PHYSICALCHANNELRECONFIGURATION,属于下行链路问题,导致后面出现超时,这种情况是由源小区的干扰或者功率不足造成,应该考虑覆盖方面、或者合理设置3A门限让其在信号较弱时切换至GSM小区。其次,UE收到了PHYSICALCHANNELRECONFIGURATION,并返回了物理信道重配置完成或者失败,但是由于上行无线链路环境较差,导致RNC没有收到,从而导致超时,这种一般为同频干扰导致错误的切换关系,以优化切换关系为主。最后小区的时钟告警、传输告警、通道告警都会引起此类切换失败,可以通过对实时及历史的告警的核查来核实这个问题。2213三类场景后台异常信令截图(此异常信令无法找到故用红色字体代替)分析优化思路对比正常信令发现,RNC向NOTEB发送无线链路请求后,NOTEB返回RADIOLINKFAILURE,所以RNC就不在响应UE的切换请求,这属于切换准备失败,不属于考核的范围内,考虑以下情况。该小区存在告警或者故障,导致无法建立无线链路,这种现象极少发现,因此在异常信令中未发现。222RNC间切换2221一类情景后台异常信令截图分析优化思路对比正常信令发现,RNC向CN发送重定位请求后,CN返回RELOCATIONPREPARATIONFAILURE,所以RNC就不在响应UE的切换请求,这属于切换准备失败,不属于考核的范围内,考虑以下情况。目标RNC的小区出现码资源或者功率资源不足,导致CN在请求目标RNC的小区时遭到拒绝,由于现网中用户较少,所以未出现此现象,故用23G重定位替代。目标RNC在请求NOTEB无线链路时,该小区存在告警或者故障,导致无法建立无线链路,返回无线链路建立失败,目标RNC返回CN失败,CN返回给源RNC失败,这种现象极少发现。2222二类情景后台异常信令截图分析优化思路对比正常信令发现,RNC向UE发送无线承载重配置后,UE返回无线承载重配置失败,后台统计为PHYSICALCHANNELFAILURE,考虑以下情况。目标小区存在上行或者下行干扰,系统间属于硬切换,需要进行UPPTS的上行同步,所以UPPCH干扰也会导致切换失败,主要考虑通过天馈调整、频点调整来排除干扰。目标小区存在告警或者故障,如时钟同步类、传输类、功率类都会造成切换失败。2223三类情景后台异常信令截图(由于未发现切换超时,用正常信令替代)分析优化思路对比正常信令发现,RNC向UE发送无线承载重配置后,UE未返回任何消息,超时导致切换失败,考虑以下情况。源小区无线环境较差,UE上报的重配置失败源小区没有收到,主要考虑通过天馈调整、频点调整来排除干扰。源小区或者目标小区存在时钟同步告警,较多的信令出窗,导致无响应超时。2224四类情景后台异常信令截图(由于未发现切换超时,用正常信令替代)分析优化思路UE完成切换间切换后,目标RNC下发UECAPABITYENQUIRY,要求UE上报终端性能,UE未返回任何消息,超时导致手机迁移到空闲,考虑以下情况。目标小区无线环境较差,UE上报的UECAPABITYENQUIRYINFORMATION目标小区没有收到,这方面主要以排查干扰为主。终端不支持性能的上报,导致超时掉话。223系统间切换A电路域2231电路域同步失败后台异常信令截图分析优化思路UE触发异系统切换门限后,上报测量报告,RNC通过重定位后,向UE下发HANDOVERUTRANCOMMANDGSM,UE上报HANDOVERFROMUTRANFAILLURE,这个占了绝大多数,后台统计为PHYSICALCHANNELFAILURE,考虑以下情况。最可能的是GSM小区存在上下行干扰,导致未能与GSM小区完成同步,从而造成切换失败,一般通过调整3A门限、优化邻区及调整CIO解决。终能性能不佳,导致解错GSM信号强度,误切换导致切换失败,对于这种情况一般提高异系统门限,提高切换难度来进行规避。2232电路域重定位失败后台异常信令截图分析优化思路UE触发异系统切换门限后,上报测量报告,RNC向CN发出重定位请求,但是由于目标小区存在拥塞或者故障告警就会造成准备的失败,由于涉及23G切换,此时切换准备失败很可能发生掉话,考虑以下情况。最可能的是GSM小区存在拥塞或者告警,现网一般拥塞情况较多,对于这种问题一般通过调整拥塞小区的个性偏移,提高切换难度,尽量避免准备失败的发生。2233电路域切换超时后台异常信令截图分析优化思路B分组域2234分组域切换超时后台异常信令截图分析优化思路从后台信令可以看出,UE发出切换门限后,上报测量报告,RNC下发切换命令,UE无任何响应,与电路域异系统切换不同,分组域不进行重定位,所以在切换前不进行任何的资源请求,加之分组域占用资源较大,所以很较大可能由于GSM网络拥塞造成切换失败。可能是UE没有收到

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论