ＲＲＣ（ｒａｄｉｏｒｅｓｏｕｒｃｅｃｏｎｔｒｏｌ）−サービスデータユニットの受信
【課題】ＵＭＴＳ ＴＤＤまたはＦＤＤシステムにおいて、システム機能の適正なパフォーマンスを維持するためには、欠陥のあった伝送を補完するため、ＳＩＢの繰り返しレートを増加させねばならない場合、無線資源の効率と利便性が低下する。
【解決手段】情報セグメントよりなる情報セグメントの周期的な伝送を含む通信を受信し（８０）処理する方法である。情報セグメントセットの第１回目の伝送を受信し処理し、各情報セグメントが有効か無効かを判断する（８１）。有効と判断した情報セグメントをストアする（８２）。当該情報セグメントセットの全ての情報セグメントがストアされなかった場合に（８３）、その後の情報セグメントセットの伝送を受信し（８５）、以前ストアされなかった情報セグメントに対応する情報セグメントのみを処理して有効か無効かを判断する。有効と判断した情報セグメントをストアする（８２）。当該情報セグメントセットの全ての情報セグメントがストアされるまで、その後の伝送を繰り返し受信する（８５）。
【解決手段】情報セグメントよりなる情報セグメントの周期的な伝送を含む通信を受信し（８０）処理する方法である。情報セグメントセットの第１回目の伝送を受信し処理し、各情報セグメントが有効か無効かを判断する（８１）。有効と判断した情報セグメントをストアする（８２）。当該情報セグメントセットの全ての情報セグメントがストアされなかった場合に（８３）、その後の情報セグメントセットの伝送を受信し（８５）、以前ストアされなかった情報セグメントに対応する情報セグメントのみを処理して有効か無効かを判断する。有効と判断した情報セグメントをストアする（８２）。当該情報セグメントセットの全ての情報セグメントがストアされるまで、その後の伝送を繰り返し受信する（８５）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＭＴＳ（Universal Mobile Telecommunications Systems）に関する。
【背景技術】
【０００２】
ＵＭＴＳネットワークアーキテクチャは、図１に示すように、コアネットワーク（ＣＮ）２と、ＵＴＲＡＮ（ＵＭＴＳ Terrestrial Radio Access Network ）３と、少なくとも１つのＵＥ（User Equipment）１８（図を簡略にするため、図には１つのＵＥ１８のみを図示した）とを含む。２つの一般的なインタフェースは、ＵＴＲＡＮとコアネットワークの間のＩｕインタフェースであり、同様に、ＵＴＲＡＮとＵＥの間の無線インタフェースＵｕである。
【０００３】
ＵＴＲＡＮは幾つかのＲＮＳ（Radio Network Subsystem）１０、１１よりなる。これらＲＮＳを、Ｉｕｒインタフェースによって相互に接続することができる。ＲＮＳ１０、１１は、それぞれ、ＲＮＣ（Radio Network Controller）１２、１３と、幾つかの基地局（Ｎｏｄｅ Ｂ）１４−１７ とに分割されている。基地局１４−１７はＩｕｂインタフェースによりＲＮＣ１２、１３に接続されている。１つの基地局１４−１７は１または複数のセル（cell）をサーブすることができる。
【０００４】
ＵＴＲＡＮ３は無線インタフェースにおいてＦＤＤモードとＴＤＤモードの両方をサポートする。これら両方のモードに対して、同一のネットワークアーキテクチャと同一のプロトコルが用いられている。
【０００５】
基地局１４−１７とＵＥ１８の間において無線インタフェースＵｕを介して行う通信は、無線インタフェースプロトコルを用いて行われる。無線インタフェースプロトコルスタックアーキテクチャが図２に示してある。当業者にとって当然のことであるが、無線インタフェースプロトコルスタック２０のデザイン（design）は、３つのレイヤー、すなわち、物理レイヤー（Ｌ１）２１と、データリンクレイヤー（Ｌ２）２２と、ネットワークレイヤー（Ｌ３）２３とに分割されている。データリンクレイヤー（Ｌ２）２２は、４つのサブレイヤー、すなわち、ＭＡＣ（media access control）２４と、ＲＬＣ（Radio Link Control）２５と、ＢＭＣ（broadcast/multicast control）２７と、ＰＤＣＰ（packet data convergence protocol）２６とに分けられている。
【０００６】
ネットワークレイヤー（Ｌ３）２３は、ＲＲＣ（radio resource control）２８を含む。このＲＲＣ２８はＵＴＲＡＮ３とＵＥ１８の間のＬ３のコントロールプレーンシグナリング（control plain signaling）を処理する。このＲＲＣ２８は、ＵＴＲＡＮ３における他の全てのプロトコルレイヤーを構成しコントロールすることを担当し、しかも、利用可能な無線資源（radio resource）をコントロールすることを担当する。これには、無線資源を割り当て再構成し解放することが含まれ、同様に、要求されたＱｏＳ（quality of service）を継続してコントロールすることが含まれる。
【０００７】
ＲＬＣレイヤー２５は、トランスペアレントモードか、不確認（unacknowledged）モードか、または確認（acknowledged）モードで、上位レイヤーにデータホワーディングを行う。確認モードでのホワーディングにおいては、選択的拒否−自動再送要求（selective reject-automatic repeat request）を持つスライディングウィンドウプロトコルが用いられる。
【０００８】
ＭＡＣレイヤー２４は、ＲＬＣ２５の論理チャンネルを、物理レイヤーの提供するトランスポートチャンネルに、マッピングする。ＭＡＣレイヤー２４は、主に、マルチプレクシング機能よりなるが、ＭＡＣレイヤー２４には、ＲＲＣ２８により資源配分についての情報が通知される。ＭＡＣレイヤー２４により、同一物理資源にマッピングされた異なるデータフロー間の優先処理が行われる。ＢＭＣ２７とＰＤＣＰ２６の機能とオペレーションについては、当業者に周知であるから、ここではこれ以上説明しない。
【０００９】
物理レイヤー２１は、エアーインタフェース（air interface）を介してトランスポートブロックを伝送することを担当する。この中には、前方誤り訂正（forward error correction）、同一物理資源上への異なるトランスポートチャンネルの多重化、レートマッチング（すなわち、使用可能な物理資源にユーザデータの量を適合させること）、変調、拡散、およびＲＦ（radio frequency）処理が含まれる。エラー検出も、物理レイヤー２１により行われ、上位のレイヤーである、データリンクレイヤー２２、ネットワークレイヤー２３に表示される。
【００１０】
図３はデータリンクレイヤー（Ｌ２）２２のデータフロー全体を示す。上位レイヤーＰＤＵ（protocol data unit）はＲＬＣレイヤー２５に渡される。ＲＬＣレイヤー２５において、ＳＤＵ（service data unit）はセグメントにセグメンテーション（segmentation）されコンカチネート（concatenate）される。ＲＬＣヘッダが付加され、ＲＬＣＰＤＵが構成される。ＲＬＣレイヤー２５においては、エラー検出符号は付加されない。トランスペアレントモードＲＬＣにあっては、ＲＬＣレイヤー２５において、セグメンテーションは行われず、上位レイヤーのＰＤＵにＲＬＣヘッダやＭＡＣヘッダは付加されない。
【００１１】
ＭＡＣレイヤー２４においては、ヘッダが付加されるだけである。このヘッダには、論理チャンネルをトランスポートチャンネルにマッピングすることを記述するルーチング情報を含めることができる。また、共通チャンネル上にＵＥ識別情報を含めることができる。
【００１２】
物理レイヤー（Ｌ１）２１において、エラー検出のためにＣＲＣが付加される。レシーバにおけるＣＲＣチェックのリザルト（result）は、再送コントロールのため、ＲＬＣレイヤーに渡される。
【００１３】
現行のＵＭＴＳ ＴＤＤまたはＦＤＤシステムにおいては、ＲＲＣ−ＳＤＵ（radio resource control service data unit）を、ＲＬＣトランスペアレントモードか、不確認モードか、または確認モードで、ＵＴＲＡＮ−ＲＲＣとＵＥ−ＲＲＣとの間で送信することができる。確認モードについては説明しない。しかし、ＲＲＣ−ＳＤＵが、トランスペアレントモードまたは不確認モードでトランスポートされる場合には、受信側のＲＬＣレイヤーとＭＡＣレイヤーは、ＲＲＣ−ＳＤＵに気付かない。そこで、受信されたＲＲＣ−ＳＤＵであって、伝送中でのエラーまたは他のソースに起因するエラーは、下位レイヤーではなく、ＲＲＣレイヤーにおいて、処理されねばならない。
【００１４】
ＲＲＣ−ＳＤＵは、ＴＢ（transport block）として知られる幾つかの個々のセグメントに入れて伝送することができる。ＲＲＣ−ＳＤＵの一例はＢＣＣＨ−ＳＩＢ）broadcast control channel system information block）である。
【００１５】
ＢＣＣＨ−ＳＩＢの場合には、このＳＩＢに関連付けられたＴＢが、ＵＴＲＡＮ−ＲＲＣからＵＥ−ＢＣＦＥ（UE broadcast control functional entity）へ、繰り返し伝送される。ＳＤＵバージョンの指標は「ＶＡＬＵＥタグ」により識別される。ＶＡＬＵＥタグに変化がないときは、ＵＥ１８は、ＵＴＲＡＮが繰り返し同一のＢＣＣＨ−ＳＩＢを送信していると仮定する。仮にＵＴＲＡＮ３から伝送されるＢＣＣＨ−ＳＩＢに変化がある場合には、そのＵＴＲＡＮ３は、変化があったことを、ＶＡＬＵＥタグを用いて、ＵＥ１８に示す。スケジューリング情報、すなわちＢＣＣＨ−ＳＩＢのＴＢがいつＵＥ１８に到達するかの情報と、ＢＣＣＨ−ＳＩＢのバージョンとが、ＵＴＲＡＮ３からの伝送に先立って、ＵＥ１８に知らされる。
【００１６】
図４は、Ｌ１のＳＤＵを受信するＵＥ１８を示す。このＳＤＵは、例えば、ＢＣＣＨ−ＳＩＢを持つＴＢと、ＵＥ１８のＬ１により伝送エラー検出を行うために用いられるＣＲＣとを備える。図に示すように、ＴＢはＳＦＮ（system frame number）を含むことができるが、このＳＦＮは、ＢＣＣＨ−ＳＩＢのＴＢでもそうであったが、ＴＢのＵＥ１８への到達タイムを示すものである。あるいはまた、ＴＢがＳＦＮを明示的に含んでいないときは、到達タイムを示すＳＦＮは、Ｌ１により物理レイヤーのタイミングから導き出すことができる。ＵＥ１８のＬ１は、ＴＢと、ＳＦＮと、ＣＲＣとのリザルトを上位のレイヤーに渡す。しかし、ＲＬＣとＭＡＣレイヤー２５、２４が、ＢＣＨ（broadcast channel）データに対してトランスペアレントモードでオペレートするので、このＴＢはＲＲＣレイヤーに渡される。
【００１７】
ＴＢは、ＵＥ１８とＵＴＲＡＮ３の間をフェージング環境で伝送されることが多いので、ＴＢの伝送と、正常送受信の目標確率、例えば９９％とが関連付けされる。仮にＢＣＣＨ−ＳＩＢが多数のＴＢから構成されている場合には、ＢＣＣＨ−ＳＩＢのＴＢを全て正しく受信する確率は、おおよそ０．９９の（ＴＢの数のべき乗）になる。例えば、ＢＣＣＨ（broadcast control channel）のＢＣＣＨ−ＳＩＢは、１０個を超える数のＴＢを伝送する必要がある場合があり、この場合、ＵＥ１８がＢＣＣＨ−ＳＩＢを正しく受信する確率は、０．９９の１０乗、すなわち、９０％未満になる。したがって、ＢＣＣＨ−ＳＩＢを正しく受信できる確率は、ＴＢの数が増加するほど減少する。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
ＵＭＴＳ ＴＤＤまたはＦＤＤシステムにおいて、ＳＩＢを正常に受信するためのタイムによって、多くのシステム機能のパフォーマンスが決定される。加えて、これらのシステム機能の適正なパフォーマンスを維持するためには、欠陥のあった伝送を補完するため、ＳＩＢの繰り返しレートを増加させねばならない場合があるが、そうすると、無線資源の効率と利便性が低下する。
【００１９】
図５と図６は、それぞれ、ＵＴＲＡＮ３によりＵＥ１８に伝送されたＲＲＣ−ＳＤＵを正常に受信するのに使用される現行の方法の例でありフローを示す図である。図に示すように、ＵＥ−ＢＣＦＥはＲＲＣ−ＳＤＵを受信する（ステップ６０）。ここでは、このＲＲＣ−ＳＤＵが９つのＴＢを備え、ＳＦＮ＝２からＳＦＮ＝１８までがラベル付けしてあり、繰り返しレートが６４フレームである。ＵＥ−ＢＣＦＥはＲＲＣ−ＳＤＵを読み取り、ＴＢにエラーがないか、ＲＲＣ−ＳＤＵが紛失していないかを判断する（ステップ６１）。ここでは、ＳＦＮ１０にエラーがあるものとする。受信されたＲＲＣ−ＳＤＵにエラーがあるので、ＵＥ−ＢＣＦＥは全てのＲＲＣ−ＳＤＵを廃棄し、繰り返しレート、すなわち６４フレームだけ待機し、同一の情報を持つ別のＲＲＣ−ＳＤＵを受信する（ステップ６２）。再び、このＵＥ−ＢＣＦＥは、９つのＴＢを備え、ＳＦＮ＝６６からＳＦＮ＝８２までをラベル付けしたＲＲＣ−ＳＤＵを受信し（ステップ６３）、エラーがあるか否かを判断する（ステップ６１）。この例では、ＳＦＮ７０（ＳＦＮ６＋６４（繰り返しレート））は、エラーを有するか、紛失している。仮に受信されたＲＲＣ−ＳＤＵにエラーが発見されない場合には、ＵＥ−ＢＣＦＥはそのＲＲＣ−ＳＤＵを正常に受信したので、そのＲＲＣ−ＳＤＵをデコードする（ステップ６４）。仮にエラーが発見された場合には、この例では、ＵＥ−ＢＣＦＥは、受信したＲＲＣ−ＳＤＵ（９つのＴＢを備えている）全体を廃棄し、繰り返しレートだけ待機し（ステップ６２）、次のＲＲＣ−ＳＤＵを受信する（ステップ６３）。このプロセスは、ＵＥ−ＢＣＦＥが９つのＴＢの連続したものを正常に受信するまで、継続される。
【００２０】
ＵＴＲＡＮからＲＲＣ−ＳＤＵを受信するこの種の方法に関連する領域としては、２つの重要な領域がある。第１の領域は、適正に／正しく受信するまでのレイテンシーにあり、このレイテンシーに起因して、システム情報量、および／または受信回数が増加したり、システム機能のパフォーマンスが低下したりして、その結果として、無線資源の効率が低下することになる。第２の領域は、エラーがあると、その度に、ＵＥのＬ１がＲＲＣ−ＳＤＵ中の全てのＴＢを繰り返し受信し、デコードし、処理することを要求され、その結果として、高い処理コストとバッテリーコストが生じることになる領域である。
【００２１】
そうすると、ＵＭＴＳ ＴＤＤまたはＦＤＤシステムに対しては改善するニーズがある。
【課題を解決するための手段】
【００２２】
情報セグメントのセットを周期的に伝送することを含む通信を、受信し処理する方法においては、情報セグメントセットの各情報セグメントが有効か否かを識別するため、このような情報セグメントセットについて第１回目の伝送が行われる。この第１回目の伝送で伝送された情報セグメントセットは、受信され処理される。そして、当該情報セグメントセットの情報セグメントのうち有効なセグメントが、ストアされる。この第１回目に伝送された情報セグメントセットの情報セグメントが全て有効でなく、その結果、ストアされない場合には、その後に続いて、情報セグメントセットが伝送される。その後に続いて伝送された情報セグメントの情報セグメントのうち以前有効でなくその結果ストアされなかった情報セグメントに対応する情報セグメントのみが、これら受信された情報セグメントについて、有効か否かを識別するために、受信および処理がされる。そして、有効な情報セグメントがストアされる。以後、当該情報セグメントセットの全ての情報セグメントが有効でストアされるまで、情報セグメントのセットのその後に続く伝送が、繰り返し受信される。
【発明の効果】
【００２３】
以上説明したように、本発明によれば、システム情報、例えば、より高速なセルサーチと、より短縮されたハンドオーバ伝送中断期間と、より高速なＲＡＮコネクション確立と、より高速なＵＥステートの遷移と、の獲得に関連付けさられたＵＥ機能のパフォーマンスを改善できる。
【図面の簡単な説明】
【００２４】
【図１】ＵＭＴＳ（universal mobile telecommunications system）を示すブロック図である。
【図２】無線インタフェースプロトコルスタックアーキテクチャの例を示す図である。
【図３】Ｌ２におけるデータフローを示す図である。
【図４】Ｌ１ ＳＤＵを受信するＵＥを示す図である。
【図５】ＲＲＣ−ＳＤＵを受信するために用いられる現行の方法を示す図である。
【図６】ＲＲＣ−ＳＤＵを受信するために用いられる現行の方法のフロー図である。
【図７】本発明の好ましい実施形態に係るＲＲＣ−ＳＤＵを受信する方法を示す図である。
【図８】本発明の好ましい実施形態に係るＲＲＣ−ＳＤＵを受信する方法を示すフロー図である。
【発明を実施するための形態】
【００２５】
以下、本発明の好ましい実施形態について、図面を参照して説明する。図において同一の参照番号は同様の要素を示す。
【００２６】
図４を説明する。ＵＥ−Ｌ１は、受信したＴＢセットと、ＳＦＮと、各ＴＢのうちのＣＲＣエラー検出結果を、上位レイヤー（Ｌ２およびＬ３）に渡す。ＭＡＣレイヤー２４と、ＲＬＣレイヤー２５は、ＢＣＣＨに対して、トランスペアレントモードでオペレートするので、例えば、ＢＣＣＨのＴＢを、処理せず、Ｌ３にホワーディング（forwarding）することができる。また、ＣＲＣエラーのあるＴＢは、Ｌ３へホワーディングされる前に、Ｌ２またはＬ３によって廃棄される可能性もある。
【００２７】
図７と図８は、それぞれ、本発明の好ましい実施形態において用いられる方法の例を示す図であり、この方法のフローを示す図である。図７は、ＲＲＣ−ＳＤＵが、６４フレームの繰り返し期間を有する９つのＴＢで構成されているシナリオの例を示す。ＳＦＮ＝２からＳＦＮ＝１８までのＲＲＣ−ＳＤＵを期待するように、予めＵＥ−ＢＣＦＥに通知される。ＵＥ−ＢＣＦＥは、基地局１４−１７のうち１つの基地局から、そのＲＲＣ−ＳＤＵに対応するＴＢセットを受信し（ステップ８０）、１つ以上のＴＢを紛失したか、あるいはエラーがあるか否かを判断する（ステップ８１）。
【００２８】
本発明の好ましい実施形態によれば、ＵＥ−ＢＣＦＥがこの判断を行う方法としては、少なくとも２つの方法がある。第１の方法は、ＵＥのＬ１がＣＲＣエラー検出を用いて伝送エラーがあるか否かを検出し、エラーのあるＴＢのＳＦＮをＵＥ−ＢＣＦＥに通知する方法である。第２の方法は、ＵＥ−ＢＣＦＥがスケジューリング情報と、正しく受信されたＴＢのＳＦＮとを利用して、正常受信されなかったＴＢを判断する方法である。ここでは、ＴＢにエラーがあるか、あるいはＴＢを紛失したか否かをこのように判断する方法としては、２つの方法のみを開示したが、その他の方法も、本発明の範囲を逸脱しない限り使用することができる。
【００２９】
ひとたびＵＥ−ＢＣＦＥがこのような判断を行うと、正しいＴＢはＵＥ−ＢＣＦＥによりストアされ（ステップ８２）、紛失したＴＢ、またはエラーのあるＴＢは、廃棄される（ステップ８３）。ステップ８３は、ＵＥ−ＢＣＦＥを処理する前に、Ｌ１またはＬ２のいずれかにより同様にして実行されるから、このことに留意されたい。そして、ＲＲＣ２８は、エラーがあるか紛失するかした全てのＴＢの次のＳＦＮを、次のＲＲＣ−ＳＤＵの伝送について計算する（ステップ８４）。図７の例においては、ＳＦＮの次のオカランス（本例では、７４）を決定するため、ＵＥ−ＢＣＦＥは、エラーのあったＴＢ（ＳＦＮ１０）を、繰り返し期間すなわち６４に加算することになる。幾つかのＴＢにエラーがあることもあるが、このような場合には、エラーのあったＴＢのそれぞれのＳＦＮが、その後のＲＲＣ−ＳＤＵの伝送について、計算される。ひとたびこれらＳＦＮが決定されると、ＲＲＣ２８は、決定されたＳＦＮのみを受信しデコードすることを、Ｌ１に通知する。この例では、再受信時には、ＳＦＮ７４に対応する１つのＴＢのみが識別される。ひとたびＬ１がこの計算されたＳＦＮのあるＴＢを受信すると、Ｌ１は、ＲＲＣ２８から要求があった特定のＳＦＮを有するＴＢとＳＦＮとＣＲＣとを、ＲＲＣ２８にホワーディングする（ステップ８５）。再伝送され受信されたＴＢのセットにエラーが検出されず、かつ当該ＲＲＣ−ＳＤＵからのＴＢを紛失していない場合には、ＵＥ−ＢＣＦＥは、所定の場所に、これら正しいＴＢを他のＴＢとともにストアし（ステップ８２）、ＲＲＣ−ＳＤＵをデコードする（ステップ８６）。受信されたＲＲＣ−ＳＤＵのＴＢに依然としてＣＲＣエラーがある場合には、ＲＲＣ２８はこのようなＳＦＮを判断し、上述した処理を繰り返す（ステップ８４）。以後、当該ＲＲＣ−ＳＤＵに関連付けされた完全ＴＢのセットがＵＥ−ＢＣＦＥによりストアされ、ＲＲＣ２８により処理されるまで、この処理を継続する（ステップ８６）。
【００３０】
本発明は、周期的に伝送されるセグメンテーションされた全てのＲＲＣ−ＳＤＵに適用することができる。このプロシージャは、更新されたＶＡＬＵＥタグが検出されると、開始される。仮に受信中にＶＡＬＵＥタグが更新された場合には、当該セットの前のセットの全てのＴＢが、ＵＥ−ＢＣＦＥにより削除される。
【００３１】
本発明の１つの利点は、ＲＲＣ−ＳＤＵの正常受信時間すなわちレイテンシーが大幅に短縮される点にあり、このレイテンシーは、ＵＥ１８とＵＴＲＡＮ３の間で個々のＴＢを伝送する場合の目標エラー率（ＲＲＣ−ＳＤＵのサイズと無関係である）に関連付けされたレイテンシーまで短縮された。受信レイテンシーが減少すると、これにより、システム情報、例えば、より高速なセルサーチと、より短縮されたハンドオーバ伝送中断期間と、より高速なＲＡＮコネクション確立と、より高速なＵＥステートの遷移と、の獲得に関連付けさられたＵＥ機能のパフォーマンスが改善された。
【００３２】
さらに、本発明によれば、ＵＥ１８がシステム情報をより効率的に受信することができるので、スケジューリングレート（すなわち、再送の周期）を減少させることが可能である。その結果、限りのあるＢＣＣＨの物理的資源の効率が向上し利用率が高くなる。
【００３３】
本発明のもう１つの利点は、ＵＥにおける処理とバッテリー消費とが減少する点にある。ＵＥ１８は、ＴＢの受信エラーを検出する能力を有し、ＴＢスケジューリング情報を認識することができるから、ＲＲＣ−ＳＤＵ全体ではなく、エラーのあった特定のＴＢのみの受信を開始することができる。加えて、より少ない伝送により、ＲＲＣ−ＳＤＵを正常受信することができ、これにより、ＵＥのバッテリー消費が軽減され処理が軽減される。
【００３４】
ＵＥ−ＢＣＦＥをして、ＲＲＣ−ＳＤＵ、例えばＢＣＨ上のＢＣＣＨ−ＳＩＢを、より高速に受信させることができ、かつＵＥでの処理を軽減させ、バッテリー消費を軽減させるため、本発明を適用することができる。
【００３５】
以上、本発明の好ましい実施形態について説明したが、他の変形は、それが特許請求の範囲を逸脱しないものである限り、当業者に明らかなものである。
【産業上の利用可能性】
【００３６】
本発明は、一般的に無線通信システムに利用することができる。特に、ＵＭＴＳ（Universal Mobile Telecommunications Systems）に関する。
【符号の説明】
【００３７】
２ コアネットワーク
３ ＵＴＲＡＮ
１０、１１ ＲＮＳ
【技術分野】
【０００１】
本発明は、ＵＭＴＳ（Universal Mobile Telecommunications Systems）に関する。
【背景技術】
【０００２】
ＵＭＴＳネットワークアーキテクチャは、図１に示すように、コアネットワーク（ＣＮ）２と、ＵＴＲＡＮ（ＵＭＴＳ Terrestrial Radio Access Network ）３と、少なくとも１つのＵＥ（User Equipment）１８（図を簡略にするため、図には１つのＵＥ１８のみを図示した）とを含む。２つの一般的なインタフェースは、ＵＴＲＡＮとコアネットワークの間のＩｕインタフェースであり、同様に、ＵＴＲＡＮとＵＥの間の無線インタフェースＵｕである。
【０００３】
ＵＴＲＡＮは幾つかのＲＮＳ（Radio Network Subsystem）１０、１１よりなる。これらＲＮＳを、Ｉｕｒインタフェースによって相互に接続することができる。ＲＮＳ１０、１１は、それぞれ、ＲＮＣ（Radio Network Controller）１２、１３と、幾つかの基地局（Ｎｏｄｅ Ｂ）１４−１７ とに分割されている。基地局１４−１７はＩｕｂインタフェースによりＲＮＣ１２、１３に接続されている。１つの基地局１４−１７は１または複数のセル（cell）をサーブすることができる。
【０００４】
ＵＴＲＡＮ３は無線インタフェースにおいてＦＤＤモードとＴＤＤモードの両方をサポートする。これら両方のモードに対して、同一のネットワークアーキテクチャと同一のプロトコルが用いられている。
【０００５】
基地局１４−１７とＵＥ１８の間において無線インタフェースＵｕを介して行う通信は、無線インタフェースプロトコルを用いて行われる。無線インタフェースプロトコルスタックアーキテクチャが図２に示してある。当業者にとって当然のことであるが、無線インタフェースプロトコルスタック２０のデザイン（design）は、３つのレイヤー、すなわち、物理レイヤー（Ｌ１）２１と、データリンクレイヤー（Ｌ２）２２と、ネットワークレイヤー（Ｌ３）２３とに分割されている。データリンクレイヤー（Ｌ２）２２は、４つのサブレイヤー、すなわち、ＭＡＣ（media access control）２４と、ＲＬＣ（Radio Link Control）２５と、ＢＭＣ（broadcast/multicast control）２７と、ＰＤＣＰ（packet data convergence protocol）２６とに分けられている。
【０００６】
ネットワークレイヤー（Ｌ３）２３は、ＲＲＣ（radio resource control）２８を含む。このＲＲＣ２８はＵＴＲＡＮ３とＵＥ１８の間のＬ３のコントロールプレーンシグナリング（control plain signaling）を処理する。このＲＲＣ２８は、ＵＴＲＡＮ３における他の全てのプロトコルレイヤーを構成しコントロールすることを担当し、しかも、利用可能な無線資源（radio resource）をコントロールすることを担当する。これには、無線資源を割り当て再構成し解放することが含まれ、同様に、要求されたＱｏＳ（quality of service）を継続してコントロールすることが含まれる。
【０００７】
ＲＬＣレイヤー２５は、トランスペアレントモードか、不確認（unacknowledged）モードか、または確認（acknowledged）モードで、上位レイヤーにデータホワーディングを行う。確認モードでのホワーディングにおいては、選択的拒否−自動再送要求（selective reject-automatic repeat request）を持つスライディングウィンドウプロトコルが用いられる。
【０００８】
ＭＡＣレイヤー２４は、ＲＬＣ２５の論理チャンネルを、物理レイヤーの提供するトランスポートチャンネルに、マッピングする。ＭＡＣレイヤー２４は、主に、マルチプレクシング機能よりなるが、ＭＡＣレイヤー２４には、ＲＲＣ２８により資源配分についての情報が通知される。ＭＡＣレイヤー２４により、同一物理資源にマッピングされた異なるデータフロー間の優先処理が行われる。ＢＭＣ２７とＰＤＣＰ２６の機能とオペレーションについては、当業者に周知であるから、ここではこれ以上説明しない。
【０００９】
物理レイヤー２１は、エアーインタフェース（air interface）を介してトランスポートブロックを伝送することを担当する。この中には、前方誤り訂正（forward error correction）、同一物理資源上への異なるトランスポートチャンネルの多重化、レートマッチング（すなわち、使用可能な物理資源にユーザデータの量を適合させること）、変調、拡散、およびＲＦ（radio frequency）処理が含まれる。エラー検出も、物理レイヤー２１により行われ、上位のレイヤーである、データリンクレイヤー２２、ネットワークレイヤー２３に表示される。
【００１０】
図３はデータリンクレイヤー（Ｌ２）２２のデータフロー全体を示す。上位レイヤーＰＤＵ（protocol data unit）はＲＬＣレイヤー２５に渡される。ＲＬＣレイヤー２５において、ＳＤＵ（service data unit）はセグメントにセグメンテーション（segmentation）されコンカチネート（concatenate）される。ＲＬＣヘッダが付加され、ＲＬＣＰＤＵが構成される。ＲＬＣレイヤー２５においては、エラー検出符号は付加されない。トランスペアレントモードＲＬＣにあっては、ＲＬＣレイヤー２５において、セグメンテーションは行われず、上位レイヤーのＰＤＵにＲＬＣヘッダやＭＡＣヘッダは付加されない。
【００１１】
ＭＡＣレイヤー２４においては、ヘッダが付加されるだけである。このヘッダには、論理チャンネルをトランスポートチャンネルにマッピングすることを記述するルーチング情報を含めることができる。また、共通チャンネル上にＵＥ識別情報を含めることができる。
【００１２】
物理レイヤー（Ｌ１）２１において、エラー検出のためにＣＲＣが付加される。レシーバにおけるＣＲＣチェックのリザルト（result）は、再送コントロールのため、ＲＬＣレイヤーに渡される。
【００１３】
現行のＵＭＴＳ ＴＤＤまたはＦＤＤシステムにおいては、ＲＲＣ−ＳＤＵ（radio resource control service data unit）を、ＲＬＣトランスペアレントモードか、不確認モードか、または確認モードで、ＵＴＲＡＮ−ＲＲＣとＵＥ−ＲＲＣとの間で送信することができる。確認モードについては説明しない。しかし、ＲＲＣ−ＳＤＵが、トランスペアレントモードまたは不確認モードでトランスポートされる場合には、受信側のＲＬＣレイヤーとＭＡＣレイヤーは、ＲＲＣ−ＳＤＵに気付かない。そこで、受信されたＲＲＣ−ＳＤＵであって、伝送中でのエラーまたは他のソースに起因するエラーは、下位レイヤーではなく、ＲＲＣレイヤーにおいて、処理されねばならない。
【００１４】
ＲＲＣ−ＳＤＵは、ＴＢ（transport block）として知られる幾つかの個々のセグメントに入れて伝送することができる。ＲＲＣ−ＳＤＵの一例はＢＣＣＨ−ＳＩＢ）broadcast control channel system information block）である。
【００１５】
ＢＣＣＨ−ＳＩＢの場合には、このＳＩＢに関連付けられたＴＢが、ＵＴＲＡＮ−ＲＲＣからＵＥ−ＢＣＦＥ（UE broadcast control functional entity）へ、繰り返し伝送される。ＳＤＵバージョンの指標は「ＶＡＬＵＥタグ」により識別される。ＶＡＬＵＥタグに変化がないときは、ＵＥ１８は、ＵＴＲＡＮが繰り返し同一のＢＣＣＨ−ＳＩＢを送信していると仮定する。仮にＵＴＲＡＮ３から伝送されるＢＣＣＨ−ＳＩＢに変化がある場合には、そのＵＴＲＡＮ３は、変化があったことを、ＶＡＬＵＥタグを用いて、ＵＥ１８に示す。スケジューリング情報、すなわちＢＣＣＨ−ＳＩＢのＴＢがいつＵＥ１８に到達するかの情報と、ＢＣＣＨ−ＳＩＢのバージョンとが、ＵＴＲＡＮ３からの伝送に先立って、ＵＥ１８に知らされる。
【００１６】
図４は、Ｌ１のＳＤＵを受信するＵＥ１８を示す。このＳＤＵは、例えば、ＢＣＣＨ−ＳＩＢを持つＴＢと、ＵＥ１８のＬ１により伝送エラー検出を行うために用いられるＣＲＣとを備える。図に示すように、ＴＢはＳＦＮ（system frame number）を含むことができるが、このＳＦＮは、ＢＣＣＨ−ＳＩＢのＴＢでもそうであったが、ＴＢのＵＥ１８への到達タイムを示すものである。あるいはまた、ＴＢがＳＦＮを明示的に含んでいないときは、到達タイムを示すＳＦＮは、Ｌ１により物理レイヤーのタイミングから導き出すことができる。ＵＥ１８のＬ１は、ＴＢと、ＳＦＮと、ＣＲＣとのリザルトを上位のレイヤーに渡す。しかし、ＲＬＣとＭＡＣレイヤー２５、２４が、ＢＣＨ（broadcast channel）データに対してトランスペアレントモードでオペレートするので、このＴＢはＲＲＣレイヤーに渡される。
【００１７】
ＴＢは、ＵＥ１８とＵＴＲＡＮ３の間をフェージング環境で伝送されることが多いので、ＴＢの伝送と、正常送受信の目標確率、例えば９９％とが関連付けされる。仮にＢＣＣＨ−ＳＩＢが多数のＴＢから構成されている場合には、ＢＣＣＨ−ＳＩＢのＴＢを全て正しく受信する確率は、おおよそ０．９９の（ＴＢの数のべき乗）になる。例えば、ＢＣＣＨ（broadcast control channel）のＢＣＣＨ−ＳＩＢは、１０個を超える数のＴＢを伝送する必要がある場合があり、この場合、ＵＥ１８がＢＣＣＨ−ＳＩＢを正しく受信する確率は、０．９９の１０乗、すなわち、９０％未満になる。したがって、ＢＣＣＨ−ＳＩＢを正しく受信できる確率は、ＴＢの数が増加するほど減少する。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
ＵＭＴＳ ＴＤＤまたはＦＤＤシステムにおいて、ＳＩＢを正常に受信するためのタイムによって、多くのシステム機能のパフォーマンスが決定される。加えて、これらのシステム機能の適正なパフォーマンスを維持するためには、欠陥のあった伝送を補完するため、ＳＩＢの繰り返しレートを増加させねばならない場合があるが、そうすると、無線資源の効率と利便性が低下する。
【００１９】
図５と図６は、それぞれ、ＵＴＲＡＮ３によりＵＥ１８に伝送されたＲＲＣ−ＳＤＵを正常に受信するのに使用される現行の方法の例でありフローを示す図である。図に示すように、ＵＥ−ＢＣＦＥはＲＲＣ−ＳＤＵを受信する（ステップ６０）。ここでは、このＲＲＣ−ＳＤＵが９つのＴＢを備え、ＳＦＮ＝２からＳＦＮ＝１８までがラベル付けしてあり、繰り返しレートが６４フレームである。ＵＥ−ＢＣＦＥはＲＲＣ−ＳＤＵを読み取り、ＴＢにエラーがないか、ＲＲＣ−ＳＤＵが紛失していないかを判断する（ステップ６１）。ここでは、ＳＦＮ１０にエラーがあるものとする。受信されたＲＲＣ−ＳＤＵにエラーがあるので、ＵＥ−ＢＣＦＥは全てのＲＲＣ−ＳＤＵを廃棄し、繰り返しレート、すなわち６４フレームだけ待機し、同一の情報を持つ別のＲＲＣ−ＳＤＵを受信する（ステップ６２）。再び、このＵＥ−ＢＣＦＥは、９つのＴＢを備え、ＳＦＮ＝６６からＳＦＮ＝８２までをラベル付けしたＲＲＣ−ＳＤＵを受信し（ステップ６３）、エラーがあるか否かを判断する（ステップ６１）。この例では、ＳＦＮ７０（ＳＦＮ６＋６４（繰り返しレート））は、エラーを有するか、紛失している。仮に受信されたＲＲＣ−ＳＤＵにエラーが発見されない場合には、ＵＥ−ＢＣＦＥはそのＲＲＣ−ＳＤＵを正常に受信したので、そのＲＲＣ−ＳＤＵをデコードする（ステップ６４）。仮にエラーが発見された場合には、この例では、ＵＥ−ＢＣＦＥは、受信したＲＲＣ−ＳＤＵ（９つのＴＢを備えている）全体を廃棄し、繰り返しレートだけ待機し（ステップ６２）、次のＲＲＣ−ＳＤＵを受信する（ステップ６３）。このプロセスは、ＵＥ−ＢＣＦＥが９つのＴＢの連続したものを正常に受信するまで、継続される。
【００２０】
ＵＴＲＡＮからＲＲＣ−ＳＤＵを受信するこの種の方法に関連する領域としては、２つの重要な領域がある。第１の領域は、適正に／正しく受信するまでのレイテンシーにあり、このレイテンシーに起因して、システム情報量、および／または受信回数が増加したり、システム機能のパフォーマンスが低下したりして、その結果として、無線資源の効率が低下することになる。第２の領域は、エラーがあると、その度に、ＵＥのＬ１がＲＲＣ−ＳＤＵ中の全てのＴＢを繰り返し受信し、デコードし、処理することを要求され、その結果として、高い処理コストとバッテリーコストが生じることになる領域である。
【００２１】
そうすると、ＵＭＴＳ ＴＤＤまたはＦＤＤシステムに対しては改善するニーズがある。
【課題を解決するための手段】
【００２２】
情報セグメントのセットを周期的に伝送することを含む通信を、受信し処理する方法においては、情報セグメントセットの各情報セグメントが有効か否かを識別するため、このような情報セグメントセットについて第１回目の伝送が行われる。この第１回目の伝送で伝送された情報セグメントセットは、受信され処理される。そして、当該情報セグメントセットの情報セグメントのうち有効なセグメントが、ストアされる。この第１回目に伝送された情報セグメントセットの情報セグメントが全て有効でなく、その結果、ストアされない場合には、その後に続いて、情報セグメントセットが伝送される。その後に続いて伝送された情報セグメントの情報セグメントのうち以前有効でなくその結果ストアされなかった情報セグメントに対応する情報セグメントのみが、これら受信された情報セグメントについて、有効か否かを識別するために、受信および処理がされる。そして、有効な情報セグメントがストアされる。以後、当該情報セグメントセットの全ての情報セグメントが有効でストアされるまで、情報セグメントのセットのその後に続く伝送が、繰り返し受信される。
【発明の効果】
【００２３】
以上説明したように、本発明によれば、システム情報、例えば、より高速なセルサーチと、より短縮されたハンドオーバ伝送中断期間と、より高速なＲＡＮコネクション確立と、より高速なＵＥステートの遷移と、の獲得に関連付けさられたＵＥ機能のパフォーマンスを改善できる。
【図面の簡単な説明】
【００２４】
【図１】ＵＭＴＳ（universal mobile telecommunications system）を示すブロック図である。
【図２】無線インタフェースプロトコルスタックアーキテクチャの例を示す図である。
【図３】Ｌ２におけるデータフローを示す図である。
【図４】Ｌ１ ＳＤＵを受信するＵＥを示す図である。
【図５】ＲＲＣ−ＳＤＵを受信するために用いられる現行の方法を示す図である。
【図６】ＲＲＣ−ＳＤＵを受信するために用いられる現行の方法のフロー図である。
【図７】本発明の好ましい実施形態に係るＲＲＣ−ＳＤＵを受信する方法を示す図である。
【図８】本発明の好ましい実施形態に係るＲＲＣ−ＳＤＵを受信する方法を示すフロー図である。
【発明を実施するための形態】
【００２５】
以下、本発明の好ましい実施形態について、図面を参照して説明する。図において同一の参照番号は同様の要素を示す。
【００２６】
図４を説明する。ＵＥ−Ｌ１は、受信したＴＢセットと、ＳＦＮと、各ＴＢのうちのＣＲＣエラー検出結果を、上位レイヤー（Ｌ２およびＬ３）に渡す。ＭＡＣレイヤー２４と、ＲＬＣレイヤー２５は、ＢＣＣＨに対して、トランスペアレントモードでオペレートするので、例えば、ＢＣＣＨのＴＢを、処理せず、Ｌ３にホワーディング（forwarding）することができる。また、ＣＲＣエラーのあるＴＢは、Ｌ３へホワーディングされる前に、Ｌ２またはＬ３によって廃棄される可能性もある。
【００２７】
図７と図８は、それぞれ、本発明の好ましい実施形態において用いられる方法の例を示す図であり、この方法のフローを示す図である。図７は、ＲＲＣ−ＳＤＵが、６４フレームの繰り返し期間を有する９つのＴＢで構成されているシナリオの例を示す。ＳＦＮ＝２からＳＦＮ＝１８までのＲＲＣ−ＳＤＵを期待するように、予めＵＥ−ＢＣＦＥに通知される。ＵＥ−ＢＣＦＥは、基地局１４−１７のうち１つの基地局から、そのＲＲＣ−ＳＤＵに対応するＴＢセットを受信し（ステップ８０）、１つ以上のＴＢを紛失したか、あるいはエラーがあるか否かを判断する（ステップ８１）。
【００２８】
本発明の好ましい実施形態によれば、ＵＥ−ＢＣＦＥがこの判断を行う方法としては、少なくとも２つの方法がある。第１の方法は、ＵＥのＬ１がＣＲＣエラー検出を用いて伝送エラーがあるか否かを検出し、エラーのあるＴＢのＳＦＮをＵＥ−ＢＣＦＥに通知する方法である。第２の方法は、ＵＥ−ＢＣＦＥがスケジューリング情報と、正しく受信されたＴＢのＳＦＮとを利用して、正常受信されなかったＴＢを判断する方法である。ここでは、ＴＢにエラーがあるか、あるいはＴＢを紛失したか否かをこのように判断する方法としては、２つの方法のみを開示したが、その他の方法も、本発明の範囲を逸脱しない限り使用することができる。
【００２９】
ひとたびＵＥ−ＢＣＦＥがこのような判断を行うと、正しいＴＢはＵＥ−ＢＣＦＥによりストアされ（ステップ８２）、紛失したＴＢ、またはエラーのあるＴＢは、廃棄される（ステップ８３）。ステップ８３は、ＵＥ−ＢＣＦＥを処理する前に、Ｌ１またはＬ２のいずれかにより同様にして実行されるから、このことに留意されたい。そして、ＲＲＣ２８は、エラーがあるか紛失するかした全てのＴＢの次のＳＦＮを、次のＲＲＣ−ＳＤＵの伝送について計算する（ステップ８４）。図７の例においては、ＳＦＮの次のオカランス（本例では、７４）を決定するため、ＵＥ−ＢＣＦＥは、エラーのあったＴＢ（ＳＦＮ１０）を、繰り返し期間すなわち６４に加算することになる。幾つかのＴＢにエラーがあることもあるが、このような場合には、エラーのあったＴＢのそれぞれのＳＦＮが、その後のＲＲＣ−ＳＤＵの伝送について、計算される。ひとたびこれらＳＦＮが決定されると、ＲＲＣ２８は、決定されたＳＦＮのみを受信しデコードすることを、Ｌ１に通知する。この例では、再受信時には、ＳＦＮ７４に対応する１つのＴＢのみが識別される。ひとたびＬ１がこの計算されたＳＦＮのあるＴＢを受信すると、Ｌ１は、ＲＲＣ２８から要求があった特定のＳＦＮを有するＴＢとＳＦＮとＣＲＣとを、ＲＲＣ２８にホワーディングする（ステップ８５）。再伝送され受信されたＴＢのセットにエラーが検出されず、かつ当該ＲＲＣ−ＳＤＵからのＴＢを紛失していない場合には、ＵＥ−ＢＣＦＥは、所定の場所に、これら正しいＴＢを他のＴＢとともにストアし（ステップ８２）、ＲＲＣ−ＳＤＵをデコードする（ステップ８６）。受信されたＲＲＣ−ＳＤＵのＴＢに依然としてＣＲＣエラーがある場合には、ＲＲＣ２８はこのようなＳＦＮを判断し、上述した処理を繰り返す（ステップ８４）。以後、当該ＲＲＣ−ＳＤＵに関連付けされた完全ＴＢのセットがＵＥ−ＢＣＦＥによりストアされ、ＲＲＣ２８により処理されるまで、この処理を継続する（ステップ８６）。
【００３０】
本発明は、周期的に伝送されるセグメンテーションされた全てのＲＲＣ−ＳＤＵに適用することができる。このプロシージャは、更新されたＶＡＬＵＥタグが検出されると、開始される。仮に受信中にＶＡＬＵＥタグが更新された場合には、当該セットの前のセットの全てのＴＢが、ＵＥ−ＢＣＦＥにより削除される。
【００３１】
本発明の１つの利点は、ＲＲＣ−ＳＤＵの正常受信時間すなわちレイテンシーが大幅に短縮される点にあり、このレイテンシーは、ＵＥ１８とＵＴＲＡＮ３の間で個々のＴＢを伝送する場合の目標エラー率（ＲＲＣ−ＳＤＵのサイズと無関係である）に関連付けされたレイテンシーまで短縮された。受信レイテンシーが減少すると、これにより、システム情報、例えば、より高速なセルサーチと、より短縮されたハンドオーバ伝送中断期間と、より高速なＲＡＮコネクション確立と、より高速なＵＥステートの遷移と、の獲得に関連付けさられたＵＥ機能のパフォーマンスが改善された。
【００３２】
さらに、本発明によれば、ＵＥ１８がシステム情報をより効率的に受信することができるので、スケジューリングレート（すなわち、再送の周期）を減少させることが可能である。その結果、限りのあるＢＣＣＨの物理的資源の効率が向上し利用率が高くなる。
【００３３】
本発明のもう１つの利点は、ＵＥにおける処理とバッテリー消費とが減少する点にある。ＵＥ１８は、ＴＢの受信エラーを検出する能力を有し、ＴＢスケジューリング情報を認識することができるから、ＲＲＣ−ＳＤＵ全体ではなく、エラーのあった特定のＴＢのみの受信を開始することができる。加えて、より少ない伝送により、ＲＲＣ−ＳＤＵを正常受信することができ、これにより、ＵＥのバッテリー消費が軽減され処理が軽減される。
【００３４】
ＵＥ−ＢＣＦＥをして、ＲＲＣ−ＳＤＵ、例えばＢＣＨ上のＢＣＣＨ−ＳＩＢを、より高速に受信させることができ、かつＵＥでの処理を軽減させ、バッテリー消費を軽減させるため、本発明を適用することができる。
【００３５】
以上、本発明の好ましい実施形態について説明したが、他の変形は、それが特許請求の範囲を逸脱しないものである限り、当業者に明らかなものである。
【産業上の利用可能性】
【００３６】
本発明は、一般的に無線通信システムに利用することができる。特に、ＵＭＴＳ（Universal Mobile Telecommunications Systems）に関する。
【符号の説明】
【００３７】
２ コアネットワーク
３ ＵＴＲＡＮ
１０、１１ ＲＮＳ
【特許請求の範囲】
【請求項１】
Ｎ個の情報セグメントのセットの周期的な伝送を受信する方法であって、
前記Ｎ個の情報セグメントのセット全体の伝送を、繰り返し受信するステップと、
レイヤー３において、有効なセグメントがまだストアされていない各々の情報セグメントを処理して、その情報セグメントが有効かまたは無効かを識別するステップと、
前記有効な情報セグメントをストアするステップと、
前記セットのＮ個の異なる情報セグメントがストアされているか否かを判定するステップと、
前記セットのＮ個の異なる情報セグメントがストアされていないと判定した場合に、前記受信するステップ、前記処理して識別するステップ、前記ストアするステップおよび前記判定するステップを繰り返すステップと、
最初の前記Ｎ個の情報セグメントのセット全体の伝送を受信した後で、先に無効として識別されたセグメントのみをデコードするステップと、
Ｎ個の異なる情報セグメントがストアされた後、前記ストアされたセットをさらに処理するため、デコードするステップと、
を備えることを特徴とする方法。
【請求項２】
請求項１において、前記処理して、識別するステップは、
前記セグメントの各々とともに含まれるエラーコードを用いて、いずれかの前記セグメントのエラーを検出するステップと、
前記エラーが検出された前記セグメントの各々のセグメント番号を判断するステップと、
をさらに含むことを特徴とする方法。
【請求項３】
請求項２において、前記情報セグメントは、情報セグメントに含まれる情報を示すヴァリュータグを含むことを特徴とする方法。
【請求項４】
請求項３において、第１回目の伝送と、後続する伝送とは、等しいヴァリュータグを有することを特徴とする方法。
【請求項５】
請求項４において、前記ストアされた有効な情報セグメントは、前記第１回目の伝送と前記後続する伝送とにおいてヴァリュータグが等しくない場合に、削除されることを特徴とする方法。
【請求項１】
Ｎ個の情報セグメントのセットの周期的な伝送を受信する方法であって、
前記Ｎ個の情報セグメントのセット全体の伝送を、繰り返し受信するステップと、
レイヤー３において、有効なセグメントがまだストアされていない各々の情報セグメントを処理して、その情報セグメントが有効かまたは無効かを識別するステップと、
前記有効な情報セグメントをストアするステップと、
前記セットのＮ個の異なる情報セグメントがストアされているか否かを判定するステップと、
前記セットのＮ個の異なる情報セグメントがストアされていないと判定した場合に、前記受信するステップ、前記処理して識別するステップ、前記ストアするステップおよび前記判定するステップを繰り返すステップと、
最初の前記Ｎ個の情報セグメントのセット全体の伝送を受信した後で、先に無効として識別されたセグメントのみをデコードするステップと、
Ｎ個の異なる情報セグメントがストアされた後、前記ストアされたセットをさらに処理するため、デコードするステップと、
を備えることを特徴とする方法。
【請求項２】
請求項１において、前記処理して、識別するステップは、
前記セグメントの各々とともに含まれるエラーコードを用いて、いずれかの前記セグメントのエラーを検出するステップと、
前記エラーが検出された前記セグメントの各々のセグメント番号を判断するステップと、
をさらに含むことを特徴とする方法。
【請求項３】
請求項２において、前記情報セグメントは、情報セグメントに含まれる情報を示すヴァリュータグを含むことを特徴とする方法。
【請求項４】
請求項３において、第１回目の伝送と、後続する伝送とは、等しいヴァリュータグを有することを特徴とする方法。
【請求項５】
請求項４において、前記ストアされた有効な情報セグメントは、前記第１回目の伝送と前記後続する伝送とにおいてヴァリュータグが等しくない場合に、削除されることを特徴とする方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１０−２７９０７１（Ｐ２０１０−２７９０７１Ａ）
【公開日】平成２２年１２月９日（２０１０．１２．９）
【国際特許分類】
【出願番号】特願２０１０−１８１７６９（Ｐ２０１０−１８１７６９）
【出願日】平成２２年８月１６日（２０１０．８．１６）
【分割の表示】特願２００６−５０６７（Ｐ２００６−５０６７）の分割
【原出願日】平成１４年９月１３日（２００２．９．１３）
【出願人】（５９６００８６２２）インターデイジタル テクノロジー コーポレーション (871)
【Ｆターム（参考）】
【公開日】平成２２年１２月９日（２０１０．１２．９）
【国際特許分類】
【出願日】平成２２年８月１６日（２０１０．８．１６）
【分割の表示】特願２００６−５０６７（Ｐ２００６−５０６７）の分割
【原出願日】平成１４年９月１３日（２００２．９．１３）
【出願人】（５９６００８６２２）インターデイジタル テクノロジー コーポレーション (871)
【Ｆターム（参考）】
[ Back to top ]