このすべての情報は、3GPP TS 23.401を読んで見つけることができます。
今日は通常、高いレベルの抽象的な画像から始めます。 下記を参照してください。
あなたが見ることができるように、図1はX2ベースのハンドオーバとほぼ同じです。SGWを変更する必要がなかった場合、緑色の矢印が先ほど話したケースを示しています（興味があればここで読むことができます） 。 今日我々は、青（青紫色の青色の矢印）で描かれた場合に興味があります。 ハンドオーバがどこで行われたかSGW再配置によるX2インターフェイス。
UEとeNB間の緑色の回線で、SGWの変更なしにハンドオーバ操作の終了時に変更されたパスを示します。 UE、eNB、MMEと新しいSGWとの間の青い線は、古いSGWを新しいものに変更した後に新しい経路を示している。
ハンドオーバの詳細な説明に入る前に、X2インターフェイスベースのハンドオーバに関する一般的な情報はほとんどありません。
一般的なX2ベースのHO記述
これらの手順は、X2インタフェースを使用してソースeNodeBからターゲットeNodeBにUEをハンドオーバするために使用される。これらの手順では、MMEは変更されません。サービングGWが変更されていないか、または再配置されているかによって、2つの手順が定義されます。ソースeNodeBとターゲットeNodeBとの間のX2インタフェースに加えて、手順は、MMEとソースeNodeBとの間だけでなく、MMEとターゲットeNodeBとの間のS1-MMEインタフェースの存在に依存する。
サービングPLMNがX2ベースのハンドオーバの間に変化する場合、例えば、ソースeNodeBは、新しいサービングPLMNとして選択されたPLMNを（ハンドオーバー制限リスト内の）ターゲットeNodeBに示すものとする。
UEは、ハンドオーバコマンドを受信すると、ターゲットセル内の対応するEPS無線ベアラを受信しなかったEPSベアラを除去する。ハンドオーバ実行の一部として、ダウンリンクおよびオプションとしてアップリンクパケットがソースeNodeBからターゲットeNodeBに転送される。 UEがターゲットeNodeBに到着したとき、ソースeNodeBから転送されたダウンリンクデータをそれに送ることができる。 UEからのアップリンクデータは、（ソース）SGWを介してPGWに、またはオプションでソースeNodeBからターゲットeNodeBに転送することができる。ハンドオーバ完了フェーズのみがSGWの潜在的な変更の影響を受け、ハンドオーバ準備と実行フェーズは同一である。
MMEは、X2ハンドオーバが進行中であることを示すeNodeBからのNAS手順（例えば専用ベアラ確立/変更/リリース、位置報告制御、NASメッセージ転送など）に対する拒否を受信した場合、 SGW再配置の場合を除いて、ハンドオーバが完了したか、またはハンドオーバが失敗したとみなされる場合でも、同じNAS手順。故障は、NAS手順を守るタイマーの満了によって知られている。
MMEは、ハンドオーバ手順中にサービングGWの再配置が必要であることを検出した場合（このタイプのHOについては後で説明する）、ハンドオーバ手順が開始された後に受信されたPGW開始EPSベアラ要求を拒否し、進行中のハンドオーバ手順によりリクエストが一時的に拒否されました。拒否はSGWによってPGWに転送され、同じ指示が適用されます。
進行中のハンドオーバ手順のために要求が一時的に拒否されたことを示すEPSベアラPDN GW開始手順に対する拒否を受信すると、PGWはローカルに構成されたガードタイマを開始する。 PGWは、ハンドオーバが完了したことを検出するか、またはメッセージ受信を使用して失敗したか、またはガードタイマーが満了したときに、予め設定された回数まで手順を再試行する。
MMEが、X2ハンドオーバが進行中であるという指示を伴うeNodeBからのCSフォールバックインジケータを有するUEコンテキスト変更要求メッセージに対する拒否を受信した場合、MMEはCSフォールバックインジケータを有するUEコンテキスト変更要求メッセージをターゲットeNodeBに再送するハンドオーバが完了したとき、またはハンドオーバが失敗したとみなされたときにソースeNBに通知する。
サービングGW再配置によるX2ベースのハンドオーバ
この手順は、MMEが変更されておらず、MMEがサービングGWが再配置されるべきであると決定した場合に、X2を使用してUEをソースeNodeBからターゲットeNodeBにハンドオーバーするために使用される。 正直言って、今私がこの記事を準備しているとき、私がこのハンドオーバタイプを使用すると思う理由は、SGWのソフトウェアアップグレードへの準備です。 ソースサービングGWとソースeNodeBとの間、ソースサービングGWとターゲットeNodeBとの間、およびターゲットサービングGWとターゲットeNodeBとの間のIP接続の存在が想定される。 （ターゲットeNodeBとソースサービングGWとの間にIP接続がない場合、代わりにS1ベースのハンドオーバー手順が使用されるものと想定される）。
ステップ1：ターゲットeNodeBは、ターゲットセルのECGIおよび切り替えられるEPSベアラのリストを含む、UEがセルを変更したことを通知するために、MMEにパス切り替え要求メッセージを送信する。 MMEは、サービングGWが再配置されたと判定し、新たなサービングGWを選択する。
注：MMEはTA粒度のSGWサービスエリアを知っています。
ステップ2. MMEは、PDN GWアドレスおよびTEID（GTPベースのS5 / S8の場合）またはGREキー（PMIPベースのS5 / S8の場合）を持つベアラコンテキストをPDN GWに送信します。デフォルトのベアラが存在する各PDN接続のターゲットSGWへのPDN接続あたりのアップリンクトラフィック、受け入れられたEPSベアラのためのダウンリンクユーザプレーンのeNodeBアドレスおよびTEID、受け入れられたEPSベアラのためのプロトコルタイプ、S5 / S8、UEタイムゾーン）ターゲットeNodeBによって受け入れられました。ターゲットサービングGWは、S1-Uインタフェース（ベアラ当たり1つのTEID）上のアップリンクトラフィック用のSGWアドレスとTEIDを割り当てる。 S5 / S8上のプロトコルタイプは、S5 / S8インターフェイス上でどのプロトコルを使用すべきかSGWに提供されます。 PGWがUEの位置情報を要求した場合、MMEはまた、このメッセージ内にユーザ位置情報IEを含む。
MMEは、ステップ1で受信されたEPSベアラのリストを使用して、UEコンテキスト内の任意の専用EPSベアラがターゲットeNodeBによって受け入れられていないかどうかを判定する。 MMEは、ターゲットSGWを介してベアラ解放手順をトリガすることによって、未承諾の専用ベアラを解放する。 SGWが未受領のベアラに対するDLパケットを受信すると、SGWはDLパケットを廃棄し、MMEにダウンリンクデータ通知を送信しない。
PDNコネクションのデフォルトのベアラがターゲットeNodeBによって受け入れられておらず、複数のPDNコネクションがアクティブである場合、MMEはそのPDNコネクションのすべてのベアラを失敗としてみなし、MMEが要求したPDN切断手順をソースSGW。
デフォルトのEPSベアラがターゲットeNodeBによって受け入れられなかった場合、MMEはステップ5で指定されたとおりに動作する。
ステップ3：ターゲットサービングGWは、PDN GWからのダウンリンクトラフィックのアドレスおよびTEID（ベアラ当たり1つ）を割り当てる。サービングGWは、受け入れられないベアラについても、S5 / S8上でDL TEIDを割り当てる。 PDN接続ごとにPDN GWにModify Bearer Request（ユーザプレーン用のGWアドレスおよびTEID（s））メッセージを送信します。 SGWは、ステップ2で存在する場合、ユーザ位置情報IEおよび/またはUE時間帯IEも含む.PDN GWは、そのコンテキストフィールドを更新し、ベアラ変更応答（課金Id、MSISDNなど）メッセージをサービングGWに返す。 MSISDNは、PDN GWがUEコンテキストに格納している場合に含まれます。 PDN GWは、新しく受信したアドレスとTEIDを使用して、ターゲットGWへのダウンリンクパケットの送信を開始する。これらのダウンリンクパケットは、ターゲットeNodeBへのターゲットサービングGWを介して新しいダウンリンク経路を使用する。サービングGWは、失敗したベアラに対してTEIDを割り当て、MMEに通知しなければならない。
ステップ4：ターゲットサービングGWは、ターゲットMMEにセッション作成応答（ユーザプレーン用サービングGWアドレスおよびアップリンクTEID）メッセージを返信する。 MMEは、ステップ7で使用されるタイマーを開始する。
ステップ5. MMEは、Path Switch Request Ack（ユーザプレーンのサービングGWアドレスおよびアップリンクTEID）メッセージを含むPath Switch Requestメッセージを確認する。 UE AMBRが変更された場合、例えば、同じAPNに関連付けられているすべてのEPSベアラがターゲットeNodeBで拒否された場合、MMEは、Path Switch Request AckメッセージのターゲットeNodeBにUE AMBRの更新値を提供します。ターゲットeNodeBは、後続のアップリンクパケットを転送するために新しいサービングGWアドレスおよびTEIDを使用し始める。
一部のEPSベアラがコアネットワークで正常に切り替えられなかった場合、MMEは、パススイッチ要求確認メッセージに、ベアラが確立されなかったことを通知し、専用ベアラは、ベアラ解放手順を開始して、 EPSベアラー。ターゲットeNodeBは、ベアラがコアネットワーク内に確立されていないことが通知されたときに、対応するベアラコンテキストを削除しなければならない。
デフォルトのEPSベアラがコアネットワークで正常に切り替えられなかった場合、またはターゲットeNodeBによって受け入れられていない場合、MMEはターゲットeNodeBにPath Switch Request Failureメッセージを送信します。 MMEは、MME開始デタッチ手順で説明したように、UEを明示的にデタッチする。
Release Resourceを送信することによって、ターゲットeNodeBは、ソースeNodeBへのハンドオーバーの成功を通知し、リソースの解放をトリガーする。
ステップ7.ステップ4の後にタイマーが満了すると、ソースMMEは、セッションの削除要求メッセージ（原因）を送信することによって、ソースサービングGW内のベアラを解放する。 原因は、Source Serving GWがSource Serving GWがPDN GWに対して削除手順を開始しないことをSource Serving GWに示す。 Source Serving GWは、セッション応答メッセージの削除を確認します。 この手順の前にISRがアクティブ化されている場合、原因はまた、送信元SGWがそのCNノードにベアラ削除要求メッセージを送信することによって、他の古いCNノード上のベアラリソースを削除することをソースSGWに示す。
ステップ8：UEは、そのような必要性があるときにトラッキングエリア更新手順を開始する
No comments:
Post a Comment