NOKIA优化项目总结

NOKIA优化项目总结NOKIA优化项目总结优化项目行将结束,为了以后工程的顺利开展,也为了项目组成员技能的提高,现总结如下。为了便于总结，分别从终端操作，report运行，操作命令，参数调整，提取数据几个方面予以描述。1NOKIA终端操作1．1使用工具:由于NOKIAOMC_R不是图形化界面，故要使用reflection软件登陆OMC终端，提取报告，查参数，告警等，当然也可以使用telnet,x-manager等终端工具，通过工程实践证明reflection是最佳工具。1．2操作界面进入OMC后，可以通过不同的操作进入不同的操作界面，执行不同的任务：BSC操作界面1．－通过reflection下的reflectionforUNIXandDigital子菜单等陆；－输入用户名：planner－输入密码：xxxxx(登陆后首先进入的是UNIX界面，可以使用UNIX操作命令，如tar,vi等)以上是REFLECTION登陆步骤，进入任何操作界面前都必须经过以上步骤。下面的操作步骤对于进入BSC界面，报告界面，SQL界面是不同的。－键入命令：neman.sh－选择不同的BSC－用户名：xxxx密码：xxxx（至此，便进如BSC操作界面—MAINLEVELCOMMAND）－进入BSC后可敲入各种命令：ZEEI，ZEAO，ZEHO，ZEUO，ZEQO，ZERO，ZEOO等。Z命令退出BSC操作界面，最后返回reflection登录后的unix界面。Report报告提取界面－REFLECTION登陆步骤（同上）－在UNIX界面下进入目录：cd/d/nmsopt/nokiaoss/content/ndobss回车－./ndp001mx.sh－用户名：xxxxx密码：xxxxx（进入报告界面）－选择菜单6，提取报告－键入报告名如800,204,163,213,196,222等q命令退出报告界面，退回UNIX命令界面。进入SQL界面－在UNIX界面下进入相关目录－sqlplus命令进入SQL编辑器界面－sql>@cellKPInew_bh_10_today.sql运行sql文件－可用ftp工具传送sql文件（注意：一定要使用ASIC方式传送文件，否则不能运行。）－quit命令退出SQL语言编程将是我们必须掌握的一项技能，如若不然，如果新换一个工地，取数据将会是一个问题。2．Report在NOKIA优化中，常用到如下报告：800全网指标（可以看全网、BSC和小区级主要性能指标，任意时段、任意时间区间、可以是多天联合统计、或全天）163全网高掉话小区统计，从高到低排序。204小区级指标统计196/197小区级各TRX质量统计。（不能查看单独时段，最短只能看当天0：00到观察时间的联合统计）213小区级指标统计，包含参数设置，又名cellDocter（是记录统计数据最全的报告，但很烦琐，类容很多，不容易找到重点。）222各LAC下寻呼量统计076各BSC下同频同色码统计3．COMMAND常用命令也就是bsc_log.sh中的几个按纽所示，具体的命令格式详见NED：ZEEI显示小区级参数，如该小区各载波频点，是否可用，BCCH频点ZEOL/ZAOH显示告警ZEEO显示BSC级的告警门限等参数ZERO显示小区各载波时隙的占用情况，干扰情况ZEEL:显示该BSC下BL的小区，载波ZEHO:显示切换参数ZEAO:显示邻小区参数ZEUO:显示功控参数ZEQO:显示所有BTS的参数，加ALL显示以上命令的具体内容请参阅NED4.参数调整总体来看，NOKIA的参数有以下几方面的特点：1、较其他厂家明显多很多，初步了解起来感觉很烦琐；2、与客户提及的参数一般以简写进行说明，比如：最小接入电平（ACCMIN）在NOKIA的参数里面则叫做RXP。类似这种参数名称的叫法要比较习惯，与客户的交流感觉会好些；3、参数繁多从另一个角度也可以看到在NOKIA进行优化时的参数调整手段也相对比较多。比如：POPT、LEV、LEVD、PD0、PD1、PD2、EFH、EFP等参数对降低或稳定掉话都有一定程度的作用。目前实验的与其他厂家不同的参数还只有这几个，其他还有这方面的参数，需要多理解，能够找到更多降低掉话率的方法。另外，其他厂家具备的参数在NOKIA同样也有相似的作用，比如：关闭由于电平的切换、调整功率控制门限、启用功率控制功能、启用BB跳频等。因此，NOKIA的优化手段应该比其他厂家更多，需要不停的尝试和发掘；4、NOKIA参数的另外一个特点就是没有有关定时器的参数，如T3101、3103、3109等等，这些参数都是不能进行调整的。在优化过程中建议不要考虑这方面的问题；5、容量问题，BSC在进行工程配置时以承载多少载频为依据，一般新的BSC（3i系列）以BCSU的数量决定BSC的载频数量，一个BCSU承载110套载频，旧的BSC（2e、2i系列）以总体承载载频数进行规划，2e承载256套载频，2i承载512套载频。在进行容量调整时需要考虑这方面的因素。NED中有具体说明；6、ABIS口传输数量问题不需要加以考虑。对于BSC只需要考虑载频数量，只要载频数量没有超过限制，多少小区和多少ABIS传输接口都没有限制；7、注意和GPRS之间的影响问题。各BSC中容量规划原则：一个PCU128个TRX，256个PDTCH信道，一个BSC有2~5各PCU。BSC下小区归属的GPRS片区（NSEI号）要注意，一个片区由一个PCU管理，一个NSEI号对应一个PCU，其下小区的分布不要交叉。8、同步切换问题。和其他厂家不同，在同站不同小区可能使用不同的BCF，也就是说一个站三个小区可能是一个BCF也可能是2个或3个BCF，但作为同步切换的原则是：只能在同一个BCF下才能进行同步切换。NOKIA的参数主要在参数手册中有介绍，但我们认为那些都是一些简单的介绍，估计更具体的说明应该在NED中。参数部分需要（而且也是目前能够直接进行学习的部分）重点加以关注和了解。5.统计数据分析1、对于NMS中的统计数据原始记录表通过SQL语言编程提取或ODBC提取时都是完全开放的，只要有能力，能够看到所有的统计数据，包含交换方面的统计都一定程度上可以看到。比如：1、能够看到载频级的质量和电平统计，能够直接通过统计数据定位故障载频；2、能够比较全面的看到小区TA分布，了解小区的覆盖距离，同时也更有利于捕捉直放站的存在问题；3、切换跟踪能够看到NEI级的由于资源的切换失败问题，由此能够具体分析出影响某个NEI方向切换失败的原因是否是由于资源问题导致，但不能区分向某个NEI切换的具体原因，如果要实现这个功能也是可以实现的，但需要打开专门的测量统计，进行专项分析，不过比较消耗BSC和NMS资源，一般不建议启用；2、由于信息量太大，因此分析起来更加烦琐，提取的数据更多，需要了解更多的计数器，甚至交换方面的计数器。原则上说，对这些计数器了解得越多，优化分析的能力将更进一步有所提升，分析深度更深，数据说明更有依据。不过，从优化总体分析和常规分析来看，以前其他厂家的分析方法和思路都能够应用到NOKIA的分析中。3、分析数据的相关门限：对于NOKIA分析一般情况下上下行链路平衡在15db以上才考虑硬件故障的可能性，主要原因还是和硬件结构相关，NOKIA基站灵敏度仅仅是符合GSM的规范，是-110dbm，但上下行相差15db以内还是能够正常工作。象类似这样的门限分析时需要根据当地数据判断和确定，不能一概而论。4、分配失败率问题：在NOKIA不能准确的取出分配失败率数据，但能取出一个比较接近的数据进行类比，只要小区不是严重拥塞，也可以以此来进行分析，而且这次我们和NOKIA进行交流后，他们都承认向我们学习了一个判断硬件故障非常快捷的方法。5、统计数据的提取：由于NOKIA的统计数据是全开放的，用NOKIA的说法就是，只要搞清楚了所有的计数器，这些计数器的功能甚至可以取代信令分析仪。由此说明其计数器之繁多。每个优化人员都可能随时提取其中的部分计数器数据。而提取计数器数据的方法只有两种：SQL程序或ODBC。两种方法都有其好的方面也有其局限。ODBC在任何时候都可以直接提取各种数据，非常方便。但其最大的局限就是非常慢，同时还受用户权限的限制。因为计数器的数量太多，且记录的时段是以每个小时为单位，因此数据量很大，要想取一天比较全面的数据需要消耗大量的时间，很慢。而且目前安排我们登陆的工作站IP其归属的路由器根本没有和数据服务器设置为同一网段，因此无法直接连接ODBC。SQL的特点是需要事先进行编程。完成SQL程序后，在UNIX中可以安装为自动执行，可以在晚上NMS比较空闲时自动运行提取数据，形成压缩文件。理论上说，只要熟悉SQL语法和NOKIA的统计数据表结构，能够在任何时间提取任何想要提取的原始数据，甚至可以通过SQL直接进行运算形成想要的中间表格，减少提取的数据量，而且不受用户权限的限制。任何一个最低级的用户权限，都能够完成SQL的编程和数据提取功能。6、对于统计数据分析方面，如果没有ODBC权限的话，SQL编程能力非常重要。因为日常优化不可能提取全部网络数据，只是提取需要分析的那些部分，对于临时出现的提取数据需求，需要临时编写SQL程序进行提取。7、统计数据提取时限：在NMS上最大能够提取两周（14天）的统计数据。6.告警收集和分析NOKIA的告警信息比较全面，能够定位到包括天线VSWR不正常的相关问题。及时监控2993告警能够将TR（TC）掉话降低为0等等。因此对告警信息的了解和查询非常重要，不一定要记住全部告警，但一定要知道告警的提取和查询方法。6.NOKIA优化知识准备综合以上内容，NOKIA优化知识准备主要有以下几个方面：1、全面了解NOKIA的网络结构，重点是基站结构；2、尽可能全面了解NOKIA的网络参数，对于有优化经验的工程师做到这点应该只需要3天时间就足够了；3、对NOKIA的计数器进行尽可能的了解，目前主要是提取数据工具中的数据表的理解，以后需要深入到对原始表的理解。了解越多，优化分析能力将越强。4、对NOKIA各种原始报告的理解，了解各种报告能够看出什么方面的问题，有些什么数据等。对所有工程现场都适用。实际上这些报告也就是一系列SQL程序的运行结果。5、对NOKIA告警信息的提取、分析和处理的了解。尤其是了解告警信息的查询方法。记住所有告警是不可能的。6、熟悉了解UNIX操作，常用的UNIX命令、VI工具的使用。7、SQL语言的学习和了解，在NOKIA系统的几乎和技术相关的客户都比较清楚SQL语言，因此这方面需要重点加以关注。8、对NOKIA数据库的原始表格结构和表格列（COLUMNNAME）的完整名称需要了解清楚，才有能力进行SQL编程。9、对容量方面的规划、预测、计算等，在NOKIA，优化和CELLPLAN是不分开的，需要同时具备这两方面的能力，甚至和无线相关的MSC方面的一些问题都需要涉及，比如：寻呼量、LAC下用户数、相关话务量、MOC、MTC比例、A接口容量计算、扩容、割接计划、LAC规划和调整、MSC、Gb的负荷、CPU负荷等等。这方面的问题我们在现场也是遇到一个学习和分析一个。10、对无线传播理论的学习和了解。由于NOKIA优化和PLAN没有分开，因此对无线传播理论和计算方法等方面的要求比较高，要求要具备一定程度的室内、市外覆盖预测能力和链路预算估算能力，对于频率规划方案的了解和分配等等。11、其他方面：ACCESS、EXCEL、MAPINFO应用能力需要具备。谢谢第二篇：OA项目总结4100字组织机构管理模块请描述一下你做的组织机构管理模块描述思路：1、组织机构模块的基本需求a)本模块主要管理公司、子公司、部门、岗位、员工的信息b)公司下面可以创建子公司、部门c)部门下面可以创建子部门、岗位或员工d)岗位下面可以创建员工（即员工可以属于某个岗位）e)公司、部门、岗位、员工形成一棵组织机构树，要求使用树型方式来展现和管理2、组织机构的总体设计思路a)公司、部门、岗位、员工可以看成同一种类型：Partyb)在Party上实现树型结构（父子关系）c)其它类型：公司、部门、岗位、员工均继承Party（请画出类图）3、组织机构的实现技巧a)利用jQuery的jsTree实现组织机构树b)利用jQuery的treeTable实现列表（AJAX、查询、分页）c)在组织机构树中显示公司、部门、岗位的信息，点击公司、部门、岗位，则可以显示其详细信息，及其下面的所有员工（利用hibernatefilter避免在树上显示员工信息）d)为了显示某个公司或部门（包括其下级机构）下面的所有员工，我们设计了一个sn，这个sn根据组织机构的树型结构来取值，通过它便可以方便实现查询需求。e)利用TreadLocal实现分页参数的传输f)利用VO设计模式适应客户端对数据格式的特殊要求4、我们这个设计的优点在哪里a)通过树的方式来管理，一目了然，层次清楚b)TheadLocal设计模式的运用大大降低了分页查询逻辑的封装处理c)抽象出Party来，便于对所有的组织机构实体进行统一的管理（比如方便我们后面的权限管理模块把所有Party统一对待）5、我们这个设计的缺点在哪里a)没有实现员工的调动管理（从一个部门调到另外一个部门），此功能在项目二期实现！b)员工不允许跨部门（即一个员工只能属于一个部门，而不能同时属于多个部门）c)在模型上没有规定哪些类型的Party只能放在哪些类型的Party下面，比如，在一般的需求中，岗位下面肯定是不能挂一个公司的。我们针对这种需求，是通过具体的代码逻辑来实现的，而没有办法在一个地方去统一定义这种规则。i.如果要实现这些逻辑的统一定义，可以参考“责任模式”！权限管理模块请描述一下你做的权限管理模块描述思路：1、权限管理的基本需求a)系统后台有很多菜单项，同时各个页面上也有很多功能按钮，客户要求我们的系统要能够控制这些菜单项的访问权限，也可以控制到具体每个功能按钮的访问权限b)客户要求建立角色的概念（参考RBAC），能够自由定制不同的角色，角色和用户之间是多对多的。c)权限可以授予角色，然后把角色分配给用户，这样用户就拥有了角色的权限d)权限也可以授予某个部门、某个岗位，这样在这些部门或岗位下面的用户就拥有了这些部门和岗位的权限e)客户还要求权限也能直接授予用户，这样即使拥有相同的角色、相同的部门、相同的岗位，用户的权限也可以是不同的f)这样，用户自身被授予的权限、用户拥有的角色的权限、用户所属部门或岗位的权限这些要素联合起来判断，才能最终决定用户的权限。g)因为用户的权限可能从多个角色或部门、岗位中继承下来，而这些角色、部门或岗位的授权极有可能会有冲突，比如一个角色的授权是允许访问，而另外一个角色的授权是拒绝访问，客户要求，如果出现这种情况，就以拒绝为准，即不允许访问。2、权限管理的总体设计思路a)因为权限可以被授予用户、角色、部门、岗位等等，我们称之为权限控制的“主体”，我们定义了一个接口Principal用来表示主体的概念，用户、角色、部门、岗位等均实现这个接口b)我们要控制菜单项以及各种功能按钮的访问，我们称这些菜单项和各种功能按钮为权限控制的“资源”，定义了一个SysResource接口来表示资源的概念。c)菜单项是一种资源；而各种功能按钮最终其实是要访问后台的某个类的某个方法，因此我们把Action类看成是一种资源（称为“操作资源”），各种功能按钮则对应了这个类里面的各种方法，我们把这些方法看成是这种资源的各种操作。d)我们定义了一个ACL用来表示哪些资源的哪些操作被授予了哪些主体，ACL中的主要属性包括：主体类型（principalType）、主体ID(principalId)、资源类型(resourceType)、资源ID(resourceId)、操作状态(aclState)，其中操作状态是int类型，在Java中，一个int有32位（bit），我们定义资源的时候，把这个资源对应的操作映射到某一位上，规定在这一位上取1表示允许执行那个操作，而取0表示不允许执行那个操作。e)这样，在授权的时候，我们直接改变相应操作的状态位的取值即可；在认证的时候，直接判断相应操作状态位的取值3、权限管理的实现技巧a)在实现上，对于授权，我们界面上用jQuery和jQuery的插件jsTree来呈现菜单树，在菜单树的前面显示一个CheckBox框，打勾表示允许，打叉表示拒绝；同时也做了一些右键点击显示上下文菜单，方便客户执行各种功能b)jsTree没有打叉这种显示方式，为了满足我们的要求，所以对jsTree插件做了一些扩展（主要是修改它的js文件和css文件、图片等），以便能支持更强大的显示方式。c)因为我们把系统中的各种Action类及其方法，看成是各种资源及其操作，为了方便管理，我们利用Spring提供的API搜索具备某些特征的Action类及其方法（特定的命名及特定的注解），将这些信息插入数据库，这样便可以将其用于授权和认证。d)在认证的时候，我们实现了两种方式的认证：i.第一是根据授权，能够把没有授权的菜单项屏蔽，也能够把没有授权的功能按钮屏蔽；ii.第二，因为第一种认证方式会有一些安全性问题，比如客户可以绕过功能按钮，直接在浏览器输入某个功能的地址，为了避免这种问题，我们在后台也做了认证，根据当前请求的是哪个类的哪个方法，编写拦截器，判断当前登录用户是否具备这个权限，如果没有这个权限，就不允许执行这个操作！e)InitService和XMLf)自定义注解，利用Springde的API扫描类（大概说出一两个类名）4、我们这个设计的优点在哪里a)因为抽象出了主体和资源这两个概念，核心的授权和认证代码依赖于这两个概念，而不是具体的哪个主体或资源。所以，能够更灵活的支持主体和资源的扩展，比如假设以后客户还想要给用户分组，按照分组来给用户授权，那么只需要实现一个新的主体类型即可，核心的授权和认证的代码无需变化。b)权限控制的粒度更细，因为我们用一个int来表示操作的允许状态，这就意味着，我们能支持在某个资源上的至多32种操作，在设计上无需做变化。一个资源上的操作一般不会超过32种操作，一般来说也就是添加、更新、删除、查询，以及在这个基础上更加细分的一些操作而已，很少会超过32种操作。即使是极端情况，超过了32种操作，那么我们的核心设计也无需变动，无非就是把int换成一个long类型即可（支持64种操作）。c)我们还能支持细粒度的操作权限继承关系：i.比如针对“公司管理”这种资源，假设它有六种操作：添加公司信息、删除公司信息、更新公司信息、查询公司信息、添加子公司、删除子公司；我们可以把这些权限授予比如“张三”这个用户。在授权的时候，我们可以细化到这种程度：1.明确规定：允许张三查询公司信息、更新公司信息2.明确规定：不允许张三添加公司信息、删除公司信息3.至于张三是否能执行添加子公司和删除子公司这些操作，我们可以不做明确规定，而是由其所拥有的角色，或其所属的部门、岗位的权限来决定，这称为“权限的继承关系”，针对这种需求，在ACL中，我们设计了一个额外的属性：a