(57)【要約】  ＲＲＣによる再送において、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行う無線送信装置、無線受信装置及び無線通信方法を提供する。これらの装置及び方法によれば、送信装置（１００）がRRCメッセージを再送する際、既に送信した元のメッセージのＳＮ及び元のメッセージとの関係を示す情報（フラグ）を含めた再送メッセージを送信し、この再送メッセージを受信した受信装置（１５０）が既に受信したメッセージのＳＮ及び既に受信したメッセージとの関係を示す情報に基づいて、今回受信した再送メッセージを処理する。
2008023791.tif 000002
【特許請求の範囲】
【請求項１】
RRCメッセージを再送する際、既に送信した元のメッセージのＳＮ（Sequence Number）及び前記元のメッセージとの関係を示す情報を含めて再送メッセージを作成する作成手段と、
作成された前記再送メッセージを送信する送信手段と、
を具備する無線送信装置。
【請求項２】
前記作成手段は、RRCメッセージを作成する際、既に送信したメッセージであり、かつ、今回作成するメッセージと関連するメッセージがある場合、前記関連するメッセージのＳＮ及び前記関連するメッセージとの関係を示す情報を含めてメッセージを作成する請求項１に記載の無線送信装置。
【請求項３】
前記作成手段は、前記元のメッセージとの関係を示す情報をメッセージタイプに関連付けて前記再送メッセージを作成する請求項１に記載の無線送信装置。
【請求項４】
前記作成手段は、前記関連するメッセージとの関係を示す情報をメッセージタイプに関連付けて前記メッセージを作成する請求項２に記載の無線送信装置。
【請求項５】
既に受信したメッセージのＳＮ（Sequence Number）及び前記既に受信したメッセージとの関係を示す情報が含められたメッセージを受信する受信手段と、
前記既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報に基づいて、今回受信したメッセージを処理する処理手段と、
を具備する無線受信装置。
【請求項６】
前記処理手段は、前記既に受信したメッセージとの関係を示す情報としてメッセージタイプを用いて、今回受信したメッセージを処理する請求項５に記載の無線受信装置。
【請求項７】
無線送信装置において、RRCメッセージを送信する際、既に送信した元のメッセージのＳＮ（Sequence Number）及び前記元のメッセージとの関係を示す情報を含めて再送メッセージを作成する作成工程と、
作成された前記再送メッセージを無線受信装置に送信する送信工程と、
前記無線受信装置において、既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報が含められたメッセージを前記無線送信装置から受信する受信工程と、
前記既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報に基づいて、今回受信したメッセージを処理する処理工程と、
を具備する無線通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線送信装置、無線受信装置及び無線通信方法に関する。
【背景技術】
【０００２】
既に標準化作業が行われた３ＧＰＰ（3rd Generation Partnership Project） ＵＭＴＳ（Universal Mobile Telecommunications System）Release1999において、ＲＬＣ（Radio Link Control）は、無線区間でのエラーを解消する役割（リカバリー）を果たしている。具体的には、受信側において受信できているパケットの情報をステータスレポート（Status report）として受信側から送信側に報告し、送信側は、その結果を用いて、受信側において受信できていないパケットを再送する。これにより、パケット損失のリカバリーを行っている（例えば、非特許文献１参照）。【０００３】
現在、３ＧＰＰで標準化が行われているＬＴＥ（Long Term Evolution）においても、ＲＬＣは存在しているものの、ＵＭＴＳとは異なり、ＬＴＥではＨＡＲＱ（Hybrid ARQ）が常に存在する。ＨＡＲＱにおいてもパケット損失をリカバリーする再送を行っている。そのため、ＬＴＥでのＲＬＣの役割は、ＨＡＲＱでリカバリーできない場合の対応となる。ＬＴＥでのＲＬＣがエラーリカバリーを行う条件としては、以下の場合が考えられる。１つには、ＨＡＲＱの再送が最大再送回数に達した場合、２つには、ＨＡＲＱでのＮＡＣＫが送信側でＡＣＫとして受信された場合、３つには、送信側からのデータの送信に受信側が気付かず、受信側はＡＣＫもＮＡＣＫも送っていないにもかかわらず、送信側でＡＣＫを誤検出した場合などである。【０００４】
このような場合において、ステータスレポートを常時送信していては無駄が多いので、ＬＴＥでは簡易なリカバリー方法が検討されている。このリカバリー方法として、以下の２つの方式が検討されている。【０００５】
１つめの方式としては、図１に示すように、ＲＬＣ／ＭＡＣでのＳＮ（Sequence Number）を用いたエラー検出であり、受信側において、送られてくるデータのＲＬＣ／ＭＡＣでのＳＮを監視して、抜けているＳＮがあれば、そのＳＮについて再送要求を送出するというものである。【０００６】
２つめの方式としては、図２に示すように、ＮＤＩ（New Data Indicator）を用いたエラー検出であり、受信側において、ＮＤＩを監視して、ＮＤＩが連続していなければ、Errorを返す。なお、ＮＤＩ用のビット数はまだ決まっていない（ＵＭＴＳにおけるＨＳＤＰＡでは１ビット）。【０００７】
これら２つの方式のいずれかによれば、ＨＡＲＱでリカバリーできない場合でも、比較的簡易にリカバリーすることができる（例えば、非特許文献２及び非特許文献３参照）。【０００８】
ところが、これら２つの方式は、主に、ｕプレーン（u-plane: user-plane)、すなわちデータについて検討されており、ｃプレーン（c-plane: control-plane)、すなわち制御情報についてはあまり検討されていない。【０００９】
ここで、ｕプレーンとｃプレーンとについて簡単に説明する。ｕプレーンは、送信頻度が比較的高いため、次にデータが送られてきた時にエラーを検出できる上記の簡易なリカバリーが有効である。また、エラーがあった場合には、常に同じデータを再送する必要がある。さらに、メッセージ（Message）サイズ（1 IP packet = 1500Kbyte)が最小送信単位に比べて大きく、データを分割して送信することが多い。そのため、分割された単位で再送することが有効である。【００１０】
一方、ｃプレーンは、送信頻度が比較的低いため、次にデータが送られてきたときにエラー検出を行う上記の簡易なリカバリーでは、長時間検出できない可能性がある。また、エラーがあった場合に、同じデータを再送することが最適とは限らず、再送時に設定（制御）内容を変更することが考えられる。さらに、メッセージサイズが小さく、制御情報を分割することはあまりない。そのため、分割した単位での再送とメッセージ毎の再送とで差がない。【００１１】
これらのことから、ｕプレーンに関してはＲＬＣでの再送は有効ではあるが、ｃプレーンに関してはあまり有効ではないと言える。【００１２】
そこで、ｃプレーンの再送に関しては、その制御情報を生成するＲＲＣ（Radio Resource Control）で再送処理を行うことが考えられる。具体的には、図３に示すように、送信側ＲＲＣ（図中Tx RRC）は、メッセージ送信時にタイマー（Timer）を開始し、受信側ＲＲＣ（図中Rx RRC）は、メッセージ受信時に応答メッセージ（Response message）を返送する。そして、送信側ＲＲＣは、応答メッセージ受信時にタイマーを停止する。【００１３】
なお、ＵＭＴＳではメッセージ内容を変更できないが、ＲＲＣでの再送を特別な場合に関してのみサポートしていた。特別な場合とは、端末が基地局に最初にアクセスするための要求信号であるRRC接続要求（RRC CONNECTION REQUEST）を送信する場合、端末が新たなセルを見つけて新たなセルにアクセスするための要求信号であるCELL UPDATEを送信する場合、ＲＬＣがリセットされた場合等のようにＲＬＣでの再送が行えない場合である。このような場合、ＵＭＴＳでは、RRC SNは変えずに、情報要素であるTransaction IDを変える。すなわち１インクリメントすることで前のメッセージと区別していた。しかしながら、この方式では、RRC SNを下位のレイヤ（ＲＬＣ、ＭＡＣ）で使いまわすことができない（非特許文献４参照）。これは、下位のレイヤでは前のメッセージとの違いが区別できず、前のメッセージを受信できている場合には、再送されたメッセージを同様のメッセージと判断して廃棄してしまうためである。そのため、上記の通り、再送時に設定を変更するという処理ができなくなってしまう。【００１４】
そこで、ここでのポイントとしては、送信側ＲＲＣは、タイマー満了時にRRCメッセージを再送し、再送時はＲＲＣ内でメッセージの順番を管理するために定義されているRRC SNとして新たな値を使う必要がある。また、ＲＬＣは、ＵＭ（Unacknowledged Mode）で動作させることにより、再送処理を実施せず、また新たな機能追加がＲＬＣに必要となることもない。【００１５】
これにより、送信頻度の低いRRCメッセージに対しても、有効な再送処理が可能となる。また、メッセージの内容に応じたタイマー設定なども可能である。さらに、ＲＲＣ自体での再送のため、メッセージ内容を変えることが可能となる。
【非特許文献１】TS25.322, “Radio Link Control (RLC) Protocol Specification”
【非特許文献２】R2-060826, “HARQ-ARQ interaction”, Nokia, 3GPP TSG-RAN WG2 Meeting#52
【非特許文献３】R2-060909, “Robustness of HARQ assisted ARQ operation”, Samsung, 3GPP TSG-RAN WG2 Meeting#52
【非特許文献４】R2-061903, “Using same Sequence Number for ARQ for Security”, ASUSTeK, 3GPP TSG-RAN WG2 LTE adhoc
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかしながら、ＲＲＣにおける再送では、以下のような問題が考えられる。すなわち、図４に示すように、送信側ＲＲＣは、受信側ＲＲＣからの応答メッセージの受信に失敗した場合、タイマー満了後、RRCメッセージを再送することになるが、再送されたRRCメッセージは、受信側ＲＲＣにおいて既に正しく処理されているので、再度設定を行うことになってしまう。【００１７】
本発明の目的は、ＲＲＣによる再送において、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行う無線送信装置、無線受信装置及び無線通信方法を提供することである。
【課題を解決するための手段】
【００１８】
本発明の無線送信装置は、RRCメッセージを再送する際、既に送信した元のメッセージのＳＮ（Sequence Number）及び前記元のメッセージとの関係を示す情報を含めて再送メッセージを作成する作成手段と、作成された前記再送メッセージを送信する送信手段と、を具備する構成を採る。【００１９】
本発明の無線受信装置は、既に受信したメッセージのＳＮ（Sequence Number）及び前記既に受信したメッセージとの関係を示す情報が含められたメッセージを受信する受信手段と、前記既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報に基づいて、今回受信したメッセージを処理する処理手段と、を具備する構成を採る。【００２０】
本発明の無線通信方法は、無線送信装置において、RRCメッセージを送信する際、既に送信した元のメッセージのＳＮ（Sequence Number）及び前記元のメッセージとの関係を示す情報を含めて再送メッセージを作成する作成工程と、作成された前記再送メッセージを無線受信装置に送信する送信工程と、前記無線受信装置において、既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報が含められたメッセージを前記無線送信装置から受信する受信工程と、前記既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報に基づいて、今回受信したメッセージを処理する処理工程と、を具備するようにした。
【発明の効果】
【００２１】
本発明によれば、ＲＲＣによる再送において、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行うことができる。
【図面の簡単な説明】
【００２２】
【図１】ＬＴＥで検討されている簡易なリカバリー方法を示すシーケンス図
【図２】ＬＴＥで検討されている簡易なリカバリー方法を示すシーケンス図
【図３】ｃプレーンの再送処理を示すシーケンス図
【図４】課題の説明に供する図
【図５】本発明の実施の形態１，２及び３に係る送信装置の構成を示すブロック図
【図６】本発明の実施の形態１，２及び３に係る受信装置の構成を示すブロック図
【図７】図５に示した送信装置と図６に示した受信装置との通信手順の概略を示すシーケンス図
【図８】フラグがメッセージをキャンセルする場合を示すシーケンス図
【図９】フラグが元のメッセージと同一である場合を示すシーケンス図
【図１０】フラグが元のメッセージの処理待ちである場合を示すシーケンス図
【図１１】フラグをメッセージタイプで代用する場合を示すシーケンス図
【図１２】ハンドオーバを指示するハンドオーバインジケーションの受信に端末が失敗した場合を示すシーケンス図
【図１３】ハンドオーバインジケーションの受信成功を示す応答の受信に基地局が失敗した場合を示すシーケンス図
【図１４】本発明の実施の形態３に係るセキュリティ設定時の通信手順を示すシーケンス図
【発明を実施するための最良の形態】
【００２３】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。【００２４】
（実施の形態１）
図５は、本発明の実施の形態１に係る送信装置１００の構成を示すブロック図である。この図において、受信部１０１は、通信相手から送信されたメッセージを受信する。また、ここで通信相手から送信された通常メッセージは制御決定部１０２に出力される。また、送信装置１００から送信したメッセージに対して、通信相手から応答（Response）を受信した場合には、受信した応答は通信結果判定部１０５に出力される。【００２５】
制御決定部１０２は、上位ノード（Node）又は他レイヤ（Layer）からの指示、または通信相手からのメッセージに応じて制御内容を決定する。決定された制御内容は制御メッセージ作成部１０３に出力される。【００２６】
制御メッセージ作成部１０３は、制御決定部１０２から出力された制御内容を用いて、制御メッセージを作成する。また、後述する通信結果判定部１０５から出力されたメッセージの通信結果をもとに、制御決定部１０２から指示された制御内容の結果を制御決定部１０２に返す。また、制御決定部１０２からの情報をもとに通信結果判定部１０５に対して通信結果の判定を通知する。【００２７】
送信部１０４は、制御メッセージ作成部１０３から出力された制御メッセージを送信すると共に、通信結果判定部１０５に通信相手からの応答を管理するタイマーの開始を指示する。【００２８】
通信結果判定部１０５は、送信部１０４からの指示をトリガーにタイマーを開始し、受信部１０１から出力された通信相手からの応答を取得すると、タイマーを停止する。また、タイマーの満了、停止の情報はそれぞれのタイミングで制御メッセージ作成部１０３に通知される。【００２９】
次に、図５に示した送信装置１００の動作について詳細に説明する。送信装置１００では、制御決定部１０２において、通信相手に対する制御内容を決定する。ここでの制御内容とは、３ＧＰＰにおいて規定されているＲＲＣでの制御内容であり、チャネル設定、ハンドオーバ指示、チャネル解放指示、品質測定指示、品質測定結果報告等が挙げられる。また、この制御の元となる情報としては、上位ノード又は他レイヤからの情報であり、具体的には、送信装置１００が基地局である場合、上位ノード（コアネットワーク）からのチャネル設定指示、コアネットワークのメッセージ（コアネットワークのメッセージはＲＲＣを介して送信されるため)、端末からの品質測定結果などが挙げられる。また、送信装置１００が端末である場合、上位レイヤからの呼発生通知、下位レイヤからの品質測定結果等が挙げられる。【００３０】
制御決定部１０２は、このような情報を元に決定された制御内容を制御メッセージ作成部１０３に通知すると同時に、その制御内容を保持する。また、この制御内容を制御決定部１０２及び制御メッセージ作成部１０３の双方が参照できるように、この制御内容にＩＤ等を付して受け渡しを行う。【００３１】
このように、制御決定部１０２では、制御内容を決定する処理に加えて、前回決定した制御内容との確認も行う。具体的には、今回設定する内容が前回の再設定である場合には、前回送信したＩＤと、前回送信した制御内容との関係を示す情報とを決定する。そして、決定したこれらの情報を制御内容として制御メッセージ作成部１０３に出力する。【００３２】
制御メッセージ作成部１０３では、制御決定部１０２から通知された制御内容に基づいて、制御メッセージを作成する。ここで、前回送信した制御メッセージと今回送信する制御メッセージをそれぞれ識別するＳＮ（Sequence number）が制御メッセージのヘッダ又はメッセージ自体に埋め込まれる。また、制御決定部１０２から関係情報が出力された場合には、この関係情報も制御メッセージのヘッダ又はメッセージ自体に埋めこむ。このように生成された制御メッセージは送信部１０４に出力される。【００３３】
送信部１０４では、制御メッセージ作成部１０３から出力されたメッセージを送信する。ここでの送信とは、主に、下位レイヤへの受け渡しであり、この後、下位レイヤによって更なるヘッダの追加、符号化、暗号化等が行われることがあるが、どのような送信処理が下位レイヤで行われてもよい。また、送信のタイミングで通信結果判定部１０５に対して、送信したメッセージのＳＮの情報を出力する。また、このとき、タイマー情報（タイマーの長さ自体の情報又はメッセージタイプを示す）等も合わせて出力する。【００３４】
なお、受信部１０１に関しても、下位レイヤからの受け渡しを行うものであり、下位レイヤによって復号処理等が行われることがあるが、どのような受信処理が下位レイヤで行われてもよい。【００３５】
通信結果判定部１０５では、送信部１０４から出力された情報に基づいてタイマーを開始する。この際、タイマーの長さは、送信部１０４から出力されたタイマー情報に従って決定される。具体的には、タイマー情報がタイマーの長さ自体の情報である場合には、その値を用いてタイマーを設定する。一方、タイマー情報がメッセージタイプである場合には、通信結果判定部１０５において予め設定されているメッセージタイプ毎のタイマー値を参照してタイマーを決定する。【００３６】
このタイマーは、受信部１０１から出力された通信相手の応答によって停止され、通信結果判定部１０５は、そのタイミングで送信が正常に完了したことをメッセージのＳＮを用いて、制御メッセージ作成部１０３に通知する。【００３７】
制御メッセージ作成部１０３は、制御決定部１０２に対して制御内容を示すＩＤを用いて、その制御が正常に終了したことを通知する。この通知によって正常に制御が完了したことになる。また、タイマーが満了した場合には、通信結果判定部１０５は、そのタイミングで送信が所定時間内に行われなかったことをメッセージのＳＮを用いて制御メッセージ作成部１０３に通知する。この結果、制御メッセージ作成部１０３は、制御内容を示すＩＤを用いて、その制御が所定時間内に行われなかったことを制御決定部１０２に通知する。この後の動作は上記の再送時の動作となる。【００３８】
受信部１０１は、通信相手から送信された情報を受信する。その際、通信相手からの通常のメッセージを受信した場合には、受信した通常メッセージを制御決定部１０２に出力し、送信装置１００から送信したメッセージに対する応答を受信した場合には、受信した応答を該当メッセージのＳＮと共に受信成功を通信結果判定部１０５に通知する。通信相手からのメッセージが通常の応答に加えて制御情報を含んでいる場合には、制御決定部１０２にメッセージ自体を出力し、別途、応答を通信結果判定部１０５に出力する。【００３９】
図６は、本発明の実施の形態１に係る受信装置１５０の構成を示すブロック図である。この図において、受信部１５１は、送信装置１００から送信された制御メッセージを受信し、関連するメッセージ等の情報が無ければ制御処理部１５４に制御メッセージを送り、関連するメッセージ等の情報があれば処理確認部１５２に制御メッセージを送る。【００４０】
処理結果保持部１５３は、後述する制御処理部１５４で処理した制御の内容を保持し、保持した内容が処理確認部１５２によって確認される。【００４１】
処理確認部１５２は、処理結果保持部１５３に確認し、受信した制御メッセージを処理するか否かを判定する。受信した制御メッセージを処理する場合には、その制御メッセージを元にして行うべき制御内容を制御処理部１５４に通知し、処理を行う必要が無い場合には、その旨を制御処理部１５４に通知する。【００４２】
制御処理部１５４は、受信した制御メッセージに設定されている制御を実行し、その結果を応答メッセージ作成部１５５に通知する。処理をすぐに行わない場合、または処理に時間がかかる場合には、制御メッセージを受信したことを応答メッセージ作成部１５５に通知する。また、行った処理の情報は処理結果保持部１５３に出力される。【００４３】
応答メッセージ作成部１５５は、制御処理部１５４から通知された制御処理の結果を示す応答メッセージ、受信結果を示す応答メッセージを作成し、作成した応答メッセージを送信部１５６に出力する。【００４４】
送信部１５６は、応答メッセージ作成部１５５から出力された応答メッセージの送信処理を行う。【００４５】
次に、図６に示した受信装置１５０の動作について詳細に説明する。受信装置１５０において、受信部１５１では、送信装置１００から送信された制御メッセージを受信する。ここで、今回受信した制御メッセージが再送メッセージであるかどうかを確認する。具体的には、制御メッセージのヘッダ又はメッセージ内に関連するメッセージを示すＳＮが入っているかどうかで見分けることとなる。ここで、ＳＮがある場合には、今回受信した制御メッセージを処理確認部１５２に出力し、ＳＮがない場合には、今回受信した制御メッセージを制御処理部１５４に出力する。【００４６】
処理確認部１５２では、今回のメッセージと関連するメッセージと、そのメッセージとの関係に応じて処理を決定する。処理内容の決定の際に、元のメッセージを受信できているかを確認する。この際に、元のメッセージを受信できていなければ、今回のメッセージをそのまま制御処理部１５４に通知する。【００４７】
一方、元のメッセージを受信できており、今回のメッセージが元のメッセージと同じ内容である場合には、今回のメッセージの内容を実施する必要はないので、その旨を制御処理部１５４に通知する。また、元のメッセージの設定ではなく、今回のメッセージの設定を実行する指示である場合には、今回のメッセージの内容を用いて再設定するように制御処理部１５４に通知する。【００４８】
制御処理部１５４では、処理確認部１５２から通知された指示に従って、受信部１５１から出力された制御メッセージを処理する。具体的な内容としては、３ＧＰＰで規定されているＲＲＣ処理の実施、制御メッセージが受信できたことを応答メッセージ作成部１５５に通知することなどである。また、ここで処理した制御メッセージの情報を処理結果保持部１５３に保存しておき、処理確認部１５２が確認できるようにしておく。【００４９】
応答メッセージ作成部１５５では、制御処理部１５４からの指示に応じて応答メッセージを作成する。応答メッセージとしては、単純に制御メッセージの受信ができたことを通知するもの、制御メッセージの処理の結果を通知するものとがあるが、ここではその両方を制御処理部１５４からの情報に基づいて作成することとなる。作成された制御メッセージは送信部１５６に出力され、送信部１５６において送信処理される。【００５０】
図７は、図５に示した送信装置１００と図６に示した受信装置１５０との通信手順の概略を示すシーケンス図である。送信装置１００は、RRCメッセージを送信する場合、そのメッセージが再送メッセージである場合には、再送する際の元のメッセージのＳＮ、関連する元のメッセージのＳＮを含め、さらにそのＳＮのメッセージとの関連を示す情報（フラグ）をつけて送信する。このフラグとしては、そのＳＮのメッセージをキャンセルすること、又は、このメッセージはそのＳＮのメッセージと同じであること、などが考えられる。【００５１】
受信装置１５０は、受信メッセージに関連するメッセージのＳＮが含まれている場合には、そのＳＮのメッセージとの関係を示す情報を確認し、その確認結果をもとに受信メッセージの処理を決定する。【００５２】
ここで、フラグの示す情報として、そのＳＮのメッセージをキャンセルする場合を図８に示し、このメッセージはそのＳＮのメッセージと同じである場合を図９に示す。【００５３】
また、本実施の形態では、再送されるRRCメッセージの処理内容について説明したが、RRCメッセージが再送される間に、他のRRCメッセージが送られる場合を考えると、更なる拡張が必要となる。具体的には、再送される間に送られるRRCメッセージを処理する順番を考慮する場合に拡張が必要となる。【００５４】
すなわち、先に送信したRRCメッセージを処理した後に処理を行う必要のあるRRCメッセージの場合に、再送により順序入れ替えが起こっても、正しい順番で処理を行う必要がある。具体例としては、RB Setupメッセージ後のNASメッセージ（Service accept）等があげられる。【００５５】
このような場合には、先に送信したRRCメッセージを処理した後に処理すべきRRCメッセージに、先に処理すべきメッセージのＳＮと、先に送ったメッセージの処理を行ってからこのメッセージの処理を行うことを示すフラグとを入れることが考えられる。この処理は、制御決定部１０２にて行うことが可能である。【００５６】
これにより、図１０に示すように、先に送ったメッセージを待ってから処理すべきメッセージの場合には、先に送ったメッセージが処理されているかを確認し、処理されている場合には今回のメッセージ処理を行う。逆に、先に送ったメッセージが処理されていない場合には、先に送ったメッセージが処理されるまで今回のメッセージ処理を待つこととする。この待機処理は、処理確認部１５２で実施可能であり、先に送ったメッセージが処理されている場合には、今回のメッセージ処理を行うことを制御処理部１５４に通知する。【００５７】
このように実施の形態１によれば、送信装置がRRCメッセージを再送する際、既に送信した元のメッセージのＳＮ及び元のメッセージとの関係を示す情報（フラグ）を含めた再送メッセージを送信し、この再送メッセージを受信した受信装置が既に受信したメッセージのＳＮ及び既に受信したメッセージとの関係を示す情報に基づいて、今回受信した再送メッセージを処理することにより、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行うことができる。【００５８】
なお、本実施の形態では、制御決定部１０２と制御メッセージ作成部１０３とを分けて示したが、この２つを合わせて実装することでメッセージのＳＮのみを用いて制御内容を管理し、別途制御内容を示すＩＤを省くことも考えられる。【００５９】
また、本実施の形態では、制御メッセージ作成部１０３にてＳＮをつけるようにしたが、送信部１０４がＳＮを付けるようにしてもよい。この場合、通信の結果は通信結果判定部１０５から送信部１０４に送られる。また、制御メッセージ作成部１０３と送信部１０４との間で制御メッセージを示すＩＤを別途用意する必要があり、そのＩＤを用いて送信部１０４から制御メッセージ作成部１０３に通知する必要がある。また、上記２つを組み合わせてもよい。【００６０】
また、本実施の形態では、どのような処理を行うのかを示すフラグを用いる場合について説明したが、このフラグを用いず、メッセージタイプに基づいて、受信メッセージの処理を決定することも可能である。この場合には、メッセージタイプ毎にどのような動作を行うかを予め決定しておく。この決定は、標準化上で一意に決めておくことが一般的に考えられるが、その設定自体を制御できるようにすることも可能である。この概念図を図１１に示す。具体的な例としては、ハンドオーバ（Handover）を指示するメッセージ、セキュリティの設定を行うメッセージ等に関しては常に新しい設定を行う必要がある。そのため、前に受信したメッセージを破棄して新たに再送されたメッセージの内容を使用し、測定の指示等前回と内容的にほとんど変える必要がないメッセージに関して、前のメッセージを受信している場合にはその設定をそのまま使用することが考えられる。【００６１】
また、メッセージの形態、制御形態によっては、同じ設定を上書きすることが受信側として問題ない場合が考えられる。その場合には、前のメッセージをキャンセルしたい時、すなわち、前のメッセージで設定した内容を取り消さないと、新たな設定に支障が出るようなことがある。このような場合には、関係するメッセージとしてキャンセルするメッセージのＳＮのみを通知すればよく、前のメッセージとの対応内容を示すフラグは必要ない。そのため受信側としては、前のメッセージのＳＮが示されている場合には前に受け取ったメッセージの内容を常にキャンセルすることとなる。【００６２】
また、前のメッセージの動作をキャンセルする際に、メッセージの内容を全てキャンセルするのではなく、キャンセルする部分、もしくはキャンセルできる部分と、キャンセルしない部分、もしくはキャンセルできない部分とを分けておくことも考えられる。すなわち、キャンセルする部分、もしくはキャンセルできる部分は、前のメッセージのＳＮと必要ならば前のメッセージに対する対応を示す情報を通知するのみでキャンセルされるが、キャンセルしない部分、もしくはキャンセルできない部分は明示的に削除または上書きするような処理が必要となる。この、キャンセルする部分、もしくはキャンセルできる部分と、キャンセルしない部分、もしくはキャンセルできない部分の切り分けとしては、RRCメッセージで規定されているMandatory（必ず必要な情報）、Option（必須ではない情報）で分けることも可能であるし、ＵＭＴＳのRRCメッセージのencodingとして用いられているASN.1におけるCritical information、Non Critical informationで分けることも可能であるし、他の方法でも構わない。【００６３】
また、本実施の形態では、前のメッセージのＳＮとして示すものが１つである必要はなく、複数であってもかまわない。具体例としては、測定指示を行うRRCメッセージを送った後にNASメッセージを送った場合で、この両方に対して応答が返ってこなかった例などが考えられる。このような場合には、再送時に２つのメッセージをあわせて１つのメッセージとして送ることが考えられる。そのため、前回送った２つのメッセージに対する処理を記載することとなる。また、複数の前のメッセージを示す場合に、メッセージ毎に異なる動作を行うことが考えられる。すなわち、２つの前に送ったメッセージのＳＮを含む場合に、１つのメッセージは前のメッセージを受け取っていたとしても無視するが、もう１つが前のメッセージを受け取っていたとしたら今回のメッセージを無視できる等である。このような場合には、受信側での処理が複雑になると考えられるので、同一の処理を行うもののみをあわせて送信できるように制限をかけることが考えられる。その場合には、どのような処理を行うのかを示すフラグが必要な場合でも、フラグはメッセージに１つあればよくなる。【００６４】
また、本発明では、制御内容の例として３ＧＰＰで規定されているＲＲＣで制御されている内容を参照して説明したが、制御内容としてはこの内容に限定されるものではなく、コアネットワーク側の処理であるＮＡＳ（Non Access Stratum）で規定されている制御処理等を含めてもよく、下位レイヤであるＭＡＣ（Medium Access Control）で規定されている制御処理等を含めた制御に対して適用してもよい。また、ＲＲＣのみでなくNASメッセージの再送のためにＮＡＳにて実装してもよいし、ＭＡＣの制御信号の再送のためにＭＡＣに実装してもよい。さらには、制御情報のみでなくても、再送信時に値が変わるような性質をもつデータ通信に対しても適用することが考えられる。この場合には、通信端末間で通信を行う場合には、通信端末間で今回の機能を実現することになる。また、通信端末とサーバのようなものとで通信を行う場合には、通信端末とサーバとで今回の機能を実現することになる。また、このようにデータに適用した場合には、前述の通り複数の前のメッセージのＳＮを示すことで、通信途中のファイルの上書きなどを実現することができる。【００６５】
また、本実施の形態では、再送のメッセージを送る際に異なるRRC SNを使用するように記載した。しかしながら、RRC SNを下位レイヤ（ＲＬＣ、ＭＡＣ）で用いない場合には、同じRRC SNを使用することも考えられる。すなわち、同じRRC SNを用いてTransaction IDで再送であることを示すことなどである。この場合にも同様に、元のメッセージとの関係を示すフラグの導入、またはメッセージタイプによる一意な処理判断などが考えられる。またさらには、メッセージのフォーマットとしては、同じ内容を再送する場合と、異なる値を再送する場合とで異なるタイプのTransaction IDを使用することが考えられる。具体的にはTransaction ID１とTransaction ID２を用意しておき、同一内容の再送時にはTransaction ID１を使用し、異なる内容を再送する場合にはTransaction ID２を用いるなどである。【００６６】
なお、本実施の形態では、RRCメッセージを通信相手に送信した後の処理を記載したが、RRCメッセージを通信相手に送信前の動作に適用することが可能である。すなわち、RRCメッセージを下位レイヤ（ＲＬＣ、ＭＡＣ）に渡した後に、そのメッセージが実際に通信相手に送信される前に送信をキャンセルすることが考えられる。この時にも、本発明を使用することが可能である。具体的には、下位レイヤに対して新たな再送メッセージと同時に前のメッセージの送信をキャンセルする指示を送る。この場合に、下位レイヤでは既に前のメッセージの送信を行ってしまっている可能性がある。しかしその場合でも、本発明のように前のメッセージとの関係が示されていれば、下位レイヤは渡された再送メッセージを通常通り送信するだけですむ。そのため処理の簡素化が可能となる。【００６７】
なお、本実施の形態では、RRCメッセージに対する応答をRRCメッセージ毎に返す動作を図示したが、複数のRRCメッセージが近いタイミングで送られてきた場合などには、１つの応答を複数のRRCメッセージの応答として使用することも可能である。【００６８】
（実施の形態２）
本発明の実施の形態２では、実施の形態１において説明した内容をハンドオーバに適用する場合について説明する。【００６９】
本発明の実施の形態２に係る送信装置及び受信装置の構成は、実施の形態１で示した図５と図６の構成と同一であるので、図５及び図６を援用して説明する。なお。本実施の形態では、送信装置を端末とし、受信装置を基地局とする。【００７０】
図１２及び図１３は、本発明の実施の形態２に係るハンドオーバ時の通信手順を示すシーケンス図である。特に、図１２は、ハンドオーバを指示するハンドオーバインジケーション（Handover indication）の受信に端末が失敗した場合を示す。また、図１３は、ハンドオーバインジケーションの受信成功を示す応答の受信に基地局が失敗した場合を示す。【００７１】
図１２に示す場合では、ハンドオーバインジケーションの受信に端末が失敗しているため、端末としてはハンドオーバを実行することはない。そのため、再度同じハンドオーバ先へハンドオーバを示すメッセージを送ることが一般的に考えられる。ただし、図１２に示すように、再送のためのタイマーが動いている最中に測定報告（Measurement report）によってさらに適切なセルが見つかった場合には、そのセルを管理する基地局と通信を行い、ネゴシエーション（negotiation）が成立したら、そのセルに対するハンドオーバインジケーションを送信することが可能である。この場合には、タイマーの満了を待ってからの指示ではなくて、ネゴシエーション確立後にすぐハンドオーバインジケーションを送信することが考えられる。【００７２】
図１３に示す場合では、ハンドオーバインジケーションの受信成功を示す応答の受信に基地局が失敗しているため、端末はハンドオーバを実行することになる。この場合には、端末は移動先のセルを管理しているターゲット（target）基地局に対して、ハンドオーバ完了（Handover complete）を用いて、ハンドオーバの終了を通知する。そのため、ターゲット基地局ではハンドオーバを確認でき、その結果をソース（source）基地局に通知する。これにより、ソース基地局では、無事ハンドオーバが終わったことを確認できる。そのため、それを持ってタイマーを停止することとなる。このため、通常の場合で通信相手からのメッセージを元にタイマーを停止する場合とは若干異なる処理となる。図５を用いて説明すると、制御決定部１０２において上位ノード又は他レイヤとしてハンドオーバ終了の情報を受け取る。制御決定部１０２はこれにより、ハンドオーバ制御が完了したことがわかる。そのため、制御完了の通知を制御内容を示すＩＤ等と共に制御メッセージ作成部１０３に送る。その後、制御メッセージ作成部１０３では通信結果判定部１０５に対して制御完了を通知することでタイマーを停止することとなる。【００７３】
（実施の形態３）
本発明の実施の形態３では、実施の形態１において説明した内容をセキュリティ設定に適用する場合について説明する。【００７４】
本発明の実施の形態３に係る送信装置及び受信装置の構成は、実施の形態１で示した図５と図６の構成と同一であるので、図５及び図６を援用して説明する。なお、本実施の形態では、送信装置を端末とし、受信装置を基地局とする。【００７５】
図１４は、本発明の実施の形態３に係るセキュリティ設定時の通信手順を示すシーケンス図である。【００７６】
ここで、セキュリティ関係の設定でクリティカルなものとして、セキュリティの設定内容を反映させるタイミング情報が挙げられる。このタイミングは、３ＧＰＰでは、ＡＴ（Activation time）として定義され、RRCメッセージによって渡される。このＡＴは再送を考慮した値である必要がある。すなわち、端末と基地局とで同時にセキュリティの設定内容を反映させる必要があるため、端末が受信したことの確認が取れておらず、再送のためのタイマーが動いている最中に端末側がセキュリティの設定を行ってしまっては問題があるため、再送を行う時間より長い値を取ることが必要である。また、再送時に同じＡＴを用いると再度再送が必要な場合に問題が出てくる。そのため、ここでは、図１４に示すように、ＡＴの値をさらに変更することが考えられる。この際、端末としては、たとえ最初のメッセージを受信している場合でも、後のメッセージを受けたら前の設定ではなく、今回受け取った設定を用いて動作することとなる。すなわち、前回のメッセージで指定されているＡＴの値ではなく今回のメッセージで指定されているＡＴの値である。【００７７】
また、更なるケースとして再送のメッセージも正しく送信できない可能性がある。特に問題として考えられるのは、図１４に示したように応答が返ってこない場合で、さらに再送のメッセージが端末に届かないケースである。この場合には、端末は再送されていることに気づかずに前に受け取ったメッセージを用いて設定を行ってしまう可能性がある。このようなことをさけるため、再送のメッセージを送った際に設定するタイマーは最初にメッセージを送った際のタイマーよりも短くすることなどが考えられる。よって、受信側（本実施の形態では端末）でも早く応答を返すように処理を行うことが考えられる。具体例としては、最初のメッセージの場合には、メッセージの内容の確認、または処理等を行ってから応答を返すようにしておき、再送のメッセージの場合には、再送であることが判断できたらメッセージ内容の確認、または処理等を行う前に応答を返すなどの処理である。なお、上記の動作は、本実施の形態で記載されているセキュリティの設定のみでなく、他の処理で基地局と端末とでそろって処理を実行する必要のあるものに対して有効である。【００７８】
なお、このセキュリティの設定内容としてはＡＴ以外を変える必要性が少ない。そのため、ＡＴの情報をRRCメッセージ内部に入れるのではなくて、RRCのヘッダに入れるなどの手段が再送の効率化のために考えられる。このように再送時に変更のあるパラメータをヘッダに入れることで、再送の際のRRCメッセージの処理、暗号化、インテグリティチェック（Integrity check）の動作等を簡易に行うことができる。【００７９】
上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はソフトウェアで実現することも可能である。【００８０】
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【００８１】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。【００８２】
さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。【００８３】
２００６年８月２５日出願の特願２００６−２２９８１２の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【００８４】
本発明にかかる無線送信装置、無線受信装置及び無線通信方法は、ＲＲＣによる再送において、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行うことができ、３ＧＰＰの移動通信システム等に適用できる。
【図１】
2008023791.tif 000003
【図２】
2008023791.tif 000004
【図３】
2008023791.tif 000005
【図４】
2008023791.tif 000006
【図５】
2008023791.tif 000007
【図６】
2008023791.tif 000008
【図７】
2008023791.tif 000009
【図８】
2008023791.tif 000010
【図９】
2008023791.tif 000011
【図１０】
2008023791.tif 000012
【図１１】
2008023791.tif 000013
【図１２】
2008023791.tif 000014
【図１３】
2008023791.tif 000015
【図１４】
2008023791.tif 000016
【手続補正書】
【提出日】平成21年1月7日(2009.1.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
RRCメッセージを再送する際、既に送信した元のメッセージのＳＮ（Sequence Number）及び前記元のメッセージとの関係を示す情報を含めて再送メッセージを作成する作成手段と、
作成された前記再送メッセージを送信する送信手段と、
を具備する無線送信装置。
【請求項２】
前記作成手段は、RRCメッセージを作成する際、既に送信したメッセージであり、かつ、今回作成するメッセージと関連するメッセージがある場合、前記関連するメッセージのＳＮ及び前記関連するメッセージとの関係を示す情報を含めてメッセージを作成する請求項１に記載の無線送信装置。
【請求項３】
前記作成手段は、前記元のメッセージとの関係を示す情報をメッセージタイプに関連付けて前記再送メッセージを作成する請求項１に記載の無線送信装置。
【請求項４】
前記作成手段は、前記関連するメッセージとの関係を示す情報をメッセージタイプに関連付けて前記メッセージを作成する請求項２に記載の無線送信装置。
【請求項５】
既に受信したメッセージのＳＮ（Sequence Number）及び前記既に受信したメッセージとの関係を示す情報が含められたメッセージを受信する受信手段と、
前記既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報に基づいて、今回受信したメッセージを処理する処理手段と、
を具備する無線受信装置。
【請求項６】
前記処理手段は、前記既に受信したメッセージとの関係を示す情報としてメッセージタイプを用いて、今回受信したメッセージを処理する請求項５に記載の無線受信装置。
【請求項７】
無線送信装置において、RRCメッセージを送信する際、既に送信した元のメッセージのＳＮ（Sequence Number）及び前記元のメッセージとの関係を示す情報を含めて再送メッセージを作成する作成工程と、
作成された前記再送メッセージを無線受信装置に送信する送信工程と、
前記無線受信装置において、既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報が含められたメッセージを前記無線送信装置から受信する受信工程と、
前記既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報に基づいて、今回受信したメッセージを処理する処理工程と、
を具備する無線通信方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線送信装置、無線受信装置及び無線通信方法に関する。
【背景技術】
【０００２】
既に標準化作業が行われた３ＧＰＰ（3rd Generation Partnership Project） ＵＭＴＳ（Universal Mobile Telecommunications System）Release1999において、ＲＬＣ（Radio Link Control）は、無線区間でのエラーを解消する役割（リカバリー）を果たしている。具体的には、受信側において受信できているパケットの情報をステータスレポート（Status report）として受信側から送信側に報告し、送信側は、その結果を用いて、受信側において受信できていないパケットを再送する。これにより、パケット損失のリカバリーを行っている（例えば、非特許文献１参照）。
【０００３】
現在、３ＧＰＰで標準化が行われているＬＴＥ（Long Term Evolution）においても、ＲＬＣは存在しているものの、ＵＭＴＳとは異なり、ＬＴＥではＨＡＲＱ（Hybrid ARQ）が常に存在する。ＨＡＲＱにおいてもパケット損失をリカバリーする再送を行っている。そのため、ＬＴＥでのＲＬＣの役割は、ＨＡＲＱでリカバリーできない場合の対応となる。ＬＴＥでのＲＬＣがエラーリカバリーを行う条件としては、以下の場合が考えられる。１つには、ＨＡＲＱの再送が最大再送回数に達した場合、２つには、ＨＡＲＱでのＮＡＣＫが送信側でＡＣＫとして受信された場合、３つには、送信側からのデータの送信に受信側が気付かず、受信側はＡＣＫもＮＡＣＫも送っていないにもかかわらず、送信側でＡＣＫを誤検出した場合などである。
【０００４】
このような場合において、ステータスレポートを常時送信していては無駄が多いので、ＬＴＥでは簡易なリカバリー方法が検討されている。このリカバリー方法として、以下の２つの方式が検討されている。
【０００５】
１つめの方式としては、図１に示すように、ＲＬＣ／ＭＡＣでのＳＮ（Sequence Number）を用いたエラー検出であり、受信側において、送られてくるデータのＲＬＣ／ＭＡＣでのＳＮを監視して、抜けているＳＮがあれば、そのＳＮについて再送要求を送出するというものである。
【０００６】
２つめの方式としては、図２に示すように、ＮＤＩ（New Data Indicator）を用いたエラー検出であり、受信側において、ＮＤＩを監視して、ＮＤＩが連続していなければ、Errorを返す。なお、ＮＤＩ用のビット数はまだ決まっていない（ＵＭＴＳにおけるＨＳＤＰＡでは１ビット）。
【０００７】
これら２つの方式のいずれかによれば、ＨＡＲＱでリカバリーできない場合でも、比較的簡易にリカバリーすることができる（例えば、非特許文献２及び非特許文献３参照）。
【０００８】
ところが、これら２つの方式は、主に、ｕプレーン（u-plane: user-plane)、すなわちデータについて検討されており、ｃプレーン（c-plane: control-plane)、すなわち制御情報についてはあまり検討されていない。
【０００９】
ここで、ｕプレーンとｃプレーンとについて簡単に説明する。ｕプレーンは、送信頻度が比較的高いため、次にデータが送られてきた時にエラーを検出できる上記の簡易なリカバリーが有効である。また、エラーがあった場合には、常に同じデータを再送する必要がある。さらに、メッセージ（Message）サイズ（1 IP packet = 1500Kbyte)が最小送信単
位に比べて大きく、データを分割して送信することが多い。そのため、分割された単位で再送することが有効である。
【００１０】
一方、ｃプレーンは、送信頻度が比較的低いため、次にデータが送られてきたときにエラー検出を行う上記の簡易なリカバリーでは、長時間検出できない可能性がある。また、エラーがあった場合に、同じデータを再送することが最適とは限らず、再送時に設定（制御）内容を変更することが考えられる。さらに、メッセージサイズが小さく、制御情報を分割することはあまりない。そのため、分割した単位での再送とメッセージ毎の再送とで差がない。
【００１１】
これらのことから、ｕプレーンに関してはＲＬＣでの再送は有効ではあるが、ｃプレーンに関してはあまり有効ではないと言える。
【００１２】
そこで、ｃプレーンの再送に関しては、その制御情報を生成するＲＲＣ（Radio Resource Control）で再送処理を行うことが考えられる。具体的には、図３に示すように、送信側ＲＲＣ（図中Tx RRC）は、メッセージ送信時にタイマー（Timer）を開始し、受信側ＲＲＣ（図中Rx RRC）は、メッセージ受信時に応答メッセージ（Response message）を返送する。そして、送信側ＲＲＣは、応答メッセージ受信時にタイマーを停止する。
【００１３】
なお、ＵＭＴＳではメッセージ内容を変更できないが、ＲＲＣでの再送を特別な場合に関してのみサポートしていた。特別な場合とは、端末が基地局に最初にアクセスするための要求信号であるRRC接続要求（RRC CONNECTION REQUEST）を送信する場合、端末が新たなセルを見つけて新たなセルにアクセスするための要求信号であるCELL UPDATEを送信する場合、ＲＬＣがリセットされた場合等のようにＲＬＣでの再送が行えない場合である。このような場合、ＵＭＴＳでは、RRC SNは変えずに、情報要素であるTransaction IDを変える。すなわち１インクリメントすることで前のメッセージと区別していた。しかしながら、この方式では、RRC SNを下位のレイヤ（ＲＬＣ、ＭＡＣ）で使いまわすことができない（非特許文献４参照）。これは、下位のレイヤでは前のメッセージとの違いが区別できず、前のメッセージを受信できている場合には、再送されたメッセージを同様のメッセージと判断して廃棄してしまうためである。そのため、上記の通り、再送時に設定を変更するという処理ができなくなってしまう。
【００１４】
そこで、ここでのポイントとしては、送信側ＲＲＣは、タイマー満了時にRRCメッセージを再送し、再送時はＲＲＣ内でメッセージの順番を管理するために定義されているRRC SNとして新たな値を使う必要がある。また、ＲＬＣは、ＵＭ（Unacknowledged Mode）で動作させることにより、再送処理を実施せず、また新たな機能追加がＲＬＣに必要となることもない。
【００１５】
これにより、送信頻度の低いRRCメッセージに対しても、有効な再送処理が可能となる。また、メッセージの内容に応じたタイマー設定なども可能である。さらに、ＲＲＣ自体での再送のため、メッセージ内容を変えることが可能となる。
【非特許文献１】TS25.322, “Radio Link Control (RLC) Protocol Specification”
【非特許文献２】R2-060826, “HARQ-ARQ interaction”, Nokia, 3GPP TSG-RAN WG2 Meeting#52
【非特許文献３】R2-060909, “Robustness of HARQ assisted ARQ operation”, Samsung, 3GPP TSG-RAN WG2 Meeting#52
【非特許文献４】R2-061903, “Using same Sequence Number for ARQ for Security”, ASUSTeK, 3GPP TSG-RAN WG2 LTE adhoc
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかしながら、ＲＲＣにおける再送では、以下のような問題が考えられる。すなわち、図４に示すように、送信側ＲＲＣは、受信側ＲＲＣからの応答メッセージの受信に失敗した場合、タイマー満了後、RRCメッセージを再送することになるが、再送されたRRCメッセージは、受信側ＲＲＣにおいて既に正しく処理されているので、再度設定を行うことになってしまう。
【００１７】
本発明の目的は、ＲＲＣによる再送において、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行う無線送信装置、無線受信装置及び無線通信方法を提供することである。
【課題を解決するための手段】
【００１８】
本発明の無線送信装置は、RRCメッセージを再送する際、既に送信した元のメッセージのＳＮ（Sequence Number）及び前記元のメッセージとの関係を示す情報を含めて再送メッセージを作成する作成手段と、作成された前記再送メッセージを送信する送信手段と、を具備する構成を採る。
【００１９】
本発明の無線受信装置は、既に受信したメッセージのＳＮ（Sequence Number）及び前記既に受信したメッセージとの関係を示す情報が含められたメッセージを受信する受信手段と、前記既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報に基づいて、今回受信したメッセージを処理する処理手段と、を具備する構成を採る。
【００２０】
本発明の無線通信方法は、無線送信装置において、RRCメッセージを送信する際、既に送信した元のメッセージのＳＮ（Sequence Number）及び前記元のメッセージとの関係を示す情報を含めて再送メッセージを作成する作成工程と、作成された前記再送メッセージを無線受信装置に送信する送信工程と、前記無線受信装置において、既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報が含められたメッセージを前記無線送信装置から受信する受信工程と、前記既に受信したメッセージのＳＮ及び前記既に受信したメッセージとの関係を示す情報に基づいて、今回受信したメッセージを処理する処理工程と、を具備するようにした。
【発明の効果】
【００２１】
本発明によれば、ＲＲＣによる再送において、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行うことができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００２３】
（実施の形態１）
図５は、本発明の実施の形態１に係る送信装置１００の構成を示すブロック図である。この図において、受信部１０１は、通信相手から送信されたメッセージを受信する。また、ここで通信相手から送信された通常メッセージは制御決定部１０２に出力される。また、送信装置１００から送信したメッセージに対して、通信相手から応答（Response）を受信した場合には、受信した応答は通信結果判定部１０５に出力される。
【００２４】
制御決定部１０２は、上位ノード（Node）又は他レイヤ（Layer）からの指示、または通信相手からのメッセージに応じて制御内容を決定する。決定された制御内容は制御メッセージ作成部１０３に出力される。
【００２５】
制御メッセージ作成部１０３は、制御決定部１０２から出力された制御内容を用いて、制御メッセージを作成する。また、後述する通信結果判定部１０５から出力されたメッセージの通信結果をもとに、制御決定部１０２から指示された制御内容の結果を制御決定部１０２に返す。また、制御決定部１０２からの情報をもとに通信結果判定部１０５に対して通信結果の判定を通知する。
【００２６】
送信部１０４は、制御メッセージ作成部１０３から出力された制御メッセージを送信すると共に、通信結果判定部１０５に通信相手からの応答を管理するタイマーの開始を指示する。
【００２７】
通信結果判定部１０５は、送信部１０４からの指示をトリガーにタイマーを開始し、受信部１０１から出力された通信相手からの応答を取得すると、タイマーを停止する。また、タイマーの満了、停止の情報はそれぞれのタイミングで制御メッセージ作成部１０３に通知される。
【００２８】
次に、図５に示した送信装置１００の動作について詳細に説明する。送信装置１００では、制御決定部１０２において、通信相手に対する制御内容を決定する。ここでの制御内容とは、３ＧＰＰにおいて規定されているＲＲＣでの制御内容であり、チャネル設定、ハンドオーバ指示、チャネル解放指示、品質測定指示、品質測定結果報告等が挙げられる。また、この制御の元となる情報としては、上位ノード又は他レイヤからの情報であり、具体的には、送信装置１００が基地局である場合、上位ノード（コアネットワーク）からのチャネル設定指示、コアネットワークのメッセージ（コアネットワークのメッセージはＲＲＣを介して送信されるため)、端末からの品質測定結果などが挙げられる。また、送信装置１００が端末である場合、上位レイヤからの呼発生通知、下位レイヤからの品質測定結果等が挙げられる。
【００２９】
制御決定部１０２は、このような情報を元に決定された制御内容を制御メッセージ作成部１０３に通知すると同時に、その制御内容を保持する。また、この制御内容を制御決定部１０２及び制御メッセージ作成部１０３の双方が参照できるように、この制御内容にＩ
Ｄ等を付して受け渡しを行う。
【００３０】
このように、制御決定部１０２では、制御内容を決定する処理に加えて、前回決定した制御内容との確認も行う。具体的には、今回設定する内容が前回の再設定である場合には、前回送信したＩＤと、前回送信した制御内容との関係を示す情報とを決定する。そして、決定したこれらの情報を制御内容として制御メッセージ作成部１０３に出力する。
【００３１】
制御メッセージ作成部１０３では、制御決定部１０２から通知された制御内容に基づいて、制御メッセージを作成する。ここで、前回送信した制御メッセージと今回送信する制御メッセージをそれぞれ識別するＳＮ（Sequence number）が制御メッセージのヘッダ又はメッセージ自体に埋め込まれる。また、制御決定部１０２から関係情報が出力された場合には、この関係情報も制御メッセージのヘッダ又はメッセージ自体に埋めこむ。このように生成された制御メッセージは送信部１０４に出力される。
【００３２】
送信部１０４では、制御メッセージ作成部１０３から出力されたメッセージを送信する。ここでの送信とは、主に、下位レイヤへの受け渡しであり、この後、下位レイヤによって更なるヘッダの追加、符号化、暗号化等が行われることがあるが、どのような送信処理が下位レイヤで行われてもよい。また、送信のタイミングで通信結果判定部１０５に対して、送信したメッセージのＳＮの情報を出力する。また、このとき、タイマー情報（タイマーの長さ自体の情報又はメッセージタイプを示す）等も合わせて出力する。
【００３３】
なお、受信部１０１に関しても、下位レイヤからの受け渡しを行うものであり、下位レイヤによって復号処理等が行われることがあるが、どのような受信処理が下位レイヤで行われてもよい。
【００３４】
通信結果判定部１０５では、送信部１０４から出力された情報に基づいてタイマーを開始する。この際、タイマーの長さは、送信部１０４から出力されたタイマー情報に従って決定される。具体的には、タイマー情報がタイマーの長さ自体の情報である場合には、その値を用いてタイマーを設定する。一方、タイマー情報がメッセージタイプである場合には、通信結果判定部１０５において予め設定されているメッセージタイプ毎のタイマー値を参照してタイマーを決定する。
【００３５】
このタイマーは、受信部１０１から出力された通信相手の応答によって停止され、通信結果判定部１０５は、そのタイミングで送信が正常に完了したことをメッセージのＳＮを用いて、制御メッセージ作成部１０３に通知する。
【００３６】
制御メッセージ作成部１０３は、制御決定部１０２に対して制御内容を示すＩＤを用いて、その制御が正常に終了したことを通知する。この通知によって正常に制御が完了したことになる。また、タイマーが満了した場合には、通信結果判定部１０５は、そのタイミングで送信が所定時間内に行われなかったことをメッセージのＳＮを用いて制御メッセージ作成部１０３に通知する。この結果、制御メッセージ作成部１０３は、制御内容を示すＩＤを用いて、その制御が所定時間内に行われなかったことを制御決定部１０２に通知する。この後の動作は上記の再送時の動作となる。
【００３７】
受信部１０１は、通信相手から送信された情報を受信する。その際、通信相手からの通常のメッセージを受信した場合には、受信した通常メッセージを制御決定部１０２に出力し、送信装置１００から送信したメッセージに対する応答を受信した場合には、受信した応答を該当メッセージのＳＮと共に受信成功を通信結果判定部１０５に通知する。通信相手からのメッセージが通常の応答に加えて制御情報を含んでいる場合には、制御決定部１０２にメッセージ自体を出力し、別途、応答を通信結果判定部１０５に出力する。
【００３８】
図６は、本発明の実施の形態１に係る受信装置１５０の構成を示すブロック図である。この図において、受信部１５１は、送信装置１００から送信された制御メッセージを受信し、関連するメッセージ等の情報が無ければ制御処理部１５４に制御メッセージを送り、関連するメッセージ等の情報があれば処理確認部１５２に制御メッセージを送る。
【００３９】
処理結果保持部１５３は、後述する制御処理部１５４で処理した制御の内容を保持し、保持した内容が処理確認部１５２によって確認される。
【００４０】
処理確認部１５２は、処理結果保持部１５３に確認し、受信した制御メッセージを処理するか否かを判定する。受信した制御メッセージを処理する場合には、その制御メッセージを元にして行うべき制御内容を制御処理部１５４に通知し、処理を行う必要が無い場合には、その旨を制御処理部１５４に通知する。
【００４１】
制御処理部１５４は、受信した制御メッセージに設定されている制御を実行し、その結果を応答メッセージ作成部１５５に通知する。処理をすぐに行わない場合、または処理に時間がかかる場合には、制御メッセージを受信したことを応答メッセージ作成部１５５に通知する。また、行った処理の情報は処理結果保持部１５３に出力される。
【００４２】
応答メッセージ作成部１５５は、制御処理部１５４から通知された制御処理の結果を示す応答メッセージ、受信結果を示す応答メッセージを作成し、作成した応答メッセージを送信部１５６に出力する。
【００４３】
送信部１５６は、応答メッセージ作成部１５５から出力された応答メッセージの送信処理を行う。
【００４４】
次に、図６に示した受信装置１５０の動作について詳細に説明する。受信装置１５０において、受信部１５１では、送信装置１００から送信された制御メッセージを受信する。ここで、今回受信した制御メッセージが再送メッセージであるかどうかを確認する。具体的には、制御メッセージのヘッダ又はメッセージ内に関連するメッセージを示すＳＮが入っているかどうかで見分けることとなる。ここで、ＳＮがある場合には、今回受信した制御メッセージを処理確認部１５２に出力し、ＳＮがない場合には、今回受信した制御メッセージを制御処理部１５４に出力する。
【００４５】
処理確認部１５２では、今回のメッセージと関連するメッセージと、そのメッセージとの関係に応じて処理を決定する。処理内容の決定の際に、元のメッセージを受信できているかを確認する。この際に、元のメッセージを受信できていなければ、今回のメッセージをそのまま制御処理部１５４に通知する。
【００４６】
一方、元のメッセージを受信できており、今回のメッセージが元のメッセージと同じ内容である場合には、今回のメッセージの内容を実施する必要はないので、その旨を制御処理部１５４に通知する。また、元のメッセージの設定ではなく、今回のメッセージの設定を実行する指示である場合には、今回のメッセージの内容を用いて再設定するように制御処理部１５４に通知する。
【００４７】
制御処理部１５４では、処理確認部１５２から通知された指示に従って、受信部１５１から出力された制御メッセージを処理する。具体的な内容としては、３ＧＰＰで規定されているＲＲＣ処理の実施、制御メッセージが受信できたことを応答メッセージ作成部１５５に通知することなどである。また、ここで処理した制御メッセージの情報を処理結果保持部１５３に保存しておき、処理確認部１５２が確認できるようにしておく。
【００４８】
応答メッセージ作成部１５５では、制御処理部１５４からの指示に応じて応答メッセージを作成する。応答メッセージとしては、単純に制御メッセージの受信ができたことを通知するもの、制御メッセージの処理の結果を通知するものとがあるが、ここではその両方を制御処理部１５４からの情報に基づいて作成することとなる。作成された制御メッセージは送信部１５６に出力され、送信部１５６において送信処理される。
【００４９】
図７は、図５に示した送信装置１００と図６に示した受信装置１５０との通信手順の概略を示すシーケンス図である。送信装置１００は、RRCメッセージを送信する場合、そのメッセージが再送メッセージである場合には、再送する際の元のメッセージのＳＮ、関連する元のメッセージのＳＮを含め、さらにそのＳＮのメッセージとの関連を示す情報（フラグ）をつけて送信する。このフラグとしては、そのＳＮのメッセージをキャンセルすること、又は、このメッセージはそのＳＮのメッセージと同じであること、などが考えられる。
【００５０】
受信装置１５０は、受信メッセージに関連するメッセージのＳＮが含まれている場合には、そのＳＮのメッセージとの関係を示す情報を確認し、その確認結果をもとに受信メッセージの処理を決定する。
【００５１】
ここで、フラグの示す情報として、そのＳＮのメッセージをキャンセルする場合を図８に示し、このメッセージはそのＳＮのメッセージと同じである場合を図９に示す。
【００５２】
また、本実施の形態では、再送されるRRCメッセージの処理内容について説明したが、RRCメッセージが再送される間に、他のRRCメッセージが送られる場合を考えると、更なる拡張が必要となる。具体的には、再送される間に送られるRRCメッセージを処理する順番を考慮する場合に拡張が必要となる。
【００５３】
すなわち、先に送信したRRCメッセージを処理した後に処理を行う必要のあるRRCメッセージの場合に、再送により順序入れ替えが起こっても、正しい順番で処理を行う必要がある。具体例としては、RB Setupメッセージ後のNASメッセージ（Service accept）等があげられる。
【００５４】
このような場合には、先に送信したRRCメッセージを処理した後に処理すべきRRCメッセージに、先に処理すべきメッセージのＳＮと、先に送ったメッセージの処理を行ってからこのメッセージの処理を行うことを示すフラグとを入れることが考えられる。この処理は、制御決定部１０２にて行うことが可能である。
【００５５】
これにより、図１０に示すように、先に送ったメッセージを待ってから処理すべきメッセージの場合には、先に送ったメッセージが処理されているかを確認し、処理されている場合には今回のメッセージ処理を行う。逆に、先に送ったメッセージが処理されていない場合には、先に送ったメッセージが処理されるまで今回のメッセージ処理を待つこととする。この待機処理は、処理確認部１５２で実施可能であり、先に送ったメッセージが処理されている場合には、今回のメッセージ処理を行うことを制御処理部１５４に通知する。
【００５６】
このように実施の形態１によれば、送信装置がRRCメッセージを再送する際、既に送信した元のメッセージのＳＮ及び元のメッセージとの関係を示す情報（フラグ）を含めた再送メッセージを送信し、この再送メッセージを受信した受信装置が既に受信したメッセージのＳＮ及び既に受信したメッセージとの関係を示す情報に基づいて、今回受信した再送メッセージを処理することにより、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行うことができる。
【００５７】
なお、本実施の形態では、制御決定部１０２と制御メッセージ作成部１０３とを分けて示したが、この２つを合わせて実装することでメッセージのＳＮのみを用いて制御内容を管理し、別途制御内容を示すＩＤを省くことも考えられる。
【００５８】
また、本実施の形態では、制御メッセージ作成部１０３にてＳＮをつけるようにしたが、送信部１０４がＳＮを付けるようにしてもよい。この場合、通信の結果は通信結果判定部１０５から送信部１０４に送られる。また、制御メッセージ作成部１０３と送信部１０４との間で制御メッセージを示すＩＤを別途用意する必要があり、そのＩＤを用いて送信部１０４から制御メッセージ作成部１０３に通知する必要がある。また、上記２つを組み合わせてもよい。
【００５９】
また、本実施の形態では、どのような処理を行うのかを示すフラグを用いる場合について説明したが、このフラグを用いず、メッセージタイプに基づいて、受信メッセージの処理を決定することも可能である。この場合には、メッセージタイプ毎にどのような動作を行うかを予め決定しておく。この決定は、標準化上で一意に決めておくことが一般的に考えられるが、その設定自体を制御できるようにすることも可能である。この概念図を図１１に示す。具体的な例としては、ハンドオーバ（Handover）を指示するメッセージ、セキュリティの設定を行うメッセージ等に関しては常に新しい設定を行う必要がある。そのため、前に受信したメッセージを破棄して新たに再送されたメッセージの内容を使用し、測定の指示等前回と内容的にほとんど変える必要がないメッセージに関して、前のメッセージを受信している場合にはその設定をそのまま使用することが考えられる。
【００６０】
また、メッセージの形態、制御形態によっては、同じ設定を上書きすることが受信側として問題ない場合が考えられる。その場合には、前のメッセージをキャンセルしたい時、すなわち、前のメッセージで設定した内容を取り消さないと、新たな設定に支障が出るようなことがある。このような場合には、関係するメッセージとしてキャンセルするメッセージのＳＮのみを通知すればよく、前のメッセージとの対応内容を示すフラグは必要ない。そのため受信側としては、前のメッセージのＳＮが示されている場合には前に受け取ったメッセージの内容を常にキャンセルすることとなる。
【００６１】
また、前のメッセージの動作をキャンセルする際に、メッセージの内容を全てキャンセルするのではなく、キャンセルする部分、もしくはキャンセルできる部分と、キャンセルしない部分、もしくはキャンセルできない部分とを分けておくことも考えられる。すなわち、キャンセルする部分、もしくはキャンセルできる部分は、前のメッセージのＳＮと必要ならば前のメッセージに対する対応を示す情報を通知するのみでキャンセルされるが、キャンセルしない部分、もしくはキャンセルできない部分は明示的に削除または上書きするような処理が必要となる。この、キャンセルする部分、もしくはキャンセルできる部分と、キャンセルしない部分、もしくはキャンセルできない部分の切り分けとしては、RRCメッセージで規定されているMandatory（必ず必要な情報）、Option（必須ではない情報）で分けることも可能であるし、ＵＭＴＳのRRCメッセージのencodingとして用いられているASN.1におけるCritical information、Non Critical informationで分けることも可能であるし、他の方法でも構わない。
【００６２】
また、本実施の形態では、前のメッセージのＳＮとして示すものが１つである必要はなく、複数であってもかまわない。具体例としては、測定指示を行うRRCメッセージを送った後にNASメッセージを送った場合で、この両方に対して応答が返ってこなかった例などが考えられる。このような場合には、再送時に２つのメッセージをあわせて１つのメッセージとして送ることが考えられる。そのため、前回送った２つのメッセージに対する処理を記載することとなる。また、複数の前のメッセージを示す場合に、メッセージ毎に異な
る動作を行うことが考えられる。すなわち、２つの前に送ったメッセージのＳＮを含む場合に、１つのメッセージは前のメッセージを受け取っていたとしても無視するが、もう１つが前のメッセージを受け取っていたとしたら今回のメッセージを無視できる等である。このような場合には、受信側での処理が複雑になると考えられるので、同一の処理を行うもののみをあわせて送信できるように制限をかけることが考えられる。その場合には、どのような処理を行うのかを示すフラグが必要な場合でも、フラグはメッセージに１つあればよくなる。
【００６３】
また、本発明では、制御内容の例として３ＧＰＰで規定されているＲＲＣで制御されている内容を参照して説明したが、制御内容としてはこの内容に限定されるものではなく、コアネットワーク側の処理であるＮＡＳ（Non Access Stratum）で規定されている制御処理等を含めてもよく、下位レイヤであるＭＡＣ（Medium Access Control）で規定されている制御処理等を含めた制御に対して適用してもよい。また、ＲＲＣのみでなくNASメッセージの再送のためにＮＡＳにて実装してもよいし、ＭＡＣの制御信号の再送のためにＭＡＣに実装してもよい。さらには、制御情報のみでなくても、再送信時に値が変わるような性質をもつデータ通信に対しても適用することが考えられる。この場合には、通信端末間で通信を行う場合には、通信端末間で今回の機能を実現することになる。また、通信端末とサーバのようなものとで通信を行う場合には、通信端末とサーバとで今回の機能を実現することになる。また、このようにデータに適用した場合には、前述の通り複数の前のメッセージのＳＮを示すことで、通信途中のファイルの上書きなどを実現することができる。
【００６４】
また、本実施の形態では、再送のメッセージを送る際に異なるRRC SNを使用するように記載した。しかしながら、RRC SNを下位レイヤ（ＲＬＣ、ＭＡＣ）で用いない場合には、同じRRC SNを使用することも考えられる。すなわち、同じRRC SNを用いてTransaction IDで再送であることを示すことなどである。この場合にも同様に、元のメッセージとの関係を示すフラグの導入、またはメッセージタイプによる一意な処理判断などが考えられる。またさらには、メッセージのフォーマットとしては、同じ内容を再送する場合と、異なる値を再送する場合とで異なるタイプのTransaction IDを使用することが考えられる。具体的にはTransaction ID１とTransaction ID２を用意しておき、同一内容の再送時にはTransaction ID１を使用し、異なる内容を再送する場合にはTransaction ID２を用いるなどである。
【００６５】
なお、本実施の形態では、RRCメッセージを通信相手に送信した後の処理を記載したが、RRCメッセージを通信相手に送信前の動作に適用することが可能である。すなわち、RRCメッセージを下位レイヤ（ＲＬＣ、ＭＡＣ）に渡した後に、そのメッセージが実際に通信相手に送信される前に送信をキャンセルすることが考えられる。この時にも、本発明を使用することが可能である。具体的には、下位レイヤに対して新たな再送メッセージと同時に前のメッセージの送信をキャンセルする指示を送る。この場合に、下位レイヤでは既に前のメッセージの送信を行ってしまっている可能性がある。しかしその場合でも、本発明のように前のメッセージとの関係が示されていれば、下位レイヤは渡された再送メッセージを通常通り送信するだけですむ。そのため処理の簡素化が可能となる。
【００６６】
なお、本実施の形態では、RRCメッセージに対する応答をRRCメッセージ毎に返す動作を図示したが、複数のRRCメッセージが近いタイミングで送られてきた場合などには、１つの応答を複数のRRCメッセージの応答として使用することも可能である。
【００６７】
（実施の形態２）
本発明の実施の形態２では、実施の形態１において説明した内容をハンドオーバに適用する場合について説明する。
【００６８】
本発明の実施の形態２に係る送信装置及び受信装置の構成は、実施の形態１で示した図５と図６の構成と同一であるので、図５及び図６を援用して説明する。なお。本実施の形態では、送信装置を端末とし、受信装置を基地局とする。
【００６９】
図１２及び図１３は、本発明の実施の形態２に係るハンドオーバ時の通信手順を示すシーケンス図である。特に、図１２は、ハンドオーバを指示するハンドオーバインジケーション（Handover indication）の受信に端末が失敗した場合を示す。また、図１３は、ハンドオーバインジケーションの受信成功を示す応答の受信に基地局が失敗した場合を示す。
【００７０】
図１２に示す場合では、ハンドオーバインジケーションの受信に端末が失敗しているため、端末としてはハンドオーバを実行することはない。そのため、再度同じハンドオーバ先へハンドオーバを示すメッセージを送ることが一般的に考えられる。ただし、図１２に示すように、再送のためのタイマーが動いている最中に測定報告（Measurement report）によってさらに適切なセルが見つかった場合には、そのセルを管理する基地局と通信を行い、ネゴシエーション（negotiation）が成立したら、そのセルに対するハンドオーバインジケーションを送信することが可能である。この場合には、タイマーの満了を待ってからの指示ではなくて、ネゴシエーション確立後にすぐハンドオーバインジケーションを送信することが考えられる。
【００７１】
図１３に示す場合では、ハンドオーバインジケーションの受信成功を示す応答の受信に基地局が失敗しているため、端末はハンドオーバを実行することになる。この場合には、端末は移動先のセルを管理しているターゲット（target）基地局に対して、ハンドオーバ完了（Handover complete）を用いて、ハンドオーバの終了を通知する。そのため、ターゲット基地局ではハンドオーバを確認でき、その結果をソース（source）基地局に通知する。これにより、ソース基地局では、無事ハンドオーバが終わったことを確認できる。そのため、それを持ってタイマーを停止することとなる。このため、通常の場合で通信相手からのメッセージを元にタイマーを停止する場合とは若干異なる処理となる。図５を用いて説明すると、制御決定部１０２において上位ノード又は他レイヤとしてハンドオーバ終了の情報を受け取る。制御決定部１０２はこれにより、ハンドオーバ制御が完了したことがわかる。そのため、制御完了の通知を制御内容を示すＩＤ等と共に制御メッセージ作成部１０３に送る。その後、制御メッセージ作成部１０３では通信結果判定部１０５に対して制御完了を通知することでタイマーを停止することとなる。
【００７２】
（実施の形態３）
本発明の実施の形態３では、実施の形態１において説明した内容をセキュリティ設定に適用する場合について説明する。
【００７３】
本発明の実施の形態３に係る送信装置及び受信装置の構成は、実施の形態１で示した図５と図６の構成と同一であるので、図５及び図６を援用して説明する。なお、本実施の形態では、送信装置を端末とし、受信装置を基地局とする。
【００７４】
図１４は、本発明の実施の形態３に係るセキュリティ設定時の通信手順を示すシーケンス図である。
【００７５】
ここで、セキュリティ関係の設定でクリティカルなものとして、セキュリティの設定内容を反映させるタイミング情報が挙げられる。このタイミングは、３ＧＰＰでは、ＡＴ（Activation time）として定義され、RRCメッセージによって渡される。このＡＴは再送を考慮した値である必要がある。すなわち、端末と基地局とで同時にセキュリティの設定内
容を反映させる必要があるため、端末が受信したことの確認が取れておらず、再送のためのタイマーが動いている最中に端末側がセキュリティの設定を行ってしまっては問題があるため、再送を行う時間より長い値を取ることが必要である。また、再送時に同じＡＴを用いると再度再送が必要な場合に問題が出てくる。そのため、ここでは、図１４に示すように、ＡＴの値をさらに変更することが考えられる。この際、端末としては、たとえ最初のメッセージを受信している場合でも、後のメッセージを受けたら前の設定ではなく、今回受け取った設定を用いて動作することとなる。すなわち、前回のメッセージで指定されているＡＴの値ではなく今回のメッセージで指定されているＡＴの値である。
【００７６】
また、更なるケースとして再送のメッセージも正しく送信できない可能性がある。特に問題として考えられるのは、図１４に示したように応答が返ってこない場合で、さらに再送のメッセージが端末に届かないケースである。この場合には、端末は再送されていることに気づかずに前に受け取ったメッセージを用いて設定を行ってしまう可能性がある。このようなことをさけるため、再送のメッセージを送った際に設定するタイマーは最初にメッセージを送った際のタイマーよりも短くすることなどが考えられる。よって、受信側（本実施の形態では端末）でも早く応答を返すように処理を行うことが考えられる。具体例としては、最初のメッセージの場合には、メッセージの内容の確認、または処理等を行ってから応答を返すようにしておき、再送のメッセージの場合には、再送であることが判断できたらメッセージ内容の確認、または処理等を行う前に応答を返すなどの処理である。なお、上記の動作は、本実施の形態で記載されているセキュリティの設定のみでなく、他の処理で基地局と端末とでそろって処理を実行する必要のあるものに対して有効である。
【００７７】
なお、このセキュリティの設定内容としてはＡＴ以外を変える必要性が少ない。そのため、ＡＴの情報をRRCメッセージ内部に入れるのではなくて、RRCのヘッダに入れるなどの手段が再送の効率化のために考えられる。このように再送時に変更のあるパラメータをヘッダに入れることで、再送の際のRRCメッセージの処理、暗号化、インテグリティチェック（Integrity check）の動作等を簡易に行うことができる。
【００７８】
上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はソフトウェアで実現することも可能である。
【００７９】
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【００８０】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
【００８１】
さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。
【００８２】
２００６年８月２５日出願の特願２００６−２２９８１２の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【００８３】
本発明にかかる無線送信装置、無線受信装置及び無線通信方法は、ＲＲＣによる再送に
おいて、RRCメッセージの内容を変更すると共に、変更に応じた設定を効率よく行うことができ、３ＧＰＰの移動通信システム等に適用できる。
【図面の簡単な説明】
【００８４】
【図１】ＬＴＥで検討されている簡易なリカバリー方法を示すシーケンス図
【図２】ＬＴＥで検討されている簡易なリカバリー方法を示すシーケンス図
【図３】ｃプレーンの再送処理を示すシーケンス図
【図４】課題の説明に供する図
【図５】本発明の実施の形態１，２及び３に係る送信装置の構成を示すブロック図
【図６】本発明の実施の形態１，２及び３に係る受信装置の構成を示すブロック図
【図７】図５に示した送信装置と図６に示した受信装置との通信手順の概略を示すシーケンス図
【図８】フラグがメッセージをキャンセルする場合を示すシーケンス図
【図９】フラグが元のメッセージと同一である場合を示すシーケンス図
【図１０】フラグが元のメッセージの処理待ちである場合を示すシーケンス図
【図１１】フラグをメッセージタイプで代用する場合を示すシーケンス図
【図１２】ハンドオーバを指示するハンドオーバインジケーションの受信に端末が失敗した場合を示すシーケンス図
【図１３】ハンドオーバインジケーションの受信成功を示す応答の受信に基地局が失敗した場合を示すシーケンス図
【図１４】本発明の実施の形態３に係るセキュリティ設定時の通信手順を示すシーケンス図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008023791.tif 000017
【図２】
2008023791.tif 000018
【図３】
2008023791.tif 000019
【図４】
2008023791.tif 000020
【図５】
2008023791.tif 000021
【図６】
2008023791.tif 000022
【図７】
2008023791.tif 000023
【図８】
2008023791.tif 000024
【図９】
2008023791.tif 000025
【図１０】
2008023791.tif 000026
【図１１】
2008023791.tif 000027
【図１２】
2008023791.tif 000028
【図１３】
2008023791.tif 000029
【図１４】
2008023791.tif 000030
【国際調査報告】
2008023791.tif 000031
2008023791.tif 000032
2008023791.tif 000033
2008023791.tif 000034