CN100571267C - 一种通用多协议关联方法 - Google Patents
一种通用多协议关联方法 Download PDFInfo
- Publication number
- CN100571267C CN100571267C CNB2005101168994A CN200510116899A CN100571267C CN 100571267 C CN100571267 C CN 100571267C CN B2005101168994 A CNB2005101168994 A CN B2005101168994A CN 200510116899 A CN200510116899 A CN 200510116899A CN 100571267 C CN100571267 C CN 100571267C
- Authority
- CN
- China
- Prior art keywords
- detail record
- incidence relation
- affairs
- tdr
- affairs detail
- 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
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种通用多协议关联方法,根据协议类型确定并定义协议间的关联关系,根据协议间关联关系确定事务详细记录(TDR)的关联关系,TDR的关联关系具有可传递性,根据任意一个TDR,可以找到跟该TDR直接或者间接关联的所有TDR,这些互相关联的TDR,共同组成一个完整的业务过程。对关联出来的完整业务过程,显示其业务流程图,对业务流程图进行分析,可以定位网络故障。本发明所述方法,不但通用性好、适应性强,还可扩展、可维护,完全可以适应电信网络和电信业务复杂多变的特点,满足对电信网络进行多协议关联分析,快速准确定位网络故障的实际需要。
Description
技术领域
本发明涉及电信7号信令网和数据网络的协议分析领域,具体涉及一种通用多协议关联(MPRA,Multi-Protocol Relating-Analysis)方法。
背景技术
今天,电信事业得到了突飞猛进的发展,各电信运营商对人们除了提供传统的语音业务以外,还不断推出各种新的数据业务,从根本上改变了人们的工作和生活方式。电信网络的健康发展,离不开各种信令仪表的支持。信令仪表对电信网中的信令消息进行采集和协议分析、可以快速定位网络的故障,对网络的开通、扩容和日常维护提供全方位的支持。电信网络的发展同时也促进了信令仪表的发展,现在,很多信令仪表都进化为系统,比如现在的信令监测系统。
无论是信令仪表还是信令监测系统,其核心功能是一致的:都是通过对信令网络中的信令消息进行采集、对采集到的信令进行协议分析,并根据各种协议的规则TDR(Transaction Detail Record,合成事务详细记录),对于传统的语音呼叫业务又可称为CDR(Call Detail Record,呼叫详细记录)。TDR包含用户号码、事务开始时间和结束时间、业务路由、业务结果、业务失败原因等信息,对事务详细记录进一步进行多角度的统计分析、可以帮助网络运营商对网络进行深层次的网络管理、业务管理、用户管理以及网络优化、网络规划、网络设计。
上述TDR一般是基于单种协议分析基础之上的。但是现实中一个电信业务常常是多种协议、跨越多段路由配合完成的,对这种复杂业务的完整过程分析就需要对该业务过程中的多种协议的TDR进行关联分析,得到该业务的完整信令配合流程,这就需要一种多协议关联的技术。多协议关联技术已经成为电信网络协议分析领域的研究热点。
目前,领域内实现多协议关联的普遍方法是:对不同的业务定制不同的关联分析流程和分析方法。这种方法虽然在一定程度上也能达到多协议关联的目的,但是因为其分析方法是跟具体协议相关的,具有以下缺点:
1)适应性差,不能满足电信业务多样性的需要。实际上,电信业务过程是复杂多变的,即使是同一种电信业务,也会因为运营商不同、网络规模不同或者组网方式不同而导致一个完整的业务过程各不相同,而一个固定的分析流程和方法是不能满足对不同业务过程的分析需要的。
2)可扩展性、可维护性差,电信业务的发展是日新月异的,每当出现一种新的业务,都需要重新定制一套关联分析的流程,需要较长的周期,不能快速满足用户的需求。
由于以上两个缺点的存在,传统的多协议关联方法不能很好的满足电信网络的日常维护和故障定位的实际需要。
发明内容
为了克服传统多协议关联方法存在的问题,本发明提出了一种协议关联关系可定义、协议关联分析过程跟具体协议无关的通用多协议关联方法。
本发明具体是这样实现的:
步骤1、定义协议间关联关系,建立协议关联关系表;
步骤2、对被监测电信网络的信令消息进行采集,发送到协议解码模块;
步骤3、对每条信令消息进行协议解码,并按照具体的协议规则合成本协议事务详细记录,并提取用于关联分析的关键信息,进一步合成关联分析通用事务详细记录,发送到协议关联分析模块;
步骤4、依次对所有的关联分析通用事务详细记录进行协议关联分析,对每个事务详细记录按照协议关联关系表从已分析事务详细记录表中查找跟本事务详细记录相关联的其它事务详细记录,记录到事务详细记录关联关系表;
步骤5、根据用户选择的事务详细记录,查找所有跟该事务详细记录直接或者间接关联的事务详细记录,合成完整业务过程,并按照用户选择的显示规则来输出完整业务流程图。
所述步骤1中的协议关联关系通过字段:协议类型、关联主键、关联关系类型和关联关系生存期定义;
所述字段的赋值可以根据实际情况进行调整。通过协议类型中规定的关联关系类型计算关联关系是否成立来确定协议之间的事务详细记录是否存在关联关系;
所述关联关系类型可以被定义或扩展,基本类型包括等于、包含和被包含。
所述协议解码时,
首先在通用事务详细记录中正确填写本协议的协议类型;
其次应定义本协议事务详细记录的关联主键,并将协议解码过程得到的关联主键值填写到关联主键表;
最后填写通用事务详细记录的开始时间和结束时间。
所述通用的事务详细记录的定义包括如下字段:
协议类型、当前事务详细记录的索引、事务详细记录开始时间、事务详细记录结束时间、关联主键表、关联事务详细记录索引表和扩展事务详细记录;
所述关联主键表包括:关联主键名称和关联主键取值。
所述步骤4中关联分析具体包括如下步骤:
(1)先判断当前事务详细记录的协议类型ProType;
(2)根据ProType查找协议关联关系表,检查是否存在跟本协议类型存在关联关系的协议RalatedProType;
(3)如果RalatedProType不存在,则关联分析处理结束;
如果找到了,则进一步进行步骤(4)处理;
(4)根据RalatedProType去事务详细记录索引表中查找协议类型为RalatedProType的事务详细记录索引,如果没有找到符合条件的事务详细记录,则关联分析处理结束;
如果找到了,则进一步进行步骤(5)处理;
(5)根据两个事务详细记录的关联主键和关联关系类型以及关联关系生存期计算关联关系是否成立:
如果关联关系成立,则分别在两个事务详细记录的关联事务详细记录索引表中记录对方的索引值;
如果关联关系不成立,则不记录关联关系;
(6)继续执行步骤(4),直到找到所有的关联事务详细记录。
所述业务流程图包括信令消息时间、信令协议类型、业务路由和业务结果。所述查找所有跟该事务详细记录直接或者间接关联的事务详细记录,具体包括如下步骤,
(1)每个事务详细记录的关联事务详细记录索引表都记录了跟自己直接关联的事务详细记录索引,根据这些索引可以迅速找到直接关联的事务详细记录;
(2)对每一个跟当前事务详细记录直接关联的事务详细记录,分别查找跟这些事务详细记录直接关联的事务详细记录,记录到临时的间接关联事务详细记录索引表;
(3)对每一个跟当前事务详细记录间接关联的事务详细记录,也分别查找其直接关联事务详细记录,记录到临时的间接关联事务详细记录索引表,依次类推。
采用本发明所述的通用多协议关联方法,具有通用性好、适应性强、可扩展可维护等优点,完全可以适应电信网络和电信业务的复杂多变的特点、满足对电信网络进行多协议关联分析、快速准确定位网络故障的实际需要。
附图说明
图1是本发明的总体处理流程图;
图2是协议关联分析模块对当前TDR进行多协议关联分析的处理流程图。
具体实施方式
本发明所述方法,通过以下模块来具体实现的,所述模块包括:协议关联关系定义模块、信令采集模块、协议解码模块、用户输入处理模块、协议关联分析模块和关联结果处理模块等。
本发明所述方法的核心思想体现如下:
1)据协议类型确定并定义协议间关联关系;
2)根据协议间关联关系确定TDR的关联关系,TDR的关联关系具有可传递性,根据任意一个TDR,可以找到跟该TDR直接或者间接关联的所有TDR,这些互相关联的TDR,共同组成一个完整的业务过程。
3)对关联出来的完整业务过程,显示其业务流程图,对业务流程图进行分析,可以定位网络故障;也可以将完整业务过程进行保存,以满足日后分析的需要。
所述方法的总体处理流程见图1,具体如下:
1)定义协议关联关系表:协议间关联关系可以通过协议类型、关联主键、关联关系类型、关联关系生存期等字段明确定义,各字段的实际赋值可根据网络的实际情况进行调整;
2)采用信令采集模块对被监测电信网络的信令消息进行采集,发送到协议解码模块;
3)在协议解码模块中对每条信令消息进行协议解码,并按照协议规则合成本协议事务详细记录,并提取协议类型、关联主键及取值、事务开始时间、事务结束时间等用于关联分析的关键信息,进一步合成关联分析通用TDR(详见后文具体实施方式),发送到协议关联分析模块;
4)采用协议关联分析模块依次对所有的TDR进行协议关联分析,对每个TDR按照协议关联关系表从已分析TDR表中查找跟本TDR相关联的其它TDR,记录到TDR关联关系表。
5)步骤3)生成的TDR和步骤4)生成的TDR关联关系表都输入到关联结果处理模块。该模块的主要功能是根据用户选择的TDR,查找所有跟该TDR直接或者间接关联的TDR,合成完整业务过程,并按照用户选择的显示规则来输出完整业务流程图。完整业务流程图包括信令消息时间、信令协议类型、业务路由、业务结果等信息,用户通过分析这些信息可以直观的发现非正常业务过程、定位网络故障。
所述通用多协议关联方法,具体包括:
1、定义协议关联关系
协议关联关系的定义是实现多协议关联的基础。协议关联关系定义模块要求能够灵活的定义,包括关联关系的增加、删除、修改和查询,不同协议之间的关联关系,以满足在不同业务、不同网络规模、不同组网方式的情况下,对协议之间的不同关联关系都能够进行正确描述和定义。
协议关联关系可以用下面的一个结构来描述:
struct ProRelation
{
string ProTypeOne; //协议类型一
string RelationKeyOne;//关联主键一
string ProTypeTwo; //协议类型二
string RelationKeyTwo;//关联主键二
int RelationType; //关联关系类型
int Relat ionTTL; //关联关系生存期
}
说明:
1)所有的协议都有唯一的协议名称来跟其它的协议互相区分,结构中的ProTypeOne和ProTypeTwo就是两种协议的协议名称,表示这两种协议存在着关联关系。
2)每种协议的TDR都有一个或者多个关联主键RelationKey,用来确定该TDR是否跟其它协议的TDR存在关联关系。结构中的RelationKeyOne是ProTypeOne的TDR中的关联主键,RelationKeyTwo是ProTypeTwo的TDR中的关联主键。在确定两种协议的TDR是否存在关联关系时,需要按照RelationType中规定的关联关系类型来计算关联关系是否成立。
3)关联关系类型也是可以定义和可扩展的。基本的关联关系类型有“等于”、“包含”、“被包含”等。比如当关联关系为“等于”时,只有关联主键一的值等于关联主键二的值,两个TDR的关联关系才成立,否则不成立。
4)在实际中许多关联关系是存在时间效应的,关联关系生存期RelationTTL定义了该关联关系允许的两个TDR的最大时间差。
2、信令采集
采用信令采集模块负责从信令链路上采集信令消息,并将采集到的信令消息提交给协议解码模块进行TDR合成。
3、协议解码
协议解码是根据各具体协议的规则,进行TDR的合成,并将合成的TDR提交给协议关联分析模块,TDR的结构采用上述定义的通用TDR结构。
为了保证后续的多协议关联正确进行,协议解码需要重点注意以下几个方面:
1)在TDR中正确填写本协议的协议类型;
2)定义本协议TDR的关联主键,并将协议解码过程中得到的关联主键值填写到关联主键表;
3)填写TDR的开始时间和结束时间。
TDR提交到协议关联分析模块后,根据协议类型、关联主键和开始结束时间进行TDR间的关联关系计算。
4、协议关联分析
协议关联分析是本发明最核心的模块。要实现多种协议的统一关联分析,首先要保证所有的TDR结构定义是一致的。
下面给出了一种通用TDR的定义:
struct TDR{
string ProType; //协议类型
int TDRIndex; //当前TDR的索引
BYTE BeginTime[8]; //TDR开始时间
BYTE EndTime[8]; //TDR结束时间
RelationKeyTable KeyTable;//关联主键表
vector<int>RelatedTDRTable;//关联TDR索引表
void *ExtTDR; //扩展TDR
}
其中RelationKeyTable的定义为:
vector<KeyPair>RelationKeyTable;
struct KeyPair{
string RelationKey; //关联主键名称
string Value; //关联主键取值
}
说明:
1)TDR结构中的ProType记录了本TDR的协议类型,在进行关联分析时,需要根据协议类型查找协议关联关系定义表。
2)多协议关联关系分析模块记录了所有的TDR,并为每个TDR分配了唯一的索引值TDRIndex,保证每个TDR都能相互区分。
3)上述已经阐述,每个TDR都有一个或者多个关联主键,KeyTable就是用来记录当前TDR的所有关联主键。一个关联主键由主键名称和主键取值两部分组成,这样就保证了两个存在关联关系的主键可以有不同的名称。
4)TDR开始时间和TDR结束时间是进行关联关系生存期判断的基础。
5)RelatedTDRTable用来记录所有跟本TDR存在关联关系的其它TDR的索引表。
6)因为每个TDR都有本协议的专有信息,这些专有信息可以保存在自定义TDR中,并以指针的方式挂靠在通用TDR的ExtTDR字段。
协议关联分析模块对协议解码模块输入的每个TDR依次进行关联分析,从而得到所有TDR的关联关系。
下面按照附图2所示,详细介绍对一个TDR进行关联分析的步骤:
1)先判断当前TDR的协议类型ProType;
2)根据ProType查找协议关联关系表,检查是否存在跟本协议类型存在关联关系的协议RalatedProType;
3)如果RalatedProType不存在,则关联分析处理结束。如果找到了,则进一步进行步骤4)处理;
4)根据RalatedProType去TDR索引表中查找协议类型为RalatedProType的TDR,如果没有找到符合条件的TDR,则关联分析处理结束。如果找到了,则进一步进行步骤5)处理;
5)根据两个TDR的关联主键和关联关系类型以及关联关系生存期计算关联关系是否成立。如果关联关系成立,则分别在两个TDR的关联TDR索引表中记录对方的索引值。如果关联关系不成立,则不记录关联关系。
6)续执行步骤4),直到找到所有的关联TDR。
5、用户输入处理
所述处理步骤是在用户输入处理模块中完成的,具体包括:接收和解释用户的指令,如将步骤5)中用户选择需要进行关联分析的TDR输入到关联结果处理模块。
6、关联结果处理
所述处理步骤是在关联结果处理模块中完成,所述模块的主要功能是根据用户选择的TDR,查找所有跟该TDR直接或者间接关联的TDR,并按照用户选择的显示规则来输出业务过程流程图。
完整业务流程图包括信令消息时间、信令协议类型、业务路由、业务结果等信息,通过这些信息可以直观的发现非正常业务过程、定位网络故障。
本步骤的核心是快速查找到跟指定TDR直接或者间接相关联的TDR,具体步骤是:
1)每个TDR的关联TDR索引表都记录了跟自己直接关联的TDR索引。根据这些索引可以迅速找到直接关联的TDR。
2)对每一个跟当前TDR直接关联的TDR,分别查找跟这些TDR直接关联的TDR,记录到临时的间接关联TDR索引表;
3)对每一个跟当前TDR间接关联的TDR,也分别查找其直接关联TDR,记录到临时的间接关联TDR索引表,依次类推。
找到所有的关联TDR后,就可以得到整个业务过程的所有TDR和所有信令消息了,关联结果模块根据用户指定的显示规则,对信令消息进行排序,按照时间顺序绘制完整业务流程图,并显示信令消息时间、信令协议类型、业务路由、业务结果等信息,用来进行网络故障定位。也可以将完整业务过程进行保存,以满足日后分析的需要。
上面结合附图对本方法的实施方式进行了描述,但是本方法并不局限于上述的具体实施方式。上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本方法的启示下,在不脱离本方法宗旨和权利要求所保护的范围情况下,还可以作出很多变形,这些均属于本方法的保护之内。
Claims (8)
1、一种通用多协议关联方法,其特征在于,包括:
步骤1、定义协议间关联关系,建立协议关联关系表;
步骤2、对被监测电信网络的信令消息进行采集,发送到协议解码模块;
步骤3、对每条信令消息进行协议解码,并按照具体的协议规则合成本协议事务详细记录,并提取用于关联分析的关键信息,进一步合成关联分析通用事务详细记录,发送到协议关联分析模块;
步骤4、依次对所有的关联分析通用事务详细记录进行协议关联分析,对每个事务详细记录按照协议关联关系表从已分析事务详细记录表中查找跟本事务详细记录相关联的其它事务详细记录,记录到事务详细记录关联关系表;
步骤5、根据用户选择的事务详细记录,查找所有跟该事务详细记录直接或者间接关联的事务详细记录,合成完整业务过程,并按照用户选择的显示规则来输出完整业务流程图。
2、如权利要求1所述的通用多协议关联方法,其特征在于:
所述步骤1中的协议关联关系通过字段:协议类型、关联主键、关联关系类型和关联关系生存期定义;
所述字段的赋值可以根据实际情况进行调整。
3、如权利要求2所述的通用多协议关联方法,其特征在于:
通过协议关联关系中定义的关联关系类型计算关联关系是否成立来确定协议之间的事务详细记录是否存在关联关系;
所述关联关系类型可以被定义或扩展,基本类型包括等于、包含和被包含。
4、如权利要求1所述的通用多协议关联方法,其特征在于:
所述协议解码时,
首先在通用事务详细记录中正确填写本协议的协议类型;
其次应定义本协议事务详细记录的关联主键,并将协议解码过程得到的关联主键值填写到关联主键表;
最后填写通用事务详细记录的开始时间和结束时间。
5、如权利要求1所述的通用多协议关联方法,其特征在于:
所述通用的事务详细记录的定义包括如下字段:协议类型、当前事务详细记录的索引、事务详细记录开始时间、事务详细记录结束时间、关联主键表、关联事务详细记录索引表和扩展事务详细记录;
所述关联主键表包括:关联主键名称和关联主键取值。
6、如权利要求1所述的通用多协议关联方法,其特征在于:
所述步骤4中关联分析具体包括如下步骤:
(1)先判断当前事务详细记录的协议类型ProType;
(2)根据ProType查找协议关联关系表,检查是否存在跟本协议类型存在关联关系的协议RalatedProType;
(3)如果RalatedProType不存在,则关联分析处理结束;
如果找到了,则进一步进行步骤(4)处理;
(4)根据RalatedProType去事务详细记录索引表中查找协议类型为RalatedProType的事务详细记录索引,如果没有找到符合条件的事务详细记录,则关联分析处理结束;
如果找到了,则进一步进行步骤(5)处理;
(5)根据两个事务详细记录的关联主键和关联关系类型以及关联关系生存期计算关联关系是否成立:
如果关联关系成立,则分别在两个事务详细记录的关联事务详细记录索引表中记录对方的索引值;
如果关联关系不成立,则不记录关联关系;
(6)继续执行步骤(4),直到找到所有的关联事务详细记录。
7、如权利要求1所述的通用多协议关联方法,其特征在于:
所述业务流程图包含信令消息时间、信令协议类型、业务路由和业务结果。
8、根据权利要求1或7所述的通用多协议关联方法,其特征在于:
所述查找所有跟该事务详细记录直接或者间接关联的事务详细记录,具体包括如下步骤,
(1)每个事务详细记录的关联事务详细记录索引表都记录了跟自己直接关联的事务详细记录索引,根据这些索引可以迅速找到直接关联的事务详细记录;
(2)对每一个跟当前事务详细记录直接关联的事务详细记录,分别查找跟这些事务详细记录直接关联的事务详细记录,记录到临时的间接关联事务详细记录索引表;
(3)对每一个跟当前事务详细记录间接关联的事务详细记录,也分别查找其直接关联事务详细记录,记录到临时的间接关联事务详细记录索引表,依次类推。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005101168994A CN100571267C (zh) | 2005-10-31 | 2005-10-31 | 一种通用多协议关联方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005101168994A CN100571267C (zh) | 2005-10-31 | 2005-10-31 | 一种通用多协议关联方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1960367A CN1960367A (zh) | 2007-05-09 |
CN100571267C true CN100571267C (zh) | 2009-12-16 |
Family
ID=38071858
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2005101168994A Active CN100571267C (zh) | 2005-10-31 | 2005-10-31 | 一种通用多协议关联方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100571267C (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101827068B (zh) * | 2009-03-02 | 2012-07-11 | 中国移动通信集团公司 | 一种业务场景还原方法与装置 |
CN101902336B (zh) * | 2009-05-27 | 2012-07-18 | 北京启明星辰信息技术股份有限公司 | 一种基于规则模型的安全事件关联分析系统及方法 |
CN102724645B (zh) * | 2012-06-29 | 2015-03-18 | 深圳市博瑞得科技有限公司 | Gsm网络短信全流程多接口关联方法 |
CN105933929B (zh) * | 2016-04-20 | 2019-04-05 | 重庆重邮汇测通信技术有限公司 | 一种适用于lte-a网络空口监测仪表的多协议关联方法及系统 |
CN109561462A (zh) * | 2019-01-24 | 2019-04-02 | 重庆重邮汇测电子技术研究院有限公司 | 一种适用于5g终端模拟器的多协议关联方法及系统 |
CN112491595B (zh) * | 2020-11-12 | 2023-04-07 | 杭州迪普信息技术有限公司 | 故障区域定位方法、装置、设备及计算机可读存储介质 |
-
2005
- 2005-10-31 CN CNB2005101168994A patent/CN100571267C/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN1960367A (zh) | 2007-05-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100571267C (zh) | 一种通用多协议关联方法 | |
CN1081863C (zh) | 个人信息服务系统 | |
US6189031B1 (en) | Method and system for emulating a signaling point for testing a telecommunications network | |
US6483812B1 (en) | Token ring network topology discovery and display | |
WO2008017221A1 (fr) | Réseau de service de valeur ajoutée, serveur rvi et procédé permettant d'analyser le suivi de processus en temps réel | |
WO2014008694A1 (zh) | 一种实现ps域分布式架构的信令监测装置 | |
CN104144069B (zh) | 无线侧呼叫数据记录与用户业务行为关联的方法和装置 | |
CN102378151A (zh) | 信息共享平台及方法 | |
CN102694895A (zh) | 来电原因的判定方法及装置 | |
CN101453520A (zh) | 一种检测与拦截骚扰电话的系统及方法 | |
EP0720341B1 (en) | Method and system for customizing communications over a network | |
CN101771757A (zh) | 一种检测与拦截骚扰电话的方法 | |
CN110517163A (zh) | 一种配网馈线组分析方法 | |
CN101764892A (zh) | 一种检测与拦截骚扰电话的系统 | |
CN101409886B (zh) | 一种关联彩信事件的方法 | |
CN103414593A (zh) | 基于网络资源的跨专业工程网元级联屏蔽系统及屏蔽方法 | |
CN102547711B (zh) | 一种检测与拦截ip信令网络中骚扰电话的系统及方法 | |
JPH09321869A (ja) | 呼情報試験方法とその装置 | |
CN100349471C (zh) | 程控交换机主叫号码分析方法 | |
JP4080747B2 (ja) | 複数のシグナリング・ポイントから1つのポイント(複数ポイントからポイントへ)へのパケット放送ネットワークによるss7シグナリング・メッセージ内容の転送 | |
CN101742486B (zh) | 标签通信方法及支持该通信方法的手机和系统 | |
TWI301956B (zh) | ||
CN113660119A (zh) | 物联网终端状态数据追溯方法及其系统 | |
CN113055244A (zh) | 一种网络交换机端口监测分析管理控制方法 | |
US20060277306A1 (en) | Apparatus and method for data extraction |
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 |