CN100440869C - Method for starting user datagram protocol packet header compression - Google Patents
Method for starting user datagram protocol packet header compressionDownload PDFInfo
- Publication number
- CN100440869C CN100440869CCNB200610072688XACN200610072688ACN100440869CCN 100440869 CCN100440869 CCN 100440869CCN B200610072688X ACNB200610072688X ACN B200610072688XACN 200610072688 ACN200610072688 ACN 200610072688ACN 100440869 CCN100440869 CCN 100440869C
- Authority
- CN
- China
- Prior art keywords
- compression
- message
- context
- header
- udp
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Translated fromChinese
Description
Translated fromChinese技术领域technical field
本发明涉及报文压缩技术领域，尤其是启动用户数据报协议(UserDatagram Protocol，简称UDP)报文首部压缩的方法。The invention relates to the technical field of message compression, in particular to a method for starting User Datagram Protocol (UserDatagram Protocol, UDP for short) message header compression.
背景技术Background technique
在TCP/IP技术中为了减低点到点链路中报文流的冗余，采用了一种IP首部压缩的技术，即IPHC(IP Header Compression)技术，这种技术是基于以下的原理来实现的：在同一个报文流(例如Socket连接中的报文流)中，组成报文首部的大部分字段都是始终保持不变的，例如：源、目的地址，源、目的端口号等，这些保持不变的字段被称为该报文流的压缩解压缩上下文，如果在点到点链路的两端建立起报文流对应的压缩解压缩上下文，那么在接下来的压缩方发送的后续报文中，只需携带报文首部中发生变化的字段，而不需要完整的报文首部，这样解压缩方也能够根据压缩解压缩上下文和发生变化的字段解压出该后续报文原来的首部，从而降低了报文流的冗余，降低了网络消耗。In TCP/IP technology, in order to reduce the redundancy of message flow in point-to-point links, an IP header compression technology, that is, IPHC (IP Header Compression) technology is adopted. This technology is realized based on the following principles : In the same message flow (such as the message flow in the Socket connection), most of the fields that make up the header of the message are always unchanged, such as: source, destination address, source, destination port number, etc., These fields that remain unchanged are called the compression and decompression context of the packet flow. If the compression and decompression context corresponding to the packet flow is established at both ends of the point-to-point link, then the next compressor sends In the subsequent message, only the changed fields in the message header need to be carried instead of the complete message header, so that the decompressor can also decompress the original message of the subsequent message according to the compression and decompression context and the changed fields. header, thereby reducing the redundancy of the message flow and reducing network consumption.
在压缩方和解压缩方之间可能会同时存在多个报文流，因此需要用上下文标识(Context Identifier，简称CID)来区分不同报文流的上下文，每一个上下文必须分配一个唯一的CID标识，如果报文流为传输控制协议(Transmission Control Protocol，简称TCP)报文流，则只需要CID标识就足够了，但如果报文流为非TCP报文流(例如UDP报文流)，则还需要在上下文发生变化的时候使用Generation标识来区分上下文的不同版本。There may be multiple message streams between the compressor and the decompressor at the same time, so it is necessary to use the context identifier (Context Identifier, CID for short) to distinguish the context of different message streams. Each context must be assigned a unique CID identifier. If the packet flow is a Transmission Control Protocol (TCP) packet flow, only the CID identifier is sufficient, but if the packet flow is a non-TCP packet flow (such as a UDP packet flow), then the It is necessary to use the Generation identifier to distinguish different versions of the context when the context changes.
在IPHC技术中，报文可以根据作用不同分为两类：一种是用于建立上下文的完整首部报文，一种是建立上下文后发送的压缩首部报文。以UDP报文为例，每一个UDP报文，其数据净荷的前面会封装上UDP首部和IP首部，IP首部和UDP首部都是由很多字段组成的，这些字段的长度和顺序是由协议严格规定的。在IP首部中有一个字段叫“长度”字段，它的取值表示报文从IP首部开始的长度，即IP首部以及UDP首部和报文净荷的总长度。UDP首部中也有一个字段叫“长度”字段，它的取值表示报文从UDP首部开始的长度，即UDP首部和报文净荷的总长度。与此同时，IP首部中还有一个字段是“IP首部长度”字段，该字段的取值表示报文IP首部的长度。假如已经了解了链路层承载净荷的总长度(即IP首部、UDP首部以及数据净荷的总长度)，那么就等于知道了IP首部中“长度”字段的值，根据这个值以及IP首部中“IP首部长度”字段的值，就可以得出UDP首部中“长度”字段的值。因此，这两个长度字段的值是冗余的，从而可以利用这两个字段来携带CID标识和Generation标识，这样的报文被称为完整首部(FULL_HEADER)报文，其中Generation标识只是针对非TCP报文而存在的。In the IPHC technology, packets can be divided into two types according to different functions: one is a complete header packet used to establish a context, and the other is a compressed header packet sent after the context is established. Take the UDP message as an example. For each UDP message, the UDP header and IP header will be encapsulated in front of the data payload. The IP header and the UDP header are composed of many fields. The length and order of these fields are determined by the protocol. strictly regulated. There is a field called "length" in the IP header, and its value indicates the length of the message starting from the IP header, that is, the total length of the IP header, UDP header and message payload. There is also a field called "length" in the UDP header, and its value indicates the length of the message starting from the UDP header, that is, the total length of the UDP header and the payload of the message. At the same time, there is another field in the IP header is the "IP header length" field, and the value of this field indicates the length of the IP header of the message. If you have already known the total length of the payload carried by the link layer (that is, the total length of the IP header, UDP header and data payload), then it is equivalent to knowing the value of the "length" field in the IP header. According to this value and the IP header The value of the "IP Header Length" field in the UDP header can be obtained from the value of the "Length" field in the UDP header. Therefore, the values of these two length fields are redundant, so that these two fields can be used to carry the CID identifier and the Generation identifier. Such a message is called a complete header (FULL_HEADER) message, and the Generation identifier is only for non- exists for TCP packets.
在建立压缩解压缩上下文后，压缩首部报文只携带CID标识、Generation标识(针对于非TCP报文)以及首部中发生变化的字段。After the compression and decompression context is established, the compressed header message only carries the CID identifier, the Generation identifier (for non-TCP packets) and the changed fields in the header.
在压缩方和解压缩方之间正确的建立压缩解压缩上下文是IPHC技术的关键，如果完整首部报文在传输中发生丢失，解压缩方就无法根据该报文建立相应的上下文，从而解压缩方后期接收的压缩首部报文将因为解压缩失败而被丢弃。为了正确的建立UDP报文流的压缩解压缩上下文，现有技术采用了一种慢启动的方法来保证上下文的正确建立，基本原理是：在压缩启动的过程中，采用一种渐变的发送过程，即先发送一个完整首部报文，随后发送一个压缩报文，然后再发送一个完整首部报文，随后再发送2个压缩报文，即每发送2n个压缩报文就需要发送一个完整首部报文，当连续发送的压缩报文个数2n达到设定值后，就每隔2n个压缩报文发送一个完整首部报文来进行定期的刷新，这时便进入了稳定的发送状态。Establishing the correct compression and decompression context between the compressor and the decompressor is the key to the IPHC technology. If the complete header message is lost during transmission, the decompressor cannot establish a corresponding context based on the message, so the decompressor Compressed header packets received later will be discarded due to decompression failures. In order to correctly establish the compression and decompression context of the UDP message stream, the existing technology adopts a slow start method to ensure the correct establishment of the context. The basic principle is: in the process of compression startup, a gradual transmission process is adopted , that is, first send a complete header message, then send a compressed message, then send a complete header message, and then send 2 compressed messages, that is, for every 2n compressed messages, a complete header needs to be sent message, when the number of compressed messages sent continuously reaches the set value 2n , a complete header message is sent every 2n compressed messages for regular refresh, and then it enters a stable sending state .
如图1所示，为现有技术中慢启动过程的示意图，其中FH表示完整首部报文，CH表示压缩首部报文，从图1中能看出慢启动过程是个比较漫长的过程，通常需要发送9次完整报文才能进入稳定发送状态，这样带来以下问题：As shown in Figure 1, it is a schematic diagram of the slow start process in the prior art, wherein FH represents a complete header message, and CH represents a compressed header message. It can be seen from Figure 1 that the slow start process is a relatively long process, usually requiring Sending 9 complete packets can enter the stable sending state, which brings the following problems:
如果报文流频繁的发生变化(即不断出现新的报文流)，或者同一报文流的上下文出现震荡变化，压缩方需要重新进行压缩并执行慢启动过程，由于完整首部报文的首部长度与原始首部(未经压缩处理的)报文的首部长度是相等的，而压缩首部报文的首部长度是大大小于原始首部报文的首部长度的，因为慢启动过程中需要频繁发送完整首部报文，所以如果频繁经历慢启动过程，那么压缩效率比较低，换句话说压缩的效果比较差；慢启动过程是压缩方的单向发送过程，压缩方无法明确的了解解压缩方是否已经建立起上下文，如果报文流前面丢失过几个完整首部，则可能导致大量的报文无法进行解压缩而被丢弃。If the packet flow changes frequently (that is, new packet flows appear constantly), or the context of the same packet flow fluctuates, the compressor needs to re-compress and perform the slow start process. It is equal to the header length of the original header (uncompressed) message, and the header length of the compressed header message is much smaller than the header length of the original header message, because the complete header message needs to be sent frequently during the slow start process. Therefore, if the slow start process is frequently experienced, the compression efficiency is relatively low, in other words, the compression effect is relatively poor; the slow start process is a one-way transmission process of the compressor, and the compressor cannot clearly understand whether the decompressor has established Context, if several complete headers are lost before the packet flow, it may cause a large number of packets to be discarded because they cannot be decompressed.
发明内容Contents of the invention
本发明的目的是针对现有UDP报文首部压缩慢启动方法的缺陷，提出一种启动用户数据报协议报文首部压缩的方法，可以缩短首部压缩启动时间，减少完整首部发送个数，取得更好的首部压缩效果，并且降低对网络资源的消耗。The purpose of the present invention is to propose a kind of method that starts UDP message header compression at the defect of existing UDP message header compression slow start method, can shorten header compression start-up time, reduce the number of complete header transmissions, and obtain more Good header compression effect, and reduce the consumption of network resources.
为实现上述目的，本发明提供了一种启动用户数据报协议报文首部压缩的方法，其特征在于在慢启动过程开始后，压缩方朝解压缩方发送包含完整首部的UDP报文时，执行以下步骤：In order to achieve the above object, the invention provides a method for starting User Datagram Protocol message header compression, which is characterized in that after the slow start process starts, when the compression side sends a UDP message that includes a complete header toward the decompression side, execute The following steps:
步骤1，所述解压缩方接收所述报文，建立扩展的压缩解压缩上下文；Step 1, the decompressor receives the message, and establishes an extended compression and decompression context;
步骤2，所述解压缩方成功建立所述压缩解压缩上下文后，向所述压缩方发送包含标识的应答报文，所述标识用于确认上下文建立有效；Step 2, after the decompressor successfully establishes the compression and decompression context, send a response message containing an identifier to the compressor, and the identifier is used to confirm that the context establishment is valid;
步骤3，所述压缩方接收到所述应答报文后，修改所述扩展的压缩解压缩上下文中的标识位为表示所述压缩解压缩上下文已经确认建立的含义，并结束慢启动过程，进入稳定发送状态。Step 3: After receiving the response message, the compressing party modifies the flag in the extended compression and decompression context to indicate that the compression and decompression context has been confirmed to be established, and ends the slow start process, and enters Stable sending status.
在上述技术方案中，在所述压缩方向解压缩方发送包含完整首部的UDP报文之前，还包括以下步骤：所述压缩方判断所述UDP报文是否满足压缩条件，是则压缩方在本端保存压缩解压缩上下文，并向解压缩方发送包含完整首部的UDP报文，否则中止UDP报文慢启动过程，并结束操作。In the above technical solution, before the compressing direction sends the UDP message containing the complete header to the decompressing party, the following steps are further included: the compressing party judges whether the UDP message satisfies the compression condition, and if so, the compressing party The side saves the compression and decompression context, and sends a UDP message containing the complete header to the decompression side, otherwise the slow start process of the UDP message is terminated, and the operation ends.
判断压缩条件的操作主要有两种，一种是判断所述UDP报文是否预设为不进行压缩；另一种是判断所述UDP报文是否为IP分片报文。There are mainly two operations for judging the compression conditions, one is to judge whether the UDP packet is preset not to be compressed; the other is to judge whether the UDP packet is an IP fragmented packet.
在所述步骤3之后，所述解压缩方判断后续接收到包含完整首部的报文与已建立的压缩解压缩上下文相比是否发生改变，是则重新建立所述压缩解压缩上下文，并执行所述步骤2，否则维持稳定发送状态。如果所述压缩方在所述慢启动过程中预定长度的时间内未收到包含有效标识的应答报文时，重新进行慢启动过程；或者不对报文流进行压缩。After the step 3, the decompressor judges whether the subsequent received message containing the complete header has changed compared with the established compression and decompression context, and if so, re-establishes the compression and decompression context, and executes the Step 2 above, otherwise maintain the stable sending state. If the compressor does not receive a response message containing a valid identifier within a predetermined period of time during the slow start process, restart the slow start process; or not compress the message stream.
基于上述的技术方案，本发明具有以下优点：Based on the above-mentioned technical scheme, the present invention has the following advantages:
本发明中解压缩方在建立上下文环境后会向压缩方发回有效标识，克服了现有慢启动过程中单向发送的缺陷，降低了解压缩失败的可能；并且在压缩方收到有效标识的应答报文后，会对上下文进行标记，并直接进入稳定发送，从而大大的提高了压缩效率。In the present invention, the decompressing party will send back an effective identification to the compressing party after setting up the context environment, which overcomes the defect of one-way transmission in the existing slow start process and reduces the possibility of decompression failure; and when the compressing party receives the effective identification After the message is answered, the context will be marked and sent directly into stable transmission, which greatly improves the compression efficiency.
下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。The technical solutions of the present invention will be described in further detail below with reference to the accompanying drawings and embodiments.
附图说明Description of drawings
图1为现有技术中慢启动过程的示意图。FIG. 1 is a schematic diagram of a slow start process in the prior art.
图2为本发明启动用户数据报协议报文首部压缩的方法的基本流程示意图。FIG. 2 is a schematic flowchart of the method for starting the compression of the UDP message header in the present invention.
图3为本发明启动用户数据报协议报文首部压缩的方法的一个实施例的流程示意图。FIG. 3 is a schematic flowchart of an embodiment of a method for starting UDP message header compression according to the present invention.
图4为本发明启动用户数据报协议报文首部压缩的方法的另一个实施例的流程示意图。Fig. 4 is a schematic flowchart of another embodiment of the method for starting UDP message header compression according to the present invention.
具体实施方式Detailed ways
本发明的核心是：通过在报文流两端之间的报文中加入标识，实现了对报文首部压缩的启动过程优化，可以缩短压缩慢启动的过程，提高了上下文建立的效率。The core of the present invention is: by adding a mark in the message between the two ends of the message flow, the optimization of the starting process of message header compression is realized, the slow start process of compression can be shortened, and the efficiency of context establishment is improved.
接下来将在下面的实施例中结合附图对本发明进行进一步的描述。Next, the present invention will be further described in the following embodiments with reference to the accompanying drawings.
如图2所示，为本发明启动用户数据报协议报文首部压缩的方法的基本流程示意图，在慢启动过程开始后，先发送一个完整首部报文，然后每发送2n个压缩报文就需要发送一个完整首部报文，其中n≥0，在这个过程中，当压缩方朝解压缩方发送包含完整首部的UDP报文时，执行以下步骤：As shown in Figure 2, it is a schematic flow diagram of the basic flow of the method for starting the compression of the user datagram protocol message header of the present invention. After the slow start process starts, a complete header message is sent first, and then every time 2n compressed messages are sent. It is necessary to send a complete header message, where n≥0. In this process, when the compressor sends a UDP message containing a complete header to the decompressor, perform the following steps:
步骤101，解压缩方接收压缩方发送的UDP报文，并根据UDP报文建立压缩解压缩上下文；
步骤102，解压缩方在成功建立压缩解压缩上下文后，会向压缩方发送包含标识的应答报文，该应答报文为扩展的CONTEXT_STATE报文，格式如下表：
其中第一个字节为类型字节，用来表示这个CONTEXT_STATE报文是否是确认上下文“有效”的，具体设置的值为预先设定的，作为代表“有效”或者“无效”的标识。第二个字节的第一个比特为CID标识位，用来标识CID的位数，例如当CID标识位取1时，CID为16比特；CID标识位取0时，CID为8比特。后两个字节为CID的低字节和高字节，如果CID为8比特，则不需要CID高字节；The first byte is a type byte, which is used to indicate whether the CONTEXT_STATE message confirms that the context is "valid", and the specific set value is preset as an identifier representing "valid" or "invalid". The first bit of the second byte is the CID identification bit, which is used to identify the number of bits of the CID. For example, when the CID identification bit is 1, the CID is 16 bits; when the CID identification bit is 0, the CID is 8 bits. The last two bytes are the low byte and high byte of CID. If the CID is 8 bits, the high byte of CID is not needed;
步骤103，压缩方接收到带有“有效”标识的应答报文后，将压缩解压缩上下文标记位修改为“已确认”，然后结束慢启动过程，直接进入稳定的发送过程。本发明在常规的UDP报文首部压缩上下文表项添加“已确认标志”，用以标注压缩解压缩上下文为已确认，具体见下表。
在稳定发送过程建立后，还要考虑到上下文发生变化的情况，如图3所示，为本发明启动用户数据报协议报文首部压缩的方法的一个实施例的流程示意图，即在基本流程之后，加入了以下步骤：步骤104，如果解压缩方后续收到的包含完整首部的报文与已建立的压缩解压缩上下文相比发生了变化，则重新建立压缩解压缩上下文，然后重新执行回步骤102，向压缩方发送包含有效标识的应答报文，当压缩方接收到带有有效标识的应答报文后，将压缩解压缩上下文标记为已确认，然后结束慢启动过程，重新进入稳定的发送过程。After the stable sending process is established, the situation that the context changes will also be considered, as shown in Figure 3, it is a schematic flow diagram of an embodiment of the method for starting the user datagram protocol message header compression of the present invention, that is, after the basic flow , adding the following steps: step 104, if the message containing the complete header subsequently received by the decompressor has changed compared with the established compression and decompression context, then re-establish the compression and decompression context, and then re-execute back to the
在实际过程中，有的UDP报文并不符合压缩条件，这样的报文压缩方会识别出而不进行压缩处理的，具体的压缩条件现有技术中有详细的规定，一般有以下几种情况：如果UDP报文的IP首部带有“选项”字段，那么可以不对其进行压缩；“选项”是IP首部中一个可选的字段，而且其含义是标志该UDP报文不需要被压缩；另外，如果UDP报文是IP分片报文，那么也不对其进行压缩。IP分片报文是指当上层应用交给IP层的报文大于链路的最大传输单元(即链路一次可以发送的最大报文长度)时，IP层会将该报文分成几片进行发送。In the actual process, some UDP packets do not meet the compression conditions, and the compressor of such packets will recognize them and not perform compression processing. The specific compression conditions are stipulated in detail in the prior art. Generally, there are the following types Situation: If the IP header of the UDP message has an "option" field, it may not be compressed; "option" is an optional field in the IP header, and its meaning is to mark that the UDP message does not need to be compressed; In addition, if the UDP packet is an IP fragmented packet, it is not compressed either. IP fragmentation message means that when the message delivered by the upper layer application to the IP layer is larger than the maximum transmission unit of the link (that is, the maximum message length that the link can send at one time), the IP layer will divide the message into several pieces for processing. send.
虽然本发明将以上条件设定为压缩条件，但这并不只限定这几种压缩条件，同时对于上述两种情况，也可以设置为进行压缩。Although the present invention sets the above conditions as compression conditions, it is not limited to these compression conditions, and can also be set as compression for the above two cases.
对于IP分片报文，如果要对这种报文进行压缩，那么需要将一个连接上的分片报文和未分片的报文划分成两个报文流进行压缩处理，同样，对于一个IP首部带“选项”的UDP报文和不带“选项”的UDP报文必须划分成两个报文流进行压缩处理。For IP fragmented packets, if you want to compress such packets, you need to divide the fragmented packets and non-fragmented packets on a connection into two packet streams for compression processing. Similarly, for a UDP packets with "options" in the IP header and UDP packets without "options" must be divided into two packet streams for compression.
另外，本发明是针对UDP报文进行压缩处理，如果链路两端发送TCP报文或者仅有IP首部(称为Raw IP)的报文，这些报文也不满足压缩条件，不能被压缩。In addition, the present invention compresses UDP messages. If both ends of the link send TCP messages or only IP header (called Raw IP) messages, these messages do not meet the compression conditions and cannot be compressed.
本发明还公开了这样一个实施例，如图4所示，为本发明启动用户数据报协议报文首部压缩的方法的另一个实施例的流程示意图，在压缩方朝解压缩方发送包含完整首部的UDP报文之前，包括以下步骤：The present invention also discloses such an embodiment. As shown in FIG. 4 , it is a schematic flow chart of another embodiment of the method for starting user datagram protocol packet header compression in the present invention. Before the UDP packet, the following steps are included:
步骤201，压缩方判断该UDP报文是否满足压缩条件，是则压缩方朝解压缩方发送包含完整首部的UDP报文，并执行步骤203；否则执行步骤202；Step 201, the compressor judges whether the UDP message meets the compression conditions, if so, the compressor sends a UDP message containing a complete header to the decompressor, and executes step 203; otherwise, executes step 202;
步骤202，中止UDP报文压缩的慢启动过程，即不对进行压缩该UDP报文流进行压缩，结束操作；Step 202, stop the slow start process of UDP message compression, promptly do not compress this UDP message flow of compressing, end operation;
步骤203，解压缩方接收压缩方发送的UDP报文，并根据UDP报文建立压缩解压缩上下文；Step 203, the decompressor receives the UDP message sent by the compressor, and establishes a compression and decompression context according to the UDP message;
步骤204，解压缩方在成功建立压缩解压缩上下文后，会向压缩方发送包含标识的应答报文，该应答报文为扩展的CONTEXT_STATE报文；Step 204, after successfully establishing the compression and decompression context, the decompressor will send a response message containing the identifier to the compressor, and the response message is an extended CONTEXT_STATE message;
步骤205，压缩方接收到带有“有效”标识的应答报文后，将压缩解压缩上下文标记位修改为“已确认”，然后结束慢启动过程，直接进入稳定的发送过程。本发明在常规的UDP报文首部压缩上下文表项添加“已确认标志”。Step 205, after receiving the response message with the "valid" flag, the compressor modifies the compression and decompression context flag bit to "confirmed", then ends the slow start process, and directly enters the stable sending process. The present invention adds a "confirmed flag" to the compression context entry of the conventional UDP message header.
如果压缩方在慢启动过程中预定长度的时间内未收到所述包含有效标识的应答报文时，重新进行慢启动过程，或者中止对所述报文流进行压缩。If the compressor does not receive the response message containing the valid identifier within a predetermined period of time during the slow start process, restart the slow start process, or stop compressing the message stream.
在上述两个实施例中，解压缩方在建立上下文环境后会向压缩方发回有效标识，克服了现有慢启动过程中单向发送的缺陷，即现有方式的慢启动过程中压缩方无法获知上下文环境建立是否成功，只能重复的发送完整报文以保证成功建立；而本发明可以在解压缩方建立成功后可以立刻反馈给压缩方，因此避免了冗余的重复发送过程；而且由于压缩方获知了上下文环境的建立情况，自然降低了解压缩失败的可能。压缩方在收到标识的应答报文后，会对上下文进行标记，并直接进入稳定发送，从而大大的提高了压缩效率。In the above two embodiments, the decompressor will send back a valid identifier to the compressor after the context is established, which overcomes the defect of one-way transmission in the existing slow start process, that is, the compression party in the existing slow start process It is impossible to know whether the establishment of the context environment is successful, and the complete message can only be sent repeatedly to ensure the successful establishment; and the present invention can immediately feed back to the compressor after the decompression party is successfully established, thus avoiding redundant repeated sending process; and Since the compressor knows the establishment of the context environment, the possibility of decompression failure is naturally reduced. After the compressor receives the identified response message, it will mark the context and send it directly, thus greatly improving the compression efficiency.
最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制；尽管参照较佳实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本发明的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本发明技术方案的精神，其均应涵盖在本发明请求保护的技术方案范围当中。Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them; although the present invention has been described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that: the present invention can still be Modifications to the specific implementation of the invention or equivalent replacement of some technical features; without departing from the spirit of the technical solution of the present invention, should be included in the scope of the technical solution claimed in the present invention.
Claims (7)
Translated fromChinesePriority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB200610072688XACN100440869C (en) | 2006-04-11 | 2006-04-11 | Method for starting user datagram protocol packet header compression |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB200610072688XACN100440869C (en) | 2006-04-11 | 2006-04-11 | Method for starting user datagram protocol packet header compression |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1968190A CN1968190A (en) | 2007-05-23 |
| CN100440869Ctrue CN100440869C (en) | 2008-12-03 |
Family
ID=38076747
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB200610072688XAExpired - Fee RelatedCN100440869C (en) | 2006-04-11 | 2006-04-11 | Method for starting user datagram protocol packet header compression |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100440869C (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102420672A (en)* | 2011-01-25 | 2012-04-18 | 苏州汉明科技有限公司 | Method for transmitting data from wireless access point of wireless local area network to wireless controller |
| CN106470212B (en)* | 2016-10-13 | 2020-01-17 | 重庆金美通信有限责任公司 | Method for compressing and encrypting EIGRP protocol message based on LZW compression algorithm |
| WO2022151105A1 (en)* | 2021-01-13 | 2022-07-21 | 北京小米移动软件有限公司 | Compression processing method and apparatus |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030198250A1 (en)* | 2002-03-28 | 2003-10-23 | Rolf Hakenberg | Method, apparatus and system for transmitting compressed header data |
| CN1545783A (en)* | 2001-06-27 | 2004-11-10 | ��˹��ŵ�� | Transmission of Header Compression Identifiers on Packet Connections |
| US20050008012A1 (en)* | 2003-07-08 | 2005-01-13 | Cisco Technology, Inc. | Performing compression of user datagram protocol packets |
| CN1592272A (en)* | 2003-09-04 | 2005-03-09 | 国际商业机器公司 | Method for header compression |
| CN1602616A (en)* | 2002-08-09 | 2005-03-30 | 松下电器产业株式会社 | Header compression/decompression device and header compression/decompression method |
| CN1713614A (en)* | 2004-06-21 | 2005-12-28 | 信息产业部电信研究院 | Group message header compression in IP telecommunication network system |
- 2006
- 2006-04-11CNCNB200610072688XApatent/CN100440869C/ennot_activeExpired - Fee Related
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1545783A (en)* | 2001-06-27 | 2004-11-10 | ��˹��ŵ�� | Transmission of Header Compression Identifiers on Packet Connections |
| US20030198250A1 (en)* | 2002-03-28 | 2003-10-23 | Rolf Hakenberg | Method, apparatus and system for transmitting compressed header data |
| CN1602616A (en)* | 2002-08-09 | 2005-03-30 | 松下电器产业株式会社 | Header compression/decompression device and header compression/decompression method |
| US20050008012A1 (en)* | 2003-07-08 | 2005-01-13 | Cisco Technology, Inc. | Performing compression of user datagram protocol packets |
| CN1592272A (en)* | 2003-09-04 | 2005-03-09 | 国际商业机器公司 | Method for header compression |
| CN1713614A (en)* | 2004-06-21 | 2005-12-28 | 信息产业部电信研究院 | Group message header compression in IP telecommunication network system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1968190A (en) | 2007-05-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100496041C (en) | Method for defining context identifiers, compression system, network element and mobile station | |
| US7286536B2 (en) | Method and system for early header compression | |
| JP4763682B2 (en) | Providing information on upper layer packet or frame boundary in GRE frame | |
| US7430617B2 (en) | Method and system for header compression | |
| TWI342678B (en) | Message compression methods and apparatus | |
| US7512716B2 (en) | Header compression method | |
| WO2013167013A2 (en) | Compression and decompression method of ethernet header and device of same | |
| WO2010020197A1 (en) | Data transmission method, communication equipment and communication system | |
| WO2011160495A1 (en) | Feedback method and device for header compression feedback information | |
| CN101146025A (en) | Compressed real-time transport protocol message transmission method and system and compression end unit | |
| CN100446514C (en) | Method and device for transmitting data packets in packet stream | |
| CN100433841C (en) | Robustness header compression/decompression method for MIPv6 | |
| KR20090084864A (en) | Message compression | |
| CN100440869C (en) | Method for starting user datagram protocol packet header compression | |
| CN102118792A (en) | Method and device for transmitting data packets | |
| CN101534291A (en) | Method for sending and receiving IP message and device thereof | |
| JP2006513640A (en) | Method and apparatus for compressing header information in short data burst messaging | |
| CN100454900C (en) | Method and system for quickly responding to IP fragmentation packets | |
| CN100433724C (en) | Method and equipment of ageing treatment for header compressed list items of context in Internet protocol | |
| US20040034826A1 (en) | Transport protocol checksum recalculation | |
| CN101197825B (en) | Method, system and device for compression message transmission | |
| CN102638391B (en) | Method and equipment for transmission of frame relay compressed messages | |
| CN101102263B (en) | Method and device for recovering compressed message | |
| US20050086383A1 (en) | Optimizing the compression efficiency in a packet data communication | |
| CN101415003B (en) | Method, apparatus and communication system for transmission of compression message |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | Effective date of registration:20170921 Address after:151400, No. 3, No. 13, 27 Committee, anda rainbow Street, anda, Heilongjiang, Suihua Patentee after:Qin Xiuyu Address before:518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before:Huawei Technologies Co., Ltd. | |
| TR01 | Transfer of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee | Granted publication date:20081203 Termination date:20180411 | |
| CF01 | Termination of patent right due to non-payment of annual fee |