JP2007521707A - Ｕｔｒａｎトランスポート・ネットワークにおけるマクロダイバーシチを扱う装置および方法 - Google Patents

Abstract

本発明はＵＭＴＳにおけるルータ、コンピュータプログラム製品および方法に関係する。ルータは、インターネット・プロトコル（ＩＰ）ベースのＵＭＴＳの地上無線アクセスネットワーク（ＵＴＲＡＮ）のトランスポート・ネットワークに存在する。ＵＴＲＡＮトランスポート・ネットワークは、ＲＮＣと少なくとも１つのノードＢとの間の専用チャネル（ＤＣＨ）においてＤＣＨフレームを搬送し、ルータはＩＰマルチキャスト・プロトコルを使用して、１つのＤＣＨトラフィック・フローを少なくとも２つのＤＣＨトラフィック・フローに分割する手段を含む。

Description

本発明は第３世代移動体通信システムおよびその進化した変形における装置と方法に関係する。さらに詳細には、本発明はＵＭＴＳ無線アクセス・ネットワーク（、ＵＴＲＡＮ）のトランスポート・ネットワークにおけるマクロダイバーシチを扱う装置および方法に関係する。

第３世代の移動体通信システム（ＵＭＴＳ）は、移動体ユーザに高品質音声およびデータサービスを提供する。またシステムは、大容量および世界的なサービスエリアを供給する。しかしながら状況によっては、信頼性に欠ける無線チャネルのため、その履行が困難となることがある。無線インタフェースを介するリンクの信頼性の問題と取り組む１つの有望な技術は、マクロダイバーシチ技術である。しかしながら、マクロダイバーシチはまた、セル方式ネットワークにおいて多元アクセス技術としてＣＤＭＡを使用する場合の本来的な帰結と見なされるべきである。ＣＤＭＡは干渉により制限される技術である。即ち、セル内の干渉により、セル容量の上限が設定される。干渉を可能な限り少なく保つために、基地局がセルの移動体端末の無線送信機出力電力を制御すること、即ち迅速で効果的な電力制御が必須である。移動体端末がセル周辺に向けて移動した場合、移動体端末はその無線送信電力を増加することで、基地局が送信信号を受信できるようにしなければならない。同様に、基地局は、移動体端末に対するその無線送信電力を増加しなければならない。この電力増加は、移動体端末自体のセル、および、移動体端末の近くの隣接セルの、両方の容量を悪化させる影響を与える。マクロダイバーシチは、この影響を緩和するために利用される。移動体端末が２以上の基地局を介して通信する場合、単一の基地局のみを利用する場合に比べて、より少ない無線送信電力で信号品質を維持できる。従って、マクロダイバーシチは、信頼性に欠ける無線チャネルの品質を向上させる特徴を有すると共に、ＣＤＭＡベースのセルラーシステムの本来的な弱点を克服するために不可欠な技術でもある。

図１は、ＵＴＲＡＮを示す図である。無線ネットワークコントローラ（ＲＮＣ）１０２、１１２は、コアネットワーク１００に接続される。コアネットワーク１００は、更に別のネットワークに接続されてもよい。ＲＮＣ１０２は、トランスポート・ネットワーク１０６を介して１以上のノードＢ（１０４）に接続される。このノードＢは、基地局ともいう。トランスポート・ネットワーク１０６は、例えばＩＰベースであってもよいし、あるいは、ＡＴＭベースであってもよい。ノードＢ（１０４）は、１以上のユーザ装置（ＵＥ）１１０に無線により接続されてもよい。このユーザ装置は、移動体端末ともいう。サービングＲＮＣ（Ｓｅｒｖｉｎｇ−ＲＮＣ、Ｓ−ＲＮＣ）１１２は、ＵＥ１１０と無線リソース接続（ＲＲＣ）を有するＲＮＣである。ドリフトＲＮＣ（Ｄｒｉｆｔ−ＲＮＣ、Ｄ−ＲＮＣ）１０２は、ＵＥ１１０と接続されてもよいＲＮＣであるが、別のＲＮＣ１１２、即ちＳ−ＲＮＣがＵＥ１１０とのＲＲＣ接続を扱う。

マクロダイバーシチは、移動局が２以上の無線リンクにより固定ネットワークと通信することを可能にする、即ち移動局が２以上の無線ポート（あるいはノードＢとも呼ばれる基地局）へ情報を送信し、該２以上の無線ポートから情報を受信することができる。無線ポート（ＲＰ）は短距離、例えば建物内の異なる階の間（ピコセル）から、約数キロメートル（マイクロセル、およびマクロセル）までの距離において空間的に分離される。移動体端末と異なるＲＰとの間の伝播条件は、同時刻においても異なるので、複数の受信信号の結合から得られる品質は、しばしば個々の信号の品質より良い。このようにして、マクロダイバーシチは無線リンクの品質を改善することができる。移動体端末が、２以上の基地局と同時に接続されると、ＵＥはソフトハンドオーバーにあるといわれる。

マクロダイバーシチは専用チャネル（ＤＣＨ）にのみ適用可能である。ノードＢにおける対応するソフターハンドオーバー機能を考慮しなければ、全ての現行マクロダイバーシチ機能はＲＮＣに存在する。ダウンリンクでは、ＲＮＣにおいて分割が行われ、関係するＤＣＨの動作中のセットの各経路を介した各ダウンリンクのＤＣＨ ＦＰフレームのコピーの送信が保証される。ＤＣＨ ＦＰデータフレームとＤＣＨ ＦＰ制御フレームの両方は、分割機能に従う。
アップリンクでは、ＲＮＣは結合を行う。この結合は、分割よりさらに複雑である。ＤＣＨ ＦＰデータフレームのみが結合手続に従う。各アップリンクＤＣＨ ＦＰ制御フレームは、個々のノードＢに特有の制御データを含むので、ＤＣＨ ＦＰ制御フレームは結合されない。アップリンクに対して、ＲＮＣは時間窓を有し、その間に全経路が、結合に負担（即ち所定の接続フレーム番号（ＣＦＮ）を有するＤＣＨ ＦＰフレーム）を提供することが期待される。時間窓が終了すると、時間窓の中で受信された正しいＣＦＮを有する全ＤＣＨ ＦＰフレームが結合機能に送られる。

実際の結合では、異なる経路を介して受信された候補の中から最良のデータ片が選択される。非音声ＤＣＨにとって、選択の単位はトランスポート・ブロック（ＴＢ）である。所定のトランスポート・ブロックについて選択する候補を決定するために、提供されたフレームのそれぞれにおいて関係するＴＢのＣＲＣＩがチェックされる。そのなかで、ＴＢがノードＢにおいて正しく受信されたこと（即ちノードＢにより受信されたとき、ＣＲＣチェックが関係するＴＢに対して成功すること）を示すＣＲＣＩが唯一存在すれば、そのＴＢが選択される。他に複数のＣＲＣＩが、ＣＲＣチェックが成功することを示せば、結合機能は、最大の品質評価（ＱＥ）パラメータを有するフレームに属する、これらのＴＢのうちの１つを選択する。同様に全てのＣＲＣＩが、ＣＲＣチェックが不成功であることを示せば、結合機能は最大のＱＥパラメータを有するフレームからＴＢを選択する。最後の２つの場合に、最大のＱＥパラメータ値が２以上のフレームで発見されると（即ち、これらのＱＥパラメータが等しければ）、ＴＢの選択は実装に依存する。図２は非音声ＤＣＨの結合手順を説明する。

音声ＤＣＨに対する結合動作は、少々異なる。適応型マルチレート（ＡＭＲ）通話コーデックは３つのサブフローを生成し、それぞれが各ＤＣＨにおいて転送される。これら３つのＤＣＨは所謂同格の (coordinated) ＤＣＨである。同格のＤＣＨは同じＤＣＨ ＦＰフレームに含まれ、フレームの各サブフローにはただ１つのＴＢが存在する。結合において、結合機能が異なる候補フレームから個別のＴＢを選択し、非音声ＤＣＨに関して上述したような新しい結合フレームを創出することはない。その代わりに、サブフロー１に関連するＴＢのＣＲＣＩに基づいて、最重要のサブフローである１つのフレーム全体を選択する。他のサブフローのＣＲＣＩは、これらのサブフローが無線インタフェース上でＣＲＣにより保護されないので、重要ではない。ここで再度、ＣＲＣＩがＣＲＣチェックの不成功を指示した場合、あるいは、関係する全ＣＲＣＩがＣＲＣチェックの不成功を指示する場合には、最大のＱＥパラメータを持つフレームが選択される。図３は音声ＤＣＨの結合手順を説明する。

このようにして、現在のＵＴＲＡＮにおけるマクロダイバーシチは、ＲＮＣではダイバーシチ・ハンドオーバー（ＤＨＯ）機能とも呼ばれるマクロダイバーシチ機能により実現される。現行標準は、サービングＲＮＣ（Ｓ−ＲＮＣ）とＤ−ＲＮＣとの双方におけるＤＨＯ機能を許容するが、Ｄ−ＲＮＣ機能にＤＨＯ機能を配する可能性は一般には使用されない。

従って、既存のマクロダイバーシチ・ソリューションの問題点は、ユーザデータの分割されたダウンリンクフローと非結合アップリンクフローとが、ＲＮＣとノードＢの間の全行程に亘って転送されることである。これは、高価な伝送リソースがＵＴＲＡＮトランスポート・ネットワークにおいて消費されることになり、またオペレータにとっても相当なコストになる。

本発明の目的は上記の課題を解決することである。

当該課題は、請求項１に記載のルータ、請求項１９に記載の方法、および、請求項４０及び４１に記載のコンピュータプログラム製品により解決され、ルータへのマクロダイバーシチ機能の分配が提案される。

ＵＭＴＳ内のインターネット・プロトコル（ＩＰ）ベースのＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）のトランスポート・ネットワークにおけるルータ（１０８）であって、ＵＴＲＡＮトランスポート・ネットワークがＲＮＣと少なくとも１つのノードＢとの間で専用チャネルによりＤＣＨフレームを搬送し、該ルータは、ＩＰマルチキャスト・プロトコルを利用して１つのＤＣＨトラフィック・フローを少なくとも２つのＤＣＨトラフィック・フローに分割する手段を備え、必要な伝送リソースの削減を可能にする。

ＵＭＴＳ内のインターネット・プロトコル（ＩＰ）ベースのＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）のトランスポート・ネットワークにおける方法であって、前記ＵＴＲＡＮトランスポート・ネットワークがＲＮＣと少なくとも１つのノードＢとの間で専用チャネル（ＤＣＨ）によりＤＣＨフレームを搬送し、前記方法は、ＩＰマルチキャスト・プロトコルを利用して１つのＤＣＨトラフィック・フローを少なくとも２つのＤＣＨトラフィック・フローに分割する工程を備え、必要な伝送リソースの削減を可能にする。

ＵＭＴＳ内のノードに含まれるコンピュータの内部メモリに直接ロード可能なコンピュータプログラム製品であって、本発明に対応し、上記方法を実行するためのソフトウエア・コード部分を備え、必要な伝送リソースの削減を可能にする。

コンピュータで利用可能な媒体に格納されたコンピュータプログラム製品であって、本発明に対応し、ＵＭＴＳ内のノードに含まれるコンピュータを制御して上記方法を実行させる読取可能なプログラムを備え、必要な伝送リソースの削減を可能にする。

本発明により達成される最も重要な利点はＵＴＲＡＮトランスポート・ネットワークにおける伝送の節約であり、これはオペレータにとり重要なコスト節約になる。伝送の節約はＤＨＯ機能の最適配置により実現される。その際、冗長なデータ転送は経路の一部において排除されるが、排除されなければ、同一ＤＣＨの異なるマクロダイバーシチの経路に関連するデータは、同一ルートに沿って並列に転送される。

本発明の別の利点は、（地理的分散を少なくして、）ＲＮＣのネットワークのより中央への配置を容易にすることである。現在のＲＮＣの一般的な地理的分散の主な目的は、並列マクロダイバーシチ経路の伝送経費を制限することである。この並列データ転送が排除されれば、オペレータが、例えばＭＳＣあるいはＭＧＷとの併設によりＲＮＣを集中化させることがより有利になる。同じ場所にいくつかのノードを併設すれば、運用と保守とが簡単化され、これはまたオペレータにとり経費の削減になる。

以下において、本発明の実施形態を示す添付の図面を参照して、本発明をより詳細に記述する。しかしながら、本発明は、ここで説明する実施形態のみに限定されるものとして解釈されるべきではない。むしろ、これらの実施形態は、本開示が完璧かつ完全となるように、また当業者に本発明の範囲を十分に伝えるように提供されている。全体を通じて、類似の番号は類似の要素を指す。

本発明は図１に示すようにインターネット・プロトコル（ＩＰ）ベースのトランスポート・ネットワークを有するＵＴＲＡＮにおいて実装することができる。ＩＰベースのトランスポート・ネットワークはバージョン４、６あるいは、将来バージョンのＩＰにより制御することができる。

必要とされる伝送リソースを削減するために、本発明はＲＮＣからＵＴＲＡＮトランスポート・ネットワークのルータに、マクロダイバーシチ機能を分散させることを提案する。ルータがマクロダイバーシチを処理すれば、トラフィック・フローの分割と結合はトランスポート・ネットワークの任意のルータにおいて実行することができる。しかしながらＲＮＣよりノードＢに近いトランスポート・ネットワーク・ルータを選択するのが有利である。これにより、図4に示すように冗長なデータ経路が削減され、伝送リソースが節約される。この例では、Ｄ−ＲＮＣはトラフィック・フローの経路には含まれないが、専用チャネル（ＤＣＨ）が確立されれば、（適用可能であれば）無線ネットワーク・サブシステムのアプリケーションパート（ＲＮＳＡＰ）及びノードＢ・アプリケーションパート（ＮＢＡＰ）の信号通報には含まれる。

上記のように、マクロダイバーシチを処理するルータには、ダウンリンクＤＣＨトラフィック・フローの少なくとも２つのダウンリンクＤＣＨトラフィック・フローへの分割と、少なくとも２つのアップリンクＤＣＨトラフィック・フローの１つの単一ＤＣＨトラフィック・フローへの結合と、を実行可能であることが要求される。これは以下にさらに詳しく記述される。

［ダウンリンクの分割］
ＵＴＲＡＮトランスポート・ネットワーク・ルータに存在する、本発明に対応するマクロダイバーシチ装置は分割ユニットを備える。分割ユニットは、ダウンリンク・トラフィック・フローを分割する手段を備え、分割にはＩＰマルチキャストが使用される。それはＩＰベースのトランスポート・ネットワークにおける本発明に対応するルータには、マルチキャスト性能が要求されることを意味する。各ＤＣＨは、要求に応じて確立されるそれ自体のマルチキャスト・ツリーを得る。トランスポート・ネットワークの本来のマルチキャスト性能、例えばトランスポート・ネットワーク層（ＴＮＬ）の機能は伝送の観点から最適分割を可能にするために使用される。従って、ダウンリンク接続はマルチキャスト接続であることが要求される。本発明によれば、その場合、従来技術におけるように各マクロダイバーシチの経路に１ＤＣＨ ＦＰフレームに代わって、ＲＮＣはダウンリンク接続において各ＤＣＨ ＦＰフレームの単一のコピーを送信することのみが要求される。分割ルータは各ＤＣＨ ＦＰフレームの単一のコピーを複写することにより分割を行い、マルチキャスト・プロトコルにより複写ＤＣＨ ＦＰフレームを送信する。

インターネット・プロトコルの現行および将来バージョンと共に使用することが考えられる、幾つかのマルチキャスト・ルーティング・プロトコルを使用することができる。マルチキャスト・ルーティング・プロトコルはマルチキャスト・パケットを転送するマルチキャスト・ツリーを構築するために必要である。可能なマルチキャスト・ルーティング・プロトコルの例にはプロトコル非依存のマルチキャスト−スパースモード（ＰＩＭ−ＳＭ）、コアベースのツリー・マルチキャスト・ルーティング・バージョン２（ＣＢＴｖ２）、距離ベクトルマルチキャスト・ルーティング・プロトコルバージョン３（ＤＶＭＲＰｖ３）およびマルチキャストＯＳＰＦ（ＭＯＳＰＦ）がある。本発明の実施形態ではＰＩＭ−ＳＭおよびＣＢＴｖ２が好ましい。

以下に記す実施形態では、記述を単に簡単にするためにマルチキャスト・ルーティング・プロトコルＣＢＴｖ２を使用するが、上記の他のマルチキャスト・ルーティング・プロトコルを使用しても良い。ＣＢＴｖ２マルチキャスト・ツリーは「コアルータ」、即ちＵＴＲＡＮのＲＮＣで始まり、そこからツリーは関係するＣＢＴｖ２ルータを通してエンドホスト、即ちノードＢへ広がる。ネットワークには多くのコアルータが存在し、それぞれトラフィックを存在するマルチキャスト・グループの全て、あるいは一部に転送する。

本質的な構成要素は、ＩＰｖ６のための、マルチキャスト受信者探索（ＭＬＤ）プロトコルである。ＭＬＤプロトコルはエンドホスト、即ちリンクの一定のマルチキャスト・アドレスを受信するノードＢの探索に利用される。従って、ＭＬＤプロトコルはノードＢとその隣接ルータとの間で使用することができる。ＩＰｖ４の場合、インターネットグループ管理プロトコル（ＩＧＭＰ）バージョン１、２、あるいは３を、ＭＬＤの代わりに使用しなければならない点に注意すべきである。

ＤＣＨトランスポート・ベアラーが確立されると、本発明では、ＲＮＣはこの特定のＤＣＨのためにダウンリンクのノードＢに対してマルチキャスト宛先アドレスを動的に割り当てることが必要である。ＵＴＲＡＮの全てのＲＮＣは、重複のない範囲のマルチキャスト・アドレスにより構成される。割り当てられたマルチキャスト・アドレスは関係するＲＮＣに対して構成された範囲から選択される。従って、各ダウンリンクＤＣＨトランスポート・ベアラーはノードＢにおいて、それ自体の専用マルチキャスト宛先アドレスを有する。ＮＢＡＰおよびＲＮＳＡＰは、マルチキャスト・アドレスの割り当てに使用できるが、その場合は、ＮＢＡＰおよびＲＮＳＡＰを変更することが必要である。従って、マルチキャスト・アドレスは、無線リンク設定要求、無線リンク再構成要求および無線リンク再構成準備などのメッセージにおける新しい情報要素（ＩＥ）であってもよい。

経路及びこれに伴う追加のノードＢが、ＤＣＨの動作中のセットに加えられると、これらノードＢは、動作中のセットの確立済みのノードＢと同じダウンリンクＤＣＨトランスポート・ベアラーのマルチキャスト宛先アドレスに割り当てられる。

図５は第１の経路の確立を示す図である。図６は第２の経路の確立を示す図であり、ここでＵＥはソフトハンドオーバー状態にある。結合ルータは、ノードＢからの最初のホップであるので、ＭＬＤあるいは対応するプロトコルで十分である。従って、マルチキャスト・ルーティング・プロトコルは必要ではない。

一度マルチキャスト・ツリーが確立されると、ルータのマルチキャスト転送能力は、各ダウンリンク・パケットのコピーがそれぞれ関係するノードＢに配信されることを保証する。

マルチキャスト・ツリーの機能は、各ルータにとり所定のマルチキャスト・アドレスのツリーを構築するコアルータ、即ちＵＴＲＡＮのＲＮＣが既知であることに依存する。この知識は、所定のマルチキャスト・アドレスを指示するマルチキャスト受信者レポートをルータが受信する際に使用される。この初期ステップの後、コアルータ・アドレス、即ちＲＮＣアドレスはメッセージによりツリーを介して伝達される。

マルチキャスト性能を有するルータにマルチキャスト・アドレスとコアルータとの間のマッピングを知らせる種々の方法が存在する。以下に、３つの異なる方法を説明する。本発明の好ましい実施形態に従い、ＣＢＴｖ２あるいはＰＩＭ−ＳＭブートストラップ機構が使用され、マルチキャスト・アドレスをコアルータにマッピングするのに必要な情報によりＣＢＴｖ２又はＰＩＭ−ＳＭのルータを自動的に構成する。別の実施形態では、各ルータは、マルチキャスト・アドレスをＲＮＣにマッピングする情報により手動で構成される。さらなる実施形態では、ＮＢＡＰを変更することができ、ＤＣＨが確立されるとコアルータであるＳ−ＲＮＣのＩＰアドレスは無線リンク設定要求、無線リンク再構成要求、あるいは、無線リンク再構成準備メッセージでノードＢに搬送される。次いでノードＢはＭＬＤバージョン３のソースフィルタの特徴を使用して、このコアルータ・アドレス、即ちＳ−ＲＮＣアドレスをルータに伝達する。マルチキャスト受信者レポートでは、ノードＢは、関係するマルチキャスト・アドレスについて、ソースとして指示されたＲＮＣを有するマルチキャスト・パケットにのみ関心があることを示している。次いでルータは、このマルチキャスト・ツリーのコアルータとなるＲＮＣを指示するものとして、この情報を解釈する。

このように、本発明によれば、マルチキャストはダウンリンクの分割に使用される。各ＤＣＨは、要求に応じて確立される自体のマルチキャスト・ツリーを取得する。ＩＰｖ６のマルチキャスト受信者探索（ＭＬＤ）プロトコル、あるいは、ＩＰｖ４のインターネットグループ管理プロトコル（ＩＧＭＰ）バージョン１、２あるいは３および幾つかのマルチキャスト・ルーティング・プロトコル（例えばＰＩＭ−ＳＭあるいはＣＢＴｖ２）のいずれかを利用して、伝送の観点から最適マルチキャスト・ツリーが構築される。このようにしてダウンリンク・トラフィックはこのマルチキャスト・ツリーを介して転送される。分割点はトランスポート・ネットワークのルータの間で、（伝送の観点から）最適に分散される。この手順は図５および図６に示される。

［アップリンクの分割］
ＵＴＲＡＮトランスポート・ネットワークのルータに存在するマクロダイバーシチ装置は、本発明の一実施形態によれば結合ユニットを備える。結合ユニットは、少なくとも２つのアップリンクＤＣＨトラフィック・フローを１つの単一アップリンクＤＣＨトラフィック・フローに結合する手段を備える。しかしながら、結合ユニットは、分割ユニットより複雑である。結合機能には、以下が含まれる。
ａ）ルータが、分割ポイントおよび結合ポイントの少なくともいずれかであることを検出するための手段。
ｂ）結合されるべきアップリンクを識別するための手段。
ｃ）ＤＣＨ ＦＰフレームを実際に結合するための手段。
ｄ）結合ルータが、未処理のフレームについて無制限に待機すること防止するための時間管理のための手段。

［分割／結合ポイントの確認］
マルチキャスト・ルーティング・プロトコルが、ＣＢＴｖ２およびＰＩＭ−ＳＭの両方が行うように、マルチキャスト・ツリーの構築プロセスにおいて逆経路転送原理を利用すれば、ルータがダウンリンク・マルチキャスト・ツリーの分割ポイントである、即ち分割ユニットを含めば、アップリンクユニキャストフローの結合ポイントである、即ち結合ユニットを含むこととなる。従って、ルータが、自身が分割ポイントであることを検出するための手段を備えれば、ルータは自身が結合ポイントであることを検出するための手段を自動的に含むこととなる。
分割ポイントは、ダウンリンクの方向に複数の受信者がいることにより特徴付けられる。ＣＢＴｖ２およびＭＬＤの機能により、ルータは離合するノードを記憶することができ、それにより特定のマルチキャスト・アドレスに対してルータが有する受信者数を判断できる。ＭＬＤプロトコルは、ある場合には、正しい数の受信者の判断を可能とするために変更を要する場合がある。この変更を要する場合とは、複数のノードＢが共通マルチアクセス・リンク、例えばイーサネット(登録商標)・リンクを介して同じルータに接続される場合である。この状況では、ＭＬＤの受信者レポート抑制機構は排除されなければならない。さもなければ、同じリンクの別のノードＢが同じマルチキャスト・グループの受信者レポートを最近に送信していた場合、ノードＢは、予定された受信者レポートをルータに送信しないこととなる。結果として、ルータは、リンクのマルチキャスト・グループの受信者数を知ることができなくなる。

従って、分割／結合ルータがノードＢに隣接する場合、分割／結合の確認はＭＬＤプロトコルによって行われる。さもなければマルチキャスト・ルーティング・プロトコルが必要である。

［アップリンク・トラフィック・フローの識別］
アップリンクの２つ以上の経路の結合を行うために、ルータは一定のダウンリンク・マルチキャスト・ツリーに対応するアップリンク・フローを識別するための手段を含まねばならない。本発明の好適な実施形態では、ダウンリンク宛先アドレスとして割り当てられるマルチキャスト・アドレスは、全ての関係するノードＢからアップリンク送信されるパケットのソースアドレスとしても使用される。従って、ＲＮＣは上記のごとく各ＤＣＨダウンリンクに固有のマルチキャスト宛先アドレスを割り当てる。関係する全てのノードＢが対応するアップリンクのソースアドレスとして、このマルチキャスト・アドレスを使用すれば、ＵＴＲＡＮトランスポート・ネットワーク・ルータは種々のアップリンク・フローに属するパケットを確認することができる。この方法は単純だが、しかしながら現行ＩＰｖ６標準はソースアドレスとしてマルチキャスト・アドレスを持つパケットを廃棄するので、ＩＰｖ６ルータは変更の必要がある。ＩＰｖ４とＩＰｖ４ルータにとって状況は類似する。

ノード同期手順のＤＣＨ ＦＰ制御フレームが、対応するデータＤＣＨ ＦＰフレームと同一のトランスポート・ベアラーに送信されると、ＲＮＣは、受信ＤＣＨ ＦＰ制御フレームの発信元ノードＢを識別しなければならない。これが関係するフレームのタイプはアップリンク・ノード同期制御フレームに限られる。各マクロダイバーシチ経路のトランスポート・ベアラーがＲＮＣに終端する現行ＵＴＲＡＮでは、発信元ノードＢのアイデンティティは、フレームを受信したトランスポート・ベアラーにより黙示的に示される。しかしながら、本発明によりＤＨＯ機能が分散されると、この方法は使用することができない。代わって発信元ノードＢを確認するために使用することができる別の方法は、ＤＣＨが確立された場合にマルチキャスト・アドレスを割り当てることに加えて、ＮＢＡＰにおいて既に指定されているパラメータを使用して、ＲＮＣがアップリンクで使用される宛先アドレスと宛先ポートを割り当てることである。正常な動作は、ＤＣＨアップリンクの動作中のセットの各経路に同じ宛先アドレスと、固有の宛先ポートを割り当てることである。しかしながら、全経路に同じ宛先ポートを割り当てることも可能である。後者の手法を取る１つの理由は、極めて大きなＲＮＣにおいてポート数がリソースを制限することになるリスクを小さくするためである。

アップリンク経路毎に固有の宛先ポートにより、フレームが到達するポートにおいて、（結合されない）アップリンク制御フレームの発信元ノードＢが黙示的に識別される。従って、アップリンクＤＣＨフレームの発信元ノードＢの識別は、ＤＣＨのアップリンクのノードＢにＲＮＣにより割り当てられる宛先ＩＰアドレスと宛先ＵＤＰポートとに基づく。これは好ましい動作であると思われる。

しかしながら、全経路に同じアップリンク宛先ポートを使用することが好ましく、そうする場合、発信元ノードＢは、ＩＰおよびＵＤＰヘッダのソースデータによってのみ識別される。ソースアドレスは全経路に対し同一なので、ソースポートのみが区別のための指標として残る。全経路のソースポートが確実に異なるようにするために、ソースポートはＲＮＣにより割り当てられねばならない。これは、各経路が確立されるとＮＢＡＰを介して行われる。従って、アッププリンクＤＣＨフレームの発信元ノードＢの識別は、ＤＣＨのアップリンクのためのノードＢに対し、ＲＮＣにより割り当てられたソースＵＤＰポートに基づくこととなる。

ここで、ＤＣＨユーザ・プレーン・データを搬送するトランスポート・ベアラーを介したノード同期手順の実行は不要な点にも注意すべきである。また、ノード同期フレームを別の高優先度ベアラーで送信し、測定において高い精度を達成することが可能である。この原理が維持され、ノード同期フレームに通常のユニキャスト接続が使用される限り、アップリンクＤＣＨ ＦＰフレームの発信元識別の問題は排除される。従って、このような場合、所定のＤＣＨの全経路のアップリンクに同一のソースアドレス及びソースポートを使用するのと同様に、同一の宛先アドレスと宛先ポートとを使用することが可能である。

本発明の一つの実施形態に対応する、アップリンク・フローを識別するための第２の方法は、ＲＮＣからアップリンク・フローの宛先アドレスと宛先ポートとを取得することである。宛先アドレスがダウンリンク・マルチキャスト・ツリーのコアルータであるため、該宛先アドレスはルータには既知であるが、宛先ポート情報はルータから明確に通報されねばならない。フレーム・フォーマット情報がルータに転送される場合、この情報が含まれても良い。

全経路が同一のアップリンク宛先ポートを使用すれば、これが必要な全てである。しかしながら、に異なるアップリンク宛先ポートを経路について使用すれば、フレーム・フォーマット情報と共にポート情報を転送しても十分ではない。このような場合、マルチキャスト・ツリーの新しい分岐がルータに追加されるたびに、結合ルータはＲＮＣからポート情報を取得しなければならない。

この方法が使用されるとき、発信元ノードＢの識別は問題にはならない。異なるアップリンク宛先ポート番号が異なる経路について使用されれば、発信元ノードＢは、少なくとも制御フレームについては宛先ポート番号において黙示的に示される。一方、全経路について同一のアップリンク宛先ポートが使用されれば、（この場合、各ノードＢは固有のソースアドレスを使用するので）発信元ノードＢはアップリンク・パケットのソースアドレスにより明示される。しかしながら、ノード同期制御フレームについて個々のユニキャスト・トランスポート・ベアラーを使用すれば、発信元ノードＢを識別する必要はなくなる。

本発明のさらなる実施形態に対応するアップリンク・フローを識別するための第３の方法は、ダウンリンク・フローに潜在するアップリンク・フローのアイデンティティを使用することである。この方法を使用することにより、結合ルータはＲＮＣからの明確な通知なしに、アップリンク宛先アドレスと宛先ＵＤＰポートとを通じてアップリンク・フローを識別することができる。これを機能させるためにＲＮＣは、動作中のセットの全ノードＢに同一のアップリンク宛先アドレスとポートとを割り当てねばならず、このアドレスとポートとのセットは、ダウンリンクで使用されるソースアドレスとポートとのセットと同一でなければならない。次いで結合ルータは、ダウンリンク・パケットのソースアドレスとポートとを参照して、アップリンク宛先アドレスとポートとを取得するように適合される。この方法では、全経路に共通のアップリンク宛先ポートが必要となるので、アップリンク・ソースアドレスに基づく発信元ノードＢの識別が必要とされる。しかしながら、ノード同期制御フレームについて個々のユニキャスト・トランスポート・ベアラーを使用すれば、発信元ノードＢを識別する必要はなくなる。

本発明のさらなる実施形態に対応するアップリンク・フローを識別するための第４の方法は、ＭＬＤ（あるいはＩＧＭＰ）プロトコルとマルチキャスト・ルーティング・プロトコルを変更し、アップリンク宛先ポートがマルチキャスト・ツリーの構築に使用されるメッセージ（例えば、ＭＬＤプロトコルのマルチキャスト受信者レポート・メッセージおよびＣＢＴｖ２のＪＯＩＮ＿ＲＥＱＵＥＳＴメッセージ）に含まれるようにすることである。

以上の第２、第３および第４の方法は、共にアップリンク・パケットのＵＤＰポート番号に基づく。さらに第２、第３および第４の方法は、より複雑あるいは効率に劣るが、ＩＰ原理には反しない。しかしながら、アップリンク・フローは当業者に既知の他の方法によっても識別することができる。

［実際の結合］
ルータが、自身が結合ポイントであることを検出すると、本発明によれば、関係するアップリンク・フローの選択及び結合を直ちに開始すべきである。実際の結合原理は、（ＲＮＣにおいて行われる）従来技術における実際の結合に類似する。主な相違は、ＲＮＣの代わりに結合ルータが結合を行うことである。結合手順は、従来技術のように非音声ＤＣＨと音声ＤＣＨとで異なる。

ルータが、自身が結合ポイントであることを検出したＤＣＨが非音声ＤＣＨであれば、結合を開始する前に、ルータはＲＮＣからフレーム・フォーマット情報を取得しなければならない。これは非音声ＤＣＨの選択単位が、上記のとおりＤＣＨ ＦＰフレームのほんの一部分、従ってＵＤＰパケットのほんの一部分を表すに過ぎないＴＢであるためである。ＴＢは各フレームにおいてトランスポート・フォーマット指標（ＴＦＩ）により記述される。

必要とされるフォーマット情報を取得するために、ルータは新しいアプリケーションレベル・プロトコルを使用してダウンリンク・マルチキャスト・ツリーのコアルータであるＲＮＣにコンタクトする。アプリケーションレベル・プロトコルは、プロトコルスタックにおいてトランスポートレベルより上、即ちユーザ・データグラム・プロトコル（ＵＤＰ）、通信制御プロトコル（ＴＣＰ）あるいはストリーム制御通信プロトコル（ＳＣＴＰ）などのトランスポート・プロトコルより上で動作するプロトコルである。アプリケーションレベル・プロトコルの例はＨＴＴＰであるが、アプリケーションレベル・プロトコルは幾つかのプロトコルを含む。ルータによる結合の実行のために必要な情報はＴＦＩであり、これはＤＣＨおよびＴＦＩのそれぞれのＴＢ数およびＴＢのサイズ（あるいはＴＢのセットのサイズ）とのマッピングに使用される。ＴＦＩの解釈は動的であり、おそらくはＤＣＨ毎に変わるので、ＴＦＩをルータにおいて事前に構成しておくことはできない。ＴＦＩは、ＲＮＣからＮＢＡＰを介してノードＢに通報される。また、ＤＣＨの送信時間間隔（ＴＴＩ）は、以下でさらに記すタイミング・アルゴリズムに対して有効な場合があり、よって、ルータは、ＲＮＣからＴＴＩをフレーム・フォーマット情報と共に取得してもよい。

ルータがフレーム・フォーマット情報を取得すると、アップリンク・フローの各フレームにおける個々のＴＢ、その関連するＣＲＣＩおよびＱＥパラメータを識別することができる。ルータは、現在ＲＮＣが行うのと同様の方法でＴＢを選択する能力を使用する。ＲＮＣと同様に、ルータはフレームヘッダのフレームタイプ指標をチェックし、全ての受信候補フレームが同じＣＦＮ値を持つことを保証するために制御フレームとＣＦＮの結合の試行を回避しなければならない。フレームタイプとＣＦＮはフレームヘッダに固定位置を有するので、その抽出は些細なことである。上記の実際の結合は従来技術に従って行われる。しかしながら、本発明と従来技術の相違はルータが新フレームを構築し、新フレームを新ＵＤＰパケットに配置し、それをＲＮＣに送信することである。

新フレームのヘッダは全ての受信候補フレームにおけるものと同一であり、ＴＢおよびそのＣＲＣＩは選択されたものである。結合ルータは新フレームのＱＥフィールドに含まれるべき候補フレームの品質評価（ＱＥ）値の中から最良（最大）のものを選択する。任意にペイロードＣＲＣが使用されれば、ルータは新フレームのための新たなペイロードＣＲＣを計算しなければならない。フレームヘッダは、ヘッダＣＲＣ、フレームタイプ指標、ＣＦＮおよびトランスポート・フォーマット指標からなる。このヘッダはペイロードのデータ品質に依存しない。従って、ヘッダは全候補フレームにおいて同じである。候補フレームは、この仕様ではある意味で結合手順において選択されるべき最良品質のデータを供給する候補である、同じＣＦＮを有する全てのフレームを意味する。ヘッダは全ての候補フレームについて同一なので、ヘッダは結果として得られる結合フレームにおいても変化なく維持される。しかしながら、候補フレームのペイロードは、品質が変化することのあるトランスポート・ブロック（ＴＢ）を含む。所定のＴＢの品質は、関連するＣＲＣ指標（ＣＲＣＩ）により示される。ＣＲＣＩは、ＴＢが無線インタフェースを介して基地局で受信されたときにＣＲＣチェックをパスしたかを示す。さらに、ＱＥはフレームの総合的品質を示す。ＱＥは、フレームのコンテンツが生ずる時間間隔に大体応じて基地局で測定される。ＱＥの値はビット誤り率と関連する。ＴＢは、全候補フレームから個別に選択される。ＴＢが候補フレームＸから選択されると、フレームＸの関連ＣＲＣＩもまた選択される。従って、結合フレームのヘッダは候補フレームと同一であり、候補フレームのＴＢは選択されたＴＢである。

従来技術では、結合の結果はフレームでは転送されない。従って、従来技術の結合では、ＱＥパラメータを転送のために選択する必要はない。しかしながら本発明の実施形態に対応する結合では、ＱＥパラメータは結合フレーム内に含まれねばならない。従って、本発明の実施形態では、ＱＥパラメータの選択ルールが必要となる。本発明の好適な実施形態では、候補フレームの最良（最大）のＱＥパラメータが選択される。この選択は、結合フレームの品質が候補フレームの最良の品質より通常良いことに基づく。それ故、結合フレームのＱＥパラメータが、候補フレームの最大のＱＥパラメータと少なくとも同等の大きさを有すると考えるのは妥当である。

結合フレームが構築されると、ルータは上記のように結合フレームを新ＵＤＰパケットに含めなければならない。上記のように、異なる経路、即ち異なる候補フレームについて、ＵＤＰソースおよび宛先ポートの少なくともいずれかが異なれば、ルータは受信候補フレームの１つからソースと宛先ポートとを選択しなければならない。本発明の好適な実施形態では、フローの全ての新ＵＤＰパケットに同一ポート番号が使用されるが、これはＩＰ／ＵＤＰヘッダの圧縮に最適の方法であるからである。続いてルータは、ＵＤＰパケットのＲＮＣへの送信前に、新ＵＤＰのチェックサムを計算しなければならない。

音声ＤＣＨの結合手順は、非音声ＤＣＨの場合に比べて最適化される。音声ＤＣＨ ＦＰデータフレームにおいてトランスポート・ブロックの数が固定化される限り、ルータはＲＮＣからフレーム・フォーマット情報を取得しなくとも良い。ルータは、ＴＴＩも取得しなくても良い。ＴＴＩは、固定化され、予測可能であり、例えば音声ＤＣＨの場合２０ｍｓである。このように、ＲＮＣからなんら情報を取得しなくても良い。音声ＤＣＨのＴＴＩおよびフレーム・フォーマットに関して必要な知識は、ルータにおいて予め構成される。

固定数のトランスポート・ブロック、例えば３、即ち各サブフローに１つ、を伴うフレームでは、選択の基本となるパラメータ、即ちトランスポート・ブロック・サブフロー１のＣＲＣＩおよびＱＥパラメータは、フレームの終端に対して固定位置にあるので、任意のペイロードＣＲＣが一貫して使用されないかあるいは常に使用されれば（決して使用されないのが好ましいが）、容易に抽出できる。

非音声ＤＣＨと比較した場合の音声ＤＣＨの手順の第二の最適化は、ルータが新フレームおよび新ＵＤＰパケットを構築しなくて良いことである。この理由は、選択単位が全ＵＤＰパケットに対応する全フレームであるからである。従って、本発明の一つの実施形態によれば、ルータは、自身が結合ポイントであることを検出するための手段と、アップリンク・フローを識別するための手段と、選択を行うための手段と、選択されたＵＤＰパケット（即ち、選択フレーム）を送信するための手段とを備え、結合ＤＣＨが音声ＤＣＨである場合に、ＲＮＣとは全くコンタクトしない。もし、ソース及び宛先ポートが全経路について同一でなければ、ありうべき最適化は、ルータに選択パケットのＵＤＰヘッダのポート番号を変更させ、ＵＤＰチェックサムを再計算させ、全ての選択ＵＤＰパケットが同一のソース及び宛先ポートを得るようにすることである。ＩＰ／ＵＤＰヘッダの圧縮の観点から、これはポート数の変更より適切であり好ましい。

結合ルータをＲＮＣに非依存にするために、結合ルータは、音声ＤＣＨと非音声ＤＣＨとを区別する手段を必要とする。本発明の一つの実施形態によれば、ＤＣＨのタイプを指示する簡単な方法は、音声ＤＣＨのダウンリンク宛先マルチキャスト・アドレスと等しい、専用のアップリンク・マルチキャスト・ソースアドレスを使用することである。例えば、音声ＤＣＨは奇数のマルチキャスト・ソースアドレスを使用することができるが、他のＤＣＨは偶数のマルチキャスト・アドレスを使用する。本発明の別の実施形態によれば、他の方法は、専用アップリンク宛先あるいはソースポートを使用することであり、この場合、例えば音声ＤＣＨには奇数番号のポートを使用し、他のＤＣＨには偶数番号のポートを使用する。本発明のさらなる実施形態によれば、ダウンリンク宛先ポート、即ち、音声に１つのデフォルトポートを使用し、非音声に１つのデフォルトポートを使用することも可能である。しかしながらこの場合、ルータは、ＤＣＨのタイプを判定するために、最初のダウンリンク・パケットを待たなければならない。

本発明の一つの実施形態によれば、音声ＤＣＨの実際の結合は、非音声ＤＣＨの結合より複雑ではないので、ルータは、音声ＤＣＨのアップリンク結合のみを行うことができ、非音声ＤＣＨは従来技術によりＲＮＣにおいて結合される。

［アップリンクフレームの結合のためのタイミング方式］
フレーム結合のタイミングは、未処理の候補フレームの到達までの待機時間を把握するための問題と関係する。待機時間が短ければ、遅れて来る候補フレームを見逃すリスクが大きくなる。一方、待機時間が長過ぎれば、得られる結合フレームがＲＮＣあるいは背後の結合ポイントに到達するのが遅すぎることになってしまう。ＲＮＣおよびノードＢは予め定義された手順により同期するが、これらの同期手順はトランスポート・ネットワーク・ルータを含まないことに注意すべきである。

結合タイミングに伴う困難性は、ルータがノードＢおよびＲＮＣと同期していないことから生じる。この結果、結合ルータは、結合するフレームの到達時間の窓を容易に定義できない。トリガーポイントは到達する最初の候補フレームでなければならない。次いでルータは、残りの候補フレームが他の経路から到達するまで待機しなければならない。従来技術におけるように結合がＲＮＣで行われる場合、ＲＮＣはＴＴＩの終わりまで待つが、しかしルータはそのような参照タイミングを持たない。

理想的には、ルータの待機中に最後の候補フレームが到達し、ルータはフレームを結合し、結果を送信する。しかしながら、フレームの１つ（あるいは複数）が到達しないと、問題が生じる。そこで、ルータのために最長待機時間を定義しておく必要がある。最長待機時間を、例えば最短ＴＴＩの３分の１と定義することは可能であるが、その待機時間は無意味である。無用な待機時間はトランスポート・ネットワークの最長遅延を不可避的に増加させる。また、全ての候補フレームが到達した場合でも最長待機時間が終了するまではルータが常に待機しない限り、遅延変動も増加する。

最長待機時間が終了するまでルータに待機させ、その後に受信した候補フレームのみを送信するようにした場合、ルータが２経路の結合ポイントであると仮定すると、問題がある。アップリンクに沿ってさらに第２の結合ポイントが存在すれば、フレームがその結合ポイントに到達するのが遅すぎることとなる。その場合、第２の結合ルータは、遅延フレームを好ましくは破棄するが、しかし転送することもある。第２の結合ルータが、そのフレームを転送すると、ＲＮＣは１つのフレームのみの受信を予想しているところに同一のＣＦＮを有する２つのフレームを受信する。その場合、ＲＮＣは２つのフレームを結合するか、あるいは、最後に受信された方を破棄することができる。

ＲＮＣが処理するには遅すぎる、即ち関係するＴＴＩの終了後に、フレームが非常に遅れて到達することがある。これを避けるには、ＲＮＣは終了時点を遅らせて到達時間の窓を広げることができる、しかしそうすると遅延が増大することになる。

本発明に対応する上述の問題を解決するための一つの方法は、結合ルータに、結合されるべきフレームのセット、即ち、所定の接続フレーム番号（ＣＦＮ）を有する予想されるフレームについて、適応最大許容到達時間（adaptive latest accepted time of arrival : LAToA）を定義させることである。目的は、LAToAをノードＮから結合ルータまでの経路においてフレームに対して許容される最大転送遅延に適合させることである。ここで、該最大転送遅延は、標準規格により許容される最大の転送遅延を滅多に超えることがないことを前提としている。妥当なＬＡＴｏＡを定義するために、結合ルータは、接続のためのＴＴＩを把握している必要がある。ＴＴＩは、上記のようにＤＣＨ ＦＰフレームフォーマットに関する必要な情報と共にＲＮＣから取得される。音声ＤＣＨについて、ＴＴＩは常に２０ｍｓであるので、フレーム・フォーマットと同様にＴＴＩをルータにおいて予め構成しておいてもよい。

一般に、ルータはＴＴＩを使用して、結合する次のフレームのセット、即ち所定のＣＦＮを有するフレームのセットのＬＡＴｏＡを、前のフレームのセット、即ち前のＣＦＮを有するフレームの到達時間に基づいて推定する。当該推定は、それぞれ新しいＣＦＮについて調整される。

結合タイミング方式の次の記述において、ＣＦＮは、ＣＦＮ０、ＣＦＮ１、ＣＦＮ２、．．．ＣＦＮｎ、ＣＦＮｎ＋１、．．．と番号付けされる。ＣＦＮに対応するパラメータは対応するインデックスを有する。

一般に、ＣＦＮｎの全候補フレームがＬＡＴｏＡ前に到達すれば、ルータは全候補フレームを結合し、ＬＡＴｏＡまで待つことなく結果を送信する。ＣＦＮ_nの全候補フレームがＬＡＴｏＡまでに到達しなければ、ルータは受信した候補フレームを結合し、結果を送信する。候補フレームが１つだけ受信されれば、そのフレームは変更されることなく転送される。フレームが受信されなければ、何も送信されない。

結合対象である最初のアップリンクフレームが時間ｔ₀に到達すると、ルータはＣＦＮ、ここでは受信フレームのＣＦＮ₀のＬＡＴｏＡをｔ₀＋△に設定する（このＬＡＴｏＡはＬＡＴｏＡ₀、即ちＬＡＴｏＡ₀＝ｔ₀＋△と表される）。ここで△はＴＴＩの一部である。

本発明によれば、後続するＣＦＮの一般規則は以下の２つの異なる場合に分けられる。

１．ＣＦＮ_nの全候補フレームがＬＡＴｏＡ_n前に到達した場合
この場合、ＣＦＮ_nの最後の結合フレームの到達時間ＴｏＡｏＬＣＦ_nがＬＡＴｏＡ_n−△より遅いか等しければ、即ちＬＡＴｏＡ_n−△≦ＴｏＡｏＬＣＦ_n≦ＬＡＴｏＡ_nであれば、その場合、ＬＡＴｏＡ_n+1はＬＡＴｏＡ_n+1＝ＴｏＡｏＬＣＦ_n＋ＴＴＩ＋△に設定される。一方、最後の結合フレームがＬＡＴｏＡ_n−△より前に到達した場合、即ちＴｏＡｏＬＣＦ_n＜ＬＡＴｏＡ_n−△であれば、ＬＡＴｏＡ_n+1はＬＡＴｏＡ_n+1＝ＬＡＴｏＡ_n＋ＴＴＩ−δに設定される。このとき、δは△の一部である。別の実施形態によれば、この一般規則に追加する規則は、ＬＡＴｏＡ−△−δ＜ＴｏＡｏＬＣＦ_n≦ＬＡＴｏＡ_n−△であれば、その場合ＬＡＴｏＡ_n+1はＬＡＴｏＡ_n+1＝ＴｏＡｏＬＣＦ_n＋ＴＴＩに設定されることである。

２．ＣＦＮｎの全候補フレームがＬＡＴｏＡ_nの前に到達しない場合
第２の場合においてＣＦＮ_nの全候補フレームがＬＡＴｏＡ_nに到達していないと、ルータはＣＦＮ_nの最後の結合フレームの到達時間に基づいてＬＡＴｏＡ_n+1をＴｏＡｏＬＣＦ_nに設定する。ＴｏＡＬＣＦ_nがＬＡＴｏＡ_n−△より遅いか等しければ（即ちＬＡＴｏＡ_n−△≦ＴｏＡＬＣＦ_n≦ＬＡＴｏＡ_n）、その場合ＬＡＴｏＡ_n+1はＬＡＴｏＡ_n+1＝ＴｏＡｏＬＣＦ_n＋ＴＴＩ＋△に設定される。一方、最後の結合フレームがＬＡＴｏＡ_n−△より前に到達した場合（即ちＴｏＡｏＬＣＦ_n＜ＬＡＴｏＡ_n−△）あるいは候補フレームが全く受信されなかった場合、ＬＡＴｏＡ_n+1はＬＡＴｏＡ_n+1＝ＬＡＴｏＡ_n＋ＴＴＩに設定される。その後ＣＦＮ_nの候補フレームがＬＡＴｏＡ_nの後、ＴｏＡＬＵＦ_n（即ちＣＦＮ_nの遅延した非結合フレームの到達時間）に受信されると、ＬＡＴｏＡ_n+1はＬＡＴｏＡ_n+1＝ＴｏＡｏＬＵＦ_n＋ＴＴＩ＋△に設定される。実際の遅延した非結合フレームの処理に関して、ルータは２つの選択肢を持つ：ルータは非結合フレームを変更せずに転送する、あるいは破棄することができる。好ましくは、帯域幅を浪費しないために、また、アップリンク上に更に存在する可能性のある第２の結合ルータを混乱させないためにも、ルータは非結合フレームを破棄すべきである。記載した結合タイミング方式は、図７および図８に図示される。△およびδの好ましい値の例は、δ＝１０μｓおよび△＝２５０μｓである。

この方式は、ルータが、ＬＡＴｏＡをノードＢと結合ルータとの間の経路においてフレームが経験しうる最長遅延に適合させ、フレームが予想より遅く到達すると、ルータは次のＬＡＴｏＡを調節する。フレームがベアラーのＱｏＳが許容するよりも長い転送遅延にさらされないと仮定すれば、これは正に所望されるものである。異常に遅延したフレームから復旧し、クロックドリフトに対処するために、全候補フレームが早く到達すると、他の方向にゆっくりと適応することもありうる（即ち次のＬＡＴｏＡを時間的に早く調整する）。δは、この目的に使用される。

タイミングの問題を回避する１つの方法は、サイレントモードおよびＤＴＸの少なくともいずれかが使用されていても、送信すべき正に受信したデータがない場合にもノードＢは常にフレームを送信することを保証することである。その場合ノードＢは長さゼロのＴＢを示すＴＦＩを使用する、あるいは、より好ましくはＣＦＮのみからなるフレームを送信する。後者の場合、ヘッダ圧縮を適用して得られるＩＰパケットはわずかに５バイトである。タイミングアルゴリズムを使用する代わりに、この機能を設けて、結合ルータは予想される全候補フレームの到達を常に待ち、その後フレームを結合することもできる。

不利な点は、たとえ小さなパケットでもデータが不要に送信されることである。シグナリング・メッセージを導入して、遠隔からこの機能をＲＮＣからオンおよびオフしない限り、接続がマクロダイバーシチモードでなくともこれは生じる。効果的なヘッダ圧縮のおかげで余計なパケットは非常に小さくなったとしても、マクロダイバーシチ機能をトランスポート・ネットワークのルータに移す本発明の主な目的そのものを妨げる。別の不利な点は、トランスポート・ネットワークにおいてフレームが失われる稀な事態が生じると、結合ルータは損失フレームを待ち続け、結果としてそのＣＦＮを持つ全フレームが破棄されることである。

そこで、本発明によれば、ＵＭＴＳ内のＩＰベースのＵＴＲＡＮトランスポート・ネットワークにおける方法であって、該ＵＴＲＡＮトランスポート・ネットワークがＲＮＣと少なくとも１つのノードＢとの間の専用チャネル（ＤＣＨ）においてＤＣＨフレームを搬送し、該方法は、ＩＰマルチキャスト・プロトコルを使用して１つのＤＣＨトラフィック・フローを少なくとも２つのＤＣＨトラフィック・フローに分割する行程を備える。

本発明に使用されるＲＮＣおよびルータについての方法および機能は、コンピュータプログラム製品により実装することができる。コンピュータプログラム製品は、１以上のノード、例えば本発明に対応する移動体通信ネットワークのルータあるいはサーバ内のコンピュータの内部メモリに直接ロード可能であり、本発明に対応する方法の工程を実行するソフトウエアコード部分を含む。コンピュータプログラム製品はコンピュータで利用可能な媒体にさらに格納され、本発明に対応する移動体通信ネットワークのルータ、サーバ、ＲＮＣあるいはノードＢ内のコンピュータを制御して本発明の方法の工程を実行させる読取可能なプログラムを含む。

図面と明細書において本発明の典型的な好適な実施形態を示し、特定の用語が使用されたが、それらは一般的、かつ説明の意味のみで使用され、制限する目的ではなく、本発明の範囲は上記の特許請求の範囲において明らかにされる。

ＵＭＴＳ地上無線アクセスネットワークの概要図である。 非音声ＤＣＨの結合手順を概略的に説明する図である。 音声ＤＣＨの結合手順を概略的に説明する図である。 本発明に対応するネットワークにおける潜在的な伝送の節約を概略的に説明する図である。 、 本発明に対応する第１および第２の経路の確立を概略的に説明する図である。 、 本発明に対応する結合のタイミング方式を概略的に説明する図である。

Claims (41)

1. ＵＭＴＳ内のインターネット・プロトコル（ＩＰ）ベースのＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）のトランスポート・ネットワーク（１０６）におけるルータ（１０８）であって、
   前記ＵＴＲＡＮトランスポート・ネットワーク（１０６）がＲＮＣ（１０２）と少なくとも１つのノードＢ（１０４）との間で専用チャネル（ＤＣＨ）によりＤＣＨフレームを搬送し、
   前記ルータ（１０８）は、ＩＰマルチキャスト・プロトコルを利用して１つのＤＣＨトラフィック・フローを少なくとも２つのＤＣＨトラフィック・フローに分割する手段を備える、ことを特徴とするルータ。
2. 各ＤＣＨフレームを複製する手段と、
   前記ＩＰマルチキャスト・プロトコルに従って前記複製されたＤＣＨフレームを送信する手段と
   を備えることを特徴とする請求項１に記載のルータ。
3. 前記ＩＰマルチキャスト・プロトコルが、コアベースのツリー・マルチキャスト・ルーティング・バージョン２（ＣＢＴｖ２）であることを特徴とする請求項１または２に記載のルータ。
4. 前記ＩＰマルチキャスト・プロトコルが、プロトコル非依存のマルチキャスト−スパースモード（ＰＩＭ−ＳＭ）であることを特徴とする請求項１または２に記載のルータ。
5. 各ＤＣＨトラフィック・フローに、１以上の前記ノードＢの専用マルチキャスト宛先アドレスが割り当てられることを特徴とする請求項１乃至４のいずれかに記載のルータ。
6. 前記分割する手段が、ＣＢＴｖ２あるいはＰＩＭ−ＳＭのブートストラップ機構を利用して、前記ＲＮＣと前記マルチキャスト宛先アドレスとの間のマッピングを識別する手段をさらに含むことを特徴とする請求項１乃至５のいずれかに記載のルータ。
7. 前記プロトコルＣＢＴｖ２およびＭＬＤの少なくともいずれかを利用して、前記ルータが分割ルータおよび結合ルータの少なくともいずれかであるかを判断する手段を備え、
   前記少なくとも１つのプロトコルは、特定のマルチキャスト宛先アドレスの受信者数を判断するために利用されることを特徴とする請求項１乃至６のいずれかに記載のルータ。
8. 前記プロトコルＰＩＭ−ＳＭおよびＭＬＤの少なくともいずれかを利用して、前記ルータが分割ルータおよび結合ルータの少なくともいずれかであるかを判断する手段を備え、
   前記少なくとも１つのプロトコルは、特定のマルチキャスト宛先アドレスの受信者数を判断するために利用されることを特徴とする請求項１乃至６のいずれかに記載のルータ。
9. 前記プロトコルＰＩＭ−ＳＭおよびインターネットグループ管理プロトコル（ＩＧＭＰ）の少なくともいずれかを利用して、前記ルータが分割ルータおよび結合ルータの少なくともいずれかであるかを判断する手段を備え、
   前記少なくとも１つのプロトコルは、特定のマルチキャスト宛先アドレスの受信者数を判断するために利用されることを特徴とする請求項１乃至６のいずれかに記載のルータ。
10. 前記プロトコルＣＢＴｖ２およびインターネットグループ管理プロトコル（ＩＧＭＰ）の少なくともいずれかを利用して、前記ルータが分割ルータおよび結合ルータの少なくともいずれかであるかを判断する手段を備え、
    前記少なくとも１つのプロトコルは、特定のマルチキャスト宛先アドレスの受信者数を判断するために利用されることを特徴とする請求項１乃至６のいずれかに記載のルータ。
11. ダウンリンク宛先アドレスとして割り当てられた前記マルチキャスト・アドレスを、関連する全てのノードＢからアップリンクＤＣＨトラフィック・フローにて送信されるＤＣＨフレームのソースアドレスとして利用することにより、異なるアップリンクＤＣＨトラフィック・フローに属するＤＣＨフレームを識別するための手段を備えることを特徴とする請求項１乃至１０のいずれかに記載のルータ。
12. 前記ＲＮＣより、前記アップリンクＤＣＨトラフィック・フローの前記宛先アドレスと前記宛先ポートとを取得することにより、異なるアップリンクＤＣＨトラフィック・フローに属するＤＣＨフレームを識別するための手段を備えることを特徴とする請求項１乃至１０のいずれかに記載のルータ。
13. 前記ダウンリンクＤＣＨトラフィック・フロー内に潜在するアップリンクフローの識別性を利用することにより、異なるアップリンクＤＣＨトラフィック・フローに属するＤＣＨフレームを識別するための手段を備えることを特徴とする請求項１乃至１０のいずれかに記載のルータ。
    
14. 前記アップリンクの前記宛先ポートが前記マルチキャスト・ツリーの構築に使用される前記メッセージに含まれるように、前記ＭＬＤまたはＩＧＭＰプロトコルと、前記マルチキャスト・ルーティング・プロトコルとを修正することにより、異なるアップリンクＤＣＨトラフィック・フローに属するＤＣＨフレームを識別するための手段を備えることを特徴とする請求項１乃至１０のいずれかに記載のルータ。
15. 少なくとも２つのアップリンクＤＣＨトラフィック・フローを１つの単一アップリンクＤＣＨトラフィック・フローに結合する手段を備えることを特徴とする請求項１乃至１４のいずれかに記載のルータ。
16. 前記結合する手段が、
    結合されるべき前記少なくとも２つのアップリンクＤＣＨトラフィック・フローにおいて受信したＤＣＨフレームのセットから、新しいＤＣＨフレームを構築する手段と、
    該新しいＤＣＨフレームをＵＤＰパケットにカプセル化する手段と、
    該ＵＤＰパケットを前記アップリンク方向に送信する手段と
    をさらに備えることを特徴とする請求項１５に記載のルータ。
17. 前記新しいＤＣＨフレームを構築する前記手段が、
    前記新しいＤＣＨフレームのペイロードに選択されたトランスポート・ブロック（ＴＢ）のセットを含める手段と、
    前記受信したＤＣＨフレームのヘッダーを前記新しいＤＣＨフレームにコピーする手段と、
    前記新しいＤＣＨフレームについて品質評価（ＱＥ）値を選択する手段と
    ペイロードＣＲＣが使用されている場合に、前記新しいＤＣＨフレームについてペイロードＣＲＣを算出する手段と
    を備えることを特徴とする請求項１６に記載のルータ。
18. 接続フレーム番号ＣＦＮ_n-1を有する前のフレームのセットの到達時間に基づいて、ＣＦＮ_nを有する、次の結合されるべきＤＣＨフレームのセットの許容到達時間（ＬＡＴｏＡ）を推定する手段と、
    前記ノードＢから前記結合ルータへの経路上の通常状況下でフレームが経験しうる最長の転送遅延に適合するように、それぞれ新フレームのＬＡＴｏＡの推定値を調整する手段と
    を備えることを特徴とする請求項１乃至１７のいずれかに記載のルータ。
    
19. ＵＭＴＳ内のインターネット・プロトコル（ＩＰ）ベースのＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）のトランスポート・ネットワークにおける方法であって、
    前記ＵＴＲＡＮトランスポート・ネットワークがＲＮＣと少なくとも１つのノードＢとの間で専用チャネル（ＤＣＨ）によりＤＣＨフレームを搬送し、
    前記方法は、ＩＰマルチキャスト・プロトコルを利用して１つのＤＣＨトラフィック・フローを少なくとも２つのＤＣＨトラフィック・フローに分割する工程を備える、ことを特徴とする方法。
20. 各ＤＣＨフレームを複製する工程と、
    前記ＩＰマルチキャスト・プロトコルに従って前記複製されたＤＣＨフレームを送信する工程と
    を備えることを特徴とする請求項１９に記載の方法。
21. 前記ＩＰマルチキャスト・プロトコルが、コアベースのツリー・マルチキャスト・ルーティング・バージョン２（ＣＢＴｖ２）であることを特徴とする請求項１９または２０に記載の方法。
22. 前記ＩＰマルチキャスト・プロトコルが、プロトコル非依存のマルチキャスト−スパースモード（ＰＩＭ−ＳＭ）であることを特徴とする請求項１９または２０に記載の方法。
23. 各ＤＣＨトラフィック・フローに、１以上の前記ノードＢの専用マルチキャスト宛先アドレスが割り当てられることを特徴とする請求項１９乃至２２のいずれかに記載の方法。
24. ＣＢＴｖ２あるいはＰＩＭ−ＳＭのブートストラップ機構を利用して、前記ＲＮＣと前記マルチキャスト宛先アドレスとの間のマッピングを識別する工程をさらに含むことを特徴とする請求項１９乃至２３のいずれかに記載の方法。
25. 前記プロトコルＣＢＴｖ２およびＭＬＤの少なくともいずれかを利用して、前記ルータが分割ルータおよび結合ルータの少なくともいずれかであるかを判断する工程を備え、
    前記少なくとも１つのプロトコルは、特定のマルチキャスト宛先アドレスの受信者数を判断するために利用されることを特徴とする請求項１９乃至２４のいずれかに記載の方法。
26. 前記プロトコルＰＩＭ−ＳＭおよびＭＬＤの少なくともいずれかを利用して、前記ルータが分割ルータおよび結合ルータの少なくともいずれかであるかを判断する工程を備え、
    前記少なくとも１つのプロトコルは、特定のマルチキャスト宛先アドレスの受信者数を判断するために利用されることを特徴とする請求項１９乃至２４のいずれかに記載の方法。
27. 前記プロトコルＰＩＭ−ＳＭおよびインターネットグループ管理プロトコル（ＩＧＭＰ）の少なくともいずれかを利用して、前記ルータが分割ルータおよび結合ルータの少なくともいずれかであるかを判断する工程を備え、
    前記少なくとも１つのプロトコルは、特定のマルチキャスト宛先アドレスの受信者数を判断するために利用されることを特徴とする請求項１９乃至２４のいずれかに記載の方法。
28. 前記プロトコルＣＢＴｖ２およびインターネットグループ管理プロトコル（ＩＧＭＰ）の少なくともいずれかを利用して、前記ルータが分割ルータおよび結合ルータの少なくともいずれかであるかを判断する工程を備え、
    前記少なくとも１つのプロトコルは、特定のマルチキャスト宛先アドレスの受信者数を判断するために利用されることを特徴とする請求項１９乃至２４のいずれかに記載の方法。
29. ダウンリンク宛先アドレスとして割り当てられた前記マルチキャスト・アドレスを、関連する全てのノードＢからアップリンクＤＣＨトラフィック・フローにて送信されるＤＣＨフレームのソースアドレスとして利用することにより、異なるアップリンクＤＣＨトラフィック・フローに属するＤＣＨフレームを識別するための工程を備えることを特徴とする請求項１９乃至２８のいずれかに記載の方法。
30. 前記ＤＣＨのアップリンクのために前記ＲＮＣによりノードＢに割り当てられた宛先ＩＰアドレスと宛先ＵＤＰポートとに基づいて、アップリンクＤＣＨフレームの発信元のノードＢを識別する工程を更に備えることを特徴とする請求項２９に記載の方法。
31. 前記ＲＮＣより、前記アップリンクＤＣＨトラフィック・フローの前記宛先アドレスと前記宛先ポートとを取得することにより、異なるアップリンクＤＣＨトラフィック・フローに属するＤＣＨフレームを識別するための工程を備えることを特徴とする請求項１９乃至２８のいずれかに記載の方法。
32. 前記ダウンリンクＤＣＨトラフィック・フロー内に潜在するアップリンクフローのアイデンティティを利用することにより、異なるアップリンクＤＣＨトラフィック・フローに属するＤＣＨフレームを識別するための工程を備えることを特徴とする請求項１９乃至２８のいずれかに記載の方法。
33. 前記アップリンクの前記宛先ポートが前記マルチキャスト・ツリーの構築に使用される前記メッセージに含まれるように、前記ＭＬＤまたはＩＧＭＰプロトコルと、前記マルチキャスト・ルーティング・プロトコルとを修正することにより、異なるアップリンクＤＣＨトラフィック・フローに属するＤＣＨフレームを識別するための工程を備えることを特徴とする請求項１９乃至２８のいずれかに記載の方法。
34. 前記ＤＣＨのアップリンクのために前記ＲＣＮによりノードＢに割り当てられたソースＵＤＰポートに基づいて、アップリンクＤＣＨフレームの発信元のノードＢを識別する工程を更に備えることを特徴とする請求項２９、３１、３２、または、３３に記載の方法。
35. ソースＩＰアドレスに基づいて、アップリンクＤＣＨフレームの発信元のノードＢを識別する工程を更に備えることを特徴とする請求項３１乃至３３のいずれかに記載の方法。
36. 少なくとも２つのアップリンクＤＣＨトラフィック・フローを１つの単一アップリンクＤＣＨトラフィック・フローに結合する工程を更に備えることを特徴とする請求項１９乃至３５のいずれかに記載の方法。
37. 結合されるべき前記少なくとも２つのアップリンクＤＣＨトラフィック・フローにおいて受信したＤＣＨフレームのセットから、新しいＤＣＨフレームを構築する工程と、
    該新しいＤＣＨフレームをＵＤＰパケットにカプセル化する工程と、
    該ＵＤＰパケットを前記アップリンク方向に送信する工程と
    をさらに備えることを特徴とする請求項３６に記載の方法。
38. 前記新しいＤＣＨフレームを構築する前記工程が、
    前記新しいＤＣＨフレームのペイロードに選択されたトランスポート・ブロック（ＴＢ）のセットを含める工程と、
    前記受信したＤＣＨフレームのヘッダーを前記新しいＤＣＨフレームにコピーする工程と、
    前記新しいＤＣＨフレームについて品質評価（ＱＥ）値を選択する工程と、
    ペイロードＣＲＣが使用されている場合に、前記新しいＤＣＨフレームについてペイロードＣＲＣを算出する工程と
    を備えることを特徴とする請求項３７に記載の方法。
39. 接続フレーム番号ＣＦＮ_n-1を有する前のフレームのセットの到達時間に基づいて、ＣＦＮ_nを有する、次の結合されるべきＤＣＨフレームのセットの許容到達時間（ＬＡＴｏＡ）を推定する工程と、
    前記ノードＢから前記結合ルータへの経路上の通常状況下でフレームが経験しうる最長の転送遅延に適合するように、それぞれ新フレームのＬＡＴｏＡの推定値を調整する工程と
    を備えることを特徴とする請求項１９乃至３８のいずれかに記載の方法。
40. ＵＭＴＳ内のノードに含まれるコンピュータの内部メモリに直接ロード可能なコンピュータプログラムであって、請求項１９乃至３９のいずれかに記載の方法をコンピュータに実行させるためのコンピュータプログラム。
41. ＵＭＴＳ内のノードに含まれるコンピュータに請求項１９乃至３９のいずれかに記載の方法を実行させるためのコンピュータプログラムを格納するコンピュータで読取可能な媒体。

Images