第一篇：VOLTE优化经验总结
优化经验总结
1.1 日常优化总结
日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2 RLC优先级优化
现象：呼叫建立与切换过程冲突，专载被MME释放。呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3.导致NAS的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。
优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3 QCI 5 PDCP DiscardTimer时长优化
现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：
QCI5 PDCP DiscardTimer由300ms修改为无穷大
优化效果：
VoLTE无线接通率提升明显
1.4 SBC传输协议TCP重传次数优化
背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481invite486invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5 系统间邻区优化
LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：
4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。通过经纬将4G弱信号(RSRP<-110dbm)与2G强信号（RXLOV>-95dbm）在50米范围内拟合，根据拟合度对2G邻区进行补漏工作。
剔除现网已配置的邻区关系，补漏邻区关系对后，eSRVCC切换提升明显，且由于2G邻区不准确导致的异系统重定向大大减少。
1.6 重定向掉话
XX区域掉话最严重属于重定向掉话，在XX基站算法中，以下三种可能发生重定向，重定向释放RRC后，专载同时被拆除，VoLTE业务产生掉话。
1.7 上行PUSCH功控参数优化
背景：xx区域拉网测试发现上行PUSCH发射功率偏高，对现网参数检查发现，xx区域上行期望功率值设置过高。
优化措施： 进行功控相关参数优化，现网配置： p0NominalPUSCH =-75 ；puschPCAdjType=0
优化值： p0NominalPUSCH =-87 ；puschPCAdjType=2
●同等路损情况下，参数修改后，ue发射功率大约下降2~3dB。
●目前终端平均上行发射功率仍高于10db，仍需完善现有功控方式。
修改后，PUSCH TxPower（10dbm以上）占比由40%下降到30%左右。
1.8 RTP丢包率优化
背景：测试发现，XX区域RTP丢包率偏高，个别网格甚至达到2%以上。
原因分析：在无线质量较好的情况下基本无丢包；无线质量较差的情况下上行丢包现象较为严重，PDCP重传时间超时，数据包将被丢弃；
外场测试表明QCI 1 PDCP Discardtimer 配置与RTP丢包率及Jitter有密切关系，QCI 1 PDCP Discardtimer 配置越大，RTP丢包率越低，但Jitter也随之变大。
●MOS值与RTP丢包及Jitter关系都较大，目前正在进行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的对比验证。
1.9 MME专载保存功能（可选）功能描述：在基站发起UE-lost原因值的上下文释放请求时，MME保持专载2s不释放，等待空口重建。
验证情况：已在某MME下成功验证了该功能。当时无线环境较差，UE发起RRC重建失败，通过MME专载QCI1保持功能使得在新发起的业务过程中，RRC重配中建立包括专载QCI1的3条DRB，不会发生掉话。（本次测试中专载保持时长约1.358s）
功能总结：
1）当无线环境较差时，UE发生RRC重建，若RRC重建成功，手机将不会掉话。
2）MME侧也可以在RRC重建失败后，通过MME专载QCI1保持功能使得在新发起的业务过程中，专载QCI1继续保持，也可使得手机不掉话。
3）此功能为爱立信MME非必选功能，建议打开。但是该功能不在集采目录，暂时无法采购。
1.10 专载释放与切换冲突，通话结束未收到专载释放掉话
[问题描述]：在拉网测试过程中，通话挂机后，主叫上报BYE消息，IMS回BYE200消息前后，同时手机发生切换，未收到EPS专载释放请求，1s后软件统计掉话。
[问题分析]：经分析MME log，发现MME未收到PGW下发的delete bearer request消息。当X2切换触发SGW-initiated bearer modification procedure（完整信令是CCR-CCA），如果此时SIP挂机触发PCRF也发RAR给PGW，由于Gx链路时延等原因，使得RAR先于CCA到达PGW，根据协议规定，PGW会继续SGW-initiated bearer modification procedure而reject RAR(result code DIAMETER_OUT_OF_SPACE)。
[优化措施]：当前解决办法：
（1）缩短DRA时延配置。
（2）修改SAPC到DRA链路为主-备模式，保证CCA和RAR走同一路径和到达PGW的先后顺序。
[优化结果]：近期调整后的网格测试，暂时没有发现BYE200消息前后发生的切换没释放QCI 1专载的情况。
1.11 通话结束MME收到del bearer req，专载释放与切换冲突，基站未下发NAS
[问题描述]：通话挂机后，主叫上报BYE消息，IMS回BYE200消息前后，同时手机发生切换，EPS专载没有释放，1s后软件统计掉话。
[问题分析]：主叫挂机后，MME收到del bearer req，下发Deactivate EPS bearer context Request给源eNB携带NAS释放专载，但同时源eNB触发X2切换，向MME响应ERAB release response（X2-Handover-Triggered），NAS消息未下发到手机。根据协议36.413 中8.6.2.4有描述当eNB在触发X2切换时，eNB将不传递NAS消息。
[优化措施]：属测试软件统计问题，建议软件加以剔除该问题。
案例分析
2.1 典型案例
案例1：LTE弱覆盖，eSRVCC切换不及时掉话
10:57:29.710基站下发异频异系统测量报告，包含2G频点及B2门限（LTE:-110，GERAN:-95）
10:57:38.479，主叫达到B2门限
10:57:42.109，主叫RSRP已恶化至-117dBm，SINR至-3，但终端仍没有上报B2事件
10:58:05.587，RTP包不能正常收发，10s后RTP inactivity定时器触发，会话中断，出现掉话：
解决建议：
①规范LTE频点配置，清理多余异频频点，缩短终端测量周期；
②终端芯片提高测量能力，尽快实现CDRX休眠期测量功能。
案例2：VoLTE单通现象
VoLTE单通现象分为两类：一是VoLTE打VoLTE单通，二是VoLTE拨打GSM单通。经分析，第一类主要是终端问题，第二类主要是网络问题。
注：红圈为RTP包抓包位置
案例3：eNodeB参数配置不合理，导致eSRVCC失败
问题现象：
终端发生eSRVCC时，在LTE向GSM切换过程中产生掉话。
问题分析：
终端可以正常收到测控消息，并上报测量报告，且掉话发生在向GSM切换过程中，是GSM或者和基站侧参数设置问题。
问题解决：
基站BsCAccess-ID项中的管理状态为Locked，设置有误。将该状态修改为Unlock后，对该站点进行重启后发现eSRVCC功能正常。
2.2 空口信令判断案例
案例1：RRC重建失败，无线网问题
现象：切换失败导致RRC释放，重建RRC未成功，重新进行RRC申请，QCI=1的承载未建立成功，导致掉话
分析：呼叫重建失败后，新小区重新申请RRC，未能建立VOLTE专载，导致掉话。该流程均由ENODEB控制执行。而切换失败的原因往往是无线环境问题、参数配置不合理、邻区漏配、非竞争随机接入异常等，均为无线网问题。
结论：切换失败与RRC重申请流程均与EUTRAN相关，因此认定为无线网问题。
案例2：基站异常导致双端无下行信令及RTP包断传，无线网问题
现象：主被叫VOLTE接通后，在同一小区同时发生缺失下行信令20秒，此后数秒发生终端上发bye request挂断。
分析：丢信令之前，主被叫双端处于同一小区，且RTP包双向传输正常。丢信令期间，终端测量信息完整，但在2秒后发生RTP包只有终端向网络单向传输，未再有任何网络下发的RTP包，高度怀疑基站临时故障导致。
结论：软件显示丢信令，但通过进一步分析确认应为基站故障导致。无线网问题。
案例3： VOLTE接通下发生IMS注册掉话，IMS网络问题
现象： VOLTE接通后，被叫发生IMS注册且成功，此时主叫收到网络下发的bye request内含注册超时字样
分析：按照3GPP协议，终端应在3000秒上发注册，本次华为SBC于3600秒才收到注册请求，此时IMS认为注册超时，对主叫下发了sip bye消息释放了。
但通过进一步确认，终端实际于600秒前已上发了注册消息（UDP），但此时恰好在G网下，未收到回复：
注：同样类型的掉话也有600秒前处于LTE网（TCP），而未收到OK或未鉴权回复的情况
结论：前10分钟的注册失败，导致了后续的IMS通话中释放，虽然终端前一次的失败处理机制可能存在问题，但仍然体现出IMS对通话中发生注册时直接释放会话的措施欠妥。
2.3 网元流程判断案例
案例1：被叫收到寻呼但未收到INVITE请求，核心网问题
现象：主叫上发了invite，被叫收到了寻呼且建立RRC成功，此时应收到下行的invite，但始终未收到。
分析：被叫响应寻呼并进行了RRC申请，表明MME已收到由SGW触发的数据业务请求，即sip invite消息应由IMS网元的SBC下发给了PGW、SGW。
①Sip invite消息由IMS网元SBC下发到被叫核心网网元PGW
②PGW转发给SGW，SGW通过S11触发MME进行寻呼被叫
③被叫被寻呼到，并完成RRC连接与建立默认承载所需RAB，接收数据
结论：收到寻呼消息表示sip invite数据包已经到达了LTE核心网，未能继续下发当前怀疑是sip数据在S/PGW异常丢失。
案例2：重配置消息释放DRB承载，无线网与核心网配合问题
现象：被叫上发sip183后，在激活EPS承载之前，终端上报了1条A3测报，激活EPS后，发生切换重配置消息中释放了QCI=1的DRB。
分析：起呼时MME进行激活EPS承载流程过程中，恰好发生S1切换时，由于EPS承载建立未完成，MME在切换准备阶段，对下发到目标小区的切换准备的请求消息中不携带QCI=1的VOLTE专载，导致VOLTE专载源小区完成的情况下，在目标小区被释放，切换完成后呼叫中断
①切换准备时，MME向目标小区发切换请求，RAB建立请求表只有2条，无QCI=1的专载
②目标小区收到MME的切换请求后，回复的切换确认消息里仅有2条RAB建立
③MME向源小区下发的切换命令消息中，只建立2条承载，导致ENODEB释放了QCI=1的VOLTE专载。
结论：切换与EPS激活流程碰撞，无线网与核心网配合问题。在进行激活EPS专载过程中，发生切换时，均会造成上述问题，目前还无较好的解决办法。
2.4 网络设备问题案例总结
案例1：中兴ENODEB异频重定向掉话，无线网问题
现象：主被叫VOLTE接通后，服务小区信号较差，但未配置异频邻区；通过重定向消息RRC connection release携带频点，由D频段重定向到F频段，但VOLTE呼叫不支持重定向方式的RTP包接续，导致掉话。
设备：中兴ENODEB
分析：中兴设备为了防止邻区漏配情况下，影响用户在LTE数据业务下的感知质量，默认具备异频重定向功能，但未曾考虑对VOLTE呼叫的接续保持。
结论：完善邻区配置，在VOLTE呼叫区域考虑关闭中兴设备的异频重定向功能。
案例2：华为基站到卡特切换导致的RTP包传输中断问题，无线网问题
现象：主被叫接通状态下，在发生一次由华为设备到卡特设备的切换后，20秒后主被叫终端同时上发了bye request消息，网络侧回复bye(487 Request Terminated)，后网络去激活了EPS承载，掉话。
设备：华为ENODEB与卡特ENODEB
分析：PDCP SN SIZE长度有12bit和7bit，目前华为基站配置为12bit,贝尔配置为7bit，两个厂家配置数据不统一。华为enodeb设备具有自适应功能。
①在华为小区起呼时，切换到卡特小区时，卡特无自适应功能，PDCP SN不一致导致组包混乱。
②当在贝尔小区起呼时，切换到华为小区时，华为PDCP SN自适应为7bit，通话正常。
结论：临时解决方案：华为PDCP SN Size修改为7bit，进行拉网测试主叫呼叫56次，未出现终端主动上发bye的掉话。异常掉话及切换后单通问题基本解决
案例3：爱立信IMS网元CS域呼叫处理能力不足问题，IMS网络问题
现象：在做互通测试过程中，主叫VOLTE起呼后，被叫始终在TD下未收到寻呼消息，主叫收到网络侧下发trying后，立即收到网络下发的invtie 604（Does Not Exist Anywhere），呼叫失败。
设备：爱立信IMS
分析：空口信令仅能确认，被叫端处于TD网，发INVITE到MGCF，MGCF回复604 Does Not Exist Anywhere。该问题为爱立信IMS网元MGCF默认配置仅能同时容纳32个CS域呼叫，导致互通测试过程中，由于容量不足，造成大量连续未接通。
结论：爱立信IMS网元MGCF默认配置容量偏小，发生以上问题后，经过扩容已达可处理2、3G呼叫320个。
案例4：华为EPC修改EPS与切换碰撞，拒绝承载修改。核心网问题
现象：主叫VOLTE起呼后，收到网络回复trying，激活了EPS承载后，又进行了1次EPS承载的修改，此时主叫侧在发生了1次LTE的切换后，收到IMS网络下发的sip503消息，服务不可得。
设备：华为EPC
分析：某地在激活EPS完成后，仍需要进行2次EPS承载的修改，本次呼叫时第2次EPS的修改（空口信令不可见）恰好与切换同时发生，当IMS要求核心网PCRF需要对EPS承载进行修改时，由于切换具有更高的优先级，华为EPC拒绝了承载更新，而只执行切换，导致IMS下发sip 503消息中断呼叫
该市合适的CQI=1的EPS承载建立需要3个步骤：
①CQI=1的初始EPS承载建立，GBR=40kbps但TFT无IPV6地址
②修改GBR49kbps支持高清语音并对TFT内的增加IPV6地址以及 UDP端口进行修改
③在现有TFT中再新建两个ptf。
结论：冗余的EPS承载修改TFT，一方面导致了呼叫建立时延长；同时增加了与切换发生冲突的几率；华为EPC在切换与修改EPS承载冲突时，不具备同时处理或排队处理的能力，导致直接以“资源临时不可得”拒绝了承载更新。一方面建议降低EPS承载修改次数，减少切换碰撞几率与时延；另一方面建议华为EPC进行升级。
案例5：华为EPC、中兴IMS协议理解不一致。IMS网络问题（升级SBC解决故归此类）
现象：VOLTE起呼后，EPS承载激活完成，有一定几率1秒后直接收到网络直接下发sip 500消息（Server Internal Error），中断呼叫。
设备：华为EPC、中兴IMS
分析：EPC按照3GPP规范产生的计费标识中包含“0a”的内容，但在IMS网络中，按照SIP协议将“0a”解析成换行符，造成对计费标识的误读。导致中兴IMS网与华为EPC网元PCRF对RX接口中字符格式理解不一致；中兴不支持PCRF通过Rx接口返回的不可见字符，导致了IMS直接下发了内部服务器错误
经过IMS内部信令跟踪：
①中兴IMS网元SCSCF返回500错误，原因为收到SBC转发的invite request消息携带的PCV头部有问题，发现换行符（0A），导致S-CSCF网元上解码认为头部结束，从而认为不合语法规范，获取ecid失败
②华为EPC网元PCRF通过Rx接口返回接入网络计费标识（Access-Network-Charging-Identifier-value），至中兴IMS SBC，而后中兴SBC通过ecid参数来HEXDIG编码上述计费标识信息
29.214协议：The Access-Network-Charging-Identifier-Value AVP(AVP code 503)is of type OctetString, and contains a charging identifier
结论：即3GPP该计费标识可以包含字符串形式，中兴按IMS SIP协议理解ecid只能是可见字符，对字符串形式不进行HEXDIG转换，导致了上述问题。临时解决方案，中兴SBC进行相应的版本或补丁解决，支持不可见字符。
第二篇：VoLTE百日会战KPI优化周报-W17 (002)
VoLTE百日会战KPI优化-W17 重点巡检项目
第一批巡检的城市7项集团关注的重点指标基本能达到或者超过集团要求。
DT KPI按照目前集团的要求暂时没有太大压力，各项目如有省内评比的压力，请积极反馈省内竞争对手的指标情况。请严格按照各省客户要求的路线进行测试。F-ASB区域下周开始将不在上报上海项目情况，原因为上海f-ASB区域为三方负责一体化优化工作。
厂家指标来源是否为客户指定测试路线当前测试当前测试终终端类型端版本平均RSR平均SINMoS平均PR值>3.5 MOS占比>3.0(%)85NOKIADTNOKIADTNOKIADTNOKIADTNOKIADTNOKIADTHWfASBfASBfASBHWDTDTDTDTDTNYYYYYNYYYYYYYYYYYYHTC M8T3.59.1403.2HTC M8T3.51.1403.2HTC M8T3.51.1403.2HTC M8T3.51.1403.2HTC M8T3.59.1403.2ATUHTC M8T3.59.1403.2HTC M8T3.59.1403.2HTC M8T3.59.1403.1ATUHTC M8T3.59.1403.2HTC M8T3.59.1403.2HTC M8T3.59.1403.2HTC M8T3.59.1403.2HTC M8T3.59.1403.2HTC M8T3.59.1403.2HTC M8T3.59.1403.1HTC M8T3.59.1403.2-89.80-86.77-80.37-85.26-82.33-89.79-80.66-85.00-84.08-83.45-78.56-81.22-88.86-80.02-69.35-85.93-80.41-82.25--12.7916.9115.4814.8614.5915.69 14.1520.01 14.0016.2813.3217.3416.4217.1417.1416.7717.91 16.03-14.87--3.873.673.643.753.843.96 3.833.94-3.843.623.903.493.773.914.013.68 3.90-3.88--86.30 70.5471.2881.87 84.7091.69 96.6891.92-73.9475.4585.24-0.840.9092.93 88.57 89.54-86.470.91-97.29 81.9683.0391.73 95.3497.16 91.5697.95-89.6088.9393.10 91.290.9296.5896.88 94.28 97.27-95.740.96-VoLTE呼延(s)43.373.043.112.782.912.14 4.002.70 3.601.932.892.803.582.383.152.342.51 2.25-2.116.37-1.300.380.140.741.840.22 1.010.32 0.850.721.680.83-0.940.980.700.95 0.60-0.840.00-16.5216.427.7915.4617.127.74 5.564.59--14.6817.54-12.0114.648.895.89 9.30-78.008.07-MOS占比叫建立时RTP丢包率RTP抖动接通率(%掉话率(%)97100.0099.7799.3798.31100.0099.68 99.26100.00 100.00100.00100.00100.00100.0099.3699.1498.6198.76 100.00-100.001.00-)10.002.034.730.620.420.27 1.870.00 0.850.000.420.000.830.480.000.740.71 0.97-0.000.00-IMS注册eSRVCC成功率（%）98100.00100.0098.15100.00100.00100.00 100.00100.00 100.00100.00100.00100.0096.00100.00100.00100.00100.00 100.00-100.00100.00-1139600 190 50402540000-0--切换次数eSRVCC切eSRVCC成功率（%）97100.00 100.00 100.00 100.00 no Esrvc HO no Esrvc HO94.74 no Esrvc HO100.00 no Esrvc HO100.00 no Esrvc HO100.00100.00 no Esrvc HO no Esrvc HO no Esrvc HO no Esrvc HO-no Esrvc HO------171.000.00172.00235.19260.00No update换时延-用户面（ms）350125.00300.50404.00ATU+N11_01.6900RPD_CN-80.25NOKIADTNOKIADTNOKIADTNOKIADTNOKIADTNOKIADTNOKIADTNOKIADTNOKIADTNOKIADTNOKIADT低于集团要求Top3第一批测试城市第二批测试城市暂无合同或客户无要求 指标问题
掉话率
福州 2.03% 厦门 4.73% 上海 1.87% 福州、厦门初步判断与本次测试采用的大唐 ATU设备问题有关。
此外厦门网络进行MME POOL扩容工程，新站入网也较多，没来得及优化，导致掉话率也比较高。
上海初步判定测试终端问题，终端不到时间主动发送Bye，导致掉线
>3.0 MOS占比(%)福州81.96% 厦门83.03% 福州、厦门初步判断与本次测试采用的大唐 ATU设备问题有关。
福州ATU通道异常，网格3/6/7/8/9/16低于90%，其余网格均高于90% 厦门2套大唐ATU设备中一套测试MOS>3.0的只有40%左右，导致全网的MOS值较低
eSRVCC成功率（%）上海94.74% 上海初步判定测试终端问题
Sharing 江西网管VoLTE掉线高问题
江西RLF延迟定时器屏蔽盒验证有效果，修改SWconfig文件内参数，可延长到15s左右释放，指标评估还在进行中，由于VoLTE呼叫数量少，暂时效果不明显。缺点是每次修改都需要重启集中生效。
宁波昨天改了30个站点，效果体现。Gn平台掉线由0.6—>0.13;OMC指标由于15a的公式原因未做评估。现场会继续观察
该方法拉长了RLT的时长，对于DT、ATU测试的掉线率可能同样有效，能够加大RRC重建成功的几率。河南项目华为最近ATU掉线率直线下降为0，可能和RLT 20s计时器设置有关，现场正在调查。
网管eSRVCC统计修正
网管升级NetAct 15.5之后，对应的北向2.6 mapping文件需要打一个补丁path_001，然后再打完path之后还需要手工按照下表来改映射。要不然会出现eSRVCC切换统计为0的情况
其他项目
整体看全国其他项目的综合指标低于第一批巡检的重点城市。
IMS注册成功率 广东 96% 初步判断是核心网问题，4月份广东几乎所有地市IMS注册成功率都比较低 掉话率
湖南 1.47%->0.52% 掉话问题主要为无线环境、邻区未配置等多问题，已分别处理，无特别共性问题。
现场性能问题
北京/浙江/江西 问题：
网管统计eSRVCC成功率低。
北京：90%左右，低于HW、ZTE的93%。浙江：94%左右。
江西：90%左右，低于华为96%。解决措施：
除下列优化手段外，在counter统计方面NOKIA用SUCC/ATT计算成功率，比华为采用的(ATT-FAIL)/ATT差3个点是一个重要原因，但按照华为的counter定义，两个公式的结果是一样的因为HW 统计中ATT=SUCC+FAIL，而NOKIA ATT> SUCC+FAIL，差别在于NOKIA的统计方式SUCC会少一部分。
北京：eSRVCC成功率有所改善，保持在90%以上，不过与异厂家差距还在，需要探求新方法。浙江：
1、开网优化中的规划邻区数偏少，目前结合2G邻区规划数据和CSFB统计优化邻区配置：已完成SRVCC邻区和频点新规划方案，并在小区域进行试点和指标评估，目前SRVCC已经提升至95.28（杭州98左右）。
2、弱电平SRVCC Feature：近期研发会在TL15a出Knife支持Smart SRVCC，并在宁波现场验证。江西：近期针对有ESRVCC失败的小区进行邻区重规划、个别站点进行B2门限优化。4-16：修改城区b2异系统门限-90，郊区b2异系统门限-95，eSRVCC成功率提高3%左右，并针对eSRVCC失败的小区添加邻区，目前除了赣州、抚州指标较差，其他三个地市达到94%；
4-18：各地市都出现偶发性的eSRVCC失败次数异常多，且都在较短的时间内，出现的小区不固定，无法抓包定位，临时将出现问题的小区的2G邻区删除； 浙江 问题：
N1 Max终端问题。
1.最新集团ATU会使用N1 Max手机测试语音和视频，新手机拉网测试语音接通率从99.1大幅到97.33（同网格不同手机）。
2.最新集团ATU会使用N1 Max手机测试语音和视频，新手机拉网测试语音掉话率大幅恶化0.31至1.86.解决措施：（无更新）
1.分析N1Max有一定概率触发bearer resource modification request，但是由于诺基亚核心网功能缺陷一定会拒绝，为核心网已知问题。暂无解决办法。
2.主被叫建立通话后，单通20秒后，随后由被叫发送BYE请求，最终导致掉话。基本确定是N1MAX终端版本缺陷导致，待升级后确定。问题：
1.VOLTE呼叫建立成功率概率性下降，QCI1专载建立流程与X2切换流程冲突，导致专载建立失败，且不触发CSFB流程。解决措施：（无更新）
已报caseNA05885826。问题：
VoLTE掉话率高。MP1.2.1版本批量升级已经开始，目前已完成2批次300多站升级，但升级后TDS个别小区接通率恶化验证、全网切换成功率99.43%下降至98.15%（问题1），且升级后大量双模站点LTE侧出现4160告警退服（问题2），VOLTE掉话率无明显改善（问题3）解决措施：
问题1.已开case NA05912525 /(TNodeB V400R10)After the base station upgrade appears PS business ERAB success rate is low，重启后可以恢复。目前该case GDC已经将LOG转到鼎桥专家，正在抓包定位。
问题2.双模站点TDS重启后LTE29个站点出现4160告警，LTE基站无法on air。已开case NA05912573(TDD LTE TL15A)，暂无进展。
问题3.初步抓包分析发现，切换后掉话问题依旧，掉话问题未彻底解决。
金华/青岛 问题：
MOS值偏低。
金华：同区域不同厂家网络测试对比结果显示，卡特MOS值3.0占比差华为9个百分点。金华最主要的问题是下行BLER异常偏高，无法收敛在target BLER(10%),其次是质差（DL SINR<10dB）问题，最后是抖动（Jitter>80ms），仅少部分是丢包率（大于1%）和弱覆盖；
青岛：在相同无线环境（SINR)下MOS值贝尔区域低于中兴区域，中兴在不同RSRP和SINR下，MOS值基本都在3.5以上；RSRP高于-100时，贝尔与中兴MOS值相当，但RSRP低于-100以后，贝尔MOS值下降严重；SINR高于12时，贝尔与中兴MOS值相当，但SINR低于12时，贝尔MOS值明显低于中兴。解决措施： 金华：
1.针对此问题已报AR，目前在梳理少部分尚未升级到最新版本的站点，同时需要TAC/GPS重点分析BLER无法收敛的问题。
2.近期通过丢包参数、关闭DRX、调整QCI5权重参数进行面上优化，目前MOS值3.0占比有4个点改善幅度；
3.计划本周进行定点验证测试，并收到问题站点的TRACE。青岛：
1.部分网格已实施“VOLTE丢包率优化参数”part1第一部分，MOS值指标无明显提升，后增加的5个参数对MOS有所提升；
2.尝试联系核心网针对SAEGW上对各个qci值的突发大流量包的三种处理方式，policing/shaping/advanced_shaping，修改为qci=1/2配置的处理方式是shaping，降低时延和抖动，未能实施；
3.切换前后对MOS的影响较大，切换前1s和切换后3sMOS低于3.0的采样点占整体将近50%，无线侧已针对频繁切换通过RF调整、CIO、切换迟滞进行优化，降低频繁切换对MOS的影响，但切换丢包率较高还需要二线支持帮忙分析切换对MOS的影响问题； 4.对比测试HW&ZTE发现，尽管ASB区域UL TBS更大，HW&ZTE的TBS在1000左右，ASB在2500左右，而HW的UL grant在180左右，ASB仅约50，整体差异较大，即UL grant差距是关键，需研发介入调查；研发回复之所以用这么大的TBS是为了应对突发情况，另一方PRB资源只是影响容量的一方面，最主要的是目前版本调度器一个TTI只能调度6个用户，在实验室环境下也只能调度到30个左右；PRB调用个数会在PL07版本改善，预计从4个降至3个。
5.计划对部分区域升版到PF07load，验证效果；青岛需要将07版本基于V21上面做新的LOAD，现在LOAD没有做出来，等LOAD出来进行验证； 金华/上海/盐城/扬州/潍坊/锦州/河南 问题：
网管统计eSRVCC成功率低。解决措施：
1.邻区优化及基础无线优化。
2.部分地区参考以下江苏经验，已开始实施：江苏各地市均存在eSRVCC成功率偏低问题，通过前期的数据核查处理，目前约80%的失败集中在VS_HO_LTE_to_GERAN_SRVCC_all_abort_CascadeHO_src(L12885_1)，主要原因在于enodeb收到UE上报的B2事件后，发起了esrvcc请求，之后在执行esrvcc过程中又收到了UE上报的A3或者A5时间，触发了LTE系统内的同频或者异频切换，由于会优先进行系统内切换，所以就把原来的esrvcc过程取消了，目前已经尝试通过修改B2的测量以及针对2/4G邻区分QCI设置不同的eMctaPriority进行问题规避，此外也需要考虑向集团应答修正esrvcc成功率公式，把此类因流程冲突而取消的esrvcc请求剔除掉。
需要升级为TOP的case：
本周暂无
第三篇：网站SEO优化经验总结
网站SEO优化经验总结
导读：网站SEO优化分为站内优化和站外优化，网站优化的核心是以内容为王，然而做网站优化要注意很多细节，这就是同样的优化方法，有些人成功，有些人却失败。
1.外部的反向链接不要一下增加很多，要定时定量的增加。
2.在网站没有很充实内容时提交搜索引擎。提交时网站在架构做好，内容不多时提交。不要有大量内容，不要有重复内容。每天提交内容。搜索引擎喜欢小的，有潜力的网站。
3.从博客来的反链对google排名影响大。从论坛来的反链对百度排名影响大。制作反接方法是：前面是带链接的文本描述，后面再加上网址。
4.网站内部SEO的主要操作重点地方：标题，链接命名，链接深度，文章内容，文章标题，文章内部锚文本链接，文章标签，网页底部和顶部的写法，代码。
5.每星期都尽量更新网站地图。
6.收录速度的决定因素：内容频繁更新，外部高质量链接。
7.增大收录量：百度对不喜欢采集的，要做伪原创。每天内容要不定时但定量更新。
8.避免K站：收录量和外链的多少匹配。收录多了以后，在大量的增加外链。
9.限制某些内容抓取。比如后台管理的地址就要屏蔽搜索引擎抓取。
10.从快照日期看哪些内容已经老了。先限制抓取，然后再删除。
11.做之前把关键词和关键词组列出来。寻找关键字的方法：百度指数：
http://index.baidu.com/百度相关搜索，百度竞价词语。GOOGLE：热榜：
http:///rebang/home
12.每个页面的关键字在20个以内。页面展示30%之内。
13.每个页面都有多个长尾关键字。部署3-5个。最好页面围绕长尾关键字做。通过文章内容作长尾关键字。
14.首页标题的字数，只往上加，不减。
15.文章标题是页面标题的一部分，这样页面标题的关键字就放的多了。
16.把好内容的放在网页的前面和左侧。
17.h标签强调关键词内容。重要关键词h1只能出现一次，流量关键词h2，长尾关键词h3能多次出现。
18.keywords关键词写5，6个就可以了。最多10个词，字数25个以内。
19.《meta name=“description”描述：就是把关键词串起来的一段话。
20.每个图片的alt标签都要有，但不能一样。
21.文章的标签重要。而且也能对图片起提示作用。
22.单页面优化：每个页面的标题必须不同。关键字和描述也基本不一样。
23.页面链接在100以内，多了屏蔽掉。标题20以内，描述50以内。
24.站内有关键字的链接要做成导向相关内容的导出链接。
25.有分类时，最好用分类的拼音做这个分类的域名。
26.新内容要在前。容易被抓取。
27.域名要使用“/”结尾的域名，能增加这个域名的pr。比如
/index.html 就不如好。
28.文章标题带有关键词。作用很大。
29.文章字数多时要分页，第段100-150个字，一定带关键词，要带上锚文本链接。文章结尾要写上作者，版权等。最后加上标签。
30.每段里的同样的关键词只链接一次，关键字的链接指向相关的地方，增加微通道。每段里面增加1.2个关键字链接。
31.现在文章内的链接权重大，比如软文就是很好的东西。
32.页面左侧放新发布的文章。
33.在白天发布文章，时间不定。但每天文章数的频率一样。
34.文章页面中有相关的链接。相关文章或者栏目的链接。
35.起一个奇怪的名字，在百度百科创建词条，能有很大的收获。
36.多域名指向一个网站要用301转到一个站，不带www的301转到带www的。
37.把栏目里的“更多”改成“查看更多图片”等带关键字的词语。而且是把链接加在“图片”等关键字上面。
38.品牌词前面加上一个修饰的属性词语。用这个属性词作为锚文本链接。
39.避免使用大量完全相同的锚文本，要使用同义词。不要把大量的锚文字指向同一个页面，指向权重集中的页面。
40.新站的链接不要多。30.40个。找高质量的外链。
41.外部链接最好链接首页，找不到首页就要和本站内容一样的相关页面的链接
42.外链的方法。锚文本改成做关键字，而不是网站公司的名称。
43.看竞争对手的链接。目标网站的反链。好博客的链接。赞助活动得链接。去他的博客看博客链接。网站后面带一个博客。在维基百科等发链接。
44.链接诱饵。能引起讨论的话题，天涯论坛等。低俗内容等。网络书签？？？
45.用雅虎查反相链接。用google管理员工具查反链。
46.如何搜索引擎不收录，可以用空的robots.txt 来尝试。
第四篇：移动网络优化经验总结
移动网络优化经验总结
热度 4已有 133 次阅读 2010-12-22 20:21 |个人分类:网优|关键词:移动网络优化经验总结
移动网络优化经验总结 感知篇
此文通过比喻的方式总结一下我对网络优化工作的认识。
医生面对一位病人时通常是诊断、治疗、观察三个步骤，网优工程师的工作方式和性质和医生极为相似。一．“诊断”
医生在诊断病人病症时需要通过问诊、化验、透视、超声波等方法取得病人数据来判断病人的某些部位的病因和病状。同样，网优工程师在网络优化的过程中第一件要做的事情的如何取得数据和分析数据以确定网络中全部或部分小区何时发生了何种问题，情况如何，如何发生的。“诊断”网络的方法我们通常包括：
1．用户反馈与投诉：就如医生问诊一样，病痛会让病人主动投医，当网络出现问题时某些的时候还来不及等待网优工程师发现，用户的反馈甚至投诉就会到达。用户投诉时往往是“病痛难忍”的时候，说明网络绝对发生了很明显的故障。在对用户投诉的详情了解的过程中我们可以获取到用户感知，通过经验可以初步判断出“病状”：信号差、起呼难、通话质量差、掉话、单通、串话、寻呼失败等，合格的网优工程师能够通过用户投诉的信息初步判断出问题的原因，并有针对性地安排进一步的“诊断”来帮助更正确的“确诊”。
2．DT与CQT：医生确诊病因时，通常需要让病人进行化验，化验可以通过血液和体液中的各种细胞和酶的含量发现病因。DT和CQT的目的也是为了获取一些必要的空口数据用来判断出网络问题，包括：信号强度、话音质量、邻区信息、TA与站距、功率控制、覆盖情况、频率干扰、空口信令、切换过程、掉话过程等。DT和CQT是以抽样为基础面向单个用户，是处理用户投诉问题时非常有效的方法之一。
3．OMCR数据统计分析：对健康有意识的人会经常关注自己的身体状况，通过全面各项的体检来发现可能存在的疾病，例如心率、血压、红白细胞含量等。在无线侧网络优化中可以通过OMCR中的大量计数器数据和信令录制来全面分析整体网络的性能，可以及时发现正在或已经变差的小区，提前将问题解决，保持网络的良好性能，避免引起用户投诉。同时通过OMCR数据分析能更快更好地从面向网元的角度去发现网络性能的问题，例如分配成功率低，拥塞率高，掉话率高，切换成功率低等等。
4．告警监测：常见的外科疾病例如骨折，创伤等是不需要过多的分析就知道病因的。告警监测类似于此，在网优过程中通过观察告警也是很直观的告诉我们设备何时发生何种故障，及时解决故障能够避免网络发生更大的问题，另外在故障分析中第一时间查看告警历史记录能够避免在分析过程中走过多的弯路。
结合以上几种方法我们大部分能够确诊网络发生的“病症”，接下来要做的事情就解决问题，也就是“治疗”的过程。二．“治疗”
治疗一种疾病前，医生掌握了常见的治疗方法，例如药物治疗，手术治疗，物理治疗等。同样网优工程师的基本技能也是要掌握大量的处理故障方法，这些方法大致包括，配置数据更改，无线参数调整，远程复位，设备更换，扩容，天线调整，割接，翻频等。使用何种方法“治疗”需要先了解“病因”，下面就我在工作中最关注的几种问题来总结一下这些问题排查解决方法：
1．语音信道拥塞：
语音信道拥塞的主要“病因”：
1)
话务密度高，超出基站的设计容量；
2)
设备的不稳定或故障造成的可用资源缺乏导致信道拥塞；
3)
邻小区存在故障；
4)
LAC规划不合理，如LAC的边界在高话务地带、主要交通干道等用户多且移动频繁的区域，使得位置更新过于频繁形成不合理的呼叫模型，降低了系统容量；
5)
无线参数设置不合理。如小区重选滞后，切换容限，小区切出触发电；
6)
平等定义的不合理造成的乒乓位置更新和乒乓切换；
7)
覆盖过大，存在孤岛现象。
“治疗”语音信道拥塞的主要方法：
1)
检查小区和它的邻小区是否工作正常，检查TCH可用性以确定不稳定设备。如邻小区工作不正常，本小区会额外承担其部分话务；
2)
检查话务移动性，看是否是由于过量来切换引起的TCH拥塞，如存在，可通过优化切换参数来减少邻区至拥塞小区的切换次数，来减小拥塞；
3)
检查无线参数设置，如小区重选滞后，切换容限，小区切出触发电平等定义的不合理造成的乒乓位置更新和乒乓切换；
4)
通过场强测试，分析是否覆盖过大，有孤岛现象存在。对于孤岛现象，一种方法是调整孤岛小区的天线，消除孤岛现象；另外一个方法是为孤岛小区定义新的邻小区，其参数的定义原则是：从孤岛小区向正常小区的切换/位置更新优先于反方向的切换/位置更新；
5)
拥塞由话务密度高引起，检查基站是否已达最大配置否，规划扩容足够数量的载频。
2．语音信道指配失败
语音信道指配失败的主要“病因”：
1)
硬件故障，如收发信机故障；合路器故障，如无前向功率输出等；板件间射频连线不正确；
2)
同频或者邻频干扰，由于干扰而引起的高误码率，使得移动台不能与BTS建立起第二层链路，导致指派失败；
3)
天馈系统出现故障，由于天馈线受到折损、腐蚀，导致因驻波比过高而影响收发性能。当仅携载TCH的天线受到障碍物的阻挡或覆盖的地区和另一根携带BCCH或者SDCCH信道的天线不一样时，就有可能导致MS占用不上该TCH信道；
4)
参数不合理，如果采用了跳频，而HSN或MAIO设置的不合理，可能导致小区内或跳频组相同的小区间的同频或邻频干扰较大，从而导致指派失败严重，如果T3107设置的过小，使得网络在未收到指配完成时，就由于T3107的逾时已将信道释放掉；
5)
Abis接口传输故障，如果Abis接口传输误码率大，就会导致MS和网络之间不能正常的完成信令的交换，从而导致指派失败现象。
“治疗”语音信道指配失败的主要方法：
1)
检查小区无线参数设置是否合理，如跳频参数、频率数据等，对不合理的参数进行优化调整；
2)
检查BER、空闲干扰带等级等指标，减小消除无线干扰；
3)
检查小区硬件，如收发信机、合路器、分路器，板件间的射频连线等，对故障硬件进行排查更换；
4)
检查天馈系统，如排查天馈驻波比，同一小区的天线是否朝向一致，有无天馈线接错接反等问题，对存在的故障进行排查更换；
5)
排查传输故障。
3．掉话
掉话分为三大类：无线链路掉话、LAPD掉话、切换掉话，相对来说是网优工作中故障的重中之重，是KPI指标中最重要的一项。
无线链路掉话的“病因”有：
1)
存在覆盖弱区，无线信号差；
2)
存在干扰，如频率规划不当而导致的网内干扰以及其他系统外干扰等；
3)
无线参数设置不合理：小区最小接入电平设置过小，导致移动台在覆盖弱区通话，易掉话；NCC Permitted设置不合理，有些网络可能存在主小区和邻小区采用不同的NCC，这就需要在NCC Permitted中添加相应的邻区采用的NCC。一旦设置不合理，将导致移动台不侦测某一NCC的邻区，导致无法切换，产生射频丢失掉话；
4)
无线链路故障定时器设置过小，导致移动台陡然恶化情况下就超时掉话；功控参数设置不合理，如电平、质量功控门限不合理，可能将导致移动台在信号差、质量差的时候还在降功率等问题；跳频参数设置不合理，Maio配置不合理，导致同一站内存在同邻频干扰；
5)
邻区数据定义不全或配置错误，导致移动台无法通过切换来改善信号，导致信号恶化掉话；
6)
切换参数设置不合理，导致移动台在质量很差的情况下无法及时切换来改善无线质量而掉话；
7)
邻区存在拥塞，导致移动台在质量很差的情况下无法及时切换来改善无线质量而掉话。重点需解决邻区的拥塞；
8)
设备硬件故障，如功放输出功率过低，不同载频发射功率差别大，载频发射机、合路器、分路器设备故障等；
9)
天馈系统故障，如小区内两根天线倾角和方位角不一致，天馈驻波比大，天线过高或下倾角不合理造成覆盖范围过大，造成越区覆盖，形成远端孤岛效应而产生掉话等；用户原因造成，如移动台电池接触不良易掉电等。
无线链路掉话的“治疗”方法：
1)
检查无线参数设置，对不合理的无线参数设置进行调整；
2)
检查BER、空闲干扰带等级等指标，减小消除无线干扰；
3)
通过路测查看是否存在覆盖问题，针对弱覆盖区，需重点排查硬件故障，针对越区覆盖，需重点排查功率参数、切换参数，天线下倾角等；
4)
检查排除设备硬件，对问题板件等进行更换；
5)
检查天馈系统，对问题部分进行排查。
LAPD掉话的“病因”有：
1)
基站传输问题，如传输中断或传输不稳定（时断时续）等；
2)
基站侧硬件故障，如E1线不可靠，CMM板，背板连线存在故障等；
3)
BSC侧硬件故障，如LAPD处理板等。LAPD掉话的“治疗”方法：
1)
排查BSC侧硬件故障；
2)
排查基站传输；
3)
排查基站侧硬件故障。
切换掉话的“病因”有：
1)
存在干扰，如频率规划不当而导致的网内干扰以及其他系统外干扰等；
2)
设备硬件故障，如目标小区或本小区存在时钟故障，功放输出功率过低，不同载频发射功率差别大，载频发射机、合路器、分路器设备故障等；
3)
无线参数设置不合理，目标小区同BCCH同色等问题，导致切出失败高，从而形成掉话；
4)
邻区关系定义不当或邻区数据错误，导致切出失败高，从而形成掉话；
5)
切换参数设置不合理，导致乒乓切换等问题，易形成掉话。
切换掉话的“治疗”方法：
1)
检查无线参数设置，对不合理的无线参数设置进行调整，合理增加邻区关系等；
2)
检查BER、空闲干扰带等级等指标，减小消除无线干扰；
3)
查排除设备硬件，对问题板件等进行更换。
网优工作中处理的问题和病人的病一样，有大病也有小病，有外科有内科，有常见疾病，很容易就处理的，例如更换载频；也有重症疾病需要大动手术才能处理，例如翻频、割接；同时也会出现一些疑难杂症，现场人员解决不了的，需要专家会诊。医生需要治疗经验总结共享，网优工程师也需要将经验汇总，传授于新人，因为某种意义上经验就是理论，经验就是知识，我作为一位新人在实习过程中，非常感谢我的指导老师给我传授了很多宝贵的经验，也感谢部门的专家给我们总结很多经验文档供我们学习。三．观察
医生在治疗病人时，观察是同步的，也是反复的，这个过程的目的就是为了确保治疗的方法有效，保持病情的稳定，直到病症消除。网优工作也是一样，常见的“治疗”方法是比较片面的，要找到正确的方法，也是一个处理与观察相互的过程。例如，通过BTS测量发现某载频指配成功为零，第一判断是载频故障，某些时候并不是如此，CDU故障也会导致同样的问题，所以在更换载频后网优工程师必须进行KPI观察，以确保解决方法有效，直到问题解决。
总体来说，在网优工作的过程中，把自己当做网络的“医生”，需要不断提高“医术”，需要不断总结经验，需要掌握很多“诊断设备”的使用，要掌握一些“手术”技能，要有一种良好的“医德”在遇到“病症”时要尽自己最大能力去“治疗”，不能放任不管，敷衍了事，这是对自己职业的不负责，也是对我们的“病人”不负责。.本文来自: 去通信网优论坛 详细文章参考：http://yaovs.com/home.php?mod=space&uid=1&do=blog&id=188
第五篇：VoLTE测试案例分析
案例1：580 Precondition Failure导致的未接通。
【问题描述】
在集团测试LOG中，存在Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。
Log文件名：
9100060920***3MS2_UE1.lte 9100060920***3MS2_UE2.lte MO UE: *** MT UE: *** 时间：10：16：14.320
【问题分析】
1、呼叫过程中，被叫发送Ringing 180后，收到网络下发的专载去激活命令，QCI 1被释放，被叫随后上报580 Precondition Failure，主叫同样收到网络侧转发的580消息，呼叫接续中止，导致未接通。
2、从信令中可以看到，被叫回复Ringing 180且主叫也已经收到Ringing 180，被叫随后收到网络侧下发的RRC重配，携带有QCI 1被释放的信息，被叫去激活专有承载。由于专载已被释放，业务资源已不存在，所以被叫上发580 Precondition Failure失败消息。主叫收到网络侧下发的580，接续被中止，导致了会话未接通。
3、从MME下发到Node B的E-RAB RELEASE COMMAND，原因上看是Nas层nomal_release，导致专载QCI 1被释放。
4、专载QCI 1被释放，去激活后，被叫发送INVITE 580，主叫收到网络侧转发的INVITE 580，会话流程中断，导致未接通
【问题定位】
在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND，使得QCI 1被释放，导致未接通。【解决措施】
需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。
【测试验证】
案例2：Server Internal Error 500导致的未接通
【问题描述】
在集团测试LOG中，存在Server Internal Error 导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的Server Internal Error 500消息，随后呼叫中止，出现未接通事件。
Log文件名：
9500061120***2ms1.lte 9500061220***2ms1.lte MO UE: *** MT UE: *** 时间：10：19：29.051
【问题分析】
1、主叫发出UPDATE后，被叫收到UPDATE并回复UPDATE 200，随后被叫发送Ringing 180，主叫同时收到UPDATE 200和Ringing 180。按照正常的信令流程应该是先收到UPDATE 200，再收到Ringing 180。
2、然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放，去激活，导致会话未接通。
【问题定位】
主叫收到网络侧下发的INVITE 500，然后网络侧又下发RRC重配，释放掉QCI 1，然后去激活，会话流程终止，导致未接通
【解决措施】
需要核心网确认，为什么会下发INVITE 500，什么情况下会导致网络侧下发INVITE 500，随后的专载释放是否由INVITE 500导致的
【测试验证】
案例3：软件对失败事件的误判导致统计错误
【问题描述】
在集团测试LOG中，存在软件的误判而错误统计的失败事件。如在某个特定时间点上，信令显示主被叫正常通话，软件却统计出掉话或未接通事件。
Log文件名：
9500060520***1ms1.lte 9500060620***1ms1.lte MO UE: *** MT UE: *** 时间：09：44：14.0 【问题分析】
1、主叫从09:42:41主叫开始呼叫到09:45:47挂机成功，在通话过程中信令流程正常，中间出现一次RRC重建被拒，导致RRC释放，事件表现为掉话，软件统计为掉话。
2、在09：44：14.910主叫收到网络侧下发的RRC重建被拒，主叫随后发起RRC建立请求，在09：44：15：004，然后因为TAU，在09：44：15：128 RRC Connection Release了，软件统计为掉话。随后主叫又发起RRC连接，且在09：44：15.659重建完成，从RRC重建被拒到RRC连接成功不到1s，且默认承载和专有承载均保持，未被释放，证明会话保持正常。
3、到最后结束通话正常挂机都没有出现失败事件
【问题定位】
主叫接通后，在没有收到通话结束的情况下，中间出现RRC Connection Release，软件判断为掉线，此次是在会话建立后出现，软件统计为掉话
【解决措施 】
需要鼎利修改判断事件失败的机制
【测试验证】
案例4：软件对失败事件的重复统计
【问题描述】
软件对于失败事件存在重复统计的问题，在集团测试问题统计表中，多次出现同一次失败事件，软件却作了多次统计，导致失败事件的增多。
Log文件名：
9500060520***1ms1.lte 9500060620***1ms1.lte MO UE: *** MT UE: *** 时间：10：04：08.0 【问题分析】
1、主叫在10：04：04.642发出INVITE会话请求，被叫在10：04：08.261收到网络侧下发的BYE Request，软件统计为掉话。
查看BYE Request中的CALL-ID，发现是上次会话的BYE Request
2、被叫在10：04：08：230收到网络侧下发的INVITE Request同时发送Trying 100，又在10：04：08.261收到网络侧下发的INVITE Request同时发送Trying 100，并在同时发送INVITE 486，软件统计为未接通。
3、主叫在收到网络侧下发的UPDATE 200后，在10：04：24.845上报Cancel，主叫的整个会话流程到这里被终止，事件上表现为未接通。且承载都存在
【问题定位】
通话期间，被叫收到网络下发的BYE Request会被软件统计为掉话。被叫连续两次收到网络下发的INVITE Request，回复INVITE 486 Busy Here，由于第一次INVITE Request未释放，故第二次INVITE Request网络侧才会下发INVITE 486，流程停止，软件统计为未接通。此时主叫在进行正常的会话接续，信令流程正常，事件中未出现失败事件。直到主叫上报Cancel，主叫会话流程停止，事件表现为未接通，之前的两次失败事件统计是重复统计。
【解决措施】
需要鼎利确认对失败事件的统计机制。
【测试验证】
案例5：LTE到2G eSRVCC切换失败导致的掉话
【问题描述】
呼叫会话建立后，由于到达异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置命令，但在2G侧切入失败，导致掉话。
Log文件名： 9500060520***5ms1.lte 9500060620***5ms1.lte MO UE: *** MT UE: *** 时间：11：16：42：311 【问题分析】
1、被叫上报B2事件，满足切换门限系统下发mobility切换命令，此时4G的流程已完成，接下来切入2G网络，2G网络下发TMSI Reallocation Command，被叫回复TMSI Reallocation Complete，此后流程中断，eSRVCC切换失败。
3、信令上看，4G流程正常走完且建立会话，被叫切换到2G，但是网络下发TMSI Reallocation Command导致流程终止，eSRVCC切换失败，会话流程结束，怀疑是2G问题。
【问题定位】
4G流程正常且已正常建立会话，由于2G网络侧下发TMSI Reallocation Command导致eSRVCC切换失败，会话流程结束，导致掉话，怀疑是2G的问题。
【解决措施】
下周准备复侧，准备定位。
【测试验证】
案例6： TAU过程中RRC Connection Release导致的未接通
【问题描述】
在越秀区网格10的测试LOG中，出现如下的未接通事件： 主叫起呼发出Invite消息后，在收到网络效应Trying 100之前，先收到了网络下发的RRC Connection Release消息，RRC连接释放后，接续被终止，出现了Blocked Call事件。
【问题分析】
1、通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从PCI216小区重选至PCI103小区，由于源小区与目标小区处在不同的TAC，主叫发起了TAU请求：
2、在主叫上发TAU请求后，未等网络回复ATU Accept，主叫已开始了起呼，上发Invite消息。然而Invite上发0.172s后，主叫同时收到了网络下发的ATU Accept和RRC Connection Release消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫释放，从而导致了Blocked Call事件的发生：
3、进一步分析信令可以发现，主叫在该测试路段内连续在3个TAC（9437、10315、10014）间进行TAU更新，其中从11:42:53至11:43:04就发生了4次，可能在存在TAC规划不合理的问题。
【问题定位】 【解决措施】 【测试验证】
案例7：Alerting中eSRVCC失败导致未接通
【问题描述】
主叫起呼后，流程正常，达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing 180，主叫未摘机，由于切换失败导致未接通。
Log文件名：
9500060520***5ms1.lte 9500060620***5ms1.lte MO UE: *** MT UE: *** 时间：11：25：28：189
【问题分析】
1、主叫在11：25：26.130起呼，到11：25：28.204收到网络侧转发的Ringing 180，整个信令流程正常
2、在主叫几乎收到网络侧转发的Ringing 180的同时，主叫达到eSRVCC切换门限，网络侧在11：25：28.189下发eSRVCC切换命令，在切换过程中主叫处于振铃中，并未摘话，而切换失败，导致了未接通。
【问题定位】
主叫已经收到Ringing 180，处于振铃状态还未摘话，由于在Alerting中发生了eSRVCC 切换失败导致了未接通
【解决措施】
需要核心网方面帮忙定位 【测试验证】
案例8：CSFB失败导致未接通
【问题描述】
主叫起呼后，被叫CSFB失败，主叫直接Cancel导致未接通
Log文件名：
9500060520***6ms1.lte 9500060620***6ms1.lte MO UE: *** MT UE: *** 时间：15：42：53：063 【问题分析】
1、主叫于15:42:22发起invite，被叫未收到网络侧转发的INVITE Request，但是主叫能一直收到网络侧下发的INVITE 183、PRACK、UPDATE消息，这些消息被叫并没有收到也没有回复。被叫在15:42:24收到网络侧下发的CSFB request，但CSFB到2G后从信令看没有呼叫相关的信令交互过程
2、直到15:42:35 CSFB失败，由于收不到被叫的响应，主叫主动于15:42:53发起CANCLE。导致会话未接通。
【问题定位】
主叫发起会话后，被叫没有收到会话请求，直接CSFB，CSFB失败，主叫一直未收到被叫的响应，直接Cancel，导致会话未接通。
【解决措施】
需要核心网 查看为什么被叫没有收到主叫的会话请求，且主叫能收到网络侧下发的INVITE 180、UPDATE、PRACK消息。【测试验证】
案例9：被叫Detach导致会话未接通
【问题描述】
主叫发起会话，被叫驻留在2G未返回4G，没有响应主叫的会话请求，主叫收不到被叫相应，直接Cancel导致未接通。
Log文件名：
9500060520***6ms1.lte 9500060620***6ms1.lte MO UE: *** MT UE: *** 时间：15：43：37：999
【问题分析】
1、主叫在15：43：08.657起呼，此时被叫任然驻留在2G，由于上一次会话中CSFB失败，并没有返回4G。
2、起呼后，被叫一直无响应，没有与主叫进行信令交互，然而主叫能一直收到网络侧下发的PRACK、UPDATE消息。
3、主叫一直收不到被叫的回复，被叫在15:43:30.449被叫上发Detach Request，主叫在15：43：37.999上发Cancel，取消会话，导致未接通
【问题定位】
被叫停留在2G未返回4G，然后上发Detach Request，主叫收不到被叫的回复，直接Cancel，导致未接通 【解决措施】
需要核心网查看为什么主叫会话信令流程正常，被叫却无法收到主叫的会话请求。同时查看2G无线侧，为什么被叫会上发Detach Request。
【测试验证】
案例10：承载未建立导致未接通
【问题描述】
主叫收到100 Trying 后未建立承载，使得 RRC直接释放，导致未接通
Log文件名：
9500060520***5ms1.lte 9500060620***5ms1.lte MO UE: *** MT UE: *** 时间：15：46：36：271 【问题分析】
1、主叫在15：46：19.079发起会话，收到网络侧下发的100 Trying后，专有承载一直未建立，10s后RRC释放，主叫在15：46：36.271上发Cancel，导致会话未接通
【问题定位】
专有承载未建立，10s后RRC释放，导致未接通
【解决措施】
需要核心网查看为什么没有建立专有承载 【测试验证】
案例11：承载异常释放导致掉话
【问题描述】
被叫重建立成功后，专有承载突然被释放，导致掉话
Log文件名：
9500060520***1ms1.lte 9500060620***1ms1.lte MO UE: *** MT UE: *** 时间：10：35：41：981 【问题分析】
1、主叫在10：28：06.903起呼，流程正常，收到网络侧转发的Ringing 180，UPDATE 200，主被叫会话正常建立。
2、被叫在10：35：38.253发送重建立，重建立成功，且流程正常，但是在10：35：41.981承载被释放，导致掉话
【问题定位】
会话建立后，被叫重建立完成，但是专有承载被释放，导致掉话
【解决措施】
需要核心网确认承载释放的原因 【测试验证】
案例12：信令转发失败导致未接通
【问题描述】
主叫发起会话请求，网络侧未转发，被叫未收到，主叫Cancel，导致未接通
Log文件名：
9500060520***1ms1.lte 9500060620***1ms1.lte MO UE: *** MT UE: *** 时间：10：03：48：952 【问题分析】
主叫在10：03：32.741发起会话，被叫未收到，直到10：03：48.952主叫Cancel，会话接续无法继续，导致未接通。整个过程无线环境良好，网络侧未转发信令。
【问题定位】
网络侧未转发主叫会话请求，使得会话接续无法继续，主叫Cancel，导致未接通。
【解决措施】
需要核心网确认会话信令是否成功转发
【测试验证】
案例13：终端上报Cancel导致会话未接通
【问题描述】
会话流程正常接续，终端上报Cancel，导致会话未接通
Log文件名：
9500060520***5ms1.lte 9500060620***5ms1.lte MO UE: *** MT UE: *** 时间：14：53：06：510 【问题分析】
1、主叫在14：53：03.998起呼，信令流程正常，且被叫上发Ringing 180，主叫收到网络侧转发的Ringing 180，主被叫都已经振铃。但是主叫突然在14：53：06.510上发Cancel，被叫也收到网络侧转发的Cancel，会话接续停止，导致未接通。
【问题定位】
主被叫会话流程正常，无线环境良好，信令转发正常。主叫上报Cancel，导致会话未接通，定位为终端问题
【解决措施】
需要终端确认或者更换终端测试再查看结果
【测试验证】
案例14：
【问题分析】 【问题定位】 【解决措施】 【测试验证】
点击咨询 