无线的给力，加油哦！

支持楼主，给力继续啊！

没有现成的报告，初衷也不是发附件，另外也是想只要注册有浏览本区权限的人都能参与讨论和提高。
所以哥们你还是一起讨论吧.

CCCH的评估再补充点，通常我们都是以小时的统计粒度做规划，最直接的规划就是以某小区的PSIMMASS+CSIMMASS+DISCIMASS的量做规划，考虑到60%的CCCHblock给PCH的话，那么单小区的AGCH容纳极限就是5万多，假设取整以6万为单位规划CCCH，超过6万设置2个CCCH，超过12万设3个CCCH。不过本人在最近做规划的时候，发现有些小区只有1,2万的IMASS数，也会有不少的寻呼丢弃数。这是为什么呢？
我想主要原因在这个统计时长上，如果这1,2万的IMASS数大多都集中在某15分钟之内发送，那么从15分钟的粒度来看，你这个时候的CCCH的BLOCK数就只有一个小时的1/4了，同样对PCH、AGCH的block都的除4，而在这个时间粒度里如果2万的IMASS(一小时的量)的绝大部分都是产生在15分钟里，那么这个15分钟里的绝大部分的CCCHblock将会被AGCH充斥，PCH的BLOCK就会少，寻呼丢弃自然也就产生了。这是猜想，本人因时间原因没有取更详细的统计验证。C友们可以验证下。
因此我觉得做CCCH规划不仅需要看IMASS的量，也的将寻呼丢弃数（pagpchcong、pagetooold）纳入CCCH规划的公式。
还有一个就是做扩容规划可以考虑前面说的6万为单位，但是做CCCH减容规划的时候，对一个CCCH支持的IMASS数要适当保守不应过大，比如4万这样保守点。避免减后产生寻呼丢弃。

当然这些考虑中的具体数值不是绝对的，大家这些考虑应该周全，具体值可以借鉴也可以根据现网实际验证。

周五了，看周末准备准备第二个话题。
不过还是希望能出去逛逛啊，做宅男没意思。

措辞挺有意思的！

对于现在的我来说有点深啊~~

学习学习，好好学习！

真正的存技术贴啊，要收藏起来才行，有空要多看下

哈哈，终于开始第二个话题了。耽误了几天没更新啊，有没有人久等了呢？
单刀直入，强势切入主题。
TBF是个嘛东西啊？

Temporary Block Flow。用通俗语言来说，他就是一个临时的名字，当手机和网络建立了一种联系后，这种联系就叫TBF。网络分配一个TFI标志建立起来的TBF。你还不理解，那我就再粗俗点，当一个男人和一个女人生活在一起后，就产生了一种联系，这种联系就叫婚姻（TBF）。双方闹崩了，那么这个TBF也就解除释放了。咱发扬一下灰太狼精神，女方为中心，女方是网络侧，男方是手机侧，那么在上行方向上用什么来标志这种联系？
老婆（上行TFI）就是标志这种关系的名称，老公（下行TFI）是下行方向上双方婚姻联系的标志。
TFI
：临时流标志(Temporary Flow Identity) 共五位比特，取值范围为0~31。

USF ：上行链路状态标志(Uplink State Flag) 共三位比特，取值范围为0~7。用于动态分配模式下控制多个MS使用无线信道USF。
好了，现在你知道了TBF建立成功率就是婚姻建立成功率，就是把女朋友整成媳妇的比例。

本来准备直接进入，想想还是负责任把前戏做足点吧。再把相关概念引入一下啊，这样你我无线的快乐才能更猛烈而持久，总之不把你弄喷不行。

[attach]169952[/attach]

PDCH从编码方式来分，有BPDCH/GPDCH/EPDCH。B-PDCH (Basic PDCH capable of CS1 & CS2), G-PDCH ( General PDCH capable of CS3 & CS4), E-PDCH (EDGE PDCH capable of EGPRS and CS1 to CS4)。
从Abis资源连接情况来分，有FPDCH/SPDCH。
从使用情况来看，有FPDCH/On-demandPDCH。

着重再讲讲TBF复用度。如果从业内同行日常交流表达的内容来看，TBF复用度有2个，一个是参数设置的TBF复用度，限制了每个PDCH上的多少个用户使用；一个是统计里面的指标。大家可能会互为一谈。其实两者差别巨大。
首先我们谈谈TBF复用度这个参数，参数就是上图中的意思。比如说上行TBFULLIMIT设置为20后，你看CHGR1里的第3、4、6、7时隙，上面的TBF层数就是2。表明同一时间使用某一PDCH的激活状态TBF只能是两个。比如上图，再有新的TBF建立，只能建立在CHGR1的0、1、2、5时隙上。
依次类推图中TBFDLLIMIT的理解。

而统计中的TBF复用度。实际上与英文的指标名称是有差异的，在KPI体系里属于容量相关，通常有Sharing on B, G, E-PDCH (DL & UL)、Sharing on E-PDCH (DL & UL) 4个KPI。
比如Sharing on E-PDCH-DL
公式为：DLTBFPEPDCH / DLEPDCH
Object Type: TRAFDLGPRS
DLTBFPEPDCH 在每个E-PDCH上所承载的同时发生的TBF（所有的TBF类型）的总和。
DLEPDCH承载一个或多个任何类型的TBF的E-PDCH的个数。
还是上图助于我们理解，上图所示情况，这样在下行方向上，DLEPDCH =++2（这个好理解，就是CHGR1的TS6、7）; DLTBFPEPDCH = ++4(在EPDCH上多少个TBF呢？再见图解)
[attach]169954[/attach]



因此例子中Sharing on E-PDCH-DL（或者你习惯叫下行ETBF复用度了）=
DLTBFPEPDCH =4


--------------------------------------------------------

DLEPDCH=2
结果当前Sharing on E-PDCH-DL=2。这样TBFDLLIMIT是30（也是3个TBF的复用度），而统计的TBF复用度是2。
而更普通情况则是Sharing on E-PDCH-DL
>
TBFDLLIMIT。这又是为什么？
我们说了TBFDLLIMIT是每PDCH上激活状态的TBF复用个数，那么再见图：
[attach]169955[/attach]

下面这两个TBF数据发送完毕，但是TBF还未被释放，因此还承载在当前PSET里，但是他没有数据发送，因此从TBFDLLIMIT来看，不考虑这两个。
所以TBFDLLIMIT还是30（也是3个TBF的复用度），而统计的TBF复用度是8/2=4。
OK，这就是我要讲的，哈哈，不知道你明白否。
这里还可以介绍一下，当图中5、6这个TBF在TBF释放时延之前又有新的数据到达需要发送。这个时候会出现两种情况，一是在原有的TS6,7上的ETBF2,3这个TBF数据在这个时间之前传送完毕，也进入了TBF释放进程中，这样2,3这个TBF变成空闲，而5，6这个TBF则可以继续使用原有时隙。
另一种情况是，5，6TBF被转移到其他未达到TBFDLLIMIT限制的时隙上。

好啦，前戏结束。
首先来看TBF建立成功率指标公式，给出了网络中TBF建立尝试成功的比例。
Object Type: CELLGPRS, CELLGPRS2
下行TBF建立成功率公式为：
100-100 * (FAILDLTBFEST / DLTBFEST)
上行TBF建立成功率的公式为：
100-100 * (PREJTFI + PREJOTH) / PSCHREQ
---------- old
100 * (MSESTULTBF / PSCHREQ )
---------- new
COUNTER的含义，我还是翻下阿莱士文档的。
下行TBF建立失败数：FAILDLTBFEST
这个计数器记录了下行TBF建立尝试失败的次数，失败的原因是由于下面提到的一个或多个原因：信道故障，信道预清空，没有可用的无线信道，TFI匮乏，MS个体的匮乏，MAC拥塞，由于CP负荷调整导致的拥塞。
下行TBF建立申请数：DLTBFEST
这个计数器记录了所有下行TBF建立尝试成功的次数(DLTBFEST always stepped when FAILDLTBFESTis stepped)（包括CCCH, PACCH or PCCCH）以及下行TBF建立尝试失败的次数，这些建立失败主要是由于下面一个或多个原因：手机没有响应，接入的延迟大于了TA的最大值，Packet CTRL ACK 消息语法错误，RLC中断，未指明的错误，立即指派发送计时器超时，信道故障，信道预清空，没有可用信道，TFI匮乏，MS个体的匮乏，MAC拥塞，由于CP负荷调整导致的拥塞。
该计数器随着48.018 DL-UNITDATA到达PCU而增加。
上行TBF建立因容量原因失败数：PREJTFI
这个计数器记录了分组接入请求被拒绝的次数，拒绝的原因是没有PDCH，没有USF或没有足够的TFI。请求被拒绝是通过发送"Immediate Assignment Reject"消息或 "Packet Access Reject"消息。
通过增加分配给PDCH的BPC个数将对这个计数器有一个正面的影响，同时参数ULDELAY，USFLIMIT和TFILIMIT也会对这个计数器有影响。
采集消息：

• 44.060 PACKET ACCESS REJECT

• 44.018 IMMEDIATE ASSIGNMENT REJECT

上行TBF建立非容量原因失败数：PREJOTH
这个计数器记录了分组接入被拒绝的次数，拒绝的原因是除了“没有PDCH，没有USF或没有TFI”之外的其他原因。此外请求被拒绝是通过发送"Immediate Assignment Reject"消息或"Packet Access Reject"消息。
采集消息：

• 44.060 PACKET ACCESS REJECT

• 44.018 IMMEDIATE ASSIGNMENT REJECT

上行TBF建立申请数：PSCHREQ
这个计数器记录了PCU中接收到的小区中任何信道上分组接入请求的次数，包括RACH，PRACH或PACCH （in Packet Downlink Ack/Nack)，一个分组接入请求通常是在上行TBF中建立的。
采集消息：

• 44.060 PACKET CHANNEL REQUEST
• 44.060 EGPRS PACKET CHANNEL REQUEST
• 44.058 CHANNEL REQUIRED containing 44.018 CHANNEL REQUEST with establishment cause "One Phase Packet Access" and "Single Block Access".
• 44.060 PACKET DOWNLINK ACK/NACK if Information Element "Channel Request Description" is included.
• 44.060 EGPRS PACKET DOWNLINK ACK/NACK if Information Element "Channel Request Description" is included.

新的上行TBF建立成功数：MSESTULTBF
这个计数器记录上行建立成功并且开始传送数据（至少收到一个RLC Block）的TBF数。MSESTULTBF较低是受PDCH资源或用户行为有关。


之所以在上行指标公式产生变化了之后，还把原有的旧公式做讲解，是因为在分析新的上行建立成功率指标时，还是需要去分析容量原因和无线原因，因此PREJTFI和PREJOTH这两个counter仍然需要关注。

非常不错。。。。。。。。。。。
尤其楼主不用附件的方式，我很赞同啊。

[ 本帖最后由 pandeng0701 于 2011-6-1 11:51 编辑 ]

您好请问你的这份TBF资料能贴出来供下载么