高效PDT 终端定位数据上报方法

2021-09-06 12:30伦立宝赵志强许聪聪李怀禄
吉林大学学报(信息科学版) 2021年4期
关键词:短消息信令信道

伦立宝 赵志强 许聪聪 李怀禄

(河北远东通信系统工程有限公司产品与解决方案中心,石家庄 050200)

0 引 言

PDT(Professional Digital Trunking)标准是具有中国自主知识产权的数字集群通信标准,中国公安部倡导的数字集群技术体制,可满足公安等关键领域用户对高效、专业无线调度指挥业务的迫切需求[1-3]。随着专网无线通信的快速发展,PDT 标准应用于越来越多的行业,其终端也越来越智能化[4-6]。在满足语音、短信等基本业务的同时,终端实时上报定位信息到指挥调度中心也成为比较迫切的应用需求。终端的实时定位使指挥调度业务更加丰富和高效。

标准协议定义了3 种定位数据上报方法,分别为GPS(Global Positioning System)单次上拉、专用数据信道上拉、终端在数据信道主动上报定位数据[7]。现实使用过程中,当指挥调度中心需要实时监控系统内各个终端的位置信息时,所有终端需在指定的较短时间内周期上报定位数据。然而受限于窄带无线系统的数据接入和传输能力[8],PDT 标准协议定义的3 种定位数据上报方法并不能很好地满足要求。因此为对标准业务进行扩展,笔者设计了一种基于组呼文本短消息上拉与专用数据信道上报相结合的方法,实现终端定位数据高效上报。

1 核心问题

GPS 单次上拉,授权的有线调度终端向系统发送上拉请求,系统按照请求向目标终端下发上拉指令,目标终端通过控制信道将定位数据以短消息的方式进行上报。在该方法业务处理过程中,所有信令均在控制信道发射,当指挥调度中心需要实时监控终端的位置信息时,其需要周期性地发起上拉业务,整个上拉过程严重占用控制信道,极大概率导致系统下语音呼叫业务失败,影响系统和终端的正常使用。每次上报定位数据需要完整的上拉流程,以短消息的方式上报定位数据,终端每次上报最少需要发送C_UDTHU 和C_UDTHD[9-10]两条信令,业务整体上报效率较低。

专用数据信道上拉,授权的有线调度终端向系统订阅目标终端定位数据及上拉周期,订阅成功后,系统按照上拉周期要求自动周期性地向目标终端下发上拉指令,上拉目标终端定位数据,直至授权终端取消订阅才停止周期性上拉。周期性定位上拉指令在专用数据信道下发,该信道位于与控制信道相同载频的另一个时隙。目标终端收到上拉指令后通过专用数据信道上报定位数据。在该方法业务处理过程中,50%的信令在控制信道发射,整个上拉过程控制信道占用率较高,较大概率导致系统下语音呼叫业务失败,影响系统和终端的正常使用。每次上报定位数据需要完整的上拉流程,业务整体上报效率较低。

数据信道终端主动上报定位数据,该定位数据上报是移动台根据系统配置信息在指定数据信道上报终端当前所处的位置信息的方法,根据触发方式,可分为按时间、距离、时间距离相结合3 种上报方式。授权的有线终端可以通过系统修改相关配置信息对终端的定位数据上报进行控制。该方法终端在业务信道进行上报,如果直接采用周期上报的方式,当终端数量较大时,会出现大量终端在同一时隙上报定位数据的情况,PDT 系统会在极短的时间内收到大量消息。这些消息同时抵达会形成射频消息串扰,给PDT 系统造成RFID(Radio Frequency Identification)碰撞问题,导致系统无法正常接收到所有终端的定位数据。终端上报过程一直处于业务信道,无法进行语音呼叫业务。

标准协议定义的以上3 种定位数据上报方法主要存在控制信道占用率高、上报效率低、影响语音呼叫业务和RFID 碰撞4 个核心问题。在终端数量大、上报周期短的情况下这4 个问题表现尤为明显。

2 关键技术

2.1 组呼文本短消息上拉技术

PDT 标准中定义了2 种文本短消息业务,个呼文本短消息和组呼文本短消息。组呼文本短消息业务中接收方为组号码,授权的调度终端发起组呼文本短消息业务后,在该组内的所有终端均可收到该条短消息。系统下发的短消息信令主要包括C_UDTHD 和C_UDTDD,其中C_UDTDD 信令用于承载短消息数据。当采用二进制数据进行存储时,每个作为中间帧的C_UDTDD 信令最多可携带96 比特数据,每个作为结束帧的C_UDTDD 信令最多可以携带79 比特数据,一条短消息最多可以携带4 个C_UDTDD 信令,因此一条短消息最多可以携带367 比特数据。

为解决控制信道占用率高、上报效率低和RFID 碰撞问题,PDT 系统将所有需要上报定位数据的终端归属到同一组,然后按照一定规则进行排序,将排序后的终端号码按顺序封装到C_UDTDD 信令中,同时将终端总个数以及当前短消息序号封装到C_UDTDD 信令中。利用组呼文本短消息业务,将所有需要上报的终端号码、终端总个数和当前短消息序号信息发送给组内所有终端。需要上报定位数据的终端接收完组呼文本短消息后,对短消息内容进行解析,然后根据自己的上报顺序依次上报。通过组呼文本短消息上拉,可以有效地解决单独对每个终端上拉造成的控制信道占用率高的问题,提高上拉效率,降低对语音呼叫业务的影响。终端根据上报顺序依次上报,可以有效地避免RFID碰撞的发生。

2.2 专用数据信道上报

在标准协议定义的专用数据信道上拉业务中,目标终端收到上拉指令后通过专用数据信道上报定位数据,上报完成后返回控制信道。目标终端上报采用C_GPS3U 信令携带定位数据,每次上报只需发送一条C_GPS3U 信令,终端上报过程效率较高。终端通过专用数据信道上报定位数据,不会影响控制信道和业务信道语音呼叫业务的进行。因此在设计终端定位数据上报方法时,可选择在专用数据信道进行上报。

3 定位数据上报方法设计

笔者提出了一种基于组呼文本短消息上拉与专用数据信道上报相结合的定位数据上报方法。该方法通过组呼文本短消息上拉,对终端进行排序,使终端按照顺序依次在专用数据信道上报。

3.1 组呼文本短消息封装

PDT 系统接收到有线调度终端上拉请求后,对目标终端按照规则进行排序,然后封装成定位数据上拉组呼文本短消息,主要流程如图1 所示。

图1 PDT 系统封装定位数据上拉组呼文本短消息流程Fig.1 The process of encapsulating pull-up group text message for positioning data

定位数据上报业务的发起者为有线调度终端。有线调度终端与PDT 系统对定位数据上报业务请求指令及携带数据的格式进行定义。PDT 系统接收调度终端的请求指令然后进行解析,如果请求指令为定位数据上拉指令,则请求指令携带的数据为目标用户群组号码。PDT 系统将目标用户群组内所有在线终端作为目标终端,并获取目标终端总个数。一条短消息最多可携带4 个C_UDTDD 信令,最多可携带367 比特数据。在进行封装时,首先设定每条短消息中用于标识目标终端总个数的字段所占用的比特长度,目标终端总个数可根据业务场景实际需要进行设定。然后依据每条短消息的容量,计算所需的短消息的总条数,根据短消息的总条数设定每条短消息中用于标识短消息序号的字段所占用的比特长度。最后按照一定规则将所有目标终端进行排序,根据所得的短消息总条数,以及每条短消息的容量,将序列分成相应数量的分段,分段和短消息按顺序一一对应,将分段后每个分段内的终端号码按序依次封装到对应的短消息的C_UDTDD 信令中。

3.2 组呼文本短消息接收与解析

PDT 系统在下发定位上拉组呼文本短消息前,会通过广播的方式向目标终端发送上拉通知指令。通过该指令,PDT 系统通知目标终端开始准备接收上拉组呼文本短消息。终端接收到该指令后,开始接收上拉组呼文本短消息并进行解析,主要流程如图2 所示。

图2 终端接收并解析上拉组呼文本短消息流程Fig.2 The process of receiving and parsing pull-up group text message

1) 终端首先接收第1 条短消息的C_UDTHD 信令和C_UDTDD 信令并进行解析,判断终端所在用户群组的组地址与C_UDTHD 信令中的是否一致,若是,则继续接收C_UDTDD 信令并进行解析,获取定位数据上拉组呼文本短消息携带的目标终端总个数、当前短消息序号和短消息内每个终端的号码等信息。终端对C_UDTDD 信令进行解析时,用于标识目标终端总个数的字段所占用的比特长度和用于标识短消息序号的字段所占用的比特长度与PDT 系统保持一致,根据业务场景实际需求进行提前设定。

2) 终端解析出目标终端总个数后,采用与PDT 系统相同的方式计算定位数据上拉组呼文本短消息的条数,然后将当前收到的短消息序号与短消息总条数进行比较,判断当前接收到的短消息是否为最后一条,若不是,则继续接收短消息,否则,开始对接收到的所有短消息进行解析。

3) 终端将接收到的所有短消息中携带的目标终端号码进行排序,然后根据自己在序列中的位置,计算本终端上报数据所需等待的时间,等待时间以PDT 标准中的时隙为单位。

3.3 总体流程设计

笔者提出的上报方法依赖于有线调度终端、PDT 系统和终端的紧密配合,是在PDT 标准业务的基础上进行的扩展。该方法的总体流程图如图3 所示。

图3 卫星定位数据上报方法总体流程图Fig.3 The process of positioning data reporting method

1) 有线调度终端选择目标用户群组,然后向PDT 系统发起定位数据上拉请求。目标用户群组至少包括一个用户终端为目标终端,各用户群组均具有唯一的组号码和组地址,其终端均具有唯一的个人号码和个人地址。

2) PDT 系统接收到有线调度终端发出的上拉请求后,对上拉请求进行解析,然后按照3.1 节所述方法封装上拉所需组呼文本短消息。

3) PDT 系统通过自定义广播的方式向目标终端下发定位数据上拉指令,通知目标终端准备接收定位数据上拉组呼文本短消息,并准备定位数据。定位数据上拉指令中携带目标用户地址,即目标用户群组的组号码。目标终端接收到上拉指令后,开始准备接收定位数据上拉组呼文本短消息。

4) PDT 系统向目标终端下发定位数据上拉组呼文本短消息,若定位数据上拉组呼文本短消息有多条,则按顺序依次下发。

5) 目标终端收到定位数据上拉组呼文本短消息后,按照3.2 节所述方法对短消息进行解析,计算本终端上报数据所需等待的时间并开启定时器。

6) 终端根据定时器判断何时进行上报,当开始上报时,切换到专用数据信道,上报完成后,再次切换到控制信道。

7) PDT 系统收到目标终端上报的定位数据后,对定位数据进行解析,将经度、纬度和目标终端个人号码发送给有线调度终端,有线调度终端对定位数据进行存储和显示。

4 测试验证及结果分析

为测试本方法的实际应用性能,进行如下测试验证工作。

1) 上报效率和RFID 碰撞验证。试验环境中,共准备100 部终端,终端号码为80020200~80020299,组号码为80020910,所有终端均在80020910 组中。分别对10、30、50、80、100 部终端进行单次上拉试验,实验过程中系统无语音呼叫业务,在有线调度终端上对终端上报情况进行记录显示。实验结果如表1 所示。

表1 终端上报效率和成功率实验结果Tab.1 The experimental results of the terminal reporting efficiency and success rate

从表1 可以看出,在无语音呼叫业务的情况下,终端能实现高效的位置上报,上报成功率为100%。

2) 对语音呼叫业务的影响。为验证上报方法对语音呼叫业务的影响,选取了50 部终端,终端号码为80020200~80020249。对终端进行上拉试验,有线调度终端配置上拉周期为15 s。在上拉过程的不同时间阶段进行语音组呼呼叫业务,呼叫总时长设置为3 s 。试验结果如表2 所示。

表2 上报方法对语音呼叫业务的影响试验结果Tab.2 The influence of reporting method on voice call service

在PDT 系统中,语音呼叫优先级高于位置上报业务。在上拉业务开始前和系统下发上拉请求过程中发起语音呼叫,PDT 系统会优先处理呼叫业务,待呼叫结束后再继续下发上拉请求,从而保证了终端能正确接收上拉请求并完成位置上报。在终端按序上报定位数据过程,如果终端正在专用信道进行位置上报,当有呼叫业务时,不能及时加入呼叫。终端完成位置上报返回控制信道后,会通过迟后加入的方式进入呼叫。若终端在等待上报过程接收到语音呼叫业务,能直接加入到呼叫中。终端在呼叫结束后计算当前是否已经错过上报时机,若错过,则等待下次上拉请求,否则继续等待上报时机进行位置上报。

从实验结果可以看出,上报方法不会影响语音呼叫业务的正常进行。同时,由于上报方法采取周期上拉的方式,语音呼叫过程会影响上报结果,呼叫结束后,上报业务会在下一个上拉周期恢复正常,从而保证了上拉业务的持续进行。

5 结 语

笔者提出的PDT 终端定位数据上报方法,充分利用了组呼文本短消息的数据承载能力。通过组呼文本短消息上拉和专用数据信道上报相结合,解决了现有标准上报业务存在的控制信道占用率高、上报效率低、影响语音呼叫业务和RFID 碰撞等核心问题,实现了高效、稳定的数据上报,为实现终端位置实时监控提供重要保障。

猜你喜欢
短消息信令信道
基于自适应学习的5G通信系统信道估计方法
信号/数据处理数字信道接收机中同时双信道选择与处理方法
基于北斗通信终端的数据转发控制器设计
一种基于向量回归的无人机通信信道选择方法
网内信令链路负荷分担不均原因研究
浅谈JSQ-31 V5数字程控用户交换机NO.7及NO.1信令参数设定及不同
WLAN和LTE交通规则
移动网短消息业务流程及案例分析
小灵通里的父爱