CN100531254C - 掉话故障信息的上报方法、装置及掉话故障原因定位系统 - Google Patents
掉话故障信息的上报方法、装置及掉话故障原因定位系统 Download PDFInfo
- Publication number
- CN100531254C CN100531254C CNB2005100902957A CN200510090295A CN100531254C CN 100531254 C CN100531254 C CN 100531254C CN B2005100902957 A CNB2005100902957 A CN B2005100902957A CN 200510090295 A CN200510090295 A CN 200510090295A CN 100531254 C CN100531254 C CN 100531254C
- Authority
- CN
- China
- Prior art keywords
- call drop
- drop fault
- fault
- reason
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种掉话故障信息的上报方法，包括预先设定要记录的掉话故障参数；根据所设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；在该呼叫出现掉话故障时，将记录得到的数据上报给网络管理中心。相应的，本发明还公开了一种掉话故障信息的上报装置及其对掉话故障原因进行定位的系统。本发明可以使在发生掉话故障时，网络设备能够及时、准确、完整地将获取到的掉话故障信息上报给网络管理中心。
Description
技术领域
本发明涉及移动通信网络系统的优化技术，尤其涉及一种掉话故障信息的上报方法、及其掉话故障信息的上报装置以及对掉话故障原因进行定位的系统。
背景技术
宽带码分多址(WCDMA，Wideband Code Division Multiple Access)系统是一个开放的系统，该系统主要包含核心网(CN，Core Network)、UMTS陆地无线接入网(UTRAN，UMTS Terrestrial Radio Access Network)以及用户终端(UE，User Equipment)三部分(其它如网管以及告警平台等部分不在本专利描述之列)。如图1所示，其中的无线网络控制器(RNC，Radio NetworkController)属于UTRAN部分，RNC与其它网元之间存在着标准接口，包括：与CN之间的IU接口，与NodeB之间的IUB接口，与其它RNC之间的IUR接口，以及与UE之间的UU接口。
如图1所示，一个RNC可以连接一个或者多个NodeB，而一个NodeB包含一个或者多个小区。UE开机后，在一个小区中驻留后便可接收网络侧的服务，比如接收系统消息和寻呼消息。当UE通话或浏览网页等其它分组业务时，UE会在这个小区触发一系列标准接口的流程，直至完成呼叫的建立。
用户接入网络成功后便开始处于通话状态，对于无线通信系统而言，用户会根据预先规定的小区选择准则选取一个合适的小区驻留，每个小区都有一定的覆盖范围，这个覆盖范围与NodeB的发射功率以及小区中用户的数量有关。但是，由于用户的移动性以及无线网络环境本身的复杂性，还是可能会导致掉话等呼叫故障。
在无线网络运行过程中，尤其是在建网初期，经常会出现在呼叫过程中发生掉话这种问题，这将严重影响到通信质量问题，因此如何来发现并解决这种问题，便显得尤为重要了。
在现有网络的日常维护工作中，通常通过如下方法来进行掉话原因的分析和定位：
1、性能统计功能
性能统计是通过统计网络中关键的统计项来衡量当前网络的质量，该方法是统计在一个特定的测量周期内掉话次数，并将该统计值反馈给网络管理中心，由网络管理中心进行全面的分析，通过分析结果来指导解决问题和进行网络优化。
但是，性能统计是一种长时间、或者说是一种周期任务的统计功能，在一段时间内进行统计掉话率，这种统计结果本身就很粗糙，不能提供掉话时的具体场景信息，不利于对导致掉话故障的具体原因进行分析。
2、全网信令检测方法
信令跟踪的方法是通过信令跟踪仪器在标准协议接口(如UU、IUB等)中跟踪呼叫过程尤其是来自不同网元中的标准协议消息，并将这些相关的消息发送给网络管理中心，通过对这些捕获的消息来进行分析，根据分析结果对网络进行优化，同时解决呼叫过程中的掉话部分问题。
但是，全网跟踪方法是一种实时的跟踪，需要在所有的标准协议接口通过第三方仪器(如信令跟踪仪)进行跟踪，这种跟踪会产生大量的数据，目前的2G全网信令跟踪只是跟踪了网间的消息，也就是核心网部分的消息，没有跟踪接入网部分的消息。对于3G系统来说，这些跟踪消息将会是海量的，尤其是需要跟踪接入网部分的消息时。如何从大量的跟踪消息中获取有用的信息，将会是非常大的工作量。另外通过信令跟踪还需要有很丰富的经验，能够很敏锐的发现消息中存在的问题，这种方法也不便于在维护人员中推广。
3、告警
在无线网络系统发生故障时，如发生掉话故障时，告警系统可以实时的将掉话故障以告警信息的形式发送给网络管理中心，网络管理中心可以通过对接收的告警信息进行处理和分析，以达到对网络故障(如掉话故障)进行分析和排除。
但是，告警一般来说关注的都是设备故障，对用户故障的关注比较少，比如用户由于无线网络环境原因而导致掉话的时候，采用告警方式就无法体现出来，所以告警基本上不能反映或者解决掉话原因的失败和定位问题。
发明内容
本发明要解决的技术问题在于提出一种掉话故障信息的上报方法，以使在发生掉话故障时，网络设备能够及时、准确、完整地将获取到的掉话故障信息上报给网络管理中心。
本发明要解决的技术问题还在于提出一种掉话故障信息的上报装置。
本发明要解决的技术问题还在于提出一种对掉话故障原因进行定位的系统。
为解决上述问题，本发明提出的技术方案如下：
一种掉话故障信息的上报方法，应用于宽带码分多址系统，包括步骤：
预先设定要记录的掉话故障参数；
根据所设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；
在该呼叫出现掉话故障时，将记录得到的数据上报给网络管理中心。
较佳地，所述方法还包括步骤：
通过在所述网络管理中心对接收的数据进行分析，来定位该呼叫产生掉话故障的原因。
较佳地，所述方法还包括步骤：
预先设定编解码方式；
对记录得到的数据按照所述编解码方式进行编码，形成码流后上报给网络管理中心。
较佳地，所述方法还包括步骤：
所述网络管理中心按照所述编解码方式对接收码流进行解码，得到对应的数据；并
通过对得到的数据进行分析，来定位该呼叫产生掉话故障的原因。
较佳地，所述要记录的掉话故障参数由运营商设定。
较佳地，所述编解码方式由运营商设定。
较佳地，所述编解码方式为抽象语法符号1编解码方式。
较佳地，所述要记录的掉话故障参数包括：
故障类型、掉话原因、掉话时间、用户的国际移动用户识别码、无线资源控制连接状态指示、掉话前的无线接入承载信息以及掉话的无线接入承载信息。
较佳地，所述要记录的掉话故障参数还包括：
无线资源控制连接的建立时间、用户当前所处过程的类型、最好小区信息以及小区支路信息。
较佳地，所述故障类型为掉话故障。
较佳地，所述掉话原因包括：
无线网络控制器内部原因、UU接口失败原因、IUB接口失败原因、IU接口失败原因以及IUR接口失败原因。
较佳地，所述无线网络控制器内部原因包括：
发射载波功率值、接收载波功率值、公共信道类型以及公共信道标识。
较佳地，所述无线网络控制器内部原因还包括：
拥塞状态、小区异常状态、公共信道去激活、信令无线承载复位、抽象语法符号1错误原因、L2层配置失败原因、传输层配置失败原因、内存分配失败以及用户面异常。
较佳地，所述小区异常状态包括：
小区删除信息、小区去激活信息以及小区阻塞信息。
较佳地，所述UU接口失败原因包括：UU接口原因和UU接口超时。
较佳地，所述IUB接口失败原因包括：IUB接口原因和IUB接口超时。
较佳地，所述IU接口失败原因包括：IU接口原因和IU接口超时。
较佳地，所述IUR接口失败原因包括：IUR接口原因和IUR接口超时。
较佳地，所述无线资源控制连接状态指示为：
用户处于CELL_DCH状态指示；或
用户处于CELL_FACH状态指示；或
用户处于CELL_PCH状态指示；或
用户处于URA_PCH状态指示。
较佳地，所述用户当前所处过程的类型为：
无线资源控制连接建立过程；或
无线接入承载指配过程；或
软切换过程；或
硬切换过程；或
重定位过程；或
异系统换入过程；或
异系统换出过程；或
小区更新过程。
较佳地，所述掉话前的无线接入承载信息包括：
业务类型、下行最大比特率、上行最大比特率、无线接入承载标识以及无线接入承载建立或修改时间。
较佳地，所述掉话前的无线接入承载信息还包括：
核心网域标识、下行保证比特率以及上行保证比特率。
较佳地，所述掉话的无线接入承载信息包括：无线接入承载标识和核心网域标识。
较佳地，所述最好小区信息、小区支路信息分别包括：
小区标识、公共导频信道信噪比以及公共导频信道接收信号码功率。
相应的，本发明还提出了一种掉话故障信息的上报装置，应用于宽带码分多址系统，包括：
第一设定单元，用于预先设定要记录的掉话故障参数；
记录单元，用于根据所述第一设定单元中设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；和
上报单元，用于在该呼叫出现掉话故障时，将所述记录单元记录得到的数据上报给网络管理中心。
较佳地，所述装置还包括：
第二设定单元，用于预先设定编解码方式；和
编码单元，用于对所述记录单元记录得到的数据按照所述第二设定单元设定的编解码方式进行编码处理；所述上报单元将编码单元编码后形成的码流上报给网络管理中心。
较佳地，由运营商在所述第一设定单元中设定要记录的掉话故障参数。
较佳地，由运营商在所述第二设定单元中设定编解码方式。
相应的，本发明还提出了一种对掉话故障原因进行定位的系统，应用于宽带码分多址系统，包括掉话故障信息上报装置和网络管理中心，所述掉话故障信息上报装置包括：
第一设定单元，用于预先设定要记录的掉话故障参数；
记录单元，用于根据所述第一设定单元中设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；和
上报单元，用于在该呼叫出现掉话故障时，将所述记录单元记录得到的数据上报给网络管理中心；
所述网络管理中心通过对所述上报单元上报的数据进行分析，来定位该呼叫产生掉话故障的原因。
较佳地，由运营商在所述第一设定单元中设定要记录的掉话故障参数。
相应的，本发明还提出了一种对掉话故障原因进行定位的系统，应用于宽带码分多址系统，包括掉话故障信息上报装置和网络管理中心，所述掉话故障信息上报装置包括：
第一设定单元，用于预先设定要记录的掉话故障参数；
第二设定单元，用于预先设定编解码方式；
记录单元，用于根据所述第一设定单元中设定的要记录的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；
编码单元，用于在该呼叫出现掉话故障时，对所述记录单元记录得到的数据按照所述第二设定单元设定的编解码方式进行编码处理；
上报单元，用于将编码单元编码后形成的码流上报给网络管理中心；
所述网络管理中心包括：
解码单元，用于对所述上报单元上报的码流按照所述第二设定单元设定的编解码方式进行解码处理，以得到对应的数据；
分析单元，用于对所述解码单元解码得到的数据进行分析，来定位该呼叫产生掉话故障的原因。
较佳地，由运营商在所述第一设定单元中设定要记录的掉话故障参数；并在第二设定单元中设定编解码方式。
本发明能够达到的有益效果如下：
本发明通过统一设定各个要记录的掉话故障参数，以按照统一设定的各个要记录的掉话故障参数，来对某一呼叫过程中的对应参数值进行记录，并对应记录各个参数值的记录时间，并在该呼叫出现掉话故障时，将记录得到的数据上报给网络管理中心，从而可以使得各个设备提供商能够按照(运营商)规定记录的掉话故障参数，将掉话故障数据较为完整、及时、准确的上报给网络管理中心，使得在网络管理中心侧能够更为准确的定位到发生掉话故障的原因，以进行更加有目的的网络优化处理。
附图说明
图1为现有UTRAN体系结构示意图；
图2为本发明掉话故障信息的上报方法的主要实现原理流程图；
图3为本发明掉话故障信息的上报装置的主要组成结构框图；
图4为本发明掉话故障信息的上报装置增加有解码单元的主要组成结构框图；
图5为本发明提出的第一种对掉话故障原因进行定位的系统的组成结构框图；
图6为本发明提出的第二种对掉话故障原因进行定位的系统的组成结构框图。
具体实施方式
本发明的设计思想是提供一种呼叫历史记录(CHR，CALL HISTORYRECORD)，该记录可以跟踪呼叫过程中出现的问题，并通过标准协议消息形式反馈给网络管理中心，在网络管理中心侧可以根据这些历史记录来分析呼叫出现掉话的原因，并通过采取相应的处理手段(如网络优化、软件升级等)来恢复故障，达到网络优化的目的。
下面将结合各个附图对本发明掉话故障信息的上报方法的主要实现原理及其具体实施方式进行详细的阐述。请参照图2，该图是本发明掉话故障信息的上报方法的主要实现原理流程图，其主要实现过程如下：
步骤S10，预先设定要记录的掉话故障参数；其中可以由运营商来统一设定要记录的各个掉话故障参数；
步骤S20，根据上述预先设定的各个掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；
步骤S30，在该呼叫出现掉话故障时，将上述记录得到的数据上报给网络管理中心；
步骤S40，通过在网络管理中心侧对接收的数据进行分析，来定位该呼叫产生掉话故障的原因，并通过定位到的掉话故障原因，采用相应的手段(如网络优化、软件升级等)来恢复掉话故障，以达到网络优化的目的。
其中还可以预先设定一标准编解码方式，如设定的编解码方式可以但不限于为：抽象语法符号1(ASN.1，Abstract Syntax Notation One)编解码方式，其中ASN.1编解码方式是3GPP标准规范中的标准编解码协议。优选的，可以由运营商来统一设定标准的编解码方式。
这样在上述步骤S30中，就可以按照设定的标准编解码方式对记录得到的数据进行编码处理，形成码流后上报给网络管理中心；
网络管理中心再按照上述设定的标准编解码方式对接收码流进行解码处理，得到对应的数据；
在网络管理中心侧再通过对得到的数据进行分析，来定位该呼叫产生掉话故障的原因，并通过定位到的掉话故障原因，采用相应的手段(如网络优化、软件升级等)来恢复掉话故障，以达到网络优化的目的。
其中本发明掉话故障信息的上报方法的设计思想是基于目前3GPP规范中并没有对掉话故障日志记录的输出内容进行描述，包括掉话原因和掉话的关键场景信息等描述。本发明就是针对这个问题，提出了一套统一、完善的掉话故障日志记录输出内容，以规范掉话故障日志记录的输出内容。在掉话情况下，可以通过对该规范的掉话故障日志记录输出的相关参数值进行分析，来定位出现掉话故障的原因，以指导运营商进行网络优化。
如下表所示，这些内容(即上述所述的预先设定的要记录的掉话故障参数，下面将每个参数称之为“网元”)，每个网元信息(要记录的掉话故障参数值)在网络侧均可以获得，在发生掉话时，网络侧需要输出如下信元信息，并且按照3GPP标准的ASN.1编解码方式进行编码输出。
表1：所有信元信息的描述分为必选、可选、条件选择三类
缩写 含义
MP 该信元必须被包含在故障原因记录中
OP 该信元可能被包含在故障原因记录中
C 在条件满足时，该信元将被包含在故障原因记录
中，否则，该信元将不会被包含在故障原因记录中，
其中所预先设定的要记录的掉话故障参数包括：
故障类型、掉话原因、掉话时间、用户的国际移动用户识别码(IMSI)、无线资源控制连接(RRC)状态指示、掉话前的无线接入承载(RAB)信息以及掉话的无线接入承载(RAB)信息；
所预先设定的要记录的掉话故障参数还包括：
无线资源控制连接(RRC)的建立时间、用户当前所处过程的类型、最好小区信息以及小区支路信息。
具体的，发生掉话故障时网络侧需要输出如下表格所示的各个信元信息(每个信元信息代表一个掉话故障参数)，其中该表格中的信元今后可以扩展，扩展方式采用ASN.1中的EXTENSION方式，以保证扩展前后的兼容性：
表2：发生掉话故障时网络侧需要输出的各个信元：
| 信元名(InformationElement/Group name) | 是否需要(Need) | Multi | 参考类型(Typeand reference) | 语法描述(Semanticsdescription) |
| Failure Type | MP | Failure Type2.2.2.2 | 故障类型 | |
| Failure informationelements | ||||
| ＞Drop Cause | MP | Drop Cause2.2.2.3 | 掉话原因 | |
| ＞Drop Time | MP | BIT STRING(32) | 掉话时间(日期:时:分:秒) | |
| UE informationelements | ||||
| ＞IMSI | MP | IMSI2.2.2.4 | 国际移动用户识别码 | |
| ＞RRC EstablishmentTime | MP | BIT STRING(32) | RRC建立时间(日期:时:分:秒) | |
| ＞RRC State Indicator | MP | RRC State Indicator2.2.2.5 | RRC连接状态 | |
| Current Procedure | OP | Procedure Type2.2.2.6 | 当前过程类型 | |
| RAB Informationelements | ||||
| ＞RAB information | MP | RAB ListInformation2.2.2.7 | 掉话前的RAB列表信息 | |
| ＞Drop RABinformation | MP | Failed RAB ListInformation2.2.2.8 | 掉话的RAB列表信息 | |
| Best Cell informationelements | ||||
| ＞Best Cell Information | MP | Cell Information2.2.2.9 | 最好小区信息 | |
| Cell Leg Informationelements | ||||
| ＞Cell Leg Information | MP | 0～6 | Cell Information2.2.2.9 | 小区支路信息 |
因为故障类型为掉话故障，所以需要将故障类型信元中记录故障为DROP，代表掉话，故障类型的表格形式如下表所示：
表3：故障类型，如故障为掉话时则选择DROP
| 信元名(InformationElement/Group name) | 是否需要(Need) | Multi | 参考类型(Typeand reference) | 语法描述(Semanticsdescription) |
| Failure Type | MP | 列举ENUMERATEDRRC SETUP；RABASSIGNMENT；SOFTHANDOVER；HARDHANDOVER；RELOCATION；INTER RAT；HANDOVER IN；INTER RATHANDOVEROUT；CELL UPDATE；DROP；NULL) | 故障类型列举无线资源控制连接建立；无线接入承载指配；软切换；硬切换；重定位；异系统切换入；异系统切换出；小区更新；掉话；其它) |
其中掉话原因包括：无线网络控制器(RNC)内部原因、UU接口失败原因、IUB接口失败原因、IU接口失败原因以及IUR接口失败原因：
其中RNC内部原因包括：
发射载波功率值、接收载波功率值、公共信道类型以及公共信道标识；还包括拥塞状态、小区异常状态、公共信道去激活、信令无线承载复位(SRB复位)、抽象语法符号1错误原因、L2层配置失败原因、传输层配置失败原因、内存分配失败以及用户面异常；
其中小区异常状态包括：小区删除信息、小区去激活信息以及小区阻塞信息；其中UU接口失败原因包括：UU接口原因和UU接口超时；其中IUB接口失败原因包括：IUB接口原因和IUB接口超时。其中IU接口失败原因包括：IU接口原因和IU接口超时。其中IUR接口失败原因包括：IUR接口原因和IUR接口超时。
表4：掉话的详细原因
| 信元名(InformationElement/Group name) | 是否需要(Need) | Multi | 参考类型(Type andreference) | 语法描述(Semanticsdescription) |
| CHOICE Cause Group | MP | |||
| ＞RNC Inner FailureChoice | OP | RNC内部原因 | ||
| ＞＞Congestion | OP | 拥塞 | ||
| ＞＞＞Transmitted CarrierPower Value | MP | INTEGER(0..100) | 发射载波功率 | |
| ＞＞＞Received TotalWide Band Power Value | MP | INTEGER(0..621) | 接收载波功率 | |
| ＞＞Cell Abnormal | OP | ENUMERATED(RNCTrigger，NodeBTrigger | 小区异常 | |
| ＞＞＞CHOICE | ||||
| ＞＞＞＞Cell Delete | OP | 小区删除 | ||
| ＞＞＞＞Cell Disable | OP | 小区去激活 | ||
| ＞＞＞＞Cell Block | OP | 小区阻塞 | ||
| ＞＞Common Channeldisable | OP | ENUMERATED(RNCTrigger，NodeBTrigger) | 公共信道去激活 | |
| ＞＞＞Common ChannelType | MP | ENUMERATEDCommon PhysicalChannel；Common TransportChannel； | 公共信道类型列举公共物理信道；公共传输信道； | |
| ＞＞＞Common ChannelIdentity | MP | INTEGER(0..255) | 公共信道ID | |
| ＞＞SRB reset | OP | 信令RB复位 | ||
| ＞＞ASN.1 Error Cause | ENUMERATEDTransfer Syntax Error；Abstract Syntax Error；Logical Error； | 抽象语法符号错误1列举传输语法错误；抽象语法错误；逻辑错误； | ||
| ＞＞L2 ConfigurationError Cause | OP | L2 Configuration ErrorCause | L2配置失败 | |
| ＞＞Transport layerConfiguration ErrorCause | OP | Transport layerConfiguration ErrorCause | 传输层配置失败 | |
| ＞＞Allocation MemoryFailure | OP | 内存分配失败 | ||
| ＞＞User Plane ErrorCause | OP | User Plane Error Cause | 用户面异常 | |
| ＞＞Unspecified | OP | |||
| ＞UU Interface FailureChoice | OP | UU接口失败选择 | ||
| ＞＞UU Cause | OP | UU cause | UU接口原因，参见 |
| 3GPP TS25.331 | ||||
| ＞＞UU Time Out | OP | UU接口超时 | ||
| ＞IUB Interface FailureChoice | OP | IUB接口失败选择 | ||
| ＞＞IUB Cause | OP | IUB cause | IUB接口原因，参见3GPP TS25.433 | |
| ＞＞IUB Time Out | OP | IUB接口超时 | ||
| ＞IU Interface FailureChoice | OP | IU接口失败选择 | ||
| ＞＞IU Cause | OP | IU cause | IU接口原因，参见3GPP TS25.413 | |
| ＞＞IU Time Out | OP | IU接口超时 | ||
| ＞IUR Interface FailureChoice | OP | IUR接口失败选择 | ||
| ＞＞IUR Cause | OP | IUR cause | IUR接口原因，参见3GPP TS25.423 | |
| ＞＞IUR Time Out | OP | IUR接口超时 |
表5：IMSI(GSM-MAP)
| 信元名(InformationElement/Group name) | 是否需要(Need) | Multi | 参考类型(Type andreference) | 语法描述(Semanticsdescription) |
| IMSI | MP | 6 to 21 | The first element containsthe first IMSI digit，thesecond element the secondIMSI digit and so on.(第一个信元包含第一个IMSI数字，第二个信元包含第二个IMSI数字....依次类推)Although normally upto 15digits are used for this IE，abigger length is used tosupport future extension.(通常用15个数字表示，超过15个用来支持以后扩展) | |
| ＞IMSI digit | MP | INTEGER(0..9) |
其中，RRC连接状态指示包括：
用户处于CELL_DCH状态指示；或
用户处于CELL_FACH状态指示；或
用户处于CELL_PCH状态指示；或
用户处于URA_PCH状态指示；
表6：RRC State Indicator
| 信元名(InformationElement/Group name) | 是否需要(Need) | Multi | 参考类型(Typeand reference) | 语法描述(Semanticsdescription) |
| RRC State indicator | MP | 列举ENUMERATED(CELL_DCH，CELL_FACH，CELL_PCH，URA_PCH) | 无线连接控制状态指示 |
其中用户当前所处过程的类型为：
RRC连接建立过程；或RAB指配过程；或软切换过程；或硬切换过程；或重定位过程；或异系统换入过程；或异系统换出过程；或小区更新过程；
表7：当前用户所处的过程类型(Procedure Type)
| 信元名(InformationElement/Group name) | 是否需要(Need) | Multi | 参考类型(Type andreference) | 语法描述(Semanticsdescription) |
| Procedure Type | MP | ENUMERATEDRRC SETUP；RABASSIGNMENT；SOFTHANDOVER；HARDHANDOVER；RELOCATION；INTER RAT；HANDOVER IN；INTER RATHANDOVER OUT；CELL UPDATE；NULL) | 过程类型列举无线资源控制连接建立；无线接入承载指配；软切换；硬切换；重定位；异系统切换入；异系统切换出；小区更新；其它 |
其中用户掉话前的RAB信息包括：业务类型、下行最大比特率、上行最大比特率、无线接入承载标识以及无线接入承载建立或修改时间；还包括核心网域标识、下行保证比特率以及上行保证比特率；
表8：用户当前的RAB信息列表(RAB List Information)
| IE/Group Name | 是否需要(Need) | Multi | 参考类型(Typeand referenee) | 语法描述(Semanticsdescription) |
| RABsInformation List | 1～maxnoofRABs | 无线接入承载信息列表Maximum no.of RABs forone UE.Value is 256一个UE的最大RAB个数为256 | ||
| ＞Traffic Class | MP | ENUMERATEDconversational；streaming；Interactive；Background；... | 业务类型列举会话；业务流；交互式业务；背景业务； | |
| ＞CN Informationidentity | OP | CN Domainidentity | CN域标识 | |
| ＞DL MaximumBit Rate | MP | INTEGER(1..16,000,000) | 下行最大BIT率 | |
| ＞UL MaximumBit Rate | MP | INTEGER(1..16,000,000) | 上行最大BIT率 | |
| ＞DL GuaranteedBit Rate | OP | INTEGER(0..16,000,000) | 下行保证BIT率 | |
| ＞UL GuaranteedBit Rate | OP | INTEGER(0..16,000,000) | 上行保证BIT率 | |
| ＞RAB ID | MP | BIT STRING(8) | 无线接入承载标识 | |
| ＞RAB To BeSetup Or ModifiedTime | MP | BIT STRING(32) | 无线接入承载建立或修改时间(日期DATE:小时HOUR:分钟MINUTE:秒SECOND) |
其中用户掉话的RAB信息包括：无线接入承载标识和核心网域标识；
表9：用户掉话的RAB信息列表(Failed RAB List Information)
| 信元名(InformationElement/Group name) | 是否需要(Need) | Multi | 参考类型(Typeand reference) | 参数描述(Semanticsdescription) |
| Fail RABs List | 1 to255 | 用户掉话的RAB列表 | ||
| ＞RAB ID | MP | BIT STRING(8) | 无线接入承载标识 | |
| ＞CN Domain Identity | MP | CN Domain Identity | CN域标识 |
其中最好小区信息、以及小区支路信息分别包括：小区标识、公共导频信道信噪比以及公共导频信道接收信号码功率；
表10：小区信息(Cell Information)
| 信元名(InformationElement/Group name) | 是否需要(Need) | Multi | 参考类型(Type andreference) | 语法描述(Semanticsdescription) |
| Cell identity | MP | BITSTRING(28) | 小区标识 | |
| Measurement resultfor current cell | 当前小区的测量结果 | |||
| ＞CPICH Ec/N0 | MP | INTEGER(0..49) | 公共导频信道Ec/N0 | |
| ＞CPICH RSCP | OP | INTEGER(0..91) | 公共导频信道接收信号码功率 |
以下通过一个例子来说明本发明掉话故障信息的上报方法的具体实施过程，掉话分析示例：
比如用户正在进行CS12.2K语音通信的同时进行着64K的PS数据下载，用户在移动过程中突然发生掉话；
网络管理中心接到用户的投诉后，可以根据该用户的手机号码(MSISDN，Mobile Station Identifier Number)，查找到该用户手机的IMSI，根据IMSI以及用户投诉的时间段在接收到的掉话故障日志记录中搜索该用户的掉话故障信息。搜索结果发现有两条故障记录，表11显示故障为掉话，表12显示故障为软切换失败，分别如下：
表11：掉话故障日志记录
表12：软切换故障日志记录：
| 用户标识(IMSI) | 460070114001271 |
| 故障类型 | 软切换失败 |
| 故障原因 | 目标小区准入失败 |
| 小区拥塞：RTWP：403TCP：90 | |
| 故障时间 | 30日09:38:24 |
| RRC建立时间 | 30日09:25:12 |
| RRC连接状态 | DCH |
| 掉话前业务建立信息 | 2 |
| CS DOMAIN，CONVERSATIONAL(电路域，会话业务)；UL/DL Bit Rate：12200(上/下行BIT率)；UL/DL Guaranteed Bit Rate：4.75K(上下行保证BIT率)；建立时间：30日9:30:15RABID：2(RAB标识)；PS DOMAIN，BACKGROUD(分组域，背景业务)；UL/DL Bit Rate：64K/64K(上/下行BIT率)；建立时间：30日9:25:15RABID：1(RAB标识)； | |
| 最好小区 | RNC：10，CELLID：101 |
| 最好小区RSCP | -80dbm |
| 最好小区EcNo | -12db |
| 其它服务小区 | 无 |
| 其他服务小区RSCP | 无 |
| 其他服务小区EcNo | 无 |
| 检测集小区1信息 | RNC：10，CELLID：109 |
| 检测集小区1RSCP | -85dbm |
| 检测集小区1EcNo | -10db |
| 检测集小区2信息 | RNC：10，CELLID：120 |
| 检测集小区2RSCP | -83dbm |
| 检测集小区2EcNo | -12db |
| 切换目标小区信息 | RNC：10，CELLID：109 |
通过分析表11可以获得如下信息：
1)掉话原因是SRB复位，掉话时间是09:40:40；
2)当前最好小区的RSCP为-95dbm，最好小区EcNo为-15db，说明最好小区信号质量已经很差了；
通过分析表12可以获得如下信息：
11)在掉话的前2秒钟，也就是09:38:24，发生软切换失败的故障；
12)当时用户已经移动到小区101和109的共同覆盖区，此时最好小区101的质量还是不错的，而小区109的小区已经满足了软切换1A事件(1A事件：小区信号质量达到报告范围)的门限，从而UE在109号小区上报了1A事件；
13)RNC判断出该109号小区满足软切换条件后，触发了软切换(说明101和109号小区属于同一个NODEB)，但是由于109号小区当前的负载已经非常高了，其中载波发射功率TCP达到了90％，超过了接入该小区的门限；
14)由于目标小区109负载很重导致了软切换失败。
综合上述分析可知，用户掉话的原因是：用户移动过程中原小区质量变差，而目标小区负载过重，不能及时切换到质量更好的小区而导致了掉话。
经过上面的分析可知，目标小区的负荷过重，由此优化人员可以采取如下措施进行掉话故障的消除：
A)目标小区是否处于热点的中心位置，如果是，那么应当优化网络，减少将该目标小区作为邻区；
B)目标小区的导频功率是否设置太大了，导致太多用户接入到该小区中；如果是，那么应当减小该目标小区的导频功率，以便使得用户可以平均分布到其它相邻小区；
C)修改目标小区的小区选择与重选参数，以便使得在该小区中的用户在空闲时更容易重选到其它邻区。
由此可见，在3G网络运行的初期，经常会出现由于3G网络覆盖不合理的情况，比如小区覆盖面积设计过大，由于用户太多而导致小区资源耗尽，或者配置的邻区信号在覆盖区太差等原因，这些原因将导致用户在这些地方进行呼叫、或者处于呼叫过程中的用户移动到了这些地方时，通信信号会变得非常差，严重时便会出现掉话。针对这种情况，本发明掉话故障信息的上报方法可以帮助优化人员分析掉话原因并指导故障问题的解决，也能够使故障日志记录得输出信息和格式规范化，形成一个共享、开放式的故障定位平台。
相应的，本发明还提出了一种掉话故障信息的上报装置，如图3所示，该图为本发明掉话故障信息的上报装置的主要组成结构框图，其主要由第一设定单元10、记录单元20和上报单元30组成，各个组成单元的作用及其之间的连接关系具体如下：
第一设定单元10，用于预先设定要记录的掉话故障参数；其中可以由运营商在该第一设定单元10中设定要记录的掉话故障参数；
记录单元20，与第一设定单元10存在逻辑连接，用于根据第一设定单元10中设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；
上报单元30，与记录单元20存在逻辑连接，用于在该呼叫出现掉话故障时，将记录单元20记录得到的数据上报给网络管理中心，以用于网络管理中心进行掉话故障原因的分析处理。
请参照图4，该图是本发明掉话故障信息的上报装置增加有解码单元的主要组成结构框图，其在上述主要组成结构的基础上，还增加有第二设定单元40和编码单元50，这两个增加单元的作用具体如下：
第二设定单元40，用于预先设定编解码方式，其中可以由运营商在该第二设定单元40中设定编解码方式(其中设定的编解码方式可以为ASN.1)。
编码单元50，分别与第二设定单元40、记录单元20和上报单元30存在逻辑连接，用于对记录单元20记录得到的数据按照第二设定单元40设定的编解码方式进行编码处理；上报单元30再将编码单元50编码后形成的码流上报给网络管理中心。
相应的，本发明还提出了两种对掉话故障原因进行定位的系统，分别如下：
请参照图5，该图是本发明提出的第一种对掉话故障原因进行定位的系统的组成结构框图；其主要由掉话故障信息上报装置100和网络管理中心200组成，其中掉话故障信息上报装置100中主要包括：
第一设定单元10，用于预先设定要记录的掉话故障参数；其中可以由运营商在该第一设定单元10中设定要记录的掉话故障参数；
记录单元20，与第一设定单元10存在逻辑连接，用于根据第一设定单元10中设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；
上报单元30，与记录单元20存在逻辑连接，用于在该呼叫出现掉话故障时，将记录单元20记录得到的数据上报给网络管理中心200；
网络管理中心200，与上报单元30存在逻辑连接，用于接收上报单元30发来的数据，并通过对接收的数据进行分析，来定位该呼叫产生掉话故障的原因。
请参照图6，该图是本发明提出的第二种对掉话故障原因进行定位的系统的组成结构框图；其主要由掉话故障信息上报装置100和网络管理中心200组成，其中掉话故障信息上报装置100中主要包括：
第一设定单元10，用于预先设定要记录的掉话故障参数；其中可以由运营商在该第一设定单元10中设定要记录的掉话故障参数；
第二设定单元40，用于预先设定编解码方式，其中可以由运营商在该第二设定单元40中设定编解码方式(其中设定的编解码方式可以为ASN.1)；
记录单元20，与第一设定单元10存在逻辑连接，用于根据第一设定单元10中设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；
编码单元50，分别与第二设定单元40和记录单元20存在逻辑连接，用于对记录单元20记录得到的数据按照第二设定单元40设定的编解码方式进行编码处理；
上报单元30，与编码单元50存在逻辑连接，用于将编码单元50编码处理后形成的码流上报给网络管理中心200；
其中网络管理中心200中主要包括：
解码单元210，与掉话故障信息上报装置100中的上报单元30存在逻辑连接，用于对上报单元30上报的码流按照第二设定单元40中设定的编解码方式进行解码处理，以得到对应的数据；
分析单元220，与解码单元210存在逻辑连接，用于对解码单元210解码得到的数据进行分析处理，以定位该呼叫产生掉话故障的原因。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
Claims (32)
1、一种掉话故障信息的上报方法，应用于宽带码分多址系统，其特征在于，包括步骤：
预先设定要记录的掉话故障参数；
根据所设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；
在该呼叫出现掉话故障时，将记录得到的数据上报给网络管理中心。
2、如权利要求1所述的方法，其特征在于，还包括步骤：
通过在所述网络管理中心对接收的数据进行分析，来定位该呼叫产生掉话故障的原因。
3、如权利要求1所述的方法，其特征在于，还包括步骤：
预先设定编解码方式；
对记录得到的数据按照所述编解码方式进行编码，形成码流后上报给网络管理中心。
4、如权利要求3所述的方法，其特征在于，还包括步骤：
所述网络管理中心按照所述编解码方式对接收码流进行解码，得到对应的数据；并
通过对得到的数据进行分析，来定位该呼叫产生掉话故障的原因。
5、如1～4任意权利要求所述的方法，其特征在于，所述要记录的掉话故障参数由运营商设定。
6、如权利要求3所述的方法，其特征在于，所述编解码方式由运营商设定。
7、如权利要求3或6所述的方法，其特征在于，所述编解码方式为抽象语法符号1编解码方式。
8、如权利要求1所述的方法，其特征在于，所述要记录的掉话故障参数包括：
故障类型、掉话原因、掉话时间、用户的国际移动用户识别码、无线资源控制连接状态指示、掉话前的无线接入承载信息以及掉话的无线接入承载信息。
9、如权利要求8所述的方法，其特征在于，所述要记录的掉话故障参数还包括：
无线资源控制连接的建立时间、用户当前所处过程的类型、最好小区信息以及小区支路信息。
10、如权利要求8所述的方法，其特征在于，所述故障类型为掉话故障。
11、如权利要求8所述的方法，其特征在于，所述掉话原因包括：
无线网络控制器内部原因、UU接口失败原因、IUB接口失败原因、IU接口失败原因以及IUR接口失败原因。
12、如权利要求11所述的方法，其特征在于，所述无线网络控制器内部原因包括：
发射载波功率值、接收载波功率值、公共信道类型以及公共信道标识。
13、如权利要求12所述的方法，其特征在于，所述无线网络控制器内部原因还包括：
拥塞状态、小区异常状态、公共信道去激活、信令无线承载复位、抽象语法符号1错误原因、L2层配置失败原因、传输层配置失败原因、内存分配失败以及用户面异常。
14、如权利要求13所述的方法，其特征在于，所述小区异常状态包括：
小区删除信息、小区去激活信息以及小区阻塞信息。
15、如权利要求11所述的方法，其特征在于，所述UU接口失败原因包括：UU接口原因和UU接口超时。
16、如权利要求11所述的方法，其特征在于，所述IUB接口失败原因包括：IUB接口原因和IUB接口超时。
17、如权利要求11所述的方法，其特征在于，所述IU接口失败原因包括：IU接口原因和IU接口超时。
18、如权利要求11所述的方法，其特征在于，所述IUR接口失败原因包括：IUR接口原因和IUR接口超时。
19、如权利要求8所述的方法，其特征在于，所述无线资源控制连接状态指示为：
用户处于CELL_DCH状态指示；或
用户处于CELL_FACH状态指示；或
用户处于CELL_PCH状态指示；或
用户处于URA_PCH状态指示。
20、如权利要求9所述的方法，其特征在于，所述用户当前所处过程的类型为：
无线资源控制连接建立过程；或
无线接入承载指配过程；或
软切换过程；或
硬切换过程；或
重定位过程；或
异系统换入过程；或
异系统换出过程；或
小区更新过程。
21、如权利要求8所述的方法，其特征在于，所述掉话前的无线接入承载信息包括：
业务类型、下行最大比特率、上行最大比特率、无线接入承载标识以及无线接入承载建立或修改时间。
22、如权利要求21所述的方法，其特征在于，所述掉话前的无线接入承载信息还包括：
核心网域标识、下行保证比特率以及上行保证比特率。
23、如权利要求8所述的方法，其特征在于，所述掉话的无线接入承载信息包括：无线接入承载标识和核心网域标识。
24、如权利要求9所述的方法，其特征在于，所述最好小区信息、小区支路信息分别包括：
小区标识、公共导频信道信噪比以及公共导频信道接收信号码功率。
25、一种掉话故障信息的上报装置，应用于宽带码分多址系统，其特征在于，包括：
第一设定单元，用于预先设定要记录的掉话故障参数；
记录单元，用于根据所述第一设定单元中设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；和
上报单元，用于在该呼叫出现掉话故障时，将所述记录单元记录得到的数据上报给网络管理中心。
26、如权利要求25所述的装置，其特征在于，还包括：
第二设定单元，用于预先设定编解码方式；和
编码单元，用于对所述记录单元记录得到的数据按照所述第二设定单元设定的编解码方式进行编码处理；所述上报单元将编码单元编码后形成的码流上报给网络管理中心。
27、如权利要求25或26所述的装置，其特征在于，由运营商在所述第一设定单元中设定要记录的掉话故障参数。
28、如权利要求26所述的装置，其特征在于，由运营商在所述第二设定单元中设定编解码方式。
29、一种对掉话故障原因进行定位的系统，应用于宽带码分多址系统，其特征在于，包括掉话故障信息上报装置和网络管理中心，所述掉话故障信息上报装置包括：
第一设定单元，用于预先设定要记录的掉话故障参数；
记录单元，用于根据所述第一设定单元中设定的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；和
上报单元，用于在该呼叫出现掉话故障时，将所述记录单元记录得到的数据上报给网络管理中心；
所述网络管理中心通过对所述上报单元上报的数据进行分析，来定位该呼叫产生掉话故障的原因。
30、如权利要求29所述的系统，其特征在于，由运营商在所述第一设定单元中设定要记录的掉话故障参数。
31、一种对掉话故障原因进行定位的系统，应用于宽带码分多址系统，其特征在于，包括掉话故障信息上报装置和网络管理中心，所述掉话故障信息上报装置包括：
第一设定单元，用于预先设定要记录的掉话故障参数；
第二设定单元，用于预先设定编解码方式；
记录单元，用于根据所述第一设定单元中设定的要记录的掉话故障参数，对一个呼叫过程中的对应各个参数值分别进行记录，并对应记录各个参数值的记录时间；
编码单元，用于在该呼叫出现掉话故障时，对所述记录单元记录得到的数据按照所述第二设定单元设定的编解码方式进行编码处理；
上报单元，用于将编码单元编码后形成的码流上报给网络管理中心；
所述网络管理中心包括：
解码单元，用于对所述上报单元上报的码流按照所述第二设定单元设定的编解码方式进行解码处理，以得到对应的数据；
分析单元，用于对所述解码单元解码得到的数据进行分析，来定位该呼叫产生掉话故障的原因。
32、如权利要求31所述的系统，其特征在于，由运营商在所述第一设定单元中设定要记录的掉话故障参数；并在第二设定单元中设定编解码方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2005100902957A CN100531254C (zh) | 2005-08-12 | 2005-08-12 | 掉话故障信息的上报方法、装置及掉话故障原因定位系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2005100902957A CN100531254C (zh) | 2005-08-12 | 2005-08-12 | 掉话故障信息的上报方法、装置及掉话故障原因定位系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1852347A CN1852347A (zh) | 2006-10-25 |
| CN100531254C true CN100531254C (zh) | 2009-08-19 |
Family
ID=37133814
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2005100902957A Active CN100531254C (zh) | 2005-08-12 | 2005-08-12 | 掉话故障信息的上报方法、装置及掉话故障原因定位系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100531254C (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWI664835B (zh) * | 2017-10-18 | 2019-07-01 | 中華電信股份有限公司 | 用於分析行動網路中用戶通訊中斷成因之智能方法 |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101212308A (zh) | 2006-12-30 | 2008-07-02 | 华为技术有限公司 | 一种统计上报方法 |
| CN102572888B (zh) * | 2010-12-24 | 2014-10-08 | 中国移动通信集团北京有限公司 | 道路掉话事件的确定方法及装置 |
| CN102612063A (zh) * | 2011-01-20 | 2012-07-25 | 华为技术有限公司 | 无线信道环境信息获取方法、装置和无线网络控制设备 |
| WO2013082762A1 (zh) * | 2011-12-06 | 2013-06-13 | 华为技术有限公司 | 一种通信方法及设备 |
| WO2015029269A1 (ja) | 2013-11-19 | 2015-03-05 | 株式会社小松製作所 | 通信管理システム及び通信管理方法 |
| CN105873094A (zh) * | 2015-12-08 | 2016-08-17 | 乐视移动智能信息技术（北京）有限公司 | 掉话测试方法及装置 |
| CN108156622A (zh) * | 2018-01-05 | 2018-06-12 | 武汉虹旭信息技术有限责任公司 | Lte网络小区信号质量及链路负荷的监测系统及其方法 |
| CN108494976A (zh) * | 2018-03-26 | 2018-09-04 | 安徽德特信息技术有限公司 | 基于信令分析的掉话故障自动警报上传系统及其方法 |
| CN110944347A (zh) * | 2019-10-23 | 2020-03-31 | 宇龙计算机通信科技(深圳)有限公司 | 一种掉话检测方法、装置、存储介质及终端 |
-
2005
- 2005-08-12 CN CNB2005100902957A patent/CN100531254C/zh active Active
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWI664835B (zh) * | 2017-10-18 | 2019-07-01 | 中華電信股份有限公司 | 用於分析行動網路中用戶通訊中斷成因之智能方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1852347A (zh) | 2006-10-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2425466C2 (ru) | Обнаружение соседних сот | |
| CN101273556B (zh) | 设置和改变用于调度分组数据业务的方法和装置 | |
| US20180035321A1 (en) | Method and system for collecting terminal measurement data | |
| US20070099561A1 (en) | System and method for tracking UMTS cell traffic | |
| Kreher | UMTS performance measurement: a practical guide to KPIs for the UTRAN environment | |
| CN100544275C (zh) | 检测无线网络空中接口 | |
| KR100932485B1 (ko) | 방송 및/또는 멀티캐스트 서비스를 제공하는 방법 | |
| CN113630794A (zh) | 多媒体广播多播服务中的测量 | |
| US20110064059A1 (en) | Apparatuses, Methods and Computer Program for Cell Reselection Evaluation | |
| CN102783200A (zh) | 通信系统中的覆盖的地理确定 | |
| US6885645B2 (en) | Method and mobile station for controlling bearer assignment | |
| EP3797545B1 (en) | Automatically optimising cell parameter of serving base station | |
| US8744432B2 (en) | Performance management for a telecommunication network | |
| CN103260176A (zh) | 最小化路测方法、网元及系统 | |
| US20050163074A1 (en) | Method of communication | |
| GB2429880A (en) | Method for testing performance of a mobile telecommunications network | |
| CN100531254C (zh) | 掉话故障信息的上报方法、装置及掉话故障原因定位系统 | |
| CN101790180A (zh) | 一种基于信令的跟踪方法、系统及设备 | |
| US8098586B2 (en) | Determining configuration parameters of a mobile network | |
| EP1215928A2 (en) | Intelligent optimisation system and method of optimising communication performance in a cellular telecommunications network | |
| CN106993314A (zh) | 一种电路域交换回落的回落性能判决方法和装置 | |
| CN103748912A (zh) | 频点测量控制方法、终端和基站 | |
| CN100403837C (zh) | 一种wcdma系统中小区更新故障的上报方法 | |
| CN103428751A (zh) | 一种最小化路测服务质量连续性测量方法及装置 | |
| CN100396136C (zh) | 一种从3g到2g系统切换过程中故障的上报方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |