CN112385193A - 处理消息数据的方法和装置 - Google Patents
处理消息数据的方法和装置 Download PDFInfo
- Publication number
- CN112385193A CN112385193A CN201980029289.0A CN201980029289A CN112385193A CN 112385193 A CN112385193 A CN 112385193A CN 201980029289 A CN201980029289 A CN 201980029289A CN 112385193 A CN112385193 A CN 112385193A
- Authority
- CN
- China
- Prior art keywords
- data
- field
- data message
- message
- processing
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- 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
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/622—Layer-2 addresses, e.g. medium access control [MAC] addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/659—Internet protocol version 6 [IPv6] addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
- H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Debugging And Monitoring (AREA)
- Communication Control (AREA)
Abstract
使用从除了数据分组本身或其所属于的流之外的源获得的信息,处理诸如以IPv4或IPv6格式的数据分组之类的数据消息以进行压缩/解压缩。这可以涉及在由共享标记标识的规范中定义的附加动态处理,或者从诸如静态文件、数据库应用等附加数据源获得的附加动态处理。本文描述的实施例利用数据分量的动态确定来增强该方法。
Description
技术领域
本发明总体上涉及数据消息的处理,并且特别地涉及对这样的数据的压缩。
背景技术
图1示意性示出了现有技术中已知的网络报头压缩机制的方面。
具体地,图1示出了用于IPv6网络的报头压缩的机制的元素,基本上如在LPWAN静态上下文报头压缩(SCHC)和用于IPv6和UDP的draft-tetf-lpwan-ivp6-static-context-hc-00中提出的。
如所示的,数据要经由基于IPv6的LPWAN网络150从发送设备A发送到接收设备B。由于诸如在发送设备处的功率或者带宽可用性之类的限制,因此可能期望减少要被发送的数据的总量。根据图1的机制,包括多个用于发送的定义字段的数据分组被暴露给一组规则110、120、130、140,这些规则一起构成上下文100a。每个规则包括多个字段指令行。例如,规则140包括字段指令行141、142、143、144、145等。字段描述行具有包括四个条目的公共行。具体地,每个字段描述行包括指定数据分组的定义字段中的一个的字段ID、目标值、匹配运算符和压缩/解压缩动作。因此,如所示的,规则141的字段可以被视为被结构化为四个列140a、140b、140c、140d。因此,字段描述行141具有字段ID 141a、目标值141b、匹配运算符141c和压缩/解压缩动作141d。类似地,字段描述行142具有字段ID 142a、目标值142b、匹配运算符142c和压缩/解压缩动作142d。
在操作中,在发送器侧处理的数据分组相继与每个规则进行比较,并且使用匹配运算符,每个规则相继与该规则的每个字段描述行进行比较。
对于每个字段描述行,确定在字段ID条目中引用的字段的目标值条目是否以如该字段描述行的匹配运算符条目中定义的规定方式相对应。在引用的字段针对相应的规则中的每一个字段以规定方式对应于目标值的情况下,应用对应的规则中的每个字段的压缩/解压缩动作。
可能的匹配运算符包括运算符“忽略(ignore)”或者“相等(equal)”MSB(长度)和来自列表的匹配映射。
通过示例的方式,规则140可以包括下面示出的三个字段:
附图标记 | 字段ID | 目标值 | 匹配运算符 | 压缩函数 |
141 | F1 | 0x00 | 忽略 | 未发送 |
142 | F2 | 0x1230 | 相等 | 未发送 |
143 | F3 | 0xABC0 | 相等 | 未发送 |
基于此,数据分组中的第一字段将首先被暴露给字段指令行141,由于在针对该字段的匹配运算符条目中规定的比较方法是“忽略”,因此该比较被自动满足。方法然后进行到字段指令行142,针对其在匹配运算符条目中规定的比较方式是“相等”。因此,数据分组的字段F2必须包括目标值“0x1230”,如在目标值字段中定义的。方法然后进行到字段指令行143,针对其在匹配运算符条目中规定的比较方式是“相等”。因此,数据分组的字段F3必须包括目标值“0xABC0”,如在目标值字段中定义的。
假设规则140中的所有三个字段基于此被满足,则选择规则140以应用。基于此,规则140中的每个字段的压缩指令被应用于数据分组。
如上所示,针对规则141的所有三个字段指令行的压缩函数都是“未发送”,从而指示所讨论的三个字段F1、F2和F3中的每一个被从要被发送的分组剥离。
如图1中示出的,压缩的分组然后经由网络150连同已经应用的规则140的标识符(ID4)一起被发送到接收侧b。
如所示的,分别与上面描述的规则110、120、130、140相对应的一组规则160、170、180、190一起构成上下文100b。上下文100b在结构和内容上与上下文100a相对应,使得每个规则包括多个字段指令行。例如,规则190包括字段指令行191、192、193、194、195等。字段指令行具有包括四个条目的共同结构。具体地,每个字段指令行包括指定数据分组的定义字段中的一个的字段参考、目标值、匹配运算符和压缩/解压缩动作。因此,如所示的,规则191的字段指令行可以被视为被结构化为四个列190a、190b、190c、190d。因此,字段指令行191具有字段参考191a、目标值191b、匹配参数191c和压缩函数191d。类似地,字段指令行192具有字段参考192a、目标值192b、匹配参数192c和压缩函数192d。
在操作中,所接收的数据分组根据由所接收的发送指定规则(即,与规则190相对应的规则ID4)被处理。指定规则中的每个字段指令行以规定方式被应用于相应的字段。
参考与上面呈现的规则140相同的规则190(如由唯一规则ID(ID4)指示的),规则190可以包括下面示出的三个字段:
附图标记 | 字段参考 | 目标值 | 匹配运算符 | 压缩函数 |
141 | F1 | 0x00 | 忽略 | 未发送 |
142 | F2 | 0x1230 | 相等 | 未发送 |
143 | F3 | 0xABC0 | 相等 | 未发送 |
基于此,数据分组中的第一字段F1将被填充有值0x00,数据分组中的第二字段F2将被填充有值0x1230,并且数据分组中的第三字段F3将被填充有值0xABC0。
基于此可以观察到,除了字段F1的值之外,所得到的分组13与原始分组11相同,其中,通过字段141c中的“忽略”匹配运算符的操作,原始值0xA1已经由值0x00替换。将认识到的是,在某些情况下,可以确定特定字段的值可以以这一方式安全地缺省为预定值而不干扰整体系统操作。
在上面提到的标准中定义的压缩/解压缩操作包括以下内容:
诸如参考图1描述的机制之类的机制提供了用于减少网络中的数据流的基础,然而,随着使用这样的通信系统的设备数量增加,并且终端设备的能力在功耗、处理功率和通信带宽方面受到更为严格的限制的影响,期望提供用于进一步优化这样的通信的机制。
发明内容
根据本发明的第一方面,提供了一种处理用于发送的数据消息的方法。该方法包括以下步骤:解析数据消息的字段以获取第一类型的数据分量,其中,第一类型的数据分量可从除了与该数据消息相关联的数据流之外的数据源导出;向数据消息添加标记,该标记与定义导出的处理操作的规范相关联。
根据第一方面的发展,将与第一数据分量类型相关联的标记添加到数据消息的步骤包括:用标记替换数据分量。
根据第一方面的发展,方法包括以下步骤:从数据消息中提取与第一数据分量类型相关联的标记;以及通过关于除了与数据消息相关联的数据流之外的数据源的处理操作来导出另外的数据分量,其中,处理操作是在与标记相关联的规范中定义的。
根据第一方面的发展,方法包括以下另外的步骤:利用另外的数据分量重构数据分量。
根据第一方面的发展,方法包括以下另外的步骤:将另外的数据分量添加到数据消息。
根据第一方面的发展,方法包括以下另外的步骤:存储另外的数据分量;以及在解析另外的数据消息的区域以获取与第一数据分量类型相关联的标记的步骤的另外的迭代中,取回所存储的替代数据,而不是重复询问与标记相关联的数据源的步骤。
根据第一方面的发展,数据源是DNS服务器,并且其中,标记指示数据源和URL,并且其中,替代数据是IP地址。
根据第一方面的发展,数据源是DHCP服务器,并且其中,规范指示数据源和MAC地址,并且其中,另外的数据分量是IP地址。
根据第一方面的发展,数据源是适于返回指定实体的加密密钥的加密密钥服务器,并且其中,规范指示数据源和指定实体。
根据第一方面的发展,标记还包括数据分量的加密版本,方法包括以下另外的步骤:使用取回的加密密钥来解密数据分量的加密版本。
根据第一方面的发展,数据分量是分段校验和,并且其中,源是适于返回对应的校验和的校验和计算器。
根据第一方面的发展,定义了一个或多个规则,每个规则包括一个或多个字段指令行,每个字段指令行包括目标值和处理指令。
方法包括以下另外的步骤:针对规则确定数据消息的相应的指定区域是否以相应的规定方式对应于目标值,并且在相应的指定区域针对相应的规则中的每个字段指令行以相应的规定方式对应于目标值的情况下,关于该相应的指定区域,应用对应的规则中的每个字段指令行的处理指令,其中,如由该处理指令定义的那样处理数据分量。
根据本发明的第二方面,提供了一种计算机程序,其包括适于实现第一方面的步骤的指令。
根据本发明的第三方面,提供了一种用于处理数据消息的发送处理器,该发送处理器适于进行以下操作:解析数据消息的字段以获取第一类型的数据分量,其中,第一类型的数据分量可从除了与该数据消息相关联的数据流之外的数据源导出;以及向数据消息添加标记,该标记与定义导出的处理操作的规范相关联。
根据本发明的第四方面,提供了一种用于处理所接收的数据消息的接收处理器,该接收处理器适于进行以下操作:从数据消息中提取与第一数据分量类型相关联的标记;以及通过关于除了与数据消息相关联的数据流之外的数据源的处理操作来导出另外的数据分量,其中,处理操作是在与标记相关联的规范中定义的。
附图说明
现在将仅出于说明的目的参考附图描述本发明的上述和其他优点,其中:
图1示意性地示出了网络报头压缩机制的方面;
图2示出了根据第一实施例的方法;
图3示出了根据第二实施例的方法;
图4示意性地呈现了根据某些实施例的图2和图3的方法的组合操作;
图5示出了关于图4介绍的发送侧处理的变型;
图6示出了根据实施例的规范学习算法;
图7呈现了根据实施例的经由状态通信的规范学习的示例;
图8示出了适于本发明的实施例的实现方式的通用计算系统;并且
图9示出了适于构成实施例的独立传感器设备。
具体实施方式
图2示出了根据第一实施例的方法。
如图2中示出的,提供了一种处理用于发送的数据消息的方法。消息可以是例如根据已知的分组传输协议(例如,IPv6或IPv4)定义的分组。消息可以例如在点对点通信中等同地构成突发类型的消息。通过示例的方式,消息可以包括与气象站的通信、报告通信、蜂窝电话信令通信(例如,3G PDU、移动性管理等)、蓝牙、Zigbee、ADS-B飞机通信、远程工业传感器(例如,管道的流控制和状态监视)、远程设施的入侵检测、设备管理(例如,OMA-DM、LWM2M)、OneM2M、OCF、线程、ZigBee集群库等。
在一些实施例中,可以参考数据消息或数据消息可以属于的数据流的特性来获得数据分量。还将认识到的是,可以例如在系统初始化时或在处理规范时动态地获得特性的一些或全部方面。例如,在消息的方面是始发IP地址的情况下,可以在系统启动时在发送侧获得该特性。
该特性可以是消息所属于的数据流的任何特性,或者可以是其他相关联的特性,可以假设该相关联的特性在通过网络时保持为真。特性的可能示例可以包括根据其对消息进行编码的协议,例如,IPv4或IPv6。可以根据关于流的形式和内容的特性进行推论,这可以是下文中更详细描述的处理操作中的一些的基础。将认识到的是,实施例可以在非常广泛的通信网络中使用,通过非限制性示例的方式,这些通信网络包括IPv4或IPv6、CoAP(受限应用协议)、UDP(用户数据报协议)、TCP(传输控制协议)、ICMP(互联网控制消息协议)、ICMPv6、CBOR(简洁的二进制对象表示)、CoMI(CoAP管理接口)、LWM2M(轻量级机器到机器)、OneM2M、OCF(开放连接基金会)、MQTT(消息队列遥测传输)、RoHC(鲁棒性报头压缩)、VJ(VanJacobson报头压缩)、GHC(通用报头压缩)、DTLS(数据报传输层安全性)或上面提到的通信上下文中的任一个的其他特征特性、未格式化的数据消息,其中单个数据字段归因于消息内的可以具有专有格式或其他格式的固定位或字位置。
如图所示的方法开始于步骤200,然后进行到步骤210,在步骤210处,解析数据消息的字段以获得第一类型的数据分量,其中与第一类型的数据分量相对应的替代数据可以结合特性知识从除了与数据消息相关联的数据流之外的数据源导出。
基于参考图1描述的压缩技术,数据分量可以是数据消息的字段,例如,如在字段指令行的字段ID条目中指定的。基于此,数据分量的解析可以包括以下步骤:确定指定字段是否以字段指令行的匹配运算符定义的方式对应于目标值。技术人员将认识到的是,在不同的上下文中,可以通过任何合适的机制来执行数据消息的解析。
确定指定字段是否以字段指令行的匹配运算符定义的方式对应于目标值不一定构成确定该字段是否等于目标值。匹配运算符可以用于评估字段值是否与目标值匹配。这可以被表述为:MO(Field_Value,Target_Value)——其中MO返回真(TRUE)或假(FALSE)(匹配或不匹配)。该表示方式被表示为波兰语标记。
在由此标识出第一类型的数据分量的情况下,如在步骤215处确定的那样,方法进行到步骤220,在步骤220处,将与定义替代数据的导出的处理操作的规范相关联的标记添加到数据消息中,然后在步骤230处终止。否则,在没有标识出第一类型的数据分量的情况下,如在步骤215处确定的那样,方法在步骤230处终止。
在例如下文中讨论的实施例中,可以执行对具有标记的数据消息的修改以压缩或富集数据消息。标记的定义、选择或包含可以根据在字段指令行中,特别是在处理操作字段中提供的指令来执行或者以其他方式执行,如下面更详细地讨论的。标记可以包括例如关于图1所描述的规则ID,或者在下文中,在这种情况下,定义替代数据的导出的处理操作的规范可以对应于规则或规则的指令行。该过程并不意味着限制标记的本质——标记可以是位的不透明的集合(例如,标签)或结构化信息(例如,CBOR、XML或其他格式化的数据)。
可以注意到,虽然现有技术的压缩/解压缩操作仅依赖于数据消息本身或数据消息所属于的数据流的特性并且因此是固有静态的,但是本文描述的实施例利用数据分量的动态确定增强了该方法。
基于此,在压缩模式下,修改具有标记的数据消息的步骤可以包括用标记替换数据分量。通过示例的方式,标记可以包括如参考图1所讨论的规则ID,其中对应于数据分量的替代数据可从除了与数据消息相关联的数据流之外的数据源导出。
类似地,在富集模式下,修改具有标记的数据消息的步骤可以包括用标记替换数据分量。通过示例的方式,标记可以包括如参考图1所讨论的规则ID,其中对应于数据分量的替代数据可从除了与数据消息相关联的数据流之外的数据源导出。
图3示出了根据第二实施例的方法。
如图3中示出的,提供了一种处理所接收的数据消息的方法。
因此,图3的方法可以被视为实现了与参考图2描述的过程匹配的过程,其中图2的方法在发送方或发送器处实现,并且图3的方法在接收器处实现,该接收器接收例如根据图2的方法处理的消息。
如图3中示出的,方法开始于步骤300,然后进行到步骤310,在步骤310处,提取与数据消息的第一数据分量类型相关联的标记。然后,方法进行到步骤320,在步骤320处,通过关于除了与数据消息相关联的数据流之外的数据源的处理操作来导出另外的数据分量,其中,处理操作是在与标记相关联的规范中定义的。然后方法在步骤330处终止。
图4示意性地呈现了根据某些实施例的图2和图3的方法的组合操作。
如图4中示出的,处理数据消息410以在发送处理器420处进行发送。根据图2的方法,解析数据消息410的字段411以获得第一类型的数据分量412,其中确定第一类型的数据分量412可从除了与数据消息410相关联的数据流之外的数据源导出。然后,发送处理器用与第一数据分量类型相关联的标记433、443替换数据分量412。如所示的,标记433可以仅替换所讨论的数据分量,或者可替代地,单个标记443可以替换属于数据消息中的多个字段的数据分量,例如,如上面关于图1所描述的方法所允许的那样。将认识到的是,术语“替换”不应被理解为要求将标记放置在数据消息中的与数据分量相同的位置,也不应被理解为要求标记应该具有相同的长度。实际上,标记将典型地比它所替换的数据分量短得多,以便实现压缩效果。实际上,在标记根据参考图1描述的方法采取规则ID的形式的情况下,标记典型地可以为1字节的量级,并且可以小至一个位。将认识到的是,可以使用一个或多个标记来替换属于相同字段的数据分量、或属于不同的相应的字段数据分量、或散布在多个相应字段中的数据分量。将认识到的是,在某些情况下,包含要被一个或多个标记替换的数据分量的一个或多个字段可以包含未被标记替换的附加内容,在这种情况下,该另外的内容被包括在数据消息430、440中,作为相应的剩余有效载荷432、442。
然后,经由网络450将所得到的数据消息430或440从发送方a发送至接收器b。在某些实现方式中,根据实施例的通信可以在终端设备与服务器或其他集中点之间发生。在任何情况下,在根据实施例的通信在两个设备之间发生的情况下,这两个设备可以各自作为发送方和接收器操作。在其他情况下,特定设备可以仅作为发送方或仅作为接收器操作。
当接收器b接收到数据消息430或440时,该数据消息430或440由接收器处理器460处理,并且标记433、443由功能单元461从内部数据源462或外部数据源463中提取到另外的数据分量。
数据源可以是存储器中或存储装置上的数据库、区块链、公共注册表(例如,由IANA持有的公共注册表)、例如以XML、JSON或二进制格式的文件等。下面提供了更多示例。
在图1的布置中,假定规范在接收器和发送器中是相同的,并且出于相同的原因假定这些规范都是相同的,而无论实现这些规范的位置的特性如何,例如,一方面在终端设备中实现,另一方面在服务器中实现。例如,对于压缩,可以关于通过DHCP(全局)或SLAAC(链接本地)获知的值对IP地址进行压缩,以便标记将指示这是全局地址还是链接本地地址。然而,在接收器侧,利用了解地址的本质(即,地址的实际值)的通用值解压缩地址可以是足够的。根据某些实施例,可以设想例如如下的替代方案:
·定义处理操作的规范可以被定义,其中取决于情况来应用某些元素的替代方案——例如,与发送的消息相反的针对所接收的消息的不同的目标值、匹配运算符或处理指令等。
·发送处理器或接收器处理器可以适于处理规范,该规范以与其操作的设备的情况相对应的方式定义处理操作。例如,在规范要求进行DHCP操作的情况下,在从设备本身进行发送的情况下,可以对发送处理器进行编程以省略该步骤,并且仅针对设备IP地址插入预定义的值。
根据某些可选的变型,另外的数据分量可以被存储在存储设备464中,例如以减少对另外的询问动作的需要。
基于此,实施例可以被视为状态与给定设备、数据流、消息或通常与压缩器/解压缩器的关联。一个特定的示例是这样的概念:设备在其与特定网络进行关联期间可以具有相同的IPv6地址,该设备上的管理应用在设备的整个寿命中将具有相同的UDP端口,特定的管理会话(其将重新配置设备休眠的时段)可以具有在管理会话的持续时间内有效的CoAP令牌ID,压缩器/解压缩器可以具有实现的或不存在的特定处理指令功能等。基于此,例如,如果目标值条目实现了一个学习操作(如下面更详细描述的),则该学习必须存储在某个位置。其可以在外部服务上(例如,经由HTTPS推送它或将其存储在数据库中)或者在其他位置,但是在任何情况下本质上都构成了状态的保持。对于可以在内部改变、发现、学习或使用的任何功能,情况是一样的。可以有保持已经通过压缩器的消息的数量的功能。或者,可以有可以存储特定消息以进行恢复的FEC功能。或者,可以由加密密钥、隧道建立或签名。一旦通信被视为具有状态性,允许通信中的两个设备相对于其操作或特定状态交换数据的信令机制就变得有意义。然后可以将其用于递送来自功能的值,在执行功能时可能需要对这些值进行配置。可以基于每个压缩器/解压缩器、每个数据流、每个设备、每个规范、每个上下文、每个功能来保留这种状态或动态地创建这种状态。可以在本地、远程(例如,经由SSH、DNS、DHCP、HTTPS、MQTT、ODBC)或两者来保持状态。然后上下文可以被视为静态描述,其具有关于如何与状态进行交互的指示。实施例涉及与处理操作的规范相关联的标记,该处理操作的规范定义了从除了与数据消息相关联的数据流之外的数据源导出数据分量。处理操作可以包括从诸如静态文件或数据库之类的储存库中取回数据分量或其某些前体(precursor)的指令。处理操作可以可替代地或另外地包括从过程中取回数据分量或其某些前体的指令,该过程可以是外部应用或者规范本身中定义的且在合适平台上执行的软件操作,在这种情况下,执行的软件可以构成数据源。在任一种情况下,数据源都不是与数据消息相关联的数据流,例如,数据消息所属于的数据流或者数据消息本身。数据源可以可选地排除规范和/或规范所属于的上下文。处理操作可以有助于以下各项的定义:相应的指定区域、目标值、可能要求目标值和特定区域中的值相对应的规定方式或者在步骤235处应用字段指令行的情况下要执行的处理指令或者这些项中的一些或全部的任何组合。
因此,公开了一种用于处理数据消息的发送处理器,该发送处理器适于进行以下操作:解析数据消息的字段以获取第一类型的数据分量,其中,第一类型的数据分量可从除了与该数据消息相关联的数据流之外的数据源导出;以及向数据消息添加标记,该标记与定义导出的处理操作的规范相关联。
类似地,公开了一种用于处理所接收的数据消息的接收处理器,该接收处理器适于进行以下操作:从数据消息中提取与第一数据分量类型相关联的标记;以及通过关于除了与数据消息相关联的数据流之外的数据源的处理操作来导出另外的数据分量,其中,处理操作是在与标记相关联的规范中定义的。
标记与定义数据分量的导出的处理操作的规范相关联。标记可以通过引用或以任何方便的方式来指定规范。规范的示例是如上面所描述的规则,在该上下文中,标记可以是规则ID。在某些实施例中,标记可以包括附加信息,例如,压缩残差、学习信息或信号/控制信息,如下面所讨论的。
在某些实施例中,标记可以在带内递送用于压缩器/解压缩器的状态信息。例如,具有功能的字段可以具有结构化可变长度标记(SVLM)。该SVLM可以具有例如以CBOR表示为TLV或其他的结构。这可以将标记分为两部分——“标记”和“附加信息”。“附加信息”可以携带诸如针对目标值的“新的目标值”之类的信息。在下面的DHCP()服务器的示例中,网络可以执行DHCP以确定IP地址,然后在SLVM中将获得的值发送到设备。
然后,这还可以用于通过单个规范来初始化设备的配置,该单个规范定义了被分配用于该用途的处理操作,例如,定义其中包含需要值的所有功能的处理操作的规范。除了建立与这些功能相关联的状态之外,定义处理操作的规范本身将不会在设备上生成任何分组或操作。
这样的示例可以要求用户定义一些值,例如,终端设备上的源IP、目的地IP、UDP目的地。这可以例如用函数的定义来表示:
UserDefined()
通过示例的方式,设备然后可以具有配置规范(CONFIG SPECIFICATION),其中RULE_ID==100:
在这里,变量“FirstIPv6Add”、“SecondIPv6Add”和“FirstUDPDest”引用了端点上的局部状态的一部分。然后,可以由定义处理操作的其他规范中的功能来引用该信息,例如以用作目标值(TargetValue)。命名是用户定义的,并且可以具有诸如“All.IPv6.source”或“RuleID.5.IPv6.source”之类的逻辑。
仅当需要发送配置时才可以匹配该定义处理操作的规范,并且可以使用SVLM。可替代地,可以存在可以在CoAP之上执行该配置的管理协议,或者可以存在发送处理器/接收处理器无法直接理解的其他单元。SVLM提供了一种同步带内两个通信端的状态的方式。
“附加信息”还可以包括发送方在其状态中没有该字段的指示。这向接收器指示只要可能就要发送它。例如,设备可以在上下文中看到DHCP()函数,但可能无法直接执行DHCP()。压缩后,它将在SVLM的“附加信息”部分中指示“缺少本地状态”。
根据某些可选变型,可以在接收器处理器或发送处理器中对另外的数据分量进行进一步处理。
根据某些可选变型,例如通过替换功能单元465,在重构或解压缩的数据消息470中,另外的数据分量471可以替换原始数据分量412。
根据某些可选的变型,例如通过“添加”功能单元466将另外的数据分量491添加到数据消息中作为不属于原始或重构的数据消息480的另外的字段。
图2或图3的方法可以在诸如图1的场景之类的场景中实现,其中定义了一个或多个规则,每个规则包括一个或多个指令行,每个指令行包括目标值和处理指令。因此,这种“规则”是定义处理操作的规范的示例。在这种上下文中,方法可以包括以下另外的步骤:针对规则确定数据消息的相应的指定区域是否以相应的规定方式对应于相应的目标值,并且在相应的指定区域针对相应的规则中的每个字段以相应的规定方式对应于目标值的情况下,关于该相应的指定区域,应用对应的规则中的每个字段的处理指令。关于图1描述的通用结构是这种操作场景的一个示例,尽管本领域技术人员将认识到,可以设想这种场景的任何数量的变型。尽管参考这种场景描述了本文的某些示例,但是将认识到的是,实施例可应用于许多消息处理和报头压缩场景。例如,消息可以是例如根据已知的分组传输协议(例如,IPv6或IPv4以及最终的上层协议)定义的分组。消息可以例如在点对点通信中等同地构成突发类型的消息。通过示例的方式,消息可以包括与气象站的通信、报告通信、蜂窝电话信令通信(例如,3G PDU、移动性管理等)、蓝牙、Zigbee、ADS-B飞机通信、远程工业传感器(例如,管道的流控制和状态监视)、远程设施的入侵检测等,如上面所提到的。
可以以多种方式扩展根据图1的基本方法,以增加其功能和复杂性。
测试每个规则并且然后应用规则中的每个字段指令行的通用方法意味着可以(例如,通过设置匹配运算符为忽略)以操作对测试没有影响(它们始终为真)的方式将操作包括在编写的规则中,但随后包括用于进一步处理数据消息的特定操作。下面呈现的许多示例都使用这种方法。
在某些情况下,可以假定以字段指令行出现在规则中的次序来应用所选择的规则的字段指令行,并且以与所应用的规则中的字段指令行的次序相同的序列从一端到另一端构造输出数据消息。通过这种方式,可以通过适当地定义字段指令行的序列来构造输出数据消息,并且在某些情况下可以将字段ID号用于其他目的。下面呈现的许多示例都使用这种方法。
根据某些实施例,字段指令行可以以任意序列执行,如由一些附加考虑因素所建议的。例如,字段指令行可以与序列号相关联,或者可以以预定义的优先次序或其他方式处理与数据分组的实际字段不对应的某些字段ID行。将认识到的是,某些字段指令行可以以它们在报头中的位置的次序继续被执行,而其他字段指令行则以某种其他次序被处理。
处理指令可能包括压缩和/或解压缩动作,如关于图1所讨论的。除了利用处理指令执行各种附加操作之外,还可以定义提供零长度输出(例如,不输出任何内容)的函数,并且仅关注动作。
然后,可以以各种方式来使用根据图3的方法取回的另外的数据分量。
在某些情况下,可以通过利用取回的信息填充数据消息的空白部分来使用另外的数据分量填入解压缩的数据消息。基于此,图2和图3的方法的操作一起构成了从一端到另一端的压缩/解压缩操作。因此,方法可以包括以下另外的步骤:用另外的数据分量替换该数据分量。
在某些情况下,除了原始数据消息之外,另外的数据分量还可以用于通过将取回的信息作为补充数据添加到数据消息中来富集数据消息。基于此,图2和图3的方法的操作一起构成了末端加载的富集操作。因此,方法可以包括以下另外的步骤:将另外的数据分量添加到数据流。
在某些情况下,方法可以包括以下另外的步骤:存储另外的数据分量;以及在解析另外的数据消息的区域以获取与第一数据分量类型相关联的标记的步骤的另外的迭代中,取回所存储的替代数据,而不是重复询问与标记相关联的数据源的步骤。
将认识到的是,可以组合上面提到的各种用例。例如,另外的数据可以既被添加到数据流,又被存储以用于未来的迭代;另外的数据可以用于解压缩数据消息,并且被存储以用于未来的迭代,或任何其他组合。
将认识到的是,在这种上下文中,可以在过程中的各种不同点处执行取回以及视情况使用另外的数据分量。例如,可以在字段的规范、处理指令的定义或分辨率、要求特定目标值对应于目标值的方式的定义、目标值等等的上下文中询问数据源。在以下小节中,将进一步详细探讨这些可能性中的一些。
在某些实施例中,通过处理操作导出另外的数据分量可以通过规范中并入的特殊处理操作命令来实现,其中,发送处理器或接收处理器适于直接解释并执行以便生成另外的数据分量或其元素。可以提供多个这样的特殊处理操作命令,每个对应于特定功能,或者可以提供一个或多个通用特殊处理操作命令,其功能是基于相同字段指令行中的其他元素来解释的。通过示例的方式,“生成”或“计算”功能的以下示例遵循该后一种方法,尽管本领域技术人员将认识到,这两种方法可以等同地单独实现。
以下三个示例示出了根据实施例的“生成”处理指令的使用。这样的“生成”处理指令可以用于填充未通过网络发送的字段,这意味着在某些情况下,所讨论的字段可以仅在发送的数据中省略。“生成”处理指令可以与如上面所描述的存储装置(例如,元素464)的使用相关联,以允许操作散布在多个随后的消息中。
对于IPv6报头中的IPv6流标签字段ID:
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
IPv6.FlowL | 忽略 | 生成 |
当包含与设备地址相对应的数据分量的数据消息到达发送器处理器时,发送器处理器将确定适用的规范,因为在任何情况下,匹配运算符都是“忽略”,因此该行将始终为真,并且在此基础上执行“生成”操作,由此针对具有相同源地址、源端口和目的地端口的所有消息生成相同的标识符值。可以定义生成操作以存储标签,并且然后取决于业务特性在特定时间段后将其丢弃。
尽管上面呈现的示例保留了图1的方法的四列结构,但是将认识到的是,根据本发明的实施例,可以定义另外的列,从而支持另外的并行功能和/或扩展或修改行为。例如,除了指定如在数据消息的基础协议中定义的字段之外,还可以关于例如指定字段内的起始位置和子字段长度或其他来定义字段的子部分。尽管图1的方法假设规范在上游和下游等同地适用,但也可以定义在一个方向或另一个方向上适用的规范,或者在一个方向上以一种方式适用并且在相反方向以另一种方式适用的规范或者其他规范。还可以将附加字段添加到上下文表中,该上下文表对于系统内务处理(housekeeping)(例如,规范到期日期(例如,对于太阳设置数据格式,或者对于订阅到期))可以是可选的。这等效于在匹配运算符中添加日期运算符,但从概念上讲,这可以作为上下文数据库实现方式中的附加字段而更容易被管理。其他示例可以包括规范有效性窗口(2个字段)、日志记录ID(可能用于性能分析——1个字段)等等。
为了清楚起见,在上面的规范表中定义了与数据消息中的实际指定字段相对应的字段ID参考,并且下面的另外的示例中的一些是根据惯例[协议].[字段参考]的。字段ID参考不符合该惯例,并且特别地,表示不对应于网络协议的第一组件可以被理解为替换使用字段ID,以便实现如本文所描述的特殊特征。
对于IPv4分段标识符,IPv4报头的字段ID:
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
IPv4.fragId | 忽略 | 生成 |
当包含与设备地址相对应的数据分量的数据消息到达发送器处理器时,发送器处理器将确定适用的规范,因为在任何情况下,匹配运算符都是“忽略”,因此该行将始终为真,并且在此基础上执行“生成”操作,由此在每次调用处理指令时,随后的字段指令行都可以生成不同的值。例如,对于所有消息或对于由相同的源地址、相同的源端口和相同的目的地端口组成的每个元组(tuple),该值可以不同。
对于CoAP消息ID,CoAP报头的字段ID:
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
CoAP.MID | 忽略 | 生成 |
当包含与设备地址相对应的数据分量的数据消息到达发送器处理器时,发送器处理器将确定适用的规范,因为在任何情况下,匹配运算符都是“忽略”,因此该行将始终为真,并且在此基础上执行“生成”操作,由此对于CoAP消息ID,其行为可以与IPv4分段的行为相同——在每次调用处理指令时,在以下字段指令行中通过示例的方式示出的“生成”处理指令可以生成不同的值。例如,对于所有消息或对于由相同的源地址、相同的源端口和相同的目的地端口组成的每个元组,该值可以不同。这可以用于压缩非消息。
特别地,数据分量可以是分段ID,并且源可以是适于返回对应ID的校验和计算器。
例如,在IPv4中,针对分段的标识符可以由解压缩器生成,并且该标识符对于每个分组都必须不同。在IPv6中,流标签可以由解压缩器生成,但是该流标签必须对流保持相等。对于CoAP消息ID,其具有与IPv4分段ID的行为相同的行为。
在目标值的上下文中使用另外的数据分量
如果假设诸如最终用户设备之类的发送方已经实现了图2的方法以便发送与指定以下规范的规则ID相对应的标记,则Protocol.fieldID是称呼要被学习的特定字段的通用名称:
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
Protocol.field ID | Learning1(val,..) | 相等 | 未发送 |
目标值通过函数配置,该函数可以可选地具有一些参数。该函数返回例如在参考图1描述的过程中或其他过程中用作目标值的值。
如果函数存在于许多不同的字段指令行中,则可以在第一次调用服务时缓存结果,在这种情况下,可以不时地再次调用结果以刷新值,或者可以仅针对为每个字段指令行调用结果。
基于此,当确定数据消息的相应的指定区域是否以相应的规定方式对应于相应的目标值时,从规范中指定的服务中即时取回所讨论的目标值。
在某些情况下,也可能希望将获得的值通知终端设备。例如,可以使用管理协议(例如,轻量级M2M、CoMI或其他协议)通过信令协议(例如,MAC层命令)、专门分配的规则ID等来完成该操作。
作为使用上面描述的通用方法来定义目标值的一个示例,目标值可以包括被定义以便取回设备地址的标记。
以下条目示出了根据实施例的如何使用DHCP为设备动态地获得IPv6地址:
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
IPv6.prefES | DHCP(“node1”) | 相等 | 未发送 |
IPv6.IIDES | DHCP(“node1”) | 相等 | 未发送 |
当包含与设备地址相对应的数据分量的数据消息到达发送器处理器时,发送器处理器将例如通过以下操作来确定适用的规范:通过执行规范中指定的DHCP调用来填充目标值,并将其与在字段参考中指定的发送方地址字段进行比较,并假设该匹配发现适用的规范,并且考虑到“未发送”操作,省略该地址。当数据消息到达接收器处理器时,提取标记,并且作为响应,将上面列出的规范应用于数据消息,并执行新的DHCP操作以获得发送方的IP地址,并将其并入到重构的数据消息中。
该功能提供了可能期望另外地存储操作结果的情况的示例——首次从该设备发送消息时,处理器可以发送DHCP请求,从而要求为该设备分配IP地址,如上面所描述的。然后,答案将以与该设备相关联的状态存储。从这里开始,任何(去往设备/来自设备的)上行链路或下行链路消息都可以使用该IP地址。
该功能提供了可能期望另外地修改规范本身的情况的示例:处理器可以通过用恒定值(例如,“2001::1”或“10.0.0.1”)替换DHCP(“node1”)文本来永久改变规范。
另外地,该示例可以适于实现状态通信的方面的实施例,并且提出了(例如,在一方面是终端设备,并且另一方面是网络组件的情况下)其中可以取决于执行操作的设备的角色来不同地执行操作的考虑因素。在存在配置协议(信令/控制或带内)的情况下,如果网络侧是发送方,则可以确定该发送方需要执行DHCP()以便获得必要的信息。然后,发送方将消息发送到设备以配置状态,使得其还包含通过DHCP()获得的值(例如,目的地IPv6地址)。此时,网络和设备两者都具有指示要供DHCP(“node1”)函数使用的值的状态。此时,发生标准压缩/解压缩过程。
在缺少信令/控制通信协议或带内通信协议以及优化的情况下,这也可以通过非对称上下文来实现。在这种情况下,在不需要交换任何信息的情况下,网络可以能够执行DHCP,但设备不能执行DHCP。设备可以始终使用链接本地IPv6地址(例如,FE80::ABCD)作为源IP地址,将其省略,并且网络在接收时可以使用DHCP()获得全局地址以放入分组中(例如,2001::1234)。下行链路消息也使全局地址被省略,并且在接收时用链接本地地址替换。以这种方式,这高效地将压缩/解压缩转换为NAT。
最后,在设备不执行完全分组解压缩的情况下,这可能对整个系统有利。设备发送标记,该标记向网络指示它需要执行DHCP()(或任何其他机制)来确定要放入传出分组中的源地址。如果有任何下行链路,则将仅省略源地址被省略,然后将进而返回到设备,设备仅查看标记并知道如何处理它,而不需要关心标记确切拥有的IP地址。
这提供了其中不同的行为可能适合相同规范下的发送和接收行为的示例,例如,发送设备可能不一定执行DHCP调用来取回其自己的IP地址,在某些实施例中,发送设备可以从存储器中取回IP地址。
此外,在使用状态通信的实现方式中,如果设备是发送方,则可以将其配置为将DHCP()操作解释为指令,该指令指示网络将执行DHCP()查询并通过信令机制发送回必要的信息。这也可能意味着发送方应该执行DHCP调用,然后通过信令机制将值发送给接收器。这可能意味着设备可以仅省略发送方IP地址,并且该地址将由接收器侧的DHCP()填充。
前两个字段指令行使用DHCP来获取前缀。节点的名称或其MAC地址可以作为参数给出。第二对字段指令行描述了具有邻居发现的行为(SLAAC)。在这种情况下,可以提供MAC地址。
因此,该规范要求询问多个数据源。由于该规范将IPv6地址划分为两部分,因此一次可以执行单次询问,并且从第一询问中取回的数据分量例如被存储在存储装置464中以用于填充第二对字段指令行并获得完整的地址。
以下条目示出了根据实施例的如何使用SLAAC为设备动态地获得IPv6地址:
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
IPv6.prefES | SLAAC(EUI) | 相等 | 未发送 |
IPv6.IIDES | SLAAC(EUI) | 相等 | 未发送 |
此方法可能适用于其他字段(例如,TTL(IPv4)或跳数限制(IPv6))其默认值由DHCP或SLAAC返回。
作为使用上面描述的通用方法来定义目标值的另一示例,目标值可以包括被定义以便取回应用地址的标记。
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
IPv6.prefLA | DNS(“coap.ex.io”) | 相等 | 未发送 |
IPv6.IIDLA | DNS(“coap.ex.io”) | 相等 | 未发送 |
当包含与设备地址相对应的数据分量的数据消息到达发送器处理器时,发送器处理器将例如通过以下操作来确定适用的规范:通过执行规范中指定的DNS调用来填充目标值,并将其与在字段参考(IIDLA=接口标识符本地地址)中指定的应用标识符地址字段进行比较,并假设该匹配发现适用的规范,并且考虑到“未发送”操作,省略该地址。当数据消息到达接收器处理器时,提取标记,并且作为响应,将上面列出的规范应用于数据消息,并执行新的DNS操作以获得发送方的IP地址,并将其并入到重构的数据消息中。
相应地,数据源以及相应的另外的数据分量可以采用多种形式。例如,数据源可以是DNS服务器,并且标记可以指示DNS服务器和URL。基于此,另外的数据分量可以是IP地址。
例如,数据源可以是DHCP服务器,并且标记可以指示DHCP服务器和MAC地址。基于此,另外的数据分量可以是IP地址。
例如,数据源可以是适于返回指定实体的公共密钥的加密密钥服务器。基于此,标记指示加密密钥服务器和指定实体。
使用标记引用软件代码
匹配运算符、目标值或处理指令可以包含以软件语言(例如,JavaScript、lua或任何其他编程语言)编写的代码。
匹配运算符或处理指令字段的字段ID可以用于指定语言。
如上面所讨论的,匹配运算符的角色可以是用于测试字段值的有效性。可以定义诸如字段值(压缩时的原始值、解压缩后的残差)和目标值之类的参数。在规范包括对类似于编程语言的元素的调用的某些实施例中,可以根据以下3个参数来定义处理指令:压缩字段的函数、解压缩字段的函数以及应该返回的位大小,尽管在某些情况下可以指定可变的返回大小。
以下规范提供了关于编程语言元素定义的操作的示例,这些示例以JavaScript格式具体示出,但是将认识到的是,可以使用任何编程语言:
数据是特殊的字段ID,其不与报头分组中的任何字段相对应,而是指定解析的报头之后的数据。长度和位置可以用于隔离数据中的序列。规则中的附加位置条目可以给出要访问的有效载荷部分的偏移和长度。
处理指令将利用N个变元JS(a、b、c……)来调用过程JavaScript,变元中的一个包含要被执行的JavaScript代码。该JavaScript代码可以是代码段(例如,单个JavaScript表达式),或者是由多个JavaScript函数组成的程序,该程序最终可以产生预期的结果。匹配运算符的预期的结果可以是布尔值真/假(例如,当为“真”时该字段匹配,并且当为“假”时该字段不匹配)。除了JavaScript代码之外的变元可以提供执行JavaScript代码必要的所有信息,包括但不限于:字段值(FV)、目标值(TV)、压缩字段值(CFV)、与该数据消息相关联的状态、与该数据流关联的状态、与该C/D关联的状态等。
当包含具有值为0b1110000的数据分量的数据消息到达发送器处理器时,发送器处理器将调用在匹配运算符中指定的JavaScript函数ExecuteJavaScript(FieldValue,TargetValue,“FV&TV==TV”)。引号中的文本定义了一个有效的JavaScript代码,在这种情况下,该代码定义了要被评估的表达式,该表达式使用两个参数:FV(对应于字段值)和TV(对应于目标值)。一旦被评估,JavaScript代码将产生布尔值(取真或假),这是匹配运算符的预期行为。为了该表达式的执行,该表达式将通过按位与(Bitwise AND)(基于本示例中使用的JavaScript代码并以“&”表示)在字段值中指定的内容与目标值中的值0b1110000进行比较,如果该按位与的结果等于目标值(用==表示),则执行结果被评估为“真”,则确定该规范适用。还利用JavaScript表达式定义了压缩和解压缩,其中压缩定义为JS(FV,“[FV,6]”},并且解压缩被定义为JS(CFV,TV,“[CFV<<2|TV,8]”)。将认识到的是,这可以等同地被分为两个函数Compress=JS()和Decompress=JS()。
通过执行函数ExecuteJavaScript(FieldValue,“[FV,6]”)来确定压缩,而通过执行函数ExecuteJavaScript(CompressedFieldValue,TargetValue,“[CFV<<2|TV,8]”)来获得解压缩。
压缩代码“[FV,6]”返回变量FV,该变量在该示例中包含字段值和值“6”,从而指示在这种情况下为发送保留的位数,并且解压缩代码“[CFV<<2|TV,8]”提供解压缩器的二进制输出以及输出的大小,其中CFV是包含“压缩字段值”的变量,<<2指示具有2位的二进制左移,|表示按位或(Bitwise OR),TV表示目标值,并且8表示输出的位大小。
基于此,压缩器用指定上面列出的规范的标记替换数据分量,并且新的数据值对应于在字段参考中指定的数据的按位左移。当数据消息到达接收器处理器时,提取标记,并且作为响应,将上面列出的规范应用于数据消息。以与发送侧相同的方式调用并评估匹配运算符字段中的JavaScript操作,并且调用处理指令中的JavaScript操作,并且在这种情况下,目标值的值0b1110000并入到重构的数据消息中。
为了简单起见,上面已经通过示例的方式描述了一般的JavaScript操作,然而,将认识到的是,任何操作或操作序列都可以以这种方式定义。
如上面所提到的,在某些情况下,标记可以构成超出数据消息中包含的内容的信息。如参考图4的元素470和490所讨论的,该信息可以由接收器处理器添加到数据消息中。在其他实施例中,可以在发送侧将信息添加到数据消息中。
除了上面讨论的标准编程语言之外,发送处理器或接收处理器可以被配置为直接支持许多处理操作。例如:
·Delta(x),可以在其中添加或减去值,
·逻辑函数,例如,与(AND)、或(OR)、异或(XOR)、非(NOT)。例如:可以假定IP版本非6的匹配运算符返回4。
·f(x)=learning(x),其中第一则消息将填充正确的值。
·了解LPWAN应用的可能值,该值可以在已知范围内,例如,房间中的温度,它可以在19到22度之间反复,因此已知目标值在该范围内,匹配运算符为“包括”并且处理指令可能未被发送,或者发送了delta(x)。
将认识到的是,这些操作可以在目标值或匹配运算符条目中实现,在这种情况下,可以期望布尔输出,而针对处理指令条目所实现操作的,可以期望它们返回值。
图6示出了关于图4介绍的发送侧处理的变型。
图6基本上如参考图4所描述的那样再现了发送侧元件400、410、411,412、420和450。然而,在图6的情况下,在用与第一数据分量类型相关联的标记替换数据分量412的步骤处,标记633被添加到数据分组630的结构外部的数据消息中。
使用标记来引用集中式储存库
如上面所描述的,与处理操作的规范相关联的标记可以用于定义从数据源导出数据分量。将认识到的是,基于此,多个设备可以使用公共数据源。例如,当数据消息从发送设备通过多个网络节点传递到接收设备时,每个设备和每个节点可以解析该数据消息并访问单个数据源以取回数据分量。类似地,消息可以被发送到多个接收设备,每个消息引用的数据源与这些消息公共的数据分量的源相同。
方法的可能应用可以包括并入与设备管理或安全性相关的其他信息。示例包括标识发送处理器、添加cookie以在处理中引入状态、认证发送处理器或添加序列号。
可以将其视为定义在规范外部的上下文以确保系统的全局行为。这可以用于生成值或调用某种其他函数(压缩/处理)。
特别地,数据分量可以是分段校验和,并且源可以是适于返回对应的校验和的校验和计算器。
例如,在IPv4中,分段的标识符可以由解压缩器生成,并且该标识符对于每个分组都必须不同,在IPv6中,流标签可以由解压缩器生成,但是该流标签必须对流保持相等。对于CoAP消息ID,其具有与IPv4分段ID的行为相同的行为。
有效载荷签名
该处理指令可以用于添加覆盖整个消息的签名以及规则ID。除了在发送器或接收器处的替换操作之外,该处理指令还可以例如在完成压缩/解压缩之后应用,并且可以在发送SCHC消息之前构成该处理指令。添加该字段参考以计算签名,并且该字段不是消息的一部分:
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
Comp.hash | (无) | 忽略 | 哈希(秘密) |
所示的字段指令行在测试阶段始终为真,以便考虑“忽略”匹配运算符来确定该规范是否适用。假设随后应用该规范,则处理指令将诸如哈希(hash)之类的密码签名函数添加到压缩报头残差,从而支持压缩器的认证。当数据消息到达接收器处理器时,提取标记,并且作为响应,将上面列出的规范应用于数据消息。接收器进行相反的操作并验证哈希。如果哈希不正确,则丢弃该帧。密码签名函数可以导出任何输入数据(包括整个数据消息或其一部分)的签名。例如,密码签名函数可以导出特定字段的签名,或相同规范的先前指令行的输出的签名。
因此,根据图2或图3的方法,标记还可以包括数据分量的加密版本。基于此,图3的方法可以包括以下另外的步骤:使用取回的加密密钥来解密数据分量的加密版本。
Ping本地管理
该规则以常规方式描述IPv6报头和ICMPv6报头,并在描述的末尾添加comp.ping字段。当分组到达时,将其字段中的每一个与字段描述进行比较,并且如果所有字段都匹配,则选择该规则。可以注意到,Compute.ping是字段ID条目没有被分解为数据消息字段的情况的示例,并且因此在常规的字段比较中可能无法使用。作为该处的示例,示出了需要回复的Echo请求(ICMPv6类型128,代码0),因此Comp.Ping将回复该ping。
当接收器处理器收到来自互联网的消息时,如果匹配正确,则以通常方式选择规范。这导致执行回复-ping处理指令。该处理指令生成ping回复并将其发送给请求方。针对所有字段(除了comp.ping之外)的处理指令均被设置为未发送,因此不会生成任何残差数据。将针对comp.ping的处理指令设置为动作(ping答案)。该动作将接收触发规则选择的原始分组作为变元。该动作利用适当的参数构造ping响应(即,反转源地址和目的地地址的位置并改变icmpv6代码以进行回复)。该答案被发送回ping请求方,并且通知主要压缩器必须不能发送标记。
例如在LPWAN静态上下文头压缩(SCHC)中讨论的DEViid和APPiid函数和用于IPv6和UDP的分段(draft-ietf-lpwan-ipv6-static-context-hc-04)用于分别处理IPv6地址的Dev和应用接口标识符(Deviid和Appiid)。可以根据第2层报头中存在的设备ID计算IID值。该计算特定于每种LPWAN技术,并取决于设备ID的大小。在下游方向上,这些可以用于确定LPWAN使用的L2地址。
使用标记对封装的协议做标志
第一规则描述了IPv6和UDP字段。然后添加comp.SCHC字段。
当分组到达时,将其字段中的每一个与字段描述进行比较,并且如果所有字段都匹配,则选择该规则。可以注意到,Compute.ping是字段ID条目没有被分解为数据消息字段的情况的示例,并且因此在常规的字段比较中可能无法使用。
针对所有字段(除了comp.SCHC之外)的处理指令均被设置为适当的动作,这可以产生一些残差值。然后,利用其余的报头字段(例如,仅以CoAP为例)递归地调用SCHC。匹配完成,并且可以找到压缩CoAP的规则。在这种情况下,提供了标记以及残差。标记和残差的级联通过第一级压缩发送,并且由于该字段被描述为变量,因此前面带有长度。
接收器接收压缩的消息。接收器应用规则来恢复IPv6和UDP字段,并再次对不透明值调用SCHC解压缩器以解压缩其余字段。
在字段ID中,可以通过例如学习过程来添加有效载荷。在大部分用途是针对传感器的LPWAN应用中,可以快速地给出学习或压缩有效载荷的一些方式。如果期望放置更全局的应用有效载荷,则可以将该有效载荷作为协议进行处理,以学习LPWAN应用的可能值,该可能值可以在已知范围内,例如,房间中的温度,它可以在19到22度之间反复,使得目标值可以被设置为等于该范围,匹配运算符为“包括”并且处理指令可能未被发送,或者发送了delta(x)。
解压缩器对发送的值调用处理指令以处理信息。这可以导致拒绝帧或记住该信息或进行其他任何处理。
在某些情况下,诸如图1的通用方法之类的通用方法可能发生故障,因为发送处理器和/或接收处理器无法解释数据消息且无法标识其中的字段,这是因为例如它是根据发送处理器和/或接收处理器的主要压缩/解压缩机制不支持的协议进行编码的,例如如上面所描述的。由于诸如图1的方法之类的方法基于定义用于处理的字段的可能性,因此没有可用于处理这种异常消息的机制。
尽管如关于图1所讨论的,通常假定每个字段指令行的字段参考对应于由字段参考指定的数据消息的字段,但是在某些实施例中,该字段参考可以用于其他目的。特别地,在提供的字段参考条目没有有效地指定数据消息的字段的情况下,可以假定该字段参考条目用于执行某些其他功能。例如,在确定数据消息符合除了发送处理器和/或接收处理器的主要压缩/解压缩机制直接支持的协议之外的协议的情况下,可以在字段指令行的字段条目中提供不支持的协议的标识的指示,当在接收器侧应用时,该指示可以用于将所讨论的内容定向到合适的外部解码器。本文呈现的使用字段指令行的该通用方法的示例包括协议ID、有效载荷签名、Ping进程以及替代协议(GHC、RoHC、VJ)的处理。
例如,可以考虑根据以下内容的规范:
在该示例中,IPv6和UDP根据如上面所描述的主要压缩/解压缩机制进行压缩,而其余协议报头的部分则利用次要机制进行压缩,例如,在RTP的情况下,这可以通过使用RoHC形式化来实现。
规则以常规方式(例如,逐行评估匹配运算符,并在匹配之后执行处理指令)描述IPv6报头和UDP报头,其中comp.RoHC处理指令覆盖了消息的一部分——在该示例中,该部分为最终协议报头。
当分组到达时,将其字段中的每一个与字段描述进行比较,并且如果所有字段都匹配,则选择该规则。可以注意到,Compute.ping是字段ID条目没有被分解为数据消息字段的情况的示例,并且因此在常规的字段比较中可能无法使用。
针对所有字段(除了comp.rohc之外)的处理指令均被设置为适当的动作,这可以产生一些残差值。针对comp.rohc的处理指令被设置为动作(rohc压缩)。该动作将接收触发规则选择的原始分组作为变元。动作遵循RoHC算法应用次要压缩。可以注意到,该动作可以创建特定状态(即,所存储的信息),该特定状态将由RoHC压缩动作重用以处理未来的消息。结果返回给主要压缩/解压缩机制,该机制将该结果作为不透明值发送,即,该值对于主要处理机制没有任何意义/解释/语义,但只能由某种其他机制来解释。例如。值MSLKQSLDKQ可以对主要处理机制而言是不透明的,但可以表示对RoHC完全有意义的编码。注意,comp.RoHC字段描述可以被设置为变量,以指示不透明值的长度。
接收器接收具有标记的压缩报头。标记有助于查找规则,并且关于该规则处理字段。使用主要压缩/解压缩机制恢复来自IPv6和UDP的字段。然后将不透明值赋予RoHC压缩动作。使用RoHC解压缩算法,并恢复字段值。字段值被添加到未压缩的字段描述中,该字段描述将用于重构原始消息。
所示的字段指令行在测试阶段始终为真,以便考虑“忽略”匹配运算符来确定该规范是否适用。假设随后应用该规范,则处理指令将由include(x)目标值定义的不可处理残差引用到与出现在字段参考中的字段参考142相对应的RoHC压缩器(Comp.RoHC是针对RoHC的引用)。每个IETF协议具有参考ID,该参考ID用于标识所使用的协议,参见https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml。这些号可以用于包括要在Comp.Protocol中处理的不同协议。IANA号标识IETF的协议,这些号是公知的,并且可以在本发明中用于标识要被计算的不同协议以便压缩完整的报头栈。通常,该表的第一列可以用于标识消息的报头字段,还可以处理不属于原始报头但会有助于减小其大小的有效载荷、数据和协议。在协议的情况下,可以具有:Comp.RoHC、Comp.VJ、Comp.RoHCv2、Comp.SogComp、Comp.DTLS、Comp.IPSec等。
当数据消息到达接收器处理器时,提取标记,并且作为响应,将上面列出的规范应用于数据消息。接收器通过引用与出现在字段参考中的字段参考comp.RoHC相对应的不可处理的RoHC解压缩器来重复操作,并且通过目标值字段将结果调回以将其并入到输出数据消息中。
另一示例是使用通用压缩函数,例如,DEFLATE(如在ZIP中使用的)。在这种情况下,还可以将初始词典提供给压缩/解压缩函数。注意,这也与应用有效载荷相关。例如,可以对有效载荷执行无损压缩以及诸如JPEG之类的有损压缩。
例如,可以考虑根据以下内容的规范:
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
… | … | … | 未发送 |
IPv6.devIID | … | … | 未发送 |
… | … | … | … |
Comp.DEFLATE | 无 | 忽略 | DEFLATE(DICTIONNARY)| |
规则以常规方式(例如,逐行评估匹配运算符,并在匹配之后执行处理指令)描述IPv6报头和UDP报头,其中comp.DEFLATE处理指令覆盖了消息的一部分——在该示例中,该部分为最终协议报头。
这还可以用于根据本文描述的实施例的压缩的封装实例,使得可以设想实施例的多个递归应用(例如,当某些部分被加密时),以通过将规范分为若干部分来减少规范的数量。对于定义了两个COAP报头的OSCORE也可以是有用的。
规范学习
在某些实施例中,规范可以向发送器处理器或接收器处理器指示可以通过学习过程获得、改进、替换或以其他方式确定的值中的一些。
该学习过程可以基于统计采样、贝叶斯网络、神经网络、遗传算法、机器学习、数据挖掘或任何其他形式的过程,其中要考虑到给定数据流、设备、部署场景、发送器处理器或接收器处理器能力等的特定特性。
作为示例,可以在办公大楼中部署通用设备(例如,温度计),在该办公大楼中温度总是在22摄氏度左右。发送器处理器或接收器处理器可以使用上面提到的算法中的任一个来确定工作几天之后的值“22”要求改进的压缩,并特别地为其分配新的规范。在工厂中部署的相同设备可能发送的温度范围为30-35度,在这种情况下,可以针对该范围优化有效载荷压缩。
学习算法可以是对称的,例如,发送方和接收器两者都可以在它们那一侧执行学习过程。在上面的示例中,通用温度计可以具有学习算法,从而指示在5个具有特定温度(例如,22℃)的连续消息后,具有标记等于10的新的规范将被设置为该值。这也发生在接收器上,该接收器通过观察5个过去的值学习到标记的值=10等同于设置为22℃。
过程也可以是非对称的,这可能需要例如具有如上面所概括的信令协议,该信令协议将使两个发送器处理器或接收器处理器实例同步。例如,网络可以包括提供学习算法的元素,该学习算法然后将对应的值更新到终端设备。
与Comp.DEFLATE一起使用时就是这种情况,其中网络可以确定更好的DEFLATE字典并在最终设备上更新DEFLATE字典。
学习过程可以修改状态,这可以对压缩/解压缩过程产生多种影响,例如:
-启用或禁用特定规则。
o例如,这可以通过使匹配运算符查询本地状态中的变量来实现。该变量可以指示匹配运算符始终为假(例如,规则永远不匹配),直到学习过程已经达到某个目标为止。
o这也可以直接通过目标值来实现。
-修改一个或多个规则的目标值中的一个或多个。一个示例是禁用规则ID==100,直到匹配特定的IPv6目的地地址5次,此后,规则ID的目标值将等于该特定的IPv6地址,这将启用规则ID==100的规则。
实现该目的的一种可能方式是使匹配运算符执行学习阶段,并在满足某些内部条件时更新目标值。这可以通过使用学习匹配运算符(LMO)-学习目标值(LTV)的对来实现,其中LMO在相同规则的相同行上更新LTV的状态,或者可以是一个LMO在规则中的任一个的任一行上更新一个或多个LTV的状态。另外地,LMO可以执行学习,这可以影响该C/D上的函数中的任一个的状态。注意,学习可以以任何函数来执行,例如,在压缩/解压缩动作中也是如此。
图6示出了根据实施例的规范学习算法。
如图6中示出的,方法开始于步骤600,然后进行到步骤605,在步骤605处,等待下一个数据消息。
通过示例的方式,在其中定义了一个或多个规则(对应于如上面所描述的规范)的场景中描述了图6的方法,每个规则包括一个或多个字段指令行,每个字段指令行包括目标值和处理指令。
如果在步骤610处确定已经接收到新的数据消息,则方法进行到步骤615,在步骤615处,选择第一规则进行评估。然后,方法进行到步骤620,在步骤620处,考虑当前选择的规则的第一指令行进行评估。如果数据消息的指定区域以第一相应的规定方式对应于目标值(例如,如果字段值与目标值匹配),则方法进行到步骤640,在步骤640处,确定当前正在考虑的指令行是否是最后一行。在步骤640处确定当前正在考虑的指令行是最后一行的情况下,方法进行到步骤645,在步骤645处,确定当前正在考虑的规则是否是最后的规则。在步骤645处确定当前正在考虑的规则是最后的规则的情况下,方法以参考图1所讨论的通常方式,根据匹配规则来处理数据分组,然后返回步骤605。在步骤640处确定当前正在考虑的指令行不是最后一行的情况下,方法进行到步骤650,在步骤650处,选择下一指令行,然后返回步骤625。在步骤645处确定当前正在考虑的规则不是最后的规则的情况下,方法进行到步骤655,在步骤655处,选择下一个规则,然后返回步骤615。以这种方式,方法循环通过所有规则的所有字段,以便找到匹配规则,如参考图1所描述的。在步骤625处,在数据消息的指定区域没有以第一相应的规定方式对应于目标值的情况下(例如,如果字段值与目标值匹配),则方法进行到步骤630,在步骤630处,确定数据消息的指定区域是否以第二相应的规定方式对应于目标值,例如,由如上面介绍的学习匹配运算符所确定的。例如,数据消息可以在特定范围内偏离目标值。在这种情况下,方法进行到步骤635,在步骤635处,学习值指示已经发现数据消息的指定区域是否以第二相应的规定方式对应于目标值的次数。方法接下来进行到步骤636,在步骤636处,确定学习值是否超过阈值,并且在超过阈值的情况下,更新正在考虑的指令行的第一规定方式,例如以与第二规定方式匹配,然后返回步骤640。如果在步骤635处发现学习值未超过阈值,则方法直接返回步骤640。
因此,提供了一种处理多个数据消息的方法,其中定义了一个或多个规则,每个规则包括一个或多个字段指令行,每个所述字段指令行包括目标值和处理指令。
方法包括以下另外的步骤:针对规则确定每个数据消息的相应的指定区域是否以相应的规定方式对应于目标值;以及在对于预定数量的数据消息,相应的指定区域针对相应的规则中的每个字段指令行不以相应的规定方式对应于目标值的情况下,以预定方式修改目标值。
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
字段1 | LearnedValue() | Learn(“max5”) | not-sent-or-sync() |
上表中的示例显示了LTV和LMO如何一起起作用。技术人员将认识到,这是简化的结构,并且除了目标值、匹配运算符和处理指令字段之外,还可以添加附加列。对于字段1,LMO“学习”表示学习函数,它取一个参数——评估标准的名称(“max5”)。该函数是匹配运算符,当学习过程已达到足够的性能时(例如,当满足评估标准时)返回“真”,否则返回“假”。在这种情况下,评估标准可以指示最后5条消息包含相同的值。在这种场景中,可以接受该值作为目标值的值。当满足评估标准时,规则将与数据消息匹配,并且将来调用压缩/解压缩动作以压缩数据消息,其中LearnedValue()作为输入。LearnedValue()返回学习函数的结果,然后由not-sent-or-sync()CDA处理。
在该示例中,not-sent-or-sync()是一个函数,该函数考虑了发送方和接收器的状态并且使用信令/控制机制的存在。如果发送方和接收器的状态关于要被发送的值不同或是未知的,则在输出值中指示这一点,并且潜在地调用信令/控制协议。每当知道发送方和接收器两者的状态关于要被发送的值是相同的(例如,通过先前的交换),它就用作未发送。例如,可以将其实现为具有可变长度输出,每当长度为0时,就指示状态的同步是不必要的;并且如果长度大于0,则包含结构化可变长度标记(SVLM),该标记提供了必要的状态更新。
另一示例是将预定义词典用于通用压缩算法,例如,DEFLATE。例如,网络可以执行处理器密集型字典更新,并且在达到一定标准(例如,与当前/通用字典相比,新字典的压缩率提高10%)之后,可以发送新字典以由设备用于DEFLATE函数。
图7呈现了根据实施例的经由状态通信的规范学习的示例。图7的场景提供了可以由参考图6描述的方法实现的情况。如所示的,在第一设备A700与第二设备B 701之间发生一系列通信711、712、713、714、715。在开始时,学习阶段尚未执行。
A是具有标识(aa-bb-vvvvv-yyyyy)的节点,该标识在规则创建时是未知的并且可以被动态地定义。A具有两个定义的规则,一个带有标识,另一个不带有标识。想象非常简单的协议发送标识和值。规则可以如下定义:规则A1
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
ID | 无 | 忽略 | 值已发送 |
值 | 无 | 忽略 | 值已发送 |
规则A2
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
ID | 无 | 忽略 | 未发送 |
值 | 无 | 忽略 | 值已发送 |
B是需要学习设备A的标识的解压缩器。B具有包括相同内容的两个定义的规则(B1和B2),但是当A的标识未知时,使用B1,并且当A的标识已知时,使用B2。
规则B1
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
确认 | 无 | 忽略 | 值已发送 |
规则B2
字段参考 | 目标值 | 匹配运算符 | 处理指令 |
确认 | 无 | 忽略 | 未发送 |
设备A 700从设备B 701接收利用规范B1被压缩然后根据规范A1被解压缩的消息711、712。由于规范B1请求确认,因此设备A 700以消息713进行响应,消息713也利用规范A1被压缩,然后根据规范B1被解压缩。该消息713包含根据规范A1发送的ID和值字段。当设备B的接收处理器接收到该消息时,它可以学习设备B的ID。基于此,设备B然后可以使用不要求确认的规范B2发送其下一个通信714。基于此,设备A可以为不包括ID信息的下一个通信715选择规范A2,从而增加正在进行的通信的压缩程度。
如果设备B 701重启,则它可以返回到初始规范,然后设备A 700将必须重新发送学习信息。如果设备A 700改变其学习信息,则它也可以再次返回到规则1。
如上面所描述的,使用从除了数据分组本身或其所属于的流之外的源获得的信息,处理诸如以IPv4或IPv6格式的数据分组之类的数据消息以进行压缩/解压缩。这可以涉及在由共享标记标识的规范中定义的附加动态处理,或者从诸如静态文件、数据库应用等附加数据源获得的附加动态处理。本文描述的实施例利用数据分量的动态确定来增强该方法。
软件实施例包括但不限于应用、固件、驻留软件、微代码等。本发明可以采用计算机程序产品的形式,其可从计算机可使用或者计算机可读介质访问,以提供用于供计算机或指令执行系统使用或者结合计算机或指令执行系统使用的程序代码。软件实施例包括适于实现上面参考图1-4讨论的步骤的软件。计算机可使用或者计算机可读可以是任何装置,其可以包含、存储、传送、传播或者传输程序以供指令执行系统、装置或设备使用或者结合指令执行系统、装置或设备使用。介质可以是电子、磁、光、电磁、红外或者半导体系统(或者装置或者设备)或者传播介质。
在一些实施例中,本文描述的方法和过程可以部分或者全部由用户设备实现。这些方法和过程可以由计算机应用程序或服务、应用编程接口(API)、库和/或其他计算机程序产品或者这样实体的任一组合实现。
用户设备可以是移动设备(例如,智能电话或者平板)、无人机、计算机或者具有处理能力的任何其他设备,例如,机器人或者其他连接的设备,包括IoT(物联网)设备。
图8示出了适于本发明的实施例的实现方式的通用计算系统。
如图8中示出的,系统包括逻辑设备801和存储设备802。系统可以可选地包括显示接口804和显示器811、输入/输出子系统803、通信子系统820和/或未示出的其他组件。
逻辑设备801包括被配置为执行指令的一个或多个物理设备。例如,逻辑设备801可以被配置为执行作为一个或多个应用、服务、程序、例程、库、对象、分量、数据结构或者其他逻辑构造的一部分的指令。这样的指令可以被实现以执行任务、实现数据类型、变换一个或多个组件的状态、实现技术效果或者以其他方式达到期望的结果。
逻辑设备801可以包括被配置为执行软件指令的一个或多个处理器。另外地或者可替代地,逻辑设备可以包括被配置为执行硬件或固件指令的一个或多个硬件或固件逻辑设备。逻辑设备的处理器可以是单核心或者多核心的,并且在其上执行的指令可以被配置用于顺序、并行和/或分布式处理。逻辑设备801的单个组件可以可选地分布在可以远程定位和/或被配置用于协调处理的两个或更多个单独的设备之间。逻辑设备801的方面可以由以云计算配置进行配置的远程可访问的联网计算设备虚拟化并执行。
存储设备802包括被配置为保存由逻辑设备可执行以实现本文描述的方法和过程的指令的一个或多个物理设备。当这样的方法和过程被实现时,存储设备802的状态可以被变换例如以保存不同数据。
存储设备802可以包括可移除和/或内置的设备。存储设备可以被本地或者远程存储(例如,在云中)。存储设备802可以包括一种或者多种类型的存储设备,包括光学存储器(例如,CD、DVD、HD-DVD、蓝光盘等)、半导体存储器(例如,FLASH、RAM、EPROM、EEPROM等)和/或磁存储器(例如,硬盘驱动器、软盘驱动器、磁带驱动器、MRAM等)等等。存储设备可以包括易失性、非易失性、动态、静态、读取/写入、只读、随机存取、顺序存取、位置可寻址、文件可寻址和/或内容可寻址设备。
在某些布置中,系统可以包括适于支持逻辑设备801与另外的系统组件之间的通信的接口803。例如,附加的系统组件可以包括可移除和/或内置的扩展存储设备。扩展存储设备可以包括一种或者多种类型的存储设备,包括光学存储器832(例如,CD、DVD、HD-DVD、蓝光灯)、半导体存储器833(例如,RAM、EPROM、EEPROM、FLASH等)和/或磁存储器831(例如,硬盘驱动器、软盘驱动器、磁带驱动器、MRAM等)等等。这样的扩展存储设备可以包括易失性、非易失性、动态、静态、读取/写入、只读、随机存取、顺序存取、存储单元可寻址、文件可寻址和/或内容可寻址设备。
将认识到的是,存储设备包括一个或多个物理设备,并且排除传播信号本身。然而,本文描述的指令的方面可替代地可以由与存储在存储设备上相对的通信介质(例如,电磁信号、光学信号等)传播。
逻辑设备801和存储设备802的方面可以一起被集成到一个或多个硬件逻辑组件中。这样的硬件逻辑组件可以例如包括现场可编程门阵列(FPGA)、程序专用和专用集成电路(PASIC/ASIC)、程序专用和专用标准产品(PSSP/ASSP)、片上系统(SOC)和复杂可编程逻辑器件(CPLD)。
术语“程序”可以用于描述被实现以执行特定功能的计算系统的方面。在一些情况下,程序可以经由执行由存储设备802保存的机器可读指令的逻辑设备实例化。将理解的是,不同的模块可以从相同的应用、服务、代码块、对象、库、例程、API、函数等被实例化。同样,相同的程序可以由不同的应用、服务、代码块、对象、例程、API、函数等实例化。术语“程序”可以包含单个的或者成组的可执行文件、数据文件、库、驱动程序、脚本、数据库记录等。
特别地,图8的系统可以用于实现本发明的实施例。
例如,实现关于图2至图5描述的步骤的程序或者上面呈现的算法可以被存储在存储设备802中并且由逻辑设备801执行。数据消息和/或数据分量可以经由通信接口820接收和/或发送,并且特别地经由无线电网络874或者互联网875接收和/或发送。上下文或者单个规范可以经由通信接口820接收和/或发送,并且特别地经由无线电网络874或者互联网875接收和/或发送。数据消息和/或数据分量可以被缓冲或者以其他方式存储在存储设备802、831、832、833中。上下文或者单个规范可以被存储在存储设备802、831、832、833中。数据消息和/或数据分量可以是用户。单元420、470中的任一个或者所有、或者它们相应的子单元中的任一个或者所有的功能可以类似地由执行要求的功能的程序实现,根据需要与附加的专用硬件单元通信。因此,本发明可以以计算机程序的形式被体现。
将认识到的是,如本文使用的,“服务”是跨多个用户会话可执行的应用程序。服务可以可用于一个或多个系统组件、程序和/或其他服务。在一些实现方式中,服务可以运行在一个或多个服务器计算设备上。
当包括显示子系统811时,显示子系统811可以用于呈现由存储设备保存的数据的视觉表示。这一视觉表示可以采取图形用户接口(GUI)的形式。如本文所描述的,方法和过程改变由存储设备802保存的数据,并且因此变换存储设备802的状态,显示子系统811的状态同样可以被变换为视觉地表示潜在数据的改变。显示子系统811可以包括虚拟地利用例如上面讨论的任何类型技术的一个或多个显示设备。这样的显示设备可以在共享的外壳中与逻辑设备和/或存储设备组合,或者这样的显示设备可以是外围显示设备。也可以提供诸如扬声器814之类的音频输出。
当包括输入子系统时,输入子系统可以包括一个或多个用户输入设备或者与一个或多个用户输入设备接合,这些用户设备例如键盘812、鼠标813、触摸屏811或者游戏控制器(未示出)。在一些实施例中,输入子系统可以包括所选择的自然用户输入(NUI)组件或者与其接合。这样的组件可以是集成的或者是外围的,并且输入动作的换能和/或处理可以被在板上或者离板处理。示例NUI组件可以包括用于语音和/或声音识别的麦克风815;用于机器视觉和/或手势识别的红外、彩色、立体和/或深度相机816;用于运动检测和/或意图识别的头部跟踪器、眼部跟踪器、加速计和/或陀螺仪;以及用于评估大脑活动的电场感测组件。输入/输出接口803可以类似地与扬声器814、振动电机或者任和其他换能器设备(如本领域技术人员可以想到的)接合。例如,系统可以与打印机817接合。
当包括通信子系统820时,通信子系统820可以被配置为将计算系统与一个或多个其他计算设备通信地耦合。例如,通信模块经由任何大小的网络将计算设备通信地耦合到例如托管在远程服务器876上的远程服务,该网络例如包括个域网、局域网、广域网或者互联网。通信子系统可以包括与一个或多个不同的通信协议兼容的有线和/或无线通信设备。作为非限制示例,通信子系统可以被配置用于经由无线电话网络874或者有线或无线局域网或者广域网通信。在一些实施例中,通信子系统可以允许计算系统经由诸如互联网875之类的网络向其他设备发送消息和/或从其他设备接收消息。通信子系统可以另外地支持利用无源或者有源设备(NFC、RFID、UHF等)的短距离感应通信。在上面描述的实施例的某些变型中,业务数据可以经由无线电网络874或者互联网875接收。
图8的系统旨在反映宽范围的不同类型的信息处理系统。将认识到的是,关于图8描述的子系统和特征中的许多对于本发明的实现方式并非是要求的,而是被包括以反映根据本发明的可能的系统。将认识到的是,系统架构宽泛地变化,并且图8的不同子系统之间的关系只是示意性的,并且可能关于系统中的布局和角色分配而变化。将认识到的是,在实践中,系统可能并入关于图8描述的各种特征和子系统的不同子集。
包括参考图8描述的系统的至少一些元件并且适于实现本发明的实施例的设备的示例包括:包括智能电话的蜂窝电话手持设备、以及车辆导航系统、分布式传感器、智能家用电器、连接的工业基础设施装置、智能城市实现方式或组件、智能能源消耗实现方式或组件,从而找到物体或者人、医疗、应急服务、农业、用于人类和其他物种的可穿戴传感器等等。
图8示出了适于构成实施例的独立传感器设备。图8的独立传感器设备800可以表示典型的“物联网”组件。这样的设备经常关于通信带宽、功耗、处理和存储器容量受到显著约束,并且因此可以得益于前述讨论中呈现的机制中的许多机制。如图8中示出的,独立传感器设备并入元件801、802、803、820,以及传感器设备860。独立传感器设备经由网络875与无线电网络874和服务器876通信。也可以使用诸如专用网络或者Wi-Fi之类的替代的通信机制。
如所示的,传感器设备是温度传感器,然而将认识到的是,传感器设备可以等同地体现任何其他类型的传感器或者其他换能器或者适合于设备的角色的多个换能器。
将理解的是,本文描述的配置和/或方法在本质上是示例性的,并且这些具体实施例或者示例不应被认为具有限制性意义,因为各种变型是可能的。本文描述的具体例程或者方法可以表示任何数目的处理策略中的一个或多个。因此,所示出和/或描述的各种动作可以以所示出和/或描述的序列、以其他序列、并行地执行或者被省略。同样,上面描述的过程的次序可以改变。
本公开的主题包括本文公开的各种过程、系统和配置以及其他特征、功能、动作和/或属性的所有新颖且非显而易见的组合和子组合,以及其任何和所有等同物。
Claims (15)
1.一种处理用于发送的数据消息的方法,所述方法包括以下步骤:解析所述数据消息的字段以获取第一类型的数据分量,其中,所述第一类型的所述数据分量能够从除了与所述数据消息相关联的数据流之外的数据源导出;向所述数据消息添加标记,所述标记与定义所述导出的处理操作的规范相关联。
2.根据权利要求1所述的方法,其中,将与所述第一数据分量类型相关联的标记添加到所述数据消息的所述步骤包括:用所述标记替换所述数据分量。
3.一种处理所接收的数据消息的方法,所述方法包括以下步骤:从所述数据消息中提取与第一数据分量类型相关联的标记;以及通过关于除了与所述数据消息相关联的数据流之外的数据源的处理操作来导出另外的数据分量,其中,所述处理操作是在与所述标记相关联的规范中定义的。
4.根据权利要求3所述的方法,包括以下另外的步骤:利用所述另外的数据分量重构所述数据分量。
5.根据权利要求3或4所述的方法,包括以下另外的步骤:将所述另外的数据分量添加到所述数据消息。
6.根据权利要求3、4或5所述的方法,包括以下另外的步骤:存储所述另外的数据分量;以及在解析另外的数据消息的区域以获取与第一数据分量类型相关联的标记的所述步骤的另外的迭代中,取回所存储的替代数据,而不是重复询问与所述标记相关联的数据源的所述步骤。
7.根据前述权利要求中任一项所述的方法,其中,所述数据源是DNS服务器,并且其中,所述标记指示所述数据源和URL,并且其中,所述替代数据是IP地址。
8.根据权利要求1至6中任一项所述的方法,其中,所述数据源是DHCP服务器,并且其中,所述规范指示所述数据源和MAC地址,并且其中,所述另外的数据分量是IP地址。
9.根据权利要求1至6中任一项所述的方法,其中,所述数据源是适于返回指定实体的加密密钥的加密密钥服务器,并且其中,所述规范指示所述数据源和所述指定实体。
10.根据权利要求1至6中任一项所述的方法,其中,所述标记还包括所述数据分量的加密版本,所述方法包括以下另外的步骤:使用所述取回的加密密钥来解密所述数据分量的所述加密版本。
11.根据权利要求1至6中任一项所述的方法,其中,所述数据分量是分段校验和,并且其中,所述源是适于返回对应的校验和的校验和计算器。
12.根据前述权利要求中任一项所述的方法,其中,定义了一个或多个规则,每个所述规则包括一个或多个字段指令行,每个所述字段指令行包括目标值和处理指令;
所述方法包括以下另外的步骤:针对所述规则确定所述数据消息的相应的指定区域是否以相应的规定方式对应于所述目标值,并且在所述相应的指定区域针对相应的所述规则中的每个字段指令行以所述相应的规定方式对应于所述目标值的情况下,关于所述相应的指定区域,应用所述对应的规则中的每个字段指令行的处理指令,其中,如由所述处理指令定义的那样处理所述数据分量。
13.一种计算机程序,包括适于实现根据权利要求1至11中的任一项所述的步骤的指令。
14.一种用于处理数据消息的发送处理器,所述发送处理器适于进行以下操作:解析所述数据消息的字段以获取第一类型的数据分量,其中,所述第一类型的所述数据分量能够从除了与所述数据消息相关联的数据流之外的数据源导出;以及向所述数据消息添加标记,所述标记与定义所述导出的处理操作的规范相关联。
15.一种用于处理所接收的数据消息的接收处理器,所述接收处理器适于进行以下操作:从所述数据消息中提取与第一数据分量类型相关联的标记;以及通过关于除了与所述数据消息相关联的数据流之外的数据源的处理操作来导出另外的数据分量,其中,所述处理操作是在与所述标记相关联的规范中定义的。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP18305301.6A EP3541040B1 (en) | 2018-03-16 | 2018-03-16 | Method and apparatus for processing message data |
EP18305301.6 | 2018-03-16 | ||
PCT/EP2019/056338 WO2019175275A1 (en) | 2018-03-16 | 2019-03-13 | Method and apparatus processing of message data |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112385193A true CN112385193A (zh) | 2021-02-19 |
CN112385193B CN112385193B (zh) | 2022-11-04 |
Family
ID=61827658
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201980029289.0A Active CN112385193B (zh) | 2018-03-16 | 2019-03-13 | 处理消息数据的方法和装置 |
Country Status (5)
Country | Link |
---|---|
US (2) | US11303738B2 (zh) |
EP (2) | EP4030738A1 (zh) |
CN (1) | CN112385193B (zh) |
ES (1) | ES2921983T3 (zh) |
WO (1) | WO2019175275A1 (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3731044B1 (en) * | 2019-04-26 | 2022-09-07 | Kabushiki Kaisha Yaskawa Denki | Communication system and communication method |
CN112148694B (zh) * | 2019-06-28 | 2022-06-14 | 华为技术有限公司 | 一种用于电子设备的数据压缩、数据解压方法及电子设备 |
CN114253479B (zh) * | 2021-12-20 | 2023-06-20 | 国汽(北京)智能网联汽车研究院有限公司 | 一种can总线入侵检测方法及系统 |
CN114860693B (zh) * | 2022-05-30 | 2024-04-19 | 北京方胜有成科技股份有限公司 | 一种智能终端结构化数据管理方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6647428B1 (en) * | 2000-05-05 | 2003-11-11 | Luminous Networks, Inc. | Architecture for transport of multiple services in connectionless packet-based communication networks |
JP2004046393A (ja) * | 2002-07-10 | 2004-02-12 | Mebius Corp | データ処理の方法 |
CN102196058A (zh) * | 2011-05-19 | 2011-09-21 | 清华大学深圳研究生院 | 一种6LoWPAN协议中地址压缩控制表的维护方法 |
WO2017155703A1 (en) * | 2016-03-08 | 2017-09-14 | Qualcomm Incorporated | System, apparatus and method for generating dynamic ipv6 addresses for secure authentication |
Family Cites Families (73)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2002339605A1 (en) * | 2001-11-06 | 2003-05-19 | Koninklijke Philips Electronics N.V. | Wireless communication arrangements with encapsulation and header compression |
US20070253430A1 (en) * | 2002-04-23 | 2007-11-01 | Minami John S | Gigabit Ethernet Adapter |
US7286536B2 (en) * | 2002-10-28 | 2007-10-23 | Nokia Corporation | Method and system for early header compression |
US7188250B1 (en) * | 2002-12-13 | 2007-03-06 | Nvidia Corporation | Method and apparatus for performing network processing functions |
US7397797B2 (en) * | 2002-12-13 | 2008-07-08 | Nvidia Corporation | Method and apparatus for performing network processing functions |
US7533184B2 (en) * | 2003-06-13 | 2009-05-12 | Microsoft Corporation | Peer-to-peer name resolution wire protocol and message format data structure for use therein |
US8767704B2 (en) * | 2003-10-17 | 2014-07-01 | Nokia Solutions And Networks Oy | Compressing header data |
US7826470B1 (en) * | 2004-10-19 | 2010-11-02 | Broadcom Corp. | Network interface device with flow-oriented bus interface |
US7958227B2 (en) * | 2006-05-22 | 2011-06-07 | Mcafee, Inc. | Attributes of captured objects in a capture system |
US10075182B2 (en) * | 2006-10-13 | 2018-09-11 | Qualcomm Incorporated | Message compression |
US8165124B2 (en) * | 2006-10-13 | 2012-04-24 | Qualcomm Incorporated | Message compression methods and apparatus |
US8416788B2 (en) * | 2007-04-26 | 2013-04-09 | Microsoft Corporation | Compression of data packets while maintaining endpoint-to-endpoint authentication |
CN101364980B (zh) * | 2007-08-10 | 2012-06-20 | 华为技术有限公司 | 建立头压缩通信的方法及系统、头压缩策略功能实体 |
US7852774B2 (en) * | 2007-11-28 | 2010-12-14 | Cisco Technology, Inc. | User datagram protocol traceroute probe extension |
US8396954B2 (en) * | 2010-06-24 | 2013-03-12 | Aryaka Networks, Inc. | Routing and service performance management in an application acceleration environment |
US8612530B1 (en) * | 2011-05-27 | 2013-12-17 | Mu Dynamics, Inc. | Pass-through testing using message exchange identifiers |
US8897298B2 (en) * | 2011-11-02 | 2014-11-25 | Qualcomm Incorporated | Systems and methods for compressing headers and payloads |
WO2013088323A2 (en) * | 2011-12-16 | 2013-06-20 | Koninklijke Philips Electronics N.V. | Operation of wireless resource-constrained devices in ip networks |
US9100291B2 (en) * | 2012-01-31 | 2015-08-04 | Db Networks, Inc. | Systems and methods for extracting structured application data from a communications link |
US20180375841A1 (en) * | 2012-05-24 | 2018-12-27 | Smart Security Systems Llc | Systems and methods for enterprise communications |
US20150295807A1 (en) * | 2012-08-02 | 2015-10-15 | Telefonaktiebolaget L M Ericsson (Publ) | Manipulation of streams of monitoring data |
US9769701B2 (en) * | 2013-06-14 | 2017-09-19 | Texas Instruments Incorporated | Header compression for wireless backhaul systems |
US9241044B2 (en) * | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
US9350550B2 (en) * | 2013-09-10 | 2016-05-24 | M2M And Iot Technologies, Llc | Power management and security for wireless modules in “machine-to-machine” communications |
US9894100B2 (en) | 2014-12-30 | 2018-02-13 | Fortinet, Inc. | Dynamically optimized security policy management |
US10127280B2 (en) * | 2015-02-25 | 2018-11-13 | Sumo Logic, Inc. | Automatic recursive search on derived information |
US9838243B2 (en) * | 2015-03-24 | 2017-12-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Transformative requests |
JP6256883B2 (ja) * | 2015-03-25 | 2018-01-10 | 国立大学法人 筑波大学 | データ圧縮・解凍システム、データ圧縮方法及びデータ解凍方法、並びにデータ圧縮器及びデータ解凍器 |
US11057446B2 (en) * | 2015-05-14 | 2021-07-06 | Bright Data Ltd. | System and method for streaming content from multiple servers |
CN108353029B (zh) * | 2015-06-25 | 2021-02-26 | Nec实验室欧洲有限公司 | 用于管理计算网络中的数据业务的方法和系统 |
US10944590B2 (en) * | 2015-12-10 | 2021-03-09 | Nicira, Inc. | Transport protocol task offload emulation to detect chunks of data for communication with a private network |
US10911579B1 (en) * | 2016-03-01 | 2021-02-02 | Amazon Technologies, Inc. | Generating programmatically defined fields of metadata for network packets |
GB2549997B (en) * | 2016-04-19 | 2019-07-03 | Cisco Tech Inc | Management of content delivery in an IP network |
US10333769B2 (en) * | 2016-06-09 | 2019-06-25 | LGS Innovations LLC | Deployable linear bitwise protocol transformation |
US10432509B2 (en) * | 2016-06-14 | 2019-10-01 | Cisco Technology, Inc. | Flow classification for information centric network protocols |
US10841222B2 (en) * | 2016-07-05 | 2020-11-17 | Ologn Technologies Ag | Systems, apparatuses and methods for network packet management |
US10374947B2 (en) * | 2016-09-30 | 2019-08-06 | Huawei Technologies Co., Ltd. | Method and apparatus for encapsulating / decapsulating data packets at a radio access node |
US10749995B2 (en) * | 2016-10-07 | 2020-08-18 | Cisco Technology, Inc. | System and method to facilitate integration of information-centric networking into internet protocol networks |
US9692784B1 (en) * | 2016-10-25 | 2017-06-27 | Fortress Cyber Security, LLC | Security appliance |
US11032739B2 (en) * | 2017-03-10 | 2021-06-08 | Convida Wireless, Llc | Dynamic header compression for constrained networks |
US10630654B2 (en) * | 2017-03-22 | 2020-04-21 | Microsoft Technology Licensing, Llc | Hardware-accelerated secure communication management |
US11036438B2 (en) * | 2017-05-31 | 2021-06-15 | Fmad Engineering Kabushiki Gaisha | Efficient storage architecture for high speed packet capture |
US11128740B2 (en) * | 2017-05-31 | 2021-09-21 | Fmad Engineering Kabushiki Gaisha | High-speed data packet generator |
US10999220B2 (en) * | 2018-07-05 | 2021-05-04 | Vmware, Inc. | Context aware middlebox services at datacenter edge |
US11159658B2 (en) * | 2018-07-23 | 2021-10-26 | Moj.Io, Inc. | Homogenization of telematics data through unified messaging protocol |
US10917389B2 (en) * | 2018-07-31 | 2021-02-09 | Splunk Inc. | Trusted tunnel bridge |
EP3644573B1 (en) * | 2018-10-24 | 2021-04-21 | Acklio | Simple communication protocol for data transmission over constrained networks |
CN111510419B (zh) * | 2019-01-31 | 2021-03-30 | 华为技术有限公司 | 一种数据压缩的方法及基站 |
LT3780547T (lt) * | 2019-02-25 | 2023-03-10 | Bright Data Ltd. | Turinio parsisiuntimo, naudojant url bandymų mechanizmą, sistema ir būdas |
WO2020176222A2 (en) * | 2019-02-28 | 2020-09-03 | Futurewei Technologies, Inc. | Compressed data transmissions in networks implementing interior gateway protocol |
WO2020198359A1 (en) * | 2019-03-27 | 2020-10-01 | Apple Inc. | Ethernet header compression |
US11411922B2 (en) * | 2019-04-02 | 2022-08-09 | Bright Data Ltd. | System and method for managing non-direct URL fetching service |
US11411948B2 (en) * | 2019-04-04 | 2022-08-09 | Cisco Technology, Inc. | Systems and methods for applying attestation tokens to LISP messages |
GB2583112B (en) * | 2019-04-16 | 2023-02-01 | Cisco Tech Inc | Efficient protection for an IKEv2 device |
US10884960B2 (en) * | 2019-04-19 | 2021-01-05 | Cisco Technology, Inc. | Offloading data movement for packet processing in a network interface controller |
US11570100B2 (en) * | 2019-04-25 | 2023-01-31 | Advanced New Technologies Co., Ltd. | Data processing method, apparatus, medium and device |
US10880211B2 (en) * | 2019-05-06 | 2020-12-29 | Seth Gregory Friedman | Transaction encoding and verification by way of data-link layer fields |
US11343185B2 (en) * | 2019-05-20 | 2022-05-24 | Citrix Systems, Inc. | Network traffic steering with programmatically generated proxy auto-configuration files |
US11394813B1 (en) * | 2019-07-10 | 2022-07-19 | Ethernovia Inc. | Protocol independent data unit forwarding |
KR102434217B1 (ko) * | 2019-08-23 | 2022-08-19 | 아서스테크 컴퓨터 인코포레이션 | 무선 통신 시스템에서 사이드링크 무선 베어러에 대한 헤더 압축 구성 방법 및 장치 |
US11616850B1 (en) * | 2019-08-23 | 2023-03-28 | Fitbit, Inc. | Connection management techniques |
US10868707B1 (en) * | 2019-09-16 | 2020-12-15 | Liquid-Markets-Holdings, Incorporated | Zero-latency message processing with validity checks |
US20200177660A1 (en) * | 2020-02-03 | 2020-06-04 | Intel Corporation | Offload of streaming protocol packet formation |
US11394582B2 (en) * | 2020-02-04 | 2022-07-19 | 360 It, Uab | Multi-part TCP connection over VPN |
US11223705B2 (en) * | 2020-03-06 | 2022-01-11 | Cisco Technology, Inc. | Techniques to dynamically negotiate and provide compression for packet forwarding control protocol (PFCP) messages |
US11934330B2 (en) * | 2020-05-08 | 2024-03-19 | Intel Corporation | Memory allocation for distributed processing devices |
US10904012B1 (en) * | 2020-07-12 | 2021-01-26 | Fraudmarc Inc. | Email authentication and data integrity validation |
US11722488B2 (en) * | 2020-07-29 | 2023-08-08 | Cujo LLC | Non-intrusive / agentless network device identification |
US11374859B2 (en) * | 2020-08-04 | 2022-06-28 | Pensando Systems, Inc. | Flow table programming using flow miss metadata and burst action assist via CPU offload |
US11343715B1 (en) * | 2020-08-23 | 2022-05-24 | Rockwell Collins, Inc. | Header compression for network |
US20220085916A1 (en) * | 2020-12-26 | 2022-03-17 | Intel Corporation | Scalable protocol-agnostic reliable transport |
US20220215948A1 (en) * | 2021-01-07 | 2022-07-07 | Abiomed, Inc. | Network-based medical apparatus control and data management systems |
US20220291928A1 (en) * | 2022-05-03 | 2022-09-15 | Intel Corporation | Event controller in a device |
-
2018
- 2018-03-16 EP EP22160606.4A patent/EP4030738A1/en active Pending
- 2018-03-16 EP EP18305301.6A patent/EP3541040B1/en active Active
- 2018-03-16 ES ES18305301T patent/ES2921983T3/es active Active
-
2019
- 2019-03-13 CN CN201980029289.0A patent/CN112385193B/zh active Active
- 2019-03-13 WO PCT/EP2019/056338 patent/WO2019175275A1/en active Application Filing
- 2019-03-13 US US16/980,403 patent/US11303738B2/en active Active
-
2022
- 2022-03-07 US US17/688,581 patent/US11622030B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6647428B1 (en) * | 2000-05-05 | 2003-11-11 | Luminous Networks, Inc. | Architecture for transport of multiple services in connectionless packet-based communication networks |
JP2004046393A (ja) * | 2002-07-10 | 2004-02-12 | Mebius Corp | データ処理の方法 |
CN102196058A (zh) * | 2011-05-19 | 2011-09-21 | 清华大学深圳研究生院 | 一种6LoWPAN协议中地址压缩控制表的维护方法 |
WO2017155703A1 (en) * | 2016-03-08 | 2017-09-14 | Qualcomm Incorporated | System, apparatus and method for generating dynamic ipv6 addresses for secure authentication |
Also Published As
Publication number | Publication date |
---|---|
US11622030B2 (en) | 2023-04-04 |
EP3541040A1 (en) | 2019-09-18 |
US20210051218A1 (en) | 2021-02-18 |
US20220201102A1 (en) | 2022-06-23 |
WO2019175275A1 (en) | 2019-09-19 |
ES2921983T3 (es) | 2022-09-05 |
EP3541040B1 (en) | 2022-04-13 |
US11303738B2 (en) | 2022-04-12 |
CN112385193B (zh) | 2022-11-04 |
EP4030738A1 (en) | 2022-07-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112385193B (zh) | 处理消息数据的方法和装置 | |
US11038990B2 (en) | Methods and apparatus to compress packets in a computing environment | |
JP6906498B2 (ja) | メッセージ送信及び受信方法及び装置 | |
WO2019129201A1 (en) | Session management for communications between a device and a dtls server | |
US8949617B2 (en) | Disrupting password attack using compression | |
US11388262B2 (en) | Compression context setup for data transmission for IOT devices | |
JP2022545081A (ja) | 帯域幅拡張のための特徴ディクショナリ | |
US11394537B2 (en) | Homomorphic encryption with quantum key distribution encapsulation | |
GB2572537A (en) | Generating or obtaining an updated neural network | |
WO2019019593A1 (zh) | 无状态通信安全签名方法、终端及服务器端 | |
CN112272935B (zh) | 处理消息数据的方法和装置 | |
US20220103634A1 (en) | Device registration mechanism | |
CN112335212B (zh) | 消息数据的处理的方法和装置 | |
US20210044971A1 (en) | Security Credentials Recovery in Bluetooth Mesh Network | |
CN112422525B (zh) | 一种故障数据传输方法、装置、设备及存储介质 | |
CN116708589B (zh) | 包头的压缩方法、装置、计算机设备和存储介质 | |
US11438230B2 (en) | Template-based registration of devices | |
US11106634B1 (en) | Systems and methods for randomized file segmentation and storage | |
CN115967717B (zh) | 基于中继集群的通信方法和装置 | |
CN111600846B (zh) | 一种网关设备的恢复方法和恢复系统 | |
Tömösközi | Machine learning for flow compression | |
CN117597891A (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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |