JP6138058B2 - サーバ及び通信端末 - Google Patents

サーバ及び通信端末 Download PDF

Info

Publication number
JP6138058B2
JP6138058B2 JP2013557681A JP2013557681A JP6138058B2 JP 6138058 B2 JP6138058 B2 JP 6138058B2 JP 2013557681 A JP2013557681 A JP 2013557681A JP 2013557681 A JP2013557681 A JP 2013557681A JP 6138058 B2 JP6138058 B2 JP 6138058B2
Authority
JP
Japan
Prior art keywords
trigger
address
communication terminal
packet
data
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.)
Expired - Fee Related
Application number
JP2013557681A
Other languages
English (en)
Other versions
JPWO2014006803A1 (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.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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 Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JPWO2014006803A1 publication Critical patent/JPWO2014006803A1/ja
Application granted granted Critical
Publication of JP6138058B2 publication Critical patent/JP6138058B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • 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
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/11Allocation or use of connection identifiers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本開示技術は、セルラー通信機能を利用して通信技術に関し、特に、マシン間コミュニケーション(Machine to Machine CommunicationやMachine Type Communicationと呼ばれる。以下、M2M通信(又はMTCと記載))の技術を利用して通信を行うサーバ及び通信端末に関する。
セルラー通信機能は、携帯電話やスマートフォンなどの音声通話やデータ通信で利用されるだけでなく、M2M通信向けの機器(MTCデバイスとも呼ばれる)でも広く利用されており、MTCデバイスを含むセルラー通信端末(以下、UE(User Equipment)又は通信端末と記載する)の数は今後も増加の一途を辿っている。
ユーザ及びユーザが操作するアプリケーション(以下、MTCアプリケーション、アプリケーションサーバ、又はAS(Application Server)とも呼ぶ)がUEに対してアプリケーションデータ(以下、アプリケーションPDU、アプリケーションペイロード、又はデータとも呼ぶ)を送信する場合、SCS(Service Capability Server、又はMTCサーバ、あるいは単にサーバとも呼ぶ)へデータを渡して、そのデータをUEへ送信することを依頼することができる(Indirect Model)。ASからデータを受けたSCSは、適切な送信手段を用いてデータをUEへ送信する。送信手段としては、例えば、UEのIPアドレス宛のIPパケットを作成し、アプリケーションデータパケットとしてUEへ送信する方法や、セルラーネットワーク内のエンティティへ送信する制御メッセージの中にデータを含めて送信する方法などがある。制御メッセージを用いる場合、SCSは、セルラーネットワークへのゲートウェイであるIWF(Interworking Function)に対して、データを含む制御メッセージを送信する。
このメッセージはデバイストリガ要求(Device Trigger Request、以下トリガ要求とも呼ぶ)と呼ばれ、デバイストリガ要求を受けたMTC−IWFは、データなどのトリガ情報をUEに対して通知するための手段を選択し、送信処理を開始する。UEへトリガ情報を通知するメッセージ(デバイストリガ、以下トリガとも呼ぶ)としては、SMS−SCを介してSMS(Short Message Service)メッセージとして送信する方法や、CBCを介してCBS(Cell Broadcast Service)メッセージとして送信する方法、MBMS(Multicast Broadcast Message Service)メッセージとして送信する方法、さらにはコアネットワーク内のエンティティを介して送信される制御メッセージとして送信する方法などを用いることができる。例えば、IWFが制御メッセージを用いることを選択した場合、IWFはMME/SGSN/MSCに対してトリガ情報を含めた制御メッセージ(T5インタフェース)を送信し、その制御メッセージを受けたMME/SGSN/MSCは、UEに対してトリガ情報を含んだNAS(Network Access Stratum)メッセージを送信する。トリガを受けたUEは、MME/SGSN/MSCに対してトリガ応答を送信する。トリガ応答には必要に応じてUEのアプリケーションデータを含めることもできる。
また、UEがSCSとデータ通信をするためのコネクション(ユーザプレーン、PDPコンテキスト、PDNコネクションなどと呼ぶ)がまだ利用可能でない場合、デバイストリガに関する処理が完了した後、UEは必要に応じて適切なプロシージャ(接続、コネクション確立、コネクション有効化、ベアラ確立、ベアラ有効化、ベアラ変更)を実行する。これらのプロシージャは、コネクション確立要求やサービスリクエスト、ベアラ確立要求などの制御メッセージを送信することで開始される。トリガを受けたUEはコネクションを確立することでIPアドレスを取得でき、ASへ渡すアプリケーションデータを含むIPパケットをSCSへ送信することができる。一方、SCSは、UEから受けたIPパケットに含まれるデータを適切なASへ渡す必要がある。
SCSは、UEのIPアドレスを保持していないためIPパケットを送信する代わりに制御メッセージを送信する。そのため、制御メッセージを送信した後にUEからアプリケーションデータを含むIPパケット受けたSCSは、IPヘッダの送信元アドレスに設定されているIPアドレスに関する情報を持っていないため、送信元のUEを特定することができない。また、IPパケット内のアプリケーションデータの中にUEの識別子が含まれていたとしても、アプリケーションデータはASによって解釈されるフォーマットで作成されているため、SCSはアプリケーションデータのフォーマットを解釈することができない。このため、SCSはIPパケットを受信する際に送信元UEを認証することができないため、IPパケットの送信元であるUEを特定しないままデータをASへ渡すことになり、セキュリティリスクが生じてしまう。
上記の問題を解決するため、本開示技術は、IPパケットの送信を開始する前に制御メッセージを用いてIPアドレスをSCSへ通知することができるようにする技術を開示する。例えば、本開示技術の一態様は、ネットワークを介して、所定の通信装置と通信を行う通信端末であって、前記所定の通信装置から送信され、制御メッセージを前記通信端末へ送信することを要求するトリガ要求メッセージに基づいて生成された前記制御メッセージを前記ネットワークから受信する制御メッセージ受信部と、前記所定の通信装置とIPパケットを使って前記通信をするか否かを判断する判断部と、前記制御メッセージ受信部で前記制御メッセージを受信したとき、IPパケットを使って前記通信をすると判断した場合に、前記所定の通信装置との前記通信に使用するIPコネクションに割り当てられているIPアドレスを取得するコネクション管理部と、前記制御メッセージに対する応答メッセージであって、前記コネクション管理部が取得した前記IPアドレスを含む応答メッセージを前記ネットワークに送信する応答メッセージ送信部とを有する通信端末を含む。上記の構成により、例えば、SCSと通信を開始する前に、UEのIPアドレスを制御メッセージであるトリガ応答に含めてSCSへ通知することができるという効果が実現される。
なお、本開示技術の態様は、上記通信端末以外に、通信システム、コンピュータプログラム、あるいはこれらの組み合わせなどによって実現されてもよい。
なお、本開示技術が有する効果及び利点は、上記に限定されるものではなく、更なる効果及び利点は、本明細書及び図面の開示内容から明らかとなるであろう。上記更なる効果及び利点は、本明細書及び図面に開示されている様々な実施の形態及び特徴によって個別に提供されてもよく、必ずしもすべての効果及び利点が提供される必要はない。
本開示技術の一態様によれば、例えば、SCSと通信を開始する前に、UEのIPアドレスを制御メッセージであるトリガ応答に含めてSCSへ通知することができるという効果が実現される。
本開示技術の第1の実施の形態におけるネットワーク構成の一例を示す図 本開示技術の第1の実施の形態におけるSCS300及びUE100の動作の第1の例を示すシーケンス図 本開示技術の第1の実施の形態において、デバイストリガを受けたUE100が行う処理の一例を示すシーケンス図 本開示技術の第1の実施の形態において、トリガレポートを受けたSCS300が行う処理の一例を示すシーケンス図 本開示技術の第1の実施の形態において、SCヘッダが付加された場合のトリガ応答のメッセージ構成の一例を示す図 本開示技術の第1の実施の形態におけるSCS300及びUE100の動作の第2の例を示すシーケンス図 本開示技術の第1の実施の形態において、デバイストリガを受けたUE100が行う処理の一例を示すフローチャート 本開示技術の第1の実施の形態におけるUE100の構成の一例を示すブロック図 本開示技術の第1の実施の形態におけるSCS300の構成の一例を示すブロック図 本開示技術の第2の実施の形態におけるSCS300及びUE100の動作の例を示すシーケンス図 デバイストリガを受けたUE100が行う処理の第1の例を示すフローチャート デバイストリガを受けたUE100が行う処理の第2の例を示すフローチャート
以下、図面を参照しながら、本開示技術の第1〜第2の実施の形態について説明する。本開示技術の第1の実施の形態では、デバイストリガを受信したUEがASへ送信するアプリケーションデータに基づいて、IPアドレスをSCSへ通知するか否かを判断する方法について説明する。また、本開示技術の第2の実施の形態では、デバイストリガの中のトリガペイロードに含まれているアプリケーションデータに基づいて、IPアドレスをSCSへ通知するか否かを判断する方法について説明する。
(第1の実施の形態)
まず、本開示技術の第1の実施の形態について説明する。図1は、本開示技術の第1の実施の形態におけるネットワーク構成の一例を示す図である。図1には、セルラー通信端末であるUE100と、UE100が接続するセルラーネットワーク(コアネットワーク、3GPPネットワークとも呼ぶ。以下、単にネットワークと記載することもある)200と、UE100宛てのトリガ要求の送信を行うSCS300、及びUE100とデータ通信を行うアプリケーションサーバ400が図示されている。
また、図1には、セルラーネットワーク200の構成要素として、セルラーネットワーク200とSCS300を繋ぐIWF210、UE100の位置情報(ロケーション)の管理やUE100の通信制御(回線交換制御又はパケット交換制御)などを行うMME/SGSN/MSC(Mobility Management Entity/Serving GPRS Support Node/Mobile Switching Center)220、UE100のデータ通信用のコネクション管理や外部ネットワークへのデータ転送、ユーザ認証やQoS制御などを行うP−GW/GGSN/ePDG(Packet Data Network Gateway/Gateway GPRS Support Node/evolved Packet Data Gateway)230、UE100が接続(アタッチ)する基地局とセルラーネットワーク200内のエンティティ(例えばP−GW)との間のコネクション管理やユーザデータ転送を行うS−GW(Serving Gateway)240、UE100に対してセルラーネットワーク200への接続ポイントを提供する基地局として機能するeNB/NB/BS250(evolved Node B/Node B/Base Station)、ユーザのサブスクリプションデータの管理を行うHSS/HLR(Home Subscriber Server/Home Location Register)260、UE100へSMSを送信する役割を持つSMS−SC(Short Message Service-Service Center、又はGMSC/IWMSC)270、IWF210のIDとIPアドレスの対応関係を保持するDNS280が図示されている。
なお、図1には、3GPPで規定されている機能を実現するためのネットワーク構成の一例が図示されているが、本開示技術が適用されるネットワーク構成は図1に図示されているものに限定されるものではない。また、以下の説明では、本開示技術に係る技術的思想を明確にするため、図1に図示されているMME/SGSN/MSC220をMME220と記載し、図1に図示されているP−GW/GGSN/ePDG230をP−GW230と記載することがある。
SCS300は、AS400からアプリケーションデータを取得した際にUE100のIPアドレスを保持していない場合は、IWF210に対してUE100宛のデバイストリガ(制御メッセージ)の送信要求を送信する。一方、IWF210は、SCS300からトリガ要求を受けた場合、ネットワーク200を介してデータを含むトリガ情報をUE100へ送信する。なお、トリガ情報を送信する手段としては、SMSメッセージやCBSメッセージ、MME220宛のメッセージなどの制御メッセージ(C−plane(コントロールプレーン))を用いる方法など複数あるが、IWF210はUEの情報やネットワークの混雑状況などに基づいていずれかの手段を選択する。
セルラーネットワーク200内には、3GPPの無線ネットワーク及びコアネットワークを構成する複数のエンティティが存在し、MME220及びSMS−SC270は、IWF210からの要求を受け、トリガ情報を含むSMSメッセージであるデバイストリガをUE100へ送信する役割を持つ。デバイストリガとして従来のSMSを用いる場合、IWF210はSMS−SC270へデバイストリガの送信を要求し、SMS−SC270はMME220に対してSMSの送信を要求する。MME220は、SMS−SC270から受信したSMSをUE100へ送信する。例えば、MME220は、Downlink NAS TransportのNAS message containerにSMSを含めてUE100へ送信する。一方、MSC220の場合は、SMS専用のメッセージをUE100へ送信する。
また、デバイストリガをMME220へ通知するために、IWF210は、MME220と繋がるインタフェースを用いてトリガ要求を送信することもできる。この場合、MME220は、IWF210からトリガ要求を受けたら、そのトリガ要求に含まれるトリガ情報をDownlink NAS TransportのNAS message containerに含めてデバイストリガとして送信してもよいし、他のNASメッセージに含めてデバイストリガとして送信してもよい。NAS message containerにトリガ情報を入れる際、トリガ情報をSMSのフォーマットに変換したものを入れてもよい。
一方、IWF210がP−GW230へ繋がるインタフェースを持っている場合、P−GW230に対してトリガ情報を含むIPパケットをUE100へ送信するよう要求することもできる。しかし、本開示技術のIWF210はこの方法を用いない。
以下では、説明を簡略化するため、SCS300がIWF210へデバイストリガの送信要求(トリガ要求)を送信し、そのトリガ要求を受信したIWF210が、トリガ情報の送信手段としてMME220へ繋がるインタフェースを用いてトリガ情報を送信する手段を選択する場合を一例として説明する。この場合、MME220は、IWF210から受信したトリガ情報を含めた制御メッセージ(NASメッセージ)をデバイストリガとしてUE100へ送信する。なお、UE100との間でアプリケーションレイヤの通信を行うアプリケーションサーバ400はSCS300上で動作してもよいし、SCS300と接続された他のノード上で動作してもよい。また、SCS300はセルラーネットワーク200内に配置されてもよい。
UE100はデバイストリガを受けると、必要に応じて制御メッセージを送信し、セルラーネットワーク200との間でコネクションの確立や変更などの処理を実行する。このとき送信される制御メッセージとしては、例えば、接続要求(ATTACH REQUEST)や切断要求(DETACH REQUEST)、サービス要求(SERVICE REQUEST)、PDNコネクション確立要求(PDN CONNECTIVITY REQUEST)、専用ベアラ確立要求(ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST)、ベアラリソース割り当て要求(BEARER RESOURCE ALLOCATION REQUEST)、ベアラリソース変更要求(BEARER RESOURCE MODIFICATION REQUEST)などがあるが、どの制御メッセージを送信するべきかについては、デバイストリガの対象となるアプリケーションの種類やアプリケーションの状態、デバイストリガを受けた際のUE100の接続状況などに基づいて判断される。
例えば、デバイストリガを受けたアプリケーションがSCS300とデータ通信を行うために必要なコネクション(PDNコネクション、デフォルトベアラ、専用ベアラ)が未確立(利用可能でない)であった場合は、必要なコネクションを確立するために制御メッセージ(PDNコネクション確立要求、専用ベアラ確立要求(ベアラ確立要求、ベアラ変更要求))を送信する。なお、新たに専用ベアラを確立する代わりに、既存のベアラを更新してアプリケーションの要求を満たすベアラに変更してもよい。コネクションが確立されるとUE100はIPアドレスを取得でき、確立済みのコネクションを介してSCS300へデータパケット(アプリケーションのメッセージ)を送信することができる。
なお、PDNコネクションとは、UE100とPGW230との間で確立されるデータ通信用のコネクションであり、UE100が使用する単一のIPアドレスが割り当てられる。一方、ベアラ(EPSベアラとも呼ぶ)とは、そのPDNコネクションに関連付けられて確立されるコネクションであり、ビットレートが保証されたGBR(Guaranteed Bit Rate)ベアラとベストエフォートのNon−GBRベアラの2つの種類がある。特定のAPN(Access Point Name、PDN(Packet Data Network)の識別子)に対してPDNコネクションが確立される際に、デフォルトベアラ(Non−GBR)も同時に確立される。PDNコネクション及びデフォルトベアラが確立された後、UE100はアプリケーションなどの要求に応じて任意の専用ベアラを確立する。なお、EPS(Evolved Packet System)におけるベアラは、UMTS(Universal Mobile Telecommunications System)におけるPDP(Packet Data Protocol)コンテキストに相当する。
なお、本開示技術の第1の実施の形態では、UE100の通信相手としてアプリケーションサーバ400を想定して説明しているが、UE100の通信相手はアプリケーションサーバ400に限らず、他のUEであってもよい。また、図1で示すセルラーネットワーク200としては、LTE/SAE/EPS(Long Term Evolution/System Architecture Evolution/Evolved Packet System)、UMTS、GPRS(General Packet Radio Service.)やGSM(Global System for Mobile Communications)などのほかに、WiMAX(Worldwide Interoperability for Microwave Access)(登録商標)やモバイルWiMAX、WLAN(Wireless Local Access Network)などを用いてもよいが、その場合の各種エンティティの名称はその仕様に準ずる。
図2は、本開示技術の第1の実施の形態におけるSCS300及びUE100の動作の第1の例を示すシーケンス図である。SCS300はAS400から取得したデータをUE100へ送信するためにトリガ要求をIWF210へ送信する。なお、SCS300は、トリガ要求の送信先であるIWF210のIPアドレスをDNS280へ問い合わせてもよい。すでにIWF210のIPアドレスを保持している場合は、DNS280への問合せは省略される。SCS300はIWF210に対してUE100のID(External Identifier又はMSISDN(Mobile Subscriber ISDN Number))、SCS300のIDなどを含めたトリガ要求を送信する(ステップS2002)。
また、SCS300は、トリガ要求の中のペイロードフィールド(以下、トリガペイロードと呼ぶ)にUE100のアプリケーションへ通知する情報を含める。UE100のアプリケーションに通知する情報とは、AS400から取得したデータやSCS300が生成したデータである。SCS300は、AS400から取得したデータのサイズがトリガペイロードのサイズよりも小さい場合は、全てのデータをトリガペイロードに含めてもよい。一方、AS400から取得したデータのサイズがトリガペイロードのサイズよりも大きい場合は、データの一部をトリガペイロードに含め、残りをIPパケットとして送信してもよいし、又は全てのデータをIPパケットとして送信してもよい。
なお、トリガペイロード内のデータは、コアネットワーク内のエンティティ(IWF210やMME220など)に対しては透過的であり、SCS300によって挿入された情報のままUE100へ通知される。トリガ要求に含まれるUE100のIDは、IWF210及びMME220が送信する制御メッセージの送信先(ターゲット)を示している。トリガ要求を受けたIWF210は、トリガ要求の送信元であるSCS300の確認や、トリガの送信先であるUE100の登録情報(サブスクリプション情報)の確認、及びトリガ要求のロードコントロールのチェックなどを行う。SCS300の確認とは、SCS300から受信したトリガ要求を受け入れてもよいか否かのチェックであり、例えば、デバイストリガの送信を許可(Authorize)されたSCSであるか否か、SCS300がトリガ要求の送信を制限されているSCSでないか、受信したトリガ要求のメッセージにフォーマットエラーがないか、などの確認である。
また、トリガ要求のロードコントロールをチェックとは、トリガ要求の送受信によるネットワーク帯域やトラフィックロード、契約内容に関するチェックであり、例えば、SCS300が送信したトリガ要求の送信回数(Submission Quota)が規定値を超えていないか、トリガ要求の送信頻度(Submission Rate)が規定値を超えていないか、IWFの処理負荷が過負荷(Overload)になっていないかなどの負荷状況の確認である。例えば、SCS300から受信したトリガ要求の送信頻度が規定値(契約で決められた上限値など)を超えていた場合は、ロードコントロールに問題があると判断してトリガ要求を拒絶する。
さらに、UE100の登録情報のチェックとは、HSS(Home Subscription Server)へUE100の情報を問い合わせ、デバイストリガをUEへ送信できるか否かなどを確認する。例えば、UEの情報を確認した結果、UEがデバイストリガの受信資格がなかった場合や、UEがデバイストリガを受信できる状態にない場合は、UEの情報に問題があると判断しトリガ要求を拒絶する。これらのチェックに問題がなかった場合、IWF210は、MME220に対してデバイストリガの要求を送信する(ステップS2003)。これを受けたMME220は、UE100に対してトリガ情報を含む制御メッセージ(デバイストリガ)を送信する(ステップS2004)。
図3は、デバイストリガを受けたUE100が行う処理(図2のステップS2004〜S2006)の一例を示すフローチャートである。デバイストリガを受けたUE100は(S3001)、AS400とデータ通信をするためのコネクションがあるか否かを確認する(S3002)。コネクションがない場合は、コネクションを確立するための処理を実行する(S3003)。この場合、UE100は、コネクションを確立してIPアドレスを取得することができるまで、デバイストリガに対するトリガ応答を送信しない。そして、そのコネクションに割り当てられているIPアドレスをトリガ応答の所定のフィールド(トリガペイロード)に含め(S3004)、MME220へ送信する(S3005)。
AS400とデータ通信をするためのコネクションとは、AS400が存在するPDN(Packet Data Network)に接続するコネクションである。つまり、受信したデバイストリガの中のトリガペイロードに含まれているデータから導かれたAPN(Access Point Name)や、デバイストリガの対象であるアプリケーションに対応するAPNによって識別されるPDN上のSCS300と通信をするためのコネクションである。UE100は、SCS300がIWF210から受信するトリガレポートからIPアドレスを適切に取り出すことができるよう、SCS300が解釈できるフォーマットにIPアドレスを含めてトリガペイロードに挿入する。
例えば、SCS300が解釈できるフォーマットで構成されたヘッダ(以下、SC(Service Capability)ヘッダと呼ぶ)を作成し、そのヘッダにIPアドレスを含めてトリガペイロードの所定の位置(最前部又は最後部)に配置する。もしUE100からAS400へ通知するデータがある場合は、そのデータの先頭にSCヘッダを付加したものをトリガペイロードに挿入する。
図5は、SCヘッダが付加された場合のトリガ応答のメッセージ構成の一例を示す図である。UE100から送信されたトリガ応答を受けたMME220は、トリガ応答に含まれているトリガペイロードをトリガレポートに含めIWF210へ送信し、さらにIWF210はそのトリガレポートをSCS300へ送信する(ステップS2007、S2008)。なお、図2では、ステップS2006をトリガ応答と呼び、ステップS2007、S2008をトリガレポートと呼んで区別しているが、UE100が挿入したトリガペイロード(SCヘッダ及びデータ)をSCS300へ通知することができるメッセージであればどのようなメッセージを用いてもよい。
図4は、トリガレポートを受けたSCS300が行う処理(図2のステップS2008〜S2010)の一例を示すフローチャートである。トリガレポートを受けたSCS300は(S4001)、トリガレポートのトリガペイロードに含まれている情報を取得し(S4002)、そのトリガペイロードにIPアドレスを含むSCヘッダが含まれているか否かを確認する(S4003)。SCヘッダがある場合は、SCヘッダに含まれているIPアドレスを取得し、IPアドレスとUEのIDを関連付けて保持する(S4004)。そして、SCヘッダを取り除いた残りの部分をデータとしてASへ通知する(S4005)。IWF210とSCS300の間で送受信されるメッセージは秘匿性や完全性などのセキュリティ用件を満たすメッセージ(制御メッセージ)であるため、SCS300は、IWF210から受信するトリガレポートに含まれているIPアドレスがUE100のIPアドレスであることを信用することができる。UE100がユーザプレーンを用いてIPアドレスをSCS300へ通知する場合にはIPSecなどのセキュリティメカニズムを用いてセキュリティを確保する必要があるため、UE100とSCS300の処理負荷が増すが、制御メッセージを用いてIPアドレスを通知することでその処理負荷を軽減することができる。
ステップS4003において、IPアドレスを含むSCヘッダがない場合はトリガペイロードの中の全ての情報をデータとしてASへ通知する(S4005)。一方、SCヘッダからUE100のIPアドレスの取得をした後は、SCヘッダを取り除いた残りの情報をデータとしてASへ通知する(S4005)。なお、S4003において、SCヘッダは存在しているが、IPアドレスが含まれていない場合も同様に、SCヘッダを取り除いた残りの部分をデータとしてASへ通知する。図2に戻り、UE100は、データを含むIPパケットをSCS300へ送信する(S2011)。
IPパケットを受信したSCS300は、IPパケットの送信元アドレスの確認を行い(S2012)、送信元のIPアドレスを保持している場合は、IPペイロードに含まれているデータをAS400へ通知する(S2013)。一方、送信元アドレスに対応するIPアドレスを保持していない場合は、送信元のUEを特定できないため、IPパケットを破棄する。送信元のIPアドレスを保持している場合とは、送信元のIPアドレスが、ステップS2009のトリガレポートで通知されたIPアドレスに一致する場合であり、そのIPアドレス対応するUEを特定できる場合である。なお、IPペイロードの中のデータにSCS300が処理するべきヘッダが付加されている場合は、それらのヘッダを取り除いた残りの部分のデータをAS400へ通知する。
図6は、本開示技術の第1の実施の形態におけるSCS300及びUE100の動作の第2の例を示すシーケンス図である。図2を用いて説明した第1の例との違いは、トリガを受けたUE100が、ステップS6006においてコネクションの有無を確認する前に、ステップS6005において、AS400へ送信するアプリケーションデータを確認するところである。その他のステップについては、図2と同じであるため説明を省略する。
図7は、デバイストリガを受けたUE100が行う処理(ステップS6004〜S6007)の一例を示すフローチャートである。図3を用いて説明した第1の例におけるUE100の動作との違いは、ステップS7002において、UE100のアプリケーションからAS400へ通知するデータをIPパケットで送信する必要があるか否かを確認するところである。デバイストリガを受けたUE100は(S7001)、デバイストリガに含まれているトリガペイロードをアプリケーションへ通知する(S7002)。もしアプリケーションが起動されていない場合は、デバイストリガの対象となるアプリケーションを起動した後にデータを通知する。なお、UE100のNASレイヤがデバイストリガを受信し、トリガペイロードを適切なアプリケーション又はアプリケーションを制御するレイヤ(以下、SC(Service Capability)レイヤ)へ通知する。SCレイヤはトリガペイロードの処理を行い、必要に応じてトリガペイロードに含まれているデータを適切なアプリケーションへ通知する役割を持つ。
例えば、SCヘッダに含まれているアプリケーションIDから対象となるアプリケーションを特定(起動)し、そのアプリケーションに対してSCヘッダを取り除いた残りの情報をデータとして通知する。つまり、UE100のNASレイヤは、受信したデバイストリガに対するトリガ応答を送信する前に、SCレイヤ及びアプリケーションによるトリガペイロード及びデータの処理結果が通知されるまで待機する。なお、これらのSCレイヤの機能は、NASレイヤとアプリケーションレイヤの間に位置するレイヤによって提供されてもよいし、アプリケーションレイヤで動作する1つのアプリケーションとして提供されてもよいし、NASレイヤによって提供されてもよい。
トリガペイロードを処理した結果、AS400へ送信するアプリケーションデータがある場合は、そのデータはIPパケットを用いて送信する必要があるデータか否かを確認する(S7003)。データをIPパケットで送信する必要がある場合とは、データのサイズがトリガ応答に含められるデータサイズ(トリガペイロードのサイズ)よりも大きい場合などである。また、AS400へ送信するデータの生成に時間を要する場合(SCレイヤ又はアプリケーションへトリガペイロードを通知してから一定時間経過した場合)は、NASレイヤは、IPパケットを用いてデータを送信する必要があると判断してもよい。なお、IPパケットでデータを送る必要があるか否かの判断は、UE100のNASレイヤだけで行ってもよい。例えば、デバイストリガに含まれているSCS300の識別情報や、データを生成したAS400の識別情報に基づいて、IPパケットを用いたデータ通信が必要であるか否かを確認する。
データをIPパケットで送信する必要がある場合は、AS400とデータ通信をするためのコネクションがあるか否かを確認する(S7004)。ステップS7004以降の動作は図3のステップS3002以降の動作と同じであるため説明を省略する。一方、UE100のアプリケーションからAS400へ通知するデータをIPパケットで送信する必要がない場合は、データのみを含むトリガペイロードを挿入したトリガ応答を送信する(S7007)。なお、UE100は、IPアドレスを含まないSCヘッダをデータに付加したものをトリガペイロードに挿入し、そのトリガペイロードを含むトリガ応答を送信してもよい。
次に、本開示技術の第1の実施の形態におけるUE100の構成例について説明する。図8は、本開示技術の第1の実施の形態におけるUE100の構成の一例を示すブロック図である。図8に図示されているUE100は、インタフェース101、デバイストリガ処理部102、コネクション管理部103、アプリケーション部104、トリガ応答送信部105、IPパケット送信部106を有している。
インタフェース101は、UE100がネットワークに接続して制御メッセージやIPパケットを送受信するための機能を有している。インタフェース101には、他の通信装置(例えば、ネットワーク上に配置されているネットワークノードや他のUE100など)と通信を行うために、情報を電気的な信号に変調及び復調するハードウェアも含まれる。デバイストリガ受信部102は、デバイストリガを受信し、デバイストリガに含まれているトリガペイロードをアプリケーション部104へ渡す。また、コネクション管理部103に対して、コネクションの確立を行うよう指示する。
コネクション管理部103は、デバイストリガ受信部102又はトリガ応答送信部105の指示を受け、コネクションの確立を行う。AS400との通信に使用できるコネクションが既にある場合は、そのコネクションに割り当てられているIPアドレスをトリガ応答送信部105へ通知する。なお、コネクション管理部103が行う処理は、新たなコネクションの確立に限らず、確立済みコネクションの変更なども含む。アプリケーション部104は、デバイストリガ受信部102から通知されたトリガペイロードをチェックし、AS400に対して送信するデータを生成し、トリガ応答送信部105へ通知する。トリガ応答送信部105は、アプリケーション部104から通知されたデータをIPパケットで送る必要がある場合は、コネクション管理部103からIPアドレスを取得し、IPアドレスを含むトリガ応答を送信する。また、トリガ応答を送信した後、IPパケット送信部に対してデータをIPパケットで送信するよう指示する。IPパケット送信部106は、トリガ応答送信部105から受けたAS400へ通知するデータを含むIPパケットをSCS300宛に送信する。
次に、本開示技術の第1の実施の形態におけるSCS300の構成例について説明する。図9は、本開示技術の第1の実施の形態におけるSCS300の構成の一例を示すブロック図である。図9に図示されているSCS300は、インタフェース400、トリガ要求送信部302、送信手段判断部303、IPパケット受信部304、アプリケーション部305、UE情報保持部306、トリガ応答受信部307を有している。
インタフェース101は、UE100がネットワークに接続して制御メッセージやIPパケットを送受信するための機能を有している。インタフェース101には、他の通信装置(例えば、ネットワーク上に配置されているネットワークノードや他のUE100など)と通信を行うために、情報を電気的な信号に変調及び復調するハードウェアも含まれる。トリガ要求送信部302は、送信手段判断部303の指示を受け、UE100に対するデバイストリガの送信を要求するためのトリガ要求をIWF210へ送信する。トリガ要求のトリガペイロードにはアプリケーション部305から通知されたデータを含める。送信手段判断部303は、アプリケーション部305から通知されたデータをUE100へ送信するための手段を選択する。
トリガ要求を送信手段として選択した場合は、トリガ要求送信部302に対してトリガ要求を送信するよう指示する。IPパケット受信部304は、UE情報保持部306に保持されているUEのIDとIPアドレスの対応関係を参照し、受信したIPパケットの送信元アドレスを持つUEを特定する。送信元のUEを特定できた場合は、IPパケットに含まれているデータをアプリケーション部305へ通知する。アプリケーション部305は、AS400からデータを受け、送信手段判断部303に対してUE100へ送信するよう指示する。
また、IPパケット受信部304及びトリガ応答受信部307から受けたデータをAS400へ通知する。なお、アプリケーション部305は、AS400の機能を含んでいてもよい。UE情報保持部306は、UEのIDとIPアドレスの対応関係を保持している。トリガレポート受信部307は、トリガレポートを受信し、トリガレポートに含まれているトリガペイロードの中のSCヘッダに設定されているIPアドレスを取得し、UE情報保持部306へ保持するよう指示する。さらに、SCヘッダを取り除いた残りのトリガペイロードをアプリケーション部305へ通知する。
以上説明したように、本開示技術の第1の実施の形態によれば、UE100は、受信したデバイストリガに対する応答を返す前に、AS400と通信をするためのコネクションの確立を行い、割り当てられたIPアドレスをSCS300が解釈できるフォーマットでトリガ応答に含めることができるため、SCS300は、コアネットワーク200から受信した信頼できるトリガレポートメッセージに含まれるUE100のIPアドレスを保持することができる。また、UE100からIPパケットを受信する前に、UE100のIPアドレスを知ることができるため、受信したIPパケットの送信元アドレスを確認できた場合にデータをAS400へ通知する。これにより、UE100のIPアドレスは信頼できるメッセージでSCS300へ通知されるため、SCS300は、信頼できるIPアドレスから送られたIPパケットだけを受信し、そのIPパケットに含まれるデータをAS400へ通知することができる。
(第2の実施の形態)
次に、本開示技術の第2の実施の形態において、デバイストリガの中のアプリケーションペイロードに含まれているアプリケーションデータに基づいて、IPアドレスをSCSへ通知する方法について説明する。
図10は、本開示技術の第2の実施の形態におけるSCS300及びUE100の動作の第1の例を示すシーケンス図である。図2を用いて説明した本開示技術の第1の実施の形態の第1の例との違いは、トリガを受けたUE100が、ステップS10005において受信したアプリケーションデータを確認するところである。その他のステップについては、図2と同じであるため説明を省略する。図11は、デバイストリガを受けたUE100が行う処理(ステップS10004〜S10007)の第1の例を示すフローチャートである。図3を用いて説明した本開示技術の第1の実施の形態の第1の例におけるUE100の動作との違いは、ステップS11003において、トリガペイロードの中にデータが含まれているか否かを確認するところである。
デバイストリガを受けたUE100は(S11001)、デバイストリガに含まれているトリガペイロードを取得する(S11002)。トリガペイロードにデータが含まれているか否かを確認し(S11003)、含まれていない場合は、SCS300はAS400から通知されたデータをIPパケットで送信するために、UE100からIPアドレスが通知されるのを待っていると解釈する。そのため、ステップS11004及びステップS11005の処理を経た後、最終的にUE100はトリガ応答の中にIPアドレスを含むSCヘッダをトリガペイロードに挿入して送信する(S11006、S11007)。ステップS11004以降の処理は図2と同じであるため説明を省略する。
一方、トリガペイロードにデータが含まれている場合は、SCS300はAS400から通知されたデータをトリガペイロードに含めていると解釈し、SCS300はAS400から通知されたデータをIPパケットで送信する必要がないかもしれないと解釈する。そのため、UE100は、IPアドレスを含まないトリガ応答を送信する(S11007)。なお、UE100は、データのみを含むトリガペイロードを挿入したトリガ応答を送信してもよいし、IPアドレスを含まないSCヘッダを付加したデータを含むトリガペイロードを挿入したトリガ応答を送信してもよい。なお、ステップS11003において、トリガペイロードの中にSCヘッダが含まれている場合には、SCヘッダを取り除いた残りの部分にデータが含まれているか否かを確認し、データが含まれていた場合にはステップS11007へ進み、含まれていない場合にはステップS11004へ進む。SCヘッダに基づいてIPアドレスを通知するべきか否かを判断する方法については後述する。
図10に戻り、UE100は、データを含むIPパケットをSCS300へ送信する(S10012)。IPパケットを受信したSCS300は、IPパケットの送信元アドレスの確認を行い(S10013)、送信元のUEを特定できた場合は、データをAS400へ通知する(S10014)。一方、送信元アドレスに対応するUEを特定できなかった場合は、データをAS400へ通知せずにIPパケットを破棄する。
図12は、デバイストリガを受けたUE100が行う処理(ステップS10004〜S10007)の第2の例を示すフローチャートである。図11を用いて説明した本開示技術の第2の実施の形態の第1の例におけるUE100の動作との違いは、ステップS12002においてコネクションがない場合に、トリガペイロードを取得し(S12003)、そのトリガペイロードにデータが含まれているか否かを確認する。データが含まれていない場合は、SCS300はAS400から通知されたデータをIPパケットで送信するために、UE100からIPアドレスが通知されるのを待っていると解釈する。そのため、UE100はコネクション確立処理を実行し(S12007)、IPアドレスを含むSCヘッダをトリガペイロードに挿入し、そのトリガペイロードを含むトリガ応答を送信する(S12008、S12009)。
一方、データが含まれている場合には、IPアドレスの遅延通知情報をSCヘッダに含め、そのSCヘッダをトリガペイロードに挿入し(S12005)、そのトリガペイロードを含むトリガ応答を送信する(S12006)。そして、平行してコネクションの確立処理を実行し(S12007)、確立したコネクションに割り当てられたIPアドレスを含むSCヘッダをトリガペイロードに挿入し(S12008)、そのトリガペイロードを含むトリガ応答を再度送信する(S12009)。SCS300は、IPアドレスの遅延通知を含むトリガレポートを受信した場合、その遅延通知をUE100のIDと関連付けて保持する。そして、AS400からUE100に対して通知するデータを受けたときに、UE100のIPアドレスを保持していない場合であってもトリガ要求を送信するのではなく、UE100からIPアドレスが通知されるのを待つべきと判断する。そしてUE100からIPアドレスが通知されたら、AS400から受けたデータをIPパケットを用いてUE100へ送信する。
また、本開示技術の第2の実施の形態におけるSCS300及びUE100の動作の第2の例として、SCS300はIWF210へ送信するトリガ要求のトリガペイロードの中にSCヘッダを含める。この場合、SCS300は、AS400から受けたデータの先頭にSCヘッダを付加したものをトリガペイロードに挿入する。このSCヘッダのIPアドレスを含めるフィールドにはSCS300のIPアドレスが含まれていてもよい。またこのSCヘッダのアプリケーションIDを含めるフィールドにはAS400の識別子、又はAS400で動作しているアプリケーションの識別子が含まれていてもよい。
また、SCS300は、AS400から取得したデータのサイズがトリガペイロードのサイズよりも大きい場合は、UE100に対してIPアドレスの通知を要求するために、トリガペイロードにSCヘッダを含めてもよい。この場合、SCS300は、AS400から通知されたデータの一部に対してSCヘッダを付加したものをトリガペイロードに挿入してもよいし、SCヘッダのみをトリガペイロードに挿入してもよい。SCS300は、UE100からIPアドレスの通知を受けるまで、トリガペイロードに入れられなかったデータを保持し、UE100のIPアドレスを取得した後に、IPパケットとしてUE100へ送信する。
なお、SCS300は、UE100のIPアドレスの通知を要求していることを示す情報をSCヘッダの中に明示的に含めてもよい。例えば、IPアドレスの通知を要求していることを示すフラグをSCヘッダにセットすることや、UE100のIPアドレスを含めるフィールドを空(ゼロ値)又は任意の値にすることで、UE100のIPアドレスの通知を要求していることを示してもよい。また、これとは反対に、UE100のIPアドレスの通知が不要であることを示す情報をSCヘッダの中に明示的に含めてもよい。
デバイストリガを受けたUE100のNASレイヤは、デバイストリガに含まれているトリガペイロードをSCレイヤへ渡す。SCレイヤは、トリガペイロードにSCヘッダが含まれていた場合や、SCヘッダにIPアドレスの通知を要求する情報が含まれていた場合には、SCS300へIPアドレスを通知する必要があると判断し、IPアドレスが設定されたSCヘッダを含むトリガペイロードをトリガ応答に挿入して送信する。またSCレイヤは、SCヘッダに含まれているアプリケーションIDから対象となるアプリケーションを特定(起動)し、そのアプリケーションに対してSCヘッダを取り除いた残りの情報をデータとして通知する。またSCレイヤは、SCヘッダにSCS300のIPアドレスが含まれている場合、そのIPアドレスを取得し、SCS300へIPパケットを送信する際に宛先アドレスとして使用する。
このように、UE100は、受信したデバイストリガのトリガペイロードの中にSCヘッダがあるか否か、又はSCヘッダの内容を確認し、SCS300へIPアドレスを通知する必要があるか否かを判断する。
以上説明したように、本開示技術の第2の実施の形態によれば、UE100は、受信したデバイストリガのトリガペイロードを確認することで、SCS300に対してIPアドレスの通知をするべきか否かを判断することができる。さらに、SCS300に対してIPアドレスを直ぐに通知する必要はないが、コネクションを確立した後にIPアドレスを通知することを事前に通知しておくことで、SCS300は、UE100に対してIPパケットを用いて送信するべきデータがあったとしても、直ぐにデバイストリガ要求を送信するのではなく、UE100からのIPアドレスの通知を待つべきであると判断することができる。これにより、不要なデバイストリガ要求の送信をなくすことができる。
本開示技術の一態様では、通信端末において、前記コネクション管理部が、前記IPアドレスを取得する際、前記IPコネクションが確立されていない場合に新たにIPコネクションを確立してもよい。
また、本開示技術の一態様では、通信端末において、前記応答メッセージ送信部が、前記IPアドレスを、前記応答メッセージの中のアプリケーション情報を入れるためのフィールドに挿入してもよい。
また、本開示技術の一態様では、通信端末において、前記応答メッセージ送信部が、前記制御メッセージの中にアプリケーションデータが含まれていない場合に、IPパケットを使って前記通信をすると判断してもよい。
また、本開示技術の一態様では、通信端末において、前記応答メッセージ送信部が、前記所定の通信装置へ送信すべきアプリケーションデータを前記通信端末が有する場合に、IPパケットを使って前記通信をすると判断してもよい。
また、本開示技術の一態様は、通信端末とアプリケーションサーバとの通信を仲介するサーバであって、前記アプリケーションサーバからデータを取得した際、制御メッセージを前記通信端末へ送信することを要求するトリガ要求をネットワークノードへ送信するトリガ要求送信部と、前記トリガ要求に基づいて前記ネットワークから前記通信端末へ送信された前記制御メッセージに対する応答メッセージであって、前記通信端末のIPアドレスを含む応答メッセージを受信した前記ネットワークノードから前記IPアドレスを含むレポートメッセージを受信し、前記レポートメッセージの中に含まれる前記通信端末のIPアドレスを取得するレポート受信部と、前記IPアドレスと前記通信端末の識別情報を関連付けて保持する通信端末情報保持部とを有するサーバを含むことができる。
また、本開示技術の一態様では、サーバにおいて、前記IPアドレスが、前記レポートメッセージのアプリケーション情報を入れるためのフィールドに挿入されていてもよい。
また、本開示技術の一態様では、サーバにおいて、受信したIPパケットの送信元アドレスが、前記通信端末情報保持部に保持されているIPアドレスと一致する場合に、前記IPパケットに含まれているペイロードを前記アプリケーションサーバへ通知するIPパケット受信部を更に有してもよい。
なお、例えば、上記本開示内容の各態様は適宜組み合わせることが可能である。また、本開示技術の一態様は、通信端末、サーバに加えて、通信端末などによって実現される方法、この方法をコンピュータに実行させるためのプログラム、及びこのプログラムを記録した記録媒体などによって実現されてもよい。
また、上記実施の形態の説明に用いた各機能ブロックは、ハードウェア、ソフトウェア、あるいはこれらの組み合わせによって実現されてもよい。例えば、ブロック図などに図示されている各装置に含まれる機能ブロック、あるいは、同等の機能を有する各処理部は、任意のコンピュータのCPU、メモリ、通信インタフェースを含む各種インタフェースなどのハードウェアによって実現されてもよい。また、各機能に係る動作が記述されたプログラムをコンピュータによって実行させることで、各機能ブロックや各処理部が実現されてもよい。また、上記実施の形態におけるフローチャートやシーケンスチャートは、CPUやメモリなどのハードウェアによって実現されてもよい。
なお、上記の各実施の形態の説明に用いた各機能ブロック、並びにフローチャートにおける各ステップ及びシーケンスチャートにおける各処理は、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部又はすべてを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。
本開示技術は、SCSと通信を開始する前に、UEのIPアドレスを制御メッセージであるトリガ応答に含めてSCSへ通知することができるという効果を有しており、セルラー通信機能を利用した通信技術(特に、M2M通信の技術)に適用可能である。

Claims (7)

  1. ネットワークを介して、所定の通信装置と通信を行う通信端末であって、
    前記所定の通信装置から送信され、制御メッセージを前記通信端末へ送信することを要求するトリガ要求メッセージに基づいて生成された前記制御メッセージを前記ネットワークから受信する制御メッセージ受信部と、
    前記所定の通信装置とIPパケットを使って前記通信をするか否かを判断する判断部と、
    前記制御メッセージ受信部で前記制御メッセージを受信したとき、IPパケットを使って前記通信をすると判断した場合に、前記所定の通信装置との前記通信に使用するIPコネクションに割り当てられているIPアドレスを取得するコネクション管理部と、
    前記制御メッセージに対する応答メッセージであって、前記コネクション管理部が取得した前記IPアドレスを含む応答メッセージを前記ネットワークに送信する応答メッセージ送信部とを、
    し、
    前記応答メッセージ送信部は、
    前記制御メッセージの中にアプリケーションデータが含まれていない場合に、IPパケットを使って前記通信をすると判断する通信端末。
  2. 前記コネクション管理部は、
    前記IPアドレスを取得する際、前記IPコネクションが確立されていない場合に新たにIPコネクションを確立する請求項1に記載の通信端末。
  3. 前記応答メッセージ送信部は、
    前記IPアドレスを、前記応答メッセージの中のアプリケーション情報を入れるためのフィールドに挿入する請求項1に記載の通信端末。
  4. 前記応答メッセージ送信部は、
    前記所定の通信装置へ送信すべきアプリケーションデータを前記通信端末が有する場合に、IPパケットを使って前記通信をすると判断する請求項1に記載の通信端末。
  5. 通信端末とアプリケーションサーバとの通信を仲介するサーバであって、
    前記アプリケーションサーバからデータを取得した際、制御メッセージを前記通信端末へ送信することを要求するトリガ要求をネットワークノードへ送信するトリガ要求送信部と、
    前記トリガ要求に基づいて前記ネットワークノードから前記通信端末へ送信された前記制御メッセージに対する応答メッセージであって、前記通信端末のIPアドレスを含む応答メッセージを受信した前記ネットワークノードから前記IPアドレスを含むレポートメッセージを受信し、前記レポートメッセージの中に含まれる前記通信端末のIPアドレスを取得するレポート受信部と、
    前記IPアドレスと前記通信端末の識別情報を関連付けて保持する通信端末情報保持部とを、
    有するサーバ。
  6. 前記IPアドレスは、前記レポートメッセージのアプリケーション情報を入れるためのフィールドに挿入されている請求項に記載のサーバ。
  7. 受信したIPパケットの送信元アドレスが、前記通信端末情報保持部に保持されているIPアドレスと一致する場合に、前記IPパケットに含まれているペイロードを前記アプリケーションサーバへ通知するIPパケット受信部を更に有する請求項に記載のサーバ。
JP2013557681A 2012-07-02 2013-04-23 サーバ及び通信端末 Expired - Fee Related JP6138058B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2012148619 2012-07-02
JP2012148619 2012-07-02
PCT/JP2013/002741 WO2014006803A1 (ja) 2012-07-02 2013-04-23 サーバ及び通信端末

Publications (2)

Publication Number Publication Date
JPWO2014006803A1 JPWO2014006803A1 (ja) 2016-06-02
JP6138058B2 true JP6138058B2 (ja) 2017-05-31

Family

ID=49881581

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013557681A Expired - Fee Related JP6138058B2 (ja) 2012-07-02 2013-04-23 サーバ及び通信端末

Country Status (3)

Country Link
US (1) US9439073B2 (ja)
JP (1) JP6138058B2 (ja)
WO (1) WO2014006803A1 (ja)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9036603B2 (en) 2012-08-03 2015-05-19 Intel Corporation Network assistance for device-to-device discovery
US8913518B2 (en) 2012-08-03 2014-12-16 Intel Corporation Enhanced node B, user equipment and methods for discontinuous reception in inter-ENB carrier aggregation
US9526022B2 (en) 2012-08-03 2016-12-20 Intel Corporation Establishing operating system and application-based routing policies in multi-mode user equipment
US9191828B2 (en) 2012-08-03 2015-11-17 Intel Corporation High efficiency distributed device-to-device (D2D) channel access
WO2014022797A1 (en) * 2012-08-03 2014-02-06 Intel Corporation Device trigger recall/replace feature for 3gpp/m2m systems
JP6241420B2 (ja) 2012-12-21 2017-12-06 日本電気株式会社 システム、scsエンティティ、及びユニット
JP6337890B2 (ja) * 2013-05-15 2018-06-06 日本電気株式会社 制御装置、通信システム、通信装置、通信方法及びプログラム
US9693205B2 (en) 2014-07-03 2017-06-27 Cisco Technology, Inc. System and method for providing message delivery and paging to a group of users in a network environment
US9516640B2 (en) 2014-08-01 2016-12-06 Cisco Technology, Inc. System and method for a media access control scheduler for a long term evolution unlicensed network environment
US9949117B2 (en) * 2014-08-29 2018-04-17 At&T Intellectual Property I, L.P. Method and apparatus for managing access to a wireless communication network
US10462699B2 (en) 2014-09-08 2019-10-29 Cisco Technology, Inc. System and method for internet protocol version-based multiple access point name support in a network environment
US9717068B2 (en) 2014-09-09 2017-07-25 Cisco Technology, Inc. System and method for supporting cell updates within a small cell cluster for idle mobility in cell paging channel mode
US9917927B2 (en) * 2014-09-09 2018-03-13 Telefonaktiebolaget L M Ericsson (Publ) Simplified notification of network triggered reporting—first core network node (e.g., GGSN) and method
US9730156B1 (en) 2014-11-07 2017-08-08 Cisco Technology, Inc. System and method for providing power saving mode enhancements in a network environment
US9699725B1 (en) 2014-11-07 2017-07-04 Cisco Technology, Inc. System and method for providing power saving mode enhancements in a network environment
US9843687B2 (en) 2014-11-09 2017-12-12 Cisco Technology, Inc. System and method for radio aware traffic management based wireless authorization
CN105794258B (zh) * 2014-11-10 2019-07-09 华为技术有限公司 拥塞通知方法、相关设备和***
US9629042B2 (en) 2014-12-05 2017-04-18 Cisco Technology, Inc. System and method for providing collaborative neighbor management in a network environment
US9686798B1 (en) 2015-01-14 2017-06-20 Cisco Technology, Inc. System and method for providing collision-avoided physical downlink control channel resource allocation in a network environment
US9621362B2 (en) 2015-02-03 2017-04-11 Cisco Technology, Inc. System and method for providing policy charging and rules function discovery in a network environment
US10313143B1 (en) 2015-02-23 2019-06-04 Sprint Communications Company L.P. Wireless communication system to provide buffering in a single frequency network
EP3352498B1 (en) * 2015-09-16 2021-06-02 LG Electronics Inc. Bearer setting method and device supporting same for transmitting/receiving data in wireless communication system
CN109155913B (zh) * 2016-06-01 2021-05-18 华为技术有限公司 网络连接方法、安全节点的确定方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1085734A3 (en) * 1999-09-09 2002-11-27 Han, Tae Hee Internet telephony system and method using public telephone network terminal adapters
US7170896B2 (en) 2001-06-20 2007-01-30 Motorola, Inc. Communication infrastructure and method to preserve communication link bandwidth in a packet communication session
US7492753B2 (en) * 2003-02-21 2009-02-17 Motorola, Inc. Method for performing transactions in a wireless local area network
JP2006014188A (ja) * 2004-06-29 2006-01-12 Canon Inc サーバシステム、サーバおよび記憶媒体
US20090262682A1 (en) * 2008-04-18 2009-10-22 Amit Khetawat Method and Apparatus for Transport of RANAP Messages over the Iuh Interface in a Home Node B System
CN101924751B (zh) * 2009-05-22 2013-11-06 中兴通讯股份有限公司 一种单模业务连续性实现方法及单模业务连续性***
WO2011087826A1 (en) * 2009-12-22 2011-07-21 Interdigital Patent Holdings, Inc. Group-based machine to machine communication
US9807602B2 (en) * 2010-04-07 2017-10-31 Qualcomm Incorporated Apparatus and method for connection establishment in a communications network
US8477785B2 (en) * 2010-07-09 2013-07-02 Stoke, Inc. Method and system for interworking a WLAN into a WWAN for session and mobility management
WO2012033774A2 (en) * 2010-09-07 2012-03-15 Interdigital Patent Holdings, Inc. Bandwidth management, aggregation and internet protocol flow mobility across multiple-access technologies
US20130089076A1 (en) * 2011-04-01 2013-04-11 Interdigital Patent Holdings, Inc. Local / remote ip traffic access and selective ip traffic offload service continuity
EP2695474B1 (en) * 2011-04-01 2015-02-18 InterDigital Patent Holdings, Inc. System and method for sharing a common pdp context

Also Published As

Publication number Publication date
US20140177583A1 (en) 2014-06-26
JPWO2014006803A1 (ja) 2016-06-02
US9439073B2 (en) 2016-09-06
WO2014006803A1 (ja) 2014-01-09

Similar Documents

Publication Publication Date Title
JP6138058B2 (ja) サーバ及び通信端末
US11606734B2 (en) Handover method in wireless communication system and apparatus therefor
US10972956B2 (en) Enhanced handling on QoS flow description
CN110431859B (zh) 用于无线通信***中层之间交互的方法及其设备
US10362511B2 (en) Method and apparatus for determining PDU session identity in wireless communication system
US10652085B2 (en) Method for setting configuration of non-IP data delivery (NDID) in wireless communication system and device for same
JP7287431B2 (ja) ユーザ装置、通信装置、及び通信方法
CN108370506B (zh) 无线通信***中的服务节点重新定位方法及其设备
US20200015311A1 (en) Method for processing nas message in wireless communication system and apparatus for same
US10219143B2 (en) Data transmission method, mobility management entity, and mobile terminal
JP6211081B2 (ja) 二重優先度アクセスのための無線リソース管理
US9648515B2 (en) Device triggering and APN-based congestion control
CN106464602B (zh) 使用at命令获取mtu大小的方法以及终端设备
KR102048046B1 (ko) 무선 통신 시스템에서 ladn 이용 방법 및 이를 위한 장치
WO2017172912A1 (en) Method and apparatus for clot device data transfer
US10623990B2 (en) User equipment and method for transmitting data, and network node and method for receiving data
WO2013113186A1 (zh) 一种mtc用户设备触发信息的发送方法、***和用户设备
WO2018137152A1 (zh) 短消息传输方法、设备和***
US20180077578A1 (en) Apparatus, system and method for mobile communication
JP2013239837A (ja) ネットワークノード及びサーバ
WO2023015973A1 (zh) 一种网络切片准入控制方法和装置
WO2013114492A1 (ja) 通信端末及びネットワークノード
JP2013219524A (ja) ネットワークノード及び通信端末

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160830

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161130

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: 20170404

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170425

R150 Certificate of patent or registration of utility model

Ref document number: 6138058

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees