CN107566507A - 一种移动互联网医疗系统 - Google Patents
一种移动互联网医疗系统 Download PDFInfo
- Publication number
- CN107566507A CN107566507A CN201710844238.6A CN201710844238A CN107566507A CN 107566507 A CN107566507 A CN 107566507A CN 201710844238 A CN201710844238 A CN 201710844238A CN 107566507 A CN107566507 A CN 107566507A
- Authority
- CN
- China
- Prior art keywords
- server
- protocol
- medical system
- pptp
- subscriber terminal
- 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.)
- Pending
Links
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明涉及一种移动互联网医疗系统,解决的是流量消耗大的技术问题,通过采用包括至少一个移动用户终端、一个医院信息收录单元以及中心服务器;移动用户终端与服务器,医院信息收录单元与服务器均通过PPTP方法进行IP网络通信,移动用户终端、医院信息收录单元及服务器内均处设有物理网卡,物理网卡连接有路由器;所述PPTP方法包括建立控制连接以及建立数据连接;移动互联网医疗系统还包括与中心服务器连接的第三方支付平台,第三方支付平台还与移动用户终端建立IP网络通信;中心服务器还设有RTC模块,RTC模块用于对移动用户终端的业务请求进行排序确定优先级;的技术方案,较好的解决了该问题,可用于移动互联网医疗中。
Description
技术领域
本发明涉及医疗设备领域,具体涉及一种移动互联网医疗系统。
背景技术
目前各技术领域主要推动“互联网+”,旨在推广互联网、云计算、大数据、物联网等与现代制造业结合,促进电子商务、工业互联网金融的健康发展,引导互联网企业拓展国际、国内市场的要求。“互联网+”在医疗技术应于使用是具有创新意义,目的是通过集结现金的高新网络计算机技术、传统的医疗系统及创新的互联技术,解决广大市民“有病难就医”的需求,打通就医服务的中间环节,使就医人员直通健康服务,协助各大医疗接哦股率先迈进互联网医疗生态圈。
现有的移动互联网医疗系统采用的网络连接方式存在流量消耗大,在流量仍然收费的今天,使得患者就医的成本加大。同时,由于流量消耗,使得患者不能全程在线的使用移动互联网医疗系统。因此,提供一种流量开销低的移动互联网医疗系统就很有必要。
发明内容
本发明所要解决的技术问题是现有技术中存在的流量消耗大技术问题。提供一种新的移动互联网医疗系统,该移动互联网医疗系统具有流量开销低、成本低、使用方便的特点。
为解决上述技术问题,采用的技术方案如下:
一种移动互联网医疗系统,所述移动互联网医疗系统包括至少一个移动用户终端、一个医院信息收录单元以及中心服务器;所述移动用户终端与服务器,医院信息收录单元与服务器均通过PPTP方法进行IP网络通信,所述移动用户终端、医院信息收录单元及服务器内均处设有物理网卡,物理网卡连接有路由器;
所述PPTP方法包括建立控制连接以及建立数据连接;所述移动互联网医疗系统还包括与中心服务器连接的第三方支付平台,第三方支付平台还与移动用户终端建立IP网络通信;
所述中心服务器还设有RTC模块,RTC模块用于对移动用户终端的业务请求进行排序确定优先级;
所述医院信息收录单元用于采集医院各科室的实时业务信息给中心服务器;所述移动用户终端用于向服务器发起业务请求。
本发明的工作原理:移动用户终端使用流量来进行网络通信,对各个路由器的数据监控也需要额外的流量,而用户往往较为在意流量的使用。移动运营商的计量计费,通过移动运营商网络的实际流量就是通过层层打包的流量,需要应用数据加上各层包头。按照现行计费原则,只对IP首部,TCP/UDP首部和应用数据的流量进行记录并计费,因此数据链路层的开销并不计算在内。一个IP数据报由首部和数据两部分组成。首部的前一部分是固定长度,共20字节。在首部固定部分的后面是可选字段,最长为40字节。
PPTP(Point to Point Tunneling Protocol),即点对点隧道协议。该协议是在PPP协议的基础上开发的一种新的增强型安全协议,支持多协议虚拟专用网,可以通过密码验证协议,可扩展认证协议等方法增强安全性。远程用户可以通过ISP、直接连接Internet或者其他网络安全地访问企业网;它能够将PPP(点到点协议)帧封装成IP数据包,以便能够在基于IP的互联网上进行传输。PPTP使用TCP是实现隧道的创建、维护与终止,并使用GRE(通用路由封装)将PPP帧封装成隧道数据。被封装后的PPP帧的有效载荷可以被加密或压缩。PPTP通信过程中需要建立两种连接,一种是控制连接,另一种是数据连接。控制连接用来协商通信过程中的参数和进行数据连接的维护。而真正的数据通信部分则交由PPTP数据连接完成。
上述方案中,为优化,进一步地,所述业务请求包括用户注册、用户登录、用户推出、医院就诊信息查询、预约挂号、排队就医、缴纳费用及提交评价。
进一步地,所述控制连接包括:步骤a:建立TCP连接,步骤b:PPTP控制连接和GRE隧道建立,步骤c:PPP协议的LCP协商,步骤d:PPP协议的身份验证,步骤e:PPP协议的NCP协商,步骤f:PPP协议的CCP协商。
进一步地,所述TCP连接替换为UDP连接。
进一步地,所述建立数据连接为进行数据包封装,数据包封装是将应用层数据封装成IP数据包。
进一步地,所述数据包封装包括:
步骤A:将IP数据包发送到VPN的虚拟接口;VPN的虚拟接口将IP数据包压缩和加密,并增加PPP头;
步骤B:VPN的虚拟接口将PPP帧发送给PPTP协议驱动单元;PPTP协议驱动单元在PPP帧外添加GRE报头;
步骤C:PPTP协议驱动单元将GRE报头提交给TCP/IP协议驱动单元;TCP/IP协议驱动单元为GRE驱动添加IP头部;
步骤D:IP数据包进行数据链路层封装后通过路由器中的物理网卡发送,依据不同的外发物理网络再添加相应的数据链路层报头和报尾。如果IP数据报将在以太网上传输,则用以太网报头和报尾对IP数据报进行数据链路层封装;如果IP数据报将在点对点WAN上传输,如模拟电话或ISDN等,则用PPP报头和报尾对IP数据报进行数据链路层封装。
网络开销即流量,是从IP层算起,IP数据包首部中有固定部分,长为20字节,UDP报文长度固定为8字节。所以PC之间通过UDP报文传一次数据至少要花28字节的开销。因此,使用尽可能长的IP数据报会使传输效率提高,因为每一个IP数据报中首部长度占比数据报总长度的比例就会小些。当报文过大时,稳定性会大大减弱。因为当报文过大时会被分割,使得每个分割块(fragmentation)的长度小于MTU,然后分别发送,并在接收方重新组合(reassemble),但是如果其中一个报文丢失,那么其他已收到的报文都无法返回给程序,也就无法得到完整的数据。选用UDP进行传输时,数据部分的长度最好在28字节到1472字节之间。使用TCP来传输,建立连接需要开销144字节,发送一次数据需要开销80字节,断开连接需要开销160字节,当发送的数据超过1460字节后会进行分片发送。
本发明的有益效果:
效果一,通过PPDP通信方式减少移动医疗系统的流量消耗,降低成本;
效果二,通过第三方支付平台减少用户的使用难度;
效果三,业务请求包括用户注册、用户登录、用户推出、医院就诊信息查询、预约挂号、排队就医、缴纳费用及提交评价,能够全方位覆盖用户的就医全过程,功能齐全。
附图说明
下面结合附图和实施例对本发明进一步说明。
图1,移动互联网医疗系统的示意图。
图2,实施例1中移动互联网医疗系统的就医流程示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。
实施例1
本实施例提供一种移动互联网医疗系统,如图1,所述移动互联网医疗系统包括至少一个移动用户终端、一个医院信息收录单元以及中心服务器;所述移动用户终端与服务器,医院信息收录单元与服务器均通过PPTP方法进行IP网络通信,所述移动用户终端、医院信息收录单元及服务器内均处设有物理网卡,物理网卡连接有路由器;
所述PPTP方法包括建立控制连接以及建立数据连接;所述移动互联网医疗系统还包括与中心服务器连接的第三方支付平台,第三方支付平台还与移动用户终端建立IP网络通信;
所述中心服务器还设有RTC模块,RTC模块用于对移动用户终端的业务请求进行排序确定优先级;
所述医院信息收录单元用于采集医院各科室的实时业务信息给中心服务器;所述移动用户终端用于向服务器发起业务请求。
本实施例的工作流程:如图2,移动用户终端注册、登录后发起查询业务请求;中心服务器将查询业务请求经过RTC排序,按照优先级优先级调取给医院信息收录单元中的医院实时就诊信息;中心服务器将实时就诊信息发送给移动用户终端,移动用户终端确定选项后挂号;挂号成功后到达医院,通过移动用户终端发起排队就诊;中心服务器实时监控医院信息收录单元的实时就诊信息,提示患者就诊;患者就诊,医院信息收录单元接收医生开具电子就诊记录以及生产缴费信息;中心服务器接收缴费信息以及就诊记录,将缴费信息传输给第三方支付平台以及移动用户终端,就诊记录传输给各相关科室;移动用户终端缴费,第三方支付平台同时反馈缴费结果给移动用户终端以及中心服务器;中心服务器通知个相关科室进行相应付费项目治疗;治疗完成后,移动终端推出登录。
注册流程:
终端平台分配序列号模式使用,预制序列号的终端直接登录,终端发送注册包时,包头中的终端序列号后8位为‘0’。终端注册成功后,保存终端序列号和注册成功状态。下次终端重新启动或者换卡重新启动后,读取终端保存的注册状态和终端序列号,注册状态是注册成功时,终端直接登录。
终端发送登录包时,包头中的终端序列号为平台在注册成功应答中分配给终端的序列号或者终端预制的序列号。
终端退出,定义LOGOUT,LOGOUT值为0:正常退出,进入等待激活模式1:准备升级;2:故障断开;3:应用新配置;4:心跳超时;5:故障退出,进入等待激活模式,其他:保留。
其中,IP通信过程由PPTP(Point to Point Tunneling Protocol)完成,即点对点隧道协议。PPTP是在PPP的基础上开发的一种新的增强型安全协议,支持多协议虚拟专用网,可以通过密码验证协议,可扩展认证协议等方法增强安全性。远程用户可以通过ISP、直接连接Internet或者其他网络安全地访问企业网;它能够将PPP(点到点协议)帧封装成IP数据包,以便能够在基于IP的互联网上进行传输。PPTP使用TCP是实现隧道的创建、维护与终止,并使用GRE(通用路由封装)将PPP帧封装成隧道数据。被封装后的PPP帧的有效载荷可以被加密或压缩。PPTP通信过程中需要建立两种连接,一种是控制连接,另一种是数据连接。控制连接用来协商通信过程中的参数和进行数据连接的维护。而真正的数据通信部分则交由PPTP数据连接完成。
详细地,所述业务请求包括用户注册、用户登录、用户推出、医院就诊信息查询、预约挂号、排队就医、缴纳费用及提交评价。
详细地,所述控制连接包括:步骤a:建立TCP连接,步骤b:PPTP控制连接和GRE隧道建立,步骤c:PPP协议的LCP协商,步骤d:PPP协议的身份验证,步骤e:PPP协议的NCP协商,步骤f:PPP协议的CCP协商。
具体地,建立TCP连接:
PPTP控制层协议是建立在TCP协议的基础上,所以刚开始是TCP三次握手。
Client端向Server的1723端口发TCPSYN包,请求建立TCP连接。
Server接收TCP连接请求,回发SYN、ACK。
Client端向Server发送确认包ACK。3次握手协议所花的开销为52+52+40=144字节。
PPTP控制连接和隧道的建立:接下来完成PPTP控制连接和GRE隧道建立。
Client向Server发送Start-Control-Connection-Request,请求建立控制连接。
Server向Client发送Start-Control-Connecton-Reply,应答客户端的请求。
Client向Server发送Outgoing-Call-Request,请求建立PPTP隧道,该消息包含GRE报头中的Call id,该id可唯一地标识一条隧道。
Server向Client发送Outgoing-Call-Reply,应答客户端的建立PPTP隧道请求。
由Client或者Server任意一方发出Set-Link-info,设置PPP协商的选项。
包括TCP包,PPTP控制连接和隧道的建立的开销为196+(40)+196+208+72+64+(40)=816字节。
PPP协议的LCP协商:
LCP是PPP协议的链路控制协议,负责建立、拆除和监控数据链路。协商链路参数,如认证方法,压缩方法,是否回叫等。
Client发送一个Configuration Request,把自己的配置参数发送给Server。
Server发送一个Configuration Request,把自己的配置参数发送给Client。
Client发送一个Configuration Ack,表示所有配置参数全部认识且可以接受,应答Server。
Client又发送一个Configuration Request,把自己的配置参数发送给Server。
Server发送一个Configuration Reject,将自己不能识别的参数告知Client,让Client进行修正。
Client修改配置项后再次发送Configuration Request。
Server发送一个Configuration Ack,标示所有配置参数全部认识且可以接受,应答Client。
包括TCP包和GRE包,LCP协商的开销为57+65+65+(40+32)+57+47+58+58=479字节。
PPP协议的身份验证:LCP协商完成后,PPP协议的Server端会对Client端进行身份验证,在LCP协商中已经协商好身份验证协议。
Server向Client发送Challenge,其中包括一个Challenge string(value字段)和Server Name(pptpd);
Client向Server发送Response,其中用户名使用明文发送,密码(syberos)和Challenge字段混合hash后以密文(value字段)形式发送;
Server读取密码文件,对用户身份进行验证,验证成功,向Client发送Success,表示身份验证成功;
包括PPTP包、LCP包和TCP包,PPP协议的身份验证的开销为(64)+60+(56+65+58+40)+94+101=538字节。
PPP协议的CCP协商:CCP协议协商PPP通讯中数据加密的协议。
Server向Client发送Configuration Request,标识服务端支持的加密协议。
Client向Server发送Configuration Request,标识客户端支持的加密协议。
Client向Server发送Configuration ack,标识接受服务端的加密协议。
Server发现Client的配置是无效的,则给Client发送一条有效的配置信息,使用Configuration Nak发送。
Client根据Server端发送过来的配置,修改后再次发送Configuration Request。
Server向Client发送Configuration ack,标识接受客户端的加密协议。
PPP协议的CCP协商的开销为44+44+44+44+48+48=272字节。PPP协议的NCP协商。
NCP协议是PPP协议的网络控制协议,主要用来协商双方网络层接口参数,配置虚拟端口,分配IP,DNS等信息。IPCP是NCP基于TCP/IP的接口协商协议。Server和Client都要把自己的Miniport信息发送给对方。
Client把自己的Miniport信息,即无效数据通过Configuration Request发送给Server。
Server直接发送Termination ACK拒绝请求。
Server把自己的Miniport信息通过Configuration Request发送给Client。
Client接收Server的接口配置,向Server发送Configuration ACK,应答上一步骤的Request。
Client把自己的Miniport信息通过Configuration Request发送给Server。
Server发现Client的配置是无效的,直接发送Reject拒绝。
Client把自己的Miniport信息,等待Server分配,通过Configuration Request发送给Server。
Server发现Client的配置是无效的,则给Client发送一条有效的配置信息,使用Configuration Nak发送,其中主要是给Client分配ip。
Client根据Server端发送过来的配置,修改自己的Miniport的接口,再次发送Configuration Request。
Server接受Client的配置,发送Configuration Ack应答Request。
PPP协议的NCP协商的开销为字节:
68+38+44+48+68+54+60+60+60+60=560字节。
综上所述,本次PPTP控制连接建立的总开销为2809字节。
而UDP的开销要小于TCP的开销,在流量有限的情况,优选地,所述TCP连接替换为UDP连接。
详细地,所述建立数据连接为进行数据包封装,数据包封装是将应用层数据封装成IP数据包。
详细地,所述数据包封装包括:
步骤A:将IP数据包发送到VPN的虚拟接口;VPN的虚拟接口将IP数据包压缩和加密,并增加PPP头;
步骤B:VPN的虚拟接口将PPP帧发送给PPTP协议驱动单元;PPTP协议驱动单元在PPP帧外添加GRE报头;
步骤C:PPTP协议驱动单元将GRE报头提交给TCP/IP协议驱动单元;TCP/IP协议驱动单元为GRE驱动添加IP头部,这是第三步封装,是三层封装;
步骤D:IP数据包进行数据链路层封装后通过路由器中的物理网卡发送,依据不同的外发物理网络再添加相应的数据链路层报头和报尾。如果IP数据报将在以太网上传输,则用以太网报头和报尾对IP数据报进行数据链路层封装;如果IP数据报将在点对点WAN上传输,如模拟电话或ISDN等,则用PPP报头和报尾对IP数据报进行数据链路层封装。
尽管上面对本发明说明性的具体实施方式进行了描述,以便于本技术领域的技术人员能够理解本发明,但是本发明不仅限于具体实施方式的范围,对本技术领域的普通技术人员而言,只要各种变化只要在本发明精神和范围内,一切利用本发明构思的发明创造均在保护之列。
Claims (6)
1.一种移动互联网医疗系统,其特征在于:所述移动互联网医疗系统包括至少一个移动用户终端、一个医院信息收录单元以及中心服务器;所述移动用户终端与服务器,医院信息收录单元与服务器均通过PPTP方法进行IP网络通信,所述移动用户终端、医院信息收录单元及服务器内均处设有物理网卡,物理网卡连接有路由器;
所述PPTP方法包括建立控制连接以及建立数据连接;所述移动互联网医疗系统还包括与中心服务器连接的第三方支付平台,第三方支付平台还与移动用户终端建立IP网络通信;
所述中心服务器还设有RTC模块,RTC模块用于对移动用户终端的业务请求进行排序确定优先级;
所述医院信息收录单元用于采集医院各科室的实时业务信息给中心服务器;
所述移动用户终端用于向服务器发起业务请求。
2.根据权利要求1所述的移动互联网医疗系统,其特征在于:所述业务请求包括用户注册、用户登录、用户推出、医院就诊信息查询、预约挂号、排队就医、缴纳费用及提交评价。
3.根据权利要求1所述的移动互联网医疗系统,其特征在于:所述控制连接包括:步骤a:建立TCP连接,步骤b:PPTP控制连接和GRE隧道建立,步骤c:进行PPP协议的LCP协商,步骤d:进行PPP协议的身份验证,步骤e:进行PPP协议的NCP协商,步骤f:进行PPP协议的CCP协商。
4.根据权利要求3所述的移动互联网医疗系统,其特征在于:所述控制连接包括:所述TCP连接替换为UDP连接。
5.根据权利要求3或4所述的移动互联网医疗系统,其特征在于:所述建立数据连接为进行数据包封装,数据包封装是将应用层数据封装成IP数据包。
6.根据权利要求5所述的移动互联网医疗系统,其特征在于:所述数据包封装的过程包括:
步骤A:将IP数据包发送到VPN的虚拟接口;VPN的虚拟接口将IP数据包压缩和加密,并增加PPP头;
步骤B:VPN的虚拟接口将PPP帧发送给PPTP协议驱动单元;PPTP协议驱动单元在PPP帧外添加GRE报头;
步骤C:PPTP协议驱动单元将GRE报头提交给TCP/IP协议驱动单元;TCP/IP协议驱动单元为GRE驱动添加IP头部;
步骤D:IP数据包进行数据链路层封装后通过路由器中的物理网卡发送,依据不同的外发物理网络再添加相应的数据链路层报头和报尾。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710844238.6A CN107566507A (zh) | 2017-09-19 | 2017-09-19 | 一种移动互联网医疗系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710844238.6A CN107566507A (zh) | 2017-09-19 | 2017-09-19 | 一种移动互联网医疗系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN107566507A true CN107566507A (zh) | 2018-01-09 |
Family
ID=60980282
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710844238.6A Pending CN107566507A (zh) | 2017-09-19 | 2017-09-19 | 一种移动互联网医疗系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107566507A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116188180A (zh) * | 2023-04-25 | 2023-05-30 | 浩然加中医疗科技(山东)有限公司 | 一种基于gre网络的医保报销结算方法、系统及设备 |
CN117454856A (zh) * | 2023-12-22 | 2024-01-26 | 达州爱迦飞诗特科技有限公司 | 基于线上点对点模式的医疗诊断数据编辑方法和系统 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101018259A (zh) * | 2006-02-08 | 2007-08-15 | 中国电信股份有限公司 | 电信综合信息系统及方法 |
CN101360096A (zh) * | 2008-08-12 | 2009-02-04 | 中山爱科数字科技有限公司 | 一种应用于数字医疗的系统安全规划方案 |
CN102324084A (zh) * | 2011-09-20 | 2012-01-18 | 温州医学院眼视光研究院 | 医疗就诊手机预约引导支付系统 |
-
2017
- 2017-09-19 CN CN201710844238.6A patent/CN107566507A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101018259A (zh) * | 2006-02-08 | 2007-08-15 | 中国电信股份有限公司 | 电信综合信息系统及方法 |
CN101360096A (zh) * | 2008-08-12 | 2009-02-04 | 中山爱科数字科技有限公司 | 一种应用于数字医疗的系统安全规划方案 |
CN102324084A (zh) * | 2011-09-20 | 2012-01-18 | 温州医学院眼视光研究院 | 医疗就诊手机预约引导支付系统 |
Non-Patent Citations (1)
Title |
---|
王锋: "《Windows Server 2003服务器配置实用案例教程》", 30 September 2007 * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116188180A (zh) * | 2023-04-25 | 2023-05-30 | 浩然加中医疗科技(山东)有限公司 | 一种基于gre网络的医保报销结算方法、系统及设备 |
CN117454856A (zh) * | 2023-12-22 | 2024-01-26 | 达州爱迦飞诗特科技有限公司 | 基于线上点对点模式的医疗诊断数据编辑方法和系统 |
CN117454856B (zh) * | 2023-12-22 | 2024-04-16 | 达州爱迦飞诗特科技有限公司 | 基于线上点对点模式的医疗诊断数据编辑方法和系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109155757A (zh) | 混合接入网络中的多路径tcp | |
US8533473B2 (en) | Method and apparatus for reducing bandwidth usage in secure transactions | |
CN104125191B (zh) | 基于以太网的点对点协议的处理方法、设备和系统 | |
US8782772B2 (en) | Multi-session secure tunnel | |
EP1158730A2 (en) | Dynamic application port service provisioning for packet switch | |
US9088416B2 (en) | Method for securely associating data with HTTP and HTTPS sessions | |
CN102868609B (zh) | 一种最大传输单元协商方法及数据终端 | |
CN102843292B (zh) | 一种跨运营商网络的vpn数据处理方法及装置 | |
EP3930288B1 (en) | Multilayer tunneling of protocols over quic | |
CN104009972B (zh) | 网络安全接入的认证系统及其认证方法 | |
CN107426339A (zh) | 一种数据连接通道的接入方法、装置及系统 | |
CN102195878A (zh) | 经由流中间重新协商的代理ssl切换 | |
CN107968726B (zh) | 一种用于电力系统的设备网络管理方法 | |
CN101645883A (zh) | 数据传输方法、数据发送方法及数据接收方法 | |
CN103873449B (zh) | 网络接入方法与系统 | |
CN109936529A (zh) | 一种安全通信的方法、装置和系统 | |
CN108810023A (zh) | 安全加密方法、密钥共享方法以及安全加密隔离网关 | |
CN107566507A (zh) | 一种移动互联网医疗系统 | |
CN104993993B (zh) | 一种报文处理方法、设备和系统 | |
CN109906625A (zh) | 无线局域网上的安全链路层连接的方法 | |
CN106161224B (zh) | 数据交换方法、装置及设备 | |
CN109104744A (zh) | 利用wifi管理帧的数据发送、接收以及通信方法 | |
CN107453861A (zh) | 一种基于ssh2协议的数据采集方法 | |
CN111343083A (zh) | 即时通信方法、装置、电子设备及可读存储介质 | |
US20070071035A1 (en) | LAC-based LFI support for tunneled PPP sessions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180109 |