VOLTE案例PPT课件

各省上报VoLTE无线案例情况,10月份，山东、河南、广东、浙江、福建、广西、天津、上海、江苏、安徽等10个省公司上报了29个VoLTE无线案例。,VoLTE切换失败导致的掉话福建公司9月份案例,问题描述：诺基亚基站开启QCI1DRX情况下，在eNodeB内的不同小区切换，切换成功率只有96%左右，导致VoLTE掉话。,问题分析：1、UE已经在源小区收到切换命令，但是在目标小区随机接入失败，最终导致掉话。2、抓取DRX开启下的研发Log发现，当MGS3的HARQ反馈为NACK时，本应触发HARQ重传机制，但是由于软件bug，错误认为UE处于DRX的sleep状态，未能重传MSG3消息，导致UE在目标小区接入不成功，发生掉话。3、只有当DRX打开时，软件才会错误的计算UE处于DRX的sleep状态，切换失败。DRX关闭时，HAQR反馈为NACK后软件能正常的保证重传。,问题解决：基站软件bug，RL55MP1.0版本已解决此问题。升级后，福建公司复测未在发现此问题。,QCI1的RLC传输模式配置不同导致未接通广东公司9月份案例,问题描述：UE在同站异小区之间切换时，eNB下发的RRC重配消息里有对专载进行释放，导致呼叫建立失败。问题分析：1、主叫在PCI为226小区起呼（RSRP：-66，sinr：23），1s后成功的建立专载，在建立专载请求的RRC重配消息里QCI=1的RLC设置AM模式2、建立完专载后，主被叫都发生了从PCI226到同站PCI227的切换，在切换请求对应的RRC重配消息里都对专载QCI1进行释放3、查看PCI227的VoLTE参数配置，QCI1的RLC是UM模式4、由于两小区QCI=1的RLC模式设置不同，导致的QCI1语音切换失败，专载丢失，以至于主叫没有收到被叫的invite200，就上发Cancel，呼叫建立失败问题解决：根据协议要求，QCI1的传输模式为UM。对全网VoLTE参数进行核查，确保所有小区的QCI1传输模式为UM。,大话务场景下频繁发生未接通广东公司9月份案例,问题描述：大话务场景下，出现较多的未接通事件。通过分析Log发现，主叫向网络侧发了invite请求，但没有收到网络侧下发的100trying消息，之后终端直接上报CANCEL，导致未接通。问题分析：1、主叫起呼后发起RRC连接请求，但是RRC连接失败，层3信令显示RRC被拒。之后一直发RRC连接请求，RRC连接依然被拒。最后RRC连接释放掉了，释放原因other。2、由于话务量高，RRC接入成功率只有51.577%，判断是基站侧的问题影响RRC接入。,问题解决：开启基站设备的大话务量参数配置，主要包括开启异频负载均衡调整、关闭DRX等。,爱立信设备参数设置问题导致无法触发eSRVCC切换,典型案例介绍（1）,广东公司10月份案例,问题现象：苹果公司在广州爱立信网络测试过程中，存在部分室内服务小区在信号变差后，上报大量的Measurementreport，但是网络侧一直不下发切换命令最终导致掉话。,问题分析：1、由于ServiceTriggeredMobility失效，导致下发B2测量如下：即出现B2-1=-128，B2-2=-852、分析LOG有B2触发的报告中，可以看到LTE信号RSRP强度为-134dBm，信号非常弱，这样会出现上行信号较差，eNB有概率接收不到B2报告，从而在终端侧无法触发eSRVCC切换的现象3、从A2测量报告中可以看到LTE无线信号RSRP在-110-115之间，UE不断上报A2报告，而没有达到B2门限，所以不会上报B2报告，故没有触发eSRVCC。,问题解决：激活ServiceTriggeredMobility后，eSRVCC门限为B2-1=-116，B2-2=-85，问题解决。,华为基站参数设置不合理引起eSRVCC切换掉话,典型案例介绍（2）,安徽公司10月份案例,问题现象：eSRVCC验证测试，从地下车库一层移动至地下车库三层，LTE信号逐步变差，但一直未触发eSRVCC切换，最终导致掉话。,问题分析：1、eSRVCC的默认A2测量门限为-105dBm，B1的门限为-95dBm，即当LTE弱于-105dBm时，GSM强于-95dBm时，即可进行eSRVCC切换。测试时完全可以满足该门限。2、在出现问题时ENODEB向终端下发的测量控制消息中没有关于2G的测量，因此基站根本不会进行到2G的测量，更加不会进行切换。3、4G异频下发的频点数默认值为7（最大只能测量7个异频频点），下发频点的顺序为4G/3G/2G。由于测试站点已配置5个LTE异频、3个TDS异系统邻区，无法下发2G频点。,问题解决：通过指令“MODCELLUEMEASCONTROLCFG”，将小区异频异系统测量对象最大值将修改为12后，基站除下发LTE异频和TDS异系统测量频点外，还可下发2G频点，成功实现eSRVCC。,典型案例介绍（3）,北京公司10月份案例,TAU与QCI1建立冲突导致未接通,问题现象：主叫发生X2切换，收到携带QCI1建立消息的RRC重配置消息后，没有立即回激活QCI1的上行直传消息给MME，而是先发送了TAU消息，导致在eNB和MME侧QCI1承载建立状态不同，MME认为QCI1没有建立成功，导致未接通。,问题分析：1、主叫X2切换成功后，收到QCI1建立消息，并且答复了RRC重建完成。终端首先发送TAURequest的上行直传消息，显示有3个EPS承载，随后再发送包含QCI1承载建立完成的上行直传消息。2、eNB收到RRC连接重配置完成消息，并且发送ERABResponse消息给MME，终端和eNB都认为QCI1承载已经建立。3、MME没有收到终端发的激活QCI1承载接收的上行直传消息，认为QCI1没有建立成功，回复的TAUAccept中只包含2个EPS承载。4、TAU成功后，MME收到UE发送的QCI1激活消息，在createbearerresponse里回复成功。由于eNB已经存在QCI1承载，答复失败，原因：Multiple-E-RAB-ID-instances，产生未接通。,问题解决：需要在规范中明确，UE发送QCI1建立的RRC重配置消息后，先发送激活QCI1的上行直传消息给MME，再发送TAUrequest。,典型案例介绍（4）,福建、浙江公司10月份案例,华为MATE7终端大唐基站下语音不清晰,问题现象：在大唐ENB下进行VoLTE语音呼叫测试，华为Mate7测试终端做VoLTE语音呼叫时，出现语音不清晰的问题；其他终端均正常题。,问题分析：1、ENB侧抓取S1口数据包，从IMS下发到ENB的S1口RTP包均是连续的。同时通过ENB侧观察PDCP下行空口SDU发包数在测试期间发包正常，PDCP下行空口SDU丢包数为0，确认ENB接收和转发无丢包2、华为Mate7测试，ENB发给UE的RTP包间歇性丢包，几乎每隔8个连续包，就会丢弃3-8个包。其他终端无RTP包连续丢包，判断是华为Mate7终端RTP语音包间歇性丢包导致语音不清晰3、根据wireshark抓包数据分析，ENB侧的处理流程符合RFC3095及RFC4815协议规范，排除ENB侧问题。ENB侧尝试关闭RTP层压缩（关闭头压缩0X0001算法）后Mate7通话正常。初步结论是华为Mate7对ENB的头压缩算法兼容性有问题。注：头压缩算法支持0X0001和0X0002压缩；Profile0 x0001是支持IP/UDP/RTP协议头压缩，Profile0 x0002是支持IP/UDP协议头压缩，是对Profile0 x0001的补充，优先级较Profile0 x0001低,问题解决：1、可采用关闭0 x0001头压缩算法的方案临时解决。2、最终解决方案是Mate7终端升级版本。华为已有补丁，计划近期测试。,典型案例介绍（5）,浙江公司10月份案例,MME与eMSC协议版本不一致导致eSRVCC掉话,问题现象：在台州VoLTE测试时发现，当发生eSRVCC（LTE-2G）成功切换到2G后，出现提示音“您所拨打的号码有误，请查证后再拨”，双方通话中断。,问题分析：1、查看无线侧信令，eSRVCC切换成功说明无线侧网络正常。2、eSRVCC刚切换到2G后通话异常，怀疑是eMSC的问题。3、协议规定MME需向eMSC发送STN-SR字段，诺西MME发送R10协议版本格式的stn-sr字段，而华为eMSC默认按照R10以前协议版本识别STN-SR字段，所以无法识别，导致eSRVCC刚切换到2G后通话异常。,问题解决：该问题可以由诺西MME修改STN-SR协议版本格式,也可以由eMSC做修改。在此修改eMSCSTN-SR协议版本格式，使得eMSC针对所有诺西MME以R10协议版本格式识别STN-SR字段后，测试eSRVCC正常,1-呼叫建立专载时，PGW通过CCR-U上报RESOURCESLIMITATION,问题描述：主被叫为HTC终端，都在LTE覆盖下，发起VoLTE语音呼叫。多次测试发现，主被叫开关机后的第一次呼叫总是成功，但是多次呼叫后，就会出现主叫呼叫马上自动挂断，被叫无任何反应的现象。出现故障后，再次尝试呼叫，问题一直存在，除非重新开关机。,问题分析：抓包可以看到，PCSCF收到被叫发来的183消息，通过AAR触发PCRF建立专载，PCRF发送RAR给PGW，PGW给出了正确响应。但是马上发起了CCR-U消息，消息中携带Charging-Rule-Report/Rule-Failure-Code:RESOURCES_LIMITATION(5)。,从PGW的单用户跟踪消息看，PGW收到RAR之后，并没有向SGW发送任何建立专载的消息。跟踪消息如附件：,进一步可以看到，问题发生前的呼叫结束后，PCSCF收到BYE消息后，向PCRF发送STR消息，但是PCRF返回了Result-Code:DIAMETER_UNKNOWN_SESSION_ID(5002)。,问题原因：分析发现，原因是第一次PCSCF通过LDRA发送STR消息中，携带了正确的hostname：FZM01PCRF01BNK.，但LADR没转发给PCRF。第二次PCSCF以小写的hostname：发送，LDRA正常转发给了PCRF，但是由于hostname是区分大小写的，所以PCRF以Result-Code:DIAMETER_UNKNOWN_SESSION_ID拒绝了STR消息，导致没有正常释放语音专载。再次呼叫时，对于该用户PCRF再次发送RAR给PGW，带有相同的charging-rule-name及QOS及TFT。此时PGW根据协议，会修改前面的专载，将TFT里的filter累加到原先的TFT里，修改后的专载可以正常用于语音通话。但是当重复拨打4次后，TFT里的filter达到最大值16后，PGW就会发送CCR-U携带RESOURCES_LIMITATION给PCRF，导致语音呼叫失败。,问题解决：对于LDRA没有正常转发STR的问题，经查是由于一台LDAR上缺少相关配置导致的，在该LDRA上添加配置后，该问题解决。呼叫失败的问题不再出现。,1-呼叫建立专载时，PGW通过CCR-U上报RESOURCESLIMITATION,2-MME处理NegotiatedQoS不正确，导致视频呼叫失败,问题描述：终端做视频呼叫测试时，有时候出现主叫呼叫后马上断掉，被叫无任何反应的情况,问题分析：从抓包分析，可以看到有以下过程及问题：1.在456消息里，PCRF向SAEGW发送RAR，指示SAEGW为语音和视频建立专有承载。在RAR消息里，视频QCI=2在前，音频QCI=1在后。2.在464消息里，SAEGW向MME发送CreateBearerRequest，视频QCI=2在前，音频QCI=1在后。3.在468消息里，MME向ENB发送E_RABSetupRequest。QCI=2的EPS的QOS和NegotiatedQoS里的上下行速率相差极大（事实上NegotiatedQoS跟音频专载qci=1的相同）。,3-三星终端语音视频呼叫失败,问题描述：TAS完成补丁安装后，三星S5终端无法进行语音、视频呼叫。问题分析：跟踪信令发现，TAS回500Error，Reasoncode800（Preconditionisnotsupportedattheterminatingside）。报case后研发给出的结论为三星S5终端发出的INVITE消息不符合规范（3GPP24.229），即终端发出的INVITE带了Require：precondition，如右上图1示。未来的终端将不会，携带这样的消息格式，所以新的补丁不再对该消息格式进行兼容。,9月12日CMRILab（TAS补丁版本与FJMCC一致）用另一种软件版本的三星S5终端做了语音和视频呼叫，结果是正常的。从北京实验室的消息来看，终端发出的INVITE符合3GPP24.229，即没有Require：precondition。如右下截图所示：,问题解决：升级三星S5终端的软件版本,4-触发异频测量时DRX-Config不下发,问题描述:VoLTE关键无线参数配置外场测试时发现，在RSRP=-110-120dbm时RRCConnectionReconfiguration中没有下发DRX-Config，而在RSRP=-85dbm时RRCConnectionReconfiguration中有携带DRX-Config。,问题分析:VoLTE关键无线参数配置外场测试时发现，在RSRP=-110-120dbm时RRCConnectionReconfiguration中没有下发DRX-Config，而在RSRP=-85dbm时RRCConnectionReconfiguration中有携带DRX-Config。先后对比两种无线覆盖场景下的具体消息上区别：a.在RSRP=-85dbm时，正常携带DRX-Config消息；b.在RSRP=-115dbm时，则不带DRX-Config信息；通过分析判断，这两种场景下具体区别为覆盖电平值差异，在电平值较好时则下发正常，电平值较差时则下发异常，可能涉及该异常现象为触发某种门限开关导致，刚好该门限开关在-85dbm-115dbm之间，通过现场测试log分析并从后台提供的scfc文件比对提取后，发现当电平值在小于-100dbm时，会触发异频测量控制，这时候发现基站下发的RRCConnectionReconfiguration消息里不包括DRX-Config消息。当电平值大于-100dbm时，则显示正常包含DRX-Config。因此导致该异常现象的可能为异频测量控制启动。,问题原因：为什么启动异频测量控制时会触发基站侧对终端隐藏DRX-Config消息？通过与研发人员咨询后得知，这是诺基亚当前产品的处理策略所致，当终端触发异频测量时，则默认其终端所处的无线环境较差，需要通过切换至异频/异系统来保持业务连续性。从处理策略上考虑，此时终端省电的处理优先级较低，为了保障终端在弱场下的接收性能，网络侧即不下发DRX-config来让终端处于非DRX状态来提升整体性能表现，保证网络指标。因此针对测试场景，现网异频测量门限Thresholdth2interFreqforRSRP=-100dbm的设置相对太保守，这也导致了在集团要求的-115dbm附近的测试环境下，过早触发异频测量门限，以至于网络侧认为终端已经处于弱场下才不发DRX-Config。,问题解决：将异频测量门限从原来-100dbm修改至-120dbm后，问题解决。,4-触发异频测量时DRX-Config不下发,5-QCI5开启profile1后HTCM8t终端主叫异常,问题描述：测试终端HTCM8t进行VoLTE业务时无法正常主叫，重启终端后马上拨打可以正常主叫，挂断后连续拨打可以正常主叫，但挂断后等待13分钟主叫失败，重启手机，等待35分钟主叫失败；连续拨打过程多次拨打也会出现异常，出现异常后后续无法主叫，但华为mate7未发现异常。,问题分析：1、将终端HTCM8t拿到华为和大唐区域进行VoLTE业务时均未发现异常。UU口信令显示主叫一直在发invite消息，但被叫无任何响应。2、基站侧进行数据抓包，抓到UE上报的相关SIP信令，如左图：,3、诺西的核心网MME上也抓到了相关SIP信令，如下图：但华为的IMSSBC上却没有收到INVITE消息。,从上述现象看，应该是MME到IMSSBC过程中将INVITE消息丢了，或者INVITE消息有误IMSSBC无法解析。由于这款终端在本地市的其他厂家区域测试VoLTE均是正常的，我们更怀疑是后者，将基站配置参数与其他地市的数据进行对比，发现QCI=5的ROHC格式Profile0 x0001是打开的，而其他地市ROHC格式Profile0 x0001是关闭的。尝试将该参数关闭进行VoLTE业务，可以正常主叫。,问题原因：后经研发确认这个问题是HTC与基站对QCI5开启Profile1的处理不一致导致。（1）基站：对于QCI5开启profile1，按照profile0不压缩处理。（2）HTC：对于QCI5开启profile1，按照profile2，压缩UDP/IP处理。最终，会导致HTC发出的SIP信令都是压缩的，到基站无法解压缩，IMS上也就识别不了如invite的这些SIP信令。当重新启动HTC后，ROHC上下文被重置，然后会发送基本无压缩的初始报文，可以打通。中间间断几分钟，HTC又开始发出压缩的SIP信令，基站无法正确解压缩，又出现上面说的问题。而华为Mate7与基站处理方式一致，按协议标准，可正常主叫。,问题解决：关闭QCI5的profile1，问题解决，测试终端HTCM8t进行VoLTE业务时主叫正常。,5-QCI5开启profile1后HTCM8t终端主叫异常,6-TCU单元故障导致eSRVCC切换后语音大概率出现单通,问题描述：在VoLTE试商用测试过程中发现后台统计mos值部分为空（发生esrvcc后），经过验证发现发生esrvcc切换成功后语音未接续，出现单通的情况概率基本为50%左右。信令上看无异常，此刻实际通话已显示为单通。,问题分析：首先核查目标站点状态，涉及切换的LTE/GSM站点状态正常，均无告警，查询站点日常KPI指标，并无其他异常，后续在周围其他站点下进行同样eSRVCC切换，也出现类似情况。排除站点故障造成的异常；而后核查其无线环境覆盖，切换后的GSM站点覆盖良好，其Rxlev在-75dbm左右，因此该单通现象可能非无线环境导致。其问题可能与核心网侧有关，与核心网工程师进行联系抓包处理。问题原因：闭掉了TCU-0单元后，经测试后问题解决了。原因为原来的TCU-2单元故障，这时候TCU-0做为备份TCU接替TCU-2的工作，但TCU-0一样存在问题。这样才导致最终eSRVCC过去后出现单通状态。问题解决：闭掉TCU-0后，只有TCU-1工作。问题解决。,问题描述：VoLTE用户在QCI1DRX打开的情况下，在eNodeB内的不同小区切换，切换成功率只有96%左右，导致VoLTE掉话。,7-诺基亚基站版本问题导致VoLTE切换失败掉话,问题分析：在RL55站点下网格遍历的VoLTE测试中发现VoLTE掉话次数较多，掉话率高达20%左右，严重高于VoLTE的掉线率目标值2%。经分析一半以上的掉话都是由于站内切换失败引起的掉话。,如图:UE已经在源小区收到切换命令，但是在目标小区随机接入失败，最终导致掉话。,EmilLog也显示在由于随机接入失败引起的切换失败。,7-诺基亚基站版本问题导致VoLTE切换失败掉话,MACPS研发分析了现有的TTItracelog，未能找到rootcause。可能的怀疑点包括DRX功能无线链路原因MSG1消息解码。外场对比DRX开启和关闭的切换成功率对比。发现在DRX开启的情况下VoLTE切换成功率只有95.1%。,抓取DRX开启下的研发Log，经分析，如果上行MGS3的HARQ反馈为ACK时，目标小区接入能正常进行，切换成功。但当MGS3的HARQ反馈为NACK时，本应触发HARQ重传机制，但是由于软件内部计算偏差，错误认为UE处于DRX的sleep状态，未能有效的进行MSG3消息的重传，导致目标小区接入不成功，切换失败。由此看出，切换失败只发生在接入的HARQ反馈的NACK时，故比例约为4%。并且只有当DRX打开时，软件才会错误的计算UE处于DRX的sleep状态，切换失败。DRX关闭时，HAQR反馈为NACK后软件能正常的保证重传。切换失败只发生在VoLTE时，是因为VoLTE采用QCI1传输。QCI1配置的DRX周期较短，DRX计算错误切换失败就会发生。如果DRX的周期较长，即使计算错误，UE的DRX状态还是active，还是能够保证重传后切换成功。所以切换失败只发生在DRX周期较短的VoLTE测试中。,问题原因：基站版本LNT5.0_ENB_1407_555_03存在问题,问题解决：升级至校正版本LNT5.0_ENB_1407_556_47_89135后，站内切换与站间切换均恢复正常，问题解决。,9-eMSC上缺失了LTETA和GSMLAC的对应关系导致切换准备失败,问题描述：进行eSRVCC测试时，发现终端正常上发测量报告后，eNODEB向核心网发起切换请求后，核心网直接回复切换准备失败（失败原因为：目标EPC-enodeb失败）问题分析：该问题疑为华为eNB和诺西MME配合不当有关，在多个地市均发现类似现象且较为严重。无线侧异常信令如下：,进行联合抓包分析发现为eMSC上缺失了LTETA和GSMLAC的对应关系所致。,问题解决：全网统一添加LTETA与GSMLAC对应关系后，问题解决。,9-核心网和终端协商速率过低导致视频电话质量差,问题描述：终端发起视频电话业务，业务接通后发现黑屏、马赛克严重，语音通话质量良好。,问题分析：终端侧发起视频业务请求，主叫终端与被叫终端协商后的业务速率在UPDATE200信令中：,从SDP和H.264协议解释看，Profile-level-id决定了视频的类型和等级。其中第一个字节表示视频的类型，第三个字节表示了Level等级。H.264对视频业务Profile分类为：Baseline、Extended、Main、High、High10、High422、High444等，如下表：,每种Profile对应的ID号(十进制)如下表：,从UPDATE200信令得知：双方协商的Profile-level-id=42C01E。其中Profileid=0 x42，对应于十进制的66，表示Profile是BaseLine类型的；Level=0 x1E，对应于十进制的30，表示LevelNumber为3，与实时直播业务的标清Baseline的要求一致。从协议的要求看MaxVideoBitRate需达到10Mbps。实际核心网下发的激活EPS承载信令中，QCI-2对应的上下行的Maximumbitrate只有640K。按照核心网的配置，无法支持level1.3及以上等级的视频业务。,当终端协商的视频格式速率要求远大于核心网配置的业务QCI中的Maximumbitrate时，会导致视频业务质量严重下降，马赛克、黑屏等问题。,问题解决：核心网修改了测试SIM卡对应的Maximumbitrate参数为2Mbps后，视频业务的质量得到明显改善。,H.264对不同的Profile下边又定义了不同的level等级：,对应于业务应用中，推荐的Profile及level等级如下：,10-核心网和终端协商速率过低导致视频电话质量差,10-终端APN名称设置为空时，激活多条QCI9承载,问题描述：终端设置APN接入点名称为空，接入点协议为ipv4/ipv6时，终端发多条PDNconnectivityrequest，导致网络为该终端建立多条QCI9承载。问题分析：正常情况下，使用相同终端将APN接入点名称设置为cmnet，且接入点协议设置为ipv4/ipv6时，除终端attach过程时建立的ipv4，APN为cmnet的QCI9默认承载，终端还会发起APN为imsipv4/ipv6的PDN连接请求，最终网络将会给该用户建立一个ipv4APN为cmnet的QCI9默认承载和一个ipv6APN为ims的QCI5专用承载。而将终端APN接入点名称设置为空时，除终端attach过程时建立的ipv4，APN为cmnet的QCI9默认承载外，终端还会发起三次PDN连接请求，其中一条APN为imsipv4/ipv6的PDN连接请求，一条APN为空ipv4/ipv6的PDN连接请求，一条APN为空ipv6的PDN连接请求。最终网络将会该用户建立4个承载：一个ipv4APN为cmnet的QCI9默认承载；一个ipv6APN为ims的QCI5专用承载；一个ipv4APN为cmnet的QCI9承载；一个ipv6APN为cmnet的QCI9承载。相对比多出两条QCI9承载。网络为该用户多建立的默认承载，无论对无线网还是核心网都会增加一定的网络负荷。问题解决：在IMS注册时，终端部分选择APN接入点名称为cmnet的接入点进行接入，减少终端发起PDN连接请求数量，核心网部分需禁止为用户建立过多的承载，只需为用户建立ipv4APN为cmnet的QCI9默认承载，以及ipv6APN为ims的QCI5专用承载。,11.大唐610版本基站ERAB建立失败问题,问题描述：VoLTE测试期间，在运营中心(610版本)进行4G语音测试，发现偶尔会出现呼叫失败的情况。,问题定位：测试采用的是商用终端，为方便定位问题，测试过程中，EPC侧一直跟踪UE信令，通过EPC侧的信令中MME-UE-SIAP-ID(本次失败时为201330337)来对应到基站的CDL进行分析。通过MME-UE-SIAP-ID=201330337对应到CDL中，发现在16：02：16的时候核心网下发了ERABID=7的承载建立请求，基站判决为ERABID重复导致的失败：,此次的失败对应为CellUEID=178的终端，往上分析，在16：02：00的时候，EPC通知基站释放ERABID=7的承载，基站下发重配通知UE，但是由于空口的原因，基站并没有收到UE上报的重配完成，所以基站认为此承载释放失败，通过S1ERABReleaseResponse携带ERABID=7释放失败的原因值unspecified，来通知EPC次承载释放失败，同时也回复了S1NASNonDeliveryIndication指示下行NAS释放消息传递失败：,此时基站存储此ERABID被占用，没有删除承载信息。而后在16：02：16的时候核心网又要求建立一样的ERABID的承载的时候，基站判断承载已经存在，并回复MME消息S1ERABSetupResponse携带cause指示承载ID重复，ERAB建立失败。,问题原因：通过对比其他厂家的实现方式，以及和核心网的处理保持一致的原则，当空口原因导致的ERAB释放失败时，默认终端已经释放资源，需要基站回复核心网ERAB释放成功，当基站再一次收到核心网的ERAB建立请求时，即可以正常建立。由于需要修改相应的处理机制，需要基站版本来进行修改，此问题并入620版本完成。,问题解决：修改相应的处理机制，升级基站版本，此问题并入620版本完成。,11.大唐610版本基站ERAB建立失败问题,12.大唐E-RAB建立时延大,问题描述：日常监控VoLTE相关KPI，发现大唐E-RAB建立时延偏大约70ms，其他厂家30ms左右。,问题定位：ERAB建立时延分为初始ERAB建立时延与附加ERAB建立时延。初始ERAB建立时延统计起始信令节点为EPC给ENB下发InitialContextSetupRequest，结束信令节点为ENB给EPC回复InitialContextSetupResponse。初始ERAB建立过程中可能会有SMC过程、UE能力查询过程、第一次RRC重配过程。附加ERAB建立时延统计起始信令节点为EPC给ENB下发ErabSetupRequest，结束信令节点为ErabSetupRespone，过程中会有一次RRC重配过程。从KPI统计来看，初始ERAB建立时延较大，且初始ERAB建立次数相对附加ERAB建立次数要多，所以ERAB建立时延偏大问题的原因在于初始ERAB建立时延。从以下4个方面进行ERAB建立时延根本原因分析：1）KPI统计是否准确；2）分析是否基站内部处理时延引起；3）是否终端处理时延引起；4）是否空口处理时延引起。选取上街环岛1个用户数时段偏少的15分钟的CDL统计，按信令节点过滤手动计算ERAB时延建立，与KPI统计对比，基本一致，因此可以排除KPI统计不准确的原因。,继续分析CDL，以一次完整的ERAB建立过程为例。,从ENB收到初始ERAB建立请求（InitialContextSetupRequest），到ENB给UE下发SMC或UECapabilityEnquiry，这段时延为基站内部处理时延，从15分钟CDL的手工计算可以看出，此部分时延主要集中在5/10ms，及30/35ms，个别异常情况下处理时延会更长。且统计出的ERAB时延分布情况和基站处理时延相关性较大，因此基站内部处理时延是ERAB建立时延偏大的其中一个原因。,结合路测终端与CDL进行联合分析，从终端log看，在收到SMC和RRC重配均在15ms内回复了SMC完成和RRC重配完成，但是在基站侧看RRC重配完成下发后到收到RRC重配完成用了5个