(57)【特許請求の範囲】
【請求項１】
汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（ＧＴＰ）メッセージを作成するためにコアネットワークノード（２００、３００、４００、５００）において実行される方法であって、前記ＧＴＰメッセージが、ＧＴＰヘッダと、その後に続く、事前規定された情報要素（ＩＥ）タイプのセット内の特別なＩＥタイプに関連付けられた少なくとも１つのＩＥとを含み、前記ＩＥが複数のフィールドを含み、前記特別なＩＥタイプが、前記ＩＥの第１のオクテット内の事前規定されたＩＥタイプフィールド内で符号化された値によって識別される、方法において、
前記特別なＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするように、前記ＩＥの第４および第５のオクテット、または前記ＩＥの第５および第６のオクテットにおいてＩＥタイプ拡張フィールドを予約すること（１１１０）と、
前記事前規定されたＩＥタイプのセットに加えて、少なくとも１つの新規のＩＥタイプを規定するように予約済みのＩＥタイプ拡張フィールドを設定すること（１１２０）と
を含む、方法。
【請求項２】
前記ＧＴＰメッセージを送信すること（１１３０）をさらに含む、請求項１に記載の方法。
【請求項３】
前記事前規定された特別なＩＥタイプが、将来使用するように予約された予備のＩＥタイプである、請求項１または２に記載の方法。
【請求項４】
前記事前規定された特別なＩＥタイプが、プライベート拡張ＩＥタイプである、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記コアネットワークノードが、サービングゲートウェイ（ＳＧＷ）（２００）、ＰＤＮゲートウェイ（ＰＧＷ）（３００）、移動管理エンティティ（ＭＭＥ）（４００）、またはポリシーおよび課金ルール機能（ＰＣＲＦ）（５００）のうちのいずれか１つである、請求項１から４のいずれか一項に記載の方法。
【請求項６】
汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（ＧＴＰ）メッセージを動作可能に生成するように設定されたコアネットワークノード（２００、３００、４００、５００）であって、前記ＧＴＰメッセージが、ＧＴＰヘッダと、その後に続く、事前規定されたＩＥタイプのセット内の特別なＩＥタイプに関連付けられた少なくとも１つの情報要素（ＩＥ）とを含み、前記ＩＥが複数のフィールドを含み、前記特別なＩＥタイプが、前記ＩＥの第１のオクテット内の事前規定されたＩＥタイプフィールド内で符号化された値によって識別され、前記コアネットワークノード（２００、３００、４００、５００）が、
命令を含むメモリ（９２０）と、
前記特別なＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするように、前記ＩＥの第４および第５のオクテット、または前記ＩＥの第５および第６のオクテットにおいてＩＥタイプ拡張フィールドを予約し、
前記事前規定されたＩＥタイプのセットに加えて、少なくとも１つの新規のＩＥタイプを規定するように予約済みのＩＥタイプ拡張フィールドを設定する
ための命令を動作可能に実行するように設定されたプロセッサ（９１０）と
を含む、コアネットワークノード（２００、３００、４００、５００）。
【請求項７】
前記ＧＴＰメッセージを動作可能に送信するように設定される、請求項６に記載のコアネットワークノード。
【請求項８】
前記事前規定された特別なＩＥタイプが、将来使用するように予約された予備のＩＥタイプである、請求項６または７に記載のコアネットワークノード。
【請求項９】
前記事前規定された特別なＩＥタイプが、プライベート拡張ＩＥタイプである、請求項６または７に記載のコアネットワークノード。
【請求項１０】
サービングゲートウェイ（ＳＧＷ）（２００）、ＰＤＮゲートウェイ（ＰＧＷ）（３００）、移動管理エンティティ（ＭＭＥ）（４００）、またはポリシーおよび課金ルール機能（ＰＣＲＦ）（５００）のうちのいずれか１つである、請求項６から９のいずれか一項に記載のコアネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（ＧＴＰ）メッセージを作成および送信するための方法およびコアネットワークノードに関する。このＧＴＰメッセージは、ＧＴＰヘッダと、その後に続く少なくとも１つの情報要素（ＩＥ）を含み、このＩＥは複数のフィールドを含む。
【背景技術】
【０００２】
汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（ＧＴＰ）は、各ノード間にＧＴＰトンネルをセットアップして、トラフィックを様々な通信フローに分離するために使用される、よく知られたプロトコルである。
【０００３】
よく知られているように、ＧＴＰバージョン１（ＧＴＰｖ１）では、ＧＴＰトンネルは、たとえば、公衆陸上移動網（ＰＬＭＮ）内のサービングＧＰＲＳサポートノード（ＳＧＳＮ）やゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）など、ＧＰＲＳサポートノード（ＧＳＮ）間のＧｎインターフェース上、および様々なＰＬＭＮ内のＧＳＮ間のＧｐインターフェース上にセットアップされる。
【０００４】
２Ｇおよび３Ｇのモバイルネットワークで使用されるＧＴＰｖ１を修正および強化し、Ｌｏｎｇ−Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）システムでのエボルブドパケットコア（ＥＰＣ）ネットワークで使用するためのエボルブドＧＴＰ（ｅＧＴＰ）と一般に呼ばれるＧＴＰバージョン２（ＧＴＰｖ２）では、サービングゲートウェイ（ＳＧＷ）とパケットデータネットワークゲートウェイ（ＰＧＷ）の間のＳ５／Ｓ８インターフェース、移動管理エンティティ（ＭＭＥ）とＳＧＷの間のＳ１１インターフェース、エボルブドパケットデータゲートウェイ（ｅＰＤＧ）とＰＧＷの間のＳ２ｂインターフェースなど、様々なインターフェースの間にＧＴＰトンネルがセットアップされる。
【０００５】
ＧＴＰメッセージは、ヘッダと、その後に続くゼロ以上の情報要素（ＩＥ）からなる。このヘッダは、たとえば、ＧＴＰのバージョン、メッセージの全長、およびトンネル終端点識別子を規定する。ＧＴＰｖ２では、２５６個の異なるＩＥタイプが存在し、それぞれのＩＥタイプは、０〜２５５のＩＥタイプ値によって識別される。
【０００６】
このＩＥタイプ値は、たとえば、携帯機器識別番号（ＭＥＩ）の値７５、ユーザ位置情報（ＵＬＩ）の値８６、ベアラコンテキストの値９３、パケットフローＩＤの値１２３などによって例示される非常に様々なメッセージ特性を規定する。これは、たとえば技術仕様書３ＧＰＰ  ＴＳ  ２９．２７４  Ｖ１３．２．０を参照されたい。
【０００７】
最近、ＧＴＰｖ１およびＧＴＰｖ２のプロトコルでの第３世代パートナーシッププロジェクト（３ＧＰＰ）の新機能を実装するために、多数の新規のＩＥタイプが指定され、これにより、予備のＩＥとして残っている新規のＩＥタイプが次第に減少していく（場合によっては、ＧＴＰｖ１では２０タイプ未満であり、おそらくＧＴＰｖ２では５０タイプ未満である）。これによって、将来は、ＧＴＰｖ２プロトコルにおいてより多くの機能を効率的にサポートできなくなる恐れもある。
【発明の概要】
【０００８】
本開示の目的は、前述の通り、当技術分野における１つまたは複数の問題を解決するか、または少なくとも軽減すること、ならびにＧＴＰメッセージでのＩＥの利用率を改善するための方法およびコアネットワークノードを実現することである。
【０００９】
この目的は、コアネットワークノードで実行されて、ＧＴＰメッセージを作成するための方法によって、本開示の第１の態様において実現され、このＧＴＰメッセージは、ＧＴＰヘッダと、その後に続く、事前規定されたＩＥタイプのセット内の特別なＩＥタイプに関連付けられた少なくとも１つのＩＥを含み、このＩＥは、複数のフィールドを含み、ここで、この特別なＩＥタイプが、ＩＥの第１のオクテットでの事前規定されたＩＥタイプフィールドにおいて符号化された値によって識別される。この方法は、特別なＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするように、ＩＥの第４および第５のオクテット、またはＩＥの第５および第６のオクテットにおいてＩＥタイプ拡張フィールドを予約することと、事前規定されたＩＥタイプのセットに加えて、少なくとも１つの新規のＩＥタイプを規定するように予約済みのＩＥタイプ拡張フィールドを設定することとを含む。
【００１０】
この目的は、ＧＴＰメッセージを動作可能に作成するように設定されたコアネットワークノードによって、本開示の第２の態様において実現され、このＧＴＰメッセージは、ＧＴＰヘッダと、その後に続く、事前規定されたＩＥタイプのセット内の特別なＩＥタイプに関連付けられた少なくとも１つのＩＥを含み、このＩＥは、複数のフィールドを含み、ここで、この特別なＩＥタイプが、ＩＥの第１のオクテットでの事前規定されたＩＥタイプフィールドにおいて符号化された値によって識別される。このコアネットワークノードは、命令を有するメモリと、この各命令を動作可能に実行して、特別なＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするように、ＩＥの第４および第５のオクテット、またはＩＥの第５および第６のオクテットにおいてＩＥタイプ拡張フィールドを予約し、事前規定されたＩＥタイプのセットに加えて、少なくとも１つの新規のＩＥタイプを規定するように予約済みのＩＥタイプ拡張フィールドを設定するように設定されたプロセッサとを含む。
【００１１】
したがって、特別なＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするように、各フィールドのうち１つまたは複数を予約することと、事前規定されたＩＥタイプのセットに加えて、少なくとも１つの新規のＩＥタイプを規定するように、予約された１つまたは複数のフィールドを設定することとにより、有利には、さらなるＩＥタイプを規定するための、より多くのバイナリビットを提供することができる。
【００１２】
本明細書に記載の解決策は、各実施形態を例示することに関連して、特許請求の範囲に記載の特徴の実現可能な全ての組合せに関することに留意されたい。添付の特許請求の範囲および以下の説明を検討すれば、この解決策のさらなる特徴およびその利点が明白になろう。この解決策の様々な特徴を組み合わせて、以下に説明する実施形態以外の実施形態を作成できることが当業者には理解できる。
【００１３】
前述の説明は、添付図面に示す例示的な実施形態のより具体的な以下の説明から明白になろう。添付図面においては、様々な図を通して同じ参照文字は同じ部品を指す。
【図面の簡単な説明】
【００１４】
【図１】エボルブドパケットシステム（ＥＰＳ）内の３ＧＰＰアクセス用の例示的なよく知られたＬＴＥアーキテクチャの概略図である。
【図２】よく知られた例示的なＬＴＥアーキテクチャの別の概略図である。
【図３】ＧＴＰｖ１ヘッダの概略図である。
【図４】ＧＴＰｖ１ヘッダと、その後に続く１つまたは複数の後続のＩＥの概略図である。
【図５】ＧＴＰｖ２−Ｃヘッダの概略図である。
【図６】ＥＰＣ固有のＧＴＰｖ２−Ｃヘッダの概略図である。
【図７】ＧＴＰｖ２−Ｃヘッダと、その後に続くゼロ、または１つもしくは複数の後続のＩＥの概略図である。
【図８】例示的なＧＴＰｖ２の情報要素（ＩＥ）のフォーマットの概略図である。
【図９】新規のＩＥタイプ拡張フィールドを有する、例示的なＧＴＰｖ１の情報要素（ＩＥ）タイプの概略図である。
【図１０】新規のＩＥタイプ拡張フィールドを有する、例示的なＧＴＰｖ２の情報要素（ＩＥ）タイプの概略図である。
【図１１】本明細書に記載の例示的な実施形態を概略的に示す、例示的な流れ図である。
【図１２】本明細書に記載の例示的な実施形態の各動作を、動作可能に実行するように設定された例示的な移動管理ユニット２００の概略図である。
【発明を実施するための形態】
【００１５】
以下の説明では、限定するためではなく説明するために、具体的な構成要素、要素、技法などの具体的な詳細を記載して、例示的な実施形態の十分な理解を可能にする。しかし、これらの具体的な詳細から逸脱する他の方式で、例示的な実施形態を実施してもよいことが、当業者には明白になろう。他の例では、例示的な実施形態の説明を曖昧にしないように、よく知られた方法および要素の詳細な説明を省く。本明細書において使用される専門用語は、例示的な実施形態を説明するためのものであり、本明細書において提示される実施形態を限定するものではない。
【００１６】
図１には、よく知られた例示的な無線通信システムの概略図が示してある。このシステムは、いわゆるＬＴＥベースのシステムである。「ＬＴＥ」および「ＬＴＥベース」のシステムという用語は、本明細書においては、たとえば高度なＬＴＥシステムなど、現在と将来両方のＬＴＥベースのシステムを含むように使用されることを念押ししなければならない。さらに、図１には、ＬＴＥベースのシステムの形態での無線通信システムが示してあるが、本明細書における例示的な実施形態は、図１のシステムの各ノードおよび機能に対応する各ノードおよび機能を含む他の無線通信システムに関連して利用してもよいことを理解されたい。
【００１７】
図２には、例示的なＬＴＥベースのアーキテクチャの形態での、よく知られた無線通信システムの別の概略図が示してある。図２を見て分かるように、このシステムは、サービングゲートウェイ（ＳＧＷ）に接続され、さらに移動管理エンティティ（ＭＭＥ）およびＰＤＮゲートウェイ（ＰＧＷ）に接続される、ｅＮｏｄｅＢの形態の基地局を備え、このＰＤＮゲートウェイは、ポリシーおよび課金ルール機能（ＰＣＲＦ）に接続される。
【００１８】
このｅＮｏｄｅＢは、無線端末とインターフェースする無線アクセスノードであり、ＬＴＥにおけるユーザ機器（ＵＥ）と表される。実際、システムのｅＮｏｄｅＢは、ＬＴＥ用の無線アクセスネットワークＥ−ＵＴＲＡＮを形成する。
【００１９】
ＳＧＷ２００は、ユーザデータパケットをルーティングおよび転送し、ｅＮＢ間のハンドオーバの際にユーザプレーンでの移動アンカとして、またＬＴＥと他の３ＧＰＰ技術との間の移動性のためのアンカとしての機能も果たす（Ｓ４インターフェースを終了し、２Ｇ／３ＧシステムとＰＤＮ  ＧＷとの間のトラフィックを中継する）。アイドル状態のＵＥでは、ＤＬデータがＵＥに到達すると、ＳＧＷは、ＤＬデータ経路を終了し、ページングをトリガする。これが、ＵＥコンテキスト、たとえばＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報を管理および格納する。これはまた、合法的傍受の場合にはユーザトラフィックの複製を実行する。
【００２０】
ＭＭＥ４００は、ＬＴＥアクセスネットワークにおいて重要な制御ノードである。これは、再伝送を含む、アイドルモードＵＥの追跡およびページングの手順について役割を担う。これは、ベアラ起動／動作停止プロセスに関わっており、初期接続時、およびコアネットワーク（ＣＮ）ノードの再配置を伴うＬＴＥ内ハンドオーバ時に、ＵＥ用のＳＧＷを選択する役割をも担う。これは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ）のシグナリングがＭＭＥにおいて終了し、このＭＭＥは、一時的な識別番号を生成し、それを各ＵＥに割り当てる役割をも担う。これは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ）にキャンプオンするためのＵＥの許可を検査し、ＵＥローミング制限を強制する。ＭＭＥは、ＮＡＳシグナリング用の暗号化／完全性の保護のためのネットワーク内の終端点であり、セキュリティキー管理を処理する。シグナリングの合法的傍受も、ＭＭＥによってサポートされる。ＭＭＥはまた、ＬＴＥと、ＳＧＳＮからＭＭＥで終了するＳ３インターフェースを有する２Ｇ／３Ｇアクセスネットワークとの間の移動性のための制御プレーン機能を提供する。ＭＭＥはまた、ＵＥをローミングするために、ホームＨＳＳへ向かうＳ６ａインターフェースを終端する。
【００２１】
ＰＧＷ３００は、ＵＥのためのトラフィックの出口点および入口点であることにより、外部パケットデータネットワーク２５０をＵＥに接続する。ＵＥは、複数のＰＤＮにアクセスするため、２つ以上のＰＧＷとの同時接続を有してもよい。通常、ＰＧＷは、ポリシー強制、各ユーザ向けのパケットフィルタリング、課金サポート、合法的傍受、およびパケットスクリーニングのうちの１つまたは複数を実行する。ＰＧＷの別の重要な役割は、３ＧＰＰと、ＷｉＭＡＸや３ＧＰＰ２（ＣＤＭＡ  １ＸおよびＥｖＤＯ）などの非３ＧＰＰ技術との間での移動用のアンカの役割を果たすことである。
【００２２】
ＰＣＲＦ５００は、システムの無線端末に対してリアルタイムでポリシールールを決定する。これは、たとえば、システムのコアネットワークおよび運用支援システムなどとの間の情報をリアルタイムにアグリゲートして、ルールの作成を支援すること、および／またはこのようなルールもしくは類似のものに基づいて、システム内で現在稼働中のユーザ無線端末のポリシー決定を自動的におこなうことを含んでもよい。ＰＣＲＦは、ポリシーおよび課金施行機能（ＰＣＥＦ）として働くことによって使用されるルールおよび／またはポリシーもしくは同様のものをＰＧＷに提供する。
【００２３】
ＳＧＷ、ＭＭＥ、ＰＧＷ、およびＰＣＲＦは全て、コアネットワークノードの例であり、ｅＮｏｄｅＢは、無線アクセスネットワーク（ＲＡＮ）ノードの例である。コアネットワークノードは、ＧＴＰメッセージによって互いに通信する。
【００２４】
背景技術の段落で既に示したように、ＧＴＰｖ１およびＧＴＰｖ２を使用して、コアネットワーク内のコアネットワークノード間でＧＴＰトンネルをセットアップし、様々なＧＴＰメッセージを通信することがよく知られている。一般に、ＧＴＰメッセージは、ヘッダと、その後に続くゼロ個以上の情報要素（ＩＥ）からなる。
【００２５】
以下に、ＧＴＰｖ１メッセージ内のＧＴＰｖ１ヘッダおよびＧＴＰｖ１  ＩＥ、ならびにＧＴＰｖ２メッセージ内のＧＴＰｖ２ヘッダおよびＧＴＰｖ２  ＩＥを多少詳しく説明する。
【００２６】
ＧＴＰｖ１ヘッダ
ＧＴＰｖ１メッセージ内のＧＴＰｖ１ヘッダは、ＧＴＰ−ＣプロトコルとＧＴＰ−Ｕプロトコル、すなわちＧＴＰ制御プレーンプロトコルとＧＴＰユーザプレーンプロトコルの両方に使用される、可変長ヘッダである。
【００２７】
図３を見て分かるように、ＧＴＰｖ１ヘッダには、追加の任意選択フィールドの存在を通知するのに使用される３つのフラグ、すなわちＰＮフラグ、Ｓフラグ、およびＥフラグがある。ＰＮフラグを使用して、Ｎ−ＰＤＵ番号の存在を通知する。Ｓフラグを使用して、ＧＴＰシーケンス番号フィールドの存在を通知する。Ｅフラグを使用して、拡張ヘッダフィールドの存在を通知する。このフィールドを使用して、ＧＴＰヘッダの将来の拡張を可能にする。これら３つのフラグが設定される場合に限り、フィールドシーケンス番号、Ｎ−ＰＤＵ、および拡張ヘッダが存在することになる。よく知られた方式では、ＧＴＰｖ１ヘッダ内に存在する、いくつかのトンネル終端点識別子（ＴＥＩＤ）もある。
【００２８】
ＧＴＰ−Ｃ（制御プレーン）およびＧＴＰ−Ｕ（ユーザプレーン）は、ＧＴＰヘッダ内のフィールドのいくつかを別々に使用する。
【００２９】
ＧＴＰｖ１−Ｃヘッダおよび情報要素（ＩＥ）
図４を見て分かるように、制御プレーンメッセージのタイプに応じて、ＧＴＰ−Ｃヘッダの後に、１つまたは複数の後続のＩＥが続く場合がある。それぞれのタイプがいくつか存在していてもよい、認証３ビットバイト、ＰＤＰコンテキスト、トンネル終端点識別子データＩＩ、ＮＳＡＰＩ、ＰＳハンドオーバＸＩＤパラメータ、パケットフローＩＤ、ＲＦＳＰインデックス、ＰＤＵ番号、エボルブドアロケーション／リテンション優先順位ＩＩ、ＮＳＡＰＩ付きのＡＰＮ−ＡＭＢＲ、ＮＳＡＰＩ付きのシグナリング優先順位指示、ＮＳＡＰＩ付きのローカルホームネットワークＩＤ（ＬＨＮ−ＩＤ）、課金特性、およびＦＱＤＮ情報要素を除いて、単一のＧＴＰｖ１−Ｃメッセージには、それぞれのタイプで１つのＩＥしか許可されない。
【００３０】
ＧＴＰｖ１情報要素（ＩＥ）
ＧＴＰ（シグナリング）メッセージは、いくつかのＩＥを含んでもよい。ＩＥは、ＧＴＰシグナリングメッセージにおいて、タイプフィールドが昇順にソーティングされることが好ましい。ＩＥ内では、ある特定のフィールドを予備として記述してもよい。将来の機能を可能にするため、受信機はこれらのビットを評価してはならない。しかし、この解決策の実施形態によれば、こうしたいくつかのフィールドを使用してもよい。
【００３１】
以下の表には、現在利用可能なＧＴＰｖ１情報要素（ＩＥ）が示してある。この表では、長さタイプは、固定、可変、または拡張可能でもよい。これらは、以下の通りに規定される。
−  長さタイプが固定の情報要素は、固定セットのフィールドおよび固定数のオクテットを有する。これらは、たとえば「４」の固定値を有する、最後のオクテットの番号を有する。
−  長さタイプが可変の情報要素は、固定セットのフィールドおよび可変数のオクテットを有する。これらは、たとえば「ｎ」の可変値を有する、最後のオクテットの番号を有する。可変長の情報要素は、最後の可変オクテットを超えて、いかなる新規のオクテットフィールドも追加してはならない。
−  長さタイプが拡張可能な情報要素は、可変数のフィールドおよび可変数のオクテットを有する。これらは、たとえば「ｎ」の可変値を有する、最後のオクテットの番号を有し、以下の記述も有する。「これら（１つまたは複数）のオクテットは、明示的に指定された場合にのみ存在する」。
【００３２】
ＴＶフォーマットの情報要素は、常に、長さタイプが固定でなければならない。ＴＬＶフォーマットの情報要素は、長さタイプが固定、可変、または拡張可能でもよい。
表１
0006507313.tif 000002
0006507313.tif 000003
0006507313.tif 000004
0006507313.tif 000005
0006507313.tif 000006
【００３３】
ＴＶおよびＴＬＶタイプのフィールドでの最大有効ビットは、ＩＥ向けにＴＶフォーマットが使用される場合は０に設定され、ＴＬＶフォーマットの場合は１に設定される。
表２
0006507313.tif 000007
【００３４】
制御プレーンでのＧＴＰｖ２ヘッダ
図５には、ＧＴＰｖ２−Ｃメッセージでの制御プレーンＧＴＰｖ２ヘッダ（ＧＴＰｖ２−Ｃヘッダ）の一般的なフォーマットが示してある。ＧＴＰｖ２−Ｃは、可変長のヘッダを使用する。制御プレーンＧＴＰヘッダ長は、４オクテットの倍数とする。ＥＰＣ固有のインターフェース全体にわたるＧＴＰｖ２−Ｃヘッダの使用法が、３ＧＰＰ  ＴＳ  ２９２７４の５．５項「Ｕｓａｇｅ  ｏｆ  ｔｈｅ  ＧＴＰｖ２−Ｃ  Ｈｅａｄｅｒ］に規定されている。
【００３５】
ＧＴＰｖ２−Ｃヘッダにおいては、
−  Ｔ＝０の場合、ＴＥＩＤフィールドが存在せず、ｋ＝０、ｍ＝０、およびｎ＝５である。
−  Ｔ＝１の場合、ＴＥＩＤフィールドは存在し、ｋ＝１、ｍ＝５、およびｎ＝９である。
【００３６】
オクテット１の各ビットは、以下のように符号化されるものとする。
−  ビット６〜８は、バージョンフィールドを表す。
−  ビット５は、ピギーバッキングフラグ（Ｐ）を表す。
−  ビット４は、ＴＥＩＤフラグ（Ｔ）を表す。
−  ビット３〜１は予備であり、送信側がこれを「０」に設定し、受信側がこれを無視するものとする。
【００３７】
図６には、ＥＰＣ固有のＧＴＰ−Ｃヘッダの概略図が示してある。エコー要求、エコー応答、およびバージョン非サポート指示メッセージは別にして、ＧＴＰ−Ｃメッセージヘッダが、ＴＥＩＤおよびシーケンス番号のフィールドと、その後に続く１つの予備オクテットを含むものとする。予備ビットは、送信側でゼロに設定され、受信側で無視されるものとする。
【００３８】
図７には、制御プレーンメッセージのタイプに応じて、ＧＴＰｖ２−Ｃヘッダと、その後に続くゼロ、または１つもしくは複数の後続のＩＥの概略図が示してある。
【００３９】
ＧＴＰｖ２−Ｃ情報要素（ＩＥ）
ＧＴＰｖ２制御プレーン（シグナリング）メッセージは、いくつかのＩＥを含むことがある。ＧＴＰｖ２のＩＥに対して前方互換性のあるタイプ規定を有するように、この全てが、ＴＬＩＶ（タイプ、長さ、インスタンス、値）符号化されるものとする。
【００４０】
以下の表には、現在利用可能なＧＴＰｖ２情報要素（ＩＥ）が示してある。この表の最後の列は、情報要素が以下の通りかどうか示す。
−  固定長：ＩＥは、固定セットのフィールドおよび固定数のオクテットを有する。
−  可変長：ＩＥは、固定セットのフィールドおよび可変数のオクテットを有する。たとえば、最後のオクテットは、「５〜（ｎ＋４）」と同様に番号付けしてもよい。この例では、長さフィールドの値ｎが０の場合、最後のフィールドは存在しない。
−  拡張可能：ＩＥは、可変数のフィールドおよび可変数のオクテットを有する。最後のフィールドは通常、以下の記述で指定される。「これら（１つまたは複数）のオクテットは、明示的に指定された場合にのみ存在する」。従来型の受信側は、未知のオクテットを無視するものとする。
表３
0006507313.tif 000008
0006507313.tif 000009
0006507313.tif 000010
0006507313.tif 000011
【００４１】
図８には、例示的なＧＴＰｖ２の情報要素（ＩＥ）のフォーマットが示してある。通常、ＩＥは以下のフィールドを有する。
−  タイプフィールド：このフィールドは情報要素のタイプを示す。現在利用可能なＧＴＰｖ２−ＣのＩＥタイプの有効な値は、上記の表において規定される。
−  長さ：このフィールドは、第１の４つのオクテットを除く情報要素の長さを含み、これらのオクテットは、全ての情報要素（タイプ、長さ、およびオクテット４の内容）に共通であり、図８．２−１に「ｎ」で表してある。全ての長さフィールドにおいて、最小番号のオクテットのビット８が最大有効ビットであり、最大番号のオクテットのビット１が最小有効ビットである。
−  ＩＥはまた、インスタンスフィールドを有してもよい：このフィールドは、同じ情報要素タイプを使用する、ある特定のメッセージ内の様々なパラメータを区別するのに使用されるものとする。
【００４２】
通常ＩＥは、符号化されたＴＬＩＶ（タイプ、長さ、インスタンス、値）である。
【００４３】
ＧＴＰｖ１  ＩＥタイプ拡張フィールド
背景技術の段落で既に示したように、３ＧＰＰで新規に導入された機能に対応するために、ＧＴＰｖ１において非常に多くの新規のＩＥタイプが作成される。新規の機能に新規のＩＥタイプを導入するとき、予備のＩＥタイプ（たとえば、ＧＴＰｖ１  ＩＥタイプの上記表でのＩＥタイプ２１７〜２３８参照）を使用することが望ましいが、その理由は、これにより、通常、より完全なプロトコル仕様書、およびより良好な後方互換性のある手法が実現できるからである。たとえば、新規のＩＥタイプは、従来型の受信機によって安全に破棄することができる。しかし、これによって、予備として残っている新規のＩＥタイプが次第に少なくなっていく。したがって、予備のＩＥタイプの数が減少すると、ＧＴＰｖ１プロトコルでのより多くの機能の効率的なサポートが危うくなる場合もあり、これは深刻な欠点である。
【００４４】
したがって、３ＧＰＰで新規に導入される機能に対応するためには、予備のＩＥタイプが不足していることを考慮すれば、ＧＴＰｖ１プロトコルでより多くの機能を効率的にサポートすることが危うくなる場合があり、好ましくは後方互換性のある方式で既存のＩＥタイプの範囲を拡張するメカニズムが望まれる。
【００４５】
図９には、ＩＥタイプの範囲が拡張された新規のＩＥタイプ拡張フィールドを有する、例示的なＧＴＰｖ１  ＩＥタイプの概略図が示してある。新規のＩＥタイプは、ＩＥの第１の（１ｓｔ）オクテットにおける既存の事前規定されたＩＥタイプフィールド内に符号化された値と、これに加えてＩＥタイプ拡張フィールド内に符号化された追加の新規値とによって識別される。この例では、特別なＩＥタイプ、すなわちＧＴＰｖ１  ＩＥタイプの上記表での予備のＩＥタイプ２１７〜２３８のうちの１つとして、既存の事前規定されたＧＴＰｖ１  ＩＥタイプ２３８が選択される。しかし、上記のＧＴＰｖ１  ＩＥタイプの上記表での任意の適切な既存の事前規定されたＩＥタイプ、たとえば、予備のＩＥタイプ２１７〜２３７のうちの他の任意のタイプなどを使用してもよい。新規のＩＥタイプは、一般に知られているように、ＩＥの第１の（１ｓｔ）オクテットにおいて符号化された既存の事前規定されたＩＥタイプによって規定されるが、ここでは、予約されたＩＥタイプ拡張フィールド、好ましくはＩＥのオクテット４および５において設定される追加の値とともに規定される。特別なＩＥタイプ２３８は、ＧＴＰｖ１  ＩＥタイプの上記表でのＩＥタイプ２３８「将来の使用のための予備」に対応する。前述の通り、既存の事前規定された予備のＩＥタイプ（たとえば、ＩＥタイプ２３８）を使用することによって、ソリューションは後方互換性を有するようになるが、その理由は、このような新規のＩＥタイプは、従来型の受信機によって安全に破棄できるからである。しかし、予備のＩＥタイプ以外のＩＥタイプを使用してもよいが、このような実施形態は後方互換性がなくてもよいことを付け加えなければならない。
【００４６】
ＧＴＰｖ２  ＩＥタイプ拡張フィールド
背景技術の段落で既に示したように、３ＧＰＰで新規に導入された機能に対応するために、ＧＴＰｖ２において非常に多くの新規のＩＥタイプが作成される。新規の機能に新規のＩＥタイプを導入するとき、予備のＩＥタイプ（たとえば、ＧＴＰｖ２  ＩＥタイプの上記表でのＩＥタイプ１８７〜２５４参照）を使用することが望ましいが、その理由は、これにより、通常、より完全なプロトコル仕様書、およびより良好な後方互換性のある手法が実現できるからである。たとえば、新規のＩＥタイプは、従来型の受信機によって安全に破棄することができる。しかし、これによって、予備として残っている新規のＩＥタイプが次第に少なくなっていく。したがって、予備のＩＥタイプの数が減少すると、ＧＴＰｖ１プロトコルでのより多くの機能の効率的なサポートが危うくなる場合もあり、これは深刻な欠点である。
【００４７】
したがって、３ＧＰＰで新規に導入される機能に対応するためには、予備のＩＥタイプが不足していることを考慮すれば、ＧＴＰｖ２プロトコルでより多くの機能を効率的にサポートすることが危うくなる場合があり、好ましくは後方互換性のある方式で既存のＩＥタイプの範囲を拡張するメカニズムが望まれる。
【００４８】
図１０には、ＩＥタイプの範囲が拡張された新規のＩＥタイプ拡張フィールドを有する、例示的なＧＴＰｖ２  ＩＥタイプの概略図が示してある。新規のＩＥタイプは、ＩＥの第１の（１ｓｔ）オクテットにおける既存の事前規定されたＩＥタイプフィールド内に符号化された値と、これに加えてＩＥタイプ拡張フィールド内に符号化された追加の新規値とによって識別される。この例では、特別なＩＥタイプ、すなわちＧＴＰｖ２  ＩＥタイプの上記表での予備のＩＥタイプ１８７〜２５４のうちの１つとして、既存の事前規定されたＧＴＰｖ２  ＩＥタイプ２５４が選択される。しかし、上記のＧＴＰｖ２  ＩＥタイプの上記表での任意の適切な既存の事前規定されたＩＥタイプ、たとえば、予備のＩＥタイプ１８７〜２５３のうちの他の任意のタイプなどを使用してもよい。新規のＩＥタイプは、一般に知られているように、ＩＥの第１の（１ｓｔ）オクテットにおいて符号化された既存の事前規定されたＩＥタイプによって規定されるが、ここでは、予約されたＩＲタイプ拡張フィールド、好ましくはＩＥのオクテット５および６において設定される追加の値とともに規定される。特別なＩＥタイプ２５４は、ＧＴＰｖ２  ＩＥタイプの上記表でのＩＥタイプ２５４「将来の使用のための予備」に対応する。前述の通り、既存の事前規定された予備のＩＥタイプ（たとえば、ＩＥタイプ２５４）を使用することによって、ソリューションは後方互換性を有するようになるが、その理由は、このような新規のＩＥタイプは、従来型の受信機によって安全に破棄できるからである。しかし、予備のＩＥタイプ以外のＩＥタイプを使用してもよいが、このような実施形態は後方互換性がなくてもよいことを付け加えなければならない。
【００４９】
図１１には、本明細書に記載の例示的な実施形態を概略的に示す、例示的な流れ図が示してある。
【００５０】
図１１には、コアネットワークノード（２００、３００、４００、５００）がＧＴＰメッセージを作成する方法が示してある。ＧＴＰメッセージは、ＧＴＰヘッダと、その後に続く、事前規定されたＩＥタイプのセット内の特別なＩＥタイプに関連付けられた少なくとも１つのＩＥとを含む。ＩＥは複数のフィールドを含み、ここで、特別なＩＥタイプは、ＩＥの第１のオクテットでの既存の事前規定されたＩＥタイプフィールドにおいて符号化された値によって識別され、この方法は以下の動作を含んでいる。
【００５１】
特別な事前規定されたＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするように、ＩＥの第４および第５のオクテット、またはＩＥの第５および第６のオクテットにおいてＩＥタイプ拡張フィールドが予約される、第１の動作１１１０。および、
【００５２】
事前規定されたＩＥタイプのセットに加えて、少なくとも１つの新規のＩＥタイプを規定するように予約済みのＩＥタイプ拡張フィールドが設定される、第２の動作１１２０。
【００５３】
ＧＴＯメッセージが、たとえば、コアネットワーク内の別のコアネットワークノード送信される、第３の動作１１３０。この動作は、任意選択でもよい。
【００５４】
図１２には、本明細書に記載の例示的な実施形態の各動作を、動作可能に実行するように設定された例示的なコアネットワークノードが示してある。図９に示すように、コアネットワークノードは、プロセッサ装置９１０およびメモリ装置９２０を備えてもよい。このプロセッサ装置は、他のコアネットワークノードおよびユニットと動作可能に通信して、たとえば、図２に示すように、メモリ装置に記憶された命令を動作可能に実行するように設定されることが好ましい。このメモリ装置は、前記プロセッサ装置によって実行可能な命令を含んでおり、したがって本明細書に記載の例示的な実施形態の動作を実行するように例示的なネットワークノードが設定される。プロセッサ装置９１０は、本明細書に記載の例示的な実施形態の動作および機能を実行するように、メモリ装置に記憶された命令を実行できるようにする、任意の適切なデジタルおよびアナログの回路を備えてもよい。プロセッサ装置９１０およびメモリ装置９２０のデジタルおよびアナログの回路は、たとえば、ＳＧＷ、ＰＧＷ、ＭＭＥ、またはＰＣＲＦなどの既知のコアネットワークノードでのものと同じまたは類似のものでもよいが、各命令は、本明細書に記載の実施形態に固有のものである。
【００５５】
上で開示した例示的な実施形態のいくつかは、以下のように要約することができる。
【００５６】
第１の例示的な実施形態は、ＧＴＰメッセージを作成するためにコアネットワークノードにおいて実行される方法を対象としており、このＧＴＰメッセージは、ＧＴＰヘッダと、その後に続く、事前規定されたＩＥタイプのセット内の特別なＩＥタイプに関連付けられた少なくとも１つのＩＥとを含み、このＩＥは複数のフィールドを含み、ここで特別なＩＥタイプは、ＩＥの第１のオクテット内の事前規定されたＩＥタイプフィールド内で符号化された値によって識別され、この方法は、特別なＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするように、ＩＥの第４および第５のオクテット、またはＩＥの第５および第６のオクテットにおいてＩＥタイプ拡張フィールドを予約することと、事前規定されたＩＥタイプのセットに加えて、少なくとも１つの新規のＩＥタイプを規定するように予約済みのＩＥタイプ拡張フィールドを設定することとを含む。
【００５７】
この方法はさらに、ＧＴＰメッセージを送信することを含む。
【００５８】
事前規定された特別なＩＥタイプは、将来使用するように予約された予備のＩＥタイプでもよい。
【００５９】
事前規定された特別なＩＥタイプは、プライベート拡張ＩＥタイプでもよい。
【００６０】
コアネットワークノードは、ＳＧＷまたはＰＧＷまたはＭＭＥまたはＰＣＲＦのうちいずれか１つでもよい。
【００６１】
別の例示的な実施形態は、ＧＴＰメッセージを動作可能に生成するように設定されたコアネットワークノードを対象としており、このＧＴＰメッセージは、ＧＴＰヘッダと、その後に続く、事前規定されたＩＥタイプのセット内の特別なＩＥタイプに関連付けられた少なくとも１つの情報要素（ＩＥ）とを含み、このＩＥは複数のフィールドを含み、ここで、特別なＩＥタイプは、ＩＥの第１のオクテット内の事前規定されたＩＥタイプフィールド内で符号化された値によって識別され、ここで、このコアネットワークノードは、命令を含む持続的なメモリと、特別なＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするように、ＩＥの第４および第５のオクテット、またはＩＥの第５および第６のオクテットにおいてＩＥタイプ拡張フィールドを予約し、事前規定されたＩＥタイプのセットに加えて、少なくとも１つの新規のＩＥタイプを規定するように予約済みのＩＥタイプ拡張フィールドを設定するための命令を動作可能に実行するように設定されたプロセッサとを含む。
【００６２】
コアネットワークノードは、ＧＴＰメッセージを動作可能に送信するように設定してもよい。
【００６３】
事前規定された特別なＩＥタイプは、将来使用するように予約された予備のＩＥタイプでもよい。
【００６４】
事前規定された特別なＩＥタイプは、プライベート拡張ＩＥタイプでもよい。
【００６５】
コアネットワークノードは、ＳＧＷまたはＰＧＷまたはＭＭＥまたはＰＣＲＦのうちいずれか１つでもよい。
【００６６】
予備のＩＥタイプと予約済みのプライベート拡張ＩＥタイプ（および、他のほとんどの事前規定されたＩＥも同様）との間の違いは、送信者が予約済みのＩＥタイプを使用している場合は、従来型の受信機がエラー処理をトリガするが、ＩＥタイプが分からない場合には、予備のＩＥタイプを通知することなく破棄することである。
【００６７】
上記の例示的な実施形態に示すように、新規の予約済みＩＥタイプ拡張フィールドは、ＩＥ内のオクテット４および５、またはオクテット５および６を含んでもよく、各オクテットが、それぞれ８つのバイナリビットを含む。したがって、予約済みフィールドは、２オクテット、すなわち２×８＝１６ビットを含むことができる。これらの１６ビットによって、特別なＩＥタイプの拡張である、２１６＝６５５３６個の新規のＩＥタイプの追加セットの規定が可能になる。
【００６８】
さらに、実施形態によっては、特別なＩＥタイプの拡張である新規のＩＥタイプの追加セットの規定を可能にするための、さらなるフィールドを予約してもよい。たとえば、オクテット７および８は、既に第１のフィールド内に予約されているオクテット５および６に加えて、第２のフィールド内に予約してもよい。ここで、例示的な２つの予約済みフィールドは、ｐ（２ｎ×８）個の新規のＩＥタイプの追加セットの規定を可能にするように互いに加算してもよく、ここで、予約済みフィールドの数はｐ＝２であり、各フィールド内のオクテットの数はｎ＝２である。これにより、２（２２×８））＝２（２１６）＝２×６５５３６＝１３１０７２個の新規のＩＥタイプの追加セットの規定が可能になる。あるいは、例示的な２つの予約済みフィールドを互いに連結して、２ｐｎ８個の新規のＩＥタイプの追加セットの規定を可能にしてもよく、ここで、フィールドの数はｐ＝２であり、各フィールド内のオクテットの数はｎ＝２である。これにより、２（２×２×８）＝２３２＝４２９４９６７２９６個の新規のＩＥタイプの追加セットの規定が可能になる。予約済みのフィールドを互いに加算することは、より容易で、より後方互換性があるように思えるが、予約済みのフィールドを連結した場合のように多くの新規のＩＥタイプを規定することはできない。
【００６９】
ＩＥは、符号化されたタイプ／値（ＴＶ）、または符号化されたタイプ／長さ／値（ＴＬＶ）、または符号化されたタイプ／長さ／インスタンス／値（ＴＬＩＶ）でもよい。
【００７０】
事前規定されたＩＥタイプのセットは、２５６個の事前規定された異なるＩＥタイプのセットを提供する、８バイナリビットの１オクテットを含むタイプフィールド内で規定してもよい。
【図１】
0006507313.tif 000012
【図２】
0006507313.tif 000013
【図３】
0006507313.tif 000014
【図４】
0006507313.tif 000015
【図５】
0006507313.tif 000016
【図６】
0006507313.tif 000017
【図７】
0006507313.tif 000018
【図８】
0006507313.tif 000019
【図９】
0006507313.tif 000020
【図１０】
0006507313.tif 000021
【図１１】
0006507313.tif 000022
【図１２】
0006507313.tif 000023