CN114189821B - 呼叫详细记录信令合成系统和方法 - Google Patents

Abstract

本发明涉及一种呼叫详细记录信令合成系统和方法，呼叫详细记录信令合成系统包括：信令解析单元，信令解析单元对呼叫过程中采集到的信令数据流进行解码，形成事务详细记录信令事件；呼叫详细记录信令合成单元，将信令解析单元输出的原始信令作为输入，呼叫详细记录信令合成单元利用Flink的会话窗口机制，完成对原始信令数据流的分组、聚合操作，生成呼叫详细记录信令；呼叫详细记录信令推送接口单元，用于将形成的呼叫详细记录信令通过http接口实时推送给各个业务应用。依据本发明的呼叫详细记录信令合成系统，基于Flink会话窗口实现，不增加硬件采集设备，不增加软件算法模块，仅利用现有的TDR信令数据，实现合成CDR的操作，大大降低了实现难度和经济成本。

Description

呼叫详细记录信令合成系统和方法

技术领域

本发明涉及通信技术领域，具体而言，涉及一种基于Flink会话窗口开发出的呼叫详细记录信令合成系统和方法。

背景技术

目前，移动通信领域中的许多增值业务，是基于对话务分析来触发的，例如挂机短信系统，计费系统等，而话务分析的基础CDR(Calling Detail Records，呼叫详细记录)的合成，这也是整个信令监测系统的核心技术，它为应用层功能提供原始的数据依据，实现对网络各项业务的分析与统计，也是挂机短信、计费系统等应用场景的数据依据，CDR信令的实时性、完整性和准确性决定了业务产品的服务质量。随着移动通信网络的不断发展，为提高网络业务质量以及用户感知，逐渐衍生出许多以CDR信令为依托的业务产品。

然而由于历史原因，业务系统在接入信令监测系统的建设初期，并未考虑到对CDR信令的需求，因此业务系统只能从现有的信令监测系统中获取TDR(Transation DetailRecords，事务详细记录)信令。而由于TDR信令在内容上缺少通话时长这类只有CDR信令才有的状态参数，无法满足需要依靠通话时长触发的业务场景。且对现有信令监测系统进行软硬件的重构无论从时间成本和经济成本都不具备条件。

随着业务的不断扩展，对CDR信令的需求日益迫切。而在解决CDR信令合成过程中存在以下亟待解决的问题：

1.对信息量不全(缺少呼叫过程中上下文关联关系，会话标识)、且有重复、时序混乱的TDR信令进行实时还原并合成CDR信令。具体来说，目前，由于受到信令监测系统提供的原始信令的数据完整性的限制，只有主叫、被叫、信令类型、时间戳4个字段，缺少的含有通话上下文关联标识或者会话标识的信息，且由于对一个端对端的呼叫过程，常常是跨越网络(软交换)的多个接口，覆盖多个协议，其结果是对于同一个呼叫过程，在不同的接口上会产生多个CDR，造成CDR的重复，同时，由于不同网络设备的时差问题，导致同一个呼叫过程中，不同事件信令到达的时序发生错乱。因此在业务层合成CDR信令的技术难度是很大。如现有的合成CDR技术所采用的离线批量合成法，即存在此问题。

2.对长时间通话的CDR信令的合成，由于中间状态的信令时间驻留内存时间过长，导致阻塞合成信令的服务进程，甚至导致内存溢出。如现有的合成CDR技术所采用的链表结构+Map(键值对)数据结构，即存在此问题。

3.对信令监测系统进行重构，增加硬件采集设备，在软交换设备上增加软件算法模块实现CDR信令的合成。

发明内容

本发明要解决的技术问题是设计一种不需要重构现有的信令监测系统软硬件架构的前提下，利用原有的、已送达业务层的TDR信令数据，通过Flink流计算的时间窗口技术对TDR的进行实时合成，从而满足业务对CDR信令的需求。

为解决上述技术问题，根据本发明的一个方面，提供一种呼叫详细记录信令合成系统，其包括：信令解析单元，信令解析单元对呼叫过程中采集到的信令数据流进行解码，形成事务详细记录信令事件，事务详细记录信令事件包括主叫号码、被叫号码、事件类型和事件发生的时间戳，经过解码后的事务详细记录信令属于原始信令，由信令解析单元输出，其中，事件类型包括：起呼、振铃、应答、挂机；呼叫详细记录信令合成单元，将信令解析单元输出的原始信令作为输入，呼叫详细记录信令合成单元利用Flink的会话窗口机制，完成对原始信令数据流的分组、聚合操作，其中，主叫号码和被叫号码作为信令分组的关键字，关键字相同的信令分为一组，聚合操作是在同一组内，对每一对主被叫的信令事件类型进行统计叠加，其中，统计叠加后的数组形式为[起呼，振铃，应答，挂机]，判断是否收集齐起呼、振铃、应答、挂机4种事件类型，如果是，则聚合为一条CDR信令，对于重复事件的信令，则取时间戳最大值的信令事件，然后计算出本次呼叫的通话时长：通话时长＝挂机事件信令时间戳-应答事件信令时间戳，从而获得通话时长，通话时长与事务详细记录信令合并生成呼叫详细记录信令，呼叫详细记录信令合成单元输出呼叫详细记录信令；呼叫详细记录信令推送接口单元，用于将形成的呼叫详细记录信令通过http接口实时推送给各个业务应用，触发业务逻辑。

依据本发明的实施例，事件类型的数据延迟到来时，可使用Flink提供的allowedLateness来处理延迟的数据，预设延迟事件会延迟的时间值，通过allowedLateness加入延迟时间值，使得延迟的事件数据分到另一个会话窗口中处理。在allowedLateness预设的时间值到达后仍未收到延迟事件数据时，可使用Flink提供的sideOutputLateData方法，把延迟之后的数据输出到全局窗口，并按照设定的周期性的触发窗口计算，直到聚合完成；如果超过设定的周期，则丢弃。

依据本发明的实施例，事务详细记录信令事件的出现重复时，可在会话窗口内对聚合后的信令进行记录合并操作，合并的依据是对关键字为对应主叫号码和被叫号码的记录，对于重复信令事件，则取时间戳最大值的信令。

根据本发明的另一方面，提供一种呼叫详细记录信令合成方法，包括如下步骤：

步骤1：信令解码，对呼叫过程中采集到的信令数据流进行解码，形成事务详细记录信令事件，事务详细记录信令事件包括主叫号码、被叫号码、事件类型和事件发生的时间戳，经过解码后的事务详细记录信令属于原始信令，解码后形成事务详细记录信令并输出，其中，事件类型包括：起呼、振铃、应答、挂机；

步骤2：呼叫详细记录信令合成，将原始信令作为输入，利用Flink的会话窗口机制，完成对原始信令数据流的分组、聚合操作，其中，主叫号码和被叫号码作为信令分组的关键字，关键字相同的信令分为一组，聚合操作是在同一组内，对每一对主被叫的信令事件类型进行统计叠加，其中，统计叠加后的数组形式为[起呼，振铃，应答，挂机]，判断是否收集齐起呼、振铃、应答、挂机4种事件类型，如果是，则聚合为一条CDR信令，对于重复事件的信令，则取时间戳最大值的信令，然后计算出本次呼叫的通话时长：通话时长＝挂机事件信令时间戳-应答事件信令时间戳，从而获得通话时长，通话时长与事务详细记录信令合并生成呼叫详细记录信令，输出呼叫详细记录信令；

步骤3：呼叫详细记录信令推送，将形成的呼叫详细记录信令通过http接口实时推送给各个业务应用平台，触发具体的业务场景。

依据本发明的实施例，呼叫详细记录信令合成方法的步骤2可包括如下步骤：

分配窗口，当呼叫过程中采集到的信令事件流接入Flink时，Flink为每个信令事件分配一个窗口；

合并窗口，自定义window assigner算子和trigger来实现一个基本会话窗口，用Flink的window assigner算子遍历现有的会话窗口，并合并这会话窗口，生成新的会话窗口；

窗口切分，用Flink的window assigner API区分各会话之间的空挡，并切分窗口，从而主叫+被叫关键字相同的信令分为一组，放入同一会话窗口中。

依据本发明的实施例，事件类型的数组内容为[起呼，振铃，应答]时，事件类型的数据延迟到来。事件类型的数据延迟到来时，可使用Flink提供的allowedLateness来处理延迟的数据，预设延迟事件会延迟的时间值，通过allowedLateness加入延迟时间值，使得延迟的事件数据分到另一个会话窗口中处理。在allowedLateness预设的时间值到达后仍未收到延迟事件数据时，可使用Flink提供的sideOutputLateData方法，把延迟之后的数据输出到全局窗口，并按照设定的周期性的触发窗口计算，直到聚合完成；如果超过设定的周期，则丢弃。

依据本发明的实施例，事务详细记录信令事件的出现重复时，在会话窗口内对聚合后的信令进行记录合并操作，合并的依据是对关键字为对应主叫号码和被叫号码的记录，对于重复信令事件，则取时间戳最大值的信令。

因为依据本发明的呼叫详细记录信令合成系统，其包括：信令解析单元，信令解析单元对呼叫过程中采集到的信令数据流进行解码，形成事务详细记录信令事件，事务详细记录信令事件包括主叫号码、被叫号码、事件类型和事件发生的时间戳，经过解码后的事务详细记录信令属于原始信令，由信令解析单元输出，其中，事件类型包括：起呼、振铃、应答、挂机；呼叫详细记录信令合成单元，将信令解析单元输出的原始信令作为输入，呼叫详细记录信令合成单元利用Flink的会话窗口机制，完成对原始信令数据流的分组、聚合操作，其中，主叫号码和被叫号码作为信令分组的关键字，关键字相同的信令分为一组，聚合操作是在同一组内，对每一对主被叫的信令事件类型进行统计叠加，其中，统计叠加后的数组形式为[起呼，振铃，应答，挂机]，判断是否收集齐起呼、振铃、应答、挂机4种事件类型，如果是，则聚合为一条CDR信令，对于重复事件的信令，则取时间戳最大值的信令，然后计算出本次呼叫的通话时长：通话时长＝挂机事件信令时间戳-应答事件信令时间戳，从而获得通话时长，通话时长与事务详细记录信令合并生成呼叫详细记录信令，呼叫详细记录信令合成单元输出呼叫详细记录信令；呼叫详细记录信令推送接口单元，用于将形成的呼叫详细记录信令通过http接口实时推送给各个业务应用，触发业务逻辑，所以可实现如下有益效果：

1.对原始TDR信令信息的完整性要求不高，对缺少的含有通话上下文关联标识或者会话标识的信息，只有主叫、被叫、信令类型、时间戳4个字段的TDR信令能有效合成，且算法简单高效。

2.相对于离线批量合成技术，本发明是一种在线的CDR信令实时合成方法，可以比喻成“边收边合成”，是一种高实时性合成方法。

3.本发明是在业务层的合成方式，不增加硬件采集设备，不需要在软交换设备上增加软件算法模块，仅利用现有的TDR信令数据，以纯软件的方式来实现合成CDR的操作,大大降低了实现难度和经济成本。

4.相对于现有技术而言，综合考虑了成本、效率、功能等问题，使得TDR信令合成效果体现出：高效、快速、准确，而且实施简单。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例的附图作简单地介绍，显而易见地，下面描述中的附图仅仅涉及本发明的一些实施例，而非对本发明的限制。

图1是示出Flink会话窗口示意图。

图2是示出依据本发明实施例的呼叫详细记录信令合成流程图。

图3是图2的详细分解图。

图4是示出信令进入Flink的初始状态示意图。

图5是示出Flink分配窗口示意图。

图6是图5状态下第3个信令到来后的窗口示意图。

图7是图6窗口合并后示意图。

图8是示出窗口切分示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例的附图，对本发明实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其它实施例，都属于本发明保护的范围。

除非另作定义，此处使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。本发明专利申请说明书以及权利要求书中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“一个”或者“一”等类似词语也不表示数量限制，而是表示存在至少一个。

本发明是一种基于Flink的Session Window(会话窗口)机制的对TDR信令进行实时合成CDR的方法和系统，Flink包括以下基本概念和操作原理：

1.Window(窗口)

Flink的Window是一种用来对一个无限的流设置的一个有限的集合，从而在有界的数据集上进行操作的机制。Flink支持5种类型的窗口：

a)time-tumbling-window(无重叠数据的时间窗口)

b)time-sliding-window(有重叠数据的时间窗口)

c)count-tumbling-window(无重叠数据的数量窗口)

d)count-sliding-window(有重叠数据的数量窗口)

e)session-window(基于会话的窗口)

2.AggregateFunction：聚合函数，主要用来做窗口的聚合计算

Flink的聚合函数分两种：

a)增量聚合:是指窗口每进入一条数据就计算一次。

b)全量聚合:是指在窗口触发的时候才会对窗口内的所有数据进行一次计算(例如每隔3秒，计算前3秒内的所有数据)。

3.Trigger：触发器，用来确定何时触发窗口的计算。

Flink的触发器，分为2类：

a)固定周期触发

b)按照某种事件触发

图1是示出Flink会话窗口示意图。

依据本发明的一个或一些实施例，如图1所示，本发明所涉及的基于Flink会话窗口机制的实时合成CDR的方法，使用的是Flink的session Window(会话窗口)，与TumblingWindow(翻滚窗口)和Sliding Window(滑动窗口)相比，Session Window(会话窗口)数据不重叠并且没有固定的开始和结束时间，会话窗口采用会话持续时长作为窗口处理依据，当会话窗口在一段时间内没有接收到元素时，即当发生不活动的Session Gap(会话间隙)时，会话窗口关闭。会话窗口分配器可以设置静态会话间隙和动态会话间隙。会话窗口的这种特性非常适合用来处理信令事件到达时间不确定，以及长时间通话导致最终状态的信令驻留内存时间过长的场景。

图2是示出依据本发明实施例的呼叫详细记录信令合成流程图，图3是图2的详细分解图。

依据本发明的一个或一些实施例，呼叫详细记录信令合成系统，包括：信令解析单元、呼叫详细记录信令合成单元、呼叫详细记录信令推送接口单元。

信令解析单元对呼叫过程中采集到的信令数据流进行解码，形成TDR信令事件，TDR信令事件包括主叫号码、被叫号码、事件类型和事件发生的时间戳，经过解码后的TDR信令属于原始信令，由信令解析单元输出到Flink信令合成单元。

解码后的TDR数据结构如下表：

字段名	字段类型	大小	是否为空
				主叫号码	Varchar	64	否
被叫号码	Varchar	64	否
				事件类型	Int	1	1-起呼,2-振铃,3-应答,4-挂机
时间戳	Timestamp	Long	否

呼叫详细记录信令合成单元，即Flink窗口信令合成单元，主要利用Flink的会话窗口机制，完成对信令数据流的进行分组聚合操作，分组的依据是主叫+被叫作为关键字，将主叫+被叫关键字相同的信令分为一组，聚合的依据是主叫+被叫相同的关键字，把每一次到来的事件类型放进数组列表中，判断数组内容是否为[1,2,3,4](注：[1,2,3,4]等同于[起呼，振铃，应答，挂机]上文表中对此事件类型有定义)，如果是，则聚合为一条CDR信令，对于重复事件的信令，则取时间戳最大值的信令，然后计算出本次呼叫的通话时长，通话时长＝挂机事件信令时间戳-应答事件信令时间戳。对应处理流程如图2和图3所示。

CDR(呼叫详细记录)信令推送接口单元：用于将形成的CDR信令通过http接口实时推送给各个业务应用，触发业务逻辑。

依据本发明的一个或一些实施例，通过Session window(会话窗口)合成CDR信令的过程种，需要处理的难点问题是：

(1)数据的延迟到来。有多种情况会导致数据延迟到来，比如一个用户打了很长时间的电话，假如15分钟之后，才收集到完整的信令事件，如果把session gap放长，则会导致阻塞其他信令合成，无法满足实时要求，因此，需要利用Flink提供了allowedLateness来处理延迟的数据，可以预设有些信令事件会延迟1个小时到来，那么通过allowedLateness这个参数，使得那些延迟的数据分到另一个session的窗口中：

allowedLateness(Time.minutes(60))

依据本发明的一个或一些实施例，更极端的情况下，一通呼叫的某个事件在1个小时候仍未到来，不可能一直修改allowedLateness参数来控制，此时，利用Flink提供的sideOutputLateData方法让我们得以把延迟之后的数据输出到Global Window(全局窗口)，并按照设定的周期性的触发窗口计算，直到聚合完成，如果超过设定的周期，则丢弃。

(2)事件信令重复：这主要是由于信令采集过程中，往往是跨网络多接口采集，导致同一个呼叫过程中的同一类型事件信令产生多条，解决这个问题的方法是，在Sessionwindow内对聚合后的信令进行记录合并操作，合并的依据是对关键字为主叫+被叫的记录，取起呼时间最大的记录。

依据本发明的一个或一些实施例，本发明提供的呼叫详细记录信令合成方法，从现有的socket数据流中接收二进制码流后，经过解码，生成TDR信令数据流，把TDR信令数据流输入到Flink的session window(会话窗口)进行关联，聚合，合并操作，最终生成CDR信令。在业务层的以现有的TDR信令为基础数据的通过软件方式实现的高实时性的CDR合成方法。具体方法包括如下步骤：

步骤1：信令解码

解码后的事件信令形成TDR信令事件流，信令的具体内容包括：主叫号码、被叫号码、事件类型、事件发生的时间戳。经过解码后的信令属于原始信令,4种类型的事件信令数据格式如下：

起呼，主叫号码，被叫号码，时间戳

振铃，主叫号码，被叫号码，时间戳

应答，主叫号码，被叫号码，时间戳

挂机，主叫号码，被叫号码，时间戳

步骤2：Flink会话窗口定义及分组聚合，即CDR信令合成

本步骤是合成CDR信令的核心，主要处理信令的时序错乱、重复信令，无上下文关联标识的信令进行分组、聚合处理。

图4是示出信令进入Flink的初始状态示意图，图5是示出Flink分配窗口示意图，图6是图5状态下第3个信令到来后的窗口示意图，图7是图6窗口合并后示意图，图8是示出窗口切分示意图。

当信令流进入Flink的会话窗口后，其初始状态如图1所示。

由图4可以很直观地观察到，一个通话的事件是一段一段的，每一段内的事件都是连续紧凑的，段内关联度要远大于段之间行为的关联度。

如图5所示，当信令事件流接入Flink时，Flink会为每个信令事件分配一个窗口。图6所示为第3个信令到来时的情况。

首先，自定义window assigner算子和trigger来实现一个基本能用的sessionwindow。由于Flink支持窗口的合并，window assigner算子可以合并这些窗口。用Flink的window assigner算子遍历现有的窗口，并告诉Flink哪些窗口需要合并成新的窗口。Flink会按照自定义的规则进行合并窗口，本发明将窗口合并的规则定义为：当主叫+被叫相同时，将这些窗口进行合并，所以，假设上面3个信令的主被叫相同，最终就形成如图7所示的窗口状态：3个信令在一个窗口，这就是会话窗口形成的底层原理。

把每一段通话行为看作一个“session”，段之间的空档看作为“session gap”。如图8所示，按照session window对信令流进行切分，并计算每个session的结果。

为了定义上述的窗口切分规则，可以使用Flink提供的window assigner API来实现，以下是部分代码实例。

这样，Flink就会基于信令关键字：主叫+被叫，自动地将信令放到不同的sessionwindow中。由于session window也集成了EventTime功能，把EventTime设置为信令的时间戳，如果两个信令的时间戳间隔小于session gap，则会在同一个session window中。如果两个信令之间的间隔大于session gap，且没有信令能够填补上这个gap，那么它们会被放到不同的session window中。

依据本发明的一个或一些实施例，当相同主被叫的信令数据被合并到同一个session window后，就可以进行合成操作，具体实现方法是：对每一窗口内的信令，进行聚合，以主叫+被叫相同的关键字，把每一次到来的事件类型放进数组列表中，判断数组内容是否为[1,2,3,4]，如果是，则聚合为一条CDR信令，计算出本次呼叫的通话时长，通话时长＝挂机事件信令时间戳-应答事件信令时间戳合成处理后形成的数据格式为json字符串,其中key以“-“作为分隔符,value为数组:主叫-被叫:[1,2,3],中括号内表示，本例中，当前主被叫已经收集到了起呼、振铃、应答3种信令，如果在15分钟内仍然没有收到4-挂机事件信令，则通过allowedLateness方法，将信令数据放入存放到另一个session window,等待下一次聚合。如果在1个小时内仍然为完成聚合操作，则将信令放入Global Sessionwindow,设置触发器Trigger,以固定周期1分钟的频率来触发聚合函数。如果1个小时后仍然未能合成CDR信令，则丢弃该信令。

步骤3：CDR信令推送

将最终从Flink中合成的CDR信令，以http接口实时的推送个业务平台，用以触发具体的业务场景，同时，也可以将CDR信令保存到数据仓库，以备后续做数据挖掘。

依据本发明的一个或一些实施例的CDR信令合成系统和方法对原始TDR信令信息的完整性要求不高，对缺少的含有通话上下文关联标识或者会话标识的信息，只有主叫、被叫、信令类型、时间戳4个字段的TDR信令能有效合成，且算法简单高效。

相对于离线批量合成技术，本发明是一种在线的CDR信令实时合成方法，可以比喻成“边收边合成”，是一种高实时性合成方法。

本发明是在业务层的合成方式，不增加硬件采集设备，不需要在软交换设备上增加软件算法模块，仅利用现有的TDR信令数据，以纯软件的方式来实现合成CDR的操作,大大降低了实现难度和经济成本。

相对于现有技术而言，综合考虑了成本、效率、功能等问题，使得TDR信令合成效果体现出：高效、快速、准确，而且实施简单。

本发明提出了一种利用流计算框架Flink的Session Window(会话窗口)机制实现在应用层对只含有主被叫等少量信息TDR信令实时地合成CDR信令的方法，从而解决了通过增加硬件带来的经济成本压力以及链表+Map算法的对时间敏感导致的合成失败率高的问题。以及由于长时间通话带来的中间态信令驻留内存时间过长而导致的内存溢出问题。

以上所述仅是本发明的示范性实施方式，而非用于限制本发明的保护范围，本发明的保护范围由所附的权利要求确定。

Claims (10)

1.一种呼叫详细记录信令合成系统，包括：

信令解析单元，所述信令解析单元对呼叫过程中采集到的信令数据流进行解码，形成事务详细记录信令事件，所述事务详细记录信令事件包括主叫号码、被叫号码、事件类型和事件发生的时间戳，经过解码后的事务详细记录信令属于原始信令，由所述信令解析单元输出，

其中，所述事件类型包括：起呼、振铃、应答、挂机；

呼叫详细记录信令合成单元，将所述信令解析单元输出的原始信令作为输入，所述呼叫详细记录信令合成单元利用Flink的会话窗口机制，完成对所述原始信令数据流的分组、聚合操作，

其中，主叫号码和被叫号码作为信令分组的关键字，所述关键字相同的信令分为一组，聚合操作是在同一组内，对每一对主被叫的信令事件类型进行统计叠加，

其中，统计叠加后的数组形式为[起呼，振铃，应答，挂机]，判断是否收集齐起呼、振铃、应答、挂机4种事件类型，如果是，则聚合为一条CDR信令，对于重复事件的信令，则取时间戳最大值的信令事件，然后计算出本次呼叫的通话时长：

通话时长＝挂机事件信令时间戳-应答事件信令时间戳，

从而获得通话时长，所述通话时长与所述事务详细记录信令合并生成呼叫详细记录信令，所述呼叫详细记录信令合成单元输出所述呼叫详细记录信令；以及

呼叫详细记录信令推送接口单元，用于将形成的呼叫详细记录信令通过http接口实时推送给各个业务应用，触发业务逻辑。

2.如权利要求1所述的呼叫详细记录信令合成系统，其中，所述事件类型的数据延迟到来时，使用Flink提供的allowedLateness来处理延迟的数据，预设延迟事件会延迟的时间值，通过allowedLateness加入所述延迟时间值，使得延迟的事件数据分到另一个会话窗口中处理。

3.如权利要求2所述的呼叫详细记录信令合成系统，其中，在allowedLateness预设的时间值到达后仍未收到延迟事件数据时，使用Flink提供的sideOutputLateData方法，把延迟之后的数据输出到全局窗口，并按照设定的周期性的触发窗口计算，直到聚合完成；如果超过设定的周期，则丢弃。

4.如权利要求1所述的呼叫详细记录信令合成系统，其中，所述事务详细记录信令事件的出现重复时，在会话窗口内对聚合后的信令进行记录合并操作，

其中，合并的依据是对关键字为对应主叫号码和被叫号码的记录，对于重复信令事件，则取时间戳最大值的信令。

5.一种呼叫详细记录信令合成方法，包括如下步骤：

步骤1：信令解码，对呼叫过程中采集到的信令数据流进行解码，形成事务详细记录信令事件，所述事务详细记录信令事件包括主叫号码、被叫号码、事件类型和事件发生的时间戳，经过解码后的事务详细记录信令属于原始信令，解码后形成事务详细记录信令并输出，

其中，所述事件类型包括：起呼、振铃、应答、挂机；

步骤2：呼叫详细记录信令合成，将所述原始信令作为输入，利用Flink的会话窗口机制，完成对所述原始信令数据流的分组、聚合操作，

其中，主叫号码和被叫号码作为信令分组的关键字，所述关键字相同的信令分为一组，聚合操作是在同一组内，对每一对主被叫的信令事件类型进行统计叠加，

其中，统计叠加后的数组形式为[起呼，振铃，应答，挂机]，判断是否收集齐起呼、振铃、应答、挂机4种事件类型，如果是，则聚合为一条CDR信令，对于重复事件的信令，则取时间戳最大值的信令，然后计算出本次呼叫的通话时长：

通话时长＝挂机事件信令时间戳-应答事件信令时间戳，

从而获得通话时长，所述通话时长与所述事务详细记录信令合并生成呼叫详细记录信令，输出所述呼叫详细记录信令；以及

步骤3：呼叫详细记录信令推送，将形成的呼叫详细记录信令通过http接口实时推送给各个业务应用平台，触发具体的业务场景。

6.如权利要求5所述的呼叫详细记录信令合成方法，所述步骤2包括如下步骤：

分配窗口，当呼叫过程中采集到的信令事件流接入Flink时，Flink为每个信令事件分配一个窗口；

合并窗口，自定义window assigner算子和trigger来实现一个基本会话窗口，用Flink的window assigner算子遍历现有的会话窗口，并合并这所述会话窗口，生成新的会话窗口；

窗口切分，用Flink的window assigner API区分各会话之间的空挡，并切分窗口，从而主叫+被叫关键字相同的信令分为一组，放入同一会话窗口中。

7.如权利要求5所述的呼叫详细记录信令合成方法，所述数组内容为[起呼，振铃，应答]时，所述事件类型的数据延迟到来。

8.如权利要求7述的呼叫详细记录信令合成方法，其中，所述事件类型的数据延迟到来时，使用Flink提供的allowedLateness来处理延迟的数据，预设延迟事件会延迟的时间值，通过allowedLateness加入所述延迟时间值，使得延迟的事件数据分到另一个会话窗口中处理。

9.如权利要求8所述的呼叫详细记录信令合成方法，其中，在allowedLateness预设的时间值到达后仍未收到延迟事件数据时，使用Flink提供的sideOutputLateData方法，把延迟之后的数据输出到全局窗口，并按照设定的周期性的触发窗口计算，直到聚合完成；如果超过设定的周期，则丢弃。

10.如权利要求5所述的呼叫详细记录信令合成方法，其中，所述事务详细记录信令事件的出现重复时，在会话窗口内对聚合后的信令进行记录合并操作，

其中，合并的依据是对关键字为对应主叫号码和被叫号码的记录，对于重复信令事件，则取时间戳最大值的信令。

Images