CN105101108A - 集群业务中进行头压缩配置的方法、系统及核心网子系统 - Google Patents

Abstract

本发明公开了集群业务中进行头压缩配置的方法、系统及核心网子系统，其中，该方法包括：接收终端建立网络连接后上报的集群信道头压缩支持能力；根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给基站，以开启或关闭头压缩，进行数据下发。本发明方案能够在保证集群组中所有终端设备都接收下行数据的前提下，尽量启用头压缩，提高空中接口的带宽利用率。

Description

集群业务中进行头压缩配置的方法、系统及核心网子系统

技术领域

本发明涉及集群业务技术，尤其涉及集群业务中进行头压缩配置的方法、系统及核心网子系统。

背景技术

在基于IP的无线系统中，包头的开销是空中接口开销中不可忽略的一部分；尤其是在VoIP这种小语音包的场景中，语音的净荷一般为十几到二十几个字节，而IP、用户数据报协议(UDP，UserDatagramProtocol)包头的开销可能占到四十个字节左右，占整个数据包的2/3。为了提高空中接口带宽利用率，一般采取头压缩的方式来减少包头的大小。

但对于基于IP的集群业务，无法保证集群组中所有的终端都能支持IP头压缩。为描述方便，下文将不支持集群下行业务信道的头压缩的终端称为“低能力终端”，将支持集群下行业务信道的头压缩的终端称为“高能力终端”。在集群系统中，为了节约空中接口下行资源，在组呼业务中大多采用广播/组播的方式将下行数据流发给被叫终端，某些情形下集群组中可能存在部分低能力终端，此时，若对集群组内所有终端开启头压缩，将导致其中的低能力终端无法正确接收下行数据。

由以上分析，如果一个集群组中同时存在高能力终端和低能力终端，则不宜对所有终端开启头压缩。鉴于此，需要一种机制，既保证所有终端可接收下行数据，还能尽量提高空中接口的带宽利用率。

发明内容

本发明提供了一种集群业务中进行头压缩配置的方法，该方法能够保证集群组中所有终端设备都接收下行数据，且尽量提高空中接口的带宽利用率。

本发明提供了一种集群业务中进行头压缩配置的系统，该系统能够保证集群组中所有终端设备都接收下行数据，且尽量提高空中接口的带宽利用率。

本发明提供了一种集群业务中进行头压缩配置的核心网子系统，该核心网子系统能够保证集群组中所有终端设备都接收下行数据，且尽量提高空中接口的带宽利用率。

一种集群业务中进行头压缩配置的方法，该方法包括：

接收终端建立网络连接后上报的集群信道头压缩支持能力；

根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；

进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给基站，以开启或关闭头压缩，进行数据下发。

一种集群业务中进行头压缩配置的系统，该系统包括终端、核心网子系统和基站；

所述终端，建立网络连接后，向所述核心网子系统上报自身的集群信道头压缩支持能力；

所述核心网子系统，根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给所述基站；

所述基站，接收来自所述核心网子系统的集群信道头压缩支持能力，按照集群信道头压缩支持能力开启或关闭头压缩，并将头压缩配置通知给本基站下该集群组中的所有在线终端，对集群组中所有在线终端进行数据下发。

一种集群业务中进行头压缩配置的核心网子系统，该核心网子系统包括接入连接管理模块和调度控制模块；

所述接入连接管理模块，接收终端建立网络连接后上报的集群信道头压缩支持能力，发送给所述调度控制模块；进行集群组呼建立时，从所述调度控制模块获取集群组的集群信道头压缩支持能力，发送给基站，以开启或关闭头压缩，进行数据下发；

所述调度控制模块，根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；并在进行集群组呼建立时根据请求为所述接入连接管理模块的提供集群组的集群信道头压缩支持能力。

从上述方案可以看出，本发明中，接收终端建立网络连接后上报的集群信道头压缩支持能力；根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给基站，而后，基站便可根据集群信道头压缩支持能力确定是否开启头压缩。这样，若集群组中都是高能力终端，则采用头压缩方式进行数据下发，若集群组中存在低能力终端，则不采用头压缩方式进行数据下发；从而，保证了集群组中所有终端设备都接收下行数据，且尽量提高了空中接口的带宽利用率。并且，本发明采用终端在与网络建立连接后、集群组呼建立之前，进行能力上报，上报动作发生在组呼业务之前，不影响呼叫建立时间。

附图说明

图1为本发明集群业务中进行头压缩配置的方法示意性流程图；

图2为本发明集群业务中进行头压缩配置的方法流程图实例；

图3为本发明集群业务中进行头压缩配置的系统结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明进一步详细说明。

本发明中，终端在与网络建立连接后进行集群信道头压缩支持能力的上报，核心网子系统根据终端的上报，确定集群组的集群信道头压缩支持能力，若集群组中都是高能力终端，则采用头压缩方式进行数据下发，若集群组中存在低能力终端，则不对所有终端采用头压缩方式进行数据下发；从而，保证了集群组中所有终端设备都接收下行数据，且尽量提高了空中接口的带宽利用率。

参见图1，为本发明集群业务中进行头压缩配置的方法示意性流程图，其包括以下步骤：

步骤101，接收终端建立网络连接后上报的集群信道头压缩支持能力。

终端建立网络连接后，向核心网子系统上报自身的集群信道头压缩支持能力；所述建立网络连接的情形如：开机、终端从无信号的区域移动到有信号覆盖的区域等。

终端上报自身的集群信道头压缩支持能力，可采用多种方式实现，可通过基站中转的方式上报给核心网子系统，也可直接上报给核心网子系统。下面进行实例说明：

方式一：终端建立网络连接后，在无线资源控制(RRC，RadioResourceControl)消息中携带自身的集群业务信道头压缩支持能力，上报给基站，基站将集群业务信道头压缩支持能力携带在S1消息中，上报给核心网子系统。所述RRC消息具体如终端能力信息(UECapabilityInformation)，所述S1消息具体如终端能力信息指示。

方式二：对于采用非接入层(NAS，Non-AccessStratum)协议的情形，终端在建立网络连接后，在非接入层(NAS，Non-AccessStratum)协议消息中携带自身的集群业务信道头压缩支持能力，上报给核心网子系统；所述NAS协议消息可以是已有NAS协议消息，也可以是新定义的NAS协议消息。

步骤102，根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持。

集群组的集群信道头压缩能力由该集群组内所有在线终端的支持能力确定，如果所有在线终端均支持，则确定该集群组的集群信道头压缩支持能力为支持；如果在线终端中有一个以上不支持，则确定该集群组的集群信道头压缩支持能力为不支持。

步骤103，进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给基站，以开启或关闭头压缩，进行数据下发。

将集群组的集群信道头压缩支持能力发送给基站，可采用多种方式实现，例如，在发给基站的呼叫建立消息中，携带集群组的集群信道头压缩支持能力。

基站接获知集群组的集群信道头压缩支持能力后，相应开启或关闭头压缩；具体地，如果为支持，则开启头压缩，采用头压缩方式进行数据下发；如果为不支持，则关闭头压缩，不采用头压缩方式进行数据下发。

基站根据呼叫建立消息中的集群信道头压缩支持能力，开启或关闭头压缩，并将头压缩配置通知给本基站下该集群组中的所有在线终端；基站对集群组中所有在线终端进行数据下发。

进一步地，还可根据集群组内终端的动态变化，对头压缩配置进行调整。下面分两种情形进行举例说明。

情形一、

进行集群组呼建立之前，该方法还包括：

监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；

用当前确定的该及群组的集群信道头压缩支持能力更新原集群信道头压缩支持能力。

情形二、

将集群组的集群信道头压缩支持能力发送给基站之后，该方法还包括：

监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；

用当前确定的该集群组的集群信道头压缩支持能力更新原集群信道头压缩支持能力；并在该集群组的集群信道头压缩支持能力发生变化、且该集群组正在进行组呼时，发送集群信道头压缩支持能力的改变指示给基站，以进行头压缩配置变更。

本发明中，接收终端建立网络连接后上报的集群信道头压缩支持能力；根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给基站，而后，基站便可根据集群信道头压缩支持能力确定是否开启头压缩。这样，若集群组中都是高能力终端，则采用头压缩方式进行数据下发，若集群组中同时存在高能力终端和低能力终端，则不采用头压缩方式进行数据下发；从而，保证了集群组中所有终端设备都接收下行数据，且尽量提高了空中接口的带宽利用率。并且，本发明采用终端在与网络建立连接后、集群组呼建立之前，进行能力上报，上报动作发生在组呼业务之前，不影响呼叫建立时间。

下面通过图2的流程，对本发明集群业务中进行头压缩配置的方法给予实例说明，其包括以下步骤：

步骤201，终端建立网络连接后在终端能力信息中携带自身的集群业务信道头压缩支持能力，上报给基站。

步骤202，基站将集群业务信道头压缩支持能力携带在终端能力信息指示中，上报给核心网子系统。

步骤203，核心网子系统根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持。

步骤204，核心网子系统监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持。

原不在线的终端变为在线，如终端开机，或者从无信号的区域移动到有信号覆盖的区域。原在线的终端变为不在线，如终端关机等。

核心网子系统检测到集群组内终端的在线情况发生变化，则采用步骤203的方案重新确定集群组当前的集群信道头压缩支持能力。

步骤205，核心网子系统用当前确定的集群信道头压缩支持能力更新原集群信道头压缩支持能力。

步骤204-205是非呼叫中的组能力改变情形。

步骤206，进行集群组呼建立时，核心网子系统在发给基站的呼叫建立消息中，携带集群组的集群信道头压缩支持能力。

步骤207，基站从呼叫建立消息中获知集群组的集群信道头压缩支持能力，如果为支持，则开启头压缩，并将头压缩配置通知给本基站下该集群组中的所有在线终端，采用头压缩方式进行数据下发；如果为不支持，则关闭头压缩，并将头压缩配置通知给本基站下该集群组中的所有在线终端，不采用头压缩方式进行数据下发。

步骤208，核心网子系统监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持。

核心网子系统检测到集群组内终端的在线情况发生变化，则采用步骤203的方案重新确定集群组当前的集群信道头压缩支持能力。

步骤209，核心网子系统用当前确定的该集群组的集群信道头压缩支持能力更新原集群信道头压缩支持能力；并在该集群组的集群信道头压缩支持能力发生变化、且该集群组正在进行组呼时，发送集群信道头压缩支持能力的改变指示给基站。

如果该集群组的集群信道头压缩支持能力发生变化，核心网子系统还向基站发送改变指示。

步骤210，基站接收改变指示后，对头压缩配置进行变更，并将头压缩配置变更通知给本基站下该集群组中的所有在线终端，采用变更后的方式进行数据下发。

步骤208-210为呼叫中的组能力改变，包括两种情形：

a、如果核心网子系统根据上述步骤203的判断原则，判断某集群组的头压缩属性从“支持集群信道头压缩”变为“不支持集群信道头压缩”，且该组正在进行组呼，则核心网子系统应将该属性改变通知基站，基站应将集群业务信道的数据压缩方式从使用头压缩变为不使用头压缩，并将该头压缩配置改变通知该组的终端。

b、如果核心网子系统根据上述步骤203的判断原则，判断某集群组的头压缩属性从“不支持集群信道头压缩”变为“支持集群信道头压缩”，且该组正在进行组呼，则核心网子系统应将该属性改变通知基站，基站应将集群业务信道的数据压缩方式从不使用头压缩变为使用头压缩，并将该头压缩配置改变通知该组的终端。

由于支持集群信道头压缩的终端也可以接收不压缩的数据，因此，对于上述b情形，核心网子系统可不将该属性改变通知基站；基站可不改变下行数据的头压缩配置。

下面具体以时分长期演进(TD-LTE，TimeDivision-LongTermEvolution)集群业务为例，对本发明进行头压缩配置的方法作进一步说明。

假定集群组A包含3个UE，分别为UE1、UE2和UE3，其中，UE1、UE2支持集群业务信道(TTCH，TrunkingTrafficChannel)的分组数据汇聚协议(PDCP，PacketDataConvergenceProtocol)头压缩，UE3不支持TTCH的PDCP头压缩。

场景1：【UE能力上报、非呼叫中的组能力改变】

1.1UE1开机执行附着(Attach)过程后，将“支持TTCH的PDCP头压缩”能力上报给核心网。

本实例中的上报方式为，Attach过程后UE1触发基站(eNodeB)发起终端能力传输(UECapabilityTransfer)过程，UE1在终端能力信息(UECapabilityInformation)中将能力进行上报，eNodeB在终端能力信息指示(UECapabilityInfoIndication)中将该能力上报给核心网子系统。

3GPP定义的UECapabilityInformation结构如下所示，其中包含UE-CapabilityRAT-ContainerList信元。该信元的结构中包含子信元ueCapabilityRAT-Container，格式为OCTETSTRING，可以在此子信元中携带UE支持集群业务信道头压缩的能力。

上述UECapabilityInformation结构中，标有下划线的部分指示出了其包含的UE-CapabilityRAT-ContainerList信元。下面给出UE-CapabilityRAT-ContainerList信元的结构：

上述UE-CapabilityRAT-ContainerList信元的结构中，标有下划线的部分指示出了其中的ueCapabilityRAT-Container子信元，其格式为OCTETSTRING，可以在此子信元中携带UE支持集群业务信道头压缩的能力。

当然地，上述UECapabilityInformation结构只是一个实例，并不仅限于此。

1.2核心网子系统根据判断原则，集群组A中在线的UE(仅有UE1)支持TTCH的PDCP头压缩，所以集群组A的属性为“支持TTCH的PDCP头压缩”。

1.3UE2开机，按照步骤1.1的方法将“支持TTCH的PDCP头压缩”能力上报给核心网子系统。

1.4核心网子系统根据判断原则，集群组A中在线的UE(UE1、UE2)均支持TTCH的PDCP头压缩，所以集群组A的属性仍保持为“支持TTCH的PDCP头压缩”。

场景2：【呼叫建立】

2.1UE1、UE2均已开机，集群组A的属性为“支持TTCH的PDCP头压缩”。

2.2UE1对集群组A发起组呼建立。

2.3核心网子系统指示eNodeB建立组呼资源，并指示集群组A的属性为“支持TTCH的PDCP头压缩”。

2.4eNodeB建立组呼后，向集群组A发广播，指示本次呼叫使用PDCP头压缩。

2.5eNodeB启用TTCH的PDCP头压缩，UE1、UE2启用TTCH的PDCP头解压缩。

场景3：【呼叫中的集群能力改变】

3.1UE1、UE2均已开机，UE1已对集群组A发起组呼建立，eNodeB已启用TTCH的PDCP头压缩。

3.2UE3开机，按照步骤1.1的方法将“不支持TTCH的PDCP头压缩”能力上报给核心网子系统。

3.3核心网子系统根据判断原则，集群组A中在线的UE(UE1、UE2、UE3)存在不支持TTCH的PDCP头压缩的UE(UE3)，所以集群组A的属性更改为“不支持TTCH的PDCP头压缩”。

3.4核心网子系统应将集群组A的属性改变指示eNodeB。

其中一种可能的指示方式为，核心网子系统发S1消息指示eNodeB修改已建立的集群呼上下文，在该S1消息中携带集群组A的属性为“不支持TTCH的PDCP头压缩”。

3.5eNodeB收到上述S1消息，关闭TCCH的PDCP头压缩，并向集群组A发广播，指示本次呼叫不使用PDCP头压缩。

3.6UE1、UE2、UE3使用非压缩模式接收TTCH数据。

参见图3，为本发明集群业务中进行头压缩配置的系统结构示意图，该系统包括终端、核心网子系统子系统和基站；

所述终端，建立网络连接后，向所述核心网子系统子系统上报自身的集群信道头压缩支持能力；

所述核心网子系统子系统，根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给所述基站；

所述基站，接收来自所述核心网子系统的集群信道头压缩支持能力，按照集群信道头压缩支持能力开启或关闭头压缩，并将头压缩配置通知给本基站下该集群组中的所有在线终端，对集群组中所有在线终端进行数据下发。

较佳地，所述核心网子系统子系统包括接入连接管理模块和调度控制模块；

所述接入连接管理模块，接收终端建立网络连接后上报的集群信道头压缩支持能力，发送给所述调度控制模块；进行集群组呼建立时，从所述调度控制模块获取集群组的集群信道头压缩支持能力，发送给所述基站；

所述调度控制模块，根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；并根据请求为所述接入连接管理模块的提供集群组的集群信道头压缩支持能力。

较佳地，所述调度控制模块包括第一能力变更单元，在进行集群组呼建立之前，监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；用当前确定的集群信道头压缩支持能力更新原集群信道头压缩支持能力。

较佳地，所述调度控制模块包括第二能力变更单元和变更指示单元；

所述第二能力变单元，在根据请求为所述接入连接管理模块的提供集群组的集群信道头压缩支持能力之后，监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；用当前确定的该集群组的集群信道头压缩支持能力更新原集群信道头压缩支持能力，并在该集群组的集群信道头压缩支持能力发生变化、且该集群组正在进行组呼时向所述变更指示单元发送启动指令；

所述变更指示单元，接收来自所述第二能力变更单元的启动指令，发送集群信道头压缩支持能力的改变指示给所述接入连接管理模块；

所述接入连接管理模块，还接收来自所述变更指示单元的集群信道头压缩支持能力的改变指示，发送给基站，以进行头压缩配置变更。

采用本发明方案，系统能够根据集群组中在线终端的集群信道头压缩支持能力，自适应地开启和关闭头压缩，在保证所有终端都收听组呼的前提下，尽可能地提高了数据传输效率。

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

Claims (10)

1.一种集群业务中进行头压缩配置的方法，其特征在于，该方法包括：

接收终端建立网络连接后上报的集群信道头压缩支持能力；

根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；

进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给基站，以开启或关闭头压缩，进行数据下发。

2.如权利要求1所述的方法，其特征在于，所述终端上报集群业务信道头压缩支持能力包括：

终端在无线资源控制RRC消息中携带自身的集群业务信道头压缩支持能力，上报给基站，基站将集群业务信道头压缩支持能力携带在S1消息中，上报给核心网子系统；或者，

终端在非接入层NAS协议消息中携带自身的集群业务信道头压缩支持能力，上报给核心网子系统，所述NAS协议消息为已有NAS协议消息或新定义的NAS协议消息。

3.如权利要求1所述的方法，其特征在于，所述将集群组的集群信道头压缩支持能力发送给基站，以开启或关闭头压缩，进行数据下发包括：

在发给基站的呼叫建立消息中，携带集群组的集群信道头压缩支持能力；

基站根据呼叫建立消息中的集群信道头压缩支持能力，开启或关闭头压缩，并将头压缩配置通知给本基站下该集群组中的所有在线终端；

基站对集群组中所有在线终端进行数据下发。

4.如权利要求1所述的方法，其特征在于，进行集群组呼建立之前，该方法还包括：

监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；

用当前确定的集群信道头压缩支持能力更新原集群信道头压缩支持能力。

5.如权利要求1至4中任一项所述的方法，其特征在于，所述将集群组的集群信道头压缩支持能力发送给基站之后，该方法还包括：

监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；

用当前确定的该集群组的集群信道头压缩支持能力更新原集群信道头压缩支持能力；并在该集群组的集群信道头压缩支持能力发生变化、且该集群组正在进行组呼时，发送集群信道头压缩支持能力的改变指示给基站，以进行头压缩配置变更。

6.一种集群业务中进行头压缩配置的系统，其特征在于，该系统包括终端、核心网子系统和基站；

所述终端，建立网络连接后，向所述核心网子系统上报自身的集群信道头压缩支持能力；

所述核心网子系统，根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；进行集群组呼建立时，将集群组的集群信道头压缩支持能力发送给所述基站；

所述基站，接收来自所述核心网子系统的集群信道头压缩支持能力，按照集群信道头压缩支持能力开启或关闭头压缩，并将头压缩配置通知给本基站下该集群组中的所有在线终端，对集群组中所有在线终端进行数据下发。

7.如权利要求6所述的系统，其特征在于，所述核心网子系统包括接入连接管理模块和调度控制模块；

所述接入连接管理模块，接收终端建立网络连接后上报的集群信道头压缩支持能力，发送给所述调度控制模块；进行集群组呼建立时，从所述调度控制模块获取集群组的集群信道头压缩支持能力，发送给所述基站；

所述调度控制模块，根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；并根据请求为所述接入连接管理模块的提供集群组的集群信道头压缩支持能力。

8.一种集群业务中进行头压缩配置的核心网子系统，其特征在于，该核心网子系统包括接入连接管理模块和调度控制模块；

所述接入连接管理模块，接收终端建立网络连接后上报的集群信道头压缩支持能力，发送给所述调度控制模块；进行集群组呼建立时，从所述调度控制模块获取集群组的集群信道头压缩支持能力，发送给基站，以开启或关闭头压缩，进行数据下发；

所述调度控制模块，根据终端的上报，判断集群组中的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；并在进行集群组呼建立时根据请求为所述接入连接管理模块的提供集群组的集群信道头压缩支持能力。

9.如权利要求8所述的核心网子系统，其特征在于，所述调度控制模块包括第一能力变更单元，在进行集群组呼建立之前，监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；用当前确定的集群信道头压缩支持能力更新原集群信道头压缩支持能力。

10.如权利要求8或9所述的核心网子系统，其特征在于，所述调度控制模块包括第二能力变更单元和变更指示单元；

所述第二能力变单元，在根据请求为所述接入连接管理模块的提供集群组的集群信道头压缩支持能力之后，监测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；用当前确定的该集群组的集群信道头压缩支持能力更新原集群信道头压缩支持能力，并在该集群组的集群信道头压缩支持能力发生变化、且该集群组正在进行组呼时向所述变更指示单元发送启动指令；

所述变更指示单元，接收来自所述第二能力变更单元的启动指令，发送集群信道头压缩支持能力的改变指示给所述接入连接管理模块；

所述接入连接管理模块，还接收来自所述变更指示单元的集群信道头压缩支持能力的改变指示，发送给基站，以进行头压缩配置变更。