高高顶起！

回来了！！！嘿嘿，先把之前的close，然后再发些水贴。

TBF建立受CCCH资源的影响：
通过上述TBF建立信令流程的分析，我们知道了在TBF建立阶段的初期，主要通过CCCH交互信令，而TBF建立阶段产生的IMMEDIATE ASSIGNMENT并不是一个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的channel administration了，前戏太多就不是前戏了，有可能高潮在前戏中就结束）。其实单个小区的TFI是没有限制的，虽然你一个PSET里的极限是32，但如果你资源充足的话，还可以触发下一个PSET的建立，这样你在下一个PSET里仍有32个TFI资源。依次往后类推。
USF资源对TBF建立成功的影响与TFI类似，在上行方向上，系统以USF来区分识别各用户，而一个PSET里每PDCH上USF的资源为8个；不过通常来说USF不会成为资源瓶颈，这主要是因为咱们设置的TBFxLLIMIT的设置范围是10~80。
从后续进程来看，用户的接入最终是为了占用PDCH传送数据，因此在接入阶段，系统会根据策略为用户预留PDCH，如果没有至少一个PDCH能被预留（大部分情况如此，有些时候需要预留更多的PDCH），则接入进程将会被终止，从而TBF建立失败；CS Domian业务繁忙是导致PDCH不能被预留的原因之一；而参数ODPDCHLIMIT的设置使得CS Domain的空闲信道不能被PS Domian使用，导致没有更多PDCH被预留；当然最多的情况是小区信道容量（不管是CS PS Domian）不够，导致没有再多的PDCH预留而造成TBF建立失败。

OK 关于TBF建立的原理部分，就讲这些了。

针对TBF建立成功率的优化，做个流程介绍。
[attach]179865[/attach]

[ 本帖最后由 molanrotbio 于 2011-7-20 22:02 编辑 ]

晕死，图发好几遍，版主帮忙把附件删掉吧。

PCU load control介绍

有效的挖掘PCU中各RPP潜力是提供整个PCU容量的好方法。避免RPP内的话务之间的冲突，甚至重启，避免CPU负荷过重，这些思路都可以使得CPU处理更多的话务流量。本功能通过优化CPU中的各种行为、以及为了限制负荷过高而设置的一些功能门限来实现。
PCU负荷功能分担主要分三个部分：
Ø RPP内负荷管理
负荷管理功能通过GPH内的一种新的负荷管理功能，使得重要的话务流量得到足够的CPU时间资源。
Ø RPP内过负荷保护
过负荷保护机制通过更快得对CPU负荷和内存使用情况做处理，保证不会因为负荷过高导致的RPP重启。当负荷升高的时候，系统会做以下包含措施：
高负荷情况：
l 停止RPEF时间，并停止在该RPP内加入新的GSL信道
l 通过减少PILTIMER提前释放空闲ondemand PDCH来减轻负荷
l 逐步清除PDCH
低内存情况：
l 减少MS的流控内存块的大小
l 禁止新的TBF在该RPP建立
Ø RPP间负荷分担

RPP间负荷分担功能通过检测和比较所有PCU内各RPP的负荷情况，可触发cellmove，通过这种方式平衡各RPP间的负荷。这种方式相对上面两种需要的时间较长，相对于突发话务的均衡，该方法是一种较长期的均衡方法。
<br />                <img src="attachments/month_1107/20110720_1ba44921558406bb33f3zuH6nv66PPUN.jpg.thumb.jpg" border="0" aid="attachimg_179870" width="400" alt="" /><br />               

RPP间负荷分担
RPP负荷分担流程启动如下：
l 在GSL资源出现问题的RPP所管理的小区中选择一个合适的小区，该小区在所有候选小区中承载TBF数量尽量少，同时该小区中固定PDCH数量尽量多。这样可以保证在该小区迁移时，影响到用户（TBF）较少，而一次迁移空闲出的GSL资源较多。
l 在将选定的小区迁移时，如果迁移成功，该小区中的CELLMOVED和MOVECELLTBF要相应计数。
l 如果迁移失败，在BSCGPRS中的FAILMOVECELL要计数。

[ 本帖最后由 molanrotbio 于 2011-7-20 22:13 编辑 ]

Flexible Abis
动态Abis功能的目的是优化使用Abis接口上的传输，更好地利用有限的传输资源并且节省GSL设备。目前的ABIS分配算法是提供足够宽（64kpbs）的Abis路径来满足同时进行的在所有小区和所有时间内在特定的TG内的多时隙业务，而新功能仅需提供少量的Abis路径来进行同样的业务。这些Abis路径仅在信道被激活时被连接到相应信道，而不是在配置时就分配给信道。当一个信道去激活时，相应的Abis路径被释放，从而可以被用给对应TG的其它信道。
ABIS动态池由16kpbs和64kpbs的Abis路径组成。在PS数据传输中分配了16kpbs的Abis路径的信道也可以升级使用64kpbs的Abis路径。当非EGPRS性能的GPRS终端进入一个小区并且没有分配资源时，可以通过参数FLEXHIGHGPRS来选择是分配一个16kpbs的Abis路径或是64kpbs的Abis路径。当分配了16kpbs的Abis路径后就不能保证CS-3和CS-4的使用，但是就可以保留64kpbs的Abis路径给EGPRS业务使用。
动态Abis功能的目的是优化使用Abis接口上的传输，更好地利用有限的传输资源并且节省GSL设备。目前的ABIS分配算法是提供足够宽（64kpbs）的Abis路径来满足同时进行的在所有小区和所有时间内在特定的TG内的多时隙业务，而新功能仅需提供少量的Abis路径来进行同样的业务。这些Abis路径仅在信道被激活时被连接到相应信道，而不是在配置时就分配给信道。当一个信道去激活时，相应的Abis路径被释放，从而可以被用给对应TG的其它信道。
ABIS动态池由16kpbs和64kpbs的Abis路径组成。在PS数据传输中分配了16kpbs的Abis路径的信道也可以升级使用64kpbs的Abis路径。当非EGPRS性能的GPRS终端进入一个小区并且没有分配资源时，可以通过参数FLEXHIGHGPRS来选择是分配一个16kpbs的Abis路径或是64kpbs的Abis路径。当分配了16kpbs的Abis路径后就不能保证CS-3和CS-4的使用，但是就可以保留64kpbs的Abis路径给EGPRS业务使用。
[attach]179873[/attach]

当在G-TCHS和E-TCHS上分配ondemand或半专用PDCH的时候，对应的Abis传输设备就可以从池资源中获取。当然，FPDCH仍然是与Abis传输设备和GSL设备固定相连。
另外，CS呼叫也可以使用Abis池中的共享传输设备，其使用的是16k的Abis传输设备。



主要改进和变化：
Ø 使分散在不同64kAbis时隙上的16kAbis打包合成一处，
Ø 使分散在不同64kGSL时隙上的16kGSL打包合成一处，
Ø 把FLEX64KGPRS重命名FLEXHIGHGPRS
Ø 提升了ABIS链路降级功能
Ø 由于ABIS拥塞导致的PDCH预清空
Ø BPDCH向EPDCH升级过程中的TBF升级和预留

全速率AMR在8kAIS上的使用。

EGPRS/GPRSLoad Optimization

目前，在多个用户共享信道的时候，各用户使用信道的机会均等，与手机的MSRAC能力和无线环境无关。GPRS/EGPRS Load Optimization 通过减少RF环境差的用户或者GPRS的用户使用信道的机会、增加正常RF环境用户和EGPRS用户使用信道的机会，提高整个小区throughput、从而提高系统的PS容量。这是牺牲公平性来获得系统级的性能。
根据共享信道中用户的无线质量进行资源调度方面的优化，增加小区的数据吞吐速率；通过更多的为拥有更好无线连接的用户发送数据，来提高用户和整个系统的数据传输速率。
功能关闭时：
[attach]179877[/attach]
功能开启时：
[attach]179878[/attach]
当一个GPRS/EGPRS用户（TBF）处于很差的RF环境下，它的Throughput会变差。用户Throughput低于某个门限时，系统就减少对这个用户（TBF）的Schedule、而增加对其他用户的Schedule。
为了把TBF置于级别较低的模式，需要满足以下条件：
Ø Qos的类型为交互型、背景型；
Ø 该TBF的数据流量中等或偏小；
Ø MAC模式是DA（仅对于上行）。
GPRS/EGPRS Load Optimization在上、下行均有效，也在GPRS和EGPRS用户间有效。该Feature对QoS级别Interactive和Background的TBF起作用，如果系统QoS功能没有激活、则对所有用户起作用。

1. 下行TBF负荷优化的实现
对于每个下行TBF有一个滑动窗口，其记录最后50个RLC/MAC无线块的无线比特率。它的无线比特率对应MS发回的44.060 (EGPRS) PACKET DOWNLINK ACK/NACK进行计算。当计算出的无线比特率低于LOPTGTHR或LOPTETHR，那么该TBF就置于低预留模式，同时该滑动窗口清空。
特殊情况：
Ø 某TBF处以低预留模式，此时该TBF的Qos等级更新，如果LOADOPT激活，那么系统会检查该TBF的Qos等级是否满足上述的几个关于Qos的条件，如果不满足，则把被置低预留级别的TBF恢复正常。
Ø 如果编码方式高于CS-2或MCS-5，那么该TBF的的预留方式也将恢复正常。
Ø 对于处以低预留模式下的TBF，在向MS发送NACC所需要的系统信息时，该TBF会被系统认为处于正常的预留等级。
2. 上行TBF负荷优化的实现
当上行流量较低，那么该上行TBF应处于一个无线环境较差的环境。如果它处于动态分配模式，那么该TBF就会被置于低预留模式。如果某TBF处于扩展动态分配模式，那么应先转换成动态分配模式，然后才开始评估该TBF的预留级别。

对应每个上行TBF有个滑动窗口，存储至少100个RLC/MAC块。每当向MS发送44.060 (EGPRS) PACKET UPLINK ACK/NACK开始进行计算，计算出来的无线链路比特率和预留的USF数量一起保留，当总共对100个上行的 RLC/MAC响应后，计算出一个平均无线比特率的值。这100个RLC/MAC可以包括真实的数据帧、填充帧和重传帧等。当计算出来的无线链路比特率低于LOPTGTHR or LOPTETHR，那么该上行的TBF就置于低预留模式，然后滑动窗口全部清空。

Five Downlink Timeslots
该功能可以根据MS的多时隙能力，提供下行5个、上行4个，同时总共6个信道。实现了支持3GPP协议中关于30－33等级的MS，如下图：
[attach]179888[/attach]
同时，系统还提供了等级从34－45的MS所对应的不同的映射功能：

[attach]179889[/attach]

同时针对该功能，引入了 新的统计counter

• MUTIL15

• MUTIL25

• MUTIL35

• MUTIL45

• MUTIL55

Five Downlink Timeslots应用前景
该功能的最大特点就是增加了系统对下行时隙的支持数量，下行5个TS，可以增加25%的下行流量；
同时系统总共支持上下行6个TS，比R10中仅支持5个TS可以增加20％的上下行总流量。

[ 本帖最后由 molanrotbio 于 2011-7-20 22:52 编辑 ]

Single Phase Access for EGPRS

EGPRS手机可以发送11bit类型的信道接入请求信令，此时系统将完成一步接入过程，即立即指派信令将直接建立上行TBF（此时数据传输可以立即开始），而之前需要两步接入过程之后，手机才能建立上行TBF。
一步接入功能通过缩短TBF建立时间，能够改善小数据传输应用（如TCP握手过程）建立的性能。
[attach]179890[/attach]
该功能可以使BSS系统更好的减少诸如延迟敏感等的业务如EIT的时延。这种时延的减少主要通过下面两个方面实现：

• 减少EDGE的TBF的建立时间
• 更快的获取MS的多时隙能力

该功能由以下两个部分组成

• EGPRS Access on CCCH

目前，在没有设置PBCCH的网络中，是不允许一次接入的。而本功能支持EGPRS在CCCH上用Packet channel Request一次接入，被指配一个上行的ETBF。对比两次接入，可以节省大约300ms的时间。

• Improved acquisition of MS Radio Access Capabilities

在EGPRS使用一次接入方式接入网络，并获得上行ETBF的时候，BSS是无法获知MS的多时隙能力的，因此在上行ETBF释放前，系统无法知道MS的多时隙接入能力，MS也就无法进入扩展上行TBF模式。扩展上行TBF模式对于诸如EIT等流媒体业务是非常有益的。
对于一次接入的EGPRS用户，系统通过Packet uplink assignment或Immediate assignment(依据系统是否设置MPDCH)这两条包含Access Technologies Request IE的信令要求MS上报多时隙接入能力。
需要注意的是，对于使用两阶段接入的MS，其多时隙接入能力已经是被系统获知，这样系统就可以判断是否允许MS进入扩容TBF模式。
Single Phase Access for EGPRS应用前景
该功能需要把BCCH/CCCH配置在带电的TRU上，如dTRU、dTRUe、sTRU、RRU，否则无法激活该功能。
该功能激活后，系统会自动把BCCH/CCCH配置在这些TRU上。如果没有激活该功能或者是没有可以激活该功能的TRU，那么BCCH/CCCH就会优先配置在不具有EGPRS能力的TRU上。

ok,今晚到这啊，明天有时间继续。大家不要太期待哦！

竟然真没人期待，有木有？？

木人期待也继续！

Dual Transfer Mode

DTM模式可以是MS同时进行语音和数据业务，这使得用户在进行通话的时候可以不中断数据业务的业务。同时，支持DTM的终端可以在FACCH或SDCCH上进行联合LA/RA，这样可以避免因为进行RA进行单独的TBF连接，节省无线信道和PCU资源的耗费。当然要使用DTM方式，同时需要BSC和MS都要支持该功能才行。
据估计，目前市场上支持DTM的终端比例不会太高，但是DTM功能对于不支持DTM终端仍然有一个非常重要的作用，可以使得这类不支持DTM的终端在进行PS业务的时候可以被CS寻呼，也就是所谓的联合寻呼。
通常的联合寻呼是需要Gs口，这样MSC和SGSN之间进行通信后才能进行联合寻呼，但开启了DTM功能后，通过BSC和SGSN之间的信令交互，就可以实现联合寻呼。但是这需要确认SGSN是否支持联合寻呼功能。

Dual Transfer Mode应用前景

随着数据业务的应用日益广泛，越来越多的客户在使用PS业务，而对于大多数用户来说，通常只用一张SIM卡，而受限于BSC和MS的能力，这决定了他们无法同时进行PS和CS业务，而DTM的引入，使得高性能终端同时使用CS和PS业务成为可能。对于低端的终端，可以使之在进行PS业务的同时不会漏掉来电。

Extended Dynamic Allocation

EDA（Extended Dynamic Allocation）是一种扩展的上行信道分配方式，需要BSC和MS升级到一定等级才能支持该功能。BSC需要升级到R12/07A以上，而MS需要是CLASS 12以上的才支持。
如果系统开启了上下行状态转换功能，即DYNULDL，并把GPRSEDAACT功能激活，那么当上行流量满足一定条件，系统就可以使用EDA方式，使得该上行的TBF得到尽可能多的上行时隙信道，如CLASS 12的MS可以分配到4个上行时隙。
目前系统总共支持三种状态，偏下行、偏上行、中间态，EDA分配方式只能在MS处于偏上行、中间态中存在。

Extended Dynamic Allocation应用前景

显而易见，通过该功能，对于支持EDA的MS可以得到最大4个时隙的上行信道，对比仅支持DA功能的CLASS 10的MS最多分配2个上行时隙信道，FTP的上载速率可以提高一倍。

PREEMPTION

当CS域没有空闲信道时，会向PS域申请预清空小区中已存在的on-demand PDCH，一般情况下这种预清空针对所有on-demand PDCH都有效，预清空PDCH信道会导致TBF释放，引起数据业务的停顿或释放。为了保证数据业务性能和用户的感知度，在某些情况下我们不希望某些特定类型的数据业务被预清空，如数据流业务等。
开启PREEMPTON功能可以通过设定PDCHPREEMPT参数来调整on-demand PDCH被预清空的方式，减少CS业务预清空PDCH的情况，从而达到降低预清空对PS业务的影响。
PREEMPTON功能开启后，PDCHPREEMPT参数有如下几种设定：
0——表示所有的on-demand PDCH均可以被CS预清空
1——表示仅非DTM（not used for Dual Transfer）的 On-Demand PDCH会被CS预清空
2——表示仅非数据流（not used for Streaming）的 On-Demand PDCH会被CS预清空
3——表示非DTM和非数据流（not used for DTM nor for Streaming）的 On-Demand PDCH会被CS预清空
4——表示仅非必要（not essential）的 On-Demand PDCH会被CS预清空
5——表示非必要和非DTM（not essential nor DTM）的 On-Demand PDCH会被CS预清空
6——表示非必要和非数据流（not essential nor Streaming）的 On-Demand PDCH会被CS预清空
7——表示非必要和非DTM和非数据流（not essential nor DTM nor Streaming）的 On-Demand PDCH会被CS预清空
8——表示空闲（Idle）的 On-Demand PDCH会被CS预清空


PREEMPTION应用前景

在网络拥塞严重比较严重情况下，开启PREEMPTON功能可以有效的减少CS业务预清空PDCH情况，保证数据业务性能和用户感知度，特别是针对数据流业务这种用户感知度较高的业务类型，可以避免数据流过多的中断停顿造成的用户感知度下降。