CN104967570A - 一种智能北斗路由器 - Google Patents
一种智能北斗路由器 Download PDFInfo
- Publication number
- CN104967570A CN104967570A CN201510409282.5A CN201510409282A CN104967570A CN 104967570 A CN104967570 A CN 104967570A CN 201510409282 A CN201510409282 A CN 201510409282A CN 104967570 A CN104967570 A CN 104967570A
- Authority
- CN
- China
- Prior art keywords
- message
- data
- transmitting terminal
- receiving terminal
- packetized data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明涉及一种智能北斗路由器,包括能与北斗卫星进行数据通信的北斗收发模块;其特征在于:还包括与北斗收发模块连接的中心控制模块,与中心控制模块连接的至少能支持AP模式WIFI模块和局域网模块,局域网模块提供有LAN接口,其中中心控制模块能完成长度超过北斗收发模块能发送的短报文长度的长报文的发送和接收。与现有技术相比,本发明的优点在于:实现北斗信号与WIFI信号之间的转换,允许多个用户设备(比如智能手机)通过WIFI同时进行连接,还能完成长度超过北斗收发模块能发送的短报文长度的长报文的发送和接收。
Description
技术领域
本发明涉及一种智能北斗路由器。
背景技术
北斗卫星导航定位系统是中国自行研制的全球卫星导航系统,相比与其它卫星导航定位系统(如GPS,GLONASS,GALILEO),除了导航、定位、授时功能外,北斗卫星导航定位系统还具有双向的短报文通信功能。因此,利用北斗卫星导航定位系统可以在没有手机信号的区域为人们提供通信及信息服务。
由于带有短报文通信功能的北斗模块相对普通通信设备价格昂贵,对于个人用户很难进行广泛推广。因此,允许多个用户同时共用一个北斗模块是一个有效的解决方案,在产品实现上我们把它称为“北斗路由器”(类比3G路由器)。另外,民用北斗的短报文通信功能有很大的限制,比如每分钟只能发送一次,一次最多只能发送100多个字节的数据。因此,在多用户情景中有必要对北斗的短报文通信进行优化,使其具备一定的“智能”优化功能。
发明内容
本发明所要解决的技术问题是针对上述现有技术提供一种智能北斗路由器,该智能北斗路由器能实现北斗信号和局域网信号之间的转换,同时允许多个用户同时通过局域网使用北斗短报文通信功能。
本发明解决上述技术问题所采用的技术方案为:一种智能北斗路由器,包括能与北斗卫星进行数据通信的北斗收发模块;其特征在于:还包括与北斗收发模块连接的中心控制模块,与中心控制模块连接的至少能支持AP模式WIFI模块和局域网模块,局域网模块提供有LAN接口,其中中心控制模块能完成长度超过北斗收发模块能发送的短报文长度的长报文的发送和接收。
所述中心控制模块完成长度超过北斗收发模块能发送的短报文长度的长报文的发送和接收的具体方式为:
发送端的智能北斗路由器将长报文分割成能够用北斗收发模块和北斗短报文协议发送的多条分包数据,然后再将分解后的多条分包数据通过北斗短报文协议发送给接收端的智能北斗路由器;所述分包数据包括包头和数据正文两部分,其中包头包含的内容有:
分包标识:用来标识本分包数据为某长报文中的一个分包,不是独立的数据包;
末包标识:用来标识本分包数据是否是长报文的最后一个分包;
分包ID:用来指定本分包数据在原长报文所有分包数据中的唯一ID;
所属长报文ID:标明本分包数据属于哪个长报文;
接收端对收到的分包数据进行缓存,待接收端收到包含有末包标识的分包数据后,根据每个分包数据中的分包ID来确定分包数据的顺序,然后对属于同一个长报文的所有分包数据进行合并;最后根据合并的结果,给发送端返回一条“接收成功”反馈信息或“补包请求”反馈消息,“补包请求”反馈消息包含所属长报文ID、丢失的分包ID;
发送端根据收到的反馈消息,如为“补包请求”反馈消息,则将丢失的相应长报文的相应分包数据重新发送给接收端。
作为改进,发送端和接收端通过通信地址和长报文ID来维护长报文通信链路,保证不同链路的数据不会相互混淆,这里的通信地址为发送端或接收端的ID。
作为改进,接收端根据分包ID和所属长报文ID来判定是否收到重复的分包数据,如果收到了重复的分包数据,则把重复的分包数据丢弃;发送端与接收端在分包数据传输过程中出现丢包情况有五种:
第一种,接收端有其它分包数据没有收到,但包含末包标识的分包数据收到,发送端收到接收端发来的“补包请求”反馈消息;
第二种情况:发送给接收端的包含末包标识的分包数据丢失;
第三种情况:接收端所有分包数据全部收到,但接收端发送给发送端的反馈消息丢失,发送端没有收到接收端的反馈消息;
第四种情况:接收端有其它分包数据丢失,但包含末包标识的分包数据收到,接收端给发送端收发送的“补包请求”反馈消息丢失;
第五种情况:发送端发给接收端的补包数据全部丢失,即发送端发送了补包数据,但接收端一个也没收到;
针对上述五种丢包情况,通过如下补包机制进行处理:
针对第一种情况,接收端收到包含末包标识的分包数据后,由此判断发送端针对某一长报文所有的分包数据均发送结束,接收端按照分包合并后的反馈规则,给发送端返回一条反馈消息,反馈消息包含所属长报文ID和丢失的分包ID,发送端收到反馈消息后,根据反馈消息的发送地址(其实是根据这三个keys确定丢失分包。请在另个相应专利说明中做修改。)及其中的所属长报文ID和丢失的分包ID找到该长报文中相应丢失的分包数据,然后再根据反馈消息所在的短报文的发送地址将丢失的分包数据重新发送给接收端;
针对第二种情况,由于接收端没有收到包含末包标识的分包数据,因此无法判断发送端是否发送结束,也就无法启动分包合并操作,因此不会向发送端发送反馈消息,此时,发送端和接收端会进入互相等待的“死锁”状态,即——接收端等待发送端的包含末包标识的分包数据,发送端等待接收端的反馈消息,为避免这种死锁状态,在发送端设置定时器解锁机制,即:设置一个60~70秒的定时器,在一个长报文的所有分包数据发送结束后,启动定时器,如果定时器计时结束还没有收到接收端发来的反馈消息,则认为反馈消息在传输中丢失,此时发送端向接收端补发一次包含末包标识的分包数据,然后重新启动定时器,为避免无限循环,定时器重新启动的次数不超过3次;三次重启的定时器计时结束后还没有收到接收端发来的反馈消息时,释放发送端与接收端之间的链路资源,本次通信失败;
针对第三种情况,发送端针对某一长报文的所有分包数据实际上已经成功传输,但“成功接收”的反馈消息丢失,由于发送端的定时器解锁机制,定时器计时结束后会重发包含末包标识的分包数据,对此,接收端接收到包含末包标识的分包数据后,根据所属长报文ID判定此长报文已接收完毕,则丢弃该分包数据,并发送“成功接收”的反馈消息给发送端;
针对第四种情况:接收端等待发送端的补包,发送端等待接收端的反馈消息,双方会进入互相等待的“死锁”状态,此时同样通过发送端的定时器解锁机制解决;
针对第五种情况:接收端一直等待发送端的补包,发送端等待接收端的再次反馈消息,也会进入“死锁”状态,此时同样通过发送端的定时器解锁机制解决。
再改进,针对第一种情况,接收端设置有超时机制:反复发送3次“补包请求”反馈消息后仍没有收到相应丢失分包数据,则放弃接收该分包数据。
再改进,针对第三种情况,接收端记录最后一次成功接收到的分包数据中的所属长报文ID,以此判断当前收到的分包数据是否属于最后一次传输的长报文。
再改进,发送端向某一接收端发送一长报文时,需要临时建立一条长报文传输链路,不同的发送端能同时与同一个接收端之间建立长报文传输链路,即:同一个接收端能同时接收不同的发送端发来的不同长报文;同一个发送端也能同时与不同的接收端建立长报文传输链路,即:同一个发送端能同时将不同的长报文发送给不同的接收端。
再改进,所述中央控制器还能将多个用户数据捆绑在同一条短报文中进行发送,具体实现方式为:将需要发往同一个接收端的不同用户数据捆绑在一个北斗短报文中,然后通过发送终端发送出去,不同用户数据捆绑后的北斗短报文成为混合报文,混合报文的长度满足能够用北斗短报文协议进行发送,混合报文的内容格式为:标识位、第一原始数据长度、第一原始数据、第二原始数据长度、第二原始数据、……第n原始数据长度、第n原始数据;
接收终端收到发送终端发来的混合报文后,根据混合报文的内容格式,依次提取出混合报文中的原始数据。
较好的,标识位的长度为1个字节,第一原始数据长度、第二原始数据长度、……第n原始数据长度的位数也均为1个字节。
再改进,不同用户数据捆绑进同一个北斗短报文的方式为:
建立并维护一个发送队列,当北斗发送终端可以发送北斗短报文时,首先从发送队列的头部取出并移除首条待发数据,将首条待发数据作为第一原始数据放入混合报文内,统计第一原始数据的字节长度,将第一原始数据的字节长度存入混合报文的第一原始数据长度;然后依次往后遍历发送队列,找到第一个能够放入混合报文剩余空间的待发数据,把该待发数据作为第二原始数据放入混合报文中,并从发送队列中删除此待发数据,同样统计该待发数据的字节长度存入混合报文的第二原始数据长度;按照这个规则不断循环,直到混合报文剩余空间无法容纳发送队列中的任何待发数据为止。
再改进,在发送端,为每一个用户数据提供优先权级别,然后根据优先权级别将用户数据存入发送队列,优先级最高的用户数据放在发送队列的头部,优先级低的用户数据放在优先级高的数据后面。
与现有技术相比,本发明的优点在于:实现北斗信号与WIFI信号之间的转换,允许多个用户设备(比如智能手机)通过WIFI同时进行连接,还能完成长度超过北斗收发模块能发送的短报文长度的长报文的发送和接收。
附图说明
图1为本发明实施例中智能北斗路由器的模块框图;
图2为本发明实施例中分包数据结构示意图;
图3为本发明实施例中混合报文结构示意图。
具体实施方式
以下结合附图实施例对本发明作进一步详细描述。
如图1所示的智能北斗路由器,包括能与北斗卫星进行数据通信的北斗收发模块1;与北斗收发模块1连接的具有北斗信号与局域网信号转换电路的中心控制模块2,与中心控制模块2连接的能支持AP模式的WIFI模块3和局域网模块4,局域网模块提供有LAN接口。
本实施例中,所述WIFI模块、局域网模块和中心控制模块设置在核心板上,另外还设置有一底板,该底板上设置有电源电路、MCU控制器和RS232-TTL转换电路,其中电源电路的输出端具有两路输出,一路输出5V/2A的电源给核心板,另一路输出要20V/3A的电源给北斗收发模块;MCU控制器至少具有四个URAT接口,而北斗收发模块具有至少两个串口分别提供北斗信号和GPS信号,核心板至少具有两个URAT接口,北斗收发模块的两个串口分别连接一RS232-TTL转换电路后与MCU控制器的两个URAT接口连接,MCU控制器通过两个URAT接口分别与核心板的两个URAT接口连接。而MCU控制器采用ST的STM32F103RCT6控制器,主频72MHz,搭载5个UART外设接口;RS232-TTL转换电路采用TI的TRS3232CDR模块,具有双通道转换能力;核心板采用英国The Raspberry Pi Foundation公司提供的Raspberry Pi 2芯片。
本实施例中,中心控制模块能完成长度超过北斗收发模块能发送的短报文长度的长报文的发送和接收,其具体方式为:
当发送端发送的数据大于短报文的最大字节数时,我们称该数据为长报文,此时发送端的智能北斗路由器(以下简称发送端)需要把长报文分割成能够用北斗短报文协议发送的多条分包数据,每个分包数据均包含包头和数据正文两部分,参见图2所示,包头包含以下4个信息:
分包标识:用来标识本分包数据为某长报文中的一个分包,不是独立的数据包;
末包标识:用来标识本分包数据是否是长报文的最后一个分包;
分包ID:用来指定本分包数据在原长报文所有分包数据中的唯一ID;
所属长报文ID:标明本分包数据属于哪个长报文;
本实施例中,用两个字节来表示包头,其中用6bits的msgType来作为分包标识,用2bits来标明所属长报文ID,用1bit来标识末包标识,用7bits来指定分包ID,这样可支持最大长报文长度为128x120字节。实际应用中可以根据不同需求规定这些字段的长度,比如只用一个bit进行分包标志,把其余bits分配给分包ID,这样可以大大扩展长报文的最大报文长度为4096x 120。同理,分包的包头长度可以根据需求进行扩展。
接收端的智能北斗路由器(以下简称接收端)对收到的分包数据进行缓存,待接收端收到包含有末包标识的分包数据后,根据每个分包数据中的分包ID来确定分包数据的顺序,然后对属于同一个长报文的所有分包数据进行合并;最后根据合并的结果,给发送端返回一条“接收成功”反馈信息或“补包请求”反馈消息,“补包请求”反馈消息包含所属长报文ID和丢失的分包ID;
发送端根据收到的反馈消息,如为“补包请求”反馈消息,则将丢失的相应长报文的相应分包数据重新发送给接收端。
另外,由于发送端的原因,有些分包数据会被重复发送,接收端根据分包ID和所属长报文ID来判定是否收到重复分包,并把重复分包丢弃。
本发明还提供了一种可靠的丢包处理机制,即可靠性的传输机制:
北斗短报文通信没有实现链路控制功能,在传输过程中存在丢包问题,因此长报文通信方法需要实现一个补包机制,发送端与接收端在分包数据传输过程中出现丢包情况有五种:
第一种,接收端有其它分包数据没有收到,但包含末包标识的分包数据收到,发送端收到接收端发来的“补包请求”反馈消息;
第二种情况:发送给接收端的包含末包标识的分包数据丢失;
第三种情况:接收端所有分包数据全部收到,但接收端发送给发送端的反馈消息丢失,发送端没有收到接收端的反馈消息;
第四种情况:接收端有其它分包数据丢失,但包含末包标识的分包数据收到,接收端给发送端收发送的“补包请求”反馈消息丢失;
第五种情况:发送端发给接收端的补包数据全部丢失,即发送端发送了补包数据,但接收端一个也没收到;
针对上述五种丢包情况,通过如下补包机制进行处理:
针对第一种情况,接收端收到包含末包标识的分包数据后,由此判断发送端针对某一长报文所有的分包数据均发送结束,接收端按照分包合并后的反馈规则,给发送端返回一条反馈消息,反馈消息包含所属长报文ID和丢失的分包ID,发送端收到反馈消息后,根据反馈消息中的所属长报文ID和丢失的分包ID找到该长报文中相应丢失的分包数据,然后再根据反馈消息的发送地址将丢失的分包数据重新发送给接收端;而接收端设置有超时机制:反复发送3次“补包请求”反馈消息后仍没有收到相应丢失分包数据,则放弃接收该分包数据;
针对第二种情况,由于接收端没有收到包含末包标识的分包数据,因此无法判断发送端是否发送结束,也就无法启动分包合并操作,因此不会向发送端发送反馈消息,此时,发送端和接收端会进入互相等待的“死锁”状态,即——接收端等待发送端的包含末包标识的分包数据,发送端等待接收端的反馈消息;为避免这种死锁状态,在发送端设置定时器解锁机制,即:设置一个60~70秒的定时器,在一个长报文的所有分包数据发送结束后,启动定时器,如果定时器计时结束还没有收到接收端发来的反馈消息,则认为反馈消息在传输中丢失,此时发送端向接收端补发一次包含末包标识的分包数据,然后重新启动定时器,为避免无限循环,定时器重新启动的次数不超过3次;三次重启的定时器计时结束后还没有收到接收端发来的反馈消息时,释放发送端与接收端之间的链路资源,本次通信失败;
针对第三种情况,发送端针对某一长报文的所有分包数据实际上已经成功传输,但“成功接收”的反馈消息丢失,由于发送端的定时器解锁机制,定时器计时结束后会重发包含末包标识的分包数据,对此,接收端接收到包含末包标识的分包数据后,根据所属长报文ID判定此长报文已接收完毕,则丢弃该分包数据,并发送“成功接收”的反馈消息给发送端;同时接收端记录最后一次成功接收到的分包数据中的所属长报文ID,当接收端收到新的分包数据时,以此判断当前收到的新分包数据是否属于最后一次传输的长报文;
针对第四种情况:接收端等待发送端的补包,发送端等待接收端的反馈消息,双方会进入互相等待的“死锁”状态,此时同样通过发送端的定时器解锁机制解决;
针对第五种情况:接收端一直等待发送端的补包,发送端等待接收端的再次反馈消息,也会进入“死锁”状态,此时同样通过发送端的定时器解锁机制解决。
在进行长报文传输过程中,智能北斗路由器还具有较好的链路管理机制:发送端向某一接收端发送一长报文时,需要临时建立一条长报文传输链路,不同的发送端能同时与同一个接收端之间建立长报文传输链路,即:同一个接收端能同时接收不同的发送端发来的不同长报文;同一个发送端也能同时与不同的接收端建立长报文传输链路,即:同一个发送端能同时将不同的长报文发送给不同的接收端。对于发送端而言,为处理接收端的丢包反馈消息,发送端在发送完数据后需要为接收端维护所发长报文的所有分包,直到确认接收端收到所有分包后才释放资源或者三次重启的定时器计时结束后还没有收到接收端发来的反馈消息时,释放发送端与接收端之间的链路资源。而对于接收端而言,接收端在接收过程中需要缓存已接收到的所有分包数据,而且需要考虑可能同时有两个或者多个发送端在发送不同的长报文;另外为避免内存泄漏,当从相同发送端收到不同长报文的分包时,接收端才销毁上一个长报文的数据和记录,然后重新建立与之前发送端之间新的链路。通过通信地址+所属长报文ID可以进行链路的隔离,保证不同链路的数据不会混淆,而通信地址为发送端或接收端的ID。
本实施例中,中心控制模块还能将多个用户数据捆绑在同一条短报文中进行发送,具体实现方式为:是将需要发往同一个接收端的不同用户数据捆绑在一个北斗短报文中,然后通过北斗发送端发送出去;不同用户数据捆绑后的北斗短报文成为混合报文,混合报文的长度满足能够用北斗短报文协议进行发送,混合报文的内容格式为:标识位、第一原始数据长度、第一原始数据、第二原始数据长度、第二原始数据、……第n原始数据长度、第n原始数据,参见图3所示;n的大小根据实际情况原始数据大小确定。本实施例中,为了保证混合报文在接收终端的提取,标识位的长度为1个字节,将第一原始数据长度、第二原始数据长度、……第n原始数据长度的位数也都设为1个字节。
在实际操作过程中,不同用户数据捆绑进同一个北斗短报文的方式为:
在发送端,建立并维护一个发送队列,当发送端可以发送北斗短报文时,首先从发送队列的头部取出并移除首条待发数据,将首条待发数据作为第一原始数据放入混合报文内,统计第一原始数据的字节长度,将第一原始数据的字节长度存入混合报文的第一原始数据长度;然后依次往后遍历发送队列,找到第一个能够放入混合报文剩余空间的待发数据,把该待发数据作为第二原始数据放入混合报文中,并从发送队列中删除此待发数据,同样统计该待发数据的字节长度存入混合报文的第二原始数据长度;按照这个规则不断循环,直到混合报文剩余空间无法容纳发送队列中的任何待发数据为止。
而发送队列中的待发数据通过如下方式存入:在发送端,为每一个用户数据提供优先权级别,然后根据优先权级别将用户数据存入发送队列,优先级最高的用户数据放在发送队列的头部,优先级低的用户数据放在优先级高的数据后面。这种方式,可以保证优先发送优先级高的用户数据前提下,在一个混合报文中最大限度地捆绑进更多条待发用户数据。
而在接收终端收到北斗发送终端发来的短报文后,根据短报文的第一个字节内容判断是否与混合报文的标识位相同,如是,则该短报文为混合报文,然后读取该混合报文的第二个字节内容,根据第二个字节的内容读取相应长度的第一原始数据;第一原始数据读取完毕后,再读取一个字节的内容,根据该字节内容,读取相应字节长度的第二原始数据,依次类推,依次提取出混合报文中的原始数据。
Claims (10)
1.一种智能北斗路由器,一种智能北斗路由器,包括能与北斗卫星进行数据通信的北斗收发模块;其特征在于:还包括与北斗收发模块连接的中心控制模块,与中心控制模块连接的至少能支持AP模式的WIFI模块和局域网模块,局域网模块提供有LAN接口,其中中心控制模块能完成长度超过北斗收发模块能发送的短报文长度的长报文的发送和接收。
2.根据权利要求1所述的智能北斗路由器,其特征在于:所述中心控制模块完成长度超过北斗收发模块能发送的短报文长度的长报文的发送和接收的具体方式为:
发送端的智能北斗路由器将长报文分割成能够用北斗收发模块和北斗短报文协议发送的多条分包数据,然后再将分解后的多条分包数据通过北斗短报文协议发送给接收端的智能北斗路由器;所述分包数据包括包头和数据正文两部分,其中包头包含的内容有:
分包标识:用来标识本分包数据为某长报文中的一个分包,不是独立的数据包;
末包标识:用来标识本分包数据是否是长报文的最后一个分包;
分包ID:用来指定本分包数据在原长报文所有分包数据中的唯一ID;
所属长报文ID:标明本分包数据属于哪个长报文;
接收端对收到的分包数据进行缓存,待接收端收到包含有末包标识的分包数据后,根据每个分包数据中的分包ID来确定分包数据的顺序,然后对属于同一个长报文的所有分包数据进行合并;最后根据合并的结果,给发送端返回一条“接收成功”反馈信息或“补包请求”反馈消息,“补包请求”反馈消息包含所属长报文ID、丢失的分包ID;
发送端根据收到的反馈消息,如为“补包请求”反馈消息,则将丢失的相应长报文的相应分包数据重新发送给接收端。
3.根据权利要求2所述的智能北斗路由器,其特征在于:接收端根据分包ID和所属长报文ID来判定是否收到重复的分包数据,如果收到了重复的分包数据,则把重复的分包数据丢弃;发送端与接收端在分包数据传输过程中出现丢包情况有五种:
第一种,接收端有其它分包数据没有收到,但包含末包标识的分包数据收到,发送端收到接收端发来的“补包请求”反馈消息;
第二种情况:发送给接收端的包含末包标识的分包数据丢失;
第三种情况:接收端所有分包数据全部收到,但接收端发送给发送端的反馈消息丢失,发送端没有收到接收端的反馈消息;
第四种情况:接收端有其它分包数据丢失,但包含末包标识的分包数据收到,接收端给发送端收发送的“补包请求”反馈消息丢失;
第五种情况:发送端发给接收端的补包数据全部丢失,即发送端发送了补包数据,但接收端一个也没收到;
针对上述五种丢包情况,通过如下补包机制进行处理:
针对第一种情况,接收端收到包含末包标识的分包数据后,由此判断发送端针对某一长报文所有的分包数据均发送结束,接收端按照分包合并后的反馈规则,给发送端返回一条反馈消息,反馈消息包含所属长报文ID和丢失的分包ID,发送端收到反馈消息后,根据反馈消息中的所属长报文ID和丢失的分包ID找到该长报文中相应丢失的分包数据,然后再根据反馈消息所在的短报文的发送地址将丢失的分包数据重新发送给接收端;
针对第二种情况,由于接收端没有收到包含末包标识的分包数据,因此无法判断发送端是否发送结束,也就无法启动分包合并操作,因此不会向发送端发送反馈消息,此时,发送端和接收端会进入互相等待的“死锁”状态,即——接收端等待发送端的包含末包标识的分包数据,发送端等待接收端的反馈消息,为避免这种死锁状态,在发送端设置定时器解锁机制,即:设置一个60~70秒的定时器,在一个长报文的所有分包数据发送结束后,启动定时器,如果定时器计时结束还没有收到接收端发来的反馈消息,则认为反馈消息在传输中丢失,此时发送端向接收端补发一次包含末包标识的分包数据,然后重新启动定时器,为避免无限循环,定时器重新启动的次数不超过3次;三次重启的定时器计时结束后还没有收到接收端发来的反馈消息时,释放发送端与接收端之间的链路资源,本次通信失败;
针对第三种情况,发送端针对某一长报文的所有分包数据实际上已经成功传输,但“成功接收”的反馈消息丢失,由于发送端的定时器解锁机制,定时器计时结束后会重发包含末包标识的分包数据,对此,接收端接收到包含末包标识的分包数据后,根据所属长报文ID判定此长报文已接收完毕,则丢弃该分包数据,并发送“成功接收”的反馈消息给发送端;
针对第四种情况:接收端等待发送端的补包,发送端等待接收端的反馈消息,双方会进入互相等待的“死锁”状态,此时同样通过发送端的定时器解锁机制解决;
针对第五种情况:接收端一直等待发送端的补包,发送端等待接收端的再次反馈消息,也会进入“死锁”状态,此时同样通过发送端的定时器解锁机制解决。
4.根据权利要求3所述的智能北斗路由器,其特征在于:针对第一种情况,接收端设置有超时机制:反复发送3次“补包请求”反馈消息后仍没有收到相应丢失分包数据,则放弃接收该分包数据。
5.根据权利要求3所述的智能北斗路由器,其特征在于:针对第三种情况,接收端记录最后一次成功接收到的分包数据中的所属长报文ID,以此判断当前收到的分包数据是否属于最后一次传输的长报文。
6.根据权利要求2所述的智能北斗路由器,其特征在于:发送端向某一接收端发送一长报文时,需要临时建立一条长报文传输链路,不同的发送端能同时与同一个接收端之间建立长报文传输链路,即:同一个接收端能同时接收不同的发送端发来的不同长报文;同一个发送端也能同时与不同的接收端建立长报文传输链路,即:同一个发送端能同时将不同的长报文发送给不同的接收端。
7.根据权利要求1所述的智能北斗路由器,其特征在于:所述中央控制器还能将多个用户数据捆绑在同一条短报文中进行发送,具体实现方式为:将需要发往同一个接收端的不同用户数据捆绑在一个北斗短报文中,然后通过发送终端发送出去,不同用户数据捆绑后的北斗短报文成为混合报文,混合报文的长度满足能够用北斗短报文协议进行发送,混合报文的内容格式为:标识位、第一原始数据长度、第一原始数据、第二原始数据长度、第二原始数据、……第n原始数据长度、第n原始数据;
接收终端收到发送终端发来的混合报文后,根据混合报文的内容格式,依次提取出混合报文中的原始数据。
8.根据权利要求7所述的数据传输方法,其特征在于:标识位的长度为1个字节,第一原始数据长度、第二原始数据长度、……第n原始数据长度的位数也均为1个字节。
9.根据权利要求7所述的数据传输方法,其特征在于:不同用户数据捆绑进同一个北斗短报文的方式为:
建立并维护一个发送队列,当北斗发送终端可以发送北斗短报文时,首先从发送队列的头部取出并移除首条待发数据,将首条待发数据作为第一原始数据放入混合报文内,统计第一原始数据的字节长度,将第一原始数据的字节长度存入混合报文的第一原始数据长度;然后依次往后遍历发送队列,找到第一个能够放入混合报文剩余空间的待发数据,把该待发数据作为第二原始数据放入混合报文中,并从发送队列中删除此待发数据,同样统计该待发数据的字节长度存入混合报文的第二原始数据长度;按照这个规则不断循环,直到混合报文剩余空间无法容纳发送队列中的任何待发数据为止。
10.根据权利要求9所述的数据传输方法,其特征在于:在发送端,为每一个用户数据提供优先权级别,然后根据优先权级别将用户数据存入发送队列,优先级最高的用户数据放在发送队列的头部,优先级低的用户数据放在优先级高的数据后面。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510409282.5A CN104967570B (zh) | 2015-07-13 | 2015-07-13 | 一种智能北斗路由器 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510409282.5A CN104967570B (zh) | 2015-07-13 | 2015-07-13 | 一种智能北斗路由器 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104967570A true CN104967570A (zh) | 2015-10-07 |
CN104967570B CN104967570B (zh) | 2018-09-18 |
Family
ID=54221517
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510409282.5A Active CN104967570B (zh) | 2015-07-13 | 2015-07-13 | 一种智能北斗路由器 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104967570B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106211236A (zh) * | 2016-06-29 | 2016-12-07 | 中国电子科技集团公司第五十四研究所 | 面向多业务多用户的北斗rdss微基站信息组帧传输方法 |
CN106209204A (zh) * | 2016-06-30 | 2016-12-07 | 广州润芯信息技术有限公司 | 应用于北斗一代卫星导航系统的语音传输方法和系统 |
CN106411390A (zh) * | 2016-09-14 | 2017-02-15 | 西安远眺卫星通信有限公司 | 基于天通一号通信卫星的互联网便携终端及其通信方法 |
CN106452688A (zh) * | 2016-10-11 | 2017-02-22 | 福建星海通信科技有限公司 | 一种北斗数据缺报重传方法及系统 |
CN106788680A (zh) * | 2016-12-29 | 2017-05-31 | 湖南泰达讯科技有限公司 | 集群卫星通信装置及其通信方法 |
CN108398700A (zh) * | 2018-01-19 | 2018-08-14 | 重庆九洲星熠导航设备有限公司 | 一种基于北斗短报文的高精度定位系统和方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102546626A (zh) * | 2011-12-31 | 2012-07-04 | 华为技术有限公司 | 一种数据处理方法、装置及系统 |
CN103826259A (zh) * | 2014-01-13 | 2014-05-28 | 上海美迪索科电子科技有限公司 | 利用北斗短报文通信实现北斗中长报文通信功能的方法 |
CN203675339U (zh) * | 2014-01-22 | 2014-06-25 | 青岛海信电子设备股份有限公司 | 一种基于Wifi的北斗通信网关及通信系统 |
-
2015
- 2015-07-13 CN CN201510409282.5A patent/CN104967570B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102546626A (zh) * | 2011-12-31 | 2012-07-04 | 华为技术有限公司 | 一种数据处理方法、装置及系统 |
CN103826259A (zh) * | 2014-01-13 | 2014-05-28 | 上海美迪索科电子科技有限公司 | 利用北斗短报文通信实现北斗中长报文通信功能的方法 |
CN203675339U (zh) * | 2014-01-22 | 2014-06-25 | 青岛海信电子设备股份有限公司 | 一种基于Wifi的北斗通信网关及通信系统 |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106211236A (zh) * | 2016-06-29 | 2016-12-07 | 中国电子科技集团公司第五十四研究所 | 面向多业务多用户的北斗rdss微基站信息组帧传输方法 |
CN106209204A (zh) * | 2016-06-30 | 2016-12-07 | 广州润芯信息技术有限公司 | 应用于北斗一代卫星导航系统的语音传输方法和系统 |
CN106411390A (zh) * | 2016-09-14 | 2017-02-15 | 西安远眺卫星通信有限公司 | 基于天通一号通信卫星的互联网便携终端及其通信方法 |
CN106452688A (zh) * | 2016-10-11 | 2017-02-22 | 福建星海通信科技有限公司 | 一种北斗数据缺报重传方法及系统 |
CN106788680A (zh) * | 2016-12-29 | 2017-05-31 | 湖南泰达讯科技有限公司 | 集群卫星通信装置及其通信方法 |
CN108398700A (zh) * | 2018-01-19 | 2018-08-14 | 重庆九洲星熠导航设备有限公司 | 一种基于北斗短报文的高精度定位系统和方法 |
Also Published As
Publication number | Publication date |
---|---|
CN104967570B (zh) | 2018-09-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104967570A (zh) | 一种智能北斗路由器 | |
CN105120439A (zh) | 北斗长报文通信方法 | |
CN110098858A (zh) | 一种中继工作模式配置方法及终端 | |
CN109547168A (zh) | 数据传输方法、终端设备和网络设备 | |
EP2779707A1 (en) | Method, equipment and system for transmitting wireless data | |
US20220264641A1 (en) | Hybrid automatic repeat request feedback method and apparatus | |
KR20210002117A (ko) | 다운링크 피드백 정보를 송신하는 방법, 기지국 및 단말 기기 | |
US11388102B2 (en) | Transmission control device, transmission control method, reception control device, and reception control method | |
CN117544919A (zh) | 通信方法、建立slrb的方法和通信装置 | |
CN104184834A (zh) | 文件传输的方法、文件传输的装置和终端 | |
CN115361704A (zh) | 基于基站mac子层直接传输的c2d通信系统及i/o数据通信方法 | |
CN104333842A (zh) | 一种基于wifi的智能设备节目资源共享方法及其系统 | |
CN103108377A (zh) | 一种mtc终端的通信方法、系统及中心控制节点 | |
US7801097B2 (en) | Setting up of a wireless network by determining and utilizing local topology information | |
CN110140417B (zh) | 通信方法、通信装置、通信设备及计算机可读介质 | |
EP3809752B1 (en) | Electronic device, wireless communication method and computer readable medium | |
CN113573252A (zh) | 数据传输方法、系统、芯片、电子设备及存储介质 | |
CN116097825A (zh) | 一种通信方法及通信装置 | |
WO2024001832A1 (zh) | 通信方法及通信装置 | |
CN113573310B (zh) | 一种密钥更新的通信方法、装置和系统 | |
CN105580329B (zh) | 一种空口数据传输的方法、装置及系统 | |
CN101056186B (zh) | 用户网络中的组播方法及其系统 | |
WO2024046176A1 (zh) | 通信方法和通信装置 | |
CN107508660A (zh) | 一种利用北斗短报文实现第三方数据双向传输的方法 | |
WO2024051517A1 (zh) | 一种通信方法及相关装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right |
Effective date of registration: 20201209 Address after: 310051 1310, floor 13, building 5, No. 768, Jianghong Road, Changhe street, Binjiang District, Hangzhou City, Zhejiang Province Patentee after: Hangzhou Chuanshilian Science and Technology Co.,Ltd. Address before: No. 777, Zhongguan West Road, Zhenhai District, Ningbo City, Zhejiang Province Patentee before: NINGBO SHANGWEI INFORMATION TECHNOLOGY Co.,Ltd. |
|
TR01 | Transfer of patent right |