LTE学习之ROHC RFC4995（框架性描述）阅读笔记

巍巍泰然

已于 2023-06-14 10:28:28 修改

阅读量1k

点赞数 1

文章标签：网络网络协议学习

于 2023-06-13 16:36:10 首次发布

本文链接：https://blog.csdn.net/weixin_45752679/article/details/131190905

版权

ROHC（RobustHeaderCompression）是一种用于压缩数据包头部的协议，旨在减少无线和其他带宽有限链路上的传输开销。文章讨论了ROHC的基本原理、历史、压缩效率与健壮性的平衡，以及上下文管理和错误检测机制。它还介绍了不同类型的压缩数据包和头格式，以及反馈机制在保持压缩通道的正确操作中的作用。

摘要由CSDN通过智能技术生成

Acronyms 缩写

ACK（Acknowledgment）：确认，用于表示接收方已成功接收到数据的确认信号。
CID（Context Identifier）：上下文标识符，用于标识 ROHC 上下文。
CO（Compressed Packet Format）：压缩数据包格式，用于描述压缩后的数据包的格式。
CRC（Cyclic Redundancy Check）：循环冗余校验，用于检测数据传输中是否出现错误。
IR（Initialization and Refresh）：初始化和刷新，用于指示 ROHC 过程中的初始化和刷新操作。
IR-DYN（Initialization and Refresh, Dynamic part）：初始化和刷新的动态部分，是 ROHC 过程中与动态字段相关的初始化和刷新操作。
LSB（Least Significant Bit(s)）：最低有效位，二进制数中权重最低的位。
MRRU（Maximum Reconstructed Reception Unit）：最大重建接收单元，指示在解压缩过程中最大可接收的单元大小。
MSB（Most Significant Bit(s)）：最高有效位，二进制数中权重最高的位。
MSN（Master Sequence Number）：主序列号，用于标识 ROHC 上下文中的数据包序列号。
NACK（Negative Acknowledgment）：表示接收方未成功接收到数据的否定确认信号。
ROHC（RObust Header Compression）：健壮性头部压缩，是一种用于压缩和解压缩数据包头部的协议。

ROHC Terminology 术语

Context 上下文： 压缩器的上下文是指其用于压缩报头所使用的状态。解压缩器的上下文是指其用于解压缩报头所使用的状态。当明确指定时，这些参数中的任意一个或两个结合在一起通常被称为"上下文"。上下文包含了先前数据包流中的相关信息，例如静态字段和用于压缩和解压缩的可能参考值。此外，上下文还包含描述数据包流的其他信息，例如字段的变化行为（如IP标识符的行为，或序列号和时间戳的典型数据包间增量）。

Context damage 上下文损坏： 当解压器的上下文与压缩器的上下文不一致时，解压操作可能无法正确还原原始的头部信息，导致解压失败。这种情况可能发生在解压器的上下文没有正确初始化，或者在压缩器和解压器之间的数据包丢失或损坏时。由于上下文不一致而无法解压缩的数据包被称为因上下文损坏而丢失。由于上下文不一致导致解压缩后的数据包包含错误的数据被称为"由于上下文损坏而受损的数据包"。

Context repair mechanism 上下文修复机制： 上下文修复机制用于重新同步上下文，这是一个重要的任务，因为上下文损坏会导致丢失的传播。这些机制的示例包括基于NACK的机制以及重要上下文信息的定期刷新，通常在单向操作中执行。还有一些机制可以降低上下文不一致的概率，例如在多个数据包中重复相同类型的信息和使用CRC来保护上下文更新信息。

CRC-8 validation CRC-8确认： CRC-8验证是指使用IR/IR-DYN头中包含的8位CRC对接收到的IR和IR-DYN头中的位错误进行完整性验证。

CRC verification CRC验证： CRC验证是指使用压缩包格式的标头中包含的3位CRC或7位CRC尝试解压缩结果的验证。

Damage propagation 损害传播： 由于上下文损坏，即由于先前标头或反馈中的错误（即丢失或损坏）而造成的错误减压标头的损坏传播传递。

Error detection 错误检测： 下层错误检测。如果误差检测不完美，就会有残差。

Error propagation 错误传播： 损伤传播或损耗传播。

ROHC profile ROHC配置文件： ROHC配置文件是一种压缩协议，它指定如何压缩特定的标头组合。 ROHC配置文件可以被定制来处理一组特定的链路特性，例如损失特性、压缩点之间的重新排序等。 ROHC配置文件提供了在本文档中定义的报头压缩框架的详细信息，并且每个压缩配置文件都与一个唯一的ROHC配置文件标识符相关联。在设置ROHC通道时，将协商通道的两个端点支持的配置文件集，并且在初始化新上下文时，将使用来自该协商集的配置文件标识符将每个压缩上下文与一个特定的配置文件关联起来。

Link 链路： 构成单个IP跳点的物理传输路径。

Loss propagation 丢失传播： 由于错误或反馈导致的头丢失。

Packet flow 数据包流： 一组数据包，其中的字段值和字段值的更改模式使得可以使用相同的上下文压缩报头。

Residual error 剩余误差： 在传输过程中引入的误差，而底层误差检测方案没有检测到。

ROHC channel ROHC 通道： ROHC通道是一个逻辑的单向点对点通道，用于将ROHC数据包从一个压缩器传输到一个解压器。它可以选择性地承载另一个压缩器-解压器对在相反方向上操作的单独ROHC通道上的ROHC反馈信息。

背景(信息性)

头压缩成立的基础

头部压缩是可行的，因为头部字段之间存在着重复冗余，特别是在属于同一数据流的连续数据包之间。

在端到端的路径上，数据流中的所有数据包都需要完整的头部信息，但是在单个链路上，一些信息会变得冗余，可以进行压缩，只要在链路接收端能够透明地恢复这些信息。

通过首先发送那些预计在数据流的生命周期中保持不变的字段信息，可以减小头部的大小。

对于那些包含更动态变化信息的字段，可以使用针对其假定的变化行为设计的压缩方法来进一步压缩。

为了实现压缩和解压缩，需要在上下文中保存一些过去数据包的必要信息。

压缩器和解压器根据某些特定的事件（不一定同步）来更新各自的上下文。

在某些情况下，可能会出现解压器上下文的不一致性（即上下文损坏），从而导致解压缩错误。

Robust Header Compression (ROHC)方案需要一些机制来最小化上下文损坏的可能性，并提供上下文修复的机制。

头压缩的简短历史

第一个头压缩方案是由Van Jacobson引入的压缩TCP (CTCP) 。

CTCP，通常也称为VJ压缩，将TCP/IP头部的40个字节压缩为4个字节。

CTCP使用增量编码来处理顺序变化的字段。

CTCP压缩器会检测传输层的重传，并在发生重传时发送一个更新整个上下文的头部。

这种修复机制不需要压缩器和解压器之间的显式信号。

一个通用的IP头部压缩方案，IP头部压缩 (IPHC) ，对CTCP进行了一定的改进。

IP头部压缩可以压缩任意的IP、TCP和UDP头部。

在压缩非TCP头部时，IPHC不使用增量编码，因此更加稳健。（为什么？）

CTCP的修复机制增加了负面确认机制，称为CONTEXT_STATE消息，加快了修复过程。

这种上下文修复机制受到链路往返时延的限制。

IPHC不会压缩RTP头部。

CRTP是IPHC对RTP的扩展。当未启用UDP校验和时，CRTP将IPv4/UDP/RTP头部的40个字节压缩为至少2个字节。

如果启用了UDP校验和，则CRTP头部的最小长度为4个字节。

在有长时间往返时延的有损链路上，CRTP的性能表现不佳。

链路上每个丢失的数据包都会导致多个后续数据包的解压缩失败，因为上下文在丢失的数据包的至少一个链路往返时间内变得无效。

不幸的是，CRTP在更新上下文时发送的大型头部会浪费额外的带宽。

CRTP使用了一种局部修复机制，被称为TWICE，这是由IPHC引入的。（既然是在IPHC中引入的，为什么要在CRTP中突出它？）

TWICE得名于以下观察结果：当压缩数据包的流是规则的时候，在两个压缩点之间丢失一个数据包时，可以猜测在当前数据包中应用两次更新是正确的。（为什么？）

尽管TWICE显著改善了CRTP的性能，还发现即使使用TWICE，CRTP丢失的数据包数量也增加了一倍。

CRTP的一个增强版本称为eCRTP，旨在提高CRTP在存在重排序和数据包丢失情况下的健壮性，同时几乎不改变协议与CRTP相比。

因此，尽管以附加开销为代价，eCRTP确实提供了更好的实现一定程度健壮性的方法，但相对于CRTP而言，压缩效率会降低。

健壮头压缩（ROHC）概述（信息性）

General Principles (总纲)

如前所述，由于包内的头字段值之间，特别是属于同一流的连续包之间存在很多冗余，因此每个链接的头压缩是可能的。

头压缩是通过利用数据包中头字段值之间的冗余实现的，尤其是同一数据流中连续数据包之间的冗余。

要利用这些属性进行头压缩，需要考虑几个基本步骤的内容。

第一步是将数据包识别并分组到不同的“流”中，以便最大化包对包的冗余，从而提高压缩比。

将数据包分组到流中通常基于源和目标主机(IP)地址、传输协议类型(例如，UDP或TCP进程)、(端口)号以及潜在的附加的唯一应用程序标识符，例如RTP中的同步源(SSRC)。

压缩器和解压缩器分别为包流建立上下文，并在每个压缩头中包含上下文标识符（CID）来标识上下文。

第二步是了解各种标头字段的更改模式。

在高级级别中，报头字段属于以下类之一：

推断（INFERRED）：这些字段包含可以从其他字段或外部源推断出的值，例如，携带数据包的帧的大小通常可以从链路层协议中推导出，因此不必通过压缩方案进行传输。
静态（STATIC）：归类为静态的字段在包流的整个生命周期中是恒定的。因此，每个字段的值只在初始时进行通信。
静态定义（STATIC-DEF）：静态定义字段用于定义数据包流。具有这些字段值不同的数据包被视为属于不同的流。这些字段通常被压缩为静态字段。
静态已知（STATIC-KNOWN）：静态已知字段的值是已知的，因此不需要进行通信。
更改（CHANGING）：这些字段有望随机变化，可以是在有限的值集或范围内，或以其他方式变化。更改字段通常根据更详细的更改模式分类以更复杂的方式处理。

最后，最后一步是根据分类选择将应用于不同字段的编码方法。

编码方法结合识别的字段行为，为压缩头格式的设计提供输入。

然后，对识别的更改模式的概率分布进行分析，以优化数据包格式，其中最常出现的字段更改模式应在最有效的格式中进行编码。

然而，压缩效率必须与两个其他特性进行权衡：

编码对压缩机和解压缩机之间的丢失和错误的健壮性。
检测和处理解压过程中的错误的能力。

压缩效率、健壮性和透明度

压缩效率、健壮性和压缩透明度是描述报头压缩协议性能的三个参数。

压缩效率是通过应用压缩协议降低平均报头大小的程度来确定的。

健壮性是指在报头压缩进行时，能够容忍链路中的数据包丢失、剩余位错误和乱序传递，而不会丢失额外的数据包或在解压后的报头中引入额外的错误。

压缩透明度是衡量协议在保持原始报头语义方面的程度。

如果所有解压后的报头与相应的原始报头完全一样，那么该方案就是透明的。

开发ROHC协议

在开发报头压缩协议时，面临的挑战是在保持透明性的同时，平衡压缩效率和健壮性，因为提高健壮性必然会降低压缩效率，反之亦然。

设计方案还应具有足够的灵活性，以最小化应用报头压缩的链路上往返时间和丢包模式的影响。

为了实现这一目标，报头压缩方案必须提供解压缩器验证解压缩和检测潜在上下文损坏的功能，以及上下文恢复机制，如反馈。

在开发Robust Header Compression (ROHC) WG之前的报头压缩方案并未考虑到上述高级目标。

ROHC WG已经开发了报头压缩解决方案，以满足现有和未来链路技术的需求。

尽管特别关注满足无线链路特性所带来的更严格要求，但所得到的结果同样适用于许多其他链路技术。

RFC 3095 ，"RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"，于2001年发布，是ROHC WG的第一个成果。

ROHC是一个通用且可扩展的报头压缩框架，可以为不同协议的报头定义配置文件。

RFC 3095引入了许多新的压缩技术，并成功地满足了所要求的目标。

对RFC 3095的互操作性测试证实了ROHC满足其目的的能力，但实施者的反馈也表明协议规范复杂且有时不够清晰。

最重要的是，在中没有明确区分框架和配置文件，这也使得开发其他配置文件变得麻烦。

ROHC通道的运行特性

健壮的报头压缩（ROHC）可以用于许多类型的链接技术。ROHC框架提供了灵活性，以适应广泛的应用场景。本节列出了ROHC通道的一些运行特性。

通过单个逻辑通道进行多路复用：ROHC通道提供了一种机制，可以在通用ROHC数据包格式中识别上下文。通过上下文标识符（CID），支持ROHC的逻辑通道可以传输多个经过报头压缩的流，同时仍然可以将一个通道专用于单个数据包流，而不会引入任何CID开销。

具体来说，ROHC为每个逻辑通道使用一个独立的上下文标识符空间，并且当配置为使用较小的CID空间时，可以在ROHC通道上的某个流中省略上下文标识符。

通道参数的建立：支持ROHC通道的链路层必须提供建立报头压缩通道参数的手段。这可以通过协商机制、静态配置或一些带外信令来实现。
数据包类型标识：ROHC通道定义了一个数据包类型标识符空间，并对所有ROHC配置文件中常见的标识符的使用进行了限制。每个压缩报头中都包含标识符，这使得支持ROHC通道的链路可以为ROHC分配一个单个链路层有效负载类型。
压缩端点之间的无序交付：每个配置文件都定义了自己的鲁棒性级别，包括对数据包在压缩端点之间的重新排序的容忍度。对于某些配置文件，要求在压缩器和解压器之间保持数据包的有序传递，即解压器接收到的数据包顺序与压缩器发送的顺序相同。对于另一些配置文件（ROHCv2），其定义假设解压器可以接收无序的数据包，即不按照压缩器发送的顺序接收数据包。在压缩点之前的重新排序也会得到处理。
数据包的重复：支持ROHC通道的链路不允许数据包重复（不过，在数据包到达压缩器之前可能会发生重复，即不能假设压缩器只接收到每个数据包的一个副本）。
帧分割：链路层必须提供帧分割机制，以便能够区分帧的边界和各个独立的帧。
错误检测/保护：ROHC配置文件应设计为能够处理传递给解压器的头部中的残余错误。循环冗余校验（CRC）用于检测解压失败并防止或减少错误传播。建议在较低层使用错误检测机制来处理ROHC头部，并避免传递具有较高残余错误率的ROHC头部。

压缩和主序列号（MSN）

头部字段的压缩是基于对一个序列号的函数建立的，该序列号称为主序列号（MSN）。

这个函数描述了字段相对于MSN的变化模式。

变化模式可以包括字段的单调增加或以小的增量增加，很少发生变化的字段，以及整个数据包流的生命周期内保持不变的字段。在后一种情况下，函数对MSN的结果等于一个常量值。

压缩器首先为每个头部字段建立函数，然后可靠地传输MSN。

当字段的变化模式与已建立的函数不匹配时，即现有函数给出的结果与正在压缩的头部字段不同，可以发送附加信息来更新该函数的参数。

MSN是根据配置文件定义的。

它可以直接从要压缩的协议的某个字段派生（例如，RTP序列号），也可以由压缩器创建和维护（例如，在配置文件0x0102中压缩UDP的MSN 或ROHC-TCP中的MSN）。

上下文的静态部分和动态部分

压缩上下文可以在概念上分为两个不同的部分，即静态部分和动态部分，每个部分都基于正在压缩的字段的属性。

静态部分包括压缩和解压缩需要的信息，这些信息对应于被归类为STATIC、STATIC-KNOWN或STATIC-DEF的字段的变化行为。

动态部分包括为所有其他字段维护的状态，即被归类为CHANGING的字段。

ROHC框架（规范性描述）

本节规范性地定义了适用于所有ROHC配置文件的共同部分，即框架。框架规定了ROHC信道的要求和功能，包括如何处理在同一信道上的多个压缩的数据流。

最后，本节规定了所有配置文件中通用的数据包格式中使用的编码方法。这些编码方法可以在配置文件的规范部分中重复使用，以对数据包格式中的特定部分的字段进行编码，而无需重新定义它们。

ROHC信道

上下文和上下文标识符

与每个压缩数据流相关联的是一个上下文。上下文是压缩器和解压器为了正确压缩或解压数据流中的报头而维护的状态。

每个上下文使用一个上下文标识符（CID）进行标识。

当CID自创建ROHC通道以来首次与配置文件相关联时，或者当CID与不同于上下文中配置文件的IR相关联（不适用于IR-DYN）时，上下文被视为新的上下文。

上下文信息在概念上保存在一个表中。上下文表使用CID作为索引，CID随压缩报头和反馈信息一起发送。

CID空间可以是小的，即CID的取值范围为0到15，也可以是大的，即CID的取值范围为0到2^14 - 1 = 16383。

在任何压缩报头被发送到ROHC信道之前，必须明确CID空间是大的还是小的，可以通过协商来确定。

CID空间对于每个信道是独立的，即信道A上的CID 3和信道B上的CID 3不指代同一个上下文，即使A和B的端点是相同的节点。

特别地，任何一对ROHC信道的CID之间没有关联（作为彼此的反馈信道服务的两个相关ROHC信道甚至不需要具有相同大小的CID空间）。

Per-Channel Parameters 每信道参数

ROHC信道基于一些参数，这些参数构成了建立的信道状态和每个上下文状态的一部分。

ROHC信道的状态必须在发送第一个ROHC数据包之前建立，可以使用链路层提供的协商协议来实现（参见[4]，描述了PPP的ROHC参数协商选项）。

本节以抽象的方式描述了一些信道状态信息：

LARGE_CIDS: 布尔值；

如果为false，使用小CID表示（0个八位字节或1个前缀八位字节，表示CID 0到15）；如果为true，使用大CID表示（1个或2个嵌入的CID八位字节，表示CID 0到16383）。

MAX_CID: 非负整数；

压缩器要使用的最大CID编号（请注意，此参数与LARGE_CIDS没有直接关联，但在实际上受到进一步约束）。该值表示解压器同意能够提供足够的内存资源来承载至少MAX_CID+1个上下文；解压器必须在该空间内维护已建立的上下文，直到CID通过建立新上下文而被重用，或者直到信道关闭。

PROFILES: 非负整数集合；

其中每个整数表示压缩器和解压器都支持的一个配置文件。配置文件由一个16位值标识，其中8个LSB位表示实际配置文件，8个MSB位表示该配置文件的变体。 ROHC压缩报头格式仅使用8个LSB位来标识所使用的配置文件；这意味着如果ROHC信道有同一配置文件的多个变体可用，协商后的PROFILES集合不能包含同一配置文件的多个变体。压缩器不能使用不在PROFILES中的配置文件进行压缩。

FEEDBACK_FOR: 对于同一压缩端点之间相反方向的ROHC信道的可选参考。如果提供了该参数，表示这个ROHC通道发送的反馈指向哪个ROHC通道。

MRRU: 非负整数。

这是解压器预计从分段中重新组装的最大重构单元的大小，以八位字节为单位。该大小包括分段CRC。如果协商的MRRU为0，则不能在信道上使用分段，解压器必须丢弃接收到的分段。

解压器上下文的持久性

作为协商的信道参数的一部分，压缩器和解压器通过MAX_CID参数约定了要使用的最高上下文标识（CID）编号。

通过达成对MAX_CID的约定，解压器也同意提供内存资源，以承载至少MAX_CID+1个上下文，并且在协商的空间内保留具有CID的已建立上下文应由解压器保留，直到CID被重用，或者信道关闭或重新协商。

ROHC数据包和数据包类型

在图表中表示各种ROHC数据包类型、格式和字段时，使用以下约定：

冒号“:”表示这部分是可选的
斜杠“/”表示可变长度

ROHC数据包类型指示方案旨在提供可选的填充、反馈数据包类型、可选的Add-CID八位（包括4位CID）以及简单的分段和重组机制。

在ROHC框架级别，以下数据包类型已保留：

11100000 : 填充

1110nnnn : Add-CID八位（nnnn表示CID，取值为0x1到0xF）

11110 : 反馈

11111000 : IR-DYN数据包

1111110 : IR数据包

1111111 : 分段

其他数据包类型可以由各个配置文件定义和使用：

0 : 可用（未被ROHC框架保留）

10 : 可用（未被ROHC框架保留）

110 : 可用（未被ROHC框架保留）

1111101 : 可用（未被ROHC框架保留）

11111001 : 可用（未被ROHC框架保留）

ROHC数据包的通用格式

ROHC数据包具有以下通用格式：

--- --- --- --- --- --- --- ---
: Padding :
--- --- --- --- --- --- --- ---
: Feedback :
--- --- --- --- --- --- --- ---
: Header :
--- --- --- --- --- --- --- ---
: Payload :
--- --- --- --- --- --- --- ---

(All optional?)

填充：填充八位字节的数量可以是任意个（零个或多个），填充八位字节的格式在5.2.1.1节中定义。

反馈：反馈元素的数量可以是任意个（零个或多个），反馈元素的格式在5.2.4.1节中定义。

头部：可以是特定于配置文件的CO头（参见5.2.1.3节），IR或IR-DYN头（参见5.2.2节），或ROHC段（参见5.2.5节）。

一个ROHC数据包中最多只能有一个头部，但也可以省略（如果包只包含反馈）。

负载：对应于未压缩包中的零个或多个八位字节的有效负载，从当前配置文件可以压缩的最后一个头部之后的未压缩包中的第一个八位字节开始。

至少要有一个反馈或头部。

填充八位字节的格式

Padding octet:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+

注意：填充八位字节不能被解释为CID为0的Add-CID八位字节。

5.2.1.2. Add-CID八位字节的格式

Add-CID octet:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+

CID：0x1到0xF表示CID为1到15。

注意：填充八位字节看起来像CID为0的Add-CID八位字节。

头部的通用格式

所有ROHC数据包类型都具有以下通用的头部格式：

0 x-1 x 7
+---+---+---+---+---+---+---+---+
: Add-CID octet : if CID 1-15 and small CIDs
+--- --- --- --- ---+--- --- ---+
| type indication | body | 1 octet (8-x bits of body)
+--- --- --- --- ---+--- --- ---+
: :
/ 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ body / variable length
+---+---+---+---+---+---+---+---+

类型指示：ROHC数据包类型。

体：根据数据包类型指示和CID信息进行解释，由各个配置文件定义。

因此，头部要么以数据包类型指示开始，要么在Add-CID八位字节之后紧跟着数据包类型指示。

当ROHC信道配置为小CID空间时：

如果Add-CID紧跟在数据包类型指示之前，数据包的CID为Add-CID的CID；否则，CID为0。
值为0的小CID使用零位表示；因此，与CID为0关联的流在压缩头部中没有CID开销。在这种情况下，头部以数据包类型指示开始。
值为1到15的小CID使用上述的Add-CID八位字节表示。头部以Add-CID八位字节开始，后面跟着数据包类型指示。
头部中没有大CID。

当ROHC信道配置为大CID空间时：

大CID始终存在，并且使用编码方案表示，限制为两个八位字节。在这种情况下，头部以数据包类型指示开始。

初始化和刷新（IR）数据包类型

IR数据包类型包含一个配置文件标识符，确定了头部的其余部分的解释方式。

它们还将配置文件与上下文相关联。

存储的配置文件参数进一步确定了在特定上下文中使用的数据包类型标识符和数据包类型的语法和语义。

IR和IR-DYN数据包始终更新头部中的所有上下文更新字段的上下文。

它们从不清除上下文，除非初始化新的上下文，或者除非概要文件字段中指定的配置文件另行指定。

Initialization and Refresh (IR) Packet Types 初始化和刷新（IR）数据包类型

IR数据包类型包含一个配置文件标识符，它决定了如何解释报头的其余部分。

它们还将一个配置文件与一个上下文关联起来。

存储的配置文件参数进一步确定了与特定上下文一起使用的包类型标识符和包类型的语法和语义。

IR和IR-DYN数据包总是更新报头中携带的所有上下文更新字段的上下文。

除非在初始化新上下文时，或者除非概要文件字段中指示的概要文件另行指定，它们从不清除上下文。

ROHC IR数据包类型

IR头部将CID与配置文件关联，并通常也初始化上下文。

它通常还可以刷新所有（或部分）上下文。

对于IR，头部具有以下通用格式：

0 1 2 3 4 5 6 7
+--- --- --- --- --- --- --- ---+
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+

x：配置文件特定信息。根据IR头部的配置文件字段中指示的配置文件进行解释。

配置文件：与CID关联的配置文件。在IR头部中，配置文件标识符缩写为8个最低有效位。

CRC：8位CRC。

配置文件特定信息：IR头部的此部分的内容由各个配置文件定义。

根据IR头部中指示的配置文件进行解释。

ROHC IR-DYN Packet Type (IR-DYN代表“初始化和刷新-动态”)

与IR标头相比，IR-DYN标头永远不能初始化未初始化的上下文。

然而，如果IR-DYN标头中指示的配置文件允许，它可以重新定义与上下文相关联的配置文件。

因此，这种数据包类型也被保留在框架级别上。

IR-DYN标头通常还会初始化或刷新上下文的一部分。

对于IR-DYN，标题具有以下通用格式：

0 1 2 3 4 5 6 7
+--- --- --- --- --- --- --- ---+
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+