割接后系统性能监控讲解
服务器性能监控工具和技术介绍

服务器性能监控工具和技术介绍服务器性能监控是保障系统正常运行和优化系统性能的关键任务之一。
随着互联网的迅猛发展,服务器负载日益增加,因此合理选择和使用性能监控工具和技术对于确保服务器的稳定性和高效性显得尤为重要。
本文将介绍几种常见的服务器性能监控工具和技术,帮助管理员选择适合自己服务器的方案。
一、性能监控的重要性服务器是企业的核心资产之一,维持服务器的正常运行对于业务的平稳进行至关重要。
性能监控可以及时发现服务器的异常情况,如负载过高、内存泄露、硬盘故障等,能够提前预警并采取相应措施,以避免系统崩溃或数据丢失。
同时,性能监控也可以发现服务器的瓶颈和疲劳点,进而优化服务器的配置和性能,提升系统的稳定性和用户体验。
二、服务器性能监控工具1. ZabbixZabbix是一款开源免费的企业级的分布式监控解决方案,支持对服务器、网络设备和应用程序的性能进行实时监控和管理。
Zabbix提供了丰富的监控功能,包括CPU利用率、内存使用率、网络流量等等。
同时,Zabbix还可以通过邮件、短信、微信等方式发送告警,提醒管理员及时处理问题。
2. NagiosNagios是一款广泛应用的开源监控工具,以其强大的扩展性和灵活性而闻名。
Nagios通过不同的插件监控服务器的各项指标,如CPU负载、内存使用、网络连接等。
Nagios还支持自定义特定的监控项,并可以通过邮件和短信等方式进行告警通知。
3. PrometheusPrometheus是一种开源的系统监控和报警工具集。
它通过收集和存储时间序列数据进行监控,可以灵活地配置和扩展监控指标,如CPU利用率、内存使用率、磁盘IO等。
Prometheus支持丰富的可视化和报表功能,并提供强大的查询语言和告警机制。
三、服务器性能监控技术1. SNMP(Simple Network Management Protocol)SNMP是一种用于网络管理的标准协议,广泛应用于服务器性能监控。
应用系统割接概述

应用系统割接概述应用系统割接是一项重要的变更管理活动,旨在在旧的应用系统停止服务的同时,将新应用系统成功地接管并投入使用。
这项工作通常涉及多个部门和团队,以确保业务连续性和系统稳定性。
一、割接背景随着业务的发展和技术的进步,企业需要不断更新和升级其应用系统以应对日益复杂的竞争环境。
旧的应用系统可能已达到其性能和功能的极限,无法满足新的业务需求。
在这种情况下,需要进行应用系统的割接,以引入新的系统来提升整体性能和功能。
二、割接目标1. 确保业务连续性:通过平滑的割接过程,确保业务在旧系统停用和新系统启用期间不会中断,降低业务风险。
2. 提高系统稳定性:新系统应具备更高的稳定性和可靠性,以减少故障率,提高用户体验。
3. 提升性能和功能:新系统应能够提供更好的性能和功能,满足业务需求并提升市场竞争力。
三、割接流程1. 制定割接计划:明确割接的目标、时间、步骤和责任人。
2. 旧系统停用准备:确保旧系统在割接前已完成维护和更新,确保数据备份和恢复的可行性。
3. 新系统部署和测试:按照计划部署新系统,并进行充分的测试以确保其稳定性和功能。
4. 割接实施:在合适的时间,停止旧系统的服务,启用新系统。
5. 割接后评估:评估割接的效果,收集反馈并根据反馈结果进行调整和优化。
四、风险控制1. 确保数据备份的可靠性和可用性,以应对数据丢失的风险。
2. 监控新系统的运行状态,及时发现并处理潜在的问题。
3. 制定应急预案,以应对可能出现的突发情况。
4. 定期评估割接的效果,并根据评估结果进行调整和优化。
五、团队协作与沟通1. 跨部门协作:确保不同部门之间的协作和沟通,共同推进割接工作。
2. 团队沟通:建立有效的沟通机制,确保团队成员之间的信息畅通,以便及时解决问题。
3. 定期会议:定期召开会议,讨论割接的进展、问题和解决方案,确保工作按计划进行。
六、总结应用系统割接是一项复杂而重要的工作,需要充分准备、细致规划、有效沟通和协作。
系统割接方案

系统割接方案一、引言在信息技术的发展和应用过程中,为了升级现有的系统并引入新的系统,系统割接是一项必须进行的重要任务。
本文将提出一个系统割接方案,以确保顺利的系统迁移和平稳的运行。
二、割接目标和需求分析在制定系统割接方案之前,需要明确割接的目标和需求。
这包括以下几个方面:1. 数据的完整性:在割接过程中,要确保数据能够完整迁移并保持数据的一致性。
2. 业务的连续性:割接过程中不能对业务造成影响,需要确保业务能够连续进行。
3. 安全性:在割接过程中,要保障系统的安全,避免任何安全风险。
4. 时间控制:割接的时间应该合理控制,以避免对业务和用户造成长时间的中断。
5. 风险评估:需要进行全面的风险评估,确定可能带来的风险并采取相应的措施来降低风险。
三、割接方案设计基于需求分析,我们制定了以下的系统割接方案:1. 系统备份:在割接之前,对当前系统进行全面备份,以便出现问题时能够及时恢复到原有状态。
2. 测试环境搭建:搭建一个与当前系统相同的测试环境,在此环境中进行割接方案的测试和验证。
3. 逐步迁移:将当前系统的部分业务逐步迁移到新系统中,确保新系统能够正常运行,并逐步进行全面迁移。
4. 监控和调整:在割接过程中,通过监控系统的运行情况,及时发现和解决问题,并对割接方案根据实际情况进行调整和优化。
5. 回滚计划:针对可能出现的问题,制定相应的回滚计划,以确保在割接失败时能够快速恢复到原有系统状态。
6. 用户培训:在割接完成后,对用户进行培训,确保用户能够顺利过渡到新系统,并了解新系统的功能和使用方法。
四、割接执行和风险控制在实施割接方案时,需要注意以下几个关键步骤和风险控制措施:1. 事前沟通:与相关部门和用户进行充分的沟通和准备工作,明确割接的时间和过程,并取得他们的支持和配合。
2. 割接时间选择:选择一个业务相对较少的时间段进行割接,以减少对业务的影响。
3. 监控和回滚:在割接过程中,及时监控割接的情况,发现问题时及时采取措施,并根据回滚计划进行回滚操作。
性能测试中的监控和分析

性能测试中的监控和分析性能测试是一种评估系统、应用程序或设备在不同负载条件下的性能和稳定性的方法。
在进行性能测试时,一个重要的环节就是监控和分析。
监控和分析可以帮助测试团队了解系统的资源消耗、性能瓶颈和潜在问题,从而提供改进建议和决策支持。
本文将介绍在性能测试中监控和分析的方法和工具。
一、监控1. 监控的目的性能测试的监控是为了实时监测系统各项指标,包括CPU利用率、内存使用率、网络传输速率等,以了解系统当前的状态和资源消耗情况。
2. 监控的方法(1)服务器监控:通过在被测试系统所在的服务器上安装监控软件,获取服务器的性能数据。
常用的服务器监控工具有Zabbix、Nagios等。
(2)网络监控:通过监测网络传输情况,包括网络带宽、延迟、丢包率等指标,来评估系统的网络性能。
常用的网络监控工具有Wireshark、Cacti等。
(3)应用程序监控:通过在被测试系统中集成监控功能,获取应用程序的性能数据。
常用的应用程序监控工具有AppDynamics、New Relic等。
二、分析1. 分析的目的在性能测试完成后,测试团队需要通过对监控数据的分析,来发现系统中的性能问题和瓶颈,以及提供解决方案和优化建议。
2. 分析的方法(1)指标分析:对监控数据进行统计和分析,比如CPU利用率是否过高,内存是否泄露等。
通过对这些指标的分析,可以了解系统的性能状况。
(2)瓶颈分析:通过分析系统的性能瓶颈,找出导致系统性能下降的原因。
比如,网络带宽是否不足,数据库负载是否过高等。
(3)异常分析:通过对异常事件和错误日志的分析,识别系统中的异常行为和潜在问题。
比如,内存溢出、死锁等。
三、工具1. 性能测试工具(1)LoadRunner:功能强大的性能测试工具,支持多种协议和技术。
(2)JMeter:开源的性能测试工具,支持多种协议和技术,并提供丰富的插件。
2. 监控工具(1)Zabbix:功能全面的服务器监控工具,支持多种操作系统和数据库。
系统割接实施方案

系统割接实施方案一、背景介绍。
随着公司业务的不断拓展,原有的系统架构已经不能满足当前业务需求,为了提升系统的稳定性和性能,公司决定进行系统割接。
系统割接是指将原有系统的数据和功能迁移到新系统中,并确保在迁移过程中不影响业务的正常运行。
为了保证系统割接的顺利进行,制定了如下实施方案。
二、实施目标。
1. 实现系统的平稳割接,确保业务的连续性和稳定性;2. 最大限度地减少对业务的影响,确保用户体验不受影响;3. 确保数据的完整性和安全性,避免数据丢失或泄露的风险;4. 在规定的时间内完成系统割接,保证项目的进度和质量。
三、实施步骤。
1. 系统割接前的准备工作。
在进行系统割接前,需要做好充分的准备工作,包括但不限于:制定系统割接计划,明确割接的时间节点和具体流程;对原系统进行全面的数据备份,确保数据的完整性和安全性;对新系统进行充分的测试,确保新系统的稳定性和性能满足业务需求;制定系统割接的风险评估和对策,针对可能出现的问题提前做好准备。
2. 系统割接过程中的实施。
在系统割接的过程中,需要按照以下步骤进行实施:停止原系统的业务操作,并进行最后一次数据备份;将备份数据迁移至新系统中,并进行数据验证和同步;对新系统进行功能和性能测试,确保系统的正常运行;切换业务流量至新系统,监控系统运行情况,及时处理可能出现的问题。
3. 系统割接后的监控和优化。
系统割接完成后,需要进行系统的监控和优化工作,包括但不限于:监控新系统的运行情况,及时发现和解决可能出现的问题;对系统进行性能优化,提升系统的稳定性和性能;对系统割接过程进行总结和反思,为后续类似项目积累经验。
四、实施保障措施。
1. 成立系统割接项目组,明确各成员的职责和任务;2. 制定系统割接的详细计划和流程,确保实施的有序进行;3. 做好系统割接的风险评估和对策,提前做好应对措施;4. 针对系统割接过程中可能出现的问题,制定相应的应急预案;5. 加强与业务部门的沟通和协调,确保业务的连续性和稳定性。
割接实施方案

1. 前言割接是指在现有系统运行中进行系统的迁移、集成或升级等操作。
割接实施方案是指通过详细的计划和步骤,确保割接操作能够顺利进行,同时最大限度减少对现有系统运行的影响。
本文档旨在提供一个规范的割接实施方案,以确保割接工作的顺利进行。
2. 割接目标本次割接的主要目标是实现系统的升级,包括软件版本的更新、功能的增加等。
通过本次割接,我们希望保证系统的稳定性,并能够提供更好的用户体验。
3. 割接范围本次割接的范围主要包括以下几个方面:•系统软件升级:更新系统的操作系统、数据库等软件版本。
•功能增加:根据用户需求,增加系统的新功能和模块。
•数据迁移:将原有系统的数据无损地迁移到新系统中。
4. 割接计划4.1 前期准备在正式进行割接之前,需要进行一些前期准备工作,包括以下几个方面:•确认割接的时间窗口:选择最佳的时间段进行割接,以最小化对系统的影响。
•制定详细的割接计划:明确每个步骤的时间和责任人,并进行有效的沟通和协调。
•评估割接风险:针对可能出现的问题和风险进行评估,并制定相应的应对措施。
4.2 割接步骤根据前期准备的工作,制定具体的割接步骤如下:1.割接前测试:在正式割接之前,进行一次全面的测试,确保新系统的功能和性能达到预期。
2.割接准备:备份原有系统的数据,并进行必要的准备工作,如关闭相关服务和通知相关人员。
3.割接操作:按照计划进行割接操作,主要包括软件升级、功能增加和数据迁移等。
4.系统验证:对新系统进行验证,确保割接操作的正确性和稳定性。
5.回滚准备:为了应对可能出现的问题,制定详细的回滚计划,并进行相应的准备工作。
6.系统切换:将新系统切换为正式运行环境,并观察系统的运行状态。
7.后期优化:在割接完成后,对系统进行优化和调整,以进一步提高系统的性能和稳定性。
4.3 割接风险和应对措施在割接过程中可能存在以下风险:•数据丢失或损坏:通过备份数据和可靠的数据迁移操作,最大限度减少数据丢失的风险。
割接后系统性能监控

割接后系统性能监控本文分析系统性能是中国移动公司的指标计算公式为主线,从呼叫流程开始针对相关的统计项作重点分析说明,从而找到解决问题的各种方法.一.无线接通率:无线接通率=(1-SDCCH_BLK_RATE)×(1-TCH_BLK_RATE)×100% SDCCH_BLK_RATE= ALLOC_SDCCH_FAIL/ALLOC_SDCCH(+ALLOC_SDCCH_FAIL) TCH_BLK_RATE =MA_CMD_TO_MS_BLK/MA_REQ_FROM_MSC.提高无线接通率的办法是降低SDCCH_BLK_RATE 与TCH_BLK_RATE.1. SDCCH_BLK_RATE与TCH_BLK_RATE手机通过RACH向基站发起服务请求,基站从AGCH上给手机指定SDCCH,手机占上SDCCH,向网络发出服务连接请求。
这就是SDCCH的占用过程.MS 传送一个信道请求消息(智能信息,建立原因值,随机参考),打包在接入突发序列中,信道编码器对其解码.正确解码后被送到RSS-L1OK_ACC_PROC_SUC_RACH; ACCESS_PER_RACH 增值.收到信道请求消息,RSS ABIS 验证信道建立原因值有效性,无效加1,有效就格式化消息送到RRSM.一旦RRSM 接收到信道需求的消息,将试图把MS 建立在一个专用信道上, CHAN_REQ_CAUSE_ATMPT 作出标记.成功分配SDCCH 后,CRM 中的ALLOC_SDCCH 增值.每当CRM 试图分配一个空闲的SDCCH,却由于SDCCH 忙而禁止时,ALLOC_SDCCH_FAIL 值增加,当由于资源短缺而拒绝SDCCH 的切换时,在目标小区中,也会增加. (在没有SDCCH 切换时,alloc_sdcch_fail = chan_req_ms_blk )当收到来自CRM 的立即分配拒绝消息时,CHAN_REQ_MS_BLKD 递增. RR_T3101定时期满没有收到建立指示,CHAN_REQ_MS_FALL 做标记. 若存在较大的alloc_sdcch_fail ,说明SDCCH 拥塞严重,常用的解决方法是:增加SDCCH 数目,特别是铁路高速公路旁边的基站. 较大干扰会造成SDCCH,TCH 拥塞,故一定要排除干扰. 减小该cell 的C1(增大rxlev_access_min ). 采用动态分配SDCCH 的算法. 2TCH 拥塞:当SDCCH上的鉴权,加密和呼叫建立完成之后,MSC将开始分配进程为手机分配TCH。
割接工作实施方案

割接工作实施方案割接工作实施方案一、项目背景及目标割接是指在信息系统维护、升级或更换时,将旧系统从生产环境中剥离并替换为新系统的过程。
本方案旨在规范割接工作流程,确保割接过程顺利完成,系统能够在最短的时间内恢复正常运行,并保证数据完整性和业务连续性。
二、实施方案1. 割接前准备- 确定割接时间和地点,避免对业务产生不可预测的影响。
- 制定详细的工作计划,包括割接前的测试、数据备份、割接过程安排等。
- 提前通知相关人员,并确保他们了解割接计划和可能的影响。
- 确保有足够的备用设备和工具,以应对可能的紧急情况。
2. 割接过程控制- 按照工作计划,进行备份数据的操作,确保数据的完整性和安全性。
- 对新系统进行测试和验证,确保其能够正常运行。
- 在割接过程中,严格按照操作规程进行操作,避免因操作不当导致的故障或数据丢失。
- 给予割接过程充分的时间和资源,确保每个步骤都得到充分的验证和确认。
3. 割接后恢复和测试- 在割接完成后,对系统进行全面的功能测试,验证新系统是否符合预期要求。
- 对割接过程中的问题进行总结和记录,以便今后的改进和学习。
- 提供必要的培训和支持,确保用户能够熟练操作新系统。
- 监控系统运行情况,及时排除可能存在的问题,并进行数据验证。
三、风险控制与应急处理1. 事前风险评估- 在制定割接方案的初期,对可能出现的风险进行评估和预测,制定相应的应对措施。
- 确保备用设备和工具的可用性,以备不时之需。
- 提前与相关供应商沟通,确保能够及时获得支持和帮助。
2. 暂时恢复计划- 在割接过程中,如发现严重问题无法立即解决,根据预案暂时恢复到原系统,保障业务连续运行。
- 在暂时恢复的过程中,及时调整割接计划,修复问题后再次进行割接。
3. 问题处理与事后总结- 发现问题后,及时与相关人员沟通,迅速制定解决方案。
- 对割接过程中的问题进行总结和记录,以便今后的改进和学习。
- 提出针对性的问题解决方案,并对相关人员进行培训,以提高整体的工作水平。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
割接后系统性能监控本文分析系统性能是中国移动公司的指标计算公式为主线,从呼叫流程开始针对相关的统计项作重点分析说明,从而找到解决问题的各种方法.一.无线接通率:无线接通率=(1-SDCCH_BLK_RATE)×(1-TCH_BLK_RATE)×100% SDCCH_BLK_RATE= ALLOC_SDCCH_FAIL/ALLOC_SDCCH(+ALLOC_SDCCH_FAIL) TCH_BLK_RATE =MA_CMD_TO_MS_BLK/MA_REQ_FROM_MSC.提高无线接通率的办法是降低SDCCH_BLK_RATE 与TCH_BLK_RATE.1. SDCCH_BLK_RATE与TCH_BLK_RATE手机通过RACH向基站发起服务请求,基站从AGCH上给手机指定SDCCH,手机占上SDCCH,向网络发出服务连接请求。
这就是SDCCH的占用过程.MS 传送一个信道请求消息(智能信息,建立原因值,随机参考),打包在接入突发序列中,信道编码器对其解码.正确解码后被送到RSS-L1OK_ACC_PROC_SUC_RACH; ACCESS_PER_RACH 增值.收到信道请求消息,RSS ABIS 验证信道建立原因值有效性,无效加1,有效就格式化消息送到RRSM.一旦RRSM 接收到信道需求的消息,将试图把MS 建立在一个专用信道上, CHAN_REQ_CAUSE_ATMPT 作出标记.成功分配SDCCH 后,CRM 中的ALLOC_SDCCH 增值.每当CRM 试图分配一个空闲的SDCCH,却由于SDCCH 忙而禁止时,ALLOC_SDCCH_FAIL 值增加,当由于资源短缺而拒绝SDCCH 的切换时,在目标小区中,也会增加. (在没有SDCCH 切换时,alloc_sdcch_fail = chan_req_ms_blk )当收到来自CRM 的立即分配拒绝消息时,CHAN_REQ_MS_BLKD 递增. RR_T3101定时期满没有收到建立指示,CHAN_REQ_MS_FALL 做标记. 若存在较大的alloc_sdcch_fail ,说明SDCCH 拥塞严重,常用的解决方法是:增加SDCCH 数目,特别是铁路高速公路旁边的基站. 较大干扰会造成SDCCH,TCH 拥塞,故一定要排除干扰. 减小该cell 的C1(增大rxlev_access_min ). 采用动态分配SDCCH 的算法. 2TCH 拥塞:CC CREFCR:conn_req_t o_msc Conn_refused当SDCCH上的鉴权,加密和呼叫建立完成之后,MSC将开始分配进程为手机分配TCH。
交换机发分配需求消息给SSM,消息中带有交换机指定的CIC。
BSC的SSM收到分配需求后记为ma_req_from_msc.BSC的CRM随即分配TCH,如果此时无可用TCH,则记ma_cmd_to_ ms_blk,同时记alloc_tch_fail。
注意:alloc_tch_fail还会在切换时记数。
正常情况下,TCH的拥塞应该为0,如果出现拥塞,则主要的解决方法有:打开该小区往其它小区的拥塞切换。
增大天线俯仰角,降低功率,减小话务量的吸收(尽量不采用).打开该小区的动态配置功能。
使该小区往相邻小区的切换更容易。
增加TCH.是否有断站.检查是否是外部干扰引起的.提高无线接通率的办法是降低SDCCH_BLK_RATE 与TCH_BLK_RATE.只要把握尽量减小SDCCH,TCH的拥塞,无线接通率很容易达到99.7%(满分).二.切换成功率:(out_intra_bss_ho_suc+ out_inter_bss_ho_suc+ in_intra_bss_ho_suc+in_inter_bss_ho_suc)/out_intra_bss_ho_atmpt+out_inter_bss_ho_atmpt+in_intra_bss_ho_suc+in_intra_bss_ho_lostms+in_intra_bss_ho_return+in_intra_bss_ho_cleared+ho_req_ msc_okINTRA_BSS_HO_SUC+INTER_BSS_HO_SUC/BSS_HO_ATMP+由于INTRA_CELL_HO 不在考核范围内,故对其不作分析.当HDPC(IN RSS) 向RRSM发送切换认可消息(含原因&合格的相邻小区)后,RSS将启动切换程序.RRSM把消息作为切换认可受到消息送给SSM.,BSC决定何种切换1.BSS内切换:成功切换:每次SSM决定进行BSS内切换,OUT_INTRA_BSS_HO_REQ就进行标记.SSM 一旦收到由目标RRSM送来的切换分配消息中规定的目标资源后,通过发送开始切换消息来启动MS从源小区向目标小区的切换.发送该消息后,OUT_INTRA_BSS_HO_ATMPT对于源小区递增.源 RRSM收到开始切换消息就要格式化通过发往MS的空间接口切换命令(在FACCH上发送,并向MS提供目标TCH的详细情况).MS将改变其空间接口特性,试图在L1与目标RSS连接起来,然后L2与目标RSS连接.若不同步,会在试图建立L2之前发送4个连续的L1接入突发序列.MS在与RSS连接后,会发送一个L3切换完成消息,此消息作为切换成功消息传至SSM,SSM收到此消息后,格式化并向MSC发送切换完成的消息.IN_INTRA_BSS_HO_SUC&OUT_INTRA_BSS_HOSUC递增.切换失败:当SSM把开始切换消息发给源RRSM时,T3103开始运转,在成功的情况下SSM会在期满前收到从目标RRSM切换成功的消息.MS一收到开始切换命令就改变其本身特性,试图与目标RSS建立L1链路在异步的情况下,MS开启T3124,期满未收到物理消息或在切换完成消息发送前有底层故障,那么MS终止使用新的TCH,返回旧的TCH,MS发出切换失败消息,源RRSM告知SSMT,3103停,源小区OUT_INTRA_BSS_HO_RETURN与目标小区IN_INTRA_BSS_HO_RETURN递增.OUT_INTRA_BSS_HO_LOSTMS为在一个切换尝试过程中不能捕获新的源小区的信道而导致MS不能返回原始信道的次数,即为掉话.IN_INTRA_BSS_HO_CLR为BSS内部切换过程中呼叫被清除的次数.BBS 间切换:从公式上分析,OUT_INTRA_BSS_HO_SUC与 IN_INTRA_BSS_HO_SUC是相等的(公式不合理),在分母中,IN_INTRA_BSS_HO_CLEARED 为呼叫在进行BSS 内切换过程中被清除也就是正常挂机的次数,本统计项不能人为控制.其中比较重要的因素是IN_INTRA_BSS_HO_RETURN与IN_INTRA_BSS_HO_LOSTMS. • IN_INTRA_BSS_HO_LOSTMS:切换过程中不能捕获新的信道目标小区释放信道又不能返回原信道的掉话次数.由HO_COMPLETE定时器控制,设置要合理(30000).•IN_INTRA_BSS_HO_RETURN:回到源小区TCH后,MS发出失败消息给RRSM,RRSM再发往SSM, RR_T3103终止.该统计项递增.影响成功切换率的方面很多,可通过以下几方面进行检查:参数设置合理:部分参数的检查可以从CME文件获得. 切换优先级为1.Ul_quality2.UL_interferemce3.DL_quality4.DL_quality5.UL_level6.DL_level7.distance 8 PBGT.干扰:系统内干扰与外部干扰.小区各TCU/CTU功率不平衡,有BCCH的CTU发射功率较大,但分配TCH的CTU发射功率小,导致MS与目标RSS接入不成功,切换失败.MCUF/MCU/CTU本身硬件有问题.时钟失锁.天线朝向不对或接错.不同的扇区交叉错接或同一小区的两根天线朝向偏差较大.天线VSWR大.越区覆盖造成的切换失败,避免越区.NEIGHBOR合理.不能漏加应有的也不能加上无关的NEIGHBOR.弱覆盖.三.掉话率:OMC-R公式:RF_LOSS_TCH+OUT_INTRA_BSS_HO_LOSTMS+ OUT_INTER_BSS_HO_CLEARED+INTRA_CELL_HO_LOSTMS/TOTAL_CALLS+CONGEST_ ASSIGN_HO_SUC掉话率是系统性能中非常重要的一项指标, 就前面提到的呼叫流程对各个统计指标逐一分析:在一周中对前三项掉话指标作了统计,在总掉话次数所占比例分别是:64.4%;26.6%;9.0%.由此可见RF_LOSS_TCH所占比例最大.BSS内的切换掉话其次,BSS之间的切换掉话最少.因此降低RS_LOSS_TCH是我们的重点之重.由于INTRA_CELL_HO_LOSTMS不在考核范围内,故可将此统计项放开, 减小其他统计的掉话次数.通过参数进行修改调整:在切换优先级中上行链路干扰2级,Interfer_ho_allowed(0:disable;1=enable) 一部分小区为 0.打开Intra_cell_ho_allowed(0:不由BSS执行,由MSC控制;1: 由BSS执行;2:不允许)=2 . 应改为1.响应的参数(U_RXLEV_DL_IH=0;U_RXLEV_UL_IH=0; HOP_COUNT=2;HOP_COUNT_TIMER=20).RF LOSS:前面提到的流程中, 在专用模式下,MS在每个SACCH复桢(480MS)都向BSS传送一次测量报告.若一系列的测量报告没到达RSS,表明与MS的上行链路已经丢失,计数器LINK_FAIL (在HDPC中)递减为零,这时,RSS将宣布链路失败并发送一条错误指示消息通知RRSM,RRSM将指示RSS禁止TCH,并通知RSS链路失败,发布无线信道消息来释放信道.当RRSM接受到含有为TCH的错误消息,则RF_LOSS_TCH记数,若为SDCCH的错误消息,RF_LOSS_SD记数.OUT_INTRA_BSS_HO_LOSTMS为在一个切换尝试过程中不能捕获新的源小区的信道而导致MS不能返回原始信道的次数,即为掉话.OUT_INTER_BSS_HO_CLEARED呼叫在进行BSS间切换的过程中被清除时记数,属正常挂机,不予考虑.造成掉话的有以下几方面:上行损耗大接收通路有问题造成RF_LOSS_TCH高,可通过PATH_BALANCE 查看 (后面重点介绍), 接收通路包括天馈线,SURF/IADU/MPT/DLNB/DDF/DCF 等.系统内干扰与外部干扰造成上行链路测量报告丢失,使RF_LOSS_TCH高.可通过I_O_I查看(后面重点介绍).CTU/TCU硬件及补偿值问题.造成RSS无法接收到上行链路测量报告.若PATH_BALANCE&I_O_I均正常,RF_LOSS_TCH高,更换频点无改善.可与一个无掉话的RTF与它倒换,原来正常的RTF掉话高,说明MCUF/MCU有问题.更换即可.越区覆盖.造成干扰引起掉话.弱覆盖造成掉话长期BER高来检查.断站造成掉话. 断站可引起频率干扰,弱覆盖, 切换问题等导致掉话.直放站会引起起频率干扰及部分区域弱覆盖.切换造成的掉话.INTRA_CELL 掉话多应该从干扰的角度去检查.下面重点谈论系统中重要的直接反映问题的几个统计项:PATH_BALANCE:PATH_BALANCE=上行链路路径损耗-下行链路路径损耗+110;(其中上行链路路径损耗=实际的MS TXPWR-RXLEV_UL; 下行链路路径损耗=实际的BTS TXPWR-RXLEV_DL)该统计用来对每一个CTU提供链路平衡验证,每SACCH(480ms)更新一次.一般情况下,上下行损耗是相似的,(数值的范围0—220),±10的差值.超过±10, 路径损耗有问题,应检查:PATH_BALANCE过大,说明上行链路路径损耗大,应检查天馈线是否接错,接收设备.PATH_BALANCE过小, 下行链路路径损耗大, 应检查天馈线VSWR,发射设备输出过底,是否有塔放.PATH_BALANCE正常,不能说明没有问题,若天馈线有问题,在天馈线上的上下行损耗都很大,从而PATH_BALANCE值正常,这时体现出的症状是弱覆盖.DRI 数据配置不正确(如CELL= 1做成2)导致PATH_BALANCE大.该值不正常时会使MS与RSS之间的传送信息丢失而导致掉话与切换失败.BER:下行链路误码率:当MS处于TCH上时,MS在每个SACCH复帧都会收到来自BSS 的100个下行链路突发序列,进行质量检查得出100个BER, 并被处理一个总的BER 平均值.,然后这个平均值被编码成GSM定义的质量段,,在上行链路测量报告中送到BSS,HDPC将决定MS是否需要进行功率控制或切换.每一个SACCH复帧(480ms)更新一次.只有信道是激活的时候才报告该值.分0-7共8级.应从下面几方面查找问题: 硬件问题:A .CTU发射功率不正常过低,造成BER偏大.B.偶数TS的BER大, 奇数TS的BER小,CTU坏.弱覆盖,信号太弱造成BER偏大.干扰:包括系统内和外部干扰.越区覆盖导致频率干扰造成下行链路误码大.注:前面提到的硬件与干扰问题,可通过转移RTF观察来定位.INTF_ON_IDLE:空闲时隙上接收信号强度的干扰值.DRIM 通过RSS L1向HDPC提供每个时隙的干扰信息,每个空闲时隙的干扰情况都被监控.HDPC通过使用一种未加权的算法对这些干扰电平(0—63)进行平均,每个SACCH复帧(480ms)产生一个干扰电平值.该统计值可反映出如下问题:该值太大側载频坏.在20-30左右,可能有外部干扰存在(如军事紧急会议开启干扰源以防泄密).10左右,系统内干扰(邻区同邻频;越区覆盖干扰;断站干扰等).该值越小质量越好.注:前面提到的硬件与干扰问题,可通过转移RTF观察来定位.每次割接,系统性能就会发生响应的变化,为了及时了解分析系统性能,为用户提供一个优良的网络服务,进行系统性能进行检控是非常重要的.下面就从几方面对其进行分析.由于天气的好坏对系统性能造成较大的影响,每次割接时天气不能人为控制,首先了解天气的影响对分析割接后的系统性能是很有必要的.掉话率:CMCC DROP_CALL_RATE TCH_RFLOSS_RATE0.70%0.60%0.50%0.40%0.30%0.20%0.10%0.00%5678阴雨9阴雨10阴雨11阴雨12阴雨13阴雨1415从上图可以看出11/8阴雨天开始(8,9日是双休日)全网掉话率与TCH_RF_LOSS有较大幅度的升高,到11/14晴天回降,11/15 DROP_CALL_RATE0.54% ,TCH_RF_LOSS_RATE为0.34%基本恢复正常.阴雨天气导致话务模型的变化以及空气密度的增大地面雨水(雨水雾气折射反射)等各种原因,造成了掉话较多.CMCC HO_SUC_RATE MOT HO_SUC_RATE96.40%96.20%96.00%95.80%95.60%95.40%95.20%95.00%5678阴雨9阴雨10阴雨11阴雨12阴雨13阴雨1415168日是双休日,话务量较低,切换成功率稍高.其他阴雨天的切换成功率均比平时低.在阴雨天,UL_QUALITY_HO比例减小而PBGT增加.这种现象可能是由于用户的行为改变(位置信号弱)及空气中物质的增多使得信号传播损耗大,导致MS与RSS间的消息传送丢失比晴天多,从而影响了系统的性能,使掉话率高切换成功率低.(注:从I_O_I,handover/per call看不出明显变化).上饶在11月17日凌晨进行的改频割接(BSC01G/BSC05G).所取的数据是9:00—10:00的真实数据. 割接后从以下几方面对系统进行监控:话务量:TCH TRAFFIC4900480047004600450044004300420041004000390014151617割接1819阴雨20阴雨21阴雨222324上饶的话务量工作日期间变化不大,但双休日起伏较大,波动范围在600ERL.切换成功率:CMCC公式: (out_intra_bss_ho_suc+ out_inter_bss_ho_suc+ in_intra_bss_ho_suc+ in_inter_bss_ho_suc)/out_intra_bss_ho_atmpt+out_inter_bss_ho_atmpt+in_intra_bss _ho_suc+in_intra_bss_ho_lostms+in_intra_bss_ho_return+in_intra_bss_ho_cleared+ ho_req_msc_ok .HO_SUC_RATE(CMCC)HO_SUC_RATE(MOT)97.00%96.50%96.00%95.50%95.00%94.50%94.00%14151617割接1819阴雨20阴雨21阴雨222324OUT_INTER_BSS_HO_FAIL10.00%9.00%8.00%7.00%6.00%5.00%4.00%3.00%2.00%1.00%0.00%14151617割接1819阴雨20阴雨21阴雨22割接后切话成功率有所上升,总体上无线环境比以前好.毫无疑问,提高全网的切换成功率就是要减少切换失败次数.方法之一是从统计中过滤出失败次数多的小区,在OMCR上取PER NEIGHBOR的IN/OUT_INTRA_BSS_NC_ATMPT/SUC统计,根据该小区对每一个NEIGHBOR 切入切出切换失败次数查找问题,若所有小区对该小区的切入失败次数多则该小区有问题:检查A .数据LAC,BCCH,BSIC,SYN,IN/EXTERNAL等错误.B 干扰. C 硬件等问题 .若对某一小区切出失败次数多那么问题在于目标小区.例:市区31103切换失败次数281,切换成功率只有85.23%.切入失败次数261.经检查问题在于DRI 2 3,LOCK后切换成功率达97.49%,切换失败次数31.影响成功切换率的原因很多,见P9.干扰:系统内干扰与外部干扰.MS收到来自源小区的切换命令,试图与目标RSS建立连接,由于干扰造成不能接入.小区各TCU/CTU功率不平衡,有BCCH的CTU发射功率较大,但分配TCH的CTU发射功率小,导致MS与目标RSS接入不成功,切换失败.MCUF/MCU/CTU本身硬件有问题.时钟失锁.天线朝向不对或接错.不同的扇区交叉错接或同一小区的两根天线朝向偏差较大.天线VSWR大.越区覆盖造成的切换失败,避免越区.NEIGHBOR合理.不能漏加应有的也不能加上无关的NEIGHBOR.弱覆盖掉话率:0.50%0.52%0.54%0.56%0.58%0.60%0.62%14151617割接1819阴雨20阴雨21阴雨222324CMCC DROP_CALL_RATE0.00%0.05%0.10%0.15%0.20%0.25%0.30%0.35%0.40%0.45%14151617割接1819阴雨20阴雨21阴雨222324TCH_RF_LOSS_RATEO_INTRA_BS_LOST_RATEO_INTER_BS_HO_CLR_RATE系统中存在着同邻频干扰,要对其进行调整.如左下图两站之间相隔150米,距离太近很难做到不越区. 部分频点进行调整.三项掉话次数由1748降到1589.INTRA_CELL 掉话有2259-2048. 全网的INTF_ON_IDLE 总和降低了1320.掉话率由0.56%降到0.54%.<造成掉话的几方面原因见P10.>SDCCH 拥塞:150M公式= ALLOC_SDCCH_FAIL/ ALLOC_SDCCH+ ALLOC_SDCCH_FAIL.SDCCH_BLK_RATE0.14%0.12%0.10%0.08%0.06%0.04%0.02%0.00%14151617割接1819阴雨20阴雨21阴雨22阴雨SDCCH 拥塞率是受阻塞的SDCCH接入尝试的百分比(包含切换尝试).处理的方法之一是根据全网统计将拥塞次数较多的小区根据情况调整NUMBER_SDCCHS_PREFERRED;开启开关CHANNEL_RECONFIGURATION_SWITCH,增大MAX_NUMBER_OF_SDCCHS,LAC区域边界站将CELL_RESLECT_HYSTERESIS放到最大(7=14DB).17日拥塞率较高,经检查29711的ALLOC_SD_FAIL 达581次,全网共813. 该站为区域边界站,站型OMNI2,已经将CELL_RESLECT_HYSTERESIS放到最大,SDCCH 与TCH均拥塞严重,只能扩容.该值一般情况为0,若存在较大的alloc_sdcch_fail ,说明SDCCH拥塞严重常用的解决方法是:增加SDCCH数目,特别是铁路高速公路旁边的基站.较大干扰会造成SDCCH拥塞,故一定要排除干扰.减小该cell的C1(增大rxlev_access_min(-110---47)).采用动态分配SDCCH的算法.TCH拥塞:TCH_BLK_RATE= ALLOC_TCH_FAIL/TOTAL_CALL+ ALLOC_TCH_FAIL.该统计数据是由于TCH的拥塞而造成的呼叫建立及小区内切换被拒绝的百分比.0.00%0.10%0.20%0.30%0.40%0.50%0.60%0.70%0.80%0.90%1.00%14151617割接1819阴雨20阴雨21阴雨222324TCH_BLK_RATETCH 拥塞率会随着话务量增加而升高.由于硬件资源的有限,在现有的网络基础上进行一定的处理.将拥塞切换打开ho_exist_congestion=2;tch_congest_prevent_thres=80;邻区congest_ho_margin=0; bounce_protect_margin=10;bounce_protec_congest_tmr=20.部分小区得到缓解,但话务多的地方作用小.参见下表: NAME ALLOC_TCH_FAIL TCH_BLK _RATE Erl/tch carri er ALLOC_TCH_FAIL/打开 SD_BLK_RAT E/打开 TCH_BLK_RAT E/打开 Erl/tch/打开 10113 41 1.01% 0.717 6 15 0 0.32% 0.717 10241 56 1.34% 0.722 5 107 0 2.71% 0.750 27832 184 3.37% 0.786 6 285 0 4.41% 0.807 28312 42 2.05% 0.678 4 7 0 0.38% 0.553 28433 66 1.75% 0.723 6 15 0 0.37% 0.683 28522 45 1.05% 0.717 6 118 0 2.13% 0.762 10191 175 3.85% 0.775 6 13 0 0.27% 0.711 28182 80 3.22% 0.623 4 3 0 0.11% 0.540 28573 140 4.52% 0.744 4 1924 0 66.23% 0.929 10152 47 1.24% 0.695 6 23 0 0.58% 0.720 28862 177 3.24% 0.780 6 204 0 3.07% 0.769 29732 184 18.70% 0.776 2 136 0 12.39% 0.692 27163 84 2.04% 0.734 6 0 0 0.00% 0.546 正常情况下,TCH 的拥塞应该为0,如果出现拥塞,则主要的解决方法有: 打开该小区往其它小区的拥塞切换。