JP2006513630A - パケットサービスシステム及びパケット転送制御方法 - Google Patents

Abstract

パケットサービスシステム及びパケット転送制御方法を提供する。本発明による実時間データ伝達方法は、データソースから有線通信線及び無線通信線を備えた通信ネットワークと通信するモバイルデバイスでリアルタイムデータを伝達する方法において、前記有線通信線を介して前記データソースから前記リアルタイムデータを受信するステップと、制御情報を生成するために、前記有線通信線に対するパケット損失を決定するステップと、前記制御情報を前記データソースに転送するステップと、前記制御情報に基づき、前記リアルタイムデータを前記モバイルデバイスに転送するステップとを含むことを特徴とする。

Description

本発明は通信システムに関し、特に、パケットサービスシステム及びパケット転送制御方法に関する。

セルラー通信分野での熟練者は１Ｇ、２Ｇ、３Ｇのような用語をよく使用する。この用語は使用されるセルラー通信の世代を言及する。１Ｇは第１世代、２Ｇは第２世代、３Ｇは第３世代を言及する。１ＧはＡＭＰＳ(Ａｄｖａｎｃｅｄ Ｍｏｂｉｌｅ Ｐｈｏｎｅ Ｓｅｒｖｉｃｅ)で知らされたアナログ電話システムを言及するのに使用される。２Ｇは全世界に広く拡散されているデジタルセルラーシステムを言及するのに使用され、ＣＤＭＡＯｎｅ、ＧＳＭ(Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌ ｅｃｏｍｍｕｎｉｃａｔｉｏｎ)及びＴＤＭＡ(Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ)を含む。２Ｇシステムは１Ｇシステムより過密領域でのユーザの支援数が多い。通常、３Ｇは現在開発中にあるデジタルセルラーシステムを言及するのに使用される。最近、第３世代(３Ｇ)ＣＤＭＡ通信システムは、ｃｄｍａ２０００及びＷ-ＣＤＭＡなどを含みながら提案されている。これらの３Ｇ通信システムは、一部重要な差異を持つが、互いに概念的には類似している。

Ｗ-ＣＤＭＡシステムは、インターネット及びイントラネットアクセス、マルチメディアアプリケーション、高速ビジネストランザクション、並びにテレメトリーのようなデータ収容能力を容易にするためのＣＤＭＡ技術が強化されたサービス潜在力を使用する第３世代(３Ｇ)ワイドバント、非同期、拡散スペクトラム無線インターフェースシステムである。他の第３世代システムの一つとしてＷ-ＣＤＭＡの焦点は、無線スペクトラム利用可能性の有限な量の制限を克服するためのネットワーク経済性及び無線送信設計にある。

現在、提案されているＷ-ＣＤＭＡシステムの標準下において、基地局の各々は非同期式に動作する。換言すれば、個別基地局間に汎用時間基準がない。Ｗ-ＣＤＭＡシステムにおいて、各基地局は２つのサブチャンネルを含む“同期式”チャンネルを転送する。

２つのサブチャンネルのうち、第１チャンネル即ち第１同期チャンネルは、全ての基地局に共通する第１同期コードを用い、第２チャンネル即ち第２同期チャンネルは、第２同期コードの周期的セットを用いる。第２同期コードは同じコード群にない他の基地局と共有しない。Ｗ-ＣＤＭＡシステムにおいて、移動局は、第１同期チャンネルの第１同期コードを探索後、第１同期チャンネルから誘導されたタイミング情報を用いて、第２同期チャンネルを処理することで、一つ以上の基地局の同期チャンネルを獲得できる。

ＩＴＵ(Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ)は、本来ＩＭＴ２０００(Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｐｈｏｎｙ ２０００)プロジェクトに係るモバイル通信システム用３Ｇ(第３世代)標準の先頭走者である。ＩＭＴ２０００は、グローバル３Ｇシステムとして認知される無線ネットワークに単一グローバル標準用バージョンを提供する。３Ｇシステムにおいて、モバイル通信システムの次世代は、マルチメディア及びビデオのような強化されたサービスを提供する。主な３Ｇ技術は、ＵＭＴＳ(Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ)及びＣＤＭＡ２０００を含む。

ＵＭＴＳはマルチメディアサービスの強化された範囲を提供する。ＵＭＴＳは、遠距離通信、情報技術、メディア及びコンテンツ産業分野間の水廉を加速化して、新たなサービスを伝達し新たな所得発生機会を生成する。ＵＭＴＳは、グローバルローミング及び他の進歩した収容能力を持つ固定条件下において、２Ｍｂｐｓのような高速の低費用、高容量のモバイル通信提供データレートを伝達する。ＵＭＴＳを定義する仕様は、３ＧＰＰ(Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)により規定化する。

ＵＭＴＳは、ＧＳＭヨーロッパ標準から展開した次世代モバイル通信システムである。図１は一般のＵＭＴＳのアーキテクチャーのブロック図である。図１を参照すれば、ＵＭＴＳはＵＥ(ｕｓｅｒｅ ｑｕｉｐｍｅｎｔ)１００(移動局ともいい)、ＵＴＲＡＮ(ＵＭＴＳ ｔｅｒｒｅｓｔｒｉａｌ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ)２００及びコアネットワーク３００からなる。ＵＴＲＡＮ２００は複数の無線ネットワークサブシステム１０ａ-１０ｎからなる。

例えば、一つの無線ネットワークサブシステム１０ａは、一つのＲＮＣ(ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ)１２及び複数のノードＢ(１１ａ及び１１ｂ)からなる。ノードＢ(１１ａ及び１１ｂ)はＲＮＣ１２により管理される。無線ネットワークサブシステム１０ａ-１０ｎの各々は前述した無線ネットワークサブシステム１０ａと同様な構成を持つ。ノードＢ(１１ａ/１１ｂ、１３ａ/１３ｂ)は、ユーザー設備１００から転送されたアップリンクデータを受信したり、或いは、ダウンリンクデータをユーザー設備１００に転送する。

ＲＮＣ１２、１４は無線リソースを割り当て管理する。ＲＮＣ１２、１４はノードＢ(１１ａ/１１ｂ、１３ａ/１３ｂ)をコアネットワーク２００に連結するためのアクセスポイントの役割を果たす。また、ノードＢ(１１ａ/１１ｂ、１３ａ/１３ｂ)はユーザー設備１００をＵＴＲＡＮ２００に連結するためのアクセスポイントの役割を果たす。

前述した構成から、ユーザー設備１００がネットワークに連結中であれば、ユーザー設備１００を管理するＲＮＣはＳＲＮＣ(ｓｅｒｖｉｎｇ ＲＮＣ)である。この場合、ＳＲＮＣはユーザー設備１００をコアネットワーク３００に連結する役割を果たす。また、ＳＲＮＣは特定サービスにユーザー設備を提供するのに適当な無線リソースを割り当てる。

前述した構成から、ユーザー設備１００に提供されたサービスは、回路スイッチングしたサービス及びパケットスイッチングしたサービスに分割することができる。例えば、一般の音声通話サービスは回路スイッチングしたサービスに属し、インターネットアクセスを通したウェブブラウジングサービスはパケットスイッチングしたサービスに属する。

図１のシステムが回路スイッチングしたサービスを支援するとき、ＲＮＣ１２、１４はコアネットワーク３００のＭＳＣ(ｍｏｂｉｌｅ ｓｗｉｔｃｈｉｎｇ ｃｅｎｔｅｒ)２０に連結される。ＭＳＣ２０はＧＭＳＣ(ｇａｔｅｗａｙ ｍｏｂｉｌｅ ｓｗｉｔｃｈｉｎｇ ｃｅｎｔｅｒ)３０に連結される。ＧＭＳＣ３０は外部ネットワークまたはこれに要請されたボイスコールのアクセスを管理する。

図１のシステムがパケットスイッチングしたサービスを支援するとき、ＲＮＣ１２、１４は、コアネットワーク３００のサービングＧＰＲＳ(ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ)支援ノード(以下、ＳＧＳＮ)４０及びゲートウェアＧＰＲＳ支援ノード(以下、ＧＧＳＮ)５０に連結される。

この場合、ＧＧＳＮ５０はインターネットや外部ネットワークと相互作用するゲートウェイの役割を果たす。さらに、ＳＧＳＮ４０はＧＧＳＮ５０と連結しており、ユーザー設備１００の移動性を管理してパケットスイッチ機能を行う。相互通信用インターフェースは図１のシステムを構成する色々なエレメント間で定義される。ＩｕインターフェースはＲＮＣ１２、１４及びコアネットワーク３００間で定義される。パケットスイッチングした領域内で一つのエレメントに連結したＩｕインターフェースはＩｕ-ＰＳとして定義される。回路スイッチングした領域内で一つのエレメントに連結したＩｕインターフェースはＩｕ-ＣＳとして定義される。図１に示すＵＭＴＳは既定のレベルに係る品質を保障する各種マルチメディアサービスを提供するように構築される。

特定サービスに対するユーザー満足度を決定する全体サービスの品質はＱｏＳ(ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ)として定義される。ユーザーが経験するＱｏＳは、それぞれのサービスに適用される各種複雑なファクターに従属する。

無線または有線での高速転送レート或いは速度はユーザー要請ＱｏＳを満足させない。すなわち、無線と有線とも含む全てのエンド−トゥ−エンド転送経路において転送能力(又は速度)は、既定のレベルだけでなく、無線での転送レートに渡って保障されるべきである。

ＵＭＴＳにおいて、様々なベアラー(ｂｅａｒｅｒ)サービスの概念は、エンド−トゥ−エンド特定サービスに対する既定のレベルに渡ったＱｏＳを保障するように定義される。特に、エンド−トゥ−エンド特定通信サービスは、提供される各種ネットワークエレメントを通して色んなライン(例えば、有線、無線)に分割される。つまり、データ転送サービスは各ライン内から独立的に定義され、定義されたサービスに対する各ＱｏＳは保障される。

特に、ユーザー設備及びコアネットワーク３００間のラインでユーザーデータの信頼できる転送を担当するベアラーは、ＲＡＢ(ｒａｄｉｏｎ ａｃｃｅｓｓ ｈｅａｒｅｒ)と呼ばれる。ＲＡＢは無線ベアラーサービス及びＩｕベアラーサービスを通して具現される。

無線ベアラーサービスは、ユーザー設備１００及びＲＮＣ１２、１４間のＩｕインターフェースを用いてデータ転送を行うものであり、Ｉｕベアラーサービスは、ＲＮＣ１２、１４及びコアネットワーク３００間のデータ転送を行うものである。

ＲＡＢは、まず、特定サービスを提供するように構成されるべきである。ＲＡＢを構成するとき、各種パラメーターは特定ＱｏＳを満足させるように設定される。ＭＳＣ２０は回路スイッチングしたサービスでＲＡＢを構成するように初期化する。これに対し、ＳＧＳＮ４０はパケットスイッチングしたサービスでＲＡＢを構成するように初期化する。

ＵＭＴＳの次世代標準のために生成された３ＧＰＰ(３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ)は、ユーザー設備及びＵＴＲＡＮ間の無線インターフェースプロトコルアーキテクチャーを特定する。図２は、３ＧＰＰ無線アクセスネットワーク仕様に基づき、ユーザー設備及びＵＴＲＡＮ間の無線インターフェースプロトコルアーキテクチャーを示す。

再度、図２を参照して、無線インターフェースプロトコルは、無線ベアラーサービスを設定し、再構成してリリース(ｒｅｌｅａｓｅ)する。無線インターフェースプロトコルは層１-３(Ｌ１-Ｌ３)、即ち、物理層及びネットワーク層に対応する機能を備える。

Ｌ１即ち物理層は情報転送サービスをＭＡＣサブ層及び上位層に提供する。Ｌ１は個別転送チャンネルをＭＡＣサブ層に提供する。転送チャンネルは無線インターフェース上にデータが転送される方式に特徴がある。Ｌ２はＭＡＣ(ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ)サブ層、ＲＬＣ(ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ)サブ層、パケットデータ水廉プロトコルサブ層及び放送/マルチキャストサブ層からなる。

ＭＡＣサブ層は個別論理チャンネルをＲＬＣに提供し、一つの論理チャンネルは転送された情報タイプにより特徴化する。ＭＡＣサブ層は論理チャンネルを介してデータ転送サービスを提供する。このようなチャンネルは、２種のチャンネル例えば制御面(ｃｏｎｔｒｏｌ ｐｌａｎｅ)情報転送のための制御チャンネル及びユーザー面情報転送のためのトラフィックチャンネルにグループ化する。

無線リソース及びＭＡＣパラメーターの再割当てサービスは、サービスをＭＡＣサブ層により上位層に提供する。再割当てサービスはＭＡＣパラメーターを変更し、無線リソースを再割当てするためのＲＲＣの実行要求により行われる。ＭＡＣサブ層はその自体にリソース割当てを処理する。

また、ＭＡＣサブ層は、ＭＡＣ-ｂ、ＭＡＣ-ｄ及びＭＡＣ-ｓ/ｓｈのような色んなエンティティ(ｅｎｔｉｔｙ)からなる。ＲＬＣサブ層は信頼できるデータ転送サービスを支援する。ＲＬＣサブ層は、上位層のＰＤＵ(ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔｓ)をＲＬＣＳＤＵ(ｓｅｒｖｉｃｅｄ ｄａｔａ ｕｎｉｔｓ)に分割したり、或いは、ＲＬＣ ＳＤＵを上位層のＰＤＵに更にアセンブルリングする。

ＢＭＣ(ｂｒｏａｄｃａｓｔ/ｍｕｌｔｉｃａｓｔ ｃｏｎｔｒｏｌ)サブ層は、ユーザー面において放送/マルチキャスト転送サービスを提供する。ＢＭＣサブ層の基本機能は、セル放送メッセージ(ＣＢ)の格納、トラフィックボリュームモニターリングとセル放送サービスのための無線リソース、ＢＭＣメッセージのスケジューリング及びＢＭＳメッセージのユーザー設備への伝達である。また、ＰＤＣＰサブ層はネットワークＰＤＵの転送/受信を提供する。
Ｌ３は制御面上のサブ層を含む。Ｌ３のサブ層の中の最下位層としてＲＲＣ(ｒａｄｉｏｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ)は、次の機能を備える。

ＲＲＣ層は、ＵＥ及びＵＴＲＡＮ間のＲＲＣ接続の構築、再構築、維持管理及びリリースを担当する。また、ＲＲＣ層は、ユーザー面上においてＲＢ(ｒａｄｉｏ ｂｅａｒｅｒ)の設定、再構成及びリリースを担当する。さらに、ＲＲＣ層は、ＲＲＣ接続に対する無線リソースの割当て、再構成及びリリースを担当する。

前述した無線インターフェースプロトコルアーキテクチャーを用いる３ＧＰＰは、ＭＢＭＳ(ｂｒｏａｄｃａｓｔ/ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ)に対する標準仕様を開発しようとするものである。ＭＢＭＳはマルチキャスト機能支援、支援可能なメディアデータの制限などの失敗のような以前ＣＢＳ(ｃｅｌｌ ｂｒｏａｄｃａｓｔ ｓｅｒｖｉｃｅ)の制限を克服しようとするものである。

ここで、ＭＢＭＳは、単方向ポイント−トゥ−マルチポイントベアラーサービスを用いて、オーディオやビデオ等のマルチメディアデータを多数のＵＥに伝達する。ＭＢＭＳは放送モード及びマルチキャストモードに分割される。

ＭＢＭＳ放送モードにおいて、マルチメディアデータは、放送サービスを利用できる放送ドメイン内の全てのＵＥに転送される。

ＭＢＭＳマルチキャストモードにおいて、マルチメディアデータは、マルチキャストサービスを利用できるマルチキャストドメインから特定ＵＥグループに転送される。マルチキャストモードにおいてＭＢＭＳを備えるために、ＵＥはマルチキャスト加入グループに加入すべきである。ＵＥは加入完了後に特定マルチキャストデータの受信を可能にする。

ＭＢＭＳに対する設定要件情報はＲＡＢの構成により具現される。すなわち、ＭＢＭＳにおいて、特定レベルを超えるＱｏＳを保障するためのＭＢＭＳのＲＡＢは、ＵＥ及びコアネットワーク間に設定されるべきである。

ＭＢＭＳはリアルタイムデータの転送時、ＲＴＰ(ｒｅａｌ ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ)を用いる。リアルタイムデータはリアルタイムに転送されるパケットタイプを有し、以下、リアルタイムパケットとして説明される。

ＲＴＰはマルチキャスト又はユニキャストネットワークを通して、オーディオデータやビデオデータ等のようなリアルタイム転送属性を持つマルチメディアデータを転送するのに適したプロトコルである。ＲＴＰ自体はボイスサービスやビデオサービス等のようなリアルタイムサービスに対するＱｏＳを保障出来ない。つまり、ＭＢＭＳはＲＴＣＰ(ＲＴＰ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ)をさらに用いる。

しかしながら、有線通信線を具現すれば、ＲＴＰ及びＲＴＣＰは、図２に示すシステムを介して有線と無線ともを経由してサービスを提供するのに困難がある。すなわち、ＲＴＰ及びＲＴＣＰと無線のダイレクトアプリケーションは、次のような問題があった。

まず、ＲＴＰパケットの状態情報をデータソースに転送するためのＲＴＣＰパケットは有線または無線で起きるパケット損失を区別できない。ＲＴＣＰパケットは、単にネットワークでデータの流れをモニターリングするために、有線での衝突によるパケット損失量をチェックする。データソースはパケット損失が無線または有線で起きるか否かを判定できない。

ＵＭＴＳネットワークにおいて、一般的に、無線内のパケット損失量は有線での損失量より大きい。結果として、ＲＴＣＰパケットに基づいて連続的なＲＴＰパケットの転送を行う時、データソースにエラーが発生しやすい。

例えば、データソースは、ＲＴＣＰパケット内に含まれた状態情報からネットワークの現在状況をモニターリングし、モニターリング結果により、転送されたＲＴＣＰパケット及び符号化方式(ｅｎｃｏｄｉｎｇ ｓｃｈｅｍｅ)を変更して、以後に転送される連続的なパケットの損失を減少させる。

有線でのパケット損失の原因と無線でのそれとは異なる。結果として、転送されたＲＴＰパケットの大きさ及び符号化方式は、有線及び無線の各原因によって適当に変更されるべきである。従来技術では、データソースが有線でのパケット損失の原因を無線と区別する方法がなかった。従来のシステムは、ＲＴＰパケット転送の間にエラー発生を減少させるために、有線及び/または無線ネットワークにおいて転送操作及び制御を效率よく行うことができなかった。

さらに、ＭＢＭＳのような複数のＵＥ受信サービスがあれば、ＲＴＣＰパケットはそれぞれのＵＥからデータソースに転送され、ＲＴＰ及びＲＴＣＰパケットの転送に要求される各帯域幅の決定時に問題を招くことになる。

特に、ＲＴＰ及びＲＴＣＰは有線のみに適したプロトコルであるため、有線のターミナル端に一つのＵＥ(またはホスト)が存在する。結果として、ＭＢＭＳのようなポイント−トゥ−マルチポイント通信が、従来のＲＴＰ及びＲＴＣＰを修正なしに利用すれば、パケット転送に要求される帯域幅の割当て時に問題が発生して、リソース利用の効率を減少させる。

上記目的を達成するために、本発明は、データソースから有線通信線及び無線通信線を備えた通信ネットワークと通信するモバイルデバイスにリアルタイムデータを転送する方法が提供される。この方法は、有線通信線を介してデータソースからリアルタイムデータを受信するステップと、制御情報を生成するために有線通信線に対するパケット損失を決定するステップと、制御情報をデータソースに転送するステップと、制御情報に基づいて有線及び無線通信線を介してリアルタイムデータをモバイルデバイスに転送するステップとを含む。

一実施例において、本方法は、制御情報に基づいて有線または無線通信線の少なくとも一つに対するサービスデータの品質を決定するステップと、サービスデータの品質に基づいてリアルタイムデータに対する転送要件を調節するステップと、リアルタイムデータを含むリアルタイムデータパケットの転送の大きさを調節するステップと、リアルタイムデータのエンコーディングモードを調節するステップとをさらに含む。調節はリアルタイムデータがデータソースから転送される時に行われる。

無線通信線に対するサービスの品質は、データソースからモバイルデバイスへのリアルタイムデータの通信を制御する通信ネットワークセグメントと関連した第１サービス品質と、有線通信線と関連した第２サービス品質とに基づいて決定される。一実施例において、無線通信線に対するサービスの品質は、第１及び第２サービス情報の品質に基づいて決定される。

サービス情報の第１品質はモバイルデバイスから受信される。第２サービス情報の品質は無線通信を介して通信されるリアルタイムデータに対する損失パケット情報の受信に基づいて決定される。第１サービス情報の品質は、有線及び無線通信線を介してデータソースからモバイルデバイスにリアルタイムデータの通信が行われる間に損失されたパケット数に基づいて決定される。リアルタイムデータはＲＴＰ(ｒｅａｌ ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ)を介して受信及び転送される。

リアルタイムデータは、データソースとの通信際、モバイル通信ネットワークを介して受信及び転送される。ＵＴＲＡＮは、モバイルデバイスから受信された第１パケット損失情報と、有線通信線を介してデータ受信と関連した第２パケット損失情報とに基づいて、無線通信線に対するサービスの品質を決定する。

一実施例において、ＵＴＲＡＮは、第２パケット損失情報を決定するために、有線通信線を介して受信されたリアルタイムデータを非パケット化する(ｄｅｐａｃｋｅｔｉｚｉｎｇ)リレイ(ｒｅｌａｙ)機能モジュールを含む。リレイ機能モジュールは、非パケット化リアルタイムデータをモバイルデバイスへの転送前にパケット化する。モバイルデバイスは、第１パケット損失情報を含むフィードバックをリアルタイムデータの受信後にＵＴＲＡＮに送信する。

リアルタイムデータは、ＵＤＰ(ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ)を介して転送されるＲＴＰパケットでカプセル化(ｅｎｃａｐｕｌａｔｅｄ)する。リアルタイムデータはＲＴＣＰを介して転送される。

一実施例において、リアルタイム通信システムは、データソースと連結した有線通信線システムと、有線通信線システムをモバイルデバイスに無線で連結するインターフェースシステムとを含み、インターフェースシステムは、有線通信線システムを介して転送されたリアルタイムデータと関連した第１パケット損失情報に基づいて、リアルタイムデータに対する転送要件を調節する。

第１サービスの品質は、データソースからインターフェースシステムへのリアルタイムデータの転送に基づいて決定する。第２サービスの品質は、インターフェースシステムからモバイルデバイスへのリアルタイムデータの転送に基づいて決定される。インターフェースシステムは、データソースからモバイルデバイスに転送されたデータを処理するためのリレイモジュールを含む。転送されたデータがリアルタイムデータでなければ、リレイモジュールはデータを処理しない。データがリアルタイム制御プロトコルを介して転送されないと、リレイモジュールはデータを処理しない。

一実施例において、第１サービスの品質は、有線通信線システムにおいてパケット損失を決定するために、リアルタイム制御プロトコルを介して転送されるリアルタイムデータを非パケット化することで、リレイモジュールにより決定される。第２サービスの品質は、モバイルデバイスによるリアルタイムデータの受信後に検出されたパケット損失に対するモバイルデバイスにより提供されたフィードバックに基づいて、リレイモジュールにより決定される。

リアルタイムデータは、ＵＤＰを介して転送されたＲＴＰパケットでカプセル化する。また、リアルタイムデータは例えばＲＴＣＰを介して転送される。

他の実施例において、データ通信方法は、有線及び無線通信線セグメントを含む通信ネットワークを介して、データソース及びモバイルデバイス間に通信ベアラーを構築するステップと、リアルタイムデータを含み、通信するデータがリアルタイムデータプロトコルを介して転送される時、有線及び無線セグメントを介して、サービスの品質に基づいてリアルタイムデータの転送を調節するステップとを含む。

リレイモジュールは、リアルタイム制御プロトコルを介してモバイルデバイスからフィードバックを受信し、フィードバックを有線通信線セグメントに対するサービス情報の品質と比較することで、無線通信線セグメントを介してサービスの品質を決定する。リレイモジュールは、データソース及びモバイルデバイスを連結する通信ネットワークで一体化する。ＲＡＢ(ｒａｄｉｏ ａｃｃｅｓｓ ｂｅａｒｅｒ)は、通信ネットワーク及びモバイルデバイス間に構築されて、リレイモジュールにサービス情報の品質を提供する。

他の実施例において、データソースから無線通信線によって有線通信線に連結したモバイルデバイスにリアルタイムデータを伝達する方法が提供され、ここで、ＵＴＲＡＮは、有線及び無線通信線間の通信インターフェースとして作用する。この方法は、有線通信線を介してデータソースからリアルタイムデータを受信するステップと、有線通信線を介してリアルタイムデータの転送品質と関連した制御情報をデータソースに転送するステップと、制御情報に基づいて無線通信線を介してリアルタイムデータをモバイルデバイスに転送するステップとを含む。

本発明は、当該技術分野の熟練者には、例えば、適当にプログラミングされたデジタル信号プロセッサー(ＤＳＰ)又は他のデータ処理デバイス、外部支援ロジックを備えた単独またはその組合を用いて、容易に具現できるのが明らかである。

また、本発明は、ソフトウェア、ファームウエア、ハードウェアまたはその組合を生成するために、標準プログラミング及び/またはエンジニアリング技術を用いる方法、装置または製造物として具現される。用語“製造物”は、ハードウェアロジック(例えば、集積回路チップ、ＦＰＧＡ(ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ)、ＡＳＩＣ(ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｒｇａｔｅｄ ｃｉｒｃｕｉｔ)等)またはコンピュータ読出し可能な媒体(例えば、磁気記録媒体(例えば、ハードディスクドライバ、フロッピー（登録商標）ディスクドライバ、テープ等)、光ストレージ(ＣＤ-ＲＯＭ、光ディスク等)、非活性及び非揮発性メモリデバイス(例えば、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ファームウエア、プログラム可能なロジック等))で具現されるコードまたはロジックを言及する。コンピュータ読出し可能な媒体において、コードはプロセッサーによりアクセス及び実行される。

以下、本発明に係る好適な実施の形態について、添付の図面に基づいて詳細に説明する。

なお、図において、同一または類似な構成要素については同じ符号を付けて使用する。

本発明の説明を助けるために、任意の例示的なパラメーター名、値、長さ及び他の属性は、移動局及び基地局間で通信するチャンネル、メッセージ及びフィクスまたは可変識別子を説明するのに使用される。このようなパラメーター名は単に例示的なものであり、他の名が同一又は類似な機能を説明するのに使用されることもできるのに留意すべきである。

図３を参照すれば、本発明に係るパケットサービスシステムは、データソース、コアネットワーク、ＵＴＲＡＮ及びＵＥを含む。データソースは有線の開始ポイントであり、ユーザー設備は無線の終了ポイントである。

ＵＴＲＡＮは有線の終了ポイント且つ無線の開始ポイントである。ユーザー設備は無線を介したターミナルであり、ＵＴＲＡＮは、データソースにより提供されるパケットサービスを用いて、ユーザー設備にＵＴＲＡＮに対する無線アクセスを提供する無線アクセスネットワークである。

データソース及びユーザー設備は、リアルタイムパケットサービスに対するプロトコル層を備える。例えば、ダウンロードしたデータソースは、ＲＴＰ層及びＲＴＣＰ層を含み、ＲＴＰ/ＲＴＣＰ層の下のＵＤＰ/ＩＰ(ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ/ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ)層をさらに含む。勿論、ユーザー設備は前述したデータソースのプロトコル層を含む。さらに、データソース及びユーザー設備は、非リアルタイムパケットサービスに対するプロトコル層を含む。

一実施例において、本発明は、ＵＴＲＡＮがリアルタイムパケットサービスを支援するために、ＵＤＰ/ＩＰ層上のＲＴＰ及びＲＴＣＰ層を含むことに特徴がある。勿論、ＵＴＲＡＮは非リアルタイムパケットサービスをさらに支援する。ＵＴＲＡＮは非リアルタイムパケットを転送する役割を明確に担当する。

ＵＴＲＡＮのＲＴＰ層はデータソースから転送されたリアルタイムデータをＵＥにリレイし、ＲＴＣＰ層はリアルタイムデータの転送を制御する。ＵＴＲＡＮはＲＴＰ/ＲＴＣＰ層の下のＵＤＰ/ＩＰをさらに含む。データソース及びＵＴＲＡＮ又はＵＥ及びＵＴＲＡＮ間に転送/受信されたリアルタイムデータはＲＴＰ/ＵＤＰ/ＩＰパケットである。対応するＲＴＰ/ＵＤＰ/ＩＰ層は受信されたＲＴＰ/ＵＤＰ/ＩＰパケットを抽出し、これをＲＴＰ又はＲＴＣＰパケットに変換する。

前述の説明から、ＵＴＲＡＮがＵＴＲＡＮの構造的な変更を最小化する、動作を行うＵＤＰ/ＩＰ層上のＲＴＰ/ＲＴＣＰ層を含む。特に、本発明のＵＴＲＡＮはＲＴＰ層による動作及びＲＴＣＰ層による動作を行う機能エンティティを含む。機能エンティティリレイ機能モジュールは、例えば、一実施例によってＵＴＲＡＮの一エレメントとしてＲＮＣにインストールされる。リレイ機能モジュールは有線及び無線を互いに区別する。本発明に係るリレイ機能モジュールを用いる一例は図３に示され、リレイ機能モジュールを具現するのに要求されるプロトコルアーキテクチャーは図４に示される。

図３のリレイ機能モジュールは、次のように説明される。第一に、複数のリレイ機能モジュール８０ａ-８０ｎは、ＲＴＰパケットのようなリアルタイムパケットに対する有線及び無線の各々でＲＴＰ/ＲＴＣＰの独立的な動作を提供する。この場合、ＵＴＲＡＮ２００及びＵＥ１００間に無線が置かれ、ＵＴＲＡＮ２００及びデータソース７０間に有線が置かれる。

第二に、リレイ機能モジュール８０ａ-８０ｎは、ＭＢＭＳのようなＲＴＰ及びＲＴＣＰパケットを転送するためのシステムで使用される。このようなシステムにおいて、リレイ機能モジュール８０ａ-８０ｎは、有線の受信状態情報を転送するＲＴＣＰパケットを発生させ、ＵＥ１００から無線の状態情報を転送するＲＴＣＰパケットを操作するために無線部でＲＴＰパケットをＵＥ１００に転送する。

第三に、リレイ機能モジュール８０ａ-８０ｎは、無線のパケット転送の制御を行うＵＴＲＡＮ２００でインストールされる。リレイ機能モジュール８０ａ-８０ｎは、ＵＴＲＡＮ２００のＲＮＣ１２ａ-１２ｎに連結する。システム具現際、リレイ機能モジュール８０ａ-８０ｎはＲＮＣ１２ａ-１２ｎにインストールされることができ、また、ＲＮＣ１２ａ-１２ｎから分離されたＵＴＲＡＮ２００にインストールされることができる。リレイ機能モジュール８０ａ-８０ｎがＲＮＣ１２ａ-１２ｎに動作するために連結するとき、その連結は“トンネルリング(ｔｕｎｎｅｌｉｎｇ)”により達成される。すなわち、リレイ機能モジュール８０ａ-８０ｎは、有線/無線でパケットの流れ及び操作制御を行うためのトンネルリングによってＲＮＣ１２ａ-１２ｎの各々に連結する。

したがって、リレイ機能モジュール８０ａ-８０ｎがＵＴＲＡＮ２００の一エレメントとして使用されれば、図３に示す各線でＲＴＣＰの効率的な動作を提供するために、リレイ機能モジュール８０ａ-８０ｎにより実行されるプロトコル層は、図４に示すように定義される。

リレイ機能モジュール８０ａ-８０ｎ、ＵＤＰ層及びＩＰ層の機能に対応するＲＴＰ/ＲＴＣＰは、ＵＴＲＡＮ２００の無線及びネットワークアクセスプロトコルにさらに提供される。

リレイ機能モジュール８０ａ-８０ｎの動作は、一例として、ＵＴＲＡＮ２００のＲＡＮＣ１２ａ-１２ｎの各々でリレイ機能モジュール８０ａ-８０ｎのインストールを処理することにより、次のように説明される。

リレイ機能モジュール８０ａ-８０ｎは、データソース７０から転送されるＲＴＰパケットのようなリアルタイム属性を備えたデータパケットが受信される時、有線に対する受信状態情報を転送する制御パケットを発生させる。リレイ機能モジュール８０ａ-８０ｎは、その後に発生する制御パケットをデータソース７０に提供する。

一実施例において、データソース７０は、リレイ機能モジュール８０ａ-８０ｎから転送された制御パケットを有線及び/または無線のそれぞれの終了ポイントから転送されるものと見なし、データパケット(例えば、ＲＴＰパケット)及び制御パケット(例えば、ＲＴＣＰパケット)のそれぞれの転送に要求される帯域幅を決定する。

リレイ機能モジュール８０ａ-８０ｎは、リアルタイム属性のデータパケットをダウンリンク無線チャンネル上の複数のＵＥに放送及びマルチキャストし、その後に受信されたデータパケットを備えたＵＥから発生した制御パケットを受信して、現在無線の受信状態情報を獲得する。

リレイ機能モジュール８０ａ-８０ｎ又はＲＮＣ１２ａ-１２ｎは、制御パケットから獲得した無線の受信状態情報を用いて、データパケット上でパケット転送の制御を行う。ＵＴＲＡＮ２００のＲＮＣ１２ａ-１２ｎがデータソースから転送されたデータパケットの制御情報を提供する場合、リレイ機能モジュール８０ａ-８０ｎは有線の受信状態情報をデータソースに提供する。

結果として、有線の受信状態情報からパケット転送の制御を行う一つ(データソース)は、無線の受信状態情報からパケット転送の制御を行うもう一つ(ＲＮＣ)と独立的である。

他の例として、本発明のリレイ機能モジュール８０ａ-８０ｎの各々は、ＵＥ１００の制御パケットから獲得された無線の受信状態情報を、データソース７０に伝達及び転送する対応する制御パケットに付加する。

一実施例において、データソース７０からＵＥ１００に転送されたパケットは、非リアルタイム属性のデータパケット、且つ、リアルタイム属性のデータパケットである。また、リレイ機能モジュール８０ａ-８０ｎは、ＲＴＰパケットのようなリアルタイム属性を備えたデータパケットのパケット転送を支援及び制御する。

これにより、コアネットワーク３００は、データソース７０から転送されるデータパケットの属性を決定し、特定インジケーター(ｉｎｄｉｃａｔｏｒ)を用いて、決定されたデータパケットの属性がリアルタイムであればリレイ機能モジュール８０ａ-８０ｎを動作させる。

したがって、一実施例において、本発明は、リアルタイムパケット転送と非リアルタイムパケット転送ともを支援するためのシステムにおいて、リアルタイムパケット転送の制御を支援するリレイ機能モジュール８０ａ-８０ｎの使用が非リアルタイムパケットの転送を中断しないようにインジケーターを用いる。他の実施例において、本発明は、制御パケット及び特にＲＴＣＰパケットが不要であるとき、リレイ機能モジュール８０ａ-８０ｎの使用がリアルタイムパケットの転送を中断しないようにインジケーターを用いる。

コアネットワーク３００は、データソース７０から転送される現在データパケットの属性がリアルタイムか非リアルタイムかを判定する。コアネットワーク３００は、ＵＥへのパケット転送に対する無線アクセスベアラーの設定時、データパケットの決定された属性の有線の終端があることをＵＴＲＡＮ２００に通知する。

本発明に係るパケットサービスシステムは、図４のプロトコルアーキテクチャーを通して具現され、ＭＢＭＳのようなリアルタイムデータを転送するサービスに適用可能である。本発明に係るパケットサービスシステムは、リアルタイム及び非リアルタイムデータを同時に支援するサービスに適用可能である。

図４を参照すれば、ＲＴＰは、マルチキャスト又はユニキャストネットワークを用いるリアルタイム属性を備えたマルチメディアデータ(ビデオ及び/またはオーディオ)をユーザーに提供するのに適したプロトコルである。ＲＴＰにより定義されるパケットフォーマットは、ＲＴＰメディアタイプを表現するためのＲＴＰメディアタイプフィールドを含み、実質的にサービスされたユーザー情報を含んだペイロード(ｐａｙｌｏａｄ)をさらに含む。ＲＴＰメディアタイプフィールドはタイプをペイロードに通知するためのものである。

ＲＴＣＰは、マルチキャストネットワークにおいてデータ転送をモニターリングし、最小制御及び識別機能を行うためのプロトコルである。ＲＴＣＰの主要機能は、例えば、マルチキャストネットワークに属するネットワークエレメントにデータを分配するための状態情報を発生させ、状態情報をデータソースにフィードバックさせるものである。

ＲＴＣＰの一部機能は、他のプロトコルの流れ制御及び水廉制御と関連する。例えば、ＲＴＣＰを通した状態情報フィードバックは、ＲＴＰパケットを転送する発信先からＲＴＰパケットを受信する目的地へのＲＴＰパケットの転送プロセスの情報(例えば、ＲＴＰパケット損失量、パケット転送の間に起きる遅延時間などの情報)を含む。ＲＴＣＰパケットは受信状態情報を転送することができる。

受信されたＲＴＰパケットに対するＲＴＣＰパケットが目的地から発信先へフィードバックされる時、発信先はＲＴＣＰパケットに含まれる状態情報を用いて、転送されるＲＴＰパケットのデータの大きさ、データ量及び/またはデータ符号化方式を決定する。

例えば、本発明の一実施例において、ＵＴＲＡＮは受信されたＲＴＰパケットに対する状態情報を転送するＲＴＣＰパケットをデータソースに転送し、ユーザー設備(ＵＥ)はＲＴＣＰパケットをＵＴＲＡＮに転送する。ＲＴＣＰパケットは、ＲＴＣＰパケットの受信側がデータパケット(ＲＴＰパケット)の転送の制御を行うようにする状態情報を含む制御パケットである。

ＵＴＲＡＮは、ＵＥから受信されたＲＴＣＰパケットに含まれた状態情報を用いて、ＵＥに転送されるＲＴＰパケットのデータの大きさ、データ量及び/またはデータ符号化方式を決定する。データソースは、ＵＴＲＡＮから受信されたＲＴＣＰパケットに含まれた状態情報を用いて、ＵＴＲＡＮに転送されるＲＴＰパケットのデータの大きさ、データ量及び/またはデータ符号化方式を決定する。

本発明の一実施例において、インジケーターは、ＵＴＲＡＮにおいてリレイ機能モジュールを用いるか否かを示すのに使用される。インジケーターは、データソースから発生したパケットの属性をモニターリングするコアネットワークより発生する。コアネットワークは、データソースから発信されたパケットサービスに対する無線アクセスベアラーの設定時にインジケーターを発生させる。インジケーターは、データソースから発生したパケットの属性を示し、ＵＴＲＡＮに伝達される。

一実施例において、ＵＴＲＡＮは、リアルタイムパケットの転送のためのＵＤＰ/ＩＰ層上のＲＴＰ及びＲＴＣＰ層を含む。リレイ機能モジュールは、コアネットワークから受信されたインジケーターにより動作することが好ましい。すなわち、コアネットワークはインジケーターを用いるリレイ機能モジュールの制御動作を行う。換言すれば、コアネットワークから発生したインジケーターは、リレイ機能モジュールの動作をターンオン/ターンオフするためのコマンドである。

図３を参照すれば、データソース７０は、リアルタイム又は非リアルタイム属性のパケットを伝達させる。このとき、データソース７０は、パケットフォーマットとして特定データを提供するサーバまたはターミナルである。コアネットワーク３００は、データソース７０から転送されるパケットの属性を決定し、転送されるパケットの決定された属性の有線の終端としてＵＴＲＡＮ２００に通知する。

コアネットワーク３００及びＵＥ１００間のパケット転送に対する無線アクセスベアラーの設定時、コアネットワーク３００のＳＧＳＮ４０ａ-４０ｎの各々は、データソース７０から転送されるパケットが非リアルタイム又はリアルタイム属性を持つか否かをＵＴＲＡＮ２００に通知する。コアネットワーク３００のＳＧＳＮ４０ａ-４０ｎは、データソース７０から転送されるパケットの属性を通知するために一つのインジケーターを用いる。

本発明の一実施例において、インジケーターは、現在パケットの属性を通知するのに制限はない。コアネットワーク３００のＳＧＳＮ４０ａ-４０ｎは、ＲＴＰ/ＲＴＣＰ及び/またはＵＴＲＡＮ２００に含まれたリレイ機能モジュール８０ａ-８０ｎだけでなく、転送されるパケットの属性を用いるか否かを通知するインジケーターを活用する。インジケーターが転送されるパケットの属性を通知する場合、ＵＴＲＡＮ２００は、受信されたインジケーターにより表示されたパケットの属性に応じて、リレイ機能モジュール８０ａ-８０ｎを用いるか否かを判定する。

さらに、インジケーターがリレイ機能モジュール８０ａ-８０ｎの利用可否をＵＴＲＡＮに通知する時、ＵＴＲＡＮ２００は、例えば、現在受信されたパケットが受信されたインジケーターにより表示された情報からリアルタイムまたは非リアルタイム属性を持つかをチェックすることができる。

本発明の一実施例において、ＵＴＲＡＮ２００はデータソース７０からデータを受信する有線デバイスを含む。有線ではパケット転送の制御が有線の受信状態情報に応じて支援される。無線デバイスは無線の受信状態情報に応じて無線でパケット転送の制御を行うためにパケットをＵＥ１００に転送する。

好ましくは、本発明のＵＴＲＡＮ２００はリレイ機能モジュール８０ａ-８０ｎを含む。一実施例において、リレイ機能モジュール８０ａ-８０ｎは、図３に示すＲＮＣ１２ａ-１２ｎの各々にインストールされる。これにより、ＵＴＲＡＮ２００は、無線アクセスベアラーの設定時、コアネットワーク３００のＳＧＳＮ４０ａ-４０ｎの中に対応する一つから受信されたインジケーターのコマンドに応じて、リレイ機能モジュール８０ａ-８０ｎのターンオン/ターンオフ動作を行う。

一つのパケットがデータソース７０から転送される時、ＳＧＳＮ５０ａ-５０ｎの各々はデータソースが属するネットワークと相互作用するためのゲートウェイとして作用し、対応するパケットをＳＧＳＮ４０ａ-４０ｎに伝達する。ＳＧＳＮ４０ａ-４０ｎの各々はＵＥに転送されるパケットの属性を決定し、対応するパケットの属性を通知するためのインジケーターをＵＴＲＡＮ２００に伝達する。リアルタイムでパケットの決定された属性がＲＴＰパケットの属性だけ良好であれば、ＲＴＣＰはデータソース７０をインジケーターに含まれる方式により、コアネットワーク３００を介してリアルタイムパケットの受信状態情報を通知する。

一実施例において、ＵＴＲＡＮ２００は、コアネットワーク３００から伝達されたインジケーターからリレイ機能モジュール８０ａ-８０ｎを用いるか判定したり、及び/またはデータの属性を決定する。リレイ機能モジュール８０ａ-８０ｎの利用可否は、伝達するインジケーターにさらに含まれることができる。すなわち、非リアルタイムパケットサービスを提供する場合、リレイ機能モジュール８０ａ-８０ｎは動作せず、パケットはデータソースからＵＥに明確に転送される。ＳＧＳＮ４０ａ-４０ｎの各々は、リアルタイム又は非アルタイムパケットをＵＴＲＡＮ２００のＲＮＣ１２ａ-１２ｎに伝達する。ＵＴＲＡＮ２００のリレイ機能モジュール８０ａ-８０ｎは、ＵＥ１００に伝達されるパケットがリアルタイムの場合及びＲＴＣＰの利用時に動作する。非リアルタイムの場合には動作しない。伝達されたパケットがリアルタイムであってもＲＴＣＰが用いられないと、リレイ機能モジュール８０ａ-８０ｎは動作しない。リレイ機能モジュール８０ａ-８０ｎの動作は、ＳＧＳＮ４０ａ-４０ｎの中に対応する一つから受信されたインジケーターにより制御される。

例えば、ＲＴＰパケットがデータソース７０から最終目的地としてＵＥ１００に転送される時、データソース７０は有線及び無線の中間において、ＵＴＲＡＮ２００を通したパケット転送の間にＲＴＰパケットの損失量としてネットワーク状態をモニターリングできるべきである。一実施例において、リレイ機能モジュール８０ａ-８０ｎは、有線の受信状態情報を含むＲＴＰパケットをデータソース７０にフィードバックする。

リレイ機能モジュール８０ａ-８０ｎを備えたＲＮＣ１２ａ-１２ｎの各々は、ＳＧＳＮ４０ａ-４０ｎの中に対応する一つから受信されたパケットを無線でＵＥに転送する。このとき、サービスがマルチキャストの場合、ＲＮＣ１２ａ-１２ｎはパケットをこれらのサービスドメインに位置した複数のＵＥに転送する。ＳＧＳＮ４０ａ-４０ｎの中に対応する一つから受信されたパケットがリアルタイムパケットの場合、リレイ機能モジュール８０ａ-８０ｎはリアルタイムパケットをＵＥに転送する。

リレイ機能モジュール８０ａ-８０ｎは、リアルタイムパケットの受信状態情報を含む制御パケット(例えば、ＲＴＣＰパケット)をデータソース７０にフィードバックし、無線の受信状態情報を含む制御パケット(例えば、ＲＴＣＰパケット)をＵＥの各々から受信する。

一実施例において、ＵＥから受信された制御パケットの各状態情報は、データソース７０にフィードバックされる制御パケットの中に対応する一つに含まれる。ＲＮＣ１２ａ-１２ｎにインストールされたリレイ機能モジュール８０ａ-８０ｎの各々は、ＵＥから受信された制御パケットからＵＥの受信状態情報をデータソース７０に提供する。

他の実施例において、データソースにフィードバックされた各制御パケットが無線の受信状態情報を含まないため、無線の受信状態情報を含む制御パケット(ＵＥから受信されたＲＴＣＰパケット)がＲＮＣ１２ａ-１２ｎの各々により操作されることが好ましい。ＲＮＣ１２ａ-１２ｎは、ＵＥから受信された制御パケットに基づき、無線に転送されるパケットの大きさ、量及び/または符号化方式を決定する。

前述した説明から、リアルタイム/非リアルタイムパケットの流れにおいて有線及び無線の状態を区別するのに使用されるリレイ機能モジュール８０ａ-８０ｎがＲＮＣ１２ａ-１２ｎの各々にインストールされる。また、リレイ機能モジュール８０ａ-８０ｎは、ＲＮＣ１２ａ-１２ｎからＵＴＲＡＮ２００に独立的にインストールできる。さらに、ＲＮＣ１２ａ-１２ｎは、リレイ機能モジュール８０ａ-８０ｎの機能を含む機能を行うように具現されることができる。例示的な実施例において、リレイ機能モジュール８０ａ-８０ｎはＲＮＣ１２ａ-１２ｎの各々にインストールされる。本発明においてＵＴＲＡＮ２００にインジケーターを転送する例は、次の通り説明される。

リレイ機能モジュール８０ａ-８０ｎがインジケーターのコマンドに応じてターンオン/ターンオフされる時及び属性のパケットがデータソース７０から転送される時、コアネットワーク３００は転送されるパケットの属性を示すインジケーターをＵＴＲＡＮ２００に伝達する。このようなインジケーターは、パケットがリアルタイム又は非リアルタイム属性を持つか、ＲＴＣＰパケットのような制御パケットが使用されるかを示す。

結果として、リアルタイムパケットは、インジケーターがリアルタイム属性のパケット転送を通知した後に受信され、ＲＴＣＰパケットの利用がコアネットワークから受信された場合、リレイ機能モジュール８０ａ-８０ｎは有線でリアルタイムパケットに対する状態情報をデータソース７０に通知する。また、非リアルタイム属性のパケット転送を通知するインジケーターがコアネットワーク３００から受信されると、リレイ機能モジュール８０ａ-８０ｎは非リアルタイムパケット転送に全く関連しない。

リレイ機能モジュール８０ａ-８０ｎは、非リアルタイムパケット属性がデータソース７０から伝達される時にインジケーターのコマンドによりターンオフされる。コアネットワーク３００は、転送されるパケットの属性が非リアルタイムであったり、或いは、有線での状態情報が、転送されるパケットが非リアルタイムパケットであっても要求されないと、ＵＴＲＡＮ２００にインジケーターを伝達する。すなわち、ＲＴＣＰはリアルタイムパケット転送の場合に使用されない。その結果、非リアルタイム属性のパケット転送を通知する一つのインジケーター、或いは、有線での状態情報がコアネットワーク３００から要請されないことを通知する他のインジケーターを受信する。リレイ機能モジュール８０ａ-８０ｎは非リアルタイム又はリアルタイムパケット転送と関係なしに、すぐターンオフされる。

ＭＢＭＳは支援され、リレイ機能モジュール８０ａ-８０ｎは、ＲＴＰパケットがデータソース７０から転送される時、コアネットワーク３００からインジケーターのコマンドに応じてＲＴＣＰパケットを利用するか否かを判定する。コアネットワーク３００は、ＲＴＣＰパケットが用いられると、インジケーターをＵＴＲＡＮ２００に伝達する。

結果として、コアネットワークからインジケーターを受信すると、リレイ機能モジュール８０ａ-８０ｎは有線の状態情報を含むＲＴＣＰパケットをデータソース７０に提供し、ＲＴＣＰを利用することなく、リアルタイム属性のパケットの他の転送と関連しない。よって、インジケーターはＲＴＣＰの利用の可否を通知する情報を含む。

図５を参照すれば、データソース７０は、リアルタイムパケット転送に対する状態情報を要請するリアルタイムパケットと、リアルタイムパケット転送に対する状態情報を要請するのに失敗した非リアルタイムパケットとを伝達しようとするものである。

ある特定パケット転送がデータソース７０から要請される時、コアネットワーク３００は少なくとも一つのターミナル１００を持つ無線アクセスベアラーを設定する(Ｓ１０)。次の説明において、ＭＢＭＳ無線アクセスベアラーがＭＢＭＳを対応するターミナルに転送すように設定されると仮定する。

ＭＢＭＳ無線アクセスベアラーが設定される時、コアネットワーク３００は、データソース７０から転送されるパケットデータの属性を決定し、決定された属性をＵＴＲＡＮ２００に通知する。コアネットワーク２００のＳＧＳＮ４０ａ-４０ｎは、データソース７０から転送されるパケットがリアルタイム又は非リアルタイム属性を持つか否かをＵＴＲＡＮ２００に通知する。ＳＧＳＮ４０は、これがインジケーターを利用するリアルタイムパケットの転送のためにＲＴＣＰを利用するか否かをＵＴＲＡＮ２００に通知する。

一実施例において、一つのインジケーターは転送されるパケットが非リアルタイム又はリアルタイム属性を持つか否かを示す。このようなインジケーターはパケット属性インジケーターである。リアルタイムパケットの転送のためにＲＴＣＰの利用可否を通知する他のインジケーターは、例えば、ＲＴＣＰ使用/非使用インジケーターと命名する。

これにより、ＵＴＲＡＮ２００は、受信されたインジケーターに基づき、リレイ機能モジュール８０ａ-８０ｎの使用の可否を判定する(Ｓ１１)。続いて、データソース７０のパケットはＵＴＲＡＮ２００のＲＮＣ１２ａ-１２ｎに伝達される(Ｓ１２)。ＵＴＲＡＮ２００のＲＮＣ１２ａ-１２ｎは、無線アクセスベアラーを設定するプロセスにおいて、コアネットワーク３００から受信されたインジケーターによりリレイ機能モジュール８０ａ-８０ｎの使用の可否を既に決定した。よって、リレイ機能モジュール８０ａ-８０ｎは受信されるパケットに対する次の二つの方式で動作する。

まず、受信されるパケットがＲＴＣＰを利用するＲＴＰパケットの場合、リレイ機能モジュール８０ａ-８０ｎの各々は受信されたＲＴＰパケットに対する有線での状態情報(例えば、ＲＴＰパケットの損失量)をＲＴＣＰパケットに付加し、これをデータソース７０にフィードバックする(Ｓ１３)。このとき、ＲＮＣ１２ａ-１２ｎは、トンネルリング又はリレイ機能モジュール８０ａ-８０ｎとのノード−トゥ−ノード通信により受信されるＲＴＰパケットを提供する。

ＲＮＣ１２ａ-１２ｎ又はリレイ機能モジュール８０ａ-８０ｎは、受信されたＲＴＰパケットを無線での複数のターミナル１００に転送する(Ｓ１４)。このとき、ターミナル１００に転送されるＲＴＰパケットはダウンリンク無線チャンネル上で放送またはマルチキャストされる。一方、受信されたＲＴＣＰパケットを持つデータソース７０は、ＲＴＣＰパケットに含まれた状態情報に基づき、転送されるＲＴＰパケットのデータの大きさ、適当な符号化方式及び/またはその他を決定する(Ｓ１５)。

一実施例において、データソース７０は、ＲＴＣＰパケットに含まれた状態情報に基づき、後に転送されるＲＴＰパケットに含まれたルーティング情報を変更し、ＲＴＰパケットがよく衝突が発生するコアネットワーク３００及び/またはＵＴＲＡＮ２００のエレメントでの流れを妨害することになる(Ｓ１５)。

さらに、データソース７０は、リレイ機能モジュール８０ａ-８０ｎから伝達されたＲＴＣＰパケットがそれぞれの有線/無線のエンドポイント毎に一つずつ転送されると見なし、ＲＴＰパケット及びＲＴＣＰパケットの転送に要求される各帯域幅を適当に決定する(Ｓ１５)。

一方、ターミナル１００は、コアネットワーク３００を持つ無線アクセスベアラーを設定するプロセスで受信されるパケットの属性を既に認識している。その結果、受信されたＲＴＰパケットを備えた対応するターミナル１００は、無線転送の間のＲＴＰパケットの損失数、転送遅延時間などのような状態情報を含むＲＴＣＰパケットを発生させ、これをＲＮＣ１２ａ-１２ｎまたはリレイ機能モジュール８０ａ-８０ｎにフィードバックする(Ｓ１６)。

ＲＮＣ１２ａ-１２ｎまたはリレイ機能モジュール８０ａ-８０ｎは、無線でそれぞれのターミナル１００から転送されたＲＴＣＰパケットから獲得した受信状態情報に基づき、無線で各ターミナル１００に転送されたＲＴＰパケット上で転送操作を行う(Ｓ１７)。

一実施例において、ＲＮＣ１２ａ-１２ｎまたはリレイ機能モジュール８０ａ-８０ｎは、各ターミナル１００からデータソース７０に受信されたＲＴＣＰパケットをさらにフィードバックする。データソースは、以後に転送されるＲＴＰパケットのデータの大きさ、適当な符号化方式及び/またはその他を決定する時、各ターミナル１００からフィードバックする。

受信されるパケットがＲＴＣＰなしに利用されるＲＴＰまたは非リアルタイムパケットのとき、すなわち、リレイ機能モジュール８０が使用に不要な場合、ＲＮＣ１２ａ-１２ｎはコアネットワーク３００を介して受信されたパケットを無線の複数のターミナル１００に転送する(Ｓ１８)。ＲＴＣＰその自体が非使用される所で、受信されたＲＴＰパケットを備えたターミナル１００はＲＴＣＰパケットを発生させるための動作アクションを取らない。

これにより、本発明の説明から、リレイ機能モジュールを示すＵＴＲＡＮは、ＲＴＰ及びＲＴＣＰ動作を好適に行うために、有線の終端からデータソースにＲＴＣＰパケットを転送する。特に、各ユーザー設備から転送されたＲＴＣＰパケットは、ＵＴＲＡＮで操作され、データソースに転送されない。結果として、無線リソースの消費が防止され、インターネット上の衝突時パケット損失の数を正確に把握できる。よって、損失パケットの数は計数でき、パケットサービスを提供するために適当に制御できる。

本発明において、ＲＴＰパケットを制御するためのＲＴＣＰパケットが、有線のエントポイントとしてＵＴＲＡＮと無線のエントポイントとしてユーザー設備とから各々発生するため、有線及び無線の状態を容易に区別できる。よって、本発明は、有線及び無線のそれぞれの原因により、転送されるＲＴＰパケットのパケットの大きさ及び符号化方式を変更するように構成される。

例えば、データソースは、転送されるＲＴＰパケットの損失を減少させるために、転送されるＲＴＰパケットの大きさ及び符号化方式を適当に変更させることで、データ伝達量を適当に調節できる。さらに、有線の状況は有線を效率よく制御するために正確に把握される。

本発明において、ＵＴＲＡＮが無線を管理及び制御するため、無線自体は現在の無線の状態に適当なデータ伝達量及び符号化方式を調節できる。本発明において、有線及び無線の状態は互いに区別されることにより、リアルタイムデータパケットの損失が有線または無線で起きるか否かを正確に判断できるだけでなく、有線及び無線でそれぞれのパケット転送遅延時間を正確に判断できる。

本発明において、ＲＴＰ及びＲＴＣＰに対する帯域幅は正確に決定でき、全体ネットワークは有線の状態を理解することにより效率よく制御できる。本発明に係るシステムはＭＢＭＳに対して適当であるように修正される。ＭＢＭＳはリアルタイムデータを転送するためのＲＴＰ及びＲＴＣＰを利用する。その結果、本発明はシステムがＭＢＭＳに対する無線でユーザー設備を利用するために、リアルタイムパケットを放送/マルチキャストする時より効率的である。

つまり、本発明において、ＵＴＲＡＮがリレイ機能モジュールを利用する時、リレイ機能モジュールの動作制御のためのインジケーターは、リレイ機能モジュールの動作効率を改善するのにさらに使用される。よって、本発明は特定ＱｏＳを満足させるパケットサービスにより適する。

図６は本発明の好適な実施例による移動局のブロック図である。

図６を参照すれば、移動局５００は、プロセッサー(またはデジタル信号プロセッサー)５１０、ＲＦモジュール５３５、電力管理モジュール５０５、アンテナ５４０、バッテリー５５５、ディスプレイ５１５、キーパッド５２０、メモリ５３０、ＳＩＭカード５２５(選択事項)、スピーカー５４５及びマイクロホン５５０を含む。

例えば、キーパッド５２０のボタンを押下したり、或いは、マイクロホン５５０を用いて音声を活性化することにより、電話番号のような指示情報をユーザーが書き込む。マイクロプロセッサー５１０は、電話番号のダイヤルリングのような適当な機能を行うために指示情報を受信及び処理する。動作データは、ＳＩＭ(ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ)カード５２５又はメモリモジュール５３０から検索されて機能を行う。さらに、プロセッサー５１０は、ユーザーの好み及び便宜のためにディスプレイ５１５上に指示及び動作情報をディプレイする。

プロセッサー５１は、通信を開始するために、例えば、音声通信データを含む無線信号を転送するための指示情報をＲＦ部５３５に発行する。ＲＦ部５３５は無線信号を転送及び受信するための受信機及び転送機を含む。アンテナ５４０は無線信号の転送及び受信を容易にする。無線信号の受信時、ＲＦモジュール５３５は信号をプロセッサー５１により処理するためのベースバンド周波数に伝達及び変換する。処理された信号は、例えば、スピーカー５４５を介して出力される可聴または読出し可能な情報に変形される。

好適な実施例が具現されるコードは、転送媒体またはネットワークを介してファイルサーバーからよりアクセス可能である。この場合、コードが具現される製造物は、ネットワーク転送線、無線転送線、空間を通して伝播される信号、無線波、赤外線信号などのような転送媒体を含む。勿論、当該技術分野の熟練者は、本発明の要旨から逸脱しない範囲内で多様に修正でき、製造物が公知の任意の情報含有媒体を含むことを認識できる。

当該技術分野の熟練者は、多様な修正及び変形が本発明でなされることが理解できる。従って、本発明は、添付された特許請求の範囲の範囲内で提供される修正及び変形をカバーする。

本発明の追加的な理解を提供するために含まれ、本明細書の一部として合体される添付図面は、本発明の実施例を例示し、本発明の原理を説明する。
一般のＵＭＴＳのアーキテクチャーのブロック図である。 ３ＧＰＰ無線アクセスネットワーク仕様に基づいて、ユーザー設備及びＵＴＲＡＮ間の無線インターフェースプロトコルアーキテクチャーを示す。 本発明の一実施例によるリアルタイム/非リアルタイムパケットの流れを説明するＵＭＴＳの図である。 本発明の一実施例によるリアルタイム/非リアルタイムパケットの流れを説明するプロトコルアーキテクチャーの図である。 本発明の一実施例によるリアルタイム/非リアルタイムパケットを操作する順序図である。 本発明の好適な実施例による移動局のブロック図である。

符号の説明

７０ データソース
８０ａ−８０ｎ リレイ機能モジュール
１００ ターミナル
３００ コアネットワーク
５００ 移動局
５０５ 電力管理モジュール
５１０ プロセッサー
５２０ キーボード
５２５ ＳＩＭカード
５３０ メモリ
５３５ ＲＦモジュール
５４０ アンテナ
５４５ スピーカー５４５
５５０ マイクロホン
５５５ バッテリー

Claims (40)

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. 前記制御情報に基づいて前記有線通信線に対するサービスの品質を決定するステップをさらに含むことを特徴とする請求項３５に記載の実時間データ転送方法。
37. 前記有線通信線に対する前記サービスの品質に基づき、前記リアルタイムデータに対する転送要件を調節するステップをさらに含むことを特徴とする請求項３５に記載の実時間データ転送方法。
38. 前記調節ステップは、前記リアルタイムデータを含むリアルタイムデータパケットの転送の大きさを調節するステップを含むことを特徴とする請求項３７に記載の実時間データ転送方法。
39. 前記調節ステップは、前記リアルタイムデータのエンコーディングモードを調節するステップを含むことを特徴とする請求項３７に記載の実時間データ転送方法。
40. 前記調節は、リアルタイムデータが前記データソースから転送される時に行われることを特徴とする請求項３７に記載の実時間データ転送方法。

Images