(57)【特許請求の範囲】
【請求項１】
コアネットワークを形成する複数のノードを備えた移動体通信システムであって、
前記複数のノードの少なくとも一つは、
前記複数のノード間で共有されるリソース情報に基づき、スリープすることを決定し、
自ノードをスリープさせると決定した場合に、自ノードがスリープする旨を、前記複数のノードの内の他のノード、及びＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を形成するノードへ通知し、
前記通知への応答が前記ＲＡＮを形成するノードから受信された際、前記他のノードのいずれか一つに対して、自ノードに代わって、前記ＲＡＮを形成するノードとのコネクションを確立するよう要求し、
前記応答は、ハンドオーバ手順に用いられるＲｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージであり、
前記要求は、前記ハンドオーバ手順に用いられるＦｏｒｗａｒｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信することによって行われる、
移動体通信システム。
【請求項２】
移動体通信システムにおけるコアネットワークを形成するノードであって、
前記コアネットワークを形成する１以上の他のノードとの間で、リソース情報を共有する第１の手段と、
前記リソース情報に基づき、自ノードをスリープさせるか否かを決定する第２の手段と、
前記第２の手段が自ノードをスリープさせると決定した場合に、自ノードがスリープする旨を、前記他のノード、及びＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を形成するノードへ通知する第３の手段と、
前記通知への応答が前記ＲＡＮを形成するノードから受信された際、前記他のノードのいずれか一つに対して、自ノードに代わって、前記ＲＡＮを形成するノードとのコネクションを確立するよう要求する第４の手段と、を備え、
前記応答は、ハンドオーバ手順に用いられるＲｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージであり、
前記第４の手段は、前記要求を、前記ハンドオーバ手順に用いられるＦｏｒｗａｒｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信することによって行う、
ノード。
【請求項３】
請求項２において、
前記第２の手段は、前記リソース情報が、前記他のノードのいずれかが自ノードの負荷を転送するのに十分なリソース量を有する旨を示している場合に、自ノードをスリープさせると決定する、
ことを特徴としたノード。
【請求項４】
請求項２又は３において、
自ノードをスリープさせるのに先立って、前記ＲＡＮを介して自ノードへアタッチしているＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)に対して、前記他のノードのいずれか一つへ再アタッチするよう要求する第５の手段、
をさらに備えたノード。
【請求項５】
請求項４において、
前記第５の手段は、前記ＵＥに対する要求を、ｒｅ−ａｔｔａｃｈ ｒｅｑｕｉｒｅｄを示すデタッチ種別を伴うデタッチ要求メッセージを送信することによって行う、
ことを特徴としたノード。
【請求項６】
移動体通信システムにおけるエネルギー節約方法であって、
前記移動体通信システムにおいてコアネットワークを形成する複数のノードの少なくとも一つを、前記複数のノード間で共有されるリソース情報に基づきスリープさせると決定し、
前記少なくとも一つのノードをスリープさせると決定した場合に、前記少なくとも一つのノードがスリープする旨を、前記複数のノードの内の他のノード、及びＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を形成するノードへ通知し、
前記通知への応答が、前記少なくとも一つのノードにて前記ＲＡＮを形成するノードから受信された際、前記少なくとも一つのノードから前記他のノードのいずれか一つに対して、前記少なくとも一つのノードに代わって、前記ＲＡＮを形成するノードとのコネクションを確立するよう要求する、ことを含み、
前記応答として、ハンドオーバ手順に用いられるＲｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージを受信し、
前記要求は、前記ハンドオーバ手順に用いられるＦｏｒｗａｒｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信することによって行われる、
方法。
【請求項７】
移動体通信システムにおいてコアネットワークを形成するノードの制御方法であって、
前記コアネットワークを形成する１以上の他のノードとの間でリソース情報を共有し、
前記リソース情報に基づき、自ノードをスリープさせるか否かを決定し、
自ノードをスリープさせると決定した場合に、自ノードがスリープする旨を、前記他のノード、及びＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を形成するノードへ通知し、
前記通知への応答が前記ＲＡＮを形成するノードから受信された際、前記他のノードのいずれか一つに対して、自ノードに代わって、前記ＲＡＮを形成するノードとのコネクションを確立するよう要求する、ことを含み、
前記応答として、ハンドオーバ手順に用いられるＲｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージを受信し、
前記要求は、前記ハンドオーバ手順に用いられるＦｏｒｗａｒｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信することによって行われる、
方法。
【請求項８】
請求項７において、
前記リソース情報が、前記他のノードのいずれかが自ノードの負荷を転送するのに十分なリソース量を有する旨を示している場合に、自ノードをスリープさせると決定する、
ことを特徴とした方法。
【請求項９】
請求項７又は８において、
自ノードをスリープさせるのに先立って、前記ＲＡＮを介して自ノードへアタッチしているＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)に対して、前記他のノードのいずれか一つへ再アタッチするよう要求する、
ことをさらに含む方法。
【請求項１０】
請求項９において、
前記ＵＥに対する要求は、ｒｅ−ａｔｔａｃｈ ｒｅｑｕｉｒｅｄを示すデタッチ種別を伴うデタッチ要求メッセージを送信することによって行われる、
ことを特徴とした方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、３Ｇ(３ｒｄ Ｇｅｎｅｒａｔｉｏｎ)ネットワークにおけるＣＮ(Ｃｏｒｅ Ｎｅｔｗｏｒｋ)のためのエネルギー節約に関する。
【背景技術】
【０００２】
世界中のモバイルカバレッジは、急速に増加しており、今や世界人口の大半をカバーしている。ネットワークへアクセスする人の数が増加するに従って、移動体通信オペレータにより生み出される電力消費が環境にとっての重荷となり、配慮を必要とする。省エネ型の設備及びメカニズムが、エネルギー消費を低減して、環境汚染を防止するために必要である。
【０００３】
本発明においては、モバイルＣＮを効率良く使用するためのメカニズムが提供される。モバイルコアネットワークへの負荷は人的活動に応じて変化し、ＣＮが夜間に低い負荷を有していることは容易に推測される。未利用のノードをこれらの時間帯に“スリープ”させることによって、ＣＮの合計電力消費を減少させることが可能である。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ ＴＳ ２３．２５１、“Ｎｅｔｗｏｒｋ Ｓｈａｒｉｎｇ： Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ ｆｕｎｃｔｉｏｎａｌ ｄｅｓｃｒｉｐｔｉｏｎ (Ｒｅｌｅａｓｅ １０)”、Ｖ１０．０．０、２０１０年１２月、７〜８頁、４．１節
【非特許文献２】３ＧＰＰ ＴＳ ２３．２３６、“Ｉｎｔｒａ−ｄｏｍａｉｎ ｃｏｎｎｅｃｔｉｏｎ ｏｆ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ (ＲＡＮ) ｎｏｄｅｓ ｔｏ ｍｕｌｔｉｐｌｅ Ｃｏｒｅ Ｎｅｔｗｏｒｋ (ＣＮ) ｎｏｄｅｓ (Ｒｅｌｅａｓｅ １０)”、Ｖ１０．２．０、２０１０年１２月、１２頁、４．５ａ．１節
【非特許文献３】ＧＩＳＦＩ、ＧＥ−２０１０００２０、“Ｇｒｅｅｎｉｎｇ ｔｈｅ ｍｏｂｉｌｅ ｃｏｒｅ ｎｅｔｗｏｒｋ”、２０１０年１２月
【発明の概要】
【発明が解決しようとする課題】
【０００５】
現行の標準規格は、アクティブ呼を持つノードをシャットダウンする手段を提供していない。Ｉｕ−ｆｌｅｘメカニズムは、呼を持たないノードをシャットダウンする手段を提供し得るが、ノードに長時間のコネクション(例えば、ビデオストリーミング)が在る場合には、ノードをシャットダウンするのに時間を要する。
【０００６】
本発明は、アクティブ呼を他のノードへ転送するためのハンドオーバメカニズムを用い、短時間でのスリープを可能にすることによって、この問題を解決する方法を与える。
【０００７】
なお、関連技術として、非特許文献１には、Ｎｅｔｗｏｒｋ Ｓｈａｒｉｎｇが記載されている。非特許文献２には、複数のＣＮ(Ｃｏｒｅ Ｎｅｔｗｏｒｋ)ノードに対するＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)ノードのイントラドメイン・コネクションが記載されている。非特許文献３には、スリーピングＥＰＣが記載されている。
【課題を解決するための手段】
【０００８】
モバイルネットワークは、これを使用するユーザが存在しない又は少数である期間(例えば、夜間)であっても、エネルギーを消費する。不必要な電力消費を削減するために、本発明は、ＣＮノードが“スリープ(シャットダウン又は低電力状態で稼働)”することを提案する。ここでは、ＰＳ(Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ)ネットワークのためのスリーピングＣＮノード、すなわち、スリーピングＳＧＳＮ(Ｓｅｒｖｉｎｇ ＧＰＲＳ (Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ) Ｓｕｐｐｏｒｔ Ｎｏｄｅ)を定義する。
【０００９】
ＳＧＳＮが、これらのリソース情報をＯ＆Ｍ(ｏｐｅｒａｔｉｏｎ ａｎｄ ｍａｉｎｔｅｎａｎｃｅ)又はＧＴＰ−Ｃ(ＧＰＲＳ ｔｕｎｎｅｌｉｎｇ ｐｒｏｔｏｃｏｌ’ｓ Ｃ−ｐｌａｎｅ)メッセージを用いて共有し、Ｐｏｗｅｒ Ｄｏｗｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージによってＲＮＣ(Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ)／ＢＳＣ(Ｂａｓｅ Ｓｔａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ)リロケーションをトリガし、ＲＮＣ／ＢＳＣが、同一呼に属して“ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｉｒｅｄ”／“ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔ”が送信／受信されたリソースを特定可能な、新たな手段が含まれる。
【発明の効果】
【００１０】
本発明によれば、以下の効果を奏する。
【００１１】
１．オペレータは、未利用のネットワークノードをシャットダウンするか、或いはその電力を低くすることが可能であろう。これによって低電力消費を達成し得るから、オペレータは、環境に優しいシステムを実現できる。
【００１２】
２．オペレータは、ＣＮのサイズを、ネットワークへアクセスするユーザの量に応じて動的に縮小又は拡大(スケール)することが可能である。
【図面の簡単な説明】
【００１３】
【図１】２０２０年度における移動体通信セクタのＧＨＧ排出を示したグラフ図である。
【図２】３ＧＰＰアクセスネットワークの基本的な構成を示したブロック図である。
【図３】ＬＴＥネットワークの基本的な構成を示したブロック図である。
【図４】Ｎｅｔｗｏｒｋ Ｓｈａｒｉｎｇのためのゲートウェイ・コアネットワーク構成を示したブロック図である。
【図５】スリーピングコアネットワークの動作を示したブロック図である。
【図６】ＩＤＬＥモード状態に適用可能なデタッチ／アタッチ方法を示したシーケンス図である。
【図７】ＣＯＮＮＥＣＴＥＤモード状態に適用可能なリルーティング方法を示したシーケンス図である。
【図８】本発明の実施の形態に係るコアネットワークノードの構成例を示したブロック図である。
【発明を実施するための形態】
【００１４】
以下、本発明に係るＣＮノード及びこれを適用する移動体通信システムの実施の形態を、図面を参照して説明する。Ｉｕ−ｆｌｅｘが利用可能な３ＧＰＰ準拠のネットワークにおいては、共通プールエリア内の一群のＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)ノードが、当該プールエリアを監視するいずれかのＣＮノードによって制御され得る。ＣＮノードらは、一日の或る時間帯においては完全には動作し得ないだろうから、プールエリアにおける未利用リソースの合計量が、或るＣＮノードのキャパシティを超過する。これらのケースにおいては、特定のＣＮノードが、その負荷を他のＣＮノード(アクティブＣＮノード)へ受け渡し、そしてシャットダウンするか或いは電力消費を低下させる(例えば、待機モード又は休止モードへ入る)ことを決定しても良い。ここでは、ＰＳネットワークに着目する。
【００１５】
[スリーピングＳＧＳＮ]
休眠する前に、“スリープしたい”ＳＧＳＮ又はオペレータは、同一のＰＳプールエリア内の他のアクティブＳＧＳＮノードの空きリソース量をチェックするであろう(図６及び図７各々に示すステップＳ１０１)。これは、Ｏ＆Ｍメッセージを用いるか、又はＧＴＰ−Ｃプロトコルでメッセージを定義することによって実現できる。より詳細には、ＳＧＳＮは、Ｏ＆Ｍ又はＧＴＰ−Ｃメッセージを用いて相互に通信し、以てＳＧＳＮ同士間で空きリソースに関する情報(以下、“リソース情報”と呼称することがある)を共有する。こうすることにより、スリープしたいＳＧＳＮ又はオペレータは、スリープしたいＳＧＳＮがその負荷を移し且つスリープするのに十分なリソース量があるか否かを検知するであろう(図６及び図７各々に示すステップＳ１０２)。
【００１６】
スリープしたいＳＧＳＮは、一旦スリープを決定すると、ｐｏｗｅｒ ｄｏｗｎ ｎｏｔｉｆｉｃａｔｉｏｎを送出することによって、スリープする旨を宣言する(図６及び図７各々に示すステップＳ１０３)。これにより、ＲＮＣ／ＢＳＣがスリープしたいＳＧＳＮを新たなコネクション及びハンドオーバのために選択するのを防止する。
【００１７】
次に、スリープしたいＳＧＳＮは、その負荷を、同一のＰＳプールエリアにおける他のＳＧＳＮへ移すであろう。これには２つの方法が利用可能であり、その一つは、ＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)に対しネットワークへのデタッチ／アタッチを要求すること(ＲＮＣは、ｐｏｗｅｒ ｄｏｗｎ ｎｏｔｉｆｉｃａｔｉｏｎからスリープしたいＳＧＳＮを再選択しないであろう)、或いは新たなＳＧＳＮへのコネクションをリルーティングすることであり得る。
【００１８】
＜デタッチ／アタッチ方法＞
図６は、デタッチ／アタッチ方法を示している。この方法は、ＩＤＬＥモード状態に最も利用可能である。ＣＯＮＮＥＣＴＥＤモード状態にも適用可能であるが、アクティブなデータ転送を中断し得る。ここで、ＳＧＳＮは、ｐｏｗｅｒ ｄｏｗｎ ｎｏｔｉｆｉｃａｔｉｏｎを送信した後、ＵＥへのコネクション毎に、“ｄｅｔａｃｈ ｔｙｐｅ： ｒｅａｔｔａｃｈ ｒｅｑｕｉｒｅｄ”を伴うデタッチ要求を送出するであろう。デタッチ手順が、関連するノード間で行われる(ステップＳ１０４)。この後、ＵＥは、アタッチ手順をトリガするであろう。ここで、ＲＮＣ／ＢＳＣは、スリーピングＳＧＳＮがもはや使用中で無いことを検知しており、アタッチ要求のためにアクティブＳＧＳＮを選択するであろう(ステップＳ１０５)。
【００１９】
＜リルーティング方法＞
図７は、リルーティング方法を示している。この方法は、ＵＥコンテキストをスリープしたいＳＧＳＮからアクティブＳＧＳＮへ転送するハンドオーバ方式を部分的に使用するため、ＣＯＮＮＥＣＴＥＤモード状態に最も利用可能である。選択されたＲＮＣ／ＢＳＣには変更が無いため、ＵＥとＲＮＣ／ＢＳＣとの間に相互作用は無い。ｐｏｗｅｒ ｄｏｗｎ ｎｏｔｉｆｉｃａｔｉｏｎは、ＲＮＣ／ＢＳＣが、リロケーションメッセージをスリープしたいＳＧＳＮへ送信してリロケーション手順を開始することをトリガする(ステップＳ２０１)。スリープしたいＳＧＳＮは、アクティブＳＧＳＮへの切替を選択し、ｆｏｒｗａｒｄ ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔをアクティブＳＧＳＮへ転送するであろう(ステップＳ２０２)。アクティブＳＧＳＮは、ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔをＲＮＣ／ＢＳＣへ送信して、新たなＲＡＢ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｂｅａｒｅｒ)を確立するであろう。ＲＮＣ／ＢＳＣは、ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔが現在のリソースの一つのためのものであることを特定し、通信のリダイレクト(ハンドオーバに必要な全てのリソースが割り当てられる訳では無い)に備えるであろう(ステップＳ２０３)。ＲＡＢが確立された後、アクティブＳＧＳＮが、ｆｏｒｗａｒｄ ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔへ応答し、スリープしたいＳＧＳＮが、ＲＮＣ／ＢＳＣに対するｒｅｌｏｃａｔｉｏｎ ｃｏｍｍａｎｄをトリガするであろう(ステップＳ２０４)。ＲＮＣ／ＢＳＣは、ｒｅｌｏｃａｔｉｏｎ ｄｅｔｅｃｔメッセージをアクティブＳＧＳＮへ送信し、この後に、ｒｅｌｏｃａｔｉｏｎ ｃｏｍｐｌｅｔｅメッセージも送信するであろう(ステップＳ２０５)。アクティブＳＧＳＮは、ｆｏｒｗａｒｄ ｒｅｌｏｃａｔｉｏｎ ｃｏｍｐｌｅｔｅ ｎｏｔｉｆｉｃａｔｉｏｎをスリープしたいＳＧＳＮへ送信し、Ｕ−Ｐｌａｎｅをリダイレクトするためのｕｐｄａｔｅ ＰＤＰ(Ｐａｃｋｅｔ Ｄａｔａ Ｐｒｏｔｏｃｏｌ) ｃｏｎｔｅｘｔを、アクティブＳＧＳＮを介して送信するであろう(ステップＳ２０６)。最後に、スリープしたいＳＧＳＮは、ＲＮＣ／ＢＳＣとのＩｕコネクションを削減することが可能であろう(ステップＳ２０７)。
【００２０】
全てのコネクションがスリープしたいＳＧＳＮから削除された後、スリープしたいＳＧＳＮは、シャットダウン又は低電力モードへ変化でき、自ＳＧＳＮをスリーピングＳＧＳＮにする(ステップＳ２０８)。スリーピングＳＧＳＮは、所定のタイマにより又はオペレータにより手動で、ＧＴＰ又はＯ＆Ｍメッセージによるｐｏｗｅｒ ｕｐ ｎｏｔｉｆｉｃａｔｉｏｎメッセージを送信して、自ＳＧＳＮが再びオンラインとなったことを示す。
【００２１】
上記の説明に基づき、次のような文書がＧＩＳＦＩ(Ｇｌｏｂａｌ ＩＣＴ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｆｏｒｕｍ ｆｏｒ Ｉｎｄｉａ)へ提出されるであろう。
【００２２】
１．要約
移動体通信は、インドだけで無く全世界で急成長しているセクタである。このセクタは、他のセクタのＧＨＧ(Ｇｒｅｅｎ Ｈｏｕｓｅ Ｇａｓ：温室効果ガス)排出の減少を促進する一方で、その成長に伴い移動体通信セクタ自体の排出量を増加させるであろう。このセクタの持続可能な成長を保証するためには、ＧＨＧ排出を緩和する手段が提案されるべきである。本文書は、先の提案ＧＥ−２０１０００２０［１］の改訂であり、移動体通信のコアネットワーク部分に着目する。本文書が、その成果物としての２つのグリーンエネルギー・アクティビティ、“Ｓｔｕｄｙ ｏｎ ｐｏｔｅｎｔｉａｌ ｅｎｈａｎｃｅｍｅｎｔｓ ｏｆ ＩＣＴ(Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｔｅｃｈｎｏｌｏｇｙ)”に受け入れられるべきことを提案する。
【００２３】
２．序論
ＩＣＴの活用は、(ＧＥ−２０１０００１１［２］で議論される通り)他のセクタのＧＨＧ排出を減少させる効果的な方法と考えられる。しかしながら、ＩＣＴが、ＩＣＴセクタ自体のＧＨＧ排出を低減させるのは困難である。このため、ＧＨＧを減少させる更なる方法が、“グリーン”ＩＣＴのために検討されるべきである。本文書は、ＩＣＴの移動体通信部分のコアネットワークに着目するであろう。
【００２４】
ＳＭＡＲＴ２０２０[３]によれば、移動体通信は、２０２０年迄に２０１メガトンのＧＨＧを地球大気圏へ排出すると言われている(図１参照)。移動体通信は、移動体端末と、ＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋｓ)と、コアネットワークとから成る。これらの排出の大半はＲＡＮからであるものの、コアネットワークが、そのエネルギー消費及びＧＨＧ排出を低減させる対策を講じるべきである。
【００２５】
本文書では、第１に、現行のコアネットワークが、３Ｇ及びＬＴＥのために如何にして構築されるかを議論する。第２に、現行のネットワークからどのような要素が欠けているかを議論する。最後に、ＧＨＧ排出量を効率良く低減するだろうハイレベルなソリューションを提案する。
【００２６】
３．現行分析
コアネットワークのために如何にしてＧＨＧ排出を低減できるかを議論する前に、ネットワークの現行のアーキテクチャを知ることが重要である。この節では、従来の３Ｇ(３ｒｄ Ｇｅｎｅｒａｔｉｏｎ)ネットワーク及びＬＴＥ(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)ネットワークを例に挙げて、３ＧＰＰ(３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)がＧＨＧ排出を低減するために講じている対策を説明する。
【００２７】
３．１．コアネットワークの現状
図２は、３Ｇネットワークのアーキテクチャ[４](この図ではＬＴＥを省略)を示している。ネットワークアーキテクチャは、ＲＡＮと、コアネットワークとから成る。ＲＡＮは、ＲＮＣ(Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒｓ)と、３Ｇ用のＮｏｄｅＢとから成る。ＣＳ(ｃｉｒｃｕｉｔ ｓｗｉｔｃｈｅｄ)呼及びＰＳ(ｐａｃｋｅｔ ｓｗｉｔｃｈｅｄ)呼の両者が、ＲＡＮを通過し、コアネットワーク内の異なるノードへ導かれる(すなわち、ＣＳはＭＳＣ(Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｒｅ)よって提供され、ＰＳはＳＧＳＮ(Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ)によって提供される)。ＣＳ又はＰＳデータは、コアネットワークへ入力された後、処理されて適切な宛先へ送信される。
【００２８】
図３は、ＬＴＥネットワーク[５]を示している。従来の３Ｇネットワークと異なり、ＬＴＥネットワークは、ＰＳサービスのみを扱う。ＲＡＮはｅＮｏｄｅＢから成り、これらの制御はＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｉｅｓ)によって扱われる。Ｓ−ＧＷ(Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ)及びＰ−ＧＷ(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ)がユーザプレーンのトラヒックを扱い、ＭＭＥが制御パケットを扱う。ＣＳサービスが必要な場合、カバレッジが利用可能であれば、３Ｇネットワークへのフォールバックを行うことができる。
【００２９】
３．２．グリーン・コアネットワークのための現行の対策
３ＧＰＰにおいて標準化されている、グリーン・コアネットワークをもたらす方法の一つが、Ｎｅｔｗｏｒｋ Ｓｈａｒｉｎｇ(ＴＳ ２３．２５１[６])である。Ｎｅｔｗｏｒｋ Ｓｈａｒｉｎｇは、異なるオペレータが、コアネットワークの端点で同一のＲＡＮ及びノードを共有可能にする。これにより、同一エリアをカバーする重複した設備が低減される。このことは、設備及び電力消費の少ないグリーン効果を与えるように、オペレータに対し開発及び運用コストの削減をもたらす。しかしながら、既に既存のネットワークが在る場合、オペレータは、結局は設備を無駄にするはめになる。よって、このソリューションは、これを新たなエリアでの開発に適用する場合にオペレータにとって魅力的であるに過ぎない。
【００３０】
図４は、従来の３ＧＰＰネットワークのＧＣＮＷ(Ｇａｔｅｗａｙ Ｃｏｒｅ Ｎｅｔｗｏｒｋ)構成を示している。ＳＧＳＮ／ＭＳＣ／ＭＭＥは、オペレータ同士間でこれらのコアネットワークの端点で共有され、ＲＮＣ／ｅＮｏｄｅＢは、ＲＡＮのために共有される。
【００３１】
４．ギャップ分析
コアネットワークにて節電するための更なる方法も検討されるべきである。まず、現行のソリューションでは解決出来ない問題について議論する。そして、この問題に対処するための解決策を詳述する。
【００３２】
４．１．更なる節約が必要なエリア
３ＧＰＰが与える現行のＮｅｔｗｏｒｋ Ｓｈａｒｉｎｇソリューションは、設備及び運用コストを削減するための方法としては非常に有益である。しかしながら、依然として扱う必要のある、電力削減が可能なより多くのエリアを生み出すという問題がある。また、標準化の側面から、この問題に対処することが要求されるであろう。
【００３３】
深刻な問題の一つは、システムにて使用される電力が、１日を通して定常的には使用されないことである。例えば商業地域では、システムが日中に最も繁忙状態に在り、業務時間後に減少し始めるであろう。住居区域は、おそらく異なるピーク時間帯を有しており、大抵のエリアが、１日のより早い時間帯に亘って著しく低い負荷を有するであろう。
【００３４】
現行のシステムは、その負荷に応じては処理キャパシティを変更しない。これらのシステムは、ＢＨＣＡ(ｂｕｓｙ ｈｏｕｒ ｃａｌｌ ａｔｔｅｍｐｔｓ)に基づき構築されており、１日の如何なる時間においても最大キャパシティを処理可能なように運用される。このことは不必要な電力消費を招き、その対応策を、グリーン・コアネットワーク実現の要件とする。
【００３５】
４．２．ハイレベルな提案
前節で議論した要件を解決するためには、新たなソリューションが必要である。前章における要件は、システムが最大キャパシティ比して低い負荷を有する場合に電力消費を削減することであった。電力消費を削減するための幾つかの解決策は、ＣＰＵ性能を低下させること、システムを一時停止／待機モードにすること、及びシステムの電源をオフすることである。これらの適用は、ネットワークの一部には用いられていない(このケースでは、３Ｇ用のＳＧＳＮ、並びにＬＴＥ用のＭＭＥ及びＳ−ＧＷ)。しかしながら、これらのソリューションは、ネットワークにおいてターゲットノードが他のノードからアクセスされた場合に通信の問題を生み出し得る。ネットワークにおいてノードをパワーダウンさせるには、ノード同士間でのネゴシエーションが極めて重要であろう。
【００３６】
図５は、コアノードがパワーダウンする(又は、実際のトランザクションを扱わない低電力状態に入る)ことを可能にするシステムのハイレベルなアーキテクチャを示している。まず、或るコアノード(ＳＧＳＮ、ＭＭＥ又はＳ−ＧＷ)は、種々の理由(例えば、夜中にシグナリングトラヒックの数が小さいことや、ユーザの不在等)に因り“スリープ”すると決定した場合、“スリーピング宣言”を接続されるノードに対して送出するであろう。このメッセージの受信コアノードがスリーピングノードによってカバーされる全てのトラヒックを扱うことが可能な場合、スリーピングノードは、その全てのトランザクションを受信ノードへ受け渡す。よって、ユーザのトラヒックは、異なるノードを介してネットワークへ接続されたままである。今、トラヒックが残っていないのであるから、スリーピングノードは、電源を切る又は低電力状態へ遷移することが可能である。スリーピングノードは、所定のタイマ又はウェイクアップ・メッセージによって“ウェイクアップ”することが可能である。
【００３７】
５．結論
本文書を通して、コアネットワークが如何にして非効率的に電力を使用し得るかを議論した。移動体産業はインドにおいて急成長しているセクタであるから、ＧＨＧ排出の増大を回避する対策が存在すべきである。コアネットワークの不必要なエネルギー消費の除去を促進するだろうハイレベルなアーキテクチャを提案した。本文書が、その成果物としての２つのグリーンエネルギー・アクティビティ、“Ｓｔｕｄｙ ｏｎ ｐｏｔｅｎｔｉａｌ ｅｎｈａｎｃｅｍｅｎｔｓ ｏｆ ＩＣＴ”に受け入れられることを提案する。
【００３８】
６．参考文献
[１] ＧＩＳＦＩ、ＧＥ１−２０１０００２０、Ｇｒｅｅｎ ｔｈｅ ｍｏｂｉｌｅ ｃｏｒｅ ｎｅｔｗｏｒｋ、２０１０年１２月
[２] ＧＩＳＦＩ、ＧＥ１−２０１０００１１、Ｍａｋｉｎｇ ｔｈｉｎｇｓ Ｇｒｅｅｎ ｗｉｔｈ ＩＣＴ、２０１０年９月
[３] Ｔｈｅ Ｃｌｉｍａｔｅ Ｇｒｏｕｐ： Ｇｌｏｂａｌ ｅ−Ｓｕｓｔａｉｎａｂｉｌｉｔｙ Ｉｎｉｔｉａｔｉｖｅ ｒｅｐｏｒｔ、“Ｓｍａｒｔ ２０２０ Ｅｎａｂｌｉｎｇ Ｌｏｗ Ｃａｒｂｏｎ Ｅｃｏｎｏｍｙ ｉｎ ｔｈｅ Ｉｎｆｏｒｍａｔｉｏｎ Ａｇｅ”、２００８年、＜ｈｔｔｐ：／／ｗｗｗ.ｓｍａｒｔ２０２０.ｏｒｇ／ｐｕｂｌｉｃａｔｉｏｎｓ／＞
[４] ３ＧＰＰ、ＴＳ ２３．００２ ｖ９．１．０、Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ、２００９年９月
[５] ３ＧＰＰ、ＴＳ ２３．４０１ ｖ９．６．０、Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ (ＧＰＲＳ) ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ (Ｅ−ＵＴＲＡＮ) ａｃｃｅｓｓ、２０１０年９月
[６] ３ＧＰＰ、ＴＳ ２３．２５１ ｖ９．２．０、Ｎｅｔｗｏｒｋ ｓｈａｒｉｎｇ； Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ ｆｕｎｃｔｉｏｎａｌ ｄｅｓｃｒｉｐｔｉｏｎ、２０１０年３月
【００３９】
次に、本実施の形態に係るＣＮノード(すなわち、図６及び図７に示したスリーピングＳＧＳＮ)の構成例を、図８を参照して説明する。
【００４０】
図８に示すように、ＳＧＳＮ １０は、共有部１１と、決定部１２と、通知部１３と、要求部１４及び１５とを含む。
【００４１】
共有部１１は、例えば上記のＯ＆Ｍ又はＧＴＰ−Ｃメッセージを用いて、他のＳＧＳＮ(すわわち、アクティブＳＧＳＮ)との間でリソース情報を共有する。決定部１２は、上述した通りに、リソース情報に基づいてＳＧＳＮ １０をスリープさせるか否かを決定する。通知部１３は、ＳＧＳＮ １０のスリープに際して、ｐｏｗｅｒ ｄｏｗｎ ｎｏｔｉｆｉｃａｔｉｏｎをＲＮＣ／ＢＳＣ及びアクティブＳＧＳＮへ通知する。要求部１４は、上記のデタッチ／アタッチ方法に係る処理を行う。具体的には、要求部１４は、“ｒｅａｔｔａｃｈ ｒｅｑｕｉｒｅｄ”を示すデタッチ種別を伴うデタッチ要求メッセージを、ＲＮＣ／ＢＳＣを介してＳＧＳＮ １０へアッタッチしているＵＥへ送信する。要求部１５は、上記のリルーティング方法に係る処理を行う。具体的には、要求部１５は、ＲＮＣ／ＢＳＣから、リロケーションメッセージ(図７のステップＳ２０１に示したＲｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージ)を、ｐｏｗｅｒ ｄｏｗｎ ｎｏｔｉｆｉｃａｔｉｏｎへの応答として受信する。そして、要求部１５は、Ｆｏｒｗａｒｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを、アクティブＳＧＳＮの一つへ送信する。
【００４２】
これらのユニット１１〜１２は、例えば、他のＳＧＳＮ及びＲＮＣ／ＢＳＣと通信するインタフェースと、これらのインタフェースを制御して、図６及び図７に示した処理或いはこれと同等の処理を実行するコントローラとで構成できる。
【００４３】
なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。
【００４４】
この出願は、２０１１年２月２４日に出願された日本出願特願２０１１−０３８７７９を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【００４５】
上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【００４６】
(付記１)
どのコアノードがスリープすべきかを決定する方法
スリーピングノードを決定するための幾つかの方法がある。オペレータは、ＳＧＳＮのリソースを予め定義したＯ＆Ｍメッセージを介してＯ＆Ｍターミナル経由でチェックすることによって、スリーピングノードを決定できる。或いは、ＳＧＳＮは、これらのためのリソースを、定義したＧＴＰ−Ｃ又はＯ＆Ｍメッセージを介してリソースをチェックすることによってチェックできる。
【００４７】
(付記２)
ｐｏｗｅｒ ｄｏｗｎ ｎｏｔｉｆｉｃａｔｉｏｎ及びｐｏｗｅｒ ｕｐ ｎｏｔｉｆｉｃａｔｉｏｎメッセージ
ｐｏｗｅｒ ｄｏｗｎ／ｕｐ ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、メッセージをＲＡＮＡＰ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ)、ＧＴＰ−Ｃ及びＯ＆Ｍメッセージ上で定義することによって送信できる。ｐｏｗｅｒ ｕｐメッセージは、所定のタイマ、災害、他のＳＧＳＮ／ＲＮＣからの過負荷メッセージ、又はオペレータにより手動にてトリガされ得る。
【００４８】
(付記３)
パワーダウン準備
スリープしたいノードが効率良くパワーダウンするために、新たなコネクションを遮断し、切断又はハンドオーバに関連するメッセージのみを受け付けるであろう。全てのコネクションが一旦転送又は切断されると、スリーピングノードはパワーダウンするであろう。
【００４９】
(付記４)
Ｓｅｒｖｉｎｇ ＲＮＳ(Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｓｕｂｓｙｓｔｅｍ)リロケーション手順の再利用
本手順は、ソースＲＮＣとターゲットＲＮＣとが同一のＲＮＣであるため、Ｓｅｒｖｉｎｇ ＲＮＳリロケーションとは異なる。このため、ＲＮＣは、不必要なＲＮＣ内部メッセージを省略し、不必要なリソースを確保してしまうのを防止できるであろう。ＲＮＣは、同一呼に属するリロケーションメッセージを、ＲＮＣにて送信／受信されるｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｉｒｅｄメッセージとｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージとを比較することによって特定できるであろう。 
【符号の説明】
【００５０】
１０  ＳＧＳＮ
１１  共有部
１２  決定部
１３  通知部
１４, １５  要求部
【図１】
0005582257.tif 000002
【図２】
0005582257.tif 000003
【図３】
0005582257.tif 000004
【図４】
0005582257.tif 000005
【図５】
0005582257.tif 000006
【図６】
0005582257.tif 000007
【図７】
0005582257.tif 000008
【図８】
0005582257.tif 000009