(57)【特許請求の範囲】
【請求項１】
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう送信装置と受信装置とを有する通信システムの制御方法であって、
前記受信装置は、
自局の受信バッファの空き容量を前記送信装置に通知し、
前記送信装置は、
前記受信装置から通知された前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、
前記受信装置から通知された前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう、
ことを特徴とする、通信システムの制御方法。
【請求項２】
前記送信装置は、
前記第２の優先度を有するデータの容量が前記閾値以下である場合に、前記第２の優先度を有するデータを前記受信装置へ送信する一方、前記第２の優先度を有するデータの容量が前記閾値よりも大きい場合に、前記第２の優先度を有するデータの送信を待機する、
ことを特徴とする、請求項１記載の通信システムの制御方法。
【請求項３】
前記送信装置は、
前記第１の優先度を有するデータの発生数と前記第２の優先度を有するデータの発生数とに応じて、前記閾値を動的に変更する、
ことを特徴とする、請求項１または２に記載の通信システムの制御方法。
【請求項４】
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう通信装置であって、
受信側の受信バッファの空き容量に関する情報を受信する受信部と、
前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう処理部と、をそなえた、
ことを特徴とする、通信装置。
【請求項５】
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう送信装置と受信装置とを有する通信システムであって、
前記受信装置は、
自局の受信バッファの空き容量を前記送信装置に通知する送信部をそなえ、
前記送信装置は、
前記通知を受信する受信部と、
前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう処理部と、をそなえた、
ことを特徴とする、通信システム。
【請求項６】
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう通信装置に搭載されたコンピュータに、
受信側の受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を実行させ、
前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムの制御方法、通信装置、通信システム及びプログラムに関する。例えば、前記通信装置には、ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう通信装置が含まれる。
【背景技術】
【０００２】
図１は、ＬＴＥ（Long Term Evolution）方式の無線通信システムの構成の一例を示す図である。
この図１に示す無線通信システム１００は、例えば、ユーザ端末（ＵＥ：User Equipment）の一例としての無線端末と無線リンクにより通信可能な複数の無線基地局（eNode B、以下、ｅＮＢと略記する）３００−１〜３００−３と、その上位装置であるＭＭＥ（Mobility Management Entity）／ＳＧＷ（Serving GateWay）２００−１，２００−２と、をそなえる。なお、以下では、ｅＮＢ３００−１〜３００−３を区別しない場合、単にｅＮＢ３００と表記し、ＭＭＥ／ＳＧＷ２００−１，２００−２を区別しない場合、単にＭＭＥ／ＳＧＷ２００と表記する。
【０００３】
上記の無線通信システム１００において、ｅＮＢ３００とＭＭＥ／ＳＧＷ２００との間との通信は、Ｓ１インタフェースと呼ばれる装置間インタフェースを介して行なわれる。一方、ｅＮＢ３００間の通信は、Ｘ２インタフェースと呼ばれる装置間インタフェースを介して行なわれる。
ここで、Ｓ１インタフェースは、ｅＮＢ３００とＭＭＥ／ＳＧＷ２００との間を、ＩＰ（Internet Protocol）を用いて接続し、制御プレーン（C-Plane）及び／又はユーザプレーン（U-plane）の信号を伝送するのに用いられる。一方、Ｘ２インタフェースは、ｅＮＢ３００−１〜３００−３間を、ＩＰを用いて接続し、制御プレーン及び／又はユーザプレーンの信号を伝送するために用いられる。
【０００４】
また、Ｓ１インタフェース及びＸ２インタフェースなどにおいて、制御信号を伝送する際に用いる通信プロトコルの一つに、ＳＣＴＰ（Stream Control Transmission Protocol）がある。
ＳＣＴＰは、ＩＰ上でシーケンス番号とチェックサムとを基にパケットの正統性を検証することで、パケットの多重送信、喪失などをできるだけ回避して信頼性を確保しつつ情報転送を行なえるようにするトランスポート層の通信プロトコルの一つである。ＳＣＴＰは、例えば、下記の非特許文献１〜３によって規定されている。
【０００５】
ＳＣＴＰ機能をもつネットワークエンティティ（以下、ノードともいう）は、１又は複数のエンドポイントと呼ばれる論理的な終端点をもち、他のノードのエンドポイントとアソシエーションと呼ばれる論理的な接続（ＳＣＴＰリンク）を確立する。その際、ノード（エンドポイント）は、クライアントとサーバという２つの状態をもち、クライアントは接続（アソシエーション）確立要求の送信側として動作し、サーバは前記接続確立要求の受信側として動作することが要求される。
【０００６】
ＳＣＴＰにおけるパケットは、ＳＣＴＰ共通ヘッダと、これに続く１又は複数のチャンクと呼ばれるデータブロックからなる。チャンクには、制御信号（メッセージ）が格納される制御チャンクと、ユーザデータが格納されるデータチャンクとがある。制御チャンクは、アソシエーションの確立（初期化：INIT）や解放のときなどに送信される。
例えば、アソシエーション確立時には、制御チャンクとして、INITチャンク、INIT-ACKチャンク、COOKIE-ECHOチャンク、COOKIE-ACKチャンク等が用いられる。一方、アソシエーション解放時には、制御チャンクとして、SHUTDOWNチャンク、SHUTDOWN-ACKチャンク、SHUTDOWN-COMPLETEチャンク等が用いられる。
【０００７】
次に、ＬＴＥにおけるＳ１インタフェースの制御プレーンのプロトコルスタックの一例を図２に示し、ＬＴＥにおけるＸ２インタフェースの制御プレーンのプロトコルスタックの一例を図３に示す。
図２に示すように、Ｓ１インタフェースでは、制御プレーンのプロトコルスタックとして、下位層から順に、物理（ＰＨＹ）層、データリンク（ＭＡＣ：Media Access Control）層、ＩＰ層、ＳＣＴＰ層、Ｓ１−ＡＰ（アプリケーション）層が規定される。一方、Ｘ２インタフェースでは、図３に示すように、制御プレーンのプロトコルスタックとして、下位層から順に、物理（ＰＨＹ）層、データリンク（ＭＡＣ）層、ＩＰ層、ＳＣＴＰ層、Ｘ２−ＡＰ（アプリケーション）層が規定される。
【０００８】
ところで、インターネット網では、トランスポート層（レイヤ４）の機能を提供するプロトコルとして、ＴＣＰ（Transmission Control Protocol）とＵＤＰ（User Datagram Protocol）とが用いられることが多い。これらは、インターネット網で使用される標準的な通信プロトコルである。
ＵＤＰは、コネクションレスサービスをサポートしており、メッセージの転送には使用できない。一方、ＴＣＰは、コネクションオリエンテッドサービスをサポートしているが、信頼性のあるデータ転送を実現できる代わりに、転送遅延が発生したり、優先度を付けた転送ができなかったりするため、メッセージの転送に使用することは困難である。
【０００９】
これに対し、ＳＣＴＰは、輻輳制御を行なうことが可能な、高い信頼性を有する通信プロトコルであり、例えば、以下のような特徴を有する。
（１）メッセージ指向の通信プロトコルである。即ち、メッセージ単位でフレーム化を行なうことができるため、データグラムの構造や順序を見失わずにすむ。
（２）シーケンス番号とチェックサムとに基づき、パケットの正当性を検証することにより、パケットの多重送信などを回避して信頼性を確保することができる。
【００１０】
（３）マルチホーミング対応の通信プロトコルであり、１つのストリームに対して、通信路を複数持たせることができるので、障害回復機能に優れている。
ＳＣＴＰでは、メッセージの送信側と受信側との間で通信コネクション（アソシエーション）を確立して通信を行なう。
１つのアソシエーションに対して、内部で論理的に複数の個別の通信用チャネル（ストリーム）をサポートできるという点で、アソシエーションはＴＣＰのコネクションと異なる。
【００１１】
図４に例示するように、アソシエーション内の全てのストリーム（例えば、ストリーム＃０１，ストリーム＃０２，ストリーム＃０３，ストリーム＃０４）は互いに独立しているが、ある１つのアソシエーションに関連付けられている。各ストリームには、ストリーム番号（例えば、＃０１〜＃０４）が付与され、各ストリーム番号はアソシエーションを流れるＳＣＴＰパケット内にエンコードされる。
【００１２】
マルチストリーミングでは、ブロックされたストリームがアソシエーション内の他のストリームに影響を与えないという点が重要である。
ストリームは、ユーザ毎に割り当てられ、例えば、呼接続処理のデータを送受信する際に使用される。
なお、ＳＣＴＰに関する技術として、下記特許文献１には、ストリームを制御する層において、他の通信に対して緊急性を有するメッセージを優先的に処理する方法が提案されている。
【００１３】
また、下記特許文献２には、局間の通信において、優先度に応じてデータを送信する方法が提案されている。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２０１０−０８７９９０号公報
【特許文献２】特開２０１１−０４４８００号公報
【非特許文献】
【００１５】
【非特許文献１】L. Ong、外１名、“An Introduction to the Stream Control Transmission Protocol (SCTP)”、［online］、2002年5月、［平成24年2月21日検索］、インターネット〈URL：https://www.ietf.org/rfc/rfc3286.txt〉
【非特許文献２】R. Stewart、外４名、“Stream Control Transmission Protocol (SCTP) Specification Errata and Issues”、［online］、2006年4月、［平成24年2月21日検索］、インターネット〈URL：https://www.ietf.org/rfc/rfc4460.txt〉
【非特許文献３】R. Stewart, Ed.、“Stream Control Transmission Protocol”、［online］、2007年9月、［平成24年2月21日検索］、インターネット〈URL：https://www.ietf.org/rfc/rfc4960.txt〉
【発明の概要】
【発明が解決しようとする課題】
【００１６】
近年、携帯電話などの無線端末の普及に伴い、無線端末から警察、救急、消防等の緊急連絡先への緊急通報（例えば、１１０番や１１９番）の件数が年々増加している。
警視庁の調査によると、２０１０年１月〜１１月の日本における１１０番の受領件数は、８４９万１２８５件であり、２００９年の同期間に比して、２３万６９５８件（２．３％）増加している。
【００１７】
また、上記８４９万１２８５件のうち、無線端末からの通報件数は、５５９万３２４１件であり、全体の半数以上を占めている。
例えば、災害などの発生時には、優先度が相対的に小さい一般呼によって無線基地局が混雑することがあるが、ＳＣＴＰを用いた通信では、優先度に応じた通信は規定されておらず、優先度が相対的に大きい緊急呼についての処理が遅延することがある。
【００１８】
そこで、本発明は、ＳＣＴＰを用いた通信において、優先度に応じた制御方法を提供することを目的の１つとする。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
【課題を解決するための手段】
【００１９】
（１）第１の案として、例えば、ＳＣＴＰを用いて確立した通信リンクを介して通信を行なう送信装置と受信装置とを有する通信システムの制御方法であって、前記受信装置は、自局の受信バッファの空き容量を前記送信装置に通知し、前記送信装置は、前記受信装置から通知された前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、前記受信装置から通知された前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう、通信システムの制御方法を用いることができる。
【００２１】
（３）さらに、第３の案として、例えば、ＳＣＴＰを用いて確立した通信リンクを介して通信を行なう通信装置であって、受信側の受信バッファの空き容量に関する情報を受信する受信部と、前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう処理部と、をそなえた、通信装置を用いることができる。
【００２３】
（５）さらに、第５の案として、例えば、ＳＣＴＰを用いて確立した通信リンクを介して通信を行なう送信装置と受信装置とを有する通信システムであって、前記受信装置は、自局の受信バッファの空き容量を前記送信装置に通知する送信部をそなえ、前記送信装置は、前記通知を受信する受信部と、前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう処理部と、をそなえた、通信システムを用いることができる。
【００２５】
（７）さらに、第７の案として、例えば、ＳＣＴＰを用いて確立した通信リンクを介して通信を行なう通信装置に搭載されたコンピュータに、受信側の受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を実行させ、前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を実行させるためのプログラムを用いることができる。
【発明の効果】
【００２７】
ＳＣＴＰを用いた通信において、優先度に応じた制御方法を提供することができる。
【図面の簡単な説明】
【００２８】
【図１】ＬＴＥ方式の無線通信システムの構成の一例を示す図である。
【図２】Ｓ１インタフェースの制御プレーンのプロトコルスタックの一例を示す図である。
【図３】Ｘ２インタフェースの制御プレーンのプロトコルスタックの一例を示す図である。
【図４】ＳＣＴＰアソシエーションの一例を示す図である。
【図５】緊急呼が遅延するケースの一例を示す図である。
【図６】緊急呼が遅延するケースの他の一例を示す図である。
【図７】一実施形態に係る通信システムの構成の一例を示す図である。
【図８】図７に示すｅＮＢの構成の一例を示す図である。
【図９】一実施形態に係る制御方法の一例を示す図である。
【図１０】a_rwnd，a_rwnd_em，a_rwnd_nm及びem_buf_minの関係を示す図である。
【図１１】一実施形態に係る制御方法の一例を示す図である。
【図１２】一実施形態に係る制御方法の一例を示す図である。
【図１３】高優先度用バッファ量の動的制御の一例を示す図である。
【図１４】一実施形態に係る制御方法の一例を示す図である。
【図１５】一実施形態に係る制御方法の一例を示す図である。
【図１６】ｅＮＢのハードウェア構成の一例を示す図である。
【図１７】対向ノードのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００２９】
以下、図面を参照して本発明の実施形態を説明する。ただし、以下に示す実施形態は、あくまでも例示に過ぎず、以下に示す実施形態で明示しない種々の変形や技術の適用を排除する意図はない。即ち、以下に示す実施形態を、本発明の趣旨を逸脱しない範囲で種々変形して実施してもよい。
〔１〕一実施形態
（１．１）緊急呼の遅延発生の一例について
緊急呼が遅延する一例を図５に示す。なお、前提として、例えば、呼処理制御を行なうｅＮＢとＭＭＥとの間で、ＳＣＴＰアソシエーション（通信リンク）を確立するとともに複数のストリーム（例えば、図４に例示したように、ストリーム＃０１，ストリーム＃０２，ストリーム＃０３，ストリーム＃０４）を設定し、さらに、設定した複数のストリームのうちの１つ（例えば、ストリーム＃０１）を一般呼に比して高優先度の緊急呼の設定制御に用いることを決めておく。
【００３０】
このとき、図５に例示するように、ＵＥから一般呼の設定要求がｅＮＢに送信されると（ステップＡ１）、ｅＮＢのＳ１−ＡＰ層及びＳＣＴＰ層は、ＭＭＥのＳ１−ＡＰ層及びＳＣＴＰ層に対して接続要求を送信する（ステップＡ２）。
ここで、ｅＮＢの対向ノードの一例であるＭＭＥの受信バッファに空きが有る場合、ＭＭＥは、受信バッファに空きが有ることを示すＳＡＣＫ（Selective ACKknoledgement）応答をｅＮＢに返信する（ステップＡ３）。
【００３１】
これにより、ＵＥとＳＧＷとの間で一般呼についての通信路（ストリーム＃０２〜＃０４の少なくともいずれか）が確立される（ステップＡ４）。
ここで、確立済みの一般呼について、通信種別の変更やハンドオーバなどの制御が生じた場合、ｅＮＢのＳ１−ＡＰ層及びＳＣＴＰ層は、ＭＭＥのＳ１−ＡＰ層及びＳＣＴＰ層に対して制御メッセージを送信する（ステップＡ５）。
【００３２】
このとき、ＭＭＥの受信バッファに空きが無いことがあり、このような場合、ＭＭＥは、受信バッファに空きが無いことを示すＳＡＣＫ応答をｅＮＢに返信する（ステップＡ６）。
ＭＭＥから受信バッファに空きが無いことを示すＳＡＣＫ応答を受信したｅＮＢは、上記制御が完了していないことを検知し、上記制御メッセージを送信してから所定の時間が経過した場合に、制御メッセージを再送する（ステップＡ７）。
【００３３】
ここで、ＵＥから一般呼よりも優先度の高い緊急呼の設定要求がｅＮＢに送信されると（ステップＢ１）、ｅＮＢのＳＣＴＰ層は、ＭＭＥの受信バッファに空きが生じるまで緊急呼の接続要求の送信を待機する（ステップＢ２）。
そして、ＭＭＥの受信バッファに空きが生じると、ＭＭＥのＳＣＴＰ層は、ｅＮＢのＳＣＴＰ層へ、受信バッファに空きが有ることを示すＳＡＣＫ応答をｅＮＢに送信する（ステップＡ８）。
【００３４】
これにより、ｅＮＢとＭＭＥとの間で上記制御メッセージに対応する制御が完了する（ステップＡ９）。
次に、ｅＮＢのＳＣＴＰ層は、ステップＡ８で受信したＳＡＣＫ応答に基づいて、ＭＭＥの受信バッファに空きが生じたことを検知し、ＭＭＥのＳ１−ＡＰ層及びＳＣＴＰ層に対して緊急呼の接続要求を送信する（ステップＢ３）。
【００３５】
そして、ＭＭＥは、受信バッファに空きが有ることを示すＳＡＣＫ応答をｅＮＢに返信する（ステップＢ４）。
これにより、ＵＥとＳＧＷとの間で緊急呼についての通信路（ストリーム＃０１）が確立される（ステップＢ５）。
以上のように、ＭＭＥの受信バッファが不足している場合、緊急呼の処理が遅延することがある。
【００３６】
（１．２）緊急呼の遅延発生の他の一例について
また、緊急呼が遅延する他の一例を図６に示す。なお、上記と同様の前提として、例えば、呼処理制御を行なうｅＮＢとＭＭＥとの間で、ＳＣＴＰアソシエーション（通信リンク）を確立するとともに複数のストリーム（例えば、図４に例示したように、ストリーム＃０１，ストリーム＃０２，ストリーム＃０３，ストリーム＃０４）を設定し、さらに、設定した複数のストリームのうちの１つ（例えば、ストリーム＃０１）を一般呼に比して高優先度の緊急呼の設定制御に用いることを決めておく。
【００３７】
このとき、図６に例示するように、ＵＥから一般呼の設定要求がｅＮＢに送信されると（ステップＣ１）、ｅＮＢのＳ１−ＡＰ層及びＳＣＴＰ層は、ＭＭＥのＳ１−ＡＰ層及びＳＣＴＰ層に対して接続要求を送信する（ステップＣ２）。
ここで、ｅＮＢの対向ノードの一例であるＭＭＥの受信バッファに空きが有る場合、ＭＭＥは、受信バッファに空きが有ることを示すＳＡＣＫ応答をｅＮＢに返信する（ステップＣ３）。
【００３８】
これにより、ＵＥとＳＧＷとの間で一般呼についての通信路（ストリーム＃０２〜＃０４の少なくともいずれか）が確立される（ステップＣ４）。
ここで、確立済みの一般呼について、通信種別の変更やハンドオーバなどの制御が生じた場合、ｅＮＢのＳ１−ＡＰ層及びＳＣＴＰ層は、ＭＭＥのＳ１−ＡＰ層及びＳＣＴＰ層に対して制御メッセージを送信する（ステップＣ５）。
【００３９】
このとき、ＭＭＥの受信バッファに空きが有れば、ＭＭＥは、受信バッファに空きが有ることを示すＳＡＣＫ応答をｅＮＢに返信する（ステップＣ６）。
しかしながら、ＭＭＥの処理能力がデータ処理に追いつかない場合、上記制御メッセージはバッファリングされて（ステップＣ７）、制御処理は行なわれない。
ここで、ＵＥから一般呼よりも優先度の高い緊急呼の設定要求がｅＮＢに送信されると（ステップＤ１）、ｅＮＢのＳ１−ＡＰ層及びＳＣＴＰ層は、ＭＭＥのＳＣＴＰ層に対して緊急呼の接続要求を送信する（ステップＤ２）。
【００４０】
しかしながら、ＭＭＥの処理能力がデータ処理に追いつかない場合、上記制御メッセージと同様に、緊急呼の接続要求はバッファリングされて（ステップＤ３）、接続処理は行なわれない。
ここで、ＭＭＥが上記制御メッセージを処理できるようになると、ＭＭＥのＳＣＴＰ層は、上記制御メッセージの処理を開始し（ステップＣ８）、当該制御メッセージに対応する制御が完了する（ステップＣ９）。
【００４１】
次に、ＭＭＥが上記緊急呼の接続要求を処理できるようになると、ＭＭＥのＳＣＴＰ層は、上記接続要求の処理を開始し（ステップＤ４）、ＭＭＥの受信バッファに空きが有れば、ＭＭＥは、受信バッファに空きが有ることを示すＳＡＣＫ応答をｅＮＢに返信する（ステップＤ５）。
これにより、ＵＥとＳＧＷとの間で緊急呼についての通信路（ストリーム＃０１）が確立される（ステップＤ６）。
【００４２】
以上のように、ＭＭＥのデータ処理能力が不足している場合、緊急呼の処理が遅延することがある。
そこで、本例では、優先度が相対的に高いデータについて、遅延の発生を抑制すべく、以下に例示する制御方法を提案する。
（１．３）一実施形態に係る通信システムについて
本発明の一実施形態に係る通信システム１の構成の一例を図７に示す。
【００４３】
この図７に例示するように、通信システム１は、ユーザ装置（ＵＥ）２と、無線基地局（ｅＮＢ）３と、ＭＭＥ４と、ＳＧＷ５とをそなえ、コア網６に接続されている。
ＵＥ２は、ｅＮＢ３と無線通信する無線端末である。ＵＥ２は、例えば、ユーザによって移動可能な通信装置であり、その意味で、無線移動端末あるいは移動局（ＭＳ：Mobile Station）と同義である。
【００４４】
ＵＥ２は、ｅＮＢ３と無線通信を行なう際、呼の確立要求をｅＮＢ３に送信する。なお、当該呼には、例えば、優先度が相対的に小さい一般呼と、一般呼よりも優先度が大きい緊急呼とがある。
ｅＮＢ３は、セルやセクタなどで構成される通信サービスエリア（無線エリア）を提供し、当該通信サービスエリア内に位置するＵＥ２と無線通信することができる。また、ｅＮＢ３は、Ｘ２インタフェースを介して、他のｅＮＢ３と有線により通信することができる。さらに、ｅＮＢ３は、Ｓ１インタフェースを介して、ＭＭＥ４及びＳＧＷ５と有線により通信することができる。
【００４５】
ＭＭＥ４は、ＵＥ２の位置登録や、呼出し、ハンドオーバなどを管理し、ＳＧＷ５は、ユーザデータを中継する。
コア網６は、通信システム１と接続される外部ネットワークであって、例えば、ＰＧＷ（Packet data network GateWay）及びＨＳＳ（Home Subscriber Server）を有している。なお、ＰＧＷは、外部ネットワークと接続する装置であり、ＨＳＳは、端末識別番号などのユーザ情報を管理する装置である。
【００４６】
本例のｅＮＢ３は、ＭＭＥ４，ＳＧＷ５または他のｅＮＢ３との間で、ＳＣＴＰを用いた通信を行なう。
即ち、ｅＮＢ３は、ＳＣＴＰを用いて確立した通信リンクを介して通信を行なう送信装置の一例として機能するとともに、ＭＭＥ４，ＳＧＷ５などの対向ノードは、ＳＣＴＰを用いて確立した通信リンクを介して通信を行なう受信装置の一例として機能する。
【００４７】
（１．４）ｅＮＢ３の構成の一例について
ここで、ｅＮＢ３の構成の一例を図８に示す。
図８に示すｅＮＢ３は、例えば、無線信号を送受信するアンテナ３０１と、アンテナ３０１で受信した無線信号について無線受信処理を行なう一方、アンテナ３０１から送信する無線信号について無線送信処理を行なう無線（ＲＦ：Radio Frequency）部３０２とをそなえる。
【００４８】
また、ｅＮＢ３は、例えば、ディジタル信号をアナログ信号に変換するディジタル／アナログ変換部（ＤＡＣ：Digital to Analog Converter）３０３と、アナログ信号をディジタル信号に変換するアナログ／ディジタル変換部（ＡＤＣ：Analog to Digital Converter）３０４とをそなえる。
さらに、ｅＮＢ３は、例えば、送信部３０６及び受信部３０７を有しベースバンド処理を行なうベースバンド（ＢＢ）部３０５と、無線通信を制御する無線通信制御部３０８とをそなえる。
【００４９】
また、ｅＮＢ３は、例えば、自局３が提供するセルやセクタなどの無線エリアを制御する無線エリア制御部３０９と、自局３とＵＥ２との間で設定される呼の処理を制御する呼処理制御部３１０と、ＭＭＥ４，ＳＧＷ５などの対向ノードとの通信を制御するネットワーク通信制御部３１１と、ＭＭＥ４，ＳＧＷ５などの対向ノードとのインタフェース機能を提供する有線インタフェース（ＩＦ：Interface）部３１６とをそなえる。
【００５０】
ここで、ネットワーク通信制御部３１１は、例示的に、バッファ管理部３１２と、データ種別判別部３１３と、ウィンドウサイズ算出部３１４と、処理能力推定部３１５とをそなえる。
バッファ管理部３１２は、ＭＭＥ４，ＳＧＷ５などの対向ノードにおける受信バッファの空き状況を管理し、当該管理結果に基づいて、データの送信制御を行なう。また、バッファ管理部３１２は、後述する処理能力推定部３１５での推定結果に基づいて、データの送信制御を行なってもよい。
【００５１】
データ種別判別部３１３は、送信データのデータ種別を判別する。具体的には例えば、データ種別判別部３１３は、Ｓ１−ＡＰ層やＸ２−ＡＰ層から指定される送信データ種別に関する情報に基づいて、送信データが一般呼に関するデータであるか、一般呼よりも高優先度の緊急呼に関するデータであるかを判別する。なお、当該判別結果は、データ種別判別部３１３からバッファ管理部３１２に通知され、データの送信制御に用いられる。
【００５２】
ウィンドウサイズ算出部３１４は、ＭＭＥ４，ＳＧＷ５などの対向ノードにおける受信バッファの使用状況または空き状況を定期あるいは不定期に算出する。具体的には例えば、ウィンドウサイズ算出部３１４は、ＭＭＥ４，ＳＧＷ５などの対向ノードから適宜通知される受信ウィンドウ保証量広告（a_rwnd: Advertised Receiver Window Credit）や、送信データサイズなどに基づいて、対向ノード４，５における受信バッファの使用状況または空き状況を算出する。なお、当該算出結果は、ウィンドウサイズ算出部３１４からバッファ管理部３１２に通知され、データの送信制御に用いられる。
【００５３】
処理能力推定部３１５は、ＭＭＥ４，ＳＧＷ５などの対向ノードのデータ処理能力を推定する。具体的には例えば、処理能力推定部３１５は、送信データ量，データの送信間隔及び対向ノード４，５から報告されるa_rwnd値に基づいて、対向ノード４，５のデータ処理能力を推定する。なお、当該推定結果は、処理能力推定部３１５からバッファ管理部３１２に通知され、データの送信制御に用いられる。
【００５４】
（１．５）ｅＮＢ３の送信制御動作の一例について
次に、ｅＮＢ３の送信制御動作の一例として、高優先度通信用（緊急呼用）のバッファ予約処理について説明する。
まず、図９に例示するように、ネットワーク通信制御部３１１によって送信制御が開始されると（ステップＳ１）、バッファ管理部３１２は、緊急呼などの高優先度の通信向けに最低限確保しておきたい対向ノード４，５のバッファサイズ（最低保障バッファサイズ：em_buf_min）を設定する（ステップＳ２）。なお、em_buf_minの値は、緊急呼の発生頻度、緊急呼の発生回数、緊急呼のデータサイズなどに基づいて決定されてもよい。
【００５５】
そして、ｅＮＢ３は、ＭＭＥ４，ＳＧＷ５などの対向ノードとの間でINITチャンク及びINIT-ACKチャンクなどの制御チャンクを交換（ハンドシェイク）し、対向ノード４，５からの制御チャンクに含まれる受信ウィンドウ保証量広告（a_rwnd）を、アンテナ３０１を介して受信する（ステップＳ３）。なお、a_rwndは、データの送信側が対向ノード４，５において最も直近に計算した受信ウィンドウサイズを保存しておくためのＳＣＴＰ変数であり、a_rwndの値によって送信側は、対向ノード４，５の受信バッファの使用状況（空き状況）を把握することができる。また、a_rwndは、対向ノード４，５からのＳＡＣＫに含まれることがある。さらに、ＳＣＴＰでは、受信側が１つのＳＣＴＰパケットのために少なくとも１５００バイトは受信可能でなければならないことが規定されているため、a_rwndは、１５００バイト以上の値となる。
【００５６】
次に、バッファ管理部３１２は、ステップＳ２で設定したem_buf_minとステップＳ３で受信したa_rwndとを比較し、a_rwndがem_buf_minよりも大きいかどうかを判定する（ステップＳ４）。
ここで、a_rwndがem_buf_min以下であると判定した場合（ステップＳ４のＮｏルート）、対向ノード４，５の受信バッファサイズに緊急呼などの高優先度のデータをバッファする余裕がないと判定し、バッファ管理部３１２は、高優先度通信用のバッファを予約しない。
【００５７】
一方、a_rwndがem_buf_minよりも大きいと判定した場合（ステップＳ４のＹｅｓルート）、対向ノード４，５の受信バッファサイズに緊急呼などの高優先度のデータをバッファする余裕があると判定し、バッファ管理部３１２は、高優先度通信用のバッファを予約する。具体的には例えば、バッファ管理部３１２は、ステップＳ３で受信したa_rwndの値を、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）として採用するとともに、a_rwnd_emからem_buf_minを差し引いた値を、低優先度通信用（一般呼用）のバッファサイズ（a_rwnd_nm）として採用する（ステップＳ５）。
【００５８】
即ち、対向ノード４，５における現時点での受信ウィンドウサイズ（a_rwnd）と、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）と、低優先度通信用（一般呼用）のバッファサイズ（a_rwnd_nm）と、最低保障バッファサイズ（em_buf_min）との関係は、図１０に示すとおりとなる。
再び図９に戻り、ｅＮＢ３は、対向ノード４，５との間でＳＣＴＰアソシエーションを確立し（ステップＳ６）、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）を設定できたかどうかを判定する（ステップＳ７）。
【００５９】
ここで、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）を設定できなかった（即ち、ステップＳ４でＮｏルートへ進んだ）と判定した場合（ステップＳ７のＮｏルート）、ｅＮＢ３は、緊急呼のバッファ予約処理を行なわず処理を終了する（ステップＳ９）。この場合、ｅＮＢ３は、例えば、優先度を考慮しないＳＣＴＰ送信制御を行なうようにしてもよい。
【００６０】
一方、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）を設定できた（即ち、ステップＳ４でＹｅｓルートへ進んだ）と判定した場合（ステップＳ７のＹｅｓルート）、ｅＮＢ３は、ＳＣＴＰアソシエーション内のいずれかのストリーム（例えば、ストリーム＃０１）を緊急呼の通信用に設定し（ステップＳ８）、処理を終了する（ステップＳ９）。
【００６１】
次に、以上のようにして確立したＳＣＴＰアソシエーションにおいて行なわれるデータ送信制御について説明する。
まず、図１１に例示するように、呼の接続要求などのＳＣＴＰデータの送信契機が発生すると制御が開始され（ステップＳ１０）、データ種別判別部３１３は、送信データが相対的に低優先度のデータ（例えば、一般呼に関するデータ）であるか、送信データが相対的に高優先度のデータ（例えば、緊急呼に関するデータ）であるかを判別する（ステップＳ１１）。なお、データ種別の判別は、例えば、ｅＮＢ３のアプリケーション層から指定されるデータ種別に関する情報に基づいて行なわれる。
【００６２】
ここで、送信データが一般呼に関するデータであると判別された場合（ステップＳ１１の「一般呼」ルート）、バッファ管理部３１２は、低優先度通信用（一般呼用）のバッファサイズ（a_rwnd_nm）と当該データのサイズ（d_size_nm）とを比較し、a_rwnd_nmがd_size_nm以上であるかどうかを判定する（ステップＳ１２）。
a_rwnd_nmがd_size_nm以上であると判定した場合（ステップＳ１２のＹｅｓルート）、対向ノード４，５の受信バッファサイズに一般呼などの低優先度のデータをバッファする余裕があると判定し、バッファ管理部３１２は、一般呼に関する新規データチャンクを対向ノード４，５へ送信する（ステップＳ１５）。
【００６３】
一方、a_rwnd_nmがd_size_nmよりも小さいと判定した場合（ステップＳ１２のＮｏルート）、対向ノード４，５の受信バッファサイズに一般呼などの低優先度のデータをバッファする余裕がないと判定し、バッファ管理部３１２は、一般呼に関する新規データチャンクを一般呼用の送信キューへ送出（キューイング）し、送信を待機する（ステップＳ１４）。
【００６４】
また、ステップＳ１１において、送信データが緊急呼に関するデータであると判別された場合（ステップＳ１１の「緊急呼」ルート）、バッファ管理部３１２は、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）と当該データのサイズ（d_size_em）とを比較し、a_rwnd_emがd_size_em以上であるかどうかを判定する（ステップＳ１３）。
a_rwnd_emがd_size_em以上であると判定した場合（ステップＳ１３のＹｅｓルート）、対向ノード４，５の受信バッファサイズに緊急呼などの高優先度のデータをバッファする余裕があると判定し、バッファ管理部３１２は、緊急呼に関する新規データチャンクを対向ノード４，５へ送信する（ステップＳ１６）。なお、このとき、緊急呼に関する新規データチャンクと一般呼に関する新規データチャンクとは、チャンク結合しない方が望ましい。
【００６５】
一方、a_rwnd_emがd_size_emよりも小さいと判定した場合（ステップＳ１３のＮｏルート）、対向ノード４，５の受信バッファサイズに緊急呼などの高優先度のデータをバッファする余裕がないと判定し、バッファ管理部３１２は、緊急呼に関する新規データチャンクを緊急呼用の送信キューへ送出（キューイング）し、送信を待機する（ステップＳ１７）。なお、上述した例では、ｅＮＢ３が、一般呼用の送信キューと緊急呼用の送信キューとを個別に有している例について説明したが、１つの送信キューを一般呼と緊急呼とで共用するようにしてもよい。ただ、ｅＮＢ３における送信待ちに起因する遅延を考慮すれば、一般呼用の送信キューと緊急呼用の送信キューとを個別に有している方が望ましい。
【００６６】
即ち、バッファ管理部３１２は、対向ノード（受信側）４，５の受信バッファの空き容量（a_rwnd＝a_rwnd_em）に基づいて、第１の優先度を有するデータ（例えば、緊急呼）の送信制御を行なう一方、前記受信バッファの空き容量よりも小さい閾値（a_rwnd_nm）に基づいて、第１の優先度よりも低い優先度の第２の優先度を有するデータ（例えば、一般呼）の送信制御を行なう。
【００６７】
そして、上記の各ステップＳ１４〜Ｓ１７の処理に次いで、ウィンドウサイズ算出部３１４は、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）と低優先度通信用（一般呼用）のバッファサイズ（a_rwnd_nm）とを更新する。具体的には例えば、ウィンドウサイズ算出部３１４は、現在のa_rwnd_emから緊急呼に関する送信データサイズ（d_size_em）を差し引いた値を新たな高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）として設定するとともに、現在のa_rwnd_nmから一般呼に関する送信データサイズ（d_size_nm）を差し引いた値を新たな低優先度通信用（一般呼用）のバッファサイズ（a_rwnd_nm）として設定する（ステップＳ１８）。
【００６８】
次に、図１２に例示するように、ｅＮＢ３が対向ノード４，５からＳＡＣＫを受信すると（ステップＳ２０）、ウィンドウサイズ算出部３１４は、a_rwndの値を更新する。具体的には例えば、ウィンドウサイズ算出部３１４は、受信したＳＡＣＫに含まれるa_rwndから応答待ちの送信データサイズを差し引いた値を新たなa_rwndの値に設定する（ステップＳ２１）。
【００６９】
そして、バッファ管理部３１２は、ステップＳ２で設定したem_buf_minとステップＳ２１で設定した新たなa_rwndとを比較し、当該a_rwndがem_buf_minよりも大きいかどうかを判定する（ステップＳ２２）。
ここで、ステップＳ２１で設定した新たなa_rwndがem_buf_min以下であると判定した場合（ステップＳ２２のＮｏルート）、バッファ管理部３１２は、対向ノード４，５の受信バッファサイズに緊急呼などの高優先度のデータをバッファする余裕がなくなったと判定する。
【００７０】
一方、ステップＳ２１で設定した新たなa_rwndがem_buf_minよりも大きいと判定した場合（ステップＳ２２のＹｅｓルート）、バッファ管理部３１２は、対向ノード４，５の受信バッファサイズに緊急呼などの高優先度のデータをバッファする余裕があると判定する。
そして、この場合、バッファ管理部３１２は、ステップＳ２１で設定した新たなa_rwndの値を、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）として更新するとともに、当該a_rwnd_emからem_buf_minを差し引いた値を、低優先度通信用（一般呼用）のバッファサイズ（a_rwnd_nm）として更新する（ステップＳ２３）。
【００７１】
次いで、バッファ管理部３１２は、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）を設定（更新）できたかどうかを判定する（ステップＳ２４）。
ここで、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）を設定できなかった（即ち、ステップＳ２２でＮｏルートへ進んだ）と判定した場合（ステップＳ２４のＮｏルート）、ｅＮＢ３は、それまで緊急呼の通信用に設定していたＳＣＴＰアソシエーション内のいずれかのストリーム（例えば、ストリーム＃０１）の予約を解除し（ステップＳ２６）、処理を終了する（ステップＳ２７）。この結果、それまで緊急呼の通信用に設定していたＳＣＴＰアソシエーション内のいずれかのストリーム（例えば、ストリーム＃０１）を、一般呼用の通信で使用することが可能となる。
【００７２】
一方、高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）を設定できた（即ち、ステップＳ２２でＹｅｓルートへ進んだ）と判定した場合（ステップＳ２４のＹｅｓルート）、ｅＮＢ３は、ＳＣＴＰアソシエーション内のいずれかのストリーム（例えば、ストリーム＃０１）を緊急呼の通信用に再設定し（ステップＳ２５）、処理を終了する（ステップＳ２７）。
【００７３】
以上のように、本例では、ＳＣＴＰを用いた通信において、優先度に応じた通信制御を行なうことが可能となる。具体的には例えば、一般呼についてのデータ送信頻度を抑制して、一般呼によるバッファフル状態を防止することができる。また、一般呼についてのデータ送信処理よりも緊急呼についてのデータ送信処理を優先させることで、緊急呼の処理遅延を抑制することが可能となる。
【００７４】
（１．６）a_rwnd_nm及びem_buf_minの動的制御について
図１０に例示したように、本例では、ＳＣＴＰアソシエーションの確立時に、a_rwnd_em，a_rwnd_nm及びem_buf_minの各値を設定するが、例えば、緊急呼が多発するような状況では、予約した高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）を直ぐに使い切ってしまう可能性がある。
【００７５】
しかしながら、対向ノード４，５の受信バッファのうちの多くを高優先度通信用（緊急呼用）のバッファサイズ（a_rwnd_em）として割り当ててしまうと、低優先度通信用（一般呼用）のバッファサイズ（a_rwnd_nm）が不足してしまうこととなる。
そこで、例えば、所定の期間において、緊急呼などの高優先度のシグナリングの発生回数と一般呼などの低優先度のシグナリングの発生回数とを測定し、当該測定結果に基づいて、低優先度通信用（一般呼用）のバッファサイズ（a_rwnd_nm）を動的に増減設定するようにしてもよい。
【００７６】
具体的には例えば、まず、バッファ管理部３１２が、ある一定の時間毎に一般呼の発生回数と緊急呼の発生回数とをそれぞれ測定する。そして、バッファ管理部３１２は、a_rwnd_nmとem_buf_minとの比率が一般呼の発生回数と緊急呼の発生回数との比率となるように、a_rwnd_em，a_rwnd_nm及びem_buf_minの各値を動的に設定する。
ただし、上記のようにして算出したa_rwnd_nmが、「a_rwnd - a_rwnd_nm < （最初に設定したem_buf_min）」を満たす場合は、「a_rwnd_nm = a_rwnd_em - （最初に設定したem_buf_min）」を満足するように、a_rwnd_nmを設定することで、最初に設定したem_buf_minについては確保できるようにするのが望ましい。
【００７７】
上記の動的制御の一例を図１３に示す。
図１３に例示するように、本例によれば、最初に設定したem_buf_minを確保しつつも、一般呼の発生回数と緊急呼の発生回数とに応じてバッファを動的に管理することができるので、より柔軟な通信制御を実現することが可能となる。
（１．７）ｅＮＢ３の送信制御動作の他の一例について
次に、ｅＮＢ３の送信制御動作の他の一例として、対向ノード４，５のデータ処理能力の推定処理について説明する。
【００７８】
図１４に例示するように、まず、ＳＣＴＰアソシエーションの確立処理の開始などを契機として処理が開始されると（ステップＳ３０）、ｅＮＢ３は、対向ノード４，５から送信されたINIT-ACKチャンクに含まれるa_rwnd値を取得する（ステップＳ３１）。
また、ｅＮＢ３の処理能力推定部３１５は、a_rwnd値の取得時刻を記憶する（ステップＳ３２）。
【００７９】
次に、ｅＮＢ３がＵＥ２からデータの送信要求を受信すると（ステップＳ３３）、ｅＮＢ３の処理能力推定部３１５は、送信データサイズを累積して記憶する（ステップＳ３４）。
そして、ｅＮＢ３は、ＵＥ２からの送信要求に従って、データを対向ノード４，５に送信し（ステップＳ３５）、対向ノード４，５からＳＡＣＫを受信して（ステップＳ３６）、受信したＳＡＣＫに含まれるa_rwnd値を抽出する（ステップＳ３７）。なお、抽出されたa_rwnd値は、処理能力推定部３１５に通知される。
【００８０】
また、ｅＮＢ３の処理能力推定部３１５は、上記ＳＡＣＫの受信時刻を記憶する（ステップＳ３８）。
そして、処理能力推定部３１５は、対向ノード４，５のデータ処理能力を推定する（ステップＳ３９）。具体的には例えば、処理能力推定部３１５は、送信データ量，データの送信間隔及び対向ノード４，５から報告されるa_rwnd値に基づいて、対向ノード４，５のデータ処理能力を推定する。
【００８１】
一例として、処理能力推定部３１５は、以下の数式（１）に基づいて、対向ノード４，５のデータ処理能力を推定することができる。
【００８２】
【数１】
0005924096.tif 000002
【００８３】
なお、上記の数式（１）において、Ｘは対向ノード４，５の単位時間あたりのデータ処理能力を表し、Ａは前回のa_rwndの取得時刻と今回のa_rwndの取得時刻との間における送信データの総量を表し、Ｂは前回取得したa_rwndと今回取得したa_rwndとの差分を表し、Ｔは前回のa_rwndの取得時刻と今回のa_rwndの取得時刻との差分を表す。当該推定結果は、処理能力推定部３１５からバッファ管理部３１２に通知される。
【００８４】
そして、ｅＮＢ３がＵＥ２から新たなデータの送信要求を受信すると（ステップＳ４０）、バッファ管理部３１２は、送信データサイズが上記ステップＳ３９で推定した対向ノード４，５の単位時間あたりのデータ処理能力と前回のデータ送信からの経過時間との積以下であるか否かを判定する（ステップＳ４１）。
ここで、送信データサイズが上記ステップＳ３９で推定した対向ノード４，５の単位時間あたりのデータ処理能力と前回のデータ送信からの経過時間との積以下であると判定した場合（ステップＳ４１のＹｅｓルート）、バッファ管理部３１２は、ＵＥ２から送信要求のあった全てのデータを送信して（ステップＳ４２）、処理を終了する（ステップＳ４４）。
【００８５】
一方、送信データサイズが上記ステップＳ３９で推定した対向ノード４，５の単位時間あたりのデータ処理能力と前回のデータ送信からの経過時間との積よりも大きいと判定した場合（ステップＳ４１のＮｏルート）、バッファ管理部３１２は、上記ステップＳ３９で推定した対向ノード４，５の単位時間あたりのデータ処理能力と前回のデータ送信からの経過時間との積に相当するサイズの一部のデータを対向ノード４，５に送信するとともに、残りのデータの送信を行なわずに（ステップＳ４３）、処理を終了する（ステップＳ４４）。なお、送信されなかったデータについては、次の送信タイミングで送信してもよい。
【００８６】
即ち、バッファ管理部３１２は、対向ノード（受信側）４，５の受信バッファの空き容量と対向ノード（受信側）４，５に送信したデータの容量とを基に推定した対向ノード（受信側）４，５のデータ処理能力に基づいて、データの送信制御を行なう。
上記の送信制御の一例を図１５に示す。
図１５に例示するように、６秒間に送信したデータが３個であり、且つ、報告されたa_rwndから対向ノード４，５の受信バッファの空きがデータ２個分増えた場合、処理能力推定部３１５は、対向ノード４，５が６秒間に５個分のデータサイズを処理できると推定することができる。即ち、処理能力推定部３１５は、対向ノード４，５の単位時間あたりのデータ処理能力を、５／６＝約０．８３［個／秒］と推定することができる。
【００８７】
また、次の１７秒間に送信を要求されたデータが１２個である場合、前回推定した対向ノード４，５の単位時間あたりのデータ処理能力×１７秒＝約１４．１７［個］となるので、ｅＮＢ２は、１２個のデータ全てを対向ノード４，５に送信することができる。
一方、当該送信の結果、報告されたa_rwndから対向ノード４，５の受信バッファの空きがデータ５個分減った場合、処理能力推定部３１５は、対向ノード４，５が１７秒間に７（＝１２−５）個分のデータサイズを処理できると推定することができる。即ち、処理能力推定部３１５は、対向ノード４，５の単位時間あたりのデータ処理能力を、７／１７＝約０．４１［個／秒］と推定することができる。
【００８８】
ここで、次の８秒間に送信を要求されたデータが５個である場合、前回推定した対向ノード４，５の単位時間あたりのデータ処理能力×８秒＝約３．２９［個］となるので、ｅＮＢ２は、５個のデータのうち、３個のデータを対向ノード４，５に送信する一方、２個のデータの送信を待機する。
本例によれば、対向ノード４，５の処理能力の推定結果に応じて送信データ量を制御できるので、対向ノード４，５での処理遅延の発生を抑制することが可能となる。その結果、緊急呼を迅速に処理することが可能となる。
【００８９】
〔２〕ハードウェア構成の一例について
ここで、図１６にｅＮＢ３のハードウェア構成の一例を示す。
この図１６に示すように、ｅＮＢ３は、例示的に、アンテナ３１と、無線インタフェース（無線ＩＦ）部３２と、ベースバンド処理部３３と、プロセッサ３４と、メモリ３５と、有線インタフェース部（有線ＩＦ部）３６とをそなえる。
【００９０】
無線ＩＦ部３２は、例えば、アンテナ３１を介して、ＵＥ２と無線通信を行なうためのインタフェース装置である。ベースバンド処理部３３は、アンテナ３１及び無線ＩＦ部３２で受信した無線信号について、所定のベースバンド処理を施すとともに、アンテナ３１及び無線ＩＦ部３２を介して送信する信号について、所定のベースバンド処理を施す回路であり、例えば、ＬＳＩ（Large Scale Integration）やＦＰＧＡ（Field Programmable Gate Array）等を含む。プロセッサ３４は、データを処理する装置であり、例えば、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital Signal Processor）等を含む。メモリ３５は、データを記憶する装置であり、例えば、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等を含む。有線ＩＦ部３６は、通信システム１のコア網６側のネットワーク（いわゆるバックホールネットワーク）と有線通信を行なうためのインタフェース装置である。
【００９１】
なお、図８に例示するｅＮＢ３の各構成と図１６に例示するｅＮＢ３の各構成との対応関係は、例えば次の通りである。
アンテナ３１は、例えば、アンテナ３０１に対応し、無線ＩＦ部３２は、例えば、ＲＦ部３０２，ＤＡＣ３０３及びＡＤＣ３０４に対応する。
また、ベースバンド処理部３３は、例えば、ＢＢ部３０５，送信部３０６及び受信部３０７に対応し、プロセッサ３４及びメモリ３５は、例えば、無線通信制御部３０８，無線エリア制御部３０９，呼処理制御部３１０，ネットワーク通信制御部３１１，バッファ管理部３１２，データ種別判別部３１３，ウィンドウサイズ算出部３１４及び処理能力推定部３１５に対応する。
【００９２】
さらに、有線ＩＦ部３６は、例えば、有線ＩＦ部３１６に対応する。
即ち、アンテナ３１は、受信側の受信バッファの空き容量に関する情報を受信する受信部の一例として機能し、プロセッサ３４は、受信側の受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、受信バッファの空き容量よりも小さい閾値に基づいて、第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう処理部の一例として機能する。
【００９３】
また、プロセッサ３４は、受信側の受信バッファの空き容量と受信側に送信したデータの容量とに基づいて推定した受信側のデータ処理能力に基づいて、データの送信制御を行なう処理部の一例として機能する。
また、図１７に対向ノード４，５のハードウェア構成の一例を示す。
この図１７に示すように、対向ノード４，５は、例示的に、プロセッサ４１と、論理回路４２と、メモリ４３と、有線ＩＦ部４４とをそなえる。
【００９４】
プロセッサ４１は、データを処理する装置であり、例えば、ＣＰＵやＤＳＰ等を含む。論理回路４２は、論理演算を行なう電子回路であり、例えば、ＬＳＩやＦＰＧＡ等を含む。メモリ４３は、データを記憶する装置であり、例えば、ＲＯＭやＲＡＭ等を含む。有線ＩＦ部４４は、ｅＮＢ３と有線通信を行なうためのインタフェース装置である。
即ち、メモリ４３は、受信バッファの一例として機能し、有線ＩＦ部４４は、自局４，５の受信バッファの空き容量をｅＮＢ（送信装置）３に通知する送信部の一例として機能する。
【００９５】
〔３〕その他
なお、上述した実施形態におけるｅＮＢ３及び対向ノード４，５の各構成及び各機能は、必要に応じて取捨選択してもよいし、適宜組み合わせて用いてもよい。即ち、本発明の機能を発揮できるように、上記の各構成及び各機能を取捨選択したり、適宜組み合わせて用いたりしてもよい。
【００９６】
また、上述した例では、比較的優先度の低いデータの一例として一般呼を挙げるとともに、比較的優先度の高いデータの一例として緊急呼を挙げて本発明を説明したが、各優先度は、例えば、ユーザやシステム管理者などによって適宜変更可能であり、この点で、本発明が上述した例に限定されないことはいうまでもない。
さらに、上述した例では、ｅＮＢ３とその対向ノード４，５との間で本例の通信制御を適用した例を挙げて本発明を説明したが、ＳＣＴＰを用いて通信を行なう他の装置間においても本発明を適用することが可能であり、この点で、本発明が上述した例に限定されないことはいうまでもない。
【００９７】
なお、上述したｅＮＢ３としての機能は、コンピュータ（ＣＰＵ，情報処理装置，各種端末を含む）が所定のプログラムを実行することによって実現されてもよい。
即ち、上記プログラムは、ＳＣＴＰを用いて確立した通信リンクを介して通信を行なう通信装置に搭載されたコンピュータに、受信側の受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を実行させ、前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を実行させるためのプログラムの一例である。
【００９８】
また、上記プログラムは、ＳＣＴＰを用いて確立した通信リンクを介して通信を行なう通信装置に搭載されたコンピュータに、受信側の受信バッファの空き容量と前記受信側に送信したデータの容量とに基づいて、前記受信側のデータ処理能力を推定させ、前記推定結果に基づいて、データの送信制御を実行させるためのプログラムの一例である。
上記プログラムは、例えば、フレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど）等のコンピュータ読取可能な記録媒体に記録された形態で提供されうる。この場合、コンピュータはその記録媒体から上記プログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いることができる。また、そのプログラムを、例えば、磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信回線を介してコンピュータに提供するようにしてもよい。なお、記録媒体としては、上述したフレキシブルディスク，ＣＤ，ＤＶＤ，磁気ディスク，光ディスク，光磁気ディスクのほか、ＩＣカード，ＲＯＭカートリッジ，磁気テープ，パンチカード，コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ），外部記憶装置等や、バーコードなどの符号が印刷された印刷物等の、コンピュータ読み取り可能な種々の媒体を利用することもできる。
【００９９】
また、コンピュータとは、ハードウェアとＯＳ（Operating System）とを含む概念であり、ＯＳの制御の下で動作するハードウェアを意味している。また、ＯＳが不要でプログラム単独でハードウェアを動作させるような場合には、そのハードウェア自体がコンピュータに相当する。ハードウェアは、少なくとも、ＣＰＵ等のプロセッサと、記録媒体に記録されたコンピュータプログラムを読み取るための手段とをそなえている。
【０１００】
さらに、上記プログラムは、上述のようなコンピュータに、ｅＮＢ３としての機能を実現させるプログラムコードを含んでいる。また、その機能の一部は、ＯＳによって実現されてもよい。
以上の実施形態に関し、さらに以下の付記を開示する。
〔４〕付記
（付記１）
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう送信装置と受信装置とを有する通信システムの制御方法であって、
前記受信装置は、
自局の受信バッファの空き容量を前記送信装置に通知し、
前記送信装置は、
前記受信装置から通知された前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、
前記受信装置から通知された前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう、
ことを特徴とする、通信システムの制御方法。
【０１０１】
（付記２）
前記送信装置は、
前記第１の優先度を有するデータの容量が前記受信バッファの空き容量以下である場合に、前記第１の優先度を有するデータを前記受信装置へ送信する一方、前記第１の優先度を有するデータの容量が前記受信バッファの空き容量よりも大きい場合に、前記第１の優先度を有するデータの送信を待機する、
ことを特徴とする、付記１記載の通信システムの制御方法。
【０１０２】
（付記３）
前記送信装置は、
前記第２の優先度を有するデータの容量が前記閾値以下である場合に、前記第２の優先度を有するデータを前記受信装置へ送信する一方、前記第２の優先度を有するデータの容量が前記閾値よりも大きい場合に、前記第２の優先度を有するデータの送信を待機する、
ことを特徴とする、付記１または２に記載の通信システムの制御方法。
【０１０３】
（付記４）
前記送信装置は、
前記第１の優先度を有するデータの発生数と前記第２の優先度を有するデータの発生数とに応じて、前記閾値を動的に変更する、
ことを特徴とする、付記１〜３のいずれか１項に記載の通信システムの制御方法。
【０１０４】
（付記５）
前記送信装置は、
前記受信バッファの空き容量と前記変更後の閾値との差が所定値以上となるように、前記閾値を制御する、
ことを特徴とする、付記４記載の通信システムの制御方法。
【０１０５】
（付記６）
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう送信装置と受信装置とを有する通信システムの制御方法であって、
前記受信装置は、
自局の受信バッファの空き容量を前記送信装置に通知し、
前記送信装置は、
前記受信装置から通知された前記受信バッファの空き容量と前記受信装置に送信したデータの容量とに基づいて、前記受信装置のデータ処理能力を推定し、
前記推定結果に基づいて、データの送信制御を行なう、
ことを特徴とする、通信システムの制御方法。
【０１０６】
（付記７）
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう通信装置であって、
受信側の受信バッファの空き容量に関する情報を受信する受信部と、
前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう処理部と、をそなえた、
ことを特徴とする、通信装置。
【０１０７】
（付記８）
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう通信装置であって、
受信側の受信バッファの空き容量に関する情報を受信する受信部と、
前記受信バッファの空き容量と前記受信側に送信したデータの容量とを基に推定した前記受信側のデータ処理能力に基づいて、データの送信制御を行なう処理部と、をそなえた、
ことを特徴とする、通信装置。
【０１０８】
（付記９）
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう送信装置と受信装置とを有する通信システムであって、
前記受信装置は、
自局の受信バッファの空き容量を前記送信装置に通知する送信部をそなえ、
前記送信装置は、
前記通知を受信する受信部と、
前記受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を行なう一方、前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を行なう処理部と、をそなえた、
ことを特徴とする、通信システム。
【０１０９】
（付記１０）
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう送信装置と受信装置とを有する通信システムであって、
前記受信装置は、
自局の受信バッファの空き容量を前記送信装置に通知する送信部をそなえ、
前記送信装置は、
前記通知を受信する受信部と、
前記受信バッファの空き容量と前記受信側に送信したデータの容量とに基づいて推定した前記受信側のデータ処理能力に基づいて、データの送信制御を行なう処理部と、をそなえた、
ことを特徴とする、通信システム。
【０１１０】
（付記１１）
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう通信装置に搭載されたコンピュータに、
受信側の受信バッファの空き容量に基づいて、第１の優先度を有するデータの送信制御を実行させ、
前記受信バッファの空き容量よりも小さい閾値に基づいて、前記第１の優先度よりも低い第２の優先度を有するデータの送信制御を実行させるためのプログラム。
【０１１１】
（付記１２）
ＳＣＴＰ（Stream Control Transmission Protocol）を用いて確立した通信リンクを介して通信を行なう通信装置に搭載されたコンピュータに、
受信側の受信バッファの空き容量と前記受信側に送信したデータの容量とに基づいて、前記受信側のデータ処理能力を推定させ、
前記推定結果に基づいて、データの送信制御を実行させるためのプログラム。
【符号の説明】
【０１１２】
１  通信システム
２  ＵＥ
３  ｅＮＢ
４  ＭＭＥ
５  ＳＧＷ
６  コア網
３１  アンテナ
３２  無線ＩＦ部
３３  ベースバンド処理部
３４  プロセッサ
３５  メモリ
３６  有線ＩＦ部
４１  プロセッサ
４２  論理回路
４３  メモリ
４４  有線ＩＦ部
１００  無線通信システム
２００−１，２００−２  ＭＭＥ／ＳＧＷ
３００−１〜３００−３  ｅＮＢ
３０１  アンテナ
３０２  ＲＦ部
３０３  ＤＡＣ
３０４  ＡＤＣ
３０５  ＢＢ部
３０６  送信部
３０７  受信部
３０８  無線通信制御部
３０９  無線エリア制御部
３１０  呼処理制御部
３１１  ネットワーク通信制御部
３１２  バッファ管理部
３１３  データ種別判別部
３１４  ウィンドウサイズ算出部
３１５  処理能力推定部
３１６  有線ＩＦ部
【図１】
0005924096.tif 000003
【図２】
0005924096.tif 000004
【図３】
0005924096.tif 000005
【図４】
0005924096.tif 000006
【図５】
0005924096.tif 000007
【図６】
0005924096.tif 000008
【図７】
0005924096.tif 000009
【図８】
0005924096.tif 000010
【図９】
0005924096.tif 000011
【図１０】
0005924096.tif 000012
【図１１】
0005924096.tif 000013
【図１２】
0005924096.tif 000014
【図１３】
0005924096.tif 000015
【図１４】
0005924096.tif 000016
【図１５】
0005924096.tif 000017
【図１６】
0005924096.tif 000018
【図１７】
0005924096.tif 000019