运维文档_eRAN2.2_LTE问题定位指导书-时延篇-20110924-A-1.0.doc

产品名称Product name密级Confidentiality level问题定位指导书时延篇内部公开产品版本Product versionTotal 33 pages 共33页eRAN2.2LTE eRAN2.2问题定位指导书时延篇(仅供内部使用）For internal use only拟制:Prepared byLTE交付维护组日期：Date2011-07-18审核:Reviewed byLTE交付维护组日期：Dateyyyy-mm-dd审核:Reviewed by日期：Dateyyyy-mm-dd批准:Granted by日期：Dateyyyy-mm-dd华为技术有限公司Huawei Technologies Co., Ltd.版权所有 侵权必究All rights reservedRevision HistoryDateVersionDescriptionReviewerAuthor2010-9-1V0.1初稿2011-2-26V0.2刷新为适合于eRan2.1的版本2011-7-18V0.3刷新为适合于eRan2.2的版本目 录1Document description62Principle62.1信令面（控制面）时延介绍62.1.1初始接入时延72.1.2Idle to Active时延82.1.3paging时延102.2用户面时延介绍112.2.1影响Ping时延的关键因素112.2.2Ping时延与调度132.2.3Ping测试153Operation Guide153.1控制面时延问题定位思路163.2接入时延的定位193.2.1环境检查193.2.2参数影响203.2.3时延问题验证213.2.4数据采集与分析233.3用户面时延问题测试定位293.3.1Ping时延分段定位293.3.2Ethereal抓包303.3.3M2000进行用户面跟踪314Reference Information335Typical Cases33Figures 图1 时延测试组网图.6图2 UE开机进行初始接入图7图3 Idle到active接入流程图9图4 paging流程图10图5 ping流程图11图6 图6 Ping包流程12图7 时延定位流程图16图8 Ping时延分段分析示意图30问题定位指导书时延篇Keywords：LTE,Abstract： 本文主要描述了eRan2.2时延问题的定位过程以及相关的一些基本原理。Acronyms and Abbreviations：Acronyms and AbbreviationsFull SpellingLTELong Term EvolutionMACMedium Access ControlPDCPPacket Data Convergence ProtocolRLCRadio Link ControleRAN2.2_LTE问题定位指导书-时延篇-20110924-A-1.0内部公开1 Document description本文主要从信令面和用户面，描述了UE接入过程及业务的时延问题的定位流程。本文主要基于eRAN2.2版本。2 PrincipleLTE系统相比其它通讯系统，结构更加精简。从协议已发布一些指标来看，时延相比其它系统有较大改善。比如协议要求控制面时延小于100ms，用户面（小包）时延小于10ms。并且从已有的测试来看，运营商也比较关注时延，例如：接入时延，idle2active时延，寻呼时延，ping包时延等等。时延测试一般对组网没有特殊要求，最基本的组网图如下所示图1 时延测试组网图2.1 信令面（控制面）时延介绍信令面时延分为三种：UE开机时初始接入时延、Idle2Active时延，Paging时延。统计方法主要是统计RRC层信令之间的时延值。运营商一般要求统计终端侧的信令时延，基站侧统计的时延仅作参考。但需要注意的是商用终端并不一定提供跟踪信令的工具，若不能跟踪终端侧信令，需要说服客户接受使用基站侧信令进行统计。下面按照三种时延分类说明：2.1.1 初始接入时延接入是指UE在开始和网络通信之前的接入过程。 终端开机后，执行注册过程，即网络附着，完成和EPC间的相互认证鉴权，让网络获得该UE的基本信息，UE通过建立RRC连接进入连接状态（RRC-CONNECTED）状态，然后UE就可以与网络进行业务数据的交互。UE开机进行初始接入的流程如下：图2 UE开机进行初始接入图接入流程的描述：1) UE开机或者由IDLE发起无线连接建立请求的时候，UE先发送PREAMBLE到ENB。ENB返回RA Response消息。这段消息在UE侧统计时候，通常计算入接入时延，在ENB侧统计时候，通常不记入接入时延内；UE接收到RAR消息后，会发起RRC_CON_REQ消息；2) ENB接收到无线连接建立请求，由层三处理分配相关的资源。ENB发送RRC_CON_SETUP消息；3) UE接收到RRC_CON_SETUP消息后，对该消息进行处理，然后返回RRC_CON_SETUP_CMP消息。为了节省消息，在该消息除了携带无线连接建立完成消息外，同时还携带了UE接入申请的资源字段，即NAS消息，这些消息在ENB内是直传的；4) ENB接收到该消息，就向核心网发送消息，根据RRC_CON_SETUP_CMP中携带的NAS消息进行相应的ATTACH请求；5) 接着两对上下行直传消息是鉴权和加密过程；(鉴权也可以在核心网侧关掉，节省时间)6) 核心网接收到该消息，处理后返回ENB INITIAL_CONTEXT_SETUP_REQ消息，该消息中携带ATTACH请求是否接收，ENB根据该消息进行下一步处理。如果拒绝就进行资源释放，携带的是ATTACH REJ消息且包含拒绝原因；如果是接受，该消息携带的ATTACH ACP消息，ENB随后进行加密和RB重配置；7) 然后就是UE能力查询与上报；8) 为了节省流程，提高接入时延，该处流程目前通常配置成SECUR与RB配置同时发送的情况。这两个消息间隔比较小，通常在同一个消息里面可以下发给UE；9) UE接收到同时发来的SECUR消息和RB重配置消息，然后经过层2和层3逐步处理。由于UE在处理上不能并发，所以在UE侧的消息上处理通常是先处理SECUR然后处理RB重配置；10) UE按照顺序把SECUR完成消息和RB重配置完成消息发送给ENB后，认为接入流程已经完成；11) 后续还存在着测量控制的下发和ATTACH完成消息的发送。以及ENB和核心网之间存在消息的交互。目前认为这些消息在接入流程之外，不进行细致描述。2.1.2 Idle to Active时延当UE处于IDLE态且有上行业务的时候，UE会发起服务请求触发Idle到Active的流程，idle2active时延就是指从UE侧发起请求，UE从Idle态到active态的接入时延，与初始接入流程的区别是：由于核心网中已经保存了UE的上下文信息，因此不需要进行UE能力查询和鉴权加密，流程如下：图3 Idle到active接入流程图Idle to Active流程是指UE在Idle状态下发起的接入流程。从流程图中我们可以看到其与初始接入的区别在于两点：第一点：没有了UE能力信息查询和完成这一步骤。原因是Idle状态时，核心网和eNodeB仍旧保留了初始接入时UE的能力信息，所以不需要在重复查询了。第二点：UE没有了与核心网的鉴权加密过程。这是因为测试时，在核心网侧一般没有打开鉴权加密开关。只有在核心网侧打开了鉴权加密开关时，UE才会在接入过程中执行鉴权和加密。除此之外，其他的消息流程与Initial Attach相同，此处不再重复。2.1.3 paging时延当有下行业务或者核心网认为有需要的时候，会发起paging流程寻呼处于IDLE态的用户，Paging时延是从核心网侧发起paging请求，UE从Idle态到active态的接入时延，寻呼流程如下：图4 paging流程图PAGING 流程与Idle to Active类似，此时的UE也是处于Idle态，区别在于此时是由核心网侧发起接入，经过eNodeB传递后到达该UE，然后由UE发起一个服务请求（MM_SER_REQ），并开始执行接入过程。注: 我司核心网在有UE上下文的时候会关闭鉴权加密过程,具体表现是initial_ue_msg和initial_context_set_req之间没有鉴权和加密流程，但不排除使用其它核心网或者使用我司核心网默认打开鉴权加密开关的情况。2.2 用户面时延介绍用户面时延也指PING时延，它反应端到端的用户面时延，涉及到用户面的所有网元，对于验证网络性能是一个重要的指标。图5 ping流程图PING时延测试主要分为两大类，第一类是按字节大小分，通常会测试PING 32 bytes，以及1000/1460/1500字节；另外也分调度方式：动态调度和预调度。2.2.1 影响Ping时延的关键因素 信道质量如果测试时UE所处环境的信道质量不好，则会对解调性能造成一定的影响，这样有可能造成错包或者丢包，进而影响时延结果。 HARQ重传如果数据包在传输过程中出现了错误或者丢失（触发原因可能因为瞬时信号质量变化使得较高的MCS无法解调正确），那么会触发HARQ重传，直到数据包接收正确为止。因此，信道质量越差，重传次数越多，时延也就越大。 调度方式由于不同调度方式的流程间存在区别，则调度采用预调度还是非预调度会对时延造成影响。a) 预调度：调度器始终为其分配资源，不需要调度请求（Scheduling Request）。详见下图6（a）b) 非预调度：在首包到达之后调度器再为其分配资源。UE要通过调度请求来初始化这一流程。详见下图6（b） 图6 图6 Ping包流程： (a) 预调度, (b) 非预调度 Ping包大小与调度资源分配（MCS和PRB）分配MCS和PRB个数不同，则可以承载的数据量不同。如果调度使用MCS10阶，RB数5个，根据36.213协议查表（Table 7.1.7.2.1-1），那么这次调度可以发送的数据量为776bit。如果使用MCS28阶，RB数41个，那么这次调度可以发送的数据量为30576bit。下面针对不同的调度方式进行进一步的分析:a) 对于非预调度参照图3（b），UE首先进行资源的申请，即SR过程，eNB会为其首次分配调度资源，通过上行授权（UL Grant）告知UE。如果此时的资源不足以承载全部的数据量，比如此时Ping包为1500字节（即12000bit），而分配的MCS10阶，RB数5个，那么此次分配的资源不够将数据一次发送完成，将会触发BSR过程。BSR过程即UE上报BSR（Buffer Status Reports）告知eNB缓存中的数据量，申请调度资源的过程。而如果上行授权时分配了MCS28阶，RB数41个，那么足够将数据量全部发送完成，将不会触发BSR过程。而如果Ping包为32字节（即256bit），而首次上行分配资源依然为MCS10阶，RB数5个，通过比较可知这将不会触发BSR过程。可见Ping包大小和SR过程中分配的资源的差异将引入调度过程的时延差异。b) 对于预调度参照图3（a），调度器始终为其分配资源，但如果分配的资源不足以传输全部数据，仍会触发BSR过程进行资源的进一步申请。那么Ping包大小和预调度资源的分配的差异也将引入调度过程的时延差异，分析与非预调度场景相似。2.2.2 Ping时延与调度eRan2.2默认预调度打开，采用预调度策略可以明显减少控制面和用户面的时延。而对于动态调度和预调度，可以优化一些参数减少时延值。122.12.1.12.2.1.1 动态调度采用动态调度策略时，设置QCI对应的SRI周期到最小值（5ms），MOD TYPDRBBSR: QCI=QCI9, TPERODICBSRTIMER=TPeriodBSRTimer_sf5;修改该参数主要影响动态调度下ping时延的波动情况，设置该参数可以限制ping包时延的波动范围。该参数的默认设置根据QCI级别不同而不同。在实际测试中，需要根据开户信息进行针对性修改。在ENB侧S1口进行查看：注意：预调度开关是默认打开的，测试动态调度时，需要将预调度特性开关关闭。MOD CELLALGOSWITCH: LocalCellId=0, UlSchSwitch=PreAllocationSwitch-0;针对动态调度，SR调度数据量修改为15000MOD CELLULSCHALGO: LocalCellId=0, UlSrSchDateLen=15000;修改该参数主要影响动态调度下Ping业务的一次调度的数据量，可以减少Ping大包的时延。2.2.1.2 预调度这里主要针对预调度情况下的PING时延测试：打开预调度开关（默认参数即是打开的），并把预调度的周期修改为1ms，可以减少用户面的时延。MOD CELLULSCHALGO: LocalCellId=0, PreAllocationMinPeriodicity=1;如果需要测试PING大包，例如1000/1460/1500字节，则修改默认预调度数据量将会起到节省时延的目的，适合于比拼测试时使用。MOD CELLULSCHALGO: LocalCellId=0, PreAllocationSize=1500;注：测试完毕后，需恢复默认配置。2.2.3 Ping测试确认好动态调度、预调度的参数设置后，就开始正式测试PING时延了。Ping测试的过程相对比较简单，如下：ping 40.32.1.166 n 100 l 1500 参数 n 表示ping包的次数，l 表示ping包的长度，单位是字节。将结果保存在文本文件中。如果要直接将测试结果输入到文件，可以采用以下通道命令，例如：ping 40.32.1.166 n 100 l 1500 ping1500.txt3 Operation Guide时延问题总的定位思路是分段隔离分析，通过信令跟踪统计，分段抓包等方法，尽可能的找出出现问题的最小网元或者模块，下面是总的定位流程图： 图7 时延定位流程图3.1 控制面时延问题定位思路根据2.1节中接入时延的介绍，控制面时延在UE侧和ENB侧都是RRC_CON_REQ到第一个RRC_CON_RECFG_CMP之间的时延。总体思路是：根据信令流程，对每一条消息和下一条消息之间的处理时间计算为两条消息之间的时延，总的接入时延就是这些消息的之间的时延总和。对接入过程中涉及到的RRC层的信令消息分段处理和分析，如果发现问题，再根据问题点细化处理。为了能够方便的对比接入时延的情况，对UE和ENB各侧都进行了数据处理，统计UE侧和enodeB侧的各自RRC层相邻间信令之间的时延，进行处理分析，后续还可以再进一步细分。统计模板如下：可以将后一条信令消息的时间戳减去前一条信令消息的时间戳。得出两条消息的处理间隔时长。根据分段时间统计结果分析，首先定位时延问题出现在哪两条信令之间，这样对问题分析缩小范围。然后对这两个信令间的模块处理的情况进行了深入的分析，找出涉及到的那几个网元。分段的意义在于我们在把握总体时延测试值的同时，也需要关注分段时延情况。当总体时延出现异常时，需要依靠分段时延来定位、排查问题所在。典型的是由于S1口核心网/传输引入的时延，这个时候就能依靠分段时延来进行判断。注: 以上消息流程是在核心网侧并没有对SERVICE REQUEST进行鉴权加密的条件下。目前核心网侧关于鉴权加密是可选的，在关闭的条件下，我们在任何接入过程都不会进行鉴权加密的过程，也就没有了初始接入initial attach中的上下行数传消息（RRC_DL_INFO_TRANSF / RRC_UL_INFO_TRANSF）3.2 接入时延的定位3.2.1 环境检查时延环境包括UE，ENB,MME，SGW,HSS等相关的网元，基本组网图如下：eNodeB和核心网之间可能因为传输的距离过远，或者是因为它们之间的传输网元（例如路由器，交换机）的影响，造成时延过大。在定位的时候，应该首先排查和确认。一般正常传输时延不会超过2ms。空口的要求一般要求在信道质量很好的条件下测试,才有可能得到理想的时延值，所以UE的选点一般选择在近点（RSRP：-75至-85，SINR25）.3.2.2 参数影响eNodeB上的一些参数的修改会对时延产生影响，对于商用局，实验局和比拼局有不同的参数要求，一般按照测试用例的描述进行设置即可。在进行时延优化时可以考虑修改这些参数，同时对于设置这些参数可能对其他性能产生影响，请注意慎重修改。参数影响说明如下：3.2.2.1 ENB侧参数参数一：测试Idle2Active时延时，为了UE从IDLE态发起service request消息，需要设置UE进入不活动期的时长。该时间长度表示UE在该时间内没有数据传送就会释放资源，进入IDLE状态。便于测试Idle到active的时延。设置方法：在LMT上运行MML MOD RRCCONNSTATETIMER: UeInactiveTimer=10;参数二：调度特性开关设置。对于接入时延的测试，要求分别设置动态调度和预调度来进行测试和数据统计。上行预调度模式比动态调度模式能明显减少接入时延，在需要得到小时延结果或者比拼场景，建议打开预调度模式。关闭和打开预调度模式的设置方式：MOD CELLALGOSWITCH: LOCALCELLID=0,UlSchSwitch=PreAllocationSwitch-0;MOD CELLALGOSWITCH: LOCALCELLID=0,UlSchSwitch=PreAllocationSwitch-1;如果采用默认的上行预调度打开，把预调度的周期修改为1ms，用户预调度数据量修改为1500字节MOD CELLULSCHALGO: LocalCellId=0, PreAllocationMinPeriod=1, PreAllocationSize=1500;预调度周期默认值为5，修改为1后，将会减小测试的波动；预调度数据量默认为80字节，修改为1500字节，将会减少调度次数，从而提升时延性能。参数三：针对paging的控制面时延，修改寻呼周期MOD PCCHCFG: LOCALCELLID=0, DEFAULTPAGINGCYCLE=rf32;此参数在做paging测试的时候会减小时延的波动范围。默认值一般为128，即1280ms，修改为32后，Paging波动将减小。3.2.2.2 UE版本UE版本对接入时延的影响现在暂时不作为考虑的因素，一般选用发布的版本即可。3.2.2.3 核心网参数设置及版本核心网的一些具体设置会对时延有影响。比拼测试的时候,建议可以关闭商用计费功能，将SGW、PGW合设等。另核心网版本对接入时延也存在影响，当时延问题出现时，需要排查环境上所使用的核心网版本是否已经存在时延的遗留问题和针对时延的补丁。因此需要核心网相关人员配合定位。3.2.3 时延问题验证在有时延问题的环境进行测试和验证，接入时延测试分两种状态下的测试，一是在开机关机流程中，UE发起的为初始ATTACH接入流程。一是在IDLE状态下发起SERVECE请求的ATTACH流程。两者的主要区别在MME内的处理差异，初始ATTACH流程中需要MME和HSS进行交互，读取相关的信息。从IDLE接入相关信息已经保存在MME中，不需要和HSS进行交互。验证步骤：对于初始接入测试比较简单，直接通过UE控制软件开机操作，等待UE接入网络，完成接入后，完成接入流程。对于idle2active接入，在ENB上设置完成进入IDLE的时间，然后在开机接入后等待UE进入IDLE态，然后从UE侧发起ping测试，触发接入流程,等待UE接入，完成一次接入时延的测试。然后等待下一次进入IDLE状态，然后发起ping业务，触发接入流程。对于paging触发的接入，和idle2active的方法类似，不同的是，UE处于idle态，要从核心网业务服务器侧发起ping操作，来触发接入流程。时延值具有波动性，并不能单纯通过一次的测试结果来判断是否时延过大，另外不同配置情况下的基线值也有所差别，所以应该区别对待在分析控制面时延数据的时候，要按照下面的格式统计和计算出时延数据，然后将结果和版本测试的正常值进行对比，如果时延偏大，一般都可以从下表中初步定位出是哪两条信令间的时延过大。表格参考如下：如果两条消息时间间隔比较大，需要从处理过这两条消息的具体模块从头到尾进行分析。比如UU口消息时延比较大，需要查看空口质量和相关干扰；比如S1口消息时延比较大，需要查看eNB处理时长、传输时长、核心网侧处理时长等。3.2.4 数据采集与分析时延数据的采集和分析，主要通过S1口消息跟踪、UU口消息跟踪、OMT和probe软件进行数据的采集，利用excel、Assistant工具进行数据的统计。3.2.4.1 eNB侧UU口的消息处理eNodeB侧主要通过M2000或weblmt，跟踪uu口的信令消息，然后将跟踪数据导出到excel表格，然后处理计算出各个信令间时延数据。3.2.4.2 PROBE测试统计UE侧的消息之间的时延，由于OMT的日志数据无法直接保存到excel，不方便直接统计计算，可以利用PROBE和ASSISTANT的工具帮助进行测试和统计，可以节省大量的手动统计工作量。下面详细说明：PROBE工具的使用请参考PROBE使用指导书。测试接入时延的时候，主要用probe来记录日志录像，然后后续可以将*.gen日志导入到assistance，方便的统计时延数据。在连接好UE以后，配置完成后，就可以在probe中点击日志记录按钮开始记录日志，然后进行开机或者ping测试。对PING触发IDLE接入测试的注意点，每次PING的间隔，需要大于设置的UE进入IDLE态的时间，这样保证，每次发起的PING包可以触发一次SERVICE请求。把测试LOG保存下来，就可以利用ASSISTANT进行时延分析了。3.2.4.3 ASSISTANT统计对于PROBE测试记录的后缀名为gen的日志文件，导入到ASSISTANT内，然后进行接入时延的统计，就可以统计出相关的时延了。如果对ASSISTANT使用不熟悉，请参考ASSISTANT使用指导书。下面简要说明：首先打开GENEX Assistant，然后新建一个Project，如下图：在新建的Project下面创建Dataset，如下图右键点击新建的Dataset，导入gen文件，如下图：指定要导入的gen文件，把测试数据导入后，进入KPI选项，选择LTE TIMEDELAY选项：点击LTE TIMEDELAY选项后，出现如下对话框，在下拉菜单中选择需要统计时延的消息选中。选择完成后，点击，就完成了消息的选择：选