+

WO2002029991A1 - Encapsulation de paquets groupes et systeme et procede de compression - Google Patents

Encapsulation de paquets groupes et systeme et procede de compression Download PDF

Info

Publication number
WO2002029991A1
WO2002029991A1 PCT/US2001/031086 US0131086W WO0229991A1 WO 2002029991 A1 WO2002029991 A1 WO 2002029991A1 US 0131086 W US0131086 W US 0131086W WO 0229991 A1 WO0229991 A1 WO 0229991A1
Authority
WO
WIPO (PCT)
Prior art keywords
packets
packet
encapsulation
header
node
Prior art date
Application number
PCT/US2001/031086
Other languages
English (en)
Inventor
Zezhen Huang
Original Assignee
Provisionpoint Communications, Llc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US09/789,852 external-priority patent/US6618397B1/en
Application filed by Provisionpoint Communications, Llc filed Critical Provisionpoint Communications, Llc
Priority to AU2001296586A priority Critical patent/AU2001296586A1/en
Publication of WO2002029991A1 publication Critical patent/WO2002029991A1/fr

Links

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/04—Protocols for data compression, e.g. ROHC
    • 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

Definitions

  • the present invention generally relates to the field of electronic communications. More specifically, the present invention relates to communication protocol systems and methods used in such electronic communications.
  • IP Internet protocol
  • FIG. 1 shows an open system interconnect (OSI) model 100 that depicts the different layers of processing involved in IP data communication within a gateway or host computer.
  • the model 100 includes application 102, presentation 104, session 106, transport 108, network 110, data link 112, and physical 114 layers.
  • Each layer understands a certain communication protocol, which among other things contains a specific packet format.
  • Each layer also employs a standard method of encapsulating and de-encapsulating packets received from upper and lower layers.
  • When a layer receives a packet of data from an upper layer that layer encapsulates the packet into a new packet conforming to the packet format the layer understands.
  • the layer then passes the new packet to the next lower layer.
  • the receiving layer retrieves (i.e., deencapsulates) the encapsulated inner packet and passes it to the next upper layer.
  • FIG. 2 shows a group of diagrams 200 that illustrate encapsulation at various layers of model 100 as an example of UDP/IP over Ethernet, i.e., from the transport layer 108 to the network layer 110 and then to the data link layer 112.
  • a UDP packet 220 includes a UDP header 202 and data 210.
  • the IP packet 230 includes the UDP packet 220 and an IP header 204.
  • the IP packet 230 is encapsulated in an Ethernet header 206 and trailer 208, as an Ethernet frame 240.
  • the Ethernet frame 240 is transmitted to a physical network connection. It can be seen from FIG. 1 and FIG.
  • Ethernet header 206 and trailer 208 together add 26 bytes. That is, for each IP packet transmitted, there will be 26 bytes of overhead in Ethernet 5 framing.
  • FIG. 3 illustrates an example of prior art data communication between nodes, e.g., gateway/host A 310 and gateway/host D 340, which includes transit through gateway B 320 and gateway C 330.
  • the data-link layer technologies employed by each connection may be different.
  • the direction of data communication is from gateway/host A 0 310 to gateway/host D 340.
  • the gateway For each frame of data received in a gateway (e.g., gateway 320 or 330), the gateway needs to determine (referred to as routing) which gateway in the next hop to send the data, and may need to retrieve the IP packet from the frame and encapsulate the IP packet in a different data-link framing technology before relaying it to the next hop gateway.
  • routing referred to as routing
  • Such processing consumes computing power and memory and causes transmission delay. If data 5 traffic is heavy in a gateway, the gateway may not be able to transmit the data as fast as it is received and network congestion and delays result due to excess contention for limited gateway resource and bandwidth.
  • IP header compression is a prior art technique that can reduce a packet's size and result in more efficient packet transportation.
  • IP header o compression There are some Internet standard methods for IP header o compression, such as IP/TCP header compression (RFC 1144) and IP/UDP/RTP header compression (RFC 2508).
  • Header compression relies on many fields in the header being constant or changing seldomly in consecutive packets belonging to the same packet stream. Fields that do not change between packets need not be transmitted at all.
  • a full header carrying a context identifier (CID) is transmitted over the link. 5
  • the compressor and decompressor store most fields of this full header in a context structure and the CID to be associated with the context structure.
  • the context structure comprises the fields of the header whose values are constant and thus need not be sent over the link at all, or change little between consecutive headers so that it uses fewer bits to send the difference from the previous value compared to sending the absolute value.
  • the compressor can then compress packet headers by computing the difference between the headers and the initial values stored in the context structure and encoding only the non-zero values of the difference.
  • the decompressor retrieves the context structure using the CID and decompresses the compressed header. Header compression is most effective for small packets where the overhead header is significant.
  • IP header compression The problem with IP header compression is that, the compressed packet is no longer a standard IP packet and it depends on the data-link layer to carry the compression information such that the receiving node can decompress the header and recover the original packet. This requires that the receiving node must 5 have a data-linlc layer direct comiection with the sending node. Therefore, IP header compression has been applied only on a link-by-link basis. In today's public Internet, packet may traverse over many intermediate routers before reaching the receiving node. As shown in FIG. 3, packets originated from Node A 310 traverse over Node B 320 and Node C 330 before reaching Node D 340. Therefore, IP header compression cannot be applied just between Node A 310 and Node D o 340.
  • IP payload compression is another prior art technique for improving packet transportation efficiency
  • IPComp is an Internet standard method (RFC-2393).
  • IPComp reduces the size of IP payload before passing the IP packet to the data-link layer, and therefore increases the overall communication performance between a pair of communicating hosts/gateways 5 ("nodes").
  • the PComp protocol operates at the network layer 110 in the OSI model 100, illustrated in FIG. 1.
  • the compression processing of IP packets has two phases: compressing of outbound IP packets ("compression”) and decompressing of inbound IP packets (“decompression”).
  • compression processing must be loss-less, ensuring that the IP packet, after being compressed o and decompressed, is identical to the original IP packet. Additionally, the compression processing must enforce a non-expansion policy, that is, if the compressed packet is larger than the original packet, the original packet will be transmitted.
  • the data link layer typically imposes a maximum transmission unit (MTU).
  • MTU maximum transmission unit
  • the Ethernet has a MTU of 1500 bytes.
  • the non-expansion policy ensures the packet would not 5 exceed the MTU, which would cause packet fragmentation and result in increased overhead.
  • Each IP packet is compressed and decompressed by itself without any relation to other packets ("stateless compression"), as IP packets may arrive out of order or not arrive at all.
  • Each compressed IP packet encapsulates a single IP payload.
  • IP packet 400 is shown in prior art FIG. 4A.
  • IP packet 400 is shown in a o compressed form 420 in FIG. 4B, in accordance with the prior art protocol IPComp.
  • the compressed IP packet 420 contains a modified IP header 422, an IPComp header 424, and compressed payload data 426.
  • the payload data 426 may be compressed using any known lossless compression algorithm.
  • the modified (indicated by the asterisk) IP header 422 shown in FIG. 4B contains a new protocol identification, which is used by the remote node to identify the packet as an IPComp compressed packet.
  • the modified IP header 422 also contains new value of total length and header checksum for the compressed IP packet 420.
  • an IPComp header 450 consists of four-octets, 0 through 3 (i.e., 4 bytes), where the field 452 stores an IP (v.4) protocol field or an IP (v.6) Next Header field of the original IP header; the "Flags" fields 454 is typically reserved and set to zero; the "Compression Parameter Index” (CPI) field 456 identifies the compression algorithm used. The remote node receiving the compressed IP packet will choose the correct decompression algorithm according to CPI 456.
  • CA compression association
  • IPComp requires each IP packet to be compressed individually without any relation to other packets. This requirement limits the ability to compress IP data, so a certain amount of inefficiency generally has been tolerated, as being unavoidable.
  • the invention is a system and method for group packet encapsulation and (optionally) compression.
  • the system and method increase packet transmission performance between two gateways or host computers by reducing data-link layer framing overhead, reducing packet routing overhead in gateways, reducing packet header overhead, and increasing loss-less data compression ratio beyond that otherwise achievable with standard protocols, such as IPComp.
  • IPComp IPcomp protocol
  • the system and method implement an encapsulation protocol of the present invention, which, as an example, can be used with IP packets, as a group IP packet encapsulation and (optionally) compression (GIEC) system and method.
  • GIEC group IP packet encapsulation and (optionally) compression
  • a communication device may accumulate multiple packets in its internal queue before passing them to the data link layer.
  • the packet accumulation could be the result of, as examples, a TCP/UDP protocol sending multiple packets at the same time, network congestion blocking packets in queue, multiple TCP/UDP flows transmitting simultaneously between two nodes (e.g., gateways/hosts) or some combination thereof.
  • two communication nodes e.g., a Node-X and a Node-Y
  • a node could be a gateway, host computer or some other known communication device.
  • Node-X and Node-Y may be configured with modules that implement the system, method, and protocol of the present invention.
  • Node-X establishes a protocol association for Node-Y.
  • a protocol association for Node-X includes an address map.
  • the address map comprises a list of 5 addresses of nodes for which packets transmitted from Node-X can pass through to get to Node- Y.
  • An address for a node could be an address for an end system or a subnet address representing a sub-network, as examples.
  • Node-Y can establish a protocol association for Node-X. For packets being transmitted from Node-X to Node-Y, only one protocol association is required. 0 hi accordance with the present invention, when Node-X is preparing to transmit packets,
  • Node-X determines which of those packets has a destination address that matches an address in the address map.
  • the packets are grouped according to having a common destination or intermediate node in their path.
  • Node-X dynamically combines the group of packets into one encapsulation packet with one 5 encapsulation packet header and one encapsulation payload.
  • the encapsulation payload contains the original packet headers and payloads.
  • Node-X may optionally compress at least a portion of the original packet headers and/or payloads in the encapsulation payload, according to known compression techniques.
  • the encapsulation packet header contains a special protocol identifier referred to as an encapsulation packet protocol ID.
  • Node-X transmits the encapsulation packet o to, in this example, Node-Y.
  • the encapsulation packet protocol ID (or other information encoded in the encapsulation packet) is used by Node-Y to identify the received packet as an encapsulation packet in accordance with the present invention.
  • Node-Y retrieves the encapsulation payload, decompresses the payload, if it has been compressed, and then de-encapsulates the encapsulation payload.
  • Node- 5 Y After de-encapsulating, Node- 5 Y recovers the original group of packets and forwards them to the appropriate gateways or end systems. That is, for those packets for which Node-Y is not the ultimate destination, the packets are sent on to their destinations from Node-Y.
  • the system and method of the present invention improves transmission performance in a variety of manners. For example, data link o framing overhead is reduced, which results in reduced bandwidth consumption. That is, instead of incurring n framing overheads for n packets, by encapsulating these n packets into one packet, there will be only one framing overhead. Additionally, packet routing overhead in gateways is reduced. Instead of incurring n overheads in routing n packets, by encapsulating these n packets into one encapsulation packet, there is one overhead, as if routing only one packet.
  • IP header compression can be applied on IP packets contained in the encapsulation payload without requiring Node-X and Node-Y to have a direct data-link connection. Also, if compression is applied in IP payloads contained in the encapsulation payload, the set of data that 5 comprise these payloads can be compressed together, rather than compressing each IP packet payload individually, as is done in the prior art systems. As a result, the compression ratio may be increased, because more data are compressed together within a single packet, resulting in reduced bandwidth consumption.
  • the encapsulation protocol may further employ an intelligent adaptive algorithm (IAA) to 0 prevent the encapsulated and (optionally) compressed packet from exceeding the MTU.
  • IAA intelligent adaptive algorithm
  • the IAA at a macro level, includes at least two steps.
  • the compression ratio is defined as 5 the size of buffer before compression divided by the size of buffer after compression.
  • the compression ratio can be estimated from compression ratios obtained from the previous packets.
  • the compression ratio can also be continuously updated as an average, over a chosen window of time. If no compression is applied, the compression ratio can be set to 1, referred to as "null" compression.
  • the encapsulation protocol is backward compatible with known protocols, such as IPComp. That is, the system and method of the present invention may employ a protocol 5 ID that is adapted from a protocol ID otherwise assigned to a known protocol (e.g., IPComp).
  • IPComp a protocol ID otherwise assigned to a known protocol
  • the encapsulation protocol employs special values in the CPI for identifying, as an encapsulation protocol, a known protocol.
  • a standard IPComp header contains a 16-bit CPI that identifies a compression algorithm.
  • the known IPComp standard defined in RFC-2393, allocates CPI values 0-63 for well-known compression algorithms and allocates o values 61440-65535 for private use among cooperating parties.
  • the encapsulation protocol may designate a value range, in the unassigned value range of 61440- 65535, to identify the encapsulation protocol.
  • CPI values in this range may be referred to as encapsulation CPI values.
  • Different D values may designate different encapsulation schemes, while the values in the range may designate different payload compression algorithms.
  • An encapsulation scheme specifies the format with which multiple IP packets are encapsulated into one IP packet.
  • the encapsulation scheme may insert a header compression (HC) header before each packet header contained in the encapsulation packet.
  • HC header compression
  • the HC header may contain one or more bytes that comprise information of header compression scheme ID, encoding scheme ID, size of the following header, and context identifier (CID).
  • Header compression schemes specify types of header compression such as Null-header- compression, IP -TCP header compression, IP -UDP header compression, and EP-UDP-RTP compression, etc.
  • Null-header-compression indicates that the following header is not compressed, which allows selective header compression in one encapsulation packet.
  • Encoding schemes specify encoding algorithms used for encoding compressed headers. If an implementation will support only one encoding scheme for each header compression scheme, it is not necessary for the HC header to include an encoding scheme ID.
  • a specific encapsulation scheme may also indicate whether any header compression has been applied or not, and therefore whether a HC header has been inserted before each packet header or not in the encapsulation packet.
  • header and/or payload compression can be optional.
  • Group packet encapsulation even without compression, significantly increases communication performance in most cases, especially when each encapsulated packet is short.
  • Group packet encapsulation reduces the overheads associated with data link layer framing and with packet routing. Therefore, unlike the IPComp protocol, as an example, the encapsulation protocol of the present invention can be applied to payload data that is not compressible, such as speech and video data in voice and video over IP communications.
  • Group packet encapsulation combining with header and/or payload compression can further reduce the encapsulation packet size and therefore achieve higher performance.
  • Null payload compression means that packet payloads contained in the encapsulation packet are not compressed.
  • the same encapsulation protocol can also support optional packet 5 header compression by using special encapsulation scheme IDs (i.e., D values) to designate null header compression.
  • "Null header compression” means that packet headers contained in the encapsulation packet are not compressed.
  • the system and method of the present invention need not use or be backward compatible with the IPComp protocol.
  • IPComp IPComp protocol
  • 0 compatibility with other protocols may be favored and implemented in addition to or instead of IPComp, as will be appreciated by those skilled in the art.
  • FIG. 1 is a prior art figure of an OSI model
  • FIG. 4A is a diagram depicting a prior art IP packet and FIG. 4B is a prior art diagram depicting the IP packet of FIG. 4A in compressed form in accordance to IPComp;
  • FIG. 4C is a prior art diagram depicting an IPComp header used in the compressed IP 5 packet of FIG. 4B;
  • FIG. 5 A is a block diagram of GIEC modules in accordance with one embodiment of the present invention and FIG. 5B is a method implemented by the GIEC modules of FIG. 5 A;
  • FIG. 6 is a block diagram depicting GIEC protocol associations made at nodes that implement the modules of FIG. 5 A and the method of FIG. 5B; o FIG. 7A (prior art), 7B (prior art), 7C (prior art), 7D, 7E, and 7F are diagrams depicting various GIEC encapsulation schemes implemented by the modules of FIG. 5 A and the method of FIG. 5B; and
  • FIG. 8A and 8B are diagrams depicting HC header formats used for packet header compression for GIEC packets in accordance with the present invention. For the most part, and as will be apparent when referring to the figures, when an item is used unchanged in more than one figure, it is identified by the same alphanumeric reference indicator in the various figures in which it is presented.
  • the invention is a system and method for group packet encapsulation and (optionally) compression.
  • the system and method increase packet transmission performance between two nodes (e.g., gateways or host computers) by reducing data-link layer framing overhead, reducing packet routing overhead, allowing packet header compression without direct data link connection 0 and increasing loss-less payload compression ratio beyond that otherwise achievable with prior art protocols.
  • the packets are IP packets and the system and method are a group IP encapsulation and (optionally) compression (GIEC) system and method implementing a GIEC encapsulation protocol that is optionally compatible with IPComp protocol.
  • GIEC group IP encapsulation and (optionally) compression
  • the GIEC system and method employ the IPComp protocol, as one possible payload compression method for IP packets.
  • an IP communication device can accumulate multiple IP packets in its internal queue before passing them to the data link layer of the OSI model 100 of FIG. 1.
  • the packet accumulation could be the result of, as examples, the TCP UDP protocol sending multiple o packets at the same time, network congestion blocking packets in queue, multiple TCP/UDP flows transmitting simultaneously between two routers, gateways, hosts, or some combination thereof.
  • the GIEC system includes GIEC functionality that maybe implemented in software, firmware, hardware, or some combination thereof.
  • GIEC functionality 5 is preferably implemented on a plurality of networked communication devices or nodes.
  • a node may be any device capable of generating, transmitting, and/or receiving electronic messages, such as a personal computer (PC), personal digital assistant (PDA), cell phone, e-mail device, pager, Web or network enabled television or appliance, server, gateway, host, router or other such devices.
  • the devices may be networked together over one or more of a plurality of types of o networks, such as the Internet, world wide web (Web), intranet, extranet, private network , virtual private network, local area network (LAN), wide area network (WAN), telephone network, cable network, or some combination thereof.
  • PC personal computer
  • PDA personal digital assistant
  • the devices may be networked together over one or more of a plurality of types of o networks, such as the Internet, world wide web (Web), intranet, extranet, private network , virtual private network, local area network (LAN), wide area network (WAN), telephone network, cable network, or some combination thereof.
  • Web world wide web
  • intranet intranet
  • extranet private network
  • LAN local area
  • the GIEC functionality is implemented as a group of GIEC modules 530, shown in FIG. 5 A, that maybe hosted on any of the aforementioned types of nodes to implement the method depicted in flowchart 550 of FIG. 5B.
  • the GIEC modules 530 are hosted on a node 500 that includes known communication software 510 configured for conducting the transmission and reception of messages over a network, having a network interface generally depicted by double arrow 512.
  • Database (DB) 520 may hold packets and related information and 5 executable files associated with modules 530.
  • step 552 at a given GIEC node, e.g., Node-X 602 of FIG. 6, packets in queue for transmission are analyzed by packet analyzer & grouper 532 of FIG. 5A and a set of those packets are classified according to a determination that the packets in the set have a common GIEC destination node, e.g., Node-Y 604, in their path. 0
  • the set of packets going to the GIEC destination node are grouped together and within the group the packets are sequenced, in step 554. Sequencing may be accomplished by any of a variety of manners, such as, for example, a first-in-first-out sequence.
  • the packets in a group are addressed for the same ultimate destination (e.g., the receiving GIEC node or some other non-GIEC node), but rather that a common GIEC node is in 5 the path of the packets in the group, as a GIEC receiving node, regardless of the ultimate destination of those packets.
  • the packets are combined into an encapsulation GIEC packet by encapsulation module 534.
  • encapsulation schemes Some of which are described in more detail with respect to 0 FIGs. 7A, 7B, 7C, 7D, 7E, and 7F.
  • h step 558 optionally, the packet headers, payloads, or both are selectively compressed by compression module 536. Whether compressed or not, a GIEC header (e.g., an IP header with protocol ID identifying GIEC) is added to the encapsulation GIEC packet, in step 560. At some point after determination of the set of packets, an intelligent adaptive algorithm (IAA) module 538 may be used to ensure that the size of the GIEC packet is 5 . not greater than the MTU of the communications path.
  • the GIEC packet is transmitted via communication module 510 of FIG. 5A to a destination GIEC node (e.g., Node-Y 604), in step 562.
  • a destination GIEC node e.g., Node-Y 604
  • the GIEC packet is received by the destination GIEC node, in step 564, and de-compressed if necessary, in step 566. h step 568, the GIEC packet is de-encapsulated. The original group of packets is reconstructed and the packets are ungrouped, in step 570. If the GIEC destination o node is not the ultimate destination for a packet, the packet is then forwarded along a path to its ultimate destination, in step 572.
  • FIG. 6 provides an exemplary block diagram 600 of several nodes configured to communicate across a network.
  • a Node-L 612 and a Node-M 614 are coupled to GIEC Node-X 602.
  • a Node-1616 and a Node-J 618 are coupled to GIEC Node-Y 604, wherein Node-X 602 and Node-Y 604 are coupled together, h the preferred embodiment, each of the GIEC Nodes-X and Y includes the GIEC modules 530 of FIG. 5A.
  • Node-X 602 includes an address map 622, which may be stored in DB 520. Address map 622 comprises a list of addresses corresponding to devices or nodes to which Node-X can exchange message 5 traffic.
  • Node-Y 604 also includes an address map 624 that comprises a list of addresses corresponding to devices or nodes to which Node-Y can exchange message traffic.
  • An address map is used to facilitate and enable communications among nodes listed in the map.
  • address map 622 for Node-X among other possible addresses, includes an Address-X for Node-X 602, an Address-L for Node-L 612, and an 0 Address-M for Node-M 614.
  • An address map for Node-Y 604 includes, among other possible addresses, an Address-Y for Node-Y 604, an Address-I for Node-I 616, and an Address- J for Node-J 608.
  • Each GIEC node also includes, for each other GIEC node with which it is configured to communicate, a GIEC (protocol) association file.
  • the GIEC association file includes 5 information that facilitates and enables communication between GIEC nodes and, ultimately, to the non-GIEC nodes to which the GIEC nodes are coupled. Accordingly, in FIG. 6, Node-X 602 includes a GIEC association file 626 that includes the address map 624 of Node-Y. Similarly, Node-Y 604 includes a GIEC association file 628 that includes the address map 622 of Node-X 602.
  • a GIEC protocol association may include the encapsulation scheme IDs. If packet header compression is to be applied between two GIEC nodes, a GIEC protocol association may also include header compression scheme IDs and their associated header context structures and context identifiers (CID). If packet payload compression is to be applied between two GIEC nodes, a GIEC protocol association may also include compression algorithm IDs, which in the 5 preferred embodiment are encoded into a GIEC CPI value, such as a CPI value 456 of a standard IPComp header, for example, as is shown in FIG. 4C.
  • a GIEC protocol association can be established in any of a variety of manners. For example, a GIEC protocol association can be manually entered (e.g., by keyboard) with an address map of a remote communication node into an electronic device (e.g., Node-X 602), along o with any other relevant optional parameters. As another example, a GIEC protocol association can be established automatically, by employing broadcasting or multicasting protocols, or client- server based database look up methods. A GIEC protocol association can also be updated dynamically between the two communication nodes. For example, when packet header compression is applied, new context structures corresponding to new packet streams may be created dynamically and synchronized between the two communication nodes and saved in a GIEC protocol association. While the GIEC protocol is not known in the art, such protocol association methods are generally known in the art, so are not discussed in detail herein.
  • GIEC protocol association 626 for Node-Y 604 has been established on Node-X 602. hi this example, the GIEC protocol association 626 also includes encapsulation scheme IDs, header compression scheme IDs and their associated context structures and CIDs, and payload compression algorithm IDs. In any event, for each pair of GIEC nodes, the supported header compression schemes and payload 0 compression algorithms must be agreed upon in order for the compression and decompression to be successfully implemented by the nodes.
  • Node-X 602 must use a compression algorithm that is accommodated by Node-Y, so that Node-Y can decompress the packets sent by Node-X.
  • compression module 536 of FIG. 5 A compresses the encapsulation (or the plain) IP packet according to a known header compression scheme and/or o payload compression algorithm. If payload compression has been performed with a compression algorithm identifier, denoted as "C-ID", the CPI value of the IPComp protocol header (see FIG. 4C) is set to (61440+D*100+C-ID) if it's an encapsulation GIEC IP packet or it is set to CID if it's a plain IP packet. If no payload compression is applied, the CPI value is set to the GIEC null compression CPI value (61540+D*100-1).
  • the encapsulation 5 scheme inserts a HC (header compression) header before each compressed or uncompressed packet header.
  • the HC header comprises a header compression scheme ID, size of the following header, and CID identifying the context structure used in compression.
  • the header compression scheme ID indicates what type of header and whether the header has been compressed or not. If the header is not compressed, the HC header may not comprise the CID. More detail description o about HC header will be discussed according to FIGs. 8A and 8B.
  • Payload compression can also be done selectively on portions of the IP packet sequence to be encapsulated. For example, if encoded speech packets and keyboard message packets are encapsulated together, the keyboard message packets can be compressed while encoded speech packets may not be compressible.
  • the selective payload compression can be done before encapsulation or after encapsulation, and it may require special encapsulation scheme to accommodate the information.
  • Node-X 602 has transmitted a GIEC IP packet to Node-Y 604, which is received by communication transmit and receive module 510 via interface 512 at Node-Y 604 and passed to the packet analyzer and grouper 532 for further GIEC processing.
  • the IP header contains a GIEC protocol identifier, it is a GIEC protocol processed IP packet.
  • the GIEC protocol employs the IPComp protocol and the GIEC protocol identifier uses the same IPComp protocol identifier that has been assigned the value of 108 by the Internet Standard Organization (ISO). The CPI value is retrieved from the IPComp header.
  • the packet is a regular IPComp packet, and no packet encapsulation or header compression has been applied and the payload compression algorithm ID (C-ID) is the CPI value.
  • the CPI value is a GIEC CPI value in the range of (61440+D*100)-(61540+D*100-1)
  • D 0,1...
  • the encapsulation scheme ID value D and the payload compression algorithm identifier C-ID can be retrieved easily.
  • the encapsulation scheme ID specifies the packet encapsulation fo ⁇ nat and whether or not header compression has been applied to any inner packet header.
  • the compressed payload is decompressed by compression module 536 using the corresponding decompression algorithm designated by the C-ID. If the C_ID is a null payload compression ID, payload decompression is not necessary. If the CPI is a GIEC CPI value and the encapsulation scheme ID value (D) indicates header compression has been applied, each of the compressed headers in the encapsulation packet will be decompressed by compression module 536. After decompression, encapsulation module 534 de-encapsulates the decompressed GIEC IP packet, and recovers the original IP packet sequence. It should be emphasized here that other protocol designs employing known protocol compression can be used by the GIEC protocol, and the identification of a GIEC packet may be based on other information embedded in a GIEC IP packet.
  • a packet encapsulation scheme defines the fo ⁇ nat for the encapsulation of packets into a
  • FIG. 7A shows different components of an IP packet 700.
  • An IP packet 700 comprises an IP header 712 and an IP payload 713.
  • the IP payload 713 comprises upper layer protocol header (U header) 714 and payload 715.
  • the U header 714 for example, 5 could be a TCP header, UDP header, or UDP/RTP header.
  • the IP header 712 and the U header 714 together are referred to as header 716.
  • Assume there are a plurality of IP packets in queue at Node-X 602, designated as IP-1, IP -2, ... JP-n. Also, within this plurality of IP packets, let there be a set, sequence or subsequence of outgoing IP packets in queue at Node-X 602, designated as IP-1, IP -2, ... IP-k where k ⁇ n.
  • Each packet in the set, sequence, or subsequence has a 0 destination IP address that corresponds to an address in address map 624 contained in the GIEC protocol association 626 for Node-Y 604.
  • the set, sequence, or subsequence of packets e.g., IP-1, LP-2, ..., IP-k, is designated for encapsulation into one GIEC packet.
  • the grouped set, sequence, or subsequence of packets (i.e., IP-1, IP -2, ..., IP-k), as the case maybe, is encapsulated by the encapsulation module 534 of FIG. 5 A into one GIEC packet 5 to be transmitted to the destination GIEC node.
  • FIGs. 7B, 7C, 7D, 7E, and 7F demonstrate various encapsulation schemes of encapsulating a packet sequence 720 into a single GIEC IP packet.
  • FIG. 7B shows the packet sequence 720, including IP packets: IP packet- 1, IP packet- 2... IP packet-k.
  • FIG. 7B shows the packet sequence 720, including IP packets: IP packet- 1, IP packet- 2... IP packet-k.
  • FIG. 7C shows the same sequence 720 where each packet is shown to include two components, i.e., a header 731 and a payload 732, for example.
  • FIGs. 7D, 7E, and 7F show o three encapsulation schemes for encapsulating the packet sequence 720 into a GIEC IP packet, in accordance with the present invention.
  • FIG. 7D illustrates an encapsulation scheme A as one form of GIEC IP packet780, wherein the IP packet sequence 720 of FIG. 7B has been encapsulated.
  • Encapsulation scheme A supports payload compression.
  • the GIEC IP packet 780 is sent from Node-X 602 to Node-Y 5 604.
  • the GIEC IP Header 741 is an IP header with total length, checksum, etc. derived from the IP encapsulation payload 790.
  • GIEC IP Header 741 includes the address of Node-X 602 as a source address, and the address of Node-Y 604 as destination address.
  • the GIEC IP packet 780 comprises the IP packet sequence 720 in the payload that can be further compressed with compression algorithm ID encoded in the IPComp header 742.
  • FIG.7E illustrates an o encapsulation scheme B as fonn of a GIEC IP packet 782, wherein the IP packet sequence 720 of
  • FIG.7B has been encapsulated.
  • Encapsulation scheme B supports both payload compression and header compression.
  • the GIEC IP packet 782 is sent from Node-X 602 to Node-Y 604.
  • the GIEC IP Header 750 is an IP header with total length, checksum, etc. derived from the GIEC IP encapsulation payload 792.
  • GIEC IP Header 750 comprises the address of Node-X 602 as source address and the address of Node-Y 604 as destination address.
  • the GIEC IP packet 782 comprises the EP packet sequence 720 in the payload with packet headers 731, 733, and 735 and payloads 732, 734, and 736 separated in different parts of the payload. A one-byte "No.
  • GIEC IP packet sequence 720 is inserted after the IPComp header 752 to help Node-Y 604 easily de-encapsulate the GIEC IP packet.
  • a header compression (HC) header (756, 758, and 760) is inserted before each compressed header (731, 733, and 735). Encapsulated payloads 732, 734, and 736 can be compressed independently.
  • the HC headers (756, 758, and 760) comprise information that allows Node-Y 604 to decompress each compressed header and recover the original header (731, 733, and 735).
  • FIG. 8 A shows an exemplary composition of a HC header 800, such as the HC headers of
  • HC header 800 comprises an "header compression scheme ID” field 802, "header size” field 804, "CID (context ID)” field 806, and "encoding scheme” field 808.
  • the "header compression scheme ID” 802 specifies the compression scheme used in header compression. For example, header compression schemes may implement IP_NULL for no header compression, IP_TCP for IP/TCP header compression, IPJUDP for IP/UDP header compression, and
  • IP_UDP_RTP for IP/UDP/RTP header compression.
  • the header size field 804 specifies the compressed or uncompressed header size and the CID field 806 specifies the identifier of the context structure on which the header compression is based. If the header compression scheme is IP_NULL (i.e., no compression), the CID field 806 can be empty or does not exist.
  • the encoding scheme field 808 specifies the encoding method used in representing the following compressed header. Typically, there is one encoding scheme for each header compression scheme, and therefore the encoding scheme field 808 is not required, as shown in FIG. 8B.
  • Node-X 602 When Node-X 602 is to compress a packet header, it searches a context structure matching the packet header, compresses the packet header using the context structure, and encodes the CID associated with the context structure in the HC header inserted before the compressed header.
  • Node-Y 604 When Node-Y 604 is to decompress a compressed packet header, it retrieves the context structure using the CID encoded in the HC header inserted before the compressed packet header, and decompresses the packet header using the context structure.
  • FIG. 7F illustrates encapsulation scheme C as one form of a GIEC IP packet 784, wherein the IP packet sequence 720 of FIG.7B has been encapsulated.
  • the IP packet sequence 720 of FIG.7B has been encapsulated.
  • GIEC IP header** 762 is derived from the IP header of IP packet- 1 722 (see FIG. 7B) to eliminate one extra IP header added in the encapsulation.
  • the original source address 770 and destination address 768 of the IP packet-1 722 header may be replaced with the address of Node- X 602 and address of Node-Y 604, respectively.
  • the original source address 770 and destination address 768 of the IP packet- 1 722 header may also be saved in the encapsulation payload 794 such that the IP packet- 1 722 header can be reconstructed by Node-Y 604.
  • the GIEC IP header 762 also replaces other fields such as checksum, total length, and protocol ID in the IP packet- 1 722 header.
  • the protocol ID in the IP packet- 1 722 header is saved in the "Next header" 452 in the IPComp header 450 as shown in FIG. 4C.
  • the total length of the IP packet-1 722 header is saved in 766 as part of the encapsulation payload.
  • the encapsulation payload can be further compressed.
  • Encapsulation scheme C does not show header compression. However, encapsulation scheme C can be revised to include header compression in accordance with the present invention, as would be appreciated by those skilled in the art. 0
  • GIEC packet Prior to being transmitted from a first GIEC node to a second GIEC node, when a set, sequence, or subsequence of packets is encapsulated into a GIEC packet, it is desirable that the number of packets in the sequence be limited such that the resultant GIEC packet does not 5 exceed the MTU; exceeding the MTU would cause packet fragmentation. If there is no header compression or payload compression applied, the total length of the GIEC packet can be easily determined for a given encapsulation scheme and a given sequence of packets to be encapsulated and, therefore, the maximum number of packets in the sequence to be encapsulated can be easily determined.
  • the total length of o the GIEC packet cannot be determined before compression has been performed. Therefore, the limit on the number of packets in the sequence to be encapsulated cannot be easily determined.
  • the total length of the GIEC packet can be estimated based on compression ratios estimated from the compression results for previous sequences of packets. For sequences of packets that belong to the same packet stream or similar streams where packets contain similar 5 characteristics and compressibility, compression ratios from sequence to sequence are ususally consistent and the estimated compression ratios would be more accurate.
  • the IAA module 538 of FIG. 5A is an optional o module performing this functionality.
  • the IAA module 538 estimates the allowed maximum length of the GIEC packet before any compression is performed, based on the estimated compression ratios for header compression and for payload compression and the MTU of the transmission path between the two GIEC nodes in question.
  • IP-1, IP-2,..., IP-k, k > 1.
  • LPS size of IP packet header field 750
  • ICS size of the IPComp header field 752
  • NPS size of the No. of packets field 754
  • HCS size of the HC header 756, 758, and 760
  • HDS(k) size of all encapsulated headers 731, 733, and 735 of the packet sequence
  • IP-1, IP-2...IP-k before any header compression HDSC(k) size of all encapsulated headers 731, 733, and 735 of the packet sequence o IP- 1 , IP-2... IP-k after header before compression
  • PYS(k) size of all encapsulated payloads 732, 734, and 736 of the packet sequence
  • PYSC(k) size of all encapsulated payloads 732, 734, and 736 of the packet sequence IP-1, IP -2,...IP-k after payload compression 5
  • RH compression ratio for header compression that is equal to HDS(k) / HDSC(k)
  • RP compression ratio for payload compression that is equal to PYS(k) / PYSC(k)
  • RHE estimated value for the RH
  • RPE estimated value for the RP GPS(k): size of the GIEC packet 782 after header and payload compression have been o performed
  • GGSE(k) estimated size of the GIEC packet 782 after header and payload compression have been performed based on the values of RHE and RPE According to the encapsulation scheme B shown in FIG. 7E, the GPS(k) value, size of the GIEC packet 782 after header and payload compression have been performed, can be obtained 5 as:
  • GPS(k) LPS + ICS + NPS*k + HDSC(k) + PYSC(k)
  • the HDSC(k) and PYSC(k) cannot be known before header and payload compression have been performed.
  • the estimated values for HDSC(k) and PYSC(k) however can be obtained based on the estimated compression ratios of RHE and RPE and the HDS(k) and PYS(k), respectively. o Therefore, the GGSE(k), the estimated size of the GIEC packet 782 after header and payload compression have been performed, can be obtained by:
  • GGSE(mk) ⁇ MTU, and GGSE(mk+l) > MTU
  • the GGSE(k) value can be computed for each k before header compression and payload compression is performed. 5
  • the RHE and RPE can then be updated for the encapsulation of the next sequence of packets.
  • the preferred selection process for a sequence of packets IP-1, IP-2...IP-k to be 5 encapsulated using encapsulation scheme B shown in FIG. 7E may be summarized as follows:
  • GGSE(k) LPS + ICS + NPS + NPS*k + HDS(k) / RHE + PYS(k) / RPE
  • the initial values for RHE and RPE can be set to 1.
  • group packet encapsulation can still improve the transmission performance through reduced routing overhead and reduced data link layer framing overhead. Therefore, as long as the resultant GIEC IP packet with null 5 compression does not exceed the MTU, it is transmitted.
  • the GIEC protocol improves transmission performance by reducing the overheads of data link layer framing and IP packet routing, compressing encapsulated packet headers without requiring link-by-link connection, and increasing the payload compression ratio.
  • the typical data link layer framing overhead ranges from about 10 to 30 bytes per IP packet for ATM, PPP, and Ethernet
  • the packet header overhead ranges from 20 to 40 bytes per IP packet for IP/TCP, EP/UDP, and IP /UDP/RTP.
  • the frame introduces another 26 bytes 5 of framing overhead (i.e., 8 bytes of preamble + 14 bytes of frame header + 4 bytes of frame trailer), resulting in a total of 86 bytes transmitted over the cable every 20 milliseconds, which is 34.4 kbits/second. Assuming there are 10 voice channels transmitted between these two gateways, the total bandwidth consumption on each direction would be 344 kbits/second.
  • IP/UDP/RTP header compression is performed, which typically can reduce the IP/UDP/RTP header to 4 bytes, and assuming each HC header is 3 bytes and the "No.
  • the total length of the GIEC packet is 295 bytes (20 bytes of GIEC IP header + 4 bytes of IPComp header + 1 byte of number of packets + 3*10 of all HC headers + 4*10 of all compressed IP/UDP/RTP headers + 20*10 of all voice payloads).
  • the GIEC IP packet is still well below the MTU, which is about 1500 bytes for Ethernet. Therefore, the GIEC IP packet can be transmitted over one Ethernet frame.
  • the result is an Ethernet frame of 321 bytes (295 bytes of GIEC packet + 26 bytes framing overhead) transmitted over the cable every 20 milliseconds, that is 128.4 kbits/second.
  • a savings of about 62% of bandwidth consumption for 10 voice channels is realized.
  • 29 voice channels instead of 10 channels can be transmitted without sacrificing voice quality.
  • DSL For broadband DSL and cable modem access, multiple layers of framing overheads may be involved for each IP packet.
  • DSL it may involve IP over PPP and PPP over ATM encapsulations.
  • PPP For cable modem, it may involve IP over Ethernet frame and Ethernet frame (without preamble) over MAC protocol encapsulations.
  • Ethernet frame and Ethernet frame (without preamble) over MAC protocol encapsulations.
  • bandwidth savings can be further increased.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne l'encapsulation de paquets groupés et éventuellement un système (fig. 5A) et un procédé (fig. 5B) de compression. Dans ce procédé, un protocole d'encapsulation améliore les performances de transmission des paquets entre deux têtes de lignes ou deux ordinateurs hôtes (602, 604) en réduisant les frais de structure de trame de la couche de liaison de données, en réduisant les frais d'acheminement des paquets dans les têtes de ligne (602, 604), en compressant les en-têtes (558) des paquets dans les paquets d'encapsulation, et en augmentant le taux de compression de données sans perte au delà des taux réalisables par les systèmes habituels. Les paquets en file d'attente dans un noeud (500) agencé selon l'invention sont classifiés, groupés (554) et encapsulés (556) en un seul paquet en fonction de la présence d'un autre noeud ainsi agencé dans leur cheminement. Ces noeuds (500) échangent des paquets d'encapsulation, même si les paquets présents dans le paquet d'encapsulation peut avoir au final deux destinations différentes. On peut réaliser la compression des en-têtes, des charges utiles ou de ces deux éléments dans un paquet d'encapsulation.
PCT/US2001/031086 2000-10-05 2001-10-04 Encapsulation de paquets groupes et systeme et procede de compression WO2002029991A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001296586A AU2001296586A1 (en) 2000-10-05 2001-10-04 Group packet encapsulation and compression system and method

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US23813800P 2000-10-05 2000-10-05
US23821300P 2000-10-05 2000-10-05
US23826600P 2000-10-05 2000-10-05
US60/238,266 2000-10-05
US60/238,213 2000-10-05
US60/238,138 2000-10-05
US24105500P 2000-10-17 2000-10-17
US60/241,055 2000-10-17
US09/789,852 US6618397B1 (en) 2000-10-05 2001-02-21 Group packet encapsulation and compression system and method
US09/789,852 2001-02-21

Publications (1)

Publication Number Publication Date
WO2002029991A1 true WO2002029991A1 (fr) 2002-04-11

Family

ID=27540091

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/031086 WO2002029991A1 (fr) 2000-10-05 2001-10-04 Encapsulation de paquets groupes et systeme et procede de compression

Country Status (2)

Country Link
AU (1) AU2001296586A1 (fr)
WO (1) WO2002029991A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002080372A3 (fr) * 2001-03-29 2002-12-27 Koninkl Philips Electronics Nv Flot de donnees a donnees reduites destine a transmettre un signal
EP1432196A1 (fr) * 2002-12-20 2004-06-23 Matsushita Electric Industrial Co., Ltd. Méthode de compression pour le trafic de commande dans la transmission de données média
EP1553774A1 (fr) * 2002-07-16 2005-07-13 Matsushita Electric Industrial Co., Ltd. Appareil de reception de contenu et appareil de transmission de contenu
EP1773012A1 (fr) * 2005-10-05 2007-04-11 Alcatel Lucent Procédé et dispositif pour le transport de services en mode circuit dans un réseau de transport en mode paquet
WO2007125259A1 (fr) * 2006-04-28 2007-11-08 France Telecom Procede de transmission d'une pluralite de champs identificateurs dans un reseau a commutation de paquets
WO2008134157A1 (fr) 2007-04-26 2008-11-06 Microsoft Corporation Compression de paquets de données tout en conservant une authentification d'extrémité à extrémité
DE10353289B4 (de) * 2003-11-14 2009-10-15 Infineon Technologies Ag Verfahren und Vorrichtung zur Kompression von Datenpaketen
KR101005138B1 (ko) 2002-05-29 2011-01-04 레이데온 컴퍼니 셀들의 캡슐화를 위한 방법 및 시스템
US8995469B2 (en) 2008-01-30 2015-03-31 Qualcomm Incorporated Relay based header compression
WO2015133770A1 (fr) * 2014-03-03 2015-09-11 Lg Electronics Inc. Appareil et procédés pour émettre/recevoir un signal de diffusion
CN105191225A (zh) * 2013-03-28 2015-12-23 株式会社东芝 通信装置、通信方法、以及通信程序

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5535199A (en) * 1994-09-06 1996-07-09 Sun Microsystems, Inc. TCP/IP header compression X.25 networks
US5774467A (en) * 1994-01-21 1998-06-30 Koninklijke Ptt Nederland Nv Method and device for transforming a series of data packets by means of data compression
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774467A (en) * 1994-01-21 1998-06-30 Koninklijke Ptt Nederland Nv Method and device for transforming a series of data packets by means of data compression
US5535199A (en) * 1994-09-06 1996-07-09 Sun Microsystems, Inc. TCP/IP header compression X.25 networks
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002080372A3 (fr) * 2001-03-29 2002-12-27 Koninkl Philips Electronics Nv Flot de donnees a donnees reduites destine a transmettre un signal
KR101005138B1 (ko) 2002-05-29 2011-01-04 레이데온 컴퍼니 셀들의 캡슐화를 위한 방법 및 시스템
EP1553774A1 (fr) * 2002-07-16 2005-07-13 Matsushita Electric Industrial Co., Ltd. Appareil de reception de contenu et appareil de transmission de contenu
US8503471B2 (en) 2002-07-16 2013-08-06 Panasonic Corporation Content receiver and content transmitter
EP1553774A4 (fr) * 2002-07-16 2011-05-25 Panasonic Corp Appareil de reception de contenu et appareil de transmission de contenu
EP1432196A1 (fr) * 2002-12-20 2004-06-23 Matsushita Electric Industrial Co., Ltd. Méthode de compression pour le trafic de commande dans la transmission de données média
DE10353289B4 (de) * 2003-11-14 2009-10-15 Infineon Technologies Ag Verfahren und Vorrichtung zur Kompression von Datenpaketen
WO2007039597A1 (fr) * 2005-10-05 2007-04-12 Alcatel Lucent Procede et dispositif servant a transporter des services commutes par circuit sur un reseau de transport en mode de paquets
EP1773012A1 (fr) * 2005-10-05 2007-04-11 Alcatel Lucent Procédé et dispositif pour le transport de services en mode circuit dans un réseau de transport en mode paquet
WO2007125259A1 (fr) * 2006-04-28 2007-11-08 France Telecom Procede de transmission d'une pluralite de champs identificateurs dans un reseau a commutation de paquets
US7953091B2 (en) 2006-04-28 2011-05-31 France Telecom Method for transmitting a plurality of identifier fields in a packet switch network
EP2145435A1 (fr) * 2007-04-26 2010-01-20 Microsoft Corporation Compression de paquets de données tout en conservant une authentification d'extrémité à extrémité
WO2008134157A1 (fr) 2007-04-26 2008-11-06 Microsoft Corporation Compression de paquets de données tout en conservant une authentification d'extrémité à extrémité
EP2145435A4 (fr) * 2007-04-26 2014-12-31 Microsoft Corp Compression de paquets de données tout en conservant une authentification d'extrémité à extrémité
US8995469B2 (en) 2008-01-30 2015-03-31 Qualcomm Incorporated Relay based header compression
CN105191225A (zh) * 2013-03-28 2015-12-23 株式会社东芝 通信装置、通信方法、以及通信程序
WO2015133770A1 (fr) * 2014-03-03 2015-09-11 Lg Electronics Inc. Appareil et procédés pour émettre/recevoir un signal de diffusion

Also Published As

Publication number Publication date
AU2001296586A1 (en) 2002-04-15

Similar Documents

Publication Publication Date Title
US6618397B1 (en) Group packet encapsulation and compression system and method
CN1155210C (zh) 一种支持压缩分段头标的分段协议
US7136377B1 (en) Tunneled datagram switching
EP1247420B1 (fr) Procede et dispositif assurant une commutation efficace au niveau d'application pour des flux de media a protocole internet multiplexes
EP1122925B1 (fr) Compression d'en-tête pour service général de radiocommunication par paquets dans un protocole tunnel (GTP)
EP1243118B1 (fr) Systeme et procede permettant d'obtenir une compression d'en-tete ip/udp/rtp robuste en presence de reseaux non fiables
EP1994716B1 (fr) Transport de paquets
US8045585B2 (en) Method and apparatus providing media aggregation in a packet-switched network
EP1106008A1 (fr) Procede et appareil assurant un multiplexage utilisateur dans un protocole en temps reel -
JP2005509381A (ja) ヘッダ圧縮を行う無線通信装置
JP2005509381A6 (ja) ヘッダ圧縮を行う無線通信装置
EP1495612B1 (fr) Procede et appareil de transmission efficace de trafic voip
WO2006123980A1 (fr) Compression d'en-tete ip au moyen d'un noeud mobile ipv6
JP4044845B2 (ja) 無線データ通信のための圧縮方法、送信機及び受信機
WO2002029991A1 (fr) Encapsulation de paquets groupes et systeme et procede de compression
Shambour et al. Effective voice frame shrinking method to enhance VoIP bandwidth exploitation
WO2008079200A1 (fr) Suppression d'en tête dans un réseau de communication sans fil
US20020064190A1 (en) Method for compressing packet headers within a trunking protocol for aggregating multiple information channels across a network
Niu et al. Backfill: An efficient header compression scheme for OpenFlow network with satellite links
Al-Mimi et al. Enhancing Bandwidth Utilization of IP Telephony Over IPv6 Networks.
FI110151B (fi) Menetelmä pakettien siirtämiseksi piirikytkentäisen verkon yli
US20020018471A1 (en) Method and system for voice-over-IP communication
Morais et al. 5G Transport Payload: Ethernet-Based Packet-Switched Data
JP2005167458A (ja) 音声画像伝送方法
Morais Broadband Wireless Payload: Packet-Switched Data

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载