CN101521656A - 组业务加密密钥更新方法及系统 - Google Patents

Abstract

本发明实施例涉及一种组业务加密密钥更新方法，网络侧实体发送携带GTEK更新信息的MBS_MAP消息；MS接收到MBS_MAP消息后，得到GTEK更新信息，并更新对应的MBS的GTEK。本发明实施例还涉及一种组业务加密密钥更新系统，包括网络侧实体和移动台。本发明实施例的组业务加密密钥更新方法及系统，可以避免由于享用该MBS业务的多个MS的寻呼侦听间隔的不一样，按每个MS的寻呼侦听间隔多次发送GTEK更新信息，可以同时通知所有享有同一MBS业务的MS，并可以避免空口资源浪费；MBS_MAP消息属于多播发送方式，可以使用SFN方式进行发送，提高指示消息的可靠性。

Description

组业务加密密钥更新方法及系统

技术领域

本发明涉及移动通信技术领域，特别涉及一种组业务加密密钥更新方法及系统。

背景技术

WiMAX的全名是微波互操作全球互通(Worldwide Interoperability forMicrowave Access)，又称为802.16无线城域网，是一种为企业和家庭用户提供“最后一英里”的宽带无线连接方案，在数据通信领域可实现高覆盖范围，可以覆盖25～30英里的范围。WiMAX以IEEE 802.16的系列宽频无线标准为基础，作为它的空口协议。IEEE 802.16标准系列到目前为止包括802.16、802.16a、802.16c、802.16d、802.16e、802.16f和802.16g共七个标准。其中，802.16、16a、16d属于固定无线接入空中接口标准，802.16e属于移动宽带无线接入空中标准。WiMAX更在802.16e的基础上，提出了新的增强技术802.16m，802.16m要与802.16e兼容。

下面对移动台(Mobile Station，以下简称：MS)的空闲模式与寻呼原理加以介绍，由于系统的空闲模式与寻呼原理都是类似的，因此以IEEE 802.16e的空闲模式与寻呼作为示例，描述如下：

当MS处于空闲模式(Idle Mode)时，MS可以在很大的一个区域内移动，每隔一定的周期将接收下行广播的业务消息。MS在这个区域内漫游过程中不必在漫游的小区向这个小区的基站(Base Station，以下简称：BS)进行注册。空闲模式下，MS漫游到不同小区时，不必进行切换等正常操作流程，从而有利于节省MS的功率和空口资源。处于空闲模式的移动设备，会周期性的向BS发送信号进行位置更新的过程；或者当其所在寻呼区域发生改变时，也会向BS发送信号进行位置更新的过程。空闲模式为BS提供了一种简单、及时的方法通知MS是否有下行广播的业务消息发送，及寻呼方式。

寻呼(Paging)：当网络侧实体，一般为BS，检测到处于空闲模式的MS有消息来到时，就会发起寻呼MS的过程。在IEEE802.16e中，寻呼消息由BS广播给MS。当MS解析得到的消息中的MS MAC地址的哈希值与自己本身MAC地址的哈希值匹配时，就认为BS是在寻呼自己；然后MS就根据消息中的动作码(Action Code)来执行相应的动作。

现有的802.16e标准中，当MS进入空闲模式后，会周期的在寻呼侦听间隔(paging listening interval)醒过来并接收寻呼消息(MOB_PAG_ADV)。此时，如果MS还加入了某一多播广播业务(Multicast Broadcast Service，以下简称：MBS)，即一种在下行链路上点到多点的数据传输服务，MS还会在每一次多播广播业务指配消息(以下简称：MBS_MAP Message)指定的到达时刻醒过来，在相应的广播连接上接收数据。其中，MBS_MAP消息为一链式指配方式消息，即在当前的MBS_MAP消息中会指出下一次发送的MBS_MAP消息的到达时刻。因此MS可以一环接一环的解出MBS_MAP消息的到达时刻。也就是说，当MS进入空闲模式，并且已经加入某一MBS业务后，会在寻呼侦听间隔和MBS_MAP消息的到达时刻醒过来。

MBS业务可以采用单频网(Single Frequency Network，以下简称：SFN)方式发送，即多个BS可以利用相同的时频资源发送相同的数据，以使得MS可以从多个基站接收信号，达到更好的接收效果。

MS接收的MBS的多播数据是进行密钥管理的，组业务加密密钥(GroupTraffic Encryption Key，以下简称：GTEK)的作用是生成多播数据的加密密钥；组密钥加密密钥(Group Key Encryption Key，以下简称：GKEK)的作用是加密GTEK。一个GKEK负责多个GTEK的更新，通过MS的主要管理连接，BS单播GKEK给MS的；多个GTEK是用GKEK加密然后广播给MS的。如果处于空闲模式的MS需要更新GTEK，BS需要在处于空闲模式的MS的寻呼侦听间隔，广播GTEK给不同的MS。如果享用同一个MBS业务的不同MS有不同的寻呼侦听间隔，那么BS要广播多次更新GTEK的通知消息。

综上所述，在现有的多播业务的密钥更新流程中，存在如下的技术缺陷：享用该MBS业务的MS的寻呼侦听间隔可能是不一样的，因此要多次广播发送GTEK更新通知消息，即PKMv2 Group-Key-Update-Command(GTEKx+1)消息，造成了空口资源的浪费，并导致所有使用此MBS业务的MS的GKEK的全部更新完成是一个非常漫长的过程，无法做到同步更新；由于GTEK是广播发送的，因此，所有不相关的MS都要解GTEK更新通知消息；由于GTEK更新通知消息是广播发送的，因此，不能采用SFN方式。

发明内容

本发明实施例提供一种组业务加密密钥更新方法及系统，将GTEK更新信息置于MBS_MAP消息中发送移动台进行组业务加密密钥更新，以同步更新GTEK，并可获得更好的SFN增益效果。

本发明实施例提供了一种组业务加密密钥更新方法，包括：

网络侧实体发送携带组业务加密密钥更新信息的多播广播业务指配消息；

移动台接收到所述多播广播业务指配消息后，得到所述组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

本发明实施例还提供了一种组业务加密密钥更新系统，包括：

网络侧实体，用于发送携带组业务加密密钥更新信息的多播广播业务指配消息；

移动台，用于接收到所述多播广播业务指配消息后，得到所述组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

由以上技术方案可知，本发明实施例的组业务加密密钥更新方法及系统，可以克服上述技术缺陷，并带来如下技术效果：

1)避免了由于享用该MBS业务的多个MS的寻呼侦听间隔的不一样，按每个MS的寻呼侦听间隔多次发送GTEK更新通知消息，并可以避免空口资源浪费；

2)BS在MBS_MAP消息中，通过一次携带GTEK更新信息就可以通知所有享有同一MBS业务的MS，即对应的GTEK更新信息的发送对所有的MS来说是同步的；

3)MBS_MAP消息属于多播发送方式，可以使用SFN方式进行发送，因此，由它携带GTEK更新信息会带来SFN增益，提高指示消息的可靠性。

下面通过具体实施例并结合附图对本发明做进一步的详细描述。

附图说明

图1为本发明组业务加密密钥更新方法实施例一的流程示意图；

图2为本发明组业务加密密钥更新方法实施例二的流程示意图；

图3为本发明组业务加密密钥更新方法实施例三的流程示意图；

图4为本发明组业务加密密钥更新方法实施例四的流程示意图；

图5为本发明组业务加密密钥更新方法实施例五的流程示意图；

图6为本发明组业务加密密钥更新系统实施例的结构示意图。

具体实施方式

本发明实施例的方案是通过将GTEK更新信息置于MBS_MAP消息中发送移动台进行组业务加密密钥更新，以获得更好的SFN增益效果。本发明实施例中的网络侧实体包括但不限于BS。

如图1所示，为本发明组业务加密密钥更新方法实施例一的流程示意图，具体步骤如下：

步骤101、网络侧实体发送携带组业务加密密钥更新信息的多播广播业务指配消息；

将现有技术中，当MS处于空闲状态时，在MS的寻呼有效间隔发送GTEK更新通知消息更改为：通过在MBS_MAP消息中携带GTEK更新信息，这样可以做到同一MBS业务下的所有MS可以一次性的同时收到GTEK更新信息；

步骤102、移动台接收到多播广播业务指配消息后，得到组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

MS接收到MBS_MAP消息后，可以解密得到GTEK，并更新其对应的多播广播业务的GTEK。

本实施例提供的组业务加密密钥更新方法，通过将GTEK更新信息置于MBS_MAP消息中发送给MS，使得MS可以进行GTEK的更新，避免了现有技术中通过寻呼方式进行GTEK更新造成的空口资源浪费及更新过程漫长的缺陷，可以做到同时对所有MBS业务对应的MS进行GTEK的更新，及获得更好的SFN增益效果等。

如图2所示，为本发明组业务加密密钥更新方法实施例二的流程示意图，具体步骤如下：

步骤201、网络侧实体在多播广播业务指配消息中的可扩展编码元中携带组业务加密密钥更新信息，并发送；

其中，可扩展的编码元，即类型、长度、值编码元(TLV encoding element)；

步骤202、移动台接收到多播广播业务指配消息后，得到可扩展编码元中携带的组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

MS接收到MBS_MAP消息后，可以从扩展的编码元(TLV encodingelement)中解密得到GTEK，并更新其对应的多播广播业务的GTEK。

其中，扩展的TLV encoding element内容可以为如下表一所示：

表一

 

Type类型

Length长度

Value值

 

Type为现有标准中可以使用而不冲突的任意值

根据内容而定

GTEK更新信息(见表二)

表一中的Value值，即GTEK更新的信息内容如下表二所示：

表二

 

属性	内容
		No.GSAID	组安全联盟标识的个数(可选)
GSAID	组安全联盟标识(可选)
		业务加密密钥(TEK)	TEK，使用协商的TEK加密算法进行加密(encrypted with the negotiated TEK encryptionalgorithm)(必选)GTEK由GKEK进行加密(必选)
密钥生存时间(Key-Lifetime)	TEK生存时间(可选)
		TEK顺序号(Key-Sequence-Number)	TEK顺序号(可选)
密码块链条初始向量(CBC-IV)	密码块链条初始向量(Cipher block chaininginitialization vector)(可选)
		关联的GKEK顺序号	带有TEK参数关联的GKEK顺序号(Associated GKEK sequence number with thisTEK-Parameters)(可选)

在该实施例的实现中，如果现有标准协议已经有相应的TLV，那么可以利用此TLV进行承载，比如在802.16e标准中，已经存在类似的TLV：SA-TEK-Update，此TLV包括了上面新增TLV的内容，但是标准中此TLV不能在MBS_MAP消息中携带，因此需要对此TLV的定义进行修改，使得它可以在MBS_MAP消息中携带。通过此方法可以非常容易的在一些标准中实现在MBS_MAP消息中携带GTEK更新信息。

本实施例具体说明了将GTEK更新信息置于MBS_MAP消息中的可扩展编码元中发送给MS，避免了现有技术进行GTEK更新造成的空口资源浪费及更新过程漫长的缺陷，可以做到同时对所有MBS业务对应的MS进行GTEK的更新，及获得更好的SFN增益效果等。

如图3所示，为本发明组业务加密密钥更新方法实施例三的流程示意图，具体步骤如下：

步骤301、网络侧实体在多播广播业务指配消息中的信息元中携带组业务加密密钥更新信息，并发送；

其中，信息元包括：有多播广播业务数据信息元(MBS_DATA_IE)、多播广播业务数据时分信息元(MBS_DATA_Time_Diversity_IE)、扩展多播广播业务数据信息元(Extended MBS_DATA_IE)三种类型的IE之一或者某两个或者三个都有；GTEK更新信息可以携带在MBS_MAP消息包括的三种IE的一个或者多个中；

步骤302、移动台接收到多播广播业务指配消息后，得到信息元中携带的组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

MS接收到MBS_MAP消息后，可以从信息元中解密得到GTEK，并更新其对应的多播广播业务的GTEK。GTEK更新的信息内容如上表二所示。

本实施例具体说明了将GTEK更新信息置于MBS_MAP消息中的信息元中发送给MS，避免了现有技术进行GTEK更新造成的空口资源浪费及更新过程漫长的缺陷，可以做到同时对所有MBS业务对应的MS进行GTEK的更新，及获得更好的SFN增益效果等。

如图4所示，为本发明组业务加密密钥更新方法实施例四的流程示意图，具体步骤如下：

步骤401、网络侧实体在多播广播业务数据包中携带组业务加密密钥更新信息，并发送；

即在MBS数据包的MAC头携带GTEK更新信息的方法有两种：通过MAC子头来携带GTEK更新信息；增加一种MAC扩展子头来携带GTEK更新信息；

步骤402、移动台接收到多播广播业务数据包后，得到该数据包中携带的组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

MS接收到MBS_MAP消息后，可以从数据包中解密得到GTEK，并更新其对应的多播广播业务的GTEK。GTEK更新的信息内容如上表二所示。

本实施例具体说明了将GTEK更新信息置于MBS_MAP消息指配的数据包中发送给MS，避免了现有技术进行GTEK更新造成的空口资源浪费及更新过程漫长的缺陷，可以做到同时对所有MBS业务对应的MS进行GTEK的更新，及获得更好的SFN增益效果等。

如图5所示，为本发明组业务加密密钥更新方法实施例五的流程示意图，具体步骤如下：

步骤501、通过移动台的主要管理连接，网络侧实体单播组密钥加密密钥更新信息至移动台；

网络侧实体，一般为BS，单播(即BS分别单独对不同的MS)发送某一MBS业务对应的GKEK更新信息给已经加入此MBS业务的MS，此GKEK是为后面加密的多个多播广播业务数据对应的GTEK1至GTEKn的n个GTEK传输而使用的；

步骤502、当组业务加密密钥更新期到达时，发送携带组业务加密密钥更新信息的多播广播业务指配消息；

当某一多播广播业务对应的GTEK，例如GTEK1的更新期到达的时候，BS可以在对应的MBS_MAP消息中携带GTEK1更新通知信息；

步骤503、移动台根据组密钥加密密钥更新信息中的组密钥加密密钥，解密组业务加密密钥更新信息中的组业务加密密钥；

利用步骤501单播发送至MS的GKEK解密对应的GTEK1更新信息，并得到其中的GTEK1；

步骤504、移动台根据得到的组业务加密密钥更新对应的多播广播业务的组业务加密密钥。

MS根据得到的GTEK1更新原来多播广播业务对应的GTEK，完成某一多播广播业务对应的GTEK更新。

在步骤501中提到，GKEK是为后面加密的多个多播广播业务数据对应的GTEK1至GTEKn的n个GTEK传输而使用的，那么对应于其他多播广播业务的GTEK2至GTEKn也是采用上述的步骤，在不同的对应的MBS_MAP消息中携带GTEK更新信息，发送至MS，可以对对应的多播广播业务的GTEK进行更新。GTEK更新的信息内容如上表二所示。

在上述步骤502中，具体的可以在MBS_MAP消息的可以扩展的编码元，即类型、长度、值编码元(TLV encoding element)中携带GTEK更新信息。标准中的MBS_MAP消息格式如下表三所示。

表三

 

Syntax语句	Size(bit)字节	Notes注解
			MBS_MAP Message format(){	—	—
Management Message Type＝62	8	62
			MBS_DIUC_Change_Count	8	—
#MBS_DATA_IE	4	消息中包括MBS DATA IE的个数
			for(i＝0；i<n；i++){	—	n＝#MBS DATA IEs
MBS_DATA_IE	variable	—
			}	—	—
#Extended_MBS_DATA_IE	4	消息中包括Extended MBSDATA IE的个数
			for(i＝0；i<k；i++){	—	k＝#Extended MBS DATA IEs
Extended_MBS_DATA_IE()	variable	—
			}
#MBS_DATA_Time_Diversity_IE	4	消息中包括MBS DATA TimeDiversity IE的个数
			for(i＝0；i<m；i++){	—	m＝#MBS DATA Time DiversityIEs
MBS_DATA_Time_Diversity_IE()	variable	—
			}	—	—
if(！byte boundary){	—	—
			Padding Nibble	4	—
}
			TLV encoding element	—	—
}

可以看出在MBS_MAP消息中，后面带了一个可以扩展的TLV encodingelement，这个TLV encoding element可以用来携带GTEK更新信息，新增的TLV内容如上表一、表二所示。

其中，在本实施例的具体实现中，如果现有标准协议已经有相应的TLV，那么可以利用此TLV进行承载，比如在802.16e标准中，已经存在类似的TLV：SA-TEK-Update，此TLV包括了上面新增TLV的内容，但是标准中此TLV不能在MBS_MAP消息携带，因此需要对此TLV的定义进行修改，使得它可以在MBS_MAP消息中携带。通过此方法可以非常容易的在一些标准中实现在MBS_MAP消息中携带GTEK更新信息。

在上述步骤502中，具体的还可以在MBS_MAP消息的信息元(information element，以下简称：IE)中携带GTEK更新信息。MBS MAP消息包括有多播广播业务数据信息元(MBS_DATA_IE)、多播广播业务数据时分信息元(MBS_DATA_Time_Diversity_IE)、扩展多播广播业务数据信息元(Extended MBS_DATA_IE)三种类型的IE之一或者某两个或者三个都有，如表二所示。GTEK更新信息可以携带在MBS_MAP消息包括的三种IE的一个或者多个中。

MBS_DATA_IE中携带GTEK更新信息示例如下表四所示：

表四

 

Syntax语句	Size(bits)字节	Notes注释
			MBS_DATA_IQE(){		多播广播业务数据信元
MBS_MAP Type＝0	2	多播广播业务指配类型为0
			MBS Burst Frame Offset	2	多播广播业务突发帧偏移
Next MBS MAP changeindication	1	下一次多播广播指配是否改变标识
			No.of Multicast CID	3	多播连接标识的数目
For(i＝0；i<No.of Multicast CID；i++){
			Multicast CID	12	多播连接标识的低12位
}
			MBS DIUC	4	多播广播业务下行链路间隔使用码
OFDMA Symbol Offset	8	正交频分多址接入符号偏移
			Subchannel Offset	6	子信道偏移
Boosting	3	同表1中的boosting
			No.OFDMA Symbols	7	多播广播业务指配消息所占的正交频分多址接入符号数目
No.Subchannels	6	多播广播业务指配消息所占的子信道数目
			Repetition Coding Indication	2	0b00：没有重复编码0b01：重复编码因子为2

 

		0b10：重复编码因子为40b11：重复编码因子为6
			Next MBS Frame Offset	8	下一次多播广播业务的帧偏移
Next MBS OFDMA SymbolOffset	8	下一次多播广播业务的正交频分多址接入符号偏移
			If(Next MBS MAP changeindication＝1){		如果下一次多播广播指配是否改变标识
Next MBS No.OFDMA Symbols	2	下一次多播广播业务指配消息所占的正交频分多址接入符号数目
			Next MBS No.OFDMASubchannels	6	下一次多播广播业务指配消息所占的子信道数目.
}
			GTEK更新信息	Variable	更新的GTEK信息(见表二)
Padding	variable	填充
			}

其中，多播广播业务指配类型，在原有标准中此处的值为0，本实施例中在该MBS_DATA_IE中增加携带GTEK更新信息后，可以采用新值，以跟原来的MBS_DATA_IE进行区分。当然，可以仍然使用原来的值。

Extended MBS_DATA_IE中携带GTEK更新信息示例如下表五所示：

表五

 

Syntax	Size(bits)	Notes
			Extended_MBS_DATA_IE(){		多播广播业务数据信元
MBS_MAP Type＝2	2	多播广播业务指配类型为2
			MBS Burst Frame Offset	2	多播广播业务突发帧偏移
Next MBS MAP change indication	1	下一次多播广播指配是否改变标识
			No.of Multicast CID	3	多播连接标识的数目
For(i＝0；i<No.ofMulticast CID；i++){
			Multicast CID	12	多播连接标识的低12位
No.of Logical Channel ID	4	逻辑链路标识的数目
			For(j＝0；j<No.of Logical Channel ID；j++){
Logical Channel ID	8	逻辑链路标识
			}
}
			MBS DIUC		多播广播业务下行链路间隔使用码
OFDMA Symbol Offset	8	正交频分多址接入符号偏移
			Subchannel Offset	6	子信道偏移
Boosting	3	同表1中的boosting

 

No.OFDMA Symbols	7	多播广播业务指配消息所占的正交频分多址接入符号数目
			No.Subchannels	6	多播广播业务指配消息所占的子信道数目
Repetition Coding Indication	2	0b00：没有重复编码0b01：重复编码因子为20b10：重复编码因子为40b11：重复编码因子为6
			Next MBS Frame Offset	8	下一次多播广播业务的帧偏移
Next MBS OFDMA Symbol Offset	8	下一次多播广播业务的正交频分多址接入符号偏移
			If(Next MBS MAP change indication＝1){		如果下一次多播广播指配是否改变标识
Next MBS No.OFDMA Symbols	2	下一次多播广播业务指配消息所占的正交频分多址接入符号数目
			Next MBS No.OFDMA Subchannels	6	下一次多播广播业务指配消息所占的子信道数目.
}
			GTEK更新信息	Variable	更新的GTEK信息(见表二)
Padding	variable	填充
			}

同上所述，在这里多播广播业务指配类型，在原有标准中此处的值为2，本实施例中在该Extended MBS_DATA_IE中增加携带GTEK更新信息后，可以采用新值，以跟原来的Extended MBS_DATA_IE进行区分。当然，可以仍然使用原来的值。

MBS_DATA_Time_Diversity_IE中携带GTEK更新信息示例如下表六所示：

表六

 

Syntax	Size(bits)	Notes
			MBS_DATA_Time_Diversity_IE(){		多播广播业务数据时间分集信元
MBS_MAP Type＝1	2	多播广播业务指配类型为1
			MBS Burst Frame Offset	2	多播广播业务数据突发帧偏移
Multicast CID	12	多播连接标识的低12位
			OFDMA symbol offset	8	正交频分多址接入符号偏移
N_EP code	4	编码包比特码(Code of encoder packetbits)
			N_SCH code	4	分配的子信道码(Code of allocated

 

		subchannels)
			AI_SN	1	自动重传请求标识序列号(ARQIdentifier Sequence Number)
SPID	2	子包标识(subpacket identifier)
			ACID		自动重传请求信道标识(ARQChannel Identifier)
Next MBS MAP change indication	1	下一次多播广播指配是否改变标识
			Next MBS frame offset	8	下一次多播广播业务的帧偏移
Next MBS OFDMA Symbol offset	8	下一次多播广播业务的正交频分多址接入符号偏移
			If(Next MBS MAP change indication＝1){		如果下一次多播广播指配是否改变标识
Next MBS No.OFDMA symbols		下一次多播广播业务指配消息所占的正交频分多址接入符号数目
			Next MBS No.OFDMA subchannels		下一次多播广播业务指配消息所占的子信道数目.
}
			GTEK更新信息	Variable	更新的GTEK信息(见表二)
Padding	variable	填充
			}

同上所述，在这里多播广播业务指配类型，在原有标准中此处的值为1，本实施例中在该MBS_DATA_Time_Diversity_IE中增加携带GTEK更新信息后，可以采用新值，以跟原来的MBS_DATA_Time_Diversity_IE进行区分。当然，可以仍然使用原来的值。

在上述步骤502中，具体的还可以在MBS_MAP消息指配的数据包中携带GTEK更新信息。

通过MS的主要管理连接，由网络侧实体发送GKEK来更新MS的某个多播业务的GKEK；当某个GTEK的更新期到达的时候，BS可以在对应的MBS数据包中携带GTEK更新信息；MS收到更新的GTEK之后就更新相应的GTEK；当下一个GTEK的更新期到达的时候，BS可以在对应的另一个MBS数据包中携带GTEK更新信息；MS收到GTEK更新信息之后就更新相应的GTEK。

下面给出在MBS数据包中携带GTEK信息的方法。在MBS数据包的MAC头携带GTEK更新信息的方法有两种：通过MAC子头来携带GTEK更新信息；增加一种MAC扩展子头来携带GTEK更新信息。本实施例中所述的信息格式及内容均基于IEEE 802.16e，MAC子头不能进行扩展。所以这里只是给出通过MAC扩展子头来携带GTEK的方法。但并不限于如果IEEE802.16m或是其他标准的MAC子头可以扩展的话就可以用MAC子头来携带GTEK。

新增一种MAC扩展子头用来携带GTEK更新信息，下面给出携带上述信息的扩展子头的具体形式，如表七所示。

表七

 

Syntax	Size(bits)	Notes
			Key Update Extended Subheader(){	-	组密钥加密密钥更新扩展子头
Extended Subheader Type＝5	7	扩展子头的类型值为5
			GTEK更新信息	Variable	更新的GTEK信息(见表二)
}

其中，扩展子头的类型值并不一定就是5，只要与现有标准不冲突即可。如上表所示，当MS解析到MAC扩展子头的GTEK时，就知道其对应的MBS业务对应的GTEK需要更新。

本实施例中所述的信息格式及内容均基于IEEE 802.16e，但不限于IEEE802.16e，并且在将来还可能会用在兼容IEEE 802.16e的IEEE 802.16m上。

本实施例提供的组业务加密密钥更新方法，通过单播GKEK更新信息至MS，并当GTEK更新期到达时，发送携带GTEK更新信息的MBS_MAP消息；MS再解密得到GTEK并更新对应多播广播业务的GTEK，可以实现同时对所有MBS业务对应的MS进行GTEK的更新，节省空口资源，及获得更好的SFN增益效果等。

如图6所示，为本发明组业务加密密钥更新系统实施例的结构示意图，该组业务加密密钥更新系统包括：

网络侧实体1，用于发送携带组业务加密密钥更新信息的多播广播业务指配消息。

移动台2，用于接收到多播广播业务指配消息后，得到组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

所述网络侧实体1具体还包括有单播模块11，用于通过移动台2的主要管理连接，由单播模块11单播组密钥加密密钥更新通知消息至移动台2。

所述移动台2具体包括有解密模块21，用于根据组密钥加密密钥更新信息中的组密钥加密密钥，解密组业务加密密钥更新信息中的组业务加密密钥；更新模块22，用于根据得到的组业务加密密钥更新对应的多播广播业务的组业务加密密钥。

以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (11)

1、一种组业务加密密钥更新方法，其特征在于包括：

网络侧实体发送携带组业务加密密钥更新信息的多播广播业务指配消息；

移动台接收到所述多播广播业务指配消息后，得到所述组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

2、根据权利要求1所述的组业务加密密钥更新方法，其特征在于在所述发送携带所述组业务加密密钥更新信息的多播广播业务指配消息之前包括：通过所述移动台的主要管理连接，所述网络侧实体单播组密钥加密密钥更新信息至所述移动台。

3、根据权利要求2所述的组业务加密密钥更新方法，其特征在于所述移动台接收到所述多播广播业务指配消息后，得到所述组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥具体为：

所述移动台根据所述组密钥加密密钥更新信息中的组密钥加密密钥，解密所述组业务加密密钥更新信息中的组业务加密密钥；

所述移动台根据得到的组业务加密密钥更新对应的多播广播业务的组业务加密密钥。

4、根据权利要求1、2或3所述的组业务加密密钥更新方法，其特征在于所述发送携带所述组业务加密密钥更新信息的多播广播业务指配消息具体为：

在所述多播广播业务指配消息中的可扩展编码元中携带所述组业务加密密钥更新信息，并发送。

5、根据权利要求1、2或3所述的组业务加密密钥更新方法，其特征在于所述发送携带所述组业务加密密钥更新信息的多播广播业务指配消息具体为：在所述多播广播业务指配消息中的信息元中携带所述组业务加密密钥更新信息，并发送。

6、根据权利要求5所述的组业务加密密钥更新方法，其特征在于所述在所述多播广播业务指配消息中的信息元中携带所述组业务加密密钥更新信息，并发送具体包括：

在所述多播广播业务指配消息中的多播广播业务数据信息元中携带所述组业务加密密钥更新信息，并发送；或

在所述多播广播业务指配消息中的多播广播业务数据时分信息元中携带所述组业务加密密钥更新信息，并发送；或

在所述多播广播业务指配消息中的扩展多播广播业务数据信息元中携带所述组业务加密密钥更新信息，并发送。

7、根据权利要求1、2或3所述的组业务加密密钥更新方法，其特征在于所述发送携带所述组业务加密密钥更新信息的多播广播业务指配消息具体为：在所述多播广播业务数据包中携带所述组业务加密密钥更新信息，并发送。

8、根据权利要求7所述的组业务加密密钥更新方法，其特征在于所述在所述多播广播业务指配消息中的多播广播业务数据包中携带所述组业务加密密钥更新信息，并发送具体包括：

在所述多播广播业务指配消息中的多播广播业务数据包的媒体接入控制子头中携带对应的所述组业务加密密钥更新信息，并发送；或

在所述多播广播业务指配消息中的多播广播业务数据包增加的媒体访问控制扩展子头中携带对应的所述组业务加密密钥更新信息，并发送。

9、一种组业务加密密钥更新系统，其特征在于包括：

网络侧实体，用于发送携带组业务加密密钥更新信息的多播广播业务指配消息；

移动台，用于接收到所述多播广播业务指配消息后，得到所述组业务加密密钥更新信息，并更新对应的多播广播业务的组业务加密密钥。

10、根据权利要求9所述的组业务加密密钥更新系统，其特征在于所述移动台包括：

解密模块，用于根据所述组密钥加密密钥更新信息中的组密钥加密密钥，解密所述组业务加密密钥更新信息中的组业务加密密钥；

更新模块，用于根据得到的组业务加密密钥更新对应的多播广播业务的组业务加密密钥。

11、根据权利要求9所述的组业务加密密钥更新系统，其特征在于所述网络侧实体还包括：单播模块，用于通过所述移动台的主要管理连接，所述单播模块单播组密钥加密密钥更新通知消息至所述移动台。

Images