特許 7444153 第１の装置による方法及びＰＣＲＦ装置による方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-27

(45)【発行日】2024-03-06

(54)【発明の名称】第１の装置による方法及びＰＣＲＦ装置による方法

(51)【国際特許分類】

   H04W 28/24 20090101AFI20240228BHJP

   H04W 4/24 20240101ALI20240228BHJP

   H04W 72/0457 20230101ALI20240228BHJP

   H04W 88/18 20090101ALI20240228BHJP

   H04L 47/2425 20220101ALI20240228BHJP

   H04W 4/70 20180101ALN20240228BHJP

【ＦＩ】

H04W28/24

H04W4/24

H04W72/0457

H04W88/18

H04L47/2425

H04W4/70

【請求項の数】 6

(21)【出願番号】P 2021181256

(22)【出願日】2021-11-05

(62)【分割の表示】P 2020053958の分割

【原出願日】2014-12-04

(65)【公開番号】P2022028745

(43)【公開日】2022-02-16

【審査請求日】2021-11-05

(31)【優先権主張番号】P 2014002755

(32)【優先日】2014-01-09

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】岩井 孝法

【審査官】伊藤 嘉彦

(56)【参考文献】

【文献】国際公開第２０１５／１０４７５１（ＷＯ，Ａ１）

【文献】国際公開第２０１３／１６１２３３（ＷＯ，Ａ１）

【文献】米国特許出願公開第２００９／０２３８２０７（ＵＳ，Ａ１）

【文献】欧州特許出願公開第０２３８５７２１（ＥＰ，Ａ１）

【文献】国際公開第２０１３／１６１２７５（ＷＯ，Ａ１）

【文献】国際公開第２０１３／０２５５３４（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ４７／２４２５

Ｈ０４Ｗ ４／００ － ９９／００

Ｈ０４Ｂ ７／２４ － ７／２６

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

第１の装置による方法であって、
コアネットワークの外部に配置され且つ前記コアネットワークと相互作用してサービスを提供する第２の装置から、バックグラウンドデータ転送のための第１の要求を受信し、
前記バックグラウンドデータ転送のための課金情報が対応する前記バックグラウンドデータ転送の最大ビットレートを前記コアネットワークにおけるＰｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ（ＰＣＲＦ）装置が生成するよう、前記バックグラウンドデータ転送のための第２の要求を、前記第１の要求に基づいて前記ＰＣＲＦ装置へ送信する、
方法。

【請求項2】

前記第１の要求は、アプリケーションのプロバイダを識別する情報を含む、請求項１に記載の方法。

【請求項3】

前記第２の要求は、前記第１の要求に含まれるパラメータを含む、請求項１または２に記載の方法。

【請求項4】

コアネットワークにおけるＰｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ（ＰＣＲＦ）装置による方法であって、
第１の装置によって送信されたバックグラウンドデータ転送のための第２の要求を受信し、
前記第２の要求は、前記コアネットワークの外部に配置され且つ前記コアネットワークと相互作用してサービスを提供する第２の装置から送信された、前記バックグラウンドデータ転送のための第１の要求に基づいて前記第１の装置によって送信され、
前記第２の要求における情報に基づいて、前記バックグラウンドデータ転送のための課金情報が対応する前記バックグラウンドデータ転送の最大ビットレートを生成する、
方法。

【請求項5】

前記第１の要求は、アプリケーションのプロバイダを識別する情報を含む、請求項４に記載の方法。

【請求項6】

前記第２の要求は、前記第１の要求に含まれるパラメータを含む、請求項４または５に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、無線通信システムにおけるサービス品質の制御に関する。

【背景技術】

【0002】

Third Generation Partnership Project（3GPP）は、Machine Type Communication（MTC）の標準化を検討している。MTCは、Machine-to-Machine（M2M）ネットワーク又はセンサネットワークとも呼ばれる。3GPPは、MTCのために機械及びセンサに実装される移動局（MS, UE）を“MTCデバイス”と定義している。MTCデバイスは、機械（e.g.自動販売機、ガスメータ、電気メータ、自動車、鉄道車両）及びセンサ（e.g.環境、農業、交通等に関するセンサ）等の様々な機器に搭載される。MTCデバイスは、Public Land Mobile Network（PLMN）に接続し、MTCアプリケーションサーバ（Application Server（AS））と通信を行う。MTC アプリケーションサーバは、PLMNの外部（外部ネットワーク）に配置され、MTCアプリケーションを実行し、MTCデバイスに実装されたMTC UEアプリケーションと通信する。MTC アプリケーションサーバは、一般的に、MTCサービスプロバイダ（M2Mサービスプロバイダ）によって制御される。

【0003】

3GPPは、MTC アプリケーションサーバがMTCデバイスと通信できるようにするために、Service Capability Server （SCS）及びMachine Type Communication Inter Working Function （MTC-IWF）を含むネットワークエレメント、参照点（reference point）、及び手順（procedure）を規定している（非特許文献１を参照）。なお、参照点（reference point）は、インタフェースとも呼ばれる。

【0004】

SCSは、MTCアプリケーションサーバを3GPPのPLMNに接続し、3GPPで定義されたPLMNサービスを介してMTCアプリケーションサーバがUE（つまり、MTCデバイス）と通信できるようにするエンティティである。また、SCSは、MTCアプリケーションサーバがMTC-IWFと通信できるようにする。SCSは、PLMNのオペレータ、又はMTCサービスプロバイダによって制御されることが想定されている。

【0005】

MTC-IWFは、PLMNに属するコントロールプレーンのエンティティである。MTC-IWFは、SCSとのシグナリング・インタフェース（参照点）を有するとともに、PLMN内のノード（例えば、Home Subscriber Server（HSS）、Short Message Service - Service Center（SMS-SC）、Serving GPRS Support Node （SGSN）、Mobility Management Entity（MME）、Mobile Switching Center（MSC））とのシグナリング・インタフェース（参照点）を有する。MTC-IWFは、SCSを含むM2Mサービスレイヤと3GPP PLMNとが、3GPP PLMN のトポロジの詳細を隠蔽しながら協調動作（interwork）するためのコントロールプレーンのインタフェースとして振る舞う。

【0006】

また、非特許文献２は、セクション7.4.2において、PCRF initiated IP-CAN Session Modification手順を開示している。一例において、Policy and Charging Rule Function（PCRF）は、Traffic Detection Function（TDF）によるアプリケーション・トラフィック（e.g. streaming video service、VoIP service、P2P file sharing service、specific HTTP traffic）の検出をトリガーとして、IP-CAN Session Modification手順を開始する。他の例において、PCRFは、Application Function（AF）によって供給された（provided）又は取り消された（revoked）サービス情報（例えば、優先度レベルの変更）に応答して、IP-CAN Session Modification手順を開始する。非特許文献３は、セクション4.3.1において、非特許文献２と同様のIP-CAN Session Modification手順を開示している。

【先行技術文献】

【非特許文献】

【0007】

【文献】3GPP TS 23.682 V11.5.0 (2013-09) “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release 11)”, 2013年9月

【文献】3GPP TS 23.203 V11.11.0 (2013-09) “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 11)”, 2013年9月

【文献】3GPP TS 29.213 V11.8.0 (2013-09) “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control signalling flows and Quality of Service (QoS) parameter mapping (Release 11)”, 2013年9月

【発明の概要】

【発明が解決しようとする課題】

【0008】

本件の発明者は、MTCアプリケーションの様々なユースケースについて検討した。例えば、Public Land Mobile Network（PLMN）は、MTC アプリケーションサーバからの要求に従って、UE（MTCデバイス）の特定の通信（サービスデータフロー）のサービス品質、例えばQoSポリシー（e.g. QoS Class Identifier (QCI)、Allocation and Retention Priority (ARP)、Maximum Bit Rate (MBR)、Guaranteed Bit Rate (GBR)）、を動的に調整することが考えられる。このユースケースを実現するためには、例えば、MTC-IWFは、SCSからサービス品質の要求を受信したことに応答して、特定の通信のサービス品質の制御（QoS制御）をPLMN内のネットワークエレメントに対して要求できることが望ましいかもしれない。しかしながら、非特許文献１～３は、このような制御動作又は制御手順を想定していない。

【0009】

したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、SCSからのサービス品質の要求に応答して特定の通信のサービス品質の制御をPLMN内において行うことを容易にするためのMTC-IWFエンティティ、PCRFエンティティ、制御方法、及びプログラムを提供することである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

【課題を解決するための手段】

【0010】

一実施形態では、MTC-IWFエンティティは制御部を含む。前記制御部は、MTCデバイスの特定通信に適用されるサービス品質の第１の要求をSCSから受信したことに応答して、前記サービス品質を前記特定通信に適用するための第２の要求をPCRFエンティティに送信するよう構成されている。

【0011】

一実施形態では、MTC-IWFエンティティにより行われる方法は、MTCデバイスの特定通信に適用されるサービス品質の第１の要求SCSから受信したことに応答して、前記サービス品質を前記特定通信に適用するための第２の要求をPCRFエンティティに送信することを含む。

【0012】

一実施形態では、プログラムは、直前の段落に記載されたMTC-IWFエンティティにより行われる方法をコンピュータに行わせるための命令群を含む。

【0013】

一実施形態では、PCRFエンティティは制御部を含む。前記制御部は、MTCデバイスの特定通信に適用されるサービス品質の要求をMTC-IWFエンティティから受信したことに応答して、前記サービス品質を前記特定通信に適用するための制御を行うよう構成されている。

【0014】

一実施形態では、PCRFエンティティにより行われる方法は、MTCデバイスの特定通信に適用されるサービス品質の要求をMTC-IWFエンティティから受信したことに応答して、前記サービス品質を前記特定通信に適用するための制御を行うことを含む。

【0015】

一実施形態では、プログラムは、直前の段落に記載されたPCRFエンティティにより行われる方法をコンピュータに行わせるための命令群を含む。

【0016】

一実施形態では、PCRFエンティティは、制御部を含む。前記制御部は、設定済みのベアラを経由して移動局により送信又は受信されるユーザトラフィックの中から特定パケットフローが検出されたことに応答して、前記特定パケットフローに適用される第１のPolicy and Charging Control（PCC）ルールをPolicy and Charging Enforcement Function（PCEF）を有するPCRFノードに供給するよう構成されている。一例において、前記移動局は、MTCデバイスであってもよい。この場合、前記制御部は、前記MTCデバイスの特定通信に適用されるサービス品質の要求をMTC-IWFエンティティから受信したことに応答して、前記第１のPCCルールを前記PCEFノードに供給してもよい。

【0017】

一実施形態では、PCRFエンティティにより行われる方法は、設定済みのベアラを経由して移動局により送信又は受信されるユーザトラフィックの中から特定パケットフローが検出されたことに応答して、前記特定パケットフローに適用される第１のPolicy and Charging Control（PCC）ルールをPolicy and Charging Enforcement Function（PCEF）を有するPCRFノードに供給することを含む。一例において、前記移動局は、MTCデバイスであってもよい。この場合、前記供給することは、前記MTCデバイスの特定通信に適用されるサービス品質の要求をMachine Type Communication Inter Working Function（MTC-IWF）エンティティから受信したことに応答して、前記第１のPCCルールを前記PCEFノードに供給することを含んでもよい。

【0018】

一実施形態では、プログラムは、直前の段落に記載されたPCRFエンティティにより行われる方法をコンピュータに行わせるための命令群を含む。

【発明の効果】

【0019】

上述の実施形態によれば、SCSからのサービス品質の要求に応答して特定の通信のサービス品質の制御をPLMN内において行うことを容易にするためのMTC-IWFエンティティ、PCRFエンティティ、制御方法、及びプログラムを提供することができる。

【図面の簡単な説明】

【0020】

【図1】第１及び第２の実施形態に係る無線通信システムを示す図である。

【図2】第１の実施形態に係るサービス品質の制御の一例を示すシーケンス図である。

【図3】第２の実施形態に係るサービス品質の制御の一例を示すシーケンス図である。

【図4】第２の実施形態に係るいくつかのエンティティ又はノードの構成例を示すブロック図である。

【図5】その他の実施形態２に係る無線通信システムを示す図である。

【図6】その他の実施形態２に係る動作の一例を示すシーケンス図である。

【発明を実施するための形態】

【0021】

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

【0022】

＜第１の実施形態＞
図１は、本実施形態に係る無線通信システムの構成例を示す図である。本実施形態に係る無線通信システムは、例えば、3GPPのEvolved Packet System（EPS）である。EPSは、Long Term Evolution（LTE）システムとも呼ばれる。以下では、本実施形態に係る無線通信システムがEPSである場合を例にとって説明する。しかしながら、本実施形態は、Universal Mobile Telecommunications System（UMTS）等の他の無線通信システムにも適用できる。

【0023】

UE３は、MTC UEアプリケーション３１を実行し、MTCデバイスとして振る舞う。MTCデバイスとしてのUE３は、Radio Access Network（RAN）５４を介してMME５３に接続するとともに、MTCアプリケーションサーバ４と通信する。RAN５４は、Evolved UMTS Terrestrial Radio Access Network（E-UTRAN）を含む。

【0024】

UE３は、MTCゲートウェイ・デバイスであってもよい。MTCゲートウェイ・デバイスは、3GPP移動通信機能（つまり、UEの機能）を有するとともに、パーソナル／ローカルエリア接続技術によって近隣のデバイス（例えば、センサ、radio frequency identification （RFID）タグ、カーナビゲーション装置）と接続する。パーソナル／ローカルエリア接続技術の具体例は、IEEE 802.15、ZigBee（登録商標）、Bluetooth（登録商標）、IEEE 802.11aを含む。なお、MTCゲートウェイ・デバイスに接続する近隣のデバイスは、典型的には3GPP移動通信機能を有していないデバイスであるが、3GPP移動通信機能を有するデバイス（つまり、MTCデバイス）であってもよい。

【0025】

なお、本明細書では、MTCデバイスの用語とMTCゲートウェイ・デバイスの用語を特に区別せずに使用する。つまり、本明細書において用いられるMTCデバイスの用語は、MTCゲートウェイ・デバイスを包含する。したがって、MTCデバイスとしてのUE３は、MTCゲートウェイ・デバイスとしてのUE３も意味する。

【0026】

MTC Inter Working Function （MTC-IWF）エンティティ１は、PLMNに属するコントロールプレーンのエンティティである。MTC-IWFエンティティ１は、シグナリング・インタフェース（参照点）を介して他のネットワーク要素と通信する。MTC-IWFエンティティ１は、SCS２を含むM2Mサービスレイヤと3GPP PLMNとが、3GPP PLMN のトポロジの詳細を隠蔽しながら協調動作（interwork）するためのコントロールプレーンのインタフェース又はゲートウェイとして振る舞う。以下では、MTC-IWFエンティティ１のシグナリング・インタフェース（参照点）及び他のネットワーク要素について説明する。

【0027】

MTC-IWFエンティティ１は、Tsp参照点を介してService Capability Server （SCS）２と通信する。SCS２は、MTCアプリケーションサーバ４をPLMNに接続し、3GPPで定義されたPLMNサービスを介してMTCアプリケーションサーバ４がUE３（つまり、MTCデバイス）と通信できるようにする。MTCアプリケーションサーバ４は、M2Mアプリケーションサーバとも呼ばれる。また、SCS２は、MTCアプリケーションサーバ４がMTC-IWFエンティティ１と通信できるようにする。SCS２は、PLMNのオペレータ、又はMTCサービスプロバイダによって制御される。SCS２は、MTCサーバ又はM2Mサーバとも呼ばれる。SCS２は、単体の独立した物理的なエンティティであってもよいし、他のネットワーク要素（例えば、MTCアプリケーションサーバ４）に付加された機能的なエンティティであってもよい。Tsp参照点は、例えば、SCS２からMTC-IWFエンティティ１へのデバイストリガーの送信要求（Device Trigger Request（DTR））の送信、MTC-IWFエンティティ１からSCS２へのデバイストリガー結果の報告のために用いられる。

【0028】

MTC-IWFエンティティ１は、S6m参照点を介してHome Subscriber Server（HSS）５１と通信する。HSS５１は、PLMNのコアネットワーク（i.e. EPSでのEvolved Packet Core（EPC））に配置されたコントロールプレーンのノードであり、UE３の加入者情報を管理する。S6m参照点は、例えば、MTC-IWFエンティティ１からHSS５１への加入者情報の問い合わせの送信、及びHSS５１からMTC-IWFエンティティ１への加入者情報の送信のために用いられる。

【0029】

MTC-IWFエンティティ１は、T5b参照点を介してMobility Management Entity（MME）５３と通信する。MME５３は、EPSのコアネットワークノードであり、UE３のモビリティ管理（e.g. 位置登録）、及びベアラ管理（e.g. ベアラ確立、ベアラ構成変更、ベアラ解放）などを行う。MME５３は、RAN５４内のノード（i.e. eNodeB）との間で制御メッセージを送受信し、UE３との間でNASメッセージを送受信する。NASメッセージは、RAN５４で終端されず、RANの無線アクセス方式に依存することなく、UE３とMME５３の間で透過的に送受信される。

【0030】

以上に述べたTsp、S6m、及びT5b参照点は、非特許文献１に規定されている。しかしながら、非特許文献１は、MTC-IWFエンティティ１とPCRFエンティティ５の間の参照点、及びMTC-IWFエンティティ１とDiameter Routing Agent（DRA）５２の間の参照点を規定していない。

【0031】

Policy and Charging Rules Function（PCRF）エンティティ５は、EPSのコアネットワーク（i.e. EPC）に配置される制御エンティティである。PCRFエンティティ５は、UE３のサービスデータフローに適用されるべきPolicy and Charging Control（PCC）ルールを決定し、Policy and Charging Enforcement Function（PCEF）を有するP-GW５６に決定されたPCCルールを送信する。PCCルールは、UE３のサービスデータフローに適用されるべきQoSポリシー、課金ルール、及びサービスデータフローを検出するためのサービスデータフロー（SDF）テンプレートを含む。さらに、PCRFエンティティ５は、Application Detection and Control（ADC）ルールをTraffic Detection Function（TDF）エンティティ５７を供給する。ADCルールは、UE３によって送信又は受信されるユーザーデータ・トラフィックの中から特定のアプリケーション・トラフィック（e.g. streaming video service、VoIP service、P2P file sharing service、specific HTTP traffic）を検出するためにTDFエンティティ５７において使用される。ADCルールは、アプリケーション・トラフィックを特定するために必要なOSI参照モデルのレイヤ４－７の識別情報を含む。

【0032】

PCRFエンティティ５は、P-GW５６に配置されたPolicy and Charging Enforcement Function（PCEF）との間にシグナリング・インタフェース（i.e. Gx参照点）を有する。PCRFエンティティ５は、Traffic Detection Function（TDF）エンティティ５７との間にシグナリング・インタフェース（i.e. Sd参照点）を有する。また、PCRFエンティティ５は、S-GW５５に配置されたBearer Binding and Event Reporting Function（BBERF）との間にシグナリング・インタフェース（i.e. Gxc参照点）を有してもよい。

【0033】

さらに、PCRFエンティティ５は、MTC-IWFエンティティ１との間にシグナリング・インタフェース１１を有する。シグナリング・インタフェース１１は、Rx参照点であってもよい。Rx参照点は、PCRF とApplication Function（AF）の間のインタフェースである。この場合、PCRFエンティティ５は、アプリケーション・レベルのサービス情報をMTC-IWFエンティティ１から受信し、PCCルールを決定し、PCCルールをP-GW５６に供給してもよい。

【0034】

Diameter Routing Agent（DRA）５２は、EPSのコアネットワーク（EPC）に配置される制御エンティティである。DRA５２は、コアネットワーク（EPC）内に複数のPCRFエンティティを配置することを可能とする。すなわち、DRA５２は、PLMNを利用する加入者（UE３）とその加入者のIP-CANセッションに対するQoS制御及び課金制御を行うPCRFエンティティを対応付ける。DRAの機能の詳細は、3GPP TS 29.213及びIETF RFC 3588に示されている。

【0035】

DRA５２は、Redirect DRAとして実装されてもよいし、Proxy DRAとして実装されてもよい。DRA５２がRedirect DRAとして実装された場合、DRA５２は、クライアント（e.g. Application Function（AF）、BBERFとしてのS-GW５５、PCEFとしてのP-GW５６、及びMTC-IWFエンティティ１）からDiameter requestメッセージを受信したことに応答して、Diameter Attribute-value pair （Diameter AVP）を返信する。DRA５２にから返信されるDiameter AVP（つまり、Redirect-Host-Usage AVP）は、クライアントがDiameter requestメッセージを送信するべきPCRFエンティティを示す。DRA５２がProxy DRAとして実装された場合、DRA５２は、クライアント（e.g. Application Function（AF）、BBERFとしてのS-GW５５、PCEFとしてのP-GW５６、及びMTC-IWFエンティティ１）からDiameter requestメッセージを受信したことに応答して、そのDiameter requestメッセージを適切なPCRFエンティティに転送する。

【0036】

なお、PLMN内に配置されるPCRFエンティティが１つのみである場合、又はMTC-IWFエンティティ１がMTCデバイスとしてのUE３のIP-CANセッションを管理するPCRFエンティティ５を予め知っている場合などには、MTC-IWFエンティティ１とDRA５２の間のシグナリング・インタフェース１２は省略されてもよい。言い換えると、MTC-IWFエンティティ１は、DRA５２とのシグナリングを行わなくてもよい。

【0037】

Serving Gateway（S-GW）５５は、EPSのコアネットワークに配置されるユーザープレーンのパケット転送ノードであり、UE３のユーザーデータパケットを転送する。S-GW５５は、RAN５４とのゲートウェイの役割を担う。S-GW５５は、RAN５４（i.e. E-UTRAN）との間にユーザープレーンのトンネリング・インタフェース（i.e. S1-U参照点）を有し、P-GW５６との間にユーザープレーンのトンネリング・インタフェース（i.e. S5/S8参照点）を有する。S-GW５５は、MME５３との間にシグナリング・インタフェース（i.e. S11参照点）を有する。

【0038】

さらに、S-GW５５は、Bearer Binding and Event Reporting Function（BBERF）を有してもよい。BBERFとしてのS-GW５５は、PCRFエンティティ５からQoSルールを受信し、QoSルールに基づいて制御されるべきUE３のサービスデータフロー（つまり、IPパケットフロー）を検出し、検出されたサービスデータフローをQoSルールに対応した適切なIP-CANベアラ（EPSベアラ）に対応づける。さらに、BBERFとしてのS-GW５５は、PCRFエンティティ５によってインストールされたイベントトリガーに基づいて、PCRFエンティティ５にイベントを報告する。

【0039】

Packet Data Network Gateway（P-GW）５６は、EPSのコアネットワーク（EPC）に配置されるユーザープレーンのパケット転送ノードであり、UE３のユーザーデータパケットを転送する。P-GW５６は、外部Packet Data Network（PDN）とのゲートウェイの役割を担い、UE３に外部PDNとのコネクティビティを提供する。外部PDNは、例えばSCS２及びMTCアプリケーションサーバ４を含む。さらに、P-GW５６は、Charging Trigger Function (CTF)、Charging Data Function (CDF)、及びPolicy and Charging Enforcement Function（PCEF）を有する。PCEFとしてのP-GW５６は、PCRFエンティティ５から供給されたPolicy and Charging Control（PCC）ルールに従って、UE３のサービスデータフロー（つまり、IPパケットフロー）単位でのQuality of Service（QoS）制御およびフローベースのベアラ課金（Flow Based bearer Charging（FBC））を行う。FBCは、P-GW５６が有するCTF、CDF、及びPCEFによって実現される。

【0040】

つまり、P-GW５６は、SDFテンプレート又はTraffic Flow Template（TFT）を用いてUE３によって送信又は受信される複数のサービスデータフローを区別するともに、各サービスデータフローを各サービスデータフローのQoSに対応したEPSベアラ（IP Connectivity Access Network（IP-CAN）ベアラ）にマッピングする。さらに、P-GW５６は、Charging Data Record（CDR）の生成及びクローズをトリガーする課金対象イベント（chargeable event）としてサービスデータフローを監視し、サービスデータフローのパケット数をカウントし、サービスデータフローに関する課金情報を含むCDRを生成する。なお、課金対象イベントは、通信ネットワークのリソース又はサービスを利用するアクテビティを意味する。課金対象イベントは、例えば、user to user communication (e.g. a single call, a data communication session or a short message)、user to network communication (e.g. service profile administration)、inter-network communication (e.g. transferring calls, signaling, or short messages)、又はmobility (e.g. roaming or inter-system handover) である。CDRは、フォーマットされた課金情報（e.g. 通話時間、データ転送量など）を意味する。

【0041】

Traffic Detection Function（TDF）エンティティ５７は、deep packet inspection（DPI）機能を有する。TDFエンティティ５７は、Sd参照点を介してPCRFエンティティ５からApplication Detection and Control（ADC）ルールを受信し、ADCルールに従ってユーザパケットに対するディープパケットインスペクションを実行し、ADCルールによって指定されたアプリケーション・トラフィック（e.g. streaming video service、VoIP service、P2P file sharing service、specific HTTP traffic）を検出する。そして、TDFエンティティ５７は、Sd参照点を介して、アプリケーション・トラフィックの検出結果をPCRFエンティティ５に報告する。TDFエンティティ５７の機能は、PCEFと一緒に配置（collocate）されてもよい。言い換えると、TDFエンティティ５７は、P-GW５６に配置されてもよい。さらに言い換えると、P-GW５６は、PCEF enhanced with ADCを有してもよい。

【0042】

続いて以下では、UE３の特定通信のサービス品質の制御について説明する。図１の例では、MTC-IWFエンティティ１は、PCRFエンティティ５との間にシグナリング・インタフェース（参照点）１１を有する。MTC-IWFエンティティ１は、Tsp参照点を介してSCS２から第１のQoS要求を受信したことに応答して、シグナリング・インタフェース１１を介してPCRFエンティティ５に第２のQoS要求を送信する。

【0043】

SCS２からMTC-IWFエンティティ１に送られる第１のQoS要求は、MTCデバイスとしてのUE３の特定通信に適用されるサービス品質を要求する。UE３の特定通信は、特定の通信相手との通信、特定プロトコルの通信、又は特定アプリケーションのトラフィックであってもよい。言い換えると、UE３の特定通信は、OSI参照モデルのレイヤ３－７のいずれかの識別情報又はこれらの組み合わせによって特定されてもよい。

【0044】

第１のQoS要求は、サービス品質を指定するために、QoS Class Identifier (QCI)、Allocation and Retention Priority (ARP)、Maximum Bit Rate (MBR) 、Guaranteed Bit Rate (GBR)、及び優先度レベル（e.g. high priority、medium priority、low priorityなど）のうち少なくとも１つを示してもよい。また、第１のQoS要求は、UE３の特定通信を指定するために、アプリケーション名（e.g. YouTube（登録商標）、Skype（登録商標））を含んでもよい。また、第１のQoS要求は、UE３の特定通信のパケットフローを特定するための送信元アドレス、宛先アドレス、ポート番号、及びプロトコル識別子のうち少なくとも１つを含んでもよい。さらにまた、第１のQoS要求は、特定通信の利用用途（e.g. background通信、ソフトウェアの自動アップデート、自動検針（automatic meter reading））を示してもよい。

【0045】

第１のQoS要求は、対象のUE３を指定するために、UE３に関連付けられた外部識別子（External ID）を含んでもよい。外部識別子は、SCS２及びMTCアプリケーションサーバ４を含むPLMNの外部においてUE３を識別するために使用される。外部識別子は、例えば、Mobile Subscriber ISDN Number（MSISDN）であってもよい。

【0046】

第１のQoS要求は、送信元のSCS２を示すために、SCS２の識別子を含んでもよい。また、SCS２から送られる複数の第１のQoS要求を区別するために、第１のQoS要求は、トランザクション識別子（e.g. シーケンス番号）を含んでもよい。

【0047】

一方、MTC-IWFエンティティ１からPCRFエンティティ５に送られる第２のQoS要求は、サービス品質を指定するために、第１のQoSと同様の情報を示してもよい。すなわち、第２のQoS要求は、QCI、ARP、MBR、GBR、及び優先度レベルのうち少なくとも１つを示してもよい。また、第２のQoS要求は、UE３の特定通信のパケットフローを特定するための送信元アドレス、宛先アドレス、ポート番号、及びプロトコル識別子のうち少なくとも１つを含んでもよい。さらにまた、第２のQoS要求は、特定通信の利用用途を示してもよい。

【0048】

第２のQoS要求は、対象のUE３を指定するために、UE３に関連付けられた内部識別子（Internal ID）を含んでもよい。内部識別子は、PLMN内でUE３を識別するために使用される。内部識別子は、例えば、International Mobile Subscriber Identity（IMSI）であってもよい。MTC-IWFエンティティ１は、UE３の内部識別子を取得するために、UE３の外部識別子に対応する内部識別子をHSS５１に問い合わせてもよい。

【0049】

PLMN内に複数のPCRFエンティティ５が配置されている場合、MTC-IWFエンティティ１は、UE３のサービスデータフローを管理しているPCRFエンティティ５を複数のPCRFエンティティ５の中から選択しなければならない。したがって、MTC-IWFエンティティ５は、DRA５２との間で制御メッセージを交換し、適切なPCRFエンティティ５のアドレスをDRA５２から取得してもよい。

【0050】

PCRFエンティティ５は、第２のQoS要求をMTC-IWFエンティティ１から受信したことに応答して、第２のQoS要求によって要求されたサービス品質をUE３の特定通信に適用するための制御を行う。第２のQoS要求によって要求されたサービス品質をUE３の特定通信に適用するために、PCRFエンティティ５は、PCEFを有するP-GW５６及びTDFを有するエンティティ５７のうち少なくとも一方を制御すればよい。

【0051】

具体的には、PCRFエンティティ５は、第２のQoS要求に示されたサービス品質、UE３の識別子、及び特定通信の識別情報（e.g. アプリケーション名、送信元アドレス、宛先アドレス、ポート番号、若しくはプロトコル識別子、又はこれらの組み合わせ）に基づいてPCCルールを生成し、生成されたPCCルールをP-GW５６に供給してもよい。このPCCルールのP-GW５６への供給は、UE３に関するIP-CANセッションの修正（modification）を引き起こす。IP-CANセッションの修正は、例えば、既に設定されているIP-CANベアラ（EPSベアラ）のQoSのアップデート、又はSDFテンプレート若しくはTraffic Flow Template（TFT）のアップデートを含む。また、UE３の特定通信のサービスデータフロー（IPパケットフロー）に適用されるQoSポリシーが既に設定されているEPSベアラのQoSポリシーと異なる場合、IP-CANベアラの修正は、UE３の特定通信のサービスデータフローを転送するための新たな個別ベアラ（dedicated EPS bearer）の生成であってもよい。

【0052】

また、PCRFエンティティ５は、第２のQoS要求に示された特定通信の識別情報（e.g. アプリケーション名）に基づいてADCルールを生成し、生成されたPCCルールをTDFエンティティ５７に供給してもよい。そして、設定済みのEPSベアラを経由してUE３により送信又は受信されるユーザトラフィックの中から特定通信のパケットフローが検出されたことに応答して、特定通信のパケットフローに適用されるPCCルールを生成してもよい。例えば第２のQoS要求においてUE３の特定通信がOSI参照モデルのレイヤ５－７の情報（e.g. アプリケーション名）によって指定されている場合、PCRFエンティティ５は、第２のQoS要求に含まれる情報のみから十分なPCCルールを生成することができない可能性がある。なぜなら、UE３の通信相手のIPアドレス等のPCCルール（具体的にはSDFテンプレート又はTFT）に必要なレイヤ３及び４の情報が不明であるためである。このため、PCRFエンティティ５は、TDFエンティティ５７のdeep packet inspection（DPI）機能を利用し、UE３のユーザーデータフローの中から特定通信のトラフィック（つまり、特定アプリケーションのトラフィック）を検出してもよい。これにより、PCRFエンティティ５は、PCCルールの決定に必要な情報、つまりUE３の通信相手のIPアドレス及びポート番号といったレイヤ３及び４の情報を得ることができる。

【0053】

図２は、SCS２からの要求に基づくUE３のサービス品質制御（QoS制御）の一例を示すシーケンス図である。ステップＳ１０１では、SCS２は、Tsp参照点を介して、第１のQoS要求をMTC-IWFエンティティ１に送信する。第１のQoS要求は、制御対象のUE３を特定するためにUE３の外部識別子（External ID）を含む。さらに第１のQoS要求は、UE３の特定通信を特定するための情報、例えばアプリケーション名、ポート番号若しくは通信相手のIPアドレス又はこれらの組み合わせ、を示す。さらにまた、第１のQoS要求は、要求されるサービス品質を特定するための情報、例えばQCI、ARP、MBR、GBR若しくは優先度レベル又はこれらの組み合わせ、を示す。

【0054】

ステップＳ１０２では、MTC-IWFエンティティ１は、SCS２からの第１のQoS要求の受信に応答して、第１のQoS要求において示されたUE３の外部識別子に対応する内部識別子をHSS１に問い合わせる。MTC-IWFエンティティ１は、UE３の外部識別子に対応する加入者情報をHSS５１に要求すればよい。なお、UE３の内部識別子がMTC-IWFエンティティ１において既知である場合、ステップＳ１０２は省略されてもよい。

【0055】

ステップＳ１０３では、MTC-IWFエンティティ１は、UE３のIP-CANセッションを管理しているPCRFエンティティ５をDRA５２に問い合わせる。MTC-IWFエンティティ１は、UE３のIP-CANセッションを管理しているPCRFエンティティ５のアドレスをDRA５２に要求すればよい。なお、PLMN内に配置されたPCRFエンティティ５が１つのみである場合、又はMTCデバイスとしてのUE３を管理するPCRFエンティティ５をMTC-IWFエンティティ１が既に知っている場合は、ステップＳ１０３は省略されてもよい。

【0056】

ステップＳ１０４では、MTC-IWFエンティティ１は、シグナリング・インタフェース１１を介して、第２のQoS要求をPCRFエンティティ５に送信する。図２の例では、第２のQoS要求は、制御対象のUE３を特定するためにUE３の内部識別子（Internal ID）を含む。さらに第２のQoS要求は、UE３の特定通信を特定するための情報、例えばアプリケーション名、ポート番号若しくは通信相手のIPアドレス又はこれらの組み合わせ、を示す。さらにまた、第２のQoS要求は、要求されるサービス品質を特定するための情報、例えばQCI、ARP、MBR、GBR若しくは優先度レベル又はこれらの組み合わせ、を示す。

【0057】

ステップＳ１０５では、PCRFエンティティ５は、MTC-IWFエンティティ１から第２のQoS要求を受信したことに応答して、UE３の特定通信に適用されるべきPCCルールを決定する。当該PCCルールは、UE３の特定通信に関するパケットフローを特定するためのSDFテンプレート（i.e. パケットフィルタ）、QoS制御のための情報（e.g. QCI、ARP、MBR、GBR）を含む。さらに、当該PCCルールは、UE３の特定通信に対する課金制御のための情報（e.g. Charging key、Charging method、Measurement method）を含んでもよい。ステップＳ１０６では、PCRFエンティティ５は、決定されたPCCルールをUE３の特定通信に施行するために、決定されたPCCルールをP-GW５６（PCEF）に送信する。

【0058】

ステップＳ１０７では、PCEFとしてのP-GW５６は、PCCルールを受信したことに応答して、PCCルールをUE３の通信に適用する。具体的には、P-GW５６は、PCCルールの受信に応答して、IP-CAN Session Modification procedureを開始する。上述したように、IP-CANセッションの修正は、例えば、既に設定されているIP-CANベアラ（EPSベアラ）のQoSのアップデート、又はSDFテンプレート若しくはTraffic Flow Template（TFT）のアップデートであってもよい。また、UE３の特定通信に関するサービスデータフロー（IPパケットフロー）に適用されるQoSポリシーが既に設定されているEPSベアラのQoSポリシーと異なる場合、IP-CANベアラの修正は、UE３の特定通信のサービスデータフローを転送するための新たな個別ベアラ（dedicated EPS bearer）の生成であってもよい。

【0059】

上述したことから理解されるように、本実施形態では、MTC-IWFエンティティ１及びPCRFエンティティ５は、SCS２からのサービス品質（QoS）の要求に基づいて、UE３の特定通信（e.g. 特定のアプリケーション・トラフィック）のサービス品質（QoS）を調整するよう動作する。したがって、本実施形態は、SCS２からのサービス品質の要求に応答してUE３の特定通信のサービス品質の制御をPLMN内において容易に行うことができる。

【0060】

＜第２の実施形態＞
本実施形態では、SCS２からの要求に基づくUE３のサービス品質制御（QoS制御）に関する他の具体例を説明する。本実施形態に係る無線通信システムの構成例は、図１と同様である。

【0061】

図３は、SCS２からの要求に基づくUE３のサービス品質制御（QoS制御）の一例を示すシーケンス図である。図３の例では、SCS２から送信される第１のQoS要求及びMTC-IWFエンティティ１から送信される第２のQoS要求において、UE３の特定通信がOSI参照モデルのレイヤ５－７の情報（e.g. アプリケーション名）によって指定される。したがって、PCRFエンティティ５は、UE３のユーザーデータフローの中から特定通信のトラフィック（つまり、特定アプリケーションのトラフィック）を検出するために、TDFエンティティ５７のdeep packet inspection（DPI）機能を利用する。これにより、PCRFエンティティ５は、PCCルールの決定に必要な情報、つまりUE３の特定通信に関するレイヤ３及び４の情報（e.g. UE３の通信相手のIPアドレス及びポート番号）を得ることができる。

【0062】

ステップＳ２０１では、SCS２は、Tsp参照点を介して、第１のQoS要求をMTC-IWFエンティティ１に送信する。第１のQoS要求は、UE３の特定通信を特定するためのレイヤ５－７の情報（e.g. アプリケーション名）を含む。また、図２に関して説明されたのと同様に、第１のQoS要求は、UE３の外部識別子（External ID）、及び要求されるサービス品質を特定するための情報（e.g. QCI、ARP、MBR、GBR若しくは優先度レベル）を含んでもよい。

【0063】

ステップＳ２０２では、MTC-IWFエンティティ１は、シグナリング・インタフェース１１を介して、第２のQoS要求をPCRFエンティティ５に送信する。第２のQoS要求は、UE３の特定通信を特定するためのレイヤ５－７の情報（e.g. アプリケーション名）を含む。また、図２に関して説明されたのと同様に、第２のQoS要求は、UE３の内部識別子（Internal ID）、及び要求されるサービス品質を特定するための情報（e.g. QCI、ARP、MBR、GBR若しくは優先度レベル）を含んでもよい。また、ステップＳ２０２に先立って、HSS５１への問い合わせ及びDRA５２への問い合わせ（図２のステップＳ１０２及びＳ１０３）が行われてもよい。

【0064】

ステップＳ２０３では、PCRFエンティティ５は、第２のQoS要求の受信に応答して、UE３のユーザーデータフローの中から特定通信のトラフィック（つまり、特定アプリケーションのトラフィック）を検出ために利用されるADCルールを決定する。当該ADCルールは、制御対象のUE３の識別子（e.g. IPアドレス）、及び検出されるべきアプリケーションの識別子（e.g. アプリケーション名）を含む。ステップＳ２０４では、PCRFエンティティ５は、決定されたADCルールをTDFエンティティ５７に供給する。

【0065】

ステップＳ２０５では、TDFエンティティ５７は、受信したADCルールに従って特定アプリケーション・トラフィックを検出するために、UE３のユーザーデータフローに対するDPIを開始する。そしてステップＳ２０６では、TDFエンティティ５７は、特定アプリケーション・トラフィックを検出したことに応答して、検出レポートをPCRFエンティティ５に送信する。検出レポートは、特定アプリケーション・トラフィックに関するレイヤ３及び４の情報（e.g. UE３の通信相手のIPアドレス及びポート番号）を含む。

【0066】

ステップＳ２０７では、PCRFエンティティ５は、TDFエンティティ５７からの検出レポートに基づいて、UE３の特定通信に適用されるべきPCCルールを決定する。当該PCCルールは、UE３の特定通信に関するパケットフローを特定するためのSDFテンプレート（i.e. パケットフィルタ）、QoS制御のための情報（e.g. QCI、ARP、MBR、GBR）を含む。さらに、当該PCCルールは、UE３の特定通信に対する課金制御のための情報（e.g. Charging key、Charging method、Measurement method）を含んでもよい。ステップＳ２０８では、PCRFエンティティ５は、決定されたPCCルールをUE３の特定通信に施行するために、決定されたPCCルールをP-GW５６（PCEF）に送信する。

【0067】

ステップＳ２０９では、PCEFとしてのP-GW５６は、PCCルールを受信したことに応答して、PCCルールをUE３の通信に適用する。具体的には、P-GW５６は、PCCルールの受信に応答して、IP-CAN Session Modification procedureを開始する。

【0068】

図４は、本実施形態に係るMTC-IWFエンティティ１、PCRFエンティティ５、P-GW５６、及びTDFエンティティ５７の構成例を示すブロック図である。図４の例では、MTC-IWFエンティティ１は、制御部１０１を有する。制御部１０１は、SCS２から第１のQoS要求を受信したことに応答して、PCRFエンティティ５に第２のQoS要求を送信するよう構成されている。

【0069】

図４の例では、PCRFエンティティ５は、制御部５０１を有する。制御部５０１は、第２のQoS要求を受信したことに応答して、UE３の特定アプリケーション・トラフィックを検出するためのADCルールを決定し、決定されたADCルールをTDFエンティティ５７に供給するよう構成されている。さらに、制御部５０１は、UE３の特定アプリケーション・トラフィックに関する検出レポートをTDFエンティティ５７から受信したことに応答して、UE３の特定アプリケーション・トラフィックに適用されるPCCルールを決定し、決定されたPCCルールをP-GW５６に供給するよう構成されている。

【0070】

図４の例では、TDFエンティティ５７は、シグナリング部５７１及び検出部５７２を含む。シグナリング部５７１は、PCRFエンティティ５（制御部５０１）からADCルールを受信し、ADCルールに基づいて検出されたアプリケーション・トラフィックに関する検出レポートを送信するよう構成されている。検出部５７２は、ADCルールにおいて指定されたアプリケーション・トラフィックを検出するために、UE３のユーザーデータ・トラフィックに対するDPIを実行するよう構成されている。

【0071】

図４の例では、P-GW５６は、シグナリング部５６１及びパケット処理部５６２を含む。シグナリング部５６１は、PCRFエンティティ５（制御部５０１）からPCCルールを受信するよう構成されている。パケット処理部５６２は、PCCルールにおいて指定されたサービスデータフロー及びQoSポリシーを、IP-CANベアラ（EPSベアラ）に適用するよう構成されている。すなわち、パケット処理部５６２は、UE３との個別ベアラのQoSポリシーを修正し、UE３との個別ベアラに適用されるSDFテンプレート及びTFTを修正し、又はUE３に向けて新たな個別EPSベアラを確立するよう構成されている。

【0072】

本実施形態によれば、SCS２は、第１のQoS要求において、サービス要求の対象とされるUE３の特定通信をOSI参照モデルのレイヤ５－７の情報によって指定することができる。例えば、サービス要求の対象とされるUE３の特定通信は、第１のQoS要求において、アプリケーション名（e.g. YouTube（登録商標）、Skype（登録商標））によって指定されてもよい。また、他の例では、UE３の特定通信は、第１のQoS要求において、特定通信の利用用途（e.g. background通信、ソフトウェアの自動アップデート、自動検針（automatic meter reading））によって指定されてもよい。これにより、SCS２は、PLMN（MTC-IWFエンティティ１）に対してQoS要求を行う際に、QoS要求の対象となるUE３の特定通信を上位レイヤ（レイヤ５－７）の情報を用いて柔軟に指定することができる。

【0073】

＜その他の実施形態１＞
PLMN内に複数のHSS５１が配置される場合、MTC-IWFエンティティ１は、UE３の内部識別子を問い合わせるべきHSS５１を特定するためにHSS検索を実行してもよい。一例では、MTCデバイスとしてのUE３の加入者情報を管理するHSS５１のアドレスが予めMTC-IWFエンティティ１に設定されてもよい。他の例では、MTC-IWFエンティティ１は、Subscription Locator Function（SLF）又はDiameter Routing Agent（DRA）を利用してもよい。

【0074】

上述した第２の実施形態では、レイヤ５－７情報によるアプリケーションの指定を含むQoS要求に基づくPCCルールの適用について説明した。すなわち、第２の実施形態に係るPCRFエンティティ５は、レイヤ５－７情報によるアプリケーションの指定を含むQoS要求に応答して、TDFによるDPIを利用し、これによりPCCルール（SDFテンプレート）の決定に必要なレイヤ３及び４情報を取得する。このPCRFエンティティ５の動作は、SCS２又はMTC-IWFエンティティ１とは異なる他のノード又はエンティティ（e.g. Application Function）からのQoS要求に対して行われてもよい。これにより、ノード又はエンティティ（e.g. Application Function）は、PCRFエンティティ５に対してQoS要求を行う際に、QoS要求の対象となるUE３の特定通信を上位レイヤ（レイヤ５－７）の情報を用いて柔軟に指定することができる。

【0075】

上述した第２の実施形態では、TDFエンティティ５７がアプリケーション・トラフィックの検出を行う例について説明した。しかしながら、アプリケーション・トラフィックを検出するために常にDPIを実行することは、TDFエンティティ５７の処理負荷を増大させるかもしれない。したがって、PCRFエンティティ５は、ADCルールと共に、DPIが実行されるべき期間、言い換えるとADCルールが施行されるべき期間、をTDFエンティティ５７に通知してもよい。さらに、DPIが実行されるべき期間（ADCルールが施行されるべき期間）は、SCS２からMTC-IWFエンティティ１に送られる第１のQoS要求、及びMTC-IWFエンティティ１からPCRFエンティティ５に送られる第２のQoS要求において指定されてもよい。すなわち、第１及び第２のQoS要求は、UE３の特定通信に対して特別なQoSポリシーが適用される期間を指定してもよい。これにより、SCS２は希望する期間（時間帯）において特別なQoSポリシーの適用を受けることができ、さらにTDFエンティティ５７の負荷を軽減することができる。

【0076】

第１及び第２の実施形態で説明されたMTC-IWFエンティティ１、SCS２、UE３、PCRFエンティティ５、S-GW５５、P-GW５６、及びTDFエンティティ５７等の動作は、少なくとも１つのプロセッサ（e.g. マイクロプロセッサ、Micro Processing Unit（MPU）、Central Processing Unit（CPU））を含むコンピュータにプログラムを実行させることによって実現されてもよい。具体的には、図２及び図３等を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムをコンピュータに供給すればよい。

【0077】

このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（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）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

【0078】

＜その他の実施形態２＞
ここでは、上述した第１及び第２の実施形態とは異なる新たな実施形態について説明する。ここで説明される新たな実施形態は、上述した第１及び第２の実施形態とは独立して実施されることができ、第１及び第２の実施形態とは異なる課題を解決することができる。

【0079】

図５は、本実施形態に係る本実施形態に係る無線通信システムの構成例を示す図である。MTCデバイス６１は、PLMN６２に接続することができ、PLMN６２を介してMTCサーバ６３と通信することができる。MTCデバイス６１は、MTC UEアプリケーションを実行するUEと呼ぶこともできる。MTCデバイス６１は、MTCゲートウェイ・デバイスであってもよい。

【0080】

Public Land Mobile Network（PLMN）６２は、例えば、3GPPネットワーク、つまりUniversal Mobile Telecommunications System（UMTS）又はEvolved Packet System（EPS）である。PKMN６２は、Radio Access Network（RAN）及びコアネットワークを含む。より具体的に述べると、PLMN６２は、RANノードとしての基地局、コアネットワークのコントロールプレーン・エンティティとしての移動管理ノード（e.g. MME、又はSGSNのコントロールプレーン機能）、及びコアネットワークのユーザープレーン・エンティティとしてのデータ転送ノード（e.g. P-GW、S-GW、GGSN、又はSGSNのユーザープレーン機能）を含む。さらに、PLMN６２は、MTCサーバ６３を含むM2MサービスレイヤがPLMN６２と協調動作（interwork）できるようにするために、Machine Type Communication Inter Working Function （MTC-IWF）エンティティを含んでもよい。

【0081】

MTCサーバ６３は、M2Mアプリーション６４をPLMN６２に接続し、PLMN６２により提供されるサービスを介してM2Mアプリーション６４がMTCデバイス６１と通信できるようにする。MTCサーバ６３は、Service Capability Server（SCS）又はM2Mサーバとも呼ばれる。

【0082】

M2Mアプリケーション６４は、PLMN６２の外部（外部ネットワーク）に配置され、M2Mアプリケーション（MTCアプリケーション）を実行し、MTCデバイス６１に実装されたMTC UEアプリケーションと通信する。M2Mアプリケーション６４は、一般的に、M2Mサービスプロバイダ（MTCサービスプロバイダ）によって制御される。M2Mアプリケーション６４は、M2Mアプリケーションサーバ又はMTCアプリケーションサーバとも呼ばれる。

【0083】

以下では、本実施形態のMTCデバイス６１、PLMN６２、及びMTCサーバ６３の動作についてさらに詳しく説明する。PLMN６２は、MTCデバイス６１のPLMN６２へのアタッチ（ステップＳ６０１）に応答して、MTCデバイス６１がPLMN６２にアタッチしたことをMTCサーバ６３に通知するよう動作する（ステップＳ６０２）。なお、MTCデバイス６１がPLMN６２にアタッチすることは、PLMN６２においてMTCデバイス６１のモビリティ管理が開始されることを意味する。例えば、EPSの場合、MTCデバイス６１は、PLMN６２内のMMEに登録され、EPS Mobility Management (EMM)-DEREGISTERED状態からEMM-REGISTERED状態に遷移する。つまり、MTCデバイス６１がPLMN６２にアタッチすると、ページングによってMTCデバイス６１に到達することができるようになる。したがって、PLMN６２は、ページングによってMTCデバイス６１に到達できることを通知すると言い換えることもできる。

【0084】

MTCサーバ６３は、MTCデバイス６１のアタッチ通知（Ｓ６０２）をPLMN６２にから受信することで、MTCデバイス６１との通信を行えることを認識できる。したがって、MTCサーバ６３は、MTCデバイス６１との通信を開始してもよい（ステップＳ６０３）。

【0085】

ステップＳ６０１～Ｓ６０３の動作は、MTCサーバ６３がPLMN６２を介してMTCデバイス６１と通信可能である期間を十分に正確に把握できないケースで特に有効である。例えば、消費電力を低減するために、MTCデバイス６１が、殆どの時間で通信モジュールの動作を停止しているケースが考えられる。この場合、MTCデバイス６１は、MTCサーバ６３により設定されたwake/sleepスケジュールを有してもよい。wake/sleepスケジュールは、wake期間とsleep期間を定める。wake期間では、MTCデバイス６１は、PLMN６２にアタッチし、PLMN６２を介してMTCサーバ６３と通信することができる。sleep期間では、MTCデバイス６１は、PLMN６２からデタッチしており、PLMN６２からのページングに反応することができず、したがってMTCサーバ６３はMTCデバイス６１と通信することができない。

【0086】

MTCデバイス６１は、何らかの要因に応じてsleep期間内でもPLMN６２と通信してもよい。しかしながら、MTCサーバ６３は、予め定められたwake期間を除いて、MTCデバイス６１がPLMN６２にアタッチしていること（つまり、MTCデバイス６１との通信を開始できること）を知ることができない。さらに、MTCデバイス６１は、送信するべきデータが存在しない場合、又は所定の送信条件が成立していない場合に、wake期間であってもPLMN６２にアタッチしないことが考えられる。さらにまた、MTCデバイス６１が有する内部クロックは、十分に正確ではない可能性があり、したがってMTCデバイス６１が有するwake/sleepスケジュールは、MTCサーバ６３が有するwake/sleepスケジュールと十分に同期していないおそれがある。これらの場合、MTCサーバ６３は、MTCデバイス６１がPLMN６２にアタッチしていること（つまり、MTCデバイス６１との通信を開始できること）を正確に知ることができない。

【0087】

したがって、上述したように、MTCデバイス６１がPLMN６２にアタッチしていること（つまり、MTCデバイス６１との通信を開始できること）をPLMN６２からMTCサーバ６３に通知することで、MTCサーバ６３がMTCデバイス６１と通信する機会を増やすことができる。

【0088】

本実施形態が有効に適用できる例として、MTCデバイス６１が河川の水位計に結合され、測定された水位をMTCサーバ６３又はMTCアプリケーション６４に報告する場合が考えられる。MTCデバイス６１は、短いwake期間（e.g. １分）と、長いsleep期間（e.g. ６時間）をMTCサーバ６３から設定されてもよい。さらに、MTCデバイス６１は、測定された水位が所定の閾値を上回った場合にのみ新たな測定結果を報告してもよい。水位が正常である限り、MTCデバイス６１は、長期間（e.g. 数ヶ月）にわたって測定結果を報告しないかもしれない。

【0089】

しかしながら、１つの又はいくつかの水位計（MTCデバイス６１）から測定結果が報告され且つその測定結果が水害の発生が憂慮される値であるととき、現況をより詳細に把握するために他の水位計（MTCデバイス６１）の測定結果を速やかに且つ頻繁に得られることが好ましい。この場合、関係する（e.g. 同一河川の）全てのMTCデバイス６１のwake/sleepスケジュールを速やかに更新できることが好ましい。上述したステップＳ６０１～Ｓ６０３の動作によれば、MTCサーバ６２は、MTCデバイス６１との通信（つまり、mobile terminated方向の通信）が開始可能であることを正確に把握できるから、測定結果の報告がなされないMTCデバイス６２に対しても新たなwake/sleepスケジュールを速やかに送信することができる。

【0090】

図６は、図５を用いて説明したステップＳ６０１～Ｓ６０３の動作の具体例を示すシーケンス図である。図６の例では、PLMN６２は、MME６２１及びMTC-IWFエンティティ６２２を含む。ステップＳ７０１では、MTCデバイス６１は、MME６２１にATTACH REQUESTを送信し、MME６２１との間でアタッチ手順を開始する。ステップＳ７０２では、MME６２１は、MTCデバイス６１のPLMN６２へのアタッチを示す通知をMTC-IWFエンティティ６２２に送信する。ステップＳ７０３では、MTC-IWFエンティティ６２２は、MME６２１からの通知に応答して、MTCデバイス６１のPLMN６２へのアタッチを示す通知をMTCサーバ６３に送信する。ステップＳ７０４では、MTCサーバ６２は、PLMN６２を介してMTCデバイス６１に新たなwake/sleepスケジュールを送信する。新たなwake/sleepスケジュールは、例えば、電子メール、Short Message Service（SMS）メッセージ、又はMultimedia Messaging Service（MMS）メッセージによって送信されてもよい。

【0091】

さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

【0092】

例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

【0093】

（付記１）
設定済みのベアラを経由して移動局により送信又は受信されるユーザトラフィックの中から特定パケットフローが検出されたことに応答して、前記特定パケットフローに適用される第１のPolicy and Charging Control（PCC）ルールをPolicy and Charging Enforcement Function（PCEF）を有するPCRFノードに供給する制御部を備える、
Policy and Charging Rule Function（PCRF）エンティティ。

【0094】

（付記２）
前記第１のPCCルールは、前記ユーザトラフィックに適用される第２のPCCルールと異なる、付記１に記載のPCRFエンティティ。

【0095】

（付記３）
前記第１のPCCルールの前記PCEFノードへの供給は、前記特定パケットフローを転送するための新たな個別ベアラの生成を引き起こす、付記１又は２に記載のPCRFエンティティ。

【0096】

（付記４）
前記制御部は、
前記特定パケットフローを検出するためのApplication Detection and Control（ADC）ルールをTraffic Detection Function（TDF）を有するTDFノードに供給し、
前記TDFノードによる前記特定パケットフローの検出に応答して、前記第１のPCCルールを前記PCEFノードに供給する、
付記１～３のいずれか１項に記載のPCRFエンティティ。

【0097】

（付記５）
前記ADCルールは、前記特定パケットフローを指定するためのアプリケーション名を含み、
前記第１のPCCルールは、前記アプリケーション名に基づいて前記特定パケットフローに関して前記TDFノードにおいて検出された送信元アドレス、宛先アドレス、ポート番号、及びプロトコル識別子のうち少なくとも１つを示す、
付記４に記載のPCRFエンティティ。

【0098】

（付記６）
前記移動局は、Machine Type Communication（MTC）デバイスであり、
前記制御部は、前記MTCデバイスの特定通信に適用されるサービス品質の要求をMachine Type Communication Inter Working Function（MTC-IWF）エンティティから受信したことに応答して、前記第１のPCCルールを前記PCEFノードに供給する、
付記１～３のいずれか１項に記載のPCRFエンティティ。

【0099】

（付記７）
前記移動局は、Machine Type Communication（MTC）デバイスであり、
前記制御部は、前記MTCデバイスの特定通信に適用されるサービス品質の要求をMachine Type Communication Inter Working Function（MTC-IWF）エンティティから受信したことに応答して、前記ADCルールを前記TDFノードに供給する、
付記４又は５に記載のPCRFエンティティ。

【0100】

（付記８）
前記制御部は、前記ADCルールが施行される期間を前記TDFノードに通知する、付記４、５、又は７に記載のPCRFエンティティ。

【0101】

（付記９）
前記要求は、前記特定通信に前記サービス品質が適用される期間の指定を含み、
前記制御部は、前記サービス品質が適用される期間に基づいて決定された前記ADCルールが施行される期間を前記TDFノードに通知する、付記７に記載のPCRFエンティティ。

【0102】

（付記１０）
設定済みのベアラを経由して移動局により送信又は受信されるユーザトラフィックの中から特定パケットフローが検出されたことに応答して、前記特定パケットフローに適用される第１のPolicy and Charging Control（PCC）ルールをPolicy and Charging Enforcement Function（PCEF）を有するPCRFノードに供給することを備える、
Policy and Charging Rule Function（PCRF）エンティティにより行われる制御方法。

【0103】

（付記１１）
前記第１のPCCルールは、前記ユーザトラフィックに適用される第２のPCCルールと異なる、付記１０に記載の制御方法。

【0104】

（付記１２）
前記第１のPCCルールの前記PCEFノードへの供給は、前記特定パケットフローを転送するための新たな個別ベアラの生成を引き起こす、付記１０又は１１に記載の制御方法。

【0105】

（付記１３）
前記供給することは、
前記特定パケットフローを検出するためのApplication Detection and Control（ADC）ルールをTraffic Detection Function（TDF）を有するTDFノードに送信すること、及び
前記TDFノードによる前記特定パケットフローの検出に応答して、前記第１のPCCルールを前記PCEFノードに供給すること、
を含む、
付記１０～１２のいずれか１項に記載の制御方法。

【0106】

（付記１４）
前記ADCルールは、前記特定パケットフローを指定するためのアプリケーション名を含み、
前記第１のPCCルールは、前記アプリケーション名に基づいて前記特定パケットフローに関して前記TDFノードにおいて検出された送信元アドレス、宛先アドレス、ポート番号、及びプロトコル識別子のうち少なくとも１つを示す、
付記１３に記載の制御方法。

【0107】

（付記１５）
前記移動局は、Machine Type Communication（MTC）デバイスであり、
前記供給することは、前記MTCデバイスの特定通信に適用されるサービス品質の要求をMachine Type Communication Inter Working Function（MTC-IWF）エンティティから受信したことに応答して、前記第１のPCCルールを前記PCEFノードに供給することを含む、
付記１０～１２のいずれか１項に記載の制御方法。

【0108】

（付記１６）
前記移動局は、Machine Type Communication（MTC）デバイスであり、
前記送信することは、前記MTCデバイスの特定通信に適用されるサービス品質の要求をMachine Type Communication Inter Working Function（MTC-IWF）エンティティから受信したことに応答して、前記ADCルールを前記TDFノードに送信することを含む、
付記１３又は１４に記載の制御方法。

【0109】

（付記１７）
Policy and Charging Rule Function（PCRF）に関する制御方法をコンピュータに行わせるためのプログラムであって、
前記制御方法は、設定済みのベアラを経由して移動局により送信又は受信されるユーザトラフィックの中から特定パケットフローが検出されたことに応答して、前記特定パケットフローに適用される第１のPolicy and Charging Control（PCC）ルールをPolicy and Charging Enforcement Function（PCEF）を有するPCRFノードに供給することを備える、
プログラム。

【0110】

（付記１８）
Public Land Mobile Network（PLMN）に配置されるネットワークノードであって、
Machine Type Communication（MTC）デバイスが前記PLMNにアタッチしたことに応答して、前記MTCデバイスとの通信が可能であることを示す通知を前記PLMNの外部に配置されたMTCサーバに送信する制御部を備えるネットワークノード。

【0111】

（付記１９）
前記ネットワークノードは、Machine Type Communication Inter Working Function（MTC-IWF）エンティティである、付記１８に記載のネットワークノード。

【0112】

（付記２０）
Public Land Mobile Network（PLMN）に配置されるネットワークノードにより行われる方法であって、
Machine Type Communication（MTC）デバイスが前記PLMNにアタッチしたことに応答して、前記MTCデバイスとの通信が可能であることを示す通知を前記PLMNの外部に配置されたMTCサーバに送信することを備える方法。

【0113】

（付記２１）
前記ネットワークノードは、Machine Type Communication Inter Working Function（MTC-IWF）エンティティである、付記２０に記載の方法。

【0114】

この出願は、２０１４年１月９日に出願された日本出願特願２０１４－００２７５５を基礎とする優先権を主張し、その開示の全てをここに取り込む。

【符号の説明】

【0115】

１ Machine Type Communication Inter Working Function （MTC-IWF）エンティティ
２ Service Capability Server （SCS）
３ User Equipment（UE）
４ MTC アプリケーションサーバ
１１、１２ シグナリング・インタフェース（又は参照点）
３１ MTC UE アプリケーション
５１ Home Subscriber Server（HSS）
５２ Diameter Routing Agent（DRA）
５３ Mobility Management Entity（MME）
５４ Radio Access Network（RAN）
５５ Serving Gateway（S-GW）
５６ Packet Data Network Gateway（P-GW）
５７ Traffic Detection Function（TDF）
１０１ 制御部
５０１ 制御部
５６１ シグナリング部
５６２ パケット処理部
５７１ シグナリング部
５７２ 検出部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】