特許 6366112 混雑状況でサービスレベルを調節する方法及び装置

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

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

(11)【特許番号】6366112

(24)【登録日】2018年7月13日

(45)【発行日】2018年8月1日

(54)【発明の名称】混雑状況でサービスレベルを調節する方法及び装置

(51)【国際特許分類】

   H04W 4/24 20090101AFI20180723BHJP

   H04W 28/12 20090101ALI20180723BHJP

【ＦＩ】

   H04W4/24

   H04W28/12

【請求項の数】20

【全頁数】34

(21)【出願番号】特願2015-553660(P2015-553660)

(86)(22)【出願日】2014年1月20日

(65)【公表番号】特表2016-504001(P2016-504001A)

(43)【公表日】2016年2月8日

(86)【国際出願番号】KR2014000558

(87)【国際公開番号】WO2014112843

(87)【国際公開日】20140724

【審査請求日】2016年11月22日

(31)【優先権主張番号】10-2013-0006081

(32)【優先日】2013年1月18日

(33)【優先権主張国】KR

(31)【優先権主張番号】10-2013-0030770

(32)【優先日】2013年3月22日

(33)【優先権主張国】KR

(31)【優先権主張番号】10-2013-0131691

(32)【優先日】2013年10月31日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100154922

【弁理士】

【氏名又は名称】崔 允辰

(74)【代理人】

【識別番号】100140534

【弁理士】

【氏名又は名称】木内 敬二

(72)【発明者】

【氏名】サンスー・ジョン

(72)【発明者】

【氏名】ソンヤン・チョ

(72)【発明者】

【氏名】ヨンキョ・ベク

(72)【発明者】

【氏名】ハナ・リム

【審査官】 望月 章俊

(56)【参考文献】

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

【文献】 特表２０１３−５４２６２９（ＪＰ，Ａ）

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

【文献】 特開２０１２−１９５８９８（ＪＰ，Ａ）

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

Ｈ０４Ｗ４／００−Ｈ０４Ｗ９９／００

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

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

【請求項1】

移動通信システムのパケットデータネットワークゲートウェイ（ＰＧＷ）での信号の送受信方法において、
パケットデータネットワーク（ＰＤＮ）から端末と関連したデータパケットを受信する段階と、
サービングゲートウェイ（ＳＧＷ）から前記端末のＰＤＮ ｃｏｎｎｅｃｔｉｏｎに対応するＰＤＮ ｃｈａｒｇｉｎｇと関連した制御情報を含むメッセージを受信する段階と、
前記制御情報に基づいて、前記ＰＤＮ ｃｏｎｎｅｃｔｉｏｎに対応するあるパケットに対し、ＰＤＮ ｃｈａｒｇｉｎｇを中止する段階とを含み、
前記中止されるＰＤＮ ｃｈａｒｇｉｎｇは、前記制御情報に基づいて対応するＰＤＮ ｃｏｎｎｅｃｔｉｏｎ別に中止され、
前記ＰＤＮ ｃｈａｒｇｉｎｇが中止される間ＰＤＮ ｃｏｎｎｅｃｔｉｏｎに関連したデータパケットが廃棄（ｄｉｓｃａｒｄ）されることを特徴とする信号の送受信方法。

【請求項2】

前記廃棄されるデータパケットは、前記端末に伝送されるために前記ＰＧＷに受信されたパケットであることを特徴とする請求項１に記載の信号の送受信方法。

【請求項3】

前記制御情報は、
前記ＰＤＮ ｃｈａｒｇｉｎｇの中止を開始することを示す指示子を含むことを特徴とする請求項１に記載の信号の送受信方法。

【請求項4】

前記端末との接続が損失されたことを示す基地局から受信された情報に基づいて、前記制御情報が生成されることを特徴とする請求項１に記載の信号の送受信方法。

【請求項5】

前記ＳＧＷにある前記ＰＤＮに対するデータパケットは、前記ＰＤＮ ｃｈａｒｇｉｎｇが中止される間に廃棄されることを特徴とする請求項１に記載の信号の送受信方法。

【請求項6】

移動通信システムのサービングゲートウェイ（ＳＧＷ）での信号の送受信方法において、
パケットデータネットワークゲートウェイ（ＰＤＮ ＧＷ、ＰＧＷ）から端末と関連したデータパケットを受信する段階と、
前記端末のＰＤＮ ｃｏｎｎｅｃｔｉｏｎに対応するＰＤＮ ｃｈａｒｇｉｎｇと関連した制御情報を含むメッセージを前記ＰＧＷに伝送する段階とを含み、
前記制御情報に基づいて、前記ＰＤＮ ｃｏｎｎｅｃｔｉｏｎに対応するあるパケットに対し、ＰＤＮ ｃｈａｒｇｉｎｇが中止され、
前記中止されるＰＤＮ ｃｈａｒｇｉｎｇは、前記制御情報に基づいて対応するＰＤＮ ｃｏｎｎｅｃｔｉｏｎ別に中止され、
前記ＰＤＮ ｃｈａｒｇｉｎｇが中止される間ＰＤＮ ｃｏｎｎｅｃｔｉｏｎに関連したデータパケットが廃棄（ｄｉｓｃａｒｄ）されることを特徴とする信号の送受信方法。

【請求項7】

前記廃棄されるデータパケットは、前記端末に伝送されるために前記ＰＧＷに受信されたパケットであることを特徴とする請求項６に記載の信号の送受信方法。

【請求項8】

前記制御情報は、
前記ＰＤＮ ｃｈａｒｇｉｎｇの中止を開始することを示す指示子を含むことを特徴とする請求項６に記載の信号の送受信方法。

【請求項9】

基地局から前記端末との接続が損失されたことを示す情報を受信する段階と、
前記基地局から受信された情報に基づいて、前記制御情報を生成する段階とをさらに含むことを特徴とする請求項６に記載の信号の送受信方法。

【請求項10】

前記ＰＤＮ ｃｈａｒｇｉｎｇが中止される間に前記データパケットを廃棄する段階をさらに含むことを特徴とする請求項６に記載の信号の送受信方法。

【請求項11】

移動通信システムのパケットデータネットワークゲートウェイ（ＰＧＷ）において、
信号を送受信する送受信部と、
前記送受信部を制御し、パケットデータネットワーク（ＰＤＮ）から端末と関連したデータパケットを受信し、サービングゲートウェイ（ＳＧＷ）から前記端末のＰＤＮ ｃｏｎｎｅｃｔｉｏｎに対応するＰＤＮ ｃｈａｒｇｉｎｇと関連した制御情報を含むメッセージを受信し、前記制御情報に基づいて、前記ＰＤＮ ｃｏｎｎｅｃｔｉｏｎに対応するあるパケットに対し、ＰＤＮ ｃｈａｒｇｉｎｇを中止する制御部とを含み、
前記中止されるＰＤＮ ｃｈａｒｇｉｎｇは、前記制御情報に基づいて対応するＰＤＮ ｃｏｎｎｅｃｔｉｏｎ別に中止され、
前記ＰＤＮ ｃｈａｒｇｉｎｇが中止される間ＰＤＮ ｃｏｎｎｅｃｔｉｏｎに関連したデータパケットが廃棄（ｄｉｓｃａｒｄ）されることを特徴とするＰＧＷ。

【請求項12】

前記廃棄されるデータパケットは、前記端末に伝送されるために前記ＰＧＷに受信されたパケットであることを特徴とする請求項１１に記載のＰＧＷ。

【請求項13】

前記制御情報は、
前記ＰＤＮ ｃｈａｒｇｉｎｇの中止を開始することを示す指示子を含むことを特徴とする請求項１１に記載のＰＧＷ。

【請求項14】

前記端末との接続が損失されたことを示す基地局から受信された情報に基づいて、前記制御情報が生成されることを特徴とする請求項１１に記載のＰＧＷ。

【請求項15】

前記ＳＧＷにある前記ＰＤＮに対するデータパケットは、前記ＰＤＮ ｃｈａｒｇｉｎｇが中止される間に廃棄されることを特徴とする請求項１１に記載のＰＧＷ。

【請求項16】

移動通信システムのサービングゲートウェイ（ＳＧＷ）において、
信号を送受信する送受信部と、
前記送受信部を制御し、 パケットデータネットワークゲートウェイ（ＰＤＮ ＧＷ、ＰＧＷ）から端末と関連したデータパケットを受信し、前記端末のＰＤＮ ｃｏｎｎｅｃｔｉｏｎに対応するＰＤＮ ｃｈａｒｇｉｎｇと関連した制御情報を含むメッセージを前記ＰＧＷに伝送する制御部とを含み、
前記制御情報に基づいて、前記ＰＤＮ ｃｏｎｎｅｃｔｉｏｎに対応するあるパケットに対し、ＰＤＮ ｃｈａｒｇｉｎｇが中止され、
前記中止されるＰＤＮ ｃｈａｒｇｉｎｇは、前記制御情報に基づいて対応するＰＤＮ ｃｏｎｎｅｃｔｉｏｎ別に中止され、
前記ＰＤＮ ｃｈａｒｇｉｎｇが中止される間ＰＤＮ ｃｏｎｎｅｃｔｉｏｎに関連したデータパケットが廃棄（ｄｉｓｃａｒｄ）されることを特徴とするＳＧＷ。

【請求項17】

前記廃棄されるデータパケットは、前記端末に伝送されるために前記ＰＧＷに受信されたパケットであることを特徴とする請求項１６に記載のＳＧＷ。

【請求項18】

前記制御情報は、
前記ＰＤＮ ｃｈａｒｇｉｎｇの中止を開始することを示す指示子を含むことを特徴とする請求項１６に記載のＳＧＷ。

【請求項19】

前記制御部は、
基地局から前記端末との接続が損失されたことを示す情報を受信し、前記基地局から受信された情報に基づいて、前記制御情報を生成することを特徴とする請求項１６に記載のＳＧＷ。

【請求項20】

前記制御部は、前記ＰＤＮ ｃｈａｒｇｉｎｇが中止される間に前記データパケットを廃棄することを特徴とする請求項１６に記載のＳＧＷ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、無線通信システムで混雑状況でサービスレベルを調節する方法及び装置に関する。より具体的に、混雑が発生した場合、混雑を解決する方案及び混雑解決による副作用を減らすことができる方法及び装置に関する。

【背景技術】

【0002】

図１は、ＬＴＥ移動通信システムの構造を示す図面である。

【0003】

前記図１を参照すれば、示されたようにＬＴＥ移動通信システムの無線アクセスネットワークは、次世代基地局(Ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ、ＥＵＴＲＡＮ、以下、ＥＮＢ又はＮｏｄｅ Ｂと言う)１１０とＭＭＥ(移動性管理エンティティー、Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)１２０及びＳ−ＧＷ(サービングゲートウェイ、Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ)１３０から構成される。ユーザ端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、以下、端末又はＵＥと称する)１００は、ＥＮＢ１１０及びＳ−ＧＷ１３０、及びＰ−ＧＷ(パケットデータネットワークゲートウェイ、Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ−Ｇａｔｅｗａｙ)１６０を介して外部ネットワークと接続する。ＡＦ(応用機能、Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ)はユーザとａｐｐｌｉｃａｔｉｏｎ水準でａｐｐｌｉｃａｔｉｏｎに係る情報を交換する装置である。ＰＣＲＦ１５０は、ユーザのＱｏＳに係るｐｏｌｉｃｙを制御する装置であり、ｐｏｌｉｃｙに該当するＰＣＣ(Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ)ｒｕｌｅは、Ｐ−ＧＷ１６０に伝達して適用される。

【0004】

ＥＮＢ１１０は、ＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)ノードとしてＵＴＲＡＮシステムのＲＮＣ(Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒｓ)、及びＧＥＲＡＮシステムのＢＳＣ(ｂａｓｅ ｓｔａｔｉｏｎ ｃｏｎｔｒｏｌｌｅｒ)に対応される。ＥＮＢ１１０はＵＥ１００と無線チャンネルで接続されて既存のＲＮＣ／ＢＳＣと類似の役目を行う。

【0005】

ＬＴＥではインターネットプロトコルを通じるＶｏＩＰ(Ｖｏｉｃｅ ｏｖｅｒ ＩＰ)のようなリアルタイムサービスを含むすべてのユーザトラフィックが共用チャンネル(ｓｈａｒｅｄ ｃｈａｎｎｅｌ)を介してサービスされるので、ＵＥ１００の状況情報を集めてスケジューリングをする装置が必要で、これをＥＮＢ１１０が担当する。

【0006】

Ｓ−ＧＷ１３０は、データベアラを提供する装置であり、ＭＭＥ１５０の制御に応じてデータベアラを生成したり除去する。ＭＭＥ１５０は、各種制御機能を担当する装置で一つのＭＭＥ１５０は多数の基地局と接続されることができる。

【0007】

ＰＣＲＦ(Ｐｏｌｉｃｙ Ｃｈａｒｇｉｎｇ ａｎｄ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ)１５０は、トラフィックに対するＱｏＳ及び課金を総括的に制御するエンティティーである。

【0008】

一般的に、 ＵＰとはユーザのデータが送受信されるＵＥ１００とＲＡＮノード、ＲＡＮノードでＳ−ＧＷ１３０、そしてＳ−ＧＷ１３０でＰ−ＧＷ１６０を繋ぐ経路を称する。ところで、この経路の中でリソースの制限がひどい無線チャンネルを用いる部分はＵＥとＲＡＮノードの間の経路である。

【0009】

ＬＴＥのような無線通信システムにおいてＱｏＳを適用することができる単位はＥＰＳベアラである。一つのＥＰＳベアラは同じなＱｏＳ要求事項を持つＩＰ Ｆｌｏｗを送信するのに用いられる。ＥＰＳベアラにはＱｏＳに係るパラメタが指定されることができ、ここにはＱＣＩとＡＲＰが含まれる。ＥＰＳベアラは、ＧＰＲＳシステムのＰＤＰ ｃｏｎｔｅｘｔに対応される。

【0010】

したがって、無線通信システムにおいてリソースの制限により発生することができる混雑を減らすことができる方案が要求される。

【発明の概要】

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

【0011】

前記問題点を解消するために、本願発明の実施形態はＲＡＮ混雑状況(以下、Ｕｓｅｒ Ｐｌａｎｅ(ユーザ平面)混雑状況と同様に使用)でユーザ体感サービス品質を劣らず、かつ混雑状況に対応するために、基地局がユーザ特性又はサービス応用(ａｐｐｌｉｃａｔｉｏｎ)を考慮した混雑制御をする方法及び装置を提供することを目的とする。

【0012】

また、本願発明の他の実施形態は基地局が混雑制御の際、パケットに対する通信網の事業者が前記混雑制御が適用されるパケットに対して容易に課金することができる方法及び装置を提供することをその目的とする。

【0013】

また、本願発明のまた他の実施形態は端末が基地局の間でハンドオーバーが起きる場合に混雑制御情報を介して移動した基地局で混雑制御を効率的にできる方法及び装置を提供することを目的とする。

【0014】

また、本願発明のまた他の実施形態は基地局が混雑制御の際、前記混雑制御が適用されるパケットの性格によって混雑制御ができる方法及び装置を提供することを目的とする。

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

【0015】

上述した課題を達成するために、本明細書の一実施形態による移動通信システムで基地局の混雑管理方法は、移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ)でユーザ加入情報をリクエストする段階と、前記ＭＭＥから前記ユーザ購読情報を受信する段階と、及び前記受信したユーザ購読情報に基づいて端末との通信で混雑制御を行う段階と、を含む。

【0016】

本明細書の他の実施形態による移動通信システムの移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ)で混雑管理方法は、基地局からユーザ加入情報をリクエストを受信する段階と、及び前記リクエストに基づいて前記基地局にユーザ購読情報を送信する段階を含み、前記基地局は前記受信したユーザ購読情報に基づいて端末との通信で混雑制御を行うことを特徴とする。

【0017】

本明細書の他の実施形態による移動通信システムで基地局は、移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、 ＭＭＥ)でユーザ加入情報をリクエストし、 前記ＭＭＥから前記ユーザ購読情報を受信する送受信部と、及び前記受信したユーザ購読情報に基づいて端末との通信で混雑制御を行う制御部と、を含む。

【0018】

本明細書のまた他の実施形態による移動通信システムの移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、 ＭＭＥ)は、基地局からユーザ加入情報をリクエストを受信する送受信部と、及び前記前記リクエストに基づいて前記基地局にユーザ購読情報を送信するように前記送受信部を制御する制御部を含み、前記基地局は前記受信したユーザ購読情報に基づいて端末との通信で混雑制御を行うことを特徴とする。

【0019】

本明細書の他の実施形態による移動通信システムの端末で混雑管理方法は、ＵＰＣＯＮ政策サーバー(Ｕｓｅｒ Ｐｌａｎｅ Ｃｏｎｇｅｓｔｉｏｎ ｐｏｌｉｃｙ ｓｅｒｖｅｒ)に政策リクエストメッセージを送信する段階と、前記ＵＰ政策サーバーから前記政策リクエストメッセージに対応した１個以上のアプリケーションのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを含む政策応答メッセージを受信する段階と、前記端末が行うアプリケーションがデータを生成する段階と、及び前記応答メッセージに基づいて前記生成されたデータ及び前記生成されたデータのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを含む信号を基地局に送信する段階と、を含む。

【0020】

本明細書の他の実施形態による移動通信システムの基地局で混雑管理方法は、端末から前記端末で実行されるアプリケーションが生成したデータ及び前記生成されたデータのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを含む第１信号を受信する段階と、前記受信した信号に基づいて前記アプリケーションが生成したデータのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを含む情報を記憶する段階と、前記アプリケーションが生成したデータをゲートウェイに送信する段階と、前記ゲートウェイから前記アプリケーションが生成したデータに対応して目的サーバーが生成したデータを含む第２信号を受信する段階と、及びユーザ平面が混雑状況の場合、前記サーバーが生成したデータを送信するとき、前記記憶された情報に基づいて混雑制御を行う段階と、を含む。

【0021】

本明細書の他の実施形態による移動通信システムの基地局でデータ送受信方法は、コアネットワークからデータパケットを受信する段階と、前記受信したデータパケットを端末へ送信する段階と、前記端末と連結が有効ではないことを検出する段階と、及び前記検出結果を前記コアネットワークに伝達する段階と、を含み、前記検出結果を受信したコアネットワークは前記端末に送信したデータパケットに係る情報を変更する段階と、を含む。

【0022】

本明細書のまた他の実施形態による移動通信システムのコアネットワークノードでデータ送受信方法は、基地局へデータパケットを送信する段階と、前記基地局から前記基地局と端末の接続状態情報を含むメッセージを受信する段階と、及び前記接続状態が有効ではない場合、前記送信したデータパケットに対する情報を変更する段階と、を含む。

【発明の効果】

【0023】

実施形態による場合、無線通信システムで混雑制御をするとき、ユーザ情報及び現在混雑状況を考慮した措置をすることができるから混雑制御による副作用を減らすことができる。

【0024】

また、パケットドロップを行うとき、ドロップされたパケットに対する課金をしないようにする方法及び装置を提示することによって、より容易に混雑制御を行うことができる。

【0025】

また、混雑制御の際、混雑制御を適用するパケットの種類によって混雑制御を行うことによって混雑制御によるユーザ不便を最小化させることができる。

【0026】

また、アプリケーションのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ情報を政策サーバーから受信し、前記混雑制御の際、前記アプリケーションが発生させるパケットの性格によって混雑制御ができる。

【0027】

また、実施形態による場合、端末がデータパケットが受信することができない場合にコアネットワークが送信されるパケットを調節したり課金情報を変更して基地局又はコアネットワークでパケットがドロップされることを防止し、端末に不当な課金が発生することを防止することができる。

【図面の簡単な説明】

【0028】

【図1】従来発明による無線通信システムの構造を示す図面である。

【図2】実施形態による混雑状況を示す信号流れ図である。

【図3】実施形態による混雑制御を実施するための信号流れを示す図面である。

【図4】実施形態による混雑制御をするための信号流れを示す図面である。

【図5】実施形態による混雑制御をするためのデータの送受信を示す図面である。

【図6】実施形態による端末のハンドオーバーの際の混雑制御のための信号流れを示す図面である。

【図7】他の実施形態による端末のハンドオーバーの際の混雑制御のための信号流れを示す図面である。

【図8】また他の実施形態によるハンドオーバーの際の混雑制御のための信号流れを示す図面である。

【図9】実施形態によるパケットの性格に基づいて混雑制御のための信号流れを示す図面である。

【図10】他の実施形態によるパケットの性格に基づいて混雑制御のための信号流れを示す図面である。

【図11】他の実施形態によるパケットの性格に基づいて混雑制御のための信号流れを示す図面である。

【図12】また他の実施形態によるパケットの性格に基づいて混雑制御のための信号流れを示す図面である

【図13】実施形態の通信システムでアプリケーションの性格に基づいて混雑制御をするときの構造に対する図面である。

【図14】また他の実施形態によるアプリケーションの性格に基づいて混雑制御をするための信号流れとデータ処理を示す図面である。

【図15】本明細書の実施形態を説明するための基地局と端末の間の接続損失(ｃｏｎｎｅｃｔｉｏｎ ｌｏｓｓ)状況を示す図面である。

【図16】本明細書の実施形態を通じる接続損失の際の信号送受信方法を示すための図面である。

【図17】本明細書の実施形態によるコアネットワークノードの動作を示すフローチャートである。

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

【0029】

以下、本発明の実施形態を添付された図面を参照して詳細に説明する。

【0030】

実施形態を説明するにあたり、本発明が属する技術分野によく知られており、本発明と直接的に関連がない記述内容に対しては説明を省略する。これは不必要な説明を省略することによって本発明の要旨を明瞭にし、より明確に伝達するためである。

【0031】

同様の理由で添付図面において一部構成要素は誇張されたり省略されたり概略的に図示された。また、各構成要素の大きさは、実際大きさを全的に反映するのではない。各図面で同一又は対応する構成要素には同一参照番号を付した。

【0032】

以下で本発明の実施形態を説明するにあたり、関連する公知機能又は構成に対する具体的な説明が本発明の要旨を不必要にすることができると判定される場合にはその詳細な説明を省略する。

【0033】

また、本発明の実施形態を具体的に説明するにおいて、基本的な３ＧＰＰ(Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)ＬＴＥシステムを主な対象とするが、本発明の実施形態は類似の技術的背景及びシステム形態を持つその他の通信／コンピューターシステムにも本発明の範囲を大きく逸脱せず範囲で適用可能であり、これは本発明の技術分野で熟練された技術的知識を有する者の判定で可能であろう。例えば、ＬＴＥシステムを対象とした本技術は類似のシステム構造を持つＵＴＲＡＮ／ＧＥＲＡＮシステムでも適用されることができる。この場合、ＥＮＢ(ＲＡＮノード)は、ＲＮＣ／ＢＳＣに対置されることができ、 Ｓ−ＧＷは省略されたりＳＧＳＮ(Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ)に含まれ、 Ｐ−ＧＷはＧＧＳＮ(Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ)に対応されることができる。また、ＬＴＥシステムのベアラ概念はＵＴＲＡＮ／ＧＥＲＡＮシステムのＰＤＰ ｃｏｎｔｅｘｔに対応されることができる。

【0034】

また、実施形態でＲＡＮは限定された周波数内でユーザとデータを送受信しなければならない。ＲＡＮノードが管轄するセル内にユーザが多くなるとか、ユーザが送受信するトラフィックが多くなると、前記ＲＡＮに混雑状況が発生することができる。このような前記ＲＡＮ混雑状況(以下、Ｕｓｅｒ Ｐｌａｎｅ混雑状況と同様に使用)でユーザ体感サービス品質を劣らず、かつ、混雑状況に対応するため、ユーザ特性又はサービス応用(ａｐｐｌｉｃａｔｉｏｎ)を考慮した混雑制御が必要である。このような混雑状況に対応する動作を主体的に行うことができるシステム構成要素は、ユーザ端末、通信ネットワーク、及びトラフィックを送信する中、一つ以上の構成であることができる。

【0035】

もし、混雑状況に対するトラフィック管理をする主体がネットワーク内のＲＡＮ(前記ＬＴＥ 網の場合、Ｅ−ＵＴＲＡＮ又はｅＮｏｄｅＢ)であれば、前記ＲＡＮは混雑状況が極度に酷い場合、特定条件を満足するデータパケットに対する差等送信や極端的にデータパケットを送信せずドロップする動作を行うことができる。この時、もし課金のためにユーザ端末に対するパケッの送信情報(送信されたパケットの数や容量など)を収集するエンティティー(前記ＬＴＥ網の場合、一般的にＰ−ＧＷで遂行)が予めパケットに対する課金情報を生成したのにかかわらず、混雑状況によりＲＡＮで当該パケットが送信されることができないか、或は課金されたことに比べてサービスを碌に受けることができなかった場合が発生することができる。

【0036】

図２は、実施形態による混雑状況を示す信号流れ図である。

【0037】

図２を参考すれば、ユーザ端末２０２が混雑するＲＡＮ２１５でサービスを受けている状況を仮定することができる(段階２１５)。

【0038】

段階２１０でＧＷ２０６ノード(Ｓ−ＧＷ又はＰ−ＧＷであるが好ましくはＰ−ＧＷ)にダウンリンクパケットが到逹することができる。

【0039】

段階２２０で課金に係る情報を収集するＧＷ２０６ノード(普通Ｐ−ＧＷ)は、当該パケットに対する課金情報を生成することができる。

【0040】

段階２２５でＧＷ２０６ノードは、前記課金情報を生成したパケットをＲＡＮノード２０４へ送信することができる

【0041】

段階２３０でＲＡＮ２０４ノードは混雑状況でより前記ユーザ端末２０２に伝達しなければならないパケットを混雑により送信することができなく、ドロップする状況が発生することができる。

【0042】

前記段階２３０で予め課金されたパケットがドロップされる(ｄｒｏｐ)場合、段階２３５のようにユーザ端末に伝達の試しさえ成らなかったにもかかわらず課金になる状況が発生することができる。

【0043】

前記のような問題を解決するため、ＲＡＮ２０４ノードは自分が混雑制御を適用してもユーザ端末２０２に対する課金に問題が起こらない場合に限ぎり、パケットをドロップするなどの制御を適用することができる。

【0044】

図３は、実施形態による混雑制御を実施するための信号流れを示す図面である。

【0045】

図３を参考すれば、ユーザ加入情報データベース(例えば、ＨＳＳ３０６)はユーザ端末に適用する課金形態に対する情報を記憶している途中、コアネットワークノード(例えば、ＭＭＥ３０４)にユーザ加入情報を伝達するとき、これを共に伝達することができる。もし、必要な場合、コアネットワークノードはＲＡＮ３０２ノードに伝達するユーザ情報(ＵＥ ｃｏｎｔｅｘｔ)の一部で当該課金形態の関連情報を含ませることができる。前記ユーザ情報を受信したＲＡＮ３０２ノードは、混雑状況でユーザ端末の課金形態がパケットを伝達しなくドロップする場合にも問題がないとき(例えば、Ｆｌａｔ課金や定額制、又は無制限料金制、又は網事業者とユーザの設定によるパケットをドロップすることが許容された場合など)の場合にパケットに対するｇａｔｉｎｇ(パケットを送信せずドロップすること)動作又は差等送信を適用することができる。前記動作は単純にユーザ加入情報にデータパケットを網からユーザ端末まで伝達せずドロップするのが許容されるのか否かを示す情報を含み、この情報をＲＡＮノードまで伝達して許容された場合にだけパケットをドロップする動作を行うことに変更されることもできる。課金の形態やパケットのドロップを許容するか否かは、ユーザ別(ｐｅｒ ＵＥ)又はサービス別に区別するのが可能である。前記サービス別に区別されることの一例としては、ＰＤＮ接続別(ｐｅｒ ＡＰＮ)及びＢｅａｒｅｒ別(ｐｅｒ ＥＰＳ ｂｅａｒｅｒ)うちの一つ以上に区別することを含むことができる。例えば、もしユーザ端末が２つのＥＰＳ ｂｅａｒｅｒを生成したが、加入情報サーバーからＲＡＮノードに伝達した加入情報によって一つのＥＰＳ ｂｅａｒｅｒに対してだけパケットのドロップすることが許容されたり課金形態がパケットのドロップすることによる問題がない場合、ＲＡＮノードは当該ＥＰＳ ｂｅａｒｅｒに対してだけｇａｔｉｎｇ(パケットのドロップ)を適用することができる。

【0046】

図３を参照すれば、段階３１０でＨＳＳ３０６は、ＭＭＥ３０４に加入情報を伝達する時(Ｕｐｄａｔｅ Ｌｏｃａｔｉｏｎ Ａｃｋ又はＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎメッセージ)ｃｈａｒｇｉｎｇ ｔｙｐｅ又はｐａｃｋｅｔ ｄｒｏｐが許容されるのか否かを示す情報を含んで伝達することができる。実施形態によってＣｈａｒｇｉｎｇ ｔｙｐｅはユーザ端末に適用される課金の形態を含むことができる。前記課金の形態は、ｆｌａｔ ｃｈａｒｇｉｎｇ、ｏｎｌｉｎｅ ｃｈａｒｇｉｎｇ、ｏｆｆｌｉｎｅ ｃｈａｒｇｉｎｇ、ｕｎｌｉｍｉｔｅｄ ｄａｔａ ｐｌａｎ、ｖｏｌｕｍｅ ｂａｓｅｄ ｃｈａｒｇｉｎｇなどを区別することができる識別子を含むことができる。これを受信したＭＭＥ３０４はこれを記憶することができる。

【0047】

ＭＭＥ３０４は、前記記憶されたユーザ情報を必要によりＲＡＮ３０２ノードで送信することができる。このようにＲＡＮ３０２ノードで前記ユーザ情報を送信することはＲＡＮ３０２ノードから混雑があることを通知する情報が受信された場合を含むことができる。

【0048】

段階３１５でＲＡＮ３０２ノードは混雑が起きたことを示す情報を含むＭＭＥ３０４に通知することができる。

【0049】

段階３２０でＭＭＥ３０４は、段階３１５で受信したメッセージに基づいて前記記憶されたユーザ情報及びパケットのｄｒｏｐが可能であるか否かを含む情報をＲＡＮ３０２に通知することができるのか判定することができる。前記判定は、予め設定されたユーザ識別子又は網事業者の設定によって決定されることができる。

【0050】

段階３２５で前記記憶されたユーザ情報及びパケットのｄｒｏｐが可能であるか否かを含む情報を送信可能であると判定したＭＭＥ３０４は、前記記憶されたユーザ情報及びパケットのｄｒｏｐが可能であるか否かを含む情報をＲＡＮ３０２ノードへ送信することができる。実施形態によって前記送信方法は、前記情報をユーザ端末に対するｃｏｎｔｅｘｔに含んで(Ｓ１―AP ｉｎｉｔｉａｌ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｒｅｑｕｅｓｔ メッセージに含み)ＲＡＮ ノードに伝達することができる。ＲＡＮ３０２ノードは、前記受信したメッセージを記憶することができる。

【0051】

段階３３０でＲＡＮ３０２ノードは、混雑状況で、もしデータパケットをドロップしても問題ない課金形態(Ｆｌａｔ ｃｈａｒｇｉｎｇ、ｕｎｌｉｍｉｔｅｄ ｃｈａｒｇｉｎｇ ｐｌａｎ など)を持つとか、加入情報によってパケットのドロップすることが許容されるユーザ端末にだけパケットをドロップする動作を適用することができる。

【0052】

実施形態で、もし、前記のような動作をＰＤＮ接続別(ｐｅｒ ＡＰＮ)又はベアラ別(ｐｅｒ ＥＰＳ ｂｅａｒｅｒ)で適用する場合には、課金形態情報やパケットのドロップを許容する否かＰＤＮ接続別又はベアラ別で区分されて伝達することができる。

【0053】

また、他の実施形態でユーザ情報をＨＳＳ３０６がＰ−ＧＷで伝達することができる。実施形態によって前記ユーザ情報はＳＰＲがＰ−ＧＷへ伝達することができる。もし、ＨＳＳ又は ＳＰＲがＰ−ＧＷと直接接続を持たない場合、当該ユーザ加入情報はＨＳＳ又はＳＰＲがＰＣＲＦに伝達し、ＰＣＲＦがＰ−ＧＷを制御するために送信するＰＣＣ規則又はＡＤＣ規則の一部へ伝達することもできる。

【0054】

前記ユーザ情報はパケットをドロップするのに判定要素として用いられることができる情報を含むことができる。前記ユーザ情報は図３の実施形態を説明するために用いた情報を含むことができる。

【0055】

前記ユーザ情報を受信したＰ−ＧＷは前記ユーザ情報を記憶し、前記ユーザ情報に基づいてＲＡＮノードが混雑制御の際、判定することができる情報を前記パケットに含ませて送信することができる。実施形態によって前記混雑制御の際、判定することができる情報はパケットをドロップすることが可能な場合を表されるインジケーター又は送信優先順位を表される識別子を含むことができ、前記インジケーターと情報は前記送信されるデータパケットのＧＴＰ−Ｕヘッダーに含まれて送信されることができる。もし、Ｓ−ＧＷがＰ−ＧＷから受信したパケットを基地局まで伝達しなければならない場合、Ｓ−ＧＷはＧＴＰ−Ｕヘッダーに含まれた前記情報を、基地局へ伝達するパケットのＧＴＰ−Ｕヘッダーにさらに挿入して伝達する過程を行うことができる。

【0056】

前記基地局は混雑制御のためにパケットをドロップする場合、ドロップするパケットを検査して前記インジケーターがパケットをドロップできると表される場合、前記パケットをドロップすることができる。また前記インジケーターはパケットをドロップするとき、判定することができる優先順位を含むことができる。図４は、実施形態による混雑制御をするための信号流れを示す図面である。

【0057】

図４を参照して他の実施形態で混雑制御の際の課金問題を解決するため、送信されたパケットの送信成功であるか否かに基づいて課金するか否かを判定する方法を提案することができる。

【0058】

コアネットワークでダウンリンクパケットをＲＡＮ４０２ノードまで伝達するＧＷノード４０６、４０８は、パケットを伝達するとき、手順番号(Ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ、ＳＮ)を付して伝達することができる。ＲＡＮ４０２ノードは当該パケットに対する送信であるか否かを通知する情報をさらにＧＷ４０６、４０８ノードに通知することである。もし、パケットが多くのノードを経てＲＡＮ４０２ノードまで伝達する場合、中間ホップノードは受信したパケットと送信したパケットのＳＮマッピング情報を憶えているから、送信可否情報を伝達するときに対応されるパケットに対するＳＮに変更して伝達する。課金情報を生成するノードまでこの情報が伝達すれば、パケットに対する実際送信するか否かによって課金情報を生成したり修正することができる。実施形態によってこのような動作は、特定のＰＤＮ接続やＥＰＳ ｂｅａｒｅｒに対してだけ適用されることもできる。

【0059】

段階４１０でＲＡＮ４０２ノードは必要な場合(例えば、混雑制御を開始した場合)、自分に伝達するデータパケットに対してＳＮを付けて送信するのをリクエストするメッセージをＭＭＥ４０４に伝達することができる。ＲＡＮ４０２ノードの前記リクエストは特定のベアラに対してリクエストしたりベアラと関係せずリクエストすることもできる。

【0060】

段階４１５でＭＭＥ４０４は前記リクエストを受信することを基づいて、Ｓ−ＧＷ４０６にＳＮを付けて送信するのをリクエストするメッセージを送信することができる。実施形態によって前記リクエストメッセージをｍｏｄｉｆｙ ｂｅａｒｅｒ ｒｅｑｕｅｓｔメッセージに以後に送信するＧＴＰ―Ｕパケットの場合、ヘッダーにＳＮを必ず記入することをリクエストする情報を含むことができる。このようなリクエストは、前述したようにベアラ別でなることもできる。また、Ｓ−ＧＷ４０６は前記リクエストに基づいて送信するパケットのＳＮマッピングテーブルを記憶することができる。したがって、Ｓ−ＧＷ４０６はＰ−ＧＷ４０８から受信したパケットと、基地局４０２へ送信したパケットのＳＮをマッピングすることができる

【0061】

段階４２０でＳ−ＧＷ４０６は、Ｐ−ＧＷ４０８にＳＮを付けて送信することをリクエストするメッセージを送信することができる。実施形態によって前記リクエストメッセージは送信するｍｏｄｉｆｙ ｂｅａｒｅｒ ｒｅｑｕｅｓｔメッセージに以後に送信するＧＴＰ−Ｕパケットの場合、ヘッダーにＳＮを必ず記入することをリクエストする情報を含むことができる。このようなリクエストは、前述したようにｂｅａｒｅｒ別で成ることもできる。

【0062】

段階４２５でこれを受信したＰ−ＧＷ４０８は、送信されるパケットのＳＮを用いなければならないことを(ｂｅａｒｅｒ別でリクエストされた場合、どんなｂｅａｒｅｒが適用しなければならないか)記憶し、これに対する応答をＳ−ＧＷ４０６に伝達することができる。以後、各構成ノードはＳＮを用いることで設定されたユーザ(又はユーザのｂｅａｒｅｒ)のためのデータパケットはＧＴＰ−Ｕ ヘッダーにＳＮを記入して伝達する。また、段階４３０でＳ−ＧＷ４０６は伝達された前記応答メッセージをＭＭＥ４０４に送信することができる。

【0063】

図５は、実施形態による混雑制御をするためのデータの送受信を示す図面である。

【0064】

図５を参照すれば、データパケットの送信及び、課金制御は図５に示される方法のように成ることができる。また、実施形態は図４で設定によって送信するパケットに前記パケットを識別することができるＳＮを用いることができる。また、Ｓ−ＧＷ５０６は送信されるＳＮのマッピングテーブルを記憶することができる。

【0065】

段階５１０でＰ−ＧＷ５０６は予め設定された情報又は前記実施形態によってダウンリンクパケットに対してＳＮ情報を記録することができる。実施形態によって前記送信されるパケットにＳＮ情報はＧＴＰ−ＵヘッダーのＳＮフィールドを用いて記録することができる。

【0066】

段階５１５でＳ−ＧＷ５０４は前記受信されたパケットをＲＡＮ５０２ノードに伝達するとき、伝達するパケットのＳＮを記入して伝達することができる。好ましくはＳ−ＧＷ５０４は新たに付けるＧＴＰ−ＵヘッダーにＳＮフィールドを記入して伝達することができる。また、Ｓ−ＧＷ５０４は自分がＰ−ＧＷ５０６から受信したＧＴＰ−ＵパケットのＳＮとこれを自分がＲＡＮ５０２ノードに伝達したとき、用いたＧＴＰ−ＵパケットのＳＮに対するマッピング情報を記憶することができる。

【0067】

段階５２０でＲＡＮ５０２ノードは受信されたパケットを自分の混雑状況によって送信したりドロップすることができる。実施形態でＲＡＮ５０２ノードは混雑状況を制御するために前記パケットの送信の手順を調節することができる。

【0068】

段階５２５でＲＡＮ５０２ノードはパケットのＳＮと当該パケットの状態に対する情報をＳ−ＧＷ５０４に伝達する。前記パケットの状態は送信成功するか否か、送信失敗するか否か、ドロップするか否か、及びバッファーで留まった時間のうちのいずれか１つ以上を含むことができる。

【0069】

段階５３０でＳ−ＧＷ５０４は段階５２０で受信した情報に基づいてこの情報に含まれたＳＮと、予め記憶されたマッピング情報を用いてＰ−ＧＷ５０６から受信したＧＴＰ−ＵパケットのＳＮが分かることができる。

【0070】

段階５３５でＳ−ＧＷ５０４は段階５３０で分かったＳＮ情報に基づいてＰ−ＧＷ５０６にパケットの送信状態を伝達することができる。実施形態によってＳ−ＧＷ５０４はＰ−ＧＷ５０６にＳ５／S８(Ｓ−ＧＷ５０４とＰ−ＧＷ５０６間のインターフェース)パケットのＳＮと当該パケットの状態を含む情報をＰ−ＧＷ５０６に伝達する。

【0071】

段階５４０でＰ−ＧＷ５０４は前記情報を受信すると、課金情報を生成したり、予め生成された課金情報を修正するのに活用することができる。このようなＲＡＮ５０２ノードからＰ−ＧＷ５０６まで伝達するパケット送信情報は、別途のＧＴＰ−Ｃメッセージを用いて伝達することもでき、アップリンクパケットのＧＴＰ−Ｕヘッダーのｎｅｘｔ ｅｘｔｅｎｓｉｏｎ ｈｅａｄｅｒの形態で伝達されることもできる。 また、リアルタイム課金のために短い周期(例えば、毎パケットを受信するとき毎に)送信情報を送信することもでき、シグナリング負荷を減らすために一定の時間ごとに収集された情報を一度に送信することもできる。

【0072】

図６は、実施形態による端末のハンドオーバーの際の混雑制御のための信号流れを示す図面である。

【0073】

図６を参照すれば、ユーザ端末６０２が混雑が発生して混雑制御を適用中である第１基地局６０４と接続されてサービスを受けてから、第２基地局６０６に移動する場合、第２基地局は６０４では第１基地局６０２で送受信されていたユーザ端末６０２のデータパケットの状態が分かることができないから前記ユーザ端末６０２が持続的にサービスを受けることができない状況又は移動したユーザ端末６０２によって他のユーザのサービス品質が低下される問題が発生することができる。前記問題を解決するために、ハンドオーバーが発生したとき、第１基地局６０４は第２基地局６０６にユーザ端末６０２のパケットが混雑制御を受けることを通知し、第２基地局６０６はこれに基づいてパケット送信制御を行うことができる。

【0074】

一実施形態で、もしユーザ端末６０２が混雑する第１基地局６０４で混雑しない第２基地局６０６へハンドオーバーした場合、パケット送信制御は前記ユーザ端末６０２に対するｓｔａｒｖａｔｉｏｎを緩和するために同じ送信優先権を持つ他のユーザのトラフィックより、先ず送信することであることができる。

【0075】

他の実施形態で、もしユーザ端末６０２が混雑する第１基地局６０４で混雑する第２基地局６０６へハンドオーバーした場合、パケット送信制御は予め混雑制御を受けていたユーザ端末６０２に対する送信優先順位を続き低めることによって他のユーザ端末に対するサービス品質を低めないこともある。

【0076】

段階６１０で端末６０２は通信状態を測定した測定報告情報を第１基地局６０４へ伝達することができる。前記測定報告情報はハンドオーバーであるか否かを判定することができる情報を含むことができる。

【0077】

段階６１５で第１基地局６０４は前記送信された測定報告情報に基づいてハンドオーバーであるか否かを決定する。実施形態で第１基地局６０４は第２基地局６０６でハンドオーバーを決定することができる。ハンドオーバーが発生すれば、第１基地局６０４は第２基地局６０６に送信するｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔメッセージにユーザ端末が混雑制御を受けていたのか示す情報、どんな種類のスケジューリング政策が適用されていたのか、非優先ユーザであるか否か、及び当該ユーザ端末の加入レベル(例えば、ゴールド／シルバー／ブロンズメンバーシップユーザーなど)、及び課金方法(例えば、無制限料金制、ｆｌａｔ料金制、数／量に基づく課金適用対象など) のうちのいずれか１つ以上の情報を含むことができる。第２基地局６０６は前記受信した情報に基づいて以後の段階で混雑制御をするとき、前記情報に基づいて混雑制御を行うことができる。また、実施形態でこれを受信した第２基地局６０６はこの情報を記憶していてから用いる。特に、ユーザ端末６０２が受けていた混雑制御に係る情報(例えば、混雑制御適用するか否かや混雑制御適用レベルなど)は第１基地局６０４からハンドオーバー過程の中にフォワーディングされたデータトラフィックを送信するとき、送信優先順位を高めたり低めるか否かを決定するとき、用いることができる。又は、当該情報は第２基地局にＲＡＮ混雑が発生したとき、混雑制御を適用するのに用いられることもできる。実施形態で非優先ユーザ(Ｄｅ−ｐｒｉｏｒｉｔｉｚｅｄ ｕｓｅｒ)はネットワークによって混雑制御を受ける端末のユーザを含むことができる。

【0078】

段階６２０で第１基地局６０４及び第２基地局６０６の間にハンドオーバー手続きが行われ、段階６２５で第１基地局６０４は第２基地局でハンドオーバーに必要なデータを送信することができる。

【0079】

段階６３０で第２基地局６０６は第１基地局６２５から受信した前記情報に基づいて送信の優先順位を決定することによって混雑制御を行うことができる。

【0080】

段階６３５で第２基地局６０６はユーザ端末６０２にデータを送信することができる。実施形態によって混雑状況で前記段階６３０で決定された優先順位に基づいて混雑制御を行うことができる。

【0081】

図７は他の実施形態による端末のハンドオーバーの際の混雑制御のための信号流れを示す図面である。

【0082】

図７を参考すれば、段階７１０で端末７０２は通信状態を測定した測定報告情報を第１基地局７０４へ伝達することができる。前記測定報告情報はハンドオーバーであるか否かを判定することができる情報を含むことができる。

【0083】

段階７１５で第１基地局７０４は前記送信された測定報告情報に基づいてハンドオーバーであるか否かを決定する。実施形態で第１基地局７０４は第２基地局７０６でハンドオーバーを決定することができる。第１基地局７０４は第２基地局７０６でハンドオーバーできる。

【0084】

段階７２０で第１基地局７０４は第２基地局７０６にユーザ端末７０２の混雑制御に係る情報を含むメッセージを伝達することができる。実施形態で第１基地局７０４は第２基地局７０６に送信するＳＮ ｓｔａｔｕｓ ｔｒａｎｓｆｅｒに各データパケット別の送信差等を適用するか否かや、基地局のバッファーで留まった時間などに対する情報を含んで送信することができる。第１基地局７０４は制御メッセージに混雑制御情報を含ませて第２基地局７０６へ送信することができる。

【0085】

段階７２５で第１基地局７０４は第２基地局７０６にハンドオーバーに必要な情報を含むデータを送信することができる。

【0086】

段階７３０で第２基地局７０６は第１基地局７０４から受信した情報を記憶し、これに基づいて混雑制御を行うのに用いることができる。実施形態によって第１基地局７０４からハンドオーバー過程のうちにフォワーディングされたデータトラフィックを送信するとき、送信優先順位を高めたり低めるのか否かを決定するときに用いることができる。他の実施形態を挙げると、第２基地局７０６はバッファーで留まった時間が１００ms 以上のパケットは優先的に送信することと同様の方法を適用することができる。

【0087】

図８は、また他の実施形態によるハンドオーバーの際の混雑制御のための信号流れを示す図面である。

【0088】

図８で段階８１０及び８１５の手続きは図７の段階７１０及び７１５の手続きにそれぞれ対応することができる。

【0089】

図８を参照すれば、段階８２０でハンドオーバーが発生すれば、第１基地局８０４は第２基地局８０６にフォワーディングするデータパケットのＰＤＣＰヘッダーの新しいフィールドを用いてパケット別で送信差等を適用するか否かや、基地局のバッファーで留まった時間などに対する情報を含む送信することができる。

【0090】

段階８２５でこれを受信した第２基地局８０６は前記情報を記憶することができる。以後、第１基地局８０４からハンドオーバー過程のうちにフォワーディングされたデータトラフィックをユーザ端末８０２に送信するとき、送信優先順位を高めたり低めるのか否かを決定するときに用いることができる。例えば、バッファーで留まった時間が１００ms 以上のパケットは優先的に送信することと同様の方法を適用することができる。

【0091】

図６乃至８で各基地局の間に送信される混雑制御に関する情報は互いに連関されることができ、各実施形態で他の実施形態の関連情報を借用して用いることができる。

【0092】

図９は、実施形態によるパケットの性格に基づいて混雑制御のための信号流れを示す図面である。

【0093】

図９を参考すれば、現在ユーザ端末９０２が用いるトラフィックのうちに多い部分はユーザの直接的な相互作用(ｉｎｔｅｒａｃｔｉｏｎ) 無しに発生するものである。例えば、ユーザはユーザ端末９０２の画面をオンして直接用いていないが、端末９０２で実行中の応用がｂａｃｋｇｒｏｕｎｄで送受信するデータによってトラフィックが発生することができる。このようなｂａｃｋｇｒｏｕｎｄトラフィックはユーザの意図と関係せず送受信されるから、混雑状況で優先的に伝達する必要がない。実施形態でユーザと直接的な相互作用があるデータをａｔｔｅｎｄｅｄ(注意する)データと言え、ユーザと直接的な相互作用がないデータをｕｎａｔｔｅｎｄｅｄ(注意しない) データと言える。

【0094】

したがって、前記ユーザとｉｎｔｅｒａｃｔｉｏｎがないデータの場合、優先的に送信されなくても端末９０２のユーザが直接的に不便を認知することができなく、以後の再送信過程によってさらに送信されることができるから、混雑時に送信の優先順位を低めることができる。

【0095】

段階９１０で端末９０２は基地局９０４にＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔを送信することができる。段階９１５で基地局９０４は段階９１０で送信されたメッセージに基づいてＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｓｅｔｕｐ ｒｅｑｕｅｓｔを端末９０２に送信することができる。前記ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｓｅｔｕｐ ｒｅｑｕｅｓｔメッセージは基地局９０４が混雑状況にあることを通知するメッセージを含むことができる(ｃｏｎｇｅｓｔｉｏｎ)。

【0096】

段階９２０で端末９０２は基地局９０４にＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｃｏｍｐｌｅｔｅメッセージを伝達することができる。前記ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｃｏｍｐｌｅｔｅメッセージはａｔｔａｃｈ ｒｅｑｕｅｓｔ／ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ及びＮＡＳ ｍｅｓｓａｇｅのうちのいずれか１つ以上を含むことができる。また、段階９１５で基地局９０４から混雑を通知するメッセージを受信した端末９０２は送信をリクエストするデータのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを含む情報を前記ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｃｏｍｐｌｅｔｅに含ませて送信することができる。

【0097】

段階９２５で基地局９０４は前記送信を要求するデータがｕｎａｔｔｅｎｄｅｄであることを記憶することができる。送信を要求するデータがａｔｔｅｎｄｅｄの場合、既存の動作と類似に行われることができる。

【0098】

段階９３０で端末９０２は基地局９０４が混雑状況であることを記憶することができる。これによる送信でデータを表示するか否かを検出したり、以後の段階で端末の送信するデータがａｔｔｅｎｄｅｄに変更される場合、基地局にメッセージを送信することができる。

【0099】

段階９３５で端末９０２、基地局９０４及びＳ−ＧＷ／Ｐ−ＧＷ９０６の間にＡｔｔａｃｈ／ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ全体処理過程が完了することができる。

【0100】

段階９４０でＳ−ＧＷ／Ｐ−ＧＷ９０６、基地局９０４及び端末９０２でダウンリンクデータが送信されることができる。

【0101】

段階９４５で基地局９０４は基地局は該当の端末に対するトラフィックのうちでｎｏｎ−ＧＢＲベアラに属したものなどに対する送信優先順位を低めることができる。

【0102】

段階９５０乃至９６０の場合、端末９０２の送信するデータの変更がある場合を示し、段階 ９６５乃至段階９７５の場合、基地局９０４の混雑状況が解消された場合を示す。

【0103】

段階９５０で端末９０２は送信するデータのａｔｔｅｎｄａｎｃｅ変更を検出することができる。実施形態によって前記変更はユーザの入力によって送受信するデータの発生及び端末９０２の表示部がオンした場合のうち、１つ以上を含むことができる。

【0104】

段階９５５で端末９０２は基地局９０４に端末が送信するデータの状態が変更されたことを示すメッセージを送信することができる。前記メッセージは基地局９０４が混雑状況を端末９０２に通知した場合にだけ送信されることができる。実施形態で端末９０２は基地局９０４にＲＲＣ ＵＥ Ｓｔａｔｕｓメッセージを介して送信するデータの状態がａｔｔｅｎｄｅｄされることを示す情報を送信することができる。

【0105】

段階９６０で基地局９０４は段階９５５で受信したメッセージに基づいてｕｎａｔｔｅｎｄｅｄ状態をａｔｔｅｎｄｅｄに変更することができる。また、実施形態によって前記メッセージを受信した基地局９０４はｎｏｎ−ＧＢＲトラフィックに対して送信優先順位をこれ以上低めない。

【0106】

段階９６５で基地局の混雑状況が解消されることができる。この場合、基地局９０４はｎｏｎ−ＧＢＲベアラ送信に対して優先順位を低めるスケジューリングを中断することができる。

【0107】

段階９７０で基地局９０４は端末９０２に混雑状況が解消されたことを示すメッセージを伝達することができる。実施形態によって前記メッセージはＲＲＣ ｅＮＢ ｓｔａｔｕｓメッセージに含まれて伝達することができる。

【0108】

段階９７５で端末９０２は基地局９０４が混雑状況が解消されたことを記憶することができる。

【0109】

実施形態で、ユーザ端末９０２はＲＡＮ ｃｏｎｇｅｓｔｉｏｎ状態でだけａｔｔｅｎｄｅｄ(ユーザが意図する)／ｕｎａｔｔｅｎｄｅｄ(ユーザが意図しない) 状態変化を通知する。ユーザ端末がａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを決定することは事業者が設定したプログラム以外のプログラムが実行中であるときや、ユーザ端末のｓｃｒｅｅｎのオフ状態でデータが発生したときである。ユーザ端末９０２はＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｓｅｔｕｐ ｒｅｑｕｅｓｔメッセージを介して基地局９０４からＲＡＮにｃｏｎｇｅｓｔｉｏｎが発生したことを認知し、ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｃｏｍｐｌｅｔｅ メッセージに端末９０２ａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ状態を含んで送信する。

【0110】

この過程でユーザ端末９０２は基地局９０４が混雑するのか否かを記憶し、基地局９０４はユーザがｕｎａｔｔｅｎｄｅｄ状態であるか否かを記憶する。もし、ユーザ端末９０２がｕｎａｔｔｅｎｄｅｄであることを通知した場合にダウンリンクデータが到逹すると、基地局９０４は該当の端末に対するトラフィックのうちのｎｏｎ−ＧＢＲベアラに属したものなどに対する送信優先順位を低めることができる。もし、ユーザ端末がａｔｔｅｎｄｅｄ状態に変更されたが、相変らず基地局９０４が混雑すると、ユーザ端末９０２は状態変更をＲＲＣ ＵＥ ｓｔａｔｕｓメッセージを介して伝達する。これを受信した基地局はｎｏｎ−ＧＢＲトラフィックに対して送信優先順位をこれ以上低めない。一方、もし、基地局９０４の混雑が解消された場合は、ユーザ端末９０２がｕｎａｔｔｅｎｄｅｄと状態を通知してもｎｏｎ−ＧＢＲトラフィックに対する送信優先順位を低めなく、基地局９０４がこれ以上の混雑しないことをＲＲＣ ｅＮＢ ｓｔａｔｕｓメッセージを介してユーザ端末９０２に通知することができる。ユーザ端末９０２は基地局９０４の状態を記憶することができる。

【0111】

以上の実施形態はユーザ端末９０２がａｃｔｉｖｅした状態で動的にトラフィックを差等送信することができるメリットがあるが、多くのシグナリングが発生したり基地局のデータバッファーのオーバーフロー(ｏｖｅｒｆｌｏｗ)が発生する余地がある。

【0112】

図１０は、他の実施形態によるパケットの性格に基づいて混雑制御のための信号流れを示す図面である。

【0113】

図１０を参照すれば、本発明のまた他の実施形態ではユーザ端末１００２のａｔｔｅｎｄｅｄであるか否かをｃｏｎｇｅｓｔｉｏｎ状況でＰ−ＧＷ１００６まで送信されるパケット(好ましくはＧＴＰ−Ｕヘッダー)を用いて通知する方案を提案することができる。このために、ｕｐｌｉｎｋ ｄａｔａがあればそのデータのヘッダーを用い、若しくはダミー(ｄｕｍｍｙ)パケットを作って送信する。この場合、ＧＴＰ−Ｕヘッダーにはパケットがｄｕｍｍｙであることを通知する情報と共にａｔｔｅｎｄｅｄするか否かを含むことができる。

【0114】

段階１０１０及び段階１０１５は図９の段階９１０及び９１５にそれぞれ対応して類似に進行されることができる。

【0115】

段階１０１５でユーザ端末１００２はＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｓｅｔｕｐ ｒｅｑｕｅｓｔ メッセージを介して基地局１００４からＲＡＮにｃｏｎｇｅｓｔｉｏｎが発生したことを認知し、段階１０２０で端末１００２は注意(ａｔｔｅｎｄａｎｃｅ)を確認することができる。

【0116】

段階１０２５は、図９の段階９２０に対応して類似に成ることができる。端末１００２は実施形態でＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｃｏｍｐｌｅｔｅメッセージに自分のａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ状態を含んで送信することができる。

【0117】

段階１０３５で基地局１００４は端末のａｔｔｅｎｄａｎｃｅ状況を記憶することができる。
実施形態で基地局１００４は端末がｕｎａｔｔｅｎｄｅｄ状態でデータを送受信していることを記憶することができる。
段階１０３５で端末１００２は基地局１００４が混雑状況であることを記憶することができる。

【0118】

段階１０４０で端末１００２、基地局１００４及びＳ−ＧＷ／Ｐ−ＧＷ１００６はＡｔｔａｃｈ／ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ全体過程を処理することができる。

【0119】

段階１０４５で基地局１００４はユーザ端末１００２から送信されるｎｏｎ−ＧＢＲアップ リンクパケットがあれば、これを用い、若しくはｄｕｍｍｙパケットを生成してユーザ端末１００２がａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを表示することができる。実施形態で好ましくは基地局１００４はＧＴＰ−Ｕヘッダーにユーザ端末１００２がａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを表示することができる。

【0120】

段階１０５０でユーザ端末１００２のａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを表示した情報はＳ−ＧＷとＰ−ＧＷ１００６まで同様の方法で伝達することができる。

【0121】

段階１０５５で、Ｓ−ＧＷ又はＰ−ＧＷ１００６は端末がｕｎａｔｔｅｎｄｅｄ状態にある場合、当該端末１００２に対する送信トラフィックの優先順位を低めることができる。実施形態でＳ−ＧＷ又はＰ−ＧＷ１００６は当該端末１００２がｕｎａｔｔｅｎｄｅｄ状態にある場合、端末１００２に対するｎｏｎ−ＧＢＲトラフィックの送信優先順位を低めることができる。

【0122】

段階１０６５乃至段階１０８０は端末１００２のａｔｔｅｎｄａｎｃｅが変更されたことを検出した場合、基地局１００４及びＳ−ＧＷ／Ｐ−ＧＷ１００６に伝達する実施形態に関する説明である。

【0123】

段階１０６５でユーザ端末１００２がａｔｔｅｎｄｅｄ状態に変更されたが、相変らず基地局１００４が混雑すれば、段階１０７０でユーザ端末１００２は状態変更をＲＲＣ ＵＥ ｓｔａｔｕｓメッセージを介して基地局１００４に伝達することができる。これを受信した基地局１００４は段階１０８０でＳ−ＧＷ／Ｐ−ＧＷ１００６に前述したようにＧＴＰ−Ｕヘッダーを用いてａｔｔｅｎｄｅｄで状態が変化したことを通知することができる。各情報を伝達するメッセージは実施形態によって他のメッセージが用いられることができる。

【0124】

段階１０８５乃至段階１０９６は基地局１００４の混雑が解消された場合に基地局１００４が各構成要素に情報を伝達することを示す方法である。

【0125】

段階１０８５で基地局１００４は混雑状況が解消されたか否かを判定することができる。さらに、基地局１００４は実施形態によってｕｎａｔｔｅｎｄｅｄされた端末にだけ混雑状況が解消されたことを示す情報を伝達することができる。しかし、他の実施形態ではすべての端末１００２に混雑状況が解消されたことを示す情報を伝達することができる。

【0126】

段階１０９０で基地局１００４はＳ−ＧＷ／Ｐ−ＧＷ１００６に基地局１００２が混雑状況で解消されたことを示す情報を伝達することができる。基地局１００２は前記情報をｄｕｍｍｙ ｄａｔａのヘッダーに含ませて伝達することができる。

【0127】

段階１０９２で基地局１００４は端末１００２に混雑状況が解消されたことを示す情報を伝達することができる。実施形態で基地局１００４は端末１００２にＲＲＣ ｅＮＢ ｓｔａｔｕｓメッセージを介してユーザ端末１００２に通知することができる。さらに、実施形態によって端末１００２はユーザ端末のｕｎａｔｔｅｎｄｅｄ状態と関係せずＧＴＰ−Ｕヘッダーを用いてユーザがａｔｔｅｎｄｅｄ状態と通知する。これを受信したＧＷノード１００６はｎｏｎ−ＧＢＲトラフィックに対する送信優先順位を低めないこともある。

【0128】

前記の実施形態は簡単で、かつａｃｔｉｖｅ状態のユーザ端末１００２に対して動的に送信差等を適用することができるというメリットがあるが、多くのシグナリングが生ずることができる。

【0129】

図１１は、他の実施形態によるパケットの性格に基づいて混雑制御のための信号流れを示す図面である。

【0130】

図１１を参考すれば、実施形態は基地局１１０４の混雑状態をｂｒｏａｄｃａｓｔして、端末１１０２は受信したｂｒｏａｄｃａｓｔ情報に基づいてａｔｔｅｎｄｅｄ状態変化を通知した決定する方法を提案する。

【0131】

段階１１１０でユーザ端末１１０２は、ＯＭＡ−ＤＭ１１０８サーバーを用いる方法を用いてｃｏｎｇｅｓｔｉｏｎ状況でａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを報告しなければならない対象ａｐｐｌｉｃａｔｉｏｎの種類又はＥＰＳ ｂｅａｒｅｒの ＱＣＩに対して設定されることができる。

【0132】

段階１１１５で端末１１０２、基地局１１０４及びＳ−ＧＷ／ＰＧＷ１１０６間にＡｔｔａｃｈ ｒｅｑｕｅｓｔ／ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔが処理されることができる。

【0133】

段階１１２０でユーザ端末１１０２は報告対象ａｐｐｌｉｃａｔｉｏｎからトラフィックが発生したり、報告対象ＱＣＩを持つｂｅａｒｅｒを持っている場合、混雑情報をｂｒｏａｄｃａｓｔするＳＩＢｎを周期的に受信することができる(段階１１２５)。端末１１０２は、前記受信したＳＩＢｎに基づいて端末のａｔｔｅｎｄａｎｃｅ状態を基地局に伝達することができる。

【0134】

もし、ＳＩＢｎで現在基地局１１０４が混雑すると通知した場合、段階１１３０でユーザ端末１１０２は自分のａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを把握し、もし端末１１０２のａｔｔｅｎｄａｎｃｅ状態が変更された場合、段階１１５０でこれを基地局１１０４に通知することができる。実施形態で端末１１０２はＲＲＣ ＵＥ ｓｔａｔｕｓメッセージを用いてａｔｔｅｎｄａｎｃｅ状態変更を基地局１１０４に通知することができる。

【0135】

以後、動作は前述した図９の実施形態と同様である。もし、図１０のようにＧＷノードでトラフィック制御をする場合、図１１の段階１１１５乃至段階１１４０は図１０の過程１０１０乃至１０５０に対置されることができる。ただ、実施形態で基地局１１０４の混雑状況解消の際には段階１１６５でＳＩＢｎを介して端末１１０２に混雑の解消するか否かを通知することができる。

【0136】

一方、前記ｂｒｏａｄｃａｓｔされたＲＡＮの混雑情報は、ユーザ端末１１０２で能動的に発生するデータ量を減らすことにも用いられることができる。このために基地局１１０４は現在混雑状態の程度を示す情報や、それとも現在対比減らさなければならないデータの量を示す情報を送信することができる。例えば、もしＳＩＢｎでｂｒｏａｄｃａｓｔされた混雑情報が現在対比２０％発生させるデータ量を減らすという場合、これを受信したユーザ端末１１０２は自分が発生させる、又は自分のリクエストで発生するデータの量を２０％減らす動作を行うことができる。

【0137】

実施形態の方法はＳＩＢを用いることによって効果をシグナリングを減らすことができる一方、放送リソースの一部が消耗することができる。

【0138】

図１２は、また他の実施形態によるパケットの性格に基づいて混雑制御のための信号流れを示す図面である。

【0139】

図１２を参照すれば、端末１２０２の介入無しに混雑状況で混雑制御のために用いられることができる方法を提案する。

【0140】

実施形態によれば ＰＧＷ１２０６はｃｏｎｇｅｓｔｉｏｎ状態情報とｇａｔｉｎｇ状態情報によってＤＬパケットをｄｒｏｐｐｉｎｇしたりｓｃｈｅｄｕｌｉｎｇ速度を調整することができる。

【0141】

段階１２１０で端末１２０２、基地局１２０４及びＳ−ＧＷ／Ｐ−ＧＷ１２０６の間にＡｔｔａｃｈ ｒｅｑｕｅｓｔ／ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔが処理されることができる。

【0142】

段階１２１５でＣｏｎｇｅｓｔｉｏｎ発生の際、基地局１２０４はＳＧＷ／ＰＧＷ１２０６に混雑状況を通知するメッセージを伝達することができる。実施形態で基地局１２０４はＧＴＰ−Ｕヘッダーを用いてｃｏｎｇｅｓｔｉｏｎ状態をＳＧＷ／ＰＧＷ１２０６に伝達することができる(段階１２２０)。

【0143】

これは以前の実施形態で基地局がゲートウェイ端に混雑状況を伝達する過程と類似に行われることができる。また、ＳＧＷは関連ヘッダーをＰＧＷでｒｅｌａｙすることができる。実施形態で基地局は混雑であるか否かをｄｕｍｍｙ ｄａｔａのヘッダーを用いてＳＧＷ／ＰＧＷ１２０６に送信することができる。

【0144】

段階１２２５で、もし混雑制御をセル単位に行う場合、ＰＧＷ１２０６を行って混雑したセル(ＥＣＧＩ)でサービスを受けるすべてのａｃｔｉｖｅ ｎｏｎ−ＧＢＲ ｂｅａｒｅｒを対象でＤＰＩ行って対象ｆｌｏｗ選定する。もし、特定端末１２０２だけ対象で適用する場合、ＰＧＷ１２０６は当該端末１２０２のすべてのａｃｔｉｖｅ ｎｏｎ−ＧＢＲ ｂｅａｒｅｒを対象でＤＰＩを行って対象ｆｌｏｗを選定する。ＰＧＷ１２０６はＤＰＩ結果に基づいて対象ｆｌｏｗのｍｉｎｉｍｕｍ ｂｉｔ ｒａｔｅを選定してＧＴＰ−ＵヘッダーでＤＬデータ送信のとき、基地局１２０４へ伝達する(段階１２３０)。

【0145】

段階１２３５乃至段階１２４０で基地局１２０４はＧＴＰ−Ｕヘッダーに含まれたｍｉｎｉｍｕｍ ｂｉｔ ｒａｔｅを基準でこれを満足するようにｓｃｈｅｄｕｌｉｎｇを行うことができる。

【0146】

実施形態で基地局１２０４がもし混雑がひど過ぎてリクエストされたｍｉｎｉｍｕｍ ｂｉｔ ｒａｔｅを満足させることができないときはＰＧＷ１２０６で当該ｆｌｏｗに対するｇａｔｅ ｃｌｏｓｅをリクエストすることができる(段階１２４５)。段階１２４５のリクエストを受信したＳ−ＧＷ／Ｐ−ＧＷ１２０６はｇａｔｉｎｇ ｃｌｏｓｅ要求記憶後の関連ｆｌｏｗのｐａｃｋｅｔがすべてｄｒｏｐｐｉｎｇできる。

【0147】

また、実施形態で基地局１２３５が前記 ｍｉｎｉｍｕｍ ｂｉｔ ｒａｔｅを満足させることができない場合、当該パケットがすべてｄｒｏｐできる(１２３５)。

【0148】

段階１２５５で基地局１２０４のｃｏｎｇｅｓｔｉｏｎ解消の際、基地局１２０４はＳ−ＧＷ／Ｐ−ＧＷ１２０６に混雑が解消されたことを示すメッセージを送信することができる。実施形態によって前記メッセージはこれをＧＴＰ−Ｕヘッダーを用いてＳ−ＧＷ／Ｐ−ＧＷ１２０６でｃｏｎｇｅｓｔｉｏｎ ｓｔｏｐ状態を伝達することができる(ＳＧＷは関連ヘッダーを ＰＧＷでｒｅｌａｙ)。もし、このような制御がセル単位で行われる場合、これを受信したＰＧＷ１２０６はｃｏｎｇｅｓｔｉｏｎ状態情報とｇａｔｉｎｇ ｃｌｏｓｅ中であるｆｌｏｗ別に状態情報を削除し、端末１２０２単位の場合、ＰＧＷ１２０６は該当端末のｆｌｏｗのｃｏｎｇｅｓｔｉｏｎ状態情報とｇａｔｉｎｇ ｃｌｏｓｅ状態情報を削除することができる(段階 １２６５)。

【0149】

図１３は、実施形態の通信システムでアプリケーションの性格に基づいて混雑制御のためのネットワーク構成を示す図面である。

【0150】

図１３を参照すれば、事業者ＩＰサービス(Ｏｐｅｒａｔｏｒ ＩＰ Ｓｅｒｖｉｃｅ)網のＵＰＣＯＮ政策サーバー(Ｕｓｅｒ Ｐｌａｎｅ ｃｏｎｇｅｓｔｉｏｎ ｐｏｌｉｃｙ ｓｅｒｖｅｒ)１３９０を含むことができる。前記ＵＰＣＯＮ政策サーバー１３９０はユーザ平面関連混雑制御のための政策を決定することができるサーバーとして実施形態のように前記事業者ＩＰサービス網に位置することができ、ＰＣＲＦ１３５０及びＨＳＳのうちの少なくとも一つに位置することもできる。また、実施形態によって前記ＵＰＣＯＮ政策サーバー１３９０はＡｃｃｅｓｓ ｎｅｔｗｏｒｋ ｄｉｓｃｏｖｅｒｙ ａｎｄ ｓｅｌｅｃｔｉｏｎ ｆｕｎｃｔｉｏｎ(ＡＮＤＳＦ)であることがある。実施形態によってＵＰＣＯＮ政策サーバー１３９０は混雑制御のための情報を他の通信エンティティーに伝達することができる。

【0151】

図１４は、また他の実施形態によるアプリケーションの性格に基づいて混雑制御をするための信号流れとデータ処理を示す図面である。

【0152】

図１４を参照すれば、図１４は図１３のように事業者ＩＰサービス網内にＵＰＯＣＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１３９０が存在してアプリケーションの性格に基づいて混雑制御を移動通信網で行うときの信号流れを示す。

【0153】

実施形態でＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３はオペレーターが設定したアプリケーション別にａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄに対する設定を記憶するサーバーとして、図面１３の構成図に記述されたように端末とデータ網を介して接続されるように事業者ＩＰサービス網内にｅｎｔｉｔｙ１３９０である。しかし、ＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３の位置は事業者ＩＰサービス網内で限定されない。

【0154】

実施形態で端末１４００は端末１４００内に記憶されたＵＰＣＯＮ Ｐｏｌｉｃｙ ｓｅｒｖｅｒ１４０３の情報を用いてＤＮＳ ｑｕｅｒｙを送信してＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３の住所を獲得したりＤＨＣＰ(Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ)Ｓｅｒｖｅｒで情報を要求してＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３の住所を獲得することができる。前記ＵＰＣＯＮ Ｐｏｌｉｃｙ ｓｅｒｖｅｒ１４０３の情報はＦＱＤＮ(ｆｕｌｌｙ ｑｕａｌｉｆｉｅｄ ｄｏｍａｉｎ ｎａｍｅ)を含むことができる。

【0155】

段階１４１０で端末１４００は前記ＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３の住所を用いてＰｏｌｉｃｙをリクエストするｒｅｑｕｅｓｔメッセージをＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３へ伝達する。前記ｒｅｑｕｅｓｔメッセージは、端末１４１０を識別することができるＩＤを含む。また、実施形態で前記Ｐｏｌｉｃｙは混雑制御に係る政策を決定する因子を含むことができる。また、実施形態によって前記ｒｅｑｕｅｓｔメッセージは端末１４１０で実行される１個以上のアプリケーションを識別することができるＩＤを追加で含むことができる。

【0156】

段階１４１１で前記１４１０のｒｅｑｕｅｓｔメッセージを受信したＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３は前記端末１４００のＩＤを確認する。さらに、ＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３事業者(ｏｐｅｒａｔｏｒ)が設定したアプリケーションＩＤ別にａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ設定を記憶して１４１０のｒｅｑｕｅｓｔに対する応答で端末１４００にＲｅｓｐｏｎｓｅ(応答)メッセージを伝達することができる。さらに、実施形態によってＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３は前記端末１４００のＩＤに基づいてローミング端末であるか否かを判定し、ローミングをどんな事業者が運営するかによって他のアプリケーションＩＤ別にａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ設定値を適用して応答を構成することができる。また、実施形態でＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３は前記受信した１個以上のアプリケーションＩＤに基づいてａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ設定を適用して応答を構成することができる。前記設定も端末にサービスを提供する網事業者に従って異なるように構成されることができる。

【0157】

実施形態によってＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３はユーザの使用パターン及びアプリケーションの特徴のうちの少なくとも一つに基づいてアプリケーション別にａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ設定を記憶することができ、段階１４１０のような端末１４００のリクエストがある場合、前記アプリケーションＩＤに対応するａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ設定リストを端末１４００に送信することができる。

【0158】

段階１４１２で前記ＵＰＣＯＮ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ１４０３の応答メッセージを受けた端末１４００は前記受信したメッセージに含まれた情報を記憶する。前記受信したメッセージに含まれた情報はアプリケーションＩＤリスト及び各アプリケーションＩＤのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを含むことができる。

【0159】

実施形態で段階１４１２以後の端末１４００は端末１４００で実行されるアプリケーションがデータを発生させると、前記１４１２で記憶した情報に基づいて前記データを発生させるアプリケーションがａｔｔｅｎｄｅｄと設定されているかｕｎａｔｔｅｎｄｅｄと設定されているかを確認することができる。

【0160】

段階１４１３で端末１４００は前記確認結果によって送信するデータに前記データを発生させたアプリケーションのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを含ませて基地局１４０１に送信することができる。実施形態によって前記アプリケーションのａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かは送信されるデータのヘッダーうちの一つ以上に含まれることができ、好ましくはＩＰ ｈｅａｄｅｒのｅｘｔｅｎｓｉｏｎ ｆｉｅｌｄ及びＰＤＣＰヘッダーのｅｘｔｅｎｓｉｏｎ ｆｉｅｌｄのうちの少なくとも一つにａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ表示拡張フィールドの値を設定して基地局１４０１に送信することができる。

【0161】

段階１４１４で端末１４００は前記段階１４１３で処理したデータを基地局１４０１へ送信することができる。

【0162】

段階１４１４で端末１４００は前記段階１４１３で処理したデータを基地局１４０１へ送信することができる。

【0163】

段階１４１５で前記段階１４１４で送信されたデータを受信した基地局１４０１は段階１４１３で端末１４００が設定した値を確認することができる。また、実施形態によって基地局１４０１は前記受信したデータの住所、ポート情報及びａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ設定のうちの少なくとも一つを記憶した後、ａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄ関連情報を除去する処理を行うことができる。

【0164】

実施形態によって前記受信したデータの住所はＩＰヘッダーに含まれることができ、前記受信したデータのソース(ｓｏｕｒｃｅ)住所及び前記受信したデータの目的(ｄｅｓｔｉｎａｔｉｏｎ)住所のうちの一つ以上を含むことができる。

【0165】

段階１２１６で基地局１４０１は、段階１２０５で処理したデータをＳＧＷ／ＰＧＷ１４０２に送信され、前記送信されたデータをＳＧＷ／ＰＧＷ１４０２が事業者網の外部へ送信することができる。

【0166】

段階１４１７ａでＳＧＷ／ＰＧＷ１４０２が端末１４００に送信されるデータを受信すれば段階１４１７ｂでＳＧＷ／ＰＧＷ１４０２は前記受信したデータを基地局１４０１へ送信することができる。

【0167】

段階１４１８で前記データを受信した基地局１４０１は現在状態が混雑(ｃｏｎｇｅｓｔｉｏｎ) 状態であるときは、段階１４１７ｂで受信したデータのＩＰヘッダーを検査する。実施形態によって前記混雑状態は前記受信したデータに含まれた情報又は基地局１４０１のデータ送受信量に基づいて決定することができる。実施形態で基地局１４０１は前記受信したデータのＩＰ検査するとき、前記段階１４１５で記憶した目的(ｄｅｓｔｉｎａｔｉｏｎ)住所と段階１４１７ｂで受信したデータのソース(ｓｏｕｒｃｅ)住所と比べて、前記段階１４１５で記憶したソース(ｓｏｕｒｃｅ)住所と１４１７bで受信したデータの目的(ｄｅｓｔｉｎａｔｉｏｎ)住所を比べる。また、基地局１４０１はポート番号も同じ方式で１４１５で記憶した目的(ｄｅｓｔｉｎａｔｉｏｎ)ポートを段階１４１７ｂで受信したソース(ｓｏｕｒｃｅ)ポートと比べ、１４１５で記憶したソースポート(ｓｏｕｒｃｅ ｐｏｒｔ)を段階１４１７ｂで受信した目的(ｄｅｓｔｉｎａｔｉｏｎ)ポートと比べる。前記比較過程は、実施形態によって少なくとも一つ以上の値の比較ができ、前記比較結果、その値が一致すれば、段階１４１５で当該データトラフィック(ｔｒａｆｆｉｃ)に対してａｔｔｅｎｄｅｄに記憶されたのかｕｎａｔｔｅｎｄｅｄに記憶されているかを確認する。前記確認過程は前記データトラフィックを発生させるアプリケーションＩＤを比べる段階を含むことができる。前記確認結果、前記アプリケーションに対してａｔｔｅｎｄｅｄに設定された場合の状態であれば基地局１４０１は該当のデータｔｒａｆｆｉｃの優先順位(ｐｒｉｏｒｉｔｙ) 調整無しに端末１４００へ送信する。前記確認結果、前記アプリケーションに対してＵｎａｔｔｅｎｄｅｄと設定された状態であれば基地局１４０１は当該データ ｔｒａｆｆｉｃの ｐｒｉｏｒｉｔｙを低くスケジューリングを行うことができる。前記ｐｒｉｏｒｉｔｙを低く設定する段階は前記データｔｒａｆｆｉｃに含まれるパケットの送信を緩めたり、前記データｔｒａｆｆｉｃに含まれるパケットをドロップ(ｄｒｏｐ)する段階を含むことができる。

【0168】

段階１４１９で基地局１４０１は段階１４１８の結果に基づいて段階１４１７ｂで受信したデータを含むデータを端末１４００へ送信することができる。

【0169】

また、他の実施形態では段階１４１６で基地局１４０１はａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かを表される指示者を含むパケットを事業者網の外部で送信することができる。実施形態によって前記インジケーターはＩＰ ヘッダーに含まれることができ、前記パケットを受信したアプリケーションサーバーは前記ａｔｔｅｎｄｅｄ／ｕｎａｔｔｅｎｄｅｄであるか否かに基づいてデータ送信方法を決定することができる。

【0170】

一方、本明細書の実施形態は、事業者網でユーザ端末に不当な課金が発生することを緩和したり阻むにも用いられることができる。

【0171】

より具体的に、ユーザ端末のデータに対する不正確な課金はユーザ端末が一時的にシステムと通信することができない場合にも発生することができる。一例としてユーザ端末が陰影地域に位置する場合、ＶｏＬＴＥやＣＳＦＢがサポートされない領域で音声コールが発生して一時的に２Ｇ／３Ｇ網に移動してＣＳサービスを用いる場合にはユーザ端末がネットワークからデータパケットを受信することができない。

【0172】

この場合、ユーザ端末がネットワークからデータパケットを受信することができないサービス不能状態が検出されてコアネットワークまで伝達するまでは時間がかかることができ、このようにサービス不能状態がコアネットワークまで伝達する間の基地局やコアネットワークノードにパケットが持続的に流入される場合、課金情報は生成されたが基地局又はコアネットワークノードでパケットが損失されて端末に伝達することができない状況が発生することができる。

【0173】

図１５は、本明細書の実施形態を説明するための基地局と端末の間の接続損失(ｃｏｎｎｅｃｔｉｏｎ ｌｏｓｓ) 状況を示す図面である。

【0174】

図１５を参照すれば、実施形態で端末１５０２、基地局１５０４、移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、 ＭＭＥ)１５０６、サービングゲートウェイ(Ｓｅｒｖｉｎｇ ＧａｔｅＷａｙ、ＳＧＷ)１５０８及びパケットネットワークゲートウェイ(Ｐａｃｋｅｔ ｎｅｔｗｏｒｋ ＧａｔｅＷａｙ、ＰＧＷ)１５１０はそれぞれ異なるエンティティーと信号を送受信できる。

【0175】

実施形態でユーザ端末１５０２は段階１５１５で接続状態となると、基地局１５０４からデータパケットを受信することができる。

【0176】

このとき、ダウンリンクデータパケットはＰＤＮ(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ)から生成されてＰＧＷ１５１０へ伝達し、段階１５１２でＰＧＷ１５１０は受信したデータパケットに対する課金情報を生成した後データパケットをＳＧＷ１５０８に伝達する。

【0177】

段階１５２０及び段階１５２５のうちの少なくとも一つで前記データパケットを受信したＳＧＷ１５０８はユーザ端末が接続モードであればデータパケットを接続された基地局１５０４に伝達する。実施形態で前記データパケットはＭＭＥ１５０６を介して基地局に伝達することができる。

【0178】

ところで、段階１５３０のようにユーザ端末１５０２は接続モードから陰影地域に抜けるとか、若しくは事業者網のＶｏＬＴＥやＣＳＦＢなど機能の未支援で音声サービスのために２Ｇ／３Ｇシステムに移動することができる。このような場合、ユーザ端末１５０２と基地局１５０４の間に段階１５３５のように接続損失(ｃｏｎｎｅｃｔｉｏｎ ｌｏｓｓ)が発生することができる。

【0179】

このとき、コアネットワークでユーザ端末１５０２がこれ以上の基地局１５０４とデータを送受信することができないことを検出するまでは時間が必要となるので、持続的にデータパケットがＰＧＷ１５１０からＳＧＷ１５０８、及び基地局１５０２に伝達することができる。もし、これによりＳＧＷ１５０８又は基地局１５０４にバッファーオーバーフローやパケット損失が発生すれば(段階１５４０又は段階１５４５)、端末１５０２ユーザは自分が受信することができなかったパケットに対して料金を払うべき状況が発生することができる。

【0180】

前記状況を緩和するために提案される本明細書の一実施形態では前述した実施形態と同様にユーザ端末１５０２がデータパケットをこれ以上受信することができない状況になれば(Ｒａｄｉｏ ｌｉｎｋ ｆａｉｌｕｒｅなどによるｉｄｌｅ ｍｏｄｅ感知)、これをＳＧＷ１５０８と ＰＧＷ１５１０を含むコアネットワークまで通知し、これ以上の課金情報が生成されたり、若しくは受信することができないデータパケットがＳＧＷ１５０８や基地局１５０４に伝達することを阻むことである。

【0181】

図１６は、本明細書の実施形態を通じる接続損失の際の信号送受信方法を示すための図面である。

【0182】

図１６を参照すれば、実施形態で端末１６０２、基地局１６０４、移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、 ＭＭＥ)１６０６、サービングゲートウェイ(Ｓｅｒｖｉｎｇ ＧａｔｅＷａｙ、ＳＧＷ)１６０８及びパケットネットワークゲートウェイ(Ｐａｃｋｅｔ ｎｅｔｗｏｒｋ ＧａｔｅＷａｙ、ＰＧＷ１６１０はそれぞれ異なるエンティティーと信号を送受信できる。
段階１６１５でユーザ端末１６０２は接続状態となると、基地局１６０４からデータパケットを受信することができる。

【0183】

このとき、ダウンリンクデータパケットはＰＤＮ(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ)から生成されてＰＧＷ１６１０へ伝達し、段階１６１２でＰＧＷ１６１０は受信したデータパケットに対する課金情報を生成した後、段階１６２０及び段階１６２５のうちの一つ以上で前記生成されたデータパケットをＳＧＷ１６０８に伝達し、これを受信したＳＧＷ１６０８はユーザ端末が接続モードであればデータパケットを接続された基地局１６０４に伝達する。実施形態で前記データパケットはＭＭＥ１６０６を介して基地局１６０４に伝達することができる。

【0184】

ところで、段階１６３０でユーザ端末１６０２は連結モードから陰影地域で抜けたり、若しくは事業者網のＶｏＬＴＥやＣＳＦＢなど機能の未支援で音声サービスのために２Ｇ／３Ｇシステムに移動することができる。このような場合、ユーザ端末１６０２と基地局１６０４の間に段階６３５のように接続損失(ｃｏｎｎｅｃｔｉｏｎ ｌｏｓｓ)が発生することができる。

【0185】

このとき、コアネットワークがユーザ端末１６０２がこれ以上の基地局１６０４とデータを送受信することができないことを検出するまでは時間が必要となるので、持続的にデータパケットがＰＧＷ１６１０からＳＧＷ１６０８、及び基地局１６０４に伝達することができる。

【0186】

このような場合、段階１６４０又は段階１６４５のようにＳＧＷ１６０８及び基地局１６０４のうちの少なくとも一つにバッファーオーバーフローやパケット損失が発生することができる。

【0187】

段階１６５０で基地局１６０４はユーザ端末１６０２との連結がこれ以上、有効ではないことを検出(この時には基地局が送信するダウンリンクパケットに対する受信応答がユーザ端末から一定時間以内に到逹しないとか、このような状況が何回以上繰り返された場合を通じて分かる)できる。

【0188】

このような場合、基地局１６０４は段階１６５５でユーザ端末１６０２がこれ以上の接続モードではないことを示す情報や、これ以上のユーザ端末１６０４に対するダウンリンク課金を行わないという情報中の一つ以上をＭＭＥ１６０６に伝達することができる。実施形態で前記メッセージはＳ１ ｒｅｌｅａｓｅリクエストメッセージを介してＭＭＥ１６０６に伝達することができる。

【0189】

ＭＭＥ１６０６はこのような情報を基地局から受信すると、段階１６６０でＭＭＥ１６０６はＳＧＷ１６０８に段階１６５５で受信した情報を含むメッセージを伝達することができ、この時にはｍｏｄｉｆｙ ｂｅａｒｅｒ ｒｅｑｕｅｓｔメッセージが用いられることができる。

【0190】

一方、ＳＧＷ１６０８はこのような情報を受信すると、段階１６６５でＳＧＷ１６０８はユーザ端末１６０２に対する接続がさらに有効である示す情報を受信する前まではこれ以上のデータパケットを送信しないこともあり、ＰＤＮ ｃｏｎｎｅｃｔｉｏｎ又はＥＰＳ ｂｅａｒｅｒ別に前記情報を含むメッセージをＰＧＷ１６１０に送信することができる。実施形態で前記メッセージはｍｏｄｉｆｙ ｂｅａｒｅｒ ｒｅｑｕｅｓｔなどのメッセージを介してＰＧＷ１６１０まで伝達することができる。この時、ＳＧＷ１６０８はユーザ端末がＰＤＮ ｃｏｎｎｅｃｔｉｏｎを持つすべてのＰＧＷ１６１０に前記情報を伝達することができる。

【0191】

段階１６７０でＰＧＷ１６１０は前記情報を受信すると、ユーザ端末１６０２に対するダウンリンクデータパケットに対する状態をＰａｕｓｅと変更し、課金を止めることができる。また、追加的なデータパケット損失を阻むためにＳＧＷ１６０８から別途のリクエストがある前までデータパケット送信を止めることができる。

【0192】

前記実施形態はユーザ端末１６０２に対する接続が有効ではなくなると、これを検出してコアネットワークに通知してこれ以上の追加的な課金間エラーやデータパケット損失が発生することを阻むのに用いられることができる。本明細書の一実施形態では、前記実施形態のようにデータパケット損失が発生して課金情報にエラー(すなわち、ユーザに送信をしないパケットに対しても課金される場合)が発生した場合、これを修正して課金情報の間のエラーを最小化されることができるようにする技術を提案する。

【0193】

実施形態で課金情報を生成するノード(例えば、ＰＧＷ)は、ユーザに伝達するダウンリンクパケットを検査(ｉｎｓｐｅｃｔｉｏｎ)し、どんなパケット識別子(例えば、ＴＣＰ ｓｅｑｕｅｎｃｅ 番号)を持つパケットがユーザ端末を向けて送信されたかを記憶し、ユーザ端末が送信する受信応答メッセージ(Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ)を検査し、どんなパケットがユーザ端末に成功的に伝達したかを確認する。もし、ユーザ端末を向けてデータパケットを送信したが、一定時間以内に受信応答メッセージが送信されないとか、前記実施形態によってユーザ端末の連結がこれ以上の有効ではない、若しくは課金を止めなければならないことを示す情報を受信すると、ＰＧＷはデータパケットが損失されたと判定して課金情報を修正することができる(すなわち、応答メッセージが検出されないパケットに対する課金は除く)。

【0194】

図１７は、本明細書の実施形態の実施形態によるコアネットワークノードの動作を示すフローチャートである。より具体的に図１７は課金情報を管理するコアネットワークノード(はい、ＰＧＷ)の動作を表されることができる。

【0195】

図１７を参照すれば、段階１７０５でＰＧＷはＰＤＮからデータパケットを受信することができる。

【0196】

段階１７１５で前記ＰＧＷはパケット検出(Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ)を用いて当該データパケットがどんなＴＣＰ ｓｅｓｓｉｏｎやＩＰ ｆｌｏｗに属するかを分かる。この時、このような過程を適用するか否かは、ＰＣＲＦを介して受信したＰＣＣ ｒｕｌｅに基づいたり、若しくはＳＧＷから受信したユーザｂｅａｒｅｒ情報を介して分かることもできる。ＰＧＷはこの過程を介してパケットが属したＴＣＰ ｓｅｅｓｉｏｎ／ＩＰ ｆｌｏｗ、及びＴＣＰの ｓｅｑｕｅｎｃｅ番号が分かり、課金情報を生成してｔｉｍｅｒを開始する。前記ｔｉｍｅｒ値は予め設定された値や可変的な設定により決定することができる。

【0197】

段階１７２０で前記ＰＧＷは前記Ｔｉｍｅｒ内に端末が送信したＴＣＰに対する受信確認(ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ)を送信したか判定することができる。実施形態で前記ＰＧＷはもしユーザ端末からアップリンク方向にパケットが受信された場合、同様にパケット検出を適用し、もしマッチングされると、どんなダウンリンクＴＣＰパケットに対して受信が完了したか(ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ)を把握することができる。例えば、ＰＧＷが検出したＴＣＰパケットのＳｅｑｕｅｎｃｅ番号が１０００番であり、ユーザ端末が同じＴＣＰ ｓｅｓｓｉｏｎへ送信したＴＣＰ ａｃｋパケットが１００１番を通知すると、これは１０００番までのｓｅｑｕｅｎｃｅ番号を持つＴＣＰパケットが成功的に受信されたことを表されることである。アップ／ダウンリンクのデータパケットが同じＩＰ ｆｌｏｗ又はＴＣＰ ｓｅｓｓｉｏｎに属するのか否かはＩＰ送受信住所とポート番号などを用いて分かる。

【0198】

もし、前記設定した時間内にダウンリンクＴＣＰパケットに対する送信が成功されたことを認知することができなかった場合は、段階１７３０で前記ＰＧＷはパケット損失が発生したと判定し、パケットに対する課金情報を修正したり削除し、送信されることができなかったパケットに対する課金が成らないようにする。

【0199】

実施形態でＴＣＰパケットの送信が成功的に成る場合、段階１７２５で前記ＰＧＷは課金情報が有効であることを判定して適用した課金データを維持することができる。

【0200】

本明細書の前述した実施形態で説明したユーザ端末に対する接続状態有効性であるか否か、若しくは課金止め情報が適用された場合、ＰＧＷはダウンリンクでデータパケットを送信してｔｉｍｅｒを開始するが、アップリンクパケット検査を介して成功するか否かが分からなく、まだｔｉｍｅｒが終わる前にＳＧＷからユーザ端末に対する接続が損失されたり、若しくは課金を止めるという情報を受信すると、同様にパケット損失が発生したと判定し、パケットに対する課金情報を修正したり削除し、送信されることができなかったパケットに対する課金がならないようにできる。

【0201】

前記実施形態では説明の便宜性のためにＴＣＰを用いる場合を利用したが、本実施形態の主な要旨は、他の種類のプロトコル(例えば、ＵＤＰやＲＴＰなど)を用いる場合にも適用されることができる。

【0202】

以上、実施形態で各構成要素は他の構成要素とデータを送受信できる送受信部及び前記送受信部を制御して前記送受信部を介して送受信されるデータに基づいて判定ができる制御部を含むことができる。

【0203】

本発明が属する技術分野の通常の知識を有する者は、本発明がその技術的思想や必須な特徴を変更しなくても他の具体的な形態で実施されることができるということを理解することができるでしょう。よって、以上で記述した実施形態はすべての面で例示的なことで限定的ではないことで理解すべきである。本発明の範囲は前記詳細な説明よりは後述する特許請求の範囲によって表され、特許請求の範囲の意味、範囲、及びその均等概念から導出されるすべての変更又は変形された形態が本発明の範囲に含まれることに解釈されなければならない。

【0204】

一方、本明細書及び図面には本発明の好ましい実施形態に対して開示したが、たとえ特定用語が用いられるが、これはただ本発明の記述内容を容易に説明して発明の理解を助けるための一般的な意味で用いられることであって、本発明の範囲を限定しようとするものではない。ここに開示された実施形態の外にも本発明の技術的思想に基づいた他の変形例が実施可能であるということは本発明が属する技術分野で通常の知識を有する者に自明なものである。

【符号の説明】

【0205】

１００ ＵＥ
１１０ ＥＮＢ
１２０ ＭＭＥ
１３０ ＧＷ
１５０ ＰＣＲＦ
１６０ ＧＷ
２０２ ユーザ端末
２０４ ＲＡＮ
２０６ ＧＷ
２１５ ＲＡＮ
３０２ ＲＡＮ
３０４ ＭＭＥ
３０６ ＨＳＳ
４０２ ＲＡＮ
４０４ ＭＭＥ
４０６ ＧＷ
４０８ ＧＷ
５０２ ＲＡＮ
５０４ ＧＷ
５０６ ＧＷ
６０２ ユーザ端末
６０４ 第１基地局
６０６ 第２基地局
７０２ ユーザ端末
７０４ 第１基地局
７０６ 第２基地局
８０２ ユーザ端末
８０４ 第１基地局
８０６ 第２基地局
９０２ ユーザ端末
９０４ 基地局
９０６ ＧＷ
１００２ ユーザ端末
１００４ 基地局
１００６ ＧＷ
１１０２ ユーザ端末
１１０４ 基地局
１１０６ ＰＧＷ
１２０２ 端末
１２０４ 基地局
１２０６ ＧＷ
１３５０ ＰＣＲＦ
１３９０ ＵＰＣＯＮ政策サーバー
１４００ 端末
１４０１ 基地局
１４０２ ＰＧＷ
１５０２ ユーザ端末
１５０４ 基地局
１５０６ ＭＭＥ
１５０８ ＳＧＷ
１５１０ ＰＧＷ
１６０２ ユーザ端末
１６０４ 基地局
１６０６ ＭＭＥ
１６０８ ＳＧＷ
１６１０ ＰＧＷ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】