CN100372420C

CN100372420C - 一种用户呼叫故障检测方法

Info

Publication number: CN100372420C
Application number: CNB2005101259480A
Authority: CN
Inventors: 李硕
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2005-11-28
Filing date: 2005-11-28
Publication date: 2008-02-27
Anticipated expiration: 2025-11-28
Also published as: CN1852542A

Abstract

本发明提供一种用户呼叫故障检测方法，其关键在于，当移动用户呼叫发生故障时，网关通用分组无线业务支持节点(GGSN)发送呼叫应答消息后，将确定并输出包含呼叫失败原因的基本信息。当服务通用分组无线业务支持节点(SGSN)向GGSN发送呼叫消息时，GGSN将按照协议要求执行呼叫流程，并在执行过程中可导致呼叫失败的地方判断是否成功处理，如果是，则继续处理呼叫消息，直至GGSN向SGSN发送呼叫应答消息，GGSN再结束呼叫处理过程；否则GGSN向SGSN发送呼叫应答消息后，确定并记录包含呼叫失败原因的基本信息，再将基本信息输出给网络管理中心；网络管理中心得到基本信息以后，可以准确地判断出用户呼叫失败的原因，并可以根据呼叫失败原因对网络进行有效地维护。

Description

一种用户呼叫故障检测方法

技术领域

本发明涉及移动通讯技术，特别是涉及一种用户呼叫故障检测方法。

背景技术

宽带码分多址(WCDMA，Wideband Code Division Multiple Access)是一种第三代移动通信的国际标准，也是最早投入商用的第三代移动通信***。在实际应用中，由于通用移动通信***(UMTS)采用了WCDMA空中接口技术，通常也被称为WCDMA通信***。

图1是一个典型的UMTS通信***结构图。如图1所示，UMTS包括：

用户设备(UE，User Equipment)，用于通过空中接口发起呼叫和接收呼叫。

陆地无线接入网(UTRAN，UMTS Terrestrial Radio Access Network)，用于处理所有与无线有关功能的业务。陆地无线接入网一般包括：无线网络子***(Radio Network Subsystem，RNS)和基站节点(NodeB，Node Base Station)。其中，RNS用于负责分配和控制与之相连或相关的NodeB资源，主要完成连接建立、断开、切换、宏分集合并、无线资源管理等功能；NodeB用于负责完成接口之间的数据流的转换。

核心网(CN，Core Net)，用于负责处理UMTS***内所有的话音呼叫和数据连接，并实现与外部网络的交换和路由功能。CN从逻辑又可以分为电路交换域(CS，Circuit Switching)和分组交换域(PS，Packet Switching)。其中，CS域提供电路型业务，连接公共交换电话网(PSTN)等电路交换网络；而PS域提供分组数据业务，连接Internet等外公众数据网(PDN，Public DataNetwork)。

其中，核心网的CS域包括移动交换中心(MSC，Mobile Switching Center)和网关移动业务交换中心(GMSC，Gateway Mobile Switching Center)，MSC主要提供UTRAN的CS域接入功能，包括电路域的呼叫、接续、移动性管理、鉴权和加密等；GMSC主要充当移动网和固定网之间的移动关口局，完成PSTN用户呼移动用户时呼入呼叫的路由功能，承担路由分析、网间接续、网间结算等重要功能，同时也完成移动呼叫本地固定的话路汇接功能。

核心网的PS域包括服务通用分组无线业务支持节点(SGSN，Serving GPRSSupport Node)和网关通用分组无线业务支持节点(GGSN，Gateway GPRSSupportNode)，SGSN和RNC之间通过Iu接口连接，SGSN和GGSN之间通过Gn接口连接，GGSN与Internet通过Gi接口连接。SGSN负责完成位置管理、移动型管理和隧道管理等功能。GGSN提供数据包在UMTS网和外部数据网之间的路由和封装，主要完成用户鉴权、IP地址分配、UMTS会话管理等。

按照协议规定，当用户访问PDN外部网络时，首先由UE在GGSN上发起激活流程，当GGSN成功地处理为该用户建立PDP上下文、用户鉴权、创建信令路径、分配IP地址等一系列协议规定的过程后，用户就可以访问外部网络；当用户业务质量(QOS，Quality of Service)、流量模板(TFT，Traffic FlowTemplate)等发生改变或者路由区更新时，则发起PDP上下文更新流程；当用户停止访问PDN外部网络时，则发起PDP上下文去活流程用于拆除已经被激活的PDP上下文。

如图2所示，***发起激活流程的方法是：UE向SGSN发送激活PDP上下文请求消息；SGSN向GGSN发送创建PDP上下文请求消息；GGSN按照协议规定对消息进行处理，执行激活流程后，GGSN再向SGSN发送创建PDP上下文应答消息；如果激活成功，SGSN将激活接收消息发送给用户设备，否则，SGSN将激活拒绝消息发送给用户设备。

***发起更新流程的方法是：当用户业务质量、流量模板发生改变或者路由区更新时，SGSN按照协议规定向GGSN发送更新PDP上下文请求消息；GGSN对消息进行处理，执行更新流程后，GGSN再向SGSN发送更新PDP上下文应答消息。

***发起去活流程的方法是：UE向SGSN发送PDP上下文去活请求消息；SGSN向GGSN发送删除PDP上下文请求消息；GGSN按照协议对该消息进行处理，执行去活流程后，GGSN向SGSN发送删除PDP上下文应答消息；SGSN再向UE发送PDP上下文去活应答消息。

GGSN在执行激活、更新和去活流程时，可能会由于不正常情况发生而导致用户呼叫失败。不正常情况发生的原因有很多，比如：用户鉴权不成功，没有IP地址可用，用户呼叫报文格式错误等等。但是，3GPP的协议对GGSN如何对用户呼叫故障进行检测并没有相应的标准，而如何准确地检测出用户呼叫故障的原因，是网络管理中心采取相应的措施进行网络维护的重要基础，也是运营商提供优质服务的基本保障。

在现有技术中，检测用户呼叫故障的方法主要是全网信令检测方法。全网信令检测方法的基本原理是：在***中所有的标准协议接口中都设置一个信令跟踪仪器，信令跟踪仪器实时跟踪呼叫过程中的标准协议消息，并将这些消息发送给网络管理中心，然后网络管理中心通过对这些捕获的消息进行人工分析，得到检测结果。

全网信令检测方法的缺点是：由于信令跟踪仪器捕获呼叫过程中的标准协议消息后，并不会对该消息作任何的改变，而是直接输出给网络管理中心。当用户呼叫失败时，被捕获的消息只包括标准协议所要求携带的内容，而没有准确的失败原因，网络管理中心很难从消息中直接判断出准确的失败原因，从而降低了网络维护的效率。

由此可见，在现有技术中，当用户呼叫失败时，还没有一种由GGSN直接检测出用户呼叫故障准确原因的方法。

发明内容

有鉴于此，本发明的主要目的在于提供一种用户呼叫故障检测方法，能在用户呼叫失败时，由GGSN直接检测出用户呼叫故障的准确原因。

为了达到上述目的，本发明提出的技术方案为：

一种用户呼叫故障检测方法，当网关通用分组无线业务支持节点GGSN接收到服务通用分组无线业务支持节点SGSN发送的呼叫消息时，该方法包括以下步骤：

a、GGSN处理呼叫消息，并在处理过程中的可导致呼叫失败点判断是否成功处理，如果是，则继续处理呼叫消息，直至GGSN向SGSN发送呼叫应答消息，GGSN再结束呼叫处理过程；否则，执行步骤b；

b、GGSN向SGSN发送呼叫应答消息，确定并记录呼叫消息的基本信息，再输出基本信息，所述基本信息为包含呼叫失败原因的信息。

较佳地，所述步骤a之前进一步包括：GGSN确定呼叫流程的关键点；

步骤a所述GGSN处理呼叫消息的方法为：GGSN按照协议要求对呼叫消息进行处理，并在每个关键点之后生成打点信息，并记录下打点信息，所述打点信息是对呼叫流程中关键点执行情况描述的信息；

步骤b所述输出基本信息之后进一步包括：输出打点信息。

较佳地，所述生成打点信息的方法为：GGSN直接将预设的字符串作为打点信息；或者，

GGSN将预设的字符串和执行关键点后得到的参数作为打点信息。

较佳地，所述GGSN确定呼叫流程的关键点和步骤a之间进一步包括：GGSN为接收到的呼叫消息创建呼叫日志；

步骤a所述记录下打点信息的方法为：GGSN将打点信息记录在呼叫日志中；

步骤a所述直至GGSN向SGSN发送呼叫应答消息和GGSN结束呼叫处理过程之间进一步包括：GGSN删除当前接收到的呼叫消息的呼叫日志；

步骤b所述记录呼叫消息的基本信息的方法为：将呼叫消息的基本信息记录在呼叫日志中；

步骤b所述GGSN输出基本信息和输出打点信息的方法为：GGSN输出呼叫日志；

步骤b所述输出打点信息之后进一步包括：GGSN删除呼叫日志。

较佳地，步骤b所述GGSN输出呼叫日志的方法为：GGSN将呼叫日志输出给GGSN本地终端；

步骤b所述GGSN删除呼叫日志之后进一步包括：网络管理中心向GGSN本地终端发送请求消息，再由GGSN本地终端将呼叫日志传输给网络管理中心。

较佳地，步骤b所述GGSN输出呼叫日志的方法为：GGSN将呼叫日志直接输出给网络管理中心。

较佳地，步骤b所述确定基本信息的方法为：GGSN直接根据呼叫消息内容和呼叫流程执行情况来确定基本信息；或者，

根据在GGSN创建的上下文内容和呼叫流程执行情况来确定基本信息。

较佳地，所述呼叫消息为创建PDP上下文请求消息，所述呼叫流程为激活流程；或者，

所述呼叫消息为更新PDP上下文请求消息，所述呼叫流程为更新流程；或者，

所述呼叫消息为删除PDP上下文请求消息，所述呼叫流程为去活流程。

较佳地，所述GGSN为接收到的呼叫消息创建呼叫日志和步骤a之间进一步包括：GGSN判断接收到的呼叫消息的类型，

如果呼叫消息为创建PDP上下文请求消息，所述GGSN按照协议要求对呼叫消息进行处理的方法为：GGSN按照协议要求执行激活流程；所述呼叫应答消息为创建PDP上下文应答消息；

如果呼叫消息为更新PDP上下文请求消息，所述GGSN按照协议要求对呼叫消息进行处理的方法为：GGSN按照协议要求执行更新流程；所述呼叫应答消息为更新PDP上下文应答消息；

如果呼叫消息为删除PDP上下文请求消息，所述GGSN按照协议要求对呼叫消息进行处理的方法为：GGSN按照协议要求执行去活流程；所述呼叫应答消息为删除PDP上下文应答消息。

较佳地，步骤b所述基本信息包括：业务类型、国际移动用户识别码、移动台国际ISDN号码、呼叫建立时间、用户IP地址、SGSN信令面IP地址、SGSN数据面IP地址、计费标识、PDP上下文索引、PDP上下文类型、接入点名称、用户呼叫失败原因。

综上所述，本发明提出的一种用户呼叫故障检测方法具有以下优点：由于GGSN在处理呼叫消息时，在处理过程中可导致呼叫失败点都判断是否成功处理呼叫消息，并在处理呼叫消息失败时输出包含呼叫失败原因的基本信息，所以，当用户呼叫发生故障时，GGSN必定能输出包含呼叫失败原因的基本信息，可以实现由GGSN直接检测出用户呼叫故障准确原因的方法。

附图说明

图1是典型的实现用户呼叫的通用移动通信***结构图；

图2是典型的实现用户呼叫的消息流示意图；

图3是本发明方案流程图；

图4是应用本发明方案的实施例流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。

本发明实现用户呼叫故障检测的基本思想是：当GGSN接收到SGSN发送的呼叫消息时，GGSN处理呼叫消息，并在处理过程中可导致呼叫失败点判断是否成功处理，如果是，则继续处理呼叫消息，直至GGSN向SGSN发送呼叫应答消息，GGSN再结束呼叫处理过程；否则，GGSN向SGSN发送呼叫应答消息，确定并记录呼叫消息的基本信息，GGSN再输出呼叫消息的基本信息，然后结束呼叫处理过程。

其中，呼叫消息是SGSN按照协议要求向GGSN发送的请求消息，包括：创建PDP上下文请求消息、更新PDP上下文请求消息和删除PDP上下文请求消息。

呼叫流程是GGSN按照协议要求处理用户呼叫消息时需要执行的流程，由协议要求完成的子过程组成。当处理创建PDP上下文请求消息时，GGSN需要执行激活流程；当处理更新PDP上下文请求消息时，GGSN需要执行更新流程；当处理删除PDP上下文请求消息时，GGSN需要执行去活流程。

呼叫应答消息是GGSN按照协议要求向SGSN发送的消息，包括：创建PDP上下文应答消息、更新PDP上下文应答消息和删除PDP上下文应答消息。

基本信息是处理呼叫消息失败时，GGSN输出的包含呼叫失败原因的信息。

图3是本发明中GGSN实现用户呼叫故障检测方法的流程图。如图3所示，GGSN实现用户呼叫故障检测的方法包括以下步骤：

步骤301：GGSN接收来自SGSN呼叫消息，并开始处理该呼叫消息。

步骤302：GGSN在处理过程中可导致呼叫失败的地方判断是否成功处理，如果是，则继续处理呼叫消息，直至GGSN向SGSN发送呼叫应答消息，GGSN再结束呼叫处理过程；否则，执行步骤303。

步骤303：GGSN向SGSN发送呼叫应答消息，确定并记录呼叫消息的基本信息，GGSN再输出呼叫消息的基本信息，然后结束呼叫处理过程。

在本实施例中，GGSN先确定呼叫流程中的关键点；SGSN向GGSN发送呼叫消息；GGSN接收呼叫消息并为该消息创建呼叫日志；GGSN在对呼叫消息进行处理，执行呼叫流程，在呼叫流程中每个关键点之后生成打点信息，并将打点信息记录在呼叫日志中；同时，GGSN在处理过程中可导致呼叫失败的地方判断是否成功处理，如果是，则继续处理呼叫消息，直至GGSN向SGSN发送呼叫应答消息，GGSN再结束呼叫处理过程；否则GGSN向SGSN发送呼叫应答消息，确定并记录呼叫消息的基本信息，GGSN再输出呼叫消息的基本信息，然后结束呼叫处理过程。

其中，呼叫流程的关键点是GGSN按照协议要求需要完成的全部或部分子过程，可以由用户自行确定。

呼叫日志用来记录基本信息和打点信息，本实施例中呼叫日志可以采用表一的形式来记录基本信息和打点信息。

基本信息
基本信息	字段名	描述
业务类型	字段名	描述
业务类型	国际移动用户识别码
移动台国际ISDN号码	国际移动用户识别码
移动台国际ISDN号码	呼叫建立时间
用户IP地址	呼叫建立时间
用户IP地址	SGSN信令面IP地址
SGSN数据面IP地址	SGSN信令面IP地址
SGSN数据面IP地址	计费标识
PDP上下文索引	计费标识
PDP上下文索引	PDP上下文类型
接入点名称	PDP上下文类型
接入点名称	呼叫失败原因
打点信息	呼叫失败原因
打点信息

表一

基本信息由呼叫消息中携带的参数、呼叫流程子过程执行后得到的参数和GGSN在呼叫故障时判断的呼叫失败原因组成。其中，业务类型、国际移动用户识别码、移动台国际ISDN号码、呼叫建立时间、SGSN信令面IP地址、SGSN数据面IP地址、计费标识、PDP上下文类型、接入点名称等属于呼叫消息携带的参数，可以从接收到的呼叫消息中得到，也可以在创建的上下文中得到；PDP上下文索引、用户IP地址分别是执行创建上下文子过程和执行分配IP地址子过程后得到的参数，GGSN获取这些参数后一般记录在该呼叫消息对应的用户上下文中，所以，当需要确定呼叫日志中的基本信息时，GGSN可以从用户上下文中获取PDP上下文索引和用户IP地址这两个参数；呼叫失败原因则是发生呼叫故障时，由GGSN确定的信息。GGSN确定呼叫故障的原因有很多，可以根据GGSN具体执行子过程的功能来决定输出的呼叫失败原因，比如：报文格式错误、申请内存资源失败、申请IP地址资源失败等等。一般来说，当GGSN由于发生呼叫故障而退出呼叫流程时，GGSN就将执行当前子过程失败作为呼叫失败原因。当然，基本信息也可以不包括这些信息，但至少包括呼叫失败原因。

打点信息是对呼叫流程中关键点执行情况的描述，是为了当出现用户呼叫故障后，网络管理中心可以通过查看打点信息来了解GGSN执行的过程或执行的历史记录，可以对呼叫失败的原因判断得更加准确。比如，当GGSN成功执行创建上下文之后，生成的打点信息可以为：创建用户上下文成功，上下文的索引为15。打点信息可以是用户预先设定的字符串，也可以是用户预先设定的字符串和执行关键点之后得到的参数组成的字符串。字符串的内容可以由用户自行确定，只要能描述关键点执行情况即可。另外，由于打点信息都是在关键点执行之后生成的，即只有成功执行了关键点，才会存在打点信息，否则，GGSN将退出呼叫流程，不再生成打点信息。当发生呼叫故障后，GGSN就可以将打点信息和基本信息组成的呼叫日志输出给网络中心。

图4是应用本发明方案的实施例流程图。如图4所示，本实施例实现用户呼叫故障检测的方法的步骤包括：

步骤401：GGSN确定呼叫流程的关键点。

在实际应用中，GGSN可能执行激活流程、更新流程和去活流程，GGSN将分别在这三个不同的流程中确定各自的关键点。比如：GGSN可以将激活流程中的创建用户上下文、将解析后的消息内容保存在上下文、流量传输模板TFT信元检查、协议配置选项PCO信元检查、授权检查、协商服务质量QOS，带宽检查、创建信令路径、创建数据路径、置激活时间戳、选择模式检查、AAA鉴权、分配IP地址、创建话单、AAA计费、建立本地各种表项等子过程确定为激活流程中的关键点。

步骤402：SGSN向GGSN发送呼叫消息。

在实际应用中，SGSN可能向GGSN发送创建PDP上下文请求消息、更新PDP上下文请求消息或删除PDP上下文请求消息。

步骤403：GGSN接收到来自SGSN的呼叫消息后，为该呼叫消息创建呼叫日志。

本实施例中，GGSN所创建的呼叫日志如表一所示。在实际应用中，也可以先将用户IP地址默认为255.255.255.255或0.0.0.0，表示IP地址无效。如果成功分配IP地址，则GGSN再将该值修改为实际得到的正确的值；否则，不作更改。

在实际应用中，呼叫日志也可以在需要记录打点信息时才创建。

步骤404：GGSN判断接收到的呼叫消息的类型，并按照判断结果执行相应的呼叫流程。

在实际应用中，如果呼叫消息为创建PDP上下文请求消息，则GGSN执行激活流程；如果呼叫消息为更新PDP上下文请求消息，则GGSN执行更新流程；如果呼叫消息为删除PDP上下文请求消息，则GGSN执行去活流程。

步骤405：GGSN执行呼叫流程，在呼叫流程中的每个关键点之后生成打点信息，并将打点信息记录在呼叫日志中。

在实际应用中，生成打点信息的方法有两种：一种是GGSN直接将预设的字符串作为打点信息；另一种是GGSN将预设的字符串和执行关键点后得到的参数作为打点信息。

在实际应用中，GGSN还可能在刚开始执行呼叫流程时，就由于发生呼叫故障而退出呼叫流程，此时，GGSN可能还没有生成打点信息，则呼叫日志中将不存在打点信息。而如果GGSN生成了打点信息，则将打点信息记录在呼叫日志中。比如：GGSN执行激活流程时生成的打点信息可能如表二所示：

基本信息
基本信息	字段名	描述
业务类型	字段名	描述
业务类型	国际移动用户识别码
移动台国际ISDN号码	国际移动用户识别码
移动台国际ISDN号码	呼叫建立时间
用户IP地址	呼叫建立时间
用户IP地址	SGSN信令面IP地址
SGSN数据面IP地址	SGSN信令面IP地址
SGSN数据面IP地址	计费标识
PDP上下文索引	计费标识

PDP上下文类型
PDP上下文类型		接入点名称
呼叫失败原因		接入点名称
呼叫失败原因		打点信息
1.创建用户上下文成功，上下文的索引为152.向AAA服务器10.118.70.1发送鉴权请求消息成功…		打点信息

表二

步骤406：GGSN在呼叫流程的可导致呼叫失败的地方判断是否成功执行，如果是，则继续处理，直至GGSN向SGSN发送创建PDP上下文应答消息，再执行步骤407；否则，执行步骤408。

呼叫流程的可导致呼叫失败的地方即GGSN在按照协议执行呼叫流程中发生呼叫故障，而退出呼叫流程的地方。在现有技术中，虽然不同的GGSN执行的呼叫流程可能不同，但都必须在发生呼叫故障时向SGSN发送应答消息，所以，就可以确定呼叫流程的可导致呼叫失败的地方。

在实际应用中，由于呼叫流程中的关键点，和呼叫流程的可导致呼叫失败的地方可能分别有多个，并且执行的顺序可能是交错进行的，所以，步骤405和步骤406并没有严格的顺序和执行次数，由实际情况决定。但是，一旦GGSN在呼叫流程的某一个可导致呼叫失败的地方判断为执行不成功，则由于GGSN将退出呼叫流程，而不再生成并记录打点信息了。

步骤407：GGSN删除呼叫日志，再结束呼叫处理过程。

步骤408：GGSN向SGSN发送应答消息，GGSN确定基本信息，并将基本信息记录在呼叫日志中，再向网络管理中心输出呼叫日志。

在实际应用中，GGSN也可以将呼叫日志输出给GGSN本地终端，网络管理中心向GGSN本地终端发送请求消息，再由GGSN本地终端将呼叫日志传输给网络管理中心。

GGSN确定基本信息的方式有以下几种方式：

当呼叫消息为创建PDP上下文请求消息时，确定基本信息的方法为：GGSN直接根据创建PDP上下文请求消息内容，及其执行情况来确定基本信息；或者，GGSN根据该消息在GGSN创建的上下文内容和激活流程执行情况来确定基本信息。

当呼叫消息为更新PDP上下文请求消息时，确定基本信息的方法为：GGSN直接根据更新PDP上下文请求消息的内容，及其执行情况来确定基本信息；或者，GGSN根据与该消息对应的上下文内容和更新流程执行情况来确定基本信息。

当呼叫消息为删除PDP上下文请求消息时，确定基本信息的方法为：GGSN直接根据删除PDP上下文请求消息的内容，及其执行情况来确定基本信息；或者，GGSN根据与该消息对应的上下文内容和去活流程执行情况来确定基本信息。

比如：GGSN执行激活流程时，在分配IP地址子过程时发现呼叫失败，则GGSN将从为呼叫消息创建的用户上下文中得到业务类型、国际移动用户识别码、移动台国际ISDN号码、呼叫建立时间、用户IP地址、SGSN信令面IP地址、SGSN数据面IP地址、计费标识、PDP上下文索引、PDP上下文类型、接入点名称，把这些信息记录在呼叫日志中。另外，由于GGSN是在分配IP地址子过程中发生呼叫失败，则GGSN将用户呼叫失败原因确定为分配IP地址资源失败。呼叫日志的结果如表三所示：

基本信息
基本信息		字段名	描述
业务类型	激活	字段名	描述
业务类型	激活	国际移动用户识别码	460070114001271
移动台国际ISDN号码	13681234567	国际移动用户识别码	460070114001271
移动台国际ISDN号码	13681234567	呼叫建立时间	18:21:54GMT+08:00Sun 2005/08/21
用户IP地址	255.255.255.255	呼叫建立时间	18:21:54GMT+08:00Sun 2005/08/21
用户IP地址	255.255.255.255	SGSN信令面IP地址	10.110.218.81
SGSN数据面IP地址	10.110.218.81	SGSN信令面IP地址	10.110.218.81
SGSN数据面IP地址	10.110.218.81	计费标识	5489621
PDP上下文索引	15	计费标识	5489621
PDP上下文索引	15	PDP上下文类型	IPv4
接入点名称	cmnet	PDP上下文类型	IPv4
接入点名称	cmnet	关键点失败信息	申请IP地址资源失败
打点信息		关键点失败信息	申请IP地址资源失败
打点信息		1.创建用户上下文成功，上下文的索引为15

2.向AAA服务器10.118.70.1发送鉴权请求消息成功3.IP地址请求响应消息中返回无效IP地址，255.255.255.255

表三

步骤409：GGSN删除呼叫日志，然后结束呼叫处理过程。

在实际应用中，呼叫日志可以由步骤403在缓冲区中创建，当步骤407和步骤409删除呼叫日志时，将释放缓冲区。

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

Claims

1.一种用户呼叫故障检测方法，其特征在于，当网关通用分组无线业务支持节点GGSN接收到服务通用分组无线业务支持节点SGSN发送的呼叫消息时，该方法包括以下步骤：

a、GGSN处理呼叫消息，并在处理过程中可导致呼叫失败点判断是否成功处理，如果是，则继续处理呼叫消息，直至GGSN向SGSN发送呼叫应答消息，GGSN再结束呼叫处理过程；否则，执行步骤b；

2.根据权利要求1所述的方法，其特征在于，所述步骤a之前进一步包括：GGSN确定呼叫流程的关键点；

步骤b所述输出基本信息之后进一步包括：输出打点信息。

3.根据权利要求2所述的方法，其特征在于，所述生成打点信息的方法为：GGSN直接将预设的字符串作为打点信息；或者，

4.根据权利要求2所述的方法，其特征在于，所述GGSN确定呼叫流程的关键点和步骤a之间进一步包括：GGSN为接收到的呼叫消息创建呼叫日志；

5.根据权利要求4所述的方法，其特征在于，步骤b所述GGSN输出呼叫日志的方法为：GGSN将呼叫日志输出给GGSN本地终端；

6.根据权利要求4所述的方法，其特征在于，步骤b所述GGSN输出呼叫日志的方法为：GGSN将呼叫日志直接输出给网络管理中心。

7.根据权利要求4所述的方法，其特征在于，步骤b所述确定基本信息的方法为：GGSN直接根据呼叫消息内容和呼叫流程执行情况来确定基本信息；或者，

8.根据权利要求7所述的方法，其特征在于，所述呼叫消息为创建PDP上下文请求消息，所述呼叫流程为激活流程；或者，

9.根据权利要求4所述的方法，其特征在于，所述GGSN为接收到的呼叫消息创建呼叫日志和步骤a之间进一步包括：GGSN判断接收到的呼叫消息的类型，

10.根据权利要求1至9任一项所述的方法，其特征在于，步骤b所述基本信息包括：业务类型、国际移动用户识别码、移动台国际ISDN号码、呼叫建立时间、用户IP地址、SGSN信令面IP地址、SGSN数据面IP地址、计费标识、PDP上下文索引、PDP上下文类型、接入点名称、用户呼叫失败原因。