(57)【特許請求の範囲】
【請求項１】
発展型パケット・システム（ＥＰＳ）パケット・ドメインに関し、汎用パケット無線サービス（ＧＰＲＳ）パケット・ドメインのために定義されたＡＴコマンドの利用を促進する方法であって、
セカンダリ・パケット・データ・プロトコル（ＰＤＰ）コンテキストの定義を指示するＡＴコマンドに応答して、前記セカンダリＰＤＰコンテキストに基づき、ＥＰＳのサービス・データ・フロー（ＳＤＦ）を定義するステップを含むことを特徴とする方法。
【請求項２】
前記ＥＰＳのＳＤＦは、既存のパケット・データ・ネットワーク（ＰＤＮ）コネクション内で定義される、
ことを特徴とする請求項１に記載の方法。
【請求項３】
各ＡＴコマンドは、前記ＰＤＰコンテキストを参照するコンテキスト識別（ＣＩＤ）パラメータを含む、
ことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記ＡＴコマンドに含まれる前記ＣＩＤパラメータを、前記ＥＰＳのＳＤＦに対する参照として使用するステップを更に含む、
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＥＰＳのＳＤＦに関連付けられているＥＰＳディフォルト・ベアラのＣＩＤパラメータを、前記ＥＰＳディフォルト・ベアラに関連付けられているパケット・データ・ネットワーク（ＰＤＮ）コネクションと前記ＥＰＳのＳＤＦとをリンクさせるために使用するステップを更に含む、
ことを特徴とする請求項３又は４に記載の方法。
【請求項６】
非セカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドに応答して、前記非セカンダリＰＤＰコンテキストに基づき、ＥＰＳディフォルト・ベアラを定義するステップを更に含む、
ことを特徴とする請求項１から５のいずれか１項に記載の方法。
【請求項７】
前記ＡＴコマンドに含まれる前記ＣＩＤパラメータを、ＥＰＳディフォルト・ベアラの参照として使用するステップを更に含む、
ことを特徴とする請求項３又は６に記載の方法。
【請求項８】
ＥＰＳ個別ベアラを定義する機構を設けるステップを更に含む、
ことを特徴とする請求項１から７のいずれか１項に記載の方法。
【請求項９】
コンテキスト識別（ＣＩＤ）パラメータを含むＡＴコマンドに応答して前記ＥＰＳ個別ベアラを定義するステップと、
前記ＡＴコマンドに含まれる前記ＣＩＤパラメータを、前記ＥＰＳ個別ベアラの参照として使用するステップと、
を更に含むことを特徴とする請求項８に記載の方法。
【請求項１０】
ＥＰＳベアラと、前記ＥＰＳベアラの１つ以上のＳＤＦを確立し、前記ＥＰＳベアラと、前記ＥＰＳベアラの１つ以上のＳＤＦは、専用のＣＩＤによって参照される、
ことを特徴とする請求項３から９のいずれか１項に記載の方法。
【請求項１１】
前記方法は、レガシーＵＭＴＳモードもサポートするユーザ端末のロング・ターム・エボリユーション（ＬＴＥ）モードにおいて実行される、
ことを特徴とする請求項１から１０のいずれか１項に記載の方法。
【請求項１２】
前記レガシーＵＭＴＳモードにおいて、各ＡＴコマンドは、ＧＰＲＳパケット・ドメインの定義に従い解釈される、
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ユーザ端末は、ＬＴＥネットワーク・アクセス及びレガシーＵＭＴＳネットワーク・アクセス間での無線アクセス技術（ＲＡＴ）を変更するハンドオーバを実行することが可能であり、
前記ハンドオーバ前に前記ＥＰＳパケット・ドメインの１つのＥＰＳベアラにｎ個のＥＰＳのＳＤＦが関連付けられ、ｎ個のＰＤＰコンテキストが定義されている場合、前記ｎ個のＰＤＰコンテキストを、前記ＧＰＲＳパケット・ドメインへの１つのＰＤＰコンテキストにマッピングするステップを更に含む、
ことを特徴とする請求項１１又は１２に記載の方法。
【請求項１４】
ＧＰＲＳのサービス品質（ＱｏＳ）プロファイルとＥＰＳのＱｏＳプロファイル間の変換ロジックを設けるステップを更に含む、
ことを特徴とする請求項１から１３のいずれか１項に記載の方法。
【請求項１５】
前記ＧＰＲＳのＱｏＳプロファイルは、３ＧＰＰリリース７以前のＱｏＳプロファイルに準拠し、ＥＰＳのＱｏＳプロファイルは、３ＧＰＰリリース８以後のＱｏＳプロファイルに準拠する、
ことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記変換ロジックは、ＱｏＳプロファイルを特定するＡＴコマンドへの応答として使用される、
ことを特徴とする請求項１４又は１５に記載の方法。
【請求項１７】
前記ＡＴコマンドは、＋ＣＧＥＱＲＥＱ、＋ＣＧＥＱＭＩＮ、＋ＣＧＥＱＯＳ及び＋ＣＧＥＱＯＳＲＤＰのいずれかである、
ことを特徴とする請求項１６に記載の方法。
【請求項１８】
ＡＴコマンド＋ＣＧＣＭＯＤ及び＋ＣＧＴＦＴの少なくとも１つのサポートを設けるステップを更に含む、
ことを特徴とする請求項１から１７のいずれか１項に記載の方法。
【請求項１９】
ＡＴコマンド＋ＣＧＡＣＴのサポートを設けるステップを更に含む、
ことを特徴とする請求項１から１８のいずれか１項に記載の方法。
【請求項２０】
前記ＥＰＳのＳＤＦの活性化の際に、ベアラ・リソースの活性化に関するメッセージを送信するステップ、或いは、
前記ＥＰＳのＳＤＦの非活性化の際に、ベアラ・リソースの解放に関するメッセージを送信するステップを含む、
ことを特徴とする請求項１９に記載の方法。
【請求項２１】
前記ＥＰＳディフォルト・ベアラの活性化の際に、ＰＤＮ接続要求メッセージを送信するステップ、或いは、
前記ＥＰＳディフォルト・ベアラの非活性化の際に、ＰＤＮ切断要求メッセージを送信するステップを含む、
ことを特徴とする請求項５又は１９に記載の方法。
【請求項２２】
前記ＡＴコマンドは、アプリケーションから受信し、アプリケーションから要求され、又は、アプリケーションからのトリガにより生成される、
ことを特徴とする請求項１から２１のいずれか１項に記載の方法。
【請求項２３】
前記アプリケーションは、コネクションが、ＧＰＲＳパケット・ドメインへのものであるか、ＥＰＳパケット・ドメインへのものであるかを関知しない、
ことを特徴とする請求項２２に記載の方法。
【請求項２４】
前記アプリケーションは、ＥＰＳ個別ベアラのみを扱う様に構成されている、
ことを特徴とする請求項２２又は２３に記載の方法。
【請求項２５】
発展型パケット・システム（ＥＰＳ）パケット・ドメインに関し、汎用パケット無線サービス（ＧＰＲＳ）パケット・ドメインのために定義されたＡＴコマンドの利用を促進するためのコンピュータ・プログラムであって、
前記コンピュータ・プログラムは、コンピュータに、
セカンダリ・パケット・データ・プロトコル（ＰＤＰ）コンテキストの定義を指示するＡＴコマンドを受信するステップと、
前記ＡＴコマンドに応答して、前記セカンダリＰＤＰコンテキストに基づき、ＥＰＳのサービス・データ・フロー（ＳＤＦ）を定義するステップと、
を実行させることを特徴とするコンピュータ・プログラム。
【請求項２６】
請求項２５に記載のコンピュータ・プログラムを記録しているコンピュータ可読記録媒体。
【請求項２７】
発展型パケット・システム（ＥＰＳ）パケット・ドメインに関し、汎用パケット無線サービス（ＧＰＲＳ）パケット・ドメインのために定義されたＡＴコマンドの利用を促進する装置（８０）であって、
セカンダリ・パケット・データ・プロトコル（ＰＤＰ）コンテキストの定義を指示するＡＴコマンドに応答して、前記セカンダリＰＤＰコンテキストに基づき、ＥＰＳのサービス・データ・フロー（ＳＤＦ）を定義する様に構成された構成要素（８４）を含む、
ことを特徴とする装置。
【請求項２８】
前記ＥＰＳのＳＤＦは、既存のパケット・データ・ネットワーク（ＰＤＮ）コネクション内で定義される、
ことを特徴とする請求項２７に記載の装置。
【請求項２９】
各ＡＴコマンドは、前記ＰＤＰコンテキストの参照とする、コンテキスト識別（ＣＩＤ）パラメータを含む、
ことを特徴とする請求項２７又は２８に記載の装置。
【請求項３０】
前記ＡＴコマンドに含まれる前記ＣＩＤパラメータを、前記ＥＰＳのＳＤＦに対する参照として使用する様に構成された構成要素（９０）を更に含む、
ことを特徴とする請求項２９に記載の装置。
【請求項３１】
非セカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドに応答して、前記非セカンダリＰＤＰコンテキストに基づき、ＥＰＳディフォルト・ベアラを定義する様に構成された構成要素（８６）を更に含む、
ことを特徴とする請求項２７から３０のいずれか１項に記載の装置。
【請求項３２】
前記ＡＴコマンドに含まれる前記ＣＩＤパラメータを、ＥＰＳディフォルト・ベアラの参照として使用する様に構成された構成要素（９２）を更に含む、
ことを特徴とする請求項２９又は３１に記載の装置。
【請求項３３】
前記ＡＴコマンドに含まれる前記ＣＩＤパラメータを、前記ＥＰＳディフォルト・ベアラに関連付けられているパケット・データ・ネットワーク（ＰＤＮ）コネクションへのリンクとして使用する様に構成された構成要素（９２）を更に含む、
ことを特徴とする請求項３２に記載の装置。
【請求項３４】
請求項２７から３３のいずれか１項に記載の装置を含むことを特徴とするユーザ端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にＡＴコマンドの処理に関する。特に、発展型パケット・システム（ＥＰＳ）パケット・ドメインで、汎用パケット無線サービス（ＧＰＲＳ）パケット・ドメインで定義されているＡＴコマンドの利用を促進する技術を開示する。
【背景技術】
【０００２】
現代のＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）チップ・セットには、ＧＰＲＳ、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ）、広帯域符号分割多重アクセス（ＷＣＤＭＡ）、発展型高速パケット・アクセス（ｅＨＳＰＡ）等の無線アクセス技術（ＲＡＴ）の２つ以上をサポートするものがある。現在使用しているＲＡＴに拘わらず、マルチＲＡＴのＵＭＴＳユーザ装置（ＵＥ）は、パケット交換サービスのために、同じパケット交換ドメイン、つまり、ＧＰＲＳパケット・ドメインに常に接続される。この様に、ＵＥは、常に同じインターネット・プロトコル（ＩＰ）ベアラ及び接続の管理及び配分を使用するかもしれない。
【０００３】
ＧＰＲＳパケット・ドメインのＩＰベアラ及び接続の管理及び配分は、パケット・データ・プロトコル（ＰＤＰ）コンテキストに基づき、非特許文献１に一般的に記載されているベアラ及び接続の活性化、非活性化、修正のための機能を備えている。ＰＤＰコンテキストは、対象とするパケット・データ・ネットワーク（ＰＤＮ）への特定のベアラ及び接続を特徴づけるパラメータの記録データと看做すことができる。
【０００４】
１つのＵＥで動作する複数のアプリケーションは、１つ以上のＰＤＮへの複数の接続を必要とするかもしれず、その結果、複数のＰＤＰコンテキストを定義する必要があり得る。これら複数のＰＤＰコンテキストは、所謂、プライマリＰＤＰコンテキスト（非セカンダリＰＤＰコンテキストとしても以後参照する。）に一方ではグループ化することができ、他方ではセカンダリＰＤＰコンテキストにグループ化することができる。
【０００５】
複数のプライマリＰＤＰコンテキストは、異なるＰＤＮへの接続を提供し、それぞれは、一意のＩＰアドレスに関連付けられている。各セカンダリＰＤＰコンテキストは、既に存在しているプライマリＰＤＰコンテキストに基づき生成され、そのプライマリＰＤＰコンテキストと同じＰＤＮへの接続を提供する。しかしながら、セカンダリＰＤＰコンテキストは、一般的には、関連するプライマリＰＤＰコンテキストに保証されているのとは異なるサービス品質（ＱｏＳ）に関連付けられている。各プライマリ及びセカンダリＰＤＰコンテキストは、それ自身の無線アクセス・ベアラ（ＲＡＢ）を有し、ＧＰＲＳパケット・ドメイン及びＵＥにおいて局所的に使用される、一意のネットワーク・レイヤ・サービス・アクセス・ポイント識別子（ＮＳＡＰＩ）により識別される。
【０００６】
ＩＰアドレスは、プライマリＰＤＰコンテキストと、それに関連付けられているセカンダリＰＤＰコンテキストで同じであるので、ＧＰＲＳパケット・ドメインのゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）は、プライマリ及びセカンダリＰＤＰコンテキストの正しいＲＡＢに下りリンクのユーザ・プレーンのデータを送信するためにフィルタを必要とする。このフィルタは、ＵＥによってＧＧＳＮに送信されるセカンダリＰＤＰコンテキスト活性化要求メッセージで通知される、所謂、トラフィック・フロー・テンプレート（ＴＦＴ）を用いて設定される。
【０００７】
ＧＰＲＳパケット・ドメインとＵＥのレイヤ３機能間のリンクのための３ＧＰＰ標準で定義されているＩＰベアラ及び接続の管理及び配分の既存の解決法は、データ転送のためのこれらレイヤ３機能を利用するアプリケーションでも使用される。その様なアプリケーションは、ＵＥの内部にインストールされ、或いは、ＵＥがモデム・サービスを提供する外部の端末装置にインストールされ得る。
【０００８】
ＩＰベアラ及び接続の管理及び配分機能は、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を用いてアプリケーション（及び端末装置）に提供され得る。内部のアプリケーションのために、ＡＰＩは、非特許文献２に記載の、所謂オープン・プラットフォームＡＰＩ（ＯＰＡ）の形式で実現され得る。或いは、（例えば、外部のアプリケーションのために）ＩＰベアラ及び接続の管理及び配分機能は、非特許文献３に記載のＡＴコマンドＡＰＩにより提供され得る。
【０００９】
図１に示す様に、ＡＴコマンドは、端末装置（ＴＥ）から端末アダプタ（ＴＡ）経由でＧＰＲＳパケット・ドメインのサービスと、移動機終端（ＭＴ）機能を制御するために使用される。ＴＡ、ＭＴ及びＴＥは、必要に応じて個別又は一体化したものとして実装される。非特許文献３は、ＰＤＰコンテキストに基づきＧＰＲＳパケット・ドメインのサービスとＭＴ機能を制御するための複数のＡＴコマンドを定義している。各ＡＴコマンドは、ＡＴコマンドが適用される特定のＰＤＰコンテキスト（及び関連するＲＡＢ）を参照するためにコンテキスト識別子（ＣＩＤ）パラメータを含んでいる。
【００１０】
３ＧＰＰ標準のリリース８において、ロング・ターム・エボリユーション（ＬＴＥ）ＲＡＴ及び発展型パケット・システム（ＥＰＳ）が導入された。ＥＰＳは、従来のＧＰＲＳパケット・ドメインに代えて、ＬＴＥモードのＵＥが使用するパケット・ドメインである。
【００１１】
ＧＰＲＳパケット・ドメイン及びＥＰＳパケット・ドメインは、多くの点で異なる。例えば、ＥＰＳにおいては、ＰＤＰコンテキストによるのではなく、非特許文献４及び５に記載されている様に、ディフォルト・ベアラ、個別ベアラ及びサービス・データ・フロー（ＳＤＦ：ＥＰＳベアラ・リソースとも呼ばれる。）を定義する非アクセス・ストラタム（ＮＡＳ）プロトコルに基づいている。更に、ＧＰＲＳパケット・ドメインでは、ＵＥがＰＤＰコンテキストの設定を開始していたが、ＥＰＳベアラの設定手順は、常に、ネットワーク側から開始される。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】“Ｍｏｂｉｌｅ  Ｒａｄｉｏ  Ｉｎｔｅｒｆａｃｅ  Ｌａｙｅｒ  ３Ｓｐｅｃｉｆｉｃａｔｉｏｎ；  Ｃｏｒｅ  Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌｓ；  Ｓｔａｇｅ  ３”，３ＧＰＰ  ＴＳ  ２４．００８
【非特許文献２】Ａ.Ｇｈｏｓｈ，ｅｔ  ａｌ．，“Ｏｐｅｎ  ａｐｐｌｉｃａｔｉｏｎ  ｅｎｖｉｒｏｎｍｅｎｔｓ  ｉｎ  ｍｏｂｉｌｅ  ｄｅｖｉｃｅｓ：Ｆｏｃｕｓ  ｏｎ  ＪＭＥ  ａｎｄ  Ｅｒｉｃｓｓｏｎ  Ｍｏｂｉｌｅ  Ｐｌａｔｆｏｒｍｓ”，Ｅｒｉｃｓｓｏｎ  Ｒｅｖｉｅｗ，Ｖｏｌｕｍｅ  ８２，２００５．
【非特許文献３】“ＡＴ  ｃｏｍｍａｎｄ  ｓｅｔ  ｆｏｒ  Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔｓ”，３ＧＰＰ  ＴＳ  ２７．００７
【非特許文献４】“ＧＰＲＳ  ｅｎｈａｎｃｅｍｅｎｔｓ  ｆｏｒ  Ｅ−ＵＴＲＡＮ  ａｃｃｅｓｓ”，３ＧＰＰ  ＴＳ  ２３．４０１
【非特許文献５】“Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ  （ＮＡＳ）  ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ  （ＥＰＳ）；  Ｃｏｒｅ  Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌｓ；  Ｓｔａｇｅ３”，３ＧＰＰ  ＴＳ  ２４．３０１
【発明の概要】
【発明が解決しようとする課題】
【００１３】
ＥＰＳにおいて、ベアラは、ＱｏＳ制御粒度の基本レベルである（つまり、同じＥＰＳベアラの総てのデータ・トラフィックには、同じＱｏＳが保証され、異なるベアラには異なるＱｏＳが保証されることを意味する。）。ＥＰＳのディフォルト・ベアラは、初期ＵＥネットワーク・アタッチメント処理でのディフォルトＱｏＳプロファイルに従い設定される。結果、各ＵＥは、サービスの開始を早めるために、少なくとも１つの活性化されているベアラ（ディフォルト・ベアラ）を持つ。ディフォルト・ベアラの様に同じＰＤＮに接続される追加のＥＰＳベアラは、個別ベアラと呼ばれ、一般的には、関連するディフォルト・ベアラとは異なるＱｏＳプロファイルを持つ。
【００１４】
ＥＰＳのＳＤＦ機能は、ＧＰＲＳのＴＦＴ機能と似ており、各ＳＤＦは、パケット・フィルタ又はパケット・フィルタ集合体（例えば、複数の上り及び下りリンクのパケット・フィルタ）に関するものと看做すことができる。更に、各ＳＤＦは、特定のＱｏＳプロファイルに関連付けられる。ＳＤＦはＥＰＳベアラに基づくため、同じＱｏＳプロファイルを持つ幾つかのＳＤＦが、単一ＥＰＳベアラにマップされる統合されたＳＤＦを構成し得る。
【００１５】
ＴＦＴ及びＰＤＰコンテキストをどの様にマッピングするかをＵＥが決定するＧＰＲＳとは反対に、ＥＰＳにおいては、ネットワークがどの様にマッピングするかを決定する。結果、ＵＥがＮＡＳシグナリング経由で発行する、ＳＤＦのためのＬＴＥリソース配分要求メッセージは、要求されたＳＤＦを伴う新しいＥＰＳ個別ベアラを返すか、追加のＳＤＦを伴う既存ＥＰＳ（専用又はディフォルト）を返すことができる。ＧＰＲＳパケット・ドメインにおいて、対応するセカンダリＰＤＰコンテキスト活性化要求メッセージは、常に、関連するＲＡＢを有する新しい（セカンダリ）ＰＤＰコンテキストを返している。
【００１６】
ＥＰＳのＩＰベアラ及び接続の管理及び配分のためのアプリケーションへのインタフェースをどの様に作成するかについて幾つかの可能性が存在する。第一の解決法は、ＵＥ又はＵＥに接続されている端末装置のアプリケーションへのインタフェースに基づくものとして、ＵＥのレイヤ３機能とＥＰＳ間のインタフェースのために、非特許文献５で定義されている概念を利用することである。アプリケーションへのその様なインタフェースは、ベアラ・リソース配分／開放メッセージ、ＥＰＳディフォルト／個別ベアラ・コンテキスト活性化要求メッセージ等の、ＥＰＳに特有のメッセージを含むことになる。
【００１７】
この解決法は、ＬＴＥのみをサポートするために提供される単一ＲＡＴのＵＥではうまくいくが、ＬＴＥベアラでＥＰＳパケット・ドメインに接続し、レガシーのＵＭＴＳベアラでＧＰＲＳパケット・ドメインに接続するＬＴＥが利用可能な複数ＲＡＴのＵＥでは不利となる。特に、その様な解決法は、ＩＰベアラ及び接続の管理及び配分のためのアプリケーションへのインタフェースを、利用しているＲＡＴにより異ならせることを要求する。しかしながら、多くの場合、利用しているＲＡＴに拘わらず、アプリケーションがパケットに基づくサービスを要求できる（つまり、アプリケーションが、現在使用しているＲＡＴを認識する必要性をなくすことができる）ことが望ましい。
【００１８】
第２の解決法は、ＰＤＰコンテキストをＥＰＳベアラに変換して解釈し、その逆にも変換して解釈できる専用インタフェースをプログラミングすることである。第２の解決法によると、プライマリＰＤＰコンテキストは、対応するＥＰＳディフォルト・ベアラに変換して解釈し、セカンダリＰＤＰコンテキストは、対応するＥＰＳ個別ベアラに変換して解釈できる。結果、ＬＴＥベアラ制御のためのＡＴコマンド・インタフェースは、ＧＰＲＳパケット・ドメイン制御のための既存のＡＴコマンド・インタフェースの大部分を再利用できる。
【００１９】
第２の解決法の主な欠点は、上述した異なるベアラの活性化処理にある。つまり、ＧＰＲＳパケット・ドメインにおいては、新しいＰＤＰコンテキストを活性化するかをＵＥが決定し、ＥＰＳパケット・ドメインにおいては、新しいＥＰＳベアラを活性化するかをネットワークが決定する。結果、ＰＤＰコンテキスト／ＥＰＳベアラの活性化要求（＋ＣＧＡＣＴ）の様なＡＴコマンドは、利用するＲＡＴにより異なる様に解釈しなければならない。よって、ＬＴＥのＲＡＴとレガシーＧＰＲＳのＲＡＴとの差分処理するために、アプリケーションに付加的なロジックを実装しなければならない。これは、ＧＰＲＳパケット・ドメインのためにプログラムされたアプリケーションを、ＥＰＳパケット・ドメインのサポートのために更新しなければならないことを暗示している。
【課題を解決するための手段】
【００２０】
上述した問題の少なくとも幾つかを解決できる効果的な技術が必要とされている。特に、ＥＰＳパケット・ドメインにおいて、ＧＰＲＳパケット・ドメインのために定義されたＡＴコマンドの利用を促進する技術が必要とされている。
【００２１】
第１の態様によると、ＧＰＲＳパケット・ドメインのために定義されたＡＴコマンドの利用は、セカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドに応答して、セカンダリＰＤＰコンテキストに基づき、ＥＰＳのＳＤＦを定義するステップを含む方法により、ＥＰＳパケット・ドメインにおいて容易になる。
【００２２】
セカンダリＰＤＰコンテキストの要求は、この様に、要求されたセカンダリＰＤＰコンテキストのパラメータ（例えば、特定のパケット・フィルタ及び／又はＱｏＳプロファイルに関連）を考慮してＥＰＳのＳＤＦの要求と解釈される。その様な方法は、既存のアプリケーションを再プログラミングすることなく、多くの既存のＡＴコマンドをＥＰＳパケット・ドメインの制御に再利用することを可能にする。早期の３ＧＰＰ標準で使用されている用語“ＥＰＳのＳＤＦ”は、例えば、“ＥＰＳトラフィック・フロー”や、“ＥＰＳベアラ資源”の様に、後のバージョンにおいて繰り返し変更されていることに留意すべきである。よって、ここでの用語“ＥＰＳのＳＤＦ”は、非特許文献５の様な３ＧＰＰ標準の現在のバージョンにおける対応する概念を包含するものとして使用される。
【００２３】
新たに定義されるＥＰＳのＳＤＦ要求は、ＥＰＳパケット・ドメインへはＮＡＳシグナリングで通知され、要求されたＳＤＦを有する新しいＥＰＳ個別ベアラ又は当該ＳＤＦに関連付けられた既存のＥＰＳベアラについて返送する。ＳＤＦは、この様に、既存ＰＤＮコネクション内で定義される。用語“ＥＰＳベアラ”は、ＥＰＳディフォルト・ベアラ及びＥＰＳ個別ベアラの両方を参照するものとして使用する。同様に、用語“ＰＤＰコンテキスト”は、非セカンダリ（つまり、プライマリ）ＰＤＰコンテキストと、セカンダリＰＤＰコンテキストの両方を参照するものとして使用する。
【００２４】
ＡＴコマンドの総て又は幾つかは、セカンダリ又は非セカンダリＰＤＰコンテキストへの参照としてＣＩＤパラメータを含むことができる。セカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドの場合、ＡＴコマンドに含まれるＣＩＤパラメータは、この様にして定義されたＳＤＦへの参照として使用され得る。
【００２５】
新たに定義したＳＤＦは、特定のＰＤＮコネクションを持つＥＰＳディフォルト・ベアラに関連付けられ得る。ＥＰＳディフォルト・ベアラは、よって、個別ＣＩＤパラメータと関連付けられ、ＥＰＳディフォルト・ベアラのこのＣＩＤパラメータは、新たに定義したＳＤＦと、関連するＥＰＳディフォルト・ベアラ及び／又はＰＤＮコネクションをリンクするために、新たに定義したＳＤＦのＣＩＤパラメータと関連付けられ得る。
【００２６】
本方法は、非セカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドに応答して、非セカンダリＰＤＰコンテキストに基づき、ＥＰＳディフォルト・ベアラを定義するステップを更に含むことができる。ＥＰＳディフォルト・ベアラの定義は、非セカンダリＰＤＰコンテキストのパラメータを考慮して実行され得る。
【００２７】
非セカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドは、ＣＩＤパラメータを含むことができ、このＣＩＤパラメータは、新たに定義したＥＰＳディフォルト・ベアラへの参照として使用することができる。
【００２８】
セカンダリ及び非セカンダリＰＤＰコンテキストの定義を可能にする専用のＡＴコマンドを定義する場合において、各ＡＴコマンドのＣＩＤパラメータは、ＳＤＦ及びＥＰＳディフォルト・ベアラの両方の参照として、それぞれ、使用できる（例えば、ＥＰＳ個別ベアラとＥＰＳディフォルト・ベアラへの参照の代わりとして）。ＣＩＤにより参照されるＥＰＳディフォルト・ベアラは、“全適合”上り及び下りリンク・パケット・フィルタ（例えば、ＳＤＦで定義されたパケット・フィルタの代わりに）と関連付けることができる。さらに、ＣＩＤパラメータが、ＥＰＳディフォルト・ベアラへの参照として使用される場合、このＣＩＤパラメータは、特に、このＥＰＳディフォルト・ベアラのディフォルト・サービス又はコネクションへの参照として使用され得る。さらに、又は、代わりに、このＣＩＰパラメータは、このＥＰＳディフォルト・ベアラに関連するＰＤＮコネクションへの参照として使用され得る。
【００２９】
ＥＰＳ個別ベアラを定義する機構も設けられる。ある形態において、ＥＰＳ個別ベアラは、ＣＩＤパラメータを含むＡＴコマンドに応答して定義され得る。ＡＴコマンドに含まれるＣＩＤパラメータは、新たに定義したＥＰＳ個別ベアラへの参照として使用され得る。
【００３０】
例示的なシナリオにおいて、ＥＰＳベアラと、ＥＰＳベアラの１つ以上のＳＤＦが、特定のＰＤＮに関して確立される。このシナリオにおいて、ＥＰＳベアラと、ＥＰＳベアラの１つ以上のＳＤＦは、専用（つまり、異なる）ＣＩＤによって参照される。
【００３１】
ここで述べる技術は、ＬＴＥのＲＡＴと１つ以上のレガシーＵＭＴＳのＲＡＴをサポートする複数のＲＡＴ（又は複数のモード）のユーザ端末で実行され得る。レガシーＵＭＴＳ（例えば、ＧＰＲＳ及びＥＤＧＥを含む）モードにおいて、各ＡＴコマンドは、レガシーの標準（例えば、３ＧＰＰリリース７以前）でＧＰＲＳパケット・ドメインのために定義された様に解釈される。
【００３２】
複数のＲＡＴのユーザ端末は、ＬＴＥネットワーク・アクセス及びレガシーＵＭＴＳネットワーク・アクセス間のハンドオーバ（ＲＡＴ変更又はＲＡＴ内でのハンドオーバを含む）を実行することができる。ＬＴＥネットワーク・アクセスからレガシーＵＭＴＳネットワーク・アクセスへの典型的なハンドオーバのシナリオにおいて、ｎ個のＰＤＰコンテキストが定義され、ｎ個のＳＤＦが、ハンドオーバ前にＥＰＳパケット・ドメインの１つのＥＰＳベアラに関連付けられ得る。レガシーＵＭＴＳネットワーク・アクセスへのハンドオーバ後、ｎ個のＰＤＰコンテキストは、ＧＰＲＳパケット・ドメインへの１つのＰＤＰコンテキストにマッピングされ得る。
【００３３】
互換性の理由により、ＧＰＲＳのＱｏＳプロファイルとＥＰＳのＱｏＳプロファイル間の変換ロジックが提供され得る。変換ロジックにより、ＧＰＲＳのＱｏＳプロファイルは、ＥＰＳのＱｏＳプロファイルであると解釈され、その逆の解釈も行われる。ＧＰＲＳのＱｏＳプロファイルは、３ＧＰＰリリース７以前のＱｏＳプロファイルに準拠し、ＥＰＳのＱｏＳプロファイルは、３ＧＰＰリリース８以後のＱｏＳプロファイルに準拠し得る。変換ロジックは、ＡＴコマンド＋ＣＧＥＱＲＥＱ、＋ＣＧＥＱＭＩＮ、＋ＣＧＥＱＯＳ及び＋ＣＧＥＱＯＳＲＤＰのいずれかの様な、ＱｏＳプロファイルを特定するＡＴコマンドで利用され得る。ある形態において、これらＡＴコマンドは、ＬＴＥネットワーク・アクセスの場合にはＳＤＦに適用され、レガシーＵＭＴＳネットワーク・アクセスの場合にはＰＤＰコンテキストに適用される。
【００３４】
他の方法として、＋ＣＧＴＦＴ、＋ＣＧＣＭＯＤ及び＋ＣＧＡＣＴの様な１つ以上のＡＴコマンドのサポートが提供され得る。これらのＡＴコマンドは、ＬＴＥネットワーク・アクセスの場合にはＳＤＦ及び／ＥＰＳベアラに適用され、レガシーＵＭＴＳ（例えば、ＷＣＤＭＡ）ネットワーク・アクセスの場合にはＰＤＰコンテキストに適用され得る。
【００３５】
＋ＣＧＡＣＴのサポートは、ＥＰＳのＳＤＦの活性化の際に、ベアラ・リソースの活性化に関するメッセージ（例えば、ベアラ・リソース配分要求メッセージ）を送信すること、或いは、ＥＰＳのＳＤＦの非活性化の際に、ベアラ・リソースの開放に関するメッセージ（例えば、ベアラ・リソース修正要求メッセージ）を送信することを含む。さらに、ＡＴコマンド＋ＣＧＡＣＴに関し、ＥＰＳディフォルト・ベアラの活性化の際に、ＰＤＮ接続要求メッセージが送信され、或いは、ＥＰＳディフォルト・ベアラの非活性化の際に、ＰＤＮ切断要求メッセージが送信され得る。
【００３６】
ＡＴコマンドは、アプリケーション又はユーザ・インタフェース経由で要求され、受信され、又は、これらからのトリガにより生成される。アプリケーションは、ＵＥ内で局所的に、或いは、ＵＥがモデム・サービスを提供する外部端末装置により実行され得る。ある形態において、アプリケーションは、接続が、ＧＰＲＳパケット・ドメインへのものであるか、ＥＰＳパケット・ドメインへのものであるかを関知しない。言い換えると、アプリケーションは、現在利用されているＲＡＴを認識しない。
【００３７】
アプリケーションは、（例えば、＋ＣＧＤＣＯＮＴ及び＋ＣＧＤＳＣＯＮTの様な、非セカンダリ及びセカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドにより）１つ以上のＥＰＳベアラ及び１つ以上のＳＤＦの少なくとも１つの設定を開始することに制限され得る。これは、ＧＰＲＳパケット・ドメインのために定義された“従来”のＡＴコマンドの使用が、ＥＰＳディフォルト・ベアラ及びＳＤＦのみを確立することを暗示している。ＥＰＳ個別ベアラの設定に関し、追加の制御機構が必要に応じて提供され得る。例えば、ＥＰＳ個別ベアラは、アプリケーションにより非透過的に扱われ、その結果、アプリケーションは、必要に応じて、ＥＰＳ個別ベアラの設定を明確に要求する。例えば、新しいＡＴコマンドが、このために明示的に定義され得る。
【００３８】
ここに提示する技術は、ソフトウェア、ハードウェア又はそれらの組み合わせにより実現できる。ソフトウェアに関し、１つ以上のコンピュータ装置で実行されたときに、ここに述べるステップを実行するプログラムが提供される。コンピュータ・プログラムは、メモリ・チップ、ＣＤ−ＲＯＭ、ハード・ディスク等のコンピュータ可読記録媒体に保存され得る。さらに、コンピュータ・プログラムは、その様な記録媒体に、ネットワーク接続経由のダウンロードで提供され得る。
【００３９】
さらなる態様によると、ＥＰＳパケット・ドメインに関し、ＧＰＲＳパケット・ドメインのために定義されたＡＴコマンドの利用を促進する装置が提供される。装置は、セカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドに応答して、セカンダリＰＤＰコンテキストに基づき、ＥＰＳのＳＤＦを定義する様に構成された構成要素を含む。ＥＰＳのＳＤＦは、既存のＰＤＮコネクション内で定義され得る。
【００４０】
装置は、さらに、ＡＴコマンドに含まれるＣＩＤパラメータを使用し、セカンダリＰＤＰコンテキストを、ＥＰＳのＳＤＦへの参照として使用する様に構成された構成要素を含む。さらに、非セカンダリＰＤＰコンテキストの定義を指示するＡＴコマンドに応答して、非セカンダリＰＤＰコンテキストに基づき、ＥＰＳディフォルト・ベアラを定義する様に構成された構成要素が提供され得る。この構成要素は、そのＡＴコマンドに含まれるＣＩＤパラメータを使用し、ＥＰＳディフォルト・ベアラへの参照として非セカンダリＰＤＰコンテキストを使用する様に構成され得る。さらに、ＡＴコマンドに含まれるＣＩＤパラメータを、ＥＰＳディフォルト・ベアラに関連付けられているＰＤＮコネクションへのリンクとして使用する様に構成されている構成要素が、装置に含まれ得る。
【００４１】
上記装置を含むユーザ端末（ＵＥ）が提供される。ユーザ端末は、移動電話、ネットワーク・カード、データ・カード若しくはスティック、又は、ネットワークにアクセスできる可搬型若しくは卓上型コンピュータ等として実現できる。
【００４２】
提示する技術の更なる側面及び利点は、以下の好ましい実施形態及び図面の記述から明らかになる。
【図面の簡単な説明】
【００４３】
【図１】一方のアプリケーション又はユーザ・インタフェースと、他方のパケットに基づくネットワーク間を接続する機能エンティティの例示的な実装を示す図。
【図２】複数ＲＡＴをサポートするユーザ端末の一実施形態を示す図。
【図３】図２のユーザ端末のＡＴコマンド・コントローラの一実施形態を示す図。
【図４】図３のコントローラのアプリケーション・プログラミング・インタフェースの一実施形態を示す図。
【図５】一実施形態による方法のフロー図。
【図６】ＥＰＳ及びＧＰＲＳパケット・ドメインのパケット・ドメイン識別子を示すテーブル。
【発明を実施するための形態】
【００４４】
好ましい実施形態の以下の記述は説明を目的とするものであり、制限するものではなく、特定の詳細な説明（特定の信号処理部品及び信号処理ステップのシーケンス）は、本発明の理解のために提示される。記述される技術が、これら特定の詳細から離れて実施され得ることについては当業者には明らかである。
【００４５】
例えば、以下の実施形態は、主に、特定のＡＴコマンド（特に＋ＣＧＤＣＯＮＴ及び＋ＣＧＤＳＣＯＮＴ）を用いて記述されるが、ここで開示される技術は、３ＧＰＰで規定される他のＡＴコマンドに対しても適用できる。さらに、本技術は、３ＧＰＰ標準で定義されるＡＴコマンドに制限されない。例えば、本技術は、ＯＰＡ又は他のＥＰＳ／ＧＰＲＳベアラ管理のＡＰＩに基づくオープン・プラットフォーム・ソリューションのために定義されたコマンドに適用できる。さらに、実施形態は、ＬＴＥへの例示的な実装に関するものであるが、ここに記述する本技術は、ＬＴＥアドバンスド・ネットワークの様な、他の通信ネットワークにおいても実装することができる。
【００４６】
更に、当業者は、以下に説明するサービス、機能及びステップが、プログラムされたマイクロ・プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、デジタル・シグナル・プロセッサ（ＤＳＰ）又は汎用プロセッサのコンピュータにおいて、ソフトウェアを使用して実装できることを理解する。以下の実施形態は、方法及び装置により記述するが、本発明は、コンピュータ・プロセッサと、このプロセッサに接続するメモリとを含むシステムにおいて、コンピュータ・プログラムにより実現することができ、メモリは、開示するサービス、機能及びステップを実行する１つ以上のプログラムを含んでいる。
【００４７】
図２は、１つ以上のアプリケーション２２と、ＡＴコマンド信号によりアプリケーション２２にネットワークへのアクセス機能を提供する様に構成されたＡＴコマンド・コントローラ２４を含むユーザ端末（ＵＥ）２０の一実施形態を示している。ＵＥ２０は、少なくともＬＴＥネットワーク・アクセスと、ＷＣＤＭＡ又はｅＨＳＰＡネットワーク・アクセスを少なくとも含む複数のＲＡＴによりネットワークへのアクセスをサポートする様に構成されている。図２に示す様に、アプリケーション２２は、ＥＰＳパケット・ドメイン３０（ＬＴＥネットワーク・アクセス）又はＧＰＲＳパケット・ドメイン４０（ＷＣＤＭＡ／ｅＨＳＰＡネットワーク・アクセス）のいずれかでサービスを受ける。ＵＥ２０は、ＲＡＴ間ハンドオーバ、例えば、ＷＣＤＭＡ又はｅＨＳＰＡからＬＴＥへと、その逆をサポートする様に構成される。
【００４８】
他の実施形態として、アプリケーション２２は、携帯型又は固定型のコンピュータの様な、端末装置で動作する外部アプリケーションであり得ることに留意すべきである。外部への実装の場合、ＵＥ２０は、端末装置にモデム・サービスを提供する様に構成される。
【００４９】
図３は、ＵＥ２０のＡＴコマンド・コントローラ２４の構成を示している。図３から明らかな様に、ＡＴコマンド・コントローラ２４は、図１を参照して既に説明した機能エンティティを一般的に有している。つまり、ＡＴコマンド・コントローラ２４は、端末装置部（ＴＥ）５０、ＴＥ５０に接続する端末アダプタ部（ＴＡ）６０、ＴＡ６０に接続する移動終端部（ＭＴ）７０を有している。
【００５０】
ＴＥ５０は、ＡＴコマンドによりＴＡ６０と通信して対応する応答を受信する。ＴＥ５０との通信のために、ＴＡ６０は、ＡＴコマンド・インタフェース８０をＡＰＩの形式で含んでいる。ＴＡ６０は、図３に示すＭＴ制御メッセージ及び状態メッセージによりＭＴ７０と通信する。ＭＴ７０は、例えば、図２に示すＥＰＳパケット・ドメイン３０及びＧＰＲＳパケット・ドメイン４０へのネットワーク・アクセス機能を提供する。このため、ＭＴ７０は、利用しているＲＡＴ経由でネットワーク・メッセージを送受信する。
【００５１】
ＴＡ６０のＡＴコマンド・インタフェース８０の内部構成を図４に示す。図4に示す様に、ＡＴコマンド・インタフェース８０は、ＡＴコマンド・インタプリタ８２と、ＥＰＳ・ＳＤＦ定義部８４と、ＥＰＳディフォルト・ベアラ定義部８６と、他のＡＴコマンドの処理部８８と、を備えている。さらに、図4に示す様に、ＥＰＳ・ＳＤＦ定義部８４及びＥＰＳディフォルト・ベアラ定義部８６にはそれぞれ専用のＣＩＤ参照部９０、９２が接続される。各ＣＩＤ参照部９０、９２は、ＳＤＦ及びＥＰＳのＣＩＤパラメータの相関マップを保存する様に構成された保存部９４が接続される。マップは、さらに、ＥＰＳ個別ベアラのためのＣＩＤパラメータを保持することもできる。一実施形態として、マップは、第一列に個々のＣＩＤパラメータを、第二列に関連するＳＤＦの識別子、ディフォルト・ベアラ、オプションとしての個別ベアラを配置したテーブルの形態である。
【００５２】
図４に示すＡＴコマンド・インタフェース８０の動作について、例示的な方法である図５のフロー図５００を参照して説明する。
【００５３】
最初のステップ５０２において、インタプリタ８２は、ＴＥ５０からＡＴコマンドを受信する。ＡＴコマンドは、アプリケーション２２からＴＥ５０によって受信されたもの、或いは、アプリケーション２２又はユーザ・インタフェース（図示せず）から受信した要求によって、ＴＥ５０が生成したものであるかもしれない。本実施形態において、受信したＡＴコマンドは、（プライマリ）ＰＤＰコンテキストの定義を指示する＋ＣＧＤＣＯＮＴ又はセカンダリＰＤＰコンテキストの定義を指示する＋ＣＧＤＳＣＯＮＴのいずれかとする。どちらの場合でも、ＡＴコマンドは、ＣＩＤパラメータと、例えば、パケット・データのプロトコル種別（ＩＰやＸ.２５等）を指示するＰＤＰコンテキスト定義パラメータを含んでいる。
【００５４】
ＡＴコマンドが、プライマリＰＤＰコンテキストの定義を指示する場合、ＥＰＳディフォルト・ベアラ定義部８６が次の処理ステップを実行する。そうでなければ、つまり、ＡＴコマンドが、セカンダリＰＤＰコンテキストの定義を指示する場合、ＥＰＳのＳＤＦ定義部８４が更なる処理を実行する。受信したＡＴコマンドが、＋ＣＧＤＣＯＮＴでも、＋ＣＧＤＳＣＯＮＴでもなければ（図５において考慮していない場合）、処理部８８が更なる処理を実行する。
【００５５】
続いて、図５の処理において、ＡＴコマンドが＋ＣＧＤＣＯＮＴである場合の処理をまず説明する。ステップ５０４において、ＥＰＳディフォルト・ベアラは、ＡＴコマンドにより受信したプライマリＰＤＰコンテキスト定義に基づき定義される。ＰＤＮ接続当たり１つのＥＰＳディフォルト・ベアラが常に存在するため、プライマリＰＤＰコンテキストは、ＥＰＳディフォルト・ベアラに属するＰＤＮ接続も規定する。上述した様に、各ＰＤＮ接続はそれ自身のＩＰアドレスを有している。
【００５６】
受信したＡＴコマンド＋ＣＧＤＣＯＮＴにおいて定義されるプラマリ・コンテキストは、同じＡＴコマンドに含まれる特定のＣＩＤパラメータに関連付けられる。このＣＩＤパラメータで定義されるプライマリＰＤＰコンテキストは、それが、“全適合”上り及び下りリンク・パケット・フィルタに関連付けられているＥＰＳディフォルト・ベアラ上での特定のディフォルト・サービス／接続の参照（つまり、例えば、ＳＤＦに従う専用パケット・フィルタが定義されていないディフォルト・サービス／接続への参照）としてのみ使用されるため、ＥＰＳディフォルト・ベアラの総てのサービスを含むものではない。これは、特定のＥＰＳディフォルト・ベアラの任意の（他の）ＳＤＦが、以下にその詳細を説明する様に、他のＣＩＤパラメータによって参照され得るので、特定のＣＩＤパラメータ（特定のＣIＤパラメータ自身も同様に）で定義されるプライマリＰＤＰコンテキストは、これらＳＤＦへの参照として使用されないことを意味している。
【００５７】
ＥＰＳディフィルト・ベアラ定義ステップ５０４の後、ＡＴコマンド・インタフェース８０の処理は、ＣＩＤ参照部９２によって対応するＡＴコマンド＋ＣＧＤＣＯＮＴに含まれる特定のＣＩＤパラメータによって新しく定義するＥＰＳディフォルト・ベアラを参照する処理に進む（ステップ５０６）。このため、特定のＣＩＤパラメータが、保存部９４が維持するテーブルに、新しく定義するＥＰＳディフォルト・ベアラの識別子（例えば、ＧＰＲＳパケット・ドメインでのＮＳＡＰＩに対応）と共に、入力されている。
【００５８】
次のステップ５０８において、新しく定義したＥＰＳディフォルト・ベアラを活性化する要求が生成される。ステップ５０８は、インタプリタ８２によるＡＴコマンド＋ＣＧＤＣＯＮＴの受信の応答として、ＡＴコマンド処理部８８が実行することができる。活性化するＥＰＳディフォルト・ベアラを識別するために、ＡＴコマンド処理部８８は、ＡＴコマンド＋ＣＧＡＣＴに含まれるＣＩＤパラメータを判定し、図４の矢印で示す様に、保存部９４から関連するＥＰＳディフォルト・ベアラの識別子を読み出すことができる。更に、ステップ５０８において、ＡＴコマンド処理部８８は特定のＥＰＳディフォルト・ベアラのＰＤＮ接続要求を生成し、図３のＭＴ７０にＭＴ制御信号で要求を転送できる。図３のＭＴ７０は、この要求を、対応するネットワーク・メッセージでＥＰＳパケット・ドメイン３０に転送できる。
【００５９】
続いて、図５に示すフロー図の第２の処理ブランチの詳細について説明する。第２の処理ブランチは、ステップ５０２で受信したＡＴコマンド＋ＣＧＤＳＣＯＮＴに含まれるセカンダリＰＤＰコンテキスト・パラメータに基づきＥＰＳのＳＤＦを定義するステップ５１０から開始する。ステップ５１０は、受信したＡＴコマンド＋ＣＧＤＳＣＯＮＴに含まれるセカンダリＰＤＰコンテキスト・パラメータに基づき、既存のＰＤＮ接続内の新しいＥＰＳのＳＤＦを定義するＥＰＳ・ＳＤＦ定義部８４により実行される。これは、新しく定義されるＳＤＦは、新しく定義されるＳＤＦに関連付けられるＥＰＳディフォルト・ベアラと同じＩＰプロトコルの設定に基づくということを意味している。アプリケーション２２は、新しく定義されるＳＤＦが、新しいＥＰＳ個別ベアラに設定されるか、既存のＥＰＳ個別ベアラに設定されるか、関連するＥＰＳディフォルト・ベアラに設定されるかについて認識しない。新しく定義されるＳＤＦは、関連するＥＰＳディフォルト・ベアラのＣＩＤパラメータ（例えば、保存部９４内）を特定することにより特定のＰＤＮ接続にリンクされる。
【００６０】
ＥＰＳのＳＤＦがステップ５１０で定義されると、ＡＴコマンド・インタフェース８０の動作は、ステップ５１２に進む。ステップ５１２において、新しく定義されたＥＰＳのＳＤＦは、ＥＰＳのＳＤＦを定義するセカンダリＰＤＰコンテキストに含まれているＡＴコマンド＋ＣＧＤＳＣＯＮＴで搬送されているＣＩＤパラメータによって参照される。このため、ＣＩＤ参照部９０は、保存部９４のテーブルに新たなエントリを生成する。この新たなエントリは、ＣＩＤパラメータを新たに生成したＳＤＦに関連付ける。加えて、テーブルのエントリは、新たに定義したＳＤＦの基礎となるＥＰＳディフォルト・ベアラのＣＩＤパラメータを含む。
【００６１】
更なるステップ５１４において、新たに定義したＳＤＦの活性化の要求が生成される。ステップ５０８で既に述べた様に、ＳＤＦの活性化の要求は、特定のセカンダリＰＤＰコンテキストの活性化を要求するＡＴコマンド＋ＣＧＡＣＴの受信の応答として生成できる。ＡＴコマンド処理部８８は、最初のステップにおいて、ＡＴコマンド＋ＣＧＡＣＴに含まれるＣＩＤパラメータを判定し、保存部９４のテーブルから関連するＳＤＦ識別子（そして、オプションとして関連するＥＰＳディフォルト・ベアラの対応する識別子）を読み出し、ＭＴ７０経由でＥＰＳパケット・ドメイン３０に送信される、ベアラ・リソース配分要求又は同様のメッセージを生成する。
【００６２】
上記内容から明らかな様に、種々の識別子がＡＴコマンド・インタフェース８０により、その動作中に定義され、読み出され、そして処理される。これら識別子の総ては、保存部９４のテーブル（又は他のデータ構造）に保存され得る。一般的に、ネットワーク（ＧＰＲＳパケット・ドメイン又はＥＰＳパケット・ドメイン）への識別子は、アプリケーション２２で使用される識別子とは異なる。図６のテーブル６００は、ＧＰＲＳパケット・ドメイン及びＥＰＳパケット・ドメインそれぞれにおいて、ネットワークでの識別子とアプリケーション２２での識別子の関係を示している。
【００６３】
保存部９４が保持する情報は、ハンドオーバ又はＲＡＴ変更（例えば、ＷＣＤＭＡネットワーク・アクセスからＬＴＥネットワーク・アクセス、又はその逆）の際に利用され得る。ＡＴコマンド・インタフェース８０は、ハンドオーバ又はＲＡＴ変更の際に、アプリケーション２２への適合を必要としないことが一般的な目標である。言い換えると、アプリケーション２２は、現在活性化されている特定のＲＡＴを認識しないままとできる。
【００６４】
ＡＴコマンド・インタフェース８０の両側、つまり、ネットワーク及びアプリケーション２２側において、レガシーＵＭＴＳ（ＷＣＤＭＡ、ＧＰＲＳ、ＥＤＧＥを含む）モードのＰＤＰコンテキストは、ＩＰベアラの接続管理及び配分に使用される。このため、従来のインタフェース解決法においては、ＣＩＤパラメータとＮＳＡＰＩパラメータには１対１の関係がある。このＡＴコマンド・インタフェース８０の両側における１対１の関係は、ＬＴＥネットワーク・アクセスからレガシーＵＭＴＳネットワーク・アクセスへのハンドオーバを扱うためには、ネットワーク側のＰＤＰコンテキスト（ＮＳＡＰＩにより識別される）とアプリケーション２２側のＰＤＰコンテキスト（ＣＩＤパラメータにより識別される）には１対ｎの関係が有る様に変更しなければならない。
【００６５】
この１：ｎの関係は、ハンドオーバ又はＲＡＴ変更前に、１つのＥＰＳベアラにマッピングされたｎ個のＳＤＦが有る場合、アプリケーション２２側のインタフェースにｎ個のＰＤＰコンテキストが存在し、このｎ個のＰＤＰコンテキストは、ネットワーク側のインタフェースの１つのＰＤＰコンテキスト（つまり、ハンドオーバ又はＲＡＴ変更後のＧＰＲＳパケット・ドメイン側）にマッピングされることを意味している。このマッピングは、保存部９４のテーブルのエントリに基づきＡＴコマンド・インタフェース８０の専用部（図示せず）により実行され得る。
【００６６】
今まで、本実施形態は、ＡＴコマンド＋ＣＧＤＣＯＮＴ及びＣＧＤＳＣＯＮＴと、ＡＴコマンド＋ＣＧＡＣＴの幾つかの側面に焦点をあてて説明してきた。以下においては、ＡＴコマンド・インタフェース８０の動作、より詳しくは、ＡＴコマンド・コントローラ２４がサポートする他のレガシーＡＴコマンドに対するＡＴコマンド処理部８８の動作について説明する。
【００６７】
まず、ＡＴコマンド・コントローラ２４は、ＡＴコマンド＋ＣＧＥＱＲＥＱをサポートするかもしれない。このコマンドは、ＴＥ５０（及びアプリケーション２２）が、ＵＥ２０がベアラ・リソース配分するときに（例えば、ネットワークにベアラ・リソース配分要求メッセージを送信することにより）利用されるＱｏＳプロファイルを特定することを可能にする。ＥＰＳパケット・ドメインのシナリオにおいて、このコマンドは、コマンドに含まれるＣＩＰパラメータによって識別されるＳＤＦのＱｏＳプロファイルを特定する。後方互換のために、コマンド自体は、３ＧＰＰ規格のリリース７に準拠するＱｏＳプロファイルを特定する。よって、ＥＰＳパケット・ドメインにおいて要求されたＱｏＳプロファイルを実現するために、ＡＴコマンド・インタフェースは、要求された３ＧＰＰリリース７のＱｏＳプロファイルを、ＥＰＳパケット・ドメインのための３ＧＰＰリリース８のＱｏＳプロファイルに変換する。
【００６８】
ＡＴコマンド・インタフェース８０は、さらに、ＡＴコマンド＋ＣＧＥＱＭＩＮをサポートするかもしれない。このコマンドは、ＴＥ５０及びアプリケーション２２が、受け入れられる最小のＱｏＳプロファイルを特定することを可能にし、受け入れられる最小のＱｏＳプロファイルは、例えば、個別ベアラ・コンテキスト活性化要求又はＥＰＳベアラ・コンテキスト修正要求により交渉中のＱｏＳプロファイルが返送されたとき、ＵＥ２０により検査される。このコマンドは、コマンドに含まれるＣＩＤにより識別されるＳＤＦのためのＱｏＳプロファイルを特定する。後方互換のため、ＱｏＳプロファイル自体は、３ＧＰＰ規格のリリース７に準拠して特定される。よって、ＥＰＳパケット・ドメインにおいて要求された３ＧＰＰリリース７のＱｏＳプロファイルを使用するために、ＡＴコマンド・インタフェース８０は、要求された３ＧＰＰリリース７のＱｏＳプロファイルを、ＥＰＳパケット・ドメインのための３ＧＰＰリリース８のＱｏＳプロファイルに変換する、変換ロジックを実装しなければならない。
【００６９】
ＡＴコマンド・インタフェース８０は、さらに、ＡＴコマンド＋ＣＧＥＱＮＥＧをサポートするかもしれない。このコマンドは、ＴＥ５０及びアプリケーション２２が、個別ベアラ・コンテキスト活性化要求又はＥＰＳベアラ・コンテキスト修正要求で返送される、ＳＤＦ（ＡＴコマンドに含まれるＣＩＤパラメータにより特定される）の交渉したＱｏＳプロファイルを読み出すことを可能にする。ネットワークのＥＰＳベアラ当たり（ＳＤＦ当たりではなく）唯一つのＱｏＳ定義を有するにも拘らず、ＱｏＳプロファイル定義のためのＡＴコマンドは、ＥＰＳパケット・ドメインで再利用され得る。よって、ＵＥ側において、ＳＤＦに返送された交渉しているＱｏＳプロファイルの保存（例えば、保存部９４に）を可能にする様な拡張が可能である。１つのＣＩＤパラメータが正確に１つのＰＤＰコンテキストのみ参照しているので、ＧＰＲＳパケット・ドメインのために、ＱｏＳプロファイルは、ＰＤＰコンテキストのみに対して保存されなければならないことに留意すべきである。ＬＴＥシステムにおいて、交渉しているＱｏＳは、同じＥＰＳベアラにおいては総てのＳＤＦにおいて同じであることが期待されていることに留意すべきである。
【００７０】
インタフェース８０は、さらに、ＡＴコマンド＋ＣＧＴＦＴをサポートするかもしれない。このコマンドは、アプリケーション２２が、ＳＤＦに割り当てられた少なくとも１つのパケット・フィルタを定義することを可能にする。ＳＤＦ自体は、１つ以上のパケット・フィルタを統合したものと関係する。ＬＴＥシステムにおいて、１つ以上のパケット・フィルタ（レガシーＵＭＴＳシステムにおけるＴＦＴに対応）は、ＰＤＮコネクションのために定義され、ＰＤＮコネクション内において利用可能なＥＰＳ個別ベアラに対して、どの様にパケットをルーティングするかを定義する。現在の場合、ＥＰＳ個別ベアラを識別しないことは、ＣＩＤパラメータではなく、ＳＤＦの問題である。ＧＰＲＳパケット・ドメインにおいて、ＡＴコマンド＋ＣＧＴＦＴは、所定のＩＰアドレスに定義された総てのパケット・フィルタの監視を維持することを要求する。この点において、パケット・フィルタの識別子は、プライマリＰＤＰコンテキストのＣＩＤパラメータに関連する総てのＣＩＤパラメータに渡り一意でなければならない。パケット・フィルタの定義は、任意のＣＩＤパラメータにより行われ、ＰＤＰコネクション内の総てのセカンダリＰＤＰコンテキストに渡り監視される必要があるので、ＬＴＥシステムにおいて、ＣＩＤパラメータをＳＤＦが指定するものとして使用したとしても、何ら問題は生じない。しかしながら、総てのパケット・フィルタ識別子が１つのＰＤＮコネクションに属する総てのＳＤＦに渡り一意であることを確実にするために、パケット・フィルタ識別子の監視は依然必要である。
【００７１】
既に簡潔に述べた様に、ＡＴコマンド・インタフェース８０は、ＡＴコマンド＋ＣＧＡＣＴもサポートしている。この“実行”コマンドは、ＥＰＳベアラ及び／又はＳＤＦの活性化又は非活性化のために利用される。ＥＰＳベアラ及びＳＤＦは、ＡＴコマンド＋ＣＧＡＣＴにおいて、その対応するＣＩＤパラメータにより定義される。図５を参照して説明したＥＰＳディフォルト・ベアラ又はＳＤＦを活性化する利用法に加えて、非活性化を実装することもできる。その場合、例えば、ＥＰＳディフォルト・ベアラの非活性化が要求され、ＰＤＮ切断要求がネットワークに送信される。他方、ＳＤＦの非活性化が要求されると、対応する開放メッセージ（ベアラ・リソース開放要求メッセージの様な）がネットワークに送信される。
【００７２】
さらに、ＡＴコマンド・インタフェース８０は、ＡＴコマンド＋ＣＧＣＭＯＤもサポートできる。このコマンドは、それに含まれる特定のＣＩＤパラメータによって定義されるＳＤＦを修正するために利用される。修正は、特に、ＱｏＳプロファイルとパケット・フィルタに関係する。修正される各ＳＤＦについて、対応する修正メッセージ（ベアラ・リソース配分要求メッセージの様な）が、ネットワークに送信される。
【００７３】
上述したＡＴコマンドは、基本的に、ＧＰＲＳパケット・ドメインで既に定義されているレガシーＡＴコマンドであり、ＥＰＳパケット・ドメインで再利用することができる。以下に、既存のＡＴコマンドの修正及びＥＰＳパケット・ドメインでの必要性のために特に設けた新しいＡＴコマンドの導入について説明する。
【００７４】
３ＧＰＰリリース８のＱｏＳプロファイルのパラメータは、３ＧＰＰリリース７のＱｏＳプロファイルのパラメータとは異なるため、ＬＴＥの要求ＱｏＳプロファイル、最小ＱｏＳプロファイル及び合意ＱｏＳプロファイルのための新しいＡＴコマンドを導入できる。基本的には、既存のコマンド・セットに、これら新しいＡＴコマンドを導入するための２つの方法が存在する。
【００７５】
第１のオプションは、対応する３ＧＰＰリリース７のＱｏＳプロファイルのＡＴコマンドを、新しいＡＴコマンドと取り替えることである。言い換えると、新しいコマンドが、ＬＴＥという単一のＲＡＴをサポートするＵＥと、例えば、ＬＴＥネットワーク・アクセス及びＷＣＤＭＡネットワーク・アクセスといった、複数のＲＡＴをサポートするＵＥの両方のための古いコマンドを取り替える。よって、複数のＲＡＴをサポートするＵＥは、ＷＣＤＭＡが利用しているＲＡＴである場合、要求された３ＧＰＰリリース８のＱｏＳプロファイルを、３ＧＰＰリリース７のＱｏＳプロファイルに変換する変換ロジックを提供しなければならない。
【００７６】
第２のオプションは、新しいＡＴコマンドと既存のＡＴコマンドを共存させることである。アプリケーションが、既存のＡＴコマンドによりＱｏＳプロファイルを定義又は要求する場合、ＵＥは、ＬＴＥが利用しているＲＡＴである場合、３ＧＰＰリリース７のＱｏＳプロファイルを、３ＧＰＰリリース８のＱｏＳプロファイルに変換する変換ロジックを必要とする。ＷＣＤＭＡ又は他のレガシーＵＭＴＳ（例えば、ＷＣＤＭＡ、ＧＰＲＳ及びＥＤＧＥを含む）が利用しているＲＡＴであり、アプリケーションが新しく導入したＡＴコマンドでＱｏＳプロファイルを定義又は要求する場合、変換は逆方向に対しても行わなければならない。アプリケーションが、新しく導入したＡＴコマンド及び従来のＡＴコマンドによる２つのＱｏＳプロファイルのバージョンを定義又は要求する場合、ＵＥは、レガシーＵＭＴＳ（例えば、ＧＰＲＳ及びＥＤＧＥを含む）ネットワーク・アクセスのためには、従来のＡＴコマンドのパラメータを使用し、ＬＴＥネットワーク・アクセスのためには、新たに定義したＡＴコマンドのパラメータを使用できる。
【００７７】
現在のＡＴコマンド・セットは、特定のＬＴＥサービスには有用である、ＳＤＦのパケット・フィルタの除去をサポートしていない。新しい機能の導入については、基本的に、以下の可能性がある。第一の可能性は、ＡＴコマンド＋ＣＧＴＦＴを拡張する。例えば、ＡＴコマンド＋ＣＧＴＦＴの特定の拡張は、コマンドで特定される１つ以上のパケット・フィルタが、同じくコマンドで特定される特定のＳＤＦ（例えば、関連するＣＩＤパラメータにより）から除去する様に定義できる。更なるオプションによると、パケット・フィルタ除去のための新しいＡＴコマンドが導入される。このコマンドは、除去される１つ以上のパケット・フィルタを識別するためのパラメータと、コマンドを適用する特定のＳＤＦを識別するためのパラメータ（例えば、ＣＩＤパラメータ）を含んでいる。
【００７８】
上述した実施形態から明らかな様に、開示した技術は、種々の有利な効果を有している。例えば、本技術は、利用しているＲＡＴ（ＧＰＲＳ、ＥＤＧＥ、ＷＣＤＭＡ、ｅＨＳＰＡ及びＬＴＥの様な）とは無関係であるＩＰベアラ及び接続の管理及び配分のためのアプリケーションに共通のインタフェースを提供することを可能にする。結果、ＥＰＳパケット・ドメインのサービスが、既存のアプリケーション及びユーザ・インタフェースに対して、改造することなく提供することができる。特に、ＧＰＲＳパケット・ドメインに準拠するアプリケーションについては、改造することなくＥＰＳパケット・ドメインのサービスに利用することができる。
【００７９】
開示した本技術の多くの利点は、以上の記載から理解され、本発明の範囲から逸脱することなく、また、その利点を犠牲にすることなく、例示的な実施形態の形式、構造及び配置について種々の変更が可能であることは明らかである。開示の技術は、多くの方法で変更でき、本発明は、以下の特許請求の範囲の範囲のみにより制限されることを認識すべきである。
【図１】
0005349600.tif 000002
【図２】
0005349600.tif 000003
【図３】
0005349600.tif 000004
【図４】
0005349600.tif 000005
【図５】
0005349600.tif 000006
【図６】
0005349600.tif 000007