以下、本発明の実施形態を説明する。各実施形態は例示であり、本発明は各実施形態に限定されるものではない。
<第1の実施形態>
以下、本実施形態による通信システムとして、LTE(Long Term Evolution)の通信システムの例を示す。ただし、本発明が適用される通信システムはLTEに限定されない。例えば、本発明は、GPRS(General Packet Radio Service)、UMTS(Universal Mobile Telecommunication System)、WiMAX(Worldwide Interoperability for Microwave Access)等にも適用可能である。
本発明の第1の実施形態について、図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。
図1は、第1の実施形態の通信システムの構成例を示す。図1において、第1の実施形態の通信システムは、携帯電話、PC(Personal Computer)、モバイルルータ、スマートデバイス(例えば、家庭の消費電力をモニタするスマートメータ、スマートテレビ、ウェアラブル端末)、M2M(Machine to Machine)デバイス等の端末1を含む。M2Mデバイスは、例えば、上記のデバイスに加え、産業機器、車、ヘルスケア機器、家電等を含む。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
第1の実施形態の通信システムは、端末1と、当該端末1に通信サービスを提供するための複数のネットワークノード(基地局(eNB)2、SGW(Serving Gateway)3、PGW(PDN Gateway)4、MME(Mobility Management Entity)5)を含む。各ネットワークノードは、例えば、所定の通信機能を有する通信装置である。
端末1は、例えば、基地局2と接続し、SGW3とPGW4を経由して、インターネット等のネットワークにアクセスする。
図1に例示された各ネットワークノードは、所定の信号処理を実行する。各ネットワークノードは、例えば、信号処理に関する以下の機能を含む。
PGW4:
・パケットを処理する機能(User−Plane機能)
・通信に応じた課金状態を管理する機能(PCEF:Policy and Charging Enforcement Function)
・QoS等のポリシーを制御する機能(PCRF:Policy and Charging Rule Function)
SGW3:
・パケットを処理する機能(User−Plane機能)
・制御シグナリングを処理する機能(C−Plane機能)
・通信を傍受するための合法的傍受(LI:Lawful Interception)機能
MME5:
・制御シグナリングを処理する機能(C−Plane機能)
・HSS(Home Subscriber Server)と連携して、通信システムの加入者情報を管理する機能
第1の実施形態の通信システムは、端末1の端末属性に基づいて、該端末1と接続する基地局2を選択可能である。端末1の端末属性は、例えば、端末1がMTC(Machine Type Communication)デバイスであるか否かを示す。端末属性は、例えば、端末1の種別、端末1が所定のMTCデバイスグループに属するか否か等を示してもよい。
MTCデバイスは、例えば、スマートデバイス(例えば、家庭の消費電力をモニタするスマートメータ、スマートテレビ、ウェアラブル端末)、産業機器、車、ヘルスケア機器、家電等である。MTCは、例えばスマートメータなど、必ずしも人間の介入を必要としないデータ通信の形態を意味する。つまり、MTCデバイスは、通信相手の機器と自律通信が可能である。MTCは、技術標準仕様書(3GPP(3rd Generation Partnership Project) TS22.368等)で標準化が進められている。MTCデバイスは、特定の時間(例えば、“毎日、PM12:00”や“毎週金曜日、AM3:00”等)に通信を行う場合が想定される。この場合、多数の同種のMTCデバイス(例えば、スマートメータ)が、同じ時間に通信を開始し、大量の通信トラフィックが特定の時間に発生することが想定される。このような大量の通信トラフィックは、例えば、端末1と基地局2との間の無線通信に遅延を生じさせることが想定される。
そこで、第1の実施形態の通信システムは、MTCデバイス(端末1B)用の基地局2(B)を設け、該MTCデバイスである端末1Bからの通信トラフィックを当該基地局2(B)にオフロードさせる。そのため、端末1からの通信トラフィックが複数の基地局2に分散され、該端末1と基地局2との間の無線通信の遅延を低減できる。また、基地局2(A)と基地局2(B)の無線方式が同一であれば、仮に端末1が複数の無線方式に対応していなくとも、通信トラフィックがオフロードされる。よって、第1の実施形態の通信システムは、端末1がサポートする通信方式に依存せずに、通信トラフィックをオフロードすることができる。
第1の実施形態の通信システムにおいて、例えば、基地局2(B)は、MTCデバイス向けにチューニングされた基地局である。例えば、基地局2(B)は、例えば“Inactivity Timer”等のパラメータがMTCデバイス用に設定されている基地局である。基地局2は、端末1のデータ通信が終了して無通信状態に遷移してから一定時間が経過すると、端末1との接続を切断する。“Inactivity Timer”は、基地局2が端末1との接続を切断するまでのタイマである。例えば、基地局2(B)の“Inactivity Timer”は、MTCデバイス(端末1B)の通信特性や移動特性に応じて設定される。例えば、基地局2(B)の“Inactivity Timer”は、移動量が少ない(あるいは移動が無い)MTCデバイス(端末1B)用に、他の基地局2の“Inactivity Timer”よりも長く設定されている。
“Inactivity Timer”がMTCデバイス用に設定されているので、基地局2が、端末1との通信の切断処理と接続処理を実行する回数が抑止される。従って、端末1が基地局2と接続する際に発生する制御シグナリングが抑止され、通信システムの負荷が軽減される。
MTCデバイス用の基地局2(基地局2(B))は、例えば、フェムトセル(Femto−Cell)基地局であってもよい。フェムトセル基地局は、通常の基地局(マクロセル)のセルサイズよりも狭い半径数m〜数十m程度の領域をカバーする基地局である。フェムトセル基地局は、例えば、ビル内や住宅内、地下街等に、通信品質や通信速度の向上などの目的で設置される。
例えば、スマートメーター等のスマートデバイスは、宅内に設置されたフェムトセル基地局と通信可能な範囲に設置されることが想定される。この場合、例えば、スマートデバイス(例えば、端末1B)の通信トラフィックをフェムトセル基地局にオフロードして、通常の基地局(マクロセル)の無線通信の遅延を低減する。
図1に例示されるように、第1の実施形態の通信システムは、制御サーバ6を含んでいてもよい。制御サーバ6は、例えばSON(Self Organizing Network)サーバである。制御サーバ6は、例えば、モビリティ負荷分散(MLB:Mobility Load Balancing)を用いて、端末1と基地局2との接続を制御する。MLBは、端末を基地局間でハンドオーバーさせることによって、無線通信の負荷を分散させる技術である。
図2は、第1の実施形態の通信システムの他の構成例を示す。図2において、第1の実施形態の通信システムは、複数のMME(MME5(A)とMME5(B))を含む。図2の例において、MME5(A)は、基地局2(A)および基地局2(A)に接続する端末1に関する制御シグナリングを処理する。一方、図2の例において、MME5(B)は、基地局2(B)および基地局2(B)に接続する端末1(例えば、MTCデバイス)に関する制御シグナリングを処理する。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
図2の例では、基地局2から送信される制御シグナリングが、複数のMME5に分散される。従って、制御シグナリングの処理に要するMME5の負荷が軽減される。
図3は、第1の実施形態における基地局2の構成例を示す。図3に例示するように、基地局2は、制御部20と、識別部21とを含む。
識別部21は、通信トラフィックの種別や端末1の属性・種別を識別する。例えば、識別部21は、所定の識別ポリシーに基づいて、通信トラフィックの種別や端末1の種別を識別できる。例えば、識別部20の識別ポリシーは、動的に変更される。例えば、ネットワークオペレータは、識別ポリシーを動的に変更できる。
制御部20は、識別部21が識別した通信トラフィックの種別や端末1の属性・種別に基づいて、端末1と基地局2との接続を制御できる。制御部20は、例えば、所定の制御ポリシーに基づいて、端末1と基地局2との接続を制御できる。例えば、非MTCデバイス用の基地局2(A)には、端末1がMTCデバイスである場合、端末1を他の基地局2と接続させることを示す制御ポリシーが設定される。また、例えば、非MTCデバイス用の基地局2(A)には、端末1が非MTCデバイスである場合、端末1が基地局2(A)に接続することを許可することを示す制御ポリシーが設定される。
例えば、MTCデバイス用の基地局2(B)には、端末1がMTCデバイスである場合、端末1と接続し、端末1とネットワークとの間のセッションを確立させることを示す制御ポリシーが設定される。また、例えば、MTCデバイス用の基地局2(B)には、端末1が非MTCデバイスである場合、端末1を他の基地局2と接続させることを示す制御ポリシーが設定される。
例えば、制御部20は、識別部21が識別した通信トラフィックの種別や端末1の属性・種別に基づいて、端末1を他の基地局2と接続させることができる。また、制御部20は、識別部21が識別した通信トラフィックの種別や端末1の属性・種別に基づいて、端末1をネットワークと接続させることもできる。
識別部21は、例えば、端末1がMTCデバイスであるか否かを識別する。識別部21は、例えば、端末1から受信した接続要求に含まれる端末1の属性に関する情報に基づいて、端末1がMTCデバイスか否かを判断する。接続要求は、例えば、3GPPの技術仕様書に規定された“RRC Connection Request”という制御信号である。“RRC Connection Request”には、端末1の優先度に関する情報が含まれる。例えば、識別部21は、端末1が低優先である場合、端末1がMTCデバイスであると判断する。端末1が低優先である場合、例えば、“RRC Connection Request”には“LAPI:Low Access Priority Indicator”が含まれる。識別部21は、例えば、“RRC Connection Request”に“LAPI”が含まれる場合、端末1がMTCデバイスであると判断する。
制御部20は、例えば、基地局2に設定された制御ポリシーに基づいて、端末1と基地局2との接続を制御する。制御部20は、例えば、端末1がMTCデバイスである場合、制御ポリシーに応じた制御を実行する。例えば、制御部20は、端末1がMTCデバイスである場合、接続要求を拒否し、端末1に他の基地局2(例えば、MTCデバイス用の基地局2)への接続を指示することができる。制御部20は、接続要求を拒否する場合、端末1にMTCデバイス用の基地局2に関する情報を通知することができる。MTCデバイス用の基地局2に関する情報は、例えば、複数のMTCデバイス用の基地局2が記載されたリスト(セルリスト)であってもよい。
また、制御部20は、例えば、端末1がMTCデバイスである場合、端末1との間で無線接続を確立し、端末1がネットワークノードと通信セッションを確立するための処理を開始できる。制御部20は、通信セッションを確立するために、MME5に対してNAS(Non−Access Stratum)メッセージを送信することができる。
識別部21は、例えば、通信トラフィックがMTC関連のアプリケーションに対応するか否かを識別できる。例えば、制御部20は、通信トラフィックがMTC関連のアプリケーションに対応する場合、端末1に対して、他の基地局2と再接続することを指示できる。制御部20は、接続要求を拒否する場合、端末1にMTCデバイス用の基地局2に関する情報を通知することができる。また、制御部20は、例えば、通信トラフィックがMTC関連のアプリケーションに対応する場合、端末1用に確立された通信セッションを介して、通信トラフィックを転送できる。
図4は、第1の実施形態におけるMME5の構成例を示す。MME5は、制御部50と、識別部51とを含む。
識別部51は、基地局2から受信したNASメッセージに基づいて、通信トラフィックの種別や端末1の属性・種別を識別できる。なお、識別部51の機能は、識別部21の機能と同様であるため、詳細な説明は省略される。
制御部50は、識別部51が識別した通信トラフィックの種別や端末1の属性・種別に基づいて、端末1と基地局2との接続を制御できる。制御部50は、例えば、所定の制御ポリシーに基づいて、端末1と基地局2との接続を制御できる。例えば、MME5には、端末1がMTCデバイスである場合、端末1をMTCデバイス用の基地局2と接続させることを示す制御ポリシーが設定される。また、例えば、MME5には、端末1がMTCデバイスである場合、端末1とネットワークとの間のセッションを確立させることを示す制御ポリシーが設定される。
制御部50は、例えば、端末1がMTCデバイスである場合、基地局2に対して、端末1を他の基地局2に再接続させるための指示を通知できる。
図5は、第1の実施形態における制御サーバ6の構成例を示す。制御サーバ6は、制御部60と、識別部61とを含む。
識別部61は、基地局2から受信した端末1の端末情報に基づいて、通信トラフィックの種別や端末1の属性・種別を識別する。なお、識別部61の機能は、識別部21又は識別部51の機能と同様であるため、詳細な説明は省略される。
制御部60は、識別部61が識別した通信トラフィックの種別や端末1の属性・種別に基づいて、端末1と基地局2との接続を制御できる。制御部60は、例えば、所定の制御ポリシーに基づいて、端末1と基地局2との接続を制御できる。例えば、制御サーバ6には、端末1がMTCデバイスである場合、端末1をMTCデバイス用の基地局2と接続させることを示す制御ポリシーが設定される。また、例えば、制御サーバ6には、端末1がMTCデバイスである場合、端末1とネットワークとの間のセッションを確立させることを示す制御ポリシーが設定される。
制御部60は、例えば、端末1がMTCデバイスである場合、基地局2に対して、端末1を他の基地局2に再接続させるための指示を通知できる。
図6は、第1の実施形態における端末1の構成例を示す。図6に例示するように、端末1は、メッセージ生成部10と、通信部11とを含む。
メッセージ生成部10は、端末1が基地局2に対して通知するメッセージを生成する。
例えば、メッセージ生成部10は、例えば、“RRC Connection Request”メッセージを生成できる。例えば、メッセージ生成部10は、端末1の属性に応じて、“RRC Connection Request”メッセージに、端末1の優先度を示す情報を含めることができる。例えば、メッセージ生成部10は、“RRC Connection Request”に“LAPI”を含めることができる。また、例えば、メッセージ生成部10は、通信トラフィックに対応するアプリケーションを示す情報を含むメッセージを生成する。
通信部11は、生成されたメッセージを基地局2に送信する。通信部11は、メッセージを送信する基地局2を選択できる。例えば、通信部11は、基地局2に送信した接続要求が拒絶された場合、他の基地局2を再選択できる。また、例えば、通信部11は、接続要求の拒絶通知に含まれる情報(例えば、基地局2の情報や、セルリスト)に基づいて、基地局2を再選択できる。
図7は、第1の実施形態の動作例を示すシーケンス図である。なお、図7は、基地局2が端末1の属性・種別(端末属性)を識別する動作例であるが、基地局2は、通信トラフィックの種別を識別してもよい。
非MTCデバイスである端末1A(非MTCデバイス1A)は、基地局2(A)との間で無線によるコネクションを確立するため、接続要求を送信する(S1−1)。接続要求は、例えば、端末1が無線ネットワークと接続するために送信するメッセージである。非MTCデバイス1Aは、例えば、基地局2(A)に、接続要求として“RRC Connection Request”を送信する。
基地局2(A)の識別部21は、接続要求の受信に応じて、端末属性を識別する(S1−2)。例えば、基地局2(A)は、非MTCデバイス1Aから受信した“RRC Connection Request”に、“LAPI”が含まれるか否かに基づいて、端末属性を識別する。図7の例では、非MTCデバイス1Aから送信された“RRC Connection Request”には“LAPI”は含まれていない。よって、S1−2において、識別部21は、端末1Aは非MTCデバイスであると識別する。
基地局2(A)の制御部20は、識別部21が端末1Aを非MTCデバイスと識別したことに応じて、MME5にNASメッセージを送信する(S1−3)。
MTCデバイスである端末1B(MTCデバイス1B)は、基地局2(A)に、接続要求(例えば、“RRC Connection Request”)を送信する(S1−4)。
基地局2(A)の識別部21は、接続要求の受信に応じて、端末属性を識別する(S1−5)。図7の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、基地局2(A)の識別部21は、“RRC Connection Request”に含まれる“LAPI”に基づいて、端末1BがMTCデバイスであると識別する。
基地局2(A)の制御部20は、識別部21が端末1BをMTCデバイスと識別したことに応じて、MTCデバイス1Bに、接続要求が拒否されたことを示す拒否通知を送信する(S1−6)。拒否通知は、例えば、端末1Bから接続要求を受信した基地局2(A)と当該端末1Bとの接続の拒否を示す通知であってもよい。制御部20は、例えば、拒否通知に、MTCデバイス(端末1B)用の基地局2(B)を示す情報を含めてもよい。
MTCデバイス1Bは、他の基地局2(図7の例では、MTCデバイス用の基地局2(B))に接続要求(例えば、“RRC Connection Request”)を再送信する(S1−7)。
基地局2(B)の制御部20は、MME5にNASメッセージを送信する(S1−8)。図7の例では、基地局2(B)には、端末1がMTCデバイスの場合、端末1と無線接続を確立し、端末1とネットワークノードとの通信セッションを開始することを示す制御ポリシーが設定されている。よって、基地局2(B)の制御部20は、MTCデバイスである端末1Bと無線接続を確立し、MME5に対してNASメッセージを送信する。なお、基地局2(B)の制御部20は、MTCデバイス用のMME(例えば、図2のMME5(B))に対して、NASメッセージを送信してもよい。
図8は、第1の実施形態の他の動作例を示すシーケンス図である。図8は、MME5が端末1の属性・種別(端末属性)を識別する場合の動作例である。
非MTCデバイス1Aは、基地局2(A)に接続要求を送信する(S2−1)。例えば、非MTCデバイス1Aは、“RRC Connection Request”を送信する。接続要求を受信した基地局2(A)は、MME5に、NASメッセージを送信する(S2−2)。
MME5の識別部51は、NASメッセージの受信に基づいて、端末属性を識別する(S2−3)。MME5の識別部51は、例えば、受信したNASメッセージに、“LAPI”が含まれるか否かに基づいて、端末属性を識別する。図8の例では、非MTCデバイス1Aからの接続要求に応じて基地局2(A)が送信したNASメッセージには、“LAPI”は含まれていない。よって、S2−3において、識別部51は、端末1Aは非MTCデバイスであると識別する。MME5は、端末1Aが非MTCデバイスと認識されたので、端末1Aとネットワークノードとの通信セッションを確立するための処理(例えば、3GPP TS23.401 v12.3.0の5.3.2章に規定された“Attach Procedure”)を開始する。
MTCデバイスである端末1Bは、基地局2(A)に接続要求(例えば、“RRC Connection Request”)を送信する(S2−4)。接続要求を受信した基地局2(A)は、MME5に、NASメッセージを送信する(S2−5)。
MME5の識別部51は、NASメッセージの受信に基づいて、端末属性を識別する(S2−6)。図8の例では、MTCデバイス1Bからの接続要求に応じて基地局2(A)が送信したNASメッセージには、“LAPI”が含まれる。よって、識別部51は、端末1BがMTCデバイスであると識別する。
MME5の制御部50は、例えば、識別部51がMTCデバイスと識別した場合に、端末1に対して、基地局2の切り替えを指示するメッセージ(切り替え指示)を送信する(S2−7)。
MTCデバイス1Bは、他の基地局2(図8の例では、MTCデバイス用の基地局2(B))に、接続要求(例えば、“RRC Connection Request”)を送信する(S2−8)。接続要求を受信した基地局2(B)は、MME5にNASメッセージを送信する(S2−9)。なお、基地局2(B)は、MTCデバイス用のMME(例えば、図2のMME5(B))に対して、NASメッセージを送信してもよい。
図9は、第1の実施形態の他の動作例を示すシーケンス図である。図9は、制御サーバ6が端末1の属性・種別(端末属性)を識別する場合の動作例である。
非MTCデバイス1Aは、基地局2(A)に接続要求を送信する(S3−1)。例えば、非MTCデバイス1Aは、“RRC Connection Request”を送信する。接続要求を受信した基地局2(A)は、制御サーバ6に、端末情報を送信する(S3−2)。
制御サーバ6の識別部61は、端末情報の受信に基づいて、端末属性を識別する(S3−3)。制御サーバ6の識別部61は、例えば、受信した端末情報に、“LAPI”が含まれるか否かに基づいて、端末属性を識別する。図9の例では、非MTCデバイス1Aからの接続要求に応じて基地局2(A)が送信した端末情報には、“LAPI”は含まれていない。よって、S3−3において、識別部61は、端末1Aは非MTCデバイスであると認識する。制御サーバ6は、端末1Aが非MTCデバイスと認識されたので、端末1Aとネットワークノードとの通信セッションを確立するための処理(例えば、3GPP TS23.401 v12.3.0の5.3.2章に規定された“Attach Procedure”)を開始する。
MTCデバイスである端末1Bは、基地局2に接続要求(例えば、“RRC Connection Request”)を送信する(S3−4)。接続要求を受信した基地局2(A)は、制御サーバ6に、端末情報を送信する(S3−5)。
制御サーバ6の識別部61は、端末情報の受信に基づいて、端末属性を識別する(S3−6)。図9の例では、MTCデバイス1Bからの接続要求に応じて基地局2(A)が送信した端末情報には、“LAPI”が含まれる。よって、識別部61は、端末1BがMTCデバイスであると識別する。
制御サーバ6の制御部60は、例えば、識別部61がMTCデバイスと識別した場合に、端末1に対して、基地局2の切り替えを指示するメッセージ(切り替え指示)を送信する(S3−7)。
MTCデバイス1Bは、他の基地局2(図9の例ではMTCデバイス用の基地局2(B))に、接続要求(例えば、“RRC Connection Request”)を送信する(S3−8)。
上記のとおり、第1の実施形態の通信システムは、端末1の端末属性に基づいて、該端末1と接続する基地局2を選択可能である。そのため、端末1からの通信トラフィックが複数の基地局2に分散され、該端末1と基地局2との間の無線通信の遅延を低減できる。
また、基地局2(A)と(B)の無線方式が同一であれば、仮に端末1が複数の無線方式に対応していなくとも、通信トラフィックがオフロードされる。よって、第1の実施形態の通信システムは、端末1がサポートする通信方式に依存せずに、通信トラフィックをオフロードすることができる。
<第2の実施形態>
本発明の第2の実施形態では、ネットワークノードの機能の少なくとも一部が、ソフトウェア等により仮想的に運用される。なお、第2の実施形態の技術は、第1の実施形態、後述の実施形態のいずれにも適用可能である。
第2の実施形態の通信システムでは、ソフトウェア等により仮想的に運用されるネットワークノードが、端末属性に応じてオフロードされたトラフィックを処理できる。従って、第2の実施形態の通信システムは、オフロードされたトラフィックを処理するためのネットワークノードを、ソフトウェアにより容易かつ低コストで構築することが可能である。
図10は、第2の実施形態の通信システムの構成例を示す。図10の例では、MTC端末(端末1B)が基地局2(B)に接続され、MTC端末のトラフィックがオフロードされる。図10に例示するように、第2の実施形態の通信システムは、仮想MME5Aが、基地局2(B)および基地局2(B)に接続する端末1(例えば、MTCデバイス)に関する制御シグナリングを処理する。仮想MME5Aは、MME5の機能を、仮想マシン等のソフトウェアで運用する。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
図10の例において、MME5(A)は、基地局2(A)および基地局2(A)に接続する端末1(例えば、非MTC端末)に関する制御シグナリングを処理する。
仮想MME5Aは、動的なスケールアウト・スケールインが可能である。ネットワークオペレータは、例えば、端末1の通信トラフィックの状況に応じて、仮想MME5Aの動的なスケールアウト・スケールインが可能である。例えば、ネットワークオペレータは、端末1が通信を開始する時間に合わせて、仮想MME5Aを動的に起動することができる。また、例えば、ネットワークオペレータは、端末1からの通信トラフィックに対応する仮想MME5Aを起動することができる。また、例えば、ネットワークオペレータは、端末1からの通信トラフィックの処理に対する要求条件(例えば、SLA:Service Level Agreement)を満たすように、仮想MME5Aを起動することができる。
図10の例では、基地局2から送信される制御シグナリングが、複数のMME5(MME5および仮想MME5A)に分散される。従って、制御シグナリングの処理に要するMME5の負荷が軽減される。また、図10の例では、端末1からの通信トラフィックに合わせて仮想MME5Aを動的にスケールアウト・スケールインできる。よって、例えば、端末1がMTCデバイスである場合、該通信システムは、MTCデバイス1Bからの通信トラフィックが多い時間帯に仮想マシンを起動し、当該通信トラフィックが少ない時間帯に仮想マシンを停止することができる。従って、通信システムは、仮想マシンを実現するサーバ等の消費電力を抑止することが可能となる。
図10に例示された端末1(Non−MTCデバイス1A、MTCデバイス1B)、基地局2(基地局(A)、基地局(B))、MME5の構成は、第1の実施形態と同様なので、詳細な説明は省略される。また、図10に例示されたネットワークノード(SGW3、PGW4)の機能は、第1の実施形態で説明された機能と同様であり、詳細な説明は省略される。
図11は、第2の実施形態の通信システムの他の構成例を示す。図11に例示するように、第2の実施形態の通信システムは、レガシーネットワークと仮想ネットワークにより構成される。レガシーネットワークと仮想ネットワークは、EPC(Evolved Packet Core)等のバックボーンネットワークである。レガシーネットワークと仮想ネットワークは、端末1が、基地局2を介してインターネット等の外部ネットワークと通信するためのバックボーンネットワークである。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
図11の例では、所定の属性の端末1(例えば、MTCデバイス)からの通信トラフィックが、仮想ネットワークにオフロードされる。よって、該通信システムは、例えば、MTCデバイスの通信トラフィックによるレガシーネットワークへの負荷を軽減することができる。例えば、MTCデバイスとネットワークとを接続するための制御信号を、仮想ネットワークに送信することで、レガシーネットワークがMTCデバイスからの制御信号を処理する負荷を軽減することができる。
レガシーネットワークは、端末1に通信サービスを提供するための複数のネットワークノード(SGW3、PGW4、MME5)を含む。各ネットワークノードは、例えば、所定の通信機能を有する通信装置である。
仮想ネットワークでは、レガシーネットワークのネットワークノードの機能の少なくとも一部が、ソフトウェアにより仮想的に運用される。例えば、ネットワークノードの機能は、仮想マシン上のアプリケーションで運用される。仮想ネットワークは、例えば、サーバや通信機器(スイッチやルータ等)で構成されるデータセンターに構築される。
仮想ネットワークは、例えば、仮想マシンの動的なスケールアウト・スケールインにより構築される。例えば、ネットワークオペレータは、ネットワークにおける通信トラフィックの状況に応じて、仮想マシンを動的に起動することで、仮想ネットワークを構築できる。また、例えば、ネットワークオペレータは、所定の時間帯に仮想マシンを動的に起動することで、仮想ネットワークを構築することもできる。ネットワークオペレータは、所定の通信トラフィックや、所定の端末1の通信トラフィックに対応する仮想マシンを起動し、動的に仮想ネットワークを構築することができる。ネットワークオペレータは、通信トラフィックの処理に対する要求条件(例えば、SLA)を満たすように仮想マシンを起動し、動的に仮想ネットワークを構築することができる。
ネットワークオペレータは、例えば、通信トラフィックが少ない所定の時間帯に、仮想マシンを停止することで、仮想ネットワークに割り当てるリソースを抑え、データセンターの消費電力を抑止することもできる。
図11に例示する通信システムは、レガシーネットワークと仮想ネットワーク以外に他のネットワークを含んでもよい。また、レガシーネットワークと仮想ネットワークは、それぞれ、複数種類のネットワークを含んでもよい。例えば、レガシーネットワークと仮想ネットワークは、それぞれ、LTEネットワーク、GPRSネットワーク、UMTSネットワーク等の複数種類のネットワークを含んでもよい。
図11に例示するように、端末1は、基地局2(A)を介してレガシーネットワークに接続できる。一方、端末1は、基地局2(B)を介して仮想ネットワークに接続できる。
例えば、基地局2(B)がMTCデバイス用の基地局2である場合、MTCデバイス1Bからの通信トラフィックが、当該基地局2(B)を介して仮想ネットワークにオフロードされる。例えば、MTCデバイスとネットワークとを接続するための制御信号は、基地局2(B)を介して、仮想ネットワークへ送信される。よって、MTCデバイスの通信トラフィックによるレガシーネットワークへの負荷が軽減される。将来、膨大な数のMTCデバイスが通信システムと接続することが想定されるが、上記制御信号が仮想ネットワークにオフロードされることで、レガシーネットワークが上記制御信号を処理する負荷を軽減できる。また、図11の例では、基地局2(A)と基地局2(B)の無線方式が同一であれば、仮に端末1が複数の無線方式に対応していなくても、通信トラフィックが仮想ネットワークにオフロードされる。よって、第2の実施形態の通信システムは、端末1がサポートする通信方式に依存せずに、通信トラフィックを仮想ネットワークにオフロードすることが可能となる。
図11に例示された端末1(非MTCデバイス1A、MTCデバイス1B)、基地局2(基地局(A)、基地局(B))、MME5の構成は、第1の実施形態と同様なので、詳細な説明は省略される。また、図11に例示されたネットワークノード(SGW3、PGW4)の機能は、第1の実施形態で説明された機能と同様であり、詳細な説明は省略される。
図12は、第2の実施形態の通信装置100の構成例を示す。通信装置100は、例えば、サーバ、スイッチ、ルータ等である。通信装置100は、仮想ネットワークにおける仮想ネットワークノード(例えば、仮想SGW3A、仮想PGW4A、仮想MME5A等)の機能を提供する仮想マシンを運用する。
通信装置100は、制御部110、仮想ネットワーク機能(VNF:Virtual Network Function)120を含む。
制御部110は、仮想ネットワークノードの機能を提供するVNF120を仮想マシン上で運用することができる。制御部110は、例えば、ハイパーバイザ(Hypervisor)等、コンピュータの仮想化を実行可能な制御ソフトウェアにより構成されてもよい。
制御部110は、VNF120を運用する仮想マシンの起動、停止、移行(仮想マシンを他の通信装置100に移行する)の少なくとも1つを実行できる。
仮想ネットワークノードの各々は、例えば以下の機能を有する。
仮想PGW4A:
・パケットを処理する機能(User−Plane機能)
・通信に応じた課金状態を管理する機能(PCEF:Policy and Charging Enforcement Function)
・QoS等のポリシーを制御する機能(PCRF:Policy and Charging Rule Function)
仮想SGW3A:
・パケットを処理する機能(User−Plane機能)
・制御シグナリングを処理する機能(C−Plane機能)
・通信を傍受するための合法的傍受(LI:Lawful Interception)機能
仮想MME5A:
・制御シグナリングを処理する機能(C−Plane機能)
・HSS(Home Subscriber Server)と連携して、通信システムの加入者情報を管理する機能
VNF120は、仮想マシン上で、上述の仮想ネットワークノードとして動作する。上述の実施形態では、VNF120は、仮想ネットワークノード毎に構築されるが、VNF120は、各仮想ネットワークノードが有する機能毎に構築されてもよい。例えば、VNF120は、仮想マシン上で、仮想PGW4AのU−Plane機能として動作してもよい。
図13は、第2の実施形態の動作例を示すシーケンス図である。なお、図13は、基地局2が端末1の属性・種別(端末属性)を識別する動作例であるが、基地局2は、通信トラフィックの種別を識別してもよい。
非MTCデバイスである端末1A(非MTCデバイス1A)は、基地局2(A)との間で無線によるコネクションを確立するため、接続要求を送信する(S4−1)。非MTCデバイス1Aは、例えば、基地局2(A)に、接続要求として“RRC Connection Request”を送信する。
基地局2(A)の識別部21は、接続要求の受信に応じて、端末属性を識別する(S4−2)。例えば、基地局2(A)は、非MTCデバイス1Aから受信した“RRC Connection Request”に、“LAPI”が含まれるか否かに基づいて、端末属性を識別する。図13の例では、非MTCデバイス1Aから送信された“RRC Connection Request”には“LAPI”は含まれていない。よって、S4−2において、識別部21は、端末1Aは非MTCデバイスであると識別する。
基地局2(A)の制御部20は、識別部21が端末1Aを非MTCデバイスと識別したことに応じて、MME5にNASメッセージを送信する(S4−3)。
MTCデバイスである端末1B(MTCデバイス1B)は、基地局2(A)に、接続要求(例えば、“RRC Connection Request”)を送信する(S4−4)。
基地局2(A)の識別部21は、接続要求の受信に応じて、端末属性を識別する(S4−5)。図13の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、基地局2(A)の識別部21は、“RRC Connection Request”に含まれる“LAPI”に基づいて、端末1BがMTCデバイスであると識別する。
基地局2(A)の制御部20は、識別部21が端末1BをMTCデバイスと識別したことに応じて、MTCデバイス1Bに、接続要求が拒否されたことを示す拒否通知を送信する(S4−6)。制御部20は、例えば、拒否通知に、MTCデバイス(端末1B)用の基地局2(B)を示す情報を含めてもよい。
MTCデバイス1Bは、他の基地局2(図13の例では、MTCデバイス用の基地局2(B))に接続要求(例えば、“RRC Connection Request”)を再送信する(S4−7)。
基地局2(B)の制御部20は、仮想MME5AにNASメッセージを送信する(S4−8)。図13の例では、基地局2(B)には、端末1がMTCデバイスの場合、端末1と無線接続を確立し、端末1とネットワークノードとの通信セッションを開始することを示す制御ポリシーが設定されている。よって、基地局2(B)の制御部20は、MTCデバイスである端末1Bと無線接続を確立し、仮想MME5Aに対してNASメッセージを送信する。
図14は、第2の実施形態の他の動作例を示すシーケンス図である。図14は、MME5が端末1の属性・種別(端末属性)を識別する場合の動作例である。
非MTCデバイス1Aは、基地局2(A)に接続要求を送信する(S5−1)。例えば、非MTCデバイス1Aは、“RRC Connection Request”を送信する。接続要求を受信した基地局2(A)は、MME5に、NASメッセージを送信する(S5−2)。
MME5の識別部51は、NASメッセージの受信に基づいて、端末属性を識別する(S5−3)。MME5の識別部51は、例えば、受信したNASメッセージに、“LAPI”が含まれるか否かに基づいて、端末属性を識別する。図14の例では、非MTCデバイス1Aからの接続要求に応じて基地局2(A)が送信したNASメッセージには、“LAPI”は含まれていない。よって、S5−3において、識別部51は、端末1Aは非MTCデバイスであると識別する。MME5は、端末1Aが非MTCデバイスと認識されたので、端末1Aとネットワークノードとの通信セッションを確立するための処理(例えば、3GPP TS23.401 v12.3.0の5.3.2章に規定された“Attach Procedure”)を開始する。
MTCデバイスである端末1Bは、基地局2(A)に接続要求(例えば、“RRC Connection Request”)を送信する(S5−4)。接続要求を受信した基地局2(A)は、MME5に、NASメッセージを送信する(S5−5)。
MME5の識別部51は、NASメッセージの受信に基づいて、端末属性を識別する(S5−6)。図14の例では、MTCデバイス1Bからの接続要求に応じて基地局2(A)が送信したNASメッセージには、“LAPI”が含まれる。よって、識別部51は、端末1BがMTCデバイスであると識別する。
MME5の制御部50は、例えば、識別部51がMTCデバイスと識別した場合に、端末1に対して、基地局2の切り替えを指示するメッセージ(切り替え指示)を送信する(S5−7)。
MTCデバイス1Bは、他の基地局2(図14の例では、MTCデバイス用の基地局2(B))に、接続要求(例えば、“RRC Connection Request”)を送信する(S5−8)。接続要求を受信した基地局2(B)は、仮想MME5AにNASメッセージを送信する(S5−9)。
図15は、第2の実施形態の他の動作例を示すシーケンス図である。図15は、制御サーバ6が端末1の属性・種別(端末属性)を識別する場合の動作例である。
非MTCデバイス1Aは、基地局2(A)に接続要求を送信する(S6−1)。例えば、非MTCデバイス1Aは、“RRC Connection Request”を送信する。接続要求を受信した基地局2(A)は、制御サーバ6に、端末情報を送信する(S6−2)。
制御サーバ6の識別部61は、端末情報の受信に基づいて、端末属性を識別する(S6−3)。制御サーバ6の識別部61は、例えば、受信した端末情報に、“LAPI”が含まれるか否かに基づいて、端末属性を識別する。図15の例では、非MTCデバイス1Aからの接続要求に応じて基地局2(A)が送信した端末情報には、“LAPI”は含まれていない。よって、S6−3において、識別部61は、端末1Aは非MTCデバイスであると認識する。制御サーバ6は、端末1Aが非MTCデバイスと認識されたので、端末1Aとネットワークノードとの通信セッションを確立するための処理(例えば、3GPP TS23.401 v12.3.0の5.3.2章に規定された“Attach Procedure”)を開始する。基地局2(A)は、例えば、制御サーバ6が端末1Aを非MTCデバイスと認識した場合、MME5に対して、NASメッセージを送信する(S6−4)。
MTCデバイスである端末1Bは、基地局2に接続要求(例えば、“RRC Connection Request”)を送信する(S6−5)。接続要求を受信した基地局2(A)は、制御サーバ6に、端末情報を送信する(S6−6)。
制御サーバ6の識別部61は、端末情報の受信に基づいて、端末属性を識別する(S6−7)。図15の例では、MTCデバイス1Bからの接続要求に応じて基地局2(A)が送信した端末情報には、“LAPI”が含まれる。よって、識別部61は、端末1BがMTCデバイスであると識別する。
制御サーバ6の制御部60は、例えば、識別部61がMTCデバイスと識別した場合に、端末1に対して、基地局2の切り替えを指示するメッセージ(切り替え指示)を送信する(S6−8)。
MTCデバイス1Bは、他の基地局2(図15の例ではMTCデバイス用の基地局2(B))に、接続要求(例えば、“RRC Connection Request”)を送信する(S6−9)。接続要求を受信した基地局2(B)は、仮想MME5Aに、NASメッセージを送信する(S6−10)。
上記のとおり、第2の実施形態は、端末1からの通信トラフィックに合わせて仮想MME5Aを動的にスケールアウト・スケールインできる。よって、例えば、端末1がMTCデバイスである場合、該通信システムは、MTCデバイス1Bからの通信トラフィックが多い時間帯に仮想マシンを起動し、当該通信トラフィックが少ない時間帯に仮想マシンを停止することで、仮想マシンを実現するサーバ等の消費電力を抑止することが可能となる。
また、第2の実施形態は、所定の端末1(例えば、MTCデバイス)からの通信トラフィックが、仮想ネットワークにオフロードされる。よって、該通信システムは、例えば、MTCデバイスの通信トラフィックによるレガシーネットワークへの負荷を軽減することができる。例えば、MTCデバイスとネットワークとを接続するための制御信号を、仮想ネットワークに送信することで、レガシーネットワークがMTCデバイスからの制御信号を処理する負荷を軽減することができる。
<第3の実施形態>
本発明の第3の実施形態について、図面を参照して説明する。第3の実施形態は、基地局2が端末1の端末属性を識別する場合について、3GPPの標準仕様(例えば、3GPP TS23.401)に適用した際の動作例を説明するものである。なお、第3の実施形態の技術は、第1および第2の実施形態、後述の実施形態のいずれにも適用可能である。
図16は、第3の実施形態の動作例を示すシーケンス図である。図16は、3GPP(3rd Generation Partnership Project)の仕様書(TS23.401 v12.3.0)の5.3.2章に記載された“Attach Procedure”に本発明の技術を適用した動作例を示す。
非MTCデバイス1Aは、基地局2(A)との間で無線によるコネクションを確立するため、基地局2(A)に“RRC Connection Request”を送信する(S7−1)。
基地局2(A)の識別部21は、“RRC Connection Request”の受信に応じて、端末属性を識別する(S7−2の“Identify Terminal Property”)。例えば、基地局2(A)は、非MTCデバイス1Aから受信した“RRC Connection Request”に、“LAPI”が含まれるか否かに基づいて、端末属性を識別する。図16の例では、非MTCデバイス1Aから送信された“RRC Connection Request”には“LAPI”は含まれていない。よって、S7−2において、識別部21は、端末1Aは非MTCデバイスであると識別する。
基地局2(A)の制御部20は、識別部21が端末1を非MTCデバイスと識別したことに応じて、MME5にNASメッセージを送信する(S7−3)。
MTCデバイスである端末1B(MTCデバイス1B)は、基地局2(A)に、“RRC Connection Request”を送信する(S7−4)。
基地局2(A)の識別部21は、“RRC Connection Request”の受信に応じて、端末属性を識別する(S7−5の“Identify Terminal Property”)。図16の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、基地局2(A)の識別部21は、“RRC Connection Request”に含まれる“LAPI”に基づいて、端末1BがMTCデバイスであると識別する。
基地局2(A)の制御部20は、識別部21が端末1BをMTCデバイスと識別したことに応じて、MTCデバイス1Bに、“RRC Connection Request”が拒否されたことを示す拒否通知を送信する(S7−6の“NACK(Negative ACKnowledgement)”)。なお、基地局2(A)の制御部20は、例えば、識別部21が端末1BをMTCデバイスと識別した場合に、該基地局2(A)の隣接基地局がMTCデバイス用の基地局2(例えば、基地局2(B))であることに応じて、MTCデバイス1Bに拒否通知を送信してもよい。また、基地局2(A)の制御部20は、例えば、識別部21が端末1BをMTCデバイスと識別した場合に、該基地局2(A)の隣接セルがMTCデバイス用の基地局2(例えば、基地局2(B))がカバーするセルであることに応じて、MTCデバイス1Bに拒否通知を送信してもよい。
MTCデバイス1Bは、他の基地局2(図16の例では、MTCデバイス用の基地局2(B))に、“RRC Connection Request”を再送信する(S7−7)。MTCデバイス用の基地局2(B)は、例えば、MTCデバイス用に設けられたMME5(例えば、図2のMME5(B))や仮想MME5Aに対応付けられた基地局である。MTCデバイス用の基地局2(B)は、例えば、端末1がMTCデバイスの場合、端末1と無線接続を確立し、端末1とネットワークノードとの通信セッションを開始することを示す制御ポリシーが設定される。
基地局2(B)の識別部21は、“RRC Connection Request”の受信に応じて、端末属性を識別する(S7−8の“Identify Terminal Property”)。図16の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、基地局2(B)の識別部21は、“RRC Connection Request”に含まれる“LAPI”に基づいて、端末1BがMTCデバイスであると識別する。
基地局2(B)の制御部20は、MME5にNASメッセージを送信する(S7−9)。図16の例では、基地局2(B)には、端末1がMTCデバイスの場合、端末1と無線接続を確立し、端末1とネットワークノードとの通信セッションを開始することを示す制御ポリシーが設定されている。よって、基地局2(B)の制御部20は、MTCデバイスである端末1Bと無線接続を確立し、MME5に対してNASメッセージを送信する。なお、基地局2(B)の制御部20は、MTCデバイス用のMME5(例えば、図2のMME5(B)、図10の仮想MME5A)に対して、NASメッセージを送信してもよい。
図17は、第3の実施形態の他の動作例を示すシーケンス図である。図17は、基地局2(A)の制御部20が送信する拒否通知に、MTCデバイス(端末1B)用の基地局2(B)を示す情報を含める場合の動作例を示す。
MTCデバイスである端末1B(MTCデバイス1B)は、基地局2(A)に、“RRC Connection Request”を送信する(S8−1)。
基地局2(A)の識別部21は、“RRC Connection Request”の受信に応じて、端末属性を識別する(S8−2)。図17の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、基地局2(A)の識別部21は、“RRC Connection Request”に含まれる“LAPI”に基づいて、端末1BがMTCデバイスであると識別する。
基地局2(A)の制御部20は、識別部21が端末1BをMTCデバイスと識別したことに応じて、MTCデバイス1Bに対して、“RRC Connection Request”が拒否されたことを示す拒否通知に、MTCデバイス(端末1B)用の基地局2(B)を示す情報を含めて送信する(S8−3の“NACK with Base Station Info”)。MTCデバイス用の基地局2に関する情報は、例えば、複数のMTCデバイス用の基地局2が記載されたリスト(セルリスト)であってもよい。
端末1の通信部11は、拒否通知に含まれる情報(例えば、基地局2の情報や、セルリスト)に基づいて、例えば、MTCデバイス用の基地局2(B)を再選択する(S8−4の“Selection”)。
端末1の通信部11は、S8−4で選択したMTCデバイス用の基地局2(B)に対して、“RRC Connection Request”を送信する(S8−5)。
基地局2(B)の識別部21は、“RRC Connection Request”の受信に応じて、端末属性を識別する(S8−6)。図17の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、基地局2(B)の識別部21は、“RRC Connection Request”に含まれる“LAPI”に基づいて、端末1BがMTCデバイスであると識別する。
基地局2(B)の制御部20は、MME5にNASメッセージを送信する(S8−7)。図17の例では、基地局2(B)には、端末1がMTCデバイスの場合、端末1と無線接続を確立し、端末1とネットワークノードとの通信セッションを開始することを示す制御ポリシーが設定されている。よって、基地局2(B)の制御部20は、MTCデバイスである端末1Bと無線接続を確立し、MME5に対してNASメッセージを送信する。なお、基地局2(B)の制御部20は、MTCデバイス用のMME5(例えば、図2のMME5(B)、図10の仮想MME5A)に対して、NASメッセージを送信してもよい。
図18は、第3の実施形態の他の動作例を示すシーケンス図である。図18は、MTCデバイス用の基地局2(B)が、他の基地局2に対して、該基地局2(B)に関するシステム情報を予め通知する場合の動作例である。
MTCデバイス用の基地局2(B)は、他の基地局2に対して、自装置(基地局2(B))に関する情報を含むシステム情報ブロック(SIB:System Information Block)を、ブロードキャストする(S9−1の“SIB Broadcast with Base Station Info”)。システム情報ブロックは、例えば、基地局2(B)の各種パラメータに関する情報や、基地局2(B)がカバーするセルに関する情報を含む。MTCデバイス用の基地局2(B)が送信するシステム情報ブロックは、例えば、MTCデバイス用の基地局であることを示す情報を含む。基地局2(A)の識別部21は、例えば、受信したシステム情報ブロックに、MTCデバイス用の基地局であることを示す情報が含まれていることに基づき、基地局2(B)をMTCデバイス用の基地局と識別する。
MTCデバイスである端末1B(MTCデバイス1B)は、基地局2(A)に、“RRC Connection Request”を送信する(S9−2)。
基地局2(A)の識別部21は、“RRC Connection Request”の受信に応じて、端末属性を識別する(S9−3)。図18の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、基地局2(A)の識別部21は、“RRC Connection Request”に含まれる“LAPI”に基づいて、端末1BがMTCデバイスであると識別する。
基地局2(A)の制御部20は、識別部21が端末1BをMTCデバイスと識別したことに応じて、MTCデバイス1Bに対して、“RRC Connection Request”が拒否されたことを示す拒否通知に、MTCデバイス用の基地局2を示す情報を含めて送信する(S9−4の“NACK with Base Station Info”)。MTCデバイス用の基地局2を示す情報は、例えば、複数のMTCデバイス用の基地局2が記載されたリスト(セルリスト)であってもよい。
端末1の通信部11は、拒否通知に含まれる情報(例えば、基地局2の情報や、セルリスト)に基づいて、例えば、MTCデバイス用の基地局2(B)を再選択する(S9−5の“Selection”)。
端末1の通信部11は、S9−5で選択したMTCデバイス用の基地局2(B)に対して、“RRC Connection Request”を送信する(S9−6)。
基地局2(B)の識別部21は、“RRC Connection Request”の受信に応じて、端末属性を識別する(S9−7)。図18の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、基地局2(B)の識別部21は、“RRC Connection Request”に含まれる“LAPI”に基づいて、端末1BがMTCデバイスであると識別する。
基地局2(B)の制御部20は、MME5にNASメッセージを送信する(S9−8)。図18の例では、基地局2(B)には、端末1がMTCデバイスの場合、端末1と無線接続を確立し、端末1とネットワークノードとの通信セッションを開始することを示す制御ポリシーが設定されている。よって、基地局2(B)の制御部20は、MTCデバイスである端末1と無線接続を確立し、MME5に対してNASメッセージを送信する。なお、基地局2(B)の制御部20は、MTCデバイス用のMME5(例えば、図2のMME5(B)、図10の仮想MME5A)に対して、NASメッセージを送信してもよい。
<第4の実施形態>
本発明の第4の実施形態について、図面を参照して説明する。第4の実施形態は、MME5が端末1の端末属性を識別する場合について、3GPPの標準仕様(例えば、3GPP TS23.401)に適用した際の動作例を説明するものである。なお、第4の実施形態の技術は、第1乃至第3の実施形態、および、後述の実施形態のいずれにも適用可能である。
図19は、第4の実施形態の動作例を示すシーケンス図である。図19は、3GPP(3rd Generation Partnership Project)の仕様書(TS23.401 v12.3.0)の5.3.2章に記載された“Attach Procedure”に本発明の技術を適用した動作例を示す。
非MTCデバイス1Aは、基地局2との間で無線によるコネクションを確立するため、基地局2に“RRC Connection Request”を送信する(S10−1)。
“RRC Connection Request”を受信した基地局2(A)は、MME5に、NASメッセージを送信する(S10−2)。
MME5の識別部51は、NASメッセージの受信に応じて、端末属性を識別する(S10−3の“Identify Terminal Property”)。例えばMME5は、基地局2(A)から受信したNASメッセージに、“LAPI”が含まれるか否かに基づいて、端末属性を識別する。図19の例では、基地局2(A)から送信されたNASメッセージには“LAPI”は含まれていない。よって、S10−3において、識別部51は、端末1Aは非MTCデバイスであると識別する。
MME5の識別部51は、端末1Aが非MTCデバイスであると識別したことに応じて、EPS(Evolved Packet System)ベアラの確立手順を開始する(S10−4の“EPS Session Establishment”)。MME5によるEPSベアラの確立手順の開始により、SGW3、PGW4、MME5および基地局2(A)の間で制御信号が交換される。制御信号が各ノード間で交換されることにより、EPSベアラが確立される。非MTCデバイス1Aは、確立されたEPSベアラを介して通信する。基地局2(A)は、非MTCデバイス1Aに関する通信データを、EPSベアラを介して送受信する。
MTCデバイスである端末1B(MTCデバイス1B)は、基地局2(A)に、“RRC Connection Request”を送信する(S10−5)。
“RRC Connection Request”を受信した基地局2(A)は、MME5に、NASメッセージを送信する(S10−6)。
MME5の識別部51は、NASメッセージの受信に応じて、端末属性を識別する(S10−7の“Identify Terminal Property”)。図19の例では、MTCデバイス1Bから送信された“RRC Connection Request”には“LAPI”が含まれる。よって、S10−7において、識別部51は、端末1BがMTCデバイスであると識別する。
MME5の識別部51は、端末1BがMTCデバイスであると識別したことに応じて、端末1Bに対して、基地局2の再選択を指示する制御信号を通知する(S10−8の“Reselection Indication”)。基地局2の再選択を指示する制御信号は、例えば、“RRC Connection Request”が拒否されたことを示す拒否通知(NACK)であってもよい。なお、MME5の識別部51は、拒否通知(NACK)に、拒否理由を示す情報を含めてもよい。拒否理由を示す情報は、例えば、端末1BがMTCデバイスであるために拒否されたこと示す情報である。
MTCデバイス1Bは、他の基地局2(例えば、MTCデバイス用の基地局2(B))に対して、“RRC Connection Request”を再送信する(S10−9)。
MME5の識別部51は、端末1Bに対して基地局2の再選択を指示する制御信号を通知したことに応じて、EPSベアラの確立手順を開始する(S10−10の“EPS Session Establishment”)。MME5によるEPSベアラの確立手順の開始により、SGW3、PGW4、MME5および基地局2(B)の間で制御信号が交換される。制御信号が各ノード間で交換されることにより、EPSベアラが確立される。MTCデバイス1Bは、確立されたEPSベアラを介して通信する。基地局2(B)は、MTCデバイス1Bに関する通信データを、EPSベアラを介して送受信する。
図20乃至22は、第4の実施形態の他の動作例を示すシーケンス図である。図20乃至22は、3GPP(3rd Generation Partnership Project)の仕様書(TS23.401 v12.3.0)の5.3.2章に記載された“Attach Procedure”に本発明の技術を適用した動作例を示す。
非MTCデバイス1Aは、“Attach Request”を基地局2に送信する(S11−1)。基地局2は、“Attach Request”を、MME5に送信する。
MME5は、例えば、受信した“Attach Request”に含まれるIMSI(International Mobile Subscriber Identity)に基づいて、非MTCデバイス1Aの認証手順を実行する(S11−2の“Authentication”)。IMSIは、端末の識別情報である。
MME5は、認証手順において、端末属性を識別する(S11−3)。MME5は、“Attach Request”に含まれるIMSIに基づいて、端末属性を識別する。
図22は、MME5が端末1の認証手順を実行する場合の動作例である。
MME5は、HSS(Home Subscriber Server)7に、“Authentication Information Request”を送信する(S11−11)。“Authentication Information Request”にはIMSIが含まれる。
HSS7は、外部AS(Application Server)がMTCデバイスを識別するための識別情報である“External Identifier”を管理できる。例えば、外部ASは、“External Identifier”に基づいて、MTCデバイスを呼び出す(外部ASがトリガーとなるCall手順)。例えば、M2Mサービス事業者は、MTCデバイスを識別するために、“External Identifier”を用いる。HSS7は、例えば、IMSIと“External Identifier”を関連付けて管理する。
HSS7は、“Authentication Information Request”の受信に応じて、“External Identifier”を検索する(S11−12の“External ID Search”)。HSS7は、例えば、“Authentication Information Request”に含まれるIMSIに対応付けられた“External Identifier”を検索する。
HSS7は、“External Identifier”の検索結果を、“Authentication Information Answer”に含めてMME5に送信する(S11−13)。MME5は、例えば、“Authentication Information Answer”に“External Identifier”が検索されたことを示す情報が含まれる場合、端末がMTCデバイスであると判断する。また、MME5は、例えば、“Authentication Information Answer”に“External Identifier”が検索されたことを示す情報が含まれていない場合、端末がMTCデバイスではないと判断する。
なお、MME5は、受信した“Attach Request”に“LAPI”が含まれるか否かに基づいて、端末属性を識別してもよい。
図20において、MME5の識別部51は、端末1Aが非MTCデバイスであると識別したことに応じて、EPSベアラの確立手順を開始する(S11−4)。
MTCデバイス1Bは、“Attach Request”を基地局2に送信する(S11−5)。基地局2は、“Attach Request”を、MME5に送信する。
MME5は、受信した“Attach Request”に含まれるIMSIに基づいて、MTCデバイス1Bの認証手順を実行する(S11−6)。
MME5は、認証手順において、端末属性を識別する(S11−7)。MME5が端末属性を識別する方法は、図22に示す動作例と同様である。
MME5の識別部51は、端末1BがMTCデバイスであると識別したことに応じて、端末1Bに対して、基地局2の再選択を指示する制御信号を通知する(S11−8)。基地局2の再選択を指示する制御信号は、例えば、“RRC Connection Request”が拒否されたことを示す拒否通知(NACK)であってもよい。
MTCデバイス1Bは、他の基地局2(例えば、MTCデバイス用の基地局2(B))に対して、“Attach Request”を再送信する(S11−9)。
MME5の識別部51は、端末1Bに対して基地局2の再選択を指示する制御信号を通知したことに応じて、EPSベアラの確立手順を開始する(S11−10)。
図23は、第4の実施形態の他の動作例を示すシーケンス図である。図23は、基地局2(A)が、MME5からの指示に応じて、MTCデバイス用の基地局2(B)との間に設定されたX2インターフェースを介して、MTCデバイス1Bのハンドオーバーを実行する場合の動作例である。
MTCデバイス1Bは、“Attach Request”を基地局2に送信する(S12−1)。基地局2は、“Attach Request”を、MME5に送信する。
MME5の制御部50は、“Attach Request”を受信したことに応じて、EPSベアラの確立手順を開始する(S12−2)。MME5によるEPSベアラの確立手順の開始により、SGW3、PGW4、MME5および基地局2(A)の間で制御信号が交換される。制御信号が各ノード間で交換されることにより、EPSベアラが確立される。MTCデバイス1Bは、確立されたEPSベアラを介して通信する。基地局2(A)は、MTCデバイス1Bに関する通信データを、EPSベアラを介して送受信する。
MME5の識別部51は、“Attach Request”に基づいて、端末属性を識別する。識別部51は、端末1BがMTCデバイスである場合、端末1Bに対して、ハンドオーバーの実行を指示する(S12−3の“X2 Handover Indication”)。
基地局2(A)の制御部20は、MME5からの指示に基づいて、例えば、MTCデバイス用の基地局2(B)に対してハンドオーバー要求(Handover Request)を送信する(S12−4)。
基地局2(A)の制御部20は、MTCデバイス用の他の基地局2(B)からのハンドオーバー応答(ACK)に応じて、端末1Bに対して、ハンドオーバー指示(Handover Command)を送信する(S12−5)。
端末1Bは、ハンドオーバー指示を受信したことに応じて、MTCデバイス用の基地局2(B)と接続処理を実行する(S12−6の“Handover”)。
基地局2(B)の制御部20は、MME5に対して、セッションの切り替えを要求する(S12−7の“Session Modify Request”)。
MME5の制御部50は、基地局2(B)からの要求に応じて、セッションの切り替え処理を実行する(S12−8の“Session Modify”)。MME5の制御部50は、例えば、SGW3に対して、基地局2(B)のアドレス、及び、セッションの識別子であるTEID(Tunnel Endpoint Identifier)を通知し、セッションの更新を要求する。MME5の制御部50は、例えば、SGW3から、セッションの更新応答を受信する。
<第5の実施形態>
本発明の第5の実施形態について、図面を参照して説明する。第5の実施形態は、MTCデバイス1Bが、予め受信したMTCデバイス用の基地局2に関する情報に基づいて、接続要求を送信する基地局2を選択可能な場合の実施形態である。
図24は、第5の実施形態の端末1の構成例を示す。図24に例示するように、端末1は、メッセージ生成部10と、通信部11と、選択部12とを含む。なお、メッセージ生成部10は、図6の構成例と同様であるので、詳細な説明は省略される。
通信部11は、MTCデバイス用の基地局2(B)から、基地局2(B)に関する情報を含むシステム情報ブロック(SIB)を受信する。基地局2(B)に関する情報は、例えば、基地局2(B)の各種パラメータに関する情報や、基地局2(B)がカバーするセルに関する情報を含む。基地局2(B)に関する情報は、例えば、MTCデバイス用の基地局であることを示す情報を含む。
通信部11は、メッセージ生成部10が生成したメッセージを、選択部12によって選択された基地局2に送信する。
選択部12は、受信したシステム情報ブロックに基づいて、基地局2の属性を識別可能である。選択部12は、例えば、基地局2(B)から受信したシステム情報ブロック(SIB)に、MTCデバイス用の基地局であることを示す情報が含まれていることに基づいて、該基地局2(B)をMTCデバイス用の基地局と識別する。
選択部12は、端末1の属性に基づいて、メッセージを送信する基地局2を選択する。
選択部12は、例えば、端末1の属性がMTCデバイスである場合、メッセージを送信する基地局2を、MTCデバイス用の基地局2(例えば、基地局2(B))から選択する。
図25は、第5の実施形態の動作例を示すシーケンス図である。
MTCデバイス用の基地局2(B)は、端末1に対して、MTCデバイス用の基地局であることを示す情報を含むシステム情報ブロック(SIB)を、予めブロードキャストする(S13−1)。端末1は、例えば、受信したシステム情報ブロックに、MTCデバイス用の基地局であることを示す情報が含まれていることに基づき、該システム情報ブロックを送信した基地局2(B)をMTCデバイス用の基地局と識別する。
MTCデバイス用の端末1Bは、受信したシステム情報ブロックに基づいて識別されたMTCデバイス用の基地局2(B)に対して、“RRC Connection Request”を送信する(S13−2)。
基地局2(B)の制御部20は、“RRC Connection Request”を受信したことに応じて、MME5にNASメッセージを送信する(S13−3)。基地局2(B)は、MTCデバイス用のMME(例えば、図2のMME(B)5、図10の仮想MME5A)にNASメッセージを送信してもよい。
MME5の識別部51は、NASメッセージを受信したことに応じて、EPSベアラの確立手順を開始する(S13−4)。
図26は、第5の実施形態の動作例を示すシーケンス図である。
MTCデバイス用の基地局2(例えば、基地局2(B))は、端末1および他の基地局2に対して、自装置(例えば、基地局2(B))に関する情報を含むシステム情報ブロック(SIB)を、ブロードキャストする(S14−1)。
S14−2からS14−8の動作例は、図18のS9−2からS9−8の動作例と同様であるため、詳細は省略される。なお、S14−5において、端末1の選択部12が、基地局2(A)からの拒否通知に含まれる情報に基づいて、MTCデバイス用の基地局2(B)を再選択してもよい。また、図18のS9−8と同様に、S14−8において、基地局2(B)の制御部20は、MTCデバイス用のMME5(例えば、図2のMME5(B)、図10の仮想MME5A)に対して、NASメッセージを送信してもよい。
上記のとおり、第5の実施形態は、MTCデバイス1Bが、予め受信したMTCデバイス用の基地局2に関する情報に基づいて、メッセージを送信する基地局2を選択できる。
よって、MTCデバイス1Bは、接続する基地局2の選択及び決定に必要な制御信号の送受信を低減することができる。
<第6の実施形態>
本発明の第6の実施形態について、図面を参照して説明する。第6の実施形態は、端末1と基地局2との接続に関するポリシーをコントローラが集中管理する。よって、端末1と基地局2との接続に関するポリシーの運用管理の効率が向上する。第6の実施形態の技術は、第1乃至第5の実施形態、後述の実施形態のいずれにも適用可能である。
図27は、第6の実施形態の通信システムの構成例を示す図である。
コントローラ8は、基地局2やMME5、制御サーバ6に対して、端末1と基地局2との接続に関するポリシーを通知する機能を有する。
なお、端末1や基地局2、SGW3、PGW4、MME5、制御サーバ6については、上述した実施形態の構成例と同様であるため、詳細な説明は省略される。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
図28は、第6の実施形態のコントローラ8の構成例を示す図である。
コントローラ8は、ポリシー管理DB(Data Base)80、制御部81、インターフェース82を含む。
インターフェース82は、基地局2やMME5、制御サーバ6と通信するためのインターフェースである。コントローラ8は、例えば、インターフェース82を介して、所定のプロトコルで基地局2、MME5及び制御サーバ6と通信できる。
ポリシー管理DB80は、端末1と基地局2との接続に関するポリシーを管理するデータベースである。例えば、ネットワークオペレータが、ポリシー管理DB80にポリシーを入力できる。
制御部81は、ポリシー管理DB80を参照し、基地局2やMME5、制御サーバ6に対してポリシーを通知する。制御部81は、インターフェース82を介して、基地局2やMME5、制御サーバ6に対してポリシーを通知する。
コントローラ8は、例えば、SONサーバである。また、コントローラ8は、例えば、ネットワークオペレータが使用する運用管理装置であってもよい。
ポリシー管理DB80は、例えば、端末1と基地局2との接続に関するポリシーを管理する。ポリシー管理DB80に記憶されるポリシーの例を、以下に示す。
(端末の種別に関するポリシー)
・MTCデバイスからの接続要求を許可し、非MTCデバイスからの接続要求を拒否する。
・非MTCデバイスからの接続要求を許可し、MTCデバイスからの接続要求を拒否する。
・所定のMTCデバイス(例えば、スマートメーター)からの接続要求を許可し、他の種別のMTCデバイスからの接続要求を拒否する。
・所定のMTCデバイスグループに属するMTCデバイスからの接続要求を許可し、他のMTCデバイスグループに属するMTCデバイスからの接続要求を拒否する。
・所定のユーザ属性(例えば、プレミアムユーザ)に対応する端末からの接続要求を許可し、他のユーザ属性(例えば、一般ユーザ)に対応する端末からの接続要求を拒否する。
・所定のユーザ属性(例えば、一般ユーザ)に対応する端末からの接続要求を許可し、他のユーザ属性(例えば、プレミアムユーザ)に対応する端末からの接続要求を拒否する。
・通信量が所定値を超過したユーザの端末からの接続要求を拒否する。
・非MTCデバイス用の基地局に接続したMTCデバイスに、接続する基地局を再選択させる。
・非MTCデバイス用の基地局に接続したMTCデバイスを、他の基地局(例えば、MTCデバイス用の基地局)に再接続させる。
・非MTCデバイス用の基地局に接続したMTCデバイスに対して、他の基地局(例えば、MTCデバイス用の基地局)へのハンドオーバー(Handover)を行う。
・所定の時間帯(Ex:AM1:00−AM4:00)にのみポリシーを有効化。(このポリシーは、上記のポリシーの少なくとも1つと組み合わせて使用される。)
(通信トラフィックの種別に関するポリシー)
・MTC関連のアプリケーションに関する通信トラフィックをMTCデバイス用の基地局で処理する。
・非MTC関連のアプリケーションに関する通信トラフィックを非MTCデバイス用の基地局で処理する。
・通話に関する通信トラフィックを所定の基地局(例えば、非MTCデバイス用の基地局)で処理する。
・所定のアプリケーション(例えば、SNS(Social Networking Service)アプリケーション)に関する通信トラフィックを、所定の基地局で処理する。
・所定のアプリケーション(例えば、SNSアプリケーション)に関する通信トラフィックの一部を、所定の基地局で処理する。
・所定の課金特性(例えば、定額課金)に対応する通信トラフィックを、所定の基地局で処理する。
・所定の課金特性(例えば、従量型課金)に対応する通信トラフィックを、所定の基地局で処理する。
・所定のQoS特性に関する通信トラフィックを、所定の基地局で処理する。
・所定の時間帯(Ex:AM1:00−AM4:00)にのみポリシーを有効化。(このポリシーは、上記のポリシーの少なくとも1つと組み合わせて使用される。)
図29は、第6の実施形態の基地局2の構成例を示す図である。
基地局2は、インターフェース22を介して、コントローラ8と通信する。基地局2は、インターフェース22を介して、コントローラ8からポリシーを受信する。受信したポリシーは、例えば、識別部21に記憶される。制御部22は、例えば、受信したポリシーに基づいて、端末1と基地局2との接続に関する処理を実行する。
なお、制御部20および識別部21は、図3の構成例と同様であるため、詳細な説明は省略される。
MME5は、基地局2と同様に、コントローラ8と通信するためのインターフェースを有していてもよい。MME5は、インターフェースを介して、コントローラ8からポリシーを受信する。MME5は、受信したポリシーに基づいて、端末1と基地局2との接続に関する処理を実行する。
制御サーバ6は、基地局2と同様に、コントローラ8と通信するためのインターフェースを有していてもよい。制御サーバ6は、インターフェースを介して、コントローラ8からポリシーを受信する。制御サーバ6は、受信したポリシーに基づいて、端末1と基地局2との接続に関する処理を実行する。
上記のとおり、第6の実施形態は、端末1と基地局2との接続に関するポリシーをコントローラ8が集中管理する。よって、該ポリシーの運用管理の効率が向上する。
<第7の実施形態>
本発明の第7の実施形態について、図面を参照して説明する。第7の実施形態では、コントローラ8が仮想ネットワークのリソースのプロビジョニングを実行できる。よって、仮想ネットワークの運用管理の効率が向上する。第7の実施形態の技術は、第1乃至第6の実施形態、後述の実施形態のいずれにも適用可能である。
図30は、第7の実施形態の通信システムの構成例を示す。
コントローラ8は、仮想ネットワークのリソースのプロビジョニングを実行する。コントローラ8は、例えば、通信トラフィックのオフロードに備え、仮想ネットワークノード(仮想MME5A、仮想SGW3A、仮想PGW4A等)を運用するためのリソース割り当てを実行する。仮想ネットワークノードを運用するためのリソースは、例えば、サーバ資源、CPU資源、ネットワーク資源(スイッチやルータ)等である。コントローラ8は、例えば、仮想ネットワークノードを運用する仮想マシンやサーバに対して、リソースを割り当てる。
コントローラ8は、例えば、通信トラフィックが増加する時間帯を予測し、当該時間帯に先立って仮想ネットワークのリソースのプロビジョニングを実行できる。また、コントローラ8は、通信トラフィックの増加に応じて、仮想ネットワークのリソースのプロビジョニングを動的に実行できる。
なお、端末1や基地局2、SGW3、PGW4、MME5、仮想SGW3A、仮想PGW4A、仮想MME5A、制御サーバ6については、上述の実施形態の構成例と同様であるため、詳細な説明は省略される。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
図31は、第7の実施形態のコントローラ8の構成例を示す。図31の例では、コントローラ8は、第6の実施形態で例示された構成に加え、仮想ネットワークのリソースのプロビジョニングを実行する仮想NW(ネットワーク)制御部83を含む。第7の実施形態のコントローラ8の構成は、図31の例に限定されない。例えば、第7の実施形態のコントローラ8は、基地局2等に、端末1と基地局2との接続に関するポリシーを通知する機能(ポリシー管理DB80等)を備えなくてもよい。例えば、第6の実施形態のコントローラと、第7の実施形態のコントローラとは、互いに異なる装置であってもよい。
仮想NW制御部83は、仮想ネットワークのリソースのプロビジョニングを実行する。
仮想NW制御部83は、例えば、所定の種別のMTCデバイスによる通信が発生する時間帯に先立って、当該MTCデバイスによる通信トラフィックを処理可能なリソースを仮想ネットワークに割り当てる。
例えば、仮想NW制御部83は、MTCデバイスが送信する制御信号(例えば、ネットワークへの接続要求に関する制御信号)を処理するためのリソースを、仮想MME5Aに割り当てる。また、例えば、仮想NW制御部83は、MTCデバイスが送信するU−Plane(ユーザ・プレーン)データを処理するためのリソースを、仮想SGW3Aや仮想PGW4Aに割り当てる。仮想NW制御部83は、所定の種別のMTCデバイスグループに関する通信トラフィックを処理するためのリソースを仮想ネットワークに割り当ててもよい。仮想NW制御部83は、MTCデバイスによる通信トラフィックが発生しない時間帯は、仮想ネットワークからリソースを解放してもよい。
仮想NW制御部83は、例えば、通信システムにおける通信トラフィックの分析結果に基づいて、通信トラフィックが増加する時間帯を予測する。仮想NW制御部83は、例えば、予測結果に基づいて、増加する通信トラフィックを処理するためのリソースを仮想ネットワークに割り当てる。仮想NW制御部83が、通信トラフィックの分析を実行してもよい。また、仮想NW制御部83は、OSS/BSS(Operation Support System/Business Support System)を介してネットワークオペレータからトラフィック分析の結果を取得してもよい。
例えば、仮想NW制御部83は、増加が見込まれる通信トラフィックの制御信号を処理するためのリソースを、仮想MME5Aに割り当てる。また、例えば、仮想NW制御部83は、増加が見込まれるU−Plane(ユーザ・プレーン)データを処理するためのリソースを、仮想SGW3Aや仮想PGW4Aに割り当てる。
仮想NW制御部83は、例えば、地震等の災害発生に応じて、仮想ネットワークにリソースを割り当てる。また、仮想NW制御部83は、例えば、多数の端末利用者が集まるイベントが開催される日時に先立って、仮想ネットワークにリソースを割り当てる。
例えば、仮想NW制御部83は、災害発生に伴って増加が見込まれる通話やデータ通信を処理するためのリソースを、仮想SGW3A、仮想PGW4A、仮想MME5Aに割り当てる。また、例えば、仮想NW制御部83は、イベントに伴って増加が見込まれる通話やデータ通信を処理するためのリソースを、仮想SGW3A,仮想PGW4A、仮想MME5Aに割り当てる。
仮想NW制御部83は、例えば、仮想ネットワークに要求される性能に基づいて、仮想ネットワークにリソースを割り当てる。例えば、仮想NW制御部83は、仮想ネットワークに要求されるSLA(Service Level Agreement)を満たすように、仮想ネットワークにリソースを割り当てる。
仮想NW制御部83は、例えば、基地局2等に通知済みのポリシーによって仮想ネットワークに流入すると想定される通信トラフィックの量を予測する。仮想NW制御部83は、基地局2等に通知する予定のポリシーによって仮想ネットワークに流入すると想定される通信トラフィックの量を予測してもよい。仮想NW制御部83は、予測された通信量に基づいて、仮想ネットワークにリソースを割り当てる。例えば、仮想NW制御部83は、仮想ネットワークに流入すると想定される通信トラフィックを処理するために必要なリソースを、仮想ネットワークに割り当てる。仮想NW制御部83は、仮想ネットワークに流入すると想定される通信トラフィックを所定のSLAを満たす性能で処理するために必要なリソースを、仮想ネットワークに割り当ててもよい。
なお、コントローラ8の制御部81は、例えば、リソースが割り当てられたことに応じて、端末1と基地局2との接続に関するポリシーを基地局2等に通知してもよい。制御部81は、例えば、上述の第6の実施形態に例示されたポリシーの少なくとも1つを、基地局2等に通知してもよい。
図32は、第7の実施形態の通信装置100の構成例を示す。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
通信装置100の制御部110は、コントローラ8の仮想NW制御部83から、VNF120を実行するための仮想マシンの起動、削除、移行の少なくとも1つの指示を受ける。仮想NW制御部83は、仮想マシンの起動、削除、移行の少なくとも1つを制御部110に指示することにより、仮想ネットワークのリソースを制御できる。
なお、制御部110および仮想ネットワーク機能については、図12の構成例と同様であるため、詳細な説明は省略される。
上記のとおり、第7の実施形態では、コントローラ8が仮想ネットワークのリソースのプロビジョニングを実行できる。よって、仮想ネットワークの運用管理の効率が向上する。
<第8の実施形態>
本発明の第8の実施形態について、図面を参照して説明する。本発明の第8の実施形態では、仮想ネットワークのオペレータは、レガシーネットワークのオペレータに対して、仮想ネットワークを貸し出すことができる。仮想ネットワークのオペレータは、仮想ネットワークの利用料金を得ることができる。また、レガシーネットワークのオペレータは、自らレガシーネットワークへの設備投資をしなくとも、ネットワークを仮想的に増強できる。第8の実施形態の技術は、第1乃至第7の実施形態のいずれにも適用可能である。
図33は、第8の実施形態の通信システムの構成例を示す。
図33の例では、仮想ネットワークのオペレータ(オペレータ:B)は、レガシーネットワークのオペレータ(オペレータ:A)に、仮想ネットワークを貸し出す。オペレータAは、仮想ネットワークに通信トラフィックをオフロードすることで、レガシーネットワークの負荷を軽減できる。
図33の例では、オペレータBが所有する基地局2(B)は、オペレータAの加入者端末の通信トラフィックを仮想ネットワークに送信できる。基地局2(B)は、加入者端末の通信トラフィックを識別し、識別されたトラフィックを仮想ネットワークに送信できる。
基地局2は、上述の実施形態で例示された構成例に基づいて、端末の属性に応じて端末と基地局との接続を制御できる。図33では、例えば、基地局2(B)は、MTCデバイス(端末1B)からの接続要求を許可し、非MTCデバイス(端末1A)からの接続要求を拒否できる。また、例えば、基地局2(A)は、非MTCデバイス(端末1A)からの接続要求を許可し、MTCデバイス(端末1B)からの接続要求を拒否できる。
基地局2(B)は、例えば、上述の第6の実施形態に例示されたポリシーに基づいて、オペレータAの加入者端末の通信トラフィックの一部を、基地局2(B)で処理する。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
図34は、第8の実施形態の通信システムの構成例を示す。
図34の例のように、オペレータAは、オペレータBが所有する仮想ネットワークの利用に対して、オペレータBに料金を支払う。オペレータAは、例えば、月または年単位で、定額の料金をオペレータBに支払う。また、例えば、オペレータAは、仮想ネットワークの利用量に応じた通信料金をオペレータBに支払う。また、例えば、オペレータAは、オペレータA用に仮想ネットワークに割り当てた仮想マシンに対応するリソース量に応じた料金をオペレータBに支払ってもよい。上記の課金方法は例示であり、オペレータAに対する課金方法は、上記の例に限定されない。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
オペレータAは、基地局2に、端末1と基地局2との接続に関するポリシーを設定する。例えば、オペレータAは、上述の第6の実施形態に例示されたポリシーを、基地局2に設定する。オペレータAは、MME5にポリシーを設定してもよい。基地局2やMME5は、設定されたポリシーに従って、端末1が接続する基地局2を選択する。なお、仮想ネットワークのオペレータBが、オペレータAに代替して、基地局2等にポリシーを設定してもよい。
図35は、第8の実施形態の動作例を示すシーケンス図である。
端末1は、基地局2(A)との間で無線によるコネクションを確立するため、基地局2(A)に“Attach Request”を送信する(S15−1)。図35の例では、端末1は、MTCデバイスである。また、図35の例では、基地局2(B)には、MTCデバイスからの接続要求を許可するポリシーが設定されているものとする。
基地局2(B)は、仮想ネットワークをオペレータBから借りたオペレータAに対して、専用の仮想MME5Aを選択できる(S15−2の“Select vMME specific to Operator(A)”)。基地局2(B)は、例えば、仮想ネットワークを利用するオペレータ毎に、仮想MME5Aを管理する。例えば、基地局2の識別部21は、オペレータAに対して、専用の仮想MME5Aを選択できる。
基地局2(B)は、端末1から送信された“Attach Request”を、選択した仮想MME5Aに送信する(S15−3)。
仮想MME5Aは、“Attach Request”の受信に先立って、端末1の認証処理を実行する。仮想MME5Aは、例えば、仮想ネットワークに配置されたHSS7を用いて、端末1を認証する。仮想MME5Aは、レガシーネットワークに配置されたHSS7を用いて端末1を認証してもよい。
HSS7は、例えば、端末1のIMSIと、当該端末1が加入するオペレータに関する情報とを関連付けて管理する。例えば、仮想MME5Aは、上記の認証処理の際、HSS7から、端末1が加入するオペレータに関する情報を取得し、端末1に対応するオペレータを認識する。
仮想MME5Aは、EPSベアラの構築を開始する。図35の例では、仮想MME5Aは、仮想ネットワークをオペレータBから借りたオペレータAに対して、専用のゲートウェイ(仮想SGW3A、仮想PGW4A)を割り当てる。他のオペレータ(例えば、オペレータC)がオペレータBから仮想ネットワークを借りていたとしても、オペレータAとオペレータCには、それぞれ異なるゲートウェイが割り当てられる。仮想ネットワークを利用するオペレータの各々に対して異なるゲートウェイが割り当てられることで、各オペレータに関する通信トラフィックは仮想的に分離され、セキュリティが向上する。
仮想MME5Aは、“Attach Request”の受信に応じて、オペレータA専用の仮想SGW3を選択する(S15−4の“Select vSGW specific to Operator(A)”)。
例えば、仮想MME5Aの識別部51は、仮想ネットワークを利用するオペレータ毎に、仮想エンティティ(仮想SGW3A、仮想PGW4A等)を管理する。仮想MME5Aの制御部50は、識別部51に従って、オペレータAに対応する仮想SGW3Aを選択する。
また、例えば、仮想MME5Aの制御部50は、識別部51が管理する仮想エンティティから、オペレータAに割り当てる仮想SGW3Aを選択する。識別部51は、制御部50に選択された仮想SGW3Aと、当該仮想SGW3Aが割り当てられたオペレータの識別情報とを対応付ける。制御部50は、仮想SGW3Aを選択する際、識別部51が管理する仮想エンティティのうち、オペレータの識別情報が対応付けられていない仮想エンティティを選択する。
仮想MME5Aは、S15−4で選択した仮想SGW3Aに対して、“Create Session Request”メッセージを送信する(S15−5)。仮想MME5Aは、仮想ネットワークをオペレータBから借りたオペレータAに対して、専用の仮想PGW4Aを割り当てる。仮想MME5Aは、“Create Session Request”メッセージに、オペレータAに割り当てられた仮想PGW4AのIPアドレスを含める。
例えば、仮想MME5Aの識別部51は、仮想ネットワークを利用するオペレータ毎に、仮想エンティティ(仮想SGW3A、仮想PGW4A等)を管理する。仮想MME5Aの制御部50は、識別部51に従って、オペレータAに対応する仮想PGW4AのIPアドレスを“Create Session Request”メッセージに含める。
また、例えば、仮想MME5Aの制御部50は、識別部51が管理する仮想エンティティから、オペレータAに割り当てる仮想PGW4Aを選択する。識別部51は、制御部50に選択された仮想PGW4Aと、当該仮想PGW4Aが割り当てられたオペレータの識別情報とを対応付ける。制御部50は、仮想PGW4Aを選択する際、識別部51が管理する仮想エンティティのうち、オペレータの識別情報が対応付けられていない仮想エンティティを選択する。
仮想MME5Aから“Create Session Request”メッセージを受信したことに応じて、仮想SGW3Aは、受信したメッセージで指定された仮想PGW4Aに対して、“Create Session Request”メッセージを送信する(S15−6)。仮想SGW3Aは、仮想PGW4Aに送信するメッセージに、自身のIPアドレスを含める。
仮想PGW4Aは、仮想SGW3Aに対して、“Create Session Response”メッセージを返信する(S15−7)。
仮想SGW3Aは、仮想MME5Aに対して、“Create Session Response”メッセージを返信する(S15−8)。“Create Session Response”メッセージの受信に応じて、仮想MME5Aは、基地局2に対して、仮想SGW3Aと基地局2との間でセッションを構築するための情報を通知する。
以上の図35に例示された動作により、仮想ネットワークにEPSベアラが構築される。オペレータAのレガシーネットワークの加入者端末(図35中の端末1)は、構築されたEPSベアラを介して通信する。
図36は、第8の実施形態の他の動作例を示すシーケンス図である。
基地局2(B)は、端末1から送信された“Attach Request”を、仮想MME5Aに送信する(S16−1)。図36の例では、端末1は、MTCデバイスである。また、図36の例では、基地局2(B)には、MTCデバイスからの接続要求を許可するポリシーが設定されているものとする。
仮想MME5Aは、“Attach Request”の受信に先立って、端末1の認証処理を実行する。仮想MME5Aは、例えば、仮想ネットワークに配置されたHSS7を用いて、端末1を認証する。仮想MME5Aは、レガシーネットワークに配置されたHSS7を用いて端末1を認証してもよい。
HSS7は、例えば、端末1のIMSIと、当該端末1が加入するオペレータに関する情報とを関連付けて管理する。例えば、仮想MME5Aは、上記の認証処理の際、HSS7から、端末1が加入するオペレータに関する情報を取得し、端末1に対応するオペレータを認識する。
仮想MME5Aは、仮想SGW3Aに対して、“Create Session Request”メッセージを送信する(S16−2)。仮想MME5Aは、例えば、端末1に対応するオペレータに関する情報を“Create Session Request”に含める。仮想MME5Aは、“Create Session Request”メッセージを送信することで、EPSベアラの構築を開始する。
図36の例では、仮想MME5A、仮想SGW3A、仮想PGW4Aは、それぞれ、仮想ネットワークをオペレータBから借りたオペレータAに関するベアラに対して、専用のTEIDを割り当てる。他のオペレータ(例えば、オペレータC)がオペレータBから仮想ネットワークを借りていたとしても、オペレータAとオペレータCに関するベアラには、それぞれのオペレータ特有のTEIDが割り当てられる。仮想ネットワークを利用するオペレータの各々に対して特有のTEIDが割り当てられることで、セキュリティが向上する。
仮想SGW3Aは、仮想PGW4Aに対して、“Create Session Request”メッセージを送信する(S16−3)。仮想SGW3Aは、オペレータAの加入者端末である端末1に、オペレータA用のTEIDを割り当てる。仮想SGW3Aは、選択したTEIDを、“Create Session Request”メッセージに含める。また、仮想SGW3Aは、端末1に対応するオペレータに関する情報を“Create Session Request”に含めてもよい。
例えば、仮想SGW3Aは、仮想ネットワークを利用するオペレータ毎に、各オペレータに割り当てる候補のTEID群を管理する。例えば、仮想SGW3Aは、オペレータAに割り当てる候補のTEID群や、オペレータCに割り当てる候補のTEID群を管理する。仮想SGW3Aは、仮想MME5Aから通知されたオペレータ情報に基づいて、TEIDを選択する。
また、例えば、仮想SGW3Aは、TEID群から、オペレータAに割り当てるTEIDを選択する。仮想SGW3Aは、選択されたTEIDと、当該TEIDが割り当てられたオペレータの識別情報とを対応付ける。仮想SGW3Aは、TEIDを選択する際、オペレータの識別情報が対応付けられていないTEIDを選択する。
仮想PGW4Aは、仮想SGW3Aに、“Create Session Response”メッセージを返信する(S16−4)。仮想PGW4Aは、オペレータAの加入者端末である端末1に、オペレータA用のTEIDを割り当てる。仮想PGW4Aは、選択したTEIDを、“Create Session Response”メッセージに含める。仮想PGW4Aは、例えば、仮想SGW3Aと同様の方法でTEIDを選択する。
仮想SGW3Aは、仮想MME5Aに対して、“Create Session Response”メッセージを送信する(S16−5)。仮想SGW3Aは、オペレータAの加入者端末である端末1に、オペレータA用のTEIDを割り当てる。仮想SGW3Aは、選択したTEIDを、“Create Session Response”メッセージに含める。“Create Session Response”メッセージの受信に応じて、仮想MME5Aは、基地局2(B)に対して、仮想SGW3Aと基地局2(B)との間でセッションを構築するための情報を通知する。
以上の図36に例示された動作により、仮想ネットワークにEPSベアラが構築される。オペレータAのレガシーネットワークの加入者端末(図36中の端末1)は、構築されたEPSベアラを介して通信する。
図37は、第8の実施形態の通信システムの他の構成例を示す図である。
図37の例は、仮想ネットワークのオペレータ(オペレータB)が、仮想ネットワークを借りたオペレータ(図37では、オペレータA及びオペレータC)の通信トラフィックをモニタする構成例を示す。図37の例では、仮想ネットワークを借りたオペレータ毎に、仮想SGW3Aや仮想PGW4Aが配置される。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
図37の例では、仮想ネットワークに配置された仮想PCRF(Policy and Charging Rule Function)40が、通信トラフィックをモニタする。図37の例では、仮想ネットワークをオペレータBから借りたオペレータ(オペレータA、オペレータC)毎に、仮想PCRF40が配置される。
仮想ネットワークのオペレータBは、例えば、コントローラ8(不図示)により、仮想ネットワークに仮想PCRF40を配置する。例えば、コントローラ8の仮想NW制御部83は、仮想ネットワークを利用するオペレータAに関する通信トラフィックを監視するための仮想PCRF40を、仮想ネットワークに配置する。
例えば、仮想PGW4Aの各々は、各仮想PGW4Aに対応付けられたオペレータ用の仮想PCRF40と接続する。仮想PGW4Aの各々は、PCEF(Policy and Charging Enforcement Function)機能によりパケット数をカウントする。仮想PGW4Aの各々は、各仮想PGW4Aに接続された仮想PCRF40に、パケット数のカウント結果を転送する。
仮想ネットワークのオペレータ(オペレータB)は、各仮想PCRF40によるパケットのカウント数をモニタし、仮想ネットワークを利用するオペレータ毎の通信量を取得する。オペレータBは、例えば、オペレータ毎の通信量に基づいて、各オペレータに仮想ネットワークの使用料金を請求する。
上記のとおり、第8の実施形態は、仮想ネットワークのオペレータが、レガシーネットワークのオペレータに対して、仮想ネットワークを貸し出すことができる。よって、仮想ネットワークのオペレータは、仮想ネットワークの利用料金を得ることができる。また、レガシーネットワークのオペレータは、自らレガシーネットワークへの設備投資をしなくとも、ネットワークを仮想的に増強できる。
図38は、第8の実施形態の通信システムの他の構成例を示す図である。
図38において、オペレータBは、オペレータAが保有する通信ネットワークを借りて、移動通信サービスを提供する事業者である。オペレータBは、いわゆる仮想移動体通信事業者(MVNO:Mobile Virtual Network Operator)である。オペレータAは、通信ネットワークを保有する移動体通信事業者(MNO:Mobile Network Operator)であり、当該通信ネットワークをオペレータBに貸し出す。オペレータAは、オペレータBに対して、通信ネットワークの利用料金を請求する。なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
MVNOには、モバイル網で用いるトンネリングプロトコル(例えば、GTP:GPRS(General Packet Radio Service) Tunneling Protocol)を終端可能なゲートウェイ(例えば、P−GW)を保有するか否かにより、2つのタイプ(保有する場合:レイヤー2接続型、保有しない場合:レイヤー3接続型)が存在する。図38は、オペレータBがレイヤー3接続型のMVNOである場合の構成例である。オペレータBがレイヤー2接続型の場合、オペレータBは、例えば、図38のPGW4及び仮想PGW4Aに対応する機能を有するPGWを、オペレータAとは別に保有する。
図38において、オペレータAは、例えば、オペレータBに対して、レガシーネットワークと仮想ネットワークとを貸し出す。
オペレータAの基地局2(A)は、オペレータBの加入者端末のうち非MTCデバイスと識別した端末の通信トラヒックを、レガシーネットワークに送信する。また、オペレータAの基地局2(A)は、オペレータBの加入者端末のうちMTCデバイスと識別した端末に対して、例えば、接続要求が拒否されたことを示す拒否通知を送信する。
オペレータAの基地局2(B)は、オペレータBの加入者端末のうちMTCデバイスと識別した端末の通信トラヒックを、仮想ネットワークに送信する。なお、オペレータAの基地局2(A)及び基地局2(B)は、オペレータAの加入者端末に対しても、オペレータBの加入者端末に対する処理と同様の処理を実行可能である。
オペレータAは、例えば、レガシーネットワーク及び仮想ネットワークにおけるオペレータBの加入者端末の通信量や、加入者端末数に応じて、オペレータBに利用料金を請求する。
上記のとおり、第8の実施形態では、通信ネットワークを保有するオペレータが、当該通信ネットワークを保有しないオペレータに対して、通信ネットワークを貸し出すこともできる。
以上、本発明の実施形態を説明したが、本発明は、上記したそれぞれの実施形態に限定されるものではない。本発明は、各実施形態の変形・置換・調整に基づいて実施できる。
また、本発明は、各実施形態を任意に組み合わせて実施することもできる。即ち、本発明は、本明細書の全ての開示内容、技術的思想に従って実現できる各種変形、修正を含む。
また、本発明は、SDN(Software−Defined Network)の技術分野にも適用可能である。
また、本発明において、端末1又はネットワークノード(基地局(eNB)2、SGW3、PGW4、MME5)のコンピュータ、CPU(Central Processing Unit)又はMPU(Micro−Processing Unit)等が、上述した各実施形態の機能を実現するソフトウェア(プログラム)を実行してもよい。端末1又は各ネットワークノードは、例えばCD−R(Compact Disc Recordable)等の各種記憶媒体又はネットワークを介して、上述した各実施形態の機能を実現するソフトウェア(プログラム)を取得してもよい。端末1又は各ネットワークノードが取得するプログラムや該プログラムを記憶した記憶媒体は、本発明を構成することになる。なお、該ソフトウェア(プログラム)は、例えば、端末1又は各ネットワークノードに含まれる所定の記憶部に、予め記憶されていてもよい。端末1又は各ネットワークノードのコンピュータ、CPU又はMPU等は、取得したソフトウェア(プログラム)のプログラムコードを読み出して実行してもよい。したがって、端末1又は各ネットワークノードは、上述した各実施形態における端末1又は各ネットワークノードの処理と同一の処理を実行する。
この出願は、2014年11月21日に出願された日本出願特願2014−236080を基礎とする優先権を主張し、その開示の全てをここに取り込む。