JP4573440B2 - 無線アクセスベアラサービスを提供する方法及び装置 - Google Patents

Description

【０００１】
本発明は、コア網及び無線アクセス網を有する網において、それらの各網間の無線アクセスベアラ上で無線アクセスベアラサービスを提供するための方法及び装置に関する。それは、それぞれ異なるアプリケーションのリアルタイムサービスの送信に適している。
【０００２】
電気通信網管理事業者は、完全な電気通信サービスを提供することもできるし、ベアラサービスのみを提供することもできる。ベアラサービスは、通信をするための移送システムであり、これに対して電気通信サービスは、接続をするための機能と通信をするための規則をも包含したものである。
【０００３】
電気通信サービスは、（例えば音声のような）基本サービスであったり、（情報データベースのような）アプリケーションサービスであったり、あるいは、付加サービス（基本サービスに変更を加えたものもあり得る。）であったりする場合がある。電気通信サービスは、そのサービスが音声、データ、ビデオ及びマルチメディア等のどの形態で利用者に提供されるかに基づいて分類される。
【０００４】
網を介してこういったサービス全てを送信するには、透過性が必要である。良好な透過性は、網における接続構成要素を通過する際の遅延が最小になること、情報フローが変動しないこと、及び、送信に必要な回線容量が確保されていることを意味する。したがって、透過性に係わる３つの最重要パラメータは、回線容量、ビット誤り及び遅延である。音声、ビデオ及びデータに対する回線容量の必要条件は相互に異なる。例えばビデオ伝送は、最大遅延変動が認められているため、網に特別な必要条件を設定する。高品質なビデオ伝送のためには、遅延変動は小さくなくてはならず、時には数ミリ秒より大きくてはならないこともある。
【０００５】
回線モード及びパケットモードといった様々な転送モードが、様々なサービスの情報伝送に対して存在する。回線モードでは、情報は所定の長さの時間フレーム中で送信される。パケットモードでは、情報は、網を介した移送のためのアドレスヘッダが付いたパケットに分割される。送信された情報が網を通過する途中で転送モードを変更することが、ますます一般的になっている。将来的な目的は、回線容量及び転送モードに関係なく、同じ網で様々なサービス形態の通信をすることである。
【０００６】
網を介する通信は、プロトコルと呼ばれるある種の規約に従って実行される。ＴＣＰ／ＩＰは、世界中の様々なコンピュータ網をつなぐ世界的ネットワークであるインターネット上で使用される一連のパケットモードプロトコルである。ＩＰプロトコルの主要な役割りはアドレス指定である。ＴＣＰプロトコルは、例えば、ホスト間の順序制御及びフロー制御を処理する。
【０００７】
通信には、カップリング及びセッションの２つの段階がある。電話の呼においては、会話そのものがセッションであり、他の通信形態においては、利用者の間でデータが伝送されている間がセッション段階である。
【０００８】
電気通信網はアクセス網とコア網に分割される。ローカル局（local stations）間の接続がコア網を規定するのに対して、アクセス網は、加入者とローカル局を接続する部分である。
【０００９】
移動体電気通信システムには、サービスエリア内に規則的に配置された局部基地局がある。このようなエリアは、各セル毎に１つの基地局を有するセルに分割される。無線アクセス網内の移動局は、そのサービスエリアで地理的に最も近い局部基地局と通信する。固定コア網との通信は、このように無線アクセス網を介して行われる。
【００１０】
セルラーシステムは、今日、爆発的な増加の一途をたどっている。９０年代前半、無線利用者に向けての主要サービスは音声であった。音声はリアルタイムで、遅延の影響を受けやすいサービスであり、セルラー音声通信で用いられる技術は、多くの点で固定電気通信網から模倣されている。したがって、セルラーシステムは従来通り回線交換され、無線インターフェースを介する通信チャネルは専用チャネルとして定義される。
【００１１】
しかし、近年、他のサービス形態がセルラー業界で出現し始めた。これらは、無線通信の無線ベアラ上に、例えば遅延や回線容量に関して様々な必要条件を具備したデータサービスである。このようなサービスに共通の特徴は、そういったサービスでは、パケットデータ型の形態による伝送の使用を活用できることである。
【００１２】
実際に、その動向は、近年でのインターネットの爆発的な発展で固定電気通信網の側でも見られるようになった。音声も含む、様々なアプリケーションサービス（通信サービス）が実行されているパケットデータ型インフラストラクチャーの主要プラットホームはＴＣＰ／ＩＰスーツである。Ｅメール、インターネット閲覧及びビデオ会議は、まさしく、このような新しいアプリケーションサービスの例である。ＩＰは、パケットモードサービスであり、接続が保証されないことを意味する「最善努力型配送」（“best effort delivery”）を提供する。
【００１３】
異なるシステム間の通信サービスはアプリケーションを用いて使用できる。標準的なアプリケーションを使用することによって、それぞれ異なるシステムにおいてデータを単純な方法で置き換えることができる。そのアプリケーションは、メディアとして、ＴＣＰ（The Transmission Control Protocol)又はＵＤＰ（The User Datagram Protocol)を使用する。アプリケーションの例は、ＳＭＴＰ（Simple Mail Transfer protocol)、ＳＮＭＰ（Simple Network Management Protocol)、ＷＨＯＩＳ（カタログデータベース）、ＮＴＰ（Network Time Protocol)、ＨＴＴＰ（Hyper Text Transfer Protocol）及びＷＷＷ（情報データベース網)である。これらのアプリケーションは、様々なＲＦＣ（Request for Comments）勧告でより詳細に説明されていたり、実際のサービスプロバイダごとに特有のものだったりする。セッショントラフィックフローは、アプリケーションに応じて様々な長さとなる。将来、音声、写真、セキュリティなどの形態で更に多くのアプリケーションサービスが現れるだろう。
【００１４】
パケットデータ型サービスは、同じ通信チャネル上で複数の利用者を同時伝送し、回線交換網よりも（データ処理効率の点で）更に能率的に情報を伝送する機会を提供する。無線インターフェースの基本的な特徴は、１接続で様々な品質要件を具備した複数同時通信サービスを輸送できることである。
【００１５】
コア網と無線アクセス網との間のインターフェースを介して送信される様々なアプリケーションには、供給サービスによって異なった無線アクセスベアラが必要となる。パケットデータ型サービスに対しては、コア網と無線アクセス網との間のインターフェースを介する無線アクセスベアラサービス及びネゴシエーションプロトコルに特徴的な複数の特性（attributes（特性ないし属性））が存在する。アプリケーションの能力は、回線容量、サービス品質、最大ビットレート、最小ビットレートなどに関連する、ベアラサービスに対するこれらの特性によって決まる。
【００１６】
今、第３世代移動体通信システムの標準化が世界の主要地域にて急速に進行している。それらのシステムは、ＩＴＵ（国際電気通信連合）内ではＩＭＴ−２０００、ＥＴＳＩ（欧州電気通信標準化機構）内ではＵＭＴＳ（Universal Mobile Telecommunication system)と呼ばれ、例えば高速データ通信能力を持つＧＳＭのような現在の第２世代システムによって提供されているサービス範囲を広げるものとなるであろう。ＵＴＭＳ／ＩＭＴ−２０００の一般的なシステム構造には、利用者環境（User Equipment）、ＵＭＴＳ地球無線アクセス網（ＵＴＲＡＮ）及びコア網が含まれる。さらに、その一般的な構造には、ＵＴＲＡＮとコア網との間に存在するＩｕインターフェース、及びＵＴＲＡＮと利用者環境との間に存在するＵｕインターフェースの２つの一般的なインターフェースが含まれる。
【００１７】
ＵＭＴＳはまさに発展中で、無線アクセスベアラサービスネゴシエーションがどのようにＩｕインターフェース（無線アクセスベアラはこのＩｕインターフェースに基づいて与えられる）を介して実施されるべきかについてのコンセプトは完成していない。パケットデータ型セルラーソリューションの開発に対するコンセプトも、例えば、ＧＰＲＳ（一般パケット無線サービス）のような他のセルラー方式に必要である。
【００１８】
その網の無線アクセス網部は、必要に応じてコア網に無線アクセスベアラサービスを提供する。パケットデータトラフィックが、スペクトル効率の高い方法でコア網と無線アクセス網との間の無線インターフェースを通過していくことが望まれる場合、いくつかの問題点を考慮しなければならない。
【００１９】
コア網に提供される無線アクセスベアラサービスの使用に関連する問題点の１つは、任意のアプリケーションに対して必要な無線アクセスベアラを確立する方法である。
【００２０】
例えば、同時に異なるアプリケーションを実行するとき、ないし任意のアプリケーションがストリーム毎に異なったサービス品質を要求するとき、一人の移動体利用者に１つもしくは複数の無線アクセスベアラサービスが与えられる。従来の移動体利用方法では、例えば、ベアラに特徴的な特性に関する様々なアプリケーションニーズが考慮されない。したがって、例えば、ＵＭＴＳにおいて無線アクセスベアラサービス（ＲＡＢＳ）を提供するとき、必要な無線ベアラが大きすぎたり小さすぎたりする危険性が存在する。
【００２１】
いくつかのタイプのセルラー通信網では、利用者は、ベアラ（つまりサービスプロバイダ）に対して自分が必要とするサービスを１つもしくは複数の所要のサービス品質（ＱｏＳ）ベクタないし所要のサービスベクタＲＳＶという言葉で、明確にする。各ベクタは、所要のサービスに関連する複数のＱｏＳパラメータから構成される。代わりに、利用者の要求は、ベアラとともにネゴシエーションを実施するコンピュータ又はコンピュータアプリケーションに入力される。ＱｏＳパラメータは、以下に制限されないが、所要のビットレート（最大、平均、及び／又はその他のレート）、所要のビットエラーレート（ＢＥＲ）及び所要の伝送遅延を含む。加えて、利用者は望ましいサービスの料金パラメータを指定することもある。所定のアプリケーションに対して、各ＱｏＳパラメータ値の範囲は利用者に容認されている。例えば、ウェブ検索アプリケーションにおいて、利用者は、通常、更に高い料金を支払ってでも高速ビットレートを所望する。しかし、利用者が価格を最小限に抑えたい場合は、低速ビットレートで我慢する。アプリケーションの中には、利用者が受け入れるいくつかのＱｏｓパラメータ値の範囲がかなり狭いものもある。例えば音声データは低速ビットレート及び／または長い遅延に影響されやすいので、利用者は、音声アプリケーションにおいて、それ以上の低速ビットレートや長い遅延を容認しようとしない。低速ビットレート及び長い遅延などの許容条件を下回る場合、その通話は切断されるほうが望ましいのである。
【００２２】
利用者がサービスプロバイダに自分のサービス必要条件を提示できる方法の１つは、２つのＱｏＳベクタを明確にすることである。第２番目のＱｏＳベクタにおけるＱｏＳパラメータ値は、許容できる（又は最低水準の）サービスを表す。通常、望ましいＱｏＳパラメータ値は、上述で提案したように、利用者に代わってより低い価格・レベルに対する敏感度を示す[t2]。対照的に、許容できるＱｏＳパラメータ値は、より高い価格に対する敏感度と関連する。[t3]音声の場合において、いくつかのＱｏＳパラメータ（例えば最大伝送遅延）の希望値と許容値が同一であることもある。そのことは、それらのＱｏＳパラメータに対して希望値以下は許容したくないという利用者側の不本意を示している。希望サービス、最低許容サービスおよびその中間のサービスを定義することもできる。
【００２３】
通話のセットアップ、ハンドオーバー及び通話再ネゴシエーション時に、接続確立に使用されるべきサービスが決定されなければならない。利用者の要求及びベアラ能力が考慮される必要がある。ベアラ能力は、ＱｏＳベクタの形式でも表されることができ、所定のサービスベクタＯＳＶと呼ばれることもある。ＯＳＶを発生させる手続きはベアラサービスジェネレーションと呼ばれる。利用者の要望をベアラ能力と整合させる手続きは、ベアラサービスネゴシエーションと呼ばれる。ベアラサービスネゴシエーションの手続きによって、ネゴシエートされたＱｏＳベクタ又はＮＳＶが生成される。一般的に、ＮＳＶの中には、サービスプロバイダによって提供され、ＲＳＶにおいて利用者が指定する値の要望を満足させるサービスを反映するＱｏＳパラメータ値に入っている。利用者の要求とベアラ能力との釣り合いが全く取れていない場合、そのＮＳＶには何もないということになる。
【００２４】
サービスプロバイダは、ＮＳＶで定められたサービス品質を常に保証できるとは限らない。そのサービス品質というものは、単にサービスプロバイダが達成しようとしていることにすぎない。しかし、ベアラサービスネゴシエーションと例えば通話セットアップとの間にかかる時間で、データトラフィック変動やフェージングといった現象が原因で条件は変化し、それによって、サービスプロバイダがＮＳＶによって規定されたサービス水準を実現することは不可能となる。サービスプロバイダが少なくとも最低限の要望を達成できなければ、ベアラサービスは再ネゴシエートされる必要がある、または通話が続いている場合は、ハンドオーバーされる（つまり他のサービスプロバイダに変更される）か切断される必要がある。
【００２５】
セルラーネットワークに付加されているデータサービスで、無線システム工学は、それぞれ異なった品質要求を持つ様々なサービスの接続を適応させなければならない課題に直面している。（ＧＳＭ、ＴＤＭＡ／１３６などのような）第２世代システムのＷＣＤＭＡ及び無線ＬＡＮにおける、無線アクセスを使用する複数の異なるアプリケーションの混成において、組織化された処理が欠如していると、方式性能が低下し、ネットワーク管理事業者に更なる問題が生まれる。
【００２６】
フルレート音声及びハーフレート音声が、現在、民間のＧＳＭ方式で利用可能で、回線交換データはまもなく多重スロット伝送にまで拡張するであろう。これらの混成サービスの（サービスの利用を制御する）受け入れ制御受け入れ制御は、可能ではあるが、サービス定型がほとんどないので未発達である。さらに、フルレート音声をロードする以外にサービスのロードがある。混成サービス無線方式に取り組む試みでは、無線リソースを、所定のアクセス制御にしたがって、音声などの遅延評価サービス及びデータなどの無遅延評価サービスに割り当てる課題に焦点が置かれてきた。
【００２７】
混成サービスの取り扱いに関する現状の解決法にはいくつかの問題点がある。これらの課題は、複雑に絡み合ったサービスを支援するシステムでは困難の原因となる全体構造がないまま、各サービスごとに取り扱われている。
【００２８】
受け入れ制御受け入れ制御に関して、サービス区別及び利用者区別は広く普及していない。つまり、あるユーザは利用できるのに、別のユーザは利用できないリソースがあったりする。
【００２９】
適応的アプリケーション、つまり、複数の操作モードを有するアプリケーションもまたあまり普及していない。例えば、ビデオコーデックは、複数のビットレートモードで操作できる。これらのモードは、有効な回線容量に対応するので、回線容量ネゴシエーションは、少なくとも接続セットアップ時に実行される必要がある。
【００３０】
ウェブ検索のような、多様なベアラを使用した単一モードで操作可能な（そして、対応する多様な通信品質を利用者に提供可能な）順応的アプリケーションも広く取り扱われていない。
【００３１】
ＮＯＫＩＡ ＴＥＬＥＣＯＭＵＮＩＣＡＴＩＯＮＳ ＯＹによる国際特許出願ＷＯ ９９／０１９９１において、ＴＣＰ／ＩＰサービスを提供する電気通信網に接続されたセルラー無線アクセス網でＴＣＰ／ＩＰサービスをサポートするための方法及び準備が紹介されている。この明細書に紹介されている解決法によれば、異なるＴＣＰ／ＩＰサービスによって要求されるベアラサービスパラメータは、無線アクセス網において予め決定され、所定の接続のための適切なパラメータは、第１番目の受信ＩＰパケットの内容を基にＴＣＰ／ＩＰサービスを識別することによって選択される。したがって、異なるＴＣＰ／ＩＰサービスは、異なる方法で無線アクセス網にて取り扱われ、実際のニーズに最もうまく一致するベアラサービスは、局部データベースを用いて無線アクセス網を介して確立される。
【００３２】
しかし、ＩＰパケットが送信開始時から最適の無線アクセスベアラ上で送信されるように、無線アクセスベアラサービスをより速く柔軟に提供する方法が必要である。
【００３３】
同様に必要なのは、順応的アプリケーションを扱うだけでなく、複数の操作モードを有するアプリケーションを収容するのに適応的な混成サービスも扱う解決法である。
【００３４】
無線アクセス網の時間変動特性が問題なので、状況によってはセッション中に無線アクセスベアラを変更することも可能であるべきである。無線アクセス網は、例えば、トラフィックロード又はリンクバジェットにおける変更によって、個人利用者又は団体利用者の所定の回線容量を削減（又は増加）する。
【００３５】
本発明の目的は、上述した問題点の１つもしくは複数を解決する網において無線アクセスベアラサービスを提供するための方法と装置である。
【００３６】
したがって、本発明の目的の１つは、任意のアプリケーションに必要とされる最良の無線アクセスベアラをさらに高速に確立するための方法と装置を完成させることである。
【００３７】
本発明の第２番目の目的は、適切な無線アクセスベアラ上でデータストリームを位置付けるための方法と装置を完成させることである。
【００３８】
本発明の第３番目の目的は、無線網の変動特性を考慮するための方法と装置を完成させることである。
【００３９】
【発明の要旨】
コア網と無線アクセス網から成る網で、その２つの網の間にある無線アクセスベアラを介して、異なるアプリケーションの無線アクセスベアラサービスを提供するための本発明の方法は、主に、１つもしくは複数のセッショントラフィックフローがアプリケーションによって送信されていることを識別する過程を特徴とし、１つもしくは複数の無線アクセスベアラを決定するのに必要なパラメータ形式でその識別されたセッションを特徴づけ、その特徴づけされたパラメータを無線アクセスベアラ特性に変換し、前記特性によって定められた１つもしくは複数の無線アクセスベアラを要求、確立し、前記要求に基づいて確立された適切な無線アクセスベアラ上に各セッションを位置付け、セッションの終了を示し、必要がなくなり次第その無線アクセスベアラを解放する。
【００４０】
コア網と無線アクセス網から成る網において、異なるアプリケーションの無線アクセスベアラサービスを行う本発明の装置は、前記コア網と無線アクセス網との間の網に導入された無線アクセスベアラ管理ノードである。それは主に、本発明の方法の各段階を実行するための手段を特徴とする。
【００４１】
結論として、本発明は、ＵＴＭＳ又はパケットデータトラフィック計算の無線アクセスベアラサービスネゴシエーション処理を行う同様の網において、例えばコア網側に機能構成要素を提供できる。セッションフローを識別して特徴づけるパケットストリームの実際のセッションフローの識別／情報は、必要な無線アクセスベアラ数を決定するために使用され、値を無線アクセスベアラ特性に割り当てる。その方法には、確立された無線アクセスベアラ上に利用者データのセッションフローを位置付ける方法も含まれる。
【００４２】
例えば、適切なベアラ上で適切なトラフィックを位置付けるために、ビデオ、音声及び信号などの同一ソースから異なるストリームを引き出す手段として、非多重化が使用されなければならない場合もある。
【００４３】
そのセッショントラフィックは、そのセッションを認識し、特徴づける別の方法と同一視されてきた。第１番目の実施例において、そのセッションは、セッションのパケットのパケットヘッダによって特徴づけられる。第２番目の実施例において、そのセッションは、その接続に対する論理リンクの生成と関連するエンド・ツー・エンド型信号メッセージを用い認識され、特徴づけられる。第３番目の実施例において、そのセッションは、本発明装置への直接信号メッセージを用いることによって認識され、特徴づけられる。
【００４４】
無線アクセスベアラ特性は、サービス品質及び回線容量要求から構成される。それらの品質及び要求は、順に論理静止型変換データベース、遠隔型変換データベース、ユーザプロファイル及び／又はベアラ管理からの負荷指示計に基づいている。
【００４５】
本発明の１つの実施例において、セッションの進行中、変更は認識され、その結果、無線アクセスベアラ特性は変更される。アプリケーションのニーズの変更を認識するために、上述されたセッションフローを開始する方法のいずれかの組合せによってそのセッションが周期的に調査されるように、その変更は認識される。好ましい１つの実施例において、背圧メカニズムは、例えば、急により多くのスペクトルが利用可能になるなど、無線インターフェース上の状況が変化する場合、もしくは無線悪条件または輻輳（ふくそう）によって状況が悪化する場合に備えて、そのアプリケーションに戻るために使用される。本発明は、既に確立された無線アクセスベアラ上のトラフィックを監視するために使用され、可能な限り無線アクセスベアラサービス（ＲＡＢＳ）再ネゴシエーションを介してベアラ特性を調整するために使用されることができる。
【００４６】
セッションの継続中に無線アクセスベアラ特性に加えられる変更は、多くの異なる再ネゴシエーションシーケンスを通じて実行可能である。このことは、本明細書にて後に説明される。
【００４７】
このように、本発明において、その無線アクセスベアラは、無線アクセスベアラサービス特性を使用するサービスネゴシエーションを基に、コア網と無線アクセス網との間の境界に提供される。これらの特性が無線アクセスベアラサービスを特徴付け、その目的は、適切なサービス品質を持つベアラを提供することのみならず、無線リソース管理の能率的なアルゴリズムを可能にすることでもある。後者の一例は、できるだけ多くの移動体利用者に無線アクセスを提供することによって、的確なアプリケーションニーズについての情報を利用することができる受け入れ制御受け入れ制御アルゴリズムである。
【００４８】
本発明の装置及び方法によって、網通信レベルにおいて、つまりＩＰネットワークプロトコルの使用時には確実な接続が存在しないパケットデータ型セルラー方式の無線アクセスネゴシエーションを実行できる。提案されたコア網側での論理ノードの導入、又はサービス品質の観点でアプリケーションニーズを認識する方法と共に、無線アクセス網側での論理ノードの導入によって、能率的な無線アクセスベアラサービス（ＲＡＢＳ）ネゴシエーションの手段が提供される。結果的に、適切なＲＡＢＳを提供することによって、乏しい無線リソースのスペクトルの能率的な利用のための受け入れ制御受け入れ制御アルゴリズムを開発することが更に容易になる。さらに、前記ノードの組合せとトラフィック認識方法の利用によって、適切な無線アクセスベアラ上に入力パケットデータトラフィックを位置付けることが可能となる。
【００４９】
本発明のいくつかの実施例が、図とフローチャートを用いて以下に記述される。本発明は請求項の範囲内で変更可能であり、以下に示される詳細に制限されるものではない。
【００５０】
【詳細な説明】
例えば、音声、ビデオ、データなどのようなアプリケーションサービスのパケットデータから構成される送信トラフィックフローは、参照番号１が付された図１において示されるように、本発明の様々な実施例において様々な方法で開始することができる。そのセッションの認識及び特徴づけの方法は、セッショントラフィックフローを開始するために使用される方法によって決まる。これらのうち、３つの方法を以下に示す。
【００５１】
第１番目の方法において、セッショントラフィックは、固定最善努力型チャネル("Parmanent best effort channel")を介してアプリケーションから送信される。ここで言う固定最善努力型チャネルは、デフォルトの無線アクセスベアラが想定されていることを意味する。このようなベアラは既に確立されているが、実際のアプリケーションには最適化されていない。この方法では、そのセッションはセッションパケットのパケットヘッダを用いて識別され、特徴づけられる。任意の無線アクセスベアラ上に位置付けられるべきトラフィックは、ＩＰデータパケットのように入力トラフィック間で認識される。適切なベアラ上でトラフィックを位置付けるためにパケットごとのトラフィックを特徴付けるには、例えば、音声、ビデオ及び信号などの同じソースからの様々なストリームが引き出されなければならない。網を介して送信される各パケットには、パケットが適切な受信者にたどり着けるように、メッセージそのものに加えてアドレス情報などの他の情報も入っている。メッセージ自体は、アドレス及び他の情報が入っている、いわゆる「ヘッダ」に収容される。他の情報は、例えば、サービス形態、パケット長、識別データなどである。サービス形態には、許容される遅延、ビットレートなどについての情報も含まれる。さらに、そのセッションは、トラフィック状況及び無線リソースに関する情報のような、ヘッダに含まれる付加情報及び測定値によって識別され得る。セッションを特徴付けるこれらの全情報は、「セッションパラメータ」という形式で公式化される。この明細書では、セッションは前記パラメータによって特徴付けられるべきであるということである。
【００５２】
前記３つの方法のうち第２番目の方法において、そのセッショントラフィックは、Ｈ３．２３のような標準 信号／セッション 開始プロトコルの後に続いてくる。この方法における第１ステップは、実際の接続に備えてエンドユーザとアプリケーションとの間に論理リンクを確立するために、最善努力型チャネルを使用して、信号をアプリケーションからエンドユーザに送信し、これらの信号が、送信されるアプリケーションサービスに関する情報を含むようにすることである。その情報は上述の第１番目の方法にあるパラメータと同じパラメータの形式となるはずである。データパケットが論理リンクにおけるチャネルと同じチャネルを介して送信される実施例と、信号が専有チャネルを通過する実施例の両方が本発明にて扱われる。この方法では、コア網と無線アクセス網との間に導入された無線アクセスベアラ管理ノードを経由するエンド・ツー・エンド型セッション信号メッセージを傍受し翻訳することによって、セッションが識別、特徴づけられる。したがって、この場合、適切なベアラはエンド・ツー・エンド型メッセージ中に含まれる、アプリケーションサービスに関する情報によって、定義される。
【００５３】
第３番目の方法において、そのセッショントラフィックは、本発明による方法で、正当な無線アクセスベアラサービスの確立を実施するためにコア網と無線アクセス網との間に導入された無線アクセスベアラ管理ノードへ直接信号を介して導かれる。この方法では、セッションは、アプリケーションから前記ノードへ信号メッセージを翻訳することによって識別されて特徴づけられる。コア網側にあるアプリケーションは、無線リソースを全く使用せずに、直接信号を介して、同じくコア網側にある前記ノードへのセッションを確立する。そのノードは、所要のパラメータを識別した後に、信号を終了させる。この場合、接続に備えて論理リンクは確立されない。その代わりに、上述のパラメータと同じパラメータの形式でアプリケーションに関する情報が、そのアプリケーションから前記ノードに直接送信された信号メッセージに含まれる。したがって、この場合、適切なベアラは、網内のアプリケーションから前記ノードへのこれらのメッセージ中に含まれる、アプリケーションサービスに関する情報によって定義される。
【００５４】
これら３つの方法のうちのいくつか、又は図１のステップ１と２で示されたようないくつかの組合わせに従って、セッションが認識され、特徴づけられた後、それに相当するサービス品質及び回線容量要求が、前記特徴付け、つまり「セッションパラメータ」形式で表される特徴付けによって公式化される。前記パラメータは、品質と回線容量要求の公式化に使用される。つまり、引き出された情報は図１の参照番号３で示されたように、現存するＲＡＢＳを定義する、無線アクセスベアラ特性ＲＡＢＳに変換される。以下のパラメータが周知のものである場合、これらの特性は局部静止型変換データベース（ユーザ独立、ロード独立）、遠隔変換データベース、ユーザ・プロファイル、ないしベアラ管理からの局部指示器を用いて決定できる。
【００５５】
無線アクセスベアラは図１のステップ４で無線アクセス網からの要求に基づいて確立される。確立された無線アクセスベアラ上でのセッショントラフィックフローの位置付けが図１のステップ５で実行される。パケットフローでの複数のセッションの場合、適正な無線アクセスベアラ（ＲＡＢ）上で正当なセッションフローの位置付けをする課題は各パケットベースで処理されなければならない。つまり、各パケットがセッションごとに識別され、各ＲＡＢ上に位置付けられる必要がある。どのＲＡＢを使用すべきかを決定するのは、サービス品質及び回線容量要求（つまり、ＲＡＢＳ特性）である。複数のセッションが同じＲＡＢ上に位置付けできることもあるが、これはできればの話であり、関連する同一のＲＡＢＳ特性を有する場合である。
【００５６】
本発明の好ましい実施例において、変換されるべき特性は、セッションの送信開始と関連してステップ２で特徴づけられたパラメータに加えて、セッションの継続中に加えられた変更を基準とすることもできる。
【００５７】
セッション中に、急により多くのスペクトルが利用可能になる、もしくは無線悪条件または輻輳（ふくそう）により状況が悪化するなど、無線アクセス網の状況が変化したことについての情報を搬送する無線アクセス網（ＲＡＮ）から、メッセージが受信されることもある。ステップ７にしたがって、無線アクセス網からそういったメッセージが届いた場合、ＲＡＮからのメッセージは、ステップ８で本発明の無線アクセスベアラ管理ノードによってアプリケーションが理解できるメッセージに変換され、ステップ９でアプリケーションに送信される。アプリケーションは、図１のステップ１で示されたような前記第１番目の方法にしたがって送信を始め、又はパケットヘッダ内にその情報を取り入れ、第２番目又は第３番目の方法にしたがってセッション開始信号メッセージ内のこのメッセージに含まれる変更に関する情報を使用する。こうして、アプリケーションは、そのトラフィックを現在のチャネル特性に適応させることができる（例えば、低品質であるが、回線低容量の別の音声符号器を使用するなど）。しかし、特性を変更するために、これらの変更を実行するアプリケーションを待ち受けする必要はない。本発明の、変更についてアプリケーションに通知する管理ノードによって、図１のステップ７からステップ３に進む矢印で示されるように、特性を直接変更することが可能である。
【００５８】
情報に対する変更（つまり、そのパラメータの変更）が、セッションの調査結果としてステップ６にしたがって認識された場合、その新しい情報は、本発明のステップ１０で示されるように、まず分析される。もし、情報の変更がそのセッションに対する新しい特性（つまりパラメータ）が存在することを意味する場合、その新しい特性はステップ３でＲＡＢ特性に変換され、前にステップ４−５で実行されたように、新しいＲＡＢＳがネゴシエート（つまり再ネゴシエート）され、使用される。もし、新しい情報がセッションの終了が始まったときに入ってきて、既にＲＡＢＳを開放する段階であるなら、無線アクセスベアラサービスはステップ１１で開放される。
【００５９】
図２には、ノードＤ形式で本発明の装置の実用的なモデル例が示されている。それは、図２において、Ｉｕインターフェース１６のコア網側１９で、コア網１９と無線アクセス網１８との間に導入される。ノードＤは、本発明の方法にしたがって無線アクセスベアラを確立、維持及び開放し、正当な無線アクセスベアラ上にユーザトラフィックを位置付ける。
【００６０】
図２において、ノードＤは３つの構成要素から成る。分級器１３は矢印１’で示されるように、アプリケーション１７から送信されたセッションフローを認識する（図１のステップ１）。分級器１３は、任意の無線アクセス網−コア網間インターフェースの静的パラメータのような任意情報を引き出すようにプログラムされている（図１のステップ２）。同様に分級器１３において、これらのパラメータがＲＡＢＳ特性に変換される（図１のステップ３）。セッション分級器１３は双方向矢印６’にしたがって周期的にセッションの検査も行うので、トラフィック情報の変更を識別できる（図１のステップ６）。分級器１３は、トラフィック情報の変更がある場合及びセッションの終了が示される場合、新しいパラメータの特徴づけに対して責任をもつ（図１のステップ３）。このように、分級器は、分級器１３においても行われる（図１のステップ３）正当なＲＡＢＳの決定のため、ないしＲＡＢＳの開放（図１のステップ１１）のために必要な情報を生み出すノードＤ内のユニットである。
【００６１】
ＱｏＳ及び回線容量（つまりＲＡＢＳ特性）要求はベアラマネージャユニット１４に送信される。無線アクセスベアラサービスマネージャ１４は、無線アクセスベアラサービスを確立／ネゴシエートするために分級器１３から受信される入力として、前記特性を有する。ネゴシエーションは、双方向矢印４’にしたがって、ＲＡＮとＲＡＢＳマネージャとの間で行われる。分級器からの情報がセッションの終了を示したとき、ベアラマネージャユニット１４はＲＡＢＳを開放する。
【００６２】
無線アクセスベアラマネージャ１４は、矢印７’による無線アクセス網からの潜在的メッセージの「トランシーバー」でもある（図１のステップ７）。これらのメッセージは、例えば、急激な有効スペクトル増加又は悪無線条件や輻輳による悪化条件などの、無線アクセス網状況の変化に関する情報を搬送する。無線アクセス網からそういったメッセージが届いた場合、無線アクセスベアラマネージャは、このメッセージをアプリケーションの認識可能なメッセージに翻訳し、矢印９’にしたがって、それをアプリケーションに送信する。無線アクセス網状況の変化に関する情報は、ベアラマネージャ１４で特性を直接変更し、その後、新しいＲＡＢＳのためにネゴシエートするために、ＲＡＢＳマネージャにおいても処理されることが好ましい。
【００６３】
矢印５’、５’’及び５’’’によって示されるように、正当なＲＡＢ上でのユーザトラフィックの位置付けは、第３番目のユニット１５にて実行される。
【００６４】
セッションの送信を開始するための方法は、ここまでで３つ説明された。同じように、セッションの特性を変更し、新しいＲＡＢＳを再ネゴシエートする方法も複数ある。これらの別の方法は図１及び２を用いて以下に示される。
【００６５】
本発明の１つの実施例によれば、アプリケーションは継続中のセッションの特性を変更する。セッション分級器１３は、矢印６’で示したように、周期的にセッションを検査する結果、その変更を認識する。次に、セッション分級器１３は図１のステップ２で前回のようにフローを「再分析」して、図１のステップ３に示したように、新しいパラメータを基に新しいＱｏＳと回線容量の需要量（新規特性）を決定する。その後、セッション分級器は、再ネゴシエーション要求をベアラマネージャ１４に送信する。そのベアラマネージャ１４は、図１のステップ４のように新しいＲＡＢＳを確立するために、矢印４’で示されたように、再ネゴシエーションプロトコルを処理する。
【００６６】
本発明の別の実施例によれば、アプリケーションは、セッション特性における変更を信号で伝えるためにエンド・ツー・エンド型信号メッセージを送信する。セッション分級器１３はセッション信号メッセージを受けて図１のステップ２及び３を実行する。その後、セッション分級器１３は、ベアラマネージャ１４に再ネゴシエーション要求を送信する。ベアラマネージャ１４は矢印４’で示されたように、新しいＲＡＢＳを確立するために再ネゴシエーションプロトコルを処理する。その後、アプリケーションは、新しいセッション特性の使用に切り替わる。
【００６７】
本発明のまた別の実施例によれば、アプリケーションは、セッション特性の変更を信号で伝えるエンド・ツー・エンド型信号メッセージを送信する。セッション分級器１３はセッション信号メッセージを受信し、図１のステップ２及び３を実行する。その後、セッション分級器１３は、再ネゴシエーション要求をベアラマネージャ１４に送信する。そのベアラマネージャ１４は矢印４’で示されたように、新しいＲＡＢＳを確立するために最ネゴシエーションプロトコルを処理する。その後、アプリケーションは新しいセッション特性の使用に切り替わる。
【００６８】
本発明の装置の様々な構成要素によって実施される機能は、本発明とは異なる方法で準備されることも可能であり、以下の実施例で記述されるように、他の機能があってもよい。
【００６９】
本発明の別の実施例によれば、無線方式における混成サービスを行い、図１及び２で部分的にＲＡＢＳマネージャの機能を有する受け入れ制御受け入れ制御機能が示されている。その受け入れ制御機能は、複数の機能ブロックから構成される構造の一部である。図３を参照すると、３つの機能ブロックから成るサービス処理制御方式１００が説明されている。その機能ブロックは、アプリケーションインタプリタ（Ａ１）１２０、受け入れ制御要素１３０及び無線リソースマネージャ（ＲＲＭ）１４０である。
【００７０】
（例えば、図１及び２におけるセッション分級器及びＲＡＢＳマネージャと部分的に一致する機能を有する）アプリケーションインタプリタ１２０は、アプリケーションからの接続要求１１０によって稼動する（図１のステップ１）。ユーザ固有情報及びアプリケーションニーズに関する他の情報と同様に、この要求を基にして、アプリケーションインタプリタ１２０は、ベアラ要求（又は要求されたサービスベクタＲＳＶ）を発生する。ユーザ固有情報は、例えば無線サブスクリプションデータベース１５０に格納される。アプリケーションニーズに関する情報は、例えば、アプリケーションセットアップ信号を監視することによって検索される。（アプリケーションからの）この要求は、望ましいベアラ特性、つまり、無線方式を介したトラフィックの搬送に望ましい接続を説明するものである。情報の種類又はベアラ特性に含まれるものは、（１）遅延、フレーム誤り率（ＦＥＲ）及びビットエラー率（ＢＥＲ）などの送信データに対する品質要求（２）単位時間当たりにアプリケーションから期待できるデータ量などのソース情報（３）ベアラは単一方向性又は双方向性であるべきか否か、又は誤ったフレームは網内で上位レイヤに送られるべきか否かといった、一般ベアラ及びプロトコル情報、及び（４）ベアラ要求の重要性の分類に使用され、よって要求する側がそのベアラに対して支払う意思のある金額として確認される優先情報、である。ベアラオファー（ＯＳＶ）で使用されるとき、優先事項は所定のベアラのコストとして解釈されるべきである。その優先事項は利用者申し込みの際に[t5]利用者によって直接指定される。
【００７１】
アプリケーション要求は、少なくとも１つの所要の選択ベアラ（ＲＳＶ）となる。アプリケーションインタプリタ１２０は、ネゴシエートされたベアラ（又は、ネゴシエートされたサービスベクタＮＳＶ）を受信することやネゴシエートされたベアラ（ＮＳＶ）をアプリケーションが認識できるメッセージに翻訳することも可能である。
【００７２】
図１及び２の、位置付けユニットに対応する機能を有する無線リソースマネージャ１４０は、各能動接続のためにネゴシエートされたベアラ（ＮＳＶ）を受信する。図３の無線リソースマネージャの役割は、アプリケーションによって識別ないし要求された所定のベアラ品質特性を維持するために電力及びチャネルといった無線リソースを最大限に有用することである。無線リソースマネージャ１４０の機能を実行する際のアルゴリズムは、例えば、ハンドオフ、電力制御、符号割り当て及び変調選択、チャネル符号化、及びＣＤＭＡ方式における拡散要素を含んでいる。ネゴシエートされたベアラの全パラメータ（ＮＳＶ）を維持できない場合、無線リソースマネージャ１４０は、少なくとも１つのベアラの再ネゴシエーションを命令する。
【００７３】
図３の受け入れ制御要素１３０は、図４で２３０として表示されており、図１及び２のＲＡＢＳマネージャに対応する機能の一部を有する。本発明の典型的な実施例によれば、受け入れ制御機能２３０は、所定のベアラ発生器２４０及びベアラ整合機能２５０を含む。アプリケーションからの最初の要求を基に発生されたベアラ要求２１０（ＲＳＶ）は、受け入れ制御２３０によって受信される。ベアラ要求は、１つ以上のＲＳＶもしくは代替ＲＳＶから成る。代替ＲＳＶは、複数の別個の特性値の集合、もしくは少なくとも１つの特性がこのベアラ要求に応じた値の範囲を有する、特性の集合体によって説明されるものである。
【００７４】
所定のベアラ発生器２４０は、例えば、要求を出している移動局に提供されるベアラ（ＯＳＶ）２６０を発生させる。この所定のベアラ２６０は、ベアラの優先事項（又はコスト）を含んでいる。所定のベアラ（ＯＳＶ）２６０は上述したように、所要のソース及び品質ベアラ特性に基づいて発生する。さらに、所定のベアラ２６０は、問題のセルとそのセルと抵触するセルにおける現在の負荷及び干渉レベルと、及び移動局の上り線及び下り線信号品質のような移動局の固有情報に基づいている。例えば、高い負荷がかかったセルにおいて、要求されたベアラ（ＲＳＶ）の品質が低い場合、無線リソースにかかるコストは低くなる。同様に、移動局が良好な（つまり長期間の）信号品質の保持を認めても、コストは低くなる。
【００７５】
ベアラ整合機能２５０は、所要のベアラ（ＲＳＶ）２１０及び所定のベアラ（ＯＳＶ）２６０を受信し、所要のベアラ２１０と所定のベアラ２６０を整合させようとする。整合の過程において、所要のベアラ（ＲＳＶ）２１０で指定された（品質、優先事項などに関する）期間及び条件を満たす所定のベアラ（ＯＳＶ）２６０が存在するか否かに関して決定がなされる。そのベアラの優先事項部分は区別化に使用される。例えば、所定のベアラの優先事項が高いと示された場合、そのベアラは重要な要求（つまり優先度の高いＲＳＶを持つ要求）とだけ適合できる。整合の過程を終えた出力がネゴシエートされたベアラ（ＮＳＶ）２７０である。もし適合性が見出されなければ、アプリケーション要求は否定される。つまり、ベアラ要求２１０を満たす所定のベアラ発生器２４０が、所定のベアラ（ＯＳＶ）２６０を発生しないので、ベアラ要求（ＮＳＶ）２１０を出した利用者は受け入れられない。
【００７６】
上述のように、ベアラ発生器２４０及びベアラ整合機能２５０の条件を共に満たす所定のベアラ発生器２４０は、接続要求を受信し、その要求を実行する方法を決定する受け入れ制御機能２００を形成するものとして理解される。しかし、本発明の受け入れ制御機能２００は、周知の受け入れ制御のように要求を受信し、「はい」又は「いいえ」で応答するのではなく、受け入れ制御同じアプリケーションから複数の要求を受信でき、その要求を満たす最適な所定ベアラを選択できる。少なくとも１つのパラメータ値が複数のＲＳＶ間で異なるアプリケーションによって、複数のＲＳＶが発生される。一例として、ＲＳＶ_１において、遅延が１秒とし、ＲＳＶ_２において、０．５秒と仮定する。択一的に、多重要求の指定形式として、１つもしくは複数のパラメータが指定値範囲を持つ１つのＲＳＶが生成される。例えば、１つのＲＳＶ内で、ＦＥＲは１つの値として指定されるが、遅延は０．５秒から１秒といったように、２値間の範囲として指定される。別の例として、ビットレートは例えば３２から６４ｋｂｐｓのような範囲で指定される。このことは、これら２値間のビットレートならどの値でもアプリケーションに受け入れられることを示している。ＯＳＶも同様の方法で発生する。既述したように、受け入れ制御機能２００は、様々な方法で、様々な利用者及びサービスを取り扱うことができるのである。
【００７７】
サービス又はベアラベクタの提供（ＯＳＶ）及びサービス又はベアラベクタのネゴシエーション（ＮＳＶ）は、本発明の好ましい実施例によれば、連続的ないし同時に起こる。図５（ａ）に示されたような第１番目の実施例によれば、ＯＳＶの発生及びＲＳＶを獲得するのためのネゴシエーションは、１つの共同受け入れ制御ステップ３０５において実施される。図５（ｂ）に示されたような第２番目の実施例において、ＯＳＶの発生はステップ３１５[t6]で起こり、ＲＳＶを獲得するネゴシエーションはステップ３１７で起こる。第２番目の実施例によれば、（ステップ３１１で）少なくとも１つのＲＳＶに対して、（ステップ３１３で）システム情報を集めた後に、ステップ３１５において複数ベアラ（又はＯＳＶ）が提供され、その次にステップ３１７においてＮＳＶのネゴシエーションが行われる。３１５及び３１７のこれら２つのステップは連続して起こる。
【００７８】
複数の要求を処理する周知の受け入れ制御を利用した方法の１つは、連続操作を行うことである。つまり、最初に所望のベアラが要求されて、その所望のベアラが受け入れられない場合、許可が下りるまで別のベアラが要求される。しかし、この解決法は多量の付加信号を生じさせる。結果的に、すべての選択肢は受け入れ制御機能が実施されるのと同時及び以前に知られているものとして、受け入れ制御による決定は通知されない。
【００７９】
ネゴシエートされたベアラ品質が非許容レベルまで低下する場合、図４の２８０で示される新しいベアラは再ネゴシエートされる必要がある。本発明の典型的な実施例によれば、図６で示されたように、汎用移動通信システム（ＵＭＴＳ）におけるマルチモードアプリケーションが公示されている。ＵＭＴＳ方式において、ＵＭＴＳの様々な伝送部を担当する複数のベアラから成るベアラ構造４００が定義されている。図６において、ＵＭＴＳベアラ４４０のようなベアラサービスは、コア網ＩＵエッジノード（ＣＮ）４２０と移動終端ノード(mobile termination node)（ＭＴ）４３０との間で定義される。これらの２つのノード間の伝送は、複数のＱｏＳ特性を有するサービスを具備した２つのノード間の一部を形成する。
【００８０】
その特性は開始又は伝送前にネゴシエートされるので、結局はネゴシエートされたサービスベクタ部，ＮＳＶ部である。所定のベアラサービスの１つは、コア網ＩＵエッジノード４２０と移動終端ノード（ＭＴ）４３０との間を移送する無線アクセスベアラ（ＲＡＢ）４１０である。図６でわかるように、所定のベアラサービスはつまり、ＵＭＴＳのもとにベアラサービスをセットアップするために階層構造を形成する。ＲＡＢは、ネゴシエーションがあらゆるベアラサービスレベルにおいて行われるときのためにのみ表示されている。
【００８１】
コア網はゲートウェイとＩＵエッジノードを具備する。ＧＳＭ方式では、対応するノードは、ＧＭＳＣとＭＳＣである。ＧＰＲＳ方式に対しては、対応するノードは、ＧＧＳＮとＳＧＳＮである。利用者環境は、論理的に端末装置（ＴＥ）と移動終端（ＭＴ）とに分類される。ＴＥ部はＵＭＴＳ固有の高層プロトコルレイヤを含む。結果的に、利用者環境のＴＥ部は、ＵＭＴＳを認識しておらず、ＭＴ部はどのアプリケーションが使用されているかを認識していない。
【００８２】
上述したように、アプリケーションは様々な品質モードで運用している。例えば、ビデオコーデックは通常品質モードと高品質モードを有する。高品質モードにおいては、アプリケーションは通常モードより速いデータ速度を生み出す。これらは６４ｋｂｐｓ及び１２８ｋｂｐｓの保証ビットレートを具備した異なる品質モードとして示されている。知覚ビデオ品質は、６４ｋｂｐｓの品質より１２８ｋｂｐｓの方がよい。この種のビデオコーデックは適応的アプリケーションと順応的アプリケーションの２系統のどちらかに属することができる。適応的アプリケーションでは、操作モードが中間ネットワークからアプリケーションへ信号送信される必要があるのに対して、順応的アプリケーションでは、使用モードの中間ネットワークによる通知がなくても、どのモードでも操作できる。この典型的な実施例においては、適応的ビデオコーデックが仮定されている。
【００８３】
アプリケーションからのＱｏＳ要求は図７で示されたように信号が送られる。現在の方式においては、一度に１つのデータ速度しか要求できない。例えば、１２８ｋｂｐｓに対応するデータ速度がアプリケーションによって要求される。この要求はＵＭＴＳベアラサービスに翻訳され、結果的にＲＡＢは、１つのデータ速度を具備した１つのＲＡＢのみを有する。
【００８４】
本発明の典型的な実施例によれば、アプリケーションはビデオコーデックアプリケーションに関する２つのデータ速度を有した複数選択要求（multiple alternative request）を提供できる。帰着したＲＡＢ要求は、各ＲＡＢが１つの保証ビット速度を具備した２つの代替ＲＡＢも含む。ＲＡＢ要求は、利用者がこのＲＡＢに対して支払うべき「コスト」を含めた、他の特性も含む。ＲＡＢ要求は、配分／保持の優先値(priority value)を割り当てる。例として、２番目の優先値は３番目の優先値より重要なものとして扱われるが、１番目の優先値より重要ではない。
【００８５】
この要求の受け入れにおいて、受け入れ制御５１０（つまり、ＵＴＲＡＮにおける図４の所定のベアラ発生器２４０及びベアラ整合機能２５０）は、その要求を検討し、データ速度を含むネゴシエートされたＲＡＢを返送する。
【００８６】
ＷＣＤＭＡ方式のＵＭＴＳにおいて、所定のベアラ発生器は、移動局が接続される基地局のアクティブセット（アクティブセットは利用者１からｎまでを含む「ａ」として示される）での上り線干渉レベル、アクティブセットによって干渉されたセルにおける干渉レベル、移動局と基地局のアクティブセットとの間の接続における信号品質、アクティブセットでの下り線送信能力、アクティブセットによって干渉されたセルでの下り線送信能力、アクティブセットで使用された下り線拡散符号、アクティブセットでセルに接続された他の移動局に対するＵＴＲＡＮでの行列の大きさ、データ転送に伴ったノードのメモリ容量、処理容量、バッファ容量（つまり、ＭＴ、ＵＴＲＡＮ及びコア網Ｉｕエッジノード）のような入力パラメータを検討する。これらのパラメータを基にして、所定のベアラ発生器が要求に沿ったデータ速度での付加接続の効果を予測し、どのデータ速度を提供するべきかという点で「コスト」を決定する。例えば、基地局のアクティブセットでの干渉レベルが高すぎて移動局に高速データを提供できないことなども含まれる。したがって、データ速度を減速すると、この移動局側でさらに加えられる干渉が減少するので、この状況においては、速度を低下させることがより適切である。（優先事項という言葉で表現される）コストは高速データサービスに対してはとても高く、低速データサービスに対しては低く設定されている。所定の優先事項（つまりコスト）は、その要求が許容されるように、このベアラの要求に割り当てられた重要度を反映する。リソース限度が原因で任意のベアラサービスを提供することができない場合、そのコストは無限大に設定され、このシナリオにおいては、接続は不可能であろう。もう一方の無負荷方式においては、干渉レベルが低いので、どちらのデータ速度も（６４ｋｂｐｓと１２８ｋｂｐｓ）低コストで提供できる。
【００８７】
上述の特別な例において、所定のベアラ発生器は上記で列挙された入力パラメータを考慮し、以下のことを含む。
１）移動局とＰ_１，６４−Ｐ_ｎ，６４及びＰ_{１，１２８}，Ｐ_{ｎ，１２８}（Ｐは能力を示す）との間の伝播路損失は、各６４ｋｂｐｓ及び１２８ｋｂｐｓのビット速度に対して、アクティブセットにおける上り線干渉Ｉ_１，６４−Ｉ_ｎ，６４及びＩ_{１，１２８}，Ｉ_{ｎ，１２８}（Ｉは干渉を示す）を増加させる。
２）アクティブセットでの現在の上り線干渉は十分に小さいので、過負荷の危険性を伴わずに、Ｉ_１，６４，Ｉ_ｎ，６４及びＩ_{１，１２８}，Ｉ_{ｎ，１２８}の干渉を増加させるどちらのビット速度も許容できる。
３）アクティブセットでの現状の上り線干渉は十分に小さいので、過負荷の危険性を伴わずに、どちらのビット速度も許容できる。
４）アクティブセットでの下り線能力が小さいと、６４ｋｂｐｓビット速度を許容、及びＰ_１，６４，Ｐ_ｎ，６４の能力を増加させても、そのシステムにおいて過負荷が引き起こされることはないが、１２８ｋｂｐｓビット速度を許容する、及びＰ_{１，１２８}，Ｐ_{ｎ，１２８}の能力を増加させると、すでに許容された別のＲＡＢの保留が潜在的に引き起こされる。
５）アクティブセットによって干渉されたセルにおける下り線能力は十分に小さいので、どちらのビット速度も受容を許可する。
６）十分開放された下り線拡散符号は、２つのビット速度のいずれかの受容を許可する。
７）アクティブセットでの行列の大きさは十分に小さいので、他のトラフィックの超過遅延をもたらすことなく、２つのビット速度のいずれかの受容を許可する。
８）データ転送に伴うノードのメモリ容量、処理容量、バッファ容量は２つのビット速度のうち、どちらのビット速度をサポートするのにも有効である。
【００８８】
このように、示された例において、方式及び利用者状況はこのようなので、方式に障害をきたすことなく、６４ｋｂｐｓはいずれの優先要求にも提供され得る。６４ｋｂｐｓの保証ビット速度及び３番目の配分／保持の優先（つまり最低可能優先）を有する所定のベアラが形成される。１２８ｋｂｐｓのビット速度が提供されることもあるが、下り線送信能力状況が原因となり、重要利用者のみに提供される。したがって、所定のベアラは１２８ｋｂｐｓの保証ビット速度及び１番目の割り当て／保持の優先で形成される。
【００８９】
その後、所要ベアラと所定ベアラを入力として使用すると、ベアラ整合機能は使用されるべきネゴシエートされたベアラを発生させる。上述の例において、その整合機能は、要求時及び提供時での優先値を基にして、６４ｋｂｐｓの保証ビット速度を有するＲＡＢはネゴシエートされたベアラ（ＮＳＶ）の唯一の選択であると結論付ける。
【００９０】
別の典型的なシナリオにおいて、下り線送信能力は、ネゴシエートされたベアラとして１２８ｋｂｐｓを選択する整合機能を導く優先２で、どちらのビット速度も受容を許可する。さらに別のシナリオにおいては、下り線送信能力ないし他の共通リソースのいずれかが非常に欠乏しているために、６４ｋｂｐｓの承認も１２８ｋｂｐｓの承認も優先２で許可されない。この場合、整合機能がネゴシエートされたベアラの代わりに要求否定メッセージを返信することになる。
【００９１】
ネゴシエートされたベアラは、Ｉｕインターフェース及び他のインターフェースを介してアプリケーションに翻訳して戻され、どのモードで操作すべきかをアプリケーションに通知する。上述で強調した例において、そのモードは「good」 及び「normal」である。他のインターフェースには無線インターフェースも含まれる。そのアプリケーションは端末装置（ＴＥ）内に存在するので、ＴＥはネゴシエーションの結果に関して通知される必要がある。他のＴＥも通知される必要があるので、ネゴシエーションの結果は中間インターフェースを介して、１つのＴＥからもう１つのＴＥまでさまざまに信号送信される必要がある。
【００９２】
本発明の別の典型的な実施例によれば、ＵＭＴＳにおける順応的アプリケーションも公示されている。操作モードについて明示的に通知されず異なる品質のベアラによって搬送できる場合、アプリケーション形式は順応的であるものとして示されている。順応的アプリケーションの例には、広範囲なデータ速度で実行できるウェブ検索がある。したがって、ベアラの網依存選択(Network-dependent selection)はまだ可能であるが、どのデータ速度が使用されるかに関してアプリケーションに明示的に通知する必要はない。
【００９３】
このように、基本的な操作はマルチモードアプリケーションの場合と同じである。しかし、ＵＭＴＳに到達したアプリケーション要求が１つしかないと、そのただ１つの要求が、この特別なアプリケーション要求が、例えば、異なる速度と品質を有する２つの無線アクセスベアラによって択一的にサポートされ得ることを示すＵＭＴＳ内の承諾となる。結果的に、Ｉｕインターフェースを介したベアラ要求は、２つの無線アクセスベアラから構成される。
【００９４】
提供及び整合手続きは、１モードでの操作のみ可能であるので、どのベアラが選択されたかに関してそのアプリケーションに通知する必要がない点を除けば、実質上同じである。
【００９５】
適応的アプリケーション手段で、そのアプリケーションは、ベアラが特有の遅延を提供できないことなど、ネゴシエートされたベアラ（ＮＳＶ）に生じる潜在的な再ネゴシエーションについて認識する必要がある。アプリケーションがＮＳＶの変更に適応し、操作モードを変更できるように、ＮＳＶにおけるこれらの変更はアプリケーションに通信、ないし信号を返信される必要がある。
【００９６】
対照的に、順応的アプリケーション手段では、アプリケーションへの信号返信は要求されない。例えば、遅延のように、ＮＳＶパラメータのうち１つが再ネゴシエートされる場合、アプリケーションは単純にデータを待ち受ける。このような状況において、そのアプリケーションはさらに辛抱強く機能する。つまり、アプリケーションはネゴシエートされたベアラの再ネゴシエーションを許容して調整する。
【００９７】
本発明は、将来的な混成サービス方式に不可欠な無線方式で混成サービスを構造処理するための受け入れ制御方式を提供する。混成サービスを扱うどの無線方式でも同様に、それはＧＳＭ／ＧＰＲＳ，ＷＣＤＭＡ（ＵＴＭＳ）及びＷＬＡＮなど現存する方式に適用できる。しかしながら本発明は無線方式に制限されるものではない。
本発明は理解を容易にするため特定の実施例に関して記述されてきたが、上記実施例は実例であり、限定するために挙げられたのではない。本発明の中心的な意図及び範囲を逸脱することなく、示された特定の実施例とは異なった方法も実施され得ることは当業者にとっては明らかであろう。したがって、本発明は上記の実施例に制限されるものではなく、請求項の範囲において同等であるとみなされるべきである。
【図面の簡単な説明】
【図１】 フローチャートを用いて本発明を説明するものである。
【図２】 電気通信網で導入されるべき本発明の装置の概要図である。
【図３】 複数のサービスを行う電気通信網で導入されるべき本発明の装置の別の実施例である。
【図４】 図３の制御方式の一部である受け入れ制御機能を示すものである。
【図５】 ＵＭＴＳ標準に従ってベアラレベル定義を示すものである。
【図６】 端末装置からのベアラサービス要求の単純化された図を示すものである。
【図７】 アプリケーションからのＱｏＳ要求の送信方法例を示すものである。

Claims (28)

1. コア網及び無線アクセス網を有する網において無線アクセス網からコア網への無線アクセスベアラ上で無線アクセスベアラサービスを提供する方法であって、
   ａ）アプリケーションによって送信されるないし送信される予定の少なくとも１つのセッショントラフィックフローを認識する過程と、
   ｂ）少なくとも１つの無線アクセスベアラを決定するのに必要なパラメータ形式で、認識されたセッショントラフィックフローを特徴付ける過程と、
   ｃ）先行過程のパラメータを無線アクセスベアラ特性に変換する過程と、
   ｄ）前記特性によって定義された１つもしくは複数の無線アクセスベアラを要求して確立する過程と、
   ｅ）前記要求に基づいて確立された適切な無線アクセスベアラ上に各セッショントラフィックを位置付ける過程と、
   ｆ）そのセッションの終了を示す過程と、
   ｇ）無線アクセスベアラを解放する過程と
   を有し、過程ａ）−ｇ）がコア網と無線アクセス網との間のインターフェースに関連してコア網側に導入された論理ノードによって実行され、
   セッションが継続中に、無線アクセス網からその無線アクセス網の状況の変更に関するメッセージを受け取ると、無線アクセスベアラ特性は、その変更を実行するアプリケーションを待ち受けせずに直接変更されることを特徴とする方法。
2. セッショントラフィックが、有効な実存する無線アクセスベアラに送信されたとき、セッションのパケットのパケットヘッダを用いることにより、各過程ａ）、ｂ）で、そのセッションが認識され、特徴づけられることを特徴とする請求項１に記載の方法。
3. 同じソースからの異なるデータストリームがパケットごとに特徴づけられ、正当なベアラ上で位置付けられることを特徴とする請求項２に記載の方法。
4. 過程ａ）が、アプリケーションによって送信される予定の１つもしくは複数のセッショントラフィックフローに関する情報を受信することと、前記情報を用いてセッションを識別することとによって実施され、過程ｂ）が、１つもしくは複数の無線アクセスベアラを決定するのに必要なパラメータ形式で前記情報を用いて識別されたセッショントラフィックフローを特徴付けることによって実施されることを特徴とする請求項１に記載の方法。
5. 過程ｂ）において、アドレス情報、サービス形式、パケット長、識別データ、許容遅延、ビット速度、無線リソース、フレーム誤り率、ビット誤り率、及び／又はトラフィックといったパラメータによってセッションが特徴づけられることを特徴とする請求項１ないし４のいずれかに記載の方法。
6. パラメータに対して値の範囲が指定されることを特徴とする請求項５に記載の方法。
7. 過程ｄ）のベアラ要求が、無線アクセスベアラ特性に加えて、ソース情報及び優先情報のうち少なくとも１つを有することを特徴とする請求項１ないし６のいずれかに記載の方法。
8. 前記ソース情報が値の範囲を含むことを特徴とする請求項７に記載の方法。
9. 前記ソース情報が、アプリケーションがデータを処理する単位時間当たりの速度を含むことを特徴とする請求項７に記載の方法。
10. 前記優先情報がベアラ要求の優先事項を分類することを特徴とする請求項７に記載の方法。
11. アプリケーションが、ビデオコーデックアプリケーションないしウェブ検索アプリケーションのような適応的アプリケーションないし順応的アプリケーションであることを特徴とする請求項１ないし１０のいずれかに記載の方法。
12. パラメータが、基地局のアクティブセットにおける干渉レベルを含み、前記基地局のアクティブセットは移動局が接続される基地局を示すことを特徴とする請求項１ないし１１のいずれかに記載の方法。
13. セッショントラフィックが標準的なエンド・ツー・エンド型による信号／セッションの開始プロトコルの後に続くとき、各過程ａ）、ｂ）において、これらのエンド・ツー・エンド型セッション信号メッセージを受信して解釈することによってセッションが識別され、特徴づけられることを特徴とする請求項１ないし１２のいずれかに記載の方法。
14. セッショントラフィックが、網において、アプリケーションから無線アクセスベアラ管理ノードへの直接信号メッセージの後に続くとき、アプリケーションと前記管理ノードとの間の信号メッセージを解釈することによってセッションが過程ａ）において識別され、過程ｂ）において特徴づけられることを特徴とする請求項１ないし１３のいずれかに記載の方法。
15. 過程ｃ）における無線アクセスベアラ特性へのパラメータの変換が、局部静止型変換データベース、遠隔操作変換データベース、ユーザ・プロファイル、及び／又は、ベアラ管理からの負荷指示器を用いることによって実行されることを特徴とする請求項１ないし１４のいずれかに記載の方法。
16. セッションがアプリケーションのニーズの変更を認識するために時間ごとに調査されることを特徴とする請求項１ないし１５のいずれかに記載の方法。
17. 継続中のセッションにおいて認識されたパラメータの変更が、アプリケーションによって送信された継続中のセッションのパラメータの変更の結果として認識されることを特徴とする請求項１６に記載の方法。
18. 継続中のセッションに対して無線アクセスベアラを定義するために用いられたパラメータが、それらのパラメータを変更するためのアプリケーションからのエンド・ツー・エンド型信号メッセージにより変更されることを特徴とした請求項１ないし１５のいずれかに記載の方法。
19. 継続中のセッションに対して無線アクセスベアラを定義するために用いられたパラメータが、それらのパラメータを変更するためのアプリケーションから網の中の無線アクセスベアラ管理ノードへの信号メッセージにより、変更されることを特徴とする請求項１ないし１５のいずれかに記載の方法。
20. セッションの継続中、その特性に加えられる変更は、無線アクセス網からアプリケーションに送信されたメッセージの結果、アプリケーションによって識別され、そのメッセージは無線アクセス網の状況の変更に関する情報を搬送することを特徴とする請求項１７ないし１９のいずれかに記載の方法。
21. コア網及び無線アクセス網を有する網において、それらの各網間の無線アクセスベアラを介し、異なるアプリケーションの無線アクセスベアラサービスを実行する装置であって、
    ａ）アプリケーションによって送信される予定の１つもしくは複数のセッショントラフィックフローについての情報を受信し、そのセッショントラフィックフローを識別する手段と
    ｂ）１つもしくは複数の無線アクセスベアラを決定するのに必要なパラメータ形式で、識別されたセッショントラフィックフローを特徴付ける手段と、
    ｃ）先行過程のパラメータを無線アクセスベアラ特性に変換する手段と、
    ｄ）前記特性によって定義された１つもしくは複数の無線アクセスベアラを要求して確立する手段と、
    ｅ）適切な確立された無線アクセスベアラ上に各セッショントラフィックを位置付ける手段と、
    ｆ）セッションの終了を示す手段と、
    ｇ）無線アクセスベアラを解放する手段と
    を有し、該装置が、コア網と無線アクセス網との間のインターフェースに関連してコア網側に導入された論理ノードであり、
    前記装置は、セッションの継続中に変更を認識する手段と、無線アクセス網から無線アクセス網の状況の変更に関するメッセージを受信する無線アクセスベアラサービスマネージャとをさらに有し、
    前記無線アクセスベアラサービスマネージャが前記メッセージを受信すると、前記先行過程のパラメータを変換する手段は、その変更を実行するアプリケーションを待ち受けせずに無線アクセスベアラ特性を直接変更することを特徴とする装置。
22. 前記装置が、セッション分級器をさらに具備したことを特徴とする請求項２１に記載の装置。
23. セッション分級器が、前記パラメータにおける変更を認識するためにセッションを時間ごとに調査する手段も具備することを特徴とする請求項２２に記載の装置。
24. 無線アクセスベアラサービスマネージャは、セッション分級器からのセッション要求を受信する手段も具備することを特徴とする請求項２２または２３に記載の装置。
25. 無線アクセスベアラサービスマネージャは、無線アクセス網の状況の変更に関する無線アクセス網からのメッセージをアプリケーションに送信する手段も具備することを特徴とする請求項２１ないし２４のいずれかに記載の装置。
26. 無線アクセスベアラサービスマネージャは、アプリケーション認識可能形式に翻訳する手段とそれらをアプリケーションに送信する手段を具備することを特徴とする請求項２５の装置。
27. 無線アクセスベアラサービスマネージャは、無線アクセス網の状況の変更に関する無線アクセス網からのメッセージに備えて、特性を変更する手段も具備することを特徴とする請求項２５に記載の装置。
28. 利用者データトラフィックを位置付ける手段をさらに具備したことを特徴とする請求項２１ないし２７のいずれかに記載の装置。

Images