JP4237794B2 - フレームプロトコル・データフレームにおける一般化したスペア拡張フィールドの使用 - Google Patents

Description

本発明は無線通信の技術分野に関する。詳しくは、本発明は、異なる各種通信チャネルを介して無線で通信を行う際に使用されるフレームプロトコルに関し、特に３ＧＰＰに準拠するようなプロトコルに関する。

第３世代パートナープログラム（３ＧＰＰ）に準拠する各種通信チャネル（例えば、ＤＣＨ、ＤＳＣＨ、ＨＳ−ＤＳＣＨ、ＲＡＣＨ、ＦＡＣＨ、その他など）を介して、無線で通信を行う際に使用されるデータフレームは、フレームプロトコルに関連する種々の３ＧＰＰ技術規格によって規定されている。特に、ＴＳ２５.４２５、ＴＳ２５.４２７およびＴＳ２５.４３５のこれら３ＧＰＰ技術規格の各々は、いわゆるスペア拡張（ＳＥ：Spare Extension）の情報要素（ＩＥ：Information Element）を規定するものである。すなわち、個々の３ＧＰＰ技術規格は、このフレームを現在規定しているフレームと互換のないものにすることなく、後でリリースされる３ＧＰＰ技術規格のフレームに、ＩＥを追加または規定化する位置（フィールド）を提供／規定するものである。例えば、ＴＳ２５.４３５ ｖ５.５.０は、将来使用できるように０〜２オクテットを予約するような位置（１以上の規定を行うＩＥ用）を規定する。スペア拡張（以降、ＳＥと表記）セクションは、リリース '９９版以降からのすべてのリリース版に対して提供されるものである。いわゆるリリース '９９版（リリース '９９版以降のバージョン、すなわち以降のリリース版）の後に追加されるすべてのフィールドに、ＳＥセクションが追加される。

ＳＥに関する規定の不足に起因して、すなわち、任意の規格のリリース版（すなわち、例えばＲｅｌ-５またはＲｅｌ-６）に新規ＩＥを追加するような３ＧＰＰ規格において、ＳＥの使用方法に関する規格化の不足に起因して、実際にＳＥを使うことは困難である。一つには、ＳＥが使用中であるか否かの検出が困難である。なぜならば、この検出を行うためには、受信用ノードは、ＳＥが存在しているか否かを検出するためにフレームのペイロード部のすべてのＩＥについて構文解析を行う必要がある。さらに、たとえ受信用ノードがＳＥ部を検出し、これを取り出したとしても、受信用ノードがＳＥを使用する方法を決定することが困難だからである。すなわち、ＳＥを介して２つ以上の新規ＩＥを提供する場合、フレームの中でＩＥがどのような順序で存在するかを知ることは困難である。なぜならば、ＳＥの使用方法が定められていないからである。例えば、ＩＥがＲｅｌ-６の中に追加され、このＲｅｌ-６の規定がフリーズされたときに、Ｒｅｌ-５規定の中に重大な誤りが生じて、新規ＩＥを必要とする場合、ＩＥをＲｅｌ-５に追加する方法を知ることは困難である。このことを理解するのに、フレーム構造を示す図２を参照にされたい。また、図３Ａと図３Ｂとを参照にされたい。この図は、Ｒｅｌ-６内のＳＥの中にＩＥを追加し、次いで規定をフリーズさせたときに、重大な誤りを訂正するために、Ｒｅｌ-５内のどこに新規ＩＥを追加すべきかを知ることは困難であることを示す。

しかしながら、一つだけ確かなことがある。それは、新規Ｒｅｌ-５のＩＥを追加する位置が、因果関係をもつことがあることである。例えば、Ｒｅｌ-６のＩＥの前方に新規Ｒｅｌ-５のＩＥを追加する場合、これは、後方互換性のないＲｅｌ-６規定に変更を引き起こすことになる。Ｒｅｌ-６のＩＥの後方に新規Ｒｅｌ-５のＩＥを追加する場合、Ｒｅｌ-５の実行はＲｅｌ-６のＩＥを理解することも可能である。

したがって、本発明は、ＳＥを使用する方法について扱う。すなわち、リリースするための新規ＩＥの追加方法、および特に事前にリリースされた規定に適合させる新規ＩＥの追加方法について扱う。さらに、本発明は、ＳＥが使用中であるか否かを示す方法についても扱う。

さらに、上述の種々のフレームプロトコル（すなわちＴＳ２５.４２５、ＴＳ２５.４２７、ＴＳ２５.４３５）内の制御フレームにおけるスペア拡張部フラグ（以降、ＳＥＦと表記）の最大サイズが、３２オクテットであるのに対して、プロトコルにおけるＳＥＦの最大サイズは２オクテットにすぎない。しかしながら、長さの違いを説明する十分な理由は存在しない。スペア拡張部（ＳＥ）はこのような短いデータフレームなので、過度にＳＥを限定することは、厄介な問題を引き起こす可能性がある。したがって、本発明は、上記プロトコルに準拠するデータフレームにおけるＳＥの長さについても扱うものである。

本発明の第１の態様では、通信システムの送信用ノードと受信用ノードとの間で、フレームに編成される情報を通信する際に使用されるフレームプロトコルを提供する。そして、上記フレームプロトコルは、上記フレーム内に１以上の情報要素（ＩＥ）フィールドの値を搬送するスペア拡張（ＳＥ）セクションを含み、上記送信用ノードは上記受信用ノードに上記フレームを送信するステップを有する。さらに、上記フレームプロトコルは、新規ＩＥフラグのＩＥの個々のフラグを介して、上記ＳＥセクションが１以上のそれぞれのＩＥの有効データを上記ＳＥセクション内に含むか否かを、上記受信用ノードに対して示すような上記新規ＩＥフラグのＩＥを上記フレームが含むことを特徴とする。

本発明の第１の態様によれば、上記新規ＩＥフラグのＩＥは、上記ＳＥセクションが１以上のそれぞれのＩＥの有効データを含むか否かを指し示すことができる。これは、上記新規ＩＥフラグのＩＥのビット位置と、上記ＳＥセクションの中で存在する１以上のそれぞれのビットセットの位置との間の所定の対応関係に基づいて、指し示すことができる。

また、本発明の第１の態様によれば、上記フレームは、ＳＥセクションの中に１以上のＩＥの有効データを含むか否かを示すために、上記フレームのヘッダのスペアビット部内にＳＥフラグのＩＥを含むことができる。

また、本発明の第１の態様によれば、上記フレームは、少なくとも第１のＳＥ長のＩＥ、および、第１の新規ＩＥフラグのＩＥと第１のＳＥサブセクションとを含む少なくとも第１のブロックとを含む。この場合、上記第１のＳＥ長のＩＥは、上記第１のブロックの長さを示すことができる。

また、本発明の第１の態様によれば、上記フレームは、新規ＩＥフラグのＩＥと対応するスペア拡張サブセクションとを、個々に順番に含む複数のブロックを備えることができる。さらに、個々のブロック内の個々の新規ＩＥフラグのＩＥのビットは、上記ブロックの一部として次の対が上記フレームの中に含まれているか否かを示すことができる。

また、本発明の第１の態様によれば、上記フレームは、ＳＥセクションが１以上のＩＥの有効データを含むか否かを示すために、そして有効データを含む場合は上記ＳＥセクションの長さを示すために、該フレームのヘッダ内にＳＥ長のＩＥを含むことができる。

また、本発明の第１の態様によれば、上記ＩＥが導入される順に、上記ＳＥセクション内に上記ＩＥを含むことができる。

また、本発明の第１の態様によれば、 上記受信用ノードに実装されている規定のリリース版よりも、時間的に後でフリーズされた規定のリリース版が上記ＩＥフィールドに導入されたとき、上記ＳＥセクション内に存在するＩＥと上記新規ＩＥフラグのＩＥ内の対応するビットとが、上記受信用ノードによってスペアビットとして処理することができる。

また、本発明の第１の態様によれば、上記フレームは、有効データを有するものとして、上記新規ＩＥフラグのＩＥによって示されるＩＥのビットのみを、ＳＥの中に含むことができる。

本発明の第２の態様では、本発明の第１の態様の場合のようなフレームプロトコルに従って動作または機能することができる装置、すなわち、通信システムの送信用ノードと受信用ノードとの間で、フレームに編成される情報を通信する際に使用されるフレームプロトコルに従って動作する装置を提供する。また、１以上の情報要素（ＩＥ）フィールドの値を搬送するスペア拡張（ＳＥ）セクションが含まれる上記フレームを送信する手段を具備する装置であって、上記ＳＥセクションが１以上のそれぞれのＩＥの有効データを上記ＳＥセクションの中に含むか否かを、新規ＩＥフラグのＩＥの個々のフラグを介して、上記受信用ノードに対して示す上記新規ＩＥフラグのＩＥを上記フレームの一部として提供することを特徴とする装置を提供する。

本発明の第３の態様では、送信用ノードと受信用ノードとを備えたシステムであって、上記送信用ノードが本発明の第２の態様に従う装置を備えたシステムを提供する。

本発明の第３の態様によれば、上記受信用ノードに実装されている規定のリリース版よりも、時間的に後でフリーズされた規定のリリース版が、上記ＩＥフィールドに導入されたとき、上記受信用ノードは、受信されたフレームの上記ＳＥセクション内に存在するＩＥをスペアビットとして処理するように動作することができる。

本発明の第４の態様では、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、通信端末装置またはノード（または他のデバイス）において、コンピュータ・プロセッサによって実行されるコンピュータプログラムコードを具現化するためのコンピュータによる読み取り可能な格納構造を有する。また、コンピュータプログラム製品は、本発明の第１の態様に準じて実行されるプロトコルに従って通信端末装置またはノードを動作させる命令が含まれているコンピュータプログラムコードと共に提供される。

本発明の第５の態様では、通信システムの送信用ノードと受信用ノードとの間で、フレームに編成される情報を通信する際に使用されるフレームプロトコルを提供する。そして、１以上の情報要素（ＩＥ）フィールドの値を搬送するスペア拡張（ＳＥ）セクション内に含む上記フレームを、上記送信用ノードが上記受信用ノードへ送信するステップを有するフレームプロトコルを提供する。さらに、上記受信用ノードに実装されている規定のリリース版よりも時間的に後でフリーズされた規定のリリース版が、上記ＩＥフィールドに導入されたとき、上記受信用ノードが、受信したフレームの上記ＳＥセクション内に存在するＩＥフィールドの値をスペアビットとして処理するようなフレームプロトコルを提供する。

本発明の第５の態様によれば、上記ＩＥフィールドが有効データを含むか否かにかかわらず、上記ＳＥセクション内の個々のＩＥフィールドは、所定の固定位置を上記ＳＥセクション内に有する。

また、本発明の第５の態様によれば、上記ＩＥが導入される順に上記ＳＥセクション内に該ＩＥを含むことができる。

また、本発明の第５の態様によれば、上記ＳＥセクション内に存在するＩＥが、ビット空間内の値がいつ有効でなくなるかを示す予約値を有することができる。

本発明の第６の態様では、本発明の第５の態様のようなフレームプロトコルに従って動作する装置を提供する。

本発明の第７の態様では、上記送信用ノードと上記受信用ノードとを具備するシステムを提供し、上記送信用ノードは本発明の第６の態様の場合のような装置を備える。さらに、上記受信用ノードに実装されている規定のリリース版よりも、時間的に後でフリーズされた規定のリリース版が上記ＩＥフィールドに導入されたとき、上記受信用ノードは、受信したフレームの上記ＳＥセクション内に存在するＩＥを、スペアビットとして処理するように動作することができる。

本発明の第８の態様では、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、通信端末装置またはノードにおいて、コンピュータ・プロセッサによって実行されるコンピュータプログラムコードを具現化するためのコンピュータによる読み取り可能な格納構造を有する。そして、上記コンピュータプログラムコードと共に、通信端末装置またはノードを本発明の第５の態様に従って動作させる命令を含むコンピュータプログラム製品が提供される。

本発明の上記の目的およびその他の目的、特徴および利点は、添付図面と関連して提示される以下の詳細な説明の考察から明らかになる。

次に図１を参照してわかるように、本発明は、ＴＳ２５.４２５、ＴＳ２５.４２７およびＴＳ２５.４３５のうちの一つの３ＧＰＰリリース版の規定または別の３ＧＰＰリリース版の規定に準拠して、フレーム１０を受信用ノード１２に送信する無線通信システムの送信用ノード１１を扱うべきものである。当該技術の規定は、本発明に基づいて変更することになるであろう。本発明によって提案され、また以降でも説明するように、本発明は下記のように仮定している。データフレーム内のＳＥフィールド長が制御フレームの長さと同じになるように、ＴＳ２５.４２５、ＴＳ２５.４２７およびＴＳ２５.４３５に準拠するフレーム内のＳＥフィールド長は、３２オクテットまで増加される。しかし、本発明は、３２オクテット以外のＳＥフィールド長さの場合にも、当てはまるものであることを理解されたい。

また、明確なことは、ＴＳ２５.４２５、ＴＳ２５.４２７ならびにＴＳ２５.４３５内のいわゆるＳＥは、以下で説明するいわゆる新規ＩＥフラグのＩＥをＳＥに加えられた状態を包含することである。

図４または図５に例示するように、Ｒｅｌ-５（最新／最後版）に関連する上述のフレームプロトコル規定（ＴＳ２５.４２５、ＴＳ２５.４２７ならびにＴＳ２５.４３５）におけるデータフレーム（ＤＣＨ、ＤＳＣＨ、ＨＳ−ＤＳＣＨ、ＲＡＣＨ、ＦＡＣＨ、その他のチャネルを介する通信用に使用）に対する拡張メカニズムは、あまり明瞭ではないし、その他のリリース版の規定も明瞭ではない。ＳＥフィールドは規定されているが、ＳＥフィールドの使用方法は明瞭に規定されてはいない。データフレームに対するＳＥフィールドの規定は、０〜２オクテットのフィールドで、新規ＩＥを後方互換性のある方法で将来追加できる位置を示すフィールドということしか提示されていない。新規ＩＥを追加する方法（ＳＥフィールド内での位置、手順）に関する規定は存在していない。

したがって、以下の問題が発生する可能性がある。Ｒｅｌ-５で、リリースの規定（リリースバージョンの規定）の新規ＩＥが特定化され、次いで、このリリース版（リリースバージョン）のフレームプロトコルがフリーズされると、早期バージョンの中に、後方互換性の面において、いくつかのＩＥを含めることができなくなる。しかも、このことは常に発生する可能性があるので、重大な誤りが発見されたときに、この重大な誤りを訂正しなければならない（現在のバージョンならびにそれ以前のすべてのバージョンにおいて訂正が必要となる）。この理由のために、ＮＢＡＰ（ノードＢ（Node B）のアプリケーション部）およびＲＮＳＡＰ（無線ネットワークサブシステム（Radio Network Subsystem）のアプリケーション部）のようなアプリケーションプロトコルでは、後方互換性を有する拡張メカニズムが、明瞭に規定されている。すなわち、メッセージ（アプリケーションプロトコルでは、フレームはメッセージと呼ばれる）が、以前の規定により、受信用ノードで適切に解釈ができるようにするために、各々の上記規定は、新規ＩＥを含む方法を明確にしている。

したがって、本発明では、フレームプロトコルにおいて、後方互換性のある拡張メカニズムを確保（すなわち、より明瞭に規定）することを提案する。

上記の処理を行うための予備作業として、データフレーム用ＳＥフィールドの最大サイズを処理する。規定されているように、データフレーム内のＳＥフィールドの最大サイズは２オクテットにすぎないのに対して、制御フレームの最大サイズは３２オクテットである。本発明は、データフレーム内のＳＥフィールドを２オクテットよりも大きく拡張することを提案する。本明細書での説明では、３２オクテットは、データフレームのＳＥ長として想定されているが、このＳＥ長は、制御フレームにおけるＳＥフィールドと同じ長さである。しかし、本発明において、ＳＥ長は、別の長さをも包含するものである。

次に図６を参照してわかるように、本発明は、ヘッダ部のいわゆるスペアビットセクション、すなわちスペアビット番号３を使用して、ヘッダ部内のＲｅｌ-９９のデータフレーム内にＳＥＦ（１ビットフラグ）を含ませることを提案する。ＳＥＦ（１ビットフラグ）の規定は、本発明では以下のように行うことが好ましい。
〔スペア拡張フラグ（ＳＥＦ）〕
［説明］スペア拡張部が使用中か否かを示すフラグから成る。
［値の範囲］
０：スペア拡張部は使用中ではない。
１：スペア拡張部、ＩＥがさらなるＩＥを含む。
［フィールド長］１ビット。

本発明に基づく上記ＳＥＦ（１ビットフラグ）によって、受信用ノードは、いくつかの（１以上の）新規ＩＥがスペア拡張フィールドにおいて規定されているか否かを理解することができる。上記ＳＥＦ（１ビットフラグ）がセット（すなわち“１”の値、またはＳＥフィールドがさらなるＩＥを含むことを示す別の所定値にセット）される場合、「新規ＩＥフラグ」のＩＥのビットに続くＳＥフィールドのビット内で、どの情報が有効であるかを示すために、「新規ＩＥフラグ」のＩＥがＳＥフィールドの開始部（または、現在の開始部分）にセットされる。「新規ＩＥフラグ」のＩＥのサイズは、３ＧＰＰでの規定に依存して、例えば１オクテットまたは２オクテットにすることができる。

リリース版として規定され、その後フリーズされたセル・ポーションＩＤとして示される５ビットのＩＥの場合に適用できる「新規ＩＥフラグ」として、提案するサンプルの規定は以下とする。セル・ポーションＩＤは、導入された第１のＩＥであり、このため、本発明により、ＳＥの中で存在するＩＥとして常に第１に（好適に）出現するであろう。また、今後どんなに多くのＩＥが追加されようとも、また今後追加されるＩＥのリリース版が第１として意図されるとも関りなく、「新規ＩＥフラグ」のＩＥに関して、提案するサンプルの規定は以下とする。
〔新規ＩＥフラグのＩＥ〕
［説明］：ＳＥフィールドの後続ビットにおいて、どの情報が有効なものであるかを示すフラグから成る。
［値の範囲］：
ビット０：下位フィールドの第１バイト内のビット０〜５が、有効なセル・ポーションＩＤを含む（１の値で表示）、含まない（０の値で表示）か、を示す。
ビット１〜１５：０にセット（将来使用するために予約）。受信用ノードは、表示されるどのフラグも無視する（セル・ポーションＩＤのＩＥが導入されるリリース版から、受信用ノードは使用する）。
［フィールド長］：１６ビット

「セル・ポーションＩＤ」のＩＥの実例となる規定は、以下である。
〔セル・ポーションＩＤ［周波数分割二重化（ＦＤＤ）］〕
［説明］：セル・ポーションＩＤは、ＲＡＣＨアクセス中に最大ＳＩＲを有するセルの部分を示す。セル・ポーションＩＤは、運用と保守によって構成される。
［値の範囲］：｛０〜６３｝
［フィールド長］：６ビット
上述したように、図６に図示するセル・ポーションＩＤのＩＥは、本発明に基づき、ＳＥフィールドを介して追加される新規ＩＥの１の実施例である（すなわち、ＳＥにおける新規ＩＥの存在を、新規ＩＥフラグのＩＥに示させるようにするためである。ならびに、いくつかの実施例では、上述のようなＳＥＦによってＳＥにおける新規ＩＥの存在を第１に示し、上記ＳＥＦは、特別にセル・ポーションＩＤのＩＥを示すものではなく、むしろＳＥが少なくとも１の追加ＩＥを含むことを示すものである）。送信ノードの方法例は、（３ＧＰＰによって）ＳＥに追加されるＩＥ（の値）を、データフレームのＳＥの形で提供する。本発明によれば、３ＧＰＰがさらなるＩＥを追加する場合、このような後方で追加されるＩＥは、セル・ポーションＩＤのＩＥの後で追加されることが好適である。そして、新規ＩＥフラグのＩＥフラグは、後方で追加されるＩＥに対応することになり、送信用ノードが、ＳＥ内の対応するＩＥの値を実際に提供するかしないかに応じて、このフラグは、セットされたり、されなかったりする。

図６は、スペア拡張フィールドで１のＲｅｌ-６のＩＥを追加する方法の一つの実施例を示す図である。この例では、「新規ＩＥフラグ」のＩＥのビット番号０を使用して、「新規ＩＥフラグ」のＩＥの後の第１のＩＥが有効データを含むか否かが示される。セル・ポーションＩＤのＩＥ（図７に図示のイグザンプルのＩＥ）を追加した後に、別のＩＥが追加されたとき、新規ＩＥフラグのＩＥ内のビット番号１は、例えば、第２のＩＥ（図７のイグザンプルのＩＥ）が有効であるか否かを示す。すなわち、送信用ノードが第２の追加ＩＥの実際のデータを送信したか否かを示すことになる。新規ＩＥフラグのＩＥのフラグによって参照されるＩＥは、ＳＥフィールドに適合するものである限り、任意の長さのものでよいことに留意されたい。すなわち、このようなＩＥは必ずしもオクテットである必要はない。新規ＩＥフラグのＩＥのフラグはオクテットに対応する必要はなく、代わりに、それぞれのＩＥに対応することができる。各々のＩＥは、１ビットほどの小ささ、あるいは、数オクテットほどの長さのものでも可能である。

図６の例では、「新規ＩＥフラグ」のＩＥは、固定サイズのＳＥフィールドを介して追加されたＩＥの有効性を示す。このような方法では、ＩＥが含まれている場合、別のどのようなＩＥの存在にも関りなく、常にデータフレーム内の同じ位置にＩＥを置くことが可能となる（何故なら、新規ＩＥフラグのＩＥは、ＳＥフィールドのどのような部分がブランクであるかを示すことができ、すなわちＩＥを搬送していないことになるからである）。したがって、本発明で提供する上記方法によるプロトコルは、容易に実行することができる。この方法の欠点は、新規ＩＥフラグのＩＥは、ＳＥの部分（すなわち、それぞれのＩＥを搬送する部分）の有効性のみを示すこととなり、無効なＩＥビットの空間（すなわち、追加するＩＥを搬送するのに、送信用ノードによって使用されないビット）が無駄になることである。この欠点を解決するために、「新規ＩＥフラグ」のＩＥは、有効データを有するＩＥのみを提供するＳＥの中で、ＩＥの実際のデータがＳＥに含まれているか否かを示すのに使用することができる。したがって、例えば、送信用ノードが、ＳＥ内で存在する可能性がある１バイト長のＩＥからなる５バイトの中から、１バイト長のＩＥ（すなわち、ＳＥが有効データを提供できる対象となるＩＥ）からなる３バイトに対応する３つの機能をサポートすれば、（別の方式の場合のように）新規ＩＥフラグのＩＥのそれぞれのフラグがセットされることになる。こうして、無効データを搬送するＩＥのビット空間を提供する代わりに、送信用ノードは、有効データを含むものとして新規ＩＥフラグのＩＥによって示されるＩＥのビットのみを持つＳＥを提供することになり、このため、ＳＥの長さで２バイトが節減され、したがってデータフレームの長さで２バイトが節減される。

図７と図８とは、本発明により、提供されるプロトコルが各種リリースの規定と共に機能する方法を示す図である。これらの図に例示されていることは、セル・ポーションＩＤと呼ばれるＩＥが、Ｒｅｌ-６内のフレームに追加されて、この時点でフリーズされることである。次いで、旧バージョンのリリースの規定に関する問題点を訂正するために、イグザンプルＩＥと呼ばれるＩＥは、ＳＥフィールドを介して追加される。このようなシナリオでは、旧バージョンのリリースの規定に従って実行されるいずれのノードも、セル・ポーションＩＤと呼ばれるＩＥ、および新規ＩＥフラグのＩＥのビット番号０とを無視することになる。すなわち、ノードのような新規ＩＥフラグのＩＥのビット番号０は、セル・ポーションＩＤのＩＥと新規ＩＥフラグのＩＥのビット番号０とを、スペアビットとして処理することになる（受信用ノードは、新規ＩＥフラグのＩＥのビット番号０をスペアビットとみなすが、将来リリースされるフラグについては、識別するべきである）。したがって、本発明は、新規ＩＥフラグのＩＥを用いて、後方互換性のあるＩＥをフレームに追加することができる。

図７は、本発明に基づくＲｅｌ-６の規定におけるＲＡＣＨデータフレームを示す図である。この場合、セル・ポーションＩＤのＩＥとイグザンプルＩＥとの存在を示すために、新規ＩＥフラグのビット番号０と新規ＩＥフラグのＩＥのビット番号１とが、セット（１にセット）される。そして、このセットが、Ｒｅｌ-６に関するセル・ポーションＩＤのＩＥと「イグザンプルＩＥ」との理解（読み込みと解釈）を、受信用ノードに実行させることになる。これとは対照的に、図８は、Ｒｅｌ-９９の規定におけるＲＡＣＨデータフレームを示す図である。この場合、新規ＩＥフラグのＩＥのビット番号０は、本発明に基づいて常に０となる（ように提案する）。すなわち、任意の規定におけるスペアビットとしてマークするように提案する。そして、この新規ＩＥフラグのＩＥのビット番号０は、フレームプロトコルの規定において、上記のように指定されることになる（というのは、新規ＩＥフラグのＩＥのビット番号０に対応するＳＥフィールドのＩＥは、専ら将来のリリース用としてのみ使用されるものであるからである）。また、「イグザンプルＩＥ」の有効性を示すために、Ｒｅｌ-９９では新規ＩＥフラグのＩＥのビット番号１は、１にセットされる（ように提案する）。Ｒｅｌ-９９における新規ＩＥフラグのＩＥの例示の規定は以下のようになる。
〔新規ＩＥフラグ〕
［説明］：後続するビットの中でどの情報が有効であるかを示すフラグから成る。
［値の範囲］：
ビット０：予約済み。このビットは送信機によって０にセットされ、受信装置によって無視されることになる。
ビット１：後続する新規ＩＥフラグのＩＥの第２バイトが、有効なイグザンプルＩＥ（有効なイグザンプルを示す場合は値１、否の場合は値０）を含むか否かを示す。
ビット２〜１５： ０にセット。このユーザプレーン改訂時に予約される。示されるいずれのフラグも受信機によって無視される。
［フィールド長］：１６ビット。

この例では、受信用ノードがＲｅｌ-６のノードである場合、受信用ノードは、ビット番号０の値に基づいて、新規ＩＥフラグのＩＥのビット番号０ならびにビット番号１の双方を理解することが可能である。ビット番号１に基づいて、セル・ポーションＩＤのＩＥと「イグザンプルＩＥ」のＩＥとを解釈することが可能である。受信用ノードがＲｅｌ-９９である場合、受信用ノードはビット番号０と第１オクテットとを無視することになり、「イグザンプルＩＥ」のデータフレーム内にＩＥが存在しているか否かを判定するために、ビット番号１のみを使用することになる。ＩＥが存在していれば、受信用ノードはＩＥの値の読み込みを試みることになる。

送信用ノードは、送信用ノードが実行するときに準拠した規定に基づいて、および送信用ノードが何のＩＥをデータフレームで搬送しているかに基づいて、新規ＩＥフラグのＩＥのフラグのみをセットする（または、セットしない）。上記の例では、Ｒｅｌ-６の送信用ノードは、（送信用ノードがデータフレームの中に対応するＩＥを含んでいるか否かに応じて）、新規ＩＥフラグのＩＥのビット番号０と番号１との値をセットする（あるいはセットしない）。一方、Ｒｅｌ-９９の送信用ノードは、新規ＩＥフラグのＩＥのビット番号０の値と、ＳＥフィールドの第１バイト（あるいは、この第１のＩＥに対応するビット数がどんなに大きなビットであっても）とを、常に“０”にセットし、新規ＩＥフラグのＩＥのビット番号１の値のみをセットする（あるいはセットしない）。さらにまた、イグザンプルＩＥ（図示のような第２番目のバイト）のビット値に、適切な値を適宜セットする。

ＳＥフィールドを用いる別の代替例として、図９に図示のようにＳＥフィールドの第１のバイトの中に「ＳＥ長」のＩＥを有するものがある。このような代替例では、ＳＥフィールドのサイズは動的なものにすることができる（すなわち、ＳＥのサイズをあらかじめ定める必要はない）。このような代替例の場合、新規ＩＥフラグのＩＥおよび対応するＳＥ長は以下のように規定することができる。
〔新規ＩＥフラグ〕
［説明］：後半のビットで、どの情報が有効であるかを示すフラグから成る。
［値の範囲］：
ビット０： 次の第１番目のバイト（ビット０〜５）が有効なセル・ポーションＩＤを含むか否かを示し、含む場合は１にセットし、否の場合は０にセットする。
ビット１〜６：０にセットされる。このユーザプレーン改訂時に予約される。示されるいずれのフラグも受信機によって無視される。
ビット７：現在の新規ＩＥフラグのＩＥに付随するＩＥの後に、別の「新規ＩＥフラグ」のＩＥが規定されているか否かを示す。この値が１であれば、追加の「新規ＩＥフラグ」のＩＥが規定されており、値が１でなければ、現在に付随する新規ＩＥラグのＩＥがデータフレーム内の最後の「新規ＩＥフラグ」のＩＥとなる。
［フィールド長］：８ビット
〔ＳＥ長〕
［説明］：このフィールドの後に後続する拡張部分のバイトでの長さを示し、この長さには、「新規ＩＥフラグ」のＩＥの長さが含まれる。このようなＩＥは最大で２５５の値を示すことができる。したがって、示された長さの範囲内にある最後の新規ＩＥフラグのＩＥがさらなる新規ＩＥフラグのＩＥを示すときは、ＩＥの次のブロックを示すことになるので、任意のさらなるＳＥ長のＩＥが、次の「新規ＩＥフラグ」のＩＥの前に存在することがある。
［値の範囲］：１〜２５５
［フィールド長］：８ビット

図９に図示するように、ＳＥＦ（１ビットフラグ）と新規ＩＥフラグのＩＥとが、そのままデータフレームにおいても規定されるが、この代替例では、上記新規ＩＥフラグのＩＥは拡張メカニズムを有することになる（すなわち、個々の新規ＩＥフラグのＩＥの最終ビットは、新規ＩＥフラグのＩＥおよび対応するＳＥサブセクションの次のブロックが存在しているか否かを示すことになる）。

第１のＳＥ長のＩＥがどこで規定されるかに応じて、別のシナリオの存在も可能である。上記ＳＥ長は、ヘッダ部で規定されていれば、ＳＥＦ（１ビットフラグ）を置き換えることが可能である。図１０はこの例を示す図である。この図では、第１番目のＳＥ長は、ヘッダ部に規定されている。第１番目のＳＥ長が“０”であれば、スペア拡張部はゼロの長さのものとなる。しかし、いずれかの新規ＩＥに等しい長さがＳＥに含まれている限り、本発明に基づくＳＥ長はＳＥの長さを示すように提案されることになる。ＳＥの第１番目のオクテットは、「新規ＩＥフラグ」のＩＥになる。ＳＥ長の拡張と新規ＩＥフラグとのメカニズムは、上記と同じである。図１０において、１バイトのＳＥ長をヘッダの中で提案しているが、この長さは８ビットよりも短くして、第１番目のＳＥ長は、現在指定しているフレーム内のスペアビットセクションに適合させることもできる。図１１は、このような例を示す図である。この例のような場合（スペアビットセクションのＳＥ長）において、「ＳＥ長」のＩＥの規定を適宜変更する必要がある。すなわち、長さと値の範囲との双方を変更して、より短い所望の長さに対応することができる。

ヘッダ内の１バイトのＳＥ長フィールドの追加は、「ＳＥ長」のＩＥの規定を簡単なものにする。しかし、Ｒｅｌ-９９の規定における１バイトの「ＳＥ長」のＩＥの追加は後方互換性がないのに対して、ヘッダ内のさらに短い第１番目の「ＳＥ長」のＩＥの追加は後方互換性を有するけれども、「ＳＥ長」のＩＥの規定を困難なものにする。

本発明および上述の事項により、導入された順序に従って、好適にＩＥがＳＥの中に含まれるということを理解することが重要である。すなわち、３ＧＰＰがフリーズしたリリースに関連する第１の新規ＩＥを導入し、その後にフリーズされたリリース版（任意のフリーズされたリリース版）の規定に関連する別のＩＥを導入する場合、ＳＥに存在する第１のＩＥは、第１に導入されるＩＥとなり、ＳＥに存在する第２のＩＥは、第２に導入されるＩＥとなる。また、上述したように、ＳＥ内の新規のＩＥは、新規のＩＥが導入されるリリース版よりも以前にフリーズされたリリース版が実装されている受信用ノードによって、スペアビットとして処理される。

新規ＩＥフラグのＩＥの使用を含むように、以上では本発明について説明してきたが、本発明は、このようなＩＥの使用に依拠しないフレームプロトコルも包含するものである。図１を再度参照すると、本発明は、一般に通信システムの送信用ノード１１と受信用ノード１２との間での情報の送信時に使用するフレームプロトコルを包含するものである（この場合、ノード１１、１２は、任意の規定のおそらく異なるリリース版によって実行されるものであり、上記情報はフレーム１０に編成されて通信される。上記フレームプロトコルは、１以上のＩＥフィールド（リリース '９９以降にリリースされる任意のリリース版が、使用するのに導入されるＩＥフィールド）の値を搬送するＳＥセクションを内部に含むフレーム１０を、送信用ノード１１が受信用ノード１２へ送信するステップを含む。そして上記フレームプロトコルは、ＩＥフィールドに、受信用ノード１２に実装されている規定のリリース版よりも、時間的に後でフリーズされたリリース版が導入されたとき、受信用ノード１２がＳＥセクション内に存在するＩＥフィールド値をスペアビットとして処理するためのものである。）すなわち、受信用ノード１２に実装されている規定のリリース版よりも、後でリリースされる任意のバージョンがＩＥフィールドに導入されたとき、受信用ノード１２は、ＳＥセクション内に存在するＩＥフィールドの値をスペアビットとして処理する。

実施形態において、ＩＥフィールドが有効データを含むか否かに関りなく、ＳＥセクション内の個々のＩＥフィールドが、ＳＥセクションにおける所定の固定位置を有するものもある。また、実施形態においてＩＥが導入された順序で、ＳＥセクション内のＩＥが含まれるものもある。さらにまた、実施形態において、受信用ノードがＳＥセクション内のＩＥ用ビットをスペアビットとして処理すべきか否かを判定することを可能にするために、本発明は、新規ＩＥフラグのＩＥを使用する代替例として、ＳＥセクションの中で存在する個々のＩＥが、ビット空間内の値が有効となるときを示す予約値を有することも規定している。

上述の配置構成は本発明の原理の適用例にすぎないことを理解されたい。当業者が、本発明の範囲から逸脱することなく、多数の変更と代替の配置構成を考案することも可能であり、添付の請求項はこのような変更と、配置構成とをカバーすることを意図するものである。

本発明による受信用ノードへフレームを送信する無線通信システムの送信用ノードのブロック／フローを示す図である。 一般的なフレーム構造を示す概略図である。 スペア拡張部内に新規Ｒｅｌ-６のＩＥを追加した後の一般的なフレーム構造を示す概略図である。 “Ｒｅｌ-５のＩＥを追加する場所は？”の問題を説明するための一般的なフレーム構造を示す概略図である。 ２５.４２５における現在のＲＡＣＨデータフレーム構造を示す概略図である。 ２５.４３５における現在のＲＡＣＨデータフレーム構造を示す概略図である。 本発明による２５.４２５におけるＲＡＣＨフレーム構造を示す概略図である。 Ｒｅｌ-６の２５.４２５における例示的ＲＡＣＨフレーム構造を示す概略図である。 Ｒｅｌ-９９の２５.４２５における例示的ＲＡＣＨフレーム構造を示す概略図である。 ＳＥ内にＳＥ長フィールドを含む例示的ＲＡＣＨフレーム構造を示す概略図である。 ヘッダ内に８ビット長のＳＥ長フィールドを有する例示的ＲＡＣＨフレーム構造を示す概略図である。 ８ビット未満のＳＥ長フィールドを有し、ヘッダのスペアビットセクションに位置するような例示的ＲＡＣＨフレーム構造を示す概略図である。

Claims (39)

1. 通信システムの送信用ノード（１１）と受信用ノード（１２）との間で、フレーム（１０）に編成される情報を通信する際に使用するフレームプロトコルであって、前記フレーム（１０）内に１以上の情報要素（ＩＥ）フィールドの値を搬送するスペア拡張（ＳＥ）セクションを含む前記フレーム（１０）を、前記送信用ノード（１１）が前記受信用ノード（１２）に送信するステップを備えるフレームプロトコルにおいて、新規ＩＥフラグのＩＥの個々のフラグを介して、前記ＳＥセクションが１以上の各々のＩＥの有効データを前記ＳＥセクション内に含むか否かを、前記受信用ノード（１２）に対して示すような前記新規ＩＥフラグのＩＥを前記フレーム（１０）が含むことを特徴とするフレームプロトコル。
2. 前記新規ＩＥフラグのＩＥのビット位置と、前記ＳＥセクション内に存在する１以上のビットからなる各々のセットの位置との間での所定の対応関係に基づき、前記新規ＩＥフラグのＩＥは、前記ＳＥセクションが１以上の各々のＩＥの有効データを含むか否かを示す請求項１に記載のフレームプロトコル。
3. 前記ＳＥセクションが１以上のＩＥの有効データを含むか否かを示すために、前記フレーム（１０）が、前記フレーム（１０）のヘッダのスペアビット部内にＳＥフラグのＩＥを含む請求項１に記載のフレームプロトコル。
4. 前記フレーム（１０）は、少なくとも第１のＳＥ長のＩＥ、ならびに、第１の新規ＩＥフラグのＩＥと第１のＳＥサブセクションとを含む少なくとも第１のブロックを含み、前記第１のＳＥ長のＩＥは、前記第１のブロックの長さを示す請求項１に記載のフレームプロトコル。
5. 前記第１のブロックは、複数の連続する対の新規ＩＥフラグのＩＥと、追加するＩＥを提供するために対応するＳＥサブセクションとを含み、前記第１のブロック内の個々の新規ＩＥフラグのＩＥのビットは、前記第１のブロックの一部としてフレーム（１０）内に次の対が含まれるか否かを示す請求項４に記載のフレームプロトコル。
6. 前記第１の新規ＩＥフラグのＩＥの直前の１以上のビットとして、前記少なくとも第１のＳＥ長のＩＥが含まれる請求項４に記載のフレームプロトコル。
7. 前記フレーム（１０）は、複数の連続するＳＥ長のＩＥ、ならびに、新規ＩＥフラグのＩＥとＳＥサブセクションとからなる対応するブロックを含む請求項４に記載のフレームプロトコル。
8. 前記フレーム（１０）は、新規ＩＥフラグのＩＥと対応するスペア拡張サブセクションとを、個々に順番に含む複数のブロックを含み、個々のブロック内の個々の新規ＩＥフラグのＩＥのビットは、前記ブロックの一部として前記フレーム（１０）内に次の対が含まれるか否かを示す請求項１に記載のフレームプロトコル。
9. 前記ＳＥセクションが１以上のＩＥの有効データを含むか否かを示すために、さらに、有効データを含むときは前記ＳＥセクションの長さを示すために、前記フレーム（１０）は、前記フレーム（１０）のヘッダ内にＳＥ長のＩＥを含む請求項１に記載のフレームプロトコル。
10. 前記ＳＥ長のＩＥが示す長さは、前記ＳＥセクションの長さに、付随する新規ＩＥフラグのＩＥの長さを加えた長さになる請求項９に記載のフレームプロトコル。
11. 前記ＳＥ長のＩＥは、前記フレーム（１０）のヘッダのスペアビット部に含まれる請求項９に記載のフレームプロトコル。
12. 前記ＩＥを導入する順に、前記ＳＥセクション内の前記ＩＥを含む請求項１に記載のフレームプロトコル。
13. 前記受信用ノード（１２）に実装されている規定のリリース版よりも、時間的に後でフリーズされた規定のリリース版が前記ＩＥフィールドに導入されたとき、前記ＳＥセクション内に存在するＩＥと前記新規ＩＥフラグのＩＥ内の対応するビットとが、前記受信用ノード（１２）によってスペアビットとして処理される請求項１に記載のフレームプロトコル。
14. 前記フレーム（１０）は、有効データを有するものとして、前記新規ＩＥフラグのＩＥによって示されるＩＥのビットのみを前記ＳＥ内に含む請求項１に記載のフレームプロトコル。
15. 通信システムの送信用ノード（１１）と受信用ノード（１２）との間で、フレーム（１０）に編成される情報を通信する際に使用するフレームプロトコルに従って動作する装置であって、１以上の情報要素（ＩＥ）フィールドの値を搬送するスペア拡張（ＳＥ）セクションを含む前記フレーム（１０）と共に、前記フレーム（１０）を送信する手段を具備する装置において、新規ＩＥフラグのＩＥの個々のフラグを介して、前記ＳＥセクションが１以上の各々のＩＥの有効データを前記ＳＥセクション内に含むか否かを、前記受信用ノード（１２）に対して示すような前記新規ＩＥフラグのＩＥを、前記フレーム（１０）の一部として提供することを特徴とする装置。
16. 前記新規ＩＥフラグのＩＥのビット位置と、前記ＳＥセクション内に存在する１以上のビットからなる各々のセットの位置との間での所定の対応関係に基づき、前記ＳＥセクションが１以上の各々のＩＥの有効データを含むか否かを示すために、前記新規ＩＥフラグのＩＥのフラグをセットする請求項１５に記載の装置。
17. 前記ＳＥセクションが１以上のＩＥの有効データを含むか否かを示すために、前記フレーム（１０）において、前記フレーム（１０）内のヘッダのスペアビット部にＳＥフラグのＩＥを含み、前記ＳＥフラグのＩＥをセットする請求項１５に記載の装置。
18. 前記フレーム（１０）内に、少なくとも第１のＳＥ長のＩＥ、ならびに、第１の新規ＩＥフラグのＩＥと第１のＳＥサブセクションとを含む第１のブロックを含む装置であって、さらに前記第１のブロックの長さを示すために前記第１のＳＥ長のＩＥの値を提供する請求項１５に記載の装置。
19. 前記第１のブロックが、複数の連続する対の新規ＩＥフラグのＩＥと、追加ＩＥを提供するための対応するＳＥサブセクションとを含むように動作し、さらにまた、前記第１のブロック内の個々の新規ＩＥフラグのＩＥのビットが、前記第１のブロックの一部としてフレーム（１０）内に次の対が含まれるか否かを示すように動作する請求項１８に記載の装置。
20. 前記第１の新規ＩＥフラグのＩＥの直前の１以上のビットとして、少なくとも第１のＳＥ長のＩＥを含むように動作する請求項１８に記載の装置。
21. 前記フレーム（１０）が、複数の連続するＳＥ長のＩＥ、ならびに、新規ＩＥフラグのＩＥとＳＥサブセクションとからなる対応するブロックを含むように動作する請求項１８に記載の装置。
22. 前記フレーム（１０）が、新規ＩＥフラグのＩＥと付随するスペア拡張サブセクションとを個々に順番に含む複数のブロックを含み、個々のブロック内の個々の新規ＩＥフラグのＩＥのビットが、前記ブロックの一部としてフレーム（１０）内に次の対が含まれるか否かを示すように動作する請求項１５に記載の装置。
23. 前記ＳＥセクションが１以上のＩＥの有効データを含むか否かを示すために、そして、有効データを含むときは前記ＳＥセクションの長さを示すために、前記フレーム（１０）は、前記フレーム（１０）のヘッダ内にＳＥ長のＩＥを含むように動作する請求項１５に記載の装置。
24. 前記ＳＥ長のＩＥが示す長さは、前記ＳＥセクションの長さに、付随する新規ＩＥフラグのＩＥの長さを加えた長さになるように動作する請求項２３に記載の装置。
25. 前記ＳＥ長のＩＥを、前記フレーム（１０）のヘッダのスペアビット部内に含むように動作する請求項２３に記載の装置。
26. 前記ＩＥを導入する順に、前記ＳＥセクション内の前記ＩＥを含むように動作する請求項１５に記載の装置。
27. 前記受信用ノード（１２）に実装している規定のリリース版よりも、時間的に後でフリーズされた規定のリリース版がＩＥに導入されたとき、受信されたフレーム（１０）のＳＥセクション内に存在するＩＥと前記新規ＩＥフラグのＩＥ内の付随するビットとが、スペアビットとして処理するように動作する請求項１５に記載の装置。
28. 前記フレーム（１０）は、有効データを有するものとして、前記新規ＩＥフラグのＩＥによって示されるＩＥのビットのみを前記ＳＥ内に含むように動作する請求項１５に記載の装置。
29. 送信用ノード（１１）と受信用ノード（１２）とを具備し、前記送信用ノード（１１）が請求項１５に記載の装置を備えたシステム。
30. 前記受信用ノード（１２）に実装している規定のリリース版よりも、時間的に後でフリーズされた規定のリリース版がＩＥに導入されたとき、受信されたフレーム（１０）の前記ＳＥセクション内に存在する前記ＩＥを、スペアビットとして処理するように前記受信用ノード（１２）が動作する請求項２９に記載のシステム。
31. コンピュータプログラム製品であって、通信端末装置またはノード（１１、１２）において、コンピュータ・プロセッサによって実行されるコンピュータプログラムコードを、具現化するコンピュータによる読み取り可能な格納構造を有するコンピュータプログラム製品において、前記コンピュータプログラムコードを用いて、前記通信端末装置またはノード（１１、１２）を、請求項１〜１４に記載のいずれかの前記プロトコルに従って動作させる命令を含むことを特徴とするコンピュータプログラム製品。
32. 通信システムの送信用ノード（１１）と受信用ノード（１２）との間で、フレーム（１０）内に編成される情報を通信する際に使用するフレームプロトコルであって、前記フレーム（１０）内に１以上の情報要素（ＩＥ）フィールドの値を搬送するスペア拡張（ＳＥ）セクションを含む前記フレーム（１０）を、前記送信用ノード（１１）が前記受信用ノード（１２）に送信するステップを備えるフレームプロトコルにおいて、前記受信用ノード（１２）に実装している規定のリリース版よりも、時間的に後でフリーズされた規定のリリース版がＩＥフィールドに導入されたとき、前記受信用ノード（１２）は前記ＳＥセクション内に存在する前記ＩＥフィールドの値をスペアビットとして処理することを特徴とするフレームプロトコル。
33. 前記ＩＥフィールドが有効データを含むか否かにかかわらず、前記ＳＥセクション内の個々のＩＥフィールドは、所定の固定位置を前記ＳＥセクション内に有する請求項３２に記載のフレームプロトコル。
34. 前記ＩＥを導入する順に、前記ＳＥセクション内の前記ＩＥを含む請求項３２に記載の装置。
35. 前記ＳＥセクション内に存在するＩＥが、ビット空間内の値が有効でなくなるときを示す予約値を有する請求項３２に記載のフレームプロトコル。
36. 請求項３２〜３５のいずれかに記載のフレームプロトコルに従って動作する装置。
37. 送信用ノード（１１）と受信用ノード（１２）とを具備するシステムであって、前記送信用ノード（１１）が請求項３６に記載の装置を備えるシステム。
38. 前記受信用ノード（１２）に実装している規定のリリース版よりも、時間的に後でフリーズされた規定のリリース版がＩＥに導入されたとき、受信されたフレーム（１０）の前記ＳＥセクション内に存在するＩＥを、スペアビットとして処理するように前記受信用ノード（１２）が動作する請求項３７に記載のシステム。
39. コンピュータプログラム製品であって、通信端末装置またはノード（１１、１２）において、コンピュータ・プロセッサによって実行されるコンピュータプログラムコードを具現化するコンピュータによる読み取り可能な格納構造を有するコンピュータプログラム製品において、前記コンピュータプログラムコードを用いて、請求項３２〜３５のいずれかに記載の前記プロトコルに従って前記通信端末装置またはノード（１１、１２）を動作させる命令を含むことを特徴とするコンピュータプログラム製品。

Images