(57)【特許請求の範囲】
【請求項１】
１以上のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ）のモビリティを管理するノードであって、
ネットワークにおけるトラヒック負荷に基づき、自ノードのパワーを落とすか否かを判定する第１の手段と、
自ノードのパワーを落とすと判定された場合、自ノードに接続される基地局に自ノードのパワーが落とされる旨を通知して、前記基地局にハンドオーバを開始させる第２の手段と、
前記基地局から前記ハンドオーバのための第１の要求を受信した際、接続モードに在るＵＥのコンテキストを前記１以上のＵＥのモビリティを管理可能な他のノードへ転送するための第２の要求を送出する第３の手段と、を備え、
前記第１の要求は、Ｓ１準拠のハンドオーバ方式で用いられるＨａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄメッセージであり、
前記第２の要求は、前記Ｓ１準拠のハンドオーバ方式で用いられるＦｏｒｗａｒｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージである、
ノード。
【請求項２】
請求項１において、
自ノードのパワーを落とすのを、アイドルモードに在るＵＥが前記他のノードとのコネクションを確立可能なように設定した所定期間だけ待機する手段、
を更に備えたノード。
【請求項３】
請求項１又は２において、
前記第１の手段は、前記ネットワークのトラヒック負荷に基づき、前記１以上のＵＥに対してデータパケットのルーティング及び転送を行うゲートウェイのパワーを落とすか否かを判定し、
前記第２の手段は、前記ゲートウェイのパワーを落とすと判定された場合に、前記基地局に前記ゲートウェイのパワーが落とされる旨を通知して、前記基地局に前記ハンドオーバを開始させ、
前記第３の手段は、前記基地局から前記第１の要求を受信した際、前記１以上のＵＥに対して前記データパケットのルーティング及び転送を行うことが可能な他のゲートウェイとのセッションを確立するための第３の要求を送出すると共に、前記基地局に対して、前記他のゲートウェイに関する情報を含む応答を返す、
ことを特徴としたノード。
【請求項４】
請求項３において、
前記第３の要求は、Ｓ１準拠のハンドオーバ方式で用いられるＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔメッセージであり、
前記応答は、前記Ｓ１準拠のハンドオーバ方式で用いられるＨａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージである、
ことを特徴としたノード。
【請求項５】
請求項１において、
アイドルモードに在るＵＥへのページングを行って、当該ＵＥにＴＡＵ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｉｎｇ）手順を実行させる手段、
を更に備えたノード。
【請求項６】
請求項１〜５のいずれか一項において、
前記第１の手段は、前記トラヒック負荷が他の期間と比して減少すると予測される所定期間、又は前記トラヒック負荷が所定の閾値まで減少した場合に、自ノードのパワーを落とすと判定する、
ことを特徴としたノード。
【請求項７】
請求項１〜６のいずれか一項において、
自ノードのパワーを落とすと判定された場合、自ノードのパワーが落とされる旨を、前記１以上のＵＥのモビリティを管理可能な他のノードへ知らせる手段、
を更に備えたノード。
【請求項８】
請求項１〜７のいずれか一項において、
前記第１の手段は、自ノードのパワーが落とされた後、前記ネットワークにおけるトラヒック負荷に基づき、自ノードのパワーを上げるか否かを更に判定し、
前記第２の手段は、自ノードのパワーを上げると判定された場合、前記基地局に自ノードのパワーが上げられる旨を通知する、
ことを特徴としたノード。
【請求項９】
請求項８において、
前記第１の手段は、前記トラヒック負荷が他の期間と比して増大すると予測される所定期間、災害の際、又は前記基地局若しくは前記他のノードが過負荷である場合に、自ノードのパワーを上げると判定する、
ことを特徴としたノード。
【請求項１０】
請求項１〜９のいずれか一項において、
前記第３の手段は、前記第２の要求に、自ノードからデタッチしたＵＥのコンテキストを含める、
ことを特徴としたノード。
【請求項１１】
１以上のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ）との無線通信を行うことが可能な基地局であって、
自基地局に接続され且つ前記１以上のＵＥのモビリティを管理するノードから、前記ノードのパワーが落とされる旨を示す第１の通知を受信する第１の手段と、
前記第１の通知を受信した際、前記ノードに対して、ハンドオーバのための第１の要求を送信する第２の手段と、を備え、
前記第１の要求は、Ｓ１準拠のハンドオーバ方式で用いられるＨａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄメッセージである、
基地局。
【請求項１２】
請求項１１において、
アイドルモードに在るＵＥから、ＴＡＵ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｉｎｇ）のための第２の要求を受信する手段と、
自基地局に接続されるノードであって、前記第１の通知が受信された前記ノード以外のノードの内から、前記１以上のＵＥのモビリティを管理可能な他のノードを選択する手段と、
前記他のノードへ、前記第２の要求を転送する手段と、
を更に備えた基地局。
【請求項１３】
請求項１１又は１２において、
前記第１の手段は、前記ノードから、前記１以上のＵＥに対してデータパケットのルーティング及び転送を行うゲートウェイのパワーが落とされる旨を示す第２の通知を更に受信し、
前記第２の手段は、前記第２の通知を受信した際に、前記第１の要求を前記ノードへ送信し、
前記第３の手段は、前記ノードから、前記第１の要求に対する応答であって、前記ゲートウェイに代わり前記１以上のＵＥに対して前記データパケットのルーティング及び転送を行う他のゲートウェイに関する情報を含む応答を受信する、
ことを特徴とした基地局。
【請求項１４】
請求項１３において、
前記応答は、Ｓ１準拠のハンドオーバ方式で用いられるＨａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージである、
ことを特徴とした基地局。
【請求項１５】
１以上のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ）に対するデータパケットのルーティング及び転送を行うゲートウェイであって、
ネットワークにおけるトラヒック負荷に基づき、自ゲートウェイのパワーを落とすか否かを判定する手段と、
自ゲートウェイのパワーを落とすと判定された場合、前記１以上のＵＥのモビリティを管理するノードに、自ゲートウェイのパワーが落とされる旨を通知する手段と、
を備えたゲートウェイ。
【請求項１６】
請求項１５において、
ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）に対して、自ゲートウェイのパワーが落とされている間は、自ゲートウェイの解決（ｒｅｓｏｌｕｔｉｏｎ）を行わないよう指示する手段、
を更に備えたゲートウェイ。
【請求項１７】
１以上のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ）のモビリティを管理するノードの制御方法であって、
ネットワークにおけるトラヒック負荷に基づき、前記ノードのパワーを落とすか否かを判定し、
前記ノードのパワーを落とすと判定した場合、前記ノードに接続される基地局に前記ノードのパワーが落とされる旨を通知して、前記基地局にハンドオーバを開始させ、
前記基地局から前記ハンドオーバのための第１の要求を受信した際、接続モードに在るＵＥのコンテキストを前記１以上のＵＥのモビリティを管理可能な他のノードへ転送するための第２の要求を送出する、ことを含み、
前記第１の要求として、Ｓ１準拠のハンドオーバ方式で用いられるＨａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄメッセージを受信し、
前記第２の要求として、前記Ｓ１準拠のハンドオーバ方式で用いられるＦｏｒｗａｒｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送出する、
方法。
【請求項１８】
請求項１７において、
前記ノードのパワーを落とすのを、アイドルモードに在るＵＥが前記他のノードとのコネクションを確立可能なように設定した所定期間だけ待機する、
ことを更に含む方法。
【請求項１９】
請求項１７又は１８において、
前記ネットワークのトラヒック負荷に基づき、前記１以上のＵＥに対してデータパケットのルーティング及び転送を行うゲートウェイのパワーを落とすか否かを判定し、
前記ゲートウェイのパワーを落とすと判定した場合に、前記基地局に前記ゲートウェイのパワーが落とされる旨を通知して、前記基地局に前記ハンドオーバを開始させ、
前記基地局から前記第１の要求を受信した際、前記１以上のＵＥに対して前記データパケットのルーティング及び転送を行うことが可能な他のゲートウェイとのセッションを確立するための第３の要求を送出し、
前記基地局に対して、前記他のゲートウェイに関する情報を含む応答を返す、
ことを更に含む方法。
【請求項２０】
請求項１９において、
前記第３の要求として、Ｓ１準拠のハンドオーバ方式で用いられるＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔメッセージを送出し、
前記応答として、前記Ｓ１準拠のハンドオーバ方式で用いられるＨａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージを返す、
ことを特徴とした方法。
【請求項２１】
請求項１７において、
アイドルモードに在るＵＥへのページングを行って、当該ＵＥにＴＡＵ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｉｎｇ）手順を実行させる、
ことを更に含む方法。
【請求項２２】
請求項１７〜２１のいずれか一項において、
前記トラヒック負荷が他の期間と比して減少すると予測される所定期間、又は前記トラヒック負荷が所定の閾値まで減少した場合に、前記ノードのパワーを落とすと判定する、
ことを特徴とした方法。
【請求項２３】
請求項１７〜２２のいずれか一項において、
前記ノードのパワーを落とすと判定した場合、前記ノードのパワーが落とされる旨を、前記１以上のＵＥのモビリティを管理可能な他のノードへ知らせる、
ことを更に含む方法。
【請求項２４】
請求項１７〜２３のいずれか一項において、
前記ノードのパワーを落とした後、前記ネットワークにおけるトラヒック負荷に基づき、前記ノードのパワーを上げるか否かを更に判定し、
前記ノードのパワーを上げると判定した場合、前記基地局に前記ノードのパワーが上げられる旨を通知する、
ことを更に含む方法。
【請求項２５】
請求項２４において、
前記トラヒック負荷が他の期間と比して増大すると予測される所定期間、災害の際、又は前記基地局若しくは前記他のノードが過負荷である場合に、前記ノードのパワーを上げると判定する、
ことを特徴とした方法。
【請求項２６】
請求項１７〜２５のいずれか一項において、
前記第２の要求に、前記ノードからデタッチしたＵＥのコンテキストを含める、
ことを特徴とした方法。
【請求項２７】
１以上のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ）との無線通信を行うことが可能な基地局の制御方法であって、
前記基地局に接続され且つ前記１以上のＵＥのモビリティを管理するノードから、前記ノードのパワーが落とされる旨を示す第１の通知を受信し、
前記第１の通知を受信した際、前記ノードに対して、ハンドオーバのための第１の要求を送信する、ことを含み、
前記第１の要求として、Ｓ１準拠のハンドオーバ方式で用いられるＨａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄメッセージを送出する、
方法。
【請求項２８】
請求項２７において、
アイドルモードに在るＵＥから、ＴＡＵ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｉｎｇ）のための第２の要求を受信し、
前記基地局に接続されるノードであって、前記第１の通知が受信された前記ノード以外のノードの内から、前記１以上のＵＥのモビリティを管理可能な他のノードを選択し、
前記他のノードへ、前記第２の要求を転送する、
ことを更に含む方法。
【請求項２９】
請求項２７又は２８において、
前記ノードから、前記１以上のＵＥに対してデータパケットのルーティング及び転送を行うゲートウェイのパワーが落とされる旨を示す第２の通知を受信し、
前記第２の通知を受信した際に、前記第１の要求を前記ノードへ送信し、
前記ノードから、前記第１の要求に対する応答であって、前記ゲートウェイに代わり前記１以上のＵＥに対して前記データパケットのルーティング及び転送を行う他のゲートウェイに関する情報を含む応答を受信する、
ことを更に含む方法。
【請求項３０】
請求項２９において、
前記応答として、Ｓ１準拠のハンドオーバ方式で用いられるＨａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージを受信する、
ことを特徴とした方法。
【請求項３１】
１以上のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ）に対するデータパケットのルーティング及び転送を行うゲートウェイの制御方法であって、
ネットワークにおけるトラヒック負荷に基づき、前記ゲートウェイのパワーを落とすか否かを判定し、
前記ゲートウェイのパワーを落とすと判定した場合、前記１以上のＵＥのモビリティを管理するノードに、前記ゲートウェイのパワーが落とされる旨を通知する、
ことを含む方法。
【請求項３２】
請求項３１において、
ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）に対して、前記ゲートウェイのパワーが落とされている間は、前記ゲートウェイの解決（ｒｅｓｏｌｕｔｉｏｎ）を行わないよう指示する、
ことを更に含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＴＥ(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)システムにおけるＥＰＣ(Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ)のためのエネルギー節約に関する。
【背景技術】
【０００２】
３Ｇ(ｔｈｉｒｄ−ｇｅｎｅｒａｔｉｏｎ)通信システムと比較して、ＥＰＳ(Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ)ネットワークは、より多くの電力を必要とし、以てより多くのＣＯ２(ｃａｒｂｏｎ ｄｉｏｘｉｄｅ)を発生させる。気候変動やエネルギー不足といった深刻な問題に直面する一方、エネルギー節約は、移動体通信事業に欠かせないものと思われる。省エネ型の製品及びメカニズムは、エネルギー消費量の削減に必要であり、需要に応じたエネルギー供給の増大を抑制する。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】３ＧＰＰ ＴＳ ２３．４０１、"Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ (ＧＰＲＳ) ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ (Ｅ−ＵＴＲＡＮ) ａｃｃｅｓｓ (Ｒｅｌｅａｓｅ ９)"、Ｖ９．５．０、２０１０年６月
【発明の概要】
【０００４】
本発明では、ＬＴＥコアネットワークにおけるエネルギー節約のためのメカニズムが提供される。サービスを受けるために移動体ネットワークへ接続するユーザの多くが夜間に減少することを考慮すれば、ネットワークは、この間に全てのＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙｓ)及び／又はＳ−ＧＷ(Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙｓ)を稼働状態にしておく必要は無い。これを一般的な意味にまで及ばせれば、トラヒックがコアネットワークにおける高い負荷で無ければいつでも、幾つかのＭＭＥ及び／又はＳ−ＧＷがパワーを落とし、以てエネルギー節約及び汚染削減の目的を達成できる。非特許文献１に定義されるＭＭＥプールが、このメカニズムを可能にする。
【０００５】
用語(Ｔｅｒｍｉｎｏｌｏｇｙ)
スリーピングＭＭＥ：(エネルギー節約を目的として)パワーを落とそうとする又はパワーダウン状態に在るＭＭＥ
ノーマルＭＭＥ：恒久的にアクティブ状態を維持する、すなわちパワーダウン状態にないＭＭＥ
スリーピングＳ−ＧＷ：(エネルギー節約を目的として)パワーを落とそうとする又はパワーダウン状態に在るＳ−ＧＷ
ノーマルＳ−ＧＷ：恒久的にアクティブ状態を維持する、すなわちパワーダウン状態にないＳ−ＧＷ
【０００６】
本発明は、ＬＴＥコアネットワークにおけるエネルギー節約を考慮するものである。ネットワークが高いトラヒック負荷を有していない場合、全てのＭＭＥ及びＳ−ＧＷが活性化された状態のままでいる必要は無い。ネットワークがトラヒック負荷の減少を検知した場合、幾つかのＭＭＥ及び／又はＳ−ＧＷがパワーを落として、電力消費及びＣＯ２の発生を抑制するであろう(これらのＭＭＥ及びＳ−ＧＷを"スリーピング"ＭＭＥ及び"スリーピング"Ｓ−ＧＷと呼称し、他のＭＭＥ及びＳ−ＧＷを"ノーマル"と呼称する)。同様に、トラヒック負荷が高くなった場合、ネットワークは、スリーピングＭＭＥであったものの幾つかのパワーを上げることができる。
【０００７】
但し、ＵＥへの影響は可能な限り無くすべきである。
【発明の効果】
【０００８】
ＭＭＥ及び／又はＳ−ＧＷをしばらくの間パワーダウン状態とすることは、エネルギーを節約し、ＣＯ２の発生を抑制することに繋がる。一般的なトラヒック及び負荷の検討に基づけば、ＭＭＥ／Ｓ−ＧＷの数及びパワーダウン状態に在る総時間は非常に大きい。
【０００９】
Ｓ１準拠のハンドオーバ、及びｔｒａｃｋｉｎｇ ａｒｅ ｕｐｄａｔｉｎｇ手順の再利用は、ＵＥに影響を与えず、ネットワークに多大な負担を強いることも無いであろう。
【００１０】
ＭＭＥ及び／又はＳ−ＧＷ手順の変更は、ＵＥ及び既存のシステムに対して透過的である。
【図面の簡単な説明】
【００１１】
【図１】ＵＥが接続(ｃｏｎｎｅｃｔｅｄ)モードに在る場合におけるスリーピングＭＭＥの動作を示したシーケンス図である。
【図２】ＵＥがアイドルモードに在る場合におけるスリーピングＭＭＥの動作を示したシーケンス図である。
【図３】ＵＥが接続モードに在る場合におけるスリーピングＳ−ＧＷの動作を示したシーケンス図である。
【図４】ＵＥがアイドルモードに在る場合におけるスリーピングＳ−ＧＷの動作を示したシーケンス図である。
【発明を実施するための形態】
【００１２】
本発明の目的は、ネットワークのトラヒック負荷が減少した場合に幾つかのＭＭＥ及び／又はＳ−ＧＷがスリープする(パワーを落とす)ことを許可するメカニズムによって達成される。接続状態及びアイドル状態の両者に在るＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ)が考慮される。
【００１３】
１．スリーピングＭＭＥ
ＭＭＥがスリープする場合、ＭＭＥは、自身がスリープすべき時に、接続される全てのｅＮＢ(ｅｎｈａｎｃｅｄ Ｎｏｄｅ Ｂ)に対して"Ｐｏｗｅｒ ｄｏｗｎ"通知メッセージを送信する。このＭＭＥをスリーピングＭＭＥと呼称する。
【００１４】
接続モードに在るＵＥのために、Ｓ１準拠のハンドオーバ手順を部分的に再利用して、ＵＥのコンテキストをスリーピングＭＭＥから同一プール内のノーマルＭＭＥへ転送する。ｅＮＢとＵＥの間には如何なるＲＲＣ(Ｒｄａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ)シグナリングも発生せず、すなわち、ｅＮＢは、ＵＥにｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔｓを送信させるための"Ｍｅａｓｕｒｅｍｅｎｔ ｃｏｎｔｒｏｌ"メッセージを送出しないであろう。Ｐｏｗｅｒ ｄｏｗｎ通知メッセージは、ｅＮＢに、スリーピングＭＭＥへ"Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄ"メッセージを送信することによる、ノーマルＭＭＥへのＳ１ハンドオーバを開始させる(図１に示すステップＳ１０１及びＳ１０２)。スリーピングＭＭＥは、ｅＮＢから"Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄ"メッセージを受信した場合、ノーマルＭＭＥ(自ＭＭＥでもスリープしようとする他のＭＭＥでも無いもの)を選択するＭＭＥ選択を行う(ステップＳ１０３)。スリーピングＭＭＥは、例えば同一プール内のＭＭＥ同士間で状態を共有することによって、ノーマルＭＭＥを選択できる。一方、スリーピングＭＭＥが自身の状態について他のＭＭＥに知らせるだろうから、他のＭＭＥは、スリーピングＭＭＥをノーマルＭＭＥとしては選択しないであろう。また、ＭＭＥは、一旦スリーピングＭＭＥによって選択されると、"Ｐｏｗｅｒ ｄｏｗｎ"通知を送出すべきではない。そして、スリーピングＭＭＥは、ノーマルＭＭＥに対して"Ｆｏｒｗａｒｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ"メッセージを送信し、以てＵＥのコンテキストをノーマルＭＭＥへ転送する。ハンドオーバ手順が完了した後(ステップＳ１０４)、新たに選択されたＭＭＥは、ＧＵＴＩ(Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｔｙ) ｒｅｌｏｃａｔｉｏｎ手順を実行して、ＵＥに新たなＧＵＴＩを割り当てる(ステップＳ１０５)。
【００１５】
アイドルモードに在るＵＥのためには、ＴＡＵ(ｔｒａｃｋｉｎｇ ａｒｅａ ｕｐｄａｔｉｎｇ)手順が再利用される。"Ｐｏｗｅｒ ｄｏｗｎ"通知メッセージを送出した後(図２に示すステップＳ２０１)、スリーピングＭＭＥは、パワーダウン準備段階に入る(Ａｎｎｅｘ１)。準備段階の間、このＭＭＥに管理される全てのＵＥが、所定の期間に亘って"Ｔｒａｃｋｉｎｇ ａｒｅａ ｕｐｄａｔｉｎｇ ｒｅｑｕｅｓｔ"メッセージを送出し続ける(ステップＳ２０２)。ｅＮＢは、このようなメッセージを受信すると、ノーマルＭＭＥを選択する(ステップＳ２０３)。そして、各ｅＮＢは、"Ｔｒａｃｋｉｎｇ ａｒｅａ ｕｐｄａｔｉｎｇ ｒｅｑｕｅｓｔ"メッセージを選択したＭＭＥへ転送し、以て選択したＭＭＥに、ＵＥのコンテキストをスリーピングＭＭＥから取得させる。選択されたＭＭＥは、新たなＧＵＴＩを割り当てると共に、割り当てたＧＵＴＩをＴＡＵ ａｃｃｅｐｔメッセージに含めてＵＥへ送信する(ステップＳ２０４)。一旦パワーダウン準備段階が終わると、ＭＭＥは、パワーダウン又はスリープ状態に入る。ノーマルＭＭＥ選択は、接続モードのＵＥのためのものと同様の規則に従う。例えば、各ｅＮＢは、各ｅＮＢに接続されるＭＭＥの内から、Ｐｏｗｅｒ ｄｏｗｎ"通知メッセージを送出していないＭＭＥを選択する。
【００１６】
これに代えて、スリーピングＭＭＥがアイドルモードのＵＥに対するページングを行って、ＵＥにｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ手順を実行させることもできる(ステップＳ２０４)。この後、関与するｅＮＢは、要因"ｌｏａｄＢａｌａｎｃｉｎｇＴＡＵＲｅｑｕｉｒｅｄ"を伴うＲＲＣ ｒｅｌｅａｓｅを発行できる。このことは、後にｔｒａｃｋｉｎｇ ａｒｅａ ｕｐｄａｔｅを引き起こすであろう。この手順の変形は、ＭＭＥがより迅速にスリーピングモードへ到達することを可能にする。
【００１７】
スリーピングＭＭＥは、例えばネットワーク設定に従った時間になった、ｅＮＢが過負荷である或いは災害の場合等に、起床することができる。スリーピングＭＭＥは、ｅＮＢに対してＰｏｗｅｒ ｕｐ通知を送信するであろう(図１及び図２にそれぞれ示すステップＳ１０６及びＳ２０６)。
【００１８】
２．スリーピングＳ−ＧＷ
スリーピングＳ−ＧＷのケースでは、Ｓ−ＧＷに対応付けられたＭＭＥが、接続される全てのｅＮＢに対して、Ｓ−ＧＷがスリープする旨及びＳ−ＧＷがパワーダウンの対象(ターゲット)である旨を示すパラメータを伴う"Ｐｏｗｅｒ ｄｏｗｎ"通知メッセージを送信する(図３及び図４にそれぞれ示すステップＳ３０１及びＳ４０１)。オプションとして、Ｓ−ＧＷは、スリープを開始する際にプール内の全てのＭＭＥに対して、或いは接続される全てのｅＮＢに対して直接的に、"Ｐｏｗｅｒ ｄｏｗｎ"表示(ｉｎｄｉｃａｔｉｏｎ)を送信することができる。Ｓ−ＧＷは、その全てのセッションが削除された場合にスリープできる(ステップＳ３０５及びＳ４０３)。パワーアップのための特定のメッセージは不要である。これは、ＭＭＥが、前もってスリーピングＳ−ＧＷが起床したか否かを判定し、このＳ−ＧＷを他の(アクティブ又はアイドルモビリティ)手順内で自由に割り当てることが可能なためである(ステップＳ３０６及びＳ４０４)。ＵＥにとっては、Ｓ−ＧＷがスリープモードに在るか否かについての影響が無い。
【００１９】
接続モードに在るＵＥのためには、ｅＮＢとＵＥの間でＲＲＣシグナリングが発生しないように、Ｓ１準拠のハンドオーバ手順がまた部分的に再利用される。ｅＮＢは、ＭＭＥに対して"Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄ"メッセージを送信し、ＭＭＥは、スリープしないＳ−ＧＷを選択するＳ−ＧＷ選択を行う(ステップＳ３０２)。そして、ＭＭＥは、このノーマルＭＭＥとのセッションを確立するであろう(ステップＳ３０３)。ハンドオーバ手順は、ＭＭＥが"Ｈａｎｄｏｖｅｒ Ｃｏｍｍａｎｄ"メッセージをｅＮＢへ送信した後に終了する(ステップＳ３０４) (非特許文献１の５．５．１．２章を参照)。
【００２０】
アイドルモードに在るＵＥのためには、ＵＥはＳ−ＧＷの変更を検知する必要は無い。ＭＭＥは、ノーマルＳ−ＧＷを選択するＳ−ＧＷ選択を行うと共に、選択したノーマルＳ−ＧＷとのセッションを確立するであろう(ステップＳ４０２)。
【００２１】
なお、スリーピングＳ−ＧＷのケースでは、ＭＭＥがどのＳ−ＧＷがスリープ可能かを決定する。オプションとして、Ｓ−ＧＷ自身が決定してＭＭＥに知らせることができる。
【００２２】
スリーピングＳ−ＧＷによって知らされていないＭＭＥがスリーピングＳ−ＧＷを選択してしまうのを回避するため、Ｓ−ＧＷは、ＤＮＳ(Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ)に対し自身のスリープについて指示すべきである。ＤＮＳはスリーピングＳ−ＧＷの状態を更新すべきである。この結果、ＭＭＥは、スリーピングＳ−ＧＷを選択しないであろう。同様に、スリーピングＳ−ＧＷが起床した場合には、その状態がＤＮＳにおいて更新されるべきである。この結果、当該Ｓ−ＧＷは、ＭＭＥによって選択され得る。
【００２３】
３．ＭＭＥ及びＳ−ＧＷ両者のスリープ
ＭＭＥ及びＳ−ＧＷの両者がスリープすることが可能である。この場合、以下で事足りる。
−スリーピングＭＭＥは、スリープしようとするＭＭＥ及びＳ−ＧＷのいずれも選択すべきで無い。
−アクティブＭＭＥは、スリープしようとするＳ−ＧＷを選択すべきで無い。
−ＭＭＥは、自身に接続可能なプール内の全てのＳ−ＧＷが略同時期に(シグナリングにおける過負荷を回避するために、Ｓ−ＧＷのスリープ時間同士の最低限の時間間隔で)スリープしないことを保証すべきである。
【００２４】
Ａｎｎｅｘ１．パワーダウン準備段階
パワーダウン準備段階では、タイマのデフォルト設定として、アイドルモードのＵＥが他のＭＭＥへ移動するためにページングされない場合において、以下に定義されるような６６分５０秒の長さのタイマが必要である。
【００２５】
Ｔ３４１２＋Ｔ３４１１×５ｔｉｍｅｓ ＝ ５４分＋１０秒×５＋１２分
【００２６】
これ以外の場合、パワーダウン準備段階は、ページングによって全てのＵＥを他のＭＭＥへ移動させるのに必要な最大時間に設定できる。
【００２７】
なお、図示を省略するが、ＭＭＥは、例えば、ｅＮＢ、同一プールの他のＭＭＥ及びＳ−ＧＷとの通信をそれぞれ行うトランシーバと、これらのトランシーバを制御して、図１〜図４にそれぞれ示した処理或いはこれと同等の処理を実行するコントローラとで構成することができる。
【００２８】
また、ｅＮＢは、例えば、ＭＭＥとの通信を行うトランシーバと、ＵＥとの無線通信を行うトランシーバと、これらのトランシーバを制御して、図１〜図４にそれぞれ示した処理或いはこれと同等の処理を実行するコントローラとで構成することができる。
【００２９】
さらに、Ｓ−ＧＷは、例えば、同一プールのＭＭＥとの通信を行うトランシーバと、このトランシーバを制御して、図３及び図４にそれぞれ示した処理或いはこれと同等の処理を実行するコントローラとで構成することができる。
【００３０】
なお、上記の実施の形態によって本発明は限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。
【００３１】
この出願は、２０１０年８月１７日に出願された日本出願特願２０１０−１８２３８５を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【００３２】
上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【００３３】
(付記１)
どのＭＭＥがスリープするかを決定する方法
−これは、予め定義されるか或いはオペレータによって設定された時間通りであり得る。スリーピングＭＭＥは、定期的に、例えば毎晩、変更され得る。
−ネットワークは、トラヒック負荷の低いＭＭＥをスリープさせることを動的に選択できる。
【００３４】
(付記２)
新たなＰｏｗｅｒ ｄｏｗｎ通知メッセージ及びＰｏｗｅｒ ｕｐ通知メッセージ
Ｐｏｗｅｒ ｄｏｗｎ通知は、スリーピングＭＭＥ又はＳ−ＧＷ(Ｓ−ＧＷが決定可能な場合)によってｅＮＢへ送信され、スリープの契機となる。同様に、スリーピングＭＭＥは、Ｐｏｗｅｒ ｕｐ通知をｅＮＢへ送信して、自身がパワーダウン状態から起床することを示す。
【００３５】
(付記３)
ｅＮＢにＳ１準拠のハンドオーバを開始させるＰｏｗｅｒ ｄｏｗｎ通知メッセージ
ＭＭＥからＰｏｗｅｒ ｄｏｗｎ通知を受信した際、ｅＮＢは、ＭＭＥへＨａｎｄｏｖｅｒ ｒｅｑｕｉｒｅｄメッセージを送信することによってＳ１準拠のハンドオーバを開始すると共に、ＵＥとの間のＲＲＣシグナリングを省略するであろう。
【００３６】
(付記４)
パワーダウン準備段階
ＭＭＥは、その関連ＵＥをアクティブ又はスリープしていないＭＭＥへ転送しなければならないため、Ｐｏｗｅｒ ｄｏｗｎ通知を送出した後に直ちにはパワーを落とすべきで無い。ＭＭＥは、パワーダウン準備段階に入り、ＵＥがアクティブＭＭＥとのコネクションを確立するのを待機するであろう。
【００３７】
(付記５)
接続モードのＵＥをスリープしていないＭＭＥへ転送するためのＭＭＥ ｒｅｌｏｃａｔｉｏｎを伴うＳ１準拠のハンドオーバの再利用
このハンドオーバは、スリーピングＭＭＥがソースＭＭＥであり且つスリープしないＭＭＥがターゲットＭＭＥである一方、ｅＮＢがソース及びターゲットの両者であるという点で、一般的なＳ１準拠のハンドオーバとは若干異なる。
【００３８】
(付記６)
スリーピングＳ−ＧＷを実施するためのＳＧＷ ｒｅｌｏｃａｔｉｏｎを伴うＳ１準拠のハンドオーバの再利用
スリーピングＳ−ＧＷのケースでは、ハンドオーバ手順の一部(非特許文献１におけるステップ２〜９)が再利用される。ＭＭＥからｅＮＢへのＨａｎｄｏｖｅｒ ｃｏｍｍａｎｄメッセージにおいて、選択されたスリープしないＳ−ＧＷについての必要情報が提供される。
【００３９】
(付記７)
アイドルＵＥをアクティブＭＭＥへ転送するためのｔｒａｃｋｉｎｇ ａｒｅａ ｕｐｄａｔｉｎｇ手順の再利用
ＵＥの動作へ影響を与えず且つ不要なシグナリングを引き起こさないようにするため、スリーピングＭＭＥは、アイドルモードに在るＵＥがｔｒａｃｋｉｎｇ ａｒｅａ ｕｐｄａｔｉｎｇ手順を実行するのを待機する。この間、ｅＮＢは、ＵＥのためにスリープしないＭＭＥを選択するＭＭＥ選択を行うであろう。
【００４０】
(付記８)
ＭＭＥがスリープする契機
−スリーピングＭＭＥにはタイマが記憶且つ設定され得る。例えば、ＭＭＥは、夜間にスリープすることができる。
−或いは、パワーダウン及びアップのための閾値がオペレータによって設定され得る。すなわち、ネットワークのトラヒック負荷が閾値まで減少した場合、幾つかのＭＭＥがスリープを開始する。同様に、トラヒック負荷が増大して閾値に達した場合には、スリーピングＭＭＥの幾つか又は全てが活性化されるであろう。これは、ＯＡＭ(Ｏｐｅｒａｔｉｏｎｓ， Ａｄｍｉｎｉｓｔｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ)を介してトリガ且つ管理され得る。
【００４１】
(付記９)
スリープしないＭＭＥの選択方策
−ＭＭＥ各々は、スリーピングＭＭＥがパワーダウン準備段階又はパワーダウン状態に在るＭＭＥを選択しないよう、互いのスリープ状態について知るべきである。これは、スリーピングＭＭＥが、自身がスリープする旨を知らせるメッセージを送出することによって実現できる。
−スリーピングＭＭＥは、他のスリーピングＭＭＥによって選択された場合、要求の送信元へ知らせ、且つ適切な理由で要求を拒絶すべきである。
−スリーピングＭＭＥは、軽負荷で、スリープしないＭＭＥを動的に選択することが可能である。
【００４２】
(付記１０)
スリーピングＭＭＥが起床する契機
ＭＭＥをスリープ状態から起床させ得る幾つかのイベントが挙げられる。
−Ｏ＆Ｍ又は設定：例えば、ＭＭＥにおいて日付や時間のタイマを設定
−災害：例えば、ＥＴＷＳ(Ｅａｒｔｈｑｕａｋｅ ａｎｄ Ｔｓｕｎａｍｉ Ｗａｒｎｉｎｇ Ｓｙｓｔｅｍ)
−ｅＮｏｄｅＢ又はスリープしないＭＭＥから：例えば、ｅＮＢ又はＭＭＥが過負荷であること
【００４３】
(付記１１)
アイドルモードに在るＵＥに対するパージング(Ｐｕｒｇｉｎｇ)
通常、ＭＭＥは、ＵＥが２４時間に亘ってデタッチしている場合に、Ｐｕｒｇｅ ＵＥ ｒｅｑｕｅｓｔを送出する。しかしながら、スリーピングＭＭＥがその状態を変化させずに起床した場合には、２４時間に達せず、Ｐｕｒｇｅがトリガされないであろう。
このため、スリーピングＭＭＥがデタッチしたＵＥのコンテキストを選択したスリープしないＭＭＥへ転送し、その結果、このことがスリープしないＭＭＥによって検知されるであろう。
【００４４】
(付記１２)
ＤＮＳにおけるＳ−ＧＷ情報の更新
スリーピングＳ−ＧＷの状態は、以下の理由に因り、ＤＮＳ(Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ)準拠のＳ−ＧＷ選択手順に影響を与えるようＳ−ＧＷ又はＭＭＥのいずれかによって、ＤＮＳにおいて更新されるべきである(すなわち、スリーピングＳ−ＧＷは、そのスリーピング段階の間、ＤＮＳによって解決されるべきでは無い)。
−スリーピングＳ−ＧＷに対応付けられたＭＭＥが、スリーピングＳ−ＧＷをそのスリーピング段階の間に選択してしまうのを防止すること
−Ｓ−ＧＷに対応付けられていない他のＭＭＥが、Ｓ−ＧＷを選択してしまうのを防止すること
ＭＭＥがＤＮＳキャッシングに因ってスリーピングＳ−ＧＷを選択してしまうのを回避するため、Ｓ−ＧＷ選択用のＤＮＳ解決のためのキャッシュ時間を結果的に短縮する必要があり得る。
スリーピングＳ−ＧＷが起床した場合、ＤＮＳはまた、新たなＰＤＮ(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ)コネクションのために当該Ｓ−ＧＷの選択を許可するよう更新されるべきである。
【図１】
0005483514.tif 000002
【図２】
0005483514.tif 000003
【図３】
0005483514.tif 000004
【図４】
0005483514.tif 000005