JP6407114B2

JP6407114B2 - 通信システム、通信方法、通信ノード装置、及びプログラム

Info

Publication number: JP6407114B2
Application number: JP2015161590A
Authority: JP
Inventors: 徹也日紫喜; 巧大羽; 新小池
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2015-08-19
Filing date: 2015-08-19
Publication date: 2018-10-17
Anticipated expiration: 2035-08-19
Also published as: JP2017041714A

Description

本発明は、通信システム、通信方法、通信ノード装置、及びプログラムに関する。

特に、モバイルネットワークに収容される端末は、無線リソース関連の処理に大きな電力消費が必要であるとして、大きなバッテリ容量が期待できないセンサなどのＭ２Ｍ端末への適用を想定した低消費電力モード（ＰＳＭ（Power Saving Mode）等）が、３ＧＰＰで議論された（非特許文献１）。例えば、ＰＳＭ状態にある端末は、無線ベアラが確立されていない状態となるため、あるアプリケーションサーバが、ＰＳＭ状態の端末にメッセージ送信を試みてもメッセージは必ず非到達となり、プロトコルや実装によって決まる再送回数／タイムアウト値を超えた時点でエラーとなるか、いたずらにネットワークの負荷が高まった結果として破棄されることとなる。標準化団体である３ＧＰＰでは、アプリケーションサーバにとってもネットワーク事業者にとってもこの無駄な再送制御が望ましくないとして、次の（１）及び（２）の２つの方法で解決を行うこがを議論・規定されている（非特許文献２）。

（１）アプリケーションサーバは、端末の状態によらずにメッセージを送信する。メッセージを受け取ったネットワークは、ネットワーク内のノード（Serving GW）にメッセージをバッファしておき、端末がＰＳＭ等を抜けてアタッチ処理が行われた際にメッセージを配信する。これはページング処理を拡張することで実現される（以下、当該技術を「バッファ技術」という。）。

（２）ネットワークは、端末の状態をイベントとして通知するためのインタフェース（ＯＭＡ（Open Mobile Aliance）等で規定されるＡＰＩ、例えば、非特許文献３）を用意しておき、アプリケーションサーバは、メッセージ配信の必要性が生じたタイミングでそのイベントに購読依頼を出す。端末がＰＳＭ等を抜けてアタッチ処理が行われると、アプリケーションサーバへイベントが通知される。そのイベントを受け取ったアプリケーションサーバは、当該イベントに基づいて、端末が現在通信可能であることを知ることができるため、メッセージを配信する（以下、当該技術を「通知技術」という。）。

また、関連する市中技術として、アプリケーションサーバからの通知などのダウンリンクメッセージ配信をスマートフォンに向けて送信するためのシステムが存在している（以下、当該技術を「Ｐｕｓｈ技術」という。）。これは、主に、消費電力削減を目指しており、スマートフォン上の各アプリケーションが各アプリケーションサーバに接続を行うのではなく、代表して通信を束ねるＰｕｓｈサーバにのみ接続を確立し、まとめてメッセージを受け取るための仕組みである（非特許文献４）。

3GPP TS 23.682 V13.1.0 Architecture enhancements to facilitate communications with packet data networks and applications 3GPP TR 23.709 V1.2.0 Study on Optimizations to Support High Latency Communications Open Mobile Alliance, "Guidelines for RESTful Network APIs Approved - 27 Feb 2014", OMA-WP-Guidelines_for_RESTful_Network_APIs-20140227-A Google Cloud Messaging、［online］、［平成２７年７月１７日検索］、インターネット〈URL：https://developers.google.com/cloud-messaging/〉

しかしながら、バッファ技術を利用する場合は、ネットワーク内のノード（Serving-GW）にメッセージをストアすることになるため、現在ページングに利用している以外の余計なストレージが必要となるうえ、処理負荷がかかる。したがって、端末やアプリケーション数の爆発的な増加により、ページング処理などの現在のＳ−ＧＷの処理に支障をきたす懸念がある。また、既存機能への追加実装は、スケーラビリティの観点からも望ましいとは言えない。さらに、固定網への適用を考えると、そもそもメッセージをバッファするエンティティが存在せず、この技術の適用は困難である。

また、通知技術を利用する場合は、アプリケーションサーバに正しくイベントを使ってもらう必要がある。ネットワークがいくら端末の状態をイベントとして提供しても、アプリケーションサーバがそのイベントに対応できない実装を有している場合には、結局、再送制御を繰り返すことになる。また、ネットワークプロバイダが、自身のネットワークをコントロールできなくなる可能性がある。

更に、Ｐｕｓｈ技術を利用する場合は、端末は、ＰＳＭ等の低消費電力モードを抜けたタイミングで、毎回、自らＰｕｓｈサーバにメッセージを取りにいく必要がある。このためには、端末が（ａ）通信路確立後にＰｕｓｈサーバへの接続が必要であること、及び（ｂ）Ｐｕｓｈサーバのアドレス、の２点を知っている必要があり、当該機能を具備しない端末には適用が困難である。また、スマートフォンなどの高機能な端末が利用する想定から、一般的にはＨＴＴＰ等のプロトコルが利用されており、端末の処理負荷が上昇する懸念がある。

また、メッセージの完全性や秘匿性、表現するデータモデルなどは規定されていない。

本発明は、上記の点に鑑みてなされたものであって、端末へのダウンリンクメッセージの配信を効率的に実現することを目的とする。

そこで上記課題を解決するため、端末へのメッセージを送信するアプリケーションサーバと、前記アプリケーションサーバにネットワークを介して接続される通信ノード装置とを含む通信システムであって、前記通信ノード装置は、自装置を利用する端末と前記アプリケーションサーバとの双方について初期接続時に認証を実施する認証部と、前記アプリケーションサーバから前記端末へのメッセージを受信する受信部と、前記アプリケーションサーバが前記認証部によって認証済みである場合に、前記受信部によって受信されたメッセージを記憶する記憶部と、ネットワークに対する前記端末の接続を検出する検出部と、前記検出部によって前記端末の接続が検出されると、当該端末が前記認証部によって認証済みである場合に、当該端末の識別子を宛先とするメッセージを前記記憶部から取得して、取得されたメッセージを当該端末に送信する送信部と、を有する。

端末へのダウンリンクメッセージの配信を効率的に実現することができる。

本発明の実施の形態における通信システムのシステム構成例を示す図である。本発明の実施の形態における通信ノード装置のハードウェア構成例を示す図である。本発明の実施の形態における通信ノード装置の機能構成例を示す図である。端末の認証処理の処理手順の一例を説明するためのシーケンス図である。アプリケーションの認証処理の処理手順の一例を説明するためのシーケンス図である。アプリケーションからのダウンリンクメッセージの配信処理の一例を説明するためのシーケンス図である。移動網における通信ノード装置の実現例を示す図である。プロトコルマッピングの第１の例を示す図である。プロトコルマッピングの第２の例を示す図である。プロトコルマッピングの第３の例を示す図である。プロトコルマッピングの第４の例を示す図である。プロトコルマッピングの第５の例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における通信システムのシステム構成例を示す図である。図１において、１以上のアプリケーションサーバ２０及び１以上の端末３０は、通信ネットワークＮ１に接続される。また、通信ネットワークＮ１は、通信ノード装置１０等を含む。したがって、各アプリケーションサーバ２０及び各端末３０は、通信ネットワークＮ１を介して通信ノード装置１０と通信可能である。

アプリケーションサーバ２０は、１以上のアプリケーションが実装された１以上のコンピュータである。アプリケーションサーバ２０は、例えば、サービス事業者によって提供される。アプリケーションサーバ２０（の各アプリケーション）は、通信ネットワークＮ１を介して端末３０に対して何らかのダウンリンクメッセージを送信する。送信されるダウンリンクメッセージは、ＣｏＡＰ（Constrained Application Protocol）やＭＱＴＴ（MQ Telemetry Transport）といった軽量なＭ２Ｍ向けプロトコルを利用したものでもよいし、ＨＴＴＰ（HyperText Transfer Protocol）やＨＴＴＰ／２等の高機能プロトコルを利用したものでもよいが、これらに限らない。

端末３０は、通信ネットワークＮ１を介してアプリケーションサーバ２０からのダウンリンクメッセージを受信する端末である。例えば、端末３０は、ＰＳＭ（Power Saving Mode）等、低消費電力モードをサポートするものであってもよいし、当該低消費電力モードをサポートしないものであってもよい。各端末３０が受信するダウンリンクメッセージは、ＣｏＡＰやＭＱＴＴといった軽量なＭ２Ｍ向けプロトコルを利用したものでもよいし、ＨＴＴＰやＨＴＴＰ／２等の高機能プロトコルを利用したものでもよいが、これらに限らない。

通信ノード装置１０は、アプリケーションサーバ２０から端末３０へのダウンリンクメッセージの伝達を仲介する装置である。通信ノード装置１０からはＩＰ等のプロトコルを利用して到達可能となるケースを主眼するが、端末３０が存在するネットワークの内部にＮＡＴ／ＦＷ等の装置／システム／ソフトウェアがあるケースを除外するものではない。但し、この場合は静的又は動的な設定（ＩＰアドレスやポート番号、ＭＡＣアドレス等によりフィルタリングやホワイトリストの適用を含むがこれに限らない。）により通信ノード装置１０から端末３０への通信路を確保することが必要である。

図２は、本発明の実施の形態における通信ノード装置のハードウェア構成例を示す図である。図２の通信ノード装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

通信ノード装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って通信ノード装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

図３は、本発明の実施の形態における通信ノード装置の機能構成例を示す図である。図３において、通信ノード装置１０は、通信部１１、端末イベント部１２、認証部１３、及びメッセージ処理部１４等を含む。これら各部は、通信ノード装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

なお、図３に示される構成以外の構成が採用されてもよい。また、実装上の観点からは、通信ノード装置１０は、１つのノードとして実装されている必要もなく、さらに、図３では、説明の便宜上４つの機能部が設けられているが、他の機能部から共通的に利用される通信部１１を除き、これらにも実装上の制約等はない。例えば、端末イベント部１２の一部の機能と認証部１３の一部の機能だけを１つのノードに実装する、といったことも可能である。そのため、通信ネットワークＮ１内に既に関連機能が具備されている場合は、その一部だけを通信ノード装置１０の一部として利用することもでき、例えば、認証処理部１３３と端末管理部１３２とは、既に通信ネットワークＮ１が具備している認証のためのメカニズムが利用されて実現されてもよい。

通信部１１は、他の機能部から共通的に利用される、通信に関する機能を提供する。図３において、通信部１１は、通信管理部１１１及び通信処理部１１２等を含む。

通信管理部１１１は、通信処理部１１２が行う通信を管理する。例えば、通信管理部１１１は、５−ｔｕｐｌｅによる通信の識別や、ＴＣＰ（Transmission Control Protocol）のセッション維持など、通信の実現に必要な管理を行う。

通信処理部１１２は、通信ネットワークＮ１を介してアプリケーションサーバ２０や端末３０と通信をするために必要な処理を行う。通信処理部１１２は、通信ネットワークＮ１がサポートするＴＣＰ／ＩＰのプロトコルスタックの利用可能性を提供しつつ、端末３０及びアプリケーションサーバ２０が利用する上位プロトコル（ＣｏＡＰなどが該当するがこれに限らない）の利用可能性を提供する。

端末イベント部１２は、端末３０に関して発生したイベントを検出し、当該イベントをメッセージ処理部１４に提供する。図３において、端末イベント部１２は、端末イベント検出部１２１及び端末イベント提供部１２２等を含む。

端末イベント検出部１２１は、端末３０がＰＳＭなどの低消費電力モードから復帰し通信が可能となった際にその状態変化を検出する。

端末イベント提供部１２２は、端末イベント検出部１２１が端末３０の状態変化を検出した時に、メッセージ処理部１４に対して当該状態変化を示すイベントを提供する。

認証部１３は、通信ノード装置１０を利用する端末３０とアプリケーションサーバ２０との双方についての認証等を実施する。図３において、認証部１３は、アプリケーション管理部１３１、端末管理部１３２、認証処理部１３３、及び管理用ＤＢ１３４等を含む。

アプリケーション管理部１３１は、アプリケーションサーバ２０におけるアプリケーションからのダウンリンクメッセージを受け取り、認証処理部１３３に当該アプリケーションが認証済みであるかどうかを問い合わせる。認証処理部１３３から認証済みであることが通知された場合、アプリケーション管理部１３１は、受け取ったダウンリンクメッセージをメッセージ管理部１４１に転送する。認証処理部１３３から認証が済んでいないことが通知された場合、アプリケーション管理部１３１は、認証が必要であることをアプリケーションへと通知する。

端末管理部１３２は、端末３０からのリクエストを受け取り、認証処理部１３３に当該端末３０を接続してよいかを問い合わせる。認証処理部１３３から接続許可が通知された場合、端末管理部１３２は、接続成功レスポンスを端末３０に返す。認証処理部１３３から接続許可が通知されない場合、端末管理部１３２は、接続失敗レスポンスを端末３０に返す。

認証処理部１３３は、アプリケーション管理部１３１及び端末管理部１３２からの認証要求に応じてアプリケーション又は端末３０の認証を実施し、その結果を認証要求元に返送する。アプリケーションの認証は、認証要求に係るアプリケーションの識別子と、管理用ＤＢ１３４に動的又は静的に設定された、接続可能なアプリケーションの識別子とを照合することで行われる。認証要求に係るアプリケーションの識別子に合致する識別子が管理用ＤＢ１３４に含まれている場合、認証処理部１３３は、認証成功レスポンスを返す。認証要求に係るアプリケーションの識別子に合致する識別子が管理用ＤＢ１３４に含まれていない場合、認証処理部１３３は、認証失敗レスポンスを返す。アプリケーションの識別子とは、例えば、ドメイン名、ＦＱＤＮ（Fully Qualified Domain Name）、ＩＰアドレス、事前に双方（アプリケーション及び管理用ＤＢ１３４）に設定された文字列、又はそれらをハッシュ化した値等であるが、これらに限られない。また、これら複数の情報が組み合わせされてもよい。端末３０の認証は、認証要求に係る端末３０の識別子と、管理用ＤＢ１３４に動的又は静的に設定された、接続可能な端末３０の識別子とを照合することにより行われる。認証要求に係る端末３０の識別子に合致する識別子が管理用ＤＢ１３４に含まれている場合、認証処理部１３３は、認証成功レスポンスを返す。認証要求に係る端末３０の識別子に合致する識別子が管理用ＤＢ１３４に含まれていない場合、認証処理部１３３は、認証失敗レスポンスを返す。端末３０の識別子とは、例えば、ＵＩＣＣ（Universal Integrated Circuit Card）の情報、ＭＡＣアドレス、ＩＰアドレス、事前に双方（端末３０及び管理用ＤＢ１３４）に設定された文字列、又はそれらをハッシュ化した値等であるが、これらに限られない。また、これらの複数の情報が組み合わされてもよい。

管理用ＤＢ１３４は、認証処理部１３３が参照する管理用のデータベースであり、接続可能なアプリケーションの識別子と、接続可能な端末３０の識別子とを含む。なお、管理用ＤＢ１３４は、補助記憶装置１０２、又は通信ノード装置１０にネットワークを介して接続可能な記憶装置を用いて実現可能である。

メッセージ処理部１４は、アプリケーションが端末３０に送信するダウンリンクメッセージを処理する。図３において、メッセージ処理部１４は、メッセージ管理部１４１、暗号処理部１４２、パススルー部１４３、及びメッセージ用ＤＢ１４４等を含む。

メッセージ管理部１４１は、認証部１３のアプリケーション管理部１３１から送られてくるダウンリンクメッセージを受け取り、当該ダウンリンクメッセージのストア要求（保存要求）をメッセージ用ＤＢ１４４に送る。メッセージ管理部１４１は、また、端末イベント提供部１２２から送られたイベントに基づいて、メッセージ用ＤＢ１４４に問い合わせを行い、当該イベントに係る端末３０に対する１又は複数のダウンリンクメッセージが有れば、当該ダウンリンクメッセージを端末３０へと送信する。

暗号処理部１４２は、ダウンリンクメッセージの暗号化又は復号等を行う。アプリケーションサーバ２０と通信ノード装置１０との間の通信路と、通信ノード装置１０と端末３０の間の通信路とのそれぞれに対して暗号化通信が必要となる場合に、通信処理部１１２によって、ダウンリンクメッセージの暗号化又は復号が行われる。

パススルー部１４３は、アプリケーションがエンドツーエンドでの通信路確立が必要な場合にＴＣＰやＵＤＰ（User Datagram Protocol）による通信をパススルーして転送する。

メッセージ用ＤＢ１４４は、メッセージ管理部１４１が参照するダウンリンクメッセージ用のＤＢであり、送信するためのダウンリンクメッセージを含んでいる。各ダウンリンクメッセージは、メッセージの本文の他に、ダウンリンクメッセージごとの識別子と、送信元のアプリケーションの識別子と、宛先の端末の識別子とを含む。なお、メッセージ用ＤＢ１４４は、補助記憶装置１０２、又は通信ノード装置１０にネットワークを介して接続可能な記憶装置を用いて実現可能である。

以下、通信システムにおいて実行される処理手順について説明する。処理手順の説明において、通信部１１に関する処理は、一般的な通信の処理に関するものであるため省略される。

図４は、端末の認証処理の処理手順の一例を説明するためのシーケンス図である。

端末３０は、初期接続時に、端末管理部１３２に対して認証要求を送信する（ステップＳ１０１）。当該認証要求には、当該端末３０の識別子（以下、「端末ＩＤ」という。）が含まれる。続いて、端末管理部１３２は、認証処理部１３３に対して当該認証要求を転送する（ステップＳ１０２）。続いて、認証処理部１３３は、当該認証要求に含まれている端末ＩＤが、接続可能な端末ＩＤとして登録されているか否かを管理用ＤＢ１３４に問い合わせる（ステップＳ１０３）。管理用ＤＢ１３４は、問い合わせの対象の端末ＩＤの登録の有無を示す応答を、認証処理部１３３に返送する（ステップＳ１０４）。

認証処理部１３３は、管理用ＤＢ１３４からの応答に基づいて、接続の可否を判定し、その判定結果を、認証結果として端末管理部１３２に送信する（ステップＳ１０５）。すなわち、認証要求に含まれている端末ＩＤが管理用ＤＢ１３４に登録されていれば、接続は可能であると判定され、そうでなければ、接続は不可能であると判定される。続いて、端末管理部１３２は、認証処理部１３３から受け取った認証結果を端末３０に送信する（ステップＳ１０６）。なお、端末管理部１３２は、例えば、認証に成功した端末３０の端末ＩＤのリストを記憶しておく。

図５は、アプリケーションの認証処理の処理手順の一例を説明するためのシーケンス図である。

アプリケーションサーバ２０のアプリケーションは、初期接続時に、アプリケーション管理部１３１に対して認証要求を送信する（ステップＳ２０１）。当該認証要求には、当該アプリケーションの識別子（以下、「アプリケーションＩＤ」という。）が含まれる。続いて、アプリケーション管理部１３１は、認証処理部１３３に対して当該認証要求を転送する（ステップＳ２０２）。続いて、認証処理部１３３は、認証要求に含まれているアプリケーションＩＤが、接続可能なアプリケーションＩＤとして登録されているか否かを管理用ＤＢ１３４に問い合わせる（ステップＳ２０３）。管理用ＤＢ１３４は、問い合わせの対象のアプリケーションＩＤの登録の有無を示す応答を、認証処理部１３３に返送する（ステップＳ２０４）。

認証処理部１３３は、管理用ＤＢ１３４からの応答に基づいて、接続の可否を判定し、その判定結果を、認証結果としてアプリケーション管理部１３１に送信する（ステップＳ２０５）。すなわち、認証要求に含まれているアプリケーションＩＤが管理用ＤＢ１３４に登録されていれば、接続は可能であると判定され、そうでなければ、接続は不可能であると判定される。続いて、アプリケーション管理部１３１は、認証処理部１３３から受け取った認証結果をアプリケーションに送信する（ステップＳ２０６）。なお、アプリケーション管理部１３１は、例えば、認証に成功したアプリケーションのアプリケーションＩＤのリストを記憶しておく。

図６は、アプリケーションからのダウンリンクメッセージの配信処理の一例を説明するためのシーケンス図である。図６では、先に述べた端末３０の認証処理及びアプリケーションの認証処理が事前に済んでいるか、又は端末３０及びアプリケーションに関して認証処理が必要ない状態と想定する。

アプリケーションサーバ２０のアプリケーションは、端末３０に配信したいダウンリンクメッセージが生じた任意のタイミングで、ダウンリンクメッセージをアプリケーション管理部１３１に送信する（ステップＳ３０１）。ダウンリンクメッセージには、当該ダウンリンクメッセージの送信元のアプリケーションのアプリケーションＩＤと、当該ダウンリンクメッセージの宛先の１以上の端末ＩＤとが含まれている。

アプリケーション管理部１３１は、当該ダウンリンクメッセージを受信すると、当該ダウンリンクメッセージの送信元のアプリケーションが認証済みであることを確認し、認証済みであれば、当該ダウンリンクメッセージをメッセージ管理部１４１に転送する（ステップＳ３０２）。ダウンリンクメッセージの送信元のアプリケーションが認証済みであるか否かは、例えば、当該ダウンリンクメッセージに含まれているアプリケーションＩＤが、認証に成功したアプリケーションＩＤのリストに含まれているか否かに基づいて判定可能である。なお、認証済みでない場合、アプリケーション管理部１３１は、例えば、エラーを示す情報を、アプリケーションに送信する。

メッセージ管理部１４１は、アプリケーション管理部１３１から転送されたダウンリンクメッセージを受信すると、当該ダウンリンクメッセージのストア要求をメッセージ用ＤＢ１４４に送信する（ステップＳ３０３）。メッセージ用ＤＢ１４４は、ダウンリンクメッセージをストア（記憶）すると、ストアが正常に完了した旨の応答を返信する（ステップＳ３０４）。当該応答に応じ、メッセージ管理部１４１は、ダウンリンクメッセージを正常に受け取ったことを示す情報（以下、「受け取り確認」という。）を、アプリケーション管理部１３１に返信する（ステップＳ３０５）。続いて、アプリケーション管理部１３１は、受け取り確認をアプリケーションに返信する（ステップＳ３０６）。受け取り確認には、送信されたダウンリンクメッセージの識別子（以下、「メッセージＩＤ」という。）が含まれてもよい。

一方、端末３０は、低消費電力モードから復帰すると、通信ネットワークＮ１へのアタッチ処理を実行する（ステップＳ３１１）。端末イベント検出部１２１は、当該アタッチ処理を検出すると、当該アタッチ処理の発生を示す接続イベントを端末イベント提供部１２２へ送信する（ステップＳ３１２）。なお、当該接続イベントには、当該アタッチ処理に係る端末３０の端末ＩＤが含まれる。続いて、端末イベント提供部１２２は、当該接続イベントをメッセージ管理部１４１へ転送する（ステップＳ３１３）。

メッセージ管理部１４１は、当該接続イベントを受信すると、当該接続イベントに含まれる端末ＩＤを宛先に含むダウンリンクメッセージの検索要求を、メッセージＤＢに送信する（ステップＳ３１４）。メッセージ用ＤＢ１４４は、該当するダウンリンクメッセージが有れば、該当する全てのダウンリンクメッセージをメッセージ管理部１４１へと返送する（ステップＳ３１５）。メッセージ管理部１４１は、当該ダウンリンクメッセージを受信すると、当該ダウンリンクメッセージを、接続イベントに含まれている端末ＩＤに係る端末３０へ送信する（ステップＳ３１６）。続いて、メッセージ管理部１４１は、送信されたダウンリンクメッセージごとに、正常に送信されたことを示す確認情報をアプリケーション管理部１３１に送信する（ステップＳ３１７）。例えば、確認情報には、送信されたダウンリンクメッセージの送信元のアプリケーションのアプリケーションＩＤと、当該ダウンリンクメッセージのメッセージＩＤとが含まれる。続いて、アプリケーション管理部１３１は、各確認情報について、当該確認情報に含まれるアプリケーションＩＤに係るアプリケーションに対して、当該確認情報を送信する（ステップＳ３１８）。

次に、通信ネットワークＮ１が、移動網（ＥＰＣ：Evolved Packet Core）である場合の通信ノード装置１０の実現例について説明する。図７は、移動網における通信ノード装置の実現例を示す図である。図７の例では、認証部１３及び端末イベント部１２はそれぞれ既にＥＰＣが具備する認証メカニズムと端末イベント検出メカニズムを利用するものとしているが、独自に実装を行うことも可能である。

図７のＰＳＦ（Push server function）は、本実施の形態において追加された機能エンティティであり、通信ノード装置１０のうちの通信部１１及びメッセージ処理部１４を担う。また、端末イベント検出部１２１は、ＥＰＣが具備するＳＣＥＦ（Service Capability Exposure Function）に実装されており、端末３０のアタッチが行われると、ＰＳＦは、そのイベントをＳＣＥＦ経由で取得することが可能となっている。なお、ＰＳＦの配備にはいくつかのバリエーションが考えられ、図７に示される例に限定されない。

図７の（１）では、ＰＳＦがアプリケーションサーバ２０と接続点を有しており、ダウンリンクメッセージは、アプリケーションサーバ２０から直接的にＰＳＦへと送信される。ＰＳＦは、ダウンリンクメッセージをストアしておき、ＳＣＥＦからイベントを受け取ったタイミングで端末３０にむけてメッセージを送信する。この場合、ダウンリンクメッセージの経路にはＳＣＥＦが含まれないため、ＳＣＥＦの処理負荷の軽減を図ることができる。

図７の（２）では、ＰＳＦは、ＳＣＥＦ経由でＡＳと接続され、ダウンリンクメッセージは、ＡＳからＳＣＥＦ経由でＰＳＦへと送信される。ＰＳＦは、ＳＣＥＦから端末３０のイベントを、ダウンリンクメッセージを送信した接続点と同じ又は異なる接続点を介して受け取ったタイミングで、端末３０に向けてダウンリンクメッセージを送信する。この場合、ＰＳＦは、移動網における外部への機能提供を行うＳＣＥＦよりネットワークの内側に存在することとなるため、ＳＣＥＦが責任分解点となって、ＰＳＦのセキュリティリスク等をそれほど気にしなくともサービス提供が可能となる。

次に、プロトコルマッピングの一例について説明する。図８は、プロトコルマッピングの第１の例を示す図である。図８では、端末３０―通信ノード装置１０間は、ＣｏＡＰ／ＵＤＰを利用しているが、通信ノード装置１０―アプリケーション間は、ＨＴＴＰ／ＴＣＰを利用している。レベル１及びレベル２のプロトコルは、それぞれの区間で共通であってもよいし、異なっていてもよい。また、移動網などで利用されるように、レベル１及びレベル２のプロトコルはトンネルが確立されオーバレイされた構造を有していてもよい。

図９は、プロトコルマッピングの第２の例を示す図である。図９では、端末３０―通信ノード装置１０間は、ＣｏＡＰ／ＵＤＰを利用しているが、通信ノード装置１０―アプリケーション間は、暗号化を利用するＨＴＴＰ／ＴＬＳ（Transport Layer Security）／ＴＣＰを利用している。

図１０は、プロトコルマッピングの第３の例を示す図である。図１０では、端末３０―通信ノード装置１０間もＣｏＡＰ／ＤＴＬＳ（Datagram Transport Layer Security）／ＵＤＰを利用して暗号化通信を利用しており、通信ノード装置１０―アプリケーション間も暗号化を利用するＨＴＴＰ／ＴＬＳ／ＴＣＰを利用している。

図１１は、プロトコルマッピングの第４の例を示す図である。図１１では、端末３０―通信ノード装置１０間でＭＱＴＴ／ＴＬＳ／ＴＣＰを利用して暗号化通信を利用しており、通信ノード装置１０―アプリケーション間も暗号化を利用するＨＴＴＰ／ＴＬＳ／ＴＣＰを利用している。

図１２は、プロトコルマッピングの第５の例を示す図である。図１２では、通信ノード装置１０は、ＴＣＰを終端して転送する役目を担っており、パススルーをするエンティティとして動作し、端末３０とアプリケーションとの間で決められたプロトコルを利用可能である。

なお、プロトコルマッピングは、上記の例に限定されない。

次に、ダウンリンクメッセージの秘匿性確保の方法について説明する。ダウンリンクメッセージの秘匿性は、暗号化が必要な区間においてＴＣＰやＵＤＰ上で典型的に利用される暗号化プロトコルであるＴＬＳやＤＴＬＳを利用して通信路自体を保護することで担保することができる。また、通信路自体を保護するのではなく、端末３０とアプリケーションとの間で決められたルールに則ってダウンリンクメッセージ自体を暗号化するＯｂｊｅｃｔＬｅｖｅｌＥｎｃｒｙｐｔｉｏｎを利用することもできる。また、メッセージの完全性の確認として、Ｓｕｂ−ｒｅｓｏｕｒｃｅＩｎｔｅｇｒｉｔｙなどのハッシュ値による完全性のチェックを行うこともできる。

上述したように、本実施の形態によれば、通信ノード装置１０は、アプリケーションからのダウンリンクメッセージをストア（記憶）し、通信ネットワークＮ１に対する端末３０の接続に応じて、当該端末３０宛のダウンリンクメッセージを当該端末３０に対して配信する。したがって、端末３０へのダウンリンクメッセージの配信を効率的に実現することができる。

すなわち、本実施の形態によれば、「通知技術」で課題となっていた「アプリケーションサーバの実装に依存する」という課題を解決することができる。すなわち、アプリケーションサーバ２０は、端末３０の通信状態を気にすることなく非効率な再送制御を防ぐことができ、さらに、ネットワーク提供者は、アプリケーションサーバ２０に依存せずに自分たちのネットワークの適切な管理を実現することができる。

また、本実施の形態によれば、「Ｐｕｓｈ技術」で課題となっていた「端末がＰｕｓｈサーバへの接続の必要性やそのアドレスを知っていることが必須」及び「端末３０が高度なプロトコルを利用する必要がある」という課題を解決し、端末３０の実装に依存することなく効率的なダウンリンク通信を利用することができる。

なお、本実施の形態における通信ノード装置１０は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

なお、本実施の形態において、アプリケーション管理部１３１は、受信部の一例である。メッセージ用ＤＢ１４４は、記憶部の一例である。端末イベント検出部１２１は、検出部の一例である。メッセージ管理部１４１は、送信部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０通信ノード装置
１１通信部
１２端末イベント部
１３認証部
１４メッセージ処理部
２０アプリケーションサーバ
３０端末
１００ドライブ装置
１０１記録媒体
１０２補助記憶装置
１０３メモリ装置
１０４ＣＰＵ
１０５インタフェース装置
１１１通信管理部
１１２通信処理部
１２１端末イベント検出部
１２２端末イベント提供部
１３１アプリケーション管理部
１３２端末管理部
１３３認証処理部
１３４管理用ＤＢ
１４１メッセージ管理部
１４２暗号処理部
１４３パススルー部
１４４メッセージ用ＤＢ
Ｂバス
Ｎ１通信ネットワーク

Claims

端末へのメッセージを送信するアプリケーションサーバと、前記アプリケーションサーバにネットワークを介して接続される通信ノード装置とを含む通信システムであって、
前記通信ノード装置は、
自装置を利用する端末と前記アプリケーションサーバとの双方について初期接続時に認証を実施する認証部と、
前記アプリケーションサーバから前記端末へのメッセージを受信する受信部と、
前記アプリケーションサーバが前記認証部によって認証済みである場合に、前記受信部によって受信されたメッセージを記憶する記憶部と、
ネットワークに対する前記端末の接続を検出する検出部と、
前記検出部によって前記端末の接続が検出されると、当該端末が前記認証部によって認証済みである場合に、当該端末の識別子を宛先とするメッセージを前記記憶部から取得して、取得されたメッセージを当該端末に送信する送信部と、
を有することを特徴とする通信システム。
前記検出部は、低消費電力モードから復帰した端末による前記ネットワークへの接続を検出する、
ことを特徴とする請求項１記載の通信システム。
端末へのメッセージを送信するアプリケーションサーバと、前記アプリケーションサーバにネットワークを介して接続される通信ノード装置とを含む通信システムにおける通信方法であって、
前記通信ノード装置が、
自装置を利用する端末と前記アプリケーションサーバとの双方について初期接続時に認証を実施する認証手順と、
前記アプリケーションサーバから前記端末へのメッセージを受信する受信手順と、
前記アプリケーションサーバが前記認証手順によって認証済みである場合に、前記受信手順において受信されたメッセージを記憶部に記憶する記憶手順と、
ネットワークに対する前記端末の接続を検出する検出手順と、
前記検出手順において前記端末の接続が検出されると、当該端末が前記認証手順によって認証済みである場合に、当該端末の識別子を宛先とするメッセージを前記記憶部から取得して、取得されたメッセージを当該端末に送信する送信手順と、
を実行することを特徴とする通信方法。
自装置を利用する端末とアプリケーションサーバとの双方について初期接続時に認証を実施する認証部と、
前記アプリケーションサーバから前記端末へのメッセージを受信する受信部と、
前記アプリケーションサーバが前記認証部によって認証済みである場合に、前記受信部によって受信されたメッセージを記憶する記憶部と、
ネットワークに対する前記端末の接続を検出する検出部と、
前記検出部によって前記端末の接続が検出されると、当該端末が前記認証部によって認証済みである場合に、当該端末の識別子を宛先とするメッセージを前記記憶部から取得して、取得されたメッセージを当該端末に送信する送信部と、
を有することを特徴とする通信ノード装置。
請求項４記載の通信ノード装置が有する各部としてコンピュータを機能させるためのプログラム。