LAC优化项目Word格式.docx
《LAC优化项目Word格式.docx》由会员分享，可在线阅读，更多相关《LAC优化项目Word格式.docx（27页珍藏版）》请在冰豆网上搜索。
PAGCSBSC：
BSC在CCCH上发送的经过SGSN的CS寻呼计数。
针对以上三种情况，单位时间寻呼数的计算方法如下：
如果没有可用的统计，即在初始配置阶段，应用一话务模型。
下面的例子是计算BAS1话务模型每秒产生多少寻呼命令，和在这样一个网络中的一位置区可使用多少个TRXs。
BAS1模型基于收集到的交换数据并且在一定程度上说是对应于一平均网络（例1）。
基于平均网络的波动也被考虑，在例2中，展现了一较高寻呼负荷的网络。
通过检查这两个例子的结果，可以得到如何规划网络的结论。
当对用户行为不熟悉时，建议根据例2应用其数字。
将此作为初始配置，运营商可根据统计来优化网络。
在这部分数字指BTS的容量，也必须考虑BSC的容量限制。
例1：
BAS1模型
对位置区大小的估计需要基于话务和用户行为的一些假设。
为了估计最大的位置区大小，需要估算在此位置区的每爱尔兰话务的寻呼负荷。
每爱尔兰话务产生的第一次寻呼的数量根据下列的平均假设估计（BAS1缺省模型）：
Ø
手机主叫试呼：
65%。
主叫试呼应答率：
77%。
手机主叫应答持续时间：
75秒
手机主叫无应答率：
23%。
被叫不应答主叫试呼持续时间：
20秒。
有一寻呼的手机被叫比率：
50%。
应答的手机被叫比率：
90%。
应答的手机被叫持续时间：
90秒。
无应答的手机被叫比率：
10%。
无应答的手机被叫持续时间：
话务高峰的余量：
20%。
所有呼叫导致寻呼的比率为：
（1-65%）*50%=17.5%
BTS对呼叫的平均保持时长（包括无应答）：
0.65/（0.65+0.175）*（0.77*75s+0.23*20s）+0.175/（0.65+0.175）*（0.9*90s+0.1*20s）=63秒。
1爱尔兰的话务对应于每秒平均1/63=0.016个呼叫。
17.5%的一次寻呼的被叫每秒每爱尔兰话务大于等于0.175*0.016=0.0028。
每个寻呼块可容纳4个TMSI寻呼或2个IMSI寻呼，IMSI寻呼不少于25％，没有全局寻呼，每寻呼块的寻呼尝试为：
4/（1+2*25%）=2.7PA/PagingBlock（1PA=1TMSI+1/4IMSI）
对话务高峰，每爱尔兰的话务的总的话务负荷加上20%的余量：
1.2*0.0028=0.0034PA每秒和每爱尔兰话务。
其等于：
1.25*0.0034=0.0043寻呼命令每秒每爱尔兰话务。
在对于每爱尔兰话务每秒估计的大体寻呼尝试次数，和BTS的最大寻呼负荷，对应于最大位置区可容纳的话务能得到：
组合BCCH/SDCCH：
（AGBLK=0）：
0.5*2.7*（3/0.2354）/0.0034=5060爱尔兰
（AGBLK=1）：
0.5*2.7*（2/0.2354）/0.0034=3373爱尔兰
非组合BCCH/SDCCH：
0.5*2.7*（9/0.2354）/0.0034=15180爱尔兰
0.5*2.7*（8/0.2354）/0.0034=13495爱尔兰
在忙时每个载频约承载平均4个爱尔兰的假设下，每位置区对应的TRX数目为：
5060/4=1265每位置区载频
3373/4=843载频每位置区
15180/4=3795载频每位置区
13495/4=3373载频每位置区
例2：
高寻呼负荷
除去下列假设，其他假设同先前的例子一样，可得到在一位置区的寻呼负荷：
手机主叫比例：
一次寻呼的被叫手机比例：
70%。
这些与前面例子中的平均网络相比，要求要高一些。
按照上面的计算，对于20%余量的话务高峰每爱尔兰话务的寻呼负荷为：
0.0067PA每秒每爱尔兰话务。
0.0083寻呼命令每秒每爱尔兰话务
用可容纳的话务来表示位置区的大小和对应于每位置区的载频数量的载频为（按忙时每载频约承载4爱尔兰话务的假设）：
2568爱尔兰=641载频每位置区
1712爱尔兰=428载频每位置区
7704爱尔兰=1926载频每位置区
6848爱尔兰=1712载频每位置区
推荐使用的组合BCCH/SDCCH最多2500爱尔兰（约600载频），超过2500爱尔兰，建议使用非组合BCCH/SDCCH。
在实际网络中，还需要通过统计分析优化网络。
2）BSC寻呼容量
BSCCP处理寻呼的容量都已经最优化，不再是瓶颈，BSC内可能的瓶颈出现在TRH不足和A-bis口信令容量。
随着网络建设和优化的深入，目前山东移动网内的TRH配置都较大，而且已经取消LAPD信令压缩，TRH和A-bis口可能的瓶颈一般仅存在于较早期硬件的BSC，如BYB202和BYB501设备。
TRH性能分析请参见附件1《trh.doc》。
3）计算基站寻呼容量
对手机的寻呼是从MSC发送寻呼消息给MSC服务区的每一个BSC（全局呼），或是手机登记的位置区小区的BSC（本地呼）。
每一个BSC收到寻呼消息发送PAGINGCOMMAND消息给每一个BTS。
这消息中包含手机的身份（TMSI或IMSI），手机的寻呼组编号，和可选的一个标志，此标志说明与寻呼相关的后继事件中需要什么信道组合。
如果寻呼是全局的（在建议设置中只有当VLR中没有手机的位置区），用IMSI去识别手机。
正确规划MSC/VLR，5%以下的寻呼应是全局呼。
因此，在这些计算中，所有的寻呼假设为本地。
BTS的理论寻呼块是：
组合BCCH/SDCCH小区：
3/0.2354=12.75寻呼块/秒
2/0.2354=8.50寻呼块/秒
非组合BCCH/SDCCH小区：
9/0.2354=38.23寻呼块/秒
8/0.2354=33.98寻呼块/秒
为了计算BTS的寻呼容量，用IMSI或TMSI进行寻呼的数量需估计。
在推荐设置中，所有的第二次寻呼用IMSI来识别手机。
从现存的网络经验表明采用爱立信的GSMR10系统，典型的25%的手机存在第二次寻呼。
从平均上讲，这意味着对每一个被叫（=PagingAttempt（PA）），将发送一个TMSI和1/4个IMSI。
每一个寻呼块可容纳4个TMSI或2个IMSI寻呼。
假设有25%的第二次寻呼（IMSI），并且没有全局呼，每个寻呼块的寻呼尝试次数为：
在理论上，BTS的最大寻呼容量为：
2.7*（3/0.2354）=34PA/Second
2.7*（2/0.2354）=23PA/Second
2.7*（9/0.2354）=103PA/Second
2.7*（8/0.2354）=92PA/Second
在以上每种情况下，BTS能处理的相应的寻呼命令（PagingCommands）（包括25%的第二次寻呼）是：
组合BCCH/SDCCH小区：
1.25*34=42.5PagingCommands/Second
1.25*23=28.75PagingCommands/Second
1.25*103=129PagingCommands/Second
1.25*92=115PagingCommands/Second
在此文档中，假设BTS允许的最大寻呼负荷是理论上最大寻呼容量的50%。
这意味着对所有的BTS起始的重发送留有空间（BTS对寻呼请求的重发送仅仅在CCCH还有空闲资源的情况下发生，但是在这里50%的富余量能够重发送所有的寻呼请求（PagingRequests））。
当BTS的平均寻呼负荷是最大理论负荷的50%，很少由于寻呼排队（在BTS中）满而造成BSC起始寻呼丢失。
允许最大50%的寻呼负荷，在BTS中最大的寻呼尝试容量为：
0.5*2.7*（3/0.2354）=17PA/Second
0.5*2.7*（2/0.2354）=11.5PA/Second
0.5*2.7*（9/0.2354）=51PA/Second
0.5*2.7*（8/0.2354）=46PA/Second
允许最大50%的寻呼负荷，在上述的每一种情况下，BTS可处理的最大的寻呼命令数目为（包括25%的第二次寻呼）：
1.25*17=21.2PagingCommands/Second
1.25*11.5=14.4PagingCommands/Second
1.25*51=63.8PagingCommands/Second
1.25*46=57.5PagingCommands/Second
对于两次寻呼都为IMSI寻呼的情况，其计算方法如下：
对于第一次寻呼和第二次寻呼均为IMSI寻呼，假设现网中平均7.0%的寻呼会重复进行第二次寻呼。
这表示对每个移动台落地的呼叫尝试（=PagingAttempt（PA））,会发出（1+7.0%）个IMSI。
每个寻呼块（pagingblock）可以容纳2个IMSI的寻呼。
在我们的现网中有7.0%的第二次寻呼（IMSI），那么每个寻呼块可以容纳的寻呼尝试为：
2/（1+1*7.0%）=1.8692PA/pagingblock（1PA=1IMSI+7.0%IMSI）
1.8692*（3/0.2354）=23.8PA/Second
1.8692*（2/0.2354）=15.88PA/Second
1.8692*（9/0.2354）=71.46PA/Second
1.8692*（8/0.2354）=63.52PA/Second
相对应的每BTS能处理的寻呼指令（包括7.0%的第二次寻呼）数量为：
（1+7.0%）*23.8=25.47pagingcommand/second
（1+7.0%）*15.88=16.99pagingcommand/second
（1+7.0%）*71.46=76.46pagingcommand/second
（1+7.0%）*63.52=67.97pagingcommand/second
寻呼负荷＝忙时寻呼总量/理论每基站理论能处理的寻呼指令。
4）统计检查CCCH负荷
对于仅有CS业务的网络，用于AGCH的CCCH信道资源非常少，在计算位置区时可以忽略。
但在高GPRS业务的位置区边界小区，AGCH负荷非常高甚至可以影响寻呼容量。
因此在配置CCCH和计算位置区大小时，这些小区的AGCH负荷必须重视。
收集评估小区统计
CELLPAG:
PAGTOOOLD
PAGPCHCONG
BSC:
TOTPAG
BSCGPRS:
PAGCSBSC
PAGPSBSC
如果BSC下不止一个位置区，还需要收集以下统计
RANDOMACC:
RAANPAG
RNDACCEXT:
RAAPAG1
RAAPAG2
计算每小区寻呼丢失率
评估小区CCCH负荷
理想的小区丢寻呼率为0，但为达到这个比率，必须增加CCCH容量或降低LA大小，这样将减少可用的TCH或由于过多位置更新导致CP负荷增加。
为避免不必要的网络结构调整，可接受的丢寻呼率是0.1%。
由于第一次寻呼不到将重传，第一第二次寻呼合计丢失率要低于0.1%。
LA计算策略
寻呼负荷决定了位置区的最大值，而位置区边缘的小区的位置更新负荷决定了位置区的最小值。
最重要的原则是不要超过BTS或BSC的最大寻呼负荷。
如果已经定义了一个小区为组合BCCH/SDCCH的配置，在BTS中的寻呼容量成为限制因素之前，位置区可以相当大。
因为所有的寻呼消息在一个位置区内的所有小区中广播，如果一个位置区中有一个组合BCCH/SDCCH的小区，组合BCCH/SDCCH小区将成为限制因素。
（寻呼拥塞只影响这些组合小区，而不是整个位置区）。
通过组合BCCH/SDCCH配置，可得到一额外的SDCCH/4。
因此如果从位置更新的角度来说，建议组合配置。
在郊区，因为较低的话务负荷，找到适合的位置区边界小区是很容易的，那就每必要划分较少的位置区。
每BSC区域一个位置区是一个好的原则。
如果一个位置区相对较大，寻呼负荷较高，我们应考虑将一个位置区划为两个或多个位置区。
这将减少BTS和BSC的寻呼负荷。
在一个大城市中，在位置区边界的小区增高的SDCCH负荷是相当严重的。
找到适合的位置区边界是困难的。
如果BSC区域相对较少，并且找到适合的位置区边界较困难，一个位置区可以包括多个BSC的服务区域。
不管区域的类型，郊区还是市区，建议位置区的边界小区位于低用户密度的地区。
应该避免位置区边界穿过高移动性的区域，如高速公路。
最重要的建议是仔细监测系统的性能。
大部分CCCH上的信令负荷产生于寻呼，一个位置区的寻呼总量依赖于同一个位置区的小区总数以及这些小区的业务量。
每个小区能够处理的寻呼数量依赖于小区的CCCH配置以及寻呼消息的大小。
寻呼
1）寻呼组
为防止手机连续侦听网络PCH或PPCH，手机被分成多个寻呼组，手机只侦听属于自己寻呼组的寻呼信道。
PCH上的寻呼组
当一个手机调谐到BCCH载频上并解出系统消息，它计算自己属于那一个寻呼组，确定在寻呼信道的可用块中那一个特定寻呼块需要监听。
运营商可针对每一个小区设置寻呼组个数。
如果寻呼组个数较多意味着在其正确的寻呼块到来前，手机将需要等更长的时间，这增加了寻呼时间，而且减少了寻呼容量，因为每个寻呼组的寻呼队列较短。
寻呼组个数如果较少，会因为手机可以频繁的听自己的寻呼块而缩短呼叫建立的时间。
负影响是手机的消耗功率比较大。
有两个参数确定在一个小区的寻呼组个数（除去BCCHTYPE）。
这两个参数是AGBLK和MFRMS。
AGBLK
参数AGBLK决定在每一个复帧中保留为AGCH（立即指配ImmediateAssignment）的寻呼块。
爱立信的BTS支持AGBLK=0（不保留任何块）和AGBLK=1（保留一块）。
用作接入的寻呼块依赖于此小区的话务量。
因为在爱立信GSM系统中，立即指配的优先级要高于寻呼，AGBLK在没有特殊情况下应设定为0（在非组合配置的小区中使用小区广播或系统消息7和8在BCCH上发送时AGBLK必须设定为1）。
从现存网络的经验来看，CCCH用作接入准许的份额非常低，典型的低于5%。
MFRMS
MFRMS是复帧周期，其定义了在同一寻呼组发送寻呼消息的间隔。
例如，MFRMS=9的意思是属于一特定寻呼组的手机在每隔9个复帧时才被寻呼。
这意味着对应于一寻呼组的寻呼消息的发送间隔约为2.1秒（9*235.4毫秒）。
一较高的MFRMS值将导致在此小区中有更多的寻呼组。
MFRMS、AGBLK和寻呼组个数之间的关系是：
寻呼组个数=（3-AGBLK）*MFRMS
寻呼组个数=（9-AGBLK）*MFRMS
表4-1显示了这种关系和每一寻呼组的发送间隔时长。
在每个寻呼组之间的间隔时间
寻呼组数
（组合BCCH/SDCCH）
（非组合BCCH/SDCCH）
每个复帧3个寻呼块（AGBLK=0）
每个复帧2个寻呼（AGBLK=1）
每个复帧9个寻呼块（AGBLK=0）
每个复帧8个寻呼块（AGBLK=1）
2
0.47sec
6
4
18
16
3
0.71sec
9
27
24
0.94sec
12
8
36
32
5
1.18sec
15
10
45
40
1.41sec
54
48
7
1.65sec
21
14
63
56
1.89sec
72
64
2.12sec
81
表4-1
PPCH上的寻呼组
手机读分组系统消息PSI获知MPDCH的配置。
PPCH上的寻呼组数不能象PCH上一样可以通过参数控制，依赖于为PBCCH保留了多少块以及一个手机内部参数SPLIT_PG_CYCLE。
手机在GPRS附着过程中通知SGSN将使用SPLIT_PG_CYCLE的值，当手机侦听PPCH时，系统以此能够计算。
为PBCCH保留的块数依赖于PBCCH上有多少PSI消息要发送。
离开分组传送模式后手机进入非不连续接收“nonDRX”模式，在此期间倾所有可用的PCCCH，计时器T3194控制非不连续接收周期。
2）在基站的排队
从BSC来的寻呼命令（PagingCommands）在一个队列中进行缓冲（对每一寻呼组都有一队列）。
在BTS中的每一寻呼组的队列能容纳6到14个寻呼消息，这依赖于寻呼组的个数。
当有可用寻呼块时，BTS将寻呼命令改为寻呼请求消息在无线通道上发射。
太高的到BTS的PagingCommand消息速率将增加排队时间，有时导致寻呼响应的平均时长。
如果队列满，新到的寻呼消息将被丢弃。
如果寻呼消息在BTS中排队太长时间，寻呼也将因为MSC在计数器（PAGTIMERREP1LA或PAGTIMEREPGLOB）到期之前收到寻呼响应而丢失。
如果在每一寻呼组的发送间隔太长将增加在BTS中存在过高的延迟的危险。
如果在某一寻呼组中没有得到手机的寻呼消息，一个空寻呼消息将被发送。
将在PPCH上发送的预定的寻呼在基站不排队，因为PCCCH上消息通过GPRS信令连接（GSL）透明传送。
3）寻呼策略
寻呼块结构
每一个复帧包括3个（组合BCCH/SDCCH）或9个（非组合BCCH/SDCCH）寻呼块。
每一个寻呼块可最多发送4个寻呼请求（PagingRequests）。
每个寻呼块可发送：
2个IMSI寻呼请求（IMSI=InternationalMobileSubscriberIdentity）
4个TMSI寻呼请求（TMSI=TemporaryMobileSubscriberIdentity）
1IMSI+2TMSI寻呼请求
图4－1
重发寻呼
无Gs接口情况的CS寻呼
如果在VLR中知道手机的位置区（LA）（正常情况下），第一个寻呼消息是本地呼。
本地呼是寻呼消息只在属于手机登记的位置区的小区中发送。
如果寻呼没有成功（手机没有响应寻呼消息），MSC能够第二次发送寻呼消息。
这第二次寻呼消息可以是本地或是全局。
全局寻呼是在手机登记位置区所属MSC的所有小区中发送。
手机可以用TMSI或IMSI来识别来进行寻呼。
建议的寻呼策略是：
如果在VLR中知道手机的位置区，第一次寻呼是本地呼。
对于本地呼，用TMSI来识别手机。
如果手机不响应第一次寻呼，将进行第二次寻呼。
第二次寻呼也是本地呼但用IMSI来识别手机。
其他与建议策略不同的策略将以下列方式影响寻呼负荷：
没有第二次寻呼
没有第二次寻呼降低了BTS和BSC的寻呼负荷。
缺点是有增加不成功的手机寻呼的危险。
第二次全局寻呼
与第二次本地呼相比，第二次全局呼增加了寻呼负荷。
优点是对于那些由于某些原因在VLR中位置区错误的手机被寻呼成功的机会增加。
第二次TMSI寻呼：
如果第二次寻呼是全局寻呼，用IMSI来识别手机。
如果第二次寻呼是本地，可以用IMSI或TMSI来识别手机。
用TMSI寻呼将增加BTS的寻呼容量。
缺点是如果手机在VLR中的TMSI错误将导致许多不成功的寻呼，例如在刚刚穿过位置区边界的手机。
注意：
在寻呼信道有空闲资源时，爱立信基站会自动重发寻呼请求（如果打开CCCH重发功能）。
这对于丢失寻呼的重发不起任何作用。
有Gs接口情况手机处于GPRS附着状态的CS寻呼
对于GPRS附着状态的手机，为CS服务的第一次寻呼尝试通过Gs接口，手机在位置区内寻呼，否则在全局寻呼。
如果没有受到应答，第二次寻呼可以设置为无寻呼、通过A接口进行寻呼或通过Gs接口寻呼。
推荐通过A接口进行寻呼。
第二次寻呼应该通过IMSI来识别手机，同没有Gs接口情况一样。
这种情况下，手机状态转为GPRS分离状态。
PS寻呼
SGSN向手机当前所处的所有服务在该路由区（同位置区相同）的基站发送一个寻呼请求，T3313开始计时，如果到
升级会员 