JP7401111B2 - 基地局及び基地局の方法 - Google Patents

基地局及び基地局の方法 Download PDF

Info

Publication number
JP7401111B2
JP7401111B2 JP2021112516A JP2021112516A JP7401111B2 JP 7401111 B2 JP7401111 B2 JP 7401111B2 JP 2021112516 A JP2021112516 A JP 2021112516A JP 2021112516 A JP2021112516 A JP 2021112516A JP 7401111 B2 JP7401111 B2 JP 7401111B2
Authority
JP
Japan
Prior art keywords
data
control
transmitted
quota
regarding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021112516A
Other languages
English (en)
Other versions
JP2021166403A (ja
Inventor
創 前佛
利之 田村
直明 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JP2021166403A publication Critical patent/JP2021166403A/ja
Application granted granted Critical
Publication of JP7401111B2 publication Critical patent/JP7401111B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0289Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • H04W28/12Flow control between communication endpoints using signalling between network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/04Wireless resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1044Group management mechanisms 
    • H04L67/1053Group management mechanisms  with pre-configuration of logical or physical connections with a determined number of other peers
    • H04L67/1055Group management mechanisms  with pre-configuration of logical or physical connections with a determined number of other peers involving connection limits
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本開示は制御装置、通信端末、制御方法、及びプログラムに関する。
近年、一般的なモバイルネットワークを用いて、通常の携帯電話のみならず、データ端末、センサー、自動販売機もしくは自動車などの装置を対象とした、人間による操作を必要としない通信が検討されている。ここで対象となる装置は、例えば、IoT(Internet of Things)端末、MTC(Machine Type Communication)端末等と称される。
IoT端末は、今後、急速に増加することが予測されている。そのため、モバイルネットワークは、IoT端末に関するデータを効率よく伝送し、さらに、輻輳等が発生することを回避することが求められている。非特許文献1には、アプリケーションサーバが、SCEF(Service Capability Exposure Function)エンティティ(以下、SCEFと称する)へ、IoT端末に相当する通信端末毎に予め定められたデータ量の閾値に関する情報を送信することが開示されている。さらに、非特許文献1には、SCEFが、閾値に基づいてトラヒック制御を行うことが開示されている。トラヒック制御とは、例えば、閾値を超えたデータを伝送することを拒否することであってもよい。
3GPP TS23.682 V15.1.0 (2017-06) 5.12
非特許文献1において開示されているSCEFは、コアネットワーク内に配置されており、アプリケーションサーバと通信するためのインタフェースもしくはリファレンスポイントを有する。そのため、SCEFが独自に規定するトラヒック制御を行うことによって、アプリケーションサーバからコアネットワーク内に大量のデータが流入することを防止することができる。その結果、コアネットワーク内のリソースが大量に消費されることを防止することができる。ただし、SCEFが実施する独自のトラヒック制御は、SCEFが独自の規定に基づき、アプリケーションサーバが生成したデータの送信拒否を判断するため、アプリケーションサーバはデータの再送信を行う可能性がある。その結果、更なるトラヒックの増加につながる恐れがある。一方、通信端末からアプリケーションサーバまでデータが送信される場合であっても、SCEFが独自に規定するトラヒック制御に関する情報が通信端末に予め通知されている。そのため、通信端末からコアネットワーク内に大量のデータが流入することを防止することができる。その結果、コアネットワーク内のリソースが大量に消費されることを防止することができる。ただし、通信端末が実施する独自のトラヒック制御は、アプリケーションとして送信すべきデータを通信端末が送信拒否を判断することに過ぎない。この場合、アプリケーションが提供するサービス自体が正常に機能しない場合がある。このように、非特許文献1において開示されている関連技術では、アプリケーションサーバと通信端末の間で動作するアプリケーションのトラヒック特性を加味して、コアネットワークで伝送されるトラヒックまたはデータ量を制御していないという問題がある。
本開示の目的は、アプリケーションサーバと通信端末の間で動作するアプリケーションのトラヒック特性を加味して、コアネットワークで伝送されるトラヒックまたはデータ量を制御することができる制御装置、通信端末、制御方法、及びプログラムを提供することにある。
本開示の第1の態様にかかる制御装置は、通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、前記送信可能データ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する制御部と、を備える。
本開示の第2の態様にかかる通信端末は、通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置及び制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、前記送信可能データ量に関する情報を用いて、送信するデータに対するトラヒック制御を実行する制御部と、を備える。
本開示の第3の態様にかかる制御方法は、通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、前記送信可能データ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する。
本開示の第4の態様にかかるプログラムは、通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、前記送信可能データ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行することをコンピュータに実行させる。
本開示により、アプリケーションサーバと通信端末の間で動作するアプリケーションのトラヒック特性を加味して、コアネットワークで伝送されるトラヒックまたはデータ量を制御することができる制御装置、通信端末、制御方法、及びプログラムを提供することができる。
実施の形態1にかかる通信システムの構成図である。 実施の形態2にかかる通信システムの構成図である。 実施の形態2にかかる送信データ量に関する情報を通知する処理の流れを示す図である。 実施の形態2にかかるCPパラメータを説明する図である。 実施の形態2にかかるUEの構成図である。 実施の形態2の変形例にかかる送信データ量に関する情報を通知する処理の流れを示す図である。 実施の形態3にかかる送信データ量に関する情報を通知する処理の流れを示す図である。 実施の形態4にかかる通信システムの構成図である。 実施の形態4にかかる送信データ量に関する情報を通知する処理の流れを示す図である。 実施の形態4にかかる送信データ量に関する情報を通知する処理の流れを示す図である。 実施の形態4の変形例にかかる送信データ量に関する情報を通知する処理の流れを示す図である。 それぞれの実施の形態にかかるUEの構成図である。 それぞれの実施の形態にかかる制御装置の構成図である。
(実施の形態1)
以下、図面を参照して実施の形態について説明する。図1を用いて実施の形態1にかかる通信システムの構成例について説明する。図1の通信システムは、制御装置10、サービス制御装置20、アプリケーションサーバ30、基地局40、及び通信端末50を有している。制御装置10、サービス制御装置20、アプリケーションサーバ30、基地局40、及び通信端末50は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。また、制御装置10及びサービス制御装置20は、コアネットワーク内に配置されるコアネットワーク装置と称されてもよい。
アプリケーションサーバ30は、通信端末50にサービスを提供する。サービスは、例えば、アプリケーションサービス、IoTサービス等であってもよい。
サービス制御装置20は、アプリケーションサーバ30を認証する。具体的には、サービス制御装置20は、アプリケーションサーバ30が、通信端末50に対してサービスを提供することを認められているアプリケーションサーバか否かを判定してもよい。例えば、サービス制御装置20は、通信端末50に対してサービスを提供することが認められているアプリケーションサーバの一覧情報を保持していてもよい。
サービス制御装置20は、制御装置10及び基地局40を含むモバイルネットワーク内に配置され、モバイルネットワーク外に配置されるアプリケーションサーバ30と通信を行う。サービス制御装置20は、制御装置10と共にコアネットワーク内に配置され、コアネットワーク外に配置されるアプリケーションサーバ30と通信を行うとも言える。
続いて、制御装置10の構成例について説明する。制御装置10は、制御部11及び通信部12を有している。制御部11及び通信部12等の制御装置10を構成する構成要素は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、制御装置10を構成する構成要素は、回路もしくはチップ等のハードウェアであってもよい。
通信部12は、サービス制御装置20を介してアプリケーションサーバ30において決定された送信可能なデータ量に関する情報を受信する。送信可能なデータ量に関する情報は、例えば、Rate quota, Byte quota, Rate controlもしくはcharging policyであってもよい。もしくは、送信可能なデータ量に関する情報は、Rate quota, Byte quota, Rate control、及びcharging policyのうち複数を含んでもよい。Rate quota、Byte quota、およびRate controlは、通信端末50が、所定期間に送信可能なデータ量、或いはデータを伝送するメッセージ数を示す情報である。また、Rate quota、Byte quota、およびRate controlは、通信端末50が、所定期間に受信可能なデータ量、或いはデータを受信するメッセージ数に関する情報を含んでもよい。所定期間は、例えば、1か月、1週間、1日、もしくは1時間等であってもよい。Rate quota、及びByte quotaは、APN rateと表現されてもよい。charging policyは、通信端末50がプリペイド対応端末であり、送信可能なデータ量の上限値が定められている場合に、残りの送信可能なデータ量に関する情報であってもよい。また、Rate quota、Byte quota、及びRate controlには、Uplink data、およびDownlink data、それぞれに固有の規定値が設定されてもよい。Uplink dataは、通信端末50からアプリケーションサーバ30に向けて伝送されるデータである。Downlink dataは、アプリケーションサーバ30から通信端末50に向けて伝送されるデータである。以降、Uplink dataに対するRate quota、Downlink dataに対するRate quota、Uplink dataに対するByte quota、及びDownlink dataに対するByte quotaの4つを纏めてquotaと表現する場合がある。なお、送信可能なデータ量に関する情報は、Tariffを含んでいてもよい。そのTariffは、送信可能なデータ量、送信可能なメッセージ数、受信可能なデータ量、或いは受信可能なメッセージ数に関する情報を含んでいてもよい。
送信可能なデータ量に関する情報は、アプリケーションサーバ30が提供するサービスによって異なる。そのため、アプリケーションサーバ30が、通信端末50毎に、送信可能なデータ量を決定する。なお、アプリケーションサーバ30は、モバイルネットワーク外に配置されている。言い換えると、アプリケーションサーバ30は、モバイルネットワークを管理する事業者とは異なる事業者によって管理されていることがある。そのため、制御装置10は、セキュリティ等の観点から、送信可能なデータ量に関する情報を、アプリケーションサーバ30から直接受信するのではなく、サービス制御装置20を介してアプリケーションサーバ30から送信可能データ量に関する情報を受信する。サービス制御装置20は、上述したように、アプリケーションサーバ30を認証する機能を有することで、アプリケーションサーバ30からの情報が信頼できるものかを判定できる。
制御部11は、送信可能なデータ量に関する情報を用いて、通信端末50から送信されたデータに対するトラヒック制御を実行する。トラヒック制御は、送信可能なデータ量に関する情報に基づいて、データの送信に適用する送信レートを適切な値へ調整(Fine tuning)することにより実現されてもよい。この場合、制御部11は、送信可能なデータ量を超えるデータの送信に適用する送信レートを、送信可能なデータ量を満足するように現在の値よりも上昇または低下させてもよい。また、トラヒック制御は、通信端末50から送信されたデータの合計が、送信可能なデータ量を超える場合に、送信可能なデータ量を超えるデータの送信を拒否することであってもよい。このような場合、制御部11は、送信可能なデータ量を超えるデータの送信を行わなくてもよい。もしくは、トラヒック制御は、通信端末50から送信されたデータの合計が、送信可能なデータ量を超える場合に、送信可能なデータ量を超えるデータの送信に適用する送信レートを、現在よりも低下させてもよい。
以上説明したように、実施の形態1にかかる制御装置10は、アプリケーションサーバ30において決定された送信可能なデータ量に関する情報を、サービス制御装置20を介して受信することができる。さらに、制御装置10は、受信した送信可能なデータ量に関する情報を用いて、通信端末50から送信されたデータに対するトラヒック制御を実行することができる。その結果、モバイルネットワーク内において、アプリケーションサーバ30と通信端末50の間で動作するアプリケーションのトラヒック特性を加味して、コアネットワークで伝送されるトラヒックまたはデータ量を制御することができる。この実施の形態1にかかる制御装置10はかかる制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、アプリケーションサーバ30と通信端末50の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
また、図1において説明した制御装置10の機能は、基地局40に搭載されてもよい。つまり、基地局40が、サービス制御装置20から送信可能なデータ量に関する情報を受信し、受信した送信可能なデータ量に関する情報に基づいて、トラヒック制御を行ってもよい。
(実施の形態2)
続いて、図2を用いて実施の形態2にかかる通信システムの構成例について説明する。図2の通信システムは、UE(User Equipment)60、eNB(evolved Node B)70、SGW(Serving Gateway)80、PGW(Packet Data Network Gateway)90、PCRF(Policy and Charging Rules Function)エンティティ95(以下、PCRF95とする)、MME(Mobility Management Entity)100、SCEF(Service Capability Exposure Function)エンティティ110(以下SCEF110とする)、HSS(Home Subscriber Server)120、及びAS(Application Server)130を有している。
SGW80、PGW90、PCRF95、MME100、SCEF110、及びHSS120は、EPC(Evolved Packet Core)を構成するノード装置である。EPCはコアネットワークに相当する。また、SGW80、PGW90、及びMME100は、図1の制御装置10に相当する。
UE60は、3GPPにおける通信端末の総称であり、図1の通信端末50に相当する。UE60は、IoT端末、MTC端末であってもよい。eNB70は、無線通信方式としてLTE(Long Term Evolution)をサポートする基地局であり、図1の基地局40に相当する。UE60は、例えば、eNB70とLTEを用いた無線通信を行う。
SGW80は、eNB70とPGW90との間に配置され、ユーザデータを中継する。ユーザデータは、U(User)-Planeデータと称されてもよい。PGW90は、EPCとは異なる外部ネットワークとのゲートウェイであり、外部ネットワークに配置されているAS130と通信を行う。外部ネットワークは、例えば、アプリケーションサービスプロバイダー等の事業者が管理するネットワークやPDN(Packet Data Network)であってもよい。PGW90は、AS130とSGW80との間に配置され、ユーザデータを中継する。SGW80及びPGW90は、UE60から送信されるユーザデータに対するトラヒック制御を実行してもよい。
MME100は、UE60のモビリティの管理や制御を行う。MME100は、eNB70に接続される。MME100は、コアネットワーク内のノード装置と、eNB70との間において、制御データを中継する。もしくは、MME100は、自装置において生成した制御データを、eNB70もしくはコアネットワーク内のノード装置へ送信する。制御データは、C(Control)-Planeデータと称されてもよい。また、UE60とAS130との間において伝送されるIoTサービスに用いられるデータは、一般的なユーザデータと比較して、容量もしくはデータサイズが小さいことが知られている。そのため、IoTサービスに用いられるデータは、AS130とUE60との間において、SCEF110、MME100、及びeNB70を、介して、制御データとして伝送されてもよい。IoTサービスに用いられるデータは、例えば、スモールデータと称されてもよい。MME100は、UE60から制御データとして送信されるスモールデータに対するトラヒック制御を実行してもよい。MME100は、SCEF110を介してアプリケーションサーバ30において決定された送信可能なデータ量に関する情報を受信する。そしてMME100は、送信可能なデータ量に関する情報を用いて、UE60から送信されたデータに対するトラヒック制御を実行する。
SCEF110は、外部ネットワークに配置されているAS130に関する認証等を実行する。さらに、SCEF110は、AS130へ、UE60に関するパラメータを送信する。UE60に関するパラメータは、例えば、AS130がUE60へサービスを提供するために必要となるパラメータであってもよい。SCEF110は、図1のサービス制御装置20に相当する。SCEF110は、MME100とAS130との間に配置される。
HSS120は、UE60に関する加入者情報(UE Subscription Information, UE Usage typeなど)を管理する。HSS120は、MME100及びSCEF110に接続する。
AS130は、UE60に関する送信可能なデータ量、具体的には、quota、Rate control及びcharging policyの少なくとも一つを決定する。AS130は、UE毎に、quota、Rate control及びcharging policyの少なくとも一つを決定する。なお、ASに替えて、SCS(Service Capability Server)が用いられてもよく、それらはSCS/ASと称されてもよい。AS130は、決定した送信可能なデータ量を、SCEF110を介してMME100へ送信する。なお、AS130(またはSCS)は、Tariffを決定し、そのTariffをSCEF110を介してMME100へ送信してもよい。
続いて、図3を用いて実施の形態2にかかる送信可能なデータ量に関する情報を通知する処理の流れについて説明する。はじめに、AS130は、UE60に関するパラメータとして、quota、Rate control及びcharging policyの少なくとも一つを決定する(S11)。なお、AS130は、Tariffを決定してもよい。
次に、AS130は、ステップS11において決定したパラメータを設定したSet chargeable party requestメッセージをSCEF110へ送信する(S12)。具体的には、quota、Rate control及びcharging policyは、CPパラメータとしてSet chargeable party requestメッセージに設定されてもよい。この場合のRate controlは、AS130が、コアネットワークで期待する(Suggested)データ制御である。ここで、図4を用いてCPパラメータの例について説明する。なお、AS130がTariffを決定した場合は、Set chargeable party requestメッセージにTariffが設定されてもよい。
CPパラメータは、Periodic communication indicator、Communication duration time、Periodic time、Scheduled communication time、及びStationary indicationを含む。さらに、CPパラメータには、quota、Rate control、及びcharging policyが追加されてもよい。AS130は、quota、Rate control、及びcharging policyの少なくも一つの値を決定し、決定した値をCPパラメータとしてSet chargeable party requestメッセージに設定してもよい。また、AS130は、Periodic communication indicator、Communication duration time、Periodic time、Scheduled communication time、Stationary indication、quota、Rate control、及びcharging policyのうち、変更したパラメータのみをSet chargeable party requestメッセージに設定してもよい。なお、AS130は、Tariffを決定してもよく、CPパラメータに、Tariffを含めてもよい。
図3に戻り、SCEF110は、AS130に関するアプリケーショントラヒックを保証するために、Set chargeable party requestメッセージを認証する(S13)。次に、SCEF110は、ステップS11において決定したパラメータを、CPパラメータとしてUpdate CP parameter requestメッセージに設定し、MME100へ送信する(S14)。ここで、MME100は、Update CP parameter requestメッセージに設定されたCPパラメータを保持してもよい。その後、MME100は、Update CP parameter responseメッセージをSCEF110へ送信する(S15)。次に、SCEF110は、Set chargeable party responseメッセージをAS130へ送信する(S16)。なお、AS130は、ステップS11において決定したCPパラメータを、Set chargeable party requestメッセージとは異なるメッセージに設定して、SCEF110に送信してもよい。SCEF110は、そのCPパラメータをUpdate CP parameter requestメッセージとは異なるメッセージに設定して、MME100へ送信してもよい。例えば、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が用いられてもよい。
MME100は、UE60に関するquota、Rate control、及びcharging policyの少なくとも一つを用いて、UE60からAS130まで送信される制御データとして伝送されるユーザデータに関するトラヒック制御を行う。トラヒック制御の対象となる制御データとして伝送されるユーザデータは、例えば、IoTデータ、スモールデータ等であってもよい。なお、MME100は、Tariffを受信した場合は、Tariffを加味して、トラヒック制御を行ってもよい。
MME100が、UE60から送信された制御データとして伝送されるユーザデータであって、AS130を宛先とする制御データとして伝送されるユーザデータに関するトラヒック制御を行ってもよい。さらに、SCEF110が、AS130から送信された制御データとして伝送されるユーザデータであって、UE60を宛先とする制御データとして伝送されるユーザデータに関するトラヒック制御を行ってもよい。言い換えると、Uplink dataに関して、MME100がトラヒック制御を行い、Downlink dataに関して、SCEF110がトラヒック制御を行ってもよい。それにより、コアネットワーク内を伝送するトラヒックまたはデータ量をより低減させることができる。また、Uplink dataに関するCPパラメータとDownlink dataに関するCPパラメータは、異なる値に設定されてもよい。それにより、Uplink data及びDownlink dataのそれぞれに適したトラヒック制御を行うことができる。
また、MME100は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、eNB70へ送信してもよい。例えば、MME100は、eNB70へ送信するメッセージであるUE context setup requestメッセージもしくはHandover requestメッセージにquota、Rate control、及びcharging policyの少なくとも一つを設定してもよい。この場合、MME100の代わりに、eNB70が、UE60からAS130まで送信されるデータに関するトラヒック制御を行うことができる。eNB70は、UE60からAS130まで送信される制御データに加えて、UE60からAS130まで送信されるユーザデータに関するトラヒック制御を行ってもよい。もしくは、eNB70は、制御データ及びユーザデータのどちらか一方のみトラヒック制御を行ってもよい。なお、MME100は、Tariffを受信した場合は、そのTariffをeNB70へ送信してもよい。その場合、eNB70は、Tariffを加味して、トラヒック制御を行ってもよい。
また、MME100は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、UE60へ送信してもよい。例えば、MME100は、Attach処理もしくはTAU(Tracking Area Update)処理において、UE60へ送信するメッセージに、quota、Rate control、及びcharging policyの少なくとも一つを設定してもよい。この場合、MME100の代わりに、UE60が、AS130へ送信するデータに関するトラヒック制御を行ってもよい。UE60は、AS130へ送信する制御データに加えて、AS130へ送信するユーザデータに関するトラヒック制御を行ってもよい。もしくは、UE60は、制御データ及びユーザデータのどちらか一方のみトラヒック制御を行ってもよい。なお、MME100は、Tariffを受信した場合は、そのTariffをUE60へ送信してもよい。その場合、UE60は、Tariffを加味して、トラヒック制御を行ってもよい。
例えば、UE60は、図5に示すように、制御部61及び通信部62を有する。制御部61及び通信部62等のUE60を構成する構成要素は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、UE60を構成する構成要素は、回路もしくはチップ等のハードウェアであってもよい。
通信部62は、quota、Rate control、及びcharging policyの少なくとも一つを受信する。さらに、制御部61は、eNB70へデータを送信する際に、受信したquota、Rate control、及びcharging policyの少なくとも一つを用いて、制御データ及びユーザデータの少なくともどちらか一方についてトラヒック制御を行う。なお、通信部62は、Tariffを受信した場合は、そのTariffを加味して、トラヒック制御を行ってもよい。
以上説明したように、実施の形態2にかかるMME100は、SCEF110からquota、Rate control、及びcharging policyの少なくとも一つを受信することができる。さらに、MME100は、quota、Rate control、及びcharging policyの少なくとも一つを用いて、UE60からAS130まで送信される制御データに関するトラヒック制御を行うことができる。なお、MME100は、Tariffを受信した場合は、そのTariffを加味して、トラヒック制御を行うことができる。この特徴により実施の形態2にかかるMME100は、AS130とUE60の間で動作するアプリケーションのトラヒック特性を加味して、制御データに関するトラヒック制御を行うことができる。この実施の形態2にかかるMME100はかかる制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、AS130とUE60の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
また、MME100が、eNB70もしくはUE60へquota、Rate control、及びcharging policyの少なくとも一つを送信し、eNB70もしくはUE60が、UE60からAS130まで送信される制御データに関するトラヒック制御を行ってもよい。
続いて、実施の形態2の変形例について説明する。図6を用いて実施の形態2の変形例にかかる送信データ量に関する情報を通知する処理の流れについて説明する。はじめに、AS130は、UE60に関するパラメータとして、quota、Rate control、及びcharging policyの少なくも一つを決定する(S11_1)。なお、以下の説明では、実施の形態2と同様に、これらのパラメータに、Tariffが含まれてもよく、その詳細は割愛する。
次に、AS130は、ステップS11_1において決定したパラメータを設定したNIDD Configuration RequestメッセージをSCEF110へ送信する(S12_1)。NIDD Configuration Requestメッセージは、T8 Set Suggested Network Configuration Requestメッセージでもかまわない。NIDD Configuration Requestメッセージ(S12_1)に設定されるRate controlは、AS130が、コアネットワークで期待する(Suggested)データ制御である。
SCEF110は、NIDD Configuration Requestメッセージ(S12_1)に設定されたquota、Rate control、及びcharging policyをUE60の管理データとして保持する(S13_1)。
SCEF110は、quota、Rate control、及びcharging policyの少なくとも一つをパラメータとして設定したNIDD Authorization RequestメッセージをHSS120に送信する(S14_1)。quota、Rate control、及びcharging policyは、NIDD Configuration Requestメッセージ(S12_1)に設定されている。NIDD Authorization Requestメッセージは、Set Suggested Network Configuration Requestメッセージでもよい。
HSS120は、UE60に関するquota、Rate control、及びcharging policyの少なくとも一つをUE60の加入者データとして保持する。HSS120は、NIDD Authorization ResponseメッセージをSCEF110に送信する(S15_1)。NIDD Authorization Responseメッセージ(S15_1)には、HSS120で更新されたUE60に関するquota、Rate control、及びcharging policyの少なくとも一つが設定されてもよい。HSS120は、NIDD Authorization Requestメッセージ(S14_1)に設定されたquota、Rate control、及びcharging policyの少なくとも一つ、あるいはすべてについて受領できない旨(Reject)を示すCauseを設定しても良い。NIDD Authorization Responseメッセージは、Set Suggested Network Configuration Responseメッセージでもよい。
SCEF110は、NIDD Configuration ResponseメッセージをAS130に送信する(S16_1)。NIDD Configuration Responseメッセージ(S16_1)には、HSS120で更新されたUE60に関するquota、Rate control、及びcharging policyの少なくとも一つが設定されてもかまわない。SCEF110は、NIDD Configuration Requestメッセージ(S12_1)に設定されたquota、Rate control、及びcharging policyの少なくとも一つ、あるいはすべてについて受領できない旨(Reject)を示すCauseを設定しても良い。NIDD Configuration Responseメッセージは、T8 Set Suggested Network Configuration Responseメッセージでもよい。
以上説明したように、実施の形態2の変形例にかかるHSS120は、SCEF110からquota、Rate control、及びcharging policyの少なくとも一つを受信することができる。さらに、HSS120は、この動作完了後に動作するUE60の移動管理、セッション管理を通じて、quota、Rate control、及びcharging policyの少なくとも一つをMME110、PGW90、及びUE60に通知する事が可能となる。また、HSS120は、AS130とUE60の間で動作するアプリケーションのトラヒック特性を加味して、UE60からAS130へ送信されるデータ、およびAS130からUE60へ送信されるユーザデータに関するトラヒック制御を行うことができる。HSS120がquota、Rate control、及びcharging policyの少なくとも一つをMME110に通知する場合は、Insert Subscriber Data Requestメッセージを用いてもかまわない。また、HSS120がquota、Rate control、及びcharging policyの少なくとも一つをUE60に通知する場合は、PCO(Protocol Configuration Option)パラメータを用いてMME110経由で通知してもかまわない。この実施の形態2の変形例にかかるMME110、PGW90、及びUE60は、AS130とUE60の間で動作するアプリケーションのトラヒック特性を加味してトラヒック制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、AS130とUE60の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
さらに、MME100が、eNB70もしくはUE60へquota、Rate control、及びcharging policyの少なくとも一つを送信し、eNB70もしくはUE60が、UE60からAS130へ伝送されるユーザデータに関するトラヒック制御を行ってもよい。
また、上述の説明においては、主に、無線通信方式としてLTEを用い、コアネットワークとしてEPCを用いる構成について説明したが、図3及び図6の処理は、3GPPにおいていわゆる3Gと称される通信システムにおいて実行されてもよい。具体的には、3Gと称される通信システムにおいては、eNBのかわりにNB(Node B)が用いられ、MMEの代わりにSGSN(Serving General Packet Radio Service Support Node)が用いられる。さらに、3Gと称される通信システムにおいては、PGWの代わりにGGSN(Gateway General Packet Radio Service Support Node)が用いられ、HSSの代わりにHLR(Home Location Register)が用いられる。以下の説明においても同様に、3Gの通信システムが用いられてもよい。
(実施の形態3)
続いて、図7を用いて実施の形態3にかかる送信データ量に関する情報を通知する処理の流れについて説明する。ステップS21~S23は、図3のステップS11~S13と同様であるため詳細な説明を省略する。
SCEF110は、ステップS23においてAS130を認証すると、Set chargeable party requestメッセージに設定されたパラメータであって、ステップS21において決定されたパラメータをPGW90へ送信する(S24)。PGW90は、受信したパラメータを保持する。その後、PGW90は、応答メッセージをSCEF110へ送信する(S25)。次に、SCEF110は、Set chargeable party responseメッセージをAS130へ送信する(S26)。
PGW90は、UE60に関するquota、Rate control、及びcharging policyの少なくとも一つを用いて、UE60からAS130へ送信されるユーザデータに関するトラヒック制御を行う。トラヒック制御の対象となるユーザデータは、例えば、IoTデータであってもよい。さらに、PGW90は、AS130からUE60へ送信されるユーザデータに関するトラヒック制御を行ってもよい。
また、PGW90は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、SGW80へ送信してもよい。この場合、PGW90の代わりに、SGW80が、UE60からAS130へ送信されるデータに関するトラヒック制御を行い、PGW90が、AS130からUE60へ送信されるデータに関するトラヒック制御を行ってもよい。
以上説明したように、実施の形態3にかかるPGW90は、SCEF110からquota、Rate control、及びcharging policyの少なくとも一つを受信することができる。さらに、PGW90もしくはSGW80は、quota、Rate control、及びcharging policyの少なくとも一つを用いて、UE60からAS130へ送信されるユーザデータに関するトラヒック制御を行うことができる。UE60からAS130へ送信されるユーザデータに関するトラヒック制御は、AS130とUE60の間で動作するアプリケーションのトラヒック特性を加味して行われる。実施の形態3にかかるPGW90は、AS130とUE60の間で動作するアプリケーションのトラヒック特性を加味してトラヒック制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、AS130とUE60の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
(実施の形態4)
続いて、図8を用いて実施の形態4にかかる通信システムの構成例について説明する。図8の通信システムは、3GPP TS23.501 V0.5.0 (2017-05) Figure 4.2.3_1を参照しており、5GC(5G Core)の構成を主に示している。図8の通信システムは、UE200、AN(Access Network)210、UPF(User Plane Function)エンティティ220(以下、UPF220とする)、AUSF(Authentication Server Function)230、AMF(Access and Mobility Management Function)エンティティ240(以下、AMF240とする)、SMF(Session Management Function)エンティティ250(以下、SMF250とする)、NEF(Network Exposure Function)エンティティ260(以下、NEF260とする)、NRF(Network Repository FunctionもしくはNetwork Functions Repository Function)エンティティ270(以下、NRF270とする)、PCF(Policy Control Function)エンティティ280(以下、PCF280とする)、UDM(Unified Data Management)290、AF(Application Function)エンティティ300(以下、AF300とする)、及びDN(Data Network)310を有している。AN210は、(R(Radio))AN210と示されてもよい。
UE200は、図2のUE60に相当する。AN210は、UE200と通信する基地局等を含む。AN210は、UE200と無線通信してもよく、有線通信してもよい。AN210に含まれる基地局等は、図2のeNB70に相当する。
UPF220は、AN210と外部ネットワークであるDN310との間に配置されている。UPF220は、AN210とDN310との間においてユーザデータのルーティングもしくは転送を行う。UPF220は、図2のSGW80及びPGW90に相当する。
AMF240は、UE200に関するモビリティ管理と、AUSF230などと連携してUE200に関する認証処理を行う。SMF250は、UE200とDN310との間においてユーザデータを伝送する際に確立されるセッションを管理する。AMF240及びSMF250は、図2のMME100に相当する。
PCF280は、図8に示す通信システムにおいて適用されるポリシールールを管理する。UDM290は、加入者データ(UE SubscriptionもしくはSubscription information)を管理する。UDM290は、図2のHSS120に相当する。
AF300は、UE200へアプリケーションサービスを提供する。AUSF230は、AMF240及びUDM290と連携してUE200に関する認証を行う。
NEF260は、外部ネットワークに配置されているAF300に関する認証処理等を実行する。さらに、NEF260は、AF300へ、UE200に関するパラメータを送信する。NEF260は、図2のSCEF110に相当する。NRF270は、例えば、UE200へ提供可能なサービスに関する情報を管理している。DN310は、コアネットワークとは異なる外部ネットワークであることを示している。
また、UE200と、AMF240との間のリファレンスポイントとして、N1が定められている。AN210とAMF240との間のリファレンスポイントとして、N2が定められている。AN210とUPF220との間のリファレンスポイントとして、N3が定められている。UPF220とSMF250との間のリファレンスポイントとして、N4が定められている。UPF220とDN310との間のリファレンスポイントとして、N6が定められている。
さらに、AUSF230、AMF240、SMF250、NEF260、NRF270、PCF280、UDM290、AF300は、それぞれService-based interfaceを定めている。Service-based interfaceは、例えば、それぞれの装置において提供されるサービスもしくは機能等を示す。
AUSF230において定められるService-based interfaceは、Nausfとあらわされる。AMF240において定められるService-based interfaceは、Namfとあらわされる。SMF250において定められるService-based interfaceは、Nsmfとあらわされる。NEF260において定められるService-based interfaceは、Nnefとあらわされる。NRF270において定められるService-based interfaceは、Nnrfとあらわされる。PCF280において定められるService-based interfaceは、Npcfとあらわされる。UDM290において定められるService-based interfaceは、Nudmとあらわされる。AF300において定められるService-based interfaceは、Nafとあらわされる。
続いて、図9を用いて実施の形態4にかかる送信データ量に関する情報を通知する処理の流れについて説明する。図9は、図8に示される通信システムにおいて、図3の処理が実行されることを示している。つまり、図9は、図8の5GCを用いて図3の各処理を実行することを示している。図9のステップS31~S36は、図3のステップS11~S16と同様であるため詳細な説明を省略する。
また、図9は、図3と同じ信号を用いることを示しているが、信号の名称が変更されてもよい。また、AMF240とNEF260との間において伝送される信号は、PCF280を介して伝送されてもよい。例えば、ステップS34におけるUpdate CP parameter requestメッセージ及びステップS35におけるUpdate CP parameter responseメッセージは、PCF280を介して伝送されてもよい。
また、AMF240は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、AN210へ送信してもよい。例えば、AMF240は、AN210へ送信するメッセージにquota、Rate control、及びcharging policyの少なくとも一つを設定してもよい。この場合、AMF240の代わりに、AN210が、UE200からAF300へ送信されるデータに関するトラヒック制御を行ってもよい。AN210は、UE200からAF300へ送信される制御データに加えて、UE200からAF300へ送信されるユーザデータに関するトラヒック制御を行ってもよい。UE200からAF300へ送信される制御データは、制御データとして伝送されるユーザデータであってもよい。もしくは、AN210は、制御データ及びユーザデータのどちらか一方のみトラヒック制御を行ってもよい。
また、AMF240は、保持したquota、Rate control、及びcharging policyの少なくとも一つを、UE200へ送信してもよい。例えば、AMF240は、Attach処理もしくはTAU(Tracking Area Update)処理において、UE200へ送信するメッセージに、quota、Rate control、及びcharging policyの少なくとも一つを設定してもよい。この場合、AMF240の代わりに、UE200が、AF300へ送信するデータに関するトラヒック制御を行ってもよい。UE200は、AF300へ送信する制御データに加えて、AF300へ送信するユーザデータに関するトラヒック制御を行ってもよい。もしくは、UE200は、制御データ及びユーザデータのどちらか一方のみトラヒック制御を行ってもよい。
また、ユーザデータのトラヒック制御をUPF220が行うために、図10に示される送信データ量に関する情報を通知する処理の流れが用いられてもよい。図10は、図8に示される通信システムにおいて、図7の処理が実行されることを示している。つまり、図10は、図8の5GCを用いて図7の各処理を実行することを示している。図10のステップS41~S46は、図7のステップS21~S26と同様であるため詳細な説明を省略する。
以上説明したように、実施の形態4における5GCにおいても、AMF240がAF300とUE200の間で動作するアプリケーションのトラヒック特性を加味して、制御データとして伝送されるユーザデータに関するトラヒック制御を行うことができる。AMF240は、MME100に相当する。さらに、UPF220がAF300とUE200の間で動作するアプリケーションのトラヒック特性を加味して、ユーザデータに関するトラヒック制御を行うことができる。そして、AMF240およびUPF220はかかる制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題は、AF300とUE200の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
続いて、実施の形態4の変形例について説明する。図11を用いて実施の形態4の変形例にかかる送信データ量に関する情報を通知する処理の流れについて説明する。はじめに、AF300は、UE200に関するパラメータとして、quota、Rate control、及びcharging policyの少なくも一方を決定する(S31_1)。
次に、AF300は、ステップS31_1において決定したパラメータを設定したNIDD Configuration RequestメッセージをNEF260へ送信する(S32_1)。NIDD Configuration Requestメッセージは、T8 Set Suggested Network Configuration Requestメッセージでもよい。
NEF260は、NIDD Configuration Requestメッセージ(S32_1)に設定されたquota、Rate control、及びcharging policyをUE200の管理データとして保持する(S33_1)。
NEF260は、NIDD Authorization RequestメッセージをUDM290に送信する(S34_1)。NIDD Authorization Requestメッセージには、NIDD Configuration Requestメッセージ(S32_1)に設定されたquota、Rate control、及びcharging policyの少なくとも一方がパラメータとして設定されている。NIDD Authorization Requestメッセージは、Set Suggested Network Configuration Requestメッセージでもよい。
UDM290は、UE200に関するquota、Rate control、及びcharging policyの少なくとも一方をUE200の加入者データとして保持する。UDM290は、NIDD Authorization ResponseメッセージをNEF260に送信する(S35_1)。NIDD Authorization Responseメッセージ(S35_1)には、UDM290で更新されたUE200に関するquota、Rate control、及びcharging policyの少なくとも一方が設定されてもかまわない。UDM290は、NIDD Authorization Requestメッセージ(S34_1)に設定されたquota、Rate control、及びcharging policyの少なくとも一方、あるいはすべてについて受領できない旨(Reject)を示すCauseを設定しても良い。NIDD Authorization Responseメッセージは、Set Suggested Network Configuration Responseメッセージでもよい。
NEF260は、NIDD Configuration ResponseメッセージをAF300に送信する(S36_1)。NIDD Configuration Responseメッセージ(S36_1)には、UDM290で更新されたUE200に関するquota、Rate control、及びcharging policyの少なくとも一方が設定されてもかまわない。NEF260は、NIDD Configuration Requestメッセージ(S32_1)に設定されたquota、Rate control、及びcharging policyの少なくとも一方、あるいはすべてについて受領できない旨(Reject)を示すCauseを設定しても良い。NIDD Configuration Responseメッセージは、T8 Set Suggested Network Configuration Responseメッセージでもよい。
以上説明したように、実施の形態4の変形例にかかるUDM290は、NEF260からquota、Rate control、及びcharging policyの少なくとも一方を受信することができる。さらに、UDM290は、この動作完了後に動作するUE200の移動管理、セッション管理を通じて、quota、Rate control、及びcharging policyの少なくとも一方をAMF240、UPF220、及びUE200に通知する事が可能となる。さらにUDM290は、AF300とUE200の間で動作するアプリケーションのトラヒック特性を加味して、UE200からAF300へ送信されるデータ、およびAF300からUE200へ送信されるユーザデータに関するトラヒック制御を行うことができる。UDM290がquota、Rate control、及びcharging policyの少なくとも一方をAMF240に通知する場合は、Insert Subscriber Data Requestメッセージを用いてもかまわない。また、UDM290がquota、Rate control、及びcharging policyの少なくとも一方をUE200に通知する場合は、PCO(Protocol Configuration Option)パラメータを用いてAMF240経由で通知してもかまわない。実施の形態4の変形例にかかるAMF240、UPF220、及びUE200は、AF300とUE200の間で動作するアプリケーションのトラヒック特性を加味してトラヒック制御を行うことにより、アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性を低減できる。アプリケーションが提供するサービスそのものが動作不良となるという問題が生じる可能性は、AF300とUE200の間で動作するアプリケーションのトラヒック特性を加味しないトラヒック制御を行うことにより発生する。
さらに、AMF240が、AN210もしくはUE200へquota、Rate control、及びcharging policyの少なくとも一方を送信してもよい。この場合、AN210もしくはUE200が、UE200からAF300へ送信されるとして伝送されるユーザデータに関するトラヒック制御を行ってもよい。
続いて以下では、図12及び図13を用いて、上述の複数の実施形態で説明された制御装置10、UE60及びUE200の構成例について説明する。
図12は、UE60及びUE200の構成例を示すブロック図である。Radio Frequency(RF)トランシーバ1101は、eNBもしくはgNBと通信するためにアナログRF信号処理を行う。RFトランシーバ1101により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ1101は、アンテナ1102及びベースバンドプロセッサ1103と結合される。すなわち、RFトランシーバ1101は、変調シンボルデータ(又はOFDM(Orthogonal Frequency Division Multiplexing)シンボルデータ)をベースバンドプロセッサ1103から受信し、送信RF信号を生成し、送信RF信号をアンテナ1102に供給する。また、RFトランシーバ1101は、アンテナ1102によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ1103に供給する。
ベースバンドプロセッサ1103は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮/復元、(b) データのセグメンテーション/コンカテネーション、(c) 伝送フォーマット(伝送フレーム)の生成/分解、(d) 伝送路符号化/復号化、(e) 変調(シンボルマッピング)/復調、及び(f) Inverse Fast Fourier Transform(IFFT)によるOFDMシンボルデータ(ベースバンドOFDM信号)の生成などを含む。一方、コントロールプレーン処理は、レイヤ1(e.g., 送信電力制御)、レイヤ2(e.g., 無線リソース管理、及びhybrid automatic repeat request(HARQ)処理)、及びレイヤ3(e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング)の通信管理を含む。
例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ1103によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol(PDCP)レイヤ、Radio Link Control(RLC)レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ1103によるコントロールプレーン処理は、Non-Access Stratum(NAS)プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
ベースバンドプロセッサ1103は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., Digital Signal Processor(DSP))とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., Central Processing Unit(CPU)、又はMicro Processing Unit(MPU))を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ1104と共通化されてもよい。
アプリケーションプロセッサ1104は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ1104は、複数のプロセッサ(複数のプロセッサコア)を含んでもよい。アプリケーションプロセッサ1104は、メモリ1106又は図示されていないメモリから読み出されたシステムソフトウェアプログラム(Operating System(OS))及び様々なアプリケーションプログラムを実行することによって、UE60及びUE200の各種機能を実現する。アプリケーションプログラムは、例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーションであってもよい。
いくつかの実装において、図12に破線(1105)で示されているように、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのSystem on Chip(SoC)デバイス1105として実装されてもよい。SoCデバイスは、システムLarge Scale Integration(LSI)またはチップセットと呼ばれることもある。
メモリ1106は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ1106は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ1106は、ベースバンドプロセッサ1103、アプリケーションプロセッサ1104、及びSoC1105からアクセス可能な外部メモリデバイスを含んでもよい。メモリ1106は、ベースバンドプロセッサ1103内、アプリケーションプロセッサ1104内、又はSoC1105内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ1106は、Universal Integrated Circuit Card(UICC)内のメモリを含んでもよい。
メモリ1106は、上述の複数の実施形態で説明されたUE60による処理を行うための命令群およびデータを含むソフトウェアモジュール(コンピュータプログラム)を格納してもよい。いくつかの実装において、ベースバンドプロセッサ1103又はアプリケーションプロセッサ1104は、当該ソフトウェアモジュールをメモリ1106から読み出して実行することで、上述の実施形態で説明されたUE60及びUE200の処理を行うよう構成されてもよい。
図13は、制御装置10の構成例を示すブロック図である。図13を参照すると、制御装置10は、ネットワークインタフェース1201、プロセッサ1202、及びメモリ1203を含む。ネットワークインタフェース1201は、通信システムを構成する他のネットワークノード装置と通信するために使用される。ネットワークインタフェース1201は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード(NIC)を含んでもよい。
プロセッサ1202は、メモリ1203からソフトウェア(コンピュータプログラム)を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明された制御装置10の処理を行う。プロセッサ1202は、例えば、マイクロプロセッサ、MPU(Micro Processing Unit)、又はCPU(Central Processing Unit)であってもよい。プロセッサ1202は、複数のプロセッサを含んでもよい。
メモリ1203は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1203は、プロセッサ1202から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1202は、図示されていないI/Oインタフェースを介してメモリ1203にアクセスしてもよい。
図13の例では、メモリ1203は、ソフトウェアモジュール群を格納するために使用される。プロセッサ1202は、これらのソフトウェアモジュール群をメモリ1203から読み出して実行することで、上述の実施形態において説明された制御装置10の処理を行うことができる。
図13を用いて説明したように、制御装置10が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体、光磁気記録媒体、CD-ROM(Read Only Memory)、CD-R、CD-R/W、半導体メモリを含む。磁気記録媒体は、例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブであってもよい。光磁気記録媒体は、例えば光磁気ディスクであってもよい。半導体メモリは、例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory)であってもよい。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
なお、本開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、2017年8月8日に出願された日本出願特願2017-153290を基礎とする優先権を主張し、その開示の全てをここに取り込む。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
(付記1)
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する制御部と、を備える制御装置。
(付記2)
前記送信可能なデータ量に関する情報は、quota、Rate control、及びcharging policyの少なくとも一つを含む、付記1に記載の制御装置。
(付記3)
前記制御部は、
前記送信可能なデータ量に関する情報において予め定められたデータ量を超えるデータの送信を拒否する、付記1又は2に記載の制御装置。
(付記4)
前記制御部は、
前記通信端末からC-PlaneデータもしくはU-Planeデータとして送信されたIoT(Internet Of Things)データに対するトラヒック制御を実行する、付記1乃至3のいずれか1項に記載の制御装置。
(付記5)
前記通信部は、
前記送信可能なデータ量に関する情報を、前記通信端末及び基地局の少なくとも一方へ送信する、付記1乃至4のいずれか1項に記載の制御装置。
(付記6)
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置及び制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信する通信部と、
前記送信可能なデータ量に関する情報を用いて、送信するデータに対するトラヒック制御を実行する制御部と、を備える通信端末。
(付記7)
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行する、制御装置において実行される制御方法。
(付記8)
通信端末にサービスを提供するアプリケーションサーバを認証するサービス制御装置を介して、前記アプリケーションサーバにおいて決定された送信可能なデータ量に関する情報を受信し、
前記送信可能なデータ量に関する情報を用いて、前記通信端末から送信されたデータに対するトラヒック制御を実行することをコンピュータに実行させるプログラム。
(付記9)
Uplink dataに関するCPパラメータまたはDownlink dataに関するCPパラメータを、SCEF(Service Capability Exposure Function)ノードからHSS(Home Subscriber Server)を介して受信し、
前記Uplink dataに関するCPパラメータまたは前記Downlink dataに関するCPパラメータを、保持する、
ことを特徴とするMME(Mobility Management Entity)の方法。
(付記10)
前記Uplink dataに関するCPパラメータまたは前記Downlink dataに関するCPパラメータを、基地局に送信する、
付記9に記載のMMEの方法。
(付記11)
前記Uplink dataに関するCPパラメータまたは前記Downlink dataに関するCPパラメータを、伝送リソースの制御のために前記基地局に提供する、
付記10に記載のMMEの方法。
(付記12)
前記基地局は、eNB(evolved Node B)である、付記10または11に記載のMMEの方法。
(付記13)
Uplink dataに関するCPパラメータまたはDownlink dataに関するCPパラメータを、SCEF(Service Capability Exposure Function)ノードからHSS(Home Subscriber Server)を介して受信する手段と、
前記Uplink dataに関するCPパラメータまたは前記Downlink dataに関するCPパラメータを、保持する手段と、
を備えることを特徴とするMME(Mobility Management Entity)。
(付記14)
前記Uplink dataに関するCPパラメータまたは前記Downlink dataに関するCPパラメータを、基地局に送信する手段を、
さらに備える付記13に記載のMME。
(付記15)
前記Uplink dataに関するCPパラメータまたは前記Downlink dataに関するCPパラメータを、伝送リソースの制御のために前記基地局に提供する、
付記14に記載のMME。
(付記16)
前記基地局は、eNB(evolved Node B)である、
付記14または15に記載のMME。
(付記17)
Uplink dataに関するCPパラメータまたはDownlink dataに関するCPパラメータを、MME(Mobility Management Entity)から受信し、
前記Uplink dataに関するCPパラメータまたは前記Downlink dataに関するCPパラメータを、伝送リソースの制御のために用いる、
ことを特徴とする基地局の方法。
(付記18)
前記基地局は、eNB(evolved Node B)である、
付記17に記載の基地局の方法。
(付記19)
Uplink dataに関するCPパラメータまたはDownlink dataに関するCPパラメータを、MME(Mobility Management Entity)から受信する手段と、
前記Uplink dataに関するCPパラメータまたは前記Downlink dataに関するCPパラメータを、伝送リソースの制御のために用いる手段と、
を備えることを特徴とする基地局。
(付記20)
前記基地局は、eNB(evolved Node B)である、
付記19に記載の基地局。
10 制御装置
11 制御部
12 通信部
20 サービス制御装置
30 アプリケーションサーバ
40 基地局
50 通信端末
60 UE
61 制御部
62 通信部
70 eNB
80 SGW
90 PGW
95 PCRF
100 MME
110 SCEF
120 HSS
130 AS
200 UE
210 AN
220 UPF
230 AUSF
240 AMF
250 SMF
260 NEF
270 NRF
280 PCF
290 UDM
300 AF
310 DN

Claims (6)

  1. 通信端末から送信されるUplink dataに関するトラヒック情報を、コアネットワーク内に配置されるモビリティ管理装置から受信する手段と、
    前記モビリティ管理装置から受信したUplink dataに関するトラヒック情報に基づいて、前記通信端末に対してトラヒック制御を行う手段と
    を備えることを特徴とする基地局。
  2. 請求項に記載の基地局であって、
    当該基地局は、eNB(evolved Node B)またはAN(Access Network)を含む。
  3. 請求項またはに記載の基地局であって、
    前記モビリティ管理装置は、MME(Mobility Management Entity)またはAMF(Access and Mobility Management Function)を含む。
  4. 通信端末から送信されるUplink dataに関するトラヒック情報を、コアネットワーク内に配置されるモビリティ管理装置から受信し、
    前記モビリティ管理装置から受信したUplink dataに関するトラヒック情報に基づいて、前記通信端末に対してトラヒック制御を行う
    ことを特徴とする基地局の方法。
  5. 請求項に記載の基地局の方法であって、
    当該基地局は、eNB(evolved Node B)またはAN(Access Network)を含む。
  6. 請求項またはに記載の基地局の方法であって、
    前記モビリティ管理装置は、MME(Mobility Management Entity)またはAMF(Access and Mobility Management Function)を含む。
JP2021112516A 2017-08-08 2021-07-07 基地局及び基地局の方法 Active JP7401111B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2017153290 2017-08-08
JP2017153290 2017-08-08
JP2019535674A JP6911924B2 (ja) 2017-08-08 2018-08-07 基地局の方法、及び基地局

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2019535674A Division JP6911924B2 (ja) 2017-08-08 2018-08-07 基地局の方法、及び基地局

Publications (2)

Publication Number Publication Date
JP2021166403A JP2021166403A (ja) 2021-10-14
JP7401111B2 true JP7401111B2 (ja) 2023-12-19

Family

ID=65272431

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2019535674A Active JP6911924B2 (ja) 2017-08-08 2018-08-07 基地局の方法、及び基地局
JP2021112516A Active JP7401111B2 (ja) 2017-08-08 2021-07-07 基地局及び基地局の方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2019535674A Active JP6911924B2 (ja) 2017-08-08 2018-08-07 基地局の方法、及び基地局

Country Status (4)

Country Link
US (2) US11425596B2 (ja)
EP (1) EP3668185A4 (ja)
JP (2) JP6911924B2 (ja)
WO (1) WO2019031504A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3668185A4 (en) * 2017-08-08 2020-07-22 Nec Corporation CONTROL DEVICE, COMMUNICATION TERMINAL, CONTROL METHOD, NON-TRANSITORIAL COMPUTER READABLE MEDIUM, MME AND BASE STATION
EP3903511A4 (en) * 2018-12-29 2022-07-13 Telefonaktiebolaget LM Ericsson (publ) METHOD AND DEVICE FOR LOCATION-BASED GROUP MESSAGING
US20210136674A1 (en) * 2019-11-06 2021-05-06 Samsung Electronics Co., Ltd. Method and apparatus for managing network slices in wireless communication system

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2339109B (en) * 1998-07-03 2000-05-10 Plessey Telecomm Telecommunications network
US20060281417A1 (en) * 2005-05-10 2006-12-14 Ntt Docomo, Inc. Transmission rate control method and mobile station
CN106507332B (zh) * 2011-11-04 2020-01-10 华为技术有限公司 一种数据传输方法、移动性管理实体和移动终端
CN103731872A (zh) * 2012-10-16 2014-04-16 中兴通讯股份有限公司 对用户设备通过信令传输数据进行控制的方法和装置
JP2014220694A (ja) 2013-05-09 2014-11-20 日本電気株式会社 通信システム、基地局、及び通信方法
WO2016037360A1 (zh) 2014-09-12 2016-03-17 深圳麦克韦尔股份有限公司 电子烟及其电池装置
JP6489334B2 (ja) 2015-03-31 2019-03-27 日本電気株式会社 通信パラメーターセットを受信する通信システム
US9930516B2 (en) * 2015-05-15 2018-03-27 Samsung Electronics Co., Ltd. UE monitoring configuration method and apparatus
WO2017017879A1 (ja) * 2015-07-24 2017-02-02 日本電気株式会社 Scefエンティティ、hss、メッセージ送信方法、及び非一時的なコンピュータ可読媒体
EP3332560B1 (en) * 2015-08-03 2021-05-26 Convida Wireless, LLC Mobile core network service exposure for the user equipment
US10805830B2 (en) * 2015-08-14 2020-10-13 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for regulating user data traffic in a wireless network
KR102425660B1 (ko) 2015-08-21 2022-07-28 삼성전자 주식회사 무선 통신 시스템에서 혼잡 관리 방법 및 장치
US20170086076A1 (en) * 2015-09-18 2017-03-23 Qualcomm Incorporated Setting transmission parameters in shared spectrum
KR102410581B1 (ko) * 2015-10-30 2022-06-17 삼성전자주식회사 무선 통신 시스템에서 업링크 데이터 전송의 제어 방법 및 장치
US10652085B2 (en) * 2016-01-07 2020-05-12 Lg Electronics Inc. Method for setting configuration of non-IP data delivery (NDID) in wireless communication system and device for same
EP3386220B1 (en) * 2016-01-18 2021-08-11 Samsung Electronics Co., Ltd. Methods and apparatus for communication in a mobile communication system
CN112087283A (zh) * 2016-02-18 2020-12-15 瑞典爱立信有限公司 用于管理控制平面优化的数据速率的系统、方法和装置
JP6402732B2 (ja) 2016-02-25 2018-10-10 オムロン株式会社 蓄電装置管理システム、蓄電装置、蓄電装置管理方法および蓄電装置管理プログラム
US9948646B1 (en) * 2016-07-08 2018-04-17 Syniverse Technologies, Llc Machine type communication interworking function proxy
CN107872790A (zh) * 2016-09-26 2018-04-03 中国电信股份有限公司 用户级速率控制方法和基站以及系统
CN108632887B (zh) * 2017-03-23 2021-01-01 华为技术有限公司 一种控制传输速率的方法和系统
EP3668185A4 (en) * 2017-08-08 2020-07-22 Nec Corporation CONTROL DEVICE, COMMUNICATION TERMINAL, CONTROL METHOD, NON-TRANSITORIAL COMPUTER READABLE MEDIUM, MME AND BASE STATION
US20190053157A1 (en) * 2017-08-11 2019-02-14 Mediatek Inc. NB-IoT UE Differentiation
CN109842955B (zh) * 2017-09-23 2023-11-21 华为技术有限公司 通信方法及装置
US10616802B2 (en) * 2018-09-04 2020-04-07 Oracle International Corporation Methods, systems and computer readable media for overload and flow control at a service capability exposure function (SCEF)
ES2947407T3 (es) * 2019-11-08 2023-08-08 Ntt Docomo Inc Sistema de comunicación y método para operar un sistema de comunicación
CN113573368A (zh) * 2020-04-29 2021-10-29 大唐移动通信设备有限公司 一种信息处理方法、装置、设备及计算机可读存储介质
CN114554554A (zh) * 2020-11-26 2022-05-27 中国移动通信有限公司研究院 信息传输方法、装置、pcf实体、终端及业务运营支撑系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Ericsson,Verizon UK Ltd,TeliaSonera,Authorization of efficient small data usage,3GPP TSG-SA WG2#111 S2-153111,2015年10月13日アップロード

Also Published As

Publication number Publication date
US11425596B2 (en) 2022-08-23
US20200374746A1 (en) 2020-11-26
JPWO2019031504A1 (ja) 2020-07-30
US11991553B2 (en) 2024-05-21
WO2019031504A1 (ja) 2019-02-14
EP3668185A4 (en) 2020-07-22
JP2021166403A (ja) 2021-10-14
EP3668185A1 (en) 2020-06-17
US20220303827A1 (en) 2022-09-22
JP6911924B2 (ja) 2021-07-28

Similar Documents

Publication Publication Date Title
US11310697B2 (en) Core node, base station, radio terminal, communication method, radio resource allocation method, base station selection method, and readable medium
JP7401111B2 (ja) 基地局及び基地局の方法
JP6733736B2 (ja) Scefエンティティ及びデータ処理方法
US9730056B2 (en) System, method, and apparatus for facilitating selection of a serving node
JP6693572B2 (ja) システム、制御装置、Exposure Functionエンティティ、及び方法
US20220353659A1 (en) Mobile communication system, mme, terminals and method for communication
JPWO2018012611A1 (ja) 加入者情報管理装置、情報取得方法、通信システム、及び通信端末
JP2019029912A (ja) 制御装置、通信端末、サービス制御装置、通信システム、データ送信方法、及びプログラム
JP6587030B2 (ja) コアノード、及び通信方法
US20240023171A1 (en) Systems and methods for protocol conversion for low power wide area technologies
US20230328507A1 (en) Systems and methods for synchronizing subscriber data and events between networks
WO2018225798A1 (ja) 管理装置、制御装置、通信端末、モビリティ制限情報送信方法、及び非一時的なコンピュータ可読媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210707

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220628

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220823

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20220927

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20221221

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231130

R151 Written notification of patent or utility model registration

Ref document number: 7401111

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151