JP2005525023A - ＱｏＳパラメータ変換器 - Google Patents
ＱｏＳパラメータ変換器 Download PDFInfo
- Publication number
- JP2005525023A JP2005525023A JP2004502558A JP2004502558A JP2005525023A JP 2005525023 A JP2005525023 A JP 2005525023A JP 2004502558 A JP2004502558 A JP 2004502558A JP 2004502558 A JP2004502558 A JP 2004502558A JP 2005525023 A JP2005525023 A JP 2005525023A
- Authority
- JP
- Japan
- Prior art keywords
- rate
- error rate
- sdu
- determining
- bit error
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2491—Mapping quality of service [QoS] requirements between different networks
Landscapes
- Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Oscillators With Electromechanical Resonators (AREA)
- Control Of Motors That Do Not Use Commutators (AREA)
- Medicines Containing Material From Animals Or Micro-Organisms (AREA)
- Networks Using Active Elements (AREA)
- Diaphragms For Electromechanical Transducers (AREA)
Abstract
ＵＭＴＳがＩＰのエンド−ツウ−エンドの通信の一部であるとき、ＵＭＴＳにとってＩＰ上にあふれだしたアプリケーションのために必要なサービスの品質（ＱｏＳ）を提供できる手段が存在しなければならない。それ故に、ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換を行うための変換機能の必要性がある。この変換はいくつかの理由のためにささいなものではない。第１に、ＩＰレベルとＵＭＴＳレベルにおけるＱｏＳパラメータの数が異なる。第２に、２つのレベルにおけるパラメータの定義も異なっている。これらの因子を考慮して、本発明はＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性に変換する方法と、ＵＭＴＳのＱｏＳ属性をＩＰのＱｏＳパラメータに変換するもう１つの方法とを提供する。この変換により、スペクトラムを効率的に用いるＵＭＴＳのベアラがＩＰにあふれだすアプリケーションについてセットアップされることが可能になる。また、これはＩＰレベルのエンティティとＵＭＴＳネットワークとの間のサービスのネゴシエーションを可能にする。これらの方法は、ユーザ装置とともにＵＭＴＳネットワークのゲートウェイにも置かれるであろう。
Description
本発明はインターネットプロトコル（ＩＰ）と全球的移動体通信サービス（ＵＭＴＳ）との相互動作に関し、特に、ＩＰのサービス品質（ＱｏＳ）パラメータとＵＭＴＳのＱｏＳ属性との間の変換を扱うものである。
第３世代無線アクセス技術の出現とともに、移動体電話の従来の標準は過去のものとなるであろう。移動体技術は今や、マルチメディアや情報サービスのような基本的な電話の枠をはるかに越えた特徴を備えることができるであろう。これらのサービスに対する永続的に広がる消費者の市場は、インターネットの広範な成長によって創造されつつある。しかしながら、これらのサービスを提供してゆく場合、いくつかの挑戦が待ち受けている。市場の観点からすると、これはセルラ環境とインターネット環境の両方においてユーザにインストールされた基盤を統合することに係わっていくであろう。技術的に言えば、その挑戦は一方ではセルラの解決策について他方では効率的なインターネットアクセスについての共通の要素を決定することである。これらの挑戦にうまく合致するため、第３世代の無線システムは、多数のサービスを提供し、かなりの柔軟性をもち、高能率の無線スペクトラムでカバレッジを保証する一方、構造化されたＱｏＳ処理と費用効果性の高いアクセスとを提供するように設計されねばならない。
インターネットは伝統的にベストエフォートで基本に動作する。ベストエフォートサービスは、バンド幅と遅延変化に適合できる過去の遺物とも言えるデータトラフィックやアプリケーションには適切なものであった。しかしながら、近年、インターネットで実行することができるために、リアルタイム性と他のＱｏＳ保証とを必要とするアプリケーションに対する必要が大きくなってきた。高速ネットワークとプロセッサの出現は種々の広く配布されるアプリケーションを可能にした。しかしながら、インターネットドメインではリアルタイムサービスと保証がないので、そのようなアプリケーションの大規模な展開を制限するものであった。これらのアプリケーションは、タイミング、提供するサービスの精度と正確さによって表されるエンド−ツウ−エンドＱｏＳ要求をもっている。例えば、ビデオ会議の通常のユーザは最終的には（最終的な結果）その画像の品質に関心をもつが、しかしながら、このことは同様に、ビデオをキャプチャーし、それを圧縮し、ネットワークにより送信し、それを伸張し、最後に表示するＱｏＳの積み重ねである。
インターネットＱｏＳは、遅延、ジッタ、バンド幅、そして信頼性が問われるネットワークの組み合わせとして表現される。遅延はパケットがソースから宛先まで通過する際の所要時間である。ジッタはエンド−ツウ−エンド遅延における知覚される変動である。バンド幅はソースと宛先との間で維持される最大データ転送率である。最後に、その送信は、もし全てのパケットを正しい順番で、それが欠落することなく、或いはビットエラーを生じさせることなく、配信するなら信頼性がある。信頼性とは送信システムにおける特性であり、その媒体の平均エラー率とともに経路選択と交換設計によっても影響を受ける。有線インターネットでは、パケット損失は共に輻輳により生じる。しかしながら、無線ネットワークでは、輻輳とメディアの信頼性のなさとの両方が考慮されねばならない。
上述のようにインターネットＱｏＳの種々の欠点はある程度までは、多数のサービスレベルを提供するように設計された分化サービス（Differentiated Services (Diffserv)）や統合サービス（Integrated Services (Intserv)）のような、現在のインターネットにより提供されるベストエフォートサービスである単一サービスよりむしろ種々のサービスを提供することにより対処することができる。
上述のＱｏＳを備えたサービス各々は異なるパラダイムを用いてＱｏＳを提供している。DiffservとIntservとはインターネット技術タスクフォース（Internet Engineering Task Force：ＩＥＴＦ）により提案されたものであり、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）環境の上に構築される。Diffservは、ルータのような中間システムに展開されるパケットを基本とした優先度サービスであり、保証された特別なサービス（Assured and Premium service）に区別されたサービス優先度を提供する。Intservは、エンドシステム（例えば、ホスト）と中間システム（例えば、ルータ）の両方に展開されるフローを基本とした予約サービスであり、リアルタイム通信のようなアプリケーションに制御された負荷（Controlled-Load）と保証された（Guaranteed）サービスとを提供している。
ＱｏＳを備えたサービス各々はそれ自身のカスタムユーザインタフェースを提供することによりアプリケーションにサービスを行っている。これには、アプリケーション・プログラミング・インタフェース（ＡＰＩ）とＱｏＳ仕様とが含まれる。Diffservはバンド幅ブローカ（ＢＢ：Bandwidth Broker）とそのＡＰＩを用い、Intservは資源予約プロトコル（ＲＳＶＰ：Resource ReSerVation Protocol）とそのＡＰＩを用いている。
それ故に、アプリケーションはインタフェースの起源の異なるユーザインタフェースに対処してそのＱｏＳを保証する必要がある。加えて、ＱｏＳ要求はアプリケーションからアプリケーションへと変化する。例えば、インタフェース電話のアプリケーションは音声信号が許容遅延変動内に到着することを必要とするし（ジッタ）、ビデオプレーヤーは画像をスムーズに搬送するバンド幅保証を必要とするし（バンド幅）、リアルタイムモニタは通信遅延が厳密に保証されていることを必要とする（遅延）。
今や生じる重要な問題はアプリケーションがＱｏＳを備えたサービスと相互作用できることを容易にする点にある。第１に、ユーザはネットワークによって提供される具体的なサービスの正確な知識をもっていないかもしれないし、その必要のためにＱｏＳ要求のカスタマイズの仕方を知らないかもしれない。第２に、ネットワークＱｏＳは異なるサービスモデルを用いて表現されても良いし、一貫性のない資源利用を引き起こすかもしれない。第３に、古典的なアプリケーションはＱｏＳ配信に接続して制御するために拡張されたり、アシストされたりする必要がある。第４に、システムと、ＱｏＳを扱うように備えられていないアプリケーションとのＱｏＳ制御の相互動作が、ＱｏＳ制御がいくつかのネットワークシステムに対して部分的にのみ利用可能であるときには、特に重要なものとなる。その問題は、無線システムがたまたまＩＰのエンド−ツウ−エンド通信の一部になるときにはさらに拡大する。
特に関心のあるものの内、無線システムがＵＭＴＳを基本とする具体的な事例がある。この場合についての詳細な検討を以下行う。
図１はＩＰネットワークを示している。その図は２つのユーザを示しているが、そのネットワークの基本的な機能性を変更することなく、より多くのユーザを含むように容易に適合できる。
図１において、ユーザＡは、テキストを基本とするか、或いは、音声を基本とした会話によりユーザＢと通信を行うかもしれない。同様に、ユーザＡはビデオストリーミングサーバであるかもしれないアプリケーションサーバと通信を行うかもしれない。これらのアクセスの両方における共通の要素は、ユーザが、電話、ＧＳＭ（Global System for Mobile Communication：汎欧州デジタル移動電話方式）、ＧＰＲＳ（汎用パケット無線サービス：General Packet Radio Service）、或いはＵＭＴＳネットワークのようなローカルアクセスネットワークを介してＩＰバックボーンのネットワークに接続することである。さらにその上、このローカルアクセスネットワークはユーザＡとユーザＢとに対して異なっても良い。ＩＰバックボーンネットワークは、パケットをユーザＡとユーザＢとの間で、そして、ユーザＡとアプリケーションサーバとの間でルーティングするために数多くのルータを有しても良い。
ユーザに関する限り、問題となるのはユーザにより知覚されるＱｏＳである。それ故に、全ての中間的なネットワークは互いに“協働”して互いのＱｏＳを“理解”する必要がある。
異なるアプリケーションが種々のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を介してネットワークにアクセスできる。ＡＰＩは基幹となるシステムの資源にアクセスするための統一したインタフェースをアプリケーションプログラマに提供している。例えば、もしＩＰネットワークがDiffservネットワークであるなら、アプリケーションプログラムはＩＰパケットの全てが“早期転送（Expedited Forwarding）”処理を受信することを要求するかもしれない。
なお、ＡＰＩは種々のアクセスネットワークとバックボーンネットワークに組み込まれた技術のことを忘れてしまうかもしれないが、それらのネットワークも同様にそれら自身のＱｏＳレベルを採用しているかもしれない。例えば、ユーザはＲＳＶＰ／Intservを基本としたＡＰＩを用いるかもしれないが、エンド−ツウ−エンドの実施例はＵＭＴＳアクセスネットワークとＲＳＶＰを用いないで動作可能なＩＰネットワークとを含んでも良い。そのような場合、ＱｏＳがエンド−ツウ−エンドに備えられることを確実にするあるメカニズムが求められる。
図２はホスト間のエンド−ツウ−エンドの統合サービスを示している。そのサービスはノード間での関連情報のシグナリングによりサービス定義をサポートするルータとホストとを用いて提供される。そのホストはＲＳＶＰを用いて、特定のアプリケーションについて、ネットワークから欲している所望のサービス品質を要求する。全ての中間ルータもまたＲＳＶＰを用いてＱｏＳを全ての経路に沿って各ノードに配信し、要求されたサービスを提供するために状態を確立・維持する。その結果、ＲＳＶＰ要求は一般に、ネットワークが宛先への経路上にある全てのノードにおいて資源を確保するようになる。
ＧＰＲＳとＵＭＴＳとは全体的なネットワークの一部を形成し、それに接続されるカスタマのためのエンド−ツウ−エンドのベアラサービスにおいて重要な役割を果たす。従って、ＧＰＲＳ／ＵＭＴＳネットワークによって提供されるサービスは、要求されるエンド−ツウ−エンドのベアラサービスを提供できるために、シグナリングとユーザプレーンのトランスポートを制御する面から適切なものでなければならない。図３は図１の具体例を図示しており、そこではローカルアクセスネットワークがＧＰＲＳ／ＵＭＴＳネットワークとなっている。ＧＰＲＳ／ＵＭＴＳネットワークは、移動局（ＭＳ）として言及されるホストと、ユーザが接続する外部のパケット交換ネットワークとの間のネットワーク要素のセットから成り立っている。サービングＧＰＲＳサポートノード（ＳＧＳＮ）は対応するＭＳについての移動管理と認証とを提供する。ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）はＵＭＴＳコアネットワークと外部ネットワークとの間のゲートウェイとしてふるまう。
ベアラは、そのソースからＱｏＳベアラサービスの宛先までの経路全てでセットされて明瞭に定義された特性と機能性とを具体化しなければならない。契約をしたＱｏＳの提供を可能にするために、ベアラサービスは全ての必要な様相を含まなければならない。ＱｏＳ要求は考慮中の現在のＵＭＴＳのＱｏＳクラスに依存している。
図４はＵＭＴＳについてのＱｏＳクラスを図示している、そこには４つのＱｏＳクラスがある。即ち、会話クラス、ストリーミングクラス、インタラクティブクラス、及びバックグラウンドクラスである。これらＱｏＳクラス間での主要な区別される因子は遅延敏感度である。即ち、会話クラスでは遅延に敏感なトラフィックについて意味するものであるが、バックグラウンドクラスではトラフィックは遅延に敏感ではないことを意味する。会話とストリーミングクラスでは主としてリアルタイムトラフィックを搬送することが意図されている。それらの間の主要な区別因子は各遅延敏感度である。ビデオや電話のような会話のあるリアルタイムサービスは最も遅延に敏感なアプリケーションであり、これらのデータストリームは会話クラスで搬送されるべきである。
インタラクティブ及びバックグラウンドクラスは主として、ワールドワイドウェブ（ＷＷＷ）、電子メール、テルネット（Telnet）、ファイル転送プロトコル（ＦＴＰ）、及びニュースのような伝統的なインターネットアプリケーションにより用いられることが意図されている。遅延に対する要求がゆるいため、会話クラスやストリーミングクラスと比較して、両方ともチャネル符号化及び再送により、より良いエラー処置を提供している。インタラクティブとバックグラウンドクラスとの間の主要な違いは、インタラクティブクラスが主として、例えばインタラクティブ電子メールやインタラクティブウェブ閲覧のようなインタラクティブアプリケーションにより用いられる一方、バックグラウンドクラスは、例えば、電子メールのバックグラウンドでのダウンロードやバックグラウンドでのファイルのダウンロードなどのバックグラウンドのトラフィックに対して意図されている点にある。インタラクティブ・アプリケーションの応答性は、インタラクティブ・アプリケーションとバックグラウンド・アプリケーションとを分離することにより保証される。バックグラウンド・アプリケーションはインタラクティブ・アプリケーションが伝送資源を必要としないときにのみ、伝送資源を用いるので、インタラクティブクラスでのトラフィックはバックグラウンドクラスのトラフィックと比較してスケジューリングを行う際により高い優先度をもつ。有線ネットワークと比較してバンド幅が不足する無線環境では、このことは非常に重要である。
図５は異なるＵＭＴＳのＱｏＳ属性を使用する様子を概観したものである。これら属性の正確な定義は３ＧＰＰ ＴＳ ２３．１０７に見出すことができる。
図６において、ＵＭＴＳベアラの属性と各ベアラのトラフィッククラスについての関連性が示されている。
図７はいくつかのＩＰのＱｏＳパラメータについて概観したものである。ＩＰのＱｏＳパラメータは３つのクラスに分割される。即ち、制御された負荷サービスパラメータ、ＭＩＭＥ固有のパラメータ、及び“無線ヒント（wireless hints）”（標準化のためにＩＥＴＦに提案中）である。ＭＩＭＥ固有パラメータと“無線ヒント”とはオプションとして考慮される。
図８はＵＭＴＳベアラサービスのレイヤ化されたアーキテクチュアを描いたものである。１つの端末装置（ＴＥ）から別のものへの経路において、トラフィックはネットワークの異なるベアラサービスを通過しなければならない。ＴＥは移動体端末（ＭＴ）の使用によりＵＭＴＳネットワークに接続されている。アプリケーションレベルでのエンド−ツウ−エンドのサービスは基幹となるネットワークのベアラサービスを使用する。ＴＥにより使用されるエンド−ツウ−エンドのサービスは、ＴＥ／ＭＴローカルベアラサービス、ＵＭＴＳベアラサービス、及び外部ベアラサービスを利用して具体化される。ＵＭＴＳベアラサービスはＵＭＴＳのＱｏＳを提供するベアラサービスである。
エンド−ツウ−エンドのＩＰのＱｏＳについての制御プレーンとＱｏＳ管理のためのＵＭＴＳベアラサービスのＱｏＳ管理機能が図９に図示されている。これらは３ＧＰＰ ＴＳ ２３．１０７と３ＧＰＰ ＴＳ ２３．２０７とに詳細に記載されている。
上述のようなシステム（即ち、ＩＰのエンド−ツウ−エンド通信の一部としてのＵＭＴＳ）は非常に多くのバラエティに富んだアプリケーションをもっている。ＵＭＴＳが提供するであろうそのように多くのバラエティに富んだアプリケーションの結果として、ＩＰ−ＵＭＴＳのトラフィックが将来的にはとてつもなく大きくなるのではと憶測がとんでいる。そのようなアプリケーションはビデオストリーミング、ビデオ会議、マルチメディアメッセージサービスを含むであろう。これは、無線媒体ではバンド幅の不足があるため、特に、ＵＭＴＳドメインでのバンド幅の効率的利用の必要性を作り出すものとなるであろう。ある者がＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性へと変換することができるなら、容易に特定のアプリケーションについてのバンド幅要求を決定することができ、これにより効率的なスペクトラム利用ができる結果となるであろう。
さらに、アプリケーションは異なるレベル（例えば、アプリケーションの種類や受信ＱｏＳ）でサービスをネゴシエーションすることが要求されるであろうし、そのレベルに関し、ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間での変換は必須であるように思われる。この変換はおそらく、ＩＰレベルでのエンティティと全ＵＭＴＳネットワーク自身との間のより効率的なサービスネゴシエーションをもたらす結果となるであろう。
この分野において、ある特許出願がなされている。その名称を“３ＧネットワークにおけるＲＳＶＰの扱い（RSVP handling in 3G network）”という特許文献１は、３Ｇ無線ネットワークにおけるＲＳＶＰシグナリングをサポートするために移動体端末での方法を提供することを扱っている。移動体端末はローカルなユーザの端末装置に接続され、また、無線ネットワークと通信を行う。ＵＭＴＳネットワークにおけるＲＳＶＰとＩＰのＱｏＳ情報の相互動作をサポートするために、その発明は、パケットデータプロトコル（ＰＤＰ）環境にＩＰのＱｏＳ情報を含ませ、そのＱｏＳ情報をＵＭＴＳネットワークを通して搬送する方法を提供している。しかしながら、その発明はＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性に変換することや、その逆の過程についての問題を扱ってはいない。その変換は、ＩＰトラフィックを扱う一方でＵＭＴＳドメインにおける効率的なスペクトラム利用のために本質的なものである。この変換機能はまた、ＩＰレベルでのエンティティと全ＵＭＴＳネットワークとの間のサービスネゴシエーションのためにも必要とされる。
国際公開第０１／５６２５０号パンフレット
ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間のこの変換は、いくつかの理由のためにささいなものではない。第１に、２つのレベルにおけるＱｏＳパラメータの数は、そのマッピングが１対１の対応ではないために異なる。第２に、２つのレベルにおけるパラメータの定義も異なっている。このことはパラメータの範囲とその予想される利用法との両方に関して真実である。これは、例えば、（セルラネットワークにおけるスペクトラムの効率的なトランスポートに対して今日のＩＰネットワークでは過剰供給している）ＱｏＳを提供する異なる方法のためである。第３に、（図７で具体的に記載されている）無線ヒントを含むＩＰのＱｏＳパラメータセットを変換する問題は早期に解決されていなかった。
それ故に、必要なことは、ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換のための変換機能である。
要約
本発明はＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換についての変換機能の必要を満たす方法に関するものである。
本発明はＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換についての変換機能の必要を満たす方法に関するものである。
本発明の目的は、ＩＰのＱｏＳパラメータ（無線ヒントを含む）とＵＭＴＳのＱｏＳ属性との間の変換についての変換機能の必要を満たす方法に関するものである。
本発明の別の目的は、ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換を行う移動体端末における方法を提供することにある。
本発明の別の目的は、無線ヒントを含むＩＰのＱｏＳパラメータからＵＭＴＳのＱｏＳ属性へ変換方法を提供することにある。
本発明のさらに別の目的は、ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換を行うＵＭＴＳゲートウェイにおける方法を提供することにある。
本発明のさらに別の目的は、ＵＭＴＳのＱｏＳ属性から無線ヒントを含むＩＰのＱｏＳパラメータへ変換方法を提供することにある。
本発明のさらに別の目的は、ＵＭＴＳベアラの効率的な利用についてのＱｏＳ変換方法を提供することにある。
本発明のさらに別の目的は、ＩＰレベルのエンティティとＵＭＴＳネットワークとの間でのサービスネゴシエーションを可能するＱｏＳ変換方法を提供することにある。
前述の目的を達成するために、そして、ここで広く説明するように本発明の目的に従って、本発明はＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換の方法を提供するものである。
本発明の好適な実施例についてこれ以後、本発明を限定するものではなく例示的に示すために備えられた添付図面との関連で説明するが、それらの図面において同じ指示記号は同じ構成要素を示すものである。
図１はＩＰネットワークを図示している。ここで、ユーザＡ１０１はユーザＢ１０２或いはアプリケーションサーバ１０３と通信することができる。両方のユーザともローカルアクセスネットワーク１０５と１０６を介してインターネット１０４に接続されている。本発明は、ユーザがインターネットにＵＭＴＳネットワークであるローカルアクセスネットワークを介して接続される具体的な場合に有用である。そのようなシナリオで、必要なＵＭＴＳ資源パラメータはＩＰレイヤで規定されるＱｏＳパラメータから生じなければならない。このため、“変換機能”と呼ばれるエンティティは、３ＧＰＰ標準の一部であるＵＭＴＳの制御プレーンアーキテクチュア内で定義されている。変換機能の仕事の１つはＵＭＴＳベアラサービス属性と外部ネットワークサービス制御プロトコルのＱｏＳパラメータとの間で変換を行うことである。本発明はＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換を行う変換機能での方法を提供する。
変換機能９０５或いは９１３はユーザ装置（ＵＥ）９０１或いはゲートウェイ９１７に置かれる。このことは図９に図示されている。両方の場合において、変換機能はＩＰベアラサービス（ＢＳ）管理９０３或いは９１１と、ＵＭＴＳのＢＳ管理９０７或いは９１５の両方と相互作用して、ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換を成し遂げている。ＵＥ９０１におけるＵＭＴＳのＢＳ管理と、ＧＳＭ発展型用のコアネットワークエンハンスドデータ（ＣＮ ＥＤＧＥ）９１８と、ゲートウェイ９１７とは互いの間で、また、外部のインスタンスとは変換機能を介してシグナリングを行い、ＵＭＴＳベアラサービスを確立し、変更する。ＩＰのＢＳ管理は標準的なＩＰメカニズムを用いてＩＰベアラサービスを管理する。ゲートウェイのＩＰのＢＳ管理はポリシー制御機能（Policy Control Function：ＰＣＦ）９０９と相互作用する。ＰＣＦは論理的なポリシー決定要素であり、標準的なＩＰメカニズムを用いてＩＰベアラレイヤにポリシーを実現する。ＴＥとＭＴについての機能性は、３ＧＰＰがまだＴＥとＭＴとの間の機能性分散を標準化していないので、ユーザ装置（ＵＥ）へと結合される。
ＵＥ或いはゲートウェイにおける変換機能はソフトウェア或いはハードウェアで実現される。ソフトウェアの場合には、それは、オペレーティングシステムのインストール可能な部分であるかもしれないＵＭＴＳドライバの一部である。或いは、ハードウェアの場合には、その変換機能はＵＭＴＳ ＰＣＭＣＩＡカード或いはモデムにおいて実施される。
図１０〜図１９はＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性に変換することを記述したフローチャートを図示したものである。ＵＭＴＳのＱｏＳ属性からＩＰのＱｏＳパラメータへの変換は図２０〜図２２に図示されている。
さて、図１０において、ＭＩＭＥパラメータこれがもしセットされているなら、変換機能を強化するのに用いることができる。ＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性へ変換する第１のステップでは、それ故に、ステップ１００１でＭＩＭＥパラメータがセットされているかどうかをチェックすることに関与する。もし、ＭＩＭＥパラメータがセットされていないなら、その対応する場合は図１１〜図１６を参照して詳細に検討する。もし、ＭＩＭＥパラメータがセットされているなら、ＭＩＭＥメディアタイプについてステップ１００３においてチェックがなされる。もし、ＭＩＭＥメディアタイプがオーディオ以外であるなら、その場合は図１１〜図１６を参照して検討する。もし、ＭＩＭＥメディアタイプがオーディオであるなら、ＭＩＭＥ符号化についてステップ１００５でチェックされる。もし、ＭＩＭＥ符号化が適合型マルチレート（ＡＭＲ）以外のものであるなら、その場合は図１１〜図１６を参照して検討する。もし、ＭＩＭＥ符号化がＡＭＲであるなら、その場合は図１３〜図１９を参照して検討する。
さて、図１１において、まず予想遅延範囲（ＥＤＢ：Expected-Delay-Bound）がセットされたかどうかをステップ１１０１でチェックする。もしＥＤＢがセットされているなら、ステップ１１０９において、トラフィッククラス、転送遅延、及びソース静的記述子（Source-statistics-descriptor）がＥＤＢを用いて決定される。ＥＤＢの値は会話クラスとストリーミングクラスとを区別するのに用いられる。さらに、保証ビットレートと最大ビットレートが、対応するＩＰのＱｏＳパラメータから、即ち、ステップ１１１１ではトークンレート（ｒ）から、ステップ１１０７ではピークレート（ｐ）から決定される。もし、ＳＤＵフォーマット情報（ＳＦＩ）がステップ１１１３でセットされるなら、それが用いられて、ステップ１１１５において、対応するＵＭＴＳ属性、即ち、ＳＤＵフォーマット情報を決定する。ＳＦＩがセットされないなら、ステップ１１０５では最大パケットサイズ（Ｍ）から最大ＳＤＵサイズを決定できる。
ＥＤＢがステップ１１０１でセットされていないなら、パケット処理優先度（ＰＨＰ：Packet-Handling-Priority）が用いられステップ１１０３においてトラフィッククラスとトラフィック処理優先度（Traffic-handling-priority）を決定する。ＰＨＰはインタラクティブクラスとバックグラウンドクラスとの間を区別するために用いることもできる。最大ＳＤＵサイズはステップ１１０５において最大パケットサイズから決定され、ステップ１１０７で最大ビットレートはピークレートから決定される。
さて、図１２では、ＵＭＴＳ属性の配信順序とエラーＳＤＵの配信とが、ステップ１２０１において用いられるトランスポートプロトコルについての情報を用いて決定される。一例として、ＵＤＰ関連情報はエラーＳＤＵが配信されるべきであることを指示したり、ＳＤＵの配信を順番通りに行うことが要求されていないことを示したりできる。
さて、図１３では、ＳＤＵエラー率と残存ビットエラー率との値がＩＰにおける対応するパラメータ、即ち、パケット損失率（ＰＬＲ：Packet-Loss-Ratio）とビットエラー率（ＢＥＲ：Bit-Error-Ratio）とを用いて決定される。ＰＬＲがセットされているかどうかを決定するためのチェックがステップ１３０１において、ＢＥＲがセットされているかどうかを決定するためのチェックがステップ１３０３或いは１３０５においてなされる。ＰＬＲとＢＥＲとの両方がセットされるなら、ＰＬＲが用いられてＳＤＵエラー率を決定し、ＢＥＲが用いられて残存ビットエラー率を決定する。パラメータの１つだけがセットされるなら、それがＳＤＵエラー率と残存ビットエラー率の両方を決定するのに用いられる。パラメータのどれもがセットされていないなら、デフォルト値が用いられてステップ１３０７ではこれらの属性をセットする。その詳細は図１４〜図１６で図示されている。
図１４は、ＢＥＲのみを用いてＳＤＵエラー率と残存ビットエラー率を決定することを図示している。
まず、エラーＳＤＵの配信に（Ｙｅｓ／Ｎｏ）がセットされているか、或いは（−）がセットされているかを決定するチェック（即ち、エラー検出がなされるかどうか）がステップ１４０１においてなされる。もし、エラーＳＤＵの配信に（−）がセットされているなら、エラー検出はなされず、そして、ＳＤＵエラー率はセットされない。この場合、全ビットエラー率を定義する残存ビットエラー率は、ステップ１４０３においてＢＥＲから決定される。異なるトラフィッククラスに関し、ＢＥＲの残存ビットエラー率へのマッピングは異なっていても良い。これに対して、エラーＳＤＵの配信に（Ｙｅｓ／Ｎｏ）がセットされるなら、ＳＤＵエラー率の値はまた、ステップ１４０５において同様の方法で、ＢＥＲとトラフィッククラスについての情報とから決定される。残存ビットエラー率は未検出のビットエラー率を定義する。
上述の方法は、一様ではないエラー防止（ＵＥＰ：unequal error protection）をサポートするために各無線アクセスベアラ（ＲＡＢ）のサブフローに関して用いられる。ＵＥＰは、ＩＰのペイロードの異なる部分が、空中インタフェースにより転送を行うとき、異なるエラー防止メカニズムと関連付けられることを示唆する。ＵＥＰは基幹となる無線ベアラサービスによりサポートされる。このことは３ＧＰＰ ＴＳ ２３．１０７においてさらに詳述される。
図１５はＰＬＲのみを用いてＳＤＵエラー率と残存ビットエラー率を決定することを図示している。その手順は、上述の図１４を参照して検討した場合と類似している。
図１６はＰＬＲとＢＥＲとを用いて、ＳＤＵエラー率と残存ビットエラー率を夫々決定することを図示している。その手順は、上述の図１４を参照して検討した場合と類似している。
上述の検討全ては、ＭＩＭＥパラメータがステップ１００１でセットされていないときに、ＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性へと変換することに係わるものであった。もしＭＩＭＥパラメータがセットされているなら、これらのパラメータを用いてＵＭＴＳにおけるより最適化されたベアラサービスを達成することが可能である。１つの具体的な事例は、ＡＭＲコーデックが用いられてオーディオコンテンツを符号化する場合である。この具体的な事例は図１３〜図１６に続く図１７〜図１９で詳細に検討する。
さて、図１７において、ＥＤＢとＡＭＲ固有のＭＩＭＥパラメータmaxptimeがセットされているかどうかを判断するチェックがステップ１７０１でなされる。もし、ＥＤＢとmaxptimeとの内、少なくともいずれかがセットされているなら、ＥＤＢ或いはmaxptimeが、或いはＥＤＢとmaxptimeの両方が用いられて、ステップ１７０５において、トラフィッククラス、転送遅延、ソース静的記述子を決定する。ＥＤＢとmaxptimeとの内、少なくともいずれかが用いられて会話クラスとストリーミングクラスとを区別する。もし、ステップ１７０１において、これらのパラメータの内のただ１つがセットされているなら、そのパラメータが用いられてステップ１７０５において属性をセットする。ステップ１７０１において、いずれのパラメータもセットされていないなら、ステップ１７０３でデフォルト値によりその属性がセットされる。
さて、図１８において、ＵＭＴＳベアラは、もしＩＰパケットの正確なペイロードフォーマットを知ることができ、対応するＵＭＴＳ属性にマップされるなら、より良いサービスを提供するためにさらに最適化される。もしＡＭＲパラメータがセットされているなら、ステップ１８０１でモードセットについてチェックがなされる。もし、それがセットされているなら、最大ＳＤＵサイズ、ＳＤＵフォーマット情報、最大ビットレート、及び保証ビットレートがステップ１８０３において、モードセットとmaxptimeとから決定される、もし、ステップ１８０１においてモードセットがセットされていないなら、最大ＳＤＵサイズとＳＤＵフォーマット情報とがステップ１８０５においてＳＦＩと最大パケットサイズとから決定される。さらに、ステップ１８０７において、最大ビットレートと保証ビットレートとがピークレートとトークンレートとから夫々決定される。
さて、図１９において、ＵＭＴＳ属性の配信順序が、ステップ１９０１において、用いられるトランスポートプロトコルについての情報を用いて決定される。エラーＳＤＵの配信は、ステップ１９０３において、用いられるトランスポートプロトコルについての情報とＳＤＵフォーマット情報とＡＭＲ固有のＭＩＭＥパラメータｃｒｃとを用いて決定される。
エラーＳＤＵの配信がセットされた後、ＳＤＵエラー率と残存ビットエラー率の値がＩＰにおける対応するパラメータ、即ち、ＰＬＲとＢＥＲとを用いて決定される。このことは図１３〜図１６において詳細に図示されており、前の検討において既に検討したことである。
ＩＰのＱｏＳパラメータからＵＭＴＳのＱｏＳ属性への変換について詳細に検討したので、次に、図２０〜図２２ではＵＭＴＳのＱｏＳ属性からＩＰのＱｏＳパラメータへの変換について図示する。この変換は、ＵＭＴＳのＱｏＳ属性を用いてＭＩＭＥパラメータの値を決定するのが不可能であることを仮定している。それ故に、ＩＰのＱｏＳのIntServ ＣＬと無線ヒントのパラメータだけが決定される。
さて、図２０において、まず、ステップ２００１ではトラフィッククラスがチェックされて、それがストリーミング／会話型であるか、或いは、バックグラウンド／インタラクティブ型であるのかを見出す。ストリーミングと会話クラスである場合、ＥＤＢがステップ２００３でセットされる一方、バックグラウンドとインタラクティブクラスに対しては、ステップ２００７においてＰＨＰがセットされる。ＥＤＢとＰＨＰとは、対応するＵＭＴＳ属性、即ち、転送遅延とトラフィック処理優先度とから夫々決定される。ピークレートとトークンレートとが、ステップ２０１１では対応するＵＭＴＳパラメータである最大ビットレートから、ステップ２００５では保証ビットレートから、夫々決定される。ただし例外として、そのトラフィックがインタラクティブ或いはバックグラウンドであるときを除く。インタラクティブ或いはバックグラウンドである場合には、トークンレートがステップ２００９において最大ビットレートから決定される。これは保証ビットレートがインタラクティブ／バックグラウンドクラスの場合にはセットされていないためである。
さて、図２１において、ステップ２１０１では、最大パケットサイズとＳＦＩとを決定するためにＳＤＵフォーマット情報についてチェックがなされる。最大パケットサイズとＳＦＩとは、ＳＤＵフォーマット情報を用いて、ステップ２１０３と２１０５で夫々、決定される。ＳＤＵフォーマット情報がセットされていない場合、最大パケットサイズがステップ２１０７において最大ＳＤＵサイズを用いてセットされる。
最後に、ＳＤＵエラー率と残存ビットエラー率とを用いてＰＬＲとＢＥＲの値が決定される。このことは図２２に詳細に図示されている。もし多数の無線アクセスベアラ（ＲＡＢ）のサブフローが用いられるなら、そして、各サブフローに対してＳＤＵエラー率と残存ビットエラー率との内、少なくともいずれかの異なる値が指定されるなら、図２２に図示した方法が各ＲＡＢサブフローに用いられる。
最初に、ステップ２２０１では、エラーＳＤＵの配信に（Ｙｅｓ／Ｎｏ）がセットされているかどうか（即ち、エラー検出は適用されているかどうか）が判断される。もし、エラーＳＤＵの配信に（Ｙｅｓ／Ｎｏ）がセットされているなら、ＰＬＲとＢＥＲとが、ステップ２２０５では対応するＵＭＴＳ属性であるＳＤＵエラー率から、ステップ２２０７では残存ビットエラー率から夫々決定される。ＰＬＲへのＳＤＵエラー率のマッピングとＢＥＲへの残存ビットエラー率のマッピングとはまた、トラフィッククラスにも依存している。もし、エラーＳＤＵの配信に（−）がセットされているなら、ＳＤＵエラー率はＵＭＴＳにはセットされない。それ故に、残存ビットエラー率とトラフィッククラスだけが用いられ、上述したような方法で、ステップ２２０３においてＰＬＲとＢＥＲとをセットする。
本発明の好適な実施例について説明したが、当業者が本願発明の基本的な概念を一旦理解したなら、当業者はその実施例への付加的な変更や変形を行うかもしれない。好適な実施例の説明において述べた種々のパラメータについての値は単に例示的な性質のものであるに過ぎない。それ故に、添付した請求の範囲には、好適な実施例と、本発明の精神と範囲との中に入るそのような変更や変形の全てとの両方を含むと解釈されるべきであることが意図されている。
Claims (58)
- ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換の方法であって、前記方法は、
ａ．ＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性に変換する工程と、
ｂ．ＵＭＴＳのＱｏＳ属性をＩＰのＱｏＳパラメータに変換する工程とを有することを特徴とする方法。 - ＩＰのＱｏＳパラメータは無線ヒントを含むことを特徴とする請求項１に記載の方法。
- 前記ＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性に変換する工程は、
ａ．ＭＩＭＥパラメータについてチェックする工程と、
ｂ．もしＭＩＭＥパラメータがセットされていないなら、制御された負荷パラメータと無線ヒントとを用いてＵＭＴＳのＱｏＳ属性を決定し、もしＭＩＭＥパラメータがセットされているなら、制御された負荷パラメータと無線ヒントとＭＩＭＥパラメータとを用いてＵＭＴＳのＱｏＳ属性を決定する工程とを有することを特徴とする請求項１に記載の方法。 - 前記ＭＩＭＥパラメータについてチェックする工程はさらに、
ａ．もしＭＩＭＥパラメータがセットされているなら、ＭＩＭＥメディアタイプをチェックする工程と、
ｂ．もしＭＩＭＥメディアタイプがオーディオであるなら、ＡＭＲについてのＭＩＭＥ符号化をチェックする工程とを有することを特徴とする請求項３に記載の方法。 - もしＭＩＭＥパラメータがセットされていないなら、或いは、もしＭＩＭＥパラメータがセットされておりＭＩＭＥメディアタイプがオーディオ以外であるなら、或いは、もしＭＩＭＥパラメータがセットされておりＭＩＭＥメディアタイプがオーディオでありＭＩＭＥ符号化がＡＭＲ以外であるなら、前記ＵＭＴＳのＱｏＳ属性を決定する工程はさらに、
ａ．予想遅延範囲、パケット処理優先度、ＳＦＩ、最大パケットサイズ、トークンレート、及びピークレートを用いて、トラフィッククラス、転送遅延、ソース静的記述子、トラフィック処理優先度、保証ビットレート、最大ビットレート、最大ＳＤＵサイズ、及びＳＤＵフォーマット情報を決定する工程と、
ｂ．用いられるトランスポートプロトコルについての情報を用いて、配信順序、及びエラーＳＤＵの配信を決定する工程と、
ｃ．パケット損失率とビットエラー率とを用いて、ＳＤＵエラー率と残存ビットエラー率とを決定する工程とを有することを特徴とする請求項３又は４に記載の方法。 - 前記予想遅延範囲、パケット処理優先度、ＳＦＩ、最大パケットサイズ、トークンレート、及びピークレートを用いて、トラフィッククラス、転送遅延、ソース静的記述子、トラフィック処理優先度、保証ビットレート、最大ビットレート、最大ＳＤＵサイズ、及びＳＤＵフォーマット情報を決定する工程はさらに、
ａ．予想遅延範囲がセットされたかどうかをチェックする工程と、
ｂ．もし予想遅延範囲がセットされたなら、予想遅延範囲、トークンレート、ＳＦＩ、最大パケットサイズ、及びピークレートを用いて、トラフィッククラス、転送遅延、ソース静的記述子、保証ビットレート、最大ビットレート、最大ＳＤＵサイズ、及びＳＤＵフォーマット情報を決定する工程と、
ｃ．もし予想遅延範囲がセットされていないなら、パケット処理優先度、最大パケットサイズ、及びピークレートを用いて、トラフィッククラス、トラフィック処理優先度、最大ＳＤＵサイズ、及び最大ビットレートを決定する工程とを有することを特徴とする請求項５に記載の方法。 - 前記パケット損失率とビットエラー率とを用いて、ＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．パケット損失率がセットされたかどうかをチェックする工程と、
ｂ．ビットエラー率がセットされたかどうかをチェックする工程と、
ｃ．もしパケット損失率とビットエラー率とがセットされていないなら、所定の値を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｄ．もしパケット損失率がセットされておらずビットエラー率がセットされているなら、ビットエラー率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｅ．もしパケット損失率がセットされておりビットエラー率がセットされていないなら、パケット損失率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｆ．もしパケット損失率とビットエラー率とがセットされているなら、パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程とを有することを特徴とする請求項５に記載の方法。 - 前記もしパケット損失率がセットされておらずビットエラー率がセットされているなら、ビットエラー率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項７に記載の方法。 - 前記もしパケット損失率がセットされておりビットエラー率がセットされていないなら、パケット損失率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、パケット損失率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、パケット損失率とトラフィッククラスとを用いて残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項７に記載の方法。 - 前記もしパケット損失率とビットエラー率とがセットされているなら、パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ビットエラー率とパケット損失率とトラフィッククラスとを用いて、残存ビットエラー率とＳＤＵエラー率を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項７に記載の方法。 - 前記制御された負荷パラメータと無線ヒントとを用いてＵＭＴＳのＱｏＳ属性を決定する工程は、もしＭＩＭＥメディアタイプがオーディオであり、ＭＩＭＥ符号化がＡＭＲであるなら、さらに、
ａ．予想遅延範囲とmaxptimeの内の１つがセットされるか、或いは予想遅延範囲とmaxptimeの両方がセットされるなら、予想遅延範囲とmaxptimeの内の１つの少なくともいずれかを用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程と、
ｂ．予想遅延範囲とmaxptimeがセットされないなら、所定の値を用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程と、
ｃ．モードセット、maxptime、ＳＦＩ、最大パケットサイズ、ピークレート、及びトークンレートを用いて、最大ビットレート、保証ビットレート、ＳＤＵフォーマット情報、及び最大ＳＤＵサイズを決定する工程と、
ｄ．用いられるトランスポートプロトコルについての情報を用いて配信順序を決定する工程と、
ｅ．用いられるトランスポートプロトコルについての情報とＳＤＵフォーマット情報とｃｒｃとを用いてエラーＳＤＵの配信を決定する工程と、
ｆ．パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程とを有することを特徴とする請求項３及び４に記載の方法。 - 前記予想遅延範囲とmaxptimeの内の１つがセットされるか、或いは予想遅延範囲とmaxptimeの両方がセットされるなら、予想遅延範囲とmaxptimeの内の１つの少なくともいずれかを用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程はさらに、
ａ．予想遅延範囲とmaxptimeとの内の少なくともいずれかがセットされたかどうかをチェックする工程と、
ｂ．もし予想遅延範囲がセットされmaxptimeがセットされていないなら、予想遅延範囲を用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程と、
ｃ．もし予想遅延範囲がセットされておらずmaxptimeがセットされているなら、maxptimeを用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程と、
ｄ．もし予想遅延範囲とmaxptimeがセットされているなら、予想遅延範囲とmaxptimeとの内少なくともいずれかを用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程とを有することを特徴とする請求項１１に記載の方法。 - 前記モードセット、maxptime、ＳＦＩ、最大パケットサイズ、ピークレート、及びトークンレートを用いて、最大ビットレート、保証ビットレート、ＳＤＵフォーマット情報、及び最大ＳＤＵサイズを決定する工程はさらに、
ａ．モードセットがセットされたかどうかをチェックする工程と、
ｂ．もしモードセットがセットされているなら、maxptimeとモードセットとを用いて、最大ＳＤＵサイズ、ＳＤＵフォーマット情報、最大ビットレート、及び保証ビットレートを決定する工程と、
ｃ．もしモードセットがセットされていないなら、ＳＦＩと最大パケットサイズとを用いて、ＳＤＵフォーマット情報と最大ＳＤＵサイズとを決定する工程と、
ｄ．もしモードセットがセットされていないなら、ピークレートとトークンレートとを用いて、最大ビットレートと保証ビットレートとを決定する工程とを有することを特徴とする請求項１１に記載の方法。 - 前記パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．パケット損失率がセットされたかどうかをチェックする工程と、
ｂ．ビットエラー率がセットされたかどうかをチェックする工程と、
ｃ．もしパケット損失率とビットエラー率とがセットされていないなら、所定の値を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｄ．もしパケット損失率がセットされておらずビットエラー率がセットされているなら、ビットエラー率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｅ．もしパケット損失率がセットされておりビットエラー率がセットされていないなら、パケット損失率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｆ．もしパケット損失率とビットエラー率とがセットされているなら、パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程とを有することを特徴とする請求項１１に記載の方法。 - 前記もしパケット損失率がセットされておらずビットエラー率がセットされているなら、ビットエラー率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項１４に記載の方法。 - 前記もしパケット損失率がセットされておりビットエラー率がセットされていないなら、パケット損失率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、パケット損失率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、パケット損失率とトラフィッククラスとを用いて残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項１４に記載の方法。 - 前記もしパケット損失率とビットエラー率とがセットされているなら、パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ビットエラー率とパケット損失率とトラフィッククラスとを用いて、残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項１４に記載の方法。 - 前記ＵＭＴＳのＱｏＳ属性をＩＰのＱｏＳパラメータに変換する工程は、
ａ．トラフィッククラス、転送遅延、トラフィック処理優先度、保証ビットレート、及び最大ビットレートを用いて、予想遅延範囲、パケット処理優先度、トークンレート、及びピークレートを決定する工程と、
ｂ．最大ＳＤＵサイズとＳＤＵフォーマット情報とを用いて、最大パケットサイズとＳＦＩとを決定する工程と、
ｃ．残存ビットエラー率とＳＤＵエラー率とを用いて、パケット損失率とビットエラー率とを決定する工程とを有することを特徴とする請求項１に記載の方法。 - 前記トラフィッククラス、転送遅延、トラフィック処理優先度、保証ビットレート、及び最大ビットレートを用いて、予想遅延範囲、パケット処理優先度、トークンレート、及びピークレートを決定する工程はさらに、
ａ．トラフィッククラスについてチェックする工程と、
ｂ．もしトラフィッククラスがストリーミング或いは会話型であるなら、保証ビットレートを用いて、トークンレートを決定する工程と、
ｃ．もしトラフィッククラスがストリーミング或いは会話型であるなら、最大ビットレートを用いて、ピークレートを決定する工程と、
ｄ．もしトラフィッククラスがストリーミング或いは会話型であるなら、転送遅延を用いて予想遅延範囲を決定する工程と、
ｅ．もしトラフィッククラスがバックグランド或いはインタラクティブであるなら、最大ビットレートを用いて、トークンレートを決定する工程と、
ｆ．もしトラフィッククラスがバックグランド或いはインタラクティブであるなら、最大ビットレートを用いて、ピークレートを決定する工程と、
ｇ．もしトラフィッククラスがバックグランド或いはインタラクティブであるなら、トラフィック処理優先度を用いて、パケット処理優先度を決定する工程を有することを特徴とする請求項１８に記載の方法。 - 前記最大ＳＤＵサイズとＳＤＵフォーマット情報とを用いて、最大パケットサイズとＳＦＩとを決定する工程はさらに、
ａ．ＳＤＵフォーマット情報がセットされたかどうかをチェックする工程と、
ｂ．もしＳＤＵフォーマット情報がセットされたなら、ＳＤＵフォーマット情報を用いて、最大パケットサイズを決定する工程と、
ｃ．もしＳＤＵフォーマット情報がセットされたなら、ＳＤＵフォーマット情報を用いて、ＳＦＩを決定する工程と、
ｄ．もしＳＤＵフォーマット情報がセットされていないなら、最大ＳＤＵサイズを用いて、最大パケットサイズを決定する工程とを有することを特徴とする請求項１８に記載の方法。 - 前記残存ビットエラー率とＳＤＵエラー率とを用いて、パケット損失率とビットエラー率とを決定する工程はさらに、
ａ．多数の無線アクセスベアラ（ＲＡＢ）のサブフローと、ＳＤＵエラー率と残存ビットエラー率との内の少なくともいずれかの異なる値が、前記サブフロー各々についてセットされていないなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、残存ビットエラー率とトラフィッククラスとを用いてパケット損失率とビットエラー率とを決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、残存ビットエラー率とＳＤＵエラー率とトラフィッククラスとを用いて、パケット損失率とビットエラー率とを決定する工程とを実行し、
ｂ．もしＳＤＵエラー率と残存ビットエラー率との内の少なくともいずれかの異なる値が前記サブフロー各々についてセットされているなら、全てのＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項１８に記載の方法。 - ＩＰのＱｏＳパラメータとＵＭＴＳのＱｏＳ属性との間の変換を行う、無線ネットワークとの通信を行うネットワークノード装置における方法であって、前記方法は、
ａ．ＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性に変換する工程と、
ｂ．ＵＭＴＳのＱｏＳ属性をＩＰのＱｏＳパラメータに変換する工程とを有することを特徴とする方法。 - 前記ネットワークノード装置はユーザ装置であることを特徴とする請求項２２に記載のネットワークノード装置における方法。
- 前記ネットワークノード装置はゲートウェイであることを特徴とする請求項２２に記載のネットワークノード装置における方法。
- ＩＰのＱｏＳパラメータは無線ヒントを含むことを特徴とする請求項２２に記載のネットワークノード装置における方法。
- 前記ＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性に変換する工程は、
ａ．ＭＩＭＥパラメータについてチェックする工程と、
ｂ．もしＭＩＭＥパラメータがセットされていないなら、制御された負荷パラメータと無線ヒントとを用いてＵＭＴＳのＱｏＳ属性を決定する工程と、
ｃ．もしＭＩＭＥパラメータがセットされているなら、制御された負荷パラメータと無線ヒントとＭＩＭＥパラメータとを用いてＵＭＴＳのＱｏＳ属性を決定する工程とを有することを特徴とする請求項２２に記載のネットワークノード装置における方法。 - 前記ＭＩＭＥパラメータについてチェックする工程はさらに、
ａ．もしＭＩＭＥパラメータがセットされているなら、ＭＩＭＥメディアタイプをチェックする工程と、
ｂ．もしＭＩＭＥメディアタイプがオーディオであるなら、ＡＭＲについてのＭＩＭＥ符号化をチェックする工程とを有することを特徴とする請求項２６に記載のネットワークノード装置における方法。 - もしＭＩＭＥパラメータがセットされていないなら、前記ＵＭＴＳのＱｏＳ属性を決定する工程はさらに、
ａ．予想遅延範囲、パケット処理優先度、ＳＦＩ、最大パケットサイズ、トークンレート、及びピークレートを用いて、トラフィッククラス、転送遅延、ソース静的記述子、トラフィック処理優先度、保証ビットレート、最大ビットレート、最大ＳＤＵサイズ、及びＳＤＵフォーマット情報を決定する工程と、
ｂ．用いられるトランスポートプロトコルについての情報を用いて、配信順序、及びエラーＳＤＵの配信を決定する工程と、
ｃ．パケット損失率とビットエラー率とを用いて、ＳＤＵエラー率と残存ビットエラー率とを決定する工程とを有することを特徴とする請求項２６に記載のネットワークノード装置における方法。 - 前記予想遅延範囲、パケット処理優先度、ＳＦＩ、最大パケットサイズ、トークンレート、及びピークレートを用いて、トラフィッククラス、転送遅延、ソース静的記述子、トラフィック処理優先度、保証ビットレート、最大ビットレート、最大ＳＤＵサイズ、及びＳＤＵフォーマット情報を決定する工程はさらに、
ａ．予想遅延範囲がセットされたかどうかをチェックする工程と、
ｂ．もし予想遅延範囲がセットされたなら、予想遅延範囲、トークンレート、ＳＦＩ、最大パケットサイズ、及びピークレートを用いて、トラフィッククラス、転送遅延、ソース静的記述子、保証ビットレート、最大ビットレート、最大ＳＤＵサイズ、及びＳＤＵフォーマット情報を決定する工程と、
ｃ．もし予想遅延範囲がセットされていないなら、パケット処理優先度、最大パケットサイズ、及びピークレートを用いて、トラフィッククラス、トラフィック処理優先度、最大ＳＤＵサイズ、及び最大ビットレートを決定する工程とを有することを特徴とする請求項２８に記載のネットワークノード装置における方法。 - 前記パケット損失率とビットエラー率とを用いて、ＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．パケット損失率がセットされたかどうかをチェックする工程と、
ｂ．ビットエラー率がセットされたかどうかをチェックする工程と、
ｃ．もしパケット損失率とビットエラー率とがセットされていないなら、所定の値を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｄ．もしパケット損失率がセットされておらずビットエラー率がセットされているなら、ビットエラー率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｅ．もしパケット損失率がセットされておりビットエラー率がセットされていないなら、パケット損失率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｆ．もしパケット損失率とビットエラー率とがセットされているなら、パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程とを有することを特徴とする請求項２８に記載のネットワークノード装置における方法。 - 前記もしパケット損失率がセットされておらずビットエラー率がセットされているなら、ビットエラー率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項３０に記載のネットワークノード装置における方法。 - 前記もしパケット損失率がセットされておりビットエラー率がセットされていないなら、パケット損失率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、パケット損失率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、パケット損失率とトラフィッククラスとを用いて残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項３０に記載のネットワークノード装置における方法。 - 前記もしパケット損失率とビットエラー率とがセットされているなら、パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ビットエラー率とパケット損失率とトラフィッククラスとを用いて、残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項３０に記載のネットワークノード装置における方法。 - もしＭＩＭＲパラメータがセットされており、かつ、ＭＩＭＥメディアタイプがオーディオであり、ＭＩＭＥ符号化がＡＭＲであるなら、前記制御された負荷パラメータと無線ヒントとＭＩＭＥパラメータとを用いてＵＭＴＳのＱｏＳ属性を決定する工程はさらに、
ａ．予想遅延範囲とmaxptimeの内の１つがセットされるか、或いは予想遅延範囲とmaxptimeの両方がセットされるなら、予想遅延範囲とmaxptimeの内の１つの少なくともいずれかを用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程と、
ｂ．予想遅延範囲とmaxptimeとがセットされないなら、所定の値を用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程と、
ｃ．モードセット、maxptime、ＳＦＩ、最大パケットサイズ、ピークレート、及びトークンレートを用いて、最大ビットレート、保証ビットレート、ＳＤＵフォーマット情報、及び最大ＳＤＵサイズを決定する工程と、
ｄ．用いられるトランスポートプロトコルについての情報を用いて配信順序を決定する工程と、
ｅ．用いられるトランスポートプロトコルについての情報とＳＤＵフォーマット情報とｃｒｃとを用いてエラーＳＤＵの配信を決定する工程と、
ｆ．パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程とを有することを特徴とする請求項２６及び２７に記載のネットワークノード装置における方法。 - 前記予想遅延範囲とmaxptimeの内の１つがセットされるか、或いは予想遅延範囲とmaxptimeの両方がセットされるなら、予想遅延範囲とmaxptimeの内の１つの少なくともいずれかを用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程はさらに、
ａ．予想遅延範囲とmaxptimeとの内の少なくともいずれかがセットされたかどうかをチェックする工程と、
ｂ．もし予想遅延範囲がセットされmaxptimeがセットされていないなら、予想遅延範囲を用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程と、
ｃ．もし予想遅延範囲がセットされておらずmaxptimeがセットされているなら、maxptimeを用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程と、
ｄ．もし予想遅延範囲とmaxptimeがセットされているなら、予想遅延範囲とmaxptimeとの内、少なくともいずれかを用いて、トラフィッククラス、転送遅延、及びソース静的記述子を決定する工程とを有することを特徴とする請求項３４に記載のネットワークノード装置における方法。 - 前記モードセット、maxptime、ＳＦＩ、最大パケットサイズ、ピークレート、及びトークンレートを用いて、最大ビットレート、保証ビットレート、ＳＤＵフォーマット情報、及び最大ＳＤＵサイズを決定する工程はさらに、
ａ．モードセットがセットされたかどうかをチェックする工程と、
ｂ．もしモードセットがセットされているなら、maxptimeとモードセットとを用いて、最大ＳＤＵサイズ、ＳＤＵフォーマット情報、最大ビットレート、及び保証ビットレートを決定する工程と、
ｃ．もしモードセットがセットされていないなら、ＳＦＩと最大パケットサイズとを用いて、ＳＤＵフォーマット情報と最大ＳＤＵサイズとを決定する工程と、
ｄ．もしモードセットがセットされていないなら、ピークレートとトークンレートとを用いて、最大ビットレートと保証ビットレートとを決定する工程とを有することを特徴とする請求項３４に記載のネットワークノード装置における方法。 - 前記パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．パケット損失率がセットされたかどうかをチェックする工程と、
ｂ．ビットエラー率がセットされたかどうかをチェックする工程と、
ｃ．もしパケット損失率とビットエラー率とがセットされていないなら、所定の値を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｄ．もしパケット損失率がセットされておらずビットエラー率がセットされているなら、ビットエラー率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｅ．もしパケット損失率がセットされておりビットエラー率がセットされていないなら、パケット損失率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程と、
ｆ．もしパケット損失率とビットエラー率とがセットされているなら、パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程とを有することを特徴とする請求項３４に記載のネットワークノード装置における方法。 - 前記もしパケット損失率がセットされておらずビットエラー率がセットされているなら、ビットエラー率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項３７に記載のネットワークノード装置における方法。 - 前記もしパケット損失率がセットされておりビットエラー率がセットされていないなら、パケット損失率を用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、パケット損失率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、パケット損失率とトラフィッククラスとを用いて残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項３７に記載のネットワークノード装置における方法。 - 前記もしパケット損失率とビットエラー率とがセットされているなら、パケット損失率とビットエラー率とを用いてＳＤＵエラー率と残存ビットエラー率とを決定する工程はさらに、
ａ．もし無線アクセスベアラ（ＲＡＢ）のサブフローの数が１つであるなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、ビットエラー率とトラフィッククラスとを用いて残存ビットエラー率を決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ビットエラー率とパケット損失率とトラフィッククラスとを用いて、残存ビットエラー率とＳＤＵエラー率の両方を決定する工程とを実行し、
ｂ．もし２つ以上であるなら、各ＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項３７に記載のネットワークノード装置における方法。 - 前記ＵＭＴＳのＱｏＳ属性をＩＰのＱｏＳパラメータに変換する工程は、
ａ．トラフィッククラス、転送遅延、トラフィック処理優先度、保証ビットレート、及び最大ビットレートを用いて、予想遅延範囲、パケット処理優先度、トークンレート、及びピークレートを決定する工程と、
ｂ．最大ＳＤＵサイズとＳＤＵフォーマット情報とを用いて、最大パケットサイズとＳＦＩとを決定する工程と、
ｃ．残存ビットエラー率とＳＤＵエラー率とを用いて、パケット損失率とビットエラー率とを決定する工程とを有することを特徴とする請求項２４に記載のネットワークノード装置における方法。 - 前記トラフィッククラス、転送遅延、トラフィック処理優先度、保証ビットレート、及び最大ビットレートを用いて、予想遅延範囲、パケット処理優先度、トークンレート、及びピークレートを決定する工程はさらに、
ａ．トラフィッククラスについてチェックする工程と、
ｂ．もしトラフィッククラスがストリーミング或いは会話型であるなら、保証ビットレートを用いて、トークンレートを決定する工程と、
ｃ．もしトラフィッククラスがストリーミング或いは会話型であるなら、最大ビットレートを用いて、ピークレートを決定する工程と、
ｄ．もしトラフィッククラスがストリーミング或いは会話型であるなら、転送遅延を用いて予想遅延範囲を決定する工程と、
ｅ．もしトラフィッククラスがバックグランド或いはインタラクティブであるなら、最大ビットレートを用いて、トークンレートを決定する工程と、
ｆ．もしトラフィッククラスがバックグランド或いはインタラクティブであるなら、最大ビットレートを用いて、ピークレートを決定する工程と、
ｇ．もしトラフィッククラスがバックグランド或いはインタラクティブであるなら、トラフィック処理優先度を用いて、パケット処理優先度を決定する工程を有することを特徴とする請求項４１に記載のネットワークノード装置における方法。 - 前記最大ＳＤＵサイズとＳＤＵフォーマット情報とを用いて、最大パケットサイズとＳＦＩとを決定する工程はさらに、
ａ．ＳＤＵフォーマット情報がセットされたかどうかをチェックする工程と、
ｂ．もしＳＤＵフォーマット情報がセットされたなら、ＳＤＵフォーマット情報を用いて、最大パケットサイズを決定する工程と、
ｃ．もしＳＤＵフォーマット情報がセットされたなら、ＳＤＵフォーマット情報を用いて、ＳＦＩを決定する工程と、
ｄ．もしＳＤＵフォーマット情報がセットされていないなら、最大ＳＤＵサイズを用いて、最大パケットサイズを決定する工程とを有することを特徴とする請求項４１に記載のネットワークノード装置における方法。 - 前記トラフィッククラスとエラーＳＤＵの配信と残存ビットエラー率とＳＤＵエラー率とを用いて、パケット損失率とビットエラー率とを決定する工程はさらに、
ａ．多数の無線アクセスベアラ（ＲＡＢ）のサブフローと、ＳＤＵエラー率と残存ビットエラー率との内の少なくともいずれかの異なる値とが、前記サブフロー各々についてセットされていないなら、
ｉ． エラーＳＤＵの配信についてチェックする工程と、
ii． もしエラーＳＤＵの配信に（−）がセットされているなら、残存ビットエラー率とトラフィッククラスとを用いてパケット損失率とビットエラー率とを決定する工程と、
iii. もしエラーＳＤＵの配信に（イエス／ノー）がセットされているなら、ＳＤＵエラー率と残存ビットエラー率とトラフィッククラスとを用いて、パケット損失率とビットエラー率とを決定する工程とを実行し、
ｂ．もしＳＤＵエラー率と残存ビットエラー率との内の少なくともいずれかの異なる値が前記サブフロー各々についてセットされているなら、全てのＲＡＢのサブフローについて前記ａ．の工程を繰り返すことを特徴とする請求項４１に記載のネットワークノード装置における方法。 - ＩＰのＢＳ管理とＵＭＴＳのＢＳ管理とを含むネットワークノード装置であって、
ａ．前記ＩＰのＢＳ管理と前記ＵＭＴＳのＢＳ管理との間で、ＩＰのＱｏＳパラメータをＵＭＴＳのＱｏＳ属性に変換する第１の変換器と、
ｂ．前記ＩＰのＢＳ管理と前記ＵＭＴＳのＢＳ管理との間で、ＵＭＴＳのＱｏＳ属性をＩＰのＱｏＳパラメータに変換する第２の変換器とを有することを特徴するネットワークノード装置。 - 前記ネットワークノード装置はユーザ装置であることを特徴とする請求項４５に記載のネットワークノード装置。
- 前記ネットワークノード装置はゲートウェイであることを特徴とする請求項４５に記載のネットワークノード装置。
- 前記第１及び第２の変換器はコンピュータプログラムの一部であることを特徴とする請求項４５に記載のネットワークノード装置。
- 前記第１及び第２の変換器はハードウェアで実現されることを特徴とする請求項４５に記載のネットワークノード装置。
- 前記ハードウェアはＰＣＭＣＩＡカードであることを特徴とする請求項４９に記載のネットワークノード装置。
- 前記ハードウェアはモデムであることを特徴とする請求項４９に記載のネットワークノード装置。
- 前記ＩＰのＱｏＳパラメータは無線ヒントを含むことを特徴とする請求項４５に記載のネットワークノード装置。
- 前記ネットワークノード装置はユーザ装置であることを特徴とする請求項５２に記載のネットワークノード装置。
- 前記ネットワークノード装置はゲートウェイであることを特徴とする請求項５２に記載のネットワークノード装置。
- 前記第１及び第２の変換器はコンピュータプログラムの一部であることを特徴とする請求項５２に記載のネットワークノード装置。
- 前記第１及び第２の変換器はハードウェアで実現されることを特徴とする請求項５２に記載のネットワークノード装置。
- 前記ハードウェアはＰＣＭＣＩＡカードであることを特徴とする請求項５６に記載のネットワークノード装置。
- 前記ハードウェアはモデムであることを特徴とする請求項５７に記載のネットワークノード装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/138,240 US7206324B2 (en) | 2002-05-03 | 2002-05-03 | QoS translator |
| PCT/SE2003/000592 WO2003094447A1 (en) | 2002-05-03 | 2003-04-11 | A qos parameters translater |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2005525023A true JP2005525023A (ja) | 2005-08-18 |
| JP2005525023A5 JP2005525023A5 (ja) | 2006-05-11 |
| JP4309338B2 JP4309338B2 (ja) | 2009-08-05 |
Family
ID=29269284
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004502558A Expired - Fee Related JP4309338B2 (ja) | 2002-05-03 | 2003-04-11 | ＱｏＳパラメータ変換器 |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7206324B2 (ja) |
| EP (1) | EP1504573B1 (ja) |
| JP (1) | JP4309338B2 (ja) |
| CN (1) | CN100409640C (ja) |
| AT (1) | ATE457105T1 (ja) |
| AU (1) | AU2003224534A1 (ja) |
| DE (1) | DE60331186D1 (ja) |
| PL (1) | PL372994A1 (ja) |
| WO (1) | WO2003094447A1 (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008511193A (ja) * | 2004-08-06 | 2008-04-10 | クゥアルコム・インコーポレイテッド | マルチモード環境における異なる技術に関するＱｏＳのサポート |
| JP2010508744A (ja) * | 2006-11-07 | 2010-03-18 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | 負荷に依存したレート規制方法及びシステム |
| JP2012518335A (ja) * | 2009-02-13 | 2012-08-09 | クゥアルコム・インコーポレイテッド | ワイヤレスネットワーク間でハンドオーバー中にＱｏＳ変換するための方法及びシステム |
| JP2013534081A (ja) * | 2010-05-25 | 2013-08-29 | ヘッドウォーター パートナーズ Ｉ エルエルシー | ネットワーク容量を保護するためのデバイス支援サービス |
| JP5408332B2 (ja) * | 2010-03-10 | 2014-02-05 | 富士通株式会社 | 中継装置および通信プログラム |
| JP2014147115A (ja) * | 2008-05-20 | 2014-08-14 | Telefon Ab L M Ericsson | 区分エンティティおよび容量を区分するための方法 |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7379420B2 (en) * | 2001-12-28 | 2008-05-27 | Network Equipment Technologies, Inc. | Method and apparatus for multiple qualities of service to different network connections of a single network path |
| KR100776083B1 (ko) * | 2002-06-11 | 2007-11-15 | 엘지노텔 주식회사 | 이동통신 시스템의 데이터 호 트래픽 프레임 제어방법 |
| US7221682B2 (en) * | 2002-07-18 | 2007-05-22 | Lucent Technologies Inc. | Controller for allocation of processor resources and related methods |
| US20040121778A1 (en) * | 2002-10-08 | 2004-06-24 | Interdigital Technology Corporation | Quality of service mapping between various types of wireless communication systems |
| US20040184432A1 (en) * | 2003-03-19 | 2004-09-23 | Ralitsa Gateva | Method for controlling streaming services |
| US7701915B2 (en) * | 2003-06-27 | 2010-04-20 | Nokia Corporation | Method in a communication system, a communication system and a communication device |
| EP1553737B1 (en) * | 2004-01-06 | 2007-03-07 | Alcatel | A physical layer session resource broker |
| GB2413464A (en) * | 2004-04-21 | 2005-10-26 | Orange Sa | An inter-working unit with a protocol conversion or protocol encapsulation function, for use with dual stack user equipment on a packet radio network |
| CN100396054C (zh) * | 2004-04-30 | 2008-06-18 | 华为技术有限公司 | 通用移动通信系统内部与外部间传输业务流数据包的方法 |
| CN100420232C (zh) * | 2004-04-30 | 2008-09-17 | 华为技术有限公司 | 一种传输业务流数据包的方法 |
| EP1605641A1 (en) * | 2004-06-08 | 2005-12-14 | Matsushita Electric Industrial Co., Ltd. | Mapping of shared physical channels depending on the quality of service class |
| EP1605642A1 (en) * | 2004-06-08 | 2005-12-14 | Matsushita Electric Industrial Co., Ltd. | Service dependent shared physical channel mapping |
| CN100514961C (zh) * | 2004-08-02 | 2009-07-15 | 华为技术有限公司 | 一种网际协议服务质量的信令交互方法 |
| ZA200709025B (en) * | 2005-03-21 | 2009-09-30 | Ericsson Telefon Ab L M | Automatic QoS configuration |
| US8139598B2 (en) * | 2005-03-21 | 2012-03-20 | Telefonaktiebolaget L M Ericsson (Publ) | Automatic QoS configuration |
| KR101213932B1 (ko) * | 2005-05-17 | 2012-12-18 | 삼성전자주식회사 | 이종망 환경에서 종단간 서비스 품질 연동장치 및 그 방법 |
| EP1911222A1 (en) * | 2005-07-18 | 2008-04-16 | Starent Networks Corporation | Method and system for quality of service renegotiation |
| CN1929478B (zh) * | 2005-09-09 | 2010-05-05 | 华为技术有限公司 | 一种减少传输带宽占用的方法 |
| WO2008137432A2 (en) * | 2007-05-01 | 2008-11-13 | Dyyno | Sharing of information and formatting information for transmission over a communication network |
| EP2466791A1 (en) * | 2010-12-17 | 2012-06-20 | France Telecom | Data processing for managing the quality of service in a machine-to-machine network |
| US9819469B2 (en) | 2013-07-01 | 2017-11-14 | Qualcomm Incorporated | Techniques for enabling quality of service (QoS) on WLAN for traffic related to a bearer on cellular networks |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7023820B2 (en) * | 2000-12-28 | 2006-04-04 | Nokia, Inc. | Method and apparatus for communicating data in a GPRS network based on a plurality of traffic classes |
| US20010027490A1 (en) * | 2000-01-25 | 2001-10-04 | Gabor Fodor | RSVP handling in 3G networks |
| EP1120939B1 (en) | 2000-01-26 | 2008-12-31 | Telefonaktiebolaget LM Ericsson (publ) | Method, server and arrangement in a communication network |
| JP4536990B2 (ja) | 2000-05-22 | 2010-09-01 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | アプリケーション影響ポリシー |
| US7283502B1 (en) | 2000-09-21 | 2007-10-16 | Lucent Technologies Inc. | Enhancement of framing protocol frame format to support quality of service |
| DE60134305D1 (de) * | 2001-03-08 | 2008-07-17 | Lucent Technologies Inc | Verbessertes UMTS |
| US7796608B2 (en) * | 2001-03-20 | 2010-09-14 | Verizon Business Global Llc | Edge-based per-flow QoS admission control in a data network |
| NO20011465L (no) * | 2001-03-22 | 2002-09-23 | Ericsson Telefon Ab L M | Supplerende anropsgripetjeneste for mobilnett |
| US20020184510A1 (en) * | 2001-04-17 | 2002-12-05 | At&T Wireless Services, Inc. | Binding information for IP media flows |
| EP1294202A1 (en) * | 2001-09-18 | 2003-03-19 | Lucent Technologies Inc. | A method of sending data packets through a MPLS network, and a MPLS network |
| US6661780B2 (en) * | 2001-12-07 | 2003-12-09 | Nokia Corporation | Mechanisms for policy based UMTS QoS and IP QoS management in mobile IP networks |
-
2002
- 2002-05-03 US US10/138,240 patent/US7206324B2/en not_active Expired - Fee Related
-
2003
- 2003-04-11 DE DE60331186T patent/DE60331186D1/de not_active Expired - Fee Related
- 2003-04-11 JP JP2004502558A patent/JP4309338B2/ja not_active Expired - Fee Related
- 2003-04-11 AT AT03721192T patent/ATE457105T1/de not_active IP Right Cessation
- 2003-04-11 PL PL03372994A patent/PL372994A1/xx not_active Application Discontinuation
- 2003-04-11 AU AU2003224534A patent/AU2003224534A1/en not_active Abandoned
- 2003-04-11 CN CNB038098849A patent/CN100409640C/zh not_active Expired - Fee Related
- 2003-04-11 EP EP03721192A patent/EP1504573B1/en not_active Expired - Lifetime
- 2003-04-11 WO PCT/SE2003/000592 patent/WO2003094447A1/en active Application Filing
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008511193A (ja) * | 2004-08-06 | 2008-04-10 | クゥアルコム・インコーポレイテッド | マルチモード環境における異なる技術に関するＱｏＳのサポート |
| JP2010508744A (ja) * | 2006-11-07 | 2010-03-18 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | 負荷に依存したレート規制方法及びシステム |
| JP2014147115A (ja) * | 2008-05-20 | 2014-08-14 | Telefon Ab L M Ericsson | 区分エンティティおよび容量を区分するための方法 |
| US9204333B2 (en) | 2008-05-20 | 2015-12-01 | Telefonaktiebolaget L M Ericsson (Publ) | Partitioning entity and method for partitioning capacity |
| JP2012518335A (ja) * | 2009-02-13 | 2012-08-09 | クゥアルコム・インコーポレイテッド | ワイヤレスネットワーク間でハンドオーバー中にＱｏＳ変換するための方法及びシステム |
| US9100880B2 (en) | 2009-02-13 | 2015-08-04 | Qualcomm Incorporated | Methods and systems for QoS translation during handover between wireless networks |
| JP5408332B2 (ja) * | 2010-03-10 | 2014-02-05 | 富士通株式会社 | 中継装置および通信プログラム |
| US8942619B2 (en) | 2010-03-10 | 2015-01-27 | Fujitsu Limited | Relay device |
| JP2013534081A (ja) * | 2010-05-25 | 2013-08-29 | ヘッドウォーター パートナーズ Ｉ エルエルシー | ネットワーク容量を保護するためのデバイス支援サービス |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2003094447A1 (en) | 2003-11-13 |
| DE60331186D1 (de) | 2010-03-25 |
| CN100409640C (zh) | 2008-08-06 |
| AU2003224534A1 (en) | 2003-11-17 |
| EP1504573A1 (en) | 2005-02-09 |
| EP1504573B1 (en) | 2010-02-03 |
| US7206324B2 (en) | 2007-04-17 |
| ATE457105T1 (de) | 2010-02-15 |
| PL372994A1 (en) | 2005-08-08 |
| CN1650585A (zh) | 2005-08-03 |
| US20030208582A1 (en) | 2003-11-06 |
| JP4309338B2 (ja) | 2009-08-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4309338B2 (ja) | ＱｏＳパラメータ変換器 | |
| US7230921B2 (en) | Concurrent use of communication paths in a multi-path access link to an IP network | |
| EP1368980B1 (en) | Method for assigning values of service attributes to transmissions, radio access networks and network elements | |
| US20040131078A1 (en) | Apparatus and method for supporting multiple wireless technologies within a device | |
| Räisänen | Implementing service quality in IP networks | |
| JP2013504271A (ja) | 通信サービスのＩＰ相互接続におけるネットワーク間インターフェース上のサービス品質（ＱｏＳ） | |
| Guo et al. | Providing end-to-end QoS for multimedia applications in 3G wireless networks | |
| EP1387533A1 (en) | Communication of packet data units over signalling and traffic channels | |
| EP1381198B1 (en) | Convergence layers for network devices and method for transmitting data traffic | |
| Laukkanen | UMTS quality of service concept and architecture | |
| Maniatis et al. | End-to-end quality of service issues over next generation mobile Internet | |
| Ricardo et al. | Support of IP QoS over UMTS networks | |
| WO2008014897A1 (en) | Method and system for radio resource management in geran/umts networks, related network and computer program product | |
| Manner | Provision of Quality of Service in IP-based Mobile Access Networks | |
| Kassler et al. | BRENTA-supporting mobility and quality of service for adaptable multimedia communication | |
| Chioariu | QoS in UMTS | |
| Honkasalo et al. | UMTS Quality of Service | |
| Wallbaum et al. | Voice-data integration in wireless communication networks | |
| Seth | Quality of Service (QoS) in CDMA2000-based Wireless IP Networks | |
| Prior | Scalable Network Architectures Supporting Quality of Service | |
| Madisetti et al. | Transport layer QoS management for wireless multimedia services | |
| Andersen et al. | Feasibility study of VoIP in 3GPP UMTS release 5 interworking with fixed networks | |
| Al-Zahid et al. | A Dynamic QoS-aware transmission for emergency traffic in IP networks | |
| Yalli et al. | An improved QoS in the architecture, model and huge traffic of multi-media applications under high speed wireless campus network | |
| Brunner | Basic internet technology in support of communication services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060310 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060310 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080626 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080704 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081003 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090410 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090507 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4309338 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120515 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120515 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130515 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140515 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |