説明

タイミング調整方法、移動通信システム、移動局および基地局

【課題】基地局10から移動局20への送信タイミングの調整等において生じ得る不都合を解決する。
【解決手段】移動局20は、第1の上り送信制御情報TA#1を有し基地局10に対する接続手順を行なっている場合に、第2の上り送信制御情報TA#2の受信を含む該接続手順の過程で、該第1の上り送信制御情報TA#1の適用時間を制御するタイマ251が、該移動局20の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止する。

【発明の詳細な説明】
【技術分野】
【0001】
本件は、タイミング調整方法、移動通信システム、移動局および基地局に関する。本件は、無線(移動)通信システムの上り(アップリンク:UL)の通信制御に用いられる場合がある。
【背景技術】
【0002】
携帯電話などの無線端末(移動局)を含む無線(移動)通信システムとして、現在、code division multiple access(CDMA)方式を用いた第3世代移動通信サービスが提供されている。一方、より高速な通信を可能とする次世代移動通信方式も検討されている。3rd Generation Partnership Project(3GPP)においては、Long Term Evolution(LTE)として次世代移動通信方式の検討が行なわれている。
【0003】
移動通信システムにおいては、無線基地局(evolved Node B:eNB)と移動局(User Equipment:UE)とが通信を開始するにあたって、UEがeNBに対して送信を開始する際に用いられるチャネルが用意される。3GPPにおいては、このチャネルをランダムアクセスチャネル(RACH)と呼び、RACHによる通信開始手順をランダムアクセス(RA)と呼ぶ。
【0004】
LTEにおけるランダムアクセスはSlotted Aloha方式で設計されており、RACHを送信するための時間・周波数リソースが確保されている。RACHには、eNBがUEからの送信を識別するための情報が含まれる。即ち、複数のUEで共通にRACHを使用可能とすべく、シグニチャ(あるいはプリアンブル)と呼ばれる識別子が含まれる。
UEは、複数のシグニチャの候補のうち、いずれかのシグニチャを用いて送信を行なうことで、異なるUEが、たとえ同じ時間・周波数リソースを使ってRACHを介してシグニチャの送信を行なっても、各UEが異なるシグニチャを用いていれば、eNBは、受信したシグニチャに基づいて、UEを識別することができる。
【0005】
なお、RACHは、通信開始時に使用され、以降は個別チャネル(または共有チャネル)が使用される。
UEがRAを実行する契機としては、例えば、初回送信(発信)時、eNBから着信があった時(ダウンリンク(DL)データの発生時)、ハンドオーバ時、接続解除後の復帰時(中断した通信の再開時)などがある。なお、eNBからUEへの方向の無線リンクがダウンリンク(DL)であり、その逆の方向の無線リンクがアップリンク(UL)である。
【0006】
ここで、初回送信時や接続解除後の復帰時など、eNBで存在が管理できていないUEには、排他的に使用可能な個別のシグニチャが割り当てられていない場合がある。そのようなUEは、予め用意されている複数(例えば64種類)のシグニチャの中から一つを選んでRAを行なう。したがって、低い確率ではあるが、複数のUEが同時に同じシグニチャを用いてRAを行なうことが起こり得る。このようなRA方法をcontention based random access procedure(コンテンションベースRA手順)という。
【0007】
この場合に、eNBは、競合するシグニチャ(UE)の解決(選択)を行ない、選択したUEへ応答を行なう。UEは、eNBから受信した前記応答を基に、自身がeNBに選択されたかどうかを判断する。eNBに選択されたUEは、eNBとの通信(RA手順)を継続して、eNBとの間の無線チャネル設定などを行なう。eNBに選択されなかったUEは、一定時間経過後などに、RAを再実行する。
【0008】
なお、UEが接続先のeNBを切り替えるハンドオーバを実行する場合にこのようなシグニチャの衝突が発生すると、接続の瞬断や、場合によっては通信が切断される。そのため、LTEでは、ハンドオーバを行なうUEには、予め個別のシグニチャを割り当てることが提案されている。このようなRA方法を、 non-contention based random access procedure(非コンテンションベースRA手順)と呼ぶ。
【非特許文献1】3GPP TS 36.321 V8.1.0、“Evolved Universal Terrestrial Radio Accesss (E-UTRA); Medium Acces Control (MAC) protocol specification”、[online]、平成20年3月20日、[平成20年5月22日検索]、インターネット〈URL:http://www.3gpp.org/ftp/Specs/html-info/36321.htm〉
【発明の開示】
【発明が解決しようとする課題】
【0009】
従来技術では、RAの過程(実行途中)で、送信タイミングの調整情報の有効期限が切れたり等、送信タイミングの調整等において不都合が生ずることがある。
そこで、基地局から端末(移動局)への送信タイミングの調整等において生じ得る不都合を解決することを目的とする。
他の目的の一つは、移動局が基地局に接続して通信を開始できるようになるまでの遅延時間を低減することにある。
【0010】
なお、前記目的に限らず、後述する実施形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも他の目的の一つとして位置付けることができる。
【課題を解決するための手段】
【0011】
例えば、以下の手段を用いる。
(1)移動局と基地局とを備えた移動通信システムにおけるタイミング調整方法において、前記移動局は、第1の上り送信制御情報を有し前記基地局に対する接続手順を行なっている場合に、第2の上り送信制御情報の受信を含む該接続手順の過程で、該第1の上り送信制御情報の適用時間を制御するタイマが、該移動局の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止する、タイミング調整方法を用いることができる。
【0012】
(2)上り送信制御情報に基づいて、送信手順を行なう移動局と、該移動局から送信された信号を受信する基地局とを備えた移動通信システムにおいて、前記移動局は、第1の上り送信制御情報を有し前記基地局に対する接続手順を行なう送信処理部と、第2の上り送信制御情報の受信を含む該接続手順の過程で、該第1の上り送信制御情報の適用時間を制御するタイマが、該移動局の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止するようにする制御部と、を備える移動通信システムを用いることができる。
【0013】
(3)移動局と、該移動局から送信された信号を受信する基地局とを備えた移動通信システムにおける該移動局において、第1の上り送信制御情報を有し前記基地局に対する接続手順を行なう送信処理部と、第2の上り送信制御情報の受信を含む該接続手順の過程で、該第1の上り送信制御情報の適用時間を制御するタイマが、該移動局の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止するようにする制御部と、を備える移動局を用いることができる。
【0014】
(4)上り送信制御情報に基づいて、送信手順を行なう移動局と、該移動局から送信された信号を受信する基地局とを備えた移動通信システムにおける該基地局において、第1の上り送信制御情報を有し前記基地局に対する接続手順を行なう送信処理部と、第2の上り送信制御情報の受信を含む該接続手順の過程で、該第1の上り送信制御情報の適用時間を制御するタイマが、該移動局の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止するようにする制御部と、を有する前記移動局から送信された信号を受信する受信処理部、を備える基地局を用いることができる。
【発明の効果】
【0015】
基地局から移動局への送信タイミングの調整等において生じ得る不都合を解決することが可能となる。
移動局が基地局に接続して通信を開始できるようになるまでの遅延時間を低減することも可能である。
【図面の簡単な説明】
【0016】
【図1】第1実施形態に係る無線(移動)通信システムの一例を示すブロック図である。
【図2】コンテンションベースRA手順の一例を示すシーケンス図である。
【図3】コンテンションベースRA手順におけるUEの動作例を示すフローチャートである。
【図4】コンテンションベースRA手順におけるeNBの動作例を示すフローチャートである。
【図5】第1実施形態に係るUL通信制御(方法1−1)の一例を示すシーケンス図である。
【図6】第1実施形態に係るUL通信制御(方法1−1)の他の一例を示すシーケンス図である。
【図7】第1実施形態に係るUL通信制御(方法1−1)の他の一例を示すシーケンス図である。
【図8】第1実施形態に係るUEのUL通信制御(方法1−1)の一例を示すフローチャートである。
【図9】第1実施形態に係るUL通信制御(方法1−2)の一例を示すシーケンス図である。
【図10】第1実施形態に係るUL通信制御(方法1−2)の他の一例を示すシーケンス図である。
【図11】第1実施形態に係るUL通信制御(方法1−2)の他の一例を示すシーケンス図である。
【図12】第1実施形態に係るUEのUL通信制御(方法1−2)の一例を示すフローチャートである。
【図13】第1実施形態に係るUL通信制御(方法1−3)の一例を示すシーケンス図である。
【図14】第1実施形態に係るUL通信制御(方法1−3)の他の一例を示すシーケンス図である。
【図15】第1実施形態に係るUL通信制御(方法1−3)の他の一例を示すシーケンス図である。
【図16】第1実施形態に係るUEのUL通信制御(方法1−3)の一例を示すフローチャートである。
【図17】第1実施形態に係るUL通信制御(方法1−4)の一例を示すシーケンス図である。
【図18】第1実施形態に係るUL通信制御(方法1−4)の他の一例を示すシーケンス図である。
【図19】第1実施形態に係るUL通信制御(方法1−4)の他の一例を示すシーケンス図である。
【図20】第1実施形態に係るUEのUL通信制御(方法1−4)の一例を示すフローチャートである。
【図21】第2実施形態に係るUL通信制御(方法2−1)の一例を示すシーケンス図である。
【図22】第2実施形態に係るUL通信制御(方法2−1)の他の一例を示すシーケンス図である。
【図23】第2実施形態に係るUL通信制御(方法2−1)の他の一例を示すシーケンス図である。
【図24】第2実施形態に係るUEのUL通信制御(方法2−1)の一例を示すフローチャートである。
【図25】第2実施形態に係るUL通信制御(方法2−2,2−3)の一例を示すシーケンス図である。
【図26】第2実施形態に係るUL通信制御(方法2−2,2−3)の他の一例を示すシーケンス図である。
【図27】第2実施形態に係るUL通信制御(方法2−2,2−3)の他の一例を示すシーケンス図である。
【図28】第2実施形態に係るUEのUL通信制御(方法2−2)の一例を示すフローチャートである。
【図29】第2実施形態に係るUEのUL通信制御(方法2−3)の一例を示すフローチャートである。
【図30】第2実施形態に係るUL通信制御(方法2−4)の一例を示すシーケンス図である。
【図31】第2実施形態に係るUL通信制御(方法2−4)の他の一例を示すシーケンス図である。
【図32】第2実施形態に係るUL通信制御(方法2−4)の他の一例を示すシーケンス図である。
【図33】第2実施形態に係るUEのUL通信制御(方法2−4)の一例を示すフローチャートである。
【図34】第3実施形態に係るUL通信制御(方法3−3)の一例を示すシーケンス図である。
【図35】第3実施形態に係るUL通信制御(方法3−3)の他の一例を示すシーケンス図である。
【図36】第3実施形態に係るeNB10のUL通信制御(方法3−3)の一例を示すフローチャートである。
【図37】第3実施形態に係るUEのUL通信制御(方法3−3)の一例を示すフローチャートである。
【発明を実施するための最良の形態】
【0017】
以下、図面を参照して実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本実施形態は、その趣旨を逸脱しない範囲で種々変形(各実施例を組み合わせる等)して実施することができる。
〔1〕第1実施形態
図1は、第1実施形態に係る無線(移動)通信システムの一例を示すブロック図である。この図1に例示するシステムは、無線基地局の一例としてのeNB10と、eNB10の無線エリアにおいて無線リンクを介してeNB10と通信する、無線端末(移動局)の一例としてのUE20と、をそなえる。
【0018】
この図1では、1台のeNB10と、1台のUE20とに着目しているが、eNB10及びUE20は、それぞれ、前記無線通信システムにおいて複数存在することができる。前記無線リンクには、DL及びULの無線チャネルが含まれる。前記DL及びULの無線チャネルのそれぞれには、複数のUEにより共有される共有チャネルと、個々のUEが排他的に使用可能な個別チャネルと、が含まれ得る。
【0019】
また、図1中に例示するeNB10及びUE20の構成は、以降の第2及び第3実施形態においても、特に断らない限り、共通で構わない。さらに、本例での無線基地局10は、無線ネットワーク制御装置(RNC)の機能の一部又は全部を具備するLTEでのeNBであることを想定しているが、LTEよりも前の世代での(RNCの機能が組み込まれない)基地局であっても構わない。加えて、RA手順が規定された他のシステムの基地局でもよい。
【0020】
(1.1)eNBの説明
eNB10は、例示的に、送受信アンテナ11と、送受信部12と、バッファ13と、UL同期判定部14と、タイマ管理部15と、ULリソース管理部16と、をそなえる。
送受信アンテナ11(以下、単に「アンテナ11」と表記することもある)は、eNB10が提供する無線エリア(セル又はセクタ)に存在するUE20にて受信され得るDLの無線信号を送信する一方、UE20が送信したULの無線信号を受信する。
【0021】
送受信部12は、UE20宛の送信データ(ユーザデータ、制御データなどが含まれる)に対して所定の送信処理を施して無線チャネルの信号を生成し、送受信アンテナ11へ出力する。前記送信処理には、例示的に、DLの送信データの符号化、符号化データの変調、変調信号の所定チャネルのフレームへのマッピング、フレーム信号の無線周波数への周波数変換(アップコンバート)、無線フレームの電力増幅、などが含まれ得る。前記無線フレームには、例えば、 Orthogonal Frequency Division Multiplexing(OFDM)やOrthogonal Frequency Division Multiple Access(OFDMA)をベースとする無線フレームを適用できる。
【0022】
また、送受信部12は、アンテナ11で受信されたULの無線信号(無線フレーム)について所定の受信処理を施して、UE20が送信したULのデータ(ユーザデータ、制御データなどが含まれる)を取得する。前記受信処理には、例示的に、受信信号の低雑音増幅、ベースバンド周波数への周波数変換(ダウンコンバート)、利得調整、復調、復号などが含まれ得る。なお、送受信部12は、機能的に、送信部と受信部とに別けて備えられてもよい。
【0023】
バッファ部13は、ULの受信データ及び/又はDLの送信データを一時的に保持する。
タイマ管理部15は、ULの同期を確保(維持)するためにUE20へ周期的に送信(通知)する、送信タイミング調整情報の一例としてのTA(Time Alignment)値を生成する。このTA値の生成、通知は、呼設定及びUE20がULのデータ送信に用いる無線リソース(ULリソース)の割当を行なったUE20について行なわれる。
【0024】
TA値は、UE20によるULデータの送信タイミングと、eNB10によるULデータの受信タイミングとを揃える(同期させる)ために用いられる制御情報の一つである。つまり、TA値は、送受信部12において適切なタイミングで受信処理できるように、UE20のULの送信タイミングを調整するのに用いられる。したがって、UE20は、eNB10から受信したTA値に応じてULの送信タイミングを調整することで、ULの同期を確保することができる。
【0025】
UE20は、同じ位置に止まるとは限らないから、TA値は、eNB10とUE20との間の距離(UE20の位置)に応じた可変値となる。故に、UE20がULの同期を確保(維持)するためには、周期的にTA値を更新することが望まれる。
この更新を実現する一例として、eNB10は、周期的にUE20の位置に応じたTA値を生成してUE20に通知する。この通知に用いるDLの制御信号をTAコマンドと呼ぶ。eNB10がUE20の位置を把握するには、UE20から受信されるULの制御信号を用いることができる。この測定に用いる制御信号は、既知の信号、例えばSRS(Sounding Reference Signal)である。
【0026】
また、タイマ管理部15は、UL同期タイマ(TAタイマ)151を有する。このTAタイマ151は、UE20に対するTA値の送信(通知)を契機にスタートする。タイマ管理部15は、そのタイマ値を監視する。UE20はその移動によって位置を変えるから、UE20に通知したTA値はいつまでも有効ではない。そこで、UE20に通知したTA値の有効期限を、TAタイマ151を用いて監視する。TAタイマ151は、新たなTA値の生成、通知を行なう毎にリスタートされる。
【0027】
UL同期判定部(制御部)14は、TAタイマ151(タイマ値)を監視して、ULのデータを受信する場合、あるいはDLのデータを送信する場合ULで確認応答を受信するために、ULの同期が確保(維持)されているか否かを判定する。例えば、TAタイマ151が満了(タイムアウト)した場合は、たとえ実際の(下位レイヤの)UL同期は確保(維持)されていても、UL同期は外れたものと判定する。
【0028】
ULリソース管理部16は、UE20とのUL通信(RA時の通信も含む)に用いるULリソース〔例えば、チャネル周波数や時間(送受信タイミング)など〕と、その割当及び解放とを管理する。前記無線フレームにOFDMA方式のフォーマットを適用する場合であれば、前記無線リソースの管理は、サブチャネル周波数とシンボル時間とで規定される2次元の送受信領域(バーストと呼ばれる)の配置(マッピング)を管理することに相当する。
【0029】
前記ULリソースには、例示的に、UE20に個別のULの制御チャネル(PUCCH:Physical Uplink Control Channel)や、eNB10がチャネル推定や前記UE20の位置測定などを行なうのに用いるSRSのリソースが含まれ得る。また、PUCCHリソースには、UE20が、CQI(Channel Quality Information)や、SRI(Scheduling Request Indicator)をeNB10に送信するのに用いるリソースが含まれ得る。
【0030】
CQIリソースは、UE20の受信状態(品質)をeNB10に報告するために用いられる。eNB10は、UE20から受信したCQIを基にDLの送信(送信データ量、変調方式、符号化率など)を適応的に制御することができる。
SRIリソースは、UL同期が確保されている場合に、UE20にULデータが発生していることをUE20がeNB10に知らせるために用いられる。SRIリソースが未割当のUE20は、RAを実行してULデータの発生をeNB10に知らせることができる。なお、UL同期が確保されていないUE20は、ULデータが発生した場合、RAを実行してULデータの発生をeNB10に知らせることができる。
【0031】
ULリソース管理部16は、TAタイマ151がタイムアウトした場合、UE20に割り当てたPUCCHリソース(CQIリソース、SRIリソース)及びSRSリソースの割当を解放することが許される。
(1.2)UEの説明
一方、図1に示すUE20は、例示的に、送受信アンテナ21と、送受信部22と、バッファ23と、UL同期判定部24と、タイマ管理部25と、ULリソース管理部26と、をそなえる。
【0032】
送受信アンテナ21(以下、単に「アンテナ21」と表記することもある)は、eNB10が提供する無線エリア(セル又はセクタ)においてeNB10へULの無線信号を送信する一方、eNB10が送信したDLの無線信号を受信する。
送受信部22は、eNB10宛のULの送信データ(ユーザデータ、制御データなどが含まれる)に対して所定の送信処理を施して無線チャネルの信号を生成し、送受信アンテナ21へ出力する。前記送信処理には、例示的に、ULの送信データの符号化、符号化データの変調、変調信号の所定チャネルのフレームへのマッピング、フレーム信号の無線周波数への周波数変換(アップコンバート)、無線フレームの電力増幅、などが含まれ得る。
【0033】
また、送受信部22は、アンテナ21で受信されたDLの無線信号(無線フレーム)について所定の受信処理を施して、eNB10が送信したDLのデータ(ユーザデータ、制御データなどが含まれる)を取得する。前記受信処理には、例示的に、受信信号の低雑音増幅、ベースバンド周波数への周波数変換(ダウンコンバート)、利得調整、復調、復号などが含まれ得る。なお、送受信部22は、機能的に、送信部と受信部とに別けて備えられてもよい。
【0034】
バッファ部23は、ULの送信データ及び/又はDLの受信データを一時的に保持する。
タイマ管理部25は、eNB10におけるものと同様のUL同期タイマ(TAタイマ)251を有し、そのタイマ値を管理(監視)することで、TA値の有効期限を監視する。eNB10からTAコマンドが受信された場合、TAタイマ251は、スタート又はリスタートされる。ただし、コンテンションベースRA手順(接続処理)の過程でeNB10から新しいTA値を受信した場合、前記RA手順の開始前にeNB10から受信したTAコマンドのTA値を信頼することとしてもよい。この場合、RA手順の過程で受信したTA値を無視することが許容され、TAタイマ251をリスタートしない制御も許される。また、タイマ管理部25は、メモリ252をそなえ、RA手順の過程でeNB10から受信したTA値を、このメモリ252に、その後の適用にそなえて記憶しておくことができる。
【0035】
UL同期判定部(制御部)24は、TAタイマ251(タイマ値)を監視して、ULのデータ送信を行なう場合に、ULの同期が確保(維持)されているか否かを判定する。TAタイマ251がタイムアウトした場合は、UL同期が外れたと判定する。したがって、RA手順の過程でeNB10から受信したTA値を無視した場合、TAタイマ251がタイムアウトして、RA手順の途中でUL同期が外れたと判定される場合がある。
【0036】
ULリソース管理部26は、eNB10から割り当てられたULリソースと、その解放とを管理する。TAタイマ251がタイムアウトしてUL同期判定部24にてUL同期が外れたと判定された場合、ULリソース管理部26は、割り当てられたULリソースを解放することが許される。
(1.3)コンテンションベースRA手順
以下、上述したeNB10とUE20との間の基本的な接続処理の一例としてのコンテンションベースRA手順について、図2〜図4を用いて説明する。図2は、コンテンションベースRA手順の一例を示すシーケンス図である。図3は、UE20におけるコンテンションベースRA手順の一例を示すフローチャート、図4は、eNB10におけるコンテンションベースRA手順の一例を示すフローチャートである。
【0037】
コンテンションベースRA手順は、UE20においてULデータが発生した場合(UE20の初回送信時)や、UE20宛のDLデータがeNB10に到着してDLデータの着信通知がeNB10から受信された場合などに実行される。図3のフローチャートは、前者のケースを例示しており、図4のフローチャートは、後者のケースを例示している。
図3に例示するように、UE20において、ULデータが発生すると、UE20は、UL同期判定部24により、UL同期が確保されているか否かを判定する(処理1101〜処理1103)。
【0038】
この判定の結果、UL同期が確保されていなければ(処理1103でnoであれば)、UE20は、ULリソース管理部26にて、予め用意されている複数のシグニチャ(プリアンブル)の中から1つを選択する。UE間で同一のシグニチャを選択する可能性を少しでも低下させる趣旨であり、発生させた乱数に応じて選択する等種々の選択方法を採用できる。選択したシグニチャは、メッセージ#1(RAプリアンブル)に含められて、送受信部22からRACHにてeNB10へ送信される(図2の処理1011及び図3の処理1104)。
【0039】
eNB10は、前記メッセージ#1を受信すると、それに対する応答メッセージ#2(RAレスポンス)をUE20に送信する(図2の処理1012)。このRAレスポンス#2には、eNB10が受信(判別)できた1又は複数のシグニチャの識別子、当該シグニチャに対応するULの共有チャネルの送信許可、以降のRA通信の対象(UE20)を識別するために一時的に割り当てる識別子、などを含めることができる。この識別子は、temporary- connection radio network temporary identifier(T-CRNTI)と呼ばれる。
【0040】
UE20は、eNB10からRAレスポンス#2を受信すると(図3の処理1105)、その受信情報に前記メッセージ#1で送信したシグニチャの識別子が含まれるか否かを確認する。
含まれる場合には、UE20は、当該RAレスポンス#2に含まれる、自身が送信したシグニチャに対応する送信許可に基づいて、メッセージ#3の送信(Scheduled Transmission)を行なう(図2の処理1013及び図3の処理1106)。このメッセージ#3は、eNB10に対するスケジューリング要求を含む信号であり、UE20の識別番号の一例としてのsystem architecture evolution(SAE)-temporary mobile subscriber identity(S−TMSI)などを含むことができる。
【0041】
ここで、前記メッセージ#1で、UE20は、シグニチャを選択するが、複数のUE20が、同時に同じシグニチャを用いてメッセージ#1をeNB10に送信してしまうことも起こり得る。
その場合、eNB10では、それらのUE20を判別できないが、UE20が前記メッセージ#3で送信した識別情報(番号)(S−TMSI)を受信することで、どのUE20間でシグニチャの競合が発生したかを認識することができる。したがって、eNB10は、いずれか一のUE20を選択して競合解決することができる。この選択の基準には、メッセージ#1の受信電界強度を用いることができる。例えば、eNB10は、メッセージ#1の受信電界強度が他よりも大きいUE20を選択する。
【0042】
eNB10は、競合解決により選択したUE20に対して、メッセージ#4(Contention Resolution)をUE20へ送信する(図2の処理1014)。このメッセージ#4には、メッセージ#3で送信したS−TMSIなどの情報を含めることができる。
UE20は、eNB10から前記メッセージ#4を受信すると(図3の処理1107)、他UE20との競合の有無をチェック(自身の識別情報が含まれているか否かチェック)し(図3の処理1108)、競合が生じていなければ、ULの接続処理は完了する(図3の処理1108のnoルート)。以後、UE20は、前記一時的に割り当てられた仮の識別子(T-CRNTI)を、確定的な識別子〔C(cell)-RNTI〕としてeNB10との通信に使用する。
【0043】
一方、メッセージ#4を受信した結果、他UE20との競合が生じていた(自身の識別情報が含まれていない)場合(処理1108でyesの場合)、当該UE20は、前記バックオフで指定された時間だけ待機する(処理1111)。バックオフとは、UE20がコンテンションベースRA手順をリトライするタイミング(待機時間)を指定する情報である。
【0044】
バックオフのパラメータはメッセージ#2で通知され、UE20毎に、このバックオフを変えることで、リトライ時に再び競合が発生する確率を低減することができる。具体的には、メッセージ#2で最大バックオフ時間が通知され、UE20は、その時間の範囲内でバックオフ時間を算出する。この算出には、乱数を用いたりする等種々の算出方法を採用できる。
【0045】
そして、UE20は、次回のRA手順のリトライによりリトライ回数が最大回数を超えるか否かをチェックする(処理1112)。超えなければ(処理1112でnoなら)、UE20は、前記処理1103以降の処理を実行して、RA手順をリトライする(メッセージ#1の送信を行なう)。超える場合(処理1112でyesの場合)は、UE20は、上位レイヤにその旨を通知する(処理1113)。前記上位レイヤは、例えば、レイヤ3に属するradio resource control(RRC)レイヤである。
【0046】
前記通知を受けた上位レイヤは、RAの継続(リトライ)を監視する監視タイマを起動する。この監視タイマがタイムアウトすると、UE20の上位レイヤは、ULの接続要求(メッセージ#1の送信)先のeNB10(セル)を選びなおす制御(セル選択制御、あるいはセル再選択制御)を実行する。
なお、前記の処理1103において、UL同期が確保されている場合(処理1103でyesの場合)、UE20は、PUCCHリソース(SRIリソース)が割り当て済みであるか否かをチェックする(処理1109)。割り当て済みであれば(処理1109でyesなら)、UE20は、SRIリソースを用いてSRI(ULデータの送信要求)をeNB10に送信する(処理1110)。
【0047】
SRIリソースが割り当てられていなければ(処理1109でnoなら)、UE20は、eNB10に対するメッセージ#1の送信を行ない、RA手順を実行する。即ち、このように、処理1103において同期が確立されていると判定された場合であっても、SR PUCCHリソースが無い場合には、RA手順が実行されるケースも存在する。
一方、UE20宛のDLデータがeNB10に到着してDLデータの着信通知がeNB10からUE20になされる場合の、eNB10によるRA手順は、図4に例示するとおりである。
【0048】
すなわち、UE20宛のDLデータがeNB10に到着すると(処理1201)、eNB10は、UL同期判定部14により、UL同期が確保されているか否かを判定する(処理1202及び処理1203)。UL同期が確保されていなければ(処理1203でnoなら)、eNB10は、UE20にDLデータが到着したことを通知する(処理1204)。
【0049】
この通知(着信通知)には、個別プリアンブルを含ませることもできるが、本実施例ではUE20に個別のシグニチャ(個別プリアンブル)は含まれない。そのため、前記着信通知を受けたUE20は、上述したコンテンションベースRA手順を実行することになる。その際、以前に割り当てられたULリソースがある場合、そのULリソースは解放され、RA成功後に新たなULリソースがeNB10から割り当てられる。
【0050】
eNB10は、コンテンションベースRA手順を開始したUE20からメッセージ#1(RAプリアンブル)を受信すると(処理1205)、その応答(メッセージ#2)をUE20に返信する(処理1206)。
そして、メッセージ#3をUE20から受信すると(処理1207)、eNB10は、メッセージの衝突があるか否かをチェックし(処理1208)、無ければメッセージ#4をUE20へ送信する(処理1208のnoルートから処理1209)。メッセージの衝突が有れば(処理1208でyesなら)、eNB10は、メッセージ#4の送信は行なわずにRA手順を終了する。
【0051】
以上がコンテンションベースRAの基本的な手順である。ここで、eNB10が、UE20におけるTAタイマ251の値を正確に管理できていない(eNB10のTAタイマ151とUE20のTAタイマ251のタイマ値が同期していない)場合を想定する。
例示的に、UE20のTAタイマ251は計時を継続しているが、eNB10ではその継続を把握していないために、UE20のTAタイマ251はタイムアウトしているとeNB10が誤認識している場合を考える。
【0052】
その一例を図5〜図7(図9〜図11、図13〜図15、図17〜図19)に示す。eNB10は、UE20に対して呼設定及びULリソース(例えば、SRIリソース#1,CQIリソース#1,SRSリソース#1)の割当を行なうと(処理1008)、TAコマンドを周期的にUE20に送信する(処理1009)。このTAコマンド(TA値=TA#1;第1のタイミング調整情報)を受信したUE20は、TAタイマ251をスタートする。
【0053】
UE20が前記TAコマンドで通知されたTA#1に基づいてULの送信を行ない、その送信が終了した後、eNB10にUE20宛のDLデータが到着すると、eNB10は、UE20に対して着信通知(メッセージ#0の送信)を行なう(処理1010)。この着信通知#0を受けたUE20は、ULの同期とリソースとを確保するため、コンテンションベースRA手順を開始する。
【0054】
すなわち、UE20は、選択したシグニチャ(ランダムプリアンブル)を含むメッセージ#1をeNB10に送信し(処理1011)、このメッセージ#1を受信したeNB10は、RAレスポンス#2をUE20に返信する(処理1012)。その際、eNB10は、新しいTA値(TA#2;第2のタイミング調整情報)をRAレスポンス#2に含める。
【0055】
このRAレスポンス#2を受信したUE20は、新しいTA#2を適用してTAタイマ251をリスタートできるが、既述のように当該TA#2を無視することも許される。無視した場合、その後のメッセージ#3の送信(処理1013)とメッセージ#4の受信(処理1014)との間でTAタイマ251がタイムアウトする場合がある。
この場合に、UE20において、UL同期が外れたと判定して、それまでに確保しているULリソースのすべてを解放すると、以後、RACH以外のULデータの送信が不能になる。
【0056】
そこで、本例では、コンテンションベースRA手順の過程でTAタイマ251がタイムアウトした場合に、以下のようにして、UL同期とULリソースとを確保する。なお、以降の説明(後述する他の実施形態も含む)で用いる図面において、同一の処理番号を付した処理は、特に断らない限り、同一若しくは同様の処理を意味する。
(1.4)メッセージ#4の受信時に他UE20との競合が生じていなかった場合
他UE20との競合が生じていなかった場合(RAが成功した場合)、RAを実行したUE20に個別のULリソースが確保できたことを示す。しかし、TAタイマ251はタイムアウトした状態であるため、UL同期が確保できたとはいえない。
【0057】
そこで、UE20は、以下に示す4つの方法1−1〜1−4のいずれかを用いてUL同期を確保する。
(1.4.1)方法1−1(図5〜図8)
UE20は、図8に例示するように、コンテンションベースRA手順の過程で前記メッセージ#2により受信したTA値(TA#2)をタイマ管理部25のメモリ252に記憶しておく(処理1105a)。
【0058】
なお、UE20(ULリソース管理部26)は、UL同期外れを認識した場合、コンテンションベースRAを開始する前に受信したTA#1に基づく送信処理に用いていた(RA開始前にeNB10から割り当てられた)ULリソースを解放することができる。
この解放のタイミングは、例えば、図5に例示するように、前記着信通知メッセージ#0を受信したタイミング(UL同期の管理がeNB10と一致していないことを認識したタイミング)(処理2001)でもよいし、図6に示すように、TAタイマ251がタイムアウトしたタイミング(処理2002)でもよい。ただし、図7に例示するように、TAタイマ251がタイムアウトしても、当該ULリソースの解放は行なわずに確保(継続使用)したままにすることもできる(処理2003)。
【0059】
その後、UE20は、コンテンションベースRA手順を継続して、メッセージ#4の受信に成功すると、UE20は、メモリ252に記憶したTA値(TA#2)をUL送信に適用するとともに、TAタイマ251をリスタートする(処理1108のnoルートから処理1114)。
つまり、TA#2の適用は、TAタイマ251のタイムアウト後、RAの過程においてUE20が、自身の識別情報の一例としてのT-CRNTIを含むメッセージ#2(応答信号)を受信したことを契機として許容される。なお、「TA値を適用する」とは、TA値で示される送信タイミングに基づいてULの送信(RAの実行)を制御することを意味する。この制御は、例えばUL同期判定部24の一機能として実現することができる(以降において同様)。
【0060】
この際、TAタイマ251の値は、規定値としてもよいし、メッセージ#2の受信タイミングに基づいて設定することもできる。例えば、UL同期はメッセージ#2の受信時に既に成功していたことにして、規定値からメッセージ#2の受信からメッセージ#4の受信までに要した時間を差し引いてTAタイマ251の値を設定してもよい。これは、メッセージ#2によりTA#2の通知を受けてからRAの結果が通知されるまでの時間だけタイマ値(タイミング調整情報の有効期限)を早めることを意味する。
【0061】
このように、本例では、UE20が、TA#1に基づいてeNB10に対するRAを行なっている場合に、そのRAの過程で、TA#2を受信すると、TAタイマ251のタイムアウト(TA#1の有効期限)までの送信処理に対しては、TA#1を送信タイミングの調整に適用する。TAタイマ251のタイムアウト後(TA#1の有効期限後)の送信処理に対しては、TA#2を送信タイミングの調整に適用する。
【0062】
これによれば、TA#2による送信タイミングの即時更新を行なわなくとも、TA#1の有効期限が過ぎた後(タイムアウトした後)、TA#2を適用して送信制御を行なうことができる。
その後、UE20は、メッセージ#4に対する確認応答メッセージ(ACK又はNACK)をeNB10に返信する(処理1015)。eNB10は、メッセージ#4に対する確認応答メッセージとしてACKを受信すれば、新たなULリソース(例えば、SRIリソース#2,CQIリソース#2,SRSリソース#2)をUE20に割り当てる(処理1016)。
【0063】
なお、図7に例示するように、UE20のTAタイマ251がタイムアウトしてもULリソースの解放を行なわない場合に、UE20は、既に確保しているULリソースを継続使用してもよいが、これに代わる新たなULリソースの割り当てをeNB10に要求することもできる(処理1017)。
UE20は、割り当てられたULリソースをULリソース管理部26において管理し、以後、当該ULリソースを用いてeNB10に対するUL送信を行なう。
【0064】
(1.4.2)方法1−2(図9〜図12)
第2の方法として、図9〜図12に例示するように、UE20は、メッセージ#2で受信したTA値(TA#2)をメモリ252に記憶しておく(処理1105a)。その後、メッセージ#3の送信(処理1013)からメッセージ#4の受信(処理1014)までの間にTAタイマ251がタイムアウトしたとする。
【0065】
この場合、UE20は、メッセージ#4の受信を待たずに、メモリ252に記憶したTA値(TA#2)をUL送信に適用して、TAタイマ251をリスタートする(図12の処理1161のyesルートから処理1162)。リスタートのタイミングは、TAタイマ251のタイムアウトと同時としてよい。つまり、メッセージ#2で受信したTA#2の適用は、TAタイマ251のタイムアウト(TA#1の有効期限)のタイミングで許容される。
【0066】
これによれば、TA#2による送信タイミングの即時更新を行なわなくとも、TA#1の有効期限が過ぎた時(タイムアウトした時)、TA#2を適用して送信制御を行なうことができる。
(1.4.3)方法1−3(図13〜図16)
第3の方法として、図13〜図16に例示するように、eNB10が、メッセージ#4を送信する際には、新しいTA値(TA#3)を含めることとする(図13〜図15の処理1014a、図16の処理1107a)。
【0067】
つまり、UE20が、TA#1(第1の送信タイミング調整情報)に基づいてeNB10に対するRAを行なっている場合に、そのRAの過程で、eNB10は、UE20に送信するメッセージ#4(UE20の識別情報の一例としてのS−TMSIを含む信号)に、TA#3(第2の送信タイミング調整情報)を含める。
UE20は、このメッセージ#4をeNB10から受信すると、当該メッセージ#4に含まれるTA値(TA#3)をUL送信に適用して、TAタイマ251をスタートする(図16の処理1114)。
【0068】
即ち、通常であれば、移動局の識別情報が含まれるメッセージ#4には、TA値は含まれないが、この実施例では、メッセージ#4にTA値を含めることで、メッセージ#2で受信したTA#2を無視したUE20が、メッセージ#4のTA値をその後の送信タイミングの調整情報として適用し、TAタイマ251をスタートさせることができる。
なお、本例において、UE20は、前記無視したTA#2をメモリ252に記憶しておいてもよい。
【0069】
(1.4.4)方法1−4(図17〜図20)
第4の方法として、図17〜図20に例示するように、UE20は、eNB10からメッセージ#2で受信したTA値(TA#2)を記憶するか否かに関わらず、メッセージ#2の受信を契機としてTAタイマ251をリスタートする。
この場合、UE20は、RA手順開始以前にeNB10から受信したTA値(TA#1)を、その後のRA(UL送信)に適用することを継続する(図20の処理1105b)。これは、RA開始前にeNB10からTAコマンドで受信したULの送信タイミングの有効期限をRAの過程で延長させるようTAタイマ251を制御することに相当する。
【0070】
つまり、UE20は、TA#1に基づいてeNB10に対するRAを行なっている場合に、そのRAの過程で、TA#2を受信すると、TA#2を適用せずに、TA#1を継続して適用するとともに、TA#1の有効期限を延長する。
なお、延長する期間(TA#2についてのTAタイマ251の値)は、規定値としてもよいし、メッセージ#2の受信タイミングに基づいて設定することもできる。例えば、UL同期はメッセージ#2の受信からTA#1のタイムアウトまでに要した時間を差し引いてTAタイマ251の値を設定してもよい。
【0071】
本例によれば、TA#2の受信後もTA#1を引き続き延長して利用することができ、送信タイミングの調整に適用することができる。
(1.5)メッセージ#4の受信時に他UE20との競合が生じていた場合
メッセージ#4の受信時に他UE20との競合が生じている場合は、他UE20が用いるULリソースとの重複が発生しており、自局20に個別のULリソースは確保できなかったことを意味する。
【0072】
そのため、UE20は、RACH以外のULのデータ送信を行なえないので、コンテンションベースRAのリトライを実行して、UL同期の確保を試みる(図3の処理1108のyesルート)。
〔2〕第2実施形態
上述した第1実施形態では、UE20がメッセージ#3を送信してからメッセージ#4をeNB10から受信するまでの間に、UE20のTAタイマ251がタイムアウトした場合を想定した。本実施形態では、UE20がeNB10からメッセージ#2を受信してからeNB10に対してメッセージ#3を送信するまでの間に、UE20のTAタイマ251がタイムアウトする場合を想定する。
【0073】
例えば、図21〜図23、図25〜図27及び図30〜図32に例示するように、eNB10にUE20宛のDLデータが到着して、UE20に着信通知(処理1010)が行なわれると、コンテンションベースRA(メッセージ#1の送信:処理1011)が実行される。この場合に、eNB10からメッセージ#2でTA値(TA#2)を受信したUE20が、当該TA#2を無視すると、メッセージ#3(UE20の識別情報の一例としてのS−TMSIを含む信号)の送信までにTAタイマ251がタイムアウトする場合がある。
【0074】
このような場合、UE20(UL同期判定部24)は、UL同期が外れたと判定するが、以下の方法2−1〜2−4のいずれかにより、RAを継続する。
(2.1)方法2−1(図21〜図24)
UE20において、UL同期が外れたと判定した場合、本来的にはメッセージ#3の送信は行なえない。しかし、TAタイマ251は、物理レイヤにおけるUL同期が外れない範囲のフェイルセーフに設定される場合が多い。したがって、TAタイマ251がタイムアウトしても、実際の(下位レイヤの)UL同期は確保できている場合もある。
【0075】
そこで、本例では、UE20がeNB10からメッセージ#2を受信(処理1012)した後にTAタイマ251がタイムアウトしたとしても、当該UE20は、eNB10に対するメッセージ#3の送信(強制送信)を試行する(図21〜図23の処理1013a、図24の処理1105c及び処理1106a)。即ち、タイムアウトしたが、TA#1を適用してメッセージ#3を送信することができる。なお、TA#2は、メモリ252に記憶しておく。
【0076】
つまり、UE20は、TA#1に基づいてeNB10に対するRAを行なっている場合に、そのRAの過程で、TA#1の有効期限がメッセージ#3の送信処理を行なう前に到来すると、TA#1の有効期限の到来以前にTA#2を受信していたとしても、メッセージ#3のeNB10への送信処理をTA#1に基づいて実行することができる。
これにより、メッセージ#3をeNB10が受信できれば、UE20は、コンテンションベースRAを最初からやり直さずに、以後のRA手順を継続することが可能となる。即ち、UE20は、メッセージ#3に対する応答信号として自身の識別情報を含むメッセージ#4の受信に成功すれば、TA#2をその後の送信処理の送信タイミングの調整に適用して、TAタイマ251をスタートすることができる。したがって、ULデータ送信開始までの遅延を低減することができる。
【0077】
ただし、eNB10は、UE20がメッセージ#3を強制送信した、いわば規定違反を犯したことを認識できるので、メッセージ#4で接続拒否メッセージをUE20に送信することもできる。つまり、eNB10は、TA#1の有効期限が過ぎた後にUE20からTA#1に基づいて送信されたメッセージ#3を受信した場合に、拒否メッセージをUE20に送信することができる。
【0078】
この場合、UE20は、セル選択・再選択を実行したり、RA手順のリトライを実行する。あるいは、eNB10は、メッセージ#4を意図的に送信しないこともできる。この場合、UE20は、許容されている再送回数(通常の最大再送回数、あるいは、この場合のみに適用される最大再送回数)に達するまでメッセージ#3の再送を継続する。
(2.2)方法2−2(図25〜図28)
UE20は、図25〜図27に例示するように、メッセージ#2(TA#2)を受信(処理1012)した後、メッセージ#3をeNB10へ送信(処理1013)する前に、TAタイマ251が満了した場合、メッセージ#3の送信はキャンセルして、実行中のコンテンションベースRA手順を中止(キャンセル)する(処理1018)。
【0079】
つまり、UE20は、TA#1に基づいてeNB10に対するRAを行なっている場合に、そのRAの過程で、TA#1の有効期限が、UE20の識別情報の一例としてのS−TMSIを含む信号の送信処理を行なう前に到来すると、TA#1の有効期限が到来する以前にTA#2を受信していても、RAを中止する。
この場合、UE20は、図28に例示するように、バックオフを適用して、コンテンションベースRAのリトライを実行する(処理1105dのyesルート)。すなわち、RAのリトライは、中止したRAの過程でeNB10から受信したバックオフ時間(待機時間情報)に基づくタイミングで実行される。UE20は、図25〜図27に例示するように、メッセージ#1の送信(処理1011)、メッセージ#2(TA#3)の受信(処理1012)などを行なう。
【0080】
ここで、メッセージ#2(TA#2)を受信した時点でTAタイマ251はタイムアウトしている(起動していない)。したがって、UE20は、リトライしたRAの過程でメッセージ#2により受信した新しいTA#3をその後のUL送信の送信タイミングの調整に適用して、TAタイマ251をスタートすることができる。メッセージ#4の受信時にRAの敗者であること(衝突発生)を認識した場合は、TAタイマ251は強制終了してよい(図25〜図27の処理2004)。
【0081】
本例のように、TAタイマ251がタイムアウトした時点で、RA手順を中止してRAのリトライを実行することで、残りの手順(例えば、メッセージ#3の送信及びメッセージ#4の受信)を最後まで実施するよりも、ULデータ送信開始までの遅延を低減することができる。
(2.3)方法2−3(図25〜図27、図29)
なお、上述のごとくTAタイマ251がタイムアウトして、コンテンションベースRAをリトライする場合、図29に例示するように、UE20は、バックオフを適用せずに前記リトライを行なってもよい(処理1105dのyesルート)。
【0082】
即ち、UE20は、RAのリトライを、中止したRAの過程でeNB10から受信したバックオフ時間を適用しないで実行することができる。バックオフを適用しないことで、バックオフを適用する場合よりもULデータ送信開始までの遅延を低減することが可能となる。
(2.4)方法2−4(図30〜図33)
また、図30〜図32に例示するように、TAタイマ251がタイムアウトした場合、UE20は、バックオフの適否に関わらず、上位レイヤ(例えば、RRCレイヤ)に通知を行なってもよい(処理1021、図33の処理1105dのyesルートから処理1113)。
【0083】
これにより、UE20の上位レイヤはRAの監視タイマを起動し、RA手順の継続(リトライ)を監視する。つまり、UE20は、TAタイマ251のタイムアウト(TA#1の有効期限の到来)に応じて、RAの監視を行なう。RAの継続中に、監視タイマがタイムアウトすると、UE20の上位レイヤは、セル選択、あるいはセル再選択処理を実行する(図30〜図32の処理1022)。
【0084】
したがって、UE20は、早期に他のセル(eNB10)とのRAを開始することができ、ULデータ送信開始までの遅延を低減することができる。なお、TAタイマ251のタイムアウトに応じた上位レイヤによるRAの監視は、前記の方法2−1〜2−3に適用してもよい。
〔3〕第3実施形態
次に、本実施形態では、eNB10が、UE20におけるTAタイマ251のタイマ値を正確に管理できている場合(eNB10及びUE20の両TAタイマ151,251が同期している場合)を想定する。この場合、UE20のTAタイマ251の計時が継続していることを、eNB10は認識できるから、UE20は、eNB10から受信されるTA値を信頼してよい。さらに、第1実施形態および第2実施形態とは異なり、eNB10からTA値が送信されることが期待できる。
【0085】
そして、UE20がTAコマンドにより受信したTA値に基づくULデータの送信を終了した後、eNB10にUE20宛のDLデータが到着すると、eNB10は、当該UE20に対して着信通知(メッセージ#0の送信)を行なう。
これにより、当該着信通知を受信したUE20は、コンテンションベースRA手順を開始する。その後、メッセージ#2の受信(処理1012)からメッセージ#3の送信(処理1013)までの間に、UE20のTAタイマ251がタイムアウトすると、UE20は、以下の方法3−1〜3−3のいずれかによりUL同期を確保する。
【0086】
(3.1)方法3−1
UE20は、第1実施形態で述べた方法1−2(図9〜図12)と同様に、RA手順の過程でeNB10からメッセージ#2で受信したTA値をメモリ252に記憶しておく。そして、メッセージ#3をeNB10に送信する前にTAタイマ251がタイムアウトすると、メモリ252に記憶しておいたTA値をUL送信に適用して、TAタイマ251をスタートする。
【0087】
(3.2)方法3−2
UE20は、第2実施形態で述べた方法2−1〜2−4のいずれかを実行する。
(3.3)方法3−3(図34〜図37)
図34及び図35に例示するように、UE20は、TA#1に基づいてeNB10に対するRAを行なっている場合に、そのRAの過程で、UE20の識別情報の一例としてのS−TMSIを含む信号(メッセージ#3)を送信する(処理1013)。
【0088】
eNB10は、UE20のTAタイマ251がタイムアウトする前に、このメッセージ#3をUE20からRAの過程で受信すると(処理1013)、当該メッセージ#3の受信を契機として、新しいTA値(TA#3;第2のタイミング調整情報)を含むTAコマンドをUE20へ送信する(処理1009a、図36の処理1208a)。
一方、UE20は、RAの実行中においてもTAコマンドの受信を監視(モニタ)する。例えば、eNB10にメッセージ#3を送信(処理1013)した後は、eNB10からのTAコマンドの受信を監視する。この監視中に、TAコマンドをeNB10から受信すると(処理1009a、図37の処理1161)、UE20(タイマ管理部25)は、受信したTAコマンドのTA値(TA#3)をUL送信に適用して、TAタイマ251をスタートする(図37の処理1162)。
【0089】
なお、UE20におけるULリソースの管理は、第1又は第2実施形態と同様でよい。例えば、eNB10からDLデータの着信通知(メッセージ#0)を受信したタイミングで、それまでに確保しているULリソースを解放してもよいし、TAタイマ251がタイムアウトしたタイミングで当該ULリソースを解放してもよい。また、TAタイマ251がTA#3を受信する以前にタイムアウト(TA#1の有効期限が到来)しても、それまでに確保していたULリソースは解放せずに維持(継続使用)することも可能である(図35の処理2005)。
【0090】
また、UE20は、メッセージ#3の送信からメッセージ#4の受信までの間に、TAタイマがタイムアウトした場合、第1実施形態と同様の形態(方法1−1〜方法1−4のいずれか)を適用することができる。
【符号の説明】
【0091】
10 無線基地局(eNB)
11 送受信アンテナ
12 送受信部
13 バッファ部
14 UL同期判定部
15 タイマ管理部
151 UL同期タイマ(TAタイマ)
16 ULリソース管理部
20 無線端末(UE)
21 送受信アンテナ
22 送受信部
23 バッファ部
24 UL同期判定部
25 タイマ管理部
251 UL同期タイマ(TAタイマ)
252 メモリ
26 ULリソース管理部

【特許請求の範囲】
【請求項1】
移動局と基地局とを備えた移動通信システムにおけるタイミング調整方法において、
前記移動局は、第1の上り送信制御情報を有し前記基地局に対する接続手順を行なっている場合に、第2の上り送信制御情報の受信を含む該接続手順の過程で、該第1の上り送信制御情報の適用時間を制御するタイマが、該移動局の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止する、
ことを特徴とする、タイミング調整方法。
【請求項2】
上り送信制御情報に基づいて、送信手順を行なう移動局と、該移動局から送信された信号を受信する基地局とを備えた移動通信システムにおいて、
前記移動局は、
第1の上り送信制御情報を有し前記基地局に対する接続手順を行なう送信処理部と、
第2の上り送信制御情報の受信を含む該接続手順の過程で、該第1の上り送信制御情報の適用時間を制御するタイマが、該移動局の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止するようにする制御部と、を備える
ことを特徴とする、移動通信システム。
【請求項3】
移動局と、該移動局から送信された信号を受信する基地局とを備えた移動通信システムにおける該移動局において、
第1の上り送信制御情報を有し前記基地局に対する接続手順を行なう送信処理部と、
第2の上り送信制御情報の受信を含む該接続手順の過程で、該第1の上り送信制御情報の適用時間を制御するタイマが、該移動局の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止するようにする制御部と、を備える
ことを特徴とする、移動局。
【請求項4】
上り送信制御情報に基づいて、送信手順を行なう移動局と、該移動局から送信された信号を受信する基地局とを備えた移動通信システムにおける該基地局において、
第1の上り送信制御情報を有し前記基地局に対する接続手順を行なう送信処理部と、
第2の上り送信制御情報の受信を含む該接続手順の過程で、該第1の上り送信制御情報の適用時間を制御するタイマが、該移動局の識別情報を含む信号の送信を行なう前に満了すると、前記接続手順を中止するようにする制御部と、
を有する前記移動局から送信された信号を受信する受信処理部、を備える
ことを特徴とする、基地局。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20】
image rotate

【図21】
image rotate

【図22】
image rotate

【図23】
image rotate

【図24】
image rotate

【図25】
image rotate

【図26】
image rotate

【図27】
image rotate

【図28】
image rotate

【図29】
image rotate

【図30】
image rotate

【図31】
image rotate

【図32】
image rotate

【図33】
image rotate

【図34】
image rotate

【図35】
image rotate

【図36】
image rotate

【図37】
image rotate


【公開番号】特開2013−21724(P2013−21724A)
【公開日】平成25年1月31日(2013.1.31)
【国際特許分類】
【出願番号】特願2012−229338(P2012−229338)
【出願日】平成24年10月16日(2012.10.16)
【分割の表示】特願2011−52981(P2011−52981)の分割
【原出願日】平成20年6月2日(2008.6.2)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】