1.1 VoLTE互操作类参数
参数英文名：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失败 对网络质量的影响： 增加该参数的取值，可以提高UE的RRC connection establishment过程中随机接入的成功率。但是，当UE选择的小区信道质量较差或负载较大时，可能增加UE的无谓随机接入尝试次数。 减少该参数的取值，当UE选择的小区信道质量较差或负载较大时，可能减少UE的无谓随机接入尝试次数。但是，可能降低UE的RRC connection establishment过程中随机接入的成功率
参数英文名：T304 For Intra-Lte 功能描述： 在“E-UTRAN内切换”和“切换入E-UTRAN的系统间切换”的情况下，UE在收到带有“mobilityControlInfo”的RRC连接重配置消息时启动定时器，在完成新小区的随机接入后停止定时器；定时器超时后UE需恢复原小区配置并发起RRC重建请求 对网络质量的影响： 用于系统内切换，该值设置过大会导致切换失败无法及时回退并发起RRC连接重建过程
1）参数英文名：T311 功能描述： T311用于UE的RRC连接重建过程，T311控制UE开始RRC连接重建到UE选择一个小区过程所需的时间，期间UE执行cell-selection过程。 对网络质量的影响： 设置值越大，UE进行小区选择过程中所被允许的时间越长， RRC Connection Reestablishment过程越滞后；如果该参数设置过小，可能在某些链路可以被挽救的情况下，却由于定时器设置不合理而进入IDLE状态，引起掉话，严重影响用户感知。 2）参数英文名：T301 功能描述： 在UE上传RRCConnection ReestabilshmentRequest后启动。在超时前如果收到UE收到RRCConnectionReestablishment或RRCConnectionReestablishmentReject，则定时器停止。定时器超时，则UE变为RRC_IDLE状态 对网络质量的影响： 增加该参数的取值，可以提高UE的RRC connection re-establishment过程中随机接入的成功率。但是，当UE选择的小区信道质量较差或负载较大时，可能增加UE的无谓随机接入尝试次数。减少该参数的取值，当UE选择的小区信道质量较差或负载较大时，可能减少UE的无谓随机接入尝试次数。但是，可能降低UE的RRC connection re-establishment过程中随机接入的成功率
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室分小区的邻区。
用户开机以后，首先完成EPC附着过程，建立QCI=9默认承载，附着完成以后，发起IMS注册过程和鉴权。在IMS注册流程中，先建立QCI=5的SIP信令承载。然后进行SIP的注册过程，当完成注册过程以后，就可以进行VoLTE呼叫了。若未建立QCI 5就无法完成终端与IMS的SIP注册信令的交互；若QCI5建立成功后，终端与IMS的SIP注册流程异常，也将会导致不能在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注册失败问题都与核心网相关，主要在于核心网侧排查解决。
答：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编码制式。
答：专用承载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与QCI9的MAX GBR后确定了问题原因。下图是QCI1修改前的参数（图中MAX GBR数值为换算后结果，下同）
下图为QCI9的参数：
核心网QCI1承载的MAX GBR改为150：
修改后QCI1:
由于VOLTE是VOIP业务所以速率的大小直接影响了通话的质量，速率太小语音业务就会出现卡顿和失真的现象。专用承载的最大保证比特率应该先由在不受限条件下的业务最高速率来确定。
答：当拨打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值。
答：基站侧打开QCI=1及QCI=2的开关，并将qciTab2maxGbrDl及qciTab2maxGbrul均设置为100k，拨打Volte视频电话,QCI=1专载成功建立，但QCI=2的专用承载未建立，视频电话呼叫失败。如下图所示：
怀疑为qciTab2maxGbr配置过低，未能达到视频电话保障最低要求，经查证，核心网要求的maxGBR值需大于512k，通过后台修改qciTab2maxGbr值为2048之后，再进行Volte视频电话拨打，能正常进行视频通话，如图所示：
所以Volte视频电话，需同时打开QCI=1.QCI=2的开关，且maxGBR值需配置大于核心网要求的值方可正常通话。
答：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卡发现，问题会伴随尾号为55的SIM卡，与终端无关。 联系HSS工程师核查SIM卡参数，发现尾号为55的SIM卡Session Transfer Number参数为空，此字段为eSRVCC切换时核心网的一个标识的初始值。若字段为空，则表示不支持eSRVCC。
重新设置尾号为55的SIM卡后，问题消失。
答：地下车库-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%以上。
答：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。
答：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 process的TB解码失败时，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=9的long DRX-cycle设置（160ms），又由于UE在进行语音业务时，用户正在通话时会每20ms产生一个采样包，宜为设置long DRX-cycle为40ms，为20ms的整数倍。同时，由于语音业务都是20ms产生一个采样包进行下发，用户在接受到语音数据包后并不需要连续监听，且由于longdrxcycle更变，DRXinactivityTimer也不宜设置过大（原QCI=9该参数为60/200（psf）），宜为设置为4（psf），以达到节电功能。 故VOLTE推荐的DRX PROFILE为
答：处于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帧号对一个复帧长度的整除，可以确定帧号为FN的TDMA帧所归属的复帧的编号；正如上文提到的系统消息以每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过程。
答：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下发重选信息。
问题现象 按指导书设置了相关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流程
现象：呼叫建立与切换过程冲突，专载被MME释放。呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。 优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。 原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施： QCI5 PDCP DiscardTimer由300ms修改为无穷大 优化效果： VoLTE无线接通率提升明显
背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481\invite486\invite580，呼叫失败。 优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
[问题描述]：在拉网测试过程中，通话挂机后，主叫上报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消息未下发到手机。根据协议36.413 中8.6.2.4有描述当eNB在触发X2切换时，eNB将不传递NAS消息。 [优化措施]：属测试软件统计问题，建议软件加以剔除该问题。
常见RRC连接建立失败原因有如下几种： 1. 弱覆盖区域发起接入； 2. 上行RACH问题； 3. TAU过程中寻呼失败： a）小区重选参数设置不合理 b）小区重选不及时 4. UE未能在最好小区上发起接入； 5. RS功率及功率分配参数问题； 6. 拥塞问题； 7. 设备异常问题。 RRC连接建立失败解决措施： 1. RF优化：消除弱覆盖、控制好越区覆盖 2. 优化TA边界，减小不必要的频繁TAU，尽可能将TA边界规划在低密度区域。 3. 优化问题小区重选参数：保证UE能尽快选择最优小区发起接入。 4. 修改随机接入及功率分配参数：譬如PRACH/PCCH/PDCCH/PDSCH/MSG3等的功率偏置。 5. 修改RS功率：确保满足预期的小区覆盖半径。
要实现VoLTE语音业务和视频业务需要建立以下承载组合： 语音业务载组合：SRB1+SRB2+2xAM DRB+1xUM DRB，其中，UM DRB的QCI=1，2个AM DRB的QCI分别为QCI=5和QCI=8/9。 音频业务承载组合：SRB1+SRB2+2xAM DRB+2xUM DRB，其中，2个UM DRB的QCI=1和QCI=2，2个AM DRB的QCI分别为QCI=5和QCI=8/9。 e-RAB建立失败排查方法如下几种情况： 1）弱覆盖导致E-RAB建立失败： a）上行覆盖差：排查是否存在上行干扰； b）下行覆盖差：排除UE 解调性能不佳的因素，可以通过新增基站、进行RF优化，调整天馈系统、RS功率优化等手段，改善弱覆盖区域的问题，提高无线信号的覆盖质量。 c）UE没有驻留到最优小区发起接入：对于这种情况需要提高同频小区重选的启动门限和速度，使得UE尽快驻留在最优小区，在最优小区发起接入。 2）UE/MME侧导致的E-RAB建立失败： a）UE设备异常导致的UE拒绝：通过升级HW/SW版本或者替换其他UE予以解决； b）针对MME侧导致的承载建立异常问题：排除无线信号覆盖质量问题和S1链路失败等问题后，通过分析eNodeB侧跟踪数据，对于MME导致的其他问题需要提交给CORE团队进行故障排查。 3）参数配置不合理导致E-RAB建立失败： 对于eRab承载异常导致的接入失败或掉话问题，首先检查参数配置，通过比较正常接入小区与接入异常小区的参数配置，确认两者是否存在不同；如有不同，确认是否会影响到UE业务接入或保持。 4）拐角效应： 实质上就是RF优化，调整天线或者RS功率等，使得目标小区的天线覆盖能够越过拐角，在拐角之前就能发生小区重选或者使当前小区的天线覆盖越过拐角，从而避免拐角带来的信号快速变化过程，来降低呼叫失败。 5）设备异常
下行覆盖问题是对DT测试获得的RSRP进行分析。常见的覆盖问题如下表所示：
弱覆盖问题：常见的弱覆盖会导致掉话、接入失败和切换失败等。 对于弱覆盖问题可以通过以下方法优化： 1. 首先明确当前的弱覆盖区域由哪些扇区的信号覆盖； 2. 根据网络拓扑结构和无线环境确定最适合覆盖该区域的扇区、并加强它的覆盖： ●排除主覆盖小区的硬件故障（例如：基带及射频器件故障、天馈系统驻波比告警等） ●提高主覆盖小区的RS功率 ●调整主覆盖扇区的天线下倾角或方位角 ●建议加站（并调整周边基站天线的方位角和下倾角）
当一个小区的信号出现在其周围一圈邻区及以外的区域时，并且能够成为主服务小区，称为越区覆盖。在实际网络覆盖中，由于无法精确控制无线信号的传播，因此或多或少都会存在越区覆盖的情况。 越区覆盖易导致 “导频污染”或引起主服务小区的干扰（包括邻区漏配、越区信号的迅速变化等），易导致各种异常事件。 对于越区覆盖一般优化原则，是在区域中已有合理的稳定信号覆盖的情况下、尽可能地控制越区覆盖的信号： （1）调整越区覆盖扇区的天线下倾角、方位角或RS功率 （2）上述方法无法实施，在孤岛区域形成的影响区域较小时，可以设置单 边邻区解决；在越区形成的影响区域较大时，在PCI不冲突的情况下，可以通过互配邻区的方式解决，但需谨慎考虑。
干扰从链路方向分为上行干扰和下行干扰，区分上行或下行干扰不同的表象，有利于快速定位问题和给出解决方案。 上行干扰：当上行链路受到干扰的时候，UE的发射功率通常较高（接近UE最大发射功率），而且基站侧测得的RSSI偏高。上行干扰问题通过检查各个小区的底噪进行判断。如果某一小区的底噪过高，并且没有与之相当的高话务量存在，则确认存在上行干扰问题，分析干扰原因并解决。 当下行链路受到干扰的时候，UE测得的RSRP较好、但是SINR偏差的情况，确认为下行干扰问题，分析干扰原因并加以解决。
切换失败将影响掉话率、MOS等关键指标。切换优化是一个长期的持续性的工作，需要做好覆盖优化和邻区优化，而不是靠个别参数的调优或启用某些特定功能，就能有较大幅度的提高或改善，需要不断的做精做细。 切换问题优化可以通过以下方法开展： 邻区优化需要重点关注漏配邻区的问题。 切换参数优化：涉及同频/异频/异系统邻区是否完善、邻区参数是否正确、切换参数是否合理或漏配等，需要纳入日常性的核查与优化工作中。 通过RF手段优化切换问题，关键在于控制切换区的位置和长度，并尽量保证在切换区里参与切换的信号强度能够平稳的变化，通过调整天线方向角和下倾角来改变切换区的位置和信号分布，优化时要根据实际的环境加以调整。 案例：异频邻区漏配导致掉话 现象：终端满足切换条件后上报系统内异频的测量报告，基站在收到目标PCI为未知测报（即:小区已配置的邻区中不包含该PCI），则基站立刻进行异频重定向流程，下发RRCConnectionRelease，原因为异频重定向，从而产生掉话事件。 分析： 1. 服务小区频点为38350，从重配消息中可以看到，其已配置的频点为37900的邻区中不包含PCI5的邻区，见图：
2. 满足切换条件后，终端上报测量报告，目标PCI为5，见下图：
3. 基站收到测报后，立即下发RRCConnectionRelease，原因为指向37900频点的重定向，重定向后产生了掉话，见下图：
解决方案：此类掉话可通过完善漏配的邻区或关闭异频重定向（关异频重定向需要做DV表关闭）加以解决。
eSRVCC切换成功率与G网邻区配置准确性和合理性有直接关系，对eSRVCC优化建议如下： 1）在初始配置阶段，可以参考CSFB邻区配置，虽然CSFB仅仅配置频点，未具体定义哪个具体小区，但是CSFB在外场经历了长期的优化，相对而言邻区设置比较合理。但要确保邻区的准确和完善，比如配置的G小区不合理，上报的G网小区满足不了B2异系统门限（GSM）而导致切换失败。 2）系统间邻区关系配置，建议定期结合GSM规划数据更新eSRVCC邻区定义，核查G网小区参数是否与现网一致，2G邻区相关的参数配置要正确，如BSIC参数错误，频点错误等。 3）核查邻区同频同BSIC情况，如发生此类问题，需要及时协调GSM侧优化调整。结合测试进行补充、删除不合理邻区关系，此项工作为日常优化工作重要组成部分。 4）根据不同场景设置合理的切换参数。eSRVCC异系统门限设置不合理会导致过早切换到异系统、来不及切换到异系统等问题，容易引发通话质量下降、掉话、重定向等事件发生，可以根据具体环境验证最佳取值（需注意：若A1门限配置过低，易导致删除B2事件，不触发eSRVCCC切换）。 案例：GSM邻区信息配置错误无法触发eSRVCC切换 现象：在某次VoLTE语音业务路测中，因LTE小区外部GSM邻区网管参数配置与实际不一致而导致eSRVCC切换失败，终端掉话并重定向到GSM网络。 UE测量满足B2条件并上报B2测量报告，在B2测量报告中GSM邻区为BCCH 512，BSIC 12（NCC 01、BCC 02 ），如图所示：
正常情况下，eNB收到该B2测量报告并判决下发mobilityFromEUTRACommand消息给UE，让其切换到该GSM邻区，但实际上网络下发的是RRC Connection Release消息（如下图）使UE重定向到GSM小区，终端掉话：
通过核查网管中该G网邻区参数配置，发现该邻区BSIC配置为7，与实际UE测量的BSIC 12不一致，修改该G网邻区BSIC为12后，复测可正常切换到该小区，掉话解决。 |
|
|
来自： 昵称29060005 > 《待分类》
