著录项信息
专利名称 | 高密度通讯环境下通信数据收发方法 |
申请号 | CN201210116106.9 | 申请日期 | 2012-04-20 |
法律状态 | 授权 | 申报国家 | 中国 |
公开/公告日 | 2012-09-26 | 公开/公告号 | CN102693573A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | G07C13/00 | IPC分类号 | G;0;7;C;1;3;/;0;0查看分类表>
|
申请人 | 中南大学;龙建 | 申请人地址 | 湖南省长沙市麓山南路932号
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 中南大学,龙建 | 当前权利人 | 中南大学,龙建 |
发明人 | 龙军;杨柳;龙建 |
代理机构 | 暂无 | 代理人 | 暂无 |
摘要
本发明公开一种针对高密度通讯环境下通信数据收发方法,该通信数据收发方法采用轮询方式、组呼方式和竞争方式来计算资源动态服务能力及通信任务实时匹配来实现。设备唯一编号作为其通讯身份标识、通信数据有效性采用重发和校验机制来保证、拥塞控制理论贯穿在整个通信过程中。利用该通信数据收发方法来评估选择最优的通讯方式进而提高数据收发速率,它的主要优点是:在高密度通讯环境下反应速度快,通讯设备不用空等,有效的解决了通讯过程中相互冲突问题;采用可扩展的设计模式,可高效地集成到已有各类通讯系统中,并在系统运行过程中时刻自适应地调整和调度数据收发策略。
1.一种针对高密度通讯环境的通信数据收发方法,其特征在于包括以下步骤:
步骤一、应用软件设置服务端基础信标;
步骤二、应用软件设置服务端投票信标到开始状态;
步骤三、服务端广播基础信标和投票信标;
步骤四、反馈端进入对应的反馈模式;
步骤五、服务端询问反馈端是否有数据提交;
步骤六、反馈端传送数据给服务端,服务端确认收到反馈端的数据;
步骤七、应用软件询问服务端是否有数据提交;
步骤八、服务端将数据打包好提交给应用软件;
步骤九、应用软件对数据包进行解析和处理;
步骤十、应用软件设置服务端投票信标到结束状态。
2.根据权利要求1所述的通信数据收发方法,它包括应用软件和服务端之间的数据通讯,其中应用软件和服务端之间的数据通讯的具体流程包括:
(1)应用软件询问服务端,服务端是否有数据提交给应用软件;
(2)服务端将数据打包提交给应用软件;
(3)应用软件向服务端对数据包进行确认;
(4)应用软件对服务端的数据包进行解析;
(5)应用软件询问是否有指令要转发,无则跳转到(1),有则执行下一步;
(6)发送指令给服务端;
(7)应用软件询问是否要等待应答,要则执行下一步,不要则跳转到(10);
(8)应用软件等待服务端应答,服务端等待反馈端的应答;
(9)应用软件、服务端有应答就处理;
(10)判断转发时间是否到了极限,是则跳转到(1),否则跳转到(5)。
3.根据权利要求1或2所述的通信数据收发方法,它包括服务端和反馈端之间的数据通讯,其中服务端和反馈端之间的数据通讯的具体流程包括:
(1)服务端通电,启动服务端和反馈端之间的数据通讯;
(2)服务端判断基础时标的执行时间是否已到,是则服务端发送基础信标并且控制遥控类设备执行相关操作,否则继续执行下一步;
(3)服务端发送基础信标给反馈端;
(4)服务端发送投票信标给反馈端;
(5)反馈端提交结果或申请给服务端;
(6)服务端保存结果或申请并向反馈端进行确认;
(7)服务端询问应用软件是否有指令要转发,有则跳转到(2),无则执行下一步;
(8)服务端转发应用软件指令;
(9)反馈端应答处理;
(10)反馈端询问转发时间是否到达预设的极限值,是则跳转到(2),否则执行下一步;
(11)服务端断电,保存参数设置,停止服务端和反馈端之间的数据通讯。
4.根据权利要求3所述的通信数据收发方法,其中所述服务端与反馈端之间数据交互方式包括以下3种:
(1)第1种是轮询式,即服务端指定某个特定编号的反馈端提交数据;
(2)第2种是竞争式,即服务端发令后,反馈端只要有数据,都可以提交,但是要按某种防止冲突的方法提交数据;
(3)第3种是组呼式,即将反馈端要提交的数据按一定的策略进行分组,反馈端一组一组地提交数据。
高密度通讯环境下通信数据收发方法\n技术领域\n[0001] 本发明涉及通信领域,尤其是一种复杂环境下的数据收发方法。\n背景技术\n[0002] 随着电子、通信技术、互联网技术的发展,人类开始使用投票表决系统来进行投票,许多大型会场都配有电子投票表决系统,可以自动完成投票、记票、结果统计。但是,目前电子表决系统往往都是针对单个会场的需求设计,无法即时完成视讯会议若干个会场统一投票表决,现有的视频会议系统把每个会场作为一个视讯终端来管理,无法实时对会议议案的投票过程控制和表决结果即时统计。\n[0003] 有一种跨区域投票表决系统,该系统将多个独立的投票表决子系统通过网络连接在一起,利用某个会场的服务端或独立的主机作为服务器,各个分会场通过网络与服务器通讯,实现实时对异地若干个分会场的会议议案的投票过程控制和投票结果即时统计。由于跨区域投票表决系统通常要使用视频会议系统,虽然上述方案使若干个会场的投票表决得以实现,但是由于和视频会议室系统是完全独立的两套系统,使用不方便,会议成本较高,同时也无法解决视频会议系统对参会人员对议案投票表决的管理。\n[0004] 本发明提供了一种新的高密度通讯环境下通信数据方法,其具有在高密度通讯环境下反应速度快,通讯设备不用空等,可采用可扩展的设计模式,可以高效地集成到已有各类通讯系统中等优点。\n发明内容\n[0005] 本发明的技术方案是,一种针对高密度通讯环境的通信数据收发方法,其特征在于包括以下步骤:\n[0006] 步骤一、应用软件设置服务端基础信标;\n[0007] 步骤二、应用软件设置服务端投票信标到开始状态;\n[0008] 步骤三、服务端广播基础信标和投票信标;\n[0009] 步骤四、反馈端进入对应的反馈模式;\n[0010] 步骤五、服务端询问反馈端是否有数据提交;\n[0011] 步骤六、反馈端传送数据给服务端;\n[0012] 步骤七、应用软件询问服务端数据;\n[0013] 步骤八、服务端将数据打包好的给应用软件;\n[0014] 步骤九、应用软件对数据进行解析和处理;\n[0015] 步骤十、应用软件设置服务端投票信标到结束状态。\n[0016] 优选的,它包括应用软件和服务端之间的数据通讯,其中应用软件和服务端之间的数据通讯的具体流程包括:\n[0017] (1)应用软件询问服务端数据;\n[0018] (2)服务端将数据打包提交给应用软件;\n[0019] (3)应用软件向服务端对数据包进行确认;\n[0020] (4)应用软件对服务端的数据包进行解析;\n[0021] (5)应用软件询问是否有指令要转发,无则跳转到(1),有则执行下一步;\n[0022] (6)发送指令给服务端设备;\n[0023] (7)应用软件询问是否要等待应答,要则执行下一步,否要则跳转到(10);\n[0024] (8)应用软件等待服务端应答,服务端等待反馈端应答;\n[0025] (9)应用软件、服务端有应答就处理;\n[0026] (10)判断转发时间是否到了极限,是则跳转到(1),否则跳转到(5)。\n[0027] 优选的,它包括服务端和反馈端之间的数据通讯,其中服务端和反馈端之间的数据通信的具体流程包括:\n[0028] (1)服务端通电,启动服务端和反馈端之间的数据通讯;\n[0029] (2)服务端判断基础时标的执行时间是否已到,是则服务端发送基础信标并执行遥控类设备的相关操作,否则继续执行下一步;\n[0030] (3)服务端发送基础信标给反馈端;\n[0031] (4)服务端发送投票信标给反馈端;\n[0032] (5)反馈端提交结果或申请给服务端;\n[0033] (6)服务端保存结果或申请并对反馈端进行确认;\n[0034] (7)服务端询问应用软件是否有指令要转发,有则跳转到(2),无则执行下一步;\n[0035] (8)服务端转发应用软件指令;\n[0036] (9)反馈端应答处理;\n[0037] (10)反馈端询问转发时间是否到达预设的极限值,是则跳转到(2),否则执行下一步;\n[0038] (11)服务端断电,保存参数设置,停止服务端和反馈端之间的数据通讯。\n[0039] 优选的,所述服务端与反馈端之间数据交互方式包括以下3种:\n[0040] (1)第1种是服务端指定某个特定编号的反馈端提交数据,我们叫轮询式;\n[0041] (2)第2种是服务端发令后,反馈端只要有数据,都可以提交,但是要按某种防止冲突的方法提交数据,我们叫竞争式;\n[0042] (3)第3种将反馈端按一定的策略进行分组,反馈端一组一组地提交数据,我们叫组呼模式。\n附图说明\n[0043] 图1是根据本发明的高密度通讯环境下通信数据收发方法的流程图。\n[0044] 图2是本发明应用软件和与服务端的通讯流程控制。\n[0045] 图3是本发明服务端对反馈端通讯流程控制。\n[0046] 图4是本发明轮询方式数据收发示意图。\n[0047] 图5是本发明组呼方式数据收发示意图\n[0048] 图6是本发明竞争方式数据收发示意图\n[0049] 图7是本发明上传单包数据流程图\n具体实施方式\n[0050] 以下将结合附图来对本发明进行进一步的详细说明,如图1所示,本发明的技术方案是一种高密度通讯环境下通信数据收发方法,其特征在于包括以下步骤:\n[0051] 步骤一、在电脑中通过应用软件设置服务端基础信标;\n[0052] 步骤二、应用软件设置服务端投票信标到开始状态;\n[0053] 步骤三、服务端广播基础信标和投票信标;\n[0054] 步骤四、反馈端进入对应的反馈模式;\n[0055] 步骤五、服务端询问反馈端是否有数据提交;\n[0056] 步骤六、反馈端传送数据给服务端;\n[0057] 步骤七、应用软件询问服务端数据;\n[0058] 步骤八、服务端将数据打包好的给应用软件;\n[0059] 步骤九、应用软件对数据进行解析和处理;\n[0060] 步骤十、应用软件设置服务端投票信标到结束状态。\n[0061] 其中,应用软件可以是本领域所公知的各种投票反馈软件,例如: TurningPoint、PowerVoteQuizz。应用软件发送指令给服务端,通知服务端收取反馈端数据,无论反馈端数量有多大都在规定的时间内收取完毕。\n[0062] 在上述步骤一、二、七、八、十中均涉及应用软件与服务端之间的通讯,优选的,应用软件与服务端之间的通讯流程控制如附图2所示,包括如下步骤:\n[0063] (1)应用软件询问服务端数据;\n[0064] (2)服务端将数据打包提交给应用软件;\n[0065] (3)应用软件向服务端对数据包进行确认;\n[0066] (4)应用软件对服务端的数据包进行解析;\n[0067] (5)应用软件询问是否有指令要转发,无则跳转到(1),有则执行下一步;\n[0068] (6)发送指令给服务端设备;\n[0069] (7)应用软件询问是否要等待应答,要则执行下一步,否要则跳转到(10);\n[0070] (8)应用软件等待服务端应答,服务端等待反馈端应答;\n[0071] (9)应用软件、服务端有应答就处理;\n[0072] (10)判断转发时间是否到了极限,是则跳转到(1),否则跳转到(5)。\n[0073] 进一步的,根据本发明的高密度通讯环境下通讯数据收发方法的步骤三六、七均涉及服务端与反馈端之间的数据通讯,优选的,该具体流程如图3所示,其包括如下步骤:\n[0074] (1)服务端通电,启动服务端和反馈端之间的数据通讯;\n[0075] (2)服务端判断基础时标的执行时间是否已到,是则服务端发送基础信标并执行遥控类设备的相关操作,否则继续执行下一步;\n[0076] (3)服务端发送基础信标给反馈端;\n[0077] (4)服务端发送投票信标给反馈端;\n[0078] (5)反馈端提交结果或申请给服务端;\n[0079] (6)服务端保存结果或申请并对反馈端进行确认;\n[0080] (7)服务端询问应用软件是否有指令要转发,有则跳转到(2),无则执行下一步;\n[0081] (8)服务端转发应用软件指令;\n[0082] (9)反馈端应答处理;\n[0083] (10)反馈端询问转发时间是否到达预设的极限值,是则跳转到(2),否则执行下一步;\n[0084] (11)服务端断电,保存参数设置,停止服务端和反馈端之间的数据通讯。\n[0085] 以下将进一步对根据本发明的数据收发方法进行说明。\n[0086] 公知的,数据传输方向包括2种,上传和下载,上传是指反馈端向服务端提交数据,下载是服务端发送给反馈端数据。\n[0087] 通常,数据量按大小划分为单包和多包。单包指一个定长的数据包就可以完整传输的信息。多包是指要分成多个单包,多次传输才能完成的数据。\n[0088] 为提高通讯效率,服务端和反馈端之间的通信可以划分为4种类型:上传单包、上传多包、下载单包、下载多包。保证这四种数据包的可靠传输就可以满足高密度通讯环境通信数据通信实时收发的需求。\n[0089] 为保证数据包可靠传输到对方,任何数据包都要求有接收正确确认,即传输1个数据包后,接收方应该应答说数据收到了,如果没有这个应答,发送方就应该重新发送,直到成功或多次尝试后宣告失败。\n[0090] 由于都同时发送数据的话,会有通讯冲突导致都无法通讯,所以要有解决通讯冲突的机制。本发明采用主从结构,而且是带信标的,反馈端都以服务端发送的命令为信标,反馈端不主动发送数据,服务端要求发数据才提交数据。\n[0091] 优选的,服务端要求发数据的方式包括有2种,1种称为轮询式,如附图4 所示,其特征在于由服务端指定某个特定编号的反馈端提交数据,反馈端依据服务端的指令顺序,依次向服务端提交数据。优选的,轮询方式具有一种提高效率的变形方式,是一组一组地提交数据,我们叫组呼模式,如附图5所示。第2种称为竞争式,如附图6所示,与轮询式不同,在服务端广播式发问(即向非特定反馈端发问)后,反馈端只要有数据,都可以提交。但此时需要采取某种防止冲突的方法提交数据。例如,如附图6中所示的,如果A3号与A5号在同一时刻提交数据,产生数据冲突,则数据作废。\n[0092] 轮询方式冲突少,但效率低,竞争式就是效率高,以上模式各有特点,在根据本发明的高密度通讯环境下通信数据收发方法中均可采用。\n[0093] 上传单包的实现,如图7所示,上传单包数据的流程如下:\n[0094] 步骤1,服务端询问数据,询问的方式采用轮询、组呼、竞争;\n[0095] 步骤2,反馈端检查是否有数据上传;\n[0096] 步骤3,反馈端上传数据;\n[0097] 步骤4,服务端收到数据后,向反馈端确认数据;\n[0098] 步骤5,检查是否收到来自反馈端的确认,如果没有收到重复步骤3否则回到步骤\n1.\n[0099] 上传多包的实现\n[0100] 上传多包方式有两种:\n[0101] (1)用多次的不连续的上传单包实现的,\n[0102] (2)连续地一次传完多包数据。\n[0103] 例如:一次传一个NK字节的数据包,实现方式有2种情况:一种是服务端要求提交某种类型的多包,一种是反馈端要求发送多包,2种情况都有可能。\n[0104] 如果是反馈端要求发送多包,我们采用的是,反馈端先申请传多包,然后 服务端再用多包接收指令不停接收直到接收完毕的流程。反馈端先申请传多包的请求是在服务端询问上传单包的时候提交给服务端的,然后服务端把申请上传多包的反馈端编号记录下来,然后根据需要再在恰当的时候用多包接收指令接收数据。\n[0105] 多包接收指令可以采用1问1答或1问多传的模式实现。\n[0106] 下载单包的实现\n[0107] 下载单包一般是服务端向指定反馈端发数据包,然后等待反馈端的确认应答,否则重新发数据包。\n[0108] 下载多包的实现\n[0109] 指一次性连续地下载多包数据,实现有1发1确认、多传1确认两种模式。\n[0110] (1)1发1确认模式\n[0111] 服务端向指定反馈端发送类型为T的数据包的第1包,然后等待反馈端确认应答,没收到确认就重新发送,收到确认就发送下一包,直到所有数据包接收正确。\n[0112] (2)多传1确认模式\n[0113] 服务端连续地传输多个数据包,例如1次先传输16个数据包,然后再询问16个包里面正确接收了哪些包,然后再重新发送未正确接收的数据包,然后再询问正确接收的情况。\n在该模式下由于询问的次数大大减少,指定单个反馈端下载的时候,效率提高约1倍。如果是广播式,由于重复发送多次后所有反馈端基本都能接收正确,只剩询问结果的时序,发送数据的时序大大减少,效率能提高很多倍。
法律信息
- 2016-11-16
- 2013-01-09
文件的公告送达
文件的公告送达失败
收件人: 中南大学
文件名称: 发明专利申请初步审查合格通知书
- 2012-11-21
实质审查的生效
IPC(主分类): G07C 13/00
专利申请号: 201210116106.9
申请日: 2012.04.20
- 2012-09-26
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| | 暂无 |
2008-12-09
| | |
2
| |
2009-01-14
|
2005-10-28
| | |
3
| |
2008-06-25
|
2006-02-22
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |