特開2019-220986(P2019-220986A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

▶ 株式会社NTTドコモの特許一覧
特開2019-220986ユーザ装置、及びランダムアクセス方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2019-220986(P2019-220986A)
(43)【公開日】2019年12月26日
(54)【発明の名称】ユーザ装置、及びランダムアクセス方法
(51)【国際特許分類】
   H04W 72/04 20090101AFI20191129BHJP
   H04W 74/04 20090101ALI20191129BHJP
【FI】
   H04W72/04 136
   H04W72/04 137
   H04W74/04
【審査請求】有
【請求項の数】3
【出願形態】OL
【全頁数】33
(21)【出願番号】特願2019-159515(P2019-159515)
(22)【出願日】2019年9月2日
(62)【分割の表示】特願2016-105565(P2016-105565)の分割
【原出願日】2016年5月26日
(31)【優先権主張番号】特願2016-42819(P2016-42819)
(32)【優先日】2016年3月4日
(33)【優先権主張国】JP
(71)【出願人】
【識別番号】392026693
【氏名又は名称】株式会社NTTドコモ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100124844
【弁理士】
【氏名又は名称】石原 隆治
(72)【発明者】
【氏名】高橋 秀明
(72)【発明者】
【氏名】内野 徹
(72)【発明者】
【氏名】ウリ アンダルマワンティ ハプサリ
【テーマコード(参考)】
5K067
【Fターム(参考)】
5K067AA23
5K067EE02
5K067EE10
5K067HH22
(57)【要約】
【課題】ランダムアクセス手順において、ユーザ装置が、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避する。
【解決手段】基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置において、所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、前記選択部により選択されたランダムアクセス信号を前記基地局に装置する送信部と、を備え、前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信する。
【選択図】図8
【特許請求の範囲】
【請求項1】
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、
共通制御チャネルで送信されるRRCConnectionRequest message、RRCConnectionReestablishmentRequest message、及びRRC connection resume messageのうちのいずれか一つであるCommon Control Channel Service Data Unit(CCCH SDU)にMACヘッダとを加えたサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、
前記選択部により選択されたランダムアクセス信号を前記基地局に送信する送信部と、を備え、
前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記CCCH SDUを前記共通制御チャネルで送信する
ことを特徴とするユーザ装置。
【請求項2】
前記MACヘッダを加えたCCCH SDUのサイズが前記所定の閾値よりも大きい場合に、前記選択部は、2つのランダムアクセス信号グループのうち、前記サイズが前記所定の閾値よりも大きい場合に対応するランダムアクセス信号グループを選択する
ことを特徴とする請求項1に記載のユーザ装置。
【請求項3】
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、
共通制御チャネルで送信されるRRCConnectionRequest message、RRCConnectionReestablishmentRequest message、及びRRC connection resume messageのうちのいずれか一つであるCommon Control Channel Service Data Unit(CCCH SDU)にMACヘッダとを加えたサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択ステップと、
前記選択ステップにより選択されたランダムアクセス信号を前記基地局に送信する送信ステップと、
前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記CCCH SDUを前記共通制御チャネルで送信する送信ステップと
を備えることを特徴とするランダムアクセス方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、無線通信システムにおいてユーザ装置(以下、UE)と基地局(以下、eNB)との間で実行されるランダムアクセス手順に関連するものである。
【背景技術】
【0002】
LTE等の無線通信システムでは、UEがeNBとの接続を確立する場合や、再接続(再同期)を行う場合等にランダムアクセス(以下、RAと略記する場合がある)手順が実行される。RA手順には、衝突型RA手順と、非衝突側RA手順がある。衝突型RA手順は、全ての目的に使用でき、非衝突側RA手順はハンドオーバ等の特定の目的に使用される。ここでは、衝突型RA手順を対象とする。
【0003】
RA手順では、UEがeNBにRA preambleを送信し、eNBがUEにRA responseを返す。そして、UEは、RA responseの中のUL grantで割り当てられた上りリソースを用いて制御メッセージをeNBに送信する。この制御メッセージはMessage 3(メッセージ3)と呼ばれる(非特許文献1)。
【0004】
Message 3では、接続時にはRRCConnectionRequest messageが、再接続時にはRRCConnectionReestablishmentRequest messageが、logical channel(論理チャネル)であるCCCH(Common Control Channel、共通制御チャネル)で送られる。
【0005】
RRCConnectionRequest message、RRCConnectionReestablishementRequest messageは、標準仕様上、総称してCCCH SDU(Service Data Unit)とも呼ばれる。RRCConnectionRequest message、RRCConnectionReestablishmentRequest messageのサイズは共に48ビットであり、これにMAC headerの8ビットが付加され、MAC PDUとしては56ビットになる。すなわち、56ビットのデータが、物理レイヤ(PHY)で送信可能な1つのTransport Block(トランスポートブロック)となり、そのサイズ(56ビット)がTransport Block Size (TBS)となる。
【先行技術文献】
【非特許文献】
【0006】
【非特許文献1】3GPP TS 36.300 V12.8.0 (2015-12)
【非特許文献2】3GPP TS 36.321 V12.8.0 (2015-12)
【非特許文献3】3GPP TR 23.720 V1.2.0(2015-11)
【非特許文献4】3GPP R2-161745
【非特許文献5】3GPP TS 36.331 V12.8.0 (2015-12)
【発明の概要】
【発明が解決しようとする課題】
【0007】
Message 3のTBSとして56ビットよりも大きな値を割り当てることもできる。この場合、例えばPadding BSR(Padding Buffer Status Report)などがデータに付加される。LTEでは、RA preambleをグルーピングし、グループの中から選択されたRA preambleを用いてUEがRA手順を行うことが規定されている(非特許文献2)。eNBは、送信されたRA preambleが属するグループにより、Message 3のサイズが大きくなるか否かを判定し、該当TBSをRA responseでUEに通知することができる。
【0008】
具体的には、非特許文献2に記載されているように、Preamble group A/Bが設けられる。そして、Preamble group Bが存在し、システム情報で設定されたmessage size(messageSizeGroupA in RACH-ConfigCommon)よりもMessage 3のsizeが大きく、かつパスロスが所定の値以下である場合にPreamble group Bの中からRA preambleが選択される。そうでない場合は、Preamble group Aの中からRA preambleが選択される。
【0009】
ところで、UEがアイドル状態にあるときにeNB/UEでUEコンテクストを保存しておき、接続状態に遷移する際に、保存したUEコンテクストを用いることで、接続のためのシグナリング量を削減する仕組みが検討されている。例えば、非特許文献3にはsolution 18として、その例が記載されている。
【0010】
本仕組みにおいて、保存したUEコンテクストを用いてRRC connectionを再開するために、UEがMessage 3で再開要求メッセージを送信する。このメッセージには、接続を再開するために用いるIDや認証情報が加えられるため、メッセージサイズが、既存のCCCH SDUのTBSの56ビットを超える可能性がある(例えば、非特許文献4)。
【0011】
従って、メッセージサイズの異なる複数のCCCH SDUが規定される可能性がある。メッセージサイズの異なる複数のCCCH SDUが規定される場合、UEは、手順に応じて、異なるサイズのCCCH SDUをeNBに送信する。例として、UEは、通常のRRC connection requestを56ビットのTBSで送信し、RRC connection resumeを64ビットのTBSで送信するといったことが想定される。
【0012】
従来はCCCH SDUのメッセージサイズは1つ(TBS:56ビット)であったが、メッセージサイズが異なるCCCH SDUが規定されると、eNBは、RA responseでMessage 3のUL grantを割当てるまでに、CCCH SDUのサイズを考慮してUL grantで割り当てるTBSを決める必要がある。しかし、従来の仕組みでは、eNBがCCCH SDUのメッセージサイズをRA responseの送信前に知ることができないため、CCCH SDUのサイズを考慮してUL grantで割り当てるTBSを決めることができない。このため、例えば、UEが、再開要求メッセージを送信しようとしても、TBSが不足して、送信できないといったことが発生し得る。
【0013】
なお、上記のような課題は、再開要求メッセージ以外の制御メッセージを送信する場合にも生じ得る課題である。
【0014】
本発明は上記の点に鑑みてなされたものであり、ランダムアクセス手順において、ユーザ装置が、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避する技術を提供することを目的とする。
【課題を解決するための手段】
【0015】
本発明の実施の形態によれば、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、
共通制御チャネルで送信されるRRCConnectionRequest message、RRCConnectionReestablishmentRequest message、及びRRC connection resume messageのうちのいずれか一つであるCommon Control Channel Service Data Unit(CCCH SDU)にMACヘッダとを加えたサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、
前記選択部により選択されたランダムアクセス信号を前記基地局に送信する送信部と、を備え、
前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記CCCH SDUを前記共通制御チャネルで送信する
ことを特徴とするユーザ装置が提供される。
【発明の効果】
【0016】
本発明の実施の形態によれば、ランダムアクセス手順において、ユーザ装置が、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避する技術が提供される。
【図面の簡単な説明】
【0017】
図1】本発明の実施の形態における通信システムの構成図である。
図2】ランダムアクセス手順を示す図である。
図3】コンテクスト保持方式例1の処理シーケンスを示す図である。
図4】コンテクスト保持方式例1の処理シーケンスを示す図である。
図5】コンテクスト保持方式例2の処理シーケンスを示す図である。
図6】実施例1における仕様変更例を示す図である。
図7】実施例1における仕様変更例を示す図である。
図8】実施例2における処理手順を示すフローチャートである。
図9】実施例2における仕様変更例を示す図である。
図10】実施例2における仕様変更例を示す図である。
図11】実施例2における仕様変更例を示す図である。
図12】実施例2における仕様変更例を示す図である。
図13】実施例2の変形例を説明するための図である。
図14】実施例2の変形例における処理手順を示すフローチャートである。
図15】実施例2の変形例における仕様変更例を示す図である。
図16】実施例2の変形例における仕様変更例を示す図である。
図17】実施例2の変形例における仕様変更例を示す図である。
図18】実施例2の変形例における仕様変更例を示す図である。
図19】実施例3における処理手順を示すフローチャートである。
図20】実施例3における仕様変更例を示す図である。
図21】実施例3における仕様変更例を示す図である。
図22】実施例3における仕様変更例を示す図である。
図23】実施例4における処理手順を示すフローチャートである。
図24】UEの構成図である。
図25】UEのHW構成図である。
図26】eNBの構成図である。
図27】eNBのHW構成図である。
【発明を実施するための形態】
【0018】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態では、LTEのシステムを対象としているが、本発明はLTEに限らずに適用可能である。また、本明細書及び特許請求の範囲では、特に断らない限り、「LTE」の用語は3GPPの特定のRel(リリース)に限定されない。また、「LTE」は「5G」を含むこととする。また、本実施の形態で説明する処理において、「以下」と「より小さい」は実質的に同じであり、どちらを用いても良い。
【0019】
(システム全体構成)
図1は、本発明の実施の形態における通信システムの構成例を示す図である。図1に示すように、本実施の形態の通信システムは、eNB10、eNB20、MME30、S−GW(Serving Gateway)40、UE50を含む。
【0020】
UE50は携帯電話機等のユーザ装置である。eNB10、20はそれぞれ基地局である。MME30は、eNBを収容し、位置登録、ページング、ハンドオーバ等のモビリティ制御、ベアラ確立/削除等を行うノード装置である。S−GW40は、ユーザデータ(U−Planeデータ)の中継を行うノード装置である。なお、MME30とS−GW40からなるシステムを通信制御装置と呼ぶ。また、MME30とS−GW40を1つの装置で構成し、それを通信制御装置と呼ぶこととしてもよい。
【0021】
図1に示すように、MME30とeNB10、20間はS1−MMEインターフェースで接続され、S−GW40とeNB10、20間はS1−Uインターフェースで接続される。点線の接続線は制御信号インターフェースを示し、実線の接続線はユーザデータ転送のインターフェースを示す。
【0022】
本発明に係る技術は、前述したUEコンテクスト保持方式における接続再開時のランダムアクセスに限らずに適用可能であるが、本実施の形態では、本発明の適用例の1つとして、UEコンテクスト保持方式を用いている。
【0023】
本実施の形態では、UEコンテクスト保持方式の例として、非特許文献3に記載されている方式であるRRC-Suspended(及びECM-Suspended)という新しいRRCの状態を定義する方式(コンテクスト保持方式1)と、新たなRRCの状態を定義することなくUEコンテクストの再利用を行う方式(コンテクスト保持方式2)を説明している。これらのシーケンスの例は後述する。
【0024】
(ランダムアクセス手順について)
本実施の形態では、ユーザ装置(UEと呼ぶ)と基地局eNB(eNBと呼ぶ)との間のランダムアクセス手順を対象としていることから、まず、ランダムアクセス手順の基本的な処理を説明する。
【0025】
ランダムアクセス(以下、RA)は、UEが、発信時等において、eNBと接続を確立する場合に行われ、その主な目的は上り同期を確立することである。既に説明したように、RA手順には、衝突型RA手順と、非衝突側RA手順がある。衝突型RA手順は、全ての目的に使用でき、非衝突側RA手順はハンドオーバ等の特定の目的に使用される。本実施の形態では、衝突型RA手順を対象とする。
【0026】
図2を参照して衝突型RA手順を説明する。UEは、所定数のRA preamble(系列)の中から1つの系列を使用して、PRACH(Physical Random Access Channel)により、RA preamble(選択した系列)を送信する(ステップS1)。同時刻に同系列を使用してランダムアクセスを行う他のUEが存在しなければ衝突は生じない。
【0027】
ステップS2において、eNBは、DL−SCH(下り共有チャネル)を利用して、UEの送信タイミングを調整するためのTA(timing advance)コマンド、検出したRA preambleのインデックス、上りリソース割り当て情報(UL grant)等を含むRA response(レスポンス)をUEに送信する。
【0028】
RA responseを受信したUEは、上りのタイミングを調整し、割り当てられたリソースを用いてCCCHにより、RRC connection request等の制御メッセージをeNBに送信する(ステップS3)。
【0029】
RA preambleを送信したUEが、RA responseを受信できなかった場合については(ランダムアクセス試行が失敗した場合)、UEは、1回失敗するたびに、所定のステップサイズだけ送信電力を上げてPRACHを送信する。このような動作はPower Rampingと呼ばれる。
【0030】
ステップS4において、eNBは、contention resolution(競合解決メッセージ)を送信する。contention resolutionを受信したUEは、自分のID(例:TC−RNTI、ステップS3でスクランブルに使用したもの)が含まれていることを確認することで、ランダムアクセス処理を完了し、以降、データの送受信を行う。
【0031】
(コンテクスト保持方式のシーケンス例について)
次に、本実施の形態におけるシステムの動作例として、前述したコンテクスト保持方式に係る動作を説明する。以下では、コンテクスト保持方式1とコンテクスト保持方式2を説明する。
【0032】
<コンテクスト保持方式1>
まず、コンテクスト保持方式1について説明する。コンテクスト保持方式1では、従来のRRC-Idle(RRCアイドル状態)とRRC-Connected(RRC接続状態)に加えて、RRC-Suspended(RRC保留状態と呼ぶ)という状態が追加されている。RRC保留状態において、UEとeNBはそれぞれ、RRC保留状態になる前のRRC接続状態で接続に使用したUEコンテクストを保持する。そして、RRC保留状態からRRC接続状態に遷移するときに、当該保持したUEコンテクストを使用してRRC接続確立をする。
【0033】
まず、コンテクスト保持方式1における通信システム全体のシーケンス例として、UE50が、RRCアイドル状態からRRC保留状態(及びECM保留状態)に遷移する場合の処理シーケンスを図3を参照して説明する。
【0034】
ステップS11において、eNB10は、RRC接続を保留することを決定する。ステップS12において、eNB10は、UE50のRRC接続が保留されたことを示すメッセージをMME30に送信する。MME10とeNB30はUEコンテクストを保持する。
【0035】
ステップS13、S14でのメッセージを経て、ステップS15において、MME30はステップS12に対するAckを返す。ステップS16で、MME30はECM-SUSPENDEDの状態に入る。
【0036】
ステップS17では、eNB10はUE50にRRC connection suspendメッセージを送信し、UE50をRRC保留状態にする(ステップS18)。RRC connection suspendメッセージには、Resume ID(再開ID)が含まれる。Resume IDは、次にRRC接続を再開する場合に使用される識別子である。RRC保留状態において、UE50とeNB10はそれぞれ、UEコンテクストを格納する。
【0037】
ここで、本実施の形態において、UE50とeNB10のそれぞれで保持されるUEコンテクストは、例えば、RRCコンフィギュレーション(RRC configuration)、ベアラコンフィギュレーション(bearer configuration: RoHC state information等を含む)、ASセキュリティコンテクスト(Access Stratum Security Context)、L2/L1パラメータ(MAC、PHYのコンフィギュレーション等)等である。
【0038】
UE10とeNB10はそれぞれUEコンテクストとして上記のような情報を保持することで、RRC保留状態からRRC接続状態に遷移する際に、RRC Connection Setup Complete、RRC Security Mode Command、RRC Security Mode Complete、RRC Connection Reconfiguration、RRC Connection Reconfiguration Complete、等のメッセージの送受信を行うことなくRRC接続確立を行うことができる。
【0039】
次に、UE50が、RRC保留状態からRRC接続状態に遷移する場合のシーケンス例を図4を参照して説明する。図4は、RRC保留状態(ステップS51)にあるUE50が着信を受ける(ステップS52〜S55)ケースを示しているが、これは例であり、RRC保留状態にあるUE50が発信をする場合も、UEコンテクストの再利用に関しては同様の処理が行われる。
【0040】
eNB10からページングを受信したUEにおいて、ステップS56では、EMMレイヤから、RRC再開手順(resume procedure)が起動される。ステップS57にてRandom Access PreambleがUE50からeNB10に送信され、ステップS58にて、Random Access ResponseがeNB10からUE10に返される。
【0041】
ステップS59では、メッセージ3として、UE50は、RRC Connection Resume RequestメッセージをeNB10に送信する。
【0042】
当該RRC Connection Resume Requestメッセージには、UE50がUEコンテクストを保持することを示す情報であるResume Id(再開ID)、認証情報等が含まれる。RRC Connection Resume Requestメッセージを受信したeNB10は、当該メッセージに含まれるResume Idに対応付けて格納されている、UE50のUEコンテクストを取得し、UEコンテクストの情報に基づき、ベアラの再開等を行う。ステップS60では、eNB10は、UE50に対してResume Idを含むRRC Connection Resume Completeメッセージを送信する。
【0043】
ステップS61では、UE50とeNB10は、格納したセキュリティコンテクストを再開する。そして、ステップS62〜S65において、MME30に対するUE50の状態変更の通知等が行われる。
【0044】
<コンテクスト保持方式2>
次に、コンテクスト保持方式2について説明する。前述したとおり、コンテクスト保持方式2は、RRC-Suspendedのような新しい状態を定義することなく、RRCアイドル状態において、UEとeNBがUEコンテクストを保持し、RRC接続状態に遷移する際に、保持したUEコンテクストを再利用することで、シグナリング数削減を可能とする方式である。
【0045】
コンテクスト保持方式2における通信システム全体のシーケンス例として、RRCアイドル状態のUE50に対する着信がある場合に、MME30からページングを行う方式について説明する。より具体的には、UE50がeNB10に接続してRRC接続状態となり、eNB10の配下のセルでRRCアイドル状態となり、同一セルで、その後に着信を受ける場合の処理シーケンスを図5を参照して説明する。
【0046】
図5の処理の前提として、UE50はeNB10のセルにおいてRRC接続状態にあり、UE50に関するS1−C/Uのコネクションが確立されている状態とする。図5において、S1−Cコネクションは、eNB10とMME30との間のコネクションとMME30とS−GW40間のコネクションを含み、S1−Uコネクションは、eNB10とS−GW40間のコネクションを含む。コネクションが確立されている場合、コネクション確立信号等のコネクションセットアップのための手順を実行することなく、該当ノード装置間でUE50に係る信号(データ)を送受信できる。
【0047】
図5の手順の説明に入る前に、UE50が最初にeNB10に接続する際の手順の一例の概要を説明しておく。なお、この最初の接続に係る手順は、コンテクスト保持方式1にも適用できる。UE50のランダムアクセス時に、eNB10は、RRC Connection SetupをUE50に送信し、UE50をRRC接続状態とし、UE50からRRC Connection Setup Completeを受信する。その後、eNB10は、MME30からInitial Context Setup Requestを受信し、UE50に対してRRC Security Mode Commandを送信し、UE50からRRC Security Mode Completeを受信し、また、UE50に対してRRC Connection Reconfigurationを送信し、UE50からRRC Connection Reconfiguration Completeを受信し、MME30に対してInitial Context Setup Responseを送信する。このような手順を経て、UE50とeNB10におけるUEコンテクストの確立、保持等がなされる。
【0048】
図5に示すように、RRC接続状態において、eNB10はMME30に対してコネクション維持指示信号を送信する(ステップS71)。また、MME30はコネクション維持指示信号をS−GW40に送信する(ステップS72)。
【0049】
コネクション維持指示信号は、当該UE50に関するS1−C/Uコネクションを維持しながら、UE50への着信時に下りデータをS−GW40に保留して、MME30からページングを行うことを指示する信号である。
【0050】
コネクション維持指示信号を受信したS−GW40は、指示を確認したことを示す確認応答をMME30に送信し(ステップS73)、MME30は、確認応答をeNB10に送信する(ステップS74)。
【0051】
UE50に関するeNB10からMME30へのコネクション維持指示信号の送信は、例えば、eNB10において、UE50をRRCアイドル状態に遷移させる事象が発生したことをトリガーとして行ってもよいし、UE50が最初にeNB10の配下でRRC接続状態になり、当該UE50に関するS1−C/Uコネクションが確立された直後に行うこととしてもよい。
【0052】
上記のRRCアイドル状態に遷移させる事象とは、例えば、所定のタイマ(例:UE Inactivity Timer)の満了によって、UE50との通信(上り下りのユーザデータ通信)が一定時間発生しないことを検知した場合であるが、これに限られるわけではない。
【0053】
図5は、UE50との通信(上り下りのユーザデータ通信)が一定時間発生しないことを検知したことをトリガーとする場合を想定しており、ステップS71〜S74の後に、RRC接続解放(RRC Connection Release)をUE50に送信し、UE50をRRCアイドル状態に遷移させる(ステップS75)。UE50が、RRCアイドル状態に遷移する場合でも、UE50とeNB10のそれぞれにおいて、RRC接続時に確立したUEコンテクストは保持される。
【0054】
その後、UE50向けの下りデータが発生し、当該下りデータがS−GW40に到着する(ステップS76)。ここでは、S1−Uコネクションは確立済みであるが、ステップS72で受信したコネクション維持指示信号に基づき、S−GW40は、当該下りデータをeNB10に転送せずにバッファに保留しておく。
【0055】
S−GW40は、下りデータ着信通知をMME30に送信し(ステップS77)、MME30はUE50向けのS1−APページングの信号をeNB10に送信する(ステップS78)。このページング自体は、既存のページングと同様であり、UE50のトラッキングエリアの各eNBに送信されるが、図5ではeNB10への送信を示している。
【0056】
S1−APページングの信号を受信したeNB10は、配下のUE50にRRCページングの信号を送信する(ステップS79)。
【0057】
RRCページング信号を受信したUE50は、RRC接続確立手順を実行し、RRC接続を確立させる(ステップS80)。その後、eNB10は、RRC接続の確立が完了したことを示す信号であるRRC接続確立完了をMME30に送信する(ステップS81)。
【0058】
MME30はRRC接続確立完了の信号をS−GW40に送信する(ステップS82)。これにより、S−GW40はUE50とeNB10間のRRC接続が確立したと判断し、既に確立されているUE50に係るS1−Uコネクションを利用して、保留していた下りデータのeNB10への転送を開始する(ステップS83)。当該下りデータはeNB10からUE50に届く(ステップS84)。このようにしてUE50への下りデータの伝送が開始される。
【0059】
図5のステップS80のRRC接続確立手順では、UE50とeNB10のそれぞれで保持しておいたUEコンテクストが利用されるので、従来は必要であった、RRC Security Mode Command、RRC Security Mode Complete、RRC Connection Reconfiguration、RRC Connection Reconfiguration Complete、等のメッセージの送受信を行うことなくRRC接続確立を行うことができる。
【0060】
以下、前述したランダムアクセス手順における課題を解決する方式として、実施例1〜4を説明する。つまり、UEが、Message 3を送信しようとしても、TBSが不足して、送信できないといったことを回避する方式の例として、実施例1〜4を説明する。以下の各実施例における全体のランダムアクセス手順は図2に示したとおりの手順である。また、以下では、ユーザ装置をUEと呼び、基地局をeNBと呼ぶことにする。
【0061】
(実施例1)
まず、実施例1を説明する。実施例1では、UEは、ランダムアクセス手順において、RA preamble group A/Bの中からRA preamble groupを選択する際に、既存のRA preamble group Bを選択する条件に外れる場合でも、CCCH SDUのサイズ(MACヘッダを加えたサイズ)が、messageSizeGroupAよりも大きい場合には、RA preamble group Bを選択し、RA preamble group Bの中からRA preambleを選択して送信する。
【0062】
上記の手順はRA preamble group Bが存在する場合に行われる。つまり、UEがeNBからSIB2メッセージ(又はRRC個別メッセージ)を受信し、当該メッセージの中のRACH-ConfigCommonにおいて、sizeOfRA-PreamblesGroupA(GroupAのプリアンブル数)がnumberOfRA-Preambles(全プリアンブル数)と等しくなければ、UEは、RA preamble group Bが存在すると判定する。messageSizeGroupAは、RACH-ConfigCommonの中のパラメータであり、RA preamble group A/Bの選択判定における、メッセージサイズ(Message 3のサイズ)との比較対象となる閾値である。
【0063】
図6に、実施例1のUEの動作に対応する仕様書(3GPP TS 36.321)の記載例(抜粋)を示す。図6において、非特許文献2からの変更箇所に下線が引かれている。
【0064】
図6に記載のとおりRA preamble group A/Bのいずれかを選択する判定条件において、RA preamble group Bを判定する条件の中に、CCCH SDU sizeがmessageSizeGroupAより大きい場合という条件をORで付け加えている。
【0065】
すなわち、この仕様書に準拠する実施例1のUEは、図2に示したステップS1を行う前に、まず、RA preamble group Bが存在するかどうかを判定し、存在する場合に、以下の処理を行う。
【0066】
まず、UEは、Message 3として送信しようとするメッセージ(ULデータ+MACヘッダ、必要に応じて、+MAC CE)のサイズがmessageSizeGroupAより大きく、かつ、パスロスが所定の値以下であるかどうかを判定し、判定結果がYesであれば、RA preamble group Bを選択する。
【0067】
また、UEは、CCCH SDU size(MAC PDUとしてのサイズ)が、messageSizeGroupAよりも大きいか否かを判定し、判定結果がYesであれば、RA preamble group Bを選択する。なお、本実施の形態(実施例1〜4)におけるCCCH SDU sizeは、MAC header を加えたサイズであることを明示的に記載しない場合でも、MAC headerを加えたサイズを意味する。ただし、これに代えて、MAC headerを含まないCCCH SDUのサイズを用いてもよい。
【0068】
上記のいずれの判定結果もNoであれば、UEは、RA preamble group Aを選択する。
【0069】
そして、UEは、選択したグループの中のRA preambleからランダムに1つのRA preambleを選択してeNBに送信する(図2のステップS1)。
【0070】
eNBでは、例えば、RA preamble group BのRA preambleを受信したことを判別すると、RA preamble group AのRA preambleを受信する場合よりも大きなTBSをULリソースとして割り当てて、UL grantを含むRA responseをUEに送信する(図2のステップS2)。これにより、UEは、例えば、56ビットよりも大きなMessage 3をeNBに送信することができる。
【0071】
図7は、実施例1のUEの動作に対応する仕様書(3GPP TS 36.321)の記載(抜粋)の他の例を示す。図7に示す例は、messageSizeGroupAと比較するサイズが、「CCCH SDU size+MAC header」のサイズであることを明確に記載した例である。すなわち、当該仕様書の動作を実行するUEは、"ランダムアクセス手順がCCCH論理チャネルに対して開始され、かつ、「CCCH SDU size+MAC header」が、messageSizeGroupAよりも大きい"か否かを判定し、判定結果がYesであれば、RA preamble group Bを選択する。この部分以外は、図6と同じである。なお、「ランダムアクセス手順がCCCH論理チャネルに対して開始される」とは、例えば、RRCConnectionRequest message、RRCConnectionReestablishmentRequest message、RRC connection resume message等の送信のためにランダムアクセス手順が開始される(initiated)ことに相当する。
【0072】
なお、実施例1において、eNBからUEに通知するmessageSizeGroupAの値は特定の値に限定されないが、例えば、56ビットである。
【0073】
実施例1は、現行の56ビットのTBSに加えて、1つだけ追加のCCCH SDU sizeが規定される場合に、特に適している。ただし、2つ以上の追加のCCCH SDU sizeが規定される場合でも、実施例1の技術を使用することは可能である。
【0074】
(実施例2)
次に、実施例2を説明する。実施例2では、新たに追加されるCCCH SDU size用に新しくRA preamble groupを設けることとしている。例えば、1つだけCCCH SDU sizeを追加する場合、Group Cを新しく追加する。つまり、この場合、UEがランダムに選択可能な複数プリアンブル(例:64個、RACH-ConfigCommonのnumberOfRA-Preamblesで通知される値)が3つのグループ(Group C、Group B、Group C)に分けられる。
【0075】
実施例2におけるUEのRA preamble選択の動作例(図2のステップS1の直前の動作)を図8のフローチャートを参照して説明する。このフローチャートの前提として、UEは、SIB2メッセージ(又はRRC個別メッセージ)を受信し、当該メッセージの中のRACH-ConfigCommonにより、閾値等の各パラメータを取得、保持しているものとする。また、UEは、パラメータにより、Group CとGroup Bが存在することを把握しているとする。また、以下の「Group Cのmessage size」は、eNBからUEに通知されるパラメータの1つである。
【0076】
UEは、例えば、前述した接続再開のためのメッセージをMessage 3としてeNBに送信したい場合において、ランダムアクセス手順を開始する。
【0077】
ステップS101において、例えば、UEは、RA PreambleがeNBからexplicitly にシグナリングされていないことを把握して、MACレイヤでのRA preamble選択処理を開始する。
【0078】
ステップS102において、UEは、送信しようとするmessage size (CCCH SDU + MAC header)がGroup Cのmessage sizeと等しいかどうかを判定する。判定結果がYesであれば、ステップS104に進み、Group Cを選択し、Group Cの中からRA preambleを選択する。
【0079】
ステップS102での判定結果がNoである場合にはステップS103に進む。ステップS103において、UEは、Potential message size(ULデータ+MACヘッダ、必要に応じて、+MAC CE)がGroup Cのmessage sizeより大きく、かつ、パスロスが所定の値以下であるかどうかを判定する。判定結果がYesであれば、ステップS105に進み、Group Bを選択し、Group Bの中からRA preambleを選択する。なお、Potential message sizeは、Message 3として送信予定のメッセージのサイズである。
【0080】
ステップS103での判定結果がNoである場合にはステップS106に進み、Group Aを選択し、Group Aの中からRA preambleを選択する。
【0081】
例えば、新たなCCCH SDU + MAC headerが64ビットであるとした場合、eNBは、Group CのRA preambleをUEから受信した場合において、64ビットのTBSをUEに割り当てる。また、この場合、eNBは、Group BのRA preambleをUEから受信した場合において、64ビットよりも大きなTBS(例:80ビット)をUEに割り当てる。また、Group AのRA preambleをUEから受信した場合において、64ビットよりも小さなTBS(例:56ビット)をUEに割り当てる。
【0082】
図9に、実施例2のUEの動作に対応する仕様書(3GPP TS 36.321, 5.1.1)の記載例(抜粋)を示す。図9において、非特許文献2からの変更箇所に下線が引かれている。
【0083】
図9に示すように、RA Preambles group A、RA Preambles group B、及びRA Preambles group Cに含まれるプリアンブルは、numberOfRA-Preambles、sizeOfRA-PreamblesGroupA、及びsizeOfRA-PreamblesGroupCのパラメータから計算されることが規定されている。また、RA Preambles Group Cが存在する場合に、RA Preamble Group Cのプリアンブルは、sizeOfRA-PreamblesGroupAからnumberOfRA-PreamblesC - 1 までであり、RA Preamble Group Bのプリアンブルは、sizeOfRA-PreamblesGroupCからnumberOfRA-Preambles - 1までであることが規定されている。
【0084】
図10に、実施例2のUEの動作に対応する仕様書(3GPP TS 36.321、5.1.2)の記載例(抜粋)を示す。図10において、非特許文献2からの変更箇所に下線が引かれている。
【0085】
図10に示す記載例は、図8に示したフローチャートの内容に対応する。なお、図10に示すように、Group Cが存在しない場合には、従来と同様に、potential message sizeがGroup Aのmessage size以上かつパスロスが所定の値以下でGroup Bが選択される。
【0086】
図11図12は、実施例2のUEの動作に対応する仕様書(3GPP TS 36.331)の記載例(抜粋)を示す。図11図12において、非特許文献5からの変更箇所に下線が引かれている。
【0087】
図11に示すように、RACH-ConfigCommon information elementにおいて、sizeOfRA-PreamblesGroupC、messageSizeGroupC、messagePowerOffsetGroupB等のパラメータが追加されている。messageSizeGroupCは、判定で使用される閾値(GroupCのmessage size)である。図12に示すように、sizeOfRA-PreamblesGroupCは、GroupCのサイズ(プリアンブル数)である。
【0088】
なお、実施例2では、1つのグループが新たに追加される場合を例に説明したが、2つ以上のグループが新たに追加される場合でも同様の処理を実現できる。その場合は、図8のフローにおいて、message size (CCCH SDU + MAC header)とパラメータ(Group Cのmessage size等)とが等しいかどうかの判定が追加グループ毎に行われる。
【0089】
(実施例2の変形例)
次に、実施例2の変形例を説明する。実施例2の変形例では、図13に示す5つのパターンに分けられるように、4つのRA preamble groupを設けることとしている。なお、この例では、RA preamble group Aのmessage sizeを56ビットとし、RA preamble group Cのmessage sizeを80ビットとしているが、これは一例である。これらの値は、RACH-ConfigCommonによりパラメータとしてeNBからUEに通知される。本例では、UEがランダムに選択可能な複数プリアンブルが4つのグループ(Group D、Group C、Group B、Group C)に分けられる。
【0090】
実施例2の変形例におけるUEのRA preamble選択の動作例(図2のステップS1の直前の動作)を図14のフローチャートを参照して説明する。このフローチャートの前提として、UEは、SIB2メッセージ(又はRRC個別メッセージ)を受信し、当該メッセージの中のRACH-ConfigCommonにより、閾値等の各パラメータを取得、保持しているものとする。また、UEは、パラメータにより、Group CとGroup Bが存在することを把握しているとする。
【0091】
UEは、例えば、前述した接続再開のためのメッセージをMessage 3としてeNBに送信したい場合において、ランダムアクセス手順を開始する。
【0092】
ステップS201において、例えば、UEは、RA PreambleがeNBからexplicitly にシグナリングされていないことを把握して、MACレイヤでのRA preamble選択処理を開始する。
【0093】
ステップS202において、UEは、Potential message size(ULデータ+MACヘッダ、必要に応じて、+MAC CE)がGroup Cのmessage sizeより大きく、かつ、パスロスが所定の値以下であるかどうかを判定する。判定結果がYesであれば、ステップS204に進み、Group Bを選択し、Group Bの中からRA preambleを選択する。
【0094】
ステップS202での判定結果がNoである場合にはステップS203に進む。ステップS203において、UEは、送信しようとするMessage 3のmessage size (CCCH SDU + MAC header)がGroup Cのmessage size(例:80ビット)と等しいかどうかを判定する。判定結果がYesであれば、ステップS205に進み、Group Cを選択し、Group Cの中からRA preambleを選択する。
【0095】
ステップS203での判定結果がNoである場合にはステップS206に進む。ステップS206において、UEは、「Potential message size(ULデータ+MACヘッダ、必要に応じて、+MAC CE)がGroup Cのmessage sizeより小さく、かつ、Potential message size(ULデータ+MACヘッダ、必要に応じて、+MAC CE)がGroup Aのmessage size(例:56ビット)より大きく、かつ、パスロスが所定の値以下」であるかどうかを判定する。判定結果がYesであれば、ステップS207に進み、Group Dを選択し、Group Dの中からRA preambleを選択する。判定結果がNoであれば、ステップS208に進み、Group Aを選択し、Group Aの中からRA preambleを選択する。
【0096】
例えば、新たなCCCH SDU + MAC headerが80ビットであり、既存の(Group A)のメッセージサイズが56ビットであるとした場合、eNBは、Group CのRA preambleをUEから受信した場合において、80ビットのTBSをUEに割り当てることが考えられる。また、eNBは、Group BのRA preambleをUEから受信した場合において、80ビットよりも大きなTBSをUEに割り当てる。また、Group AのRA preambleをUEから受信した場合において、56ビットのTBSをUEに割り当てる。また、Group DのRA preambleをUEから受信した場合において、56ビットよりも大きく、80ビットよりも小さなTBS(例:64ビット)をUEに割り当てる。
【0097】
図15に、実施例2の変形例のUEの動作に対応する仕様書(3GPP TS 36.321, 5.1.1)の記載例(抜粋)を示す。図15において、非特許文献2からの変更箇所に下線が引かれている。
【0098】
図15に示すように、RA Preambles group A、RA Preambles group B、RA Preambles group C、及びRA Preambles group Dに含まれるプリアンブルは、numberOfRA-Preambles、sizeOfRA-PreamblesGroupA、及びsizeOfRA-PreamblesGroupCのパラメータから計算されることが規定されている。また、RA Preambles Group C、RA Preambles Group Dが存在する場合に、RA Preamble Group Cのプリアンブルは、sizeOfRA-PreamblesGroupAからnumberOfRA-PreamblesC - 1 までであり、RA Preamble Group Dのプリアンブルは、sizeOfRA-PreamblesGroupCからnumberOfRA-PreamblesD - 1までであり、RA Preamble Group Bのプリアンブルは、sizeOfRA-PreamblesGroupDからnumberOfRA-Preambles - 1までであることが規定されている。
【0099】
図16に、実施例2の変形例のUEの動作に対応する仕様書(3GPP TS 36.321、5.1.2)の記載例(抜粋)を示す。図16において、非特許文献2からの変更箇所に下線が引かれている。
【0100】
図16に示す記載例は、図14に示したフローチャートの内容に対応する。なお、図16に示すように、Group Cが存在しない場合には、従来と同様に、potential message sizeがGroup Aのmessage size以上かつパスロスが所定の値以下でGroup Bが選択される。
【0101】
図17図18は、実施例2の変形例のUEの動作に対応する仕様書(3GPP TS 36.331)の記載例(抜粋)を示す。図17図18において、非特許文献5からの変更箇所に下線が引かれている。
【0102】
図17に示すように、RACH-ConfigCommon information elementにおいて、sizeOfRA-PreamblesGroupC、messageSizeGroupC、messagePowerOffsetGroupB、sizeOfRA-PreamblesGroupD等のパラメータが追加されている。messageSizeGroupCは、判定で使用される閾値(GroupCのmessage size)である。図18に示すように、sizeOfRA-PreamblesGroupCは、GroupCのサイズ(プリアンブル数)である。
【0103】
なお、実施例2の変形例では、2つのグループが新たに追加される場合を例に説明したが、3つ以上のグループが新たに追加される場合でも同様の処理を実現できる。
【0104】
(実施例3)
次に、実施例3を説明する。実施例3では、CCCH SDU size毎に異なる64個のRA preamble resource(PRACH resource)が用意される。64個は例である。UEは、その個数を、eNBからのシステム情報又はRRC個別シグナリングに基づいて決定することができる。以下では、64個であるとして説明する。なお、CCCH SDU sizeとRA preamble resourceとは1対1に対応している必要はなく、例えば、1対N(Nは2以上の整数)の対応であってもよい。
【0105】
UEは、Zadoff-chu系列からRA preamble系列を生成する。UEは、そのRA preamble系列を上記のRA preamble resourceと見なすことができる。この場合、異なる64個のRA preamble系列がそれぞれ、CCCH SDUのサイズに対応する。例えば、UEは、72ビットのCCCH SDUのメッセージを送信する場合に、80ビットに対応するRA preamble系列1を送信し、56ビットのCCCH SDUのメッセージを送信する場合に、56ビットに対応するRA preamble系列2を送信する。
【0106】
また、例えば、RA preamble系列は、CCCH SDU sizeに拠らずに同一として、RA preamble系列を送信する周波数・時間リソースをCCCH SDU sizeに対応付けることとしてもよい。この場合は、当該周波数・時間リソースが上記のRA preamble resourceに相当する。この場合、例えば、UEは、80ビットのCCCH SDUのメッセージを送信する場合に、80ビットに対応する周波数・時間リソース1でRA preambleを送信し、56ビットのCCCH SDUのメッセージを送信する場合に、56ビットに対応する周波数・時間リソース2でRA preambleを送信する。
【0107】
CCCH SDU sizeとRA preamble resourceとの対応関係の情報は、eNBからUEに対して、システム情報又はRRC個別シグナリングにより通知される。UEは当該対応関係の情報を保持し、当該対応関係と、送信しようとするMessage 3のCCCH SDU sizeとに基づいて、RA preamble resourceを決定する。
【0108】
eNBは、CCCH SDU sizeとRA preamble resourceとの対応関係を保持しており、UEから受信するRA preamble resourceに基づき、Message 3でUEが送信しようとしているCCCH SDU sizeを把握できる。これにより、CCCH SDU sizeに応じたTBSの割り当てをRA responseで行うことができる。
【0109】
実施例3におけるUEのRA preamble選択の動作例(図2のステップS1の直前の動作)を図19のフローチャートを参照して説明する。このフローチャートの前提として、UEは、eNBから受信したシステム情報(又はRRC個別メッセージ)から、CCCH SDU sizeとRA preamble resourceとの対応関係の情報を取得し、保持しているとする。
【0110】
UEは、例えば、前述した接続再開のためのメッセージをMessage 3としてeNBに送信したい場合において、ランダムアクセス手順を開始する。
【0111】
ステップS301において、例えば、UEは、RA PreambleがeNBからexplicitly にシグナリングされていないことを把握して、MACレイヤでのRA preamble選択処理を開始する。
【0112】
ステップS302において、UEは、送信しようとするMessage 3のCCCH SDU sizeが、システム情報又は個別のRRCシグナリング内で通知された所定のmessage sizeと等しいかどうかを判定する。つまり、システム情報又は個別のRRCシグナリング内で通知された上記の対応関係の中のmessage sizeのリストの中に、CCCH SDU sizeと等しいmessage sizeがあるか否かを判定する。
【0113】
ステップS302の判定結果がYesの場合、ステップS303に進み、UEは、CCCH SDU sizeと等しいmessage sizeに対応するPRACH resource(一般には複数のPRACH resourceがある)を使用可能なPRACH resourceとみなす。そして、ステップS305において、UEは、使用可能なPRACH resourceの中からRA preambleのリソースを選択して、RA preambleを送信する。
【0114】
ステップS302での判定結果がNoの場合、ステップS304に進み、システム情報若しくは個別のRRCシグナリングで通知された従来のPRACH resourceを使用可能なPRACH resourceとみなして、ステップS305に進む。
【0115】
図20に、実施例3のUEの動作に対応する仕様書(3GPP TS 36.321, 5.1.1)の記載例(抜粋)を示す。図20において、非特許文献2からの変更箇所に下線が引かれている。
【0116】
図20に示すように、RA手順の開始にあたって、UEは、Message 3の各message sizeに対応付けられた使用可能なPRACH resourceのセットを把握している。これは、prach-ConfigIndexにより示される。
【0117】
図21に、実施例3のUEの動作に対応する仕様書(3GPP TS 36.321, 5.1.2)の記載例(抜粋)を示す。図21において、非特許文献2からの変更箇所に下線が引かれている。
【0118】
図21に示すように、Message 3にCCCH SDUが含まれ、CCCH SDU sizeがMessageSizePrachInfoList(所定のサイズのリスト)の中のMessageSizeOfMsg3に示されている場合に、UEは、そのサイズに対応するリソース(PRACH-ParametersMsgSize) を使用可能なPRACH resourcesと見なす。そうでなければ、PRACH-ConfigSIB又はPRACH-Configで示されるリソースを使用可能なPRACH resourcesと見なす。
【0119】
図22は、実施例3のUEの動作に対応する仕様書(3GPP TS 36.331)の記載例(抜粋)を示す。図22において、非特許文献5からの変更箇所に下線が引かれている。図22に示すように、上記のMessageSizePrachInfoList、PRACH-ParametersMsgSize等がPRACH-Config information elementsに追加されている。これらの情報が、前述したCCCH SDU sizeとRA preamble resourceとの対応関係の情報に相当する。
【0120】
(実施例4)
次に、実施例4を説明する。実施例4では、UEが、RRC connectionを再開(resume)する場合(例:図4のステップS56〜S59、図5のステップS80)、UEは、RRCレイヤで再開を要求するメッセージ(従来のMsg.3より大きいサイズ)と同時に従来のMsg.3 size (56 bits TBS)のRRC Connection request message(もしくはRRC Connection reestablishment request message)も作成する。そして、UEは、両方のメッセージを下位レイヤに送り出す。
【0121】
UEは、MACレイヤにおいて、割り当てられたTBSに応じて、従来のMsg.3より大きいサイズの再開を要求するメッセージを送るか、従来のMsg.3 sizeのRRC connection request message(もしくはRRC Connection reestablishment request message)を送るかを選択する。
【0122】
例えば、図4のケースでは、ステップS56で、UEがRRC接続再開を開始すると、UEは、RRC connection resume request messageを作成するとともに、RRC Connection request messageも作成する。そして、UEは、MACレイヤにおいて、ステップS58で受信するUL grantで割り当てられたTBSに応じて、RRC connection resume request messageかRRC Connection request messageのいずれかを送信するかを判断する。例えば、TBSが、RRC connection resume request messageを送信することができるサイズである場合に、RRC connection resume request messageを送信する。この場合は、以降、図4に示す手順が行われる。一方、TBSが、RRC connection resume request messageを送信することができるサイズではない場合に、RRC Connection request message(もしくはRRC Connection reestablishment request message)を送信する。この場合は、以降、従来のRRC Connection request message(もしくはRRC Connection reestablishment request message)送信時の手順と同様の手順が実行される。
【0123】
実施例4におけるUEのRRC接続再開時の動作例を図23のフローチャートを参照して説明する。なお、図23は、RRC接続再開のためのメッセージとしてRRC connection resume request messageを使用する。これは、図4での新規メッセージであると考えてもよいし、既存のメッセージを拡張したもの(例:図5のステップS80で使用するメッセージ)であると考えてもよい。
【0124】
ステップS401において、UEは、RRCレイヤでRRC connection resume request messageを作成すると同時に、既存のRRC connection request messageも作成する。ステップS402において、UEは、Message 3に割り当てられたTBSでRRC connection resume requestを送信可能か否かを判定する。
【0125】
ステップS402での判定結果がYesであれば、ステップS403でRRC connection resume request messageを送信する。Noである場合、TBSは56ビットであることが想定され、ステップS404で既存のRRC connection request messageを送信する。
【0126】
実施例4では、例えば、無線品質が良い場合であれば、大きなTBSの割り当てを期待でき、その場合はRRC connection resume request messageを送信できる。また、通常のTBSの割り当てを受ける場合でも、RRC connection request messageを送信することができる。すなわち、RA手順において、UEが、eNBから割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避することができる。
【0127】
実施例4では、RRC connection request messageとRRC connection resume request messageを同時に作成する例を示したが、このようなサイズの異なる複数のメッセージを同時に作成し、大きなメッセージ送信可能であればそれを送信する処理は、RRC connection request messageとRRC connection resume request messageに限らずに適用可能である。
【0128】
実施例1〜実施例4(実施例2の変形例を含む、以下同様)の全部又はいずれか複数は矛盾の生じない限り組み合わせて実施することができる。
【0129】
(装置構成例)
次に、本発明の実施の形態におけるUEとeNBの装置構成例を説明する。以下で説明する各装置の構成は、発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともLTEに準拠した通信システムにおける装置として動作するための図示しない機能も有するものである。また、各図に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。
【0130】
各装置は、実施例1〜実施例4の全ての機能を備えてもよいし、実施例1〜実施例4のうちのいずれか1つの実施例の機能又は変形例の機能を備えることとしてもよいし、実施例1〜実施例4のうちのいずれか複数の機能を備えることとしてもよい。以下の説明では、各装置は実施例1〜実施例4の機能を備えるものとする。
【0131】
<ユーザ装置UE>
図24に、UEの機能構成図を示す。図24に示すように、UEは、DL信号受信部51、UL信号送信部52、プリアンブル選択部53、RRC処理部54、UEコンテクスト管理部55を備える。なお、図24は、UEにおいて本発明に特に関連する機能部のみを示すものであり、UEは、少なくともLTEに準拠した動作を行うための図示しない機能も有するものである。
【0132】
DL信号受信部51は、基地局eNBから各種の下り信号を受信し、受信した物理レイヤの信号からより上位のレイヤの情報を取得する機能を含み、UL信号送信部52は、UE50から送信されるべき上位のレイヤの情報から、物理レイヤの各種信号を生成し、基地局eNBに対して送信する機能を含む。
【0133】
プリアンブル選択部53は、実施例1〜2で説明したロジックでMACレイヤでのプリアンブルの選択を行う。なお、プリアンブル選択部53は、UL信号送信部52の中に備えられていてもよい。また、プリアンブル選択部53は、実施例3におけるRA preamble送信のためのリソース選択を行う。
【0134】
RRC処理部54は、RRCメッセージの生成・送信(送信はUL信号送信部52を介した送信)、DL信号受信部51により受信したRRCメッセージの解釈等を行う。実施例3において、RRC処理部54は、対応関係の情報を取得・保持する。実施例4において、RRC処理部54は、RRC connection request messageとRRC connection resume request messageを同時に作成する。また、実施例4において、TBSに基づき、RRC connection request messageとRRC connection resume request messageのいずれを送信するかを判定する機能は、UL信号送信部52に含まれている。
【0135】
UEコンテクスト管理部55は、メモリ等の記憶手段を含み、RRC保留状態/RRCアイドル状態においてUEコンテクストを保持する。
【0136】
図24に示すUEの構成は、全体をハードウェア回路(例:1つ又は複数のICチップ)で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をCPUとプログラムとで実現してもよい。
【0137】
図25は、UEのハードウェア(HW)構成の例を示す図である。図25は、図24よりも実装例に近い構成を示している。図25に示すように、UEは、無線信号に関する処理を行うRE(Radio Equipment)モジュール151と、ベースバンド信号処理を行うBB(Base Band)処理モジュール152と、上位レイヤ等の処理を行う装置制御モジュール153と、USIMカードにアクセスするインタフェースであるUSIMスロット154とを有する。
【0138】
REモジュール151は、BB処理モジュール152から受信したデジタルベースバンド信号に対して、D/A(Digital−to−Analog)変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、A/D(Analog to Digital)変換、復調等を行うことでデジタルベースバンド信号を生成し、BB処理モジュール152に渡す。REモジュール151は、例えば、図24のDL信号受信部51及びUL信号送信部52における物理レイヤ等の機能を含む。
【0139】
BB処理モジュール152は、IPパケットとデジタルベースバンド信号とを相互に変換する処理を行う。DSP(Digital Signal Processor)162は、BB処理モジュール152における信号処理を行うプロセッサである。メモリ172は、DSP162のワークエリアとして使用される。BB処理モジュール152は、例えば、図24のDL信号受信部51及びUL信号送信部52におけるレイヤ2等の機能、プリアンブル選択部53、RRC処理部54及びUEコンテクスト管理部54を含む。なお、プリアンブル選択部53、RRC処理部54及びUEコンテクスト管理部54の機能の全部又は一部を装置制御モジュール153に含めることとしてもよい。
【0140】
装置制御モジュール153は、IPレイヤのプロトコル処理、各種アプリケーションの処理等を行う。プロセッサ163は、装置制御モジュール153が行う処理を行うプロセッサである。メモリ173は、プロセッサ163のワークエリアとして使用される。また、プロセッサ163は、USIMスロット154を介してUSIMとの間でデータの読出し及び書込みを行う。
【0141】
<基地局eNB>
図26に、eNBの機能構成図を示す。図26に示すように、eNBは、DL信号送信部11、UL信号受信部12、RRC処理部13、UEコンテクスト管理部14、NW通信部15を備える。なお、図26は、eNBにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、eNBは、少なくともLTE方式に準拠した動作を行うための図示しない機能も有するものである。
【0142】
DL信号送信部11は、eNBから送信されるべき上位のレイヤの情報から、物理レイヤの各種信号を生成し、送信する機能を含む。UL信号受信部12は、UEから各種の上り信号を受信し、受信した物理レイヤの信号からより上位のレイヤの情報を取得する機能を含む。
【0143】
RRC処理部13は、RRCメッセージ及びシステム情報の生成・送信(送信はDL信号送信部11を介した送信)、UL信号受信部12により受信したRRCメッセージの解釈、動作等を行う。またRRC処理部13は、UEコンテクスト管理部14に保持しておいたUEコンテクストを利用してRRC接続を再開する機能等も含む。
【0144】
UEコンテクスト管理部14は、メモリ等の記憶手段を含み、RRC保留状態/RRCアイドル状態においてUEコンテクストを保持する。
【0145】
NW通信部15は、S1−MMEインターフェースでMMEとの間で制御信号を送受信する機能、及び、S1−UインターフェースでS−GWとの間でデータを送受信する機能、コネクション維持指示信号の送信機能、RRC接続確立完了の送信の送信機能等を含む。
【0146】
図26に示すeNBの構成は、全体をハードウェア回路(例:1つ又は複数のICチップ)で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をCPUとプログラムとで実現してもよい。
【0147】
図27は、eNBのハードウェア(HW)構成の例を示す図である。図27は、図26よりも実装例に近い構成を示している。図27に示すように、eNBは、無線信号に関する処理を行うREモジュール251と、ベースバンド信号処理を行うBB処理モジュール252と、上位レイヤ等の処理を行う装置制御モジュール253と、ネットワークと接続するためのインタフェースである通信IF254とを有する。
【0148】
REモジュール251は、BB処理モジュール252から受信したデジタルベースバンド信号に対して、D/A変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、A/D変換、復調等を行うことでデジタルベースバンド信号を生成し、BB処理モジュール252に渡す。REモジュール251は、例えば、図26のDL信号送信部11及びUL信号受信部12における物理レイヤ等の機能を含む。
【0149】
BB処理モジュール252は、IPパケットとデジタルベースバンド信号とを相互に変換する処理を行う。DSP262は、BB処理モジュール252における信号処理を行うプロセッサである。メモリ272は、DSP252のワークエリアとして使用される。BB処理モジュール252は、例えば、図25のDL信号送信部11及びUL信号受信部12におけるレイヤ2等の機能、RRC処理部13、UEコンテクスト管理部14を含む。なお、RRC処理部13、UEコンテクスト管理部14の機能の全部又は一部を装置制御モジュール253に含めることとしてもよい。
【0150】
装置制御モジュール253は、IPレイヤのプロトコル処理、OAM処理等を行う。プロセッサ263は、装置制御モジュール253が行う処理を行うプロセッサである。メモリ273は、プロセッサ263のワークエリアとして使用される。補助記憶装置283は、例えばHDD等であり、基地局eNB自身が動作するための各種設定情報等が格納される。
【0151】
なお、図24図27に示す装置の構成(機能区分)は、本実施の形態で説明する処理を実現する構成の一例に過ぎない。本実施の形態で説明する処理を実現できるのであれば、その実装方法(具体的な機能部の配置、名称等)は、特定の実装方法に限定されない。
【0152】
(実施の形態のまとめ)
以上、説明したように、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、前記選択部により選択されたランダムアクセス信号を前記基地局に装置する送信部と、を備え、前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信することを特徴とするユーザ装置が提供される。
【0153】
上記の構成により、例えば、基地局は、ユーザ装置が送信しようとするメッセージのサイズをRA responseを送信する前に把握することができ、適切なTBSをRA responseのUL grantで割り当てることができる。従って、ユーザ装置において、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避することができる。
【0154】
前記メッセージのサイズが前記所定の閾値よりも大きい場合に、前記選択部は、2つのランダムアクセス信号グループのうち、前記所定の閾値に対応するランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、既存のGroup Bを用いて、ユーザ装置が新たなCCCH SDU sizeを使用することを基地局に通知できる。
【0155】
また、前記メッセージのサイズが前記所定の閾値と等しい場合に、前記選択部は、複数のランダムアクセス信号グループの中から、前記所定の閾値に対応するランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、新たなGroupであるGroup Cを用いて、ユーザ装置が新たなCCCH SDU sizeを使用することを基地局に通知できる。前記所定の閾値に対応するランダムアクセス信号グループは、例えば、messageSizeGroupCである。
【0156】
また、上記の例において、前記メッセージのサイズが前記所定の閾値よりも大きく、かつ、パスロスが所定の値よりも小さい場合に、前記選択部は、複数のランダムアクセス信号グループの中から、前記所定の閾値に対応するランダムアクセス信号グループとは異なる所定のランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、既存のGroup Bを用いて、ユーザ装置がmessageSizeGroupCよりも大きなメッセージを使用することを基地局に通知できる。
【0157】
前記選択部は、前記メッセージのサイズが前記所定の閾値よりも大きく、かつ、パスロスが所定の値よりも小さいという第1条件が満たされるか否かを判定し、前記第1条件が満たされない場合に、前記メッセージのサイズが前記所定の閾値と等しいという第2条件が満たされるか否かを判定し、当該第2条件が満たされる場合に、前記所定の閾値に対応するランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、新たなGroupであるGroup Cを用いて、ユーザ装置が新たなCCCH SDU sizeを使用することを基地局に通知できる。
【0158】
上記の例において、前記第2条件が満たされない場合に、前記選択部は、前記メッセージのサイズが前記所定の閾値よりも小さく、かつ、前記メッセージのサイズが所定の第2の閾値よりも大きく、かつ、パスロスが所定の値よりも小さいという第3条件が満たされるか否かを判定し、前記第3条件が満たされる場合に、前記選択部は、前記所定の第2の閾値と前記所定の閾値との間のサイズに対応するランダムアクセス信号グループを選択し、前記第3条件が満たされない場合に、前記選択部は、前記所定の第2の閾値に対応するランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、図12に示したように、メッセージサイズを複数パターンに分けて、パターン毎に基地局への通知を行うことができる。
【0159】
また、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、所定の論理チャネルで送信されるメッセージのサイズと、ランダムアクセス信号のリソースとの間の対応関係の情報を前記基地局から受信する受信部と、前記所定の論理チャネルで送信されるメッセージのサイズに対応するリソースを、前記対応関係の情報から選択する選択部と、前記選択されたリソースを用いて、ランダムアクセス信号を前記基地局に送信する送信部とを備えるユーザ装置が提供される。
【0160】
上記の構成により、例えば、基地局は、ユーザ装置が送信しようとするメッセージのサイズをRA responseを送信する前に把握することができ、適切なTBSをRA responseのUL grantで割り当てることができる。従って、ユーザ装置において、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避することができる。
【0161】
前記リソースは、例えば、ランダムアクセス信号の系列、又はランダムアクセス信号の送信に使用する時間と周波数のリソースである。このように、リソースとして種々の情報を使用することで、柔軟なリソース制御が可能となる。
【0162】
また、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択ステップと、前記選択ステップにより選択されたランダムアクセス信号を前記基地局に装置する送信ステップと、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信する送信ステップとを備えるランダムアクセス方法が提供される。
【0163】
また、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、所定の論理チャネルで送信されるメッセージのサイズと、ランダムアクセス信号のリソースとの間の対応関係の情報を前記基地局から受信する受信ステップと、前記所定の論理チャネルで送信されるメッセージのサイズに対応するリソースを、前記対応関係の情報から選択する選択ステップと、前記選択されたリソースを用いて、ランダムアクセス信号を前記基地局に送信する送信ステップとを備えるランダムアクセス方法が提供される。
【0164】
また、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、第1のメッセージと、当該第1のメッセージよりもサイズの小さい第2のメッセージを生成する生成部と、前記基地局に送信されたランダムアクセス信号に対する当該基地局からの応答により割り当てられるリソースの量に応じて、前記第1のメッセージを送信できる場合に当該第1のメッセージを前記基地局に送信し、前記第1のメッセージを送信できない場合に前記第2のメッセージを前記基地局に送信する送信部とを備えるユーザ装置が提供される。
【0165】
上記の構成により、ユーザ装置において、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避することができる。
【0166】
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、2以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に(矛盾しない限り)適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には1つの部品で行われてもよいし、あるいは1つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、各装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従って当該装置が有するプロセッサにより動作するソフトウェアは、ランダムアクセスメモリ(RAM)、フラッシュメモリ、読み取り専用メモリ(ROM)、EPROM、EEPROM、レジスタ、ハードディスク(HDD)、リムーバブルディスク、CD−ROM、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
【0167】
また、本明細書で説明した各態様/実施形態は、LTE(Long Term Evolution)、LTE−A(LTE-Advanced)、SUPER 3G、IMT−Advanced、4G、5G、FRA(Future Radio Access)、W−CDMA(登録商標)、GSM(登録商標)、CDMA2000、UMB(Ultra Mobile Broadband)、IEEE 802.11(Wi−Fi)、IEEE 802.16(WiMAX)、IEEE 802.20、UWB(Ultra-WideBand)、Bluetooth(登録商標)、その他の適切なシステムを利用するシステム及び/又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【0168】
また、本明細書で説明した各実施例/変形例の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【0169】
また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。上述したパラメータに使用する名称はいかなる点においても限定的なものではない。
【0170】
本明細書には下記の事項が開示されている。
(第1項)
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、
所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、
前記選択部により選択されたランダムアクセス信号を前記基地局に装置する送信部と、を備え、
前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信する
ことを特徴とするユーザ装置。
(第2項)
前記メッセージのサイズが前記所定の閾値よりも大きい場合に、前記選択部は、2つのランダムアクセス信号グループのうち、前記所定の閾値に対応するランダムアクセス信号グループを選択する
ことを特徴とする第1項に記載のユーザ装置。
(第3項)
前記メッセージのサイズが前記所定の閾値と等しい場合に、前記選択部は、複数のランダムアクセス信号グループの中から、前記所定の閾値に対応するランダムアクセス信号グループを選択する
ことを特徴とする第1項に記載のユーザ装置。
(第4項)
前記メッセージのサイズが前記所定の閾値よりも大きく、かつ、パスロスが所定の値よりも小さい場合に、前記選択部は、複数のランダムアクセス信号グループの中から、前記所定の閾値に対応するランダムアクセス信号グループとは異なる所定のランダムアクセス信号グループを選択する
ことを特徴とする第3項に記載のユーザ装置。
(第5項)
前記選択部は、
前記メッセージのサイズが前記所定の閾値よりも大きく、かつ、パスロスが所定の値よりも小さいという第1条件が満たされるか否かを判定し、
前記第1条件が満たされない場合に、前記メッセージのサイズが前記所定の閾値と等しいという第2条件が満たされるか否かを判定し、当該第2条件が満たされる場合に、前記所定の閾値に対応するランダムアクセス信号グループを選択する
ことを特徴とする第1項に記載のユーザ装置。
(第6項)
前記第2条件が満たされない場合に、前記選択部は、前記メッセージのサイズが前記所定の閾値よりも小さく、かつ、前記メッセージのサイズが所定の第2の閾値よりも大きく、かつ、パスロスが所定の値よりも小さいという第3条件が満たされるか否かを判定し、
前記第3条件が満たされる場合に、前記選択部は、前記所定の第2の閾値と前記所定の閾値との間のサイズに対応するランダムアクセス信号グループを選択し、前記第3条件が満たされない場合に、前記選択部は、前記所定の第2の閾値に対応するランダムアクセス信号グループを選択する
ことを特徴とする第5項に記載のユーザ装置。
(第7項)
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、
所定の論理チャネルで送信されるメッセージのサイズと、ランダムアクセス信号のリソースとの間の対応関係の情報を前記基地局から受信する受信部と、
前記所定の論理チャネルで送信されるメッセージのサイズに対応するリソースを、前記対応関係の情報から選択する選択部と、
前記選択されたリソースを用いて、ランダムアクセス信号を前記基地局に送信する送信部と
を備えることを特徴とするユーザ装置。
(第8項)
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、
所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択ステップと、
前記選択ステップにより選択されたランダムアクセス信号を前記基地局に装置する送信ステップと、
前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信する送信ステップと
を備えることを特徴とするランダムアクセス方法。
(第9項)
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、
所定の論理チャネルで送信されるメッセージのサイズと、ランダムアクセス信号のリソースとの間の対応関係の情報を前記基地局から受信する受信ステップと、
前記所定の論理チャネルで送信されるメッセージのサイズに対応するリソースを、前記対応関係の情報から選択する選択ステップと、
前記選択されたリソースを用いて、ランダムアクセス信号を前記基地局に送信する送信ステップと
を備えることを特徴とするランダムアクセス方法。
【0171】
本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【符号の説明】
【0172】
10、20 eNB
11 DL信号送信部
12 UL信号受信部
13 RRC処理部
14 UEコンテクスト管理部
15 NW通信部
30 MME
40 S−GW
50 UE
51 DL信号受信部
52 UL信号送信部
53 プリアンブル選択部
54 RRC処理部
55 UEコンテクスト管理部
151 REモジュール
152 BB処理モジュール
153 装置制御モジュール
154 USIMスロット
251 REモジュール
252 BB処理モジュール
253 装置制御モジュール
254 通信IF
図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