动态PDTCH扩容标准
中国移动HSDPA无线资源利用率的评估及扩容原则
行 了 分 析 和 研 究 ， 以码 资 源 占用 比例 表 示 业 务 信 道 的 无 线 资 源 利 用率 。 对 于 中 国移 动 正 在 大 力 推 动 和 发展 的 ＴＤ— ＣＤＭ Ａ 据 业 务 ，特 别 Ｓ 数
无需扩容
≤３ ～ ×
（～ ３ ６）× Ｎ
用户数—般 ； 容量需求较少
Ｈ — Ｄ Ｃ 不需考 虑扩容 ；但 当接入失败次数较多时 ．建议增加下行伴随信 ＳＰ Ｓ Ｈ 道的数量 （ 如将３ Ｓ 个Ｈ ． Ｈ 调整为２ 个，最大可 增加 １ 个接入 用户 ，．或者 ６ 进行一定策略的状态迁移
２． １建 议 配 置
是由ＨＳ Ａ系统承载 的高速数据业 务 ，其业 务 ＤＰ
信 道 （ — ＤＳ ＨＳ Ｐ ＣＨ ）为 共 享 信 道 ，传 输 格 式 和调制方 式均是动态调 整方式 ，同时还受限于
（） 线 资 源 配 置 １无
根 据 ＴＤ— ＣＤＭ Ａ业 务 的 总 体 规 划 ，按 照 Ｓ Ｔ Ｓ ＤＭＡ “ 期 重 点 发 展移 动 宽 带 业 务和 基 Ｄ— Ｃ 近 于 双 模 终 端 的 语 音 业 务 ” 的 市场 定 位 ，现 有 网 络 ＨＳ Ａ 波 及时 隙配 置 如 下 ： ＤＰ 载 ・上 下 行 时 隙 配 比 为 ２ ：４， 其 中 Ｈ — Ｓ
Ｐ Ｃ ＤＳ Ｈ时 隙配 置 ３ ； 个
伴随信道 、用户平 均速 率等多种 因素的制 约 ，
不宜再 以业务信道 利用率作为惟 一的计算和评 价 标 准 。 此 外 ，数 据业 务 的 用 户 模 型 也 相 对 较 为 复 杂 ，因 此 ，需 要 根 据 ＨＳ Ａ的技 术 特 点 ， ＤＰ 结 合 用 户 体 验 和 业 务模 型 等 多 种 因 素 重 新 定 义
中国移动4G无线网扩容标准(修订版)
中国移动4G 无线网扩容标准（修订版）4G （TD-LTE ）无线网络扩容包括用户数扩容和载频扩容两个方面。
用户数扩容即基本功能软件包的扩容。
基本功能软件包按照RRC 连接数配置，以本地网为单位共享。
载频扩容以小区为单位进行核算，以基站为单位进行工程实施。
一、用户数扩容（RRC 连接数扩容） （一）扩容标准基本功能软件包按照系统忙时平均RRC 连接数采购，报价单位共8档：0.1万、0.5万、1万、2万、5万、10万、20万、50万，扩容规模=档位取整（规划期末用户数 * 激活因子（忙时平均RRC 连接数/用户数×100%）-现网配置），激活因子按网管数据取定。
（二）扩容方法忙时平均RRC 连接数取连续七日系统忙时各小区“RRC 连接平均数”之和的平均值。
忙时平均RRC 连接数=∑∑小区i 的“RRC 连接平均数”小区数i=17n=17⁄涉及的参数在《NB网元统计数据需求规范》定义如下：二、载频扩容（一）扩容标准按照大、中、小包的小区分类确定标准，当小区自忙时达到门限时实施载频扩容。
小区分类标准及扩容门限如下：小区扩容核定逻辑为：[“有效RRC用户数达到门限”且“上行利用率达到门限”且“上行流量达到门限”]或[“有效RRC用户数达到门限”且“下行利用率达到门限（PDSCH或PDCCH）”且“下行流量达到门限”]。
（二）核算方法载频扩容标准核算使用的数据均为连续七天小区自忙时均值。
用于小区分类的小区自忙时平均E-RAB流量计算公式为：小区自忙时平均E−RAB流量=∑“小区用户面下行字节数”+“小区用户面下行字节数”“E−RAB建立成功数”7n=17⁄载频扩容各参数的计算公式为：①有数据传输的RRC数有数据传输的RRC 数=∑“有效RRC 连接平均数”7n=17⁄②上/下行利用率上行利用率=上行PRB 利用率上行PRB 利用率=∑（“上行PUSCH PRB 占用平均数”/“上行PUSCH PRB 可用平均数”7n=1）7⁄ 下行利用率=“下行PRB 利用率”或“下行CCE 利用率”下行PRB 利用率=∑（“下行PDSCH PRB 占用平均数”/“下行PDSCH PRB 可用平均数”7n=1）7⁄ 下行CCE 利用率=∑（“PDCCH 信道CCE 占用率”7n=1）7⁄③上/下行流量上（下）行流量=∑“小区用户面上（下）行字节数”/10007n=17⁄涉及的参数在《NB 网元统计数据需求规范》定义如下：。
动态扩容实现原理
动态扩容实现原理
动态扩容是指在系统运行时根据需求动态地增加系统资源，例如内存、存储空
间或处理器等。
动态扩容的实现原理主要涉及到系统架构、资源管理和调度等方面。
首先，动态扩容的实现需要一个可靠的系统架构来支持资源的动态调整。
通常，系统需要具备可插拔的模块化设计，使得新增资源能够被系统识别和利用。
此外，系统还需要有一套完善的资源管理机制，能够对系统资源进行有效地监控和调度。
其次，动态扩容实现的关键在于资源的动态管理和调度。
系统需要能够实时监
测资源的利用情况，当资源利用率达到一定阈值时，系统需要自动触发扩容机制。
扩容过程需要考虑资源的分配和调度，确保新增资源能够被合理利用，同时不影响系统的稳定性和性能。
另外，动态扩容还需要考虑资源的可用性和可靠性。
系统需要具备容错和负载
均衡的能力，确保在资源扩容的过程中不会影响系统的正常运行。
此外，系统还需要能够动态地调整资源的分配，使得系统能够根据实际需求动态调整资源的分配比例。
总的来说，动态扩容实现的原理涉及到系统架构、资源管理和调度等方面。
通
过合理的设计和实现，系统能够根据需求动态地增加资源，从而提高系统的灵活性和可靠性。
动态扩容是现代系统设计的重要特性，能够帮助系统应对不断变化的需求和挑战。
动态扩容云服务平滑接入方案
动态扩容云服务平滑接入方案动态扩容云服务平滑接入方案云服务的发展已经成为了现代企业不可或缺的一部分。
随着业务的扩展和用户量的增加，云服务的规模也需要不断扩容。
然而，在扩容过程中，需要注意的是保证服务的稳定性和可靠性，以及确保用户体验不受影响。
因此，制定一套动态扩容云服务平滑接入方案，显得尤为重要。
首先，动态扩容需要进行充分的规划和准备工作。
在系统设计阶段，应考虑到未来可能的扩容需求，采用可扩展的架构和技术。
此外，需要建立监控系统，及时了解系统的负载情况和性能状况。
这样，一旦发现系统负载过高或性能不足，便可以及时进行扩容。
在实施动态扩容时，需要根据实际情况选择合适的扩容策略。
一种常见的策略是水平扩容，即增加服务器数量，平均分担负载。
这可以通过自动----宋停云与您分享----化工具来实现，例如使用容器技术来快速部署和管理多个服务器。
另一种策略是垂直扩容，即增加服务器的硬件配置，提升单个服务器的性能。
这种策略适用于单个请求的处理能力较弱的情况。
在扩容过程中，需要注意避免单点故障。
为了确保服务的高可用性，应采用负载均衡技术，将流量分散到多个服务器上。
同时，还可以采用故障转移和自动容错机制，以保证即使某个服务器发生故障，整个系统也能继续正常运行。
除了考虑技术实现，还需要关注用户体验。
为了确保用户无感知地进行扩容，可以采用灰度发布的方式。
即先将一部分流量引导到新的扩容服务器上，进行测试和验证，确认没有问题后再逐渐增加流量。
这样可以最大程度地减少对用户的影响。
最后，在动态扩容完成后，需要进行性能测试和监控，确保新的扩容服务器能够正常工作，并满----宋停云与您分享----足预期的性能要求。
同时，还需要定期进行容量规划和评估，及时调整扩容策略，以保证云服务的稳定和可靠。
综上所述，动态扩容云服务平滑接入方案需要从系统设计、扩容策略、高可用性、用户体验和监控等多个方面进行考虑。
只有充分规划和准备，并采取合适的策略和措施，才能实现云服务的平滑扩容，满足不断增长的业务需求。
微服务架构的容器编排与动态扩缩容(三)
微服务架构的容器编排与动态扩缩容随着云计算和虚拟化技术的快速发展，微服务架构在软件开发中越来越受欢迎。
微服务通过将单体应用拆分成独立的服务，每个服务可以独立部署、测试和扩展，实现了更高的灵活性和可伸缩性。
然而，当微服务数量增多后，管理和调度这些服务变得越来越困难。
这时候就需要使用容器编排工具来帮助我们管理和调度微服务。
容器编排工具主要用于自动化容器的部署、扩缩容和管理。
Kubernetes就是目前最流行的容器编排工具之一。
Kubernetes可以通过定义和管理容器的副本数来实现动态扩缩容。
当负载过高时，可以自动增加副本数来提供更多的服务能力；当负载下降时，可以自动减少副本数来节省资源。
这种动态扩缩容的能力使得微服务架构更加强大和灵活。
在使用Kubernetes进行容器编排时，首先需要将微服务打包成Docker镜像，并上传到Docker仓库中。
然后，通过Kubernetes的命令行工具kubectl来创建和管理容器编排的资源对象，如Pod、Deployment、Service等。
Pod是最小的部署单元，它可以包含一个或多个容器。
Deployment用于定义Pod的副本数和更新策略。
Service用于暴露Pod的网络接口，以便其他服务或用户可以访问。
当需要动态扩缩容时，可以通过修改Deployment的副本数来实现。
Kubernetes会根据副本数的变化自动创建或删除Pod。
同时，Kubernetes还提供了水平自动扩缩容器的功能，可以根据CPU、内存等指标来自动调整副本数。
这种自动化的动态扩缩容使得系统能够根据实际负载情况来提供足够的服务能力，提高了系统的资源利用率和响应能力。
除了动态扩缩容，容器编排工具还可以提供负载均衡和容错等功能。
负载均衡可以将请求均匀地分发到多个Pod上，提高系统的并发处理能力。
容错机制可以保证在某个Pod出现故障时，其他Pod继续提供服务，确保系统的高可用性。
这些功能都可以通过容器编排工具的配置来实现。
hadoop动态扩容 原理
hadoop动态扩容原理Hadoop动态扩容原理1. 引言在大数据领域，Hadoop是一种被广泛使用的分布式计算框架。
随着数据规模的不断增长，Hadoop动态扩容成为了一个重要的需求。
本文将从浅入深地解释Hadoop动态扩容的原理。
2. Hadoop概述Hadoop是一个开源的分布式计算框架，主要包含两个核心组件：Hadoop Distributed File System (HDFS)和MapReduce。
Hadoop通过将大规模数据集分割成多个小任务，然后分布式计算这些小任务，从而实现高效的数据处理。
3. 动态扩容的意义在实际应用中，数据量的增长是不可避免的。
因此，保证集群的性能和可用性是至关重要的。
动态扩容能够根据实际需求自动增加或减少集群的节点数量，以适应不断变化的负载情况，提高整个系统的处理能力。
4. Hadoop动态扩容原理节点管理器（Node Manager）Hadoop集群中的每个节点都运行一个节点管理器（Node Manager），用于管理该节点的资源和任务调度。
节点管理器定期向资源管理器（Resource Manager）报告该节点的资源状况并接收任务分配。
资源管理器（Resource Manager）资源管理器（Resource Manager）是Hadoop集群中的一个主节点，负责整个集群的资源管理和任务调度。
资源管理器根据集群当前的负载情况和配置策略，决定是否需要进行动态扩容。
动态扩容过程动态扩容的过程主要涉及以下几个步骤： - 步骤一：检测负载情况。
资源管理器通过监控集群的负载情况，如CPU利用率、内存使用率和任务队列长度等指标，判断是否需要进行动态扩容。
- 步骤二：生成扩容计划。
资源管理器根据负载情况和配置策略，生成扩容计划，包括需要新增的节点数量和节点配置信息。
- 步骤三：节点启动。
资源管理器向新增节点发送启动指令，并将新增节点添加到集群的节点列表中。
- 步骤四：节点注册。
云扩容相关的标准
云扩容相关的标准包括：
1.可扩展性：存储服务器必须具备良好的可扩展性，以适应云计算平台动态
增长和不断变化的存储需求。
2.可靠性：数据在云计算平台中的存储需求一般具有高可靠性要求，存储服
务器应采用可靠的硬件和软件设备，确保数据的安全和可靠性。
3.高性能：云计算平台对存储服务器的性能要求很高，包括存储容量、数据
传输速度以及响应时间等。
4.云服务提供商的限制：不同的云服务提供商可能有不同的限制，例如最大
的扩容容量、最大的虚拟机数量等。
5.物理服务器的限制：云主机实际运行在物理服务器上，物理服务器的资源
也是有限的，扩容过程可能会受到物理服务器资源的限制。
6.账户的限制：用户账户可能有一定的资源配额，扩容时需要确保账户的资
源配额足够。
7.操作系统的限制：操作系统对于硬件资源的支持也是有限的，扩容时需要
确保操作系统的支持能够满足扩容后的需求。
Docker容器的动态资源调整和扩展策略
Docker容器的动态资源调整和扩展策略一、动态资源调整策略在使用Docker容器部署应用程序时，动态资源调整是一个重要的因素，它可以帮助我们实现弹性扩展和优化资源利用率。
本文将探讨Docker容器的动态资源调整策略，以满足应用程序的需求。
1. 垂直扩展垂直扩展是指增加单个容器的资源配额，例如CPU和内存。
这种扩展策略通常适用于单个容器需要更多资源的情况。
通过使用Docker提供的命令，可以实现对容器资源的动态调整。
例如，使用`docker update`命令可以增加或减少容器的CPU和内存分配。
通过监控容器的资源使用情况，可以根据需求进行调整，提高容器的性能和稳定性。
2. 水平扩展水平扩展是指增加容器的数量，以实现更高的吞吐量和负载均衡。
这种扩展策略常用于应对高并发流量和容器故障的情况。
使用容器编排工具如Docker Swarm 或Kubernetes，可以轻松地增加或减少容器的数量。
这些工具提供了自动化部署和伸缩的功能，可以根据应用程序的负载情况自动调整容器的数量。
通过水平扩展，可以实现更高的可用性和容错性。
3. 自动化伸缩为了更加智能地调整容器资源，可以使用自动化伸缩策略。
自动化伸缩可以根据事先设定的指标和算法来自动调整容器资源，以满足应用程序的需求。
常见的指标包括CPU利用率、内存使用率和请求响应时间等。
通过监控这些指标，并根据设定的规则进行判断和调整，可以实现容器资源的动态自适应。
例如，当CPU利用率超过一定阈值时，自动增加容器数量；当内存使用率低于一定阈值时，自动减少容器数量。
二、扩展策略的实施在实施Docker容器的动态资源调整和扩展策略时，需要注意以下几个方面。
1. 监控和度量为了实现容器资源的动态调整，需要对容器进行监控和度量。
可以使用监控工具如Prometheus、Grafana或ELK Stack等来收集和展示容器的性能指标。
通过实时监控，可以了解容器的资源使用情况，及时进行调整。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
小区动态PDTCH扩容标准――为了提高无线利用率一、前言提高无线利用率现主要有三个方法：一、修改公式或OMCR统计值；二、修改参数，如delay 和T3192, 这个的缺点是可能会影响GPES/EDGE系统性能，需要谨慎并修改后观察；三、扩容动态PDTCH，满足在现有设备资源、统计公式的基础上，通过增加了实际业务量，从而提高了无线利用率，这是各方最容易接受的方法；为提高无线利用率扩容动态PDTCH和平时我们优化中为提高系统性能扩容PDTCH的目的不一样，标准也略有不同，优化中的原则是系统性能达标就不用扩容，提高无线利用率的原则是在资源容许的情况下只要能有效增加实际话务量，就可以扩。
二、扩容动态PDTCH原则扩容动态PDTCH，，不能盲目增加，需在PCU 的PRP板、GDS、小区的Abis接口、BSC端口资源满足的情况下，根据实际语音、数据话务统计忙、闲有目的的调整，为了最大化利用现有资源扩容，具体调整原则是：1．对于PDTCH忙而TCH不忙的小区，修改部分TCH为动态PDTCH的方法解决；2．对小区PDTCH和TCH都拥塞的小区，通过减少部分静态PDTCH和TCH，增加为动态PDTCH的方法解决，在某一业务忙时使用动态PDTCH，避免拥塞；3．对数据流量较高的小区，通过修改部分TCH为动态PDTCH的方法解决；4．对于TCH忙而PDTCH不忙的小区，修改部分静态PDTCH为动态PDTCH的方法解决；5．为了提高网络流量，满足更多GPRS用户的使用，在开EDGE的小区尽量保持_cell_data,0参数为60，使更多的GPRS用户可以使用EDGE信道（CQT及VIP点可以除外）；6．增加PDTCH数，要求PCU的PRP板和GDS接口时隙满足配置要求，BSC 下小区的PDTCH数不能超过PRP板和GDS的支持能力，如果必须增加动态PDTCH，而PRP板和GDS容量限制，请在PRP板和GDS扩容后再增加PDTCH；三、扩容标准的相关统计推荐采用“TBF复用度”作为主要标准，其它标准为次要标准，或用SPSS等工具对下面几个统计项聚类，再对几个统计项都显示需扩的小区扩容；1．TBF复用度无线利用率的提升，扩容动态PDTCH现主要参考统计是“TBF复用度”。
TBF复用度＝AVG_SIMUL_DL_TBFS_MEAN / DL_BUSY_PDTCH_MEANAVG_SIMUL_DL_TBFS_MEAN：同时传输的TBF平均个数。
现MOTO设备一个PDTCH可以最大支持4个手机同时使用，就是4个TBF。
AVG_SIMUL_DL_TBFS_MEAN / DL_BUSY_PDTCH_MEAN：代表小区的TBF交织深度，或每个PDTCH的平均TBF个数。
这个值的范围从0.25（低交织）到4（高交织），由于统计时间的原因，很少的数据在这个范围外，当此比例低时，每个PD上TBF少，或者说每个TBF单独占用的PD多，造成的利用率高；当比例高时，说明每个PD上TBF很多，或者说非常拥挤，交织很厉害，每个TBF连一个PD都不能完全占用。
等于0.25时，表示1个手机占用4个PDTCH，等于0.5时，表示1个手机占用2个PDTCH，等于1时，表示1个手机占用1个PDTCH，等于2时，表示2个手机占用1个PDTCH，等于4时，表示4个手机占用1个PDTCH，此比例用于衡量是否增加小区PD个数或增加多少。
比如当比例大时，说明交织加剧，可适当增加PD缓解交织占用。
当比例很小时，说明每个TBF 的资源还可以，增加PD后效果不会很明显，因为TBF业务本来也不太多。
具体比例是多少时增加，多少时减少，需我们实际使用中看增加或减少是否有作用，可根据实际情况自行制定，建议大于0.5时即可以增加。
2．PDTCH拥塞率●原始统计GPRS_CELL_CONGESTION统计是以小区中PDCH上承载的TBF来衡量的，GPRS_CELL_CONGESTION = 100% 代表1个PDTCH被4个TBF占用时间；GPRS_CELL_CONGESTION = 25% 代表1个TBF占用1个PDTCH时间；每隔6秒，在使用的GPRS时隙资源落在那个BIN 范围,系统就会在该BIN值的统计项中记录1次，高的拥塞率表明一个PDTCH被多个手机占用，直接影响手机的FTP下载速率等。
Name Bin # RangeGPRS_CELL_CONGESTION_25 0 >= 0%, < 25%GPRS_CELL_CONGESTION_30 1 >= 25%, < 30%GPRS_CELL_CONGESTION_35 2 >= 30%, < 35%GPRS_CELL_CONGESTION_40 3 >= 35%, < 40%GPRS_CELL_CONGESTION_45 4 >= 40%, < 45%GPRS_CELL_CONGESTION_50 5 >= 45%, < 50%GPRS_CELL_CONGESTION_55 6 >= 50%, < 55%GPRS_CELL_CONGESTION_60 7 >= 55%, < 60%GPRS_CELL_CONGESTION_65 8 >= 60%, < 65%GPRS_CELL_CONGESTION_70 9 >= 65%, < 70%GPRS_CELL_CONGESTION_75 10 >= 70%, < 75%GPRS_CELL_CONGESTION_80 11 >= 75%, < 80%GPRS_CELL_CONGESTION_85 12 >= 80%, < 85%GPRS_CELL_CONGESTION_90 13 >= 85%, < 90%GPRS_CELL_CONGESTION_95 14 >= 90%, < 95%GPRS_CELL_CONGESTION_100 15 >= 95%, <= 100%●公式将拥塞大于25%的时间相加，公式如下：CELL_CONGESTION_TIME =(GPRS_CELL_CONGESTION_30+GPRS_CELL_CONGESTION_35 + GPRS_CELL_CONGESTION_40+GPRS_CELL_CONGESTION_45 + GPRS_CELL_CONGESTION_50+GPRS_CELL_CONGESTION_55 + GPRS_CELL_CONGESTION_60+GPRS_CELL_CONGESTION_65 + GPRS_CELL_CONGESTION_70+GPRS_CELL_CONGESTION_75 + GPRS_CELL_CONGESTION_80+GPRS_CELL_CONGESTION_85 + GPRS_CELL_CONGESTION_90+GPRS_CELL_CONGESTION_95 + GPRS_CELL_CONGESTION_100)*6关注门限值拥塞时间超过1800～2700，建议扩容，或再统计拥塞大于55%的时间来参考，可根据实际情况自行制定。
3．PDTCH自身利用率反映统计时段内数据业务信道占用率，包括GPRS/EGPRS。
dl/ul_busy_pdtch_mean：上/下行分组业务平均占用的PDTCH数res_gprs_pdch+sw_gprs_pdch: 系统配置的PDTCH静动态数。
PDTCH自身利用率=忙时数据等效话务量*100%/（静态PDTCH+动态PDTCH=(dl_busy_pdtch_mean+ul_busy_pdtch_mean)*100%/(res_gprs_pdch +sw_gprs_pdch)需根据网络资源情况，一般建议当PDTCH自身信道利用率较高时,必须扩容PDTCH信道，该处的利用率和无线利用率分母有区别，无线利用率扩容动态PDTCH后分母基本不变，分子增加，故无线利用率总体增加。
4．小区数据业务流量参考小区全天GPRS/EDGE总流量。
如某小区全天总流量较大，表示该小区全天上网人数较多，数据业务需求较大，考虑到业务量为无线利用率的分子，我们希望能尽量提高分子的数值，根据实际情况适当增加扩容sw pdtch数量。
5．满足手机配置需求由于现网多是4＋2的手机（就是最大下行占4个时隙，上行占2个时隙，同时最多可占用5个时隙），对于res+sw pdtch数量不足4个TS的小区，尽量调整后静态+动态 PDTCH大于等于4，以保证1个上网用户可以提供4个下行信道话务量。
四、扩容动态PDTCH注意事项1、各统计项的门限值没有具体的门限值，这不是优化，只是对现有设备的最大化使用，各地原始网络现状不同，目的是在现有网络资源下尽可能的扩动态PDTCH，同时观察是否有效果，对没有效果的小区，可以不扩。
2、PRP板支持PDTCH数门限值每个PCU最多可以配置9块PRP板，每块PRP板支持120个PDTCH信道，但是只有30个PDTCH才能同时进行数据传输，故BSC配置的PDTCH总数应该小于PCU支持的总信道数，还要留些余量为可能的调整；3、PCU的GDS支持的PDTCH数门限值每块PRP板最多可以支持两个PMC，每个PMC可以接2个GDS，即每块PRP板最多支持4个GDS。
每条GDS可以支持124个16Kbps的PDTCH、或62个32Kbps的PDTCH、或31个64Kbps的PDTCH；在无法继续扩容GDS的情况下，必须保留足够后期扩容的GDS EDGE信道数；由于16k/32k/64k的信道混合配置后，GDS 和 PMC NIB的利用率几乎不可能达到100%，按现网情况需预留一定的扩容空间；4、PCU的PRP板负荷超过保证系统性能的经验值在有多块PRP板的系统中,负荷一般会在各板子间均衡一下，PRP_Load 超过100将发生Interleaving,此时多个MS合用一个PDTCH,存在排队，如忙时部分PRP单板最大负荷常远超过100，忙时部分PRP单板平均负荷超过70，则要考虑对该PCU的PRP单板进行扩容或者对该PCU的各个PRP单板进行资源调整。
5、PCU的PRP板CPU利用率超过安全的经验值PRP单板的cpu_usage_max忙时可能出现100%的情况，但只要cpu_usage_mean不超过40%，对系统性能不会产生很大影响。
如果PRP单板的cpu_usage_mean超过40%，则要考虑对该PCU的PRP 单板进行扩容或者对该PCU的各个PRP单板进行资源调整。