WO2014087764A1

WO2014087764A1 - Terminal and communication system

Info

Publication number: WO2014087764A1
Application number: PCT/JP2013/079330
Authority: WO
Inventors: 一範小澤
Original assignee: 日本電気株式会社
Priority date: 2012-12-03
Filing date: 2013-10-23
Publication date: 2014-06-12

Abstract

In order to prevent any deterioration in quality of experience (QoE), this terminal, which is connected to a network and transmits and receives media-data-containing packets over said network, is provided with the following: a congestion detection unit that detects network congestion on the basis of received downlink packets; and a packet transmission/reception unit that, if the congestion detection unit has detected network congestion, uses the reverse direction of the network to send an opposing terminal a request to change the rate of the abovementioned media data.

Description

端末および通信システムTerminal and communication system

　本発明は、ネットワークに接続される携帯端末などの端末に関し、特に、パケットにより映像、音声、オーディオ通信の輻輳制御を行なう通信システムに使用される端末に関する。 The present invention relates to a terminal such as a portable terminal connected to a network, and more particularly to a terminal used in a communication system that performs congestion control of video, audio, and audio communication using packets.

　近年、モバイルネットワークでも大容量化、高速化が進展し、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）やＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）などのシステムが導入開始されている。
　従来の通信システムでは、音声通話やＴＶ電話を行なう回線交換と、データを流すパケット交換とは別々のシステムから構成されていた。それに対して、ＬＴＥ／ＥＰＣシステムでは、同じパケット通信路に、音声通話データやＴＶ電話データやコンテンツ配信データなどといわゆるデータ信号（アプリケーションデータ、ドキュメントデータ、写真データなど）とを一緒に流すことを特徴とする。さらに、携帯端末としては、従来型のいわゆるガラパゴス携帯だけでなく、スマートフォンやタブレットなどの、いわゆるスマートデバイスの普及が加速化している。
　これにより、ＬＴＥ／ＥＰＣシステムでは、従来の通信システムとは比較にならない膨大なデータ量のパケットが、パケット通信路を流れることになる。
　そのため、ＬＴＥ／ＥＰＣシステムにおいては、パケット転送レート制御を行う必要がある。例えば、特開２００４−３２０４５２号公報（特許文献１）は、パケット転送レート制御を行うパケット転送制御装置を開示している。
　この特許文献１に開示されたパケット転送制御装置は、回線輻輳状態判定部と、転送レート制御決定部と、パケット加工処理部とを備える。回線輻輳状態判定部は、複数パケットに対しパケットサイズの累積値である累積パケット総量にもとづき、バックボーン回線が輻輳かどうかを判別する。転送レート制御決定部は、バックボーン回線が輻輳状態との判定のときは、しきい値を下回るホップカウント値を有する１以上のＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）フローを選択する。パケット加工処理部は、転送レート制御決定部で選択されたＩＰフローに対し、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）パケットか否かを判別し、ＴＣＰパケットの場合は、次に述べる３種のパケット加工処理を施す。
　具体的には、１）サーバからの発信パケットの場合は、ＴＣＰヘッダにＥＣＮ（Ｅｘｐｌｉｃｉｔ　Ｃｏｎｇｅｓｔｉｏｎ　Ｎｏｔｉｆｉｃａｔｉｏｎ）のＣＥ（Ｃｏｎｇｅｓｔｉｏｎ　Ｅｘｐｅｒｉｅｎｃｅ）ビットをセットする。２）クライアントから返信される返信パケットの場合は、ＴＣＰヘッダの広告ウィンドゥサイズを縮小変更する。３）確認応答（Ａｃｋ）パケットの場合は、当該パケットのバックボーン回線に対する送出タイミングを遅らせる。なお、ＴＣＰパケットでない場合は、パケットを廃棄する。 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 conventional communication systems, circuit switching for voice calls and videophone calls and packet switching for sending data are configured as separate systems. On the other hand, in the LTE / EPC system, voice call data, videophone data, content distribution data, and so-called data signals (application data, document data, photo data, etc.) flow together on the same packet communication path. Features. Furthermore, as mobile terminals, the spread of so-called smart devices such as smartphones and tablets as well as conventional so-called Galapagos mobiles is accelerating.
Thereby, in the LTE / EPC system, a packet with a huge amount of data that cannot be compared with the conventional communication system flows through the packet communication path.
Therefore, in the LTE / EPC system, it is necessary to perform packet transfer rate control. For example, Japanese Patent Laying-Open No. 2004-320452 (Patent Document 1) discloses a packet transfer control device that performs packet transfer rate control.
The packet transfer control device disclosed in Patent Document 1 includes a line congestion state determination unit, a transfer rate control determination unit, and a packet processing unit. The line congestion state determination unit determines whether the backbone line is congested based on the accumulated packet total amount that is the accumulated value of the packet size for a plurality of packets. When determining that the backbone line is in a congested state, the transfer rate control determination unit selects one or more IP (Internet Protocol) flows having a hop count value lower than the threshold value. The packet processing unit determines whether the IP flow selected by the transfer rate control determination unit is a TCP (Transmission Control Protocol) packet. In the case of a TCP packet, the packet processing unit performs the following three types of packet processing. Apply.
Specifically, 1) In the case of an outgoing packet from the server, the CE (Consultation Experience) bit of ECN (Explicit Connection Notification) is set in the TCP header. 2) In the case of a reply packet returned from the client, the advertisement window size of the TCP header is reduced and changed. 3) In the case of an acknowledgment (Ack) packet, the transmission timing of the packet to the backbone line is delayed. If it is not a TCP packet, the packet is discarded.

特開２００４−３２０４５２号公報（［００５１］~［００５７］）JP 2004-320452 A ([0051] to [0057])

　パケット転送制御装置（例えばＥＰＣのＰ−ＧＷ：Ｐａｃｋｅｔ　ｄａｔａ　ｎｅｔｗｏｒｋ　ＧａｔｅＷａｙやＳ−ＧＷ：Ｓｅｒｖｉｎｇ　ＧａｔｅＷａｙ）では、これまでは、ＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）を制御するパラメータとして、ＱＣＩ（Ｑｕａｌｉｔｙ　Ｃｌａｓｓ　Ｉｄｅｎｔｉｆｉｅｒ）、ＭＢＲ（Ｍａｘｉｍｕｍ　Ｂｉｔ　Ｒａｔｅ）、ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ　Ｂｉｔ　Ｒａｔｅ）などのパラメータを設定して、パケット毎にＱｏＳを制御している。
　しかしながら、ＬＴＥ／ＥＰＣシステム全体のネットワークの帯域幅は、トラヒック量の時間的な変動に依存して時間的に変動するため、ＱＣＩ（Ｑｕａｌｉｔｙ　Ｃｌａｓｓ　Ｉｄｅｎｔｉｆｉｅｒ）、ＭＢＲ（Ｍａｘｉｍｕｍ　Ｂｉｔ　Ｒａｔｅ）、ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ　Ｂｉｔ　Ｒａｔｅ）などのパラメータ値の設定による転送制御は十分ではなく、最悪の場合は端末で画面がフリーズする、音が途切れる、などといった、ＱｏＥ（Ｑｕａｌｉｔｙ　ｏｆ　Ｅｘｐｅｒｉｅｎｃｅ）の劣化に関する課題が発生していた。
　さらに、今後、ＬＴＥ／ＥＰＣシステムのパケット通信路を用いて高音質ＶｏＩＰ（Ｖｏｉｃｅ　Ｏｖｅｒ　ＩＰ）や高解像度ＴＶ電話などのリアルタイム通信サービスとして開始される状況において、ネットワークが輻輳すると、最悪の場合には、ＶｏＩＰによる音声通話の際に端末で音が途切れたり、ＴＶ電話の際に端末で映像が乱れたりあるいはフリーズしたりする、といった、端末側のＱｏＥの劣化に関する課題が発生する恐れがあった。
　尚、特許文献１は、バックボーン回線が輻輳状態のときに、しきい値を下回るホップカウント値を有する１以上のＩＰフローを選択する、パケット転送制御装置を開示しているに過ぎない。すなわち、特許文献１では、上述したＱｏＥの劣化に関する課題の認識がないし、携帯端末などの端末の具体的な構成についても何ら開示していない。
　本発明の目的は、ＱｏＥの劣化を回避することができる、端末を提供することにある。 Until now, in packet transfer control devices (for example, EPC P-GW: Packet data network Gateway or S-GW: Serving Gateway), QCI (Quality Class Id) is used as a parameter for controlling QoS (Quality of Service). Parameters such as (Maximum Bit Rate) and GBR (Guaranteed Bit Rate) are set, and QoS is controlled for each packet.
However, since the network bandwidth of the entire LTE / EPC system varies temporally depending on the temporal variation of the traffic volume, QCI (Quality Class Identifier), MBR (Maximum Bit Rate), GBR (Guaranteed Bit Rate) Transfer control by setting parameter values such as (Rate) is not sufficient, and in the worst case, a problem relating to quality of experience (QoE) degradation such as the screen being frozen at the terminal or the sound being interrupted has occurred.
Furthermore, in the future, when the network is congested in a situation where it is started as a real-time communication service such as a high-quality voice VoIP (Voice Over IP) or a high-resolution videophone using the packet communication path of the LTE / EPC system, There is a risk of problems regarding QoE degradation on the terminal side, such as sound being interrupted at the terminal during a voice call by VoIP, or video being disturbed or frozen at the terminal during a videophone call.
Note that Patent Document 1 merely discloses a packet transfer control device that selects one or more IP flows having a hop count value lower than a threshold value when the backbone line is congested. That is, Patent Document 1 does not recognize the above-described problem relating to the deterioration of QoE, and does not disclose any specific configuration of a terminal such as a portable terminal.
An object of the present invention is to provide a terminal capable of avoiding QoE degradation.

　本発明の一形態は、ネットワークに接続され、前記ネットワークを介してメディアデータを格納したパケットを送受信する端末であって、受信した下り方向のパケットに基づいて、前記ネットワークの輻輳を検出する輻輳検出部と、前記輻輳検出部が前記ネットワークの輻輳を検出した場合に、相手端末に対して前記メディアデータについてレートを変更する要求を前記ネットワークの逆の方向を用いて通知するパケット送受信部と、を備えることを特徴とする。 One aspect of the present invention is a terminal that is connected to a network and transmits / receives a packet storing media data via the network, and detects congestion of the network based on a received downstream packet. And a packet transmission / reception unit that, when the congestion detection unit detects congestion of the network, notifies a counterpart terminal of a request to change the rate of the media data using the reverse direction of the network. It is characterized by providing.

　本発明によれば、トラヒックが統計値に比べ大幅に変化した場合でも、輻輳状態を回避することが可能となる。 According to the present invention, it is possible to avoid a congestion state even when the traffic changes significantly compared to the statistical value.

　図１は本発明が適用される通信システムの接続構成を示すブロック図である。
　図２は図１に示した通信システムに使用される、本発明の第１の実施形態に係る携帯端末の構成を示すブロック図である。
　図３は図１に示した通信システムに使用される、本発明の第２の実施形態に係る携帯端末の構成を示すブロック図である。 FIG. 1 is a block diagram showing a connection configuration of a communication system to which the present invention is applied.
FIG. 2 is a block diagram showing the configuration of the mobile terminal according to the first embodiment of the present invention used in the communication system shown in FIG.
FIG. 3 is a block diagram showing a configuration of a mobile terminal according to the second embodiment of the present invention used in the communication system shown in FIG.

　以下、図面を参照して、本発明の実施形態と動作について詳細に説明する。
　図１は本発明が適用される通信システムの構成を示すブロック図である。ここでは、ネットワークとしてはモバイルＬＴＥ／ＥＰＣパケットネットワーク１５０を用いる場合の構成を示している。
　また図１の通信システムにおいては、後述するパケット転送制御装置１９０は、Ｐ−ＧＷ（Ｐａｃｋｅｔ　ｄａｔａ　ｎｅｔｗｏｒｋ　ＧａｔｅＷａｙ）またはＳ−ＧＷ（Ｓｅｒｖｉｎｇ　ＧａｔｅＷａｙ）またはそれらの両者を用いる場合の構成を示している。また携帯端末は、いわゆるガラパゴス携帯、スマートフォン、タブレットを想定している。
　図１の通信システムでは、ユーザＡが相手のユーザ（図示せず）と通信を行なう例を示している。
　図１の通信システムでは、ユーザＡが携帯端末１７０を用いて、モバイルネットワーク１５０およびＩＭＳ（ＩＰ　Ｍｕｌｔｉｍｅｄｉａ　Ｓｕｂｓｙｓｔｅｍ）網１３０を介して、相手先ネットワーク（図示せず）を経由して相手先の端末（図示せず）とＶｏＩＰ（Ｖｏｉｃｅ　Ｏｖｅｒ　ＩＰ）音声通信を行なう。
　なお、相手先端末と映像、音声をやりとりするＴＶ電話でも同一の構成をとることができるが、ここでは、その場合の説明を省略する。
　図１の通信システムでは、輻輳検出の一例として、携帯端末１７０が、モバイルネットワーク１５０から受信した下り方向のパケットに対しＥＣＮ（Ｅｘｐｌｉｃｉｔ　Ｃｏｎｇｅｓｔｉｏｎ　Ｎｏｔｉｆｉｃａｔｉｏｎ）による輻輳情報を受信して輻輳を検出する構成について示す。なお、ここでは、屋外型ＬＴＥ無線基地局装置（ｅＮｏｄｅＢ装置）１９４が無線ネットワークでの輻輳状態を検出すると、ｅＮｏｄｅＢ装置１９４が携帯端末１７０へ送出する下りパケットのＩＰ（ｉｎｔｅｒｎｅｔ　ｐｒｏｔｏｃｏｌ）ヘッダ部のＥＣＮフィールドに、ＣＥ（Ｃｏｎｇｅｓｔｉｏｎ　Ｅｘｐｅｒｉｅｎｃｅ）ビットをたてることにより、携帯端末１７０に輻輳状態であることを通知するものとする。
　図１の通信システムにおいて、携帯端末１７０は、音声通話の接続要求として、相手先端末のＩＰアドレス、ＲＴＰ（ｒｅａｌ−ｔｉｍｅ　ｔｒａｎｓｐｏｒｔ　ｐｒｏｔｏｃｏｌ）ポート番号を送出すると、その接続要求は、ｅＮｏｄｅＢ装置１９４ならびにパケット転送制御装置１９０を経由して、ＩＭＳ（ＩＰ　Ｍｕｌｔｉｍｅｄｉａ　Ｓｕｂｓｙｓｔｅｍ）網１３０に配置されたＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）サーバ１１０ならびに、ＰＣＲＦ（Ｐｏｌｉｃｙ　ａｎｄ　Ｃｈａｒｇｉｎｇ　Ｒｕｌｅｓ　Ｆｕｎｃｔｉｏｎ）装置１９１、の少なくとも一方に転送される。さらに、携帯端末１７０は、音声通話トラヒック、希望ＱｏＳクラス、ＭＢＲ（Ｍａｘｉｍｕｍ　Ｂｉｔ　Ｒａｔｅ）、ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ　Ｂｉｔ　Ｒａｔｅ）などのパラメータのうちの少なくとも一つのパラメータを接続要求に追加し、パケット転送制御装置１９０経由で、ＳＩＰサーバ１１０ならびにＰＣＲＦ装置１９１の少なくとも一方に通知することもできる。
　ＳＩＰサーバ１１０は、音声通話の接続要求信号を受け取り、相手先端末（図示せず）に対し相手先ネットワーク（図示せず）を経由して接続要求を送出する。そして、ＳＩＰサーバ１１０は、相手先端末からＡｃｋ信号を受け取ると、当該Ａｃｋ信号をパケット転送制御装置１９０ならびにｅＮｏｄｅＢ装置１９４を経由して携帯端末１７０に送出する。携帯端末１７０でこのＡｃｋ信号を受信することで、音声通話のための制御信号のやりとりが行なわれる。ここで、相手先端末からは、携帯端末１７０のＩＰアドレス、ＲＴＰポート番号だけでなく、音声通話トラヒック、希望ＱｏＳクラス、ＭＢＲ（Ｍａｘｉｍｕｍ　Ｂｉｔ　Ｒａｔｅ）、ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ　Ｂｉｔ　Ｒａｔｅ）のパラメータの少なくとも一つをＡｃｋ信号に追加して送出することもできる。これらのパラメータは、ＳＩＰサーバ１１０だけでなくＰＣＲＦ装置１９１に伝えることができる。
　ＰＣＲＦ装置１９１は、上りならびに下り方向の少なくとも一方に対して、音声通話トラヒック、携帯端末１７０のＩＰアドレス、ポート番号をパケット転送制御装置１９０から入力する。さらに必要であれば、ＰＣＲＦ装置１９１は、希望ＱｏＳクラス、ＭＢＲ（Ｍａｘｉｍｕｍ　Ｂｉｔ　Ｒａｔｅ）、ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ　Ｂｉｔ　Ｒａｔｅ）などのパラメータもＱｏＳ情報としてパケット転送制御装置１９０から入力する。
　次に、ＰＣＲＦ装置１９１は、ＱｏＳ制御のためのＱｏＳパラメータを生成する。ＱｏＳ制御のためのＱｏＳパラメータは、ＱｏＳクラスを識別する値であるＱＣＩ（Ｑｕａｌｉｔｙ　Ｃｌａｓｓ　Ｉｄｅｎｔｉｆｉｅｒ）、リソースの確保と保持の優先度を表すＡＲＰ（Ａｌｌｏｃａｔｉｏｎ　ａｎｄ　Ｒｅｔｅｎｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）、ＭＢＲ、ＧＢＲの少なくとも一つである。ここで、ＭＢＲとＧＢＲは、パケット転送制御装置１９０から受信する場合はそのまま使い、受信がない場合はＰＣＲＦ装置１９１が生成する。
　ＰＣＲＦ装置１９１は、上り方向ならびに下り方向の各々に対し、これら４種類のＱｏＳパラメータの少なくとも一つを生成し、生成したＱｏＳパラメータをパケット転送制御装置１９０に送出する。携帯端末１７０に対しては、トラヒックが音声通話であることから、ＱｏＳパラメータの値は、具体的には、例えば、上り、下りともに、ＱＣＩ＝１（Ｃｏｎｖｅｒｓａｔｉｏｎａｌ　Ｖｏｉｃｅ）、ＡＲＰ＝２、ＧＢＲ＝１２．２ｋｂｐｓ、ＭＢＲ＝２２．８ｋｂｐｓ、と設定する。ここでは、一例として携帯端末１７０でＡＭＲ−ＮＢ（Ａｄａｐｔｉｖｅ　Ｍｕｌｔｉ−Ｒａｔｅ　Ｎａｒｒｏｗｂａｎｄ）音声コーデックを用いるものとして、上記のパラメータ値を用いることとする。なお、ＡＭＲ−ＮＢ音声コーデックの詳細は、例えば、３ＧＰＰ　ＴＳ２６．０９０規格を参照することができるので、ここではその説明を省略する。
　また、別の音声コーデックとして、ＡＭＲ−ＷＢ（Ａｄａｐｔｉｖｅ　Ｍｕｌｔｉ−Ｒａｔｅ　Ｗｉｄｅ　ｂａｎｄ）音声コーデックを用いることもできるが、この場合は、ＧＢＲの数値を変更することができる。ＡＭＲ−ＷＢ音声コーデックの詳細は、例えば、３ＧＰＰ　ＴＳ２６．１９０規格を参照することが出来るので、ここではその説明を省略する。
　パケット転送制御装置１９０は、携帯端末１７０からの制御信号をＳＩＰサーバ１１０に中継するとともに、ＳＩＰサーバ１１０からの制御信号やＡｃｋ信号を携帯端末１７０へ中継する。パケット転送制御装置１９０は、ＰＣＲＦ装置１９１から、トラヒックデータ毎に、ＱＣＩ、ＡＲＰ、ＭＢＲ、ＧＢＲの４種のＱｏＳパラメータの少なくとも一つを入力する。すなわち、パケット転送制御装置１９０は、音声通話トラヒックの上り方向ならびに下り方向の各々に対する４種類のＱｏＳパラメータの少なくとも一つ、及び、ダウンロードデータトラヒックの下り方向に対する４種類のＱｏＳパラメータの少なくとも一つを、ＲＣＲＦ装置１９１から入力し、ＱｏＳパラメータの設定値に従い、上りおよび下りのパケットの転送制御を行なう。
［第１の実施形態］
　次に、図２を用いて、本発明の第１の実施形態に係る携帯端末１７０の構成について説明する。図２は、携帯端末１７０の構成を示すブロック図である。ここで、相手先の端末も図２と同じ構成であるので、相手先端末の説明は省略する。
　図２に示されるように、携帯端末１７０は、パケット受信部２５０と、パケット送信部２５１と、音声デコーダ２５３と、レート設定部２５４と、輻輳検出部２５５と、音声エンコーダ２５６とから構成される。
　図２において、パケット受信部２５０は、まず、図１のｅＮｏｄｅＢ装置１９４から送出された下り方向のパケットを受信する。そして、パケット受信部２５０は、その受信したパケットから、ＩＰヘッダ部分の情報とペイロードヘッダ部分の情報とペイロードデータとを抽出する。パケット受信部２５０は、ＩＰヘッダ部分の情報を輻輳検出部２５５に送出し、ペイロードヘッダ部分の情報をレート設定部２５４に送出し、ペイロードデータを音声デコーダ２５３に送出する。ここでは、受信パケットのプロトコルとして、ＲＴＰ／ＵＤＰ（ｕｓｅｒ　ｄａｔａｇｒａｍ　ｐｒｏｔｏｃｏｌ）／ＩＰパケットを用いるものとする。
　輻輳検出部２５５は、下り方向のパケットのＩＰヘッダ部分の情報を入力し、ＩＰヘッダ部のＥＣＮ（Ｅｘｐｌｉｃｉｔ　Ｃｏｎｇｅｓｔｉｏｎ　Ｎｏｔｉｆｉｃａｔｉｏｎ）フィールドをチェックする。輻輳検出部２５５は、ＥＣＮフィールドにＣＥビットがたっている場合、ｅＮｏｄｅＢ装置１９４から携帯端末１７０までの下り方向のネットワークまたは、パケット転送制御装置１９０から携帯端末１７０までの下り方向のネットワークが輻輳状態であると検出し、下り方向の輻輳検出情報をレート設定部２５４に送出する。
　レート設定部２５４は、輻輳検出部２５５から、下り方向の輻輳検出情報を入力した場合、相手先端末の音声エンコーダのレートを変更するために変更後のレートを設定する。具体的には、レート設定部２５４は、レート変更前のレート設定が１２．２ｋｂｐｓであった場合、輻輳検出後は、レートを６．７ｋｂｐｓに変更する。そして変更後のレートを、逆方向である上り方向のパケットにより相手先端末に要求するために、レート設定部２５４は、上り方向パケットのペイロードヘッダのＣＭＲ（Ｃｏｄｅｃ　Ｍｏｄｅ　Ｒｅｑｕｅｓｔ）フィールドに変更後のレートを書き込むよう、パケット送信部２５１に指示する。
　また、レート設定部２５４は、パケット受信部２５０において下り方向のパケットから抽出したペイロードヘッダ情報を、パケット受信部２５０から入力し、前記ペイロードヘッダ情報においてＣＭＲフィールドをチェックする。もしＣＭＲフィールドで指定されているレートが変更されている場合は、相手先端末から、下り方向のパケットを介して、携帯端末１７０の音声エンコーダに対しレート変更の要求がきていることになるので、レート設定部２５４は、ＣＭＲフィールドで指定された変更後の値にレートを変更し、変更後のレートを音声エンコーダ２５６に送出する。
　音声デコーダ２５３は、パケット受信部２５０からペイロードデータを入力し、音声デコーダを動作させて、ペイロードデータに含まれる音声の圧縮符号化ビットストリームを入力してこれを復号し、復号して得た再生音声信号を出力する。ここで、音声デコーダとしては、前述したように、ＡＭＲ−ＮＢデコーダを用いるものとする。
　音声エンコーダ２５６は、レート設定部２５４から変更後のレートを入力し、レートが変更されている場合は変更後のレートに基づき、レートが変更されていない場合はこれまでのレートに基づき、入力した音声信号を圧縮符号化して得たビットストリームをパケット送信部２５１に送出する。ここで、音声エンコーダとしては、前述したように、ＡＭＲ−ＮＢエンコーダを用いるものとする。
　パケット送信部２５１は、音声エンコーダ２５６から入力した圧縮符号化ビットストリームを送信パケットのペイロード部分に格納する。さらに、相手先端末に対し変更後のレートを要求するために、パケット送信部２５１は、レート設定部２５４から入力した、変更後のレート値を前記送信パケットのペイロードヘッダ部分のＣＭＲフィールドに設定した上で、前記パケットをｅＮｏｄｅＢ装置１９４に対し送出する。ここで、送信パケットのプロトコルは、前述したように、ＲＴＰ／ＵＤＰ／ＩＰパケットを用いるものとする。
　以上で本発明の第１の実施形態の構成の説明を終えるが、種々の変形が可能である。
　本第１の実施形態では、相手先端末に対しレートを変更する要求として、パケットＣＭＲフィールドを用いる構成を示したが、別の構成として、ＲＴＣＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）パケットやＲＴＣＰ−ＡＰＰ（ＡＰＰｌｉｃａｔｉｏｎ　ｓｐｅｃｉｆｉｃ）パケットを用いて、これらに、レート値やレート変更値や、またはＣＭＲ値を記載することもできる。さらに、相手先端末に対しレートを変更する要求として、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）やＳＤＰ（Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）を用いることもできる。ＳＤＰを用いる場合は、例えばｍｏｄｅ　ｓｅｔのパラメータに含めることもできる。
　また、音声コーデックとしては、ＡＭＲ−ＮＢ以外にも、ＡＭＲ−ＷＢや、複数ビットレートで動作する他の音声コーデックを用いることができる。
　本第１の実施形態では、音声通話を行なう場合について示したが、例えば、ＴＶ電話に対しても同じ構成で対応することができる。またオーディオ信号にも適用することができる。
　なお、第１の実施形態では、輻輳の検出はＥＣＮ情報を用いたが、他の情報を用いることも出来る。
　また、モバイルネットワーク１５０は、３Ｇネットワークとすることもできるし、パケット転送制御装置１９０に、ＳＧＳＮ（Ｓｅｒｖｉｎｇ　ＧＰＲＳ　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ）やＧＧＳＮ（Ｇａｔｅｗａｙ　ＧＰＲＳ　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ）を用いることも出来る。
　また、３ＧネットワークではなくＮＧＮ（Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｎｅｔｗｏｒｋ）などのＩＰネットワークを用いることもできる。また、ｅＮｏｄｅＢ装置１９４のかわりに、Ｗ−ＬＡＮ（Ｗｉｒｅｌｅｓｓ　Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）アクセスポイントを用いることも出来る。
　尚、携帯端末１７０は、コンピュータによって実行されるプログラムによって実現され得る。すなわち、携帯端末１７０は、パケット送受信制御プロセッサ（図示せず）と記憶装置（図示せず）とから構成されてよい。記憶装置は、パケット送受信制御プログラムを記憶する。この場合、パケット送受信制御プロセッサは、記憶装置に記憶されたパケット送受信制御プログラムに従って上述したパケット送受信制御動作を行う。
　次に、本発明の第１の実施形態の効果について説明する。
　本発明の第１の実施形態によれば、ネットワークの輻輳を端末で検出した場合に、相手端末に対し、映像および音声およびオーディオの少なくとも一つについてレートを変更する要求を前記ネットワークの逆の方向を用いて通知することが可能となる。その結果、輻輳状態を回避することが可能となり、端末で、音が途切れる、画面がフリーズする、といったＱｏＥ（Ｑｕａｌｉｔｙ　ｏｆ　Ｅｘｐｅｒｉｅｎｃｅ）の劣化を回避することができるという効果がある。さらに、今後、ＬＴＥ／ＥＰＣシステムのパケット通信路を用いて高音質ＶｏＩＰや高解像度ＴＶ電話などのサービスが開始されても、端末側のＱｏＥの劣化を回避することができるという効果がある。
［第２の実施形態］
　次に、図３を参照して、本発明の第２の実施形態に係る携帯端末１７０Ａの構成について説明する。
　図３は、携帯端末１７０Ａにおいて、輻輳検出時に、ネットワークの帯域を推定し、推定値をもとに変更すべきレートを算出する構成を示している。図３において、図２と同じ番号を付した構成要素は、図２と同じ動作を行うので、それらの説明を省略する。
　携帯端末１７０Ａは、帯域推定部２５７が追加されていると共に、レート設定部の動作が後述するように変更されている点を除いて、図２に示した携帯端末１７０と同様の構成を有する。従って、レート設定部に２５８の参照符号を付してある。
　帯域推定部２５７は、輻輳検出部２５５からの出力信号が、下り方向のネットワークの輻輳を検出したことを示す場合、下記の式（１）に従い、パケット受信部２５０において輻輳検出の直後の第ｎ時刻以降に受信したパケットに対し、当該パケットの遅延時間Ｔ（ｎ）を測定する。
　Ｔ（ｎ）　＝　Ｒ（ｎ）　−Ｓ（ｎ）　　　　　　　（１）
ここで、Ｔ（ｎ）、Ｒ（ｎ）、Ｓ（ｎ）は、それぞれ、第ｎ番目のパケットの遅延時間、第ｎ番目のパケットの受信時刻、第ｎ番目のパケットの送信時刻、を示す。
　さらに、帯域推定部２５７は、後続の連続する複数個のパケットに対しても遅延値を測定し、時間方向に平滑化した上で、下記の式（２）から、下り方向のネットワークの帯域Ｗを推定する。
　Ｗ　＝　Ｄ／ＳＴ　　　　　　　　　　　　　（２）
ここで、Ｗはネットワークの推定帯域、Ｄは受信したデータサイズの時間平滑化値、ＳＴは遅延時間の時間平滑化値、をそれぞれ示す。
　そして、帯域推定部２５７は、推定した帯域Ｗをレート設定部２５８に送出する。
　レート設定部２５８は、輻輳検出部２５５から下り方向の輻輳検出情報を入力した場合、相手先端末の音声エンコーダのレートを変更するために変更後のレートを設定する。具体的には、レート設定部２５８は、帯域推定部２５７から、下り方向のネットワークの帯域推定値Ｗを入力し、音声コーデックがサポートしている複数のレートの中から、下記の式（３）を満たすレートを選択し、これを変更後のレートに設定する。
　Ｂ（ｉ）　＜　Ｗ　　　　　　　（３）
ここで、Ｂ（ｉ）は、音声コーデックがサポートしているＮ種類のレートのうちのｉ番目のレートであり、１＜ｉ＜　Ｎである。ここで、ＮはＡＭＲ−ＮＢ音声コーデックの場合は８、ＡＭＲ−ＷＢ音声コーデックの場合は９となる。
　たとえば、式（３）を満たすレートとして、６．７ｋｂｐｓと４．７５ｋｂｐｓの２種類があった場合に、レート設定部２５８はビットレートの高い方のレートを選択する。従って、ここではレート設定部２５８は６．７ｋｂｐｓを選択することになる。
　そして変更後のレートを、逆方向である上り方向のパケットにより相手先端末に要求するために、レート設定部２５８は、上り方向パケットのペイロードヘッダのＣＭＲ（Ｃｏｄｅｃ　Ｍｏｄｅ　Ｒｅｑｕｅｓｔ）フィールドに変更後のレートを書き込むよう、パケット送信部２５１に指示する。
　また、レート設定部２５８は、パケット受信部２５０において下り方向のパケットから抽出したペイロードヘッダ情報を、パケット受信部２５０から入力し、前記ペイロードヘッダ情報においてＣＭＲフィールドをチェックする。もしＣＭＲフィールドで指定されているレートが変更されている場合は、相手先端末から下り方向のパケットを介して携帯端末１７０Ａの音声エンコーダに対しレート変更の要求がきていることになるので、レート設定部２５８は、ＣＭＲフィールドで指定された変更後の値にレートを変更し、変更後のレートを音声エンコーダ２５６に送出する。
　以上で本発明の第２の実施形態の構成の説明を終えるが、種々の変形が可能である。
　本第２の実施形態では、相手先端末に対しレートを変更する要求として、パケットＣＭＲフィールドを用いる構成を示したが、別の構成として、ＲＴＣＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）パケットやＲＴＣＰ−ＡＰＰ（ＡＰＰｌｉｃａｔｉｏｎ　ｓｐｅｃｉｆｉｃ）パケットを用いて、これらに、レート値やレート変更値や、またはＣＭＲ値を記載することもできる。さらに、相手先端末に対しレートを変更する要求として、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）やＳＤＰ（Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）を用いることもできる。ＳＤＰを用いる場合は、例えばｍｏｄｅ　ｓｅｔのパラメータに含めることもできる。
　また、音声コーデックとしては、ＡＭＲ−ＮＢ以外にも、ＡＭＲ−ＷＢや、複数ビットレートで動作する他の音声コーデックを用いることができる。
　また、帯域推定の方法や、レートの変更法について、他の方法を用いることも出来る。
　本第２の実施形態では、音声通話を行なう場合について示したが、例えば、ＴＶ電話に対しても同じ構成で対応することができる。またオーディオ信号にも適用することができる。
　なお、第２の実施形態では、輻輳の検出はＥＣＮ情報を用いているが、他の情報を用いることも出来る。
　また、モバイルネットワーク１５０は、３Ｇネットワークとすることもできるし、パケット転送制御装置１９０に、ＳＧＳＮ（Ｓｅｒｖｉｎｇ　ＧＰＲＳ　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ）やＧＧＳＮ（Ｇａｔｅｗａｙ　ＧＰＲＳ　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ）を用いることも出来る。
　また、３ＧネットワークではなくＮＧＮ（Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｎｅｔｗｏｒｋ）などのＩＰネットワークを用いることもできる。また、ｅＮｏｄｅＢ装置１９４のかわりに、Ｗ−ＬＡＮ（Ｗｉｒｅｌｅｓｓ　Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）アクセスポイントを用いることも出来る。
　尚、携帯端末１７０Ａは、コンピュータによって実行されるプログラムによって実現され得る。すなわち、携帯端末１７０Ａは、パケット送受信制御プロセッサ（図示せず）と記憶装置（図示せず）とから構成されてよい。記憶装置は、パケット送受信制御プログラムを記憶する。この場合、パケット送受信制御プロセッサは、記憶装置に記憶されたパケット送受信制御プログラムに従って上述したパケット送受信制御動作を行う。
　次に、本発明の第２の実施形態の効果について説明する。
　本発明の第２の実施形態によれば、ネットワークの輻輳を端末で検出した場合に、相手端末に対し、映像および音声およびオーディオの少なくとも一つについてレートを変更する要求を前記ネットワークの逆の方向を用いて通知することが可能となる。その結果、輻輳状態を回避することが可能となり、端末で、音が途切れる、画面がフリーズする、といったＱｏＥ（Ｑｕａｌｉｔｙ　ｏｆ　Ｅｘｐｅｒｉｅｎｃｅ）の劣化を回避することができるという効果がある。さらに、今後、ＬＴＥ／ＥＰＣシステムのパケット通信路を用いて高音質ＶｏＩＰや高解像度ＴＶ電話などのサービスが開始されても、端末側のＱｏＥの劣化を回避することができるという効果がある。
　以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施の形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
　上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
　ネットワークに接続され、前記ネットワークを介してメディアデータを格納したパケットを送受信する端末であって、
　受信した下り方向のパケットに基づいて、前記ネットワークの輻輳を検出する輻輳検出部と、
　前記輻輳検出部が前記ネットワークの輻輳を検出した場合に、相手端末に対して前記メディアデータについてレートを変更する要求を前記ネットワークの逆の方向を用いて通知するパケット送受信部と、
を備えることを特徴とする端末。
（付記２）
　前記輻輳検出部は、前記下り方向のパケットから輻輳情報を抽出して、前記ネットワークの輻輳を検出する、ことを特徴とする付記１に記載の端末。
（付記３）
　前記輻輳検出部は、前記下り方向のパケットのＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）ヘッダ部のＥＣＮ（Ｅｘｐｌｉｃｉｔ　Ｃｏｎｇｅｓｔｉｏｎ　Ｎｏｔｉｆｉｃａｔｉｏｎ）フィールドをチェックすることにより、前記輻輳情報を抽出する、ことを特徴とする付記２に記載の端末。
（付記４）
　前記レートを変更する要求は、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）／ＳＤＰ（Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）、ＣＭＲ（Ｃｏｄｅｃ　Ｍｏｄｅ　Ｒｅｑｕｅｓｔ）、ＲＴＣＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）、およびＲＴＣＰ−ＡＰＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ−ＡＰＰｌｉｃａｔｉｏｎ　ｓｐｅｃｉｆｉｃ）のいずれか一つを用いることを特徴とする、付記１乃至３のいずれか１つに記載の端末。
（付記５）
　前記パケット送受信部は、
　前記輻輳検出部が前記ネットワークの輻輳を検出した場合に、前記受信した下り方向のパケットに基づいて、前記ネットワークの帯域を推定する帯域推定部と、
　該推定したネットワークの帯域に基づいて、変更すべきレートを算出するレート設定部と、
　前記算出したレートに基づいて、前記レートを変更する要求を前記相手端末に送出するパケット送信部と、
を備えることを特徴とする付記１乃至４のいずれか１つに記載の端末。
（付記６）
　前記メディアデータは、映像データ、音声データ、オーディオデータの少なくとも一つからなる、付記１乃至５のいずれか１つに記載の端末。
（付記７）
　付記１乃至６のいずれか１つに記載の端末と、前記ネットワークを介して前記端末に接続されたパケット転送制御装置と、を含む通信システム。
（付記８）
　ネットワークに接続され、前記ネットワークを介してメディアデータを格納したパケットを送受信する端末におけるパケット送受信制御方法であって、
　受信した下り方向のパケットに基づいて、前記ネットワークの輻輳を検出する輻輳検出ステップと、
　前記ネットワークの輻輳を検出した場合に、相手端末に対して前記メディアデータについてレートを変更する要求を前記ネットワークの逆の方向を用いて通知するパケット送受信ステップと、
を含むパケット送受信制御方法。
（付記９）
　前記輻輳検出ステップは、前記下り方向のパケットから輻輳情報を抽出して、前記ネットワークの輻輳を検出する、付記８に記載のパケット送受信制御方法。
（付記１０）
　前記輻輳検出ステップは、前記下り方向のパケットのＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）ヘッダ部のＥＣＮ（Ｅｘｐｌｉｃｉｔ　Ｃｏｎｇｅｓｔｉｏｎ　Ｎｏｔｉｆｉｃａｔｉｏｎ）フィールドをチェックすることにより、前記輻輳情報を抽出する、請求項９に記載のパケット送受信制御方法。
（付記１１）
　前記レートを変更する要求は、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）／ＳＤＰ（Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）、ＣＭＲ（Ｃｏｄｅｃ　Ｍｏｄｅ　Ｒｅｑｕｅｓｔ）、ＲＴＣＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）、およびＲＴＣＰ−ＡＰＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ−ＡＰＰｌｉｃａｔｉｏｎ　ｓｐｅｃｉｆｉｃ）のいずれか一つを用いることを特徴とする、付記８乃至１０のいずれか１つに記載のパケット送受信制御方法。
（付記１２）
　前記パケット送受信ステップは、
　前記ネットワークの輻輳を検出した場合に、前記受信した下り方向のパケットに基づいて、前記ネットワークの帯域を推定する帯域推定ステップと、
　該推定したネットワークの帯域に基づいて、変更すべきレートを算出するレート算出ステップと、
　前記算出したレートに基づいて、前記レートを変更する要求を前記相手端末に送出する送出ステップと、
を含む付記８乃至１１のいずれか１つに記載のパケット送受信制御方法。
（付記１３）
　前記メディアデータは、映像データ、音声データ、オーディオデータの少なくとも一つからなる、付記８乃至１２のいずれか１つに記載のパケット送受信制御方法。
（付記１４）
　ネットワークに接続された端末であるコンピュータに、前記ネットワークを介してメディアデータを格納したパケットを送受信させるパケット送受信制御プログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記パケット送受信制御プログラムは、前記コンピュータに、
　受信した下り方向のパケットに基づいて、前記ネットワークの輻輳を検出する輻輳検出手順と、
　前記ネットワークの輻輳を検出した場合に、相手端末に対して前記メディアデータについてレートを変更する要求を前記ネットワークの逆の方向を用いて通知するパケット送受信手順と、
を実行させる記録媒体。 Hereinafter, embodiments and operations of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a block diagram showing a configuration of a communication system to which the present invention is applied. Here, a configuration in which the mobile LTE / EPC packet network 150 is used as the network is shown.
Further, in the communication system of FIG. 1, a packet transfer control device 190 (to be described later) shows a configuration using P-GW (Packet data network Gateway) or S-GW (Serving Gateway) or both. The mobile terminal is assumed to be a so-called Galapagos mobile phone, a smartphone, or a tablet.
The communication system of FIG. 1 shows an example in which user A communicates with a partner user (not shown).
In the communication system of FIG. 1, a user A uses a portable terminal 170 to connect to a partner terminal (not shown) via a mobile network 150 and an IMS (IP Multimedia Subsystem) network 130 via a partner network (not shown). (Not shown) and VoIP (Voice Over IP) voice communication.
Note that the same configuration can be adopted for a videophone that exchanges video and audio with a partner terminal, but the description in that case is omitted here.
In the communication system of FIG. 1, as an example of congestion detection, a configuration in which the mobile terminal 170 detects congestion by receiving congestion information by ECN (Explicit Connection Notification) for downlink packets received from the mobile network 150 is shown. . Here, when the outdoor LTE radio base station apparatus (eNodeB apparatus) 194 detects a congestion state in the wireless network, the ECN of the IP (Internet protocol) header portion of the downlink packet that the eNodeB apparatus 194 sends to the mobile terminal 170 It is assumed that the mobile terminal 170 is in a congested state by setting a CE (Congestion Experience) bit in the field.
In the communication system of FIG. 1, when the mobile terminal 170 sends out the IP address and RTP (real-time transport protocol) port number of the destination terminal as a voice call connection request, the connection request is sent to the eNodeB device 194 and the packet. The data is transferred to at least one of a SIP (Session Initiation Protocol) server 110 and a PCRF (Policy and Charging Rules Function) 191 that are arranged in an IMS (IP Multimedia Subsystem) network 130 via the transfer control device 190. Further, the mobile terminal 170 adds at least one parameter such as voice call traffic, desired QoS class, MBR (Maximum Bit Rate), GBR (Guaranteed Bit Rate) to the connection request, and 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 via the route.
The SIP server 110 receives a connection request signal for a voice call and sends a connection request to a partner terminal (not shown) via a partner network (not shown). When the SIP server 110 receives the Ack signal from the counterpart terminal, the SIP server 110 transmits the Ack signal to the mobile terminal 170 via the packet transfer control device 190 and the eNodeB device 194. When the mobile terminal 170 receives this Ack signal, control signals for voice call are 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 be transmitted in addition to the Ack signal. These parameters can be transmitted not only to the SIP server 110 but also to the PCRF apparatus 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, the PCRF device 191 also inputs parameters such as a desired QoS class, MBR (Maximum Bit Rate), GBR (Guaranteed Bit Rate), etc. from the packet transfer control device 190 as QoS information.
Next, the PCRF device 191 generates a QoS parameter for QoS control. The QoS 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. is there. Here, the MBR and the 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 QoS parameters for each of the uplink direction and the downlink direction, and sends the generated QoS parameters to the packet transfer control device 190. For the mobile terminal 170, since the traffic is a voice call, the values of the QoS parameters are specifically, for example, QCI = 1 (Conversational Voice), ARP = 2, GBR = 12, for both uplink and downlink. .2 kbps and MBR = 22.8 kbps are set. Here, as an example, the above-described parameter values are used on the assumption that the mobile terminal 170 uses an AMR-NB (Adaptive Multi-Rate Narrowband) audio codec. For details of the AMR-NB audio codec, for example, the 3GPP TS26.090 standard can be referred to, and the description thereof is omitted here.
As another audio codec, an AMR-WB (Adaptive Multi-Rate Wide band) audio codec can also be used. In this case, the value of GBR can be changed. For details of the AMR-WB audio codec, for example, the 3GPP TS26.190 standard can be referred to, and the description thereof is omitted here.
The packet transfer control device 190 relays the control signal from the mobile terminal 170 to the SIP server 110 and relays the control signal and the Ack signal from the SIP server 110 to the mobile terminal 170. The packet transfer control device 190 inputs at least one of four types of QoS parameters, QCI, ARP, MBR, and GBR, for each traffic data from the PCRF device 191. That is, the packet transfer control device 190 receives at least one of the four types of QoS parameters for the uplink direction and the downlink direction of the voice call traffic, and at least one of the four types of QoS parameters for the downlink direction of the download data traffic. , Input from the RCRF device 191, and performs uplink and downlink packet transfer control according to the set value of the QoS parameter.
[First Embodiment]
Next, the configuration of the mobile terminal 170 according to the first embodiment of the present invention will be described with reference to FIG. FIG. 2 is a block diagram illustrating a configuration of the mobile terminal 170. Here, the counterpart terminal also has the same configuration as that shown in FIG.
As shown in FIG. 2, the portable terminal 170 includes a packet receiver 250, a packet transmitter 251, a voice decoder 253, a rate setting unit 254, a congestion detector 255, and a voice encoder 256. .
In FIG. 2, the packet receiving unit 250 first receives a downlink packet transmitted from the eNodeB apparatus 194 in FIG. Then, the packet receiving unit 250 extracts information on the IP header portion, information on the payload header portion, and payload data from the received packet. The packet receiving unit 250 sends the information of the IP header part to the congestion detection unit 255, sends the information of the payload header part to the rate setting unit 254, and sends the payload data to the audio decoder 253. Here, it is assumed that an RTP / UDP (user datagram protocol) / IP packet is used as the protocol of the received packet.
The congestion detection unit 255 inputs the information of the IP header portion of the downstream packet, and checks the ECN (Explicit Connection Notification) field of the IP header portion. When the CE bit is set in the ECN field, the congestion detection unit 255 indicates that the downlink network from the eNodeB device 194 to the portable terminal 170 or the downlink network from the packet transfer control device 190 to the portable terminal 170 is congested. It detects that there is, and sends down congestion detection information to the rate setting unit 254.
When the downstream congestion detection information is input from the congestion detection unit 255, the rate setting unit 254 sets the changed rate in order to change the rate of the speech encoder of the counterpart terminal. Specifically, when the rate setting before the rate change is 12.2 kbps, the rate setting unit 254 changes the rate to 6.7 kbps after detecting congestion. Then, in order to request the changed rate from the counterpart terminal using an uplink packet that is the reverse direction, the rate setting unit 254 sets the rate after the change in the CMR (Codec Mode Request) field of the payload header of the uplink packet. To the packet transmission unit 251.
Further, the rate setting unit 254 inputs the payload header information extracted from the downstream packet in the packet receiving unit 250 from the packet receiving unit 250, and checks the CMR field in the payload header information. If the rate specified in the CMR field has been changed, a request for rate change has been received from the counterpart terminal to the voice encoder of the mobile terminal 170 via a downstream packet. The rate setting unit 254 changes the rate to the changed value designated in the CMR field, and sends the changed rate to the speech encoder 256.
The audio decoder 253 inputs the payload data from the packet receiving unit 250, operates the audio decoder, inputs the audio compression-encoded bitstream included in the payload data, decodes it, and reproduces it by decoding Output audio signals. Here, as described above, an AMR-NB decoder is used as the audio decoder.
The voice encoder 256 inputs the changed rate from the rate setting unit 254, and inputs the rate based on the changed rate when the rate is changed, or based on the previous rate when the rate is not changed. A bit stream obtained by compressing and encoding the audio signal is sent to the packet transmission unit 251. Here, as described above, an AMR-NB encoder is used as the speech encoder.
The packet transmission unit 251 stores the compressed and encoded bit stream input from the audio encoder 256 in the payload portion of the transmission packet. Further, in order to request the changed rate from the counterpart terminal, the packet transmission unit 251 sets the changed rate value input from the rate setting unit 254 in the CMR field of the payload header portion of the transmission packet. The packet is sent to the eNodeB device 194. Here, as described above, the RTP / UDP / IP packet is used as the protocol of the transmission packet.
Although the description of the configuration of the first embodiment of the present invention has been completed above, various modifications are possible.
In the first embodiment, the configuration in which the packet CMR field is used as a request to change the rate to the counterpart terminal has been described. However, as another configuration, an RTCP (RTP Control Protocol) packet or an RTCP-APP (APPLICATION SPECIFIC) is used. ) Packets can be used to describe rate values, rate change values, or CMR values. Furthermore, SIP (Session Initiation Protocol) or SDP (Session Description Protocol) can also be used as a request for changing the rate to the partner terminal. When using SDP, it can also be included in the parameters of the mode set, for example.
As the audio codec, in addition to AMR-NB, AMR-WB and other audio codecs operating at a plurality of bit rates can be used.
In the first embodiment, a case where a voice call is made has been described. However, for example, a TV phone can be handled with the same configuration. It can also be applied to audio signals.
In the first embodiment, congestion detection uses ECN information, but other information can also be used.
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).
In addition, an IP network such as NGN (Next Generation Network) can be used instead of the 3G network. Further, instead of the eNodeB device 194, a W-LAN (Wireless Local Area Network) access point may be used.
The portable terminal 170 can be realized by a program executed by a computer. That is, the mobile terminal 170 may be configured by a packet transmission / reception control processor (not shown) and a storage device (not shown). The storage device stores a packet transmission / reception control program. In this case, the packet transmission / reception control processor performs the above-described packet transmission / reception control operation according to the packet transmission / reception control program stored in the storage device.
Next, effects of the first exemplary embodiment of the present invention will be described.
According to the first embodiment of the present invention, when network congestion is detected at a terminal, a request to change the rate of at least one of video, audio, and audio is sent to the opposite terminal in the reverse direction of the network. Can be notified using. As a result, it is possible to avoid a congestion state, and there is an effect that it is possible to avoid deterioration of QoE (Quality of Experience) such as the sound being interrupted and the screen being frozen at the terminal. Furthermore, even if services such as high sound quality VoIP and high resolution TV phone are started using the packet communication path of the LTE / EPC system in the future, there is an effect that deterioration of QoE on the terminal side can be avoided.
[Second Embodiment]
Next, the configuration of a mobile terminal 170A according to the second embodiment of the present invention will be described with reference to FIG.
FIG. 3 shows a configuration in which portable terminal 170A estimates a network bandwidth and calculates a rate to be changed based on the estimated value when congestion is detected. In FIG. 3, the constituent elements having the same numbers as those in FIG. 2 perform the same operations as in FIG.
The mobile terminal 170A has the same configuration as the mobile terminal 170 shown in FIG. 2 except that a band estimation unit 257 is added and the operation of the rate setting unit is changed as will be described later. Therefore, the reference numeral 258 is attached to the rate setting unit.
When the output signal from the congestion detection unit 255 indicates that the downstream network congestion has been detected, the bandwidth estimation unit 257 is the nth immediately after the congestion detection in the packet reception unit 250 according to the following equation (1). For a packet received after the time, the delay time T (n) of the packet is measured.
T (n) = R (n) −S (n) (1)
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 bandwidth estimation unit 257 measures delay values for a plurality of subsequent consecutive packets, smooths them in the time direction, and then obtains the bandwidth W of the downstream network from the following equation (2). Is estimated.
W = D / ST (2)
Here, W is the estimated bandwidth of the network, D is the time smoothed value of the received data size, and ST is the time smoothed value of the delay time.
Then, the bandwidth estimation unit 257 sends the estimated bandwidth W to the rate setting unit 258.
When the downlink congestion detection information is input from the congestion detection unit 255, the rate setting unit 258 sets the changed rate in order to change the rate of the speech encoder of the counterpart terminal. Specifically, the rate setting unit 258 receives the bandwidth estimation value W of the downstream network from the bandwidth estimation unit 257, and the following equation (3) is selected from a plurality of rates supported by the voice codec. Select a rate that satisfies, and set this to the new rate.
B (i) <W (3)
Here, B (i) is the i-th rate among the N types of rates supported by the audio codec, and 1 <i <N. Here, N is 8 for the AMR-NB audio codec and 9 for the AMR-WB audio codec.
For example, when there are two types, 6.7 kbps and 4.75 kbps, as the rates satisfying Expression (3), the rate setting unit 258 selects the higher bit rate. Accordingly, here, the rate setting unit 258 selects 6.7 kbps.
Then, in order to request the changed rate from the counterpart terminal using an uplink packet that is the reverse direction, the rate setting unit 258 sets the rate after the change in the CMR (Codec Mode Request) field of the payload header of the uplink packet. To the packet transmission unit 251.
Further, the rate setting unit 258 inputs the payload header information extracted from the downlink packet in the packet receiving unit 250 from the packet receiving unit 250, and checks the CMR field in the payload header information. If the rate specified in the CMR field has been changed, a rate change request has been made to the voice encoder of the portable terminal 170A via the downstream packet from the counterpart terminal. The unit 258 changes the rate to the changed value specified in the CMR field, and sends the changed rate to the speech encoder 256.
This is the end of the description of the configuration of the second exemplary embodiment of the present invention, but various modifications are possible.
In the second embodiment, the configuration using the packet CMR field as a request for changing the rate to the counterpart terminal is shown. However, as another configuration, an RTCP (RTP Control Protocol) packet or an RTCP-APP (APPLICATION SPECIFIC) is used. ) Packets can be used to describe rate values, rate change values, or CMR values. Furthermore, SIP (Session Initiation Protocol) or SDP (Session Description Protocol) can also be used as a request for changing the rate to the partner terminal. When using SDP, it can also be included in the parameters of the mode set, for example.
As the audio codec, in addition to AMR-NB, AMR-WB and other audio codecs operating at a plurality of bit rates can be used.
Also, other methods can be used for the band estimation method and the rate changing method.
In the second embodiment, a case where a voice call is performed has been described. However, for example, a TV phone can be handled with the same configuration. It can also be applied to audio signals.
In the second embodiment, ECN information is used to detect congestion, but other information can also be used.
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).
In addition, an IP network such as NGN (Next Generation Network) can be used instead of the 3G network. Further, instead of the eNodeB device 194, a W-LAN (Wireless Local Area Network) access point may be used.
The portable terminal 170A can be realized by a program executed by a computer. That is, the mobile terminal 170A may be composed of a packet transmission / reception control processor (not shown) and a storage device (not shown). The storage device stores a packet transmission / reception control program. In this case, the packet transmission / reception control processor performs the above-described packet transmission / reception control operation according to the packet transmission / reception control program stored in the storage device.
Next, effects of the second exemplary embodiment of the present invention will be described.
According to the second embodiment of the present invention, when network congestion is detected at a terminal, a request to change the rate for at least one of video, audio, and audio is sent to the opposite terminal in the reverse direction of the network. Can be notified using. As a result, it is possible to avoid a congestion state, and there is an effect that it is possible to avoid deterioration of QoE (Quality of Experience) such as the sound being interrupted and the screen being frozen at the terminal. Furthermore, even if services such as high sound quality VoIP and high resolution TV phone are started using the packet communication path of the LTE / EPC system in the future, there is an effect that deterioration of QoE on the terminal side can be avoided.
Although the present invention has been described with reference to the embodiments, the present invention is not limited to the above embodiments. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.
A part or all of the above-described embodiment can be described as in the following supplementary notes, but is not limited thereto.
(Appendix 1)
A terminal connected to a network for transmitting and receiving packets storing media data via the network;
A congestion detector that detects congestion of the network based on the received downstream packet;
A packet transmission / reception unit for notifying a request for changing the rate of the media data to the counterpart terminal using the reverse direction of the network when the congestion detection unit detects congestion of the network;
A terminal comprising:
(Appendix 2)
The terminal according to appendix 1, wherein the congestion detection unit extracts congestion information from the downlink packet and detects congestion of the network.
(Appendix 3)
The congestion detection unit extracts the congestion information by checking an ECN (Explicit Connection Notification) field of an IP (Internet Protocol) header portion of the downstream packet, wherein the congestion information is extracted. Terminal.
(Appendix 4)
The request for changing the rate includes SIP (Session Initiation Protocol) / SDP (Session Description Protocol), CMR (Codec Mode Protocol), RTCP (RTP Control Protocol), and RTCP-APP (RTP Protocol Control). The terminal according to any one of appendices 1 to 3, wherein one of the two is used.
(Appendix 5)
The packet transmitter / receiver
When the congestion detection unit detects congestion of the network, a bandwidth estimation unit that estimates a bandwidth of the network based on the received downstream packet;
A rate setting unit that calculates a rate to be changed based on the estimated network bandwidth;
Based on the calculated rate, a packet transmitter that sends a request to change the rate to the counterpart terminal;
The terminal according to any one of supplementary notes 1 to 4, further comprising:
(Appendix 6)
The terminal according to any one of appendices 1 to 5, wherein the media data includes at least one of video data, audio data, and audio data.
(Appendix 7)
A communication system including the terminal according to any one of supplementary notes 1 to 6 and a packet transfer control device connected to the terminal via the network.
(Appendix 8)
A packet transmission / reception control method in a terminal connected to a network and transmitting / receiving a packet storing media data via the network,
A congestion detection step of detecting congestion of the network based on the received downstream packet;
A packet transmission / reception step for notifying a request for changing the rate of the media data to the counterpart terminal using the reverse direction of the network when congestion of the network is detected;
Packet transmission / reception control method including
(Appendix 9)
9. The packet transmission / reception control method according to appendix 8, wherein the congestion detection step extracts congestion information from the downstream packet and detects congestion of the network.
(Appendix 10)
The packet transmission / reception control method according to claim 9, wherein the congestion detection step extracts the congestion information by checking an ECN (Explicit Connection Notification) field of an IP (Internet Protocol) header portion of the downlink packet. .
(Appendix 11)
The request for changing the rate includes SIP (Session Initiation Protocol) / SDP (Session Description Protocol), CMR (Codec Mode Protocol), RTCP (RTP Control Protocol), and RTCP-APP (RTP Protocol Control). The packet transmission / reception control method according to any one of appendices 8 to 10, characterized in that any one of them is used.
(Appendix 12)
The packet transmission / reception step includes:
A bandwidth estimation step of estimating the bandwidth of the network based on the received downstream packet when congestion of the network is detected;
A rate calculating step for calculating a rate to be changed based on the estimated network bandwidth;
A sending step of sending a request to change the rate to the counterpart terminal based on the calculated rate;
The packet transmission / reception control method according to any one of appendices 8 to 11 including:
(Appendix 13)
The packet transmission / reception control method according to any one of appendices 8 to 12, wherein the media data includes at least one of video data, audio data, and audio data.
(Appendix 14)
A computer-readable recording medium that records a packet transmission / reception control program that causes a computer that is a terminal connected to a network to transmit and receive packets storing media data via the network, the packet transmission / reception control program comprising: On the computer,
A congestion detection procedure for detecting congestion of the network based on the received downstream packet;
A packet transmission / reception procedure for notifying a counterpart terminal of a request to change the rate of the media data using the reverse direction of the network when congestion of the network is detected;
Recording medium that executes

　１１０　ＳＩＰサーバ
　１３０　ＩＭＳ網
　１５０　モバイルネットワーク
　１７０、１７０Ａ　携帯端末
　１９０　パケット転送制御装置
　１９１　ＰＣＲＦ装置
　１９４　ｅＮｏｄｅＢ装置
　２５０　パケット受信部
　２５１　パケット送信部
　２５３　音声デコーダ
　２５４　レート設定部
　２５５　輻輳検出部
　２５６　音声エンコーダ
　２５７　帯域推定部
　２５８　レート設定部
　この出願は、２０１２年１２月３日に出願された、日本特許出願第２０１２−２６３９５６号を基礎とする優先権を主張し、その開示の全てをここに取り込む。 DESCRIPTION OF SYMBOLS 110 SIP server 130 IMS network 150 Mobile network 170, 170A Portable terminal 190 Packet transfer control device 191 PCRF device 194 eNodeB device 250 Packet reception unit 251 Packet transmission unit 253 Speech decoder 254 Rate setting unit 255 Congestion detection unit 256 Speech encoder 257 Band estimation Part 258 Rate Setting Part This application claims priority based on Japanese Patent Application No. 2012-263958 filed on December 3, 2012, the entire disclosure of which is incorporated herein.

Claims

　ネットワークに接続され、前記ネットワークを介してメディアデータを格納したパケットを送受信する端末であって、
　受信した下り方向のパケットに基づいて、前記ネットワークの輻輳を検出する輻輳検出部と、
　前記輻輳検出部が前記ネットワークの輻輳を検出した場合に、相手端末に対して前記メディアデータについてレートを変更する要求を前記ネットワークの逆の方向を用いて通知するパケット送受信部と、
を備えることを特徴とする端末。 A terminal connected to a network for transmitting and receiving packets storing media data via the network;
A congestion detector that detects congestion of the network based on the received downstream packet;
A packet transmission / reception unit for notifying a request for changing the rate of the media data to the counterpart terminal using the reverse direction of the network when the congestion detection unit detects congestion of the network;
A terminal comprising:
　前記輻輳検出部は、前記下り方向のパケットから輻輳情報を抽出して、前記ネットワークの輻輳を検出する、ことを特徴とする請求項１に記載の端末。 The terminal according to claim 1, wherein the congestion detection unit extracts congestion information from the downlink packet and detects congestion of the network.
　前記輻輳検出部は、前記下り方向のパケットのＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）ヘッダ部のＥＣＮ（Ｅｘｐｌｉｃｉｔ　Ｃｏｎｇｅｓｔｉｏｎ　Ｎｏｔｉｆｉｃａｔｉｏｎ）フィールドをチェックすることにより、前記輻輳情報を抽出する、ことを特徴とする請求項２に記載の端末。 The congestion detection unit extracts the congestion information by checking an ECN (Explicit Connection Notification) field of an IP (Internet Protocol) header portion of the downlink packet. Terminal.
　前記レートを変更する要求は、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）／ＳＤＰ（Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）、ＣＭＲ（Ｃｏｄｅｃ　Ｍｏｄｅ　Ｒｅｑｕｅｓｔ）、ＲＴＣＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）、およびＲＴＣＰ−ＡＰＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ−ＡＰＰｌｉｃａｔｉｏｎ　ｓｐｅｃｉｆｉｃ）のいずれか一つを用いることを特徴とする、請求項１乃至３のいずれか１つに記載の端末。 The request to change the rate is SIP (Session Initiation Protocol) / SDP (Session Description Protocol), CMR (Codec Mode Protocol), RTCP (RTP Control Protocol), and RTCP-APP (RTPProc) The terminal according to claim 1, wherein one of the terminals is used.
　前記パケット送受信部は、
　前記輻輳検出部が前記ネットワークの輻輳を検出した場合に、前記受信した下り方向のパケットに基づいて、前記ネットワークの帯域を推定する帯域推定部と、
　該推定したネットワークの帯域に基づいて、変更すべきレートを算出するレート設定部と、
　前記算出したレートに基づいて、前記レートを変更する要求を前記相手端末に送出するパケット送信部と、
を備えることを特徴とする請求項１乃至４のいずれか１つに記載の端末。 The packet transmitter / receiver
When the congestion detection unit detects congestion of the network, a bandwidth estimation unit that estimates a bandwidth of the network based on the received downstream packet;
A rate setting unit that calculates a rate to be changed based on the estimated network bandwidth;
Based on the calculated rate, a packet transmitter that sends a request to change the rate to the counterpart terminal;
The terminal according to any one of claims 1 to 4, further comprising:
　前記メディアデータは、映像データ、音声データ、オーディオデータの少なくとも一つからなる、請求項１乃至５のいずれか１つに記載の端末。 The terminal according to any one of claims 1 to 5, wherein the media data includes at least one of video data, audio data, and audio data.
　請求項１乃至６のいずれか１つに記載の端末と、前記ネットワークを介して前記端末に接続されたパケット転送制御装置と、を含む通信システム。 A communication system including the terminal according to any one of claims 1 to 6 and a packet transfer control device connected to the terminal via the network.
　ネットワークに接続され、前記ネットワークを介してメディアデータを格納したパケットを送受信する端末におけるパケット送受信制御方法であって、
　受信した下り方向のパケットに基づいて、前記ネットワークの輻輳を検出する輻輳検出ステップと、
　前記ネットワークの輻輳を検出した場合に、相手端末に対して前記メディアデータについてレートを変更する要求を前記ネットワークの逆の方向を用いて通知するパケット送受信ステップと、
を含むパケット送受信制御方法。 A packet transmission / reception control method in a terminal connected to a network and transmitting / receiving a packet storing media data via the network,
A congestion detection step of detecting congestion of the network based on the received downstream packet;
A packet transmission / reception step for notifying a partner terminal of a request to change the rate of the media data using the reverse direction of the network when congestion of the network is detected;
Packet transmission / reception control method including
　前記レートを変更する要求は、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）／ＳＤＰ（Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）、ＣＭＲ（Ｃｏｄｅｃ　Ｍｏｄｅ　Ｒｅｑｕｅｓｔ）、ＲＴＣＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）、およびＲＴＣＰ−ＡＰＰ（ＲＴＰ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ−ＡＰＰｌｉｃａｔｉｏｎ　ｓｐｅｃｉｆｉｃ）のいずれか一つを用いることを特徴とする、請求項８に記載のパケット送受信制御方法。 The request to change the rate is SIP (Session Initiation Protocol) / SDP (Session Description Protocol), CMR (Codec Mode Protocol), RTCP (RTP Control Protocol), and RTCP-APP (RTPProc) The packet transmission / reception control method according to claim 8, wherein one of them is used.
　前記パケット送受信ステップは、
　前記ネットワークの輻輳を検出した場合に、前記受信した下り方向のパケットに基づいて、前記ネットワークの帯域を推定するステップと、
　該推定したネットワークの帯域に基づいて、変更すべきレートを算出するステップと、
　前記算出したレートに基づいて、前記レートを変更する要求を前記相手端末に送出するステップと、
を含む請求項８又は９に記載のパケット送受信制御方法。 The packet transmission / reception step includes:
Estimating the bandwidth of the network based on the received downstream packet when congestion of the network is detected;
Calculating a rate to be changed based on the estimated network bandwidth;
Sending a request to change the rate to the counterpart terminal based on the calculated rate;
The packet transmission / reception control method according to claim 8 or 9, comprising: