代维巡检动环维护主动推送
代维巡检动环维护主动推送[20191213092644]
摘 要
随着客户需求的不断增加、通信网络规模不断扩大以及移动数据流量的急剧增长和技术的飞速发展，各种常规但繁杂的事情逐渐增多，通信网络代维服务已成为通信网络运维体系不可或缺的部分。虽然从事代维服务的企业有上千家，但是由于成本和定位的限制以及工作性质导致代维人员责任感和归属感相对淡薄，缺乏积极的思考，而其中代维工作人员维护质量的高低完全关系到网络是否能够安全运行。
本课题来源于常州移动与校企合作项目：代维巡检动环维护主动推送系统。
根据常州移动公司据代维管理办法，代维每月巡检需进行动环水浸、门开告警等验证测试并核对动环监控采集数据。代维公司人员巡检时是否按照要求进行告警测试及数据核对完全依赖于代维人员的自觉性，暂时无具体的技术手段来直观体现巡检结果。
为了全面掌握基站动环监控系统运行及代维动环故障处理情况，通过精准管理提升代维技术能力、动环监控系统稳定性及安全性，对存在重要动环监控故障的局站自动告警并通过报表短信等手段进行提示，本文提出了代维巡检动环维护主动推送系统的想法。该系统通过C接口采集动环实时数据，并生成报表，通过短信邮件平台将动环告警测试完成情况、动环监控处理情况、动环监控系统自检告警情况推送给相关代维工作人员。
查看完整论文请+Q: 351916072
关键字:代维巡检；主动推送；动环监控
目 录
摘 要 I
Abstract II
第一章 绪论 1
第一节 课题研究背景 1
第二节 本课题的研究意义 1
第三节 本文主要研究内容及章节安排 2
第二章 技术相关概要 3
第一节 C接口相关规范 3
第二节 Java Web 6
第三节 MyEclipse 8
第四节 MYSQL 8
第三章 系统总体设计 10
第一节 功能需求 10
第二节 需求分析 11
第三节 系统流程分析 13
第四节 方案对比 16
第四章 系统详细设计与实现 27
第一节 数据库设计 27
第二节 用户登录界面 28
第三节 JSP获取远程数据库数据 32
第五章 系统集成及测试 34
第一节 系统集成 34
第二节 系统测试 34
第六章 总结与展望 38
参考文献 39
致 谢 41
一、英文原文 43
二、英文翻译 50
第一章 绪论
第一节 课题研究背景
随着电信行业新一轮重组和年初3G牌照的正式发放，中国正式进入了3G时代，同时电信运营商也迎来了全业务发展的新时期。全业务运营时代业务量不断增大，对无线网络室内覆盖的要求更高；终端服务增多，维护的协调工作量更大；由于尽可能缩短了建设周期，测试和网络优化要求更加频繁——这些都大大增加了电信运营商的运营工作量。
通信设备和设施的稳定运行至关重要，设备的每一次故障都有可能给运营商造成无法估量的损失，所以，保证设备的安全运行是运营商网络维护的首要任务。代维的各项工作是有效保证通信系统安全的基础工作，代维工作管理上的缺失将影响着网络的价值及用户的感知。
根据代维管理办法，代维每月巡检需进行动环水浸、门开告警等验证测试并核对动环监控采集数据。代维公司人员巡检时是否按照要求进行告警测试及数据核对完全依赖于代维人员的自觉性，暂时无具体的技术手段来直观体现巡检结果。
第二节 本课题的研究意义
建立代维巡检动环维护主动推送系统，将代维巡检需进行的动环测试及数据核对纳入其中，每月对代维完成情况进行汇总，生成报表，通过短信和邮件主动推送给代维管理人员及代维公司。通过每月动环告警测试及数据核对，可以提高动环监控可用率、准确率，确保告警事件正确及时呈现，同时提高代维人员的工作效率，确保通信设备正常运行。
该系统能将代维管理人员与代维工作人员间搭建起一个资源共享、信息沟通的平台。通过人员管理、维护对象管理、工器具管理、车辆管理、资料库管理、维护流程管理、工单管理、发电调度、故障调度、沟通平台和统计报表等功能实现,让代维公司的维护人员在处理障碍时更有针对性、更快捷,确保用户故障及时处理;同时实现代维管理部门间的任务交互、代维公司与运营商间的任务交互、交流沟通,最终促进整个代维业务的良性发展。
第三节 本文主要研究内容及章节安排
该系统分解为3个子系统：“代维巡检动环维护主动推送系统汇总与报告子系统”、“代维巡检动环维护主动推送系统短信邮件主推子系统”、“代维巡检动环维护主动推送系统信息录入子系统”。本文主要研究的是代维巡检动环维护主动推送系统信息录入子系统。
章节安排如下：
第一章是绪论，主要介绍了该系统的研究背景、研究意义以及相关的的研究内容以及章节安排。
第二章是介绍的相关技术概要，主要介绍了C接口的相关规范、Java Web方面的知识以及开发工具Myplise和数据库Mysql。
第三章则进入到了子系统的总体设计。首先对该子系统进行功能需求分析，然后对实现该子系统的功能设计了多种方案并进行方案对比。
第四章则按照上章对比的最终方案对该子系统具体功能进行详细设计。
第五章对小组各个成员设计的子系统进行集成并完成主要功能的测试。
第六章是对该系统的总结和展望，主要对该系统功能的总结以及一些不足和需要改正的地方。
第二章 技术相关概要
由于该课题来源于常州移动和校企合作项目，其中涉及到了移动公司的C接口相关规范以及数据库MYSQL、JAVA WEB等等相关技术。
第一节 C接口相关规范
一、 术语、定义
移动通信图象、动力及环境集中监控系统－PEMS（Video Power & Environment Supervision system for Mobile communication），对移动通信机房的动力设备及环境进行图象监控、遥测、遥信、遥控和遥调，实时监视其运行参数，监测和处理故障，记录和处理相关数据，实现移动通信机房少人或无人值守和集中维护。
集中监控中心－Central Supervision Center（CSC)，面向多LSC管理的高级监控层次，通过开放的数据协议，连接下属的多个LSC对象。
区域监控中心－Local supervision Center（LSC)，面向区域级的设备对象管理和表现的监控层次，连接区域内的FSU，在此层次对监控的基本功能进行实现。
C接口—C Interface，为集中监控中心（CSC）与区域监控中心（LSC）之间的接口。
二、 组网结构及接入双方要求
LSC与CSC之间通过TCP/IP方式与数据库方式互联。采用TCP/IP方式时，LSC为服务器，CSC为客户端。采用数据库方式时，LSC提供中间数据库，CSC通过访问中间数据库提取数据。
三、 C接口协议
1.报文原则
CSC与LSC之间的接口基于TCP/IP技术，采用C/S体系结构，其中CSC作为客户端，LSC作为服务器，在LSC服务器上提供一个套接字接口。
2.基本报文格式定义
表2.1 基本报文格式定义
序号 类型 内容 定义
1 Long 报文包头(Header) 报文开始包头标志 0x7E7C6B5A
2 Long 长度（Length） 总报文长度
3 Long 报文序号（SerialsNo） 报文发送、应答过程中使用的序号，应答包的序号等于对应的发送包的序号，使用的序号值由厂家自定义，注意：使用的序号不能等于报文包头的值
4 long 命令字（PK_Type） 报文类型
5 内容（Info） 报文内容
6 short CRC16 2~5的CRC16值
报文最大长度64K，长度可设。
四、数据库接口协议
1.数据库接口说明
各个LSC根据CSC系统约定，增加中间数据表，存储LSC的基站数据，设备数据，测点数据，告警数据，历史数据。
2.数据库接口要求
⑴局站、设备、测点数据同步要求
LSC把监控对象配置根据“数据库接口定义”的数据结构存储到中间数据库表中，增加、修改和删除任何配置，LSC必须保证能够及时的维护该中间数据库表中的数据。涉及到的中间数据库表有M_Area、M_Station、M_Device、M_AIC、M_AOC、M_DIC、M_DOC。中间数据库表中的数据由LSC维护，LSC保证上述表中的数据和LSC的配置一致。CSC根据设计要求，自行连接各个数据表，确保数据同步。
⑵实时告警（活动告警）要求
LSC将告警存储到数据库中，每种状态的演变，LSC均产生一条记录插入数据库，每一个完整的告警演变流程，所有产生的告警记录的告警序号一致。涉及到的数据表为D_ActiveAlarm。该数据库表的记录由LSC负责存储，CSC则根据D_ActiveAlarm中的ID字段的变化来定期同步（CSC与LSC约定ID最大值为20亿，请LSC厂家注意根据此ID字段的增长情况进行数据库维护）。
CSC负责定期将两天前的数据删除，删除机制如下：在保证活动告警表中至少存储一条某测点对象的记录的前提下，以最大的告警发生时间为基准，删除比该时间小的该对象所有记录。
⑶历史告警要求
LSC实时存储历史告警，当活动告警恢复以后，及时把数据存储到历史告警表中。涉及到的表为D_AlarmH。该数据表的数据由CSC来维护，LSC只负责实时存储历史告警，删除工作由CSC负责。
⑷历史数据要求
LSC在中间数据库表中存储历史数据。按LSC的存储原则写入，删除工作由CSC完成。LSC根据时间间隔（最小为1小时），向历史告警表，遥信量历史数据表，遥测量历史数据表，历史事件表存储数据。
3.数据库部分接口定义
表2.2：区域表(M_Area)
列名称 数据类型 说明
LSCId Long LSC的ID号
AreaId Long 区域编号(主键，从1开始，在LSC下的范围为1-65535)
LastAreaId Long 上级区域ID，如果不存在上级区域，则该LastAreaId为0，最大嵌套4级别
AreaName char(NAME_LENGTH) 区域名称
表2.3：局站表(M_Station)
列名称 数据类型 说明
NodeId Long 主键:基站数据标识ID
LSCId Long LSC ID
NodeType EnumType 数据的类型,此处填0
NodeName char(NAME_LENGTH) 基站名字
NodeDesc char(DES_LENGTH) 基站描述
Longitude Float 经度
Latitude Float 纬度
STD StationID char(DES_LENGTH) 基站ID
NodeFeatures EnumNodeType 基站特征
StationTypeId EnumStationType 基站类型
AreaId Long 区域编号
第二节 Java Web
一、 Web应用程序的运行原理
在传统的Web应用程序开发中，需要同时开发客户端和服务器端的程序，由服务器端的程序提供基本的服务，客户端是提供给用户的访问接口，用户可以通过客户端的软件访问服务器提供的服务，这种Web应用程序的开发模式就是传统的C/S开发模式，在这种模式中，由服务器端和客户端的共同配合来完成复杂的业务逻辑。例如以前的网络软件中，一般都会采用这种模式，而且现在的网络游戏中，一般还会采用这种Web开发模式，在这些Web应用程序中，都是需要用户安装客户端才可以使用的[1]。
在目前的Web应用程序开发中，一般情况下会采用另一种开发模式，在这种开发模式中，不在单独开发客户端软件，客户端只需要一个浏览器即可，这个浏览器在每个操作系统中都是自带的，软件开发人员只需专注开发服务器端的功能，用户通过浏览器就可以访问服务器端提供的服务，这种开发模式就是当前流行的B/S架构，在这种架构中，只需要开发服务器端的程序功能，而无需考虑客户端软件的开发，客户通过一个浏览器就可以访问应用系统提供的功能。这种架构是目前Web应用程序的主要开发模式，例如各大门户网站、各种Web信息管理系统等，使用B/S的架构加快Web应用程序开发的速度，提高了开发效率[2]。
二、 Web服务器汇总
IIS 是微软提供的一种Web服务器，提供对ASP语言的良好支持，通过插件的安装，也可以提供对PHP语言的支持。
摘 要
随着客户需求的不断增加、通信网络规模不断扩大以及移动数据流量的急剧增长和技术的飞速发展，各种常规但繁杂的事情逐渐增多，通信网络代维服务已成为通信网络运维体系不可或缺的部分。虽然从事代维服务的企业有上千家，但是由于成本和定位的限制以及工作性质导致代维人员责任感和归属感相对淡薄，缺乏积极的思考，而其中代维工作人员维护质量的高低完全关系到网络是否能够安全运行。
本课题来源于常州移动与校企合作项目：代维巡检动环维护主动推送系统。
根据常州移动公司据代维管理办法，代维每月巡检需进行动环水浸、门开告警等验证测试并核对动环监控采集数据。代维公司人员巡检时是否按照要求进行告警测试及数据核对完全依赖于代维人员的自觉性，暂时无具体的技术手段来直观体现巡检结果。
为了全面掌握基站动环监控系统运行及代维动环故障处理情况，通过精准管理提升代维技术能力、动环监控系统稳定性及安全性，对存在重要动环监控故障的局站自动告警并通过报表短信等手段进行提示，本文提出了代维巡检动环维护主动推送系统的想法。该系统通过C接口采集动环实时数据，并生成报表，通过短信邮件平台将动环告警测试完成情况、动环监控处理情况、动环监控系统自检告警情况推送给相关代维工作人员。
查看完整论文请+Q: 351916072
关键字:代维巡检；主动推送；动环监控
目 录
摘 要 I
Abstract II
第一章 绪论 1
第一节 课题研究背景 1
第二节 本课题的研究意义 1
第三节 本文主要研究内容及章节安排 2
第二章 技术相关概要 3
第一节 C接口相关规范 3
第二节 Java Web 6
第三节 MyEclipse 8
第四节 MYSQL 8
第三章 系统总体设计 10
第一节 功能需求 10
第二节 需求分析 11
第三节 系统流程分析 13
第四节 方案对比 16
第四章 系统详细设计与实现 27
第一节 数据库设计 27
第二节 用户登录界面 28
第三节 JSP获取远程数据库数据 32
第五章 系统集成及测试 34
第一节 系统集成 34
第二节 系统测试 34
第六章 总结与展望 38
参考文献 39
致 谢 41
一、英文原文 43
二、英文翻译 50
第一章 绪论
第一节 课题研究背景
随着电信行业新一轮重组和年初3G牌照的正式发放，中国正式进入了3G时代，同时电信运营商也迎来了全业务发展的新时期。全业务运营时代业务量不断增大，对无线网络室内覆盖的要求更高；终端服务增多，维护的协调工作量更大；由于尽可能缩短了建设周期，测试和网络优化要求更加频繁——这些都大大增加了电信运营商的运营工作量。
通信设备和设施的稳定运行至关重要，设备的每一次故障都有可能给运营商造成无法估量的损失，所以，保证设备的安全运行是运营商网络维护的首要任务。代维的各项工作是有效保证通信系统安全的基础工作，代维工作管理上的缺失将影响着网络的价值及用户的感知。
根据代维管理办法，代维每月巡检需进行动环水浸、门开告警等验证测试并核对动环监控采集数据。代维公司人员巡检时是否按照要求进行告警测试及数据核对完全依赖于代维人员的自觉性，暂时无具体的技术手段来直观体现巡检结果。
第二节 本课题的研究意义
建立代维巡检动环维护主动推送系统，将代维巡检需进行的动环测试及数据核对纳入其中，每月对代维完成情况进行汇总，生成报表，通过短信和邮件主动推送给代维管理人员及代维公司。通过每月动环告警测试及数据核对，可以提高动环监控可用率、准确率，确保告警事件正确及时呈现，同时提高代维人员的工作效率，确保通信设备正常运行。
该系统能将代维管理人员与代维工作人员间搭建起一个资源共享、信息沟通的平台。通过人员管理、维护对象管理、工器具管理、车辆管理、资料库管理、维护流程管理、工单管理、发电调度、故障调度、沟通平台和统计报表等功能实现,让代维公司的维护人员在处理障碍时更有针对性、更快捷,确保用户故障及时处理;同时实现代维管理部门间的任务交互、代维公司与运营商间的任务交互、交流沟通,最终促进整个代维业务的良性发展。
第三节 本文主要研究内容及章节安排
该系统分解为3个子系统：“代维巡检动环维护主动推送系统汇总与报告子系统”、“代维巡检动环维护主动推送系统短信邮件主推子系统”、“代维巡检动环维护主动推送系统信息录入子系统”。本文主要研究的是代维巡检动环维护主动推送系统信息录入子系统。
章节安排如下：
第一章是绪论，主要介绍了该系统的研究背景、研究意义以及相关的的研究内容以及章节安排。
第二章是介绍的相关技术概要，主要介绍了C接口的相关规范、Java Web方面的知识以及开发工具Myplise和数据库Mysql。
第三章则进入到了子系统的总体设计。首先对该子系统进行功能需求分析，然后对实现该子系统的功能设计了多种方案并进行方案对比。
第四章则按照上章对比的最终方案对该子系统具体功能进行详细设计。
第五章对小组各个成员设计的子系统进行集成并完成主要功能的测试。
第六章是对该系统的总结和展望，主要对该系统功能的总结以及一些不足和需要改正的地方。
第二章 技术相关概要
由于该课题来源于常州移动和校企合作项目，其中涉及到了移动公司的C接口相关规范以及数据库MYSQL、JAVA WEB等等相关技术。
第一节 C接口相关规范
一、 术语、定义
移动通信图象、动力及环境集中监控系统－PEMS（Video Power & Environment Supervision system for Mobile communication），对移动通信机房的动力设备及环境进行图象监控、遥测、遥信、遥控和遥调，实时监视其运行参数，监测和处理故障，记录和处理相关数据，实现移动通信机房少人或无人值守和集中维护。
集中监控中心－Central Supervision Center（CSC)，面向多LSC管理的高级监控层次，通过开放的数据协议，连接下属的多个LSC对象。
区域监控中心－Local supervision Center（LSC)，面向区域级的设备对象管理和表现的监控层次，连接区域内的FSU，在此层次对监控的基本功能进行实现。
C接口—C Interface，为集中监控中心（CSC）与区域监控中心（LSC）之间的接口。
二、 组网结构及接入双方要求
LSC与CSC之间通过TCP/IP方式与数据库方式互联。采用TCP/IP方式时，LSC为服务器，CSC为客户端。采用数据库方式时，LSC提供中间数据库，CSC通过访问中间数据库提取数据。
三、 C接口协议
1.报文原则
CSC与LSC之间的接口基于TCP/IP技术，采用C/S体系结构，其中CSC作为客户端，LSC作为服务器，在LSC服务器上提供一个套接字接口。
2.基本报文格式定义
表2.1 基本报文格式定义
序号 类型 内容 定义
1 Long 报文包头(Header) 报文开始包头标志 0x7E7C6B5A
2 Long 长度（Length） 总报文长度
3 Long 报文序号（SerialsNo） 报文发送、应答过程中使用的序号，应答包的序号等于对应的发送包的序号，使用的序号值由厂家自定义，注意：使用的序号不能等于报文包头的值
4 long 命令字（PK_Type） 报文类型
5 内容（Info） 报文内容
6 short CRC16 2~5的CRC16值
报文最大长度64K，长度可设。
四、数据库接口协议
1.数据库接口说明
各个LSC根据CSC系统约定，增加中间数据表，存储LSC的基站数据，设备数据，测点数据，告警数据，历史数据。
2.数据库接口要求
⑴局站、设备、测点数据同步要求
LSC把监控对象配置根据“数据库接口定义”的数据结构存储到中间数据库表中，增加、修改和删除任何配置，LSC必须保证能够及时的维护该中间数据库表中的数据。涉及到的中间数据库表有M_Area、M_Station、M_Device、M_AIC、M_AOC、M_DIC、M_DOC。中间数据库表中的数据由LSC维护，LSC保证上述表中的数据和LSC的配置一致。CSC根据设计要求，自行连接各个数据表，确保数据同步。
⑵实时告警（活动告警）要求
LSC将告警存储到数据库中，每种状态的演变，LSC均产生一条记录插入数据库，每一个完整的告警演变流程，所有产生的告警记录的告警序号一致。涉及到的数据表为D_ActiveAlarm。该数据库表的记录由LSC负责存储，CSC则根据D_ActiveAlarm中的ID字段的变化来定期同步（CSC与LSC约定ID最大值为20亿，请LSC厂家注意根据此ID字段的增长情况进行数据库维护）。
CSC负责定期将两天前的数据删除，删除机制如下：在保证活动告警表中至少存储一条某测点对象的记录的前提下，以最大的告警发生时间为基准，删除比该时间小的该对象所有记录。
⑶历史告警要求
LSC实时存储历史告警，当活动告警恢复以后，及时把数据存储到历史告警表中。涉及到的表为D_AlarmH。该数据表的数据由CSC来维护，LSC只负责实时存储历史告警，删除工作由CSC负责。
⑷历史数据要求
LSC在中间数据库表中存储历史数据。按LSC的存储原则写入，删除工作由CSC完成。LSC根据时间间隔（最小为1小时），向历史告警表，遥信量历史数据表，遥测量历史数据表，历史事件表存储数据。
3.数据库部分接口定义
表2.2：区域表(M_Area)
列名称 数据类型 说明
LSCId Long LSC的ID号
AreaId Long 区域编号(主键，从1开始，在LSC下的范围为1-65535)
LastAreaId Long 上级区域ID，如果不存在上级区域，则该LastAreaId为0，最大嵌套4级别
AreaName char(NAME_LENGTH) 区域名称
表2.3：局站表(M_Station)
列名称 数据类型 说明
NodeId Long 主键:基站数据标识ID
LSCId Long LSC ID
NodeType EnumType 数据的类型,此处填0
NodeName char(NAME_LENGTH) 基站名字
NodeDesc char(DES_LENGTH) 基站描述
Longitude Float 经度
Latitude Float 纬度
STD StationID char(DES_LENGTH) 基站ID
NodeFeatures EnumNodeType 基站特征
StationTypeId EnumStationType 基站类型
AreaId Long 区域编号
第二节 Java Web
一、 Web应用程序的运行原理
在传统的Web应用程序开发中，需要同时开发客户端和服务器端的程序，由服务器端的程序提供基本的服务，客户端是提供给用户的访问接口，用户可以通过客户端的软件访问服务器提供的服务，这种Web应用程序的开发模式就是传统的C/S开发模式，在这种模式中，由服务器端和客户端的共同配合来完成复杂的业务逻辑。例如以前的网络软件中，一般都会采用这种模式，而且现在的网络游戏中，一般还会采用这种Web开发模式，在这些Web应用程序中，都是需要用户安装客户端才可以使用的[1]。
在目前的Web应用程序开发中，一般情况下会采用另一种开发模式，在这种开发模式中，不在单独开发客户端软件，客户端只需要一个浏览器即可，这个浏览器在每个操作系统中都是自带的，软件开发人员只需专注开发服务器端的功能，用户通过浏览器就可以访问服务器端提供的服务，这种开发模式就是当前流行的B/S架构，在这种架构中，只需要开发服务器端的程序功能，而无需考虑客户端软件的开发，客户通过一个浏览器就可以访问应用系统提供的功能。这种架构是目前Web应用程序的主要开发模式，例如各大门户网站、各种Web信息管理系统等，使用B/S的架构加快Web应用程序开发的速度，提高了开发效率[2]。
二、 Web服务器汇总
IIS 是微软提供的一种Web服务器，提供对ASP语言的良好支持，通过插件的安装，也可以提供对PHP语言的支持。
版权保护: 本文由 hbsrm.com编辑，转载请保留链接: www.hbsrm.com/dzxx/txgc/2248.html
