JP5158080B2

JP5158080B2 - 移動通信ネットワークのコンテンツ同期

Info

Publication number: JP5158080B2
Application number: JP2009514121A
Authority: JP
Inventors: マイケルノースリー; ピエールマルシャン
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2007-05-04
Filing date: 2008-05-02
Publication date: 2013-03-06
Anticipated expiration: 2028-05-02
Also published as: WO2008139976A1; US8305950B2; GB2448933B; GB2448933A; CN101690310A; US20100103923A1; EP2146516A4; GB0708694D0; JPWO2008139976A1; EP2146516A1

Description

本発明は、移動無線通信ネットワークのコンテンツ同期のための方法と関連するネットワーク装置及びデータ構造に関する。

例えばＭＢＭＳ伝送のため単一周波数ネットワーク（ＳＦＮ）技術を使用する場合、提供されるサービスの伝送エリアは１つ以上のマルチセルＭＢＭＳ同期エリア（ＭＭＳＡ）と交わる。各ＭＭＳＡの中で、サービスデータを搬送する信号は全送信ｅＮｏｄｅＢの間で同一でなければならない。これは、送信機会が（公差内で）完璧に重なるようにするため、送信器と共通リソース割り当て機構との間で時間同期を要することになる。また、各々の送信機会に同じデータブロックを符号化し、コンテンツ同期を達成する必要もある。この目的のため、ＭＭＳＡの中にある全ｅＮｏｄｅＢは単一のソースから、すなわちタイムスタンプ方式、あるいはバイトオフセット方式等のＳＹＮＣプロトコルを使ってパケットを伝送するマルチセル調整体（ＭＣＥ）から、サービスデータパケットを受け取る。

バイトレベルシーケンス番号方式のコンテンツ同期は相対的同期法である。つまり、タイムスタンプによっていかなる特定の送信時間もパケットに割り当てられることはないが、この方法はＭＭＳＡの全ｅＮｏｄｅＢによってあらゆる所与パケットが同時に送信されることは保証する。パケットはＭＣＥによってバイトオフセットとともに発行され、同バイトオフセットは、ＭＢＭＳサービスへ割り当てられるブロックのシーケンスによって形成されるバイトストリームの中でそれらのパケットの正確な位置を効果的に特定し、開始時間はあらかじめ決定される。バイトオフセットによって示される実際の配置は先行パケットのパッキングに費やされるオーバーヘッドに依存するが、ｅＮｏｄｅＢはどれも同じルールに従ってパケットをパッキングするため、コンテンツ同期は維持される。

この方式の場合は通常、１つのパケットに対応するバイトオフセットは、以前のパケットに対応するバイトオフセットに以前のパケットのサイズを加えたものに等しい。どんな方式にもいえることだが、割り当てられるキャパシティは実際のデータ量を若干上回らなければならない。これは、あらゆるｅＮｏｄｅＢが取りそこなうパケットと混同されないよう、パケットフローの中でアイドルギャップを管理しなければならないことを意味する。

ＭＣＥは、自身が上流フローでギャップに遭遇する場合に、パケットのストリームの中でアイドルギャップを生成することがある。ただしアイドルギャップは本来、ソースのデータレートをエアインターフェースの実際のレートに合わせるように調整されるものである。ＭＣＥは、もしもｅＮｏｄｅＢによって消費されるオーバーヘッド（一定ではない）にまったく気づかなければ、ｅＮｏｄｅＢにおけるキューイングが安定に保たれることは保証できない。事実、平均的なキューの増大を回避するためリソースが割り当てられ、これはその追求にあたってともするとデータが使い果たされることを意味する。この場合、同期法はこの状況に対処するか、あるいは最初からアイドル同期ギャップを適時に管理することによってこれを回避しなければならない。

ｅＮｏｄｅＢは、１つ以上のパケットを取りそこなったことを検知した場合に、その損失の影響を受けるブロックを一切送信できないが（ブロックを部分的に送信することはできないので）、損失を全く被らなかったｅＮｏｄｅＢとの同期を保つため、スキップすべきブロックの数と送信を再開するところのバイトとを判断しなければならない。

ｅＮｏｄｅＢは、（損失の前後に）受信するパケットに対応するバイトオフセットの差からギャップのサイズを知るように思われるが、そのサイズには、パッキングプロセスによって加わるオーバーヘッドが含まれないことを理解されたい。したがってｅＮｏｄｅＢは、他のｅＮｏｄｅＢが費やすオーバーヘッドを計算する必要がある。つまりｅＮｏｄｅＢは不在データのパッキングを模擬しなければならない。失われたパケットがひとつなら、これがパッキングされた方法はただひとつである。ただしこの段階でｅＮｏｄｅＢはそれを知ることができないし、これを想定しない。オーバーヘッドは通常、パケットがいかにブロックにおさまるかに応じて異なるため、数個のパケットが不在の場合は、それらのサイズの合計を知るだけでは不十分である。

３ｇＰＰ提案Ｅｒｉｃｓｓｏｎ、ＴｄｏｃＲ２−０７０５７３からは、オーバーヘッドの計算を瑣末なものであるとする提言がなされている。つまり、各ブロックは一定量のスペースをヘッダに当てる。したがってオーバーヘッドは一定となり、転送されるユーザデータの量も一定となる。

ただし、この公知の提案には２つの限界と短所がある。

第１に、最大限の連結パケットの極端で希なケースを除き、使われないヘッダスペースが存在する。
第２に、浪費を抑えるためヘッダを縮小するとヘッダスペースを使い尽くす一連のパケットに遭遇するリスクが増し、ブロックのデータ部分の使用不能スペースにより無駄が生じ、（未使用スペースに収まったかもしれないデータを破棄することにより）データの損失を招くか、（このデータを後続ブロックでパッキングすることにより）遅れを招く。

本発明は、公知の技術を凌ぐ利点の提供を目指すものである。

本発明の第１の態様は、移動無線通信ネットワークの中でのコンテンツ同期のためＲＬＣブロックの形成方法であり、前記ブロックの中で複数のＳＤＵの各々につき制御要素を提供するステップを含み、ここで各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備える。

ここで述べるとおり、本発明は、これが各ブロックの中で不定数のパケットまたはセグメントを許容することによりオーバーヘッドの最適化を達成するのを助けることができる限り、とりわけ有利である。

さらに、パケット損失はネットワークの中で、例えばｅＮｏｄｅＢにて、検出でき、それゆえ不在データに引き続き同期送信が再開されうる。

前記ヘッダ要素は前記ＳＤＵの各々につきプレフィックスを備えることが好ましい。

ヘッダ要素は、これの参照先にあたるデータの長さを指示するためのフラグを含むことができる。

特に、ヘッダ要素はＳＤＵのペイロードの中でデータと混在されるという利点がある。

ある特定の実施形態において、ヘッダ要素のサイズは一定である。

さらに、この長さインジケータはＲＬＣヘッダの中に含めることができ、前記方法はさらに、アイドルギャップを計算するステップを含むことができる。

またさらに、長さインジケータに関連しゼロによる最終パディングを使用するようヘッダ要素の形成を構成できる。

前記方法はまた、ダミーパケットによってアイドルギャップの信号を送るステップを含むことができる。

特に、前記方法はダミーパケットをダミーＳＤＵとしてＲＬＣＰＤＵにマッピングするステップを含むことができる。

本発明の別の態様は、移動無線通信ネットワークの中でのコンテンツ同期のためのＲＬＣブロックであり、前記ブロックの中に複数のＳＤＵの各々につき制御要素を含み、ここで各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備える。

前記ヘッダ要素は前記ＳＤＵの各々につきプレフィックスを備えるのが好ましい。

特に、ヘッダ要素はＳＤＵのペイロードの中でデータとともに混在されるという利点がある。

本発明の別の態様は、移動無線通信ネットワークの中でのコンテンツ同期のためＲＬＣブロックを提供し、前記ブロックの中で複数のＳＤＵの各々につき制御要素を提供するよう構成される移動無線通信ネットワーク装置で、各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備える。

前記ヘッダ要素はここでも前記ＳＤＵの各々につきプレフィックスを備えることが好ましい。

前記ヘッダ要素は、これの参照先にあたるデータの長さを指示するためのフラグを含むことができる。

特に、前記ヘッダ要素はＳＤＵのペイロードの中でデータと混在されるという利点がある。

移動無線通信ネットワーク装置はマルチセル調整体を備えることが好ましい。

後に理解されるとおり、本発明は部分的に新しいＲＬＣブロック構築方法を提案するものであり（ＲＬＣはセグメント化と連結を処理する実体）、これは各ブロックにて不定数のパケット及び／またはセグメントを許容することによりオーバーヘッドを最適化する。有利なことに、これはパケット損失を検出するｅＮｏｄｅＢが、不在データの後に同期送信を再開することをも可能にする。

可変オーバーヘッドに伴い、ＭＣＥは、ｅＮｏｄｅＢにおいてデータキューが決して使い果たされないこと、またはアイドルギャップによって制御されることが確実になるというさらなる問題を経験する。可変オーバーヘッドは、ｅＮｏｄｅＢによる正確なデータ供給レートが分からないことを意味し、この目的のためのｅＮｏｄｅＢからのフィードバックは３ＧＰＰによって除外されている。ただし本発明は、この点にも有利に対処する。

本発明は、上述した可変オーバーヘッドに伴う問題を間接的に解決することにより、かかる問題への対処に貢献する。

これ以降さらに説明され理解されるとおり、本発明は、バイトオフセット方式ＳＹＮＣプロトコルと特定ＲＬＣＰＤＵ構築法に対し多少の修正を伴うものである。

より詳細には、ＲＬＣは、ＳＤＵの長さを含む要素と共に、ＳＹＮＣによって伝送される各ＳＤＵをプレフィックスする。これらのプレフィックスは、あたかもそれらがデータの一部であるかのようにペイロードの中でＳＤＵとともにパッキングされ、連結は必然的に行なわれ、分解にあたってはプレフィックスを繰り返し読み取る。プレフィックスは一定のサイズ（ＬＴＥで２バイト）を持ち、このサイズはＭＣＥによってＳＹＮＣバイトオフセットに含まれる。

次のパケットのオフセットは前のパケットのオフセットであるが、前のパケットの実サイズにＲＬＣＳＤＵプレフィックスのサイズを加えたサイズで増加されている。ただしこれは、ＭＣＥが関係する限り、ＳＹＮＣプロトコルとＲＬＣプロトコルとによって共有される定数に過ぎない。

セグメント化も必然的になされ、ＲＬＣＰＤＵが失われないにも関わらず、再組み立ては瑣末なものである。アンパッキングプロセスは、損失ＲＬＣＰＤＵの後で全ＲＬＣヘッダの中にある「プレフィックスオフセットフィールド」から再開し、同プレフィックスオフセットフィールドは次の使用可能プレフィックスを指示する（実行の詳細は以下に説明する）。

ＳＹＮＣはいかなる真のペイロードも含まないダミーパケットを伝送できる。そのペイロードはパケットの仮想サイズを、すなわち通常の方法で次のオフセットに反映されるサイズを（プレフィックスサイズを含む）、指示するフィールドである。かくしてダミーＳＹＮＣＰＤＵは、その小さい実サイズによって識別される（真のパケットはこのように小さくはない）。

ダミーパケットによって信号送信されるアイドルギャップは、プレフィックスと、データの代わりにその仮想サイズに従い生成されたパディングとを備えるダミーＳＤＵとしてＲＬＣＰＤＵにマッピングされる。その結果生じた真のデータも含むＰＤＵは送信される。パディングだけを含むＰＤＵは、後続ＰＤＵの構築に影響しない限り、構築される必要はない。

このようにパディングＳＤＵは各ＳＤＵプレフィックスの中にあるパディングフラグにより受信ＲＬＣ体によって識別され、破棄される。セグメントの再組み立てに影響が及ばないことに注意されたい（実行の詳細は以下に説明する）。

ＭＣＥは、スケジューリング期間にわたるＳＹＮＣバイトオフセットの増加（またはそれの倍数）に基づき正確な擬似レートを保証することによって、アイドルギャップと共に実際のｅＮｏｄｅＢ供給レートを制御できる。

本発明は、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）のため提案された「バイトレベルシーケンス番号方式同期法」として知られるベーシックＭＢＭＳサービスコンテンツ同期方式の改良に相当する。上述したこの公知の方式は、数個のｅＮｏｄｅＢが同時にパケットを送信することを可能にするが、パケットごとのタイムスタンプは避け、関係する全ｅＮｏｄｅＢにとって共通の連続するＭＢＭＳサービス送信機会によって構成される仮想バイトシーケンスの中で各パケットの配置させるバイトオフセットを代わりに使用する。この方式は、調整体間の複数パケット損失の可能性に耐える。（ＭＣＥと１つ以上のｅＮｏｄｅＢは、送信データブロックの形成に制約を課す。つまり各ブロックは一定量のユーザデータを転送しなければならない（データとしてのアイドルギャップを含む）。ここでユーザデータは、ＭＢＭＳベアラサービスのペイロードを指す。）ただし、容量の浪費を避ける上では望ましいパケットの連結は一般的に、可変オーバーヘッドを招く。よって、ブロック当たりの一定量のデータの要求は、最大連結数への対処に適した各ブロックにおける一定量の予約スペースを意味する。これは規則的なキャパシティの浪費をもたらす。

これより、添付の図面を参照しながら本発明の一例をさらに説明する。

ｅＭＢＭＳサービスのため割り当てられるエアインターフェースリソースと関連Ｌ１パラメータは、少なくともセッションが続く間は、一定と仮定する。さらに、それらは同一容量の転送ブロックに分割されると仮定する。さらに、ＭＡＣ層は一定のオーバーヘッドを消費すると仮定する。これら仮定の一連の結果として、ｅＮｏｄｅＢにおけるＲＬＣは、送信機会にマッピングする、各サービスセッションにつきサイズが一定且つ既知の、ＲＬＣＰＤＵを作る。ただし、予測可能な可変サイズに方式を調整することもできるが、明確を図るため、これ以降は単一のサイズを仮定する。

ＲＬＣＰＤＵは固定ヘッダとペイロード部からなる。ここで定義するペイロードは、実際にはデータ（ＲＬＣＳＤＵまたはそのセグメント）のほかにある程度のオーバーヘッドを含むが、本方式にとっては、このような形でＲＬＣプロセスを提示するのが最適である。使用可能なＲＬＣＰＤＵサイズとヘッダに求められるサイズがどうあれ、ペイロード部はバイト整合され、これ以降ペイロードサイズと呼ぶ整数の既知バイト数（オクテット）を保持する。これは図１に具体的に示されており、ここでサイズ１０のＲＬＣＰＤＵは、ペイロードバイト１６によって、すなわちバイト境界１８で区切られた前述したオクテットによって区切られるペイロードバイト１６の数によって決まるペイロードサイズのペイロード部１４と、ヘッダ部１２とを有する。

サービスセッションに（開始から終了まで）含まれるＲＬＣＰＤＵのシーケンスを考えた場合、ペイロードは概念上、連続バイトストリーム、またはバイトオフセットを通じてアドレスできるアドレススペース（ゼロから始まる）とを形成するとみなすことができる。つまり、図２に示された一連のＲＬＣＰＤＵ２０は各々ＲＬＣヘッダ２２とＲＬＣペイロード２４とを備え、ここでサービスセッションは、サービスセッション開始矢印２６とサービスセッション終了矢印２８との間に位置するＰＤＵ２０によって決定される。

ペイロードスペース３０の仮想マッピングも、ペイロードスペース３０によって形成される仮想連続バイトストリームとの関係で使用されるバイトオフセット３２の例と併せて示されている。

ＳＹＮＣプロトコルによるＳＤＵの伝送時に（ＳＹＮＣはＭＢＭＳサービスパケットをｅＮｏｄｅＢへ伝送し、これは最終的にＲＬＣＳＤＵになる）、ＲＬＣは、（少なくとも）ＳＤＵのサイズを含む制御要素と共に各ＳＤＵをプレフィックスする。このステップは仮想であり、問題はＲＬＣＰＤＵにおける最終的なバイトの配置だけである。これは図３に示されており、ここでＳＹＮＣ３４はＲＬＣＳＤＵ４０を備えるＳＹＮＣＰＤＵ３８をＲＬＣ３６へ伝送し、同ＳＹＮＣＰＤＵ３８はその後ＲＬＣ３６において、本発明の一実施形態に従い発生しＲＬＣ３６によって加えられるプレフィックス４４を含む増補ＳＤＵ４２に形成される。ただしこれらのプレフィックスは、最終的にはＲＬＣＰＤＵのペイロードの中で真の要素となるため、オクテット整合を維持するため、プレフィックスは整数のバイト数を持つ。これはヘッダにおける長さ指示とペイロードにおけるデータ要素との仮想関係として提示されており、伝送ＳＤＵから新規（増補）ＳＤＵへの局所的形成をもたらす。

プレフィックスの中で与えられる長さがプレフィックスそのものの長さを含む代案も可能である。換言すると、これは単に真のＳＤＵの長さではなく、増補ＳＤＵの長さとなる。この同等の方法に実用上の利点はほとんどないように思われるが、ゼロからプレフィックスのサイズまでの長さには特別な意味を与えることができる。例えば、セッションの終わりには最終ＰＤＵをパディングしなければならないかもしれない。これは以下に提案する方法で果たすことができるが、ゼロによるパディングの不定の長さは、「それ以上データなし、セッションは完了」を意味するゼロ長により特定されうる。

ＳＹＮＣによって搬送されるバイトオフセットは（これより「バイトオフセット方式」、または「バイトレベルシーケンス番号方式」コンテンツ同期法の一般的概念を参照する）、増補（プレフィックス）ＳＤＵのサイズの現在合計である。ＭＣＥ（ＳＹＮＣＰＤＵのソース）は、ｅＮｏｄｅＢにおけるＲＬＣ手順について正確に知る必要はない。これがやることは、バイトオフセットを計算するときに一定量（ＲＬＣＳＤＵプレフィックスサイズ）によりパケットのサイズを誇張するだけである。換言すると、第１のＳＹＮＣＰＤＵのバイトオフセットはゼロであり、任意の後続ＰＤＵのバイトオフセットは（アイドルギャップは無視する）、前のＰＤＵのペイロードのバイト数による実サイズに、ＲＬＣプロトコル定義によって課せられる一定数を加えることで増加した、前のＰＤＵのオフセットである。これは、オフセットのより大きな増加によってギャップをも提供する一般的な「バイトオフセット方式コンテンツ同期」法の軽微な調整である。これは、ＳＹＮＣ３４で発生し、パケットまたはＲＬＣＳＤＵ４８とオフセット値４６とを備えるＰＤＵを再び示す図４で具体的に示されている。このＰＤＵの後ろには、パケットまたはＲＬＣＳＤＵ５０とオフセット５２とを備える後続ＰＤＵが続き、この場合のオフセットは、先行ＰＤＵのオフセット４６とパケットサイズ４８との、さらにプレフィックスサイズと、ギャップが発生する場合はそのサイズとの合計に等しい。

このＳＹＮＣプロトコルとＲＬＣプロトコルとのリンク（共有定数）は、おそらく原則として望ましくはないが、多大な制約を提示せず、例えばＳＹＮＣは、プレフィックスの構造もその使用も知る必要はない。これは、オフセット計算に加える一定数について知るだけでよい。

実際、１５００バイト以下のパケットを考えた場合（現在のＬＴＥ仮定）、プレフィックスは２オクテットを要する（後述するとおり、１１ビットの長さ指示と数個のフラグ）。

ＳＹＮＣバイトオフセットは、上に定義したペイロードスペースの中でアドレスとみなすことができ、これはＲＬＣがペイロードスペースの中で、すなわち特定のＲＬＣＰＤＵの中で、または複数のＲＬＣＰＤＵにまたがり、増補（プレフィックス）ＳＤＵを無条件に配置することを可能にする。したがってＳＤＵの配置は以前に失われたいかなるパケットとも無関係となり、これは各ｅＮｏｄｅＢが、Ｓ１リンク（ＭＣＥとｅＮｏｄｅＢとの間）上でのあらゆるパケット損失にかかわらず、他の全てのｅＮｏｄｅＢと同期を保つことを可能にする。図５では、プレフィックス６０とＲＬＣＳＤＵ６２とを備えるＰＤＵに比べて、一連の第１、第２、及び第３のパケットオフセット５４、５６、５８が示されている。

ＲＬＣＰＤＵペイロード６４もギャップ６６と同様に示されており、ギャップ６６は、第２及び第３のパケット間のパディングＳＤＵ（図示せず）で埋めることができる。実際にはそこにペイロードスペースはないが、ＲＬＣＰＤＵ形成は追加的に容易に果たすことができる。つまりＲＬＣは、増補（プレフィックス）ＳＤＵのシーケンスに従い、それらをプレフィックスとともに相次いでコピーし、前のＰＤＵをパッキングするときに途切れた場所から始まり、ペイロードを完了するバイトまでＳＤＵが連続していることをバイトオフセットで確認しながら、現在のＰＤＵのペイロード部を単純に埋める。バイトオフセットの食い違いがＳＤＵの不在を示唆する場合、ＲＬＣは、その食い違いを計上するためいくつかのバイトをスキップし、ことによると後続ＰＤＵに処理を進める。スキップされるバイトのコンテンツ（値）の問題は、後ほどアイドルギャップを検討するときに再び取り上げる（以下参照）。さしあたり、バイトオフセットの食い違いの原因は損失パケットにあるとする。この場合、任意のデータをなくしたＰＤＵはいずれもどのみち破棄する必要がある（つまり送信しない）ため、スキップされるバイトは重要でない。ただしスキップされるバイトがパディングされた場合、結果生ずる転送ブロックは、パケット損失を被らなかった近傍ｅＮｏｄｅＢによって送信されるものと異なり、ＭＢＳＦＮ伝送原則に違反することとなる。

上の定義は、仮想的に関連づけられたプレフィックスが今、真のＳＤＵの手前に実際にコピーされることを、つまり、あたかもペイロードの一部としてデータと混在させられることを意味する。この説明の過程で、これは最も自然なアプローチである。ただしＲＬＣパッキングに関する従来技術の状況においては、これらのＳＤＵプレフィックス等の制御要素をグループにまとめ、それらをＲＬＣヘッダへ組み入れることにより、これを可変サイズとするのが一般的なやり方である。よって、これらのプレフィックスをペイロードの中に置くことの妥当性は革新的とみることができる。さらに、先行技術によって提案されるグループ化には問題があり、それは以下に示すとおりに対処できるが、不利な効果を伴う。この問題は、ここで提示するペイロードスペースの観点から、プレフィックスを２つのＰＤＵの間で分割する必要があるケースに、または先行技術の観点から、例えばＲＬＣＰＤＵ構築がＰＤＵの中にプレフィックスより小さい、例えばちょうど１バイトの、予備キャパシティをもたらすケースに相当する構成に伴い発生する。同期にとってはＳＹＮＣバイトオフセットがデータバイトとプレフィックスバイトとの合計に一致することが重要であり、ただひとつの予備バイトも無駄にはできない（証明：これが２度起こると食い違いはプレフィックスにとって十分な２バイトであり、もしもある１つのｅＮｏｄｅＢがいくつかのパケットを失うなら、これは機会を逸し、あちこちでバイトを浪費することとなり、他のｅＮｏｄｅＢとの同期をゆるめる）。状況を改善するため、ＲＬＣヘッダにてプレフィックスのリストの中に部分的プレフィックスを有するよう配置でき、これらはフラグを必要とする。結局のところ、この方法はすでにプレフィックスリストの終わりを指示するため継続フラグを必要とする。あるいは、予備バイトはＲＬＣヘッダの固定（メイン）部分における予約バイトで補完できる。ただしその予約バイトは、一般的なケースでＰＤＵのキャパシティを減少させる。また、結局これはペイロードスペースの中の何もないところからバイトを作ることになる。よってこれは、ＳＹＮＣバイトオフセットとの同期を保つため、次のＰＤＵにおいて浪費される追加バイトによって補償されなければならない。このような構成は、これを信号送信するためのフラグをも必要とする。これは必要とあればことごとく明らかにできる。ここでの主張は、可変ＲＬＣヘッダでプレフィックスをグループ化することは厄介で非効率的であるため、プレフィックスはペイロードの中に置いたほうが良いということである。

ＲＬＣＰＤＵアンパッキングは、ＰＤＵが失われない（つまりより下位層によって決定されることはない）限りは、瑣末なことである。この場合、連続ペイロードスペースの概念は依然通用する。バイトのストリームは、後続ＳＤＵの長さを含む所謂プレフィックスから始まり、これのすぐ後ろに（ペイロードスペース内）次のプレフィックスが続く。図６は、受信端末におけるダイレクトマッピング７０による一連のＲＬＣＳＤＵ６８のアンパッキングについて図示している。最終ＰＤＵはあるパディングで完了する必要があるかもしれないことに注意されたい。このように、アンパッキングＲＬＣは（データストリームの中でアイドルギャップを処理する場合と同様に）何を破棄するべきかを指示するプレフィックスを有することとなる。実際のところ、ＲＬＣはＰＤＵを一度に１つずつ処理し、これは単純に２つのことを意味する。
−ＲＬＣはＳＤＵの長さを記憶し、これが現在のＲＬＣＰＤＵを超えて継続していることが明白ならば、どの程度アンパッキング済みかを記憶する。
−ＲＬＣは、ＰＤＵペイロードに残っているスペースがプレフィックスにとって小さすぎることを検知することがある（提案されているＬＴＥ実装において、それはわずか１バイトしか残っていないことを意味する）。この場合ＲＬＣは、この残りのＰＤＵ部分を、次のペイロードの開始によって完了するプレフィックスの先頭と仮定し、保存しなければならない。

この後者の点は、上の論述から自然に導き出されるものであるが、メインヘッダの後ろでプレフィックスをグループ化してなる先行技術に対する改善である。後者は、上でいくぶん念入りに詳述したとおり、やりにくい、またはキャパシティを浪費することになる、幾つかの方法で解決できる。

いくつかのＲＬＣＰＤＵがアンパッキング側で失われる場合には（破損、ｅＮｏｄｅＢにおける損失パケットの影響等、何らかの理由でより下位層によって復号化できない）、いくつかのプレフィックスが不在となる可能性があり、これは上述した連鎖を破綻させる。不在ＰＤＵ（実際には任意の数のＰＤＵ）の後でアンパッキングプロセスを再開するために、各ＰＤＵは、アクセス可能な次のプレフィックスをどこで見つけるかを指示する情報を含まなければならない。この情報は、ＲＬＣ固定ヘッダの中に長さ指示要素を含めることによって提供される。ヘッダのサイズは、その固定サイズのため、あるいはむしろ結果生じるペイロード部の既知サイズのため、同期に影響しないことに注意されたい。この新しいフィールドは、図７のようにペイロード部を開始する増補ＳＤＵセグメントの長さとみなすことができ、同図においては、プレフィックスオフセットフィールド値７４を導入したペイロード７２とともにＲＬＣＰＤＵ構造が示されており、これは７６にも単独で示されている。ただし検討するべき異なるセグメント化ケースがあり、「プレフィックスオフセットフィールド」と命名されるこの長さ指示のより厳密な定義は、ペイロードＰＤＵ部の先頭に対する増補ＳＤＵの第一の開始のオフセットであり、以下の論理的限界ケースを伴う。

もしもＰＤＵが進行中のセグメント化から始まらないなら、当然「プレフィックスオフセットフィールド」は図８に示すとおりゼロに設定しなければならず、同図は図７と同様、ペイロード７８と、導入されたプレフィックスオフセットフィールド８０とを示しており、これは８２にも単独で示されているが、ここでフィールド８０の実値はゼロということになる。

もしもＰＤＵが１セグメントだけを保持するなら（すなわちこのＰＤは、長いセグメント化ＳＤＵの中間に位置し、したがってペイロードにプレフィックスはない）、「プレフィックスオフセットフィールド」の値は、少なくともペイロード部の長さには等しくなければならない。その長さに代わるものは、（３）で定義した連続ペイロードスペースにおける次のプレフィックスまでのオフセットであるが、それは実際には必要ない。ペイロード８４の長さがプレフィックスオフセットフィールド８６の長さに等しくなる一例を示した図９を参照されたい。このプレフィックスオフセットフィールドもまた８８にて単独で示されている。

すでに定義が示唆しているとおり、もしペイロードが切断されたプレフィックスで始まるなら（これが前のＰＤＵで始まったため）、「プレフィックスオフセットフィールド」で指し示すべき正しいプレフィックスは次のプレフィックスである。これは図１０に示すとおり、ここでは次のプレフィックスもまた期せずして切断される。つまり、ペイロード９０の長さは、分割されたプレフィックス９４、９６を除いたプレフィックスオフセットフィールド９２の長さにほぼ等しく、ここでもまたプレフィックスオフセットフィールド９８は９８にて単独で示されている。

ただし、この後者のケースは改善できるシナリオに属する。つまり、増補ＳＤＵがＳＤＵの開始前にセグメントされる度に、ＳＤＵ（または、これが次のＰＤＵにまたがってセグメント化される場合にはこれの最初のセグメント）を回復することが可能である。ＲＬＣヘッダにおける余分のフラグ（または、いずれにせよヘッダの一部をなす「プレフィックスオフセットフィールド」そのもの）により、以下の状況は指示できる。
セグメント化は増補ＳＤＵを、そのプレフィックスとＳＤＵとの間で分割する、及びプレフィックスの最後のバイトは現在のＰＤＵの中にある。

プレフィックスサイズが２より大きいなら、より多くのケースがあることに注意されたい。

ＳＹＮＣバイトオフセットメカニズムによりアイドルギャップはＭＣＥで生成され、ｅＮｏｄｅＢの観点からは損失データとみなされる（アイドルギャップは、パケット配信ネットワーク上でのレートマッチング、すなわち柔軟性のため必要であり、ｅＮｏｄｅＢは自ら同期アイドルギャップを生成できない）。ただしこの場合、アイドルギャップと損失パケットの共通手順の単純さは弊害をもたらす。なぜなら損失パケットは、各ｅＮｏｄｅＢで別個に発生する偶発的イベントと想定される。よって、ある１つのｅＮｏｄｅＢが不在データを伴いＰＤＵを送信する場合、そのｅＮｏｄｅＢは確実に、近傍ｅＮｏｄｅＢが送信するものとは異なるブロックを送信することとなり、ＭＢＳＦＮ伝送ルールに違反することとなる。したがってパケットの損失は、正常に受信され、ギャップを取り囲むデータの実質的損失をも余儀なくする（単にギャップとともにＰＤＵを共有するセグメントではなく、これらのセグメントが属するパケット全体）。ただしアイドルギャップは異常で希なケースではない。アイドルギャップは平常作動中に頻繁に発生し、全ＭＢＳＦＮ参加ｅＮｏｄｅＢにはよくあることである。アイドルギャップの信号送信（すなわち、それらを損失パケットと区別するメカニズム）により、ｅＮｏｄｅＢはアイドルギャップを取り囲むあらゆるデータを捨てる必要はなく、全ての部分的に満たされたＰＤＵは全てのｅＮｏｄｅＢで同じになる。アイドルギャップは、ユーザデータを所持しないダミーＳＹＮＣＰＤＵを使用することにより、ＳＹＮＣプロトコルにいかなる大幅な変更も加えずとも、信号送信されうる。ダミーＳＹＮＣＰＤＵの目的は、ｅＮｏｄｅＢに向けてアイドルギャップを明確に提示することである。したがってダミーＳＹＮＣＰＤＵは、信号送信するつもりのギャップのサイズを所持しなければならない。これは、もしもそれらのパケットが適当サイズのダミーパケットとともに生成されるなら、大した問題ではない。しかし第１に、これは余分なキャパシティを占めており、第２に、ダミーデータは真のデータから区別されなければならない。しかし、もしもバイトオフセットへ仮想サイズが加えられる一方でＰＤＵのデータペイロードが単純に省かれるなら、ギャップのサイズはさかのぼって知るよりほかない（複数のダミーＰＤＵは専らこれを緩和する）。その上、ギャップの一部が実際、ひとつ以上の損失パケットを含むというキャンセルが依然あり、それ故ｅＮｏｄｅＢが、部分的に満たされたＰＤＵを送信することが正しいという保証がなくなる。これは図１１Ａに図示されており、同図においては、時間に対して、パケットまたはＲＬＣＳＤＵ１０２をプレフィックスオフセット１０４とともに備えるＰＤＵが示されており、後続のダミーＳＹＮＣＰＤＵ１０６は、オフセット１０４とオクテット単位のパケットＲＬＣＳＤＵ１０２とローカル値２との合計に等しいオフセット１０８を含み、その後ろにＰＤＵが続き、そのプレフィックスオフセット１１０は、値Ｘに加えてダミーＳＹＮＣＰＤＵ１０６のオフセットの合計からなる。

図１１ＢもＰＤＵ１０２、１０４とダミーＳＹＮＣＰＤＵ１０６が再び到着する一例を示しているが、ここで介在するＰＤＵ１１２はパケットまたはＲＬＣＳＤＵ１１４を有すると考えられ、プレフィックスオフセット１１６は失われ、その後には、前述したオフセット１０４と、前述したダミーＳＹＮＣＰＤＵ１０６に等しいパケットサイズと、ダミーＳＹＮＣＰＤＵのプレフィックス１０８と、前述した公称値Ｘとの合計に等しいプレフィックスオフセット値を伴うＰＤＵが続くと考えられる。提案されたダミーＳＹＮＣＰＤＵ構造は通常のＰＤＵと同じだが、そのペイロード（パケットまたはＲＬＣＳＤＵ）は、ペイロードのサイズ（ダミーパケットの仮想サイズ）として設定された長さインジケータに置き換えられる。バイトオフセットは依然、適切なＰＤＵとして設定されるが、ダミーＰＤＵの後に続く任意のパケット（それ自体ダミーまたはダミーでない）のオフセットは、前のパケットの実サイズではなく仮想サイズにＲＬＣＳＤＵプレフィックスサイズを加えたサイズによって増加される（あるいは、ダミーパケットの仮想サイズは、後続ＳＹＮＣＰＤＵとのオフセットの差からプレフィックスサイズを引いたものである）。長さインジケータに要求されるサイズは最小パケットサイズより小さいため、ダミーＰＤＵは通常のＰＤＵから実サイズによって区別される。

無論、ダミーＳＹＮＣＰＤＵが失われることがあることは分かる。ただしこの場合、ｅＮｏｄｅＢはパディングされたＰＤＵを送信しないというより安全な選択肢に戻るだけのことである。異常な状況においても損失は許容され、ダミーパケットの損失も何ら変わりはない。

上記のとおり、アイドルギャップは、送信すべきデータを所持する不完全ＲＬＣＰＤＵをパディングするためのメカニズムを必要とする。パディングは単に、全てのｅＮｏｄｅＢが同じＰＤＵを作ることを保証するためのメカニズムであり、上述したパッキング法から取り残された全体を満たす必要はない（例えば、パディングはペイロードの末尾へ移すことができる）。ただし、アイドルギャップをダミーＳＤＵとして扱うと格段に単純になる（パディングはダミーデータとして生成されパディングフラグによって信号送信されるが、ダミーデータを所持しないので、ダミーＳＹＮＣＰＤＵは透過的にダミーＳＤＵにならないにもかかわらず）。加えて、この方法は上述した全ての検討が有効であり続けることを保証する。よって、真のＳＤＵと同様、ダミーまたはパディングＳＤＵは、全てゼロ（または規格化される場合はゼロ以外）となるパディングの長さを指示するプレフィックスの後に続く。これらのパディングＳＤＵはアンパッキングＲＬＣ体によって破棄される必要があり、各プレフィックス内の「パディングフラグ」は関連ＳＤＵがパディングであるか否かを指示するものであり、パディングの値はそれらを信号送信するにあたって信頼できる方法ではない。さもなければ、アンパッキングは影響を受けない。パディングＳＤＵはあらゆるＳＤＵと同様にセグメント化できる。失われたＲＬＣＰＤＵは、セグメントの性質が定まらないことを意味するが（一致するプレフィックスが不在または不完全だった場合）、不完全ＳＤＵのセグメントのようにどのみち破棄される。パディングＳＤＵはダミーＳＹＮＣＰＤＵごとに作成することが示唆される。パディングを所持するだけのＰＤＵは送信する必要はなく、構築する必要すらないことに注意されたい。

上述したとおり、ＲＬＣＰＤＵの中の論理的ギャップにパディングが合致する必要はない。換言すると、ひとたびセグメント化されＰＤＵに割り当てられたＳＤＵは、例えばギャップを一端へ押しやりながら、ＰＤＵの中で再配置されうる。ただしこれは、ギャップが非常に小さく（ギャップのＰＤＵとの交差が１バイトくらい小さく）なる場合に問題を招き、これはフラグによって解決できる。

ｅＮｏｄｅＢキューは決して空にならないことが好ましいため、ＭＣＥはｅＮｏｄｅＢ誘発オーバーヘッドを全面的には無視できない（ｅＮｏｄｅＢは損失パケットと同様に進行しなければならないが、ＭＣＥにとっては同期化アイドルギャップを生成するほうが良い）。幸いこの方法により、ＭＣＥは、ＳＹＮＣバイトオフセットによって測定される一定の供給レートを保証するだけでよい。よって、アイドルギャップサイズ計算は実際には、目標平均パケットデータ送信レート（バイト単位）ではなく、時間の経過にともなうオフセット増大の関数である。換言すると、アイドルギャップはＳＹＮＣバイトオフセットを規制し、実パケットデータの量に関係づけるのではなく、ＲＬＣペイロードスペースの中でギャップを効果的に管理する。したがって原則として、アイドルギャップに関係するオフセットはプレフィックスより小さくなり、これは上述した提案手法を無効にする。ＳＹＮＣ層（後続オフセットがプレフィックスサイズを下回らなければならない場合のダミーパケットの負の仮想サイズ）とＲＬＣ層（通常のプレフィックスが後ろに続く、ありえない１バイトギャップの代わりに、通常の、すなわち３バイトの、プレフィックスよりＳＤＵプレフィックスが長いことを指示する、ＳＤＵプレフィックス内のフラグ）の両方における改善は、この問題を解決できる。ただし、そのような非常に小さいアイドルギャップは現実的ではなく、所定の最小サイズ（実際、ＲＬＣ関連ＳＹＮＣバイトオフセット増加のためすでに指定されたものと同じ値）より長いアイドルギャップを要求するほうが格段に単純であり、その結果、パディングＳＤＵ（プレフィックス完備）は常に特定のギャップの中に収められることができる。

上述したとおり、エアインターフェースサービスレートが平均してＭＣＥ供給レートより高くならないことを保証するため、ＭＣＥがある程度の認識を持たなければならないことが理解される。ここで提示する同期法は、スケジューリング期間にわたるオフセットの増加率が（真のユーザデータレートではない）、またはその倍数が、正確に一定となるよう（そして他の全オーバーヘッドを勘案し、物理的配分が支持できるものに一致するよう）パケットまたはアイドルギャップを提供することをＭＣＥに要求するまでこの認識を軽減する。

したがって上記から、本発明が現在の技術からの有利な脱却を意味することは理解されるであろう。特に、ペイロードの中でデータと混在する制御情報を備えるＳＤＵプレフィックスの概念である。

ＲＬＣメイン（固定）ヘッダの中に長さインジケータを有する必要があることも理解される。これはＳＤＵヘッダ（プレフィックス）の追加の例ではなく、ＳＤＵではなくセグメントに関連する長さインジケータに過ぎない。その厳密な定義は上記のとおりであり、これは、セグメント化をサポートするためにプレフィックスが余分なフィールドを必要としないことを暗示する。

本発明は、固定ヘッダ（またはプレフィックスオフセットフィールド）内の２、３のフラグにより、増補ＳＤＵがこれのプレフィックスまたはその一部だけを失うセグメント化ケースに対処するアイデアを提案する。

必須ではないが、本発明は、長さ指示の中にそれ自体含まれるプレフィックスに関連してゼロによる最終パディングする可能性を認識する。

これはセッションの中でのパディングに使用することもできるが、発明者はこれを好ましいものとせず、プレフィックス内のパディングフラグをより好ましいものとする。パディングは、ペイロード内のその論理的位置に置く必要はない。各ＲＬＣＰＤＵを調べ、パディングは常にペイロードブロックの末尾へ移すことができる。この場合、ゼロの長さ（最初のバイトをプレフィックスとして読み取る）はそれがパディングであることを指示でき、その実際の長さはペイロードブロックのサイズから暗示される。そして全てのプレフィックスにおいてパディングビットは余剰となる。ただし、もしもＰＤＵに割り当てられるパディングがわずか１バイトなら問題がある（プレフィックスより短いアイドルギャップは発生しないが、ペイロードスペースにおけるその位置は恣意的であり、アイドルギャップを挿入するときにＭＣＥがＲＣＬブロック境界に注意を払うことは明らかに間違っている）。ヌル長を指示するプレフィックスはもちろんのこと、プレフィックスを作るにあたって１バイトは短すぎる。よって、さらに別のフラグが固定ヘッダにて必要となる。いずれにせよプレフィックスには予備ビットがあるため、プレフィックスごとのパディングフラグと期待されるところのパディングは、よりシンプルで、より優れたものとなる。

この点において制限されないが、本発明は、ＭＢＳＦＮをサポートするｅＮｏｄｅＢ（ＬＴＥをサポートするノードＢ）と、ＭＢＭＳ（＆）を受信できるＬＴＥＵＥと、ＬＴＥマルチセル調整体（ＭＣＥ）を実装する装置において、具体的用途を見いだすであろう。

ＲＬＣＰＤＵ構造の図である。ペイロードスペースの仮想表現をなす。ＲＬＣによるプレフィックスＳＤＵ形成の図をなす。ＳＹＮＣバイトオフセットの図である。ペイロードスペースにおけるプレフィックスＳＤＵの配置を示す図である。受信端末によるＲＬＣＳＤＵのアンパッキングを示す概略図である。一般的なＲＬＣＰＤＵ構造を示す図である。図７の構造に類似する構造の図であるが、ペイロードの先頭に進行中のセグメント化は見られない。類似するＲＬＣＰＤＵ構造の図であるが、セグメント化の最中にある。セグメント化によって２つのプレフィックスが分割されたＲＬＣＰＤＵ構造の図である。ダミーＳＹＮＣＰＤＵ使用の各種シナリオを示す。

Claims

移動無線通信ネットワークにおけるコンテンツ同期のための、ＲＬＣヘッダ及びペイロードを含むＲＬＣブロックの形成方法であって、
移動無線通信ネットワーク装置が、前記ペイロードの中で複数のＳＤＵの各々につき制御要素を提供するステップを含み、
各制御要素は、それぞれのＳＤＵの前に配置されるヘッダ要素を備え、
前記ヘッダ要素は、前記ＲＬＣヘッダとは異なる、
ことを特徴とする方法。
前記ヘッダ要素は、前記ＳＤＵの各々につきプレフィックスを備える、請求項１に記載の方法。
前記ヘッダ要素は、前記ヘッダ要素の参照先にあたるデータの長さを指示するためのフラグを含むことができる、請求項１または２に記載の方法。
前記ヘッダ要素は、前記ペイロードの中にデータとともに含まれる、請求項１、２、または３に記載の方法。
前記ヘッダ要素のサイズは一定である、請求項１〜４のいずれか一項に記載の方法。
前記ＲＬＣヘッダの中に長さインジケータを含む、請求項１〜５のいずれか一項に記載の方法。
前記移動無線通信ネットワーク装置が、アイドルギャップを計算するステップを含む、請求項１〜６のいずれか一項に記載の方法。
前記移動無線通信ネットワーク装置が、ダミーパケットを使用するアイドルギャップの信号を送信するステップを含む、請求項７に記載の方法。
前記移動無線通信ネットワーク装置が、前記ダミーパケットをダミーＳＤＵとしてＲＬＣＰＤＵにマッピングするステップを含む、請求項８に記載の方法。
前記ヘッダ要素の形成は、前記長さインジケータに関連しゼロによる最終パディングを使用するよう構成できる、請求項６に記載の方法。
移動無線通信ネットワークにおいてコンテンツ同期のため、ＲＬＣヘッダ及びペイロードを含むＲＬＣブロックを提供し、前記ペイロードの中で複数のＳＤＵの各々につき制御要素を提供するよう構成される移動無線通信ネットワーク装置であって、
前記装置は、各制御要素がそれぞれのＳＤＵの前に配置されるヘッダ要素を備えるよう構成され、
前記ヘッダ要素は、前記ＲＬＣヘッダとは異なる、
移動無線通信ネットワーク装置。
請求項１から１０のいずれか一項に記載された方法を遂行するよう構成される、請求項１１に記載の移動無線通信ネットワーク装置。
マルチセル調整体を備える、請求項１１または１２に記載の移動無線通信ネットワーク装置。