(57)【要約】  本発明は、移動無線通信ネットワークのコンテンツ同期のための方法と関連するネットワーク装置及びデータ構造に関する。  本発明は、移動無線通信ネットワークにおけるコンテンツ同期のためＲＬＣブロックを形成する方法を提供し、前記方法は前記ブロックの中で複数のＳＤＵの各々につき制御要素を提供するステップを含み、ここで各制御要素はそれぞれのＳＤＵの前に配置されるヘッダ要素を備え、さらに本発明は、前記ブロックを提供するネットワーク装置と、かかる構造を有するブロックとを提供する。
2008139976.tif 000002
【特許請求の範囲】
【請求項１】
移動無線通信ネットワークにおけるコンテンツ同期のためのＲＬＣブロックの形成方法であり、前記ブロックの中で複数のＳＤＵの各々につき制御要素を提供するステップを含み、各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備えることを特徴とする方法。
【請求項２】
前記ヘッダ要素は、前記ＳＤＵの各々につきプレフィックスを備える、請求項１に記載の方法。
【請求項３】
前記ヘッダ要素は、これの参照先にあたるデータの長さを指示するためのフラグを含むことができる、請求項１または２に記載の方法。
【請求項４】
前記ヘッダ要素は、前記ＳＤＵの前記ペイロードの中にデータとともに含まれる、請求項１、２、または３に記載の方法。
【請求項５】
前記ヘッダ要素のサイズは一定である、先行する請求項のいずれか一項以上に記載の方法。
【請求項６】
ＲＬＣヘッダの中に長さインジケータを含む、先行する請求項のいずれか一項以上に記載の方法。
【請求項７】
アイドルギャップを計算するステップを含む、先行する請求項のいずれか一項以上に記載の方法。
【請求項８】
ダミーパケットを使用するアイドルギャップを送信信号するステップを含む、請求項７に記載の方法。
【請求項９】
前記ダミーパケットをダミーＳＤＵとしてＲＬＣ  ＰＤＵにマッピングするステップを含む、請求項８に記載の方法。
【請求項１０】
前記ヘッダ要素の形成は、前記長さインジケータに関連しゼロによる最終パディングを使用するよう構成できる、先行する請求項のいずれか一項以上に記載の方法。
【請求項１１】
移動無線通信ネットワークにおけるコンテンツ同期のためのＲＬＣブロックであって、前記ブロックの中に複数のＳＤＵの各々につき制御要素を含み、各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備えることを特徴とするブロック。
【請求項１２】
前記ヘッダ要素は、前記ＳＤＵの各々につきプレフィックスを備える、請求項１１に記載のブロック。
【請求項１３】
前記ヘッダ要素は、これの参照先にあたるデータの長さを指示するためのフラグを含む、請求項１１または１２に記載のブロック。
【請求項１４】
前記ヘッダ要素は、前記ＳＤＵの前記ペイロードの中にデー
タとともに有利に含まれる、請求項１１、１２、または１３に記載のブロック。
【請求項１５】
一定サイズのヘッダ要素を含む、請求項１１から１４のいずれか一項以上に記載のブロック。
【請求項１６】
移動無線通信ネットワークにおいてコンテンツ同期のためＲＬＣブロックを提供し、前記ブロックの中で複数のＳＤＵの各々につき制御要素を提供するよう構成される移動無線通信ネットワーク装置であって、前記装置は、各制御要素がそれぞれのＳＤＵの前に配置されるヘッダ要素を備えるよう構成される、移動無線通信ネットワーク装置。
【請求項１７】
請求項１から１０のいずれか一項以上に記載された方法を遂行するよう構成される、請求項１６に記載の移動無線通信ネットワーク装置。
【請求項１８】
マルチセル調整体を備える、請求項１６または１７に記載の移動無線通信ネットワーク装置。
【請求項１９】
添付の図面を参照しながら前記の通り概ね説明された、移動無線通信ネットワークにおいてコンテンツ同期のためＲＬＣブロックを形成する方法。
【請求項２０】
添付の図面を参照しながら前記の通り概ね説明された、移動無線通信ネットワークにおいてコンテンツ同期を行なうためのＲＬＣブロック。
【請求項２１】
添付の図面を参照しながら前記の通り概ね説明された、移動無線通信ネットワークにおいてコンテンツ同期のためＲＬＣブロックを提供する移動無線通信ネットワーク装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動無線通信ネットワークのコンテンツ同期のための方法と関連するネットワーク装置及びデータ構造に関する。
【背景技術】
【０００２】
例えばＭＢＭＳ伝送のため単一周波数ネットワーク（ＳＦＮ）技術を使用する場合、提供されるサービスの伝送エリアは１つ以上のマルチセルＭＢＭＳ同期エリア（ＭＭＳＡ）と交わる。各ＭＭＳＡの中で、サービスデータを搬送する信号は全送信ｅＮｏｄｅＢの間で同一でなければならない。これは、送信機会が（公差内で）完璧に重なるようにするため、送信器と共通リソース割り当て機構との間で時間同期を要することになる。また、各々の送信機会に同じデータブロックを符号化し、コンテンツ同期を達成する必要もある。この目的のため、ＭＭＳＡの中にある全ｅＮｏｄｅＢは単一のソースから、すなわちタイムスタンプ方式、あるいはバイトオフセット方式等のＳＹＮＣプロトコルを使ってパケットを伝送するマルチセル調整体（ＭＣＥ）から、サービスデータパケットを受け取る。【０００３】
バイトレベルシーケンス番号方式のコンテンツ同期は相対的同期法である。つまり、タイムスタンプによっていかなる特定の送信時間もパケットに割り当てられることはないが、この方法はＭＭＳＡの全ｅＮｏｄｅＢによってあらゆる所与パケットが同時に送信されることは保証する。パケットはＭＣＥによってバイトオフセットとともに発行され、同バイトオフセットは、ＭＢＭＳサービスへ割り当てられるブロックのシーケンスによって形成されるバイトストリームの中でそれらのパケットの正確な位置を効果的に特定し、開始時間はあらかじめ決定される。バイトオフセットによって示される実際の配置は先行パケットのパッキングに費やされるオーバーヘッドに依存するが、ｅＮｏｄｅＢはどれも同じルールに従ってパケットをパッキングするため、コンテンツ同期は維持される。【０００４】
この方式の場合は通常、１つのパケットに対応するバイトオフセットは、以前のパケットに対応するバイトオフセットに以前のパケットのサイズを加えたものに等しい。どんな方式にもいえることだが、割り当てられるキャパシティは実際のデータ量を若干上回らなければならない。これは、あらゆるｅＮｏｄｅＢが取りそこなうパケットと混同されないよう、パケットフローの中でアイドルギャップを管理しなければならないことを意味する。【０００５】
ＭＣＥは、自身が上流フローでギャップに遭遇する場合に、パケットのストリームの中でアイドルギャップを生成することがある。ただしアイドルギャップは本来、ソースのデータレートをエアインターフェースの実際のレートに合わせるように調整されるものである。ＭＣＥは、もしもｅＮｏｄｅＢによって消費されるオーバーヘッド（一定ではない）にまったく気づかなければ、ｅＮｏｄｅＢにおけるキューイングが安定に保たれることは保証できない。事実、平均的なキューの増大を回避するためリソースが割り当てられ、これはその追求にあたってともするとデータが使い果たされることを意味する。この場合、同期法はこの状況に対処するか、あるいは最初からアイドル同期ギャップを適時に管理することによってこれを回避しなければならない。【０００６】
ｅＮｏｄｅＢは、１つ以上のパケットを取りそこなったことを検知した場合に、その損失の影響を受けるブロックを一切送信できないが（ブロックを部分的に送信することはできないので）、損失を全く被らなかったｅＮｏｄｅＢとの同期を保つため、スキップすべきブロックの数と送信を再開するところのバイトとを判断しなければならない。【０００７】
ｅＮｏｄｅＢは、（損失の前後に）受信するパケットに対応するバイトオフセットの差からギャップのサイズを知るように思われるが、そのサイズには、パッキングプロセスによって加わるオーバーヘッドが含まれないことを理解されたい。したがってｅＮｏｄｅＢは、他のｅＮｏｄｅＢが費やすオーバーヘッドを計算する必要がある。つまりｅＮｏｄｅＢは不在データのパッキングを模擬しなければならない。失われたパケットがひとつなら、これがパッキングされた方法はただひとつである。ただしこの段階でｅＮｏｄｅＢはそれを知ることができないし、これを想定しない。オーバーヘッドは通常、パケットがいかにブロックにおさまるかに応じて異なるため、数個のパケットが不在の場合は、それらのサイズの合計を知るだけでは不十分である。【０００８】
３ｇＰＰ提案Ｅｒｉｃｓｓｏｎ、Ｔｄｏｃ  Ｒ２−０７０５７３からは、オーバーヘッドの計算を瑣末なものであるとする提言がなされている。つまり、各ブロックは一定量のスペースをヘッダに当てる。したがってオーバーヘッドは一定となり、転送されるユーザデータの量も一定となる。【０００９】
ただし、この公知の提案には２つの限界と短所がある。【００１０】
第１に、最大限の連結パケットの極端で希なケースを除き、使われないヘッダスペースが存在する。
第２に、浪費を抑えるためヘッダを縮小するとヘッダスペースを使い尽くす一連のパケットに遭遇するリスクが増し、ブロックのデータ部分の使用不能スペースにより無駄が生じ、（未使用スペースに収まったかもしれないデータを破棄することにより）データの損失を招くか、（このデータを後続ブロックでパッキングすることにより）遅れを招く。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、公知の技術を凌ぐ利点の提供を目指すものである。
【課題を解決するための手段】
【００１２】
本発明の第１の態様は、移動無線通信ネットワークの中でのコンテンツ同期のためＲＬＣブロックの形成方法であり、前記ブロックの中で複数のＳＤＵの各々につき制御要素を提供するステップを含み、ここで各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備える。【００１３】
ここで述べるとおり、本発明は、これが各ブロックの中で不定数のパケットまたはセグメントを許容することによりオーバーヘッドの最適化を達成するのを助けることができる限り、とりわけ有利である。【００１４】
さらに、パケット損失はネットワークの中で、例えばｅＮｏｄｅＢにて、検出でき、それゆえ不在データに引き続き同期送信が再開されうる。【００１５】
前記ヘッダ要素は前記ＳＤＵの各々につきプレフィックスを備えることが好ましい。【００１６】
ヘッダ要素は、これの参照先にあたるデータの長さを指示するためのフラグを含むことができる。【００１７】
特に、ヘッダ要素はＳＤＵのペイロードの中でデータと混在されるという利点がある。【００１８】
ある特定の実施形態において、ヘッダ要素のサイズは一定である。【００１９】
さらに、この長さインジケータはＲＬＣヘッダの中に含めることができ、前記方法はさらに、アイドルギャップを計算するステップを含むことができる。【００２０】
またさらに、長さインジケータに関連しゼロによる最終パディングを使用するようヘッダ要素の形成を構成できる。【００２１】
前記方法はまた、ダミーパケットによってアイドルギャップの信号を送るステップを含むことができる。【００２２】
特に、前記方法はダミーパケットをダミーＳＤＵとしてＲＬＣ  ＰＤＵにマッピングするステップを含むことができる。【００２３】
本発明の別の態様は、移動無線通信ネットワークの中でのコンテンツ同期のためのＲＬＣブロックであり、前記ブロックの中に複数のＳＤＵの各々につき制御要素を含み、ここで各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備える。【００２４】
前記ヘッダ要素は前記ＳＤＵの各々につきプレフィックスを備えるのが好ましい。【００２５】
ヘッダ要素は、これの参照先にあたるデータの長さを指示するためのフラグを含むことができる。【００２６】
特に、ヘッダ要素はＳＤＵのペイロードの中でデータとともに混在されるという利点がある。【００２７】
ある特定の実施形態において、ヘッダ要素のサイズは一定である。【００２８】
さらに、この長さインジケータはＲＬＣヘッダの中に含めることができ、前記方法はさらに、アイドルギャップを計算するステップを含むことができる。【００２９】
またさらに、長さインジケータに関連しゼロによる最終パディングを使用するようヘッダ要素の形成を構成できる。【００３０】
本発明の別の態様は、移動無線通信ネットワークの中でのコンテンツ同期のためＲＬＣブロックを提供し、前記ブロックの中で複数のＳＤＵの各々につき制御要素を提供するよう構成される移動無線通信ネットワーク装置で、各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備える。【００３１】
前記ヘッダ要素はここでも前記ＳＤＵの各々につきプレフィックスを備えることが好ましい。【００３２】
前記ヘッダ要素は、これの参照先にあたるデータの長さを指示するためのフラグを含むことができる。【００３３】
特に、前記ヘッダ要素はＳＤＵのペイロードの中でデータと混在されるという利点がある。【００３４】
ある特定の実施形態において、ヘッダ要素のサイズは一定である。【００３５】
さらに、この長さインジケータはＲＬＣヘッダの中に含めることができ、前記方法はさらに、アイドルギャップを計算するステップを含むことができる。【００３６】
またさらに、長さインジケータに関連しゼロによる最終パディングを使用するようヘッダ要素の形成を構成できる。【００３７】
移動無線通信ネットワーク装置はマルチセル調整体を備えることが好ましい。【００３８】
後に理解されるとおり、本発明は部分的に新しいＲＬＣブロック構築方法を提案するものであり（ＲＬＣはセグメント化と連結を処理する実体）、これは各ブロックにて不定数のパケット及び／またはセグメントを許容することによりオーバーヘッドを最適化する。有利なことに、これはパケット損失を検出するｅＮｏｄｅＢが、不在データの後に同期送信を再開することをも可能にする。【００３９】
可変オーバーヘッドに伴い、ＭＣＥは、ｅＮｏｄｅＢにおいてデータキューが決して使い果たされないこと、またはアイドルギャップによって制御されることが確実になるというさらなる問題を経験する。可変オーバーヘッドは、ｅＮｏｄｅＢによる正確なデータ供給レートが分からないことを意味し、この目的のためのｅＮｏｄｅＢからのフィードバックは３ＧＰＰによって除外されている。ただし本発明は、この点にも有利に対処する。【００４０】
本発明は、上述した可変オーバーヘッドに伴う問題を間接的に解決することにより、かかる問題への対処に貢献する。【００４１】
これ以降さらに説明され理解されるとおり、本発明は、バイトオフセット方式ＳＹＮＣプロトコルと特定ＲＬＣ  ＰＤＵ構築法に対し多少の修正を伴うものである。【００４２】
より詳細には、ＲＬＣは、ＳＤＵの長さを含む要素と共に、ＳＹＮＣによって伝送される各ＳＤＵをプレフィックスする。これらのプレフィックスは、あたかもそれらがデータの一部であるかのようにペイロードの中でＳＤＵとともにパッキングされ、連結は必然的に行なわれ、分解にあたってはプレフィックスを繰り返し読み取る。プレフィックスは一定のサイズ（ＬＴＥで２バイト）を持ち、このサイズはＭＣＥによってＳＹＮＣバイトオフセットに含まれる。【００４３】
次のパケットのオフセットは前のパケットのオフセットであるが、前のパケットの実サイズにＲＬＣ  ＳＤＵプレフィックスのサイズを加えたサイズで増加されている。ただしこれは、ＭＣＥが関係する限り、ＳＹＮＣプロトコルとＲＬＣプロトコルとによって共有される定数に過ぎない。【００４４】
セグメント化も必然的になされ、ＲＬＣ  ＰＤＵが失われないにも関わらず、再組み立ては瑣末なものである。アンパッキングプロセスは、損失ＲＬＣ  ＰＤＵの後で全ＲＬＣヘッダの中にある「プレフィックスオフセットフィールド」から再開し、同プレフィックスオフセットフィールドは次の使用可能プレフィックスを指示する（実行の詳細は以下に説明する）。【００４５】
ＳＹＮＣはいかなる真のペイロードも含まないダミーパケットを伝送できる。そのペイロードはパケットの仮想サイズを、すなわち通常の方法で次のオフセットに反映されるサイズを（プレフィックスサイズを含む）、指示するフィールドである。かくしてダミーＳＹＮＣ  ＰＤＵは、その小さい実サイズによって識別される（真のパケットはこのように小さくはない）。【００４６】
ダミーパケットによって信号送信されるアイドルギャップは、プレフィックスと、データの代わりにその仮想サイズに従い生成されたパディングとを備えるダミーＳＤＵとしてＲＬＣ  ＰＤＵにマッピングされる。その結果生じた真のデータも含むＰＤＵは送信される。パディングだけを含むＰＤＵは、後続ＰＤＵの構築に影響しない限り、構築される必要はない。【００４７】
このようにパディングＳＤＵは各ＳＤＵプレフィックスの中にあるパディングフラグにより受信ＲＬＣ体によって識別され、破棄される。セグメントの再組み立てに影響が及ばないことに注意されたい（実行の詳細は以下に説明する）。【００４８】
ＭＣＥは、スケジューリング期間にわたるＳＹＮＣバイトオフセットの増加（またはそれの倍数）に基づき正確な擬似レートを保証することによって、アイドルギャップと共に実際のｅＮｏｄｅＢ供給レートを制御できる。【００４９】
本発明は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）のため提案された「バイトレベルシーケンス番号方式同期法」として知られるベーシックＭＢＭＳサービスコンテンツ同期方式の改良に相当する。上述したこの公知の方式は、数個のｅＮｏｄｅＢが同時にパケットを送信することを可能にするが、パケットごとのタイムスタンプは避け、関係する全ｅＮｏｄｅＢにとって共通の連続するＭＢＭＳサービス送信機会によって構成される仮想バイトシーケンスの中で各パケットの配置させるバイトオフセットを代わりに使用する。この方式は、調整体間の複数パケット損失の可能性に耐える。（ＭＣＥと１つ以上のｅＮｏｄｅＢは、送信データブロックの形成に制約を課す。つまり各ブロックは一定量のユーザデータを転送しなければならない（データとしてのアイドルギャップを含む）。ここでユーザデータは、ＭＢＭＳベアラサービスのペイロードを指す。）ただし、容量の浪費を避ける上では望ましいパケットの連結は一般的に、可変オーバーヘッドを招く。よって、ブロック当たりの一定量のデータの要求は、最大連結数への対処に適した各ブロックにおける一定量の予約スペースを意味する。これは規則的なキャパシティの浪費をもたらす。
【発明の効果】
【００５０】
これより、添付の図面を参照しながら本発明の一例をさらに説明する。
【発明を実施するための最良の形態】
【００５１】
ｅＭＢＭＳサービスのため割り当てられるエアインターフェースリソースと関連Ｌ１パラメータは、少なくともセッションが続く間は、一定と仮定する。さらに、それらは同一容量の転送ブロックに分割されると仮定する。さらに、ＭＡＣ層は一定のオーバーヘッドを消費すると仮定する。これら仮定の一連の結果として、ｅＮｏｄｅＢにおけるＲＬＣは、送信機会にマッピングする、各サービスセッションにつきサイズが一定且つ既知の、ＲＬＣ  ＰＤＵを作る。ただし、予測可能な可変サイズに方式を調整することもできるが、明確を図るため、これ以降は単一のサイズを仮定する。【００５２】
ＲＬＣ  ＰＤＵは固定ヘッダとペイロード部からなる。ここで定義するペイロードは、実際にはデータ（ＲＬＣ  ＳＤＵまたはそのセグメント）のほかにある程度のオーバーヘッドを含むが、本方式にとっては、このような形でＲＬＣプロセスを提示するのが最適である。使用可能なＲＬＣ  ＰＤＵサイズとヘッダに求められるサイズがどうあれ、ペイロード部はバイト整合され、これ以降ペイロードサイズと呼ぶ整数の既知バイト数（オクテット）を保持する。これは図１に具体的に示されており、ここでサイズ１０のＲＬＣ  ＰＤＵは、ペイロードバイト１６によって、すなわちバイト境界１８で区切られた前述したオクテットによって区切られるペイロードバイト１６の数によって決まるペイロードサイズのペイロード部１４と、ヘッダ部１２とを有する。【００５３】
サービスセッションに（開始から終了まで）含まれるＲＬＣ  ＰＤＵのシーケンスを考えた場合、ペイロードは概念上、連続バイトストリーム、またはバイトオフセットを通じてアドレスできるアドレススペース（ゼロから始まる）とを形成するとみなすことができる。つまり、図２に示された一連のＲＬＣ  ＰＤＵ  ２０は各々ＲＬＣヘッダ２２とＲＬＣペイロード２４とを備え、ここでサービスセッションは、サービスセッション開始矢印２６とサービスセッション終了矢印２８との間に位置するＰＤＵ  ２０によって決定される。【００５４】
ペイロードスペース３０の仮想マッピングも、ペイロードスペース３０によって形成される仮想連続バイトストリームとの関係で使用されるバイトオフセット３２の例と併せて示されている。【００５５】
ＳＹＮＣプロトコルによるＳＤＵの伝送時に（ＳＹＮＣはＭＢＭＳサービスパケットをｅＮｏｄｅＢへ伝送し、これは最終的にＲＬＣ  ＳＤＵになる）、ＲＬＣは、（少なくとも）ＳＤＵのサイズを含む制御要素と共に各ＳＤＵをプレフィックスする。このステップは仮想であり、問題はＲＬＣ  ＰＤＵにおける最終的なバイトの配置だけである。これは図３に示されており、ここでＳＹＮＣ  ３４はＲＬＣ  ＳＤＵ  ４０を備えるＳＹＮＣ  ＰＤＵ  ３８をＲＬＣ  ３６へ伝送し、同ＳＹＮＣ  ＰＤＵ  ３８はその後ＲＬＣ  ３６において、本発明の一実施形態に従い発生しＲＬＣ  ３６によって加えられるプレフィックス４４を含む増補ＳＤＵ  ４２に形成される。ただしこれらのプレフィックスは、最終的にはＲＬＣ  ＰＤＵのペイロードの中で真の要素となるため、オクテット整合を維持するため、プレフィックスは整数のバイト数を持つ。これはヘッダにおける長さ指示とペイロードにおけるデータ要素との仮想関係として提示されており、伝送ＳＤＵから新規（増補）ＳＤＵへの局所的形成をもたらす。【００５６】
プレフィックスの中で与えられる長さがプレフィックスそのものの長さを含む代案も可能である。換言すると、これは単に真のＳＤＵの長さではなく、増補ＳＤＵの長さとなる。この同等の方法に実用上の利点はほとんどないように思われるが、ゼロからプレフィックスのサイズまでの長さには特別な意味を与えることができる。例えば、セッションの終わりには最終ＰＤＵをパディングしなければならないかもしれない。これは以下に提案する方法で果たすことができるが、ゼロによるパディングの不定の長さは、「それ以上データなし、セッションは完了」を意味するゼロ長により特定されうる。【００５７】
ＳＹＮＣによって搬送されるバイトオフセットは（これより「バイトオフセット方式」、または「バイトレベルシーケンス番号方式」コンテンツ同期法の一般的概念を参照する）、増補（プレフィックス）ＳＤＵのサイズの現在合計である。ＭＣＥ（ＳＹＮＣ  ＰＤＵのソース）は、ｅＮｏｄｅＢにおけるＲＬＣ手順について正確に知る必要はない。これがやることは、バイトオフセットを計算するときに一定量（ＲＬＣ  ＳＤＵプレフィックスサイズ）によりパケットのサイズを誇張するだけである。換言すると、第１のＳＹＮＣ  ＰＤＵのバイトオフセットはゼロであり、任意の後続ＰＤＵのバイトオフセットは（アイドルギャップは無視する）、前のＰＤＵのペイロードのバイト数による実サイズに、ＲＬＣプロトコル定義によって課せられる一定数を加えることで増加した、前のＰＤＵのオフセットである。これは、オフセットのより大きな増加によってギャップをも提供する一般的な「バイトオフセット方式コンテンツ同期」法の軽微な調整である。これは、ＳＹＮＣ  ３４で発生し、パケットまたはＲＬＣ  ＳＤＵ  ４８とオフセット値４６とを備えるＰＤＵを再び示す図４で具体的に示されている。このＰＤＵの後ろには、パケットまたはＲＬＣ  ＳＤＵ  ５０とオフセット５２とを備える後続ＰＤＵが続き、この場合のオフセットは、先行ＰＤＵのオフセット４６とパケットサイズ４８との、さらにプレフィックスサイズと、ギャップが発生する場合はそのサイズとの合計に等しい。【００５８】
このＳＹＮＣプロトコルとＲＬＣプロトコルとのリンク（共有定数）は、おそらく原則として望ましくはないが、多大な制約を提示せず、例えばＳＹＮＣは、プレフィックスの構造もその使用も知る必要はない。これは、オフセット計算に加える一定数について知るだけでよい。【００５９】
実際、１５００バイト以下のパケットを考えた場合（現在のＬＴＥ仮定）、プレフィックスは２オクテットを要する（後述するとおり、１１ビットの長さ指示と数個のフラグ）。【００６０】
ＳＹＮＣバイトオフセットは、上に定義したペイロードスペースの中でアドレスとみなすことができ、これはＲＬＣがペイロードスペースの中で、すなわち特定のＲＬＣ  ＰＤＵの中で、または複数のＲＬＣ  ＰＤＵにまたがり、増補（プレフィックス）ＳＤＵを無条件に配置することを可能にする。したがってＳＤＵの配置は以前に失われたいかなるパケットとも無関係となり、これは各ｅＮｏｄｅＢが、Ｓ１リンク（ＭＣＥとｅＮｏｄｅＢとの間）上でのあらゆるパケット損失にかかわらず、他の全てのｅＮｏｄｅＢと同期を保つことを可能にする。図５では、プレフィックス６０とＲＬＣ  ＳＤＵ  ６２とを備えるＰＤＵに比べて、一連の第１、第２、及び第３のパケットオフセット５４、５６、５８が示されている。【００６１】
ＲＬＣ  ＰＤＵペイロード６４もギャップ６６と同様に示されており、ギャップ６６は、第２及び第３のパケット間のパディングＳＤＵ（図示せず）で埋めることができる。実際にはそこにペイロードスペースはないが、ＲＬＣ  ＰＤＵ形成は追加的に容易に果たすことができる。つまりＲＬＣは、増補（プレフィックス）ＳＤＵのシーケンスに従い、それらをプレフィックスとともに相次いでコピーし、前のＰＤＵをパッキングするときに途切れた場所から始まり、ペイロードを完了するバイトまでＳＤＵが連続していることをバイトオフセットで確認しながら、現在のＰＤＵのペイロード部を単純に埋める。バイトオフセットの食い違いがＳＤＵの不在を示唆する場合、ＲＬＣは、その食い違いを計上するためいくつかのバイトをスキップし、ことによると後続ＰＤＵに処理を進める。スキップされるバイトのコンテンツ（値）の問題は、後ほどアイドルギャップを検討するときに再び取り上げる（以下参照）。さしあたり、バイトオフセットの食い違いの原因は損失パケットにあるとする。この場合、任意のデータをなくしたＰＤＵはいずれもどのみち破棄する必要がある（つまり送信しない）ため、スキップされるバイトは重要でない。ただしスキップされるバイトがパディングされた場合、結果生ずる転送ブロックは、パケット損失を被らなかった近傍ｅＮｏｄｅＢによって送信されるものと異なり、ＭＢＳＦＮ伝送原則に違反することとなる。【００６２】
上の定義は、仮想的に関連づけられたプレフィックスが今、真のＳＤＵの手前に実際にコピーされることを、つまり、あたかもペイロードの一部としてデータと混在させられることを意味する。この説明の過程で、これは最も自然なアプローチである。ただしＲＬＣパッキングに関する従来技術の状況においては、これらのＳＤＵプレフィックス等の制御要素をグループにまとめ、それらをＲＬＣヘッダへ組み入れることにより、これを可変サイズとするのが一般的なやり方である。よって、これらのプレフィックスをペイロードの中に置くことの妥当性は革新的とみることができる。さらに、先行技術によって提案されるグループ化には問題があり、それは以下に示すとおりに対処できるが、不利な効果を伴う。この問題は、ここで提示するペイロードスペースの観点から、プレフィックスを２つのＰＤＵの間で分割する必要があるケースに、または先行技術の観点から、例えばＲＬＣ  ＰＤＵ構築がＰＤＵの中にプレフィックスより小さい、例えばちょうど１バイトの、予備キャパシティをもたらすケースに相当する構成に伴い発生する。同期にとってはＳＹＮＣバイトオフセットがデータバイトとプレフィックスバイトとの合計に一致することが重要であり、ただひとつの予備バイトも無駄にはできない（証明：これが２度起こると食い違いはプレフィックスにとって十分な２バイトであり、もしもある１つのｅＮｏｄｅＢがいくつかのパケットを失うなら、これは機会を逸し、あちこちでバイトを浪費することとなり、他のｅＮｏｄｅＢとの同期をゆるめる）。状況を改善するため、ＲＬＣヘッダにてプレフィックスのリストの中に部分的プレフィックスを有するよう配置でき、これらはフラグを必要とする。結局のところ、この方法はすでにプレフィックスリストの終わりを指示するため継続フラグを必要とする。あるいは、予備バイトはＲＬＣヘッダの固定（メイン）部分における予約バイトで補完できる。ただしその予約バイトは、一般的なケースでＰＤＵのキャパシティを減少させる。また、結局これはペイロードスペースの中の何もないところからバイトを作ることになる。よってこれは、ＳＹＮＣバイトオフセットとの同期を保つため、次のＰＤＵにおいて浪費される追加バイトによって補償されなければならない。このような構成は、これを信号送信するためのフラグをも必要とする。これは必要とあればことごとく明らかにできる。ここでの主張は、可変ＲＬＣヘッダでプレフィックスをグループ化することは厄介で非効率的であるため、プレフィックスはペイロードの中に置いたほうが良いということである。【００６３】
ＲＬＣ  ＰＤＵアンパッキングは、ＰＤＵが失われない（つまりより下位層によって決定されることはない）限りは、瑣末なことである。この場合、連続ペイロードスペースの概念は依然通用する。バイトのストリームは、後続ＳＤＵの長さを含む所謂プレフィックスから始まり、これのすぐ後ろに（ペイロードスペース内）次のプレフィックスが続く。図６は、受信端末におけるダイレクトマッピング７０による一連のＲＬＣ  ＳＤＵ  ６８のアンパッキングについて図示している。最終ＰＤＵはあるパディングで完了する必要があるかもしれないことに注意されたい。このように、アンパッキングＲＬＣは（データストリームの中でアイドルギャップを処理する場合と同様に）何を破棄するべきかを指示するプレフィックスを有することとなる。実際のところ、ＲＬＣはＰＤＵを一度に１つずつ処理し、これは単純に２つのことを意味する。
−ＲＬＣはＳＤＵの長さを記憶し、これが現在のＲＬＣ  ＰＤＵを超えて継続していることが明白ならば、どの程度アンパッキング済みかを記憶する。
−ＲＬＣは、ＰＤＵペイロードに残っているスペースがプレフィックスにとって小さすぎることを検知することがある（提案されているＬＴＥ実装において、それはわずか１バイトしか残っていないことを意味する）。この場合ＲＬＣは、この残りのＰＤＵ部分を、次のペイロードの開始によって完了するプレフィックスの先頭と仮定し、保存しなければならない。【００６４】
この後者の点は、上の論述から自然に導き出されるものであるが、メインヘッダの後ろでプレフィックスをグループ化してなる先行技術に対する改善である。後者は、上でいくぶん念入りに詳述したとおり、やりにくい、またはキャパシティを浪費することになる、幾つかの方法で解決できる。【００６５】
いくつかのＲＬＣ  ＰＤＵがアンパッキング側で失われる場合には（破損、ｅＮｏｄｅＢにおける損失パケットの影響等、何らかの理由でより下位層によって復号化できない）、いくつかのプレフィックスが不在となる可能性があり、これは上述した連鎖を破綻させる。不在ＰＤＵ（実際には任意の数のＰＤＵ）の後でアンパッキングプロセスを再開するために、各ＰＤＵは、アクセス可能な次のプレフィックスをどこで見つけるかを指示する情報を含まなければならない。この情報は、ＲＬＣ固定ヘッダの中に長さ指示要素を含めることによって提供される。ヘッダのサイズは、その固定サイズのため、あるいはむしろ結果生じるペイロード部の既知サイズのため、同期に影響しないことに注意されたい。この新しいフィールドは、図７のようにペイロード部を開始する増補ＳＤＵセグメントの長さとみなすことができ、同図においては、プレフィックスオフセットフィールド値７４を導入したペイロード７２とともにＲＬＣ  ＰＤＵ構造が示されており、これは７６にも単独で示されている。ただし検討するべき異なるセグメント化ケースがあり、「プレフィックスオフセットフィールド」と命名されるこの長さ指示のより厳密な定義は、ペイロードＰＤＵ部の先頭に対する増補ＳＤＵの第一の開始のオフセットであり、以下の論理的限界ケースを伴う。【００６６】
もしもＰＤＵが進行中のセグメント化から始まらないなら、当然「プレフィックスオフセットフィールド」は図８に示すとおりゼロに設定しなければならず、同図は図７と同様、ペイロード７８と、導入されたプレフィックスオフセットフィールド８０とを示しており、これは８２にも単独で示されているが、ここでフィールド８０の実値はゼロということになる。【００６７】
もしもＰＤＵが１セグメントだけを保持するなら（すなわちこのＰＤは、長いセグメント化ＳＤＵの中間に位置し、したがってペイロードにプレフィックスはない）、「プレフィックスオフセットフィールド」の値は、少なくともペイロード部の長さには等しくなければならない。その長さに代わるものは、（３）で定義した連続ペイロードスペースにおける次のプレフィックスまでのオフセットであるが、それは実際には必要ない。ペイロード８４の長さがプレフィックスオフセットフィールド８６の長さに等しくなる一例を示した図９を参照されたい。このプレフィックスオフセットフィールドもまた８８にて単独で示されている。【００６８】
すでに定義が示唆しているとおり、もしペイロードが切断されたプレフィックスで始まるなら（これが前のＰＤＵで始まったため）、「プレフィックスオフセットフィールド」で指し示すべき正しいプレフィックスは次のプレフィックスである。これは図１０に示すとおり、ここでは次のプレフィックスもまた期せずして切断される。つまり、ペイロード９０の長さは、分割されたプレフィックス９４、９６を除いたプレフィックスオフセットフィールド９２の長さにほぼ等しく、ここでもまたプレフィックスオフセットフィールド９８は９８にて単独で示されている。【００６９】
ただし、この後者のケースは改善できるシナリオに属する。つまり、増補ＳＤＵがＳＤＵの開始前にセグメントされる度に、ＳＤＵ（または、これが次のＰＤＵにまたがってセグメント化される場合にはこれの最初のセグメント）を回復することが可能である。ＲＬＣヘッダにおける余分のフラグ（または、いずれにせよヘッダの一部をなす「プレフィックスオフセットフィールド」そのもの）により、以下の状況は指示できる。
セグメント化は増補ＳＤＵを、そのプレフィックスとＳＤＵとの間で分割する、及びプレフィックスの最後のバイトは現在のＰＤＵの中にある。【００７０】
プレフィックスサイズが２より大きいなら、より多くのケースがあることに注意されたい。【００７１】
ＳＹＮＣバイトオフセットメカニズムによりアイドルギャップはＭＣＥで生成され、ｅＮｏｄｅＢの観点からは損失データとみなされる（アイドルギャップは、パケット配信ネットワーク上でのレートマッチング、すなわち柔軟性のため必要であり、ｅＮｏｄｅＢは自ら同期アイドルギャップを生成できない）。ただしこの場合、アイドルギャップと損失パケットの共通手順の単純さは弊害をもたらす。なぜなら損失パケットは、各ｅＮｏｄｅＢで別個に発生する偶発的イベントと想定される。よって、ある１つのｅＮｏｄｅＢが不在データを伴いＰＤＵを送信する場合、そのｅＮｏｄｅＢは確実に、近傍ｅＮｏｄｅＢが送信するものとは異なるブロックを送信することとなり、ＭＢＳＦＮ伝送ルールに違反することとなる。したがってパケットの損失は、正常に受信され、ギャップを取り囲むデータの実質的損失をも余儀なくする（単にギャップとともにＰＤＵを共有するセグメントではなく、これらのセグメントが属するパケット全体）。ただしアイドルギャップは異常で希なケースではない。アイドルギャップは平常作動中に頻繁に発生し、全ＭＢＳＦＮ参加ｅＮｏｄｅＢにはよくあることである。アイドルギャップの信号送信（すなわち、それらを損失パケットと区別するメカニズム）により、ｅＮｏｄｅＢはアイドルギャップを取り囲むあらゆるデータを捨てる必要はなく、全ての部分的に満たされたＰＤＵは全てのｅＮｏｄｅＢで同じになる。アイドルギャップは、ユーザデータを所持しないダミーＳＹＮＣ  ＰＤＵを使用することにより、ＳＹＮＣプロトコルにいかなる大幅な変更も加えずとも、信号送信されうる。ダミーＳＹＮＣ  ＰＤＵの目的は、ｅＮｏｄｅＢに向けてアイドルギャップを明確に提示することである。したがってダミーＳＹＮＣ  ＰＤＵは、信号送信するつもりのギャップのサイズを所持しなければならない。これは、もしもそれらのパケットが適当サイズのダミーパケットとともに生成されるなら、大した問題ではない。しかし第１に、これは余分なキャパシティを占めており、第２に、ダミーデータは真のデータから区別されなければならない。しかし、もしもバイトオフセットへ仮想サイズが加えられる一方でＰＤＵのデータペイロードが単純に省かれるなら、ギャップのサイズはさかのぼって知るよりほかない（複数のダミーＰＤＵは専らこれを緩和する）。その上、ギャップの一部が実際、ひとつ以上の損失パケットを含むというキャンセルが依然あり、それ故ｅＮｏｄｅＢが、部分的に満たされたＰＤＵを送信することが正しいという保証がなくなる。これは図１１Ａに図示されており、同図においては、時間に対して、パケットまたはＲＬＣ  ＳＤＵ  １０２をプレフィックスオフセット１０４とともに備えるＰＤＵが示されており、後続のダミーＳＹＮＣ  ＰＤＵ  １０６は、オフセット１０４とオクテット単位のパケットＲＬＣ  ＳＤＵ  １０２とローカル値２との合計に等しいオフセット１０８を含み、その後ろにＰＤＵが続き、そのプレフィックスオフセット１１０は、値Ｘに加えてダミーＳＹＮＣ  ＰＤＵ  １０６のオフセットの合計からなる。【００７２】
図１１ＢもＰＤＵ１０２、１０４とダミーＳＹＮＣ  ＰＤＵ  １０６が再び到着する一例を示しているが、ここで介在するＰＤＵ  １１２はパケットまたはＲＬＣ  ＳＤＵ  １１４を有すると考えられ、プレフィックスオフセット１１６は失われ、その後には、前述したオフセット１０４と、前述したダミーＳＹＮＣ  ＰＤＵ  １０６に等しいパケットサイズと、ダミーＳＹＮＣ  ＰＤＵのプレフィックス１０８と、前述した公称値Ｘとの合計に等しいプレフィックスオフセット値を伴うＰＤＵが続くと考えられる。提案されたダミーＳＹＮＣ  ＰＤＵ構造は通常のＰＤＵと同じだが、そのペイロード（パケットまたはＲＬＣ  ＳＤＵ）は、ペイロードのサイズ（ダミーパケットの仮想サイズ）として設定された長さインジケータに置き換えられる。バイトオフセットは依然、適切なＰＤＵとして設定されるが、ダミーＰＤＵの後に続く任意のパケット（それ自体ダミーまたはダミーでない）のオフセットは、前のパケットの実サイズではなく仮想サイズにＲＬＣ  ＳＤＵプレフィックスサイズを加えたサイズによって増加される（あるいは、ダミーパケットの仮想サイズは、後続ＳＹＮＣ  ＰＤＵとのオフセットの差からプレフィックスサイズを引いたものである）。長さインジケータに要求されるサイズは最小パケットサイズより小さいため、ダミーＰＤＵは通常のＰＤＵから実サイズによって区別される。【００７３】
無論、ダミーＳＹＮＣ  ＰＤＵが失われることがあることは分かる。ただしこの場合、ｅＮｏｄｅＢはパディングされたＰＤＵを送信しないというより安全な選択肢に戻るだけのことである。異常な状況においても損失は許容され、ダミーパケットの損失も何ら変わりはない。【００７４】
上記のとおり、アイドルギャップは、送信すべきデータを所持する不完全ＲＬＣ  ＰＤＵをパディングするためのメカニズムを必要とする。パディングは単に、全てのｅＮｏｄｅＢが同じＰＤＵを作ることを保証するためのメカニズムであり、上述したパッキング法から取り残された全体を満たす必要はない（例えば、パディングはペイロードの末尾へ移すことができる）。ただし、アイドルギャップをダミーＳＤＵとして扱うと格段に単純になる（パディングはダミーデータとして生成されパディングフラグによって信号送信されるが、ダミーデータを所持しないので、ダミーＳＹＮＣ  ＰＤＵは透過的にダミーＳＤＵにならないにもかかわらず）。加えて、この方法は上述した全ての検討が有効であり続けることを保証する。よって、真のＳＤＵと同様、ダミーまたはパディングＳＤＵは、全てゼロ（または規格化される場合はゼロ以外）となるパディングの長さを指示するプレフィックスの後に続く。これらのパディングＳＤＵはアンパッキングＲＬＣ体によって破棄される必要があり、各プレフィックス内の「パディングフラグ」は関連ＳＤＵがパディングであるか否かを指示するものであり、パディングの値はそれらを信号送信するにあたって信頼できる方法ではない。さもなければ、アンパッキングは影響を受けない。パディングＳＤＵはあらゆるＳＤＵと同様にセグメント化できる。失われたＲＬＣ  ＰＤＵは、セグメントの性質が定まらないことを意味するが（一致するプレフィックスが不在または不完全だった場合）、不完全ＳＤＵのセグメントのようにどのみち破棄される。パディングＳＤＵはダミーＳＹＮＣ  ＰＤＵごとに作成することが示唆される。パディングを所持するだけのＰＤＵは送信する必要はなく、構築する必要すらないことに注意されたい。【００７５】
上述したとおり、ＲＬＣ  ＰＤＵの中の論理的ギャップにパディングが合致する必要はない。換言すると、ひとたびセグメント化されＰＤＵに割り当てられたＳＤＵは、例えばギャップを一端へ押しやりながら、ＰＤＵの中で再配置されうる。ただしこれは、ギャップが非常に小さく（ギャップのＰＤＵとの交差が１バイトくらい小さく）なる場合に問題を招き、これはフラグによって解決できる。【００７６】
ｅＮｏｄｅＢキューは決して空にならないことが好ましいため、ＭＣＥはｅＮｏｄｅＢ誘発オーバーヘッドを全面的には無視できない（ｅＮｏｄｅＢは損失パケットと同様に進行しなければならないが、ＭＣＥにとっては同期化アイドルギャップを生成するほうが良い）。幸いこの方法により、ＭＣＥは、ＳＹＮＣバイトオフセットによって測定される一定の供給レートを保証するだけでよい。よって、アイドルギャップサイズ計算は実際には、目標平均パケットデータ送信レート（バイト単位）ではなく、時間の経過にともなうオフセット増大の関数である。換言すると、アイドルギャップはＳＹＮＣバイトオフセットを規制し、実パケットデータの量に関係づけるのではなく、ＲＬＣペイロードスペースの中でギャップを効果的に管理する。したがって原則として、アイドルギャップに関係するオフセットはプレフィックスより小さくなり、これは上述した提案手法を無効にする。ＳＹＮＣ層（後続オフセットがプレフィックスサイズを下回らなければならない場合のダミーパケットの負の仮想サイズ）とＲＬＣ層（通常のプレフィックスが後ろに続く、ありえない１バイトギャップの代わりに、通常の、すなわち３バイトの、プレフィックスよりＳＤＵプレフィックスが長いことを指示する、ＳＤＵプレフィックス内のフラグ）の両方における改善は、この問題を解決できる。ただし、そのような非常に小さいアイドルギャップは現実的ではなく、所定の最小サイズ（実際、ＲＬＣ関連ＳＹＮＣバイトオフセット増加のためすでに指定されたものと同じ値）より長いアイドルギャップを要求するほうが格段に単純であり、その結果、パディングＳＤＵ（プレフィックス完備）は常に特定のギャップの中に収められることができる。【００７７】
上述したとおり、エアインターフェースサービスレートが平均してＭＣＥ供給レートより高くならないことを保証するため、ＭＣＥがある程度の認識を持たなければならないことが理解される。ここで提示する同期法は、スケジューリング期間にわたるオフセットの増加率が（真のユーザデータレートではない）、またはその倍数が、正確に一定となるよう（そして他の全オーバーヘッドを勘案し、物理的配分が支持できるものに一致するよう）パケットまたはアイドルギャップを提供することをＭＣＥに要求するまでこの認識を軽減する。【００７８】
したがって上記から、本発明が現在の技術からの有利な脱却を意味することは理解されるであろう。特に、ペイロードの中でデータと混在する制御情報を備えるＳＤＵプレフィックスの概念である。【００７９】
ＲＬＣメイン（固定）ヘッダの中に長さインジケータを有する必要があることも理解される。これはＳＤＵヘッダ（プレフィックス）の追加の例ではなく、ＳＤＵではなくセグメントに関連する長さインジケータに過ぎない。その厳密な定義は上記のとおりであり、これは、セグメント化をサポートするためにプレフィックスが余分なフィールドを必要としないことを暗示する。【００８０】
本発明は、固定ヘッダ（またはプレフィックスオフセットフィールド）内の２、３のフラグにより、増補ＳＤＵがこれのプレフィックスまたはその一部だけを失うセグメント化ケースに対処するアイデアを提案する。【００８１】
必須ではないが、本発明は、長さ指示の中にそれ自体含まれるプレフィックスに関連してゼロによる最終パディングする可能性を認識する。【００８２】
これはセッションの中でのパディングに使用することもできるが、発明者はこれを好ましいものとせず、プレフィックス内のパディングフラグをより好ましいものとする。パディングは、ペイロード内のその論理的位置に置く必要はない。各ＲＬＣ  ＰＤＵを調べ、パディングは常にペイロードブロックの末尾へ移すことができる。この場合、ゼロの長さ（最初のバイトをプレフィックスとして読み取る）はそれがパディングであることを指示でき、その実際の長さはペイロードブロックのサイズから暗示される。そして全てのプレフィックスにおいてパディングビットは余剰となる。ただし、もしもＰＤＵに割り当てられるパディングがわずか１バイトなら問題がある（プレフィックスより短いアイドルギャップは発生しないが、ペイロードスペースにおけるその位置は恣意的であり、アイドルギャップを挿入するときにＭＣＥがＲＣＬブロック境界に注意を払うことは明らかに間違っている）。ヌル長を指示するプレフィックスはもちろんのこと、プレフィックスを作るにあたって１バイトは短すぎる。よって、さらに別のフラグが固定ヘッダにて必要となる。いずれにせよプレフィックスには予備ビットがあるため、プレフィックスごとのパディングフラグと期待されるところのパディングは、よりシンプルで、より優れたものとなる。
【産業上の利用可能性】
【００８３】
この点において制限されないが、本発明は、ＭＢＳＦＮをサポートするｅＮｏｄｅＢ（ＬＴＥをサポートするノードＢ）と、ＭＢＭＳ（＆）を受信できるＬＴＥ  ＵＥと、ＬＴＥマルチセル調整体（ＭＣＥ）を実装する装置において、具体的用途を見いだすであろう。
【図面の簡単な説明】
【００８４】
【図１】ＲＬＣ  ＰＤＵ構造の図である。
【図２】ペイロードスペースの仮想表現をなす。
【図３】ＲＬＣによるプレフィックスＳＤＵ形成の図をなす。
【図４】ＳＹＮＣバイトオフセットの図である。
【図５】ペイロードスペースにおけるプレフィックスＳＤＵの配置を示す図である。
【図６】受信端末によるＲＬＣ  ＳＤＵのアンパッキングを示す概略図である。
【図７】一般的なＲＬＣ  ＰＤＵ構造を示す図である。
【図８】図７の構造に類似する構造の図であるが、ペイロードの先頭に進行中のセグメント化は見られない。
【図９】類似するＲＬＣ  ＰＤＵ構造の図であるが、セグメント化の最中にある。
【図１０】セグメント化によって２つのプレフィックスが分割されたＲＬＣ  ＰＤＵ構造の図である。
【図１１】ダミーＳＹＮＣ  ＰＤＵ使用の各種シナリオを示す。
【図１】
2008139976.tif 000003
【図２】
2008139976.tif 000004
【図３】
2008139976.tif 000005
【図４】
2008139976.tif 000006
【図５】
2008139976.tif 000007
【図６】
2008139976.tif 000008
【図７】
2008139976.tif 000009
【図８】
2008139976.tif 000010
【図９】
2008139976.tif 000011
【図１０】
2008139976.tif 000012
【図１１】
2008139976.tif 000013
【国際調査報告】
2008139976.tif 000014
2008139976.tif 000015
2008139976.tif 000016
2008139976.tif 000017
2008139976.tif 000018