JPWO2011039985A1 - パケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置 - Google Patents

パケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置 Download PDF

Info

Publication number
JPWO2011039985A1
JPWO2011039985A1 JP2011534061A JP2011534061A JPWO2011039985A1 JP WO2011039985 A1 JPWO2011039985 A1 JP WO2011039985A1 JP 2011534061 A JP2011534061 A JP 2011534061A JP 2011534061 A JP2011534061 A JP 2011534061A JP WO2011039985 A1 JPWO2011039985 A1 JP WO2011039985A1
Authority
JP
Japan
Prior art keywords
packet
bearer
mobile terminal
communication
message
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.)
Withdrawn
Application number
JP2011534061A
Other languages
English (en)
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 Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
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 Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JPWO2011039985A1 publication Critical patent/JPWO2011039985A1/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/1026—Media gateways at the edge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/30—Network data restoration; Network data reliability; Network data fault tolerance

Abstract

本発明は、ゲートウェイ装置におけるパケット廃棄情報をリアルタイムに通知することにより、移動端末における無駄な待ち時間（タイムアウト）を待つことなくパケットリカバリ処理を開始でき、通信品質並びに通信効率を向上させることができるパケット回復方法などを提供する技術が開示され、その技術によれば移動端末と移動端末の通信相手装置との間で送受信されるパケットのうち、移動端末と通信相手装置との通信経路上に配置された中間装置によって廃棄されたパケットの回復のためのパケット回復方法であって、中間装置が、パケットを廃棄した旨の廃棄通知メッセージの送信を必要とする通信フローの情報に基づいて廃棄通知メッセージを移動端末へ送信するステップと、移動端末が、廃棄通知メッセージに基づいて、廃棄されたパケットの再送を要求する再送要求メッセージを通相手信装置へ送信するステップとを有する。

Description

本発明は、パケット通信においてパケットロスが発生した際に迅速な復旧を行わせるためのパケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置に関する。
従来の移動通信システム、特に３ＧＰＰ規格に基づく移動通信システムでは、移動端末がコアネットワークを介して通信相手とパケット通信を行う際のデータパス（ここでは３ＧＰＰ規格に準じて特にベアラと呼ぶ）に設定する帯域割り当てに二通りの考え方があった。一つはＧＢＲ（Guaranteed Bit Rate）を適用するもので、これに基づくベアラをＧＢＲベアラと呼ぶ。もう一つはＧＢＲを適用しないもので、これに基づくベアラを非ＧＢＲ（あるいはｎｏｎ−ＧＢＲ）ベアラと呼ぶ。
ＧＢＲベアラは、ＱｏＳ保証が適用されるベアラであり、下記の非特許文献２に開示されるようなＱＣＩ（QoS Class Identifier）、ＧＢＲ（Guaranteed Bit Rate）、ＭＢＲ（Maximum Bit Rate）などの伝送遅延、パケットロス、伝送レートなどに関する保証値が設定される。ＱＣＩは、伝送優先度、伝送遅延バジェット、パケットロスバジェットなどについて定義された複数のＱｏＳプロファイルを識別するための識別子（ＩＤ）である。移動端末（UE）が送信／受信するパケットの中継を行うゲートウェイ（非特許文献２ではPDN-GWあるいはPGW（Packet Data Network Gateway）と呼ぶ）は、ＧＢＲやＭＢＲを超えるＵＥのトラフィックについてパケットの廃棄を行うことがある。
非ＧＢＲベアラは、部分的なＱｏＳ保証が適用されるベアラであり、非特許文献２に開示されるようなＱＣＩ、ＡＰＮ−ＡＭＢＲ（Per APN Aggregate Maximum Bit Rate）、ＵＥ−ＡＭＢＲ（per UE Aggregate Maximum Bit Rate）などの伝送遅延、パケットロス、ＡＰＮ／ＵＥ単位の伝送レートなどに関する保証値が設定される。ＧＢＲベアラにおけるＧＢＲの扱いと同様、ＰＧＷでは、ＡＰＮ−ＡＭＢＲあるいはＵＥ−ＡＭＢＲ（これらを総じてＡＭＢＲとよぶ）を超えるＵＥのトラフィックについてパケットの廃棄を行うことがある。
ＰＧＷでは、ＭＢＲやＡＭＢＲを超える流量のパケットを廃棄することがある。ＰＧＷによるパケット廃棄が生じると、送信ノードが当該パケットに対する受信Ａｃｋが未受信であることを再送タイマのタイムアウトをトリガとして検出したり、移動端末（受信側）がパケット受信タイマのタイムアウトをトリガとして再送要求を送信したりして、廃棄されたパケットの再送によりリカバリーを試みる。しかし、実際のパケット廃棄は、タイムアウトの検出より前に発生したものであり、移動端末やアプリケーションにとっては無駄な待ち時間を浪費して通信効率が著しく低下し、アプリケーションの利便性が低下するという問題があった。
下記の非特許文献１は、ＩＣＭＰ（Internet Control Message Protocol）到達不能メッセージ（ICMP unreachable message）を用いて、送信ノードにおけるＴＣＰ（Transmission Control Protocol）再送タイマの調整を行わせる方法について開示するものである。これを応用して、上記の問題を解決することができる。つまり、パケットが廃棄されたことをICMP到達不能メッセージを用いて送信ノードに通知して、再送要求処理を実行させることにより、パケット再送タイマのタイムアウトを待つことなく廃棄されたパケットを迅速に再送させることができる。
A. Zimmermann "Make TCP more Robust to Long Connectivity Disruptions", draft-zimmermann-tcp-lcd-01 July 2009 "GPRS enhancements for E-UTRAN access (Release9)", 3GPP TS23.401 v.9.1.0 June 2009 "The Addition of Explicit Congestion Notification (ECN) to IP", IETF RFC3168September 2001 "GPRS Tunnelling Protocol for Control plane (GTPv2-C) (Release8)", 3GPP TS29.274 v.8.2.0 June 2009
しかしながら、上記従来技術においては、ＩＣＭＰ到達不能メッセージを受信すると、該当する通信セッションを切断してしまうアプリケーションを搭載する通信ノードが既に流通しており、必ずしも意図した効果、すなわち迅速なパケットリカバリ処理（例えば再送処理）を促すという効果、が得られるとは限らない。こうした通信ノードは、例えばパソコンや携帯電話、その他の携帯端末、テレビやビデオレコーダなどのネット家電などであり、意図した効果を得るために、これらすべての通信ノードにＩＣＭＰ到達不能メッセージを受信しても通信セッションを切断しないように対応させたり、ＩＣＭＰ到達不能メッセージとは異なる同様の効果を得るための独自のメッセージに対応させたりすることは、莫大なコストや対応のための人的労力を伴うため、まったく現実的でない。また、パケットを廃棄した中間ノード（本発明ではゲートウェイ装置（ＰＧＷ）に相当）が、アドレス以外の情報で通信フローを識別している場合、中間ノードは、送信ノードのアドレスをパケットヘッダから抽出する必要があり、中間ノード（ＰＧＷ）の処理負荷を増大させることにもなる。
このように、世界中に既に存在するすべての通信ノードに上記機能の対応を期待するのは、必要となるコストや人的労力の点で、ほぼ不可能と考えてもよく、これらの送信ノードに頼ることなく、通信ノードが搭載する通信スタックやアプリケーションに既に実装されている再送メカニズムを利用して、無駄な再送待ち時間を浪費することなく、迅速に再送要求の送信やパケットリカバリ処理を開始させるために、パケット廃棄情報をリアルタイムに、かつ効率的に移動端末に通知できる方法が必要となる。ここで、移動端末は、所定の規格（例えば３ＧＰＰ）にもとづいて通信方法が規格化され、またオペレータ等によって管理されるものであり、上記課題を解決するための改修に伴う労力は、上記従来技術よりはるかに少ない。
本発明は、上記の問題点に鑑み、移動端末が登録したパケットフィルタ情報に基づいてゲートウェイ装置がパケット廃棄時の情報通知対象フローを決定し、ゲートウェイ装置が、決定したフローについてパケット廃棄通知を移動端末に送信する。これにより、実際にパケットが廃棄された時点でパケットの受信ノードである移動端末にそのことを通知し、移動端末がパケット送信ノードに対してリアルタイムに再送要求を送信することができるので、移動端末は無駄な再送待ち時間を消費することなく、通信効率を向上させることができるパケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置（ゲートウェイ装置）を提供することを目的とする。
上記目的を達成するために、本発明によれば、移動端末と前記移動端末の通信相手装置との間で送受信されるパケットのうち、前記移動端末と前記通信相手装置との通信経路上に配置された中間装置によって廃棄されたパケットを回復するためのパケット回復方法であって、前記中間装置が、パケットを廃棄したことを通知する廃棄通知メッセージの送信を必要とする通信フローの情報に基づいて前記廃棄通知メッセージを前記移動端末へ送信するステップと、前記移動端末が、前記廃棄通知メッセージに基づいて、廃棄された前記パケットの再送を要求する再送要求メッセージを前記通相手信装置へ送信するステップとを、有するパケット回復方法が提供される。この構成により、無駄な再送待ち時間を消費することなく、通信効率を向上させることができる。
また、本発明によれば、移動端末と、前記移動端末の通信相手装置と、前記移動端末と前記通信相手装置との通信経路上に配置された中間装置とを備え、廃棄されたパケットの回復を行うパケット回復システムであって、前記中間装置が、前記移動端末と前記通信相手装置との間で送受信されるパケットを廃棄した場合に、パケットを廃棄したことを示す廃棄通知メッセージの送信を必要とする通信フローの情報に基づいて前記廃棄通知メッセージを前記移動端末へ送信し、前記移動端末が、前記廃棄通知メッセージに基づいて、廃棄された前記パケットの再送を要求する再送要求メッセージを前記通信相手装置へ送信するパケット回復システムが提供される。この構成により、無駄な再送待ち時間を消費することなく、通信効率を向上させることができる。
また、本発明によれば、移動端末と前記移動端末の通信相手装置との間で送受信されるパケットのうち、前記移動端末と前記通信相手装置との通信経路上に配置された中間装置によって廃棄されたパケットの回復を行う前記移動端末であって、パケットを廃棄したことを通知する廃棄通知メッセージを前記中間装置から受信する受信手段と、受信した前記廃棄通知メッセージに基づいて、廃棄された前記パケットの再送を要求する再送要求メッセージを生成するメッセージ生成手段と、生成された前記再送要求メッセージを前記通信相手装置へ送信する送信手段とを、備える移動端末が提供される。この構成により、無駄な再送待ち時間を消費することなく、通信効率を向上させることができる。
また、本発明によれば、移動端末と前記移動端末の通信相手装置との通信経路上に配置され、前記移動端末と前記通信相手装置との間で送受信されるパケットを廃棄する中間装置であって、パケットを廃棄したことを通知する廃棄通知メッセージの送信を必要とする通信フローの情報に基づいて前記廃棄通知メッセージを生成するメッセージ生成手段と、生成された前記廃棄通知メッセージを前記移動端末へ送信する送信手段とを、備える中間装置が提供される。この構成により、無駄な再送待ち時間を消費することなく、通信効率を向上させることができる。
本発明のパケット回復方法、パケット回復システム、その方法で用いられる移動端末（ＵＥ）及び中間装置（ゲートウェイ装置：ＰＧＷ）は、ＰＧＷ２００が所定のＱｏＳ値を超える流量のパケットを廃棄する際に、廃棄パケットが対応付けられるベアラとそのベアラを保有するＵＥ１００を容易に特定できるので、ＰＧＷ２００の負荷を特に増加させることなく、パケット廃棄（パケット廃棄タイミング）をリアルタイムにＵＥ１００に通知して、ＵＥ１００が再送要求などのパケットリカバリ処理を実施することで通信効率を向上させることができる。また、ＵＥ１００が設定するＴＦＴを参照して、パケット廃棄通知の要否を確認することにより、ＵＥ１００が必要とする通信フローのパケット廃棄だけを通知することができ、コアネットワークやアクセスネットワークのトラフィックを無意味に増加させたり、ＵＥ１００やＰＧＷ２００自身の処理負荷を無意味に増加させたりすることなく、適した通信フローの状態をＵＥ１００に通知して、適正に再送制御処理を実施させることができる。
本発明の第１の実施の形態における通信システムの構成の一例を示す構成図 本発明の第１の実施の形態に係るパケット回復方法の一例を説明するためのシーケンスチャート 本発明の第１の実態の形態におけるパケットフィルタの構成の一例を示す構成図 本発明の第１、２の実態の形態におけるトラフィックフローテンプレート（ＴＦＴ）の構成の一例を示す構成図 本発明の第１の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の第１の実施の形態に係る移動端末における処理フローの一例を示すフローチャート 本発明の第１の実施の形態に係るゲートウェイ装置の構成の一例を示す構成図 本発明の第１の実施の形態に係るゲートウェイ装置における処理フローの一例を示すフローチャート 本発明の第２の実施の形態における通信システムの構成の一例を示す構成図 本発明の第２の実施の形態に係るベアラ解放回避方法の一例を説明するためのシーケンスチャート 本発明の第２の実施の形態におけるパケットフィルタの構成の一例を示す構成図 本発明の第２の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の第２の実施の形態に係る移動端末における処理フローの一例を示すフローチャート 本発明の第２の実施の形態に係るゲートウェイ装置の構成の一例を示す構成図 本発明の第２の実施の形態に係るゲートウェイ装置における処理フローの一例を示すフローチャート 本発明の第３の実施の形態における通信システムの構成の一例を示す構成図 本発明の第３の実施の形態におけるベアラ解放回避方法の一例を説明するためのシーケンスチャート 本発明の第３の実施の形態に係るＲＮの構成の一例を示す構成図 本発明の第３の実施の形態における動作フローの一例を示すフローチャート 本発明の第４の実施の形態における通信システムの構成の一例を示す構成図 本発明の第４の実施の形態におけるベアラ解放回避方法の一例を説明するためのシーケンスチャート 本発明の第４の実施の形態に係るＲＮの構成の一例を示す構成図 本発明の第４の実施の形態における動作フローの一例を示すフローチャート
＜第１の実施の形態＞
本発明の第１の実施の形態の詳細な動作について説明する。図１は本発明の第１の実施の形態によるシステム構成を説明するための図であり、アクセスネットワーク１０と、コアネットワーク２０と、パケットデータネットワーク（ＰＤＮ：Packet Data Network）３０と、アクセスネットワーク１０に接続してコアネットワーク２０経由でＰＤＮ３０と接続する移動端末（ＵＥ）１００と、ＰＤＮ３０を介して移動端末１００と通信を行う通信相手（ＣＮ：Correspondent Node）３００と、移動端末１００がＰＤＮ３０に接続する際の接続制御を行うゲートウェイ装置（ＰＧＷ：PDN Gateway）２００とが配備される。
さらに詳細には、アクセスネットワーク１０は、採用する規格に応じて３ＧＰＰアクセスネットワーク（例えば、ＬＴＥ、ＧＰＲＳ、ＷＣＤＭＡなど）、Ｎｏｎ−３ＧＰＰアクセスネットワーク（例えば、ＷｉＭＡＸなどの無線ＷＡＮ、ＷｉＦｉなどの無線ＬＡＮ、３ＧＰＰ２規格に準じたＨＲＰＤなどのセルラアクセスネットワーク、イーサネット（登録商標）（Ethernet（登録商標））などの有線ＬＡＮなど）などと称されることもある。
また、コアネットワーク２０は、３ＧＰＰ規格に準じてＥＰＣ（Evolved Packet Core network）や、単に３ＧＰＰコアネットワーク、またコアネットワーク２０を含むシステムとしてＥＰＳ（Evolved Packet System）などと称されることもある。ゲートウェイ装置２００も同様に、採用する規格に応じて、ゲートウェイＧＰＲＳサービングノード（Gateway GPRS Serving Node：ＧＧＳＮ）、ホームエージェント（Home Agent：ＨＡ）、ローカルモビリティアンカー（Local Mobility Anchor：ＬＭＡ）などと称されることもある。
図１において、移動端末１００は、アクセスネットワーク１０経由でＰＤＮ３０への接続処理をゲートウェイ装置２００との間で実施し、ＰＤＮ３０との接続が完了すると、通信相手３００と通信を行う（例えば、ＴＣＰプロトコルを用いたデータ転送など）。なお、第１の実施の形態では、移動端末１００、ゲートウェイ装置２００は、説明のため非特許文献２に示す３ＧＰＰ Ｅ−ＵＴＲＡＮ、ＳＡＥ（System Architecture Evolution）規格に準じて動作するものとする。
図２は、本発明の第１の実施の形態におけるパケット回復方法の一例を説明するためのシーケンスチャートである。移動端末（以下、ＵＥ）１００は、ＰＤＮ３０に接続するため、ゲートウェイ装置（以下、ＰＧＷ）２００に対して、非特許文献２に示すような接続処理（アタッチ手順：Attach Procedure）を実行する（ステップＳ２０１）。この接続処理を通じて、ＵＥ１００はＰＤＮ３０からＩＰアドレス（ＩＰｖ４アドレス、ＩＰｖ４サブネット、ＩＰｖ６アドレス、ＩＰｖ６プレフィクスなど）を取得し、ＰＤＮ３０経由で通信相手３００などの外部通信ノードと通信を開始できるようになる。
続いてＵＥ１００は、パケット廃棄時に通知してほしい通信フローをＰＧＷ２００に知らせるために、パケットフィルタの設定を行う（ステップＳ２０２）。すなわち、ＵＥ１００は、通信フローの情報をＰＧＷ２００に事前に登録する。非特許文献２には、ＵＥ１００がベアラリソース修正手順（UE requested bearer resource modification procedure）を用いて、ＰＧＷ２００が管理するトラフィックフローテンプレート（Traffic Flow Template、以下ＴＦＴと呼ぶ）のパケットフィルタを設定する方法が開示されている（新規フィルタの追加、既存フィルタの修正、既存フィルタの削除）。
パケットフィルタは、アップリンク用とダウンリンク用に区別して設定され、管理用のパケットフィルタ識別子、個々のフィルタの評価順序を決定する評価優先度（Evaluation Precedence index）、そして通信フローを表記するための要素である、相手ノードのＩＰアドレス（リモートアドレス：Remote Address）（及びサブネットマスクあるいはＩＰプレフィクス）、プロトコル番号（ＩＰｖ４の場合）、ネクストヘッダ番号（ＩＰｖ６の場合）、自ポート範囲（Local Port Range）、相手ポート範囲（Remote Port Range）、ＩＰｓｅｃセキュリティパラメータインデックス（IPsec Security Parameter Index：ＳＰＩ）、ＴＯＳ値（ＩＰｖ４の場合）、トラフィッククラス（Traffic Class：ＩＰｖ６の場合）及びＴＯＳ／トラフィッククラスに対するマスク値、フローラベル（ＩＰｖ６の場合）、そしてパケット廃棄時の通知有無、などの情報で構成される。ＵＥ１００は、これらの中から必要な要素をベアラリソース修正手順におけるRequest Bearer Resource Modificationメッセージに記載して送信する。
なお、パケットフィルタの設定は、接続処理（ステップＳ２０１）の中で実施するものであってもよく、ＵＥ１００は接続要求メッセージ（例えば、非特許文献２のAttach Requestメッセージ）に、パケット廃棄通知を必要とする通信フローの情報を記載して送信する。通信フローの情報は、ベアラリソース修正手順と同様に、通信フローを表現するのに必要な要素を接続要求メッセージに記載する。また、パケットフィルタの設定は、アプリケーション生成時や、ＵＥ状態の変化時（後述する移動度に応じた設定、等）に実施するものであってもよい。
パケット廃棄通知の取得対象とする通信フローは、例えば次のように指定することができる。
１）通信相手ごと
ＵＥが通信を行っている通信相手のアドレス単位で通信フローを定義する。すなわち、通信フローの情報は、ＵＥが通信を行っている通信相手のアドレス単位で登録される。この場合、Remote Addressに通信相手のアドレス（あるいはＩＰサブネットやＩＰプレフィクス）を記載してパケットフィルタを構成する。ここで、通信相手が異なるアドレスタイプ（すなわちＩＰv４アドレスとＩＰv６アドレス）の双方を保有し、ＵＥがそれらのアドレスに対して同時に通信を行っている場合、アドレスタイプ毎に通信フローを定義してもよいし、それらのアドレスタイプを束ねて一つの通信フローとして定義してもよい。
前者の場合、例えば、ＩＰv４アドレス（あるいはＩＰｖ４サブネット、以下同様）を用いた通信フローだけパケット廃棄通知の対象とし、ＩＰv６アドレス（あるいはＩＰｖ６プレフィクス、以下同様）を用いた通信フローはパケット廃棄通知の対象としない設定とすることができる。このとき、アドレスやサブネット・プレフィクス値を指定するのではなく、アドレスタイプ（ＩＰｖ４やＩＰｖ６、または両者を示すＩＰｖ４／ＩＰｖ６）を指定するものであってもよく、これによってパケットフィルタの情報量を低減でき、設定に要するトラフィックの低減を図ることができるとともに、ＴＦＴ管理テーブルを節約することにより、リソースの有効活用を図ることができる。後者の場合、例えば、ＩＰｖ４アドレスとＩＰv６アドレスをともに記載したパケットフィルタを構成し、それらの通信フローに対して共通的にパケット廃棄通知を受けるように（または受けないように）設定することができる。これにより、通信フローの特性に応じて、必要最低限の通信フローに対してパケット廃棄通知を受けるようにすることができ、ＰＧＷやＵＥの処理負荷並びに通信トラフィックの低減を図ることができる。また、ＴＦＴ管理テーブルを節約することにより、リソースの有効活用を図ることができる。
２）ポート番号ごと
ＵＥが通信を行っているポート番号単位で通信フローを定義する。すなわち、通信フローの情報は、ＵＥが通信を行っているポート番号単位で登録される。例えば、ＦＴＰプロトコルを用いたアプリケーション（ファイル転送アプリケーション）の通信フロー（標準的にはポート２０番と２１番を用いる）はパケット廃棄通知の対象とし、ＨＴＴＰ（Hyper Text Transfer Protocol）プロトコルを用いたアプリケーション（Ｗｅｂブラウザ）の通信フロー（標準的にはポート８０番を用いる）はパケット廃棄通知の対象としない設定にしたりすることができる。
ここで、アプリケーションやプロトコルによっては、使用するポート番号が変更されることがあり、必ずしも上記のような標準的なポート番号を用いる必要はなく、適したポート番号をパケットフィルタに設定する。またポート番号のレンジを設定してもよい。これにより、通信フローの特性に応じて、必要最低限の通信フローに対してパケット廃棄通知を受けるようにすることができ、ＰＧＷやＵＥの処理負荷並びに通信トラフィックの低減を図ることができる。また、ＴＦＴ管理テーブルを節約することにより、リソースの有効活用を図ることができる。
３）プロトコルタイプごと
ＵＥが通信を行っているプロトコル単位で通信フローを定義する。すなわち、通信フローの情報は、ＵＥが通信を行っているプロトコル単位で登録される。例えば、ＴＣＰ（Transmission Control Protocol）を用いた通信フローはパケット廃棄通知の対象とし、ＵＤＰ（User Datagram Protocol）を用いた通信フローは対象としないように設定することができる。ＴＣＰの場合に廃棄通知を取得するメリットとして、ＴＣＰが実施する再送制御を効率化させることによる通信効率の向上があげられる。
ここで、ＵＤＰを用いた通信フローであっても、アプリケーションが再送制御を実施しているような場合は、その効率化のために、廃棄通知を受け取るものとしてもよい。これにより、通信フローの特性に応じて、必要最低限の通信フローに対してパケット廃棄通知を受けるようにすることができ、ＰＧＷやＵＥの処理負荷並びに通信トラフィックの低減を図ることができる。また、ＴＦＴ管理テーブルを節約することにより、リソースの有効活用を図ることができる。
４）ＱＣＩごと
ベアラに紐付けされたＱＣＩ（QoS Class Identifier）単位で通信フローを定義する。すなわち、通信フローの情報はＱＣＩ単位で登録される。ＱＣＩは、伝送優先度、伝送遅延バジェット、パケットロスバジェットなどについて定義された複数のＱｏＳプロファイルを識別するための識別子（ＩＤ）である。例えば、ＱＣＩ８はＴＣＰを用いたアプリケーション向けのＱｏＳプロファイルであるので、パケット廃棄通知を受け取る設定としたり、ＱＣＩ１は通話（Conversational Voice）向けのＱｏＳプロファイルであるので、パケット廃棄通知を受け取らない設定としたりすることができる。これにより、通信フローの特性に応じて、必要最低限の通信フローに対してパケット廃棄通知を受けるようにすることができ、ＰＧＷやＵＥの処理負荷並びに通信トラフィックの低減を図ることができる。また、ＴＦＴ管理テーブルを節約することにより、リソースの有効活用を図ることができる。
５）アプリケーションごと
アプリケーションごとにＰＤＮコネクションを生成管理するような場合、アプリケーション単位で廃棄対象とする通信フローを定義してもよい。例えば、そのＰＤＮコネクション上を流れるすべての通信フローについて、廃棄通知を受けるようにするために、パケット廃棄通知有無フラグのみを有効にしたパケットフィルタを設定登録する。これにより、通信フローの特性に応じて、必要最低限の通信フローに対してパケット廃棄通知を受けるようにすることができ、ＰＧＷやＵＥの処理負荷並びに通信トラフィックの低減を図ることができる。また、ＴＦＴ管理テーブルを節約することにより、リソースの有効活用を図ることができる。
なお、上記説明では、パケット廃棄通知を受ける場合と受けない場合で、ともに設定を行うように説明したが、廃棄通知を受けない場合は特に設定を行わなくてもよい。すなわち、デフォルトで廃棄通知を受けない設定（すなわちパケット廃棄通知フラグをＯＦＦ）としておき、通知を受ける場合のみ設定（すなわち同フラグをＯＮにセットする）を行うものとしてもよい。また、逆に、デフォルトで廃棄通知を受ける設定（すなわち同フラグをＯＮ）としておき、あえて通知を受けなくてもよい場合のみ設定（すなわち同フラグをＯＦＦにセットする）を行うようにしてもよい。これにより、必要最低限の設定を行うだけでよく、ＴＦＴ管理テーブルを節約することにより、リソースの有効活用を図ることができるとともに、ＵＥやＰＧＷの処理負荷並びに通信トラフィックの低減を図ることができる。
また、上記説明では通信フローを定義する要素について示したが、それらの組み合わせであってもよい。例えば、ＵＤＰを用いた通信フローであっても、アプリケーションによっては再送制御を実施しているものと実施していないものがあるので、さらに通信相手やポート番号で分類して設定することができる。これによって、アプリケーションやプロトコルの状況に応じて、適したパケットフィルタを柔軟に構成することができる。
また、特にアプリケーションによるパケットリカバリをサポートしているような場合に、所定数のパケットが連続して廃棄された場合に通知するように設定してもよい。すなわち、ＰＧＷ２００は、廃棄したパケットが所定の数に達した場合に廃棄通知メッセージを送信する。例えば、通常のＶｏＩＰアプリケーションでは、再生音声の補間処理を行っており、数個程度（例えば２〜３個）のパケットロスは許容できる。そのため、例えば３個のパケットが連続して廃棄された場合に廃棄通知を受け取る設定とすることにより、アプリケーションのパケットリカバリ処理でカバーできない場合は迅速に再送制御をするなどの対応が可能となる。また、これにより、廃棄通知の回数を必要最低限に抑えることが可能となり、ＵＥやＰＧＷの処理負荷ならびに通信トラフィックを低減し、ひいてはシステム負荷の低減を図ることができる。
また、ＵＥ１００の移動度や移動状態に応じて廃棄通知を受ける設定を行ってもよい。例えば、高速移動時や移動に伴う一時的な通信状態の悪化でＰＧＷにおけるパケット滞留が懸念される場合は、廃棄通知を受ける設定をすることにより、ハンドオーバや通信状態の悪化により通信できなかった期間に受信する予定であったパケットのロスを迅速かつ的確に検出することができ、通信効率の向上を図ることができる。
ＰＧＷ２００は、ＵＥ１００からパケットフィルタ情報を取得すると、自身が管理するＵＥ１００用のＴＦＴに設定する（フィルタ設定：ステップＳ２０３）。ここで、廃棄通知対象とする通信フローについて、課金ポリシ等との照合を行ってもよい。例えば、通信の課金・ＱｏＳポリシを決定したり関連情報を配布したりするＰＣＲＦ（Policy and Charging Rules Function）や、ＵＥ１００の契約情報を管理するＨＳＳ（Home Subscriber Server）に対して、ＰＧＷが、廃棄通知対象として登録されようとしている通信フローが課金やＱｏＳ管理、あるいはＵＥの契約上問題がない（許容されるものであるか）確認を依頼し（あるいは関連情報を取得してＰＧＷにおいて確認し）、問題がない場合のみ、通信フローの設定を有効とし、ＴＦＴに登録する。このように、特定の通信フローあるいは特定のユーザに対して廃棄通知の設定を許可することにより、すべての通信フローに対して廃棄通知設定が行われるような事態を回避でき、ＰＧＷの負荷低減を図ることができる。なお、上記以外の条件に基づいて通信フローの登録可否を判断したり、ＰＧＷが独自に判断したりするものであってもよい。
以降、ＰＧＷ２００は、ＵＥ１００−ＣＮ３００間の通信トラフィックを中継することができるようになり、同時にＵＥ１００に対するＰＤＮコネクション内の通信ベアラ（非特許文献２では、ＥＰＳベアラに相当）がＧＢＲベアラか非ＧＢＲベアラかに応じて、ＧＢＲベアラの場合はＭＢＲに基づく流量制御、非ＧＢＲベアラの場合はＡＭＢＲに基づく流量制御を実施する（ステップＳ２０４）。すなわち、ＧＢＲベアラの場合はＭＢＲを超える流量のパケットを廃棄し、非ＧＢＲベアラの場合はＡＭＢＲを超える流量のパケットを廃棄する（流量超えのパケット：ステップＳ２０５）。
なお、廃棄通知対象とする通信フローの設定は、ネットワーク側で主体的に行うものであってもよい。例えば、ＰＣＲＦから取得したＱｏＳパラメータや課金情報、またＨＳＳから取得したＵＥの契約情報等にもとづいて、ＵＥやアプリケーション、またはオペレータやサービスプロバイダにとって特に重要な通信フローに対して、廃棄通知が設定されたパケットフィルタをＰＧＷがＴＦＴに登録するものであってもよい。さらには、ＵＥによる設定とネットワーク側装置による設定を統合したものであってもよい。このとき、ＵＥによる設定とネットワークによる設定の干渉を回避するために、いずれかの設定内容を優先するための優先度を設けてもよい。
次に、ＰＧＷ２００が管理するパケットフィルタとＴＦＴ構造について図３、図４を用いて説明する。なお、ここで説明するパケットフィルタ構造は、ＵＥがＰＧＷに通知対象フローを登録する際にも用いられる。
図３は、パケットフィルタ構造の一例を示す図であり、フィルタＩＤ、優先順位（Precedence）、通信相手のアドレス（リモートアドレス）とサブネットマスク、プロトコル番号（ＩＰｖ４の場合）あるいはネクストヘッダ値（ＩＰｖ６の場合）、ローカルポート範囲（自ポート範囲）、通信相手のポート範囲（相手ポート範囲）、ＩＰｓｅｃで用いるセキュリティ識別子（IPsec SPI）、ＴＯＳ値（ＩＰｖ４の場合）あるいはトラフィッククラス（ＩＰｖ６の場合）及びマスク、フローラベル（ＩＰｖ６の場合）といった従来のパケットフィルタ情報の他に、ＱＣＩや、本願の特徴である廃棄通知要否のフラグを新たに含む。
各フィルタエントリにはフィルタＩＤが付与され、図３の例では少なくとも３つのエントリが登録されている。また各エントリには、評価の優先順位（Precedence）が指定されており、所定の順序（昇順あるいは降順）で対象通信フローに対してエントリの評価が実施される。例えば、図３に示したパケットフィルタの例では、フィルタＩＤが１のエントリにはフロー情報は何も指定されていない。すなわち、すべての通信フローがこのエントリにマッチすることになる。
フィルタＩＤが２のエントリには、通信相手のポート番号８０だけが指定されている。これより、この通信フローはＨＴＴＰを用いたトラフィックであることが推察される。フィルタＩＤが３のエントリには、通信相手のアドレスx.x.x.xが指定されている。また、フィルタＩＤが２と３のエントリに対して、廃棄通知要否がＹ（Yes）（あるいはＯＮ）に設定されているので、これらのエントリに合致する通信フローのパケットを廃棄した場合はＵＥに通知を行う。
これらのエントリを有するパケットフィルタをもとに、通信フローを評価する際、まず優先順位の高いフィルタＩＤが３のエントリから評価が行われる。すなわち、通信フローの送信元アドレス（下りパケットの場合）あるいはあて先アドレス（上りパケットの場合）がx.x.x.xであるか評価する。次にフィルタＩＤが２のエントリに基づいて通信フローの送信元ポート（下りパケットの場合）あるいはあて先ポート（上りパケットの場合）が８０番であるか評価する。いずれのエントリにも合致しなかった場合、フィルタＩＤが１のエントリに合致することになる。ここで、ＱＣＩは別テーブル（別構造体）で管理されるものを参照するだけのものであってもよい。また、優先順位は、降順・昇順のいずれを適用してもよい。すなわち、優先順位値のより小さい方を高優先とするものであってもよい。
図４は、ＴＦＴ構造の一例を示す図である。ＴＦＴ構造では、先に説明したパケットフィルタ構造に登録されたエントリに合致する通信フローを伝送するＥＰＳベアラを指定する。すなわち、パケットフィルタ構造のエントリに対応するフィルタＩＤと、各エントリに合致する通信フロー（パケット）を伝送させるＥＰＳベアラＩＤとを記載する。図４の例によれば、フィルタＩＤが３及び２に合致する通信フローはＥＰＳベアラ５を用いて、それ以外の通信フロー（すなわちフィルタＩＤが１に合致する通信フロー）はＥＰＳベアラ３を用いてＵＥとＰＧＷ間の伝送が行われる。
流入パケットの混雑などによりＭＢＲ、ＡＭＢＲを上回る流量のパケットを検出すると、ＰＧＷ２００は対象となるパケットを廃棄し（ステップＳ２０６）、先にＵＥ１００が設定したパケットフィルタのうち、パケット廃棄時の通知が必要とされるエントリに合致する場合は、ＵＥ１００にパケット廃棄通知メッセージ（Drop Notification）を送信する（ステップＳ２０７）。パケット廃棄通知メッセージを受信したＵＥ１００は、廃棄されたパケットに対するリカバリー処理を実施する。例えば、図２に示すように再送要求メッセージ（Retransmission Request）を廃棄パケットの送信元（すなわち通信相手（ＣＮ）３００）に送信する（ステップＳ２０８）。
これを受けて、通信相手３００は、廃棄されたパケットをＵＥ１００に再送する（ステップＳ２０９）。このときＵＥ１００は、再送要求メッセージを送信するまでに所定の待ち時間を設けてもよい。これによって、ネットワークが混雑していたり、ＰＧＷの処理負荷が高まっていたりすることがパケット廃棄の要因となっているような場合に、いくらか時間をおいて送受信させることにより、更なる混雑や処理負荷増を引き起こすことなく、再送要求並びに再送パケットの伝送を正常に行わせることができる。
また、ＵＥ１００は、再度、パケットが廃棄される可能性がある旨の通知を再送要求メッセージに含めて送信し、通信相手３００が再送パケットの送信までに所定の時間を設けてもよく、上記と同等の効果を期待することができる。また、ＵＥ１００は、再送制御以外のリカバリー処理を実施してもよい。例えば、前後のパケットから抽出したコンテンツ（アプリケーションデータ）をもとにデータ補完を試みてもよいし、データロスが許容される場合は、単にパケットロス（あるいはコンテンツロス）として扱うものであってもよい。
ここで、パケット廃棄通知メッセージには、廃棄されたパケットの先頭から所定のサイズ分のコンテンツを含めることができる（例えば、廃棄パケットの先頭から６０バイトなど）。これによって、ＵＥ１００あるいはＵＥ１００上で動作するアプリケーションが、パケットの送信元アドレスを知り、再送要求メッセージを送信することができる。また、ＵＥ１００（ないしアプリケーション）が廃棄パケットの概要（例えば、ＴＣＰやＵＤＰなどのプロトコル番号、ポート番号、シーケンス番号やＴＣＰセグメント番号などのヘッダ情報や、アプリケーションデータの少なくとも一部）を知ることができ、再送制御方式や再送制御を実施するプロトコルレイヤ（レイヤ４、レイヤ５など）やプロトコル（ＴＣＰ、ＳＣＴＰ（Stream Control Transmission Protocol）、アプリケーション独自など）を決定したり、再送制御の必要性を決定したりすることができる。また、パケット廃棄通知メッセージは、ＩＣＭＰメッセージなどのユーザプレーンメッセージであってもよいし、非特許文献２に開示されるベアラリソース修正メッセージ（Bearer Resource Modification Message）のようなコントロールプレーンメッセージであってもよい。
また、廃棄パケットの識別子（例えば、シーケンス番号やＴＣＰセグメント番号など）を知ることによって、再送対象のパケットを特定することができ、確実に再送制御を実行することができる。なお、廃棄パケットの一部を含めずに、ＰＧＷ２００が廃棄パケットから抽出した送信元アドレスだけを廃棄通知メッセージに含めてもよい。パケット廃棄通知メッセージを制御プレーン（Control Plane）でＵＥ１００に配送する場合は、廃棄されたパケットの通信フローが属するベアラの識別子（ベアラＩＤ）をメッセージに含めることにより、ＵＥ１００はそのベアラに対して設定されたＴＦＴを参照して、ＴＦＴのパケットフィルタに通信相手のアドレスが登録されている場合は、廃棄パケットの一部からアドレスを抽出することなく再送要求メッセージを送信することができる。
なお、上記ではＰＧＷ２００がＵＥ１００に対してパケット廃棄を通知して、ＵＥ１００が廃棄パケットに対するリカバリーを実施することについて説明したが、ＵＥ１００の送信したパケットがＰＧＷ２００によって廃棄されるような場合にも、本発明による方法は適用できる。すなわち、ＵＥ１００が送信したパケットが、ＰＧＷ２００によって廃棄されると、ＰＧＷ２００がパケット廃棄通知メッセージをＵＥ１００に送信し、ＵＥ１００がこれを受け取って、廃棄されたパケットを再送する。このとき、再送までに所定の遅延を設けてもよく、これにより、ＰＧＷ２００やＰＤＮのさらなる混雑を回避することができる。
またさらには、廃棄パケットのリカバリーをＰＧＷ２００が実施するものであってもよい。すなわち、パケット廃棄を検出すると、パケット廃棄通知メッセージをＵＥ１００に送信せずに、廃棄パケットの送信元アドレス（すなわち通信相手３００）に対して再送要求メッセージを送信する。これにより、ＵＥ−ＰＧＷ間の通信、ＵＥによるリカバリー処理が不要となり、ＵＥ１００がリカバリー処理を実施する場合に比べて、よりリアルタイムな再送制御を実施することができる。
ここで、ＰＧＷ２００は、ＵＥ１００の再送要求タイマがエクスパイアするなどして、自発的な再送要求を実施させないよう、ＰＧＷ２００にて代理再送要求中なので自発的な再送要求を実施しないようＵＥ１００に指示してもよい（例えば、廃棄通知メッセージに再送要求処理の抑制を指示するフラグを設けたり、独自のメッセージにより指示したりする、など）。これを受けてＵＥ１００は、再送要求タイマがエクスパイアするなどしても自発的な再送要求を実施しない。例えば、再送要求タイマをリセットあるいは無効化したり、送信予定の再送要求メッセージを破棄したりすることで、再送要求処理を抑制する。これにより、重複した再送要求を抑えることができ、通信相手３００における混乱を回避させたり、通信相手３００が同一パケットを重複して送信することによるトラフィック増を防いだりすることができ、ひいては通信相手３００の処理負荷の低減を図ることができる。
また、ＵＥ１００が再送制御を実施する場合において、ＰＧＷ２００がパケット廃棄通知メッセージの送信時あるいは送信前後に、ＵＥ１００への再送制御指示中につき、自発的な再送制御を実施しないよう、通信相手３００に指示してもよい。すなわち、ＰＧＷ２００は、廃棄通知メッセージをＵＥ１００へ送信する際、自発的なパケットの再送制御をする必要がない旨のメッセージを通信相手３００へ送信する。これにより、通信相手３００が、ＡＣＫ未受信タイマがエクスパイアするなどしても、タイマをリセットあるいは無効化したり、再送予定のパケット送信を停止させたりして、自発的なパケット再送を実施することを防止でき、上記と同様、同一パケットによるトラフィック増を防ぐことができ、処理負荷の低減を図ることができる。
上記説明したように、本発明によるパケット回復方法では、ＰＧＷ２００が所定のＱｏＳ値を超える流量のパケットを廃棄する際に、廃棄パケットが対応付けられるベアラとそのベアラを保有するＵＥ１００を容易に特定できるので、ＰＧＷ２００の負荷を特に増加させることなく、パケット廃棄（パケット廃棄タイミング）をリアルタイムにＵＥ１００に通知して、ＵＥ１００が再送要求などのパケットリカバリ処理を実施することで通信効率を向上させることができる。
また、ＵＥ１００が設定するＴＦＴを参照して、パケット廃棄通知の要否を確認することにより、ＵＥ１００が必要とする通信フローのパケット廃棄だけを通知することができ、コアネットワークやアクセスネットワークのトラフィックを無意味に増加させたり、ＵＥ１００やＰＧＷ２００自身の処理負荷を無意味に増加させたりすることなく、適した通信フローの状態をＵＥ１００に通知して、適正に再送制御処理を実施させることができる。
次に、本発明の第１の実施の形態に係る移動端末（ＵＥ）の動作の一例について図５、図６を用いて説明する。図５は本発明の第１の実施の形態に係るＵＥの構成の一例を説明するための構成図である。通信部５０１は、アクセスネットワーク１０の基地局と接続して通信を行うための通信処理を実施し、具体的には基地局やアクセスネットワーク１０内の他のノードと通信するための通信プロトコル処理（ここではＩＰプロトコルを含む下位のプロトコル処理を行うものとする）並びにモデム処理を実施する。
通信制御部５０２は、通信プロトコルを操作して本発明に基づく方法を含む通信制御を行う。フィルタ管理部５０３は、本発明を実施するためのパケットフィルタの構築と管理を行う。再送制御部５０４は、廃棄されたパケットをリカバリーするための再送処理を実施する。上位層処理部５０５は、ＩＰレイヤより上位のプロトコル処理を実施する。アプリケーション部５０６は、アプリケーション処理を実施する。なお、通信部５０１は、フィルタ管理部５０３が構築したパケットフィルタ情報に基づいて、送信パケットを伝送するＰＤＮコネクションやベアラを決定する。
本発明による方法は、主に通信制御部５０２に実装されるものとして、その動作の一例について周辺の動作を交えながら図６を用いて説明する。まず、ＵＥが通信開始する際に、非特許文献２に示されるようなＰＤＮコネクションセットアップ処理を実施する。具体的には、アプリケーションの要請やハンドオーバ等を契機としてＰＤＮコネクションの開設を決定すると、通信制御部５０２は、非特許文献２に示すアタッチ手順（Attach Procedure）、あるいは既にアタッチメント手順が完了している場合は、ＰＤＮコネクション追加手順（Additional PDN Connectivity Procedure）を実施する（ＰＤＮコネクションセットアップ：ステップＳ６０１）。各手順の中で用いられるメッセージの送受信は通信部５０１を介して行われる。
ＰＤＮコネクションセットアップ処理が完了すると、通信制御部５０２指示を受けるなどして、フィルタ管理部５０３がパケット廃棄通知の対象とする通信フローを記述したパケットフィルタを構築し、通信制御部５０２を介してＰＧＷに登録する。具体的には、フィルタ管理部５０３が、上記説明したような形式で通信フローを表記してパケットフィルタを構築し、通信制御部５０２が、非特許文献２に示すようなベアラ修正手順（Bearer Modification Procedure）を用いて、構築したパケットフィルタをＰＧＷのＴＦＴに登録する（パケットフィルタセットアップ：ステップＳ６０２）。上記手順で用いられるメッセージの送受信は通信部５０１を介して行われる。
なお、パケットフィルタのＰＧＷへの登録（ステップＳ６０２）は、ＰＤＮコネクションセットアップ処理（ステップＳ６０１）の中であわせて実施するものであってもよい。すなわち、ＵＥは、廃棄通知対象とする通信フローを記述したパケットフィルタを、アタッチ手順やＰＤＮコネクション追加手順のメッセージに含めてＰＧＷに送信してもよい。
確立（セットアップ）したＰＤＮコネクションを用いて、ＵＥが通信を開始する。通信部５０１がメッセージを受信するとき（受信メッセージが制御プレーンメッセージか：ステップＳ６０３）、受信メッセージがユーザプレーンメッセージである場合、すなわち受信メッセージが、先に確立したＰＤＮコネクション内に開設されたベアラ上を伝送してＵＥに到達するものであった場合（例えば、ＩＰパケットを含むメッセージあるいはＩＰパケットそのもの）、ＩＰパケットのペイロードを上位層処理部５０５に転送し、然るべき上位層処理が行われる（ステップＳ６０６）。その結果、抽出されたアプリケーションデータはアプリケーション部５０６に転送され、処理される。
受信メッセージが制御プレーンメッセージである場合、受信メッセージがパケット廃棄通知メッセージであるか確認する（ステップＳ６０４）。受信メッセージがパケット廃棄通知メッセージでなかった場合は、通信制御部５０２において対応する処理が実施される（ステップＳ６０７）。受信メッセージがパケット廃棄通知メッセージであった場合、通信制御部５０２は然るべき処理部、例えば上位層処理部５０５やアプリケーション部５０６に、パケットが廃棄されたことを通知するとともに廃棄通知メッセージに情報（例えば、廃棄パケットの一部など）が含まれている場合はその情報を転送し、廃棄パケットに対するリカバリー処理を促す（パケットリカバリ処理：ステップＳ６０５）。
リカバリー処理の一例として、パケットの送信元に対して再送要求処理を実施する。廃棄通知メッセージに廃棄パケットのヘッダ（全体あるいは一部）が含まれている場合は、それをもとにパケット送信元のアドレスを特定することができる。または、先に登録した廃棄通知対象とする通信フローのフローフィルタ情報から通信相手のアドレスを特定してもよい。再送要求処理は、通信制御部５０２が行うものであってもよいし、通信制御部５０２以外の処理部、例えば上位層処理部５０５やアプリケーション部５０６が行うものであってもよく、適した再送要求を実施できる処理部において実施することが望ましい。例えば、上位層処理部５０５やアプリケーション部５０６が、廃棄パケットの識別子に対するＮＡＣＫ応答を送信元に返すことにより、送信元端末に当該パケットを再送させることができる。
他のリカバリー処理の例は、アプリケーションによるデータ補間である。例えば、既に受信済みのデータから廃棄パケットが含んでいたであろうデータを推定して生成し、データ全体を再生する。この場合、再送要求は行わない。
なお、廃棄パケットに対するリカバリー処理は、廃棄通知メッセージを受信する都度行われるものでなくてもよい。すなわち、再送制御を実施するプロトコルなどの事情に応じて、リカバリー処理を実施する廃棄パケット数を決めておいてもよい。例えば、２パケット廃棄される毎にリカバリー処理を起動する場合、１回の廃棄通知で１個の廃棄パケット情報が通知されるとすると、合計２回の廃棄通知を受信したときに１度リカバリー処理を実施すればよい。
また、１回の廃棄通知で複数の廃棄パケット情報が通知される場合は、通知された廃棄パケット数が、リカバリー処理の起動に必要な廃棄パケット数に達した時点で、リカバリー処理を実施すればよい。これにより、すべての廃棄通知に対応する必要がなくなり、同時に必要最低限のリカバリー処理を起動することができるようになり、ＵＥ装置内の処理負荷の低減を図ることができる。
なお、パケット廃棄通知メッセージがＩＣＭＰメッセージなどのユーザプレーンデータ（すなわちＩＰ層以上のレイヤで規定されるプロトコル）で実装されるものであってもよく、その場合は、受信したデータがパケット廃棄通知メッセージに該当するかを判定し（ステップＳ６０４と同様の処理）、パケット廃棄通知メッセージであった場合は、パケットリカバリ処理を開始する（ステップＳ６０５と同様の処理)。受信したデータがパケット廃棄通知メッセージでなかった場合は、上位層処理部５０５にて処理が行われる（ステップＳ６０６）。以降は、上記説明したのと同じ処理となるので、ここでは説明を割愛する。
なお、通信制御部５０２が、リカバリー処理を実施する処理部を特定する方法としては、パケット廃棄通知メッセージが伝送されたベアラの識別子（廃棄通知メッセージがユーザプレーンデータで実装される場合）、また廃棄通知メッセージに含まれる情報（例えば、ベアラ識別子、廃棄パケットのヘッダ情報から抽出した受信アドレスや受信ポート番号、プロトコル番号など）から、廃棄されたパケットの受信処理を本来行うべきであった上位層プロトコル（あるいはＩＰ層のプロトコル）を特定して、特定した情報とともに上位層処理部５０５に通知したり、同様にして受信ソケットを特定し、廃棄パケットのデータが本来転送されるべきであったアプリケーション部５０６に通知したりする。
次に、本発明の第１の実施の形態に係るゲートウェイ装置（ＰＧＷ）の動作の一例について図７、図８を用いて説明する。図７は本発明の第１の実施の形態に係るＰＧＷの構成の一例を説明するための構成図である。通信部７０１は、ＰＤＮ３０（具体的には、例えばＰＤＮ３０内に設置される図示していないゲートウェイ）と通信を行ったり、コアネットワーク２０内のノードと通信を行ったりするための通信処理を実施し、具体的には、通信プロトコル処理（ここではＩＰプロトコルを含む下位のプロトコル処理を行うものとする）並びにモデム処理を実施する。
なお、通信部７０１はＰＤＮ側と接続するための通信部（ＰＤＮインタフェース）と、コアネットワーク側と接続するための通信部（コアネットワーク・インタフェース）に論理的あるいは物理的に分離されていてもよい。通信制御部７０２は、通信プロトコルを操作するなど通信部７０１の制御管理を行う。フィルタ管理部７０３は、本発明を実施するためのパケットフィルタをＴＦＴとともに管理する。転送処理部７０４は、フィルタ管理部７０３が管理するＴＦＴに基づいて、ＰＤＮから受信したパケットの転送制御ならびに流量制御を実施する。コネクション管理部７０５は、ＵＥとの間で確立するＰＤＮコネクションやベアラの制御や管理を行う。
本発明による方法は、主に転送処理部７０４に実装されるものとして、その動作の一例について、周辺の動作を交えながら図８を用いて説明する。まず、ＵＥからのＰＤＮコネクション確立要求、例えば非特許文献２に示すような、アタッチ手順（Attach Procedure）、あるいは既にアタッチメント手順が完了している場合は、ＰＤＮコネクション追加手順（Additional PDN Connectivity Procedure）のメッセージを通信部７０１が受信すると、通信制御部７０２を介してコネクション管理部７０５に転送され、コネクション管理部７０５及び通信制御部７０２の制御のもと、ＵＥが所望のＰＤＮとの間で通信を行うためのＰＤＮコネクションを確立する（ＰＤＮコネクションセットアップ：ステップＳ８０１）。ＰＤＮコネクション確立に用いられるメッセージの送受信は通信部７０１を介して行われる。
続いて、ＵＥからパケットフィルタを登録あるいは更新するためのメッセージ、例えば非特許文献２に示すようなベアラ修正手順（Bearer Modification Procedure）で用いられるメッセージを通信部７０１が受信すると、通信制御部７０２を介してフィルタ管理部７０３がＴＦＴを更新する（パケットフィルタセットアップ：ステップＳ８０２）。これによって、ＵＥが廃棄通知対象とする通信フローがＰＧＷのＴＦＴに登録され、以降ＰＧＷはＴＦＴを参照することによって、パケット廃棄時にパケットヘッダを参照したりすることなく、すなわち大きな負荷を伴うことなくＵＥにパケット廃棄を通知することができるようになる。
なお、廃棄通知対象となる通信フローの情報を含むパケットフィルタのＴＦＴへの登録（ステップＳ８０２）は、ＰＤＮコネクションセットアップ（ステップＳ８０１）の中であわせて実施される場合もある。また、廃棄通知対象となる通信フローのパケットフィルタ及びＴＦＴへの登録は、ＰＧＷが独自に実施するものであってもよい。すなわち、ＰＤＮコネクションセットアップ（ステップＳ８０１）の過程で、ＰＣＲＦ（Policy and Charging Rules Function）から取得したＱｏＳパラメータ（セットアップ中のＰＤＮコネクション及びベアラに適用される）や課金情報に基づいて、ＵＥやアプリケーションにとって特に重要な通信フローに対して廃棄通知が設定されたパケットフィルタをＴＦＴに登録してもよい。
例えば、通常より高めの料金を特別に支払っているユーザに対しては、すべての通信フローに対して廃棄通知設定を行ってもよい。廃棄通知設定がデフォルトで有効となるようなＱｏＳポリシを設けてもよく、例えば、廃棄通知設定が有効となるようなＱＣＩが指定されたＰＤＮコネクションやベアラについては、ＵＥからの登録がなくても自動的にＰＧＷによって廃棄通知を設定するようにしてもよい。
確立（セットアップ）したＰＤＮコネクションあてのパケット、すなわち当該ＰＤＮコネクション向けに割り当てたＩＰアドレスあるいはＩＰプレフィクスやＩＰサブネットに宛てられたパケットを通信部７０１がＰＤＮから受信する（ステップＳ８０３）と、受信パケットを転送処理部７０４に転送する。転送処理部７０４は、フィルタ管理部７０３が管理するＴＦＴを参照して、対応するベアラを検索し、転送先となるコアネットワーク内のノード（ＳＧＷやＳＧＳＮ、ＡＧＷなど）を決定し、転送キューに積む。
通信部７０１は転送キューに積まれたパケットを順次コアネットワークに向けて、すなわちＵＥあてに送出する（ステップＳ８０６）。このとき、ＰＧＷは対応するベアラに通じるトンネル（ＧＴＰトンネルやＰＭＩＰトンネル、Dual Stack MIPなどのモバイルＩＰトンネル）に対してパケットを送信する（すなわちトンネルヘッダを付加して送信する）。なお、転送キューについては、ＧＢＲベアラあてパケットはそのＰＤＮに対するＧＢＲベアラ単位、ｎｏｎ−ＧＢＲベアラあてパケットはＰＤＮ単位で設けられており、それらのキューの間でも、ＱＣＩなどに基づく転送の優先制御が実施されているものとする。あるいは単にＱＣＩ単位で転送キューが設けられていてもよく、以下説明する処理を同様に適用することができる。
ここで、コアネットワーク内の輻輳などにより通信部７０１による送信処理が滞ると、転送キューに積まれたパケット量が所定の閾値を上回ることがある。すなわち、ＵＥのＧＢＲベアラに対してはＰＤＮコネクション確立時あるいはベアラリソース修正時に割り当てられた容量（ＭＢＲにて示される）、ｎｏｎ−ＧＢＲベアラに対してはＰＤＮ全体に対して割り当てられた容量（ＡＰＮ−ＡＭＢＲにて示される）に対して、各キューに積まれたパケットの総量（パケットサイズ）とそれらの送出予定時刻から算出された実容量が上回る場合に、最近キューに積まれたパケットから順次廃棄される。なお、ＧＢＲベアラに対するパケット廃棄指標をＧＢＲ、ｎｏｎ−ＧＢＲベアラに対するパケット廃棄指標をＵＥ−ＡＭＢＲとしてもよい。
このようにして、パケットを廃棄するか否か（ステップＳ８０４）を判断し、さらにはパケットの廃棄が実施されると、転送処理部７０４は、廃棄したパケットにマッチするパケットフィルタエントリ（あらためてＴＦＴを参照してもよいし、例えばパケット毎のキャッシュ情報に記載するなどキューに積む際にパケットに紐づけておいてもよい）の廃棄通知要否フラグがＯＮの場合は、廃棄パケットを転送する予定であったベアラのＵＥに対してパケット廃棄通知メッセージを送信する（ステップＳ８０５）。
パケット廃棄通知メッセージには、廃棄パケットの一部、例えばパケットヘッダや、さらにはペイロードの先頭から所定サイズ分のデータ（例えば数十バイト）、またはパケットの先頭から所定サイズ分のデータ（例えば数十バイト）を含めてもよい。また、パケット廃棄通知メッセージは、例えばＩＣＭＰメッセージを応用するなどして、該当するベアラのユーザプレーンを用いてＵＥに伝送するものであってもよい。
なお、転送処理部７０４は、実際にパケットを廃棄する前、すなわち、パケット廃棄を決定した時点で、ＵＥにパケット廃棄通知メッセージを送信してもよい。これによって、ＵＥにおいては、より迅速にパケットリカバリ処理、例えば再送要求をよりリアルタイムに実施できるようになり、ＵＥの通信効率を向上させることができる。
＜第２の実施の形態＞
本発明の第２の実施の形態の詳細な動作について説明する。図９は本発明の第２の実施の形態によるシステム構成を説明するための図であり、アクセスネットワーク１０と、コアネットワーク２０と、パケットデータネットワーク（ＰＤＮ）３０と、アクセスネットワーク１０に接続してコアネットワーク２０経由でＰＤＮ３０と接続する移動端末（ＵＥ）１００と、ＰＤＮ３０を介して移動端末１００と通信を行う通信相手（ＣＮ：Correspondent Node）３００と、また、移動端末１００がＰＤＮ３０に接続する際の接続制御を行うゲートウェイ装置（ＰＧＷ：PDN Gateway）２００と、ＰＧＷ２００に対してアクセスネットワーク１０に対する移動端末１００の局所的な接続制御を実施する局所ゲートウェイ装置（ＳＧＷ：Serving Gateway）６００と、移動端末１００の移動管理を行う移動管理装置（ＭＭＥ：Mobility Management Entity）５００と、移動端末１００に対するアクセスネットワーク１０の直接的なアタッチポイントとなる基地局装置（ｅＮＢ：evolved Node B）４００とが配備される。
さらに詳細には、アクセスネットワーク１０は、採用する規格に応じて３ＧＰＰアクセスネットワーク（例えば、ＬＴＥ、ＧＰＲＳ、ＷＣＤＭＡなど）、Ｎｏｎ−３ＧＰＰアクセスネットワーク（例えば、ＷｉＭＡＸなどの無線ＷＡＮ、ＷｉＦｉなどの無線ＬＡＮ、３ＧＰＰ２規格に準じたＨＲＰＤなどのセルラアクセスネットワーク、イーサネット（登録商標）（Ethernet（登録商標））などの有線ＬＡＮなど）などと称されることもある。
また、コアネットワーク２０は、３ＧＰＰ規格に準じてＥＰＣ（Evolved Packet Core network）や、単に３ＧＰＰコアネットワーク、またコアネットワーク２０を含むシステムとしてＥＰＳ（Evolved Packet System）などと称されることもある。ゲートウェイ装置２００も同様に、採用する規格に応じて、ゲートウェイＧＰＲＳサービングノード（Gateway GPRS Serving Node：ＧＧＳＮ）、ホームエージェント（Home Agent：ＨＡ）、ローカルモビリティアンカー（ＬＭＡ：Local Mobility Anchor）などと称されることもある。
局所ゲートウェイ装置６００は、アクセスゲートウェイ（Access Gateway：ＡＧＷ）、モビリティアンカーゲートウェイ（Mobility Anchor Gateway：ＭＡＧ）、パケットデータゲートウェイ（Packet Data Gateway：ＰＤＧ、enhanced Packet Data Gateway：ｅＰＤＧ）サービングＧＰＲＳサービングノード（Serving GPRS Serving Node：ＳＧＳＮ）などと称されることもある。また、基地局装置４００は、アクセスポイント（ＡＰ：Access Point）、ノードＢ（ＮＢ：Node B）、ベースステーション（Base Station：ＢＳ）、アタッチポイント（ＰｏＡ：Point of Attachment）などと称されることもある。また、家庭や店舗、学校等の構内などに設置されるホーム基地局（例えば、Home eNodeB（HeNB）やHome NodeB（HNB）、ピコセル（Pico cell）基地局、フェムトセル（Femto cell）基地局、アットセル（Atto cell）基地局）であってもよい。
本発明の第２の実施の形態では、第１の実施の形態で説明した内容に加え、さらに新たな課題を解決するものである。すなわち、図９において、アクセスネットワーク１０が収容するＵＥ数の増加や、アクセスネットワーク１０内のトラフィックの増加などを理由に、当初ＵＥに割り当てたＱｏＳ保証値（具体的にはＧＢＲ値）を基地局ｅＮＢ４００が維持できなくなると、ＵＥ１００への通知なしにＧＢＲベアラを切断（あるいは無効化）することがある。
基地局４００がＧＢＲベアラ切断を判断した時に、ＵＥ１００に通知することも考えられるが、既に普及設置されている既存の基地局（しかもカバーエリアを確保するため、設置場所も拡散されている）をすべて対応させるのは、莫大なコストを要するため現実的ではない。一方、一部の基地局だけがベアラ切断通知機能に対応している状況では、ＵＥ１００からみたシステム挙動が一貫せず（あるところでは通知を受けられるが、あるところでは通知を受けられずベアラが勝手に切断されてしまう）、システム安定性の点で望ましくない。
以下説明する本発明の第２の実施の形態によれば、基地局に比べて設置台数が極めて少なく、また設置場所も局所化される傾向にあるＰＧＷを変更するだけで所望の効果を得ることができ、したがって導入コストも大きく抑えることができる。すなわち、ＰＧＷにおいて基地局が発行するベアラリリースを捕捉してＵＥに通知し、ＵＥがベアラリソースを調整することでベアラリリースを停止させる。これによって、著しいコスト増加を伴うことなく、安定性の確保された通信システムを提供することができ、さらには、ＵＥが存続を希望するベアラについては、ベアラリソースを削減して設定することで、ベアラ存続を維持させることも可能であることから、リアルタイムストリーミングでビデオ視聴しているユーザが、ウィンドウサイズを縮小させて（すなわち品質を落として）でも視聴を継続させたいような場合に対応できるようになり（従来は意図せず切断されていた）、ユーザ利便性の向上を図ることができる。
以下、図１０を用いて本発明の第２の実施の形態による方法の動作について詳しく説明する。図１０は、本発明の第２の実施の形態におけるベアラ解放回避方法の一例を説明するためのシーケンスチャートである。ステップＳ１００１からＳ１００４までは、第１の実施の形態で説明したステップＳ２０１からＳ２０４までの処理と同じであるので、ここでは説明を割愛する。
通信相手３００と通信を行っている状態で、ＵＥ１００は定期的に、あるいは常時、無線リンクや基地局を中心とするアクセスシステムの状態を評価する（ステップＳ１００５）。例えば、電波強度を観測することにより、ハンドオーバを実行するほどではないが、現状のＱｏＳを維持するには難しい状況になっていることを判断（例えば、無線区間でのパケットロス、すなわち無線リンクレベルのパケットロスが発生しており、ＲＲＣ（Radio Resource Control）やＭＡＣなどのリンクレイヤによる再送制御が動作していることを検出した場合など）することができる。
また、非特許文献３に開示されるようなＥＣＮ（Explicit Congestion Notification）プロトコルを用いて、基地局が評価した混雑状況をＥＣＮヘッダに記載して、ユーザプレーンのパケットヘッダに重畳してＵＥ１００に通知することが可能である場合、ＵＥ１００は受信したパケットのＥＣＮヘッダから混雑状況を読み出して（例えば、ビット列が’００’以外の値である、など）、基地局が現状のＱｏＳを維持するには難しい状況になっていることを判断することができる。ここで、ＥＣＮヘッダ付きのパケットは、ユーザプレーンで伝送されるため、どのベアラに対するパケットであるかを判別できるという特徴がある。
また、さらには、基地局４００におけるトラフィックの混雑状況や、端末収容状況、リソース使用状況（あるいはリソース残量）などの情報を他の基地局とで交換しているような場合、例えば非特許文献２に開示されるようなＸ２インタフェースを用いて基地局間で上記混雑状況や収容状況などの情報をＬＯＡＤ ＩＮＦＯＲＭＡＴＩＯＮによって交換しているような場合は、それらと同様の情報を基地局４００からＵＥ１００に直接通知してもよい。これによって、ＵＥ１００が基地局４００やアクセスネットワークの混雑状況や負荷状況を直接的に知ることができる。このとき、あわせて許容可能なトラフィック量や収容数などを示す値（スレッショルド）をＵＥ１００への通知メッセージに付加してもよい。
上記条件のうち、いずれか一つでも満たされる場合、すなわち、ＵＥ１００が基地局４００あるいはアクセスネットワークにおいてベアラの維持が困難な状況になりつつあると判断した場合、先にＴＦＴに設定したパケットフィルタの更新（Update、あるいは再設定（Reconfiguration）とも呼ぶ）を行う（パケットフィルタ更新メッセージの送信：ステップＳ１００６）。なお、先にパケットフィルタの設定を行わなかった場合（すべての通信フローに対して設定してない場合や、特定の通信フローに対して設定してない場合）は、ここで新規に設定する。
なお、ＵＥ１００がＥＣＮを受信すると、直ちに通信レートを下げるためにベアラに設定されたビットレート（すなわちＧＢＲやＡＭＢＲ）を下方修正する処理を開始する場合がある。このように、通信レートを下げたことによってＥＣＮを受信しなくなった場合は、パケットフィルタの更新あるいは設定を行わずに、引き続き基地局やアクセスネットワークの状態監視を継続するものであってもよい。これは、ＥＣＮを受信しなくなったことが、少なくともそのＵＥに対しては混雑が解消できたことを示すからである。一方、ＥＣＮを引き続き断続的あるいは連続して受信し続けるような場合は、混雑が解消されていないので、パケットフィルタを更新あるいは設定して、不意のベアラ解消に備えることができる。
また、ＵＥ１００の接続時に決定されたＡＲＰ（Allocation and Retention Priority）が所定値よりも高い場合は、ネットワークが優先してベアラを維持してくれるため、パケットフィルタの更新あるいは設定を行わなくてもよい。
このパケットフィルタ更新（あるいはＴＦＴ更新とも呼ぶ）は、ＵＥ１００が接続を維持したい通信フローを収容するベアラに対する、基地局４００の判断によるベアラリリースを回避するために行う。すなわち、ＵＥ１００は、パケットフィルタ更新メッセージに、接続を維持したい通信フローに関するパケットフィルタ情報とベアラ解放抑止を指示する情報（例えば、フラグなど）を記載して送信する。パケットフィルタ更新メッセージは、ＭＭＥ５００やＳＧＷ６００などのノードを経由してＰＧＷ２００に配送される。
ここで、ベアラ解放抑止を指示するためのパケットフィルタの更新あるいは設定は、ＵＥ１００の移動度や通信位置などに応じて実施するものであってもよい。例えば、低速でセル境界を移動していたり、単にセル境界で通信していたりするときは、通信状態が不安定になりやるいため、積極的にパケットフィルタの更新を行い、それ以外の場合は行わないものであってもよい。これによって、本質的にベアラ切断対象となりうるユーザのみを対象に本発明によるサービスを提供でき、システム負荷の低減とともに、リソース有効活用を図ることができる。
ＰＧＷ２００がパケットフィルタ更新メッセージを受信すると、パケットフィルタ情報をメッセージから抽出して、ＰＧＷ２００が管理するＴＦＴにＵＥ１００の対象通信フローに関するエントリを作成又は更新する（フィルタ更新：ステップＳ１００７）。ここで、既存のパケットフィルタの更新は、ＵＥ１００が通知するパケットフィルタ情報に既存パケットフィルタのフィルタＩＤを含めることにより、ＰＧＷ２００が該当するパケットフィルタを特定して実施する。
ここで、ＰＧＷ２００が管理するパケットフィルタについて図１１を用いて説明する。ここで説明するパケットフィルタ構造は、ＵＥがＰＧＷに通知対象フローを登録する際にも用いられる。なお、ＴＦＴ構造は先に図４を用いて説明したのと同じ構造を用いることができるので、ここでは説明を割愛する。
図１１に示すパケットフィルタ構造は、図３に示したのとほとんど同じ構成をもつものであるが、唯一異なるのは、第２の実施の形態の特徴であるベアラ解放抑止を要求するためのフラグ（あるいは相当の情報）を有する点である。ＵＥがベアラ解放抑止を指示する場合、ベアラ解放抑止フラグをＹ（Yes）（あるいはＯＮ）にしてＰＧＷに登録する。
ＰＧＷはフィルタＩＤが３のエントリに対応する通信フローを伝送するためのベアラ（すなわちＥＰＳベアラ５）に対してベアラ解放処理が開始されたことを検出すると、以下説明する手順に基づいてベアラ解放抑止処理を実施する。パケットフィルタ更新メッセージは、非特許文献２に開示されるようなベアラリソース修正手順（UE requested bearer resource modification procedure）におけるRequest Bearer Resource Modificationメッセージに相当するものであるが、他のメッセージであってもよい。ここで、パケットフィルタ情報の更新・設定は、次のような粒度で実施することができる。
１）無線リンクや基地局の状態が、現状のＱｏＳを維持するには難しい状況であることの検出をベアラ単位で実施できる場合、すなわち、特定のベアラに対して現状ＱｏＳの維持が難しい状況であると判断できる場合、そのベアラ上を流れる通信フロー（すべてあるいは一部）に対してベアラ解放抑止を有効に設定するパケットフィルタ更新を実施する。これは、基地局がＥＣＮなどを用いて、ユーザプレーン上で混雑状況をＵＥ１００に通知するような場合の実施例である。すなわち、ＵＥ１００は、基地局が混雑状況を記載したＥＣＮヘッダを含むパケットが流れるベアラを特定することができるので、そのベアラを流れる通信フローの中から接続を維持したいものについてベアラ解放抑止を有効化させることができる。
ベアラ単位のパケットフィルタ更新は、ＵＥ１００やＰＧＷ２００において更新対象となるパケットフィルタエントリを容易に特定できることから、それらノードの処理負荷を低減させることができる。これはＴＦＴ構造の構成上の特性から、登録されたパケットフィルタを、ベアラＩＤを鍵として検索しやすいためである（例えば、図４参照）。
ここで、特定できたベアラがデフォルトベアラであった場合、基地局によるベアラリリースの対象外であることから、ベアラ解放抑止のためのパケットフィルタ更新は行わなくてもよく、その設定のためのトラフィック並びにＵＥ１００やＰＧＷ２００における処理負荷の低減を図ることができる。
２）無線リンクや基地局の状態が、現状のＱｏＳを維持するには難しい状況であることの検出をＰＤＮコネクション単位で実施できる場合、例えば、特定のＰＤＮコネクション上を流れるパケットのロス率がすべてのベアラに対して一様に高まっていることが検出できた場合など、現状ＱｏＳの維持が難しい状況であると判断できる場合、そのＰＤＮコネクション上を流れる通信フロー（すべてあるいは一部）に対してベアラ解放抑止を有効に設定するパケットフィルタ更新を実施する。
ここで、特定できたＰＤＮコネクションのデフォルトベアラについては、基地局によるベアラリリースの対象外であることから、ベアラ解放抑止のためのパケットフィルタ更新は行わなくてもよく、その設定のためのトラフィック並びにＵＥ１００やＰＧＷ２００における処理負荷の低減を図ることができる。
３）無線ベアラや基地局の状態が、現状のＱｏＳを維持するには難しい状況であることを検出すると、既存の通信フィルタすべてに対してベアラ解放抑止を有効に設定するパケットフィルタ更新を実施する。これは、特に、無線リンクの状態からＱｏＳ維持の困難さを判断するような場合に有効である。すなわち、無線リンクの状態が悪化していることを検出したが、対象となるベアラを特定できないような場合である。
基地局４００が、実際にＱｏＳ維持が難しいことなどを理由にベアラ解放を決定すると（ステップＳ１００８）、非特許文献２に示すようなベアラ解放手順（Dedicated Bearer Deactivation Procedure）を開始する。すなわち、基地局４００がベアラ解放指示メッセージ（Bearer Release Indication）をＭＭＥ５００に送信する（ステップＳ１００９）。これを受けて、ＭＭＥ５００がベアラ削除コマンドメッセージ（Delete Bearer Command）をＳＧＷ６００に送信すると（ステップＳ１０１０）、ＳＧＷ６００はそれをＰＧＷ２００に転送する（ステップＳ１０１１）。
ＰＧＷ２００は、ベアラ削除コマンドメッセージを受信すると、メッセージから削除対象のベアラ（ベアラＩＤ）を確認し、ＴＦＴ並びにパケットフィルタを参照して、そのベアラに対してベアラ解放抑止が設定されているかを確認する（ベアラ解放抑止の設定の確認：ステップＳ１０１２）。削除対象のベアラに対してベアラ解放抑止が設定されていない場合、ＰＧＷ２００は通常の（すなわち非特許文献２に示されるような）ベアラ解放手順を継続し、対象ベアラは解放される。削除対象のベアラに対してベアラ解放抑止が設定されている場合、ＰＧＷ２００は実施中のベアラ解放手順を中断（停止）し、ＵＥ１００にベアラ解放手順が実施されていることを通知する（ベアラ解放通知メッセージ：ステップＳ１０１３）。
ベアラ解放通知メッセージには、解放対象のベアラＩＤを記載してもよい。また、特にベアラＩＤを記載しない場合でも、対象ベアラに関連するシグナリングプレーンやユーザプレーン上にベアラ解放通知メッセージを流すことによって、ＵＥ１００が対象ベアラを特定できるようにするものであってもよい。
ＵＥ１００がベアラ解放通知メッセージを受信すると、基地局４００が発行したベアラ解放を停止させて通信フローを維持させるため、対象ベアラに対するＱｏＳ値を減少させる設定を行う。具体的には、非特許文献２に示すようなベアラリソース修正手順（UE requested bearer resource modification procedure）を実施して、ネットワークに新たなＱｏＳ値を設定する。すなわちＵＥ１００は、ベアラリソース修正要求メッセージを送信する（ステップＳ１０１４）。ＭＭＥ５００がこれを受信すると、ＳＧＷ６００にベアラリソースコマンドメッセージを送信し（ステップＳ１０１５）、ＳＧＷ６００はそれをＰＧＷ２００に転送する（ステップＳ１０１６）。
これを受けてＰＧＷ２００は、非特許文献２に示すようなＰＧＷ主導ベアラ修正手順（PGW initiated bearer modification procedure）を起動して、先に解放対象となったＵＥ１００のベアラに対するＱｏＳ設定を実行する（ＰＧＷ主導ベアラ修正手順を起動：ステップＳ１０１７）。ＱｏＳ設定が完了すると、ＰＧＷ２００は、先に停止させていたベアラ解放手順に対して、処理が失敗した旨の応答を送信する。
これは、例えば非特許文献４に示されるようなベアラ削除失敗通知（Delete Bearer Failure Indication）メッセージである。これにより、ＳＧＷ６００やＭＭＥ５００、基地局４００は、ベアラ解放処理を実施することなく処理を完了する。ＵＥ１００は、要求したＱｏＳ設定に基づいて更新されたベアラを用いて通信を継続させることができる。
なお、ベアラ解放通知メッセージ（ステップＳ１０１３）の中で、ＰＧＷ２００からＵＥ１００に適正なＱｏＳ値（又は推奨されるＱｏＳ値）が通知されるものであってもよい。さらに通知されるＱｏＳ値は、ＰＧＷ２００がＰＣＲＦなどのＱｏＳを管理するネットワークノードから取得したポリシやあらかじめ設定されたポリシに基づいて決定するものであってもよいし、基地局４００やＭＭＥ５００などのネットワークノードがアクセスネットワークの状況に基づいて決定するものであってもよい。
また、ベアラ解放処理を一時的に停止させず、ＵＥ１００が対象ベアラのＱｏＳ調整を開始する前に、ＰＧＷ２００がベアラ解放処理を失敗させてもよい。これにより、システムの不安定な状態（ＱｏＳ調整を行っている間、アクセスネットワークとしては本来解放させてしまいたい状態にあるベアラが生かされるでもなく切断されるでもなく維持されてしまっている不安定な状態）を回避でき、システム全体の効率低下を避けることができる。
第２の実施の形態によれば、従来基地局４００が発行するベアラリリース通知（ベアラ解放指示メッセージ：ステップＳ１００９）には、ベアラリリースの理由となる情報（例えば、無線区間の混雑、基地局の停止、など）が含まれていないため、ＰＧＷ２００では、正しく所望のベアラリリースだけを停止させることができなかったが、第２の実施の形態では、ＵＥ１００がベアラリリースの可能性とその解放抑止要求をあらかじめＰＧＷ２００に通知してあるので、正しく所望のベアラリリースだけを停止させることが可能となる。また、既に全世界に設置され、稼動している無数の基地局や、ＭＭＥ−ＳＧＷ−ＰＧＷ間の既存シグナリングを変更することなく、ＰＧＷとＵＥの変更により所望の効果を達成することができ、実施コストの点で優位である。
なお、あらかじめ対応が必要なエリアが限定されているなどの理由から、当該処理に関係する基地局数が許容される実施コストの範囲内であることが明らかである場合は、次のような方法により、基地局によるベアラリリースを抑止することもできる。一つには、ベアラのＱｏＳ保証ができなくなってきたため、パケットの配送ができないことを示す通知を基地局がＵＥに送信する。このメッセージには、ICMP UnreachableメッセージやＡＳ（Access Stratum）シグナリングなどを用いることができる。
あるいは同通知を基地局がＰＧＷに送信してもよく、これを受けてＰＧＷは、該当するパケットについて、先に説明したパケット廃棄通知をＵＥに送信する。通知を受けたＵＥは、先に示したのと同様の手順により、パケットリカバリ処理を開始する。すなわち、廃棄されたパケットの再送要求を送信元端末に対して実施したり、廃棄されたパケットのデータをアプリケーションレベルで補間して再送を不要としたりする。
次に、本発明の第２の実施の形態に係る移動端末（ＵＥ）の動作の一例について図１２、図１３を用いて説明する。図１２は本発明の第２の実施の形態に係るＵＥの構成の一例を説明するための構成図である。基本的な構成要素は、図５において説明したものであるが、第２の実施の形態に係るＵＥの構成において唯一異なるのは、第２の実施の形態の特徴であるアクセスＮＷ（ネットワーク）状態検出部１２０７を有していることである。アクセスＮＷ状態検出部１２０７は、ＵＥが接続しているアクセスネットワークの状態、すなわちトラフィックの混雑状況や収容端末の過密状態などを推定し、基地局においてベアラＱｏＳの維持が可能であるかを推測する。
本発明による方法は、主に通信制御部１２０２に実装されるものとして、その動作の一例について図１３を用いて説明する。なお、ステップＳ１３０１からＳ１３０７に示した処理は、第１の実施の形態において説明したステップＳ６０１からＳ６０７とそれぞれ同じ処理であるので、ここでは説明を割愛する。
ステップＳ１３０１、Ｓ１３０２を経てＰＤＮコネクションを確立した後、アクセスＮＷ状態検出部１２０７は、先に示したような手順に基づいてアクセスネットワークの状態を検出する（アクセスネットワークが不安定か：ステップＳ１３０８）。その結果、基地局をはじめとするアクセスネットワークにおいてベアラＱｏＳの維持が困難となる可能性があり、基地局（あるいはアクセスネットワーク内のその他のノード）によってベアラが独自に解放されうることを察知して、それを抑止するようＰＧＷに通知して、パケットフィルタを更新する（ステップＳ１３０９）。
具体的には、先に説明したように、解放されたくないベアラに対してベアラ解放抑止フラグ（あるいは相当の情報）をＯＮにしたパケットフィルタ（エントリ）を、ベアラリソース修正手順を通じてＰＧＷに登録する。ここで登録するパケットフィルタエントリが、ＰＧＷのＴＦＴに既存のものとマッチする場合、ＰＧＷはそれを更新する（少なくともベアラ解放抑止フラグをＯＮにする）。マッチしない場合、ＰＧＷは新規のエントリを作成する。
なお、上記ベアラ解放抑止のためのパケットフィルタ更新は、特に通信中であり解放されては困るベアラについて実施するものであってもよい。これによって、本来解放されても影響のないベアラにまで解放抑止を実施させる必要がなくなり、要求のためのパケットフィルタ更新を行わないでよいことから、通信トラフィックの低減やＵＥ、ＭＭＥ、ＰＧＷなどネットワークノードの処理負荷低減を図ることができる。
また、常にすべてのベアラについて解放抑止させたい場合は、一括要求するものであってもよい。すなわち、全ベアラを対象とする識別子を設けるなどして、全ベアラに対して解放抑止フラグをＯＮにしたパケットフィルタエントリを構築して、ＰＧＷに登録してもよい。
一方、通信部１２０１において受信したメッセージがベアラ解放通知メッセージか否か（ステップＳ１３１０）で、ベアラ解放通知メッセージであった場合、通信制御部１２０２が、メッセージに含まれる情報から解放されようとしているベアラ識別子を抽出し、当該ベアラに対してベアラＱｏＳを下方修正するためのベアラリソース修正手順を実施する（ベアラＱｏＳ調整：ステップＳ１３１１）。例えば、それまでＧＢＲ＝１０Ｍｂｐｓだったベアラに対して、ＧＢＲ＝５Ｍｂｐｓとするようなベアラリソース修正要求メッセージ（Request Bearer Resource Modification）を通信部１２０１を介して送信する。
ここで、ＧＢＲ以外のパラメータを修正してもよい。例えば、ＭＢＲ値の下方修正であったり、遅延プロファイルを大きめに設定したりしてもよいし、ＱＣＩ自体をより制限の緩いものに変更するものであってもよい。こうして、主にＱｏＳパラメータを調整して、ベアラ容量などを下方修正することで、自身が保有するベアラの解放を回避できるのみならず、アクセスネットワーク全体のトラフィックも低減させることができる。
次に、本発明の第２の実施の形態に係るゲートウェイ装置（ＰＧＷ）の動作の一例について図１４、図１５を用いて説明する。図１４は本発明の第２の実施の形態に係るＰＧＷの構成の一例を説明するための構成図である。基本的な構成要素は、図７において説明したものであるが、第２の実施の形態におけるＰＧＷの構成において唯一異なるのは、本発明の第２の実施の形態の特徴であるベアラ解放抑止部１４０６を有していることである。
第２の実施の形態における特徴的な方法は、主にベアラ解放抑止部１４０６に実装されるものとして、その動作の一例について図１５を用いて説明する。なお、ステップＳ１５０１からＳ１５０２、またＳ１５０４からＳ１５０７に示した処理は、第１の実施の形態において説明したステップＳ８０１からＳ８０２、またＳ８０３からＳ８０６とそれぞれ同じ処理であるので、ここでは説明を割愛する。
ステップＳ１５０１、Ｓ１５０２を経てＵＥがＰＤＮに接続するためのＰＤＮコネクションを確立した後、通信部１４０１がコアネットワーク側からパケット／メッセージを受信したか否か（ステップＳ１５０３）を判断し、コアネットワーク側からメッセージを受信したと判断する（ステップＳ１５０８）と、パケットフィルタを更新するための非特許文献２に示すようなベアラリソース修正要求メッセージか否か（パケットフィルタ更新か：ステップＳ１５０９）を判断され、ベアラリソース修正要求メッセージであった場合は、通信制御部１４０２を介してフィルタ管理部１４０３に転送する。フィルタ管理部１４０３は、ＵＥから通知されたパケットフィルタをＴＦＴに登録する（ＴＦＴ更新：ステップＳ１５１０）。
このとき、ＵＥが通知したパケットフィルタではベアラ解放抑止フラグがＯＮに設定されており、したがって、ＴＦＴにもベアラ解放抑止フラグが有効設定されたパケットフィルタが登録される。
また、通信制御部１４０２は、受信したメッセージが、アクセスネットワーク、特に基地局が発行したベアラ解放要求に起因するベアラ解放メッセージ、具体的には、例えば非特許文献２に示されるベアラ削除コマンド（Delete Bearer Command）メッセージか否か（ベアラ解放メッセージか：ステップＳ１５１１）を判断し、ベアラ削除コマンドメッセージであった場合、フィルタ管理部１４０３が管理するＴＦＴを参照して、そのベアラにマッチするパケットフィルタエントリにベアラ解放抑止フラグが設定されているか確認する（ベアラ解放抑止フラグあるか：ステップＳ１５１３）。
ベアラ解放抑止フラグが設定されていない場合（すなわち、ＯＦＦに設定されている場合）は、通常のベアラ解放処理を実施する（ステップＳ１５１４）。例えば、非特許文献２に示されるように、ベアラ削除コマンドメッセージを受信したＰＧＷの通信制御部１４０２は、ＰＣＲＦに対してＩＰ−ＣＡＮセッション修正手順（PCEF initiated IP-CAN Session Modification Procedure）を実行し、ベアラ削除要求（Delete Bearer Request）メッセージをＳＧＷに送信する。そして、続けてＳＧＷから受信するベアラ削除応答（Delete Bearer Response）メッセージを受けて、指定されたベアラコンテキストやリソースを解放する。
ベアラ解放抑止フラグが有効（ＯＮ）に設定されている場合は、ベアラ解放抑止部１４０６が、ベアラ解放抑止処理を実施する（ステップＳ１５１５）。具体的には、ベアラ解放抑止部１４０６が、例えば非特許文献２に示されるようなベアラ削除要求（Delete Bearer Request）メッセージの送信を一時的に停止あるいは拒否するよう通信制御部１４０２に指示して、実施されているベアラ解放処理を一時的に中断あるいは拒否させる。これを受けて、通信制御部１４０２は、ベアラ解放処理のステートを、一時中断を示す状態に遷移させるか、ベアラ解放処理を拒否あるいは失敗となったことを示す、非特許文献４に示すようなベアラ削除失敗通知（Delete Bearer Failure Indication）メッセージをＳＧＷに送信する。
さらに、ベアラ解放抑止部１４０６は、ベアラ解放通知メッセージを通信制御部１４０２経由でＵＥに送信する。これを受けてＵＥは、切断対象となっているベアラの存在に気づき、対象ベアラを存続させるために、ベアラのＱｏＳ調整を開始するため、例えば非特許文献２に示されるようなベアラリソース修正要求（Request Bearer Resource Modification）メッセージを送信し、その結果、ＰＧＷの通信部１４０１は、ベアラリソースコマンド（Bearer Resource Command）メッセージを受信し、非特許文献２に示される方法により、ベアラリソース修正処理が通信制御部１４０２によって適正に実施される。
ベアラ解放通知メッセージには、適正なＱｏＳパラメータを記載してもよい。例えば、現在のアクセスネットワークにおける、ベアラ維持可能な伝送容量やＱＣＩ値などをＭＭＥやＡＡＡサーバを通じて取得できる場合、それらの取得した値をベアラ解放通知メッセージに記載してＵＥに通知する。これによって、ＵＥは現在のアクセスネットワーク状態に応じてベアラＱｏＳを調整してベアラを維持することができるようになり、ひいてはセッション切断を回避してユーザ利便性を向上させることができる。
ＵＥによるベアラＱｏＳ調整処理、すなわちベアラリソース修正処理が完了すると、ベアラ解放抑止部１４０６は、先に中断させていたベアラ解放処理を失敗させるよう通信制御部１４０２に指示し、これを受けて通信制御部１４０２は、非特許文献４に示すようなベアラ削除失敗通知（Delete Bearer Failure Indication）メッセージを用いて、ベアラ解放処理を終了させる。ここで、ベアラリソース修正処理が失敗した場合は、ベアラ解放処理を継続して実施するものであってもよい。すなわち、ベアラリソース修正処理が成功したときのみ一時中断していたベアラ解放処理を失敗させ、ベアラリソース修正処理が失敗したときは、一時中断していたベアラ解放処理を継続実施して対象ベアラを解放させる。
ＱｏＳ調整が失敗して、アクセスネットワーク（特に基地局）がそもそもサポートできないとしたＱｏＳを有するベアラを維持させるのはシステム運用の点で望ましくないことからベアラの解放を決断する。これにより、システムに過度の負荷がかかるのを回避することができ、システム効率の向上を図ることができる。
なお、コアネットワーク側から受信したメッセージが、上記いずれにも該当しないメッセージであった場合は、別途規定される然るべき処理が実施される（対応するメッセージ処理：ステップＳ１５１２）。
上述した第２の実施の形態に係る発明によれば、移動端末に割り当てられた通信品質（ＱｏＳ保証値）が維持できないことによってベアラが解放されることを回避するベアラ解放回避方法であって、ゲートウェイ装置が、前記移動端末が接続する基地局によるベアラ解放が開始されたことを検出し、前記ベアラ解放が開始された旨のベアラ解放通知メッセージを前記移動端末へ送信するステップと、前記移動端末が、前記ベアラ解放通知メッセージに基づいて、割り当てられた前記通信品質を修正する処理を行うステップとを、有するベアラ解放回避方法が提供される。
また、第２の実施の形態に係るベアラ解放回避方法において、前記移動端末が、前記基地局との無線通信状態の悪化を判断し、前記ベアラ解放通知メッセージを前記移動端末自身に送信すべき旨の情報（フラグ）を前記ゲートウェイ装置に登録し、前記ゲートウェイ装置が、前記送信すべき旨の情報に基づいて前記ベアラ解放通知メッセージを前記移動端末へ送信することは、好ましい態様である。
また、第２の実施の形態に係るベアラ解放回避方法において、前記移動端末が、前記基地局が属するアクセスネットワークのトラフィック状態の悪化の通知を受けて、前記ベアラ解放通知メッセージを前記移動端末自身に送信すべき旨の情報（フラグ）を前記ゲートウェイ装置に登録し、前記ゲートウェイ装置が、前記送信すべき旨の情報に基づいて前記ベアラ解放通知メッセージを前記移動端末へ送信することは、好ましい態様である。
また、第２の実施の形態に係る発明によれば、移動端末と、前記移動端末の通信相手装置と前記移動端末との通信経路上に配置されたゲートウェイ装置とを備え、前記移動端末に割り当てられた通信品質が維持できなくなることによるベアラの解放を回避するベアラ解放回避システムであって、ゲートウェイ装置が、前記移動端末が接続する基地局によるベアラ解放が開始されたことを検出し、前記ベアラ解放が開始された旨のベアラ解放通知メッセージを前記移動端末へ送信し、前記移動端末が、前記ベアラ解放通知メッセージに基づいて、割り当てられた前記通信品質を修正する処理を行うベアラ解放回避システムが提供される。
また、第２の実施の形態に係るベアラ解放システムにおいて、前記移動端末が、前記基地局との無線通信状態の悪化を判断し、前記ベアラ解放通知メッセージを前記移動端末自身に送信すべき旨の情報（フラグ）を前記ゲートウェイ装置に登録し、前記ゲートウェイ装置が、前記送信すべき旨の情報に基づいて前記ベアラ解放通知メッセージを前記移動端末へ送信することは、好ましい態様である。
また、第２の実施の形態に係るベアラ解放システムにおいて、前記移動端末が、前記基地局が属するアクセスネットワークのトラフィック状態の悪化の通知を受けて、前記ベアラ解放通知メッセージを前記移動端末自身に送信すべき旨の情報（フラグ）を前記ゲートウェイ装置に登録し、前記ゲートウェイ装置は、前記送信すべき旨の情報に基づいて前記ベアラ解放通知メッセージを前記移動端末へ送信することは、好ましい態様である。
また、第２の実施の形態に係る発明によれば、移動端末に割り当てられた通信品質（ＱｏＳ保証値）が維持できないことによってベアラが解放されることを回避する前記移動端末であって、前記移動端末自身が接続する基地局によるベアラ解放が開始されたことを検出するゲートウェイ装置によって送信された、前記ベアラ解放が開始された旨のベアラ解放通知メッセージを受信する受信手段と、受信した前記ベアラ解放通知メッセージに基づいて、割り当てられた前記通信品質を修正する処理を行う処理手段とを、備える移動端末が提供される。
また、第２の実施の形態に係る発明によれば、移動端末に割り当てられた通信品質（ＱｏＳ保証値）が維持できないことによってベアラが解放されることを回避するゲートウェイ装置であって、前記移動端末が接続する基地局によるベアラ解放が開始されたことを検出する検出手段と、前記検出により、前記ベアラ解放が開始された旨のベアラ解放通知メッセージを生成するメッセージ生成手段と、生成された前記ベアラ解放通知メッセージを前記移動端末へ送信する送信手段とを、備えるゲートウェイ装置が提供される。
また、第２の実施の形態に係るゲートウェイ装置において、前記検出手段が、前記ベアラ解放の開始を検出した後、前記ベアラ解放の処理を中断させることは、好ましい態様である。
＜第３の実施の形態＞
本発明の第３の実施の形態の詳細な動作について説明する。図１６は本発明の第３の実施の形態によるシステム構成を説明するための図であり、アクセスネットワーク１０と、コアネットワーク２０と、パケットデータネットワーク（ＰＤＮ）３０と、アクセスネットワーク１０に接続してコアネットワーク２０経由でＰＤＮ３０と接続する移動端末（ＵＥ）１００と、ＰＤＮ３０を介して移動端末１００と通信を行う通信相手（ＣＮ：Correspondent Node）３００と、また、移動端末１００がＰＤＮ３０に接続する際の接続制御を行うゲートウェイ装置（ＰＧＷ：PDN Gateway）２００と、ＰＧＷ２００に対してアクセスネットワーク１０に対する移動端末１００の局所的な接続制御を実施する局所ゲートウェイ装置（ＳＧＷ：Serving Gateway）６００と、移動端末１００の移動管理を行う移動管理装置（ＭＭＥ：Mobility Management Entity）５００と、移動端末１００に対するアクセスネットワーク１０の直接的なアタッチポイントとなる移動基地局（ＲＮ：Relay Node）８００と、移動基地局８００のアクセスネットワーク１０におけるアタッチポイントとなる基地局装置（DｅＮＢ：Donor evolved Node B）４００と、移動基地局８００の移動管理を行う移動管理装置（ＲＮ−ＭＭＥ）９００とが配備される。
本発明の第３の実施の形態では、第２の実施の形態で説明した内容に加え、さらに新たな課題を解決するものである。すなわち、図１６において、通信エリア拡充を主な目的として移動基地局ＲＮ８００が導入される場合、ＲＮ８００はアクセスネットワーク１０における基地局ＤｅＮＢ４００にアタッチして無線ベアラを確立し、配下の移動端末ＵＥ１００によるシグナリング及びユーザデータトラフィックを収容する。ＵＥ１００はＲＮ８００にアタッチして無線ベアラおよびＰＧＷとのコネクション（ＰＤＮコネクション）を確立し、ＣＮ３００と通信を行う。
こうした状況において、ＲＮ８００によるアクセスネットワークのカバレッジ向上に伴い、アクセスネットワークにおける端末収容数を増加できる一方で、ＲＮ８００を直接的に、またＵＥ１００を間接的に収容するＤｅＮＢ４００においてリソース消費の増加が懸念される。これにより、リソース不足を理由にＤｅＮＢ４００がＲＮ８００のＧＢＲベアラを解放するような状況が、より発生しやすくなるものと想定される。この場合、ＵＥ１００がＲＮ８００との無線リンク状態の悪化から第２の実施の形態にて説明したベアラ切断抑制制御を行い、ＲＮ８００によるＧＢＲベアラ解放を抑止することは可能である。
しかし、実際には、ＲＮ８００とＤｅＮＢ４００との間の無線リンク状態の悪化により、ＤｅＮＢ４００がＲＮ８００のＧＢＲベアラを解放してしまうことも想定され、ＵＥ１００による判断だけではＤｅＮＢ４００によるベアラ解放まで抑止するのは不可能である。別の例では、ＵＥ１００とＲＮ８００間の通信状態は良好であっても、ＲＮ８００とＤｅＮＢ４００間の通信状態が悪化しているかもしれない。このときＵＥ１００はベアラ解放を抑止する制御を実施しないので、ＲＮ８００のベアラが解放されることにより、結果的にＵＥ１００のベアラも解放されてしまう。
ＵＥ１００がＲＮ８００とＤｅＮＢ４００間の無線リンクの状態を監視するのは、技術的に困難さを伴う。例えば、ＵＥ１００は、ＵＥ１００がアタッチしているＲＮ８００がどのＤｅＮＢ４００にアタッチしているかを、リアルタイムに判別する必要がある。ＲＮ８００は移動可能であるため、複数のＤｅＮＢ４００間をハンドオーバすることもある。こうした状況は、ＲＮ８００に接続中のＤｅＮＢ４００に関する情報を定期的あるいはハンドオーバの都度通知させる、などにより可能ではある。
しかしながら、さらにＵＥ１００は、自身の通信処理と並行して（例えば、無通信や応答待ちの時間を利用して）ＲＮ８００とＤｅＮＢ４００間の無線状況を監視する必要がある。ＲＮ８００とＤｅＮＢ４００間は、ＵＥ１００とＲＮ８００間の接続とは異なる周波数で接続されることもあり、その場合ＵＥ１００は通信デバイスの周波数サーチならびに周波数切り替え、同期、報知情報の読み出し、等の処理を行うことになるため、自身の通信への影響が大きい（例えば、データレート低減）、バッテリ消費量が増加、などの問題が発生する。
したがって、本発明では、ＵＥ１００とＲＮ８００間、およびＲＮ８００とＤｅＮＢ４００間の無線状況に応じて所定の通信ベアラが不意に解放（リリース）されることを防ぐ方法について説明する。
以下、図１７を用いて本発明の第３の実施の形態による方法の動作について詳しく説明する。図１７は、本発明の第３の実施の形態におけるベアラ解放回避方法の一例を説明するためのシーケンスチャートである。
まず、ＲＮ８００がアタッチ手順を実施する（ステップＳ１７００）。これによってＲＮ８００とＤｅＮＢ４００の間に、ＵＥ１００を収容するための無線ベアラを確立する。ＲＮ８００のモビリティはＲＮ−ＭＭＥ９００が管理する。ＲＮ８００がＵＥ１００を収容する準備（無線ベアラの確立など）を終えると、ＵＥ１００がＲＮ８００を介してＰＤＮ３０へのアタッチ手順を実施する（ステップＳ１７０１）。これにより、ＵＥ１００、ＲＮ８００、ＳＧＷ６００、ＰＧＷ２００を経由するＰＤＮコネクション（ＥＰＳベアラ）が確立され、ＣＮ３００と通信（データパケットの送受信）を行うことができるようになる（ステップＳ１７０２）。なお、ステップＳ１７００及びステップＳ１７０１のアタッチ手順は、単に無線ベアラやＰＤＮコネクションを追加するための手順であってもよく、その場合は手順の名称がアタッチ手順とは異なることがある（例えば、ベアラ追加手順やＰＤＮコネクション追加手順など）。
続いてＵＥ１００は、ベアラ解放抑止フラグを含むパケットフィルタ更新メッセージを送信する（ステップＳ１７０４）。このメッセージは、ＭＭＥ５００を介してＰＧＷ２００に配送される。なお、ＵＥ１００はアクセスシステムの状態を評価した結果、パケットフィルタ更新メッセージを送信するものであってもよい（ステップＳ１７０３）。アクセスシステムの状態評価は、第２の実施の形態にて説明したのと同じものであり、ＲＮ８００とＵＥ１００間の無線状態に基づき、適切なタイミングでＲＮ８００によるベアラ解放を抑止させることができる。また、ＵＥ１００は、ＲＮ８００との間の無線状態の善し悪しによらず、新たにＰＤＮコネクションを確立した直後にパケットフィルタ更新メッセージを送信するものであってもよい。これによって、ＲＮ８００とＤｅＮＢ４００間の無線状態の悪化によってＤｅＮＢ４００がＲＮ８００のベアラを解放する場合にも対応させることができる。
ＰＧＷ２００は、パケットフィルタ更新メッセージを受信すると、該当するＵＥ１００のＰＤＮコネクションに関するパケットフィルタを更新する（ステップＳ１７０５）。すなわち、対象であるＰＤＮコネクションのパケットフィルタエントリに、ベアラ解放抑止フラグを付加する。
次に、ＲＮ８００がＵＥ１００のベアラ解放を実施する場合の抑止処理について説明する。ＲＮ８００が、ＵＥ１００のベアラに対してＱｏＳ維持が難しいことなどを理由にベアラ解放を決定すると（ステップＳ１７０６）、ベアラ解放手順（Dedicated Bearer Deactivation Procedure）を開始する。すなわち、ＲＮ８００がベアラ解放指示メッセージ（Bearer Release Indication）をＭＭＥ５００に送信する（ステップＳ１７０７）。これを受けて、ＭＭＥ５００がベアラ削除コマンドメッセージ（Delete Bearer Command）をＳＧＷ６００に送信すると、ＳＧＷ６００はそれをＰＧＷ２００に転送する（ステップＳ１７０８）。
ＰＧＷ２００は、ベアラ削除コマンドメッセージを受信すると、メッセージから削除対象のベアラ（ベアラＩＤ等で識別する）を確認し、ＴＦＴ並びにパケットフィルタを参照して、そのベアラに対してベアラ解放抑止が設定されているかを確認する（ベアラ解放抑止の設定の確認：ステップＳ１７０９）。削除対象のベアラに対してベアラ解放抑止が設定されていない場合、ＰＧＷ２００は通常の（すなわち、非特許文献２に示されるような）ベアラ解放手順を継続し、対象ベアラは解放される。削除対象のベアラに対してベアラ解放抑止が設定されている場合、ＰＧＷ２００は実施中のベアラ解放手順を中断（停止）し、ＵＥ１００にベアラ解放手順が実施されていることを通知する（ベアラ解放通知メッセージ：ステップＳ１７１０）。
ベアラ解放通知メッセージには、解放対象のベアラＩＤを記載してもよい。また、特にベアラＩＤを記載しない場合でも、対象ベアラに関連するシグナリングプレーンやユーザプレーン上にベアラ解放通知メッセージを流すことによって、ＵＥ１００が対象ベアラを特定できるようにするものであってもよい。
ＵＥ１００がベアラ解放通知メッセージを受信すると、ＲＮ８００が発行したベアラ解放を停止させて通信フローを維持させるため、対象ベアラのＱｏＳ値を減少させる設定を行う。具体的には、非特許文献２に示すようなベアラリソース修正手順（UE requested bearer resource modification procedure）を実施して、ネットワークに新たなＱｏＳ値を設定する。すなわちＵＥ１００は、ベアラリソース修正要求メッセージを送信する（ステップＳ１７１１）。ＭＭＥ５００がこれを受信すると、ＳＧＷ６００にベアラリソースコマンドメッセージを送信し、ＳＧＷ６００はそれをＰＧＷ２００に転送する（ステップＳ１７１２）。
これを受けてＰＧＷ２００は、非特許文献２に示すようなＰＧＷ主導ベアラ修正手順（PGW initiated bearer modification procedure）を起動して、先に解放対象となったＵＥ１００のベアラに対するＱｏＳ設定を実行する（ＰＧＷ主導ベアラ修正手順を起動：ステップＳ１７１３）。ＱｏＳ設定が完了すると、ＰＧＷ２００は、先に停止させていたベアラ解放手順に対して、処理が失敗した旨の応答を送信する。
これは、例えば非特許文献４に示されるようなベアラ削除失敗通知（Delete Bearer Failure Indication）メッセージである。これにより、ＳＧＷ６００やＭＭＥ５００、基地局４００は、ベアラ解放処理を実施することなく処理を完了する。ＵＥ１００は、要求したＱｏＳ設定に基づいて更新されたベアラを用いて通信を継続させることができる。
ここで、ＲＮ８００は既存の基地局（ｅＮＢ）とは異なり、今後普及が見込まれる装置である。このことから、本発明による機能を搭載させることが可能であると考える。すなわち、ＵＥ１００が送信するパケットフィルタ更新メッセージにベアラ解放抑止フラグが付加されていることを判別して、処理の最適化を行うことが可能である。具体的には、ベアラ解放抑止フラグを付加したパケットフィルタ更新メッセージ（これはＮＡＳメッセージとして処理される）を送信する際に、当該メッセージを転送するためのＲＲＣメッセージにその旨を示す情報を付加して送信する。
例えば、ＲＲＣメッセージにも同様に、ベアラ解放抑止フラグを追加する。ここで、ベアラ解放抑止の対象となるベアラＩＤを追加してもよい（ＥＰＳベアラＩＤあるいは該当する無線ベアラＩＤ（例えばＤＲＢ識別子（DRB-ID））；ＲＮ８００は無線ベアラＩＤのみ評価するため、特別な変換処理が不要である後者（無線ベアラＩＤ）が望ましい）。ＲＮ８００はＲＲＣメッセージの情報を読み取って記憶し、それ以降に対象ベアラの解放を決断する際に、自発的に対象ベアラのＱｏＳを低下させて解放を抑止したり、ベアラ解放通知メッセージをＵＥ１００に送信したり（これによりＵＥ１００が対象ベアラのＱｏＳを調整）、あるいは無線状態のよい近隣基地局へハンドオーバ（特にマクロ基地局（ｅＮＢ）などへのハンドオーバ）させたりするなど、ＵＥ１００の対象ベアラを解放させずに済む処理を実施することもできる。
さらに、ＲＮ８００に本発明による機能を追加する場合、ＤｅＮＢ４００によるＲＮ８００のベアラ解放にも対応させることが可能である。これについて、ステップ１４以降で説明する。ＤｅＮＢ４００がＲＮ８００のベアラ解放を決定すると（ステップＳ１７１４）、ベアラ解放指示メッセージをＲＮ−ＭＭＥ９００に送信する（ステップＳ１７１５）。これを受けて、ＲＮ−ＭＭＥ９００はベアラ解放の実施を決定し、ベアラ解放要求メッセージをＤｅＮＢ４００に送信する（ステップＳ１７１６）。ＤｅＮＢ４００は、ＲＲＣコネクション再設定メッセージをＲＮ８００に送信する（ステップＳ１７１７）。ＲＮ８００は、対象ベアラの解放を受理し、解放処理を開始するとともに、ＲＲＣコネクション再設定完了メッセージをＤｅＮＢ４００に送信する（ステップＳ１７１８）。これを受けてＤｅＮＢ４００がベアラ解放応答メッセージをＲＮ−ＭＭＥ９００に送信する（ステップＳ１７１９）。
ここで、ＲＮ８００は解放対象であるベアラ（以下、RNベアラとも呼ぶ）が、先にＵＥ１００から抑止対象に指定されたＵＥ１００のベアラを収容するRNベアラであることを検出すると、そのＵＥ１００のベアラの収容先を他のRNベアラに切り替える（ステップＳ１７２０）。このとき、ＵＥ１００のベアラを収容可能なＱｏＳ能力を有するRNベアラに切り替える。あるいは、ＲＮ８００がＵＥ１００にベアラ解放通知メッセージを送信し、ＱｏＳリソースを削減するためのベアラリソース修正要求メッセージの送信を促してもよい。このとき、ベアラ解放通知メッセージに、ＲＮ８００において収容可能なＱｏＳパラメータを通知してもよい。
ＲＮ８００はＵＥ１００の対象ベアラの収容先切り替えを完了すると、解放対象であるＲＮ８００のベアラコンテキストを解放し、コンテキスト解放応答メッセージをＤｅＮＢ４００経由でＲＮ−ＭＭＥ９００に送信する（ステップＳ１７２１）。
なお、ＵＥ１００においてパケットフィルタ更新メッセージの送信を判断する際に、ＲＮ８００からの通信品質情報を用いてもよい。特に、ＲＮ８００がＤｅＮＢ４００−ＲＮ８００間の通信品質情報を含めてＵＥ１００に通知するような場合は、ＵＥ１００−ＲＮ８００−ＤｅＮＢ４００の無線状態をＵＥ１００が総合的に判断し、適したタイミングでベアラ解放抑止のためのフィルタ情報をＰＧＷ２００に設定することができ、永続的にベアラ解放抑止のための情報をネットワーク側装置に設定しておく必要がなくなる。これにより、ネットワーク側装置のリソース効率化を図ることができる。
さらには、ＲＮ８００がＤｅＮＢ４００−ＲＮ８００間の無線状態を、ＵＥ１００−ＲＮ８００間の無線リンクに反映してもよい。例えば、ＤｅＮＢ４００−ＲＮ８００間の無線リンクにおけるパケットロス数を、ＵＥ１００−ＲＮ８００間の無線リンク上で再現させたり（同じ数のパケットをあえてロスさせる）、ＤｅＮＢ４００がＲＮ８００に要求するのと同回数の再送要求をＵＥ１００に対して発行したり、ＤｅＮＢ４００−ＲＮ８００間の無線リンクと同等のアクセス状態（例えば、アクセス成功頻度、送受信成功頻度など）となるように、ＵＥ１００に対するスロット割当て頻度を調整（例えば、意図的に下げる）したりすることにより、ＤｅＮＢ４００−ＲＮ８００間の無線状態を擬似的にＵＥ１００−ＲＮ８００間の無線リンクに再現させる。これにより、ＲＮ８００がＵＥ１００にＤｅＮＢ４００−ＲＮ８００間の無線状態を明示的に通知する必要がなくなり、シグナリングトラフィックの削減を図ることができる。
また、ＵＥ１００からベアラ解放抑止フラグ付きのパケットフィルタ更新メッセージが送信された際に、ＵＥ１００とＲＮ８００間の無線品質は悪化しているが、ＲＮ８００とＤｅＮＢ４００間の無線品質が良好であることをＲＮ８００が検出した場合、ＲＮ８００はＵＥ１００に対する無線品質を向上させてもよい（例えば、ＲＮ８００をＵＥ１００に近い位置に移動させる、ＵＥ１００に対するリソース割り当てを増加する、など）。さらには、ＵＥ１００からのパケットフィルタ更新メッセージを転送せずに破棄してもよい。これにより、不要なシグナリングによるトラフィック増加を抑えるとともに、ＰＧＷ２００による監視負荷を低減させることができる。
また、ＲＮ８００を運用停止する等の場合、ＲＮ８００あるいはＭＭＥ５００は、ＵＥ１００からのベアラ解放抑止フラグ付きのパケットフィルタ更新メッセージを拒否するものであってもよい。その際、ＵＥ１００に拒否理由（例えば、ＲＮ運用停止）を通知することで、ＵＥ１００からのメッセージ再送を回避することができる。
次に、本発明の第３の実施の形態に係る移動基地局（ＲＮ）の動作の一例について図１８、図１９を用いて説明する。図１８は本発明の第３の実施の形態に係るＲＮの構成の一例を説明するための構成図である。通信部８０３は、アクセスネットワーク１０においてＵＥ１００やＤｅＮＢ４００と接続して通信を行うための通信処理を実施し、具体的にはＵＥ１００やＤｅＮＢ４００、またアクセスネットワーク１０内の他のノードと通信するための通信プロトコル処理（ここではＩＰプロトコルを含む下位のプロトコル処理、例えばＮＡＳやＡＳ、ＲＲＣ処理を行うものとする）並びにモデム処理を実施する。
ＲＮ制御部８０１は、通信部８０３と連携しながら移動基地局（リレーノード）の動作を実施する。アクセスＮＷ状態検出部８０２は、ＲＮが接続しているアクセスネットワークの状態、すなわちトラフィックの混雑状況や収容端末の過密状態などを推定し、ＤｅＮＢにおいてベアラＱｏＳの維持が可能であるかを推測する。また、アクセスＮＷ状態検出部８０２では、ＵＥとの間の無線リンクの状態を検出することもできる。ベアラ管理部８０４は、本発明を実施するためのベアラ管理を行う。
本発明による方法は、主にベアラ管理部８０４に実装されるものとして、その動作の一例について図１９を用いて説明する。
ＲＮ８００は、ＲＮ制御部８０１の制御にもとづいて起動処理を行い、ＵＥベアラを収容するためのＲＮベアラを確立する（ステップＳ１９０１）。この処理は、通信部８０３を介して行われるアタッチ手順に相当する。続いて、受信するデータ（メッセージ）が、ＵＥからのベアラ解放抑止のためのパケットフィルタ更新メッセージであるかを判定する（ステップＳ１９０２）。この判定処理の詳細については、先に説明した通りである。パケットフィルタ更新メッセージであった場合は、解放抑止の対象となるベアラＩＤを抽出・格納し（ステップＳ１９０３）、上位ノード（ここではＤｅＮＢ４００）にメッセージを転送する（ステップＳ１９０４）。
受信データがパケットフィルタ更新メッセージではない場合は、さらにそのメッセージがＲＲＣコネクション再設定メッセージであるかを判定する（ステップＳ１９０５）。ＲＲＣコネクション再設定メッセージである場合は、対応する処理の実施し、ＲＲＣコネクション再設定完了メッセージを送信する（ステップＳ１９０６）。ここで、ＲＲＣコネクション再設定の対象であるＲＮベアラが、解放抑止対象であるＵＥベアラに対応するもの（解放抑止対象であるＵＥベアラを収容するもの）であるかを判定する（ステップＳ１９０７）。
これは先にステップＳ１９０３で格納しておいたＵＥベアラＩＤとの対比により判定を実施する。解放抑止対象のＵＥベアラを収容するＲＮベアラが今回の解放対象である場合は、そのＵＥベアラを他のＲＮベアラに乗せ替える（切り替える）処理（具体的にはＵＥベアラコンテキストを新たなＲＮベアラにマッピングさせる処理）を行い（ステップＳ１９０８）、コンテキスト解放応答メッセージを送信する（ステップＳ１９０９）。対象ＵＥベアラがない場合は、ＵＥベアラの乗せ替えを行うことなくステップＳ１９０９を実施する。受信データがＲＲＣコネクション再設定メッセージではない場合は、対応するメッセージ処理を実施する（ステップＳ１９１０）。
なお、ＵＥ装置の構成ならびに動作は、先の実施の形態にて説明したもの（すなわち図１２、図１３に示した構成ならびに動作）と同じであるため説明を割愛する。また、ＰＧＷ装置の構成ならびに動作も、先に説明したもの（すなわち図１４、図１５に示した構成ならびに動作）と同じであるので説明を割愛する。
＜第４の実施の形態＞
本発明の第４の実施の形態の詳細な動作について説明する。図２０は本発明の第４の実施の形態によるシステム構成を説明するための図であり、アクセスネットワーク１０と、コアネットワーク２０と、パケットデータネットワーク（ＰＤＮ）３０と、アクセスネットワーク１０に接続してコアネットワーク２０経由でＰＤＮ３０と接続する移動端末（ＵＥ）１００と、ＰＤＮ３０を介して移動端末１００と通信を行う通信相手（ＣＮ：Correspondent Node）３００と、また、移動端末１００がＰＤＮ３０に接続する際の接続制御を行うゲートウェイ装置（ＰＧＷ：PDN Gateway）２００と、ＰＧＷ２００に対してアクセスネットワーク１０に対する移動端末１００の局所的な接続制御を実施する局所ゲートウェイ装置（ＳＧＷ：Serving Gateway）６００と、移動端末１００の移動管理を行う移動管理装置（ＭＭＥ：Mobility Management Entity）５００と、移動端末１００に対するアクセスネットワーク１０の直接的なアタッチポイントとなる移動基地局（ＲＮ：Relay Node）８００と、移動基地局８００のアクセスネットワーク１０におけるアタッチポイントとなる基地局装置（DｅＮＢ：Donor evolved Node B）４００と、移動基地局８００の移動管理を行う移動管理装置（ＲＮ−ＭＭＥ）９００と、移動基地局８００を収容するゲートウェイ装置（ＲＮ−Ｓ／ＰＧＷ）１０００とが配備される。
なお、ＲＮ−Ｓ／ＰＧＷ１０００は、ＰＧＷ２００とＳＧＷ６００を、説明の便宜上、一つの機能であるかのように取り扱うものであり、実際にＲＮ−ＳＧＷとＲＮ−ＰＧＷのように物理的あるいは論理的に異なる装置で構成されるものであってもよい。
本発明の第４の実施の形態では、第３の実施の形態で説明した新たな課題を、第３の実施の形態で説明したのとは異なる形態でＲＮを収容するネットワークシステムにおいて解決するものである。すなわち、第３の実施の形態ではＲＮがＳ１ベアラのみ有し、ＵＥのＳ１ベアラ及びＥＰＳベアラを収容していたのに対し、第４の実施の形態ではＲＮがＳ１ベアラとＥＰＳベアラを有し、ＵＥのＳ１ベアラとＥＰＳベアラを収容する点が異なる。
以下、図２１を用いて本発明の第４の実施の形態による方法の動作について詳しく説明する。図２１は、本発明の第４の実施の形態におけるベアラ解放回避方法の一例を説明するためのシーケンスチャートである。
まず、ＲＮ８００がアタッチ手順を実施する（ステップ２１０１）。これによってＲＮ８００とＲＮ−Ｓ／ＰＧＷ１０００の間にＥＰＳベアラを確立し、ＵＥ１００を収容することができるようになる。ＲＮ８００のモビリティはＲＮ−ＭＭＥ９００が管理する。ＲＮ８００がＵＥ１００を収容する準備を終えると、ＵＥ１００がＲＮ８００を介してＰＤＮ３０へのアタッチ手順を実施する（ステップＳ２１０２）。これにより、ＵＥ１００、ＲＮ８００、ＳＧＷ６００、ＰＧＷ２００を経由するＰＤＮコネクション（ＥＰＳベアラ）が確立され、ＣＮ３００と通信（データパケットの送受信）を行うことができるようになる（ステップＳ２１０３）。なお、ステップＳ２１０１及びステップＳ２１０２のアタッチ手順は、単にＰＤＮコネクション（ＥＰＳベアラ）を追加するための手順であってもよく、その場合は手順の名称がアタッチ手順とは異なることがある（例えば、ベアラ追加手順やＰＤＮコネクション追加手順など）。
続いてＵＥ１００は、ベアラ解放抑止フラグを含むパケットフィルタ更新メッセージを送信する（ステップＳ２１０５）。このメッセージは、ＭＭＥ５００を介してＰＧＷ２００に配送される。なお、ＵＥ１００はアクセスシステムの状態を評価した結果、パケットフィルタ更新メッセージを送信するものであってもよい（ステップＳ２１０４）。アクセスシステムの状態評価は、第２の実施の形態にて説明したのと同じものであり、ＲＮ８００とＵＥ１００間の無線状態に基づき、適切なタイミングでＲＮ８００によるベアラ解放を抑止させることができる。また、ＵＥ１００は、ＲＮ８００との間の無線状態の善し悪しによらず、新たにＰＤＮコネクションを確立した直後にパケットフィルタ更新メッセージを送信するものであってもよい。これによって、ＲＮ８００とＤｅＮＢ４００間の無線状態の悪化によってＤｅＮＢ４００がＲＮ８００のベアラを解放する場合にも対応させることができる。
ＰＧＷ２００は、パケットフィルタ更新メッセージを受信すると、該当するＵＥ１００のＰＤＮコネクションに関するパケットフィルタを更新する（ステップＳ２１０６）。すなわち、対象であるＰＤＮコネクションのパケットフィルタエントリに、ベアラ解放抑止フラグを付加する。なお、ＲＮ８００がＵＥ１００のベアラ解放を実施する場合の抑止処理は、第３の実施の形態にて説明した動作と同じであるので、ここでは説明を割愛する。
ここで、ＲＮ８００は既存の基地局（ｅＮＢ）とは異なり、今後普及が見込まれる装置である。このことから、本発明による機能を搭載させることが可能であると考える。すなわち、ＵＥ１００が送信するパケットフィルタ更新メッセージにベアラ解放抑止フラグが付加されていることを判別して、処理の最適化を行うことが可能である。具体的には、ベアラ解放抑止フラグを付加したパケットフィルタ更新メッセージ（これはＮＡＳメッセージとして処理される）を送信する際に、当該メッセージを転送するためのＲＲＣメッセージにその旨を示す情報を付加して送信する。
例えば、ＲＲＣメッセージにも同様に、ベアラ解放抑止フラグを追加する。ここで、ベアラ解放抑止の対象となるベアラＩＤを追加してもよい（ＥＰＳベアラＩＤあるいは該当する無線ベアラＩＤ（例えば、ＤＲＢ識別子（DRB-ID））；ＲＮ８００は無線ベアラＩＤのみ評価するため、特別な変換処理が不要である後者のＩＤが望ましい）。ＲＮ８００はＲＲＣメッセージの情報を読み取って記憶し、それ以降に対象ベアラの解放を決断する際に、自発的に対象ベアラのＱｏＳを低下させて解放を抑止したり、ベアラ解放通知メッセージをＵＥ１００に送信したり（これによりＵＥ１００が対象ベアラのＱｏＳを調整）、あるいは無線状態のよい近隣基地局へハンドオーバ（特にマクロ基地局（ｅＮＢ）などへのハンドオーバ）させたりするなど、ＵＥ１００の対象ベアラを解放させずにすむ処理を実施することもできる。
さらに、ＲＮ８００に本発明による機能を追加する場合、ＤｅＮＢ４００によるＲＮ８００のベアラ解放にも対応させることが可能である。これについて、ステップ７以降で説明する。ＲＮ８００がＵＥ１００によるベアラ解放抑止フラグを含むパケットフィルタ更新メッセージの送信を検出すると、解放抑止の対象となるベアラを特定する（ステップＳ２１０７）。これは、パケットフィルタ更新メッセージを転送するＵＥ１００の無線ベアラＩＤから、そのベアラを収容するＲＮ８００のベアラ（ＩＤ）を導き出すものであってもよいし、先に示したようにＵＥ１００からＲＲＣメッセージの中で指示されたベアラＩＤをもとに、そのベアラを収容するＲＮ８００のベアラ（ＩＤ）を導き出すものであってもよい。
続いてＲＮ８００は、ベアラ解放抑止フラグを含むパケットフィルタ更新メッセージを送信する（ステップＳ２１０８）。このメッセージは、ＲＮ−ＭＭＥ９００を介してＲＮ−Ｓ／ＰＧＷ１０００に配送される。ＲＮ−Ｓ／ＰＧＷ１０００（の特にＰＧＷ装置に相当する処理部）は、パケットフィルタ更新メッセージを受信すると、該当するＲＮ８００のＰＤＮコネクションに関するパケットフィルタを更新する（ステップＳ２１０９）。すなわち、対象であるＰＤＮコネクションのパケットフィルタエントリに、ベアラ解放抑止フラグを付加する。
ＤｅＮＢ４００が、ＲＮ８００のベアラに対してＱｏＳ維持が難しいことなどを理由にベアラ解放を決定すると（ステップＳ２１１０）、ベアラ解放手順（Dedicated Bearer Deactivation Procedure）を開始する。すなわち、ＤｅＮＢ４００がベアラ解放指示メッセージ（Bearer Release Indication）をＲＮ−ＭＭＥ９００に送信する（ステップＳ２１１１）。これを受けて、ＲＮ−ＭＭＥ９００がベアラ削除コマンドメッセージ（Delete Bearer Command）をＲＮ−Ｓ／ＰＧＷ１０００に送信する（ステップＳ２１１２）。
ＲＮ−Ｓ／ＰＧＷ１０００は、ベアラ削除コマンドメッセージを受信すると、メッセージから削除対象のベアラ（ベアラＩＤ）を確認し、ＴＦＴ並びにパケットフィルタを参照して、そのベアラに対してベアラ解放抑止が設定されているかを確認する（ベアラ解放抑止の設定の確認：ステップＳ２１１３）。削除対象のベアラに対してベアラ解放抑止が設定されていない場合、ＲＮ−Ｓ／ＰＧＷ１０００は通常の（すなわち非特許文献２に示されるような）ベアラ解放手順を継続し、対象ベアラは解放される。削除対象のベアラに対してベアラ解放抑止が設定されている場合、ＲＮ−Ｓ／ＰＧＷ１０００は実施中のベアラ解放手順を中断（停止）し、ＲＮ８００にベアラ解放手順が実施されていることを通知する（ベアラ解放通知メッセージ：ステップＳ２１１４）。
ベアラ解放通知メッセージには、解放対象のベアラＩＤを記載してもよい。また、特にベアラＩＤを記載しない場合でも、対象ベアラに関連するシグナリングプレーンやユーザプレーン上にベアラ解放通知メッセージを流すことによって、ＲＮ８００が対象ベアラを特定できるようにするものであってもよい。
ＲＮ８００がベアラ解放通知メッセージを受信すると、ＤｅＮＢ４００が発行したベアラ解放を停止させて通信フローを維持させるため、対象ベアラに対するＱｏＳ値を減少させる設定を行う。具体的には、非特許文献２に示すようなベアラリソース修正手順（UE requested bearer resource modification procedure）を実施して、ネットワークに新たなＱｏＳ値を設定する。すなわちＲＮ８００は、ベアラリソース修正要求メッセージを送信する（ステップＳ２１１５）。ＲＮ−ＭＭＥ９００がこれを受信すると、ＲＮ−Ｓ／ＰＧＷ１０００にベアラリソースコマンドメッセージを送信する（ステップＳ２１１６）。これを受けてＲＮ−Ｓ／ＰＧＷ１０００は、非特許文献２に示すようなＰＧＷ主導ベアラ修正手順（PGW initiated bearer modification procedure）を起動して、先に解放対象となったＲＮ８００のベアラに対するＱｏＳ設定を実行する（ＰＧＷ主導ベアラ修正手順を起動：ステップＳ２１１７）。ＱｏＳ設定が完了すると、ＲＮ−Ｓ／ＰＧＷ１０００は、先に停止させていたベアラ解放手順に対して、処理が失敗した旨の応答を送信する。
これは、例えば非特許文献４に示されるようなベアラ削除失敗通知（Delete Bearer Failure Indication）メッセージである。これにより、ＲＮ−Ｓ／ＰＧＷ１０００（の特にＳＧＷ装置に相当する処理部）やＲＮ−ＭＭＥ９００、ＤｅＮＢ４００は、ベアラ解放処理を実施することなく処理を完了する。ＲＮ８００は、要求したＱｏＳ設定に基づいて更新されたベアラを用いて通信を継続させることができる。
なお、ＲＮ８００は、ベアラ解放通知メッセージを受信したときに、そのベアラが収容するＵＥ１００のベアラの収容先を他のＲＮベアラに切り替えるものであってもよい。このとき、ＵＥ１００のベアラを収容可能なＱｏＳ能力を有するベアラに切り替える。あるいは、ＲＮ８００がＵＥ１００にベアラ解放通知メッセージを送信し、ＱｏＳリソースを削減するためのベアラリソース修正要求メッセージの送信を促してもよい。このとき、ベアラ解放通知メッセージに、ＲＮ８００において収容可能なＱｏＳパラメータを通知してもよい。ＲＮ８００はＵＥ１００の対象ベアラの収容先切り替えを完了すると、所定の手続きを用いて、解放対象であるＲＮ８００のベアラを解放する。
また、ＵＥ１００においてパケットフィルタ更新メッセージの送信を判断する際に、ＲＮ８００からの通信品質情報を用いてもよい。特に、ＲＮ８００がＤｅＮＢ４００−ＲＮ８００間の通信品質情報を含めてＵＥ１００に通知するような場合は、ＵＥ１００−ＲＮ８００−ＤｅＮＢ４００の無線状態をＵＥ１００が総合的に判断し、適したタイミングでベアラ解放抑止のためのフィルタ情報をＰＧＷ２００に設定することができ、永続的にベアラ解放抑止のための情報をネットワーク側装置に設定しておく必要がなくなる。これにより、ネットワーク側装置のリソース効率化を図ることができる。さらには、ＲＮ８００がＤｅＮＢ４００−ＲＮ８００間の無線状態を、ＵＥ１００−ＲＮ８００間の無線リンクに反映してもよい。
例えば、ＤｅＮＢ４００−ＲＮ８００間の無線リンクにおけるパケットロス数を、ＵＥ１００−ＲＮ８００間の無線リンク上で再現させたり（同じ数のパケットをあえてロスさせる）、ＤｅＮＢ４００がＲＮ８００に要求するのと同回数の再送要求をＵＥ１００に対して発行したり、ＤｅＮＢ４００−ＲＮ８００間の無線リンクと同等のアクセス頻度となるように、ＵＥ１００に対するスロット割当て頻度を調整（例えば、意図的に下げる）したりすることにより、ＤｅＮＢ４００−ＲＮ８００間の無線状態を擬似的にＵＥ１００−ＲＮ８００間の無線リンクに再現させる。これにより、ＲＮ８００がＵＥ１００にＤｅＮＢ４００−ＲＮ８００間の無線状態を明示的に通知する必要がなくなり、シグナリングトラフィックの削減を図ることができる。
また、ＵＥ１００からベアラ解放抑止フラグ付きのパケットフィルタ更新メッセージが送信された際に、ＵＥ１００とＲＮ８００間の無線品質は悪化しているが、ＲＮ８００とＤｅＮＢ４００間の無線品質が良好であることをＲＮ８００が検出した場合、ＲＮ８００はＵＥ１００に対する無線品質を向上させてもよい（例えば、ＲＮ８００をＵＥ１００に近い位置に移動させる、ＵＥ１００に対するリソース割り当てを増加する、など）。さらには、ＵＥ１００からのパケットフィルタ更新メッセージを転送せずに破棄してもよい。これにより、不要なシグナリングによるトラフィック増加を抑えるとともに、ＰＧＷ２００による監視負荷を低減させることができる。
また、ＲＮ８００を運用停止する等の場合、ＲＮ８００あるいはＭＭＥ５００は、ＵＥ１００からのベアラ解放抑止フラグ付きのパケットフィルタ更新メッセージを拒否するものであってもよい。その際、ＵＥ１００に拒否理由（例えば、ＲＮ運用停止）を通知することで、ＵＥ１００からのメッセージ再送を回避することができる。
次に、本発明の第４の実施の形態に係る移動基地局（ＲＮ）の動作の一例について図２２、図２３を用いて説明する。図２２は本発明の第４の実施の形態に係るＲＮの構成の一例を説明するための構成図である。通信部８１３は、アクセスネットワーク１０においてＵＥ１００やＤｅＮＢ４００と接続して通信を行うための通信処理を実施し、具体的にはＵＥ１００やＤｅＮＢ４００、またアクセスネットワーク１０内の他のノードと通信するための通信プロトコル処理（ここではＩＰプロトコルを含む下位のプロトコル処理、例えばＮＡＳやＡＳ、ＲＲＣ処理を行うものとする）並びにモデム処理を実施する。
ＲＮ制御部８１１は、通信部８１３と連携しながら移動基地局（リレーノード）の動作を実施する。アクセスＮＷ状態検出部８１２は、ＲＮが接続しているアクセスネットワークの状態、すなわちトラフィックの混雑状況や収容端末の過密状態などを推定し、ＤｅＮＢにおいてベアラＱｏＳの維持が可能であるかを推測する。また、アクセスＮＷ状態検出部８１２では、ＵＥとの間の無線リンクの状態を検出することもできる。ベアラ管理部８１４は、本発明を実施するためのベアラ管理を行う。フィルタ管理部８１５は、本発明を実施するためのパケットフィルタの構築と管理を行う。なお、通信部８１３は、フィルタ管理部８１５が構築したパケットフィルタ情報に基づいて、送信パケットを伝送するＰＤＮコネクションやベアラを決定する。
本発明による方法は、主にベアラ管理部８１４に実装されるものとして、その動作の一例について図２３を用いて説明する。ＲＮ８００は、ＲＮ制御部８１１の制御に基づいて起動処理を行い、ＵＥベアラを収容するためのＲＮベアラを確立する（ステップＳ２３０１）。この処理は、通信部８１３を介して行われるアタッチ手順に相当する。続いて、受信するデータ（メッセージ）が、ＵＥからのベアラ解放抑止のためのパケットフィルタ更新メッセージであるかを判定する（ステップＳ２３０２）。
この判定処理の詳細については、先に説明した通りである。パケットフィルタ更新メッセージであった場合は、解放抑止の対象となるベアラＩＤを抽出・格納し（ステップＳ２３０３）、上位ノード（ここではＤｅＮＢ４００）にメッセージを転送する（ステップＳ２３０４）。さらにフィルタ管理部８１５が、解放抑止対象であるＵＥベアラを収容するＲＮベアラに対してベアラ解放抑止フラグ（あるいは相当の情報）をＯＮにしたパケットフィルタ（エントリ）をＲＮ−Ｓ／ＰＧＷ１０００（のＰＧＷ装置に相当する処理部）に登録するためのパケットフィルタ更新メッセージを生成して送信する（ステップＳ２３０５）。
受信データがパケットフィルタ更新メッセージではない場合は、さらにそのメッセージがベアラ解放通知メッセージであるかを判定する（ステップＳ２３０６）。ベアラ解放通知メッセージである場合は、第２の実施の形態において説明したＵＥ１００が実施するベアラＱｏＳの調整処理と同等の処理を、ベアラ解放通知メッセージによって通知される対象ＲＮベアラに対して実施する（ステップＳ２３０７）。受信データがベアラ解放通知メッセージではない場合は、対応するメッセージ処理を実施する（ステップＳ２３０８）。
なお、ＵＥ装置の構成ならびに動作は、先の実施の形態にて説明したもの（すなわち図１２、図１３に示した構成ならびに動作）と同じであるため説明を割愛する。また、ＰＧＷ装置の構成ならびに動作も、先に説明したもの（すなわち図１４、図１５に示した構成ならびに動作）と同じであるので説明を割愛する。
なお、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えばバイオ技術の適応などが可能性としてあり得る。
また、上記各実施の形態においては、パケット受信する通信ノードを特に移動端末１００としたが、移動端末１００は特に移動を伴ったり、移動に対応する機能を有するノードである必要はなく、特定の場所に据え付けられたノードであったり、移動に対応する機能を有しないノード、また移動を伴わないノードであってもよい。
また、上記各実施の形態において説明したパケット廃棄通知メッセージやベアラ解放通知メッセージは、単体のメッセージである必要はなく、パケット廃棄を通知する情報やベアラ解放を通知する情報を含むフィールドを有する他のメッセージであってもよい。例えば、他の目的を持つメッセージにパケット廃棄やベアラ解放を通知するための情報を含むフィールドを重畳したようなものであってもよい。
本発明のパケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置（ゲートウェイ装置）は、ＰＧＷ２００が所定のＱｏＳ値を超える流量のパケットを廃棄する際に、廃棄パケットが対応付けられるベアラとそのベアラを保有するＵＥ１００を容易に特定できるので、ＰＧＷ２００の負荷を特に増加させることなく、パケット廃棄（パケット廃棄タイミング）をリアルタイムにＵＥ１００に通知して、ＵＥ１００が再送要求などのパケットリカバリ処理を実施することで通信効率を向上させることができ、また、ＵＥ１００が設定するＴＦＴを参照して、パケット廃棄通知の要否を確認することにより、ＵＥ１００が必要とする通信フローのパケット廃棄だけを通知することができ、コアネットワークやアクセスネットワークのトラフィックを無意味に増加させたり、ＵＥ１００やＰＧＷ２００自身の処理負荷を無意味に増加させたりすることなく、適した通信フローの状態をＵＥ１００に通知して、適正に再送制御処理を実施させることができるので、パケット通信においてパケットロスが発生した際に迅速な復旧を行わせるためのパケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置（ゲートウェイ装置）などに有用である。

Claims (18)

  1. 移動端末と前記移動端末の通信相手装置との間で送受信されるパケットのうち、前記移動端末と前記通信相手装置との通信経路上に配置された中間装置によって廃棄されたパケットを回復するためのパケット回復方法であって、
    前記中間装置が、パケットを廃棄したことを通知する廃棄通知メッセージの送信を必要とする通信フローの情報に基づいて前記廃棄通知メッセージを前記移動端末へ送信するステップと、
    前記移動端末が、前記廃棄通知メッセージに基づいて、廃棄された前記パケットの再送を要求する再送要求メッセージを前記通相手信装置へ送信するステップとを、
    有するパケット回復方法。
  2. 前記移動端末は、前記通信フローの情報を前記中間装置に事前に登録する請求項１に記載のパケット回復方法。
  3. 前記通信フローの情報は、前記移動端末が通信を行っているポート番号単位で登録される請求項２に記載のパケット回復方法。
  4. 前記通信フローの情報は、前記移動端末が通信を行っている通信相手のアドレス単位で登録される請求項２に記載のパケット回復方法。
  5. 前記通信フローの情報は、前記移動端末が通信を行っているプロトコル単位で登録される請求項２に記載のパケット回復方法。
  6. 前記通信フローの情報は、ＱＣＩ単位で登録される請求項２に記載のパケット回復方法。
  7. 前記中間装置は、廃棄したパケットが所定の数に達した場合に前記廃棄通知メッセージを送信する請求項１から６のいずれか１つに記載のパケット回復方法。
  8. 前記中間装置は、前記廃棄通知メッセージを前記移動端末へ送信する際、自発的なパケットの再送制御をする必要がないことを示すメッセージを前記通信相手装置へ送信する請求項１に記載のパケット回復方法。
  9. 移動端末と、前記移動端末の通信相手装置と、前記移動端末と前記通信相手装置との通信経路上に配置された中間装置とを備え、廃棄されたパケットの回復を行うパケット回復システムであって、
    前記中間装置が、前記移動端末と前記通信相手装置との間で送受信されるパケットを廃棄した場合に、パケットを廃棄したことを示す廃棄通知メッセージの送信を必要とする通信フローの情報に基づいて前記廃棄通知メッセージを前記移動端末へ送信し、
    前記移動端末が、前記廃棄通知メッセージに基づいて、廃棄された前記パケットの再送を要求する再送要求メッセージを前記通信相手装置へ送信するパケット回復システム。
  10. 前記移動端末は、前記通信フローの情報を前記中間装置に事前に登録する請求項９に記載のパケット回復システム。
  11. 前記通信フローの情報は、前記移動端末が通信を行っているポート番号単位で登録される請求項１０に記載のパケット回復システム。
  12. 前記通信フローの情報は、前記移動端末が通信を行っている通信相手のアドレス単位で登録される請求項１０に記載のパケット回復システム。
  13. 前記通信フローの情報は、前記移動端末が通信を行っているプロトコル単位で登録される請求項１０に記載のパケット回復システム。
  14. 前記通信フローの情報は、ＱＣＩ単位で登録される請求項１０に記載のパケット回復システム。
  15. 前記中間装置は、廃棄したパケットが所定の数に達した場合に前記廃棄通知メッセージを送信する請求項９から１４のいずれか１つに記載のパケット回復システム。
  16. 前記中間装置は、前記廃棄通知メッセージを前記移動端末へ送信する際、自発的なパケットの再送制御をする必要がないことを示すメッセージを前記通信相手装置へ送信する請求項９に記載のパケット回復システム。
  17. 移動端末と前記移動端末の通信相手装置との間で送受信されるパケットのうち、前記移動端末と前記通信相手装置との通信経路上に配置された中間装置によって廃棄されたパケットの回復を行う前記移動端末であって、
    パケットを廃棄したことを通知する廃棄通知メッセージを前記中間装置から受信する受信手段と、
    受信した前記廃棄通知メッセージに基づいて、廃棄された前記パケットの再送を要求する再送要求メッセージを生成するメッセージ生成手段と、
    生成された前記再送要求メッセージを前記通信相手装置へ送信する送信手段とを、
    備える移動端末。
  18. 移動端末と前記移動端末の通信相手装置との通信経路上に配置され、前記移動端末と前記通信相手装置との間で送受信されるパケットを廃棄する中間装置であって、
    パケットを廃棄したことを通知する廃棄通知メッセージの送信を必要とする通信フローの情報に基づいて前記廃棄通知メッセージを生成するメッセージ生成手段と、
    生成された前記廃棄通知メッセージを前記移動端末へ送信する送信手段とを、
    備える中間装置。
JP2011534061A 2009-09-30 2010-09-27 パケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置 Withdrawn JPWO2011039985A1 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2009227218 2009-09-30
JP2009227218 2009-09-30
JP2010176282 2010-08-05
JP2010176282 2010-08-05
PCT/JP2010/005785 WO2011039985A1 (ja) 2009-09-30 2010-09-27 パケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置

Publications (1)

Publication Number Publication Date
JPWO2011039985A1 true JPWO2011039985A1 (ja) 2013-02-21

Family

ID=43825834

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011534061A Withdrawn JPWO2011039985A1 (ja) 2009-09-30 2010-09-27 パケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置

Country Status (3)

Country Link
US (1) US9197378B2 (ja)
JP (1) JPWO2011039985A1 (ja)
WO (1) WO2011039985A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10713099B2 (en) * 2011-08-22 2020-07-14 Xilinx, Inc. Modifying application behaviour

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8665717B2 (en) * 2011-02-18 2014-03-04 Verizon Patent And Licensing Inc. Data rate aware scheduling in advanced wireless networks
JP5678766B2 (ja) * 2011-03-29 2015-03-04 富士通株式会社 情報処理装置、遠隔操作通信装置及び情報処理装置制御方法
TW201246879A (en) 2011-04-13 2012-11-16 Interdigital Patent Holdings Methods, systems and apparatus for managing and/or enforcing policies for managing internet protocol (''IP'') traffic among multiple accesses of a network
WO2012147270A1 (en) * 2011-04-28 2012-11-01 Panasonic Corporation Communication system, mobile terminal, router, and mobility management entity
CN102355292A (zh) * 2011-08-05 2012-02-15 中兴通讯股份有限公司 参数传输方法及装置、参数生成方法及装置
ES2873373T3 (es) * 2011-10-27 2021-11-03 Ericsson Telefon Ab L M Almacenamiento en memoria caché en redes de comunicación inalámbricas
WO2013088616A1 (ja) * 2011-12-14 2013-06-20 日本電気株式会社 無線基地局、サーバ、移動通信システム及び動作制御方法
JP6396808B2 (ja) 2012-02-17 2018-09-26 インターデイジタル パテント ホールディングス インコーポレイテッド 輻輳を処理するおよび／またはユーザ体感品質を管理するための階層的トラフィック区分化
US9538394B2 (en) * 2012-02-24 2017-01-03 Tejas Networks Limited Method for bearer signalling management
EP2842364B1 (en) * 2012-04-23 2020-03-11 Nokia Solutions and Networks Oy Method to address infrequent transmission
US9585054B2 (en) * 2012-07-19 2017-02-28 Interdigital Patent Holdings, Inc. Method and apparatus for detecting and managing user plane congestion
US9154990B2 (en) * 2012-08-06 2015-10-06 Qualcomm Incorporated Method to drop packets selectively in packet data networks
CN103716196B (zh) * 2012-09-28 2018-10-09 新华三技术有限公司 一种网络设备及探测方法
CN103716835B (zh) * 2012-09-29 2017-06-16 国际商业机器公司 基于多路径传输和接收数据的方法、装置和系统
KR20140045215A (ko) * 2012-10-08 2014-04-16 삼성전자주식회사 그룹 기반 연결 설정 방법 및 장치
TW201442527A (zh) 2013-01-11 2014-11-01 Interdigital Patent Holdings 使用者平面壅塞管理
US20140211619A1 (en) * 2013-01-29 2014-07-31 Qualcomm Incorporated Probabilistic retention of the quality of service (qos) bearer for voice over internet protocol (voip) service as voice over long term evolution (volte)
KR102054566B1 (ko) * 2013-07-18 2020-01-22 콘비다 와이어리스, 엘엘씨 릴레이된 디바이스의 빌링
US9872210B2 (en) 2013-10-16 2018-01-16 At&T Mobility Ii Llc Adaptive rate of congestion indicator to enhance intelligent traffic steering
KR102176923B1 (ko) * 2013-12-04 2020-11-10 삼성전자 주식회사 이동 통신 시스템에서 호 서비스의 품질을 높이는 방법 및 장치
CN104702531B (zh) * 2013-12-10 2018-04-20 华为技术有限公司 一种网络设备拥塞避免的方法及网络设备
US20150215220A1 (en) * 2014-01-30 2015-07-30 Candy Yiu Method and apparatus to assist network traffic
KR102279486B1 (ko) * 2014-03-13 2021-07-20 삼성전자 주식회사 무선 통신 시스템에서 연결을 생성하는 방법 및 장치
JP6415603B2 (ja) * 2014-06-30 2018-10-31 インテル アイピー コーポレーション Ｌｔｅ用のサービス品質アーキテクチャを改善する装置及び方法
US9860791B1 (en) * 2014-07-02 2018-01-02 Sprint Communications Company L.P. Long term evolution communication policies based on explicit congestion notification
CN105722154B (zh) * 2014-12-01 2019-09-27 南京中兴新软件有限责任公司 资源处理的优化方法及服务网关和优化系统
US9609660B2 (en) * 2014-12-19 2017-03-28 Wipro Limited System and method for adaptive downlink scheduler for wireless networks
KR102273762B1 (ko) * 2015-01-05 2021-07-07 주식회사 엘지유플러스 VoLTE(Voice over Long Term Evolution) 시스템 및 그 제어방법과 및 이 시스템에 포함되는 PGW(PDN Gateway) 및 CSCF(Call Session Control Function)과 그 제어방법
US9723543B2 (en) 2015-07-08 2017-08-01 Blackberry Limited Systems and methods for managing a UE-to-network relay
JP6471244B2 (ja) * 2015-11-20 2019-02-13 エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー Ｓｄｎに支援されたシームレスなｒａｎアプリマイグレーション
US11889579B2 (en) * 2017-03-24 2024-01-30 Telefonaktiebolaget Lm Ericsson (Publ) QoS flows inactivity counters
EP3635916A4 (en) * 2017-06-08 2020-12-09 Hyannis Port Research, Inc. DYNAMIC TCP FLOW PROCESSING WITH CHANGE NOTIFICATION
US10805434B2 (en) 2017-06-08 2020-10-13 Hyannis Port Research, Inc. Dynamic TCP stream processing with modification notification
JP7142426B2 (ja) * 2017-11-15 2022-09-27 シャープ株式会社 端末装置および方法
US11076436B2 (en) * 2018-04-13 2021-07-27 T-Mobile Usa, Inc. QCI change via bearer release and reestablishment
JP7211765B2 (ja) * 2018-10-30 2023-01-24 日本電信電話株式会社 パケット転送装置、方法、及びプログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11298525A (ja) * 1998-04-13 1999-10-29 Nippon Telegr & Teleph Corp <Ntt> ネットワークノード装置、端末装置及びゲートウェイ装置
JP2002077251A (ja) * 2000-08-28 2002-03-15 Nec Corp データ伝送システム、データ中継装置、およびデータ中継方法
US7106691B1 (en) * 2000-11-01 2006-09-12 At&T Corp. Method for tracking source and destination internet protocol data
US7299296B1 (en) * 2002-09-18 2007-11-20 Juniper Networks, Inc. Filtering data flows based on associated forwarding tables
JP2005354408A (ja) 2004-06-10 2005-12-22 Nippon Telegr & Teleph Corp <Ntt> ファイル配信システムおよび受信端末
KR100636284B1 (ko) * 2005-08-19 2006-10-18 삼성전자주식회사 ＱｏＳ 모니터링 기능을 갖는 ＶｏＩＰ 단말기 및 ＱｏＳ모니터링 방법
US8867340B2 (en) * 2005-12-21 2014-10-21 Alcatel Lucent Discarded packet indicator

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10713099B2 (en) * 2011-08-22 2020-07-14 Xilinx, Inc. Modifying application behaviour

Also Published As

Publication number Publication date
US20120182859A1 (en) 2012-07-19
US9197378B2 (en) 2015-11-24
WO2011039985A1 (ja) 2011-04-07

Similar Documents

Publication Publication Date Title
WO2011039985A1 (ja) パケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置
JP7088557B2 (ja) ネットワークシステムと方法と装置並びにプログラム
US20230093775A9 (en) Method for (re)selection of control plane and user plane data transmission
JP7306511B2 (ja) 制御プレーンＣＩｏＴ ＥＰＳ最適化による負荷制御
US9648520B2 (en) Method for processing data associated with handover in a wireless network
JP4882959B2 (ja) パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置
JP5680633B2 (ja) バックホールヘッダ圧縮
US9191856B2 (en) Network system, offload device, and offload traffic control method
JP5538544B2 (ja) モビリティアンカーの移転
WO2009139679A1 (en) Data forwarding during handover in a self-backhauled cell
WO2011135790A1 (ja) 通信装置及びネットワークノード
US9860792B2 (en) Network device for supporting gateway change in mobile communication system, and method for operating same
WO2012130064A1 (zh) 数据传输方法以及系统

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20131203