(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-11
(45)【発行日】2023-12-19
(54)【発明の名称】基地局及び基地局の方法
(51)【国際特許分類】
H04W 28/02 20090101AFI20231212BHJP
H04W 92/04 20090101ALI20231212BHJP
H04W 92/24 20090101ALI20231212BHJP
【ＦＩ】
H04W28/02
H04W92/04
H04W92/24
【請求項の数】
6
(21)【出願番号】P 2021112516
(22)【出願日】2021-07-07
(62)【分割の表示】P 2019535674の分割
【原出願日】2018-08-07
(65)【公開番号】P2021166403
(43)【公開日】2021-10-14
【審査請求日】2021-07-07
【審判番号】
【審判請求日】2022-12-21
(31)【優先権主張番号】P 2017153290
(32)【優先日】2017-08-08
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【弁理士】
【氏名又は名称】家入 健
(72)【発明者】
【氏名】前佛 創
(72)【発明者】
【氏名】田村 利之
(72)【発明者】
【氏名】鈴木 直明
【合議体】
【審判長】齋藤 哲
【審判官】廣川 浩
【審判官】角張 亜希子
(56)【参考文献】
【文献】韓国公開特許第１０－２０１７－００２２７７２（ＫＲ，Ａ）
【文献】Ｅｒｉｃｓｓｏｎ，Ｖｅｒｉｚｏｎ ＵＫ Ｌｔｄ，ＴｅｌｉａＳｏｎｅｒａ，Ａｕｔｈｏｒｉｚａｔｉｏｎ ｏｆ ｅｆｆｉｃｉｅｎｔ ｓｍａｌｌ ｄａｔａ ｕｓａｇｅ，３ＧＰＰ ＴＳＧ－ＳＡ ＷＧ２＃１１１ Ｓ２－１５３１１１，２０１５年１０月１３日アップロード
(58)【調査した分野】(Int.Cl.，ＤＢ名)
H04B7/24- 7/26
H04W4/00-99/00
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1,4
(57)【特許請求の範囲】
【請求項1】
通信端末から送信されるUplink dataに関するトラヒック情報を、コアネットワーク内に配置されるモビリティ管理装置から受信する手段と、前記モビリティ管理装置から受信したUplink dataに関するトラヒック情報に基づいて、前記通信端末に対してトラヒック制御を行う手段と
を備えることを特徴とする基地局。
【請求項2】
請求項１に記載の基地局であって、当該基地局は、ｅＮＢ（evolved Node B）またはＡＮ（Access Network）を含む。
【請求項3】
請求項１または２に記載の基地局であって、前記モビリティ管理装置は、ＭＭＥ（Mobility Management Entity）またはＡＭＦ（Access and Mobility Management Function）を含む。
【請求項4】
通信端末から送信されるUplink dataに関するトラヒック情報を、コアネットワーク内に配置されるモビリティ管理装置から受信し、前記モビリティ管理装置から受信したUplink dataに関するトラヒック情報に基づいて、前記通信端末に対してトラヒック制御を行う
ことを特徴とする基地局の方法。
【請求項5】
請求項４に記載の基地局の方法であって、当該基地局は、ｅＮＢ（evolved Node B）またはＡＮ（Access Network）を含む。
【請求項6】
請求項４または５に記載の基地局の方法であって、前記モビリティ管理装置は、ＭＭＥ（Mobility Management Entity）またはＡＭＦ（Access and Mobility Management Function）を含む。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は制御装置、通信端末、制御方法、及びプログラムに関する。
【背景技術】
【0002】
近年、一般的なモバイルネットワークを用いて、通常の携帯電話のみならず、データ端末、センサー、自動販売機もしくは自動車などの装置を対象とした、人間による操作を必要としない通信が検討されている。ここで対象となる装置は、例えば、ＩｏＴ（Internet of Things）端末、ＭＴＣ（Machine Type Communication）端末等と称される。
【0003】
ＩｏＴ端末は、今後、急速に増加することが予測されている。そのため、モバイルネットワークは、ＩｏＴ端末に関するデータを効率よく伝送し、さらに、輻輳等が発生することを回避することが求められている。非特許文献１には、アプリケーションサーバが、ＳＣＥＦ（Service Capability Exposure Function）エンティティ（以下、ＳＣＥＦと称する）へ、ＩｏＴ端末に相当する通信端末毎に予め定められたデータ量の閾値に関する情報を送信することが開示されている。さらに、非特許文献１には、ＳＣＥＦが、閾値に基づいてトラヒック制御を行うことが開示されている。トラヒック制御とは、例えば、閾値を超えたデータを伝送することを拒否することであってもよい。
【先行技術文献】
【非特許文献】
【0004】
【文献】3GPP TS23.682 V15.1.0 (2017-06) 5.12
【発明の概要】
【発明が解決しようとする課題】
【0005】
非特許文献１において開示されているＳＣＥＦは、コアネットワーク内に配置されており、アプリケーションサーバと通信するためのインタフェースもしくはリファレンスポイントを有する。そのため、ＳＣＥＦが独自に規定するトラヒック制御を行うことによって、アプリケーションサーバからコアネットワーク内に大量のデータが流入することを防止することができる。その結果、コアネットワーク内のリソースが大量に消費されることを防止することができる。ただし、ＳＣＥＦが実施する独自のトラヒック制御は、ＳＣＥＦが独自の規定に基づき、アプリケーションサーバが生成したデータの送信拒否を判断するため、アプリケーションサーバはデータの再送信を行う可能性がある。その結果、更なるトラヒックの増加につながる恐れがある。一方、通信端末からアプリケーションサーバまでデータが送信される場合であっても、ＳＣＥＦが独自に規定するトラヒック制御に関する情報が通信端末に予め通知されている。そのため、通信端末からコアネットワーク内に大量のデータが流入することを防止することができる。その結果、コアネットワーク内のリソースが大量に消費されることを防止することができる。ただし、通信端末が実施する独自のトラヒック制御は、アプリケーションとして送信すべきデータを通信端末が送信拒否を判断することに過ぎない。この場合、アプリケーションが提供するサービス自体が正常に機能しない場合がある。このように、非特許文献１において開示されている関連技術では、アプリケーションサーバと通信端末の間で動作するアプリケーションのトラヒック特性を加味して、コアネットワークで伝送されるトラヒックまたはデータ量を制御していないという問題がある。
【0006】
本開示の目的は、アプリケーションサーバと通信端末の間で動作するアプリケーションのトラヒック特性を加味して、コアネットワークで伝送されるトラヒックまたはデータ量を制御することができる制御装置、通信端末、制御方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【0007】
本開示の第１の態様にかかる制御装置は、通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、前記送信可能データ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する制御部と、を備える。
【0008】
本開示の第２の態様にかかる通信端末は、通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置及び制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、前記送信可能データ量に関する情報を用いて、送信するデータに対するトラヒック制御を実行する制御部と、を備える。
【0009】
本開示の第３の態様にかかる制御方法は、通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、前記送信可能データ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する。
【0010】
本開示の第４の態様にかかるプログラムは、通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、前記送信可能データ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行することをコンピュータに実行させる。
【発明の効果】
【0011】
本開示により、アプリケーションサーバと通信端末の間で動作するアプリケーションのトラヒック特性を加味して、コアネットワークで伝送されるトラヒックまたはデータ量を制御することができる制御装置、通信端末、制御方法、及びプログラムを提供することができる。
【図面の簡単な説明】
【0012】
【図1】実施の形態１にかかる通信システムの構成図である。
【図2】実施の形態２にかかる通信システムの構成図である。
【図3】実施の形態２にかかる送信データ量に関する情報を通知する処理の流れを示す図である。
【図4】実施の形態２にかかるＣＰパラメータを説明する図である。
【図5】実施の形態２にかかるＵＥの構成図である。
【図6】実施の形態２の変形例にかかる送信データ量に関する情報を通知する処理の流れを示す図である。
【図7】実施の形態３にかかる送信データ量に関する情報を通知する処理の流れを示す図である。
【図8】実施の形態４にかかる通信システムの構成図である。
【図9】実施の形態４にかかる送信データ量に関する情報を通知する処理の流れを示す図である。
【図10】実施の形態４にかかる送信データ量に関する情報を通知する処理の流れを示す図である。
【図11】実施の形態４の変形例にかかる送信データ量に関する情報を通知する処理の流れを示す図である。
【図12】それぞれの実施の形態にかかるＵＥの構成図である。
【図13】それぞれの実施の形態にかかる制御装置の構成図である。
【発明を実施するための形態】
【0013】
（実施の形態１）
以下、図面を参照して実施の形態について説明する。図１を用いて実施の形態１にかかる通信システムの構成例について説明する。図１の通信システムは、制御装置１０、サービス制御装置２０、アプリケーションサーバ３０、基地局４０、及び通信端末５０を有している。制御装置１０、サービス制御装置２０、アプリケーションサーバ３０、基地局４０、及び通信端末５０は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。また、制御装置１０及びサービス制御装置２０は、コアネットワーク内に配置されるコアネットワーク装置と称されてもよい。
以下、図面を参照して実施の形態について説明する。図１を用いて実施の形態１にかかる通信システムの構成例について説明する。図１の通信システムは、制御装置１０、サービス制御装置２０、アプリケーションサーバ３０、基地局４０、及び通信端末５０を有している。制御装置１０、サービス制御装置２０、アプリケーションサーバ３０、基地局４０、及び通信端末５０は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。また、制御装置１０及びサービス制御装置２０は、コアネットワーク内に配置されるコアネットワーク装置と称されてもよい。
【0014】
アプリケーションサーバ３０は、通信端末５０にサービスを提供する。サービスは、例えば、アプリケーションサービス、IoTサービス等であってもよい。
【0015】
サービス制御装置２０は、アプリケーションサーバ３０を認証する。具体的には、サービス制御装置２０は、アプリケーションサーバ３０が、通信端末５０に対してサービスを提供することを認められているアプリケーションサーバか否かを判定してもよい。例えば、サービス制御装置２０は、通信端末５０に対してサービスを提供することが認められているアプリケーションサーバの一覧情報を保持していてもよい。
【0016】
サービス制御装置２０は、制御装置１０及び基地局４０を含むモバイルネットワーク内に配置され、モバイルネットワーク外に配置されるアプリケーションサーバ３０と通信を行う。サービス制御装置２０は、制御装置１０と共にコアネットワーク内に配置され、コアネットワーク外に配置されるアプリケーションサーバ３０と通信を行うとも言える。
【0017】
続いて、制御装置１０の構成例について説明する。制御装置１０は、制御部１１及び通信部１２を有している。制御部１１及び通信部１２等の制御装置１０を構成する構成要素は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、制御装置１０を構成する構成要素は、回路もしくはチップ等のハードウェアであってもよい。
【0018】
通信部１２は、サービス制御装置２０を介してアプリケーションサーバ３０において決定された送信可能なデータ量に関する情報を受信する。送信可能なデータ量に関する情報は、例えば、Rate quota, Byte quota, Rate controlもしくはcharging policyであってもよい。もしくは、送信可能なデータ量に関する情報は、Rate quota, Byte quota, Rate control、及びcharging policyのうち複数を含んでもよい。Rate quota、Byte quota、およびRate controlは、通信端末５０が、所定期間に送信可能なデータ量、或いはデータを伝送するメッセージ数を示す情報である。また、Rate quota、Byte quota、およびRate controlは、通信端末５０が、所定期間に受信可能なデータ量、或いはデータを受信するメッセージ数に関する情報を含んでもよい。所定期間は、例えば、１か月、１週間、１日、もしくは１時間等であってもよい。Rate quota、及びByte quotaは、APN rateと表現されてもよい。charging policyは、通信端末５０がプリペイド対応端末であり、送信可能なデータ量の上限値が定められている場合に、残りの送信可能なデータ量に関する情報であってもよい。また、Rate quota、Byte quota、及びRate controlには、Uplink data、およびDownlink data、それぞれに固有の規定値が設定されてもよい。Uplink dataは、通信端末５０からアプリケーションサーバ３０に向けて伝送されるデータである。Downlink dataは、アプリケーションサーバ３０から通信端末５０に向けて伝送されるデータである。以降、Uplink dataに対するRate quota、Downlink dataに対するRate quota、Uplink dataに対するByte quota、及びDownlink dataに対するByte quotaの４つを纏めてquotaと表現する場合がある。なお、送信可能なデータ量に関する情報は、Tariffを含んでいてもよい。そのTariffは、送信可能なデータ量、送信可能なメッセージ数、受信可能なデータ量、或いは受信可能なメッセージ数に関する情報を含んでいてもよい。
【0019】
送信可能なデータ量に関する情報は、アプリケーションサーバ３０が提供するサービスによって異なる。そのため、アプリケーションサーバ３０が、通信端末５０毎に、送信可能なデータ量を決定する。なお、アプリケーションサーバ３０は、モバイルネットワーク外に配置されている。言い換えると、アプリケーションサーバ３０は、モバイルネットワークを管理する事業者とは異なる事業者によって管理されていることがある。そのため、制御装置１０は、セキュリティ等の観点から、送信可能なデータ量に関する情報を、アプリケーションサーバ３０から直接受信するのではなく、サービス制御装置２０を介してアプリケーションサーバ３０から送信可能データ量に関する情報を受信する。サービス制御装置２０は、上述したように、アプリケーションサーバ３０を認証する機能を有することで、アプリケーションサーバ３０からの情報が信頼できるものかを判定できる。
【0020】
制御部１１は、送信可能なデータ量に関する情報を用いて、通信端末５０から送信されたデータに対するトラヒック制御を実行する。トラヒック制御は、送信可能なデータ量に関する情報に基づいて、データの送信に適用する送信レートを適切な値へ調整(Fine tuning)することにより実現されてもよい。この場合、制御部１１は、送信可能なデータ量を超えるデータの送信に適用する送信レートを、送信可能なデータ量を満足するように現在の値よりも上昇または低下させてもよい。また、トラヒック制御は、通信端末５０から送信されたデータの合計が、送信可能なデータ量を超える場合に、送信可能なデータ量を超えるデータの送信を拒否することであってもよい。このような場合、制御部１１は、送信可能なデータ量を超えるデータの送信を行わなくてもよい。もしくは、トラヒック制御は、通信端末５０から送信されたデータの合計が、送信可能なデータ量を超える場合に、送信可能なデータ量を超えるデータの送信に適用する送信レートを、現在よりも低下させてもよい。
【0021】
以上説明したように、実施の形態１にかかる制御装置１０は、アプリケーションサーバ３０において決定された送信可能なデータ量に関する情報を、サービス制御装置２０を介して受信することができる。さらに、制御装置１０は、受信した送信可能なデータ量に関する情報を用いて、通信端末５０から送信されたデータに対するトラヒック制御を実行することができる。その結果、モバイルネットワーク内において、アプリケーションサーバ３０と通信端末５０の間で動作するアプリケーションのトラヒック特性を加味して、コアネットワークで伝送されるトラヒックまたはデータ量を制御することができる。この実施の形態１にかかる制御装置１０はかかる制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、アプリケーションサーバ３０と通信端末５０の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
【0022】
また、図１において説明した制御装置１０の機能は、基地局４０に搭載されてもよい。つまり、基地局４０が、サービス制御装置２０から送信可能なデータ量に関する情報を受信し、受信した送信可能なデータ量に関する情報に基づいて、トラヒック制御を行ってもよい。
【0023】
（実施の形態２）
続いて、図２を用いて実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、ＵＥ（User Equipment）６０、ｅＮＢ（evolved Node B）７０、ＳＧＷ（Serving Gateway）８０、ＰＧＷ（Packet Data Network Gateway）９０、ＰＣＲＦ（Policy and Charging Rules Function）エンティティ９５（以下、ＰＣＲＦ９５とする）、ＭＭＥ（Mobility Management Entity）１００、ＳＣＥＦ（Service Capability Exposure Function）エンティティ１１０（以下ＳＣＥＦ１１０とする）、ＨＳＳ（Home Subscriber Server）１２０、及びＡＳ（Application Server）１３０を有している。
続いて、図２を用いて実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、ＵＥ（User Equipment）６０、ｅＮＢ（evolved Node B）７０、ＳＧＷ（Serving Gateway）８０、ＰＧＷ（Packet Data Network Gateway）９０、ＰＣＲＦ（Policy and Charging Rules Function）エンティティ９５（以下、ＰＣＲＦ９５とする）、ＭＭＥ（Mobility Management Entity）１００、ＳＣＥＦ（Service Capability Exposure Function）エンティティ１１０（以下ＳＣＥＦ１１０とする）、ＨＳＳ（Home Subscriber Server）１２０、及びＡＳ（Application Server）１３０を有している。
【0024】
ＳＧＷ８０、ＰＧＷ９０、ＰＣＲＦ９５、ＭＭＥ１００、ＳＣＥＦ１１０、及びＨＳＳ１２０は、ＥＰＣ（Evolved Packet Core）を構成するノード装置である。ＥＰＣはコアネットワークに相当する。また、ＳＧＷ８０、ＰＧＷ９０、及びＭＭＥ１００は、図１の制御装置１０に相当する。
【0025】
ＵＥ６０は、３ＧＰＰにおける通信端末の総称であり、図１の通信端末５０に相当する。ＵＥ６０は、ＩｏＴ端末、ＭＴＣ端末であってもよい。ｅＮＢ７０は、無線通信方式としてＬＴＥ（Long Term Evolution）をサポートする基地局であり、図１の基地局４０に相当する。ＵＥ６０は、例えば、ｅＮＢ７０とＬＴＥを用いた無線通信を行う。
【0026】
ＳＧＷ８０は、ｅＮＢ７０とＰＧＷ９０との間に配置され、ユーザデータを中継する。ユーザデータは、U（User）-Planeデータと称されてもよい。ＰＧＷ９０は、ＥＰＣとは異なる外部ネットワークとのゲートウェイであり、外部ネットワークに配置されているＡＳ１３０と通信を行う。外部ネットワークは、例えば、アプリケーションサービスプロバイダー等の事業者が管理するネットワークやＰＤＮ（Packet Data Network）であってもよい。ＰＧＷ９０は、ＡＳ１３０とＳＧＷ８０との間に配置され、ユーザデータを中継する。ＳＧＷ８０及びＰＧＷ９０は、ＵＥ６０から送信されるユーザデータに対するトラヒック制御を実行してもよい。
【0027】
ＭＭＥ１００は、ＵＥ６０のモビリティの管理や制御を行う。ＭＭＥ１００は、ｅＮＢ７０に接続される。ＭＭＥ１００は、コアネットワーク内のノード装置と、ｅＮＢ７０との間において、制御データを中継する。もしくは、ＭＭＥ１００は、自装置において生成した制御データを、ｅＮＢ７０もしくはコアネットワーク内のノード装置へ送信する。制御データは、C（Control）-Planeデータと称されてもよい。また、ＵＥ６０とＡＳ１３０との間において伝送されるＩｏＴサービスに用いられるデータは、一般的なユーザデータと比較して、容量もしくはデータサイズが小さいことが知られている。そのため、ＩｏＴサービスに用いられるデータは、ＡＳ１３０とＵＥ６０との間において、ＳＣＥＦ１１０、ＭＭＥ１００、及びｅＮＢ７０を、介して、制御データとして伝送されてもよい。ＩｏＴサービスに用いられるデータは、例えば、スモールデータと称されてもよい。ＭＭＥ１００は、ＵＥ６０から制御データとして送信されるスモールデータに対するトラヒック制御を実行してもよい。ＭＭＥ１００は、ＳＣＥＦ１１０を介してアプリケーションサーバ３０において決定された送信可能なデータ量に関する情報を受信する。そしてＭＭＥ１００は、送信可能なデータ量に関する情報を用いて、ＵＥ６０から送信されたデータに対するトラヒック制御を実行する。
【0028】
ＳＣＥＦ１１０は、外部ネットワークに配置されているＡＳ１３０に関する認証等を実行する。さらに、ＳＣＥＦ１１０は、ＡＳ１３０へ、ＵＥ６０に関するパラメータを送信する。ＵＥ６０に関するパラメータは、例えば、ＡＳ１３０がＵＥ６０へサービスを提供するために必要となるパラメータであってもよい。ＳＣＥＦ１１０は、図１のサービス制御装置２０に相当する。ＳＣＥＦ１１０は、ＭＭＥ１００とＡＳ１３０との間に配置される。
【0029】
ＨＳＳ１２０は、ＵＥ６０に関する加入者情報（UE Subscription Information, UE Usage typeなど）を管理する。ＨＳＳ１２０は、ＭＭＥ１００及びＳＣＥＦ１１０に接続する。
【0030】
ＡＳ１３０は、ＵＥ６０に関する送信可能なデータ量、具体的には、quota、Rate control及びcharging policyの少なくとも一つを決定する。ＡＳ１３０は、ＵＥ毎に、quota、Rate control及びcharging policyの少なくとも一つを決定する。なお、ＡＳに替えて、ＳＣＳ（Service Capability Server）が用いられてもよく、それらはＳＣＳ／ＡＳと称されてもよい。ＡＳ１３０は、決定した送信可能なデータ量を、ＳＣＥＦ１１０を介してＭＭＥ１００へ送信する。なお、ＡＳ１３０（またはＳＣＳ）は、Tariffを決定し、そのTariffをＳＣＥＦ１１０を介してＭＭＥ１００へ送信してもよい。
【0031】
続いて、図３を用いて実施の形態２にかかる送信可能なデータ量に関する情報を通知する処理の流れについて説明する。はじめに、ＡＳ１３０は、ＵＥ６０に関するパラメータとして、quota、Rate control及びcharging policyの少なくとも一つを決定する（Ｓ１１）。なお、ＡＳ１３０は、Tariffを決定してもよい。
【0032】
次に、ＡＳ１３０は、ステップＳ１１において決定したパラメータを設定したSet chargeable party requestメッセージをＳＣＥＦ１１０へ送信する（Ｓ１２）。具体的には、quota、Rate control及びcharging policyは、ＣＰパラメータとしてSet chargeable party requestメッセージに設定されてもよい。この場合のRate controlは、ＡＳ１３０が、コアネットワークで期待する(Suggested)データ制御である。ここで、図４を用いてＣＰパラメータの例について説明する。なお、ＡＳ１３０がTariffを決定した場合は、Set chargeable party requestメッセージにTariffが設定されてもよい。
【0033】
ＣＰパラメータは、Periodic communication indicator、Communication duration time、Periodic time、Scheduled communication time、及びStationary indicationを含む。さらに、ＣＰパラメータには、quota、Rate control、及びcharging policyが追加されてもよい。ＡＳ１３０は、quota、Rate control、及びcharging policyの少なくも一つの値を決定し、決定した値をＣＰパラメータとしてSet chargeable party requestメッセージに設定してもよい。また、ＡＳ１３０は、Periodic communication indicator、Communication duration time、Periodic time、Scheduled communication time、Stationary indication、quota、Rate control、及びcharging policyのうち、変更したパラメータのみをSet chargeable party requestメッセージに設定してもよい。なお、ＡＳ１３０は、Tariffを決定してもよく、ＣＰパラメータに、Tariffを含めてもよい。
【0034】
図３に戻り、ＳＣＥＦ１１０は、ＡＳ１３０に関するアプリケーショントラヒックを保証するために、Set chargeable party requestメッセージを認証する（Ｓ１３）。次に、ＳＣＥＦ１１０は、ステップＳ１１において決定したパラメータを、ＣＰパラメータとしてUpdate CP parameter requestメッセージに設定し、ＭＭＥ１００へ送信する（Ｓ１４）。ここで、ＭＭＥ１００は、Update CP parameter requestメッセージに設定されたＣＰパラメータを保持してもよい。その後、ＭＭＥ１００は、Update CP parameter responseメッセージをＳＣＥＦ１１０へ送信する（Ｓ１５）。次に、ＳＣＥＦ１１０は、Set chargeable party responseメッセージをＡＳ１３０へ送信する（Ｓ１６）。なお、ＡＳ１３０は、ステップＳ１１において決定したＣＰパラメータを、Set chargeable party requestメッセージとは異なるメッセージに設定して、ＳＣＥＦ１１０に送信してもよい。ＳＣＥＦ１１０は、そのＣＰパラメータをUpdate CP parameter requestメッセージとは異なるメッセージに設定して、ＭＭＥ１００へ送信してもよい。例えば、Set chargeable party requestメッセージに替えて、T8 Set Suggested Network Configuration Request messageが用いられてもよい。Update CP parameter requestメッセージに替えて、Set Suggested Network Configuration Request messageが用いられてもよい。また、Update CP parameter responseメッセージに替えて、Set Suggested Network Configuration Response messageが用いられてもよい。Set chargeable party responseメッセージに替えて、T8 Set Suggested Network Configuration Response messageが用いられてもよい。
【0035】
ＭＭＥ１００は、ＵＥ６０に関するquota、Rate control、及びcharging policyの少なくとも一つを用いて、ＵＥ６０からＡＳ１３０まで送信される制御データとして伝送されるユーザデータに関するトラヒック制御を行う。トラヒック制御の対象となる制御データとして伝送されるユーザデータは、例えば、IoTデータ、スモールデータ等であってもよい。なお、ＭＭＥ１００は、Tariffを受信した場合は、Tariffを加味して、トラヒック制御を行ってもよい。
【0036】
ＭＭＥ１００が、ＵＥ６０から送信された制御データとして伝送されるユーザデータであって、ＡＳ１３０を宛先とする制御データとして伝送されるユーザデータに関するトラヒック制御を行ってもよい。さらに、ＳＣＥＦ１１０が、ＡＳ１３０から送信された制御データとして伝送されるユーザデータであって、ＵＥ６０を宛先とする制御データとして伝送されるユーザデータに関するトラヒック制御を行ってもよい。言い換えると、Uplink dataに関して、ＭＭＥ１００がトラヒック制御を行い、Downlink dataに関して、ＳＣＥＦ１１０がトラヒック制御を行ってもよい。それにより、コアネットワーク内を伝送するトラヒックまたはデータ量をより低減させることができる。また、Uplink dataに関するＣＰパラメータとDownlink dataに関するＣＰパラメータは、異なる値に設定されてもよい。それにより、Uplink data及びDownlink dataのそれぞれに適したトラヒック制御を行うことができる。
【0037】
また、ＭＭＥ１００は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、ｅＮＢ７０へ送信してもよい。例えば、ＭＭＥ１００は、ｅＮＢ７０へ送信するメッセージであるUE context setup requestメッセージもしくはHandover requestメッセージにquota、Rate control、及びcharging policyの少なくとも一つを設定してもよい。この場合、ＭＭＥ１００の代わりに、ｅＮＢ７０が、ＵＥ６０からＡＳ１３０まで送信されるデータに関するトラヒック制御を行うことができる。ｅＮＢ７０は、ＵＥ６０からＡＳ１３０まで送信される制御データに加えて、ＵＥ６０からＡＳ１３０まで送信されるユーザデータに関するトラヒック制御を行ってもよい。もしくは、ｅＮＢ７０は、制御データ及びユーザデータのどちらか一方のみトラヒック制御を行ってもよい。なお、ＭＭＥ１００は、Tariffを受信した場合は、そのTariffをｅＮＢ７０へ送信してもよい。その場合、ｅＮＢ７０は、Tariffを加味して、トラヒック制御を行ってもよい。
【0038】
また、ＭＭＥ１００は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、ＵＥ６０へ送信してもよい。例えば、ＭＭＥ１００は、Ａｔｔａｃｈ処理もしくはＴＡＵ（Tracking Area Update）処理において、ＵＥ６０へ送信するメッセージに、quota、Rate control、及びcharging policyの少なくとも一つを設定してもよい。この場合、ＭＭＥ１００の代わりに、ＵＥ６０が、ＡＳ１３０へ送信するデータに関するトラヒック制御を行ってもよい。ＵＥ６０は、ＡＳ１３０へ送信する制御データに加えて、ＡＳ１３０へ送信するユーザデータに関するトラヒック制御を行ってもよい。もしくは、ＵＥ６０は、制御データ及びユーザデータのどちらか一方のみトラヒック制御を行ってもよい。なお、ＭＭＥ１００は、Tariffを受信した場合は、そのTariffをＵＥ６０へ送信してもよい。その場合、ＵＥ６０は、Tariffを加味して、トラヒック制御を行ってもよい。
【0039】
例えば、ＵＥ６０は、図５に示すように、制御部６１及び通信部６２を有する。制御部６１及び通信部６２等のＵＥ６０を構成する構成要素は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、ＵＥ６０を構成する構成要素は、回路もしくはチップ等のハードウェアであってもよい。
【0040】
通信部６２は、quota、Rate control、及びcharging policyの少なくとも一つを受信する。さらに、制御部６１は、ｅＮＢ７０へデータを送信する際に、受信したquota、Rate control、及びcharging policyの少なくとも一つを用いて、制御データ及びユーザデータの少なくともどちらか一方についてトラヒック制御を行う。なお、通信部６２は、Tariffを受信した場合は、そのTariffを加味して、トラヒック制御を行ってもよい。
【0041】
以上説明したように、実施の形態２にかかるＭＭＥ１００は、ＳＣＥＦ１１０からquota、Rate control、及びcharging policyの少なくとも一つを受信することができる。さらに、ＭＭＥ１００は、quota、Rate control、及びcharging policyの少なくとも一つを用いて、ＵＥ６０からＡＳ１３０まで送信される制御データに関するトラヒック制御を行うことができる。なお、ＭＭＥ１００は、Tariffを受信した場合は、そのTariffを加味して、トラヒック制御を行うことができる。この特徴により実施の形態２にかかるＭＭＥ１００は、ＡＳ１３０とＵＥ６０の間で動作するアプリケーションのトラヒック特性を加味して、制御データに関するトラヒック制御を行うことができる。この実施の形態２にかかるＭＭＥ１００はかかる制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、ＡＳ１３０とＵＥ６０の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
【0042】
また、ＭＭＥ１００が、ｅＮＢ７０もしくはＵＥ６０へquota、Rate control、及びcharging policyの少なくとも一つを送信し、ｅＮＢ７０もしくはＵＥ６０が、ＵＥ６０からＡＳ１３０まで送信される制御データに関するトラヒック制御を行ってもよい。
【0043】
続いて、実施の形態２の変形例について説明する。図６を用いて実施の形態２の変形例にかかる送信データ量に関する情報を通知する処理の流れについて説明する。はじめに、ＡＳ１３０は、ＵＥ６０に関するパラメータとして、quota、Rate control、及びcharging policyの少なくも一つを決定する（Ｓ１１＿１）。なお、以下の説明では、実施の形態２と同様に、これらのパラメータに、Tariffが含まれてもよく、その詳細は割愛する。
【0044】
次に、ＡＳ１３０は、ステップＳ１１＿１において決定したパラメータを設定したNIDD Configuration RequestメッセージをＳＣＥＦ１１０へ送信する（Ｓ１２＿１）。NIDD Configuration Requestメッセージは、T8 Set Suggested Network Configuration Requestメッセージでもかまわない。NIDD Configuration Requestメッセージ（Ｓ１２＿１）に設定されるRate controlは、ＡＳ１３０が、コアネットワークで期待する(Suggested)データ制御である。
【0045】
ＳＣＥＦ１１０は、NIDD Configuration Requestメッセージ（Ｓ１２＿１）に設定されたquota、Rate control、及びcharging policyをＵＥ６０の管理データとして保持する（Ｓ１３＿１）。
【0046】
ＳＣＥＦ１１０は、quota、Rate control、及びcharging policyの少なくとも一つをパラメータとして設定したNIDD Authorization RequestメッセージをＨＳＳ１２０に送信する（Ｓ１４＿１）。quota、Rate control、及びcharging policyは、NIDD Configuration Requestメッセージ（Ｓ１２＿１）に設定されている。NIDD Authorization Requestメッセージは、Set Suggested Network Configuration Requestメッセージでもよい。
【0047】
ＨＳＳ１２０は、ＵＥ６０に関するquota、Rate control、及びcharging policyの少なくとも一つをＵＥ６０の加入者データとして保持する。ＨＳＳ１２０は、NIDD Authorization ResponseメッセージをＳＣＥＦ１１０に送信する（Ｓ１５＿１）。NIDD Authorization Responseメッセージ（Ｓ１５＿１）には、ＨＳＳ１２０で更新されたＵＥ６０に関するquota、Rate control、及びcharging policyの少なくとも一つが設定されてもよい。ＨＳＳ１２０は、NIDD Authorization Requestメッセージ（Ｓ１４＿１）に設定されたquota、Rate control、及びcharging policyの少なくとも一つ、あるいはすべてについて受領できない旨（Reject）を示すCauseを設定しても良い。NIDD Authorization Responseメッセージは、Set Suggested Network Configuration Responseメッセージでもよい。
【0048】
ＳＣＥＦ１１０は、NIDD Configuration ResponseメッセージをＡＳ１３０に送信する（Ｓ１６＿１）。NIDD Configuration Responseメッセージ（Ｓ１６＿１）には、ＨＳＳ１２０で更新されたＵＥ６０に関するquota、Rate control、及びcharging policyの少なくとも一つが設定されてもかまわない。ＳＣＥＦ１１０は、NIDD Configuration Requestメッセージ（Ｓ１２＿１）に設定されたquota、Rate control、及びcharging policyの少なくとも一つ、あるいはすべてについて受領できない旨（Reject）を示すCauseを設定しても良い。NIDD Configuration Responseメッセージは、T8 Set Suggested Network Configuration Responseメッセージでもよい。
【0049】
以上説明したように、実施の形態２の変形例にかかるＨＳＳ１２０は、ＳＣＥＦ１１０からquota、Rate control、及びcharging policyの少なくとも一つを受信することができる。さらに、ＨＳＳ１２０は、この動作完了後に動作するＵＥ６０の移動管理、セッション管理を通じて、quota、Rate control、及びcharging policyの少なくとも一つをＭＭＥ１１０、ＰＧＷ９０、及びＵＥ６０に通知する事が可能となる。また、ＨＳＳ１２０は、ＡＳ１３０とＵＥ６０の間で動作するアプリケーションのトラヒック特性を加味して、ＵＥ６０からＡＳ１３０へ送信されるデータ、およびＡＳ１３０からＵＥ６０へ送信されるユーザデータに関するトラヒック制御を行うことができる。ＨＳＳ１２０がquota、Rate control、及びcharging policyの少なくとも一つをＭＭＥ１１０に通知する場合は、Insert Subscriber Data Requestメッセージを用いてもかまわない。また、ＨＳＳ１２０がquota、Rate control、及びcharging policyの少なくとも一つをＵＥ６０に通知する場合は、ＰＣＯ(Protocol Configuration Option)パラメータを用いてＭＭＥ１１０経由で通知してもかまわない。この実施の形態２の変形例にかかるＭＭＥ１１０、ＰＧＷ９０、及びＵＥ６０は、ＡＳ１３０とＵＥ６０の間で動作するアプリケーションのトラヒック特性を加味してトラヒック制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、ＡＳ１３０とＵＥ６０の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
【0050】
さらに、ＭＭＥ１００が、ｅＮＢ７０もしくはＵＥ６０へquota、Rate control、及びcharging policyの少なくとも一つを送信し、ｅＮＢ７０もしくはＵＥ６０が、ＵＥ６０からＡＳ１３０へ伝送されるユーザデータに関するトラヒック制御を行ってもよい。
【0051】
また、上述の説明においては、主に、無線通信方式としてＬＴＥを用い、コアネットワークとしてＥＰＣを用いる構成について説明したが、図３及び図６の処理は、３ＧＰＰにおいていわゆる３Ｇと称される通信システムにおいて実行されてもよい。具体的には、３Ｇと称される通信システムにおいては、ｅＮＢのかわりにＮＢ（Node B）が用いられ、ＭＭＥの代わりにＳＧＳＮ（Serving General Packet Radio Service Support Node）が用いられる。さらに、３Ｇと称される通信システムにおいては、ＰＧＷの代わりにＧＧＳＮ（Gateway General Packet Radio Service Support Node）が用いられ、ＨＳＳの代わりにＨＬＲ（Home Location Register）が用いられる。以下の説明においても同様に、３Ｇの通信システムが用いられてもよい。
【0052】
（実施の形態３）
続いて、図７を用いて実施の形態３にかかる送信データ量に関する情報を通知する処理の流れについて説明する。ステップＳ２１～Ｓ２３は、図３のステップＳ１１～Ｓ１３と同様であるため詳細な説明を省略する。
続いて、図７を用いて実施の形態３にかかる送信データ量に関する情報を通知する処理の流れについて説明する。ステップＳ２１～Ｓ２３は、図３のステップＳ１１～Ｓ１３と同様であるため詳細な説明を省略する。
【0053】
ＳＣＥＦ１１０は、ステップＳ２３においてＡＳ１３０を認証すると、Set chargeable party requestメッセージに設定されたパラメータであって、ステップＳ２１において決定されたパラメータをＰＧＷ９０へ送信する（Ｓ２４）。ＰＧＷ９０は、受信したパラメータを保持する。その後、ＰＧＷ９０は、応答メッセージをＳＣＥＦ１１０へ送信する（Ｓ２５）。次に、ＳＣＥＦ１１０は、Set chargeable party responseメッセージをＡＳ１３０へ送信する（Ｓ２６）。
【0054】
ＰＧＷ９０は、ＵＥ６０に関するquota、Rate control、及びcharging policyの少なくとも一つを用いて、ＵＥ６０からＡＳ１３０へ送信されるユーザデータに関するトラヒック制御を行う。トラヒック制御の対象となるユーザデータは、例えば、IoTデータであってもよい。さらに、ＰＧＷ９０は、ＡＳ１３０からＵＥ６０へ送信されるユーザデータに関するトラヒック制御を行ってもよい。
【0055】
また、ＰＧＷ９０は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、ＳＧＷ８０へ送信してもよい。この場合、ＰＧＷ９０の代わりに、ＳＧＷ８０が、ＵＥ６０からＡＳ１３０へ送信されるデータに関するトラヒック制御を行い、ＰＧＷ９０が、ＡＳ１３０からＵＥ６０へ送信されるデータに関するトラヒック制御を行ってもよい。
【0056】
以上説明したように、実施の形態３にかかるＰＧＷ９０は、ＳＣＥＦ１１０からquota、Rate control、及びcharging policyの少なくとも一つを受信することができる。さらに、ＰＧＷ９０もしくはＳＧＷ８０は、quota、Rate control、及びcharging policyの少なくとも一つを用いて、ＵＥ６０からＡＳ１３０へ送信されるユーザデータに関するトラヒック制御を行うことができる。ＵＥ６０からＡＳ１３０へ送信されるユーザデータに関するトラヒック制御は、ＡＳ１３０とＵＥ６０の間で動作するアプリケーションのトラヒック特性を加味して行われる。実施の形態３にかかるＰＧＷ９０は、ＡＳ１３０とＵＥ６０の間で動作するアプリケーションのトラヒック特性を加味してトラヒック制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、ＡＳ１３０とＵＥ６０の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
【0057】
（実施の形態４）
続いて、図８を用いて実施の形態４にかかる通信システムの構成例について説明する。図８の通信システムは、3GPP TS23.501 V0.5.0 (2017-05) Figure 4.2.3_1を参照しており、５ＧＣ（5G Core）の構成を主に示している。図８の通信システムは、ＵＥ２００、ＡＮ（Access Network）２１０、ＵＰＦ（User Plane Function）エンティティ２２０（以下、ＵＰＦ２２０とする）、ＡＵＳＦ（Authentication Server Function）２３０、ＡＭＦ（Access and Mobility Management Function）エンティティ２４０（以下、ＡＭＦ２４０とする）、ＳＭＦ（Session Management Function）エンティティ２５０（以下、ＳＭＦ２５０とする）、ＮＥＦ（Network Exposure Function）エンティティ２６０（以下、ＮＥＦ２６０とする）、ＮＲＦ（Network Repository FunctionもしくはNetwork Functions Repository Function）エンティティ２７０（以下、ＮＲＦ２７０とする）、ＰＣＦ（Policy Control Function）エンティティ２８０（以下、ＰＣＦ２８０とする）、ＵＤＭ（Unified Data Management）２９０、ＡＦ（Application Function）エンティティ３００（以下、ＡＦ３００とする）、及びＤＮ（Data Network）３１０を有している。ＡＮ２１０は、（Ｒ（Radio））ＡＮ２１０と示されてもよい。
続いて、図８を用いて実施の形態４にかかる通信システムの構成例について説明する。図８の通信システムは、3GPP TS23.501 V0.5.0 (2017-05) Figure 4.2.3_1を参照しており、５ＧＣ（5G Core）の構成を主に示している。図８の通信システムは、ＵＥ２００、ＡＮ（Access Network）２１０、ＵＰＦ（User Plane Function）エンティティ２２０（以下、ＵＰＦ２２０とする）、ＡＵＳＦ（Authentication Server Function）２３０、ＡＭＦ（Access and Mobility Management Function）エンティティ２４０（以下、ＡＭＦ２４０とする）、ＳＭＦ（Session Management Function）エンティティ２５０（以下、ＳＭＦ２５０とする）、ＮＥＦ（Network Exposure Function）エンティティ２６０（以下、ＮＥＦ２６０とする）、ＮＲＦ（Network Repository FunctionもしくはNetwork Functions Repository Function）エンティティ２７０（以下、ＮＲＦ２７０とする）、ＰＣＦ（Policy Control Function）エンティティ２８０（以下、ＰＣＦ２８０とする）、ＵＤＭ（Unified Data Management）２９０、ＡＦ（Application Function）エンティティ３００（以下、ＡＦ３００とする）、及びＤＮ（Data Network）３１０を有している。ＡＮ２１０は、（Ｒ（Radio））ＡＮ２１０と示されてもよい。
【0058】
ＵＥ２００は、図２のＵＥ６０に相当する。ＡＮ２１０は、ＵＥ２００と通信する基地局等を含む。ＡＮ２１０は、ＵＥ２００と無線通信してもよく、有線通信してもよい。ＡＮ２１０に含まれる基地局等は、図２のｅＮＢ７０に相当する。
【0059】
ＵＰＦ２２０は、ＡＮ２１０と外部ネットワークであるＤＮ３１０との間に配置されている。ＵＰＦ２２０は、ＡＮ２１０とＤＮ３１０との間においてユーザデータのルーティングもしくは転送を行う。ＵＰＦ２２０は、図２のＳＧＷ８０及びＰＧＷ９０に相当する。
【0060】
ＡＭＦ２４０は、ＵＥ２００に関するモビリティ管理と、ＡＵＳＦ２３０などと連携してＵＥ２００に関する認証処理を行う。ＳＭＦ２５０は、ＵＥ２００とＤＮ３１０との間においてユーザデータを伝送する際に確立されるセッションを管理する。ＡＭＦ２４０及びＳＭＦ２５０は、図２のＭＭＥ１００に相当する。
【0061】
ＰＣＦ２８０は、図８に示す通信システムにおいて適用されるポリシールールを管理する。ＵＤＭ２９０は、加入者データ（UE SubscriptionもしくはSubscription information）を管理する。ＵＤＭ２９０は、図２のＨＳＳ１２０に相当する。
【0062】
ＡＦ３００は、ＵＥ２００へアプリケーションサービスを提供する。ＡＵＳＦ２３０は、ＡＭＦ２４０及びＵＤＭ２９０と連携してＵＥ２００に関する認証を行う。
【0063】
ＮＥＦ２６０は、外部ネットワークに配置されているＡＦ３００に関する認証処理等を実行する。さらに、ＮＥＦ２６０は、ＡＦ３００へ、ＵＥ２００に関するパラメータを送信する。ＮＥＦ２６０は、図２のＳＣＥＦ１１０に相当する。ＮＲＦ２７０は、例えば、ＵＥ２００へ提供可能なサービスに関する情報を管理している。ＤＮ３１０は、コアネットワークとは異なる外部ネットワークであることを示している。
【0064】
また、ＵＥ２００と、ＡＭＦ２４０との間のリファレンスポイントとして、Ｎ１が定められている。ＡＮ２１０とＡＭＦ２４０との間のリファレンスポイントとして、Ｎ２が定められている。ＡＮ２１０とＵＰＦ２２０との間のリファレンスポイントとして、Ｎ３が定められている。ＵＰＦ２２０とＳＭＦ２５０との間のリファレンスポイントとして、Ｎ４が定められている。ＵＰＦ２２０とＤＮ３１０との間のリファレンスポイントとして、Ｎ６が定められている。
【0065】
さらに、ＡＵＳＦ２３０、ＡＭＦ２４０、ＳＭＦ２５０、ＮＥＦ２６０、ＮＲＦ２７０、ＰＣＦ２８０、ＵＤＭ２９０、ＡＦ３００は、それぞれService-based interfaceを定めている。Service-based interfaceは、例えば、それぞれの装置において提供されるサービスもしくは機能等を示す。
【0066】
ＡＵＳＦ２３０において定められるService-based interfaceは、Nausfとあらわされる。ＡＭＦ２４０において定められるService-based interfaceは、Namfとあらわされる。ＳＭＦ２５０において定められるService-based interfaceは、Nsmfとあらわされる。ＮＥＦ２６０において定められるService-based interfaceは、Nnefとあらわされる。ＮＲＦ２７０において定められるService-based interfaceは、Nnrfとあらわされる。ＰＣＦ２８０において定められるService-based interfaceは、Npcfとあらわされる。ＵＤＭ２９０において定められるService-based interfaceは、Nudmとあらわされる。ＡＦ３００において定められるService-based interfaceは、Nafとあらわされる。
【0067】
続いて、図９を用いて実施の形態４にかかる送信データ量に関する情報を通知する処理の流れについて説明する。図９は、図８に示される通信システムにおいて、図３の処理が実行されることを示している。つまり、図９は、図８の５ＧＣを用いて図３の各処理を実行することを示している。図９のステップＳ３１～Ｓ３６は、図３のステップＳ１１～Ｓ１６と同様であるため詳細な説明を省略する。
【0068】
また、図９は、図３と同じ信号を用いることを示しているが、信号の名称が変更されてもよい。また、ＡＭＦ２４０とＮＥＦ２６０との間において伝送される信号は、ＰＣＦ２８０を介して伝送されてもよい。例えば、ステップＳ３４におけるUpdate CP parameter requestメッセージ及びステップＳ３５におけるUpdate CP parameter responseメッセージは、ＰＣＦ２８０を介して伝送されてもよい。
【0069】
また、ＡＭＦ２４０は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、ＡＮ２１０へ送信してもよい。例えば、ＡＭＦ２４０は、ＡＮ２１０へ送信するメッセージにquota、Rate control、及びcharging policyの少なくとも一つを設定してもよい。この場合、ＡＭＦ２４０の代わりに、ＡＮ２１０が、ＵＥ２００からＡＦ３００へ送信されるデータに関するトラヒック制御を行ってもよい。ＡＮ２１０は、ＵＥ２００からＡＦ３００へ送信される制御データに加えて、ＵＥ２００からＡＦ３００へ送信されるユーザデータに関するトラヒック制御を行ってもよい。ＵＥ２００からＡＦ３００へ送信される制御データは、制御データとして伝送されるユーザデータであってもよい。もしくは、ＡＮ２１０は、制御データ及びユーザデータのどちらか一方のみトラヒック制御を行ってもよい。
【0070】
また、ＡＭＦ２４０は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、ＵＥ２００へ送信してもよい。例えば、ＡＭＦ２４０は、Ａｔｔａｃｈ処理もしくはＴＡＵ（Tracking Area Update）処理において、ＵＥ２００へ送信するメッセージに、quota、Rate control、及びcharging policyの少なくとも一つを設定してもよい。この場合、ＡＭＦ２４０の代わりに、ＵＥ２００が、ＡＦ３００へ送信するデータに関するトラヒック制御を行ってもよい。ＵＥ２００は、ＡＦ３００へ送信する制御データに加えて、ＡＦ３００へ送信するユーザデータに関するトラヒック制御を行ってもよい。もしくは、ＵＥ２００は、制御データ及びユーザデータのどちらか一方のみトラヒック制御を行ってもよい。
【0071】
また、ユーザデータのトラヒック制御をＵＰＦ２２０が行うために、図１０に示される送信データ量に関する情報を通知する処理の流れが用いられてもよい。図１０は、図８に示される通信システムにおいて、図７の処理が実行されることを示している。つまり、図１０は、図８の５ＧＣを用いて図７の各処理を実行することを示している。図１０のステップＳ４１～Ｓ４６は、図７のステップＳ２１～Ｓ２６と同様であるため詳細な説明を省略する。
【0072】
以上説明したように、実施の形態４における５ＧＣにおいても、ＡＭＦ２４０がＡＦ３００とＵＥ２００の間で動作するアプリケーションのトラヒック特性を加味して、制御データとして伝送されるユーザデータに関するトラヒック制御を行うことができる。ＡＭＦ２４０は、ＭＭＥ１００に相当する。さらに、ＵＰＦ２２０がＡＦ３００とＵＥ２００の間で動作するアプリケーションのトラヒック特性を加味して、ユーザデータに関するトラヒック制御を行うことができる。そして、ＡＭＦ２４０およびＵＰＦ２２０はかかる制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、ＡＦ３００とＵＥ２００の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
【0073】
続いて、実施の形態４の変形例について説明する。図１１を用いて実施の形態４の変形例にかかる送信データ量に関する情報を通知する処理の流れについて説明する。はじめに、ＡＦ３００は、ＵＥ２００に関するパラメータとして、quota、Rate control、及びcharging policyの少なくも一方を決定する（Ｓ３１＿１）。
【0074】
次に、ＡＦ３００は、ステップＳ３１＿１において決定したパラメータを設定したNIDD Configuration RequestメッセージをＮＥＦ２６０へ送信する（Ｓ３２＿１）。NIDD Configuration Requestメッセージは、T8 Set Suggested Network Configuration Requestメッセージでもよい。
【0075】
ＮＥＦ２６０は、NIDD Configuration Requestメッセージ（Ｓ３２＿１）に設定されたquota、Rate control、及びcharging policyをＵＥ２００の管理データとして保持する（Ｓ３３＿１）。
【0076】
ＮＥＦ２６０は、NIDD Authorization RequestメッセージをＵＤＭ２９０に送信する（Ｓ３４＿１）。NIDD Authorization Requestメッセージには、NIDD Configuration Requestメッセージ（Ｓ３２＿１）に設定されたquota、Rate control、及びcharging policyの少なくとも一方がパラメータとして設定されている。NIDD Authorization Requestメッセージは、Set Suggested Network Configuration Requestメッセージでもよい。
【0077】
ＵＤＭ２９０は、ＵＥ２００に関するquota、Rate control、及びcharging policyの少なくとも一方をＵＥ２００の加入者データとして保持する。ＵＤＭ２９０は、NIDD Authorization ResponseメッセージをＮＥＦ２６０に送信する（Ｓ３５＿１）。NIDD Authorization Responseメッセージ（Ｓ３５＿１）には、ＵＤＭ２９０で更新されたＵＥ２００に関するquota、Rate control、及びcharging policyの少なくとも一方が設定されてもかまわない。ＵＤＭ２９０は、NIDD Authorization Requestメッセージ（Ｓ３４＿１）に設定されたquota、Rate control、及びcharging policyの少なくとも一方、あるいはすべてについて受領できない旨（Reject）を示すCauseを設定しても良い。NIDD Authorization Responseメッセージは、Set Suggested Network Configuration Responseメッセージでもよい。
【0078】
ＮＥＦ２６０は、NIDD Configuration ResponseメッセージをＡＦ３００に送信する（Ｓ３６＿１）。NIDD Configuration Responseメッセージ（Ｓ３６＿１）には、ＵＤＭ２９０で更新されたＵＥ２００に関するquota、Rate control、及びcharging policyの少なくとも一方が設定されてもかまわない。ＮＥＦ２６０は、NIDD Configuration Requestメッセージ（Ｓ３２＿１）に設定されたquota、Rate control、及びcharging policyの少なくとも一方、あるいはすべてについて受領できない旨（Reject）を示すCauseを設定しても良い。NIDD Configuration Responseメッセージは、T8 Set Suggested Network Configuration Responseメッセージでもよい。
【0079】
以上説明したように、実施の形態４の変形例にかかるＵＤＭ２９０は、ＮＥＦ２６０からquota、Rate control、及びcharging policyの少なくとも一方を受信することができる。さらに、ＵＤＭ２９０は、この動作完了後に動作するＵＥ２００の移動管理、セッション管理を通じて、quota、Rate control、及びcharging policyの少なくとも一方をＡＭＦ２４０、ＵＰＦ２２０、及びＵＥ２００に通知する事が可能となる。さらにＵＤＭ２９０は、ＡＦ３００とＵＥ２００の間で動作するアプリケーションのトラヒック特性を加味して、ＵＥ２００からＡＦ３００へ送信されるデータ、およびＡＦ３００からＵＥ２００へ送信されるユーザデータに関するトラヒック制御を行うことができる。ＵＤＭ２９０がquota、Rate control、及びcharging policyの少なくとも一方をＡＭＦ２４０に通知する場合は、Insert Subscriber Data Requestメッセージを用いてもかまわない。また、ＵＤＭ２９０がquota、Rate control、及びcharging policyの少なくとも一方をＵＥ２００に通知する場合は、ＰＣＯ(Protocol Configuration Option)パラメータを用いてＡＭＦ２４０経由で通知してもかまわない。実施の形態４の変形例にかかるＡＭＦ２４０、ＵＰＦ２２０、及びＵＥ２００は、ＡＦ３００とＵＥ２００の間で動作するアプリケーションのトラヒック特性を加味してトラヒック制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性は、ＡＦ３００とＵＥ２００の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
【0080】
さらに、ＡＭＦ２４０が、ＡＮ２１０もしくはＵＥ２００へquota、Rate control、及びcharging policyの少なくとも一方を送信してもよい。この場合、ＡＮ２１０もしくはＵＥ２００が、ＵＥ２００からＡＦ３００へ送信されるとして伝送されるユーザデータに関するトラヒック制御を行ってもよい。
【0081】
【0082】
図１２は、ＵＥ６０及びＵＥ２００の構成例を示すブロック図である。Radio Frequency（RF）トランシーバ１１０１は、ｅＮＢもしくはｇＮＢと通信するためにアナログRF信号処理を行う。RFトランシーバ１１０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ１１０１は、アンテナ１１０２及びベースバンドプロセッサ１１０３と結合される。すなわち、RFトランシーバ１１０１は、変調シンボルデータ（又はOFDM（Orthogonal Frequency Division Multiplexing）シンボルデータ）をベースバンドプロセッサ１１０３から受信し、送信RF信号を生成し、送信RF信号をアンテナ１１０２に供給する。また、RFトランシーバ１１０１は、アンテナ１１０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ１１０３に供給する。
【0083】
ベースバンドプロセッサ１１０３は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮／復元、(b) データのセグメンテーション／コンカテネーション、(c) 伝送フォーマット（伝送フレーム）の生成／分解、(d) 伝送路符号化／復号化、(e) 変調（シンボルマッピング）／復調、及び(f) Inverse Fast Fourier Transform（IFFT）によるOFDMシンボルデータ（ベースバンドOFDM信号）の生成などを含む。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（e.g., 無線リソース管理、及びhybrid automatic repeat request（HARQ）処理）、及びレイヤ３（e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含む。
【0084】
例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ１１０３によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ１１０３によるコントロールプレーン処理は、Non-Access Stratum（NAS）プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
【0085】
ベースバンドプロセッサ１１０３は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）、又はMicro Processing Unit（MPU））を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ１１０４と共通化されてもよい。
【0086】
アプリケーションプロセッサ１１０４は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ１１０４は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ１１０４は、メモリ１１０６又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラムを実行することによって、ＵＥ６０及びＵＥ２００の各種機能を実現する。アプリケーションプログラムは、例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーションであってもよい。
【0087】
いくつかの実装において、図１２に破線（１１０５）で示されているように、ベースバンドプロセッサ１１０３及びアプリケーションプロセッサ１１０４は、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ１１０３及びアプリケーションプロセッサ１１０４は、１つのSystem on Chip（SoC）デバイス１１０５として実装されてもよい。SoCデバイスは、システムLarge Scale Integration（LSI）またはチップセットと呼ばれることもある。
【0088】
メモリ１１０６は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ１１０６は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ１１０６は、ベースバンドプロセッサ１１０３、アプリケーションプロセッサ１１０４、及びSoC１１０５からアクセス可能な外部メモリデバイスを含んでもよい。メモリ１１０６は、ベースバンドプロセッサ１１０３内、アプリケーションプロセッサ１１０４内、又はSoC１１０５内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ１１０６は、Universal Integrated Circuit Card（UICC）内のメモリを含んでもよい。
【0089】
メモリ１１０６は、上述の複数の実施形態で説明されたＵＥ６０による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、ベースバンドプロセッサ１１０３又はアプリケーションプロセッサ１１０４は、当該ソフトウェアモジュールをメモリ１１０６から読み出して実行することで、上述の実施形態で説明されたＵＥ６０及びＵＥ２００の処理を行うよう構成されてもよい。
【0090】
図１３は、制御装置１０の構成例を示すブロック図である。図１３を参照すると、制御装置１０は、ネットワークインタフェース１２０１、プロセッサ１２０２、及びメモリ１２０３を含む。ネットワークインタフェース１２０１は、通信システムを構成する他のネットワークノード装置と通信するために使用される。ネットワークインタフェース１２０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。
【0091】
プロセッサ１２０２は、メモリ１２０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明された制御装置１０の処理を行う。プロセッサ１２０２は、例えば、マイクロプロセッサ、MPU（Micro Processing Unit）、又はCPU（Central Processing Unit）であってもよい。プロセッサ１２０２は、複数のプロセッサを含んでもよい。
【0092】
メモリ１２０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１２０３は、プロセッサ１２０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１２０２は、図示されていないI/Oインタフェースを介してメモリ１２０３にアクセスしてもよい。
【0093】
図１３の例では、メモリ１２０３は、ソフトウェアモジュール群を格納するために使用される。プロセッサ１２０２は、これらのソフトウェアモジュール群をメモリ１２０３から読み出して実行することで、上述の実施形態において説明された制御装置１０の処理を行うことができる。
【0094】
図１３を用いて説明したように、制御装置１０が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。
【0095】
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体、光磁気記録媒体、ＣＤ－ＲＯＭ（Read Only Memory）、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、半導体メモリを含む。磁気記録媒体は、例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブであってもよい。光磁気記録媒体は、例えば光磁気ディスクであってもよい。半導体メモリは、例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory）であってもよい。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【0096】
なお、本開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。
【0097】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【0098】
この出願は、２０１７年８月８日に出願された日本出願特願２０１７－１５３２９０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【0099】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する制御部と、を備える制御装置。
（付記２）
前記送信可能なデータ量に関する情報は、quota、Rate control、及びcharging policyの少なくとも一つを含む、付記１に記載の制御装置。
（付記３）
前記制御部は、
前記送信可能なデータ量に関する情報において予め定められたデータ量を超えるデータの送信を拒否する、付記１又は２に記載の制御装置。
（付記４）
前記制御部は、
前記通信端末からC-PlaneデータもしくはU-Planeデータとして送信されたIoT（Internet Of Things）データに対するトラヒック制御を実行する、付記１乃至３のいずれか１項に記載の制御装置。
（付記５）
前記通信部は、
前記送信可能なデータ量に関する情報を、前記通信端末及び基地局の少なくとも一方へ送信する、付記１乃至４のいずれか１項に記載の制御装置。
（付記６）
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置及び制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、
前記送信可能なデータ量に関する情報を用いて、送信するデータに対するトラヒック制御を実行する制御部と、を備える通信端末。
（付記７）
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する、制御装置において実行される制御方法。
（付記８）
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行することをコンピュータに実行させるプログラム。
（付記９）
Uplink dataに関するＣＰパラメータまたはDownlink dataに関するＣＰパラメータを、ＳＣＥＦ（Service Capability Exposure Function）ノードからＨＳＳ（Home Subscriber Server）を介して受信し、
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、保持する、
ことを特徴とするＭＭＥ（Mobility Management Entity）の方法。
（付記１０）
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、基地局に送信する、
付記９に記載のＭＭＥの方法。
（付記１１）
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、伝送リソースの制御のために前記基地局に提供する、
付記１０に記載のＭＭＥの方法。
（付記１２）
前記基地局は、ｅＮＢ（evolved Node B）である、付記１０または１１に記載のＭＭＥの方法。
（付記１３）
Uplink dataに関するＣＰパラメータまたはDownlink dataに関するＣＰパラメータを、ＳＣＥＦ（Service Capability Exposure Function）ノードからＨＳＳ（Home Subscriber Server）を介して受信する手段と、
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、保持する手段と、
を備えることを特徴とするＭＭＥ（Mobility Management Entity）。
（付記１４）
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、基地局に送信する手段を、
さらに備える付記１３に記載のＭＭＥ。
（付記１５）
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、伝送リソースの制御のために前記基地局に提供する、
付記１４に記載のＭＭＥ。
（付記１６）
前記基地局は、ｅＮＢ（evolved Node B）である、
付記１４または１５に記載のＭＭＥ。
（付記１７）
Uplink dataに関するＣＰパラメータまたはDownlink dataに関するＣＰパラメータを、ＭＭＥ（Mobility Management Entity）から受信し、
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、伝送リソースの制御のために用いる、
ことを特徴とする基地局の方法。
（付記１８）
前記基地局は、ｅＮＢ（evolved Node B）である、
付記１７に記載の基地局の方法。
（付記１９）
Uplink dataに関するＣＰパラメータまたはDownlink dataに関するＣＰパラメータを、ＭＭＥ（Mobility Management Entity）から受信する手段と、
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、伝送リソースの制御のために用いる手段と、
を備えることを特徴とする基地局。
（付記２０）
前記基地局は、ｅＮＢ（evolved Node B）である、
付記１９に記載の基地局。
（付記１）
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する制御部と、を備える制御装置。
（付記２）
前記送信可能なデータ量に関する情報は、quota、Rate control、及びcharging policyの少なくとも一つを含む、付記１に記載の制御装置。
（付記３）
前記制御部は、
前記送信可能なデータ量に関する情報において予め定められたデータ量を超えるデータの送信を拒否する、付記１又は２に記載の制御装置。
（付記４）
前記制御部は、
前記通信端末からC-PlaneデータもしくはU-Planeデータとして送信されたIoT（Internet Of Things）データに対するトラヒック制御を実行する、付記１乃至３のいずれか１項に記載の制御装置。
（付記５）
前記通信部は、
前記送信可能なデータ量に関する情報を、前記通信端末及び基地局の少なくとも一方へ送信する、付記１乃至４のいずれか１項に記載の制御装置。
（付記６）
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置及び制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、
前記送信可能なデータ量に関する情報を用いて、送信するデータに対するトラヒック制御を実行する制御部と、を備える通信端末。
（付記７）
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する、制御装置において実行される制御方法。
（付記８）
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行することをコンピュータに実行させるプログラム。
（付記９）
Uplink dataに関するＣＰパラメータまたはDownlink dataに関するＣＰパラメータを、ＳＣＥＦ（Service Capability Exposure Function）ノードからＨＳＳ（Home Subscriber Server）を介して受信し、
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、保持する、
ことを特徴とするＭＭＥ（Mobility Management Entity）の方法。
（付記１０）
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、基地局に送信する、
付記９に記載のＭＭＥの方法。
（付記１１）
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、伝送リソースの制御のために前記基地局に提供する、
付記１０に記載のＭＭＥの方法。
（付記１２）
前記基地局は、ｅＮＢ（evolved Node B）である、付記１０または１１に記載のＭＭＥの方法。
（付記１３）
Uplink dataに関するＣＰパラメータまたはDownlink dataに関するＣＰパラメータを、ＳＣＥＦ（Service Capability Exposure Function）ノードからＨＳＳ（Home Subscriber Server）を介して受信する手段と、
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、保持する手段と、
を備えることを特徴とするＭＭＥ（Mobility Management Entity）。
（付記１４）
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、基地局に送信する手段を、
さらに備える付記１３に記載のＭＭＥ。
（付記１５）
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、伝送リソースの制御のために前記基地局に提供する、
付記１４に記載のＭＭＥ。
（付記１６）
前記基地局は、ｅＮＢ（evolved Node B）である、
付記１４または１５に記載のＭＭＥ。
（付記１７）
Uplink dataに関するＣＰパラメータまたはDownlink dataに関するＣＰパラメータを、ＭＭＥ（Mobility Management Entity）から受信し、
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、伝送リソースの制御のために用いる、
ことを特徴とする基地局の方法。
（付記１８）
前記基地局は、ｅＮＢ（evolved Node B）である、
付記１７に記載の基地局の方法。
（付記１９）
Uplink dataに関するＣＰパラメータまたはDownlink dataに関するＣＰパラメータを、ＭＭＥ（Mobility Management Entity）から受信する手段と、
前記Uplink dataに関するＣＰパラメータまたは前記Downlink dataに関するＣＰパラメータを、伝送リソースの制御のために用いる手段と、
を備えることを特徴とする基地局。
（付記２０）
前記基地局は、ｅＮＢ（evolved Node B）である、
付記１９に記載の基地局。
【符号の説明】
【0100】
１０ 制御装置
１１ 制御部
１２ 通信部
２０ サービス制御装置
３０ アプリケーションサーバ
４０ 基地局
５０ 通信端末
６０ ＵＥ
６１ 制御部
６２ 通信部
７０ ｅＮＢ
８０ ＳＧＷ
９０ ＰＧＷ
９５ ＰＣＲＦ
１００ ＭＭＥ
１１０ ＳＣＥＦ
１２０ ＨＳＳ
１３０ ＡＳ
２００ ＵＥ
２１０ ＡＮ
２２０ ＵＰＦ
２３０ ＡＵＳＦ
２４０ ＡＭＦ
２５０ ＳＭＦ
２６０ ＮＥＦ
２７０ ＮＲＦ
２８０ ＰＣＦ
２９０ ＵＤＭ
３００ ＡＦ
３１０ ＤＮ
１１ 制御部
１２ 通信部
２０ サービス制御装置
３０ アプリケーションサーバ
４０ 基地局
５０ 通信端末
６０ ＵＥ
６１ 制御部
６２ 通信部
７０ ｅＮＢ
８０ ＳＧＷ
９０ ＰＧＷ
９５ ＰＣＲＦ
１００ ＭＭＥ
１１０ ＳＣＥＦ
１２０ ＨＳＳ
１３０ ＡＳ
２００ ＵＥ
２１０ ＡＮ
２２０ ＵＰＦ
２３０ ＡＵＳＦ
２４０ ＡＭＦ
２５０ ＳＭＦ
２６０ ＮＥＦ
２７０ ＮＲＦ
２８０ ＰＣＦ
２９０ ＵＤＭ
３００ ＡＦ
３１０ ＤＮ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】