本发明涉及网络通信技术领域,尤其涉及一种端到端通信的时延测量方法及装置,计算机可读存储介质。
背景技术
5g网络作为第五代移动通信网络,面临高速率、端到端低时延、稿可靠性、大规模连接等方面的挑战。
其中,itu、imt-2020推进组等国内外5g研究组织机构均对5g提出了毫秒级的端到端时延要求,对于端到端时延的定义是:数据包从离开源节点的应用层是算起一直抵达并被目的节点的应用层成功接收,一共经历的时间长度。端到端时延包括空口时延、核心网时延和pdn网络时延。在现有技术中,各种通信系统的时延具体为:理想情况下端到端时延为1ms,典型端到端时延为5-10ms左右。我们目前使用的4g网络,端到端理想时延是10ms左右,lte的端到端时延是50-100ms,这意味着5g需要将端到端时延缩短为4g的十分之一。
基于现有的通信技术中,系统的通信时延远远没有达到5g网络的要求,若想要实现对通信时延的监控调整,则需要对系统中所交互的业务流程进行监控分析,因此,急需提供一种能够分析通信过程中的端到端整体时延统计数据、时间切片统计数据,并以直观的形式展示给用户的分析方法。
技术实现要素:
为了解决上述的技术问题,本发明实施例提供的端到端通信的时延测量方法及装置、计算机可读存储介质,以解决在端到端通信的过程中无法实现对通信时延的定位分析计算,导致系统的时延较大,降低了用户的使用体验的技术问题。
为解决上述技术问题,本发明实施例提供一种端到端通信的时延测量方法,包括:
监测端到端通信系统的发送端发送的业务通信信令数据,并记录发送业务通信信令数据的发送时间以及所述业务通信信令数据对应的业务类型;
识别端到端通信系统的接收端是否接收到所述业务通信信令数据,若接收到,并记录所述接收端接收到所述业务通信信令数据的接收时间;
根据记录的所述发送时间和接收时间计算所述端到端通信系统通信的信令时延。
本发明实施例还提供一种端到端通信的时延测量装置,包括:
数据监测模块,用于监测端到端通信系统的发送端发送的业务通信信令数据,并记录发送业务通信信令数据的发送时间以及所述业务通信信令数据对应的业务类型;
识别模块,用于识别端到端通信系统的接收端是否接收到所述业务通信信令数据,若接收到,并记录所述接收端接收到所述业务通信信令数据的接收时间;
时延计算模块,用于根据记录的所述发送时间和接收时间计算所述端到端通信系统通信的信令时延。
本发明实施例还提供一种端到端通信的时延测量装置,所述装置包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的时延分析程序,所述时延分析程序被所述处理器执行时实现上所述的端到端通信的时延测量方法的步骤。
本发明实施例还提供一种计算机存储介质,所述计算机可读存储介质上存储有时延分析程序,所述时延分析程序被执行时实现前述的端到端通信的时延测量方法的步骤。
本发明的有益效果是:
根据本发明实施例提供的端到端通信的时延测量方法及装置、计算机可读存储介质,通过监测发送端上发送的业务通信信令数据,同时记录对应的发送时间,在识别到接收端接收到该业务通信信令数据时,记录对应的接收时间,然后根据接收时间和发送时间计算通信时延,从而方便地实现了端到端通信系统的通信时延的分析,由于是通过系统本身交互的业务信令数据进行的时延分析,这样不仅实现了对系统的时延分析,还便于用户了解通信网络时延现状以及系统的通信质量,也缩短了分析时延过程的耗时时长;通过对业务通信信令数据的跟踪分析,为通信人员提供的网络维护的有力依据,提高了维修效率。
附图说明
图1为本发明实施例一提供的端到端通信的时延测量方法的流程图;
图2为本发明实施例提供的信令模型定义示意图;
图3为本发明实施例提供的一种信令模型;
图4为本发明实施例一提供的根据信令模型对信令数据提取的流程图;
图5为本发明实施例一提供的一种业务切片计算示例;
图6为本发明实施例一提供的计算通信时延的流程图;
图7为本发明实施例一提供的时延分析报告展示示意图;
图8为本发明实施例一提供的一种时延分析报告展示示例;
图9为本发明实施例二提供的端到端通信的时延测量装置的结构框图;
图10为本发明实施例三提供的端到端通信的时延测量装置的结构框图。
具体实施方式
下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。
实施例一:
请参见图1,图1为本实施例提供的端到端通信的时延测量方法的流程图,该方法具体可以基于现有的网管管理系统来实现,具体是通过监控系统中的起始端和目的端之间的数据交互来实现时延的分析,其处理步骤具体包括:
s101,监测端到端通信系统中的发送端所发送的业务通信信令数据,并记录发送时间以及对应的业务类型。
s102,识别端到端通信系统的接收端是否接收到所述业务通信信令数据,若存在,则记录对应的接收时间。
s103,根据所述接收时间和发送时间计算通信时延。
在本实施例中,所述端到端通信系统中的发送端指的是发送数据包的网元,而接收端指的是接收到数据包且被应用或进行分析处理的网元,整个端到端通信系统可以包括两个网元,也可以包括多个网元,当包括多个网元时,发送端指的是系统中的第一个网元,接收端指的是系统中的最后一个网元,其他的作为实现第一、第二网元的连接网元。
在本实施例中,所述业务通信信令数据指的是端到端通信系统实现业务交互时的业务传输数据,该业务传输数据是通过各种通信信令请求数据的发送和反馈接收等,因此,该业务通信信令数据是业务输出传输必须的信令。当然,在实际应用中,该业务通信信令数据还可以是用户为分析端到端系统之间的时延时,专门设为其设置特定通信信令。
在步骤s102中,对于从接收端上识别是否接收到发送端发送出来的业务通信信令数据,具体是通过建立好的业务模型来进行识别,当识别出在接收端上已经接收到的与该业务模型相匹配的数据时,则获取接收该数据是上报的接收时间。
在实际应用中,所述业务模型具体是根据现有的3gpp通信协议建立,然后在识别接收端上是否存在相同的业务数据具体是,根据步骤s101中记录的业务类型从众多业务模型中选择与该业务类型对应的业务模型,根据该业务模型从所述接收端中识别是否存在与所述业务模型相匹配的业务流程,并根据识别的结果从所述业务流程提取对应的通信信令数据,记录对应的接收时间。
在本实施例中,所述业务模型具体包括信令模型,所述信令模型包括用于触发所述业务流程所需要的起始信令组、中间信令组和结束信令组,在实际应用中,不同的业务交互,其使用的信令组也是不相同的,因此,所述所述识别端到端通信系统的接收端是否接收到所述业务通信信令数据具体还可以通过信令模型来实现。
优选的,根据信令模型得到实现该业务交互时所需要的信令组,根据所述信令组从所述通信信令数据确定与所述起始信令组对应的起始信令;
根据所述起始信令查找与该起始信令对应的结束信令组;
根据所述结束信令组对所述通信信令数据进行筛选,确定所述通信信令数据中的结束信令,并记录所述结束信令被所述接收端确认接收到的接收时间。
在实际应用中,在对端到端通信系统中的业务通信信令数据进行时延分析时,首先要确定对应的业务类型以及对应的信令模型,根据信令模型来提取对应的信令数据,最后再对提取到的信令数据进行时延的分析,对于信令模型具体如图2所示,该图左半部分展示的是根据实际的业务流程抽象出来的信令流程示意图,它包含三个重要的组成部分:
起始信令:信令流程的触发信令,也可以说是流程的第一条信令。
结束信令:信令流程的最后一条信令,该条信令标识流程的完结。如图中最下面所示的结束信令1、结束信令2、……、结束信令n,这表示结束信令有多种可能。这是因为流程有可能正常结束,也有可能异常结束(比如流程失败了),或其他的一些情况,结束信令往往不唯一。
中间信令:除起始、结束信令之外的,在网元间传递和转换的信令。该部分信令的特点是某些信令会根据不同的组网、业务等情况,会条件的出现。鉴于这个特点,该部分信令可以分成两大类:流程必定包含的信令和流程可能包含的信令。
依据上面的信令流程,可以映射得到图2右侧的信令流程模型。该模型有起始信令、中间信令(必有)、中间信令(可有)、结束信令组。起始信令标识该流程的起始;中间信令(必有)包含该流程中必定包含的信令;中间信令(可有)包含该流程中条件出现的信令;结束信令组,定义了若干条与流程起始信令对应的结束信令(每条结束信令都可能是该流程的结束)。
由于信令模型是提取信令数据的关键,为了更好的理解,本发明实施例提供的分析方法,下面会自行定义一个信令模型,如图3所示:
起始信令:
attachrequest
结束信令组:
attachreject(图3中没有,图3是个正常流程)
modifybearerresponse
中间信令(必有):
createsessionrequest
createsessionresponse
initialcontextsetuprequest
…………
中间信令(可有)
deletesessionrequest
deletesessionresponse
…………
根据上述的信令模型并结合具体的业务,可以定义出若干个业务流程,根据上述的信令模型进行信令数据的提取和分析,具体如图4所示:
s401、遍历采集到的信令数据集合。
具体的,根据信令模型中的起始信令组合、中间信令组合结束信令组对获取到的信令数据集合中的信令组进行划分,在一个业务流程中,至少会存在三种信令,为了便于后续的查询操作,因此需要根据信令模型对所述信令数据集合进行信令划分。
s402、判断提取出的集合中的一条信令是否能和某个配置的业务信令流程的起始信令相匹配,如果不能,则继续遍历采集到的信令数据集合。
s403、如果信令是某个业务流程的起始信令,则找到与起始信令对应的结束信令组。
s404、遍历结束信令组,从若干结束信令中提取出一条结束信令,然后从信令集合中当前信令的下一条开始索引结束信令,如果没有索引到结束信令,则继续遍历结束信令,直到遍历结束。
s405、如果索引到了结束信令,则依据起始信令编号和结束信令编号将这一闭区间的信令全部提取出来。
s406、流程清洗。根据业务模型将与所述业务模型不匹配的业务流程从所述业务通信信令数据中剔除。
在实际应用中,在流程提取前,会对多个网元上报的信令进行排序,排序主要的依据是单网元信令的上报顺序,以及信令的时间戳,由于网元时间的不一致以及业务的复杂性(比如正在做数据业务,之间来了电话),都会导致提取的流程中可能会夹杂不是本流程的信令。可以利用之前业务流程中定义的信令(起始、结束信令以及中间信令)对流程进行清洗,即将流程中不在其中的信令移除。
s407、将清洗后的信令提取出来,并将起始、结束信令打上标记(标注哪条是起始信令、哪条是结束信令),构建信令流程。
s408、继续遍历采集到的信令数据集合(不是从结束信令开始遍历,而是从起始信令的下一条开始),直到遍历到最后一条信令,将所有的信令流程都提取出来为止。
在实际应用中,所述结束信令组包括结束一个业务所有可能出现的情况,因此,在计算时延之前,还通过上述的方法对信令数据中的信令进行遍历,判断每个信令的实际情况,若选择计算时延的信令属于业务异常结束是的结束信令,这时所计算出来的时延就会出在非常大的误差,其参考价值也就非常低,最终会误导了网络维护人员确定的优化方案,若是异常的情况则需要重新监控获取新的信令数据进行时延的分析。
在本实施例中,获取到的信令模型可能是属于端到端通信系统的包括所有业务交互的信令模型,这时若根据这样的信令模型时延的分析时就会出现心痛的分析信息量过大,为了更好的避免这种情况,本发明提供的方法还包括将获取到的业务通信信令数据进行切片处理,优选的,按照业务的类型进行切片,每个时间切片都对对应一个业务,也即是可以理解为业务流程中的子流程,然后根据子流程的类型进行模型配置,其中对于信令数据的提取分析流程的方法与图4中的业务流程一致,如图5所示,是本实施例给出一种业务切片计算示例。
在本实施例中,在提取到对应的数据以及信令的发送、接收时间后,根据得到的时间计算对应的时延,并将分析的结果显示给网络维护人员进行对系统时延的优化处理,如图6所示:
s601,业务流程的结束信令时间减去起始信令时间,为整体业务流程的时延数据。
s602、切片业务对应的结束信令时间减去起始信令时间,为对应切片时延数据。
s603、遍历信令文件中相同业务流程和切片的时延,计算均值。
s604、统计时延分析结果直观展示给用户,效果参见图7。
s605、给出时延分析报告,示例参加图8。
s606、时延分析结果支持导出为文件,格式可以为html、xls等。
在本实施例中,除了通过上述的步骤直接分析业务的交互信令数据实现时延分析之外,还可以通过设置标识符的方式进行分析,具体的通过在所述发送端发送的所述业务通信信令数据中设置信令标识符;监测所述接收端中的业务通信信令数据中是否存在所述信令标识符;若存在,则获取设置有所述信令标识符的业务通信信令数据被接收到时的接收时间。
本发明实施例提供的端到端通信的时延测量方法,通过监测发送端上发送的业务通信信令数据,同时记录对应的发送时间,在识别到接收端接收到该业务通信信令数据时,记录对应的接收时间,然后根据接收时间和发送时间计算通信时延,从而方便地实现了端到端通信系统的通信时延的分析,由于是通过系统本身交互的业务信令数据进行的时延分析,这样不仅实现了对系统的时延分析,还便于用户了解通信网络时延现状以及系统的通信质量,也缩短了分析时延过程的耗时时长;通过对业务通信信令数据的跟踪分析,为通信人员提供的网络维护的有力依据,提高了维修效率。
实施例二:
请参考图9,图9为本实施例提供的端到端通信的时延测量装置的结构框图,该装置包括:数据监测模块91、识别模块92和时延计算模块93,其中:
数据监测模块91,用于监测端到端通信系统的发送端发送的业务通信信令数据,并记录发送业务通信信令数据的发送时间以及所述业务通信信令数据对应的业务类型。
在本实施例中,所述业务通信信令数据指的是端到端通信系统实现业务交互时的业务传输数据,该业务传输数据是通过各种通信信令请求数据的发送和反馈接收等,因此,该业务通信信令数据是业务输出传输必须的信令。当然,在实际应用中,该业务通信信令数据还可以是用户为分析端到端系统之间的时延时,专门设为其设置特定通信信令。
其中,所述端到端通信系统中的发送端指的是发送数据包的网元,而接收端指的是接收到数据包且被应用或进行分析处理的网元,整个端到端通信系统可以包括两个网元,也可以包括多个网元,当包括多个网元时,发送端指的是系统中的第一个网元,接收端指的是系统中的最后一个网元,其他的作为实现第一、第二网元的连接网元,如图2所示。
识别模块92,用于识别端到端通信系统的接收端是否接收到所述业务通信信令数据,若接收到,并记录所述接收端接收到所述业务通信信令数据的接收时间。
时延计算模块93,用于根据记录的所述发送时间和接收时间计算所述端到端通信系统通信的信令时延。
在本实施例中,所述装置还包括模型建立模块94,该模型建立模块94用于根据3gpp通信协议建立所述端到端通信系统的业务模型。
所述识别模块92用于根据所述业务类型确定对应的业务模型;根据所述业务模型,从所述接收端中识别是否存在与所述业务模型相匹配的业务流程,并根据识别的结果从所述业务流程提取对应的通信信令数据,记录对应的接收时间。
优选的,所述业务模型包括信令模型,所述信令模型包括用于触发所述业务流程所需要的起始信令组、中间信令组和结束信令组,其中,所述起始信令组和结束信令组时业务流程中必须的触发和结束信令,而中间信令组根据实际情况判断是否需要。对于所述结束信令组包括结束一个业务所有可能出现的情况,因此,在计算时延之前,还通过上述的方法对信令数据中的信令进行遍历,判断每个信令的实际情况,若选择计算时延的信令属于业务异常结束是的结束信令,这时所计算出来的时延就会出在非常大的误差,其参考价值也就非常低,最终会误导了网络维护人员确定的优化方案,若是异常的情况则需要重新监控获取新的信令数据进行时延的分析。
所述识别模块92用于从所述通信信令数据确定与所述起始信令组对应的起始信令;根据所述起始信令查找与该起始信令对应的结束信令组;根据所述结束信令组对所述通信信令数据进行筛选,确定所述通信信令数据中的结束信令,并记录所述结束信令被所述接收端确认接收到的接收时间。
在实际应用中,不同的业务交互,其使用的信令组也是不相同的,因此,所述所述识别端到端通信系统的接收端是否接收到所述业务通信信令数据具体还可以通过信令模型来实现。
例如,存在一个业务是通过如图3所定义的信令模型进行的业务交互时,根据图3中的信令模型对获取到的业务通信信令数据进行提取,首先对所述业务通信信令数据根据信令模型中的起始信令组进行筛选,筛选出起始信令,并判断该起始信令是否是模型中的起始信令组中的,若不是,则执行剔除步骤将该信令从数据集合中剔除;若存在,则记录到起始信令,并记录对应的发送时间,并继续判断下一条信令;在将所述信令数据中的所有起始信令确定后,根据起始信令查找对应的结束信令组,同时筛选信令数据中的结束信令是否属于该结束信令组中的,若是,则记录该结束信令以及对应的接收时间,最后根据记录的起始信令的发送时间和结束信令的接收时间计算出对应的通信时延。
在本实施例中,除了通过上述的步骤直接分析业务的交互信令数据实现时延分析之外,还可以通过设置标识符的方式进行分析,具体的通过在所述发送端发送的所述业务通信信令数据中设置信令标识符;监测所述接收端中的业务通信信令数据中是否存在所述信令标识符;若存在,则获取设置有所述信令标识符的业务通信信令数据被接收到时的接收时间。
在本实施例中,所述端到端通信的时延测量装置具体可以作为一个子系统设置在所述端到端通信系统中的网管系统中,通过增加该系统不仅实现了对各终端之间的业务交互信令的正确性进行监控,还可以实现了在各终端交互业务的同时实现业务流程交互时所需要的时间进行分析,工作人员可以随时根据分析的时延报告优化调整各终端之间的通信时间。
本发明实施例提供的端到端通信的时延测量装置,通过监测发送端上发送的业务通信信令数据,同时记录对应的发送时间,在识别到接收端接收到该业务通信信令数据时,记录对应的接收时间,然后根据接收时间和发送时间计算通信时延;通过系统本身交互的业务信令数据进行的时延分析,这样不仅实现了对系统的时延分析,也缩短了分析时延过程的耗时时长,同时还提高了用户对通信网络时延现状以及系统的通信质量的了解,解决了端到端系统在通信的过程中无法实现对通信时延的定位分析计算,导致系统的时延较大,提高了用户的使用体验。
实施例三:
请参考图10,图10为本实施例提供的端到端通信的时延测量装置的结构框图,该装置包括:处理器11、存储器12及通信总线13,在所述存储器12中存储有时延分析程序,其中:
所述通信总线13用于实现所述处理器11与所述存储器12之间的通信连接;
所述处理器11用于执行所述存储器12中存储的时延分析程序,以实现以下步骤:
监测端到端通信系统的发送端发送的业务通信信令数据,并记录发送业务通信信令数据的发送时间以及所述业务通信信令数据对应的业务类型;
识别端到端通信系统的接收端是否接收到所述业务通信信令数据,若接收到,并记录所述接收端接收到所述业务通信信令数据的接收时间;
根据记录的所述发送时间和接收时间计算所述端到端通信系统通信的信令时延。
在实际应用中,业务通信信令数据指的是端到端通信系统实现业务交互时的业务传输数据,该业务传输数据是通过各种通信信令请求数据的发送和反馈接收等,因此,该业务通信信令数据是业务输出传输必须的信令。当然,在实际应用中,该业务通信信令数据还可以是用户为分析端到端系统之间的时延时,专门设为其设置特定通信信令。
在本实施例中,所述处理器11还用于执行所述时延分析程序以实现以下步骤:
根据3gpp通信协议建立所述端到端通信系统的业务模型;
根据所述业务类型确定对应的业务模型;
根据所述业务模型,从所述接收端中识别是否存在与所述业务模型相匹配的业务流程,并根据识别的结果从所述业务流程提取对应的通信信令数据,记录对应的接收时间。
优选的,所述业务模型包括信令模型,所述信令模型包括用于触发所述业务流程所需要的起始信令组、中间信令组和结束信令组,所述处理器11在执行所述时延分析程序实现识别端到端通信系统的接收端是否接收到所述业务通信信令数据时,具体是通过以下方式:
从所述通信信令数据确定与所述起始信令组对应的起始信令;
根据所述起始信令查找与该起始信令对应的结束信令组;
根据所述结束信令组对所述通信信令数据进行筛选,确定所述通信信令数据中的结束信令,并记录所述结束信令被所述接收端确认接收到的接收时间。
在实际应用中,不同的业务交互,其使用的信令组也是不相同的,因此,所述所述识别端到端通信系统的接收端是否接收到所述业务通信信令数据具体还可以通过信令模型来实现。例如,存在一个业务是通过如图3所定义的信令模型进行的业务交互时,根据图3中的信令模型对获取到的业务通信信令数据进行提取,首先对所述业务通信信令数据根据信令模型中的起始信令组进行筛选,筛选出起始信令,并判断该起始信令是否是模型中的起始信令组中的,若不是,则执行剔除步骤将该信令从数据集合中剔除;若存在,则记录到起始信令,并记录对应的发送时间,并继续判断下一条信令;在将所述信令数据中的所有起始信令确定后,根据起始信令查找对应的结束信令组,同时筛选信令数据中的结束信令是否属于该结束信令组中的,若是,则记录该结束信令以及对应的接收时间,最后根据记录的起始信令的发送时间和结束信令的接收时间计算出对应的通信时延。
在本实施例中,所述端到端通信的时延测量装置除了通过直接分析业务的交互信令数据实现时延分析之外,还可以通过所述处理器11执行所述时延分析程序对所述业务通信信令数据设置标识符的方式进行分析,具体的通过在所述发送端发送的所述业务通信信令数据中设置信令标识符;监测所述接收端中的业务通信信令数据中是否存在所述信令标识符;若存在,则获取设置有所述信令标识符的业务通信信令数据被接收到时的接收时间。
对应的,本发明还提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有时延分析程序,所述时延分析程序被执行时实现上述实施例所提供的端到端通信的时延测量方法的步骤。
中综上述,本发明实施例提供的端到端通信的时延测量方法及装置、计算机可读存储介质,通过监测发送端上发送的业务通信信令数据,同时记录对应的发送时间,在识别到接收端接收到该业务通信信令数据时,记录对应的接收时间,然后根据接收时间和发送时间计算通信时延;通过系统本身交互的业务信令数据进行的时延分析,这样不仅实现了对系统的时延分析,也缩短了分析时延过程的耗时时长,同时还提高了用户对通信网络时延现状以及系统的通信质量的了解,解决了端到端系统在通信的过程中无法实现对通信时延的定位分析计算,导致系统的时延较大,提高了用户的使用体验。
显然,本领域的技术人员应该明白,上述本发明实施例的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在计算机存储介质(rom/ram、磁碟、光盘)中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以,本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。