JP7728459B2 - Ｇｔｐ－ｕエンティティ再開始の向上 - Google Patents

Description

約２０年前に、３ＧＰＰは、ユーザプレーンのための汎用パケット無線サービス（ＧＲＰＳ）トンネリングプロトコル（ＧＴＰ）エコー応答メッセージ（ＧＴＰ－Ｕ）から回復の使用を除去することを判断し、その回復は、ＧＴＰエンティティのための再開始（ｒｅｓｔａｒｔ）カウンタとして規定される。当時、ＧＴＰエンティティは、制御プレーン（ＣＰ）部分とユーザプレーン（ＵＰ）部分とを備えるので、制御プレーンシグナリング経路とユーザプレーンペイロード経路の両方を介してＧＴＰエンティティのための再開始カウンタを通信することが、冗長である。

ＧＴＰ－Ｕメッセージ中の「回復」情報エレメント中の「再開始カウンタ」フィールドの使用が、３ＧＰＰ ＴＳ２９．０６０ Ｒｅｌ－３ ＣＲ０９６を通して２０００年３月に変更され、これは、３ＧＰＰ ＴＳ２９．０６０ Ｖ３．４．０上に書かれており、３ＧＰＰ ＴＳ２９．０６０ Ｖ３．５．０において実装された。ＣＲ（３ＧＰＰ ＴＳ２９．０６０ Ｒｅｌ－３ ＣＲ ０９６）における「変更の理由」は、以下のように読める。「ノードが再開始を経験したことをピアノードに知らせるために、エコー応答メッセージ中の再開始カウンタが使用される。ＧＴＰ－ＵとＧＴＰ－Ｃの両方において再開始カウンタ値を使用することは、ＧＴＰ－Ｃのみにおいて再開始カウンタ値を使用することが十分であるので、不要である。その上、Ｉｕインターフェースにおいて、ＲＡＮＡＰが、ノード再開始のためのプロシージャをすでに有する。したがって、エコー応答メッセージ中の再開始カウンタ値がＧＴＰ－Ｕにおいて使用されないことが提案される。ＣＲはまた、エコー応答が受信されたときにどのように反応すべきかのいくつかの明確化を提案する。」

３ＧＰＰ Ｒｅｌ－８の前に、ＧＴＰ－Ｕの規範的仕様が、３ＧＰＰ ＴＳ２９．０６０中にＧＴＰｖ１とともに含まれた。３ＧＰＰ Ｒｅｌ－８において、ＧＴＰ－Ｕの規範的仕様は、３ＧＰＰ ＴＳ２９．０６０から３ＧＰＰ ＴＳ２９．２８１に移動された。ＧＴＰ－Ｕに関するテキストは、事実上、３ＧＰＰ ＴＳ２９．０６０に「記載のもの」のままにされ、仕様中の節９の始めに注が追加された。注は、以下のように読める。「リリース８以降から、ＧＴＰバージョン１のユーザプレーンの規範的仕様は３ＧＰＰ ＴＳ２９．２８１［４１］である。本文書中のＧＴＰｖ１ユーザプレーンに関するすべての箇条が、３ＧＰＰ ＴＳ２９．２８１［４１］によって取って代わられるものとする。」

したがって、ＴＳ２９．２８１において指定されているように、節７．２．２は、以下を述べる。「回復情報エレメント中の再開始カウンタ値は使用されないものとし、すなわち、再開始カウンタ値は、送信側によって０にセットされるものとし、受信側によって無視されるものとする。回復情報エレメントは、バックワードコンパチビリティの理由により必須である。随意のプライベート拡張が、ベンダーまたはオペレータ固有情報を含んでいる。」（強調加筆）。

図１
本開示の図１は、ＴＳ２９．２８１の節７．２．２の表７．２．２－１を含む。

さらに、ＴＳ２９．２８１の節７．７．１１４（「ＵＬＩタイムスタンプ」）は、以下を開示する。「ＵＬＩタイムスタンプＩＥは、図７．７．１１４－１に示されているようにコーディングされる。ＵＬＩタイムスタンプＩＥは、ユーザロケーション情報が収集されたＵＴＣ時間を指示する。オクテット４～７が、ＩＥＴＦ ＲＦＣ５９０５［５５］の節６において規定されている６４ビットタイムスタンプフォーマットの最初の４つのオクテットと同じフォーマットで符号化される。注：エンコーディングは、１９００年１月１日の００：００：００に対する秒単位の時間として規定される。」

図２
本開示の図２は、ＴＳ２９．２８１の節７．７．１１４中の図（「図７．７．１１４－１：ＵＬＩタイムスタンプ」）を含む。

したがって、３ＧＰＰは、ピアＧＴＰ－ｕ再開始に関する要件を指定しないが、ＧＴＰ－Ｕ経路障害のみを指定する。たとえば、第５世代システム（５ＧＳ）についてのＴＳ２３．５２７において述べられているように、以下である。

ＴＳ２３．５２７、節５．４の開始
５．４ ユーザプレーン経路障害時の復旧プロシージャ
節５．２．２において指定されているＧＴＰ－Ｕユーザプレーン経路障害を検出すると、ＵＰＦは、そこに向かう障害が検出された、（１つまたは複数の）リモートＧＴＰ－ＵピアのＩＰアドレスをもつユーザプレーン経路障害報告を含むＰＦＣＰノード報告要求（３ＧＰＰ ＴＳ２９．２４４［４］参照）を送信することによって、ユーザプレーン経路障害をＳＭＦに報告するものとする。ＵＰＦはまた、運用保守システムを介してＧＴＰ－Ｕユーザプレーン経路障害を通知するべきである。

ＳＭＦが、ユーザプレーン経路障害報告をもつＰＦＣＰノード報告要求を受信したとき、ＳＭＦは、以下を行い得る。
－ 障害のある経路に関連するＰＤＵセッションコンテキストを削除すること、または
－ オペレータ設定可能最大経路障害持続時間中、障害のある経路に関連するＰＤＵセッションコンテキストを維持すること。ＳＭＦは、障害のある経路に関連するＰＤＵセッションコンテキストを、この持続時間が満了したときにその経路が依然としてダウンしている場合、削除するものとする。
注１： 過渡的経路障害（たとえば、多くとも数分を超えない経路障害）中、ピアのＩＰアドレスに関連するＰＤＵセッションコンテキストを維持することは、（経路が再び再確立されたときの）エンドユーザサービスの配信を可能にし、これはまた、それらのＰＤＵセッションを復旧するための、ネットワーク中の不要なシグナリングを回避する。
注２： （たとえば、多くとも数分を超える）長い経路障害中、ＰＤＵセッションコンテキストを維持することは、これが、過度のチャージングのような望ましくない効果を暗示することになるので、意図されない。

障害のある経路に関連するＰＤＵセッションコンテキストを削除することを判断したとき、ＳＭＦは、ＵＰＦにおける、影響を及ぼされるＰＦＣＰセッションを修正または削除するものとする。
注３： ＳＭＦは、多数のＰＦＣＰセッションがユーザプレーン経路障害によって影響を及ぼされる場合、ＵＰＦに向かうシグナリング負荷を平滑化するように注意する必要がある。
ＴＳ２３．５２７、節５．４の終了

また、ＥＰＳについてのＴＳ２３．００７において、節２０．３は、以下を開示する。

ＴＳ２３．００７、節２０．３の開始
２０．３ ユーザプレーン経路障害検出およびハンドリング
２０．３．１ 概略
ＧＴＰ－Ｕエンティティが、以下のやり方で、エコー要求／エコー応答メッセージを使用することによる、経路障害の検出をサポートするものとする。経路カウンタが、エコー応答が経路上で受信されるたびにリセットされ、経路上で送信されたエコー要求メッセージについてＴ３応答タイマーが満了したときに増分されるものとする。経路は、カウンタがＮ３要求を超える場合、ダウンしていると見なされるものとする。

経路障害を検出すると、ネットワークノードは、運用保守システムを介して障害を通知するべきであり、以下のいずれかを行い得る。
－ 障害のある経路に関連するベアラコンテキストを削除すること、または
－ オペレータ設定可能最大経路障害持続時間中、障害のある経路に関連するベアラコンテキストを維持すること。ネットワークノードは、この持続時間が満了したときに経路が依然としてダウンしている場合、維持されたリソースを削除するものとする。
ＴＳ２３．００７、節２０．３の終了

ＧＴＰ－Ｕエンティティが、対応するコンテキストなしにＧＴＰ－Ｕパケットを受信したとき、ＧＴＰ－Ｕエンティティは、ＧＴＰエラー指示を送信することになる。ＴＳ２９．２８１の節７．３．１は、以下を開示する。

ＴＳ２９．２８１、節７．３．１の開始
７．３．１ エラー指示
ＧＴＰ－Ｕノードが、ＥＰＳベアラコンテキスト、ＰＤＰコンテキスト、ＰＤＵセッション、ＭＢＭＳベアラコンテキスト、またはＲＡＢが存在しない、Ｇ－ＰＤＵを受信したとき、ＧＴＰ－Ｕノードは、Ｇ－ＰＤＵを廃棄するものとする。着信Ｇ－ＰＤＵのＴＥＩＤが値「すべて０」とは異なる場合、ＧＴＰ－Ｕノードはまた、ＧＴＰエラー指示を発信ノードに返すものとする。ＧＴＰエンティティは、いくつかのシナリオにおけるサービス拒否攻撃の危険を緩和することができる機構の実装を簡略化するために、「ＵＤＰポート」拡張ヘッダ（タイプ０ｘ４０）を含み得る。

受信されたエラー指示のハンドリングが、３ＧＰＰ ＴＳ２３．００７［３］および３ＧＰＰ ＴＳ２３．５２７［３３］において指定されている。

情報エレメント トンネルエンドポイント識別子データＩが、このプロシージャをトリガしたＧ－ＰＤＵからフェッチされるＴＥＩＤであるものとする。

情報エレメントＧＴＰ－Ｕピアアドレスが、このプロシージャをトリガした元のユーザデータメッセージからフェッチされる宛先アドレス（たとえば宛先ＩＰアドレス、ＭＢＭＳベアラコンテキスト）であるものとする。ＧＴＰ－Ｕピアアドレスは、ＧＧＳＮ、ＳＧＳＮ、ＲＮＣ、ＰＧＷ、ＳＧＷ、ｅＰＤＧ、ｅノードＢ、ＴＷＡＮ、ＭＭＥ、ｇＮＢ、Ｎ３ＩＷＦ、またはＵＰＦアドレスであり得る。ＴＥＩＤとＧＴＰ－Ｕピアアドレスとは、一緒に、受信ノードにおける関係するＰＤＰコンテキスト、ＲＡＢ、ＰＤＵセッションまたはＥＰＳベアラを一意に識別する。

随意のプライベート拡張が、ベンダーまたはオペレータ固有情報を含んでいる。
ＴＳ２９．２８１、節７．３．１の終了

図３
本開示の図３は、ＴＳ２９．２８１、節７．３．１の表（「表７．３．１－１：エラー指示中の情報エレメント」）を含む。

ピアＧＴＰ－Ｕエンティティは、所与のパケットデータネットワーク（ＰＤＮ）接続／プロトコルデータユニット（ＰＤＵ）セッションのためのユーザプレーン経路が切断されたことを指示する、ＧＴＰエラー指示を受信すると、これは、制御プレーン機能、たとえばサービングゲートウェイ制御プレーン機能（ＳＧＷ－Ｃ）、またはＰＤＮゲートウェイ制御プレーン機能（ＰＧＷ－Ｃ）、またはセッション管理機能（ＳＭＦ）に報告されなければならず、したがって、制御プレーン機能は、そのＰＤＮ接続のためにユーザプレーンをセットアップするように、再開始したＧＴＰ－Ｕエンティティ（たとえば新世代無線アクセスネットワーク（ＮＧ－ＲＡＮ））に要求するための、関連のある制御プレーンシグナリングプロシージャをトリガし得る。

図４
図４は、ＴＳ２３．５２７の節５．３．２（「５Ｇ－ＡＮから受信されるＧＴＰ－Ｕエラー指示のためのプロシージャ」）中の図（「図５．３．２．１－１：５Ｇ－ＡＮからのＧＴＰ－Ｕエラー指示」）を含む。図（「図５．３．２．１－１：５Ｇ－ＡＮからのＧＴＰ－Ｕエラー指示」）に関して、ＴＳ２３．５２７の節５．３．２は、以下をさらに開示する。

ＴＳ２３．５２７、節５．３．２の開始
１． 既存のＰＤＵセッションのユーザプレーン接続がアクティブ化される。ダウンリンクＧ－ＰＤＵが５Ｇ－ＡＮに向けて送信される。
２． ５Ｇ－ＡＮは、５Ｇ－ＡＮが、対応するＧＴＰ－Ｕコンテキストを有しない場合、ＧＴＰ－Ｕエラー指示を返す（節５．２参照）。
３． ＧＴＰ－Ｕエラー指示の受信時に、ＵＰＦは、３ＧＰＰ ＴＳ２９．２４４［４］の節５．１０において指定されているように、関係するＰＦＣＰセッションを識別し、ＳＭＦにエラー指示報告を送信するものとする。
４． ５Ｇ－ＡＮから受信されたＧＴＰ－Ｕエラー指示について、ＳＭＦは、ダウンリンクパケットをバッファするようにＵＰＦに命令するためにＰＦＣＰセッションを修正するものとする。
５． ＰＤＵセッションのユーザプレーン接続が、ＳＭＦによってアクティブ化されたと見なされる場合、ＳＭＦは、３ＧＰＰ ＴＳ２３．５０２［５］の節４．３．７において指定されているように、ＰＤＵセッションのリソースを解放するように５Ｇ－ＡＮに要求するためにＮａｍｆ＿Ｃｏｍｍｕｎｉｃａｔｉｏｎ＿Ｎ１Ｎ２ＭｅｓｓａｇｅＴｒａｎｓｆｅｒサービス動作を始動するものとする。
６． ＰＤＵセッションリソース解放コマンドを転送するようにとのＮａｍｆ＿Ｃｏｍｍｕｎｉｃａｔｉｏｎ＿Ｎ１Ｎ２ＭｅｓｓａｇｅＴｒａｎｓｆｅｒ要求の受信時に、ＡＭＦは、以下を行うものとする。
－ ＵＥが、ＰＤＵセッションに関連するアクセスネットワークタイプについてＣＭ－ＣＯＮＮＥＣＴＥＤ状態にある場合、３ＧＰＰ ＴＳ２９．５１８［６］の節５．２．２．３．１において指定されているように、要求を進めること、
－ 他の場合、ＵＥが、ＰＤＵセッションに関連するアクセスネットワークタイプについてＣＭ－ＩＤＬＥ状態にあることを指示するエラーとともに、要求を拒否すること。
７． ＡＭＦが５Ｇ－ＡＮにＰＤＵセッションリソース解放コマンドを送信した場合、ＰＤＵセッションのリソース解放は、ＳＭＦに対して確認応答される。
８． ＳＭＦは、ＰＤＵセッションのユーザプレーン接続を再アクティブ化するために、３ＧＰＰ ＴＳ２３．５０２［５］の節４．２．３．３において指定されているネットワークトリガ型サービス要求プロシージャを始動する。
ＴＳ２３．５２７、節５．３．２の終了

ＴＳ２９．２４４において、節７．４．５．１．１（「ＰＦＣＰノード報告要求－概略」）は、「ＰＦＣＰノード報告要求は、ＰＦＣＰセッションに固有でない情報をＣＰ機能に報告するために、ＵＰ機能によって、Ｓｘａ、Ｓｘｂ、ＳｘｃおよびＮ４インターフェース上で送信されるものとする」と開示する。

図５
本開示の図５は、ＴＳ２９．２４４の節７．４．５．１．１中の表（「表７．４．５．１．１－１：ＰＦＣＰノード報告要求中の情報エレメント」）を含む。

図６
本開示の図６は、ＴＳ２９．２４４の節７．４．５．１．２（「ＰＦＣＰノード報告要求内のユーザプレーン経路障害報告ＩＥ」）の表（「表７．４．５．１．２－１：ＰＦＣＰノード報告要求内のユーザプレーン経路障害報告ＩＥ」）を含む。

図７
本開示の図７は、ＴＳ２９．２４４の節８．２．７０（「リモートＧＴＰ－Ｕピア」）中の図（「図８．２．７０－１：リモートＧＴＰ－Ｕピア」）を含む。

現在、（１つまたは複数の）ある課題が存在する。ＧＴＰ－Ｕエンティティ再開始、たとえば、ＮＧ－ＲＡＮ（たとえば、ｇＮＢ）が再開始した、の場合、それは、すべてのそのコンテキストを失うことになり、したがって、中間ユーザプレーン機能（Ｉ－ＵＰＦ）または訪問ＵＰＦ（Ｖ－ＵＰＦ）からのＤＬ ＧＴＰ－Ｕパケットについての対応するコンテキストを見つけることが可能でない。これは、大規模な量のＧＴＰエラー指示メッセージを送信するように、再開始したＧＴＰ－Ｕエンティティをトリガし、これは、ＵＰ機能がＧＴＰエラー指示の受信をＣＰ機能に報告しなければならないので、Ｓｘ／Ｎ４インターフェース上での大規模な量のシグナリングにつながる。

ＧＴＰ－Ｕエンティティが再開始したとき、（ＧＴＰエラー指示を送信するための）ＧＴＰ－Ｕインターフェース上での、および（ＧＴＰエラー指示と、ＤＬ ＦＡＲを更新するためのパケットフォワーディング制御プロトコル（ＰＦＣＰ）セッション修正シグナリングとの受信を報告する）Ｓｘ／Ｎ４上でのそのような大規模シグナリングは、回避されるべきである。

本開示のいくつかの態様およびそれらの実施形態は、これらまたは他の課題のソリューションを提供し得る。本開示は、（たとえば、ＳＧＷ－Ｕ、ＰＧＷ－Ｕ、またはＵＰＦのための）ＧＴＰ－Ｕエンティティが、ピアＧＴＰ－Ｕエンティティが再開始したことを検出することと、ピアＧＴＰ－Ｕエンティティが再開始した場合、ＣＰ機能がユーザプレーン経路を復旧することができるように、ピアＧＴＰ－Ｕエンティティの再開始をＣＰ機能（たとえば、ＳＧＷ－Ｃ、ＰＧＷ－Ｃ、ＳＭＦ）に報告することとを行うことを可能にするための、実施形態を提案する。

本開示の実施形態は、以下の特徴のうちの１つまたは複数を含む。
１． エコー応答メッセージ中に回復タイムスタンプを追加する。回復タイムスタンプは、ＧＴＰｖ１ ＩＥ「ＵＬＩタイムスタンプ」、または「ＵＬＩタイムスタンプ」ＩＥの場合と同じエンコーディングをもつ新しいＩＥを再使用し得る。
２． できるだけ早くピアＧＴＰ－Ｕエンティティへの再開始をポピュレートするために、ＧＴＰエラー指示中に回復タイムスタンプを追加する。あるＧＴＰ－Ｕエンティティ実装形態は、転送しているペイロードパケットがあるとき、エコー要求／応答を送信しないことがある。この場合、ユーザプレーン経路は、健全と見なされ得る。
３． ユーザプレーン機能（ＵＰ機能）が、「ＩＰアドレス」によって識別される複数のＧＴＰ－Ｕエンティティを有し得るので、ＧＴＰエラー指示中に、（再開始によって影響を及ぼされる）ＩＰアドレスのリストを追加する。
４． ＵＰ機能が、ピアＧＴＰ－Ｕが再開始したことを検出したとき、ＵＰ機能は、ＣＰ機能に「ＰＦＣＰノード報告要求」メッセージを送信することになる。ＰＦＣＰノード報告要求メッセージは、ＩＰアドレスのリスト、およびネットワークインスタンス／宛先インターフェースととともに、ピアＧＴＰ－Ｕエンティティが再開始したという情報を含んでいる。さらに、ＵＰ機能は、ＵＰ機能が、ピアＧＴＰ－ｕ再開始によって影響を及ぼされるすべてのＰＦＣＰセッションについて、リモート完全修飾トンネルエンドポイント識別子（Ｆ－ＴＥＩＤ：Ｆｕｌｌｙ ｑｕａｌｉｆｉｅｄ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ）を除去することと、ＦＡＲ（それは、リモートＧＴＰ－Ｕエンティティによって割り当てられたリモートＦ－ＴＥＩＤを含んでおり、したがって、それは、リモートＧＴＰ－Ｕ再開始によって影響を及ぼされた）における適用アクションを「バッファリング」にセットすることとを行おうとしていることを指示し、したがって、ＣＰ機能は、これを行うためにＰＦＣＰセッションごとに「ＰＦＣＰセッション修正要求」を送信する必要がない（たとえば、ＣＰ機能は、ＦＡＲにおけるリモートＦ－ＴＥＩＤを除去し、適用アクションを変更する）。
５． ＣＰ機能は、ピアＧＴＰ－Ｕエンティティが再開始し、再開始したＧＴＰ－Ｕエンティティによって割り当てられたＦ－ＴＥＩＤが、無効になり、影響を及ぼされるＰＦＣＰセッションから除去されるべきであるという、報告に確認応答する。
６． ＣＰ機能は、ローカル設定に基づいてリモートＧＴＰ－Ｕ再開始によって影響を及ぼされるＰＤＵセッションを解放すること、たとえば、再開始したリモートＧＴＰ－ＵエンティティがＰＤＵセッションアンカー（ＰＳＡ）ＵＰＦである場合に、影響を及ぼされるＰＤＵセッションを解放すること、あるいは、たとえば再開始したリモートＧＴＰ－ＵエンティティがＮＧ－ＲＡＮ（たとえば、ｇＮＢ）またはＲＡＮ（たとえば、ｅＮＢ）である場合に、影響を及ぼされるＰＤＵセッションのためのユーザプレーン接続を復旧することを判断する。

いくつかの実施形態は、（１つまたは複数の）以下の技術的利点のうちの１つまたは複数を提供し得る。ＧＴＰ－Ｕエンティティ再開始のための大規模シグナリングは、ＧＴＰ－ＵがすべてのそのＧＴＰ－Ｕコンテキストを失っており、それらのＧＴＰ－Ｕコンテキストが、他の手段によって、たとえば、そのＧＴＰ－ＵのＣＰ機能を介して復旧され得ない場合、回避され得る。

本開示のこれらおよび他の目的、特徴および利点は、添付の図面とともに読み取られるべきである、本開示の例示的な実施形態の以下の詳細な説明から明らかになろう。

ＴＳ２９．２８１における節７．２．２の表７．２．２－１を含む図である。 ＴＳ２９．２８１の節７．７．１１４中の図（「図７．７．１１４－１：ＵＬＩタイムスタンプ」）を含む図である。 ＴＳ２９．２８１、節７．３．１の表（「表７．３．１－１：エラー指示中の情報エレメント」）を含む図である。 ＴＳ２３．５２７の節５．３．２（「５Ｇ－ＡＮから受信されるＧＴＰ－Ｕエラー指示のためのプロシージャ」）中の図（「図５．３．２．１－１：５Ｇ－ＡＮからのＧＴＰ－Ｕエラー指示」）を含む図である。 ＴＳ２９．２４４の節７．４．５．１．１中の表（「表７．４．５．１．１－１：ＰＦＣＰノード報告要求中の情報エレメント」）を含む図である。 ＴＳ２９．２４４の節７．４．５．１．２（「ＰＦＣＰノード報告要求内のユーザプレーン経路障害報告ＩＥ」）の表（「表７．４．５．１．２－１：ＰＦＣＰノード報告要求内のユーザプレーン経路障害報告ＩＥ」）を含む図である。 ＴＳ２９．２４４の節８．２．７０（「リモートＧＴＰ－Ｕピア」）中の図（「図８．２．７０－１：リモートＧＴＰ－Ｕピア」）を含む図である。 本開示の１つの例示的な実施形態による、ピアＧＴＰ－Ｕエンティティ再開始を検出および報告するためのプロシージャの一実施形態を示す図である。 ＣＰ－１ ８００がいくつかのステップを実施し得る一実施形態を示す図である。 ＵＰ－１ ８０２がいくつかのステップを実施し得る一実施形態を示す図である。 ＵＰ－２ ８０４がいくつかのステップを実施し得る一実施形態を示す図である。 ＣＰ－１ ８００がいくつかのステップを実施し得る一実施形態を示す図である。 本開示の実施形態が実装され得るセルラ通信システム１３００の一例を示す図である。 任意の２つのネットワーク機能（ＮＦ）間の対話がポイントツーポイント参照ポイント／インターフェースによって表される、コアＮＦから組み立てられた５Ｇネットワークアーキテクチャとして表される無線通信システムを示す図である。 図１４の５Ｇネットワークアーキテクチャにおいて使用されるポイントツーポイント参照ポイント／インターフェースの代わりに、ＣＰ中でＮＦ間でサービスベースインターフェースを使用する５Ｇネットワークアーキテクチャを示す図である。 本開示のいくつかの実施形態による、ネットワークノード１６００の概略ブロック図である。 本開示のいくつかの実施形態による、ネットワークノード１６００の仮想化された実施形態を示す概略ブロック図である。 本開示のいくつかの他の実施形態による、ネットワークノード１６００の概略ブロック図である。

次に、添付の図面を参照しながら、本明細書で企図される実施形態のうちのいくつかがより十分に説明される。実施形態は、例として、主題の範囲を当業者に伝えるように提供される。また、追加情報が、付録（付録１および付録２）において提供される（１つまたは複数の）文書において見つけられ得る。

図８
図８は、本開示の１つの例示的な実施形態による、ピアＧＴＰ－Ｕエンティティ再開始を検出および報告するためのプロシージャの一実施形態を示す。プロシージャは、ＣＰ機能（「ＣＰ－１ ８００」）と、第１のＵＰ機能（「ＵＰ－１ ８０２」）と、第２のＵＰ機能（「ＵＰ－２ ８０４」）とによって実施される。ＣＰ－１ ８００は、ＳＧＷ－Ｃ、ＰＧＷ－Ｃ、またはＳＭＦであり得るか、あるいはそれにおいて実装され得る。ＵＰ－１ ８０２またはＵＰ－２ ８０４は、ｇＮＢ、ｅＮＢ、ＳＧＷ－Ｕ、ＰＧＷ－Ｕ、Ｉ－ＵＰＦ（中間ＵＰＦ）、またはＶ－ＵＰＦ（訪問ＵＰＦ）であり得るか、あるいはそれにおいて実装され得る。本開示の図８は、以下のステップを示す。
ステップ８０６およびステップ８０８において、ＣＰ－１ ８００とＵＰ－１ ８０２との間のＰＦＣＰセッションをセットアップするために、ＰＦＣＰセッション確立および修正要求／応答メッセージが使用される。プロシージャは、ＣＰ－１ ８００が、ＵＰ－１ ８０２にリモートＧＴＰ－Ｕの（ＵＰ－２ ８０４）Ｆ－ＴＥＩＤ（ＩＰアドレス＋トンネルエンドポイントＩＤ）を提供することを可能にする。言い換えれば、ＰＦＣＰセッション確立および修正要求メッセージは、リモートＧＴＰ－ＵのＦ－ＴＥＩＤを含んでいることがある。したがって、ＵＰ－１ ８０２は、ＣＰ機能に向けてペイロードを送信することになり、同時に、ＵＰ－１ ８０２は、ＣＰ機能に、ＵＰ－１ ８０２の、（リモートＧＴＰ－Ｕ（ＵＰ－２ ８０４）からペイロードを受信するために使用される）ＧＴＰ－Ｕ Ｆ－ＴＥＩＤを提供することになる。ＣＰ機能は、さらに、たとえば、ＮＧＡＰシグナリングメッセージ（ＵＰ－２ ８０４がＮＧ－ＲＡＮノードである場合、ＰＤＵセッションリソースセットアップ要求メッセージ）を介して、ＵＰ－２ ８０４にＵＰ－１のＧＴＰ－Ｕ Ｆ－ＴＥＩＤをポピュレートするために、制御プレーンシグナリングを使用することになる。
ステップ８１０およびステップ８１２において、ＵＰ－１ ８０２はＵＰ－２ ８０４に「エコー要求」を送信し得、エコー要求は、ＵＰ－２ ８０４のライブネスをプローブするための（ＵＰ－２ ８０４からのＦ－ＴＥＩＤ中の）ＩＰアドレスを含む。エコー要求は、エコー要求のソースＩＰアドレスによって識別される、ＵＰ－１ ８０２の回復情報を含む。ＵＰ２は、エコー応答のリソースＩＰアドレスによって識別される、ＵＰ－２の回復情報を含んでいる「エコー応答」メッセージで返答することになる。ＵＰ－１ ８０２は、将来の比較のためにＵＰ－２の回復情報を記憶することになる。ＵＰ－２ ８０４も、ＵＰ－１ ８０２に「エコー要求」を送信し得る。次いで、ＵＰ－２ ２ ８０４も、ＵＰ－１ ８０２から「エコー応答」を受信し得る。ペイロードは、ＵＰ－１ ８０２とＵＰ－２ ８０４との間のセグメントを含む、エンドツーエンドで転送している。ＵＰ－２ ８０４は、再開始し、再開始から回復した。しかしながら、ＵＰ－２ ８０４は、すべてのそのＧＴＰ－Ｕコンテキストを失っており、すなわち、ＵＰ－２ ８０４は、それがその再開始の前に割り当てたＦ－ＴＥＩＤを認識することができない。
ステップ８１４において、再開始したＵＰ－２ ８０４が、再開始したＵＰ－２ ８０４が認識しないＧＴＰ－Ｕ Ｆ－ＴＥＩＤをアドレス指定するペイロードを受信したとき、再開始したＵＰ－２ ８０４は、（１）変更された回復情報を含んでいる「ＧＴＰエラー指示」メッセージと、（２）再開始によって影響を及ぼされるＩＰアドレスのリスト、すなわち、これらのＩＰアドレスに関連するすべてのＧＴＰ－Ｕコンテキストが失われた、とを送信する。
ステップ８１６において、ＵＰ－１ ８０２はＣＰ－１ ８００に「ＰＦＣＰノード報告要求」メッセージを送信し、「ＰＦＣＰノード報告要求」メッセージは、（１）ピアＵＰ（ＵＰ－２ ８０４）が再開始したこと、および（ＧＴＰエラー指示中で提供される）ＩＰアドレスのリストに関連するＧＴＰ－Ｕコンテキストが失われたことと、（２）ＵＰ－１ ８０２が、ＤＬ ＦＡＲにおける適用アクションを「バッファリング」にセットし、すべての影響を及ぼされるＰＦＣＰセッションについて、（ＵＰ－２ ８０４からの）ＤＬ Ｆ－ＴＥＩＤを除去するべきであり、すなわち、ＣＰ－１ ８００が、ＰＦＣＰセッションごとにＤＬ ＦＡＲを変更するために「ＰＦＣＰセッション修正要求」メッセージを送信する必要がないこととを指示する。
ステップ８１８において、ＰＦＣＰノード報告要求メッセージに対する応答として、ＣＰ－１ ８００は、ＵＰ－１ ８０２に、「ＰＦＣＰノード報告応答」を送信し、「ＰＦＣＰノード報告応答」は、（再開始したＵＰ－２ ８０４との）すべての影響を及ぼされるＰＦＣＰセッションにおけるダウンリンクＦＡＲが、適用アクションが「バッファリング」にセットされて、更新され、（ＵＰ－２ ８０４からの）リモートＦ－ＴＥＩＤが除去されたという確認応答を含む。
ステップ８２０において、ＣＰ－１ ８００は、ローカル設定に基づいてリモートＧＴＰ－Ｕ再開始によって影響を及ぼされるＰＤＵセッションを解放すること、たとえば、再開始したリモートＧＴＰ－ＵエンティティがＰＳＡ ＵＰＦである場合に、影響を及ぼされるＰＤＵセッションを解放すること、あるいは、たとえば再開始したリモートＧＴＰ－ＵエンティティがＮＧ－ＲＡＮ（たとえば、ｇＮＢ）またはＲＡＮ（たとえば、ｅＮＢ）である場合に、影響を及ぼされるＰＤＵセッションのためのユーザプレーン接続を復旧することを判断する。

図９
一実施形態では、ＣＰ－１ ８００は、図９に示されている以下のステップを実施し得る。
ステップ９００において、ＣＰ－１ ８００は、ＵＰ－１ ８０２から、ＵＰ－２ ８０４が再開始した、に関係する報告を含んでいるＰＦＣＰメッセージを受信する。随意に、ＰＦＣＰメッセージはＰＦＣＰノード報告要求メッセージである。随意に、報告は、ＵＰ－１ ８０２が、すべての影響を及ぼされるＰＦＣＰセッションについて、ＵＰ－２ ８０４によって割り当てられた（１つまたは複数の）リモートＦ－ＴＥＩＤを除去し、ＦＡＲにおける適用アクションを「バッファリング」に変更したという指示をさらに含む。
ステップ９０２において、ＣＰ－１ ８００は、報告に確認応答し、すなわち、ＣＰ－１ ８００は、ＵＰ－１ ８０２に、リモートＦ－ＴＥＩＤを除去することと、ＦＡＲにおける適用アクションを変更することとを行うようにとのＰＦＣＰセッション修正要求メッセージを送信しないことになる。
ステップ９０４において、ＣＰ－１ ８００は、ＵＰ－２ ８０４の識別情報に基づいてアクションを実施する。ステップ９０４Ａにおいて、ＣＰ－１ ８００は、ＵＰ－２ ８０４がＲＡＮまたはＮＧ－ＲＡＮノードである場合、影響を及ぼされるＰＤＵセッションのためのユーザプレーン接続を復旧する。ステップ９０４Ｂにおいて、ＣＰ－１ ８００は、ＵＰ－２ ８０４がＰＳＡ ＵＰＦまたはＰＧＷ－Ｕである場合、影響を及ぼされるＰＤＵセッションを解放する。

図１０
一実施形態では、ＵＰ－１ ８０２は、図１０に示されている以下のステップを実施し得る。
ステップ１０００において、ＵＰ－１ ８０２は、ＵＰ－２ ８０４にエコー要求を送信する。随意に、エコー要求は回復タイムスタンプを含み得る。
ステップ１００２において、ＵＰ－１ ８０２は、ＵＰ－２ ８０４からエコー応答を受信する。
ステップ１００４において、ＵＰ－１ ８０２は、ＵＰ－２ ８０４からエコー要求を受信する。
ステップ１００６において、ＵＰ－１ ８０２は、ＵＰ－２ ８０４にエコー応答を送信する。このステップまで、ＵＰ－１ ８０２とＵＰ－２ ８０４とは、それらの回復タイムスタンプを交換しており、したがって、ＵＰ－１ ８０２とＵＰ－２ ８０４とは、（再開始による）新しい回復タイムスタンプが無効になる前に割り当てられたＦ－ＴＥＩＤを知ることになる。上記のステップ１０００～１００６は、ＵＰ－１ ８０２とＵＰ－２ ８０４との間でエコー要求／エコー応答を交換する例示的なステップである。したがって、ステップ１０００～１００６の時間順序が変動させられ得る。たとえば、ステップ１００４および１００６は、ステップ１０００および１００２の前に行われ得る。
ステップ１００８において、ＵＰ－１ ８０２は、回復タイムスタンプを含むＧＴＰエラー指示を受信する。
ステップ１０１０において、ＵＰ－１ ８０２は、ＧＴＰエラー指示中で受信された回復タイムスタンプを、エコー要求、エコー応答、またはＧＴＰエラー指示を介して前に受信された回復タイムスタンプと比較する。
ステップ１０１２において、ＵＰ－１ ８０２は、ＵＰ－２ ８０４が再開始したと決定する。
ステップ１０１４において、ＵＰ－１ ８０２は、たとえば、さらなるＧＴＰエラー指示を受信することと、ＵＰ－２ ８０４の再開始によって影響を及ぼされるＵＥ／ＰＤＵセッションをオーバーチャージすることとを回避するために、再開始したＵＰ－２ ８０４にさらなるペイロードを送信することを停止する。
ステップ１０１６において、ＵＰ－１ ８０２は、ＵＰ－１ ８０２がもはやペイロードを送信しないので、ＵＰ－２ ８０４によって割り当てられたＦ－ＴＥＩＤを除去し、「適用アクション」を「バッファリング」に変更する。
ステップ１０１８において、ＵＰ－１ ８０２は、ＵＰ－２ ８０４の再開始を報告するようにとのＰＦＣＰ要求メッセージを送信する。随意に、ＰＦＣＰ要求メッセージはＰＦＣＰノード報告要求メッセージである。
ステップ１０２０において、ＵＰ－１ ８０２はＰＦＣＰ応答メッセージを受信する。

図１１
一実施形態では、ＵＰ－２ ８０４は、図１１に示されている以下のステップを実施し得る。
ステップ１１００において、ＵＰ－２ ８０４は、ＵＰ－１ ８０２にエコー要求を送信する。随意に、エコー要求は回復タイムスタンプを含む。
ステップ１１０２において、ＵＰ－２ ８０４は、ＵＰ－１ ８０２からエコー応答を受信する。
ステップ１１０４において、ＵＰ－２ ８０４は、ＵＰ－１ ８０２からエコー要求を受信する。
ステップ１１０６において、ＵＰ－２ ８０４は、ＵＰ－１ ８０２にエコー応答を送信する。このステップまで、ＵＰ－１ ８０２とＵＰ－２ ８０４とは、それらの回復タイムスタンプを交換しており、したがって、ＵＰ－１ ８０２とＵＰ－２ ８０４とは、（再開始による）新しい回復タイムスタンプが無効になる前に割り当てられたＦ－ＴＥＩＤを知ることになる。上記のステップ１１００～１１０６は、ＵＰ－１ ８０２とＵＰ－２ ８０４との間でエコー要求／エコー応答を交換する例示的なステップである。したがって、ステップ１１００～１１０６の時間順序が変動させられ得る。たとえば、ステップ１１０４および１１０６は、ステップ１１００および１１０２の前に行われ得る。
ステップ１１０８において、ＵＰ－２ ８０４は、ＵＰ－１ ８０２に、新しい回復タイムスタンプを含むＧＴＰエラー指示を送信する。

図１２
一実施形態では、ＣＰ－１ ８００は、図１２に示されている以下のステップを実施し得る。
ステップ１２０８において、ＣＰ－１ ８００は、ＵＰ－１ ８０２から、ＵＰ－２ ８０４が再開始した、に関係する報告を含むパケットフォワーディング制御プロトコル（ＰＦＣＰ）要求メッセージを受信する。
ステップ１２１０において、ＣＰ－１ ８００は、ＵＰ－１ ８０２にＰＦＣＰ応答メッセージを送信することによって報告に確認応答する。
ステップ１２１２において、ＣＰ－１ ８００は、ＵＰ－２ ８０４の識別情報に基づいてアクションを実施する。ＵＰ－２ ８０４の識別情報がＲＡＮまたはＮＧ－ＲＡＮノードである場合、アクションは、影響を及ぼされるＰＤＵセッションのためのユーザプレーン接続を復旧することである。ＵＰ－２ ８０４の識別情報がＰＳＡ ＵＤＦまたはＰＧＷ－Ｕである場合、アクションは、影響を及ぼされるＰＤＵセッションを解放することである。
一実施形態では、ＵＰ－１ ８０２は、図１２に示されている以下のステップを実施し得る。
ステップ１２００およびステップ１２０２において、ＵＰ－１ ８０２は、エコー要求およびエコー応答をＵＰ－２ ８０４と交換する。
ステップ１２０４において、ＵＰ－１ ８０２は、回復タイムスタンプを含んでいるＧＴＰエラー指示を受信する。
ステップ１２０６Ａにおいて、ＵＰ－１ ８０２は、ＧＴＰエラー指示中で受信された回復タイムスタンプを、エコー要求、エコー応答またはＧＴＰエラー指示を介して前に受信された回復タイムスタンプと比較する。
ステップ１２０６Ｂにおいて、ＵＰ－１ ８０２は、ＵＰ－２ ８０４が再開始したと決定する。
ステップ１２０６Ｃにおいて、ＵＰ－１ ８０２は、再開始したＵＰ－２ ８０４にさらなるペイロードを送信することを停止する。
ステップ１２０６Ｃにおいて、ＵＰ－１ ８０２は、ＵＰ－２ ８０４によって割り当てられたＦ－ＴＥＩＤを除去し、適用アクションをバッファリングに変更する。
ステップ１２０８において、ＵＰ－１ ８０２は、ＵＰ－２ ８０４の再開始を報告するようにとのＰＦＣＰ要求メッセージを送信する。
ステップ１２１０において、ＵＰ－１ ８０２はＰＦＣＰ応答メッセージを受信する。
一実施形態では、ＵＰ－２ ８０４は、図１２に示されている以下のステップを実施し得る。
ステップ１２００およびステップ１２０２において、ＵＰ－２ ８０４は、エコー要求およびエコー応答をＵＰ－１ ８０２と交換する。
ステップ１２０４において、ＵＰ－２ ８０４は、新しい回復タイムスタンプを含むＧＴＰエラー指示を送信する。

３ＧＰＰ変更
以下は、本開示をサポートするための（ステージ３仕様中の）いくつかの３ＧＰＰ変更を例示する。イタリック体の太字のテキスト（または情報エレメント）は、３ＧＰＰ規格に対する新たに示唆される変更を指示する。

ＴＳ２９．２８１の以下の節（７．２．２および７．３．１）が、イタリック体の太字のテキスト（または情報エレメント）によって指示される部分において変更するように提案される。

ＴＳ２９．２８１の開始
７．２．２ エコー応答
メッセージは、受信されたエコー要求に対する応答として送信されるものとする。

回復情報エレメント中の再開始カウンタ値は使用されないものとし、すなわち、再開始カウンタ値は、送信側によって０にセットされるものとし、受信側によって無視されるものとする。回復情報エレメントは、バックワードコンパチビリティの理由により必須である。

随意のプライベート拡張が、ベンダーまたはオペレータ固有情報を含んでいる。

７．３．１ エラー指示
ＧＴＰ－Ｕノードが、ＥＰＳベアラコンテキスト、ＰＤＰコンテキスト、ＰＤＵセッション、ＭＢＭＳベアラコンテキスト、またはＲＡＢが存在しない、Ｇ－ＰＤＵを受信したとき、ＧＴＰ－Ｕノードは、Ｇ－ＰＤＵを廃棄するものとする。着信Ｇ－ＰＤＵのＴＥＩＤが値「すべて０」とは異なる場合、ＧＴＰ－Ｕノードはまた、ＧＴＰエラー指示を発信ノードに返すものとする。ＧＴＰエンティティは、いくつかのシナリオにおけるサービス拒否攻撃の危険を緩和することができる機構の実装を簡略化するために、「ＵＤＰポート」拡張ヘッダ（タイプ０ｘ４０）を含み得る。

受信されたエラー指示のハンドリングが、３ＧＰＰ ＴＳ２３．００７［３］および３ＧＰＰ ＴＳ２３．５２７［３３］において指定されている。

情報エレメント トンネルエンドポイント識別子データＩが、このプロシージャをトリガしたＧ－ＰＤＵからフェッチされるＴＥＩＤであるものとする。

情報エレメントＧＴＰ－Ｕピアアドレスが、このプロシージャをトリガした元のユーザデータメッセージからフェッチされる宛先アドレス（たとえば、宛先ＩＰアドレス、ＭＢＭＳベアラコンテキスト）であるものとする。ＧＴＰ－Ｕピアアドレスは、ＧＧＳＮ、ＳＧＳＮ、ＲＮＣ、ＰＧＷ、ＳＧＷ、ｅＰＤＧ、ｅノードＢ、ＴＷＡＮ、ＭＭＥ、ｇＮＢ、Ｎ３ＩＷＦ、またはＵＰＦアドレスであり得る。ＴＥＩＤとＧＴＰ－Ｕピアアドレスとは、一緒に、受信ノードにおける関係するＰＤＰコンテキスト、ＲＡＢ、ＰＤＵセッションまたはＥＰＳベアラを一意に識別する。随意のプライベート拡張が、ベンダーまたはオペレータ固有情報を含んでいる。

ＴＳ２９．２４４の以下の節が、イタリック体の太字のテキスト（または情報エレメント）によって指示される部分において変更するように提案される。

ＴＳ２９．２４４の開始
７．４．５．１．１ 概略
ＰＦＣＰノード報告要求は、ＰＦＣＰセッションに固有でない情報をＣＰ機能に報告するために、ＵＰ機能によって、Ｓｘａ、Ｓｘｂ、ＳｘｃおよびＮ４インターフェース上で送信されるものとする。

７．４．５．１．Ｘ ＰＦＣＰノード報告要求内のピアＵＰ再開始報告ＩＥ
表7.4.5.1.X-1: PFCPノード報告要求内のユーザプレーン経路回復報告IE

８．２．６９ ノード報告タイプ
ノード報告タイプＩＥは、図８．２．６９－１に示されているように符号化されるものとする。ノード報告タイプＩＥは、ＵＰ機能がＣＰ機能に送信するノード報告のタイプを指示する。

オクテット５は、以下のように符号化されるものとする。
－ ビット１－ ＵＰＦＲ（ユーザプレーン経路障害報告）：「１」にセットされたとき、これはユーザプレーン経路障害報告を指示する。
－ ビット２－ ＵＰＲＲ（ユーザプレーン経路回復報告）：「１」にセットされたとき、これはユーザプレーン経路回復報告を指示する。
ビット３－ ＣＫＤＲ（クロックドリフト報告）：「１」にセットされたとき、これはクロックドリフト報告を指示する。
－ ビット４－ ＧＰＱＲ（ＧＴＰ－Ｕ経路ＱｏＳ報告）：「１」にセットされたとき、これはＧＴＰ－Ｕ経路ＱｏＳ報告を指示する。
－ ビット５－ ＰＵＲＲ（ピアＧＴＰ－Ｕエンティティ再開始報告）：「１」にセットされたとき、これはピアＧＴＰ－Ｕ再開始報告を指示する。
－ ビット６～８－ 将来の使用のためのスペアであり、「０」にセットされる。

少なくとも１つのビットが「１」にセットされるものとする。いくつかのビットが「１」にセットされ得る。
注： ＵＰＦＲビットとＵＰＲＲビットの両方が「１」にセットされた場合、ユーザプレーン経路障害報告ＩＥ中のリモートＧＴＰ－ＵピアＩＥとユーザプレーン経路回復報告ＩＥ中のリモートＧＴＰ－ＵピアＩＥとが異なる。

ＣＰ機能およびＵＰ機能は、ＣＰ機能特徴およびＵＰ機能特徴を介して、（上記で説明された）この新しい特徴のそれらの機能のサポートを指示する必要がある。

８．２．５８ ＣＰ機能特徴
ＣＰ機能特徴ＩＥは、ＣＰ機能によってサポートされる特徴を指示する。（システム全体に及ぶ）ＵＰ機能挙動に対する影響を有する特徴のみが、このＩＥ中でシグナリングされる。ＣＰ機能特徴ＩＥは、図８．２．５８－１に示されているようにコーディングされる。

ＣＰ機能特徴ＩＥは、各ビットセットが、対応する特徴がサポートされることを指示する、ビットマスクの形態をとる。スペアビットが受信側によって無視されるものとする。同じビットマスクが、すべてのＰＦＣＰインターフェースについて規定される。

以下の表は、ＰＦＣＰインターフェース上で規定される特徴と、それらの特徴が適用されるインターフェースとを指定する。

８．２．２５ ＵＰ機能特徴
ＵＰ機能特徴ＩＥは、ＵＰ機能によってサポートされる特徴を指示する。ＵＰ機能特徴ＩＥは、図８．２．２５－１に示されているようにコーディングされる。

ＵＰ機能特徴ＩＥは、各ビットセットが、対応する特徴がサポートされることを指示する、ビットマスクの形態をとる。スペアビットが受信側によって無視されるものとする。同じビットマスクが、すべてのＰＦＣＰインターフェースについて規定される。

以下の表は、ＰＦＣＰインターフェース上で規定される特徴と、それらの特徴が適用されるインターフェースとを指定する。

図１３
図１３は、本開示の実施形態が実装され得るセルラ通信システム１３００の一例を示す。本明細書で説明される実施形態では、セルラ通信システム１３００は、次世代ＲＡＮ（ＮＧ－ＲＡＮ）と５Ｇコア（５ＧＣ）とを含む５Ｇシステム（５ＧＳ）である。この例では、ＲＡＮは、５ＧＳにおいてＮＲ基地局（ｇＮＢ）と随意に次世代ｅＮＢ（ｎｇ－ｅＮＢ）（たとえば、５ＧＣに接続されたＬＴＥ ＲＡＮノード）とを含み、ＥＰＳにおいてｅＮＢを含む、基地局１３０２－１および１３０２－２を含み、これらは対応する（マクロ）セル１３０４－１および１３０４－２を制御する。基地局１３０２－１および１３０２－２は、概して、本明細書では、まとめて基地局１３０２と呼ばれ、個別に基地局１３０２と呼ばれる。同様に、（マクロ）セル１３０４－１および１３０４－２は、概して、本明細書では、まとめて（マクロ）セル１３０４と呼ばれ、個別に（マクロ）セル１３０４と呼ばれる。ＲＡＮは、対応するスモールセル１３０８－１～１３０８－４を制御する、いくつかの低電力ノード１３０６－１～１３０６－４をも含み得る。低電力ノード１３０６－１～１３０６－４は、（ピコ基地局またはフェムト基地局などの）小さい基地局またはＲＲＨなどであり得る。特に、示されていないが、スモールセル１３０８－１～１３０８－４のうちの１つまたは複数は、基地局１３０２によって代替的に提供され得る。低電力ノード１３０６－１～１３０６－４は、概して、本明細書では、まとめて低電力ノード１３０６と呼ばれ、個別に低電力ノード１３０６と呼ばれる。同様に、スモールセル１３０８－１～１３０８－４は、概して、本明細書では、まとめてスモールセル１３０８と呼ばれ、個別にスモールセル１３０８と呼ばれる。セルラ通信システム１３００は、５Ｇシステム（５ＧＳ）において５ＧＣと呼ばれる、コアネットワーク１３１０をも含む。基地局１３０２（および、随意に低電力ノード１３０６）は、コアネットワーク１３１０に接続される。

基地局１３０２および低電力ノード１３０６は、対応するセル１３０４および１３０８中の無線通信デバイス１３１２－１～１３１２－５にサービスを提供する。無線通信デバイス１３１２－１～１３１２－５は、概して、本明細書では、まとめて無線通信デバイス１３１２と呼ばれ、個別に無線通信デバイス１３１２と呼ばれる。以下の説明では、無線通信デバイス１３１２は、しばしばＵＥであるが、本開示はそれに限定されない。

図１４
図１４は、任意の２つのネットワーク機能（ＮＦ）間の対話がポイントツーポイント参照ポイント／インターフェースによって表される、コアＮＦから組み立てられた５Ｇネットワークアーキテクチャとして表される無線通信システムを示す。図１４は、図１３のシステム１３００の特定の一実装形態と見なされ得る。

アクセス側から見ると、図１４に示されている５Ｇネットワークアーキテクチャは、ＲＡＮ１３０２またはアクセスネットワーク（ＡＮ）のいずれか、ならびにＡＭＦ１４００に接続される複数のＵＥ１３１２を備える。一般に、Ｒ（ＡＮ）１３０２は、たとえばｅＮＢまたはｇＮＢあるいは同様のものなど、基地局を備える。コアネットワーク側から見ると、図１４に示されている５ＧＣ ＮＦは、ＮＳＳＦ１４０２、ＡＵＳＦ１４０４、ＵＤＭ１４０６、ＡＭＦ１４００、ＳＭＦ１４０８、ＰＣＦ１４１０、およびアプリケーション機能（ＡＦ）１４１２を含む。

標準的な規格化における詳細なコールフローを展開するために５Ｇネットワークアーキテクチャの参照ポイント表現が使用される。ＵＥ１３１２とＡＭＦ１４００との間のシグナリングを搬送するために、Ｎ１参照ポイントが規定される。ＡＮ１３０２とＡＭＦ１４００との間を、およびＡＮ１３０２とＵＰＦ１４１４との間を接続するための参照ポイントが、それぞれ、Ｎ２およびＮ３として規定される。ＡＭＦ１４００とＳＭＦ１４０８との間に参照ポイントＮ１１があり、これは、ＳＭＦ１４０８がＡＭＦ１４００によって少なくとも部分的に制御されることを暗示する。Ｎ４が、ＳＭＦ１４０８およびＵＰＦ１４１４によって使用され、したがって、ＵＰＦ１４１４は、ＳＭＦ１４０８によって生成された制御信号を使用してセットされ得、ＵＰＦ１４１４は、その状態をＳＭＦ１４０８に報告することができる。それぞれ、Ｎ９が、異なるＵＰＦ１４１４間の接続のための参照ポイントであり、Ｎ１４が、異なるＡＭＦ１４００間を接続する参照ポイントである。ＰＣＦ１４１０が、それぞれ、ＡＭＦ１４００およびＳＭＦ１４０８にポリシを適用するので、Ｎ１５およびＮ７が規定される。Ｎ１２は、ＡＭＦ１４００がＵＥ１３１２の認証を実施するために必要とされる。ＵＥ１３１２のサブスクリプションデータがＡＭＦ１４００およびＳＭＦ１４０８のために必要とされるので、Ｎ８およびＮ１０が規定される。

５ＧＣネットワークは、ＵＰとＣＰとを分離することを目的とする。ＵＰはユーザトラフィックを搬送し、ＣＰはネットワーク中のシグナリングを搬送する。図１４では、ＵＰＦ１４１４はＵＰ中にあり、すべての他のＮＦ、すなわち、ＡＭＦ１４００、ＳＭＦ１４０８、ＰＣＦ１４１０、ＡＦ１４１２、ＮＳＳＦ１４０２、ＡＵＳＦ１４０４、およびＵＤＭ１４０６はＣＰ中にある。ＵＰとＣＰとを分離することは、各プレーンリソースが独立してスケーリングされることを保証する。ＵＰとＣＰとを分離することはまた、ＵＰＦが、分散してＣＰ機能とは別個に展開されることを可能にする。このアーキテクチャでは、ＵＰＦは、低レイテンシを必要とするいくつかの適用例についてＵＥとデータネットワークとの間のラウンドトリップタイム（ＲＴＴ）を短縮するために、ＵＥの極めて近くに展開され得る。

コア５Ｇネットワークアーキテクチャは、モジュール化された機能から組み立てられる。たとえば、ＡＭＦ１４００とＳＭＦ１４０８とは、ＣＰ中の独立した機能である。分離されたＡＭＦ１４００とＳＭＦ１４０８とは、独立した発展およびスケーリングを可能にする。ＰＣＦ１４１０およびＡＵＳＦ１４０４のような他のＣＰ機能が、図１４に示されているように分離され得る。モジュール化された機能設計は、５ＧＣネットワークが様々なサービスをフレキシブルにサポートすることを可能にする。

各ＮＦは、別のＮＦと直接対話する。あるＮＦから別のＮＦにメッセージをルーティングするために中間機能を使用することが可能である。ＣＰでは、２つのＮＦ間の対話のセットがサービスとして規定され、したがって、その再使用が可能である。このサービスは、モジュラリティのサポートを可能にする。ＵＰは、異なるＵＰＦ間のフォワーディング動作など、対話をサポートする。

図１５
図１５は、図１４の５Ｇネットワークアーキテクチャにおいて使用されるポイントツーポイント参照ポイント／インターフェースの代わりに、ＣＰ中でＮＦ間でサービスベースインターフェースを使用する５Ｇネットワークアーキテクチャを示す。しかしながら、図１４を参照しながら上記で説明されたＮＦは、図１５に示されているＮＦに対応する。ＮＦが他の許可されたＮＦに提供する（１つまたは複数の）サービスなどは、サービスベースインターフェースを通して、許可されたＮＦに公開され得る。図１５では、サービスベースインターフェースは、文字「Ｎ」およびその後に続くＮＦの名前、たとえば、ＡＭＦ１４００のサービスベースインターフェースの場合はＮａｍｆおよびＳＭＦ１４０８のサービスベースインターフェースの場合はＮｓｍｆなどによって指示される。図１５中のＮＥＦ１５００およびＮＲＦ１５０２は、上記で説明された図１４に示されていない。しかしながら、図１４中で明示的に指示されていないが、図１４に示されているすべてのＮＦが、必要に応じて図１５のＮＥＦ１５００およびＮＲＦ１５０２と対話することができることが、明瞭にされるべきである。

図１４および図１５に示されているＮＦのいくつかの性質が、以下の様式で説明され得る。ＡＭＦ１４００は、ＵＥベース認証、許可、モビリティ管理などを提供する。ＡＭＦ１４００はアクセス技術から独立しているので、多元接続技術を使用するＵＥ１３１２でさえ、基本的に単一のＡＭＦ１４００に接続される。ＳＭＦ１４０８は、セッション管理を担当し、インターネットプロトコル（ＩＰ）アドレスをＵＥに割り当てる。ＳＭＦ１４０８はまた、データ転送のためにＵＰＦ１４１４を選択し、制御する。ＵＥ１３１２が複数のセッションを有する場合、複数のセッションを個別に管理し、場合によってはセッションごとに異なる機能を提供するために、異なるＳＭＦ１４０８が各セッションに割り当てられ得る。ＡＦ１４１２は、ＱｏＳをサポートするために、ポリシ制御を担当するＰＣＦ１４１０に、パケットフローに関する情報を提供する。その情報に基づいて、ＰＣＦ１４１０は、ＡＭＦ１４００およびＳＭＦ１４０８を適切に動作させるために、モビリティおよびセッション管理に関するポリシを決定する。ＡＵＳＦ１４０４は、ＵＥまたは同様のものについての認証機能をサポートし、したがって、ＵＥまたは同様のものの認証のためのデータを記憶し、ＵＤＭ１４０６は、ＵＥ１３１２のサブスクリプションデータを記憶する。５ＧＣネットワークの一部でないデータネットワーク（ＤＮ）は、インターネットアクセスまたはオペレータサービスおよび同様のものを提供する。

ＮＦは、専用ハードウェア上のネットワークエレメントとして、専用ハードウェア上で稼働するソフトウェアインスタンスとして、または適切なプラットフォーム、たとえば、クラウドインフラストラクチャ上でインスタンス化される仮想化された機能としてのいずれかで実装され得る。

図１６
図１６は、本開示のいくつかの実施形態による、ネットワークノード１６００の概略ブロック図である。随意の特徴が、点線ボックスによって表される。ネットワークノード１６００は、たとえば、ＮＦ（たとえば、ＡＭＦ１４００、ＳＭＦ１４０８、またはＮＳＡＣＦ１５０４）を実装するコアネットワークノード、またはＮＦの機能の全部または一部（たとえば、本明細書で説明されるＡＭＦ１４００、ＳＭＦ１４０８、またはＮＳＡＣＦ１５０４の機能の全部または一部）を実装するネットワークノードであり得る。図示のように、ネットワークノード１６００は、１つまたは複数のプロセッサ１６０４（たとえば、中央処理ユニット（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）など）と、メモリ１６０６と、ネットワークインターフェース１６０８とを含む。１つまたは複数のプロセッサ１６０４は、本明細書では処理回路とも呼ばれる。１つまたは複数のプロセッサ１６０４は、本明細書で説明されるネットワークノード１６００の１つまたは複数の機能（たとえば、本明細書で説明されるＡＭＦ１４００、ＳＭＦ１４０８、またはＮＳＡＣＦ１５０４のうちの１つまたは複数の機能）を提供するように動作する。いくつかの実施形態では、（１つまたは複数の）機能は、たとえば、メモリ１６０６に記憶され、１つまたは複数のプロセッサ１６０４によって実行される、ソフトウェアで実装される。ネットワークノード１６００の例は、図８中のＣＰ－１ ８００と、ＵＰ－１ ８０２と、ＵＰ－２ ８０４とを含み得る。

図１７
図１７は、本開示のいくつかの実施形態による、ネットワークノード１６００の仮想化された実施形態を示す概略ブロック図である。ここでも、随意の特徴が、点線ボックスによって表される。本明細書で使用される「仮想化された」ネットワークノードは、ネットワークノード１６００の機能の少なくとも一部分が、（たとえば、（１つまたは複数の）ネットワークにおける（１つまたは複数の）物理処理ノード上で実行する（１つまたは複数の）仮想マシンを介して）（１つまたは複数の）仮想構成要素として実装されるネットワークノード１６００の一実装形態である。図示のように、この例では、ネットワークノード１６００は、（１つまたは複数の）ネットワーク１７０２に結合されるか、または（１つまたは複数の）ネットワーク１７０２の一部として含まれる、１つまたは複数の処理ノード１７００を含む。各処理ノード１７００は、１つまたは複数のプロセッサ１７０４（たとえば、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡなど）と、メモリ１７０６と、ネットワークインターフェース１７０８とを含む。この例では、本明細書で説明されるネットワークノード１６００の機能１７１０（たとえば、本明細書で説明されるＡＭＦ１４００、ＳＭＦ１４０８、またはＮＳＡＣＦ１５０４のうちの１つまたは複数の機能）は、１つまたは複数の処理ノード１７００において実装されるか、または２つまたはそれ以上の処理ノード１７００にわたって任意の所望の様式で分散される。いくつかの特定の実施形態では、本明細書で説明されるネットワークノード１６００の機能１７１０の一部または全部は、（１つまたは複数の）処理ノード１７００によってホストされる（１つまたは複数の）仮想環境において実装される１つまたは複数の仮想マシンによって実行される仮想構成要素として実装される。

いくつかの実施形態では、少なくとも１つのプロセッサによって実行されたとき、本明細書で説明される実施形態のうちのいずれかに従って、少なくとも１つのプロセッサに、仮想環境におけるネットワークノード１６００の機能１７１０のうちの１つまたは複数を実装するネットワークノード１６００またはノード（たとえば、処理ノード１７００）の機能を行わせる命令を含むコンピュータプログラムが提供される。いくつかの実施形態では、上述のコンピュータプログラム製品を備えるキャリアが提供される。キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体（たとえば、メモリなど、非一時的コンピュータ可読媒体）のうちの１つである。

図１８
図１８は、本開示のいくつかの他の実施形態による、ネットワークノード１６００の概略ブロック図である。ネットワークノード１６００は、１つまたは複数のモジュール１８００を含み、その各々はソフトウェアで実装される。（１つまたは複数の）モジュール１８００は、本明細書で説明されるネットワークノード１６００の機能を提供する。この説明は、モジュール１８００が処理ノード１７００のうちの１つにおいて実装されるか、または複数の処理ノード１７００にわたって分散され得る、図１７の処理ノード１７００に等しく適用可能である。

本明細書で説明されるコンピューティングデバイス（たとえば、ＵＥ、ネットワークノード、ホスト）は、ハードウェア構成要素の示されている組合せを含み得るが、他の実施形態は、構成要素の異なる組合せをもつコンピューティングデバイスを備え得る。これらのコンピューティングデバイスが、本明細書で開示されるタスク、特徴、機能および方法を実施するために必要とされるハードウェアおよび／またはソフトウェアの任意の好適な組合せを備え得ることを理解されたい。本明細書で説明される決定すること、計算すること、取得すること、または同様の動作は、処理回路によって実施され得、処理回路は、たとえば、取得された情報を他の情報に変換すること、取得された情報または変換された情報をネットワークノードに記憶された情報と比較すること、ならびに／あるいは、取得された情報または変換された情報に基づいて、および前記処理が決定を行ったことの結果として、１つまたは複数の動作を実施することによって情報を処理し得る。その上、構成要素が、より大きいボックス内に位置する単一のボックスとして、または複数のボックス内で入れ子にされている単一のボックスとして図示されているが、実際には、コンピューティングデバイスは、単一の示されている構成要素を組成する複数の異なる物理構成要素を備え得、機能が、別個の構成要素間で区分され得る。たとえば、通信インターフェースは、本明細書で説明される構成要素のうちのいずれかを含むように設定され得、および／または、それらの構成要素の機能は、処理回路と通信インターフェースとの間で区分され得る。別の例では、そのような構成要素のうちのいずれかの非計算集約的機能が、ソフトウェアまたはファームウェアで実装され得、計算集約的機能がハードウェアで実装され得る。

いくつかの実施形態では、本明細書で説明される機能の一部または全部は、メモリに記憶された命令を実行する処理回路によって提供され得、メモリは、いくつかの実施形態では、非一時的コンピュータ可読記憶媒体の形態のコンピュータプログラム製品であり得る。代替実施形態では、機能の一部または全部は、ハードワイヤード様式などで、別個のまたは個別のデバイス可読記憶媒体に記憶された命令を実行することなしに、処理回路によって提供され得る。それらの特定の実施形態のいずれでも、非一時的コンピュータ可読記憶媒体に記憶された命令を実行するか否かにかかわらず、処理回路は、説明される機能を実施するように設定され得る。そのような機能によって提供される利益は、処理回路単独に、またはコンピューティングデバイスの他の構成要素に限定されないが、全体としてコンピューティングデバイスによって、ならびに／または概してエンドユーザおよび無線ネットワークによって、享受される。

いくつかの実施形態の概要
上記で説明された実施形態のうちのいくつかは、以下の様式で要約され得る。

１． 通信ネットワーク（１３０２）において制御プレーン機能（ＣＰ－１）（８００）によって実施される方法であって、ＣＰ－１（８００）が管理しているプロトコルデータユニット（ＰＤＵ）セッションのためのユーザプレーン経路においてユーザプレーン（ＵＰ）機能の再開始を管理するためのものであり、方法は、
・ ＵＰ機能（ＵＰ－１）（８０２）から、別のＵＰ機能（ＵＰ－２）（８０４）が再開始した、に関係する報告を含むパケットフォワーディング制御プロトコル（ＰＦＣＰ）メッセージを受信すること（図９、９００）と、
・ 報告に確認応答すること（図９、９０２）と、
・ 別のＵＰ－２（８０４）の識別情報に基づいてアクションを実施すること（図９、９０４）と
を含む、方法。

２． ＵＰ－２（８０４）の識別情報が無線アクセスノード（ＲＡＮ）または新世代（ＮＧ）－ＲＡＮノードであり、アクションが、影響を及ぼされるＰＤＵセッションのためのユーザプレーン接続を復旧すること（図９、９０４Ａ）である、実施形態１に記載の方法。

３． ＵＰ－２（８０４）の識別情報がＰＳＡ ＵＤＦまたはＰＧＷ－Ｕであり、アクションが、影響を及ぼされるＰＤＵセッションを解放すること（図９、９０４Ｂ）である、実施形態１に記載の方法。

４． ＰＦＣＰメッセージがＰＦＣＰノード報告要求メッセージである、実施形態１から３のいずれか１つに記載の方法。

５． 報告は、ＵＰ－１（８０２）が、影響を及ぼされるＰＦＣＰセッションについて、ＵＰ－２（８０４）によって割り当てられたリモートＦ－ＴＥＩＤを除去し、ＦＡＲにおける適用アクションをバッファリングに変更したという指示を含む、実施形態１から４のいずれか１つに記載の方法。

６． ＣＰ－１（８００）が、（ａ）サービングゲートウェイ制御プレーン機能（ＳＧＷ－Ｃ）と、（ｂ）パケットデータネットワーク（ＰＤＮ）ゲートウェイ制御プレーン機能（ＰＧＷ－Ｃ）と、（ｃ）セッション管理機能（ＳＭＦ）とのうちの１つまたは複数において実装される、実施形態１から５のいずれか１つに記載の方法。

７． 通信ネットワーク（１３０２）において、制御プレーン機能（ＣＰ－１）（８００）および第２のユーザプレーン機能（ＵＰ－２）（８０４）と通信する第１のユーザプレーン機能（ＵＰ－１）（８０２）によって実施される方法であって、ピアＵＰ機能再開始を管理するためのものであり、方法は、
・ ＵＰ－２（８０４）にエコー要求を送信すること（図１０、１０００）と、
・ ＵＰ－２（８０４）からエコー応答を受信すること（図１０、１００２）と、
・ ＵＰ－２（８０４）からエコー要求を受信すること（図１０、１００４）と、
・ ＵＰ－２（８０４）にエコー応答を送信すること（図１０、１００６）と、
・ 回復タイムスタンプを含んでいるＧＴＰエラー指示を受信すること（図１０、１００８）と、
・ ＧＴＰエラー指示中で受信された回復タイムスタンプを、エコー要求、エコー応答またはＧＴＰエラー指示を介して前に受信された回復タイムスタンプと比較すること（図１０、１０１０）と、
・ ＵＰ－２（８０４）が再開始したと決定すること（図１０、１０１２）と、
・ 再開始したＵＰ－２（８０４）にさらなるペイロードを送信することを停止すること（図１０、１０１４）と、
・ ＵＰ－２（８０４）によって割り当てられたＦ－ＴＥＩＤを除去し、適用アクションをバッファリングに変更すること（図１０、１０１６）と、
・ ＵＰ－２（８０４）の再開始を報告するようにとのＰＦＣＰ要求メッセージを送信すること（図１０、１０１８）と、
・ ＰＦＣＰ応答メッセージを受信すること（図１０、１０２０）と
を含む、方法。

８． ＵＰ－１（８０２）によって送信されたエコー要求が回復タイムスタンプを含む、実施形態７に記載の方法。

９． ＵＰ－１（８０２）が、（ａ）新無線（Ｎｅｗ Ｒａｄｉｏ：ＮＲ）ノードＢ（ｇＮＢ）と、（ｂ）エボルブドノードＢ（ｅＮＢ）と、（ｃ）サービングゲートウェイ制御プレーン機能（ＳＧＷ－Ｕ）と、（ｄ）パケットデータネットワーク（ＰＤＮ）ゲートウェイ制御プレーン機能（ＰＧＷ－Ｕ）と、（ｅ）中間ユーザプレーン機能（Ｉ－ＵＰＦ）と、（ｆ）訪問ユーザプレーン機能（Ｖ－ＵＰＦ）と、（ｇ）プロトコルデータユニット（ＰＤＵ）セッションアンカー（ＰＳＡ）ＵＰＦとのうちの１つまたは複数において実装される、実施形態７または８に記載の方法。

１０． ＵＰ－１（８０２）によって送信されたエコー要求が、ＵＰ－１（８０２）によって送信されたエコー要求のソースＩＰアドレスによって識別される、ＵＰ－１（８０２）の回復情報を含む、実施形態７から９のいずれか１つに記載の方法。

１１． ＵＰ－１（８０２）によって受信されたエコー応答が、ＵＰ－１（８０２）によって受信されたエコー応答のリソースＩＰアドレスによって識別される、ＵＰ－２（８０４）の回復情報を含む、実施形態７から１０のいずれか１つに記載の方法。

１２． ＰＦＣＰ要求メッセージがＰＦＣＰノード報告要求メッセージである、実施形態７から１１のいずれか１つに記載の方法。

１３． ＰＦＣＰノード報告要求メッセージは、ＵＰ－２（８０４）が再開始したこと、およびＩＰアドレスのリストに関連するＧＴＰ－Ｕコンテキストが失われたことを指示する、実施形態１２に記載の方法。

１４． ＰＦＣＰノード報告応答メッセージは、すべての影響を及ぼされるＰＦＣＰセッションにおけるダウンリンクＦＡＲが、適用アクションがバッファリングにセットされて、更新され、リモートＦ－ＴＥＩＤが除去されたという確認応答を含む、実施形態１２に記載の方法。

１５． 通信ネットワーク（１３０２）において、制御プレーン機能（ＣＰ－１）（８００）および第１のユーザプレーン機能（ＵＰ－１）（８０２）と通信する第２のユーザプレーン機能（ＵＰ－２）（８０４）によって実施される方法であって、ＵＰ機能の再開始を管理するためのものであり、方法が、
・ ＵＰ－１（８０２）にエコー要求を送信すること（図１１、１１００）と、
・ ＵＰ－１（８０２）からエコー応答を受信すること（図１１、１１０２）と、
・ ＵＰ－１（８０２）からエコー要求を受信すること（図１１、１１０４）と、
・ ＵＰ－１（８０２）にエコー応答を送信すること（図１１、１１０６）と、
・ 新しい回復タイムスタンプを含むＧＴＰエラー指示を送信すること（図１１、１１０８）と
を含む、方法。

１６． ＵＰ－２（８０４）によって送信されたエコー要求が回復タイムスタンプを含む、実施形態１５に記載の方法。

１７． ＵＰ－２（８０４）が、（ａ）新無線（ＮＲ）ノードＢ（ｇＮＢ）と、（ｂ）エボルブドノードＢ（ｅＮＢ）と、（ｃ）サービングゲートウェイ制御プレーン機能（ＳＧＷ－Ｕ）と、（ｄ）パケットデータネットワーク（ＰＤＮ）ゲートウェイ制御プレーン機能（ＰＧＷ－Ｕ）と、（ｅ）中間ユーザプレーン機能（Ｉ－ＵＰＦ）と、（ｆ）訪問ユーザプレーン機能（Ｖ－ＵＰＦ）と、（ｇ）プロトコルデータユニット（ＰＤＵ）セッションアンカー（ＰＳＡ）ＵＰＦとのうちの１つまたは複数において実装される、実施形態１５または１６に記載の方法。

１８． 制御プレーン機能（ＣＰ－１）（８００）を実装するネットワークノード（１３０８）であって、
・ ＵＰ－１（８０２）から、ＵＰ－２（８０４）が再開始した、に関係する報告を含むパケットフォワーディング制御プロトコル（ＰＦＣＰ）メッセージを受信すること（図９、９００）と、
・ 報告に確認応答すること（図９、９０２）と、
・ ＵＰ－２（８０４）の識別情報に基づいてアクションを実施すること（図９、９０４）と
を行うように適応された、ネットワークノード（１３０８）。

１９． ネットワークノード（１６００）が、実施形態２から６のいずれか１つに記載の方法を実施するようにさらに適応された、実施形態１８に記載の、ＣＰ－１（８００）を実装するネットワークノード（１６００）。

２０． 制御プレーン機能（ＣＰ－１）（８００）を実装するネットワークノード（１６００）であって、ネットワークノード（１６００）が処理回路を備え、処理回路は、ネットワークノード（１６００）に、
・ ＵＰ－１（８０２）から、ＵＰ－２（８０４）が再開始した、に関係する報告を含むパケットフォワーディング制御プロトコル（ＰＦＣＰ）メッセージを送信する受信すること（図９、９００）と、
・ 報告に確認応答すること（図９、９０２）と、
・ ＵＰ－２（８０４）の識別情報に基づいてアクションを実施すること（図９、９０４）と
を行わせるように設定された、ネットワークノード（１６００）。

２１． 処理回路が、ネットワークノード（１６００）に、実施形態２から６のいずれか１つに記載の方法を実施させるようにさらに設定された、実施形態２０に記載の、ＣＰ－１（８００）を実装するネットワークノード（１６００）。

２２． 第１のユーザプレーン機能（ＵＰ－１）（８０２）を実装するネットワークノード（１６００）であって、
・ ＵＰ－２（８０４）にエコー要求を送信すること（図１０、１０００）と、
・ ＵＰ－２（８０４）からエコー応答を受信すること（図１０、１００２）と、
・ ＵＰ－２（８０４）からエコー要求を受信すること（図１０、１００４）と、
・ ＵＰ－２（８０４）にエコー応答を送信すること（図１０、１００６）と、
・ 回復タイムスタンプを含んでいるＧＴＰエラー指示を受信すること（図１０、１００８）と、
・ ＧＴＰエラー指示中で受信された回復タイムスタンプを、エコー要求、エコー応答またはＧＴＰエラー指示を介して前に受信された回復タイムスタンプと比較すること（図１０、１０１０）と、
・ ＵＰ－２（８０４）が再開始したと決定すること（図１０、１０１２）と、
・ 再開始したＵＰ－２（８０４）にさらなるペイロードを送信することを停止すること（図１０、１０１４）と、
・ ＵＰ－２（８０４）によって割り当てられたＦ－ＴＥＩＤを除去し、適用アクションをバッファリングに変更すること（図１０、１０１６）と、
・ 第２のＵＰ機能の再開始を報告するようにとのＰＦＣＰ要求メッセージを送信すること（図１０、１０１８）と、
・ ＰＦＣＰ応答メッセージを受信すること（図１０、１０２０）と
を行うように適応された、ネットワークノード（１６００）。

２３． ネットワークノード（１６００）が、実施形態８から１４のいずれか１つに記載の方法を実施するようにさらに適応された、実施形態２２に記載の、ＵＰ－１（８０２）を実装するネットワークノード（１６００）。

２４． 第１のユーザプレーン機能（ＵＰ－１）（８０２）を実装するネットワークノード（１６００）であって、ネットワークノード（１６００）が処理回路を備え、処理回路は、ネットワークノード（１６００）に、
・ ＵＰ－２（８０４）にエコー要求を送信すること（図１０、１０００）と、
・ ＵＰ－２（８０４）からエコー応答を受信すること（図１０、１００２）と、
・ ＵＰ－２（８０４）からエコー要求を受信すること（図１０、１００４）と、
・ ＵＰ－２（８０４）にエコー応答を送信すること（図１０、１００６）と、
・ 回復タイムスタンプを含んでいるＧＴＰエラー指示を受信すること（図１０、１００８）と、
・ ＧＴＰエラー指示中で受信された回復タイムスタンプを、エコー要求、エコー応答またはＧＴＰエラー指示を介して前に受信された回復タイムスタンプと比較すること（図１０、１０１０）と、
・ ＵＰ－２（８０４）が再開始したと決定すること（図１０、１０１２）と、
・ 再開始したＵＰ－２（８０４）にさらなるペイロードを送信することを停止すること（図１０、１０１４）と、
・ ＵＰ－２（８０４）によって割り当てられたＦ－ＴＥＩＤを除去し、適用アクションをバッファリングに変更すること（図１０、１０１６）と、
・ 第２のＵＰ機能の再開始を報告するようにとのＰＦＣＰ要求メッセージを送信すること（図１０、１０１８）と、
・ ＰＦＣＰ応答メッセージを受信すること（図１０、１０２０）と
を行わせるように設定された、ネットワークノード（１６００）。

２５． 処理回路が、ネットワークノード（１６００）に、実施形態８から１４のいずれか１つに記載の方法を実施させるようにさらに設定された、実施形態２４に記載の、ＵＰ－１（８０２）を実装するネットワークノード（１６００）。

２６． 第２のユーザプレーン機能（ＵＰ－２）（８０４）を実装するネットワークノード（１６００）であって、
・ ＵＰ－１（８０２）にエコー要求を送信すること（図１１、１１００）と、
・ ＵＰ－１（８０２）からエコー応答を受信すること（図１１、１１０２）と、
・ ＵＰ－１（８０２）からエコー要求を受信すること（図１１、１１０４）と、
・ ＵＰ－１（８０２）にエコー応答を送信すること（図１１、１１０６）と、
・ 新しい回復タイムスタンプを含むＧＴＰエラー指示を送信すること（図１１、１１０８）と
を行うように適応された、ネットワークノード（１６００）。

２７． ネットワークノード（１６００）が、実施形態１６または１７に記載の方法を実施するようにさらに適応された、実施形態２６に記載の、ＵＰ－２（８０４）を実装するネットワークノード（１６００）。

２８． 第２のユーザプレーン機能（ＵＰ－２）（８０４）を実装するネットワークノード（１６００）であって、ネットワークノード（１６００）が処理回路を備え、処理回路が、ネットワークノード（１６００）に、
・ ＵＰ－１（８０２）にエコー要求を送信すること（図１１、１１００）と、
・ ＵＰ－１（８０２）からエコー応答を受信すること（図１１、１１０２）と、
・ ＵＰ－１（８０２）からエコー要求を受信すること（図１１、１１０４）と、
・ ＵＰ－１（８０２）にエコー応答を送信すること（図１１、１１０６）と、
・ 新しい回復タイムスタンプを含むＧＴＰエラー指示を送信すること（図１１、１１０８）と
を行わせるように設定された、ネットワークノード（１６００）。

２９． 処理回路が、ネットワークノード（１６００）に、実施形態２７または２８に記載の方法を実施させるようにさらに設定された、実施形態２８に記載の、ＵＰ－２（８０４）を実装するネットワークノード（１６００）。

３０． 通信ネットワーク（１３０２）において、制御プレーン機能（ＣＰ－１）（８００）と、第１のユーザプレーン機能（ＵＰ－１）（８０２）と、第２のユーザプレーン機能（ＵＰ－２）（８０４）とによって実施される方法であって、ピアＵＰ機能再開始を管理するためのものであり、方法は、
・ ＣＰ－１（８００）において、
〇 ＵＰ－１（８０２）から、ＵＰ－２（８０４）が再開始した、に関係する報告を含むパケットフォワーディング制御プロトコル（ＰＦＣＰ）要求メッセージを受信すること（図１２、１２０８）と、
〇 ＰＦＣＰ応答メッセージを送信することによって報告に確認応答すること（図１２、１２１０）と、
〇 ＵＰ－２（８０４）の識別情報に基づいてアクションを実施すること（図１２、１２１２）と、
・ ＵＰ－１（８０２）において、
〇 ＵＰ－２（８０４）にエコー要求を送信すること（図１２、１２００）と、
〇 ＵＰ－２（８０４）からエコー応答を受信すること（図１２、１２００）と、
〇 ＵＰ－２（８０４）からエコー要求を受信すること（図１２、１２０２）と、
〇 ＵＰ－２（８０４）にエコー応答を送信すること（図１２、１２０２）と、
〇 回復タイムスタンプを含んでいるＧＴＰエラー指示を受信すること（図１２、１２０４）と、
〇 ＧＴＰエラー指示中で受信された回復タイムスタンプを、エコー要求、エコー応答またはＧＴＰエラー指示を介して前に受信された回復タイムスタンプと比較すること（図１２、１２０６Ａ）と、
〇 ＵＰ－２（８０４）が再開始したと決定すること（図１２、１２０６Ｂ）と、
〇 再開始したＵＰ－２（８０４）にさらなるペイロードを送信することを停止すること（図１２、１２０６Ｃ）と、
〇 ＵＰ－２（８０４）によって割り当てられたＦ－ＴＥＩＤを除去し、適用アクションをバッファリングに変更すること（図１２、１２０６Ｄ）と、
〇 ＵＰ－２（８０４）の再開始を報告するようにとのＰＦＣＰ要求メッセージを送信すること（図１２、１２０８）と、
〇 ＰＦＣＰ応答メッセージを受信すること（図１２、１２１０）と、
・ ＵＰ－２（８０４）において、
〇 ＵＰ－１（８０２）にエコー要求を送信すること（図１２、１２０２）と、
〇 ＵＰ－１（８０２）からエコー応答を受信すること（図１２、１２０２）と、
〇 ＵＰ－１（８０２）からエコー要求を受信すること（図１２、１２００）と、
〇 ＵＰ－１（８０２）にエコー応答を送信すること（図１２、１２００）と、
〇 新しい回復タイムスタンプを含むＧＴＰエラー指示を送信すること（図１２、１２０４）と
を含む、方法。

３１． ＵＰ－２（８０４）の識別情報が無線アクセスノード（ＲＡＮ）または新世代（ＮＧ）－ＲＡＮノードであり、アクションが、影響を及ぼされるＰＤＵセッションのためのユーザプレーン接続を復旧すること（図９、９０４Ａ）である、実施形態３０に記載の方法。

３２． ＵＰ－２（８０４）の識別情報がＰＳＡ ＵＤＦまたはＰＧＷ－Ｕであり、アクションが、影響を及ぼされるＰＤＵセッションを解放すること（図９、９０４Ｂ）である、実施形態３０に記載の方法。

３３． 通信ネットワーク（１３０２）において、制御プレーン機能（ＣＰ－１）（８００）と、第１のユーザプレーン機能（ＵＰ－１）（８０２）と、第２のユーザプレーン機能（ＵＰ－２）（８０４）とによって実施される方法であって、ＵＰ－２（８０４）の再開始を検出することと、ユーザプレーン経路を復旧するために、再開始をＣＰ－１（８００）に報告することとを行うためのものであり、方法は、
・ ＵＰ－２（８０４）において、
〇 ＵＰ－２（８０４）の再開始の後にＵＰ－１（８０２）に汎用パケット無線サービストンネリングプロトコル（ＧＴＰ）エラー指示メッセージを送信すること（図８、８１４）と、
・ ＵＰ－１（８０２）において、
〇 ＣＰ－１（８００）にＰＦＣＰノード報告要求メッセージを送信すること（図８、８１６）と、
・ ＣＰ－１（８００）において、
〇 ＵＰ－１（８０２）からＰＦＣＰノード報告要求メッセージを受信した後に、ＵＰ－２（８０４）の再開始によって影響を及ぼされるプロトコルデータユニット（ＰＤＵ）セッションを解放すること（図８、８２０）と
を含む、方法。

３４． ・ ＵＰ－１（８０２）において、
〇 ＵＰ－２（８０４）にエコー要求を送信すること（図８、８１０）と、
〇 ＵＰ－２（８０４）からエコー応答を受信すること（図８、８１０）と、
〇 ＧＴＰエラー指示メッセージを受信すること（図８、８１４）と、
・ ＵＰ－２（８０４）において、
〇 ＵＰ－１（８０２）にエコー要求を送信すること（図８、８１２）と、
〇 ＵＰ－１（８０２）からエコー応答を受信すること（図８、８１２）と、
・ ＵＰ－１（８０２）において、
〇 ＣＰ－１（８００）からＰＦＣＰノード報告応答メッセージを受信すること（図８、８１８）と
をさらに含む、実施形態３３に記載の方法。

３５． ＵＰ－１（８０２）によって送信されたエコー要求が、ＵＰ－１（８０２）によって送信されたエコー要求のソースＩＰアドレスによって識別される、ＵＰ－１（８０２）の回復情報を含む、実施形態３４に記載の方法。

３６． ＵＰ－１（８０２）によって受信されたエコー応答が、ＵＰ－１（８０２）によって受信されたエコー応答のリソースＩＰアドレスによって識別される、ＵＰ－２（８０４）の回復情報を含む、実施形態３４に記載の方法。

３７． ＣＰ－１（８００）が、（ａ）サービングゲートウェイ制御プレーン機能（ＳＧＷ－Ｃ）と、（ｂ）パケットデータネットワーク（ＰＤＮ）ゲートウェイ制御プレーン機能（ＰＧＷ－Ｃ）と、（ｃ）セッション管理機能（ＳＭＦ）とのうちの１つまたは複数において実装される、実施形態３３から３６のいずれか１つに記載の方法。

３８． ＵＰ－１（８０２）が、（ａ）新無線（ＮＲ）ノードＢ（ｇＮＢ）と、（ｂ）エボルブドノードＢ（ｅＮＢ）と、（ｃ）サービングゲートウェイ制御プレーン機能（ＳＧＷ－Ｕ）と、（ｄ）パケットデータネットワーク（ＰＤＮ）ゲートウェイ制御プレーン機能（ＰＧＷ－Ｕ）と、（ｅ）中間ユーザプレーン機能（Ｉ－ＵＰＦ）と、（ｆ）訪問ユーザプレーン機能（Ｖ－ＵＰＦ）と、（ｇ）プロトコルデータユニット（ＰＤＵ）セッションアンカー（ＰＳＡ）ＵＰＦとのうちの１つまたは複数において実装される、実施形態３３から３７のいずれか１つに記載の方法。

３９． ＵＰ－２（８０４）が、（ａ）新無線（ＮＲ）ノードＢ（ｇＮＢ）と、（ｂ）エボルブドノードＢ（ｅＮＢ）と、（ｃ）サービングゲートウェイ制御プレーン機能（ＳＧＷ－Ｕ）と、（ｄ）パケットデータネットワーク（ＰＤＮ）ゲートウェイ制御プレーン機能（ＰＧＷ－Ｕ）と、（ｅ）中間ユーザプレーン機能（Ｉ－ＵＰＦ）と、（ｆ）訪問ユーザプレーン機能（Ｖ－ＵＰＦ）と、（ｇ）プロトコルデータユニット（ＰＤＵ）セッションアンカー（ＰＳＡ）ＵＰＦとのうちの１つまたは複数において実装される、実施形態３３から３８のいずれか１つに記載の方法。

４０． ＧＴＰエラー指示メッセージが回復情報を含む、実施形態３３から３９のいずれか１つに記載の方法。

４１． ＧＴＰエラー指示メッセージが、ＵＰ－２（８０４）の再開始によって影響を及ぼされるＩＰアドレスのリストをさらに含む、実施形態４０のいずれか１つに記載の方法。

４２． ＰＦＣＰノード報告要求メッセージは、ＵＰ－２（８０４）が再開始したこと、およびＩＰアドレスのリストに関連するＧＴＰ－Ｕコンテキストが失われたことを指示する、実施形態３３から４１のいずれか１つに記載の方法。

４３． ＰＦＣＰノード報告応答メッセージは、すべての影響を及ぼされるＰＦＣＰセッションにおけるダウンリンクＦＡＲが、適用アクションがバッファリングにセットされて、更新され、リモートＦ－ＴＥＩＤが除去されたという確認応答を含む、実施形態３３から４１のいずれか１つに記載の方法。

略語
以下の略語のうちの少なくともいくつかが本開示で使用され得る。略語間の不整合がある場合、その略語が上記でどのように使用されるかが選好されるべきである。以下で複数回リストされる場合、最初のリスティングが（１つまたは複数の）後続のリスティングよりも選好されるべきである。
２Ｇ 第２世代
３Ｇ 第３世代
３ＧＰＰ 第３世代パートナーシッププロジェクト
４Ｇ 第４世代
５Ｇ 第５世代
５ＧＳ 第５世代システム
６Ｇ 第６世代
ＡＭＦ アクセスおよびモビリティ管理機能
ＡＰ アクセスポイント
ＢＳ 基地局
ＢＳＣ 基地局コントローラ
ＢＴＳ 基地トランシーバ局
ＤＬ ダウンリンク
ｅＮＢ エボルブドノードＢ
Ｅ－ＵＴＲＡ 拡張ユニバーサル地上無線アクセス
Ｅ－ＵＴＲＡＮ エボルブドＵｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ地上無線アクセスネットワーク
Ｆ－ＴＥＩＤ 完全修飾トンネルエンドポイント識別子
ｇＮＢ ＮＲノードＢ
ＧＰＲＳ 汎用パケット無線サービス
ＧＳＭ Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ
ＧＴＰ 汎用パケット無線サービストンネリングプロトコル
ＨＳＳ ホーム加入者サーバ
ＩｏＴ モノのインターネット
Ｉ－ＵＰＦ 中間ユーザプレーン機能
ＬＴＥ Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ
ＭＭＥ モビリティ管理エンティティ
ＭＳＣ モバイルスイッチングセンタ
ＭＴＣ マシン型通信
ＮＥＦ ネットワーク公開機能
ＮＦＶ ネットワーク機能仮想化
ＮＲ 新無線
Ｏ＆Ｍ 運用保守
ＯＳＳ 運用サポートシステム
ＯＴＴ オーバーザトップ
ＰＤＮ パケットデータネットワーク
ＰＤＵ プロトコルデータユニット
ＰＦＣＰ パケットフォワーディング制御プロトコル
ＰＧＷ パケットゲートウェイ
ＰＧＷ－Ｃ パケットデータネットワーク（ＰＤＮ）ゲートウェイ制御プレーン機能
ＰＬＭＮ パブリックランドモバイルネットワーク
ＲＡＮ 無線アクセスネットワーク
ＲＡＴ 無線アクセス技術
ＲＮＣ 無線ネットワークコントローラ
ＳＧＷ サービングゲートウェイ
ＳＧＷ－Ｃ サービングゲートウェイ制御プレーン機能
ＳＭＦ セッション管理機能
ＴＣＰ／ＩＰ 伝送制御プロトコル／インターネットプロトコル
ＵＥ ユーザ機器
ＵＬ アップリンク
ＵＭＴＳ Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ
ＵＰＦ ユーザプレーン機能
ＵＳＩＭ ユニバーサル加入者識別モジュール
ＷＣＤＭＡ 広帯域符号分割多重接続
ＷＬＡＮ ワイドローカルエリアネットワーク
付録１
３ＧＰＰ ＴＳＧ－ＣＴ ＷＧ４会議＃１０７－ｅ Ｃ４－２１６ｘｙｚ
電子会議、２０２１年１１月１５日～１１月２５日
この書式を使用することに関するヘルプについて:以下で包括的なインストラクションを見つけることができる。
http://www.3gpp.org/Change-Requests
１８Ａ ＧＴＰ－Ｕベース再開始プロシージャ
ＧＴＰ－Ｕベースインターフェース、すなわち、ＥＰＳにおけるエボルブドパケットシステムのＳ１－Ｕ、Ｓ１１－Ｕ、Ｓ２ａ、Ｓ２ｂ、Ｘ２、Ｓ４、Ｓ５、Ｓ８、Ｓ１２、Ｍ１およびＳｎインターフェース、ならびに５ＧＳにおける５ＧシステムのＦ１－Ｕ、Ｘｎ、Ｎ３、Ｎ９、Ｎ１９、Ｎ３ｍｂおよびＮ１９ｍｂインターフェースにわたって、ＧＴＰ－Ｕエンティティが、再開始を検出およびハンドリングするために、回復タイムスタンプ情報エレメントを含んでいる、ＧＴＰ－Ｕエコー要求およびエコー応答メッセージまたはＧＴＰ－Ｕエラー指示メッセージを利用し得る。
ＧＴＰ－Ｕエンティティは、（知られていないピアからさえ）任意の時間においてエコー要求メッセージを受信する準備ができているものとし、ＧＴＰ－Ｕエンティティは、エコー応答メッセージで返答するものとする。
ＧＴＰ－Ｕエンティティは、２つの回復タイムスタンプ：
－ 揮発性メモリにおける、そのエンティティが接触しているピアＧＴＰ－Ｕエンティティのリモート回復タイムスタンプ、
－ または、不揮発性メモリ自体における、ピアＧＴＰ－Ｕエンティティに送信されたローカル回復タイムスタンプ
を維持するものとする。
ＧＴＰ－Ｕエンティティが（再）開始した後に、ＧＴＰ－Ｕエンティティは、すべてのローカル回復タイムスタンプを直ちに更新するものとし、すべてのリモート回復タイムスタンプをクリアするものとする。ピアＧＴＰ－Ｕエンティティ情報が利用可能であるとき、たとえば、ピアＧＴＰ－Ｕエンティティに向かう第１のＧＴＰ－Ｕトンネルが確立されるべきであるとき、（再）開始したＧＴＰ－Ｕエンティティは、ＧＴＰ－Ｕパケットを送信する前に、エコー要求メッセージ中で、ピアＧＴＰ－Ｕエンティティに、（再）開始したＧＴＰ－Ｕエンティティの（更新された）回復タイムスタンプを送信し得る。
ＧＴＰ－Ｕエンティティは、すべてのピアＧＴＰ－Ｕエンティティについて共通のローカル回復タイムスタンプを有し得るか、またはＧＴＰ－Ｕエンティティは、各ピアＧＴＰ－Ｕエンティティについて別個のローカル回復タイムスタンプを有し得る。
ＧＴＰ－Ｕエンティティは、エコー要求メッセージを送信することによって、ＧＴＰ－Ｕエンティティが接触している各ピアＧＴＰ－Ｕエンティティのライブリネスをプローブし得る。
ＧＴＰ－Ｕエコー要求および応答メッセージ中でシグナリングされる回復タイムスタンプは、メッセージのソースＩＰアドレスによって識別されるＧＴＰ－Ｕエンティティに関連する。
ＧＴＰ－Ｕエラー指示中でシグナリングされる回復タイムスタンプは、ＧＴＰ－Ｕエラー指示のソースＩＰアドレスに関連するか、または、同じ回復タイムスタンプを共有している（１つまたは複数の）ＩＰアドレスがＧＴＰ－Ｕエラー指示メッセージ中に明示的に含まれる場合、それらの（１つまたは複数の）ＩＰアドレスのリストに関連する。
ピアＧＴＰ－Ｕエンティティから回復タイムスタンプ情報エレメントを受信するＧＴＰ－Ｕエンティティは、受信されたリモート回復タイムスタンプ値を、そのピアＧＴＰ－Ｕエンティティについて記憶された前の回復タイムスタンプ値と比較するものとする。
－ 前の値が記憶されなかった場合、エコー要求または応答メッセージあるいはＧＴＰエラー指示メッセージ中で受信された回復タイムスタンプ値は、ピアＧＴＰ－Ｕエンティティについて記憶されるものとする。
－ ピアＧＴＰ－Ｕエンティティについて前に記憶された回復タイムスタンプの値が、エコー要求または応答メッセージあるいはＧＴＰ－Ｕエラー指示メッセージ中で受信された回復タイムスタンプよりも小さい場合、これは、エコー要求または応答メッセージあるいはＧＴＰ－Ｕエラー指示メッセージを送信したエンティティが再開始したことを指示する。受信された、新しい回復タイムスタンプ値は、受信エンティティによって記憶され、ピアＧＴＰ－Ｕエンティティについて前に記憶された値に取って代わるものとする。
－ ピアＧＴＰ－Ｕエンティティについて前に記憶された回復タイムスタンプの値が、エコー要求または応答メッセージあるいはＧＴＰ－Ｕエラー指示メッセージ中で受信された回復タイムスタンプ値よりも大きい場合、これは、可能な競合条件（より新しいメッセージがより古いメッセージの前に到着すること）を指示する。受信された新しい回復タイムスタンプ値は廃棄されるものとし、エラーがロギングされ得る。
オペレータのポリシに基づいて、回復タイムスタンプＩＥがピアＧＴＰ－Ｕエンティティからのエコー要求中で受信され、回復タイムスタンプが、ピアＧＴＰ－Ｕエンティティについて前に記憶された回復タイムスタンプの値よりも大きいとき、ＧＴＰ－Ｕエンティティは、ピアＧＴＰ－Ｕエンティティが実際に再開始したかどうかを、
－ ピアＧＴＰ－Ｕエンティティに向けて１つまたは複数のエコー要求メッセージを送信すること、またはピアＧＴＰ－Ｕエンティティからの回復タイムスタンプＩＥを含むＧＴＰ－Ｕエラー指示メッセージを監視することと、
－ エコー応答メッセージ中のまたはＧＴＰ－Ｕエラー指示メッセージ中の回復タイムスタンプが、ピアＧＴＰ－Ｕエンティティについて前に記憶された回復タイムスタンプの値よりも大きい場合、ピアＧＴＰ－Ｕエンティティが再開始したと決定することと
によって、検証し得る。
付録２
３ＧＰＰ ＴＳＧ－ＣＴ ＷＧ４会議＃１０７－ｅ Ｃ４－２１６ａｂｃ
電子会議、２０２１年１１月１５日～１１月２５日
ソース：Ｅｒｉｃｓｓｏｎ
題名： ＧＴＰ－Ｕエンティティ再開始を検出および報告することに関する検討
リリース： Ｒｅｌ－１７
アジェンダアイテム： ６．３．２
文書の目的： 判断
１．序論
本文書は、ＧＴＰ－Ｕエンティティ再開始に関する分析を提供することと、また、効率的なやり方でのそのようなＧＴＰ－Ｕエンティティ再開始の検出および報告の向上を導入するように提案することとを行うためのものである。
２．説明
２．１ ＧＴＰ－Ｕ再開始の検出
約２０年前に、３ＧＰＰは、ユーザプレーンのためのＧＴＰエコー応答メッセージ（ＧＴＰ－Ｕ）から回復の使用を除去することを判断し、その回復は、ＧＴＰエンティティのための再開始カウンタとして規定され、当時、ＧＴＰエンティティは、制御プレーン部分とユーザプレーン部分とを備えるので、制御プレーンシグナリング経路とユーザプレーンペイロード経路の両方を介してＧＴＰエンティティのための再開始カウンタを通信することが、冗長である。
ＧＴＰ－Ｕメッセージ中の「回復」情報エレメント中の「再開始カウンタ」フィールドの使用が、３ＧＰＰ ＴＳ２９．０６０ Ｒｅｌ－３ ＣＲ０９６［７］を通して２０００年３月に変更され、これは、３ＧＰＰ ＴＳ２９．０６０ Ｖ３．４．０［５］上に書かれており、３ＧＰＰ ＴＳ２９．０６０ Ｖ３．５．０［６］において実装された。ＣＲにおける「変更の理由」は、以下のように読める。
ノードが再開始を経験したことをピアノードに知らせるために、エコー応答メッセージ中の再開始カウンタが使用される。ＧＴＰ－ＵとＧＴＰ－Ｃの両方において再開始カウンタ値を使用することは、ＧＴＰ－Ｃのみにおいて再開始カウンタ値を使用することが十分であるので、不要である。その上、Ｉｕインターフェースにおいて、ＲＡＮＡＰが、ノード再開始のためのプロシージャをすでに有する。
したがって、エコー応答メッセージ中の再開始カウンタ値がＧＴＰ－Ｕにおいて使用されないことが提案される。
ＣＲはまた、エコー応答が受信されたときにどのように反応すべきかのいくつかの明確化を提案する。
３ＧＰＰ Ｒｅｌ－８の前に、ＧＴＰ－Ｕの規範的仕様が、３ＧＰＰ ＴＳ２９．０６０中にＧＴＰｖ１とともに含まれた。３ＧＰＰ Ｒｅｌ－８において、ＧＴＰ－Ｕの規範的仕様は、３ＧＰＰ ＴＳ２９．０６０から３ＧＰＰ ＴＳ２９．２８１［３］に移動された。ＧＴＰ－Ｕに関するテキストは、事実上、３ＧＰＰ ＴＳ２９．０６０［４］に「記載のもの」のままにされ、仕様中の節９の始めに注が追加された。注は、以下のように読める。
リリース８以降から、ＧＴＰバージョン１のユーザプレーンの規範的仕様は３ＧＰＰ ＴＳ２９．２８１［４１］である。本文書中のＧＴＰｖ１ユーザプレーンに関するすべての箇条が、３ＧＰＰ ＴＳ２９．２８１［４１］によって取って代わられるものとする。
したがって、ＴＳ２９．２８１［３］において指定されているように、節７．２．２：
回復情報エレメント中の再開始カウンタ値は使用されないものとし、すなわち、再開始カウンタ値は、送信側によって０にセットされるものとし、受信側によって無視されるものとする。回復情報エレメントは、バックワードコンパチビリティの理由により必須である。
随意のプライベート拡張が、ベンダーまたはオペレータ固有情報を含んでいる。
結論１：ＧＴＰ－Ｕエンティティ再開始の検出を無効にする、ＣＲにおける「変更の理由」において説明された動機付けは、制御プレーン機能とユーザプレーン機能とがＲｅｌ－１４以来分離されたＣＵＰＳのコンテキストにおいて、もはや有効でない。ＣＰ機能およびＵＰ機能は、３ＧＰＰ ＴＳ２３．００７における節１９ａにおいて指定されているように、ＣＰ機能およびＵＰ機能自体の再開始カウンタ／回復タイムスタンプを維持しなければならない。
結論２：そのとき以来、ユーザプレーン機能が、ピアＧＴＰ－Ｕエンティティが再開始したことを検出することを可能にするための、機構がない。したがって、ピアＧＴＰ－Ｕ再開始に関する要件がない。
２．２ リモートＧＴＰ－Ｕエンティティが再開始したときの問題
３ＧＰＰは、３ＧＰＰ ＴＳ２３．００７、節２０．３および３ＧＰＰ ＴＳ２３．５２７、節５．４においてユーザプレーン経路障害（ＧＴＰ－Ｕ経路障害）についての関連のある要件を指定した。以下を参照されたい。
２０．３．１ 概略
ＧＴＰ－Ｕエンティティが、以下のやり方で、エコー要求／エコー応答メッセージを使用することによる、経路障害の検出をサポートするものとする。経路カウンタが、エコー応答が経路上で受信されるたびにリセットされ、経路上で送信されたエコー要求メッセージについてＴ３応答タイマーが満了したときに増分されるものとする。経路は、カウンタがＮ３要求を超える場合、ダウンしていると見なされるものとする。
経路障害を検出すると、ネットワークノードは、運用保守システムを介して障害を通知するべきであり、以下のいずれかを行い得る。
－ 障害のある経路に関連するベアラコンテキストを削除すること、または
－ オペレータ設定可能最大経路障害持続時間中、障害のある経路に関連するベアラコンテキストを維持すること。ネットワークノードは、この持続時間が満了したときに経路が依然としてダウンしている場合、維持されたリソースを削除するものとする。
（オペレータ設定可能最大）経路障害タイマーは、通常、ＧＴＰ－Ｕエンティティの回復時間よりもはるかに大きく、すなわち、経路障害が検出され得る前に、ＧＴＰ－Ｕエンティティは、その再開始から回復している可能性が最も高い。
したがって、ＧＴＰ－Ｕ経路障害中に使用される機構は、たとえば、ＵＰ機能が、ＧＴＰ－Ｕ経路障害を報告するための単一のＰＦＣＰノード報告要求メッセージを使用することが可能である場合、リモートＧＴＰ－Ｕエンティティ再開始のために使用され得ない。
ＧＴＰ－Ｕエンティティが再開始したとき、たとえば、ｇＮＢが再開始したとき、それは、それが再開始から回復し、それがＤＬパケットを受信した後に、すべてのそのＧＴＰ－Ｕコンテキストを失うことになり、ｇＮＢは、（Ｉ／Ｖ－）ＵＰＦからのＤＬ ＧＴＰ－Ｕパケットについての対応するコンテキストを見つけることが可能でなく、したがって、ｇＮＢは、知られていないＤＬ ＧＴＰ－ＵパケットについてのＧＴＰエラー指示を送信するにすぎない。
したがって、その再開始から回復したばかりであるｇＮＢが、（Ｉ／Ｖ－）ＵＰＦに大規模な量のＧＴＰエラー指示メッセージを送信することになり、これは、ＵＰ機能がＧＴＰエラー指示の受信をＣＰ機能（たとえば、（Ｉ／Ｖ－）ＳＭＦ）に報告しなければならないので、Ｓｘ／Ｎ４インターフェース上での大規模な量のシグナリングにつながり、さらに悪いことに、ＣＰ機能は、その後、影響を及ぼされるＰＦＣＰセッションの各々について、再開始したｇＮＢに関連するＤＬ ＴＥＩＤを含んでいるＤＬフォワーディングアクションルールを更新するために、すなわち、（再開始したｇＮＢによって割り当てられた）ＤＬ Ｆ－ＴＥＩＤを除去し、適用アクションを「ＢＵＦＦ」に変更するために、ＰＦＣＰセッション修正プロシージャをトリガする必要がある。（３ＧＰＰ ＴＳ２３．５２７の５．３．２．１において指定されている以下のシグナリングフロー参照、ここで、ステップ３およびステップ４が最適化されるべきである。）
ｇＮＢは、ここでは一例であり、いかなるＧＴＰ－Ｕエンティティも、それが再開始し、ユーザプレーン上のそのＧＴＰ－Ｕエンティティのコンテキストが、たとえば対応する制御プレーンによって復旧され得ないとき、同じ挙動を適用することになる。
ユーザプレーンコンテキストが制御プレーン機能によって復旧され得る場合、ＵＰ機能は、時間期間の間、たとえば中間ＵＰＦ再開始の間、ＧＴＰエラー指示を送信しないことを必要とされることになることに留意されたい。
５．３．２．１ 原理
図５．３．２．１－１：５Ｇ－ＡＮからのＧＴＰ－Ｕエラー指示
１． 既存のＰＤＵセッションのユーザプレーン接続がアクティブ化される。ダウンリンクＧ－ＰＤＵが５Ｇ－ＡＮに向けて送信される。
２． ５Ｇ－ＡＮは、５Ｇ－ＡＮが、対応するＧＴＰ－Ｕコンテキストを有しない場合、ＧＴＰ－Ｕエラー指示を返す（節５．２参照）。
３． ＧＴＰ－Ｕエラー指示の受信時に、ＵＰＦは、３ＧＰＰ ＴＳ２９．２４４［４］の節５．１０において指定されているように、関係するＰＦＣＰセッションを識別し、ＳＭＦにエラー指示報告を送信するものとする。
４． ５Ｇ－ＡＮから受信されたＧＴＰ－Ｕエラー指示について、ＳＭＦは、ダウンリンクパケットをバッファするようにＵＰＦに命令するためにＰＦＣＰセッションを修正するものとする。
結論３：再開始したＧＴＰ－Ｕエンティティは、そのＧＴＰ－Ｕコンテキストが、たとえば制御プレーンによって、復旧され得ない場合、知られていない着信ＧＴＰ－Ｕパケットについての大規模な量のＧＴＰエラー指示メッセージを、それらのＧＴＰ－Ｕパケットを送信するピアユーザプレーン機能に送信することになり、それらのＧＴＰエラー指示メッセージを受信することが、Ｓｘ／Ｎ４インターフェース上でのさらなる大規模シグナリングにつながる。ＧＴＰ－ＵインターフェースおよびＳｘ／Ｎ４インターフェース上でのそのような大規模シグナリングは、回避されるべきである。
３．提案
ＧＴＰ－Ｕインターフェース上でのＧＴＰ－Ｕエンティティ再開始の検出を導入することと、ＰＦＣＰセッション修正プロシージャを回避するために、ＧＴＰ－Ｕ経路障害報告のようなＰＦＣＰノード報告プロシージャを使用してそのようなＧＴＰ－Ｕエンティティ再開始を報告することとを行うことが、提案される。
Ｃ４－２１６ｘｙｚは、ＧＴＰ－Ｕエンティティ再開始の検出について説明するステージ２ ＣＲから開始する。

Claims (4)

1. 通信ネットワーク（１３０２）において制御プレーン機能（ＣＰ）機能（８００）によって実施される方法であって、前記ＣＰ機能（８００）が管理しているプロトコルデータユニット（ＰＤＵ）セッションのためのユーザプレーン経路において第２のユーザプレーン（ＵＰ）機能（８０４）の再開始を管理するためのものであり、前記方法は、
   ・ 第１のＵＰ機能（８０２）から、前記第２のＵＰ機能（８０４）の再開始に関係する報告を含むパケットフォワーディング制御プロトコル（ＰＦＣＰ）ノード報告要求メッセージを受信すること（８１６）であって、前記ＰＦＣＰノード報告要求メッセージは、
   （１）前記第２のＵＰ機能（８０４）が再開始したこと、およびＩＰアドレスのリストに関連するＧＴＰ－Ｕコンテキストが失われたことと、
   （２）前記ＣＰ機能（８００）が、ＰＦＣＰセッションごとにＤＬ ＦＡＲを変更するためにＰＦＣＰセッション修正要求メッセージを送信する必要がないことと
   を指示する、パケットフォワーディング制御プロトコル（ＰＦＣＰ）ノード報告要求メッセージを受信すること（８１６）と、
   ・ 前記ＰＦＣＰノード報告要求メッセージに対する応答として、前記再開始した第２のＵＰ機能（８０４）に関連するすべての影響を及ぼされるＰＦＣＰセッションにおけるダウンリンクＦＡＲが、適用アクションがバッファリングにセットされて、更新され、前記第２のＵＰ機能（８０４）からのリモートＦ－ＴＥＩＤが除去されたという確認応答を含む、ＰＦＣＰノード報告応答メッセージを送信すること（８１８）と、
   ・ ローカル設定に基づいてリモートＧＴＰ－Ｕ再開始によって影響を及ぼされるＰＤＵセッションを解放すること（８２０）と
   を含む、方法。
2. 通信ネットワーク（１３０２）において、制御プレーン（ＣＰ）機能（８００）および第２のユーザプレーン（ＵＰ）機能（８０４）と通信する第１のＵＰ機能（８０２）によって実施される方法であって、前記第２のＵＰ機能（８０４）の再開始を管理するためのものであり、前記方法は、
   ・ 回復タイムスタンプと、前記第２のＵＰ機能（８０４）の再開始によって影響を及ぼされるＩＰアドレスの、これらのＩＰアドレスに関連するすべてのＧＴＰ－Ｕコンテキストが失われたことを指示するための、リストとを含んでいるＧＴＰエラー指示を受信すること（８１４）と、
   ・ 制御プレーン（ＣＰ）機能（８００）に、前記第２のＵＰ機能（８０４）の前記再開始を報告するようにとのパケットフォワーディング制御プロトコル（ＰＦＣＰ）ノード報告要求メッセージを送信すること（８１６）であって、前記ＰＦＣＰノード報告要求メッセージは、
   （１）前記第２のＵＰ機能（８０４）が再開始したこと、およびＩＰアドレスの前記リストに関連するＧＴＰ－Ｕコンテキストが失われたことと、
   （２）前記ＣＰ機能（８００）が、ＰＦＣＰセッションごとにＤＬ ＦＡＲを変更するためにＰＦＣＰセッション修正要求メッセージを送信する必要がないことと
   を指示する、パケットフォワーディング制御プロトコル（ＰＦＣＰ）ノード報告要求メッセージを送信すること（８１６）と、
   ・ ＰＦＣＰノード報告応答メッセージを受信すること（８１８）と
   を含む、方法。
3. 前記第１のＵＰ機能（８０２）が、（ａ）新無線（ＮＲ）ノードＢ（ｇＮＢ）と、（ｂ）エボルブドノードＢ（ｅＮＢ）と、（ｃ）サービングゲートウェイ制御プレーン機能（ＳＧＷ－Ｕ）と、（ｄ）パケットデータネットワーク（ＰＤＮ）ゲートウェイ制御プレーン機能（ＰＧＷ－Ｕ）と、（ｅ）中間ユーザプレーン機能（Ｉ－ＵＰＦ）と、（ｆ）訪問ユーザプレーン機能（Ｖ－ＵＰＦ）と、（ｇ）プロトコルデータユニット（ＰＤＵ）セッションアンカー（ＰＳＡ）ＵＰＦとのうちの１つまたは複数において実装される、請求項２に記載の方法。
4. 前記ＰＦＣＰノード報告応答メッセージは、すべての影響を及ぼされるＰＦＣＰセッションにおけるダウンリンクＦＡＲが、適用アクションがバッファリングにセットされて、更新され、リモートＦ－ＴＥＩＤが除去されたという確認応答を含む、請求項２に記載の方法。