室分优化常见问题及处理流程.docx

1 室分优化常见问题1.1 速率类问题1.1.1 路测类速率问题定位和优化方法 路测类业务定位流程 空口问题指标测试空口重点关注指标：RSRP、SINR、TM、RI、流数、PDCCH DL 、PDSCH RB number、MCS、iBLER、通道的平衡。一般而言，吞吐率由频谱效率、频带宽度、频带占用机会、误码率综合决定。在LTE系统中，频谱效率由MCS决定；频带宽度由分配的RB数决定；频带占用机会由DL grant决定；误码率主要考虑IBLER，HARQ重传以后，残留BLER通常较低，因此只考虑初次传输的BLER，也即IBLER。备注：DL/UL Grant理论值，FDD为固定值1000；TDD为配置的10ms内下行和特殊子帧/上行子帧个数*1000，TDD的特殊子帧计算为下行帧，录入：配比(DSUUD)，DL理论值为600，UL理论值为400。1. 下行速率的基本分析方法：（1）统计UE侧SINR vs THP：定点测试统计AVG SINR和吞吐率平均值。（2）判断用户的RB数和DL Grant是否调度充足，如果不充足，首先判断上层数据源是否充足，可以直接在Probe上查看，也可以采用MML命令DSP ETHPORT查看。（3）若DL Grant和RB数都是调度充足，下一步需判断下行IBLER是否收敛到目标值。目前下行的IBLER目标值一般为10%，即5%15%即认为IBLER收敛。可以直接在Probe上查看，也可通过M2000信令跟踪管理-用户性能监测-误码率监测观察。（4）如果IBLER收敛，可判断是否使用了双码字，我司UE可通过Probe查看用户的Rank Indicator和DL MCS。也可通过M2000信令跟踪管理-用户性能监测-信道质量查看UE上报的Rank值和调度的CQI。（5）如果上述都OK，可以查看下是否存在干扰，功率不平衡等现象，在Probe上可以直接查看（6）上述15步检查结果都OK的话，需要进行深入定位，深入定位需要在M2000上采集的数据。2. 上行速率的基本分析方法：一般而言，吞吐率由频谱效率、频带宽度、频带占用机会、误码率综合决定。在LTE系统中，频谱效率由MCS决定，MCS由SINR和IBLER决定；频带宽度由分配的RB数决定；频带占用机会由UL grant决定；误码率主要考虑IBLER，HARQ重传以后，残留BLER通常较低，但由于重传会影响传输的效率，进而影响RLC层吞吐率，因此只考虑初次传输的BLER，也即IBLER。上行吞吐率在大的面上主要也是受四个方面的影响，RB数/ul grant 不足，MSC阶数偏低、ibler 高、弱覆盖。 检查覆盖和干扰水平（查看RSRP、SINR等参数）下行覆盖采用SINR的PDF或CDF图形进行评估。如果SINR的分布较差，需要从RF优化的角度去提升SINR的分布，使之符合RF的验收要求。上行覆盖采用UE测量到的下行导频的RSRP（或路损Pathloss=下行RSRP-导频功率）作为覆盖的评估标准。UE测量到的RSRP是UE接收到的服务小区的下行导频RS信号质量，因此RSRP实际反映的是下行路损情况。一般情况认为，下行路损和上行路损是一致的。1) RSRP异常： 定点测试时，建议选择好点，-65dBm = RSRP = -80dBm。如果距离天线很近的地方（在天线下方）RSRP达不到-80dBm，需要进行如下核查； 确认小区状态是否正常？告警or 闭塞小区 确认小区功率参数配置正确，LST PDSCHCFG 宏站场景：确认天线是否存在问题，是否天线存在接反、天线的下倾角是否设置合理？ 室分场景：确认分布系统是否存在问题，可以采取断开分布系统直接在RRU端口连小天线进行测试；2) SINR异常 定点测试时，建议选择好点，选择SINR 大于20以上的地方进行测试，在RSRP较好但是SINR异常的时，需要如下核查 闭塞邻区，看SINR的变化，如果闭塞邻区SINR变好，可以证明是同频干扰，需要MOD3干扰、重叠覆盖是不是过大，参数设置存在问题？ 外部干扰查询，可以通过监控空闲状态RSSI和扫频进行问题定位； 检查同频干扰的影响当存在同频邻小区或者同频段的2G/3G信号时，邻小区的信号有可能会对本小区产生干扰，干扰严重时极度影响下行数传吞吐量。而且即便邻区没有用户接入，邻区的导频信号也会对本小区产生干扰。此类问题最典型的现象就是无论怎么调节UE的位置来改变信号的接收质量，即便RSRP调整得非常高，但UE测量出的下行SINR总是非常低，如Error! Reference source not found.所示。本小区信号RSRP为-77dBm，信号非常好，但测出的RANK2 的SINR仅有1.64dB，非常低。而此时邻区信号强度为-83dBm，和本小区的信号强度很接近，也就意味着干扰非常大，这将会导致MCS选阶较低。如果发现有邻区干扰的情况，那么需要联系网规网优的同事，查看站点规划上是否出现了异常，可能有PCI冲突和越区覆盖的情况出现。 MIMO天线功率不平衡UE两根接收天线的接收功率如果不平衡，则会严重影响下行测量的SINR，进而导致MCS选阶异常，影响流量。可以在PROBE上通过RSRP Measurement试图来观察两根天线的接收功率是否平衡，如Error! Reference source not found.所示：也可以在后台监控RSSI，对不不同天线口的RRSI差异； 如果发现两路天线的RSRP不平衡的话，需要排查DAS天馈系统。请参考6.3节DAS排查。 检查空口误码率(BLER)如果空口误码率高的话，会导致部分RB用于重传数据，进而影响吞吐量，此时应该重新选一个BLER低的点。误码率一般在10%左右收敛。若DL Grant和RB数都是调度充足，下一步需判断下行IBLER是否收敛到目标值。目前下行的IBLER目标值一般为10%，即5%15%即认为IBLER收敛。如果要达到峰值，需要IBLER为0。也可通过M2000信令跟踪管理-用户性能监测-误码率监测观察。一般来说，在AVG SINR较好的情况下BLER较差可能是由于数据业务信道的SINR较差，数据业务信道受到干扰或上行存在干扰，而这种干扰一般来自同频干扰的邻小区，或是部分频段的外界干扰； RSRP过高的影响在峰值测试中，虽然要求测试地点的RSRP与SINR要尽可能的好，但是也并不是说RSRP就没有了限制。通常我们规定的“近点”的RSRP要在-75dBm以上，但也不要超过-60dBm。这是因为终端接收到的功率过高的话会引起接收器件的削波，导致下行SINR降低，反而只会使得流量下降。并且，RSRP很高也就意味着离基站的天线很近，那么收到同站邻区的干扰也可能增大，所以不建议在“极近点”进行测试。一般来说，RSRP可以通过后台来减小功率或者加衰减器来消除影响。 检查上行干扰在下行信号较好的情况，上行吞吐率交底，UE的发射功率较大，但是MCS的阶数没有达到24（cat4、cat3终端）、RB调度不满，一般是因为上行可能存在干扰，按照干扰处理的思路进行分析； 在空载时（UE没有入网），打开OMC上打开小区性能检测中的RSSI统计监控： 通过查看RSSI的值来判断是否存在上行干扰，需要说明的是关于RSSI读数问题，在判断是否存在上行干扰时需要保证对应扇区不存在入网终端，否则会因为扇区接收到了终端信号RSSI很高导致无法做出判断。同时主分集的读数会有差距，通常相差约5dB以内认为是正常。RSSI(receive signal strength indicator) 即带内总信号强度指示.其理论在的计算值为：RSSI = -174dBm/Hz+10*log10(BW)+NF+AD量化误差，单RB正常情况下的RSSI在-120dbm左右，20M带宽内的RSSI在-98dbm左右，在RSSI跟踪中是按照RB、系统带宽和物理天线端口进行统计的，随着RB值增加频率依次增加； 上下行Grant调度次数不足l 如何判断调度次数不足 对于下行，DL Grant次数需要接近1000次。 对于上行，在峰值区域，ULGrant次数需要接近1000次；在非峰值区域，因为上行HARQ重传时，调度器不需要下发ULGrant，而IBLER一般收敛到10，所以ULGrant在900左右或以上都是正常的。 调度次数在probe中观察方法如下： DL grant 调度不足的排查手段 查看Probe-Radio Parameters-DL Grant Count是否满调度？ 检查用户配置的AMBR和GBR是否大于空口速率？ 检查DRX开关是否关闭？ LST DRX 检查S1入口数据是否充足，是否上层给水量问题？ 检查是否存在多用户； UL grant 调度不足的排查手段 首先检查是否为DSP能力限制（查询版本预警；如我们前期版本出现当2个RRU都分配到一个DSP上以后会出现DSP流控问题）； 观察核心网指配的QoS速率，如果偏低，则检查核心网开户信息是否异常； 上行来水是否充足； 上行存在DTX（需要跟踪IFTS），通过查看上行干扰和下行PDCCH的ibler来查看； 上行功控问题；（上行PUSCH 会有功控） 上下行调度RB不足l 如何判断调度RB不足 对于下行，在UE能力没有受限的情况，下行需要满RB调度。 对于上行，在闭环功控的条件下，在路损超过120dB125dB的条件下上行开始缩小调度的RB个数，此时MCS阶数大概在35阶左右，在路损小于120dB情况下，都应该以满RB调度。（满RB总的RB个数PUCCH RB个数，这个结果还要满足2，3，5法则。2，3，5法则指的是：单用户所用的RB个数必须是2，3，5的倍数，不能还包含其他倍数） 不管下行还是上行，需要注意小区内的用户数，对于多用户的情况，单个用户是不可能满调度的。（1）上图为我司终端Probe显示的结果，上行RB数=Total RBCount /Count，下行因为可能是双码字，两个码字的RB数分别通过Code0和Code1来计算 （2）下图为M2000中的RB数观察方法：RB利用率跟踪项中的等效下行RB使用数。 下行RB 调度不足的排查手段 查看Probe-Radio Parameters- PDSCH RB number/ Sub Frame是否达到满带宽？ 是否则存在多用户？ 检查S1入口数据是否充足，是否上层给水量问题？ 检查频选调度是否关闭； LST CELLALGOSWITCH； 检查下行ICIC是否关闭； LST ENODEBALGOSWITCH； 上行RB数和MCS的分配与上行调度算法有关，上行调度的输出包括分配给用户的RB、MCS、TBS等，包含在UL grant中。上行调度的主要输入包括L1的链路测量信息、功控算法、 ICIC算法输出输出等，并与上行调度策略、用户优先级有关。 MCS阶数过低l 如何判断MCS阶数过低MCS阶数是否合理在拉距的条件下较难判断。在路损超过120dB125dB缩RB的时候一般维持35阶数，但是缩着RB不能再缩小，其MCS阶数也会降低。比较方便的方法是排除法：在UE以满功率（23dBm）发送的条件下，如果调度次数和RB个数都比较正常但总吞吐率偏低，那么可以认为问题出在MCS阶数上。也可以使用MCS均值作为参考或者考虑MCS的分布范围来作为判断MCS阶数是否过低的方法。l 上行MCS阶数低1) 上行干扰排查，使用干扰检测 UE未接入情况下（所有UE关机，小区里没有业务），打开WEBLMT或者M2000的“小区性能检测”，选择“干扰检测”，查看RSSI值，在没有干扰的时候，约等于 -11910log(RB个数)，在内场差距1dB以上，在外场差距在3dB以上即认为存在干扰。也可以通过M2000上的干扰跟踪（Interference Detect Monitoring）来观察加载和不加载时干扰水平的变化，如下图所示，如果加载和不加载情况下检测到的干扰水平有明显差异，则说明小区存在互调干扰。2) UE主分集不平衡 主分集不平衡，会严重影响上行测试结果，如下为一次测试数据的结果：由于主集（Antenna0）比分集（Antenna1）小了近5dB，在显示RSRP的时候显示的是最强信号的RSRP,但是UE发送信息是从主集发送的，算路损的时候也是以主集为主。这样实际上行的信道质量就比显示的RSRP小很多。可以通过2个办法解决该问题：在测试有外置天线的时候调整主分集天线，在测试内置天线UE的时候可以改变UE位置使其主分集相对平衡，如E392在室内，近点的场景下摆放位置对吞吐率影响较大吞吐率曲线不用RSRP，改用路损VS吞吐率l 下行MCS阶数低1) 下行相关性高观察： 我司UE Probe相关性如左图所示：RxChCorFactor和TxChCorFactor两个值均大于0.5，则表明收发相关性较高，越接近1，相关性越高，解调性能越差。 解决方法： （1）排查干扰，当干扰大于信号时，会出现两路信号的相关性较大的情况。 外场： （2）直达径场景，一般相关性较高，避免直达径的地方。 2) 邻区干扰大观察： （1）在Detected Cell中看是否有多个小区，且超过1个小区的RSRP和本小区的RSRP差在3dB之内。如果是，则表明存在较强的邻区干扰。 （2）在检测到的邻区当中，不能出现和本小区PCI相同的邻区。 （3）查看下行各子带CQI是否有某一段CQI的值特别低的，如果存在，说明存在较严重的窄带干扰。 （4）粗略估计RSRP-SNR，如果该值大于-115dBm，说明干扰还是比较强的。 解决方法： （1）较强的邻区干扰只有通过调整天线功率，安装位置，天线类型等方式来解决。 （2）严重的窄带干扰通过扫频，找出干扰源，进行排除。干扰排查和恢复更详细的指导可以参见 LTE射频通道通用指南 3) RRU相关信号处理出现异常（1）RRU的通道不平衡会导致终端的解调能力下降，导致MCS偏低，可以通过下面的方法来观察观察两天线接收的RSRP差，当两根天线差值持续在5dB以上时，认为通道不平衡，需要通过调整终端天线来解决。（2）终端入口功率一般在-50dBm-90dBm，如果入口功率超过-50dBm容易导致削波，使得下行SNR偏低；如果入口功率低于-90dBm，也会使得下行SNR偏低，影响下行性能。可通过下面的方法观察终端接收的功率。 通过调整天线口和基站的功率配比来解决，但此问题需反馈回总部相关人员进行分析和优化。 下行MIMO模式异常l 下行MIMO模式异常，一方面检查eNodeB是否及时配置MIMO模式为TM3，如果保持在TM2，则下行只能使用单码字，如果没有重配到TM3，重点检查MIMO相关参数，是否和基线值保持一致； l 下行MIMO模式异常，另一方面检查UE上报的Rank是否合理。正常情况下，在两天线RSRP相差不大于3dB；收发相关性小于0.5；AvgSNR大于15dB时，系统可以使用双码字。如果没有使用，需要查看UE上报的Rank及eNB收到的Rank，并采集相关数据反馈总部分析。 模3干扰优化同频小区PCI mod 3相等会导致RS同频干扰严重，使RS SINR降低，导致吞吐率不理想，同频优化过程中对于PCI优化也是日常优化中的重点工作之一。模3干扰排查如下图所示：将PCI 13修改为PCI 17，SINR提高了7dB。 TCP常见问题判断TCP之前先通过UDP灌包来进行测试，如果TCP多线程的测试吞吐率较UPD灌包速率差，TCP一般就会存在问题，TCP的原因主要介绍服务器的TCP发送窗口设置问题和传输质量问题 1) 服务器问题 TCP的速率 = TCP的发送窗口/RTT 时延 对于服务常见的原因主要： 发送窗口过小，按照TCP的速率简单计算方式，一般推荐发送窗口设置为512K； 服务器的FTP服务器软件（Windows server 2003：自带的FTP服务器，和windows配套最好，性能相对稳定；如果都没有采用ServU）； 服务的性能（如果没有刀片服务器，推荐使用Windows 2003，其次Win XP，最次Win7。） 2) 传输问题 从一期的项目经验来看，传输问题主要表现在丢包、乱序和分片问题上（参见后面的案例） ping 包测试：通过准则:不能有丢包 LST IPRT，查看SGW IP地址 从基站对上述每个地址进行PING包，1000/2000各100次 MTU 检查：通过准则：不能有丢包测试目的：排查链路上MTU设置是否存在异常。 终端向PDN PING包，设置IP报文不分片，ping x.x.x.x f l 1472，如果无法PING通，则表示传输中有MTU小于1500的网元。TCP报文包头28字节，一般传输MTU默认设置均为1500，故报文长度设置为1472。 1.1.2 话统类速率问题定位和优化方法 话统类业务定位流程1 首先确认话统KPI的计算公式是否正确；2 如果话统KPI公式没有问题，需要判定是否前后KPI变化问题。对于前后KPI变化的问题，需要结合关联KPI变化进行分析；非KPI变化问题类问题，直接针对网络指标从四个方面进行分析：参数核查、负荷和资源、信道质量、数据源。KPI变化类问题，需要区分是否升级KPI类问题，进行关联KPI分析。3 对于升级导致的KPI变化，需要结合版本的修改和镜像环境的复现进行分析。非升级原因导致的KPI变化，需要结合网络近期的变化进行分析，例如配置修改、核心网配置、CSFB实施、用户数变化、客户营销和资费策略变化等。4 如果问题还无法解决，收集相关日志反馈总部分析。下面对各步骤分别进行介绍。 话统KPI公式和数据源检查需要确认反馈异常的KPI计算方式是否正确。按照统计范围区分，业务速率计算公式分为单小区速率和整网/Cluster级别的平均速率。1小区级速率计算小区级用户速率下行用户速率(Mbps) = L.Thrp.bits.DL/ L.Thrp.Time.DL /1000上行用户速率(Mbps) = L.Thrp.bits.UL/ L.Thrp.Time.UL/1000这两个指标反映了整小区在统计时间内，所有用户的平均速率，是反映用户体验的重要指标。是小区级的用户速率，不是小区速率。小区级满载吞吐率下行满载吞吐率(Mbps) = L.Thrp.bits.DL*系统PRB数目/L.ChMeas.PRB.DL.Used.Avg/话统统计周期(s)/1000/1000上行满载吞吐率(Mbps) = L.Thrp.bits.UL*系统PRB数目/L.ChMeas.PRB.UL.Used.Avg/话统统计周期(s)/1000/1000小区满载吞吐率反映了小区空口管道的极限能力，是小区传输效率的重要体现，影响小区总业务量和用户体验，受MCS分布变化影响。2 整网级别的速率计算若将整网的数据量和传输时间分别相加后，即可获得整网的平均用户速率。下行用户速率(Mbps) = L.Thrp.bits.DL/ L.Thrp.Time.DL /1000上行用户速率(Mbps) = L.Thrp.bits.UL/ L.Thrp.Time.UL/10003 话统数据源排查由于用户活动的规律性，一天中用户数和业务量变化很大。比较几天之间变化趋势时一般采用忙时数据进行比较，忙时指整网用户数或者业务量最大的一个小时。不建议采用一天24小时的数据相加获得一天的速率值。样本点数目会影响统计的准确性。对于单小区的速率统计，需要关注用户数和小区数传时长。对于平均用户数很少(5)或者小区数传时长比例很少(-110dbm），空载状态下全带宽RSSI 约为-70dbm-75dbm，存在高干扰，截图如下：（5）将3151 FA端口与POI 一端断开，频谱仪接入POI一侧馈缆，并将该地铁WE站点闭站，发现如下现象：a)1880M1900 LTE F频段大带宽扫频结果,出现峰值约-70dbm 干扰信号，频域未呈现明显规律，截图如下：b)取1894.9M为中心频点进行10ms时域扫频，发现类DCS1800互调特征干扰，但后台DCS工参查询结果显示该地铁PO站点并无 18501872.6高频频点配置。截图如下：c)扩大频域扫频带宽，设置1850M1920M带宽，结果显示整体干扰频域跨度约为42M。截图如下：d)设置中心频点至干扰峰值点1893.9，缩小扫频频域带宽,100K,干扰未呈现明显周期特征。截图如下：（6）3151-E端口与POI 一端断开，频谱仪接入POI 一侧馈缆，民乐WE站点闭站，发现如下现象：a)设置1850M1920M大带宽频域扫频，底噪均匀分布，无干扰信号，截图如下：（7）关闭民乐WE 站点，设置1850M1920M频域跨度进行大带宽扫频，LTE频段内未发现明显干扰。截图如下：（8）联合POI设备商和室分厂家，对该地铁站台的机房的POI进行排查，频谱仪接POI的输入口，发现强度为-70dBm的强干扰信号，断开CDMA800，GSM900，DCS1800三条输入的任何一路，干扰信号基本消失，因此判断为这三路信号的综合互调导致上行干扰。在两个TX口直接堵负载，干扰情况也基本消失。（9）同室分厂家对该POI进行旁路测试，即用我们的RRU输出，绕过POI直接接入站厅的天馈系统，现场测试情况很好，下载速率稳定在40M以上，上传速率稳定在7M以上。（10）通过以上分析，初步判定为POI模块的系统隔离度不够，不能对交调信号有效抑制，从而产生干扰，导致上行速率受限。【问题处理】1、推动运营商和POI厂家进行整改，消除存在的隐患。2、整改完成后，重新进行测试，发现上传速率恢复正常，基本稳定在7M以上。由于POI能够产生诸如驻波之类的很多问题，因此在进行排查时，应当消除POI的电源、电桥中存在的隐患，从而避免类似问题的发生。 无法数传【问题现象】：无法进行UDP灌包，在服务器端的灌包工具上看不到数传启动的信息。【定位思路】：UE能够正常接入小区，说明信令面及传输物理链路正常，那么无法数传就很可能是参数、软件设置错误、路由信息配置错误等原因。 常见的原因为在UDP灌包的过程中没有关闭UE侧PC的防火墙、终端侧DMZ 使能开关没有开启。 【iperf 灌包操作】：备注：下行灌包是从服务器往终端侧灌包，在iperf软件中填写的Host adress为P-GW分配给终端的IP地址，PC上的防火墙和360之类的软件都需要关闭； 如果上行灌包侧从终端侧往服务器进行灌包，Host adress为服务器地址，都选择上行。1.1.4 后台操作方法更多后台操作方法请参考“运维文档_eRAN3.0_LTE故障信息采集指导书-20130608-A-1.5”文档路径：28 培训材料 (1)03 LTE相关培训中国区TD-LTE资料 2006 网络优化和性能提升02 故障信息采集服务器没有权限的请联系：范丽600189 灌包iperf是一种网络流量检测工具，有UDP和TCP两种检测方式。l 命令行格式的iperf工具首先将iperf.exe文件放置在服务器以及UE PC中，即接收方和发送方电脑都有该程序。打开DOS窗口，将工作路径设置到iperf文件所在文件夹。参照下面的说明，采用UDP或TCP灌包。可以将iperf.exe文件放置在C盘根目录下，打开DOS窗口后输入cd c: ，这样当前路径即为C盘根目录。 UDP：1) 在接收方建立接收服务器，输入命令iperf s u i 1其中 s表示建立接收服务，-u表示接收的是UDP业务，-i 1表示每1秒显示一次接收到的流量。2) 在发送方输入命令iperf c x.x.x.x u t 10000 i 1 b 50m其中 c x.x.x.x表示连接到该IP；-u 表示灌UDP包；-t 100000表示灌包时长10000秒；-i 1表示每1秒显示一次灌包出口流量；-b 50m表示每秒灌50Mbits的包。3) 其它常用参数： -l 1400-表示灌包包长，默认为1498字节（IP层统计，包括IP头），需要在接收方和发送方都进行设置。-p 5010-表示灌包端口，默认为5001，需要在接收方和发送方都进行设置。注意，在发送方设置该参数表示往接收方的该端口灌包，在接收方设置该参数表示接收方在该端口接收。-P 2-表示用两个线程来灌，假设设置的灌包流量为-b 1m，采用两个线程后即每秒灌2Mbits。该参数只需要在发送方设置。注意与小写的-p加以区分。若未在接收方建立接收服务，而直接从发送方往接收方灌包，那么接收方每收到一个包都会返回一个176字节的ICMP包（IP层统计，包括IP头）。若接收已建立接收服务，则没在回包。 TCP：1) 在接收方建立接收服务器，输入命令iperf s i 1 w 512k其中 s表示建立接收服务， -i 1表示每1秒显示一次接收到的流量，-w 512k表示接收方的接收窗口是512Kbyte。与UDP的接收服务器相比，少了-u选项。2) 在发送方输入命令iperf c x.x.x.x t 10000 i 1 w 512k其中 c x.x.x.x表示连接到该IP；-t 10000表示灌包时长10000秒；-i 1表示每1秒显示一次灌包出口流量；-w 512k表示发送方的接收窗口为512Kbyte。3) 其它常用参数： -M 1400-表示TCP包的MSS（即不包括IP和TCP头的净荷最大长度），默认为1460字节，需要在接收方和发送方都进行设置。-p 5010-表示灌包端口，默认为5001，需要在接收方和发送方都进行设置。注意，在发送方设置该参数表示往接收方的该端口灌包，在接收方设置该参数表示接收方在该端口接收。-P 2-表示用两个线程来做业务，等同于两线程下载或上传。该参数只需要在发送方设置。请注意与小写的-p加以区分。若未在接收方建立接收服务，而直接从发送方往接收方灌包，则会提示连接建立失败。l 图形化giperf工具将工具包里的文件都解压缩到任意一个文件夹，然后运行giperf.exe文件。该工具将各种参数都做成了图形化的界面，在使用上简便许多，界面如图3-1所示。需要注意的是Traffic direction的选择，无论是上行还是下行，发送方都选择UL，接收方都选择DL。同时可以勾选Show页签下的“Chart”和“Messages”来查看实时流量。其余参数说明与iperf工具一样，在此就不再复述了。1. UDP灌包操作步骤1、 Traffic mode：选择UDP 2、 Traffic direction：原则：谁灌谁上行。终端下行：服务器侧选择UL，终端侧选择DL；终端上行：服务器侧选择DL，终端侧选择UL。3、 Host address：终端侧：填写服务器IP地址；服务器侧：填写终端业务IP地址。4、 Bandwidth：灌包带宽5、 Execution time：灌包执行时间，根据需求设置6、 MTU size：建议配置1000B7、 Port：服务器侧和终端侧协商好一个没有使用的端口号，两边配置一致。2. TCP灌包操作步骤和UDP灌包不同点不需要配置带宽和MTU size 查看在线用户数如果当前小区内还有其他用户接入的话，会由于用户业务优先级、调度公平性等因素导致当前用户的流量收到限制，所以特别是在进行峰值测试的时候，一定要排除其他用户的影响。可以通过在M2000上启动小区统计跟踪来进行查看当前小区的用户数信息，如below所示。在M2000上启动小区统计跟踪查看小区统计跟踪的结果 M2000上启动干扰检测上行与下行的情况不同，邻近的同频干扰源对终端的上行数传的影响比同频邻区对基站下行数传的影响要大得多。在上行空载时(所有UE关机，小区里没有业务)，可以检测上行全带宽上的接收功率RSSI，正常情况下空载时每个RB上的RSSI应该是-119dBm左右，如果有突然升高3-5dBm以上的的情况存在，说明上行有干扰，需要排查干扰源。在M2000上进行小区性能监测，选择干扰检测，填写正确的小区ID，如Error! Reference source not found.所示：在M2000上查看实时的干扰检测结果 M2000上查看小区性能在M2000里面点监控，选择”小区性能测试”，查看RB利用率，总吞吐率，小区干扰监测，用户数。选择“用户性能测试”，查看Power Headroom，信道质量，吞吐率，MCS阶数统计， 误码率。 抓包TPE定位结果如果不能得到客户的信任，建议采用三点抓包(有条件时启动4点抓包，无条件时在A、B、D 3点抓包): 1、A点抓包只需抓取包头100字节以节省文件大小，并命名为: 局点名_UEPC.pcap 2、如果实际组网环境有安全网关的话，B点抓包考虑到要能正确解密数据，必须要将IPSEC通道设置为空加密，同时抓包时必须抓完整的包. 同时因该点数据量大，为防止占用内存过大，抓包保存时可使用多个文件，避免单个文件过大。如果没有IPSec安全配置，推荐只抓包头150字节即可。 命名为：局点名_eNB.pcap 3、 C点抓包只用抓取包头150字节即可，命名为：局点名_UGW.pcap.4、 D点抓包只用抓取包头100字节即可，命名为: 局点名_Server.pcap. 5、按上述步骤，先启动各点的Wireshark做好抓包设置，再开始数传，停止数传后，再停止Wireshark抓包。 简单分析思路: 1. 在A点使用tcp.analysis.duplicate_ack_num = 2过滤看是否有丢包，如果有丢包找到一个具体丢包点，和B点核对, 分段排查。 2. 在A点使用tcp.window_size 1000过滤看是否有窗口收缩，如果有窗口收缩的时间点和IO Graphs时间点核对，如果一致说明UE PC性能不满足需求。1.2 切换重选类问题更多切换类的问题请参考服务上的文档。文档路径：28 培训材料 (1)03 LTE相关培训LTE室分X板斧参考资料切换服务器没有权限的请联系：范丽60018914。1.2.1 现象描述切换问题通常指终端按照网络侧的配置上报测量报告，但未能按照切换流程成功完成切换，根据流程失败的环节可以分为如下几类： 终端上报测量报告后未能收到切换命令 p 网络侧未能收到测量报告，源小区上行信号或上行消息发送有问题； p 网络侧收到了测量报告，但是内部准入失败或切换信令在S1、X2等接口丢失或切换惩罚，网络侧没有下发切换命令，可以确定是系统侧问题，和终端以及空口信号无关； p 网络侧下发切换命令，终端没有收到，源小区下行信号或下行消息发送有问题 终端收到切换命令但是eNodeB没有收到切换完成 p 终端在目标小区进行随机接入，eNodeB没有收到MSG1； p 终端在目标小区进行随机接入，eNodeB收到MSG1，终端没有收到MSG2； p 终端在目标小区进行随机接入，终端收到MSG2，eNodeB没有收到MSG3； eNodeB收到切换完成，但后续流程失败 p 这种场景比较少，可以确认是系统侧问题，和终端以及空口信号无关 如果切换失败，则大多表现为掉话、RRC重建等现象。换失败的空口问题，在终端侧通常表现有多种情况，但有一个共同点，则在发完测量报告后不久（2秒以内）终端重新发RRCConnectionRequest消息、或发RRCConnectionReestablishmentRequest消息、或直接进入IDLE态(仅接收paging和systemInfomation) 切换类型介绍LTE中的切换 Intra-RAT （系统内切换）载频关系：n 同频切换，n 异频切换信令承载方式：n eNodeB内的切换n MME内基于X2接口的切换（存在X2口）n MME内基于S1接口的切换（不存在X2口） n MME间S1口切换，数据转发走X2口（存在X2口） n MME间S1口切换，数据转发走S1口（不存在X2口） Inter-RAT（系统间切换） 测量事件介绍1.2.2 分析思路切换问题主要从三个方面去分析和定位：