VoLTE优化实战基础手册.doc

VoLTE优化实战手册
1 参数与定期器配备（建议）

1.1 VoLTE互操作类参数

1.2 VoLTE 功能类参数

1.3 定期器参数

1.3.1 接入类定期器

参数英文名：T300

功能描述：
该参数表达UE侧控制RRC connection establishment过程定期器。在UE发送RRCConnectionRequest后启动。
在超时前如果：1.UE收到RRCConnectionSetup或 RRCConnectionReject；2.触发Cell-reselection过程；3.NAS层终结RRC connection establishment过程。则定期器停止。
如定期器超时，则UE重置MAC层、释放MAC层配备、重置所有已建立RBs（Radio Bears）RLC实体。并告知NAS层RRC connection establishment失败

对网络质量影响：
增长该参数取值，可以提高UERRC connection establishment过程中随机接入成功率。但是，当UE选取社区信道质量较差或负载较大时，也许增长UE无谓随机接入尝试次数。
减少该参数取值，当UE选取社区信道质量较差或负载较大时，也许减少UE无谓随机接入尝试次数。但是，也许减少UERRC connection establishment过程中随机接入成功率

1.3.2 切换类定期器

参数英文名：T304 For Intra-Lte

功能描述：
在“E-UTRAN内切换”和“切换入E-UTRAN系统间切换”状况下，UE在收到带有“mobilityControlInfo”RRC连接重配备消息时启动定期器，在完毕新社区随机接入后停止定期器；定期器超时后UE需恢复原社区配备并发起RRC重建祈求

对网络质量影响：
用于系统内切换，该值设立过大会导致切换失败无法及时回退并发起RRC连接重建过程

1.3.3 重建类定期器

1）参数英文名：T311

功能描述：
T311用于UERRC连接重建过程，T311控制UE开始RRC连接重建到UE选取一种社区过程所需时间，期间UE执行cell-selection过程。

对网络质量影响：
设立值越大，UE进行社区选取过程中所被容许时间越长， RRC Connection Reestablishment过程越滞后；如果该参数设立过小，也许在某些链路可以被挽救状况下，却由于定期器设立不合理而进入IDLE状态，引起掉话，严重影响顾客感知。

2）参数英文名：T301

功能描述：
在UE上传RRCConnection ReestabilshmentRequest后启动。在超时前如果收到UE收到RRCConnectionReestablishment或RRCConnectionReestablishmentReject，则定期器停止。定期器超时，则UE变为RRC_IDLE状态

对网络质量影响：
增长该参数取值，可以提高UERRC connection re-establishment过程中随机接入成功率。但是，当UE选取社区信道质量较差或负载较大时，也许增长UE无谓随机接入尝试次数。减少该参数取值，当UE选取社区信道质量较差或负载较大时，也许减少UE无谓随机接入尝试次数。但是，也许减少UERRC connection re-establishment过程中随机接入成功率

1.4 互操作邻区配备

VoLTE商用后，由于语音业务需求或由于4G覆盖因素，终端需要通过SRVCC方式互操作至2G系统。因而，制定4G至2G邻区配备办法如下：
可先继承CSFB邻区配备原则。
详细如下：

4G 至2G邻区配备原则（用于VoLTE业务）
1）如果4G与2G社区共站，4G一方面需要配备所有共站2G社区;同步需要继承配备其中同方向角2G共站社区(系统实现时可考虑一定角度放宽,暂定60度内)2G邻区。

2）如果4G仅与3G社区共站，4G需要配备所有3G共站社区2G邻区。

3）如果4G站点为新建站，优先添加第一圈2G邻区。应重点检查如下两类2G社区：
●距离4G站点近来N个2G站址中，如果存在室外社区,则选取天线方向指向本社区2G社区（建议是法线正负60°之内）；如果存在室分社区，则无需考虑方向角，上述室内、外社区共M个（N建议不大于9个；建议距离在2km范畴内）
●4G社区天线法向方向正面对打社区且两社区天线相对方向角度在60°之内近来2个候选邻区（该邻区距本社区不超过1000m），如该2社区被包括于前述M个社区，则需配邻区个数为M，否则为M+2个。

4）如果4G与2G共室分，4G需要配备该2G室分社区，及该2G室分社区邻区。

2 终端IMS注册问题

2.1 终端开机IMS注册过程

顾客开机后来，一方面完毕EPC附着过程，建立QCI=9默认承载，附着完毕后来，发起IMS注册过程和鉴权。在IMS注册流程中，先建立QCI=5SIP信令承载。然后进行SIP注册过程，当完毕注册过程后来，就可以进行VoLTE呼喊了。若未建立QCI 5就无法完毕终端与IMSSIP注册信令交互；若QCI5建立成功后，终端与IMSSIP注册流程异常，也将会导致不能在IMS成功注册。

SIP信令注册

SIP信令注册过程如下图所示。
（点击放大浏览）

如下为QCI 5承载建立信令流程：

SIP信令注册失败因素

手机附着LTE网络并成功建立QCI9承载后PDN connectivity reject,无法建立QCI5默认承载，将导致无法成功注册IMS。如下图所示：

手机attach request -attach complete过程已经建立QCI=9信令承载，UE会在PDN Connectivity Request消息中包括APN信息，从HSS获得订阅信息中，Service-Selection="wildcard"，因此MME接受UE祈求 APN。依照新APN，分派一种Bearer ID给default EPS，并且发送Create Session Bearer Request 到 S-GW。S-GW会在它EPS Bearer 表中创立一种新实体，并且发送Create Session Request到 P-GW中。S-GW会为Control Plane和User Plane创立新DL S-GW TEID并且把她们发送到P-GW，创立QCI5默认承载。因而PDN CONECTIVITY REJECT会导致无法建立QCI5默认承载，直接导致IMS无法注册。

1）如果是ESM过程导致回绝（例如默认承载建立失败），才会带PDN CONNECTIVITY REJECT消息，EMM层回绝，只有ATTACH REJECT消息。

2）如果回绝因素值是"unknown EPS bearer context"，UE会本地去激活存在默认承载或专用承载

3）常用回绝因素有：IMSI中MNC与核心网配备不一致。

如下为也许解决办法：
1： 检查核心网和eNB侧与否存在有关告警并及时解决
2：查看回绝因素，核查相应参数与否配备对的（IMSI中MNC与核心网配备不一致，APN设立不当等问题）
3：与否存在SIM问题及核心网对SIM卡实行限制相应功能及接入级别
4：SIM卡和核心网HSS记录信息不一致导致无法注册
5：PDN祈求回绝大某些是核心网问题，可以通过抓取信令分析

SIP注册

SIP注册过程：
1）顾客初次试呼时，终端向代理服务器发送REGISTER注册祈求
2）IMS认证/计费中心获知顾客信息不在数据库中，向终端回401 Unauthorized质询信息，其中包括安全认证所需令牌
3）终端将顾客标记和密码依照安全认证令牌加密后，再次用REGISTER消息报告给IMS服务器
4）IMS服务器将REGISTER消息中顾客信息解密，认证合法后，将该顾客信息登记到数据库中，并向终端返回 响应消息200 OK。
5）顾客订阅注册事件包，
6）服务器应答订阅成功。
7）IMS服务器发送notify消息，由于订阅顾客已经注册，因此IMS服务器回应Notify消息中，状态为active，同事携带XML信息。
8）终端发送Notify 200表达接受成功。

QCI 5承载建立成功后，此时终端可以与IMS进行SIP信令交互，完毕IMS注册，若注册流程异常，可以从如下方面展开排查：

1. 需要确认终端与否发出Register SIP信令；
2. 若终端已发，确认IMS与否收到；
3. IMS收到后，与否回相应SIP信令，还是响应注册失败；
4. 与否由于终端未启动IPsec导致IMS回绝注册祈求。

普通状况下，终端IMS注册失败问题都与核心网有关，重要在于核心网侧排查解决。

3 核心参数设立问题

3.1 VoLTE语音AMR-NB AMR-WB 资源占有状况有何区别？

答：AMR全称Adaptive Multi-Rate，自适应多速率编码，重要用于移动设备音频，压缩比比较大，但相对其她压缩格式质量比较差，由于多用于人声，通话。其中AMR分为AMR-NB和AMR-WB两种，对于VoLTE而言，AMR-NB则为12.2k语音编码制式，AMR-WB则为23.85k语音编码制式。

AMR-NB和AMR-WB本质区别在于其语音带宽和抽样频率有所区别，NB语音带宽范畴为：300~3400khz，抽样频率为8khz；而WB语音带宽为50~7000khz，抽样频率为16khz。

如下为有关AMR-NB编码方式，共分为16种，其中0~7相应不同编码方式，8~15用于噪音或者保存用，VoLTE里AMR-NB采用编码方案7；

而AMR-WB编码方式同样也有16种，其中0~8相应不同编码方式，9~15保存用，当前VoLTE语音WB编码制式采用编码方式8。

如下为VoLTE有关测试中高标清占用资源对比状况:
从趋势图来看，在SINR不不大于5时候，整体MOS值比较平稳，其中高清MOS值稳定在3.5以上，标清语音MOS值稳定在3.2左右，而在SINR值不大于5之后，高清和标清语音MOS值均呈现波动且整体均值下降趋势。此外由于在SINR差点打点数较少因素，其MOS均值会浮现随着SINR均值下降而抬升异常状况。

在下行PDCP速率里对比中标清语音在7kb左右，在SINR不大于0之后开始浮现明显波动状况，直至掉0。高清语音PDCP速率则在15kbps左右，同样在SINR不大于0后开始浮现激烈波动状况。
从高清和标清下行PRB数对比状况来看，整体占用RB数差距不明显,此外下行PRB个数随着SINR值恶化逐级抬升。

从高标清指标和资源对比来看，自身AMR-NB和AMR-WB对于网络资源运用限度来看差距不大（PRB上占用差不多），但AMR-WB对于网络资源运用率会相对高些（高清码率更高），且AMR-WB顾客体验更好（MOS值高于AMR-NB一截），且抗干扰性上并没有明显差别，因而在VoLTE将来布置中，更推荐采用AMR-WB编码制式。

3.2 专用承载MAX GBR值对通话质量有什么影响？

答：专用承载MAX GBR太小将导致通话质量差。以现网测试案例为例，用CDS 48KMOS盒对在当前LTE网络下通话质量进行MOS评估时，发现当通话建立在专用承载（GBR）下时CDS MOS打分值偏低。偶尔间发现建立在默认承载上通话MOS值正常可以达到4分。预计为专用承载问题，再用8K语音文献进行MOS打分又恢复正常，拟定为速率问题，调节QCI1 MAXGBR参数后恢复正常。

VOLTE通话评估软件反映通话质量分值低，经监控基站无告警，接入指标正常，更换站点并重新导入参数后仍存在问题。曾尝试在默认承载下进行语音通话发现质量评估并无问题。初步鉴定为专用承载问题。如下图所示（左图为QCI1下，右图为QCI9下）。

选用8K采样语音文献再次进行MOS打分时发现QCI1下MOS值恢复正常

采样率不同区别在于传播时速率不同定位问题点于QCI1专用承载最高速率没有达到48K语音传播规定。在对比查看QCI1与QCI9MAX GBR后拟定了问题因素。下图是QCI1修改前参数（图中MAX GBR数值为换算后成果，下同）

下图为QCI9参数：

核心网QCI1承载MAX GBR改为150：

修改后QCI1:

由于VOLTE是VOIP业务因此速率大小直接影响了通话质量，速率太小语音业务就会浮现卡顿和失真现象。专用承载最大保证比特率应当先由在不受限条件下业务最高速率来拟定。

3.3. QCI=1开关不打开或打开但maxGBR配备过低对Volte电话影响？

答：当拨打volte电话时，QCI=1开关未打开，没有建立QCI=1专用承载，电话拨通5S后会自动挂断如图所示：
因此判断必要打开QCI=1专用承载开关，才干正常拨打电话。在后台配合下，启动QCI=1专用承载，并配备maxGBR=20k。再次拨打volte电话，发现专用承载仍未建立，volte电话依然是5s挂断，如下图所示：

推断无法正常拨打电话因素是maxGBR=20k不满足核心网配备规定，经确认，核心网规定minGBR值必要不不大于40，于是将基站侧maxGBR值改为256；再次拨打volte电话，专用承载建立成功。能正常通话；如图所示：
所觉得了保证Volte语音电话能正常拨打，需打开QCI=1开关，切配备不不大于核心网规定maxGBR值。

3.4 QCI=2下maxGBR配备过小对视频电话有什么影响？

答：基站侧打开QCI=1及QCI=2开关，并将qciTab2maxGbrDl及qciTab2maxGbrul均设立为100k，拨打Volte视频电话,QCI=1专载成功建立，但QCI=2专用承载未建立，视频电话呼喊失败。如下图所示：
怀疑为qciTab2maxGbr配备过低，未能达到视频电话保障最低规定，经查证，核心网规定maxGBR值需不不大于512k，通过后台修改qciTab2maxGbr值为2048之后，再进行Volte视频电话拨打，能正常进行视频通话，如图所示：

因此Volte视频电话，需同步打开QCI=1.QCI=2开关，且maxGBR值需配备不不大于核心网规定值方可正常通话。

3.5 HSS参数设立与否会对eSRVCC产生影响？

答：HSS参数设立不恰当也许会导致无法执行eSRVCC。正常eSRVCC流程如下：

以现网测试发现某个案例为例，无线环境满足切换条件，UE却并没有执行切换，直至SINR过差发生掉话。通过度析log发现，UE未触发eSRVCC原由于，eNB没有下发eSRVCC有关测控消息。

更换HTC测试终端发现，SIM卡尾号为19终端可收到eNB下发测控消息并正常eSRVCC，而SIM卡尾号为55终端无法收到eSRVCC测控消息，以此排除终端因素。

正常重配备信令中eSRVCC测控消息如下，SIM卡尾号为55终端无如下消息。

GSM频点信息

A2事件及B2事件：

对比19、55两部终端能力信息，发现eNB收到UE Capability Information信令完全相似，且FGI第9位、第23位设立为1，表达终端支持eSRVCC（依照3GPP 36331 B.1 Feature group indicators规定，比特位9为EUTRA RRC_CONNECTED to GERAN GSM_Dedicated handover，比特位23为GERAN measurements，reporting and measurement reporting event B2 in E-UTRA connected mode，设立为1表达支持该功能）。

对比EMIL log发现，SIM卡尾号为19终端附着时，eNB收到MME下发Initial Context Setup Request中存在SRVCCOperationPossible ：possible字段，而SIM卡尾号为55终端确没有该字段，导致eNB以为UE不支持eSRVCC，因而不下发eSRVCC测控消息。

在附着流程中，测控消息下发前，UE会通过上发NAS：Attach Request进行信息交互，其中包括UE能力有关信息。对比两部终端上发Attach Request信令，成果发现，Attach Request中除随机个性化参数不同外，其她参数完全相似，且MS NETWORK CAPABILITY (OPTIONAL)中SRVCC to GERAN/UTRAN capability字段设立为1，表达UE支持eSRVCC。

由上可知，UE无论是与eNB还是与MME交互过程中，不存在终端能力上报差别， 判断应当不是终端问题，怀疑与否为SIM卡自身问题。对调两部终端SIM卡发现，问题会随着尾号为55SIM卡，与终端无关。

联系HSS工程师核查SIM卡参数，发现尾号为55SIM卡Session Transfer Number参数为空，此字段为eSRVCC切换时核心网一种标记初始值。若字段为空，则表达不支持eSRVCC。

重新设立尾号为55SIM卡后，问题消失。

3.6 地下车库-115场景eSRVCC优化参数如何设立？

答：地下车库-115场景下，参数采用初始配备1，A2判决门限为：LTE<-110dBm，B2判决门限为：LTE<-120dBm，GSM>-85dBm。UE进入地下车库，当LTE信号低于-120dBm时触发B2事件，但在1秒内RSRP由-120dBm减少至-139dBm如下，SINR由-2dB减少至-14.7dB如下，无法完毕eSRVCC流程，导致信号恶化掉话。UE触发B2时信号截图如下：

UE掉话时信号截图：

调节B2判决门限，将B2 LTE门限由-120改为-116，发现成功率有大幅度提高，成功率不不大于70%。

分析log发现，该场景UE会占用PCI=33、34两个社区，当占用PCI=34社区时，与邻区PCI=115社区MOD3冲突，SINR差导致无法及时完毕eSRVCC切换。

邻区列表如下：

将三个社区PCI由34/33/35调节为33/35/34，eSRVCC切换成功率达90%以上。

3.7 RoHC与否应当启用？

答：RoHC通过压缩IP包头方式，在VoLTE顾客较多时，提高了空口传播效率。

1）RoHC技术

仅对QCI=1业务有效
包头压缩支持IPv4和IPv6格式

支持如下格式压缩(3GPP R8):
●0x0000 ROHC uncompressed (RFC 4995)
●0x0001 ROHC RTP (RFC 3095，RFC4815)
●0x0002 ROHC UDP (RFC 3095，RFC4815)
以上格式需要具备VoLTE能力终端支持

2）RoHC实现

高标清理论速率计算

RoHC理论速率计算

3）RoHC外场验证测试

由以上分析可看出，标清AMR压缩比为51.39%，高清AMR压缩比为65.35%，建议全网启动RoCH。

3.8 VOLTE下DRX模式与普通LTE下DRX模式有何不同？

答：DRX分两种，一种是IDLE DRX，就是当UE处在IDLE状态下非持续性接受，由于处在IDLE状态时，已经没有RRC连接以及顾客专有资源，因而这个重要是监听呼喊信道与广播信道，只要定义好固定周期，就可以达到非持续接受目。但是UE要监听顾客数据信道，则必要从IDLE状态先进入连接状态。而另一种就是ACTIVE DRX，也就是UE处在RRC-CONNECTED 状态下DRX，可以优化系统资源配备，更重要是可以节约手机功率，而不需要通过让手机进入到RRC_IDLE 模式来达到这个目，例如某些非实时应用，像web浏览，即时通信等，总是存在一段时间，手机不需要不断监听下行数据以及有关解决，那么DRX就可以应用到这样状况。

ACTIVE DRX基本机制是为处在RRC_CONNECTED态UE配备一种DRX cycle。DRX cycle由“On Duration”和“Opportunity for DRX”构成：在“On Duration”时间内，UE监听并接受PDCCH（激活期）；在“Opportunity for DRX”时间内，UE不接受下行信道数据以节约功耗（休眠期）。在大多数状况下，当一种UE在某个子帧被调度并接受或发送数据后，很也许在接下来几种子帧内继续被调度，如果要等到下一种DRX cycle再来接受或发送这些数据将会带来额外延迟。为了减少此类延迟，UE在被调度后，会持续位于激活期，即会在配备激活期内持续监听PDCCH。其实现办法是：每当UE被调度时，就会启动一种定期器drx-InactivityTimer，在该时间内不会释放连接。drx-InactivityTimer指定了当UE成功解码一种批示初传UL或DL顾客数据PDCCH后，持续位于激活态持续子帧数。为了容许UE在HARQ RTT期间内休眠，每个DL HARQ process定义了一种 “HARQ RTT(Round Trip Time) timer”。当某个下行HARQ processTB解码失败时，UE可以假定至少在“HARQ RTT”子帧后才会有重传，因而当HARQ RTT timer正在运营时，UE没必要监听PDCCH。当HARQ RTT timer超时，且相应HARQ process接受到数据没有被成功解码时，UE会为该HARQ process启动一种drx-RetransmissionTimer。当该timer运营时，UE会监听用于HARQ重传PDCCH。drx-RetransmissionTimer长度与eNodeB调度器灵活度规定有关。如果是要达到最优电池消耗，就规定eNodeB在HARQ RTT timer超时之后，及时调度HARQ重传，这就也规定eNodeB为此预留无线资源，此时drx-RetransmissionTimer也就可以配得短些。drx-RetransmissionTimer指定了从UE期待收到DL重传子帧（HARQ RTT之后）开始，持续监听PDCCH最大子帧数。

LTE设备中容许ENodeB对不同QCI业务设立不同DRX PROFILE参数集，每一种参数集会涉及longDRX-Cycle (ms)、On Duration Timer (psf) 、DRX Inactivity Timer(psf)、DRX Retrans Timer(psf) 4个参数。UE在进行不同QCI业务时会执行最高优先级业务DRX PROFILE。

而在VOLTE业务下，QCI=1时延不能超过100ms，因此DRX cycle不能设立得过长，不能使用原先QCI=9long DRX-cycle设立（160ms），又由于UE在进行语音业务时，顾客正在通话时会每20ms产生一种采样包，宜为设立long DRX-cycle为40ms，为20ms整数倍。同步，由于语音业务都是20ms产生一种采样包进行下发，顾客在接受到语音数据包后并不需要持续监听，且由于longdrxcycle更变，DRXinactivityTimer也不适当设立过大（原QCI=9该参数为60/200（psf）），宜为设立为4（psf），以达到节电功能。

故VOLTE推荐DRX PROFILE为

3.9 如何实现2G迅速重选回4G？

答：处在2G网络终端可通过社区重新返回4G，而重选频点信息将由2G系统广播SI2quater消息提供。系统消息分为各种类型：type1、2、2bis、2ter、3、4、5、5bis、5ter、6、7、8、9、13。当终端处在IDLE态下，将用BCCH信道来收听系统消息1至4及7，8，13。

UE处在空闲时，系统消息以每8个复帧重复发送一次循环方式在主BCCH信道和扩展BCCH信道中发送。因而引入循环序号TC:

其中FN是TDMA帧号，以2716548个TDMA帧为周期循环编号，取值范畴（0~2716547）；(FN/51)是TDMA帧号对一种复帧长度整除，可以拟定帧号为FNTDMA帧所归属复帧编号；正如上文提到系统消息以每8个复帧重复一次循环方式发送，(FN/51)%8是复帧编号对8求模，可以拟定该复帧在以8个复帧为周期循环中位置；因而TC表达特定系统消息在循环中第几种复帧中发送。 一种复帧长度为235ms， 8个复帧周期时长为1883ms，因此系统消息下发最短间隔为8个复帧时长1883ms。 各种系统消息发送循环号TC和相应得发送信道如下表所示：

从上表可以看出，SI2Quarter在BCCH Norm当TC=5或4时发送，或者在扩展BCCH(BCCH Ext)当TC=5时发送。如果BCCH Norm上发送SI2Quarter，会和其她系统消息存在较大发送碰撞，需要进行轮流发送。由于SI2queter消息提供内容较多，必要分多条消息发送，这样一来，发送社区重选需要多条SI2quater消息将消耗大量不拟定期间。

以SI2quater发送机制为例，SI2quater分6条消息下发，理论最短下发完毕时间为1.883×6=11.298秒，但实际中社区重选所需时间远不不大于这个值，据下图可以看出，从终端完毕RAU进入IDLE态到开始执行社区重选，需要约45S时间。

从信令上看，是由于SI2quater消息与SI13消息均在BCCH Norm同一种TC上发送，由此产生了冲突，在这种状况下，需要SI2quater消息与SI13消息周期间轮流发送，这样一来每次冲突将导致一种周期(1883ms)等待时间。

由上述分析可看出，由于SI2quater与其她系统消息发送冲突，将引起大量发送等待时间，这样一来完整SI2quater消息发送时间将大大增长。在BCCH Norm上发送SI2quater消息时，很有也许会与其她系统消息发生冲突，而BCCH Ext上发送SI2quater消息将不存在这种状况，这样一来发送完整SI2quater消息时间将大大减少，终端由2G重选回4G速度也会随之提高。因而，可以通过设立在BCCH Ext上发送SI2quater消息来加速2G重选回4G过程。

3.10 空闲态2G到4G互操作是如何实现？

答：GSM结束通话后，若终端支持自主返回4G，则可直接返回4G；若终端不支持自主返回4G，且2G未广播4G邻区和重选参数，终端需通过2→3→4重选返回LTE，网络侧应注意配备3→4邻区；若终端不支持自主返回4G，但2G广播4G邻区及重选参数，终端也许通过2G->4G或2G->3G->4G返回4G。包括 “终端自主返回4G”以及“2G→3G→4G”两种方式。下表展示了2G/3G/4G互操作类型。

1. GSM->LTE重选（Idle态）

启测条件：常测
判决条件：LTE RSRP > LTERXM+LTERUT
通过SI2quater消息发送邻区频点信息。

2. TDSCDMA->LTE重选（Idle态）

若EarFcnPriority(LTE优先级) > Priority(3G优先级)，阐明TDS重选优先级相对LTE重选优先级较低，则对于TDS重选到LTE基于高优先级重选：

启测条件：常测
判决条件：LTE RSRP > EqrxlevMinRsrp+EThdToHighRsrp
当前现网将TDS启测条件设为始终启动测量，即只要满足判决条件后持续重选定期器设定期间就执行重选。

若EarFcnPriority(LTE优先级) < Priority(3G优先级)，阐明TDS重选优先级相对LTE重选优先级较高，则对于TDS重选到LTE基于低优先级重选：
启测条件：TDS PCCPCH RSCP < Qrxlevmin(s) +ThdPrioritySearch1
判决条件：
TDS PCCPCH RSCP < Qrxlevmin(s) + ThdServingLow &
LTE RSRP > EqrxlevMinRsrp+EThdTolowRsrp
TDSCDMA系统通过SIB19下发重选信息。

3.11 定期器对SRVCC切换到GSM失败影响（案例）

问题现象

按指引书设立了有关SRVCC参数、添加GSM邻区和LNHOG。
测试过程中发现当满足B2事件条件后，UE上报B2事件，但是UE始终未收到从EnodeB下发Handover Command消息，最后导致系统释放了本次通话，多次拨测均存在此问题。

问题分析

1、核查终端与否支持SRVCC
通过S1口注册信令发现终端（HTC M8）支持SRVCC功能，排除终端导致问题

2、通过Emil抓取拨测时段信令进行分析
从抓取信令可以看到UE上发B2后，EnodeB向MME发送了HandoverRequired，但是始终未收到Handover Command消息，导致UE长时间收不到Handover Command消息

3、核心网配合抓取有关LOG
从核心网抓取MMElog中可以看到MME已经收到了ENB上发HandoverRequired消息，并开始向MSC发送PS to CS Request并得到了响应，但是此后ENB却上发了一条Handover Cancel消息给MME（因素值为9），最后导致了MSC向MME确认了Cancel消息，切换流程终结。

4、再次核查emil log
再次分析emil log发现，ENB的确向MME上发了Handover Cancel消息，因素值为：radioNetwork ：tS1relocprep-expiry（S1重定位准备超时），初步鉴定为某一定期器超时

包具有Cancel消息SRVCC某些信令

并且通过度析发现，从HandoverRequired到HandoverCancel间隔1秒整，可以判断这个定期器设立值为1秒钟

5、定期器设立
参数核查发现，Timer T304 for interRAT GSM 与LTE向GSM切换关于，并且现网设立也为1s，尝试修改到8s中进行复测，问题依然存在

征询其她项目发现，尚有1个定期器参数Supervision timer for handover preparation to GSM 会对SRVCC切换有影响，查询现网发现该参数设立为1s，修改为5s后进行复测，问题恢复。

建议方案
修改Supervision timer for handover preparation to GSM 1000ms到5000ms

复测验证
多次复测，UE都能正常切换GSM网络。
MME信令

空口信令

参数总结
1、Timer T304 for interRAT GSM，用于ENB内部计算监督切换执行阶段时间，起于MOBILITY FROM EUTRAN COMMAND，止与RRC Re-Establishment，PS切换参数
2、Supervision timer for handover preparation to GSM ，用于通过S1切换到异系统MME响应准备阶段时间，起于：HANDOVER REQUIRED，止与HANDOVER COMMAND或者PREPARATION FAILURE，超时将终结或者取消切换流程，SRVCC参数

经验总结
1、此类问题优先核查终端性能、测试卡权限
2、核查基站有关参数
3、请核心网协助核查与否参数有误
4、通过空口、S1口实际信令与正常信令进行比对，找出信令异常某些再进行分析

附：正常SRVCC流程

3.12 RLC优先级优化

现象：呼喊建立与切换过程冲突，专载被MME释放。呼喊建立过程中专载建立与切换几乎同步发生，MME未收到NAS专载完毕消息导致释放专载，终端回答invite580（也有上发CANCLE状况），专载丢失形成未接通事件。

因素分析：QCI5设立RLC优先级为2，高于SRB=2(传送NAS层消息)配备为3. 导致NAS层3消息已经比MR要早，但是由于优先级比MR和SIP低，未及时发送。

优化办法：减少QCI 5优先级，保证SIP消息及时上传，修改后此类问题改进明显。

3.13 QCI 5 PDCP DiscardTimer时长优化

现象：终端业务建立过程中，浮现SIP信息传递丢失问题，导致收到网络下发INVITE500或者580等因素值释放。

因素分析：UE在无线信道较差状况下，SIP信令发送或接受不完整或者无法及时传递，导致IMS有关定期器超时而发起会话cancel。通过度析，由于QCI5pdcp 丢弃时长过小，在无线覆盖较差地方，上行时延会变大，容易导致QCI5信令丢包。

优化办法：
QCI5 PDCP DiscardTimer由300ms修改为无穷大

优化效果：
VoLTE无线接通率提高明显

3.14 SBC传播合同TCP重传次数优化

背景：被叫从2G返回4G后，主叫起呼，被叫一方面bye消息，紧接着接连收到多条上一次呼喊invite，被叫回答bye481\invite486\invite580，呼喊失败。

优化办法：爱立信SBC对TCP配备进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。

3.15 专载释放与切换冲突，通话结束未收到专载释放掉话

[问题描述]：在拉网测试过程中，通话挂机后，主叫上报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专载状况。

3.16 通话结束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消息未下发到手机。依照合同3