-
GSM
移动通信
LAC
区划分及分析
一、简介
良好的寻呼性能对于所有手机用户是否能够成功作被叫
来说十分重要。
这份文档主要分析了我
省
LA
位置区的寻呼性能——寻呼成功率及承载能力，并针对问题
LAC
提出了规划调整方案。寻呼
性能分析主要评估了我省现
网
69
个
LA
位置区的寻呼成功率及寻呼负荷，
同时给出一些
BTS
寻呼容
量及负荷的计算。此外，针对我省
LAC
现状提出适当调整方案及今后的规划建议。
二、背景
目前全省市场资费调整，全网话务量急剧增加，网络容
量滞后于实际话务量的增长，网络容量
问题突出暴露。由于
LA
话务量增长迅速，且部分地区
LA
划分
不均衡，使得这些
LA
下的
BTS
寻呼
负荷及
BSC
负荷过高，导致手机无法被成功寻呼。我省郑州、商丘、开封等地曾出现过由于
BTS<
/p>
寻
呼负荷过高，当大量短信群呼时，对网络造成巨大冲击，大量用
户打不成电话，给我们的网络带来
了较大损失。因此，
LAC<
/p>
的规划问题目前已突出暴露出来，将
LAC
的优化及规划提上紧急日程已毋
庸置疑
!
LA
代表一个位置区域，主要有以下两项功能：
1
、在此区域内，网络发起对某个手机的呼叫，
此区域内所有的基站都会进行寻呼，因此假如一个
LA
涵盖的
基站数过多，用户数过多，大量的寻
呼将导致
BTS
寻呼负荷过载。
2
、
手机
进入一个新的
LA
服务范围内，
必须发
起请求，
更新
HLR
及
VLR
内的位置记录，因此网络的
LA
数过多，会造成手机频繁的位置更新，浪费相应的信令资源。
三、
BTS
< br>寻呼容量的相关参数设置
1
、
寻呼原理分析
当一个手机被寻呼时，
MSC
就会通过
BSC
向对应
LAC
范围内
的所有基站发出寻呼请求。一个
LA
可能涵盖数十个甚至数百个
小区，所以发至
BSC
的寻呼信息数量可能会很惊人。由于
BTS
必须通过
有限的
PCH
信道向手机发送寻呼请求，因此，过大的
LA
可能导致
BTS
的寻呼负荷过载，结果造成<
/p>
信令拥塞及寻呼信息丢失。
根据
GSM
< br>的规范，
CombinedBCCH/SDCCH
小区，
每个复帧传送
3
个寻呼组，而
Non-
CombinedBCCH/SDCCH
小区
,
每个复帧传送
9
个寻呼组。
寻呼组可作为寻呼信道
(PCH)
用来广
播寻呼请求，同时也可作为接入授权信道
(AGCH)
用来回应手机的接入请求
(
即分配
SDCCH)
。操作
上，可将数个复帧组合在一起，形成一个寻
呼周期，增加小区内的寻呼组数量。手机会周期性地监
听所属的寻呼组，于是当手机作被
叫时，会监测到基站发送的寻呼请求，并做出回应。
寻呼组设置较多意味着手机在监测到正确的寻呼组之前需要等较长时间，
这样会增加寻呼的时
间。
寻呼组设置较少会由于手机较为频繁地接听寻呼组而缩短呼叫建立时长，缺点是手机会很
费
电。
2
、
寻呼组设置
我们可以设置每个小区的寻呼组的数目，两个参数决定了一个小区寻呼组的数量。这两个参数
是：
NumberOfBlocksF
orAccessGran
、
BS_AG_BLKS_RES(
0...7)
、
noOfMultiframesBetweenPaging,
BS_PA_MFRMS (2 ...
9)
。
以下
NumberOfBlocksForAccessGrant
简写为
AG
，
noOfMul
tiframesBetweenPaging
简写为
MFR<
/p>
。
·
Combined BCCH/SDCCH 小区–
AG =0 ... 2
，而
Non-Combined BCCH/SDCCH
小区–
AG =
0 ... 7
，若使用
CBCH
，则
AG= 1 ... 7
。这个参数定义了每个复帧内
AGCH
专用的寻呼组数量。
它可以设成
AG= 0 (
即没有专用的
AGCH
，所有的寻呼组由
PCH
和
AGCH
共享。
)
或
AG>= 1 (
即保留
寻呼组作为
AGCH
专用信道
)
。用于
AGCH
的寻呼组数量取决于小区话务量。由于我省并未启用
CBCH
功能，并且在
Nokia GSM B
SS9
中，若没有保留
AGCH
的情况
下，
AGCH
的优先级高于
PCH
，因此尽管
有需求，也可以将
AG
设为
0
。
· MFR (2
..9):
这个参数定义了
BTS
的寻呼周期
,
即同一寻呼组传送寻呼请求的时间间隔。例
如：
MFR=9
的意思是每一寻呼组，以每
< br>9
个复帧的周期重复一次。也就是说属于某一特定寻呼组的
手机，必须每
9
个复帧监听一次，也就是说监听间隔时间大约
是
2.1
秒
(9 * 235.4
ms)
。
AG
，
MFR
以及寻呼组的数量三者之间的关系如下：<
/p>
以我省个别地市为例计算小区寻呼组的数量
1)CombinedBCCH/SDCCH
小区：
AG=2
MFR=5
寻呼组数量
=(3- AG)
* MFR = 5
个寻呼组
2)Non-combinedBCCH/SDCCH
小区：
AG=2
MFR=5
寻呼组数量
=(9- AG)
* MFR = 35
个寻呼组
四、
BTS
寻呼容量的计算
考虑到
SDCCH
拥塞，
一些小区配置为
combinedBCCH/SDCCH
，
但将
BCCH/SDCCH
改为
combined
后
会减少每复帧周期的寻呼组
的数量。如上计算，若使用
non-combined
，寻呼组
的数量为
35
，而用
combined
时只有
5
个寻呼组。以下主要针对
combined
配置进行深入分析。
BTS
通过寻呼组广播寻呼请求。下面是一个寻呼请求
可能的配置：
· 2
IMSIs
· 1
IMSI and 2 TMSIs
· 4 TMSIs
对于现网中部分分公司设置的
CombinedBCCH
：每个复帧有
3
个寻呼组
(235 ms),
若
AG =
2
，
每秒寻呼组的数量为：
(2
个
AGC
H->1
个
PCH)
=1<
/p>
个
PCH/0.235(
每复帧
)
=4.25
个寻呼组
/
秒
[1]
每复帧寻呼组可以传送
4
个
T
MSIpages
或
2
个
IMSI pages
。假设
25 %
用于
IMSI
，且没有全
网寻呼，每复帧寻呼组的寻呼数为：
1TMSI
寻呼占一个寻呼组的? ，
1 IMSI
寻呼占? 。
4
个寻呼
(100%)= 75%(TMSI) +
25%(IMSI)
= 3 * ? + 1 *
?
= 5/4
（所需寻呼组）
所以，估计每寻呼组的寻呼数为：
4/(5/4)=3.2 [2] /
即每寻呼组可寻呼
3.2
个手机
/
< br>因此，对于
CombinedBCCH/SDCCH
小区
，若
AG=2,
则每秒的寻呼数为：
4.25(
寻呼组
/
秒
)* 3.2(
寻呼数
/
寻呼组
)= 13.6 (
寻呼数
/
秒
) [3]
上面计算了实际现网中
AG=
2
时寻呼的容量，建议将
AG
由
2
设为
0
，这样可以
直接增加寻呼的
容量，改善寻呼成功率。以下将计算
AG
的实际需求及将
AG
由
2
设为
0
之后寻呼容量的增长。
例如：
LAC=14384(
洛阳
1
0
月
28
日忙时
SDCCH
分配次数最多的小区
63131
< br>，
SDCCH_ASSIGN = 5924)
CI63131=5924SDCCHAssign (AGCH attempts)
= 5924/3600
=
1.64AGCH / s [4]
= 1.64*0.235
= 0.38
/
即每复帧用于
AGCH
的寻呼组
为
0.38
个
/
这个计算结果说明
AGCH<
/p>
的需求不足一个寻呼组，
所以不需设置专用的
AGCH
，
即可将
AG
设为
0
。
如果将
AG
< br>由
2
设为
0
，则寻呼组的数量将会增加：
< br>每秒寻呼组的数量：
(0
寻呼组用于
AGCH
，即
3
寻呼组用于
PCH)
=
3
个
PCH/
0.235(
每复帧
)
=12.76 [5]
考虑最差情况下，除去
AGCH
后，每秒实际剩下用于
PCH
的寻呼组数量
=12.76-1.64
=11.12 [6]
因此，
CombinedBCCH/SDCCH
小区每秒寻呼数为：
(
若
AG
= 0)
11.12(
寻呼组
/
秒
) * 3.2 (
寻呼数<
/p>
/
寻呼组
)= 35.58 [7]
因此，
[7]
式
(AG= 0)
与
[3]
式相比
(AG
=2)
可知，
BTS
的寻呼容量可增
加
162%
。
五、
BTS
< br>寻呼负荷的计算
这部
分更深层次分析了我省现网配置为
CombinedBCCH/SDCCH
和
Non-combinedBCCH/SDCCH
的
基站，以及这些基站寻呼负荷现状。如下表
5.1
所示。
-
-
-
-
-
-
-
-
-
上一篇：L2TP VPN(客户LAC)终端操作
下一篇：电影类型的分类