WO2014087830A1

WO2014087830A1 - Packet-forwarding control system and method

Info

Publication number: WO2014087830A1
Application number: PCT/JP2013/080964
Authority: WO
Inventors: 一範小澤
Original assignee: 日本電気株式会社
Priority date: 2012-12-07
Filing date: 2013-11-11
Publication date: 2014-06-12

Abstract

In accordance with detected congestion, first data that is contained in a received audio/video packet and encoded at a first bit rate is decoded and then re-encoded at a second bit rate to generate second data, and a packet containing said second data is forwarded in place of the packet containing the first data.

Description

Packet transfer control system and method

The present invention relates to packet transfer control, and more particularly to packet transfer control for storing audio data.

In recent years, the capacity and speed of mobile networks have been increased, and systems such as LTE (Long Term Evolution) and EPC (Evolved Packet Core) have begun to be introduced. In the conventional system, the line exchange for voice call and video phone call and the packet exchange for sending data are composed of separate systems. However, in the LTE / EPC system, the voice call data and the video phone data are connected to the same packet communication path. And content distribution data and so-called data signals (application data, document data, photo data, etc.) are sent together. Furthermore, as mobile terminals, not only conventional so-called Galapagos mobile phones but also so-called smart devices such as smartphones and tablets are accelerating. As a result, an enormous amount of signals that cannot be compared with the conventional system flows through the packet communication path.
Up to now, packet transfer control devices (for example, EPC P-GW: Packet data network Gateway and S-GW: Serving Gateway), QCI (Quality Class Identifier), MBR (Maximum Bit Rate), GR (R) Parameters such as the above are set to control QoS (Quality of Service) for each packet.
However, since the network bandwidth of the entire LTE / EPC fluctuates in time depending on the traffic fluctuation, it is difficult for the packet transfer control device to detect the timing of network congestion. . In particular, there has been a problem that it is impossible to deal with a case in which traffic is drastically changed or increased due to an unexpected event, the introduction of popular content, the start of new use by a heavy user, or the like.
Therefore, in the future, when it starts as a real-time communication service such as high-quality voice VoIP and high-resolution videophone using LTE / EPC packet communication path, if the network is congested, the terminal will be used at the time of voice call by VoIP. There is a risk that problems related to deterioration of QoE (Quality of Experience) on the terminal side may occur, such as sound being interrupted or video being disturbed or frozen at the terminal during a videophone call.
Patent Document 1 is cited as a document describing a technique related to the present invention.

JP-A-2004-320452

The present invention has been made in view of such a situation, and the problem to be solved by the present invention is that the transport of packets storing voice data completely stops even when congestion occurs in the network. It is to provide a packet transfer control technology that can continue without interruption.

In order to solve the above-mentioned problem, the present invention has, as one aspect, when transferring a packet storing at least one of audio data and video data received from one of the two nodes to the other node. Congestion detection is performed on at least one of the uplink and downlink packet communication paths between the nodes, and the first data encoded at the first bit rate stored in the received packet according to the congestion detection Is generated, and re-encoded second data is generated at a second bit rate different from the first bit rate, and a packet storing the second data is converted into a packet storing the first data. A packet transfer control system characterized by transferring data on behalf of the device is provided. According to another aspect of the present invention, when a packet storing at least one of audio data and video data received from one of the two nodes is transferred to the other node, the uplink direction between the two nodes And detecting the congestion for at least one of the packet communication paths in the downstream direction, and decoding the first data encoded at the first bit rate stored in the received packet in response to the detection of the congestion, Second data re-encoded at a second bit rate different from the first bit rate is generated, and a packet storing the second data is transferred instead of a packet storing the first data A packet transfer control method is provided.

According to the present invention, even when congestion occurs, the re-encoded packet is transferred instead of the received packet by changing the bit rate of the voice data, so that transmission of the voice data is completely interrupted. Can do.

FIG. 1 is a diagram for explaining a communication system according to a first embodiment of the present invention.
FIG. 2 is a block diagram of the packet transfer control device 190 according to the first embodiment of this invention.
FIG. 3 is a block diagram of the transcoder 220.
FIG. 4 is a block diagram of the packet transfer control device 190 according to the second embodiment of this invention.
FIG. 5 is a block diagram of portable terminal 170 in the second embodiment of the present invention.

A first embodiment of the present invention will be described with reference to FIGS. FIG. 1 shows a configuration of a first embodiment of a communication system according to the present invention. Here, a configuration in which a mobile LTE / EPC packet network is used as the network is shown. Further, FIG. 1 shows a configuration in which the packet transfer control device 190 uses P-GW (Packet data network Gateway), S-GW (Serving Gateway), or both. The mobile terminal is assumed to be a so-called Galapagos mobile phone, a smartphone, or a tablet. FIG. 1 shows an example in which a user A and a user B connect a mobile terminal to a network and make a call between mobile phones. FIG. 1 shows that the user A uses the mobile terminal 170 to connect the mobile network 150 and the IMS. A configuration is shown in which a VoIP voice call is made with user B's mobile terminal (not shown) via a network 130 via a partner network (not shown). Note that the same configuration as that in FIG. 1 can be realized for a videophone that uses both video and audio, instead of a voice call (voice call).
In addition, FIG. 1 illustrates a configuration for detecting congestion by extracting congestion information stored in an uplink packet (that is, in the direction of the packet transfer control device 190) from the eNodeB device 194 as an example of congestion detection. Here, as an example of congestion information, a configuration for detecting congestion by receiving congestion information by ECN (Explicit Connection Notification) will be described.
Here, when the eNodeB device 194 detects a congestion state in the downlink wireless network, the CE (Congestion) is set in the ECN field of the IP header portion of the uplink packet transmitted from the eNodeB to the packet transfer control device 190. (Experence) bit is sent to the packet transfer control device 190. When the packet transfer control device 190 detects that the CE bit is in the ECN field of the IP header part in the packet received from the eNodeB, Let it be detected that the network in the direction is congested.
In FIG. 1, when the mobile terminal 170 sends out the IP address and RTP port number of the partner terminal from the mobile terminal 170 as a voice call connection request, the mobile terminal 170 passes through the eNodeB device 194 and the packet transfer control device 190 to receive the IMS ( It is transferred to at least one of the SIP server 110 and the PCRF (Policy and Charging Rules Function) device 191 arranged in the IP Multimedia Subsystem (IP) network 130. Furthermore, the mobile terminal 170 adds at least one parameter among parameters such as voice call traffic, desired QoS class, MBR (Maximum Bit Rate), GBR (Guaranteed Bit Rate), and the like via the packet transfer control device 190. It is also possible to notify at least one of the SIP server 110 and the PCRF device 191.
The SIP server 110 receives a connection request signal for a voice call, sends a connection request to a partner terminal (not shown) via a partner network (not shown), and receives an Ack signal from the partner terminal. Then, the Ack signal is transmitted to the mobile terminal 170 via the packet transfer control device 190 and the eNodeB device 194, and is received by the mobile terminal 170, whereby the control signal for the voice call is exchanged. Here, not only the IP address and RTP port number of the mobile terminal 170 but also at least one of the parameters of voice call traffic, desired QoS class, MBR (Maximum Bit Rate), GBR (Guaranteed Bit Rate) from the counterpart terminal. Can also be sent out. These parameters can be transmitted not only to the SIP server 110 but also to the PCRF device 191.
The PCRF device 191 inputs the voice call traffic, the IP address and port number of the mobile terminal 170 from the packet transfer control device 190 for at least one of the upstream and downstream directions. If necessary, parameters such as a desired QoS class, MBR (Maximum Bit Rate), GBR (Guaranteed Bit Rate), and the like are also input from the packet transfer control device 190. Furthermore, the PCRF device 191 identifies a user from the IP address of the mobile terminal, and reads user profile information from the user database owned by the PCRF device 191. Here, the user profile information includes, for example, user contract information.
Next, the PCRF device 191 generates parameters for QoS control based on the user profile information and the QoS information. The parameter for QoS control is at least one of QCI (Quality Class Identifier) which is a value for identifying a QoS class, ARP (Allocation and Retention Priority) indicating the priority of resource reservation and retention, MBR, and GBR. . Here, MBR and GBR are used as they are when received from the packet transfer control device 190, and are generated by the PCRF device 191 when there is no reception. The PCRF device 191 generates at least one of these four types of parameters for each of the uplink direction and the downlink direction, and outputs them to the packet transfer control device 190. For the mobile terminal 170, the user profile is “Premier Member”, “QoS is not allowed to be downgraded during network congestion”, and the traffic is a voice call. Specifically, for example, QCI = 1 (Conversational Voice), ARP = 2, GBR = 12.2 kbps, MBR = 22.8 kbps are set for both uplink and downlink. Here, as an example, the AMR-NB audio codec is used in the portable terminal 170, and the above parameter values are used. As another configuration, an AMR-WB audio codec can be used, but in this case, the value of GBR can be changed.
Next, the configuration of the packet transfer control device 190 will be described with reference to FIG.
FIG. 2 is a block diagram showing the configuration of the packet transfer control device 190. In the figure, the control unit 211 relays a control signal from the mobile terminal 170 to the SIP server 110 and relays a control signal and an Ack signal from the SIP server 110 to the mobile terminal 170. Further, at least one of four types of parameters, QCI, ARP, MBR, and GBR, is input from the PCRF device 191 for each traffic data. Here, in the present embodiment, at least one of four types of parameters for each of the uplink direction and the downlink direction of the voice call traffic is input from the PCRF device 191.
The congestion detection unit 200 receives the IP header information from the packet transfer unit 176 for the uplink packet received by the packet transfer unit 176 from the eNodeB device 194 in FIG. 1, and sets an ECN (Explicit Connection Notification) field in the IP header unit. To check. When the CE bit is set in the ECN field, it is detected that the downlink direction from the eNodeB device 194 to the mobile terminal 170 is in a congestion state, and the downlink congestion detection information is output to the rate setting unit 230. Further, the downstream congestion detection information is output to the PCRF device 191 of FIG.
When the congestion detection information is input from the control unit 211 in FIG. 2, the PCRF device 191 in FIG. 1 determines at least one of user profile information, QoS parameters, and operator policy for the mobile terminal 170 currently connected to the eNodeB device 194. Check one.
Here, the operator policy is a setting determined by a telecommunications carrier that manages and operates the network 150. In the present invention, the operator policy is a setting that determines a policy for dealing with congestion in the network. In the present embodiment, when the occurrence of congestion is detected in the network, processing for forcibly reducing GBR or MBR for a packet sent by a user set as a standard user in the contract information included in the user profile information On the other hand, the packet sent by the user set as the premium member in the user profile information is transferred as it is.
Here, the case where these are checked is shown. In the user profile information, it is a user who has a standard fee contract and is not a heavy user who wastes packets. According to the operator policy, in the case of voice call or TV phone communication, if the network is congested, the QoS parameter It is determined to reduce at least one of the GBR and MBR and reduce the rate of at least one of video and audio. Here, as described above, the QoS parameters of the mobile terminal 170 are QCI = 1 (Conversational Voice), ARP = 2, GBR = 12.2 kbps, and MBR = 22.8 kbps for both uplink and downlink. Since the downlink network detects congestion and is a voice call, the downlink QCI and ARP are left unchanged and only the downlink GBR and MBR are changed. GBR = 8 kbps and downlink MBR = 12.2 kbps. Note that the upstream QoS parameter is not changed. The PCRF device 191 outputs the changed OoS parameter to the rate setting unit 230 and the transfer control unit 188 via the control unit 211 of FIG.
Returning to FIG. 2, the rate setting unit 230 inputs the congestion detection information from the congestion detection unit 200, and inputs the changed QoS parameter from the control unit 211. Based on the changed QoS parameter, the rate setting unit 230 satisfies the condition of GBR = 8 kbps or less in the downlink direction among the eight types of bit rates (modes) of the AMR-NB audio codec as the changed rate. 7.95 kbps, an instruction to change the downlink rate to 7.95 kbps, and an instruction not to change the uplink rate at 12.2 kbps are output to the transcoder unit 220.
Next, the configuration of the transcoder unit 220 will be described with reference to FIG. The transcoder unit 220 includes demultiplexing / multiplexing units 280_1 and 280_2, an image transcoder 281 and an audio transcoder 282. Since the present embodiment is a voice call, only the voice transcoder 282 is used. The demultiplexing / multiplexing unit 280_1 inputs 7.95 kbps as downlink rate information after the change, and an instruction not to change the uplink rate from the rate setting unit 230, and outputs it to the audio transcoder 282. Downstream and upstream packets are input from the packet transfer control device 190 and output to the voice transcoder 282.
The audio transcoder 282 transcodes the downlink audio compression encoded stream so as to convert the rate from 12.2 kbps before the change to 7.95 kbps, and sends the converted stream to the packet transfer unit 176. Output. Here, this conversion is performed by once decoding the 12.2 kbps audio compression-encoded stream with a 12.2 kbps AMR-NB audio decoder and re-encoding with a 7.95 kbps AMR-NB audio encoder. Since the upstream direction remains 12.2 kbps and no conversion is performed, the audio transcoder is passed through the 12.2 kbps audio compression-coded stream in the upstream direction and is output as it is.
Returning to FIG. 2, the transfer control unit 188 inputs a QoS parameter from the PCRF device 191 via the control unit 211. And about the QoS parameter of a downlink direction, although QCII and ARP are not changed, it recognizes that GBR and MBR are changed. Then, the audio compression coded stream input from the transcoder unit 220 is packetized and then transferred based on the changed GBR and MBR. In this embodiment, since the audio compression coded stream is converted to 7.95 kbps below the changed GBR in the audio transcoder, the packet is transferred without delaying the packet. Become. Further, RTP / UDP / IP is used as a packetization protocol. On the other hand, in the upstream direction, it is recognized that there is no change in the QoS parameter, and the input packet storing the audio compression coded stream is transferred as it is. It is assumed that RTP / UDP / IP is used as an upstream packet protocol.
This is the end of the description of the first embodiment of the present invention, but various modifications are possible.
In the present embodiment, a case where a voice call is performed is shown, but real-time communication can be used for other services with the same configuration. For example, the same configuration can be realized for a TV phone or the like.
At that time, the packet (video packet) storing the video data is not intended only for the packet (audio packet) storing the audio data of the videophone, but instead of or in addition to the audio packet. It is good also as an object of processing. In other words, in the above description, a new audio data stored in the received audio packet is decoded, re-encoded at a lower rate than the audio data rate, and the generated audio data is stored. Although packet transfer control is performed to transfer voice packets in place of received voice packets, the same packet transfer control is performed on video packets in parallel with or in place of such packet transfer control. Decode the video data stored in the received video packet, re-encode at a rate lower than the video data rate to generate video data, and create a new video packet to store the generated video data, Packet transfer control for transferring in place of the received video packet may be performed.
Although ECN information is used to detect congestion, other information can also be used.
The congestion detection unit 200, the rate setting unit 230, and the transcoder 220 are built in the packet transfer control device 190, but some or all of them may be external devices.
Further, the function of the PCRF device 191 can be built in the packet transfer device 190.
The mobile network 150 may be a 3G network, and the packet transfer control device 190 may be an SGSN (Serving GPRS Support Node) or a GGSN (Gateway GPRS Support Node).
Next, a second embodiment of the present invention will be described. In the second embodiment, the configurations of the packet transfer control device 190 and the portable terminal 170 are different, and the other configurations are the same as those of the first embodiment shown in FIG. FIG. 4 shows the configuration of the packet transfer control device 190 in the second embodiment, and FIG. 5 shows the configuration of the portable terminal 170 in the second embodiment. In FIG. 4, the constituent elements having the same numbers as those in FIG. 2 perform the same operations as those in FIG.
In FIG. 4, the bandwidth calculation unit 205 calculates at least one of the downlink and uplink bands for the network to which the mobile terminal 170 is connected at the time of session connection or at predetermined time intervals. Here, a case where a downstream band is calculated will be described.
The bandwidth calculation unit 205 calculates using both the packet transmitted from the packet transfer unit 176 to the mobile terminal 170 and the reply packet from the mobile terminal 170. First, the bandwidth calculation unit 205 instructs the packet transfer unit 176 in FIG. 3 to transmit a plurality of specific packets (probe packets) to the mobile terminal 170 at a predetermined timing. In accordance with the instruction, the packet transfer unit 176 directs a plurality of specific packets to the mobile terminal 170 at the timing when the instruction is received, and continuously transmits the packets in a predetermined order. Here, the plurality of packets indicates two or more packets. The sending order is a predetermined order. For example, packets are sent in order from a packet having a small data size to a packet having a large data size. Further, the time interval between the packet and the next packet is a predetermined time interval. Here, for example, RTP / UDP / IP is used as the protocol.
Next, the packet transfer unit 176 receives a reply packet from the portable terminal 170 as a result of sending the plurality of packets. Here, the reply packet includes, for example, the packet number that can be received below the threshold with respect to the differential delay, the data size of the packet, the time when the packet was transmitted from the server, the packet, Include information such as the time received by the mobile terminal.
The packet transfer unit 176, from the reply response signal received from the mobile terminal 170, the number of the packet that the mobile terminal 170 was able to receive within the threshold value of the delay difference, the transmission time from the packet transfer control device 190, and the mobile terminal 170 The information of the reception time at is extracted and output to the bandwidth calculation unit 205.
The bandwidth calculation unit 205 receives the above information from the packet transfer unit 176 and calculates the network bandwidth. Specifically, the packet number that can be received by the mobile terminal 170 below the delay difference threshold, the data size of the packet, the transmission time of the packet from the packet transfer control device 190, the mobile terminal 170 of the packet Is received, and the downstream bandwidth W_d is calculated according to the following equation 1.
D (N) / W_d = R (N) -R (N-1) ... Formula 1
In Expression 1, D (N) represents the data size of the Nth packet transmitted from the packet transfer control device 190. Here, N and D (N) are the packet number and data size that can be received by the mobile terminal 170 at or below the delay difference threshold value, respectively, and are information extracted from the reply response signal from the mobile terminal 170. is there. R (N) is the reception time at the portable terminal 170 of the Nth packet sent from the packet transfer control device 190, and R (N-1) is sent N-1th from the packet transfer control device 190. The reception time of the packet at the mobile terminal 170 is shown.
Next, the downstream band measurement value W_d is temporally smoothed by the following equation 2 to calculate B (n) _d.
B (n) _d = (1-β) * B (n−1) _d + βW_d Equation 2
Here, B (n) _d indicates a downstream bandwidth calculation value after smoothing at the n-th time, and β is a constant in a range of 0 <β <1. Note that the time direction smoothing according to Equation 2 may not be performed if unnecessary.
The packet transfer unit 176 sends information necessary for calculating the network bandwidth to the portable terminal 170 only at the time of session connection or at predetermined time intervals based on the time of session connection and the time of session connection. A response signal is received from the mobile terminal.
The bandwidth calculation unit 205 calculates B (n) _d at predetermined time intervals, for example, and outputs these to the congestion detection unit 210.
The congestion detection unit 210 performs the following determination to detect congestion.
(1) When the downlink bandwidth calculation value B (n) _d is compared with the downlink GBR + α of the voice call by the mobile terminal 170, if B (n) _d ≧ GBR + α, the mobile terminal 170 is congested in the downlink direction. Is notified to the rate setting unit 215 and to the PCRF device 191 of FIG. 1 via the control unit 211. Here, α is a predetermined numerical value.
(2) Comparing the downlink bandwidth calculation value B (n) _d with the downlink GBR + α of the voice call by the mobile terminal 170, if B (n) _d <GBR + α, the mobile terminal 170 is congested in the downlink direction. Is notified to the rate setting unit 215 and to the PCRF device 191 of FIG. 1 via the control unit 211. Here, α is a predetermined numerical value. Further, in this case, the numerical value of B (n) _d is notified to the PCRF device 191 via the control unit 211.
When the congestion detection information and the value of B (n) _d are input from the control unit 211 of FIG. 2, the PCRF device 191 of FIG. 1 determines the user profile information and the QoS parameters for the mobile terminal 170 currently connected to the eNodeB device 194. And at least one of the operator policies is checked.
Here, the case where these are checked is shown. In the user profile information, it is a user who has a standard fee contract and is not a heavy user who wastes packets. According to the operator policy, in the case of voice call or TV phone communication, if the network is congested, the QoS parameter It is determined to reduce at least one of the GBR and MBR and reduce the rate of at least one of video and audio. Here, as described above, the QoS parameters of the mobile terminal 170 are QCI = 1 (Conversational Voice), ARP = 2, GBR = 12.2 kbps, and MBR = 22.8 kbps for both uplink and downlink.
Considering that the downstream network has detected congestion, the downstream bandwidth calculation value is B (n) _d, and that it is a voice call, the downstream QCI and ARP remain unchanged. Only the downlink GBR and MBR are changed. For example, the downlink GBR is changed to BBR ≦ B (n) _d, and the downlink MBR is changed to GBR <MBR <22.8 kbps. Note that the upstream QoS parameter is not changed. The PCRF device 191 outputs the changed OoS parameter to the rate setting unit 215 and the transfer control unit 188 via the control unit 211 of FIG.
The rate setting unit 215 receives the congestion detection information from the congestion detection unit 210 and the changed QoS parameter from the control unit 211. Based on the changed QoS parameter, the rate setting unit 215, as the changed rate, among the eight bit rates (modes) of the AMR-NB audio codec, the bit rate that satisfies the conditions below the GBR in the downlink direction Set. Here, it is assumed that 6.7 kbps is set as the bit rate that satisfies this condition. Further, an instruction to change the downlink rate to 6.7 kbps and an instruction to not change the uplink rate at 12.2 kbps are output to transcoder section 220.
Next, FIG. 5 is a block diagram illustrating a configuration of the mobile terminal 170. In FIG. 5, a packet transmitting / receiving unit 250 generates a reply response packet for the received probe packet and sends it to the network. Here, the reply response packet is generated as follows, for example.
The packet transmission / reception unit 250 receives each of the plurality of probe packets transmitted from the packet transfer unit 176 in FIG. 2 and outputs the received packet to the delay difference determination unit 255.
The delay difference discriminating unit 255 first measures the delay time T (n) for each packet by the following equation 3.
T (n) = R (n) -S (n) ... Formula 3
Here, T (n), R (n), and S (n) indicate the delay time of the nth packet, the reception time of the nth packet, and the transmission time of the nth packet, respectively. .
Further, the delay difference τ (n) between the packets is calculated by the following equation 4.
τ (n) = T (n) −T (n−1) Equation 4
Here, τ (n) represents the delay difference of the nth packet.
Next, using τ (n), it is determined whether or not the delay difference exceeds a predetermined threshold value. If τ (N) ≧ Th3, it is determined that the delay difference has exceeded the threshold value in the Nth packet. Here, Th3 is a predetermined threshold value. Then, the packet number N immediately after the delay difference exceeds the threshold value is output to the packet transmitting / receiving unit 250.
The packet transmission / reception unit 250 receives the packet number N from the delay difference determination unit 255, the packet number N immediately after the delay difference exceeds the threshold, the data size of the Nth packet, the N−1th packet The data size, the reception time and transmission time of each of the Nth and N-1th packets are stored in the payload of the reply response packet, and then directed to the packet transfer control device 190 via the eNodeB 194 in FIG. Send it out.
Here, the threshold value Th3 may be determined in advance, or may be determined each time after looking at a series of values of τ (n).
Also, other methods can be used as the discrimination method. For example, T (n) may be compared with a threshold value set according to a predetermined rule, and n may be returned as N when the threshold value is exceeded.
In FIG. 5, a voice codec 253 is used during a voice call. Since the present embodiment is a voice call, the image codec 252 and the display unit 256 are not used. As another embodiment, these are used in the case of a TV phone configuration.
In the second embodiment, the congestion in the downlink direction is determined as follows.
(1) The packet transfer unit 176 sends a probe packet to the mobile terminal 170 in accordance with an instruction from the bandwidth calculation unit 205.
(2) Upon receiving the probe packet, the mobile terminal 170 receives the packet number N immediately after the delay difference exceeds the threshold, the data size of the Nth packet, the data size of the N−1th packet, A reply packet storing the packet reception time and transmission time in the payload is generated, and the reply packet is transmitted to the packet transfer control device 190 via the eNodeB device 194.
(3) When the packet transfer control device 190 receives a reply packet from the portable terminal 170, the bandwidth calculation unit 205 obtains the value stored in the received reply packet, that is, the packet immediately after the delay difference exceeds the threshold value. The downstream band W_d is calculated by applying the number N, the data size of the Nth packet, the data size of the (N-1) th packet, the reception time and transmission time of each packet to Equation 1.
(4) The band calculation unit 205 calculates the smooth value B (n) _d by applying the calculated downstream band W_d to Equation 2.
(5) The congestion detection unit 210 determines whether there is congestion in the downstream direction based on B (n) _d.
(6) After the congestion is detected, the packet is transferred in the same manner as in the first embodiment.
Note that the bandwidth calculation unit 205 performs an operation corresponding to the delay difference determination unit 255 when performing the congestion determination in the upstream direction.
This is the end of the description of the second embodiment of the present invention, but various modifications are possible.
Another algorithm may be used as the band calculation algorithm in the band calculation unit 205 in FIG. Although the bandwidth is calculated based on the reply response signal from the mobile terminal, the bandwidth can also be calculated based on the measured delay amount with the mobile terminal.
A method for estimating a bandwidth using a response signal from a mobile terminal without using a probe packet, instead of calculating a bandwidth by sending a probe packet for bandwidth measurement from the packet transfer unit 176 to the mobile terminal 170. Can also be used. In this case, the sending of the probe packet from the packet transfer unit 176 in FIG. 4 and the delay difference determination unit 255 in FIG. 5 are not necessary.
In this embodiment, the bandwidth calculation unit 205, the congestion detection unit 210, and the rate setting unit 215 are built in the packet transfer control device 190, but at least one of them can be an external device.
This application claims the priority on the basis of Japanese application Japanese Patent Application No. 2012-267871 for which it applied on December 7, 2012, and takes in those the indications of all here.

Claims

When a packet storing at least one of audio data and video data received from one of the two nodes is transferred to the other node, congestion occurs in at least one of the upstream and downstream packet communication paths between the two nodes. In response to detection of congestion, the first data encoded at the first bit rate stored in the received packet is decoded, and a second data different from the first bit rate is decoded. A packet transfer control system, wherein second data re-encoded at a bit rate is generated, and a packet storing the second data is transferred instead of a packet storing the first data.
Means for changing the QoS parameters of the received packet;
The packet transfer control system according to claim 1, further comprising means for determining the second bit rate based on the first bit rate and the changed QoS parameter.
The QoS parameters include a QCI (Quality Class Identifier) that is a value for identifying a QoS class, an ARP (Allocation and Retention Priority) indicating a priority for securing and retaining resources, an MBR (Maximum Bit Rate), and a GBR (Guarante Guate). 3. The packet transfer control system according to claim 2, wherein the packet transfer control system is at least one of
The packet transfer control system according to any one of claims 1 to 3, wherein occurrence of congestion is detected based on ECN (Explicit Congestion Notification) stored in the packet.
5. The probe packet is transmitted to a terminal that is one of two nodes that establish a packet communication path, and occurrence of congestion is detected based on a response to the probe packet. The packet transfer control system according to any one of the above.
When a packet storing at least one of audio data and video data received from one of the two nodes is transferred to the other node, congestion occurs in at least one of the upstream and downstream packet communication paths between the two nodes. In response to detection of congestion, the first data encoded at the first bit rate stored in the received packet is decoded, and a second data different from the first bit rate is decoded. A packet transfer control method, wherein second data re-encoded at a bit rate is generated, and a packet storing the second data is transferred instead of a packet storing the first data.
Means for changing the QoS parameters of the received packet;
The packet transfer control method according to claim 6, further comprising means for determining the second bit rate based on the first bit rate and the changed QoS parameter.
The QoS parameters include a QCI (Quality Class Identifier) that is a value for identifying a QoS class, an ARP (Allocation and Retention Priority) indicating a priority for securing and retaining resources, an MBR (Maximum Bit Rate), and a GBR (Guarante Guate). The packet transfer control method according to claim 7, wherein the packet transfer control method is at least one of the following.
The packet transfer control method according to any one of claims 6 to 8, wherein the occurrence of congestion is detected based on ECN (Explicit Congestion Notification) stored in the packet.
9. The probe packet is transmitted to a terminal that is one of two nodes that establish a packet communication path, and occurrence of congestion is detected based on a response to the probe packet. The packet transfer control method according to any one of the above.