Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
2001-02-26
2002-05-07
Luther, William (Department: 2664)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S465000, C370S474000, C314S025000
Reexamination Certificate
active
06385199
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a packet transmitting method for transmitting and receiving packets among a plurality of data terminals, and a relaying device and a data terminal used for the packet transmission.
2. Description of Related Art
Recently, a demand for transmitting through the Internet such data as video data or audio data, which requires a real time transmission, has been intensified.
As a protocol to meet the demand, an RTP (Real-time Transport Protocol) is ruled by the RFC (Request For Comment) 1889, which was issued by the IETF (Internet Engineering Task Force), a group for standardizing the Internet. The RTP has functions such as 1) specification of a payload type, 2) designation of a sequence number, and 3) designation of a timestamp. These rules enable such information as audio and video data to be transmitted in real time on the Internet. Usually, the RTP is used as an upper layer for the IP (internet protocol) on a network layer and the UDP (User Datagram Protocol) on a transport layer.
FIG. 11A
shows contents of an RTP header, UDP header, and IP header (hereafter, referred to as “RTP/UDP/IP headers”) attached to data, such as audio and video data, to be transmitted according to the RTP, UDP and IP. Hereinafter, a packet including the RTP/UDP/IP headers is called an IP packet.
As shown in the drawing, the IP header needs 20 bytes, the UDP header does 8 bytes, and the RTP header does 12 b bytes, thus the total amount of RTP/UDP/IP headers reaches 40 bytes. In contrast, video data contained in one IP packet comprises, for example, about 50 bytes. For transmitting such image data in the form of packets, the overhead reaches therefore no less than 44 percents. Similarly, for transmitting audio data which comprises 20 bytes in one packet, the overhead reaches as much as 66 percents. Since a practical transmission needs headers for other layers to be added, the whole headers occupy a large percentage of one packet, thereby causing a drawback of reducing efficiency in communication.
As one technique to overcome the drawback, the RFC2508 issued by the IETF shows an RTP compression protocol to compress the RTP/UDP/IP headers. The RTP compression protocol permits the RTP/UDP/IP headers shown in the
FIG. 11A
to be compressed into a header exemplified in
FIG. 11B
(hereinafter referred to as a “compressed header”). This compression will be detailed as follows.
The method of the compression is applied between two nodes on a network through which packets are transmitted among a plurality of data terminals, for example. More specifically, of the two nodes, one node (hereinafter referred to as a “sender node”) converts the RTP/UDP/IP headers of one part of the IP packets communicated among the data terminals into a compressed header, and transmits it, as a header-compressed packet, to the other node (hereinafter referred to as a “receiver node”). Concurrently, the sender node transmits the RTP/UDP/IP headers of the other part of the IP packets to the receiver node, as a full-header packet without any compression. The receiver node decompresses (i.e., restoration) to an IP packet the header-compressed packet or the full-header packet received from the sender node, and sends it to the next node or a receiver data terminal. The full header is a header in which lengths included in the RTP/UDP/IP headers shown in
FIG. 11A
are replaced by information including a CONTEXT_ID for identifying the RTP connection and a link sequence number link_seq, a serial number, given in the order of transmission from the sender node.
The content of the compressed header shown in
FIG. 11B
will now be explained. The data of sections with dense hatching applied in the RTP/UDP/IP headers in
FIG. 11A
, which includes a version number (V) written in the IP header and the payload type written in the RTP header, are constant data (hereinafter referred to as “static fields”) for each packet to be transmitted from the sender node. Hence, as illustrated in
FIG. 11B
, the compressed header does not include data of the static fields. When the sender node sends the first IP packet of the packet stream to the receiver node, it sends a full-header packet which has a full header including the static fields. After this, the sender node converts the RTP/UDP/IP headers of the succeeding IP packets into a compressed header with no static fields included. The thus-converted compressed header is sent to the reception node as a header-compressed packet. When the receiver node receives the full header packet corresponding to the first IP packet, the receiver node restores the received RTP/UDP/IP headers with reference to the full header in the first received full-header packet, and writes the thus decompressed headers into an internal storage device. After this, the receiver node uses the static fields of the RTP/UDP/IP headers so as to restore the static fields of the compressed header in the header-compressed packets that will be received successively after the first packet.
The data in the static fields are not always constant over all the IP packets, but might be changed in a certain IP packet. If such a change occurs in a certain IP packet, the sender node will transmits a full header packet including a full header corresponding to the RTP/UDP/IP header of the IP packet to the receiver node, without compression.
The data in the sections with no hatching applied in the RTP/UDP/IP headers shown in
FIG. 11A
include the sequence number and timestamp of the RTP header as well as the ID of the IP header. The timestamp indicates the time at which a packet is transmitted or generated. Such data are expected to have constant difference values (changed amounts) between successive two IP packets transmitted in turn. Hereinafter, fields providing such data are referred to as “delta fields.” As shown in
FIG. 11B
, the basic compressed header does not include the data in the delta fields. As described above, the receiver node, which holds RTP/UDP/IP headers in its storage device, adds difference values, which have been previously obtained, respectively to the values in the corresponding delta fields of the stored RTP/UDP/IP headers, thus being able to decompress delta fields of compressed headers which will consecutively be received thereafter.
However, it is not always true that the difference values in the delta fields are constant between all the IP packets. There are some cases where changes are made to their difference values. In such cases, changed difference values have to be notified to the receiver node. The receiver node is able to restore the contents in the delta fields contained in the RTP/UDP/IP headers of each header-compressed packet which will be received thereafter, with reference to the contents of the RTP/UDP/IP headers held in the storage device and the newly notified difference values. For this purpose, the compressed header shown in
FIG. 11A
has flags S, T and I that represent whether the difference values in the delta fields are changed or not. If any difference values are changed, the new difference values are added to the compressed header, as shown by the dotted lines in FIG.
11
B. Practically, if there is a change in the difference value of the sequence number of the RTP header, “1” is set to the flag S and a sequence number difference value (delta RTP sequence) showing the new difference value of the sequence number is added to the compressed header, as shown by the dotted line in FIG.
11
B. Similarly, if there is a change in the difference value of the timestamp of the RTP header, “1” is set to the flag T, and a timestamp difference value (delta RTP timestamp) showing the new difference value of the timestamp is included in the compressed header, as shown by the dotted line in FIG.
11
B. Further, if there is a change in the difference value of the ID of the IP header, “1” is set to the flag I, and an ID difference value (delta IP ID) showing the new difference value of the ID is attached to the compressed header.
As shown in
Kawahara Toshiro
Suzuki Takashi
Yoshimura Takeshi
Brinks Hofer Gilson & Lione
Luther William
NTT Mobile Communications Network
LandOfFree
Method and apparatus for packet transmission with header... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for packet transmission with header..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for packet transmission with header... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2889664