JP7635367B2 - Ｒｒｃ再確立 - Google Patents

Description

本開示の例は、たとえばＵＥがＲＲＣ再確立プロシージャを実施すること、またはＵＥにＲＲＣ再確立プロシージャを実施するように命令することなど、ＲＲＣ再確立に関する。

第５世代の（５Ｇ）新無線（Ｎｅｗ Ｒａｄｉｏ：ＮＲ）セルラ通信システムは、超高信頼低レイテンシ通信（ＵＲＬＬＣ）をサポートすることを目的とする。ＵＲＬＬＣの特徴の例は、信頼性を増加させるためのＰＤＣＰ複製機能、ならびに、ＵＥがあるセルまたはビームから別のセルまたはビームに切り替わるハンドオーバにおいて、最小中断時間を保証するためのメークビフォアブレークハンドオーバプロシージャを含む。

５Ｇ ＮＲシステムの一般的な展開は、将来において、３ＧＰＰ規定されたｇノードＢ－中央ユニット－制御プレーン（ｇＮＢ－ＣＵ－ＣＰ）機能など、５Ｇコアネットワークおよび上位無線アクセスネットワーク（ＲＡＮ）機能をサポートするクラウドインフラストラクチャを利用することが予想される。クラウドインフラストラクチャは、セルラネットワーク機能をサポートするために旧来使用されてきた一般的な、専用のまたは特殊化されたハードウェアとは信頼性が異なる。１つのそのような差は、基礎をなすハードウェアの利用可能性であり、これは、旧来の専用ハードウェアと比較して、汎用既製クラウドハードウェアの場合、著しく信頼性が低くなり得る。したがって、通信機能のクラウド展開は、クラウドインフラストラクチャの障害に対処するための機構を導入し得る。そのような機構の例は、分散データベースを使用して、このデータベースをサポートする１つまたは複数のハードウェアノードの障害の場合でも、永続記憶域を提供することを含む。

ＵＲＬＬＣを使用してＵＥへの信頼できる接続を保証するための方法が、同じＵＥへの並列ユーザプレーン接続を、ユーザプレーン接続のうちの１つが失われた場合に他の接続を介してデータ送信を続けることが可能であり得るように、セットアップすることを含み得る。複数のユーザプレーン接続は、単一の制御プレーン接続（たとえば、ＲＲＣ、ＮＡＳ接続）を使用して、または２つの独立した制御プレーン接続を用いてのいずれかでサポートされ得、これは、デバイスが、デュアル無線能力を有し、２つの独立した無線接続をセットアップすることが可能であることを必要とし、これは、一般に、ＵＥのコストを増加させる。後者のソリューションは、ネットワークが、２つの制御プレーン接続が関係することを理解することと、これらのデバイスが、単一障害点を回避するために異なるネットワークリソースを使用することに誘導されることを保証することとの両方を行う必要があることになるので、ネットワーク複雑度をも増加させる。

図１は、デュアルコネクティビティを使用するエンドツーエンド冗長ユーザプレーン経路についての例示的なシナリオ１００を示す。たとえば、図１は、冗長が適用されるときのデュアルＰＤＵセッションのユーザプレーンリソース設定を示す。一方のプロトコルデータユニット（ＰＤＵ）セッション１０２が、ＵＥからマスタＮＧ－ＲＡＮノードを介してＰＤＵセッションアンカーとして働く第１のユーザプレーン機能（ＵＰＦ１）にわたり、他方のＰＤＵセッション１０４が、ＵＥから２次ＮＧ－ＲＡＮノードを介してＰＤＵセッションアンカーとして働くＵＰＦ２にわたる。参照により本明細書に組み込まれる、３ＧＰＰ技術仕様（ＴＳ）３７．３４０において説明されるように、ＮＧ－ＲＡＮは、２つのＮＧ－ＲＡＮノード（すなわち図１に示されているマスタＮＧ－ＲＡＮおよび２次ＮＧ－ＲＡＮ）または単一のＮＧ－ＲＡＮノードを用いた２つのＰＤＵセッションのために冗長ユーザプレーンリソースを実現し得る。どちらの場合も、マスタＮＧ－ＲＡＮノードからＡＭＦへ向かう単一のＮ２インターフェースがある。

これらの２つのＰＤＵセッション１０２および１０４に基づいて、２つの独立したユーザプレーン経路がセットアップされる。ＵＰＦ１とＵＰＦ２とは、同じデータネットワーク（ＤＮ）に接続するが、ＵＰＦ１およびＵＰＦ２を介したトラフィックは、ＤＮ内の異なるユーザプレーンノードを介してルーティングされ得る。

５Ｇ ＲＡＮアーキテクチャ２００は、参照により本明細書に組み込まれる３ＧＰＰ ＴＳ３８．４０１において説明されており、図２に示されている。ＮＧアーキテクチャは、以下のようにさらに説明され得る。
・ ＮＧ－ＲＡＮは、ＮＧインターフェースを通して５ＧＣに接続されるｇＮＢのセットからなる。
・ ｇＮＢは、ＦＤＤモード、ＴＤＤモードまたはデュアルモード動作をサポートすることができる。
・ ｇＮＢは、Ｘｎインターフェースを通して相互接続され得る。
・ ｇＮＢは、ｇＮＢ－ＣＵ（中央ユニット）と１つまたは複数のｇＮＢ－ＤＵ（分散ユニット）とからなり得る。
・ ｇＮＢ－ＣＵとｇＮＢ－ＤＵとは、Ｆ１論理インターフェースを介して接続される。
・ ｇＮＢ－ＤＵは、１つのｇＮＢ－ＣＵのみに接続される。

ＮＧ、ＸｎおよびＦ１は、論理インターフェースである。ＮＧ－ＲＡＮの場合、ｇＮＢ－ＣＵとｇＮＢ－ＤＵとからなるｇＮＢのためのＮＧおよびＸｎ－Ｃインターフェースは、ｇＮＢ－ＣＵにおいて終端する。Ｅ－ＵＴＲＡＮ新無線デュアルコネクティビティ（ＥＮ－ＤＣ）の場合、ｇＮＢ－ＣＵとｇＮＢ－ＤＵとからなるｇＮＢのためのＳ１－ＵおよびＸ２－Ｃインターフェースは、ｇＮＢ－ＣＵにおいて終端する。ｇＮＢ－ＣＵおよび接続されたｇＮＢ－ＤＵは、ｇＮＢとして他のｇＮＢおよびコアネットワーク（５ＧＣ）に見えるにすぎない。

ＮＧ－ＲＡＮは、無線ネットワークレイヤ（ＲＮＬ）とトランスポートネットワークレイヤ（ＴＮＬ）とにレイヤ化される。ＮＧ－ＲＡＮアーキテクチャ、すなわち、ＮＧ－ＲＡＮ論理ノードと、ＮＧ－ＲＡＮ論理ノード間のインターフェースとは、ＲＮＬの一部として規定される。各ＮＧ－ＲＡＮインターフェース（ＮＧ、Ｘｎ、Ｆ１）では、関係するＴＮＬプロトコルと機能とが指定される。ＴＮＬは、ユーザプレーントランスポートとシグナリングトランスポートとのためのサービスを提供する。ＮＧ－Ｆｌｅｘ設定では、各ｇＮＢが、アクセスおよびモビリティ機能（ＡＭＦ）領域内のすべてのＡＭＦに接続される。ＡＭＦ領域は、参照により本明細書に組み込まれる３ＧＰＰ ＴＳ２３．５０１において規定されている。

オープンインターフェースが、中央ユニット（ＣＵ）の、制御プレーン（ＣＵ－ＣＰ）部分とユーザプレーン（ＣＵ－ＵＰ）部分との間に指定された。関係する仕様は、参照により本明細書に組み込まれる３ＧＰＰ ＴＳ３８．４６３である。ＣＵ－ＣＰとＣＵ－ＵＰとの間のオープンインターフェースは、Ｅ１と称する。アーキテクチャは、スプリットｇＮＢアーキテクチャを示す図３に示されている。スプリットｇＮＢについての３つの展開シナリオが、参照により本明細書に組み込まれる３ＧＰＰ技術報告（ＴＲ）３８．８０６に示されている。
－ シナリオ１： 集中されたＣＵ－ＣＰおよびＣＵ－ＵＰ、
－ シナリオ２： 分散されたＣＵ－ＣＰおよび集中されたＣＵ－ＵＰ、
－ シナリオ３： 集中されたＣＵ－ＣＰおよび分散されたＣＵ－ＵＰ。

Ｅ１アプリケーションプロトコル（Ｅ１ＡＰ）は、ＴＳ３８．４６３において規定されている。Ｅ１ＡＰは、ＵＥにユーザプレーンサービスを提供するために、ＣＵ－ＣＰとＣＵ－ＵＰとの間で交換されるメッセージを規定する。

ＬＴＥおよびＮＲでは、ＵＥとｅＮＢまたはｇＮＢとの間の無線接続をセットアップ、設定および維持するために、無線リソース制御（ＲＲＣ）プロトコルが使用される。ＵＥがｅＮＢまたはｇＮＢからＲＲＣメッセージを受信したとき、ＵＥは設定を適用またはコンパイルし、これが成功した場合、ＵＥはＲＲＣ完了メッセージを生成し、ＲＲＣ完了メッセージは、この応答をトリガしたメッセージのトランザクションＩＤを指示する。

ＬＴＥリリース８（ｒｅｌ－８）以来、３つのシグナリング無線ベアラ（ＳＲＢ）、すなわち、ＳＲＢ０、ＳＲＢ１およびＳＲＢ２が、ＵＥとｅＮＢとの間のＲＲＣメッセージおよび非アクセス階層（ＮＡＳ）メッセージのトランスポートのために利用可能になっている。また、ＳＲＢ１ｂｉｓとして知られる新しいＳＲＢが、モノの狭帯域インターネット（ＮＢ－ＩｏＴ）におけるＤｏＮＡＳ（データオーバーＮＡＳ）をサポートするためにｒｅｌ－１３において導入された。ＳＲＢ０は、ＣＣＣＨ論理チャネルを使用するＲＲＣメッセージのためのものであり、ＲＲＣ接続セットアップ、ＲＲＣ接続再開およびＲＲＣ接続再確立をハンドリングするために使用される。ＵＥがｅＮＢに接続される（すなわち、ＲＲＣ接続セットアップまたはＲＲＣ接続再確立／再開が成功する）と、ＳＲＢ１は、すべてがＤＣＣＨ論理チャネルを使用する、（ピギーバックＮＡＳメッセージを含み得る）ＲＲＣメッセージをハンドリングするために、ならびに、ＳＲＢ２の確立より前のＮＡＳメッセージのために使用される。ＳＲＢ２は、すべてがＤＣＣＨ論理チャネルを使用する、ロギングされた測定情報を含むＲＲＣメッセージのためのもの、ならびに、ＮＡＳメッセージのためのものである。ＳＲＢ２は、ロギングされた測定情報およびＮＡＳメッセージが、長くなり得、より緊急のおよびより小さいＳＲＢ１メッセージの阻止を引き起こし得るので、ＳＲＢ１よりも低い優先度を有する。ＳＲＢ２は、常に、セキュリティアクティブ化の後にＥ－ＵＴＲＡＮによって設定される。

ｒｅｌ－１５では、デュアルコネクティビティ（マスタノードとしてのＬＴＥ、一方ＮＲは２次ノード、またはその逆、ならびに２つのＮＲノードを使用するデュアルコネクティビティ）の場合、スプリットＳＲＢが導入され、ここで、ＳＲＢ１／２が、マスタノードまたは２次ノードの無線リソースを介してトランスポートされ得る（プロトコルはマスタノードにおいて終端される）。さらに、（２次ノードがＮＲである場合）ＳＲＢ３と呼ばれる新しいＳＲＢが導入され、ＳＲＢ３はＲＲＣメッセージを、マスタノードとの協調を必要としないメッセージについて、２次ノードからＵＥに直接転送するために使用される。

ＲＲＣプロシージャの大部分が、たとえば、測定報告設定、下位レイヤ設定、無線ベアラ設定など、ＵＥの何らか挙動を再設定するために、ネットワークによって始動される。一般に、ＵＥは、新しい設定が採用されたことを指示するＲＲＣ返答メッセージで、ネットワークからのＲＲＣメッセージに確認応答する。
また、以下のものなど、いくつかのＲＲＣプロシージャが、ＵＥによって始動される。
－ （たとえばＵＥモビリティのために使用される）測定報告
－ 接続失敗の場合のＲＲＣ再確立
－ 初期ＲＲＣ接続セットアップ（たとえば、ＵＥがアイドルモードであり、接続に遷移する必要がある場合）

ＲＲＣは、ＲＲＣメッセージのロスレス、順序、複製フリー配信を保証するためにＰＤＣＰ／ＲＬＣ／ＭＡＣプロトコルに依拠する。順序配信は、ＰＤＣＰシーケンス番号によって保証され、これは、ＲＲＣメッセージが、次の予想されるＰＤＣＰシーケンス番号（すなわち、番号が、最後の配信されたメッセージのＰＤＣＰシーケンス番号よりも１大きい）であるＰＤＣＰシーケンス番号を有する場合のみ、ＰＤＣＰが、ＲＲＣメッセージを配信する（たとえば、ＰＤＣＰレイヤの上の後のものに配信する）ことを意味する。これは、ネットワークが厳密なシーケンス番号を正確に推測しない場合、メッセージは、ＵＥにおけるＰＤＣＰレイヤによって、ＵＥにおける上位レイヤ（たとえばＲＲＣレイヤ）に配信されないことになるので、ネットワークがＵＥによって予想される次のＰＤＣＰシーケンス番号の知識を失った場合、ネットワークは、いかなるＲＲＣメッセージもＵＥに送ることが可能でないことになることを意味する。

ＲＲＣプロトコルに加えて、ＵＥは、ＵＥとコアネットワークとの間にあるＮＡＳプロトコルによっても制御される。ＮＡＳプロトコルは、ＲＲＣメッセージ内に埋め込まれて配信される。

図４は、ＮＲにおける制御プレーン（ＣＰ）プロトコルスタック４００の一例を示し、図５は、ＮＲにおけるユーザプレーン（ＵＰ）プロトコルスタック５００の一例を示し、ここで、ＣＵ／ＤＵスプリットアーキテクチャが採用される（ここで、ＣＵも、ＣＵ－ＵＰとＣＵ－ＣＰとにスプリットされる）。ＣＵ－ＣＰ／ＣＵ－ＵＰスプリットは機能的スプリットであり、したがって、２つの機能は、同じノードまたは異なるノードのいずれか中に存在することができ、さらには、機能のうちの１つ、すなわち、ＣＵ－ＵＰまたはＣＵ－ＣＰは、所与のｇＮＢについて、いくつかの物理ノード／エンティティにおいて物理的に実現され得、物理的に分散され得ることに留意されたい。たとえば、所与のｇＮＢについてのＣＵ－ＵＰ／ＣＵ－ＣＰのいくつかのインスタンスが、冗長の目的でまたは負荷分散の目的でオペレータのクラウド中に存在することができる。

たとえば無線リンク障害、ハンドオーバ失敗（Ｔ３０４タイマー満了）またはＲＲＣメッセージに適合することができないこと、完全性検証失敗などにより、ＵＥとの接続が失敗した場合、ＵＥは、ＲＲＣ再確立プロシージャを始動することになる。ＮＲでは、これは、セクション５．３．７における、参照により本明細書に組み込まれるＴＳ３８．３３１において捕捉される。図６は、ＲＲＣ接続再確立（成功した）プロシージャ６００の一例を示し、図７は、ＲＲＣ確立へのフォールバックを伴うＲＲＣ再確立（成功した）プロシージャ７００の一例を示す。再確立プロシージャの目的は、ＲＲＣ接続を再確立することである。ＡＳセキュリティがＳＲＢ２および少なくとも１つのＤＲＢセットアップでアクティブ化された、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥが、ＲＲＣ接続を続けるためにＲＲＣ再接続プロシージャを始動し得る。ネットワークが、ＵＥについての有効なＵＥコンテキストを見つけ、検証することが可能である場合、接続再確立は成功し、または、ＵＥコンテキストが取り出され得ない場合、ネットワークは、たとえば図７に示されているようにＲＲＣセットアップメッセージで応答する。

ネットワークは、たとえば以下のようにプロシージャを適用する。
ＡＳセキュリティがアクティブ化され、ネットワークがＵＥコンテキストを取り出すかまたは検証するとき、
－ アルゴリズムを変更することなしにＡＳセキュリティを再アクティブ化する、
－ 再確立し、ＳＲＢ１を再開する、
ＵＥがＲＲＣ接続を再確立しつつあり、ネットワークがＵＥコンテキストを取り出すかまたは検証することが可能でないとき、
－ 記憶されたＡＳコンテキストを廃棄し、すべてのＲＢを解放する、
－ 新しいＲＲＣ接続を確立するためにフォールバックする。

ＡＳセキュリティがアクティブ化されなかった場合、ＵＥはプロシージャを始動せず、代わりにＲＲＣ＿ＩＤＬＥ状態に直接移動し、解放原因「その他（ｏｔｈｅｒ）」を伴うものとする。ＡＳセキュリティがアクティブ化されたが、ＳＲＢ２および少なくとも１つのＤＲＢがセットアップされない場合、ＵＥは、プロシージャを始動せず、代わりにＲＲＣ＿ＩＤＬＥに直接移動し、解放原因「ＲＲＣ接続失敗」を伴う。

ＵＥは、問題を検出する前にＵＥが接続されたものとは異なるノードに、再確立することができる。ターゲットネットワークノードが、（たとえば図６または図７に示されている）ＲＲＣ再確立要求メッセージを受信するとき、ターゲットネットワークノードは、ＵＥについての古いＵＥコンテキストを特定することを試みるために、要求メッセージ中に含まれるＲｅｅｓｔａｂＵＥ識別情報を使用することができる。ターゲットネットワークノードがコンテキストを特定することができる場合、ターゲットネットワークノードは、ＵＥにＲＲＣ再確立メッセージを送信することができ、ＵＥは、古い設定を復元することになる。ターゲットネットワークノードがＵＥコンテキストを見つけることができない場合、ターゲットネットワークノードは、ＮＡＳ回復を実施しなければならず、代わりに、たとえば図７に示されているように、ＵＥにＲＲＣセットアップメッセージを送る。

ターゲットネットワークノードは、（参照により本明細書に組み込まれるＴＳ３８．４２３／３６．４２３において規定されているように）ソースノード、すなわち、接続失敗の前にＵＥが接続されていたノードに、ＵＥコンテキスト取出し要求を送信することになり、ソースノードは、（ＵＥ識別および検証が成功した場合）ＵＥコンテキスト取出し応答で応答することができる。成功した場合、ＵＥコンテキスト取出し応答は、ＵＥコンテキストを含んでいる、ＴＳ３８．３３１において規定されている、ハンドオーバ準備情報メッセージを含んでいることになる。ＵＥが、ＲＲＣ再確立メッセージを受信し、いくつかの設定（たとえばＳＲＢ１）を復元し、接続を再確立すると、ＵＥは、ネットワークにＲＲＣ再確立完了メッセージを送信することになる。次いで、ネットワークは、ＲＲＣ再設定メッセージをＵＥに送ることになり、ＵＥは、ＵＥにおける設定の残りを復元し、場合によっては再設定することになる。

ＣＵ／ＤＵスプリットのコンテキストにおいて、再確立プロシージャは（ＴＳ３８．４０１、セクション８．７からの）図８に示されており、図８は、ＣＵ／ＤＵスプリットアーキテクチャの場合のＲＲＣ再確立プロシージャ８００の一例を示す。このプロシージャにおけるステップは、以下の通りである。
１． ＵＥが、プリアンブルをｇＮＢ－ＤＵに送る。
２． ｇＮＢ－ＤＵは、新しいＣ－ＲＮＴＩを割り当て、ランダムアクセス応答（ＲＡＲ）でＵＥに応答する。
３． ＵＥは、古いＣ－ＲＮＴＩと古い物理セルＩＤ（ＰＣＩ）とを含んでいるＲＲＣ再確立要求メッセージをｇＮＢ－ＤＵに送る。
４． ｇＮＢ－ＤＵは、ＲＲＣメッセージとＵＥについての対応する下位レイヤ設定とを初期ＵＬ ＲＲＣメッセージ転送メッセージ中に含め、ｇＮＢ－ＣＵに転送する。初期ＵＬ ＲＲＣメッセージ転送メッセージは、Ｃ－ＲＮＴＩを含むべきである。
５． ｇＮＢ－ＣＵは、ＲＲＣ再確立メッセージを含め、ｇＮＢ－ＤＵに転送する。ＵＥが、最後のサービングｇＮＢ－ＤＵにおけるＲＲＣ接続を再確立することを要求する場合、ＤＬ ＲＲＣメッセージ転送メッセージは古いｇＮＢ－ＤＵ ＵＥ Ｆ１ＡＰ ＩＤを含むものとする。
６． ｇＮＢ－ＤＵは、古いｇＮＢ－ＤＵ ＵＥ Ｆ１ＡＰ ＩＤに基づくＵＥコンテキストを取り出し、古いＣ－ＲＮＴＩ／ＰＣＩを新しいＣ－ＲＮＴＩ／ＰＣＩと置き換える。ｇＮＢ－ＤＵは、ＲＲＣ再確立メッセージをＵＥに送る。
７～８． ＵＥは、ＲＲＣ再確立完了メッセージをｇＮＢ－ＤＵに送る。ｇＮＢ－ＤＵは、ＲＲＣメッセージをＵＬ ＲＲＣメッセージ転送メッセージ中にカプセル化し、ｇＮＢ－ＣＵに送る。
９～１０． ｇＮＢ－ＣＵは、修正および解放されるべきＤＲＢリスト（ＤＲＢｓ ｔｏ ｂｅ ｍｏｄｉｆｉｅｄ ａｎｄ ｒｅｌｅａｓｅｄ ｌｉｓｔ）を含み得る、ＵＥコンテキスト修正要求を送ることによって、ＵＥコンテキスト修正プロシージャをトリガする。ｇＮＢ－ＤＵは、ＵＥコンテキスト修正応答メッセージで応答する。
９’～１０’． ｇＮＢ－ＤＵは、修正および解放されるべきＤＲＢリストを含み得る、ＵＥコンテキスト修正必要を送ることによって、ＵＥコンテキスト修正プロシージャをトリガする。ｇＮＢ－ＣＵは、ＵＥコンテキスト修正確認メッセージで応答する。
注： ここで、ＵＥは、ＵＥコンテキストがそのＵＥのために利用可能である、元のｇＮＢ－ＤＵからアクセスすると仮定され、ステップ９～１０またはステップ９’および１０’のいずれかが存在し得るか、または両方ともスキップされ得る。
注： ＵＥが、元のｇＮＢ－ＤＵ以外のｇＮＢ－ＤＵからアクセスする場合、ｇＮＢ－ＣＵは、この新しいｇＮＢ－ＤＵへ向かってＵＥコンテキストセットアッププロシージャをトリガするべきである。
１１～１２． ｇＮＢ－ＣＵは、ＲＲＣ再設定メッセージをＤＬ ＲＲＣメッセージ転送メッセージ中に含め、ｇＮＢ－ＤＵに転送する。ｇＮＢ－ＤＵは、それをＵＥにフォワーディングする。
１３～１４． ＵＥはＲＲＣ再設定完了メッセージをｇＮＢ－ＤＵに送り、ｇＮＢ－ＤＵはＲＲＣ再設定完了メッセージをｇＮＢ－ＣＵにフォワーディングする。

ＲＲＣメッセージの配信のために使用されるシグナリング無線ベアラ（ＳＲＢ）が、ＲＲＣメッセージのロスレス、複製フリー、順序配信を提供する。ＰＤＣＰレイヤの上の（１つまたは複数の）レイヤへの順序および複製フリー配信を保証することは、ＰＤＣＰレイヤの責任である。ＰＤＣＰレイヤは、これを、ＰＤＣＰシーケンス番号をあらゆるメッセージに割り振ることによって行う。シーケンス番号は、ＰＤＣＰメッセージのＰＤＣＰヘッダ中で転送される。ＲＲＣメッセージを含んでいるパケットのＰＤＣＰシーケンス番号が、（最後に使用されたＰＤＣＰシーケンス番号＋１である）次の予想されるＰＤＣＰシーケンス番号である場合、（たとえばＵＥにおける）受信ＰＤＣＰエンティティは、ＰＤＣＰパケット内のＲＲＣメッセージをＲＲＣレイヤに単に配信することになる。ネットワークが、失敗の前に最後に使用されたＰＤＣＰシーケンス番号よりも小さいＰＤＣＰシーケンス番号を使用する場合、ＵＥは、パケットを複製と見なし、パケットを廃棄することになる。ネットワークが、ＵＥにおける次の予想されるＰＤＣＰシーケンス番号よりも大きいＰＤＣＰシーケンスを使用する場合、ＵＥは、メッセージをＰＤＣＰレイヤに記憶し、（１つまたは複数の）欠落したシーケンス番号をもつ（１つまたは複数の）欠落したパケットを待つことになる。たとえば、ＣＰ失敗の前の最後に受信されたＲＲＣメッセージが、シーケンス番号（ＳＮ）ｘをもつＰＤＣＰパケット内にあり、ＲＲＣメッセージがＳＮｘ＋２を伴って受信された場合、ＰＤＣＰレイヤは、ＳＮｘ＋２をもつＰＤＣＰパケット中のＲＲＣメッセージをＲＲＣレイヤにフォワーディングする前に、ＳＮｘ＋１をもつＰＤＣＰパケットを待つことになる。すなわち、ＳＮｘ＋１をもつパケットが受信されない場合、ＳＮｘ＋２をもつパケットは、いつまでもＵＥに記憶されることになり、そのコンテンツは、上位レイヤに配信されないことになる。ＰＤＣＰシーケンス番号はラップアラウンドするので、順序外れパケットが複製であるのか将来の順序外れパケットであるのかの決定は、パケットがＰＤＣＰ受信ウィンドウ内にあるのかＰＤＣＰ受信ウィンドウの外にあるかに基づく。

（ＴＳ３８．３３１におけるセクション５．３．７．２による）再確立プロシージャの始動の間、ＵＥは、
－ ＭＡＣをリセットする（すなわち、ＭＡＣレベルにおける保留中のデータが、フラッシュされることになる）
－ キャリアアグリゲーション（ＣＡ）とデュアルコネクティビティ（ＤＣ）の両方が解放される
－ （再確立メッセージを送るために使用される、ＳＲＢ０を除いて）すべてのＤＲＢおよびＳＲＢが中断される

次いで、ＵＥは、タイマーＴ３１１を開始し、セル再選択を実施し、これは、ＵＥが前に接続された同じ１次セル、または別のセルを選択し得る。好適なセルが見つけられる前にタイマーが満了する場合、ＮＡＳ回復は、アイドルモードを介して実施されなければならない。好適なセルが見つけられた場合、ＵＥは、デフォルトＭＡＣおよび制御チャネル設定を適用し、タイマーＴ３０１を開始し、選定されたセルに（ＵＥ識別情報と、再確立がトリガされる前にＵＥが使用していた古いＲＲＣ完全性を使用して算出される、短いＭＡＣ－Ｉと呼ばれるセキュリティチェックサムと、以下の値、すなわち、無線リンク障害、再設定失敗、ハンドオーバ失敗、または他の失敗のうちの１つをとることができる、再確立原因とを含む）ＲＲＣ再確立要求メッセージを送る。タイマーＴ３０１が、ＵＥがネットワークからＲＲＣ再確立メッセージを受信する前に満了する場合、ＵＥは、アイドルモードを介してＮＡＳ回復を実施しなければならない。

ＮＣＣ（ネクストホップチェイニングカウント）を含んでいるＲＲＣ再確立メッセージを受信するとすぐに、ＵＥは、受信された再確立メッセージの完全性の検証のためにを含む、接続のために使用されるべき新しいユーザプレーンおよび制御プレーン暗号化および完全性保護鍵を導出するためにＮＣＣ値を使用する。ネットワークは、常に、再確立メッセージの後にＲＲＣ再設定メッセージ（仕様において「再確立の後の最初の再設定」と呼ばれる）を送る。この再設定メッセージは、完全な設定フラグを含んでおり、したがって、（Ｃ－ＲＮＴＩとマスタ鍵に関連付けられたアクセス階層セキュリティ設定とを除いて）全無線設定をリセットし、その無線設定を新しい無線設定と置き換える。さらに、ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰフィールドが、各ＳＲＢ／ＤＲＢについて含まれることになり、これは、各ＳＲＢ／ＤＲＢのＰＤＣＰエンティティを再確立することになる。ＰＤＣＰの再確立は、再確立メッセージの受信に対して計算された新しいサイファ化および完全性保護鍵を使用するために、ならびに、送信ＰＤＣＰエンティティについて、それらを新しい鍵で保護した後に保留中のＰＤＣＰパケットを送信するために、ＰＤＣＰエンティティの再設定を生じることになる（ここで「保留中」は、すでに送られたそれらのパケット、古いセキュリティ鍵を使用して保護されるが、それらの受信の確認応答が受信されなかったことを意味する）。また、ＳＲＢの場合、ＰＤＣＰの再確立は、初期値へのシーケンス番号のリセットを意味する。

ＮＣＣの使用およびセキュリティ鍵の更新についての主要な理由は、セキュリティ観点から、同じシーケンス番号（Ｃｏｕｎｔ）およびセキュリティ鍵を異なるデータのために再使用することが、回避されるべきであることであり、これは、通常ならば、ＳＲＢのシーケンス番号がリセットされるので再確立の間に起こり得る。これは、（参照により本明細書に組み込まれる３ＧＰＰ ＴＳ３３．５０１において、図Ｄ２．１．１－１に示されている）３ＧＰＰネットワークにおけるサイファ化原理が、鍵、シーケンス番号などに基づくサイファ化アルゴリズムによって生成されたセキュリティビットストリーム（鍵ストリームブロック）を伴うデータ（プレーンテキストブロック）の排他的論理和をとることに基づくことによるものである。同じビットストリームで暗号化された２つのメッセージの排他的論理和をとることによって、このセキュリティビットストリームを除去することが可能であり得る。その場合、残りのビットは、単に、２つの元のメッセージの排他的論理和（ＸＯＲ）である。したがって、攻撃者がメッセージのうちの１つを推測することができた場合、自動的に、他のメッセージを復号することも可能であることになる。３ＧＰＰ ＴＳ３３．５０１のＤ２．１．１－１が、図９に示されている。

ＲＲＣ接続再確立プロシージャは、ネットワークとＵＥとを再同期させるために使用され得る。しかしながら、それは常に、ユーザプレーンのリセットにつながり、これは、たとえば、ユーザプレーンデータ無線ベアラ（ＤＲＢ）が中断され、下位レイヤ状態マシン（たとえばＲＬＣ／ＭＡＣ）におけるパケットがフラッシュされることを意味する。研究は、一般的なＲＲＣ接続再確立プロシージャが、１００ｍｓ以上のユーザプレーンサービス中断を引き起こすことになることを示している。これは、設定可能な値を有するいくつかのタイマーによっても再確立が制御されるので、実際にはかなりより長くなり得る（たとえば、物理レイヤ問題を検出したときに開始されたＴ３１０は、最高２秒の長さであり得、ＵＥは、このタイマーが満了するまで再確立プロシージャを始動しないことになる）。一般に、これは、接続の全体的性能が、そのようなサービス中断によって著しく影響を及ぼされないので、通常のモバイルブロードバンド（ＭＢＢ）ユーザまたは他のユーザにとって問題ではない。しかしながら、ＵＲＬＬＣを必要とする接続の場合、このサービス中断は、たとえば、レイテンシおよび／または信頼性など、ＵＲＬＬＣ要件が満たされないことを意味し得る。

ＵＲＬＬＣ通信では、存続時間（ｓｕｒｖｉｖａｌ ｔｉｍｅ）は、ＵＲＬＬＣ通信サービスを消費するアプリケーションが、予期されるメッセージなしに続き得る時間である。存続時間が満了する前に通信サービス回復（たとえばＲＲＣ再確立）が完了されない場合、エンドユーザアプリケーションは、通信サービスを利用不可能と見なし、たとえば、回復するための緊急アクションをとり始め得る。存続時間はまた、（たとえばＵＥモビリティにおいて）許容されるユーザプレーン中断時間に制限を課する。存続時間は、存続時間が、アプリケーションダウンタイムを回避するためにシステムが失敗からどれくらい速く回復する必要があるかに制限を課するので、重要な要件である。通信失敗の後の回復時間が存続時間よりも短い場合、その失敗はアプリケーションによって見過ごされ得る。厳しい存続時間をもつ使用事例の例は、約１００ｍｓの存続時間を有し得る公共安全ドローンと、トラフィックが、巡回的であり、頻繁な小さいパケットを伴い、一般に、工業イーサネットを使用する、工業自動化使用事例とを含む。これらの事例における存続時間は、単一のパケットまたは数個の連続するパケットのロスを許容し得る。たとえば、動き制御は、０～２ｍｓの存続時間、ＰＬＣ間通信８～４８ｍｓ、および無人搬送車（ＡＧＶ）４０～５００ｍｓを有する。

本開示の一態様は、ＲＲＣ再確立プロシージャを実施するユーザ機器（ＵＥ）における方法を提供する。本方法は、ネットワークノードからＲＲＣ再確立プロシージャを実施するようにとの命令を受信することと、ＲＲＣ再確立要求を送信することとを含む。

本開示の別の態様は、ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するネットワークノードにおける方法を提供する。本方法は、ＵＥに関連付けられた第１の基地局制御プレーン機能が利用不可能であると決定することと、ＵＥに、少なくとも、第２の基地局制御プレーン機能との制御プレーン接続を再確立させるために、ＲＲＣ再確立プロシージャを実施するようにとの命令をＵＥに送ることとを含む。

本開示のさらなる態様は、ＲＲＣ再確立プロシージャを実施するためのユーザ機器（ＵＥ）における装置を提供する。本装置は、プロセッサとメモリとを備える。メモリは、本装置が、ネットワークノードからＲＲＣ再確立プロシージャを実施するようにとの命令を受信することと、ＲＲＣ再確立要求を送信することとを行うように動作可能であるような、プロセッサによって実行可能な命令を含んでいる。

本開示のまたさらなる態様は、ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するネットワークノードにおける装置を提供する。本装置は、プロセッサとメモリとを備える。メモリは、本装置が、ＵＥに関連付けられた第１の基地局制御プレーン機能が利用不可能であると決定することと、ＵＥに、少なくとも、第２の基地局制御プレーン機能との制御プレーン接続を再確立させるために、ＲＲＣ再確立プロシージャを実施するようにとの命令をＵＥに送ることとを行うように動作可能であるような、プロセッサによって実行可能な命令を含んでいる。

本開示の追加の態様は、ＲＲＣ再確立プロシージャを実施するためのユーザ機器（ＵＥ）における装置を提供する。本装置は、ネットワークノードからＲＲＣ再確立プロシージャを実施するようにとの命令を受信することと、ＲＲＣ再確立要求を送信することとを行うように設定される。

本開示の別の態様は、ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するためのネットワークノードにおける装置を提供する。本装置は、ＵＥに関連付けられた第１の基地局制御プレーン機能が利用不可能であると決定することと、ＵＥに、少なくとも、第２の基地局制御プレーン機能との制御プレーン接続を再確立させるために、ＲＲＣ再確立プロシージャを実施するようにとの命令をＵＥに送ることとを行うように設定される。

本開示の例をより良く理解するために、および本開示の例がどのように実現され得るかをより明らかに示すために、次に、単に例として、以下の図面への参照がなされる。

デュアルコネクティビティ（ＤＣ）を使用するエンドツーエンド冗長ユーザプレーン経路についての例示的なシナリオを示す図である。 ５Ｇ無線アクセスネットワーク（ＲＡＮ）アーキテクチャの一例を示す図である。 スプリットｇノードＢアーキテクチャを示す図である。 制御プレーン（ＣＰ）プロトコルスタックの一例を示す図である。 ユーザプレーン（ＵＰ）プロトコルスタックの一例を示す図である。 ＲＲＣ接続再確立（成功した）プロシージャの一例を示す図である。 ＲＲＣ確立へのフォールバックを伴うＲＲＣ再確立（成功した）プロシージャの一例を示す図である。 ＣＵ／ＤＵスプリットアーキテクチャの場合のＲＲＣ再確立プロシージャの一例を示す図である。 ３ＧＰＰ ＴＳ３３．５０１の図Ｄ２．１．１－１を示す図である。 ＲＲＣ再確立プロシージャを実施するユーザ機器（ＵＥ）における方法のフローチャートである。 ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するネットワークノードにおける方法のフローチャートである。 ネットワークにおける通信の特定の例示的な実施形態を示す図である。 ネットワークにおける通信の別の例を示す図である。 ＲＲＣ再確立プロシージャを実施するためのユーザ機器（ＵＥ）における装置１４００の一例の概略図である。 ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するネットワークノードにおける装置１５００の一例の概略図である。

以下は、限定ではなく説明の目的で、特定の実施形態または例など、具体的な詳細を記載する。他の例が、これらの具体的な詳細から離れて採用され得ることが当業者によって諒解されよう。いくつかの事例では、よく知られている方法、ノード、インターフェース、回路、およびデバイスの詳細な説明が、不要な詳細で説明を不明瞭にしないように省略される。説明される機能が、ハードウェア回路（たとえば、特殊な機能を実施するために相互接続されたアナログおよび／または個別論理ゲート、ＡＳＩＣ、ＰＬＡなど）を使用して、ならびに／あるいは１つまたは複数のデジタルマイクロプロセッサまたは汎用コンピュータとともにソフトウェアプログラムおよびデータを使用して、１つまたは複数のノードにおいて実装され得ることを、当業者は諒解されよう。また、エアインターフェースを使用して通信するノードは、好適な無線通信回路を有する。その上、適切な場合、本技術は、加えて、本明細書で説明される技法をプロセッサに行わせることになるコンピュータ命令の適切なセットを含んでいる、固体メモリ、磁気ディスク、または光ディスクなど、任意の形態のコンピュータ可読メモリ内で完全に具現されると見なされ得る。

ハードウェア実装形態は、限定はしないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェアと、縮小命令セットプロセッサと、限定はしないが、（１つまたは複数の）特定用途向け集積回路（ＡＳＩＣ）および／または（１つまたは複数の）フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含むハードウェア（たとえば、デジタルまたはアナログ）回路と、（適切な場合）そのような機能を実施することが可能な状態マシンとを含むかまたは包含し得る。

制御プレーン機能の失敗または制御プレーン機能が利用不可能なこと、および制御プレーン機能の再開または再配置の後の、少なくとも３つの可能なシナリオがあり得る。いくつかの例では、制御プレーン機能の再配置は、異なる制御プレーン機能が、失敗したまたは利用不可能な制御プレーン機能によってサーブされていた（１つまたは複数の）ＵＥおよび（１つまたは複数の）ＤＵについての制御プレーン機能（ｆｕｎｃｔｉｏｎ）／機能（ｆｕｎｃｔｉｏｎａｌｉｔｙ）の責任を担うことを意味し得る。第１のシナリオでは、ネットワークおよびＵＥコンテキストが同期している。たとえば、ＵＥは、ネットワークによってＵＥに送られた最後のＲＲＣメッセージを受信し、適切に適用／コンパイルし、ＳＲＢ１についての次の予想されるＰＤＣＰシーケンス番号（ＳＮ）が、ネットワークによって送信される次のシーケンス番号と同じであることになる。このシナリオでは、ネットワークによって送られる次のＲＲＣメッセージは、ＰＤＣＰレイヤにおいて順次受信され、したがって、たとえばＲＲＣレイヤなど、ＰＤＣＰレイヤの上のレイヤにフォワーディングされることになる。

第２のシナリオでは、ネットワークは、より最新のコンテキストを有する。たとえば、ネットワークは、ネットワークが送った最新のＲＲＣメッセージに従ってＵＥコンテキストを更新し、また、ＳＲＢ１についてのＰＤＣＰ ＳＮを増分したが、そのメッセージはＵＥに到着していない（たとえば、そのメッセージがＤＵまたはＵＥに到着する前に、制御プレーン機能が失敗した）。したがって、ネットワークによって送られる次のＲＲＣメッセージは、ＵＥが予想するよりも大きいＳＮを有することになり、ＵＥによっていつまでも記憶されることになり、ＵＥは、ＵＥが欠落していると見なす１つまたは複数のパケットまたはメッセージを待つ。

第３のシナリオでは、ＵＥは、より最新のコンテキストを有する。これは、たとえば、ネットワークが、記憶されたＵＥコンテキストをネットワークが更新する前に、ネットワークがＵＥからＲＲＣメッセージの確認応答を受信するまで待ち、ＵＥが、ＲＲＣメッセージを受信および適用し、確認応答を送ったが、確認応答の受信の前に制御プレーン機能が失敗した場合、起こり得る。この場合、ネットワークによって送られる次のＲＲＣメッセージは、ＵＥが予想するよりも低いＳＮを有することになり、複製と見なされることになり、ドロップされることになる。

本開示の実施形態は、たとえば、ＵＥとネットワークとの間のコンテキスト再同期が、制御プレーン回復（たとえば、１つまたは複数のＵＥについての制御プレーン機能の再開始または再配置）時に実施されることを保証し得る。また、例示的な実施形態は、特にユーザプレーンデータ無線ベアラ（ＤＲＢ）について、サービス不連続性なしにこれを達成し得る。例示的な実施形態は、ＵＥに関連付けられた（たとえばＵＥをサーブする）制御機能が利用不可能であるとき、ＵＥとネットワークとの間のコンテキスト再同期を実現するために、ＵＥに再確立プロシージャを実施させるための機構を提供する。さらに、いくつかの例では、ユーザプレーンデータ無線ベアラの動作に影響を及ぼさない、制御プレーンのみの再確立プロシージャが提供される。

例示的な実施形態の利点は、以下のうちの１つまたは複数を含み得る。ネットワークは、ネットワークとＵＥとの間でＵＥコンテキスト、設定、ＲＲＣ状態などを同期させるために、ＵＥに再確立プロシージャを実施させ得る。再確立のトリガリングは現在、ＵＥにおける条件、たとえば、無線リンク障害の検出、およびＵＥがコンパイルすることが可能でなかった再設定の受信に基づいて実施されるにすぎず、したがってＵＥ駆動型である。したがって、例示的な実施形態は、ネットワーク駆動型ＲＲＣ再確立プロシージャを導入する。いくつかの例では、制御プレーン再確立プロシージャが提供され、このプロシージャは、ユーザプレーンデータ無線ベアラに影響を及ぼさず、厳しいレイテンシおよび存続時間要件をもつベアラ／サービス（たとえばＵＲＬＬＣ）のためのＵＥにおけるサービス品質（ＱｏＳ）要件が、ＵＥに関連付けられたまたはＵＥをサーブする制御プレーン機能が利用不可能なことの場合さえ、満たされ得ることを保証し得る。また、いくつかの例では、シグナリング最適化が達成され得、すなわち、ネットワークが、ネットワークとＵＥとにおけるＵＥのコンテキストが同期中であることを了解する場合、現在常に必要とされる、再確立の後に再設定メッセージを送ることを行う必要がないことになる。再同期が必要とされる場合でも、いくつかの例では、完全な再設定の代わりに部分再設定が送られ得る。

本開示の例では、言及される制御プレーン機能が、たとえば中央ユニット制御プレーン（ＣＵ－ＣＰ）を備え得る。

図１０は、ＲＲＣ再確立プロシージャを実施するユーザ機器（ＵＥ）における方法１０００のフローチャートである。方法は、ステップ１００２において、ネットワークノード（たとえば分散ユニット（ＤＵ））からＲＲＣ再確立プロシージャを実施するようにとの命令を受信することを含む。方法１０００は、ステップ１００４において、ＲＲＣ再確立要求を送信することをも含む。したがって、たとえば、方法１０００は、ネットワーク駆動型またはネットワーク始動型ＲＲＣ再確立プロシージャを提供し得る。

いくつかの例では、ＲＲＣ再確立要求は、ＵＥのためのＲＲＣ制御プレーン接続のみを再確立するようにとの要求を含む。これは、ＵＥをサーブする制御プレーン機能が失敗したかまたは利用不可能である場合、有用であり得る。いくつかの例では、したがって、制御プレーンのみのＲＣ再確立プロシージャは、ＵＥにおけるユーザプレーンの動作に影響を及ぼさないことがあり、したがって、たとえばユーザプレーンＤＲＢは影響を受けないことがある。いくつかの例では、メッセージのタイプ、および／あるいはフラグまたは情報エレメント（ＩＥ）などのメッセージ中の指示は、ＲＲＣ再確立要求が制御プレーンのみの再確立のためのものであることを指示し得る。

追加または代替として、いくつかの例では、ネットワークノードからの命令は、制御プレーンのみの再確立プロシージャを実施するようにとの命令を含む。たとえば、命令を含んでいるメッセージのタイプは、ＲＲＣ再確立プロシージャが制御プレーンのみのためのものであることを指示し得、および／またはそのメッセージは、ＲＲＣ再確立プロシージャが制御プレーンのみのためのものであることを指示する指示（たとえばフラグまたはＩＥ）を含んでいることがある。したがって、たとえば、そのプロシージャが制御プレーンのみのためのものである場合、方法１０００は、いくつかの例では、ＵＥのためのユーザプレーンＵＥコンテキストを維持することを含み得る。これは、たとえば、命令を受信する前に設定された１つまたは複数のデータ無線ベアラ（ＤＲＢ）を使用し続けることを含み得る。いくつかの例では、これは、ＵＥのユーザプレーン動作に対する中断がほとんどまたはまったくないことを保証し得る。いくつかの例では、方法１０００は、ユーザプレーンデータ無線ベアラ（ＤＲＢ）を中断することなしにＲＲＣ再確立プロシージャを実施することを含む。

いくつかの例では、ＵＥは、命令を受信する前に第１の基地局制御プレーン機能に関連付けられ、ＲＲＣ再確立プロシージャは、第２の基地局制御プレーン機能への制御プレーン接続を再確立する。第１および／または第２の制御プレーン機能は、たとえば中央ユニット制御プレーン（ＣＵ－ＣＰ）であり得る。したがって、方法１０００は、たとえば、ＲＲＣ再確立要求に応答して、第１の制御プレーン機能からの代わりに、第２の基地局制御プレーン機能からＲＲＣ再確立メッセージを受信することを含み得る。いくつかの例では、命令は、第２の基地局制御プレーン機能から、およびいくつかの例ではネットワークノードを介して、受信される。

方法１０００は、いくつかの例では、ＲＲＣ再確立プロシージャの間、次の予想されるＲＲＣメッセージシーケンス番号をリセットする間および／またはリセットすることなしに、ＭＡＣバッファおよび／またはＲＬＣバッファをフラッシュするのを控えることを含み得る。そのような特徴は、いくつかの例では、ＵＥのユーザプレーン機能への影響を低減するかまたはなくし得る。

いくつかの例では、方法１０００は、ＲＲＣ再確立プロシージャ（たとえば図６に示されているプロシージャ）を実施することであって、ＲＲＣ再確立プロシージャが、ＲＲＣ再確立要求を送信するステップ１００４を含む、ＲＲＣ再確立プロシージャを実施することを含む（たとえば、ステップ１００４は、図６に示されている第１のステップである）。

いくつかの例では、ネットワークノードから命令を受信することは、ネットワークノードからＲＲＣメッセージを受信することと、完全性検証鍵を使用して、ＲＲＣメッセージに対して完全性検証を実施することと、完全性検証が失敗した場合、ＲＲＣメッセージがＲＲＣ再確立プロシージャを実施するようにとの命令であると決定することとを含む。したがって、たとえば、ネットワークノード（または、ネットワーク中の他のノード）は、正しくないまたは代替の完全性保護鍵を使用して、ＲＲＣメッセージに対して暗号化または完全性保護を意図的に実施し得、したがって、そのメッセージはＵＥにおいて完全性保護に失敗することになる。これは、ＲＲＣ再確立プロシージャをトリガし得る。いくつかの例では、制御プレーンのみの再確立プロシージャが最初に試みられ、その後に、制御プレーンのみのプロシージャが成功しない場合は「完全な」再確立プロシージャが続き得る。したがって、ＵＥにおける完全性検証の失敗は、いくつかの例では、ＲＲＣ再確立プロシージャ（制御プレーンのみまたはそれ以外）を実施するようにとの暗示された命令であり得る。

ステップ１００２において受信された命令は、いくつかの例では、ＭＡＣ制御エレメント（ＣＥ）中で、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）上で送信されるダウンリンク制御情報（ＤＣＩ）中で、システム情報ブロック（ＳＩＢ）中のフラグ中で、またはブロードキャストメッセージ中で受信され得る。

いくつかの例では、ＲＲＣ再確立要求は、ＲＲＣ再確立プロシージャが制御プレーンのみの再確立プロシージャであるという指示を含む。追加または代替として、いくつかの例では、ＲＲＣ再確立要求は、命令を受信する前の直近に受信されたＲＲＣメッセージのシーケンス番号の指示を含む。

図１１は、ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するネットワークノードにおける方法１１００のフローチャートである。ネットワークノードは、たとえば分散ユニット（ＤＵ）あるいは任意の他の好適なネットワークノードまたは機能を備え得る。方法１１００は、ステップ１１０２において、ＵＥに関連付けられた（たとえばＵＥをサーブする）第１の基地局制御プレーン機能（たとえばＣＵ－ＣＰ）が利用不可能であると決定することを含む。たとえば、第１の制御プレーン機能は、失敗していることがある。方法１１００のステップ１１０４は、ＵＥに、少なくとも、第２の基地局制御プレーン機能との制御プレーン接続を再確立させるために、ＲＲＣ再確立プロシージャを実施するようにとの命令をＵＥに送ることを含む。これは、いくつかの例では、上記で言及されたステップ１００２においてＵＥによって受信された命令であり得る。命令は、いくつかの例では、ＭＡＣ制御エレメント（ＣＥ）中で、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）上で送信されるダウンリンク制御情報（ＤＣＩ）中で、システム情報ブロック（ＳＩＢ）中のフラグ中で、またはブロードキャストメッセージ中で送られ得る。

いくつかの例では、方法は、命令をＵＥに送った後に、ＵＥからＲＲＣ再確立要求を受信することと、ＲＲＣ再確立要求を第２の基地局制御プレーン機能にフォワーディングすることとを含み得る。したがって、第２の基地局制御プレーン機能（たとえばＣＵ－ＣＰ）は、たとえば再確立プロシージャの結果として、ＵＥをサーブすることに対する責任を引き継ぎ、したがって、ＵＥに関連付けられる、制御プレーン機能であり得る。いくつかの例では、ＲＲＣ確立要求は、（たとえば、要求中で指示されるように）ＵＥのためのＲＲＣ制御プレーン接続のみを再確立するようにとの要求を含む。追加または代替として、ＵＥに送られた命令は、いくつかの例では上記で示唆されるように、制御プレーンのみの再確立プロシージャを実施するようにとの命令を含む。ＲＲＣ再確立要求は、いくつかの例では、ＲＲＣ再確立プロシージャが制御プレーンのみの再確立プロシージャであるという指示を含み得る。ＲＲＣ再確立要求は、いくつかの例では、命令を受信する前の直近に受信されたＲＲＣメッセージのシーケンス番号（ＳＮ）の指示を含み得る。

いくつかの例では、方法１１００は、ＵＥのためのユーザプレーンＵＥコンテキストを維持することを含む。これは、ＵＥについてほとんどまたはまったくないユーザプレーン中断を保証し得る。ＵＥのためのユーザプレーンＵＥコンテキストを維持することは、いくつかの例では、ステップ１１０２および／または１１０４の前に設定された１つまたは複数のデータ無線ベアラ（ＤＲＢ）を使用し続けることを含む。いくつかの例では、命令は、ユーザプレーンデータ無線ベアラ（ＤＲＢ）を中断することなしにＲＲＣ再確立プロシージャを実施するようにとのＵＥへの命令を含む。

ＵＥは、いくつかの例では、命令を受信する前に第１の基地局制御プレーン機能（たとえばＣＵ－ＣＰ）に関連付けられ得る。ＲＲＣ再確立プロシージャは、次いで、第２の基地局制御プレーン機能（たとえばＣＵ－ＣＰ）への制御プレーン接続を再確立し得る。

いくつかの例では、ステップ１１０４において命令をＵＥに送ることは、第２の基地局制御プレーン機能から命令を受信することと、命令をＵＥにフォワーディングすることとを含む。したがって、これらの例では、第２の制御プレーン機能は、ネットワークノード（たとえばＤＵ）を介して再確立プロシージャを始動し得る。

命令をＵＥに送ることは、いくつかの例では、たとえば上記で説明されたプロシージャと同様に、正しくない暗号化鍵でＲＲＣメッセージを暗号化することと、ＲＲＣメッセージをＵＥにフォワーディングすることとを含む。

図１２は、本明細書で説明される方法の間のネットワークにおける通信１２００の特定の例示的な実施形態を示す。ネットワークは、ＵＥ１２０２と、ＤＵ１２０４と、第１の制御プレーン機能ＣＵ－ＣＰ１ １２０６と、第２の制御プレーン機能ＣＵ－ＣＰ２ １２０８と、ＵＥコンテキストデータベース１２１０と、中央ユニットユーザプレーン（ＣＵ－ＵＰ）１２１２と、アクセスおよびモビリティ管理機能（ＡＭＦ）１２１４と、ユーザプレーン機能（ＵＰＦ）１２１６とを含む。

この例では、ＵＥとネットワークとを再同期させるために、ＲＲＣ再確立プロシージャが使用され得る。この例は、いくつかの場合には、遅延またはユーザプレーンデータ送信／受信中断につながり得るが、これは、ＵＥが初め（たとえばＮＡＳ回復）から接続を確立しなければならない場合、いくつかの例ではＮＡＳ回復よりも依然として速くなり得る。しかしながら、現在のプロシージャは、ネットワーク始動型再確立を可能にしない。

図１２の通信１２００のステップ１ａ）において、ＵＥ１２０２は、Ｓｕ１２０４とＣＵ－ＣＰ１ １２０６とを介したＡＭＦ１２１４への制御プレーン接続を有し、ステップ１ｂ）において、ＵＥ１２０２は、ＤＵ１２０４とＣＵ－ＵＰ１２１２とを介したＵＰＦ１２１６へのＰＤＵセッションのためのユーザプレーン接続を有する。ステップ２）において、ＣＵ－ＣＰ１が、ＣＵ－ＣＰ２ １２０８および／またはＵＥコンテキストデータベース１２１０にＵＥ情報を書き込む。したがって、たとえば、ＵＥのために（１つまたは複数の）ＵＥコンテキストが記憶または更新され得る。ステップ３）において、ＣＵ－ＣＰ１ １２０６は、失敗するか、または別の理由で利用不可能になる。ステップ４）において、ＤＵ１２０４は、ＣＵ－ＣＰ１ １２０６の失敗またはＣＵ－ＣＰ１ １２０６が利用不可能なことを検出する。ステップ５において、ＤＵ１２０４は、たとえば、上記で説明されたステップ１００２および１１０４に従って、ＵＥ１２０２におけるＲＲＣ再確立をトリガする。

ステップ６ａ）において、ＲＬＣおよびＭＡＣレイヤが、ＵＥ１２０２においてフラッシュされ、ステップ６ｂ）において、ＲＬＣおよびＭＡＣレイヤが、ＤＵ１２０４においてフラッシュされる。したがって、ステップ７）において、ユーザプレーン接続は中断される。ステップ８）において、図示の例では、ランダムアクセスプロシージャ（ＲＡＣＨ）がある。たとえば、ランダムアクセスおよびランダムアクセス応答（ＲＡＲ）プロシージャが、ＵＥとＤＵとの間で実施される。ＵＥは、ランダムアクセスチャネル（ＲＡＣＨ）上でスペシャルプリアンブルを送り、ネットワーク（たとえばＤＵ）は、ランダムアクセス応答（ＲＡＲ）で応答し、「グラント」は、アップリンクＲＲＣシグナリングを送るためのアップリンクリソース割り振りを含む。ＲＡＲメッセージはまた、アップリンク時間同期を保証するための時間整合情報を含んでいることがある。

ステップ９）において、ＤＵ１２０４は、ＣＵ－ＣＰ２ １２０８を選択する。ステップ１０において、ＵＥ１２０２は、たとえば上記で説明されたステップ１００４に従って、ＲＲＣ再確立要求を送る。ステップ１１）において、要求を受信したＣＵ－ＣＰ２ １２０８は、ＵＥコンテキストデータベース１２１０からＵＥコンテキストを取り出す。ＣＵ－ＣＰ２ １２０８は、次いで、ステップ１２）において、ＲＲＣ再確立メッセージをＵＥ１２０２に送る。ステップ１３）において、ＵＥ１２０２は、ＲＲＣ再確立完了メッセージでＣＵ－ＣＰ２ １２０８に返答する。

ステップ１４）において、ＣＵ－ＣＰ２ １２０８は、ＡＭＦ１２１４を更新する（たとえば、ＣＵ－ＣＰ２ １２０８は、たとえばＮＧ－ＡＰシグナリング関連付けの動きのみを指示する経路切替えプロシージャを実施することによって、ＡＭＦ１２１４へのＮＧ－Ｃインターフェースを更新する）。ステップ１５）において、この例では、同じＣＵ－ＵＰ１２１２が依然として使用され、ＣＵ－ＣＰ２ １２０８は、ＣＵ－ＵＰ１２１２中の関連のあるＵＥコンテキストを引き継ぐ。ステップ１６）において、ＣＵ－ＣＰ２ １２０８は、ＵＥ ＲＲＣ状態の随意の再同期をトリガし得る。このステップは、たとえばＵＥへ向かう保留中のＲＲＣプロシージャがある場合、ＵＥコンテキストデータベース１２１０コンテキストに依存し得る。ステップ１７ｂ）において、ＵＥ１２０２は、ＤＵ１２０４とＣＵ－ＵＰ１２１２とを介したＵＰＦ１２１６へのＰＤＵセッションのためのユーザプレーン接続を有する。

通常の条件の間、いくつかの例では、ＵＥを現在サーブしているＣＵ－ＣＰ１ １２０６は、バックアップ制御プレーン機能（ＣＵ－ＣＰ２ １２０８）またはＵＥコンテキストデータベース１２１０中のＵＥコンテキストを継続的にまたは周期的に記憶または更新する。ＤＵ１２０４は、たとえば以下などのいくつかのやり方のうちの１つで制御プレーン機能ＣＵ－ＣＰ１ １２０６が利用不可能なことを検出することができる。
－ ＳＣＴＰキープアライブ要求に対する応答の欠如
－ 所与の時間内に必要とされるＦ１－ＡＰコンテキスト修正などのＦ１－ＡＰメッセージに対する応答を受信しないこと
－ 失敗したＣＵ－ＣＰから（再開時）、または利用不可能な制御プレーン機能から責任を引き継いだ新しいＣＵ－ＣＰから、明示的指示を受信すること。

ＣＵ－ＣＰ２が（１つまたは複数の）ＵＥコンテキストをすでに有する場合（たとえば、ＵＥコンテキストが、ステップ２）においてＣＵ－ＣＰ２ １２０８中で更新されたままであった場合）、ステップ１１におけるコンテキスト取出しデータベースからのＵＥコンテキスト取出しの必要がない。

図１２に示されている例は、ネットワークが、ＲＲＣ接続を再確立するようにＵＥをトリガすることと、それにより、ＵＥコンテキスト再同期が実施されることを保証することとを可能にする。しかしながら、ユーザプレーンデータの可能な中断があり得る。これを緩和するために、いくつかの例では、制御プレーンまたは制御プレーンの部分（たとえばＳＲＢ１）のみが、再確立される必要がある。たとえば、ＵＥによって受信された命令は、制御プレーンのみの再確立プロシージャをトリガし得、ＵＥは、ＭＡＣ／ＲＬＣバッファをフラッシュするのを控え、データ無線ベアラの受信／送信を休止しないことがある。図１３は、そのような例による、ネットワークにおける通信１３００の一例を示す。ネットワークは、ＵＥ１２０２と、ＤＵ１２０４と、第１の制御プレーン機能ＣＵ－ＣＰ１ １２０６と、第２の制御プレーン機能ＣＵ－ＣＰ２ １２０８と、ＵＥコンテキストデータベース１２１０と、中央ユニットユーザプレーン（ＣＵ－ＵＰ）１２１２と、アクセスおよびモビリティ管理機能（ＡＭＦ）１２１４と、ユーザプレーン機能（ＵＰＦ）１２１６とを含む。

図１３に示されているステップ１ａ）～４）は、図１２に示され、上記で説明されたステップ１ａ）～４）と同様である。しかしながら、ステップ５）において、ＤＵ１２０４は、制御プレーン（ＣＰ）のみのＲＲＣ再確立をトリガし、ステップ６）において、ユーザプレーン接続は中断されない。たとえば、ＲＬＣおよびＭＡＣバッファは、ＵＥ１３０２およびＤＵ１３０４によってフラッシュされないことがある。

ステップ７）において、ＤＵ１２０４は、ＣＵ－ＣＰ２ １２０８を選択する。ステップ８）において、ＵＥ１２０２は、たとえば上記で説明されたステップ１００４に従って、ＲＲＣ再確立要求を送る。ステップ９）において、要求を受信したＣＵ－ＣＰ２ １２０８は、ＵＥコンテキストデータベース１２１０からＵＥコンテキストを取り出す。ＣＵ－ＣＰ２ １２０８は、次いで、ステップ１０）において、ＲＲＣ再確立メッセージをＵＥ１２０２に送る。ステップ１１）において、ＵＥ１２０２は、ＲＲＣ再確立完了メッセージでＣＵ－ＣＰ２ １２０８に返答する。

ステップ１２）において、ＣＵ－ＣＰ２ １２０８は、ＡＭＦ１２１４を更新する（たとえば、ＣＵ－ＣＰ２ １２０８は、たとえばＮＧ－ＡＰシグナリング関連付けの動きのみを指示する経路切替えプロシージャを実施することによって、ＡＭＦ１２１４へのＮＧ－Ｃインターフェースを更新する）。ステップ１３）において、この例では、同じＣＵ－ＵＰ１２１２が依然として使用され、ＣＵ－ＣＰ２ １２０８は、ＣＵ－ＵＰ１２１２中の関連のあるＵＥコンテキストを引き継ぐ。ステップ１４）において、ＣＵ－ＣＰ２ １２０８は、ＵＥ ＲＲＣ状態の随意の再同期をトリガし得る。このステップは、たとえばＵＥへ向かう保留中のＲＲＣプロシージャがある場合、ＵＥコンテキストデータベース１２１０コンテキストに依存し得る。ステップ１５）において、ＵＥ１２０２は、ＤＵ１２０４とＣＵ－ＵＰ１２１２とを介したＵＰＦ１２１６へのＰＤＵセッションのためのユーザプレーン接続を有する。

上記では、ステップ５）において再確立をトリガするために使用されたメッセージは、いくつかの例では、下位レイヤシグナリング（たとえば、ＭＡＣ制御エレメント（ＣＥ）、ダウンリンク制御情報（ＤＣＩ）、システム情報ブロック（ＳＩＢ）シグナリングなど）を使用してＤＵ１２０４から送られ得る。しかしながら、いくつかの代替ソリューションがある。一例では、ＤＵ１２０４は、ＣＵ－ＣＰ１ １２０６が利用不可能なことに関してＣＵ－ＣＰ２ １２０８に通知し得、ＣＵ－ＣＰ２ １２０８は、ＵＥ１２０２に再確立メッセージを送る。ＤＵ１２０４は、これをＵＥ１２０２に透過的にフォワーディングする。代替的に、たとえば、ＣＵ－ＣＰ２ １２０８は、ＣＵ－ＣＰ１ １２０６が利用不可能なことを検出し得、ＤＵ１２０４を介してＵＥ１２０２に制御プレーンのみの再確立命令を送る。いずれの場合も、ＤＵは、これが制御プレーンのみの再確立であり、ユーザプレーンバッファ（たとえばＭＡＣおよびＲＬＣ）をフラッシュする必要がないことを（再確立命令中で暗黙的に、または明示的にのいずれかで）通知され得る。

いくつかの例では、ＣＵ－ＣＰ２ １２０８は、上記で示唆されたように、ＲＲＣパケットを生成し、そのＲＲＣパケットを正しくない鍵（たとえばランダムまたは代替の鍵）で完全性保護し、そのＲＲＣパケットをＵＥ１２０２に送り得る。ＵＥ１２０２は、着信ＲＲＣパケットに対して完全性検証を実施し、完全性検証失敗を検出することになる。レガシーＵＥは、通常の再確立プロシージャをトリガすることになるが、いくつかの例では、上記で示唆されるように最初に制御プレーンのみの再確立を実施することを試み得る。ネットワークは、ネットワークが正しくない完全性保護を伴うＲＲＣパケットを送ることによって再確立を命令したことを知っているので、ネットワークは、いくつかの例では、制御プレーンのみの再確立プロシージャを実施し得る。

再確立が（無線リンク障害などの）レガシー再確立原因により始動されないことをネットワークに知らせるために、いくつかの例では、新しい再確立原因値（たとえばＣＰ－Ｆａｉｌｕｒｅ）が導入され得る。これは、たとえば、制御プレーン機能失敗がＤＵ１２０４によって検出された場合、ＣＵ－ＣＰ２ １２０８にとって有用であり得、したがって、それが制御プレーンのみの再確立であることにＤＵ１２０４が気づいている。

（たとえば上記で説明されたステップ１００４において送られるような）再確立要求メッセージ中に、ＵＥは、いくつかの例では、最後の受信されたＲＲＣ（たとえばＳＲＢ１）メッセージのＰＤＣＰシーケンス番号（ＳＮ）、または次の予想されるＰＤＣＰ ＳＮを含め得る。ネットワークは、したがって、ネットワークが送った最新のＲＲＣメッセージをＵＥが受信したかどうか検証し得、受信した場合、ＵＥおよびネットワークコンテキストは同期中であり、後続の再設定メッセージをＵＥに送る必要がないことになる。ネットワークが、ＵＥとネットワークとの間のＵＥコンテキストが異なる（たとえば、再確立メッセージ中で指示された最後に受信されたＰＤＣＰ ＳＮが、ネットワークがＵＥに送った最後のＳＲＢ１メッセージのために使用されたＳＮよりもより小さい）ことを発見した場合、ネットワークは、同期を達成するために後続の再設定メッセージを送り得る。

前の再確立プロシージャでは、ＳＲＢ１についてのＰＤＣＰが再確立され、これは、ＳＲＢ１についてのシーケンス番号（ＳＮ）が初期値にリセットされることを生じる。その結果、同じ鍵が同じＳＮを伴って使用されないことを保証するために（再確立メッセージ中の受信されたＮＣＣを使用して）、再確立の間、セキュリティ鍵が更新される。制御プレーンのためのセキュリティ鍵の変更は、ユーザプレーンのためのセキュリティ鍵の変更をも生じることがあり、これは、ＤＲＢについてＲＬＣ／ＭＡＣバッファが（それらが、古い鍵を使用して暗号化／完全性保護されたデータを含んでいるので）リセットされなければならず、確認応答を保留しているすべてのＰＤＣＰパケットが、新しい鍵で暗号化／完全性保護された後に再送信される必要があることになることを意味し得る。これは、ユーザプレーントラフィックについてのレイテンシの増加を生じ得る。しかしながら、本開示の例は、これらの欠点を緩和し得る。たとえば、ＵＥおよびネットワークは、制御プレーンのみの再確立プロシージャについて、セキュリティ鍵（たとえばユーザプレーンセキュリティ鍵）を変更しないか、またはシーケンス番号をリセットしないことがある。

本明細書で説明されるように制御プレーンのみの再確立プロシージャを可能にするための３ＧＰＰ仕様３８．３３１、ｖ１６．０．０の変更の一例が、以下で示される。
********************************************************************************
５．３．７．２ 始動
ＵＥは、以下の条件のうちの１つが満足されるとき、プロシージャを始動する。
１＞ ５．３．１０による、ＭＣＧの無線リンク障害、およびＴ３１６が設定されないことを検出すると、あるいは
１＞ サブクローズ５．３．５．８．３による、ＭＣＧの同期を伴う再設定失敗（ｒｅ－ｃｏｎｆｉｇｕｒａｔｉｏｎ ｗｉｔｈ ｓｙｎｃ ｆａｉｌｕｒｅ）時に、あるいは
１＞ サブクローズ５．４．３．５による、ＮＲからのモビリティ失敗（ｍｏｂｉｌｉｔｙ ｆｒｏｍ ＮＲ ｆａｉｌｕｒｅ）時に、あるいは
１＞ 完全性検査失敗がＲＲＣＲ再確立メッセージ上で検出される場合を除いて、ＳＲＢ１またはＳＲＢ２に関係する下位レイヤからの完全性検査失敗指示時に、あるいは
１＞ サブクローズ５．３．５．８．２による、ＲＲＣ接続再設定失敗時に、あるいは
１＞ ＮＲ－ＤＣにおけるサブクローズ５．３．１０．３による、またはＮＥ－ＤＣにおけるＴＳ３６．３３１［１０］サブクローズ５．３．１１．３による、ＭＣＧ送信が中断されている間にＳＣＧについての無線リンク障害を検出すると、あるいは
１＞ サブクローズ５．３．５．８．３による、ＭＣＧ送信が中断されている間のＳＣＧの同期を伴う再設定失敗時に、あるいは
１＞ ＴＳ３６．３３１［１０］サブクローズ５．３．５．７ａによる、ＮＥ－ＤＣにおけるＭＣＧ送信の間のＳＣＧ変更失敗時に、あるいは
１＞ ＮＲ－ＤＣにおけるサブクローズ５．３．５．８．２によるまたはＮＥ－ＤＣにおけるＴＳ３６．３３１［１０］サブクローズ５．３．５．５による、ＭＣＧ送信が中断されている間のＳＣＧ設定失敗時に、あるいは
１＞ ＭＣＧが中断されている間のＳＲＢ３に関係するＳＣＧ下位レイヤからの完全性検査失敗指示時に、あるいは
１＞ サブクローズ５．７．３ｂ．５による、Ｔ３１６満了時に、あるいは
１＞ ネットワークが再確立を要求するとの下位レイヤ（ＭＡＣ ＣＥ）からの指示を受信すると
プロシージャの始動時に、ＵＥは、以下を行うものとする。
１＞ 稼働している場合、タイマーＴ３１０を停止する。
１＞ 稼働している場合、タイマーＴ３１２を停止する。
１＞ 稼働している場合、タイマーＴ３０４を停止する。
１＞ タイマーＴ３１１を開始する。
１＞ 稼働している場合、タイマーＴ３１６を停止する。
１＞ 下位レイヤからの指示が再確立をトリガし、それが制御プレーンのみの再確立を指示する場合、
２＞ ５．３．７．４に従ってＲＲＣ ＣＰ再確立要求メッセージの送信を始動する。
１＞ そうでない場合、
２＞ ＭＡＣをリセットする、
２＞ 設定された場合、（１つまたは複数の）ＭＣＧ ＳＣｅｌｌを解放する。
２＞ ＵＥにｃｏｎｄｉｔｉｏｎａｌＲｅｃｏｎｆｉｇｕｒａｔｉｏｎが設定されない場合、
３＞ 設定された場合、ｓｐＣｅｌｌＣｏｎｆｉｇを解放する。
３＞ ＳＲＢ０を除く、すべてのＲＢを中断する。
２＞ ＭＲ－ＤＣが設定された場合、
３＞ クローズ５．３．５．１０において指定されているように、ＭＲ－ＤＣ解放を実施する。
２＞ 設定された場合、ｄｅｌａｙＢｕｄｇｅｔＲｅｐｏｒｔｉｎｇＣｏｎｆｉｇを解放し、稼働している場合、タイマーＴ３４２を停止する。
２＞ 設定された場合、ｏｖｅｒｈｅａｔｉｎｇＡｓｓｉｓｔａｎｃｅＣｏｎｆｉｇを解放し、稼働している場合、タイマーＴ３４５を停止する。
２＞ 設定された場合、ｉｄｃ－ＡｓｓｉｓｔａｎｃｅＣｏｎｆｉｇを解放する。
２＞ 設定された場合、ｄｒｘ－ＰｒｅｆｅｒｅｎｃｅＣｏｎｆｉｇを解放し、稼働している場合、タイマーＴ３４６ａを停止する。
２＞ 設定された場合、ｍａｘＢＷ－ＰｒｅｆｅｒｅｎｃｅＣｏｎｆｉｇを解放し、稼働している場合、タイマーＴ３４６ｂを停止する。
２＞ 設定された場合、ｍａｘＣＣ－ＰｒｅｆｅｒｅｎｃｅＣｏｎｆｉｇを解放し、稼働している場合、タイマーＴ３４６ｃを停止する。
２＞ 設定された場合、ｍａｘＭＩＭＯ－ＬａｙｅｒＰｒｅｆｅｒｅｎｃｅＣｏｎｆｉｇを解放し、稼働している場合、タイマーＴ３４６ｄを停止する。
２＞ 設定された場合、ｍｉｎＳｃｈｅｄｕｌｉｎｇＯｆｆｓｅｔＰｒｅｆｅｒｅｎｃｅＣｏｎｆｉｇを解放し、稼働している場合、タイマーＴ３４６ｅを停止する。
２＞ 設定された場合、ｒｅｌｅａｓｅＰｒｅｆｅｒｅｎｃｅＣｏｎｆｉｇを解放し、稼働している場合、タイマーＴ３４６ｆを停止する。
２＞ ＴＳ３８．３０４［２０］、クローズ５．２．６において指定されているように、セル選択プロセスに従ってセル選択を実施する。
５．３．７．３ Ｔ３１１が稼働している間のセル選択に続くアクション
＜＜スキップされたテキスト＞＞
５．３．７．４ ＲＲＣ再確立要求メッセージの送信に関係するアクション
ＵＥは、以下のようにＲＲＣ再確立要求メッセージのコンテンツをセットするものとする。
１＞ ５．３．１０．３において指定されているような無線リンク障害により、または５．３．５．８．３において指定されているようなハンドオーバ失敗により、プロシージャが始動された場合、
２＞ ＶａｒＲＬＦ－Ｒｅｐｏｒｔ中のｒｅｅｓｔａｂｌｉｓｈｍｅｎｔＣｅｌｌＩｄを、選択されたセルのグローバルセル識別情報にセットする。
１＞ 以下のようにｕｅ－Ｉｄｅｎｔｉｔｙをセットする。
２＞ ｃ－ＲＮＴＩを、ソースＰＣｅｌｌ中で使用されるＣ－ＲＮＴＩにセットする（同期を伴う再設定またはＮＲからのモビリティ失敗）か、または再確立のためのトリガが発生したＰＣｅｌｌ中で使用されるＣ－ＲＮＴＩにセットする（他のケース）。
２＞ ｐｈｙｓＣｅｌｌＩｄを、ソースＰＣｅｌｌの物理セル識別情報にセットする（同期を伴う再設定またはＮＲからのモビリティ失敗）、または再確立のためのトリガが発生したＰＣｅｌｌの物理セル識別情報にセットする（他のケース）。
２＞ ｓｈｏｒｔＭＡＣ－Ｉを、
３＞ クローズ８（すなわち、８ビットの倍数）ＶａｒＳｈｏｒｔＭＡＣ－Ｉｎｐｕｔに従って符号化されたＡＳＮ．１にわたって、
３＞ ソースＰＣｅｌｌ中で使用されたＫ_{ＲＲＣｉｎｔ}鍵と完全性保護アルゴリズムとを用いて（同期を伴う再設定またはＮＲからのモビリティ失敗）、または再確立のためのトリガが発生したＰＣｅｌｌのＫ_{ＲＲＣｉｎｔ}鍵と完全性保護アルゴリズムとを用いて（他のケース）、および
３＞ バイナリ１にセットされた、ＣＯＵＮＴ、ＢＥＡＲＥＲおよびＤＩＲＥＣＴＩＯＮのためのすべての入力ビットを用いて
計算されたＭＡＣ－Ｉの１６個の最下位ビットにセットする。
１＞ ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを以下のようにセットする。
２＞ 再確立プロシージャが、５．３．５．８．２において指定されているように、再設定失敗により始動された場合、
３＞ ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを値ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎＦａｉｌｕｒｅにセットする。
２＞ そうではなく、再確立プロシージャが、５．３．５．８．３（ＮＲ内ハンドオーバ失敗）または５．４．３．５（ＮＲからのＲＡＴ間モビリティ失敗）において指定されているように、同期を伴う再設定失敗により始動された場合、
３＞ ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを値ｈａｎｄｏｖｅｒＦａｉｌｕｒｅにセットする。
２＞ そうではなく、再確立プロシージャが、ＣＰのみの再確立をトリガするようにとの指示の受信により始動された場合、
３＞ ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを値ＣＰ－Ｆａｉｌｕｒｅにセットする。
２＞ そうでない場合、
３＞ ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを値ｏｔｈｅｒＦａｉｌｕｒｅｒにセットする。
１＞ ＳＲＢ１についてのＰＤＣＰを再確立する。
１＞ ＳＲＢ１についてのＰＬＣを再確立する。
１＞ ＳＲＢ１について９．２．１において規定されている指定された設定を適用する。
１＞ ＳＲＢ１について完全性保護およびサイファ化を中断するように下位レイヤを設定する。
注： サイファ化は、接続を再開するために使用される後続のＲＲＣ再確立メッセージのために適用されない。完全性検査は、下位レイヤによって実施されるが、ＲＲＣからの要求時に実施されるにすぎない。
１＞ ＳＲＢ１を再開する。
１＞ 送信のためにＲＲＣ接続再確立要求メッセージを下位レイヤにサブミットする。
５．３．７．５ ＵＥによるＲＲＣ再確立の受信
ＵＥは、以下を行うものとする。
１＞ タイマーＴ３０１を停止する。
１＞ 現在のセルをＰＣｅｌｌであると見なす。
１＞ ｒｅｅｓｔａｂｌｉｓｈＣＰが指示される場合、
２＞ 送信のためにＲＲＣ再確立完了メッセージを下位レイヤにサブミットする。
２ プロシージャが終了する。
１＞ ＲＲＣ再確立メッセージ中で指示されるｎｅｘｔＨｏｐＣｈａｉｎｉｎｇＣｏｕｎｔ値を記憶する。
１＞ ＴＳ３３．５０１［１１］において指定されているように、記憶されたｎｅｘｔＨｏｐＣｈａｉｎｉｎｇＣｏｕｎｔ値を使用して、現在のＫ_ｇＮＢ鍵またはＮＨに基づいて、Ｋ_ｇＮＢ鍵を更新する。
１＞ ＴＳ３３．５０１［１１］において指定されているように、前に設定されたｃｉｐｈｅｒｉｎｇＡｌｇｏｒｉｔｈｍに関連付けられたＫ_{ＲＲＣｅｎｃ}鍵およびＫ_{ＵＰｅｎｃ}鍵を導出する。
１＞ ＴＳ３３．５０１［１１］において指定されているように、前に設定されたｉｎｔｅｇｒｉｔｙＰｒｏｔＡｌｇｏｒｉｔｈｍに関連付けられたＫ_{ＲＲＣｉｎｔ}鍵およびＫ_{ＵＰｉｎｔ}鍵を導出する。
１＞ 前に設定されたアルゴリズムとＫ_{ＲＲＣｉｎｔ}鍵とを使用して、ＲＲＣ再確立メッセージの完全性保護を検証するように下位レイヤに要求する。
１＞ ＲＲＣ再確立メッセージの完全性保護検査が失敗した場合、
２＞ 解放原因「ＲＲＣ接続失敗」を伴って、５．３．１１において指定されているような、ＲＲＣ＿ＩＤＬＥに入るときのアクションを実施し、そのとき、プロシージャが終了する。
１＞ 前に設定されたアルゴリズムとＫ_{ＲＲＣｉｎｔ}鍵とを直ちに使用して、ＳＲＢ１について完全性保護を再開するように下位レイヤを設定し、すなわち、完全性保護は、プロシージャの正常な完了を指示するために使用されるメッセージを含む、ＵＥによって受信され、送られるすべての後続のメッセージに適用されるものとする。
１＞ 前に設定されたアルゴリズムとＫ_{ＲＲＣｅｎｃ}鍵とを直ちに使用して、ＳＲＢ１についてサイファ化を再開するように下位レイヤを設定し、すなわち、サイファ化は、プロシージャの正常な完了を指示するために使用されるメッセージを含む、ＵＥによって受信され、送られるすべての後続のメッセージに適用されるものとする。
１＞ 設定された場合、ｍｅａｓＧａｐＣｏｎｆｉｇによって指示された測定ギャップ設定を解放し、
１＞ ＲＲＣ再確立完了メッセージのコンテンツを以下のようにセットする。
２＞ ＵＥが、ＮＲのために利用可能なロギングされた測定を有する場合、およびＲＰＬＭＮが、ＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔに記憶されたｐｌｍｎ－ＩｄｅｎｔｉｔｙＬｉｓｔ中に含まれる場合、
３＞ ｌｏｇＭｅａｓＡｖａｉｌａｂｌｅをＲＲＣ再確立完了メッセージ中に含める。
２＞ ＵＥが、利用可能なＢｌｕｅｔｏｏｔｈのロギングされた測定を有する場合、およびＲＰＬＭＮが、ＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔに記憶されたｐｌｍｎ－ＩｄｅｎｔｉｔｙＬｉｓｔ中に含まれる場合、
３＞ ｌｏｇＭｅａｓＡｖａｉｌａｂｌｅＢＴをＲＲＣ再確立完了メッセージ中に含める。
２＞ ＵＥが、利用可能なＷＬＡＮのロギングされた測定を有する場合、およびＲＰＬＭＮが、ＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔに記憶されたｐｌｍｎ－ＩｄｅｎｔｉｔｙＬｉｓｔ中に含まれる場合、
３＞ ｌｏｇＭｅａｓＡｖａｉｌａｂｌｅＷＬＡＮをＲＲＣ再確立完了メッセージ中に含める。
２＞ ＵＥが、ＶａｒＣｏｎｎＥｓｔＦａｉｌＲｅｐｏｒｔ中で利用可能な接続確立失敗情報を有する場合、およびＲＰＬＭＮが、ＶａｒＣｏｎｎＥｓｔＦａｉｌＲｅｐｏｒｔに記憶されたｐｌｍｎ－Ｉｄｅｎｔｉｔｙに等しい場合、
３＞ ｃｏｎｎＥｓｔＦａｉｌＩｎｆｏＡｖａｉｌａｂｌｅをＲＲＣ再確立完了メッセージ中に含める。
２＞ ＵＥが、ＶａｒＲＬＦ－Ｒｅｐｏｒｔ中で利用可能な無線リンク障害またはハンドオーバ失敗情報を有する場合、およびＲＰＬＭＮが、ＶａｒＲＬＦ－Ｒｅｐｏｒｔに記憶されたｐｌｍｎ－ＩｄｅｎｔｉｔｙＬｉｓｔ中に含まれる場合、
３＞ ｒｌｆ－ＩｎｆｏＡｖａｉｌａｂｌｅをＲＲＣ再確立完了メッセージ中に含める。
２＞ ＵＥが、ＴＳ３６．３３１［１０］のＶａｒＲＬＦ－Ｒｅｐｏｒｔ中で利用可能な無線リンク障害またはハンドオーバ失敗情報を有する場合、およびＵＥが、クロスＲＡＴ ＲＬＦ報告が可能である場合、およびＲＰＬＭＮが、ＴＳ３６．３３１［１０］のＶａｒＲＬＦ－Ｒｅｐｏｒｔに記憶されたｐｌｍｎ－ＩｄｅｎｔｉｔｙＬｉｓｔ中に含まれる場合、
３＞ ｒｌｆ－ＩｎｆｏＡｖａｉｌａｂｌｅをＲＲＣ再確立完了メッセージ中に含める。
１＞ 送信のためにＲＲＣ再確立完了メッセージを下位レイヤにサブミットする。
１＞ プロシージャが終了する。
********************************************************************************

図１４は、ＲＲＣ再確立プロシージャを実施するためのユーザ機器（ＵＥ）における装置１４００の一例の概略図である。装置１４００は、処理回路１４０２（たとえば、１つまたは複数のプロセッサ）と、処理回路１４０２と通信しているメモリ１４０４とを備える。メモリ１４０４は、処理回路１４０２によって実行可能な命令を含んでいる。装置１４００は、処理回路１４０２と通信しているインターフェース１４０６をも備える。インターフェース１４０６と、処理回路１４０２と、メモリ１４０４とは、直列に接続されて示されているが、これらは、代替的に、任意の他のやり方で、たとえば、バスを介して相互接続され得る。

いくつかの実施形態では、メモリ１４０４は、装置１４００が、ネットワークノードからＲＲＣ再確立プロシージャを実施するようにとの命令を受信することと、ＲＲＣ再確立要求を送信することとを行うように動作可能であるような、処理回路１４０２によって実行可能な命令を含んでいる。いくつかの例では、装置１４００は、図１０を参照しながら上記で説明された方法１０００を行うように動作可能である。

図１５は、ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するネットワークノードにおける装置１５００の一例の概略図である。装置１５００は、処理回路１５０２（たとえば、１つまたは複数のプロセッサ）と、処理回路１５０２と通信しているメモリ１５０４とを備える。メモリ１５０４は、処理回路１５０２によって実行可能な命令を含んでいる。装置１５００は、処理回路１５０２と通信しているインターフェース１５０６をも備える。インターフェース１５０６と、処理回路１５０２と、メモリ１５０４とは、直列に接続されて示されているが、これらは、代替的に、任意の他のやり方で、たとえば、バスを介して相互接続され得る。

一実施形態では、メモリ１５０４は、装置１５００が、ＵＥに関連付けられた第１の基地局制御プレーン機能が利用不可能であると決定することと、ＵＥに、少なくとも、第２の基地局制御プレーン機能との制御プレーン接続を再確立させるために、ＲＲＣ再確立プロシージャを実施するようにとの命令をＵＥに送ることとを行うように動作可能であるような、処理回路１５０２によって実行可能な命令を含んでいる。いくつかの例では、装置１５００は、図１１を参照しながら上記で説明された方法１１００を行うように動作可能である。

上述の例は本発明を限定するのではなく例示するものであること、および、当業者であれば添付の記述の範囲から逸脱することなく、多くの代替例を設計することが可能となることに留意されたい。「含む、備える（ｃｏｍｐｒｉｓｉｎｇ）」という単語は、特許請求の範囲に列挙されているエレメントまたはステップ以外の、エレメントまたはステップの存在を除外せず、「ａ」または「ａｎ」は複数を除外せず、単一のプロセッサまたは他のユニットが、以下の記述に具陳されているいくつかのユニットの機能を果たし得る。「第１の（ｆｉｒｓｔ）」、「第２の（ｓｅｃｏｎｄ）」などの用語が使用される場合、それらは、単に、特定の特徴の好都合な識別のための標示として理解されるべきである。特に、それらは、別段に明記されていない限り、複数のそのような特徴のうちの第１の特徴または第２の特徴（すなわち、時間または空間において発生することになる、そのような特徴のうちの第１のものまたは第２のもの）を記述するものとして解釈されるべきでない。本明細書で開示された方法におけるステップは、別段に明確に述べられていない限り、任意の順序で行われ得る。記述におけるいかなる参照符号も、それらの範囲を限定するものと解釈されるべきではない。

Claims (20)

1. ＲＲＣ再確立プロシージャを実施するユーザ機器（ＵＥ）における方法であって、前記方法が、
   ネットワークノードからＲＲＣ再確立プロシージャを実施するようにとの命令を受信することと、
   前記命令の受信に応答して、ＲＲＣ再確立要求を送信することと
   を含み、
   前記ネットワークノードからの前記命令が、制御プレーンのみの再確立プロシージャを実施するようにとの命令を含む、方法。
2. 前記ＲＲＣ再確立要求が、前記ＵＥのためのＲＲＣ制御プレーン接続のみを再確立するようにとの要求を含む、請求項１に記載の方法。
3. 前記ＵＥのためのユーザプレーンＵＥコンテキストを維持することを含む、請求項２に記載の方法。
4. 前記ＵＥのための前記ユーザプレーンＵＥコンテキストを維持することが、前記命令を受信する前に設定された１つまたは複数のデータ無線ベアラ（ＤＲＢ）を使用し続けることを含む、請求項３に記載の方法。
5. ユーザプレーンデータ無線ベアラ（ＤＲＢ）を中断することなしに前記ＲＲＣ再確立プロシージャを実施することを含む、請求項１から４のいずれか一項に記載の方法。
6. 前記ＵＥが、前記命令を受信する前に第１の基地局制御プレーン機能に関連付けられ、前記ＲＲＣ再確立プロシージャが、第２の基地局制御プレーン機能への制御プレーン接続を再確立する、請求項１から５のいずれか一項に記載の方法。
7. 前記ＲＲＣ再確立要求に応答して、前記第２の基地局制御プレーン機能からＲＲＣ再確立メッセージを受信することを含む、請求項６に記載の方法。
8. 前記ＲＲＣ再確立プロシージャの間、次の予想されるＲＲＣメッセージシーケンス番号をリセットする間および／またはリセットすることなしに、ＭＡＣバッファおよび／またはＲＬＣバッファをフラッシュするのを控えることを含む、請求項１から７のいずれか一項に記載の方法。
9. 前記ネットワークノードから前記命令を受信することは、
   前記ネットワークノードからＲＲＣメッセージを受信することと、
   完全性検証鍵を使用して、前記ＲＲＣメッセージに対して完全性検証を実施することと、
   前記完全性検証が失敗した場合、前記ＲＲＣメッセージがＲＲＣ再確立プロシージャを実施するようにとの命令であると決定することと
   を含む、請求項１から８のいずれか一項に記載の方法。
10. 前記命令が、ＭＡＣ制御エレメント（ＣＥ）中で、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）上で送信されるダウンリンク制御情報（ＤＣＩ）中で、システム情報ブロック（ＳＩＢ）中のフラグ中で、またはブロードキャストメッセージ中で受信される、請求項１から９のいずれか一項に記載の方法。
11. 前記ＲＲＣ再確立要求は、前記ＲＲＣ再確立プロシージャが制御プレーンのみの再確立プロシージャであるという指示を含む、請求項１から１０のいずれか一項に記載の方法。
12. 前記ＲＲＣ再確立要求が、前記命令を受信する前の直近に受信されたＲＲＣメッセージのシーケンス番号の指示を含む、請求項１から１１のいずれか一項に記載の方法。
13. ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するネットワークノードにおける方法であって、前記方法は、
    ＵＥに関連付けられた第１の基地局制御プレーン機能が利用不可能であると決定することと、
    前記ＵＥに関連付けられた前記第１の基地局制御プレーン機能が利用不可能であると決定された場合、前記ＵＥに、少なくとも、第２の基地局制御プレーン機能との制御プレーン接続を再確立させるために、ＲＲＣ再確立プロシージャを実施するようにとの命令を前記ＵＥに送ることと、
    前記命令を前記ＵＥに送った後に、前記ＵＥからＲＲＣ再確立要求を受信することと、前記ＲＲＣ再確立要求を前記第２の基地局制御プレーン機能にフォワーディングすることと
    を含む、方法。
14. 前記命令を前記ＵＥに送ることが、正しくない暗号化鍵でＲＲＣメッセージを暗号化することと、前記ＲＲＣメッセージを前記ＵＥにフォワーディングすることとを含む、請求項１３に記載の方法。
15. 少なくとも１つのプロセッサ上で実行されたとき、前記少なくとも１つのプロセッサに、請求項１から１２のいずれか一項に記載の方法を行わせる命令を含む、コンピュータプログラム。
16. 少なくとも１つのプロセッサ上で実行されたとき、前記少なくとも１つのプロセッサに、請求項１３または１４に記載の方法を行わせる命令を含む、コンピュータプログラム。
17. ＲＲＣ再確立プロシージャを実施するためのユーザ機器（ＵＥ）における装置であって、前記装置が、
    ネットワークノードからＲＲＣ再確立プロシージャを実施するようにとの命令を受信することと、
    前記命令の受信に応答して、ＲＲＣ再確立要求を送信することと
    を行うように設定され、
    前記ネットワークノードからの前記命令が、制御プレーンのみの再確立プロシージャを実施するようにとの命令を含む、装置。
18. 前記装置が、請求項２から１２のいずれか一項に記載の方法を実施するように設定された、請求項１７に記載の装置。
19. ユーザ機器（ＵＥ）にＲＲＣ再確立プロシージャを実施するように命令するためのネットワークノードにおける装置であって、前記装置が、
    ＵＥに関連付けられた第１の基地局制御プレーン機能が利用不可能であると決定することと、
    前記ＵＥに関連付けられた前記第１の基地局制御プレーン機能が利用不可能であると決定された場合、前記ＵＥに、少なくとも、第２の基地局制御プレーン機能との制御プレーン接続を再確立させるために、ＲＲＣ再確立プロシージャを実施するようにとの命令を前記ＵＥに送ることと、
    前記命令を前記ＵＥに送った後に、前記ＵＥからＲＲＣ再確立要求を受信することと、前記ＲＲＣ再確立要求を前記第２の基地局制御プレーン機能にフォワーディングすることと
    を行うように設定された、装置。
20. 前記装置が、請求項１３または１４に記載の方法を実施するように設定された、請求項１９に記載の装置。

Images