JP6733736B2 - Scefエンティティ及びデータ処理方法 - Google Patents

Scefエンティティ及びデータ処理方法 Download PDF

Info

Publication number
JP6733736B2
JP6733736B2 JP2018543973A JP2018543973A JP6733736B2 JP 6733736 B2 JP6733736 B2 JP 6733736B2 JP 2018543973 A JP2018543973 A JP 2018543973A JP 2018543973 A JP2018543973 A JP 2018543973A JP 6733736 B2 JP6733736 B2 JP 6733736B2
Authority
JP
Japan
Prior art keywords
data
scef
mme
communication
nidd
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
JP2018543973A
Other languages
English (en)
Other versions
JPWO2018066668A1 (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 JPWO2018066668A1 publication Critical patent/JPWO2018066668A1/ja
Application granted granted Critical
Publication of JP6733736B2 publication Critical patent/JP6733736B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • H04W8/08Mobility data transfer
    • 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
    • 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/14Flow control between communication endpoints using intermediate storage
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18Service support devices; Network management devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/74Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/741Holding a request until resources become available
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/005Routing actions in the presence of nodes in sleep or doze mode
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/04Interfaces between hierarchically different network devices
    • H04W92/14Interfaces between hierarchically different network devices between access point controllers and backbone network device
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/16Interfaces between hierarchically similar devices
    • H04W92/24Interfaces between hierarchically similar devices between backbone network devices
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing energy consumption in communication networks in wireless communication networks

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

本発明はSCEF(Service Capability Exposure Function)エンティティ、通信端末、データ処理方法、データ受信方法、及びプログラムに関し、例えば、Non-IP データを処理するSCEFエンティティ、通信端末、データ処理方法、データ受信方法、及びプログラムに関する。
近年、様々なデバイス(モノ)にモバイル通信機能を持たせ、インターネットに接続したり、デバイス間で通信したりすることを実現するIoT(Internet of Things)に関するモバイル通信技術が発展している。デバイスにモバイル通信機能を持たせる上でのひとつの課題として、消費電力の低減がある。センサー装置など、数年単位の長期間に渡りメンテナンスフリーで稼働することが期待される。このようなデバイスにモバイル通信機能を持たせる上で、通信の消費電力を低減することが望ましい。
モバイル通信に関する標準仕様を定める3GPP(3rd Generation Partnership Project)においては、通信の消費電力を低減する技術の1つとして、IPプロトコルスタックを使用せずデータ通信を行うNon-IP data deliveryが規定されている。
非特許文献1の5.13.3節には、EPC(Evolved Packet Core)ネットワークにおいて、downlink(ネットワークから端末方向)のNon-IP data deliveryを行う構成例と、その構成例における手順が開示されている。
この構成例は、Non-IPデータを受信するUE(User Equipment)と、Non-IPデータの送信元であるSCS(Services Capability Server)又はAS(Application Server)と、Non-IPデータを受け付けて認可と通信量制御及びレート制御(load control)を行うSCEF(Service Capability Exposure Function)と、C(Control)−Planeのメッセージ(例えば、NAS(Non Access Stratum)メッセージ)を用いてNon-IPデータをUEへ送信する交換局MME(Mobility Management Entity)と、を含む。
3GPP TS 23.682 V14.1.0 (2016-09) 5.13.3節
モバイル通信において、downlink(ネットワークから端末方向)の通信は、UEのパワーセーブモード状況、電波状況などにより、一時的に、UEに到達不能(UE is unreachable)の場合がある。非特許文献1の5.13.3節には、downlink(ネットワークから端末方向)のNon-IP data deliveryを行う手順において、downlinkの通信がUEに到達不能だった場合に、UEに到達可能となった後に、Non-IP data deliveryが行われる。
MMEは、Non-IP data delivery送信リクエスト(NIDD Submit Request)をSCEFから受信する。MMEは、UEに到達不能であることを検出した場合、Non-IPデータがUEへ配送されなかったことを示すCauseを含めて、Non-IP data delivery送信リクエストに対する応答(NIDD Submit Response)をリターンする。Non-IP data delivery送信リクエストに設定されるCauseは、さらに、UEが到達可能(UE is reachable)となったことをMMEが検知した場合に、MMEがSCEFへその旨を通知(NIDD Submit Indication)することを示す。
上記応答(NIDD Submit Response)を受信したSCEFは、MMEからNIDD Submit Indicationが送信されるまでNon-IPデータをバッファする。SCEFは、最終的に、MMEからのNIDD Submit Indicationの受信を契機としてNon-IP data delivery送信リクエストを再送する。
しかし、UEに到達不能な間に、SCS又はASから該当UEに対して2つ以上のNon-IP data delivery送信リクエストがあった場合、次の問題が発生する。
UEに到達不能であることによって、SCEFが第1のNon-IPデータをバッファしている間に、SCEFがSCS又はASから第2のNon-IPデータに関するNon-IP data delivery送信リクエストを受信することがある。この場合、SCEFは、第2のNon-IPデータに関するNon-IP data delivery送信リクエストをMMEへ送信する。UEに到達不能の状況であるため、第2のNon-IPデータは、UEに到達せず、第1のNon-IPデータと同様、SCEFにバッファされる結果となる。従って、UEに到達不能の状況において、SCEFが第2のNon-IPデータに関するNon-IP data delivery送信リクエストを送信することは、SCEFとMMEの通信処理をむやみに増加させる悪影響を及ぼす。
本発明の目的は、Non-IP data deliveryにおいて、SCEFとMMEとの間の通信に関する処理負荷が増大することを抑えるSCEFエンティティ、通信端末、データ処理方法、データ受信方法、及びプログラムを提供することにある。
本発明の第1の態様にかかるSCEFエンティティは、通信端末へ配送されなかった第1のNon-IPデータをバッファする記憶部と、サーバ装置から前記通信端末を宛先とする第2のNon-IPデータを受信した際に、前記第1のNon-IPデータがバッファされている場合、前記第2のNon-IPデータを、モバイルネットワーク内の制御装置へ送信することを抑制し、前記第2のNon-IPデータを前記記憶部にバッファする制御部と、を備えるものである。
本発明の第2の態様にかかる通信端末は、自装置が到達可能になるまでSCEFエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信する通信部と、前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取る制御部と、を備えるものである。
本発明の第3の態様にかかるデータ処理方法は、通信端末へ配送されなかった第1のNon-IPデータをバッファし、サーバ装置から前記通信端末を宛先とする第2のNon-IPデータを受信した際に、前記第1のNon-IPデータがバッファされている場合、前記第2のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第2のNon-IPデータをバッファするものである。
本発明の第4の態様にかかるデータ通信方法は、自装置が到達可能になるまでSCEFエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信し、前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取るものである。
本発明の第5の態様にかかるプログラムは、通信端末へ配送されなかった第1のNon-IPデータをバッファし、サーバ装置から前記通信端末を宛先とする第2のNon-IPデータを受信した際に、前記第1のNon-IPデータがバッファされている場合、前記第2のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第2のNon-IPデータをバッファすることをコンピュータに実行させるものである。
本発明により、Non-IP data deliveryにおいて、SCEFとMMEとの間の通信に関する処理負荷が増大することを抑えるSCEFエンティティ、通信端末、データ処理方法、データ受信方法、及びプログラムを提供することができる。
実施の形態1にかかる通信システムの構成図である。 実施の形態2にかかる通信システムの構成図である。 実施の形態2にかかるUEが到達不能である場合の処理の流れを示す図である。 実施の形態2にかかるUEが到達可能である場合の処理の流れを示す図である。 実施の形態3にかかるSCEFが、許容通信量及びレートに関する情報を受信する処理の流れを示す図である。 実施の形態4にかかるUEの構成図である。 実施の形態4にかかるUEが到達可能である場合の処理の流れを示す図である。 実施の形態5にかかるバッファに格納されたNon-IPデータを示す図である。 実施の形態5にかかるバッファに格納されたNon-IPデータを示す図である。 それぞれの実施の形態にかかるUEの構成図である。 それぞれの実施の形態にかかるSCEFの構成図である。
(実施の形態1)
以下、図面を参照して本発明の実施の形態について説明する。図1を用いて本発明の実施の形態1にかかる通信システムの構成例について説明する。図1の通信システムは、SCEF(Service Capability Exposure Function)エンティティ(以下、SCEFとする)10、制御装置20、サーバ装置30、及び通信端末40を有している。SCEF10、制御装置20、サーバ装置30、及び通信端末40は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。
通信端末40は、携帯電話端末、スマートフォン端末、もしくはタブレット型端末等であってもよい。または、通信端末40は、M2M(Mobile to Mobile)端末、MTC(Machine Type Communication)端末、もしくはIoT(Internet of Things)端末等であってもよい。通信端末40は、無線アクセスネットワークを介してSCEFエンティティ10と通信を行う。
サーバ装置30は、例えば、アプリケーションサービスを提供するアプリケーションサーバ(Application Server)であってもよい。もしくは、サーバ装置30は、アプリケーションサーバとSCEF10との間に配置され、アプリケーションサービスに関するデータを中継するサーバ装置であってもよい。
制御装置20は、モバイルネットワーク内に配置されるノード装置である。制御装置20は、モバイルネットワーク内において制御情報を中継もしくは処理するノード装置である。制御情報は、例えば、C(Control)-Planeデータ、C-Planeメッセージ等と称されてもよい。制御装置20は、例えば、3GPPにおいて規定されているMMEもしくはSGSN(Serving GPRS(General Packet Radio Service) Support Node)等であってもよい。
SCEF10は、3GPPにおいて動作が規定されているノード装置である。SCEF10は、3GPPにおいて規定されているモバイルネットワークであって、モバイル通信事業者が管理するモバイルネットワークと、アプリケーションサーバ等のモバイル通信事業者以外の第3者が管理するサーバ装置等との間に配置される。SCEF10は、サーバ装置30に対して、モバイルネットワークにおいて対応可能なサービス、及び当該サービスを提供するための能力に関する情報を、安全に提供する。
また、SCEF10は、サーバ装置30から送信されたNon-IPデータを、モバイルネットワーク内の制御装置20を介して通信端末40へ配送もしくは配信(delivery)する。以下の記載において、配送との用語は、配信と置き換えられてもよい。Non-IPデータは、IPプロトコルスタックを使用しないデータである。Non-IP データとは、通信に用いられるデータ・パケットが EPS(Evolved Packet System) の観点からは構造化されていないものを指す。例えば、LoRa, SIGFOX, NB-IoT など 一般に LPWA (Low Power Wide Area) と総称されるテクノロジーは、デバイスの消費電力を低減するため、IP データ・ベアラを確立しない。これらに対応するため、3GPP 網では C-plane で小容量のデータをやりとりする仕組み(Non-IP Data Delivery (NIDD) )が規定されている。Non-IPデータは、モバイルネットワーク内においては制御情報として伝送される。Non-IPデータは、例えば、IoTサービスを受けるIoT端末へ送信されるデータであってもよい。
続いて、SCEF10の構成例について説明する。SCEF10は、記憶部11及び制御部12を有している。制御部12は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、制御部12は、チップもしくは回路等のハードウェアであってもよい。記憶部11は、例えば、メモリであってもよい。
記憶部11は、通信端末40へ配送されなかったNon-IPデータをバッファする。言い換えると、記憶部11は、Non-IPデータを通信端末40へ再送信するまでに、一時的にNon-IPデータを記憶、保存、もしくは格納する。Non-IPデータが通信端末40へ配送されない場合とは、例えば、通信端末40がパワーセーブモードである場合、もしくは、電波状況が悪化し無線通信を行えない場合等がある。Non-IPデータが通信端末40へ配送されない状態であることを、通信端末40が到達不能(unreachable)であると言い換えてもよい。また、Non-IPデータが通信端末40へ配送することができる状態であることを、通信端末40が到達可能(reachable)であると言い換えてもよい。
制御部12は、サーバ装置30から通信端末40を宛先とするNon-IPデータを受信した際に、通信端末40へ配送されなかったNon-IPデータが記憶部11にバッファされている場合、サーバ装置30から受信したNon-IPデータをモバイルネットワーク内の制御装置20へ送信することを抑制し、サーバ装置30から受信したNon-IPデータを記憶部11にバッファする。Non-IPデータをモバイルネットワーク内の制御装置20へ送信することを抑制するとは、Non-IPデータをモバイルネットワーク内の制御装置20へ送信しないことを含む。
通信端末40へ配送されなかったNon-IPデータが記憶部11にバッファされている場合とは、通信端末40が到達不能な場合である。そのため、SCEF10がサーバ装置30から受信した、通信端末40を宛先とする新たなNon-IPデータを制御装置20へ送信しても、制御装置20は、Non-IPデータを通信端末40へ送信することができない、もしくは、Non-IPデータを通信端末40へ送信することができない可能性が高い。
このような場合に、制御部12が、サーバ装置30から受信したNon-IPデータを制御装置20へ送信せずに、記憶部11にバッファすることによって、モバイルネットワーク内における不要なトラヒックを発生させることを防止することができる。
(実施の形態2)
続いて、図2を用いて本発明の実施の形態2にかかる通信システムの構成例について説明する。図2の通信システムは、SCEF10、MME22、SGSN24、RAN(Radio Access Network)26、AS32、SCS34、及びUE42を有している。
MME22及びSGSN24は、図1の制御装置20に相当する。AS32及びSCS34は、図2のサーバ装置30に相当する。UE42は、図1の通信端末40に相当する。UE42は、3GPPにおいて、通信端末の総称として用いられる。
RAN26は、例えば、LTE(Long Term Evolution)通信をサポートするeNB(evolved Node B)であってもよく、3GPPにおいていわゆる3G通信として規定されている無線通信をサポートするNodeB及びNodeBを制御するRNC(Radio Network Controller)であってもよい。
MME22及びSGSN24は、CPF(C-Plane Function)エンティティ(以下、CPFとする)と称されてもよい。MME22及びSGSN24は、主に、UE42の移動管理、ベアラの設定要求、ベアラの設定指示、ベアラの削除要求、もしくは、ベアラの削除指示を行う装置である。
AS32及びSCS34は、UE42にアプリケーションサービスを提供するために用いられる装置である。アプリケーションサービスは、例えば、IoTサービスと言い換えられてもよい。AS32又はSCS34は、SCEF10へNon-IPデータを送信する。AS32は、SCS34を介さず、SCEF10へ直接Non-IPデータを送信してもよい。AS32又はSCS34は、以下の説明において、AS32/SCS34、もしくは、SCS34/AS32と記載されることがある。
SCEF10は、SCS34/AS32から送信されたNon-IPデータをMME22又はSGSN24へ送信する。MME22又はSGSN24は、RAN26を介してNon-IPデータをUE42へ配送する。MME22又はSGSN24は、UE42が到達不能である場合、Non-IPデータをSCEF10へ返送する。SCEF10は、UE42へ配送されなかったNon-IPデータをバッファする。
また、図2は、SCEF10、MME22、RAN26、及びSGSN24がHPLMN(Home Public Land Mobile Network)に属している構成を示している。一方、SCEF10がHPLMNに属し、MME22、SGSN24、及びRAN26がVPLMN(Visited PLMN)に属する場合、SCEF10とMME22との間、さらに、SCEF10とSGSN24との間に、IWK(Interworking)−SCEFが配置されてもよい。IWK−SCEFは、VPLMNに配置され、SCEF10とMME22との間の通信、さらに、SCEF10とSGSN24との間の通信を中継する。
続いて、図3を用いて、UE42が到達不能である場合の処理の流れについて説明する。図3においては、SCEF10は、MME22を介してNon-IPデータを配送する処理について説明しているが、MME22の代わりにSGSN24が用いられてもよい。
はじめに、SCS34/AS32は、NIDD Submit RequestメッセージをSCEF10へ送信する(S11)。NIDD Submit Requestメッセージは、External Identifier又はMSISDN(Mobile Subscriber Integrated Service Digital Network Number)を含む。さらに、NIDD Submit Requestメッセージは、SCS/AS Reference ID、及びNon-IPデータを含む。External Identifier及びMSISDNは、UE42の識別情報である。SCS/AS Reference IDは、SCS34又はAS32の識別情報である。
次に、SCEF10は、SCS34/AS32からNIDD Submit Requestメッセージを受信すると、External Identifier又はMSISDNに関連付けられたSCEF EPS bearer contextが存在するか確認する(S12)。さらに、SCEF10は、SCS34/AS32からNIDD Submit Requestメッセージを受信すると、SCS34/AS32がNIDD Submit Requestメッセージを送信することを認可されているか確認する(S12)。さらに、SCEF10は、SCS34/AS32からNIDD Submit Requestメッセージを受信すると、SCS34/AS32に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を超過していないかを確認する(S12)。許容通信量は、例えば、1日あたりに送信されたデータ量の累積値であってもよい。
SCEF EPS bearer contextは、MME22とSCEF10との間においてNon-IPデータを送信するためのベアラが確立されていることを示す情報である。MME22とSCEF10との間には、3GPPにおいてリファレンスポイントとしてT6aが定められている。MME22とSCEF10との間のベアラは、UE42のAttach処理時に確立される。また、MME22の代わりにSGSN24が用いられることがある。SGSN24とSCEF10との間には、3GPPにおいてリファレンスポイントとしてT6bが定められている。UE42のSCEF EPS bearerは、UE42とSCS34/AS32との間でNon-IPデータを伝送するための、SCEF10とMME22との間に設定されるベアラである。
SCEF10は、SCEF EPS bearer contextが存在しない、SCS34/AS32がNIDD Submit Requestメッセージを送信することを認可されていない、及び、SCS34/AS32に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を超過している、との事象の少なくとも1つの事象に該当する場合、SCS34/AS32へNIDD Submit Responseメッセージを送信する(S13)。NIDD Submit Responseメッセージには、NIDD Submit Responseメッセージが送信される要因となった情報が設定されている。NIDD Submit Responseメッセージが送信される要因となった情報は、例えば、NIDD Submit Responseメッセージに設定されるcause valueを用いて示されてもよい。
SCEF10は、SCS34/AS32に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を超過している場合、ステップS11において受信したNon-IP データを廃棄してもよい。
また、SCEF10は、SCS34/AS32に許容されているNon-IPデータの許容通信量を超過している場合、超過分のNon-IPデータを廃棄してもよい。また、SCEF10は、SCS34/AS32に許容されているNon-IPデータのレートを超過している場合、一部のNon-IPデータを廃棄し、許容されているレートになるように制御してもよい。
また、SCEF10は、External Identifier又はMSISDNに関連付けられたSCEF EPS bearer contextが存在しない場合、External Identifier又はMSISDNに該当するUEを管理するMMEとの間において、Non-IP PDN connectionを確立するための処理を実行してもよい。
次に、SCEF10は、SCEF EPS bearer contextが存在し、SCS34/AS32がNIDD Submit Requestメッセージを送信することを認可されており、さらに、SCS34/AS32に許容されているNon-IPデータの許容通信量及びレートを超過していない場合、SCEF10の制御部12は、UE42のSCEF EPS bearerへ送信するための別のNon-IPデータを記憶部11に既にバッファしているか否かを判定する(S14)。UE42のSCEF EPS bearerへ送信するための別のNon-IPデータは、例えば、UE42へ配送されなかったNon-IPデータであってもよい。
SCEF10の制御部12は、UE42のSCEF EPS bearerへ送信するための別のNon-IPデータを記憶部11にバッファしていないと判定した場合、SCEF10は、NIDD Submit RequestメッセージをMME22へ送信する(S15)。NIDD Submit Requestメッセージは、User Identity、EPS(Evolved Packet System) Bearer ID、SCEF ID、Non-IPデータ、SCEF Wait Time、及びMaximum Re-transmission timeを含む。User Identityは、UE42の識別情報である。EPS bearer IDは、SCEF10とMME22との間に設定されたベアラ(SCEF EPS bearer)の識別情報である。SCEF IDは、SECF10の識別情報である。SCEF Wait Timeは、SCEF10が、MME22から送信されるResponseメッセージを待つことができる時間である。Maximum Re-transmission timeは、SCEF10がメッセージを再送信することができる時間である。
次に、MME22は、NIDD Submit Requestメッセージを受信すると、UE42が到達不能であることを検出する(S16)。次に、MME22は、NIDD Submit ResponseメッセージをSCEFへ送信する(S17)。NIDD Submit Responseメッセージは、Cause及びRequested Re-transmission Timeを含む。Causeは、UE42がパワーセービングモードであるため一時的に到達可能ではないとしてNon-IPデータがUE42へ配送されなかったこと、さらに、UEが到達可能(UE is reachable)となったことをMME22が検知した場合に、MME22がSCEF10へその旨を通知(NIDD Submit Indication)することを示す内容が設定される。
Requested Re-transmission Timeには、SCEF10が現在到達不能であるUE42へダウンリンクデータを再送信することが可能となることが予測される時間を示す。
また、MME22は、UEが到達可能(UE is reachable)となったことをMME22が検知した場合に、SCEF10へその旨を通知することを示すNot Reachable for NIDD flagを設定する。
次に、SCEF10は、MME22からNIDD Submit Responseメッセージを受信すると、UE42がパワーセービングモードであるため一時的に到達可能ではないことを示すCause valueを参照して、UE42が到達不能であることを理解する。さらに、SCEF10は、ステップS15において送信を試みたNon-IPデータをバッファする(S18)。また、SCEF10は、ステップS14において、UE42のSCEF EPS bearerへ送信するための別のNon-IPデータを記憶部11に既にバッファしていると判定した場合、ステップS15〜S17の処理を実行することなく、ステップS11において受信したNon-IPデータをバッファする(S18)。
次に、SCEF10は、MME22から受信した結果を含む、NIDD Submit ResponseメッセージをSCS34/AS32へ送信する(S19)。もしくは、NIDD Submit Responseメッセージは、SCEF10が、ステップS11において受信したNon-IPデータをMME22へ送信することなくバッファしたことを示す情報を含んでもよいし、UE42がパワーセービングモードであるため一時的に到達可能ではないことを示す情報を含んでもよい。
続いて、図4を用いて、UE42が到達可能である場合の処理の流れについて説明する。はじめに、MME22は、UE42が到達可能もしく到達可能になるところであることを検出する(S21)。例えば、MME22は、UE42がTAU(Tracking Area Update)を実行することによってパワーセービングモードから復帰した場合、もしくは、Mobile Originated通信が開始された場合等に、UE42が到達可能であることを検出する。
次に、MME22は、図3のステップS17においてNIDD Submit Responseメッセージを送信したSCEF10に対して、NIDD Submit Indicationメッセージを送信する(S22)。NIDD Submit Indicationメッセージは、User Identityを含む。User Identityは、UE42の識別情報である。
次に、SCEF10は、MME22からNIDD Submit Indicationメッセージを受信すると、バッファした順に、バッファしていたNon-IPデータをNIDD Submit Requestメッセージを用いてMME22へ送信する(S23)。例えば、SCEF10は、図3のステップS14において、UE42のSCEF EPS bearerへ送信するための別のNon-IPデータを記憶部11に既にバッファしていると判定した場合、はじめに、既にバッファされていたNon-IPデータをMME22へ送信する。その後、SCEF10は、図3のステップS11において受信したNon-IPデータをMME22へ送信する。
また、SCEF10は、Non-IPデータをMME22へ向けて、UE42のSCEF EPS bearerへ送信する際に、SCS34/AS32に許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用する。つまり、SCEF10は、図3のステップS15においてMME22へNon-IPデータを送信する場合に加えて、図4のステップS23においてNon-IPデータを送信する場合においても、通信量及びレート制御を適用する。
次に、MME22は、NIDD Submit Requestメッセージを受信すると、UE42へNon-IPデータを配送する(S24)。例えば、UE42とMME22との間においてC-Plane接続を確立中であれば、MME22は、UE42へNon-IPデータを即時送信する。UE42とMME22との間においてC-Plane接続を確立中でなければ、UE42を呼び出すページング処理を行う。MME22は、ページング処理を行うことによってUE42との間においてC-Plane接続を確立すると、UE42へNon-IPデータを送信する。
次に、MME22は、ステップS24におけるNon-IPデータの配送を開始することができた場合、SCEF10へNIDD Submit Responseメッセージを送信する(S25)。NIDD Submit Responseメッセージは、Non-IPデータの配送を開始することができたことを示すcause valueを含む。さらに、SCEF10は、MME22から受信したNIDD Submit Responseメッセージを、SCS34/AS32へ送信する(S26)。
また、ステップS23〜S26の動作は、バッファされているNon-IPデータの数に応じて繰り返し実施される。つまり、SCEF10は、バッファされているNon-IPデータ毎に、NIDD Submit RequestメッセージをMME22へ送信する。
また、ステップS23において、SCEF10は、Non-IPデータをMME22へ送信する際に、SCS34/AS32に許容されているNon-IPデータの許容通信量及びレートの代わりに、SCEF10に許容されているNon-IPデータの許容量及びレートを超過しないように通信量及びレート制御をしてもよい。
以上説明したように、本発明の実施の形態2にかかるSCEF10は、UE42へ送信すべきNon-IPデータがバッファされているか否かを判定することができる。さらに、SCEF10は、UE42へ送信すべきNon-IPデータがバッファされていると判定した場合、NIDD Submit Requestメッセージの送信処理及びNIDD Submit Responseメッセージの受信処理を行うことなく、Non-IPデータをバッファすることができる。これにより、SCEF10とMME22との間において不要なトラヒックが発生することを回避することができる。
さらに、SCEF10は、バッファしていたNon-IPデータをMME22へ向けて、UE42のSCEF EPS bearerへ送信する場合に、先にバッファしたNon-IPデータをMME22へ向けて、UE42のSCEF EPS bearerへ送信することができる。これより、UE42において、Non-IPデータを受信する順序が逆転することを回避することができる。その結果、Non-IPデータの順序性を維持することが要求されるアプリケーションサービスを提供することができる。
さらに、SCEF10は、バッファしていたNon-IPデータをMME22へ向けて、UE42のSCEF EPS bearerへ送信する場合に、SCS34/AS32もしくはSCEF10に許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用することができる。これより、SCEF10がNon-IPデータを再送する際にバースト転送が発生することを回避することができる。その結果、通信速度の面において低性能のIoTデバイス等のUE42が、Non-IPデータの受信に失敗する事象を減少もしくは回避させることができる。
(実施の形態3)
続いて、図5を用いて本発明の実施の形態3にかかるSCEF10が、許容通信量及びレートに関する情報を受信する処理の流れについて説明する。実施の形態2においては、SCEF10は、SCS34/AS32に許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用している。これに対して、実施の形態3においては、UE42に、又はUE42のSCEF EPS bearerに許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用する。UE42のSCEF EPS bearerは、UE42とSCS34/AS32との間でNon-IPデータを伝送するための、SCEF10とMME22との間に設定されるベアラである。
はじめに、SCS34/AS32は、NIDD Configuration RequestメッセージをSCEF10へ送信する(S31)。NIDD Configuration Requestメッセージは、External IdentifierもしくはMSISDNを含む。External IdentifierもしくはMSISDNは、UE42を識別する情報である。さらに、NIDD Configuration Requestメッセージは、SCS/AS Reference IDを含む。次に、SCEF10は、NIDD Configuration Requestメッセージに含まれるExternal IdentifierもしくはMSISDN、さらに、SCS/AS Reference IDを記憶部11に格納する(S32)。
次に、SCEF10は、SCS34/AS32が、受信したExternal IdentifierもしくはMSISDNに関するNIDD Configuration Requestメッセージを送信することを認可されているかを確認するために、HSS(Home Subscriber Server)へNIDD Authorization Requestメッセージを送信する(S33)。NIDD Authorization Requestメッセージは、External IdentifierもしくはMSISDN、さらに、SCEF10に関連付けられたAPN(Access Point Name)を含む。HSSは、複数のUEに関する加入者情報を管理するノード装置である。
次に、HSSは、SCS34/MME22が、NIDD Configuration Requestメッセージを送信することが認可されていると判定する(S34)。さらに、HSSは、NIDD Authorization Requestメッセージに含まれるExternal IdentifierもしくはMSISDNに対応付けられたIMSI(International Mobile Subscriber Identity)を抽出する。IMSIは、モバイルネットワーク内におけるUEの識別情報として用いられる。
次に、HSSは、NIDD Authorization Requestメッセージに対する応答としてNIDD Authorization ResponseメッセージをSCEF10へ送信する(S35)。NIDD Authorization Responseメッセージは、External IdentifierもしくはMSISDNに対応付けられたIMSIを含む。さらに、NIDD Authorization Responseメッセージは、UE42に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を示すLoadControlInformationを含む。HSSは、UE毎に、又はUEのSCEF EPS bearer毎に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を加入者情報として管理しているとする。
次に、SCEF10は、NIDD Configuration Requestメッセージに対する応答として、NIDD Configuration ResponseメッセージをSCS34/AS32へ送信する(S36)。
図5の処理が実行されることによって、SCEF10は、UE42に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を示す情報をHSSから取得することができる。または、SCEF10は、UE42のSCEF EPS bearerに許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を示す情報をHSSから取得することができる。
また、SCEF10は、図4と同じシーケンスに従ってUE42へNon-IPデータを送信することができる。ただし、SCEF10は、図3のステップS15、および、図4のステップS23において、Non-IPデータをMME22へ向けて、UE42のSCEF EPS bearerへ送信する際に、UE42又はUE42のSCEF EPS bearerに許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用する。
以上説明したように、SCEF10は、バッファしていたNon-IPデータをMME22へ向けて、UE42のSCEF EPS bearerへ送信する場合に、UE42に、又はUE42のSCEF EPS bearerに許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用することができる。これより、通信速度の面において低性能のIoTデバイス等のUE42が、Non-IPデータの受信に失敗する事象を減少もしくは回避させることができる。
(実施の形態4)
続いて、図6を用いて本発明の実施の形態4にかかるUE42の構成例について説明する。UE42は、通信部43及び制御部44を有している。通信部43及び制御部44は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、通信部43及び制御部44は、チップもしくは回路等のハードウェアであってもよい。
通信部43は、MME22から配送されるNon-IPデータを受信する。ここで、通信部43は、複数のNon-IPデータを一つのメッセージを用いて受信する。つまり、MME22は、SCEF10にバッファされているNon-IPデータの数と同じ回数、Non-IPデータの送信を繰り返すのではなく、複数のNon-IPデータを含む一つのメッセージをUE42へ送信する。通信部43は、複数のNon-IPデータを含む1つのメッセージを制御部44へ出力する。
制御部44は、一つのメッセージに含まれる複数のNon-IPデータを、それぞれのNon-IPデータ毎に読み取る。言い換えると、制御部44は、一つのメッセージに含まれる複数のNon-IPデータを、それぞれのNon-IPデータ毎に切り分けて読み取る。さらに言い換えると、制御部44は、一つのメッセージに含まれる複数のNon-IPデータをパース(parse)して読み取る。
制御部44は、例えば、Non-IPデータのデータサイズに関する情報を保持していてもよい。例えば、複数のNon-IPデータを含む一つのメッセージ内に、それぞれのNon-IPデータのデータサイズに関する情報が設定されていてもよい。もしくは、Non-IPデータのデータサイズがモバイルネットワーク内において予め定められている場合、制御部44は、予め定められているNon-IPデータのデータサイズに関する情報を保持していてもよい。制御部44は、Non-IPデータのデータサイズに従って、一つのメッセージに含まれる複数のNon-IPデータを読み取ってもよい。
続いて、図7を用いて、UE42が到達可能である場合の処理の流れについて説明する。図7のステップS41及びS42は、図4のステップS21及びS22と同様であるため詳細な説明を省略する。
次に、SCEF10は、MME22からNIDD Submit Indicationメッセージを受信すると、バッファされている複数のNon-IPデータを一つのNIDD Submit Requestメッセージを用いてMME22へ向けて、UE42のSCEF EPS bearerへ送信する(S43)。例えば、SCEF10は、NIDD Submit Requestメッセージの先頭に近いデータ領域に、はじめにバッファしていたNon-IPデータを設定し、メッセージの最後尾に近いデータ領域に、新たにバッファされたNon-IPデータを設定してもよい。
次に、MME22は、複数のNon-IPデータを含むNIDD Submit Requestメッセージを受信すると、UE42へ一つのメッセージを用いて複数のNon-IPデータを配送する(S44)。
次に、MME22は、ステップS44におけるNon-IPデータの配送を開始することができた場合、SCEF10へNIDD Submit Responseメッセージを送信する(S45)。次に、SCEF10は、Non-IPデータ毎に、NIDD Submit Responseメッセージを、SCS34/AS32へ送信する(S46及びS47)。例えば、ステップS43において、SCEF10は、最初にバッファしていたNon-IPデータ#1と、後からバッファしたNon-IPデータ#2とを一つのNIDD Submit Requestメッセージを用いてMME22へ送信したとする。この場合、SCEF10は、NIDD Submit Responseメッセージを受信すると、Non-IPデータ#1をUE42へ配送したことを示すNIDD Submit ResponseメッセージをステップS46において送信し、Non-IPデータ#2をUE42へ配送したことを示すNIDD Submit ResponseメッセージをステップS47において送信する。
以上説明したように、図7に示す処理を実行することによって、SCEF10は、一つのNIDD Submit Requestメッセージを用いて複数のNon-IPデータをMME22へ向けて、UE42のSCEF EPS bearerへ配送することができる。さらに、MME22は、一つのメッセージを用いて複数のNon-IPデータをUE42へ配送することができる。さらに、UE42は、一つのメッセージに含まれる複数のNon-IPデータを、Non-IPデータ毎に読み取ることができる。
その結果、モバイルネットワーク内において伝送されるメッセージ数を削減することができるため、モバイルネットワーク内に発生し得る輻輳を回避することができる。例えば、UE42としてIoT端末が用いられた場合、モバイルネットワークにかなり多くの数のIoT端末が接続されることが想定される。そのため、UE42としてIoT端末が用いられた場合等に、メッセージ数を削減するより多くの効果を得ることができる。
(実施の形態5)
続いて、実施の形態5にかかるNon-IPデータのバッファへの格納処理について説明する。アプリケーションによっては、複数のNon-IPデータをバッファへ格納する際に、既にバッファに存在するNon-IPデータは不要であり、新しくバッファへ格納されるNon-IPデータのみが必要である場合がある。
例えば、Non-IPデータがUE42の状態を示す情報である場合、新しいNon-IPデータのみが必要となってもよい。具体的には、UE42がランプである場合に、Non-IPデータは、ランプ状態をONにするかOFFにするかを示す情報を含んでもよい。はじめにランプ状態をONにすることを示すNon-IPデータがバッファに格納された後に、ランプの状態をOFFにすることを示すNon-IPデータがSCS34/AS32からSCEF10へ送信されてきた場合、はじめにバッファに格納されたNon-IPデータは不要となる。
このような場合、SCEF10は、最初にバッファに格納したNon-IPデータを削除し、後からSCS34/AS32からSCEF10へ送信されてきたNon-IPデータのみをバッファするようにしてもよい。
ここで、図8及び図9を用いて、バッファに格納されたNon-IPデータについて説明する。図8は、図3のステップS11が送信される前にバッファされているNon-IPデータを示している。図9は、図3のステップS18においてバッファされたNon-IPデータを示している。
図8及び図9のバッファ順は、1番が最も早くバッファされたNon-IPデータであり、3番が最も遅くバッファされたNon-IPデータであることを示している。Non-IPデータの設定内容は、例えば、UE42の制御内容が示されてもよい。例えば、図8のバッファ順が2であるNon-IPデータは、機器のスイッチをONにすることを示す。さらに、それぞれのNon-IPデータには属性IDが設定されているとする。例えば、バッファ順が2であるNon-IPデータは、属性IDとしてランプ状態を示す情報が設定されている。
ここで、SCEF10は、属性IDが同じNon-IPデータを受信した場合、既にバッファされているNon-IPデータを削除してもよい。図9は、バッファ順が2であるNon-IPデータと、新たに受信したNon-IPデータの属性IDが、ランプ状態で一致している場合に、既にバッファされているNon-IPデータを削除していることを示している。
以上説明したように、SCEF10は、Non-IPデータをバッファする際に、既にバッファされているNon-IPデータであって、不要なNon-IPデータを削除することができる。これにより、SCEF10のバッファサイズを縮小させることができる。
続いて以下では、上述の複数の実施形態で説明されたUE42及びSCEF10の構成例について説明する。
図10は、UE42の構成例を示すブロック図である。Radio Frequency(RF)トランシーバ1101は、RAN26と通信するためにアナログRF信号処理を行う。RFトランシーバ1101により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ1101は、アンテナ1102及びベースバンドプロセッサ1103と結合される。すなわち、RFトランシーバ1101は、変調シンボルデータ(又はOFDMシンボルデータ)をベースバンドプロセッサ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))及び様々なアプリケーションプログラム(例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション)を実行することによって、UE42の各種機能を実現する。
いくつかの実装において、図10に破線(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は、上述の複数の実施形態で説明されたUE42による処理を行うための命令群およびデータを含むソフトウェアモジュール(コンピュータプログラム)を格納してもよい。いくつかの実装において、ベースバンドプロセッサ1103又はアプリケーションプロセッサ1104は、当該ソフトウェアモジュールをメモリ1106から読み出して実行することで、上述の実施形態で説明されたUE42の処理を行うよう構成されてもよい。
図11は、SCEF10の構成例を示すブロック図である。図11を参照すると、SCEF10は、ネットワークインターフェース1201、プロセッサ1202、及びメモリ1203を含む。ネットワークインターフェース1201は、ネットワークノード(e.g., MME22もしくはSGSN24)と通信するために使用される。ネットワークインターフェース1201は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード(NIC)を含んでもよい。
プロセッサ1202は、メモリ1203からソフトウェア(コンピュータプログラム)を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明されたSCEF10の処理を行う。プロセッサ1202は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ1202は、複数のプロセッサを含んでもよい。
メモリ1203は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1203は、プロセッサ1202から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1202は、図示されていないI/Oインタフェースを介してメモリ1203にアクセスしてもよい。
図11の例では、メモリ1203は、ソフトウェアモジュール群を格納するために使用される。プロセッサ1202は、これらのソフトウェアモジュール群をメモリ1203から読み出して実行することで、上述の実施形態において説明されたSCEF10の処理を行うことができる。
図10及び図11を用いて説明したように、上述の実施形態にUE42及びSCEF10が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体(Non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、Compact Disc Read Only Memory(CD-ROM)、CD-R、CD-R/W、半導体メモリ(例えば、マスクROM、Programmable ROM(PROM)、Erasable PROM(EPROM)、フラッシュROM、Random Access Memory(RAM))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本発明は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、2016年10月7日に出願された日本出願特願2016−199093を基礎とする優先権を主張し、その開示の全てをここに取り込む。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
(付記1)
通信端末へ配送されなかった第1のNon-IPデータをバッファする記憶部と、
サーバ装置から前記通信端末を宛先とする第2のNon-IPデータを受信した際に、前記第1のNon-IPデータがバッファされている場合、前記第2のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第2のNon-IPデータを前記記憶部にバッファする制御部と、を備えるSCEFエンティティ。
(付記2)
前記制御部は、
前記サーバ装置から前記第2のNon-IPデータを受信した際に、前記第1のNon-IPデータがバッファされているか否かを判定し、前記第1のNon-IPデータがバッファされていると判定した場合、前記第2のNon-IPデータを前記記憶部にバッファし、前記第1のNon-IPデータがバッファされていないと判定した場合、前記制御装置へ前記第2のNon-IPデータを送信する、付記1に記載のSCEFエンティティ。
(付記3)
前記制御部は、
前記制御装置から、前記通信端末へNon-IPデータを配送可能な状態であることを示すメッセージを受信すると、前記記憶部にバッファされている前記第1及び第2のNon-IPデータを前記制御装置へ送信する、付記1又は2に記載のSCEFエンティティ。
(付記4)
前記制御部は、
前記記憶部にバッファされた順に、前記記憶部にバッファされているNon-IPデータを、前記制御装置へ送信する、付記3に記載のSCEFエンティティ。
(付記5)
前記制御部は、
前記記憶部にバッファされている複数のNon-IPデータを含む1つのメッセージを前記制御装置へ送信する、付記3又は4に記載のSCEFエンティティ。
(付記6)
前記制御部は、
前記サーバ装置に許容されている通信量もしくは通信レートを満たすように前記第1及び第2のNon-IPデータを前記制御装置へ送信する、付記3乃至5のいずれか1項に記載のSCEFエンティティ。
(付記7)
前記制御部は、
前記サーバ装置から前記通信端末を宛先とする前記第2のNon-IPデータを受信した際に、前記サーバ装置に許容されている通信量もしくは通信レートを超過している場合、前記第2のNon-IPデータを廃棄する、付記1乃至6のいずれか1項に記載のSCEFエンティティ。
(付記8)
前記制御部は、
前記通信端末または前記通信端末がNon-IPデータを伝送する通信ベアラに許容されている通信量もしくは通信レートを満たすように前記第1及び第2のNon-IPデータを前記制御装置へ送信する、付記3乃至5のいずれか1項に記載のSCEFエンティティ。
(付記9)
前記制御部は、
前記サーバ装置から前記通信端末を宛先とする前記第2のNon-IPデータを受信した際に、前記通信端末または前記通信端末がNon-IPデータを伝送する通信ベアラに許容されている通信量もしくは通信レートを超過している場合、前記第2のNon-IPデータを廃棄する、付記1乃至8のいずれか1項に記載のSCEFエンティティ。
(付記10)
前記制御部は、
前記通信端末または前記通信端末がNon-IPデータを伝送する前記通信ベアラに許容されている通信量もしくは通信レートに関する情報を、前記モバイルネットワーク内に配置されている加入者情報管理装置から受信する、付記8又は9に記載のSCEFエンティティ。
(付記11)
前記制御部は、
前記SCEFエンティティに許容されている通信量もしくは通信レートを満たすように前記第1及び第2のNon-IPデータを前記制御装置へ送信する、付記3乃至5のいずれか1項に記載のSCEFエンティティ。
(付記12)
前記制御部は、
前記サーバ装置から前記通信端末を宛先とする前記第2のNon-IPデータを受信した際に、前記SCEFエンティティに許容されている通信量もしくは通信レートを超過している場合、前記第2のNon-IPデータを廃棄する、付記1乃至11のいずれか1項に記載のSCEFエンティティ。
(付記13)
前記制御部は、
前記第2のNon-IPデータが、前記通信端末の状態を示す前記第1のNon-IPデータを更新するNon-IPデータである場合、前記記憶部から前記第1のNon-IPデータを削除し、前記第2のNon-IPデータを前記記憶部へバッファさせる、付記1乃至12のいずれか1項に記載のSCEFエンティティ。
(付記14)
自装置が到達可能になるまでSCEFエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信する通信部と、
前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取る制御部と、を備える通信端末。
(付記15)
通信端末へ配送されなかった第1のNon-IPデータをバッファし、
サーバ装置から前記通信端末を宛先とする第2のNon-IPデータを受信した際に、前記第1のNon-IPデータがバッファされている場合、前記第2のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第2のNon-IPデータをバッファする、データ処理方法。
(付記16)
自装置が到達可能になるまでSCEFエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信し、
前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取る、データ受信方法。
(付記17)
通信端末へ配送されなかった第1のNon-IPデータをバッファし、
サーバ装置から前記通信端末を宛先とする第2のNon-IPデータを受信した際に、前記第1のNon-IPデータがバッファされている場合、前記第2のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第2のNon-IPデータをバッファすることをコンピュータに実行させるプログラム。
(付記18)
自装置が到達可能になるまでSCEFエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信し、
前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取ることをコンピュータに実行させるプログラム。







































10 SCEF
11 記憶部
12 制御部
20 制御装置
22 MME
24 SGSN
26 RAN
30 サーバ装置
32 AS
34 SCS
40 通信端末
42 UE
43 通信部
44 制御部

Claims (6)

  1. ダウンリンクnon-IPデータを含むNIDD (Non-IP Data Delivery) のリクエストをサーバ装置から受信し、
    前記ダウンリンクnon-IPデータをバッファし、
    ダウンリンクnon-IPデータをすでにバッファしているときに、追加のダウンリンクnon-IPデータを含む追加のNIDDのリクエストを前記サーバ装置から受信した場合、端末が到達可能もしくは到達可能になるところとなる前に前記追加のダウンリンクnon-IPデータを含むNIDDのリクエストを制御装置に対して送信することなく、前記追加のダウンリンクnon-IPデータをバッファする、
    exposure functionエンティティ。
  2. すでにバッファに存在するダウンリンクnon-IPデータのうち、前記追加のダウンリンクnon-IPデータに対応するものを、削除する、
    請求項1に記載のexposure functionエンティティ。
  3. 前記exposure functionエンティティは、
    SCEF (Service Capability Exposure Function) エンティティであり、
    前記サーバ装置は、
    SCS/AS (Service Capability Server / Application Server) であり、
    前記制御装置は、
    MME (Mobility Management Entity) またはSGSN (Serving GPRS (General Packet Radio Service) Support Node) である、
    請求項1または2に記載のexposure functionエンティティ。
  4. ダウンリンクnon-IPデータを含むNIDD (Non-IP Data Delivery) のリクエストをサーバ装置から受信し、
    前記ダウンリンクnon-IPデータをバッファし、
    ダウンリンクnon-IPデータをすでにバッファしているときに、追加のダウンリンクnon-IPデータを含む追加のNIDDのリクエストを前記サーバ装置から受信した場合、端末が到達可能もしくは到達可能になるところとなる前に前記追加のダウンリンクnon-IPデータを含むNIDDのリクエストを制御装置に対して送信することなく、前記追加のダウンリンクnon-IPデータをバッファする、
    方法。
  5. すでにバッファに存在するダウンリンクnon-IPデータのうち、前記追加のダウンリンクnon-IPデータに対応するものを、削除する、
    請求項4に記載の方法。
  6. 前記サーバ装置は、
    SCS/AS (Service Capability Server / Application Server) であり、
    前記制御装置は、
    MME (Mobility Management Entity) またはSGSN (Serving GPRS (General Packet Radio Service) Support Node) である、
    請求項4または5に記載の方法。
JP2018543973A 2016-10-07 2017-10-05 Scefエンティティ及びデータ処理方法 Active JP6733736B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016199093 2016-10-07
JP2016199093 2016-10-07
PCT/JP2017/036380 WO2018066668A1 (ja) 2016-10-07 2017-10-05 Scefエンティティ、通信端末、データ処理方法、データ受信方法、及び非一時的なコンピュータ可読媒体

Publications (2)

Publication Number Publication Date
JPWO2018066668A1 JPWO2018066668A1 (ja) 2019-06-27
JP6733736B2 true JP6733736B2 (ja) 2020-08-05

Family

ID=61831771

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018543973A Active JP6733736B2 (ja) 2016-10-07 2017-10-05 Scefエンティティ及びデータ処理方法

Country Status (5)

Country Link
US (1) US10911936B2 (ja)
EP (2) EP3883271A1 (ja)
JP (1) JP6733736B2 (ja)
CN (1) CN109891918B (ja)
WO (1) WO2018066668A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10791443B2 (en) * 2017-03-03 2020-09-29 Verizon Patent And Licensing Inc. System and method for enhanced messaging using external identifiers
US10805178B2 (en) * 2017-11-27 2020-10-13 Cisco Technology, Inc. Subscription-based event notification techniques for reducing data buffering in mobile networks
US10805841B2 (en) 2018-07-23 2020-10-13 Cisco Technology, Inc. Policy enforcement methods and apparatus for background data transfers involving multiple UEs
US11323948B2 (en) * 2018-07-24 2022-05-03 T-Mobile Usa, Inc. Device management for NB-IoT devices
JP6700371B1 (ja) * 2018-11-29 2020-05-27 ソフトバンク株式会社 管理装置、通信システム、プログラム及び制御方法
WO2020133406A1 (en) * 2018-12-29 2020-07-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for location based group message delivery
US11044605B2 (en) * 2019-05-10 2021-06-22 Verizon Patent And Licensing Inc. Network based non-IP data delivery service authorization for wireless networks
US10972368B2 (en) * 2019-05-17 2021-04-06 Oracle International Corporation Methods, systems, and computer readable media for providing reduced signaling internet of things (IoT) device monitoring
CN112218305B (zh) * 2019-07-09 2022-07-12 华为云计算技术有限公司 一种配置更新方法、通信装置和系统
JP7241047B2 (ja) * 2020-03-31 2023-03-16 ソフトバンク株式会社 表示装置、送信システム、表示システム、表示方法及びプログラム
US11381955B2 (en) 2020-07-17 2022-07-05 Oracle International Corporation Methods, systems, and computer readable media for monitoring machine type communications (MTC) device related information
US11895080B2 (en) 2021-06-23 2024-02-06 Oracle International Corporation Methods, systems, and computer readable media for resolution of inter-network domain names

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004165791A (ja) * 2002-11-11 2004-06-10 Fujitsu Ltd 複数の無線端末と通信可能な無線基地局用の装置、無線基地局と通信する無線端末、そのためのプログラムおよび方法
KR100850912B1 (ko) * 2005-06-15 2008-08-07 삼성전자주식회사 무선통신시스템에서 전력 절약 장치 및 방법
JP2009010628A (ja) * 2007-06-27 2009-01-15 Toshiba Corp 無線通信装置及び無線通信方法
US8588155B2 (en) * 2007-10-23 2013-11-19 Lg Electronics Inc. Method of transmitting broadcasting information
JP2013505210A (ja) * 2009-09-18 2013-02-14 ビーエーエスエフ ソシエタス・ヨーロピア 水への溶解性が低い物質の製剤を製造する方法
US8989070B2 (en) * 2012-07-02 2015-03-24 Intel Corporation Apparatus and method to efficiently send device trigger messages
US9894464B2 (en) * 2014-03-14 2018-02-13 Intel IP Corporation Conveyance of application communication patterns from an external application server to a 3rd generation partnership project system
US10051408B2 (en) * 2014-06-11 2018-08-14 Cisco Technology, Inc. Location reporting of user equipment in a cellular network environment
JP6509613B2 (ja) 2015-04-08 2019-05-08 日本車輌製造株式会社 ピン付きゴムブッシュ及びその組立て分解方法
US10225768B2 (en) * 2015-11-04 2019-03-05 Lg Electronics Inc. Serving node relocating method in wireless communication system and device for same
WO2017140387A1 (en) * 2016-02-18 2017-08-24 Telefonaktiebolaget Lm Ericsson (Publ) System, methods, and apparatuses for managing data rate for control plane optimization
DK3406098T3 (da) * 2016-03-31 2019-07-22 Ericsson Telefon Ab L M Kommunikation med høj latens VIA SCEF

Also Published As

Publication number Publication date
EP3525497A4 (en) 2019-08-14
US20190230492A1 (en) 2019-07-25
EP3525497A1 (en) 2019-08-14
JPWO2018066668A1 (ja) 2019-06-27
EP3525497B1 (en) 2021-04-21
CN109891918B (zh) 2021-08-10
CN109891918A (zh) 2019-06-14
WO2018066668A1 (ja) 2018-04-12
EP3883271A1 (en) 2021-09-22
US10911936B2 (en) 2021-02-02

Similar Documents

Publication Publication Date Title
JP6733736B2 (ja) Scefエンティティ及びデータ処理方法
JP6693572B2 (ja) システム、制御装置、Exposure Functionエンティティ、及び方法
US11310697B2 (en) Core node, base station, radio terminal, communication method, radio resource allocation method, base station selection method, and readable medium
KR101645109B1 (ko) 무선 통신 네트워크 내의 스몰 데이터 기술 및 구성
KR102081013B1 (ko) 무선 단말, 무선국, 코어 네트워크 노드, 및 그것들에서의 방법
TWI795659B (zh) 在通信系統中經由控制平面使用指定之有效負荷容器類型進行使用者資料傳送
US11968565B2 (en) User plane information reporting method and apparatus
EP3525532B1 (en) Control device, paging method, and non-transitory computer-readable medium
JP7401111B2 (ja) 基地局及び基地局の方法
CN110301156B (zh) 通信终端、控制设备、通信系统和通信方法
JP2021057924A (ja) ゲートウェイ装置、及び制御方法
CN111526602B (zh) 无线通信中在拥塞控制下发送用户数据的方法和装置
JP6583531B2 (ja) コアノード、無線端末、及び通信方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190313

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190313

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190327

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200609

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200622

R150 Certificate of patent or registration of utility model

Ref document number: 6733736

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150