集群 业务为例，对本发明进行头压缩配置的方法作进一步说明。
[0068] 假定集群组A包含3个UE，分别为UE1、UE2和UE3,其中，UE1、UE2支持集群业 务信道（TTCH，Trunking Traffic Channel)的分组数据汇聚协议（F1DCP, Packet Data Convergence Protocol)头压缩，UE3 不支持 TTCH 的]3DCP 头压缩。
[0069] 场景I :【UE能力上报、非呼叫中的组能力改变】
[0070] I. IUEl开机执行附着（Attach)过程后，将"支持TTCH的PDCP头压缩"能力上报给 核心网。
[0071] 本实例中的上报方式为，Attach过程后UEl触发基站（eNodeB)发起终端能力传 输（UE Capability Transfer)过程，UEl 在终端能力信息（UE Capability Information) 中将能力进行上报，eNodeB在终端能力信息指示（UE Capability Info Indication)中将 该能力上报给核心网子系统。
[0072] 3GPP定义的UE Capability Information结构如下所不，其中包 含UE-CapabilityRAT-ContainerList信元。该信元的结构中包含子信元 ueCapabilityRAT-Container，格式为OCTET STRING，可以在此子信元中携带UE支持集 群业务信道头压缩的能力。
[0074]
[0075] 上述UE Capability Information结构中，标有下划线的部分指示出了其包含的 UE-CapabilityRAT-ContainerList 信兀。下面给出 UE-CapabilityRAT-ContainerList 信 元的结构：
[0077] 上述UE-CapabilityRAT-ContainerList信元的结构中，标有下划线的部分指示 出了其中的UeCapabilityRAT-Container子信元，其格式为OCTET STRING，可以在此子信 元中携带UE支持集群业务信道头压缩的能力。
[0078] 当然地，上述UE Capability Information结构只是一个实例，并不仅限于此。
[0079] 1. 2核心网子系统根据判断原则，集群组A中在线的UE(仅有UE1)支持TTCH的 rocp头压缩，所以集群组A的属性为"支持itch的rocp头压缩"。
[0080] I. 3UE2开机，按照步骤I. 1的方法将"支持TTCH的rocp头压缩"能力上报给核心 网子系统。
[0081] 1. 4核心网子系统根据判断原则，集群组A中在线的UE (UE1、UE2)均支持TTCH的 rocp头压缩，所以集群组A的属性仍保持为"支持TTCH的rocp头压缩"。
[0082] 场景2:【呼叫建立】
[0083] 2. IUEl、UE2均已开机，集群组A的属性为"支持TTCH的HXP头压缩"。
[0084] 2. 2UE1对集群组A发起组呼建立。
[0085] 2. 3核心网子系统指示eNodeB建立组呼资源，并指示集群组A的属性为"支持 TTCH的PDCP头压缩"。
[0086] 2. 4eNodeB建立组呼后，向集群组A发广播，指示本次呼叫使用HXP头压缩。
[0087] 2. 5eNodeB 启用 TTCH 的 PDCP 头压缩，UEl、UE2 启用 TTCH 的 PDCP 头解压缩。
[0088] 场景3 :【呼叫中的集群能力改变】
[0089] 3. IUEl、UE2均已开机，UEl已对集群组A发起组呼建立，eNodeB已启用TTCH的 PDCP头压缩。
[0090] 3. 2UE3开机，按照步骤L 1的方法将"不支持TTCH的rocp头压缩"能力上报给核 心网子系统。
[0091] 3. 3核心网子系统根据判断原则，集群组A中在线的UE (UE1、UE2、UE3)存在不支 持TTCH的rocp头压缩的UE (UE3)，所以集群组A的属性更改为"不支持TTCH的rocp头压 缩"。
[0092] 3. 4核心网子系统应将集群组A的属性改变指示eNodeB。
[0093] 其中一种可能的指示方式为，核心网子系统发SI消息指示eNodeB修改已建立的 集群呼上下文，在该Sl消息中携带集群组A的属性为"不支持TTCH的HXP头压缩"。
[0094] 3. 5eNodeB收到上述Sl消息，关闭TCCH的HXP头压缩，并向集群组A发广播，指 示本次呼叫不使用rocp头压缩。
[0095] 3. 6UE1、UE2、UE3使用非压缩模式接收TTCH数据。
[0096] 参见图3,为本发明集群业务中进行头压缩配置的系统结构示意图，该系统包括终 端、核心网子系统子系统和基站；
[0097] 所述终端，建立网络连接后，向所述核心网子系统子系统上报自身的集群信道头 压缩支持能力；
[0098] 所述核心网子系统子系统，根据终端的上报，判断集群组中的所有在线终端是否 均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否 贝1J，确定该集群组的集群信道头压缩支持能力为不支持；进行集群组呼建立时，将集群组的 集群信道头压缩支持能力发送给所述基站；
[0099] 所述基站，接收来自所述核心网子系统的集群信道头压缩支持能力，按照集群信 道头压缩支持能力开启或关闭头压缩，并将头压缩配置通知给本基站下该集群组中的所有 在线终端，对集群组中所有在线终端进行数据下发。
[0100] 较佳地，所述核心网子系统子系统包括接入连接管理模块和调度控制模块；
[0101] 所述接入连接管理模块，接收终端建立网络连接后上报的集群信道头压缩支持能 力，发送给所述调度控制模块；进行集群组呼建立时，从所述调度控制模块获取集群组的集 群信道头压缩支持能力，发送给所述基站；
[0102] 所述调度控制模块，根据终端的上报，判断集群组中的所有在线终端是否均支持 集群信道头压缩，如果是，则确定该集群组的集群信道头压缩支持能力为支持；否则，确定 该集群组的集群信道头压缩支持能力为不支持；并根据请求为所述接入连接管理模块的提 供集群组的集群信道头压缩支持能力。
[0103] 较佳地，所述调度控制模块包括第一能力变更单元，在进行集群组呼建立之前，监 测到集群组内原不在线的终端变为在线或原在线的终端变为不在线，则判断集群组中当前 的所有在线终端是否均支持集群信道头压缩，如果是，则确定该集群组的集群信道头压缩 支持能力为支持；否则，确定该集群组的集群信道头压缩支持能力为不支持；用当前确定 的集群信道头压缩支持能力更新原集群信道头压缩支持能力。
[0104] 较佳地，所述调度控制模块包括第二能力变更单元和变更指示单元；
[0105] 所述第二能力变单元，在根据请求为所述接入连接管理模块的提供集群组的集群 信道头压缩支持能力之后，监测到集群组内原不在线的终端变为在线或原在线的终端变为 不在线，则判断集群组中当前的所有在线终端是否均支持集群信道头压缩，如果是，则确定 该集群组的集群信道头压缩支持能力为支持；否则，确定该集群组的集群信道头压缩支持 能力为不支持；用当前确定的该集群组的集群信道头压缩支持能力更新原集群信道头压缩 支持能力，并在该集群组的集群信道头压缩支持能力发生变化、且该集群组正在进行组呼 时向所述变更指示单元发送启动指令；
[0106] 所述变更指示单元，接收来自所述第二能力变更单元的启动