特許第6554430号(P6554430)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社NTTドコモの特許一覧

<>
  • 特許6554430-在圏情報管理方法および通信システム 図000002
  • 特許6554430-在圏情報管理方法および通信システム 図000003
  • 特許6554430-在圏情報管理方法および通信システム 図000004
  • 特許6554430-在圏情報管理方法および通信システム 図000005
  • 特許6554430-在圏情報管理方法および通信システム 図000006
  • 特許6554430-在圏情報管理方法および通信システム 図000007
  • 特許6554430-在圏情報管理方法および通信システム 図000008
  • 特許6554430-在圏情報管理方法および通信システム 図000009
  • 特許6554430-在圏情報管理方法および通信システム 図000010
  • 特許6554430-在圏情報管理方法および通信システム 図000011
  • 特許6554430-在圏情報管理方法および通信システム 図000012
  • 特許6554430-在圏情報管理方法および通信システム 図000013
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6554430
(24)【登録日】2019年7月12日
(45)【発行日】2019年7月31日
(54)【発明の名称】在圏情報管理方法および通信システム
(51)【国際特許分類】
   H04W 8/08 20090101AFI20190722BHJP
   H04W 36/08 20090101ALI20190722BHJP
【FI】
   H04W8/08
   H04W36/08
【請求項の数】5
【全頁数】15
(21)【出願番号】特願2016-37693(P2016-37693)
(22)【出願日】2016年2月29日
(65)【公開番号】特開2017-157949(P2017-157949A)
(43)【公開日】2017年9月7日
【審査請求日】2018年8月14日
(73)【特許権者】
【識別番号】392026693
【氏名又は名称】株式会社NTTドコモ
(74)【代理人】
【識別番号】100088155
【弁理士】
【氏名又は名称】長谷川 芳樹
(74)【代理人】
【識別番号】100113435
【弁理士】
【氏名又は名称】黒木 義樹
(74)【代理人】
【識別番号】100121980
【弁理士】
【氏名又は名称】沖山 隆
(74)【代理人】
【識別番号】100128107
【弁理士】
【氏名又は名称】深石 賢治
(72)【発明者】
【氏名】山▲崎▼ 健生
(72)【発明者】
【氏名】岩科 滋
(72)【発明者】
【氏名】清水 雅純
【審査官】 横田 有光
(56)【参考文献】
【文献】 特開2009−206766(JP,A)
【文献】 特開2012−039318(JP,A)
【文献】 特開2004−056255(JP,A)
【文献】 特開2008−278532(JP,A)
【文献】 米国特許出願公開第2014/0105174(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24− 7/26
H04W 4/00−99/00
3GPP TSG RAN WG1−4
SA WG1−4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
予め割り当てられたエリアに在圏している端末を収容し端末に係る処理を行う複数の処理サーバと、前記複数の処理サーバのエリアにわたって端末がどの処理サーバに収容されているかの情報を記憶する在圏DBと、を含んで構成される通信システム、において実行される在圏情報管理方法であって、
前記処理サーバは、自機に設けられた在圏キャッシュであって端末がどの処理サーバに収容されているかの情報を記憶した当該在圏キャッシュを参照して、自機のエリアに在圏する端末又は当該処理サーバによる通信に係る相手先端末の情報を取得できない場合、前記相手先端末の情報を前記在圏DBに問い合わせることで前記相手先端末の情報を取得して自機の在圏キャッシュに記憶し、
前記在圏DBは、前記相手先端末の情報を問い合わせてきた処理サーバを、当該相手先端末を捕捉している捕捉エッジとして、当該相手先端末に対応付けて記憶し、
前記在圏DBは、ある端末のハンドオーバーが通知された場合、ハンドオーバーが生じた前記端末の捕捉エッジを記憶内容から特定し、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知し、
前記捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された前記端末の在圏情報を更新し、前記端末の捕捉を継続する、
ことを特徴とする在圏情報管理方法。
【請求項2】
予め割り当てられたエリアに在圏している端末を収容し端末に係る処理を行う複数の処理サーバ、を含んで構成される通信システム、において実行される在圏情報管理方法であって、
ある端末のハンドオーバーが生じた場合、ハンドオーバー元の処理サーバは、ネットワークから信号に基づき前記端末のハンドオーバーを検出し、自機に設けられた在圏キャッシュであって端末がどの処理サーバに収容されているかの情報および当該端末を捕捉している捕捉エッジの情報を記憶した当該在圏キャッシュから、前記ハンドオーバーが生じた前記端末を捕捉している捕捉エッジを特定し、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知し、
前記捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された前記端末の在圏情報を更新し、前記端末の捕捉を継続する、
ことを特徴とする在圏情報管理方法。
【請求項3】
前記捕捉エッジは、
前記新たな在圏情報が通知されたとき、自機の在圏キャッシュに記憶された元の在圏情報に当該新たな在圏情報を追加し、
前記ハンドオーバーが完了したときに、自機の在圏キャッシュから元の在圏情報を削除する、
ことを特徴とする請求項1又は2に記載の在圏情報管理方法。
【請求項4】
予め割り当てられたエリアに在圏している端末を収容し端末に係る処理を行う複数の処理サーバと、前記複数の処理サーバのエリアにわたって端末がどの処理サーバに収容されているかの情報を記憶する在圏DBと、を含んで構成される通信システムであって、
前記処理サーバのそれぞれには、端末がどの処理サーバに収容されているかの情報を記憶した在圏キャッシュが設けられており、
前記処理サーバは、自機の在圏キャッシュを参照して、自機のエリアに在圏する端末又は当該処理サーバによる通信に係る相手先端末の情報を取得できない場合、前記相手先端末の情報を前記在圏DBに問い合わせることで前記相手先端末の情報を取得して自機の在圏キャッシュに記憶するよう構成され、
前記在圏DBは、前記相手先端末の情報を問い合わせてきた処理サーバを、当該相手先端末を捕捉している捕捉エッジとして、当該相手先端末に対応付けて記憶するよう構成され、
前記在圏DBは、ある端末のハンドオーバーが通知された場合、ハンドオーバーが生じた前記端末の捕捉エッジを記憶内容から特定し、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知するよう構成され、
前記捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された前記端末の在圏情報を更新し、前記端末の捕捉を継続するよう構成される、
ことを特徴とする通信システム。
【請求項5】
予め割り当てられたエリアに在圏している端末を収容し端末に係る処理を行う複数の処理サーバ、を含んで構成される通信システムであって、
前記処理サーバのそれぞれには、端末がどの処理サーバに収容されているかの情報および当該端末を捕捉している捕捉エッジの情報を当該端末に対応付けて記憶した在圏キャッシュが設けられており、
ある端末のハンドオーバーが生じた場合、ハンドオーバー元の処理サーバは、ネットワークから信号に基づき前記端末のハンドオーバーを検出し、自機の在圏キャッシュから、前記ハンドオーバーが生じた前記端末を捕捉している捕捉エッジを特定し、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知するよう構成され、
前記捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された前記端末の在圏情報を更新し、前記端末の捕捉を継続するよう構成される、
ことを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、エッジコンピューティングを移動体通信網に適用した場合の在圏情報管理方法および通信システムに関する。
【背景技術】
【0002】
従来から、ネットワーク上において端末(スマートフォンなど)の近くにあるエッジサーバに処理を分散させることで、地球規模で集中的配備されたクラウドコンピューティングの環境と比べて通信遅延を短縮するエッジコンピューティングという技術が考えられている(非特許文献1)。
【先行技術文献】
【非特許文献】
【0003】
【非特許文献1】“エッジコンピューティング構想”、[online]、NTT持株会社ニュースリリース、[平成27年6月18日検索]、インターネット<http://www.ntt.co.jp/news2014/1401/140123a.html>
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記のエッジコンピューティングを移動体通信網に適用する場合、移動体通信網では端末が移動することで端末の在圏情報が変化するという特性(ハンドオーバーの発生)があるため、時々刻々と変化する在圏情報を適切に管理することが必要となる。従来より、端末の在圏情報を一括管理する在圏DBをコアネットワークの奥に設けて集中管理する技術が知られている。しかし、コアネットワークの奥の在圏DBに端末の在圏情報を毎回問い合わせるのは、処理の遅延を招くという課題がある。
【0005】
そこで、本発明は、エッジコンピューティングを移動体通信網に適用する場合にハンドオーバー時の処理の遅延を抑制することを目的とする。
【課題を解決するための手段】
【0006】
1つの態様として、本発明に係る在圏情報管理方法は、予め割り当てられたエリアに在圏している端末を収容し端末に係る処理を行う複数の処理サーバと、前記複数の処理サーバのエリアにわたって端末がどの処理サーバに収容されているかの情報を記憶する在圏DBと、を含んで構成される通信システム、において実行される在圏情報管理方法であって、前記処理サーバは、自機に設けられた在圏キャッシュであって端末がどの処理サーバに収容されているかの情報を記憶した当該在圏キャッシュを参照して、自機のエリアに在圏する端末又は当該処理サーバによる通信に係る相手先端末の情報を取得できない場合、前記相手先端末の情報を前記在圏DBに問い合わせることで前記相手先端末の情報を取得して自機の在圏キャッシュに記憶し、前記在圏DBは、前記相手先端末の情報を問い合わせてきた処理サーバを、当該相手先端末を捕捉している捕捉エッジとして、当該相手先端末に対応付けて記憶し、前記在圏DBは、ある端末のハンドオーバーが通知された場合、ハンドオーバーが生じた前記端末の捕捉エッジを記憶内容から特定し、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知し、前記捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された前記端末の在圏情報を更新し、前記端末の捕捉を継続することを特徴とする。
【0007】
上記の在圏情報管理方法では、処理サーバは、自機の在圏キャッシュを参照して、自機のエリアに在圏する端末又は当該処理サーバによる通信に係る相手先端末の情報を取得できない場合には、相手先端末の情報を在圏DBに問い合わせることで相手先端末の情報を取得して自機の在圏キャッシュに記憶する。これにより、相手先端末の情報が自機の在圏キャッシュに記憶されていない場合でも相手先端末の情報を取得でき、当該相手先端末の情報を用いて速やかに相手先端末にアクセスできる。もちろん、自機の在圏キャッシュから相手先端末の情報を取得できれば、当該相手先端末の情報を用いて速やかに相手先端末にアクセスすることができ、従来のように毎回在圏DBへ問い合わせることなく、迅速な処理を実現することができる。
【0008】
一方、在圏DBは、相手先端末の情報を問い合わせてきた処理サーバを、当該相手先端末を捕捉している捕捉エッジとして当該相手先端末に対応付けて記憶しておくことができ、ある端末のハンドオーバーが在圏DBに通知されたとき、在圏DBは、ハンドオーバーが生じた当該端末の捕捉エッジを記憶内容から特定して、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知することができる。そして、捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された当該端末の在圏情報を更新し、当該端末の捕捉を継続する。
【0009】
このようにして、エッジコンピューティングを移動体通信網に適用する場合にハンドオーバー時の処理の遅延を抑制することができる。
【0010】
別の態様として、本発明に係る在圏情報管理方法は、予め割り当てられたエリアに在圏している端末を収容し端末に係る処理を行う複数の処理サーバ、を含んで構成される通信システム、において実行される在圏情報管理方法であって、ある端末のハンドオーバーが生じた場合、ハンドオーバー元の処理サーバは、ネットワークから信号に基づき前記端末のハンドオーバーを検出し、自機に設けられた在圏キャッシュであって端末がどの処理サーバに収容されているかの情報および当該端末を捕捉している捕捉エッジの情報を記憶した当該在圏キャッシュから、前記ハンドオーバーが生じた前記端末を捕捉している捕捉エッジを特定し、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知し、前記捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された前記端末の在圏情報を更新し、前記端末の捕捉を継続することを特徴とする。
【0011】
上記の在圏情報管理方法では、処理サーバに設けられた在圏キャッシュには、端末がどの処理サーバに収容されているかの情報に加え、当該端末を捕捉している捕捉エッジの情報が記憶されており、ある端末のハンドオーバーが生じた場合、ハンドオーバー元の処理サーバは、ネットワークから信号に基づき当該端末のハンドオーバーを検出し、ハンドオーバーが生じた当該端末を捕捉している捕捉エッジを自機の在圏キャッシュから特定して、該捕捉エッジに対しハンドオーバー後の当該端末の新たな在圏情報を通知する。そして、捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された当該端末の在圏情報を更新し、当該端末の捕捉を継続する。
【0012】
このようにして、エッジコンピューティングを移動体通信網に適用する場合にハンドオーバー時の処理の遅延を抑制することができる。
【0013】
なお、上記の1つの態様および別の態様ともに、上記の捕捉エッジによる在圏キャッシュに記憶された端末の在圏情報の更新方法について、捕捉エッジは、新たな在圏情報が通知されたとき、自機の在圏キャッシュに記憶された元の在圏情報に当該新たな在圏情報を追加し、ハンドオーバーが完了したときに、自機の在圏キャッシュから元の在圏情報を削除してもよい。この場合、ハンドオーバーが失敗したときのリカバリーが簡易になるという利点がある。ただし、捕捉エッジは、新たな在圏情報が通知されたときに元の在圏情報を当該新たな在圏情報に置換する方法を採用してもよい。
【0014】
ところで、在圏情報管理方法に係る本発明は、通信システムに係る発明として以下のように記述することができ、同様の作用および効果を奏する。
【0015】
1つの態様に係る通信システムは、予め割り当てられたエリアに在圏している端末を収容し端末に係る処理を行う複数の処理サーバと、前記複数の処理サーバのエリアにわたって端末がどの処理サーバに収容されているかの情報を記憶する在圏DBと、を含んで構成される通信システムであって、前記処理サーバのそれぞれには、端末がどの処理サーバに収容されているかの情報を記憶した在圏キャッシュが設けられており、前記処理サーバは、自機の在圏キャッシュを参照して、自機のエリアに在圏する端末又は当該処理サーバによる通信に係る相手先端末の情報を取得できない場合、前記相手先端末の情報を前記在圏DBに問い合わせることで前記相手先端末の情報を取得して自機の在圏キャッシュに記憶するよう構成され、前記在圏DBは、前記相手先端末の情報を問い合わせてきた処理サーバを、当該相手先端末を捕捉している捕捉エッジとして、当該相手先端末に対応付けて記憶するよう構成され、前記在圏DBは、ある端末のハンドオーバーが通知された場合、ハンドオーバーが生じた前記端末の捕捉エッジを記憶内容から特定し、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知するよう構成され、前記捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された前記端末の在圏情報を更新し、前記端末の捕捉を継続するよう構成されることを特徴とする。
【0016】
また、別の態様に係る通信システムは、予め割り当てられたエリアに在圏している端末を収容し端末に係る処理を行う複数の処理サーバ、を含んで構成される通信システムであって、前記処理サーバのそれぞれには、端末がどの処理サーバに収容されているかの情報および当該端末を捕捉している捕捉エッジの情報を当該端末に対応付けて記憶した在圏キャッシュが設けられており、ある端末のハンドオーバーが生じた場合、ハンドオーバー元の処理サーバは、ネットワークから信号に基づき前記端末のハンドオーバーを検出し、自機の在圏キャッシュから、前記ハンドオーバーが生じた前記端末を捕捉している捕捉エッジを特定し、該捕捉エッジに対しハンドオーバー後の前記端末の新たな在圏情報を通知するよう構成され、前記捕捉エッジは、通知された新たな在圏情報をもって、自機の在圏キャッシュに記憶された前記端末の在圏情報を更新し、前記端末の捕捉を継続するよう構成されることを特徴とする。
【発明の効果】
【0017】
本発明によれば、エッジコンピューティングを移動体通信網に適用する場合にハンドオーバー時の処理の遅延を抑制することができる。
【図面の簡単な説明】
【0018】
図1】第1実施形態の通信システムの構成例を示す図である。
図2】(a)〜(c)は在圏キャッシュのデータ例を示す図である。
図3】(a)〜(c)は在圏DBのデータ例を示す図である。
図4】VM等のハードウェア構成例を示す図である。
図5】UEのハンドオーバーを伴わない場合の処理例を示すフロー図である。
図6】UEのハンドオーバーを伴う場合の処理例を示すフロー図である。
図7】第2実施形態の通信システムの構成例を示す図である。
図8】(a)〜(c)はハンドオーバー元(VM3)の在圏キャッシュのデータ例を示す図である。
図9】各VMが備えるVMとeNBとの対応テーブルのデータ例を示す図である。
図10】(a)〜(c)は捕捉エッジ(VM1)の在圏キャッシュのデータ例を示す図である。
図11】移動検出機が備えるUE−収容VM対応テーブルのデータ例を示す図である。
図12】ネットワークがUEのハンドオーバーを検出する場合の処理例を示すフロー図である。
【発明を実施するための形態】
【0019】
以下、図面と共に本発明に係る在圏情報管理方法および通信システムの実施形態を順に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。
【0020】
[第1実施形態]
図1には、第1実施形態の通信システム1の構成例を示す。通信システム1は、エッジコンピューティングを移動体通信網に適用した場合の通信システムであり、図1に示すように、相互に直接又は間接的に接続された複数の交換機(Switch Board、以下「SW」と称する)10と、PDN(Public Data Network:公衆データ網)20と、移動体通信網における基地局に相当するeNodeB(以下「eNB」と称する)30と、複数の仮想マシン(Virtual Machine、以下「VM」と称する)40と、複数の端末(User Equipment、以下「UE」と称する)50と、複数のUEの在圏情報を一括管理する在圏DB60と、を含んで構成される。説明の便宜上、図1に示すように、複数のSWはSW1〜SW4と図示し、複数のVMはVM1〜VM3と図示し、複数のeNBはeNB1〜eNB3と図示し、複数のUEはUE1,UE2と図示している。この構成例では、在圏DB60はPDN20に接続され、SW3はeNB1とeNB2に接続され、SW4はeNB3に接続されている。
【0021】
VM1、VM2、VM3は、それぞれeNB1、eNB2、eNB3に接続され、それぞれに予め割り当てられたエリアに在圏するUEを収容し、エッジコンピューティングにおけるエッジとしてUEからのサービス要求に応じたさまざまな処理を実行する。例えば、VMは、在圏するUEで動作するアプリケーションから、他のUEで動作するアプリケーションとの通信を要求された場合、当該他のUEを収容する他のVMを特定して、当該他のVMとの通信を確立する処理等を実行する。このような処理を実行するために、VM1〜3はそれぞれ、UEがどのVMに収容されているかの情報を記憶した在圏キャッシュ70を備える。
【0022】
図2(a)〜図2(c)には、在圏キャッシュ70のデータ例を示しており、UEと、該UEが収容されているVM(図2では「エッジ」と表記)とが対応付けて記憶される。なお、図2(a)〜図2(c)は、後述する図5および図6の処理において捕捉エッジとなるVM1の在圏キャッシュ70のデータ例を示している。
【0023】
図3(a)〜図3(c)には、在圏DB60のデータ例を示しており、UEと、該UEが収容されているVM(図3では「エッジ」と表記)と、該UEを捕捉しているVM(図3では「捕捉エッジ」と表記)とが対応付けて記憶される。
【0024】
なお、図1のSW10、eNB30、VM40、UE50、在圏DB60は、通信機能を備えた一般的なコンピュータにより構成される。例えば、図4に示すように、これらの装置(装置100と総称する)は、一又は複数のCPU101、主記憶装置であるRAM(Random Access Memory)102及びROM(Read Only Memory)103、通信を行うための通信モジュール104(Transmitter又はReceiver)、並びにハードディスク等の補助記憶装置105(Memory)等のハードウェアを備えた1つ又は複数のコンピュータにより構成される。装置100では、図4に示すCPU101、RAM102等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、CPU101の制御のもとで通信モジュール104等を動作させるとともに、RAM102や補助記憶装置105におけるデータの読み出しおよび書き込みを行うことで、各部における一連の機能が実現される。
【0025】
なお、CPU101などのプロセッサ(Processor)は、その機能の全部または一部を専用の集積回路(IC:integrated circuit)により実行するよう構成してもよい。例えば、画像処理や通信制御を行うための専用の集積回路を構築することにより上記機能を実行するようにしてもよい。
【0026】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
【0027】
また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線(DSL)などの有線技術及び/又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び/又は無線技術は、伝送媒体の定義内に含まれる。
【0028】
(UEのハンドオーバーを伴わない場合の処理例)
まず、図5を用いてUEのハンドオーバーを伴わない場合の処理例を説明する。
【0029】
VM1が、在圏するUE1から、UE2との通信を要求された場合、VM1は、まずは自機の在圏キャッシュを検索する(ステップS1)。即ち、VM1は、まず自機の在圏キャッシュを参照することで、相手先端末UE2の在圏情報の取得を試みる。しかし、1回目は図2(a)に示すようにVM1の在圏キャッシュにUE2の在圏情報が無いため、VM1は、在圏DBにUE2の在圏情報を問い合わせる(ステップS2)。
【0030】
問合せを受けた在圏DBは、図3(a)に示す自機のデータから、UE2がVM3に収容されている旨の在圏情報を得て、当該在圏情報をVM1に応答し(ステップS3)、図3(b)に示すように、UE2の在圏情報を問い合わせてきたVM1をUE2の捕捉エッジとして登録する(ステップS4)。上記応答を受けたVM1は、図2(b)に示すようにUE2の在圏情報(UE2がVM3に収容されている旨の情報)を自機の在圏キャッシュに登録し(ステップS5)、VM3と通信する(ステップS6)。
【0031】
そして、2回目以降は、VM1がUE1からUE2との通信を要求された場合、VM1は、図2(b)の自機の在圏キャッシュを検索し(ステップS7)、自機の在圏キャッシュからUE2の在圏情報を得て(ステップS8)、VM3と通信する(ステップS9)。これにより、VM1は、2回目以降は、在圏DBへの問合せを行うことなく、速やかに、UE1からの要求に応じた処理を行うことができる。
【0032】
(UEのハンドオーバーを伴う場合の処理例)
次に、図6を用いて、UEのハンドオーバーを伴う場合、即ち、相手先端末であるUE2がVM3からVM2へハンドオーバーする場合の処理例を説明する。
【0033】
VM1が、在圏するUE1から、UE2との通信を要求された場合、VM1は、図2(b)の自機の在圏キャッシュを検索し(ステップS11)、自機の在圏キャッシュからUE2の在圏情報を得て(ステップS12)、VM3と通信する(ステップS13)。しかし、このときVM3からVM2へのUE2の移動処理(ハンドオーバー)が実行されている(ステップS14)ため、VM3はUE2の不在通知をVM1へ返送する(ステップS15)。この不在通知を受けたVM1は通信を待機する。なお、ステップS14の処理は、例えば、エラスティックコア技術によるサーバステートの共有処理を含み、VM2においてUE2に関する在圏キャッシュ作成が実行される。ハンドオーバー完了後は、VM3においてUE2に関する在圏キャッシュが破棄される。
【0034】
そして、ハンドオーバー完了後に、VM2は、UE2がVM2のエリアへ移動完了した旨を在圏DBへ通知する(ステップS16)。在圏DBは、図3(b)に示す自機のデータから、移動完了したUE2を捕捉している捕捉エッジとしてVM1を特定し、VM1に対しUE2がVM2のエリアへ移動完了した旨を通知し(ステップS17)、そして、図3(c)に示すようにUE2の在圏情報(在圏しているVM)をVM3からVM2に更新する(ステップS18)。
【0035】
ステップS17の通知を受けたVM1は、図2(c)に示すように自機の在圏キャッシュに記憶されたUE2の在圏情報(在圏しているVM)をVM3からVM2に更新し(ステップS19)、待機していた通信(UE2を収容するVM(この時点ではVM2)との通信)を再開する(ステップS20)。
【0036】
そして、ステップS19の在圏キャッシュ更新後に発生した通信については、VM1がUE2との通信をUE1から要求されると、VM1は、図2(c)に示す自機の在圏キャッシュを検索し(ステップS21)、自機の在圏キャッシュからUE2の在圏情報(VM2)を得て(ステップS22)、VM2との通信を実行する(ステップS23)。
【0037】
以上のように、第1実施形態によれば、VM1は、捕捉しているUE2のハンドオーバーが発生した場合であっても、ハンドオーバー先のVM(VM2)の情報を自動的に得て、UE2の捕捉を継続することができる。そのため、UE1からの要求に応じた処理を速やかに実行でき、ハンドオーバー時の処理の遅延を抑制することができる。
【0038】
なお、図6のステップS16では、ハンドオーバー先のVM(VM2)が、在圏DBにUE2の移動を通知する例を説明したが、ハンドオーバー元のVM(VM3)が在圏DBに通知してもよいし、ネットワークでUE2の移動を検出して在圏DBに通知してもよい。同様に、S17にて捕捉エッジに移動を通知する処理を在圏DBによって行っているが、この処理は移動元VM又は移動先VMによって行っても良い。
【0039】
[第2実施形態]
第2実施形態では、相手先端末(UE2)のハンドオーバーをネットワークで検出して、捕捉エッジ(VM1)が、在圏DBへの問合せを行うことなくハンドオーバー先(VM2)の情報を得るための一連の処理を説明する。
【0040】
図7には、第2実施形態における通信システム1Sの構成例を示す。図7に示すように、通信システム1Sは、EPC(Evolved Packet Core)80と、ネットワーク信号に基づきUEの移動を検出する移動検出機90とをさらに備え、eNBとして、eNB1、2−1、2−2、3−1、3−2を備える点が、第1実施形態の通信システム1(図1)と異なる。EPC80はPDN20に接続され、移動検出機90はEPC80に接続されている。eNB1はVM1に、eNB2−1、2−2はVM2に、eNB3−1、3−2はVM3に、それぞれ接続され、後述の図12の処理開始時点では、UE1はeNB1に無線接続されVM1に収容されており、UE2はeNB3−1に無線接続されVM3に収容されている。
【0041】
図8(a)〜図8(c)には、ハンドオーバー元(VM3)の在圏キャッシュ70のデータ例を示しており、UEと、該UEが収容されているVM(図8では「エッジ」と表記)とに加え、該UEを捕捉しているVM(図8では「捕捉エッジ」と表記)がさらに対応付けて記憶される。
【0042】
図9には、各VMが備える、VMと該VMにより管理されるeNBとの対応テーブルのデータ例を示している。
【0043】
図10(a)〜図10(c)には、捕捉エッジ(VM1)の在圏キャッシュ70のデータ例を示しており、前述した図8と同様に、UEと、該UEが収容されているVM(図8では「エッジ」と表記)と、該UEを捕捉しているVM(図8では「捕捉エッジ」と表記)とが対応付けて記憶される。
【0044】
図11には、移動検出機90が備える、UEと該UEが収容されているVM(図8では「エッジ」と表記)との対応テーブルのデータ例を示している。
【0045】
(ネットワークがUEのハンドオーバーを検出する場合の処理例)
次に、図12を用いて、ネットワークがUEのハンドオーバーを検出する場合の処理例を説明する。ここでは、VM1が捕捉しているUE2が、VM3からVM2へハンドオーバーする例を説明する。
【0046】
移動するUE2が、EPC80を含むモバイルコアネットワークにハンドオーバー制御信号を送信すると(ステップS31)、モバイルコアネットワークから移動検出機に対し、eNB3−1からeNB2−2へのUE2のハンドオーバー開始が通知され(ステップS32)、モバイルコアネットワークでは通常のハンドオーバー処理が実行される(ステップS33)。
【0047】
移動検出機は、ステップS32の通知に基づきUE2の移動(eNB3−1からeNB2−2へのハンドオーバー)を検出し(ステップS34)、図11のテーブルを参照してUE2の在圏エッジとして「VM3」を特定し、VM3に対しeNB3−1からeNB2−2へのUE2のハンドオーバーを通知する(ステップS35)。
【0048】
ステップS35の通知を受けたVM3は、自機が備える図9のテーブルを参照して、UE2のハンドオーバー先であるeNB2−2を管理する移動先VMを検索し、移動先VMとして「VM2」を特定する(ステップS36)。そして、VM3は、特定されたVM2に対しUE2の移動通知および自機の在圏キャッシュ情報の転送を行い(ステップS37)、UE2の捕捉エッジであるVM1に対しUE2の移動通知を行い(ステップS38)、在圏DBに対しUE2の在圏情報の更新を要求する(ステップS39)。
【0049】
さらに、VM3は、図8(a)の自機の在圏キャッシュにおけるUE2の所在を図8(b)のように「VM2、VM3」に更新する(ステップS40)。ここでの「VM2、VM3」は、UE2がVM2、VM3のうちどちらかに在圏していることを意味する。ステップS37の通知を受けたVM2は、自機の在圏キャッシュに、UE2のレコードとUE2の捕捉エッジ(VM1)に在圏しているUEのレコードとをコピーすることで(ステップS41)、自機の在圏キャッシュを最新状態に更新する。その後、VM3とVM2との間で、例えばエラスティックコア技術によるサーバステートの共有処理を含む移動処理が実行される(ステップS42)。
【0050】
一方、ステップS38の通知を受けた捕捉エッジ(VM1)は、図10(a)の自機の在圏キャッシュにおけるUE2に関するレコードを、図10(b)のようにUE2がVM2、VM3のうちどちらかに在圏している旨に更新する(ステップS43)。また、ステップS39の要求を受けた在圏DBは、UE2の所在をVM3から「VM2、VM3」(VM2、VM3のうちどちらかに在圏)に更新する(ステップS44)。
【0051】
その後、ステップS33のハンドオーバー処理が正常終了すると、モバイルコアネットワークから移動検出機へハンドオーバー成功通知が送信され(ステップS45)、移動検出機はハンドオーバー成功通知を、在圏DB、捕捉エッジ(VM1)、ハンドオーバー先のVM2、ハンドオーバー元のVM3、のそれぞれに送信する(ステップS46〜S49)。そして、在圏DBは、UE2の所在を「VM2、VM3」(VM2、VM3のうちどちらかに在圏)からハンドオーバー先の「VM2」に更新し(ステップS50)、捕捉エッジ(VM1)は、図10(b)の自機の在圏キャッシュにおけるUE2に関するレコードを、図10(c)のようにUE2がVM2に在圏している旨に更新する(ステップS51)。また、ハンドオーバー先のVM2は、自機の在圏キャッシュにおけるUE2の所在を「VM2、VM3」からVM2に更新し(ステップS52)、ハンドオーバー元のVM3は、図8(c)のように自機の在圏キャッシュからUE2のレコードを削除する(ステップS53)。
【0052】
以上のように、第2実施形態によれば、ネットワークがUEのハンドオーバーを検出する場合であっても、捕捉エッジ(VM1)は、在圏DBへの問合せを行うことなく、ハンドオーバー先のVM(VM2)の情報を自動的に得て、UE2の捕捉を継続することができる。そのため、UE1からの要求に応じた処理を速やかに実行でき、ハンドオーバー時の処理の遅延を抑制することができる。
【0053】
なお、ステップS33のハンドオーバー処理が失敗した場合の処理は、図12に示していないが、モバイルコアネットワークから移動検出機へハンドオーバー失敗通知が送信され、移動検出機はハンドオーバー失敗通知を、在圏DB、捕捉エッジ(VM1)、ハンドオーバー先のVM2、ハンドオーバー元のVM3、のそれぞれに送信する。そして、在圏DBは、UE2の所在をVM3に戻し、捕捉エッジ(VM1)は、自機の在圏キャッシュにおけるUE2に関するレコードを、UE2がVM3に在圏している旨に戻し、ハンドオーバー先のVM2は、自機の在圏キャッシュからUE2のレコードを削除し、ハンドオーバー元のVM3は、自機の在圏キャッシュにおけるUE2の所在をVM3に戻す。このように、図12の処理のようにハンドオーバー元(VM3)の情報を残しておく態様では、ハンドオーバーが失敗したときのリカバリー処理は非常に簡易である。
【0054】
ただし、図12の処理のようにハンドオーバー元(VM3)の情報を残しておく態様は必須ではなく、ハンドオーバー元(VM3)の情報を残さない態様を採用してもよい。その場合、図12におけるステップS45〜S53の処理(ハンドオーバー元の情報を削除する処理)は不要となり、その代わり、在圏DBや在圏キャッシュのハンドオーバー前の情報を保管しておき、ハンドオーバーが失敗した場合に在圏DBや在圏キャッシュをハンドオーバー前の情報に戻すための処理が必要となる。
【0055】
また、上記の第1、第2実施形態では、在圏DBとそこに記憶されるIPアドレスによるルーティングを制御する実装を例示したが、これ以外の実装、例えばSDNコントローラによる「IP以外のルーティング」を用いてもよい。その場合、VMの近くにSDNコントローラを設けて、ハンドオーバーを検出し次第、SDNコントローラによって、接続元VMから接続先VMへのフローを切り替える実装を採用することができる。
【0056】
また、上記の第1、第2実施形態では、在圏DBがコアネットワークの奥に設けられた例を説明したが、在圏DBとしては、随所に分散している分散DBを使っても良い。
【0057】
また、上記の第1、第2実施形態では、本発明に係る処理サーバが仮想マシン(VM)により構成される例を説明したが、本発明に係る処理サーバは、仮想マシン(VM)以外のサーバにより実装されてもよい。
【0058】
なお、本明細書で説明した「情報」は、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【0059】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【0060】
本明細書で説明した各態様/実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【0061】
本明細書で説明した各態様/実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知(例えば、「Xであること」の通知)は、明示的に行うものに限られず、暗黙的(例えば、当該所定の情報の通知を行わない)ことによって行われてもよい。
【0062】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【符号の説明】
【0063】
1、1S…通信システム、10…SW、20…PDN、30…eNB、40…VM(処理サーバ)、50…UE、60…在圏DB、70…在圏キャッシュ、80…EPC、90…移動検出機、100…装置、101…CPU、102…RAM、103…ROM、104…通信モジュール、105…補助記憶装置。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12