JP2002094553A - Device and method for transmitting packet - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable a receiving side to correctly restore a header without lowering the compression efficiency of the header and the transmission efficiency of a packet even when both header compression and retransmission control are used. SOLUTION: When an RTP packet generating part 101 outputs a retransmission request signal to a compression method selecting part 202, the part 202 compares the sequence number of a retransmission packet with the sequence number of context stored in a buffer 203. In the part 202, when the sequence number of the retransmission packet is smaller than the sequence number of the context, the header is restored without referring to the reference information on the opposite communication side, and the header that is not used to update the reference information is selected as the header of the retransmission packet.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a packet transmission apparatus and a packet transmission method, and more particularly, to a packet transmission apparatus and a packet transmission method for compressing and transmitting a header.

[0002]

2. Description of the Related Art At present, as a typical protocol (communication procedure) used for transmitting a packet on the Internet, RTP (Real-time Transport Protocol) is used.
l), UDP (User Data Protocol), IP (Internet P
rotocol), and in packet transmission, these protocols are generally used in combination. These protocols are also based on the IETF (Internet Engineering Tas
k Force).

In each of the above protocols, a packet is generated by adding the following information as a header to transmission data. That is, first, in RTP,
As shown in (a), a sequence number (hereinafter referred to as “SN”) indicating the order of data and a time stamp (hereinafter referred to as “TS”) as time information are added to the data.
An RTP packet is generated. Next, in UDP, FIG.
As shown in (b), the port number on the receiving side is RTP
A UDP packet is generated by being added to the packet. Next, in the IP, as shown in FIG. 6C, an address (IP address) on the receiving side on the Internet is added to the UDP packet to generate an IP packet. Then, the IP packet is transmitted to the receiving side.

[0004] Further, there is a header compression technique as a technique for improving packet transmission efficiency by compressing and transmitting a header. Regarding the compression method of each header added in RTP, UDP, and IP, the IETF requested RFC (Request For
Comments) 2508. The header compression method specified in RFC2508 is mainly specified for packet transmission over a wire such as the Internet.

On the other hand, ROHC (RObust Header Compression) is currently proposed as a header compression method proposed by the IETF for wireless packet transmission such as in a mobile phone network. Since the error rate during packet transmission tends to be higher in the wireless section than in the wired section, ROHC is
This is a header compression method characterized by having a high resistance to an error generated during transmission.

[0006] Further, since the usable frequency band is narrower in the wireless section than in the wired section, ROHC has a higher header compression ratio than the header compression method specified in RFC2508. ROHC is draft-ietf
-rohc-rtp-kw-00.txt and draft-ietf-rohc-rtp-rocco-00.
Proposed as txt etc.

[0007] Specifically, ROHC compresses a header as follows. That is, since the IP address and the port number do not change from the start of communication to the end of communication, they are transmitted only once after the start of communication. Also, the increase in SN
If there is a certain regularity with the increment of TS, only SN is transmitted. Further, for the SN, only the lower few bits are transmitted, and all bits are transmitted only when a carry occurs. The transmitting side refers to reference information called a context to compress the header, and the receiving side refers to the same context used by the transmitting side to restore the header.

[0008] In ROHC, there are basically three types of headers as shown in FIGS. 7A to 7C, which are called UPDATE_FULLHEADER, UPDATE, and NON_UPDATE, respectively. UPDATE_FULLHEADER shown in FIG. 7A includes an IP address and a port number in addition to the SN and the TS. As described above, since the IP address and port number are not changed from the start of communication to the end of communication, UPDATE_FULLHEADER is
Usually, it is transmitted only once at the beginning of the communication. FIG.
The UPDATE shown in (b) does not include the IP address or the port number, but includes the flag 'U' indicating that the SN, TS, and context are updated. In addition, N shown in FIG.
ON_UPDATE does not include the IP address, port number, and TS, but includes SN ′ represented by only the lower few bits of the SN.

On the receiving side, UPDATE_FULLHEADER, UPDAT
E For each NON_UPDATE, the header is restored by changing the presence / absence of context update and the header restoration method. That is,
The receiving side updates the context when UPDATE_FULLHEADER or UPDATE is received, and does not update the context when NON_UPDATE is received.

On the receiving side, when UPDATE_FULLHEADER or UPDATE is received, the SN and TS included in UPDATE_FULLHEADER or UPDATE are used as the SN and TS of the received packet. On the other hand, when NON_UPDATE is received, the context is referred to and included in NON_UPDATE.
The SN and TS of the received packet are restored from SN '.

Next, a procedure for transmitting and receiving packets performed using ROHC will be specifically described with reference to a sequence diagram.
FIG. 8 is a sequence diagram for explaining a procedure of transmitting and receiving a packet performed using ROHC. For simplicity, UPDATE_FULLHEADER and UPDAT
The SN included in E is represented by 3 bits, and NON_UPDATE
Is represented by the lower 2 bits of the SN.
Further, the IP address and the port number are also stored as the context, and the IP address and the port number are restored on the receiving side. However, the description of the IP address and the port number is omitted here for the sake of simplicity.

In FIG. 8, the transmitting side transmits UPDATE_FULLHEADER in the first transmission after the start of communication. This UPD
SN of ATE_FULLHEADER is '000' (binary number) and TS is '0'
It is. Then, when transmitting UPDATE_FULLHEADER, the transmitting side sets the SN of the context to “000” and the TS to “0”.
Similarly, on the receiving side, when UPDATE_FULLHEADER is received, the SN of the context is set to “000” and the TS is set to “0”. As a result, the context on the transmitting side matches the context on the receiving side. On the receiving side, the received SN and TS are used directly as the SN and TS of the received data.

In the second to fourth transmissions, the transmitting side sets NON_
Send UPDATE. From the comparison result of the SN to be transmitted and the SN of the context, the transmitting side determines the SN in the second to fourth transmissions.
It is determined that the most significant bit of is not changed to '0', that is, the SN has not been carried, and in NON_UPDATE, only the lower two bits of the SN are transmitted. Also, in this example, there is a regularity that TS increases by 10 every time SN increases by 1. Therefore, NON_UPDA
TS is not transmitted in TE.

On the receiving side, in the second to fourth receptions, the SN and TS are restored with reference to the context set in the first reception. In other words, the most significant bit of the received SN is the most significant bit of the SN of the context.
Decompress the compressed SN by supplementing 0's. Also, if SN is 1
Restore TS by increasing TS by 10 for each increase. For example, 4
In the third reception, 30 is added to TS'0 'of the context, and the TS of the fourth received data is restored as'30'.

In the fifth transmission, a carry occurs in the SN, so the transmitting side transmits UPDATE. That is, an UPDATE with SN set to '100' and TS set to '40' is transmitted. When transmitting UPDATE, the SN of the context is updated to '100' and the TS is updated to '40'. Similarly, the receiving side sets the SN of the context to “100” and the TS to “40” when receiving the UPDATE. As a result, the context on the transmitting side matches the context on the receiving side. On the receiving side, the received SN and TS are used directly as the SN and TS of the received data.

After the sixth time, the same procedure is repeated. Here, as shown by the crosses in FIG. 8, even if an error occurs during the transmission of the third transmitted packet and the packet is discarded on the receiving side, the ROHC receives the fourth and subsequent received packets. In, the header can be correctly restored. As described above, ROHC has a feature that the effect of an error generated during transmission does not affect the restoration of another header.
As described above, by using ROHC as a header compression method, it is possible to increase the header compression ratio while having high resistance to an error generated during transmission.

[0017]

However, the above RO
When the HC is used together with the retransmission control, there is a problem that the header of the retransmission packet cannot be correctly restored on the receiving side. Hereinafter, this problem will be specifically described with reference to a sequence diagram. FIG. 9 is a sequence diagram for explaining a transmission / reception procedure when ROHC is used together with retransmission control. 9 differs from the procedure shown in FIG. 8 in that a retransmission request is sent from the receiving side to the transmitting side at the time of the fourth reception, and the transmitting side retransmits the packet in which an error has occurred.

First, the receiving side detects in the UDP layer that an error has occurred in NON_UPDATE whose SN received at the third time is '2' by CRC (Cyclic Redundancy Check) or the like, and discards the NON_UPDATE. And the receiving side is RTP
In the layer, since the SN restored from the fourth NON_UPDATE received is “3”, discontinuity of the SN is detected, and a request for retransmission of the packet whose SN is “2” is made to the transmitting side.

Here, it takes some time from when the transmitting side transmits the third packet to when the transmitting side receives the retransmission request for the packet. This time is RTT (Round Trip
9), and corresponds to the time from the third transmission on the transmitting side to the reception of the retransmission request signal in FIG.

During the RTT, if the context has already been updated in the fifth transmission / reception as shown in FIG.
Even if the third transmission (NON_UPDATE transmitted) is retransmitted as it is in the seventh transmission, the receiving side cannot correctly restore the header.

That is, on the receiving side, the SN of the context has already been updated to '100' and the TS has been updated to '40' at the time of the fifth reception. For this reason, the receiving side erroneously decompresses the compressed SN as '6' (decimal number) by supplementing '1' to the most significant bit of the SN received at the seventh time, and replaces it with the TS '40' of the context. By adding 20, the TS of the seventh received packet is erroneously restored to '60'.

In order to prevent such an erroneous restoration, it is conceivable to adopt a method in which the transmission side transmits an UPDATE in response to a retransmission request as shown in FIG. When the receiving side receives the UPDATE, it uses the received SN and TS as the header as it is.
By transmitting an UPDATE with the SN set to '010' and the TS set to '20', the receiving side identifies the SN that could not be restored during the third reception.
The TS can be obtained correctly in the seventh reception.

However, by transmitting the UPDATE, the SN of the context becomes “010” in the seventh transmission / reception.
Then, TS is updated to '20'. Therefore, when the transmitting side transmits NON_UPDATE in the eighth and ninth transmissions, the receiving side erroneously restores the SN and the TS as described above. Therefore, on the sending side, the UP also occurs at the 8th transmission
DATE needs to be sent. As described above, in order to correctly restore the header even in the case of retransmission, the transmitting side needs to transmit UPDATE for the retransmission request and another UPDATE again.

However, as shown in FIG.
The data amount of the header part is larger than NON_UPDATE. Therefore, when the procedure shown in FIG. 10 is adopted, there is a problem that the compression efficiency of the header is reduced. In other words, there is a problem that the packet transmission efficiency is reduced.

The present invention has been made in view of the above point, and even when header compression and retransmission control are used in combination, the header compression efficiency and the packet transmission efficiency are not reduced, and the header is transmitted to the receiving side. An object of the present invention is to provide a packet transmission device and a packet transmission method capable of correctly restoring.

[0026]

A packet transmission apparatus according to the present invention is a packet transmission apparatus used in a packet communication system in which a header is compressed and decompressed using reference information, and a retransmission request from a communication partner. Retransmitting means for retransmitting a packet to a packet, and a header which is used for retransmitting the packet transmitted before the update of the reference information without being referred to by the communication partner and which is not used for updating the reference information. As a header of a retransmission packet.

According to the packet transmission apparatus of the present invention, when the sequence number of the retransmission packet is smaller than the sequence number of the reference information, the selecting means restores the reference information without referring to the reference information on the communication partner side. A configuration is adopted in which a header not used for updating information is selected as a header of a retransmission packet.

The image distribution device of the present invention employs a configuration in which the above-described packet transmission device is mounted.

According to these configurations, a header configuration similar to that of UPDATE is adopted. However, since a header indicating that the context is not updated by the header is used as the header of the retransmission packet, the packet transmitted next to the retransmission packet is Even if it is a packet of NON_UPDATE instead of a packet, the packet receiving side can correctly restore the header from NON_UPDATE. Therefore, according to these configurations, even when both header compression and retransmission control are used,
The header can be correctly restored on the receiving side without lowering the header compression efficiency and the packet transmission efficiency.

The computer-readable storage medium of the present invention includes a retransmission step of retransmitting a packet in response to a retransmission request from a communication partner, and a packet transmitted before updating reference information used for header compression and decompression. When retransmitting, a header that is restored without referring to the reference information on the communication partner side and that is not used for updating the reference information,
A selection step of selecting as a header of a retransmission packet;
Is stored in the computer.

According to the program stored in the storage medium, a header configuration similar to that of UPDATE is adopted, but the header that the context is not updated by the header is used as the header of the retransmission packet, so that the header is transmitted after the retransmission packet. Packet, not UPDATE packet
NO on the packet receiving side even for NON_UPDATE packets
The header can be correctly restored from N_UPDATE. Therefore, according to these configurations, even when the header compression and the retransmission control are used together, the header compression efficiency and the packet transmission efficiency do not decrease, and the header can be correctly restored on the receiving side.

The server of the present invention provides a retransmission step of retransmitting a packet in response to a retransmission request from a communication partner, and a retransmission step of retransmitting a packet transmitted before updating reference information used for header compression and decompression. Storage means for storing a program for causing a computer to execute a selection step of selecting, as a header of a retransmitted packet, a header which is restored without reference information being referenced and not used for updating reference information on the communication partner side, and a client And a transmission means for transmitting the program to the client in response to a request from the client.

According to the program transmitted from the server, the header configuration similar to that of UPDATE is adopted, but the header that the context is not updated by the header is used as the header of the retransmission packet. Not an UPDATE packet
NO on the packet receiving side even for NON_UPDATE packets
The header can be correctly restored from N_UPDATE. Therefore, according to these configurations, even when the header compression and the retransmission control are used together, the header compression efficiency and the packet transmission efficiency do not decrease, and the header can be correctly restored on the receiving side.

According to the packet transmission method of the present invention, when the packet receiving side detects an error in a received packet, the packet transmitting side transmits a packet retransmission request to the packet transmitting side, and the packet transmitting side transmits a packet retransmission request. When retransmitting a packet transmitted before updating the reference information used for compression and decompression, a header that is decompressed without reference information being used on the packet receiving side and is not used for updating the reference information is replaced with a header of the retransmitted packet. Select as header.

According to this method, a header structure similar to that of the UPDATE is adopted, but a header that the context is not updated by the header is used as a header of the retransmission packet.
Even if the packet is not a DATE packet but a NON_UPDATE packet, the packet receiving side can correctly restore the header from the NON_UPDATE. Therefore, according to these configurations, even when the header compression and the retransmission control are used together, the header compression efficiency and the packet transmission efficiency are not reduced,
Moreover, the header can be correctly restored on the receiving side.

[0036]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Depending on the type of data (for example, voice data), the regularity between the increase in SN and the increase in TS may temporarily be lost. To deal with this case, UPDATE_FULLHEADER, UPDATE and N
In addition to ON_UPDATE, the IETF uses a special header that uses the same structure as UPDATE, but the context is not updated by the header. The IETF draft-ietf-roh
Proposed as c-rtp-kw-00.txt. In the following description, this special header is referred to as 'NON_UPDATE with SN / TS'.

As shown in FIG. 1, NON_UPDATE with SN / TS does not include an IP address or a port number.
And a flag 'N' indicating that the context is not updated. In other words, NON_UPDATE with SN / TS is
It differs from UPDATE only in that the context is not updated.

[0038] The transmitting side transmits this NON_UPDATE with SN / TS to S
By transmitting when the regularity between the increment of N and the increment of TS is temporarily broken, the receiving side can use NON_UPDATE
The header can be correctly restored from NON_UPDATE received after with SN / TS.

In other words, as shown in FIG. 2, the regularity that the TS increases by 10 every time the SN increases by 1 in the TS transmitted for the third time is broken.
NON_UPDATE with SN / TS with SN set to '010' and TS set to '15' is transmitted. On the receiving side, when NON_UPDATE with SN / TS is received, SN'010 'and TS'15' are directly used as the SN and TS of the received packet as in the case of UPDATE, but the context is not updated by the SN and TS. . That is, the context is SN'0
00 'and TS'0' are maintained. Therefore, the fourth and subsequent transmissions are performed as usual, and the receiving side can correctly restore the header from NON_UPDATE by referring to the context.

The inventor has determined that this special header (NON_UPDA
Focusing on the operation of the receiving side when TE with SN / TS) is transmitted, this special header is used even when the regularity between the increase in SN and the increase in TS is temporarily lost. (NON_UPDATE
With SN / TS), the present inventors have found that the present invention can be used effectively, and have led to the present invention.

That is, the gist of the present invention is that
A special header (NON_UP) that is proposed to be used when the regularity with the increment of TS is temporarily lost
By using DATE with SN / TS) as the header of the retransmitted packet, the header compression efficiency and the packet transmission efficiency are not reduced, and the header is correctly restored on the receiving side.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. FIG. 3 is a block diagram showing a configuration of the packet transmission device according to one embodiment of the present invention. Here, a case where a packet is transmitted via a wireless line will be described.

In FIG. 3, an RTP packet generator 101
Generates an RTP packet by dividing transmission data into predetermined transmission units and adding an SN and a TS to the divided data. Then, the RTP packet generator 101 outputs the RTP packet to the switch 102 and the buffer 103. Each RTP packet output to the buffer 103 is stored in the buffer 1
03 is stored for a predetermined time.

When a retransmission request signal is output from retransmission request signal receiving section 109, RTP packet generating section 101 outputs the RTP packet of the SN indicated in the retransmission request signal from buffer 103 to switch 102. I do. Also, in this case, the RTP packet generator 101
02 is switched to the ● side to connect the buffer 103 and the UDP packet generator 104. Further, in this case, RTP packet generation section 101 outputs a retransmission request signal to transmission packet generation section 106.

The switch 102 is normally connected to the ○ side,
Only when a retransmission request signal is input to the RTP packet generator 101, the control of the RTP packet generator 101
Can be switched to the side. That is, the RTP packet generator 101 and the UDP packet generator 104 are normally connected, and the buffer 103 and the UDP packet generator 104 are connected only when there is a retransmission request from the communication partner. Becomes Thereby, when a retransmission request is made from the communication partner, the RTP packet stored in the buffer 103 is regarded as a retransmission packet and the UDP packet generation unit 10
4 is output.

The buffer 103 includes the RTP packet generator 1
Each of the RTP packets output from 01 is stored for a predetermined period. The buffer 103 is, for example, RTT (Round
Trip Time) is stored for each RTP packet.

The UDP packet generation unit 104 generates a UDP packet by adding the port number on the receiving side to the RTP packet, and outputs the UDP packet to the IP packet generation unit 105.

The IP packet generation unit 105 generates an IP packet by adding an address (IP address) on the receiving side on the Internet to the UDP packet, and outputs the IP packet to the transmission packet generation unit 106.

[0049] Transmission packet generator 106 compresses the header. Then, transmission packet generating section 106 adds the compressed header to the data to generate a transmission packet, and outputs the transmission packet to transmitting section 107. The configuration of the transmission packet generation unit 106 and a header compression method will be described later.

After performing a modulation process and a radio process (D / A conversion, up-conversion, etc.) on the transmission packet, transmission section 107 transmits the transmission packet to a communication partner via antenna 108.

[0051] The retransmission request signal receiving section 109 is connected to the antenna 1
After performing radio processing (down-conversion, A / D conversion, etc.) and demodulation processing on the retransmission request signal received via
A retransmission request signal is output to RTP packet generation section 101.

Next, the configuration of the transmission packet generator 106 will be described. FIG. 4 is a block diagram illustrating a configuration of the transmission packet generation unit of the packet transmission device according to one embodiment of the present invention.

In FIG. 4, the header separation unit 201
The header part (IP address, port number, SN, TS) of the IP packet output from the packet generation unit 201 is separated from the data part, the header is output to the compression method selection unit 202 and the header compression unit 204, and the data is output. Output to the compressed header adding unit 205.

The compression method selection unit 202 selects a compression method of the header, and sets the selected compression method to the header compression unit 204.
Inform That is, the compression method selection unit 202
TE_FULLHEADER, UPDATE, NON_UPDATE, NON_UPDATE with
One of the four types of headers, SN / TS, is selected, and the type of the selected header is determined by the header compression unit 204.
Inform A specific selection method will be described later.

The buffer 203 is a buffer for storing a context. The context stored in the buffer 203 is appropriately updated by the compression method selection unit 202.

The header compressing section 204 includes a compressing method selecting section 2
In accordance with the type of the header selected in 02, the header output from the header separating unit 201 is compressed, and the compressed header is output to the compressed header adding unit 205. Further, the header compression unit 204 refers to the context stored in the buffer 203 and compresses the header based on the context.

The compressed header adding section 205 adds the header output from the header compressing section 204 to the data output from the header separating section 201, and outputs a transmission packet with the compressed header to the transmitting section 107. .

Next, a method of selecting the type of header performed by the compression method selection unit 202 will be described. The compression method selection unit 202 selects one of the four types of headers as follows. In the following description, UPDATE_FULLHEADER, UPDAT
E and SN included in NON_UPDATE with SN / TS are represented by 3 bits, and SN ′ included in NON_UPDATE is represented by lower 2 bits of SN.

The retransmission request signal is output from the RTP packet generation unit 101 to the compression method selection unit 202, and the SN of the header output from the header separation unit 204 indicates the context.
If the value is smaller than SN, the compression method selection unit 202
Selects NON_UPDATE with SN / TS.

When a retransmission request signal is output from RTP packet generation section 101 to compression method selection section 202,
The retransmission packet is output from the buffer 103 shown in FIG.
Then, the retransmission packet is input to the header separation unit 201 via the switch 102, the UDP packet generation unit 104, and the IP packet generation unit 105. Therefore, the SN of the header output from header separation section 201 to compression method selection section 202 becomes the SN of the retransmission packet. That is, when the SN of the retransmission packet is smaller than the SN of the current context, the compression method selection unit 202 determines that the NON_UPDATE with SN
Select / TS.

NON_UPDATE with compression method selection unit 202
Since SN / TS is selected, the header compression unit 204 extracts the SN and TS from the header output from the header separation unit 201 (that is, the header of the retransmission packet), and indicates that the context is not updated. Output to compressed header adding section 205 together with 'N'. Then, the compressed header adding unit 2
05 represents the SN, TS, and N as the data output from the header separation unit 201 (that is, the data of the retransmission packet).
To be added. By this means, when there is a retransmission request from the communication partner and the packet transmitted before updating the context is retransmitted, a retransmission packet of NON_UPDATE with SN / TS is retransmitted to the communication partner. When NON_UPDATE with SN / TS is selected, the compression method selection unit 202 does not update the context stored in the buffer 203.

On the other hand, when the retransmission request signal is not output from the RTP packet generator 101 to the compression method selector 202, the compression method selector 202 updates the UPDATE_FULLHEADER, UPD
Select either ATE or NON_UPDATE header as follows.

That is, when the SN included in the header output from header separation section 201 is “000”, compression method selection section 202 selects UPDATE_FULLHEADER.
That is, UPDATE_FULLHEADER only once after the start of communication
Is selected.

UPDATE_FULLHEADE in the compression method selection unit 202
Since R is selected, the header compression unit 204 uses the header (IP address, port number, SN and TS) output from the header separation unit 201 as it is,
Output to Then, the compressed header adding unit 205
The IP address, port number, SN, and TS are added to the data output from the header separation unit 201. This allows
The UPDATE_FULLHEADER transmission packet is transmitted to the communication partner. Also, the compression method selection unit 202 updates the UPDATE_FULLHEA
When DER is selected, the IP address, port number, SN, and TS included in the header output from the header separation unit 201 are stored as contexts in the buffer 203.

If the SN included in the header output from the header separation unit 201 is other than '000', the compression method selection unit 202 determines the SN included in the header and the SN of the context stored in the buffer 203. Compare with

If no carry has occurred in the SN included in the header, the compression method selection unit 202 outputs
Select UPDATE. For example, if the SN of the context is “000”, NON_UPDATE is selected while the SN included in the header is between “001” and “011”.

Since NON_UPDATE is selected by the compression method selection unit 202, the header compression unit 204
After extracting the SN from the header output from 1, the lower 2 bits of the SN are output to the compressed header adding unit 205 as SN ′. Then, the compressed header adding unit 205 adds this SN ′ to the data output from the header separating unit 201. Thereby, the NON_UPDATE transmission packet is transmitted to the communication partner. When NON_UPDATE is selected, the compression method selection unit 202 does not update the context stored in the buffer 203.

On the other hand, when a carry occurs in the SN included in the header, the compression method selection unit 202 selects UPDATE. For example, if the SN of the context is '000', UPDAT when the SN included in the header becomes '100'
E is selected.

Since UPDATE has been selected by the compression method selection unit 202, the header compression unit 204 extracts the SN and TS from the header output from the header separation unit 201, and sets a flag 'U indicating that the context is updated. 'And output to the compressed header adding unit 205. Then, the compressed header adding unit 20
5 adds the SN, TS and U to the data output from the header separating section 201. As a result, the UPDATE transmission packet is transmitted to the communication partner. When UPDATE is selected, the compression method selection unit 202 determines the SN of the context stored in the buffer 203 by using the SN and TS included in the header output from the header separation unit 204.
And update TS. That is, the context is updated each time the SN is carried.

Next, a procedure for transmitting and receiving packet transmission performed between the packet transmission apparatus having the above configuration and a communication partner will be specifically described with reference to a sequence diagram. FIG.
FIG. 5 is a sequence diagram for explaining a procedure of transmitting and receiving packet transmission performed between the packet transmission device according to the embodiment of the present invention and a communication partner.

In the following description, the packet transmission apparatus having the above configuration is described as a transmitting side, and a communication partner is described as a receiving side. Also, the IP address and port number are saved as the context, and the IP address and port number are also restored on the receiving side, but here, for simplicity,
The description of the IP address and the port number is omitted.

In FIG. 5, the transmitting side transmits UPDATE_FULLHEADER in the first transmission after the start of communication. This UPD
SN of ATE_FULLHEADER is '000' (binary number) and TS is '0'
It is. Then, when transmitting UPDATE_FULLHEADER, the transmitting side sets the SN of the context to “000” and the TS to “0”.
Similarly, on the receiving side, when UPDATE_FULLHEADER is received, the SN of the context is set to “000” and the TS is set to “0”. As a result, the context on the transmitting side matches the context on the receiving side. On the receiving side, the received SN and TS are used directly as the SN and TS of the received data.

In the second to fourth transmissions, the transmitting side sets NON_
Send UPDATE. From the comparison result of the SN to be transmitted and the SN of the context, the transmitting side determines the SN in the second to fourth transmissions.
It is determined that the most significant bit of is not changed to '0', that is, the SN has not been carried, and in NON_UPDATE, only the lower two bits of the SN are transmitted as SN '. In this example, SN is 1
Because there is a regularity that TS increases by 10 every time it increases,
TS is not transmitted in NON_UPDATE.

On the receiving side, in the second to fourth receptions, the SN and TS are restored with reference to the context set in the first reception. In other words, the most significant bit of the received SN is the most significant bit of the SN of the context.
The original 3-bit SN is restored from the compressed 2-bit SN 'by supplementing 0'. Also, the TS is restored by increasing the TS by 10 each time the SN increases by 1. For example, in the fourth reception, 30 is added to the TS'0 'of the context, and the TS of the fourth received data is restored as'30'.

Here, it is assumed that an error has occurred during transmission of NON_UPDATE transmitted for the third time. On the receiving side, in the UDP layer, NON_UPDATE in which the SN received the third time is '2'
Error is detected by CRC etc., and the NON
Discard _UPDATE. Then, on the receiving side, the SN restored from the NON_UPDATE received for the fourth time is “3” in the RTP layer.
, The discontinuity of the SN is detected, and the SN
Requests retransmission of the packet of '2'. That is, the receiving side transmits a retransmission request signal indicating that the SN of the retransmission packet is '2' to the transmitting side.

After the transmitting side transmits the third packet,
After the elapse of the RTT, the retransmission request signal is received by the transmitting side. Here, as shown in FIG. 5, it is assumed that the retransmission request signal is received after the sixth transmission and before the seventh transmission.

As shown in FIG. 5, the context is updated in the fifth transmission / reception during the elapse of the RTT. Therefore, when the transmitting side retransmits the error SN'2 '(decimal number) packet in the seventh transmission, the SN of the retransmitted packet (that is,' 2 ') is changed to the SN of the current context.
(That is, '4'). Therefore,
On the 7th transmission, the transmitting side sends NON_UP sent 3rd time
NON_UPDATE with as retransmission packet of DATE packet
Send SN / TS packets. In other words, the transmitting side has the same data content as the NON_UPDATE packet transmitted the third time, with NON_UPDATE with SN set to '010' and TS set to '20'.
The SN / TS packet is transmitted as a retransmission packet.

Since the retransmission packet received at the seventh time is a packet of NON_UPDATE with SN / TS, the receiving side uses the SN and TS included in the retransmission packet as they are in the received data.
SN and TS. On the receiving side, if the retransmission packet is NON_UP
Since the packet is DATE with SN / TS, the context is not updated at the time of the seventh reception. That is, the context is maintained as SN'100 'and TS'40'.

Therefore, the transmitting side is up in the eighth transmission.
Even if NON_UPDATE is sent instead of DATE, the receiver can correctly restore the header from NON_UPDATE by referring to the context.

In other words, when the SN of the retransmission packet is smaller than the SN of the current context, the transmitting side uses NON_UPDATE with SN / T instead of the UPDATE packet.
By transmitting the S packet as a retransmission packet, the packet to be transmitted next to the retransmission packet can be a NON_UPDATE packet instead of an UPDATE packet.

Since the data amount of the header portion of NON_UPDATE is smaller than that of UPDATE, the transmitting side transmits the retransmission packet to NON_UPDA
By using TE with SN / TS packets, it is possible to prevent a reduction in header compression efficiency and a reduction in packet transmission efficiency.

As described above, according to the present embodiment, the UPDA
Takes a header structure similar to TE (ie, includes SN and TS), but uses a special header (ie, NON_UPDATE with
SN / TS) is used as the header of the retransmission packet. Therefore, even if the packet to be transmitted next to the retransmission packet is not an UPDATE packet but a NON_UPDATE packet, the packet receiving side can correctly restore the header from the NON_UPDATE.

In the above embodiment, a case has been described in which the data transmission apparatus is used in a wireless communication system. However, the present invention is not limited to this, and the data transmission apparatus according to the above embodiment may employ a wired communication system. It can also be used in systems.

In the above embodiment, the case where packet transmission is performed as a packet transmission device has been described. However, the present invention is not limited to this, and it is also possible to perform this packet transmission as software. For example, a program for performing the above packet transmission is stored in a ROM (Read Only) in advance.
Memory) and store the program in the CPU (Cent
ral Processor Unit). Further, the program for performing the packet transmission is stored in a computer-readable storage medium, and the program stored in the storage medium is stored in a RAM (Random Access Memory) of the computer.
Access Memory), and the computer may be operated according to the program. In such a case, the same operation and effect as those of the above embodiment are exhibited.

Further, the program for performing the packet transmission may be stored in a server, the program stored in the server may be transmitted to the client in response to a request from the client, and the program may be executed on the client. In such a case, the same operation and effect as those of the above embodiment are exhibited.

The packet transmission device according to the above embodiment can be mounted on an image distribution device that distributes image data. In such a case, the same operation and effect as those of the above embodiment are exhibited.

In the above embodiment, the case where retransmission control is performed in the RTP layer has been described. However, the present invention is not limited to this. The present invention is also applicable to the case where retransmission control is performed in a layer other than the RTP layer. Applicable.

In the above embodiment, RTP, UDP, and IP are used in combination as the protocol. However, the present invention is not limited to this, and the present invention is applicable to packet communication using other protocols. is there.

[0089]

As described above, according to the present invention,
Even if the packet to be transmitted next to the retransmission packet is not an UPDATE packet but a NON_UPDATE packet, the NON_UPDA
Since the header can be correctly restored from TE, even when header compression and retransmission control are used together, the header compression efficiency and packet transmission efficiency do not decrease, and the header can be correctly restored at the receiving side. it can.

[Brief description of the drawings]

FIG. 1 is a schematic diagram showing the configuration of a special packet after header compression

FIG. 2 shows a case where a special packet after header compression is used.
Sequence diagram for explaining the procedure for sending and receiving ROHC

FIG. 3 is a block diagram showing a configuration of a packet transmission device according to one embodiment of the present invention.

FIG. 4 is a block diagram showing a configuration of a transmission packet generation unit of the packet transmission device according to one embodiment of the present invention.

FIG. 5 is a sequence diagram for explaining a procedure of transmitting and receiving packet transmission performed between the packet transmission apparatus according to the embodiment of the present invention and a communication partner

FIG. 6 is a schematic diagram showing a configuration of a packet.

FIG. 7 is a schematic diagram showing a configuration of a packet after header compression.

FIG. 8 is a sequence diagram for explaining a procedure for transmitting and receiving a packet performed using ROHC.

FIG. 9 is a sequence diagram for explaining a transmission / reception procedure when ROHC is used together with retransmission control.

FIG. 10 is a sequence diagram for explaining another transmission / reception procedure when ROHC is used together with retransmission control.

[Explanation of symbols]

 Reference Signs List 101 RTP packet generator 102 switch 103 buffer 104 UDP packet generator 105 IP packet generator 106 transmit packet generator 107 transmitter 108 antenna 109 retransmission request signal receiver 201 header separator 202 compression method selector 203 buffer 204 header compressor 205 Compressed header addition unit

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Akihiro Miyazaki 1006 Kazuma Kadoma, Osaka Prefecture Matsushita Electric Industrial Co., Ltd. Terms (reference) 5K030 GA03 GA11 HA08 JA05 KA03 KX13 5K034 AA01 AA06 BB06 FF02 HH01 HH02 HH18

Claims (6)

[Claims] 1. A packet transmission apparatus used in a packet communication system in which a header is compressed and decompressed using reference information, comprising: retransmission means for retransmitting a packet in response to a retransmission request from a communication partner; Selecting means for selecting, as a header of a retransmitted packet, a header which is restored without referring to the reference information on the communication partner side and is not used for updating the reference information when retransmitting the packet transmitted before the update of the information; , A packet transmission device. 2. The method according to claim 1, wherein the selecting unit restores the reference information without referring to the reference information on the communication partner side when the sequence number of the retransmission packet is smaller than the sequence number of the reference information, and does not use the reference information for updating. 2. The packet transmission device according to claim 1, wherein the header is selected as a header of the retransmission packet. 3. An image distribution apparatus comprising the packet transmission apparatus according to claim 1 or 2. 4. A retransmission step of retransmitting a packet in response to a retransmission request from a communication partner, and retransmitting a packet transmitted before updating reference information used for header compression and decompression, on the communication partner side. A header that is restored without reference information and that is not used to update the reference information,
A selection step of selecting as a header of a retransmission packet;
A computer-readable storage medium storing a program for causing a computer to execute the program. 5. A retransmission step of retransmitting a packet in response to a retransmission request from a communication partner, and retransmitting a packet transmitted before updating reference information used for header compression and decompression, on the communication partner side. A header that is restored without reference information and that is not used to update the reference information,
A selection step of selecting as a header of a retransmission packet;
Characterized by comprising: storage means for storing a program for causing a computer to execute the program; and transmission means for transmitting the program to the client in response to a request from the client. 6. When a packet receiving side detects an error in a received packet, the packet transmitting side transmits a packet retransmission request to the packet transmitting side, and the packet transmitting side uses the packet for header compression and decompression. When retransmitting a packet transmitted before the update of the reference information, the packet receiving side should select a header that is restored without reference to the reference information and that is not used for updating the reference information as a header of the retransmission packet. Characteristic packet transmission method.