[发明专利]列车组呼实现方法及装置

说明书

本发明公开了一种列车组呼实现方法及装置，该方法包括：根据铁路上的列车顺序信息确定组成员，并将所有组成员设置为调度员，其中，每个组成员对应一辆列车；由主叫的组成员按预定格式向其他组成员发起组呼，其中，主叫的组成员能够跨不同的组呼区进行呼叫。采用本发明能够解决相关技术中通话过程中容易掉话、每次通话需要申请上行链路且通话信息容易被其他用户窃听的问题。

技术领域

本发明涉及通信领域，具体而言，涉及一种列车组呼实现方法及装置。

背景技术

组呼(VGCS)是3GPP标准组织定义的一种集群业务。一个组呼的参与用户(称为组成员，Group Member)分为两类角色：数目不等的‘业务用户’(Service subscriber)和最多5个(或者15个)‘调度员’(Dispatcher)。业务用户只能在‘组呼区’参与组呼。组呼区由至少一个或者若干个小区(可以跨BSC(Base Station Controller，基站控制器)甚至跨MSC(Message Switching Center，信息交换中心))组成。调度员的位置则不受任何限制。

按照3GPP43.068协议，组呼中的业务用户是‘动态’的：对于签约该组标识ID的业务用户，组呼中的业务用户离开组呼区则离开组呼；组呼区之外的业务用户进入组呼区则可以加入组呼。而调度员则是‘静态’的，一旦在组呼数据库(GCR)中配置，则一直不变。

相邻三列列车司机的组呼的要求是：对于一列运营列车，其列车司机发起组呼，同时呼叫前面一辆列车和后面一辆列车的司机。

由于列车的前后列车不会永远固定，所以此组呼的三个司机属于‘动态’的，不宜在GCR数据库中做成静态配置。

如前所述，普通VGCS组呼只能通过‘业务用户’实现动态组呼，在实现相邻三列列车司机的组呼时，普通VGCS组呼具有如下缺陷：

1.将三个司机都作为‘业务用户’角色时，MSC/GCR需要实时获取相邻三列列车的全球小区(Cell)，设置为组呼区。即通过‘动态组呼区’实现，这点就很难；

2.由于列车高速运行，以及三个小区未必连续，各个司机(作为‘业务用户’角色)很容易掉话；

3.由于都是‘业务用户’角色，每次讲话都需要抢占上行信道，用户使用不方便；

上述缺陷会带来如下后果：

1.容易掉话，列车越快，掉话越快；

2.使用不方便，每次讲话需要申请上行链路；

3.由于下行广播，通话信息容易被其他无关用户偷听。

针对相关技术中通话过程中容易掉话、每次通话需要申请上行链路且通话信息容易被其他用户窃听的问题，目前尚未提出有效的解决方案。

发明内容

本发明的主要目的在于提供一种列车组呼实现方法及装置，以至少解决上述相关技术中通话过程中容易掉话、每次通话需要申请上行链路且通话信息容易被其他用户窃听的问题。

根据本发明的一个方面，提供了一种列车组呼实现方法，包括：根据铁路上的列车顺序信息确定组成员，并将所有组成员设置为调度员，其中，每个组成员对应一辆列车；由主叫的组成员按预定格式向其他组成员发起组呼，其中，所述主叫的组成员能够跨不同的组呼区进行呼叫。

优选的，所述铁路上的列车顺序信息的获取方式包括下列至少之一：从无线闭塞中心RBC获取；从列车控制中心获取；从OMC输入。

优选的，所述铁路上的列车顺序信息的获取方式为从RBC获取时，若铁路上任意一个方向列车的顺序发生变化，所述RBC将更新的列车顺序信息同步到GCR组呼数据库。