JP2004502378A - 通信システムにおける無線アクセス・ベアラーの再構成方法 - Google Patents

Abstract

コア・ネットワークと、汎用地上無線アクセス・ネットワーク内の無線ネットワーク・コントローラ（ＲＮＣ）に結合されたユーザ装置とを含む通信システムにおいて、ＲＮＣにより開始される無線アクセス・ベアラー（ＲＡＢ）の交渉又は再交渉／再構成の方法である。コア・ネットワークがユーザ装置とのサービス（例えば、音声呼出し、ウェブ・サーフィン・セッション）を確立するとき、ＲＡＢは、そのサービスのためセットアップされる。ＲＡＢは、サービスの品質を達成するある一定のパラメータを含む。ＲＮＣが無線条件をモニタするとき、ＲＮＣは、修正される必要がある１つ以上のＲＡＢパラメータを決定し得る。ＲＮＣは、ＲＡＢに対する修正が必要とされること、及びその修正に影響を及ぼすべき仕方を指定するＲＡＢ修正要求メッセージをＣＮに送ることにより、ＲＡＢ再交渉／再構成手続きを開始するであろう。ＣＮは、ＲＮＣに、修正が許容できるか否かを知らせるＲＡＢ割当て要求メッセージを送り得る。

Description

【０００１】
［発明の分野］
本発明は、一般的に広帯域符号分割多元接続（Ｗ−ＣＤＭＡ）システムの分野に関し、詳細には無線アクセス・ベアラー（ｒａｄｉｏ　ａｃｃｅｓｓ　ｂｅａｒｅｒ）の再交渉／再構成を実行する方法に関する。
【０００２】
［発明の背景］
サービス品質（ＱｏＳ）は、無線通信システムにおいて重要な考慮対象である。様々な種類のサービスが様々なレベルの品質を要求する。例えば、ネットワークとの音声呼出し（ｖｏｉｃｅ　ｃａｌｌ）に参加している移動電話ユーザは、自身の移動電話器上でウェブ・サーフィンしているユーザより（遅延に関して）一層高い品質を要求する。同様に、ウェブ・サーフィン・セッションに参加しているユーザは、音声呼出しに参加しているユーザより一層良好なビット誤り率を要求しそうである。既存の第３世代共同プロジェクト（３ＧＰＰ）基準に従って、移動電話器のようなユーザ装置（ＵＥ）がコア・ネットワーク（ＣＮ）からサービスを要求するとき、ＵＭＴＳベアラー・サービス及び基礎的無線アクセス・ベアラー（ＲＡＢ）サービスは、要求されたサービスのためセットアップされる。このプロトコルは、３ＧＰＰ　ＴＳ２３．１０７ｖ４．０．０（２０００−１２）のセクション６．１、６．１．１、６．１．２に記述されている。現在、ＲＡＢは、幾つかの例を挙げると、トラフィック・クラス、最大ビット・レート、及び保証されたビット・レートのようなサービスのための１９個のパラメータを含む。パラメータは、要求されたサービスに対する要求されたＱｏＳを特徴付ける。
【０００３】
ＲＡＢパラメータは、３ＧＰＰ　ＴＳ２５．４１３ｖ４．０．０（２００１−０３）のセクション９．２．１．３に定義されている。トラック・クラスは、それに対して無線アクセス・ベアラーが最適化される種類の応用と定義される。最大ビット・レートは、１つの時間周期内に汎用地上無線アクセス・ネットワーク（ＵＴＲＡＮ）によりサービス・アクセス点（ＳＡＰ）におけるＵＴＲＡＮへ送られる最大ビット数を上記１つの時間周期の持続時間で除算したものと定義される。保証されたビット・レートは、（送るべきデータがあるという条件で）１つの時間周期内にＳＡＰで送られる保証されたビット数を上記１つの時間周期の持続時間で除算したものと定義される。ＴＳ２５．４１３のセクション８．２及び９．１．３に従って、指定されたＲＡＢパラメータ値を有するＲＡＢ割当て要求メッセージは、ＣＮからＵＴＲＡＮ内の無線ネットワーク・コントローラ（ＲＮＣ）へ送られて、ＲＡＢのためのＣＮにより期待されるＱｏＳをＲＮＣに知らせる。ＲＡＢパラメータのいずれかが変えられる必要がある場合、ＲＡＢの交渉又は再交渉／再構成が実行される。ＲＡＢの交渉は、ＲＡＢパラメータ値を決定する前にＲＡＢの確立で生じる交換を意味する。ＲＡＢの再交渉／再構成は、前に合意されたＲＡＢパラメータ値の一部又は全ての変化を要求するためＲＡＢの確立後に生じる交換を意味する。
【０００４】
例えば、ＴＳ２４．００８，ｖ４．２．０（２００１−０３），ＰＤＰコンテキスト修正手順についてのセクション６．１．３．３のような３ＧＰＰリリース１９９９標準においては、サービスのためのＱｏＳの再交渉は、ＣＮ及びＵＥにより初期化されることができる。これは、無線資源の効率的な管理を可能にしない。それは、ＲＮＣが無線資源を実際に管理するにも拘わらず、ＱｏＳの再交渉をＲＡＢの再交渉／再構成を介して開始して、変化された無線条件を明らかにすることが可能にされないからである。ＲＮＣにより開始されたＲＡＢ再交渉／再構成を実行するのに失敗することにより、無線ネットワークの過負荷、落ちた呼出し、及び残りの呼出しの品質の低下がもたらされる場合がある。例えば、呼出しのためのＲＡＢが最初に１６ｋｂｐｓの最大ビット・レートを指定する場合、ＲＮＣは、変化した無線条件のため最大ビット・レートを１２ｋｂｐｓに低下させる必要がある場合がある。現在は、ＲＮＣは、ＲＡＢの再交渉／再構成を開始して、落ちた呼出しをもたらすことがあり得るこの変化を起こすことができない。従って、無線ネットワークの過負荷、落ちた呼出し、及び呼出しの品質の低下の発生を低減させる、ＲＮＣにより開始されたＲＡＢの再交渉／再構成の方法に対する必要性がある。
【０００５】
［発明の詳細な説明］
本発明は、一般的にＲＮＣにより開始されたＲＡＢの再交渉／再構成の方法を提供する。新しいメッセージ（ＲＡＢ修正要求メッセージ）及び古いメッセージの修正版（ＲＡＢ割当て要求メッセージ、ＲＡＢ割当て応答メッセージ）は、本方法を実行するためＲＮＣとＣＮとの間で交換される。好適な実施形態においては、本方法は、ＵＭＴＳシステムにおいて実行されるが、しかしながら、本方法はまた、ＲＡＢの再交渉／再構成を要求する、広帯域符号分割多元接続（Ｗ−ＣＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、ＧＳＭエボルーション（Ｅｖｏｌｕｔｉｏｎ）のための増強されたデータ（ＥＤＧＥ）、汎用パケット無線サービス（ＧＰＲＳ）又は移動通信用グローバル・システム（ＧＳＭ）の各無線システムのいずれにおいても実行されることができる。図１を参照すると、本発明を実行するため用いることができる単純化されたＵＭＴＳアーキテクチャ１００が示されている。当該技術において知られているように、ＵＭＴＳアーキテクチャ１００は、ＵＴＲＡＮ１０４にＩｕインタフェース１０８を介して結合されたＣＮ１０２を含む。ＵＴＲＡＮ１０４はＲＮＣ１０５を含む。ＵＴＲＡＮ１０４は、ＵＥ１０６にＵｕインタフェース１１０を介して結合されている。図１に示されているＵＭＴＳアーキテクチャ１００についての更なる詳細は、３ＧＰＰ　ＴＳ２５．４０１ｖ４．０．０（２００１−０３）のセクション５及び６から確かめることができる。
【０００６】
図２を参照すると、本発明の方法の好適な実施形態のメッセージ・フロー図が示されている。ＣＮ１０２とＵＥ１０６との間のサービス（例えば、音声呼出し、ウェブ・サーフィン・セッション等）の確立で、ＣＮ１０２は、ＲＡＢ割当て要求メッセージ（ＲＡＲＱＭ）をＲＮＣ１０５に送る。これは、図２におけるステップａとして表されている。ＣＮ１０２は、ＲＡＢ　ＩＤを、サービスと関連したＲＡＢに対して割り当て、そして従来技術で知られているように、そのＲＡＢのため期待されたある一定のＲＡＢパラメータ値を指定する。しかしながら、本発明に従って、ＲＡＲＱＭはまた、ＣＮ１０２がＲＡＢパラメータを交渉可能／再交渉可能なものとして指示し且つある範囲又は組の許容値をその指定されたパラメータの一部又は全てに与えるためのフィールドを含む。例えば、ＣＮ１０２は、ＲＡＲＱＭにおいて、ＲＡＢのため１６ｋｂｐｓの保証されたビット・レートを指定し得る。ＣＮ１０２はまた、８ｋｂｐｓから１６ｋｂｐｓのような、保証されたビット・レートに対する許容範囲を指定し得る。ステップｂにおいて、ＲＮＣ１０５は、ＲＡＢ割当て応答メッセージ（ＲＡＲＳＭ）をＣＮ１０２に送る。ＲＡＲＳＭは、ＣＮ１０２に、ＲＮＣ１０５が何を割り当てることができるか（例えば、それがどのパラメータ値を与えることができるか）を知らせる。例えば、ＲＮＣ１０５が１６ｋｂｐｓの保証されたビット・レートに適合することができない場合、ＲＮＣ１０５は、ＣＮ１０２により指示された許容範囲内にある１２ｋｂｐｓにＲＮＣ１０５が適合できることを応答し得る。
【０００７】
サービスがＣＮ１０２とＵＥ１０６との間で確立された後に、ＲＮＣ１０５は、無線資源をモニタして、サービスの品質に影響を及ぼすことがある無線条件に変化があったか否かを決定する。例えば、ＵＥの位置の変化は呼出しの品質に影響を及ぼし得る。そのようなケースにおいては、ＲＮＣ１０５が呼出しのため現在適所を占めている１つ以上のＲＡＢパラメータを変える必要がある場合がある。本発明に従って、図２のステップｃにおいて、ＲＮＣ１０５は、ＲＡＢ修正要求メッセージ（ＲＭＲＭ）をＣＮ１０２に送ることによりＲＡＢの再交渉／再構成手続きを開始する。ＲＭＲＭは「修正されるべきＲＡＢ」フィールド（又は情報要素（ＩＥ））を含み、該「修正されるべきＲＡＢ」フィールド（又は情報要素（ＩＥ））を用いて、そのためパラメータを修正する必要があるＲＡＢのＲＡＢ　ＩＤを識別し、且つ修正する必要があるＲＡＢパラメータ値を識別する。例えば、音声呼出しは「１」のＲＡＢ　ＩＤを有してよく、そして修正すべきパラメータ値は保証されたビット・レートであってよい。ＲＮＣ１０５は、１２ｋｂｐｓの保証されたビット・レートを呼出しの確立時に与えることが可能であったかも知れないのに対して、変化した無線条件は、ＲＮＣ１０５に、保証されたビット・レートを１０ｋｂｐｓに低下するよう要求し得る。
【０００８】
ＲＭＲＭを受け取ると、ＣＮ１０２は、それが上記要求を受け入れるか否かを決定する。ステップｄにおいて、ＣＮ１０２は、ＲＮＣ１０５に、ＣＮ１０２が要求を受け入れてビット・レートを１０ｋｂｐｓに低下させるか否かを知らせる別のＲＡＲＱＭを送り得る。後に、無線条件が改善された場合、ＲＮＣ１０５は、保証されたビット・レートの増大を要求する別のＲＭＲＭをＣＮ１０２に送り得る。ＲＭＲＭ、ＲＡＲＱＭ及びＲＡＲＳＭは、変えるべきパラメータがある限り、ＣＮ１０２とＲＮＣ１０５との間で交換されるのを継続し得る。
【０００９】
当業者は、様々な修正及び変化を本発明の装置及びこの装置の構成において本発明の範囲又は趣旨から逸脱することなく行うことができることを認めるであろう。例えば、本発明の方法は、特定のＲＡＢの保証されたビット・レート・パラメータの修正を参照して説明された。本方法は、ＲＡＢパラメータのいずれにも同様に適用可能である。
【図面の簡単な説明】
【図１】
図１は、本発明の好適な実施形態を実行するため用いることができるＵＭＴＳシステムのアーキテクチャを示すブロック図である。
【図２】
図２は、本発明の、ＲＮＣにより開始されたＲＡＢの交渉及び再交渉／再構成の方法の好適な実施形態を含むメッセージ・フロー図である。

Claims (7)

1. 無線アクセス・ベアラー（ＲＡＢ）の交渉又は再交渉／再構成方法において、
   少なくとも１つのＲＡＢを修正する必要性を決定するステップと、
   ＲＡＢ修正要求メッセージをコア・ネットワーク（ＣＮ）に送るステップであって、前記メッセージが、修正されるべき少なくとも１つのＲＡＢの識別を指定し、且つ前記少なくとも１つのＲＡＢが修正される必要がある仕方を指定する、前記送るステップと
   を備える方法。
2. 前記ＣＮから、前記少なくとも１つのＲＡＢが前記の指定された仕方で修正されることができるか否かを指示する応答メッセージを受け取るステップと、
   修正を許容できる場合、当該修正を実行するステップと
   を更に備える請求項１記載の方法。
3. 無線ネットワーク・コントローラ（ＲＮＣ）を備える汎用移動通信システム（ＵＭＴＳ）において無線アクセス・ベアラーの交渉又は再交渉／再構成方法を実行する方法であって、
   ＲＮＣにおいて、少なくとも１つのＲＡＢの修正が行われることが必要であることを決定するステップと、
   行われることが必要である前記修正を指定するＲＡＢ修正要求メッセージをコア・ネットワークに送るステップと、
   ＲＡＢ割当て要求メッセージを前記コア・ネットワークから受け取るステップと
   を備える方法。
4. 前記ＲＡＢ修正要求メッセージが、修正する必要がある少なくとも１つのＲＡＢパラメータを識別するため用いられる修正されるべきＲＡＢフィールドを備える請求項３記載の方法。
5. 前記修正されるべきＲＡＢフィールドは更に、前記少なくとも１つのＲＡＢパラメータが修正されるであろうＲＡＢのＲＡＢ　ＩＤを識別する請求項４記載の方法。
6. 前記ＲＡＢ割当て要求メッセージは、前記修正が前記コア・ネットワーク（ＣＮ）にとって許容できるか否かを指定する請求項３記載の方法。
7. 無線ネットワーク・コントローラ（ＲＮＣ）を備える通信システムにおいて、無線アクセス・ベアラー（ＲＡＢ）構成を実行する方法において、
   特定のＲＡＢのための複数のＲＡＢパラメータの各々に対して要求されたパラメータ値を含むＲＡＢ割当て要求メッセージを受け取るステップであって、複数のＲＡＢパラメータの各々にある範囲の又はある組の許容値が与えられる、前記受け取るステップと、
   前記ＲＮＣにおいて、要求されたパラメータ値の各々が受け入れられることができるか否かを決定するステップと、
   前記ＲＮＣが前記複数のＲＡＢパラメータのうちの１つに対して要求されたパラメータ値のうちの１つを受け入れることができない場合、前記複数のＲＡＢパラメータのうちの前記１つに対して前記ある範囲の許容値の中の１つのパラメータ値を指定するＲＡＢ割当て応答メッセージを前記ＣＮに送るステップと
   を備える方法。

Images