(57)【特許請求の範囲】
【請求項１】
移動通信ネットワークにおいて使用される移動端末であって、
前記移動端末において、非アクセス層（ＮＡＳ）シグナリングを用いて、移動管理エンティティからデタッチ要求メッセージを受信する受信部と、
前記移動管理エンティティへデタッチアクセプトメッセージを送信することで前記デタッチ要求メッセージに対して応答する送信部と、
デタッチタイマを開始し、前記デタッチタイマが、満了時に前記移動端末が前記移動通信ネットワークからデタッチしなければならない所定の期間に対応するデタッチタイマ値に初期化される、処理部と、を具備し、
前記処理部は、前記デタッチタイマが満了した場合に、前記移動通信ネットワークにおけるユーザプレーン及び制御プレーンのコンテキスト情報を削除することにより、前記移動端末を前記移動通信ネットワークからデタッチする、
移動端末。
【請求項２】
前記受信部は、前記デタッチ要求メッセージ、又は、前記移動端末の事前設定に基づいて、前記デタッチタイマ値を決定する、
請求項１に記載の移動端末。
【請求項３】
前記処理部は、前記デタッチ要求メッセージの受信、前記デタッチアクセプトメッセージの送信、又は、前記処理部が前記移動端末のCONNECTED状態からIDLE状態への遷移をトリガすることに応じて、前記デタッチタイマを開始する、
請求項１又は２に記載の移動端末。
【請求項４】
前記移動端末がIDLE状態で接続している基地局によってアクセス規制が適用されている間に、前記移動端末が送信すべき上りリンクデータが有る場合、
前記移動端末は、CONNECTED状態へ入り、
前記送信部は、デタッチまでの期間を延長させるためのデタッチタイマ更新要求メッセージを前記移動管理エンティティへ送信する、
請求項１から３の何れかに記載の移動端末。
【請求項５】
前記受信部は、更新された期間を設定するデタッチタイマ更新応答メッセージを、前記移動管理エンティティから受信し、
前記移動端末は前記更新された期間の後に前記移動通信ネットワークから自発的にデタッチしなければならない、
請求項４に記載の移動端末。
【請求項６】
移動端末を移動通信ネットワークからデタッチする移動管理エンティティであって、
前記移動端末が接続された基地局から、前記移動端末がIDLE状態へ遷移するという指示を受信する受信部と、
前記基地局から受信された前記指示に応じて、非アクセス層（ＮＡＳ）シグナリングを用いて、デタッチ要求メッセージを前記移動端末へ送信する送信部と、
前記移動端末から、前記デタッチ要求メッセージに対するデタッチアクセプトメッセージを受信する受信部と、
デタッチタイマを開始し、前記デタッチタイマは、満了時に前記移動端末が前記移動通信ネットワークからデタッチしなければならない所定の期間に対応するデタッチタイマ値に初期化される、処理部と、を具備し、
前記処理部は、前記デタッチタイマが満了した場合に、前記移動通信ネットワークにおける前記移動端末のユーザプレーン及び制御プレーンのコンテキスト情報の削除によって、前記移動端末を前記移動通信ネットワークからデタッチする、
移動管理エンティティ。
【請求項７】
前記処理部は、前記移動端末に対する前記デタッチタイマ値を決定し、
前記送信部は、前記デタッチ要求メッセージに前記デタッチタイマ値を含める、
請求項６に記載の移動管理エンティティ。
【請求項８】
前記処理部は、前記デタッチ要求メッセージの送信、前記デタッチアクセプトメッセージの受信、又は、前記移動端末がIDLE状態へ遷移するという指示を前記受信部が受信したことに応じて、前記デタッチタイマを開始する、
請求項６又は７に記載の移動管理エンティティ。
【請求項９】
前記受信部は、デタッチまでの期間の延長を要求する前記移動端末から、デタッチタイマ更新要求メッセージを受信し、
前記送信部は、更新された期間を設定するデタッチタイマ更新応答メッセージを前記移動端末へ送信し、
前記移動端末は前記更新された期間の後に前記移動通信ネットワークから自発的にデタッチしなければならない、
請求項６から８の何れかに記載の移動管理エンティティ。
【請求項１０】
移動端末を移動通信ネットワークからデタッチする方法であって、
前記移動端末を前記移動通信ネットワークからデタッチするためのデタッチ処理を開始する工程、を具備し、
前記デタッチ処理の開始は、前記移動端末のCONNECTEDモードからIDLEモードへの遷移によってトリガされる、
方法。
【請求項１１】
前記移動端末において、非アクセス層（ＮＡＳ）シグナリングを用いた移動管理エンティティからのデタッチ要求メッセージを受信することにより、前記デタッチ処理が開始される、
請求項１０に記載の方法。
【請求項１２】
前記デタッチ処理は、移動管理エンティティにおいて、非アクセス層（NAS）シグナリングを用いた前記移動端末からのデタッチ要求メッセージを受信することにより開始される、
請求項１０に記載の方法。
【請求項１３】
前記デタッチ要求メッセージの受信を確認するためのデタッチアクセプトメッセージを送信する工程を、更に具備する、
請求項１１又は１２に記載の方法。
【請求項１４】
前記デタッチ処理の実行は、所定の期間により遅延される、
請求項１０から１３の何れかに記載の方法。
【請求項１５】
開始された前記デタッチ処理は、前記所定の期間の満了後に自発的に実行され、
前記移動端末及び移動管理エンティティは、何れのシグナリングも交換しない、
請求項１４に記載の方法。
【請求項１６】
前記移動端末においてデタッチタイマを開始し、前記デタッチタイマが前記所定の期間に対応するデタッチタイマ値に初期化される、工程と、
前記移動端末において前記デタッチタイマが満了したときに、前記移動端末を前記移動通信ネットワークから自発的にデタッチする工程と、を更に具備する、
請求項１４又は１５に記載の方法。
【請求項１７】
移動管理エンティティにおいて前記移動端末に対するデタッチタイマを開始し、前記デタッチタイマが前記所定の期間に対応するデタッチタイマ値に初期化される、工程を更に具備し、
前記移動管理エンティティは、前記移動管理エンティティにおいて前記デタッチタイマが満了したときに、前記移動端末を前記移動通信ネットワークからデタッチする、
請求項１４から１６の何れかに記載の方法。
【請求項１８】
デタッチ要求メッセージ又はデタッチアクセプトメッセージの受信、又は、前記移動端末のIDLE状態への遷移に応じて、前記デタッチタイマが開始される、
請求項１６又は１７に記載の方法。
【請求項１９】
前記デタッチタイマ値は、
−デタッチ要求メッセージにおいて非アクセス層（ＮＡＳ）プロトコルを用いてシグナリングされるか、
−前記移動端末又は前記移動管理エンティティが前記デタッチタイマ値を変更したい場合に、デタッチアクセプトメッセージにおいて非アクセス層（ＮＡＳ）プロトコルを用いてシグナリングされるか、
−基地局によって提供され、前記移動端末で受信されるシステムブロードキャスト情報内でブロードキャストされるか、
−前記移動端末をサービング（serving）する前記移動管理エンティティが利用できる前記移動端末の加入者情報内に構成されるか、又は、
−事前に設定されたデタッチタイマ値である、
請求項１６から１８の何れかに記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムから移動端末をデタッチ（detach）する方法に関する。さらに、本発明は、この方法を実行する移動端末及びＭＭＥ（Mobility Management Entity：移動管理エンティティ）に関する。本発明は、とりわけ、ＥＰＳ（Evolved Packet System）アーキテクチャに従う3GPP LTE-Aシステムに適用できる。
【背景技術】
【０００２】
［3GPP Long Term Evolution（３ＧＰＰ  ＬＴＥ）］
３ＧＰＰ（3rd generation Partnership Project）機関は、ＧＳＭ（登録商標）（Global System for Mobile communications）及びＵＭＴＳ（Universal Mobile Telecommunications System）等の移動セルラネットワークを仕様に含める。３ＧＰＰによって定義された最新のモバイルネットワークアーキテクチャは、Evolved 3GPP Packet Switched Domain（Evolved 3GPPパケット交換領域）と呼ばれ、ＥＰＳ（Evolved Packet System）としても知られる。ＥＰＳは、ＵＴＲＡＮ（Universal Terrestrial Radio Access Network）と呼ばれるＥ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）の前のもの（pre-successor）のみでなく、Ｅ−ＵＴＲＡＮと呼ばれる次世代のアクセスネットワーク技術を結合可能なＥＰＣ（Evolved Packet Core）ネットワークを組み合わせる。ＥＰＳの説明は、非特許文献１で見ることができる。図１は、ＥＰＳのエンティティ及びエンティティ間のインタフェースの概観を示す。
【０００３】
３ＧＰＰモバイルネットワークアーキテクチャでは、サービングゲートウェイ（Serving Gateway:ＳＧＷ）及びパケットデータネットワークゲートウェイ（Packet Data Network Gateway：ＰＤＮ−ＧＷ。以下ＰＧＷと呼ぶ）という、ＵＥ（User Equipment）の移動をサポートするＥＰＣ内に配置された２つのデータパケットゲートウェイを備える。ＳＧＷは、例えば、ＵＴＲＡＮ又はＥ−ＵＴＲＡＮ等の無線アクセスネットワーク向けのインタフェースを終結させる。１つの無線アクセスネットワーク（ＵＴＲＡＮ又はＥ−ＵＴＲＡＮ）内の移動については仕様書で入手できるので本書では説明しない。ＥＰＣ内の移動は、ＰＧＷによって管理される。また、非特許文献１に記載されているように、ＰＧＷとＳＧＷとの間のＥＰＣでの移動管理は、プロキシＭＩＰｖ６（Proxy Mobile IPv6：ＰＭＩＰ）プロトコル又はＧＰＲＳトンネリングプロトコル（General Packet Radio System Tunneling Protocol：ＧＴＰ）に基づくことが可能である。ＰＧＷは、ＰＭＩＰｖ６プロトコルの場合にはＬＭＡ（Local Mobility Anchor）の機能を実行し、ＧＴＰの場合にはＧＴＰトンネルの終点（endpoint）の機能を実行する。ＳＧＷとＰＧＷとの間のインタフェースは、Ｓ５と呼ばれ、ＧＴＰ又はＰＭＩＰｖ６プロトコルの何れかに基づくことが可能である。また、ＰＧＷは、適切なＱｏＳレベルでＵＥをマッピングするために、ＵＥ（ユーザ機器）に対するＩＰアドレス割当、及び、パケットフィルタリング（例えば、ディープパケットインスペクション、パケットスクリーニングなど）を実行する。
【０００４】
３ＧＰＰモバイルネットワークにおいて、移動端末（すなわち、ＵＥ）は、ＵＴＲＡＮアクセス内のＮｏｄｅＢ、又は、Ｅ−ＵＴＲＡＮアクセス内のｅＮｏｄｅＢ（evolved NodeB）を介してアクセスネットワークに接続される。ＮｏｄｅＢ／ｅＮｏｄｅＢエンティティは、他のモバイルネットワークでは基地局として知られている。本書では、ＮｏｄｅＢ及びｅＮｏｄｅＢの共通の記号として、「（ｅ）ＮｏｄｅＢ」を用いる。Ｅ−ＵＴＲＡＮアクセスを想定すると、ｅＮｏｄｅＢエンティティは、Ｓ１−Ｕインタフェース（「Ｕ」は「ユーザプレーン」を意味する）を介して有線により１つ又は複数のＳＧＷに接続され、Ｓ１−ＭＭＥインタフェースを介してＭＭＥ（Mobility Management Entity）に接続される。Ｓ１−Ｕインタフェースは、ＧＴＰプロトコルに基づく。
【０００５】
以前のバージョンの３ＧＰＰベースのセルラネットワークでは、通常、基地局（（ｅ）ＮｏｄｅＢ）は、コアネットワークと固定して接続されていた。しかしながら、将来のセルラネットワークアーキテクチャでは、通常の固定された（ｅ）ＮｏｄｅＢよりも小さいカバーエリアを有する無線（wireless）の（ｅ）ＮｏｄｅＢを備えることができると考えられる。なお、本書では、無線の（ｅ）ＮｏｄｅＢをリレーノード（Relay Node：ＲＮ）と呼ぶ。（ｅ）ＮｏｄｅＢはマクロセルと呼ぶことができ、リレーノードはマイクロセルと呼ぶことができる。これは、リレーノードは、より小さいカバレッジ（電波の届く範囲）を有するためである。異なる特徴（例えば、マクロセル、マイクロセル又はピコセル）を有する複数のセルから成るセルラネットワークは、ヘテロジニアスネットワーク（heterogeneous network）と呼ばれることもある。
【０００６】
［ＥＰＳ接続管理状態］
移動端末（３ＧＰＰ技術ではＵＥと呼ばれる）が移動通信ネットワークに接続されている場合、ＵＥは、REGISTERED（登録）状態となる。すなわち、ＵＥにおいて、ＥＭＭ（EPS Mobility Management）コンテキストが確立され、デフォルトＥＰＳベアラコンテキストがアクティブになる。ＵＥがREGISTERED状態である場合、ＵＥは、IDLE（アイドル）状態及びCONNECTED（接続）状態という、２つの異なる接続管理状態になり得る。ＵＥの電源が切られている場合又は移動通信ネットワークに接続されていない場合、ＵＥはDEREGISTERED（登録解除）状態となる。DEREGISTERED状態では、ＭＭＥにはＥＭＭコンテキストは存在せず、ＵＥの位置はＭＭＥには知られていない。よって、ＵＥはＭＭＥによってアクセスされない。
【０００７】
一般に、ＵＥが接続されている場合（REGISTERED状態）、少なくともコアネットワーク（ＭＭＥ、ＳＧＷ及びＰＧＷ。図１参照）内に格納されたＵＥコンテキストが存在する。なお、「ユーザ機器（ＵＥ）コンテキスト」は、例えば、セキュリティパラメータ、位置、セッション管理情報（ベアラコンテキスト、ＱｏＳパラメータ、ＩＰ設定など）などのＵＥに関する情報を意味し、コアネットワークエンティティに格納される。ＵＥがネットワークからデタッチ（detach）した場合（すなわち、ＵＥがDEREGISTERED状態に遷移した場合）、コアネットワークエンティティ内のこのＵＥコンテキストは削除される。
【０００８】
或る時間の上りリンク及び下りリンクにおいてデータ又はシグナリング伝送が無い場合、ＵＥはIDLE状態になる。IDLE状態では、ＵＥの無線リソースは解放され、ＵＥ及び無線アクセスネットワーク（すなわちｅＮｏｄｅＢ）における無線接続についての対応するコンテキスト情報は削除される。しかしながら、コアネットワーク内のＵＥのコンテキストは依然として維持され、ＵＥは有効なＩＰ設定を依然として有する。すなわち、ＵＥはセッション管理コンテキストを保持し、コアネットワークエンティティもＵＥのセッションコンテキストを保持する。
【０００９】
IDLE状態のＵＥは、ｅＮｏｄｅＢとの無線接続（すなわち、無線リソース接続（Radio Resource Connection）：ＲＲＣ）がなされていない。そのため、確立されたシグナリングベアラ及びデータベアラは存在しない。すなわち、無線アクセスネットワークにおいてコンテキスト情報は取得できない。また、ＵＥとネットワーク（例えばＭＭＥ）との間のＮＡＳ（非アクセス層：Non-Access Stratus）シグナリング接続は存在しない。同様に、ｅＮｏｄｅＢとＳＧＷとの間のＳ１−Ｕ接続も存在しない。
【００１０】
IDLE状態では、ネットワーク（例えばＭＭＥ）は、各ＵＥに対して、（１つ又は複数のｅＮｏｄｅＢによって制御される）１つ又は複数のセルから構成されるエリアが割り当てられる。このエリアでは、ＵＥはネットワークに対して何のシグナリングも無しで移動することができる。すなわち、ネットワークは、ＵＥがこのエリア内に位置していることのみを知っていて、正確な位置を知らない。３ＧＰＰ  ＥＰＳアーキテクチャにおいて、トラッキングエリア（ＴＡ）は、トラッキングエリアを構成する全てのセルによってブロードキャストされるトラッキングエリア識別子（ＴＡ  ＩＤ）によって識別される。１つ又は複数のセルは、同一のトラッキングエリアに設定され得る。また、１つのＵＥに対して複数のトラッキングエリアを割り当てることが可能である。トラッキングエリアＩＤのリストはＵＥ内に格納され、当該リストは、ＴＡＩリストと呼ばれる。
【００１１】
IDLE状態では、ＵＥは、無線アクセスネットワーク（Radio Access Network：ＲＡＮ）エンティティ（例えば、Ｅ−ＵＴＲＡＮ内のｅＮｏｄｅＢ、ＵＴＲＡＮ内のＮｏｄｅＢ及びＲＮＣ）におけるコンテキストを保持していない。これに対して、ＵＥがCONNECTED状態の場合、ＲＡＮエンティティはＵＥのコンテキストを保持し、ＵＥとｅＮｏｄｅＢとの間のＲＲＣ接続が確立される。例えば、新たなトラッキングエリアへの移動時におけるトラッキングエリア更新（Tracking Area Update：ＴＡＵ）処理のために、ＵＥとＭＭＥとの間にＮＡＳ信号接続を確立する必要がある場合、ＵＥ及びＭＭＥは、NAS CONNECTED状態に入る。IDLE状態からCONNECTED状態への遷移を開始する初期のＮＡＳメッセージは、例えば、接続要求（Attach Request）、トラッキングエリア更新（ＴＡＵ）要求、サービス要求（Service Request）又はデタッチ要求（Detach Request）である。初期のＮＡＳメッセージを送信するために、ＵＥは、まず、ＵｕインタフェースによってｅＮｏｄｅＢへのＲＲＣ接続を確立する必要がある。ＲＲＣ接続の確立中に、ＵＥ及びｅＮｏｄｅＢは同期を取り、ＮＡＳメッセージの伝送に使用される１つ又は複数のＳＲＢ（Signaling Radio Bearer）を確立する。
【００１２】
無線アクセスネットワーク（通常はｅＮｏｄｅＢ）がＵＥにおいてデータの送受信が行われていないことを検出した場合、無線アクセスネットワーク（通常はｅＮｏｄｅＢ）は、無線リソース及びＳ１接続を解放する。これにより、ＵＥは、CONNECTED状態からIDLE状態へ遷移する。また、ＭＭＥは、ＭＭＥのＵＥに対する内部状態をIDLE状態に変更し、ＳＧＷに対して、ｅＮｏｄｅＢとのＳ１−Ｕ接続の解放を通知する。
【００１３】
なお、上述したIDLE状態及びCONNECTED状態はＮＡＳ層における状態図に関するものであることに留意されたい。一方、ＡＳ（Access Stratus）層でも、IDLE及びCONNECTED状態が定義されている。AS IDLE/CONNECED状態は、NAS IDLE/CONNECTED状態に類似する。例えば、ＲＲＣ接続が確立されると、ＡＳ状態はCONNECTED状態となる一方、ＲＲＣ接続が解放されると、ＡＳ状態はIDLE状態となる。IDLE状態及びCONNECTED状態は、ＡＳ及びＮＡＳ層の状態図において使用される。
【００１４】
［マシンタイプ通信（Machine Type Communication：ＭＴＣ）］
３ＧＰＰは、サービス要求を有するマシンタイプ通信（ＭＴＣ）に対するネットワーク改善の活動（非特許文献２を参照）、及び、アーキテクチャソリューションの可能性に関する研究（非特許文献３を参照）が開始されている（いずれの非特許文献もhttp://www.3gpp.orgから入手可能であり、ここに援用される）。ＭＴＣ端末又はＭＴＣデバイスは、通常人間によって操作されず、通信の相手（communication peer）が他の機器（例えば、所謂、ＭＴＣサーバ又は他のＭＴＣ端末）であることに特徴がある。
【００１５】
ＭＴＣには、通常の人間間の通信（human-to-human communication）とは異なるいくつかの特性がある。３ＧＰＰでは、ネットワークオペレーションを最適化するために、これらの特性の識別を試みる。これらの特性は、「MTC features」と呼ばれ、非特許文献２に説明されている。例えば、MTC featureの１つは、ＭＴＣデバイスが不規則に（例えば、長いデータ送信間隔にて）データの送受信を行う「低頻度伝送（infrequent transmission）」である。また、データ送信完了後にＭＴＣデバイスがオフラインに戻る（DEREGISTERED状態に入る）ものとする要求（「return offline」）がある。
【００１６】
ＭＴＣデバイスに対するreturn offline要求（DEREGISTERED状態に入る要求）は、通信していなときはＭＴＣデバイスがデタッチされるべきであることを意味する。この要求の理由としては、端末の観点から、特に端末が電池式である場合に、端末がエネルギーを節約できる（例えば、周期的なＮＡＳシグナリング及びセル再選択処理を行う必要がなくなる）ことが挙げられる。また、ネットワークの観点からは、端末がデタッチした場合に、その端末が何れのシグナリングも生成されず（例えば、IDLE状態の端末は周期的にＭＭＥへ更新情報を伝送し得る）、さらに、ネットワークのリソース（例えば、ＭＭＥ、ＳＧＷ、ＰＧＷに格納されるコンテキスト）が占有されないことが挙げられる。
【先行技術文献】
【非特許文献】
【００１７】
【非特許文献１】3GPP TS 23.401: “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, version 10.2.1, January 2011 (available at http://www.3gpp.org and incorporated herein by reference)
【非特許文献２】3GPP TS 22.368, “Service requirements for Machine-Type Communications (MTC)”version 11.0.0, December 2010
【非特許文献３】3GPP TS 23.888; “System Improvements for Machine-Type Communications”; version 1.0.0, July 2010
【非特許文献４】3GPP TS 24.301; “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)”; version 10.1.0, December 2010
【非特許文献５】3GPP TR 23.898, "Access Class Barring and Overload Protection (ACBOP)", version 7.0.0, April 2005
【非特許文献６】3GPP TS 36.331, “Radio Resource Control (RRC)”, version 9.3.0, June 2010
【発明の概要】
【００１８】
本発明の１つの目的は、移動通信ネットワークから移動端末（例えば、ＭＴＣデバイス。ただし、これに限らない）をデタッチする新たな方法を提案することである。さらに、本発明の他の目的は、移動通信ネットワークからの移動端末のデタッチ処理における制御シグナリングを低減する方法を提案することである。さらなる目的は、移動端末（例えば、ＭＴＣデバイス。ただし、これに限らない）のデタッチをトリガするための適したトリガ方法を見いだすことである。
【００１９】
この目的は独立請求項の主題によって解決される。本発明の有利な実施の形態は、従属項の主題である。
【００２０】
本発明の第１の態様によれば、前記移動端末のCONNECTEDモードからIDLEモードへの遷移に応じて移動端末（例えば、ＭＴＣデバイス。ただし、これに限定されない）の移動通信ネットワークからのデタッチを開始することが提案されている。ただし、これは、移動端末のデタッチを引き起こす唯一の事象ではない。
【００２１】
特定の事象が移動端末のデタッチを開始する場合、その事象は、デタッチ処理に関する全てのノードに知られているべきであり、且つ／又は、デタッチ処理に関する１つ又は複数のノードに通知するためのシグナリングが予測されてもよい。この第１の態様の更なる１つの従属する態様は、少なくとも移動端末、及び、少なくとも移動通信ネットワークにおけるコアネットワーク内の、コアネットワーク向けの移動端末のシグナリングの終端となる制御ノード（ここでは移動管理エンティティ）が、移動端末と移動管理エンティティとの間においてデタッチ処理が調整されるように、トリガ条件を知っていることである。こうすることで、この従属する態様によれば、移動管理エンティティは、デタッチ要求メッセージを送信することにより、移動端末に対して移動通信ネットワークからデタッチすべきことを通知することができる。移動端末は、任意で、移動管理エンティティからのデタッチコマンドの確認のためのデタッチアクセプトメッセージを送信することにより、このデタッチ要求メッセージに対して応答してもよい。
【００２２】
本発明の他の態様は、移動端末からの上りリンクデータ／移動端末への下りリンクデータ又はシグナリングがまだあるかもしれないので移動端末がCONNECTED状態であるにも関わらず、直ちに移動端末をデタッチすることは合理的ではないということを検討することである。従って、例えば、遅延方法（deferred manner）により、所定の期間満了時に移動端末をデタッチすることが提案されている。遅延は、同期できるように、移動端末及び／又は制御ノード（すなわち、移動管理エンティティ）のいずれでも観測可能であり、又は、移動端末及び／又は制御ノードに通知される、特定の事象に関連する。例えば、１つの事象は、移動端末がIDLE状態へ遷移することである。この事象は、少なくとも移動端末に知らされており、制御ノードは、その点についてシグナリングメッセージによって通知を受けることができる。例えば、移動端末は、制御ノード、又は、移動端末が接続していて、事象が制御ノードへ通知されることを知っている基地局（又は３ＧＰＰ用語ではＮｏｄｅＢ、ｅＮｏｄｅＢ）に対して通知する。
【００２３】
デタッチ処理の遅延は、例えば、移動端末又は制御ノード（すなわち、移動管理エンティティ）において動作するデタッチタイマによって制御される。遅延デタッチ処理を使用する場合、移動端末及び制御ノードの双方が（ほぼ）同時に移動端末を移動通信ネットワークからデタッチするように、移動端末及び制御ノードのデタッチタイマを調整することが望ましい。このデタッチタイマのコンテキスト調整は、アクセス規制又は移動端末から送信すべき新たな上りリンクデータなどの構成がデタッチタイムの中断又はリセットをもたらす場合に好都合となる。
【００２４】
本発明の例示的な実施の形態は、移動端末を移動通信ネットワークからデタッチする方法を提供する。この方法によって、移動端末を移動通信ネットワークからデタッチするデタッチ処理が開始される。デタッチ処理の開始は、移動端末のCONNECTED状態からIDLE状態への遷移によってトリガされる。
【００２５】
デタッチ処理をどのように開始させることができるかについて異なる実現方法がある。本発明の１つの実施の形態では、移動端末において、非アクセス層シグナリングを用いた移動管理エンティティからのデタッチ要求メッセージを受信することにより、デタッチ処理が開始される。非アクセス層メッセージのシグナリングは、移動端末がCONNECTED状態であることを暗に伝える。
【００２６】
この実施の形態のより詳細な例示的な実装では、移動管理エンティティからのデタッチ要求メッセージの送信は、移動端末が接続する基地局が保持する、移動端末に対する非アクティブタイマの満了によってトリガされる。また、基地局における非アクティブタイマは、移動端末に特有である（すなわち、各移動端末の非アクティブタイマが個別に又はグループ毎に設定される）。他の例示的な実装では、非アクティブタイマの設定は、代わりとして、又は、追加的に、移動端末の設定に依存してもよい。
【００２７】
本発明の一実施の形態では、デタッチ要求メッセージは、CONNECTED状態からIDLE状態へ遷移すべき移動端末を指示するトリガに応じて送信される。例えば、このトリガは、移動端末が接続された基地局において移動端末がIDLE状態に入ると判断され、対応するシグナリング処理（移動通信ネットワークの無線アクセスネットワークにおけるコンテキスト情報に関する、移動端末の無線アクセスを開放するシグナリング処理）が開始されたときに、当該基地局から移動管理エンティティへ送信される通知である。
【００２８】
IDLE状態に入る移動端末に対してデタッチ処理を開始する他のオプションは、デタッチ処理が、移動管理エンティティにおいて、非アクセス層シグナリングを用いた移動端末からのデタッチ要求メッセージを受信することにより開始されることである。このオプションでは、移動端末は、デタッチを開始する。
【００２９】
本発明の一実施の形態では、デタッチ要求メッセージに応答して、デタッチアクセプトメッセージが送信される。デタッチアクセプトメッセージは、デタッチ要求メッセージの受信を確認するために送信される。デタッチアクセプトメッセージは、例えば、移動端末と移動管理エンティティとの同期をとるために使用される。
【００３０】
本発明の更なる実施の形態によれば、デタッチ要求メッセージのシグナリングに直ぐに反応し、それに応答するようにして移動端末のデタッチを直ちに実行するのではなく、デタッチ処理の実行は、所定の期間により遅延される。これにより、移動端末及び／又はネットワークは、移動端末のデタッチまでに、ユーザデータ又は制御データを更に送信することができる。
【００３１】
１つの例示的な実装では、開始されたデタッチ処理は、所定の期間の満了後に自発的に実行される。すなわち、デタッチが暗示的に行われる。自発的であり暗示的な移動端末のデタッチは、移動端末及び移動管理エンティティがデタッチを実行する際に何れのシグナリングも交換しないことを意味する。
【００３２】
一実施の形態によれば、移動端末の遅延デタッチは、デタッチタイマによって制御される。移動端末は、移動端末でのデタッチタイマを開始する。デタッチタイマは、所定の期間に対応するデタッチタイマ値に初期化される。移動端末は、移動端末においてデタッチタイマが満了したときに、移動端末を移動通信ネットワークから自発的にデタッチする。
【００３３】
同様に、ネットワークにおいても、移動管理エンティティが移動端末に対するデタッチタイマを開始し、デタッチタイマが所定の期間に対応するデタッチタイマ値に初期化される。移動管理エンティティは、移動管理エンティティにおいてデタッチタイマが満了したときに、移動端末を移動通信ネットワークからデタッチする。
【００３４】
１つの例示的かつより詳細な実装では、デタッチ要求メッセージ又はデタッチアクセプトメッセージの受信に応じてデタッチタイマが開始される。他の方法として、又は、追加して、移動端末のIDLE状態への遷移に応じて、デタッチタイマが開始されてもよい。
【００３５】
デタッチタイマ値の構成／設定に関していくつかのオプションがある。例えば、デタッチタイマ値は、
−デタッチ要求メッセージにおいて非アクセス層プロトコルを用いてシグナリングされるか、
−移動端末又は移動管理エンティティがデタッチタイマ値を変更したい場合に、デタッチアクセプトメッセージにおいて非アクセス層（ＮＡＳ）プロトコルを用いてシグナリングされるか、
−基地局によって提供され、移動端末で受信されるシステムブロードキャスト情報内でブロードキャストされるか、
−移動端末にサービング（serving）する移動管理エンティティが利用する移動端末の加入者情報内に構成されるか、又は、
−事前に設定されている。
【００３６】
上述したように、本発明の一実施の形態では、デタッチタイマは、特定の事象に応じて中断される。例えば、デタッチタイマは、移動端末がCONNECTED状態の間、移動端末及び移動管理エンティティの双方において中断されることができる。既に述べたように、IDLE状態に戻った場合、デタッチタイマは、再初期化されて開始されるか、単に再開される。
【００３７】
移動端末及び移動管理エンティティにおいてデタッチタイマを中断させる他の事象は、例えば、移動端末がIDLE状態で接続している基地局によってアクセス規制が適用されていることである。デタッチタイマは、例えば、アクセス規制が適用されている期間の間、中断される。
【００３８】
アクセス規制が適用されている場合、移動端末は、例えば、基地局がブロードキャストするブロードキャストシステム情報から、基地局によって適用されるアクセス規制の開始及び終了を判断する。さらに、他の例示的な実装では、基地局がアクセス規制を適用するか否かを判断する場合、基地局は、移動管理エンティティに対して、基地局の無線セルにおいて適用されているアクセス規制の開始及び終了を通知する。
【００３９】
他の方法として、移動管理エンティティは、いくつかの特定の無線アクセスエリア（すなわち、基地局によって制御されたセル）内においてアクセス規制をトリガし、１つ又は複数の基地局に対してアクセス規制期間の開始及び終了を通知するエンティティであってもよい。基地局は、同様に、自身のセル内の移動端末に対して、システムブロードキャストによってアクセス規制を通知してもよい。この場合、移動管理エンティティは、アクセス規制が規制される期間を直ちに知ることができ、その結果デタッチタイマを中断することができる。
【００４０】
本発明の他の例示的な実装の形態では、移動端末がIDLE状態で接続している基地局によってアクセス規制が適用されている間に移動端末から送信すべき上りリンクデータが有る場合、移動端末は、それでも、CONNECTED状態へ入り、デタッチまでの期間を延長させるためのデタッチタイマ更新要求メッセージを移動管理エンティティへ送信する。移動管理エンティティは、更新された期間を設定するデタッチタイマ更新応答メッセージを送信することでデタッチタイマ更新要求メッセージに対して応答する。移動端末は、この更新された期間の後に移動通信ネットワークから自発的にデタッチしなければならない。この更新された期間は、移動端末から提案された期間、又は、移動管理エンティティによって選択された期間でもよい。
【００４１】
本発明の一実施の形態では、デタッチ処理開始のトリガは、無線アクセスネットワークにおける移動端末に対するリソースをリリースするための、基地局が開始するシグナリング処理の一部である。そのようなシグナリング処理は、例えば、移動通信ネットワークにおいて、移動端末に対してCONNECTED状態からIDLE状態へ遷移させるために使用される。
【００４２】
本発明の更なる実施の形態は、移動端末のCONNECTED状態からIDLE状態への遷移の原因が移動端末の非アクティブである場合のみ、移動管理エンティティが移動端末の前記デタッチ処理を開始することを提案する。
【００４３】
さらに、移動端末の遅延デタッチに対して、移動端末が満了後にデタッチする期間（タイマ値）は、いくつかのパラメータに基づいて決定することができる。例えば、上記期間は、
−移動端末がCONNECTED状態へ入らされた前記移動端末の通信が下りリンクデータ又は上りリンクデータによってトリガされたか否か、
−前記移動端末の最後のCONNECTED状態の期間、及び／又は、前記移動端末のCONNECTED状態の平均期間、
−前記移動通信ネットワークへの現在の接続期間における前記移動端末のCONNECTED状態からIDLE状態への遷移回数、及び、
−前記移動端末のＭＴＣ機能、
のうちの少なくとも１つに基づいて、移動管理エンティティによって決定される。
【００４４】
本発明の一実施の形態は、移動通信ネットワークにおいて使用される移動端末に関する。移動端末は、非アクセス層シグナリングを用いて、移動管理エンティティからデタッチ要求メッセージを受信する受信部を備える。また、移動端末は、デタッチ要求メッセージに対して応答するために、移動管理エンティティへデタッチアクセプトメッセージを送信する送信部を、備える。また、移動端末は、デタッチタイマを開始する処理部を有する。デタッチタイマは、満了時に移動端末が移動通信ネットワークからデタッチしなければならない所定の期間に対応するデタッチタイマ値に初期化される。また、移動端末の処理部は、移動通信ネットワークにおけるユーザプレーン及び制御プレーンのコンテキスト情報を削除することにより、移動端末を移動通信ネットワークからデタッチする。
【００４５】
より詳細な例示的な実施の形態では、移動端末の受信部は、デタッチ要求メッセージ、又は、移動端末の事前設定に基づいて、デタッチタイマ値を決定する。
【００４６】
さらに、他の例示的なより詳細な実施の形態では、移動端末の処理部は、移動端末がCONNECTED状態の間、及び／又は、移動端末がIDLE状態で接続している基地局によってアクセス規制が適用されている間、デタッチタイマを中断する。
【００４７】
本発明の一実施の形態では、移動端末の処理部は、デタッチ要求メッセージの受信、デタッチアクセプトメッセージの送信、又は、処理部が移動端末のCONNECTED状態からIDLE状態への遷移をトリガすることに応じて、デタッチタイマを開始する。
【００４８】
本発明の更なる詳細な実施の形態に係る移動端末は、移動端末がIDLE状態で接続している基地局によってアクセス規制が適用されている間に、移動端末が送信すべき上りリンクデータが有る場合、CONNECTED状態へ入り、送信部は、デタッチまでの期間を延長させるためのデタッチタイマ更新要求メッセージを移動管理エンティティへ送信する。移動端末の受信部は、更新された期間を設定するデタッチタイマ更新応答メッセージを、移動管理エンティティから受信する。移動端末は、この更新された期間の後に移動通信ネットワークから自発的にデタッチしなければならない。
【００４９】
本発明の更なる実施の形態は、移動端末を移動通信ネットワークからデタッチする移動管理エンティティを提供することである。移動管理エンティティは、移動端末が接続された基地局から、移動端末がIDLE状態へ遷移するという指示を受信する受信部と、基地局から受信された前記指示に応じて、非アクセス層シグナリングを用いて、デタッチ要求メッセージを移動端末へ送信する送信部と、を具備する。移動管理エンティティの受信部は、移動端末から、デタッチ要求メッセージに対するデタッチアクセプトメッセージを受信する。移動端末の処理部はデタッチタイマを開始し、デタッチタイマは、満了時に移動端末が移動通信ネットワークからデタッチしなければならない所定の期間に対応するデタッチタイマ値に初期化される。
【００５０】
さらに、移動管理エンティティの処理部は、移動通信ネットワークにおける移動端末のユーザプレーン及び制御プレーンのコンテキスト情報の削除によって、移動端末を前記移動通信ネットワークからデタッチする。これは、移動端末のユーザプレーン及び制御プレーンに関するコンテキスト情報を削除するために、移動管理エンティティ及び／又は通知される他のコアネットワークエンティティのストレージ内の移動端末のユーザプレーン及び制御プレーンのコンテキスト情報を削除する処理部を含む。
【００５１】
移動管理エンティティの処理部は、さらに、移動端末に対するデタッチタイマ値を決定し、送信部は、デタッチ要求メッセージにデタッチタイマ値を含めることができる。さらに、例えば、処理部は、移動端末がCONNECTED状態の間、及び／又は、移動端末がIDLE状態で接続している基地局によってアクセス規制が適用されている間、デタッチタイマを中断する。
【００５２】
本発明の一実施の形態では、移動管理エンティティの受信部は、基地局から、基地局の無線セルにおいて適用されているアクセス規制の開始及び終了の指示を受信する。
【００５３】
移動管理エンティティの処理部は、任意で、デタッチ要求メッセージの送信、デタッチアクセプトメッセージの受信、又は、移動端末がIDLE状態へ遷移するという指示を受信部が受信したことに応じて、デタッチタイマを開始することができる。
【００５４】
本発明の一実施の形態では、移動管理エンティティの受信部は、デタッチまでの期間の延長を要求する移動端末から、デタッチタイマ更新要求メッセージを受信し、送信部は、更新された期間を設定するデタッチタイマ更新応答メッセージを移動端末へ送信する。移動端末は、この更新された期間の後に移動通信ネットワークから自発的にデタッチしなければならない。
【００５５】
一実施の形態では、移動端末及び／又は移動管理エンティティは、本明細書に記載された様々な実施の形態のうちの１つに応じた、移動端末を移動通信ネットワークからデタッチする方法を実行するように構成することができる。
【００５６】
さらに、本発明の実施の形態は、本発明の様々な態様をソフトウェアに実施することに関する。従って、本発明の一実施の形態は、命令を格納しているコンピュータ可読媒体であって、移動端末のプロセッサによって命令が実行されたとき、それによって、移動端末が、非アクセス層シグナリングを用いて、移動管理エンティティからデタッチ要求メッセージを受信し、デタッチ要求メッセージに対するデタッチアクセプトメッセージを、移動管理エンティティへ送信する。移動端末は、さらに、命令の実行によって、デタッチタイマを、満了時に移動端末が移動通信ネットワークからデタッチしなければならない所定の期間に対応するデタッチタイマ値に初期化し、デタッチタイマを開始する。さらに、命令の実行に起因して、移動端末は、前記移動通信ネットワークにおけるユーザプレーン及び制御プレーンのコンテキスト情報を削除することにより、移動端末を移動通信ネットワークからデタッチする。
【００５７】
本発明の一実施の形態は、命令を格納しているコンピュータ可読媒体に関し、移動管理エンティティのプロセッサによって実行されたとき、それに起因して、移動管理エンティティが、移動端末が接続された基地局から、移動端末がIDLE状態へ遷移するという指示を受信し、基地局から受信された指示に応じて、非アクセス層シグナリングを用いて、デタッチ要求メッセージを移動端末へ送信し、移動端末から、デタッチ要求メッセージに対するデタッチアクセプトメッセージを受信し、デタッチタイマを、満了時に移動端末が移動通信ネットワークからデタッチしなければならない所定の期間に対応するデタッチタイマ値に初期化し、デタッチタイマを開始し、移動通信ネットワークにおける移動端末のユーザプレーン及び制御プレーンのコンテキスト情報の削除により移動端末をデタッチすることによって、移動端末を移動通信ネットワークからデタッチする。
【００５８】
本発明の更なる実施の形態は、命令を格納するコンピュータ可読媒体に関し、移動端末又は移動管理エンティティによって命令が実行されたとき、それに起因して、移動端末又は移動管理エンティティが、本明細書に記載された様々な実施の形態のうちの１つに応じて移動端末を移動通信ネットワークからデタッチする方法を実行する。
【００５９】
以下では、本発明について、添付の図面を参照しながらさらに詳しく説明する。図面において類似または対応する細部には、同じ参照数字を付してある。
【図面の簡単な説明】
【００６０】
【図１】３ＧＰＰ  ＬＴＥシステムの例示的なアーキテクチャを示す図
【図２】本発明の実施の形態に係る、延期されたデタッチ処理をトリガし、当該デタッチ処理を実行する移動通信ネットワークに基づくＥＰＣ／Ｅ−ＵＴＲＡＮにおけるメッセージ交換の一例を示す図
【図３】本発明の例示的な実施の形態に係る、ユーザ機器のセルにおけるアクセス規制の説明、及び、デタッチタイマを同期させるための、ユーザ機器（ＵＥ）と移動管理エンティティ（ＭＭＥ）との間のメッセージ交換の一例を示す図
【図４】本発明の更なる例示的な実施の形態に係る、ユーザ機器のセルにおけるアクセス規制の説明、及び、デタッチタイマを同期させるための、ユーザ機器（ＵＥ）と移動管理エンティティ（ＭＭＥ）との間の他のメッセージ交換の一例を示す図
【発明を実施するための形態】
【００６１】
以下では、本発明の様々な実施形態について説明する。実施形態のほとんどは、上の背景技術のセクションで説明した３ＧＰＰ  ＬＴＥ（Release 8）及び３ＧＰＰ  ＬＴＥ−Ａ（Release 10）の移動通信システムによる、直交シングルキャリア上りリンク無線アクセス方式に関連して説明してあるが、これは例示を目的としているにすぎない。本発明は、例えば、前述した３ＧＰＰ  ＬＴＥ（Release 8）及び３ＧＰＰ  ＬＴＥ−Ａ（Release 10）通信システムなどの移動通信システムと組み合わせて有利に使用できるが、本発明は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。
【００６２】
背景技術のセクションにおける説明は、本明細書に記載した主として３ＧＰＰ  ＬＴＥ（Release 8）及び３ＧＰＰ  ＬＴＥ−Ａ（Release 10）に関連する例示的な実施形態を深く理解することを目的としており、移動通信ネットワークにおけるプロセスおよび機能の、説明した特定の実施形態に本発明を制限するものではないことを理解されたい。
【００６３】
背景技術のセクションに示したように、ＭＴＣデバイスは、通信していない場合に移動通信ネットワークからデタッチすることを要求される。通信完了後にＭＴＣデバイスをデタッチさせることができるいくつかの解決方法がある。例えば、ＭＴＣデバイス内又はＭＴＣサーバ内のＭＴＣアプリケーションは、ＭＴＣデバイス又はＭＴＣサーバにおける通信ユニットに対して通信終了をそれぞれ通知するための明示的なＡＰＩ（Application Programming Interface）を保持することができる。このようなＡＰＩがＭＴＣデバイス内で利用可能な場合、ＭＴＣデバイスは、DEREGISTERED状態へ遷移するためのデタッチ処理を開始することができる。他の可能性として、ＭＭＥが通信終了について知っているケースでは、ＭＭＥが明示的なデタッチ処理を開始することができる。例えば、ＭＭＥは、デタッチ要求メッセージをＭＴＣデバイス及びＭＴＣサーバに送信し、デタッチアクセプト（detach accept）に応答する。例えば、ＭＭＥは、通信終了を、ＭＴＣサーバがＭＭＥへ明示的に通知することにより、知ることができる。
【００６４】
双方のオプションでは、ＭＴＣデバイス／ＭＴＣサーバのＭＴＣアプリケーション層より下のプロトコル層へ通信終了を通知することを許可するＡＰＩが必要となる。ＭＴＣデバイス／ＭＴＣサーバにおいて起動しているＭＴＣアプリケーション層内のＭＴＣアプリケーションが通信終了を下位層へ通知する機能を実装していない場合、通信が完了した際にＭＴＣデバイスが移動通信システムからデタッチできるようにする他の解決方法が必要となる。
【００６５】
さらに、たとえＭＭＥが何とかして通信終了を通知でき、デタッチ処理を開始したい場合でも、ＭＴＣデバイスがIDLE状態の場合、ＭＭＥは、まず、ＭＴＣデバイスがＭＭＥとのＮＡＳ接続を確立しなければならないようにするために、ページング処理を実行しなければならない。その後、ＭＭＥは、デタッチ要求メッセージを送信することができる。このような方法はシグナリング増加をもたらしてしまう。ＭＴＣデバイスに対して、ページング及びＮＡＣ接続の確立によるさらなるシグナリングのオーバヘッド無しで、通信終了後にネットワークからデタッチする「return offline」機能を実装することが望ましい。
【００６６】
本発明の以下の異なる実施の形態は、例えば、「return offline」機能を実装することにより、通信が終了した時点で移動通信ネットワークからＭＴＣデバイスがデタッチすることができる新たなデタッチ方法に関する。ただし、ここで記載する様々な実施の形態に係るデタッチ方法は、ＭＴＣデバイスのデタッチ処理に使用されることに限定されるものではない。このデタッチ方法は、通常の移動端末が通信終了した時点で移動通信ネットワークからデタッチするために用いることができる。
【００６７】
移動通信ネットワークからの移動端末のデタッチについて、１つの課題は、どの事象を移動通信ネットワークから移動端末をデタッチさせる動機とすべきかである。通信終了した時点での移動端末のデタッチのトリガとなる適切な事象が決定されるので、この課題は「return offline」機能の実装に関連する。本発明の第１の態様によれば、移動端末がCONNECTED状態からIDLE状態へ遷移するのに応じて、移動通信ネットワークからの移動端末（例えば、ＭＴＣデバイス。ただし、これに限定されない）のデタッチが開始される。ただし、これは、移動端末のデタッチを引き起こす唯一の事象ではない。
【００６８】
或る事象が移動端末のデタッチを開始させる場合、その事象がデタッチ処理に関わる全てのノードに知らされること、及び／又は、デタッチ処理に関わる１つ又は複数のノードに通知するためにその事象がシグナリングされることが予測される。移動端末のDEREGISTERED状態へ異常無く遷移する場合（例えば、移動通信ネットワークから移動端末がデタッチする場合）に普遍性を失うことなく、移動端末が移動通信ネットワークに登録される（REGISTERED状態）ことが想定される。また、ネットワークの少なくとも２つのノードがデタッチ処理に関わることが想定される。当該２つのノードとは、ネットワークからデタッチ（すなわち、DEREGISTERED状態に遷移）すべき移動端末、及び、移動通信ネットワークのコアネットワーク内における、コアネットワーク向けの移動端末のシグナリング（制御プレーン）の終端である制御ノードである。この制御ノードは、ここでは移動管理エンティティとも呼ばれ、本発明の１つの実施の形態では、３ＧＰＰシステムのコアネットワークにおいて知られている同名のエンティティ（ＭＭＥ）である。
【００６９】
これにより、本発明の第１の態様の１つの従属する態様は、移動端末及び移動管理エンティティにおいてデタッチ処理が調整されるように、少なくとも移動端末及び制御ノードがトリガ条件を知っていることができるようにすることである。よって、この従属する態様によれば、移動管理エンティティは、デタッチ要求メッセージを送信することにより、移動端末に対して、移動通信ネットワークからデタッチすべきであることを通知することができる。また、移動端末は、移動管理エンティティからのデタッチコマンドを確認するためにデタッチアクセプトメッセージを送信することにより、任意に、このデタッチ要求メッセージに対して応答できる。これは、移動端末と移動管理エンティティとの間で明示的なシグナリングが交換される明示的なデタッチと呼ばれることもある。
【００７０】
他のオプションは、デタッチ開始のための明示的なＮＡＳシグナリングが不要である、移動端末と移動管理エンティティとの間のデタッチ処理の暗示的な調整を実装することである。このオプションは、今日では、接続の切断などの異常なケースにおける移動端末のデタッチにおいて用いられる。ここでは、暗示的なデタッチは、移動端末及び移動管理エンティティの双方が移動端末のデタッチのトリガとなる事象を知っている状況のような、通常のデタッチにおいて用いられる。暗示的なデタッチは、移動端末及び移動管理エンティティが暗示的なデタッチのために同期しているケースにおいて用いることができる。
【００７１】
上記双方のオプションにおいて、デタッチ処理に関わるさらなるネットワークノードが存在する場合、そのノードは、移動管理エンティティによって移動端末のデタッチについて通知されるか、又は、デタッチのトリガとなる事象を知っている。
【００７２】
さらに、例示的な目的のために、移動端末のデタッチの動機となる事象が、移動端末がIDLE状態となる時点（すなわち、移動端末が無線アクセスネットワークに知られなくなる時点）でトリガされることを考慮すると、制御プレーン（例えば、移動管理を含む）のＮＡＳプロトコルの終端を担うコアネットワーク内のサービング制御ノードは、セルレベルのアタッチポイントを知らない。例えば、このノードは、移動端末が位置する、複数のセルで構成するトラッキングエリアのみを知っている。したがって、最終的に移動端末をデタッチするために、好ましくないシグナリングオーバヘッドが考慮された移動端末のデタッチのためのＮＡＳ処理をトリガするために、無線アクセスネットワークを介して接続が再確立されなければならない。
【００７３】
さらなる関連した検討は、移動端末からの上りリンクデータ／移動端末への下りリンクデータ又はシグナリングがまだあるかもしれないので、移動端末がCONNECTED状態であるにも関わらず、直ちに移動端末をデタッチすることは合理的ではないということである。これは、移動端末及び移動管理エンティティが遅延デタッチ処理を実行するために同期することを生じさせる遅延方法（deferred manner）により移動端末をデタッチするのに好都合である。同期には２つの目的がある。１つは、遅延デタッチ処理を開始する共通の時点を移動端末及びネットワークに知らせることである。もう１つは、デタッチ処理の遅延に用いる共通の期間を移動端末及びネットワークにおいて用いることである。
【００７４】
これらの検討に従って、本発明の他の態様は、移動通信ネットワークにおける移動端末のデタッチするためのシグナリングオーバヘッドを低減することである。デタッチ処理の開始は、移動端末がCONNECTED状態（すなわち、無線アクセスネットワーク接続の再確立が不要な場合）に実行され得る。この態様によれば、デタッチ処理は遅延され、つまり、デタッチは、デタッチ要求メッセージ及び任意の応答（デタッチアクセプトメッセージ）の送信など、関連する制御シグナリングよりも遅い時点で実施される。換言すると、移動端末のデタッチは、特定の期間満了後に生じる。上述したように、遅延も、移動端末／制御ノード（移動管理エンティティ）によって観察可能な、又は、同期できるように移動端末／制御ノードに通知される、或る事象に関連している。例えば、１つの事象は、移動ノードがIDLE状態になることである。この事象は、少なくとも移動端末に知られることができ、制御ノードはシグナリングメッセージにより通知されることができる。例えば、移動端末は、移動端末が接続され、かつ事象が制御ノードに通知されることを知っている制御ノード又は基地局（３ＧＰＰ用語ではＮｏｄｅＢ又はｅＮｏｄｅＢ）に通知することができる。
【００７５】
デタッチ処理の遅延は、例えば、移動端末及び制御ノード（移動管理エンティティ）内で動作するデタッチタイマによって制御される。遅延デタッチ処理を用いる場合、双方が移動通信ネットワークから移動端末をほぼ同一時点でデタッチするように、移動端末及び制御ノードのデタッチタイマを調整することが望ましい。このようなデタッチ時間の調整は、アクセス規制又は移動端末から送信すべき新たな上りリンクデータなどの構成がデタッチタイマの中断又はリセットをもたらす場合に好都合となる。
【００７６】
また、デタッチタイマ値は、移動端末と制御ノードとの間で調整される必要がある。これは、例えば、移動端末における事前設定によって、又は、移動端末の加入者情報（subscription information）に使用されるタイマ値を含めることにより実現される。他のオプションとして、制御ノードから移動端末へ（又はその逆）デタッチタイマ値をシグナリングすることがある。デタッチタイマ値は、例えば、デタッチ要求メッセージ、デタッチアクセプトメッセージ、又は、移動通信ネットワークへの移動端末のアタッチ開始時に送信されるアタッチ要求メッセージに含めることができる。
【００７７】
さらに、遅延デタッチ処理は、実際のデタッチ時における追加の（ＮＡＳ）制御シグナリングを防ぐことができる。例えば、例示的な目的のために、デタッチタイマが満了した時点で移動端末がIDLE状態になると想定すると、移動端末及び制御ノードにおけるデタッチタイマによるデタッチ処理の調整では、移動端末と制御ノードとの間で交換すべき、移動端末の端末に関連するさらなるシグナリングを不要とすることができる。これにより、移動端末がデタッチのためにCONNECTED状態に遷移することが不要となる。一方、デタッチタイマ満了時には、移動端末は、移動通信ネットワーク内のユーザプレーン及び制御プレーンに関連するコンテキストを自動的に削除するので、これにより、移動端末は移動通信ネットワークからデタッチする。
【００７８】
同様に、制御ノード（例えば、移動管理エンティティ）も移動通信ネットワーク内のユーザプレーン及び制御プレーンに関する移動端末のコンテキスト情報を削除する。コアネットワークノードが移動端末をデタッチするために当該移動端末のユーザプレーン及び制御プレーンに関するコンテキスト情報を削除できるように、この移動端末のコンテキスト情報の削除は、デタッチされる移動端末のユーザプレーン及び制御プレーンに関するコンテキスト情報を保持する１つ又は複数のコアネットワークノード（例えば、３ＧＰＰシステムのＰＤＮ−ＧＷ）に対して制御ノードから通知される。
【００７９】
前述したように、移動通信ネットワークからの移動端末のデタッチは、移動端末及び移動通信ネットワーク内に保持されている、移動端末のユーザプレーン及び制御プレーンに関するコンテキスト情報を削除することと等価である。１つの例示的な実装では、移動端末のIDLE状態は、コンテキスト情報に関する無線アクセスを暗に示す。すなわち、移動端末のユーザプレーン及び制御プレーンのコンテキスト情報が移動端末及びコアネットワーク、移動通信ネットワーク内に保持されるのに対して、無線アクセスネットワーク接続に関する移動端末のコンテキスト情報は、無線アクセスネットワークノード及び移動端末において削除される。移動端末のデタッチは、移動端末及びコアネットワークが保持している、移動端末のこのユーザプレーン及び制御プレーンのコンテキスト情報を削除することができるようにする。
【００８０】
もう１つの詳細な例示的な実施の形態では、本発明は、３ＧＰＰ  ＥＰＳネットワークのアーキテクチャを有する移動通信ネットワークに実装される。コアネットワークは、３ＧＰＰ  ＧＰＲＳ、ＵＴＲＡＮ又はＥ−ＵＴＲＡＮアーキテクチャによる無線アクセスネットワーク技術で接続可能なＥＰＣネットワークとして実装される。したがって、この実施の形態では、IDLE状態及びDEREGISTERED状態（ネットワークからの移動端末のデタッチにより入る状態）の定義は、本書の技術背景のセクションと同様に定義される。
【００８１】
さらに、他の例示的な実施の形態において、移動通信ネットワークからデタッチする移動端末は、本書の技術背景のセクションで説明したマシンタイプ通信デバイス（MTCデバイス）である。
【００８２】
上述したように、IDLEモードへの遷移処理（すなわち、移動端末がIDLEモードへ遷移するようにトリガされた処理）は、遅延デタッチ処理を行うトリガ事象として用いられる。遅延デタッチ処理は、移動通信システム（例えば、移動端末に対して動作する移動管理エンティティ）によって開始され得る。移動管理エンティティは、移動端末へ送信されるデタッチ要求メッセージを用いて新たな「デタッチタイマ」パラメータを通知することができる。「デタッチタイマ」は、経過後に、移動管理エンティティ及び移動端末が暗示的にデタッチ処理を行わなければならない時間を表す。暗示的なデタッチ処理とは、すなわち、コアネットワークノード及び移動端末におけるユーザプレーン及び制御プレーンの移動端末のコンテキスト情報を、移動管理エンティティと移動端末との間での追加的なＮＡＳシグナリング無しで、自動的に削除することである。
【００８３】
デタッチタイマが動作している間、移動端末及び移動通信ネットワークは、通常どおり動作する。すなわち、上りリンク又は下りリンクのデータが待機している場合には、移動端末又はネットワークの各々は、データベアラの確立及びデータ送信を開始する。
【００８４】
１つの例示的な実装では、移動端末は、デタッチタイマ動作に対して影響を与えずに、IDLE状態からCONNECTED状態へ遷移する（又はその逆の遷移）。他の例示的な実装では、デタッチタイマは、移動端末がIDLE状態である間のみ動作する。すなわち、デタッチタイマは、移動端末がCONNECTED状態に移った時点で中断され、移動端末が（再び）IDLE状態へ移った際に再開される。さらにもう１つの例示的な実装では、デタッチタイマは、移動端末（及び対応する移動管理エンティティ）がCONNECTED状態に移った場合に、終了（クリア）させられる。さらに、後述するように、デタッチタイマは、例えば、セル内の無線アクセスが規制した場合、又は、デタッチタイマ動作中にコアネットワークが輻輳した場合などのいくつかのさらなる条件を考慮して制御されることが可能である。
【００８５】
以下の本発明の例示的な実施の形態は、ＥＰＣ／Ｅ−ＵＴＲＡＮシステムを想定した場合について詳細に説明している。ただし、本発明の着想及び原理は、無線アクセスについて、ＵＴＲＡＮ／ＵＭＴＳシステムにも適用することができる。メッセージ構造が異なるものの、ＵＴＲＡＮ／ＵＭＴＳアーキテクチャのプロトコル処理は同一である。以下では、ＵＥ（すなわち、移動端末の３ＧＰＰ用語）と呼ぶものの、本発明の異なる実施の形態では、技術背景のセクションのようにＭＴＣデバイスに適応されることも好都合である。同様に、「return offline」という機能又は表現は、データ通信が完了した際にユーザ機器が移動通信システムからデタッチすることを意味する。
【００８６】
以下に記載の本発明の異なる実施の形態は、さらに、例えば、ＭＴＣデバイスに対する上述した「return offline」機能の実装に使用可能な遅延デタッチ処理に注目している。
【００８７】
移動通信システム内に「return offline」機能をサポートする／サポートしない移動デバイスが存在することがあるので、移動管理エンティティは、各移動デバイスに対して遅延デタッチ処理をサポートするのか否かを判断する。例えば、図１に例示した移動通信ネットワークでは、ユーザ機器の「return offline」設定は、ＨＬＲ／ＨＳＳが保持する加入者データベース（subscription database）に格納される。ユーザ機器のアタッチ処理中に、移動管理エンティティは、加入者データベースから、移動端末の設定された機能を取得する。
【００８８】
他の可能性として、「return offline」機能（すなわち、遅延デタッチ）がユーザ機器にサポートされ、ユーザ機器が、移動管理エンティティとのアタッチ処理中に、移動管理エンティティに対して設定（機能）を通知することがある。例えば、アタッチ処理中のユーザ機器と移動管理エンティティとの間のいわゆる「機能交換（capabilities exchange）」は、移動管理エンティティに対する、「return offline」機能のサポートを含む、ユーザ機器においてサポートされる機能の通知に用いられる。
【００８９】
同様に、移動管理エンティティは、ネットワーク、移動管理エンティティのそれぞれが「return offline」機能をサポートするのか否かをユーザ機器に対して通知するために、ユーザ機器とのアタッチ処理を用いることができる。ネットワークの能力をユーザ機器に通知する他の可能性として、移動管理エンティティとユーザ機器との間の拡張（extended）ＴＡＵ処理がある。拡張ＴＡＵ処理では、移動管理エンティティが遅延デタッチ処理をサポートするか否かを示すために、ＴＡＵ処理のメッセージの１つが変更されている。
【００９０】
移動管理エンティティによりユーザ機器が遅延デタッチをサポートするか否かを把握すると、移動管理エンティティは、遅延デタッチ処理の使用を決定し、実装に応じて、デタッチ要求メッセージにおいて、遅延デタッチのための「デタッチタイマ」をユーザ機器に送信する。
【００９１】
その他に、遅延デタッチ処理は、例えば、デタッチが遅延されることを示す「デタッチタイマ」を含むデタッチ要求をユーザ機器が送信することにより、ユーザ機器によって開始されることもできる。デタッチまでの所望期間を示すデタッチ要求メッセージを送信することにより、ユーザ機器がネットワークからの遅延デタッチを開始する場合、ユーザ機器からの通信セッションの予測期間に対する情報は、デタッチタイマの設定に考慮される。
【００９２】
例えば、ユーザ機器は、さらなるデータが或る期間内に到着するが、この期間経過後にはデータが到着しないことを知ることができる。この場合、ユーザ機器は、未だCONNECTED状態である間、遅延デタッチ要求メッセージを送信することができる。そして、ネットワークは、ユーザ機器がIDLE状態に入ることをトリガすることができ、移動通信ネットワーク及びユーザ機器は、暗示的に、すなわち、ユーザ機器のデタッチを明示的にトリガするために再びCONNECTED状態に移行せずに、ユーザ機器をデタッチすることができる。
【００９３】
デタッチ要求メッセージに対して、ユーザ機器又は移動管理エンティティ（どのエンティティがデタッチ処理を開始するかによる）は、任意に、デタッチアクセプトメッセージを送信する。デタッチアクセプトメッセージが送信されるか否かは、例えば、デタッチの理由に依る。例えば、１つの実装では、非特許文献４の第９．９．３．７節に記載されたケース（detach type）において、デタッチアクセプトメッセージは送信される（非特許文献４はhttp://www.3gpp.orgから入手可能であり、ここに援用される）。
【００９４】
本発明の１つの例示的な実施の形態では、ユーザ機器は、デタッチタイマの受け入れに同意（acknowledge）するために、その移動管理エンティティから受け取ったデタッチ要求メッセージ（デタッチタイマを含む）に対するデタッチアクセプトメッセージを送信する。移動管理エンティティがユーザ機器からのデタッチアクセプトメッセージを受信しない場合、及び、更に発展した例示的な実装では、移動管理エンティティは、デタッチ要求メッセージを１回又は数回再送する。ユーザ機器からの応答が受信されない場合、移動管理エンティティは、ユーザ機器が不通であり、ユーザ機器が局所的な遅延無しで（すなわち、デタッチタイマの適用無しで）デタッチしていると想定する。なお、「暗示的なデタッチタイマ」は、移動管理エンティティにおいて特定されることに留意されたい。非特許文献４によれば、この暗示的なデタッチタイマは、ユーザ機器の状態がCONNECTED状態からIDLE状態へ変更したときに移動管理エンティティにおいて開始される。暗示的なデタッチタイマのタイマ値は、ユーザ機器からの周期的なトラッキングエリア更新のための移動管理エンティティ内のタイマよりも長い期間（数分）とすることができる。１つの例示的な実装では、「暗示的なデタッチタイマ」は、ユーザ機器からのデタッチアクセプトメッセージが受信された後に、移動管理エンティティにおいて、デタッチ要求メッセージに含まれるデタッチタイマ値に設定される。
【００９５】
図２は、本発明の例示的な実施の形態に係る、遅延デタッチ処理を実装するためのユーザ機器（ＵＥ）と移動通信システムとの間のシグナリングメッセージ交換の一例を示す。ユーザ機器（ＵＥ）は、最初はCONNECTED状態である。例えば、１つ又は複数のシグナリング無線ベアラ（Signaling Radio Bearer：ＳＲＢ）及びデータ無線ベアラ（Data Radio Bearer：ＤＲＢ）を含むＲＲＣ接続がｅＮｏｄｅＢを終端とする無線アクセスネットワークに向けて確立される。ユーザプレーンにおいて、無線アクセスネットワーク（ｅＮｏｄｅＢ）とコアネットワーク（サービングゲートウェイ：Ｓ−ＧＷ）との間でＳ１−Ｕベアラが確立される。また、コアネットワークにおいて、サービングゲートウェイ（Ｓ−ＧＷ）とＰＤＮゲートウェイ（Ｐ−ＧＷ）との間でＳ５ベアラが確立される。ユーザプレーンにおいて、ＤＲＢ及びＳ１−Ｕベアラのマッピングは、通常、１対１である。移動管理エンティティ（ＭＭＥ）及びサービングゲートウェイ（Ｓ−ＧＷ）は、制御プレーン及びユーザプレーンのそれぞれに対する無線アクセスネットワークとコアネットワークとの間の「ゲートウェイ」を構成すると考えることができる。
【００９６】
ｅＮｏｄｅＢは、移動管理エンティティ（ＭＭＥ）によるＮＡＳ遅延デタッチ処理をトリガするものであるＡＳ  IDLE状態トリガ処理を開始する（ステップ２０１）。IDLE状態トリガ処理は、非特許文献１の５．３．５節において「S1リリース」処理として実装されている。
【００９７】
ｅＮｏｄｅＢは、ステップ２０１において、ＵＥをIDLE状態へ遷移させるために、Ｓ１−ＡＰプロトコルのＳ１  ＵＥコンテキストリリース要求を、移動管理エンティティ（ＭＭＥ）へ通知するために送信する（この時点ではＵＥは未だCONNECTED状態である）。ｅＮｏｄｅＢによって開始されるIDLE状態トリガ処理には、異なる理由もある。例えば、無線リンクには、無線接続の失敗、IDLE状態トリガ処理をトリガするＲＲＣメッセージの整合性チェックエラーなどの問題があり得る。又は、IDLE状態トリガ処理は、ユーザが動作していないこと、すなわち、或る期間において何れのＵＥのベアラ上りリンク／下りリンクデータも存在しないことに起因しているかもしれない。
【００９８】
図２に示す例示的な実施の形態では、ｅＮｏｄｅＢによるこのメッセージは、ＮＡＳにおいて、移動管理エンティティ（ＭＭＥ）がユーザ機器（ＵＥ）の遅延デタッチ処理を開始（太線矢印を参照）するトリガとなる。上述したように、ｅＮｏｄｅＢは、Ｓ１−ＡＰメッセージ「Ｓ１  ＵＥコンテキストリリース要求」を送信することにより、移動管理エンティティ（ＭＭＥ）へＳ１−Ｕベアラのリリースを通知することにより、IDLE状態トリガ処理を開始する。このＳ１−ＡＰメッセージ「Ｓ１  ＵＥコンテキストリリース要求」は、リリースの要因を示す。当該Ｓ１リリース要因は、移動管理エンティティ（ＭＭＥ）に対して、IDLE状態トリガ処理の理由について通知する。本発明の１つの例示的な実施の形態では、移動管理エンティティ（ＭＭＥ）は、ユーザが動作していないこと（非アクティブ）がリリース要因である場合、以下の遅延デタッチ処理のみを開始する。ユーザが動作していないことと異なるリリース要因である場合、移動管理エンティティ（ＭＭＥ）は、遅延デタッチ処理を行わずに、Ｓ１リリース処理を継続する（ステップ２０４−２０８）。
【００９９】
一般に、３ＧＰＰ規格において、非アクティブタイマ（inactivity timer）は、各ｅＮｏｄｅＢに接続された全てのユーザ機器において同一である。本発明の１つの実施の形態において、ｅＮｏｄｅＢは、ユーザ機器の異なるタイプに対して異なる値の非アクティブタイマを有すること、又は、各ユーザ機器に対して異なる非アクティブタイマを起動させることが想定される。例えば、非アクティブタイマ値は、移動管理エンティティ（ＭＭＥ）からｅＮｏｄｅＢへ通知される各ＵＥのコンテキスト内に格納され、非アクティブタイマ値は、或るユーザ機器のＲＲＣ接続の存続期間中、ｅＮｏｄｅＢにおいて保存される。
【０１００】
１つの実装例では、「return offline」機能を設定された（すなわち、遅延デタッチ処理をサポートする）ユーザ機器は、この機能をサポートしていないユーザ機器とは異なる非アクティブタイマ値を有する。また、ユーザ機器又はユーザ機器グループに設定された非アクティブタイマ値はＭＴＣアプリケーションに依存する。例えば、非アクティブタイマ値は、加入者データベース内に格納される。又は、非アクティブタイマ値は、移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢによって、ｅＮｏｄｅＢの負荷に応じて導出されることも可能である。後者の場合、移動管理エンティティ（ＭＭＥ）は、ｅＮｏｄｅＢに対して、ユーザ機器タイプを通知すればよく、ｅＮｏｄｅＢは、非アクティブタイマに対するユーザ機器タイプの特定の値を導出することができる。「ユーザ機器タイプ」は、ユーザ機器が加入している特有の特徴を有する通信／アプリケーションのタイプを表すことを意図している。例えば、１つの「ユーザ機器タイプ」は、人間によって操作されるユーザ機器と比較して、異なる特徴を有するＭＴＣデバイスとすることができ、非アクティブタイマ値は異なる。他の例では、リアルタイム又はストリーミングサービスに加入している又は用いているユーザ機器は、データオンリーサービスに加入している又は用いているユーザ機器と比較して、異なる非アクティブタイマ値を有する。また、異なるＭＴＣ機能を有するＭＴＣデバイスは、ユーザ機器のタイプが異なると見なすことができる。
【０１０１】
ＭＭＥが、ユーザ機器が動作していないリリース要因、及び、ＵＥに対して「return offline」機能が構成／設定されたことを含むＳ１  ＵＥコンテキストリリース要求を受け取った後、ＭＭＥは、遅延デタッチ処理の実行を決定する。移動管理エンティティ（ＭＭＥ）は、ステップ２０２において、デタッチ要求メッセージをユーザ機器に送信する。デタッチ要求メッセージは、ＮＡＳプロトコルを用いて送信される。デタッチ要求メッセージは、満了時にユーザ機器（ＵＥ）及び移動管理エンティティ（ＭＭＥ）がＵＥを暗示的にデタッチする期間を示す。この期間は、例えば、ステップ２０２に示すように、デタッチタイマに使用されるタイマ値によって指示される。
【０１０２】
移動管理エンティティ（ＭＭＥ）におけるＵＥのコンテキスト内のデタッチタイマの値（例えば、ＭＭＥは加入者データベースから他のコンテキストパラメータとともにタイマ値を取得する）が用いられるか、又は、ＭＭＥはタイマ値を算出する。デタッチタイマ値がＵＥのコンテキスト（例えば、サブスクリプション）内に格納されている場合、ユーザ機器（ＵＥ）内にその値を設定することも可能である。ユーザ機器（ＵＥ）の設定は、例えば、ＵＳＩＭカード（つまり、ＵＳＩＭカード内に格納されて）実装されてもよく、アタッチ処理における移動管理エンティティ（ＭＭＥ）とのＮＡＳ交換中において実装されてもよい。遅延デタッチ処理に対するデタッチタイマのタイマ値の他のＵＥへの設定に代わるものとしては、ＯＭＡ  ＤＭ（Open Mobile Alliance Device Management）又はＯＴＡ（Over The Air）端末管理プロトコルの使用がある。
【０１０３】
デタッチタイマ値がユーザ機器（ＵＥ）に事前に設定／保存される場合、当然、デタッチ要求メッセージにおいてタイマ値を通知する必要は無い。移動管理エンティティ（ＭＭＥ）からのデタッチ要求メッセージは、デタッチが通常又は直ちに行われるデタッチ処理（つまり、デタッチタイマ不使用）であるか、遅延デタッチ（デタッチタイマを使用）とすべきであるか、をどうにかしてユーザ機器（ＵＥ）に通知できればよい。この目的のために、ＵＥに通知されているデタッチ要求メッセージ内のフラグが推測されるようにすることもできる。
【０１０４】
ユーザ機器（ＵＥ）に対してデタッチのタイプを通知する他のオプションは、移動管理エンティティ（ＭＭＥ）及びＵＥがアタッチ処理中に、デタッチ要求メッセージ受信時にＵＥに対して遅延デタッチ処理を想定させるか否かをネゴシエイトすることである。ネゴシエーション後、‘非拡張’デタッチ要求メッセージ（つまり、フラグ及びタイマ値を持たないデタッチ要求）は、ＵＥとＭＭＥとの間の合意として、遅延又は通常のデタッチ処理をトリガすることができる。
【０１０５】
ユーザ機器（ＵＥ）がデタッチタイマ値を含むデタッチ要求メッセージを受け取ると、ＵＥは、タイマ値を保存し、移動管理エンティティ（ＭＭＥ）に対するデタッチアクセプトメッセージを任意に生成・送信する（ステップ２０３）。デタッチアクセプトメッセージは、デタッチ要求メッセージの受信のみでなく、デタッチタイマの承認も行う。ユーザ機器（ＵＥ）が遅延デタッチ処理をサポートしていない場合（つまり、「return offline」機能を実装していない場合）、ＵＥは、デタッチアクセプトメッセージによって、結果的にＭＭＥに対して通知することができる。この際、ＭＭＥがＵＥをネットワークから直ちにデタッチしたい場合、ＭＭＥは、デタッチタイマを有さない、最新式に従うデタッチ要求メッセージを送信することができる。
【０１０６】
移動管理エンティティ（ＭＭＥ）が遅延デタッチ処理に関するユーザ機器（ＵＥ）とのＮＡＳシグナリング交換を完了した後、ＭＭＥは、さらに、Ｓ１リリース処理を実行する。ＭＭＥ及びサービングゲートウェイ（Ｓ−ＧＷ）は、ｅＮｏｄｅＢとＳ−ＧＷとの間のユーザプレーンベアラ（Ｓ１−Ｕベアラ）をリリースするために（Ｓ−ＧＷにおいてそれぞれのＵＥのＳ１−Ｕベアラのコンテキストを削除するために）、リリースアクセスベアラ要求及び応答メッセージを、Ｓ１１インタフェース（図１参照）を介して交換する（ステップ２０４、２０５）。その後、ＭＭＥは、ｅＮｏｄｅＢに対してＵＥのＳ１−Ｕベアラコンテキストを削除させるＳ１−ＡＰメッセージ（Ｓ１  ＵＥコンテキストリリースコマンド）及びその完了を、ｅＮｏｄｅＢとの間で交換する（ステップ２０６、２０８）。ｅＮｏｄｅＢは、無線接続（ＳＲＢ及びＤＲＢ）の終了を通知するために、ＲＲＣ接続リリースメッセージをＵＥに対して送信し（ステップ２０７）、ｅＮｏｄｅＢは、ＵＥの無線接続に関連するコンテキストを削除する。通常、ＲＲＣ接続リリース処理は、ｅＮｏｄｅＢによって実行される。すなわち、ＵＥは、ＲＲＣ接続リリース時には何のシグナリングも行う必要が無い。
【０１０７】
ユーザ機器（ＵＥ）側では、ＵＥもＲＲＣ接続のＲＡＮに関するコンテキスト情報を削除するとともに、CONNECTED状態からIDLE状態に入る。ＭＭＥは、Ｓ１  ＵＥコンテキストリリース完了メッセージを受信すると、ＵＥをIDLE状態に遷移させる。
【０１０８】
ｅＮｏｄｅＢ及び移動管理エンティティ（ＭＭＥ）がユーザ機器のコンテキスト情報を削除した正確な時点は、処理系に依存し、かつ、上述した例に示される時点とは異なる場合もある。また、Ｅ−ＵＴＲＡＮアーキテクチャの代わりにＵＴＲＡＮアーキテクチャを用いる場合、無線ネットワークエンティティ（例えばＮｏｄｅＢ、ＲＮＣ）は、ユーザ機器のコンテキストをリリースする必要がある。
【０１０９】
移動管理エンティティ（ＭＭＥ）からユーザ機器（ＵＥ）へ送信されたＮＡＳデタッチ要求メッセージ（ステップ２０２）は、ｅＮｏｄｅＢにおいて、非アクティブタイマ値をリセットすることができる。非アクティブタイマが動作しているとしても（すなわち、満了になっていないとしても）、Ｓ１−ＡＰのＳ１  ＵＥコンテキストリリース要求（ステップ２０６）がＲＲＣ接続リリースのトリガとなるため、ｅＮｏｄｅＢにおける非アクティブタイマ値のリセットは、IDLEモードトリガ処理に影響を与えないことが想定される。しかしながら、本発明の１つの例示的な実施の形態では、ｅＮｏｄｅＢの非アクティブタイマは、デタッチ要求メッセージ及びデタッチアクセプトメッセージの各々によって再開されない（つまりリセットされる）。
【０１１０】
図２に示す例示的な実施の形態では、デタッチタイマは、デタッチアクセプトメッセージの送受信時（ステップ２０３）に、ユーザ機器（ＵＥ）及び移動管理エンティティ（ＭＭＥ）によって開始される。また、デタッチ要求メッセージのシグナリング／受信、又は、ＵＥのIDLEモードへ入る場合（ステップ２０７、２０８）等のその他の事象がＵＥ及びＭＭＥのデタッチタイマを開始させてもよいことに留意すべきである。デタッチタイマが満了した時点で、ＵＥ及びＭＭＥは、暗示的なデタッチ処理をＵＥ及びＭＭＥのそれぞれにおいて実行する。ＵＥは、コンテキスト情報（ＥＰＳ及びＥＭＭコンテキスト、セキュリティコンテキストなど）を削除し、DEREGISTERED状態に遷移する（ステップ２０９）。ＭＭＥは、ＵＥのコンテキスト（ＥＰＳコンテキスト）を削除し（ステップ２１１）、対応するシグナリングメッセージを送信することにより、サービングゲートウェイ（Ｓ−ＧＷ）に対してＳ５ベアラのリリースをトリガする（ステップ２１０）。Ｓ−ＧＷは、ＵＥのＳ５ベアラをリリース（Ｓ５ベアラに関する対応コンテキストの削除を含む）するために、ＰＤＮゲートウェイ（Ｐ−ＧＷ）とのシグナリング交換を行う（ステップ２１２）。なお、ＭＭＥは、ＵＥコンテキストの一部（例えば、ＵＥの加入者データなど）を保持し続けることに留意されたい。さらに、ＭＭＥは、加入者リポジトリ（ＨＳＳ／ＨＬＲ）に対して、ＵＥがデタッチされたことを通知する（図２では図示せず）。
【０１１１】
本発明の１つの例示的な実施の形態では、デタッチ要求メッセージが、ＲＲＣ接続のリリースのためのＳ１−ＡＰ処理とともに、ユーザ機器（ＵＥ）へシグナリングされる。例えば、デタッチ要求メッセージは、Ｓ１−ＡＰの「Ｓ１  ＵＥコンテキストリリースコマンド」メッセージ（ステップ２０６）とともに、ｅＮｏｄｅＢへ送信される。ｅＮｏｄｅＢとＵＥとの間のデタッチ要求メッセージ及びデタッチアクセプトメッセージは、「下りリンク情報伝送」及び「上りリンク情報伝送」のＲＲＣメッセージにおいて交換されてもよい。最後に、ｅＮｏｄｅＢは、ＵＥに対してＲＲＣ接続リリースを通知し、移動管理エンティティ（ＭＭＥ）に対して、Ｓ１−ＡＰの「Ｓ１  ＵＥコンテキストリリース完了」によってリリースを承認する。
【０１１２】
図２に対して上述した例示的な実施の形態では、移動管理エンティティ（ＭＭＥ）は、デタッチタイマ値の設定を制御することができる。ユーザ機器（ＵＥ）は、また、デタッチタイマ値の決定においてネットワークをアシストすることもできる。例えば、ＵＥが、ＭＭＥから受け取るタイマ値が十分ではないことを知っており、かつ、ＵＥがデタッチアクセプトメッセージの送信時にデータの送受信にどれくらい時間が必要であるかを知っている場合、デタッチアクセプトメッセージ内には、ＵＥは、ＭＭＥによって通知されるタイマ値に対して、更新されたタイマ値、又は、増倍率（例えば、１．３、１．５など）を含めることができる。
【０１１３】
ユーザ機器（ＵＥ）は、デタッチタイマ値により示される期間が十分ではないことを知っているが、デタッチアクセプトメッセージの送信時にデータの送受信にどれくらい時間が必要であるかを知らない場合、ＵＥは、代わりに、例えばデタッチタイマ満了直前に、ＭＭＥにおけるデタッチタイマを拡張することができる。これは、例えば、ＵＥが、ＭＭＥによって事前に設定されたデタッチタイマがリセットされるか、或る係数を乗算されるべきであることを示す、ＮＡＳアタッチ要求メッセージ、ＮＡＳサービス要求メッセージ、又は、ＮＡＳ  ＴＡ更新要求メッセージをＭＭＥに送信することによって実装される。
【０１１４】
双方のケースにおいて、移動管理エンティティ（ＭＭＥ）は、ユーザ機器（ＵＥ）によって指示された変更後のデタッチタイマを任意に承認することができる。１つの可能性は、ＵＥが提案する新たなデタッチタイマ／デタッチタイマのリセットを承認する、又は、ＵＥに対する新たなデタッチタイマを設定する、ＭＭＥからＵＥへ送信される新たなＮＡＳデタッチ完了メッセージを導入することである。しかしながら、追加のシグナリングを回避するためには、既存のシグナリングメッセージを使用して、ＭＭＥが変更後のタイマを受け入れたことをＵＥに知ってもらうことが望ましい。例えば、ＭＭＥは、ＲＲＣ接続リリースメッセージの原因フィールド又は拡張フィールドにおいて、ステップ２０７のＲＲＣ接続リリースでのｅＮｏｄｅＢからＵＥへ送信される新たな原因値（例えば、「successful UE detach timer update」）によって、ｅＮｏｄｅＢへのＵＥコンテキストリリースコマンド内に（ステップ２０８）、デタッチタイマ更新が成功したか否かを示してもよい。
【０１１５】
デタッチタイマ値の設定に関して、これをどのように設定するかについて異なるオプションがある。デタッチタイマ値が算出される場合、移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢは、様々なパラメータを考慮してもよい。デタッチタイマ値の算出に使用できるいくつかのパラメータを以下に列挙する。
【０１１６】
CONNECTED状態の期間：
デタッチタイマ値は、各ユーザ機器の最近のCONNECTED状態の期間に比例する。例えば、最近のCONNECTED状態がより長いほど、デタッチタイマ値はより長く設定される。大きいデータが交換された後に、交換すべきデータがまだ残っている可能性があるので、ユーザ機器のCONNECTED状態の期間は交換されたデータ量に比例する。他の実装では、大きいデータが既に交換された後に送信するデータ量が少ないことが予測されるので、デタッチタイマ値は、各ユーザ機器の最近のCONNECTED状態の期間に反比例してもよい。さらに他の実装では、デタッチタイマ値を算出する移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢは、例えば、事前設定又は履歴情報によって、ユーザ機器により通常送信されるデータ量に関する情報を有してもよい。ＭＭＥ又はｅＮｏｄｅＢは、ユーザ機器が「通常」のデータ量を送信できるように、この情報に基づいてデタッチタイマ値を求めてもよい。
【０１１７】
CONNECTED-IDLEの遷移回数：
例えば、ユーザ機器の最初のCONNECTED状態からIDLE状態への遷移後に遅延デタッチ処理が開始される場合、ユーザ機器は、交換するいくつかのデータを未だ保持していることが想定される。よって、デタッチタイマ値はより長くなる。ネットワークに登録中にユーザ機器が既に何回かIDLE状態になっている場合、移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢは、残っている交換するデータがほとんどないと想定する。よって、デタッチタイマ値は短くなる。
【０１１８】
ユーザ優先度又はＥＰＳベアラの優先度：
ＥＰＳベアラの優先度又はＱｏＳクラスが高いほど、移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢは、デタッチタイマ値をより長く設定する。
【０１１９】
CONNECTED状態への現在の遷移の要因となる継続中の通信がネットワークによって開始されたか、ユーザ機器によって開始されたか（換言すると、ＲＲＣ確立要因がモバイル着信データ（mobile terminated data）であるか、モバイル発信データ（Mobile originated data）であるか）：
例えば、通信がモバイル発信データである場合、通信が開始されたとき、ユーザ機器の上りリンクデータがユーザ機器内で取得できることが想定され、IDLE状態がｅＮｏｄｅＢによってトリガされたとき、未処理のデータがもはや無いことが想定される。この場合、デタッチタイマは、低い値に設定されるか、削除することができる。すなわち、即時（immediate）のデタッチ（例えば、ＵＥに対するIDLE状態遷移処理によってトリガされる通常のデタッチ処理）が実行される。通信がページングを介してネットワークによって開始され、下りリンクデータがＭＴＣサーバからユーザ機器へ要求された場合、ユーザ機器は、上りリンクでの送信のためにデータ（例えば、ＧＰＳデータ）を蓄積している。この場合、移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢは、ユーザ機器に対して暗示的なデタッチの要因となるデタッチタイマ満了の前に十分な時間を許可するために、デタッチタイマ値を高い値に設定する。
【０１２０】
構成されるＭＴＣ機能：
ユーザ機器（ここではＭＴＣデバイス）は、例えば、「small data」機能及び「時間制御（time-controlled）」機能などの、ＭＴＣデバイスによって実装され、デタッチタイマ値の算出に影響を与えるＭＴＣ特有の機能で構成されることができる。
【０１２１】
ＭＴＣ機能「small data」は、ユーザ機器がＭＴＣサーバと小さいデータのみを交換することを意味する。この場合、移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢは、ユーザ機器（ＵＥ）がCONNECTED状態の間にデータを送信していて、大きなデータが未処理ではないことを想定する。よって、ｅＮｏｄｅＢによってIDLE状態がトリガされたとき、デタッチタイマに対して小さい値を設定することができる。極端な場合、ＭＴＣ機能「small data」を実装するユーザ機器のデタッチタイマ値にゼロを設定することもできる。また、ＭＭＥは、ＭＴＣ機能「small data」を実装するユーザ機器に対して、通常の（遅延しない）デタッチ処理を使用することを決定することもできる。
【０１２２】
ＭＴＣ機能「時間制御」は、ユーザ機器に対して、ネットワークとの接続確立、及び、ユーザ機器が或る期間（許可区間（grant interval）。非特許文献３の５．９．１節を参照）、ＭＴＣサーバと通信することが許可されていることを意味する。ユーザ機器にネットワークとの接続確立が許可されていない（又は、ネットワークへの接続が許可されていない）「禁止区間（forbidden interval）」と呼ばれるものがある。また、許可区間内における実際の通信期間である「通信窓（communication window）」と呼ばれるものがある。「デタッチタイマ」を決定する際、移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢは、「許可区間」、「禁止区間」及び「通信窓」を考慮してもよい。例えば、ユーザ機器に「時間制御」機能が構成／設定されている場合、ＭＭＥ又はｅＮｏｄｅＢは、ユーザ機器がネットワークに接続された時間を記録する。ｅＮｏｄｅＢによってIDLE状態トリガ処理が開始された場合、ＭＭＥ又はｅＮｏｄｅＢは、通信窓が満了するまでの残り時間として、デタッチタイマを算出することができる。また、より悪い無線条件下においてユーザ機器がより長いデータ送受信時間を要する場合、いくらかのガードタイム（例えば、１０％又は３０％長い時間）をデタッチタイマ値に含ませることができる。その他に、許可期間の終端を考慮してデタッチタイマ値を算出してもよい。
【０１２３】
当然、移動管理エンティティ（ＭＭＥ）又はｅＮｏｄｅＢは、１つ又は複数の上述したパラメータを考慮してもよく、デタッチタイマ値の算出の際に他のパラメータが考慮されてもよい。
【０１２４】
遅延デタッチ処理のためのシグナリング交換（例えば、図２のステップ２０２、２０３）が完了し、デタッチタイマが動作したとき、ユーザ機器（ＵＥ）及び移動管理エンティティ（ＭＭＥ）は、タイマ満了時にユーザ機器の局所的なデタッチ（すなわち、ＥＰＳベアラコンテキスト、移動管理コンテキストの一部削除、及び、明示的なシグナリング無しのDEREGISTERED移動状態への遷移）を行うことができる。しかしながら、デタッチタイマ動作中、いくつかの予期せぬ状況が生じ得る。そのような状況は、無線アクセスの規制であって、アクセスクラス規制（Access Class Barring：ACB）として知られている（非特許文献５及び非特許文献６を参照。いずれの非特許文献もhttp://www.3gpp.orgから入手可能であり、ここに援用される）。３ＧＰＰにおいて、ＵＥに対するアクセス規制を特定するＡＣＢと同様のテーマが低優先デバイス（low-priority device）として設定されている。この活動は、拡張アクセス規制（Extended Access Barring：ＥＡＢ）と呼ばれ、計画では、Release 11に対してこれを特定する予定である。ここでは、用語「アクセス規制Access Barring：ＡＢ）」は、ＡＣＢ及びＥＡＢ、又は他のアクセス規制方法を含むものとする。
【０１２５】
ＲＡＮにおけるアクセス規制は、通常、ネットワークオペレータによって開始される管理プロトコルによってトリガされる。しかしながら、アクセス規制は、例えば、Ｓ１−ＡＰオーバーロード開始メッセージを１つ又は複数のｅＮｏｄｅＢに送信することにより、移動管理エンティティによってトリガされることも可能である。
【０１２６】
一般に、アクセス規制は、ユーザ機器の異なるアクセスクラスに対して適用される。ｅＮｏｄｅＢによるブロードキャストシステム情報は、規制が適用されるアクセスクラスに対する情報を含む。例えば、警察、消防隊又は政府当局に属しているユーザ機器には、アクセス規制の際にもユーザ機器がネットワークにアクセスできるように、より高いアクセスクラスが割り当てられる。また、緊急通話の場合、ユーザ機器は、アクセス規制の除外を許可され得る。
【０１２７】
本発明の１つの例示的な実施の形態では、トラフィッククラス又はアプリケーションに基づいて新たなアクセス規制が導入される。ユーザ機器が低いトラフィッククラスの通信を開始した場合、ユーザ機器は規制され得るのに対して、高いトラフィッククラスの通信が開始された場合、アクセス規制は適用されない。これは、「トラフィッククラス規制」と呼ばれることもある。ここで使用される用語「アクセス規制」は、「トラフィッククラス規制」も含む。
【０１２８】
図３は、本発明の実施の形態に係る、遅延デタッチ処理を行うユーザ機器が収容される無線セルにおいてアクセス規制を操作するためのメッセージ交換の一例を示す。デタッチタイマ動作中（ステップ３０１、３０２）かつ無線アクセスネットワークがアクセス規制を開始した場合（ステップ３０３）であって、未処理の上りリンクデータが有る場合、ユーザ機器は、データ接続確立を行うことができなくなる。そのような状況では、アクセス規制がデタッチタイマよりも長く存続すると、ユーザ機器は、デタッチタイマが満了した場合にデータを送信できなくなり、ユーザ機器は、アクセス規制の終了後にアタッチ処理を行う必要がある。これは、ネットワークにおけるシグナリング及びリソース利用の増加を招いてしまう。
【０１２９】
この問題を回避するための１つの解決方法は、アクセス規制の実行中にはデタッチタイマを停止することである。「タイマ停止」とは、タイマを保持していることを意味し、すなわち、現在のタイマ値が格納され、タイマが無効又は削除されていないことを意味することに留意されたい。デタッチタイマの停止は、例えば、ユーザ機器（ＵＥ）内及び移動管理エンティティ（ＭＭＥ）内の設定を通じて実装可能である。また、ＵＥ及びＭＭＥにおいてデタッチタイマの同期が保証されるように、ＵＥ及びＭＭＥの双方がアクセス規制期間の開始及び終了を知っているか、検出することが想定される。しかしながら、このケースではなく、ＭＭＥがアクセス規制の開始を知らない場合、ＵＥ及びＭＭＥにおいて同期してデタッチタイマを停止するための他の解決方法が必要となる。
【０１３０】
図３において、例えば、ユーザ機器（ＵＥ）は、セル（IDLEモードで属しているセル）内のシステムブロードキャスト情報から、サービングｅＮｏｄｅＢがアクセス規制を適用していることを検出する（ステップ３０４）。無線セルにおいてアクセス規制が適用されている間に上りリンクデータの送信が未処理の場合（ステップ３０５）、ＵＥは、ＲＲＣ接続を確立し（すなわち、CONNECTED状態に入り）（ステップ３０６）、デタッチタイマの停止又はタイマをより長い時間に更新することを通知するために、シグナリングメッセージを移動管理エンティティ（ＭＭＥ）へ送信する（ステップ３０７）。
【０１３１】
図３において、ユーザ機器（ＵＥ）は、アクセス規制の検出後、移動管理エンティティ（ＭＭＥ）に対してデタッチタイマの更新を通知するためのＮＡＳメッセージを送信する（ステップ３０７）。ステップ３０７においてＵＥがＮＡＳ要求メッセージを送信する時点ではいくつかの更なるオプションがある。例えば、オプションの１つとして、アクセス規制の検出に反応して、又は、未処理の上りリンクデータが有りかつアクセス規制が適用されている場合に、ＮＡＳ要求メッセージを送信することがある。後者のオプションは、図２に示されている。ＭＭＥがステップ３０７においてＮＡＳメッセージを受信すると、ＭＭＥは、デタッチタイマを停止又は更新し（ステップ３０９）、ＮＡＳ応答メッセージをＵＥに送信することにより、ＵＥに対して動作の承認を行う（ステップ３０８）。ＵＥは、また、ＮＡＳ応答メッセージに応じて自身のデタッチタイマを更新し（ステップ３１０）、CONNECTED状態からIDLE状態へ戻るために、任意でＲＲＣ接続を再びリリースする（ステップ３１１）。ＵＥとＭＭＥとの間のＮＡＳメッセージを実装するための１つのオプションは、変更（modified）ＴＡＵ要求及びＴＡＵアクセプトメッセージをしようすることである。
【０１３２】
ユーザ機器（ＵＥ）がデタッチタイマの新たな更新値を提案する場合、移動管理エンティティ（ＭＭＥ）は、提案された値を変更（増加又は減少）する権限を持ってもよい。これは、ＭＭＥがアクセス規制期間のバックグラウンド情報（例えば、どれくらいコアネットワークが集中しているか等）を知っているためである。この場合、ＭＭＥは、ＳＴ３０８におけるＮＡＳ応答メッセージにおいて更新したデタッチタイマ値を通知してもよい。そして、ＵＥは、ステップ３１０において、自身のデタッチタイマを、ＭＭＥによって提案された値に更新する。また、ＵＥは、ＭＭＥに対する他のＮＡＳコンプリートメッセージによって、更新値を受領したことを承認してもよい（図３では図示せず）。なお、ＭＭＥからの更新されたデタッチタイマを有するＮＡＳ応答メッセージ、及び、ＵＥからのＮＡＳコンプリートメッセージは、デタッチタイマが確かに更新された場合のみに送信されてもよいことに留意されたい。アクセス規制処理中にデタッチタイマが停止された場合、ＭＭＥは、ＮＡＳ応答メッセージ内に更新タイマを含める必要はなく、ＵＥはＮＡＳコンプリートメッセージを送信する必要はない。
【０１３３】
通常、ユーザ機器が上りリンクデータを保持し、シグナリングを開始した場合、ユーザ機器には、アクセス規制期間中のＲＲＣ接続の確立が（例えば、規制係数によって）許可されていない。３ＧＰＰ用語では、この動作は、モバイル発信データ（mobile originated data）及びモバイル発信シグナリング（mobile originated signaling）と呼ばれる。本発明の目的のために、デタッチタイマが動作し、かつ、アクセス規制がブロードキャストされている場合に、ユーザ機器は、モバイル発信シグナリングのためにＲＲＣ接続確立の開始を許可されるようにしてもよい。
【０１３４】
アクセス規制が終了した時点において、ｅＮｏｄｅＢは、自身のセル内のユーザ機器に対してその結果を通知し（ステップ３１２）、ユーザ機器（ＵＥ）は、セル内においてアクセス規制の終了を検出できる（ステップ３１３）。その後、ユーザ機器は、再びCONNECTED状態へ入って送信が未処理である上りリンクデータを送信するために、ＮＡＳサービス要求を送信する（ステップ３１４）。ＵＥは、データ接続の確立をアクセス規制期間の終了直後に開始しないために、ランダムタイマを任意で適用してもよい。これにより、セル内においてアクセス規制終了後に上りリンクデータの送信が必要なユーザ機器から同時に多数のサービス要求が発生することを回避できる。
【０１３５】
さらに、ユーザ機器（ＵＥ）は、セル内におけるアクセス規制の終了を検出するとデタッチタイマを再開してもよい。さらに、ステップ３１４においてＮＡＳサービス要求を受け取った移動管理エンティティ（ＭＭＥ）は、このメッセージの受信に基づいて、ＵＥのセルにおいてアクセス規制がもはや適用されていないことを検出することができ、デタッチタイマを再開する。デタッチタイマがＵＥ及びＭＭＥにおいて満了したとき、双方のエンティティは、図２で説明したように暗示的なデタッチを行う。
【０１３６】
図３で説明した例では、デタッチタイマの同期は、ユーザ機器（ＵＥ）が移動管理エンティティ（ＭＭＥ）へアクセス規制期間の開始及び終了を明示的に通知することによって維持される。本発明の他の例示的な実施の形態では、他の解決方法として、アクセス規制期間がｅＮｏｄｅＢからＭＭＥへ指示される。図４は、そのような解決方法のメッセージ交換の一例を示す。図４に示す一例では、ＵＥ及びＭＭＥは、ステップ４０１，４０２においてＵＥのための遅延デタッチ処理のデタッチタイマを開始していることを再度想定する。
【０１３７】
ｅＮｏｄｅＢは、セル内でアクセス規制が適用されていることをブロードキャストし（ステップ４０４）、移動管理エンティティ（ＭＭＥ）に対してこの事象を通知する（ステップ４０３）。ｅＮｏｄｅＢに接続された複数のＭＭＥ（ＭＭＥプールと呼ばれる）が有る場合、ｅＮｏｄｅＢは、全てのＭＭＥに通知する。ＭＭＥは、「return offline」機能が構成／設定され、デタッチタイマが動作している、何れのユーザ機器がｅＮｏｄｅＢによって制御されたセル（又は複数のセル）に位置しているかについて、内部チェックを行ってもよい。そして、ＭＭＥは、デタッチタイマが動作していて、ｅＮｏｄｅＢが制御する１つ又は複数の無線セル内に位置する全てのユーザ機器（ＵＥを含む）に対するデタッチタイマを停止する（ステップ４０７）。同様に、ＵＥがアクセス規制の開始を検出した場合（ステップ４０５）、ＵＥもまたデタッチタイマを停止する（ステップ４０６）。図３と同様、ＵＥは、システムブロードキャスト情報からアクセス規制が適用されているか否かを知ることができる。
【０１３８】
アクセス規制が終了した後、ｅＮｏｄｅＢは、移動管理エンティティ（ＭＭＥ）に対してアクセス規制の終了を通知し（ステップ４０８）、デタッチタイマを再開する（ステップ４１２）。同様のことがユーザ機器（ＵＥ）でも行われる。すなわち、ＵＥは、アクセス規制がもはやブロードキャストされていないこと（ステップ４０９）を検出すると（ステップ４１０）、デタッチタイマを再開する（ステップ４１１）。
【０１３９】
アクセス規制期間中に送信未処理のデータが無い場合、ユーザ機器（ＵＥ）はデタッチできる。すなわち、ＵＥは、図２を用いて説明したように、デタッチタイマが満了した場合にDEREGISTERED状態へ移ることができる。アクセス規制期間中に送信未処理の上りリンクデータが有る場合、図３を用いて説明したように、ＵＥは、アクセス規制が終了すると、データ接続を確立するためのサービス要求を開始する。ＵＥは、データ接続の確立をアクセス規制期間の終了直後に開始しないために、ランダムタイマを任意に適用してもよい。これにより、セル内においてアクセス規制終了後に上りリンクデータの送信が必要なユーザ機器から同時に多数のサービス要求が発生することを回避できる。
【０１４０】
１つの起こり得る問題は、ユーザ機器がトラッキングエリア内のセル間を移動し、いくつかのセルがアクセス規制を適用し、他のセルがアクセス規制を適用していないことである。ユーザ機器がIDLE状態で移動した場合、移動管理エンティティ（ＭＭＥ）は、ユーザ機器が接続している正確な無線セルを知らない。よって、ＭＭＥは、アクセス規制が適用されているセルに接続しているのか否かを知ることができない。この問題は、図３及び図４で説明した双方の解決方法において生じ得る。
【０１４１】
この問題は、様々な方法によって解決される。本発明の１つの例示的な実施の形態では、ユーザ機器（ＵＥ）は、移動管理エンティティ（ＭＭＥ）に対して、例えば、ＮＡＳシグナリングを介して、検出したアクセス規制、及び、結果として生じたデタッチタイマの停止について通知する。なお、図３に示すメッセージフローの一例において、ＵＥ及びＭＭＥは、デタッチタイマを暗示的に、すなわち、明確なシグナリング無しで停止することに留意されたい。換言すると、ユーザ機器がアクセス規制の開始又は終了を検出する度に、ＵＥは、デタッチタイマの停止又は再開するためにＭＭＥとのＮＡＳシグナリング処理を行う。これは、ユーザ機器及び移動管理エンティティにおいてデタッチタイマに対する同期を維持するための信頼性のある解決方法である。
【０１４２】
図４に示す例、及び、例えば、ユーザ機器のＴＡＩリストの少なくとも１つのセルがアクセス規制を通知することを想定した場合、移動管理エンティティ（ＭＭＥ）は、ＵＥのトラッキングエリアを変更するためにＵＥをページ（page）してもよい。ユーザ機器のＴＡＩリストの一部のセルのみがアクセス規制下にあり、他のセルがそうではない状況では、ＭＭＥは、新たなセルに入る場合にＴＡＵを送信するＵＥを有するように、ＵＥに対する新たなトラッキングエリアを定義してもよい。ＭＭＥは、例えば、ＵＥが位置するセルのみをトラッキングエリアがカバーするように、又は、アクセス規制が適用されたセル又はアクセス規制が適用されていないセルのいずれかの隣接セルをトラッキングエリアがカバーするように、ＵＥのトラッキングエリアを定義することができる。アクセス規制を適用するか否かに基づくセルのグループ化は、常に実際に役立つわけではない。なぜなら、ネットワーク設定に応じて、複数のセルは、同一のトラッキングエリアＩＤ（ＴＡＩ）を使用し、各セルに対して異なるＴＡＩを再設定することは、オペレータにとって管理の負担が係ると考えられるためである。小さなトラッキングエリアを有することの他のデメリットは、ユーザ機器がＴＡＵ処理を頻繁に行う必要がある点である。
【０１４３】
図４で説明したようなアクセス規制のシナリオにおいてユーザ機器の移動の問題をターゲットにした他の例示的な実施の形態によれば、移動管理エンティティは、ユーザ機器のＴＡＩリストの一部であるセルがアクセス規制を適用すると直ぐにデタッチタイマを停止する。同様に、ユーザ機器もまた現在のセルでアクセス規制を検出すると、デタッチタイマを停止する。これは、現在のセルでは、ユーザ機器が接続していて、アクセス規制が適用されておらず、ユーザ機器がデタッチタイマを停止していないのに対して、ユーザ機器のＴＡＩリストの一部である他のセルでは、アクセス規制を適用し、移動管理エンティティがデタッチタイマを停止する状況を導いてしまう。この状況では、ユーザ機器及び移動管理エンティティは、非同期となり、ユーザ機器内のデタッチタイマは動作し続けるのに対して、移動管理エンティティ内のデタッチタイマは停止されてしまう。このため、ユーザ機器は、移動管理エンティティよりも早くデタッチし、DEREGISTERED状態に入ってしまう。これは、本質的な問題ではない。ただし、ユーザ機器及び移動管理エンティティのデタッチタイマが同期して動作せず、後述するように最適な状況ではなくなってしまう。
【０１４４】
移動管理エンティティよりも早くユーザ機器がネットワークからデタッチするいくつかのケースがある。
【０１４５】
−アクセス規制の場合、移動管理エンティティが、ユーザ機器のＴＡＩリストのセルがアクセス規制を適用すると直ぐにデタッチタイマを停止する場合、ユーザ機器内のデタッチタイマが動作しているにもかかわらず、移動管理エンティティがデタッチタイマを停止することが生じる。
【０１４６】
−ユーザ機器が複数のＭＴＣアプリケーションを有し、そのアプリケーションのいくつかがデータ交換の終了を指示することができ、他のアプリケーションがそれをできない場合、一般的な信頼性のある解決方法は、本発明で述べた遅延デタッチ処理を適用することである。しかしながら、ユーザ機器のＭＴＣアプリケーションがＵＥの通信モジュール（例えばＮＡＳ層）に対してデータ交換の終了を指示できる場合、ユーザ機器は、デタッチタイマ満了前にDEREGISTERED状態へ遷移することができる。
【０１４７】
一般に、移動管理エンティティ内のデタッチタイマ満了より早くユーザ機器が局所的にデタッチ（DEREGISTERED状態へ遷移）する場合、上りリンク通信に関する実質的な問題は無い。しかしながら、下りリンク通信においては、送信すべき下りリンクデータが有る場合、移動管理エンティティはユーザをページ（page）するものの、ユーザ機器が局所的にデタッチするので、移動管理エンティティは、ページングに対する応答（例えばＮＡＳサービス要求）を受け取れなくなる。
【０１４８】
例えば、劣悪な無線状況のように、データ通信期間の予測が困難である状況がある。また、ＭＴＣアプリケーションがＭＴＣサーバへ通知する情報を収集するのが困難となる場合、ＭＴＣデータが収集されている間、又は、ＭＴＣデータがアプリケーションレベルで処理されている間、ユーザ機器がIDLE状態でより長い時間を費やす状況がある。これらの例示する状況では、移動管理エンティティは、ＭＴＣデータを送信するのに十分ではないデタッチタイマの値を決定する。
【０１４９】
上述した起こり得る欠点を克服するために、本発明の一実施の形態によれば、ユーザがIDLE状態の間のみデタッチタイマが動作する。ユーザ機器は、ＭＴＣアプリケーションに応じて複数回、CONNECTED状態とIDLE状態との間を遷移することができる。ユーザ機器がIDLE状態からCONNECTED状態へ遷移する各回では、ユーザ機器及び移動管理エンティティ内のデタッチタイマは停止される（デタッチタイマ値は維持又は保存される）。ユーザ機器がCONNECTED状態からIDLE状態へ遷移した場合、ユーザ機器及び移動管理エンティティは、デタッチタイマを再開する。すなわち、デタッチタイマは、デタッチタイマが各エンティティにおいて停止されたときに保存された値から動作を継続させる。この例示的な実施の形態の利点は、低速データ伝送においてユーザ機器及びネットワークがデタッチタイマとは独立してデータを送信するのに十分な時間を有することである。デタッチタイマが満了に近づいているものの、ユーザ機器が未だに送信するデータを収集しているというさらなるシナリオでは、ユーザ機器は、データを実際に取得できている前にもかかわらず、IDLE状態からCONNECTED状態への遷移を開始する。CONNECTED状態への遷移は、デタッチタイマを停止させ、これにより、ユーザ機器に暗示的な又は局所的なデタッチ処理を行うまでの時間を引き延ばす機会を与える。
【０１５０】
本発明の他の例示的な実施の形態によれば、デタッチタイマは、データ通信のためにIDLE状態からCONNECTED状態への遷移が生じた際、ユーザ機器及び移動管理エンティティにおいて、常に、クリア／リセット／終了される。この例示的な実施の形態の変形として、ユーザがＴＡＵ／ＲＡＵを送信する場合には、デタッチタイマはクリア／リセット／終了されなくてもよい。これにより、ｅＮｏｄｅＢから非アクティブが指示された後、移動管理エンティティは、最後の遅延デタッチ処理が開始されてから変化した状況を考慮して新たなデタッチタイマ値を決定してもよい。例えば、移動管理エンティティは、前述したようなデタッチタイマ値を算出するための１つ又は複数のパラメータに基づいて、新たなデタッチタイマ値を決定することができ、ユーザ機器がIDLE状態へ移る前に遅延デタッチ要求メッセージをユーザ機器へ再び送信してもよい。
【０１５１】
上記において、サービングｅＮｏｄｅＢにおいて維持される非アクティブタイマの値を個別のユーザ機器又はユーザ機器のグループで異ならせることを提案している。本発明の他の例示的な実施の形態では、これは、遅延デタッチ処理の必要性を廃れさせる。ｅＮｏｄｅＢ内の非アクティブタイマに対して個別のタイマ値を用いることで、ユーザ機器に対する「return offline」機能を実現するために、IDLE状態トリガ処理をＭＴＣアプリケーションの特性に導入することができる。ｅＮｏｄｅＢにおいてユーザ機器の非アクティブタイマが満了したとき、ｅＮｏｄｅＢは、図２で説明したIDLE状態トリガ処理において移動管理エンティティに対して通知してもよい。ユーザ機器がIDLE状態に入ったこと（すなわち、ユーザ機器の非アクティブタイマ満了）を移動管理エンティティが通知されたとき、移動管理エンティティは、ネットワークからユーザ機器をデタッチするために最新のデタッチ処理を実行してもよい。
【０１５２】
その他に、ユーザ機器に対する非アクティブタイマの異なる設定が遅延デタッチ処理と相互に作用する。本発明の一実施の形態では、デタッチタイマ値の決定において、特定の非アクティブタイマ値の有用性を考慮することができる。よって、デタッチタイマ値のシグナリングを要さない遅延デタッチ処理の１つのあり得る実装は、遅延デタッチが設定されたユーザ機器が周期的なＴＡＵタイマを満了させ、ＴＡＵタイマの満了に応じてネットワークから暗示的に（シグナリング無しで）デタッチすることがある。遅延デタッチをサポートする移動通信ネットワーク内では、移動管理エンティティは、ユーザ機器を暗示的にデタッチする。移動管理エンティティ内の「暗示的なデタッチタイマ」が満了すると、移動管理エンティティは、移動通信ネットワークにおいて暗示的なデタッチ処理を行う。
【０１５３】
さらに、本発明の様々な実施の形態は、ソフトウェアモジュールによって実施することもでき、これらのソフトウェアモジュールは、プロセッサによって実行される、あるいはハードウェアにおいて直接実行される。さらに、ソフトウェアモジュールとハードウェア実装とを組み合わせることも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納することができる。
【０１５４】
実施の形態の多くは、３ＧＰＰベースの通信システムのアーキテクチャに関連して概説され、上記の各セクションにおいて使用された用語は、主に、３ＧＰＰ用語に関連する。ただし、３ＧＰＰベースのアーキテクチャに対する様々な実施の形態での用語及び説明は、本発明の原理及び着想をそのようなシステムのみに限定するものではない。
【０１５５】
さらに、［背景技術］における詳しい説明は、本明細書に記載されている、ほとんどが３ＧＰＰに固有な例示的な実施形態を深く理解することを目的としており、移動通信ネットワークにおけるプロセス及び機能の、説明した特定の実施の形態に本発明を制限するものではないことを理解されたい。しかしながら、本文書に提案したコンセプト及びサブフレーム構造は、[背景技術]に記載したアーキテクチャにおいてただちに適用することができる。さらには、本発明のコンセプトは、３ＧＰＰによって現在検討されているＬＴＥ−Ａ  ＲＡＮにおいてもただちに使用することができる。
【０１５６】
ここまで、本発明の様々な実施の形態及びそれらのバリエーションについて説明してきた。具体的な実施の形態において示した本発明には、広義に記載されている本発明の概念又は範囲から逸脱することなく膨大なバリエーション若しくは変更形態を創案できることが、当業者には理解されるであろう。
【図１】
0005851019.tif 000002
【図２】
0005851019.tif 000003
【図３】
0005851019.tif 000004
【図４】
0005851019.tif 000005