(57)【要約】複数の電気通信システムが様々な規格（ＷＬＡＮ、ＵＭＴＳ）に従って動作しかつ統合的に端末（Ｔ）から該システムに到達可能である環境において、電気通信サービスを提供する方法であり、該サービスの少なくとも１つがより多くのシステムにより提供できる。上記サービスの提供リクエストに際し、本発明による方法は、−リクエストされたサービスの提供のために、少なくとも第１（ＷＬＡＮ）及び第２（ＵＭＴＳ）システムの可用性を検証するステップ、及び−リクエストされているサービスの提供のために自動かつ動的に少なくとも前記第１（ＷＬＡＮ）及び前記第２（ＵＭＴＳ）システムのうちの１つを選択するステップを有する。
2005539444.tif 000002
【特許請求の範囲】
【請求項１】
異なる規格（ＷＬＡＮ、ＵＭＴＳ）に従って動作し且つ統合された方法にて端末（Ｔ）から到達可能な複数のシステムが存在する環境内での電気通信サービスの提供方法であって、前記サービスのうち少なくとも１つが、前記複数のシステムのうちのいくつかのシステムにより提供でき、前記方法が、前記少なくとも１つのサービスの提供のリクエストに関して：
-  リクエストされたサービスの提供のため、前記複数システムのうち少なくとも第１（ＷＬＡＮ）システム及び第２（ＵＭＴＳ）システムの可用性を検証するステップ、及び
-  リクエストされたサービスの提供のため自動的かつ動的な方法で前記複数システムにおける前記第１（ＷＬＡＮ）及び前記第２（ＵＭＴＳ）システムのうちの少なくとも１つを選択するステップ
を含むことを特徴とする方法。
【請求項２】
-  ａ）前記複数のシステムのうち、少なくとも前記第１（ＷＬＡＮ）及び第２（ＵＭＴＳ）システムを選択するステップであって、前記第１システム（ＷＬＡＮ）は、前記第２システム（ＵＭＴＳ）に対して優先的に利用されるリソースを形成し；前記選択ステップは、前記サービスを：
-  前記第２システム（ＵＭＴＳ）により実質的に提供される第１セットのサービス、及び
-  前記第１システム（ＷＬＡＮ）と前記第２システム（ＵＭＴＳ）の両方により提供される第２セットのサービス
に細分できる前記ステップ、
-  ｂ）前記第１セット内のサービスの提供のリクエストの場合（１０２）、リクエストされた前記第１セットの前記サービスを提供する前記第２システムの可用性を検証し（１０４）、前記第２システムが利用可能か否かに依存して、前記第２システム（ＵＭＴＳ）による前記第１セットの前記サービスをそれぞれ供給する（１０６）及び供給しない（１１０）ステップ、
-  ｃ）前記第２セットのサービスに対する提供リクエストの場合（１１２、１２７、１３６）、
-  ｃ１）リクエストされた前記第２セットの前記サービスを提供するために前記第１システム（ＷＬＡＮ）の可用性を検証し（１１４、１２８、１３８）、もし前記第１システムが利用可能であるならば、リクエストされた前記第２セットの前記サービスを前記第１システム（ＷＬＡＮ）により提供し（１１６）、
-  ｃ２）もし前記第１システム（ＷＬＡＮ）が、リクエストされた前記第２セットの前記サービスの伝送に利用できないならば、リクエストされた前記第２セットの前記サービスを提供するために前記第２システム（ＵＭＴＳ）の可用性を検証し、前記第２システム（ＵＭＴＳ）が、リクエストされた前記第２セットの前記サービスの提供に利用可能であるか否かに依存して、リクエストされた前記第２セットの前記サービスを提供し（１２０、１３２、１４２）及び提供しない（１２６、１３４、１４４）ステップ
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記選択ステップが、前記第１セット内で少なくとも変更された通信リソースの条件下で提供できるサービスのサブセットを見つけるように実行されること、及び前記サブセットのサービスに対する提供リクエストの存在下（１０８）、リクエストされた前記サブセットの前記サービスの提供のために、前記第２システム（ＵＭＴＳ）の非可用性を検証するステップ（１０４）を含み、一旦前記非可用性が検証されたなら、提供リクエストを再交渉するステップ（１０９）を含み、それにより変更された通信リソースの条件下にて提供するために前記サブセットの前記サービスを再度リクエストすることを特徴とする請求項２に記載の方法。
【請求項４】
前記選択ステップが、前記第２セット内で少なくとも１つの変更された通信リソースの条件下で配達可能なサービスのそれぞれのサブセットを与えるように実行されること、及び前記それぞれのサブセットのサービスに対する提供リクエストが存在するときは（１１２）、リクエストされた前記それぞれのサブセットの前記サービスの提供のため前記第１（ＷＬＡＮ）及び前記第２（ＵＭＴＳ）システムのうち少なくとも１つの非可用性を検証する（１１４）ステップ、及び前記非可用性の検証（１１４、１１８）の後、提供リクエストを再交渉し（１２４）、それにより前記それぞれのサブセットの前記サービスの提供を、変更された通信リソースの条件下で再度リクエストするステップを含むことを特徴とする請求項２又は請求項３に記載の方法。
【請求項５】
前記選択ステップが、前記セット及び前記それぞれのサブセットのうち少なくとも１つ内で、変更された通信リソースの複数の条件下で提供され得るサービスを与えることができるように実行されること、及び前記方法が、次に変更された通信リソース下でのサービス提供のリクエストを反復して再交渉する（１０９、１２４）ステップを含むことを特徴とする請求項３又は請求項４に記載の方法。
【請求項６】
前記選択ステップが、前記サービスを、会話クラスのサービスを含んだ第１セットと、ストリーミングサービス、双方向サービス、及びバックグラウンドサービスのクラスのうちの少なくとも１つのクラスに含まれるサービスを含んだ第２セットとに細分するステップを含むことを特徴とする請求項２〜５のいずれか一項に記載の方法。
【請求項７】
前記第２セットのサービスの前記それぞれのサブセットが、ストリーミングクラスのサービスを含むことを特徴とする請求項４及び請求項６に記載の方法。
【請求項８】
前記選択ステップが、モバイル通信システムから形成されるグループ内で前記システムを選択することにより実行されることを特徴とする請求項１〜７のいずれか一項に記載の方法。
【請求項９】
前記選択ステップが、ＵＭＴＳ、ＷＬＡＮ及び８０２．１１システムにより形成されたグループ内で前記システムを選択することにより実行されることを特徴とする請求項８に記載の方法。
【請求項１０】
ユーザー数が増加した際に前記第１システムの性能低下を検出することにより、ユーザーのアドミッションコントロールの基準に基づいて前記第１システム（ＷＬＡＮ）の可用性を検証するステップを含むことを特徴とする請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
-  前記第１システム（ＷＬＡＮ）上のアクティブなユーザーに利用可能な総ビットレートを検出するステップ、
-  新しいユーザーの可能なアドミッションに際して利用可能なビットレートが閾値に到達すると、前記第１システムを新しいユーザーには利用不可と見なすステップ
を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記第２システムの負荷パラメータ（η）を定義すること、及び前記負荷パラメータが閾値に到達すると前記第２システムを利用不可と見なすことにより、前記第２システム（ＵＭＴＳ）の可用性を検出するステップを含むことを特徴とする請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
前記負荷パラメータ（η）が「ポールキャパシティ」に基づいて導出されるパラメータであることを特徴とする請求項１２に記載の方法。
【請求項１４】
異なる規格（ＷＬＡＮ、ＵＭＴＳ）に従って動作し且つ統合された方法にて端末（Ｔ）からアクセスできる複数の電気通信システムが与えられた環境における電気通信サービスの提供システムであって、前記サービスのうち少なくとも１つが、前記複数の電気通信システムのうちより多くの電気通信システムにより配達可能であり、該システムは、前記少なくとも１つのサービスに対する提供リクエストがある場合に、前記複数の電気通信システムと以下の目的、すなわち：
-  リクエストされたサービスの提供のため、前記複数の電気通信システムのうち少なくとも第１（ＷＬＡＮ）システム及び第２（ＵＭＴＳ）システムの可用性を検証すること、及び
-  リクエストされたサービスの提供のため自動的で動的な方法にて前記複数の電気通信システムのうち前記少なくとも第１（ＷＬＡＮ）システムか第２（ＵＭＴＳ）システムを選択すること
をもって協働できるモジュール（１０）を組み込むことを特徴とする提供システム。
【請求項１５】
前記モジュール（１０）が、前記複数の電気通信システムのうち前記少なくとも第１（ＷＬＡＮ）及び第２（ＵＭＴＳ）システムに共通のコントローラ要素に統合されたことを特徴とする請求項１４に記載のシステム。
【請求項１６】
-  ａ）前記複数の電気通信システム内で前記少なくとも第１（ＷＬＡＮ）システム及び前記少なくとも第２（ＵＭＴＳ）システムを選択し、ここで、前記第１システム（ＷＬＡＮ）は前記第２システム（ＵＭＴＳ）に対して利用されるのが好ましいリソースを形成し；前記選択は、前記サービスを：
-  前記第２システム（ＵＭＴＳ）によってのみ実質的に配達可能な第１セットのサービス、及び
-  前記第２システム（ＵＭＴＳ）のみならず前記第１システム（ＷＬＡＮ）によっても配達可能な第２セットのサービス、
に細分でき、
-  ｂ）前記第１セット内のサービスの提供に対するリクエストの場合（１０２）、リクエストされた前記第１セットの前記サービスを提供するために前記第２システムの可用性を検証し（１０４）、前記第２システムが利用可能か否かに依存してそれぞれ前記第１セットの前記サービスを前記第２システム（ＵＭＴＳ）により提供する（１０６）又は提供せず（１１０）、
-  ｃ）前記第２セット内のサービスに対する提供リクエストの場合（１１２、１２７、１３６）、
-  ｃ１）リクエストされた前記第２セットの前記サービスを提供するために前記第１システム（ＷＬＡＮ）の可用性を検証し（１１４、１２８、１３８）、もし前記第１システムが利用可能であるならば、リクエストされた前記第２セットの前記サービスを前記第１システム（ＷＬＡＮ）により配達し（１１６）；
-  ｃ２）もしリクエストされた前記第２セットの前記サービスを提供するのに前記第１システム（ＷＬＡＮ）が利用できなければ、リクエストされた前記第２セットの前記サービスを提供するために前記第２システム（ＵＭＴＳ）の可用性を検証し、リクエストされた前記第２セットの前記サービスの提供に前記第２システム（ＵＭＴＳ）が利用可能か否かに依存して、リクエストされた前記第２セットの前記サービスを提供し（１２０、１３２、１４２）又は提供しない（１２６、１３４、１４４）、
ように前記モジュールが構成されることを特徴とする請求項１４又は請求項１５に記載のシステム。
【請求項１７】
前記モジュール（１０）は、前記選択が前記第１セット内で、少なくとも低下した通信リソースの条件下で配達可能なサービスのサブセットを存在させ得るように、前記選択ステップを実行すべく構成されること、及び前記サブセットのサービスの提供リクエストの場合（１０８）には、前記モジュール（１０）は、リクエストされた前記サブセットの前記サービスの提供のために前記第２システム（ＵＭＴＳ）の非可用性を検証し（１０４）、一旦前記非可用性が検証されたならば提供リクエストを再交渉し（１０９）、それにより前記サブセットの前記サービスが再度リクエストされ、低下した通信リソースの条件下にて提供されるように構成されることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記モジュール（１０）は、前記選択が前記第２セット内で少なくとも低下した通信リソースの条件下で提供され得るサービスのそれぞれのサブセットを与えることができるように、前記選択ステップを実行すべく構成されること、及び前記それぞれのサブセットのサービスに対する提供リクエストの場合（１１２）に、前記モジュール（１０）は、リクエストされた前記それぞれのサブセットの前記サービスの提供のために前記第１（ＷＬＡＮ）及び第２（ＵＭＴＳ）システムのうち少なくとも１つの非可用性を検証し（１１４）、一旦前記非可用性（１１４、１１８）が検証されたら、提供リクエストを再交渉し（１２４）、それにより前記それぞれのサブセットの前記サービスの提供が、低下した通信リソースの条件下で再度リクエストされるように構成されることを特徴とする請求項１６又は請求項１７に記載のシステム。
【請求項１９】
前記モジュール（１０）は、前記選択が前記セットと前記それぞれのサブセットのうち少なくとも１つ内で変更された通信リソースの複数の条件下で与えることができるサービスを提供し得るように、前記選択ステップを実行するように構成されること、及び前記モジュール（１０）は、次に変更された通信リソースの条件下でのサービス提供のリクエストを反復して再交渉する（１０９、１２４）ように構成されることを特徴とする請求項１７又は請求項１８に記載のシステム。
【請求項２０】
前記モジュール（１０）は、前記選択ステップが前記サービスを会話クラスのサービスを含んだ第１セットと、ストリーミングサービス、双方向サービス、及びバックグラウンドサービスのクラスのうちの少なくとも１つのクラスに含まれるサービスを含んだ第２セットのサービスとに細分できるように構成されることを特徴とする請求項１６〜１９のいずれか一項に記載のシステム。
【請求項２１】
前記第２セットのサービスの前記それぞれのサブセットが、ストリーミングクラスのサービスを含むことを特徴とする請求項１８及び請求項２０に記載のシステム。
【請求項２２】
前記モジュール（１０）は、前記複数の前記電気通信システムなどのモバイル通信システムと協働するように構成されることを特徴とする請求項１４〜２１のいずれか一項に記載のシステム。
【請求項２３】
前記モジュール（１０）は、ＵＭＴＳ、ＷＬＡＮ及び８０２．１１システムにより形成されたグループに含まれる電気通信システムと協働するように構成されることを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記モジュール（１０）が、無線ネットワーク型コントローラ又はＲＮＣコントローラに統合されることを特徴とする請求項２３に記載のシステム。
【請求項２５】
前記モジュール（１０）は、ユーザーの数が増加した際に前記第１システムの性能低下を検出することにより、ユーザーのアドミッションコントロールの基準に基づいて前記第１システム（ＷＬＡＮ）の可用性を検証するよう構成されることを特徴とする請求項１４〜２４のいずれか一項に記載のシステム。
【請求項２６】
前記モジュール（１０）は、
-  前記第１システム（ＷＬＡＮ）上でアクティブなユーザーが利用できる総ビットレートを検出し、
-  新しいユーザーの可能なアドミッションに従って利用可能なビットレートが閾値に到達すると、前記第１システムを新しいユーザーに利用不可と見なす
ように構成されることを特徴とする請求項２５に記載のシステム。
【請求項２７】
前記モジュール（１０）は、前記第２システムの負荷パラメータ（η）を定義すること、及び前記負荷パラメータが閾値に到達すると、前記第２システムを利用不可と見なすことにより、前記第２システム（ＵＭＴＳ）の可用性を検出するよう構成されることを特徴とする請求項１４〜２６のいずれか一項に記載のシステム。
【請求項２８】
前記負荷パラメータ（η）が「ポールキャパシティ」に基づいて導出されるパラメータであることを特徴とする請求項２７に記載のシステム。
【請求項２９】
デジタルコンピュータの内部メモリに直接ロードできるコンピュータプログラム製品であって、前記製品がコンピュータ上で実行されるとき、請求項１〜１３のいずれか一項に記載の方法を実行するソフトウエアコード部分を含むコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、同時に異なる規格に従って動作する２つの電気通信システムが存在する環境において、電気通信サービスを提供することに関する。
【背景技術】
【０００２】
例として（ただし本発明の範囲を限定するものと見なすべきでない、すなわち十分に一般的である）、この２つの電気通信システムは、ＵＭＴＳ（ユニバーサルモバイル電気通信システム）規格、及び無線ローカルエリアネットワーク（ＷＬＡＮ）規格（例えば現在８０２．１１として示される規格など）に従って動作する２つのモバイル通信システムであり得る。
【０００３】
非特許文献１には、両方のシステムの完全な統合を実現できるアーキテクチャー上の解決策が記載されており、このような統合は、無線モードにて実行され、ネットワークの最適管理の可能性を与える。
【０００４】
密接に関係したトピックスが、非特許文献２において論じられている。この文献は、特に、このようなシステムのスループットを向上すること、及びユーザーに最高のサービスの質を提供することを目的とした解決策の重要性を強調する。
【非特許文献１】標題「Ｓｔａｎｄ−Ａｌｏｎｅ  Ｄａｔａ−Ｃｅｌｌｓ  ｆｏｒ  ＵＭＴＳ」の文献［ヘルシンキ（フィンランド）にて２００１年１０月１８−１９日に開催された３ＧＰＰ  Ｆｕｔｕｒｅ  Ｅｖｏｌｕｔｉｏｎ  ＷｏｒｋｓｈｏｐでＴｄｏｃ  ＦＥＷ−００３２／０１論文として提出］
【非特許文献２】Ｍ．Ｈｉｌｄｅｂｒａｎｄ、Ｇ．Ｃｒｉｓｔａｃｈｅ、Ｋ．Ｄａｖｉｄ及びＦ．Ｆｅｃｈｔｅｒによる文献「Ｌｏｃａｔｉｏｎ−ｂａｓｅｄ  Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ  ｉｎ  Ｍｕｌｔｉ  Ｓｔａｎｄａｒｄ  Ｗｉｒｅｌｅｓｓ  Ｎｅｔｗｏｒｋ  Ｅｎｖｉｒｏｎｍｅｎｔｓ」［２００２年６月１７−１９日にセサロニキ（ギリシャ）で開催されたＩＳＴ  Ｍｏｂｉｌｅ  ＆  Ｗｉｒｅｌｅｓｓ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｕｍｍｉｔ  ２００２にて提出］
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、統合シナリオにより与えられる機会を最適に利用できる解決策を提供することである。これは、特に、ネットワーク管理者（又はオペレータ）の要求及びサービスをリクエストしているユーザーの要求を考慮し、統合システムへのアクセスの最適選択を動的に実行する可能性に関する。
【課題を解決するための手段】
【０００６】
本発明により、この目的は、特許請求の範囲に具体的に記載の特徴をもった方法により達成される。本発明はまた、対応するシステム及び関連の情報技術製品にも関する。この情報技術製品は、デジタル計算装置の内部メモリに直接ロードでき、該製品がコンピュータ上で実行されるとき本方法のステップを実行するためにソフトウエアコードの部分を組み込む。
【０００７】
いずれにせよ、本発明による解決策は、上述したような統合シナリオへの適用に関して特にうまくいったが、同じ基本的な原理が直面している任意の状況に有利に適用できる。よって、本発明による解決策は、統合された方法にて共に動作する２より多い複数の電気通信システムの統合が予見される状況だけでなく、上述した規格又は後に具体的に述べる規格とは異なる規格に従って動作する電気通信ネットワークにも適用できる。
【０００８】
したがって、本発明による解決策により、
-  異なる規格に従って動作し、かつ統合的に端末から到達可能な複数の電気通信システムがあり、
-  サービスの少なくとも１つがより多いシステムにより、よって、異なる規格により提供され得る
ような環境において電気通信サービスを提供することが可能となる。
【０００９】
本発明による解決策では、上述した少なくとも１つのサービスの提供のリクエストに関し、リクエストされたサービスの提供のために、少なくとも第１及び第２システムの可用性が存在することが想定される。次に、リクエストされたサービスの提供のために、自動かつ動的に、２つのシステムのうち１つが選択される。この選択は、統合システム内でリクエストされるサービスの提供のために優先すると見なされる通信リソースを自動かつ動的に選択可能にするために、固有のモジュールを介して行われるのが好ましい。
【００１０】
以下、添付図面に関し非限定的な例により本発明を説明する。
-  図１は、本発明による解決策の一般的な適用のシナリオを示す。
-  図２は、本発明による解決策の実施を説明するフローチャートである。
-  図３は、本発明においてＷＬＡＮネットワーク又は類似のネットワークの負荷状態を評価するのに用いられる線図である。
【発明を実施するための最良の形態】
【００１１】
本発明による解決策は、図１のブロック図に示されたタイプのマルチモードシナリオ（すなわちマルチシステム又はマルチ規格シナリオ）に優先的に適用される。
【００１２】
基本的には、システムにリンクされる端末Ｔは、例えばＵＭＴＳや８０２．１１規格などの様々な規格を同時にサポートできるマルチモード又はマルチシステム端末であることが想定される。
【００１３】
したがって、このような端末は、次のものとインターフェースできる。
-  規格に関してなんら変更することなく信号を空中伝送するのに適したＵＴＲＡＮ（ＵＭＴＳ地上無線アクセスネットワーク（この用語はＵＭＴＳシステムへの無線アクセスのネットワークＮを示す））の要素を形成するノード（ここではノードＢと称する）、及び
-  アクセスポイントＡＰ、すなわち、信号を空中伝送するよう構成された８０２．１１システムの要素。
【００１４】
アクセスポイントＡＰの場合、端末Ｔと交換される情報は、ＡＰ標準モードにおいて想定される情報に本質的には等しいが、いわゆる無線ネットワークコントローラ（ＲＮＣ）（標準的なタイプであるが、８０２．１１システムを管理するよう構成された機能と一体化されている）への接続の可能性も予想される。
【００１５】
基本的には、アクセスポイントＡＰとコントローラＲＮＣは、互いに次の２つのパラメータを伝達しなければならない。
-  ＷＬＡＮネットワークにリンクされたユーザーの数、及び
-  同一のＷＬＡＮネットワーク上における進行中の通信の総ビットレート。
【００１６】
このプロシージャに関与するパラメータは次の通りである。
・ＳＩＦＳ（ショート・インターフレーム・スペース）＝２８μｓ
・バックオフ・スロット・タイム＝５０μｓ
・伝搬遅延＝１μｓ
・ｔｓｌｏｔ＝２０μｓ
・ＣＷ  ｍｉｎ（最小コンテンション・ウインドウ）=３２
・ＣＷ  ｍａｘ（最大コンテンション・ウインドウ）=２５６
【００１７】
ＵＭＴＳネットワークのインフラに関する限り、いわゆるコアネットワーク規格、特にＵＴＲＡＮネットワークとインターフェースするＳＧＳＮ（サービングＧＰＲＳサポートノード）と称するノードに関して、変更は想定されない。
【００１８】
上記すべては、統合シナリオ中にて設定され、その際、ノードＢとアクセスポイントＡＰは、好ましくは、これらの規格により想定される現在のコントローラＲＮＣの新型バージョンである固有のコントローラにより管理される。図１における特定の従来様式の構成に関する更なる情報は、上述した３ＧＰＰ  Ｆｕｔｕｒｅ  Ｅｖｏｌｕｔｉｏｎｓ  Ｗｏｒｋｓｈｏｐに提出の文献及び３ＧＰＰ仕様から得られる。後者は、ＧＳＭ仕様（ＧＰＲＳ及びＥＤＧＥを含む）と３Ｇ（第３世代）仕様のすべてを含む。３Ｇ仕様を用いるネットワークの説明に用いられるその他の用語には、ＵＴＲＡＮ、Ｗ−ＣＤＭＡ、ＵＭＴＳ（欧州にて）及びＦＯＭＡ（日本にて）がある。
【００１９】
ここに記載の状況においては、異なる種類の電気通信サービスの提供が一般に想定される。（単に例示目的のためであるが）基本的な概念を定義するために、ＵＭＴＳ規格に用いられるサービスの標準的な分類を参照できる。
【００２０】
このような状況では、まず会話サービスが扱われる。このサービスは、音声及びテレビ会議サービスの場合のように、ユーザー間でのリアルタイム呼に用いられるサービスの種類又はクラスに属する。人の知覚の特性に合わせるべく、転送時間は、短く保たなければならず、情報ストリームの様々な部分間の時間関係は、変えずに維持しなければならない。
【００２１】
次に、ユーザーがオーディオ／ビデオストリームを受け取るのを望む場合のためのストリーミングサービスを説明する。これは、通常は、モバイル端末などの端末にサーバにより提供される一方向サービスである。情報ストリームの様々な部分間の時間関係が変わらず維持されることが重要であるが、全体としての情報転送時間への特に厳しい要求は予想されない。この情報はまた、人間がジッター現象を知覚しないように、受信端末のバッファレベルにて記憶される。
【００２２】
次に、インターネットナビゲーション又はネットワークサーバへのアクセスの場合のようにユーザーがモバイル装置からデータをリクエストするときはいつでも用いられる双方向サービスのクラスがある。この場合、重要な要素はいわゆる往復遅延（ＲＴＤ）とデータ保全性である。
【００２３】
次に、バックグラウンドサービスのクラスがあり、これは、低い優先度で実行される、すなわちバックグラウンド上で実施される確率が高いアプリケーションを識別する。サービスの質すなわちＱｏＳに関するサービスのいくつかの例は、電子メールメッセージの伝送すなわちいわゆるＳＭＳである。この場合、タイムリミットは重要でないが、データ統合が重要である。
【００２４】
本発明による解決策は、上述した状況で提供される機会を最もよく利用することを狙ったものである。このことは、ネットワーク管理者（又はオペレータ）及びサービスをリクエストしているユーザーの要求を考慮して、無線アクセスの最適選択を動的に実施する技術により可能になる。
【００２５】
ここに記載の解決策では、以下のパラメータに基づいて選択を行うことが想定される：
-  ユーザーによりリクエストされるサービスのクラス；
-  伝送リソースの可用性（例えば、ＷＬＡＮサイドのみならずＵＭＴＳサイドでの無線リソース）；
-  サービスを再交渉する可能性
【００２６】
当該解決策は、以下の指針に従って機能する。
【００２７】
原則的に、ＵＭＴＳ規格は、２Ｍｂｉｔ／ｓの伝送能力を有するが、８０２．１１ｂ規格は、１１Ｍｂｉｔ／ｓに等しい総伝送能力を有する。ＵＭＴＳ規格はさらに、サービスの質（ＱｏＳ）の観点から最高の保証を与えることができる。
【００２８】
したがって、ＵＭＴＳ伝送リソースは、より有用なものと見なすことができ、また、これは、リソースが利用できない場合であって、厳しいＱｏＳの要求をするサービスに対してのみそれを利用するために、ＵＭＴＳネットワークの負荷を無くすかできるだけ小さくする基準を正当化する。その他の点については、８０２．１１ｂシステムは、その高ビットレートのおかげでＱｏＳの観点から特に厳しい要求を有しないサービスの最良のサポートを提供する。
【００２９】
実際、本発明によるシステムは、本発明の冒頭で言及した統合シナリオにおいて既に想定したＲＮＣコントローラ内に統合されたモジュール１０（図１を参照）の形態にて実現できる。
【００３０】
関連の操作方法を図２のフローチャートに示す。
【００３１】
このフローチャートでは、１００で示されたステップは、ユーザーが端末Ｔを介して行うサービスリクエストを表す。後のアクションにより、ＲＮＣコントローラに所与の特徴を有するいわゆるＲＡＢ（無線アクセスベアラー(Bearer)）を確立させるリクエストが生じる。
【００３２】
後に説明する選択に対して要求される特徴は、本質的に、リクエストされるサービスのクラス、ビットレート及びサービスを再交渉する可能性などのパラメータに対応する。
【００３３】
ステップ１０２では、リクエストされたサービスが会話型のサービスであるか否かがチェックされる。ＷＬＡＮ規格は会話サービスをサポートするには適当でないので、もしステップ１０２の検査結果が肯定であるならば、システムはステップ１０４に直接進み、そこでＵＭＴＳ通信リソースが利用可能か否かのチェックが行われる。もしステップ１０４での検査結果が肯定であるならば、システムは更なるステップ１０６にさらに進み、このようにしてサービスがＵＭＴＳシステム上で提供されるのを可能にする。もしＵＭＴＳリソースが利用できない（ステップ１０４の否定的な検査結果）ならば、システムはステップ１０８に進み、ここでより大きなデータ転送速度が必要とされるか否かがチェックされる。
【００３４】
実際、ステップ１０８では、当該サービスが当初リクエストされた特徴（例えば、ビットレート）を備えることができないとき、該サービスが変更された特徴、例えば当初予見されたビットレートよりも低いビットレートを有することができるか否かがチェックされる。
【００３５】
もしステップ１０８での検査結果が否定であれば、システムは、ステップ１１０に進み、提供されていないサービスを与えることはできないことを通知する。
【００３６】
代わりに、もしステップ１０８の検査が肯定であれば（これは、いわゆるサービスの「再交渉」を開始して低いデータ転送速度でそれを提供することが可能であることを示す）、システムは、再交渉ステップ１０９を通ってステップ１０４に戻る。
【００３７】
次に、最初にリクエストされたサービス特性ではなく、例えば低いデータ転送速度に関する再交渉から得られるサービス特性を参照することにより、ＵＭＴＳリソースの可用性について再度調べられる。
【００３８】
この操作方法の最終結果は、場合によってはさらなる「再交渉された条件（このことが可能ならば）」下での更なる試みを実行した後におけるＵＭＴＳ上のサービスの提供（ステップ１０６）、又はサービスの限定的な非提供（ステップ１１０）となる。
【００３９】
もしステップ１０２においてリクエストされたサービスが会話型のサービスでないことが確認されたならば、システムは、ステップ１１２に進み、ここで、リクエストされたサービスがストリーミングサービスであるか否かが調べられる。
【００４０】
この種のサービスは、ＷＬＡＮリソースを介して提供され得るし、同様にＵＭＴＳリソースを介しても提供し得る。しかしながら、後者は（上述した理由により）より有用なリソースと見なされている。
【００４１】
このため、もしステップ１１２が否定の結果を生じて、リクエストされたサービスがストリーミングサービスであることを示せば、システムは、まずステップ１１４に進み、ここでＷＬＡＮリソースが利用可能か否かが調べられる。
【００４２】
もしステップ１１４のテスト結果が否定ならば、システムは、適当なデータ転送速度のＷＬＡＮ上でのサービスの割当及び提供に対応する１１６で示されたステップに進む。
【００４３】
代わりに、もしステップ１１４の検査が、システムが検証する否定の結果を与えるならば（なぜなら、ＷＬＡＮリソースが利用可能でないことが分かるので。関連の検証は後に説明する基準により実施される）、次のステップ１１８でシステムは、代わりにＵＭＴＳリソースが利用可能か否かを検証する。
【００４４】
いったんＵＭＴＳリソースの可用性が検証された（ステップ１１８の否定結果）ならば、システムは、ＵＭＴＳネットワーク上でのストリーミングサービスの提供に対応するステップ１２０に進む。
【００４５】
もしＵＭＴＳリソースが利用できない（ステップ１１８の否定結果）ならば、システムは、上述したステップ１０８に実質的に類似したステップ１２２に進む。
【００４６】
ステップ１２２は、場合によってありうるサービスの再交渉のメカニズムに対応し、これは、ユーザーによりリクエストされたストリーミングサービスが異なるデータ転送速度をもち得るか否かを調べることにより、特に、より低いデータ転送速度で試みることにより実施される。
【００４７】
しかしながら、ステップ１２４により表されるこのような試みは、好ましくは、ＵＭＴＳリソースに戻る（ステップ１１８）代わりに、ＷＬＡＮリソース（有用性が低いと見なされているので、好ましくはＵＭＴＳリソースに関して用いられる）の可用性を再度検証する（ステップ１１４）ことにより実行される。
【００４８】
この場合にも、会話型のサービスに関して上述した場合のように、手順の最終結果は、ＵＭＴＳ上のサービス提供（より低いデータ転送速度での１回以上の試みが為された後-ステップ１１６）、又はステップ１２６により表されるサービスを提供できないことの最終通知である。
【００４９】
実質的に同様の基準（サービスの再交渉の可能性なし）が、双方向又はバックグラウンド型のサービスの提供に対して採用される。
【００５０】
特に、ステップ１１２の結果が否定だと（リクエストされるサービスは会話型でもストリーミング型でもない）、システムはさらなる選択ステップ１２７に進み、ここで、リクエストされているサービスが双方向サービスであるか否かが調べられる。
【００５１】
その結果が肯定の場合、もう一度システムがステップ１２８にてＷＬＡＮリソースの可用性を検証する。
【００５２】
もしこのようなリソースが利用可能であるならば（ステップ１２８の結果が肯定）、当該サービスがＷＬＡＮ上に適当なデータ転送速度で割り当てられる（ステップ１１６）。
【００５３】
もしステップ１２８がリソースの非可用性を示すならば、システムはステップ１３０に進み、ここでＵＭＴＳリソースの可用性が検証される。
【００５４】
その結果が肯定の場合は、システムは、ＵＭＴＳを介した双方向サービスの提供に対応するステップ１３２に進む。代わりに、もしステップ１３０が否定の結果を有し、ＵＭＴＳリソースの非可用性を示すならば、システムは、サービスの非提供に対応するステップ１３４に直接進む。これは、双方向型のサービスでは通常はより低いデータ転送速度の再交渉の試みが行われることは起こりそうもないことに起因する。
【００５５】
１２７で示されたステップで起こりうる否定結果は、リクエストされたサービスが会話クラスでもストリーミングクラスでもなく、また双方向クラスでもないことを示し、リクエストされたサービスをバックグラウンドサービスとして識別する。
【００５６】
いったんこのことが１３６で示されるステップで確認されたら、システムは再びステップ１３８に進んでＷＬＡＮリソースの可用性を調べる。
【００５７】
その結果が肯定の場合には、当該サービスは、利用可能として識別されたＷＬＡＮネットワーク上に割り当てられる。これは１１６で示されたステップで行われる。
【００５８】
代わりに、もしステップ１３８が、ＷＬＡＮリソースの非可用性を示す否定結果を与えるならば、システムはステップ１４０に進み、ここでＵＭＴＳリソースの可用性が調べられる。
【００５９】
上述したステップ１３０、１２３、１３４で採用した基準と基本的に類似の基準に従って、ステップ１４０の結果により、択一的に、ＵＭＴＳ上のサービス提供（ステップ１４２）又はサービス提供を出来ないことの通知（ステップ１４４）に導かれる。
【００６０】
要するに、上述した操作基準は、以下の一般的なフローチャートに遡ることができる。
【００６１】
まず、リクエストされたサービスのクラスが点検される。
【００６２】
ＷＬＡＮ規格は、会話型のサービスをサポートするにはかなり不適当であるので、この型のサービスはすぐにＵＭＴＳネットワークに送られる。
【００６３】
いったん上記の点検が行われ、リクエストされたサービスが会話型でないことが確認されたなら、システムは、一種のアドミッション・コントロールを行うことにより、ＷＬＡＮリソースが利用可能か否かを検証する。
【００６４】
実際には、ＷＬＡＮ上のユーザーのアドレス指定がネットワークに過度の負荷を掛けて、全体のシステム性能に許容できない低下を生じさせることのないことを検証すべく点検される。
【００６５】
もしＷＬＡＮリソースが利用可能であるならば、当該サービスはこの無線アクセス上に割り当てられ、本手順は終了する。
【００６６】
もしＷＬＡＮリソースが利用可能でない（すなわち、最初に実施された点検が肯定結果を与え、会話型のサービスのリクエストを通知した）ならば、（既にＵＭＴＳシステムで想定されＲＮＣコントローラにより実施される）アドミッション・コントロールの手順によりＵＭＴＳリソースの可用性が調べられる。
【００６７】
もしＵＭＴＳリソースが利用可能であるならば、当該サービスはこの無線アクセス上に割り当てられ、本手順は終了する。
【００６８】
もしＵＭＴＳリソースが利用可能でないならば、サービスを再交渉するメカニズムが利用され（会話サービス又はストリーミングの場合にのみ）、より低いサービス条件での試みが本手順により繰り返される。
【００６９】
いずれにせよリソースの新たな点検後にはこの手順は終了する。もしサービスが、より低いリソースで提供でき、このリソースが利用可能であるならば、当該サービスが提供され、さもなければサービスは提供されない。
【００７０】
会話又はストリーミングサービスに利用できる無線リソースがない場合には、サービスを再交渉し、最初にリクエストされたものに比べて低いデータ転送速度を提供することによりリクエストを満たすことができる。
【００７１】
より低いデータ転送速度での試み（ステップ１０９及び１２４）は、本質的に、より低い速度でリソースを再び制御しようと試みることにより、データ転送速度のリクエストを下げることができるか否かを調べることに対応する。
【００７２】
様々なクラスのうちでリクエストされたサービスを確認するために、上述した定義に基づいてステップ１０２、１１２及び１２７での点検手順が想定される。
【００７３】
ＷＬＡＮ又はＵＭＴＳ上のサービス割当は、リソースについての関連の点検が肯定結果を与えたということに対応し、サービスが無線アクセス又は８０２．１１ｂ又はＵＭＴＳ規格により提供される。
【００７４】
リクエストされたサービスを提供する可能性がなく本手順が終了すると、サービス条件を満たすのに利用できる無線リソースがないので、当該サービスは提供されない。
【００７５】
リソースの可用性の検証に関し、ＵＭＴＳリソースの場合、いわゆる「ポール・キャパシティ(pole capacity)」の定義から導出される式（それ自体は公知）により検証を実行できる。「アップリンク」の場合、この式は次の通りである。
η＝（１＋ｆ）＊ＳＮＲ＊ＳＡＦ
【００７６】
この式は、ηパラメータの定義に対応し、最大の理論値に関して標準化されたセル負荷を同定する。例えば、このパラメータが０．７に等しいときには、負荷されたセルを考慮に入れることができる。
【００７７】
ｆは、当該セルに隣接したセルにより生じる干渉を考慮したパラメータを意味する。
【００７８】
ＳＮＲは、要求されるノイズに対する信号の比、すなわち所与のサービスが十分にサポートされるのに必要なノイズに対する信号の比を意味する。
【００７９】
最後に、ＳＡＦ（サービス・アクティビティ・ファクター）により示されるパラメータは、ソースがアクティブである間の平均タイムスロットを示す。
【００８０】
上記の式は、個々の顧客を参照する。合計値は、パラメータの部分値を計算し（すなわち各々のアクティブ接続のその値を計算し）、このようにして得られた項すべてを総計することにより得られる。上記式は、ネットワーク負荷の適当な概算を与え、よってアドミッション・コントロールの挙動を図式化するしそれにより利用可能なＵＭＴＳリソースについての問いに対する答えを得るのに用いることができる。
【００８１】
上述した解決策は、アドミッションコントロール技術の意図的に簡単化した例である。一般にアドミッション・コントロール技術は、パワー測定から導かれる情報の利用に加えて、例えばダウンリンク接続への負荷及び拡張コードの可用性を考慮するので、より洗練されている。
【００８２】
ＷＬＡＮネットワークへのアクセスに関し、特に有利な解決策は、ユーザーの数が増えるにつれてのシステムの性能低下を記述するものである。これは、アクティブユーザーの数の関数として８０２．１１規格の容量を導出することにより、一種のアドミッション・コントロールの基準を与えることを可能にする。上述したパラメータの処理から得られる図３（すなわちショート・インターフレーム・スペース、バックオフタイム、伝搬遅延、スロットタイム、最小及び最大コンテンション・ウインドウ）は、ユーザー数の関数として最大理論ビットレートの値（例えば８０２．１１ｂシステムの１１Ｍｂｉｔ／ｓに等しい）に対して標準化されたレート値を表す。
【００８３】
換言すれば、もしＷＬＡＮ上のアクティブユーザーが例えば３０であるならば、これらのユーザーは、（図３を参照して）合計約６．４５７Ｍｂｉｔ／ｓを利用でき、それからすべてのユーザー間に分割される。
【００８４】
したがって、全体として利用可能なビットレートが、すべてのユーザーによりリクエストされたサービスを提供するのに十分であるか否かを調べることができる。
【００８５】
実際的な例として（図２のフローチャートと図３を一緒に参照して）、１４４ｋｂｉｔ／ｓビットレートでも満たされ得る３８４ｋｂｉｔ／ｓでのストリーミングサービスのユーザーリクエストの場合を考える。
【００８６】
現在３２のユーザーがＷＬＡＮ上でアクティブである（よって図３を参照すれば利用可能なビットレートが６．３３４９Ｍｂｉｔ／ｓに等しい）ことを仮定すると、ＵＭＴＳセルの負荷は最大値０．７に近いとみなされる。したがって、システムは最大負荷条件に近い。
【００８７】
よって、図３のフローチャートによる進行は次の通りである。
【００８８】
会話型のサービスか？  いいえ。
ストリーミングサービスか？  はい。
この場合の問いは、ＷＬＡＮリソースが利用可能か否かである。
【００８９】
ＷＬＡＮ上で３２のユーザーが接続されている（利用可能な最大ビットレートが０．５７５９＊１１＝６．３３４９Ｍｂｉｔ／ｓ）こと、及びこのネットワーク上の負荷が６．０００Ｍｂｉｔ／ｓに等しいことを仮定する。上述したように、３３番目のユーザーは、１４４ｋｂｉｔ／ｓビットレートでも満たし得る３８４ｋｂｉｔ／ｓのストリーミングサービスを欲する。
【００９０】
実行される制御は以下の通りである。
【００９１】
利用可能な新しいビットレートは、０．５７０６＊１１＝６．２７６６Ｍｂｉｔ／ｓである。負荷値に新しいユーザーのリクエストのビットレートを加えると、６．０００＋０，３８４＝６．３８４Ｍｂｉｔ／ｓの値が得られ、これは可用性を越えている。
ＷＬＡＮリソースは利用可能か？  いいえ。
【００９２】
ＵＭＴＳセルは最大負荷の値に近いので、リクエストはＵＭＴＳによっても満たされない。
ＵＭＴＳリソースは利用可能か？  いいえ。
次の問いが提起される：
サービスを再交渉できるか？  はい。
【００９３】
今度は、１４４ｋｂｉｔ／ｓで試みられ、実行される制御により、（第２）リクエストのビットレートを負荷データに総計し、これにより、６．０００＋０．１４４＝６．１４４Ｍｂｉｔ／ｓの値が得られ、その結果可用性を越えている。
次に再び問う：
ＷＬＡＮリソースは利用可能か？
【００９４】
今回は問いに対して肯定の答え（Ｙｅｓ）を受ける。それからサービスが、変更された適当なデータ転送速度（すなわち最初にリクエストされたデータ転送速度と比べて小さい適当なデータ転送速度）でＷＬＡＮネットワーク上に割り当てられる。
【００９５】
ここに記載の決定過程すべてに影響を与えることなく、典型的な数値が利用される他方のＷＬＡＮシステムに対し、同様の基準が適用できる。
【００９６】
明らかに、本発明の原理を変えることなく、よって、本発明の範囲及び思想を逸脱することなく、ここに記載してきたことに関し実施の詳細及び実施形態を広く変えることができる。
【００９７】
特に少なくとも２、３の適用ケースでは、特許請求の範囲に記載の１以上のセット又はサブセットが実際に空のセットに対応することが分かるであろう。さらに、所与のシステムによるその可能な提供を考慮して所与のサービスに与えられた特徴的な「配達可能(deliverable)」（すなわち利用可能）又は「配達不可(not deliverable)」（すなわち利用不可）は、完全に物理的な意義にて考える必要はないが、合理的にはユーザーに許容可能な品質レベルの条件下で所与のサービスを提供する可能性を意味するのは自明である。
【図面の簡単な説明】
【００９８】
【図１】本発明による解決策の一般的な適用のシナリオを示す。
【図２】本発明による解決策の実施を説明するフローチャートである。
【図３】本発明のＷＬＡＮネットワーク又は類似のネットワークの負荷状態を評価するのに用いられる線図である。
【符号の説明】
【００９９】
ＡＰ    アクセスポイント
Ｂ      ノード
Ｔ      端末
１０    モジュール
【図１】
2005539444.tif 000003
【図２】
2005539444.tif 000004
【図３】
2005539444.tif 000005
【国際調査報告】
2005539444.tif 000006
2005539444.tif 000007
2005539444.tif 000008