(57)【要約】【課題】ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、基地局が保持するコンテクスト情報のサイズを削減する。【解決手段】ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局において、前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、当該コンテクスト情報における所定の情報を削除する削除手段と、前記ユーザ装置が接続状態を再開する場合に、前記移動通信システムにおいて前記所定の情報を保持する通信制御装置から、当該所定の情報を取得する取得手段と、を備える。【選択図】図１３
2017123582.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、当該コンテクスト情報における所定の情報を削除する削除手段と、
前記ユーザ装置が接続状態を再開する場合に、前記移動通信システムにおいて前記所定の情報を保持する通信制御装置から、当該所定の情報を取得する取得手段と、
を備えることを特徴とする基地局。
【請求項２】
前記取得手段は、前記接続状態の再開を示す信号を前記通信制御装置に送信し、前記所定の情報を含む応答信号を前記通信制御装置から受信する
ことを特徴とする請求項１に記載の基地局。
【請求項３】
前記接続状態の再開を示す信号には、前記ユーザ装置の識別子が含まれ、前記通信制御装置は、当該ユーザ装置の識別子に基づき前記所定の情報を抽出する
ことを特徴とする請求項２に記載の基地局。
【請求項４】
前記ユーザ装置が接続状態を終了する場合に、前記所定の情報を前記通信制御装置に送信する送信手段
を更に備えることを特徴とする請求項１ないし３のうちいずれか１項に記載の基地局。
【請求項５】
前記所定の情報は、前記ユーザ装置の能力情報である
ことを特徴とする請求項１ないし４のうちいずれか１項に記載の基地局。
【請求項６】
前記所定の情報が、サイズの削減された能力情報である場合に、前記削除手段は、当該能力情報の削除を行わず、前記取得手段は、当該能力情報の取得を行わない
ことを特徴とする請求項５に記載の基地局。
【請求項７】
前記サイズの削減された能力情報は、前記ユーザ装置においてデフォルトで備えられる能力についての情報を含まない
ことを特徴とする請求項６に記載の基地局。
【請求項８】
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局が実行するコンテクスト情報保持方法であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、当該コンテクスト情報における所定の情報を削除する削除ステップと、
前記ユーザ装置が接続状態を再開する場合に、前記移動通信システムにおいて前記所定の情報を保持する通信制御装置から、当該所定の情報を取得する取得ステップと、
を備えることを特徴とするコンテクスト情報保持方法。
【請求項９】
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける通信制御装置と前記基地局とが実行するコンテクスト情報保持方法であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、前記基地局が、前記コンテクスト情報における所定の情報を削除するステップと、
前記ユーザ装置が接続状態を再開する場合に、前記基地局が、当該接続状態の再開を示す信号を前記通信制御装置に送信するステップと、
前記通信制御装置が、前記信号を受信し、前記所定の情報を含む応答信号を前記基地局に送信するステップと
を備えることを特徴とするコンテクスト情報保持方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムにおけるユーザ装置ＵＥと基地局ｅＮＢのそれぞれが、ＵＥコンテクストを保持する技術に関連するものである。
【背景技術】
【０００２】
ＬＴＥシステムにおいて、ユーザ装置ＵＥ（以下、ＵＥと記述する）における基地局ｅＮＢ（以下、ｅＮＢと記述する）との間の接続状態はＲＲＣ（Radio Resource Control）アイドル状態（RRC_Idle）と、ＲＲＣ接続状態（RRC_Connected）の２つで示される。
【０００３】
ＵＥがネットワークに接続する際に、ＵＥコンテクストが生成され、ＲＲＣ接続状態において、当該ＵＥコンテクストはＵＥが接続するｅＮＢ及び当該ＵＥに保持される。なお、ＵＥコンテクストは、ベアラ関連情報、セキュリティ関連情報等を含む情報である。
【０００４】
ＵＥがＲＲＣアイドル状態とＲＲＣ接続状態との間を遷移する際に、コアＮＷ側も含めた呼制御のシグナリングが多く発生するため、シグナリングを如何にして削減するかが課題となっている。
【０００５】
例えば、ＵＥをＲＲＣ接続状態からＲＲＣアイドル状態に遷移させる際には、図１に示すようなシグナリングが発生する（非特許文献１等）。図１のケースは、ｅＮＢ２が、ＵＥ１の通信が所定時間発生しないことを検知し、ＵＥ１との接続を切断して、ＲＲＣアイドル状態に遷移させるようなケースである。
【０００６】
図１において、ｅＮＢ２が、ＵＥコンテクスト解放要求（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 TR 23.720 V1.1.0(2015-10)
【非特許文献４】3GPP TSG-RAN WG3 Meeting #90 R3-152688 Anaheim, CA, U.S., 16th - 20th November 2015
【非特許文献５】3GPP TS 36.331 V12.6.0 (2015-06)
【発明の概要】
【発明が解決しようとする課題】
【０００９】
図１に示すようなシグナリング手順では、ＲＲＣ接続解放時に多くのシグナリングが発生するのみならず、ＵＥがＲＲＣアイドル状態から再びＲＲＣ接続状態に遷移する際に、ＵＥコンテクストの設定のために多くのシグナリングが発生する。
【００１０】
ＵＥがＲＲＣアイドル状態とＲＲＣ接続状態との間を遷移する際のシグナリングを削減するために、ＵＥが同一ｅＮＢ内でＲＲＣ接続状態‐＞ＲＲＣアイドル状態−＞ＲＲＣ接続状態と遷移する場合に、ＵＥコンテクストをｅＮＢ及びＵＥで保持したままにしておき、再利用する方法が検討され始めている（非特許文献２）。当該方法において考えられる手順の例を図２を参照して説明する。
【００１１】
図２の（ａ）に示す状態は、ＵＥ１がＲＲＣ接続状態にあり、コアＮＷ側において、当該ＵＥ１に係るＳ１−ＣのコネクションとＳ１−Ｕのコネクション（図ではＳ１‐Ｃ／Ｕ）が確立されている状態である。なお、Ｓ１−Ｃのコネクションは、Ｃ−ｐｌａｎｅ信号を送るＳ１コネクションであり、Ｓ１−ＵのコネクションはＵ−ｐｌａｎｅを通すＳ１コネクションである。
【００１２】
（ａ）に示す状態から、（ｂ）、（ｃ）に示すように、ＲＲＣ接続解放（RRC Connection Release）によりＵＥ１がＲＲＣアイドル状態に遷移される。このとき、ｅＮＢ２におけるＵＥ１に対するＵＥコンテクストは保持されたままであり、また、ＵＥ１におけるｅＮＢ２に対するＵＥコンテクストも保持されたままであり、ＵＥ１に対するＳ１‐Ｃ／Ｕコネクションも維持されたままである。そして、（ｄ）に示すように、ＵＥ１がＲＲＣ接続状態に遷移する際に、ｅＮＢ２とＵＥ１は保持しておいたＵＥコンテクストを再利用することで、シグナリングを削減して、ＲＲＣ接続を確立する。
【００１３】
図２に示す構成において、ｅＮＢ２は、ＲＲＣ接続状態のＵＥ１とデータ送受信を行うためには、UE capability（ＵＥ１の能力情報）を取得する必要がある。UE capabilityはＵＥコンテクストに含められることが想定される情報であるため、図２（ｃ）に示すように、ＵＥ１がＲＲＣアイドル状態のときに、ｅＮＢ２が保持するＵＥコンテクストにはUE capabilityが含められる。
【００１４】
しかし、UE capabilityのサイズは、通常、数百ビットにもなるため、数多くのＵＥのcapabilityをｅＮＢ２で保存しようとすると、大きなメモリ容量を確保する必要があり、ｅＮＢ２のコスト高に繋がる。
【００１５】
上記のような課題は、UE capabilityに限らず、ＵＥコンテクストとして大きなサイズの情報を保持する場合に生じ得る課題である。
【００１６】
本発明は上記の点に鑑みてなされたものであり、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、基地局が保持するコンテクスト情報のサイズを削減することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１７】
本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、当該コンテクスト情報における所定の情報を削除する削除手段と、
前記ユーザ装置が接続状態を再開する場合に、前記移動通信システムにおいて前記所定の情報を保持する通信制御装置から、当該所定の情報を取得する取得手段と、
を備えることを特徴とする基地局が提供される。
【００１８】
また、本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局が実行するコンテクスト情報保持方法であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、当該コンテクスト情報における所定の情報を削除する削除ステップと、
前記ユーザ装置が接続状態を再開する場合に、前記移動通信システムにおいて前記所定の情報を保持する通信制御装置から、当該所定の情報を取得する取得ステップと、
を備えることを特徴とするコンテクスト情報保持方法が提供される。
【００１９】
また、本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける通信制御装置と前記基地局とが実行するコンテクスト情報保持方法であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、前記基地局が、前記コンテクスト情報における所定の情報を削除するステップと、
前記ユーザ装置が接続状態を再開する場合に、前記基地局が、当該接続状態の再開を示す信号を前記通信制御装置に送信するステップと、
前記通信制御装置が、前記信号を受信し、前記所定の情報を含む応答信号を前記基地局に送信するステップと
を備えることを特徴とするコンテクスト情報保持方法が提供される。
【発明の効果】
【００２０】
本発明の実施の形態によれば、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、基地局が保持するコンテクスト情報のサイズを削減することを可能とする技術が提供される。
【図面の簡単な説明】
【００２１】
【図１】ＲＲＣアイドル状態に遷移する場合のシグナリングシーケンス例を示す図である。
【図２】ＵＥコンテクストを保持する場合の処理の例を説明するための図である。
【図３】本発明の実施の形態における通信システムの構成図である。
【図４】実施例１におけるシステム全体の処理シーケンスの例を示す図である。
【図５】実施例１におけるシステム全体の処理シーケンスの例を示す図である。
【図６】UE context suspend procedureを示す図である。
【図７】UE context resume procedureを示す図である。
【図８】UE capabilityの送信手順例を示す図である。
【図９】UE context resume requestメッセージを説明するための図である。
【図１０】UE context resume responseメッセージを説明するための図である。
【図１１】UE context suspend requestメッセージを説明するための図である。
【図１２】UE context suspend responseメッセージを説明するための図である。
【図１３】実施例２におけるシステム全体の処理シーケンスの例を示す図である。
【図１４】実施例２における接続確立手順を説明するための図である。
【図１５】実施例２における接続解放手順を説明するための図である。
【図１６】UE capabilityに関する仕様変更例を示す図である。
【図１７】UE capabilityに関する仕様変更例を示す図である。
【図１８】UE capabilityに関する仕様変更例を示す図である。
【図１９】ＭＭＥとＳ−ＧＷの構成図である。
【図２０】ＭＭＥ３０のＨＷ構成図である。
【図２１】ＵＥ５０の構成図である。
【図２２】ＵＥ５０のＨＷ構成図である。
【図２３】ｅＮＢ１０の構成図である。
【図２４】ｅＮＢ１０のＨＷ構成図である。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態では、ＬＴＥのシステムを対象としているが、本発明はＬＴＥに限らずに適用可能である。例えば、５Ｇにも適用可能である。また、本明細書及び特許請求の範囲では、特に断らない限り、「ＬＴＥ」の用語は３ＧＰＰの特定のＲｅｌ（リリース）に限定されない。
【００２３】
また、以下で説明する実施の形態では、保留／アイドル状態になったときに、ｅＮＢにおいて保持するＵＥコンテクストからUE capabilityを削除し、接続を再開する際に、UE capabilityをＭＭＥから取得することとしているが、情報量削減の対象をUE capabilityとすることは一例に過ぎない。例えば、UE capabilityに代えて、もしくは、UE capabilityに加えて、RadioResourceConfigDedicatedの情報を削減の対象としてもよい。すなわち、保留／アイドル状態になったときに、ｅＮＢにおいて保持するＵＥコンテクストからRadioResourceConfigDedicatedの情報を削除し、接続を再開する際に、RadioResourceConfigDedicatedの情報をＭＭＥから取得することとしてもよい。また、UE capability、RadioResourceConfigDedicated以外の情報を対象としてもよい。
【００２４】
（システム全体構成）
図３は、本発明の実施の形態における通信システムの構成例を示す図である。図３に示すように、本実施の形態の通信システムは、ｅＮＢ１０、ｅＮＢ２０、ＭＭＥ３０、Ｓ−ＧＷ（Serving Gateway）４０、ＵＥ５０を含む。なお、図３は、コアネットワーク（ＥＰＣ）に関して、本実施の形態に関連する部分のみを示している。
【００２５】
ＵＥ５０は携帯電話機等のユーザ装置である。ｅＮＢ１０、２０はそれぞれ基地局である。ＭＭＥ３０は、ｅＮＢを収容し、位置登録、ページング、ハンドオーバ等のモビリティ制御、ベアラ確立／削除等を行うノード装置である。Ｓ−ＧＷ４０は、ユーザデータ（Ｕ−Ｐｌａｎｅデータ）の中継を行うノード装置である。なお、ＭＭＥ３０を通信制御装置と称してもよい。また、ＭＭＥ３０とＳ−ＧＷ４０を１つの装置で構成し、それを通信制御装置と称してもよい。
【００２６】
図３に示すように、ＭＭＥ３０とｅＮＢ１０、２０間はＳ１−ＭＭＥインターフェースで接続され、Ｓ−ＧＷ４０とｅＮＢ１０、２０間はＳ１−Ｕインターフェースで接続される。点線の接続線は制御信号インターフェースを示し、実線の接続線はユーザデータ転送のインターフェースを示す。
【００２７】
本実施の形態では、前述したように、ＵＥ５０が同一ｅＮＢ内でＲＲＣ接続状態からＲＲＣアイドル状態に遷移する場合でも、当該ｅＮＢにおいてＵＥ５０のＵＥコンテクストが保持されるとともに、ＵＥ５０にも当該ｅＮＢとの接続に係るＵＥコンテクストが保持される方式を前提とする。前述したように、この方式は、シグナリング数削減を可能とする方式である。
【００２８】
本実施の形態では、上記の方式の例として、非特許文献３に記載されている、RRC-Suspended（及びECM-Suspended）という新しいRRCの状態を定義する方式をベースとした実施例を実施例１として説明し、新たなRRCの状態を定義することなくＵＥコンテクストの再利用を行う方式をベースとした実施例を実施例２として説明する。
【００２９】
（実施例１）
まず、実施例１について説明する。上記のとおり、実施例１の方式では、従来のRRC-Idle（ＲＲＣアイドル状態）とRRC-Connected（ＲＲＣ接続状態）に加えて、RRC-Suspended（ＲＲＣ保留状態と呼ぶ）という状態が追加されている。ＲＲＣ保留状態において、ＵＥとｅＮＢはそれぞれ、ＲＲＣ保留状態になる前のＲＲＣ接続状態で接続に使用したＵＥコンテクストを保持する。そして、ＲＲＣ保留状態からＲＲＣ接続状態に遷移するときに、当該保持したＵＥコンテクストを使用してＲＲＣ接続確立をする。
【００３０】
＜実施例１：全体シーケンス例＞
まず、実施例１における通信システム全体のシーケンス例として、ＵＥ５０が、ＲＲＣアイドル状態からＲＲＣ保留状態（及びＥＣＭ保留状態）に遷移する場合の処理シーケンスを図４を参照して説明する。なお、図４、及び後述する図５に示す全体の処理シーケンス自体は、非特許文献３に開示されているものなので、ここでは概要を説明する。もちろん、UE capabilityに関する動作は非特許文献３に開示されていない。
【００３１】
ステップ１０１において、ｅＮＢ１０は、ＲＲＣ接続を保留することを決定する。ステップ１０２において、ｅＮＢ１０は、ＵＥ５０のＲＲＣ接続が保留されたことを示すメッセージをＭＭＥ３０に送信する。ＭＭＥ３０とｅＮＢ３０はＵＥコンテクストを保持する。
【００３２】
ステップ１０３、１０４でのメッセージを経て、ステップ１０５において、ＭＭＥ３０はステップ１０２に対するＡｃｋを返す。ステップ１０６で、ＭＭＥ３０はECM-SUSPENDEDの状態に入る。
【００３３】
ステップ１０７では、ｅＮＢ１０はＵＥ５０にRRC connection suspendメッセージを送信し、ＵＥ５０をＲＲＣ保留状態にする（ステップ１０８）。RRC connection suspendメッセージには、Resume ID（再開ＩＤ）が含まれる。Resume IDは、次にＲＲＣ接続を再開する場合に使用される識別子である。ＲＲＣ保留状態において、ＵＥ５０とｅＮＢ１０はそれぞれ、ＵＥコンテクストを格納する。
【００３４】
ここで、本実施の形態において、ＵＥ５０とｅＮＢ１０のそれぞれで保持されるＵＥコンテクストは、例えば、ＲＲＣコンフィギュレーション（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で運ばれるコンフィギュレーション情報等を、ＵＥコンテクストとして保持する。なお、これらは一例であり、ＵＥコンテクストとして保持する情報は、これらに限られず、追加で情報を保持してもよいし、これらの情報の一部を保持しないこととしてもよい。
【００３７】
また、本実施の形態では、UE radio capability（これをUE capabilityと記述する）もＵＥコンテクストに含まれる情報である。ただし、後述するように、本実施の形態では、ＲＲＣ保留状態において、基本的に、ｅＮＢ１０はUE capabilityを保持しないようにしている。また、UE capabilityはUE radio capabilityに限られるわけではない。
【００３８】
ＵＥ１０とｅＮＢ１０はそれぞれＵＥコンテクストとして上記のような情報を保持することで、ＲＲＣ保留状態からＲＲＣ接続状態に遷移する際に、RRC Connection Setup Complete、RRC Security Mode Command、RRC Security Mode Complete、RRC Connection Reconfiguration、RRC Connection Reconfiguration Complete、等のメッセージの送受信を行うことなくＲＲＣ接続確立を行うことができる。
【００３９】
次に、ＵＥ５０が、ＲＲＣ保留状態からＲＲＣ接続状態に遷移する場合のシーケンス例を図５を参照して説明する。図５は、ＲＲＣ保留状態（ステップ１５１）にあるＵＥ５０が着信を受ける（ステップ１５２〜１５５）ケースを示しているが、これは例であり、ＲＲＣ保留状態にあるＵＥ５０が発信をする場合も、ＵＥコンテクストの再利用に関しては同様の処理が行われる。
【００４０】
ｅＮＢ１０からページングを受信したＵＥにおいて、ステップ１５６では、ＥＭＭレイヤから、ＲＲＣ再開手順（resume procedure）が起動される。ステップ１５７にてRandom Access PreambleがＵＥ５０からｅＮＢ１０に送信され、ステップ１５８にて、Random Access ResponseがｅＮＢ１０からＵＥ１０に返される。
【００４１】
ステップ１５９では、メッセージ３として、ＵＥ５０は、RRC Connection Resume RequestメッセージをｅＮＢ１０に送信する。
【００４２】
当該RRC Connection Resume Requestメッセージには、ＵＥ５０がＵＥコンテクストを保持することを示す情報であるResume Id（再開ＩＤ）が含まれる。RRC Connection Resume Requestメッセージを受信したｅＮＢ１０は、当該メッセージに含まれるResume Idに対応付けて格納されている、ＵＥ５０のＵＥコンテクストを取得し、ＵＥコンテクストの情報に基づき、ベアラの再開等を行う。ステップ１６０では、ｅＮＢ１０は、ＵＥ５０に対してResume Idを含むRRC Connection Resume Completeメッセージを送信する。
【００４３】
ステップ１６１では、ＵＥ５０とｅＮＢ１０は、格納したセキュリティコンテクストを再開する。そして、ステップ１６２〜１６５において、ＭＭＥ３０に対するＵＥ５０の状態変更の通知等が行われる。
【００４４】
＜ＵＥコンテクストの保留手順、再開手順について＞
図４、図５を参照して説明したS1-AP UE Context Suspend, resumeに関するシグナリングの例が、例えば非特許文献４（R3-152688）に記載されている。非特許文献４には、非特許文献１（3GPP TS 36.413）に対する変更として、S1-AP UE Context Suspend, resumeに関するシグナリング等が記載されている。
【００４５】
実施例１において、非特許文献４の技術を適用すると、図４に示すステップ１０２、ステップ１０５に対応して、図６に示すステップ２０１、ステップ２０２が実行される。
【００４６】
ＵＥコンテクストの保留手順（UE context suspend procedure）を示す図６において、ステップ２０１で、ｅＮＢ１０はUE Context Suspend request（ＵＥコンテクスト保留要求）をＭＭＥ３０に送信する。これにより、ＭＭＥ３０は、ＵＥコンテクストが保留状態であることを把握する。また、ステップ２０２により、ＭＭＥ３０はｅＮＢ１０にUE Context Suspend response（ＵＥコンテクスト保留応答）を送信する。これにより、ｅＮＢ１０はＲＲＣ接続を保留状態とする。
【００４７】
また、実施例１において、非特許文献４の技術を適用すると、図５に示すステップ１６２、ステップ１６５に対応して、図７に示すステップ３０１、ステップ３０２が実行される。
【００４８】
ＵＥコンテクストの再開手順（UE context resume procedure）を示す図７において、ステップ３０１で、ｅＮＢ１０はUE Context Resume request（ＵＥコンテクスト再開要求）をＭＭＥ３０に送信する。これにより、ＭＭＥ３０は、ＵＥコンテクストが再開されたことを把握する。また、ステップ３０２により、ＭＭＥ３０はｅＮＢ１０にUE Context Resume response（ＵＥコンテクスト再開応答）を送信する。
【００４９】
＜ＵＥコンテクストとしてのUE capabilityの保持／送信について＞
本実施の形態におけるシステムの通常の動作として、ＵＥ５０の電源ＯＮ等に実施されるアタッチ手順、あるいは、ＵＥ５０からＭＭＥ３０へのサービス要求手順等において、ｅＮＢ１０はＭＭＥ３０からUE capabilityを取得する。もしも、ＭＭＥ３０に当該ＵＥ５０のcapabilityが保存されていない場合は、ｅＮＢ１０がＵＥ５０に直接要求して取得する。
【００５０】
ｅＮＢ１０がＵＥ５０に直接要求して取得する場合の手順の例を図８に示す（非特許文献５）。図８に示すとおり、ｅＮＢ１０がＵＥ５０にUECapabilityEnquiry（ＵＥ能力情報要求）を送信し（ステップ１１）、当該要求に応じて、ＵＥ５０がｅＮＢ１０にUE capabilityを送信する（ステップ１２）。ｅＮＢ１０は、ＵＥ５０から取得したUE capabilityをＭＭＥ３０に送信し、ＭＭＥ３０は当該UE capabilityを保持する。
【００５１】
本実施の形態ではＵＥコンテクストにUE capabilityが含まれる。しかし、既に説明したように、UE capabilityのサイズは、通常、数百ビットにもなる。そのため、数多くの保留状態のＵＥのcapabilityをＵＥコンテクストとしてｅＮＢ１０で保存しようとすると、大きなメモリ容量を確保する必要があり、ｅＮＢ１０のコスト高に繋がる。
【００５２】
そこで、実施例１では、ＵＥ５０がＵＥコンテクストを保持した状態で保留状態に遷移した場合、ｅＮＢ１０はＵＥ５０のUE capabilityを保存せず、消去する。
【００５３】
具体的には、図４に示すシーケンスにおいて、ステップ１０７で、ｅＮＢ１０がＵＥ５０にRRC connection suspendメッセージを送信した後、ｅＮＢ１０は、ｅＮＢ１０に保持しているＵＥ５０のUE capabilityを消去する。
【００５４】
また、ＵＥ５０がＲＲＣ接続状態に復帰する場合には、S1-AP UE context resume procedure（図５のステップ１６２、１６５、図７でのステップ３０１、３０２）を用いることにより、ｅＮＢ１０はＵＥ５０のcapabilityを取得する。
【００５５】
具体的には、まず図７を参照して説明すると、ｅＮＢ１０は、ステップ３０１のUE context resume requestでＭＭＥ３０にＵＥ５０のcapabilityを要求する。つまり、UE context resume requestには、ＵＥ５０のcapabilityを要求することを示す要求情報が含まれる。
【００５６】
ＭＭＥ３０は、UE context resume requestに含まれる要求情報に応じて、保持していたＵＥ５０のcapabilityをUE context resume responseに含めてｅＮＢ１０に送信する（ステップ３０２）。これにより、ｅＮＢ１０は、ＵＥ５０のUE capabilityを取得することができる。
【００５７】
なお、ステップ３０１において、UE context resume requestの中にＵＥ５０のcapabilityを要求することを示す要求情報を含めずに、ステップ３０２において、一律に、ＭＭＥ３０が、保持していたＵＥ５０のcapabilityをUE context resume responseに含めてｅＮＢ１０に送信することとしてもよい。なお、この場合、UE context resume request自体が上記要求情報に該当することになる。
【００５８】
図５のシーケンスでは、ステップ１６２において、ｅＮＢ１０は、ＲＲＣ接続を再開するＵＥ５０のcapabilityをＭＭＥ３０に要求する。ステップ１６５において、ＭＭＥ３０は、保持していたＵＥ５０のcapabilityをｅＮＢ１０に送信する。
【００５９】
上記の処理を行う場合におけるUE context resume requestメッセージの内容例を図９に示す。図９は、非特許文献４に記載されている、非特許文献１（3GPP TS 36.413）に対して追加される内容に基づくが、下線を引いた部分は上述したUE capabilityの取得に関連し、非特許文献４に記載されていない。UE context resume procedure関連のメッセージ内容を示す他の図も同様である。
【００６０】
図９に示すように、UE context resume requestメッセージには、ＵＥの識別子として、MME UE S1AP ID、eNB UE S1AP ID、及びS-TMSI（SAE temporary mobile subscriber identity）が含まれる。S-TMSIは、ＵＥ５０固有の識別子から生成される一時的なＵＥ５０の識別子であり、ＵＥ５０の位置登録時等にＭＭＥ３０から払い出されるものである。本実施の形態において、ＭＭＥ３０は、ＵＥ５０のUE capabilityを、ＵＥ５０のS-TMSIと対応付けて保持していることから、ＭＭＥ３０は、UE context resume requestメッセージに含まれるＵＥ５０のS-TMSIを用いて、複数のUE capabilityを格納した記憶部を検索することで、ＵＥ５０のUE capabilityを抽出することができる。
【００６１】
なお、ＵＥの識別子としてS-TMSIを用いることは一例に過ぎない。ＵＥ５０のUE capabilityを抽出することができるのであれば、どのような識別子を用いてもよい。例えば、UE context resume requestメッセージに、S-TMSIを含めずに、ＭＭＥ３０がMME UE S1AP ID又はeNB UE S1AP IDでＵＥ５０を特定し、ＵＥ５０のUE capabilityを抽出することとしてもよい。
【００６２】
図１０は、UE context resume responseメッセージの内容例を示す。図１０に示すように、ＭＭＥ３０により抽出されたＵＥ５０のUE capabilityが含まれている。
【００６３】
＜保留状態に遷移する際のUE capabilityの転送について＞
実施例１において、ＵＥ５０がＵＥコンテクストを保持した状態で保留状態に遷移する際に、ｅＮＢ１０がＭＭＥ３０にＵＥ５０のUE capabilityを転送することとしてもよい。具体的には、図４でのステップ１０２、図６でのステップ２０１においてＵＥ５０のUE capabilityが転送される。
【００６４】
UE capability（転送UE capabilityと呼ぶ）を受信したＭＭＥ３０は、転送UE capabilityを格納する。既にUE capabilityを格納している場合には、例えば、既に格納しているUE capabilityに上書きして転送UE capabilityを格納する。また、転送UE capabilityが、既に格納しているUE capabilityに対して更新された情報や新たな情報を含む場合に、当該更新された情報や新たな情報のみを上書きしてもよい。
【００６５】
UE capabilityは、この前の段階でアタッチ手順等においてｅＮＢ１０からＭＭＥ３０に送信されているので、ここでの転送は必須ではないが、この転送を行うことで、最新のUE capabilityをＭＭＥ３０が保持できる。
【００６６】
図１１に、上記の転送を行う場合におけるUE context suspend requestメッセージの内容例を示す。図１１に示すように、UE capabilityが含められる。図１２は、UE context suspend responseメッセージの内容例を示す。
【００６７】
（実施例２）
次に、実施例２について説明する。前述したとおり、実施例２は、RRC-Suspendedのような新しい状態を定義することなく、ＲＲＣアイドル状態において、ＵＥとｅＮＢがＵＥコンテクストを保持し、ＲＲＣ接続状態に遷移する際に、保持したＵＥコンテクストを再利用することで、シグナリング数削減を可能とする方式である。
【００６８】
＜全体のシーケンス例＞
まず、実施例２における通信システム全体のシーケンス例として、ＲＲＣアイドル状態のＵＥ５０に対する着信がある場合に、ＭＭＥ３０からページングを行う方式について説明する。より具体的には、ＵＥ５０がｅＮＢ１０に接続してＲＲＣ接続状態となり、ｅＮＢ１０の配下のセルでＲＲＣアイドル状態となり、同一セルで、その後に着信を受ける場合の処理シーケンスを図１３を参照して説明する。
【００６９】
図１３の処理の前提として、ＵＥ５０はｅＮＢ１０のセルにおいてＲＲＣ接続状態にあり、ＵＥ５０に関するＳ１−Ｃ／Ｕのコネクションが確立されている状態とする。図１３において、Ｓ１−Ｃコネクションは、ｅＮＢ１０とＭＭＥ３０との間のコネクションとＭＭＥ３０とＳ−ＧＷ４０間のコネクションを含み、Ｓ１−Ｕコネクションは、ｅＮＢ１０とＳ−ＧＷ４０間のコネクションを含む。コネクションが確立されている場合、コネクション確立信号等のコネクションセットアップのための手順を実行することなく、該当ノード装置間でＵＥ５０に係る信号（データ）を送受信できる。
【００７０】
図１３の手順の説明に入る前に、ＵＥ５０が最初にｅＮＢ１０に接続する際の手順の一例の概要を説明しておく（非特許文献５）。なお、この最初の接続に係る手順は、実施例１にも適用できる。ＵＥ５０のランダムアクセス時に、ｅＮＢ１０は、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）をＵＥ５０に送信し、ＵＥ５０をＲＲＣアイドル状態に遷移させる（ステップ４０５）。
【００７７】
実施例２では、ＵＥ５０が、ＲＲＣアイドル状態に遷移する場合でも、ＵＥ５０とｅＮＢ１０のそれぞれにおいて、ＲＲＣ接続時に確立したＵＥコンテクストは保持される。
【００７８】
ただし、実施例１と同様に、基本的に、ｅＮＢ１０はＵＥコンテクストのうち、UE capabilityを保持しないようにしている。
【００７９】
よって、図４でのステップ１０７の後のUE capability消去と同様に、図１３のステップ４０５（RRC Connection Release送信）の後、ｅＮＢ１０は、ｅＮＢ１０に保持しているＵＥ５０のUE capabilityを消去する。
【００８０】
また、実施例１で、保留状態に遷移する際にUE capabilityを転送する場合と同様に、ｅＮＢ１０は、ステップ４０１において、コネクション維持指示信号にUE capabilityを含め、当該コネクション維持指示信号をＭＭＥ３０に送信することとしてもよい。
【００８１】
UE capability（転送UE capabilityと呼ぶ）を受信したＭＭＥ３０は、転送UE capabilityを格納する。既にUE capabilityを格納している場合には、例えば、既に格納しているUE capabilityを上書きして転送UE capabilityを格納する。また、転送UE capabilityが、既に格納しているUE capabilityに対して更新された情報や新たな情報を含む場合に、当該更新された情報や新たな情報のみを上書きしてもよい。
【００８２】
その後、ＵＥ５０向けの下りデータが発生し、当該下りデータがＳ−ＧＷ４０に到着する（ステップ４０６）。ここでは、Ｓ１−Ｕコネクションは確立済みであるが、ステップ４０２で受信したコネクション維持指示信号に基づき、Ｓ−ＧＷ４０は、当該下りデータをｅＮＢ１０に転送せずにバッファに保留しておく。
【００８３】
Ｓ−ＧＷ４０は、下りデータ着信通知をＭＭＥ３０に送信し（ステップ４０７）、ＭＭＥ３０はＵＥ５０向けのＳ１−ＡＰページングの信号をｅＮＢ１０に送信する（ステップ４０８）。このページング自体は、既存のページングと同様であり、ＵＥ５０のトラッキングエリアの各ｅＮＢに送信されるが、図１３ではｅＮＢ１０への送信を示している。
【００８４】
Ｓ１−ＡＰページングの信号を受信したｅＮＢ１０は、配下のＵＥ５０にＲＲＣページングの信号を送信する（ステップ４０９）。
【００８５】
ＲＲＣページング信号を受信したＵＥ５０は、ＲＲＣ接続確立手順を実行し、ＲＲＣ接続を確立させる（ステップ４１０）。ＲＲＣ接続確立手順の詳細例は後述する。
【００８６】
ステップ４１０の手順により、ＵＥ５０は、ＲＲＣアイドル状態からＲＲＣ接続状態になる。このとき、ＵＥ５０とｅＮＢ１０に保持されているＵＥコンテクストは、それぞれ、非アクティブ状態からアクティブ状態になる。つまり、ステップ４１０の手順により、ＵＥ５０とｅＮＢ１０に保持されているＵＥコンテクストは、それぞれ、アクティベートされる。
【００８７】
ステップ４１１において、ｅＮＢ１０は、ＲＲＣ接続の確立が完了したことを示す信号であるＲＲＣ接続確立完了をＭＭＥ３０に送信する。このＲＲＣ接続確立完了の信号は、ＵＥ５０のＵＥコンテクストがアクティベートされたことを示す信号であってもよい。
【００８８】
また、実施例１での図５のステップ１６２、図７でのステップ３０１と同様に、ステップ４１１において、ｅＮＢ１０はＲＲＣ接続確立完了の信号に、ＵＥ５０のUE capabilityを要求することを示す要求情報を含めて送信する。当該要求情報は、例えば、ＵＥ５０のS-TMSI（ＵＥ識別子の一例）である。実施例１の場合と同様に、当該要求情報を含めずに、一律に、ＭＭＥ３０が後述するステップ４１４でＵＥ５０のUE capabilityをｅＮＢ１０に送信することとしてもよい。
【００８９】
ＭＭＥ３０はＲＲＣ接続確立完了の信号をＳ−ＧＷ４０に送信する（ステップ４１２）。
【００９０】
そして、ステップ４１３において、Ｓ−ＧＷ４０は、ＲＲＣ接続確立完了の信号に対する応答の信号をＭＭＥ３０に送信する。また、ステップ４１４において、ＭＭＥ３０は、ステップ４１１のＲＲＣ接続確立完了の信号に対する応答の信号をｅＮＢ１０に送信する。ステップ４１４における応答の信号は、ＵＥコンテクストがアクティベートされたことを示す信号に対するＡｃｋの信号であってもよい。
【００９１】
また、実施例１での図５のステップ１６５、図７でのステップ３０２と同様に、ＭＭＥ３０は、ステップ４１１のＲＲＣ接続確立完了の信号に含まれる要求情報（あるいは要求情報以外のＵＥ識別子）に基づき、保持していたＵＥ５０のcapabilityを抽出し、これをステップ４１４の応答信号に含めてｅＮＢ１０に送信する。これにより、ｅＮＢ１０は、ＵＥ５０のUE capabilityを取得することができる。
【００９２】
その後、Ｓ−ＧＷ４０は保留していた下りデータのｅＮＢ１０への転送を開始する（ステップ４１５）。当該下りデータはｅＮＢ１０からＵＥ５０に届く（ステップ４１６）。このようにしてＵＥ５０への下りデータの伝送が開始される。
【００９３】
図１３のステップ４１０のＲＲＣ接続確立手順では、ＵＥ５０とｅＮＢ１０のそれぞれでＲＲＣ接続時に確立し、保持しておいたＵＥコンテクストが利用されるので、従来は必要であった、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のコンフィギュレーション等）等である。また、UE capabilityもＵＥコンテクストに含まれるが、上述したように、ｅＮＢ１０は、ＵＥ５０がＲＲＣアイドル状態中において、UE capabilityを保持しないようにしている。
【００９５】
また、ＵＥ５０とｅＮＢ１０とでＵＥコンテクストとして同じ情報を保持してもよいし、ＵＥ５０は、ｅＮＢ１０との接続に必要なＵＥコンテクストの情報のみを保持し、ｅＮＢ１０は、ＵＥ５０との接続に必要なＵＥコンテクストの情報のみを保持してもよい。
【００９６】
また、実施例２では、ｅＮＢ１０は、ＵＥコンテクストを、当該ＵＥコンテクストに対応するＵＥの識別子（ＵＥ識別子）に対応付けて記憶手段に保持する。ＵＥ識別子の種類には限定はないが、実施例２では、一例として、ＵＥ識別子として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メッセージを受信したｅＮＢ１０は、当該メッセージに含まれる認証情報を使用して、ＵＥ５０が、ＵＥ識別子により検索されたＵＥコンテクストに対応する正しいＵＥであることを認証する。その後、ＵＥ５０とｅＮＢ１０はそれぞれ、保持していたＵＥコンテクストを利用して接続を確立（再開）する。なお、保持していたＵＥコンテクストを利用して接続を確立（再開）するにあたって、ステップ５０３は必ずしも必須ではなく、ステップ５０３を実施しないこととしてもよい。
【０１０７】
＜ＲＲＣ接続確立手順の変形例＞
変形例のＲＲＣ接続確立手順におけるシーケンス自体は、図１４に示したシーケンスと同じであるので、図１４を参照してＲＲＣ接続確立手順の変形例について説明する。変形例においても、図１４に示すシーケンスは、図１３のステップ４１０の手順を想定しているが、これに限られない。
【０１０８】
図１４に示すシーケンスの前に、ＵＥ５０からｅＮＢ１０に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）に対応するＵＥコンテクストを記憶手段から検索することにより行うことができる。なお、ＵＥコンテクストをアクティベート（アクティブ化）することを指示する情報は、ｅＮＢ１０がＵＥ５０のＵＥコンテクストを保持していることを示すコンテクスト保持情報の例である。
【０１１２】
ｅＮＢ１０がＵＥ５０のＵＥコンテクストを保持していることを検知できなかった場合には、ｅＮＢ１０は、ＵＥ５０が保持しているＵＥコンテクストをアクティベート（アクティブ化）することを指示する情報を含まない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 Releaseメッセージを受信してＲＲＣアイドル状態に遷移する際に、常にＵＥコンテクストを保持することとしてもよいし、RRC Connection Releaseメッセージ内にＵＥコンテクストを保持することを指示する情報が含まれていた場合にのみＵＥコンテクストを保持することとしてもよい。後者の例を以下に説明する。
【０１２０】
図１５に示すように、ｅＮＢ１０がＵＥ５０をＲＲＣアイドル状態に遷移させる場合に、ｅＮＢ１０はＵＥ５０に対してRRC Connection Releaseメッセージを送信する（ステップ６０１）。
【０１２１】
当該RRC Connection Releaseメッセージには、ＲＲＣアイドル状態においてＵＥコンテクストを保持し続けることをＵＥ５０に指示する指示情報（indication）が含まれる。なお、指示情報については、新規のindicationをメッセージ中に含めても良いし、既存のrelease causeのスペアビットを用いることとしてもよい。
【０１２２】
ＵＥ５０は、RRC Connection Releaseメッセージから上記指示情報を検知した場合、ＲＲＣアイドル状態の間、ＲＲＣアイドル状態遷移時のＵＥコンテクスト（ベアラ情報，セキュリティ情報等）を保持し続ける。なお、所定の時間をＵＥ５０に設定し、ＵＥ５０がＲＲＣアイドル状態に遷移した時点から、ＲＲＣアイドル状態のままで当該所定の時間が経過した場合には、ＵＥ５０は、保持しているＵＥコンテクストを無効として、これを解放（削除）してもよい。
【０１２３】
（UE Capabilityのサイズ削減について）
以下、本実施の形態におけるUE Capabilityのサイズ削減について説明する。ここで説明する事項は、実施例１、実施例２のいずれにも適用可能である。
【０１２４】
今後、NB-IoT UE(NarrowBand Internet of Things UE)やLow cost MTC UE(Machine Type Communication UE)のような、一般的な携帯端末よりも機能が限定された端末が増加することが考えられる。
【０１２５】
例えば、NB-IoT UEは、上り180KHz以下（最低3.75 or 15KHz）の帯域幅で通信するため、伝送速度が低い。以下、便宜上、NB-IoT UEやLow cost MTC UE等のUEを総称して低速度UEと呼ぶ場合がある。
【０１２６】
一方、既存のLTE UE capabilityはRel-8から規定されているパラメータを入れ子に拡張する形で規定されており、既存のLTE UE capabilityに追加でNB-IoT UE等の低速度UE向けのcapabilityを規定すると、Rel-8からRel-12までのパラメータを拡張して定義することによるオーバーヘッドが発生する。例えば，Rel-12 version 12.7.0仕様のUE capabilityに追加でNB-IoT UEのcapabilityを規定しようとすると、最低でも17 bytesの大きさになる。
【０１２７】
既存のLTE UE capabilityには、mandatoryで含まれるパラメータ（含めることが必須であるパラメータ）が幾つかあり、それらがUE capabilityのサイズ増加の一要因になっている。
【０１２８】
例えば、FGI (feature group indicators) については、UEが全てのFGIに対応していれば省略できるが、現状そのようなUEは世の中に存在しておらず、UEは、UE capabilityに必ずFGIの96ビットのビット列を付加し、各FGIの対応有無（1/0）を通知しなければならない。また、Measurement gap（測定ギャップ）の必要性有無を示す情報も必ず通知する必要がある。更に、PDCPのパラメータも必ず通知する必要がある。
【０１２９】
そこで、本実施の形態では、NB-IoT UE等の低速度UE向けに新しいUE capabilityを導入する。
【０１３０】
当該UE capabilityに対応する仕様書（非特許文献５）の変更例を図１６〜図１８に示す。追加部分には下線が引かれている。
【０１３１】
図１６は、ＵＥ５０からｅＮＢ１０（及びＭＭＥ３０）に送信されるUE Capability Informationメッセージに含められる情報要素であるUE-CapabilityRAT-ContainerListを示す。UE-CapabilityRAT-ContainerListは、RAT毎にueCapabilityRAT-Containerを含む。本実施の形態では、RAT：E-UTRAに対し、UE-EUTRA-Capability-BLが追加されている。BLは、「bandwidth reduced low complexity」の略であり、BL UEは、上述したNB-IoT UE等の低速度UEを示す。
【０１３２】
図１７は、UE-EUTRA-Capability-BLの内容を示す。UE-EUTRA-Capability-BLは、低速度UE がUE Capability Informationメッセージに含めるUE capability (UE radio capability)に相当する。
【０１３３】
図１７に記載されているとおり、UE-EUTRA-Capability-BLは、BL UE（ここでは例としてＵＥ５０）が、UE capability (UE Radio Access Capability Parameters)をE-UTRA （ここでは例としてｅＮＢ１０）に送信するために使用される。
【０１３４】
図１７に示すUE-EUTRA-Capability-BLの情報要素の内容について、ＵＥカテゴリ（ue-Category）に関しては、既存のＵＥカテゴリは含めずに、新たに定めたBL UE用のＵＥカテゴリのみを含める。例えば、ＵＥ５０は、自身のカテゴリに応じて、m1として「Low Cost MTC UE」を示すカテゴリを含め、m2として「NB-IoT UE」を示すカテゴリを含める。ただし、これらは一例である。
【０１３５】
既存技術においてmandatoryであるFGI、PDCPパラメータ、measurement gapに関しては、デフォルトの能力を規定しておき、パラメータとしてシグナリングしない。すなわち、デフォルトの情報についてはUE capabilityに含めない。BL UEは機能が限定されているため、全てのBL UEが持つべき最低限の機能を想定し良い。このように全てのBL UEが持つと考えられる機能（能力）がデフォルトの能力として規定される。
【０１３６】
デフォルトの能力に対して追加の能力を持つ等、デフォルトの能力に対して能力の差分を有するUEは、当該差分（例：追加の能力を示すパラメータ）のみをUE capabilityに含めて通知する。このような差分の通知を可能とすることで、BL UEに実装する機能に柔軟性を持たせることができる。
【０１３７】
より具体的に、例えば、measurement gapは対応する周波数バンドに対してデフォルトで必要とし、UE capabilityに含めない。gap無でmeasurement可能である場合のみ、図１７における「GaplessMeas-r13」として、そのことを示す値を含める。
【０１３８】
PDCPパラメータに関しては、ROHC profileといったパラメータのデフォルト値を規定する。そして、ＵＥ５０のPDCPパラメータが、デフォルト値と異なる場合にのみ図１７における「PDCP-Parameters-r13」として、UE capabilityにその値を含める。
【０１３９】
また、物理レイヤパラメータについて、デフォルトで規定し、optionalで対応可能なものがあれば、図１７における「PhyLayerParameters」として、UE capabilityにその値を含める。
【０１４０】
3G、GERAN等の他RATの対応能力については、例えばデフォルトで無しとし、対応可能な他RATがある場合のみ、図１７における「interRAT-Parameters-r13」として、UE capabilityにその値を含める。
【０１４１】
Duplex方式に関し、対応する周波数バンドに対して、デフォルトでは、例えばhalf duplex対応のみとする。ＵＥ５０は、追加でfull duplexに対応する場合のみ、図１７における「FullDuplex-r13」として、UE capabilityに、そのことを示す値を含める。
【０１４２】
図１８は、BL UE用に新たに規定するFGIの定義の例を示す。図１８に示す例において、例えば、Rel-10対応のＵＥ５０が、カテゴリM1を通知する場合に、FDDとTDDの両方に対応している場合には、FGIの値（図１７のupportedFGIs-r13）として、例えば103を含める。
【０１４３】
＜UE capabilityサイズ削減を行う場合の実施例１、実施例２の動作について＞
上記のようなサイズの削減されたUE capabilityを用いる場合でも、実施例１、実施例２における動作は既に説明したものから変更しないこととしてもよいし、以下に示すように変更してもよい。
【０１４４】
すなわち、実施例１、実施例２において、ｅＮＢ１０は、ＵＥ５０が保留状態／アイドル状態になる際に、UE capabilityを削除していたが、対象とするUE capabilityがサイズの削減されたUE capabilityである場合には、この削除を行わないこととしてもよい。削除しなくても、UE capabilityに関するメモリ容量削減の課題を解決できるからである。サイズの削減されたUE capabilityであるか否かについては、例えば、ｅＮＢ１０は、UE capabilityにおけるＵＥカテゴリがM1又はM2である場合に、該当UE capabilityはサイズの削減されたUE capabilityであると判断できる。
【０１４５】
また、上記のように、UE capabilityの削除を行わない場合は、ｅＮＢ１０はＭＭＥ３０からのUE capabilityの取得（例：図５のステップ１６２、１６５、図１３のステップ４１１、４１４）を行わない。
【０１４６】
（装置構成例）
次に、本発明の実施の形態（実施例１、実施例２、UE capabilityサイズ削減を含む）における装置の構成例を説明する。以下で説明する各装置の構成は、発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥ（ＥＰＣを含む意味のＬＴＥ）に準拠した通信システムにおける装置として動作するための図示しない機能も有するものである。また、各図に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。
【０１４７】
各装置は、実施例１、実施例２、UE capabilityサイズ削減の全ての機能を備えてもよいし、実施例１と実施例２のうちのいずれか一方のみを備えることとしてもよいし、実施例１と実施例２のうちのいずれか一方とUE capabilityサイズ削減の機能を備えることとしてもよい。以下の説明では、各装置は実施例１、実施例２、UE capabilityサイズ削減の全ての機能を備えるものとする。
【０１４８】
＜ＭＭＥ、Ｓ−ＧＷの構成例＞
まず、図１９を参照して、ＭＭＥ３０とＳ−ＧＷ４０の構成例を説明する。図１９に示すように、ＭＭＥ３０は、ｅＮＢ通信部３１、ＳＧＷ通信部３２、通信制御部３３、ＵＥコンテクスト管理部３４を含む。
【０１４９】
ｅＮＢ通信部３１は、ｅＮＢとの間でＳ１−ＭＭＥインターフェースによる制御信号の送受信を行う機能を含む。ＳＧＷ通信部３２は、Ｓ−ＧＷとの間でＳ１１インターフェースによる制御信号の送受信を行う機能を含む。ＵＥコンテクスト管理部３４は、ＵＥコンテクストを保持する記憶手段を含む。また、ＵＥコンテクスト管理部３４は、ＭＭＥ３０がｅＮＢ１０からUE capabilityを要求する信号を受信した場合に、要求に含まれるＵＥ識別子に対応するUE capabilityを記憶手段から取得し、ｅＮＢ通信部３１等を介してｅＮＢ１０に送信する機能を含む。また、ＵＥコンテクスト管理部３４は、ＭＭＥ３０がｅＮＢ１０からUE capabilityを受信した際に、当該UE capabilityをＵＥ識別子と対応付けて記憶手段に格納する機能を有する。
【０１５０】
また、Ｓ−ＧＷ４０は、ｅＮＢ通信部４１、ＭＭＥ通信部４２、ＮＷ通信部４３、通信制御部４４を含む。ｅＮＢ通信部４１は、ｅＮＢとの間でＳ１−Ｕインターフェースによるデータの送受信を行う機能を含む。ＭＭＥ通信部４２は、ＭＭＥとの間でＳ１１インターフェースによる制御信号の送受信を行う機能を含む。ＮＷ通信部４３は、コアＮＷ側のノード装置との間で制御信号の送受信及びデータの送受信を行う機能を含む。
【０１５１】
なお、ここまでの説明は実施例１と実施例２で共通である。以下では特に、実施例２についての機能を説明する。
【０１５２】
通信制御部３３は、ｅＮＢ１０からコネクション維持指示信号を受信した場合に、コネクション維持指示信号をＳ−ＧＷに送信するようＳＧＷ通信部３２に指示するとともに、Ｓ−ＧＷ４０から確認応答を受信した場合に、当該確認応答をｅＮＢに送信するようＳＧＷ通信部３２に指示する機能を含む。また、通信制御部３３は、コネクション維持指示信号にUE capabilityが含まれている場合、UE capabilityをＵＥコンテクスト管理部３４に通知する機能を含む。
【０１５３】
また、通信制御部３３は、ＲＲＣ接続確立完了信号をｅＮＢ１０から受信した場合において、ＲＲＣ接続確立完了信号をＵＥコンテクスト管理部３４に通知し、ＵＥコンテクスト管理部３４にUE capabilityを取得させる。また、通信制御部３３は、応答信号（図１３のステップ４１４）をｅＮＢ１０に送信する際に、ＵＥコンテクスト管理部３４により取得されたUE capabilityを応答信号に含める機能も有することとしてもよい。
【０１５４】
通信制御部４４は、ＭＭＥ３０からコネクション維持指示信号を受信した場合に、確認応答をＭＭＥ３０に送信するようＭＭＥ通信部４２に指示する機能を含む。また、通信制御部４４は、ＭＭＥ３０からコネクション維持指示信号を受信している場合において、該当ＵＥへの下りデータを受信した場合に、当該下りデータをバッファに保留しておくようにＮＷ通信部４３に指示し、ＲＲＣ接続確立完了をｅＮＢから受信した場合に、当該下りデータを送信するようにＮＷ通信部４３に指示する機能を含む。
【０１５５】
なお、ＭＭＥ３０とＳ−ＧＷ４０を１つの装置として構成することもできる。その場合、ＳＧＷ通信部３２とＭＭＥ通信部４２間のＳ１１インターフェースの通信は、装置内部の通信となる。
【０１５６】
ＭＭＥ３０は、例えば、ＣＰＵとメモリを備え、プログラムがＣＰＵ（プロセッサ）により実行されることで実現されるコンピュータの構成を用いて実現できる。
【０１５７】
上記のようなコンピュータによりＭＭＥ３０を構成する場合におけるＭＭＥ３０のハードウェア（ＨＷ）構成の例を図２０に示す。
【０１５８】
図２０に示すように、当該ＭＭＥ３０は、ＣＰＵ３５１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）３５２、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）３５３、通信を行うための通信モジュール１５４、ハードディスク等の補助記憶装置３５５、入力装置３５６、出力装置３５７を備える。
【０１５９】
ＲＡＭ３５２、ＲＯＭ３５３、補助記憶装置３５５等の記憶手段に格納されたプログラムをＣＰＵ３５１が読み出し、実行することにより、ＭＭＥ３０の各機能の動作が実行される。また、通信を行う処理については、通信モジュール３５４が使用される。また、入力装置３５６により、例えば、ＭＭＥ３０に対する設定情報の入力を行い、出力装置３５７により、例えば、ＭＭＥ３０の稼働状態の出力等を行うことができる。
【０１６０】
次に、本発明の実施の形態におけるＵＥ５０とｅＮＢ１０の構成例を説明する。
【０１６１】
＜ユーザ装置ＵＥ＞
図２１に、ユーザ装置（ＵＥ５０）の機能構成図を示す。図２１に示すように、ＵＥ５０は、ＤＬ信号受信部５１、ＵＬ信号送信部５２、ＲＲＣ処理部５３、ＵＥコンテクスト管理部５４を備える。なお、図２１は、ＵＥ５０において本発明に特に関連する機能部のみを示すものであり、ＵＥ５０は、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。
【０１６２】
ＤＬ信号受信部５１は、基地局ｅＮＢから各種の下り信号を受信し、受信した物理レイヤの信号からより上位のレイヤの情報を取得する機能を含み、ＵＬ信号送信部５２は、ＵＥ５０から送信されるべき上位のレイヤの情報から、物理レイヤの各種信号を生成し、基地局ｅＮＢに対して送信する機能を含む。
【０１６３】
ＲＲＣ処理部５３は、図４〜図５、図８、図１３〜図１８等を参照して説明した、ＵＥ側の処理、ＲＲＣメッセージ（UE capability等）の生成・送信（送信はＵＬ信号送信部５２を介した送信）、ＤＬ信号受信部５１により受信したＲＲＣメッセージの解釈、解釈に基づく処理動作等を行う。また、ＲＲＣ処理部５３は、ＵＥコンテクスト管理部５４に保持しておいたＵＥコンテクストを利用してＲＲＣ接続を再開する機能等も含む。
【０１６４】
ＵＥコンテクスト管理部５４は、メモリ等の記憶手段を含み、例えば、図４のステップ１０７、図１５等で説明した指示に基づいて、ＲＲＣ保留状態／ＲＲＣアイドル状態においてＵＥコンテクスト及びＵＥ識別子（S-TMSI等）を保持する。また、図１４に示す手順においては、ＵＥコンテクストの保持の有無を判断し、ＵＥコンテクストを保持している場合には、ＵＥコンテクストを保持していることを示す情報を通知するよう、ＲＲＣ処理部５３に指示する。
【０１６５】
図２１に示すＵＥ５０の構成は、全体をハードウェア回路（例：１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。
【０１６６】
図２２は、ＵＥ５０のハードウェア（ＨＷ）構成の例を示す図である。図２２は、図２１よりも実装例に近い構成を示している。図２２に示すように、ＵＥは、無線信号に関する処理を行うＲＥ（Ｒａｄｉｏ  Ｅｑｕｉｐｍｅｎｔ）モジュール１５１と、ベースバンド信号処理を行うＢＢ（Ｂａｓｅ  Ｂａｎｄ）処理モジュール１５２と、上位レイヤ等の処理を行う装置制御モジュール１５３と、ＵＳＩＭカードにアクセスするインタフェースであるＵＳＩＭスロット１５４とを有する。
【０１６７】
ＲＥモジュール１５１は、ＢＢ処理モジュール１５２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ（Ｄｉｇｉｔａｌ−ｔｏ−Ａｎａｌｏｇ）変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ（Ａｎａｌｏｇ  ｔｏ  Ｄｉｇｉｔａｌ）変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール１５２に渡す。ＲＥモジュール１５１は、例えば、図２１のＤＬ信号受信部５１及びＵＬ信号送信部５２における物理レイヤ等の機能を含む。
【０１６８】
ＢＢ処理モジュール１５２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）１６２は、ＢＢ処理モジュール１５２における信号処理を行うプロセッサである。メモリ１７２は、ＤＳＰ１６２のワークエリアとして使用される。ＢＢ処理モジュール１５２は、例えば、図２１のＤＬ信号受信部５１及びＵＬ信号送信部５２におけるレイヤ２等の機能、ＲＲＣ処理部５３及びＵＥコンテクスト管理部５４を含む。なお、ＲＲＣ処理部５３及びＵＥコンテクスト管理部５４の機能の全部又は一部を装置制御モジュール１５３に含めることとしてもよい。
【０１６９】
装置制御モジュール１５３は、ＩＰレイヤのプロトコル処理、各種アプリケーションの処理等を行う。プロセッサ１６３は、装置制御モジュール１５３が行う処理を行うプロセッサである。メモリ１７３は、プロセッサ１６３のワークエリアとして使用される。また、プロセッサ１６３は、ＵＳＩＭスロット１５４を介してＵＳＩＭとの間でデータの読出し及び書込みを行う。
【０１７０】
＜基地局ｅＮＢ＞
図２３に、基地局ｅＮＢ（ｅＮＢ１０）の機能構成図を示す。図２３に示すように、ｅＮＢ１０は、ＤＬ信号送信部１１、ＵＬ信号受信部１２、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４、認証部１５、ＮＷ通信部１６を備える。なお、図２３は、ｅＮＢ１０において本発明の実施の形態に特に関連する機能部のみを示すものであり、ｅＮＢ１０は、少なくともＬＴＥ方式に準拠した動作を行うための図示しない機能も有するものである。
【０１７１】
ＤＬ信号送信部１１は、ｅＮＢ１０から送信されるべき上位のレイヤの情報から、物理レイヤの各種信号を生成し、送信する機能を含む。ＵＬ信号受信部１２は、ユーザ装置ＵＥから各種の上り信号を受信し、受信した物理レイヤの信号からより上位のレイヤの情報を取得する機能を含む。
【０１７２】
ＲＲＣ処理部１３は、図４〜図５、図８、図１３〜図１８等を参照して説明した、ｅＮＢ側の処理、ＲＲＣメッセージの生成・送信（送信はＤＬ信号送信部１１を介した送信）、ＵＬ信号受信部１２により受信したＲＲＣメッセージの解釈、解釈に基づく処理動作等を行う。
【０１７３】
ＵＥコンテクスト管理部１４は、メモリ等の記憶手段を含み、例えば、図４のステップ１０７、図１４等で説明した指示の送信に基づいて、ＲＲＣ保留状態／ＲＲＣアイドル状態においてＵＥコンテクスト及びＵＥ識別子（S-TMSI等）を保持する。また、ＵＥコンテクスト管理部１４は、ＲＲＣ保留状態／ＲＲＣアイドル状態に遷移した際にUE capabilityの削除を行う機能を含む。また、対象UE capabilityが、サイズの削減されたUE capabilityかどうかを判断し、サイズの削減されたUE capabilityである場合に、削除を行わないこととしてもよい。また、ＵＥコンテクスト管理部１４は、図５のステップ１６５、図１３のステップ４１４等においてＭＭＥ３０から取得したUE capabilityを記憶手段に格納する機能を含む。
【０１７４】
認証部１５は、図１４に示したステップ５０１、５０３等において、ＵＥから認証情報を受信し、ＵＥの認証を行う機能を含む。
【０１７５】
ＮＷ通信部１６は、Ｓ１−ＭＭＥインターフェースでＭＭＥとの間で制御信号を送受信する機能、及び、Ｓ１−ＵインターフェースでＳ−ＧＷとの間でデータを送受信する機能、コネクション維持指示信号の送信機能、ＲＲＣ接続確立完了の送信の送信機能等を含む。すなわち、ＮＷ通信部１６は、図５のステップ１６２、図１３のステップ４１１においてＭＭＥ３０にUE capabilityを要求する機能、図５のステップ１６５、図１３のステップ４１４においてＭＭＥ３０からUE capabilityを受信する機能を含む。
【０１７６】
図２３に示すｅＮＢ１０の構成は、全体をハードウェア回路（例：１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。
【０１７７】
図２４は、ｅＮＢ１０のハードウェア（ＨＷ）構成の例を示す図である。図２４は、図２３よりも実装例に近い構成を示している。図２４に示すように、ｅＮＢ１０は、無線信号に関する処理を行うＲＥモジュール２５１と、ベースバンド信号処理を行うＢＢ処理モジュール２５２と、上位レイヤ等の処理を行う装置制御モジュール２５３と、ネットワークと接続するためのインタフェースである通信ＩＦ２５４とを有する。
【０１７８】
ＲＥモジュール２５１は、ＢＢ処理モジュール２５２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール２５２に渡す。ＲＥモジュール２５１は、例えば、図２３のＤＬ信号送信部１１及びＵＬ信号受信部１２における物理レイヤ等の機能を含む。
【０１７９】
ＢＢ処理モジュール２５２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ２６２は、ＢＢ処理モジュール２５２における信号処理を行うプロセッサである。メモリ２７２は、ＤＳＰ２５２のワークエリアとして使用される。ＢＢ処理モジュール２５２は、例えば、図２３のＤＬ信号送信部１１及びＵＬ信号受信部１２におけるレイヤ２等の機能、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４、認証部１５を含む。なお、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４、認証部１５の機能の全部又は一部を装置制御モジュール２５３に含めることとしてもよい。
【０１８０】
装置制御モジュール２５３は、ＩＰレイヤのプロトコル処理、ＯＡＭ処理等を行う。プロセッサ２６３は、装置制御モジュール２５３が行う処理を行うプロセッサである。メモリ２７３は、プロセッサ２６３のワークエリアとして使用される。補助記憶装置２８３は、例えばＨＤＤ等であり、基地局ｅＮＢ自身が動作するための各種設定情報等が格納される。
【０１８１】
また、装置制御モジュール２５３は、図２３のＮＷ通信部１６により送受信する信号の処理を行う機能を含む。通信ＩＦ２５４は、図２３のＮＷ通信部１６における信号送受信の機能に相当する。
【０１８２】
なお、図１９〜図２４に示す装置の構成（機能区分）は、本実施の形態（実施例１、実施例２、UE capabilityサイズ削減を含む）で説明する処理を実現する構成の一例に過ぎない。本実施の形態で説明する処理を実現できるのであれば、その実装方法（具体的な機能部の配置、名称等）は、特定の実装方法に限定されない。
【０１８３】
（実施の形態のまとめ）
以上、説明したように、本実施の形態により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、当該コンテクスト情報における所定の情報を削除する削除手段と、前記ユーザ装置が接続状態を再開する場合に、前記移動通信システムにおいて前記所定の情報を保持する通信制御装置から、当該所定の情報を取得する取得手段と、を備える基地局が提供される。
【０１８４】
上記の構成により、ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおいて、基地局が保持するコンテクスト情報のサイズを削減することが可能となる。なお、ｅＮＢ１０のＵＥコンテクスト管理部１４は、削除手段の例である。また、ｅＮＢ１０のＮＷ通信部１６は、取得手段の例である。
【０１８５】
前記取得手段は、前記接続状態の再開を示す信号を前記通信制御装置に送信し、前記所定の情報を含む応答信号を前記通信制御装置から受信することとしてもよい。このようにして所定の情報を取得することで、例えば、図５に示すような信号の送受信を行う方式において、新たな信号を加えることなく、効率的に本発明を適用できる。
【０１８６】
前記接続状態の再開を示す信号には、前記ユーザ装置の識別子が含まれ、前記通信制御装置は、当該ユーザ装置の識別子に基づき前記所定の情報を抽出することとしてもよい。本構成により、通信制御装置は正確に目的の情報を抽出できるようになる。
【０１８７】
前記ユーザ装置が接続状態を終了する場合に、前記所定の情報を前記通信制御装置に送信する送信手段を更に備えてもよい。この構成により、例えば、何らかの理由で通信制御装置が前記所定の情報を保持していない場合であっても、接続状態の再開時に、前記所定の情報を取得できる。
【０１８８】
前記所定の情報は、例えば、前記ユーザ装置の能力情報である。能力情報のサイズは大きいので、この構成により、効率的に、基地局が保持すべきコンテクスト情報のサイズを削減できる。
【０１８９】
前記所定の情報が、サイズの削減された能力情報である場合に、前記削除手段は、当該能力情報の削除を行わず、前記取得手段は、当該能力情報の取得を行わないこととしてもよい。この構成により、基地局が保持すべきコンテクスト情報のサイズを削減できるとともに、シグナリングシーケンスを削減できる。
【０１９０】
前記サイズの削減された能力情報は、例えば、前記ユーザ装置においてデフォルトで備えられる能力についての情報を含まないように生成された能力情報である。この構成により、不必要な情報を通知することを回避して、能力情報のサイズ削減を実現できる。
【０１９１】
なお、上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。
【０１９２】
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、各装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従って当該装置が有するプロセッサにより動作するソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
【０１９３】
本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【符号の説明】
【０１９４】
１０、２０  ｅＮＢ
１１  ＤＬ信号送信部
１２  ＵＬ信号受信部
１３  ＲＲＣ処理部
１４  ＵＥコンテクスト管理部
１５  認証部
１６  ＮＷ通信部
３０  ＭＭＥ
３１  ｅＮＢ通信部
３２  ＳＧＷ通信部
３３  通信制御部
３４  ＵＥコンテクスト管理部
４０  Ｓ−ＧＷ
４１  ｅＮＢ通信部
４２  ＭＭＥ通信部
４３  ＮＷ通信部
４４  通信制御部
５０  ＵＥ
５１  ＤＬ信号受信部
５２  ＵＬ信号送信部
５３  ＲＲＣ処理部
５４  ＵＥコンテクスト管理部
１５１  ＲＥモジュール
１５２  ＢＢ処理モジュール
１５３  装置制御モジュール
１５４  ＵＳＩＭスロット
２５１  ＲＥモジュール
２５２  ＢＢ処理モジュール
２５３  装置制御モジュール
２５４  通信ＩＦ
３５１  ＣＰＵ
３５２  ＲＡＭ
３５３  ＲＯＭ
３５４  通信モジュール
３５５  補助記憶装置
３５６  入力装置
３５７  出力装置
【図１】
2017123582.tif 000003
【図２】
2017123582.tif 000004
【図３】
2017123582.tif 000005
【図４】
2017123582.tif 000006
【図５】
2017123582.tif 000007
【図６】
2017123582.tif 000008
【図７】
2017123582.tif 000009
【図８】
2017123582.tif 000010
【図９】
2017123582.tif 000011
【図１０】
2017123582.tif 000012
【図１１】
2017123582.tif 000013
【図１２】
2017123582.tif 000014
【図１３】
2017123582.tif 000015
【図１４】
2017123582.tif 000016
【図１５】
2017123582.tif 000017
【図１６】
2017123582.tif 000018
【図１７】
2017123582.tif 000019
【図１８】
2017123582.tif 000020
【図１９】
2017123582.tif 000021
【図２０】
2017123582.tif 000022
【図２１】
2017123582.tif 000023
【図２２】
2017123582.tif 000024
【図２３】
2017123582.tif 000025
【図２４】
2017123582.tif 000026
【手続補正書】
【提出日】平成29年3月10日(2017.3.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、当該コンテクスト情報における所定の情報を削除する削除手段と、
前記ユーザ装置が接続状態を再開する場合に、前記移動通信システムにおいて前記所定の情報を保持する通信制御装置から、当該所定の情報を取得する取得手段と、
を備えることを特徴とする基地局。
【請求項２】
前記取得手段は、前記接続状態の再開を示す信号を前記通信制御装置に送信し、前記所定の情報を含む応答信号を前記通信制御装置から受信する
ことを特徴とする請求項１に記載の基地局。
【請求項３】
前記接続状態の再開を示す信号には、前記ユーザ装置の識別子が含まれ、前記通信制御装置は、当該ユーザ装置の識別子に基づき前記所定の情報を抽出する
ことを特徴とする請求項２に記載の基地局。
【請求項４】
前記ユーザ装置が接続状態を終了する場合に、前記所定の情報を前記通信制御装置に送信する送信手段
を更に備えることを特徴とする請求項１ないし３のうちいずれか１項に記載の基地局。
【請求項５】
前記所定の情報は、前記ユーザ装置の能力情報である
ことを特徴とする請求項１ないし４のうちいずれか１項に記載の基地局。
【請求項６】
前記所定の情報が、サイズの削減された能力情報である場合に、前記削除手段は、当該能力情報の削除を行わず、前記取得手段は、当該能力情報の取得を行わない
ことを特徴とする請求項５に記載の基地局。
【請求項７】
前記サイズの削減された能力情報は、前記ユーザ装置においてデフォルトで備えられる能力についての情報を含まない
ことを特徴とする請求項６に記載の基地局。
【請求項８】
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける前記基地局が実行するコンテクスト情報保持方法であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、当該コンテクスト情報における所定の情報を削除する削除ステップと、
前記ユーザ装置が接続状態を再開する場合に、前記移動通信システムにおいて前記所定の情報を保持する通信制御装置から、当該所定の情報を取得する取得ステップと、
を備えることを特徴とするコンテクスト情報保持方法。
【請求項９】
ユーザ装置と基地局のそれぞれに保持されるコンテクスト情報を再利用して接続確立を行う機能をサポートする移動通信システムにおける通信制御装置と前記基地局とが実行するコンテクスト情報保持方法であって、
前記基地局が前記ユーザ装置に対応付けられたコンテクスト情報を保持した状態で、前記ユーザ装置が接続状態を終了する場合に、前記基地局が、前記コンテクスト情報における所定の情報を削除するステップと、
前記ユーザ装置が接続状態を再開する場合に、前記基地局が、当該接続状態の再開を示す信号を前記通信制御装置に送信するステップと、
前記通信制御装置が、前記信号を受信し、前記所定の情報を含む応答信号を前記基地局に送信するステップと
を備えることを特徴とするコンテクスト情報保持方法。
【請求項１０】
基地局とＮＢ−ＩＯＴ用のユーザ装置とを含む移動通信システムにおける前記ユーザ装置であって、
前記基地局からＵＥ能力要求を受信する受信部と、
前記ＵＥ能力要求の受信に応じて、前記ユーザ装置のＵＥ能力情報を前記基地局に送信する送信部と、を備え、
前記ＵＥ能力情報は、ＮＢ−ＩＯＴ用のＵＥカテゴリを含み、ＦＧＩのパラメータ及び測定ギャップのパラメータを含まない
ことを特徴とするユーザ装置。