CN107071833A - 数据包传输***及方法 - Google Patents
数据包传输***及方法 Download PDFInfo
- Publication number
- CN107071833A CN107071833A CN201710396940.0A CN201710396940A CN107071833A CN 107071833 A CN107071833 A CN 107071833A CN 201710396940 A CN201710396940 A CN 201710396940A CN 107071833 A CN107071833 A CN 107071833A
- Authority
- CN
- China
- Prior art keywords
- packet
- application processor
- length
- data
- character
- 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.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种数据包传输***及方法,该***包括:移动终端和外接设备,移动终端包括第一应用处理器、第一调制解调器和第一射频模块,以及与所述第一调制解调器连接的嵌入式用户识别卡和实体用户识别卡,外接设备包括第二应用处理器、第二调制解调器和第二射频模块;第一应用处理器通过预设接口接收第二应用处理器发送的数据包获取请求时,从嵌入式用户识别卡或实体用户识别卡中提取对应的数据包;对提取的数据包进行压缩以缓存至预设接口的临时缓冲区buffer中,以供第二应用处理器从buffer中提取压缩后的数据包,以完成数据包的传输。本发明避免了数据包传输过程由于包容量值过大导致终端死机的情况。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种数据包传输***及方法。
背景技术
随着移动通信技术的发展,越来越多的移动终端如智能手机具有双卡双通的功能,使得用户在实现语音业务的待机同时,能建立数据业务连接。移动终端通常具有两个用户识别卡以及分别与所述两个用户识别卡连接的调制解调器,两个用户识别卡全开时,一个用户识别卡(SIM1)可以使用4G(the 4th Generation Mobile CommunicationTechnology,***移动通信技术),例如LTE(Long Term Evolution,长期演进技术)网络,另一个用户识别卡(SIM2)仅能使用2G(2-Generation wireless telephone technology,第二代手机通信技术规格)或3G(3rd Generation,第三代移动通信技术)网络,SIM2不能上4G的原因主要是:移动终端只有一套射频,两张卡使用该套射频是分时复用的关系,并不能同时占用,由于两张卡全开时,只有一张卡可以使用4G网络,另一张卡只能使用2G或3G网络,导致移动终端中数据传输的效率较低。
因此,为了使移动终端可以支持双LTE,以提高数据传输效率,移动终端可与外接设备连接(该外接设备中设置有调制解调器),以实现双LTE通信功能。但是,目前移动终端和外接设备进行数据包传输过程中,如果移动终端中的用户识别卡是电信卡,由于电信卡一般都大于移动终端和外接设备之间数据传输的临时缓冲区buffer的容量值,因此buffer无法缓存一个完整的数据包,若是直接进行数据传输,容易导致移动终端死机。
发明内容
本发明的主要目的在于提出一种数据包传输***及方法,旨在解决现有的数据包传输方式,容易导致移动终端死机的技术问题。
为实现上述目的,本发明提供的一种数据包传输***,所述数据包传输***包括移动终端,以及通过预设接口与所述移动终端连接的外接设备,所述移动终端包括第一应用处理器、第一调制解调器和第一射频模块,以及与所述第一调制解调器连接的嵌入式用户识别卡和实体用户识别卡,所述外接设备包括第二应用处理器、第二调制解调器和第二射频模块;
所述第一应用处理器,用于通过预设接口接收第二应用处理器发送的数据包获取请求时,从嵌入式用户识别卡或实体用户识别卡中提取所述数据包获取请求对应的数据包;对提取的数据包进行压缩;将压缩后的数据包缓存至所述预设接口的临时缓冲区buffer中,以供第二应用处理器从所述buffer中提取压缩后的数据包,以完成数据包的传输。
可选地,所述第一应用处理器,还用于判断能否从所述数据包获取请求中提取出第二应用处理器添加的压缩标识;若能提取出压缩标识,则对提取的数据包进行压缩。
可选地,所述第一应用处理器,还用于对提取的所述数据包进行解析,以得到所述数据包的包头;基于所述数据包的包头确定所述数据包的长度;在所述数据包的长度大于预设阈值时,则对提取的数据包进行压缩。
可选地,所述第一应用处理器对提取的数据包进行压缩具体包括:
所述第一应用处理器获取所述数据包对应的源文本;
确定源文本中出现频率大于预设频率的字符段;
在预设字典列表中,查找所述字符段对应的编码,其中,编码的长度小于对应的字符段的长度;
通过查找的编码代替对应的字符段,以实现数据包的压缩。
可选地,所述第一应用处理器,还用于确定源文本中是否存在内容相同且长度大于预设值的字符段;
若存在,确定后一个字符段与前一个字符端的距离以及所述字符段的长度;
采用距离与长度的标识代替后一个字符段,以实现数据包的压缩。
此外,为实现上述目的,本发明还提出一种数据包传输方法,应用于移动终端以及通过预设接口与移动终端连接的外接设备,所述移动终端包括第一应用处理器、第一调制解调器和第一射频模块,以及与所述第一调制解调器连接的嵌入式用户识别卡和实体用户识别卡,所述外接设备包括第二应用处理器、第二调制解调器和第二射频模块,所述方法包括:
第一应用处理器通过预设接口接收第二应用处理器发送的数据包获取请求时,从嵌入式用户识别卡或实体用户识别卡中提取所述数据包获取请求对应的数据包;
对提取的数据包进行压缩;
将压缩后的数据包缓存至所述预设接口的临时缓冲区buffer中,以供第二应用处理器从所述buffer中提取压缩后的数据包,以完成数据包的传输。
可选地,所述对提取的数据包进行压缩的步骤之前,所述数据包传输方法还包括:
所述第一应用处理器判断能否从所述数据包获取请求中提取出第二应用处理器添加的压缩标识;
若能提取出压缩标识,则执行所述对提取的数据包进行压缩的步骤。
可选地,所述对提取的数据包进行压缩的步骤之前,所述数据包传输方法还包括:
所述第一应用处理器对提取的所述数据包进行解析,以得到所述数据包的包头;
基于所述数据包的包头确定所述数据包的长度;
在所述数据包的长度大于预设阈值时,执行所述对提取的数据包进行压缩的步骤。
可选地,所述对提取的数据包进行压缩的步骤包括:
所述第一应用处理器获取所述数据包对应的源文本;
确定源文本中出现频率大于预设频率的字符段;
在预设字典列表中,查找所述字符段对应的编码,其中,编码的长度小于对应的字符段的长度;
通过查找的编码代替对应的字符段,以实现数据包的压缩。
可选地,所述第一应用处理器获取所述数据包对应的源文本的步骤之后,所述对提取的数据包进行压缩的步骤还包括:
确定源文本中是否存在内容相同且长度大于预设值的字符段;
若存在,确定后一个字符段与前一个字符端的距离以及所述字符段的长度;
采用距离与长度的标识代替后一个字符段,以实现数据包的压缩。
本发明提出的数据包传输***及方法,所述数据包传输***包括移动终端,以及通过预设接口与所述移动终端连接的外接设备,所述移动终端包括第一应用处理器、第一调制解调器和第一射频模块,以及与所述第一调制解调器连接的嵌入式用户识别卡和实体用户识别卡,所述外接设备包括第二应用处理器、第二调制解调器和第二射频模块;所述第一应用处理器通过预设接口接收第二应用处理器发送的数据包获取请求时,先从嵌入式用户识别卡或实体用户识别卡中提取所述数据包获取请求对应的数据包,然后对提取的数据包进行压缩,再将压缩后的数据包缓存至所述预设接口的buffer中,以供第二应用处理器从所述buffer中提取压缩后的数据包,以完成数据包的传输。本方案在传输数据包时,先对待传输的数据包进行压缩,再将压缩后的数据包进行传输,使得传输的数据包的容量值有所减小,避免了数据传输过程中移动终端死机的情况。
附图说明
图1为本发明一实施例的LTE网络架构的示意图;
图2为本发明实施例中移动终端和外接设备通讯连接的一种通讯连接的实体示意图;
图3为本发明实施例中移动终端和外接设备通讯连接的一种硬件结构示意图;
图4为本发明第一应用处理器和第二应用处理器之间的交互示意图;
图5为本发明数据包传输方法第一实施例的流程示意图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做说明。
具体实施方式
应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。需要说明的是,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互任意结合。
为了对本发明的技术特征、目的和效果有更加清楚的理解,现对照附图详细说明本发明的具体实施方式。
图1是本发明一实施例的LTE(Long Term Evolution,长期演进)网络架构的示意图。本发明一实施例的LTE网络架构包括:一个或多个移动终端(user equipment,UE)100、外接设备200、E-UTRAN(Evolved UMTS Terrestrial Radio Access Network,演进的UMTS陆地无线接入网)(图中未标号)、演进分组核心(EPC)(图中未标号)、归属订户服务器(HSS)107、网络(例如,因特网)(图中未标号)以及电路交换***(图中未标号)。
E-UTRAN包括演进B节点(eNodeB)101和其它eNodeB 102。eNodeB 101提供朝向移动终端100的用户面和控制面的协议终接。eNodeB 101可经由X2接口连接到其他eNodeB。eNodeB 101也可称为基站、基收发机站、无线电基站、无线电收发机、收发机功能、基本服务集、扩展服务集、或其他某个合适的术语。eNodeB 101为移动终端100提供去往EPC的接入点。
eNodeB 101通过S1接口连接到EPC。EPC包括移动管理实体(EEM)104、其他移动管理实体106、服务网关103,以及分组数据网络(PDN)网关105。移动管理实体104是处理移动终端100与EPC之间的信令的控制节点。移动管理实体104提供承载和连接管理。所有用户IP分组通过服务网关103来传递,服务网关103自身连接到PDN网关105。PDN网关105提供UE IP地址分配以及其他功能。PDN网关105连接到网络,例如,因特网。
电路交换***包括交互解决方案模块(IWS)108、移动交换中心(MSC)109、基站110和移动站111。在一个方面,电路交换***可以通过IWS和MME(Mobility ManagementEntity,移动管理实体)与EPS(Evolved Packet System,演进的分组***)进行通信。
移动终端100通过预设接口,如USB(Universal Serial Bus,通用串行总线)数据线300与外接设备200通讯连接。
图2为本发明移动终端100和外接设备200通讯连接的实体示意图。
如图2所示,移动终端100通过USB数据线300与外接设备200通讯连接,其中,所述移动终端包括但不限于手机、PC(Personal Computer,个人电脑)或PAD(Personal DigitalAssistant,个人数字助理),所述外接设备200可选为无线上网卡或数据卡。
图3为本发明移动终端100和外接设备200通讯连接的结构示意图。
本发明实施例的移动终端100通过USB数据线300与外接设备200通讯连接,基于移动终端100和外接设备200通讯连接的基础,移动终端100可支持双LTE。具体地:
移动终端100包括第一处理芯片001,以及与所述第一处理芯片001连接的第一射频模块12,其中,第一处理芯片001包括第一应用处理器(Application Processor,用AP1表示)10、与嵌入式用户识别卡13和实体用户识别卡14连接的第一调制解调器11(modem1)、RPM(Resource Power Manager,资源电源管理器)15。
其中,所述嵌入式用户识别卡13通过串口与第一调制解调器11连接,串口包括但不限于通用异步收发传输器(UART),需要说明的是,嵌入式用户识别卡13为ESIM(EmbeddedSubscriber Identity Module)卡,相关卡参数直接写入该ESIM卡,该ESIM卡包含可编程的SIM卡芯片;该嵌入式用户识别卡13包括存储模块和片内操作***(Chip OperatingSystem,COS),该存储模块可为EFS(Encrypting File System,加密文件***),存储模块用于存储嵌入式用户识别卡13的鉴权数据。所述实体用户识别卡14为SIM(SubscriberIdentity Module,用户识别模块)卡
外接设备200包括第二处理芯片002,以及与所述第二处理芯片002连接的第二射频模块22,其中,第二处理芯片002包括第二应用处理器(用AP2表示)20和第二调制解调器(modem2)21。
第一应用处理器10和第二应用处理器20的内部框架包括应用层、框架层等,可处理复杂的逻辑操作以及进行任务分配等。在一个实施例中,应用处理器指Android操作***,以及基于Android操作***的各种apk(Android Package,安卓安装包)。在本发明的实施例中,第一应用处理器10和第二应用处理器20通过USB数据线实现通讯连接,为用户提供交互接口,将用户输入的操作指令(例如,用户通过用户界面输入的有关启动视频通话的操作指令)传输给第一调制解调器11或第二调制解调器21,以实现两个应用处理器之间数据的定义与传递,例如,进行两个应用处理器的休眠、唤醒、同步的控制、开关机时芯片启动顺序的控制等。
应当理解的是,在本发明实施例中,USB数据线300复用出三条数据通道,分别用于第一应用处理器10和第二应用处理器20之间用户数据、控制信令数据和SIM卡鉴权数据的交互,即第一应用处理器10和第二应用处理器20通过USB数据线300传输的数据包括上述三种数据。其中,用户数据包括上网产生的数据,图片和聊天信息数据;控制信令数据包括开关机的控制数据,开关飞行模式的控制数据,显示状态信号的控制数据;SIM卡鉴权数据包括但不限于IMSI(International Mobile Subscriber Identification Number,国际移动用户识别码)、Ki(key identifier,鉴权密钥)等等。
本实施例中,第一应用处理器10和第二应用处理器20通过OTG(On-The-Go)技术进行数据交互。通过OTG技术,移动终端100中的第一调制解调器11可通过嵌入式用户识别卡13或实体用户识别卡14中的SIM卡参数来接入eNodeB 101,外接设备中的第二调制解调器21可通过实体用户识别卡14或嵌入式用户识别卡13中的SIM卡参数来接入eNodeB 101,所述SIM卡参数包括但不限于SIM卡鉴权数据。其中,USB接口的buffer存在于第一应用处理器10和第二应用处理器20的两端,用buffer1和buffer2表示。需要说明的是,buffer1和buffer2对应着同一个物理地址,通过该物理地址,可控制buffer1和buffer2容量值和状态的同步变化。
由于buffer1和buffer2对应着同一个物理地址,因此第一应用处理器10将提取的数据包缓存至buffer1时,数据包通过该UART发送至buffer2中缓存,第二应用处理器20在buffer2中检测到该数据包时,即可获取到该数据包,以实现数据包的传输。
第一调制解调器11和第二调制解调器21包含各种网络交互的网络制式的协议栈,协议栈包含LTE(Long Term Evolution,长期演进)/WCDMA(Wideband Code DivisionMultiple Access,宽带码分多址)/GSM(Global System for Mobile Communication,全球移动通信***)/TD-SCDMA(Time Division-Synchronous Code Division MultipleAccess,同步时分码分多址)/CDMA(Code Division Multiple Access,码分多址)/EDGE(Enhanced Data Rate for GSM Evolution,强型数据速率GSM演进技术)等通讯标准里边规定的协议代码。移动终端100通过协议与运营商网络进行交互,即进行数据流量上网、VOLTE(Voice Over LTE)打电话或者CS(Circuit Switched,电路交换)域打电话。第一调制解调器11和第二调制解调器21还用于对SIM卡的管控等等。
在本发明实施例中,第一射频模块12用于将移动终端100传输的数据处理后传给eNodeB 101(基站网络),以及用于将eNodeB 101传输的数据处理后传给移动终端100。第二射频模块22用于将外接设备200传输的数据处理后传给eNodeB 101(基站网络),以及用于将eNodeB 101传输的数据处理后传给外接设备200。
第一射频模块12和第二射频模块22所涉及的无线接入技术可以包括LTE、GSM、GPRS(General Packet Radio Service,通用分组无线服务)、CDMA、EDGE、WLAN(WirelessLocal Area Networks,无线局域网)、CDMA-2000、TD-SCDMA、WCDMA、WIFI(WirelessFidelity,无线保真)等等。
移动终端100中的嵌入式用户识别卡13和实体用户识别卡14与第一调制解调器11连接,嵌入式用户识别卡13和实体用户识别卡14存储不同的无线通信标准相关联用户信息。应当理解,目前的移动终端只有一套射频,移动终端内部的两个用户识别卡使用该套射频是分时复用的关系,并不能同时占用。例如,在两张用户识别卡全开时,一张卡可以处理GSM通话,另一张卡只能处理4G网络信息,具体哪个用户识别卡执行何种网络,不做限定。因此目前的射频双卡分时复用这种架构仅做到了LTE+GSM(即一张用户识别卡对应的技术标准为LTE,另一张用户识别卡对应的技术标准为GSM)。
也就是说,现有的移动终端100虽然可以支持双用户识别卡,但是移动终端100在注册网络的情况下,两个用户识别卡支持的是不同技术标准的网络,一个支持2G或3G,另一个支持4G,会使得移动终端100使用过程中,上网流量速度较慢,因此本发明中,移动终端100通过USB数据线300连接外接设备200,由于外接设备200包括第二射频模块22,且第二射频模块22支持4G网络,因此,移动终端100可通过USB线300与外接设备200交互,使得嵌入式用户识别卡13可通过第二调制解调器21支持LTE,而实体用户识别卡14通过第一调制解调器11支持LTE,或者是嵌入式用户识别卡13可通过第一调制解调器11支持LTE,而实体用户识别卡14通过第二调制解调器21支持LTE,从而使得移动终端100具备双LTE功能。
在本实施例中,数据包传输***包括移动终端100和外接设备200,移动终端100通过外接设备200具备双LTE功能的实现过程可为:①实体用户识别卡14通过第二调制解调器21支持LTE,具体过程为:第一调制解调器11将实体用户识别卡14中需要访问LTE网络的数据发送给第一应用处理器10,第一应用处理器10将所接收的数据通过USB发送给外接设备200的第二应用处理器20,第二应用处理器20将所接收的数据发送给第二调制解调器21,由第二调制解调器21转发给第二射频模块22,第二射频模块22将所接收的数据通过LTE网络发送出去;而嵌入式用户识别卡13通过第一调制解调器11支持LTE,以实现移动终端100可支持双LTE。②嵌入式用户识别卡13通过第二调制解调器21支持LTE,具体过程为:第一应用处理器10将嵌入式用户识别卡13中需要访问LTE网络的数据通过USB发送给外接设备200的第二应用处理器20,第二应用处理器20将所接收的数据发送给第二调制解调器21,由第二调制解调器21转发给第二射频模块22,第二射频模块22将所接收的数据通过LTE网络发送出去;而实体用户识别卡14通过第一调制解调器11支持LTE,以实现移动终端100可支持双LTE。
在本实施例中,嵌入式用户识别卡13和实体用户识别卡14用于提供移动通信业务(CS语音业务、PS数据业务和PS语音业务)所需的相关数据,并在其内部存储用户信息、短消息、执行鉴权算法和产生加密密匙等。
实体用户识别卡14与移动终端100交互时,移动终端100检测该实体用户识别卡14存在与否的信号只在开机瞬时产生,当开机检测不到实体用户识别卡14存在时,移动终端100将提示“***用户识别卡”。移动终端100开机之后,移动终端100和实体用户识别卡14之间28秒通信一次,完成一些固定的通信检查(例如,用户识别卡是否在位等)。
需要说明的是,当嵌入式用户识别卡13需要进行网络注册时,通过开启的无线保真(WIFI)网络发送包含业务菜单数据的下载请求至嵌入式用户识别卡13对应的云端服务器,以从云端服务器获取嵌入式用户识别卡13的数据信息。当获取到嵌入式用户识别卡13的数据信息时,将数据信息写入嵌入式用户识别卡13的存储模块中,以实现嵌入式用户识别卡13的网络注册。其中,数据信息可以包括:IMSI、Ki(key identifier,鉴权密钥)、ICCID(Integrated Circuit Card Identifier)、PIN(个人标识号,Personal IdentificationNumber)、PUK(PIN Unlocking Key)。可以理解的是,云端服务器中存储了各个运营商的***资源。
在本发明的实施例中,嵌入式用户识别卡13和实体用户识别卡14承载信息,并且根据外界请求返回对应卡参数,以及对网络进行鉴权运算,第一射频模块12和第二射频模块22所涉及的无线接入技术为LTE。当移动终端100通过USB数据线300与外接设备200连接时,嵌入式用户识别卡13可通过第二调制解调器21支持LTE,而实体用户识别卡14通过第一调制解调器11支持LTE;或者嵌入式用户识别卡13可通过第一调制解调器11支持LTE,而实体用户识别卡14通过第二调制解调器21支持LTE,以实现移动终端100可支持双LTE。
移动终端100中的RPM15用于管控各种资源,包括时钟资源、总线资源、PMIC(PowerManagement IC,电源管理集成电路,即各个芯片的电压)、DDR(内存分配),以及管理芯片的休眠唤醒的中断和应用处理器唤醒的截止时间。移动终端100的各个子***,在需要资源时,向RPM15申请资源,各个子***分别包括第一应用处理器10,第一调制解调器11、PRONTO(WIFI/蓝牙、NFC(Near Field Communication,近场通信)等)、LPASS(Low power audiosubsystem,低功耗音频子***),RPM15用来决定移动终端100***的休眠状态,具体是,RPM15基于各个子***的投票机制实现,当各个子***都投休眠票时,RPM15才可以使移动终端100整个***进行休眠。
在移动终端100的整个***休眠之后,若是要重新启动运行,需要唤醒第一应用处理器10以进行数据的传输交互。
在移动终端100和外接设备200通过USB数据线300通讯连接的情况下,唤醒方式包括三种:
1、第一应用处理器10接收到控制信令数据时,通过USB数据线300传送探测包给第二应用处理器20,以唤醒第二应用处理器20。
2、外接设备200的第二调制解调器21接收到用户数据时,唤醒第二应用处理器20,由第二应用处理器20通过USB数据线300传送探测包给第一应用处理器10,以唤醒第一应用处理器10。
3、第二调制解调器21周期性查找寻呼请求,以主动激活自己,若接收到寻呼请求,唤醒第二应用处理器20,由第二应用处理器20通过USB数据线300发送探测包给第一应用处理器10,以唤醒第二应用处理器20。
此外,第二调制解调器21还可以定期唤醒自己,以在移动终端100进行位置更新时,跟基站进行握手交互,此时不需要唤醒第一应用处理器10。
需要说明的是,传输的数据包为用户数据、控制信令数据或用户识别卡数据即SIM卡数据时,三种数据都在应用处理器之间传输。
本实施例中,SIM卡包括移动卡、联通卡和电信卡,其中,移动卡和联通卡是指采用3GPP标准协议进行通讯的电话卡,3GPP标准协议规定了电话卡传输数据包的容量不能超出一定值,该值设置为512个字节;而电信卡是指采用3GPP2标准协议的电话卡,GPP2标准协议对电信卡传输的数据包的容量未做限制,电信卡传输的数据包的容量一般会超出512字节。其中,移动卡是由***(运营商)向用户提供的SIM卡,联通卡是由***(运营商)向用户提供的SIM卡,电信卡是由中国电信(运营商)向用户提供的SIM卡。
由于现有的buffer的容量一般都不超过512个字节。因此,当移动终端100中的嵌入式用户识别卡13和实体用户识别卡14都是移动卡或者是联通卡时,由于移动卡或者是联通卡收发数据包的数据容量小于512个字节的,因此,第一应用处理器10接收到数据包获取请求时,从嵌入式用户识别卡13和实体用户识别卡14获取到的数据包也是小于512个字节,相应的,存储到buffer的数据包也是小于512个字节的,因此,数据包可完整的存储到buffer中,后续,第二应用处理器20也可以取出一个完整的数据包。
但是,由于电信卡一般大于512字节,因此,在第一应用处理器10和第二应用处理器20的数据交互过程中,若是第一应用处理器10中连接的是电信卡,会出现这样的情况:
以图3为例,在嵌入式用户识别卡13和实体用户识别卡14为电信卡的情况下,移动终端100第一应用处理器10通过第一调制解调器11从嵌入式用户识别卡13中或实体用户识别卡14提取出一个数据包,由于该数据包大于512字节,而buffer一次性只能缓存不超过512字节的数据包,这种情况下,会由于无法转发大数据包导致移动终端的***死机。
若是要解决这个问题,按照常规的思路,不会将该数据包一次性进行转发,而是拆分成多个数据包进行转发,但是对于第二应用处理器20而言,当从buffer检测到有数据包时,认为该数据包是完整的数据包,此时第二应用处理器20直接从buffer获取该数据包,并将该数据包转发至基站。很明显,这种情况下,转发的数据包是不完整的数据包。
基于上述LTE网络的架构图、以及移动终端100和外接设备200通讯连接的结构示意图,提出本发明的各个实施例。
参照图3,本实施例提出一种数据包传输***,所述数据包传输***包括移动终端100,以及通过预设接口与所述移动终端100连接的外接设备200,所述移动终端100包括第一应用处理器10、第一调制解调器11和第一射频模块12,以及与所述第一调制解调器11连接的嵌入式用户识别卡13和实体用户识别卡14,所述外接设备200包括第二应用处理器20、第二调制解调器21和第二射频模块22;
所述第一应用处理器10,用于通过预设接口接收第二应用处理器20发送的数据包获取请求时,从嵌入式用户识别卡13或实体用户识别卡14中提取所述数据包获取请求对应的数据包;对提取的数据包进行压缩;将压缩后的数据包缓存至所述预设接口的临时缓冲区buffer中,以供第二应用处理器20从所述buffer中提取压缩后的数据包,以完成数据包的传输。
在本实施例中,所述第一应用处理器10通过预设接口接收第二应用处理器20发送的数据包获取请求,后续也是通过所述预设接口将数据包反馈至所述第二应用处理器20。所述预设接口为USB接口。
其中,当第二处理芯片002的第二调制解调器21通过第二射频模块22接收到基站发送的数据包获取请求时,将数据包获取请求发送至第二处理芯片002的第二应用处理器20中,当第二应用处理器20接收到数据包获取请求时,先通过USB数据线300将数据包获取请求传送至移动终端100的第一应用处理器10中;第一应用处理器10接收到该数据包获取请求时,将数据包获取请求传送至移动终端100的第一调制解调器11中,由第一调制解调器11根据该数据包获取请求从嵌入式用户识别卡13或实体用户识别卡14中获取数据包;第一调制解调器11获取到数据包之后,将数据包传输至第一应用处理器10中;第一应用处理器10获取到数据包之后,为了保证传输的数据不会大于USB的buffer,先对获取的数据包进行压缩,得到压缩后的数据包;再通过USB将压缩后的数据包传送至第二应用处理器20;第二应用处理器20在接收到数据包后,再将数据包传送至第二射频模块22,由第二射频模块22将数据包上传至基站,以完成数据的传输。
具体地,所述第一应用处理器10,还用于通过第一调制解调器11向嵌入式用户识别卡13或实体用户识别卡14中的片内操作***发送数据包获取请求,由所述片内操作***在嵌入式用户识别卡13或实体用户识别卡14中的文件存储模块中提取所述数据包获取请求对应的数据包,并反馈至所述第一调制解调器11;
所述第一应用处理器10,还用于通过第一调制解调器11接收片内操作***反馈的数据。
在本实施例中,需要说明的是,嵌入式用户识别卡13或实体用户识别卡14中的数据包存储在文件存储模块中,当第一调制解调器11要获取嵌入式用户识别卡13或实体用户识别卡14中的数据包时,第一调制解调器11不会直接与嵌入式用户识别卡13或实体用户识别卡14中的文件存储模块交互,而是先向嵌入式用户识别卡13或实体用户识别卡14中的COS(Chip Operating System,片内操作***)操作***发送数据包获取请求即Request,然后嵌入式用户识别卡13或实体用户识别卡14的COS操作***基于该Request在文件存储模块中获取数据包,然后将获取的数据包再传输给第一调制解调器11,第一调制解调器11只要接收COS操作***反馈的数据包即可,后续第一应用处理器10在第一调制解调器11中获取数据包即可实现数据包的获取过程。
可以理解,由于第一调制解调器11无法在嵌入式用户识别卡13或实体用户识别卡14中的文件存储模块直接提取数据包,因此通过与嵌入式用户识别卡13或实体用户识别卡14的COS操作***进行交互,以实现数据包的提取,保证后续的数据传输过程正常运行。
当第一应用处理器10从嵌入式用户识别卡13或实体用户识别卡14中提取出数据包获取请求对应的数据包之后,再对提取的数据包进行压缩,本实施例中,第一应用处理器10对数据包进行压缩时,可以采用加密压缩的方式进行数据包的压缩,也可以直接采用明文进行压缩。由于传输的SIM卡网络鉴权数据量比较小,为了减少加密解密等操作而导致数据传输效率低,本发明实施例优选采用明文压缩的方式对数据包进行压缩,即本方案中采用的压缩算法以简单高效为主,具体采用的压缩算法和压缩过程在下文实施例中详述。
第一应用处理器10对数据包压缩之后,即可将压缩后的数据包缓存至所述预设接口USB的buffer中,以供第二应用处理器20从所述buffer中提取压缩后的数据包,以完成数据包的传输。
本实施例中需要说明的是,buffer存在于USB接口的两端,即USB接口的两端分别设置有buffer1和buffer2。当第二应用处理器20将数据包获取请求通过USB接口发送给第一应用处理器10时,第一应用处理器10通过第一调制解调器11从嵌入式用户识别卡13或实体用户识别卡14提取出数据包之后,先将提取的数据包存储到buffer1中,以通过USB传输至buffer2中,第二应用处理器20再从buffer2中获取数据包。
本实施例提出的技术方案,所述第一应用处理器通过预设接口接收第二应用处理器发送的数据包获取请求时,先从嵌入式用户识别卡或实体用户识别卡中提取所述数据包获取请求对应的数据包,然后对提取的数据包进行压缩,再将压缩后的数据包缓存至所述预设接口的buffer中,以供第二应用处理器从所述buffer中提取压缩后的数据包,以完成数据包的传输。本方案在传输数据包时,先对待传输的数据包进行压缩,再将压缩后的数据包进行传输,使得传输的数据包的容量值有所减小,避免了数据传输过程中移动终端死机的情况。
进一步地,基于第一实施例提出本发明数据包传输***第二实施例。
数据包传输***第二实施例与数据包传输***第一实施例的区别在于,所述第一应用处理器10,还用于判断能否从所述数据包获取请求中提取出第二应用处理器20添加的压缩标识;若能提取出压缩标识,则对提取的数据包进行压缩。
在本实施例中,当第二应用处理器20向第一应用处理器10发送数据包获取请求(Request)之前,为了防止传输的数据包过大,第二应用处理器20发送Request时,先确定是否需要在Request中添加压缩标识,若需要,则先在Request中添加一个压缩标识,如添加字段01,以告知第一应用处理器10对待发送的数据包进行压缩。
需要说明的是,由于待传输的数据是根据通讯协议标准确定的,因此,第二应用处理器20可以得知即将获取的数据包的数据类型和数据大小,那么,当第二应用处理器20发送Request之前,先判断当前待获取的数据包的大小,若待获取的数据包的大小超出了buffer的容量值,则第二应用处理器20在Request中添加压缩标识,以告知第一应用处理器10对待传输的数据包进行压缩,若第二应用处理器20判断待获取的数据包的大小未超出buffer的容量值,则直接发送Request即可,无需添加压缩标识。
在本实施例中,第二应用处理器20发送Request之前,对待获取的数据包的大小进行识别,仅在待获取的数据包超出buffer的容量值时,才在Request添加压缩标识,避免了所有的数据包获取请求都添加压缩标识,缩短了数据包传输的时间,提高了数据包传输的效率。
当第一应用处理器10通过预设接口(USB)接收第二应用处理器20发送的数据包获取请求时,先对所述数据包获取请求进行解析,以确定能否从所述数据包获取请求中提取出第二应用处理器20添加的压缩标识,若在所述数据包获取请求中提取出压缩标识,此时,所述第一应用处理器10即可对提取的数据包进行压缩,后续再将压缩后的数据包缓存至所述预设接口的buffer中1,并通过USB传输至buffer2中,以供第二应用处理器20从所述buffer2中提取压缩后的数据包,以完成数据包的传输。
在本实施例中,数据包传输过程是发生第一应用处理器10和第二应用处理器20唤醒之后,那么当第一应用处理器10和第二应用处理器20唤醒之后,若第二应用处理器20通过第二调制解调器21连接的第二射频模块22接收到基站发送的数据包获取请求,执行以下操作:
判断:先确定待获取的数据包的大小,以判断是否需要添加压缩标识;
决策:若待获取的数据包超过USB的buffer的容量,则在发送数据包获取请求之前,在数据包获取请求添加压缩标识;
发送:在数据包获取请求添加压缩标识之后,发送数据包获取请求。
第一应用处理器10通过USB接收到数据包获取请求时,执行以下操作:
提取:确定能否从数据包获取请求中提取出压缩标识,若能,则提取出压缩标识;
压缩:基于提取的压缩标识,对通过第一调制解调器11从嵌入式用户识别卡13或实体用户识别卡14提取的数据包进行压缩;
反馈:反馈压缩的数据包。
最终,第二应用处理器20通过USB接收第一应用处理器10反馈的数据包,以完成数据包传输过程。上述的操作过程,可参照图4。
需要说明的是,第二应用处理器20发送的是数据包获取请求,由于数据包获取请求一般都小于buffer的容量,因此可不对数据包获取请求进行压缩。
在本实施例中,第一应用处理器10在对数据包进行压缩之前,先判断能否从所述数据包获取请求中提取出第二应用处理器20添加的压缩标识,若能提取出压缩标识,才对数据包进行压缩,防止数据包小于buffer的容量时也进行压缩,以防止***资源的浪费,并且节省了数据包传输的时间,从而提高了数据包传输的效率。
进一步地,基于第一实施例提出本发明数据包传输***第三实施例。
数据包传输***第三实施例与数据包传输***第一实施例的区别在于,所述第一应用处理器10,还用于对提取的所述数据包进行解析,以得到所述数据包的包头;基于所述数据包的包头确定所述数据包的长度;在所述数据包的长度大于预设阈值时,则对提取的数据包进行压缩。
在本实施例中,所述第一应用处理器10对数据包进行压缩之前,先对从嵌入式用户识别卡13或实体用户识别卡14中提取的数据包进行解析,以得到所述数据包的包头,然后从包头中获取数据包的长度,以确定该数据包的大小。其中,数据包为TLV格式,TLV格式是BER(Basic Encoding Rules,基本编码规则)编码的一种,全称为Type(类型),Length(长度),Value(值),T字段表示数据包的类型,L字段表示数据包的长度、V字段用于存放数据包的内容。
本实施例中,该数据包的生成过程为:传输层获取到数据包对应的原始数据,并为原始数据添加传输层的数据包头,数据包头包括传输层数据类型和数据长度,得到初始数据包,并将初始数据包传输至传输复用层。当传输复用层接收到初始数据包后,为初始化数据包添加传输复用层的数据包头,数据包头包括复用层的数据类型和数据长度,得到数据包,并调用物理驱动层的发送接口将该数据包发送给物理层。后续,第一应用处理器10对提取的所述数据包进行解析,就是从物理层(物理传输介质)之上的物理驱动层检测数据包的包头,以解析得到数据包的大小(长度)。
当第一应用处理器10确定数据包的长度后,再判断该数据包的长度是否大于预设阈值(即buffer的容量值)。在本实施例中,所述预设阈值可选为512字节,在其它实施例中,也可以将所述预设阈值设置为其它长度,在此不再限定。当数据包的长度大于所述预设阈值时,为了防止数据包传输导致终端死机,所述第一应用处理器10对提取的数据包进行压缩。可以理解,若提取的数据包的长度小于预设阈值,所述第一应用处理器10可直接通过USB接口发送该数据包至第二应用处理器20。
在本实施例中,在对数据包进行压缩之前,所述第一应用处理器10对提取的所述数据包进行解析,以得到所述数据包的包头,再确定所述数据包的长度,仅在数据包的长度大于预设阈值时,才对提取的数据包进行压缩,从而提高了数据包压缩的准确性。
进一步地,基于第一至第三实施例提出本发明数据包传输***第四实施例。
数据包传输***第四实施例与数据包传输***第一至第三实施例的区别在于,所述第一应用处理器10对提取的数据包进行压缩具体包括:
所述第一应用处理器10获取所述数据包对应的源文本;
确定源文本中出现频率大于预设频率的字符段;
在预设字典列表中,查找所述字符段对应的编码,其中,编码的长度小于对应的字符段的长度;
通过查找的编码代替对应的字符段,以实现数据包的压缩。
在本实施例中,所述第一应用处理器10对数据包进行压缩,具体地,先获取数据包对应的源文本,然后确定源文本中出现频率大于预设频率的字符段,再从预设字典列表中,查找所述字符段对应的编码,其中,编码的长度小于对应的字符段的长度,最终通过查找的编码代替对应的字符段,以实现数据包的压缩。
该过程涉及的算法为字典算法,字典算法是最为简单的压缩算法之一。该字典算法把文本中出现频率大于预设一定值的单词或词汇组合做成一个对应的字典列表,并用特殊代码来表示这个单词或词汇,例如,当前的字典列表中:
00=Chinese
01=People
02=China
若当期数据包中的源文本为:I am a Chinese people,I am from China。那么,采用该字典算法,压缩后的编码为:I am a 00 01,I am from 02。
可以理解,压缩编码后的长度显著缩小,这样的编码专有名词或者固定组合较多的内容中,压缩效率十分显著,将预定的文本内容用字典中预定的编码映射替代,解压缩的时候执行反向还原即可。
进一步地,所述第一应用处理器10,还用于依次确定源文本中高四位为零且相邻的任两个字符段;
将所述任两个字符段的高四位进行删除,并将所述任两个字符段的低四位进行组合,以实现数据包的压缩。
即,所述第一应用处理器10获取到数据包对应的源文本之后,还可依次确定源文本中高四位为零且相邻的任两个字符段,再将任两个字符段的高四位进行删除,并将任两个字符段的低四位进行组合,以实现数据包的压缩。
该过程涉及的算法为固定位长算法(Fixed Bit Length Packing),这种算法是把文本用需要的最少的位来进行压缩编码。比如:八个十六进制数:1,2,3,4,5,6,7,8。转换为二进制为:00000001,00000010,00000011,00000100,00000101,00000110,00000111,00001000。每个数只用到了低4位,而高4位没有用到(全为0),因此对低4位进行压缩编码后得到:0001,0010,0011,0100,0101,0110,0111,1000。然后两两补充为8位字节得到:00010010,00110100,01010110,01111000。所以原来的八个十六进制数缩短了一半,得到4个十六进制数:12,34,56,78。
可以理解,通过这种组合方式,将需要用到的位数进行了缩小,使得数据包的容量有所减小,同理,解压时执行反响拆分添加组合即可。
进一步地,所述第一应用处理器10,还用于对源文本中连续出现的字符,采用重复次数加字符进行代替,以实现数据包的压缩。
即,所述第一应用处理器10获取到数据包对应的源文本之后,还可对源文本中连续出现的字符,采用重复次数加字符进行代替,以实现数据包的压缩。
该过程涉及的算法为RLE(Run Length Encoding,游程编码,又译行程长度编码)算法,这种压缩编码是一种变长的编码,RLE根据文本不同的具体情况会有不同的压缩编码变体与之相适应,以产生更大的压缩比率。具体地:
变体1:重复次数+字符
文本字符串:A A A B B B C C C C D D D D,编码后得到:3A 3B 4C 4D;通过该变体算法,即可将数据包终端文本字符串进行压缩。
变体2:特殊字符+重复次数+字符
文本字符串:A A A A A B C C C C B C C C,编码后得到:B B 5A B B 4C B B3C;其中,该编码串的最开始说明特殊字符为B,然后再添加一个B,B后面跟着的数字就表示出重复的次数。也就是说,文本串字符采用该变体2算法进行编码压缩时,先在编码后的编码串的首字母说明特殊字符为B,然后由于后面紧接着出现5个字符A,需要在这5个字符A之前添加一个特殊字符即字符B,因此就是B B 5A,在5A之后出现B,且B之后又出现3个C,因此,需要在3个C之前再添加一个特殊字符B,与前面连接起来就是B B 5AB B 4C,后面采用同样的方式,即可得到最终的编码串B B 5A B B 4C B B 3C。
为了更清楚理解该方案,举另一个例子:文本字符串仍然为:A A A A A B C C CC B C C C,若当前编码串的最开始说明特殊字符为D,那么,编码后得到:D D 5A B D 4C BD 3C。
变体3:
把文本每个字节分组成块,每个字符最多重复127次。每个块以一个特殊字节开头。那个特殊字节的第7位如果被置位,那么剩下的7位数值就是后面的字符的重复次数。如果第7位没有被置位,那么剩下7位就是后面没有被压缩的字符的数量。
例如:文本字符串:A A A A A B C D E F F F,编码后得到:85A 4B C D E 83F(85H=10000101B、4H=00000100B、83H=10000011B)。其中,先将文本字符串分组成三个块,分别是A A A A A、B C D E和F F F,三个快对应的特殊字符分别是10000101、00000100和10000011,由于10000101中第7位被置位为1,因此剩下的7位数值为后面的字符的重复次数,此时可知剩下的7位数值对应的值为5,即可得到85A;同理,由于00000100中的第7位没有被置位为1,那么剩下7位是后面没有被压缩的字符的数量,可知此时剩下7位对应的值为4,即可得到4B C D E;同理可确定83F,此处不在赘述。
需要说明的是,以上所列举出的三种3种RLE变体算法仅仅是较佳的几种变体算法,本领域技术人员利用本发明的技术思想,根据其具体需求所提出的其它RLE变体算法均在本发明的保护范围内,在此不进行一一穷举。
进一步地,所述第一应用处理器10,还用于确定源文本中是否存在内容相同且长度大于预设值的字符段;
若存在,确定后一个字符段与前一个字符端的距离以及所述字符段的长度;
采用距离与长度的标识代替后一个字符段,以实现数据包的压缩。
即,所述第一应用处理器10获取到数据包对应的源文本之后,还可确定源文本中是否存在内容相同且长度大于预设值的字符段,若存在,确定后一个字符段与前一个字符端的距离以及字符段的长度,采用距离与长度的标识代替后一个字符段,以实现数据包的压缩。
该过程涉及的算法为LZ77(由Jacob Ziv和Abraham Lempel于1977年提出,所以命名为LZ77)算法。
LZ77算法的压缩原理:如果文件中有两块字符串内容相同的话,那么只要知道前一块字符串内容的位置和大小,我们就可以确定后一块字符串的内容。所以我们可以用(两块字符串之间的距离,相同内容的长度)这样一对信息,来替换后一块字符串内容。由于(两块字符串之间的距离,相同内容的长度)这一对信息的大小,小于被替换内容的大小,所以文件得到了压缩。
为更好理解,下面我们来举一个例子:
有一个文件的内容如下:http://jiurl.yeah.net http://jiurl.nease.net,其中有些部分的内容,前面已经出现过了,后面用()括起来的部分就是相同的部分:http://jiurl.yeah.net(http://jiurl.)nease(.net)。
我们使用(两块字符串之间的距离,相同内容的长度)这样一对信息,来替换后一块字符串内容,得到http://jiurl.yeah.net(22,13)nease(23,4)。
(22,13)中,22表示后一块http://jiurl.与前一块http://jiurl.中任意两个相同字符之间的距离,如后一个h与前一个h的距离;13为相同内容的长度;(23,4)同理,此处不再赘述。
从上述例子中可看出,由于(两块字符串之间的距离,相同内容的长度)这一对信息的大小,小于被替换内容的大小,所以文件得到了压缩。
具体地,LZ77算法使用滑动窗口寻找匹配串:
即LZ77算法使用"滑动窗口"的方法,来寻找文件中的相同部分,文件中相同部分即匹配串。首先,对匹配串做一个说明,匹配串是指一个任意字节的序列,不仅仅是可以在文本文件中显示出来的那些字节的序列,还可以是包括标点符号的序列。这里的串强调的是它在文件中的位置,它的长度随着匹配的情况而变化。具体地:
LZ77从文件的开始处开始,一个字节一个字节的向后进行处理。本发明实施例中,滑动窗口的长度是固定的,该滑动窗口的终止位置在当前处理字节之前,并且紧挨着当前处理字节,随着处理的字节不断的向后滑动,就象在阳光下,飞机的影子滑过大地一样。对于文件中的每个字节,用当前处理字节开始的串,和窗口中的每个串进行匹配,以寻找最长的匹配串。
窗口中的每个串指窗口中每个字节开始的串。如果当前处理字节开始的串在窗口中有匹配串,就用(之间的距离,匹配长度)这样一对信息,来替换当前串,然后从刚才处理完的串之后的下一个字节,继续处理。如果当前处理字节开始的串在窗口中没有匹配串,就不做改动的输出当前处理字节。
处理文件中第一个字节的时候,窗口在当前处理字节之前,也就是还没有滑到文件上,这时窗口中没有任何内容,被处理的字节就会不做改动的输出。随着处理的不断向后,窗口越来越多的滑入文件,最后整个窗口滑入文件,然后整个窗口在文件上向后滑动,直到整个文件结束。
需要说明的是,匹配串的长度有所限制,即本实施例中,设置了最小匹配串和最大匹配串,必须限制通过滑动窗口匹配出来的字符串大于该最小匹配串并且小于该最大匹配串,才会进行压缩,若是匹配出来的字符串小于该最小匹配串,或大于该最大匹配串,则不会进行后续的压缩操作。
为更好理解本实施例,举例如下:
假设文本字符串为:A A A B A B A A A C,当前有一个6个字符的滑动窗口,表示滑动窗口中一次性最多包含6个字符。
编码的第一步:滑动窗口是一个空窗口,此时滑动窗口还不需要滑动,将滑动窗口与滑动窗口外的文本字符串第一位字符进行比对,发现不存在匹配的字符,此时将滑动窗口往右移动一位,也就是将滑动窗口从右滑入文本字符串,那么字符串首字母进入该滑动窗口,此时滑动窗口显示字符A;
编码的第二步:由于滑动窗口内部只有字符A,滑动窗口外紧接着出现字符A,虽然滑动窗口里面和外面存在匹配的字符A,但是为了保证字符编码的效率,事先设置最小匹配串,如将最小匹配串设置为2个字符,由于此时只有一个字符A匹配,不符合要求,那么滑动窗口保持不动,将处理的字符往右移动一位,即与滑动窗口进行比对的字符就是AA,此时滑动窗口内只有一个字符A,因此,不存在匹配的字符,那么将该滑动窗口继续向右滑动,那么文本字符串的第二个字符也进入滑动窗口,此时滑动窗口中出现了两个一样的字符A。
编码的第三步:当滑动窗口内部存在两个相同的字符A时,将滑动窗口内部的两个字符A与窗口外的字符进行比对,由于滑动窗口外紧接着的两个字符是A B,不匹配,因此滑动窗口继续右滑,当滑动窗口滑动出现A A A时,滑动窗口外紧接着出现的字符是B A B,与滑动窗口内的字符不匹配,那么滑动窗口继续向右滑动,以使得滑动窗口内部出现A A AB,此时,由于滑动窗口内部的字符A B与滑动窗口外部紧接着的字符A B匹配,认为找到了相似长度为2的A B,因此滑动窗口外的AB满足最小匹配串的要求,因此一对〈长度,距离〉就被输出了,长度(length)是2并且向后距离也是2,所以输出为<2,2>。
编码的第四步:当后一个字符串AB用<2,2>输出之后,该段字符串就相当于删除了,此时将滑动窗口与剩下的文本字符串进行比对,剩下的文本字符串为A A A C,通过该滑动窗口比对时,在将A A A C中的前两个A A与滑动窗口进行比对时,虽然A A与滑动窗口出现相同内容和长度的字符,并且符合最小字符串,但是为了提高压缩效率,会继续判断文本字符串后面是否还有匹配的字符串,若此时检测到出还有一个字符A,即刚好有文本字符串A A A与滑动窗口内的三个字符A相同,那么确定剩下的文本字符串A A A与滑动窗口内AA A的距离以及相同字符串的长度,此时由于删除了原本字符串中的后一个AB,因此A A A与滑动窗口内A A A的距离是4,相同的内容长度是3,可输出<4,3>。
编码的第五步:输出<4,3>之后,该文本字符串中还需要处理的字符只有C,由于该滑动窗口中的字符是A A A B,不匹配,因此滑动窗口向右滑动一位,将字符C也滑进该滑动窗口,那么滑动窗口内的字符就为A A A B C。由于后续没有内容需要处理,那么将该滑动窗口内的所有字符都输出,最终得到的编码串为A A A B<2,2><4,3>C。
使用LZ77算法进行压缩和解压缩
为了在解压缩时,可以区分“没有匹配的字节”和“(之间的距离,匹配长度)对”,还需要在每个“没有匹配的字节”或者“(之间的距离,匹配长度)对”之前,放上一位,来指明是“没有匹配的字节”,还是“(之间的距离,匹配长度)对”。本发明实施例中,可选用0表示“没有匹配的字节”,用1表示“(之间的距离,匹配长度)对”。
实际应用中,固定(之间的距离,匹配长度)对中的,“之间的距离”和“匹配长度”所使用的位数。由于要固定“之间的距离”所使用的位数,所以才使用了固定大小的窗口,比如窗口的大小为32KB,那么用15位(2^15=32K)就可以保存0-32K范围内的任何一个值。此外,还将限定最大的匹配长度,这样一来,“匹配长度”所使用的位数也就固定了。
实际应用中,还将设定一个最小匹配长度,只有当两个串的匹配长度大于最小匹配长度时,才认为是一个匹配。为更好理解,举一个例子来说明这样做的原因:比如,“距离”使用15位,“长度”使用8位,那么“(之间的距离,匹配长度)对”将使用23位,也就是差1位3个字节。如果匹配长度小于3个字节的话,那么用“(之间的距离,匹配长度)对”进行替换的话,不但没有压缩,反而会增大,所以需要一个最小匹配长度。
压缩:
从文件的开始到文件结束,一个字节一个字节的向后进行处理。用当前处理字节开始的串,和滑动窗口中的每个串进行匹配,寻找最长的匹配串。如果当前处理字节开始的串在窗口中有匹配串,就先输出一个标志位,表明下面是一个(之间的距离,匹配长度)对,然后输出(之间的距离,匹配长度)对,然后从刚才处理完的串之后的下一个字节,继续处理。如果当前处理字节开始的串在窗口中没有匹配串,就先输出一个标志位,表明下面是一个没有改动的字节,然后不做改动的输出当前处理字节,然后继续处理当前处理字节的下一个字节。
解压缩:
从文件开始到文件结束,每次先读一位标志位,通过这个标志位来判断下面是一个(之间的距离,匹配长度)对,还是一个没有改动的字节。如果是一个(之间的距离,匹配长度)对,就读出固定位数的(之间的距离,匹配长度)对,然后根据对中的信息,将匹配串输出到当前位置。如果是一个没有改动的字节,就读出一个字节,然后输出这个字节。
综上所述,可以看出,LZ77压缩时需要做大量的匹配工作,而解压缩时需要做的工作很少,也就是说解压缩相对于压缩将快的多,这对于需要进行一次压缩,多次解压缩的情况,是一个效果显著的优点。
当第一应用处理器10通过上述任一个压缩算法对数据包进行压缩之后,再将压缩后的数据包存储到buffer中进行转发。后续,第二应用处理器20即可从buffer中提取出压缩的数据包,并对提取的压缩数据包进行解压,其中,解压的方式也包括两种:当第一应用处理器10是加密压缩时,所述第二应用处理器20采用对应的密文进行解压,当第一应用处理器10是明文压缩时,所述第二应用处理器20即可直接进行解压,以得到解压后的数据包。由于本实施例中的各个压缩算法主要是明文算法,因此,解压的方式也是明文解压。
可以理解,本方案中,在移动终端100中的电信卡传输的数据包较大时,第二应用处理器20在Request中添加标识,使第一应用处理器10对数据包进行压缩,以改变数据包的期望值,后续缓存到buffer的数据包就不会超出buffer的容量值,那么,避免了大数据包传输导致死机的问题,同时数据包不会被拆分成多个数据包,避免了数据包转发不完整的情况。
本发明进一步提供一种数据包传输方法。
参照图4,图4为本发明数据包传输方法较佳实施例的流程示意图。
本实施例提出一种数据包传输方法,在本实施例中,提供了数据包传输方法的实施例,需要说明的是,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
本发明中,数据包传输方法应用于通过预设接口与外接设备200连接的移动终端100,所述移动终端100包括第一应用处理器10、第一调制解调器11和第一射频模块12,以及与所述第一调制解调器11连接的嵌入式用户识别卡13和实体用户识别卡14,所述外接设备200包括第二应用处理器20、第二调制解调器21和第二射频模块22,所述方法包括:
步骤S10,第一应用处理器通过预设接口接收第二应用处理器发送的数据包获取请求时,从嵌入式用户识别卡或实体用户识别卡中提取所述数据包获取请求对应的数据包;
步骤S20,对提取的数据包进行压缩;
步骤S30,将压缩后的数据包缓存至所述预设接口的buffer中,以供第二应用处理器从所述buffer中提取压缩后的数据包,以完成数据包的传输。
在本实施例中,所述第一应用处理器10通过预设接口接收第二应用处理器20发送的数据包获取请求,后续也是通过所述预设接口将数据包反馈至所述第二应用处理器20。所述预设接口为USB接口。
其中,当第二处理芯片002的第二调制解调器21通过第二射频模块22接收到基站发送的数据包获取请求时,将数据包获取请求发送至第二处理芯片002的第二应用处理器20中,当第二应用处理器20接收到数据包获取请求时,先通过USB数据线300将数据包获取请求传送至移动终端100的第一应用处理器10中;第一应用处理器10接收到该数据包获取请求时,将数据包获取请求传送至移动终端100的第一调制解调器11中,由第一调制解调器11根据该数据包获取请求从嵌入式用户识别卡13或实体用户识别卡14中获取数据包;第一调制解调器11获取到数据包之后,将数据包传输至第一应用处理器10中;第一应用处理器10获取到数据包之后,为了保证传输的数据不会大于USB的buffer,先对获取的数据包进行压缩,得到压缩后的数据包;再通过USB将压缩后的数据包传送至第二应用处理器20;第二应用处理器20在接收到数据包后,再将数据包传送至第二射频模块22,由第二射频模块22将数据包上传至基站,以完成数据的传输。
具体地,所述步骤S10包括:
步骤A,所述第一应用处理器通过第一调制解调器向嵌入式用户识别卡或实体用户识别卡中的片内操作***发送数据包获取请求,由所述片内操作***在嵌入式用户识别卡或实体用户识别卡中的文件存储模块中提取所述数据包获取请求对应的数据包,并反馈至所述第一调制解调器;
步骤B,所述第一应用处理器通过第一调制解调器接收片内操作***反馈的数据包。
在本实施例中,需要说明的是,嵌入式用户识别卡13或实体用户识别卡14中的数据包存储在文件存储模块中,当第一调制解调器11要获取嵌入式用户识别卡13或实体用户识别卡14中的数据包时,第一调制解调器11不会直接与嵌入式用户识别卡13或实体用户识别卡14中的文件存储模块交互,而是先向嵌入式用户识别卡13或实体用户识别卡14中的COS(Chip Operating System,片内操作***)操作***发送数据包获取请求即Request,然后嵌入式用户识别卡13或实体用户识别卡14的COS操作***基于该Request在文件存储模块中获取数据包,然后将获取的数据包再传输给第一调制解调器11,第一调制解调器11只要接收COS操作***反馈的数据包即可,后续第一应用处理器10在第一调制解调器11中获取数据包即可实现数据包的获取过程。
可以理解,由于第一调制解调器11无法在嵌入式用户识别卡13或实体用户识别卡14中的文件存储模块直接提取数据包,因此通过与嵌入式用户识别卡13或实体用户识别卡14的COS操作***进行交互,以实现数据包的提取,保证后续的数据传输过程正常运行。
当第一应用处理器10从嵌入式用户识别卡13或实体用户识别卡14中提取出数据包获取请求对应的数据包之后,再对提取的数据包进行压缩,本实施例中,第一应用处理器10对数据包进行压缩时,可以采用加密压缩的方式进行数据包的压缩,也可以直接采用明文进行压缩。由于传输的SIM卡网络鉴权数据量比较小,为了减少加密解密等操作而导致数据传输效率低,本发明实施例优选采用明文压缩的方式对数据包进行压缩,即本方案中采用的压缩算法以简单高效为主,具体采用的压缩算法和压缩过程在下文实施例中详述。
第一应用处理器10对数据包压缩之后,即可将压缩后的数据包缓存至所述预设接口USB的buffer中,以供第二应用处理器20从所述buffer中提取压缩后的数据包,以完成数据包的传输。
本实施例中需要说明的是,buffer存在于USB接口的两端,即USB接口的两端分别设置有buffer1和buffer2。当第二应用处理器20将数据包获取请求通过USB接口发送给第一应用处理器10时,第一应用处理器10通过第一调制解调器11从嵌入式用户识别卡13或实体用户识别卡14提取出数据包之后,先将提取的数据包存储到buffer1中,以通过USB传输至buffer2,第二应用处理器20再从buffer2中获取数据包。
本实施例提出的数据包传输方法,所述第一应用处理器通过预设接口接收第二应用处理器发送的数据包获取请求时,先从嵌入式用户识别卡或实体用户识别卡中提取所述数据包获取请求对应的数据包,然后对提取的数据包进行压缩,再将压缩后的数据包缓存至所述预设接口的buffer中,以供第二应用处理器从所述buffer中提取压缩后的数据包,以完成数据包的传输。本方案在传输数据包时,先对待传输的数据包进行压缩,再将压缩后的数据包进行传输,使得传输的数据包的容量值有所减小,避免了数据传输过程中移动终端死机的情况。
进一步地,基于第一实施例提出本发明数据包传输方法第二实施例。
数据包传输方法第二实施例与数据包传输方法第一实施例的区别在于,所述步骤S20之前,所述数据包传输方法还包括:
所述第一应用处理器判断能否从所述数据包获取请求中提取出第二应用处理器添加的压缩标识;
若能提取出压缩标识,则执行所述对提取的数据包进行压缩的步骤。
在本实施例中,当第二应用处理器20向第一应用处理器10发送数据包获取请求(Request)之前,为了防止传输的数据包过大,第二应用处理器20发送Request时,先确定是否需要在Request中添加压缩标识,若需要,则先在Request中添加一个压缩标识,如添加字段01,以告知第一应用处理器10对待发送的数据包进行压缩。
需要说明的是,由于待传输的数据是根据通讯协议标准确定的,因此,第二应用处理器20可以得知即将获取的数据包的数据类型和数据大小,那么,当第二应用处理器20发送Request之前,先判断当前待获取的数据包的大小,若待获取的数据包的大小超出了buffer的容量值,则第二应用处理器20在Request中添加压缩标识,以告知第一应用处理器10对待传输的数据包进行压缩,若第二应用处理器20判断待获取的数据包的大小未超出buffer的容量值,则直接发送Request即可,无需添加压缩标识。
在本实施例中,第二应用处理器20发送Request之前,对待获取的数据包的大小进行识别,仅在待获取的数据包超出buffer的容量值时,才在Request添加压缩标识,避免了所有的数据包获取请求都添加压缩标识,缩短了数据包传输的时间,提高了数据包传输的效率。
当第一应用处理器10通过预设接口(USB)接收第二应用处理器20发送的数据包获取请求时,先对所述数据包获取请求进行解析,以确定能否从所述数据包获取请求中提取出第二应用处理器20添加的压缩标识,若在所述数据包获取请求中提取出压缩标识,此时,所述第一应用处理器10即可对提取的数据包进行压缩,后续再将压缩后的数据包缓存至所述预设接口的buffer1中,并通过USB传输至buffer2中,以供第二应用处理器20从所述buffer2中提取压缩后的数据包,以完成数据包的传输。
在本实施例中,数据包传输过程是发生第一应用处理器10和第二应用处理器20唤醒之后,那么当第一应用处理器10和第二应用处理器20唤醒之后,若第二应用处理器20通过第二调制解调器21连接的第二射频模块22接收到基站发送的数据包获取请求,执行以下操作:
判断:先确定待获取的数据包的大小,以判断是否需要添加压缩标识;
决策:若待获取的数据包超过USB的buffer的容量,则在发送数据包获取请求之前,在数据包获取请求添加压缩标识;
发送:在数据包获取请求添加压缩标识之后,发送数据包获取请求。
第一应用处理器10通过USB接收到数据包获取请求时,执行以下操作:
提取:确定能否从数据包获取请求中提取出压缩标识,若能,则提取出压缩标识;
压缩:基于提取的压缩标识,对通过第一调制解调器11从嵌入式用户识别卡13或实体用户识别卡14提取的数据包进行压缩;
反馈:反馈压缩的数据包。
最终,第二应用处理器20通过USB接收第一应用处理器10反馈的数据包,以完成数据包传输过程。上述的操作过程,可参照图4。
需要说明的是,第二应用处理器20发送的是数据包获取请求,由于数据包获取请求一般都小于buffer的容量,因此可不对数据包获取请求进行压缩。
在本实施例中,第一应用处理器10在对数据包进行压缩之前,先判断能否从所述数据包获取请求中提取出第二应用处理器20添加的压缩标识,若能提取出压缩标识,才对数据包进行压缩,防止数据包小于buffer的容量时也进行压缩,以防止***资源的浪费,并且节省了数据包传输的时间,从而提高了数据包传输的效率。
进一步地,基于第一实施例提出本发明数据包传输方法第三实施例。
数据包传输方法第三实施例与数据包传输方法第一实施例的区别在于,所述步骤S20之前,所述数据包传输方法还包括:
所述第一应用处理器对提取的所述数据包进行解析,以得到所述数据包的包头;
基于所述数据包的包头确定所述数据包的长度;
在所述数据包的长度大于预设阈值时,执行所述对提取的数据包进行压缩的步骤。
在本实施例中,所述第一应用处理器10对数据包进行压缩之前,先对从嵌入式用户识别卡13或实体用户识别卡14中提取的数据包进行解析,以得到所述数据包的包头,然后从包头中获取数据包的长度,以确定该数据包的大小。其中,数据包为TLV格式,TLV格式是BER(Basic Encoding Rules,基本编码规则)编码的一种,全称为Type(类型),Length(长度),Value(值),T字段表示数据包的类型,L字段表示数据包的长度、V字段用于存放数据包的内容。
本实施例中,该数据包的生成过程为:传输层获取到数据包对应的原始数据,并为原始数据添加传输层的数据包头,数据包头包括传输层数据类型和数据长度,得到初始数据包,并将初始数据包传输至传输复用层。当传输复用层接收到初始数据包后,为初始化数据包添加传输复用层的数据包头,数据包头包括复用层的数据类型和数据长度,得到数据包,并调用物理驱动层的发送接口将该数据包发送给物理层。后续,第一应用处理器10对提取的所述数据包进行解析,就是从物理层(物理传输介质)之上的物理驱动层检测数据包的包头,以解析得到数据包的大小(长度)。
当第一应用处理器10确定数据包的长度后,再判断该数据包的长度是否大于预设阈值(即buffer的容量值)。在本实施例中,所述预设阈值可选为512字节,在其它实施例中,也可以将所述预设阈值设置为其它长度,在此不再限定。当数据包的长度大于所述预设阈值时,为了防止数据包传输导致终端死机,所述第一应用处理器10对提取的数据包进行压缩。可以理解,若提取的数据包的长度小于预设阈值,所述第一应用处理器10可直接通过USB接口发送该数据包至第二应用处理器20。
在本实施例中,在对数据包进行压缩之前,所述第一应用处理器10对提取的所述数据包进行解析,以得到所述数据包的包头,再确定所述数据包的长度,仅在数据包的长度大于预设阈值时,才对提取的数据包进行压缩,从而提高了数据包压缩的准确性。
进一步地,基于第一至第三实施例提出本发明数据包传输方法第四实施例。
数据包传输方法第四实施例与数据包传输方法第一至第三实施例的区别在于,所述步骤S20包括:
步骤a、所述第一应用处理器获取所述数据包对应的源文本;
步骤b、确定源文本中出现频率大于预设频率的字符段;
步骤c、在预设字典列表中,查找所述字符段对应的编码,其中,编码的长度小于对应的字符段的长度;
步骤d、通过查找的编码代替对应的字符段,以实现数据包的压缩。
在本实施例中,所述第一应用处理器10对数据包进行压缩,具体地,先获取数据包对应的源文本,然后确定源文本中出现频率大于预设频率的字符段,再从预设字典列表中,查找所述字符段对应的编码,其中,编码的长度小于对应的字符段的长度,最终通过查找的编码代替对应的字符段,以实现数据包的压缩。
该过程涉及的算法为字典算法,字典算法是最为简单的压缩算法之一。该字典算法把文本中出现频率大于预设一定值的单词或词汇组合做成一个对应的字典列表,并用特殊代码来表示这个单词或词汇,例如,当前的字典列表中:
00=Chinese
01=People
02=China
若当期数据包中的源文本为:I am a Chinese people,I am from China。那么,采用该字典算法,压缩后的编码为:I am a 00 01,I am from 02。
可以理解,压缩编码后的长度显著缩小,这样的编码专有名词或者固定组合较多的内容中,压缩效率十分显著,将预定的文本内容用字典中预定的编码映射替代,解压缩的时候执行反向还原即可。
进一步地,所述步骤a之后,所述步骤S20还包括:
步骤e、依次确定源文本中高四位为零且相邻的任两个字符段;
步骤f、将所述任两个字符段的高四位进行删除,并将所述任两个字符段的低四位进行组合,以实现数据包的压缩。
即,所述第一应用处理器10获取到数据包对应的源文本之后,还可依次确定源文本中高四位为零且相邻的任两个字符段,再将任两个字符段的高四位进行删除,并将任两个字符段的低四位进行组合,以实现数据包的压缩。
该过程涉及的算法为固定位长算法(Fixed Bit Length Packing),这种算法是把文本用需要的最少的位来进行压缩编码。比如:八个十六进制数:1,2,3,4,5,6,7,8。转换为二进制为:00000001,00000010,00000011,00000100,00000101,00000110,00000111,00001000。每个数只用到了低4位,而高4位没有用到(全为0),因此对低4位进行压缩编码后得到:0001,0010,0011,0100,0101,0110,0111,1000。然后两两补充为8位字节得到:00010010,00110100,01010110,01111000。所以原来的八个十六进制数缩短了一半,得到4个十六进制数:12,34,56,78。
可以理解,通过这种组合方式,将需要用到的位数进行了缩小,使得数据包的容量有所减小,同理,解压时执行反响拆分添加组合即可。
进一步地,所述步骤a之后,所述步骤S20还包括:
步骤g、对源文本中连续出现的字符,采用重复次数加字符进行代替,以实现数据包的压缩。
即,所述第一应用处理器10获取到数据包对应的源文本之后,还可对源文本中连续出现的字符,采用重复次数加字符进行代替,以实现数据包的压缩。
该过程涉及的算法为RLE(Run Length Encoding,游程编码,又译行程长度编码)算法,这种压缩编码是一种变长的编码,RLE根据文本不同的具体情况会有不同的压缩编码变体与之相适应,以产生更大的压缩比率。具体地:
变体1:重复次数+字符
文本字符串:A A A B B B C C C C D D D D,编码后得到:3A 3B 4C 4D;通过该变体算法,即可将数据包终端文本字符串进行压缩。
变体2:特殊字符+重复次数+字符
文本字符串:A A A A A B C C C C B C C C,编码后得到:B B 5A B B 4C B B3C;其中,该编码串的最开始说明特殊字符为B,然后再添加一个B,B后面跟着的数字就表示出重复的次数。也就是说,文本串字符采用该变体2算法进行编码压缩时,先在编码后的编码串的首字母说明特殊字符为B,然后由于后面紧接着出现5个字符A,需要在这5个字符A之前添加一个特殊字符即字符B,因此就是B B 5A,在5A之后出现B,且B之后又出现3个C,因此,需要在3个C之前再添加一个特殊字符B,与前面连接起来就是B B 5A B B 4C,后面采用同样的方式,即可得到最终的编码串B B 5A B B 4C B B 3C。
为了更清楚理解该方案,举另一个例子:文本字符串仍然为:A A A A A B C C CC B C C C,若当前编码串的最开始说明特殊字符为D,那么,编码后得到:D D 5A B D 4C BD 3C。
变体3:
把文本每个字节分组成块,每个字符最多重复127次。每个块以一个特殊字节开头。那个特殊字节的第7位如果被置位,那么剩下的7位数值就是后面的字符的重复次数。如果第7位没有被置位,那么剩下7位就是后面没有被压缩的字符的数量。
例如:文本字符串:A A A A A B C D E F F F,编码后得到:85A 4B C D E 83F(85H=10000101B、4H=00000100B、83H=10000011B)。其中,先将文本字符串分组成三个块,分别是A A A A A、B C D E和F F F,三个快对应的特殊字符分别是10000101、00000100和10000011,由于10000101中第7位被置位为1,因此剩下的7位数值为后面的字符的重复次数,此时可知剩下的7位数值对应的值为5,即可得到85A;同理,由于00000100中的第7位没有被置位为1,那么剩下7位是后面没有被压缩的字符的数量,可知此时剩下7位对应的值为4,即可得到4B C D E;同理可确定83F,此处不在赘述。
需要说明的是,以上所列举出的三种3种RLE变体算法仅仅是较佳的几种变体算法,本领域技术人员利用本发明的技术思想,根据其具体需求所提出的其它RLE变体算法均在本发明的保护范围内,在此不进行一一穷举。
进一步地,所述步骤a之后,所述步骤S20还包括:
步骤h、确定源文本中是否存在内容相同且长度大于预设值的字符段;
步骤i、若存在,确定后一个字符段与前一个字符端的距离以及所述字符段的长度;
步骤j、采用距离与长度的标识代替后一个字符段,以实现数据包的压缩。
即,所述第一应用处理器10获取到数据包对应的源文本之后,还可确定源文本中是否存在内容相同且长度大于预设值的字符段,若存在,确定后一个字符段与前一个字符端的距离以及字符段的长度,采用距离与长度的标识代替后一个字符段,以实现数据包的压缩。
该过程涉及的算法为LZ77(由Jacob Ziv和Abraham Lempel于1977年提出,所以命名为LZ77)算法。
LZ77算法的压缩原理:如果文件中有两块字符串内容相同的话,那么只要知道前一块字符串内容的位置和大小,我们就可以确定后一块字符串的内容。所以我们可以用(两块字符串之间的距离,相同内容的长度)这样一对信息,来替换后一块字符串内容。由于(两块字符串之间的距离,相同内容的长度)这一对信息的大小,小于被替换内容的大小,所以文件得到了压缩。
为更好理解,下面我们来举一个例子:
有一个文件的内容如下:http://jiurl.yeah.net http://jiurl.nease.net,其中有些部分的内容,前面已经出现过了,后面用()括起来的部分就是相同的部分:http://jiurl.yeah.net(http://jiurl.)nease(.net)。
我们使用(两块字符串之间的距离,相同内容的长度)这样一对信息,来替换后一块字符串内容,得到http://jiurl.yeah.net(22,13)nease(23,4)。
(22,13)中,22表示后一块http://jiurl.与前一块http://jiurl.中任意两个相同字符之间的距离,如后一个h与前一个h的距离;13为相同内容的长度;(23,4)同理,此处不再赘述。
从上述例子中可看出,由于(两块字符串之间的距离,相同内容的长度)这一对信息的大小,小于被替换内容的大小,所以文件得到了压缩。
具体地,LZ77算法使用滑动窗口寻找匹配串:
即LZ77算法使用"滑动窗口"的方法,来寻找文件中的相同部分,文件中相同部分即匹配串。首先,对匹配串做一个说明,匹配串是指一个任意字节的序列,不仅仅是可以在文本文件中显示出来的那些字节的序列,还可以是包括标点符号的序列。这里的串强调的是它在文件中的位置,它的长度随着匹配的情况而变化。具体地:
LZ77从文件的开始处开始,一个字节一个字节的向后进行处理。本发明实施例中,滑动窗口的长度是固定的,该滑动窗口的终止位置在当前处理字节之前,并且紧挨着当前处理字节,随着处理的字节不断的向后滑动,就象在阳光下,飞机的影子滑过大地一样。对于文件中的每个字节,用当前处理字节开始的串,和窗口中的每个串进行匹配,以寻找最长的匹配串。
窗口中的每个串指窗口中每个字节开始的串。如果当前处理字节开始的串在窗口中有匹配串,就用(之间的距离,匹配长度)这样一对信息,来替换当前串,然后从刚才处理完的串之后的下一个字节,继续处理。如果当前处理字节开始的串在窗口中没有匹配串,就不做改动的输出当前处理字节。
处理文件中第一个字节的时候,窗口在当前处理字节之前,也就是还没有滑到文件上,这时窗口中没有任何内容,被处理的字节就会不做改动的输出。随着处理的不断向后,窗口越来越多的滑入文件,最后整个窗口滑入文件,然后整个窗口在文件上向后滑动,直到整个文件结束。
需要说明的是,匹配串的长度有所限制,即本实施例中,设置了最小匹配串和最大匹配串,必须限制通过滑动窗口匹配出来的字符串大于该最小匹配串并且小于该最大匹配串,才会进行压缩,若是匹配出来的字符串小于该最小匹配串,或大于该最大匹配串,则不会进行后续的压缩操作。
为更好理解本实施例,举例如下:
假设文本字符串为:A A A B A B A A A C,当前有一个6个字符的滑动窗口,表示滑动窗口中一次性最多包含6个字符。
编码的第一步:滑动窗口是一个空窗口,此时滑动窗口还不需要滑动,将滑动窗口与滑动窗口外的文本字符串第一位字符进行比对,发现不存在匹配的字符,此时将滑动窗口往右移动一位,也就是将滑动窗口从右滑入文本字符串,那么字符串首字母进入该滑动窗口,此时滑动窗口显示字符A;
编码的第二步:由于滑动窗口内部只有字符A,滑动窗口外紧接着出现字符A,虽然滑动窗口里面和外面存在匹配的字符A,但是为了保证字符编码的效率,事先设置最小匹配串,如将最小匹配串设置为2个字符,由于此时只有一个字符A匹配,不符合要求,那么滑动窗口保持不动,将处理的字符往右移动一位,即与滑动窗口进行比对的字符就是A A,此时滑动窗口内只有一个字符A,因此,不存在匹配的字符,那么将该滑动窗口继续向右滑动,那么文本字符串的第二个字符也进入滑动窗口,此时滑动窗口中出现了两个一样的字符A。
编码的第三步:当滑动窗口内部存在两个相同的字符A时,将滑动窗口内部的两个字符A与窗口外的字符进行比对,由于滑动窗口外紧接着的两个字符是A B,不匹配,因此滑动窗口继续右滑,当滑动窗口滑动出现A A A时,滑动窗口外紧接着出现的字符是B A B,与滑动窗口内的字符不匹配,那么滑动窗口继续向右滑动,以使得滑动窗口内部出现A A AB,此时,由于滑动窗口内部的字符A B与滑动窗口外部紧接着的字符A B匹配,认为找到了相似长度为2的A B,因此滑动窗口外的AB满足最小匹配串的要求,因此一对〈长度,距离〉就被输出了,长度(length)是2并且向后距离也是2,所以输出为<2,2>。
编码的第四步:当后一个字符串AB用<2,2>输出之后,该段字符串就相当于删除了,此时将滑动窗口与剩下的文本字符串进行比对,剩下的文本字符串为A A A C,通过该滑动窗口比对时,在将A A A C中的前两个A A与滑动窗口进行比对时,虽然A A与滑动窗口出现相同内容和长度的字符,并且符合最小字符串,但是为了提高压缩效率,会继续判断文本字符串后面是否还有匹配的字符串,若此时检测到出还有一个字符A,即刚好有文本字符串A A A与滑动窗口内的三个字符A相同,那么确定剩下的文本字符串A A A与滑动窗口内AA A的距离以及相同字符串的长度,此时由于删除了原本字符串中的后一个AB,因此A A A与滑动窗口内A A A的距离是4,相同的内容长度是3,可输出<4,3>。
编码的第五步:输出<4,3>之后,该文本字符串中还需要处理的字符只有C,由于该滑动窗口中的字符是A A A B,不匹配,因此滑动窗口向右滑动一位,将字符C也滑进该滑动窗口,那么滑动窗口内的字符就为A A A B C。由于后续没有内容需要处理,那么将该滑动窗口内的所有字符都输出,最终得到的编码串为A A A B<2,2><4,3>C。
使用LZ77算法进行压缩和解压缩
为了在解压缩时,可以区分“没有匹配的字节”和“(之间的距离,匹配长度)对”,还需要在每个“没有匹配的字节”或者“(之间的距离,匹配长度)对”之前,放上一位,来指明是“没有匹配的字节”,还是“(之间的距离,匹配长度)对”。本发明实施例中,可选用0表示“没有匹配的字节”,用1表示“(之间的距离,匹配长度)对”。
实际应用中,固定(之间的距离,匹配长度)对中的,“之间的距离”和“匹配长度”所使用的位数。由于要固定“之间的距离”所使用的位数,所以才使用了固定大小的窗口,比如窗口的大小为32KB,那么用15位(2^15=32K)就可以保存0-32K范围内的任何一个值。此外,还将限定最大的匹配长度,这样一来,“匹配长度”所使用的位数也就固定了。
实际应用中,还将设定一个最小匹配长度,只有当两个串的匹配长度大于最小匹配长度时,才认为是一个匹配。为更好理解,举一个例子来说明这样做的原因:比如,“距离”使用15位,“长度”使用8位,那么“(之间的距离,匹配长度)对”将使用23位,也就是差1位3个字节。如果匹配长度小于3个字节的话,那么用“(之间的距离,匹配长度)对”进行替换的话,不但没有压缩,反而会增大,所以需要一个最小匹配长度。
压缩:
从文件的开始到文件结束,一个字节一个字节的向后进行处理。用当前处理字节开始的串,和滑动窗口中的每个串进行匹配,寻找最长的匹配串。如果当前处理字节开始的串在窗口中有匹配串,就先输出一个标志位,表明下面是一个(之间的距离,匹配长度)对,然后输出(之间的距离,匹配长度)对,然后从刚才处理完的串之后的下一个字节,继续处理。如果当前处理字节开始的串在窗口中没有匹配串,就先输出一个标志位,表明下面是一个没有改动的字节,然后不做改动的输出当前处理字节,然后继续处理当前处理字节的下一个字节。
解压缩:
从文件开始到文件结束,每次先读一位标志位,通过这个标志位来判断下面是一个(之间的距离,匹配长度)对,还是一个没有改动的字节。如果是一个(之间的距离,匹配长度)对,就读出固定位数的(之间的距离,匹配长度)对,然后根据对中的信息,将匹配串输出到当前位置。如果是一个没有改动的字节,就读出一个字节,然后输出这个字节。
综上所述,可以看出,LZ77压缩时需要做大量的匹配工作,而解压缩时需要做的工作很少,也就是说解压缩相对于压缩将快的多,这对于需要进行一次压缩,多次解压缩的情况,是一个效果显著的优点。
当第一应用处理器10通过上述任一个压缩算法对数据包进行压缩之后,再将压缩后的数据包存储到buffer中进行转发。后续,第二应用处理器20即可从buffer中提取出压缩的数据包,并对提取的压缩数据包进行解压,其中,解压的方式也包括两种:当第一应用处理器10是加密压缩时,所述第二应用处理器20采用对应的密文进行解压,当第一应用处理器10是明文压缩时,所述第二应用处理器20即可直接进行解压,以得到解压后的数据包。由于本实施例中的各个压缩算法主要是明文算法,因此,解压的方式也是明文解压。
可以理解,本方案中,在移动终端100中的电信卡传输的数据包较大时,第二应用处理器20在Request中添加标识,使第一应用处理器10对数据包进行压缩,以改变数据包的期望值,后续缓存到buffer的数据包就不会超出buffer的容量值,那么,避免了大数据包传输导致死机的问题,同时数据包不会被拆分成多个数据包,避免了数据包转发不完整的情况。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者***不仅包括那些要素,而且还包括没有明确列出的其它要素,或者是还包括为这种过程、方法、物品或者***所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者***中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其它相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (10)
1.一种数据包传输***,其特征在于,所述数据包传输***包括移动终端,以及通过预设接口与所述移动终端连接的外接设备,所述移动终端包括第一应用处理器、第一调制解调器和第一射频模块,以及与所述第一调制解调器连接的嵌入式用户识别卡和实体用户识别卡,所述外接设备包括第二应用处理器、第二调制解调器和第二射频模块;
所述第一应用处理器,用于通过预设接口接收第二应用处理器发送的数据包获取请求时,从嵌入式用户识别卡或实体用户识别卡中提取所述数据包获取请求对应的数据包;对提取的数据包进行压缩;将压缩后的数据包缓存至所述预设接口的临时缓冲区buffer中,以供第二应用处理器从所述buffer中提取压缩后的数据包,以完成数据包的传输。
2.如权利要求1所述的数据包传输***,其特征在于,所述第一应用处理器,还用于判断能否从所述数据包获取请求中提取出第二应用处理器添加的压缩标识;若能提取出压缩标识,则对提取的数据包进行压缩。
3.如权利要求1所述的数据包传输***,其特征在于,所述第一应用处理器,还用于对提取的所述数据包进行解析,以得到所述数据包的包头;基于所述数据包的包头确定所述数据包的长度;在所述数据包的长度大于预设阈值时,则对提取的数据包进行压缩。
4.如权利要求1至3任一项所述的数据包传输***,其特征在于,所述第一应用处理器对提取的数据包进行压缩具体包括:
所述第一应用处理器获取所述数据包对应的源文本;
确定源文本中出现频率大于预设频率的字符段;
在预设字典列表中,查找所述字符段对应的编码,其中,编码的长度小于对应的字符段的长度;
通过查找的编码代替对应的字符段,以实现数据包的压缩。
5.如权利要求4所述的数据包传输***,其特征在于,所述第一应用处理器,还用于确定源文本中是否存在内容相同且长度大于预设值的字符段;
若存在,确定后一个字符段与前一个字符端的距离以及所述字符段的长度;
采用距离与长度的标识代替后一个字符段,以实现数据包的压缩。
6.一种数据包传输方法,其特征在于,应用于移动终端以及通过预设接口与移动终端连接的外接设备,所述移动终端包括第一应用处理器、第一调制解调器和第一射频模块,以及与所述第一调制解调器连接的嵌入式用户识别卡和实体用户识别卡,所述外接设备包括第二应用处理器、第二调制解调器和第二射频模块,所述方法包括:
第一应用处理器通过预设接口接收第二应用处理器发送的数据包获取请求时,从嵌入式用户识别卡或实体用户识别卡中提取所述数据包获取请求对应的数据包;
对提取的数据包进行压缩;
将压缩后的数据包缓存至所述预设接口的临时缓冲区buffer中,以供第二应用处理器从所述buffer中提取压缩后的数据包,以完成数据包的传输。
7.如权利要求6所述的数据包传输方法,其特征在于,所述对提取的数据包进行压缩的步骤之前,所述数据包传输方法还包括:
所述第一应用处理器判断能否从所述数据包获取请求中提取出第二应用处理器添加的压缩标识;
若能提取出压缩标识,则执行所述对提取的数据包进行压缩的步骤。
8.如权利要求6所述的数据包传输方法,其特征在于,所述对提取的数据包进行压缩的步骤之前,所述数据包传输方法还包括:
所述第一应用处理器对提取的所述数据包进行解析,以得到所述数据包的包头;
基于所述数据包的包头确定所述数据包的长度;
在所述数据包的长度大于预设阈值时,执行所述对提取的数据包进行压缩的步骤。
9.如权利要求6至8任一项所述的数据包传输方法,其特征在于,所述对提取的数据包进行压缩的步骤包括:
所述第一应用处理器获取所述数据包对应的源文本;
确定源文本中出现频率大于预设频率的字符段;
在预设字典列表中,查找所述字符段对应的编码,其中,编码的长度小于对应的字符段的长度;
通过查找的编码代替对应的字符段,以实现数据包的压缩。
10.如权利要求9所述的数据包传输方法,其特征在于,所述第一应用处理器获取所述数据包对应的源文本的步骤之后,所述对提取的数据包进行压缩的步骤还包括:
确定源文本中是否存在内容相同且长度大于预设值的字符段;
若存在,确定后一个字符段与前一个字符端的距离以及所述字符段的长度;
采用距离与长度的标识代替后一个字符段,以实现数据包的压缩。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710396940.0A CN107071833A (zh) | 2017-05-27 | 2017-05-27 | 数据包传输***及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710396940.0A CN107071833A (zh) | 2017-05-27 | 2017-05-27 | 数据包传输***及方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN107071833A true CN107071833A (zh) | 2017-08-18 |
Family
ID=59615651
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710396940.0A Withdrawn CN107071833A (zh) | 2017-05-27 | 2017-05-27 | 数据包传输***及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107071833A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108845659A (zh) * | 2018-01-30 | 2018-11-20 | 武汉大学 | 一种功耗优先的嵌入式处理器实时任务分配方法 |
-
2017
- 2017-05-27 CN CN201710396940.0A patent/CN107071833A/zh not_active Withdrawn
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108845659A (zh) * | 2018-01-30 | 2018-11-20 | 武汉大学 | 一种功耗优先的嵌入式处理器实时任务分配方法 |
CN108845659B (zh) * | 2018-01-30 | 2021-06-04 | 武汉大学 | 一种功耗优先的嵌入式处理器实时任务分配方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107222581A (zh) | 数据传输***、方法、外接设备和移动终端 | |
CN107466070A (zh) | 数据传输***、方法、外接设备和移动终端 | |
CN107231660A (zh) | 数据包传输***及方法 | |
CN107071833A (zh) | 数据包传输***及方法 | |
CN107071831A (zh) | 移动终端及数据包传输方法 | |
CN107231622A (zh) | 移动终端及数据包传输方法 | |
CN107318107A (zh) | 数据传输***、方法、外接设备和移动终端 | |
CN107182083A (zh) | 移动终端及数据包传输方法 | |
CN107318108A (zh) | 数据传输***、方法、外接设备和移动终端 | |
CN107094308A (zh) | 数据包传输***及方法 | |
CN107257568A (zh) | 数据包传输***及方法 | |
CN107182082A (zh) | 数据包传输***及方法 | |
CN107182086A (zh) | 数据包传输***及方法 | |
CN107094152A (zh) | 数据包传输***及方法 | |
CN107094151A (zh) | 移动终端及数据包传输方法 | |
CN107124738A (zh) | 移动终端及数据包传输方法 | |
CN107247679A (zh) | 数据传输***及方法 | |
CN107071832A (zh) | 数据包传输***及方法 | |
CN107257569A (zh) | 移动终端及数据包传输方法 | |
CN107222429A (zh) | 数据传输***及方法 | |
CN107277859A (zh) | 数据传输***、方法、外接设备和移动终端 | |
CN107466029A (zh) | 数据传输***、方法、外接设备和移动终端 | |
CN107466028A (zh) | 数据传输***、方法、外接设备和移动终端 | |
CN107466027A (zh) | 数据传输***、方法、外接设备和移动终端 | |
CN107148052A (zh) | 移动终端及其数据传输方法 |
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 | ||
WW01 | Invention patent application withdrawn after publication |
Application publication date: 20170818 |
|
WW01 | Invention patent application withdrawn after publication |