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

Abstract

(57)【要約】 本発明は、コア網及び無線アクセス網を有する網において、それらの各網間の無線アクセスベアラ上で無線アクセスベアラサービスを提供するための方法及び装置に関する。アプリケーションによって送信されている１つもしくは複数のセッショントラフィックフローは識別されており、当該識別されたセッションは、１つもしくは複数無線アクセスベアラを決定するのに必要なパラメータ形式で特徴づけられる。当該特徴づけられたパラメータは、無線アクセスベアラ特性に変換される。前記特性によって定義された１つもしくは複数無線アクセスベアラが、要求され、確立される。各セッションは前記要求に基づいて確立された適切な無線アクセスベアラ上に位置付けられる。無線アクセスベアラは必要とされなくなると解放される。本発明の装置は３つの構成要素から成る無線アクセスベアラ管理ノードを有する。

Description

【発明の詳細な説明】

【０００１】 本発明は、コア網及び無線アクセス網を有する網において、それらの各網間の
無線アクセスベアラ上で無線アクセスベアラサービスを提供するための方法及び
装置に関する。それは、それぞれ異なるアプリケーションのリアルタイムサービ
スの送信に適している。

【０００２】 電気通信網管理事業者は、完全な電気通信サービスを提供することもできるし
、ベアラサービスのみを提供することもできる。ベアラサービスは、通信をする
ための移送システムであり、これに対して電気通信サービスは、接続をするため
の機能と通信をするための規則をも包含したものである。

【０００３】 電気通信サービスは、（例えば音声のような）基本サービスであったり、（情
報データベースのような）アプリケーションサービスであったり、あるいは、付
加サービス（基本サービスに変更を加えたものもあり得る。）であったりする場
合がある。電気通信サービスは、そのサービスが音声、データ、ビデオ及びマル
チメディア等のどの形態で利用者に提供されるかに基づいて分類される。

【０００４】 網を介してこういったサービス全てを送信するには、透過性が必要である。良
好な透過性は、網における接続構成要素を通過する際の遅延が最小になること、
情報フローが変動しないこと、及び、送信に必要な回線容量が確保されているこ
とを意味する。したがって、透過性に係わる３つの最重要パラメータは、回線容
量、ビット誤り及び遅延である。音声、ビデオ及びデータに対する回線容量の必
要条件は相互に異なる。例えばビデオ伝送は、最大遅延変動が認められているた
め、網に特別な必要条件を設定する。高品質なビデオ伝送のためには、遅延変動
は小さくなくてはならず、時には数ミリ秒より大きくてはならないこともある。

【０００５】 回線モード及びパケットモードといった様々な転送モードが、様々なサービス
の情報伝送に対して存在する。回線モードでは、情報は所定の長さの時間フレー
ム中で送信される。パケットモードでは、情報は、網を介した移送のためのアド
レスヘッダが付いたパケットに分割される。送信された情報が網を通過する途中
で転送モードを変更することが、ますます一般的になっている。将来的な目的は
、回線容量及び転送モードに関係なく、同じ網で様々なサービス形態の通信をす
ることである。

【０００６】 網を介する通信は、プロトコルと呼ばれるある種の規約に従って実行される。
ＴＣＰ／ＩＰは、世界中の様々なコンピュータ網をつなぐ世界的ネットワークで
あるインターネット上で使用される一連のパケットモードプロトコルである。Ｉ
Ｐプロトコルの主要な役割りはアドレス指定である。ＴＣＰプロトコルは、例え
ば、ホスト間の順序制御及びフロー制御を処理する。

【０００７】 通信には、カップリング及びセッションの２つの段階がある。電話の呼におい
ては、会話そのものがセッションであり、他の通信形態においては、利用者の間
でデータが伝送されている間がセッション段階である。

【０００８】 電気通信網はアクセス網とコア網に分割される。ローカル局（local stations
）間の接続がコア網を規定するのに対して、アクセス網は、加入者とローカル局
を接続する部分である。

【０００９】 移動体電気通信システムには、サービスエリア内に規則的に配置された局部基
地局がある。このようなエリアは、各セル毎に１つの基地局を有するセルに分割
される。無線アクセス網内の移動局は、そのサービスエリアで地理的に最も近い
局部基地局と通信する。固定コア網との通信は、このように無線アクセス網を介
して行われる。

【００１０】 セルラーシステムは、今日、爆発的な増加の一途をたどっている。９０年代前
半、無線利用者に向けての主要サービスは音声であった。音声はリアルタイムで
、遅延の影響を受けやすいサービスであり、セルラー音声通信で用いられる技術
は、多くの点で固定電気通信網から模倣されている。したがって、セルラーシス
テムは従来通り回線交換され、無線インターフェースを介する通信チャネルは専
用チャネルとして定義される。

【００１１】 しかし、近年、他のサービス形態がセルラー業界で出現し始めた。これらは、
無線通信の無線ベアラ上に、例えば遅延や回線容量に関して様々な必要条件を具
備したデータサービスである。このようなサービスに共通の特徴は、そういった
サービスでは、パケットデータ型の形態による伝送の使用を活用できることであ
る。

【００１２】 実際に、その動向は、近年でのインターネットの爆発的な発展で固定電気通信
網の側でも見られるようになった。音声も含む、様々なアプリケーションサービ
ス（通信サービス）が実行されているパケットデータ型インフラストラクチャー
の主要プラットホームはＴＣＰ／ＩＰスーツである。Ｅメール、インターネット
閲覧及びビデオ会議は、まさしく、このような新しいアプリケーションサービス
の例である。ＩＰは、パケットモードサービスであり、接続が保証されないこと
を意味する「最善努力型配送」（“best effort delivery”）を提供する。

【００１３】 異なるシステム間の通信サービスはアプリケーションを用いて使用できる。標
準的なアプリケーションを使用することによって、それぞれ異なるシステムにお
いてデータを単純な方法で置き換えることができる。そのアプリケーションは、
メディアとして、ＴＣＰ（The Transmission Control Protocol)又はＵＤＰ（Th
e User Datagram Protocol)を使用する。アプリケーションの例は、ＳＭＴＰ（S
imple Mail Transfer protocol)、ＳＮＭＰ（Simple Network Management Proto
col)、ＷＨＯＩＳ（カタログデータベース）、ＮＴＰ（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 termin
ation node)（ＭＴ）４３０との間で定義される。これらの２つのノード間の伝
送は、複数のＱｏＳ特性を有するサービスを具備した２つのノード間の一部を形
成する。

【００８０】 その特性は開始又は伝送前にネゴシエートされるので、結局はネゴシエートさ
れたサービスベクタ部，ＮＳＶ部である。所定のベアラサービスの１つは、コア
網ＩＵエッジノード４２０と移動終端ノード（ＭＴ）４３０との間を移送する無
線アクセスベアラ（ＲＡＢ）４１０である。図６でわかるように、所定のベアラ
サービスはつまり、ＵＭＴＳのもとにベアラサービスをセットアップするために
階層構造を形成する。ＲＡＢは、ネゴシエーションがあらゆるベアラサービスレ
ベルにおいて行われるときのためにのみ表示されている。

【００８１】 コア網はゲートウェイとＩＵエッジノードを具備する。ＧＳＭ方式では、対応す
るノードは、ＧＭＳＣとＭＳＣである。ＧＰＲＳ方式に対しては、対応するノー
ドは、ＧＧＳＮとＳＧＳＮである。利用者環境は、論理的に端末装置（ＴＥ）と
移動終端（ＭＴ）とに分類される。ＴＥ部はＵＭＴＳ固有の高層プロトコルレイ
ヤを含む。結果的に、利用者環境のＴＥ部は、ＵＭＴＳを認識しておらず、ＭＴ
部はどのアプリケーションが使用されているかを認識していない。

【００８２】 上述したように、アプリケーションは様々な品質モードで運用している。例え
ば、ビデオコーデックは通常品質モードと高品質モードを有する。高品質モード
においては、アプリケーションは通常モードより速いデータ速度を生み出す。こ
れらは６４ｋｂｐｓ及び１２８ｋｂｐｓの保証ビットレートを具備した異なる品
質モードとして示されている。知覚ビデオ品質は、６４ｋｂｐｓの品質より１２
８ｋｂｐｓの方がよい。この種のビデオコーデックは適応的アプリケーションと
順応的アプリケーションの２系統のどちらかに属することができる。適応的アプ
リケーションでは、操作モードが中間ネットワークからアプリケーションへ信号
送信される必要があるのに対して、順応的アプリケーションでは、使用モードの
中間ネットワークによる通知がなくても、どのモードでも操作できる。この典型
的な実施例においては、適応的ビデオコーデックが仮定されている。

【００８３】 アプリケーションからのＱｏＳ要求は図７で示されたように信号が送られる。
現在の方式においては、一度に１つのデータ速度しか要求できない。例えば、１
２８ｋｂｐｓに対応するデータ速度がアプリケーションによって要求される。こ
の要求はＵＭＴＳベアラサービスに翻訳され、結果的にＲＡＢは、１つのデータ
速度を具備した１つのＲＡＢのみを有する。

【００８４】 本発明の典型的な実施例によれば、アプリケーションはビデオコーデックアプ
リケーションに関する２つのデータ速度を有した複数選択要求（multiple alter
native request）を提供できる。帰着したＲＡＢ要求は、各ＲＡＢが１つの保証
ビット速度を具備した２つの代替ＲＡＢも含む。ＲＡＢ要求は、利用者がこのＲ
ＡＢに対して支払うべき「コスト」を含めた、他の特性も含む。ＲＡＢ要求は、
配分／保持の優先値(priority value)を割り当てる。例として、２番目の優先値
は３番目の優先値より重要なものとして扱われるが、１番目の優先値より重要で
はない。

【００８５】 この要求の受け入れにおいて、受け入れ制御５１０（つまり、ＵＴＲＡＮにお
ける図４の所定のベアラ発生器２４０及びベアラ整合機能２５０）は、その要求
を検討し、データ速度を含むネゴシエートされたＲＡＢを返送する。

【００８６】 ＷＣＤＭＡ方式のＵＭＴＳにおいて、所定のベアラ発生器は、移動局が接続さ
れる基地局のアクティブセット（アクティブセットは利用者１からｎまでを含む
「ａ」として示される）での上り線干渉レベル、アクティブセットによって干渉
されたセルにおける干渉レベル、移動局と基地局のアクティブセットとの間の接
続における信号品質、アクティブセットでの下り線送信能力、アクティブセット
によって干渉されたセルでの下り線送信能力、アクティブセットで使用された下
り線拡散符号、アクティブセットでセルに接続された他の移動局に対するＵＴＲ
ＡＮでの行列の大きさ、データ転送に伴ったノードのメモリ容量、処理容量、バ
ッファ容量（つまり、ＭＴ、ＵＴＲＡＮ及びコア網Ｉｕエッジノード）のような
入力パラメータを検討する。これらのパラメータを基にして、所定のベアラ発生
器が要求に沿ったデータ速度での付加接続の効果を予測し、どのデータ速度を提
供するべきかという点で「コスト」を決定する。例えば、基地局のアクティブセ
ットでの干渉レベルが高すぎて移動局に高速データを提供できないことなども含
まれる。したがって、データ速度を減速すると、この移動局側でさらに加えられ
る干渉が減少するので、この状況においては、速度を低下させることがより適切
である。（優先事項という言葉で表現される）コストは高速データサービスに対
してはとても高く、低速データサービスに対しては低く設定されている。所定の
優先事項（つまりコスト）は、その要求が許容されるように、このベアラの要求
に割り当てられた重要度を反映する。リソース限度が原因で任意のベアラサービ
スを提供することができない場合、そのコストは無限大に設定され、このシナリ
オにおいては、接続は不可能であろう。もう一方の無負荷方式においては、干渉
レベルが低いので、どちらのデータ速度も（６４ｋｂｐｓと１２８ｋｂｐｓ）低
コストで提供できる。

【００８７】 上述の特別な例において、所定のベアラ発生器は上記で列挙された入力パラメ
ータを考慮し、以下のことを含む。 １）移動局とＰ_１，６４−Ｐ_ｎ，６４及びＰ_{１，１２８}，Ｐ_{ｎ，１２８}（Ｐは能
力を示す）との間の伝播路損失は、各６４ｋｂｐｓ及び１２８ｋｂｐｓのビット
速度に対して、アクティブセットにおける上り線干渉Ｉ_１，６４−Ｉ_ｎ，６４及
びＩ_{１，１２８}，Ｉ_{ｎ，１２８}（Ｉは干渉を示す）を増加させる。 ２）アクティブセットでの現在の上り線干渉は十分に小さいので、過負荷の危険
性を伴わずに、Ｉ_１，６４，Ｉ_ｎ，６４及びＩ_{１，１２８}，Ｉ_{ｎ，１２８}の干渉
を増加させるどちらのビット速度も許容できる。 ３）アクティブセットでの現状の上り線干渉は十分に小さいので、過負荷の危険
性を伴わずに、どちらのビット速度も許容できる。 ４）アクティブセットでの下り線能力が小さいと、６４ｋｂｐｓビット速度を許
容、及びＰ_１，６４，Ｐ_ｎ，６４の能力を増加させても、そのシステムにおいて
過負荷が引き起こされることはないが、１２８ｋｂｐｓビット速度を許容する、
及びＰ_{１，１２８}，Ｐ_{ｎ，１２８}の能力を増加させると、すでに許容された別の
ＲＡＢの保留が潜在的に引き起こされる。 ５）アクティブセットによって干渉されたセルにおける下り線能力は十分に小さ
いので、どちらのビット速度も受容を許可する。 ６）十分開放された下り線拡散符号は、２つのビット速度のいずれかの受容を許
可する。 ７）アクティブセットでの行列の大きさは十分に小さいので、他のトラフィック
の超過遅延をもたらすことなく、２つのビット速度のいずれかの受容を許可する
。 ８）データ転送に伴うノードのメモリ容量、処理容量、バッファ容量は２つのビ
ット速度のうち、どちらのビット速度をサポートするのにも有効である。

【００８８】 このように、示された例において、方式及び利用者状況はこのようなので、方
式に障害をきたすことなく、６４ｋｂｐｓはいずれの優先要求にも提供され得る
。６４ｋｂｐｓの保証ビット速度及び３番目の配分／保持の優先（つまり最低可
能優先）を有する所定のベアラが形成される。１２８ｋｂｐｓのビット速度が提
供されることもあるが、下り線送信能力状況が原因となり、重要利用者のみに提
供される。したがって、所定のベアラは１２８ｋｂｐｓの保証ビット速度及び１
番目の割り当て／保持の優先で形成される。

【００８９】 その後、所要ベアラと所定ベアラを入力として使用すると、ベアラ整合機能は
使用されるべきネゴシエートされたベアラを発生させる。上述の例において、そ
の整合機能は、要求時及び提供時での優先値を基にして、６４ｋｂｐｓの保証ビ
ット速度を有するＲＡＢはネゴシエートされたベアラ（ＮＳＶ）の唯一の選択で
あると結論付ける。

【００９０】 別の典型的なシナリオにおいて、下り線送信能力は、ネゴシエートされたベア
ラとして１２８ｋｂｐｓを選択する整合機能を導く優先２で、どちらのビット速
度も受容を許可する。さらに別のシナリオにおいては、下り線送信能力ないし他
の共通リソースのいずれかが非常に欠乏しているために、６４ｋｂｐｓの承認も
１２８ｋｂｐｓの承認も優先２で許可されない。この場合、整合機能がネゴシエ
ートされたベアラの代わりに要求否定メッセージを返信することになる。

【００９１】 ネゴシエートされたベアラは、Ｉｕインターフェース及び他のインターフェー
スを介してアプリケーションに翻訳して戻され、どのモードで操作すべきかをア
プリケーションに通知する。上述で強調した例において、そのモードは「good」
及び「normal」である。他のインターフェースには無線インターフェースも含
まれる。そのアプリケーションは端末装置（ＴＥ）内に存在するので、ＴＥはネ
ゴシエーションの結果に関して通知される必要がある。他のＴＥも通知される必
要があるので、ネゴシエーションの結果は中間インターフェースを介して、１つ
のＴＥからもう１つのＴＥまでさまざまに信号送信される必要がある。

【００９２】 本発明の別の典型的な実施例によれば、ＵＭＴＳにおける順応的アプリケーシ
ョンも公示されている。操作モードについて明示的に通知されず異なる品質のベ
アラによって搬送できる場合、アプリケーション形式は順応的であるものとして
示されている。順応的アプリケーションの例には、広範囲なデータ速度で実行で
きるウェブ検索がある。したがって、ベアラの網依存選択(Network-dependent s
election)はまだ可能であるが、どのデータ速度が使用されるかに関してアプリ
ケーションに明示的に通知する必要はない。

【００９３】 このように、基本的な操作はマルチモードアプリケーションの場合と同じであ
る。しかし、ＵＭＴＳに到達したアプリケーション要求が１つしかないと、その
ただ１つの要求が、この特別なアプリケーション要求が、例えば、異なる速度と
品質を有する２つの無線アクセスベアラによって択一的にサポートされ得ること
を示すＵＭＴＳ内の承諾となる。結果的に、Ｉｕインターフェースを介したベア
ラ要求は、２つの無線アクセスベアラから構成される。

【００９４】 提供及び整合手続きは、１モードでの操作のみ可能であるので、どのベアラが
選択されたかに関してそのアプリケーションに通知する必要がない点を除けば、
実質上同じである。

【００９５】 適応的アプリケーション手段で、そのアプリケーションは、ベアラが特有の遅
延を提供できないことなど、ネゴシエートされたベアラ（ＮＳＶ）に生じる潜在
的な再ネゴシエーションについて認識する必要がある。アプリケーションがＮＳ
Ｖの変更に適応し、操作モードを変更できるように、ＮＳＶにおけるこれらの変
更はアプリケーションに通信、ないし信号を返信される必要がある。

【００９６】 対照的に、順応的アプリケーション手段では、アプリケーションへの信号返信
は要求されない。例えば、遅延のように、ＮＳＶパラメータのうち１つが再ネゴ
シエートされる場合、アプリケーションは単純にデータを待ち受ける。このよう
な状況において、そのアプリケーションはさらに辛抱強く機能する。つまり、ア
プリケーションはネゴシエートされたベアラの再ネゴシエーションを許容して調
整する。

【００９７】 本発明は、将来的な混成サービス方式に不可欠な無線方式で混成サービスを構
造処理するための受け入れ制御方式を提供する。混成サービスを扱うどの無線方
式でも同様に、それはＧＳＭ／ＧＰＲＳ，ＷＣＤＭＡ（ＵＴＭＳ）及びＷＬＡＮ
など現存する方式に適用できる。しかしながら本発明は無線方式に制限されるも
のではない。 本発明は理解を容易にするため特定の実施例に関して記述されてきたが、上記
実施例は実例であり、限定するために挙げられたのではない。本発明の中心的な
意図及び範囲を逸脱することなく、示された特定の実施例とは異なった方法も実
施され得ることは当業者にとっては明らかであろう。したがって、本発明は上記
の実施例に制限されるものではなく、請求項の範囲において同等であるとみなさ
れるべきである。

【図面の簡単な説明】

【図１】 フローチャートを用いて本発明を説明するものである。

【図２】 電気通信網で導入されるべき本発明の装置の概要図である。

【図３】 複数のサービスを行う電気通信網で導入されるべき本発明の装置
の別の実施例である。

【図４】 図３の制御方式の一部である受け入れ制御機能を示すものである
。

【図５】 ＵＭＴＳ標準に従ってベアラレベル定義を示すものである。

【図６】 端末装置からのベアラサービス要求の単純化された図を示すもの
である。

【図７】 アプリケーションからのＱｏＳ要求の送信方法例を示すものであ
る。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０９／５２２，９０５ (32)優先日 平成12年３月10日(2000．3．10) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ， ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ， ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，Ｋ Ｐ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ， ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，Ｓ Ｇ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 オロフソン， ホーカン スウェーデン国 エス−118 67 ストッ クホルム， リングヴェーイェン 50 (72)発明者 ツリナ， ダリボー スウェーデン国 エス−183 57 テェビ ー， ユールショルムスヴェーイェン 93 (72)発明者 ハラスチ， ソルト アメリカ合衆国 ノースカロライナ州 27511， カリー， トレリス グリーン 2323 (72)発明者 ハートマン， マグナス スウェーデン国 エス−118 23 ストッ クホルム， ブレンシュルカガタン 75 エイ (72)発明者 リンドバーグ， ニクラス スウェーデン国 エス−126 35 ホーゲ ーステン， ヴァッテンレドニングスヴェ ーイェン 91 Ｆターム(参考） 5K033 AA02 CB01 CB06 DA01 DA17 DB12 DB16 EC01

Claims (36)

【特許請求の範囲】
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. 【請求項２８】 それが、３つの機能構成要素によって構成されることを特
    徴とする請求項２４ないし２７のいずれかに記載の装置。
29. 【請求項２９】 機能構成要素のうちの１つが、項目ａ）ないしｃ）及びｇ
    ）の手段を含むセッション分級器であることを特徴とする請求項２８に記載の装
    置。
30. 【請求項３０】 セッション分級器が、前記パラメータにおける変更を認識
    するためにセッションを時間ごとに調査する手段も具備することを特徴とする請
    求項２９に記載の装置。
31. 【請求項３１】 機能構成要素のうち１つが、請求項２４の項目ｄ）及びｇ
    ）の手段と請求項２５の手段を具備した無線アクセスベアラサービスマネージャ
    であることを特徴とする請求項３０に記載の装置。
32. 【請求項３２】 無線アクセスベアラサービスマネージャは、セッション分
    級器からのセッション要求を受信する手段も具備することを特徴とする請求項３
    １に記載の装置。
33. 【請求項３３】 無線アクセスベアラサービスマネージャは、無線アクセス
    網の状況の変更に関する無線アクセス網からのメッセージを受信する手段とそれ
    らをアプリケーションに送信する手段も具備することを特徴とする請求項３２に
    記載の装置。
34. 【請求項３４】 無線アクセスベアラサービスマネージャは、アプリケーシ
    ョン認識可能形式に翻訳する手段とそれらをアプリケーションに送信する手段を
    具備することを特徴とする請求項３３の装置。
35. 【請求項３５】 無線アクセスベアラサービスマネージャは、無線アクセス
    網の状況の変更に関する無線アクセス網からのメッセージに備えて、特性を変更
    する手段も具備することを特徴とする請求項３３に記載の装置。
36. 【請求項３６】 機能構成要素のうちの１つが、項目ｅ）の手段を含む、利
    用者データトラフィックを位置付ける手段によって構成されることを特徴とする
    請求項２４に記載の装置。