(57)【要約】【課題】ＵＭＴＳ  ＴＤＤまたはＦＤＤシステムにおいて、システム機能の適正なパフォーマンスを維持するためには、欠陥のあった伝送を補完するため、ＳＩＢの繰り返しレートを増加させねばならない場合、無線資源の効率と利便性が低下する。【解決手段】情報セグメントよりなる情報セグメントの周期的な伝送を含む通信を受信し処理する方法である。情報セグメントセットの第１回目の伝送を受信し処理し、各情報セグメントの有効無効を判断し、有効と判断した情報セグメントをストアする。情報セグメントセットの全情報セグメントがストアされなかった場合、その後の情報セグメントセットの伝送を受信し、以前ストアされなかった情報セグメントに対応する情報セグメントのみを処理し有効無効を判断する。有効と判断した情報セグメントをストアする。情報セグメントセットの全情報セグメントがストアされるまで、その後の伝送を繰返し受信する。【選択図】図８
2014014184.tif 000002
【特許請求の範囲】
【請求項１】
セグメント化された通信を受信する方法において、
前記全体のセグメント化された通信を、周期的に受信するステップと、
前記セグメント化された通信の各々のセグメントを検査して、前記セグメントが有効であるかどうかを決定するステップと、
前記セグメントが有効であれば、前記有効なセグメントをストアするステップと、
前記セグメントが無効であれば、
前記無効なセグメントを識別するステップと、
再送信された全体のセグメント化された通信を受信するステップと、
前記再送信されたセグメント化された通信の、前記識別された無効なセグメントのみを検査するステップと、
前記セグメントのすべてが、有効に受信されるまで、前記全体のセグメント化された
通信を繰り返し受信するステップと
を備えることを特徴とする方法。
【請求項２】
前記検査するステップは、
各々のセグメントとともに含まれるエラーコードを使って、セグメントの中でエラーを検出するステップと、
エラーが検出された各々のセグメントのセグメント番号を決定するステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記全体のセグメント化された通信は、所定の繰り返しレートの後で、受信されることを特徴とする請求項１に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
本発明は、ＵＭＴＳ（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）に関する。
【符号の説明】
【００３５】
２  コアネットワーク
３  ＵＴＲＡＮ
１０、１１  ＲＮＳ  
【図１】
2014014184.tif 000003
【図２】
2014014184.tif 000004
【図３】
2014014184.tif 000005
【図４】
2014014184.tif 000006
【図５】
2014014184.tif 000007
【図６】
2014014184.tif 000008
【図７】
2014014184.tif 000009
【図８】
2014014184.tif 000010