优化接入因子解决附着失败的案例分析李赟 肖明华 曹双 中国电信自贡分公司无线网络部 中国电信四川分公司无线网络部目 录1、问题描述32.1ATTACH流程42.2问题分析排查53、解决方案94、取得效果95、总结推广9摘要：ATTACH：完成UE在网络侧的注册，同时建立默认承载，为UE分配IP，建立UE和PDN GW之间的缺省承载，使UE的IP连接永远在线；UE在进行数据业务时，首先需要进行ATTACH，ATTACH成功与否，直接决定UE能否正常做业务。本案通过信令接入因子和呼叫接入因子的优化实现终端的正常附着；对于Attach Req之后并没有RRC Connection Req和MSG1消息时，可以尝试对这2个参数进行检查，查看是否为此参数配置过小而导致附着失败。1、问题描述 800M DT路测中发现RSRP&SINR较好的时候出现Attach失败。从高新区S305基站附近来回测试有无法正常驻留在800M-LTE基站小区的情况，查看其中一次LOG,如图1. 图1 Attach REQ消息UE会上发2次ATTACH REQ，但是第一次的REQ之后并无RRC Connection Request，2次的ATTACH REQ时间间隔为4S;为什么会出现此问题呢？正常来说应该ATTCH REQ之后UE会上发RRC Connection Request为什么并没有进行上发呢？正常一次ATTACH失败之后T3410应该为15S，为什么4S就会再次上发呢？如图2. 图2 Attach Request消息2、问题分析 2.1 ATTACH流程图3 Attach流程1. 处在RRC_IDLE态的UE进行Attach过程，首先发起随机接入过程，即MSG1消息；2. eNB检测到MSG1消息后，向UE发送随机接入响应消息，即MSG2消息；3. UE收到随机接入响应后，根据MSG2的TA调整上行发送时机，向eNB发送RRCConnectionRequest消息；4. eNB向UE发送RRCConnectionSetup消息，包含建立SRB1承载信息和无线资源配置信息；5. UE完成SRB1承载和无线资源配置，向eNB发送RRCConnectionSetupComplete消息，包含NAS层Attach request信息；6. eNB选择MME，向MME发送INITIAL UE MESSAGE消息，包含NAS层Attach request消息；7. MME向eNB发送INITIAL CONTEXT SETUP REQUEST消息，请求建立默认承载，包含NAS层Attach Accept、Activate default EPS bearer context request消息；8. eNB接收到INITIAL CONTEXT SETUP REQUEST消息，如果不包含UE能力信息，则eNB向UE发送UECapabilityEnquiry消息，查询UE能力；9. UE向eNB发送UECapabilityInformation消息，报告UE能力信息；10. eNB向MME发送UE CAPABILITY INFO INDICATION消息，更新MME的UE能力信息；11. eNB根据INITIAL CONTEXT SETUP REQUEST消息中UE支持的安全信息，向UE发送 SecurityModeCommand消息，进行安全激活；12. UE向eNB发送SecurityModeComplete消息，表示安全激活完成；13. eNB根据INITIAL CONTEXT SETUP REQUEST消息中的ERAB建立信息，向UE发送RRCConnectionReconfiguration消息进行UE资源重配，包括重配SRB1和无线资源配置，建立SRB2、DRB（包括默认承载）等；14. UE向eNB发送RRCConnectionReconfigurationComplete消息，表示资源配置完成；15. eNB向MME发送INITIAL CONTEXT SETUP RESPONSE响应消息，表明UE上下文建立完成；16. UE向eNB发送ULInformationTransfer消息，包含NAS层Attach Complete、Activate default EPS bearer context accept消息；eNB向MME发送上行直传UPLINK NAS TRANSPORT消息，包含NAS层Attach Complete、Activate default EPS bearer context accept消息。2.2 问题分析排查首先我们从终端和测试软件问题入手，初始怀疑是由于终端或者软件有问题导致RRC Connection Request没有上发，所以尝试更换终端及使用QXDM进行测试，之前使用终端为MF823更换为MF831，测试软件从CXT更换为QXDM，发现更改后还是会出现此问题，排除终端问题。如图4.图4 Attach REQ消息着手信令，查看ATTCH REQ消息，对比后发现：现场的Attach类型是2，而正常的attach的类型是1 。类型2是指EPS attach combined EPS/IMSI attach ，怀疑是UE联合附着在EPS和2/3G的核心网，在2/3G的核心网附着失败，最后在EPS附着成功。现场在QXDM中修改终端的Service Domain Preference配置CS+PS为PS,复测问题依旧存,如下图5图6：图5 Attach REQ消息详情图6 Attach REQ消息最后咨询厂家专家人员，了解到在该站点下发的SIB2消息中可以发现接入类的2个参数配置可能会导致此类问题：信令接入概率因子和呼叫接入概率因子，此两个参数在现网中设置为0.95，参数是在无线参数-LTE-FDD-小区重选配置-E-UTRAN小区重选中。如图7图8.图7 SIB2消息图8 信令接入概率因子&呼叫接入概率因子参数解释1、对主叫信令业务（比如attach）或主叫数据业务是否禁止的标识，对于接入等级09的用户选择01的随机数，若小于该配置参数，则允许发起呼叫接入，否则延迟一定时间后再发起接入；对于接入等级1115的用户，若其接入等级与参数“ac-BarringForSpecialAC”对应bit位至少有一个为0，则允许发起呼叫接入，否则同接入等级09的用户。目前网络应用初期，用户量少，接入控制不必太苛刻，因此该参数设置为最大值0.95。2、对于信令接入概率因子，如果启用了UE inactivity timer的话，主要针对手机在入网时attach和周期性TAU或正常的TAU的RRC；对于呼叫接入概率因子，则主要针对数据业务的主叫mo-data（如手机上网，ftp,短信等）。3、该两参数的主要目的是当小区内用户个数过高时，为避免过多用户同时发起连接建立这样的信令风暴对系统产生冲击，可应用该参数使终端发起呼叫离散化。4、该两参数的应用是在终端侧，一旦基站侧下发该参数，终端需要自觉按照协议规定进行操作，如果终端不实现，或恶意违反，则基站无法感知。配置为1时，表示SIB2中不下发该信令，即各种等级的UE可以不受限制的发起接入，该参数会影响 UE侧统计的 service request时延5、对应这2个参数还有信令禁止接入时间和呼叫禁止接入时间这2个配套参数，这2个参数默认配置都是4S，这样也就解释了为什么2次Attach之间是4S而不是T3410配置的15S。3、解决方案 修改信令接入概率因子和呼叫接入概率因子，从0.95调至1复测观察恢复正常。4、取得效果 如上操作后，现场测试单站测试和拉网Attach多次后未出现之前错误，如下图9：图9 恢复后的Attach交互流程5、总结推广 通过本案例，我们可以总结：对于接入时如果2个参数配置为0.95，那么不管是做什么业务都会有一定几率（5%）会出现接入失败，这样会对接入涉及到的时延类指标造成较大影响，比如：UE发送2次TAU更新才能成功，导致Fast Return时延过大等问题。网络初期默认设置为1，在流量密集区基于负荷问题而将此参数进行优化，预估容量和接入之间的一个平衡点，最大程度提升用户感知。此类问题的比较明显特征就是Attach Req之后并没有RRC Connection Req和MSG1消息。当碰到此表现时，可以对这2个参数进行检查，查看是否为此参数配置过小而导致附着失败。