TBF建立成功率Word文件下载.docx
- 文档编号:21008539
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:16
- 大小:2.21MB
TBF建立成功率Word文件下载.docx
《TBF建立成功率Word文件下载.docx》由会员分享,可在线阅读,更多相关《TBF建立成功率Word文件下载.docx(16页珍藏版)》请在冰豆网上搜索。
PDCH从编码方式来分,有BPDCH/GPDCH/EPDCH。
B-PDCH(BasicPDCHcapableofCS1&
CS2),G-PDCH(GeneralPDCHcapableofCS3&
CS4),E-PDCH(EDGEPDCHcapableofEGPRSandCS1toCS4)。
从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体系里属于容量相关,通常有SharingonB,G,E-PDCH(DL&
UL)、SharingonE-PDCH(DL&
UL)4个KPI。
比如SharingonE-PDCH-DL
公式为:
DLTBFPEPDCH/DLEPDCH
ObjectType:
TRAFDLGPRS
DLTBFPEPDCH在每个E-PDCH上所承载的同时发生的TBF(所有的TBF类型)的总和。
DLEPDCH承载一个或多个任何类型的TBF的E-PDCH的个数。
还是上图助于我们理解,上图所示情况,这样在下行方向上,DLEPDCH=++2(这个好理解,就是CHGR1的TS6、7);
DLTBFPEPDCH=++4(在EPDCH上多少个TBF呢?
再见图解)
因此例子中SharingonE-PDCH-DL(或者你习惯叫下行ETBF复用度了)=DLTBFPEPDCH=4
----------------------------------
DLEPDCH=2
结果当前SharingonE-PDCH-DL=2。
这样TBFDLLIMIT是30(也是3个TBF的复用度),而统计的TBF复用度是2。
而更普通情况则是SharingonE-PDCH-DL>
TBFDLLIMIT。
这又是为什么?
我们说了TBFDLLIMIT是每PDCH上激活状态的TBF复用个数,那么再见图:
下面这两个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建立尝试成功的比例。
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建立尝试成功的次数(DLTBFESTalwayssteppedwhenFAILDLTBFESTisstepped)(包括CCCH,PACCHorPCCCH)以及下行TBF建立尝试失败的次数,这些建立失败主要是由于下面一个或多个原因:
手机没有响应,接入的延迟大于了TA的最大值,PacketCTRLACK消息语法错误,RLC中断,未指明的错误,立即指派发送计时器超时,信道故障,信道预清空,没有可用信道,TFI匮乏,MS个体的匮乏,MAC拥塞,由于CP负荷调整导致的拥塞。
该计数器随着48.018DL-UNITDATA到达PCU而增加。
上行TBF建立因容量原因失败数:
PREJTFI
这个计数器记录了分组接入请求被拒绝的次数,拒绝的原因是没有PDCH,没有USF或没有足够的TFI。
请求被拒绝是通过发送"
ImmediateAssignmentReject"
消息或"
PacketAccessReject"
消息。
通过增加分配给PDCH的BPC个数将对这个计数器有一个正面的影响,同时参数ULDELAY,USFLIMIT和TFILIMIT也会对这个计数器有影响。
采集消息:
44.060PACKETACCESSREJECT
44.018IMMEDIATEASSIGNMENTREJECT
上行TBF建立非容量原因失败数:
PREJOTH
这个计数器记录了分组接入被拒绝的次数,拒绝的原因是除了“没有PDCH,没有USF或没有TFI”之外的其他原因。
此外请求被拒绝是通过发送"
消息或"
上行TBF建立申请数:
PSCHREQ
这个计数器记录了PCU中接收到的小区中任何信道上分组接入请求的次数,包括RACH,PRACH或PACCH(inPacketDownlinkAck/Nack),一个分组接入请求通常是在上行TBF中建立的。
44.060PACKETCHANNELREQUEST
44.060EGPRSPACKETCHANNELREQUEST
44.058CHANNELREQUIREDcontaining44.018CHANNELREQUESTwithestablishmentcause"
OnePhasePacketAccess"
and"
SingleBlockAccess"
.
44.060PACKETDOWNLINKACK/NACKifInformationElement"
ChannelRequestDescription"
isincluded.
44.060EGPRSPACKETDOWNLINKACK/NACKifInformationElement"
新的上行TBF建立成功数:
MSESTULTBF
这个计数器记录上行建立成功并且开始传送数据(至少收到一个RLCBlock)的TBF数。
MSESTULTBF较低是受PDCH资源或用户行为有关。
之所以在上行指标公式产生变化了之后,还把原有的旧公式做讲解,是因为在分析新的上行建立成功率指标时,还是需要去分析容量原因和无线原因,因此PREJTFI和PREJOTH这两个counter仍然需要关注。
在介绍完毕TBF建立成功率的指标公式组成后,需要介绍TBF建立过程的信令流程。
现网中采取的是网络模式2,不配置MPDCH,并且采取的是2步接入。
因此:
在没有MPDCH配置的小区,TBF建立在CCCH上进行。
如果当前用户已有上行或下行TBF在用,则另一个方向的TBF建立在PACCH上进行。
从本人经验来看,TBF建立受资源影响主要体现在CCCH容量、TFI资源、USF资源、TAI资源、以及PDCH资源。
特别是PDCH资源,如果BSS根据策略不能预留出至少一个PDCH,则下行方向的IMMEDIATEASSIGNMENT不会发送;
下行方向的PACKETDOWNLINKASSIGNMENT不会发送;
上行方向的PACKETUPLINKASSIGNMENT不会发送。
而无线环境侧的影响则主要是EDGE频点质量、和上行干扰。
首先我们还是根据TBF建立过程的信令流程来理顺一下TBF建立的思路。
(关于信令流程,大家可在阿莱士的FLOWGRAPHS),虽然能查到资料,但是我还是把我自己的理解综合给大家介绍下。
第一个介绍的流程是上行TBF建立,分不存在或者已存在下行的TBF两种情况;
反过来第二个介绍的是下行TBF建立,也分不存在或者已存在上行的TBF两种情况。
这些情况大家应该能理解吧,你要传数据,则你需要建上行TBF,如果你此前没接收过网络侧过来的数据,则你建立的上行TBF,属于不存在已有下行TBF的情况;
如果你此前接收过网络侧的数据,则你此时建立的上行TBF,属于已经存在有下行TBF的情况。
下行情况则反之。
OK。
结束铺垫吧,各位看官,本人都已经记不起这是第几次前戏了。
再次插入主题。
上行TBF建立需求有:
终端发送高层信令(如TCP应答)、小区更新、上传数据(如FTP)、ATTACH附着、RAU路由区更新、Paging寻呼过程。
没有已建立的下行TBF存在时的上行TBF建立流程:
上图,有图有真相啊
当一个状态为Standby的并且监听在BCCH上的用户,需要在上行方向上传送数据时,需要建立一个上行的TBF。
上图的详细过程如下:
终端通过RACH发送“信道请求”,系统用AGCH发送“立即指派”,终端在PACCH上发送PDCH资源申请,系统通过PACCH发送“分组上行指派”消息为终端分配PDCH资源,建立上行TBF!
终端通过PDCH发送数据,系统发送“上行数据包应答”
当终端被告知所有RLC数据包都已经成功被系统收到,发送“控制应答”,结束此次上行TBF。
以上过程中,以下情况出现时,“立即指派拒绝”的消息通过AGCH发送给MS:
没有有效的资源,如:
没有PDCH,TFI,USF以及TAI。
接入的时延大于该小区允许的最大TA值。
有已建立的下行TBF存在时的上行TBF建立流程:
当一个状态为Ready的并且已经存在一个下行TBF的用户,需要在上行方向上传送数据时,需要建立一个上行的TBF。
MS不用回到RACH申请PDCH,而是直接在下行TBF分配到的PDCH上发送信道申请——通过在PACCH回复的“下行数据包应答”中加入“上行信道请求”信息,
系统发送“上行指派”,为终端分配PDCH资源,建立上行TBF。
如果系统没有PDCH资源,则通过PACCH发送“PACKETACCESSREJECT”给终端。
此时上行TBF建立中断。
T3168计数器规定了两次“上行信道请求”的时间间隔,爱立信系统的设置为500ms,这一计数器在SI13中广播。
下行TBF建立需求有:
发送高层信令和数据(如FTP)、ATTACH附着、RAU路由区更新。
没有已建立的上行TBF存在时的下行TBF建立流程:
继续有图,继续有真相
终端在GMMReady&
PacketIdle状态下监听AGCH。
当有数据需要传送给MS时,需要建立一个下行的TBF。
上图详细过程如下:
系统通过发送“立即指派”为终端配置PDCH资源(其中包含一个PDCH的预留),开始建立下行TBF
为了获得无线传输必需的TA值,系统发送“询问请求”要求终端进行回应,终端发送“控制应答”
系统获得需要的TA信息,通过“下行指派”重新建立下行TBF
发送下行的RLC数据包,当终端成功接收到所有的RLC数据后,发送“下行数据包应答“,结束下行TBF。
如果在“立即指派”时,系统未能分配全部PDCH(和终端多时隙等级相同),而在第二次指派前分配到的PDCH数目仍未发生变化,系统将发送“功控/时延信息”(PacketPowerControl/TimingAdvance)为已建立的TBF更新TA值。
有已建立的上行TBF存在时的下行TBF建立流程:
当有数据需要传送给一个已经建立了上行TBF的用户时,需要建立一个下行的TBF。
手机在Packettransfer模式下持续接收所有的下行RLC数据包,并获得系统在PACCH上发送的“下行指派”信令,终端回应“控制应答”,成功建立下行TBF。
如果BSC不能成功接收到“PACKETDOWNLINKACK/NACK”,终端会重发最多6次。
直到BSC成功接收,否则TBF建立中断。
嗯,大家鼓掌,这就是TBF建立的信令流程分析了,我绞尽了脑汁,汗流浃背,看官你有受惊没?
好吧没有掌声也没有关注,我也继续。
TBF建立过程涉及的COUNTER触发机制分析,这部分的图都是阿莱士的。
翻出来加上自己的理解给大家过过。
上行TBF建立过程涉及COUNTER的触发
依据本人对上面的计数器流程图理解。
系统接收到“信道请求“消息,PSCHREQ跳变;
系统不能对接收到“信道请求“消息进行处理,PREJTFI,PREJOTH跳变;
系统没有PDCH可预留分配,PREJTFI,PREJOTH跳变;
其中造成PREJTFI的原因是由于下面一个原因:
没有PDCH,没有USF或没有足够的TFI。
其中造成PREJOTH的原因是由于除去“没有PDCH,没有USF或没有足够的TFI“之外的PACKETACCESSREJECT或者IMMEDIATEASSIGNMENTREJECT。
下行TBF建立过程涉及COUNTER的触发
同样本人对上图的理解:
MSInd不能被获取,DLTBFEST,FAILDLTBFEST跳变;
没有PDCH可预留分配,DLTBFEST,FAILDLTBFEST跳变;
TFI不能被获取,DLTBFEST,FAILDLTBFEST跳变;
CP不能正常接收RP发出的信令,DLTBFEST,FAILDLTBFEST跳变;
“IMMEDIATEASSIGNMENT”消息没有被接收,DLTBFEST,FAILDLTBFEST跳变;
由于IMMEDIATEASSIGNMENT均是在下行的AGCH上发送,而我们的经验是如果某小区IMMEDIATEASSIGNMENT超过5万个,则有可能发生“IMMEDIATEASSIGNMENT”消息不能被MS接收。
CCCH能承载的BLOCK数量为9*3600/0.2354=137638,而部分小区光PSIMMEDIATEASSIGNMENT都超过CCCH所能承载的BLOCK数量。
可见CCCH的容量不足是这里的主要原因。
“分组控制响应“消息没有被接收,DLTBFEST,FAILDLTBFEST跳变;
“分组控制响应“消息内容不正常,DLTBFEST,FAILDLTBFEST跳变。
其中造成FAILDLTBFEST的原因是由于下面一个或多个原因:
UPLINKTBF建立成功率新旧公式区别
对比上行TBF建立成功率新旧公式区别:
主要体现在分子COUNTER的变化。
最新的阿莱士说:
可见新的TBF建立成功率统计的触发是需要MS开始传送上行数据,并且BSC至少收到MS发出的一个RLCdatablock。
回过头我们看上行TBF建立过程涉及COUNTER的触发流程图里。
最后一个失败数跳变节点在中间。
而新的MSESTULTBF的跳变应该在流程最后处。
(完全是本人依据字面意思推测,也经过部分阿莱士内容的查询推导)
本人看图理解,上行TBF建立成功率将PDCH资源的影响进一步放大。
新的指标需要判断:
“PacketResourceRequest“消息发送结果是否成功,A-Bis、Um链路质量是导致不成功因素之一;
系统为MS分配预留的PDCH(多于一个,尽量达到手机支持的时隙能力所需求的PDCH数)是否成功,如果没有更多的PDCH可分配,则TBF建立将被中断;
“PacketUplinkAssignment“消息发送结果是否成功,A-Bis、Um链路质量是导致不成功因素之一;
当MS开始传送数据后,BSC至少收到一个MS发送出的RLCdatablock。
至此,新的公式才认为一次上行TBF建立成功。
因此我们总结出,与旧的上行TBF建立成功率相比,新的上行TBF建立成功率更加突出了PDCH资源影响的因素。
另外用户行为也是一个非常明显的影响原因!
TBF建立受CCCH资源的影响:
通过上述TBF建立信令流程的分析,我们知道了在TBF建立阶段的初期,主要通过CCCH交互信令,而TBF建立阶段产生的IMMEDIATEASSIGNMENT并不是一个MS在上网期间产生的全部CCCH消耗。
到这个阶段,我们总结一下TBF的建立原理
通过以上的分析,我们知道TBF建立主要在CCCH上进行;
在当前用户已有上行或下行TBF在用,则另一个方向的TBF建立在PACCH上进行。
因此TBF建立受资源影响主要体现在CCCH信道上。
而针对CCCH信道的评估我们在上一个话题以作探讨。
同时,系统以TFI来区分识别各用户,并且在接入阶段会给用户分配TFI,因此TFI的资源匮乏同样将导致TBF建立失败;
每个PSET里有32个TFI,这样一个PSET里能容纳的用户的极限是32个。
最直接的理解是,如果还有第33个用户要接入到这个PSET就会因为没有TFI而被系统拒绝。
(说到这里,发现好像前戏做的不是很足,还有继续的余地,呵呵在前面还可以讲讲PSET,不过这一引申还得讲GPRS的channeladministration了,前戏太多就不是前戏了,有可能高潮在前戏中就结束)。
其实单个小区的TFI是没有限制的,虽然你一个PSET里的极限是32,但如果你资源充足的话,还可以触发下一个PSET的建立,这样你在下一个PSET里仍有32个TFI资源。
依次往后类推。
USF资源对TBF建立成功的影响与TFI类似,在上行方向上,系统以USF来区分识别各用户,而一个PSET里每PDCH上USF的资源为8个;
不过通常来说USF不会成为资源瓶颈,这主要是因为咱们设置的TBFxLLIMIT的设置范围是10~80。
从后续进程来看,用户的接入最终是为了占用PDCH传送数据,因此在接入阶段,系统会根据策略为用户预留PDCH,如果没有至少一个PDCH能被预留(大部分情况如此,有些时候需要预留更多的PDCH),则接入进程将会被终止,从而TBF建立失败;
CSDomian业务繁忙是导致PDCH不能被预留的原因之一;
而参数ODPDCHLIMIT的设置使得CSDomain的空闲信道不能被PSDomian使用,导致没有更多PDCH被预留;
当然最多的情况是小区信道容量(不管是CSPSDomian)不够,导致没有再多的PDCH预留而造成TBF建立失败。
OK关于TBF建立的原理部分,就讲这些了。
针对TBF建立成功率的优化,做个流程介绍。
TBF释放后才释放PDCH,TBF延迟释放功能DLDELAY,应该是几乎同时了吧?
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TBF 建立 成功率
![提示](https://static.bdocx.com/images/bang_tan.gif)