外场重点关注的参数.doc

双提升项目参数专题 外场重点关注的参数外场重点关注的参数项目名称双提升项目参数专题文档编号版 本 号V1.0.0作 者景志宏版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。文档更新记录日期更新人版本备注2009-12-15景志宏V1.0.0初稿目 录1.RAB建立或重定位为1类/2类/3类用户定制的承载速率42.FACH状态UL/DL最大支持信令用户数53.时隙类型不受限情况下，码资源分配是否允许使用等效方案64.其它算法定时器75.TOAWS76.TOAWE97.NodeB的处理时延98.DPCH是否采用不连续分配119.RIM过程消息重传次数1310.0k/8k最大比特率问题1411.传输信道同步次数1512.寻呼指示长度1613.给UE重发RRC连接释放消息的最大次数1614.PDCP头压缩算法1815.下行时隙汇聚开关（4.10.20新增）1916.是否支持HSDPA/HSUPA空分复用（4.10.20新增）2017.是否启用User Inactive功能开关2118.PCH RLC Size2219.UE能力2320.UpPCH的干扰相对门限2621.无线链路失败定时器2622.T3132723.HsdpaToDchTag（4.10.20新增）27281. RAB建立或重定位为1类/2类/3类用户定制的承载速率参数含义：当UE的最大速率大于定制的承载速率时，如果定制的承载速率不为零，则业务建立时，根据定制的承载速率接入。当UE的最大速率小于定制的承载速率时，按照UE的最大速率接入。0表示不限制速率。当PS开关打开后，该参数仅影响初始接入速率，后面的速率会根据4A/4B调整。在PS没有打开的情况下，定制的承载速率小，则会影响用户的感知。 该参数包括两个方向的配置：0表示的是下行；1表示的是上行。取值范围：0, 4294967295影响范围：CELL。取值分析：该参数配置太大，会占用较多资源，对于后续用户的接入成功率可能会有影响。该参数配置太小，可能会影响UE的感知。因此，该参数可以根据需要修改。如果为了拉网指标好，下行速率可以配置384k、256k。但对于话务统计KPI来说，下行/上行速率不易太大。下行最好不要配置0（不限制速率）。建议值：64kbps/32kbps。案例：n DELL上网本接入失败，无法进行业务。4月18日11点，云南省移动公司投诉，DELL上网本在大唐网络下可以“正常接入，但只有上行速率”，但该上网本在广州大唐2000网络下、昆明普天网络下工作正常。通过分析LOG，确认该问题是由于DELL上网本使用默认配置时，UE PDP 激活请求时带的Qos参数全部为0，CN自动分配了上512，下512的速率，目前我们的HSDPA的配置是2上4下，上行时隙无法满足512K的接入请求，因而给CN回了RAB指派失败，带的失败原因是目标小区没有足够的无线资源，最终导致用户接入失败。n 案例分析：1、CN分派上行速率时，不考虑无线网络侧的实际配置能力，是直接导致此问题的根本原因；2、UE 发起PDP 激活时，不带特定的申请速率也是导致此问题的间接原因；3、CN在收到RNC回的RAB指派失败后，依然继续向UE下发PDP激活成功的NAS消息；4、“G3随e行”软件在RNC已经拆除空口连接的时候，依然提示接入成功，实际上此时UE已经响应了RNC的RRC CONNECT RELEASE消息，造成用户感知只有上行，没有下行的错觉和假象；n 解决措施：将小区CAC算法下的“RAB建立或重定位为1、2、3类用户定制的上行承载速率”配置成64000，可以避免UE上行接入高速率导致的无线资源分配失败。2. FACH状态UL/DL最大支持信令用户数参数含义：该参数用于公共信道上的接入控制，表示FACH信道上最大支持信令用户数。接入新用户之后，如果FACH状态的上行、或者下行总的信令用户数超过最大支持信令用户数，则拒绝将该用户接入到CELL_FACH。 取值范围：0, 4294967295影响范围：CELL。取值分析：如果此参数配置太大，会影响已接入FACH用户的平均速率和时延；如果配置太小，会减少CELL_FACH的接入用户数。此参数需要结合FACH/RACH容量来配置。考虑在用户数较多的情况下，通过允许在FACH上建立某些信令（Registration、Detach）达到充分利用公共信道资源的目的。减少在拥塞情况下，用户注册不上的风险。该参数可通过OMC设置。该参数可以为0，等小区用户数多，易发生拥塞，容易出现用户无法注册时，建议配置为5，但要保证RRC建立原因只允许信令（Registration、Detach），其余原因设为：不允许。如果该参数不是0的情况下，该参数的配置要考虑RRC连接建立原因，注意哪些原因允许在公传上建立。参数关联关系：TagCTrch Admission=0表示不允许，1表示允许。EstablishmentCauseTagCTrch Admission1=Originating_Conversational_Call02=Originating_Streaming_Call03=Originating_Interactive_Call04=OriginatingBackground_Call05=Originating_Subscribed_Traffic_Call06=Terminating_Conversational_Call07=Terminating_Streaming_Call08=Terminating_Interactive_Call09=Terminating_Background_Call010=Emergency_Call011=Inter-RAT_cell re-selection012=Inter-RAT_cell_change_order013=Registration114=Detach115=Originating_High_Priority_Signalling016=Originating_Low_Priority_Signalling017=Call_re-establishment018=Terminating_High_Priority _Signalling019=Terminating_Low_Priority_Signalling020=unknown13. 时隙类型不受限情况下，码资源分配是否允许使用等效方案参数含义：该开关为码资源灵活分配的开关。如果单个时隙的剩余资源不足以满足用户的需求，可以考虑为用户分配多个时隙的资源（比如两个时隙分别提供4个BRU、6个BRU，来满足UE所需的10个BRU）。时隙0-6可作以下五种限制：0:该时隙SF不作限制;1:该时隙的业务只采用SF=8,信令SF=16;2:该时隙的业务只采用SF=2,信令SF=16;3:该时隙的业务同时采用SF=8和SF=2,SF=2采用c2(1),信令SF=16;4:该时隙的业务同时采用SF=8和SF=2,SF=2采用c2(2),信令SF=16;5:窗优化分配类型。取值范围：0,1 ，0表示不允许；1表示允许。目前，个别终端跨时隙配置有些问题。因此，设为：不允许。影响范围：CELL。取值分析：该方案的优点：n 大速率接入时，不受码碎片的限制，只要载波中的可用BRU满足需求（即使这些BRU分散在不同时隙中），一般都能够分配成功。n 可以尽量满足用户的需求，优先考虑最大速率，只有当最大速率接纳失败时，才会考虑降速接入。该方案的缺点：n 因为UE的资源分散在不同的时隙，所以功控、同步比较复杂（但是协议本身是允许UE资源分配在不同时隙的，并考虑到了对应的功控、同步方法）；n 对系统间测量有影响。如果要求UE进行系统间测量，则由于UE占用太多的时隙，导致可用于系统间测量的空闲时隙减少。4. 其它算法定时器参数含义：原本“其它算法定时器”是为了避免两个算法对同一UE频繁操作的保护时间, 除HC、FDCA、PS外其他算调整成功后启动的定时器时长。单位:10ms。在4.10.10版本中，为了增加切换惩罚策略，将算法定时器中的“其它算法定时器”改作它用，不当定时器使用，借用该参数完成切换惩罚策略，当计数器使用。具体含义为：允许邻小区切换失败的次数。例如：如果设置为1，也就是如果某个邻区切换失败次数（会针对每个失败邻区都计数，有一个计数器）大于等于1次，那么，该邻区就不能再作为目标小区了。4.10.20版本，有单独的惩罚机制，在4.10.20版本中该参数没有作用。取值范围：0, 60000 ，该参数原来的取值范围较大，当次数使用时实际取值在120 之间。影响范围：CELL。取值分析：在4.10.10版本中，如果允许邻小区切换失败的次数设置的大，则切换尝试的次数就多。设置小的话，允许切换尝试的次数就少。建议值：1-3。5. TOAWS参数含义：TOAWS是接收窗口的开始点。下行链路数据帧被期望在此窗口结束点之后被收到。TOAWS定义为相对于 Time of Arrival Window Endpoint (TOAWE)的一个正值。在NODEB侧传输信道建立、增加以及重配置时，定义配置接收窗口。接收窗的值（TOAWS，TOAWE）是相对于接收端LTOA的值而定的。协议中规定TOAWS的值是相对于TOAWE的一个正值。TOAWE是相对于LTOA的一个正值。LTOA是Node B内部定义的能够来得及处理接收帧的最短时间。LTOA是在数据帧发向空中接口前的处理时间，在LTOA之后接收的数据帧将不能处理而丢弃。在传输承载建立期间，TOAWS和TOAWE可以改变。设置窗口的目的是当传输信道上接收数据帧时，检查数据帧是否落在接收窗内。如果数据帧落在接收窗之外，Node B将向RNC发起定时调整控制帧，该控制帧中包含TOA的信息。UL同步控制帧总是作为DL同步控制帧的响应发送。这些用于调整使用的偏移值。取值范围：0, 1279，单位：ms。影响范围：CELL。取值分析：配置该参数的目的是确保RNC发送的下行帧能在Node B的处理范围内收到，并尽可能减小在Node B的缓存和处理负荷。如果时间窗口的取值不合理，则会导致业务面在Iub接口上进行频繁的时间校准，RNC频繁地调整下行数据的发送时间点，使得业务面的丢帧率增加，稳定性变差，业务性能下降。在收到下行数据之后，RNC经过内部处理，然后在Iub接口上传输，经过Node B的处理，最后将此帧数据发送到空中。下行数据经历的时延分布包括：RNC的固有处理时间Tri（RNC Intrinsic delay）、RNC的时延抖动Trj（RNC delay Jitter）、Node B侧的固有传输时延Tnb_ti（Node B Transport Intrinsic delay）、Node B侧的传输时延抖动Tnb_tj（Node B Transport delay Jitter）、数据在Node B的缓冲时间Tnb_buf，以及数据在Node B的处理时间Tproc。下行数据在RNC和Node B经历的时延点分析计算ToAWS时，应考虑到以上时延因素。TOAWS不能设的过小。否则，容易造成下行数据达到时间落在窗外。建议值：80。产品线预警：YJ0051关于金华业务出窗问题预警金华及其他城市现网，或多或少存在Iub接口业务出窗的现象，具体表现为基站侧有数据出窗的告警，可能有伴随着业务接入失败的现象。影响Iub口业务丢包，由于丢包可能会影响业务接入KPI指标。窗口设置过小，或NodeB的处理时间Tproc设置过小，会导致Iub接口容易出窗，节点同步的周期性同步时长过大，会导致Iub接口时间容易偏移。问题规避方法：目前，出窗的问题还没有最终完全定位，可以通过修改参数进行一定程度上的缓解和规避：1）修改TOAWS和TOAWE参数为80和10。2）修改NodeB的处理时间Tproc，从56修改为80（即由7ms修改为10ms）。6. TOAWE参数含义：TOAWE是接收窗口的结束点。下行链路数据帧期望在此窗口结束点之前被收到。TOAWE定义为，相对于 Latest Time of Arrival (LTOA)的一个正值。因此，按照协议规定，TOAWS是相对于TOAWE而言的一个正值。TOAWS就是窗口的大小。TOAWS相对于LTOA的时间为：TOAWS+LTOA。取值范围：0, 2559 ，单位：ms。影响范围：CELL。取值分析：当TOAWE为0时，如果数据帧在TOAWE之后到达，此时会返回时间校准控制帧，使得RNC在此传输承载上发送下一帧数据时调整发送时间点。因此，如果配置ToAWE的取值大于零，则可以起到预警的作用，防止数据在LTOA之后到达。建议值：10。7. NodeB的处理时延参数含义：参数表示数据在发送到空口之前，在Node B的处理时间Tproc。下行数据经过Node B的处理，最后将此帧数据发送到空中。下行数据经历的时延分布包括：RNC的固有处理时间Tri（RNC Intrinsic delay）、RNC的时延抖动Trj（RNC delay Jitter）、Node B侧的固有传输时延Tnb_ti（Node B Transport Intrinsic delay）、Node B侧的传输时延抖动Tnb_tj（Node B Transport delay Jitter）、数据在Node B的缓冲时间Tnb_buf，以及数据在Node B的处理时间Tproc。下行数据在RNC和Node B经历的时延点分析取值范围：0, 65535 ，单位为1/8ms。影响范围：RNC。取值分析：产品线预警：YJ0051关于金华业务出窗问题预警金华及其他城市现网，或多或少存在Iub接口业务出窗的现象，具体表现为基站侧有数据出窗的告警，可能有伴随着业务接入失败的现象。影响Iub口业务丢包，由于丢包可能会影响业务接入KPI指标。窗口设置过小，或NodeB的处理时间Tproc设置过小，会导致Iub接口容易出窗，节点同步的周期性同步时长过大，会导致Iub接口时间容易偏移。问题规避方法：目前，出窗的问题还没有最终完全定位，可以通过修改参数进行一定程度上的缓解和规避：1）修改TOAWS和TOAWE参数为80和10。2）修改NodeB的处理时间Tproc，从56修改为80（即由7ms修改为10ms）。8. DPCH是否采用不连续分配参数含义：无线帧的连续分配，指每一帧的相应时隙都分配给某物理信道；不连续分配，即部分无线帧中的相应时隙分配给该物理信道。HSDPA用户包括：DPCH连续分配以及不连续分配两种情况。取值范围：0,1，1表示不连续分配；0表示连续分配。影响范围：CELL。4.10.10版本中，该参数在HSDPA信息表（rRrmHsdpa）中，参数名称为“DPCH是否采用不连续分配”；4.10.20版本中，该参数在算法过程参数表（rRrmTimer）中，参数名称为“HSPA中DPCH是否采用不连续分配。取值分析：在现网用户越来越多的情况下，H用户容量就会受到伴随DPCH码资源的限制。如何在不扩容的前提下承载更多的H用户，就需要打开HSDPA的伴随信道复用功能，来提高系统容量。现网配置的下行伴随信道一般在TS3上，而TS3上面已经有4个码道承载HS-SCCH，只剩下12个码道传输伴随DPCH，而每个用户的伴随DPCH占用两个码道，所以一个H载波最多接入6个H用户。通过把伴随DPCH改为“不连续分配”，可以接入更多的H用户。注意：T3G终端在伴随信道非连续的情况下，物理层发送存在问题。建议值：一般情况下，配置连续分配；伴随DPCH复用时，配置为“不连续分配”。案例：枣庄HSDPA伴随信道复用验证现象描述：DPCH不连续分配时，上传时出现RLC不可恢复性错误引发的小区更新，最终导致掉话。PS调度关闭时，测试是正常的。开始怀疑是基站有问题，查看基站没有相关告警；后来在4个基站反复验证，发现当DPCH不连续分配时，频率很高的出现RLC不可恢复性错误（此时上行误块率很高）引起的小区更新，开始几次UE也许会返回重配置完成消息，但几分钟后，又会上报小区更新，最终10S UE未响应导致掉话。刚开始测试用的是上海贝尔的数据卡，换成8130后，上传是正常的。此时测试DPCH连续分配时，上传都是正常的；PS调度关闭的情况下，上传也都是正常的。初步怀疑是T3G解决方案有问题。基站与终端的同事抓取了双方物理层LOG后，经过物理层译码与高层信令的联合分析，T3G终端同事明确终端处理上存在问题，即：T3G终端在伴随信道非连续的情况下，物理层发送存在问题。从基站侧来看，收到终端上发的测量报告，基站物理层译码均正常；收不到终端上发的测量报告时，是基站侧物理层没有译出终端上发的report，没有译出是由于终端发送信令的子帧号发生变化，T3G已经抓取了LOG进行分析。9. RIM过程消息重传次数参数含义：RANAP协议参数RIM全称RAN Information Management。RIM过程消息重传次数为0表示不开启NACC功能，非0表示开启NACC。网络辅助的小区改变（NACC）主要完成：n RNC获取GSM邻小区SI/PSI 过程，Iu接口是“DIRECT INFORMATION TRANSFER”消息（上下行），由于是面向“无连接”的消息，要通过GPM模块向SGSN发送消息，RSPA收到包含SI/PSI的“DIRECT INFORMATION TRANSFER”消息后转发到GPM，GPM记录SI/PSI并广播到所有RSPA。为了降低Iu接口的信令负荷，一个GSM小区仅发送一次。n GPM收到IuC消息后判断：如果存在该邻小区的SI/PSI，直接向该单板的IuC发送该GSM邻小区的SI/PSI信息；如果没有请求的邻小区的SI/PSI，记录消息中小区的参数，同时向SGSN发送DIRECT INFORMATION TRANSFER消息（包含RAN-INFORMATION-REQUEST/Multiple Report），请求这些小区的SI/PSI，并启动定时器T_RIR；如果定时器超时，没有收到包含“RAN-INFORMATION/Initial Multiple Report”的响应消息，需要重发请求消息，到达设定重传次数后停止。n Iuc收到DIRECT INFORMATION TRANSFER（包含RAN-INFORMATION/Initial Multiple Report、RAN-INFORMATION/Multiple Report）消息转发到GPM，GPM更新SI/PSI信息，并向所有IuC广播。n IuC收到GPM的消息，记录GSM邻小区的SI/PSI。取值范围：0,255 ，单位：次数。影响范围：RNC。取值分析：“RIM过程消息重传次数”为0不开启NACC，非0开启NACC。当不开启NACC时，IuC不给GPM发送请求GSM系统信息的消息。产品线预警：YJ0062 4.10.20RANAP协议过程表中RIM过程消息重传次数修改为0在4.10.20版本下，RNC打开网络辅助的小区改变（NACC）功能，在青岛、广州导致爱立信SGSN运行异常。1表示开启NACC功能，RNC会主动发起id-DirectInformation TransferINTEGER := 34消息（R7），目前现网SGSN的版本比较低，不支持该过程。另外，可能会导致部分厂家CN处理异常（比如爱立信）。问题规避方法：将RANAP协议参数中的ucRIMNum参数由1修改为0。10. 0k/8k最大比特率问题参数含义：上行RAB表、下行RAB表中最大比特速率表示上行、下行所能支持的最大速率。取值范围：单位bps。影响范围：RNC。取值分析：按照正常情况下，0k、8k业务对应的最大速率分别为0k、8kbps。基于4.10.10版本以及之前的版本RRM算法上的局限，PS调度开关打开后，4.10.10版本以及之前的版本，不希望下调时进入0k、8kbps，因此，将静态业务参数上/下行RAB信息集中，0k、8k业务对应的最大速率设置为5000000。将0k、8k最大比特率设置为5000000，是为了规避41010实现上的缺陷。即使设了最低档，PS调度时仍然还往下调整，为了不让用户感知差，才把8k最大比特率调到5000000，意思是不让下调的速率低于16k。n 案例：南京现网RNC升级后，对PS调度相关参数做过优化。外场测试反映部分终端的PDP能够成功激活，但下行几乎没有速率。对小区跟踪的LOG进行分析，发现都是由于UE在做PDP激活时，没有给RNC携带速率，此时CN在RAB指派消息中携带的是一个异常速率8640000 bps（也有可能是96000000） 。n 案例分析：UE做PDP激活时，UPLINK DIRECT TRANSFER消息中没有给RNC携带速率，大部分诊断都是携带速率的。RAB ASSIGNMENT REQUEST消息中，CN指派的上/下行速率都为8640000，不是协议规定的标准速率。此时由于CAC算法的限制，上行按照64K来接入；R5终端的下行不受CAC的限制，下行按照RAB指派速率8640000来接入。RNC给NODEB指派的RADIO LINK RECONFIGURATION PREPARE消息中，上行分配的是64K，下行实际分配的速率为0K。因此，用户PDP激活后，下行没有速率。查看静态业务参数配置集/下行RAB信息集，0k交互类业务索引对应的最大速率为5000000。用户在申请8640000速率时，由于不是协议规定的标准速率，没有此索引，因此降速至5000000上来接入，实际对应的是0K的业务速率。因此，虽然PDP能够成功激活，但下行几乎没有速率。把静态业务参数配置集/下行RAB信息集下的0k交互类业务索引对应的速率改为最大值16000000，现场验证速率正常，此时，用户降速到2800000速率对应的索引来接入。考虑到外场大量上网本CN指派的速率都是不规则的，用户接入后，速率很有可能异常，因此需要做如下修改来规避上述问题。n 解决措施：对于4.10.10版本，将0k、8k最大比特率设置从5000000修改为16000000或更大，可以规避4.10.10版本下CN指派的上/下行速率都为8640000bps，下行几乎没有速率的情况。 4.10.20版本可以按照最低档调度，0k、8k业务对应的最大速率分别为0k、8kbps。11. 传输信道同步次数参数含义：传输信道同步过程用来获取或恢复DCH数据流在下行方向上的同步。传输信道同步次数指SRNC向Node B发送DL SYNCHRONISATION的次数。同步过程由SRNC发起，SRNC向Node B发送一个DL SYNCHRONISATION控制帧，消息中指定了目标CFN。当收到DL SYNCHRONISATION控制帧后，Node B立即以UL SYNCHRONISATION控制帧响应，消息中应包含DL SYNCHRONISATION控制帧的ToA以及DL SYNCHRONISATION控制帧中指示的CFN。DCH同步过程取值范围：1,3，单位：次。建议值：2次。影响范围：RNC。取值分析：外场多次出现RNC向Node B发送DL SYNCHRONISATION，RNC高层没有收到响应帧。具体原因没有定位出来，传输信道同步次数设置小，容易出现同步失败的情况。为了规避这种情况，暂且将同步次数设置大些。产品线预警：YJ0074传输信道同步次数规避传输信道同步失败问题。目前，外场多个城市出现由于传输信道同步失败导致的L2配置失败，有些城市对业务接入成功率的影响较小，有的城市影响较大。影响4.10.10及4.10.20版本。问题可能原因：1）RNC没有发出传输信道同步帧。2）RNC发送给NB，结果中间传输丢掉了，NB没有收到。3）RNC发给了NB，NB收到后给RNC发了响应帧，结果中间传输丢掉了，RNC没有收到。4）RNC发给了NB，NB收到后给RNC发了响应帧，RNC底层收到了响应帧，高层没有收到响应帧。问题规避方法：通过修改IUB同步定时器配置集-Iub同步定时器表传输信道同步次数，由原先的1次修改成2次。传输信道同步帧为什么发出去没有响应，暂时没有最终定位，可以通过上述参数优化进行规避。12. 寻呼指示长度参数含义：该参数定义寻呼指示信道的寻呼指示长度。NPI:：表示一个PICH帧中寻呼指示的数目，它的值可由表得到。其中，LPI的取值在SIB5/6中广播给UE。表: 每个无线帧中PI长度为LPI时对应的NPILPI=2LPI=4LPI=8NPI per radio frame884422取值范围：取值范围：(2,4,8)。影响范围：CELL。取值分析：寻呼指示长度越大，一个PICH帧中寻呼指示的数目越少，该参数设置大了会增大寻呼的可靠性，但同时会降低每一PICH帧中的寻呼指示数目。建议值：8产品线预警：YJ0075 RNC修改寻呼指示长度导致UE无法接收寻呼。目前，外场在修改寻呼指示长度后，由于有BUG，修改寻呼指示长度，RNC仅发系统更新，没有触发自动小区删建，导致NB和UE侧信息不一致，UE无法正常接收寻呼。影响现网4.10.10及4.10.20版本。规避办法：修改寻呼指示长度后，需要手动去激活激活小区。CRM00013022后续版本在修改寻呼指示长度时触发小区自动删建。13. 给UE重发RRC连接释放消息的最大次数参数含义：表示RNC端给UE发送RRC CONNECTION RELEASE消息重发最大次数，以保证可靠地释放建立在专用信道上的RRC连接。When the UE is in state CELL_DCH or CELL_FACH, the UTRAN may at anytime initiate an RRC connection release by transmitting an RRC CONNECTION RELEASE message using UM RLC.UTRAN may transmit several RRC CONNECTION RELEASE messages to increase the probability of proper reception of the message by the UE. 取值范围：0,15。影响范围：RNC。取值分析：(1) SRNC通过DCCH信道向UE发送RRC连接释放消息RRC CONNECTION RELEASE，SRNC发送3次，来提高UE接收的可靠性。(2) UE向SRNC返回RRC连接释放完成消息RRC CONNECTION RELEASE COMPLETE。(3) SRNC向NodeB发送无线链路删除请求消息RADIO LINK DELETION REQUEST，删除NodeB中的无线链路资源。(4) NodeB资源释放完成后，向SRNC返回无线链路删除响应消息RADIO LINK DELETION RESPONSE。(5) RNC使用ALCAP协议发起Iub接口用户面传输承载的释放。RRC释放过程结束。根据预警将该参数改为3，原来为0。产品线预警：昆明“给UE重发RRC连接释放消息的最大次数”配置为0导致UE PDP去激活时收不到RRC RELEASE。昆明存在终端去激活PDP后收不到RRC RELEASE消息的现象，导致最后UE发起小区更新。对接通和掉话没有影响，但是会引起UE释放PS信令连接异常，异常期间会影响UE收寻呼。问题可能原因：RRC RELEASE消息采用RLC UM模式发送，如果网络侧不配置RRC层的重发，那么很有可能会导致UE收不到该消息，引起UE释放异常。问题规避方法：在下图中参数修改为3。影响范围：二期和三期采用TDR3000的4.10.10和4.10.20版本的项目。14. PDCP头压缩算法参数含义：目前有RFC2507头压缩算法、RFC3095头压缩算法。取值范围：0,1，0表示不存在；1表示存在。影响范围：RNC。取值分析：目前不打开头压缩算法。产品线预警：YJ0057产品线预警-宁波PDCP头压缩算法未关闭导致DSP故障问题宁波项目升级RNC版本TDR3000_V4.10.10.65.02_P400_20090916后 ，发现RNC的RTPA板存在DSP复位现象。初始化DSP故障对业务没有影响，对运行正常之后的DSP可能会发生故障，会影响DSP上承载小区去激活再激活，其上承载的业务中断。DSP复位起来后小区和业务会恢复。问题规避方法：将PDCP头压缩算法关闭，具体修改如下三个参数：rPdcp表的PdcpPduHeaderTag字段从0（表示存在）改为1（表示不存在）；rPdcpRfc2507表的Rfc2507Tag字段从1（表示有效）改为0（表示无效）；rPdcpRfc3095表的Rfc3095Tag字段从1（表示有效）改为0（表示无效）；问题影响范围：二期和三期采用TDR3000的4.10.10和4.10.20版本的项目。15. 下行时隙汇聚开关（4.10.20新增）参数含义：在“TD-SCDMA基站节电测试规范”中，要求RNC支持下行时隙汇聚功能。当载波下行时隙中用户分布离散的情况下，能够把用户集中在一个或者多个下行时隙中，从而腾出一个或者多个时隙，使基站能够关断空闲时隙的发射通道。在基站的节能降耗需求中，关断一个或多个时隙时，要求同一频段的所有载波，相同下行时隙都空闲时，才可以关断该时隙。因此，对于RNC而言，要求支持载波下行时隙汇聚功能，同时，尽量保证同一频段的所有载波都能空闲出相同的时隙来。根据中移动需求，时隙汇聚要可以设定开启时段。时隙汇聚功能仅针对下行DPCH资源，而且这里的时隙汇聚，不考虑TS0。取值范围：0,1，0表示关；1表示开。影响范围：CELL。FDCA信息表。取值分析：与此开关相关的参数：在算法全局表中，时隙汇聚是否使用时间段标记010时隙汇聚时间段有效标记。0-无效,1-有效。如果时段有效标志为“无效”，则认为全天都在有效时段以外。如果时段有效标志为有效，且起始时间与终止时间相同时，按照全天有效对待。动态(可创建、可修改时隙汇聚规划的时间段起始时刻01439无时隙汇聚时间段有效标记为1时有效配置值/60后向下取整表示时,在023之间。配置值模60后表示分,在059之间。动态(可创建、可修改时隙汇聚规划的时间段终止时刻01439无时隙汇聚时间段有效标记为1时有效，配置值/60后向下取整表示时,在023之间，配置值模60后表示分,在059之间。动态(可创建、可修改16. 是否支持HSDPA/HSUPA空分复用（4.10.20新增）参数含义：移动要求在包含多个HSDPA载波的小区，RNC能把同一通道的HSDPA用户分配到不同载波，以提高空分复用的使用概率。移动“TD-SCDMA新站型测试HSDPA功能测试规范”中，要求空分复用功能载波级可控制。针对移动的需求，在操作维护配置载波空分复用的开关。为H用户（包括HSDPA、HSUPA）分配资源时，优先分配支持空分复用的载波，其次，考虑不支持空分复用的载波。空分复用功能仅用于非智能天线小区。取值范围：0,1，0表示不支持；1表示支持。影响范围：CELL。取值分析：n 在载波下增加属性“是否支持HSDPA空分复用”、“是否支持HSUPA空分复用”。n 小区下SDCA信息表中，增加“HSPA空分复用系数”。取值范围14。默认为1。n FDCA算法参数中“频率优化DCA开关”定义新的取值3，表示打开 “频率优化的DCA”且采用“基于通道号的方法”。FDCA算法参数中，增加参数“用户数门限”（UserNumTh），取值范围116。参数含义“基于通道号调整时的用户数门限”。默认值1。参数关联关系：当小区算法过程参数表中的“该小区是否使用智能天线”为1时（即支持智能天线）、或者该载波没有配置HSDPA资源，则载波中“是否支持HSDPA空分复用”必须配置为0（不支持空分复用）。当小区算法过程参数表中的“该小区是否使用智能天线”为1时（即支持智能天线）、或者该载波没有配置HSUPA资源，则载波中“是否支持HSUPA空分复用”必须配置为0（不支持空分复用）。当小区算法过程参数表中的 “该小区是否使用智能天线”为1时（即支持智能天线）时，FDCA算法参数中“频率优化DCA开关”不能取3，SDCA信息表中的“HSPA空分复用系数”必须配置为1。当小区算法过程参数表中的 “该小区是否使用智能天线”为0时（即不支持智能天线）时，小区算法过程参数表中的“是否支持FACH赋型”必须为0（0=不支持），FDCA算法参数中“频率优化DCA开关”不能取1。FDCA算法参数中“频率优化DCA开关”取3时，至少有一个载波的“是否支持HSUPA空分复用”或者“是否支持HSDPA空分复用”为1。只有当“该小区是否使用智能天线”为0时，RACH帧中携带的AOA信息才可能是通道号。对于非智能天线小区，当HSDPA或HSUPA支持空分复用功能时，基站在RACH帧中所携带的AOA信息表示UE所在的通道号。根据Iub接口技术规范（2009年4月修改），RACH帧中的AOA信息如果表示通道号，则取值范围对应0255，表示绝对通道号（即AOA信息为0，表示通道0，AOA信息为1，表示通道1，依此类推）。UE在发送RRC连接建立请求、或者小区更新、或者通过RACH发送其他信令/数据时，基站将UE的通道号信息通过RACH帧通知给RNC。如果“该小区是否使用智能天线”为0，则RNC实时更新UE所在的通道号（UE通道信息初始化为全F，表示不属于任何一个通道）。当UE服务小区发生改变时，清空UE的通道号信息（通道信息置为全F）。17. 是否启用User Inactive功能开关参数含义：User Inactive功能是指对UE的非实时业务进行流量监控，当非实时业务在监视定时器超时后，仍无流量或者流量低于指定门限，就主动释放该业务，或者释放PS域Iu连接（RNC向CN发起RAB释放请求，或者Iu释放请求，释放原因填写为：User Inactivity）。取值范围：0,1，0表示不启用；1表示启用。影响范围：CELL。取值分析：打开此功能的前提条件：n “业务量测量报告的PS算法开关”打开，而且n 小区不支持UE进入PCH状态。 V4.10.10版本，小区下“是否不支持用户跃迁到CELL_PCH”配置为1（即“不支持”）； V4.10.20及其以上的版本，小区下“业务量为零时是否将用户跃迁到PCH状态”配置为0（不支持）。n 0K的业务量测量门限必须配置。新增参数：UserInactiveTag是否启用User Inactive功能开关011是否启用User Inactive功能开关0-不启用，1-启用。默认-1动态(可创建、可修改ReleaseTypeTag释放方式011释放方式：0-RAB释放，1-Iu释放，默认-1动态(可创建、可修改UserInactiveTHUserInactive业务量门限0655358业务量门限单位：byte动态(可创建、可修改UserInactiveWaitTimerUserInactive等待定时器065535120根据出来报告，判断业务量在设定的“User Inactive”门限以下，如果在该门限以下，启动定时器。单位：秒动态(可创建、可修改PchIuRelWaitTimer进入PCH态释放Iu等待定时器065535300当进入PCH后，启动定时器，如果在定时器超时后，状态没有跃迁，则释放Iu。单位：秒动态(可创建、可修改18. PCH RLC Size参数含义：RLC Size参数出处 Cell Update Confirm Handover to UTRAN Command RRC Connection Setup Radio Bearer Setup Radio Bearer Reconfiguration Radio Bearer Release Transport Channel ReconfigurationRLC size反映了RLC PDU大小，根据各种业务对应的RLC PDU大小进行配置。RLC PDU：在AM模式下，RLC PDU分为数据PDU和控制PDU，控制PDU又包括状态PDU（STATUS PDU）、捎带状态PDU（Piggybacked STATUS PDU）、重置PDU（RESET PDU）和重置确认PDU（RESET ACK PDU）四种类型。数据PDU用于传输高层的数据，控制PDU用来传输相关的控制信息。状态PDU和捎带状态PDU可以由不同的超域（SUFI）组成。一共有NO_MORE、WINDOW、ACK、LIST、BITMAP、Rlist、MRW和MRW_ACK等8种超域，每个超域指示一定的信息。寻呼消息是在PCH传输信道上传输，一个小区内可以建立一条或多条用于承载寻呼消息的PCH传输信道。对每一PCH，都有一条寻呼指示信道（PICH）与之相伴，两者共同构成一个寻呼块。寻呼指示信道（PICH）不承载传输信道的数据，但却与传输信道PCH配对使用，用以指示特定的UE是否需要解读其后跟随的PCH信道。在解读出的PCH寻呼块中，不全是自己的寻呼消息，还需要根据解读消息中IMSI或是TMSI来判定是否是自己的寻呼消息。取值范围：Integer(0.4992)；单位：bits。影响范围：RNC。取值分析：产品线在西安测试中发现，在RLC size为80，RNC重发次数为3的寻呼参数配置条件下，西安TD网络寻呼成功率较低，核心网的统计显示成功率只有70%多，近30%多的寻呼失败。在RNC上进行基于DSP的统计发现，每个DSP上均有大量的由于“调度失败”而引起RNC将该寻呼消息丢弃的现象。对于因“调度失败”而引起的RNC将该寻呼消息丢弃的问题，这种现象在各地项目中是普遍存在的。如果将RLC size从80改为240，RNC重发次数从3改为2或1，仅从提高寻呼成功率的角度考虑是会带来改善；但是会带来例如误码率升高的弊端。所以，要综合考虑利弊，根据需要进行调整。对各地寻呼参数配置建议如下：1. 根据各地现网的频率配置情况和干扰的情况，进行寻呼参数的调整；2. 对于频率复用系数为6，且干扰控制较好的城市，则设置PCH RLC size=240；对于容量不大的城市，可先将RNC重发次数设置为2，并且观察有无RNC将寻呼消息丢弃的现象，若无丢弃，则保留设置为2；否则，RNC重发次数设置为1。注意：TFS索引由93改为94，PCH RLC size由80改为240后，该操作完成后，需要将小区去激活、再激活，使修改生效，否则，会出现寻呼发不出去。19. UE能力参数含义：UE能力的参数很多，暂时只考虑PDCP参数、RLC参数、TRCH参数及物理信道参数。如下表所示：UE无线接入能力参数值域协议版本PDCP parameters支持RFC 2507与否Yes/No最大的头压缩上下文空间512, 1024, 2048, 4096, 8192 , REL-5新增：16384, 32768, 65536, 131072bytesSupport for loss-less SRNS relocationYes/NoREL-4支持RFC 3095与否Yes/NoREL-4 Maxi