生成组密钥的方法和相关设备 |
|||||||
| 申请号 | CN201110340029.0 | 申请日 | 2011-11-01 | 公开(公告)号 | CN103096309B | 公开(公告)日 | 2016-08-10 |
| 申请人 | 华为技术有限公司; | 发明人 | 张丽佳; 陈璟; 许怡娴; | ||||
| 摘要 | 本 发明 实施例 提供了生成组密钥的方法和相关设备。该方法包括：获取机器类通信MTC设备所在组的组ID；获取组ID对应的组通信根密钥；根据组通信根密钥生成组ID对应的组密钥；向MTC设备发送用MTC设备的接入层密钥加密的组密钥，以使MTC设备根据MTC设备的接入层密钥解密得到组密钥。根据上述技术方案，基站可以向MTC设备分配与MTC设备所在的组对应的组密钥，从而可以使同一组内的MTC设备利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥，这样，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 | ||||||
| 权利要求 | 1.一种生成组密钥的方法，其特征在于，包括： |
||||||
| 说明书全文 | 生成组密钥的方法和相关设备技术领域[0001] 本发明涉及通信领域，并且更具体地，涉及通信领域中生成组密钥的方法和相关设备。 背景技术[0002] 机器对机器(Machine to Machine，M2M)技术是无线通信和信息技术的整合，是指机器和机器之间可以直接进行通信而无需人工干预。M2M应用种类丰富，包括自动仪表、远程监控、工业安全与舰艇自动化、支付系统以及车辆远程控制等。 [0003] M2M存在三种方式，包括机器对机器、机器对移动电话和移动电话对机器。在M2M中，M2M设备可以通过远距离连接技术和近距离连接技术接入网络，涉及的远距离连接技术包括全球移动通信系统(Global System for Mobile communications，GSM)、通用分组无线业务(General Packet Radio Service，GPRS)、通用移动通信系统(Universal Mobile Telecommunications System，UMTS)等无线接入类型技术。近距离连接技术包括802.11b/g、蓝牙(Blue Tooth)、紫蜂(Zigbee)、无线射频识别技术(Radio Frequency Identification，RFID)和超宽带(Ultra Wideband，UWB)技术等。当然，不排除还有其他技术可用于支撑M2M通信。M2M通信也可以被称为机器类通信(Machine Type Communication，MTC)，M2M设备也可以被称为MTC设备。 [0004] 在现有技术中，基站对同一组MTC设备构建公共的物理层、无线链路控制(Radio Link Control，RLC)层、分组数据汇聚协议(Packet Data Convergence Protocol，PDCP)层和媒体接入控制(Media Access Control，MAC)层。当为同一组MTC设备建立公共承载之后，每个MTC设备都有各自单独的密钥，各MTC设备的密钥互不相同，在基站和MTC设备之间交互的PDU单元需要携带MTC设备标识以根据该标识来寻找对应的密钥。因此，在基站处，需要为同一组内的每个MTC设备维护它们各自的密钥，这增加了基站操作的复杂性，使基站需要维护和管理的密钥过多，影响基站性能。 发明内容[0005] 本发明提供了生成组密钥的方法和相关设备，以提高基站性能。 [0006] 一方面，本发明提供了一种生成组密钥的方法，包括：获取机器类通信MTC设备所在组的组ID；获取所述组ID对应的组通信根密钥；根据所述组通信根密钥生成所述组ID对应的组密钥；向所述MTC设备发送用所述MTC设备的接入层密钥加密的所述组密钥，以使所述MTC设备根据所述MTC设备的接入层密钥解密得到所述组密钥。 [0007] 另一方面，本发明提供了一种生成组密钥的方法，包括：获取机器类通信MTC设备所在组的组ID；获取所述组ID对应的组通信根密钥；向基站发送所述组ID和所述组通信根密钥，以使所述基站根据所述组通信根密钥生成所述组ID对应的组密钥并向所述MTC设备发送用所述MTC设备的接入层密钥加密的所述组密钥。 [0008] 再一方面，本发明提供了一种生成组密钥的方法，包括：从基站接收所述基站用机器类通信MTC设备的接入层密钥加密的组密钥，其中所述组密钥由所述基站根据所述基站获取的组通信根密钥生成、并与所述基站获取的MTC设备所在组的组ID对应，或者所述组密钥由所述基站根据从移动性管理实体MME获取的组通信根密钥生成、并与所述MME获取的MTC设备所在组的组ID对应；根据所述MTC设备的接入层密钥解密得到所述组密钥。 [0009] 又一方面，本发明提供了一种基站，包括：第一获取模块，用于获取机器类通信MTC设备所在组的组ID；第二获取模块，用于获取所述组ID对应的组通信根密钥；生成模块，用于根据所述组通信根密钥生成所述组ID对应的组密钥；第一发送模块，用于向所述MTC设备发送用所述MTC设备的接入层密钥加密的所述组密钥，以使所述MTC设备根据所述MTC设备的接入层密钥解密得到所述组密钥。 [0010] 又一方面，本发明提供了一种移动性管理实体，包括：第一获取模块，用于获取机器类通信MTC设备所在组的组ID；第二获取模块，用于获取所述组ID对应的组通信根密钥；发送模块，用于向基站发送所述组ID和所述组通信根密钥，以使所述基站根据所述组通信根密钥生成所述组ID对应的组密钥并向所述MTC设备发送用所述MTC设备的接入层密钥加密的所述组密钥。 [0011] 又一方面，本发明提供了一种机器类通信设备，包括：第一接收模块，用于从基站接收所述基站用机器类通信MTC设备的接入层密钥加密的组密钥，其中所述组密钥由所述基站根据所述基站获取的组通信根密钥生成、并与所述基站获取的MTC设备所在组的组ID对应，或者所述组密钥由所述基站根据从移动性管理实体MME获取的组通信根密钥生成、并与所述MME获取的MTC设备所在组的组ID对应；第一解密模块，用于根据所述MTC设备的接入层密钥解密得到所述组密钥。 [0012] 根据上述技术方案，网络侧通过确定MTC设备所在组的组ID，从而确定与该组ID对应的组密钥，通过借助于MTC设备的接入层密钥可以将MTC设备使用的组密钥安全地分配给MTC设备，并使得同一组ID内的MTC设备共用相同的组密钥。这样，同一组内的MTC设备可以利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥，从而，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。附图说明 [0013] 为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。 [0014] 图1是根据本发明实施例的生成组密钥的方法的流程图。 [0015] 图2是利用根据本发明实施例提供的方法来生成组密钥的第一例子的流程图。 [0016] 图3是在第一例子中生成组认证参数的例子的示意图。 [0017] 图4是在第一例子中MTC设备和MME(Mobility Management Entity，移动性管理实体)进行认证的流程图。 [0018] 图5是利用根据本发明实施例提供的方法来生成组密钥的第二例子的流程图。 [0019] 图6是在第二例子中生成组认证参数的例子的示意图。 [0020] 图7是在第二例子中生成组认证参数的另一例子的示意图。 [0021] 图8是在第二例子中MTC设备和MME进行认证的流程图。 [0022] 图9是利用根据本发明实施例提供的方法来生成组密钥的第三例子的流程图。 [0023] 图10是利用根据本发明实施例提供的方法来生成组密钥的第四例子的流程图。 [0024] 图11是在第三例子和第四例子中当MTC设备从空闲状态或去附着状态重新加入组通信时的流程图。 [0025] 图12是利用根据本发明实施例提供的方法来生成组密钥的第五例子的流程图。 [0026] 图13是利用根据本发明实施例提供的方法来生成组密钥的第六例子的流程图。 [0027] 图14是根据本发明实施例的生成组密钥的另一方法的流程图。 [0028] 图15是根据本发明实施例的生成组密钥的再一方法的流程图。 [0029] 图16是根据本发明实施例的基站的结构框图。 [0030] 图17是根据本发明实施例的另一基站的结构框图。 [0031] 图18是根据本发明实施例的移动性管理实体的结构框图。 [0032] 图19是根据本发明实施例的另一移动性管理实体的结构框图。 [0033] 图20是根据本发明实施例的机器类通信设备的结构框图。 [0034] 图21是根据本发明实施例的另一机器类通信设备的结构框图。 具体实施方式[0035] 下面将结合本发明实施例中的附图，对本发明实施例的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的所述实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。 [0036] 首先，结合图1，描述根据本发明实施例的生成组密钥的方法100。 [0037] 如图1所示，方法100包括： [0038] 在S110中，获取MTC设备所在组的组ID； [0039] 在S120中，获取组ID对应的组通信根密钥； [0040] 在S130中，根据组通信根密钥生成组ID对应的组密钥； [0041] 在S140中，向MTC设备发送用MTC设备的接入层密钥加密的组密钥，以使MTC设备根据MTC设备的接入层密钥解密得到组密钥。 [0042] 例如，方法100可以由基站执行。基站通过对MTC设备进行分组，进而可以确定MTC设备所在组的组ID对应的组密钥，其中组密钥与组ID是一一对应的，每个组ID对应的组密钥互不相同。基站确定了组密钥之后，通过MTC设备的接入层密钥，可以将组密钥发送给MTC设备，从而完成组密钥的分配，使得一个组ID内的MTC设备都可以通过自己的接入层密钥而安全地得到所在组使用的组密钥。 [0043] 因此，借助于基站对同一组的组密钥的分配，同一组内的MTC设备可以利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥，从而，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0044] 在S110中，基站可以通过多种方式获取MTC设备所在组的组ID。例如，基站可以对MTC设备进行分组，从而将MTC设备划分到组ID对应的组内。在进行分组时，基站可以根据MTC设备距离基站的距离进行分组，也可以根据MTC设备的信号强度进行分组，还可以根据MTC设备的制造上进行分组，还可以随机分组，本发明对如何分组的具体方式不做任何限定。 [0045] 再例如，基站可以从其他网元获取MTC设备所在组的组ID。其他网元可以是MME，也可以是HSS(Home Subscriber System，归属用户系统)，还可以是核心网的其他设备或者分组数据网的设备。该其他网元可以对MTC设备进行分组，从而基站可以从该其他网元处得到MTC设备所属的组ID。 [0046] 又例如，基站可以从MTC设备接收组ID，从而确定MTC设备所属分组。又例如，基站可以从MTC设备接收MTC设备所属业务的业务ID，根据业务ID对MTC设备进行分组，从而确定MTC设备所属组的组ID。根据业务ID进行分组从而确定组ID的方式可以与现有技术相同，例如根据支持相同业务的MTC设备所处的位置进行分组等，在此不再赘述。 [0047] 根据本发明的一个实施例，基站可以从MME接收组ID和组通信根密钥，组通信根密钥由MTC设备所属的归属用户系统HSS根据随机数和与组ID对应的集合密钥生成，或者组通信根密钥由HSS在收到MME转发的来自一个MTC设备的所述组ID时，根据随机数、组ID和该一个MTC设备的专属密钥生成，并由HSS将组通信根密钥发送给MME。根据本发明的另一实施例，基站可以从MME接收业务ID和与业务ID对应的业务根密钥，业务ID为MTC设备发送给MME的、MTC设备所属业务的业务ID，业务根密钥由MTC设备所属的HSS根据随机数和与业务ID对应的集合密钥生成，或者业务根密钥由HSS在收到MME转发的来自一个MTC设备的业务ID时，根据随机数、业务ID和该一个MTC设备的专属密钥生成，并由HSS将业务根密钥发送给所述MME，并且基站根据业务ID确定MTC设备所在组的组ID，根据业务根密钥生成组ID对应的组通信根密钥。 [0048] 这样，基站可以在不同的实施例中通过多种方式灵活获取组ID和组通信根密钥。由于在生成组密钥的过程中涉及的网元个数的增加和诸如集合密钥之类的安全信息的增加，可以进一步提高组密钥生成的安全性，并避免基站生成的不同组的组密钥发生重合。相应例子可以参考下文第一例子至第四例子的描述。 [0049] 在S120中，基站可以通过多种方式获取组ID对应的组通信根密钥。例如，基站可以从组ID内的MTC设备中选择MTC设备，根据所选择的MTC设备的密钥确定组ID对应的组通信根密钥。由于一个组ID至少对应一个MTC设备，所以基站可以从其中选择一个MTC设备，将其密钥作为组通信根密钥，或者根据其密钥生成组通信根密钥。所选择的MTC设备的密钥可以是该MTC设备对应的KeNB。 [0050] 再例如，基站可以从MME接收组ID对应的组通信根密钥，其中由MME将MTC设备划分到组ID对应的组内，从组ID内的MTC设备中选择MTC设备，根据所选择的MTC设备的密钥确定组ID对应的组通信根密钥，或者由MME根据MME生成的随机数确定组ID对应的组通信根密钥。MME将生成的组通信根密钥发送给基站，以使基站获取组ID对应的组通信根密钥。 [0051] 又例如，基站可以生成一个随机数，根据该随机数确定组ID对应的组通信根密钥。基站可以直接将生成的随机数作为组ID对应的组通信根密钥，也可以根据随机数计算而推导出组ID对应的组通信根密钥。 [0052] 又例如，当基站从MME接收集合ID和第一参数之后，基站可以根据第一参数来生成组ID对应的组通信根密钥。 [0053] 根据本发明的实施例，在S130生成组密钥之后，基站可以将组通信根密钥、组密钥与组ID相绑定并存储。这样，当确定其它MTC设备属于组ID对应的组时，可以根据组ID获取相绑定的组密钥；向其它MTC设备发送用其他MTC设备的接入层密钥加密的组密钥，以使其他MTC设备根据其接入层密钥解密得到组密钥。 [0054] 当基站确定需要为另一个属于该组ID内的MTC设备生成组密钥时，无需再确定组通信根密钥并根据组通信根密钥确定组密钥，而直接根据与组ID绑定的组密钥，基站就可以为该MTC设备分配组密钥，从而可以减小基站处理复杂度，提高组密钥生成效率，并保证同一组ID内各MTC设备使用的组密钥相同。 [0055] 接下来，结合具体的例子来描述方法100的操作。在本发明的包括第一例子至第六例子的如下实施例中，带有“Group”字样的参数表示与一个组相关的参数，一个组的参数“XXX_Group”可以具有与一个MTC设备的参数“XXX”类似的用法和作用。例如，AV_Group可以具有与认证向量(Authentication Vector，AV)相似的生成方式和表现形式，不同之处在于AV_Group是针对一个组的，而不是针对一个特定MTC设备的。 [0056] 第一例子 [0057] 在第一例子中，集合ID是MTC设备所在组的组ID，这意味着提前将MTC设备进行了分组，而确定了MTC设备所在的组。组ID可以预置在MTC设备中；也可以设置在USIM(Universal Subscriber Identity Module，全球用户识别模块)中，当将USIM插入MTC设备时，USIM成为MTC设备的一部分，从而确定MTC设备所在的组。 [0058] 第一参数是组通信根密钥，即如下描述中的KeNB_Group，它等于HSS生成的Kasme_Group。KeNB_Group具有与KeNB类似的功能，区别在于KeNB_Group是针对一个组的，而KeNB是针对一个MTC设备的通过KeNB_Group可以衍生出其它的密钥。 [0059] 在图2所示的第一例子中，插入MTC设备的USIM中保存有MTC设备所属组的组信息Group ID(组ID)以及与该Group ID对应的集合密钥K_Group。在MTC设备所属的HSS中同样保存有与Group ID对应的K_Group。 [0061] 当MME收到MTC设备发送的附着请求之后，MME确定是否保存有与Group ID绑定的AV_Group。 [0062] 当MME确定还没有保存有与Group ID相绑定的AV_Group时，在S260之前执行如下操作： [0063] 在S220中，MME向HSS发送认证数据请求，在认证数据请求中包括IMSI和Group ID； [0064] 在S230中，HSS根据IMSI找到对应的K，根据K生成AV，并且HSS根据Group ID找到对应的K_Group，并根据K_Group生成AV_Group； [0065] 在S240中，HSS将AV和AV_Group通过认证数据响应发送给MME； [0066] 在S250中，MME将Group ID和AV_Group绑定并存储。 [0067] 根据K_Group生成AV_Group的方式如图3所示，这里图3只是一个例子而并不对根据K_Group生成AV_Group的方式进行限制。 [0068] 在图3中，HSS参考生成AV的方式来生成针对Group ID的AV_Group。其中涉及的置位符AMF、函数F1至F5与现有技术的含义相同，不同之处在于其他输入参数以及产生的参数都是针对一个组的而不是针对一个MTC设备的。 [0069] HSS生成针对Group ID的序列号SQN_Group，并生成针对Group ID的随机数RAND_Group。将K_Group、SQN_Group、RAND_Group和AMF如图所示输入各函数中，生成MAC_Group、XRES_Group、CK_Group、IK_Group和AK_Group。接着，可以利用如下方式生成AUTN_Group和Kasme_Group： [0070] [0071] [0072] 其中，KDF是密钥生成函数，可以具有与现有技术相同的计算方式，与下文中的KDF函数一样，对其形式不做限定；代表异或计算；||代表将前后两个物理量并在一起而形成连续的一个物理量。 [0073] 生成AUTN_Group和Kasme_Group之后，可以得到AV_Group： [0074] AV_Group＝RAND_Group||XRES_Group||Kasme_Group||AUTN_Group [0075] 返回图2，当MME确定保存有与Group ID相绑定的AV_Group时，在S260之前执行如下操作： [0076] 在S220中，MME向HSS发送认证数据请求，在该请求中包括IMSI； [0077] 在S230中，HSS根据IMSI找到对应的K，根据K生成AV； [0078] 在S240中，HSS将AV发送给MME。此时，不需要执行S250。 [0079] 继续图2中的流程。在S260中，MME和MTC设备利用AV和AV_Group进行认证。认证过程如图4所示。 [0080] 在S410中，MME向MTC设备发送用户认证请求，在该请求中除了如现有技术那样携带RAND、AUTH、KSIASME来对MTC设备本身进行认证之外，还需要采用本发明实施例的方式携带RAND_Group、AUTH_Group、KSIASME_Group来对MTC设备属于Group ID进行组认证。RAND_Group、AUTH_Group、KSIASME_Group的含义和用法可以与RAND、AUTH、KSIASME相同，除了AND_Group、AUTH_Group、KSIASME_Group是针对一个组而言的参数，而RAND、AUTH、KSIASME是针对一个MTC设备而言的。 [0081] 在S420中，当认证成功时，MTC设备向MME返回用户认证响应，在该响应中除了如现有技术那些携带RES来对设备认证进行响应之外，还需要采用本发明实施例的方式携带RES_Group来对组认证进行响应。另外，如果认证失败，则MTC设备需要如现有技术那样向MME发送用户认证拒绝消息，在该消息中携带用于表示认证失败原因的CAUSE参数。 [0082] 返回图2并继续图2的流程。在S270中，如果认证成功，则MME和MTC设备如现有技术那样计算出KeNB，并且MME可以根据AV_Group计算出KeNB_Group，在该实施例中将Kasme_Group作为KeNB_Group。KeNB_Group是接入层的组通信根密钥，通过KeNB_Group可以生成其他的接入层组密钥。虽然在图2所示的第一例子中，MTC设备在S270处与MME并发生成KeNB，但是MTC设备也可以在S260之后、S292之前的任意时刻生成KeNB。 [0083] 在S280中，MME将Group ID、KeNB和KeNB_Group发送给eNB(evolved Node B，演进型基站)。 [0084] 在S290中，eNB根据MTC设备的安全能力选择完整性算法和加密算法。如果eNB上没有建立有与Group ID相关的绑定，则eNB根据MTC设备的组安全能力选择用于生成组密钥的组算法，可以包括组完整性算法和组加密算法。选择组完整性算法和组加密算法的方式可以与现有技术中针对MTC设备选择完整性算法和加密算法相似，组完整性算法和组加密算法也可以分别与现有技术中的完整性算法和加密算法相似，不同之处在于组完整性算法和组加密算法是针对一个组的算法，而完整性算法和加密算法是针对一个MTC设备的算法。 [0085] 当eNB第一次为一个组ID生成对应的组密钥而建立组ID的绑定关系时，eNB将密钥更新次数Key_Count置为0，该参数可以用于对组密钥进行推衍更新。当PDCP计数器(PDCP Count)值达到最大值时，可以将Key Count值加1。PDCP Count值达到最大值，可以是指PDCP Count中的超帧号(Hyper Frame Number，HFN)部分达到最大值，也就是每当HFN达到阈值时，Key Count加1。每当Key Count值加1时，eNB都可以对组密钥进行更新，从而避免组密钥使用的时间过长而降低安全性。 [0086] 之后，eNB可以建立Group ID与组完整性算法、组加密算法、Key Count的绑定关系，并计算MTC设备的接入层密钥和MTC设备所属组的接入层组密钥，再将接入层组密钥和KeNB_Group也与Group ID绑定起来。MTC设备的接入层密钥的计算方式与现有技术相同，而计算接入层组密钥可以采用如下所述的方式。 [0087] 在本文中，接入层组密钥可以被简称为组密钥。接入层组密钥可以包括组加密密钥Key_Groupenc和组完整性密钥Key_Groupint。Key_Groupenc＝KDF(KeNB_Group，Group-enc-alg、Alg-ID)，Key_Groupint＝KDF(KeNB_Group，Group-int-alg，Alg-ID)。其中，KDF是密钥生成函数，Group-enc-alg代表当前计算采用的是组加密算法、Alg-ID是算法标识，Group-int-alg代表当前计算采用的是组完整性算法。 [0088] 如果eNB上已经建立有Group ID相关的绑定，则eNB不需要执行选择组算法和计算组密钥的步骤。 [0089] 这里，虽然在第一例子中由eNB根据MTC设备的组安全能力选择组完整性算法和组加密算法，但是在其他实施例中，组完整性算法和组加密算法也可以被预先配置在eNB中，这样不需要eNB选择相应算法。 [0090] 在S291中，eNB将利用MTC设备的接入层密钥加密和完整性保护之后的包括组完整性算法和组加密算法的组算法以及包括组加密密钥和组完整性密钥的组密钥发送给MTC设备，以使MTC设备根据组算法和组密钥进行组通信。 [0091] 在S292中，MTC设备利用自己的接入层密钥，获取组算法和组密钥。这样，MTC设备可以利用一个组共用的组算法和组密钥正常进行后续的组通信。 [0092] 如果Key Count不等于0，则eNB可以根据Key Count来对组密钥进行更新。更新组密钥的方式可以是首先根据Key Count推衍新的KeNB_Group，然后利用推衍后的KeNB_Group计算出新的组密钥。 [0093] 例如，可以利用如下表达式来推衍新的KeNB_Group。用KeNB_Group*表示推衍后的KeNB_Group，并用推衍出的KeNB_Group*取代KeNB_Group，作为当前的KeNB_Group： [0094] KeNB_Group*＝KDF(KeNB_Group，Cell ID，Group ID) [0095] 其中，KDF为密钥生成函数，Cell ID为小区标识。Key Count为几，就推衍几次。 [0096] 还可以利用如下表达式来直接推衍KeNB_Group*，将KeNB_Group*作为KeNB_Group： [0097] KeNB_Group*＝KDF(KeNB_Group，Cell ID，Group ID，Key Count) [0098] 当推衍出KeNB_Group之后，eNB可以利用推衍后的KeNB_Group重新计算Key_Groupenc和Key_Groupint。接着，利用MTC设备的接入层密钥对重新计算出的组密钥进行加密，并发送给MTC设备，以使MTC设备更新组密钥，利用新的组密钥进行组通信。 [0099] 在第一例子中，一组MTC设备在一段时间内都使用一个AV_Group，可以允许AV_Group重用，SQN_Group的使用规则可以是MTC设备从网络侧收到AUTH_Group中的SQN_Group大于或等于设备侧保存的SQN_Group。如果SQN_Group出现不同步的情况，可以通过重同步过程来进行解决。 [0100] 此外，一个组内的一个MTC设备如果原本处于组通信中、但经过一段时间之后退出组通信，那么当该MTC设备需要从空闲(IDLE)状态或者去附着状态转换为活动(ACTIVE)状态而重新加入组通信时，eNB向MTC设备发送用该MTC设备的接入层密钥加密的组密钥，以使该MTC设备重新获取组密钥来进行组通信。 [0101] 第二例子 [0102] 在第二例子中，集合ID是MTC设备所在组的组ID。第一参数是组通信根密钥，即如下描述中的KeNB_Group，它等于HSS生成的Group Key。 [0103] 在图5所示的第二例子中，在MTC设备的USIM中保存有MTC设备所属组的Group ID以及与该Group ID对应的密钥K_Group。当然，本领域技术人员也可以想到，Group ID以及与Group ID对应的K_Group也可以直接保存在MTC设备中。另外，在MTC设备所属的HSS中同样保存有GroupID和K_Group的对应关系。 [0104] 在S510中，MTC设备向MME发送附着请求，请求中包括MTC设备的IMSI和Group ID。 [0105] 当MME收到MTC设备发送的附着请求之后，MME确定是否保存有与Group ID绑定的Group Key。 [0106] 当MME确定还没有保存有与Group ID相绑定的Group Key时，在S560之前执行如下操作： [0107] 在S520中，MME向HSS发送认证数据请求消息，在该消息中包含IMSI和Group ID。当在后续的认证中需要利用S530中生成的AV_Group时，则在认证数据请求中还需要包含指示符Group Key Indicator，用于表示MME还没有建立Group ID的相关绑定信息，需要HSS生成Group Key，当然，如果后续认证利用现有技术中的AV，也可以携带Group Key Indicator来表示没有建立有Group ID的相关绑定信息； [0108] 在S530中，HSS根据IMSI找到对应的K，根据K生成AV，以使MTC设备和网络侧利用AV进行认证。其中，与IMSI对应的K可以被称为MTC设备的专属密钥，任一K的取值都是唯一的，只由一个MTC设备持有。当将USIM插入MTC设备时，由于在USIM中保存有K，故MTC设备被分配了唯一的K。 [0109] HSS也可以根据IMSI找到对应的K，根据Group ID找到对应的K_Group，结合K和K_Group生成AV_Group，以使MTC设备和网络侧利用AV_Group进行认证。此外，HSS根据Group ID找到对应的K_Group，根据K_Group和随机产生的随机数Nonce生成Group Key； [0110] 在S540中，当利用AV进行认证时，HSS将AV和Group Key通过认证数据响应消息发送给MME。当利用AV_Group进行认证时，HSS将AV_Group和Group Key通过认证数据响应消息发送给MME； [0111] 在S550中，MME将Group ID与Group Key进行绑定并存储。 [0112] 根据K和K_Group生成AV_Group的方式可以如图6和图7所示。这里图6和图7只是两个例子而并不对生成AV_Group的方式进行限制。 [0113] 在图6中，HSS生成SQN并生成RAND，并将SQN和RAND作为针对一个组的序列号和随机数。HSS将SQN、RAND、AMF、K按照如图所示的方式输入与现有技术相同的F1至F5函数，得到MAC、XRES、CK、IK、AK。接着HSS将K_Group和MAC、SRES、CK、IK、AK按照如图所示的方式输入其它函数F，这些函数F可以相同也可以不同，具体形式在此不作限制。通过这些函数F可以分别得到MAC_Group、XRES_Group、CK_Group、IK_Group和AK_Group。 [0114] 在图7中，HSS生成SQN并生成RAND，并将SQN和RAND作为针对一个组的序列号和随机数。HSS将SQN、RAND、AMF、K和K_Group按照如图所示的方式输入与现有技术相同的F1至F5函数，分别得到MAC_Group、XRES_Group、CK_Group、IK_Group、AK_Group。 [0115] 在图6和图7中，都可以采用如下方式得到AV_Group： [0116] [0117] [0118] AV_Group＝RAND||XRES_Group||Kasme_Group||AUTN_Group [0119] 其中，KDF是密钥生成函数，可以具有与现有技术相同的计算方式；代表异或计算；||代表将前后两个物理量并在一起而形成连续的一个物理量。 [0120] 当MME确定保存有与Group ID相绑定的Group Key时，在S560之前执行如下操作： [0121] 在S520中，MME向HSS发送认证数据请求消息，当在后续只需要利用AV进行认证时，在认证数据请求消息中包含IMSI，当在后续需要利用AV_Group进行认证时，在认证数据请求消息中包含IMSI和Group ID； [0122] 在S530中，当利用AV进行认证时，HSS根据IMSI找到对应的K，根据K生成AV。当利用AV_Group进行认证时，HSS根据IMSI找到对应的K，根据Group ID找到对应的K_Group，结合K和K_Group生成AV_Group； [0123] 在S540中，HSS将AV或AV_Group通过认证数据响应发送给MME。此时，不需要执行S550。 [0124] 继续图5中的流程。在S560中，MME和MTC设备利用AV或者AV_Group进行认证。当利用AV认证时，采用与现有技术相同的方式。当利用AV_Group认证时，认证过程如图8所示。 [0125] 在S810中，MME向MTC设备发送用户认证请求，在该请求中携带AV_Group中的RAND_Group、AUTN_Group以及现有技术中的KSIASME。 [0126] 在S820中，当认证成功时，MTC设备向MME返回用户认证响应，在该响应中携带RES_Group。另外，如果认证失败，则MTC设备向MME发送用户认证拒绝消息，并在该消息中携带CAUSE参数。 [0127] 返回图5并继续图5的流程。在S570中，如果认证成功，则MME和MTC设备如现有技术那样计算出KeNB，MME将Group Key作为KeNB_Group。虽然在图5所示的第二例子中，MTC设备在S570处与MME并发生成KeNB，但是MTC设备也可以在S560之后、S592之前的任意时刻生成KeNB。 [0128] 在S580中，MME将Group ID、KeNB和KeNB_Group发送给eNB。 [0129] 在S590中，eNB根据MTC设备的安全能力选择完整性算法和加密算法。如果eNB上没有建立有与Group ID相关的绑定，则eNB根据MTC设备的组安全能力选择用于生成组密钥的组算法，可以包括组完整性算法和组加密算法，并计算出接入层密钥以及组密钥Key_Groupenc和Key_Groupint。此外，eNB还将组算法、Key Count、KeNB_Group、KeNB_Groupenc和KeNB_Groupint与Group ID相绑定。S590的相关内容可以参考S290中的描述，为了避免重复，在此不再赘述。 [0130] 在591中，eNB将利用MTC设备的接入层密钥加密和完整性保护之后的包括组完整性算法和组加密算法的组算法以及包括组加密密钥和组完整性密钥的组密钥发送给MTC设备，以使MTC设备根据组算法和组密钥进行组通信。 [0131] 在S592中，MTC设备利用自己的接入层密钥，获取组算法和组密钥。这样，MTC设备可以利用一个组共用的组算法和组密钥正常进行后续的组通信。 [0132] 此外，一个组内的一个MTC设备如果原本处于组通信中、但经过一段时间之后退出组通信，那么当该MTC设备需要从IDLE状态或去附着状态转换为ACTIVE状态而重新加入组通信时，eNB向MTC设备发送用该MTC设备的接入层密钥加密的组密钥，以使该MTC设备重新获取组密钥来进行组通信。 [0133] 第三例子 [0134] 在第三例子中，集合ID是MTC设备支持业务的业务ID(Service ID)，这意味着提前根据MTC设备的功能或者所属业务将MTC设备分成了不同的业务集合，由业务ID进行区分。但是业务集合并不等于共用相同组密钥的组，共用相同组密钥的组还需要由基站根据业务ID进行分组来确定。业务ID可以预置在MTC设备中；也可以设置在USIM中，当将USIM插入MTC设备时，USIM成为MTC设备的一部分，从而确定MTC设备所支持的业务。 [0135] 第一参数是与业务ID对应的业务根密钥，即如下描述中的KeNB_Service，它等于HSS生成的Service Key。通过KeNB_Service，可以由基站确定KeNB_Group。 [0136] 在图9所示的第三例子中，在MTC设备的USIM中保存有MTC设备所属业务的Service ID以及与该Service ID对应的密钥K_Service。当然，Service ID和与该Service ID对应的密钥K_Service也可以保存在MTC设备中。另外，在MTC设备所属的HSS中同样保存有Service ID和K_Service的对应关系。 [0137] 在S910中，MTC设备向MME发送附着请求，在该请求中包括IMSI和Service ID。 [0138] 当MME收到MTC设备发送的附着请求之后，MME确定是否保存有与Service ID绑定的Service Key。 [0139] 当MME确定还没有保存有与Service ID相绑定的Service Key时，在S960之前执行如下操作： [0140] 在S920中，MME向HSS发送认证数据请求消息，在该消息中携带IMSI和Service ID； [0141] 在S930中，HSS根据IMSI找到对应的K，并根据K生成AV，以使MME利用AV与MTC设备进行认证。HSS根据Service ID找到K_Service，并随机生成随机数Nonce，接着根据K_Service和Nonce生成Service key； [0142] 在S940中，HSS将AV和Service key通过认证数据响应消息发送给MME； [0143] 在S950中，MME将Service ID与Service Key进行绑定并存储。 [0144] 当MME确定保存有与Service ID相绑定的Service Key时，在S960之前执行如下操作： [0145] 在S920中，MME向HSS发送认证数据请求消息，在该消息中携带IMSI； [0146] 在S930中，HSS根据IMSI找到对应的K，并根据K生成AV； [0147] 在S940中，HSS将AV通过认证数据响应消息发送给MME。此时，不需要执行S950。 [0148] 继续图9中的流程。在S960中，MME和MTC设备利用AV进行认证。利用AV的认证过程与现有技术相同，在此不再赘述。 [0149] 在S970中，如果认证成功，则MME和MTC设备计算出KeNB，并且MME将Service Key作为KeNB_Service。虽然在图9所示的第三例子中，MTC设备在S970处与MME并发生成KeNB，但是MTC设备也可以在S960之后、S992之前的任意时刻生成KeNB。 [0150] 在S980中，MME将Service ID、KeNB和KeNB_Service发送给eNB。 [0151] 在S990中，eNB根据MTC设备的安全能力选择完整性算法和加密算法。如果eNB上没有建立有与Service ID相关的绑定关系，则eNB根据MTC设备的组安全能力选择用于生成组密钥的组算法，可以包括组完整性算法和组加密算法，并计算接入层密钥以及接入层组密钥。选择组完整性算法和组加密算法的方式可以与现有技术中针对MTC设备选择完整性算法和加密算法相似，组完整性算法和组加密算法也可以分别与现有技术中的完整性算法和加密算法相似，不同之处在于组完整性算法和组加密算法是针对一个组的算法，而完整性算法和加密算法是针对一个MTC设备的算法。 [0152] 在计算包括Key_Groupenc和Key_Groupint的接入层组密钥的过程中，eNB首先需要根据Service ID对属于同一业务的MTC设备进行分组，然后根据分组确定一个组的KeNB_Group，再根据KeNB_Group和组算法生成组密钥。 [0153] 对属于同一业务的MTC设备进行分组的方式多种多样，例如随机分组、根据MTC设备的信号强度分组等。 [0154] 可以采用如下方式计算KeNB_Group： [0155] KeNB_Group＝KDF(KeNB_Service，Cell ID，Group ID) [0156] 其中，KDF是密钥生成函数，Cell ID是eNB服务小区的编号，Group ID是经过分组得到的MTC设备所属组的组ID。 [0157] 计算出KeNB_Group之后，可以计算组加密密钥Key_Groupenc和组完整性密钥Key_Groupint： [0158] Key_Groupenc＝KDF(KeNB_Group，Group-enc-alg、Alg-ID) [0159] Key_Groupint＝KDF(KeNB_Group，Group-int-alg，Alg-ID) [0160] 其中，KDF是密钥生成函数，Group-enc-alg代表当前计算采用的是组加密算法、Alg-ID是算法标识，Group-int-alg代表当前计算采用的是组完整性算法。 [0161] 计算出组密钥之后，eNB还将组算法、Key Count、KeNB_Group、KeNB_Groupenc和KeNB_Groupint与Group ID相绑定。另外，如第一例子所述，当eNB第一次为一个组ID生成对应的组密钥而建立组ID的绑定关系时，eNB将Key Count置为0，当PDCP计数器值达到最大值时，将KeyCount值加1，通过Key Count值对组密钥进行推衍更新。 [0162] 在其它实施例中，组完整性算法和组加密算法也可以被预先配置在eNB和MTC设备上，此时无需在S990中选择组算法，也无需协商组算法。 [0163] 在S991中，eNB将利用MTC设备的接入层密钥加密和完整性保护之后的包括组完整性算法和组加密算法的组算法以及包括组加密密钥和组完整性密钥的组密钥发送给MTC设备，以使MTC设备根据组算法和组密钥进行组通信。 [0164] 在S992中，MTC设备利用自己的接入层密钥，获取组算法和组密钥。这样，MTC设备可以利用一个组共用的组算法和组密钥正常进行后续的组通信。 [0165] 如果Key Count值不等于0，则eNB可以根据Key Count对组密钥进行更新，更新组密钥的方式可以首先根据Key Count推衍新的KeNB_Group，再利用推衍后的KeNB_Group计算出新的组密钥。推衍方式可以参考S292中的相关内容。 [0166] 此外，当一个组内的一个MTC设备如果原本处于组通信中、但经过一段时间之后退出组通信，那么当该MTC设备需要从IDLE状态或去附着状态转换为ACTIVE状态而重新加入组通信时，eNB向MTC设备发送用该MTC设备的接入层密钥加密的组密钥，以使该MTC设备重新获取组密钥来进行组通信。 [0167] 第四例子 [0168] 在第四例子中，集合ID是MTC设备支持业务的业务ID。业务ID可以预置在MTC设备中；也可以设置在USIM中，当将USIM插入MTC设备时，USIM成为MTC设备的一部分，从而确定MTC设备所支持的业务。第一参数是与业务ID对应的业务根密钥，即如下描述中的KeNB_Service，它等于HSS生成的Service Key。通过KeNB_Service，可以由基站确定KeNB_Group。 [0169] 在图10所示的第四例子中，在MTC设备的USIM中保存有MTC设备所属业务的Service ID以及与该Service ID对应的密钥K_Service。当然，本领域技术人员也可以想到，Service ID以及与Service ID对应的K_Service也可以直接保存在MTC设备中。另外，在MTC设备所属的HSS中同样保存有Service ID和K_Service的对应关系。 [0170] 在S1010中，MTC设备向网络发送附着请求，在该请求中包括IMSI和Service ID。 [0171] 当MME收到MTC设备发送的附着请求之后，MME确定是否保存有与Service ID绑定的Service Key。 [0172] 当MME确定还没有保存有与Service ID相绑定的Service Key时，在S1060之前执行如下操作： [0173] 在S1020中，MME向HSS发送认证数据请求消息，在该消息中携带IMSI和Service ID； [0174] 在S1030中，HSS根据IMSI找到对应的K，并根据K生成AV，以使MME利用AV与MTC设备进行认证。并且，HSS根据Service ID计算Service Key，其中Service Key＝f(K，Service ID，Nonce)，Nonce是HSS生成的随机数，f是生成Service Key所需的函数，本发明对函数的具体形式不做任何限定。此外，在其他实施例中，Service Key也可能由HSS或MME根据Kasme计算，例如，Service Key＝f(Kasme，Service ID，Nonce)； [0175] 在S1040中，HSS将计算的AV和Service Key发送给MME； [0176] 在S1050中，MME建立Service ID和Service Key的绑定关系并存储。 [0177] 当MME确定保存有与Service ID相绑定的Service Key时，在S1060之前执行如下操作： [0178] 在S1020中，MME向HSS发送认证数据请求消息，在该消息中携带IMSI； [0179] 在S1030中，HSS根据IMSI找到对应的K，并根据K生成AV； [0180] 在S1040中，HSS将AV通过认证数据响应消息发送给MME。此时，不需要执行S1050。 [0181] 继续图10中的流程。在S1060中，MME和MTC设备利用AV进行认证。利用AV的认证过程与现有技术相同，在比不再赘述。 [0182] 在S1070中，如果认证成功，则MME和MTC设备计算出KeNB，并且MME将Service Key作为KeNB_Service。虽然在图10所示的第四例子中，MTC设备在S1070处与MME并发生成KeNB，但是MTC设备也可以在S1060之后、S1092之前的任意时刻生成KeNB。 [0183] 在S1080中，MME将Service ID、KeNB和KeNB_Service发送给eNB。 [0184] 在S1090中，eNB根据MTC设备的安全能力选择完整性算法和加密算法。如果eNB上没有建立有与Service ID相关的绑定关系，则eNB根据MTC设备的组安全能力选择用于生成组密钥的组算法，可以包括组完整性算法和组加密算法，并计算接入层密钥以及接入层组密钥。在计算包括Key_Groupenc和Key_Groupint的接入层组密钥的过程中，eNB首先需要根据Service ID对属于同一业务的MTC设备进行分组，然后根据分组确定一个组的KeNB_Group，再根据KeNB_Group和组算法生成组密钥。计算出组密钥之后，eNB还将组算法、Key Count、KeNB_Group、KeNB_Groupenc和KeNB_Groupint与Group ID相绑定。在其它实施例中，组完整性算法和组加密算法也可以被预先配置在eNB和MTC设备上。S1090的相关内容可以参考上述S990中的描述。 [0185] 在S1091中，eNB和MTC设备执行AS SMC(Access Stratum Security Mode Command，接入层安全模式命令)，协商选择的完整性算法、加密算法、组完整性算法、组加密算法。 [0186] 在S1092中，MTC设备根据协商的算法计算接入层密钥。 [0187] 在S1093中，eNB将计算出的Key_Groupenc和Key_Groupint通过接入层安全保护后发送给MTC设备，此后MTC设备和网络侧可以利用Key_Groupenc和Key_Groupint进行组通信。 [0188] 在第三例子和第四例子中，也可以在MME中根据Service ID对MTC设备进行分组，然后MME将分组得到的Group ID发送给eNB；还可以在某个特定的具有M2M功能的实体上对MTC设备进行分组，该实体将分组得到的Group ID通知给eNB。这样，在S990和S1090中eNB不需要再进行分组，直接根据收到的Group ID计算KeNB_Group即可。 [0189] 在第三例子和第四例子中，网络侧可以通过多种方式得到MTC设备的业务ID，例如：MTC设备向网络侧发送Service ID，如上所述；HSS保存IMSI和Service ID的绑定关系，通过IMSI可以查找到对应的Service ID；某个特定M2M功能的实体保存IMSI和Service ID的绑定关系，HSS可以从该实体处获取对应的Service ID；HSS通过IMSI的特定字段获知Service ID。 [0190] 此外，在第三例子和第四例子中，当MTC设备从IDLE态转换到ACTIVE态时，可以通过图11所示的流程图来进行组密钥同步。 [0191] 在S1110中，MTC设备向网络侧发送服务请求消息，在消息中包含Service ID。 [0192] 在S1120中，MME检查是否存在与该Service ID对应的绑定关系，如果不存在，则执行图10中当MEE没有绑定关系时执行的S1020至S1050以及后续的S1060至S1093；如果存在，则将Service ID发送给eNB。 [0193] 在S1130中，MME将Service ID发送给eNB。 [0194] 在S1140中，eNB根据Service ID为MTC设备分组得到Group ID，并查找该Group ID绑定的组算法和组密钥。 [0195] S1150中，eNB向MTC设备发送AS SMC，协商完整性算法、加密算法、组完整性算法和组加密算法。 [0196] 在S1160中，MTC设备根据协商的算法计算接入层密钥和Key_Groupenc、Key_Groupint。 [0197] 第五例子 [0198] 图12是利用根据本发明实施例提供的方法来生成组密钥的第五例子的流程图。 [0199] 在S1210中，eNB对MTC设备进行分组，或者从其他网元获取MTC设备的分组情况，从而确定MTC设备所在组的组ID。 [0200] 在S1220中，eNB在MTC设备所在的组内随机选择一个MTC设备或者生成一个随机数，根据所选择的MTC设备的密钥或者随机数来推衍组通信根密钥KeNB_Group，其中，KeNB_Group＝KDF(KeNB/RAND，Group ID)，KDF为密钥生成函数，可以具有与现有技术相同的定义，也可以根据不同的算法灵活定义，本发明不对KDF的具体形式进行任何限定。 [0201] eNB还为该组的MTC设备选择包含组完整性算法和组加密算法的组算法，根据KeNB_Group和组算法，计算出包括组加密密钥Key_Groupenc和组完整性密钥Key_Groupint的组密钥，并建立组ID和组通信根密钥、组算法、组密钥的绑定关系。其中，Key_Groupenc＝KDF(KeNB_Group，Group-enc-alg，Alg-ID)，Key_Groupint＝KDF(KeNB_Group，Group-int-alg，Alg-ID)Group-enc-alg代表当前计算采用的是组加密算法、Alg-ID是算法标识，Group-int-alg代表当前计算采用的是组完整性算法。组完整性算法和组加密算法的功能和用法分别与完整性算法和加密算法相似，不同之处在于，组完整性算法和组加密算法是针对一个组ID的，而完整性算法和加密算法是针对一个MTC设备的。 [0202] 在S1230中，eNB将利用MTC设备的接入层密钥加密和完整性保护之后的包括组完整性算法和组加密算法的组算法以及包括组加密密钥和组完整性密钥的组密钥发送给MTC设备，以使MTC设备根据组算法和组密钥进行组通信。 [0203] 在S1240中，MTC设备利用自己的接入层密钥，获取组算法和组密钥。这样，MTC设备可以利用一个组共用的组算法和组密钥正常进行后续的组通信。 [0204] 第六例子 [0205] 图13是利用根据本发明实施例提供的方法来生成组密钥的第六例子的流程图。 [0206] 在S1310中，MME对MTC设备进行分组，或者从其他网元获取MTC设备的分组情况，从而确定MTC设备所在组的组ID。 [0207] 在S1320中，MME在MTC设备所在的组内随机选择一个MTC设备或者生成一个随机数，根据所选择的MTC设备的密钥Kasme或者随机数RAND来推衍组通信根密钥KeNB_Group，KeNB_Group＝KDF(Kasme/RAND，NAS Count，Group ID)，其中NAS Count是非接入层计数值。MME也可以直接将随机数作为KeNB_Group，并建立Group ID和KeNB_Group的绑定关系。 [0208] 在S1330中，MME将Group ID和KeNB_Group发送给eNB。 [0209] 在S1340中，eNB为MTC设备所在的组选择组加密算法和组完整性算法，并计算响应的Key_Groupenc和Key_Groupint。其中，Key_Groupenc＝KDF(KeNB_Group，Group-enc-alg，Alg-ID)，Key_Groupint＝KDF(KeNB_Group，Group-int-alg，Alg-ID)，并建立Group ID和组完整性算法、组加密算法、KeNB_Group、KeNB_Groupenc、KeNB_Groupint的绑定关系。 [0210] 在S1350中，eNB将加密和完整性保护之后的组完整性算法、组加密算法、Key_Groupenc和Key_Groupint发送给MTC设备。用来进行加密和完整性保护的算法和密钥是MTC设备与网络侧共享的接入层算法和密钥。 [0211] 在S1360中，MTC设备获取组算法和组密钥，并利用它们进行后续通信。 [0212] 此外，在第五例子和第六例子中，当MTC设备从IDLE状态或去附着状态转换为ACTIVE状态时，可以通过如下过程进行接入层密钥同步：MTC设备向网络侧发送服务请求消息，网络侧例如MME或eNB为MTC设备分组后，当分组得到的组ID具有绑定的组密钥时，将与组ID绑定的组密钥通过MTC设备的接入层密钥发送给MTC设备即可，当分组得到的组ID没有相绑定的组密钥时，为该组ID生成组密钥后，将该组密钥通过MTC设备的接入层密钥发送给MTC设备即可。 [0213] 根据本发明的实施例，在MTC设备和eNB之间进行组通信的过程中，eNB可以不需要为每个MTC设备维护一个PDCP Count值，而是为一组MTC设备维护一个组PDCP Count值。这样，可以减少基站需要维护的PDCP Count值，进一步降低基站的处理复杂度。 [0214] 根据本发明的实施例，PDCP Count值由HFN和SN两部分组成，在MTC设备和eNB之间进行组通信的过程中，eNB可以不需要为每个MTC设备维护一个HFN值，而是为一组MTC设备维护一个组HFN值，其中组HFN由一组MTC设备共用，SN由MTC设备发送的数据包中的序列号决定。在一组MTC设备的每个MTC设备中，都维护一个PDCP Count值，该PDCPCount值中的HFN与eNB维护的组HFN和其它MTC设备的HFN保存同步，SN由MTC设备单独维护，与自己发送的数据包的序列号有关。 [0215] 对于上行链路，每个MTC设备维护一个PDCP Count值，组内每个MTC设备维护的HFN与eNB维护的组HFN保持同步。组内MTC设备利用上行PDCP Count值对上行数据进行加密，并在上行数据分组数据单元(Packet Data Unit，PDU)头部中携带SN。eNB收到公共承载上的数据包时，利用eNB保存的HFN和数据包携带的SN组成的Count值解密该数据包。当组内任一MTC设备发送数据包中的SN达到阈值时，eNB收到该数据包之后，将组HFN加1，并将该HFN的取值或者HFN需要加1的信息通知给组内的各MTC设备。 [0216] HFN可以有多种通知方式。例如，对于业务量小的MTC设备，可以将HFN设置为固定值。再例如，当HFN可变时，eNB可以通过组ID对应组内所有MTC设备各自的信令承载、组ID对应组的公共信令承载或者广播信道，向组ID对应组内所有MTC设备发送HFN的取值。eNB可以在HFN达到阈值时向组ID对应组内的所有MTC设备发送HFN取值，也可以在有MTC设备加入组ID对应组时，向该MTC设备发送HFN取值。又例如，当HFN可变时，如果组ID对应的HFN达到阈值，那么eNB可以通过组ID对应组内所有MTC设备各自的信令承载、组ID对应组的公共信令承载或者广播信道，向组ID对应组内所有MTC设备发送用于指示HFN加1的指示信息。如果广播HFN需要增加的指示信息，则对于组HFN的初始值需要MTC设备与eNB协商或由eNB发送给MTC设备。另外，eNB还可以直接将PDCPCount值放在PDU头部中发送给MTC设备，这样MTC设备根据收到的PDU，可以从头部中提取中HFN的取值。 [0217] 对于下行链路，如果组通信基于eNB和一组MTC设备之间的公共承载，则一般组内MTC设备通过公共承载接收eNB发送的组信息，此时组内MTC设备的PDCP Count值变化一致，故不需要在下行链路引入新的PDCP Count值机制。 [0218] 当eNB保存的组HFN达到阈值时，eNB对组密钥进行更新。当MTC设备内的PDCP Count值中的HFN达到阈值时，MTC设备也对组密钥进行更新。可以通过多种方式使MTC设备确定HFN达到阈值。例如eNB可以向MTC设备通知HFN取值或HFN加1的指示，以使MTC设备在改变HFN之后确定HFN达到阈值，从而更新组密钥。再例如eNB可以直接向MTC设备通知HFN达到阈值的指示，以使MTC设备更新组密钥。 [0219] 在eNB中可以有两种方式对组密钥进行更新。 [0220] 一种是先更新KeNB_Group，然后利用更新后的KeNB_Group计算Key_Groupenc和Key_Groupint。在该种更新方式中，KeNB_Group*＝KDF(KeNB_Group，Cell ID，Group ID)或者KeNB_Group*＝KDF(KeNB_Group，cell ID，Group ID，Key Count)。 [0221] 另一种是直接对Key_Groupenc和Key_Groupint进行更新。在该更新方式中，Key_Groupenc*＝KDF(Key_Groupenc，Cell ID，Group ID)，Key_Groupint*＝KDF(Key_Groupint，Cell ID，Group ID)。 [0222] 在本发明的实施例中，为了进一步保证通信的安全，网络侧可以在满足一定条件时对组通信根密钥进行更新。当满足一定条件时，网络侧更新组根密钥KeNB_Group，并根据更新后的组通信根密钥来生成新的组密钥，以通过新的组密钥进行组通信。该一定条件可以是当网络侧维护的定时器达到阈值时；也可以是eNB处维护的Key Count值达到阈值时；还可以是MME处维护的针对一个组或一个业务的计数器值达到阈值时，每当MME收到属于一个组或一个业务的MTC设备发送的NAS信令时，该计数器值加1。 [0223] 接下来，结合图14描述根据本发明实施例的生成组密钥的方法1400。 [0224] 如图14所示，方法1400包括： [0225] 在S1410中，获取MTC设备所在组的组ID； [0226] 在S1420中，获取组ID对应的组通信根密钥； [0227] 在S1430中，向基站发送组ID和组通信根密钥，以使基站根据组通信根密钥生成组ID对应的组密钥并向MTC设备发送用MTC设备的接入层密钥加密的组密钥。 [0228] 例如，方法1400可以由MME执行。MME通过对MTC设备进行分组，进而可以确定MTC设备所在组的组ID对应的组通信根密钥。MME将组ID和组通信根密钥发送给基站，以使基站生成组密钥并加密后发送给MTC设备，从而完成组密钥的分配。 [0229] 由于同一组对应一个组通信根密钥，再由组通信根密钥推衍出组密钥，可以使同一组内的MTC设备利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥，从而，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0230] 在S1410中，MME可以通过多种方式获取MTC所在组的组ID。例如，MME可以对MTC设备进行分组，从而可以将MTC设备划分到组ID对应的组内。再例如，MME可以从其它网元获取MTC设备所在组的组ID。又例如，MME可以接收MTC设备发送的组ID。 [0231] 根据本发明的实施例，当MME在S1410中从接收MTC设备发送的组ID从而获取到组ID时，在S1420中MME可以通过如下方式获取组ID对应的组通信根密钥：向MTC设备所属的HSS发送组ID，以使HSS根据随机数和与组ID对应的集合密钥生成第一参数；从HSS接收第一参数；根据第一参数生成组ID对应的组通信根密钥。 [0232] 其中，根据本发明的实施例，当组ID没有绑定与组ID对应的第一参数时，MME向HSS发送组ID。当MME从HSS接收到第一参数之后，MME可以将第一参数与组ID相绑定并存储。这样，当MME收到其它MTC设备发送的携带有组ID的附着请求时，MME可以根据组ID获取与组ID相绑定的第一参数；根据第一参数生成组ID对应的组通信根密钥；向基站发送组ID和组通信根密钥。 [0233] 根据本发明的一个实施例，MME向MTC设备所属的HSS发送组ID之后，MME可以从HSS接收组认证参数，其中组认证参数由HSS根据与组ID对应的集合密钥生成，或者由HSS根据与组ID对应的集合密钥和MTC设备的专属密钥生成；并根据组认证参数，与MTC设备进行认证。在该情况下，在MTC设备与网络侧认证成功之后，MME根据第一参数生成组ID对应的组通信根密钥。这里，MTC设备的专属密钥可以是MTC设备的K，K可以存储在USIM中，当将USIM插入一MTC设备时，USIM成为该MTC设备的一部分。 [0234] 相关实施例可以参考上述第一例子至第四例子的描述，为了避免重复，在此不再赘述。 [0235] 在S1420中，MME还可以通过如下方式获取组ID对应的组通信根密钥：从组ID内的MTC设备中选择MTC设备，根据所选择的MTC设备的密钥确定组ID对应的组通信根密钥；或者生成一个随机数，根据随机数确定组ID对应的组通信根密钥。MME可以根据选择的MTC设备的KeNB推衍得到组ID对应的组通信根密钥，也可以将选择的MTC设备的KeNB直接作为组ID对应的组通信根密钥。同样，MME可以根据随机数推衍得到组ID对应的组通信根密钥，也可以将随机数直接作为组ID对应的组通信根密钥。 [0236] 根据本发明的实施例，MME获取组ID对应的组通信根密钥之后，可以将组ID和组通信根密钥进行绑定并存储。这样，当确定其他MTC设备属于组ID对应的组时，根据组ID获取相绑定的组通信根密钥；向基站发送组ID和组通信根密钥。通过直接获取相绑定的组通信根密钥，可以降低反复生成组通信根密钥的处理复杂度，并可以保证同一组ID对应的组通信根密钥的一致性。 [0237] 相关实施例可以参考上述第五例子和第六例子的描述，为了避免重复，在此不再赘述。 [0238] 此外，根据本发明的实施例，当网络侧维护的预定定时器达到第一预定阈值时，或者当基站更新组密钥的次数达到第二预定阈值时，或者当维护的非接入层的计数值达到第三预定阈值时，与MTC设备进行重认证或者获取组ID对应的新的组通信根密钥。这样，可以在一定时间之后更新组密钥，避免同一组密钥的使用时间过长而引入不安全因素，从而可以进一步提高组通信的安全性。 [0239] 接下来，参考图15描述根据本发明实施例的生成组密钥的方法1500。 [0240] 如图15所示，方法1500包括： [0241] 在S1510中，从基站接收基站用MTC设备的接入层密钥加密的组密钥，其中组密钥由基站根据基站获取的组通信根密钥生成、并与基站获取的MTC设备所在组的组ID对应，或者组密钥由基站根据MME获取的组通信根密钥生成、并与MME获取的MTC设备所在组的组ID对应； [0242] 在S1520中，根据MTC设备的接入层密钥解密得到组密钥。 [0243] 例如，方法1500可以由MTC设备执行。由于MTC设备的操作与基站、MME的操作相对应，因此方法1500中的各步骤的描述可以参考方法100和方法1400的描述，具体实施例可以参考上述第一例子至第六例子，为了避免重复，在此不再赘述。 [0244] 根据本发明的实施例，同一组ID的所有MTC设备共用相同的HFN。为了保证同一组ID对应的HFN相同，组ID对应的HFN可以被预先设置为固定值，也可以由基站向MTC设备通知与HFN取值相关的信息。例如，MTC设备可以通过MTC设备的信令承载、组ID对应组的公共信令承载或者广播信道，从基站接收HFN的取值；或者MTC设备可以在组ID对应的HFN达到阈值时，通过MTC设备的信令承载、组ID对应组的公共信令承载或者广播信道，从基站接收用于指示HFN加1的指示信息。 [0245] 为了进一步提高组通信的安全性，网络侧可以对组密钥进行更新，而MTC设备需要通过更新后的组密钥来进行组通信。根据本发明的一个实施例，MTC设备可以从基站获取用MTC设备的接入层密钥加密的更新后的组密钥，其中更新后的组密钥由基站在组ID对应的HFN达到阈值时进行组密钥的更新而得到；根据MTC设备的接入层密钥解密得到更新后的组密钥。 [0246] 当网络侧维护的预定定时器达到第一预定阈值时，或者当基站更新组密钥的次数达到第二预定阈值时，或者当MME维护的非接入层的计数值达到第三预定阈值时，与MME进行重认证或者从基站获取基站用MTC设备的接入层密钥加密的新的组密钥。这样，可以在一定时间之后更新组密钥，避免同一组密钥的使用时间过长而引入不安全因素，从而也可以进一步提高组通信的安全性。 [0247] 根据本发明实施例提供的生成组密钥的方法，网络侧通过确定MTC设备所在组的组ID，从而确定与该组ID对应的组密钥，通过借助于MTC设备的接入层密钥可以将MTC设备使用的组密钥安全地分配给MTC设备，并使得同一组ID内的MTC设备共用相同的组密钥。这样，同一组内的MTC设备可以利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥，从而，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0248] 上面分别从基站、MME和MTC设备的角度描述了生成组密钥的方法，下面结合图16至21描述相关设备。 [0249] 图16是根据本发明实施例的基站1600的结构框图。 [0250] 基站1600包括第一获取模块1610、第二获取模块1620、生成模块1630和第一发送模块1640。第一获取模块1610可以通过输入接口和/或处理器实现，第二获取模块1620可以通过输入接口和/或处理器实现，生成模块1630可以通过处理器实现，第一发送模块1640可以通过输出接口实现。 [0251] 第一获取模块1610用于获取MTC设备所在组的组ID。第二获取模块1620用于获取组ID对应的组通信根密钥。生成模块1630用于根据组通信根密钥生成组ID对应的组密钥。第一发送模块1640用于向MTC设备发送用MTC设备的接入层密钥加密的组密钥，以使MTC设备根据MTC设备的接入层密钥解密得到组密钥。 [0252] 第一获取模块1610、第二获取模块1620、生成模块1630和第一发送模块1640的上述和其他操作和/或功能可以参考上述方法100以及第一例子至第六例子的描述，为了避免重复，在此不再赘述。 [0253] 根据本发明实施例提供的基站，通过确定MTC设备所在组的组ID，从而确定与该组ID对应的组密钥，再借助于MTC设备的接入层密钥可以将MTC设备使用的组密钥安全地分配给MTC设备，并使得同一组ID内的MTC设备共用相同的组密钥。这样，同一组内的MTC设备可以利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥，从而，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0254] 图17是根据本发明实施例的基站1700的结构框图。 [0255] 基站1700的第一获取模块1710、第二获取模块1720、生成模块1730和第一发送模块1740与基站1600的第一获取模块1610、第二获取模块1620、生成模块1630和第一发送模块1640基本相同。 [0256] 根据本发明的实施例，第一获取模块1710具体可用于将MTC设备划分到组ID对应的组内；或者从其它网元获取MTC设备所在组的组ID。 [0257] 根据本发明的实施例，第二获取模块1720具体可用于从所述组ID内的MTC设备中选择MTC设备，根据所选择的MTC设备的密钥确定所述组ID对应的组通信根密钥。或者，第二获取模块1720具体可用于从MME接收组ID对应的组通信根密钥，其中由MME将MTC设备划分到组ID对应的组内，从组ID内的MTC设备中选择MTC设备，根据所选择的MTC设备的密钥确定组ID对应的组通信根密钥，或者由MME根据MME生成的随机数确定组ID对应的组通信根密钥。或者，第二获取模块1720具体可用于生成一个随机数，根据该随机数确定组ID对应的组通信根密钥。 [0258] 根据本发明的一个实施例，第一获取模块1710和第二获取模块1720具体可用于从MME接收组ID和组通信根密钥，组通信根密钥由MTC设备所属的归属用户系统HSS根据随机数和与组ID对应的集合密钥生成，或者组通信根密钥由HSS在收到MME转发的来自一个MTC设备的组ID时，根据随机数、组ID和该一个MTC设备的专属密钥生成，并由HSS将组通信根密钥发送给MME。 [0259] 根据本发明的一个实施例，第一获取模块1710可以包括接收单元1712和确定单元1714。接收单元1712可用于从MME接收业务ID和与业务ID对应的业务根密钥，业务ID为MTC设备发送给MME的、MTC设备所属业务的业务ID，业务根密钥由MTC设备所属的HSS根据随机数和与业务ID对应的集合密钥生成，或者业务根密钥由HSS在收到MME转发的来自一个MTC设备的业务ID时，根据随机数、业务ID和一个MTC设备的专属密钥生成，并由HSS将业务根密钥发送给MME。确定单元1714可用于根据业务ID确定MTC设备所在组的组ID。在该情况下，第二获取模块1720可用于根据业务根密钥生成组ID对应的组通信根密钥。 [0260] 根据本发明的实施例，基站1700还可以包括绑定模块1750、第三获取模块1760和第二发送模块1770。绑定模块1750可用于将组通信根密钥、组密钥与组ID相绑定并存储。第三获取模块1760用于当确定其它MTC设备属于组ID对应的组时，根据组ID获取相绑定的组密钥。第二发送模块1770用于向其它MTC设备发送用其他MTC设备的接入层密钥加密的组密钥，以使所述其他MTC设备根据所述其他MTC设备的接入层密钥解密得到组密钥。 [0261] 根据本发明的实施例，同一组ID的所有MTC设备可以共用相同的HFN。这样，可以减少基站需要维护的PDCP Count值，进一步降低基站的处理复杂度。在该情况下，基站1700还可以包括更新模块1780和第三发送模块1790。更新模块1780用于当组ID对应的HFN达到阈值时，更新组密钥。第三发送模块1790用于向MTC设备发送用MTC设备的接入层密钥加密的更新后的组密钥，以使MTC设备根据MTC设备的接入层密钥解密得到更新后的组密钥。这样，可以避免同一组密钥使用时间过长而引入不安全因素，从而可以进一步提高通信安全性。 [0262] 为了保证同一组ID的所有MTC设备共用相同的HFN，可以将组ID对应的HFN预先设置为固定值，也可以由基站来通知与HFN相关的信息。根据本发明的实施例，基站1700还可以包括第四发送模块1795。第四发送模块1795可以用于通过组ID对应组内所有MTC设备各自的信令承载、组ID对应组的公共信令承载或者广播信道，向组ID对应组内所有MTC设备发送HFN的取值。或者，第四发送模块1795可以用于当组ID对应的HFN达到阈值时，通过组ID对应组内所有MTC设备各自的信令承载、组ID对应组的公共信令承载或者广播信道，向组ID对应组内所有MTC设备发送用于指示HFN加1的指示信息。 [0263] 第一获取模块1710、第二获取模块1720、接收单元1712、确定单元1714、绑定模块1750、第三获取模块1760、第二发送模块1770、更新模块1780、第三发送模块1790和第四发送模块1795的上述和其他操作和/或功能可以参考上述方法100以及第一例子至第六例子的描述，为了避免重复，不再赘述。其中，绑定模块1750、第三获取模块1760和更新模块1780可以通过处理器实现，第二发送模块1770、第三发送模块1790和第四发送模块1795可以通过输出接口实现。 [0264] 根据本发明实施例提供的基站，基站可以向同一组内的MTC设备发送相同的组密钥，从而可以使同一组内的MTC设备利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥，这样，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0265] 图18是根据本发明实施例的移动性管理实体1800的结构框图。 [0266] 移动性管理实体1800包括第一获取模块1810、第二获取模块1820和发送模块1830。第一获取模块1810和第二获取模块1820可以通过输入接口和/或处理器实现，发送模块1830可以通过输出接口实现。 [0267] 第一获取模块1810用于获取MTC设备所在组的组ID。第二获取模块1820用于获取组ID对应的组通信根密钥。发送模块1830用于向基站发送组ID和组通信根密钥，以使基站根据组通信根密钥生成组ID对应的组密钥并向MTC设备发送用MTC设备的接入层密钥加密的组密钥。 [0268] 第一获取模块1810、第二获取模块1820和发送模块1830的上述和其他操作和/或功能可以参考上述方法1400以及第一例子至第六例子的描述，为了避免重复，在此不再赘述。 [0269] 根据本发明实施例提供的移动性管理实体，通过确定MTC设备所在组的组ID和组通信根密钥，可以使基站确定与该组ID对应的组密钥，并将MTC设备使用的组密钥通过MTC设备的接入层密钥的加密而安全发送给MTC设备，使得同一组ID内的MTC设备可以共用相同的组密钥。这样，同一组内的MTC设备可以利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥，从而，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0270] 图19是根据本发明实施例的移动性管理实体1900的结构框图。 [0271] 移动性管理实体1900的第一获取模块1910、第二获取模块1920和发送模块1930与移动性管理实体1800的第一获取模块1810、第二获取模块1820和发送模块1830基本相同。 [0272] 根据本发明的实施例，第一获取模块1910具体可用于将MTC设备划分到组ID对应的组内。或者，第一获取模块1910具体可用于从其它网元获取MTC设备所在组的组ID。或者，第一获取模块1910具体可用于接收MTC设备发送的组ID。 [0273] 根据本发明的实施例，第一获取模块1910还可具体用于接收MTC设备发送的组ID。在该情况下，第二获取模块1920可以包括发送单元1922、接收单元1924和生成单元1926。发送单元1922用于向MTC设备所属的HSS发送组ID，以使HSS根据随机数和与组ID对应的集合密钥生成第一参数。接收单元1924用于从HSS接收第一参数。生成单元1926用于根据第一参数生成组ID对应的组通信根密钥。其中，发送单元1922具体可用于当组ID没有绑定与组ID对应的第一参数时，向MTC设备所属的HSS发送组ID。 [0274] 根据本发明的实施例，移动性管理实体1900还可以包括第一绑定模块1940和第三获取模块1950。第一绑定模块1940可用于将第一参数与组ID相绑定并存储。第三获取模块1950可用于当收到其它MTC设备发送的携带有组ID的附着请求时，根据组ID获取与组ID相绑定的第一参数，以使生成单元1926根据第一参数生成组ID对应的组通信根密钥。 [0275] 根据本发明的实施例，移动性管理实体1900还可以包括接收模块1960和认证模块1970。接收模块1960用于从HSS接收组认证参数，其中组认证参数由HSS根据与组ID对应的集合密钥生成，或者由HSS根据与组ID对应的集合密钥和MTC设备的专属密钥生成。认证模块1970用于根据组认证参数，与MTC设备进行认证。此时，生成单元1926可以用于在MTC设备与网络侧认证成功之后，根据第一参数生成组ID对应的组通信根密钥。 [0276] 根据本发明的实施例，第二获取模块1920可以具体用于从组ID内的MTC设备中选择一个MTC设备，并根据所选择的MTC设备的密钥确定组ID对应的组通信根密钥。第二获取模块1920还可以具体用于生成一个随机数，根据该随机数确定组ID对应的组通信根密钥。 [0277] 移动性管理实体1900还可以包括第二绑定模块1980和第四获取模块1990。第二绑定模块1980可用于将组ID和组通信根密钥进行绑定并存储。第四获取模块1990可用于当确定其他MTC设备属于组ID对应的组时，根据组ID获取相绑定的组通信根密钥，以使发送模块1930向基站发送组ID和组通信根密钥。 [0278] 根据本发明的实施例，移动性管理实体1900还可以包括处理模块1992。处理模块1992可用于当网络侧维护的预定定时器达到第一预定阈值时，或者当基站更新组密钥的次数达到第二预定阈值时，或者当维护的非接入层的计数值达到第三预定阈值时，与MTC设备进行重认证或者获取组ID对应的新的组通信根密钥。 [0279] 第一获取模块1910、第二获取模块1920、发送单元1922、接收单元1924、生成单元1926、第一绑定模块1940、第三获取模块1950、接收模块1960、认证模块1970、第二绑定模块 1980、第四获取模块1990和处理模块1992的上述和其他操作和/或功能，可以参考上述方法 1400以及第一例子至第六例子的描述，为了避免重复，在此不再赘述。其中，第一绑定模块 1940、第三获取模块1950、认证模块1970、第二绑定模块1980和第四获取模块1990可以通过处理器实现，接收模块1960可以通过输入接口实现，处理模块1992可以通过处理器和/或输入接口实现。 [0280] 根据本发明实施例提供的移动性管理实体，移动性管理实体通过向基站发送组ID和组通信根密钥，可以使基站向同一组内的MTC设备发送相同的组密钥，从而可以使同一组内的MTC设备利用相同的组密钥来正常进行组通信，而在基站中也只需要为同一个组保持相同组密钥。这样，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0281] 图20是根据本发明实施例的机器类通信设备2000的结构框图。 [0282] 机器类通信设备2000包括第一接收模块2010和第一解密模块2020，第一接收模块2010可以通过输入接口实现，第一解密模块2020可以通过处理器实现。 [0283] 第一接收模块2010用于从基站接收基站用MTC设备的接入层密钥加密的组密钥，其中组密钥由基站根据基站获取的组通信根密钥生成、并与基站获取的MTC设备所在组的组ID对应，或者组密钥由基站根据从MME获取的组通信根密钥生成、并与MME获取的MTC设备所在组的组ID对应。第一解密模块2020用于根据MTC设备的接入层密钥解密得到组密钥。 [0284] 第一接收模块2010和第一解密模块2020的上述和其他操作和/或功能可以参考上述方法1500以及第一例子至第六例子的描述，为了避免重复，在此不再赘述。 [0285] 根据本发明实施例提供的机器类通信设备，通过从基站接收和与所在组对应的组密钥，可以与同一组的其他MTC设备共用相同的组密钥来正常进行组通信，并且在基站中也只需要为同一个组保持相同组密钥，从而，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0286] 图21是根据本发明实施例的机器类通信设备2100的结构框图。 [0287] 机器类通信设备2100的第一接收模块2110和第一解密模块2120与机器类通信设备2000的第一接收模块2010和第一解密模块2020基本相同。 [0288] 根据本发明的实施例，同一组ID的所有MTC设备可以共用相同的HFN。这样，可以使基站为同一组ID维持一个PDCP Count值，从而可以进一步降低基站的处理复杂度。 [0289] 机器类通信设备2100还可以包括第二接收模块2130和第二解密模块2140。第二接收模块2130用于从基站接收用MTC设备的接入层密钥加密的更新后的组密钥，其中更新后的组密钥由基站在组ID对应的HFN达到阈值时进行组密钥的更新而得到。第二解密模块2140用于根据MTC设备的接入层密钥解密得到更新后的组密钥。 [0290] 为了使同一组的MTC设备共用相同的HFN，可以将组ID对应的HFN预先设置为固定值，也可以由MTC设备从基站接收与HFN取值相关的信息。根据本发明的实施例，机器类通信设备2100可以包括第三接收模块2150。第三接收模块2150可用于通过MTC设备的信令承载、组ID对应组的公共信令承载或者广播信道，从基站接收HFN的取值。第三接收模块2150也可用于当组ID对应的HFN达到阈值时，通过MTC设备的信令承载、组ID对应组的公共信令承载或者广播信道，从基站接收用于指示HFN加1的指示信息。 [0291] 此外，为了避免同一组密钥使用时间过长而引入不安全因素，可以在达到一定条件时，对组密钥进行更新，以进一步提高组通信的安全性。根据本发明的实施例，机器类通信设备2100还可以包括处理模块2160。处理模块2160可用于当网络侧维护的预定定时器达到第一预定阈值时，或者当基站更新组密钥的次数达到第二预定阈值时，或者当MME维护的非接入层的计数值达到第三预定阈值时，与MME进行重认证或者从基站获取基站用MTC设备的接入层密钥加密的新的组密钥。 [0292] 第二接收模块2130、第二解密模块2140、第三接收模块2150和处理模块2160的上述和其他操作和/或功能可以参考上述方法1500以及第一例子至第六例子的描述，为了避免重复，在此不再赘述。其中，第二接收模块2130和第三接收模块2150可以通过输入接口实现，第二解密模块2140可以通过处理器实现，处理模块2160可以通过处理器和/或输入接口实现。 [0293] 根据本发明实施例提供的机器类通信设备，通过从基站接收与所在组对应的组密钥，可以使同一组内的MTC设备利用相同的组密钥来正常进行组通信，并且在基站中也只需要为同一个组保持相同组密钥。这样，可以降低基站操作的复杂性，减少基站维护和管理的密钥数，提高基站性能。 [0294] 本领域技术人员可以意识到，结合本文中所公开的实施例中描述的各方法步骤和单元，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。 |
||||||
