具体实施方式

为使本申请的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本申请作进一步详细说明。

为解决现有技术所存在的问题，本申请提出一种B-TrunC系统中动态组TSM安全算法的动态协商生成方案，其主要思想在于：在创建群组时，GTCF触发各HTCF将本地保存的所有群组成员的组呼安全能力上报到GTCF；然后，由GTCF根据当前所有在线群组成员的组呼安全能力进行协商，生成TSM安全算法，并下发给各群组成员。从而，本申请通过采用群组成员动态协商的方式，在更短的时间内用更简化的流程生成了TSM安全算法，在B-TrunC系统协议里，优化了跨TCF场景下动态群组下行加密算法的协商流程，缩短了集群时延，并节省了系统资源。

图1为本申请应用于B-TrunC系统的动态组TSM安全算法的协商生成方法的示意图，该方法包括：

步骤101：在创建群组时，GTCF触发各群组成员的HTCF将各群组成员的组呼安全能力上报给GTCF；

步骤102：GTCF根据当前所有在线群组成员的组呼安全能力协商生成TSM安全算法，并下发给各群组成员。

其中，在GTCF触发各群组成员的HTCF将各群组成员的组呼安全能力上报给GTCF之前，还包括：GTCF收到调度台发送的动态重组创建请求，然后，从该动态重组创建请求中获取群组成员列表，并根据该群组成员列表确定非本地的群组成员。然后，针对非本地的群组成员，GTCF向非本地的群组成员所在的各个HTCF分别发送登记请求，登记请求中分别携带各个HTCF下所有群组成员的列表；收到登记请求的各个HTCF分别向GTCF发起登记流程，分别根据各自收到的登记请求中携带的群组成员的列表，将相应群组成员的组呼安全能力发送给GTCF。

GTCF获取到当前所有在线群组成员的组呼安全能力后，根据当前所有在线群组成员的组呼安全能力，采用取交集的方式协商出动态组使用的TSM安全算法，并下发给各群组成员。

当收到动态群组生成或群组成员变化的修改请求时，GTCF根据保存的当前群组成员的组呼安全能力，采用取交集的方式，协商出所有群组成员均支持的加密算法作为本群组的加密算法。

对应上述方法，本申请还提供了一种动态组TSM安全算法的协商生成系统，应用于B-TrunC系统，该系统至少包括：GTCF和各群组成员的HTCF，其中：

所述GTCF，用于在创建群组时触发各群组成员的HTCF将各群组成员的组呼安全能力上报给所述GTCF；

所述GTCF，还用于根据当前所有在线群组成员的组呼安全能力协商生成TSM安全算法，并下发给各群组成员。

较佳的，所述系统还包括调度台，其中：

所述调度台，用于向所述GTCF发送动态重组创建请求；

所述GTCF，在收到调度台发送的动态重组创建请求后，用于从所述请求中获取群组成员列表，并根据所述群组成员列表，确定非本地的群组成员。

较佳的，所述GTCF用于向非本地的群组成员所在的各个HTCF分别发送登记请求，所述登记请求中分别携带所述各个HTCF下所有群组成员的列表；

收到所述登记请求的所述各个HTCF，分别用于向所述GTCF发起登记流程，分别根据各自收到的登记请求中携带的群组成员的列表，将相应群组成员的组呼安全能力发送给所述GTCF。

较佳的，所述GTCF用于根据当前所有在线群组成员的组呼安全能力，采用取交集的方式协商出所述动态组使用的TSM安全算法。

较佳的，当收到动态群组生成或群组成员变化的修改请求时，所述GTCF还用于根据保存的当前群组成员的组呼安全能力，采用取交集的方式，协商出所有群组成员均支持的加密算法作为本群组的加密算法。

图2为本申请一较佳实施例在群组创建时通过协商生成动态组TSM安全算法的流程图，该流程包括以下步骤：

步骤1：调度台(DC)通过DC侧的HTCF(图中所示HTCF(DC))将动态重组创建请求(如图所示MESSAGE)发送给该群组的GTCF，其中携带该群组的群组成员列表信息。

步骤2：GTCF收到动态重组创建请求后，查看该群组的群组成员列表，确认群组成员的HTCF是否全部为本地，对于非本地的群组成员，继续进行步骤3。

步骤3：GTCF向非本地的群组成员所在的HTCF分别发送登记请求。

这里，新增TC2消息MESSAGE(GTCF要求上述非本地的群组成员所在的HTCF进行登记，消息中携带该HTCF下所有群组成员的列表)。

这里的HTCF也可称为终端HTCF，图中标记为HTCF(UE)，区别于DC侧的HTCF(DC)。本步骤中，GTCF发送给各终端HTCF的MESSAGE消息中分别需要携带本次要求相应HTCF登记的所有群组成员的UDN(用户拨号号码：User Dialing Number)列表，还可以携带群组名称、GDN(群组拨号号码：Group Dialing Number)信息等。

步骤4：各HTCF收到GTCF的登记请求后，返回200OK消息给GTCF，告知已收到该登记请求。

步骤5：各HTCF采用消息MESSAGE(终端HTCF向GTCF登记)向GTCF发起登记流程。这里，需要修改现有MESSAGE(终端HTCF向GTCF登记)，将协议中仅一个UE的登记消息，修改为可携带多个UE的登记消息，UE的UDN信息需要与步骤3登记请求中的UDN信息相同，每个UE的登记消息中均携带该UE的组呼安全能力。

步骤6：GTCF收到MESSAGE(终端HTCF向GTCF登记)后，向相应发HTCF返回200OK消息。

步骤7：GTCF收到所有群组成员所在HTCF返回的MESSAGE(终端HTCF向GTCF登记)后，得到该动态组所有群组成员的组呼安全能力，可以采用取交集等方式协商出该动态组最终使用的TSM安全算法。

此后，当收到动态群组生成或群组成员变化的修改请求时，GTCF可以根据GTCF保存的当前群组成员的组呼安全能力取交集，从而获取所有群组成员均支持的加密算法作为本群组的加密算法，若多个加密算法满足要求，可自行选择其中一种加密算法。

步骤8：GTCF向eHSS发送GroupInfo-Config-Request消息，按照B-TrunC标准要求填写对应信息，其中TSM安全算法即为步骤7中协商出的TSM安全算法。

步骤9：eHSS收到GroupInfo-Config-Request消息后，进行相关检查，在相关检查通过后，针对该群组生成Gkasme、GKVer等信息。

步骤10：eHSS按照标准协议在GroupInfo-Config-Answer中携带加密算法、Gkasme、GKVer等信息返回给GTCF。

随后的其它流程与标准B-trunC流程相同，在此不再赘述。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。