后台配合指导书(RAN12).docx

后台配合指导书(RAN12)Tyler一、 上海联通WCDMA双载波策略1. 总体描述双载波即同一个扇区有两个不同频率的同覆盖小区。上海使用频点主要有3个：F1 ：10713对应SPG=1， F2： 10688对应SPG=2，F3： 10663对应SPG=3。F1用于宏站第一载波，优先承载R99业务；F2用于宏站第二载波，优先承载HSDPA业务；F3作为室分频点使用。一般F2小区Bar掉（见上面BAR掉2载波），限制接入，空闲态的UE只驻留在F1，除RNC边界上F2小区是允许驻留主要是对H业务的DSCR来考虑的。F2和同覆盖F1互配为盲切换邻区关系，盲切换标识为TRUE，优先级为0，F2向周围F3小区加基于覆盖的异频邻区，F3不配向F2的异频邻区。F2将周围F1配为异频邻区关系（仅局限于周边区域），将周围F2配为同频邻区关，F2和F1都需配周围GSM邻区关系。2. BAR掉和恢复2载波1. BAR掉2载波2. 恢复被BAR掉的载波由于2载波的特殊性，在做宏站无线层数据规划需要注意一下两点：1) 新建站归属于BAR掉2载波的RNC时，1载波SPGID=1，2载波SPGID=2；2) 新建站归属于没有BAR掉2载波的RNC时，无论1载波还是2载波，SPGID=3；3. 同覆盖异频邻区 按照上海双载波策略要求，在BAR掉2载波的RNC上配置同覆盖异频邻区时需要注意以下部分：（1） 在SIB11下发指示：FALSE（不下发），表示该邻区关系不在SIB11中下发 ；（2） 异频覆盖切换优先级：0，表示不支持异频覆盖切换 ；（3） 盲切换标志：TURE（是），表示加邻区关系的2个小区间进行盲切换 ；如下图示： 按照上海双载波策略要求，在没有BAR掉2载波的RNC上配置同覆盖异频邻区时需要注意以下部分：（1） 针对已经BAR掉2载波，并已添加同覆盖异频邻区的需做如下修改命令（使用时只需将CI修改即可）：（2） 针对新建站点，无需BAR掉2载波，在添加同覆盖异频邻区时，需注意：a) 在SIB11下发指示：TURE（下发），表示该邻区关系SIB11中下发 ；b) 异频覆盖切换优先级：0，表示不支持异频覆盖切换 ；c) 盲切换标志：FALSE（否），表示加邻区关系的2个小区间不进行盲切换 ；如下图示：二、 修改导频功率修改小区导频功率在后台配合测试中经常出现，是常用手段。导频功率修改分为两种情况：降功率、升功率。1. 降功率1) LST UPCPICH，查询小区当前导频功率；2) MOD UPCPICHPWR，先修改PCPICH最小发射功率（=小区导频功率-17）；3) MOD UCELL，修改小区PCPICH功率；4) MOD UPCPICHPWR，修改PCPICH最大发射功率（=小区导频功率+16）；5) LST UPCPICH，查询修改后的小区导频功率；eg:将A小区导频功率从330降到270（即降6个dBm）。第一步：LST UPCPICH：查询A小区当前导频功率为330，PCPICH最大发射功率为346（=330+16），PCPICH最小发射功率为313（=330-17）；第二步：MOD UPCPICHPWR：将小区PCPICH最小发射功率修改为253（=270-17）；第三步：MOD UCELL：将小区PCPICH功率修改为270；第四步：MOD UPCPICHPWR：将小区PCPICH最大发射功率修改为286（=270+16）。2. 升功率按照小区导频功率升后是否超过小区配置的功率license，分为2类，超过和未超过。现网小区功率license一般配置为20W,即最大功率设置330，所以这里以小区导频功率升后是否超过330分为两类：超过330（如升到360）、未超过330（如从270升到330）。1) 升后功率未超过330 LST UPCPICH，查询小区当前导频功率； MOD UPCPICHPWR，先修改PCPICH最大发射功率（=小区导频功率+16）； MOD UCELL，修改小区PCPICH功率； MOD UPCPICHPWR，修改PCPICH最小发射功率（=小区导频功率-17）； LST UPCPICH，查询修改后的小区导频功率；eg:将A小区导频功率从270升到330（即升6个dBm）。第一步：LST UPCPICH：查询A小区当前导频功率为270，PCPICH最大发射功率为286（=270+16），PCPICH最小发射功率为253（=270-17）；第二步：MOD UPCPICHPWR：将小区PCPICH最大发射功率修改为346（=330+16）；第三步：MOD UCELL：将小区PCPICH功率修改为330；第四步：MOD UPCPICHPWR：将小区PCPICH最小发射功率修改为313（=330-17）。2) 升后功率超过330总体流程：先申请大功率license，再修改导频功率 申请大功率license。申请大功率license是在M2000上完成的，如下图示：申请流程如下：a) 打开M2000主界面，按照上图的顺序点击，即可；b) 点击3下面的“网元名称”，选择要修改导频功率的小区所属的基站，然后向右边拉，会出现下图所示界面：第一行表示license的类型，如43dBm表示是20W的license（即导频功率最大可以设置为330），46dBm表示是40W的license（即导频功率最大可以设置为360），47.8dBm表示是60W的license（即导频功率最大可以设置为378）；上图首行中间的“77/278”表示整个RNC共计有278个40W的license，目前已用77个，剩余201个可以分配给基站使用（如果没有剩余则不能申请）。c) 选中要升功率的小区所属的基站行，双击，出现下图所示界面：上图红框2表明选中基站所拥有的本地小区数目：3个，红框1表明此站拥有3个20W的license、0个40W的license、0个60W的license，红框1中的3个数字之和应该等于红框2中的数字（理想情况下）。如果：330要升到的功率值=360，则将上图红框1中的PA（46dBm）后面的0改为1（表示此站有一个小区的导频功率最大可以升到360 dBm）；360要升到的功率值=378，则将上图红框1中的PA（47.8dBm）后面的0改为1（表示此站有一个小区的导频功率最大可以升到378 dBm）。d) 完成上面的步骤后，再回到第一步打开的界面中的A区域，选择默认的那行，如下图示：右键先选择“分配”，完成后再选择“同步许可证”即完成大功率license的申请、分配。另：如果某小区存在CE拥塞、或者CE不足导致吞吐率问题需要修改、申请CE资源时，操作同如下：（1）打开许可证；（2）选中基站双击，出现下图 ：（3）在基站侧执行 DSP BBPTC,查询基带板业务能力，可以获知支持的最大上、下行CE数；（4）修改上行、下行CE资源值，如上图红框所示；（5）选择“分配”，分配CE资源，然后再选择“同步许可证”。 申请大功率license后升功率过程a) LST UPCPICH，查询小区当前导频功率；b) MOD UPCPICHPWR，先修改PCPICH最大发射功率（=小区导频功率+16）；c) MOD UCELL，修改小区最大发射功率（如460、478）和PCPICH功率（如360、378）；d) MOD UPCPICHPWR，修改PCPICH最小发射功率（=小区导频功率-17）；e) DEA UCELL 去激活小区f) MOD ULOCELL （在基站侧执行）配置NODEB上小区最大发射功率（如460、478，要求与第三步在RNC上设置的小区最大发射功率保持一致）g) ACT UCELLh) DSP UCELL，注意查看小区状态HSDPAHSUPA是否正常i) DSP UCELLCHK 查询小区健康状态，注意查看RNC配置的小区最大发射功率dBm 与NodeB上报的小区最大发射功率dBm 是否一致（要求一致）j) LST UPCPICH，查询修改后的小区导频功率三、 吞吐率1. 查询基站E1和FE配置1) E1查询方法登陆基站侧的本地维护终端，输出MML命令：DSP IMGRP，可以查询到基站配置E1以及处于激活状态的E1数目（有的时候会出现配置2根实际处于激活状态的只有1根，此时吞吐率只有1根E1的量）。一根E1最大支持2Mbps吞吐率。2) FE查询方法1) 在RNC上输入命令：LST ADJNODE，选择按照邻节点名称查询，输入基站名（没有基站编号），可以查到邻节点标识2) LST IPPATH，输入上面查到的邻节点标识，返回结果显示此站是否配置FE以及FE带宽是多少3) DSP IPPATH，输入上面查到的邻节点标识，查询FE PING检测结果及丢包率，如果PING检测成功且无丢包，则FE正常；反之，则不正常。2. 常见吞吐率不达标原因1) 基站与RNC上脚本未刷对于新入网小区，要求在基站与RNC上刷以下脚本，即在基站侧本地维护终端和RNC本地维护终端上，执行以下脚本：2) 小区HSDPA和HSUPA未激活小区HSDPA和HSUPA未激活，H业务就会承载在R99上，导致吞吐率不达标。 DSP UCELL，可以查询小区HSDPA和HSUPA是否激活； ACT UCELLHSDPA，激活小区HSDPA业务； ACT UCELLHSUPA，激活小区HSUPA业务；注：现在网络升级到RAN12后，工程那边自动导入的CME数据中是不包含小区HSUPA数据的，所以有时由于工程疏忽，忘了单独配置HSUPA数据，网优会发现某个小区没有配置HSUPA数据，这时我们可以自己配置，操作如下：在对应的RNC上执行MML命令：ADD UCELLHSUPA，后面的参数项全部默认，如下图：配置完后不要忘记激活HSUPA，执行MML命令：ACT UCELLHSUPA.3) 背景噪声设置不当这种现象集中体现在室分测试上面，因为室分是一个小区下面挂多个RRU，且工程经常是部分开通，导致网优测试背景噪声未来得及更改，导致现场测试吞吐率不达标。一个小区下挂的RRU数目直接影响此小区的底噪值（即背景噪声），而底噪值又影响小区RTWP值，三者关系如下：（N为小区下挂RRU数目）小区底噪值=61+100logN，常用关系：RRU数目底噪16129131094121小区正常状态下RTWP=-112+(低噪-1)/10底噪正常RTWP61-10691-103109-101.2121-100解决方案 在基站维护台上LST RRU，可以查询此站共有几个RRU；执行DSP LOCELL，可以查看每个小区存在的可用RRU数目，据此数目可以确定小区的底噪值。 在RNC上LST UCELLCAC，查询小区当前底噪值，如果与上一步确定的底噪值不一致，则执行MOD UCELLCAC，将小区底噪值修改为前面确定的底噪值。4) 邻节点映射关系错误ADJMAP即邻节点映射关系，若设置不当也会对吞吐率造成影响（主要是对开通FE的站点）。在RNC上执行LST ADJMAP，按照邻节点查询，可知此小区的ADJMAP设置：如上图示：在RNC162下，15、16、17对应的是高QoS分路IP实时业务承载，即传输走的是FE；，非15、16、17对应的就是ATM非实时业务承载，即传输走的是ATM；。对于开通FE的站点这里应该是15、16、17，否则H业务达不到FE要求的吞吐率。注：上面的151617在每个RNC下不是一致的，所以为了确认在当前RNC下设置多少值代表FE，可以在当前RNC下执行MML命令：LST ADJMAP，不设置任何参数，直接执行，如下图：5) 元器件（RRU）问题发现在某个小区下的个别RRU下上传吞吐率不正常，经核查发现这些RRU的RTWP明显高于正常值-106，如-95，这时确认是RRU的问题，通知工程去整改。具体操作方法：登陆NODEB维护端，选择“维护”“单板级RTWP测量”，输入对应的RRU的编号，即可。如下图：注：基本上元器件引起的上行吞吐率不达标都会伴随RTWP异常问题，所以有时我们可以通过RTWP异常来判断是否存在元器件安装问题，如功分器、合路器等。6) 测试APN设置错误测试现场发现下行吞吐率只有2Mbps，经查网优参数设置无误，由此怀疑测试人员的测试用APN设置错误。通过查看信令中的RANAP-DIRECT-TRANSFR（包含PDP激活请求的那条），确认终端向核心网进行业务请求时的接入点为UNINET，如下图示：此时接入点为：UNInet（最大带宽2Mbps），所以测试吞吐率只有2Mbps也就正常了。目前大家测试用的APN应该是3gnet（最大带宽7.2Mbps），修改APN的方法请参考probe用户指导书140页。7) FTP问题由于目前FTP是大家共用的，所以会存在测试文件被别的同事给误删了，这样在测试时就会发生H业务刚激活马上提示PDP去激活，这时建议去FTP查看下自己使用的目录文件是否存在。8) 工程侧参数设置不当测试中发现安基大厦上行吞吐率较低，无法达到测试要求。RNC侧检查发现此站当前告警中存在license文件配置异常告警，由此确认license配置存在问题。进一步检查基站license配置发现，此站点原本HSUPATTI没有配置，后经过协调工程完成配置，现场测试上传正常，如下图示：注：HSUPATTI现网标配每个基站为1四、 常见掉话原因目前碰到掉话主要有下面常见原因：1. 网元版本未升级此类问题多发在室分测试，现场测试发现掉话，且掉话前目标小区覆盖、质量均非常好，达到切换条件，后台验证邻区也已经添加，则可能是由于源小区所属基站与目标小区所属基站网元版本不一致导致的。查看基站网元版本可以在M2000上完成，在拓扑图上选中基站，点击右键，选择“属性”，可以看到基站网元版本。现网通用版本：DBS3900 WCDMA V200R010C01SPC300和BTS3900 WCDMA V200R012C00SPC110，但是个别新开站由于工程疏忽未及时升级版本，导致网元版本停留在产品出厂版本：DBS3900 WCDMA V200R010C01B065。此时需要联系工程进行版本升级。2. 邻区漏配邻区漏配是测试出现掉话的常见原因，现场表现为源小区覆盖、质量已经变得非常差，而目标小区覆盖、质量都非常好，但是并没有发生切换，直至掉话，掉话后UE重新接入在目标小区上邻区漏配解决方法：1) 现场测试人员将掉话前、掉话后重新接入UE占用小区信息告知机房侧，后台配合人员在现网查询掉话前后小区是否邻区漏配。如果漏配，增加相应邻区。2) 后台配合人员自己通过跟踪UE标准接口信息获取掉话前后UE所占用的小区不一致，也可以怀疑是邻区漏配问题。如何在跟踪的信令中得知当前的RRC和业务连接是承载在哪个小区上的？如上图红框中所示，to UE和from UE的消息中“用户”列所示值即为小区ID，这样即可确认掉话前后小区信息，然后在现网查询掉话前后小区是否邻区漏配（此时也可以通过测量控制进一步进行确认邻区是否漏配）。如果漏配，增加相应邻区。与邻区相关的常见的MML命令： 查询邻区：同频邻区查询：LST UINTRAFREQNCELL；异频邻区查询：LST UINTERFREQNCELL；GSM邻区查询：LST U2GNCELL; 增加邻区：增加同频邻区：ADD UINTERFREQNCELL；增加异频邻区：ADD UINTRAFREQNCELL；增加GSM邻区：ADD U2GNCELL； 删除邻区：同频邻区删除：RMV UINTRAFREQNCELL；异频邻区删除：RMV UINTERFREQNCELL；删除GSM邻区：RMV U2GNCELL;五、 其他常遇问题1. 扰码修改有时会遇到小区扰码需要修改的情况，具体如下：（1） 在现网查询此小区是否在其他RNC被定义了外部小区：在M2000 MML命令上选中10套RNC，执行LST UEXT3GCELL，查看执行结果即可。如果在其他RNC被定义则接下来需要执行第2、3步，否则只需要执行第2步；（2） 扰码修改三步走： 去激活小区：DEA UCELL 扰码修改：MOD UCELLSETUP 激活小区：ACT UCELL（3） 修改外部邻区定义。在第一步中找到的把此小区定义成外部小区的RNC上修改此小区的外部邻区定义：MOD UEXT3GCELL,如下图：将RNC163的小区11111在其他RNC的外部邻区定义的扰码修改为23。2. SAC问题小区信号覆盖和质量均正常、数据业务正常，但语音、视频业务均不能做，可能是由于核心网侧未加此小区SAC数据导致的。关于SAC：SAC即服务区码，现网配置与小区CI一致。LST UCELL,可以查询小区SAC号处理方法：（1） MOD UCELLACINFO，如下图示：将不能做业务的小区SAC换成已知正常的小区的SAC，如果此时可以打电话，则证明原SAC存在问题。（2） 在做完测试后需要改回小区SAC号、将小区去激活，并且做好问题记录，将情况反映给徐雪峰。3. RRC请求无响应测试现场反馈在室分小区下所有业务均无法做，即无法拨打电话、无法做H业务，检查各项参数设置无问题，跟踪UE标准接口信令，发现UE发送RRC建立请求后一直无任何相应。确认是工程传输问题，需工程整改。4. 驻波查询查询RRU驻波比：在NODEB上执行 DSP VSWR，即可。六、 后台信令消息1. CS/PS业务判断后台信令消息的“message source”列的值是非常有用的，通过它我们可以很容易区分UE此次进行的CS还是PS业务，如下图示：注：如前面所说，“message source”列的值是非常有用的，如表示当前激活集小区CI、RNC ID等： 表示RNC ：RNC的表示值与RNC实际值的对应表：信令值3101310231033104310531063107310831093110RNC值161162163164165166167168169170 表示小区CI：2. 判断SAC问题通过后台信令也可以判断出小区的SAC数据是否加了。由于SAC未加主要影响CS业务，所以我们需要关注CS业务是否正常。通常处理手段，通过跟踪小区的IOS，找到CS业务的信令判断SAC是否加了。上图所示的是小区SAC未加的情形。3. 外部邻区LAC错误导致跨RNC失败现场测试人员在新村路控制中心室分测试发现室内外切换总是失败，后台跟踪消息发现跨RNC迁移时失败，信令如下：查看relocation required可以看到迁移目标RNC和源RNC：但是通过将目标RNC170的LAC号转换为十进制后发现问题所在：上图中的A8 64转换为十进制后为43108，与现网RNC170的LAC号43018不一致，所以由此确认是由于外部邻区定义失败导致的迁移失败。七、 UPA和DPA不达标问题从End-to-End的角度来说, 整个通信链路上的每一个通信节点和接口都有可能导致所描述现象的发生.具体到HSPA的上下行,在UMTS的范畴内,这些节点和接口无非这么几个:UE(data card),air interface, NodeB, Iub link,RNC,IuPS link,核心网(SGSN/GGSN/HLR).1.在同一测试区域，HSDPA速率正常，HSUPA速率不达标，可能有什么原因.HSDPA速率正常,只能说明空中接口基本传输链路(HS-SCCH,HS-PDSCH,HS-DPCCH,associated DPCH)正常,以及下行的backhaul不存在拥塞,UE在合理的无线覆盖范围内且UE接收参数合理.但这不能保证上行的各个节点/接口都是通畅的. HSUPA速率不达标,体现在各个节点上的可能原因包括: - UE: 发射功率受限(传输TBS比较大的时侯).建议上Rel8的HSPA,采用E-DPCCH power boosting机制才好.在UE使用2ms TTI时也容易导致功率受限的情况,但目前现网中的数据卡好象都还不能支持2ms TTI. - air interface: 本小区的RoT已经比较高(通常上限为67dB)因而E-AGCH上给出的功率偏移本身就限制了高速率;或者某个邻小区的上行干扰已经比较严重因而在E-RGCH上发送down指令从而限制了UE在serving cell的能力发挥. - NodeB:看各家vendor各自的处理机制了.比如是否能够根据traffic特性动态调整CE分配以避免多用户时CE资源受限;NodeB是否有advanced receiver从而能够对高速上行数据做有效的信道估计和解调. - Iub link: 是承载在ATM上还是IP上.是否有上行的拥塞及丢包发生?如果存在此类现象的话,恐怕会触发Iub上的流控措施以迫使空口uplink降速以免NodeB buffer overflow - RNC: 也看各家vendor自身的处理机制了.通常RNC用户面的处理能力远远超过NodeB.但这里要保证RNC内部各关联的处理单元上没有受限的情况发生,以免在RNC上引起相关的降负荷措施而连累该UE的数据传输. - IuPS: 也要保证没有丢包和拥塞.现在有了One Tunnel,RNC可以直接和GGSN建GTP tunnel做数传了.现网中Iu接口带宽配置充分,通常不会在这里出问题. - 核心网: 保证该用户在HLR设备上有合法的签约数据并且GGSN不要实施降速限流类的策略,GGSN上防火墙设置是否合理,等. 最后还要看应用层的业务特