JP5812612B2

JP5812612B2 - 通信制御装置及びプログラム、並びに、通信システム

Info

Publication number: JP5812612B2
Application number: JP2011009052A
Authority: JP
Inventors: 修吾芝
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2011-01-19
Filing date: 2011-01-19
Publication date: 2015-11-17
Anticipated expiration: 2031-01-19
Also published as: JP2012151675A

Description

この発明は、通信制御装置及びプログラム、並びに、通信システムに関し、例えば、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）を用いて、通信装置間で音声や映像等のメディアデータを送信する際の通信制御に関する。

一般に、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）を採用したネットワークを介して、音声通話や映像配信等のメディアデータを送信する通信システムでは、ＲＴＰ（非特許文献１参照）等のリアルタイム転送向けのプロトコルを使用して、Ｅｎｄ−ｔｏ−Ｅｎｄ（端末一端未間やサーバー端末間）のパケット転送を行なう。

ＩＥＴＦＲＦＣ３５５０

通常、インターネット等のＩＰネットワークにおけるパケット転送は、ＩＰで規定される仕様に従って転送が行われるが、全ての区間で常に安定した通信品質が保たれることが保証されるわけではない。そのため、通常、インターネット等のＩＰネットワークにおけるＥｎｄ−ｔｏ−Ｅｎｄの通信では、受信側でパケット順序が入れ替わってしまったり、重複したパケットを受信してしまったりすることがあった。

メディアデータを受信して出力（例えば、映像の表示や音声の出力）する通信装置（例えば、パソコンやセット・トップ・ボックス等）には、本来の順序から入れ替わったパケットや、重複したパケットを受信すると、動作が安定しない（例えば、メディアデータが映像の場合は、映像が乱れる）といった症状が生じる問題があった。

そのため、ＩＰネットワークを介してメディアデータを送信する際の通信品質を向上させることができる通信制御装置及びプログラム、並びに、通信システムが望まれている。

第１の本発明は、送信元の通信装置から宛先の通信装置へ向けて送出された、メディアデータの一部を有する送信パケットを中継する通信制御装置において、（１）送信元の通信装置と宛先の通信装置との間で確立された、メディアデータを送信するための送信セッションを管理するセッション管理手段と、（２）上記セッション管理手段により管理された送信セッションごとに、送信パケットを蓄積するセッションキューを１又は複数備える送信パケット蓄積手段と、（３）上記セッション管理手段で管理されている各送信セッションに係るシーケンス番号に従った順序により近い順序で、上記セッションキューに供給された送信パケットを、宛先の通信装置に向けて送出する送信制御を行う送信制御手段とを有し、（４）上記セッション管理手段は、管理している送信セッションごとに、上記送信手段により最後に送信された送信パケットに係るシーケンス番号である最終シーケンス番号も管理し、（５）上記送信手段は、いずれかの上記セッションキューに送信パケットが供給されると、当該セッションキューに対応する送信セッションに係る最終シーケンス番号と、最新に当該セッションキューに供給された送信パケットのシーケンス番号とを比較し、その比較結果を利用して、当該セッションキューに蓄積されている送信パケットの送信制御内容を決定し、（６）上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号の次の順序の番号であった場合には、最新に供給された送信パケットを宛先の通信装置に向けて送出し、さらに、最新に送出した送信パケットからシーケンス番号が昇順に連続する送信パケットが、当該セッションキューに蓄積されている場合には、それらの送信パケットを宛先の通信装置へ向けて送出し、（７）上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号の２以上後の順序であった場合には、最新に当該セッションキューに供給された送信パケットを、当該セッションキューに保持させておき、（８）上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号と一致した場合、又は、最終シーケンス番号よりも前の順序の番号であった場合には、最新に当該セッションキューに供給された送信パケットを廃棄することを特徴とする。

第２の本発明の通信制御プログラムは、（１）送信元の通信装置から宛先の通信装置へ向けて送出された、メディアデータの一部を有する送信パケットを中継する通信制御装置に搭載されたコンピュータを、（２）送信元の通信装置と宛先の通信装置との間で確立された、メディアデータを送信するための送信セッションを管理するセッション管理手段と、（３）上記セッション管理手段により管理された送信セッションごとに、送信パケットを蓄積するセッションキューを１又は複数備える送信パケット蓄積手段と、（４）上記セッション管理手段で管理されている各送信セッションに係るシーケンス番号に従った順序により近い順序で、上記セッションキューに供給された送信パケットを、宛先の通信装置に向けて送出する送信制御を行う送信制御手段として機能させ、（５）上記セッション管理手段は、管理している送信セッションごとに、上記送信手段により最後に送信された送信パケットに係るシーケンス番号である最終シーケンス番号も管理し、（６）上記送信手段は、いずれかの上記セッションキューに送信パケットが供給されると、当該セッションキューに対応する送信セッションに係る最終シーケンス番号と、最新に当該セッションキューに供給された送信パケットのシーケンス番号とを比較し、その比較結果を利用して、当該セッションキューに蓄積されている送信パケットの送信制御内容を決定し、（７）上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号の次の順序の番号であった場合には、最新に供給された送信パケットを宛先の通信装置に向けて送出し、さらに、最新に送出した送信パケットからシーケンス番号が昇順に連続する送信パケットが、当該セッションキューに蓄積されている場合には、それらの送信パケットを宛先の通信装置へ向けて送出し、（８）上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号の２以上後の順序であった場合には、最新に当該セッションキューに供給された送信パケットを、当該セッションキューに保持させておき、（９）上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号と一致した場合、又は、最終シーケンス番号よりも前の順序の番号であった場合には、最新に当該セッションキューに供給された送信パケットを廃棄することを特徴とする。

第３の本発明は、複数の通信装置と、送信元の通信装置から宛先の通信装置へ向けて送出された、メディアデータの一部を有する送信パケットを中継する通信制御装置とを備える通信システムにおいて、上記通信制御装置として第１の本発明の通信制御装置を適用したことを特徴とする通信システム。

本発明によれば、ＩＰネットワークを介してメディアデータを送信する際の通信品質を向上させることができる。

実施形態に係る通信システムの全体構成について示したブロック図である。実施形態に係るトラヒック制御装置の機能的構成について示したブロック図である。実施形態に係るセッション管理テーブルの内容例について示した説明図である。実施形態に係るセッション識別部がＩＰパケットの供給を受けてセッション管理テーブルの内容を更新する処理について示したフローチャートである。実施形態に係るセッション識別部が、定期的にセッション管理テーブルの内容を更新する処理について示したフローチャートである。実施形態に係るＲＴＰパケット振り分け部の処理について示したフローチャートである。実施形態に係るセッションキュー管理部のセッションキューにＲＴＰパケットが供給された場合の処理について示したフローチャートである。実施形態に係るセッションキュー管理部が定期的に保持しているＲＴＰパケットを送出する処理について示したフローチャートである。

（Ａ）主たる実施形態
以下、本発明による通信制御装置及びプログラム、並びに、通信システムの一実施形態を、図面を参照しながら詳述する。なお、この実施形態の通信制御装置は、トラヒック制御装置である。

（Ａ−１）実施形態の構成
図１は、この実施形態の通信システム１の全体構成を示すブロック図である。

通信システム１には、サーバ２０、及び２台のクライアント３０（３０−１、３０−２）が配置されており、ＩＰネットワークＮを介して相互にＩＰ通信可能となっている。なお、配置されるサーバ２０及びクライアント３０の台数は限定されないものである。

また、クライアント３０−１、３０−２がＩＰネットワークＮに接続する入口（ＩＰネットワークＮのエッジ）には、トラヒック制御装置１０が配置されており、クライアント３０は、トラヒック制御装置１０を介してサーバ２０と通信するものとする。すなわち、ここでは、サーバ２０とクライアント３０との間を流れるパケットは、全てトラヒック制御装置１０を中継して宛先へ到達するものとする。

ここでは、トラヒック制御装置１０は、クライアント３０から見てＩＰネットワークＮの入り口（エッジ）に、トラヒック制御装置１０が配置されているものとして説明するが、トラヒック制御装置１０が配置される位置はこれに限定されないものである。例えば、トラヒック制御装置１０は、ＩＰネットワークＮ内の中継ルート上に配置するようにしても良いが、よりクライアント３０に近い位置（少ないホップ数で到達することができる位置）に配置されていることが望ましい。

サーバ２０は、ＲＴＰにより、クライアント３０に対して映像や音声等のメディアデータの送信を行うものであり、クライアント３０は、サーバ２０から送信されたデータを受信して所定の出力を行う（例えば、受信した映像データをユーザに表示出力を行う）ものである。なお、クライアント３０によるメディアデータの出力方法は限定されないものである。

すなわち、サーバ２０はメディアデータが挿入されたＲＴＰパケットをクライアント３０に送信する。そして、クライアント３０は、受信したＲＴＰパケットに挿入されたメディアデータを取り出して所定の出力処理（復号処理等も含まれる）を行う。なお、ＲＴＰパケットとは、ＲＴＰプロトコルに準拠したパケット（データ単位）である。

サーバ２０については、例えば、既存のメディアデータを配信するサーバ（メディア配信サーバであって、ＲＴＰに対応したものであるもの）を適用することができるので詳細については説明を省略する。

また、クライアント３０についても、既存のメディア配信サーバ等からＲＴＰによりメディアデータを受信することができる通信装置（例えば、パソコンやセット・トップ・ボックス等の端末）を適用することができるので詳しい説明については省略する。

また、ここではサーバ２０からそれぞれのクライアント３０−１、３０−２へのメディアデータ（ＲＴＰパケット）の送信は、ユニキャストにより行われるものとする。すなわち、サーバ２０では、２台のクライアント３０−１、３０−２のそれぞれに対して別個のＲＴＰセッションが確立しているものとする。

次に、トラヒック制御装置１０の概要について説明する。

上述の通り、トラヒック制御装置１０は、サーバ２０とクライアント３０との間を流れるパケットを中継するものである。トラヒック制御装置１０は、サーバ２０からクライアント３０へ送信されたＲＴＰパケットについて所定の通信制御処理を行い、宛先のクライアント３０へ送信する。具体的には、トラヒック制御装置１０は、受信したＲＴＰパケットをセッションごとにキューイングし、セッションごとのＲＴＰパケットの並べ替え、廃棄、送信タイミングの調整等を行う。

トラヒック制御装置１０において、ＲＴＰパケット以外のパケットの処理については限定されないものであるが、ここでは、既存のルータ等と同様に受信の都度宛先へ向けて転送するものとする。なお、トラヒック制御装置１０が受信したパケットについて転送する際に、必要に応じてアドレス変換等のパケットの加工を行うようにしても良いが、ここでは説明を簡易にするため、上述のような加工はせずにそのまま転送するものとして説明する。

次に、トラヒック制御装置１０の内部構成について説明する。

図２は、トラヒック制御装置１０の内部構成について示したブロック図である。

トラヒック制御装置１０は、トラヒック制御装置１０、送受信ポート１１、送受信ポート１２、セッション識別部１３、ＲＴＰパケット振り分け部１４、セッションキュー管理部１５、及びセッション管理テーブル１６を有している。

トラヒック制御装置１０は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、ハードディスクなどのプログラムの実行構成、及び、他の通信装置と通信をするためのインタフェースを有する情報処理装置に、実施形態の通信制御プログラム等をインストールすることにより構築するようにしても良く、その場合でもトラヒック制御装置１０の機能的構成は図２のように示すことができる。また、図２に示すトラヒック制御装置１０の各構成要素について、一部又は全部をハードウェア（例えば、専用チップ）により構築するようにしても良い。

送受信ポート１１は、ＩＰネットワークＮ内の上位側のネットワーク装置（例えば、ルータやレイヤ３スイッチ等）と接続するためのインタフェースである。すなわち、トラヒック制御装置１０は、送受信ポート１１を用いて、ＩＰネットワークＮを介してサーバ２０と通信（パケットの送受信）を行う。

送受信ポート１２は、下位側（クライアント３０）と接続するためのインタフェースである。図１においては、説明を簡易にするために、トラヒック制御装置１０はクライアント３０と直接接続するように図示しているが、トラヒック制御装置１０とクライアント３０との間の接続構成については限定されないものであり、他のネットワーク装置（例えば、Ｌ２スイッチ、レイヤ３スイッチ、ルータ等）を経由して接続するようにしても良い。図１においては図示を省略しているが、ここでは、トラヒック制御装置１０は、送受信ポート１２から他のネットワーク装置（例えば、Ｌ２スイッチ等）を経由して、クライアント３０−１、３０−２と接続しているものとする。

なお、図２では、トラヒック制御装置１０は、２つの送受信ポートを備えているが、トラヒック制御装置１０が備えるインタフェースの種類及び数は限定されないものであり、ＩＰネットワークＮとの接続方式やクライアント３０との接続方式に応じたものを備えるようにすれば良い。

セッション管理テーブル１６は、当該トラヒック制御装置１０が現在中継しているＲＴＰのセッションを管理するためのテーブルである。

図３は、セッション管理テーブル１６の内容例について示した説明図である。

図３に示すように、セッション管理テーブル１６には、ＲＴＰセッションごとに、セッション識別情報、セッション番号、及び通過カウンタの項目の情報が格納されている。なお、図３では、１行で１つのＲＴＰセッションに関する情報を示している。

セッション識別情報は、当該ＲＴＰセッションを識別するために必要な情報である。図３では、セッション識別情報として、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、及び宛先ポート番号の項目の情報が含まれている。

送信元ＩＰアドレスは、当該ＲＴＰセッションの送信元（ＲＴＰパケットの送信元）の通信装置のＩＰアドレスを示している。言い換えると、送信元ＩＰアドレスは、当該ＲＴＰセッションに係るＲＴＰパケットにおける、ＩＰプロトコルヘッダの送信元ＩＰアドレスである。

宛先ＩＰアドレスは、当該ＲＴＰセッションの宛先（ＲＴＰパケットの宛先）の通信装置のＩＰアドレスを示している。言い換えると、宛先ＩＰアドレスは、当該ＲＴＰセッションに係るＲＴＰパケットにおける、ＩＰプロトコルヘッダの宛先ＩＰアドレスである。

送信元ポート番号は、当該ＲＴＰセッションに係るＲＴＰパケットの送信元ポート番号（ＵＤＰプロトコルの送信元ポート番号）を示している。

宛先ポート番号は、当該ＲＴＰセッションに係るＲＴＰパケットの宛先ポート番号（ＵＤＰプロトコルの宛先ポート番号）を示している。

ここでは、セッション識別情報には、以上のような項目の情報が含まれているものとするが、受信したＲＴＰパケットからいずれのセッションに該当するのかが識別可能であれば、セッション識別情報に含まれる情報の組み合わせについては限定されないものである。例えば、送信元ＩＰアドレス及び又は宛先ＩＰアドレスだけでＲＴＰセッションが識別可能であれば、セッション識別に最低限必要な項目の情報だけを、セッション識別情報に含めるようにしても良い。

セッション番号は、セッション管理テーブル１６において、各ＲＴＰセッションに付与される識別子である。セッション番号は、ＲＴＰセッションごとに異なる番号が付与される。セッション番号の表示形式については限定されないものであり、ＲＴＰセッションごとにユニークな内容であれば、任意の文字列や記号（例えば、アルファベット等）を用いるようにしても良い。

通過カウンタは、当該ＲＴＰセッションについて、当該トラヒック制御装置１０が中継したＲＴＰパケットの数を数えるためのカウンタである。

セッション管理テーブル１６には、以上のような項目の情報が含まれているが、セッション管理テーブル１６の内容を更新する処理については、後述する動作説明において詳述する。

セッション識別部１３は、送受信ポート１１で受信したパケットのうち、ＲＴＰパケットについて抽出し、セッション管理テーブル１６の内容にしたがって、そのＲＴＰパケットがいずれのセッションに属するのか等を判定する。また、セッション識別部１３は、受信したＲＴＰパケットが、セッション管理テーブル１６で管理されていないＲＴＰセッションのいずれにも該当しない場合には、セッション管理テーブル１６に新たなＲＴＰセッションの情報を追加し、新たにセッション番号を付与する。

セッション識別部１３は、ＲＴＰパケットについては、当該ＲＴＰパケットに関する判定結果とともに、ＲＴＰパケット振り分け部１４へ引き渡す。例えば、セッション識別部１３は、ＲＴＰパケットを受信すると、そのＲＴＰパケットに係るＲＴＰセッションのセッション番号をセッション管理テーブル１６から取得し、当該ＲＴＰパケットと共に、ＲＴＰパケット振り分け部１４に引き渡すようにしても良い。

ＲＴＰパケット振り分け部１４は、セッション識別部１３から与えられたＲＴＰパケットについて、ＲＴＰセッションごとに振り分けて、セッションキュー管理部１５に供給する。

セッションキュー管理部１５は、１又は複数のセッションキュー１７を有しており、ＲＴＰセッションごとに１つのセッションキュー１７が割り当てられている。すなわち、セッションキュー管理部１５には、セッション管理テーブル１６で管理されているＲＴＰセッションのそれぞれに対応するセッションキュー１７が存在している。そして、ＲＴＰパケット振り分け部１４は、セッション識別部１３から与えられたＲＴＰパケットを、対応するＲＴＰセッションのセッションキュー１７に振り分ける。

図２において、セッションキュー管理部１５には、Ｎ個のセッションキュー１７（１７−１〜１７−Ｎ）が生成されている様子について示している。セッションキュー管理部１５では、セッション管理テーブル１６で、ＲＴＰセッションの追加又は削除があった場合に、セッションキュー１７の割当が変更される。

セッションキュー１７は、該当するＲＴＰセッションのＲＴＰパケット（ＲＴＰパケット振り分け部１４で振り分けられたＲＴＰパケット）を蓄積し、蓄積したＲＴＰパケットについて所定の処理を行うものである。セッションキュー１７は、例えば、蓄積したＲＴＰパケットの送出、並べ替え、廃棄等を行う。セッションキュー管理部１５における各セッションキュー１７の処理の詳細については後述する動作説明において詳述する。

セッションキュー管理部１５上のセッションキュー１７の数については、予め固定数そなえて、その中から各ＲＴＰセッションに割り当てて用いるようにしても良いし、必要な数（セッション管理テーブル１６で管理されているセッション数）だけ動的に生成して割り当てるようにしても良い。各セッションキュー１７については、ハードウェア的に実現（例えば、専用チップにより構築）するようにしても良いし、ソフトウェア的に実現（例えば、セッションキューごとにメモリ空間上の領域を動的に割り当てて構築）するようにしても良い。このように、セッションキュー管理部１５上でセッションキュー１７を実現する具体的な構成は限定されないものである。

（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態の通信システム１におけるトラヒック制御装置１０の動作を説明する。

（Ａ−２−１）セッション識別部の動作について
ここでは、まず、セッション識別部１３の動作について説明する。

図４は、セッション識別部１３が、セッション管理テーブル１６の内容を更新する処理について示したフローチャートである。

送受信ポート１１でＩＰパケットが受信され、セッション識別部１３に供給されたものとする（Ｓ１０１）。

次に、セッション識別部１３は、供給されたＩＰパケットが、ＲＴＰパケットであるか否かを判定し（Ｓ１０２）、ＲＴＰパケットであると判定した場合には、後述するステップＳ１０３から動作し、そうでないと判定した場合には後述するステップＳ１０８から動作する。セッション識別部１３において、当該ＩＰパケットが、ＲＴＰパケットであるか否かを判定する方法については限定されないものであるが、例えば、ヘッダ情報等を解析して判定するようにしても良い。具体的な例としては、参考文献１（特開２００６−７４１７５号公報）の記載技術を用いて、判定するようにしても良い。

上述のステップＳ１０２において、セッション識別部１３により当該ＩＰパケットがＲＴＰパケットでないと判定された場合には、セッション識別部１３は、当該ＩＰパケットを、送受信ポート１２に引渡し、当該ＩＰパケットを宛先へ向けて送出させる（Ｓ１０８）。

上述のステップＳ１０２において、セッション識別部１３により当該ＩＰパケットがＲＴＰパケットであると判定された場合には、セッション識別部１３は、当該ＩＰパケットのヘッダ情報等を解析し、当該ＲＴＰパケットがいずれのＲＴＰセッションに係るものであるのかを判定するのに必要な情報を抽出する（Ｓ１０３）。ここでは、セッション識別部１３は、受信したＲＴＰパケットのＩＰプロトコルヘッダの送信元ＩＰアドレス、宛先ＩＰアドレス、およびＵＤＰプロトコルヘッダの送信元ポート番号、宛先ポート番号を抽出するものとする。

次に、セッション識別部１３は、セッション管理テーブル１６で管理されているＲＴＰセッションのうち、上述のステップＳ１０３で抽出した情報の全ての項目が一致するものを検索し（Ｓ１０４）、検出できた場合には後述するステップＳ１０６から動作し、検出できなかった場合には後述するステップＳ１０５の処理から動作する。

上述のステップＳ１０４において、セッション管理テーブル１６で管理されているＲＴＰセッションから該当するものが検出できなかった場合、すなわち、セッション識別部１３に供給されたＲＴＰパケットが、まだセッション管理テーブル１６で管理されていないＲＴＰセッションに係るＲＴＰパケットであった場合には、セッション識別部１３は、セッション管理テーブル１６に、当該ＲＴＰパケットに係るＲＴＰセッションの情報（上述のステップＳ１０３で抽出した各項目に基づく情報）を、セッション管理テーブル１６に追加する（Ｓ１０５）。セッション識別部１３は、セッション管理テーブル１６に新たに追加したＲＴＰセッションのセッション識別情報として、上述のステップＳ１０３で抽出した各項目の情報を適用する。すなわち、上述のステップＳ１０３で抽出する情報は、セッション識別情報の項目と一致している必要がある。そして、セッション識別部１３は、セッション管理テーブル１６に新たに追加したＲＴＰセッションの情報のうち、セッション番号については、セッション管理テーブル１６上でユニークな番号（未だ使用されていない番号）を付与し、さらに、通過カウンタとして初期値（０）を設定する。

上述のステップＳ１０５の処理が完了した場合、又は、上述のステップＳ１０４において、セッション管理テーブル１６から該当するＲＴＰセッションの情報が検出できた場合、セッション識別部１３は、該当するＲＴＰセッションの情報のうち通過カウンタの項目の値をインクリメント（＋１）する（Ｓ１０６）。

次に、セッション識別部１３は、供給されたＲＴＰパケットと、当該ＲＴＰパケットに係るセッション番号の情報を、ＲＴＰパケット振り分け部１４へ引き渡す（Ｓ１０７）。

次に、セッション識別部１３が、セッション管理テーブル１６のＲＴＰセッションの情報を削除する動作について、図５を用いて説明する。

図５に示すフローチャートは、セッション識別部１３が、セッション管理テーブル１６で管理されているＲＴＰセッションの情報（各行の情報）を必要に応じて削除する処理について示している。セッション識別部１３は、当該処理を定期的（例えば、３０秒間隔としてもよくその長さは限定されない）に起動し（Ｓ２０１）、まず、セッション管理テーブル１６の各ＲＴＰセッションの情報のうち、通過カウンタの値が０となっているＲＴＰセッションを検索し、該当するＲＴＰセッションの情報については、セッション管理テーブル１６から削除すると判定する（Ｓ２０２）。

そして、セッション識別部１３は、上述のステップＳ２０２で、削除すると判定されたＲＴＰセッションの情報を、セッション管理テーブル１６から削除する処理を行う（Ｓ２０３）。なお、上述のステップＳ２０２で、セッション管理テーブル１６から該当するＲＴＰセッション（通過カウンタの値が０となっているＲＴＰセッション）が検出されなかった場合には、ステップＳ２０３の処理は行われない。

そして、セッション識別部１３は、上述のステップＳ２０２で、削除すると判定されなかったＲＴＰセッションの情報のそれぞれについて、通過カウンタの項目の値を全て０に更新し（Ｓ２０４）、処理を終了する。そして上述の通り、以降セッション識別部１３では、定期的に上述のステップＳ２０１の処理から動作することになる。なお、セッション管理テーブル１６から全てのＲＴＰセッションの情報が削除されている場合には、ステップＳ２０４の処理は行われないことになる。

次に、ＲＴＰパケット振り分け部１４の動作について図６を用いて説明する。

まず、セッション識別部１３から、ＲＴＰパケット振り分け部１４に、ＲＴＰパケット及び、そのＲＴＰパケットのセッション番号が供給されたものとする（Ｓ３０１）。

そして、ＲＴＰパケット振り分け部１４は、供給されたセッション番号に対応するセッションキュー１７に、当該ＲＴＰパケットを引き渡して（Ｓ３０２）処理を終了する。

図７は、ＲＴＰパケット振り分け部１４から、セッションキュー管理部１５のいずれかのセッションキュー１７に、ＲＴＰパケットが供給された場合のセッションキュー管理部１５の動作について示したフローチャートである。

なお、後述する図７の説明で用いる「最終シーケンス番号」は、各セッションキュー１７において、最後に送出されたＲＴＰパケットのシーケンス番号であるものとする。すなわち、セッションキュー管理部１５では、各セッションキュー１７について、最終シーケンス番号が管理されているものとする。なお、各ＲＴＰセッションに係る最終シーケンス番号については、セッション管理テーブル１６に項目を追加して管理するようにしても良い。

まず、ＲＴＰパケット振り分け部１４から、セッションキュー管理部１５のいずれかのセッションキュー１７（以下、セッションキュー１７−ｍと呼ぶものとする）に、ＲＴＰパケットが供給されたものとする（Ｓ４０１）。

次に、セッションキュー管理部１５では、上述のステップＳ４０１で供給されたＲＴＰパケットのヘッダ情報からシーケンス番号が抽出され（Ｓ４０２）、抽出されたシーケンス番号と、セッションキュー１７−ｍに係る最終シーケンス番号＋１が比較される（Ｓ４０３）。ここでは、上述のステップＳ４０２で抽出された当該ＲＴＰパケットのシーケンス番号をＳ１、セッションキュー１７−ｍの最終シーケンス番号をＳ２と表すものとする。そして、上述のステップＳ４０３の比較処理において、Ｓ１＞（Ｓ２＋１）と判定された場合には、後述するステップＳ４０４の処理から動作し、Ｓ１＝Ｓ２＋１と判定された場合には、後述するステップＳ４０７から動作し、Ｓ１＜（Ｓ２＋１）と判定された場合には、後述するステップＳ４０９の処理から動作する。

上述のステップＳ４０３の比較処理の結果、Ｓ１＞（Ｓ２＋１）と判定された場合には、まず、セッションキュー管理部１５では、セッションキュー１７−ｍで保持しているＲＴＰパケットの数が、所定の最大保持数に達しているか否かが確認される（Ｓ４０４）。そして、セッションキュー１７−ｍで保持しているＲＴＰパケットの数が最大保持数を超えていると判定された場合には、後述するステップＳ４０５の処理から動作し、そうでないと判定された場合には、後述するステップＳ４０６の処理から動作する。

上述のステップＳ４０４で、セッションキュー１７−ｍが保持しているＲＴＰパケットの数が最大保持数を超えていると判定された場合には、セッションキュー管理部１５は、セッションキュー１７−ｍが保持しているＲＴＰパケットの中から、シーケンス番号が最小となるＲＴＰパケットから順に、シーケンス番号が昇順に連続しているすべてのＲＴＰパケットを、送受信ポート１２に引き渡して送信させる（Ｓ４０５）。さらに、セッションキュー管理部１５は、セッションキュー１７−ｍについて管理している最終シーケンス番号を、ステップＳ４０５で送信した最後のＲＴＰパケットのシーケンス番号に更新する。

次に、セッションキュー管理部１５は、セッションキュー１７−ｍに供給されたＲＴＰパケットを保持させて（Ｓ４０６）、処理を終了する。

上述のステップＳ４０３の比較処理の結果、Ｓ１＞（Ｓ２＋１）と判定された場合とは、最新に供給されたＲＴＰパケットのシーケンス番号が、最終シーケンス番号よりも、２以上後の順序（次の順序よりもさらに後の順序）であることを示している。すなわち、上述のステップＳ４０３の比較処理の結果、Ｓ１＞（Ｓ２＋１）と判定された場合とは、最終シーケンス番号の次の順序のＲＴＰパケットがトラヒック制御装置１０に到達する前に、さらにその次以後の順序（最終シーケンス番号の２以上後の順序）のＲＴＰパケットが、トラヒック制御装置１０に到達していることを示している。したがって、この場合、最終シーケンス番号の２以上後の順序のＲＴＰパケットを先に送信してしまうと、後に送信するＲＴＰパケットの順序が入れ替わってしまうので、セッションキュー管理部１５では、上述のステップＳ４０６に示すように、当該ＲＴＰパケットをセッションキュー１７−ｍに一旦保持させて、後に最終シーケンス番号の次の順序のＲＴＰパケット送信を待ち、その後送信することになる。

また、上述のステップＳ４０４、Ｓ４０５では、セッションキュー１７−ｍが保持しているＲＴＰパケットが最大保持数に達している場合には、多少送信順序が入れ替わったり、間が空いたりしても保持しているＲＴＰパケットを送信している。セッションキュー１７−ｍに最大保持数以上のＲＴＰパケットが保持されているということは、相当時間クライアント３０側にＲＴＰパケットが送信されていないことになる。上述の通り、クライアント３０側でＲＴＰパケットがシーケンス番号順に到達することが望ましいが、そのために、長時間クライアント３０側にパケットが供給されなくなってしまうのを避ける方が良いため、上述のステップＳ４０４、Ｓ４０５の処理を設けている。長時間クライアント３０側にパケットが供給されない場合、クライアント３０で出力するメディアデータがなくなり、例えば、メディアデータが映像データであれば映像が途切れる等の問題が発生することになる。

なお、上述のステップＳ４０４、Ｓ４０５の処理については、省略するようにしても良いが、その場合、長時間クライアント３０側にパケットが供給されない場合がある。

上述のステップＳ４０３の比較処理において、Ｓ１＝Ｓ２＋１と判定された場合には、セッションキュー管理部１５は、供給されたＲＴＰパケットを送受信ポート１２に引き渡して送信させる（Ｓ４０７）。さらに、セッションキュー管理部１５は、セッションキュー１７−ｍについて管理している最終シーケンス番号を、ステップＳ４０７で送信したＲＴＰパケットのシーケンス番号に更新する。

上述のステップＳ４０３の比較処理において、Ｓ１＝Ｓ２＋１と判定された場合とは、最新に供給されたＲＴＰパケットのシーケンス番号が、最終シーケンス番号の次の順序の番号であることを示している。したがって、この場合、セッションキュー管理部１５は、最新に供給されたＲＴＰパケットを送信すると、シーケンス番号の順序通りにＲＴＰパケットを送信できることになる。

次に、セッションキュー管理部１５は、セッションキュー１７−ｍで保持しているＲＴＰパケットの中に、最終シーケンス番号＋１のシーケンス番号のＲＴＰパケットがあれば、以降昇順に連続するシーケンス番号を持つＲＴＰパケットすべてを、送受信ポート１２に引き渡して送信させ（Ｓ４０８）、処理を終了する。また、セッションキュー管理部１５は、セッションキュー１７−ｍについて管理している最終シーケンス番号を、最後に送信したＲＴＰパケットのシーケンス番号に更新する。

上述のステップＳ４０３の比較処理において、Ｓ１＜（Ｓ２＋１）と判定された場合には、セッションキュー管理部１５は、供給されたＲＴＰパケットを廃棄して（Ｓ４０９）処理を終了する。

上述のステップＳ４０３の比較処理において、Ｓ１＜（Ｓ２＋１）と判定された場合とは、最新に供給されたＲＴＰパケットのシーケンス番号が、最終シーケンス番号と一致する場合、又は、最終シーケンス番号よりも前の番号であることを示している。この場合、セッションキュー管理部１５が最新に供給されたＲＴＰパケットを送信すると、重複するＲＴＰパケットを送信することになってしまったり、クライアント３０側で出力には用いられない場合（例えば、クライアント３０側で、既に後のシーケンス番号のデータを出力している場合）があり、上述のステップＳ４０９のように廃棄することが望ましい。

なお、セッションキュー管理部１５で、既に送信したＲＴＰパケットのシーケンス番号を記憶しておき（例えば、直近の所定数のものだけ記憶するようにしても良い）、既に送信したシーケンス番号と重複するシーケンス番号のＲＴＰパケットだけを廃棄し、該当しないＲＴＰパケットについては宛先に送信するようにしても良い。これにより、セッションキュー管理部１５で、重複するＲＴＰパケットの送信を防止しつつ、中継するＲＴＰパケットの欠損が発生する頻度を低減することができる。

次に、セッションキュー管理部１５が、定期的に各セッションキュー１７により保持されているＲＴＰパケットを送出する動作について図８を用いて説明する。

セッションキュー管理部１５は、各セッションキュー１７により保持されているＲＴＰパケットについて送出する処理を、定期的（例えば、２０ｍｓ間隔としても良く長さは限定されない）に起動する（Ｓ５０１）。

そして、セッションキュー管理部１５は、前回定期起動動作の確認時から、各セッションキュー１７で保持しているＲＴＰパケットすべてを対象とし、シーケンス番号の小さい順に、受信した送受信ポート１１と反対側の送受信ポート１２から、対象とするＲＴＰパケットを送信する。また、最終シーケンス番号を、最後に送信したＲＴＰパケットのシーケンス番号とする（Ｓ５０２）。

上述の通り、クライアント３０側でＲＴＰパケットがシーケンス番号順に到達することが望ましいが、そのために、長時間クライアント３０側にパケットが供給されないことは避けた方が良い。そこで、セッションキュー管理部１５では、定期起動動作の処理（上述のステップＳ５０２の処理）により、所定時間以上滞留しているＲＴＰパケットについては、強制的に送信する処理を行っている。なお、図８のフローチャートに示す処理は、省略するようにしても良いが、その場合、長時間クライアント３０側にパケットが供給されない場合がある。

セッションキュー管理部１５では、定期起動動作の処理の完了時に各セッションキュー１７で保持しているＲＴＰパケットと、その後、次の定期起動動作の処理が開始するまでに供給されたＲＴＰパケットとを区別可能な形式で保持しているものとする。ＲＴＰパケットを区別する方式は限定されないものであるが、例えば、各セッションキュー１７の中で、定期起動動作の処理の完了時に各セッションキュー１７で保持しているＲＴＰパケットを記憶する領域と、その後、次の定期起動動作の処理が開始するまでに供給されるＲＴＰパケットを記憶する領域を別に割り当てるようにしても良い。また、例えば、セッションキュー管理部１５で、定期起動動作の処理の完了時に保持している各ＲＴＰパケットのデータに、その旨を示すフラグ情報を付与しておき、その後、次の定期起動動作の処理が開始するまでに供給されたＲＴＰパケットと区別（すなわち、新たに供給されたＲＴＰパケットにはフラグ情報が付与されていない）するようにしても良い。

（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。

トラヒック制御装置１０では、ＲＴＰセッション単位に一定期間ＲＴＰパケットを保持し、ＲＴＰパケット順序の入れ替え等の補正を行うことにより、リアルタイム性を損なわずに、シーケンス番号に従った順序により近い順序で送信している。これにより、サーバ２０からクライアント３０へ送信するＲＴＰセッションによる通信の品質を向上させ、クライアント３０の動作を安定させる等の効果を奏することができる。

また、トラヒック制御装置１０では、遅れて到着したＲＴＰパケットがあった場合（セッションキュー１７の最終シーケンス番号よりもシーケンス番号が前のＲＴＰパケットが到達した場合）には、当該ＲＴＰパケットを廃棄することで、クライアント３０に到着するＩＰパケットの順序入れ替えを少なくしている。

（Ｂ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

（Ｂ−１）上記の実施形態では、トラヒック制御装置１０を、上述の通信制御を行う専用装置として構築する例について説明しているが、例えば、ルータ、レイヤ３スイッチ等のゲートウェイとして構築し、当該ゲートウェイに供給されるＲＴＰパケットについて同様の通信制御を行う構成を付加するようにしても良い。

（Ｂ−２）上記の実施形態では、トラヒック制御装置１０が１台の構成として説明しているが、複数台配置するようにしても良い。例えば、サーバ２０がクライアント３０に対してＩＰ電話サービスを提供する装置（ＩＰ−ＰＢＸ等）である場合には、クライアント３０との間では双方向に音声データが挿入されたＲＴＰパケットが流れることになる。その場合に、サーバ２０側（サーバ２０により近い位置）にもトラヒック制御装置１０を配置して、クライアント３０から送出されるＲＴＰパケットの通信制御（パケットの並び替え等）を行うようにしても良い。

なお、上記の実施形態において、トラヒック制御装置１０は、サーバ２０とクライアント３０との間の通信を中継するものとして説明したが、トラヒック制御装置１０が中継する対象の通信装置の種類やその組み合わせは限定されないものである。例えば、トラヒック制御装置１０を、サーバとクライアントとの間の通信だけなく、クライアント間やサーバ間の通信について用いるようにしても良い。

（Ｂ−３）上記の実施形態では、トラヒック制御装置１０において通信制御対象となっているパケットはＲＴＰパケットであるものとして説明しているが、他のプロトコルその他のリアルタイム転送向けのプロトコルを通信制御対象とするようにしても良い。

（Ｂ−４）上記の実施形態では、サーバ２０とクライアント３０との間を流れるパケットは、全てトラヒック制御装置１０を中継して宛先へ到達するものとして説明したが、トラヒック制御装置１０において通信制御対象となるパケット（上記の実施形態では、ＲＴＰパケット等メディアデータのパケットが該当する）だけについて、トラヒック制御装置１０を中継させ、その他のパケット（例えば、呼制御等のシグナリングに係るパケット等）については、トラヒック制御装置１０を中継しないようなネットワーク構成としても良い。

（Ｂ−５）上記の実施形態では、サーバ２０から各クライアント３０へのメディアデータの送信はユニキャストにより行われるものとして説明したが、マルチキャストにより行うようにしても良い。その場合、セッション管理テーブル１６では、宛先ＩＰアドレス及び宛先ポート番号として、当該マルチキャストのチャンネルに係るＩＰアドレス及びポート番号が登録されることになる。

１…通信システム、２０…サーバ、３０、３０−１、３０−２…クライアント、Ｎ…ＩＰネットワーク、１０…トラヒック制御装置、１１…送受信ポート、１２…送受信ポート、１３…セッション識別部、１４…ＲＴＰパケット振り分け部、１５…セッションキュー管理部、１６…セッション管理テーブル、１７、１７−１〜１７−Ｎ…セッションキュー。

Claims

送信元の通信装置から宛先の通信装置へ向けて送出された、メディアデータの一部を有する送信パケットを中継する通信制御装置において、
送信元の通信装置と宛先の通信装置との間で確立された、メディアデータを送信するための送信セッションを管理するセッション管理手段と、
上記セッション管理手段により管理された送信セッションごとに、送信パケットを蓄積するセッションキューを１又は複数備える送信パケット蓄積手段と、
上記セッション管理手段で管理されている各送信セッションに係るシーケンス番号に従った順序により近い順序で、上記セッションキューに供給された送信パケットを、宛先の通信装置に向けて送出する送信制御を行う送信制御手段とを有し、
上記セッション管理手段は、管理している送信セッションごとに、上記送信手段により最後に送信された送信パケットに係るシーケンス番号である最終シーケンス番号も管理し、
上記送信手段は、いずれかの上記セッションキューに送信パケットが供給されると、当該セッションキューに対応する送信セッションに係る最終シーケンス番号と、最新に当該セッションキューに供給された送信パケットのシーケンス番号とを比較し、その比較結果を利用して、当該セッションキューに蓄積されている送信パケットの送信制御内容を決定し、
上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号の次の順序の番号であった場合には、最新に供給された送信パケットを宛先の通信装置に向けて送出し、さらに、最新に送出した送信パケットからシーケンス番号が昇順に連続する送信パケットが、当該セッションキューに蓄積されている場合には、それらの送信パケットを宛先の通信装置へ向けて送出し、
上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号の２以上後の順序であった場合には、最新に当該セッションキューに供給された送信パケットを、当該セッションキューに保持させておき、
上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号と一致した場合、又は、最終シーケンス番号よりも前の順序の番号であった場合には、最新に当該セッションキューに供給された送信パケットを廃棄する
ことを特徴とする通信制御装置。
上記セッション識別手段は送信パケットがＲＴＰパケットであるかを判別し、
上記送信制御手段は、ＲＴＰパケットと判別された送信パケットについてのみ、上記送信制御の処理を行い、その他の種類のパケットについては、受信の都度宛先に転送する処理を行う
ことを特徴とする請求項１に記載の通信制御装置。
上記セッション管理手段は送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、および宛先ポート番号に基づいてセッションを識別することを特徴とする請求項２に記載の通信制御装置。
上記セッション管理手段は、上記セッション識別手段で、ＲＴＰパケットと判別をした送信パケットに対し、いずれのＲＴＰセッションに該当するかを識別し、識別の結果、当該ＲＴＰセッションが、管理中のいずれのＲＴＰセッションにも属さないと確認された場合、新たな管理対象のＲＴＰセッションとして当該ＲＴＰセッションを追加し、上記セッション識別手段で、所定期間ＲＴＰパケットの識別がなされないＲＴＰセッションについては管理対象から削除することを特徴とする請求項２又は３に記載の通信制御装置。
上記送信制御手段は、上記送信パケット蓄積手段に蓄積されているＲＴＰパケットのうち、蓄積時間が所定時間を超えたものについて、強制的に送信する処理を行うことを特徴とする請求項１〜４のいずれかに記載の通信制御装置。
送信元の通信装置から宛先の通信装置へ向けて送出された、メディアデータの一部を有する送信パケットを中継する通信制御装置に搭載されたコンピュータを、
送信元の通信装置と宛先の通信装置との間で確立された、メディアデータを送信するための送信セッションを管理するセッション管理手段と、
上記セッション管理手段により管理された送信セッションごとに、送信パケットを蓄積するセッションキューを１又は複数備える送信パケット蓄積手段と、
上記セッション管理手段で管理されている各送信セッションに係るシーケンス番号に従った順序により近い順序で、上記セッションキューに供給された送信パケットを、宛先の通信装置に向けて送出する送信制御を行う送信制御手段として機能させ、
上記セッション管理手段は、管理している送信セッションごとに、上記送信手段により最後に送信された送信パケットに係るシーケンス番号である最終シーケンス番号も管理し、
上記送信手段は、いずれかの上記セッションキューに送信パケットが供給されると、当該セッションキューに対応する送信セッションに係る最終シーケンス番号と、最新に当該セッションキューに供給された送信パケットのシーケンス番号とを比較し、その比較結果を利用して、当該セッションキューに蓄積されている送信パケットの送信制御内容を決定し、
上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号の次の順序の番号であった場合には、最新に供給された送信パケットを宛先の通信装置に向けて送出し、さらに、最新に送出した送信パケットからシーケンス番号が昇順に連続する送信パケットが、当該セッションキューに蓄積されている場合には、それらの送信パケットを宛先の通信装置へ向けて送出し、
上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号の２以上後の順序であった場合には、最新に当該セッションキューに供給された送信パケットを、当該セッションキューに保持させておき、
上記送信手段は、いずれかの上記セッションキューに送信パケットが供給された場合に、最新に当該セッションキューに供給された送信パケットのシーケンス番号が、当該セッションキューに対応する送信セッションに係る最終シーケンス番号と一致した場合、又は、最終シーケンス番号よりも前の順序の番号であった場合には、最新に当該セッションキューに供給された送信パケットを廃棄する
ことを特徴とする通信制御プログラム。
複数の通信装置と、送信元の通信装置から宛先の通信装置へ向けて送出された、メディアデータの一部を有する送信パケットを中継する通信制御装置とを備える通信システムにおいて、
上記通信制御装置として請求項１〜５のいずれかに記載の通信制御装置を適用したことを特徴とする通信システム。