Coap协议学习总结

第一篇：Coap协议学习总结

Coap协议学习总结

1、Coap协议介绍

在2010年3月，CoRE工作组开始制定CoAP协议，到目前为止，该协议还没有定稿。CoAP协议是为物联网中资源受限设备制定的应用层协议。CoAP 是受限制的应用协议(Constrained Application Protocol)的代名词。在最近几年的时间中，专家们预测会有更多的设备相互连接，而这些设备的数量将远超人类的数量。在这种大背景下，物联网和 M2M技术应运而生。虽然对人而言，连接入互联网显得方便容易，但是对于那些微型设备而言接入互联网非常困难。在当前由PC机组成的世界，信息交换是通过 TCP和应用层协议HTTP实现的。但是对于小型设备而言，实现TCP和HTTP协议显然是一个过分的要求。为了让小设备可以接入互联网，CoAP协议被 设计出来。CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常的小巧，最小的数据包仅为4字节。

为了克服HTTP对于受限环境的劣势，CoAP既考虑到数据报长度的最优化，又考虑到提供可靠通信。一方面，CoAP提供URI，REST 式的方法如GET，POST，PUT和DELETE，以及可以独立定义的头选项提供的可扩展性。另一方面，CoAP基于轻量级的UDP协议，并且允许IP 多播。而组通信是物联网最重要的需求之一，比如说用于自动化应用中。为了弥补UDP传输的不可靠性，CoAP定义了带有重传机制的事务处理机制。并且提供 资源发现机制，并带有资源描述。

CoAP协议不是盲目的压缩了HTTP协议，考虑到资源受限设备的低处理能力和低功耗限制，CoAP重新设计了HTTP的部分功能以适应设备的约束条件。另外，为了使协议适应物联网和M2M应用，CoAP协议改进了一些机制，同时增加了一些功能。下图1显示了HTTP和CoAP的协议栈。CoAP和HTTP在传输层有明显的区别。HTTP协议的传输层采用了TCP协议，而CoAP协议的传输层使用UDP 协议，开销明显降低，并支持多播。

事务层(Transaction layer)用于处理节点之间的信息交换，同时提供组播和拥塞控制等功能。请求／响应层(Request／Responselayer)用于传输对资源进行操作的请求和响应信息。CoAP协议的REST构架是基于该层的通信。CoAP的双层处理方式，使得CoAP没有采用TCP协议，也可以提供可靠的传输 机制。利用默认的定时器和指数增长的重传间隔时间实现CON(Confirmable)消息的重传，直到接收方发出确认消息。另外，CoAP的双层处理方 式支持异步通信，这是物联网和M2M应用的关键需求之一。

2、CoAP协议是否可以替换HTTP协议？

CoAP并不能替代HTTP协议，但是对于那些小设备（256KB Flash 32KB RAM 20MHz主频）而言CoAP的确是一个好的解决方案。

3、CoAP的交互模型和消息类型

CoAP使用类似于HTTP的请求／响应模型：CoAP终端节点作为客户端向服务器发送一个或多个请求，服务器端回复客户端的CoAP请求。不同于 HTTP，CoAP的请求和响应在发送之前不需要事先建立连接，而是通过CoAP信息来进行异步信息交换。CoAP协议使用UDP进行传输。这是通过信息层选项的可靠性来实现的。CoAP采用和HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。

CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。ACK——应答消息，如果接受到CON消息的响应。

RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。虽然CoAP协议目前还在制定当中，但Contiki和TinyOS嵌入式操作系统已经支持CoAP协议。Contiki是一个多任务操作系统，并带有uIPv6协议栈，适用于嵌入式系统和无线传感器网络，它占用系统资源小，适用于资源受限的网络和设备。目前，火狐浏览器已经集成了Copper插件，从而实现了CoAP协议。但是这种方式只能读取传感器节点上的实时数据，而不能查看各种历史数据。为此，在Contiki系统的基础上，基于uIPv6START KIT无线网络开发套件，用自己编写的客户端程序实现了和数据库的交互，把历史数据存入数据库中，从而在Web浏览器端不仅可以访问传感器节点上的实时数 据，还能查看历史数据，以便于分析问题。

4、CoAP消息结构

一个CoAP消息最小为4个字节，以下是CoAP协议不同部分的描述。【版本Version】：类似于IPv6和IPv6，仅仅是一个版本号。

【消息类型Message Type】：CON，NON，ACK，RST。这些消息类型相当于HTTP协议的PUTGET等

【消息ID Message ID】：每个CoAP消息都有一个ID，在一次会话中ID总是保持不变。但是在这个会话之后该ID会被回收利用。【标记 Token】：标记是ID的另一种表现、【选项 Options】：CoAP选项类似于HTTP请求头，它包括CoAP消息本身，例如CoAP端口号，CoAP主机和CoAP查询字符串等。【负载Payload】：真正有用的被交互的数据。

图 CoAP消息结构

5、CoAP的URL

在 HTTP的世界中，正式RESTFul协议由于其简单性和适用性，在WEB应用中越来越受欢迎，这样的道理同样适用于CoAP。一个CoAP资源可以被一 个URI所描述，例如一个设备可以测量温度，那么这个温度传感器的URI被描述为：CoAP://machine.address:5683 /sensors/temperature。请注意，CoAP的默认UDP端口号为5683。

6、CoAP观察模式

在物联网的世界中，你需要去监控某个传感器例如温度或湿度等。在这种情况下，CoAP客户端并不需要不停的查询CoAP服务器端的数据变化情况。CoAP客 户端可以发送一个观察请求到服务器端。从该时间点开始计算，服务器便会记住客户端的连接信息，一旦温度发生变化，服务器将会把新结果发送给客户端。如果客 户端不在希望获得温度检测结果，那么客户端将会发送一个RST复位请求，此时服务器便会清除与客户端的连接信息。

7、CoAP块传输

CoAP协议的特点是传输的内容小巧精简，但是在某些情况下不得不传输较大的数据。在这种情况下可以使用CoAP协议中的某个选项设定分块传输的大小，那么无论是服务器或客户端可完成分片和组装这两个动作。

8、CoAP协议的特点：

（1）报头压缩：CoAP包含一个紧凑的二进制报头和扩展报头。它只有短短的4 B的基本报头，基本报头后面跟扩展选项。一个典型的请求报头为10～20B。

报头部分各字段的含义如下：V(Version)表示CoAP协议的版本号；T(Type)表示消息的信息类型；OC(Option Count)表示头后面的可选的选项数量；Code表示消息的类型：请求消息、响应消息，或者是空消息；Message ID表示消息编号，用于重复消息检测、匹配消息类型等。

（2）方法和URIs：为了实现客户端访问服务器上的资源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP还支持URIs，这是Web架构的主要特点。(3)传输层使用UDP协议：CoAP协议是建立在UDP协议之上，以减少开销和支持组播功能。它也支持一个简单的停止和等待的可靠性传输机制。

(4)支持异步通信：HTTP对M2M(Machine-to-Machine)通信不适用，这是由于事务总是由客户端发起。而CoAP协议支持异步通信，这对M2M通信应用来说是常见的休眠／唤醒机制。

(5)支持资源发现：为了自主的发现和使用资源，它支持内置的资源发现格式，用于发现设备上的资源列表，或者用于设备向服务目录公告自己的资源。它支持RFC5785中的格式，在CoRE中用／．well—known／core的路径表示资源描述。

(6)支持缓存：CoAP协议支持资源描述的缓存以优化其性能。

(7)订阅机制：CoAP使用异步通信方式，用订阅机制实现从服务器到客户端的消息推送。实现CoAP的发布，订阅机制，它是请求成功后自动注册的 一种资源后处理程序。是由默认的EVENT_和PERIODIC_RESOURCEs来进行配置的。它们的事件和轮询处理程序用 EST．notify_subscri bers()函数来发布。

9、CoAP协议的火狐浏览器实现（B/S架构）

B/S架构的系统结构如图9所示

系统由用户浏览器、Web服务器、IPv6智能网关、MX231CC节点组成。用户浏览器通过HTTP协议访问Web服务器，MX231CC节点通 过CoAP协议和IPv6智能网关进行通信，从而实现用户浏览器访问节点上资源的功能。图9中实线表示有线连接，虚线表示无线连接。

在当前的Contiki 2.5中，集成了CoAP 03和CoAP06这两个版本。这两个文件在Contiki 2.5的apps目录下，关于CoAP的核心内容都在这两个文件中。程序的主要部分为：

AUTOSTART_PROCESSES（PERIODIC_RESOURCE（）为进程的主体部分。

然后进行编译，编译成.elf文件，用JTAG下载器下载到节点上。节点地址设置为：2001：2：：11：22ff：：fe33：4499.这时，用火狐浏览器访问节点，因为火狐浏览器自带coap插件，如果用其他浏览器，那么需要进行coap的代理设置。以控制节点上的三色LED灯反转为例，用下 面的请求格式：GETcoap://［］：

/readings其中mote_ip_address是节点的IPv6地址，port_number是节点的端口号，readings是客户端请求的资源（温度）。

所以在浏览器地址栏输入：coap://［2001：2：：11：22ff：fe33：4499］：61616/toggle，作用是让节点上的三色LED灯进行反转。服务器端的响应信息如图10所示。

从浏览器端可以看出，CoAP协议支持Discover和Observe功能，具有GET、POST、PUT和DELETE等方法。Type表示信 息类型为ACK，Code为200，表示成功完成客户端的请求。事务ID为38 264，它用于重复信息检测，options为1表示有一个可选项，内容类型为text表示文本类型。

由此可以看出，通过火狐浏览器的CoAP协议，可以访问节点上的传感器资源。

10、CoAP协议的客户端实现（C/S架构）

通过火狐浏览器可以实现COAP协议，但是只能查看实时数据，不能查看历史数据。为此，这里搭建了一个C/S架构的环境。如图11所示。

图11中客户端软件是用基于。NET架构的C#语言编写的，数据库使用SQL Server 2008.通过此程序，可以每隔10 s读取一次数据，存入到数据库中。并可以通过前台的Web界面查看各种历史数据，包括温度、湿度、亮度等。

插入数据库中的数据如图12所示，图中显示的是室内的亮度值。

在Web浏览器端可以查看实时和历史数据，页面显示效果如图13所示。

由此看出，基于C/S架构的方式，不仅可以显示实时数据，还可以查看历史数据，以便及时发现问题，更加具有实用性。

第二篇：外文翻译Lithe物联网中的轻量级安全CoAP协议

Lithe:物联网中的轻量级安全CoAP协议

摘要：物联网支持广泛的包含潜在驱动和传感任务的应用场景，例如，在电子健康领域。为了在应用层通信，资源受限的设备要能够使用资源受限的应用协议（CoAP），目前互联网工程组正在使这项协议标准化。为了保护感知信息的传送，安全的资源受限协议授权使用数据报传输层安全协议（DTLS）作为底层安全协议来进行身份认证和保密通信。然而，数据包传输层安全协议最初是用在比较强大的设备上的，这些设备通过可靠的高带宽的链路来进行通信。在这篇论文中我们提出了Lithe——物联网中数据报传输层安全协议和资源受限的应用协议的集成协议。通过Lithe，另外我们利用低功率无线个人区域网络IPV6协议（6 LoWPAN），提出了一个新颖的DTLS头压缩计划，旨在显著降低能源消耗。最重要的是我们提出的DTLS头压缩方案不威协DTLS提供的端到端的安全属性。同时，它在保持DTLS标准性的情况下，大大降低了传播的数量字节。我们在Contiki操作系统下基于DTLS来评估了我们的方法。评估结果表明该方案在包的大小，能量消耗，处理时间方面有了显著改善，而且能够在压缩DTLS时得到全网响应。

索引词：CoAP，DTLS，CoAPs，6LoWPAN，security，IoT

一、简介

低功率无线个人区域网络IPV6协议（6 LowPAN）允许使用低功耗的IP网络和有损耗的无线传感器网络，例如无线传感网（WSNs）。这样的IP连接的智能设备正成为互联网的一部分，因此形成了物联网或者严格来说形成了IP连接的物联网。然而由于TCP的拥塞控制算法，使得它在无线网络中的性能很差，低功率无线电和传感网络中的损耗进一步恶化了它的性能。因此物联网中主要使用无连接的UDP。此外。HTTP主要是在TCP基础上运行，它在损耗和受限环境下效率低下。IETF工作在无连接的轻量级的CoAP上，CoAP是物联网中新提出的协议。它是为了满足特定需求，如在资源受限下支持简单，低开销，多播传输。当物体连接到不可信的网络时，安全就尤其重要了。例如，医疗监测代表一个典型的对安全敏感的应用场景。这里，一种智能装置，例如，如胰岛素，可能被附加到病人的身体并向后端服务互联网定期报告病人的情况。在紧急情况下，医生还可以向病人的身体即时注射治疗药物。

为了实现自动键管理、数据加密、完整性保护和身份验证，CoAP提出使用数据报传输层安全(DTLS)作为安全协议。DPLS支持的CoAP被称为安全CoAP（CoAPs）。DTLS是一个健壮的协议，它需要大量的信息交流来建立一个安全的会话。虽然DTLS支持多种对等认证的加密原语和负载保护，但它最初用于长度不是一个关键因素的网络场景。因此，它限制物联网设备，使用DTLS协议就会很低效。为应对资源约束和基于网络的IEEE 802.15.4的大小限制，定义了6 LoWPAN头压缩机制。6 LoWPAN标准已经定义了IP报头的标题压缩格式，IP扩展报头和UDP报头。我们相信把6 LoWPAN报头压缩机制应用于压缩其他有明确的头字段的协议非常有益。

在这篇文章中我们通过用6 LoWPAN报头压缩机制来压缩底层DTLS协议并提出了轻量级 CoAPs。我们命名轻量级6 LoWPAN为压缩的CoAPs Lithe。DTLS头的目的是双重压缩。

首先，由于通信比计算需要更多的能量，所以可以通过减少消息大小来提高能源效率。第二，当数据报大小大于链路层MTU时，避免应用6 LoWPAN碎片。从安全角度来看，由于6 LoWPAN禁不住碎片攻击，所以只要有可能，避免碎片是非常重要的。压缩的DTLS保证了Lithe中的6 LoWPAN主机和典型的应用未压缩的CoAPs网络主机之间的端到端安全。图1显示了一个典型的物联网设备，包含了应用CoAPs的节点的6 LoWPAN网络通过6LowPAN边界路由器(6BR)与互联网连接。

据我们所知，我们是第一个提出用6LowPAN机制压缩DTLS并使轻量级CoAPs应用于物联网的。我们在Contiki操作系统中实现了DTLS头压缩机制。这篇论文的主要贡献有：

为了增加DTLS的适用性，我们提出了新颖的标准的DTLS压缩机制，在此基础上可以将CoAPs应用于受限的设备。

我们在一个应用于物联网的操作系统上实现压缩的DTLS并且在硬件上进行了评估。结果定量的表明，与未压缩的CoAP/DTLS相比，Lithe在很多方面都很高效。

文章的余下部分是这样安排的。我们首先在第二章总结了相关工作。第三章对所用到的技术做了简要的概述。第四章，我们介绍了DTLS头压缩机制。第五章，我们给出了实现。第六章，论述了网络设置并讨论评估结果。最后在第七章做出总结。

二、相关工作

在传统互联网中提供端到端的安全通信是一个广泛的研究领域。然而，相对来说，在端到端安全研究中很少考虑到了6LoWPANs。设备的资源约束和无线链接的自然损耗是阻碍把端到端安全应用到6LoWPANs的主要原因。最近，有组织在分析基于IP的物联网的安全性挑战，为满足资源有限的设备的需求，该组织还提出了改善或修改标准IP安全协议的方案。在相关工作的讨论中，我们专注于旨在实现物联网端到端安全的方案。

先前，我们提出了一个头压缩方法，它通过用IPsec来保证6LowPAN中的节点与因特网中的主机之间的通信安全。我们定义下一个头压缩(NHC)编码来压缩认证头(AH)和封装安全有效载荷(ESP)的扩展报头。Jorge扩展了我们的解决方案，其中包括IPsec隧道模式。他们在微型操作系统上实施和评估了他们的建议。IPsec安全服务在特定的机器上运行的所有应用程序之间共享。尽管我们用

6LowPAN压缩的IPsec可以用来在网络层提供轻量级的E2E安全，但它最初不是为像HTTP和CoAP这样的网络协议设计的。TLS或DTLS web协议是常见的安全解决方案。TLS运行在TCP上，而在UDP基础上

6LowPAN网络优先。

Brachmann提出了TLS-DTLS映射来保障物联网安全。然而，这需要有可靠的6BR和在6BR间歇时的端到端安全。Kothmayr调查了在可信平台模块上用DTLS来获得对RSA算法的硬件支持。然而，他们利用了DTLS，而没有用任何压缩方法，这会造成DTLS消息中的冗余位缩短整个网络的生命周期。Granjal评估了带有CoAP的DTLS在安全通信中的性能。他们注意到稀缺性负载空间在需要更大的有效载荷的应用程序中会有问题。作为一种替代方法，他们建议在其他层使用像IPsec这样的压缩形式来保证安全。在最近的研究中，Keoh 讨论了保护以IP连接并使用DTLS协议的物联网的安全的意义，并提出了一个安全的网络架构，用延长的DTLS对单播和多播密钥进行访问和管理。

上述解决方案要么对物联网中的TLS或DTLS的使用进行了评估，要么对破坏端到端安全的当前架构进行评估。本文通过使用6LowPAN头压缩机制来减少物联网中DTLS的开销。

我们提出了设计思想以减少双向的基于证书的DTLS握手的能源消费。我们提出的建议如下：

1、预先验证可靠的6BR中的证书。

2、全面恢复会话以避免重新握手。

3、资源有限的设备的所有者来承担握手任务。在物联网中验证基于证书的可行性的工作与这一工作是互补的。为使基于证书的相互握手更高效，我们计划把DTLS报头压缩与这些想法集合起来。最近，类似于NHC的通用头压缩（GHC）也被定义成可以允许上层头压缩。6LowPANGHC对于所有的头和类似于头的结构是一个通用的压缩方案，但是一个低效的方法。它是我们的解决方案的替代方法，在将来的工作中，我们计划把我们的6LowPAN-NHC与6LowPAN-GHC做一个比较。

三、背景

由于物联网的异质性，将有资源限制的设备安全而有效的连接起来是一项很有挑战性的工作。目前，互联网工程任务组正在标准化不同的协议，如CoAP，6LowPAN，低电力有损网络中的IPv6路由协议，以使这些协议可以应用在物联网中。本文的重点是让用CoAP协议的物联网设备之间进行安全有效的沟通。在本章中我们突出了在轻量级CoAP发展中使用的技术，即物联网的HTTP变体。

A、CoAP和DTLS CoAP是运行在不可靠UDP协议上的网络协议，它最初是为物联网设计的。CoAP是最常用的同步Web协议的变种，如HTTP，是专为受限制的设备和机器与机器之间的沟通设计的。

然而，尽管CoAP提供了与HTTP类似的REST接口，但与现在物联网中它的变体相比，CoAP更注重轻量级和成本效益。为了保护CoAP传输，建议数据报TLS(DTLS)作为主要的安全协议，类似于TLS保护HTTP(HTTPs)，安全的DTLS CoAP协议称为CoAPs。然后就可以通过如下的CoAPs协议安全地访问物联网设备中的web资源：

coaps://myIPv6Address:port/MyResource 我们给出了DTLS协议的简要概述来作为DTLS压缩机制的基础。

通过对传输层和应用层的操作，DTLS保证了单个机器上不同程序之间的E2E的安全。DTLS包含两层：底层包含记录协议，上层要么包含握手，警告和

ChangeCIPherSpec，要么包含应用数据。ChangeCIPherSpec在握手过程中使用，这仅仅表明，记录协议应该通过新密码套件和安全协商钥匙来保护后续信息。DTLS使用警报协议来实现不同DTLS之间错误消息的传送。图2显示了在IP/UDP数据报中DTLS的消息结构。

记录协议是上层协议的载体。记录头包含其他内容类型和片段字段。基于内容类型的值，片段字段要么包含握手协议，警告协议和ChangeCIPherSpec协议，要么包含应用数据。

一旦握手过程完成，记录头主要是负责用密码保护上层协议或应用数据。记录协议的保护包括机密性、完整性和真实性的保护。DTLS记录是一个相当简单的协议而握手协议是一个复杂的过程，它包含以异步的方式大量交换的消息。图3给出了完整的握手过程。握手消息，通常在航班、谈判安全密钥、密码套件和压缩方法中使用。本文的范围只限于报头压缩，而不包括处理密码记录和握手协议。详细的握手消息我们参考TLS和DTLS消息。

B、6LoWPAN 6LoWPAN标准定义了与IPv6相关的WSNs中的IPv6数据报的标题压缩和分化机制的，也称为6LowPAN网络。压缩机制包括IP头压缩(IPHC)和下一个头压缩(NHC)。IPHC加密可以在单跳网络中将IPv6头长度压缩至2字节，在多跳网络中压缩至7字节（1字节IPHC、1字节发送、1字节跳限制，2字节源地址，2字节目的地地址）。在IPHC中的其他加密比特是NH比特，它在设置时显示下一个头是用NHC压缩。NHC是用来加密IPv6的扩展头和UDP头。

NHC的大小是一个多重的八位字节（主要是一个八位字节），它包含可变长度ID比特和一个特定的头编码比特。有些协议是UDP负载的一部分，有着类似于IP和UDP 的头结构。例如DTLS，IKE。因此，值得推广6LowPAN头压缩机制来压缩这些协议头。6LowPAN标准的定义了NHC编码，可用于UDP头压缩，但不能用于上层。需要一个新的NHC，因为在NHC中没有给UDP的NH位，这表明UDP负载也压缩了。在第四部分，我们提供了6LowPAN-DTLS的集合和6LowPAN NHCs来压缩DTLS。

如图1所示是头压缩在6LowPAN网络中应用。例如，在有限的节点和6LowPAN边界路由器之间的应用。6BR是用在网络和英特网之间转发消息前，来压缩/解压缩或者片段化/重新组装它们之间的消息。在这种物联网设备中，CoAP使得设备可以与网络主机之间安全通信，例如标准的电脑和智能电话等，它支持CoAPs协议。为了适应安全协议，例如在资源受限的物联网中的DTLS，把6LowPAN头压缩机制应用到这些协议中也是非常有益的。第四节里我们提出了DTLS的6LowPAN头压缩机制。以DTLS标准来设计这些报头压缩是非常重要的，要能够在传统的互联网上与现有的和新的DTLS主机之间互操作。

四、DTLS压缩

DTLS头压缩类似于IPHC，仅在6LowPAN网络中应用，如在传感器节点和6BR中使用。这是因为DTLS报头是UDP负载的一部分，而且路由所需的所有信息已经在IP层提取。在本章中除了描述DTLS的6LowPAN头压缩，我们详细介绍了如何以符合标准的方式将压缩的DTLS连接到6 LowPAN。

A、DTLS-6LowPAN 为了将6LowPAN头压缩机制应用于压缩UDP负载中的头，我们要么需要在6LowPAN协议中修改当前UDP中的NHC编码，要么需要给UDP定义一个不同于ID位的新的NHC。第一个解决方案需在当前标准中修改，因此不是一个有

利的解决方案。在这篇论文中我们用了第二种方案，它是6LowPAN标准的延伸，有一个类似的方法适合于区分NHC和GHC。UDP中NHC的ID位11110，与6LowPAN中定义的标准一样，表明UDP负载不压缩。定义ID位11011表明UDP负载用6LowPAN-NHC压缩。ID位1101目前在6LowPAN标准中还未定义。图4给出了我们提出的UDP中的NHC，它允许UDP负载的压缩。在我们的例子中，UDP负载包含用6LowPAN-NHC压缩的DTLS头。

B、用于记录头和握手头的6LowPAN-NHC记录协议 在使用DTLS的设备的生命周期中，给发送的每个数据包增加了13个字节长的头字段，另一方面，握手协议，在握手消息中增加了12字节的头。我们提出6LowPAN-NHC来压缩记录协议和握手协议，并分别把头长度减少到3~5个字节。在所有情况下，记录头仍是未加密的。因此，总是用在这章中解释的机制来压缩。

为了向记录和握手头提供头压缩，我们考虑两种情况。在第一种情况中，记录头的片段（见第三部分）包含握手消息，我们用加密字节来压缩记录和握手头消息，并且给出了记录+握手中6LowPAN-NHC的定义。在第二种情况下，我们给记录头定义了6LowPAN-NHC（6LowPAN-NHC-R），与第一种情况不同的是，在记录头中的片段是应用数据而不是握手消息。

我们成功实现了在DTLS握手后应用6LowPAN-NHC-R，并且对随后的消息进行加密和完整性保护。图2a给出了记录+握手头和记录头的6LowPAN-NHC加密。加密为有以下功能：前4位代表的ID字段用来区分 6LowPAN-NHC-RHS和其他编码，而且符合 6LowPAN-NHC编码方案。在 6LoWPAN-NHC-RHS情况下我们把ID位设置到了1000，在 6LoWPAN-NHC-R情况下ID位设置到了1001。

版本（V）：如果是0，是最新的DTLS，版本1.2，省略了字段。如果是1，版本字段进行内联。

时代（EC）：如果是0，使用了八位表示时代，最左边的八位省略。如果是1，所有16为进行内联。在大多数情况下实际年代要么是0要么是1。所以通常使用8位表示年代，这样允许更大的空间。

序列号（SN）：序列号包含48位，有些事前导0。如果序列号设为0，就用了16位的序列号，并且左边的32位省略了。如果是1，所有的48位用于内联。如图5a所示，在 6LoWPAN-NHC-R情况下，我们的SN设为2位，这样可以更高效的压缩序列号字段。如果SN=00，就用了16位的序列号，并且左边的32位省略了。如果SN=01，就用了32位的序列号并且最左边的32位省略。如果SN=01，就用了32位的序列号，并且最左边的16位省略了。如果SN=10，就用了24位的序列号，并且最左边的24位省略了。如果SN=11，所有的48位序列号用于内联。

片段（F）：如果F=0，则握手消息没有片段化，并且省略了fragment_offset 和 fragment_length字段。这是常见的情况，如果握手消息短于最大记录长度时就会发生。如果F=1，fragment_offset 和 fragment_length字段用于互联。

在记录头上，content_ type字段总是用于内联。记录头中的长度字段总是省略，因为可以从较低层推算出：或者从 6LoWPAN的头，或者从 IEEE 802.15.4的头。我们必须从低层到高层解压layer-wise，直到完全解压出UDP报头。然后就可以知道UDP有效负载的长度并可以计算出DTLS负载长度。由于我们希望在受限的环境中每个UDP包只有一个DTLS记录头，所以记录头的长度字段也省略了。当 6LoWPAN中的源装置在每个UDP包中发送一个DTLS记录时，传统网络侧会有典型的目的装置在一个UDP包中传送多个DTLS记录头。然而，当6BR对传入的包执行压缩/解压时，有可能在6LoWPAN网络中给出这些包的路由之前，对每个UDP包执行一个DTLS记录。

C、6LoWPAN-NHC for ClientHello 我们提出了客户端友好型的消息6LoWPAN-NHC（6LoWPAN-NHC-C）。在握手过程中会发送两次客户端友好型消息，第一次没有cookie而第二次有服务器的cookie。图5b给出了用6LoWPAN-NHC对客户端友好型消息进行加密的过程。

每一个压缩头字段的功能描述如下： 6LoWPAN-NHC-CH中前四位设为1010用来表示ID字段。

会话ID（SI）：如果SI=0，session_id不可用，并将这一字段和8位的前缀长度字段省略。在DTLS协议中如果没有字段可用，或者用户想生成新的安全参数，那么session_id就是空的。只有在DTLS客户想要恢复旧会话时，才会使用ClientHello消息。真正的ClientHello中session_id字段包含0-32字节。然而，它的前缀中总是有一个8位的字段来表示session_id的大小。如果SI=1，session_id字段用于内联。

Cookie（C）如果C=0，cookie字段不可用，省略这一字段和前缀8位。在ClientHello中真正的cookie字段包含1-255字节。然而，它总是有8位来表示cookie的长度。如果C=1，cookie字段用于内联。

密码套件（CS): 如果CS=0，使用了CoAP默认的（强制性）支持自动的键管理的密码套件，并且这个字段和前缀16位被省略了。在当前的CoAP草稿中，TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8是一个强制性的密码套件。真正的密码套件字段包含2-2^16−1字节。并且在前缀中包含16字节来表示 cIPher_suites的大小。如果C=1，cipher_suites用于内线互联。

压缩方法（CM）：如果CM=0，就为默认的压缩方法，例如，用到了COMPRESSION_NULL，省略这个字段和前缀8位字段。实际上压缩方法字段包含1-2^8-1字节。它总是在前缀八位包含压缩方法的大小。如果CM=1，那么压缩

方法字段用于内线互联。

在ClientHello中随机字段总是用于内线互联并且总是省略版本字段。版本字段包含的值与DTLS记录头中的值一样。在TLS/SSL情况下，定义版本字段来让一个TLS的客户指定一个旧版本以兼容SSL客户机，而这在实际中很少用到。当前所有的Web浏览器在记录和ClientHello中使用相同的TLS版本。DTLS1.2（改编自TLS 1.2）提到客户在ClientHello消息中发送最新的支持版本。所有DTLS版本(1.0和1.2)的ClientHello消息相兼容。如果客户机不兼容这种版本，那么ServerHello消息将包含支持的版本。如果客户不能够处理服务器的版本，它将给出终止与协议版本连接的警报。

使用 6LoWPAN-NHC-CH，通常只传送 ClientHello消息中的随机字段，而省略所有其他字段。同时，cookie会包含可压缩的字段。图6给出了一个包含ClientHello且未压缩的IP/UDP数据报。图7给出了我们提出的压缩DTLS，它包含ClientHello消息。在应用IPHC和 6LoWPAN-NHC头压缩后，数据报的尺寸是显著降低了。

D、服务器友好型 6LoWPAN-NHC 我们提出了SeverHello消息的 6LoWPAN-NHC（6LoWPAN-NHC-SH）。SeverHello与ClientHello除了密码套件和压缩方法字段分别位16和8位外，它们非常相似。图5给出了用 6LoWPAN-NHC 加密的ServerHello消息。每个压缩头的功能描述如下：前6 LoWPAN-NHC-SH中前四位设置为1011代表ID字段。版本（V）：为了在最初版本的握手中避免谈判，DTLS 1.2标准表明服务器的实现应该使用DTLS 1.0版本。如果V设为0，就使用DTLS1.0版本并省略版本字段。尽管DTLS1.2客户端不能假定服务器不支持更高的版本，否则它最终将使用DTLS1.0而非DTLS1.2。如果V设为1，那么版本字段用于内线互联。

会话（ID），密码套件（CS）和压缩方法（CM）的加密方式与讨论的IV-C部分类似。为了不影响安全性ServerHello中的随机字段总是进行内联。

E、其他握手消息中的 6LoWPAN-NHC 剩下的强制性握手消息ServerHelloDone ClientKeyExchange，和Finish没有可以压缩的字段，因此所有字段进行内联。包含了证书链的可选的握手消息和包含了握手消息的数字签名的 CertificateVerify，也用来内线互联。然而，压缩一些证书中的字段也是可能的，但超出了本文的范围。Pritikin提出了X.509的压缩计划。

大多数时候不传送ServerKeyExchange消息，要么由于加密的出口限制要么因为服务器的证书消息包含足够的信息来承认客户端交换premaster secret。然而，如果传送了这一消息，那么所有的字段都用于内线互联。在可选的消息CertificateRequest的情况下所有的字段都可以省略。这是可能实现的，因为certificate_types，supported_signature_algorith和 certificate_authorities字段可以在6LoWPAN网络的一组支持的和优先的值之前定义，并且所有的网络中的节点使用相同的设置值。在传统的互联网中，在将消息发送到目的地之前，6 BR可以通过缺省设置值来填充空CertificateRequest消息。如果 6LoWPAN网络中没有定义缺省的设置值，那么所有字段用于内线互联。

五、实现

我们在Contiki中实现了Lithe，Contiki是物联网的开放源代码的操作系统。

然而，我们建议的报头压缩机制可以在任何支持6LowPAN的操作系统中实现。Lithe的实现包含4个部分（1）DTLS（2）CoAP(3)CoAP和DTLS的集合模型。（4）DTLS头压缩。DTLS部分，我们使用了开放源代码的微型DTLS，它支持基于pre-shared键的基本的密码套件：TLS_PSK_WITH_AES_128_CCM_8。我们使得微型DTLS适用于WiSMote平台和支持 msp430-gcc的20位地址。（版本4.7.0）。CoAP部分，我们在Contiki操作系统中实现缺省的CoAP。我们开发出了连接CoAP和DTLS的集成模型，并可以使用CoAPs协议。这种集成允许应用程序独立访问CoAPs，在这里CoAP消息都是透明的传送给能够传输保护信息到目的地DTLS。所有的传入消息都通过DTLS来保护，因此在DTLS层首先处理并透明传送给驻留在应用层的CoAP。

第四节我们实现提出的头压缩作为在Contiki操作系统中实现的6LoWPAN 的扩展。6LoWPAN 层在IP层和MAC层之间。IP层的数据包可以从节点传出来作为输出数据包。MAC层节点接受到的数据包被看做输入包。6LoWPAN层从两个方向处理所有UDP包。因此，我们使用两种方法来从其他UDP包中区分携带DTLS消息的UDP包做为有效载荷。在输入包情况下，预配置的默认DTLS端口用于识别CoAPs消息。在第二种情况下，包从MAC层接受，NHC-for-UDP和DTLS头的NHC中的DTLS端口和ID位用来区分压缩头和未压缩的头。第四节中给出了细节。

此外，重要的是要强调，尽管应用头压缩，端到端的安全性是不能降低的。这是由于DTLS的设计和我们的努力来保持标准兼容。头字段在与密码套件联系之后，在记录层进行完整性保护。在压缩/解压过程中不修改原来的标题也保护了完整性。在6LoWPAN层解压后，在DTLS层进行包的完整性检查。把正确性完整性保护作为正确的减压证明。

六、评价

我们在运行Contiki操作系统的真正的传感器节点上评估Lithe。我们用 WiSMote作为硬件平台。该平台的配置有（1）16兆赫，MSP430 5系列、16位RISC微控制器，（2）128/16 kB的 ROM/RAM，（3）一个IEEE 802.15.4(CC2520)收发器。我们选择WiSMotes是因为由于RAM和ROM的需要DTLS实现，这会在第六章B部分详细讨论。网络设备包括两个直接通过无线电通信的WiSMotes。CC2520收发器提供了一个AES-128安全模块。然而，对我们不使用AES硬件支持而依靠软件AES来评估。利用涉及DTLS的AES硬件支持的加密计算得到了更高的性能。我们的评价关注的是DTLS报头压缩对响应时间和能源消耗节点的影响。因此，由于软件AES造成的性能损失不会影响我们的评估。此外，为了能够分析单独压缩的处理开销，我们不支持链路层安全。在先前的工作中，我们已经用AES支持的硬件来评估性能增益。在那里，我们实施和评估了IEEE802.15.4链路层安全。

A、减少数据包大小

我们可以使用6LoWPAN-NHC压缩机制显著降低DTLS头的长度。表1显示了我们提出的DTLS头压缩显著减少了头比特的数量，这也类似地减少了无线传输时间。

包含在所有DTLS消息中的记录头，可以压缩64位，节省62%的空间。在握手头的情况下，可以节省75%的空间。应用程序数据构成的最大数量的DTLS消息。把记录头从104位减少到40位，就允许在每个包中多传送64位。大于链路层MTU的数据包是分散的。碎片不仅引入更多的节点和网络开销，它也带来安全漏洞。因此，只要有可能，最好避免碎片。在有效载荷略高于分割阈值时，我们使用压缩来避免碎片或减少碎片的数量。此外，在有限的网络中减少传输比特对网络的性能和寿命有着巨大的影响。无线电通信的能源消耗通常高于节点内计算约10倍。压缩的能源消耗平衡在用于压缩和解压缩的额外内部节点与减少无线传输之间。这种权衡的影响将在第六章C部分进一步讨论。

B、RAM和ROM的要求

我们用MSP430工具链中的msp430-objdump工具来分析静态RAM和ROM。如表2所示，Lithe需要59.4kB的ROM和9.2kB的RAM。

DTLS的实现包括密码功能并且DTLS状态机需要16.8 kB的ROM和3.7 kB的 RAM。

这使得DTLS对ROM来说是仅次于操作系统的主要贡献者。The CoAP-Server 需要8 kB的ROM 和.5 kB 的RAM.我们的CoAP-Server提供单个的资源，这基于CoAP GET请求，把可变负载长度的响应消息发送回来。我们的评价中用这个来分析压缩对不同负载长度的CoAPs消息的影响。COAP得以实现的脚本取决于提供的资源。DTLS头实现了对ROM压缩2820字节，对静态RAB

压缩一个字节。一个字节的静态RAM对UDP报头的压缩。在Contiki中 6LoWPAN使用的用来压缩和片段化的（没有DTLS压缩）全部ROM是3782字节。这验证了压缩的DTLS使用相同的ROM顺序作为标准的6LoWPAN。如今的感知节点，例如带有128K字节的WiSMote一定能满足压缩的CoAPs和其他操作系统的组件，而且还可以提供为其他应用提供重要的空间。

C、运行时间性能

我观察当使用压缩的DTLS时的运行时间性能，并把它与使用为经压缩的DTLS做比较。我们分别在一个具有 Radio Duty Cycling(RDC)和没有RDC的6LoW-PAN网络中进行这个实验。当使用RDC时，收音机在大部分时间是关闭的，并且要么在特定的间隔打开来检查传入数据包的媒介，要么在传送包是打开。我们使用在Contiki操作系统中提供的duty cycled MAC协议，有着默认设置的X-MAC。在我们对运行时间进行评估时，我们关注的是传感器节点的能量消耗和网络范围的执行时间。为评估能量消耗，我们使用Contiki操作系统提供的能量估计模块。这个模块提供CPU的使用时间，LPM，特定函数收发器。每个这些组件的绝对计时器值可以使用以下方程转换成能源：

（1）DTLS压缩开销：DTLS头的节点内计算压缩和解压缩而引起的开销几乎可以忽略不计。然而，为了完整性我们测量和显示它的完整性。图8显示了头消息中用于压缩（压缩和解压缩）的额外能量消耗。每一个握手消息包含记录和握手头。平均来说，每个基于预共享秘钥的DTLS握手消息消耗4.2uJ能量。

（2）CoAPs初始化：在CoAPs初始化过程中在使用DTLS握手协议的两个通信终端建立了一个安全会话。这一握手过程同时使用了记录和握手头，这意味着这两种头都可以被压缩。额外的节点内计算和减少数据包大小之间的权衡表明

他自身在DTLS握手时传输包的能源消耗。表3把在应用压缩情况下的传输能量损耗和未应用压缩情况下的能量损耗进行了比较。平均来看，传输和接受压缩包需要使用的能量减少15%。这是因为在压缩过程中包的大小变的更小。

（3）CoAPs请求-响应：一旦CoAPs初始化过程完成了，例如已经完成了握手，一个感知节点就可以通过DTLS记录协议来发送/接收安全的CoAP消息。尽管与记录协议相比握手协议的能量消耗更大，但它旨在初始化阶段或接下来的预握手阶段执行。

为了测量记录头的压缩性能，我们在CoAP请求-应答消息过程中测量能量消耗和往返时间（RTT）。当客户准备CoAP请求时我们开始测量，并在收到服务器应答和处理后结束。相应的CoAP响应包含不同的负载长度。更精确来说，在0-48字节范围中使用了8种不同的负载大小。我们选择了48是因为在CoAPs情况下，48字节的CoAP负载 中6LoWPAN 片段发挥了作用。然而，Lithe不会导致碎片，因为通过压缩减少了比特。可以在图9a中看出这种作用，该图表明了CoAP的客户端，以及传送压缩和未压缩的CoAPs的请求和应答（不带RDC且长度不一样）的客户机的平均内部节点损耗。由于应答消息总是一个常量，所以传送CoAP GET应答消息所需的能量一样。因此，CoAP应答的能量消耗可以通过压缩来降低10%。因此，减少的能量范围在4-26%，其中最大可以节省48字节的能量。

为了分析CoAPs请求—响应的总体能量损耗，我们叠加了客户端和服务器之间的能量损耗，并在图9b中给出了描述。在该图中我们观察到平均节省了约7%的能量。然而，通过压缩来避免碎片的情况下，节省的能量达到了20.6%。这是因在48字节的负载中，6LoWPAN在两个碎片中传送包，而经过压缩后包就不会在碎片中传送。

减少的传送时间也会影响将RTT应用于CoAPs的请求—应答消息，如图10b所示，在没有RDC的情况下，RTT平均减小1.5%，除了48字节的负载。在这种情况下，带压缩的RTT甚至能效77%，因为避免了碎片。为了评估由安全性引起的总体开销，我们也在没有安全性的CoAP中加了值。只要不需要碎片。没有安全性的CoAP中的RTT占CoAPs的1/3。在图10b中我们看有RDC的RTT，我们可以看到所有的三种情况：（1）没有任何安全性的CoAP（2）CoAPs（3）带有DTLS压缩的DTLS（Lithe），RTT值都在同一范围，处理CoAP应答消息有48字节的负载。这是RDC的副作用。RDC通过把收音机加入大部分休眠状态而节省了很多能量。然而这样的代价是时延变大。RDC中的包并不直接传输。发送方必须等到接收方醒来，最坏的情况会将等待整个休眠期。结果表明，总体来说使用RTT的等待时间比未使用RTT长。我们在带有RDC的网络中观察到了这一现象。例如，图10b，带偶48字节的负载，压缩使得RTT缩小了50%。

七、结论

能够应用COAP的主机将会成为物联网不可分割的一部分。此外，现实中使用COAP的装置需要安全解决方案。为此，DTLS是使CoAP(CoAPs)安全的标准协议。在这篇论文中我们调查了通过 6LoWPAN头压缩来减少DTLS开销的可能性，并且给出了6LoWPAN第一个DTLS报头压缩规范。结果定量的表明可以压缩DTLS并且可以使用6LoWPAN标准压缩机制来大大减少它的开销。我们对压缩的DTLS的实现结果和评估表明，与CoAPs相比，由于从能量消耗和网络响应时间方面来看，DTLS压缩具有高效性，这使得可以减少CoAP的开销。如果使用未压缩的DTLS导致了6LoWPAN的碎片，那么压缩的DTLS与未压缩的DTLS有着显著的不同。

在未来的工作中我们计划在有真实的应用场景的真实的物联网系统中部署Lithe。这样的物联网设置由受限设备，标准的电脑和智能手机组成。在现实世界中部署帮助我们对一个异构物联网进行彻底评估，并最终证明Lithe在对安全敏感的应用中的使用情况。

第三篇：PDCP协议学习总结

PDCP协议学习总结

1、PDCP架构

UE/E-UTRANPDCP entiy Radio BearersPDCP-SAPPDCP-SAPC-SAPPDCP entityPDCP entity...PDCP sublayerPDCPSDU...RLC UM-SAPRLC AM-SAPRLC sublayer

2、PDCP实体：

UE/E-UTRANTransmitting PDCP entityReceiving PDCP entityE-UTRAN/UESequence numberingHeader Compression(u-plane only)Packets associated to a PDCP SDU Integrity Protection(c-plane only)Ciphering Packets not associated to a PDCP SDUIn order delivery and duplicate detection(u-plane only)Header Decompression(u-plane only)Packets associated to a PDCP SDUIntegrity Verification(c-plane only)DecipheringPackets not associated to a PDCP SDUAdd PDCP headerRemove PDCP HeaderRadio Interface(Uu)一个UE可以定义多个PDCP实体，可以对携带用户面数据的每个PDCP实体进行配置，来使用头压缩。每个PDCP实体携带一个无线承载的数据。根据无线承载所携带的数据，PDCP实体对应于控制平面或者用户平面

3、PCDP层服务

向上层提供的服务：（PDCP提供服务给UE的RRC层和用户面高层）（1）数据传输（2）头压缩（3）加密（4）完整性保护

从下层得到的服务：（RLC层向PDCP层提供服务）

（1）确认的数据传输业务，包括PDCP PDU成功传输的指示（2）非确认的数据传输业务

（3）有序传送，除了在切换时的情况（4）重复丢弃，除了在切换时的情况

4、PDCP层功能

（1）发送和接收实体利用ROHC协议对IP数据流进行相应的头压缩和解压缩（2）用户面数据或者控制面数据的传输

（3）维护RLC AM模式下的映射的无线承载的PDCP SN（4）下层重建时，上层PDU的有序传送

（5）下层重建时，RLC AM模式下的映射的无线承载的下层SDU重复消除（6）用户面数据和控制面数据的加密和解密（7）控制面数据的完整性保护与完整性验证（8）基于计时器的丢弃（9）重复丢弃

5、PDCP过程（具体过程见page 3）（1）PDCP数据传输过程 上行数据传输过程：每一个PDCP SDU对应一个Discard Timer，一旦由高层接收到一个PDCP SDU，即启动该SDU对应的Discard Timer。同时，进行发送相关的状态变量更新及加密、完整性保护等，具体过程如图2所示。

下行数据传输过程：在不需重建的情况下，PDCP实体在接收到RLC AM实体提交的PDCP PDU时，不需执行重排序过程，因为RLC AM在向PDCP实体提交PDCP PDU时，已保证顺序递交。若UE先从源eNodeB收到一些PDCP SDU，重建开始后从目的eNodeB接收PDCP SDU(其中部分是源eNodeB转给目的eNodeB的，并且有一些是源eNodeB已发给UE但尚未得到确认的)，因此，UE的PDCP实体收到的PDCP SDU可能是乱序并且有重复的，因此对于RLC AM模式，在重建情况下，PDCP接收实体需对接收的PDCP SDU进行重排序和重复检测。

（2）重建过程

上行数据传输过程：映射到RLC AM的DRB过程

映射到RLC UM的DRB过程 SRB过程 下行数据传输过程：映射到RLC AM的DRB过程

映射到RLC UM的DRB过程 SRB过程（3）PDCP状态报告 传输：

接收：

（4）PDCP丢弃：PDCP SDU的Discard_Timer超时或PDCP SDU的成功传输有PDCp状态报告确认，UE丢弃PDCP SDU及相应的PDCP PDU（5）头压缩与解压缩：

（6）加密和解密：加密不用于PDCP控制PDU 控制面：PDCP PDU中数据部分及MAC-I 用户面：PDCP PDU的数据部分

（对消息和加密流做异或(XOR)运算来实现的，这里加密流是由基于接入层(AS)导出密钥、无线承载ID、传输方向(上行或下行)以及COUNT值的加密算法所生成的。）

（7）完整性保护及确认：该功能仅用于SRB（8）未知的、意外的以及错误的协议数据的处理

6、PDCP协议数据单元及格式

PDCP数据PDU传送：一个PDU SDU SN、包含一个基于非压缩的PDCP SDU用户面数据、包含一个基于压缩的PDCP SDU用户面数据、控制平面数据、只有SRB的MAC-I域 PDCP控制PDU传送：PDCP状态报告、头压缩信息

7、参数

（1）PDCP SN：

（2）DATA：未压缩PDCP SDU（用户面或控制面数据）/压缩PDCP SDU（用户面数据）（3）MAC-I：消息认证码、未经过完整性保护的控制面数据MAC-I用0填充（4）COUNT：HFN+PDCP SN（5）R：保留位

（6）D/C：控制PDU或数据PDU（7）PDU type：status/ROHC/received（8）FMS：第一个丢失的PDCP SDU的PDCP SN值

（9）Bitmap：PDCP SDU是否被接收并正确的进行选择性解压

8、变量

PDCP实体发送端

（1）Next_PDCP_TX_SN：给定PDCP实体的下一个PDCP SDU的PDCP SN，实体重建时置0（2）TX_HFN:sehngcheng COUNT值的HFN值（COUNT值用于一个给定的PDCP实体的PDCP PDU），实体重建时置0 PDCP实体接收端

（1）Next_PDCP_RX_SN：下一个期望的PDCP SN，有一个给定PDCP实体的接收方给出，实体重建时置0（2）RX_HFN：生成COUNT值的HFN值，实体重建时置0（3）Last_Submitted_PDCP_RX_SN:传输到上层的最后一个PDCP SDU的SN，实体重建4095

9、常量

（1）Reordering_Window：2048，PDCP SN的一半，用于无线承载应设在RLC AM上的情况（2）Maximum_PDCP_SN：

10、定时器

（1）Discard_Timer丢弃定时器（2）Flush_Timer清空定时器

5.1 数据传输过程

5.1.1 上行

从上层接收到PDCP SDU后

UE启动与此PDCP相关量的discardTimer 对于从上层接收到的PDCP SDU UE应关联相应于Next_PDCP_TX_SN的PDCP SN到PDCP SDU UE应执行PDCP SDU头压缩 UE应执行完整性保密

UE应使用基于TX_HFN的COUNT以及关联于PDCP SDU的PDCP SN值进行加密 UE将Next_PDCP_TX_SN加1 若果Next_PDCP_TX_SN﹥Maximum_PDCP_SN UE应将Next_PDCP_TX_SN置0 UE应将TX_HFN加1 UE应将最后产生的PDCP Data PDU传送给低层

5.1.2 下行

一、DRB过程

1、映射到RLC AM的DRB过程

对于映射到 RLC AM的DRB，在接收到低层的PDCP Data PDU时

（1）如果接收到的PDCP SN－Last_Submitted_PDCP_RX_SN＞reordering_Window 或0≤Last_Submitted_PDCP_RX_SN－接收到的PDCP SN＜Reordering_Window Last_Submitted_PDCP_RX_SN0Maximum_PDCP_SNReordering_WindowNext_PDCP_RX_SNReceived PDCP SNRX_HFN-1

图5.1 Received PDCP SN－Last_Submitted_PDCP_RX_SN＞reordering_Window 1）如果接收到的PDCP SN＞Next_PDCP_RX_SN 0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNNext_PDCP_RX_SNReceived PDCP SNRX_HFN-1且received PDCP SN＞Next_PDCP_RX_SN

图5.2 0≤Last_Submitted_PDCP_RX_SN－received PDCP SN＜Reordering_Window UE应使用基于RX_HFN－1的COUNT与接收到的PDCP SN值，解密此PDCP 2）否则

0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNReceived PDCP SNNext_PDCP_RX_SNRX_HFN图5.3 0≤Last_Submitted_PDCP_RX_SN－received PDCP SN＜Reordering_Window

且Next_PDCP_RX_SN ＞received PDCP SN

UE应使用基于RX_HFN的COUNT与接收到的PDCP SN值，解密此PDCP PDU 3）UE应执行头压缩

4）UE应丢弃此PDCP SDU（2）否则，如果Next_PDCP_RX_SN－接收到的PDCP SN＞Reordering_Window 0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNReceived PDCP SNRX_HFNNext_PDCP_RX_SN

图5.4 Next_PDCP_RX_SN －received PDCP SN＞Reordering_Window 1）UE应将Next_HFN加1 2）UE应使用基于RX_HFN的COUNT与接收到的PDCP SN解密此PDCP PDU 3）UE应将Next_PDCP_RX_SN置为刚接收到的PDCP SN＋1（4）否则，如果接收到的PDCP SN－Next_PDCP_RX_SN≥Reordering_Window 0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNNext_PDCP_RX_SNReceived PDCP SNRX_HFN-1

图5.5 received PDCP SN－Next_PDCP_RX_SN＞Reordering_Window

1）UE应使用基于RX_HFN－1的COUNT与接收到的PDCP SN解密此PDCP PDU（5）否则，如果接收到的PDCP SN≥Next_PDCP_RX_SN Last_Submitted_PDCP_RX_SN0Maximum_PDCP_Reordering_WindowNext_PDCP_RX_SNReceived PDCP SNRX_HFN

图5.6 Received PDU SN≥Next_PDCP_RX_SN（1）

Last_0Submitted_PDCP_RX_SNMaximum_PDCP_SNNext_PDCP_RX_SNReceived PDCP SNRX_HFN

图5.7 Received PDU SN≥Next_PDCP_RX_SN（2）

Last_0Submitted_PDCP_RX_SNMaximum_PDCP_SNNext_PDCP_RX_SNReceived PDCP SNRX_HFN

图5.8 Received PDU SN≥Next_PDCP_RX_SN（3）

1）UE应使用基于RX_HFN的COUNT与接收到的PDCP SN解密此PDCP PDU 2）UE应将Next_PDCP_RX_SN置为接收到的PDCP SN＋1 3）如果Next_PDCP_RX_SN＞Maximum_PDCP_SN UE应将Next_PDCP_RX_SN置0 UE应将RX_HFN加1（6）否则，如果接收到的PDCP SN＜Next_PDCP_RX_SN Last_Submitted_PDCP_RX_SN0Maximum_PDCP_SNReordering_WindowReceived PDCP SNRX_HFNNext_PDCP_RX_SN

图5.9 Received PDU SN＜Next_PDCP_RX_SN（1）

0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNReceived PDCP SNRX_HFN

Next_PDCP_RX_

图5.10 Received PDU SN＜Next_PDCP_RX_SN（2）0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNReceived PDCP SNNext_PDCP_RX_SNRX_HFN图5.11 Received PDU SN＜Next_PDCP_RX_SN（3）

1)UE应使用基于RX_HFN的COUNT值域接收到的PDCP SN值解密此PDCP PDU（7）如果上面没有丢弃此PDCP PDU 1)UE应执行PDCP PDU的解密与头压缩

2)如果一个具有相同PDCP SN值的PDCP PDU被存储 UE应丢弃此PDU 3）否则

UE应存储此PDCP SDU 4）如果由于下层重建导致PDCP没有接收到此PDCP PDU UE应把相关的COUNT值按照升序传递给上层：

a.所有存储的，相关COUNT值小于接收PDCP SDU的COUNT值的PDCP SDU b.所有存储的，从接收到的PDCP SDU的COUNT值开始，连续COUNT值对应的PDCPSDU UE应将Last_Submitted_PDCP_RX_SN置为最后递交给高层的PDCP SDU的PDCP SN值 5）否则，如果接收到的PDCP SN＝Last_Submitted_PDCP_RX_SN﹢1，6）或者接收到的PDCP SN＝Last_Submitted_PDCP_RX_SN－Maximum_PDCP_SN UE应把相关COUNT值按照升序传递给上层

a.所有存储的，从接收到的PDCP SDU的COUNT值开始，连续COUNT值对应的PDCP SDU UE应将Last_Submitted_PDCP_RX_SN置为最后递交给高层的PDCP SDU的

PDCP SN值

2、映射到RLC UM的DRB过程

对于映射到RLC UM的DRN，在接收到低层的PDCP Data PDU以后（1）如果接收到的PDCP SN＜Next_PDCP_RX_SN 1）UE应将RX_HFN加1（2）UE应使用基于RX_HFN的COUNT值与接收到的PDCP SN值来解密此PDCP Data PDU（3）如果Next_PDCP_RX_SN＞Maximum_PDCP_SN 1）UE应将Next_PDCP_RX_SN置0 2）UE应将RX_HFN﹢1（4）执行已解密的PDCP Data PDU的头压缩（5）UE应将最后产生的PDCP SDU递交给上层

二、SRB过程

对于SRB，在接收到低层的PDCP Data PDU后（1）如果接收的PDCP SN＜Next_PDCP_RX_SN 1）UE应使用基于RX_HFN﹢1的COUNT与接收到的PDCP SN值来解密此PDU以及确认其完整性

（2）否则

1）UE应使用基于RX_HFN的COUNT与接收到的PDCP SN值来解密此PDU以及确认其完整性

（3）如果完整性确认使用并成功通过，或

（4）如果完整性确认不适用

1）如果接收的PDCP SN＜Next_PDCP_RX_SN UE应将RX_HFN加1 2）UE应将Next_PDCP_RX_SN置为接收到的PDCP SN﹢1 3）如果Next_PDCP_RX_SN＞Maximum_PDCP_SN UE应将Next_PDCP_RX_SN置0 UE应将RX_HFN加1 4）UE应将最后产生的PDCP SDU递交给上层（5）否则，如果完整性确认适用，但失败

1）UE应丢弃接收到的PDCP Data PDU 2）UE应将完整性确认失败报告递交给上层

5.2 重建过程

5.2.1 上行

1、映射到RLC AM的DRB过程 当上层请求一次PDCP重建时

（1）UE应重置上行链路的头压缩协议

（2）重建过程期间，UE应使用加密算法及上层提供的密钥加密

（3）从第一个对应的PDCP PDU成功传递但没有被下层确认的PDCP SDU开始，在如PDCP重建之前，执行所有由与此PDCP SDU对应的COUNT开始的，按照COUNT升序排列的PDCP SN值对应的PDCP SDU的重传或传输（4）UE应执行DCP SDU的头压缩

（5）UE应使用与此PDCP SDU关联的COUNT值来加密此PDCP SDU（6）UE应将最后产生的PDCP Data PDU传递给下层

2、映射到RLC UM的DRB过程 当上层请求一次PDCP重建时

（1）UE应重置上行链路的头压缩协议

（2）UE应置Next_PDCP_TX_SN以及TX_HFN为0（3）重建过程期间，UE应使用加密算法及上层提供的密钥加密

（4）对于每一个已经对应于一个PDCP SN，但相应的PDU没有事先传递给低层的PDCP SDU 1）UE认为此PDCP SDU是从上层接收而来

2）在PDCP重建之前，在不重启discardTimer的情况下，UE应按照与PDCP SDU关联的COUNT值的升序传输PDCP SDU

3、SRB过程

当上层请求一次PDCP重建时

（1）UE应置Next_PDCP_TX_SN及TX_HFN为0（2）UE应丢弃所有存储的PDCP SDU和PDCP PDU（3）重建过程期间，UE应使用加密和完整性保护算法，以及使用上层提供的密钥进行加密

5.2.2 下行

1、映射到RLC AM的DRB过程

当上层请求一次PDCP重建时

（1）UE应处理由于下层重建而从下层接收到的PDCP Data PDU（2）UE应重置下行链路的头压缩协议

（3）重建过程期间，UE应使用加密算法和上层提供的密钥进行加密

2、映射到RLC UM的DRB过程 当上层请求一次PDCP重建时

（1）UE应处理由于下层重建而从下层接收到的PDCP Data PDU（2）UE 应重置下行链路的头压缩协议

（3）UE应将Next_PDCP_RX_SN及RX_HFN置0（4）重建过程奇迹，UE应使用加密算法和上层提供的密钥进行加密

3、SRB过程

当上层请求一次PDCP重建时

（1）UE应丢弃由于下层重建而从下层接收来的PDCP Data PDU（2）UE应将Next_PDCP_RX_SN及RX_HFN置0（3）UE应丢弃所有存储的PDCP SDU和PDCP PDU（4）重建过程期间，UE 应使用加密和完整性保护算法，以及使用上层提供的密钥进行加密

5.3 PDCP状态报告

5.3.1 传输

对于映射到RLC AM的RB当上层请求一次PDCP重建时

如果此RB被上层配置用于在上行链路发送一个PDCP状态报告，在处理完因下层重建而从下层接收来的PDCP Data PCU以后，UE应按下述指示进行状态报告：（1）UE应将FMS置为第一个丢失的PDCP SDU的PDCP SN值

（2）如果至少有一个失序PDCP SDU被存储，则UE分配一个Bitmap field，长度等于从第一个丢失的PDCP SDU开始知道最后一个失序的PDCP SDU结束的PDCP SN的个数，四舍五入到下一个8的倍数

（3）UE将所有低层指示还未接受到的PDCP SDU以及任意解压缩失败的PDCP SDU在Bitmap field中对应的区域置0（4）对于其他的PDCP SDU，对应区域置1 5.3.2 接收

当在下行链路接收到一个PDCP状态报告时，对已映射到RLC AM的RB 对于每个PDCP SDU，如果在Bitmap中对应的bit位为1，或者相关联的COUNT值小于FMS字段确定的PDCP SDU的COUNT值，则相应PDCP SDU的成功传输将被确认，且UE应按照PDCP丢弃过程的规定来处理此PDCP。

5.4 PDCP丢弃

当用于PDCP SDU的discardTimer终止，或PDCP SDU的成功传输被PDCP状态报告确认，UE应就其此PDCP SDU及其对应的PDCP PDU。如果对应的PDCP PDU已经成功传递给下层，则丢弃需要指示给下层。

5.5 头压缩与解压缩

5.5.1 协议与简表

头压缩协议基于可靠性头压缩（ROHC）框架，存在多种头压缩算法，成为简表，定义用于ROHC框架。每个简表为特定的网络层、传输层或上层集合所专用。5.5.2 头压缩配置

与DRB关联的PDCP实体可被上层配置来使用头压缩 5.5.3 协议参数

压缩与解压缩端之间定义了必须有上层配置的强制配置参数，定义ROHC信道（单行信道，上行或下行），属于同一个PDCP实体的信道使用相同的配置。M、N/A、LARGE_CIDs、PROFILES（M）、FEEDBACK_FOR(N/A)、MRRU（N/A）5.5.4 头压缩

生成两种类型的输出数据包：

（1）压缩包，各自关联于一个PDCP SDU（与相关PDCP SDU相同的PDCP SN和COUNT关联）（2）独立数据包，为关联于PDCP SDU，即零散的ROHC反馈包（不与PDCP SDU关联，不与PDCP SN关联，不加密）

5.5.5 头解压缩

如果上层为关联与用户平面数据的PDCP实体配置了头解压缩，则PDCP PDU将在执行解密程序后由头解压协议进行解压缩

5.6 加密和解密

1、对于控制平面，加密的数据单元是PDCP PDU以及MAC-I的部分数据

2、对于用户平面，加密的数据单元是PDCP PDU的部分数据

3、加密不适用与PDCP控制PDU

4、加密算法和密钥由上层配置

5、加密功能由上层激活，激活后，应用于所有上层指示的上下行PDCP PDU

6、加密功能请求的输入：COUNT、DIRECTION

7、PDCP请求的，由上层提供的参数：BEARER、KEY（控制面/用户面）（1）BEARER：承载的标识，用于RB身份的标识

（2）DIRECTION：标识传输的方向，0用于上行、1用于下行（3）KEY：控制平面和用户平面的加密密钥分别为KRRCenc与KUPenc

5.7 完整性保护及确认

1、完整性保护+完整性确认

2、用于与SRB关联的PDCP

3、受完整性保护的数据单元为：PDU头和加密前的PDU部分数据

4、完整性保护算法和密钥由上层提供

5、完整性保护功能由上层激活，激活后，应用于从上层指定的PDU之后的上下行PDCP PDU

6、完整性保护算法的输入：COUNT、DIRECTION

7、PDCP请求的，由上层提供的数：BEARER、KEY

8、传输时，UE计算MAC-I字段的值

接收时，UE通过基于以上指定的输入参数计算X-MAX来确认PDCP PDU的完整性。如果计算得到的X-MAC与接收的MAC-I值相对应，则完整性保护确认成功

5.8 未知的、意外的以及错误的协议数据的处理

PDCP收到一个包括保留至或非法值的PDCP PDU时，PDCP实体应丢弃收到的PDU

补充PDCP实现LTE 接入层安全性过程

PDCP层通过接受高层的安全配置信令，进入相应的状态后才能对数据和信令进行加密及完整性保护，在正常的RRC连接建立完成并且通过层三的鉴权完成后，启动接入层的安全模式命令。网络端首先获得由非介入层的AKA（Authentication and Key Agreement）过程产生密钥KASME，然后RRC由该参数计算得到KeNB，再由KeNB计算得到控制平面的完整性保护密钥KRRCint，以及用户平面和控制平面需要的密钥KUPenc、KRRCenc，在组装成安全模式命令（SecurityModiCommand），发送给终端，配置中端的安全性参数。当网络端发出SecurityModeCommand消息后开始对下行数据进行加密，终端的PDCP层接收到SecurityModeCommand消息后，先将其发送到RRC进行解码操作，得出网络端配给终端的完整性保护算法，再将完整性保护算法和相应的密钥发给PDCP层，PDCP就可以对SecurityModeCommand消息进行完整性校验。如果没有通过完整性校验，则向网络端发送安全模式失败（SecurityModeFailure）；如果通过，则取出里面包含的加密算法，并向网络发送安全模式完成（SecurityModeComplete）消息，对其进行完整性保护但是不加密，自此后开始对上行数据加密，下行数据解密。网络端收到该消息后开始对上行数据解密，安全性建好后，开始对信令进行完整性保护。

接入层的安全性是通过加密算法和完整性保护算法来实现的。

接收时，UE通过基于以上指定的输入参数计算X-MAX来确认PDCP PDU的完整性。如果计算得到的X-MAC与接收的MAC-I值相对应，则完整性保护确认成功

第四篇：PDCP协议学习总结

PDCP协议学习总结

1、PDCP架构

UE/E-UTRANPDCP entiy Radio BearersPDCP-SAPPDCP-SAPC-SAPPDCP entityPDCP entity...PDCP sublayerPDCPSDU...RLC UM-SAPRLC AM-SAPRLC sublayer

2、PDCP实体：

一个UE可以定义多个PDCP实体，可以对携带用户面数据的每个PDCP实体进行配置，来使用头压缩。每个PDCP实体携带一个无线承载的数据（复用为2个）。根据无线承载所携带的数据，PDCP实体对应于控制平面DCCH或者用户平面DTCH

3、PCDP层服务 向上层提供的服务：（PDCP提供服务给UE的RRC层和用户面高层）（1）数据传输

（2）头压缩：IP包头压缩（3）加密

（4）完整性保护 从下层得到的服务：（RLC层向PDCP层提供服务）

（1）确认的数据传输业务，包括PDCP PDU成功传输的指示（2）非确认的数据传输业务

（3）有序传送，除了在切换时的情况（4）重复丢弃，除了在切换时的情况

4、PDCP层功能

（1）发送和接收实体利用ROHC（ROBUST HEADER COMPRESSION）协议对IP数据流进行相应的头压缩和解压缩

（2）用户面数据或者控制面数据的传输

（3）维护RLC AM模式下的映射的无线承载的PDCP SN（4）下层重建时，上层PDU的有序传送

（5）下层重建时，RLC AM模式下的映射的无线承载的下层SDU重复消除（6）用户面数据和控制面数据的加密和解密

（7）控制面数据的完整性保护与完整性验证(RRC层和NAS层)（8）基于计时器的丢弃（9）重复丢弃

5、PDCP过程

（1）PDCP数据传输过程 上行数据传输过程：每一个PDCP SDU对应一个Discard Timer，一旦由高层接收到一个PDCP SDU，即启动该SDU对应的Discard Timer。同时，进行发送相关的状态变量更新及加密、完整性保护等，PDCP SDU的Discard_Timer超时或PDCP SDU的成功传输有PDCp状态报告确认，UE丢弃PDCP SDU及相应的PDCP PDU

下行数据传输过程：在不需重建的情况下，PDCP实体在接收到RLC AM实体提交的PDCP PDU时，不需执行重排序过程，因为RLC AM在向PDCP实体提交PDCP PDU时，已保证顺序递交。若UE先从源eNodeB收到一些PDCP SDU，重建开始后从目的eNodeB接收PDCP SDU(其中部分是源eNodeB转给目的eNodeB的，并且有一些是源eNodeB已发给UE但尚未得到确认的)，因此，UE的PDCP实体收到的PDCP SDU可能是乱序并且有重复的，因此对于RLC AM模式，在重建情况下，PDCP接收实体需对接收的PDCP SDU进行重排序和重复检测。

（2）重建过程

上行数据传输过程：映射到RLC AM的DRB过程 映射到RLC UM的DRB过程 SRB过程 下行数据传输过程：映射到RLC AM的DRB过程 映射到RLC UM的DRB过程 SRB过程（4）PDCP丢弃：PDCP SDU的Discard_Timer超时或PDCP SDU的成功传输有PDCp状态报告确认，UE丢弃PDCP SDU及相应的PDCP PDU（5）头压缩与解压缩：

（6）加密和解密：加密不用于PDCP控制PDU 控制面：PDCP PDU中数据部分及MAC-I 用户面：PDCP PDU的数据部分

（对消息和加密流做异或(XOR)运算来实现的，这里加密流是由基于接入层(AS)导出密钥、无线承载ID、传输方向(上行或下行)以及COUNT值的加密算法所生成的。）

（7）完整性保护及确认：该功能仅用于SRB（8）未知的、意外的以及错误的协议数据的处理

6、PDCP协议数据单元及格式

PDCP数据PDU传送：一个PDU SDU SN、包含一个基于非压缩的PDCP SDU用户面数据、包含一个基于压缩的PDCP SDU用户面数据、控制平面数据、只有SRB的MAC-I域 PDCP控制PDU传送：PDCP状态报告、头压缩信息

5.5 头压缩与解压缩

5.5.1 协议与简表

头压缩协议基于可靠性头压缩（ROHC）框架，存在多种头压缩算法，成为简表，定义用于ROHC框架。每个简表为特定的网络层、传输层或上层集合所专用。5.5.2 头压缩配置

与DRB关联的PDCP实体可被上层配置来使用头压缩 5.5.3 协议参数

压缩与解压缩端之间定义了必须有上层配置的强制配置参数，定义ROHC信道（单行信道，上行或下行），属于同一个PDCP实体的信道使用相同的配置。M、N/A、LARGE_CIDs、PROFILES（M）、FEEDBACK_FOR(N/A)、MRRU（N/A）5.5.4 头压缩

生成两种类型的输出数据包：

（1）压缩包，各自关联于一个PDCP SDU（与相关PDCP SDU相同的PDCP SN和COUNT关联）（2）独立数据包，为关联于PDCP SDU，即零散的ROHC反馈包（不与PDCP SDU关联，不与PDCP SN关联，不加密）5.5.5 头解压缩

如果上层为关联与用户平面数据的PDCP实体配置了头解压缩，则PDCP PDU将在执行解密程序后由头解压协议进行解压缩

5.6 加密和解密

1、对于控制平面，加密的数据单元是PDCP PDU以及MAC-I的部分数据

2、对于用户平面，加密的数据单元是PDCP PDU的部分数据

3、加密不适用于PDCP控制PDU

4、加密算法和密钥由上层配置

5、加密功能由上层激活，激活后，应用于所有上层指示的上下行PDCP PDU

7、PDCP请求的，由上层提供的参数：BEARER、KEY（控制面/用户面）（1）BEARER：承载的标识，用于RB身份的标识

（2）DIRECTION：标识传输的方向，0用于上行、1用于下行

（3）KEY：控制平面和用户平面的加密密钥分别为KRRCenc与KUPenc

5.7 完整性保护及确认

1、完整性保护+完整性确认

2、用于与SRB关联的PDCP

3、受完整性保护的数据单元为：PDU头和加密前的PDU部分数据

4、完整性保护算法和密钥由上层提供

5、完整性保护功能由上层激活，激活后，应用于从上层指定的PDU之后的上下行PDCP PDU

7、PDCP请求的，由上层提供的数：BEARER、KEY

8、传输时，UE计算MAC-I字段的值

接收时，UE通过基于以上指定的输入参数计算X-MAX来确认PDCP PDU的完整性。如果计算得到的X-MAC与接收的MAC-I值相对应，则完整性保护确认成功

5.8 未知的、意外的以及错误的协议数据的处理

PDCP收到一个包括保留值或非法值的PDCP PDU时，PDCP实体应丢弃收到的PDU

补充PDCP实现LTE 接入层安全性过程

PDCP层通过接受高层的安全配置信令，进入相应的状态后才能对数据和信令进行加密及完整性保护，在正常的RRC连接建立完成并且通过层三的鉴权完成后，启动接入层的安全模式命令。网络端首先获得由非接入层的AKA（Authentication and Key Agreement）过程产生密钥KASME，然后RRC由该参数计算得到KeNB，再由KeNB计算得到控制平面的完整性保护密钥KRRCint，以及用户平面和控制平面需要的密钥KUPenc、KRRCenc，在组装成安全模式命令（SecurityModiCommand），发送给终端，配置终端的安全性参数。当网络端发出SecurityModeCommand消息后开始对下行数据进行加密，终端的PDCP层接收到SecurityModeCommand消息后，先将其发送到RRC进行解码操作，得出网络端配给终端的完整性保护算法，再将完整性保护算法和相应的密钥发给PDCP层，PDCP就可以对SecurityModeCommand消息进行完整性校验。如果没有通过完整性校验，则向网络端发送安全模式失败（SecurityModeFailure）；如果通过，则取出里面包含的加密算法，并向网络发送安全模式完成（SecurityModeComplete）消息，对其进行完整性保护但是不加密，自此后开始对上行数据加密，下行数据解密。网络端收到该消息后开始对上行数据解密，安全性建好后，开始对信令进行完整性保护。

接入层的安全性是通过加密算法和完整性保护算法来实现的。接收时，UE通过基于以上指定的输入参数计算X-MAX来确认PDCP PDU的完整性。如果计算得到的X-MAC与接收的MAC-I值相对应，则完整性保护确认成功

第五篇：MODBUS通讯协议学习总结

MODBUS通讯协议学习总结

1、协议分3个层次看：

协议应用函数层，如读写coil，寄存器； RTU或者ASCII传输层 硬件底层

2、比如上位机发来:01 06 00 01 02 D5 00 55 含义:表示上午12点05分开始采集，12*60+5=725=0X02D5 01地址

06表示功能码 00 01寄存器地址 02 D5数据 00 55 crc

3、就当是一个简单的协议看。其它的都是格式。比如：上位机发送A，下位机知道这个是>90分

按照他给的框架，自己再自由定义

比如：从机地址，可以写01-FF 255个这个是从机先固定好的。比如从机是01。上位机发了一串16进制数据，如果第一个字节是01，说明是在和自己通信。每台从机地址都不一样

再判断功能码。如03。这个看你写程序是怎么定义的。比如我这里是要读下位机采集到的数据，我这里就是设置了一个数组，把数据存了起来，等判断03的时候就把数据给上位机。

4、寄存器地址。自己定义，我这边是随便写的一个固定值

5、还有一个crc判断。读数据的时候，判断下。如果上位机发过来的crc，和自己计算出来的crc一样，才给返回数据

6、那个CRC怎么计算呢？

有固定的计算格式，只需调用即可。crc 在通过modbus串口传数据的时候用，网络上不用。