CN100499510C - 定位故障的方法以及业务维护平台 - Google Patents

Abstract

本发明公开了一种定位故障的方法，该方法包括：接收一或多个查询的业务工单；将一或多个查询的业务工单分解为针对网元的一或多个指令工单，并将所述一或多个指令工单发送给对应的网元；根据所述网元返回的结果确定故障位置和/或故障内容。本发明还公开了一种业务维护平台。通过本发明提供的技术方案，只需要向业务维护平台提交查询的业务工单，该业务维护平台将其分解为针对网元的指令工单，并发送给对应的网元，然后可以根据网元返回的结果来确定故障位置和/或故障内容，从而实现了简单方便的故障定位技术。而且，本发明实施例提出的业务维护平台还能够用于查询、修改、终止业务工单以及设置业务工单的优先级。

Description

定位故障的方法以及业务维护平台

技术领域

本发明通信技术领域，特别是一种定位故障的方法以及一种业务维护平台。

背景技术

电信运营商业务系统，例如客户管理系统(CRM)、客户维护(CustomCare)、帐单(Billing)等业务支撑系统(BSS)/运营支撑系统(OSS)，无法避免都要或多或少地开展一些业务，需要与诸如归属位置寄存器(HLR)/鉴权中心(AuC)、无线智能网(WIN)、移动数据业务平台(MDSP)、短消息中心(SMSC)、语音邮箱系统(VMS)、多媒体信息服务中心(MMSC)、统一消息服务(UM)、下一代网络(NGN)、公共电话交换网(PSTN)等网络侧的网元(NE)存在接口，以进行业务开通(Service Provisioning)，Provisioning系统就相当于介于BSS/OSS和NE之间的接口。Provisioning系统有被称为联机指令系统的，也有被称为业务开通系统(ServiceProvisioning)的，本发明统一称之为联机指令系统。图1给出了联机指令系统的位置。

目前，电信运营商无法避免会存在CRM、Custom Care、Billing等多个BSS/OSS系统，或存着不同专网的BSS/OSS运营系统，这些系统都需要交叉开展业务，需要与网络侧的网元存在接口，如果每个BSS/OSS业务请求系统都与网元直接相连，而每个网元又存在不同特色的通信协议，那势必会形成一个庞大的网状结构，这样不仅加大了运营商BSS/OSS系统的投入成本，同时还延长了运营商支撑新业务的进度。而且，由各个BSS/OSS系统提供的网元接口功能往往非常薄弱，不利于运营商快速地推出新业务。另外，此时的网元接口可维护性较低，如果发生异常，将很难处理。

现有联机指令系统的模式如图2所示。参照图2，现有的联机指令系统一般存在以下的特点：一个网元接口对应一套独立的程序或进程，接口与接口之间相互独立，每个接口有内部独立的处理逻辑。

申请人在实际使用过程中发现，由于在现有的联机指令系统中，每个进程采用分散的方式，独立启动，独立运作，各个进程之间基本没有交互，各自处理各自网元的指令工单，所以这种联机指令系统不可能具备统一的网管、日志管理、业务工单、指令等维护管理机制，对于运营商和系统提供商来说很难维护，而且可靠性较差。

另外，上述联机指令系统也不可能具备统一的业务开通平台和业务故障处理平台，无法在该系统上直接查询、单个/批量开通、单个/批量修改各网元的业务。这就导致局方的维护人员只有逐一的登录到网元系统上进行故障处理，而在复杂的网络系统中，网元非常众多，很难逐一辨别和处理，这最终将会导致业务故障处理周期长且容易出错。例如，客户发现手机无法使用某业务，向局方报障，局方维护人员接收到障碍后，通过目前的联机指令系统根本无法进行故障定位，即查询到用户实际在网元上的开通状态，只能手工登录到网元上去查看是否故障。另外，维护人员更不能直接通过该联机指令系统进行某个业务的重新开通。

发明内容

有鉴于此，本发明实施例提出了一种定位故障的方法，用以实现简单方便的故障定位。本发明实施例还提出了一种业务维护平台。

本发明实施例提供了一种定位故障的方法，该方法包括：

接收一或多个查询的业务工单，所述业务工单包括指令工单之间的逻辑关系；

根据预先设置的数据，将所述一或多个查询的业务工单分解为一或多个指令工单，并得到所述指令工单之间的逻辑关系；

将所述分解出的一或多个指令工单转换为针对网元的一或多个指令工单，并根据所述逻辑关系将所述一或多个针对网元的指令工单发送给对应的网元；

根据所述对应的网元返回的结果确定故障位置和/或故障内容。

本发明实施例还提供了一种业务维护平台，该业务维护平台包括：

请求分解模块，用于将一或多个业务工单分解为一或多个指令工单，并分解出所述指令工单之间的逻辑关系；

请求处理模块，用于将分解后的一或多个指令工单形成队列，并提供给网元适配器；并根据所述逻辑关系将所述指令工单提供给网元适配器；

网元适配器，用于分解和解析所述一或多个指令工单并转换为针对网元的一或多个指令工单，以适配同一协议下不同网元之间的差异；

网元前置机，用于将网元适配器转换后的一或多个指令工单发送给对应的网元，并实现协议的通用适配。

通过本发明实施例中提供的定位故障的方法和业务维护平台，只需要向业务维护平台提交查询的业务工单，该业务维护平台将其分解为针对网元的指令工单，并发送给对应的网元，然后可以根据网元返回的结果来确定故障位置和/或故障内容，从而实现了简单方便的故障定位技术。而且，本发明实施例提出的业务维护平台还能够用于查询、修改、终止业务工单以及设置业务工单的优先级，并且还能够直接开通业务、直接修改业务、直接处理用户业务故障，而不需要到网元设备上处理，大大方便了操作人员的使用。由于本发明实施例具备统一、完善告警监控能力，能够统一系统维护，减少了多余的操作，从而降低了维护工作量，有利于提高系统的稳定性。

附图说明

图1为联机指令系统的位置示意图；

图2表示现有联机指令系统的模式；

图3为本发明实施例技术方案中的抽象图；

图4为本发明实施例中定位故障的流程示意图；

图5为本发明实施例中开通业务的流程示意图；

图6为本发明实施例中修改业务的流程示意图；

图7为本发明实施例中取消业务的流程示意图；

图8为本发明实施例中的系统结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，以下举实施例对本发明进一步详细说明。

为了解决现有技术中的缺陷，本发明实施例提供了完整的智能化业务配置方案，使得操作人员只需要向业务维护平台发送简单的业务工单，然后业务维护平台将业务工单分解转换为针对网元的指令工单，并将所述指令工单发送给对应的网元，然后根据网元返回的结果确定故障位置和/或故障内容。

下面具体描述本发明实施例的实现方案。

为了实现本发明实施例的技术方案，需要对业务、网元、指令等进行抽象。

图3为本发明实施例中技术方案的抽象图。

首先描述对于网元的抽象。由于网元接口很多，如果针对一个网元接口开发一套完整的定制逻辑，不仅会导致很大的人力浪费，而且成本太高。因此将网元层面细分为网元前置机层和网元适配器层。

网元前置机层是对协议的一种抽象，解决相同协议的网元连接、签到、报文发送和获取机制，比如网元前置机层可以分为套接字(Socket)MML、远程登录协议(Telnet)、文件传输协议(FPT)、点到点短消息协议(SMPP)、文件类型定义(DTD)XML over HTTP、简单对象访问协议(SOAP)1.1、SOAP1.2等等；在协议层进行同一的抽象，提供给各种采用同一协议、不同实现的网元以同一类型网元前置机。

其次是网元适配器，由于虽然采用同一种协议，但是实际报文拼接的规则、报文解析的规则、心跳机制等等差异比较大，网元适配器的存在就是适配这些差异。

经过以上两层屏蔽后，剩下的就是可以完全配置化的网元信息，其包括两部分：网元基本信息、网元指令信息。其中，网元基本信息包括网元名称、IP、端口(PORT)、登录用户名/密码、失败重发次数、是否需要签到、网元启动状态、指令发送间隔时间、指令等待响应超时时间、同步/异步方式、连接数目等等。网元指令信息包括网元的指令、指令参数、指令与参数关系、参数枚举值等等。这些网元信息可以直接与网元绑定，但是这种情况下每个网元都需要配置录入对应的相关的指令信息，因此优选地将网元信息与网元模板绑定，网元模板是对采用同一种指令集的网元的一种抽象，一个网元模板下可能存在很多个网元。另外，网元适配器与网元模板是一一对应的关系。

换言之，一个网元前置机对应多个网元适配器，网元适配器适配不同网元的差异，简明起见，在图3中只标出一个网元适配器；网元适配器与网元模板为一一对应关系，抽象具有相同指令特性的网元；一个网元模板对应多个实际网元，这些不同的网元具备不同的基本信息。这些抽象的最终目的，就是将所有指令都可配置化，新增、修改指令只需修改配置。

接着描述对业务进行抽象。首先，说明一下业务的概念，业务是提供给上级业务请求系统使用的各种操作的名称，如开户业务、开通短消息业务、关闭来电显示业务、预付费用户充值业务等等。对于网元的指令来说，是不可随意修改的，而业务是可以随意更改的，具备一定的灵活性。

业务抽象的元素包括业务、业务参数、业务参数枚举值、业务与参数之间关系、业务参数与业务参数关系等。经过抽象后，操作人员开展一个新业务，可以灵活地通过配置的方式，在业务维护平台新增一个业务，业务包含几个参数，这些参数可能存在为不同的类型，存在不同的值范围。比如IMSI参数，参数类型为NumberString类型，长度为6-15；如果参数为枚举值类型，则可以配置一下参数的枚举值；如果业务参数存在默认值，则配置一个默认值；如果业务中两个参数之间存在互斥关系，比如输入MSISDN后就不允许输入IMSI，则配置一下在该业务中两个参数之间的互斥关系。

通过上述方式，本发明实施例完成了对提供给业务请求系统的业务的配置。

基于上述基础，下面描述具体业务如何与正确的网元的指令相关联，即对业务与网元指令关系抽象。

首先，在说明业务与指令之间的抽象之前，说明一下网元类型的概念。网元类型是对网元的一种分类，或者叫网元模板的一种分类，比如HLR类型可能有爱立信HLR、诺基亚HLR、西门子HLR等，它们都隶属于同一种类型，叫HLR类型。一般来说，一种网元类型可能存在多种网元模板的网元，但一般只需要向该网元类型中的一个网元发送指令。比如开户，需要向HLR发送指令，即需要向网元类型为HLR的网元发送指令，而HLR存在着爱立信、诺基亚、西门子等多种模板的多个网元，所以实际在发送时，只需要根据一定的规则向其中的一个发送指令，而不是多个。在实际应用中，同一种网元类型的网元会划分有不同的号段，号段分为移动台国际综合业务数据网号码(MSISDN)号段和国际移动用户识别码(IMSI)号段，通过MSISDN/IMSI信息就可以匹配到正确的网元。本发明实施例也可以通过其它标识来匹配到正确的网元。

接下来，分析一下业务包括指令逻辑关系的一些场景。例如，一个开户业务存在如下的指令规则：向网元类型1、网元类型2、网元类型3并行的发送指令；发送指令全部成功后，需要向网元类型4发送指令；网元类型4指令如发送失败，则向网元类型5发送指令，发送成功则向网元类型6发送指令。

根据这样的规则，用户可以通过业务配置系统来映射业务与网元类型的关系，用来配置业务与这6种网元类型之间的关系以及这6种网元类型指令之间的逻辑关系。

在配置完与网元类型的映射关系后，用户还可以根据系统提供的配置业务与具体网元模板指令映射关系的界面，来配置业务与某个具体模板指令的映射关系。同时允许这样的场景，比如：并行发送指令1、指令2，如果其中任何一个失败，则终止执行；指令1、指令2成功后，发送指令3，指令3如果执行成功，则对应该网元模板的指令执行结束，如果失败，则发送指令4、指令5回滚指令1、指令2的操作。实际的配置还可以更复杂，可以引入条件指令，即当业务参数的参数值为A时，发送指令1，为B时，发送指令2。另外，还可以允许这样的方式，指令2的执行，需要从指令1执行的返回结果中取值，取值后赋给指令2的某个参数，进行发送，这种情况可以成为交互指令。

在能够配置业务与指令关系基础上，本发明实施例还能配置业务参数与指令参数的关系，能够让业务参数的值赋给指令参数。当然，对于业务参数枚举值，也可以配置与指令参数枚举值之间的关系，形成不同的映射关系。

通过以上三点的抽象，使得用户在新增业务时，可以智能的配置业务，灵活的设置回滚、条件、交互、并行、串行等逻辑，使得新增业务变成了一种具备友好操作界面的配置性操作，从而向操作人员提供了简单的业务开通模式，降低了对操作人员专业知识的要求。

当然，为了具备良好的可操作性，业务配置还会提供给用户被配置业务的校验功能，由系统自动校验配置业务工单的正确性，避免错误配置。例如，通过处理一个业务请求，判断根据该业务请求所完成的配置能否正确实现该业务请求的目的，从而校验其正确性。

另外，本发明实施例还进一步对业务请求系统进行抽象，从而可以对于业务请求系统的业务权限、号段权限、接入方式、接入IP限制进行管理，同时还可自动设置某个业务参数对应到该业务请求系统的默认值，使得业务请求系统在发请求时尽量减少参数的填写，由业务维护平台对各种复杂参数进行屏蔽，达到只需要填写MSISDN和/或IMSI就能开通业务的程度。

对于统一的业务维护平台要基于灵活的、智能化的业务配置，其具体实现如下：

首先是对于业务请求抽象化。对于所有业务请求系统下发的业务请求，对应为一条业务工单，业务工单中包含业务工单序列号、业务码(Code)、参数值列表(List)、优先级、当前状态、下发时间、执行时间、完成时间、业务工单处理返回码、返回结果信息等信息。业务工单标识一个业务请求。

其次，对于指令请求抽象化。对于所有实际发送到网元的一条指令，对应为一条指令工单，指令工单对应为业务工单分解后得到的实际发送到网元的指令。指令工单包含业务工单序列号、指令序号、指令标识(ID)、网元类型ID、网元模板ID、网元ID、宏指令格式、实际指令等等。其中，宏指令格式实际为一种“参数1＝值1，参数2＝值2，...”的格式，是业务工单在分解后将业务参数的值逐个的赋给指令参数，同时提供给网元适配器进行实际指令的拼接。

下面描述业务工单的提交。如上所述，所有的业务都是配置的业务，那么业务维护平台根据这些配置，可以自动化生成一个页面，页面中列出该业务的所有参数，同时载入参数值的类型、范围及参数与参数之间的各种关系，包括互斥、依赖等等，比如输入A参数，则不允许输入B参数，B参数自动被禁止掉，又比如输入C参数，D参数的值自动根据C的值进行计算，从而自动获取D参数的值等等。

在输入参数时，可以自动提醒该参数的相关信息，可以预览发送的业务工单、指令工单；通过这种方式，可以提交业务工单，在转化为指令工单后，发送到任何网元上，进行业务的开通、修改、取消，业务的查询，在业务请求处理结束后，可以同步的获取请求的执行结果，处理各种网元的用户故障。

使用该功能，在不使用网元客户端登录到网元的情况下，用户可以开通任何网元接口能够支持的业务，对于维护人员来说节省了大量的时间，特别是各种不同的网元对应不同的客户端、网元个数比较多时。另外，该功能可以屏蔽了很多网元指令繁琐的参数配置，可操作性较佳。

接着描述指令请求的发送。与业务工单类似，对于指令同样也都是配置的业务，根据这些配置，也可以自动化生成一个开通的界面，进行指令工单的单独发送，这样可以单个的发送任何网元的任何指令到网元，而不必像业务工单一样，在配置业务之后才能下发请求。

最后描述业务请求指令请求监控。在能下发的基础上，系统同时还需基本控制的能力，具体可包括可以查询到各种业务工单、指令工单，其查询条件可以任意组合化；可以终止业务工单、指令工单，可以单个提交、批量提交业务工单、指令工单，可以重新设置业务工单、指令工单的优先级，当然也可以看到业务工单的详细信息以及指令工单的详细信息。

根据上述设置，本发明实施例中从业务请求系统提交业务工单到最终定位故障的过程如图4所示。

参照图4，本发明实施例中定位故障的方法包括以下步骤：

步骤101，运营商需要进行故障定位，操作人员通过诸如BOSS等业务请求系统登录到业务维护平台，并提交查询的业务工单。

本发明实施例中的业务维护平台可以提供包括文件接口、Java应用程序接口(API)、socket MML接口、数据库接口、会话描述协议(SDP)接口、远程登录Telnet接口等的请求接口。

步骤102，业务维护平台检查登录的用户名、密码、IP地址是否正确，如果正确，则执行步骤103及其后续步骤；否则拒绝当前的登录，业务维护平台还可以进一步提示用户重新登录。

步骤103，业务维护平台根据已定义的格式，检查来自业务请求系统的业务工单的格式是否正确，如果正确，则执行步骤104及其后续步骤；否则停止当前业务工单，并可以进一步提示用户重新提交业务工单。

步骤104，业务维护平台根据业务请求系统与业务的关系，检查业务请求系统是否具有该业务的权限，如果有，则执行步骤105及其后续步骤；否则停止当前业务工单，并可以进一步提示用户。

步骤105，业务维护平台根据业务工单中所包含的号码段，检查业务请求系统是否具有号码权限，如果有，则执行步骤106及其后续步骤；否则停止当前业务工单，并可以进一步提示用户。

上述步骤102至步骤105为对业务请求系统进行鉴权的过程，虽然这里只给了上述几种鉴权内容，但是本发明实施例的保护范围并不局限于此，另外，上述步骤102至步骤105的先后次序也可以任意变换。

步骤106，业务维护平台根据预先设置的数据，将业务工单分解为指令工单。

进一步，如果所述业务工单包括指令工单之间的逻辑关系，那么在分解过程中会得到该逻辑关系。

步骤107，业务维护平台通过网元适配器将分解出的指令工单转换为针对网元的指令工单，并向对应的网元发送指令工单，并等待网元的响应，即处理结果。

本步骤中的转换主要包括：根据业务与不同类型网元的关系，将分解出的指令工单转换为针对不同类型网元的指令工单，然后根据同一类型网元中的具体网元即网元模板以及指令的参数，将针对该类型网元的指令工单转换为针对所述网元的指令工单。

进一步，如果存在指令工单之间的逻辑关系，那么业务维护平台将进一步根据所述逻辑关系将指令工单发送给对应的网元。

步骤108，根据返回的结果判断故障位置、和/或确定故障内容。

这样，通过本实施例就能够简单方便地实现故障定位，而不需要操作人员到网元设备上去处理，极大地方便了操作人员的使用，降低了维护工作量。

在定位故障之后，可以根据故障位置和故障内容，形成更改后的开通的业务工单或者形成新的开通的业务工单，然后重新开通业务，从而解决故障。图5为开通业务的流程示意图。参照图5，该流程包括以下步骤：

步骤201，操作人员通过诸如BOSS等业务请求系统登录到业务维护平台，并发送开通的业务工单。

步骤202，业务维护平台根据预先设置的数据，将业务工单分解为指令工单。此时，业务维护平台可以对业务请求系统进行鉴权，也可以不进行鉴权。

进一步，如果所述业务工单包括指令工单之间的逻辑关系，那么在分解过程中会得到该逻辑关系。

步骤203，业务维护平台通过网元适配器将分解出的指令工单转换为针对网元的指令工单，并向对应的网元发送指令工单。

本步骤中的转换主要包括：根据业务与不同类型网元的关系，将分解出的指令工单转换为针对不同类型网元的指令工单，然后根据同一类型网元中的具体网元即网元模板以及指令的参数，将针对该类型网元的指令工单转换为针对所述网元的指令工单。

进一步，如果存在指令工单之间的逻辑关系，那么业务维护平台将进一步根据所述逻辑关系将指令工单发送给对应的网元。

在上述流程中发送指令工单之后，业务维护平台还可以进一步校验所述业务工单是否正确，例如对所要实现的业务进行模拟测试。如果正确，则返回给业务请求系统；否则，将不正确的信息返回给业务请求系统。

在定位了故障之后，也可以根据故障位置和故障内容，形成修改的业务工单，然后修改业务，从而解决故障。图6为修改业务的流程示意图。参照图6，该流程包括以下步骤：

步骤301，操作人员通过诸如BOSS等业务请求系统登录到业务维护平台，并发送修改的业务工单。

步骤302，业务维护平台根据预先设置的数据，将业务工单分解为指令工单。此时，业务维护平台可以对业务请求系统进行鉴权，也可以不进行鉴权。

进一步，如果所述业务工单包括指令工单之间的逻辑关系，那么在分解过程中会得到该逻辑关系。

步骤303，业务维护平台通过网元适配器将分解出的指令工单转换为针对网元的指令工单，并向对应的网元发送指令工单。

本步骤中的转换主要包括：根据业务与不同类型网元的关系，将分解出的指令工单转换为针对不同类型网元的指令工单，然后根据同一类型网元中的具体网元即网元模板以及指令的参数，将针对该类型网元的指令工单转换为针对所述网元的指令工单。

进一步，如果存在指令工单之间的逻辑关系，那么业务维护平台将进一步根据所述逻辑关系将指令工单发送给对应的网元。

在上述流程中发送指令工单之后，业务维护平台还可以进一步校验所述业务工单是否正确，例如对所要实现的业务进行模拟测试。如果正确，则返回给业务请求系统；否则，将不正确的信息返回给业务请求系统。

在定位了故障之后，还可以根据故障位置和内容，形成取消的业务工单，然后取消业务，从而解决故障。图7为取消业务的流程示意图。参照图7，该流程包括以下步骤：

步骤301，操作人员通过诸如BOSS等业务请求系统登录到业务维护平台，并发送取消的业务工单。

步骤302，业务维护平台根据预先设置的数据，将业务工单分解为指令工单。此时，业务维护平台可以对业务请求系统进行鉴权，也可以不进行鉴权。

进一步，如果所述业务工单包括指令工单之间的逻辑关系，那么在分解过程中会得到该逻辑关系。

步骤303，业务维护平台通过网元适配器将分解出的指令工单转换为针对网元的指令工单，并向对应的网元发送指令工单。

本步骤中的转换主要包括：根据业务与不同类型网元的关系，将分解出的指令工单转换为针对不同类型网元的指令工单，然后根据同一类型网元中的具体网元即网元模板以及指令的参数，将针对该类型网元的指令工单转换为针对所述网元的指令工单。

进一步，如果存在指令工单之间的逻辑关系，那么业务维护平台将进一步根据所述逻辑关系将指令工单发送给对应的网元。

在上述流程中发送指令工单之后，业务维护平台还可以进一步校验所述业务工单是否正确，例如对所要实现的业务进行模拟测试。如果正确，则返回给业务请求系统；否则，将不正确的信息返回给业务请求系统。

图8为本发明实施例中业务维护平台的结构示意图。

如图8所示业务维护平台至少包括请求分解模块、网元适配器以及网元前置机，还可以进一步包括请求接口模块、请求鉴权模块、请求处理模块等。

其中，请求分解模块将业务工单分解为各个指令工单，并将指令工单发送给网元适配器。网元适配器分解、解析所述指令工单，并转换为针对网元的指令工单，从而适配同一协议下不同网元之间的差异。网元前置机则将网元适配器转换后的指令工单发送给对应的网元，并实现协议的通用适配。

另外，如果提交的是指令工单，那么请求分解模块通过网元适配器将所述指令工单发送给网元前置机，网元前置机将指令工单发送给对应的网元。

业务维护平台还进一步包括请求处理模块，该请求处理模块将分解后的指令工单形成队列，并提供给网元适配器。进一步，如果请求分解模块还分解出指令工单之间的逻辑关系，那么请求处理模块根据该逻辑关系，将指令工单提供给网元适配器。请求处理模块还可以将网元的处理结果回写到指令工单和/或业务工单中，以及将所述处理结果返回给业务请求系统。该请求处理模块还能够查询、终止所述业务工单、指令公担，以及设置所述业务工单、指令工单的优先级。

业务维护平台还进一步包括请求接口模块。该请求接口模块用于接收来自业务请求系统的业务工单。根据需要，该请求接口模块可以包括：文件接口、Java应用程序接口(API)、socket MML接口、数据库接口、SDP接口、Telnet接口等等。各种接口用于接收相应渠道的业务工单。例如：数据库接口接收数据库渠道的业务工单，Telnet接口接收Telnet渠道的业务工单。

进一步，业务维护平台还可以包括请求鉴权模块，该请求鉴权模块用于对业务请求系统进行鉴权。根据需要，请求鉴权模块可以包括：用于检查登录的用户名、密码和/或IP地址的第一检查单元；用于检查所述业务工单的格式是否正确的第二检查单元；用于检查业务请求系统的业务权限的第三检查单元；用于检查业务请求系统的号码权限的第四检查单元，等等。

继续参考图8，图8中还画出了业务请求系统以及网元。由于篇幅所限，图8中的业务请求系统只例示了帐单&客户维护系统、CRM系统、网络自维护(Web self-care)系统，网元也只例示了HLR、VMS、AAA、IN等。但是，本领域的普通技术人员显然可以看出，本发明实施例并不局限于所例示的内容。

操作人员只需要向本实施例中的业务维护平台提交查询的业务工单，该业务维护平台将其分解为针对网元的指令工单，并发送给对应的网元，然后可以根据网元返回的结果来确定故障位置和/或故障内容，从而实现了简单方便的故障定位技术，而不需要操作人员到网元设备上去处理，极大地方便了操作人员的使用，降低了维护工作量。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (17)

1、一种定位故障的方法，其特征在于，该方法包括：

接收一或多个查询的业务工单，所述业务工单包括指令工单之间的逻辑关系；

根据预先设置的数据，将所述一或多个查询的业务工单分解为一或多个指令工单，并得到所述指令工单之间的逻辑关系；

将所述分解出的一或多个指令工单转换为针对网元的一或多个指令工单，并根据所述逻辑关系将所述一或多个针对网元的指令工单发送给对应的网元；

根据所述对应的网元返回的结果确定故障位置和/或故障内容。

2、根据权利要求1所述的方法，其特征在于，在所述接收一或多个查询的业务工单之后，根据预先设置的数据，将所述一或多个查询的业务工单分解为一或多个指令工单之前，该方法进一步包括对提交所述一或多个查询的业务工单的业务请求系统进行鉴权的步骤。

3、根据权利要求2所述的方法，其特征在于，所述对业务请求系统进行鉴权的步骤包括：

检查登录的用户名、密码和/或IP地址；和/或

检查所述一或多个查询的业务工单的格式是否正确；和/或

检查业务请求系统的业务权限；和/或

检查业务请求系统的号码权限。

4、根据权利要求2所述的方法，其特征在于，所述对业务请求系统进行鉴权的步骤包括：根据所述一或多个查询的业务工单中的移动台国际综合业务数据网号码MSISDN和/或国际移动用户识别码IMSI，检查业务请求系统的号码权限。

5、根据权利要求1所述的方法，其特征在于，该方法进一步包括：

根据故障位置和/或故障内容，修复所述故障。

6、根据权利要求1所述的方法，其特征在于，该方法进一步包括：

接收根据所述故障位置和/或故障内容生成的一或多个更正后的开通的业务工单，将所述一或多个开通的业务工单分解为针对网元的一或多个指令工单，并将所述一或多个指令工单发送给对应的网元；和/或

接收根据所述故障位置和/或故障内容生成的一或多个修改的业务工单，将所述一或多个修改的业务工单分解为针对网元的一或多个指令工单，并将所述一或多个指令工单发送给对应的网元；和/或

接收根据所述故障位置和/或故障内容生成的一或多个取消的业务工单，将所述一或多个取消的业务工单分解为针对网元的一或多个指令工单，并将所述一或多个指令工单发送给对应的网元。

7、根据权利要求1或6所述的方法，其特征在于，该方法进一步包括：

查询所述一或多个业务工单；和/或

终止所述一或多个业务工单；和/或

设置所述一或多个业务工单的优先级。

8、根据权利要求1所述的方法，其特征在于，该方法进一步包括：

向业务维护平台提交一或多个指令工单；

业务维护平台将所述一或多个指令工单发送给对应的网元。

9、根据权利要求8所述的方法，其特征在于，该方法进一步包括：

查询所述一或多个指令工单；和/或

终止所述一或多个指令工单；和/或

设置所述一或多个指令工单的优先级。

10、一种业务维护平台，其特征在于，该业务维护平台包括：

请求分解模块，用于将一或多个业务工单分解为一或多个指令工单，并分解出所述指令工单之间的逻辑关系；

请求处理模块，用于将分解后的一或多个指令工单形成队列，并提供给网元适配器；并根据所述逻辑关系将所述指令工单提供给网元适配器；

网元适配器，用于分解和解析所述一或多个指令工单并转换为针对网元的一或多个指令工单，以适配同一协议下不同网元之间的差异；

网元前置机，用于将网元适配器转换后的一或多个指令工单发送给对应的网元，并实现协议的通用适配。

11、根据权利要求10所述的业务维护平台，其特征在于，该业务维护平台进一步包括：

请求接口模块，用于接收来自业务请求系统的一或多个业务工单，并转发给所述请求分解模块。

12、根据权利要求11所述的业务维护平台，其特征在于，所述请求接口模块包括：文件接口和/或Java应用程序接口API和/或套接字模块管理语言MML接口和/或数据库接口和/或会话描述协议SDP接口和/或远程登录Te1net接口。

13、根据权利要求10所述的业务维护平台，其特征在于，该业务维护平台进一步包括：

请求鉴权模块，用于对提交所述一或多个业务工单的业务请求系统进行鉴权。

14、根据权利要求13所述的业务维护平台，其特征在于，所述请求鉴权模块包括：

第一检查单元，用于检查登录的用户名、密码和/或IP地址；和/或

第二检查单元，用于检查所述一或多个业务工单的格式是否正确；和/或

第三检查单元，用于检查业务请求系统的业务权限；和/或

第四检查单元，用于检查业务请求系统的号码权限。

15、根据权利要求10所述的业务维护平台，其特征在于，所述请求处理模块进一步用于查询所述一或多个业务工单和/或终止所述一或多个业务工单和/或设置所述一或多个业务工单的优先级。

16、根据权利要求10所述的业务维护平台，其特征在于，所述请求分解模块进一步用于将分解得到的一或多个指令工单通过网元适配器发送给网元前置机。

17、根据权利要求16所述的业务维护平台，其特征在于，该业务维护平台进一步包括业务处理模块，该业务处理模块用于查询所述一或多个指令工单和/或终止所述一或多个指令工单和/或设置所述一或多个指令工单的优先级。

Images