JP6123009B1 - ユーザ装置、基地局、及び接続確立方法 - Google Patents

Abstract

【課題】ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、ユーザ装置がコンテクスト情報を保持しているか否かを基地局により判定することを可能とする。【解決手段】前記ユーザ装置において、前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１コンテクスト保持情報を含む接続要求メッセージを、前記基地局に送信する送信手段と、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２コンテクスト保持情報を含む接続設定メッセージを、前記基地局から受信する受信手段と、前記接続設定メッセージを受信した後、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続手段とを備える。【選択図】図７

Description

本発明は、移動通信システムにおけるユーザ装置ＵＥと基地局ｅＮＢのそれぞれが、ＵＥコンテクストを保持する技術に関連するものである。

ＬＴＥシステムにおいて、ユーザ装置ＵＥ（以下、ＵＥと記述する）における基地局ｅＮＢ（以下、ｅＮＢと記述する）との間の接続状態はＲＲＣ（Radio Resource Control）アイドル状態（RRC_Idle）と、ＲＲＣ接続状態（RRC_Connected）の２つで示される。

ＵＥがネットワークに接続する際に、コアＮＷ側のＭＭＥ（Mobility Management Entity）によりＵＥコンテクストが生成され、ＲＲＣ接続状態において、当該ＵＥコンテクストはＵＥが接続するｅＮＢ及びＵＥに保持される。なお、ＵＥコンテクストは、ベアラ関連情報、セキュリティ関連情報等を含む情報である。

ＵＥがＲＲＣアイドル状態とＲＲＣ接続状態との間を遷移する際に、コアＮＷ側も含めた呼制御のシグナリングが多く発生するため、シグナリングを如何にして削減するかが課題となっている。

例えば、ＵＥをＲＲＣ接続状態からＲＲＣアイドル状態に遷移させる際には、図１に示すようなシグナリングが発生する（非特許文献１等）。図１のケースは、ｅＮＢ２が、ＵＥ１の通信が所定時間発生しないことを検知し、ＵＥ１との接続を切断して、ＲＲＣアイドル状態に遷移させるようなケースである。

図１において、ｅＮＢ２が、ＵＥコンテクスト解放要求（UE Context Release Request）をＭＭＥ３に送信する（ステップ１）。ＭＭＥ３は、ベアラ解放要求（Release Access Bearers Request）をＳ−ＧＷ４に送信し（ステップ２）、Ｓ−ＧＷ４はベアラ解放応答（Release Access Bearers Response）をＭＭＥ３に返す（ステップ３）。

ＭＭＥ３は、ＵＥコンテクスト解放指示（UE Context Release Command）をｅＮＢ２に送信する（ステップ４）。ｅＮＢ２は、ＲＲＣ接続解放（RRC Connection Release）をＵＥ１に送信し（ステップ５）、ＵＥ１に対してＵＥコンテクストを解放させて、ＲＲＣアイドル状態に遷移させる。また、ｅＮＢ２はＵＥコンテクストを解放し、ＵＥコンテクスト解放完了（UE Context Release Complete）をＭＭＥ３に送信する（ステップ６）。

3GPP TS 36.413 V12.4.0 (2014-12) 3GPP TSG RAN Meeting #66 RP-142030 Maui, USA, 8th - 11th December 2014 3GPP TS 36.331 V12.6.0 (2015-06) 3GPP TS 36.321 V12.7.0 (2015-09) 3GPP TR 23.720 V1.2.0(2015-11)

図１に示すようなシグナリング手順では、ＲＲＣ接続解放時に多くのシグナリングが発生するのみならず、ＵＥがＲＲＣアイドル状態から再びＲＲＣ接続状態に遷移する際に、ＵＥコンテクストの設定のために多くのシグナリングが発生する。

ＵＥがＲＲＣアイドル状態とＲＲＣ接続状態との間を遷移する際のシグナリングを削減するために、ＵＥが同一ｅＮＢ内でＲＲＣ接続状態‐＞ＲＲＣアイドル状態−＞ＲＲＣ接続状態と遷移する場合に、ＵＥコンテクストをｅＮＢ及びＵＥで保持したままにしておき、再利用する方法が検討され始めている（非特許文献２）。当該方法において考えられる手順の例を図２を参照して説明する。

図２の（ａ）に示す状態は、ＵＥ１がＲＲＣ接続状態にあり、コアＮＷ側において、当該ＵＥ１に係るＳ１−ＣのコネクションとＳ１−Ｕのコネクション（図ではＳ１‐Ｃ／Ｕ）が確立されている状態である。なお、Ｓ１−Ｃのコネクションは、Ｃ−ｐｌａｎｅ信号を送るＳ１コネクションであり、Ｓ１−ＵのコネクションはＵ−ｐｌａｎｅを通すＳ１コネクションである。

（ａ）に示す状態から、（ｂ）、（ｃ）に示すように、ＲＲＣ接続解放（RRC Connection Release）によりＵＥ１がＲＲＣアイドル状態に遷移される。このとき、ｅＮＢ２におけるＵＥ１に対するＵＥコンテクストは保持されたままであり、また、ＵＥ１におけるｅＮＢ２に対するＵＥコンテクストも保持されたままであり、ＵＥ１に対するＳ１‐Ｃ／Ｕコネクションも維持されたままである。そして、（ｄ）に示すように、ＵＥ１がＲＲＣ接続状態に遷移する際に、ｅＮＢ２とＵＥ１は保持しておいたＵＥコンテクストを再利用することで、シグナリングを削減して、ＲＲＣ接続を確立する。

ここで、図２の（ｄ）に示すケースにおいては、ＵＥ１とｅＮＢ２が、それぞれ保持したＵＥコンテクストを用いてＲＲＣ接続確立が行われる例を示しているが、一般には、ｅＮＢ配下のセルには、多数のＵＥが存在し、ｅＮＢは各ＵＥが、当該ｅＮＢとの接続に利用できるＵＥコンテクストを保持しているかどうかわからない。

例えば、図３に示すように、ｅＮＢ＿Ｂとの接続で利用したＵＥコンテクストを保持するＵＥ６がＲＲＣアイドル状態のままｅＮＢ＿Ａに移動した場合において、ｅＮＢ＿ＡはＵＥ６がｅＮＢ＿Ａとの接続に利用できるＵＥコンテクストを保持しているのかどうか不明である。

このような場合を考慮して、例えば、ｅＮＢ＿Ａは、ｅＮＢ＿Ａのセルに在圏する全てのＵＥがｅＮＢ＿Ａに対するＵＥコンテクストを保持するものと仮定して、ＵＥコンテクストを再利用した接続手順を試みることが考えられる。しかし、この場合、ｅＮＢ＿Ａに対するＵＥコンテクストを保持しないＵＥとの接続手順は失敗し、ＵＥコンテクストを再利用しない通常の接続手順を再度実行することになり、遅延が生じる可能性がある。

本発明は上記の点に鑑みてなされたものであり、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、ユーザ装置がコンテクスト情報を保持しているか否かを基地局により判定することを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置であって、
前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１のメッセージを、前記基地局に送信する送信手段と、
前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２のメッセージを、前記基地局から受信する受信手段と、
前記第２のメッセージを受信した後、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続手段とを備え、
前記送信手段は、前記ユーザ装置の認証情報を含む前記第１のメッセージを、前記基地局に送信する
ことを特徴とするユーザ装置が提供される。

また、本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、
前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１のメッセージを、前記ユーザ装置から受信する受信手段と、
前記第１のメッセージを受信したことに応じて、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２のメッセージを、前記ユーザ装置に送信する送信手段と、
前記第２のメッセージを送信した後、前記基地局側コンテクスト情報を利用して、前記ユーザ装置との間で接続を確立する接続手段とを備え、
前記受信手段は、前記ユーザ装置の認証情報を含む前記第１のメッセージを、前記ユーザ装置から受信する
ことを特徴とする基地局が提供される。

また、本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置が実行する接続確立方法であって、
前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１のメッセージを、前記基地局に送信する送信ステップと、
前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２のメッセージを、前記基地局から受信する受信ステップと、
前記第２のメッセージを受信した後、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続ステップとを備え、
前記送信ステップにおいて、前記ユーザ装置は、前記ユーザ装置の認証情報を含む前記第１のメッセージを、前記基地局に送信する
ことを特徴とする接続確立方法が提供される。

また、本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局が実行する接続確立方法であって、
前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１のメッセージを、前記ユーザ装置から受信する受信ステップと、
前記第１のメッセージを受信したことに応じて、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２のメッセージを、前記ユーザ装置に送信する送信ステップと、
前記第２のメッセージを送信した後、前記基地局側コンテクスト情報を利用して、前記ユーザ装置との間で接続を確立する接続ステップとを備え、
前記受信ステップにおいて、前記基地局は、前記ユーザ装置の認証情報を含む前記第１のメッセージを、前記ユーザ装置から受信する
ことを特徴とする接続確立方法が提供される。

本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、ユーザ装置がコンテクスト情報を保持しているか否かを基地局により判定することを可能とする技術が提供される。

ＲＲＣアイドル状態に遷移する場合のシグナリングシーケンス例を示す図である。 ＵＥコンテクストを保持する場合の処理の例を説明するための図である。 課題を説明するための図である。 本発明の実施の形態における通信システムの構成図である。 本実施の形態におけるシステム全体の処理シーケンスの例を示す図である。 本実施の形態におけるシステム全体の処理シーケンスの他の例を示す図である。 本実施の形態における接続確立手順を説明するための図である。 本実施の形態における接続解放手順を説明するための図である。 システム全体の処理シーケンスの他の例を示す図である。 RRCConnectionRequest messageの仕様変更例１を示す図である。 RRCConnectionSetup messageの仕様変更例１を示す図である。 RRCConnectionSetupComplete messageの仕様変更例１を示す図である。 RRCConnectionRelease messageの仕様変更例１を示す図である。 RRCConnectionRelease messageの仕様変更例２を示す図である。 RRCConnectionRequest messageの送信時の動作に関する仕様変更例を示す図である。 RRCConnectionRequest messageの仕様変更例２を示す図である。 RRCConnectionSetup messageの受信時の動作に関する仕様変更例を示す図である。 RRCConnectionSetup messageの仕様変更例２を示す図である。 Option 1に対応するRRC connection Reject受信時のＵＥ動作の仕様変更例を示す図である。 Option 2に対応するRRC connection Reject受信時のＵＥ動作の仕様変更例を示す図である。 Option 1に対応するRRC connection Reject messageの仕様変更例を示す図である。 Option 2に対応するRRC connection Reject messageの仕様変更例を示す図である。 RRCConnectionRelease messageの仕様変更例３を示す図である。 RRCConnectionRelease messageの受信時の動作に関する仕様変更例を示す図である。 ＵＥコンテンクスト保持のための変数に関する仕様変更例を示す図である。 ｅＮＢの特定情報を通知する方法の例を示す説明するための図である。 コンテクスト取得手順例を示す図である。 RRCConnectionRequest messageの仕様変更例３を示す図である。 RRCConnectionSetup messageの仕様変更例３を示す図である。 RRCConnectionSetupComplete messageの仕様変更例２を示す図である。 RRCConnectionRequest messageの仕様変更例４を示す図である。 RRCConnectionSetupComplete messageの仕様変更例３を示す図である。 RRCConnectionRequest messageの仕様変更例５を示す図である。 RRCConnectionSetupComplete messageの仕様変更例４を示す図である。 RRCConnectionRequest messageの仕様変更例６を示す図である。 RRCConnectionSetupComplete messageの仕様変更例５を示す図である。 ＵＥの動作例を説明するためのフローチャートである。 ＵＥの動作例を説明するためのフローチャートである。 RA Responseのメッセージ例を示す図である。 RA Responseのメッセージ例を示す図である。 ＵＥの動作例を説明するためのフローチャートである。 ＬＣＩＤに関する仕様変更例を示す図である。 ＵＥコンテクストの保持に関する仕様変更例を示す図である。 ＵＥコンテクストの保持に関する仕様変更例を示す図である。 ＭＭＥとＳ−ＧＷの構成図である。 ＵＥ５０の構成図である。 ＵＥ５０のＨＷ構成図である。 ｅＮＢ１０の構成図である。 ｅＮＢ１０の構成図である。 ｅＮＢ１０のＨＷ構成図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態では、ＬＴＥのシステムを対象としているが、本発明はＬＴＥに限らずに適用可能である。また、本明細書及び特許請求の範囲では、特に断らない限り、「ＬＴＥ」の用語は３ＧＰＰの特定のＲｅｌ（リリース）に限定されない。

（システム全体構成）
図４は、本発明の実施の形態における通信システムの構成例を示す図である。図４に示すように、本実施の形態の通信システムは、ｅＮＢ１０、ｅＮＢ２０、ＭＭＥ３０、Ｓ−ＧＷ（Serving Gateway）４０、ＵＥ５０を含む。なお、図４は、コアネットワーク（ＥＰＣ）に関して、本実施の形態に関連する部分のみを示している。

ＵＥ５０は携帯電話機等のユーザ装置である。ｅＮＢ１０、２０はそれぞれ基地局である。ＭＭＥ３０は、ｅＮＢを収容し、位置登録、ページング、ハンドオーバ等のモビリティ制御、ベアラ確立／削除等を行うノード装置である。Ｓ−ＧＷ４０は、ユーザデータ（Ｕ−Ｐｌａｎｅデータ）の中継を行うノード装置である。なお、ＭＭＥ３０とＳ−ＧＷ４０からなるシステムを通信制御装置と呼ぶ。また、ＭＭＥ３０とＳ−ＧＷ４０を１つの装置で構成し、それを通信制御装置と呼ぶこととしてもよい。

図４に示すように、ＭＭＥ３０とｅＮＢ１０、２０間はＳ１−ＭＭＥインターフェースで接続され、Ｓ−ＧＷ４０とｅＮＢ１０、２０間はＳ１−Ｕインターフェースで接続される。点線の接続線は制御信号インターフェースを示し、実線の接続線はユーザデータ転送のインターフェースを示す。

本実施の形態では、前述したように、ＵＥ５０が同一ｅＮＢ内でＲＲＣ接続状態からＲＲＣアイドル状態に遷移する場合でも、当該ｅＮＢにおいてＵＥ５０のＵＥコンテクストが保持されるとともに、ＵＥ５０にも当該ｅＮＢとの接続に係るＵＥコンテクストが保持される方式を前提とする。前述したように、この方式は、シグナリング数削減を可能とする方式である。

（全体のシーケンス例）
まず、本実施の形態における通信システム全体のシーケンス例として、ＲＲＣアイドル状態のＵＥ５０に対する着信がある場合に、ＭＭＥ３０からページングを行う方式について説明する。より具体的には、ＵＥ５０がｅＮＢ１０に接続してＲＲＣ接続状態となり、ｅＮＢ１０の配下のセルでＲＲＣアイドル状態となり、同一セルで、その後に着信を受ける場合の処理シーケンスを図５を参照して説明する。

図５の処理の前提として、ＵＥ５０はｅＮＢ１０のセルにおいてＲＲＣ接続状態にあり、ＵＥ５０に関するＳ１−Ｃ／Ｕのコネクションが確立されている状態とする。図５において、Ｓ１−Ｃコネクションは、ｅＮＢ１０とＭＭＥ３０との間のコネクションとＭＭＥ３０とＳ−ＧＷ４０間のコネクションを含み、Ｓ１−Ｕコネクションは、ｅＮＢ１０とＳ−ＧＷ４０間のコネクションを含む。コネクションが確立されている場合、コネクション確立信号等のコネクションセットアップのための手順を実行することなく、該当ノード装置間でＵＥ５０に係る信号（データ）を送受信できる。

図５の手順の説明に入る前に、ＵＥ５０が最初にｅＮＢ１０に接続する際の手順の一例の概要を説明しておく（非特許文献３）。ＵＥ５０のランダムアクセス時に、ｅＮＢ１０は、RRC Connection SetupをＵＥ５０に送信し、ＵＥ５０をＲＲＣ接続状態とし、ＵＥ５０からRRC Connection Setup Completeを受信する。その後、ｅＮＢ１０は、ＭＭＥ３０からInitial Context Setup Requestを受信し、ＵＥ５０に対してRRC Security Mode Commandを送信し、ＵＥ５０からRRC Security Mode Completeを受信し、また、ＵＥ５０に対してRRC Connection Reconfigurationを送信し、ＵＥ５０からRRC Connection Reconfiguration Completeを受信し、ＭＭＥ３０に対してInitial Context Setup Responseを送信する。このような手順を経て、ＵＥ５０とｅＮＢ１０におけるＵＥコンテクストの確立、保持等がなされる。

図５に示すように、ＲＲＣ接続状態において、ｅＮＢ１０はＭＭＥ３０に対してコネクション維持指示信号を送信する（ステップ１０１）。また、ＭＭＥ３０はコネクション維持指示信号をＳ−ＧＷ４０に送信する（ステップ１０２）。

コネクション維持指示信号は、当該ＵＥ５０に関するＳ１−Ｃ／Ｕコネクションを維持しながら、ＵＥ５０への着信時に下りデータをＳ−ＧＷ４０に保留して、ＭＭＥ３０からページングを行うことを指示する信号である。

コネクション維持指示信号を受信したＳ−ＧＷ４０は、指示を確認したことを示す確認応答をＭＭＥ３０に送信し（ステップ１０３）、ＭＭＥ３０は、確認応答をｅＮＢ１０に送信する（ステップ１０４）。

ＵＥ５０に関するｅＮＢ１０からＭＭＥ３０へのコネクション維持指示信号の送信は、例えば、ｅＮＢ１０において、ＵＥ５０をＲＲＣアイドル状態に遷移させる事象が発生したことをトリガーとして行ってもよいし、ＵＥ５０が最初にｅＮＢ１０の配下でＲＲＣ接続状態になり、当該ＵＥ５０に関するＳ１−Ｃ／Ｕコネクションが確立された直後に行うこととしてもよい。

上記のＲＲＣアイドル状態に遷移させる事象とは、例えば、所定のタイマ（例：UE Inactivity Timer）の満了によって、ＵＥ５０との通信（上り下りのユーザデータ通信）が一定時間発生しないことを検知した場合であるが、これに限られるわけではない。

図５は、ＵＥ５０との通信（上り下りのユーザデータ通信）が一定時間発生しないことを検知したことをトリガーとする場合を想定しており、ステップ１０１〜１０４の後に、ＲＲＣ接続解放（RRC Connection Release）をＵＥ５０に送信し、ＵＥ５０をＲＲＣアイドル状態に遷移させる（ステップ１０５）。

本実施の形態では、ＵＥ５０が、ＲＲＣアイドル状態に遷移する場合でも、ＵＥ５０とｅＮＢ１０のそれぞれにおいて、ＲＲＣ接続時に確立したＵＥコンテクストは保持される。

その後、ＵＥ５０向けの下りデータが発生し、当該下りデータがＳ−ＧＷ４０に到着する（ステップ１０６）。ここでは、Ｓ１−Ｕコネクションは確立済みであるが、ステップ１０２で受信したコネクション維持指示信号に基づき、Ｓ−ＧＷ４０は、当該下りデータをｅＮＢ１０に転送せずにバッファに保留しておく。

Ｓ−ＧＷ４０は、下りデータ着信通知をＭＭＥ３０に送信し（ステップ１０７）、ＭＭＥ３０はＵＥ５０向けのＳ１−ＡＰページングの信号をｅＮＢ１０に送信する（ステップ１０８）。このページング自体は、既存のページングと同様であり、ＵＥ５０のトラッキングエリアの各ｅＮＢに送信されるが、図５ではｅＮＢ１０への送信を示している。

Ｓ１−ＡＰページングの信号を受信したｅＮＢ１０は、配下のＵＥ５０にＲＲＣページングの信号を送信する（ステップ１０９）。

ＲＲＣページング信号を受信したＵＥ５０は、ＲＲＣ接続確立手順を実行し、ＲＲＣ接続を確立させる（ステップ１１０）。その後、ｅＮＢ１０は、ＲＲＣ接続の確立が完了したことを示す信号であるＲＲＣ接続確立完了をＭＭＥ３０に送信する（ステップ１１１）。なお、ｅＮＢ１０は、ＵＥ５０とのＲＲＣ接続が確立したことを、例えば、ｅＮＢ１０がＵＥ５０からRRC Connection Setup Completeを受信したことで判別できる。

ＭＭＥ３０はＲＲＣ接続確立完了の信号をＳ−ＧＷ４０に送信する（ステップ１１２）。これにより、Ｓ−ＧＷ４０はＵＥ５０とｅＮＢ１０間のＲＲＣ接続が確立したと判断し、既に確立されているＵＥ５０に係るＳ１−Ｕコネクションを利用して、保留していた下りデータのｅＮＢ１０への転送を開始する（ステップ１１３）。当該下りデータはｅＮＢ１０からＵＥ５０に届く（ステップ１１４）。このようにしてＵＥ５０への下りデータの伝送が開始される。

図５のステップ１１０のＲＲＣ接続確立手順の詳細については後述する。当該ＲＲＣ接続確立手順では、ＵＥ５０とｅＮＢ１０のそれぞれでＲＲＣ接続時の確立し、保持しておいたＵＥコンテクストが利用されるので、従来は必要であった、RRC Security Mode Command、RRC Security Mode Complete、RRC Connection Reconfiguration、RRC Connection Reconfiguration Complete、等のメッセージの送受信を行うことなくＲＲＣ接続確立を行うことができる。

ここで、ＵＥ５０とｅＮＢ１０のそれぞれで保持されるＵＥコンテクストは、例えば、ＲＲＣコンフィギュレーション（RRC configuration）、ベアラコンフィギュレーション（bearer configuration： RoHC state information等を含む)、ＡＳセキュリティコンテクスト（Access Stratum Security Context）、L2/L1パラメータ（MAC、PHYのコンフィギュレーション等）等である。

また、ＵＥ５０とｅＮＢ１０とでＵＥコンテクストとして同じ情報を保持してもよいし、ＵＥ５０は、ｅＮＢ１０との接続に必要なＵＥコンテクストの情報のみを保持し、ｅＮＢ１０は、ＵＥ５０との接続に必要なＵＥコンテクストの情報のみを保持してもよい。

より具体的には、ＲＲＣアイドル状態において、例えば、ＵＥ５０とｅＮＢ１０はそれぞれ、RRC Connection Setupで運ばれるRadioResourceConfigDedicatedの情報、RRC Connection Setup Completeで運ばれる能力情報、及びセキュリティ関連情報（キー情報等）、 RRC Security Mode Commandで運ばれるセキュリティ関連情報、RRC Connection Reconfigurationで運ばれるコンフィギュレーション情報等を、ＵＥコンテクストとして保持する。なお、これらは一例であり、ＵＥコンテクストとして保持する情報は、これらに限られず、追加で情報を保持してもよいし、これらの情報の一部を保持しないこととしてもよい。

ＵＥ１０とｅＮＢ１０はそれぞれＵＥコンテクストとして上記のような情報を保持することで、ＲＲＣアイドル状態からＲＲＣ接続状態に遷移する際に、RRC Security Mode Command、RRC Security Mode Complete、RRC Connection Reconfiguration、RRC Connection Reconfiguration Complete、等のメッセージの送受信を行うことなくＲＲＣ接続確立を行うことができる。

また、本実施の形態では、ｅＮＢ１０は、ＵＥコンテクストを、当該ＵＥコンテクストに対応するＵＥの識別子（ＵＥ識別子）に対応付けて記憶手段に保持する。ＵＥ識別子の種類には限定はないが、本実施の形態では、一例として、ＵＥ識別子としてS-TMSI（SAE temporary mobile subscriber identity）を使用している。

図６は、本実施の形態におけるシステム全体の処理シーケンスの他の例を示す図である。図６は、図５の場合と同じように、ＵＥ５０がｅＮＢ１０に接続してＲＲＣ接続状態となり、ｅＮＢ１０の配下のセルでＲＲＣアイドル状態となり、同一セルで、その後に着信を受ける場合の処理シーケンスである。ただし、図６に示すシーケンスは、ステップ１１３、ステップ１１４のシーケンスが存在する点で、図５と異なる。以下、主に、図５と異なる点について説明する。

ステップ１１０の手順により、ＵＥ５０は、ＲＲＣアイドル状態からＲＲＣ接続状態になる。このとき、ＵＥ５０とｅＮＢ１０に保持されているＵＥコンテクストは、それぞれ、非アクティブ状態からアクティブ状態になる。つまり、ステップ１１０の手順により、ＵＥ５０とｅＮＢ１０に保持されているＵＥコンテクストは、それぞれ、アクティベートされる。

ステップ１１１において、ｅＮＢ１０は、ＲＲＣ接続の確立が完了したことを示す信号であるＲＲＣ接続確立完了をＭＭＥ３０に送信する。このＲＲＣ接続確立完了の信号は、ＵＥ５０のＵＥコンテクストがアクティベートされたことを示す信号であってもよい。ＭＭＥ３０はＲＲＣ接続確立完了の信号をＳ−ＧＷ４０に送信する（ステップ１１２）。

そして、図６に示す例では、ステップ１１３において、Ｓ−ＧＷ４０は、ＲＲＣ接続確立完了の信号に対する応答の信号をＭＭＥ３０に送信する。また、ステップ１１４において、ＭＭＥ３０は、ステップ１１１のＲＲＣ接続確立完了の信号に対する応答の信号をｅＮＢ１０に送信する。ステップ１１４における応答の信号は、ＵＥコンテクストがアクティベートされたことを示す信号に対するＡｃｋの信号であってもよい。

その後、図５の場合と同様に、Ｓ−ＧＷ４０は保留していた下りデータのｅＮＢ１０への転送を開始する（ステップ１１５）。当該下りデータはｅＮＢ１０からＵＥ５０に届く（ステップ１１６）。このようにしてＵＥ５０への下りデータの伝送が開始される。

（ＲＲＣ接続確立手順の例）
次に、本実施の形態におけるＵＥ５０とｅＮＢ１０との間のＲＲＣ接続確立手順について、図７のシーケンスを参照して説明する。なお、図７に示すシーケンスは、図５及び図６のステップ１１０の手順を想定しているが、これに限られない。例えば、図７に示すシーケンスが、ＵＥ５０からの発信時のＲＲＣ接続確立手順におけるものであってもよい。

図７に示すシーケンスの前に、ＵＥ５０からｅＮＢ１０にRandom Access Preambleが送信され、ｅＮＢ１０からＵＥ５０にRandom Access Responseが送信されているとする。

ＵＥ５０は、Random Access Responseに含まれるＵＬグラントで割り当てられるリソースにより、ステップ２０１において、RRC Connection Requestメッセージ（ＲＲＣ接続要求）をｅＮＢ１０に送信する。本実施の形態では、ステップ２０１において、ＵＥ５０は、RRC Connection Requestメッセージにおけるスペアビット（spare bit ：１ビット）を使用して、ＵＥ５０がＵＥコンテクストを保持していることをｅＮＢ１０に通知する。例えば、ビットが立っている（１である）場合に、ＵＥ５０はＵＥコンテクストを保持していることを示す。ＵＥ５０がＵＥコンテクストを保持していることを示すこの情報をＵＥコンテクスト保持情報と呼ぶことにする。

また、RRC Connection Requestメッセージには、上記のビットに加えて、ＵＥ５０を識別するＵＥ識別子（具体的には、S-TMSI（SAE temporary mobile subscriber identity ））が含まれる。S-TMSIは、ＵＥ５０固有の識別子から生成される一時的なＵＥ５０の識別子であり、ＵＥ５０の位置登録時等にＭＭＥ３０から払い出されるものである。本実施の形態では、ＵＥ５０と各ｅＮＢは、ＵＥ５０を識別するためのS-TMSIを保持しているものとする。

ステップ２０１で上記RRC Connection Requestメッセージを受信したｅＮＢ１０は、当該メッセージからＵＥコンテクスト保持情報とＵＥ識別子を読み出すことで、ＵＥ識別子で識別されるＵＥ５０がＵＥコンテクストを保持していることを認識し、保持している複数のＵＥコンテクストの中から、当該ＵＥ識別子に対応するＵＥコンテクストを記憶手段から検索する。すなわち、ＵＥ識別子のマッチング処理を行う。

ステップ２０２において、ｅＮＢ１０は、検索の結果、ＵＥ識別子に対応するＵＥコンテクストを検出すると、RRC Connection Setupメッセージ（ＲＲＣ接続確立メッセージ）により、ｅＮＢ１０がＵＥ５０のＵＥコンテクストを保持していることをＵＥ５０に通知するとともに、ＵＥ５０の認証のための情報を送信するようにＵＥ５０に要求する。

ＵＥ５０のＵＥコンテクストを保持していることを示す情報が含まれるRRC Connection Setupメッセージを受信したＵＥ５０は、保持していたＵＥコンテクスト（ベアラ、security key、コンフィギュレーション等）を継続使用する。

また、RRC Connection Setupメッセージに含まれるRadioResourceConfigDedicatedには、ベアラ、ＭＡＣ及びＰＨＹコンフィギュレーション等に関するパラメータ値が含まれるが、ステップ２０２において上記の通知・要求を含むRRC Connection Setupメッセージを受信したＵＥ５０は、RadioResourceConfigDedicatedにより通知されるパラメータ値を無視し、保持していたＵＥコンテクストのパラメータ値を継続使用する。なお、RadioResourceConfigDedicatedにより通知されるパラメータ値を無視せずに、通知されたパラメータ値を使用することとしてもよい。これにより、既に保持しているパラメータ値がｅＮＢ１０により変更された場合に、その変更を反映することができる。

次に、ステップ２０３において、ＵＥ５０は、RRC Connection Setup Completeメッセージに、Authentication token、shortMAC-I等の認証情報を含めてｅＮＢ１０に送信する。Authentication token、shortMAC-I等の認証情報は、ｅＮＢ１０がＵＥ５０を認証するために使用される情報である。

RRC Connection Setup Completeメッセージを受信したｅＮＢ１０は、当該メッセージに含まれる認証情報を使用して、ＵＥ５０が、ＵＥ識別子により検索されたＵＥコンテクストに対応する正しいＵＥであることを認証する。その後、ＵＥ５０とｅＮＢ１０はそれぞれ、保持していたＵＥコンテクストを利用して接続を確立（再開）する。なお、保持していたＵＥコンテクストを利用して接続を確立（再開）するにあたって、ステップ２０３は必ずしも必須ではなく、ステップ２０３を実施しないこととしてもよい。

（ＲＲＣ接続解放手順の例）
本実施の形態においては、ＵＥ５０がｅＮＢ１０からRRC Connection Releaseメッセージを受信してＲＲＣアイドル状態に遷移する際に、常にＵＥコンテクストを保持することとしてもよいし、RRC Connection Releaseメッセージ内にＵＥコンテクストを保持することを指示する情報が含まれていた場合にのみＵＥコンテクストを保持することとしてもよい。後者の例を以下に説明する。

図８に示すように、ｅＮＢ１０がＵＥ５０をＲＲＣアイドル状態に遷移させる場合に、ｅＮＢ１０はＵＥ５０に対してRRC Connection Releaseメッセージを送信する（ステップ３０１）。

当該RRC Connection Releaseメッセージには、ＲＲＣアイドル状態においてＵＥコンテクストを保持し続けることをＵＥ５０に指示する指示情報（indication）が含まれる。なお、指示情報については、新規のindicationをメッセージ中に含めても良いし、既存のrelease causeのスペアビットを用いることとしてもよい。具体例については後述する。

ＵＥ５０は、RRC Connection Releaseメッセージから上記指示情報を検知した場合、ＲＲＣアイドル状態の間、ＲＲＣアイドル状態遷移時のＵＥコンテクスト（ベアラ情報，セキュリティ情報等）を保持し続ける。

（システム全体の処理シーケンスの他の例）
図５、図６に示した例では、ＵＥ１０は、同じｅＮＢ１０の下で、ＲＲＣ接続状態とＲＲＣアイドル状態との間の遷移を行ったが、ここでは別の例として、ＵＥ５０がｅＮＢ１０に接続してＲＲＣ接続状態となり、ｅＮＢ１０の配下のセルでＲＲＣアイドル状態となり、その後に、ＵＥ５０がｅＮＢ２０の配下のセルに移動して、着信を受ける場合の処理シーケンスを図９を参照して説明する。

図９の場合も、処理の前提として、ＵＥ５０はｅＮＢ１０のセルにおいてＲＲＣ接続状態にあり、Ｓ１−Ｃ／Ｕのコネクションが確立されている状態とする。

図５、図６の場合と同様にして、ｅＮＢ１０はＭＭＥ３０に対してコネクション維持指示信号を送信する（ステップ４０１）。また、ＭＭＥ３０はコネクション維持指示信号をＳ−ＧＷ４０に送信する（ステップ４０２）。

前述したとおり、コネクション維持指示信号は、当該ＵＥ５０に関するＳ１−Ｃ／Ｕコネクションを維持しながら、ＵＥ５０への着信時に下りデータをＳ−ＧＷ４０に保留して、ＭＭＥ３０からページングを行うことを指示する信号である。

コネクション維持指示信号を受信したＳ−ＧＷ４０は、確認応答をＭＭＥ３０に送信し（ステップ４０３）、ＭＭＥ３０は、確認応答をｅＮＢ１０に送信する（ステップ４０４）。

ｅＮＢ１０は、ステップ４０１〜４０４の後に、ＲＲＣ接続解放（RRC Connection Release）をＵＥ５０に送信し、ＵＥ５０をＲＲＣアイドル状態に遷移させる（ステップ４０５）。この後に、ＵＥ５０はｅＮＢ２０配下のセルに移動する。当該RRC Connection Releaseメッセージには、ＵＥコンテクストを保持する指示が含まれており、ＵＥ５０は、ＵＥコンテクストを保持する。ただし、このＵＥコンテクストは、ｅＮＢ１０との接続に利用された情報である。

その後、ＵＥ５０向けの下りデータが発生し、当該下りデータがＳ−ＧＷ４０に到着する（ステップ４０６）。ここでは、Ｓ１−Ｕコネクションは確立済みであるが、ステップ４０２で受信したコネクション維持指示信号に基づき、Ｓ−ＧＷ４０は、当該下りデータをｅＮＢ１０に転送せずにバッファに保留しておく。

Ｓ−ＧＷ４０は、下りデータ着信通知をＭＭＥ３０に送信し（ステップ４０７）、ＭＭＥ３０はＵＥ５０向けのＳ１−ＡＰページングの信号をｅＮＢ２０に送信する（ステップ４０８）。このページング自体は、既存のページングと同様であり、ＵＥ５０のトラッキングエリアの各ｅＮＢ（１つ又は複数のｅＮＢのそれぞれ）に送信されるが、図９ではｅＮＢ２０への送信を示している。

Ｓ１−ＡＰページングの信号を受信したｅＮＢ２０は、配下のＵＥ５０にＲＲＣページングの信号を送信する（ステップ４０９）。

ＲＲＣページングを受信したＵＥ５０は、ＲＲＣ接続確立手順を実行し、ＲＲＣ接続を確立させる（ステップ４１０）。また、ｅＮＢ２０とコアＮＷ側（図９ではＳ−ＧＷ４０）との間でＮＡＳ接続手順が実行され、ｅＮＢ２０についてのＳ１−Ｃ／Ｕコネクションが確立される（ステップ４１１）。

上記により、ＵＥ５０とＳ−ＧＷ４０とのコネクションが確立されるため、Ｓ−ＧＷ４０は、ＵＥ５０への下りデータの送信を開始する（ステップ４１２、Ｓ４１３）。また、ｅＮＢ１０とＭＭＥ３０間でのＵＥコンテクストが解放されるとともに、ｅＮＢ１０についてのＳ１−Ｃ／Ｕコネクションが解放される（ステップ４１４）。

上記の例では、ステップ４１０のＲＲＣ接続確立手順において、ＵＥ５０は、図７のステップ２０１のメッセージを送信するが、ｅＮＢ２０は、ＵＥ５０に対応するＵＥコンテクストを保持していないと判断するため、通常のＲＲＣ接続手順が実施される。もしくは、ｅＮＢ２０は、自身がＵＥ５０に対応するＵＥコンテクストを保持していないと判断した場合に、ＲＲＣ接続確立手順におけるメッセージによりＵＥ５０から通知されるＰＣＩ（ＵＥ５０がＵＥコンテクストを保持したセルのｅＮＢ１０を識別するセルＩＤ）等に基づいて、ｅＮＢ１０からＵＥ５０のＵＥコンテクストを取得し、当該ＵＥコンテクストを利用して、ＲＲＣ接続を行うこととしてもよい。

（仕様変更例）
次に、図７、図８で説明した各種の通知を行う場合における３ＧＰＰ仕様書（３ＧＰＰ ＴＳ ３６．３３１、非特許文献３）の記載例（抜粋）を図１０〜図１４に示す。図１０〜図１４において、非特許文献３からの変更箇所に下線が引かれている。非特許文献３からの変更箇所に下線が引かれている点は、他の仕様変更例の図においても同様である。

図１０（ａ）は、図７のステップ２０１でＵＥ５０から送信されるRRC Connection Requestメッセージの例を示す。図１０（ａ）に示すように、ue-ContextStoring（例：１ビット）が追加されている。図１０（ｂ）に示すように、ue-ContextStoringは、ＵＥ５０が、前回のＲＲＣ接続において使用したＵＥコンテクストを保持していることを示す情報である。また、図１０（ａ）に示すとおり、S-TMSIが含まれている。

図１１（ａ）は、図７のステップ２０２でｅＮＢ１０から送信されるRRC Connection Setupメッセージの例を示す。図１１（ａ）に示すように、ue-ContextStoredとue-AuthenticationInfoReqが追加されている。

図１１（ｂ）に示すように、ue-AuthenticationInfoReqは、ＵＥに対して認証情報を送信するよう要求する情報である。ue-ContextStoredは、ｅＮＢが、RRC Connection Setupの対象とするＵＥのＵＥコンテクストを保持することを示す情報である。ＵＥは、この情報（フィールド）が存在することを検出した場合、当該RRC Connection Setupメッセージにより通知されるradioRecourceConfigDedicatedフィールドを無視する。なお、前述したとおり、radioRecourceConfigDedicatedフィールドを無視せずに、これにより通知されたパラメータ値を適用することとしてもよい。

図１２は、図７のステップ２０３においてＵＥ５０から送信されるRRC Connection Setup Completeメッセージの例を示す。図１２に示すとおり、認証情報であるue-AuthenticationToken及びue-AuthenticationInfoが追加されている。

図１３〜図１４は、図８のステップ３０１においてｅＮＢ１０から送信されるRRC Connection Releaseメッセージの例１、２を示す。

図１３は、Cause valueを使用してＵＥコンテクスト保持指示を行う例（例１）を示す。この場合、図１３（ａ）に示すように、ReleaseCause内にUEcontextHoldingが追加される。図１３（ｂ）に示すとおり、ue-ContextHoldingの値は、ＵＥがＲＲＣアイドル状態の間、ＵＥコンテクストを保持し続ける指示を示す。

図１４は、新規indicationを使用してＵＥコンテクスト保持指示を行う例（例２）を示す。図１４（ａ）に示すように、新規indicationとしてue-ContextHoldingが追加されている。図１４（ｂ）に示すとおり、ue-ContextHoldingは、ＵＥがＲＲＣアイドル状態の間、ＵＥコンテクストを保持し続ける指示を示す。

（変形例１：ＲＲＣ接続確立手順、ＲＲＣ接続解放手順の他の例）
本実施の形態におけるＵＥ５０とｅＮＢ１０との間のＲＲＣ接続確立手順について、図７のシーケンスを参照して信号の内容を含めて説明したが、以下では、ＲＲＣ接続確立手順の他の例について、変形例１として説明する。また、ＲＲＣ接続解放手順についても、信号の内容についての他の例を説明する。なお、変形例１の前に、図７のシーケンスを参照して説明した例を、便宜上、基本例と呼ぶ。

＜変形例１のＲＲＣ接続確立手順＞
変形例１のＲＲＣ接続確立手順におけるシーケンス自体は、図７に示したシーケンスと同じであるので、図７を参照して変形例１のＲＲＣ接続確立手順について説明する。変形例１においても、図７に示すシーケンスは、図５及び図６のステップ１１０の手順を想定しているが、これに限られない。例えば、図７に示すシーケンスが、ＵＥ５０からの発信時のＲＲＣ接続確立手順におけるものであってもよい。

図７に示すシーケンスの前に、ＵＥ５０からｅＮＢ１０にRandom Access Preambleが送信され、ｅＮＢ１０からＵＥ５０にRandom Access Responseが送信されているとする。

ＵＥ５０は、Random Access Responseに含まれるＵＬグラントで割り当てられるリソースにより、ステップ２０１において、RRC Connection Requestメッセージ（ＲＲＣ接続要求）をｅＮＢ１０に送信する。変形例１では、ステップ２０１において、ＵＥ５０は、ＵＥコンテクストを保持している場合に、認証情報をRRC Connection Requestメッセージに含めて送信する。当該認証情報は、ｅＮＢ１０がＵＥ５０を認証するために使用される情報であり、例えば、前回のＲＲＣ接続で使用したC-RNTI、PCI、及びShortMAC-Iを含む。

また、この認証情報は、ＵＥ５０がＵＥコンテクストを保持していることをｅＮＢ１０に通知するためのＵＥコンテクスト保持情報の例でもある。

ステップ２０１で上記RRC Connection Requestメッセージを受信したｅＮＢ１０は、認証情報を用いてＵＥ５０の認証を行い、認証に成功し、かつ、ＵＥ５０のＵＥコンテクストを保持していることを検知した場合に、ＵＥ５０に対し、ＵＥ５０が保持しているＵＥコンテクストをアクティベート（アクティブ化）することを指示する情報を含むRRC Connection Setupメッセージ（ＲＲＣ接続確立メッセージ）をＵＥ５０に送信する（ステップ２０２）。上記の検知は、例えば、ｅＮＢ１０が、保持している複数のＵＥコンテクストの中から、ＵＥ固有の識別子（例：S-TMSI、C-RNTI、shortMAC-I）に対応するＵＥコンテクストを記憶手段から検索することにより行うことができる。なお、ＵＥコンテクストをアクティベート（アクティブ化）することを指示する情報は、ｅＮＢ１０がＵＥ５０のＵＥコンテクストを保持していることを示すコンテクスト保持情報の例である。

上記の認証に失敗した場合、ｅＮＢ１０は、RRC接続を拒否するRRC Connection RejectメッセージをＵＥ５０に送信する。認証が成功してもｅＮＢ１０がＵＥ５０のＵＥコンテクストを保持していることを検知できなかった場合には、ｅＮＢ１０は、ＵＥ５０が保持しているＵＥコンテクストをアクティベート（アクティブ化）することを指示する情報を含まないRRC Connection Setupメッセージ（ＲＲＣ接続確立メッセージ）をＵＥ５０に送信する。

ＵＥコンテクストをアクティベートすることを指示する情報が含まれるRRC Connection Setupメッセージを受信したＵＥ５０は、保持していたＵＥコンテクスト（ベアラ、security key、コンフィギュレーション等）をアクティベートする。アクティベートするとは、保持していたＵＥコンテクストを有効化することであり、例えば、各種無線リソースの設定、測定設定、認証キーの更新処理等を含む。なお、アクティベートする処理は特定の処理に限られるわけではない。

また、RRC Connection Setupメッセージに含まれるRadioResourceConfigDedicatedには、ベアラ、ＭＡＣ及びＰＨＹコンフィギュレーション等に関するパラメータ値が含まれ得るが、ステップ２０２において上記のアクティベート指示を含むRRC Connection Setupメッセージを受信したＵＥ５０は、RadioResourceConfigDedicatedにより通知されるパラメータ値を適用する。適用は、例えば、非特許文献３における「5.3.10 Radio resource configuration」に従ってなされる。つまり、RadioResourceConfigDedicatedに含まれる情報に基づく設定を行う。

一例として、ＵＥ５０が、ＵＥコンテクストの一部として、前回のＲＲＣ接続時のRadioResourceConfigDedicatedにおける「Ａ」という情報を保持していて、ステップ２０２においてRadioResourceConfigDedicatedにより「Ｂ」という情報を受信した場合、ＵＥ５０は、「Ａ」という情報に加えて、「Ｂ」という情報を使用できる。

また、ＵＥ５０が、ＵＥコンテクストの一部として、前回のＲＲＣ接続時のRadioResourceConfigDedicatedにおける「Ａ」という情報を保持していて、ステップ２０２においてRadioResourceConfigDedicatedにより、「Ａ」と同じ種類であるが値の異なる「Ａ´」を受信した場合、保持していた「Ａ」は、ステップ２０２で受信した「Ａ´」により更新（変更）される。

つまり、上記の処理により、保存していたRadioResourceConfigDedicatedの情報と、ステップ２０２において受信したRadioResourceConfigDedicatedの情報とのパラメータ差分の設定を行うことができる。これをdelta configurationと呼ぶ。

次に、ステップ２０３において、ＵＥ５０は、RRC Connection Setup CompleteメッセージをｅＮＢ１０に送信する。

＜変形例１の仕様変更例＞
次に、変形例１における３ＧＰＰ仕様書（３ＧＰＰ ＴＳ ３６．３３１、非特許文献３）の記載例（抜粋）を図１５〜図２５に示す。図１５〜図２５において、非特許文献３からの変更箇所に下線が引かれている。

図１５は、図７のステップ２０１でＵＥ５０からRRC Connection Requestメッセージを送信する際のＵＥ５０の動作を規定する仕様の変更例を示す。

図１５における「1> if the UE supports the RRCConnectionRequest-r13-IEs and criticalExtRRC-ConnEstReqAllowed is included in SystemInformationBlockType2:」、「2>set the RRCConnectionRequest-r13-IEs in the RRCConnectionRequest message;」は、「RRCConnectionRequest-r13-IEs」（変形例１における認証情報を運ぶメッセージ）を、ＵＥ５０とｅＮＢ１０の両方がサポートしている場合に、当該メッセージをＵＥ５０が送信することを示す。ｅＮＢ１０が「RRCConnectionRequest-r13-IEs」に対応していることを示すcriticalExtRRC-ConnEstReqAllowedは、SIB2によりｅＮＢ１０からＵＥ５０に報知される。

「1 >if the UE stores the valid AS configuration into VarAS-Config:」、「2>set the ue-Identity to UE-AS-ConfigIdentity;」は、ＵＥ５０が、正当なＵＥコンテクスト（AS configuration）を保持している場合に、ue-Identity（後述するue-Identity-r13）に認証情報（UE-AS-ConfigIdentity）を含めることを示す。これにより、認証情報がRRC Connection RequestメッセージによりｅＮＢ１０に送信される。VarAS-Configは、ＵＥコンテクスト（AS configuration）を格納する変数である。

図１６（ａ）は、図７のステップ２０１でＵＥ５０から送信されるRRC Connection Requestメッセージの例を示す。図１６（ａ）に示すように、認証情報である「UE-AS-ConfigIdenity」が追加されている。図１６（ｂ）に示すように、「UE-AS-ConfigIdenity」は、ＵＥ５０とＥ−ＵＴＲＡＮ（つまり、ｅＮＢ１０）に保持されているAS configuration（ＵＥコンテクスト）を識別し、認証する情報を含む。当該情報は、例えば、前回のＲＲＣ接続時のC-RNTI、PCI、及びShortMAC-Iを含む。

図１７は、図７のステップ２０２でｅＮＢ１０から送信されるRRC Connection SetupメッセージをＵＥ５０が受信した際の動作を規定する仕様の変更例を示す。

図１７において、「1>if the valid AS configuration is stored into VarAS-Config:」、「2 >if the ue-AS-ConfigActivate is set to true and nextHopChainingCount is included in the RRCConnectionSetup message:」として記載されているように、当該仕様に従って動作するＵＥ５０は、RRC Connection Setupメッセージを受信すると、まず、ＵＥコンテクスト（valid AS configuration）を保持しているかどうかを確認し、保持していたら、RRC Connection Setupメッセージにおいて「ＵＥコンテクストのアクティベート（有効化）が指示されており（ue-AS-ConfigActivate is set to true）、かつ、nextHopChainingCountが含まれている」か否かを判定する。nextHopChainingCountは、認証キーを更新する際に用いられる値である。

「ＵＥコンテクストのアクティベートが指示されており（ue-AS-ConfigActivate is set to true）、かつ、nextHopChainingCountが含まれている」と判定された場合、ｅＮＢ１０での認証が成功したと判断し、保持していたＵＥコンテクストのアクティベート（有効化）を実施する。

具体的には、まず、「3>perform the radio resource configuration procedure in accordance with the radioResourceConfigDedicated stored into VarAS-Config and as specified in 5.3.10;」として記載されているように、VarAS-Configに保持しているradioResourceConfigDedicated（無線リソース設定情報）に従って、無線リソース設定を実行する。

次に、「3 >perform the measurement configuration procedure in accordance with the measConfig stored into VarAS-Config as specified in 5.5.2」として記載されているように、保持していたmeasConfig（測定設定情報）に従って、測定設定（measurement configuration）を行う。また、「3>update the KeNB key based on the KASME key to which the current KeNB is associated, using the nextHopChainingCount value included in the RRCConnectionSetup message, as specified in TS 33.401 [32];」から、「3>configure lower layers to apply ciphering using the previously configured algorithm, the KRRCenc key and the KUPenc key immediately, i.e., ciphering shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate the successful completion of the procedure ;」までの手順により、security keyの更新が実行される。

一方、ＵＥ５０がＵＥコンテクストを保持している場合でも、「ＵＥコンテクストのアクティベートが指示されており（ue-AS-ConfigActivate is set to true）、かつ、nextHopChainingCountが含まれている」かどうかの判定がＮｏとなる場合（例：ue-AS-ConfigActivateを受信しない場合）には、ｅＮＢ１０がＵＥコンテクストを保持していないと判断できる。そして、「2>else: 3>release all the AS configuration stored into VarAS-Config;」として記載されているように、ＵＥ５０は、保持していたＵＥコンテクストを解放する。"解放する"とは、例えば、保持していたＵＥコンテクストを削除することである。

「ＵＥコンテクストのアクティベートが指示されており（ue-AS-ConfigActivate is set to true）、かつ、nextHopChainingCountが含まれている」かどうかの判定がＹｅｓとなる場合、Ｎｏとなる場合のいずれの場合も、「1>perform the radio resource configuration procedure in accordance with the received radioResourceConfigDedicated and as specified in 5.3.10 ;」として記載されているように、RRCConnectionSetupメッセージで受信したradioResourceConfigDedicatedを適用する。これにより、前述したdelta configurationを行うことが可能となる。

図１８（ａ）は、図７のステップ２０２でｅＮＢ１０から送信されるRRC Connection Setupメッセージの例を示す。図１８（ａ）に示すように、ue-AS-ConfigActivateとnextHopChainingCountが追加されている。図１８（ｂ）に示すように、ue-AS-ConfigActivateは、ＵＥ５０が、保持していたＵＥコンテクストの利用を再開することを示す。

前述したとおり、ｅＮＢ１０は、認証NGの場合に、RRC connection RejectメッセージをＵＥ５０に送信する。また、認証NGであるか否かにかかわらず、ｅＮＢ１０は、例えば輻輳によりRRC Connectionを拒否し、RRC connection RejectメッセージをＵＥ５０に送信する場合もある。

変形例１において、RRC connection Rejectメッセージを受信したＵＥ５０は、例えば、以下のOption 1又はOption 2の動作を実行する。

Option 1：ＵＥ５０は、RRC connection RejectでAS configuration（ＵＥコンテクスト）を解放するように指示されたら解放する。逆にそうでなければ（解放指示がない場合）、AS configurationは保持したままとする。

Option 2：ＵＥ５０は、RRC connection RejectでAS configurationを保持（storing）するように指示されたら保持したままとする。逆にそうでなければ（保持の指示がない場合）、AS configurationを解放する。

Option 1に対応するRRC connection Reject受信時のＵＥ動作の仕様変更例を図１９に示し、Option 2に対応するRRC connection Reject受信時のＵＥ動作の仕様変更例を図２０に示す。

図１９に「1>if ue-AS-ConfigRelease is included and the UE stores the AS configuration into VarAS-Config specified in 7.1: 2>release the AS configuration stored into VarAS-Config;」と記載されているように、ＵＥ５０は、解放指示（ue-AS-ConfigRelease）を受信したら、ＵＥコンテクストを解放する。「1>else if ue-AS-ConfigRelease is not included and the UE stores the AS configuration into VarAS-Config: 2>keep storing the AS configuration into VarAS-Config;」と記載されているように、解放指示がない場合、ＵＥ５０は、ＵＥコンテクストを保持し続ける。

また、解放指示がない場合において、「2>if ue-AS-ConfigValidityTime is included: 3>overwrite the AS configuration validity time with the received value in ue-AS-ConfigValidityTime;」と記載されているように、ＵＥコンテクストの有効時間（validity time）をue-AS-ConfigValidityTimeの値で上書きする。これにより、ＵＥコンテクストの保存時間（後述）を変更することができる。

図２０に「1>if ue-AS-ConfigStoring is included and the UE stores the AS configuration into VarAS-Config specified in 7.1: 2> keep the AS configuration stored into VarAS-Config;」と記載されているように、option 2では、ＵＥ５０は、保持指示（ue-AS-ConfigStoring）を受信したら、ＵＥコンテクストを保持し続ける。また、保持指示がある場合において、「2>if ue-AS-ConfigValidityTime is included: 3>overwrite the AS configuration validity time with the received value in ue-AS-ConfigValidityTime;」と記載されているように、ＵＥコンテクストの有効時間（validity time）をue-AS-ConfigValidityTimeの値で上書きする。

また、「1> else if ue-AS-ConfigStoring is not included and the UE stores the AS configuration into VarAS-Config: 2>release the AS configuration into VarAS-Config;」と記載されているように、保持指示がない場合、ＵＥ５０は、ＵＥコンテクストを解放する。

図２１に、Option 1に対応するRRC connection Rejectメッセージの仕様変更例を示し、図２２に、Option 2に対応するRRC connection Rejectメッセージの仕様変更例を示す。図２１、２２に示すとおり、ue-AS-ConfigValidityTimeは、ＲＲＣアイドル状態中におけるＵＥコンテクストの更新された最大保持時間を示す。

＜変形例１におけるＲＲＣ接続解放手順について＞
変形例１におけるＲＲＣ接続解放手順は、図８を参照して説明した手順と同様である。メッセージの内容については、図１３、図１４に示したものを使用してもよいし、以下に説明するように他の例を使用してもよい。

図２３（ａ）は、図８のステップ３０１においてｅＮＢ１０から送信されるRRC Connection Releaseメッセージの例３を示す。図２３（ａ）に示すように、ue-AS-ConfigDeactiveが含まれる。ue-AS-ConfigDeactiveは、前述したＵＥコンテクスト保持指示に相当する。また、ＵＥコンテクストを保持する期間（時間）を示すue-AS-ConfigValidityTimeが追加されている。図２３（ｂ）に示すように、ue-AS-ConfigDeactiveは、ＵＥ５０が、ＲＲＣアイドル状態にある間、ＵＥコンテクストを保持することを示す。ue-AS-ConfigValidityTimeは、ＵＥ５０が、ＲＲＣアイドル状態にある間、ＵＥコンテクストを保持する最大時間（保持期限）を示す。

図２４は、図２３に示すRRC Connection Releaseメッセージを使用する場合に、RRC Connection Releaseメッセージを受信するＵＥ５０の動作を規定する仕様の変更例を示す。図２４の下線部に示したように、当該仕様に従って動作するＵＥ５０は、RRC Connection Releaseメッセージにue-AS-ConfigDeactiveが含まれている（ue-AS-ConfigDeactive is set to true）ことを確認すると、ＵＥコンテクストとして、現在のradioResourceConfigDedicated（無線リソース設定情報）、securityAlgorithmConfig（セキュリティアルゴリズム設定情報）、及びmeasConfig（測定設定情報）をVarAS-Configに格納する。また、ＵＥ５０は、PCellのphysCellIdをVarAS-Configに格納し、現在のue-IdentityをVarAS-Configに格納する。

＜ＵＥコンテクストの保持期間について＞
ＵＥコンテクスト保持指示を含むRRC Connection Releaseメッセージを受信して、ＲＲＣアイドル状態に移行したＵＥ５０（及びｅＮＢ１０）は、基本的に、ＲＲＣアイドル状態の間、ＵＥコンテクストを保持し続ける。ただし、ＲＲＣアイドル状態にある期間が非常に長い場合等において、ＵＥ５０及びｅＮＢ１０がＵＥコンテクストを保持し続けることは、ＵＥ５０及びｅＮＢ１０のそれぞれにおいて負荷となる。

そこで、変形例１では、ＵＥ５０がＵＥコンテクストの保持する有限の時間（ＵＥコンテクスト保持期限）を設けることとしている。既に説明したように、ue-AS-ConfigValidityTimeが当該時間を示す。

例えば、当該時間をＴとすると、ＵＥ５０は、ＵＥコンテクスト保持指示を含むRRC Connection Releaseメッセージを受信し、ＲＲＣアイドル状態に遷移して、ＵＥコンテクストを保持したまま、ＲＲＣアイドル状態が継続する場合でも、ＵＥコンテクストの保持を開始した時刻（＝ＵＥコンテクスト保持指示を含むRRC Connection Releaseメッセージを受信した時刻）から、Ｔが経過した時点で、ＵＥコンテクストは無効になったと判断し、当該ＵＥコンテクストを解放（削除）する。同じ時間Ｔは、ｅＮＢ１０にも設定され、ｅＮＢ１０は、ＵＥ５０と同様にして、ＵＥコンテクストの保持を開始した時刻（＝ＵＥコンテクスト保持指示を含むRRC Connection Releaseメッセージを送信した時刻）から、Ｔが経過した時点で、ＵＥコンテクストは無効になったと判断し、当該ＵＥコンテクストを解放（削除）する。

上記のようなＵＥコンテクスト保持期限を設ける場合の仕様書（非特許文献３）の変更例を図２５に示す。図２５は、仕様書の「7.1 UE variables」に、ＵＥコンテクストを保持する変数であるVarAS-Configが追加されたことを示す。図２５に示すように、VarAS-Configは、ＲＲＣアイドル状態の間にＵＥ５０に格納されるＵＥコンテクスト（AS configuration）を含む。また、ＵＥ５０は、ＲＲＣ接続状態を離れてから、所定の期間（上記のＴ）が経過した場合に、ＵＥコンテクストが無効になったと判断する。

また、図２５に示すように、VarAS-Configは、ＵＥコンテクスト（AS configuration）として、RadioResourceConfigDedicated, SecurityAlgorithmConfig, MeasConfig, NextHopChainingCount, PhysCellId, S-TMSI, C-RNTIを含む。ただし、これらは例であり、これらのうちの一部を保持しないこととしてもよい。また、これら以外の情報を保持してもよい。

ＵＥコンテクストを保持する所定の期間（上記のＴ）は、仕様により固定的に定めることとしてもよいし、図２５の例のように、ue-AS-ConfigValidityTimeを用いてｅＮＢ１０からＵＥ５０に設定することとしてもよい。

上記のようにしてＵＥコンテクスト保持期限を設けることは、基本例においても適用可能である。
（変形例２：Context Fetch）
図９の例において前述したように、ＵＥ５０が、ＵＥコンテクストを持たないｅＮＢ２０のセルに移動した場合でも、ｅＮＢ２０は、ＵＥ５０から通知される情報に基づいて、ｅＮＢ１０を特定し、ｅＮＢ１０からＵＥ５０のＵＥコンテクストを取得し、当該ＵＥコンテクストを利用して、ＲＲＣ接続を行うことが可能である。このように、あるｅＮＢが他のｅＮＢからＵＥコンテクストを取得することをContext Fetchと呼ぶ。

以下では、ＵＥ５０がｅＮＢ１０の配下でＲＲＣ接続状態からＲＲＣアイドル状態になり、その後、ＵＥ５０が、ｅＮＢ１０とは異なるｅＮＢ２０の配下のセルの移動する場合（例：図９に示したケース）について、ｅＮＢ２０がＵＥコンテクストを取得するための処理について説明する。なお、ｅＮＢ１０とｅＮＢ２０はそれぞれ、コンテクスト保持機能を有するとともに、以下で説明するように、コンテクスト取得手順を実行する機能を有している。

まず、図２６を参照して、ＵＥ５０とｅＮＢ２０間の処理を説明する。図２６に示す処理の前提として、ＵＥ５０は、ＲＲＣアイドル状態にあり、ｅＮＢ１０との間の接続時におけるＵＥコンテクストを保持している。そして、ＵＥ５０は、ＲＲＣアイドル状態のままでｅＮＢ２０配下のセルに移動し、発信を実施することを契機として、もしくは着信を受けたことを契機としてＲＲＣ接続状態への遷移手順が起動された状況を想定する。

ステップ４５１にてRandom Access PreambleがＵＥ５０からｅＮＢ２０に送信され、ステップ４５２にて、Random Access ResponseがｅＮＢ２０からＵＥ５０に返される。

ステップ４５３において、ＵＥ５０は、RRC Connection RequestメッセージをｅＮＢ２０に送信する。ステップ４５３で送信するメッセージには、ＵＥ５０が保持するＵＥコンテクストに対応するｅＮＢ側のＵＥコンテクストを保持するｅＮＢ（ここではｅＮＢ１０）を特定する情報と、当該ＵＥコンテクストがＵＥ５０のものであることを特定するための情報（ＵＥ５０のＵＥコンテクストを特定する情報）とを含む。また、RRC Connection Requestメッセージは、ＵＥ５０のＵＥコンテクストを認証するための認証情報を含む。認証情報は、例えば、前回のＲＲＣ接続時のC-RNTI、PCI、及びShortMAC-Iである。

本例では、ｅＮＢを特定する情報とＵＥコンテクストを特定する情報とを有するID（ここではresume IDと呼ぶことにする）がRRC Connection Requestメッセージに含まれている。

RRC Connection Requestメッセージで送信されるresume IDのビット長は例えば２４ビットである。そして、例えば、resume IDの上位数ビット、下位数ビットでそれぞれｅＮＢ及びＵＥコンテクストをする。一例としては、RRC Connection Requestメッセージで送信されるresume IDにおける上位８ビットをｅＮＢの特定用の情報とし、下位１６ビットをＵＥコンテクストの特定用の情報とすることが考えられる。なお、これらの数値は一例に過ぎない。

ただし、一般には、多くのｅＮＢが多くのＵＥコンテクストを保持することが想定されるため、２４ビットのresume IDでは、特定のＵＥのＵＥコンテクストを保持するｅＮＢを特定できない場合が生じ得る。すなわち、例えば、ｅＮＢ２０は、RRC Connection Requestメッセージのresume IDにおけるｅＮＢ特定用情報に対応する複数のｅＮＢ（Context Fetchを行う宛先候補のｅＮＢ）の情報（アドレス等）を有している場合には、どのｅＮＢへContext Fetchを行ってよいかを判別できない。

そこで、本例では、そのような場合に、上記のresume ID（これをshort resume IDと呼ぶ）よりもビット長の長いresume ID（これをlong resume IDと呼ぶ）をｅＮＢからＵＥに要求することとしている。以下のステップは、このような要求を行う場合の例である。short resume IDは、ＵＥがＵＥコンテクストを保持していることを示すコンテクスト保持情報の例である。

ステップ４５４において、ｅＮＢ２０は、ＵＥ５０にlong resume ID を要求する情報を含むRRC Connection SetupメッセージをＵＥ５０に送信する。また、RRC Connection Setupメッセージには、ＵＥコンテクストをアクティベートするための情報が含まれる。ステップ４５５において、ＵＥ５０は、long resume ID を含むRRC Connection Setup CompleteメッセージをｅＮＢ２０に送信する。

long resume IDのビット長は例えば４０ビットである。そして、例えば、long resume IDにおける上位２４ビットをｅＮＢの特定用の情報とし、下位１６ビットをＵＥコンテクストの特定用の情報とすることが考えられる。なお、これらの数値は一例に過ぎない。

また、short resume IDとlong resume IDを組み合わせて使用してもよい。例えば、short resume IDの先頭（上位）１６ビットでＵＥコンテクストを特定し、「short resume IDの残り８ビット＋long resume IDの４０ビット＝４８ビット」でｅＮＢを特定することとしてもよい。また、resume IDを全体で所定ビット長（例：４０ビット）とし、最初の所定ビット（例：２４ビット）をRRC Connection Requestメッセージに含め、残りの所定ビット（例：１６ビット）をRRC Connection Setup Completeメッセージに含めるようにしてもよい。

また、例えば、RRC Connection Requestメッセージに含めるshort resume IDを４０ビットとして、short resume IDに、ｅＮＢの特定用の情報とＵＥコンテクストの特定用の情報に加えて、当該ＵＥコンテクストに対応するＵＥの認証のための情報（shortMAC-Iに相当する情報）を含めてもよい。同様に、例えば、５６ビットのlong resume IDに、ｅＮＢの特定用の情報とＵＥコンテクストの特定用の情報に加えて、当該ＵＥコンテクストに対応するＵＥの認証のための情報（shortMAC-Iに相当する情報）を含めてもよい。

なお、short Resume IDでｅＮＢとＵＥコンテクストを特定できる場合には、ステップ４５４のRRC Connection Setupの送信、ステップ４５５のRRC Connection Setup Completeの送信は行われるが、long Resume IDの要求及びlong Resume IDの送信は含まない。また、short Resume IDが自分（ｅＮＢ２０）を示す場合、つまり、ｅＮＢ２０がＵＥコンテクストを保持する場合には、他のｅＮＢに対するContext Fetchを行わない。ただし、short Resume IDでｅＮＢとＵＥコンテクストを特定できる場合でも、long Resume IDの要求及びlong Resume IDの送信を含むこととしてもよい。

ステップ４６０において、ｅＮＢ２０は、ＵＥ５０から受信したresume ID（short resume IDのみ、 long resume IDのみ、又はlong resume IDとshort resume IDの組み合わせ）により、ＵＥコンテクストを保持するｅＮＢとしてｅＮＢ１０を特定し、ｅＮＢ１０との間でコンテクスト取得手順を実行する。

次に、コンテクスト取得手順例について図２７を参照して説明する。ステップ４５５において、ＵＥ５０は、RRC Connection Setup CompleteメッセージをｅＮＢ２０に送信する。

ステップ４６１において、ｅＮＢ２０は、resume IDにより識別されるｅＮＢ１０に対してコンテクスト要求メッセージを送信する。コンテクスト要求メッセージには、resume IDと認証情報が含まれる。なお、後述するように、resume ID自身に認証情報を含む場合には、resume IDとは別の認証情報を含めないこととしてもよい。

ステップ４６１で、コンテクスト要求メッセージを受信したｅＮＢ１０は、ＵＥ５０のＵＥコンテクストを特定する情報（例:short resume IDの下位１６ビット、long resume IDの下位１６ビット等）に基づいて、ｅＮＢ１０において記憶手段に保持されている複数のＵＥコンテクストの中から、ＵＥ５０のＵＥコンテクストを特定・取得するとともに、認証情報により認証を行う。ここでは認証に成功したとする。

そして、ステップ４６２で、ｅＮＢ１０は、取得したＵＥコンテクストを含むコンテクスト応答メッセージをｅＮＢ２０に送信する。

ＵＥ５０のＵＥコンテクストを取得したｅＮＢ２０は、ステップ４７１において、例えば、RRC Connection ReconfigurationメッセージをＵＥ５０に送信する。また、ステップ４７２において、ＵＥ５０は、RRC Connection Reconfiguration CompleteメッセージをｅＮＢ２０に送信する。これにより、ＵＥ５０とｅＮＢ２０は、ＵＥコンテクストを再利用して、ＵＥ５０とｅＮＢ２０との間の接続を確立し、状態をＲＲＣ接続状態に遷移させる。

なお、ＵＥ５０とｅＮＢ２０は、保持／取得したＵＥコンテクストを再利用することでＵＥ５０とｅＮＢ２０との間のＲＲＣ接続を確立できるので、ステップ４７１とステップ４７を実行しないこととしてもよい。もしくは、ＵＥ５０は、RRC Connection Reconfigurationメッセージで受信するコンフィギュレーション情報のうちの一部又は全部を無視してもよい。また、無視せずに、RRC Connection Reconfigurationメッセージで受信するコンフィギュレーション情報を適用してもよい。

また、ｅＮＢ２０が、コンテクスト取得手順を実行したが、目的のＵＥコンテクストを取得できなかった場合（ステップ４７３）、例えば、RRC Connection Releaseメッセージを送信し、ＵＥ５０をＲＲＣアイドル状態とする（ステップ４７４）。

＜変形例２の仕様変更例＞
次に、変形例２における３ＧＰＰ仕様書（３ＧＰＰ ＴＳ ３６．３３１、非特許文献３）の記載例（抜粋）を図２８〜図３０に示す。図２８〜図３０において、非特許文献３からの変更箇所に下線が引かれている。

図２８（ａ）は、図２６のステップ４５３でＵＥ５０から送信されるRRC Connection Requestメッセージの例を示す。

図２８（ａ）に示すように、認証情報であるUE-AS-ConfigIdenityに加えて、上述したshort resume IDに相当するshortResumeIdentityが追加されている。図２８（ｂ）に示すように、本例でのshortResumeIdentityは、ＵＥコンテクスト（AS configuration）と、 当該ＵＥコンテクストを格納するｅＮＢを識別するための２４ビット長の識別子である。

図２９（ａ）は、図２６のステップ４５４でｅＮＢ２０から送信されるRRC Connection Setupメッセージの例を示す。図２９（ａ）に示すように、前述したue-AS-ConfigActivateとnextHopChainingCountに加えて、requestLongResumeIdentityが示されている。requestLongResumeIdentityは、前述したlong resume IDの要求に相当する。図２９（ｂ）に示すように、requestLongResumeIdentityは、ＵＥに対して、longResumeIdentity（long resume ID）を提供することを要求することを示す。

図３０（ａ）は、図２６のステップ４５５でＵＥ５０から送信されるRRC Connection Setup Completeメッセージの例を示す。

図３０（ａ）に示すように、上述したlong resume IDに相当するlongResumeIdentityが追加されている。図３０（ｂ）に示すように、本例でのlongResumeIdentityは、ＵＥコンテクスト（AS configuration）と、 当該ＵＥコンテクストを格納するｅＮＢを識別するための４０ビット長の識別子である。

RRC Connection RequestメッセージとRRC Connection Setup Completeメッセージについては、図３１、図３２に示す内容としてもよい。この場合も、RRC Connection Setupメッセージについては、図２９に示したものと同じである。

図３１（ａ）は、図２６のステップ４５３でＵＥ５０から送信されるRRC Connection Requestメッセージの例を示す。

図３１（ａ）に示すように、認証情報であるUE-AS-ConfigIdenityに加えて、short resume IDに相当するshortResumeIdentityが追加されている。図３１（ｂ）に示すように、本例でのshortResumeIdentityは、ＵＥコンテクスト（AS configuration）と当該ＵＥコンテクストを格納するｅＮＢを識別し、更に、当該ＵＥコンテクストに対応するＵＥを認証するための４０ビットの識別子である。なお、本実施の形態において"ＵＥコンテクストに対応するＵＥを認証する"とは、"当該ＵＥが保存されたＵＥコンテクストの所在者であることを認証する"ことでもある。また、本例では、UE-AS-ConfigIdenityの中にshortMAC-Iを含めないこととしてもよい。

図３２（ａ）は、図２６のステップ４５５でＵＥ５０から送信されるRRC Connection Setup Completeメッセージの例を示す。

図３２（ａ）に示すように、long resume IDに相当するlongResumeIdentityが追加されている。図３２（ｂ）に示すように、本例でのlongResumeIdentityは、ＵＥコンテクスト（AS configuration）と当該ＵＥコンテクストを格納するｅＮＢを識別し、更に、当該ＵＥコンテクストに対応するＵＥを認証するための５６ビットの識別子である。

また、RRC Connection RequestメッセージとRRC Connection Setup Completeメッセージについては、図３３、図３４に示す内容としてもよい。この場合も、RRC Connection Setupメッセージについては、図２９に示したものと同じである。図３３、図３４に示す例では、resume IDを全体で４０ビットとし、最初の２４ビットをRRC Connection Requestメッセージに含め、残りの１６ビットをRRC Connection Setup Completeメッセージに含める。なお、この場合でも、便宜上、RRC Connection Requestメッセージに含める最初の２４ビットを「short resume ID」と呼び、RRC Connection Setup Completeメッセージに含める残りの１６ビットと最初の２４ビットを合わせた識別子を「long resume ID」と呼ぶこととしてもよい。

図３３（ａ）は、図２６のステップ４５３でＵＥ５０から送信されるRRC Connection Requestメッセージの例を示す。

図３３（ａ）に示すように、認証情報であるUE-AS-ConfigIdenityに加えて、上述したshort resume IDに相当するresumeIdentity-LSBが追加されている。図３３（ｂ）に示すように、resumeIdentity-LSBは、ＵＥコンテクスト（AS configuration）と、 当該ＵＥコンテクストを格納するｅＮＢを識別するためのresume identityにおける最下位（least significant）２４ビットである。

図３４（ａ）は、図２６のステップ４５５でＵＥ５０から送信されるRRC Connection Setup Completeメッセージの例を示す。

図３４（ａ）に示すように、resumeIdentity-MSBが追加されている。図３４（ｂ）に示すように、resumeIdentity-MSBは、ＵＥコンテクスト（AS configuration）と、 当該ＵＥコンテクストを格納するｅＮＢを識別するためのresume identityにおける最上位（most significant）１６ビットである。

また、RRC Connection RequestメッセージとRRC Connection Setup Completeメッセージについては、図３５、図３６に示す内容としてもよい。この場合も、RRC Connection Setupメッセージについては、図２９に示したものと同じである。図３５、図３６に示す例は、図３３、図３４で示したresume IDにおいて、ＵＥコンテクストに対応するＵＥを認証するための情報を追加するものである。

図３５（ａ）は、図２６のステップ４５３でＵＥ５０から送信されるRRC Connection Requestメッセージの例を示す。

図３５（ａ）に示すように、認証情報であるUE-AS-ConfigIdenityに加えて、resumeIdentity-LSBが追加されている。図３５（ｂ）に示すように、本例のresumeIdentity-LSBは、ＵＥコンテクスト（AS configuration）と、当該ＵＥコンテクストを格納するｅＮＢを識別し、更に、当該ＵＥコンテクストに対応するＵＥを認証するためのresume identityにおける最下位（least significant）４０ビットである。

図３６（ａ）は、図２６のステップ４５５でＵＥ５０から送信されるRRC Connection Setup Completeメッセージの例を示す。

図３６（ａ）に示すように、resumeIdentity-MSBが追加されている。図３６（ｂ）に示すように、本例のresumeIdentity-MSBは、ＵＥコンテクスト（AS configuration）と、 当該ＵＥコンテクストを格納するｅＮＢを識別し、更に、当該ＵＥコンテクストに対応するＵＥを認証するためのresume identityにおける最上位（most significant）１６ビットである。

（変形例３：ＵＥコンテクスト保持機能判定について）
図７等を参照して説明したとおり、本実施の形態では、ＵＥ５０はＵＥコンテクストを保持していることをｅＮＢ１０に通知する。これはｅＮＢ１０がＵＥコンテクスト保持機能（保持したＵＥコンテクストを再利用して接続を行う機能、あるいは、Context Fetchにより取得したＵＥコンテクストを再利用して接続を行う機能）に対応していることを前提としている。

しかし、全てのｅＮＢがＵＥコンテクスト保持機能に対応しているとは限らない。例えば、ＵＥ５０が、ｅＮＢ１０の配下でＵＥコンテクストを保持したままＲＲＣアイドル状態になって、ＵＥコンテクスト保持機能を保持しないｅＮＢ−Ｘのセルに移動したとする。ここで、ＵＥ５０がＵＥコンテクストを保持していることを示す情報をｅＮＢ−Ｘに通知しても、ｅＮＢ−Ｘは当該情報を理解できない。安定した動作を行う観点から、ＵＥ５０は、在圏するセルのｅＮＢがＵＥコンテクスト保持機能を有することを確認できた場合に、図７等で説明したＵＥコンテクスト保持通知の動作を行うことが望ましい。

本変形例３では、ｅＮＢ１０がＵＥコンテクスト保持機能を有するか否かをＵＥ５０が判定する例を説明する。変形例３は、変形例１と変形例２と基本例のいずれにも適用可能である。以下では、例１〜例３を説明する。なお、変形例３における「ＵＥコンテクスト保持機能」とは、ＲＲＣ接続状態にない状態において保持しているＵＥコンテクストを利用（つまり、再利用）して、当該状態からＲＲＣ接続を確立させる機能である。また、ｅＮＢがＵＥコンテクスト保持機能を有しない、あるいは、ｅＮＢがＵＥコンテクスト保持機能に対応していない、とは、ｅＮＢがＵＥコンテクスト保持機能を能力として保持しない場合のみならず、能力としては保持するが、当該機能を停止している場合を含む。

＜例１＞
例１では、ｅＮＢ１０は、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを示す情報を報知情報でＵＥ５０に報知する。当該報知情報としては、例えば、ＭＩＢ、ＳＩＢ１、ＳＩＢ２を使用することができる。前述したように、ＳＩＢ２で報知されるcriticalExtRRC-ConnEstReqAllowedは、当該情報の例である。

図３７のフローチャートを参照して、ＵＥコンテクスト保持機能の判定に関するＵＥ５０の動作例を説明する。以下の例では、ｅＮＢ１０はＳＩＢ１を用いてＵＥコンテクスト保持機能に対応しているか否かを示す情報を報知する。

ステップ５０１において、ＵＥ５０はｅＮＢ１０からＳＩＢ１を受信する。ステップ５０２において、ＵＥ５０は、ＳＩＢ１から、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを示す情報を読み取り、当該情報に基づいて、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを判定する。

ステップ５０２の判定結果がＹｅｓ（対応している）の場合、ステップＳ５０３に進み、ＵＥ５０は、ＲＲＣ接続状態に遷移する場合に、図７等で説明した手順を実行する。すなわち、ＵＥ５０は、ＵＥコンテクストを保持していることを示す情報の通知等を行う。なお、図３４のＳ５０３には、図７に示す手順を実行することが記載されているが、これは例であり、例えば図２６に示す手順を実行してもよい。

ステップ５０２の判定結果がＮｏ（対応していない）の場合、ステップＳ５０４に進み、ＵＥ５０は、ＲＲＣ接続状態に遷移する場合に、保持しているＵＥコンテクストを破棄して、スペアビット等を用いない（あるいは、認証情報等を含まない）通常のRRC Connection RequestをｅＮＢ１０に送信する。

＜例２＞
例２では、ｅＮＢ１０は、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを、ランダムアクセス手順におけるRandom Access ResponseでＵＥ５０に通知する。

図３８のフローチャートを参照して、例２におけるＵＥ５０の動作例を説明する。ここでは、例えば、ＲＲＣアイドル状態にあるＵＥ５０が、ページングを受けて（あるいは発信を行うために）、ＲＲＣ接続状態に遷移する場合の状況を示している。

ステップ６０１において、ＵＥ５０はｅＮＢ１０にRandom Access Preambleを送信する。ステップ６０２において、ＵＥ５０はｅＮＢ１０からRandom Access Responseを受信する。当該Random Access Responseには、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを示す情報が含まれている。

ステップ６０３において、ＵＥ５０は、Random Access Responseから、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを示す情報を読み取り、当該情報に基づいて、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを判定する。

ステップ６０３の判定結果がＹｅｓ（対応している）の場合、ステップＳ６０４に進み、ＵＥ５０は、図７等で説明した手順を実行する。すなわち、ＵＥ５０は、ＵＥコンテクストを保持していることを示す情報の通知等を行う。なお、図３８のＳ６０４には、図７に示す手順を実行することが記載されているが、これは例であり、例えば図２６に示す手順を実行してもよい。

ステップ６０３の判定結果がＮｏ（対応していない）の場合、ステップＳ６０５に進み、ＵＥ５０は、保持しているＵＥコンテクストを破棄して、スペアビットを用いない通常のRRC Connection RequestをｅＮＢ１０に送信する。

図３９、図４０は、変形例３の例２におけるRandom Access Responseのメッセージ例を示す（従来例については非特許文献４参照）。図３９に示すように、ＭＡＣ ＰＤＵにＭＡＣ ＲＡＲが含まれる。図４０に示すように、例２においては、ＭＡＣ ＲＡＲ中のリザーブビットを用いて、ＵＥコンテクスト保持機能に対応しているか否かを示す情報を通知する。一例として、ビットが１であれば、ＵＥコンテクスト保持機能に対応していることを示し、０であれば対応していないことを示す。１と０が逆であってもよい。

＜例３＞
例３については、基本例を対象としている。例３では、ＵＥ５０は、RRC Connection Setupメッセージに、前述したue-ContextStored（ｅＮＢ１０がＵＥ５０対応のＵＥコンテクストを保持していることを示す情報）が含まれているか否かでｅＮＢ１０におけるＵＥコンテクスト保持機能対応有無を判定する。

すなわち、例３ではＵＥ５０は常にRRC Connection RequestでＵＥコンテクストを保持していることをｅＮＢに通知して、図７に示す動作を実行する。ただし、ここでは、RRC Connection Setupメッセージに基づいて、ｅＮＢ１０におけるＵＥコンテクスト保持機能対応有無を判定するのである。

図４１のフローチャートを参照して、例３におけるＵＥ５０の動作例を説明する。例えば、ＲＲＣアイドル状態にあるＵＥ５０が、ＲＲＣ接続状態に遷移しようとする場合に、ステップ７０１において、ＵＥ５０は、ＵＥコンテクストを保持していることを示す情報を含むRRC Connection RequestメッセージをｅＮＢ１０に送信する。

ステップ７０２において、ＵＥ５０は、ｅＮＢ１０からRRC Connection Setupメッセージを受信する。ステップ７０３において、ＵＥ５０は、ue-ContextStoredがRRC Connection Setupメッセージに含まれているか否かの判定を行い、判定結果がＹｅｓ（含まれている）であればステップ７０４に進み、判定結果がＮｏ（含まれていない）であればステップ７０５に進む。

ステップ７０４において、ＵＥ５０は、保持していたＵＥコンテクストを継続使用し、図７のステップ２０３と同様のRRC Connection Setup CompleteメッセージをｅＮＢ１０に送信する。

ステップ７０５において、ＵＥ５０は、保持していたＵＥコンテクストを破棄し、RRC Connection Setupメッセージに含まれているRadioResourceConfigDedicated内の設定値を反映してＵＥコンテクスト（ベアラ、MAC config、PHY config等）を作成し、ｅＮＢ１０との接続（通信）に使用する。ステップ７０５以降、通常のＲＲＣ接続手順が実行される。

（RRC Connection Setupメッセージに関する変形例：ＬＣＩＤ変形例）
上述したように、本実施の形態におけるＲＲＣ接続確立手順において、ＵＥ５０は、ＵＥコンテクストを保持していることを示す情報を含むRRC Connection Requestメッセージを送信する。

ところで、本実施の形態におけるＵＥとｅＮＢ間では、基本的に、データはＤＲＢ（Data Radio Bearer）を用いて送受信される。ここでは、この方式を「ＤＲＢ方式」と呼ぶ。一方、少量のデータが送受信されるＩｏＴ（Internet of Things）やＭＴＣ（Machin Type Communication）等への適用を想定して、データをＳＲＢ（Signaling Radio Bearer）で送受信する方式が提案されている（非特許文献５）。ここではこの方式を「ＳＲＢ方式」と呼ぶ。ＳＲＢ方式は、本実施の形態においても適用可能である。

しかし、ｅＮＢ側でＤＲＢ方式とＳＲＢ方式の両方に対応していたとしても、接続するＵＥがどちらの方式に対応しているかをｅＮＢ側で把握しなければ、ｅＮＢは適切に動作できないと考えられる。

そこで、本変形例（ＬＣＩＤ変形例と呼ぶ）では、図７（図２６でもよい）に示したＲＲＣ接続確立手順において、ＵＥ５０は、RRC Connection Requestメッセージで、ＤＲＢ方式とＳＲＢ方式のそれぞれについて対応しているか否かをｅＮＢ１０に通知する。しかし、RRC Connection Requestメッセージのサイズを大きくして情報ビットを追加する場合、セル端ＵＥから送信されたRRC Connection RequestメッセージのｅＮＢ側での受信品質が下がり、その結果セル端ＵＥの品質劣化、セル半径の縮小につながる可能性がある。本変形例では、以下のようにして通知を行う。

RRC Connection Requestメッセージは、Random Access Responseに含まれるＵＬグラントで割り当てられるＰＵＳＣＨのリソースを用いて、ＭＡＣ ＰＤＵにより送信される。また、RRC Connection Requestメッセージは、論理チャネルの観点では、ＣＣＣＨ（Common Control Channel、共通制御チャネル）で送信される。

そこで、本変形例では、このＭＡＣ ＰＤＵに付されているＭＡＣヘッダのＬＣＩＤ（Logical Channel ID、論理チャネルＩＤ）を使用して、ＵＥ１０が、ＤＲＢ方式とＳＲＢ方式のそれぞれについて対応しているか否かをｅＮＢ１０に通知する。

本変形例の通信システムのＭＡＣに関する動作を規定する仕様（現状の仕様からの変更例）を図４２（ａ）、（ｂ）に示す。現状のＭＡＣ仕様（非特許文献４）からの変更箇所に下線が引かれている。

図４２（ａ）、（ｂ）に示すように、ＵＥが、ＳＲＢ方式のみに対応している場合には、ＬＣＩＤ「０１１００」を用いてＣＣＣＨを指定する。ＵＥが、ＤＲＢ方式のみに対応している場合には、ＬＣＩＤ「０１１０１」を用いてＣＣＣＨを指定する。ＵＥが、ＳＲＢ方式とＤＲＢ方式の両方に対応している場合には、ＬＣＩＤ「０１１１０」を用いてＣＣＣＨを指定する。なお、これらの値は一例である。

例えば、ＵＥ５０から、ＬＣＩＤ「０１１００」を指定したＭＡＣ ＰＤＵでRRC Connection Requestメッセージが送信され、当該RRC Connection RequestメッセージをｅＮＢ１０が受信すると、ｅＮＢ１０は、ＵＥ５０がＤＲＢ方式のみに対応していることを把握し、ＤＲＢを使用したデータ送受信を行う。

また、ＵＥ５０から、ＬＣＩＤ「０１１０１」を指定したＭＡＣ ＰＤＵでRRC Connection Requestメッセージが送信され、当該RRC Connection RequestメッセージをｅＮＢ１０が受信すると、ｅＮＢ１０は、ＵＥ５０がＳＲＢ方式のみに対応していることを把握し、ＳＲＢを使用したデータ送受信を行う。

また、ＵＥ５０から、ＬＣＩＤ「０１１１０」を指定したＭＡＣ ＰＤＵでRRC Connection Requestメッセージが送信され、当該RRC Connection RequestメッセージをｅＮＢ１０が受信すると、ｅＮＢ１０は、ＵＥ５０がＤＲＢ方式とＳＲＢ方式の両方に対応していることを把握する。この場合、例えば、ｅＮＢ１０は、ＵＥ５０の能力等に応じて、ＤＲＢ方式とＳＲＢ方式のいずれを実行するかを決定する。

上記の方式により、RRC Connection Requestメッセージのサイズを増大させることなく、ＤＲＢ方式／ＳＲＢ方式の対応可否を通知することができる。

なお、上記の例では、RRC Connection Requestメッセージ送信の際に、ＬＣＩＤを使用してＤＲＢ方式／ＳＲＢ方式の対応可否を通知することとしているが、これは例であり、ＣＣＣＨで送信される他のメッセージにおいて、ＬＣＩＤを使用してＤＲＢ方式／ＳＲＢ方式の対応可否を通知することとしてもよい。

（変形例４：ＵＥコンテクストの保持期間に関する変形例について）
前述した変形例１で、ＵＥ５０は、ＵＥコンテクストの保持を開始した時刻から、ＵＥコンテクストを保持する所定の期間Ｔが経過した時点で、ＵＥコンテクストは無効になったと判断し、当該ＵＥコンテクストを解放（削除）するようにした。つまり、変形例１によれば、ＵＥ５０は、再選択するセルの無線アクセス技術（ＲＡＴ：Radio Access Technology）に関わらず、所定の期間Ｔが満了しない限り、ＵＥコンテクストを保持するように動作する。しかしながら、ＵＥ５０は、これに限られず、以下に説明する条件に従って、ＵＥコンテクストを解放（削除）するようにしてもよい。なお、セル再選択とは、一旦ＲＲＣ接続状態からＲＲＣアイドル状態に遷移したＵＲ５０が、ＲＲＣ接続状態に遷移するセルを選択（再度選択）する動作を意図しており、例えば、ＵＥ５０が他のセルに移動してそのセルを選択する動作、及び、オーバーラップされたセルのうちいずれかのセルを選択する動作を含む。

＜例１−１＞
ＵＥ５０は、セル再選択（cell reselection）を行う際に、再選択するセルがＬＴＥ以外のセルである場合（例えば、ＵＭＴＳ、ＧＳＭ（登録商標）などのＬＴＥ以外の他のＲＡＴのセルを再選択）に、ＵＥコンテクストを解放（削除）するようにしてもよい。この場合、ＵＥコンテクストを保持しているＵＥ５０は、再選択するセルで（ＬＴＥ以外の他のＲＡＴで）ＲＲＣコネクションの確立を試みる際（つまり、ＲＲＣコネクションの確立要求を基地局に送信する際）に、ＵＥコンテクストを解放（削除）するようにしてもよいし、再選択するセルで（ＬＴＥ以外の他のＲＡＴで）ＲＲＣコネクションが確立された後で、ＵＥコンテクストを解放（削除）するようにしてもよい。

また、ＵＥコンテクストを保持しているＵＥ５０は、再選択するセルで（ＬＴＥ以外の他のＲＡＴで）ＲＲＣコネクションを確立するまでに（つまり、再選択するセルでＲＲＣコネクションが確立されるまでの間の任意のタイミングで）、ＵＥコンテクストを解放（削除）するようにしてもよい。この場合の仕様変更例（ＴＳ３６．３０４）を図４３に示す。

ＵＥ５０が一旦ＬＴＥ以外のセルにアクセスした場合、すぐにＬＴＥのセルを再選択する可能性は低いと考えられることから、ＵＥ５０のメモリ使用量を削減することが可能になる。

＜例１−２＞
ＵＥ５０は、セル再選択を行う際に、再選択するセルがＬＴＥ以外のセルである場合（例えば、ＵＭＴＳ、ＧＳＭ（登録商標）などのＬＴＥ以外の他のＲＡＴのセルを再選択）であっても、ＵＥコンテクストを解放（削除）しないようにしてもよい。ＵＥ５０が一旦ＬＴＥ以外のセルにアクセスした場合であっても、すぐにＬＴＥのセルを再選択する可能性がある場合に、ＵＥコンテクストを再利用することが可能になる。

＜例２−１＞
ＵＥ５０は、セル再選択を行う際に、再選択するセルがＬＴＥのセルである場合で、かつ、当該セルの報知情報（ＳＩＢ２）に、ｅＮＢ１０がＵＥコンテクスト保持機能に対応していることを示す情報が含まれていない場合に、ＵＥコンテクストを解放（削除）するようにしてもよい。また、ＵＥ５０は、セル再選択を行う際に、再選択するセルがＬＴＥのセルである場合で、かつ、当該セルの報知情報（ＳＩＢ２）に、ｅＮＢ１０がＵＥコンテクスト保持機能に対応していることを示す情報が含まれている場合に、ＵＥコンテクストを解放（削除）しないようにしてもよい。ｅＮＢ１０がＵＥコンテクスト保持機能に対応していることを示す情報は、変形例３の＜例１＞で説明した、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを示す情報であってもよいし、ＳＩＢ２に「up-CIOT-EPS-Optimisation」が設定されていることであってもよい（以下の例２−２も同様）。これにより、ＵＥ５０は、再選択するセルにおいてｅＮＢ１０がＵＥコンテクスト保持機能に対応してない場合に、ＵＥ５０のメモリ使用量を削減することが可能になる。

なお、変形例３においても、ｅＮＢ１０がＵＥコンテクスト保持機能に対応しているか否かを示す情報は、ＳＩＢ２に「up-CIOT-EPS-Optimisation」が設定されているか否かで表現されてもよい。

＜例２−２＞
ＵＥ５０は、セル再選択を行う際に、再選択するセルがＬＴＥのセルである場合、当該セルの報知情報に、ｅＮＢ１０がＵＥコンテクスト保持機能に対応していることを示す情報が含まれている場合、及び、含まれていない場合のいずれの場合であっても、ＵＥコンテクストを解放（削除）しないようにしてもよい。これにより、ｅＮＢ１０がＵＥコンテクスト保持機能に対応していない場合であっても、その後に再選択するセルのｅＮＢ１０がＵＥコンテクスト保持機能に対応している場合に、ＵＥコンテクストを再利用することが可能になる。図４４に、＜例２−２＞に対応する仕様変更例（ＴＳ３６．３０４）を示す。

以上、変形例４により、ＲＲＣアイドル状態にあるＵＥ５０がセル再選択を行う際に、ＵＥコンテクストを保持又は解放する際の条件が明確化されることになる。

なお、変形例１、変形例４の＜例１−１＞、＜例１−２＞、＜例２−１＞、及び＜例２−２＞において、"ＵＥコンテクスト"は、"ＵＥコンテクスト及びＲｅｓｕｍｅＩＤ"に置き換えてもよい。また、以上の変形例４は、基本例と、変形例１と、変形例２と、変形例３とのいずれにも適用可能である。また、以上の変形例４の＜例１−１＞又は＜例１−２＞を、＜例２−１＞又は＜例２−２＞と組み合わせるようにしてもよい。

（装置構成例）
次に、本発明の実施の形態における装置の構成例を説明する。以下で説明する各装置の構成は、発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥ（ＥＰＣを含む意味のＬＴＥ）に準拠した通信システムにおける装置として動作するための図示しない機能も有するものである。また、各図に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

＜ＭＭＥ、Ｓ−ＧＷの構成例＞
まず、図４５を参照して、ＭＭＥ３０とＳ−ＧＷ４０の構成例を説明する。図４５に示すように、ＭＭＥ３０は、ｅＮＢ通信部３１、ＳＧＷ通信部３２、通信制御部３３を含む。

ｅＮＢ通信部３１は、ｅＮＢとの間でＳ１−ＭＭＥインターフェースによる制御信号の送受信を行う機能を含む。ＳＧＷ通信部３２は、Ｓ−ＧＷとの間でＳ１１インターフェースによる制御信号の送受信を行う機能を含む。

通信制御部３３は、ｅＮＢからコネクション維持指示信号を受信した場合に、当該コネクション維持指示信号をＳ−ＧＷに送信するようＳＧＷ通信部３２に指示するとともに、Ｓ−ＧＷから確認応答を受信した場合に、当該確認応答をｅＮＢに送信するようＳＧＷ通信部３２に指示する機能を含む。

図４５に示すように、Ｓ−ＧＷ４０は、ｅＮＢ通信部４１、ＭＭＥ通信部４２、ＮＷ通信部４３、通信制御部４４を含む。

ｅＮＢ通信部４１は、ｅＮＢとの間でＳ１−Ｕインターフェースによるデータの送受信を行う機能を含む。ＭＭＥ通信部４２は、ＭＭＥとの間でＳ１１インターフェースによる制御信号の送受信を行う機能を含む。ＮＷ通信部４３は、コアＮＷ側のノード装置との間で制御信号の送受信及びデータの送受信を行う機能を含む。

通信制御部４４は、ＭＭＥからコネクション維持指示信号を受信した場合に、確認応答をＭＭＥに送信するようＭＭＥ通信部４２に指示する機能を含む。また、通信制御部４４は、ＭＭＥからコネクション維持指示信号を受信している場合において、該当ＵＥへの下りデータを受信した場合に、当該下りデータをバッファに保留しておくようにＮＷ通信部４３に指示し、ＲＲＣ接続確立完了をｅＮＢから受信した場合に、当該下りデータを送信するようにＮＷ通信部４３に指示する機能を含む。

なお、ＭＭＥ３０とＳ−ＧＷ４０を１つの装置として構成することもできる。その場合、ＳＧＷ通信部３２とＭＭＥ通信部４２間のＳ１１インターフェースの通信は、装置内部の通信となる。

次に、本発明の実施の形態（基本例、変形例１、変形例２、変形例３、ＬＣＩＤ変形例を含む）におけるＵＥ５０とｅＮＢ１０の構成例を説明する。なお、以下で説明するＵＥ５０とｅＮＢ１０はそれぞれ、基本例の機能と全ての変形例の機能を有することとしてもよいし、基本例の機能と全ての変形例の機能のうちのいずれか１つの機能を有することとしても良いし、基本例の機能と全ての変形例の機能のうちのいずれか複数の機能を有することとしても良い。

＜ユーザ装置ＵＥ＞
図４６に、ユーザ装置（ＵＥ５０）の機能構成図を示す。図４６に示すように、ＵＥ５０は、ＤＬ信号受信部５１、ＵＬ信号送信部５２、ＲＲＣ処理部５３、ＵＥコンテクスト管理部５４を備える。なお、図４６は、ＵＥ５０において本発明に特に関連する機能部のみを示すものであり、ＵＥ５０は、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。

ＤＬ信号受信部５１は、基地局ｅＮＢから各種の下り信号を受信し、受信した物理レイヤの信号からより上位のレイヤの情報を取得する機能を含み、ＵＬ信号送信部５２は、ＵＥ５０から送信されるべき上位のレイヤの情報から、物理レイヤの各種信号を生成し、基地局ｅＮＢに対して送信する機能を含む。また、ＵＬ信号送信部５２は、RRC Connection Requestメッセージ等の送信の際に、ＬＣＩＤを使用してＤＲＢ方式／ＳＲＢ方式の対応可否をｅＮＢ１０に通知する機能を含む。

ＲＲＣ処理部５３は、図７、図８、図１０〜図４１等を参照して説明した、ＵＥ側の判定処理、ＲＲＣメッセージの生成・送信（送信はＵＬ信号送信部５２を介した送信）、ＤＬ信号受信部５１により受信したＲＲＣメッセージの解釈、解釈に基づく動作等を行う。また、図３８〜図４０を参照して説明したランダムアクセス手順におけるＭＡＣ信号の送受信は、ＤＬ信号受信部５１とＵＬ信号送信部５２により行うこととしてもよい。また、ＲＲＣ処理部５３は、ＵＥコンテクスト管理部５４に保持しておいたＵＥコンテクストを利用してＲＲＣ接続を再開する機能等も含む。この再開機能としては、例えば、変形例１において、アクティベーションの指示をｅＮＢから受信した場合におけるＵＥコンテクスト有効化の処理機能がある。

ＵＥコンテクスト管理部５４は、メモリ等の記憶手段を含み、例えば、図８で説明した指示に基づいて、ＲＲＣアイドル状態においてＵＥコンテクスト及びＵＥ識別子（S-TMSI等）を保持する。また、図７、図２６等に示す手順においては、ＵＥコンテクストの保持の有無を判断し、ＵＥコンテクストを保持している場合には、ＵＥコンテクストを保持していることを示す情報を通知するよう、ＲＲＣ処理部５３に指示する。また、ＵＥコンテクスト管理部５４は、ＲＲＣ接続状態からＲＲＣアイドル状態になった時刻から、ＲＲＣアイドル状態のまま予め定めた時間（Ｔ）が経過した場合に、保持しているＵＥコンテクストを無効と見なし、ＵＥコンテクストを解放する機能を含む。また、ＵＥコンテクスト管理部５４は、再選択するセルの無線アクセス技術（例えば、ＧＳＭ（登録商標）、ＵＭＴＳ、ＬＴＥなど）に応じて、ＵＥコンテクストを無効とみなして解放するか否かを選択する機能を含む。また、ＵＥコンテクスト管理部５４は、再選択するセルの無線アクセス技術がＬＴＥである場合、ｅＮＢ１０がＵＥコンテクストを解放する機能に対応しているか否かに基づいて、ＵＥコンテクストを無効とみなして解放するか否かを選択する機能を含む。また、ＵＥコンテクスト管理部５４は、ＵＥコンテクストを保持しながら現在のＲＡＴとは異なるＲＡＴでセル再選択を行う場合、当該異なるＲＡＴで（再選択するセルで）ＲＲＣコネクションが確立されるまでの間にＵＥコンテクストを解放（削除）する機能を含む。

図４６に示すＵＥ５０の構成は、全体をハードウェア回路（例：１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。

図４７は、ＵＥ５０のハードウェア（ＨＷ）構成の例を示す図である。図４７は、図４６よりも実装例に近い構成を示している。図４７に示すように、ＵＥ５０は、無線信号に関する処理を行うＲＥ（Ｒａｄｉｏ Ｅｑｕｉｐｍｅｎｔ）モジュール１５１と、ベースバンド信号処理を行うＢＢ（Ｂａｓｅ Ｂａｎｄ）処理モジュール１５２と、上位レイヤ等の処理を行う装置制御モジュール１５３と、ＵＳＩＭカードにアクセスするインタフェースであるＵＳＩＭスロット１５４とを有する。

ＲＥモジュール１５１は、ＢＢ処理モジュール１５２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ（Ｄｉｇｉｔａｌ−ｔｏ−Ａｎａｌｏｇ）変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ（Ａｎａｌｏｇ ｔｏ Ｄｉｇｉｔａｌ）変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール１５２に渡す。ＲＥモジュール１５１は、例えば、図４６のＤＬ信号受信部５１及びＵＬ信号送信部５２における物理レイヤ等の機能を含む。

ＢＢ処理モジュール１５２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）１６２は、ＢＢ処理モジュール１５２における信号処理を行うプロセッサである。メモリ１７２は、ＤＳＰ１６２のワークエリアとして使用される。ＢＢ処理モジュール１５２は、例えば、図４６のＤＬ信号受信部５１及びＵＬ信号送信部５２におけるレイヤ２等の機能、ＲＲＣ処理部５３及びＵＥコンテクスト管理部５４を含む。なお、ＲＲＣ処理部５３及びＵＥコンテクスト管理部５４の機能の全部又は一部を装置制御モジュール１５３に含めることとしてもよい。

装置制御モジュール１５３は、ＩＰレイヤのプロトコル処理、各種アプリケーションの処理等を行う。プロセッサ１６３は、装置制御モジュール１５３が行う処理を行うプロセッサである。メモリ１７３は、プロセッサ１６３のワークエリアとして使用される。また、プロセッサ１６３は、ＵＳＩＭスロット１５４を介してＵＳＩＭとの間でデータの読出し及び書込みを行う。

＜基地局ｅＮＢ＞
図４８に、基地局ｅＮＢ（ｅＮＢ１０）の機能構成図を示す。ここで、図４８は、変形例２のcontext fetchの機能については図示していない。図４８に示すように、ｅＮＢ１０は、ＤＬ信号送信部１１、ＵＬ信号受信部１２、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４、認証部１５、ＮＷ通信部１６を備える。なお、図４８は、ｅＮＢ１０において本発明の実施の形態に特に関連する機能部のみを示すものであり、ｅＮＢ１０は、少なくともＬＴＥ方式に準拠した動作を行うための図示しない機能も有するものである。

ＤＬ信号送信部１１は、ｅＮＢ１０から送信されるべき上位のレイヤの情報から、物理レイヤの各種信号を生成し、送信する機能を含む。ＵＬ信号受信部１２は、ユーザ装置ＵＥから各種の上り信号を受信し、受信した物理レイヤの信号からより上位のレイヤの情報を取得する機能を含む。ＵＬ信号受信部１２は、ＵＥ５０から受信するＭＡＣ ＰＤＵのＭＡＣヘッダにおけるＬＣＩＤに基づき、ＵＥ５０におけるＤＲＢ方式／ＳＲＢ方式の対応可否を決定する機能を含む。

ＲＲＣ処理部１３は、図７、図８、図１０〜図４１等を参照して説明した、ｅＮＢ側の判定処理、ＲＲＣメッセージ及び報知情報の生成・送信（送信はＤＬ信号送信部１１を介した送信）、ＵＬ信号受信部１２により受信したＲＲＣメッセージの解釈、解釈に基づく動作等を行う。また、図３８〜図４０を参照して説明したランダムアクセス手順におけるＭＡＣ信号の送受信は、ＤＬ信号送信部１１とＵＬ信号受信部１２により行うこととしてもよい。また、ＲＲＣ処理部１３は、ＵＥコンテクスト管理部１４に保持しておいたＵＥコンテクストを利用してＲＲＣ接続を再開する機能等も含む。

ＵＥコンテクスト管理部１４は、メモリ等の記憶手段を含み、例えば、図８で説明した指示の送信に基づいて、ＲＲＣアイドル状態においてＵＥコンテクスト及びＵＥ識別子（S-TMSI等）を保持する。また、図７に示す手順においては、ＵＥから受信するＵＥ識別子に基づいて、ＵＥコンテクストを検索し、ＵＥコンテクストが保持されていることを確認したら、ＵＥコンテクストが保持されていることを示す通知、及び、認証情報の要求をＲＲＣ処理部１３に指示する。また、変形例１においては、ＵＥコンテクスト管理部１４は、ＵＥから受信する認証情報に基づいて、認証部１５に認証を指示し、認証ＯＫであれば、ＵＥ５０のＵＥコンテクストを検索し、ＵＥコンテクストが保持されていることを確認したら、ＵＥコンテクストをアクティベートすることをＵＥ５０に指示するメッセージの作成、送信をＲＲＣ処理部１３に指示する。また、ＵＥコンテクスト管理部１４は、ＵＥ５０がＲＲＣ接続状態からＲＲＣアイドル状態になった時刻から、ＲＲＣアイドル状態のまま予め定めた時間（Ｔ）が経過した場合に、保持しているＵＥコンテクストを無効と見なし、ＵＥコンテクストを解放する機能を含む。

認証部１５は、基本例において、図７に示したステップ２０３において、ＵＥから認証情報を受信し、ＵＥの認証を行う機能を含む。また、認証部１５は、変形例１において、図７に示したステップ２０１でＵＥから送信される認証情報に基づいてＵＥの認証を行う。

ＮＷ通信部１６は、Ｓ１−ＭＭＥインターフェースでＭＭＥとの間で制御信号を送受信する機能、及び、Ｓ１−ＵインターフェースでＳ−ＧＷとの間でデータを送受信する機能、コネクション維持指示信号の送信機能、ＲＲＣ接続確立完了の送信の送信機能等を含む。

図４９に、変形例２における基地局ｅＮＢ（ｅＮＢ１０）の機能構成図を示す。以下では、主に、図４８のｅＮＢ１０と異なる点について説明する。図４９のｅＮＢ１０では、図４８の構成に対してＵＥコンテクスト取得部１７が追加されている。

ＲＲＣ処理部１３は、例えば図２６、図２７に示したステップ４５３〜４５５、４７１〜４７４のメッセージ送受信動作を、ＤＬ信号送信部１１及びＵＬ信号受信部１２とともに実行する。

ＵＥコンテクスト取得部１７は、例えば、ＵＥコンテクストを保持するＵＥとの間でＲＲＣ接続を確立するために必要なＵＥコンテクストがＵＥコンテクスト管理部１４に格納されていない場合において、コンテクスト取得手順を実行する（図２６のステップ４６０、図２７のステップ４６１、４６２）。また、ＵＥコンテクスト取得部１７は、他の基地局から、コンテクスト要求メッセージを受信したときに、対象のＵＥコンテクストを特定する情報に基づいて、当該ＵＥコンテクストをＵＥコンテクスト管理部１４から取得して、当該他の基地局に返す機能を有する。

図４８、４７に示すｅＮＢ１０の構成は、全体をハードウェア回路（例：１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。

図５０は、ｅＮＢ１０のハードウェア（ＨＷ）構成の例を示す図である。図５０は、図４８、４７よりも実装例に近い構成を示している。図５０に示すように、ｅＮＢ１０は、無線信号に関する処理を行うＲＥモジュール２５１と、ベースバンド信号処理を行うＢＢ処理モジュール２５２と、上位レイヤ等の処理を行う装置制御モジュール２５３と、ネットワークと接続するためのインタフェースである通信ＩＦ２５４とを有する。

ＲＥモジュール２５１は、ＢＢ処理モジュール２５２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール２５２に渡す。ＲＥモジュール２５１は、例えば、図４８、４７のＤＬ信号送信部１１及びＵＬ信号受信部１２における物理レイヤ等の機能を含む。

ＢＢ処理モジュール２５２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ２６２は、ＢＢ処理モジュール２５２における信号処理を行うプロセッサである。メモリ２７２は、ＤＳＰ２５２のワークエリアとして使用される。ＢＢ処理モジュール２５２は、例えば、図４８、４７のＤＬ信号送信部１１及びＵＬ信号受信部１２におけるレイヤ２等の機能、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４、認証部１５、ＵＥコンテクスト取得部１７を含む。なお、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４、認証部１５、ＵＥコンテクスト取得部１７の機能の全部又は一部を装置制御モジュール２５３に含めることとしてもよい。

装置制御モジュール２５３は、ＩＰレイヤのプロトコル処理、ＯＡＭ処理等を行う。プロセッサ２６３は、装置制御モジュール２５３が行う処理を行うプロセッサである。メモリ２７３は、プロセッサ２６３のワークエリアとして使用される。補助記憶装置２８３は、例えばＨＤＤ等であり、基地局ｅＮＢ自身が動作するための各種設定情報等が格納される。

なお、図４５〜図５０に示す装置の構成（機能区分）は、本実施の形態（基本例、変形例１、２を含む）で説明する処理を実現する構成の一例に過ぎない。本実施の形態（基本例、変形例１、２を含む）で説明する処理を実現できるのであれば、その実装方法（具体的な機能部の配置、名称等）は、特定の実装方法に限定されない。

（実施の形態のまとめ）
以上説明したとおり、本実施の形態により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置であって、前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１コンテクスト保持情報を含む接続要求メッセージを、前記基地局に送信する送信手段と、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２コンテクスト保持情報を含む接続設定メッセージを、前記基地局から受信する受信手段と、前記接続設定メッセージを受信した後、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続手段とを備えるユーザ装置が提供される。

上記の構成により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、ユーザ装置がコンテクスト情報を保持しているか否かを基地局により判定することが可能となる。

前記接続設定メッセージは、前記第２コンテクスト保持情報に加えて、前記ユーザ装置に対する認証情報の送信要求を含み、前記送信手段は、当該送信要求に基づいて、認証情報を前記基地局に送信することとしてもよい。この構成により、基地局がユーザ装置を認証してから接続を確立することができる。

前記送信手段は、例えば、前記認証情報を含む接続設定完了メッセージを前記基地局に送信する。この構成により、認証情報を特別なメッセージで送る必要がなくなり、メッセージを削減できる。

前記送信手段は、前記ユーザ装置の認証情報を前記第１コンテクスト保持情報として含む接続要求メッセージを、前記基地局に送信することとしてもよい。この構成により、接続設定を実施する前（ＲＲＣ接続がなされる前）に認証情報を送信することができる。

前記受信手段は、前記ユーザ装置側コンテクスト情報をアクティブ化する指示情報を前記第２コンテクスト保持情報として含む接続設定メッセージを、前記基地局から受信することとしてもよい。この構成により、ユーザ装置は、ユーザ装置側コンテクスト情報をアクティブ化する指示情報を受信するか否かにより、基地局がコンテクスト情報を保持しているか否かを判断できる。

前記受信手段は、前記ユーザ装置を接続状態からアイドル状態に遷移させる接続解放メッセージを前記基地局から受信し、当該接続解放メッセージの中から、前記ユーザ装置側コンテクスト情報を保持することを指示する情報を検知した場合に、前記アイドル状態の間、前記ユーザ装置側コンテクスト情報を記憶手段に保持することとしてもよい。この構成により、ユーザ装置は、指示を受けない場合には、ユーザ装置側コンテクスト情報を保持しなくてもよく、無駄にユーザ装置側コンテクスト情報を保持することを回避できる。

また、ユーザ装置は、前記ユーザ装置が接続状態からアイドル状態に遷移した時点から、アイドル状態のまま所定の時間が経過した場合に、前記記憶手段に保持された前記ユーザ装置側コンテクスト情報を無効とする管理手段を備えることとしてもよい。この構成により、例えば、アイドル状態が長く継続するような場合において、ユーザ装置側コンテクスト情報を保持し続けることを回避できる。

また、前記ユーザ装置が接続状態からアイドル状態に遷移した場合に、再度接続状態に遷移するために選択するセルの無線アクセス技術に応じて、前記記憶手段に保持された前記ユーザ装置側コンテクスト情報を無効とするか否かを選択する管理手段を備えることとしてもよい。この構成により、例えば、再選択するセルがＬＴＥではない場合に、ユーザ装置側コンテクスト情報を保持し続けることを回避できる。

また、本実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置であって、前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１識別子を含む接続要求メッセージを、前記基地局に送信する送信手段と、第２識別子の要求が含まれた接続設定メッセージを、前記基地局から受信する受信手段と、を備え、前記送信手段は、前記第２識別子を含む接続設定完了メッセージを前記基地局に送信することを特徴とするユーザ装置が提供される。第１識別子又は第２識別子は、例えば、ユーザ装置のコンテクスト情報と、当該コンテクスト情報を保持する基地局を識別するために用いられる識別子である。また、第１識別子又は第２識別子が、当該コンテクスト情報に対応するユーザ装置を認証する情報を含んでもよい。

また、本実施の形態により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１コンテクスト保持情報を含む接続要求メッセージを、前記ユーザ装置から受信する受信手段と、前記接続要求メッセージを受信したことに応じて、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２コンテクスト保持情報を含む接続設定メッセージを、前記ユーザ装置に送信する送信手段と、前記接続設定メッセージを送信した後、前記基地局側コンテクスト情報を利用して、前記ユーザ装置との間で接続を確立する接続手段とを備える基地局が提供される。

上記の構成により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、ユーザ装置がコンテクスト情報を保持しているか否かを基地局により判定することが可能となる。

前記受信手段は、例えば、前記接続要求メッセージから前記ユーザ装置の識別子を取得し、保持される複数の基地局側コンテクスト情報から、当該識別子に対応する基地局側コンテクスト情報を検索する。このように、識別子を使用することで、確実にユーザ装置に対応付けられた基地局側コンテクスト情報を検出することができる。

前記接続設定メッセージは、前記第２コンテクスト保持情報に加えて、前記ユーザ装置に対する認証情報の送信要求を含み、前記送信要求に基づいて、前記ユーザ装置から送信された認証情報を用いて前記ユーザ装置の認証を行う認証手段を備えてもよい。この構成により、基地局がユーザ装置を認証してから接続を確立することができる。

前記受信手段は、前記ユーザ装置の認証情報を前記第１コンテクスト保持情報として含む接続要求メッセージを、前記ユーザ装置から受信することとしてもよい。この構成により、接続設定を実施する前（ＲＲＣ接続がなされる前）に認証情報を受信し、ユーザ装置の認証を行うことができる。

前記送信手段は、前記ユーザ装置側コンテクスト情報をアクティブ化する指示情報を前記第２コンテクスト保持情報として含む接続設定メッセージを、前記ユーザ装置に送信することとしてもよい。この構成により、ユーザ装置は、ユーザ装置側コンテクスト情報をアクティブ化する指示情報を受信するか否かにより、基地局がコンテクスト情報を保持しているか否かを判断できる。

前記送信手段は、前記ユーザ装置を接続状態からアイドル状態に遷移させる接続解放メッセージの中に、前記ユーザ装置側コンテクスト情報を保持することを指示する情報を含め、当該接続解放メッセージを前記ユーザ装置に送信することとしてもよい。この構成により、ユーザ装置は、指示を受けない場合には、ユーザ装置側コンテクスト情報を保持しなくてもよく、無駄にユーザ装置側コンテクスト情報を保持することを回避できる。

また、本実施の形態により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、ユーザ装置側コンテクスト情報を保持する前記ユーザ装置から第１識別子を含む接続要求メッセージを受信する受信手段と、第２識別子の要求が含まれた接続設定メッセージを前記ユーザ装置に送信する送信手段と、前記ユーザ装置から前記第２識別子を含む接続設定完了メッセージを受信し、当該第２識別子に基づいて前記ユーザ装置の基地局側コンテクスト情報を保持する保持基地局を特定し、当該保持基地局に対して、コンテクスト要求メッセージを送信し、当該コンテクスト要求メッセージに応じて前記保持基地局から送信される前記基地局側コンテクスト情報を取得するコンテクスト取得手段とを備える基地局が提供される。 また、本実施の形態により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置であって、前記基地局から、当該基地局がコンテクスト保持機能を有するか否かを示す指示情報を受信する受信手段と、前記受信手段により受信した前記指示情報に基づき、前記基地局がコンテクスト保持機能を有するか否かを判定する判定手段と、前記判定手段により、前記基地局がコンテクスト保持機能を有すると判定される場合に、前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示すコンテクスト保持情報を含むメッセージを、前記基地局に送信する送信手段とを備えるユーザ装置が提供される。

上記の構成により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、基地局がコンテクスト情報を再利用する機能を保持するか否かをユーザ装置により判定することが可能となる。

前記受信手段は、例えば、報知情報又はランダムアクセスレスポンスに含まれる前記指示情報を受信する。この構成により、新規な信号を導入することなくユーザ装置は指示信号を受信できる。

前記送信手段は、前記コンテクスト保持情報を含む接続要求メッセージを前記基地局に送信することとしてもよい。この構成により、コンテクスト情報を再利用する機能を保持することが確認された基地局に接続要求メッセージを送信でき、コンテクスト情報を再利用した接続確立を確実に行うことができる。

また、本実施の形態により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置であって、前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１コンテクスト保持情報を含む接続要求メッセージを、前記基地局に送信する送信手段と、前記基地局から受信する接続設定メッセージの中に、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２コンテクスト保持情報が含まれているか否かを判定する判定手段と、前記判定手段により、前記接続設定メッセージの中に第２コンテクスト保持情報が含まれていると判定される場合に、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続手段とを備えるユーザ装置が提供される。

上記の構成により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、基地局がコンテクスト情報を再利用する機能を保持するか否かをユーザ装置により判定することが可能となる。

また、本実施の形態により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、前記基地局がコンテクスト保持機能を有するか否かを示す指示情報を、前記ユーザ装置に送信する送信手段と、前記ユーザ装置において、前記指示情報に基づき、前記基地局がコンテクスト保持機能を有すると判定される場合に、前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示すコンテクスト保持情報を含むメッセージを、前記ユーザ装置から受信する受信手段とを備える基地局が提供される。

上記の構成により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、基地局がコンテクスト情報を再利用する機能を保持するか否かをユーザ装置により判定することが可能となる。

前記送信手段は、例えば、前記指示情報を含む報知情報又はランダムアクセスレスポンスを前記ユーザ装置に送信する。この構成により、新規な信号を導入することなくユーザ装置は指示信号を受信できる。

前記受信手段は、前記コンテクスト保持情報を含む接続要求メッセージを前記ユーザ装置から受信することとしてもよい。この構成により、コンテクスト情報を再利用する機能を保持することが確認された基地局が接続要求メッセージを受信でき、コンテクスト情報を再利用した接続確立を確実に行うことができる。

なお、上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。

以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、各装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従って当該装置が有するプロセッサにより動作するソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
明細書には以下の事項が開示されている。
（第１項）
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置であって、
前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１コンテクスト保持情報を含む接続要求メッセージを、前記基地局に送信する送信手段と、
前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２コンテクスト保持情報を含む接続設定メッセージを、前記基地局から受信する受信手段と、
前記接続設定メッセージを受信した後、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続手段と
を備えることを特徴とするユーザ装置。
（第２項）
前記接続設定メッセージは、前記第２コンテクスト保持情報に加えて、前記ユーザ装置に対する認証情報の送信要求を含み、前記送信手段は、当該送信要求に基づいて、認証情報を前記基地局に送信する
ことを特徴とする第１項に記載のユーザ装置。
（第３項）
前記送信手段は、前記認証情報を含む接続設定完了メッセージを前記基地局に送信する
ことを特徴とする第２項に記載のユーザ装置。
（第４項）
前記送信手段は、前記ユーザ装置の認証情報を前記第１コンテクスト保持情報として含む接続要求メッセージを、前記基地局に送信する
ことを特徴とする第１項に記載のユーザ装置。
（第５項）
前記受信手段は、前記ユーザ装置側コンテクスト情報をアクティブ化する指示情報を前記第２コンテクスト保持情報として含む接続設定メッセージを、前記基地局から受信する
ことを特徴とする第１項に記載のユーザ装置。
（第６項）
前記受信手段は、前記ユーザ装置を接続状態からアイドル状態に遷移させる接続解放メッセージを前記基地局から受信し、当該接続解放メッセージの中から、前記ユーザ装置側コンテクスト情報を保持することを指示する情報を検知した場合に、前記アイドル状態の間、前記ユーザ装置側コンテクスト情報を記憶手段に保持する
ことを特徴とする第１項ないし第５項のうちいずれか１項に記載のユーザ装置。
（第７項）
前記ユーザ装置が接続状態からアイドル状態に遷移した時点から、アイドル状態のまま所定の時間が経過した場合に、前記記憶手段に保持された前記ユーザ装置側コンテクスト情報を無効とする管理手段
を備えることを特徴とする第６項に記載のユーザ装置。
（第８項）
前記ユーザ装置が接続状態からアイドル状態に遷移した場合に、再度接続状態に遷移するために選択するセルの無線アクセス技術に応じて、前記記憶手段に保持された前記ユーザ装置側コンテクスト情報を無効とするか否かを選択する管理手段
を備えることを特徴とする第６項又は第７項に記載のユーザ装置。
（第９項）
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、
前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１コンテクスト保持情報を含む接続要求メッセージを、前記ユーザ装置から受信する受信手段と、
前記接続要求メッセージを受信したことに応じて、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２コンテクスト保持情報を含む接続設定メッセージを、前記ユーザ装置に送信する送信手段と、
前記接続設定メッセージを送信した後、前記基地局側コンテクスト情報を利用して、前記ユーザ装置との間で接続を確立する接続手段と
を備えることを特徴とする基地局。
（第１０項）
前記受信手段は、前記接続要求メッセージから前記ユーザ装置の識別子を取得し、保持される複数の基地局側コンテクスト情報から、当該識別子に対応する基地局側コンテクスト情報を検索する
ことを特徴とする第９項に記載の基地局。
（第１１項）
前記接続設定メッセージは、前記第２コンテクスト保持情報に加えて、前記ユーザ装置に対する認証情報の送信要求を含み、
前記送信要求に基づいて、前記ユーザ装置から送信された認証情報を用いて前記ユーザ装置の認証を行う認証手段
を備えることを特徴とする第９項又は第１０項に記載の基地局。
（第１２項）
前記受信手段は、前記ユーザ装置の認証情報を前記第１コンテクスト保持情報として含む接続要求メッセージを、前記ユーザ装置から受信する
ことを特徴とする第９項に記載の基地局。
（第１３項）
前記送信手段は、前記ユーザ装置側コンテクスト情報をアクティブ化する指示情報を前記第２コンテクスト保持情報として含む接続設定メッセージを、前記ユーザ装置に送信する
ことを特徴とする第９項に記載の基地局。
（第１４項）
前記送信手段は、前記ユーザ装置を接続状態からアイドル状態に遷移させる接続解放メッセージの中に、前記ユーザ装置側コンテクスト情報を保持することを指示する情報を含め、当該接続解放メッセージを前記ユーザ装置に送信する
ことを特徴とする第９項ないし第１３項のうちいずれか１項に記載の基地局。
（第１５項）
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置が実行する接続確立方法であって、
前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１コンテクスト保持情報を含む接続要求メッセージを、前記基地局に送信する送信ステップと、
前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２コンテクスト保持情報を含む接続設定メッセージを、前記基地局から受信する受信ステップと、
前記接続設定メッセージを受信した後、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続ステップと
を備えることを特徴とする接続確立方法。
（第１６項）
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局が実行する接続確立方法であって、
前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１コンテクスト保持情報を含む接続要求メッセージを、前記ユーザ装置から受信する受信ステップと、
前記接続要求メッセージを受信したことに応じて、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２コンテクスト保持情報を含む接続設定メッセージを、前記ユーザ装置に送信する送信ステップと、
前記接続設定メッセージを送信した後、前記基地局側コンテクスト情報を利用して、前記ユーザ装置との間で接続を確立する接続ステップと
を備えることを特徴とする接続確立方法。

本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。

１０、２０ ｅＮＢ
１１ ＤＬ信号送信部
１２ ＵＬ信号受信部
１３ ＲＲＣ処理部
１４ ＵＥコンテクスト管理部
１５ 認証部
１６ ＮＷ通信部
１７ ＵＥコンテクスト取得部
３０ ＭＭＥ
３１ ｅＮＢ通信部
３２ ＳＧＷ通信部
３３ 通信制御部
４０ Ｓ−ＧＷ
４１ ｅＮＢ通信部
４２ ＭＭＥ通信部
４３ ＮＷ通信部
４４ 通信制御部
５０ ＵＥ
５１ ＤＬ信号受信部
５２ ＵＬ信号送信部
５３ ＲＲＣ処理部
５４ ＵＥコンテクスト管理部
１５１ ＲＥモジュール
１５２ ＢＢ処理モジュール
１５３ 装置制御モジュール
１５４ ＵＳＩＭスロット
２５１ ＲＥモジュール
２５２ ＢＢ処理モジュール
２５３ 装置制御モジュール
２５４ 通信ＩＦ

Claims (9)

1. ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置であって、
   前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１のメッセージを、前記基地局に送信する送信手段と、
   前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２のメッセージを、前記基地局から受信する受信手段と、
   前記第２のメッセージを受信した後、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続手段とを備え、
   前記送信手段は、前記ユーザ装置の認証情報を含む前記第１のメッセージを、前記基地局に送信する
   ことを特徴とするユーザ装置。
2. 前記受信手段は、前記ユーザ装置を接続状態からアイドル状態に遷移させる接続解放メッセージを前記基地局から受信し、当該接続解放メッセージの中から、前記ユーザ装置側コンテクスト情報を保持することを指示する情報を検知した場合に、前記アイドル状態の間、前記ユーザ装置側コンテクスト情報を記憶手段に保持する
   ことを特徴とする請求項１に記載のユーザ装置。
3. 前記ユーザ装置が接続状態からアイドル状態に遷移した時点から、アイドル状態のまま所定の時間が経過した場合に、前記記憶手段に保持された前記ユーザ装置側コンテクスト情報を無効とする管理手段
   を備えることを特徴とする請求項２に記載のユーザ装置。
4. 前記ユーザ装置が再選択するセルがＬＴＥ以外の他のＲＡＴである場合、前記記憶手段に保持された前記ユーザ装置側コンテクスト情報を解放する管理手段
   を備えることを特徴とする請求項２又は３に記載のユーザ装置。
5. ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、
   前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１のメッセージを、前記ユーザ装置から受信する受信手段と、
   前記第１のメッセージを受信したことに応じて、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２のメッセージを、前記ユーザ装置に送信する送信手段と、
   前記第２のメッセージを送信した後、前記基地局側コンテクスト情報を利用して、前記ユーザ装置との間で接続を確立する接続手段とを備え、
   前記受信手段は、前記ユーザ装置の認証情報を含む前記第１のメッセージを、前記ユーザ装置から受信する
   ことを特徴とする基地局。
6. 前記受信手段は、前記第１のメッセージから前記ユーザ装置の識別子を取得し、保持される複数の基地局側コンテクスト情報から、当該識別子に対応する基地局側コンテクスト情報を検索する
   ことを特徴とする請求項５に記載の基地局。
7. 前記送信手段は、前記ユーザ装置を接続状態からアイドル状態に遷移させる接続解放メッセージの中に、前記ユーザ装置側コンテクスト情報を保持することを指示する情報を含め、当該接続解放メッセージを前記ユーザ装置に送信する
   ことを特徴とする請求項５又は６に記載の基地局。
8. ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記ユーザ装置が実行する接続確立方法であって、
   前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１のメッセージを、前記基地局に送信する送信ステップと、
   前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２のメッセージを、前記基地局から受信する受信ステップと、
   前記第２のメッセージを受信した後、前記ユーザ装置側コンテクスト情報を利用して、前記基地局との間で接続を確立する接続ステップとを備え、
   前記送信ステップにおいて、前記ユーザ装置は、前記ユーザ装置の認証情報を含む前記第１のメッセージを、前記基地局に送信する
   ことを特徴とする接続確立方法。
9. ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局が実行する接続確立方法であって、
   前記ユーザ装置がユーザ装置側コンテクスト情報を保持していることを示す第１のメッセージを、前記ユーザ装置から受信する受信ステップと、
   前記第１のメッセージを受信したことに応じて、前記基地局が前記ユーザ装置に対応付けられた基地局側コンテクスト情報を保持していることを示す第２のメッセージを、前記ユーザ装置に送信する送信ステップと、
   前記第２のメッセージを送信した後、前記基地局側コンテクスト情報を利用して、前記ユーザ装置との間で接続を確立する接続ステップとを備え、
   前記受信ステップにおいて、前記基地局は、前記ユーザ装置の認証情報を含む前記第１のメッセージを、前記ユーザ装置から受信する
   ことを特徴とする接続確立方法。

Images