NOKIA优化项目总结

优化项目行将结束,为了以后工程的顺利开展,也为了项目组成员技能的提高,现总结如下。为了便于总结，分别从终端操作，report运行，操作命令，参数调整，提取数据几个方面予以描述。

1 NOKIA终端操作

1．1 使用工具:

由于NOKIA OMC_R不是图形化界面，故要使用reflection软件登陆OMC终端，提取报告，查参数，告警等，当然也可以使用telnet,x-manager等终端工具，通过工程实践证明reflection是最佳工具。

1．2 操作界面

进入OMC后，可以通过不同的操作进入不同的操作界面，执行不同的任务：

BSC操作界面

1．－通过reflection下的reflection for UNIX and Digital子菜单等陆；

－输入用户名：planner

－输入密码：xxxxx(登陆后首先进入的是UNIX界面，可以使用UNIX操作命令，如tar,vi等)

以上是REFLECTION登陆步骤，进入任何操作界面前都必须经过以上步骤。下面的操作步骤对于进入BSC界面，报告界面，SQL界面是不同的。

－键入命令：neman.sh

－选择不同的BSC

－用户名：xxxx 密码：xxxx （至此，便进如BSC操作界面—MAIN LEVEL COMMAND）

－进入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显示

以上命令的具体内容请参阅NED

4.参数调整

总体来看，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数据库的原始表格结构和表格列（COLUMN NAME）的完整名称需要了解清楚，才有能力进行SQL编程。

9、 对容量方面的规划、预测、计算等，在NOKIA，优化和CELL PLAN是不分开的，需要同时具备这两方面的能力，甚至和无线相关的MSC方面的一些问题都需要涉及，比如：寻呼量、LAC下用户数、相关话务量、MOC、MTC比例、A接口容量计算、扩容、割接计划、LAC规划和调整、MSC、Gb的负荷、CPU负荷等等。这方面的问题我们在现场也是遇到一个学习和分析一个。

10、 对无线传播理论的学习和了解。由于NOKIA优化和PLAN没有分开，因此对无线传播理论和计算方法等方面的要求比较高，要求要具备一定程度的室内、市外覆盖预测能力和链路预算估算能力，对于频率规划方案的了解和分配等等。

11、 其他方面：ACCESS、EXCEL、MAPINFO应用能力需要具备。

谢 谢

 

第二篇：OA项目总结

组织机构管理模块

请描述一下你做的组织机构管理模块

描述思路：

1、 组织机构模块的基本需求

a) 本模块主要管理公司、子公司、部门、岗位、员工的信息

b) 公司下面可以创建子公司、部门

c) 部门下面可以创建子部门、岗位或员工

d) 岗位下面可以创建员工（即员工可以属于某个岗位）

e) 公司、部门、岗位、员工形成一棵组织机构树，要求使用树型方式来展现和管理

2、 组织机构的总体设计思路

a) 公司、部门、岗位、员工可以看成同一种类型：Party

b) 在Party上实现树型结构（父子关系）

c) 其它类型：公司、部门、岗位、员工均继承Party（请画出类图）

3、 组织机构的实现技巧

a) 利用jQuery的jsTree实现组织机构树

b) 利用jQuery的treeTable实现列表（AJAX、查询、分页）

c) 在组织机构树中显示公司、部门、岗位的信息，点击公司、部门、岗位，则可以显示其详细信息，及其下面的所有员工（利用hibernate filter避免在树上显示员工信息）

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和XML

f) 自定义注解，利用Springde的API扫描类（大概说出一两个类名）

4、 我们这个设计的优点在哪里

a) 因为抽象出了主体和资源这两个概念，核心的授权和认证代码依赖于这两个概念，

而不是具体的哪个主体或资源。所以，能够更灵活的支持主体和资源的扩展，比如假设以后客户还想要给用户分组，按照分组来给用户授权，那么只需要实现一个新的主体类型即可，核心的授权和认证的代码无需变化。

b) 权限控制的粒度更细，因为我们用一个int来表示操作的允许状态，这就意味着，

我们能支持在某个资源上的至多32种操作，在设计上无需做变化。一个资源上的操作一般不会超过32种操作，一般来说也就是添加、更新、删除、查询，以及在这个基础上更加细分的一些操作而已，很少会超过32种操作。即使是极端情况，超过了32种操作，那么我们的核心设计也无需变动，无非就是把int换成一个long类型即可（支持64种操作）。

c) 我们还能支持细粒度的操作权限继承关系：

i. 比如针对“公司管理”这种资源，假设它有六种操作：添加公司信息、删除公

司信息、更新公司信息、查询公司信息、添加子公司、删除子公司；我们可以把这些权限授予比如“张三”这个用户。在授权的时候，我们可以细化到这种程度：

1. 明确规定：允许张三查询公司信息、更新公司信息

2. 明确规定：不允许张三添加公司信息、删除公司信息

3. 至于张三是否能执行添加子公司和删除子公司这些操作，我们可以不做明

确规定，而是由其所拥有的角色，或其所属的部门、岗位的权限来决定，

这称为“权限的继承关系”，针对这种需求，在ACL中，我们设计了一个

额外的属性：aclTriState，用来表示某种操作的权限是否是继承下来的。

5、 我们这个设计的缺点在哪里

a) 角色之间没有考虑父子关系，如果考虑父子关系的话，会更加便于授权，比如假设

有一个角色为“普通员工”，另外一个角色是“档案管理员”，如果把普通员工看成

是档案管理员的父角色，则意味着档案管理员这个角色的权限将可以继承普通员工中的权限（为什么没有实现这个设计呢，客户认为没有必要，因为系统中的角色数量比较少，如果这样设计的话，反而会增加客户操作的难度，无需过度设计） b) 我们还没有实现更细粒度的数据级的权限控制，比如，我们目前通过权限控制系统

无法实现如下需求：规定张三可以查看所有部门的员工信息，但只能对本部门的员工信息执行添加、删除和修改操作。没有实现的原因是：客户目前这方面的需求还不是很多，因此，没有必要在权限控制系统中实现。实现上述需求，我们是将这些逻辑写到了具体的代码中，而没有通过权限控制系统进行统一的定义。这也是大部分权限控制系统的实现策略。

工作流模块

请描述一下你做的工作流模块

描述思路：

1、 工作流模块的基本需求

a) 请描述

2、 工作流模块的总体设计思路

a) 把JBPM嵌入OA系统（如何实施的？具体过程？大概有哪些配置？）

b) 表单管理、流程管理、WorkEntity、WorkApprove、EntityProperty（动态表单）

3、 工作流模块的实现技巧

a) 引入jbpmeditor之后，对它做了一些定制开发（支持中文，动态表单的关联） b) 其它？

4、 我们这个设计的优点在哪里

a) 对JBPM的扩展

i. 自定义JBPM变量解释器

ii. 可以给角色、部门、岗位分配任务，抛弃了JBPM中简单的User-Group这种

组织结构模型，使用了OA中的组织结构模型

iii. 实现了自由流（如何实现的？）

iv. 利用自定义节点实现了会签的决策（如何实现的？）

b) 动态表单设计方案

5、 我们这个设计的缺点在哪里

a) 在流程定义的界面上，没有实现会签节点的定义

b) 在动态表单设计界面上，无法直接添加一些动态的组件（比如无法通过拖拽的方式

添加一个人员列表等等）

c) 没有实现流程的监控