(57)【要約】【課題】本願発明では、ＭＴＣデバイスの受信電力の消費削減を実現することができる技術を提供することにある。【解決手段】本願発明は、通信制御装置であって、アプリケーションサーバが端末に所定期間内に送信する複数のメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御することを特徴とする。【選択図】図１
2018110276.tif 000002
【特許請求の範囲】
【請求項１】
通信システムであって、
アプリケーションサーバが端末に所定期間内に送信する複数のメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御する制御部を有する
通信システム。
【請求項２】
前記制御部は、前記複数のメッセージが同一アプリケーションの同一パラメータのメッセージである場合に、古いメッセージを削除することにより送信回数を制御する請求項１に記載の通信システム。
【請求項３】
前記制御部は、前記複数のメッセージが同一アプリケーションのメッセージである場合、前記複数のメッセージを統合して送信することにより、送信回数を制御する請求項１に記載の通信システム。
【請求項４】
前記制御部は、送信遅延が許容されているメッセージを統合して送信することにより、送信回数を制御する請求項３に記載の通信システム。
【請求項５】
前記制御部は、前記端末の受信期間に合わせて前記送信遅延を設定する請求項４に記載の通信システム。
【請求項６】
前記制御部は、前記端末の受信期間に合わせて送信回数を制御する請求項１から請求項５のいずれかに記載の通信システム。
【請求項７】
通信制御装置であって、
アプリケーションサーバが端末に所定期間内に送信する複数のメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御する制御部を有する
通信制御装置。
【請求項８】
通信制御方法であって、
アプリケーションサーバが端末に所定期間内に送信する複数のメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御する通信制御方法。
【請求項９】
通信制御装置のプログラムであって、前記プログラムは、前記制御装置を、
アプリケーションサーバが端末に所定期間内に送信する複数のメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御する制御部として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明は、通信システム、通信制御装置、通信制御方法、及び通信プログラムに関する。
【背景技術】
【０００２】
次世代のセルラシステムの１つである３ＧＰＰ  ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）では、ＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスの消費電力の削減の為の議論が行われている。
【０００３】
３ＧＰＰ  ＬＴＥでは、ＭＴＣデバイスの消費電力の削減のために、間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ  Ｒｅｃｅｐｔｉｏｎ）に関しては非特許文献１にて定義している。一方、間欠送信（ＤＴＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ  Ｔｒａｎｓｍｉｓｓｉｏｎ）に関しては、音声データの間欠送信に関してのみ非特許文献２にて定義している。ＬＴＥでは、ＤＲＸ  ｃｙｃｌｅと呼ばれる受信期間（Ｏｎ−Ｄｕｒａｔｉｏｎ）とそれに続く非受信期間（Ｏｐｐｏｒｔｕｎｉｔｙ  ｆｏｒ  ＤＲＸ）とから構成される期間が定義され、これらの期間を繰り返すことでＤＲＸを実現する。
【０００４】
無線端末は、Ｏｎ−ｄｕｒａｔｉｏｎでは下り制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）を常に受信する必要があり、Ｏｐｐｏｒｔｕｎｉｔｙ  ｆｏｒ  ＤＲＸではＰＤＣＣＨを受信しなくてよい。なお、無線端末がＯｎ−Ｄｕｒａｔｉｏｎ期間中にデータ受信に失敗し、Ｏｎ−Ｄｕｒａｔｉｏｎ期間以降に当該データが再送される場合には、ＰＤＣＣＨを受信する期間を延長する。
【０００５】
ここで、ＤＲＸ動作中の無線端末がＰＤＣＣＨを受信する期間をＡｃｔｉｖｅ  Ｔｉｍｅと呼び、Ｏｎ−ＤｕｒａｔｉｏｎはＡｃｔｉｖｅ  Ｔｉｍｅの最小値である。さらに無線端末毎に、Ｏｐｐｏｒｔｕｎｉｔｙ  ｆｏｒ  ＤＲＸの長さが異なる「ＳｈｏｒｔＤＲＸ」と「ＬｏｎｇＤＲＸ」という２つのＤＲＸ状態（レベル）が設定可能である。ＬＴＥでは、ＳｈｏｒｔＤＲＸ状態の無線端末が一定期間データ受信を行わなかった場合、ＬｏｎｇＤＲＸ状態に遷移するＤＲＸ状態制御（ＤＲＸ  ｓｔａｔｅ  ｃｏｎｔｒｏｌ）を行う。また、ＳｈｏｒｔＤＲＸからＬｏｎｇＤＲＸに状態遷移する判定に、タイマー（ｄｒｘＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒ）を用いる。これにより、無線端末のデータ受信頻度に適したＤＲＸ状態（レベル）を設定でき、無線端末の消費電力の削減が可能になる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】３ＧＰＰ  ＴＳ３６．３２１（インターネット＜ＵＲＬ＞ＨＴＴＰ：／／ｗｗｗ.３ｇｐｐ.ｏｒｇ／ｄｙｎａｒｅｐｏｒｔ／３６−ｓｅｒｉｅｓ.ｈｔｍ）
【非特許文献２】３ＧＰＰ  ＴＳ２６．０８１（インターネット＜ＵＲＬ＞ＨＴＴＰ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ＤｙｎａＲｅｐｏｒｔ／２６‐ｓｅｒｉｅｓ.ｈｔｍ）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＭＴＣデバイスは、バッテリーで動作しているため、できる限りスリープ状態を保って消費電力の削減を図らなければならない。
【０００８】
そこで、本願発明では、上記問題点を鑑みて発明されたものであってＭＴＣデバイスの受信電力の消費削減を実現することができる技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するための本願発明は、通信システムであって、アプリケーションサーバが端末に所定期間内に送信するメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御する制御部を有する。
【００１０】
上記課題を解決するための本願発明は、通信制御装置であって、アプリケーションサーバが端末に所定期間内に送信するメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御する制御部を有する。
【００１１】
上記課題を解決するための本願発明は、通信制御方法であって、アプリケーションサーバが端末に所定期間内に送信するメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御する。
【００１２】
上記課題を解決するための本願発明は、通信制御装置のプログラムであって、前記プログラムは、前記制御装置を、アプリケーションサーバが端末に所定期間内に送信するメッセージの内容に基づいて、前記送信するメッセージの送信回数を制御する制御部として機能させる。
【発明の効果】
【００１３】
本発明によると、ＭＴＣデバイスの受信電力の消費削減を実現することができる。
【図面の簡単な説明】
【００１４】
【図１】図１は、通信システムの概要図である。
【図２】図２は、受信周期を説明するための図である。
【図３】図３は、アプリケーションサーバのブロック図である。
【図４】図４は、実施の形態１における制御部の動作を説明するためのタイムチャートである。
【図５】図５は、実施の形態２における制御部の動作を説明するためのタイムチャートである。
【図６】図６は、実施の形態３における制御部の動作を説明するためのタイムチャートである。
【図７】図７は、実施の形態４における制御部の動作を説明するためのタイムチャートである。
【発明を実施するための形態】
【００１５】
本願発明の特徴を説明するために、以下において、図面を参照して具体的に述べる。図１は、本願発明の通信システムの概要図である。
【００１６】
図１に示すように、通信システム１は、端末１０、ｅＮＢ（ｅｖｏｌｖｅｄ  ＮｏｄｅＢ）１１、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｉｙ）１２、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅ  Ｗａｙ）１３、Ｐ−ＧＷ（Ｐａｃｋｅｔｄａｔａ  Ｎｅｔｗｏｒｋ  Ｇａｔｅ  Ｗａｙ）１４、及びアプリケーションサーバ１５を有する。
【００１７】
本願発明は、アプリケーションサーバ１５が端末１０に所定期間内に送信する複数のメッセージの内容に基づいて、送信するメッセージの送信回数を制御することを特徴とする。
【００１８】
また、制御部が、複数のメッセージが同一アプリケーションの同一パラメータのメッセージである場合に、古いメッセージを削除することにより送信回数を制御することを特徴とする。
【００１９】
また、制御部は、複数のメッセージが同一アプリケーションのメッセージである場合、複数のメッセージを統合して送信することにより、送信回数を制御することを特徴とする。
【００２０】
また、制御部は、送信遅延が許容されているメッセージを統合して送信することにより、送信回数を制御することを特徴とする。
【００２１】
また、制御部は、端末１０の受信期間に合わせて送信遅延を設定することを特徴とする。
【００２２】
また、制御部は、端末１０の受信期間に合わせて送信回数を制御することを特徴とする。
【００２３】
上記特徴により、本願発明は、ＭＴＣデバイスの受信電力の消費を削減することができる。
【００２４】
以下に、本願発明の実施の形態について説明する。
【００２５】
〈実施の形態１〉
端末１０は、ＭＴＣに用いられる端末であり、ＭＴＣデバイスとも言う。端末１０は、無線基地局であるｅＮＢ１１を介してＭＭＥ１２やＳ−ＧＷ１３に位置登録を行い、Ｐ−ＧＷ１４を介してアプリケーションサーバ１５と通信する。
【００２６】
本発明の端末１０は、データの送受信を行う通信処理部を有し、間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ  Ｒｅｃｅｐｔｉｏｎ）にてアプリケーション１５からのデータを受信する。この間欠受信の周期であるＤＲＸ  ｃｙｃｌｅは、図２に示すように、データを連続受信しなくてはいけない期間（Ｏｎ−Ｄｕｒａｔｉｏｎ）と、データを受信しなくてもよい期間（Ｏｐｐｏｒｔｕｎｉｔｙ  ｆｏｒ  ＤＲＸ）とから構成される。なお、前者はＷａｋｅ  ｕｐ期間、後者はＳｌｅｅｐ期間とも呼ばれる。また、後者は、受信しない期間、あるいは受信してはいけない期間、であってもよい。
【００２７】
ｅＮＢ１１は、複数の端末１０と通信できる基地局である。ｅＮＢ１１は、は、図３に示す通り、通信部１１１と、通信処理制御部１１２を有する。
【００２８】
通信部１１１は、アプリケーションサーバ１５が実行している複数のアプリケーションからのメッセージを受信し、間欠送信にて端末１０にメッセージを送信する。
【００２９】
通信処理制御部１１２は、アプリケーションサーバ１５から送信された各種メッセージの相関関係を解析し、不必要なメッセージを破棄して送信しないように、通信部１１１の送信回数を制御する。
【００３０】
図４は通信処理制御部１１２の制御の動作例を説明するための図である。（１）は通常の動作であり、（２）は本願の制御の動作である。
【００３１】
まず、通常の動作について説明する。例えば、アプリケーションサーバ１５で実行されているアプリケーション１が、端末１０に設定されているパラメータＡを“１”に変更する制御信号（メッセージ）を出し、ｅＮＢ１１２が端末１０に送信するとする（Ｓ１）。しかしながら、端末１０の通信処理部の受信周期がＳｌｅｅｐ期間に入っていて、送信エラーになり（Ｓ２）、“１”の再送準備に入る（Ｓ３）。そして、次の送信Ａｃｔｉｖｅ期間に入る前にアプリケーション１がパラメータＡを“２”に変更する制御信号を出して送信準備に入った場合（Ｓ４）、まず、次のＡｃｔｉｖｅ期間に入ったら先に“１”を再送する（Ｓ５）。今度は送信ＯＫとなると（Ｓ６）、次の送信Ａｃｔｉｖｅ期間にて“２”を送信する（Ｓ７）。
【００３２】
続いて、本願の動作について説明する。例えば、アプリケーションサーバ１５で実行されているアプリケーション１が、端末１０に設定されているパラメータＡを“１”に変更する制御信号を出し、ｅＮＢ１１が端末１０に送信するとする（Ｓ１１）。しかしながら、端末１０の通信処理部の受信周期がＳｌｅｅｐ期間に入っていて、送信エラーになり（Ｓ１２）、“１”の再送準備に入る（Ｓ１３）。
【００３３】
そして、次の送信Ａｃｔｉｖｅ期間に入る前にアプリケーション１がパラメータＡを“２”に変更する制御信号を出して送信準備に入ったとする（Ｓ１４）。ここで通信処理制御部１１２は、アプリケーション１からのパラメータＡを“１”にする制御信号とアプリケーション１からのパラメータＡを“２”にする制御信号との相関関係を解析する。ここでは、同一アプリケーションの同一パラメータの制御信号であり、相関関係が高いため、“１”のメッセージを削除すると判断する。この判断の結果、通信処理制御部１１１２は先の“１”を削除して“２”の送信準備に入る（Ｓ１４）。そして、次のＡｃｔｉｖｅ期間に入ったら“２”を送信して（Ｓ１５）、送信ＯＫとなる（Ｓ１６）。
【００３４】
上記の通り、本願の制御によると、Ｓ５での送信が削除されたことにより、端末１０の受信電力の削減が可能となる。
【００３５】
〈実施の形態２〉
本願発明の実施の形態２について説明する。上記実施の形態では、送信するデータを削除することにより、送信回数を制御する形態について説明した。本実施の形態では、送信する複数のメッセージをまとめることにより、送信回数を制御する形態について説明する。尚、上記実施の形態と同様の構成については同一番号を付し、詳細な説明は省略する。
【００３６】
図５は、本実施の形態の通信処理制御部１１２の制御の動作例を説明するための図である。（１）は通常の動作であり、（２）は本願の制御の動作である。
【００３７】
まず、通常の動作について説明する。例えば、アプリケーションサーバ１５にて実行されているアプリケーション１が端末１０に設定されているパラメータＡを“１”に変更する制御信号を出し、ｅＮＢ１１がそれを受信して端末１０に送信するとする（Ｓ５１）。しかしながら、端末１０の通信処理部の受信周期がＳｌｅｅｐ期間に入っていて送信エラーになり（Ｓ５２）、“１”の再送準備に入る（Ｓ５３）。そして、次の送信Ａｃｔｉｖｅ期間に入る前にアプリケーション１がパラメータＢを“２”に変更する制御信号を出して送信準備に入った場合（Ｓ５４）、まず、次のＡｃｔｉｖｅ期間に入ったら先にパラメータＡの“１”を再送する（Ｓ５５）。今度は送信ＯＫとなると（Ｓ５６）、次の送信Ａｃｔｉｖｅ期間にてパラメータＢの“２”を送信する（Ｓ５７）。
【００３８】
続いて、本願の動作について説明する。例えば、アプリケーション１が、端末１０に設定されているパラメータＡを“１”に変更する制御信号を出し、ｅＮＢ１１がそれを受信して端末１０に送信するとする（Ｓ５１１）。しかしながら、端末１０の通信処理部の受信周期がＳｌｅｅｐ期間に入っていて、送信エラーになり（Ｓ５１２）、“１”の再送準備に入る（Ｓ５１３）。
【００３９】
そして、次の送信Ａｃｔｉｖｅ期間に入る前にアプリケーション１がパラメータＢを“２”に変更する制御信号を出して送信準備に入ったとする（Ｓ５１４）。ここで通信処理制御部１１２は、アプリケーション１からのパラメータＡを“１”にする制御信号とアプリケーション１からのパラメータＢを“２”にする制御信号との相関関係を解析する。ここでは、同一アプリケーションの制御信号であるため、パラメータＡの“１”を送信する送信タイミングを削除して、パラメータＢの“２”を送信する送信タイミングでパラメータＡの“１”とパラメータＢの“２”とを統合して送信すると判断する。この判断の結果、通信処理制御部１１２は先のパラメータＡの“１”の送信タイミングを削除して、パラメータＢの“２”の送信タイミングでパラメータＡの“１”とパラメータＢの“２”とを統合して送信する送信準備に入る（Ｓ５１４）。そして、次のＡｃｔｉｖｅ期間に入ったらパラメータＡの“１”とパラメータＢの“２”とを統合した制御信号を送信して（Ｓ５１５）、送信ＯＫとなる（Ｓ５１６）。
【００４０】
尚、上記実施の形態では、先のパラメータＡの“１”の送信を削除する場合を用いて説明したが、後のパラメータＢの“２”の送信を削除して、パラメータＡの“１”の送信タイミングでパラメータＡの“１”とパラメータＢの“２”とを統合した制御信号を送信してもよい。
【００４１】
上記の通り、本願の制御によると、Ｓ５５での送信を削除する制御により、端末１０は本Ｓｌｅｅｐ期間を維持できる。これにより、端末１０の受信電力の削減が可能となる。
【００４２】
〈実施の形態３〉
本願発明の実施の形態３について説明する。上記実施の形態２では、次の送信までにまとまられるメッセージが発生した場合について説明した。本実施の形態では、送信メッセージがある一定の遅延が許容される場合に、送信を制御して、送信する複数のメッセージをまとめる形態について説明する。尚、上記実施の形態と同様の構成については同一番号を付し、詳細な説明は省略する。
【００４３】
図６は、本実施の形態の通信処理制御部１１２の制御の動作例を説明するための図である。（１）は通常の動作であり、（２）は本願の制御の動作である。
【００４４】
まず、通常の動作について説明する。例えば、アプリケーションサーバ１５で実行されているアプリケーション１が、端末１０に設定されているパラメータＡを“１”に変更する制御信号を出し、ｅＮＢ１１がそれを受信して端末１０に送信するとする（Ｓ６１）。しかしながら、端末１０の通信処理部の受信周期がＳｌｅｅｐ期間に入っていて、送信エラーになり（Ｓ６２）、“１”の再送準備に入る（Ｓ６３）。そして、次の送信Ａｃｔｉｖｅ期間に入る前にアプリケーション１がパラメータＢを“２”に変更する制御信号を出して送信準備に入った場合（Ｓ６４）、まず、次のＡｃｔｉｖｅ期間に入ったら先にパラメータＡの“１”を再送する（Ｓ６５）。今度は送信ＯＫとなると（Ｓ６６）、次の送信Ａｃｔｉｖｅ期間にてパラメータＢの“２”を送信する（Ｓ６７）。
【００４５】
続いて、本願の動作について説明する。例えば、アプリケーション１が、端末１０に設定されているパラメータＡを“１”に変更する制御信号を出し、ｅＮＢ１１がそれを受信して端末１０に送信するとする（Ｓ６１１）。しかしながら、端末１０の通信処理部の受信周期がＳｌｅｅｐ期間に入っていて、送信エラーになる（Ｓ６１２）。この時、通信処理制御部１１２は、アプリケーション１のパラメータＡの遅延許容時間を確認し、遅延許容時間内に次の制御信号が来るまでは、送信Ａｃｔｉｖｅ期間が来ても送信タイミングを削除する制御をして、“１”の再送待機を行う（Ｓ６１３）。尚、各制御信号の遅延許容時間は、予めｅＮＢ１１が把握しているものとする。
【００４６】
そして、遅延許容時間内に、アプリケーション１がパラメータＢを“２”に変更する制御信号を出して送信準備に入ったとする（Ｓ６１４）。ここで通信処理制御部１１２は、アプリケーション１からのパラメータＡを“１”にする制御信号とアプリケーション１からのパラメータＢを“２”にする制御信号との相関関係を解析する。ここでは、同一アプリケーションの制御信号であるため、パラメータＡの“１”のメッセージを削除することにより送信回数を削除して、パラメータＢの“２”を送信する送信タイミングでパラメータＡの“１”とパラメータＢの“２”とを統合して送信すると判断する。この判断の結果、通信処理制御部１１２は先のパラメータＡの“１”のメッセージを削除して、パラメータＢの“２”を送信する際にパラメータＡの“１”とパラメータＢの“２”とを統合した制御信号を生成して送信する送信準備に入る（Ｓ６１４）。そして、次のＡｃｔｉｖｅ期間に入ったらパラメータＡの“１”とパラメータＢの“２”とを統合した制御信号を送信して（Ｓ６１５）、送信ＯＫとなる（Ｓ６１６）。
【００４７】
尚、上記実施の形態では、各制御信号の遅延許容時間が予めｅＮＢ１１に登録されている場合について説明した。しかしながら、端末１０が制御信号を受信できず送信エラーである旨のリジェクトメッセージを返す際に、端末１０の受信サイクルがＳｌｅｅｐ期間からＡｃｔｉｖｅ期間に入るまでの時間を送信し、この時間を遅延許容時間と設定する方法であってもよい。
【００４８】
上記の通り、本願の制御によると、Ｓ６５での送信が削除されるので、端末１０のＳｌｅｅｐ期間を維持できる。これにより、端末１０の受信電力の削減が可能となる。
【００４９】
〈実施の形態４〉
本願発明の実施の形態４について説明する。本実施の形態では、受信端末１０の受信期間に送信できないメッセージを削除する形態について説明する。尚、上記実施の形態と同様の構成については同一番号を付し、詳細な説明は省略する。
【００５０】
図７は、本実施の形態の通信処理制御部１１２の制御の動作例を説明するための図である。（１）は通常の動作であり、（２）は本願の制御の動作である。
【００５１】
まず、通常の動作について説明する。例えば、アプリケーション２が端末１０に対して位置情報送信要求の制御信号を出し、それを受信したｅＮＢ１１が端末１０に送信し、端末１０は自端末の受信期間内にその制御信号を通信処理部を介して受信する（Ｓ７１）。そして、自端末の送信期間に自端末の位置情報を通信処理部を介してｅＮＢ１１に送信する（Ｓ７２）。Ｓ７１〜Ｓ７２の動作を繰り返す。
【００５２】
続いて、本願の動作について説明する。例えば、アプリケーション２が、端末１０に対して位置情報送信要求の制御信号を出し、それを受信したｅＮＢ１１が端末１０に送信する（Ｓ７１１）。通信処理制御部１１２は、予め端末１０の受信周期を把握しており、Ｓｌｅｅｐ期間である場合は、制御信号を削除して、端末１０が前回送信した位置情報をアプリケーションサーバ１５に返すことによって、制御信号の回数を削除する（Ｓ７１２）。一方、通信処理制御部１１２は、端末１０がＡｃｔｉｖｅ期間である場合は、制御信号を送信し、端末１０の通信処理部は自身のＡｃｔｉｖｅ期間に位置情報送信要求の制御信号を受信する（Ｓ７１３）。そして、要求に応答して位置情報を通信処理部を介して送信する（Ｓ７１４）。
【００５３】
上記の通り、本願によると、送信要求の制御信号を削除することにより送信回数を削除しているので、端末１０のＳｌｅｅｐ期間を維持できる。これにより、端末１０の受信電力の削減が可能となる。
【００５４】
尚、上記本願発明における、制御回数を制御する方法は上記のいずれであっても良く、また組み合わせても良いものとする。
【００５５】
また、上記本願発明における通信処理制御部１１２はｅＮＢ１１が有している構成を用いて説明したが、端末とアプリケーションサーバ１５との間に設けた制御装置であってもアプリケーションサーバ１５が有していても良い。
【００５６】
尚、上述した本願発明は、上記説明からも明らかなようにハードウェアで構成することも可能であるが、コンピュータプログラムによって各処理を情報処理装置（ＣＰＵ）に行わせることにより実現することも可能である。
【００５７】
以上、実施の形態及び実施例をあげて本願発明を説明したが、本願発明は必ずしも上記実施の形態及び実施例に限定されるものではなく、その技術的思想の範囲内において様々に変形し実施することが出来る。
【符号の説明】
【００５８】
１      通信システム
１０    端末
１１    ｅＮＢ
１２    ＭＭＥ
１３    Ｓ−ＧＷ
１４    Ｐ−ＧＷ
１５    アプリケーションサーバ
１１１  通信部
１１２  通信処理制御部
【図１】
2018110276.tif 000003
【図２】
2018110276.tif 000004
【図３】
2018110276.tif 000005
【図４】
2018110276.tif 000006
【図５】
2018110276.tif 000007
【図６】
2018110276.tif 000008
【図７】
2018110276.tif 000009