(57)【要約】  本発明のシステムは、デバイスがグループメッセージを受信できなかった場合でも、シグナリングの削減によるネットワークの輻輳やオーバーロードを回避して障害へ対処する通信処理システムに関するものである。本通信処理システムは、訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）を構成する通信処理システムであって、アプリケーションから複数のデバイスに送信するグループメッセージ送信要求を取得するグループメッセージ送信要求取得部と、グループメッセージ送信要求を複数のデバイスに送信するグループメッセージ送信要求部と、複数のデバイスによるグループメッセージ送信要求への応答を、所定時間内に受信できない場合、応答を受信できなかったデバイスを含むサービスエリアのエラー情報に基づいて、応答を受信できなかったデバイスを含むサービスエリアに対してグループメッセージ送信要求の再送信を指示する再送信指示部と、を備える。
2017051664.tif 000002
【特許請求の範囲】
【請求項１】
訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）を構成する通信処理システムであって、
アプリケーションから複数のデバイスに送信するグループメッセージ送信要求を取得するグループメッセージ送信要求取得手段と、
前記グループメッセージ送信要求を前記複数のデバイスに送信するグループメッセージ送信要求手段と、
前記複数のデバイスによる前記グループメッセージ送信要求への応答を、所定時間内に受信できない場合、応答を受信できなかったデバイスを含むサービスエリアのエラー情報に基づいて、応答を受信できなかったデバイスを含む前記サービスエリアに対してグループメッセージ送信要求の再送信を指示する再送信指示手段と、
を備える通信処理システム。
【請求項２】
前記エラー情報を生成するエラー情報生成手段をさらに備え、
前記エラー情報生成手段は、３ＧＰＰのグループメッセージ処理に規定されたＭＣＥに含まれ、セッション開始から最初のデータ配信までの時間が所定時間を超えた場合に、前記所定時間を超えたサービスエリア識別子を含むＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージ、または、ＳＥＳＳＩＯＮ ＳＴＡＲＴ  ＦＡＩＬＵＲＥメッセージを生成する、請求項１に記載の通信処理システム。
【請求項３】
前記再送信指示手段は、３ＧＰＰのグループメッセージ処理に規定されたＢＭ−ＳＣに含まれ、前記所定時間を超えたサービスエリア識別子を含む前記エラー情報の返信に応答して、応答を受信できなかったデバイスを含むサービスエリアに対してグループメッセージ送信要求の再送信を指示する、請求項１または２に記載の通信処理システム。
【請求項４】
前記再送信指示手段は、応答を受信できなかったデバイスを含む複数のサービスエリア識別子を受信した場合、障害を受信した順序で、または、グループメッセージに含まれる優先度に応じた順序で、グループメッセージ送信要求の再送信を指示する、請求項３に記載の通信処理システム。
【請求項５】
前記所定時間を超えたサービスエリア識別子は、各メッセージのＣＡＵＳＥの領域のデータとして伝達される、請求項１乃至４のいずれか１項に記載の通信処理システム。
【請求項６】
３ＧＰＰのグループメッセージ処理に規定され、前記エラー情報を受信したＭＭＥは、前記所定時間を超えたサービスエリア識別子をＳＥＳＳＩＯＮ ＳＴＡＲＴ  ＲＥＳＰＯＮＳＥメッセージ、または、ＳＥＳＳＩＯＮ ＳＴＡＲＴ  ＦＡＩＬＵＲＥメッセージによりＭＢＭＳ−ＧＷに返信する、請求項１乃至５のいずれか１項に記載の通信処理システム。
【請求項７】
３ＧＰＰのグループメッセージ処理に規定され、前記エラー情報を受信したＭＢＭＳ−ＧＷは、前記所定時間を超えたサービスエリア識別子をＳＥＳＳＩＯＮ ＳＴＡＲＴ  ＦＡＩＬＵＲＥメッセージによりＢＭ−ＳＣに返信する、請求項１乃至６のいずれか１項に記載の通信処理システム。
【請求項８】
訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）を構成する通信処理システムのグループメッセージ処理方法であって、
アプリケーションから複数のデバイスに送信するグループメッセージ送信要求を取得するグループメッセージ送信要求取得ステップと、
前記グループメッセージ送信要求を前記複数のデバイスに送信するグループメッセージ送信要求ステップと、
前記複数のデバイスによる前記グループメッセージ送信要求への応答を、所定時間内に受信できない場合、応答を受信できなかったデバイスを含むサービスエリアのエラー情報を生成するエラー情報に基づいて、応答を受信できなかったデバイスを含む前記サービスエリアに対してグループメッセージ送信要求の再送信を指示する再送信指示ステップと、
を含むグループメッセージ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信処理システム、および、グループメッセージ処理方法に関する。
【背景技術】
【０００２】
ＩｏＴ(Internet of Things)システムでは、ネットワークに接続された膨大な数のＭＴＣ(Machine Type Communication)デバイスとデータのやりとりを行う必要がある。したがって、膨大な数のＭＴＣデバイスからのデータメッセージ、あるいは膨大な数のＭＴＣデバイスへの制御メッセージの数を低減化することが求められている。このために、地域的あるいは性質的に同グループに属するＭＴＣデバイスに対して一括的にメッセージを送信する方法が検討されている。このために、非特許文献１(TR 23.888)では、同じエリア内のデバイスや同じ機能を持つデバイスをグループ化し、同一グループに対して一括的にメッセージを送信することによって、ＭＴＣデバイスとやり取りされるメッセージ数を低減し、ネットワークの輻輳の回避やリソースのセーブを行うことについて記載されている。【０００３】
非特許文献２(TR 23.887)では、グループメッセージの送信方法についていくつかの方法が示されている。具体的には、セル-ブロードキャストサービス（ＣＢＣ：Cell Broadcast Center,ＣＢＳ：Cell Broadcast Service)を使う方法、ＭＢＭＳ(Multimedia Broadcast and Multicast Service)を使う方法、ＩＰ(Internet Protocol)マルチキャストを使う方法が記載されている。ＳＣＳ(Service Capability Server)からのグループメッセージは、ＭＴＣデバイスに送信される。無線アクセス網の一時的な障害等のなんらかの事情により、ＭＴＣデバイスがグループメッセージを受信できなかった場合、ＳＣＳに対してその旨が通知され(Action in Response to Group Messaging)、必要に応じてＳＣＳより、再送などの処理が実行される。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP TR 23.888 V11.0.0 (2012-09)
【非特許文献２】3GPP TR 23.887 V12.0.0 (2013-12)
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記文献に記載の技術において、ＳＣＳからのグループメッセージは、最終的に基地局から複数のセルグループに対して送信されるが、無線アクセス網の一時的な障害などで一部のセルグループでのセション確立ができず、ＭＴＣデバイスでのグループメッセージの受信ができない障害が発生することが考えられる。この場合の復旧手順は明確ではない。【０００６】
3GPP TS 23.246の「6.3.2項 Quality-of Service for EPS」によれば、以下の記載がある。「When the ＭＢＭＳ bearer service experience a packet error ratio which is not suitable for the ＭＢＭＳ user service or when prevention of data loss is required, an ＭＢＭＳ user service may perform retransmission of ＭＢＭＳ data over a point-to-point PDP context or PDN connection.」。つまり、「ＭＢＭＳベアラでパケットエラーが発生してＭＢＭＳユーザサービスに適さない場合、またはデータロスへの防御が必要な場合は、ＭＢＭＳユーザサービスは、ポイント・ツー・ポイントＰＤＰまたはＰＤＮ接続で再送してもよい」となっている。しかし、ポイント・ツー・ポイント通信を使用したのでは、シグナリングの削減によるネットワークの輻輳やオーバーロードを回避するという当初の目的が達成できないという課題がある。【０００７】
本発明の目的は、上述の課題を解決する技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明に係る通信処理システムは、
訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）を構成する通信処理システムであって、
アプリケーションから複数のデバイスに送信するグループメッセージ送信要求を取得するグループメッセージ送信要求取得手段と、
前記グループメッセージ送信要求を前記複数のデバイスに送信するグループメッセージ送信要求手段と、
前記複数のデバイスによる前記グループメッセージ送信要求への応答を、所定時間内に受信できない場合、応答を受信できなかったデバイスを含むサービスエリアのエラー情報に基づいて、応答を受信できなかったデバイスを含む前記サービスエリアに対してグループメッセージ送信要求の再送信を指示する再送信指示手段と、
を備える。【０００９】
上記目的を達成するため、本発明に係るグループメッセージ処理方法は、
訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）を構成する通信処理システムのグループメッセージ処理方法であって、
アプリケーションから複数のデバイスに送信するグループメッセージ送信要求を取得するグループメッセージ送信要求取得ステップと、
前記グループメッセージ送信要求を前記複数のデバイスに送信するグループメッセージ送信要求ステップと、
前記複数のデバイスによる前記グループメッセージ送信要求への応答を、所定時間内に受信できない場合、応答を受信できなかったデバイスを含むサービスエリアのエラー情報を生成するエラー情報に基づいて、応答を受信できなかったデバイスを含む前記サービスエリアに対してグループメッセージ送信要求の再送信を指示する再送信指示ステップと、
を含む。
【発明の効果】
【００１０】
本発明によれば、デバイスがグループメッセージを受信できなかった場合でも、シグナリングの削減によるネットワークの輻輳やオーバーロードを回避した障害への対処をすることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１実施形態に係る通信処理システムの構成を示すブロック図である。
【図２】本発明の第２実施形態に係る通信処理システムの動作を示すシーケンス図である。
【図３Ａ】前提技術である3GPP TS 23.887に規定された通信処理システムの動作を示すシーケンス図である。
【図３Ｂ】前提技術である3GPP TS 23.887に規定された通信処理システムの構成を示すブロック図である。
【図３Ｃ】前提技術である3GPP TS 23.246に規定された通信処理システムの動作を示すシーケンス図である。
【図３Ｄ】前提技術である3GPP TS 36.300に規定された通信処理システムの動作を示すシーケンス図である。
【図３Ｅ】前提技術である3GPP TS 29.061に規定された通信処理システムの動作を示すシーケンス図である。
【図４】本発明の第２実施形態に係る通信処理システムのＭＣＥの処理手順を示すフローチャートである。
【図５Ａ】前提技術である3GPP TS 36.300に規定された通信処理システムにおけるＭＣＥの配置を示すブロック図である。
【図５Ｂ】前提技術である3GPP TS 36.300に規定されたＭ３インタフェースの制御プレーンを示す図である。
【図５Ｃ】本発明の第２実施形態に係るＭＣＥで使用される、前提技術である3GPP TS 36.444に規定されたＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージのフォーマットを示す図である。
【図５Ｄ】本発明の第２実施形態で使用される、前提技術である3GPP TS 36.444に規定されたＣＡＵＳＥのフォーマットを示す図である。
【図５Ｅ】本発明の第２実施形態で使用される、前提技術である3GPP TS 29.274に規定されたＣＡＵＳＥの値を示す図である。
【図６】本発明の第２実施形態に係る通信処理システムのＭＭＥの処理手順を示すフローチャートである。
【図７】本発明の第２実施形態に係るＭＭＥで使用される、前提技術である3GPP TS 29.274に規定されたＭＥＭＳ  Ｓｅｓｓｉｏｎ  Ｓｔａｒｔ Ｒｅｓｐｏｎｓｅメッセージのフォーマットを示す図である。
【図８】本発明の第２実施形態に係る通信処理システムのＭＢＭＳ−ＧＷの処理手順を示すフローチャートである。
【図９】本発明の第２実施形態で使用される、前提技術である3GPP TS 36.444に規定されたＭＥＭＳ  Ｓｅｓｓｉｏｎ  Ｓｔａｒｔ Ｆａｉｌｕｒｅメッセージのフォーマットを示す図である。
【図１０】本発明の第２実施形態に係る通信処理システムのＢＭ−ＳＣの処理手順を示すフローチャートである。
【図１１】本発明の第３実施形態に係る通信処理システムのＢＭ−ＳＣの処理手順を示すフローチャートである。
【図１２】本発明の第４実施形態に係る通信処理システムの動作を示すシーケンス図である。
【図１３】本発明の第５実施形態に係る通信処理システムの動作を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
以下に、図面を参照して、本発明の実施の形態について例示的に詳しく説明する。ただし、以下の実施の形態に記載されている構成要素は単なる例示であり、本発明の技術範囲をそれらのみに限定する趣旨のものではない。
【００１３】
［第１実施形態］
本発明の第１実施形態としての通信処理システム１００について、図１を用いて説明する。通信処理システム１００は、訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）を構成するシステムである。
【００１４】
図１に示すように、通信処理システム１００は、グループメッセージ送信要求取得部１０１と、グループメッセージ送信要求部１０２と、再送信指示部１０３と、を含む。グループメッセージ送信要求取得部１０１は、アプリケーションから複数のデバイスに送信するグループメッセージ送信要求を取得する。グループメッセージ送信要求部１０２は、グループメッセージ送信要求を複数のデバイスに送信する。再送信指示部１０３は、複数のデバイスによる前記グループメッセージ送信要求への応答を、所定時間内に受信できない場合、応答を受信できなかったデバイスを含むサービスエリアのエラー情報に基づいて、応答を受信できなかったデバイスを含むサービスエリアに対してグループメッセージ送信要求の再送信を指示する。
【００１５】
本実施形態によれば、エラー発生時に訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）内でグループメッセージを再送信するので、デバイスがグループメッセージを受信できなかった場合でも、シグナリングの削減によるネットワークの輻輳やオーバーロードを回避した障害への対処ができる。
【００１６】
［第２実施形態］
次に、本発明の第２実施形態に係る通信処理システムについて説明する。本実施形態に係る通信処理システムは、アプリケーションからホーム公衆陸上移動ネットワーク（ＨＰＬＭＮ：Home Public Land Mobile Network）を介して伝えられたデバイスグループへのグループメッセージを、デバイスのエラーが発生しても訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ：Visited Public Land Mobile Network）内でグループメッセージの再送を実現する。そのため。デバイスがグループメッセージを受信できなかった場合でも、シグナリングの削減によるネットワークの輻輳やオーバーロードを回避した障害への対処ができる。
【００１７】
《前提技術》
（ＳＣＳとＵＥ間でのグループメッセージ送信）
まず、図３Ａを参照して、前提技術である3GPP(Third Generation Partnership Project) TS 23.887に規定されたＭＴＣ−ＩＷＦ(Machine Type Communication-Interworking Function)の動作シーケンスを示す。図３ＡのFigure 8.1.3.2.1.1-2は、ＭＢＭＳを用いたグループメッセージの送信手順を示している、外部ＡＳ(Application Server)からのグループメッセージ送信要求を受けたＳＣＳ(Service Capability Server)は、3GPPコアネットワークのＭＴＣ−ＩＷＦにグループメッセージの送信要求を行う。
【００１８】
このグループメッセージ送信要求には、以下の情報が含まれる。１）アプリケーション層のデータ(Application layer Data)２）グループ識別子(Group Identifier)、例えば、外部グループ識別子(External Group Identifier)３）オプションとして、グループメッセージ配信先の、ロケーション/エリア(Location/Area)、および無線アクセス技術(ＲＡＴ:Radio Access Technology)
【００１９】
ＳＣＳからグループメッセージを受けたＭＴＣ−ＩＷＦは、ＳＣＳがグループメッセージ送信を許可されているかどうかをチェックする。具体的には、ＨＳＳ/ＨＬＲ(Home Subscriber Server／Home Location Register)に対し、外部グループ識別子(External Group ＩＤ)とＳＣＳ ＩＤを含む加入者情報要求を行う。これは、ＳＣＳが特定のグループに対しグループメッセージの送信が許可されているどうかの確認と、特定のグループについての加入情報を得るためである。ＨＳＳ/ＨＬＲは、加入情報とあらかじめ設定されたポリシに基づいてＣＢＳやＭＢＭＳなどのメッセージの配信方法を加入者情報応答としてＭＴＣ−ＩＷＦに返信する。なお、ＳＣＳがグループメッセージの送信を許可されていない場合、または加入情報が無効であった場合、ＭＴＣ−ＩＷＦは、その理由を表示したグループメッセージ確認応答をＳＣＳに送信した後、グループメッセージ送信手順をストップする。他の場合は手順を進める。
【００２０】
ＭＴＣ−ＩＷＦは、ＨＳＳ/ＨＬＲから受けた情報とあらかじめ定められたポリシをもとにＣＢＳ、ＭＢＭＳ、コアネットワークなどの配信方法を選択する。もし、ＭＴＣ−ＩＷＦがＭＢＭＳを選択した場合、ＢＭ−ＳＣ／ＭＢＭＳ-ＧＷ(Broadcast Multimedia - Service Center／ＭＢＭＳ - Gateway）に対しＭＢＭＳサービスエリア情報を含むセション開始要求(Session Start Request)を送信し、これを受けたＭＢＭＳ-ＧＷは、ＭＭＥ／ＳＧＳＮとセション開始手順を行い、ＭＴＣデバイスとの接続が確立される。その後、ＭＴＣ−ＩＷＦは、アプリケーション層データの送信を開始するが、より最適化のため、前記セション開始要求に前記アプリケーション層データを含めてもよい。
【００２１】
以降、ＳＣＳからのグループメッセージが、ＭＴＣデバイスに送信される。なお、無線アクセス網の一時的な障害等のなんらかの事情により、ＭＴＣデバイスがグループメッセージを受信できなかった場合、ＳＣＳに対してその旨が通知され（“Action in Response to Group Messaging”）、必要に応じてＳＣＳより、再送などの処理が実行される。
【００２２】
（システム構成）
図３Ｂは、前提技術である3GPP TS 23.887に規定された通信処理システムの構成を示すブロック図である。なお、図３Ｂは、ＭＢＭＳベースのグループメッセージ処理の標準アーキテクチャであり、構成要素の詳細な説明は省略する。
【００２３】
（ＢＭ−ＳＣとＵＥ間でのグループメッセージ送信）
図３Ｃは、前提技術である3GPP TS 23.246に規定された通信処理システムの動作を示すシーケンス図である。なお、図３Ｃは、本実施形態に関連する、訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）内での標準動作シーケンスであり、シーケンスの詳細な説明は省略する。図３Ｃの標準動作シーケンスでは、セッション開始処理中のデバイス状態によるエラーが発生した場合、訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）内で再処理できず、ホーム公衆陸上移動ネットワーク（ＨＰＬＭＮ）においてグループメッセージ送信の再要求となる。
【００２４】
（ＭＭＥとＵＥ間でのグループメッセージ送信）
図３Ｄは、前提技術である3GPP TS 36.300に規定された通信処理システムの動作を示すシーケンス図である。なお、図３Ｄは、本実施形態に関連する、ＭＭＥとＵＥ間での標準動作シーケンスであり、シーケンスの詳細な説明は省略する。図３Ｄの標準動作シーケンスでは、セッション開始処理中のデバイス状態によるエラーが発生した場合にも、リアルタイムに把握できず、グループメッセージ送信処理が終わった後で、ホーム公衆陸上移動ネットワーク（ＨＰＬＭＮ）においてグループメッセージ送信の再要求となる。
【００２５】
（ＢＭ−ＳＣとＭＢＭＳ−ＧＷ間でのグループメッセージ送信）
図３Ｅは前提技術である3GPP TS 29.061に規定された通信処理システムの動作を示すシーケンス図である。なお、図３Ｅは、ＢＭ−ＳＣとＭＢＭＳ−ＧＷ間での標準動作シーケンスであり、シーケンスの詳細な説明は省略する。図３Ｅの標準動作シーケンスでは、セッション開始処理中のデバイス状態によるエラーが発生した場合にも、それを通知するメッセージが設けられてないので、グループメッセージ送信処理が終わった後でホーム公衆陸上移動ネットワーク（ＨＰＬＭＮ）においてグループメッセージ送信の再要求となる。
【００２６】
《本実施形態の概略》
本実施形態においては、グループメッセージを送信した各セルグループに対し、セッション確立の有無を、基地局とＭＭＥ間に論理的に定義されたＭＣＥ(Multi-cell/multicast Coordination Entity)で検出し、設定された時間以内にセッション確立ができなかったセルグループ単位でセション確立障害情報をＭＭＥ経由でＢＭ−ＳＣに送信する。なお、ＭＣＥは3GPP TS 23.300に記載されている。ＢＭ−ＳＣはセション確立障害が発生したセルグループに対してセルグループ単位でグループメッセージを再送することで、ポイント・ツー・ポイント通信を使うことなく、グループメッセージをより確実にセルグループに所属するＭＴＣデバイスに配信するものである。すなわち、ＢＭ−ＳＣ／ＭＢＭＳ−ＧＷ、ＭＭＥ、ＵＴＲＡＮ／Ｅ−ＵＴＲＡＮなどのネットワークノードとセルグループに含まれるＭＴＣデバイスによるセッション確立手順において、例えば無線区間の干渉、フェージングなどにより、あるセルグループのＭＴＣデバイスとのセッション確立ができなかった場合、一次的には基地局とＭＣＥ間でタイムアウト（Minimum time to wait before the first data delivery timer）を検出する。そして、セルグループ単位（ＳＡＩ単位）でこれをセション確立障害情報としてＭＭＥを経由し、ＢＭ−ＳＣに送信する。セション障害情報を受信したＢＭ−ＳＣは、障害発生の報告を受けたセルグループ単位に、グループメッセージの再送を行うものである。
【００２７】
《動作シーケンス》
図２は、本実施形態に係る通信処理システムの動作を示すシーケンス図である。なお、図２において、前提技術の図３Ｃと同様のシーケンスについては説明を省略する。以下では、本実施形態により、変更あるいは付加されたシーケンスにステップ番号を付して、説明する。これが、本実施形態のコアネットワークである通信処理システムのグループメッセージ処理方法となる。
【００２８】
ＭＣＥは、ステップＳ２０１において、グループメッセージのセッション開始処理が所定時間（最短待機時間）内に終了して最初のデータ配信が行なわれない（タイムアウト）を、検出する。そして、ＭＣＥは、ステップＳ２０２において、タイムアウトとなったサービスエリア識別子(ＳＡＩ(s))を含む、ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージをＭＭＥに送信する。ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージを受けたＭＭＥは、ステップＳ２０３において、ＭＢＭＳ Session Start ResponseにＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージのＳＡＩ(s)を含ませて、ＭＢＭＳ−ＧＷに送信する。ＳＡＩ(s)を含んだＭＢＭＳ Session Start Responseを受けたＭＢＭＳ−ＧＷは、ステップＳ２０４において、ＭＢＭＳ−ＧＷとＢＭ−ＳＣ間で新たに定義したＭＢＭＳ Session Start FailureにＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージのＳＡＩ(s)を含ませて、ＢＭ−ＳＣに送信する。ＢＭ−ＳＣは、ＭＢＭＳ Session Start Failureの受信を受けて、ステップＳ２０５において、ＳＡＩ(s)に対してグループメッセージのセッション開始処理を再度開始する。
【００２９】
なお、図３ＡにおけるＭＴＣ−ＩＷＦの“6. Session Start Request”のＢＭ−ＳＣにおける取得が、図１のグループメッセージ送信要求取得部１０１としての処理機能に相当する。
【００３０】
また、図２における、ＢＭ−ＳＣからＵＥへの“MBMS Session Start Request”の伝達が、図１のグループメッセージ送信要求部１０２としての処理機能に相当する。
【００３１】
そして、図２における、ステップＳ２０１からＳ２０５までの処理が、図１の再送信指示部１０３としての処理機能に相当する。その中で、特に、ＭＣＥにおける、ステップＳ２０１のタイムアウトを検出して、タイムアウトとなったサービスエリア識別子(ＳＡＩ(s))を含む、ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージをＭＭＥに送信する処理が、エラー情報生成部としての処理機能に相当する。
【００３２】
なお、一旦セッションが確立したデバイスでは、それ以降のグループメッセージのセッション開始処理はスルーするよう制御される。
【００３３】
図２の動作シーケンスは、より詳細には、以下のような処理を含む。
（１）ＭＣＥ−ＭＭＥ間(Ｍ３インタフェース／TS 36.300/ TS 36.444）
ＭＣＥとＭＭＥ間のインタフェースはＭ３インタフェースとして定義されており、そのプロトコルはＭ３ＡＰ(Ｍ３ Application Protocol)としてTS36.300およびTS 36.444で定義されている。また、Ｍ３ＡＰではERROR INDICATIONメッセージと、そのCause valueが以下に示す表で定義されている。ここに新たなCause valueとして「Miscellaneous cause」の最後に「Minimum wait timer time out」を追加し、ＭＣＥでMinimum wait timerのタイムアウトを検出した場合、「Minimum wait timer time out」をcause valueとするERROR INDIACTIONメッセージをＭＭＥに通知する。
【００３４】
（２）ＭＭＥ−ＭＢＭＳ−ＧＷ間（Smインタフェース）
TS 29.274の7.13 ＭＢＭＳ Messageでは、Smインタフェースが定義されており、その中でＭＢＭＳ session start request  およびＭＢＭＳ session start responseメッセージが定義されている。ＭＢＭＳ session start responseメッセージにはrequestメッセージに対する結果として、Cause valueが、Table 8.4-1として定義されている。ここのTable 8.4-1において、Cause value 240-255番は将来のリリース用に空いているため、この番号の一つ例えば240番を「Minimum wait timer time out」用として追加する。ＭＣＥからERROR INDIACTIONメッセージを受けたＭＭＥは、上記「Minimum wait timer time out」をCause valueとしたＭＢＭＳ session start responseメッセージをＭＢＭＳ−ＧＷに通知する。
【００３５】
（３）ＭＢＭＳ−ＧＷ−ＢＭ−ＳＣ間（SGmbインタフェース）
TS 29.061の20.3.1では、ＭＢＭＳ Session Start procedureが定義されている。ＢＭ−ＳＣからSession start request(ＲＡＲ: Re-Auth-Request Command)を受けたＭＢＳＣ−ＧＷは、ＭＢＭＳ session start response（ＲＡＡ: Re-Auth-Answer Command）を返す。しかしながら、ＭＢＭＳ session start response（ＲＡＡ: Re-Auth-Answer Command）は、Session start request(ＲＡＲ: Re-Auth-Request Command)にすぐ応答するので、ERROR INDICATIONを追加することができない。
【００３６】
したがって、ＭＢＭＳ−ＧＷ−ＢＭ−ＳＣ間では、ＭＢＭＳ session start failureを新たに定義し、ERROR INDICATIONを含めるようにする。なお、ＭＢＭＳ session start failureは、ＭＣＥ−ＭＭＥ間(Ｍ３インタフェース）において定義されている応答メッセージである。つまり、上記ＭＢＭＳ session start responseメッセージを受けたＭＢＭＳ−ＧＷは、ＢＭ−ＳＣに対し、ＭＢＭＳ session start failureメッセージにERROR INDICATIONを含めたメッセーを通知する。
【００３７】
（４）上記、ＭＢＭＳ session start failureメッセージを受けたＭＢ−ＳＣは、受信したＳＡＩ(s)に対して、Session Start Requestの再送を行う。
【００３８】
（サービスエリア識別子(ＳＡＩ(S))）
非特許文献２（TR 23.887）によれば、ＭＢＭＳをサポートするノードとして、ＢＭ−ＳＣ、ＭＢＭＳ−ＧＷがある。ＢＭ−ＳＣは、ＭＴＣ−ＩＷＦからの“Session Start Request”を受け、ＭＢＭＳ−ＧＷ、ＭＭＥ、ＵＴＲＡＮ／Ｅ−ＵＴＲＡＮなどのネットワークノードと連携してＭＴＣデバイスとのセッションを確立する。また、TS 23.246によれば、特定のＭＢＭＳセッション・データが送信されるエリアとして、ＭＢＭＳサービスエリアを定義している。3GPP TS 23.003によれば、ＭＢＭＳサービスエリアには最大256個のＳＡＩ（Service Area Identity）が含まれる。ＳＡＩ(S)は、セルのグループを識別するために使用される。つまり、セルグループは、ＳＡＩ(S)によりアドレッシングが可能である。なお、ＳＡＩ(S)についても、TS 23.003に記載されている。ＳＡＩ(S)の値は“0〜65,535”まで指定できるが、“0”は特別であり、全てのセルグループを指定する場合に使用される。つまりブロードキャストサービスに使用することができる。
【００３９】
なお、本実施形態においてＳＡＩ(S)と表記しているのは、一箇所のサービスエリアだけでエラーが発生する場合と、複数のサービスエリアでエラーが発生する場合とが想定されるためである。
【００４０】
《ＭＣＥの処理手順》
図４は、本実施形態に係る通信処理システムのＭＣＥの処理手順を示すフローチャートである。このフローチャートは、ＭＣＥを単体で制御するＣＰＵ(Central Processing Unit)、あるいは、訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）の動作を統合して制御するＣＰＵなどで実行されて、各構成機能部を実現する。例えば、訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）の各機能は、仮想ネットワークにより実現してもよい。
【００４１】
ＭＣＥは、ステップＳ４０１において、ＭＭＥからのＭＢＭＳ  Session Start Requestを待つ。ＭＭＥからのＭＢＭＳ  Session Start Requestを受信すると、ＭＣＥは、ステップＳ４０３において、ＭＢＭＳ  Session Start RequestをｅＮＢに送信する。そして、ＭＣＥは、ステップＳ４０５において、セッション応答のタイムアウトを検出するためのタイマをスタートする。
【００４２】
ＭＣＥは、ステップＳ４０７において、ｅＮＢからのＭＢＭＳ  Session Start Responseを待つ。ｅＮＢからのＭＢＭＳ  Session Start Responseが有れば、ＭＣＥは、ステップＳ４０９において、ＭＭＥにＭＢＭＳ  Session Start Responseを返す。そして、ＭＣＥは、ステップＳ４１１およびＳ４１３において、ステップＳ４０５でスタートしたタイマがタイムアウトになるまでの間、デバイス（ＵＥ）からの応答を順次保持する。
【００４３】
タイマがタイムアウトすると、ＭＣＥは、ステップＳ４１５において、タイムアウトしたサービスエリア識別子（ＳＡＩ(s)）を含むＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージを、ＭＭＥに対し発行する。
【００４４】
（ＭＣＥの配置）
図５Ａは、前提技術である3GPP TS 36.300に規定された通信処理システムにおけるＭＣＥの配置を示すブロック図である。なお、図５Ａは、標準のＭＢＭＳの論理アーキテクチャであり、詳細な説明は省略する。
【００４５】
（Ｍ３インタフェース）
図５Ｂは、前提技術である3GPP TS 36.300に規定されたＭ３インタフェースの制御プレーンを示す図である。なお、図５Ｂは、標準のＭ３インタフェースの制御プレーンを示しており、詳細な説明は省略する。
【００４６】
（ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮ）
図５Ｃは、本実施形態に係るＭＣＥで使用される、前提技術である3GPP TS 36.444に規定されたＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージのフォーマットを示す図である。すなわち、本実施形態においては、ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮメッセージのCause５３１を、タイムアウトしたサービスエリア識別子(ＳＡＩ(S))を書き込む領域として使用する。
【００４７】
図５Ｄは、本実施形態で使用される、前提技術である3GPP TS 36.444に規定されたＣＡＵＳＥのフォーマットを示す図である。また、図５Ｅは、本実施形態で使用される、前提技術である3GPP TS 29.274に規定されたＣＡＵＳＥの値を示す図である。本実施形態においては、Causeの中で、(decimal value 121 to 239 and 240 to 256)５５１を、ＳＡＩ(S)を書き込む領域として使用する。
【００４８】
《ＭＭＥの処理手順》
図６は、本実施形態に係る通信処理システムのＭＭＥの処理手順を示すフローチャートである。
【００４９】
ＭＭＥは、ステップＳ６０１において、ＭＢＭＳ−ＧＷからのＭＢＭＳ Session Start Requestを待つ。ＭＢＭＳ−ＧＷからのＭＢＭＳ Session Start Requestを受信すれば、ＭＭＥは、ステップＳ６０３において、ＭＣＥにＭＢＭＳ Session Start Requestを送信する。そして、ＭＭＥは、ステップＳ６０５において、ＭＣＥからのＭＢＭＳ Session Start Responseを待つ。
【００５０】
ＭＣＥからのＭＢＭＳ Session Start Responseを受信すると、ＭＭＥは、ステップＳ６０７において、ＳＡＩ(s)を含むＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮを待つ。なお、所定時間が経過しても、ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮを受信しなければ、正常にグループメッセージのセッションが確立したことを示すＭＢＭＳ Session Start ResponseをＭＢＭＳ−ＧＷに返してもよい。ＳＡＩ(s)を含むＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮをＭＣＥから受信すると、ＭＭＥは、ステップＳ６０９において、ＭＢＭＳ Session Start ResponseにＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮのＳＡＩ(s)を含ませて、ＭＢＭＳ−ＧＷに送信する。
【００５１】
（ＭＥＭＳ  Session Start Response）
図７は、本実施形態に係るＭＭＥで使用される、前提技術である3GPP TS 29.274に規定されたＭＥＭＳ  Ｓｅｓｓｉｏｎ  Ｓｔａｒｔ Ｒｅｓｐｏｎｓｅメッセージのフォーマットを示す図である。図７のCause７０１にＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮのＳＡＩ(s)が記憶されて、ＭＢＭＳ−ＧＷに送信される。
【００５２】
《ＭＢＭＳ−ＧＷの処理手順》
図８は、本実施形態に係る通信処理システムのＭＢＭＳ−ＧＷの処理手順を示すフローチャートである。
【００５３】
ＭＢＭＳ−ＧＷは、ステップＳ８０１において、ＢＭ−ＳＣからのＭＢＭＳ Session Start Requestを待つ、ＢＭ−ＳＣからのＭＢＭＳ Session Start Requestを受信すれば、ＭＢＭＳ−ＧＷは、ステップＳ８０３において、ＢＭ−ＳＣにＭＢＭＳ Session Start Responseを返す。そして、ＭＢＭＳ−ＧＷは、ステップＳ８０５において、ＭＭＥからのＭＢＭＳ Session Start Responseを待つ。
【００５４】
ＭＭＥからのＭＢＭＳ Session Start Responseを受信すると、ＭＢＭＳ−ＧＷは、ステップＳ８０７において、ＭＭＥからのＭＢＭＳ Session Start Responseに含まれる情報を、新たに定義したＭＢＭＳ Session Start Failureに載せ替えて、ＢＭ−ＳＣに送信する。ＭＭＥからのＭＢＭＳ Session Start ResponseにＳＡＩ(s)を含むＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮがあれば、ＭＢＭＳ Session Start FailureによりＢＭ−ＳＣに送信される。
【００５５】
（ＭＥＭＳ  Session Start Failure）
図９は、本実施形態で使用される、前提技術である3GPP TS 36.444に規定されたＭＥＭＳ  Ｓｅｓｓｉｏｎ  Ｓｔａｒｔ Ｆａｉｌｕｒｅメッセージのフォーマットを示す図である。ＭＥＭＳ  Session Start Failureは、Cause９０１を含み、かかるCauseのタイプは、ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮのCause５３１と同じなので、ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮのＳＡＩ(s)を格納して伝達することが可能である。
【００５６】
《ＢＭ−ＳＣの処理手順》
図１０は、本実施形態に係る通信処理システムのＢＭ−ＳＣの処理手順を示すフローチャートである。
【００５７】
ＢＭ−ＳＣは、ステップＳ１００１において、ＭＢＭＳ−ＧＷからのＭＥＭＳ  Session Start Failureを待つ。ＭＢＭＳ−ＧＷからのＭＥＭＳ  Session Start Failureを受信すれば、ＢＭ−ＳＣは、ステップＳ１００３において、ＭＥＭＳ  Session Start Failureに含まれるＳＡＩ(s)を取得する。そして、ＢＭ−ＳＣは、ステップＳ１００５において、ＳＡＩ(s)に基づいてＭＢＭＳ−ＧＷからＵＥ対して、ＭＥＭＳ  Session Start Requestを再送する。
【００５８】
本実施形態によれば、デバイスがグループメッセージを受信できなかった場合に、エラー発生時に訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）内のＢＭ−ＳＣにおいてグループメッセージを再送信する。したがって、シグナリングの削減によるネットワークの輻輳やオーバーロードを回避した障害への対処ができる。
【００５９】
［第３実施形態］
次に、本発明の第３実施形態に係る通信処理システムについて説明する。本実施形態に係る通信処理システムは、上記第２実施形態と比べると、複数のセルグループに障害があったことが応答された場合に、グループメッセージの再送信をする順序を選択する点で異なる。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【００６０】
《ＢＭ−ＳＣの処理手順》
図１１は、本実施形態に係る通信処理システムのＢＭ−ＳＣの処理手順を示すフローチャートである。なお、図１１において、図１０と同様のステップには同じステップ番号を付して、重複する説明を省略する。
【００６１】
ＢＭ−ＳＣは、ステップＳ１１０４において、複数のセルグループに障害がある場合に、エラー受信順や優先度に応じた優先順位順にグループメッセージを再送する順位が選定される。
【００６２】
本実施形態によれば、エラー受信順や優先順位順にグループメッセージを再送する。したがって、シグナリングの削減によるネットワークの輻輳やオーバーロードをより効率的に回避した障害への対処ができる。
【００６３】
［第４実施形態］
次に、本発明の第４実施形態に係る通信処理システムについて説明する。本実施形態に係る通信処理システムは、上記第２実施形態および第３実施形態と比べると、ＭＣＥからＭＭＥへのセッション開始がタイムアウトしたＳＡＩ(s)の送信を、ＭＥＭＳ  Session Start Failureメッセージで行なう点で異なる。その他の構成および動作は、第２実施形態、第３実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【００６４】
《動作シーケンス》
図１２は、本実施形態に係る通信処理システムの動作を示すシーケンス図である。なお、図１２において、図２と同様のステップには同じステップ番号を付して、重複する説明を省略する。
【００６５】
ＭＣＥは、ステップＳ１２０２において、セッション開始がタイムアウトしたＳＡＩ(s)の送信を、ＭＥＭＳ  Session Start FailureメッセージのCauseに書き込んでＭＭＥに送信する。
【００６６】
本実施形態においても、第２実施形態と同様に、デバイスがグループメッセージを受信できなかった場合に、エラー発生時に訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）内のＢＭ−ＳＣにおいてグループメッセージを再送信する。したがって、シグナリングの削減によるネッ＋トワークの輻輳やオーバーロードを回避した障害への対処ができる。
【００６７】
［第５実施形態］
次に、本発明の第５実施形態に係る通信処理システムについて説明する。本実施形態に係る通信処理システムは、上記第２実施形態乃至第４実施形態と比べると、ＭＭＥからＭＢＭＳ−ＧＷへのセッション開始がタイムアウトしたＳＡＩ(s)の送信を、ＭＥＭＳ  Session Start Failureメッセージで行なう点で異なる。その他の構成および動作は、第２実施形態から第４実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【００６８】
《動作シーケンス》
図１３は、本実施形態に係る通信処理システムの動作を示すシーケンス図である。なお、図１３において、図２および図１２と同様のステップには同じステップ番号を付して、重複する説明を省略する。
【００６９】
ＭＭＥは、ステップＳ１３０３において、セッション開始がタイムアウトしたＳＡＩ(s)の送信を、ＭＥＭＳ  Session Start FailureメッセージのCauseに書き込んでＭＢＭＳ−ＧＷに送信する。
【００７０】
本実施形態においても、第２実施形態と同様に、デバイスがグループメッセージを受信できなかった場合に、エラー発生時に訪問先公衆陸上移動ネットワーク（ＶＰＬＭＮ）内のＢＭ−ＳＣにおいてグループメッセージを再送信する。したがって、シグナリングの削減によるネットワークの輻輳やオーバーロードを回避した障害への対処ができる。
【００７１】
［他の実施形態］
なお、本実施形態においては、ＢＭ−ＳＣとＭＢＭＳ−ＧＷ間でのグループメッセージ送信において、図３Ｅの標準動作シーケンスでは、セッション開始処理中のデバイス状態によるエラーが発生した場合にも、それを通知するメッセージが設けられてないとして、ＭＢＭＳ session start failureを新たに定義した。しかしながら、ＭＢＭＳ session start response（ＲＡＡ）の応答を、ＥＲＲＯＲ  ＩＮＤＩＣＡＴＩＯＮを伝達できるように遅延することも可能である。
【００７２】
また、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。また、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステムまたは装置も、本発明の範疇に含まれる。
【００７３】
また、本発明は、複数の機器から構成されるシステムに適用されてもよいし、単体の装置に適用されてもよい。さらに、本発明は、実施形態の機能を実現する情報処理プログラムが、システムあるいは装置に直接あるいは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、あるいはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるＷＷＷ(World Wide Web)サーバも、本発明の範疇に含まれる。特に、少なくとも、上述した実施形態に含まれる処理ステップをコンピュータに実行させるプログラムを格納した非一時的コンピュータ可読媒体（non-transitory computer readable medium）は本発明の範疇に含まれる。
【００７４】
この出願は、２０１５年９月２４日に出願された日本国特許出願  特願２０１５−１８６３０３号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【図１】
2017051664.tif 000003
【図２】
2017051664.tif 000004
【図３Ａ】
2017051664.tif 000005
【図３Ｂ】
2017051664.tif 000006
【図３Ｃ】
2017051664.tif 000007
【図３Ｄ】
2017051664.tif 000008
【図３Ｅ】
2017051664.tif 000009
【図４】
2017051664.tif 000010
【図５Ａ】
2017051664.tif 000011
【図５Ｂ】
2017051664.tif 000012
【図５Ｃ】
2017051664.tif 000013
【図５Ｄ】
2017051664.tif 000014
【図５Ｅ】
2017051664.tif 000015
【図６】
2017051664.tif 000016
【図７】
2017051664.tif 000017
【図８】
2017051664.tif 000018
【図９】
2017051664.tif 000019
【図１０】
2017051664.tif 000020
【図１１】
2017051664.tif 000021
【図１２】
2017051664.tif 000022
【図１３】
2017051664.tif 000023
【国際調査報告】
2017051664.tif 000024
2017051664.tif 000025