(57)【特許請求の範囲】
【請求項１】
パケットをマルチキャストする方法であって、
基地局と通信する２つのユーザ機器（ＵＥ）それぞれに対して、前記基地局にバッファを提供することであって、各バッファは、前記対応するＵＥに送付されるべきパケットを格納するように構成されることと、
ＵＥに送信されるべき新しいパケットが前記基地局にあるかどうか判定することであって、新しいパケットは過去に未送付のパケットであることと、
双方のＵＥバッファが空でないかどうか判定することと、
新しいパケットがないという条件で、かつ前記バッファの内の一つが空でないという条件で、空でないバッファをフラッシュすることと、
送信するべきパケットを選択することであって、
前記バッファが所定のバッファ容量に達した場合には、前記バッファ中の先頭のパケットを選択すること、
前記バッファが前記所定のバッファ容量に達ていない場合には、
過去に送信されたが双方のＵＥによって受信確認されていないパケットがないという条件、かつ双方のバッファが空でないという条件で、各バッファ中の先頭のパケットの排他的ｏｒ結合である結合パケットを選択し、
過去に送信されたが双方のＵＥによって受信確認されていないパケットがあるという条件で、当該パケットを選択し、および
過去に送信されたが双方のＵＥによって受信確認されていないパケットがないという条件で、かつ前記バッファの内の一つが空であるという条件で、新しいパケットを選択すること
を含むことと、
前記ＵＥから受信されたフィードバックに基づいて前記バッファを更新することであって、前記更新することは、前記ＵＥが前記パケットの受信を確認したという条件で、バッファからパケットを削除することとを含むことを特徴とする方法。
【請求項２】
前記フラッシュすることは、
前記バッファが空であるかどうか判定すること、
前記バッファが空でないという条件で、前記バッファからパケットを送信すること、
前記ＵＥから受信されたフィードバックに基づいて前記バッファを更新することであって、前記更新することは、前記ＵＥが前記パケットの受信を確認したという条件で、バッファからパケットを削除することを含むこと、および
前記バッファが空になるまで、前記フラッシュを繰り返すことを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記選択することは、
空でないバッファ中の先頭のパケットを調べること、
前記先頭のパケットが、最も直近に送信されたパケットよりも所定の数前のパケットであるかどうか判定すること、および
前記先頭のパケットが、前記最も直近に送信されたパケットよりも前記所定数のパケットであるという条件で、前記先頭のパケットを送信することを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記最も直近に送信されたパケットよりも前記所定の数前のパケットは、最大遅延値に対応することを特徴とする請求項３に記載の方法。
【請求項５】
パケットをマルチキャストするように構成された基地局であって、
前記基地局と通信中の２つのユーザ機器（ＵＥ）のそれぞれについての１つのバッファとなる、２つのバッファと、
新しいパケットが過去に未送付のパケットである、ＵＥに送信されるべき新しいパケットがあるかどうか判定し、
双方のバッファが空でないかどうか判定するように構成されたプロセッサと、
新しいパケットがないという条件で、かつ前記バッファの内の一つが空でないという条件で、空でないバッファをフラッシュするように構成されたバッファフラッシュ装置と、
パケットを選択するように構成されたパケットセレクタであって、
前記バッファが所定のバッファ容量に達している場合には、前記バッファ中の先頭のパケットが選択され、
前記バッファが前記所定のバッファ容量に達していない場合には、
過去に送信されたが双方のＵＥによって受信確認されていないパケットがないという条件で、かつ双方のバッファが空でないという条件で、各バッファ中の先頭のパケットの排他的ｏｒ結合である結合パケットが選択され、
過去に送信されたが双方のＵＥによって受信確認されていないパケットがあるという条件で当該パケットが選択され、
過去に送信されたが双方のＵＥによって受信確認されていないパケットがないという条件で、かつ前記バッファのうちの一つが空であるという条件で、新しいパケットが選択される、
前記パケットセレクタと、
前記ＵＥから受信されたフィードバックに基づいて前記バッファを更新し、
前記対応するＵＥによって前記パケットが受信確認されているという条件で、バッファからパケットを削除するように構成されたバッファ更新装置と、
パケットを送信し、フィードバック情報を受信するように構成されたトランシーバとを備えることを特徴とする基地局。
【請求項６】
前記バッファフラッシュ装置は、
前記バッファが空であるかどうか判定し、
前記バッファが空でないという条件で、送信用に前記バッファからパケットを選択し、
前記バッファが空になるまで、前記バッファのフラッシュを繰り返すように構成されることを特徴とする請求項５に記載の基地局。
【請求項７】
前記パケットセレクタは、
空でないバッファ中の先頭のパケットを調べ、
前記先頭のパケットは、最も直近に送信されたパケットよりも所定の数前のパケットであるかどうか判定し、
前記先頭のパケットは前記最も直近に送信されたパケットよりも前記所定の数前のパケットであるという条件で、前記先頭のパケットを選択するように構成されることを特徴とする請求項５に記載の基地局。
【請求項８】
前記最も直近に送信されたパケットよりも前記所定の数前のパケットは、最大遅延値に対応することを特徴とする請求項７に記載の基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示内容は、ワイヤレス通信システムに関する。
【背景技術】
【０００２】
ワイヤレス通信システムでは、マルチキャストにより、パケットが多数の受信機に配信される必要がある場合でも、送信機が一度しかパケットを送付しないことが可能になる。マルチキャストによりソースパケットが送付されたとき、典型的にはターゲットとされた受信機全部がソースパケットを復元するわけではない。既存プロトコルでは、全受信機がソースパケットを復元していない場合、パケットは再送信されなければならない。一部の受信機は、既に所有しているデータを復元するので、ソースパケットの再送信の実施は、ワイヤレスシステムにおいて非効率性をもたらす。
【０００３】
一般にレートレス符号（ＲＣ：Rateless Code。ファウンテン符号としても知られる）として知られる、近年開発された技法が、元のパケットの線形結合である「派生パケット」を送信することによって、この非効率性を回避する。レートレス符号化は、非特許文献１、非特許文献２、特許文献１（名称「Information additive code generator and decoder for communication systems」）、および特許文献２（名称「Multi-stage code generator and decoder for communication systems」）を含むいくつかの先行研究において記載され分析されている。このような技法は、受信機から送付機へのフィードバックが入手可能でないシステムにおいて公知であるが、自動再送リクエスト（ＡＲＱ：Automatic Repeat Request）およびハイブリッドＡＲＱ（ＨＡＲＱ：Hybrid-ARQ）プロトコルを含む、フィードバックを伴うシステムでの適用は公知でない。
【０００４】
現況技術をより理解するために、図１に示すワイヤレス通信システムモデル１００が説明される。基地局１１０が、ｍ個のユーザ機器（ＵＥ）１２０にいくつかのソースパケットｐ１，．．．，ｐｋの送付を希望すると仮定する。こうしたソースパケットは同じサイズであり、送信はマルチキャストを用いる。基地局１１０とｍ個のＵＥ１２０との間のワイヤレスチャネルは、たがいに独立している無記憶消失チャネル（memoryless erasure channel）である。ｉ＝１，．．．，ｍであるｅｉが、基地局１１０とＵＥ  ｉ１２０との間のチャネルの消失率を示すものとする。言い換えると、ＵＥ  ｉ１２０がパケットを受信する確率は１−ｅｉであり、ＵＥ  ｉ１２０がパケットを受信しない確率はｅｉである。ＵＥが物理層前方エラー訂正技術を用いてパケット中のすべてのビットを復元することができるわけではない場合、パケットは、紛失していると見なされる。各ＵＥ１２０は、単一ビットの肯定応答／否定応答（ＡＣＫ／ＮＡＣＫ）フィードバックを基地局に送付することができ、パケットが受信されたかどうかを基地局に知らせる。一般性を失わずに、基地局１１０は、タイムスロットの第１の部分でパケットを送付し、ＵＥ１２０は、タイムスロットの第２の部分でＡＣＫ／ＮＡＣＫを送付すると仮定される。
【０００５】
次に、ＲＣ無しの既存のプロトコルが説明される。プロトコル１は、ただ２つのＵＥ（すなわち、図１でｍ＝２）を有するワイヤレス通信システム１００における既存のプロトコルを記述し、プロトコル１ａは、プロトコル１を任意の数のＵＥに拡張する。
【０００６】
プロトコル１
【０００７】
図１に示すように、基地局１１０は、あるパケットに対して各ＵＥ１２０から少なくとも１つのＡＣＫを受信するまで、この同じパケットを再送信する。ソースパケットが再送信される場合、ＵＥは、ソースパケットのＡＣＫを一度より多く返してよいことに留意されたい。次いで、基地局１１０は、新しいパケットを送付する。プロトコル１は、全ＵＥ１２０が全ソースパケットを確実に受信するようにする。
【０００８】
プロトコル１の性能を評価するために、平均（期待）オーバーヘッドが計算される。オーバーヘッドは、ソースパケットの数に対する総パケット送信回数の比である。定義により、オーバーヘッドは１以上の数になり、より小さいオーバーヘッドが望ましい。プロトコル１によると、双方のＵＥがパケットを受信するまでの同じパケットの送信回数は、各ＵＥに個別に送付された場合、同じパケットの送信の多い方に等しい。これは、多数のＵＥに適用することもできる以下の説明において、数学的に表すことができよう。
【０００９】
Ｚは、双方のＵＥがパケットを受信するまでの同じパケットの送信回数とする。次いで、Ｚ＝ｍａｘ｛Ｘ，Ｙ｝とし、ここでＸ、Ｙはそれぞれのパラメータ１−ｅ１、１−ｅ２をもつ独立幾何ランダム変数である。具体的には、ｘ，ｙ＝１，２，．．．に対して、
【００１０】
【数１】
0005481201.tif 000002
かつ
【００１１】
【数２】
0005481201.tif 000003
である。全ｋ個のソースパケットが双方のＵＥによって受信されるようにプロトコル１で送付されるパケットの総数は、
【００１２】
【数３】
0005481201.tif 000004
で与えられ、
【００１３】
上式で、ＺｉはＺと同じ分布を有する独立ランダム変数である。したがって、この総数は、
【００１４】
【数４】
0005481201.tif 000005
と書くことができ、
【００１５】
上式で、Ｘ１，．．．，Ｘｋは、パラメータ１−ｅ１をもつ独立幾何ランダム変数であり、Ｙ１，．．．，Ｙｋは、パラメータ１−ｅ２をもつ独立幾何ランダム変数である。
【００１６】
式（１）で示すように、プロトコル１で送付されるパケットの平均数はｋＥ（Ｚ）で与えられ、プロトコル１の期待オーバーヘッドはＥ（Ｚ）で与えられる。
【００１７】
【数５】
0005481201.tif 000006
であると示すことができる。
【００１８】
プロトコル１は、任意の数のＵＥを有するマルチキャストモデルに以下のように適用することができる。
【００１９】
プロトコル１ａ
【００２０】
プロトコル１ａにおいて、プロトコル１は、多数のＵＥに拡張される。プロトコル１ａにおいて、基地局は、あるパケットに対してすべてのＵＥから少なくとも１つのＡＣＫを受信するまで、この同じパケットを再送信する。次いで、基地局は、新しいパケットを送付する。プロトコル１ａは、すべてのＵＥが全ソースパケットを確実に受信するようにする。このプロトコルの性能は、２つのＵＥに対してとられる手法と同様にして評価される。
【００２１】
本開示内容は、レートレス符号化プロトコルの使用と、こうしたプロトコルが、フィードバック情報が実際に存在するシステムにもたらす効率とを含む。どのパケットが受信され、どのパケットが受信されなかったかについてのフィードバック情報があることは、既存プロトコルでは実現されない重大な追加利点をもたらし得る。フィードバックデータが現在入手可能であるので、より優れたシステム効率を可能にするために、新たなマルチキャストプロトコルが必要である。
【先行技術文献】
【特許文献】
【００２２】
【特許文献１】米国特許第６６１４３６６号明細書
【特許文献２】米国特許第７０６８７２９号明細書
【非特許文献】
【００２３】
【非特許文献１】M. Luby, "LT codes", Proceedings of the ACM Symposium on Foundations of Computer Science, 2002
【非特許文献２】A. Shokrollahi, "Raptor codes", Proceedings of the International Symposium on Information Theory, 2004
【発明の概要】
【００２４】
受信機が一般の送信機にフィードバックを提供することができるシステム内でのパケットデータのマルチキャストが、本明細書で開示される。フィードバックが存在しないときにパケットデータをマルチキャストする方法が、既存プロトコルにおいて提案されている。こうした技法は概して、レートレス符号化（ＲＣ）アルゴリズムと呼ばれる。ただし、フィードバック、したがってどのパケットが受信され、どのパケットが受信されなかったかについての情報があることは、既存技法では実現されない追加利点をもたらし得る。
【００２５】
本開示内容は、既存のＲＣ概念を、受信機フィードバックを組み込むように向上させるフレームワークを含む。具体的ないくつかの実装形態が開発され、既存の３ＧＰＰ  ＨＳＤＰＡシステムを介してマルチキャストがどのようにして改善することができるかを実証することによって例示される。こうした概念は、ＨＳＰＡに関して説明されるが、当業者によって、３ＧＰＰ  ＬＴＥを含む、フィードバックを有するどのシステムにも拡張することができる。
【００２６】
本開示内容のより詳細な理解が、例として挙げられるとともに添付の図面と併せて理解されるべきである以下の説明から得られよう。
【図面の簡単な説明】
【００２７】
【図１】任意の数のＵＥを有するマルチキャストモデルを示す図である。
【図２】２つのＵＥを伴う送信プロトコルを示すフローチャートである。
【図３】多数のＵＥを伴う送信プロトコルを示すフローチャートである。
【図４】ＵＥグループを伴う送信プロトコルを示すフローチャートである。
【図５】ブロックパケット送信を伴う送信プロトコルを示すフローチャートである。
【図６】高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ）のチャネルエンコードチェーンを示す図である。
【図７】ＨＳ−ＤＳＣＨチャネル復号チェーンを示す図である。
【図８】結合パケット用のＨＳ−ＤＳＣＨチャネルエンコードチェーンを示す図である。
【図９】結合パケット用のＨＳ−ＤＳＣＨチャネル復号チェーンを示す図である。
【図１０】２つのＵＥのケースにおける異なるプロトコル結果を比較する第１のシミュレーションを示すグラフである。
【図１１】２つのＵＥのケースにおける異なるプロトコル結果を比較する第２のシミュレーションを示すグラフである。
【図１２】２つのＵＥのケースにおける異なるプロトコル結果を比較する第３のシミュレーションを示すグラフである。
【図１３】多数のＵＥのケースにおける異なるプロトコル結果を比較する第１のシミュレーションを示すグラフである。
【図１４】多数のＵＥのケースにおける異なるプロトコル結果を比較する第２のシミュレーションを示すグラフである。
【図１５】多数のＵＥのケースにおける異なるプロトコル結果を比較する第３のシミュレーションを示すグラフである。
【発明を実施するための形態】
【００２８】
本開示内容の特徴および要素が、異なるプロトコルにおいて説明されるが、各特徴または要素は、単独でも（プロトコルの他の特徴および要素を伴わずに）、他の特徴および要素を伴って、または伴わずに様々に組み合わせて利用することもできる。
【００２９】
これ以降で言及する場合、「ユーザ機器（ＵＥ）」という用語は、ワイヤレス送受信ユニット（ＷＴＲＵ）、移動局、固定もしくは携帯電話加入者ユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、コンピュータ、またはワイヤレス環境において動作することが可能な他のどのタイプのユーザ装置も含むが、それに限定されない。これ以降で言及する場合、「基地局」という用語は、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、またはワイヤレス環境において動作することが可能な他のどのタイプのインターフェイス装置も含むが、それに限定されない。
【００３０】
性能（オーバーヘッド）を向上させる新たな送信プロトコルが説明される。２つのＵＥに適用されるこうしたプロトコルが、最初に提示される。次いで、こうしたプロトコルの、多数のＵＥへの拡張が提示される。
【００３１】
レートレス符号化において、全パケットはレートレス符号化操作を通じて何回か有効に再送信されることを思い起こされたい。フィードバックが全く提示されない場合は正当化されるが、このような操作は、フィードバックが存在する場合は必要ない。本明細書に記載するプロトコルの全体的フレームワークは、以下の通りである。
【００３２】
最初に、各データパケットの１つのインスタンスを通常のやり方で送付する。あるいは、何らかの繰返し／レートレス符号化が、ほとんどのパケットの信頼できる配信を確実にするように、先験的に適用されてもよい。ただし、このような符号化の量（「符号によってもたらされる拡張」）は制限され、フィードバック無しのケースにおいて用いられるよりも小さくなるべきである。
【００３３】
パケットをバッファリングし、受信されなかったパケット、および（入手可能な場合は）どのＵＥがどのパケットを受信し損ねたかに関する情報を収集する。
【００３４】
ここで、レートレス符号化を用いて、受信されなかったパケットのみを、全ＵＥがパケットを復号する見込みが十分にあるように効率的に再送信する。
【００３５】
レートレス符号化をフィードバック情報と組み合わせることによって、より優れた送信効率が達成され得る。
【００３６】
高レベルシステムは、それぞれがＮ個の入力パケットを受け取り、単一の出力パケットを生じる１つまたはいくつかの「パケット符号器」を使用することに留意されたい。便宜上、以下のプロトコルは、それぞれが同じ数のビットを有するパケットに作用するＸＯＲ符号器を使用する。このようなパケット符号器は単に、同じビット位置を占める異なるパケット中のビットのＸＯＲをビット単位でとる。ただし、このような制限は、以下のように容易に緩和される。すなわち、パケットは長さが等しくなくてもよく、単純なＸＯＲとは異なる符号化操作が用いられてよい。
【００３７】
ＸＯＲ符号器の使用は、以前から存在する、ＲＣ概念を用いる設計において使われる際には好まれる。ただし、より複雑な符号器（たとえば、バイナリブロック符号器）が用いられてもよい。このような符号器は、ＸＯＲ符号器のように単一パケットを出力することができ、または（たとえば、バイト入力（８ビットパケット）に作用し、バイト出力を出力するリードソロモン符号におけるように）１組の出力パケットを出力することができる。本明細書で使用するように、複数のパケットを出力する符号器は、一連の符号器として扱ってもよく、単一の出力が、使われるために選択されてもよい。
【００３８】
ただし、パケット長問題が対処される必要がある。通信システムにおいて、複数のパケットはしばしば、同じ長さをもたず、この場合ＸＯＲ符号器は定義されない。この状態が起こると、パケットは、同じ長さになるようにレートマッチングされる必要がある。最も簡単な方法は、短い方のパケットを既知のビット（しばしばゼロだが、受信機側で知られているどのビット列を使ってもよい）でパディングすることである。代替手法は、たとえばパケットの連結および分割や、チャネル符号化など、他の操作へのＸＯＲ演算の統合など、より複雑な技法の使用を伴い得る。
【００３９】
プロトコル２
【００４０】
図２は、２つのＵＥを有するマルチキャストモデルによって記述される送信プロトコル２００（「プロトコル２」）のフローチャートである。プロトコル２は、プロトコル１より送信オーバーヘッドが低い。ＲＣおよびフィードバックを組み合わせることによって、オーバーヘッドに関してより優れた効率が達成される。
【００４１】
プロトコル２では、基地局は、ＵＥ用に損失パケットを格納するために、各ＵＥ用にバッファをセットアップする。「損失パケット」とは、送付されたがＵＥによって受信されていないパケットである。方法２００は始めに、新しいソースパケットがある（これまでに送付されていないことを意味する）かどうか、または双方のバッファが空でないかどうか判定する（ステップ２１０）。これが成り立つ場合、送付されたが双方のＵＥには受信されていないソースパケットがあるかどうか判定が行われる（ステップ２１２）。このようなソースパケットが存在する場合、基地局は、この損失ソースパケットを送信する（ステップ２１４）。このようなソースパケットが存在しない場合（ステップ２１２）、双方のＵＥ用のバッファが空でないかどうか判定が行われる（ステップ２１６）。双方のＵＥバッファが空でない場合、基地局は、バッファ中の２つのソースパケットの結合である結合パケットを送信する（ステップ２１８）。少なくとも一方のＵＥバッファが空である場合（ステップ２１６）、基地局は、新しいソースパケットを送信する（ステップ２２０）。ＵＥから受信されたＡＣＫ／ＮＡＣＫフィードバックに基づいて、基地局は、双方のバッファを更新する（ステップ２２２）。
【００４２】
新しいソースパケットが存在せず、少なくとも一方のバッファが空である場合、他方のバッファが空であるかどうか判定が行われる（ステップ２２４）。他方のバッファが空である場合、プロトコルは終了する（ステップ２２６）。他方のバッファが空でない場合、そのバッファにあるパケットが送信され（ステップ２２８）、そのバッファがフィードバック情報に基づいて更新される（ステップ２３０）。プロトコル２のこのセクション（ステップ２２４〜２３０）は、バッファに残っているどのパケットもフラッシュさせる。
【００４３】
プロトコル２には、「通常送信段階」および「バースト送信完了段階」という２つの段階がある。以前に送付されたことがない新しいソースパケットが存在し、または双方のバッファが空でない場合、プロトコルは「通常送信段階」にある。それ以外の場合、プロトコルは「バースト送信完了段階」にある。
【００４４】
通常送信段階では、各タイムスロット中に、基地局は、３つの手続き規則に従って、双方のＵＥにパケットをマルチキャストする。
【００４５】
規則１：双方のＵＥが最終タイムスロット中にパケットの損失を基地局に知らせた場合、基地局は、そのパケットを現在のタイムスロット中に再送信する。一方のＵＥからＡＣＫを、他方のＵＥからＮＡＣＫを受信すると、基地局は、今送付されたパケットを後者のＵＥ用のバッファに格納する。
【００４６】
規則２：双方のＵＥ用のバッファが空でない場合、基地局は、こうした２つのバッファ中の先頭のパケットの排他的ｏｒ（ＸＯＲ）を送信する。結合パケットの２つの成分パケットの一方のみが、各ＵＥにとって未知であることに留意されたい。したがって、結合パケットを受信すると、各ＵＥは、その結合パケットを、ＵＥが過去に受信したパケットの１つでＸＯＲをとることによって、その未知のパケットを復元することができる。一方または双方のＵＥからＡＣＫを受信すると、基地局は、適切なバッファ（群）から第１のパケットを削除する。
【００４７】
規則３：基地局は、過去に送付されたことがない新しいソースパケットを送信する。一方のＵＥからＡＣＫを、他方のＵＥからＮＡＣＫを受信すると、基地局は、今送付されたパケットを後者のＵＥ用のバッファに格納する。
【００４８】
バースト送信完了段階において、長い送信バーストの終了時には、少なくとも一方のＵＥが、ソースパケット全部を受信できている。他方のＵＥがまだソースパケット全部は受信していない、すなわち、そのＵＥ用のバッファが空でない場合、基地局は、そのＵＥ用のバッファをフラッシュする。具体的には、基地局は、そのＵＥからＡＣＫを受信するまで、バッファから同じパケットを再送信し続ける。次いで、基地局は、バッファ中の次の残存パケットを送付する。
【００４９】
プロトコル２の性能評価
【００５０】
プロトコル２の期待オーバーヘッドが以下で計算される。プロトコル２の規則３によって送付されるパケットは「正規パケット」と呼ばれ、送付されるそれ以外のパケットは「修復パケット」と呼ばれる。正規パケットの数は、ソースパケットの数ｋに等しい。
【００５１】
プロトコル２によると、通常送信段階の終了時にＵＥの一方が全ソースパケットを復元するわけではない場合、通常送信段階およびバースト送信完了段階双方における全修復パケットが、このＵＥがその損失パケットを復元する助けとなる。すべての修復パケットがこのＵＥ向けの１パケット分の未知の情報を含むので、このパケットは、再送信パケットと見なすことができる。したがって、プロトコル２における総送信回数は、各ＵＥに個別に送付される同じｋ個のパケットの送信回数の大きい方に等しい。これは、以下のように数学的に表すことができる。
【００５２】
Ｘ１，．．．，Ｘｋを、パラメータ１−ｅ１をもつ独立幾何ランダム変数とし、Ｙ１，．．．，Ｙｋを、パラメータ１−ｅ２をもつ独立幾何ランダム変数とする。すると、プロトコル２において送付されるパケットの総数が、
【００５３】
【数６】
0005481201.tif 000007
によって与えられる。
【００５４】
式（２）を式（４）と比較すると、プロトコル２において送付されるパケットの総数は、プロトコル１において送付されるパケットの総数より常に少ない。
【００５５】
２つの独立チャネルの消失率が異なり、たとえば、ｅ１＞ｅ２である場合、
【００５６】
【数７】
0005481201.tif 000008
となる。大数の弱法則（Weak Law of Large Numbers）から、ｋ→∞となるのに従って、
【００５７】
【数８】
0005481201.tif 000009
が
【００５８】
【数９】
0005481201.tif 000010
より大きくなる確率が１に近づくことになる。したがって、式（４）から、プロトコル２において送付されるパケットの平均数は、
【００５９】
【数１０】
0005481201.tif 000011
、すなわち、
【００６０】
【数１１】
0005481201.tif 000012
の平均値によって近似することができる。概して、プロトコル２の期待オーバーヘッドは、
【００６１】
【数１２】
0005481201.tif 000013
により近似される。
【００６２】
これが、達成可能な最小オーバーヘッドである。基地局が、ｍａｘ｛ｅ１，ｅ２｝の消失率で無記憶消失チャネルを介してＵＥにのみソースパケットを送付するケースを検討する。情報理論的視点から、このモデルに対する最小可能オーバーヘッドは、信頼できる送信に対しては
【００６３】
【数１３】
0005481201.tif 000014
となり、したがって、プロトコル２のオーバーヘッドはほぼ最適になる。
【００６４】
上記分析は、プロトコル２がより良好なチャネル条件をもつＵＥへの同じデータの送信を無償で行うことを示し、より悪いチャネル条件をもつＵＥにソースパケットを送信するのに用いられるのと同じ回数の送信が、いかなる追加オーバーヘッドも要求されることなく用いられることを意味する。同一チャネル条件のケースに対しては、同じ結果、すなわちｅ１＝ｅ２が得られる。
【００６５】
プロトコル２は、ただ２つのＵＥという状況で説明されたが、このプロトコルはｍ個のＵＥに拡張することが明らかであることに留意されたい。復号操作は、ＲＣ符号化用の従来技術の場合と同じである。エラーレートがｅ１，．．．ｅｍであるｍ個のＵＥの場合、
【００６６】
【数１４】
0005481201.tif 000015
である理論上の最小オーバーヘッドに近づき得ることが、従来技術から明らかであろう。
【００６７】
プロトコル２の変形
【００６８】
上に示したように、プロトコル２は、２つのＵＥを有するマルチキャストモデル用に最小可能オーバーヘッドを達成する。プロトコルを判断するのに用いることができる別の基準は、待ち時間である。
【００６９】
プロトコル１は、高いオーバーヘッドを生じるが、プロトコル２に比較して待ち時間は優れている。これは、プロトコル１では、基地局が、次のソースパケットが送付される前に双方のＵＥによるソースパケットの受信を確実にするからである。全ソースパケットが、双方のＵＥによって元の順序で受信される。
【００７０】
プロトコル２は遅延を意図的にもたらすので、プロトコル２は、待ち時間性能がプロトコル１より劣っている。受信されないパケットは、直ちに再送付されるわけではない。そうではなく、後で配信するためにバッファに格納される。
【００７１】
プロトコル１、２は、２つの極端なケースを表す。すなわち、一方は待ち時間は最良であるがオーバーヘッドが最悪であり、他方はオーバーヘッドは最良であるが待ち時間が最悪である。
【００７２】
プロトコル３
【００７３】
プロトコル３は、オーバーヘッドと待ち時間とを調和したものであり、プロトコル２に基づいている。プロトコル３によると、整数Ｄに対応する所定の最大遅延がある。ＵＥバッファ中の先頭のパケットが最後に送付されたソースパケットよりもＤ番前のパケットである場合、基地局は、この先頭のパケットを直ちに送付することを試みる。
【００７４】
プロトコル３において、基地局は、各ＵＥ用にバッファをセットアップする。各バッファは、送付されたが対応するＵＥによって受信されていないパケットを格納する。
【００７５】
プロトコル３には、「通常送信段階」および「バースト送信完了段階」という２つの段階がある。以前に送付されたことがない新しいソースパケットが存在する、または双方のバッファが空でない場合、プロトコルは「通常送信段階」にある。それ以外の場合、プロトコルは「バースト送信完了段階」にある。
【００７６】
通常送信段階では、各タイムスロット中に、基地局は、以下の手続き規則に従って双方のＵＥにパケットをマルチキャストする。
【００７７】
規則１：プロトコル２の規則１と同じ。
【００７８】
規則２：プロトコル２の規則２と同じ。
【００７９】
規則３：バッファが空でなく、このバッファ中の先頭のパケットが、最後に送付されたソースパケットより前のＤ番目のパケットである場合、基地局はこのパケットを送信する。適切なＵＥからＡＣＫを受信すると、基地局はこのパケットをバッファから削除する。
【００８０】
規則４：プロトコル２の規則３と同じ。
【００８１】
バースト送信完了段階では、規則はプロトコル２の場合と同じである。
【００８２】
最大遅延Ｄが無限大に設定された場合、プロトコル３は、プロトコル２と同じになる。各ＵＥは、異なる最大遅延要件を有し得る。たとえば、Ｄ１、Ｄ２は、それぞれ、ＵＥ１、ＵＥ２によって許容される最大遅延を示す。規則３は、ＵＥに対する遅延要件に基づいて調整される。
【００８３】
このプロトコルは２つのＵＥに関して説明されたが、任意の数のＵＥへの拡張が明らかであろう。
【００８４】
オーバーヘッドおよび待ち時間に加え、プロトコルを評価するのに用いられる別の基準は、プロトコルのメモリ使用である。プロトコル２では、バッファサイズに対していかなる制約も課されないことに留意されたい。このことは、特にソースパケットの数が多く、一方の消失チャネルが他方より優れた条件をもつケースでは、メモリの多大な使用を生じ得る。そうすることによって、メモリ停止を回避するために、基地局は、最大バッファサイズまたはバッファ容量を判定するべきである。バッファは、この容量に達した場合、直ちにクリアされるべきである。
【００８５】
プロトコル４
【００８６】
プロトコル４では、基地局は、各ＵＥ用にバッファをセットアップする。各バッファは、送付されたが対応するＵＥによって受信されていないパケットを格納する。双方のバッファは、最初は空であり、基地局は、バッファ容量Ｃを予め定める。このプロトコルは２つのＵＥに関して説明されるが、任意の数のＵＥへの拡張が明らかであろう。
【００８７】
プロトコル４には、「通常送信段階」および「バースト送信完了段階」という２つの段階がある。以前に送付されたことがない新しいソースパケットが存在する、または双方のバッファが空でない場合、プロトコルは「通常送信段階」にある。それ以外の場合、プロトコルは「バースト送信完了段階」にある。
【００８８】
通常送信段階において、各タイムスロット中に、基地局は、以下の手続き規則に従って双方のＵＥにパケットをマルチキャストする。
【００８９】
規則１：プロトコル２の規則１と同じ。
【００９０】
規則２：プロトコル２の規則２と同じ。
【００９１】
規則３：バッファがバッファ容量に達した場合、基地局は、バッファ中の先頭のパケットを送信する。適切なＵＥからＡＣＫを受信すると、基地局は、このパケットをバッファから削除する。
【００９２】
規則４：プロトコル２の規則３と同じ。
【００９３】
バースト送信完了段階において、プロトコル４は、プロトコル２と同じ作用をする。
【００９４】
プロトコル４は、バッファ容量が無限大に設定された場合、プロトコル２に帰着する。双方のバッファの容量は、プロトコル４において同じになるように設定される。ただし、総バッファサイズ制限が与えられると、統一容量割振り方式は、生じたオーバーヘッドによっては最良のものではなくなる場合がある。基地局は、Ｃ１＋Ｃ２≦２ＣであるＵＥ  ｉ、ｉ＝１，２に対して、バッファ容量Ｃｉを予め定める。次いで、それに従って規則３が調整されるべきである。
【００９５】
プロトコル２と比較して、プロトコル３およびプロトコル４は両方とも、そのオーバーヘッド性能を犠牲にして、待ち時間要件またはメモリ制限どちらかを満たす。プロトコル３およびプロトコル４は、待ち時間要件およびメモリ制限双方を満たすように組み合わせることができる。
【００９６】
パケット結合における変形
【００９７】
全ソースパケットは同じサイズであることが仮定され、この仮定は、プロトコル２〜４においてパケットのＸＯＲをとるのを容易にする。ソースパケット全部が同じサイズではない場合、ＸＯＲ演算は自明ではない。異なるサイズのパケットを結合するいくつかのやり方がある。こうした方法は、パケットが同じサイズであるときに用いることも、また、２つより多いパケットを結合するのに用いることもできることに留意されたい。
【００９８】
１．パケットの一部と別のパケットとのＸＯＲをとる。たとえば、ｌ１＞ｌ２のとき、ｐ１がｌ１ビットのパケットであり、ｐ２がｌ２ビットのパケットであると想定する。パケットｐ１とｐ２を結合するために、パケットｐ２をｌ１ビットまでゼロ詰めする。生じたパケットは、パケットｐ１とのＸＯＲをとられる。
【００９９】
２．ｑ＞２であるＧＦ（ｑ）において、求和演算およびモジュロ演算を実施する。
【０１００】
３．何らかの極大値を法として、正の整数の環において求和を実施する。
【０１０１】
４．長さが短い方のパケット中で、より大きいパケットに合わせるようにビットの繰返しを実施し、次いで、生じたパケットのＸＯＲをとる。
【０１０２】
当業者は、他の代替結合方法を考えつくことができよう。
【０１０３】
多数のＵＥ用のプロトコル
【０１０４】
上記プロトコルは、２つのＵＥのシナリオから多数のＵＥのシナリオへの修正を加えて適用することができる。
【０１０５】
プロトコル５
【０１０６】
プロトコル５は、プロトコル４に基づく。プロトコル５では、基地局は、各ＵＥ用にインデックスバッファをセットアップする。各インデックスバッファは、送付されたが対応するＵＥによって受信されていないパケットのインデックスを記録する。基地局はまた、バッファ容量Ｃを予め定める。Ｐｉ，ｊは、ｉ番目のインデックスバッファ（すなわち、ＵＥ  ｉ用のインデックスバッファ）のｊ番目の位置で記録されるパケットインデックスを示すものとする。インデックスバッファｉは、１≦ｊ≦ＣであるＰｉ，ｊ＞０の場合、満杯であると言われる。インデックスバッファｉは、１≦ｊ≦ＣであるＰｉ，ｊ＝０の場合、空であると言われる。最初は、全インデックスバッファが空である。
【０１０７】
図３は、プロトコル５  ３００のフローチャートである。プロトコル３００は始めに、まだ送付されていない新しいソースパケットがあるかどうか判定する（ステップ３１０）。このような新しいソースパケットが存在する場合、満杯のインデックスバッファがあるかどうか判定が行われる（ステップ３１２）。インデックスバッファのどれも満杯でない場合、基地局は、新しいソースパケットを送信する（ステップ３１４）。１つまたは複数のインデックスバッファが満杯である場合（ステップ３１２）、基地局は、バッファ中のインデックスをもついくつかのソースパケットの結合である結合パケットを送信する（ステップ３１６）。ＵＥからのＡＣＫ／ＮＡＣＫフィードバックに基づいて、基地局は、バッファを更新する（ステップ３１８）。
【０１０８】
新しいソースパケットがない場合（ステップ３１０）、基地局はバッファをフラッシュする。バッファをフラッシュするために、全インデックスバッファが空であるかどうか、判定が行われる（ステップ３２０）。インデックスバッファ全部が空である場合、プロトコルは終了する（ステップ３２２）。インデックスバッファの全部が空であるわけではない場合（ステップ３２０）、基地局は、バッファ中のインデックスをもついくつかのソースパケットの結合である結合パケットを送信する（ステップ３２４）。基地局は次いで、ＵＥから受信されたＡＣＫ／ＮＡＣＫフィードバックに基づいてバッファを更新する（ステップ３２６）。
【０１０９】
プロトコル５には、「通常送信段階」および「バースト送信完了段階」という２つの段階がある。以前に送付されたことがない新しいソースパケットが存在する場合、プロトコルは「通常送信段階」にある。それ以外の場合、プロトコルは「バースト送信完了段階」にある。
【０１１０】
通常送信段階では、インデックスバッファのいずれも満杯でない場合、基地局は、過去に送付されたことがない新しいソースパケットを送信する。ＵＥからＮＡＣＫを受信すると、基地局は、今送付されたパケットのインデックスを適切なＵＥインデックスバッファに記録する。
【０１１１】
１つまたは複数のインデックスバッファが満杯である場合（ｌ番目のインデックスバッファが満杯であると仮定する）、基地局は、いくつかのソースパケットのＸＯＲをとることによって構築されるパケットを送信する。結合用の成分ソースパケットの組のインデックスを判定するいくつかのやり方がある。
【０１１２】
結合用の成分ソースパケットの組のインデックスを判定する１つの方法は以下の通りであり、「アルゴリズムＡ」と呼ばれる。
【０１１３】
（１）１組の成分ソースパケットおよび１組の入手不可能なソースパケットを作成する。最初は双方の組が空である。
【０１１４】
（２）成分ソースパケットの組または入手不可能なソースパケットの組に含まれないパケットをランダムに選択する。
【０１１５】
（３）選択されたパケットを成分ソースパケットの組に加える。
【０１１６】
（４）選択されたパケットを有する同じＵＥバッファ中の他の全パケットを、入手不可能なソースパケットの組に加える。
【０１１７】
（５）双方の組が空になるまでステップ（２）を繰り返す。
【０１１８】
（６）成分ソースパケットの組にあるパケット全部のＸＯＲを送信する。
【０１１９】
成分ソースパケットの組は、すべてのＵＥに対して多くとも１つの損失パケットを含む。ＸＯＲで構築されたパケットを受信すると、ＵＥは、今受信されたパケットと、過去に受信されたパケットの一部とのＸＯＲをとることによって、その損失パケット（ある場合）の１つを復元することができる。ＵＥからＡＣＫを受信すると、基地局は、適切なバッファにある対応するパケットインデックスをゼロに設定する。
【０１２０】
このシナリオ向けの一停止基準は最小バッファ充填レベルであり、ここでは、バッファ全部が所定のレベルに削減されるまでアルゴリズムが稼働されることになる。当業者は、ＵＥ全部に対処する他の停止基準を導き出してよいことに留意されたい。
【０１２１】
バースト送信完了段階では、インデックスバッファ全部が空になるまで、基地局は、いくつかのソースパケットのＸＯＲをとることによって構築されたパケットを送信する。成分ソースパケットの組のインデックスは、アルゴリズムＡによって判定することができる。アルゴリズムＡのステップ（１）で用いられるバッファのインデックスｌは、
【０１２２】
【数１５】
0005481201.tif 000016
を最大にするものであり、この式で、Ｉはインジケータ関数である。ＵＥからＡＣＫを受信すると、基地局は、適切なバッファにある対応するパケットインデックスをゼロに設定する。
【０１２３】
バッファ容量Ｃが無限大に設定された場合、生じるプロトコルは、プロトコル２の多数のＵＥへの拡張である。
【０１２４】
送付されたソースパケットがいくつかのＵＥによって受信されない場合があるので、パケット自体よりもパケットインデックスをインデックスバッファに格納する方が、少ないメモリを使用することになる。
【０１２５】
ただ１つの成分ソースパケットがアルゴリズムＡによって選択される状況（たとえば、ある１つのソースパケットがＵＥ全部によって受信されていない）がある。また、アルゴリズムＡは、プロトコル５に対して最も小さいオーバーヘッドを生じさせることができない場合があることに留意されたい。インデックスバッファから成分ソースパケットを選択するいくつかの他の方法がある。第１の方法（これ以降、「アルゴリズムＡ．１」）が以下のように説明される。
【０１２６】
（１）充填されているバッファ（filled buffer）を有するＵＥ内の先頭のパケットを選択し、このパケットを送信することによって援助（ｈｅｌｐ）される他の全ＵＥを見つける。ＵＥは、そのバッファ中のパケットが送信され得るとき、「援助される」。これらを「発見ＵＥ」と呼ぶ。
【０１２７】
（２）空バッファをもつＵＥは無視する。
【０１２８】
（３）残りのＵＥから、最も充填されているバッファ（the most filled buffer）を有する次のＵＥを見つけ、発見ＵＥのバッファ中では網羅されない、そのエントリの１つを選択する。このようなエントリがない場合、残りのＵＥに対してこのステップを繰り返す。
【０１２９】
（４）この新しいパケットを送信することによって援助される全ＵＥを見つける。
【０１３０】
（５）ＵＥ全部が対処される（すなわち、ＵＥが空バッファをもつか、またはＵＥが発見ＵＥになる）まで、ステップ（３）から再度繰り返す。
【０１３１】
（６）選択されているパケット全部のＸＯＲを送信する。
【０１３２】
第２の方法（これ以降、「アルゴリズムＡ．２」）は以下の通りである。
【０１３３】
（１）充填バッファ（filled buffer）を有するＵＥ内の先頭のパケットを選択し、このパケットを送信することによって援助される他の全ＵＥを見つける。これらを「発見ＵＥ」と呼ぶ。
【０１３４】
（２）残りのＵＥから、１つのＵＥを任意に選択する。
【０１３５】
（２ａ）発見ＵＥのバッファ中では網羅されないエントリが、選択されたＵＥのバッファ中に存在する場合、このエントリを選択する。
【０１３６】
（２ｂ）選択されたＵＥを「発見ＵＥ」と呼ぶ。
【０１３７】
（３）この新しいパケットを送信することによって援助される全ＵＥを見つける。
【０１３８】
（４）ＵＥ全部が「発見ＵＥ」となるまで、ステップ（３）を繰り返す。これは、少なくとも１つのパケットが全ＵＥバッファから送信されたときに達成される。
【０１３９】
（５）選択されているパケット全部のＸＯＲを送信する。
【０１４０】
第３の方法（これ以降、「アルゴリズムＡ．３」）は以下の通りである。
【０１４１】
（１）空バッファをもつＵＥを無視する。
【０１４２】
（２）最少充填バッファ（the least filled buffer）を有するＵＥ内の先頭のパケットを選択し、このパケットを送信することによって援助される他の全ＵＥを見つける。これらを「発見ＵＥ」と呼ぶ。
【０１４３】
（３）残りのＵＥから、最少充填バッファを有する次のＵＥを見つけ、発見ＵＥのバッファ中では網羅されない、そのエントリの１つを選択する。このようなエントリがない場合、このステップを残りのＵＥに対して繰り返す。
【０１４４】
（４）この新しいパケットを送信することによって援助される全ＵＥを見つける。
【０１４５】
（５）ＵＥ全部が対処されるまで、ステップ（３）から再度繰り返す。
【０１４６】
（６）選択されているパケット全部のＸＯＲを送信する。
【０１４７】
全ＵＥインデックスバッファの容量は、プロトコル５において同じになるように設定される。総バッファサイズ制限が与えられると、プロトコル５における統一容量割振り方式は、生じたオーバーヘッドの点で最良にならない場合がある。基地局は、
【０１４８】
【数１６】
0005481201.tif 000017
であるｉ＝１，．．．，ｍのＵＥ  ｉに対してインデックスバッファ容量Ｃｉを予め定める。１≦ｊ≦ＣｉであるＰｉ，ｊ＞０の場合、インデックスバッファｉは「満杯」である。アルゴリズムＡ、Ａ．１、Ａ．２、Ａ．３は、それに従って調整されるべきである。
【０１４９】
プロトコル１ａおよびプロトコル５のオーバーヘッドを比較するシミュレーション結果が以下に挙げられる。こうした結果は、プロトコル５がプロトコル１ａより優れたオーバーヘッド性能を有することを示す。
【０１５０】
多数のＵＥのプロトコルに対する変形
【０１５１】
待ち時間要因は、プロトコル５では考慮されない。プロトコル５における、バッファ停止を回避するための作業は、待ち時間を暗黙的に削減し得るが、明示的作業がしばしば、待ち時間要件を満たすのに必要とされる。この目的のためには、プロトコル５が修正されればよい。
【０１５２】
プロトコル６
【０１５３】
プロトコル６は、プロトコル３に基づく。プロトコル６では、基地局は、各ＵＥ用にインデックスバッファをセットアップする。各インデックスバッファは、送付されたが対応するＵＥによって受信されていないパケットのインデックスを記録する。所定の最大遅延Ｄが存在する。Ｐｉ，ｊが、ｉ番目のインデックスバッファ（すなわち、ＵＥ  ｉ用のインデックスバッファ）のｊ番目の位置で記録されるパケットインデックスを示すものとする。Ｐｉ，ｊと最近送付されたソースパケットのインデックスとの間の差がＤより大きくなるような、Ｐｉ，ｊ＞０の場合、インデックスバッファｉは、「古い（ｏｌｄ）」と言われる。最初に、全インデックスバッファが空、すなわち、Ｐｉ，ｊ＝０と設定される。
【０１５４】
プロトコル６には、「通常送信段階」および「バースト送信完了段階」という２つの段階がある。以前に送付されたことがない新しいソースパケットが存在する場合、プロトコルは「通常送信段階」にある。それ以外の場合、プロトコルは「バースト送信完了段階」にある。
【０１５５】
通常送信段階では、インデックスバッファのいずれもが古くない場合、基地局は、過去に送付されたことがない新しいソースパケットを送信する。ＵＥからＮＡＣＫを受信すると、基地局は、今送付されたパケットのインデックスを、適切なＵＥインデックスバッファに記録する。１つまたは複数のインデックスバッファが古い場合（ｌ番目のインデックスバッファが古く、Ｐｌ，ｊがこのインデックスバッファ中で最も古いパケットであると仮定する）、基地局は、いくつかのソースパケットのＸＯＲをとることによって構築されるパケットを送信する。プロトコル５におけるアルゴリズムＡが用いられ得る。追加方法は、後で説明される。
【０１５６】
成分ソースパケットの組は、すべてのＵＥに対して多くとも１つの損失パケットを含むことに留意されたい。ＸＯＲで構築されたパケットを受信すると、ＵＥは、今受信されたパケットと、ＵＥが過去に受信したパケットの一部とのＸＯＲをとることによって、その損失パケット（ある場合）の１つを復元することができる。ＵＥからＡＣＫを受信すると、基地局は、適切なバッファにある対応するパケットインデックスをゼロに設定する。
【０１５７】
結合用に、成分ソースパケットの組のインデックスを判定するいくつかのやり方がある。プロトコル５におけるアルゴリズムＡは、プロトコル６に対して最も低いオーバーヘッドを生じさせない可能性がある。プロトコル５におけるアルゴリズムＡ．１、Ａ．２、Ａ．３は全部、プロトコル６に適用可能である。利用することができる追加アルゴリズム（「アルゴリズムＢ」）があるが、これは以下で説明される。
【０１５８】
（１）ＵＥバッファ中の最も古いパケットを選択し、このパケットを送信することによって援助されるＵＥ全部を見つける。これらを「発見ＵＥ」と呼ぶ。
【０１５９】
（２）空バッファをもつＵＥは無視する。
【０１６０】
（３）残りのＵＥバッファから、発見ＵＥのバッファ中では網羅されない、次に古いパケットを見つける。
【０１６１】
（４）このパケットを送信することによって援助される全ＵＥを見つける。
【０１６２】
（５）このような全パケットが対処されるまで、ステップ（３）から再度繰り返す。
【０１６３】
（６）選択されているパケット全部のＸＯＲを送信する。
【０１６４】
成分ソースパケットの組は、すべてのＵＥに対して多くとも１つの損失パケットを含む。したがって、ＸＯＲで構築されたパケットを受信すると、ＵＥは、今受信されたパケットと、そのＵＥが過去に受信したパケットの一部とのＸＯＲをとることによって、その損失パケット（ある場合）の１つを復元することができる。
【０１６５】
バースト送信完了段階において、インデックスバッファ全部が空でないときは常に、基地局は、いくつかのソースパケットのＸＯＲをとることによって構築されるパケットを送信する。成分ソースパケットの組のインデックスは、アルゴリズムＢによって判定することができる。バッファのインデックスｌ（アルゴリズムＢのステップ（１）で使われる）は、セット｛Ｐｉ，ｊ，ｉ∈｛１，．．．，ｍ｝｝中の、最も小さい正の整数を含むインデックスである。ＵＥからＡＣＫを受信すると、基地局は、適切なバッファにある対応するパケットインデックスを、ゼロに設定する。
【０１６６】
各ＵＥは、異なる最大遅延要件を有し得る。Ｄｉが、ＵＥ  ｉによって許容される最大遅延を示すものとする。Ｐｉ，ｊと最後に送付されたソースパケットのインデックスとの間の差がＤｉより大きくなるような、Ｐｉ，ｊ＞０の場合、インデックスバッファｉは「古い」ことになる。アルゴリズムＢは、それに従って調整されるべきである。
【０１６７】
プロトコル５およびプロトコル６は双方とも、そのオーバーヘッド性能を犠牲にして、メモリ制限または待ち時間要件いずれかを満たす。プロトコル５およびプロトコル６は、メモリ制限および待ち時間要件双方を満たすように組み合わせばよい。
【０１６８】
上で提案されたプロトコル全部が、ＵＥベースのバッファを使うことに留意されたい。ほとんどのシステム設計の一部として既に存在し得る、パケットベースのバッファを使うことも可能である。具体的には、基地局は、送付される各ソースパケット用にバッファをセットアップする。バッファの内容は、第１の試行ではこのソースパケットを受信しないＵＥのインデックスのリストである。
【０１６９】
プロトコル７
【０１７０】
プロトコル７において、基地局は、送付される各ソースパケット用にインデックスバッファをセットアップする。各インデックスバッファは、対応するソースパケットを受信しないＵＥのインデックスを記録する。基地局はまた、バッファ容量Ｃを予め定める。Ｐｉ，ｊが、ｉ番目のＵＥインデックスバッファ（すなわち、ｉ番目のソースパケット用のインデックスバッファ）のｊ番目の位置で記録されるＵＥインデックスを示すものとする。最初は、全インデックスバッファが空である。このプロトコルは、２つのＵＥに関して説明されるが、任意の数のＵＥへの拡張が明らかであろう。
【０１７１】
プロトコル７には、「通常送信段階」および「バースト送信完了段階」という２つの段階がある。以前に送付されたことがない新しいソースパケットが存在する場合、プロトコルは「通常送信段階」にある。それ以外の場合、プロトコルは「バースト送信完了段階」にある。
【０１７２】
通常送信段階において、インデックスバッファが容量Ｃに達しない場合、基地局は、過去に送付されたことがない新しいソースパケットを送信する。ＵＥからＮＡＣＫを受信すると、基地局は、このＵＥのインデックスを、現在のＵＥインデックスバッファに記録する。インデックスバッファが容量Ｃに達した場合、基地局は、いくつかのソースパケットのＸＯＲをとることによって構築されるパケットを送信する。上述したアルゴリズムＡ、Ａ．１、Ａ．２、Ａ．３、Ｂに加え、以下の方法（「アルゴリズムＣ」）が、結合用に成分ソースパケットの組を判定するのに用いられ得る。
【０１７３】
（１）最も充填されているバッファの状態のソースパケットを選択し、このパケットを送信することによって援助されるＵＥ全部を見つける。これらを「発見ＵＥ」と呼ぶ。
【０１７４】
（２）空バッファをもつソースパケットを無視する。
【０１７５】
（３）残っているソースパケットから、最も充填されているバッファを有するものと、発見ソースパケットのバッファ中では網羅されない、バッファ中の全エントリとを見つける。
【０１７６】
（４）送付された全ソースパケットが対処されるまで、ステップ（３）を繰り返す。
【０１７７】
（５）選択されているパケット全部のＸＯＲを送信する。
【０１７８】
成分ソースパケットの組は、すべてのＵＥに対して多くとも１つの損失パケットを含むことに留意されたい。ＸＯＲで構築されたパケットを受信すると、ＵＥは、今受信されたパケットと、そのＵＥが過去に受信したパケットの一部とのＸＯＲをとることによって、その損失パケット（ある場合）の１つを復元することができる。
【０１７９】
ＵＥからＡＣＫを受信すると、基地局は、対応するＵＥインデックスを適切なバッファから削除する。
【０１８０】
バースト送信完了段階では、インデックスバッファが空になるまで、基地局は、いくつかのソースパケットのＸＯＲをとることによって構築されるパケットを送信する。成分ソースパケットの組のインデックスは、上述したアルゴリズムＣによって判定することができる。ＵＥからＡＣＫを受信すると、基地局は、対応するＵＥインデックスを適切なバッファから削除する。プロトコル７は、追加待ち時間要件を満たすように修正することができることに留意されたい。
【０１８１】
グループベースのバッファを用いる送信
【０１８２】
各バッファが多数のユーザ、すなわち、ＵＥのグループにパケットを供給することができる、別のプロトコル変形が検討されてもよい。システムがサポートするであろうＵＥの数は概して、ＵＥグループの数より大きくなる。損失パケット用のバッファリング資源に関する限界がある場合は、このようなバッファリング方式が用いられてもよいであろう。
【０１８３】
ＵＥは、それぞれがＵＥグループバッファに対応する、いくつかのグループにグループ分けすることができる。このグループ分けは、固定の事前割当てでも、適合型グループ割当て手順によるものでもよい。バッファリング目的のためにＵＥをグループ分けするための基準の一部は、同じまたは同様の地理的な場所、同じまたは同様のシステム遅延サービス品質（ＱｏＳ）目標またはサービスレベル、同じまたは同様のシステムスループット（または帯域幅）ＱｏＳ目標またはサービスレベル、同じまたは同様のチャネル消失率、同じまたは同様の加入プランまたは支払いプラン、および上記基準のどの組合せも含み得る。追加グループ分け基準が検討されてもよい。
【０１８４】
ＵＥグループに基づくバッファリングおよび再送信方式は、送信されたどのパケットも、少なくとも１つのＵＥ、またはＵＥグループセットのサイズより小さい、所与の最小数のＵＥによって受信される場合に送信が十分に成功したと見なされるであろうマルチキャスト状況において有用であり得る。地理的に近いＵＥはサブネットワークを形成することができ、そうすることによって、基地局からマルチキャストパケットを受信するどのＵＥも、このようなパケットを、別のエアインターフェイスネットワーク、たとえばローカルエリア協調ワイヤレスネットワークを介して、ＵＥグループ内の他のＵＥに再送付することが可能になり得る。
【０１８５】
どれだけの数のＵＥグループにＵＥのいずれかが属し得るかに依存して、用いることができる２通りのＵＥグループ割当て方法がある。第１のケース、これ以降、「非重複ＵＥグループケース」では、ＵＥは、所与のいずれのときにも、ただ１つのＵＥグループに属してよく、そのＵＥに送信されるが失われるどのパケットも、ただ１つのＵＥグループバッファにバッファリングされることになる。比較的長い期間にわたって、ＵＥからＵＥグループへの、かつ対応するＵＥグループバッファへのマッピングは、変化することが認められることに留意されたい。所与のいずれのときにも、ＵＥグループ割当ては依然として、１対１に固定される。
【０１８６】
第２のケースでは、ＵＥは、異なるユーザグループに属してよく、その結果、ある特定のＵＥに向けられたが失われるパケットが、所与のいずれのときにも複数のユーザグループバッファにバッファリングされ得る。これは、「重複ＵＥグループケース」と呼ばれる。
【０１８７】
異なるＵＥグループに属す多数のＵＥに向けられたパケットがレートレス符号化用に処理され得るためのプロトコルが、説明される。
【０１８８】
プロトコル８
【０１８９】
多数のＵＥに対する「非重複ＵＥグループケース」を用いると、プロトコル５は、ＵＥグループベースの操作用に修正することができ、プロトコル８と呼ばれる。概して、プロトコル８は、あるパケット用の少なくとも１つのＡＣＫが、グループに属すＵＥのいずれかから受信される場合の、そのパケットのＵＥグループバッファのフラッシュを含むバッファ更新規則を変更する。
【０１９０】
図４は、プロトコル８  ４００のフローチャートである。プロトコル４００は始めに、まだ送付されていない新しいソースパケットがあるかどうか判定する（ステップ４１０）。このようなソースパケットが存在する場合、満杯のインデックスバッファがあるかどうか判定が行われる（ステップ４１２）。インデックスバッファのどれも満杯でない場合、基地局は新しいソースパケットを送信する（ステップ４１４）。１つまたは複数のインデックスバッファが満杯の場合（ステップ４１２）、基地局は、バッファ中のインデックスをもつ、いくつかのソースパケットの結合である結合パケットを送信する（ステップ４１６）。基地局は次いで、パケットに対する少なくとも１つのＡＣＫが、グループに属すＵＥのいずれかから受信された場合、そのパケットのＵＥグループバッファをフラッシュする（ステップ４１８）。
【０１９１】
双方のＵＥによってまだ受信されていないソースパケットがない場合（ステップ４１０）、基地局は、バッファをフラッシュする。バッファをフラッシュするために、全インデックスバッファが空であるかどうか判定が行われる（ステップ４２０）。インデックスバッファ全部が空である場合、プロトコルは終了する（ステップ４２２）。インデックスバッファ全部が空ではない場合（ステップ４２０）、基地局は、バッファ中のインデックスをもついくつかのソースパケットの結合である結合パケットを送信する（ステップ４２４）。基地局は次いで、ＵＥから受信されたＡＣＫ／ＮＡＣＫフィードバックに基づいてバッファを更新する（ステップ４２６）。
【０１９２】
プロトコル９
【０１９３】
「重複ＵＥグループバッファのケース」では、上記と同一であるプロトコルが依然として用いられ得る。この場合、同一のパケットは、２つ以上のＵＥグループバッファにバッファリングすることができる。ＵＥ（Ａ）が、２つのＵＥグループ、すなわちＵＥグループ１およびＵＥグループ２に属すと想定する。パケットＰがＵＥ  Ａに送付されたとき、このパケットは、ＵＥグループいずれのＵＥのいずれにも受信されなかったと想定する。同じパケットＰが、一方はＵＥグループ１用であり、他方はＵＥグループ２用である、２通りのＵＥグループバッファに持ち込まれることになる。その後の再送信（結合であっても非結合であっても）において、パケットＰは、ＵＥグループ２によってではなく、ＵＥグループ１に属すＵＥ（Ｂ）によって受信される。この場合、ＵＥグループ１用のバッファのみがパケットＰからフラッシュされることになる。
【０１９４】
ＵＥグループのいずれかへの任意のＵＥのグループ割当ては、基地局（ＢＴＳ）を用いて適応的に変えてよい。ＢＴＳは、ある特定のＵＥに関連づけられたグループ割当て基準（経験されたオーバーヘッド、待ち時間、メモリ、サービスレベル、または他の任意の基準など）を監視し、ＵＥが現時点で別のグループに最良に割り当てられるように特定のＵＥ基準値が変わった場合は、どのＵＥも別のグループに割り当て直すことができる。
【０１９５】
全部のＵＥがパケットを受信し、受信したことをＡＣＫで示しているわけではないときでも、バッファに対する更新の許可（すなわち、パケットのフラッシュ）が、ＵＥグループベースのバッファリングおよび送信を必ずしも伴わない状況において用いられ得ることに留意されたい。そうではなく、このようなバッファ更新方式は、より全般的には、パケット結合および／または再送信プロトコルから独立しているプロトコル２、３、４、５において示されるものを含む、どのタイプのバッファリング方式とも用いることができる。全ＵＥがパケットを受信する前にバッファをフラッシュ可能にさせることで、システムは、一部のＵＥに対する消去を有効に許可する。このようなバッファフラッシュ方式の利点は、待ち時間およびバッファメモリ要件の削減を含む。
【０１９６】
プロトコルをサポートするためのシステムアーキテクチャ
【０１９７】
通信システムにおけるいずれかの新しいアルゴリズムの採用成功の一側面は、アルゴリズムの操作をサポートするために要求される適切なシステム／プロトコルアーキテクチャ（すなわち、情報交換のための関連シグナリング）の設計である。以下では、ほとんどの通信システムに共通するであろうシステムアーキテクチャの側面が、本明細書において説明するプロトコルを使用して説明される。
【０１９８】
パケット情報シグナリングプロトコル
【０１９９】
対処される必要がある１つの問題は、どのソースパケットがどの送信パケットに含まれているかを、ＵＥにどのようにしてシグナリングするかである。
【０２００】
シグナリング機構
【０２０１】
どのパケットが送信されるかをシグナリングするのに、いくつかの標準手法が用いられてよい。関連制御および指示チャネル、たとえば高速データパケットアクセス（ＨＳＤＰＡ）における高速共有制御チャネル（ＨＳ−ＳＣＣＨ）が一例である。関連信号チャネルの時間インスタンスが、データ搬送チャネルの時間インスタンスと、公知のやり方で調和される。たとえば、ＨＳ−ＳＣＣＨ送信時間間隔（ＴＴＩ）は、ＨＳ−ＳＣＣＨが情報を搬送する高速物理ダウンリンク共有チャネル（ＨＳ−ＰＤＳＣＨ）ＴＴＩより前の２つのスロットである。ある送信において結合されたパケットについての情報が、関連するチャネルによって搬送される。送信が新しいデータパケットであるか、それとも再送信であるかをシグナリングするインジケータと、異なる結合方式が用いられ得る場合は、結合方式インジケータフィールドと、可変長のパケットが使われ得る場合は、長さの値、またはより全般的には移送形式インジケータフィールドとを含む付加情報が任意選択で搬送されてもよい。
【０２０２】
あるいは、このような情報は、ヘッダーの形でデータチャネルに直接組み込んでもよい。
【０２０３】
シグナリングの方法
【０２０４】
どのパケットが結合されているかをシグナリングするために、パケットがインデックスを付けられると仮定される。インデックスは、少なくとも「スーパーフレーム」（このケースでは、インデックスは短く、繰返し期間が短い）にとって一意であるべきであり、または長いシーケンス番号などの長いパケットインデックスが使われてもよい。
【０２０５】
各送信ごとに、送信において結合される各パケットのパケットインデックスは、シグナリングされる必要がある。長いシーケンス番号が使われる場合は、再送信用にパケットが含まれるときは適切な剰余演算により短くしてよい。
【０２０６】
いくつかのシグナリング方法が用いられ得る。第１に、パケットインデックスおよびシーケンス番号は、直接列挙することができる。単一の送信物に結合されるソースパケットの数は、１つの関連制御チャネル上であまりにも多くの制御情報を搬送することを回避するように制限すればよい。第２に、スーパーフレーム中の各パケット用の１ビットを有するビットフィールドが用いられてよく、セットされたビットは、どのパケットが現在の送信に含まれるかを示す。ビットフィールドは、ハフマンまたは算術符号器を、高エントロピー符号器を用いてさらにランレングスエンコードしてよい。
【０２０７】
同期側面およびユーザダイナミクス
【０２０８】
同期シグナリングの可用性が、堅牢なシステム動作ならびにユーザダイナミクス（ユーザが、マルチキャストサービスに入る／出る）双方をサポートするのに用いられる。同期を確立し維持するための方法は、スーパーフレーム境界を確立することによるものである。スーパーフレームとは、（通常、およそ１００ミリ秒から数秒の）時間間隔である。再送信の目的のために、同じスーパーフレーム中のパケットのみが結合され得る。シグナリングプロトコルは概して、新しいスーパーフレームの始まりを識別する単純なやり方を含むことになる。したがって、同期を確立し、または確立し直す必要があるどのＵＥも、スーパーフレーム境界では常に同期を確立してよい。
【０２０９】
別の代替法は、たとえばＭＰＥＧストリームなどのマルチメディアデータを送信したとき、符号化が一部の自然同期フレームを含めるものであり、このケースでは、こうしたフレームの始まりは、同期を達成する手段として用いてよい。
【０２１０】
フィードバックエラー処理
【０２１２】
上述したアルゴリズムは、フィードバック中にはいかなるエラーも起こらないと仮定するが、これは非現実的である。以下の修正は、システムが確実にフィードバック中のエラーを扱うことができるようにする。
【０２１３】
上述した具体的なアルゴリズムは、ＡＣＫおよびＮＡＣＫ信号双方が各ＵＥから受信され、フィードバックがそこから発したＵＥが識別され得るようにフィードバックがタグ付けされると仮定したが、これは必要ない。実際、ＮＡＣＫのみまたはＡＣＫのみをフィードバックし、もう一方は暗黙であるなど、いくつかの他の可能性が存在する。これは、共有ランダムアクセスチャネルがフィードバック用に使われる場合に特に有用である。フィードバックエラーが対処されるためのプロセスは、フィードバックのタイプに依存する。
【０２１４】
フィードバックタイプの別の可能性は、ブロックＡＣＫおよび／またはＮＡＣＫを使うものである。ブロックＡＣＫ／ＮＡＣＫは、消失率がシステム内で十分に低いことが知られている、または比較的長い待ち時間が容認されてよい状況において有用であろう。ブロックＡＣＫは、１つのブロックとして送信される一連のパケットを受信すると送付されるが、受信されたパケットにそれぞれが対応する多数のＡＣＫを含むことになる。たとえば、１から１０まで番号が振られた１０個のマルチキャストパケットが基地局から送信されたと想定する。ＵＥ「Ａ」はパケット１、２、３、５、７、９を首尾よく受信したがパケット４、６、８、１０は受信しなかったと想定する。どのパケットが首尾よく受信されたかを基地局に示すために、ＵＥ「Ａ」は、パケット１、２、３、５、７、９を首尾よく受信したことを示す、１０個のパケット用のブロックＡＣＫを送付すればよい。あるいは、ＵＥ「Ａ」は、パケット４、６、８、１０が受信されなかったことを示すブロックＮＡＣＫを送付してもよい。
【０２１５】
上述したプロトコルおよびアルゴリズムは、パケットのブロック（非結合再送信および結合再送信を含む）を、フィードバック用に使われるブロックＡＣＫまたはブロックＮＡＣＫとともに送信するように修正してよい。この修正は、一度に１つのパケットを入力し、またはフラッシュするのではなく、各ＵＥのバッファが、「パケット入力」および「パケットフラッシュ」操作双方においてブロック単位で更新されることになるものである。したがって、プロトコル５は、たとえば、ブロックＡＣＫ状況とともに用いられる際、図５に示すように修正してよい。
【０２１６】
図５は、ブロック送信ケース用に修正されたプロトコル５  ５００のフローチャートである。プロトコル５００は始めに、まだ送付されていない新しいソースパケットブロックが存在するかどうか判定する（ステップ５０２）。新しいソースパケットブロックが存在する場合、満杯のインデックスバッファがあるかどうか判定が行われる（ステップ５０４）。満杯のインデックスバッファがある場合、結合パケットのブロックが送信される（ステップ５０６）。パケットは、以前に説明したどのやり方で結合してもよい。
【０２１７】
満杯のバッファがない場合（ステップ５０４）、新しいソースパケットのブロックが送信される（ステップ５１０）。
【０２１８】
結合パケットのブロックを送信し（ステップ５０６）、または新しいソースパケットのブロックを送信した（ステップ５１０）後、バッファは、受信されたフィードバックに基づいて更新される（ステップ５１２）。
【０２１９】
新しいソースパケットブロックがない場合（ステップ５０２）、基地局は、バッファをフラッシュすることを試みる。バッファをフラッシュするために、全インデックスバッファが空であるかどうか判定が行われる（ステップ５１４）。インデックスバッファ全部が空の場合、プロトコルは終了する（ステップ５１６）。インデックスバッファ全部が空ではない場合（ステップ５１４）、基地局は、結合パケットのブロックを送信する（ステップ５２０）。パケットは、以前に説明したどのやり方で結合してもよい。バッファは、受信されたフィードバックに基づいて更新され（ステップ５２２）、インデックスバッファ全部が空であるかどうか判定が行われ（ステップ５１４）、プロトコルは上述したように継続する。
【０２２０】
誤警報確率と見逃し確率が調和するように、誤警報／見逃し確率閾値を調節することが必要な場合がある。定期的な完全情報再送信（おそらく、同期手順の一部）が、フィードバックエラーを訂正するのに役立つ。
【０２２１】
送信機側のタイマは、ＡＣＫまたはＮＡＣＫがパケット送付からのタイマ満了時に受信されないケースでの受信成功の欠落を暗示するのに使えばよい。
【０２２２】
ソースパケットが何度も再送信される状況は、上述したプロトコルにおいて、特に一部のチャネルが不利なチャネル条件をもつ場合に起こり得る。この場合、再送信のほとんどは、より不利なチャネル条件をもつＵＥを助けることを目指している。より不利なチャネル条件をもつＵＥへのソースパケットの再送信は、オーバーヘッド性能を損なう。
【０２２３】
既存ソリューションは、同じソースパケットの再送信回数の制限を提案する。言い換えると、ソースパケットの再送信回数がある一定の上限に達した場合、このパケットの送付を止める。この限界は、全ＵＥが全パケットを受信するわけではないことを引換えにして、オーバーヘッド性能を向上させることができる。こうするために、基地局は、各ソースパケット用に再送信カウンタをセットアップする必要がある。
【０２２４】
様々なサービス品質（ＱＯＳ）およびパケットクラス
【０２２５】
一部のマルチキャストサービスでは、ＵＥのサービス品質（ＱｏＳ）が別のＵＥとは異なる場合がある。ワイヤレスシステムにおいて、ＵＥのＱｏＳは、ＵＥの最大スループットに依存し得る。通常、セルの中心に近いＵＥが、セルの端に近いＵＥより大きいスループットをもつ。したがって、セルの中心に近いＵＥは、高いＱｏＳレベルを要求し得る。ＵＥのＱｏＳは、ＱｏＳクラス登録にも依存し得る。一部のＵＥが高いＱｏＳレベルに登録してよく、それ以外が低いＱｏＳレベルに登録してよい。
【０２２６】
様々なＱｏＳ要件を満たす２つのやり方がある。ＱｏＳは、パケット単位で、またはパケット内部で制御することができる。上述したプロトコルは、様々なＱｏＳ方式と連携するように修正してよく、このような修正は当業者にとって分かりやすい。
【０２２７】
パケット単位のＱＯＳレベル
【０２２８】
ソースパケットは、様々なクラスにカテゴリ化することができる。各クラスのソースパケットは、ある一定の組のＵＥに配信されなければならないが、システム内の他のＵＥに配信されないとしても容認可能である。この場合、ここでは受信成功に関する決定が適切なＱｏＳクラスの受信成功に基づいて判定されること以外、応答手順は、以前説明したものと同様である。
【０２２９】
クラス情報のいくつかのエンコードオプションがある。第１に、ソースパケットのクラスについての情報は、関連制御および指示チャネルを介してデータパケットまたはパケットインデックスとともに送付すればよい。第２に、ＵＥのＱｏＳまたはクラスは、所望のスループット、システムローディングなどのような要因に基づいて、送信機と交渉され／適応されてよい。第３に、各ＵＥは次いで、そのサービスクラスに対して作用し、そのクラス内のパケットに関してのみフィードバックを提供する。あるいは、各ＵＥは単に、その受信に基づいてＡＣＫ／ＮＡＣＫを送付する。ＵＥからＮＡＣＫを受信すると、基地局は、紛失パケットがそのＵＥに配信されると想定されるかどうか判定する。想定されない場合、基地局はそのＮＡＣＫを無視し、その再送信を、交渉されたサービスクラスに基づいて適応させる。
【０２３０】
パケット中の様々なＱＯＳ
【０２３１】
各ソースパケットは、各サービスクラスに従って、別個の１組のビットに分割される。この分割は、パケット中の様々なクラスのビット用に用いられる符号化、レートマッチング、および変調方式を適応することによって達成される。各クラス用のソースデータは、ある一定の組のＵＥに配信されなければならないが、システム内の他のＵＥに配信されないとしても容認可能である。
【０２３２】
この場合、受信成功に関する決定が適切なＱｏＳクラスビットの受信成功に基づいて判定されること以外、応答手順は、上述したものと同様である。
【０２３３】
クラス情報のいくつかのエンコードオプションがある。第１に、ソースパケットのクラスについての情報は、関連制御および指示チャネルを介してデータパケットまたはパケットインデックスとともに送付すればよい。第２に、ＵＥのＱｏＳまたはクラスは、所望のスループット、システムローディングなどのような要因に基づいて、送信機と交渉され／適応されてよい。第３に、各ＵＥは次いで、そのサービスクラスに対して作用し、成功または失敗に関してのみフィードバックを提供して、そのクラスにあるパケット中のビットを受信する。
【０２３４】
異なるグレードのＱｏＳサービスに変調を適応するケースでは、オプションは、階層変調方式として実装すればよい。この場合、ＱｏＳの低い受信機がビットを、低次信号点配置（ｃｏｎｓｔｅｌｌａｔｉｏｎ）でエンコードされたかのように首尾よく受信することができるように、ビットは、階層化変調プロセスにおいて直接エンコードされる。高いＱｏＳサービスを有するＵＥは、高次信号点配置を用いて首尾よく受信することができよう。たとえば、低次信号点配置は、シンボルごとに２ビットを有するＱＰＳＫ方式でよく、高次信号点配置は、シンボルごとに４ビットを有する１６ＱＡＭ信号点配置方式でよい。こうした４ビットのうち、２ビットが低次信号点配置用のものと同じである。
【０２３５】
この後者の方式は、動的に用いることができ、各ＵＥは、データを選択的に復調し、ＵＥが実施することができるベストエフォート復調プロセスに基づいてフィードバックを提供することができる。
【０２３６】
ＨＳＤＰＡへの適用
【０２３７】
既存システムの上述したアルゴリズムの潜在的利点を示すために、このアルゴリズムは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）を介したマルチキャストデータの送信効率を向上させるのに用いることができる。
【０２３８】
ＨＳＤＰＡの概説
【０２３９】
広帯域符号分割多重アクセス（ＷＣＤＭＡ）用の３ＧＰＰ仕様のリリース５によると、４つの論理チャネル、すなわち高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ）、高速共有制御チャネル（ＨＳ−ＳＣＣＨ）、高速専用物理制御チャネル（ＨＳ−ＤＰＣＣＨ）、および専用チャネル（ＤＣＨ）がＨＳＤＰＡ動作に関与する。
【０２４０】
ＨＳ−ＤＳＣＨおよびそれに対応する物理チャネルは、ユーザデータのマルチキャストに使われる。ダウンリンク方向のＨＳ−ＳＣＣＨおよびアップリンク方向のＨＳ−ＤＰＣＣＨは、ダウンリンクのユーザデータ送信を制御する関連した２つの信号チャネルである。ダウンリンクおよびアップリンク方向双方におけるＤＣＨは、リリース５においてどの種類のサービスにも使うことができる信号チャネルである。リリース６では、ＤＣＨは、改良ＤＣＨで置き換えられる。上記４チャネルに加え、リリース６仕様では、全ダウンリンクトラフィックがＨＳ−ＤＳＣＨ上で搬送される際の動作に代わるための、新しいチャネル、すなわちフラクショナル専用物理チャネル（Ｆ−ＤＰＣＨ）がある。
【０２４１】
ＨＳＤＰＡを用いた主要技術の１つが、物理層再送信である。リリース９９では、データが一度正しく受信されると、無線ネットワークコントローラ（ＲＮＣ：Radio Network Controller）は、再送信をスケジュールすることになる。ＨＳＤＰＡを用いると、パケットは、最初に基地局（ＢＴＳ：Base Transceiver Station）内のバッファ中に受信される。ＢＴＳは、パケットをユーザに送付済みである場合でも、そのパケットをバッファ中に保管し、パケット復号が失敗したケースでは、再送信は、ＲＮＣの関与なしでＢＴＳから自動的に起こる。
【０２４２】
図６は、ＨＳ−ＤＳＣＨチャネルエンコードチェーン６００の図である。図６によると、情報ビットは、最初に巡回冗長検査（ＣＲＣ）ビットを付加される（ステップ６１０）。ビットスクランブル機能性（ステップ６１２）が、同じビットが長く連続しないようにする。次に、符号ブロック分割が起こる（ステップ６１４）。次にターボ符号化が起こる（ステップ６１６）。ターボ符号は、ＨＳ−ＤＳＣＨにおいて使われる一意のタイプのチャネル符号である。
【０２４３】
ＨＡＲＱは、チェイス結合再送信および増加冗長再送信という２通りのやり方で動作させることができる。チェイス結合では、レートマッチング機能性は、数回の送信に渡って同一であり、同じビットが再送信用に残る。受信機は、受信したサンプルをソフト値として格納しなければならない。増加冗長では、数回の再送信の間のレートマッチングが異なる。組織ビットに対するパリティビットの相対的数は、再送信の間で変化する。実際の実装では、チャネルエンコードは、各パケット送信ごとに行うことができ、データは次いで、ＩＲバッファ中に保管すればよい。
【０２４４】
ハイブリッドＡＲＱ（ＨＡＲＱ）段階６５０で、第１のビット分離が起こる（ステップ６１８）。ＨＡＲＱ機能性は、２段階レートマッチング（ステップ６２０、６２４）からなり、このマッチングが、増加冗長を用いる際の異なる再送信の冗長バージョンの調節を可能にする。第１のレートマッチング段階（ステップ６２０）の後、情報ビットペイロードは、ＩＲバッファに進む（ステップ６２２）。次いで、第２のレートマッチング段階（ステップ６２４）が起こる。物理チャネル分割（ステップ６２６）が起こり、その後にインターリーブ、変調、および物理チャネルマッピングが続く（ステップ６２８）。
【０２４５】
図７は、符号化チェーン６００のほぼ反対方向であるＨＳ−ＤＳＣＨチャネル復号チェーン７００を示す。図７において唯一追加されているブロックは、結合ブロック（ステップ７１４）であり、このブロックは、チェイス結合または増加冗長動作を実施する。復号プロセスにおいて、インターリーブ、変調、および物理チャネルマッピング（ステップ７１０）が最初に起こる。この段階に続いて、物理チャネル分割が起こる（ステップ７１２）。次に結合（ステップ７１４）が起こり、情報ビットによるＩＲバッファの通過が続く（ステップ７１６）。パンクチャドターボ符号語が首尾よく復号された場合、第１のレートマッチング段階（ステップ７１８）が始まり、それ以外の場合は、パンクチャドターボ符号語が首尾よく復号されるまで、結合（ステップ７１４）が再度起こる。次にビット分離（ステップ７２０）が起こり、ターボ復号化（ステップ７２２）、符号ブロック分割（ステップ７２４）、ビットスクランブル（ステップ７２６）、およびＣＲＣ付加（ステップ７２８）が続く。
【０２４６】
ＨＳＤＰＡにおけるパケットの結合
【０２４７】
ＨＳＤＰＡ仕様は、上述したマルチキャストモデルの要件を満足する。ＨＳ−ＤＳＣＨおよびＨＳ−ＤＰＣＣＨは、それぞれ、ＨＳＤＰＡにおけるダウンリンク移送チャネルおよびアップリンク信号チャネルである。前者のチャネルは、マルチキャストチャネルとして働くことができ、後者のチャネルは、マルチキャストモデルにおいてＡＣＫ／ＮＡＣＫフィードバックチャネルとして働くことができる。
【０２４８】
ＨＳＤＰＡは、マルチキャストモデル以上のものを提供する。ＨＳＤＰＡでは、パケットが正しく復号されない場合、そのパケットを破棄するのではなく、パケットは、復号にさらに使用するために格納される。このことは、再送信されるパケットに対する復号失敗率を低下させる。マルチキャストモデルの場合、送付されるパケット全部に対して消失チャネルが一定した平均消失率をもつと仮定するのは不適切である。平均消失率は、再送信の回数に応じて設定してよい。たとえば、初期パケットに対する平均消失率はｅ０であり、第１の再送信パケットに対する平均消失率はｅ１であり、第２の再送信パケットに対する平均消失率はｅ２であり、ｅ２＜ｅ１＜ｅ０である。
【０２４９】
上述したプロトコルは、ＨＳＤＰＡ環境に適用することができる。簡単にするために、プロトコル２において説明した、データストリームを２つのＵＥにマルチキャストする例が論じられる。この例は、多数のＵＥのケースに拡張してもよい。ＨＳＤＰＡにおけるチャネル符号化およびＨＡＲＱ動作は、プロトコル２では網羅されない。プロトコル２におけるパケットＸＯＲ演算は、ＨＳＤＰＡにとって新規である。
【０２５０】
プロトコル２を、ＨＳＤＰＡとの使用に適応させるために、以下の変更が行われる。バッファ中で、ＨＡＲＱを用いて、ＨＳＤＰＡにおける全送信パケットが、起こり得る再送信のためにＩＲバッファに自動的に格納される。したがって、プロトコル２における２つのバッファは、紛失パケット全体を格納する必要はない。そうではなく、こうした２つのバッファは単に、紛失パケットのインデックスを記録する。ＢＴＳがこのパケットに対して双方のＵＥからＡＣＫを受信した場合、ＩＲバッファからパケットが削除される。
【０２５１】
プロトコル２の規則１または規則３に従ってソースパケットを送信すると、ＢＴＳは、図６のＨＳ−ＤＳＣＨチャネルエンコードチェーン６００に従って、発信パケットを生成する。ＵＥは、図７のＨＳ−ＤＳＣＨチャネル復号チェーン７００に従って、受信したソースパケットを復号する。
【０２５２】
プロトコル２の規則２に従って結合パケットを送信する際、双方のＵＥ用のバッファが空であるわけではない場合、ＢＴＳは、こうした２つのバッファ中の第１のパケットのＸＯＲを送信する。ＨＳＤＰＡでは、パケットのＸＯＲをとる２つの手法がある。
【０２５３】
第１の手法は、ターボエンコードの前にＸＯＲをとるものである。ＸＯＲ演算は、オリジナルソースパケットからターボエンコードブロックの最初まで、どのステップでも実施することができる。図８は、ＣＲＣブロックの最初で情報ビットのＸＯＲをとる例を示す。
【０２５４】
図８は、結合パケット用のＨＳ−ＤＳＣＨチャネルエンコードチェーン８００のフロー図である。結合パケット用のＨＳ−ＤＳＣＨチャネルエンコードチェーン８００は始めに、パケットのＸＯＲをとる（ステップ８１０）。次いで、ＣＲＣ付加が行われ（ステップ８１２）、ビットスクランブル（ステップ８１４）、および符号ブロック分割（ステップ８１６）が続く。次いで、ターボ符号化が実施される（ステップ８１８）。次いで、ＨＡＲＱ動作８５０が開始され、最初にビット分離をする（ステップ８２０）。次いで、第１のレートマッチングシーケンス（ステップ８２２）が始まり、ＩＲバッファのデータ通過（ステップ８２４）、次いで、第２のレートマッチングシーケンス（ステップ８２６）が続く。次いで、物理チャネル分割（ステップ８２８）が起こり、インターリーブ、変調、および物理チャネルマッピング（ステップ８３０）が続く。
【０２５５】
第２の手法は、ターボエンコードの後にＸＯＲをとるものである。ＸＯＲ演算は、ターボエンコードブロックからＩＲバッファブロックの出力まで、どのステップでも実施することができる。ＨＳＤＰＡにおける全送信パケットがＩＲバッファに自動的に格納されるので、ＩＲバッファに格納されている２つの紛失パケットのビットのＸＯＲをとることが好都合である。
【０２５６】
ＨＳＤＰＡにおいて組織ターボ符号が使われる場合、上記２つの手法により生成される結合パケットは同一になる。
【０２５７】
結合パケットを復号するために、結合パケットを受信すると、ＵＥが最初に、結合パケットの成分である既知のソースパケットの複製を作成する。次いで、ＵＥは、こうした既知のパケットと、受信された結合パケットとのＸＯＲをとる。生じた未知の単一パケットは次いで、受信チェーンを通って復調される。上述したように、パケット抽出は、受信チェーン中のどこで起こってもよいが、パケット抽出を実施する最も自然な場所は、第１のレートデマッチングおよびターボ復号化に先立って、ＩＲバッファの中である。
【０２５８】
図９は、結合パケット用のＨＳ−ＤＳＣＨチャネル復号チェーン９００の図である。復号チェーン９００において、結合パケットの成分であるソースパケット（群）は最初に、ＣＲＣ付加される（ステップ９１０）。その後、ビットスクランブル（ステップ９１２）、符号ブロック分割（ステップ９１４）、ターボ符号化（ステップ９１６）、ビット分離（ステップ９１８）、および第１のレートマッチングプロセス（ステップ９２０）が続く。ＸＯＲをとる（ステップ９２２）前に、結合パケットが同時に復調され（ステップ９２４）、次いで物理チャネル分割（ステップ９２６）、次いで第２のレートデマッチングプロセス（ステップ９２８）を経ることができる。次いで、結合（ステップ９３０）が起こり、ＩＲバッファへの格納（ステップ９３２）が続く。パンクチャドターボ符号語が首尾よく復号された場合、第１のレートデマッチングプロセス（ステップ９３４）が起こり、それ以外の場合、復号に失敗したパンクチャドターボ符号語との結合（ステップ９３０）が再度起こる。第１のレートデマッチングシーケンス（ステップ９３４）に続いて、ビット分離（ステップ９３６）およびターボ復号化（ステップ９３８）が起こる。
【０２５９】
プロトコル１０
【０２６０】
ＨＳＤＰＡ用の新しいプロトコルは、ＢＴＳによる各ＵＥ用のインデックスバッファのセットアップを含む。各インデックスバッファは、送付されたが対応するＵＥによって受信されていないパケットのインデックスを記録する。双方のバッファが、最初は空である。このプロトコルは、２つのＵＥ向けに説明するが、任意の数のＵＥへの拡張が明らかであろう。
【０２６１】
プロトコル１０には、「通常送信段階」および「バースト送信完了段階」という２つの段階がある。以前に送付されたことがない新しいソースパケットが存在する、または双方のバッファが空でない場合、プロトコルは「通常送信段階」にある。それ以外の場合、プロトコルは「バースト送信完了段階」にある。
【０２６２】
通常送信段階において、ＢＴＳは、以下の手続き規則に従ってパケットを生成しマルチキャストする。
【０２６３】
規則１：双方のＵＥが共通パケットの復号の失敗をＢＴＳに知らせた場合、ＢＴＳは、再送信パケットを上述したように生成する。チェイス結合では、再送信パケットは元のパケットと同じである。増加冗長では、再送信パケットは、ターボ符号語の異なるパンクチャリングとなる。一方のＵＥからＡＣＫを、他方のＵＥからＮＡＣＫを受信すると、ＢＴＳは、後者のＵＥ用のバッファ中にパケットインデックスを加える。
【０２６４】
規則２：双方のＵＥ用のバッファが空であるわけではない場合、ＢＴＳは、上述した手法により結合パケットを生成する。一方または双方のＵＥからＡＣＫを受信すると、ＢＴＳは、適切なバッファ（群）から第１のパケットインデックス参照を削除する。
【０２６５】
規則３：ＢＴＳは、新しいパケットを上述したように送信する。一方のＵＥからＡＣＫを、他方のＵＥからＮＡＣＫを受信すると、ＢＴＳは、後者のＵＥ用のバッファ中にパケットインデックスを加える。
【０２６６】
バースト送信完了段階では、長い送信バーストの終了時に、少なくとも一方のＵＥが、全ソースパケットを復号できている。他方のＵＥは、全部のソースパケットをまだ復号しておらず、すなわち、そのＵＥ用のバッファが空でない場合、ＢＴＳはそのバッファをフラッシュする。具体的には、ＢＴＳは、ＵＥからＡＣＫを受信するまで、バッファにあるインデックスとともにパケット全部を再送信し続ける。次いで、ＢＴＳは、次のパケットをバッファにあるインデックスとともに送付する。
【０２６７】
シミュレーション結果
【０２６８】
図１０は、プロトコル１およびプロトコル２のオーバーヘッドを、２つのＵＥを有するマルチキャストモデルのチャネル消失率に対して比較する第１のシミュレーションのグラフである。こうしたシミュレーションは、２つの独立消失チャネルの消失率が同一であると仮定する。ｅは、同一の消失率を示すものとする。比較のために、２本の曲線は、図１０において、
【０２６９】
【数１７】
0005481201.tif 000018
（これ以降、「曲線Ａ」）および
【０２７０】
【数１８】
0005481201.tif 000019
（これ以降、「曲線Ｂ」）で示される。前者の曲線は、プロトコル１の期待オーバーヘッドを示す式（３）から導き出され、後者の曲線は、２つのＵＥを有するマルチキャストモデルに対するどのプロトコルの最小可能オーバーヘッドも示す式（５）から導き出される。
【０２７１】
こうしたシミュレーションにおいて、ソースパケットの数は、１０４と設定される。曲線中の各点は、２０回の独立実行の平均であり、各点の分散は、１×１０−３未満である。図１０から、プロトコル１のオーバーヘッドは曲線Ａとほぼ重なり、プロトコル２のオーバーヘッドは曲線Ｂとほぼ重なるということが分かる。言い換えると、プロトコル２が、最良のオーバーヘッド性能を達成する。このことは、同じデータを第２のユーザに無償で送信させる。
【０２７２】
図１１は、チャネル消失率ｅ２に対する、プロトコル１およびプロトコル２のオーバーヘッドを示すグラフであり、チャネル消失率ｅ１は、０．２で固定される。比較のために、ｅ１＝０．２である式（３）、（５）に基づく２本の曲線が同じ図に示されている。図１１から、プロトコル１のオーバーヘッドは式（３）の曲線とほぼ重なり、プロトコル２のオーバーヘッドは式（５）の曲線とほぼ重なるということが分かる。プロトコル２のオーバーヘッドは、プロトコル１のものより優れているが、その隔たりは、ｅ１＝ｅ２のケースほど大きくない。式（３）の曲線は、高いｅ２値では式（５）の曲線に近づくことに留意されたい。
【０２７３】
図１２は、チャネル消失率ｅ２に対する、プロトコル１およびプロトコル２のオーバーヘッドを示すグラフであり、チャネル消失率ｅ１は、０．４で固定される。図１１と同様の結果が観察され得る。
【０２７４】
図１３は、５つのＵＥを有するマルチキャストモデル向けのプロトコル１ａおよびプロトコル５のオーバーヘッドに対するシミュレーション結果のグラフである。５つ全部のチャネルのチャネル消失率が、シミュレーションにおいて同じであると仮定される。比較のために、オーバーヘッドに対する下限、すなわち、
【０２７５】
【数１９】
0005481201.tif 000020
が図１３において引かれている。図１３から、プロトコル５のオーバーヘッドはバッファ容量とともに低下するということが分かる。これは、バッファ容量が大きいほど、各結合パケットがより多くのＵＥについての１パケット分の未知の情報を含みやすくなるからである。バッファ容量が増大すると、プロトコル５のオーバーヘッドは、下限
【０２７６】
【数２０】
0005481201.tif 000021
に近づく。シミュレーションにおいて使われるバッファ容量は、ソースパケットの数と比較して小さい。さらに、バッファは、パケット全体よりも、パケットインデックスのみを格納する。したがって、プロトコル５の格納要件は、基地局によって容易に満足することができる。
【０２７７】
図１４および図１５は、それぞれ、２５個、および５０個のＵＥを伴う、プロトコル１ａおよびプロトコル５のオーバーヘッドに対するシミュレーション結果を示すグラフである。やはり、こうした全チャネルのチャネル消失率は、シミュレーションにおいて同じであると仮定される。プロトコル５を用いることによって、プロトコル１ａを上回る多大な性能向上が観察され得る。
【０２７８】
実施形態
【０２７９】
１．基地局と通信する２つのユーザ機器（ＵＥ）それぞれに対してバッファを提供すること、
過去に未送付のパケットが基地局にあるかどうか判定すること、
双方のＵＥバッファが空でないかどうか判定すること、
過去に未送付のパケットがない場合、およびバッファの一方が空でない場合、空でないバッファをフラッシュすること、
過去に未送付のパケットがある場合、または双方のバッファが空でない場合、送信するべきパケットを選択すること、ならびに
ＵＥから受信されたフィードバックに基づいてバッファを更新することを含むパケットをマルチキャストする方法。
【０２８０】
２．フラッシュすることは、バッファが空であるかどうか判定すること、バッファからパケットを送信すること、パケットを受信したＵＥから受信されたフィードバックに基づいてバッファを更新すること、およびバッファが空になるまで、フラッシュすることを繰り返すことを含む実施形態１に記載の方法。
【０２８１】
３．選択することは、過去に送信されているが双方のＵＥによって受信されているわけではないパケットを送信することを含む実施形態１または２に記載の方法。
【０２８２】
４．選択することは、過去に送信されているが双方のＵＥによって受信されているわけではないパケットがない場合、および双方のバッファが空でない場合、結合パケットを送信すること含み、結合パケットは、バッファ中の２つのパケットの結合である実施形態１または２に記載の方法。
【０２８３】
５．選択することは、過去に送信されているが双方のＵＥによって受信されているわけではないパケットがない場合、およびバッファの一方が空の場合、過去に未送付のパケットを送信することを含む実施形態１または２に記載の方法。
【０２８４】
６．マルチキャスト通信システムにおいてフィードバックを提供する方法であって、基地局からパケットを受信すること、パケットが首尾よく受信されたかどうか判定すること、および判定の結果に基づいて基地局にフィードバックを提供することを含む方法。
【０２８５】
７．受信されたパケットが結合パケットであるかどうか判定すること、結合パケットから個々のパケットを復元すること、および過去に首尾よく受信されなかった結合パケット中の個々のどのパケットに関しても、基地局にフィードバックを提供することを含む実施形態６に記載の方法。
【０２８６】
８．復元することは、結合パケットおよび過去に受信されたパケットに対して排他的ｏｒ演算を実施することを含み、そうすることによって過去に受信に失敗したパケットが復元される実施形態７に記載の方法。
【０２８７】
９．ユーザ機器は、方法を実施するように構成される前記いずれかの実施形態に記載の方法。
【０２８８】
１０．方法は、任意の数のユーザ機器と連携するように修正される前記いずれかの実施形態に記載の方法。
【０２８９】
１１．待ち時間要件に対処することをさらに含む前記いずれかの実施形態に記載の方法。
【０２９０】
１２．メモリ制限に対処することをさらに含む前記いずれかの実施形態に記載の方法。
【０２９１】
１３．結合パケットに結合されるべきパケットを選択するための方法をさらに含む前記いずれかの実施形態に記載の方法。
【０２９２】
１４．バッファは、パケットベースのバッファである前記いずれかの実施形態に記載の方法。
【０２９３】
１５．バッファは、グループベースのバッファである前記いずれかの実施形態に記載の方法。
【０２９４】
１６．方法は、高速ダウンリンクパケットアクセスに適用される前記いずれかの実施形態に記載の方法。
【０２９５】
１７．前記いずれかの実施形態に記載の方法を実施するように構成されたアーキテクチャ。
【０２９６】
１８．パケット情報シグナリングに対処することをさらに含む実施形態１７に記載のアーキテクチャ。
【０２９７】
１９．同期およびユーザダイナミクスに対処することをさらに含む実施形態１７に記載のアーキテクチャ。
【０２９８】
２０．フィードバックエラー処理に対処することをさらに含む実施形態１７に記載のアーキテクチャ。
【０２９９】
２１．様々なサービス品質レベルに対処することをさらに含む実施形態１７に記載のアーキテクチャ。
【０３００】
本開示内容の特徴および要素が、具体的な組合せとして説明されたが、各特徴または要素は、他の特徴および要素なしで個別に、あるいは他の特徴および要素ありでもなしでも、様々に組み合わせて用いることができる。挙げられた方法またはフローチャートは、汎用コンピュータまたはプロセッサによる実行用のコンピュータ可読記憶媒体内で具体的に実施される、コンピュータプログラム、ソフトウェア、またはファームウェア中に実装することができる。コンピュータ可読記憶媒体の例は、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリ素子、内部ハードディスクおよび取外し可能ディスクなどの磁気メディア、光磁気メディア、ならびにＣＤ−ＲＯＭディスク、およびデジタル多用途ディスク（ＤＶＤ）などの光メディアを含む。
【０３０１】
適切なプロセッサは、例として、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連した１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラム可能なゲートアレイ（ＦＰＧＡ）回路、他のどのタイプの集積回路（ＩＣ）、および／または状態マシンも含む。
【０３０２】
ソフトウェアと関連したプロセッサは、ワイヤレス送受信ユニット（ＵＥ）、ユーザ機器（ＵＥ）、端末、基地局、無線ネットワークコントローラ（ＲＮＣ）、または任意のホストコンピュータ内で使用するための無線周波数トランシーバを実装するのに使うことができる。ＵＥは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカフォン、振動装置、スピーカ、マイクロホン、テレビトランシーバ、ハンズフリーヘッドセット、キーボード、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、液晶ディスプレイ（ＬＣＤ）表示ユニット、有機発光ダイオード（ＯＬＥＤ）表示ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意のワイヤレスローカルエリアネットワーク（ＷＬＡＮ）モジュールなど、ハードウェアおよび／またはソフトウェア中に実装されるモジュールとともに使うことができる。
【図１】
0005481201.tif 000022
【図２】
0005481201.tif 000023
【図３】
0005481201.tif 000024
【図４】
0005481201.tif 000025
【図５】
0005481201.tif 000026
【図６】
0005481201.tif 000027
【図７】
0005481201.tif 000028
【図８】
0005481201.tif 000029
【図９】
0005481201.tif 000030
【図１０】
0005481201.tif 000031
【図１１】
0005481201.tif 000032
【図１２】
0005481201.tif 000033
【図１３】
0005481201.tif 000034
【図１４】
0005481201.tif 000035
【図１５】
0005481201.tif 000036