后台配合指导书RAN12.docx
《后台配合指导书RAN12.docx》由会员分享，可在线阅读，更多相关《后台配合指导书RAN12.docx（23页珍藏版）》请在冰豆网上搜索。
后台配合指导书RAN12
后台配合指导书（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）LSTUPCPICH，查询小区当前导频功率；
2）MODUPCPICHPWR，先修改PCPICH最小发射功率（=小区导频功率-17）；
3）MODUCELL，修改小区PCPICH功率；
4）MODUPCPICHPWR，修改PCPICH最大发射功率（=小区导频功率+16）；
5）LSTUPCPICH，查询修改后的小区导频功率；
eg:
将A小区导频功率从330降到270（即降6个dBm）。
第一步：
LSTUPCPICH：
查询A小区当前导频功率为330，PCPICH最大发射功率为346（=330+16），PCPICH最小发射功率为313（=330-17）；第二步：
MODUPCPICHPWR：
将小区PCPICH最小发射功率修改为253（=270-17）；第三步：
MODUCELL：
将小区PCPICH功率修改为270；第四步：
MODUPCPICHPWR：
将小区PCPICH最大发射功率修改为286（=270+16）。
2.升功率
按照小区导频功率升后是否超过小区配置的功率license，分为2类，超过和未超过。
现网小区功率license一般配置为20W,即最大功率设置330，所以这里以小区导频功率升后是否超过330分为两类：
超过330（如升到360）、未超过330（如从270升到330）。
1）升后功率未超过330
ØLSTUPCPICH，查询小区当前导频功率；
ØMODUPCPICHPWR，先修改PCPICH最大发射功率（=小区导频功率+16）；
ØMODUCELL，修改小区PCPICH功率；
ØMODUPCPICHPWR，修改PCPICH最小发射功率（=小区导频功率-17）；
ØLSTUPCPICH，查询修改后的小区导频功率；
eg:
将A小区导频功率从270升到330（即升6个dBm）。
第一步：
LSTUPCPICH：
查询A小区当前导频功率为270，PCPICH最大发射功率为286（=270+16），PCPICH最小发射功率为253（=270-17）；第二步：
MODUPCPICHPWR：
将小区PCPICH最大发射功率修改为346（=330+16）；第三步：
MODUCELL：
将小区PCPICH功率修改为330；第四步：
MODUPCPICHPWR：
将小区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（表示此站有一个小区的导频功率最大可以升到360dBm）；360<要升到的功率值<=378，则将上图红框1中的PA（47.8dBm）后面的0改为1（表示此站有一个小区的导频功率最大可以升到378dBm）。
d）完成上面的步骤后，再回到第一步打开的界面中的A区域，选择默认的那行，如下图示：
右键先选择“分配”，完成后再选择“同步许可证”即完成大功率license的申请、分配。
另：
如果某小区存在CE拥塞、或者CE不足导致吞吐率问题需要修改、申请CE资源时，操作同如下：
（1）打开许可证；
（2）选中基站双击，出现下图：
（3）在基站侧执行DSPBBPTC,查询基带板业务能力，可以获知支持的最大上、下行CE数；
（4）修改上行、下行CE资源值，如上图红框所示；
（5）选择“分配”，分配CE资源，然后再选择“同步许可证”。
Ø申请大功率license后升功率过程
a）LSTUPCPICH，查询小区当前导频功率；
b）MODUPCPICHPWR，先修改PCPICH最大发射功率（=小区导频功率+16）；
c）MODUCELL，修改小区最大发射功率（如460、478）和PCPICH功率（如360、378）；
d）MODUPCPICHPWR，修改PCPICH最小发射功率（=小区导频功率-17）；
e）DEAUCELL去激活小区
f）MODULOCELL（在基站侧执行）配置NODEB上小区最大发射功率（如460、478，要求与第三步在RNC上设置的小区最大发射功率保持一致）
g）ACTUCELL
h）DSPUCELL，注意查看小区状态\HSDPA\HSUPA是否正常
i）DSPUCELLCHK查询小区健康状态，注意查看RNC配置的小区最大发射功率[dBm]与NodeB上报的小区最大发射功率[dBm]是否一致（要求一致）
j）LSTUPCPICH，查询修改后的小区导频功率
三、吞吐率
1.查询基站E1和FE配置
1）E1查询方法
登陆基站侧的本地维护终端，输出MML命令：
DSPIMGRP，可以查询到基站配置E1以及处于激活状态的E1数目（有的时候会出现配置2根实际处于激活状态的只有1根，此时吞吐率只有1根E1的量）。
一根E1最大支持2Mbps吞吐率。
2）FE查询方法
1）在RNC上输入命令：
LSTADJNODE，选择按照邻节点名称查询，输入基站名（没有基站编号），可以查到邻节点标识
2）LSTIPPATH，输入上面查到的邻节点标识，返回结果显示此站是否配置FE以及FE带宽是多少
3）DSPIPPATH，输入上面查到的邻节点标识，查询FEPING检测结果及丢包率，如果PING检测成功且无丢包，则FE正常；反之，则不正常。
2.常见吞吐率不达标原因
1）基站与RNC上脚本未刷
对于新入网小区，要求在基站与RNC上刷以下脚本，即在基站侧本地维护终端和RNC本地维护终端上，执行以下脚本：
2）小区HSDPA和HSUPA未激活
小区HSDPA和HSUPA未激活，H业务就会承载在R99上，导致吞吐率不达标。
ØDSPUCELL，可以查询小区HSDPA和HSUPA是否激活；
ØACTUCELLHSDPA，激活小区HSDPA业务；
ØACTUCELLHSUPA，激活小区HSUPA业务；
注：
现在网络升级到RAN12后，工程那边自动导入的CME数据中是不包含小区HSUPA数据的，所以有时由于工程疏忽，忘了单独配置HSUPA数据，网优会发现某个小区没有配置HSUPA数据，这时我们可以自己配置，操作如下：
在对应的RNC上执行MML命令：
ADDUCELLHSUPA，后面的参数项全部默认，如下图：
配置完后不要忘记激活HSUPA，执行MML命令：
ACTUCELLHSUPA.
3）背景噪声设置不当
这种现象集中体现在室分测试上面，因为室分是一个小区下面挂多个RRU，且工程经常是部分开通，导致网优测试背景噪声未来得及更改，导致现场测试吞吐率不达标。
一个小区下挂的RRU数目直接影响此小区的底噪值（即背景噪声），而底噪值又影响小区RTWP值，三者关系如下：
（N为小区下挂RRU数目）
小区底噪值=61+100logN，常用关系：
RRU数目
底噪
1
61
2
91
3
109
4
121
小区正常状态下RTWP=-112+（低噪-1）/10
底噪
正常RTWP
61
-106
91
-103
109
-101.2
121
-100
解决方案
Ø在基站维护台上LSTRRU，可以查询此站共有几个RRU；执行DSPLOCELL，可以查看每个小区存在的可用RRU数目，据此数目可以确定小区的底噪值。
Ø在RNC上LSTUCELLCAC，查询小区当前底噪值，如果与上一步确定的底噪值不一致，则执行MODUCELLCAC，将小区底噪值修改为前面确定的底噪值。
4）邻节点映射关系错误
ADJMAP即邻节点映射关系，若设置不当也会对吞吐率造成影响（主要是对开通FE的站点）。
在RNC上执行LSTADJMAP，按照邻节点查询，可知此小区的ADJMAP设置：
如上图示：
在RNC162下，15、16、17对应的是高QoS分路IP实时业务承载，即传输走的是FE；，非15、16、17对应的就是ATM非实时业务承载，即传输走的是ATM；。
对于开通FE的站点这里应该是15、16、17，否则H业务达不到FE要求的吞吐率。
注：
上面的15\16\17在每个RNC下不是一致的，所以为了确认在当前RNC下设置多少值代表FE，可以在当前RNC下执行MML命令：
LSTADJMAP，不设置任何参数，直接执行，如下图：
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上完成，在拓扑图上选中基站，点击右键，选择“属性”，可以看到基站网元版本。
现网通用版本：
DBS3900WCDMAV200R010C01SPC300和BTS3900WCDMAV200R012C00SPC110，但是个别新开站由于工程疏忽未及时升级版本，导致网元版本停留在产品出厂版本：
DBS3900WCDMAV200R010C01B065。
此时需要联系工程进行版本升级。
2.邻区漏配
邻区漏配是测试出现掉话的常见原因，现场表现为源小区覆盖、质量已经变得非常差，而目标小区覆盖、质量都非常好，但是并没有发生切换，直至掉话，掉话后UE重新接入在目标小区上
邻区漏配解决方法：
1）现场测试人员将掉话前、掉话后重新接入UE占用小区信息告知机房侧，后台配合人员在现网查询掉话前后小区是否邻区漏配。
如果漏配，增加相应邻区。
2）后台配合人员自己通过跟踪UE标准接口信息获取掉话前后UE所占用的小区不一致，也可以怀疑是邻区漏配问题。
如何在跟踪的信令中得知当前的RRC和业务连接是承载在哪个小区上的？
如上图红框中所示，toUE和fromUE的消息中“用户”列所示值即为小区ID，这样即可确认掉话前后小区信息，然后在现网查询掉话前后小区是否邻区漏配（此时也可以通过测量控制进一步进行确认邻区是否漏配）。
如果漏配，增加相应邻区。
与邻区相关的常见的MML命令：
Ø查询邻区：
同频邻区查询：
LSTUINTRAFREQNCELL；异频邻区查询：
LSTUINTERFREQNCELL；GSM邻区查询：
LSTU2GNCELL;
Ø增加邻区：
增加同频邻区：
ADDUINTERFREQNCELL；增加异频邻区：
ADDUINTRAFREQNCELL；增加GSM邻区：
ADDU2GNCELL；
Ø删除邻区：
同频邻区删除：
RMVUINTRAFREQNCELL；异频邻区删除：
RMVUINTERFREQNCELL；删除GSM邻区：
RMVU2GNCELL;
五、其他常遇问题
1.扰码修改
有时会遇到小区扰码需要修改的情况，具体如下：
（1）在现网查询此小区是否在其他RNC被定义了外部小区：
在M2000
MML命令上选中10套RNC，执行LSTUEXT3GCELL，查看执行结果即可。
如果在其他RNC被定义则接下来需要执行第2、3步，否则只需要执行第2步；
（2）扰码修改三步走：
Ø去激活小区：
DEAUCELL
Ø扰码修改：
MODUCELLSETUP
Ø激活小区：
ACTUCELL
（3）修改外部邻区定义。
在第一步中找到的把此小区定义成外部小区的RNC上修改此小区的外部邻区定义：
MODUEXT3GCELL,如下图：
将RNC163的小区11111在其他RNC的外部邻区定义的扰码修改为23。
2.SAC问题
小区信号覆盖和质量均正常、数据业务正常，但语音、视频业务均不能做，可能是由于核心网侧未加此小区SAC数据导致的。
关于SAC：
SAC即服务区码，现网配置与小区CI一致。
LSTUCELL,可以查询小区SAC号
处理方法：
（1）MODUCELLACINFO，如下图示：
将不能做业务的小区SAC换成已知正常的小区的SAC，如果此时可以打电话，则证明原SAC存在问题。
（2）在做完测试后需要改回小区SAC号、将小区去激活，并且做好问题记录，将情
况反映给徐雪峰。
3.RRC请求无响应
测试现场反馈在室分小区下所有业务均无法做，即无法拨打电话、无法做H业务，检查各项参数设置无问题，跟踪UE标准接口信令，发现UE发送RRC建立请求后一直无任何相应。
确认是工程传输问题，需工程整改。
4.驻波查询
查询RRU驻波比：
在NODEB上执行DSPVSWR，即可。
六、后台信令消息
1.CS/PS业务判断
后台信令消息的“messagesource”列的值是非常有用的，通过它我们可以很容易区分UE此次进行的CS还是PS业务，如下图示：
注：
如前面所说，“messagesource”列的值是非常有用的，如表示当前激活集小区CI、RNCID等：
Ø表示RNC：
RNC的表示值与RNC实际值的对应表：
信令值
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
RNC值
161
162
163
164
165
166
167
168
169
170
Ø表示小区CI：
2.判断SAC问题
通过后台信令也可以判断出小区的SAC数据是否加了。
由于SAC未加主要影响CS业务，所以我们需要关注CS业务是否正常。
通常处理手段，通过跟踪小区的IOS，找到CS业务的信令判断SAC是否加了。
上图所示的是小区SAC未加的情形。
3.外部邻区LAC错误导致跨RNC失败
现场测试人员在新村路控制中心室分测试发现室内外切换总是失败，后台跟踪消息发现跨RNC迁移时失败，信令如下：
查看relocationrequired可以看到迁移目标RNC和源RNC：
但是通过将目标RNC170的LAC号转换为十进制后发现问题所在：
上图中的A864转换为十进制后为43108，与现网RNC170的LAC号43018不一致，所以由此确认是由于外部邻区定义失败导致的迁移失败。
七、UPA和DPA不达标问题
从End-to-End的角度来说,整个通信链路上的每一个通信节点和接口都有可能导致所描述现象的发生.具体到HSPA的上下行,在UMTS的范畴内,这些节点和接口无非这么几个:
UE（datacard）,airinterface,NodeB,Iublink,RNC,IuPSlink,核心网（SGSN/GGSN/HLR）.
1."在同一测试区域，HSDPA速率正常，HSUPA速率不达标，可能有什么原因".HSDPA速率正常,只能说明空中接口基本传输链路（HS-SCCH,HS-PDSCH,HS-DPCCH,associatedDPCH）正常,以及下行的backhaul不存在拥塞,UE在合理的无线覆盖范围内且UE接收参数合理.但这不能保证上行的各个节点/接口都是通畅的.
HSUPA速率不达标,体现在各个节点上的可能原因包括:
-UE:
发射功率受限（传输TBS比较大的时侯）.建议上Rel8的HSPA,采用E-DPCCHpowerboosting机制才好.在UE使用2msTTI时也容易导致功率受限的情况,但目前现网中的数据卡好象都还不能支持2msTTI.
-airinterface:
本小区的RoT已经比较高（通常上限为6~7dB）因而E-AGCH上给出的功率偏移本身就限制了高速率;或者某个邻小区的上行干扰已经比较严重因而在E-RGCH上发送"down"指令从而限制了UE在servingcell的能力"发挥".
-NodeB:
看各家vendor各自的处理机制了.比如是否能够根据traffic特性动态调整CE分配以避免多用户时CE资源受限;NodeB是否有advancedreceiver从而能够对高速上行数据做有效的信道估计和解调.
-Iublink:
是承载在ATM上还是IP上.是否有上行的拥塞及丢包发生?
如果存在此类现象的话,恐怕会触发Iub上的流控措施以迫使空口uplink降速以免NodeBbufferoverflow
-RNC:
也看各家vendor自身的处理机制了.通常RNC用户面的处理能力远远超过NodeB.但这里要保证RNC内部各关联的处理单元上没有受限的情况发生,以免在RNC上引起相关的降负荷措施而"连累"该UE的数据传输.
-IuPS:
也要保证没有丢包和拥塞.现在有了OneTunnel,RNC可以直接和GGSN建GTPtunnel做数传了.现网中Iu接口带宽配置充分,通常不会在这里出问题.
-核心网:
保证该用户在HLR设备上有合法的签约数据并且GGSN不要实施降速限流类的策略,GGSN上防火墙设置是否合理,等.
最后还要看应用层的业务特性,如果是承载在TCP上的,那么应用层会要求receiver对接收到的TCP数据包有acknowledge,否则会认为传输路径中有拥塞发生从而自动减小发送窗口（导致sender的实际发送速率变小）.我猜,这个也就是出题者为什么给出HSDPA正常的原因吧.
同时测试时不要在天线下面，找个下行80-90的下面测试一下看看RTWP抬升是否有那么明显。
测试时注意手机的发射功率，是否是室分天线上行衰减太小导致的。
2,"在同一测试区域，HSUPA速率正常，HSDPA速率不达标，可能有什么原因".分析逻辑同上.HSUPA速率正常,只能说明上行方向各接口和节点工作正常.对HSDPA,要考虑以下:
-UE:
UE侧接收参数是否设置合理.现网的智能终端偶尔会出现因UE操作系统对多任务场景的处理能力不够强导致UE解析应用层数据的能力下降从而影响了接收效果.总之,UE本身也是容易出问题的地方.
-airinterface:
UE的无线环境（上报的CQI）是否合理;基站所使用的无线
升级会员 