(57)【要約】【課題】リソースの要求値を段階的に設定することにより、通信端末が最適な通信速度を確保するため設定するリソースの柔軟な変更を可能にするアクセス制御装置を提供すること。【解決手段】ＱｏＳポリシーを受信すると、第１リソース要求値を決定する。第１リソース要求値で通信が出来ない場合は、第１リソース要求値より低い第２リソース要求値を決定する。そして、第２リソース要求値でデータを伝送した後に、リトライ判定が実行されると、第１リソース要求値で通信可能か判定する。第１リソース要求値で通信可能であれば、第１リソース要求値で通信を行う。【選択図】図３
2009159087.tif 000002
【特許請求の範囲】
【請求項１】
移動通信ネットワークにおいて、通信端末のセッションを制御するセッション制御装置と、前記通信端末に無線リソースを設定する無線アクセスポイントとに接続したアクセス制御装置において、
前記セッション制御装置から、前記通信端末がセッションを開始する情報を受信すると、第１リソース要求値を決定する第１リソース要求値決定手段と、
前記決定した第１リソース要求値に従ったリソース設定を、前記無線アクセスポイントに要求する第１リソース要求手段と、
前記無線アクセスポイントにおいて、前記第１リソース要求値によるリソース設定が失敗した場合に、前記第１リソース要求値より低い第２リソース要求値を決定する第２リソース要求値決定手段と、
前記決定した第２リソース要求値に従ったリソース設定を、前記無線アクセスポイントに要求する第２リソース要求手段と、
を備え、
所定のタイミングにおいて、前記第１リソース要求値に従ったリソース設定のリトライの判定をするリトライ判定手段を有することを特徴とするアクセス制御装置。
【請求項２】
前記第１リソース要求値によるリソース設定が失敗した場合に、前記第１リソース要求値を記憶する第１リソース要求値記憶手段を備え、
前記第１リソース要求手段は、前記リトライ判定手段によりリトライが判定された場合に、前記第１リソース要求値記憶手段に記憶されている第１リソース要求値を読み出して、無線リソースの設定を要求する手段であることを特徴とする請求項１に記載のアクセス制御装置。
【請求項３】
前記リトライの判定後、前記第１リソース要求値に従ったリソースの設定が成功した場合には、前記第２リソース要求値に従って設定されているリソースで実行中のセッションを、前記第１リソース要求値に従って設定したリソースで継続して実行し、前記第２リソース要求値に従って設定したリソースは開放することを特徴とする請求項１に記載のアクセス制御装置。
【請求項４】
前記リトライ判定手段において、リトライの判定を行うタイミングは、セッションの開始後、セッション実行中に一定時間が経過したタイミングであることを特徴とする請求項１から３のいずれか一項に記載のアクセス制御装置。
【請求項５】
前記リトライ判定手段において、リトライ判定を行うタイミングは、前記通信端末のハンドオーバを検出したタイミングであることを特徴とする請求項１から３のいずれか一項に記載のアクセス制御装置。
【請求項６】
前記リトライ判定手段において、リトライ判定を行うタイミングは、前記通信端末と同一エリアに在圏し、リソースを占有している他の通信端末がリソースを開放したのを検出したタイミングであることを特徴とする請求項１から３のいずれか一項に記載のアクセス制御装置。
【請求項７】
前記リトライ判定手段において、リトライ判定を行うタイミングは、前記通信端末と同一エリアに在圏し、リソースを占有している他の通信端末にハンドオーバが発生したことを検出したタイミングであることを特徴とする請求項１から３のいずれか一項に記載のアクセス制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はアクセス制御装置に関する。
【背景技術】
【０００２】
従来より、ＡＤＳＬ等の有線アクセス網では、ＩＰパケットを転送するルータにおけるトラフィック量等の負荷状態を監視する等して、負荷状態となっているルータにさらに帯域を割り当てる等のＱｏＳ制御を行うことが一般的である。ＩＭＴ−２０００等の移動通信網においても、こうしたＱｏＳ制御のため、必要な通信リソースを確保し通信端末に適切なサービス品質を提供する方法が講じられている（例えば、非特許文献１参照）。
【０００３】
例えば、ユーザが高品質な動画像配信等の大容量データを送受信する場合、無線区間も含めたトランスポート部分のリソースを、広帯域に確保して配信する方法が知られている。
【０００４】
また、最近では、ＩＰマルチメディアコアネットワーク制御サブシステム（ＩＭＳ）を導入したＱｏＳ制御が図られている。なお、ＩＰマルチメディアコアネットワーク制御サブシステム（ＩＭＳ）は、テレビ電話や双方向グループ通信等のリアルタイム系マルチメディアサービスを行なう際に起動されるサブシステムである。
【０００５】
ここで、図８を用いて従来の通信方法について簡単に説明する。図８は、第１通信端末と第２通信端末とが、通信を行う場合について説明するための図である。
【０００６】
まず、第１通信端末及び第２通信端末が、セッション制御装置とサービスネゴシエーションを実行すると（Ｓ９０２）、セッション制御装置は第１通信端末及び第２通信端末が行なうサービスのサービスクラス等を含むサービス情報を取得する（Ｓ９０４）。そして、セッション制御装置は、取得されたサービス情報に基づいて、リソース設定要求をアクセスゲートウェイ（ＡＧＷ）に送信する（Ｓ９０６）。なお、ここで、セッション制御装置は、サービスに必要なベアラの情報（少なくとも、要求ビットレート、トラフィッククラス、遅延／優先度等）をＱｏＳポリシーとしてリソース設定要求に含めてＡＧＷに通知する。
【０００７】
ＡＧＷは、リソース設定要求に従ってＱｏＳパラメータを決定し（Ｓ９０８）、アクセスポイント（ＡＰ）に対して無線ベアラ設定要求を送信する（Ｓ９１０）。この、無線ベアラ設定要求により、ＱｏＳパラメータがＡＰに通知される。
【０００８】
ＡＰは、無線リソース、通信端末能力からスケジューリング構成等のネゴシエーションを実行する（Ｓ９１２）。そして、通信が確保された場合は、ＡＰからＡＧＷに対してＡＣＫが送信される（Ｓ９１４）。また、ＡＧＷは、ＡＰからＡＣＫを受信すると、リソース設定要求をセッション制御装置に送信する（Ｓ９１６）。
【０００９】
これにより、第１通信端末及び第２通信端末の間の通信路がベアラに基づいて設定され、設定されたリソースのベアラ上でのユーザデータが送受信されることとなる。
【非特許文献１】３ＧＰＰ  ＴＲ  ２３．８８２; 3GPP System Architecture Evolution : Report on Technical Options and Conclusions
【発明の開示】
【発明が解決しようとする課題】
【００１０】
ここで、従来のＩＭＳのセッション制御装置は、サービスに対し保証すべきリソースの規定値をＱｏＳポリシーとして持ち、そのポリシーを満たすリソースを確保してから通信端末にサービス提供を開始する。しかし、所定のリソースが確保できなかった場合は、利用可能なだけのリソースを確保して、通信を開始することとなる。
【００１１】
このような従来のリソース設定方法では、要求したリソースが確保できなければ利用可能なリソースだけによるベストエフォートの通信を行なうしかなく、ベストエフォートの通信を開始した後、リソースが改善して最初に要求したリソースが確保可能となったにも関わらず、いったん設定したベアラは通信終了まで維持されるため、通信端末がいったん通信を終了してから再開する等して、再度リソースを要求しない限りは、リソースを設定し直すことはできないといった問題点が生じていた。したがって、リソースが改善したとしても、そのリソースがその通信端末に割り当てられることがなかった。
【００１２】
これを解決するため、通信設定後により豊富にリソースを利用可能な状況であれば、リソースを割り当て直すよう、リソースの状態やトラフィック量の監視を行う手法もあるが、ＡＤＳＬ等の有線のアクセス網とは異なり、無線リソースの監視には、通信端末からの状態通知等を必要とする等、システムの複雑化につながるという問題や、限られた無線リソースを柔軟に制御することが困難という、移動通信ネットワーク特有の問題があり実現されていなかった。
【００１３】
上記課題に鑑み、本発明が目的とするところは、リソースの要求値を段階的に決定して利用可能なリソースを設定することにより、通信端末に接続性を保証すると共に、最適な通信速度を確保するため設定するリソースの柔軟な変更を可能にするアクセス制御装置を提供することを目的とするものである。
【課題を解決するための手段】
【００１４】
上述した課題を解決するために、本発明のアクセス制御装置は、移動通信ネットワークにおいて、通信端末のセッションを制御するセッション制御装置と、前記通信端末に無線リソースを設定する無線アクセスポイントとに接続したアクセス制御装置において、前記セッション制御装置から、前記通信端末がセッションを開始する情報を受信すると、第１リソース要求値を決定する第１リソース要求値決定手段と、前記決定した第１リソース要求値に従ったリソース設定を、前記無線アクセスポイントに要求する第１リソース要求手段と、前記無線アクセスポイントにおいて、前記第１リソース要求値によるリソース設定が失敗した場合に、前記第１リソース要求値より低い第２リソース要求値を決定する第２リソース要求値決定手段と、前記決定した第２リソース要求値に従ったリソース設定を、前記無線アクセスポイントに要求する第２リソース要求手段と、を備え、所定のタイミングにおいて、前記第１リソース要求値に従ったリソース設定のリトライの判定をするリトライ判定手段を有することを特徴とする。
【００１５】
また、本発明のアクセス制御装置は、前記第１リソース要求値によるリソース設定が失敗した場合に、前記第１リソース要求値を記憶する第１リソース要求値記憶手段を備え、前記第１リソース要求手段は、前記リトライ判定手段によりリトライが判定された場合に、前記第１リソース要求値記憶手段に記憶されている第１リソース要求値を読み出して、無線リソースの設定を要求する手段であることを特徴とする。
【００１６】
また、本発明のアクセス制御装置は、前記リソース設定再判定手段により、前記第１リソース要求値により、無線リソースの設定が可能であると再判定された場合には、前記第２リソース要求値に従って設定されている無線リソースで実行中のセッションを、継続して実行することを特徴とする。
【００１７】
また、本発明のアクセス制御装置は、前記リトライ判定手段において、リトライの判定を行うタイミングは、セッションの開始後、セッション実行中に一定時間が経過したタイミングであることを特徴とする。
【００１８】
また、本発明のアクセス制御装置は、前記リトライ判定手段において、リトライ判定を行うタイミングは、前記通信端末のハンドオーバを検出したタイミングであることを特徴とする。
【００１９】
また、本発明のアクセス制御装置は、前記リトライ判定手段において、リトライ判定を行うタイミングは、前記通信端末と同一エリアに在圏し、リソースを占有している他の通信端末がリソースを開放したのを検出したタイミングであることを特徴とする。
【００２０】
また、本発明のアクセス制御装置は、前記リトライ判定手段において、リトライ判定を行うタイミングは、前記通信端末と同一エリアに在圏し、リソースを占有している他の通信端末にハンドオーバが発生したことを検出したタイミングであることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、リソース要求値に従ってリソースを設定する制御を行うアクセス制御装置において、セッション制御装置から、通信端末の通信に必要なリソース設定要求を受信すると、第１リソース要求値を決定する。そして、第１リソース要求値によるリソース設定が失敗した場合には、第１リソース要求値より低い第２リソース要求値を決定する。ここで、前記通信端末からのリトライの判定があったと判定された場合には、第１リソース要求値により、無線リソースの設定が可能か再判定することとなる。したがって、一度第１リソース要求値より低い第２リソースにおいて、セッションが確立されても、第１リソース要求値によって無線リソースが設定可能となれば、第１リソース要求値によるリソース確立をリトライしてセッションを確立する。
【発明を実施するための最良の形態】
【００２２】
以下、図面を参照して本実施形態におけるアクセス制御装置及びアクセス制御装置を利用した移動通信システムにおける最良の実施形態について説明する。
【００２３】
本発明のアクセス制御装置は、通信端末がサービスを行うのに必要なリソースを最大限有効に活用できるようにする方法を、システムの複雑化を回避し比較的容易に実現するため、次のような手段を講じた。以下、詳細に説明する。
【００２４】
［システム構成］
図１は、アクセス制御装置をアクセスゲートウェイ（ＡＧＷ）に適用し、移動通信システム１に配置した場合の一例を示す図である。移動通信システム１は、セッション制御装置１０と、ＡＧＷ２０と、アクセスポイント（ＡＰ）３０と、加入者管理サーバ４０とが接続されているネットワークであり、ＡＰ３０には通信端末５０ａが接続されている。
【００２５】
また、移動通信システム１は、ＩＰルータ６０を介してＩＰネットワークに接続されている。当該ＩＰネットワークには、通信端末５０ｂが接続されており、移動通信システム１及びＩＰネットワークを介して通信端末５０ａと、通信端末５０ｂとが通信路を設け、データの送受信を行う。
【００２６】
なお、通信端末５０ａと、通信端末５０ｂとを併せて包括的に表現する場合には通信端末５０とする。また、セッション制御装置１０と、加入者管理サーバ４０とによりＩＭＳが構成されている。
【００２７】
まず、セッション制御装置１０について説明する。セッション制御装置１０は、サービス情報取得部１０２と、ＱｏＳポリシー通知部１０４とを備えて構成される。
【００２８】
サービス情報取得部１０２は、端末間でセッションを設定する際に行なうサービスネゴシエーションを仲介し、サービスタイプ（ＣＢＲ、ＶＢＲ、ＡＢＲ、ベストエフォート等）やトラフィッククラス（会話型、双方向対話型、ストリーミング型、バックグラウンド型）等のサービスの属性に関する情報を取得する機能部である。
【００２９】
ＱｏＳポリシー通知部１０４は、サービス情報取得部１０２において取得されたサービス情報に対応し、ベストエフォートを除いたサービス毎に保証すべきリソース要求値（帯域幅や許容遅延率等の規定値）を選択し、ＡＧＷ２０のリソース設定部２０８に通知する。ここで、ＱｏＳポリシーは、通信端末毎にネットワークへの加入形態や、通信能力によって異なり、リソースが他の通信端末に占有されているような状況であっても、ある通信端末にはリソース割り当てを優先する等の情報である。そのため、ＱｏＳポリシー通知部１０４は、加入者管理サーバ４０と接続され、通信端末５０の加入形態や通信能力等の情報を取得可能としている。
【００３０】
続いて、ＡＧＷ（アクセスゲートウェイ）２０について説明する。ＡＧＷ２０には、位置管理部２０２と、リトライ判定部２０４と、記憶部２０６と、リソース設定部２０８と、データ伝送部２１０とを備えて構成されている。
【００３１】
位置管理部２０２は、ＡＰ３０に接続されている通信端末５０の位置を管理する機能部である。移動管理部２０２は、ＡＰ３０の位置管理部３０２により入力される通信端末５０の移動を管理する。また、通信端末５０ａが、ＡＰ３０の在圏エリアから外れると、ハンドオーバ処理を実行する。
【００３２】
リトライ判定部２０４は、最初に決定したリソース要求値によってリソースが確保できなかった場合に、通信設定後のタイミングで、リトライを判定する。
ここで、リトライ判定は、通信端末５０の位置を管理している位置管理部２０２から、通信端末５０のハンドオーバや、通信端末５０と同一のエリアに在圏する他の通信端末のハンドオーバ、またはリソース開放の情報を契機に判定する。
【００３３】
また、さらに簡易な方法として、タイマーを設定しておき通信開始後一定時間経過したことによって、リトライを判定してもよい。リトライ判定部２０４がリトライを判定すると、リソース設定部２０８は記憶部２０６において保持している最初のリソース要求値を呼び出して、リソースを設定する。
【００３４】
記憶部２０６は、通信端末クラスや、トラフィッククラス、サービスタイプに対応づけてリソースの要求値を記憶している記憶部である。
【００３５】
リソース設定部２０８は、ＱｏＳポリシー通知部１０４から通知されたＱｏＳポリシーに基づき、少なくともトラフィッククラスや、上り／下りのデータ伝送速度等リソース要求値を決定し、データ伝送部２１０にリソースを設定する。また、リソース設定部２０８で決定した最初のリソース要求値は、通信端末５０の通信が終了するまでの間、記憶部２０６において保持する。
【００３６】
データ伝送部２１０は、ＩＰルータ６０とデータを送受信する機能部である。例えば、リソース設定部２０８から入力されたリソース要求値等を送信したり、ＡＰ３０を介して接続されている通信端末５０ａからのデータをＩＰルータ６０に送受信したりする。
【００３７】
続いて、アクセスポイント（ＡＰ）３０について説明する。ＡＰ３０は、無線リソース設定部３０４と、移動検知部３０２と、データ伝送部３０６とを備えて構成される。
【００３８】
移動検知部３０２は、通信端末５０ａの移動を検知する機能部である。移動検知部３０２は、ＡＰ３０の在圏エリアに在圏する通信端末を管理したり、ハンドオーバの制御を行ったりする。
【００３９】
無線リソース設定部３０２は、ＡＧＷ２０からのリソース要求値に基づいて、無線変調方式等の無線パラメータを決定し、データ伝送部３０６に設定する機能部である。
【００４０】
データ伝送部３０６は、設定されたリソース要求値にしたがって、データ伝送部２１０を介して通信を行う。すなわち、ＡＧＷ２０（データ伝送部２０）と、ＩＰルータ６０とを介すことにより、通信端末５０ｂと通信を行う。
【００４１】
なお、図１は本実施形態における一構成例であり、これに限定されるものではないことはもちろんである。例えば、図１の構成例ではＡＧＷ２０に位置管理部２０２を備えているが、位置管理のシグナリングを分離して扱うよう、ＡＧＷ２０とは独立して位置管理装置として構成されてもよい。また同様に、セッション制御装置にＱｏＳポリシー通知部１０４を備えているが、ＱｏＳポリシーサーバーとしてセッション制御装置とは別に構成されていてもよい。
【００４２】
ここで、ＡＧＷ２０の記憶部２０６に記憶されるリソースの要求値について、図２を参照して説明する。図２に示すように、通信端末クラス（例えば、「クラス１」）と、トラフィッククラス（例えば「クラス１（会話型）」と、サービスタイプ（例えば、「ＣＢＲ」）とに対応づけて、第１リソース要求値（例えば、「＞１４４ｋｂｐｓ」）と、第２リソース要求値（例えば、「＞６４ｋｂｐｓ」）とを記憶している。
【００４３】
ここで、通信端末クラスとは、サービスを実行する通信端末の加入形態のタイプ、通信能力等から判定された通信端末のクラスである。
【００４４】
また、トラフィッククラスとは、トラフィックの種類に応じて記憶されており、本実施形態では、会話型の通信に用いられる「クラス１」と、双方向型の通信に用いられる「クラス２」と、ストリーミングの通信に用いられる「クラス３」と、バックグラウンドの通信に用いられる「クラス４」とがある。
【００４５】
また、サービスタイプは、提供されるサービスの種類に応じて記憶されている。本実施形態では、ＣＢＲ（固定ビットレート：Constant Bit Rate）と、ＶＢＲ（可変ビットレート：Variable Bit Rate）と、ＡＢＲ（平均ビットレート：Available Bit Rate）と、ＵＢＲ（不特定ビットレート：Unspecified Bit Rate）とに分かれている。
【００４６】
また、リソース要求値は、ベアラ通信速度を決定するための要求値である。例えば、第１リソース要求値「＞１４４ｋｂｐｓ」の場合、１４４ｋｂｐｓより大きな通信速度を要求する、換言すれば、１４４ｋｂｐｓの通信速度が保証されることとなる。
【００４７】
ここで、図２において、リソース設定部２０８がリソース要求値を決定する方法について簡単に説明する。図２は、上述したように、記憶部２０６に記憶されているリソース要求値を決定する為のテーブルである。まず、ＱｏＳポリシーによって、サービスを実行する通信端末の加入形態のタイプ、通信能力等から判定された通信端末へのリソース設定優先度が、通信端末クラスとして示される。
【００４８】
また、その通信端末のトラフィッククラス、サービスタイプ毎に対応する要求値が、第１リソース要求値と第２リース要求値として示される。この例の場合は、通信端末クラス１の通信端末が、トラフィッククラス１（会話型）の通信をＣＢＲで行なう場合に必要なリソースは、第１リソース要求値が１４４ｋｂｐｓより大きく、第２リソース要求値が６４ｋｂｐｓより大きくなっている。
【００４９】
図３に、ＡＧＷ２０の処理のフローチャートを示す。ＡＧＷ２０は、セッション制御装置１０からＱｏＳポリシー通知を受信すると（ステップＳ１００）、トラフィッククラス、最大／最小ビットレート（上り／下り）などのパラメータにより、記憶部２０６を参照して第１リソース要求値を決定する（ステップＳ１０２）。
【００５０】
次に、ＡＧＷ２０は、第１リソース要求値に基づく第１リソース設定トライを実行し、成功すると（すなわち、ＡＰ３０からＡＣＫが返ってくると）、確保したリソースで通信を開始する（ステップＳ１０４；Ｙｅｓ→ステップＳ１０６）。
【００５１】
他方、第１リソース設定トライが失敗した場合は（すなわち、ＡＰ３０からＮＡＣＫが返ってくると）、第１リソース要求値より要求レベルを低下させた第２リソース要求値を決定する（ステップＳ１０４；Ｎｏ→ステップＳ１０８）。ここで第１リソース要求値を一時的に記憶部２０６に記憶する。なお、記憶部２０６で記憶した第１リソース要求値は、通信端末５０の通信終了まで保持するようにする。
【００５２】
そして、第２リソース設定トライを行ない成功すると（ステップＳ１１０；Ｙｅｓ）、確保した第２リソース要求値で通信を開始する。なお、第２リソース設定トライに失敗した場合は（ステップＳ１１０；Ｎｏ）、リソースが確保できなかったものとして本処理を終了する。
【００５３】
ステップＳ１１２に戻って説明をする。第２リソース設定トライによって通信を開始した後、リトライをするか否か判定をする（ステップＳ１１４）。ここで、リトライするか否かを判定するトリガーは、例えば、通信端末５０がハンドオーバした時や、通信端末５０と同じＡＰに在圏する他の通信端末のリソースが開放された場合等である。
【００５４】
リトライすると判定された場合には（ステップＳ１１４；Ｙｅｓ）、第１リソース要求値を読み出し（ステップＳ１１６）、第１リソース設定リトライを実行する（ステップＳ１１８）。ここで、第１リソース要求値は、先ほど一時記憶された値が読み出されるものとする。
【００５５】
第１リソース設定リトライが成功すると（ステップＳ１１８；Ｙｅｓ）、新たに確定した第１リソース要求値に基づいて通信を開始する（ステップＳ１０６）。反対に、第１リソース設定トライに失敗した場合は（ステップＳ１１８；Ｎｏ）、既に設定している第２リソース要求値による通信を継続し、再びハンドオーバなどの契機があった場合にリトライを判定する。
【００５６】
リトライを判定する契機としては、通信端末５０のハンドオーバ等のタイミングを利用する。具体的には、ハンドオーバ元のＡＰからＡＧＷ２０への通信端末５０のハンドオーバ通知を受信した時に、リトライ判定を行なう。この通知は、通信端末５０がＡＰをまたがってハンドオーバする際に通常行われるものであり、ＡＧＷ２０はＡＰからこの通知を受けると、ハンドオーバ先のＡＰに無線リソース設定を指示し、通信端末５０はハンドオーバ先ＡＰで設定された無線リソースを利用することができる。
【００５７】
この時、ハンドオーバ元のＡＰが第２リソース要求値に従ってリソース設定をしていた場合でも、ＡＧＷ２０はハンドオーバ先ＡＰに対しては元の第２リソース要求値によるリソース設定を要求するのではなく、第１リソース要求値によるリソース設定にリトライするよう判定する。これは、ハンドオーバ先ＡＰでは無線環境が良好で第１リソース要求値でリソースを設定できる可能性があるためである。
【００５８】
リトライを判定し、ハンドオーバ先ＡＰで第１リソース要求値によるリソース設定が成功すると、通信端末５０はハンドオーバ前のリソース（第２リソース要求値で設定したリソース）よりも好適な状態でリソースを利用できるようになる。しかし、第１リソース要求値によるリソース設定が失敗した場合は、図３で説明したステップＳ１０４；Ｎｏ→ステップＳ１０８→ステップＳ１１０；Ｙｅｓと同様の手順によって第２リソース要求値によるリソース設定を行う。
【００５９】
第１リソース要求値によるリソース設定が失敗した場合の注意点としては、リトライを実行することによってハンドオーバ遅延につながる可能性があることである。これを回避する手段の一例としては、ステップＳ１００でセッション制御装置１０から通知されたＱｏＳポリシーの情報を用いる。
【００６０】
トラフィッククラス１の音声通話等の場合は、他のクラスに比べある程度の遅延が許容されるサービスであることから、トラフィッククラス１のサービスの場合はリトライを判定するという方法がある。一方、ＦＴＰサービス等トラフィッククラス４のサービスの場合は、低遅延が要求されることから、リトライによる第１リソース要求値のリソース設定よりも、第２リソース要求値によるリソース確保を維持するように、リトライしないことを判定する。
【００６１】
また、通信端末５０のハンドオーバ発生によってだけでなく、通信端末５０と同じＡＰのエリアに在圏する他の通信端末が、他のＡＰへハンドオーバしたタイミングで、リトライ判定を行ってもよい。これは、他の通信端末がハンドオーバしたことにより、通信端末５０がそのエリアにおいて利用できるリソースが増える可能性があるためであり、ＡＧＷ２０は他の通信端末のハンドオーバ元ＡＰからハンドオーバ通知を受けると、そのＡＰに在圏している通信端末５０へのリソース設定をリトライすることを判定する。
【００６２】
また、通信端末５０と同じＡＰのエリアに在圏する他の通信端末が、通信を終了したタイミングで、リトライ判定を行ってもよい。これも上記と同じく、他の通信端末が通信を終了したことにより、通信端末５０がそのエリアにおいて利用できるリソースが増える可能性があるためであり、ＡＧＷ２０は他の通信端末が終話しリソース開放を行なった通知をＡＰから受けると、通信端末５０へのリソース設定をリトライすることを判定する。
【００６３】
図４に、通信端末５０ａと通信端末５０ｂとの間で通信を開始するまでのシーケンスを示す。図４では、通信端末５０ａ側の処理のみを示しているが、通信端末５０ｂ側でも同様にリソース設定処理を行なうものとする。
【００６４】
通信端末５０ａと通信端末５０ｂの間で、まずはセッション制御装置１０を介し、実行するサービスタイプ、トラフィッククラスのサービスネゴシエーションを行なう（Ｓ２０２）。セッション制御装置２０は、サービスネゴシエーションからサービス情報を取得して（Ｓ２０４）、ＱｏＳポリシーを選択し、ＡＧＷ２０にリソース設定要求を送信する（Ｓ２０６）。
【００６５】
ＡＧＷ２０は、ＱｏＳポリシーに基づいて記憶部２０６から第１リソース要求値を決定し（Ｓ２０８）、ＡＰ３０に無線ベアラ設定要求を送信する（Ｓ２１０）。また、無線ベアラ設定要求により、ＱｏＳパラメータがＡＰ３０に通知される。
【００６６】
ここで、ＡＰ３０は、無線リソース、通信端末能力から、スケジューリング構成等のネゴシエーションを実行する（Ｓ２１２）。すなわち、ＡＰ３０は、無線ベアラ設定要求により通知されたＱｏＳパラメータを、上り／下りの伝送レートや送信電力値、無線チャネル数等の無線パラメータにマッピングし、通信端末５０ａに通知する。そして、通信端末５０ａが通知された無線パラメータを許容可能であれば、ＡＧＷ３０に「ＡＣＫ」を送信し、許容可能でない場合は「ＮＡＣＫ」を送信する。
【００６７】
ここで、許容可能で無かった場合を例にとって説明すると、ＡＰ３０は、ＡＧＷ２０に対してＮＡＣＫを送信する（Ｓ２１４）。ＮＡＣＫを受信したＡＧＷ２０は、第２リソース要求値を決定すると共に、第１リソース要求値を記憶部２０６に一時記憶する（Ｓ２１６）。そして、ＡＰ３０に、第２リソース要求値に基づく無線アクセスベアラ設定要求を送信する（Ｓ２１８）。なお、当該無線アクセスベアラ設定要求により、修正されたＱｏＳパラメータが通知されることとなる。
【００６８】
ＡＰ３０は、前記処理を再度行ない、通信端末５０ａとネゴシエーションを実行する（Ｓ２２０）。本実施形態においては、通信端末５０ａは第２リソース要求値に対しては無線パラメータを許容するものとする。したがって、ＡＰ３０は無線リソースを設定し、ＡＧＷ２０に、ＡＣＫを送信する（Ｓ２２２）。ＡＧＷ２０は、ネットワークの有線側のリソースを設定すると、データを伝送するベアラが設定され、通信セッションを開始することが可能となる。ＡＧＷ２０はセッション制御装置１０にリソース設定応答を送信し、セッションが開始される（Ｓ２２４）。
【００６９】
そして、通信端末５０ａと、通信端末５０ｂとの間にベアラが設定され、設定されたリソースのベアラ上で通信が行われることとなる。
【００７０】
次に、図５にセッションを開始した後に行なうリソース設定リトライの手順を示す。この例では、通信端末５０ａのハンドオーバを機に、ＡＧＷ２０がリトライを判定する場合である。
【００７１】
ここで、通信システムの概略を図５に示す。上述したように、セッション制御装置１０と、ＡＧＷ２０と、加入者管理サーバ４０とが相互に接続されており、ＡＧＷ２０は外部ネットワークに接続されている。また、ＡＧＷ２０には、ＡＰ３０ａと、ＡＰ３０ｂとが接続されている。そして、通信端末５０ａが、ＡＰ３０ａの在圏エリアから、ＡＰ３０ｂの在圏エリアに移動したことによりハンドオーバが発生した場合について図６のシーケンス図を用いて説明する。
【００７２】
まず、図６をみると、通信端末５０ａと、ＡＰ３０ａと、ＡＰ３０ｂと、ＡＧＷ２０と、セッション制御装置１０と、通信端末５０ｂと、が接続されている。
【００７３】
まず、通信端末５０ａと、通信端末５０ｂは、ＡＧＷ２０を介して設定されたリソースのベアラ上でユーザデータの送受信がされている（Ｓ３０２）。ここで、通信端末５０ａから、ＡＰ３０ａに対してハンドオーバ要求が送信されると（Ｓ３０４）、ＡＰ３０ａ、ＡＰ３０ｂとの間でハンドオーバ処理が実行される（Ｓ３０６）。
【００７４】
ハンドオーバ処理が実行されると、ＡＰ３０ａはＡＧＷ２０にハンドオーバ通知を送信する（Ｓ３０８）。これは、ハンドオーバ時に通常行われるＡＰ３０ａへのデータの伝送のリソース開放をＡＧＷ２０に通知するためのものである。
【００７５】
ＡＧＷ２０は、ハンドオーバ通知を受けリトライすることを判定し（Ｓ３１０）、第１リソース要求値を呼び出して、ハンドオーバ先のＡＰ３０ｂに、無線ベアラ設定要求リトライを送信する（Ｓ３１２）。ここで、無線ベアラ設定要求リトライにより、ＱｏＳパラメータがＡＰ３０ｂに通知される。
【００７６】
そして、ＡＰ３０ｂと、通信端末５０ａとの間で無線リソース、通信端末能力からスケジューリング構成等をネゴシエーションする（Ｓ３１４）。ここで、第１リソース要求値に従ったリソースが可能である場合には、ＡＰ３０ｂからＡＧＷ２０にＡＣＫを送信する（Ｓ３１６）。そして、図４で設定されたベアラ（第２リソース要求値に基づいて設定されたベアラ通信速度）は新たに確保した第１リソース要求値に基づいて設定されたベアラ速度により確立し直されたこととなり、セッションはそのベアラ上で継続される。
【００７７】
また、通信端末５０ａと同じＡＰ３０ａのエリアに接続していた他の通信端末がリソースを占有していたが、他のＡＰにハンドオーバをしたので、リソースに空きが出たという状況でも、前記と同様にＡＧＷ２０がＡＰ３０ａからの通知を機に、通信端末５０ａへのリソース設定リトライを判定するトリガーとすることができる。
【００７８】
上述したように、本実施形態によれば、通信端末が、移動通信ネットワークに接続する場合において、一度確保されたベアラの通信速度が、通信の状況が変化することにより、変化することとなる。したがって、通信端末が密集する場所であっても、最適な通信速度を実現することが可能となる。
【００７９】
なお、本実施形態においては、第１リソース要求値を、記憶部２０６に一時的に記憶することとして説明したが、記憶部２０６に記憶されているリソース要求値を用いても良い。この場合、リソース要求値を再度記憶されているテーブルから読み出す必要があるが、一時的に記憶する必要がなくなる。
【００８０】
また、通信端末５０ａと同じＡＰ３０ａのエリアに接続していた他の通信端末がリソースを占有していたが、通信を終了してリソースに空きが出た場合でも、ＡＰ３０ａからＡＧＷ２０にリソース開放を通知するため、同様にＡＧＷ２０はＡＰ３０ａからの通知を機にリトライを判定することができる。
【００８１】
また、本実施形態においては、第２リソース要求値に基づいて、第２リソース設定トライが失敗した場合には、処理を終了することとして説明したが、要求レベルを段階的に低下させ、第３、第４のリソース要求値を決定してもよいことは勿論である。
【００８２】
一例として、図７は第３リソース要求値まで記載した内容である。例えば、トラフィッククラス２のＣＲＢタイプでは、第１リソース要求値として「３８４ｋｂｐｓ」、第２リソース要求値として「２８８ｋｂｐｓ」、第３リソース要求値として「１４４ｋｂｐｓ」が設定されている。
【００８３】
このとき、まず、ＡＧＷ２０は、第１リソース要求値「３８４ｋｂｐｓ」を設定して無線ベアラ設定要求を送信する。ここで、ＮＡＣＫを受信すると、つぎに第２リソース要求値「２８８ｋｂｐｓ」を設定し、無線ベアラ設定要求を送信する。ここで、再度ＮＡＣＫを受信すると、次に第３リソース要求値「１４４ｋｂｐｓ」を設定し、無線ベアラ設定要求を送信する。ここで、ＡＣＫを受信すると、通信端末と「１４４ｋｂｐｓ」にてベアラが設定される。
【００８４】
ここで、ハンドオーバ発生時に、再度第１リソース要求値「３８４ｋｂｐｓ」を設定して再度無線ベアラ設定要求を送信する。ここで、ＡＣＫを受信すれば、通信端末と「３８４ｋｂｐｓ」にてベアラが設定されることとなる。また、ＮＡＣＫを受信した場合は、つづいて第２リソース要求値「１４４ｋｂｐｓ」を設定して、無線ベアラ設定要求を送信する。ここで、ＡＣＫを受信すると、通信端末と「１４４ｋｂｐｓ」にてベアラが設定されることとなる。
【００８５】
このように、複数のリソース要求値を設けることにより、要求レベルに関しては段階的に適用することが可能となり、通信端末の接続性を保証し適切な通信速度を設定することが可能となる。
【図面の簡単な説明】
【００８６】
【図１】本実施形態におけるネットワーク全体の構成図を示した図である。
【図２】記憶部に、各クラス・サービスタイプと対応づけてリソース要求値を記憶しているテーブルである。
【図３】ＡＧＷの動作を説明するための図である。
【図４】通信端末間の通信を説明するためのシーケンス図である。
【図５】ハンドオーバ時の通信システムの概略を示す図である。
【図６】ハンドオーバ時の通信を説明するための説明図である。
【図７】変形例として記憶部に記憶されるリソース要求値である。
【図８】従来の通信端末間の通信を説明するための図である。
【符号の説明】
【００８７】
１  移動通信システム
１０  セッション制御装置
１０２  サービス情報取得部
１０４  ＱｏＳポリシー通知部
２０、２０ａ、２０ｂ  アクセスゲートウェイ
２０２  位置管理部
２０４  リトライ判定部
２０６  記憶部
２０８  リソース設定部
２１０  データ伝送部
３０  アクセスポイント
３０２  移動検知部
３０４  無線リソース設定部
３０６  データ伝送部
４０  加入者管理サーバ
５０、５０ａ、５０ｂ  通信端末
６０  ＩＰルータ
【図１】
2009159087.tif 000003
【図２】
2009159087.tif 000004
【図３】
2009159087.tif 000005
【図４】
2009159087.tif 000006
【図５】
2009159087.tif 000007
【図６】
2009159087.tif 000008
【図７】
2009159087.tif 000009
【図８】
2009159087.tif 000010