分享

华为LTE后台监控(经典,值得收藏)

 任曙光 2016-04-28



1 主要监控内容


话统KPI主要包括以下几大类:接入性指标、保持性指标、移动性指标、业务量指标、产品运行类指标、系统可用性指标和网络资源利用率指标。


通过上述重点话统KPI指标的监测,可以达到:识别突发问题、风险提前预警、话统KPI的稳定与提升,目前LTE系统需要重点关注的话统KPI指标如下表:



2 数据提取方法


2.1 OMC自定义指标


以eNB间切换成功率为例:


1、查看工具栏,点击自定义指标管理,选择功能子集模块eNODEB,选择测量族和测量组(指标所在的测量族请参考文档《中国XX集团要求上报TDD LTE网络指标V2.1.8》),如图1:



图1


2、右击系统内切换出测量,选择添加后出现下图窗口,输入指标名称(注意单位的选择),填写公式后,点击应用



图2


3、在自定义指标管理界面找到定义的指标,右击,选择测量设置,如图3



图3


4、在弹出的窗口,如图4,勾选新对象自动测量,点击应用,结束。



图4


2.2 KPI指标提取


1、点击结果查询,选择新查询,选择对象,如需选取部分站点(点击第一个对象后,按住“Shift”键,再点击最后一个站点,可将这些对象全选),如图5



图5


2、选取需要查询的指标和对应的周期类型,如图6,按需要选择日期范围和时间方式,如图7



图6



图7


3、指标查询结果如图8



图8


3 告警提取


3.1 常见告警分类表




3.2 常见告警处理方法


3.2.1 【网元链接中断】


●告警解释:

网元与OMC网管之间的链接中断,一般来讲,为断电或传输问题


● 对系统的影响

对该网元无法控制


● 告警处理




3.2.2 【29243:小区服务能力下降】


●告警解释

当基站射频资源或基带资源不能满足当前小区的配置规格时,产生此告警


●对系统的影响

告警小区提供给客户可用的无线空口资源会减少。


●告警处理


查看当前RRU型号



查询RRU配置通道:



查询基站当前告警信息:



查询驻波:



查询光模块型号,速率:



3.2.3【19240:小区不可用告警】


●告警解释

当基站检测到小区不能提供业务时,产生此告警。


●对系统的影响

告警小区不能提供业务。


●告警处理



查询小区是否可用:



查看RRU是否有告警:



查询光路是否OK:



查询GPS是否可用:



查看是否有License告警:



3.2.4【29207: 基站控制面传输中断告警】

(注:由于网元断链,网管无法对基站控制)


● 告警解释

当基站所有SCTP链路状态都异常时,产生此告警。


●对系统的影响

基站所有承载S1Interface、X2Interface的SCTP链路(链路个数不少于2条)状态都异常,导致基站所有S1接口、X2接口无法建立成功,小区无法激活,用户无法入网。


●告警处理



3.2.5【26233:BBU IR光接口性能恶化告警】


●告警解释

当BBU的IR端口上的光模块的接收或发送性能恶化时,产生此告警。


●对系统影响

1、光模块的收发性能严重恶化,可能导致IR链路承载的业务质量严重下降,或导致下级射频单元业务中断。

2、光模块的收发性能轻微恶化,可能导致射频单元该IR链路承载的业务质量出现轻微恶化。


●告警处理





查询RRU收发光:



3.2.6 【29201:S1接口故障告警】


●告警解释

当S1AP(S1 Application Protocol)协议层处理错误,或SCTP(Stream Control Transmission Protocol)链路出现异常时,产生此告警。


●对系统影响

基站将主动去激活所有与异常的S1接口相关的小区,并释放此前已经成功接入到这些小区内的所有在网用户。新的用户将无法接入到这些小区。


●可能原因

1. SCTP链路状态异常。

2. SCTP链路未添加。

3 .S1接口配置错误。

4. SCTP链路闭塞。

5. 跟踪区域配置信息未配置 MME连接的基站数到达上限。


●告警处理




查看基站标示是否正确:



查询SCTP对端IP是否正确:



3.2.7【25888: SCTP链路故障告警】


●告警解释

当基站检测到SCTP链路无法承载业务时,产生此告警。


●对系统影响

导致SCTP链路上无法承载信令。


●可能原因

1. SCTP的承载链路故障。

2.和对端设备配置参数不一致。

3.到对端的路由不可达。

4.光纤连接错误。

5.对端设备故障。


●告警处理





检查配置的IPRT是否正确:



3.2.8【26260:系统时钟不可用告警】


●告警解释

当基站使用本地晶振的时间超过其可保持的时限时,产生此告警。


●对系统影响

基站业务处理会出现各种异常,如切换失败、掉话等,严重时基站不能提供业务。


●告警处理





查询GPS情况:



查询GPS问题是否是有单板故障问题引起:




●提示

eNodeB大部分取得时钟为对端(及TD测),现网大部分为GPS,当前时钟状态为不可用时,可判断GPS问题,需上站检查GPS。

●关于License的下发遵守的规则:

TD:



LTE:



3 坏小区(TOP小区)查找和分析处理


每小时对上一个小时的全网整体指标进行提取,如果指标变化波动较大,需提取小区级别指标进行查看,将小区级的掉话率指标和掉话绝对次数按从高到低的顺序进行排序, 确认是全网的整体问题还是TOP小区引起的指标波动,若剔除TOP小区后,指标恢复正常,则是TOP小区问题,优先分析掉话绝对次数多且掉话率高的Top小区;否则是全网性问题,以下是关于TOP小区筛选的方法和主要KPI处理方法流程:


3.1 接入性TOP分析处理


3.1.1 指标定义




3.1.2 指标分析及统计点介绍


RRC连接建立成功率



图1中【A点】


(1)指标L.RRC.ConnReq.Att加1,不统计重发的次数。


Case1:eNB下发RRC_Conn_Setup消息后,在T300定时器超时前,收到相同的UeID发起的RRC_Conn_Req(Setup丢失,UE MAC冲突解决定时器超时后重发RRC_Conn_Req,UeID不变),记为一次重发RRC_Conn_Req消息。


Case2:T300超时后,UE仍未收到RRC_Conn_Setup,UE重新搜网,发起初始接入,UeID是取0~239的随机值或上层下发的TMSI。eNB侧记为新的一次初始接入,L.RRC.ConnReq.Att加1。


Case3:发起Attach后会启动T310定时器。如果UE发出RRC_Conn_Setup_Cmp后,ENB没有收到,UE会在定时器超时后重新发起Attach,ENB侧记为新的一次初始接入;RRC_Conn_Setup_Cmp丢失不会触发重建,发起重建的前提是安全已经激活。


(2)如果RRC Connection Request消息信元Establishment Cause为“emergency”,指标L.RRC.ConnReq.Att.Emc加1。


(3)如果RRC Connection Request消息信元Establishment Cause为“highPriorityAccess”,指标L.RRC.ConnReq.Att.HighPri加1。


(4)如果RRC Connection Request消息信元Establishment Cause为“mt-Access”,指标L.RRC.ConnReq.Att.Mt加1。


(5)如果RRC Connection Request消息信元Establishment Cause为“mo-Singnalling”,指标L.RRC.ConnReq.Att.MoSig加1。


(6)如果RRC Connection Request消息信元Establishment Cause为“mo-Data”,指标L.RRC.ConnReq.Att.MoData加1。


【B点】

当eNodeB下小区接收到UE发送的RRC Connection Request消息并下发RRC Connection Setup消息给UE时,指标L.RRC.ConnSetup加1。


【C点】

当eNodeB收到UE返回的RRC Connection Setup Complete消息时统计相应指标,L.RRC.ConnReq.Succ加1。


RRC Setup Success Rate计算: RRCSetupSuccessRate=(L.RRC.ConnReq.Succ)/(L.RRC.ConnReq.Att)*100%

E-RAB建立成功率




如图2、3中【A点】所示,当eNodeB收到来自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息时统计该指标。如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同时建立多个E-RAB,则相应指标按各个业务的QCI分别进行累加。


【B点】

当MME收到来自eNodeB的E-RAB SETUP RESPONSE或者INITIAL CONTEXT SETUP RESPONSE消息时E-RAB建立成功次数累加。


ERAB Setup Success Rate计算公式:

ErabSetupSuccessRate=(L.E-RAB.SuccEst)/(L.E-RAB.AttEst)*100%


3.1.3 TOP小区分析和处理


处理流程和方法


通过对TOP小区建立失败的原因进行观察,通过对不同的原因做相应的观察,不同失败原因对于相应指标有不同的变化,应对观察指标和优化策略均不同,下表为指标提取的建立失败的不同原因分类和相应说明:



① 小区RRC建立失败次数:


1、□ 资源分配失败而导致RRC连接建立失败的次数,指标ID:1526727083;重点关注top资源是否足够,包括top用户数,传输、PRB等;


2、□ UE无应答而导致RRC连接建立失败的次数,指标ID:1526727084;关注质差、干扰、无线环境等;


3、□ 小区发送RRC Connection Reject消息次数,指标ID:1526728269;关注传输问题、是否拥塞、干扰;


4、□ 因为SRS资源分配失败而导致RRC连接建立失败的次数,指标ID:1526728485;重点关注SRS带宽、配置指示、配置方式、SRS ACK/NACK设置是否合理等;


5、□因为PUCCH资源分配失败而导致RRC连接建立失败的次数,指标ID:1526728486;关注PUCCH信道相关参数设置是否合理,CQI RB数配置是否合理等;


6、□流控导致的RRC Connection Request 消息丢弃次数,指标ID:1526728489;关注拥塞,业务流控相关参数是否设置正确等;


7、□流控导致的发送RRC Connection Reject消息次数,指标ID:1526728490;关注拥塞,业务流控相关参数是否设置正确等;


② 对小区E-RAB建立失败次数:


1、□因未收到UE响应而导致E-RAB建立失败的次数,指标ID:1526726717;处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。


2、□核心网问题导致E-RAB建立失败次数,指标ID:1526728276;处理建议:需跟踪信令,排查核心网问题(EPC参数设置,TAC码设置的一致性,对用户开卡限制,硬件故障方面排查);


3、□传输层问题导致E-RAB建立失败次数,指标ID:1526728277;处理建议:需查询传输是否有故障,高误码,闪断,传输侧参数设置问题。


4、□无线层问题导致E-RAB建立失败次数,指标ID:1526728278;处理建议:处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。


5、□无线资源不足导致E-RAB建立失败次数,指标ID:1526728279;处理建议:1、排查TOP小区资源是否足够,是否故障引起,若存在资源不足问题,可考虑参数调整,流量均衡(小区选择,重选和切换类参数);2、结合现场调整天馈,流量均衡;3、热点区域,增补基站等;


6、□安全模式配置失败导致E-RAB建立失败次数,指标ID:1526728280;处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。


在一般正常情况下建立失败的通常为无线侧问题导致的可以处理,具体常见处理方法和流程如下:


1. 检查操作,告警,传输问题,是否存在网络变动和升级行为等(1.通过LST ALMAF查询站点实时告警,用LST ALMLOG参考历史告警;?存在告警则降低功率切出用户,严重的临时去激活小区,通知维护人员处理;


2.通过DSP BRD 查询单板运行情况;?异常则通知维护人员;


3.传输及EPC侧有网络变动(升级,割接,参数修改等)。?一般为突发,及时同时相关人员;


4.通过Mapinfo查看小区PCI复用是否合理,是否存在模三冲突;?用MOD CELL修改PCI


5.检查小区时隙配比是否设置准确(室分:SA2\SSP7;宏站:SA2\SSP5)?LST CELL查看,MOD CELL修改;


6.如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰,同时可通过后台跟踪,确认干扰类型;?统计话务统计看是突发的还是持续的,可应急通过MOD PDSCH降功率处理;


7.检查传输模式,是否为TM3,如长时间为TM2,确认设置正确的情况下,基本确定小区存在弱覆盖;


8.对比64QAM和QPSK占比,如后者比例远大于前者,可确定小区覆盖异常;


9.邻区告警、故障等导致TOP小区存在弱覆盖;


10.天馈问题,无线环境差;


11.天线权值配置与现场天线参数不一致。


12.核查参考信号功率是否偏低(常规设置92,122,需结合现场设置);?MOD PDSCH进行修改;




3.2 保持性TOP分析处理


3.2.1 指标定义




3.2.2 指标分析及统计点介绍

无线掉线率




如上图:【图1】中A点所示,当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息,会释放UE的所有E-RAB。当释放原因不为“Normal Release”,“Detach”,“User Inactivity”,“CS Fallback triggered”,“UE Not Available for PS Service”,“Inter-RAT Redirection”,“Time Critical Handover”,“Handover Cancelled”时,测量指标L.UECNTX.AbnormRel加1。


如【图2】中A点所示,当eNodeB向MME发送S1 RESET消息时,根据包含的上下文个数,指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。


如【图3】中A点所示,当MME向eNodeB发送S1 RESET消息时,根据包含的上下文个数,指标L.UECNTX.Rel.S1Reset.MME进行累加。

E-RAB掉线率


E-RAB掉线分2部分,为eNodeB触发的释放原因为异常的E-RAB释放总次数和切换出E-RAB异常释放总次数,分别如下:


切换出E-RAB异常释放信令统计点如下图:



上图中,图1表示eNodeB内切换,图2表示X2接口切换,图3表示S1接口切换,图4表示E-UTRAN系统切换到WCDMA系统、GERAN系统、或者TD-SCDMA系统。如图1、图2、图3和图4中C点所示,切换执行成功,但目标小区有建立失败的承载,源小区异常释放对应的E-RAB,则在源小区按各个业务的QCI分别统计该指标。同时,在源小区根据相应E-RAB的个数将总次数累加,即指标L.E-RAB.AbnormRel.HOOut累加。


eNodeB触发的释放原因为异常的E-RAB释放信令统计点如下图:



如图1中A点所示,当eNodeB发出E-RAB RELEASE INDICATION消息,且释放原因不为“Normal Release”,“Detach”,“User Inactivity”,“CS Fallback triggered”,“UE Not Available For PS Service”,“Inter-RAT Redirection”,“Successful Handover”时统计L.E-RAB.AbnormRel.eNBTot指标,当判断相应承载有数传时统计L.E-RAB.AbnormRel指标。如果E-RAB RELEASE INDICATION信令中要求同时释放多个E-RAB,则相应的指标统计多次;


如图2中A点所示,当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息,会释放UE的所有E-RAB。当释放原因不为“Normal Release”,“Detach”,“User Inactivity”,“CS Fallback triggered”,“UE Not Available For PS Service”,“Inter-RAT Redirection”,“Time Critical Handover”,“Handover Cancelled”时统计L.E-RAB.AbnormRel.eNBTot指标,当判断相应承载有数传时统计L.E-RAB.AbnormRel指标。如果被释放用户建立了多个E-RAB,则相应的指标统计多次。并且在MME回复UE CONTEXT RELEASE COMMAND消息时,相应指标不会被重复记录。


3.2.3 TOP小区分析流程


TOP小区分析可通过OMC 920提取异常释放原因:


无线掉线率释放原因如下:

□ eNodeB发起的原因为UE LOST的UE Context释放次数

□ eNodeB发起的原因为切换失败的UE Context释放次数

□ eNodeB发起的原因为无线层问题的UE Context释放次数

□ eNodeB发起的S1 RESET导致的UE Context释放次数


E-RAB掉线率释放原因如下:

□无线层问题导致的激活的E-RAB异常释放次数

□传输层问题导致的激活的E-RAB异常释放次数

□网络拥塞导致的激活的E-RAB异常释放次数

□切换流程失败导致激活的E-RAB异常释放次数

□核心网问题导致E-RAB异常释放次数




1.通过LST ALMAF查询站点实时告警,参考历史告警LST ALMLOG;?存在告警则降低功率切出用户,严重的临时去激活小区,通知维护人员处理;



2.通过DSP BRD 查询单板运行情况; ?若异常,通知维护人员处理;


3.提取两两小区切换,确定目标小区:


A.确定目标小区运行情况,是否基站故障或异常告警;?若异常,通知维护人员处理;

B.检查邻区间参数设置是否正确;?核查修改邻区外部小区参数是否正确,切换偏置是否合理;

C.通过Mapinfo检查小区邻区配置是否合理,进行邻区合理性优化;?进行邻区的合理删除和添加;

D.检查基站是否周边站点缺少,如为孤站,可视为正常;?暂不做处理,观察;


4.检查参数设置是否合理:


A.查询掉线类定时器设置是否正确;(T310、N311、N310、T311、T301).

LST UETIMERCONST:;

B. 如掉线率突增,查询操作日志,确认是否有修改,导致小区异常;?用LST OPTLOG查看是否指标异常开始时段有相应修改操作,询问修改人进行相应恢复观察;


5.检查是否存在干扰:


A.通过Mapinfo查看小区PCI复用是否合理,是否存在模三冲突;?修改PCI

B.检查小区时隙配比是否设置准确(E频段室分:SA2\SSP7; F和D频段宏站:SA2\SSP5);?修改时隙配比配比MOD CELL;

C.如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰,同时可通过后台跟踪,确认干扰类型;?统计话务统计看是突发的还是持续的,可应急通过MOD PDSCH降功率处理;


6.是否存在高质差:


A.通过观察小区上下行丢包率是否正常,如丢包率偏高,基本断定小区存在质差;

B. 通过后台误码率跟踪,如BLER>10%,确定小区存在高误码;


7.是否存在弱覆盖:


A.检查传输模式,是否为TM3,如长时间为TM2,确认设置正确的情况下,基本确定小区存在弱覆盖;

B. 对比64QAM和QPSK占比,如后者比例远大于前者,可确定小区覆盖异常;


8.现场测试及后台跟踪:


A.安排前场人员现场测试,同时后台通过信令跟踪,配合查找问题原因;

B.如果确认问题后,需配合解决,转发相关人员处理,做好跟踪工作,直至问题闭环。



3.3 移动性TOP分析处理


3.3.1 指标定义




3.3.2 指标分析及统计点介绍


统计小区范围内不同原因的切换出失败的次数。切换出失败一般发生在切换准备阶段,包括几种典型场景:核心网问题,目标小区无响应,目标小区回复切换准备失败以及源小区发送切换取消消息。切换准备阶段是从切换判决到切换执行之间的切换资源准备阶段。


● 如图1和图2中B点所示,在S1接口切换及X2接口切换过程中的切换准备阶段,源小区收到来自MME的UE CONTEXT RELEASE COMMAND消息时,指标L.HHO.Prep.FailOut.MME加1。



● 如图3和图4中B点所示,在X2接口切换及S1接口切换过程中的切换准备阶段结束时,源小区未收到来自目标eNodeB的任何消息,包括如下场景:在X2切换时,未收到对端eNodeB发出的HANDOVER REQUEST ACKNOWLEDEG消息及HANDOVER PREPARATION FAILURE消息;在S1接口切换时,未收到MME发出的HANDOVER COMMAND消息及HANDOVER PREPARATION FAILURE消息。指标L.HHO.Prep.FailOut.NoReply加1。



● 如图5和图6中B点所示,在X2接口切换过程中的切换准备阶段,当源小区收到来自目标小区的HANDOVER PREPARATION FAILURE消息时,指标L.HHO.Prep.FailOut.PrepFailure加1。在S1接口切换过程中的切换准备阶段,当源小区收到来自MME的HANDOVER PREPARATION FAILURE消息时,指标L.HHO.Prep.FailOut.PrepFailure加1。



● 如图7和图8中B点所示,在X2接口切换及S1接口切换过程中,切换准备阶段未结束且没有收到来自目标测的任何消息,源小区判决取消本次切换,并发送HANDOVER CANCEL消息时,指标L.HHO.Prep.FailOut.HOCancel加1。如果准备阶段结束,由于其他异常原因,UE未完成切换流程,源小区向目标小区发送HANDOVER CANCEL消息时,不统计到该指标中。如图7和图8中B点所示,在X2接口切换及S1接口切换过程中,源小区发送HANDOVER CANCEL消息时,指标L.HHO.FailOut.HOCancel加1。该指标不考虑切换准备是否完成,只要源小区发送HANDOVER CANCEL消息,指标就统计。



3.3.3 TOP小区分析流程


TOP小区分析可通过OMC 920提取切换出失败原因:

□ 核心网原因导致切换出准备失败次数

□ 目标小区无响应导致切换出准备失败次数

□ 目标小区回复切换准备失败消息导致切换出准备失败次数

□ 源小区发送切换取消导致切换出准备失败次数

□ eNodeB间切换出取消次数



对TOP问题小区常见如下处理:


1. 查询站点有无告警,小区状态是否正常;(1.通过LST ALMAF查询站点实时告警,用LST ALMLOG参考历史告警;?存在告警则降低功率切出用户,严重的临时去激活小区,通知维护人员处理;


2.查询有无外部干扰(每PRB上干扰噪声平均值>-110dBm,则存在外部干扰);?统计话务统计看是突发的还是持续的,可应急通过MOD PDSCH降功率处理;


3.提取两两小区切换,确定切换出目标小区,核查外部小区参数(PCI、TAC、频点、小区标识、切换参数)配置有无错误; ?若错误则对外部定义的小区参数进行修改,另外关注两两小区切换过早和过玩或者乒乓切换统计,进行相应的CIO调整;


4.查看MAPINFO图层,查看邻区是否存在MOD干扰,确认基站规划是否合理,是否会产生弱覆盖。?用MOD CELL修改PCI或者降功率,降功率需注意是否会造成其他地方覆盖差;



4 附录文件


常用指令:


TDL站点状态查询指令:


LST CELL:; 查询小区静态参数

DSP CELL:; 查询小区动态参数

LST ALMAF:; 查询当前告警

LST BFANT:;查询天线配置信息(静态)

DSP BFANT:;查询天线配置信息(动态)

LST PDSCHCFG:;(参考信号功率)

LST CELLPDCCHALGO:;(公共控制信令聚集级别)

LST CELLDLPCPDSCHPA:;(pdsch功率控制PA调整开关)

LST EUTRANINTRAFREQNCELL:; (查询EUTRAN同频邻区关系)

LST EUTRANEXTERNALCELL:; (查询EUTRAN外部小区)

LST GPS:; (查询小区的经纬度)

LST ALMLOG:ALMTP=ALL;()


激活/解闭塞小区:

ACT CELL:LOCALCELLID=1;

ACT CELL:LOCALCELLID=2;

ACT CELL:LOCALCELLID=3;

UBL CELL:LOCALCELLID=1;

UBL CELL:LOCALCELLID=2;

UBL CELL:LOCALCELLID=3;


去激活/闭塞小区:

DEA CELL:LOCALCELLID=1;

DEA CELL:LOCALCELLID=2;

DEA CELL:LOCALCELLID=3;

BLK CELL:LOCALCELLID=1,CELLADMINSTATE=CELL_HIGH_BLOCK;

BLK CELL:LOCALCELLID=2,CELLADMINSTATE=CELL_HIGH_BLOCK;

BLK CELL:LOCALCELLID=3,CELLADMINSTATE=CELL_HIGH_BLOCK;


闭塞/解闭塞RRU

BLK BRD:CN=0,SRN=200,SN=0,BLKTP=IMMEDIATE;

UBL BRD:CN=0,SRN=202,SN=0;


修改RRU通道:

DSP TXBRANCH:;(发射通道硬件最大输出功率、驻波比等,或:DSP VSWR:查询驻波比)

DSP RXBRANCH:;(接收通道状态)

MOD TXBRANCH:CN=0,SRN=202,SN=0,TXNO=1,TXSW=OFF;(关)

MOD TXBRANCH:CN=0,SRN=202,SN=0,TXNO=1,TXSW=ON; (开)

MOD RXBRANCH:CN=0,SRN=202,SN=0,RXNO=1,RXSW=OFF; (关)

MOD RXBRANCH:CN=0,SRN=202,SN=0,RXNO=1,RXSW=ON; (开)


修改基站小区PCI:(注:同时要求修改邻区数据库相应的小区的PCI,不然影响切换)

MOD CELL:LOCALCELLID=3,PHYCELLID=131;

MOD CELL:LOCALCELLID=2,PHYCELLID=132;

MOD CELL:LOCALCELLID=1,PHYCELLID=133;

MOD EUTRANEXTERNALCELL:MCC='460',MNC='08',ENODEBID=10072,CELLID=3,PHYCELLID=131;

MOD EUTRANEXTERNALCELL:MCC='460',MNC='08',ENODEBID=10072,CELLID=2,PHYCELLID=132;

MOD EUTRANEXTERNALCELL:MCC='460',MNC='08',ENODEBID=10072,CELLID=3,PHYCELLID=133;


LTE加天线权值:

LST BFANT:;

DSP BFANT:;

RMV BFANT: DEVICENO=0;

RMV BFANT: DEVICENO=1;

RMV BFANT: DEVICENO=2;

DLD BFANTDB:IP='188.2.31.4',USR='ftpuser',PWD='Changeme_123',SRCF='ODS-090R15NT.xml';

DLD BFANTDB:IP='10.201.127.83',USR='ftpuser',PWD='ftpuser',SRCF='ODS-090R15NT.xml';

ACT BFANTDB:OPMODE=DLDFILE;

ADD BFANT:DEVICENO=0,CONNSRN=60,MODELNO='ODS-09OR15NT',TILT=3,BEAMWIDTH=65,BAND=39;

ADD BFANT:DEVICENO=1,CONNSRN=62,MODELNO='ODS-09OR15NT',TILT=3,BEAMWIDTH=65,BAND=39;

ADD BFANT:DEVICENO=2,CONNSRN=82,MODELNO='ODS-09OR15NT',TILT=3,BEAMWIDTH=65,BAND=39;

LST BFANT:;

DSP BFANT:;


查询BF开关:

LST CELLALGOSWITCH

TM2\3 BF:关

TM2\3\7 BF:开


修改BF算法开关:

修改BF开关为开:

MOD CELLALGOSWITCH:LOCALCELLID=1(小区号),BFALGOSWITCH=BfSwitch-1;

修改BF开关为关:

MOD CELLALGOSWITCH:LOCALCELLID=1(小区号),BFALGOSWITCH=BfSwitch-0;


基站PING核心网SGW操作步骤:

LST DEVIP:;(查询设备IP配置信息)

LST IPRT:;(查询静态路由配置信息)

PING:SN=6,SRCIP='152.204.12.13',DSTIP='152.194.10.10',PKTSIZE=1000,CONTPING=DISABLE,NUM=100,APPTIF=NO;

PING:SN=6,SRCIP='152.204.12.13',DSTIP='152.194.10.10',PKTSIZE=1400,CONTPING=DISABLE,NUM=100,APPTIF=NO;

PING:SN=6,SRCIP='152.204.12.13',DSTIP='152.194.10.10',PKTSIZE=2000,CONTPING=DISABLE,NUM=100,APPTIF=NO;


查站点系统经纬度:

单模: 在TDL基站侧查询 DSP GPS:;

双模: 在TDS基站侧查询 DSP GPS:;


修改小区时隙配比:

MOD CELL->小区双工模式:CELL_TDD(TDD)->红色:上下行子帧配比、特殊子帧配比。


    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 全屏 打印 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多