JP2016077009A - 通信方法及びシステム、アクセスネットワーク装置、並びにアプリケーションサーバ - Google Patents

Abstract

【課題】ユーザ要求の応答時間を改善し、サービス遅延を減らし、サービスのＱｏＳを改善することにより、ユーザ経験を改善する方法を提供する。【解決手段】アクセスネットワーク装置がサービスパケットを受信するステップと、アクセスネットワーク装置が、受信したサービスパケットをポリシーに従ってアプリケーションサーバへ送信するステップであり、アプリケーションサーバは、アクセスネットワーク側に配置され、アクセスネットワーク装置からは独立しているか、または、アクセスネットワーク装置の中にあり、アプリケーションサーバは、少なくとも１つのサービスの運用をサポートする、送信ステップと、を含む。ＵＥがアクセスネットワーク側とのサービス相互作用を直接実行することができるように、サードパーティアプリケーションの運用をサポートするアプリケーションサーバがアクセスネットワーク側に導入される。【選択図】図２

Description

本発明の実施例は、移動通信技術の分野に関し、また、より具体的には、通信方法及びシステム、アクセスネットワーク装置、並びにアプリケーションサーバに関する。

移動通信技術の分野において、ユーザ装置（User Equipment、UE）は、ワイヤレスネットワークを介して外部ネットワーク（例えば、インターネット（Internet））と接続を確立する必要があり、そして、外部ネットワークまたはリモートサーバを介して、サードパーティアプリケーションサービスのサービスを享受する。

図１に示されるように、ワイヤレスネットワークは主に、アクセスネットワーク１１０とコアネットワーク（Core Network、CN）１２０とを含み、無線リソースの管理機能は主に、アクセスネットワーク１１０の中で、中央集中方式で実現され、サービス及びアプリケーションに関する機能は主に、コアネットワーク１２０の中で、中央集中方式で実現される。したがって、アクセスネットワーク１１０は、ＵＥ１３０とコアネットワーク１２０とを接続する橋である。ＵＥ１３０の外部ネットワークとのサービス相互作用は、ＵＥとアクセスネットワークとコアネットワークとの間の接続に基づいており、最終的には、コアネットワーク側のゲートウェイ１２１を介して実現される。リモートサーバ１４０は、コアネットワークのゲートウェイ１２１の後ろに配置されており、ＵＥ１３０からずっと離れている。その結果、サービスの遅延の拡張や低いサービス品質（Quality of Service、QoS）等の問題が起こり、それによってユーザ経験に影響を与えている。

本発明の実施例は、サービスの遅延の拡大や、サービスの低いＱｏＳ等の問題を解決し、それによってユーザ経験を改善するような通信方法及びシステム、アクセスネットワーク装置、並びにアプリケーションサーバを提供する。

一態様では、本発明の一実施例は、通信方法であって、アクセスネットワーク装置が、サービスパケットを受信するステップと、アクセスネットワーク装置が、受信したサービスパケットを、ポリシーに従ってアプリケーションサーバに送信するステップであり、アプリケーションサーバは、アクセスネットワーク側に配置され、アクセスネットワーク装置から独立しているか、または、アクセスネットワーク装置の中にあり、アプリケーションサーバは、少なくとも１つのサービスの運用をサポートする、送信ステップと、を含む通信方法を提供する。

別の一態様では、本発明の一実施例は、通信方法であって、アプリケーションサーバが、アクセスネットワーク装置から送信されたサービスパケットを受信するステップであり、アプリケーションサーバはアクセスネットワーク側に配置され、アクセスネットワーク装置から独立しているか、または、アクセスネットワーク装置の中にあり、アプリケーションサーバは少なくとも１つのサービスの運用をサポートとする、受信ステップを含み、アプリケーションサーバはサービスパケットを処理する、通信方法を提供する。

別の一態様では、本発明の一実施例は、アクセスネットワーク装置であって、ユーザ装置と通信するように構成された第１のインタフェースユニットと、コアネットワークと通信するように構成された第２のインタフェースユニットと、アプリケーションサーバと通信するように構成された第３のインタフェースユニットと、を備え、アプリケーションサーバは、アクセスネットワーク側に配置され、アクセスネットワーク装置から独立しているか、または、アクセスネットワーク装置の中にあり、第１のインタフェースユニット、第２のインタフェースユニット、および、第３のインタフェースユニットのそれぞれに接続され、第３のインタフェースユニットを介して、ポリシーに従って、受信したサービスパケットをアプリケーションサーバに送信するように構成されたプロセッサを含む、アクセスネットワーク装置を提供する。

別の一態様では、本発明の一実施例は、アプリケーションサーバであって、少なくとも１つのサービスの運用をサポートし、アクセスネットワーク側に配置され、アクセスネットワーク装置から独立しているか、または、アクセスネットワーク装置の中にある、アプリケーションサーバを提供する。アプリケーションサーバは、アクセスネットワーク装置と通信するように構成されたインタフェースユニットと、アプリケーションサーバによってサポートされるサービスデータを格納するように構成された記憶ユニットと、インタフェースユニットと記憶ユニットのそれぞれに接続され、インタフェースユニットを介して、アクセスネットワーク装置によって送信されたサービスパケットを受信し、サービスパケットを処理するように構成された処理ユニットと、を含む。

別の一態様では、本発明の一実施例は、通信システムであって、上述のアクセスネットワーク装置と上述のアプリケーションサーバが、通信システムのアクセスネットワーク側に配置されている、通信システムを提供する。

別の一態様では、本発明の一実施例は、コンピュータ可読記憶媒体であって、請求項１から請求項７のいずれか１つに従った方法を実行するために利用されるプログラムを含む、コンピュータ可読記憶媒体を提供する。

別の一態様では、本発明の一実施例は、請求項８から請求項１６のいずれか１つに従った方法を実行するために利用されるプログラムを含む、コンピュータ可読記憶媒体を提供する。

本発明の実施例によれば、アクセスネットワーク側とのサービス相互作用をＵＥが直接実行できるように、サードパーティアプリケーションの運用をサポートするアプリケーションサーバがアクセスネットワーク側に導入され、大いに、ユーザ要求の応答時間が改善され、サービス遅延が減り、サービスのＱｏＳが改善され、それによってユーザ経験が改善されることがわかる。

本発明の実施例における技術的ソリューションをより明確に示すために、実施例を説明するために必要な添付図面を以下簡単に説明する。明らかに、以下の説明における添付図面は、単に本発明のいくつかの実施例を示すに過ぎず、当業者は、これらの添付図面から他の図面を容易に導出することができる。
先行技術における通信システムの概略構成図 本発明の一実施例において提供される通信システムの概略構成図 本発明の一実施例において提供されるアクセスネットワーク装置の概略構成図 本発明の一実施例において提供されるアプリケーションサーバの概略構成図 本発明の一実施例において提供される、サービスパケットを処理するアプリケーションサーバの概略フローチャート 本発明の一実施例において提供される、サービスパケットを処理するアプリケーションサーバの、他の概略フローチャート 本発明の一実施例において提供される、アプリケーション・無線ネットワークインターフェイスプロトコルの概略構成図 本発明の一実施例において提供されるアプリケーションサーバのソフトウェアアーキテクチャ図 本発明の一実施例において提供される通信方法のフローチャート 本発明の一実施例において提供される他の通信方法のフローチャート 本発明の一実施例において提供される他の通信方法の概略図 本発明の一実施例において提供される一ＬＴＥシステムの概略構成図 本発明の一実施例において提供される一ＬＴＥシステムにおけるユーザプレーンデータストリームの概略図 本発明の一実施例において提供される一ＬＴＥシステムにおけるユーザプレーンインターフェイスの概略図 本発明の一実施例において提供される一ＬＴＥシステムにおける制御プレーンデータストリームの概略図

本発明の実施例の目的、技術的ソリューション、および利点が、より分かりやすくなるように、本発明の実施例における添付図面を参照して、本発明の実施例に従った技術的ソリューションを明確且つ完全に以下説明する。明らかに、以下の説明における実施例は、本発明の実施例のすべてではなく、単なる一部に過ぎない。本発明の実施例に基づいて当業者が容易に得ることのできるすべての他の実施例は、本発明の保護範囲に入る。

本発明の一実施例において、既存のサードパーティアプリケーションのサービス相互作用の処理における問題は、十分に考慮され、サードパーティアプリケーションの運用をサポートする論理ネットワーク要素が、アクセスネットワーク側に導入される。このようにして、ＵＥは、アクセスネットワーク側とのサービス相互作用を直接実行することができ、それは大いに、ユーザ要求の応答時間を改善し、サービス遅延を減少させ、サービスのＱｏＳを改善する、そしてそれによってユーザ経験を改善する。添付図面を参照して以下において詳細な説明がなされる。

図２は、本発明の一実施例において提供される通信システムの概略構成図である。図１を参照してわかるのは、アクセスネットワーク２１０側に導入された論理ネットワーク要素が本発明の実施例におけるアプリケーションサーバ２１２であり、アプリケーションサーバ２１２が、少なくとも１つのサービスの運用をサポートすることである。物理的に、アプリケーションサーバ２１２は、アクセスネットワーク装置２１１の外にある独立した装置であり得るか、または、アクセスネットワーク装置２１１において統合され得る。このことは、この実施例によっていかなる制限を受けるものではない。

もともとの機能に加えて、アクセスネットワーク装置２１１は、ＵＥ２３０またはコアネットワークからのサービスパケットを、アプリケーションサーバ２１２へ迂回させて処理させるように、追加的なパケット迂回機能を実装する必要がある。アクセスネットワーク装置２１１のもともとの機能には、無線リソースの管理、無線インターフェイスデータの転送、およびＵＥの状態の維持が含まれ、これらは、当業者によく知られており、本明細書内で再度詳しく説明しない。

留意すべきことは、アクセスネットワーク装置２１１は、ノードＢ（Node B）、進化したノードＢ（evolved Node B、eNB）、ホームノードＢ（Home Node B、HNB）／（Home eNode B、HeNB）、無線ネットワークコントローラ（radio network controller、RNC）、基地局コントローラ（Base Station Controller、BSC）、およびベース送受信局（Base Transceiver Station、BTS）を含むが、これに限定されない、ワイヤレスネットワークにＵＥがアクセスできるようにする装置であるということである。

加えて、この実施例によるサードパーティアプリケーションには、ウェブページに関するキャッシュ（Cache）加速、ビデオトランスコーディング、マシン・ツー・マシン（Machine-to-Machine、M2M）ハンドシェイクシグナリング終端、およびコンテンツ格納と配信が含まれるが、これに限定されない。これらは、サードパーティによって提供され得、この実施例によっていかなる限定もされない。加えて、アプリケーションサーバ２１２は、サードパーティアプリケーション提供者のためのオープンプラットフォームを提供し、様々なサードパーティアプリケーションの拡張をサポートするオープンアプリーケーションサーバであり得、これによって、さらにユーザ体験を改善する。アクセスネットワーク装置２１１及びアプリケーションサーバ２１２についてのより詳細な説明が、添付図面を参照して以下においてなされる。

図３は、本発明の一実施例において提供されるアクセスネットワーク装置の概略構成図である。図３に示されるように、アクセスネットワーク装置２１１は、第１のインタフェースユニット３１０と、第２のインタフェースユニット３２０と、第３のインタフェースユニット３３０と、および、第１のインタフェースユニット３１０、第２のインタフェースユニット３２０、および第３のインタフェースユニット３３０のそれぞれに接続されたプロセッサ３４０と、を含む。第１のインタフェースユニット３１０は、ＵＥ２３０と通信するように構成され、第２のインタフェースユニット３２０は、コアネットワークと通信するように構成され、第３のインタフェースユニット３３０は、アプリケーションサーバ２１２と通信するように構成され、プロセッサ３４０は、第１のインタフェースユニット３１０または第２のインタフェースユニット３２０を介してサービスパケットを受信し、第３のインタフェースユニットを介して、受信したサービスパケットをポリシーに従ってアプリケーションサーバ２１２に送信するように構成されている。上述の通り、アプリケーションサーバ２１２は、少なくとも１つのサービスの運用をサポートし、アプリケーションサーバ２１２は、アクセスネットワーク側に、アクセスネットワーク装置２１１から独立して、または、アクセスネットワーク装置の中に、配置される。

アクセスネットワーク装置２１１によってサービスパケットをアプリケーションサーバ２１２に送信するためのポリシーには、アクセスネットワーク装置２１１によって受信された全てのサービスパケットをアプリケーションサーバ２１２に送信すること、または、識別情報を用いてサービスパケットがアプリケーションサーバ２１２に送信できるか否かを識別し、アプリケーションサーバ２１２に送信できるサービスパケットをアプリケーションサーバ２１２に送信し、アプリケーションサーバ２１２に送信できないサービスパケットをコアネットワーク２２０に送信すること、が含まれる。識別情報は、加入者プロファイル識別（Subscriber Profile ID、SPID）情報、サービス品質クラス識別子（QoS class identifier、QCI）情報、ステートフルパケット検査（Stateful Packet Inspection、SPI）情報、または、ディープパケット検査（Deep Packet Inspection、DPI）を含むが、これに限定されない。識別情報とサービスパケットがアプリケーションサーバ２１２に送信できるか否かとの対応は、事業者によって定義され得るが、このことは、この実施例によっていかなる制限を受けるものではない。

ＳＰＩＤに従って、サービスパケットの一部がアプリケーションサーバ２１２に送信されて処理される状況が例として取り上げられる。ここで、ＳＰＩＤは、事業者によって定義される加入者識別であり、現在１から２５６までの範囲の値を持ち、特定の意味が事業者によって定義され得る（現在、単にいくつかの値が、キャンピング優先度（camping priority）、および、周波数間／ＲＡＴ間ハンドオーバ優先度（inter-frequency/inter-RAT handover priority）のために定義されている）。事業者は、加入者のどのベアラが、または、サービスパケットのどのような種類が、アプリケーションサーバ２１２に送信して処理させることができるかを表すように、いくつかのＳＰＩＤを予め定義し得る。そうすることにより、サービスパケットの受信後、アクセスネットワーク装置２１１は、加入者のＳＰＩＤに従って、受信したサービスパケットをアプリケーションサーバ２１２に送信するか否かを判断することができる。

ＱＣＩに従って、サービスパケットの一部がアプリケーションサーバ２１２に送信されて処理される状況が例として取り上げられる。ここで、ＱＣＩは、９個のクラスを含み、事業者は、サービスのどのクラスが、アプリケーションサーバ２１２に送信されて処理される必要があるかを予め定義し得る。そうすることにより、サービスパケットの受信後、アクセスネットワーク装置２１１は、サービスパケットのＱＣＩに従って、受信したサービスパケットをアプリケーションサーバ２１２に送信するか否かを判断することができる。

ＳＰＩまたはＤＰＩに従って、サービスパケットの一部がアプリケーションサーバ２１２に送信されて処理される状況が例として取り上げられる。ここで、事業者は、サービスパケットをアプリケーションサーバ２１２に転送するためのいくつかのルールを予め定義し得る。例えば、パケットは、パケットの５タプル（5-tuple）（元ＩＰ、宛先ＩＰ、元ポート、宛先ポート、およびプロトコル種別）に従って転送される。そうすることにより、サービスパケットの受信後、アクセスネットワーク装置２１１は、転送ルールに従って、受信したサービスパケットをアプリケーションサーバ２１２に送信するか否かを判断することができる。

図４は、本発明の一実施例において提供されるアプリケーションサーバの概略構成図である。図４に示されるように、アプリケーションサーバ２１２は、上述の通り、少なくとも１つのサービスの運用をサポートし、アクセスネットワーク側に配置され、そして、アクセスネットワーク装置から独立し得るか、または、アクセスネットワーク装置の中にあり得る。アプリケーションサーバ２１２は、インタフェースユニット４１０と、記憶ユニット４２０と、インタフェースユニット４１０と記憶ユニット４２０のそれぞれに接続された処理ユニット４３０と、を含む。インタフェースユニット４１０は、アクセスネットワーク装置２１１と通信するように構成され、記憶ユニット４２０は、アプリケーションサーバ２１２によってサポートされるサービスのサービス日付を格納するように構成され、処理ユニット４３０は、インタフェースユニット４１０を介してアクセスネットワーク装置２１１によって送信されたサービスパケットを受信し、サービスパケットを処理するように構成される。

留意されるべきことは、処理ユニット４３０はプロセッサであり得、また、記憶ユニット４２０は、メモリであり得る、ということである。もし、アプリケーションサーバ２１２がアクセスネットワーク装置２１１において統合されているならば、アプリケーションサーバ２１２の処理ユニット４３０の機能は、アクセスネットワーク装置２１１のプロセッサ３４０において実装されることができる。すなわち、アプリケーションサーバ２１２は、アクセスネットワーク装置２１１とプロセッサを共有する。

処理ユニット４３２による、対応するサービスパケットの処理手順は、処理ユニット４３０によって受信されるサービスパケットによって変わる。手順は、以下の場合を含むが、これに限定されない。

アクセスネットワーク装置２１１がサービスパケットをアプリケーションサーバ２１２に送信するポリシーが予め設定されているとき、アプリケーションサーバ２１２によって現在サポートすることができるサービス種別に従ってポリシーは設定されており、アプリケーションサーバ２１２によってサポートされているサービスのサービスパケットだけがアプリケーションサーバ２１２に送信される。このようにして、アプリケーションサーバ２１２は、受信したサービスパケットをサポートしているか否かを判断する必要がない。サービスパケットを処理する処理ユニット４３０の手順が図５に示されており、以下を含む。

ステップＳ５１０：サービスパケットを構文解析する。構文解析は、アプリケーション層のデータを得るために、他のプロトコル層の情報をはがすプロセスである。

ステップＳ５２０：構文解析されたサービスパケットに従って、サービスパケットに対応するサービスを実行する。

ステップＳ５３０：実行結果をアクセスネットワーク装置にフィードバックする。

アクセスネットワーク装置２１１がサービスパケットをアプリケーションサーバ２１２に送信するポリシーが予め設定されているとき、もし、ポリシーが、アプリケーションサーバによって現在サポートされているサービス種別に従って設定されていないならば、サービスパケットを処理する処理ユニット４３０の手順は、図６に示されるように、以下のステップを含む。

ステップＳ６１０：サービスパケットを構文解析する。構文解析は、ステップＳ５１０と同様であり、ここで再度詳しく説明されることはない。

ステップＳ６２０：構文解析されたサービスパケットに従って、サービスパケットに対応するサービスの運用を処理ユニットがサポートするか否かを判断する。そして、もし、処理ユニットがサービスパケットに対応するサービスの運用をサポートするならば、ステップＳ６３０を実行する。もし、処理ユニットがサービスパケットに対応するサービスの運用をサポートしないならば、ステップＳ６４０、ステップＳ６５０、またはステップＳ６６０を実行する。

もし、サービスパケットに対応するサービスの運用を処理ユニットがサポートすることを構文解析の結果が示すならば、構文解析されたサービスパケットに従って、サービスパケットに対応するサービスが実行される。そして、実行結果は、アクセスネットワーク装置にフィードバックされる（ステップＳ６３０）。もし、サービスパケットに対応するサービスの運用を処理ユニットがサポートしないことを構文解析の結果が示すならば、サービスパケットはアクセスネットワーク装置に返され（ステップＳ６４０）、アクセスネットワーク装置は、サービスパケットを従来のチャネルを介して送出する、すなわち、サービスパケットはコアネットワークに送信される（ステップＳ６５０）。そしてこのとき、アプリケーションサーバからコアネットワークへの直接のチャネルが必要になる。すなわち、命令シグナリングがアクセスネットワーク装置に送信される（ステップＳ６６０）。ここで、命令シグナリングは、サービスパケットをコアネットワークに送信するようにアクセスネットワーク装置に命令するために使われる。アクセスネットワーク装置は、既にサービスパケットを受信しているので、アクセスネットワーク装置はサービスパケットをキャッシュする必要があるだけであり、命令情報に従って、サービスパケットを従来のチャネルを介して送出する。アプリケーションサーバがサービスを提供できないとき、上述のステップＳ６４０、ステップＳ６５０、またはステップＳ６６０が提供され、従来の方法でサービスがＵＥに提供され、サービスが中断しないことを確実にする。

加えて、もし、構文解析されたサービスパケットが、処理ユニットによってサポートされるサービスの更新データを含むならば、更新データは、記憶ユニットに格納される。

サービスパケットが、アクセスネットワーク装置２１１とアプリケーションサーバ２１２との間で伝送されることを考慮すると、アクセスネットワーク装置２１１とアプリケーションサーバ２１２との間で、ユーザプレーンチャネルが確立される必要がある。１つの方法は以下の通りである。ユーザプレーンチャネルは予め設定されている。そして、このとき、ユーザプレーンプロトコルだけが定義される必要があり、そして、ユーザプレーンプロトコルに従って、予め設定されたユーザプレーンチャネルを介してサービスパケットが伝送される。別の方法は、以下の通りである。アクセスネットワーク装置２１１の第３のインタフェースユニット３３０のプロトコルと、インタフェースユニット３３０と相互作用するアプリケーションサーバ２１２のインタフェースユニット４１０のプロトコルとが構成され、構成されたプロトコルに従って、必要に応じて、アクセスネットワーク装置２１１とアプリケーションサーバ２１２との間にユーザプレーンチャネルが確立され、ユーザプレーンチャネルを介してサービスパケットが送信される。

第３のインタフェースユニット３３０とインタフェースユニット４１０のプロトコルのそれぞれは、アプリケーション・無線ネットワークインターフェイスプロトコルであり、したがって、アプリケーション・無線ネットワークインターフェイスプロトコルに従って、アクセスネットワーク装置２１１とアプリケーションサーバ２１２との間にユーザプレーンチャネルが確立される。

図７は、アプリケーション・無線ネットワークインターフェイスプロトコルの概略構成図である。図７に示されるように、アプリケーション・無線ネットワークインターフェイスプロトコルは、制御プレーンプロトコル７１０とユーザプレーンプロトコル７２０とを含む。ユーザプレーンプロトコル７２０は、ユーザプレーンチャネル上の情報伝送のために使用され、制御プレーンプロトコル７１０は、ユーザプレーンチャネルを確立するために使用される。そして、ユーザプレーンチャネルを確立するステップは、制御プレーンプロトコルに従って、アクセスネットワーク装置とアプリケーションサーバとの間に制御プレーンリンクを確立するサブステップ、および、制御プレーンリンクによって運ばれる制御情報に従って、アクセスネットワーク装置とアプリケーションサーバとの間にユーザプレーンチャネルを確立するサブステップ、を含む。

制御プレーンプロトコル７１０は、サービスネットワーク層プロトコルと伝送ネットワーク層プロトコルとを含む。ここで、サービスネットワーク層プロトコルは、制御情報を含み、伝送ネットワーク層プロトコルは、物理層プロトコル、データリンク層プロトコル、ネットワーク層プロトコル、およびトランスポート層プロトコルとを含む。ユーザプレーンプロトコルは、サービスネットワーク層プロトコルおよび伝送ネットワーク層プロトコルを含む。サービスネットワーク層プロトコルは、ＵＥとリモートサーバとの間のサービスパケット伝送のために使用される既存のサービスネットワーク層プロトコルと類似しており、アクセスネットワークは、プロトコルのこの部分は処理をせず、単に、透過的伝送を実行するが、これは、当業者によってよく知られており、この実施例において再度詳しく明細書で説明されることはない。伝送ネットワーク層プロトコルは、サービスパケットの伝送を実現するために使用される。伝送ネットワーク層プロトコルはまた、物理層プロトコル、データリンク層プロトコル、ネットワーク層プロトコル、および、トランスポート層プロトコルとを含む。

制御プレーンプロトコルの伝送ネットワーク層プロトコルにおいて、ネットワーク層プロトコルは、インターネットプロトコル（Internet Protocol、IP）であり得、トランスポート層プロトコルは、ストリーム制御伝送プロトコル（Stream Control Transmission Protocol、SCTP）、伝送制御プロトコル（Transmission Control Protocol、TCP）、または、ユーザデータグラムプロトコル（User Datagram Protocol、UDP）であり得る。ユーザプレーンプロトコルのトランスポートネットワーク層プロトコルにおいて、ネットワーク層プロトコルはＩＰであり得、トランスポート層プロトコルは、ＵＤＰ、および、ＧＰＲＳトンネリングプロトコル−ユーザプレーン（GPRS Tunneling Protocol-User plane、GTP-U）を含み得る。ここで、ＧＴＰ−Ｕは、ＵＤＰトンネリングプロトコル、ＩＰトンネリングプロトコル、または、データリンク層トンネリングプロトコルで置き換えられ得る。このようなケースは、明細書における単なる例示に過ぎず、本発明を限定することを意図するものではない。

上述の制御情報は、リセット情報と、オープンＡＰＩインターフェイス設定要求メッセージと、および、基地局構成更新メッセージであり、例えばロングタームエボリューション（Long Term Evolution、LTE）アクセス技術とともに説明される基地局構成更新メッセージとを含むが、これに限定されない。他のアクセス技術、例えば、ユニバーサル移動体通信システム（Universal Mobile Telecommunications System、UMTS）、はこれと似ているが、明細書で再度詳しく説明されることはない。

好ましくは、制御情報は、アプリケーションサーバにワイヤレスネットワークの状態情報を送信するように、アクセスネットワーク装置に命令するために使用される、状態情報購読要求メッセージを含む。このようにして、サードパーティアプリケーションは、状態情報に従ってサービスパケットの処理を柔軟に調整することができる。例えば、もし、状態情報が無線インターフェイスの輻輳を示すならば、高精細度ビデオソースが、通常のビデオソースに調整されてＵＥに送信される。別の例では、サービスパケットの大部分が関係するサービスがポイントツーポイント（P2P）通信であり、サービスの小さい部分がビデオサービスであるとき、より多くの無線リソースが割り当てられてビデオ品質を確保し得る。

好ましくは、制御情報は、アクセスネットワーク装置がサービスパケットをアプリケーションサーバに送信するポリシーを示すために使用される、ポリシー変更要求メッセージを含む。このようにして、オペレータは、サードパーティアプリケーションの要件に従って、アクセスネットワーク装置がサービスパケットをアプリケーションサーバに送信するポリシーを柔軟に調整することができる。

アクセスネットワーク装置２１１のプロセッサ３４０はさらに、第３のインタフェースユニット３３０を介して、アクセスネットワーク装置２１１とアプリケーションサーバ２１２との間のユーザプレーンチャネルを確立するように構成され、アプリケーションサーバ２１２の処理ユニット４３０はさらに、インタフェースユニット４１０を介して、アクセスネットワーク装置２１１とアプリケーションサーバ２１２との間のユーザプレーンチャネルを確立するように構成されていることがわかる。

なお、サービスパケットは、ＵＥから来てもよく、または、コアネットワーク側から来てもよい。したがって、ユーザプレーンチャネルは、上りリンクと下りリンクのそれぞれにおいて確立されてもよい。もちろん、独立したユーザプレーンチャネルが確立されてもよい。このとき、サービスパケットがＵＥ側からのデータか、コアネットワーク側からのデータかを区別するために、サービスパケットのソース方向を識別できるように、方向識別フィールドがサービスパケットの中に加えられる必要がある。

加えて、アプリケーションサーバによってサポートされるサービスの数は通常１より大きいことを考慮して、１方向に１つのユーザチャネル（上りリンク方向、または、下りリンク方向）が考えられるとき、もし、全てのサービスが１つのユーザプレーンチャネルを共有するならば、転送方向を識別するために、すなわち、サービスパケットがどのサービスに提供され実行されるかを識別するために、サービスパケットの中に識別が加えられる必要がある。もし、フィールドが加えられないならば、アプリケーションサーバがサービスパケットを識別し、分配する必要がある。

アプリケーションサーバのハードウェア構成が上記のとおり説明されている。そして、アプリケーションサーバのソフトウェア構成が添付図面を参照して、以下の通り説明される。サーバの処理ユニットは、以下のソフトウェア構成を介して、アプリケーションサーバの他のユニットを管理し、アプリケーションサーバ全体の機能を実現する。図８は、本発明の一実施例において提供されるアプリケーションサーバのソフトウェアアーキテクチャを示している。図８に示されるように、処理ユニット４３０は、中央処理ユニット（Central Processing Unit、CPU）であり、その上で、オペレーティングシステム（Operating System、OS）が、ボードサポートパッケージ（board support package、BSP）を介して実行される。このようにして、制御プレーン処理プログラム、ユーザプレーン処理プログラム、サードパーティアプリケーションプログラム、オペレーションマネージャ（Operation Manager、OM）プログラムが、ＯＳによって提供されるプラットフォーム上で実行される。

制御プレーン処理プログラムは、アプリケーションサーバとアクセスネットワーク装置との間の制御プレーンメッセージを処理するために使用され、以下の３つの基本的種類の制御プロセス、すなわち、基本管理プロセス、サービスベアラ管理プロセス、および、オープン情報取得プロセス、が存在する。基本管理プロセスは、アプリケーションサーバとアクセスネットワーク装置との間の制御プレーンリンクを確立し維持するために使用される。サービスベアラ管理プロセスは、アプリケーションサーバとアクセスネットワーク装置との間のユーザプレーンチャネルを確立し維持するために使用される。オープン情報取得プロセスは、アプリケーションサーバが、ワイヤレスネットワークの状態情報（アクセスネットワーク装置側の無線インターフェイスの状態情報、または、アクセスネットワーク装置の状態情報を含む）を購読するために使用され、アクセスネットワーク装置からの状態情報を報告するために使用される。

ユーザプレーン処理プログラムは、アプリケーションサーバとアクセスネットワーク装置との間のユーザプレーンチャネルの処理を提供し、アクセスネットワーク装置とアプリケーションサーバとの間のサービスパケットの相互作用のために使用される。

サードパーティアプリケーションプログラムは、ユーザのアプリケーション層データを終端または転送する、または、特定のアプリケーションに従って特定のサービスを提供する。

ＯＭプログラムは、ユーザプレーン処理と、制御プレーン処理と、そして、サードパーティアプリケーションとを協調させ管理するために使用され、少なくとも、ログ／試験／バージョン管理機能を有する。

上述の説明からわかるように、もともとの機能に加えて、アクセスネットワーク装置は、以下の追加機能を実装する必要がある。

１．サービスパケットをアプリケーションサーバに送信して処理させる。もし、各サードパーティアプリケーションに対する独立したユーザプレーンチャネルが確立されているならば、パケットは単に、対応するユーザプレーンチャネルに転送される（もし、ユーザプレーンチャネルが、上りリンクと下りリンクのそれぞれにおいて確立されているならば、各チャネルは方向を示している。そうでなければ、データがＵＥからのデータか、または、コアネットワークからのデータかを識別するために、方向識別フィールドが使用される必要がある。）。もし、サードパーティアプリケーションが１つのユーザプレーンチャネルを共有するならば、識別（送信方向を識別するために使用される）が付加される必要がある。そして、パケットは送信される。もし、識別が付加されていないならば、パケットは、受信端で識別され分配される必要がある（もし、ユーザプレーンが、上りリンクと下りリンクの各々において確立されているならば、各チャネルは方向を示す。そうでなければ、方向識別フィールドが使用される必要がある。）。

２．パケットをアプリケーションサーバから受信後、パケットを転送する。もし、各サードパーティアプリケーションが、独立したユーザプレーンチャネルを確立するならば、パケットは、方向に従って、ＵＥまたはコアネットワークへ送信される必要がある（もし、チャネルが、上りリンクと下りリンクの各々において確立されているならば、各チャネルは、方向を示す。そうでなければ、方向識別フィールドが使用される必要がある。）。もし、サードパーティアプリケーションが、１つのユーザプレーンチャネルを共有するならば、パケットは、ポリシーに従って転送される必要がある。オプションのポリシーは、パケットをＤＰＩに従って転送すること、識別（送信方向を識別するために使用される−特定のベアラ）に従ってパケットを識別し転送すること（もし、チャネルが、ＵＥ方向とコアネットワーク方向の各々において確立されているならば、各チャネルは方向を示す。そうでなければ、方向識別フィールドが使用される必要がある。）、を含むがこれに限定されない。

３．ユーザプレーンチャネルを確立する。

アプリケーションサーバの機能は、以下のものを含む：

１．アクセスネットワーク装置によって送信されたサービスパケットを構文解析する。

２．ユーザプレーンチャネルを確立する。

３．サードパーティアプリケーションを実行する。

４．処理のためにパケットを、アクセスネットワーク装置から受信し、サービスパケットを特定のサードパーティアプリケーションへ転送する。もし、各サードバーティアプリケーションが独立したユーザプレーンチャネルを確立しているならば、対応するチャネル上のパケットは、単に、対応するサードパーティアプリケーションへ転送される（もし、チャネルが、上りリンクと下りリンクのそれぞれにおいて確立しているならば、各チャネルは方向を示す。そうでないならば、方向識別フィールドが使用される必要がある。）。もし、サードパーティアプリケーションが１つのユーザプレーンチャネルを共有するならば、パケットは、ポリシーに従って転送される必要がある。オプションのポリシーは、パケットをＤＰＩに従って転送すること、転送識別（もし、チャネルが、上りリンクと下りリンクのそれぞれにおいて確立されているならば、各チャネルは方向を示す。そうでなければ、方向識別フィールドが使用される必要がある。）、を含むがこれに限定されない。

５．処理のためにパケットを、アクセスネットワーク装置に送信する。すなわち、サードパーティアプリケーションのユーザプレーンパケットをユーザプレーンチャネルに転送する。もし、各サードパーティアプリケーションが、独立したユーザプレーンチャネルを確立しているならば、パケットは、単に、対応するチャネルに転送される必要がある（もし、チャネルが、上りリンクと下りリンクのそれぞれにおいて確立しているならば、各チャネルは方向を示す。そうでなければ、方向識別フィールドが使用される必要がある。）。もし、サードパーティアプリケーションが、１つのユーザプレーンチャネルを共有するならば、識別（転送方向を識別するために使用される）がパケットに付加される必要がある。そして、パケットは転送される（もし、識別が付加されていなければ、パケットは、受信端において識別され、分配される必要がある。もし、チャネルが、上りリンクと下りリンクのそれぞれにおいて確立しているならば、各チャネルは、方向を示す。そうでなければ、方向識別フィールドが使用される必要がある。）。

前述のアクセスネットワーク装置に対応して、本発明の一実施例は、さらに、通信方法を提供する。図９に示されるように、該方法は、以下のステップを含む：

Ｓ９１０：アクセスネットワーク装置は、サービスパケットを受信する。そして、

Ｓ９２０：アクセスネットワーク装置は、ポリシーに従って、受信したサービスパケットをアプリケーションサーバに送信する。

前述の説明において説明されたように、アプリケーションサーバは、アクセスネットワーク側に配置されており、アクセスネットワーク装置からは独立しているか、または、アクセスネットワーク装置の中にある。そして、アプリケーションサーバは、少なくとも１つのサービスの運用をサポートする。

ＵＥ側からのサービスパケットは、アクセスネットワーク装置を通してアプリケーションサーバへ転送され、アプリケーションサーバによって処理されることができることがわかる。このようにして、ＵＥ側からのサービスパケットに対する応答は、アクセスネットワーク側において実装されることができる。これは、ユーザ要求の応答時間を大いに改善し、サービス遅延を減らし、そして、サービスのＱｏＳを改善する。これによって、ユーザ経験を改善する。

前述の実施例と同様に、ステップＳ９１０において、アクセスネットワーク装置によって受信されるサービスパケットは、ＵＥ側から、または、コアネットワーク側から来得る。

前述の実施例と同様に、ステップＳ９２０において、サービスパケットがアクセスネットワーク装置によってアプリケーションサーバに送信されるポリシーは、アクセスネットワーク装置によって受信される全てのサービスパケットをアプリケーションサーバに送信する、または、識別情報を用いて、サービスパケットがアプリケーションサーバに送信されることができるか否かを識別し、アプリケーションサーバに送信されることができないサービスパケットを、コアネットワークに送信することを含むが、これに限定されない。識別情報の設定は、前述の実施例と同様であり、ここで再度詳しく説明されない。

前述のアプリケーションサーバに対応して、本発明の一実施例はさらに、他の通信方法を提供する。図１０に示されるように、該方法は以下のステップを含む：

Ｓ１０１：アプリケーションサーバは、アクセスネットワーク装置によって送信されたサービスパケットを受信する。ここで、アプリケーションサーバはアクセスネットワーク側に配置され、そして、アクセスネットワーク装置から独立しているか、または、アクセスネットワーク装置の中にあり、アプリケーションサーバは、少なくとも１つのサービスの運用をサポートする。そして、

Ｓ１０２：アプリケーションサーバは、サービスパケットを処理する。

サービスの運用をサポートするアプリケーションサーバは、アクセスネットワーク側に配置され、そして、アクセスネットワーク装置からサービスパケットを受信し、処理する。このようにして、ＵＥ側のサービスパケットに対する応答は、アクセスネットワーク側において実装されることができる。これは、ユーザ要求の応答時間を大いに改善し、サービス遅延を減らし、そして、サービスのＱｏＳを改善する。これによって、ユーザ経験を改善する。

ステップＳ１０２における対応するサービスパケットの処理手順は、アプリケーションサーバによって受信されたサービスパケットに伴って変化する。その手順は、図５および図６に示された手順を含むがこれに限定されない。

加えて、もし、構文解析されたサービスパケットが処理ユニットによってサポートされるサービスの更新データを含むならば、更新データは記憶ユニットに格納される。

アクセスネットワーク装置がサービスパケットをアプリケーションサーバに送信し、アプリケーションサーバがサービスパケットをアクセスネットワーク装置から受信する前に、ユーザプレーンチャネルがアクセスネットワーク装置とアプリケーションサーバとの間に確立されている必要がある。ユーザプレーンチャネルを確立する方法は、上記と同様であり、ここで再度詳しく説明されない。

上述の通信システムに対応して、本発明の一実施例はさらに、通信方法を提供する。図１１に示されるように、該方法は、以下のステップを含む：

Ｓ１１１：アクセスネットワーク装置は、ＵＥまたはコアネットワークから送信されたサービスパケットを受信する。

Ｓ１１２：アクセスネットワーク装置は、ポリシーに従って、受信したサービスパケットをアプリケーションサーバへ送信する。

ステップＳ１１２の前に、ユーザプレーンチャネルが、アクセスネットワーク装置とアプリケーションサーバとの間に確立されている必要がある。

上記のとおり、ユーザプレーンチャネルは、アクセスネットワーク装置とアプリケーションサーバがパワーオンされるとユーザプレーンチャネルがユーザプレーン情報を運搬できるように、予め設定され得る。あるいは、アクセスネットワーク装置とアプリケーションサーバとの間のインターフェイスプロトコルに従って、アクセスネットワーク装置とアプリケーションサーバがパワーオンされた後に、または、アクセスネットワーク装置が、アプリケーションサーバに転送される必要のあるサービスパケットを受信した後に、ユーザプレーンチャネルが確立される。

加えて、確立されるユーザプレーンチャネルの数は、１以上であり得る。例えば、もし、上りリンクおよび下りリンクのサービスデータの送信が考慮されるならば、ユーザプレーンチャネルは、上りリンクおよび下りリンクのそれぞれにおいて確立され得る。または、１つのユーザプレーンチャネルだけが確立され、サービスパケットにおいて方向識別フィールドが付加される。他の例では、アプリケーションサーバ上で動作しているサードパーティアプリケーションのデータを考慮して、ユーザプレーンチャネルは、各サードパーティアプリケーションに対して確立され得る。または、すべてのサードパーティアプリケーションによって共有される１つのユーザプレーンチャネルだけが確立され得、このときは、受信されたサービスパケットは、受信端において、識別され、分配される必要がある。または、サービスパケットにおいて、方向を識別する識別フィールドが付加される必要がある。

Ｓ１１３：アプリケーションサーバは、サービスパケットを処理する。

もし、サービスパケットがＵＥから来たならば、サービスパケットは通常、ＵＥのサービス要求を含む。そして、もし、アプリケーションサーバが、ＵＥによって要求されたサービス資源を持っているならば、アプリケーションサーバはサービス資源をアクセスネットワーク装置に送信する（Ｓ１１４）。もし、アプリケーションサーバが、ＵＥによって要求されたサービス資源を持っていないならば、アプリケーションサーバはサービスパケットをアクセスネットワーク装置に戻し、アクセスネットワーク装置が、従来のチャネルを通してサービスパケットを送出できるようにする（Ｓ１１５）。または、アプリケーションサーバは、サービスパケットを直接コアネットワークに送信する。そして、このときは、アプリケーションサーバからコアネットワークへの直接のチャネルが必要となる（Ｓ１１６）。または、アプリケーションサーバは、アクセスネットワーク装置に命令シグナリングを送る（Ｓ１１７）。ここで、命令シグナリングは、サービスパケットをコアネットワークへ送信するように、アクセスネットワーク装置に命令するために使用される。アクセスネットワーク装置は、ステップＳ１１１においてサービスパケットを受信しているので、アクセスネットワーク装置は、サービスパケットをキャッシュし、命令情報に従って、アプリケーションサーバがサービスを提供できないときは従来の方法でＵＥにサービスが提供されるように、サービスパケットを従来のチャネルを通して送出するだけでよい。

ＵＥから要求されたサービス資源を受信したときは、アクセスネットワーク装置は、サービス資源をＵＥに送信する（Ｓ１１８）。戻されたサービスパケット、または、命令シグナリングを受信したときは、アクセスネットワーク装置は、引き続きサービスパケットをコアネットワークに送信する（Ｓ１１９）。

なお、もし、アプリケーションサーバが、ＵＥによって要求されたサービスをサポートはしているけれども、ＵＥによって要求されたサービス資源は持っていないならば、サービス要求は引き続きコアネットワークを通して外部ネットワークへ送信され得、そして、要求されたサービス資源は、外部ネットワークを通して取得され得る。要求されたサービス資源がコアネットワークを通してアクセスネットワーク装置に送信され、そして、アクセスネットワーク装置がサービス資源をアプリケーションサーバに転送するとき、アプリケーションサーバは、ステップＳ１１３において、サービス資源を格納し、アプリケーションサーバにおけるサービス資源を更新する。もちろん、更新のためのサービス資源はまた、コアネットワークおよびアクセスネットワーク装置を通して、定期的またはリアルタイムに、外部ネットワークからアプリケーションサーバに送信され得る。

ＵＥのサービス要求を受信したとき、アクセスネットワーク装置は、サービス要求をアプリケーションサーバに送信し、もし、ＵＥによって要求されたサービス資源をアプリケーションサーバが持っているならば、アプリケーションサーバはＵＥのためのサービスを直接提供することができ、サービスのためのやりとりの経路を大いに縮め、サービスのためのやりとりにおいて関連するネットワーク要素の数を減らす、ということがわかる。従って、サービス遅延は減り、サービスのＱｏＳは改善され、ユーザ経験が改善される。たとえアプリケーションサーバがＵＥによって要求されたサービスをサポートしていなくても、あるいは、サービス資源を持っていなくても、ユーザのサービス利用への影響を避けられるように、アプリケーションサーバはまた引き続き、コアネットワークを通して、サービス要求をリモートサーバに送信し得る。システム全体の観点から、各アクセスネットワーク装置は通常、複数のＵＥのアクセスを許容し、各ＵＥは通常、複数のサービス要件を持っている。従って、必ずや、アプリケーションサーバによってサポートされることができるサービスがあり、それによって、サービス遅延が減り、全体的にサービスのＱｏＳが改善する。特に、複数のＵＥの同じサービス要求に対して、帰路（Backhaul）資源を上述の方法を用いて節することもできる。例えば、アプリケーションサーバがウェブ関連のキャッシュ加速（Cache acceleration）をサポートし、多くのユーザが、注目のビデオ、マイクロブログ、等に対するアクセスまたはダウンロードの必要を持っているとき、アプリケーションサーバは、この種類のサービスをこのときは直接提供する。これは、帰路資源を大いに節し、不十分な資源のせいで一部のユーザがアクセスを実行できないという問題を解決し、ダウンローディングおよびアクセスの遅延を減少し、それによって、ユーザ経験を大いに改善する。

他の例では、ステップＳ１１１において、アクセスネットワーク装置は、ＵＥのＭ２Ｍハンドシェイク要求を受信し、ＵＥによって要求された先方ＵＥもまたアクセスネットワーク装置にアクセスする。従来の処理においては、サービス要求は、コアネットワークを通過する必要があり、アクセスネットワーク装置によって先方ＵＥへ戻され供給される。この実施例において提供される方法を使用することにより、アプリケーションサーバがＭ２Ｍハンドシェイクサービスをサポートする限り、サービス要求は、コアネットワークを通過する必要がなく、これにより、サービス遅延が減少し、帰路資源が節せられる。

実施例において提供される通信方法、アクセスネットワーク装置、アプリケーションサーバ、および通信システムの特徴および長所は、ロングタームエボリューション（Long Term Evolution, LTE）通信システムを例として説明される。他の通信システム（例えば、ユニバーサル移動通信システム（Universal Mobile Telecommunications System、UMTS）および移動通信のためのグローバルシステム（Global System for Mobile Communications、GSM（登録商標）））はＬＴＥ通信システムに似ており、以下の実施例においては再度詳細は説明されない。

図１２は、本発明の一実施例において提供されるＬＴＥ通信システムの概略構成図である。図１２に示されるように、ｅＮＢ１２１およびアプリケーションサーバ１２２はアクセスネットワーク側に配置されており、アプリケーションサーバ１２２は、サードパーティアプリケーションサービスを実行するように構成され、ｅＮＢ１２１は、受信したサービスパケットをアプリケーションサーバ１２２にバイパスさせて処理させる必要がある。バイパスさせられたサービスパケットは、無線インターフェイス（UU）からのサービスパケット（すなわち、ＵＥによって送信されたサービスパケット）であり得、または、Ｓ１−Ｕインターフェイスからのサービスパケットであり、ＧＴＰ−Ｕにおいて運ばれ得る。サービングゲートウェイ（serving gateway、S-GW）１２３、パケットデータネットワークゲートウェイ（Packet Data Network (PDN) gateway、P-GW）１２４、および、移動管理エンティティ（Mobility Management Entity、MME）１２５は、コアネットワーク側に配置されている。Ｐ−ＧＷ１２４は、異なるネットワーク間のサービスデータストリームを検出し、ポリシーを実行し、ストリームベースの課金を実行するように構成されており、３ＧＰＰアクセスネットワークと非３ＧＰＰアクセスネットワークとの間のユーザプレーンアンカーポイントであり、コアネットワークパケット交換ドメインを外部ＰＤＮに接続するインターフェイスである。一方、Ｐ−ＧＷ１２４は、ポリシーおよび課金施行機能（Policy and Charging Enforcement Function、PCEF）エンティティとして機能し得、Ｇｘインターフェイスを通して、ポリシーおよび課金ルール機能（Policy and Charging Rules Function、PCRF）エンティティ１２６に接続され得る。Ｓ−ＧＷ１２３は、ｅＮＢ１２１とＰ−ＧＷとの間のユーザプレーントンネルを確立するように構成される。ＭＭＥ１２５の責任は、非アクセス層シグナリングの終端（例えば、移動管理およびセッション管理）、ゲートウェイ選択、およびＵＥ認証を含む。

なお、ＨＮＢ／ＨｅＮＢシナリオについては、サイトのカバレージが小さすぎるので、アプリケーションサーバは、コストを下げるために、ＨＮＢ／ＨｅＮＢゲートウェイ（ＧＷ）において展開され得る。ＵＭＴＳおよびＧＳＭについては、アプリケーションサーバは、ＲＮＣ／ＢＳＣにおいて、または、の近くにおいて展開され得る。ＨＮＢ／ＨｅＮＢ ＧＷまたはＲＮＣ／ＢＳＣは、受信したサービスパケットを、アプリケーションサーバにバイパスさせて処理させる必要がある。ここでバイパスされるパケットは、異なる規格／インターフェイスモードに伴って変化する。ＵＭＴＳについては、バイパスされるパケットは、無線インターフェイス方向からのパケットおよびＩｕ−ＰＳインターフェイス方向からのパケットである。そして、ＧＳＭについては、バイパスされるパケットは、無線インターフェイス方向からのパケットおよびＡ／Ｉｕ−ＰＳインターフェイス方向からのパケットである。図１３は、図１２に示された通信システムのユーザプレーンデータストリームの概略図である。実線は、アプリケーションサーバによって終端されることができるユーザプレーンデータストリームを表す。すなわち、もし、ユーザプレーンデータストリームが終端されることができるならば、サードパーティアプリケーションは直接下りリンクパケットを生成し、確立されたＧＴＰ−Ｕを使用することができる。点線は、アプリケーションサーバによっては終端できないユーザプレーンデータストリームを表す。本発明の実施例において、実線で表されるユーザプレーンデータストリームは、アプリケーションサーバによってサポートされるサードパーティアプリケーションに従って、好適に選択され得る。点線で表されるユーザプレーンデータストリームだけが存在する従来のケースに比較して、サービス遅延が減少し、そして、サービスのＱｏＳが改善される。そしてそれによってユーザ経験が改善される。

更に図１４を参照して、ｅＮＢ１２１とアプリケーションサーバ１２２との間のパケット送信を容易にするために、この実施例においては、上りリンク方向と下りリンク方向のそれぞれにおいてユーザプレーンチャネルが確立され、それぞれ、無線インターフェイス方向におけるサービスパケットとＳ１方向におけるサービスパケットを運ぶ。説明を明確にするために図１４においてｅＮＢは別々に示されているが、実際は、図１４の２つのｅＮＢは物理的には１つのエンティティである。加えて、無線インターフェイス方向におけるチャネルと、Ｓ１方向におけるチャネルとは、同じであるかもしれないし、別々であるかもしれない。そして、ユーザプレーンチャネルはＳ１チャネルとは異なり、そして、サービスパケットは、ｅＮＢによって転送される必要がある。

アプリケーション・無線ネットワークインターフェイスプロトコルは、上述されたものと似ており、アプリケーション・無線ネットワークインターフェイスプロトコルの制御プレーンプロトコルにおける制御情報のリストが以下に提供される（表１、表２に示されるとおり、表１における処理は応答を必要とする処理であり、表２における処理は、応答を必要としない処理である。）。

なお、ＵＭＴＳおよびＧＳＭは、表におけるメッセージ種別を再利用し得るが、その名前および意味は修正される必要がある。例えば、ｅＮＢ関連の語は特定のネットワーク要素名に修正される必要があり（例、ＵＭＴＳにおけるＲＮＣ）、他の意味は同じまま残るが、しかし、特定のセルは異なる。

ユーザプレーンチャネルを確立するプロセスの詳細が、上述の制御情報に従って、図１５を参照して、以下において説明される。図１５に示されるとおり：

ｅＮＢとアプリケーションサーバがパワーオンされた後、ｅＮＢとアプリケーションサーバとの間に制御プレーンリンクが確立される。具体的には、ｅＮＢは、ＳＣＴＰリンクを確立する処理を開始する。そして、ＳＣＴＰリンクが成功裏に確立された後、オープンアプリケーションプログラミングインターフェイス（Open API Interface）を確立するプロセスが開始される。オープンＡＰＩインターフェイスが成功裏に確立された後、制御プレーンリンクの確立は完了する。

ユーザプレーンチャネルが、ｅＮＢとアプリケーションサーバとの間に確立される。ＵＥの専用ベアラが確立されたとき、もし、ｅＮＢが、ＭＭＥによって送信されたサービスベアラ確立要求を受信すると、ｅＮＢは、ユーザプレーンチャネルの確立処理を完成させるように、アプリケーションサーバへのサービスベアラの確立処理のトリガーをかける。無線インターフェイス方向とＳ１方向のために、２つのユーザプレーンチャネルまたは１つのユーザプレーンチャネルが確立され得る。もし、１つのユーザプレーンチャネルだけが確立されるならば、チャネルまたはサービスパケットが無線インターフェイス方向からかＳ１方向からかを識別することが要求される。処理が成功するか否かにかかわらず、Ｓ１トンネル（すなわち、ｅＮＢとコアネットワークとの間のトンネル）が確立される。しかしながら、もし、ユーザプレーンチャネルが成功裏に確立されないならば、ｅＮＢは、サービスパケットをアプリケーションサーバに転送することができない。加えて、サービスベアラを確立する処理が成功するか否かにかかわらず、ユーザプレーンチャネルが確立されたか否かを知らせるために、サービスベアラ確立応答がＭＭＥに送信される必要がある。サービスベアラ、セッション管理、および、無線資源配布は当業者にとって周知であり、ここで再度詳しく説明されない。

もし、ｅＮＢが、ＭＭＥから送信されたベアラ更新要求を受信するならば、ｅＮＢは、アプリケーションサーバのベアラ情報が更新される必要があるか否かを判断し、そして、もし、必要があるならば、ｅＮＢはベアラ更新を開始する。そうでなければ、ｅＮＢはベアラ更新を開始しない。この処理は図１５には示されていない。

もし、ｅＮＢが自ら、または、ＭＭＥからメッセージを受信後に、ベアラ解放のトリガーをかけるならば、ｅＮＢは、サービスベアラを解放するようにアプリケーションサーバに命令する必要がある。そして、サービスベアラ解放の状況をＭＭＥに知らせるために、サービスベアラ解放応答がＭＭＥに送信される。

加えて、もし、アプリケーションサーバが、ｅＮＢの状態情報の購読を意図するならば、アプリケーションサーバは、状態情報の購読処理を開始し得る。もし、購読が成功したならば、ｅＮＢは、周期方式において、または、イベント方式において、購読された状態情報を報告する必要がある。

要約すると、本発明の実施例において、ＵＥがアクセスネットワーク側とサービス相互作用を直接実行できるように、サードパーティアプリケーションの運用をサポートするアプリケーションサーバがアクセスネットワーク側に導入され、これは、ユーザ要求の応答時間を大いに改善し、サービス遅延を減らし、サービスのＱｏＳを改善する。これによって、ユーザ経験が改善される。アクセスネットワーク側にアプリケーションサーバを加えるための実現可能なネットワーキングソリューションは、単一サイトのネットワーキング構造、または、クラウド（Cloud）ネットワークシナリオにおけるネットワーキング構造を含むが、これに限定されない。詳細な説明は以下において提供される：

単一サイトのネットワークソリューション：アクセスネットワーク装置から独立したアプリケーションサーバが、アクセスネットワーク側に直接加えられる。別の方法として、アプリケーションサーバは、アクセスネットワーク装置の１つの構成要素ユニットとして機能する。例えば、アプリケーションサーバは、ベースバンドボードと同じような方式で、ベースバンドユニット（BaseBand Unit、BBU）の中に直接組み込まれる。このとき、アプリケーションサーバユニットは、ボードの設計基準に準拠すべきであり、ＢＢＵの中に組み込まれ、バックボードを通してリンクチャネルを提供する。

クラウドネットワークシナリオに基づくネットワーキングソリューション：クラウドＢＢの標準ユニットとして機能するアプリケーションサーバが、クラウドベースステーション（Cloud BB）のキャビネットの中に組み込まれ、サードパーティアプリケーションサービスを提供する。

現在、従来技術においては、リモートサーバからＵＥへの距離を縮めてサービス遅延をさらに減らすために、例えば、ゲートウェイをＳ−ＧＷに、または、アクセスネットワーク側等に移動させる等、ゲートウェイを移動させるソリューションが提唱されている。このソリューションは、長いサービス時間およびサービスの低いＱｏＳの問題を解決することができるが、モビリティ、合法的傍受（lawful interception）、課金、帯域幅の節約、および他の観点とのバランスを達成することはできない。特に、モビリティの処理については、ひとたびＵＥが移動し、他のアクセスネットワーク装置からのアクセスを実行すると、ゲートウェイの背後のサードパーティサービスは、変化を検出することができず、従って、サービスの連続性を確保することができない。

本発明の実施例において、特定のサードパーティアプリケーションと組み合せて、モビリティ、合法的傍受、課金、帯域幅の節約、および他の観点を解決することができる。一例が以下で与えられる：

モビリティ処理

本発明の一実施例において提供されるアーキテクチャにおいて、ｅＮＢおよびアプリケーションサーバは、ＵＥが移動するとき、ユーザチャネルの確立と維持を実現することができる。これにより、サードパーティサービスと連携してサービス連続性を確保する。その状況が一例を用いて説明される：

例えば、ウェブ関連のサービスのために、このタイプのサービスのローカルキャッシュはアプリケーションサーバ上に展開され、このタイプのサービスのリモートキャッシュとサービス連続性制御機能エンティティは、コアネットワークの背後で展開される。そして、サービス終端機能エンティティは、Ｐ−ＧＷとＳ−ＧＷとの間で展開される。アプリケーションサーバ上のローカルキャッシュの内容は、リモートキャッシュの対応するコピーを持つかもしれないし持たないかもしれない。しかし、すべてのローカルキャッシュのインデックスはリモートサービス連続制御機能エンティティにおいて格納されている。すなわち、リモートキャッシュ機能エンティティは、計算を通じて、ローカルキャッシュがヒットしているかを取得することができる。

ＨＴＴＰ要求を受信するとき、アプリケーションサーバは、ローカルキャッシュがヒットしたか否かにかかわらず、Ｓ１−Ｕトンネルを通して、ＨＴＴＰシグナリングをコアネットワークへ転送する。リモートサービス連続性制御機能エンティティは、要求をリモートサーバへ転送する。要求を受信後、リモートサーバは、データをＵＥへ送信する。サービス連続性制御機能エンティティは、データがエンティティを通過するときに決定をする；もし、キャッシュがヒットしていないならば、データはキャッシュされ、キャッシュインデックス（Index）が生成される。キャッシュがヒットしているか否かにかかわらず、コンテンツはＵＥへ転送され続ける。そして、同時に、コンテンツがアプリケーションサーバ上のキャッシュによってヒットしたか否かが、ＴＣＰ拡張ヘッダによって定義されるプライベート関連情報によって示される。コンテンツがＰ−ＧＷを通してサービス終端機能エンティティに到達後、該関連情報が該エンティティによってチェックされる；もし、コンテンツがアプリケーションサーバによってヒットしたことを関連情報が示すならば、コンテンツは廃棄される。そうでなければ、コンテンツは引き続きＵＥへ転送される。もし、コンテンツが、Ｓ−ＧＷおよびｅＮＢを通してアプリケーションサーバへ転送され続けるならば、前回ローカルキャッシュによってヒットしなかったコンテンツはキャッシュされる。そして、キャッシュインデックスが生成される。もし、コンテンツがキャッシュによってヒットしているならば、元のコンテンツは置き換えられる（フォールトトレランス処理（fault tolerance processing））。

ＨＴＴＰ要求を転送するとき、ローカルアプリケーションサーバは、ローカルアプリケーション識別を示すために、アプリケーションパケットを運ぶＧＴＰ−Ｕパケットの中にプライベート拡張ヘッダを付加し得る。そして、もし、コンテンツがヒットしているならば、ＧＴＰ−Ｕパケットは、キャッシュインデックスを運ぶ必要がある。サービス終端機能エンティティを通過するとき、キャッシュインデックスは、プライベートＴＣＰ拡張ヘッダによって運ばれるように変更され得る。サービス連続性制御機能エンティティを通過するとき、サービス連続性制御機能エンティティは、上記要求と、キャッシュインデックスのようなＴＣＰ拡張ヘッダ内の情報とに対応するアプリケーションサーバを記録する。ＵＥが、あるｅＮＢから別のｅＮＢへ移動するとき、もし、アプリケーションサーバが変わると、リモートサービス連続性制御機能エンティティは、アプリケーションサーバが変わったことを知り、新しいアプリケーションサーバの中のコンテンツが、ローカルアプリケーションサーバの中にキャッシュされているか否かを知る。なぜならば、ＵＥのすべての要求情報はアプリケーションサーバを通過し、ローカルアプリケーション識別とキャッシュインデックスはＧＴＰ−Ｕの拡張ヘッダによって運ばれるからである。このようにして、サービスは連続的に送信されることができる。ＵＥが、アプリケーションサーバが利用可能な地域からアプリケーションサーバが利用可能でない地域へ移動するとき、または、アプリケーションサーバが利用可能でない地域からアプリケーションサーバが利用可能な地域へ移動するとき、ＵＥの制御情報はローカルに送信されるのではないので、リモートサービス連続性制御の機能は、変化を検出することができ、コンテンツを転送すべきか否かを知る。その結果、サービス連続性はまた、確保されることができる。

課金と合法的傍受処理に対しては２つのソリューションがある。

１．コアネットワークにおいてアプリケーションサーバゲートウェイが展開され、そして、課金ゲートウェイおよび合法的傍受ゲートウェイとの協調を実現する。課金に対しては、呼詳細記録がアプリケーションサーバによって生成され、アプリケーションサーバゲートウェイに報告される。そして、アプリケーションサーバゲートウェイは呼詳細記録をまとめて、課金ゲートウェイに報告する。合法的傍受に対しては、合法的傍受の開始後、アプリケーションサーバによってパケットがコピーされ、アプリケーションサーバゲートウェイに報告される。そして、アプリケーションサーバゲートウェイがパケットをまとめて、合法的傍受ゲートウェイに報告する。

２．モビリティ処理において説明されたサービスのような特定のサービスに対しては、アプリケーション層の制御情報は絶えずアプリケーションサーバへ送信され、アプリケーションサーバの全てのパケットはＰ−ＧＷを通過するので、３ＧＰＰの元の標準のソリューションが課金および合法的傍受に対して利用されることができる。課金および合法的傍受はＰ−ＧＷによって実現され、従って、既存のネットワーク要素には殆ど影響は生じない。

上述の方法を実現するステップの全てまたは一部は、関連するハードウェアに命令するプログラムによって実現することができることを当業者は理解することができる。該プログラムは、コンピュータ読み取り可能な媒体に格納され得る。読み取り可能な媒体は、ＲＯＭ／ＲＡＭ、磁気ディスク、光ディスク、等であり得る。

例えば、本発明の一実施例は、コンピュータ読み取り可能な媒体を含む、コンピュータプログラムプロダクトを提供する。読み取り可能な媒体は、上述の実施例において説明されたいかなる通信方法を実行するために使用される、プログラムコードのグループを含む。

添付された図は、本発明の単なる例示の実施例を示すだけであり、図において示されたユニットおよび処理は、本発明において必ずしも必須のものではないことを、当業者は理解すべきである。

実施例において提供された装置の中のユニットは、実施例の説明に従って装置の中に分散され得、または、実施例において説明されたものとは異なる１以上の装置の中に配置され得ることを、当業者は理解すべきである。上述の実施例におけるユニットは、１モジュールの中へ組み合わされ得、または、複数のサブユニットへ分割され得る。

最後に、留意されるべきは、本発明の上記実施例は、本発明を制限することを意図するものではなく、本発明の技術的ソリューションを説明することを意図するだけのものである、ということである。本発明は、上述の実施例を参照して詳細に説明されているが、上述の実施例において説明された技術的ソリューションに対して変更を加えることができること、または、その技術的特徴に対する均等な置換をすることができること、および、そのような変更または置換は、対応する技術的ソリューションのエッセンスを、本発明の実施例の技術的ソリューションのアイデアおよび範囲から離れさせることはできないことを、当業者は理解すべきである。

Claims (34)

1. アクセスネットワーク側に配置されるアクセスネットワーク装置によって実行される通信方法であって、アプリケーションサーバが前記アクセスネットワーク側に配置され、前記アプリケーションサーバは前記アクセスネットワーク装置から独立するか、又は前記アクセスネットワーク装置内にあり、前記アプリケーションサーバは少なくとも１つのサービスタイプの処理をサポートし、
   当該方法は、
   サービスパケットを受信するステップと、
   前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているか判断するステップと、
   前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているとき、前記サービスパケットを前記アプリケーションサーバに送信するか、又は、前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされていないとき、前記サービスパケットをコアネットワークに送信するステップと、
   を有する方法。
2. 請求項１に記載の方法であって、
   前記サービスパケットは、前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているか特定するのに使用される識別情報を有し、
   前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているか判断するステップは、
   前記識別情報に従って、前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているか判断するステップを有する、方法。
3. 請求項２に記載の方法であって、
   前記識別情報は、加入者プロファイル識別（ＳＰＩＤ）情報、サービス品質クラス識別子（ＱＣＩ）情報、ステートフルパケット検査（ＳＰＩ）情報、又はディープパケット検査（ＤＰＩ）を含む、方法。
4. 請求項１乃至３の何れか一項に記載の方法であって、
   前記アクセスネットワーク装置と前記アプリケーションサーバとの間にユーザプレーンチャネルを確立し、前記ユーザプレーンチャネルを介し前記サービスパケットを送信するステップを更に有する、方法。
5. 請求項４に記載の方法であって、
   前記ユーザプレーンチャネルはアプリケーション・無線ネットワークインタフェースプロトコルに従って確立され、前記アプリケーション・無線ネットワークインタフェースプロトコルは、制御プレーンプロトコルとユーザプレーンプロトコルとを含み、前記ユーザプレーンプロトコルは、前記ユーザプレーンチャネル上の情報伝送のために使用され、前記制御プレーンプロトコルは、前記ユーザプレーンチャネルの確立のために使用され、
   前記ユーザプレーンチャネルの確立は、
   前記制御プレーンプロトコルに従って、前記アクセスネットワーク装置と前記アプリケーションサーバとの間に制御プレーンリンクを確立し、
   前記制御プレーンリンクによって運ばれる制御情報に従って、前記アクセスネットワーク装置と前記アプリケーションサーバとの間に前記ユーザプレーンチャネルを確立する、ことを含む、方法。
6. 請求項５に記載の方法であって、
   前記制御情報は、前記アクセスネットワーク装置から無線ネットワークの状態情報を要求するのに使用される状態情報購読要求メッセージを含む、方法。
7. 請求項５又は６に記載の方法であって、
   前記制御情報は、前記サービスパケットを前記アプリケーションサーバに送信するためのポリシーを示すために使用されるポリシー変更要求メッセージを含む、方法。
8. アクセスネットワーク側に配置されたアプリケーションサーバによって実行される通信方法であって、前記アプリケーションサーバは少なくとも１つのサービスタイプの処理をサポートし、前記アプリケーションサーバはアクセスネットワーク装置から独立するか、又は前記アクセスネットワーク装置内にあり、
   当該方法は、
   サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされるとき、前記アクセスネットワーク装置から前記サービスパケットを受信するステップと、
   前記サービスパケットを処理するステップと、
   を有する方法。
9. 請求項８に記載の方法であって、
   前記サービスパケットは、前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているか特定するのに使用される識別情報を有する、方法。
10. 請求項８又は９に記載の方法であって、
    前記識別情報は、加入者プロファイル識別（ＳＰＩＤ）情報、サービス品質クラス識別子（ＱＣＩ）情報、ステートフルパケット検査（ＳＰＩ）情報、又はディープパケット検査（ＤＰＩ）を含む、方法。
11. 請求項８乃至１０の何れか一項に記載の方法であって、
    前記アクセスネットワーク装置と前記アプリケーションサーバとの間にユーザプレーンチャネルを確立し、前記ユーザプレーンチャネルを介し前記サービスパケットを受信するステップを更に有する、方法。
12. 請求項１１に記載の方法であって、
    前記ユーザプレーンチャネルはアプリケーション・無線ネットワークインタフェースプロトコルに従って確立され、前記アプリケーション・無線ネットワークインタフェースプロトコルは、制御プレーンプロトコルとユーザプレーンプロトコルとを含み、前記ユーザプレーンプロトコルは、前記ユーザプレーンチャネル上の情報伝送のために使用され、前記制御プレーンプロトコルは、前記ユーザプレーンチャネルの確立のために使用され、
    前記ユーザプレーンチャネルの確立は、
    前記制御プレーンプロトコルに従って、前記アクセスネットワーク装置と前記アプリケーションサーバとの間に制御プレーンリンクを確立し、
    前記制御プレーンリンクによって運ばれる制御情報に従って、前記アクセスネットワーク装置と前記アプリケーションサーバとの間に前記ユーザプレーンチャネルを確立する、ことを含む、方法。
13. 請求項１２に記載の方法であって、
    前記制御情報は、前記アクセスネットワーク装置から無線ネットワークの状態情報を要求するのに使用される状態情報購読要求メッセージを含む、方法。
14. 請求項１２又は１３に記載の方法であって、
    前記制御情報は、前記サービスパケットを前記アプリケーションサーバに送信するためのポリシーを示すために使用されるポリシー変更要求メッセージを含む、方法。
15. 請求項８乃至１４の何れか一項に記載の方法であって、
    前記サービスパケットを処理するステップは、
    前記サービスパケットを構文解析するステップと、
    前記構文解析されたサービスパケットに従って、前記サービスパケットに対応するサービスを実行するステップと、
    実行結果を前記アクセスネットワーク側にフィードバックするステップと、
    を含む、方法。
16. 請求項８乃至１５の何れか一項に記載の方法であって、
    コアネットワークからサービスパケットを受信するステップと、
    前記サービスパケットが前記アプリケーションサーバによりサポートされるサービスの更新データを有するとき、前記更新データを記憶するステップと、
    を更に有する、方法。
17. アクセスネットワーク側に配置されるアクセスネットワーク装置であって、アプリケーションサーバが前記アクセスネットワーク側に配置され、前記アプリケーションサーバは前記アクセスネットワーク装置から独立するか、又は前記アクセスネットワーク装置内にあり、前記アプリケーションサーバは少なくとも１つのサービスタイプの処理をサポートし、
    端末と通信するよう構成される第１のインタフェースユニットと、
    コアネットワークと通信するよう構成される第２のインタフェースユニットと、
    前記アプリケーションサーバと通信するよう構成される第３のインタフェースユニットと、
    前記第１のインタフェースユニット、前記第２のインタフェースユニット及び前記第３のインタフェースユニットに接続され、
    前記第１のインタフェースユニットを介しサービスパケットを受信するステップと、
    前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているか判断するステップと、
    前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているとき、前記サービスパケットを前記アプリケーションサーバに送信するか、又は、前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされていないとき、前記サービスパケットをコアネットワークに送信するステップと、
    を実行するよう構成されるプロセッサと、
    を有するアクセスネットワーク装置。
18. 請求項１７に記載のアクセスネットワーク装置であって、
    前記サービスパケットは、前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているか特定するのに使用される識別情報を有する、アクセスネットワーク装置。
19. 請求項１７又は１８に記載のアクセスネットワーク装置であって、
    前記識別情報は、加入者プロファイル識別（ＳＰＩＤ）情報、サービス品質クラス識別子（ＱＣＩ）情報、ステートフルパケット検査（ＳＰＩ）情報、又はディープパケット検査（ＤＰＩ）を含む、アクセスネットワーク装置。
20. 請求項１７乃至１９の何れか一項に記載のアクセスネットワーク装置であって、
    前記プロセッサは更に、前記第３のインタフェースユニットを介し前記アクセスネットワーク装置と前記アプリケーションサーバとの間にユーザプレーンチャネルを確立し、前記ユーザプレーンチャネルを介し前記サービスパケットを送信するよう構成される、アクセスネットワーク装置。
21. 請求項２０に記載のアクセスネットワーク装置であって、
    前記第３のインタフェースユニットのプロトコルは、アプリケーション・無線ネットワークインタフェースプロトコルであり、
    前記プロセッサは、前記アプリケーション・無線ネットワークインタフェースプロトコルに従って前記ユーザプレーンチャネルを確立し、
    前記アプリケーション・無線ネットワークインタフェースプロトコルは、制御プレーンプロトコルとユーザプレーンプロトコルとを含み、前記ユーザプレーンプロトコルは、前記ユーザプレーンチャネル上の情報伝送のために使用され、前記制御プレーンプロトコルは、前記ユーザプレーンチャネルの確立のために使用され、
    前記ユーザプレーンチャネルの確立は、
    前記制御プレーンプロトコルに従って、前記アクセスネットワーク装置と前記アプリケーションサーバとの間に制御プレーンリンクを確立し、
    前記制御プレーンリンクによって運ばれる制御情報に従って、前記アクセスネットワーク装置と前記アプリケーションサーバとの間に前記ユーザプレーンチャネルを確立する、ことを含む、アクセスネットワーク装置。
22. 請求項２１に記載のアクセスネットワーク装置であって、
    前記制御情報は、前記アクセスネットワーク装置から無線ネットワークの状態情報を要求するのに使用される状態情報購読要求メッセージを含む、アクセスネットワーク装置。
23. 請求項２１又は２２に記載のアクセスネットワーク装置であって、
    前記制御情報は、前記サービスパケットを前記アプリケーションサーバに送信するためのポリシーを示すために使用されるポリシー変更要求メッセージを含む、アクセスネットワーク装置。
24. 少なくとも１つのサービスタイプの処理をサポートし、アクセスネットワーク側に配置され、アクセスネットワーク装置から独立するか、又は前記アクセスネットワーク装置内にあるアプリケーションサーバであって、
    前記アクセスネットワーク装置と通信するよう構成されるインタフェースユニットと、
    前記アプリケーションサーバによってサポートされるサービスのサービスデータを記憶するよう構成される記憶ユニットと、
    前記インタフェースユニットと前記記憶ユニットとに接続される処理ユニットと、
    を有し、
    前記処理ユニットは、
    サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされるとき、前記インタフェースユニットを介し前記アクセスネットワーク装置から前記サービスパケットを受信するステップと、
    前記サービスパケットを処理するステップと、
    を実行するよう構成されるアプリケーションサーバ。
25. 請求項２４に記載のアプリケーションサーバであって、
    前記サービスパケットは、前記サービスパケットのサービスタイプが前記アプリケーションサーバによりサポートされているか特定するのに使用される識別情報を有する、アプリケーションサーバ。
26. 請求項２４又は２５に記載のアプリケーションサーバであって、
    前記識別情報は、加入者プロファイル識別（ＳＰＩＤ）情報、サービス品質クラス識別子（ＱＣＩ）情報、ステートフルパケット検査（ＳＰＩ）情報、又はディープパケット検査（ＤＰＩ）を含む、アプリケーションサーバ。
27. 請求項２４乃至２６の何れか一項に記載のアプリケーションサーバであって、
    前記処理ユニットは更に、前記インタフェースユニットを介し前記アクセスネットワーク装置と前記アプリケーションサーバとの間にユーザプレーンチャネルを確立し、前記ユーザプレーンチャネルを介し前記サービスパケットを受信するよう構成される、アプリケーションサーバ。
28. 請求項２７に記載のアプリケーションサーバであって、
    前記インタフェースユニットのプロトコルはアプリケーション・無線ネットワークインタフェースプロトコルであり、前記処理ユニットは、前記アプリケーション・無線ネットワークインタフェースプロトコルに従って前記ユーザプレーンチャネルを確立し、前記アプリケーション・無線ネットワークインタフェースプロトコルは、制御プレーンプロトコルとユーザプレーンプロトコルとを含み、前記ユーザプレーンプロトコルは、前記ユーザプレーンチャネル上の情報伝送のために使用され、前記制御プレーンプロトコルは、前記ユーザプレーンチャネルの確立のために使用され、
    前記ユーザプレーンチャネルの確立は、
    前記制御プレーンプロトコルに従って、前記アクセスネットワーク装置と前記アプリケーションサーバとの間に制御プレーンリンクを確立し、
    前記制御プレーンリンクによって運ばれる制御情報に従って、前記アクセスネットワーク装置と前記アプリケーションサーバとの間に前記ユーザプレーンチャネルを確立する、ことを含む、アプリケーションサーバ。
29. 請求項２８に記載のアプリケーションサーバであって、
    前記制御情報は、前記アクセスネットワーク装置から無線ネットワークの状態情報を要求するのに使用される状態情報購読要求メッセージを含む、アプリケーションサーバ。
30. 請求項２８又は２９に記載のアプリケーションサーバであって、
    前記制御情報は、前記サービスパケットを前記アプリケーションサーバに送信するためのポリシーを示すために使用されるポリシー変更要求メッセージを含む、アプリケーションサーバ。
31. 請求項２４乃至３０の何れか一項に記載のアプリケーションサーバであって、
    前記処理ユニットは、
    前記サービスパケットを構文解析するステップと、
    前記構文解析されたサービスパケットに従って、前記サービスパケットに対応するサービスを実行するステップと、
    実行結果を前記アクセスネットワーク側にフィードバックするステップと、
    を実行し、前記サービスパケットを処理するよう構成される、アプリケーションサーバ。
32. 請求項２４乃至３１の何れか一項に記載のアプリケーションサーバであって、
    前記処理ユニットは更に、
    コアネットワークからサービスパケットを受信するステップと、
    前記サービスパケットが前記アプリケーションサーバによりサポートされるサービスの更新データを有するとき、前記更新データを記憶するステップと、
    を実行するよう構成される、アプリケーションサーバ。
33. 請求項１７乃至２３の何れか一項に記載のアクセスネットワーク装置と、
    請求項２４乃至３２の何れか一項に記載のアプリケーションサーバと、
    を有する通信システム。
34. 請求項１乃至１６の何れか一項に記載の方法を実行するためのプログラムを有するコンピュータ可読記憶媒体。

Images