无线呼叫中排队介绍

无线呼叫中排队介绍
近一年来，我地区的话务量呈爆炸式增长，由此带来的是拥塞率和接通率指标的明显下降，一般情况下技术人员处理此类问题时，会采取了扩容、调整基站覆盖等手段，但扩容有时会受到很多因素的制约（如基站最大容量的限制、传输的限制、天馈线的限制等等），而调整基站的覆盖则有可能会引起用户的投诉。

那么有没有办法来最大限度的提高基站容量呢，经过研究和实验，通过优化无线资源管理的相关参数可显著提高系统的容量和性能。

该方案的核心内容是优化小区的优先级参数和排队参数，目前这些参数的设置都是采用的默认值，而这些默认值存在很大的不科学性，它一方面未将系统的容量最大限度的发挥出来，另一方面也与该小区其它参数和交换机参数的设置无法匹配。

现在我们就针对该方案所涉及的具体优化方法和主要原理进行阐述。

1.1优化方案及效果
1.1.1优化方案
1）将全网小区的参数“优先级分配门限（allocPriorityThreshold）”统一设置为0；
2）根据小区的SDCCH信道数目来调整参数“排队队列的最大长度（allocWaitThreshold）”，该参数应小于SDCCH信道的数目，若小区在LAC边界，则该参数应取值为SDCCH数目的1/2；
3）优化MSC的定时器TNT2，由于参数“优先级分配定时器（allocPriorityTimers）”所定义的排队时长一般为20s，建议该定时器应设置为30s。

4）有针对性的设置参数“优先级分配定时器（allocPriorityTimers）”，在小于TNT2的前提下，对于SDCCH负荷较高的小区可适当减小排队时长，对SDCCH负荷较低且TCH拥塞严重的小区，可适当提高排队时长。

1.1.2优化效果
5月19日至5月22日进行了根据上述方案进行了整治，效果十分明显，尤其对拥塞率低于10％的小区效果更为显著，如下表所示：
1.2优化原理
排队参数和优先级参数的设置是无线资源分配算法的主要组成部分，现在我们就对该算法中所涉及的排队参数和优先级参数进行详细的分析。

1.2.1信道分配优先级
在信令模式下（紧急呼叫、响应寻呼、附加业务等）或在业务模式下（分配请求、区间切换和区内切换），每一种类型的TCH分配请求都被定义了相应的一个外部优先级。

无论是否激活了排队功能，系统都将通过OMC-R的表格将这些外部优先级与内部优先级（0至7）一一对应起来。

注意：切换程序与指派程序都是在业务模式下在TCH上发起请求的。

而其它所有的程序都是在信令模式下，在SDCCH上或TCH上发起请求的。

如果此时没有空闲的SDCCH，则系统将分配TCH来传送信令，但是TCH的分配应按照内部优先级的定义情况来进行分配。

在该程序中，内部优先级为0的请求能优先的被分配到TCH信道。

一部分TCH信道将被预先留给内部优先级为0的TCH的分配请求。

被预留的TCH信道是针对所有TCH信道来说的，并不是指具体的TCH信道。

信道优先权可以由OMC决定，也可以由MSC决定。

MSC的外部优先级是通过assign Request（指派请求）消息来定义的。

MSC所定义的外部优先级同BSC所定义的外部优先级有一个对应关系，公式如下：BSC的外部优先级= （MSC的外部优先级– 1）即MSC的优先级1～14对应着BSC的优先级0～13。

在BSC，优先级14～17的信道指派请求被保留给的其它用途。

值得注意的是，仅当排队序列选用MSC判决的方式时，才会考虑到不同类别的指派请求（assign Request）。

14个GSM外部优先级和被预留给BSS的4个优先级，在BSS 侧被转换成了8个内部优先级。

大家应该知道的是分配优先权与排队算法是完全不相关的两个概念，这就是说当系统没有启动排队功能的时候，系统仍将根据参数的定义来保留部分信道给优先权为0的信道请求。

1.2.2排队算法
排队的算法分为两种，一种是由MSC控制，另一种是由BSC控制（即由OMC驱动），目前我们使用的是BSC控制的算法。

排队是当系统在没有TCH资源的情况下，将TCH的分配请求放入一个等候的序列中，当其它呼叫将资源释放掉后，网络就可以按照排队的先后将资源分配下去。

排队可以被认为是一种防止TCH过饱和的一种手段。

在OMC-R所定义的参数中，定义了等候的序列中最大的等候时间和参与排队的最大的TCH分配请求数目以及相关序列的最大长度。

然而，并不是所有的程序都可用于排队。

例如，小区间切换程序（intercell handover）就不能用于排队。

进一步的来说，当MS的指派请求还处在排队期间时，它占用的仍旧是SDCCH信道而且要向网络进行正常的测量报告处理过程。

如由OMC决定排队的话，那么就只允许有一个排队序列，我们可以从0～7中选择一个队列号，具有对应内部优先级的请求可进入该队列排队，信道指配的流程图下图1－2所示。

来的请求将由BSC负责管理控制并决定是否可进行排队。

在这唯一的队列中，仅允许指派请求（此时MS附着在SDCCH信道上）。

1.3相关参数的设置原则
现在来介绍一下上文中所涉及参数的具体设置方法和原则：
1、优先级分配列表（allocPriorityTable）
定义：
该列表中有18个单元，定义了外部优先级映射到内部优先级的方法，TCH分配就使用了该表。

设置原则与方法：
该列表的默认取值为222222222222222210。

该取值方法的含义是外部优先级为17的请求所映射的内部优先级为0，外部优先级为16的请求所对应的内部优先级为1，其它的外部优先级所对应的内部优先级均为2。

目前我们一般将切入请求的外部优先级设置为17，也就是说切入请求的内部优先级为0；而指配请求的外部优先级设置为16，也就是说指配请求的内部优先级为1。

注意事项：
这种设置方法我们原则上不做修改。

2、优先级分配定时器（allocPriorityTimers）
定义：
该参数列表有8个单元，定义8个内部优先级各自所允许的最大排队时间。

由于我们只支持对指配请求进行排队，因此在该列表中只有内部优先级为1的位置定义了排队时长。

设置原则与方法：
该参数的取值应为小于TNT2-3107。

TNT2为MSC的定时器，当MSC发出“指配请求”消息时开始计时，当收到“指配完成”消息时终止。

T3107为BSC的指配定时器。

目前该参数的取值一般被设置为0 20 0 0 0 0 0 0，即内部优先级为1的请求所允许的最大排队时间为20s，由于一般情况下BSC的TCH分配时长不会超过5s，若考虑到给负荷不同的小区设计出一些余量，因此建议TNT2的取值可为30s。

注意事项：
排队时间的长短应取决于SDCCH信道的负荷和拥塞的程度，因为这些指配请求是在SDCCH 信道上进行排队的，排队的时间越长，则对SDCCH负荷的影响也就越大。

此外还应考虑到用户对接续时长的忍受限度，显然排队时间越长，用户的接续时间也就越长，这将会引起用户的对该呼叫的过早释放，造成资源的白白浪费。

可根据小区的拥塞程度不同，来分别设置该参数的值。

3、排队队列的最大长度（allocWaitThreshold）
定义：
该参数列表有8个单元，定义8个内部优先级各自所允许的排队队列的长度。

由于设备仅支持对指配请求进行排队，因此在该列表中只有内部优先级为1的位置定义了排队长度。

设置原则与方法：
该参数应小于该小区所配置的SDCCH信道的数目。

该值设置的过大也没有意义，一般来说建议该值应小于16。

4、优先级分配门限（allocPriorityThreshold）
定义：
该参数定义了给内部优先级为0的信道请求预留信道的数目。

当小区空闲的TCH信道小于等
于该参数所定义的值时，BSC将只把这些信道分配给优先级为0的信道分配请求，而将其他信道请求放入排队序列或拒绝。

设置原则及方法：
目前该参数的默认取值方法为：当小区小于等于2套载波时，该参数被设置为0；当小区大于2套载波时，该参数被设置为2。

由于网络目前只有切入请求的内部优先级被设置为0（紧急呼叫和呼叫重建可忽略不计），这就意味着所有大于2套载波的小区都被预留了2个TCH 信道给切入请求，也就是说当该小区的空闲信道小于等于2个时，它将把新收到的呼叫请求都放入排队序列，若排队序列已满，BSC则会拒绝新的呼叫。

这就会造成当小区还有空闲的TCH信道时，网络很有可能已经发生了拥塞，通过数据分析我们发现这种情况是普遍存在的。

所以目前这种设置方法不符合运营商的利益，它减小了小区的承载呼叫的能力，换句话说它浪费了大部分小区的2个业务信道。

因此建议将该参数设置为0，这就相当于给这些小区多提供了1～2个爱尔兰的容量。

也许有人会有疑问，这样岂不是降低了切换的性能么？是的，从这一方面来讲是降低了切换的性能，但我们应认识到，当某一个小区的信道资源紧张时，是保证接纳新的呼叫重要呢，还是保证切换性能重要呢？答案时显而易见的，当然是接纳新的呼叫重要，这样即提高了运营收入，又提高了客户满意度，而它的负面影响是微乎其微的，因为即使切换不成功，用户还会保留在原小区当中，只是质量略受影响（绝大部分切换的触发原因都是功率预算切换，它目的是使用户尽量驻留在信号最强的小区之中）。