Emergency Services Fallback — 緊急呼を4G/E-UTRAへ移して成立させる仕組み¶

学習目標¶

この章を読み終えると、次のことができるようになります。

• Emergency Services Fallback が「緊急呼QoS/VoNR緊急呼を提供できないセルで、IMS緊急呼を4G/E-UTRAへ移して成立させる仕組み」であることを説明できる
• 起動のきっかけが「音声一般のQoS要求」ではなく UEの緊急サービス要求（緊急指示を伴う Service Request / Registration） であることを、EPS Fallback と区別して説明できる
• フォールバック先が 4G/EPS だけでなく 同一5GC配下のE-UTRA（NG-RAN内のLTE） にもなり得ることを説明できる
• 未登録UE / 限定サービス状態のUE でも緊急呼のためにフォールバックが許容され得ることを説明できる
• 移行方式（Handoverベース/Redirectベース）が EPS Fallback と同型であることを図示できる

前提知識¶

• Emergency（緊急通報） — 本章はその緊急呼を「別RATへ移して成立させる」応用。未登録受付・認証省略(NIA0/NEA0)・優先度はそちら
• EPS Fallback（一般音声のフォールバック） — 本章は「緊急呼版のフォールバック」。トリガーと移行先の違い が主題
• Handover（ハンドオーバ） — Handoverベースの移行はInter-RAT Handoverの一種
• Registration（初回登録） — 緊急指示付きの登録種別（Emergency Registration）を含む
• 補助: AMF / SMF / PCF

この章で学べること¶

• Why — なぜ「緊急呼専用」のフォールバックが要るのか
• Basic Concept — 「緊急の要求が来たら、待たずに実績あるRATへ案内する」という考え方
• EPS Fallbackとの3つの差分 — トリガー・フォールバック先・UE状態
• Architecture — Emergency Services Fallbackに関わる5GC・4G(EPC)・NG-RANの登場人物
• Procedure — Call Flow — 緊急サービス要求の検知 → RANがフォールバック起動 → 4G/E-UTRAで緊急呼成立
• Handoverベース と Redirectベース — N26の有無による2つの移行方式
• EPCとの比較 / Release差分 / Trouble Shooting / FAQ / Practice

Why — なぜ「緊急呼専用」のフォールバックが要るのか¶

VoNR と同様、5G初期展開では NR上で緊急呼QoS（VoNR緊急呼）を提供できるセルが限られていました。無線(NR)やコア(5GC)は使えても、そのセルが緊急呼の音声を運べないことが多かったのです。

一方、4G(LTE)のVoLTE・IMS緊急呼はすでに広く実運用されており、緊急呼を安定して成立させられます。緊急通報は人命に関わるため、「NRで緊急呼が成立しないなら、実績ある4G/E-UTRAへ移してでも必ず成立させる」 ことが強く求められます。

この「UEが緊急サービスを要求したときに、UEを5GS(NR)から4G/E-UTRAへ移して緊急呼を成立させる」仕組みが Emergency Services Fallback です。3GPP TS 23.502 §4.13.4.1（節番号の枝番は版により変わり得るため 要確認）に規定されています。

一般の音声呼を移す EPS Fallback（TS 23.502 §4.13.6.1）と骨格は似ていますが、トリガー・フォールバック先・許容されるUE状態 が異なる、緊急呼専用の手続きです。

Overview — 概要¶

Emergency Services Fallback は、次の流れで動きます。

1. 緊急サービス要求を検知 — UEが 緊急サービスを要求（Emergency Service Request、または緊急指示付きの Registration）する。音声呼のQoSフロー確立を待たず、この緊急要求の時点でフォールバック起動の契機になり得る
2. RANが緊急呼をNRで提供できないと判断 — このセルは緊急呼を提供できない、と無線側が判断する
3. UEを4G/E-UTRAへ移行 — NG-RANがフォールバックを起動し、UEを Handoverベース か Redirectベース で 4G/EPS または 同一5GC配下のE-UTRA へ移す
4. 移行先で緊急呼成立 — 移行後、UEは移行先RATでIMS緊急呼（PSAPへ）を確立する（緊急呼そのものの詳細は Emergency章）

ポイントは、EPS Fallback が「音声用QoS Flow（5QI=1）の確立要求」をきっかけにするのに対し、本章は「UEの緊急サービス要求そのもの」をきっかけにする点です。緊急呼は音声QoSフローの確立を待たずに、緊急要求の時点でRANがフォールバックを起動しうる、という違いが本質です。

下の図は、緊急サービス要求を契機に、RANの緊急呼可否判断でフォールバックが起動し、N26の有無で移行方式が分かれる様子を示します。

flowchart TD
    START["UE: 緊急サービス要求
（Emergency Service Request /
緊急指示付き Registration）
【EPS Fallbackと違い、音声QoS確立を待たない】"] --> Q1{"NG-RAN:
このセルは NR で緊急呼を提供可能?"}
    Q1 -- "可能" --> NR["NR上で緊急呼成立
（VoNR緊急呼。フォールバックしない）"]
    Q1 -- "不可" --> EFB["Emergency Services Fallback 起動"]
    EFB --> Q2{"N26（AMF⇔MME）
あり?"}
    Q2 -- "あり" --> HO["Handoverベース
Inter-RAT Handover
（N26で状態引き継ぎ・滑らか）"]
    Q2 -- "なし" --> RD["Redirectベース
RRC Release で E-UTRA へ誘導
（UEが移行先で再接続）"]
    HO --> DONE["4G/EPS または E-UTRA で緊急呼成立
IMS緊急呼 → PSAP"]
    RD --> DONE

    classDef common fill:#eef,stroke:#66a;
    classDef ok fill:#efe,stroke:#3a3,stroke-width:2px;
    classDef fb fill:#fee,stroke:#c33;
    class START common;
    class NR ok;
    class EFB,HO,RD,DONE fb;

Basic Concept — 初心者向け説明¶

Emergency Services Fallback は 「緊急の依頼が来たら、この窓口で扱えるか確かめる前に、実績ある窓口へ最優先でご案内する」 にたとえられます。

• 一般の EPS Fallback は「音声通話を頼まれ、音声レーン（5QI=1）を敷こうとして『うちでは無理』と分かってから」隣の窓口へ案内する
• 緊急の Emergency Services Fallback は「緊急です、と言われた瞬間に、悠長に音声レーンを敷こうとせず、扱えない窓口ならすぐ実績ある窓口へ案内する」。人命優先だからこそ、待たない
• 案内先は「4Gの窓口（4G/EPS）」だけでなく、同じ建物の別フロアのLTE窓口（同一5GC配下のE-UTRA） の場合もある
• 身分証が確認できないお客（未登録UE/限定サービス状態のUE）でも、緊急のためなら案内する（詳細は Emergency章）

案内の仕方（Handoverベース＝手を引いて連れて行く／Redirectベース＝住所を教えて行ってもらう）は EPS Fallback と同じ2通りです。

Architecture¶

graph LR
    UE["UE
(未登録/限定サービスでも可)"] -- "N1(NAS: Emergency Service Request)" --> AMF["AMF (5GC)"]
    UE -- "無線(NR→LTE/E-UTRA)" --> RAN["NG-RAN"]
    AMF -- "N11" --> SMF["SMF (5GC)"]
    RAN -- "N2" --> AMF
    AMF -- "N26" --> MME["MME (4G/EPC)"]
    RAN -. "Inter-RAT移行" .-> ENB["eNB / E-UTRA"]
    MME --> ENB

図の読み方: UEが N1（NAS）で AMF に緊急サービスを要求 すると、AMFは N2経由でNG-RANへ緊急サービスのフォールバックが必要である旨を通知 します（トリガーは EPS Fallback のような音声QoS要求ではなく、緊急サービス要求そのもの）。NG-RANが「このセルはNRで緊急呼を提供できない」と判断すると Emergency Services Fallback を起動。N26（AMF⇔MME） があれば状態を引き継いで 4G/EPS へHandover、なければRRC Releaseで E-UTRA へRedirectします。移行後の緊急呼確立（緊急用PDU Session・緊急用P-CSCF・PSAPルーティング）は Emergency章 を参照してください（本章では再掲しません）。

Network Function¶

Interface¶

Procedure — Call Flow¶

Emergency Services Fallback は、(A) 緊急サービス要求の発生 → (B) NG-RANの緊急呼NR提供不可判断 → (C) 4G/E-UTRAへ移行 → (D) 移行先で緊急呼成立 の4段階で理解します。

sequenceDiagram
    participant UE
    participant RAN as NG-RAN
    participant AMF
    participant MME as MME(4G)
    participant ENB as eNB / E-UTRA

    Note over UE,AMF: (A) UEが緊急サービスを要求（音声QoS確立を待たない）
    UE->>AMF: N1 Emergency Service Request / 緊急指示付き Registration
    AMF->>RAN: N2 緊急サービス・フォールバック要否を通知

    Note over RAN: (B) このセルはNRで緊急呼を提供できないと判断 → フォールバック起動

    alt Handoverベース（N26あり／4G/EPSへ）
        RAN->>AMF: N2 Handover Required
        AMF->>MME: N26 でコンテキスト引き継ぎ
        MME->>ENB: 4G側リソース準備
        RAN-->>UE: Inter-RAT Handover Command (→LTE)
    else Redirectベース（N26なし／E-UTRAへ）
        RAN-->>UE: RRC Release (redirect to E-UTRA)
        UE->>ENB: E-UTRAで再接続・(必要なら)登録
    end

    Note over UE,ENB: (C)/(D) 移行先で IMS緊急呼を確立（詳細は Emergency章）
    UE->>ENB: 緊急用ベアラで音声(RTP)確立 → PSAP

手順の説明:

1. (A) 緊急サービス要求の発生 — UEが 緊急サービスを要求 する（緊急サービスのフォールバックを示す Service Request、または緊急指示付きの Registration）。ここが EPS Fallback との最大の違いで、EPS Fallbackが「音声用QoS Flow(5QI=1)の確立要求」を待つのに対し、本章は緊急要求そのものが契機。音声QoSフローの確立を待たずに 次に進みうる。

1. (B) 緊急呼NR提供不可判断 — NG-RANが「このセルはNRで緊急呼を提供できない」と判断し、Emergency Services Fallback を起動する。
2. (C) 4G/E-UTRAへ移行 — 移行方式は2通り（EPS Fallback と同型）。
   • Handoverベース（N26あり） — NG-RANが N2 Handover Required を送り、AMFが N26でMMEへUEコンテキストを引き継ぎ、Inter-RAT HandoverでUEを移す（主に 4G/EPS へ。Handover章 参照）。
   • Redirectベース（N26なし） — NG-RANが RRC Release でUEを E-UTRA へリダイレクトし、UEが移行先で再接続する。
3. (D) 移行先で緊急呼成立 — 移行先RAT上でUEはIMS緊急呼を確立し、PSAP へつながる。緊急用PDU Session・緊急用P-CSCF・PSAPルーティング・優先度(ARP等)の詳細は Emergency章 を参照。

Signal Flow¶

Handoverベース と Redirectベース¶

Emergency Services Fallback の移行方式も、EPS Fallback と同じく N26インターフェースの有無 で2つに分かれます。

EPCとの比較¶

• 4Gでは: LTE上の緊急呼は VoLTE/IMS緊急呼（緊急用ベアラ＋緊急用P-CSCF→PSAP）で成立させます。4Gには他RATへ落とす CS Fallback の歴史がありましたが、緊急呼をNRから実績あるRATへ移すという発想は、その延長線上にあると理解できます。
• 5Gでは: NRで緊急呼を提供できないセルでUEが緊急サービスを要求すると、Emergency Services Fallback でUEを 4G/EPS または E-UTRA へ移し、移行先で緊急呼を成立させます（TS 23.502 §4.13.4.1）。一般音声の EPS Fallback（§4.13.6.1）と違い、トリガーが緊急サービス要求そのもので、音声QoS確立を待たない点、移行先にE-UTRAも含む点が異なります。

Release差分¶

• Rel-15: 5G初期展開でNR緊急呼(VoNR緊急呼)未提供エリアが多く、Emergency Services Fallback が緊急呼を成立させる実運用上の要として位置づけられた。TS 23.502 §4.13.4.1 に手続きが規定。
• Rel-16以降: NR緊急呼対応の拡充により、将来的には重要度が下がる方向。ただし個別の機能追加・改定は各TSを 要確認（本章では断定しない）。

Trouble Shooting¶

3GPP Specification¶

• 3GPP TS 23.502 §4.13.4.1 — Emergency Services Fallback の手続き（本章の主根拠）
• 3GPP TS 23.502 §4.13.6.1 — EPS Fallback for IMS voice（一般音声。本章はこれとの差分が主題）
• 3GPP TS 23.501 §5.16.4 — 緊急サービス（Emergency Services）の全体像（緊急呼の枠組み。詳細な枝番は 要確認）
• 3GPP TS 23.501 §5.7.4 — 標準化5QI表（移行先で使う音声QoSの識別子。5QI=1 会話音声/GBR 等）
• 3GPP TS 23.501 / 23.502 — 4G/5G Interworking と N26（AMF⇔MME）の規定（詳細な章番号は 要確認）

FAQ¶

Q. Emergency Services Fallback と EPS Fallback は何が違いますか？ A. 主に3点です。(1) トリガー — EPS Fallbackは「音声用QoS Flow(5QI=1)の確立要求」を待ちますが、Emergency Services Fallbackは UEの緊急サービス要求そのもの を契機とし、音声QoSフローの確立を待たずに RANがフォールバックを起動しうる。(2) 移行先 — EPS Fallbackは基本 4G/EPC ですが、Emergency Services Fallbackは 4G/EPS だけでなく 同一5GC配下のE-UTRA にもなり得る。(3) UE状態 — 緊急呼のため 未登録UE/限定サービス状態のUE でも許容され得る。根拠は TS 23.502 §4.13.4.1（緊急）と §4.13.6.1（一般音声）。

Q. 何がきっかけでEmergency Services Fallbackは起動しますか？ A. UEが 緊急サービスを要求（Emergency Service Request、または緊急指示付きRegistration）し、NG-RANが「このセルはNRで緊急呼を提供できない」と判断したときに起動します。音声QoSフローの確立を待たない点がEPS Fallbackとの違いです。

Q. フォールバック先は必ず4Gですか？ A. いいえ。4G/EPS（N26でEPCへ）だけでなく、同一5GC配下のE-UTRA（NG-RAN内のLTE） の場合もあります。どちらになるかは在圏の隣接RAT・ネットワーク設計・実装に依存します（実装依存、詳細は TS 23.502 §4.13.4.1 を 要確認）。

Q. 登録できていないUEでも緊急呼のフォールバックはできますか？ A. 緊急呼のため 未登録UE/限定サービス状態のUE でも許容され得ますが、受付可否は国の規制・事業者ポリシー・実装に大きく依存します（規制/実装依存）。緊急登録・認証省略の詳細は Emergency章 を参照してください。

Q. 移行後の緊急呼の確立手順はどこを見ればよいですか？ A. 本章は「NRから4G/E-UTRAへ移すまで」に焦点を当てます。移行先での緊急用PDU Session・緊急用P-CSCF・PSAPルーティング・優先度(ARP等)は Emergency章 にまとめています。

Summary¶

• Emergency Services Fallback は、NRで緊急呼を提供できないセルで、UEの緊急サービス要求を契機にUEを 5GS(NR)→4G/EPS または E-UTRA へ移し、移行先でIMS緊急呼を成立させる仕組み（3GPP TS 23.502 §4.13.4.1）
• EPS Fallback（§4.13.6.1）との違いは (1)トリガーが緊急サービス要求そのもの（音声QoS確立を待たない）／(2)移行先に4G/EPSだけでなくE-UTRAも含む／(3)未登録・限定サービスUEでも許容され得る の3点
• 移行方式は Handoverベース（N26あり・状態引き継ぎ） と Redirectベース（N26なし・RRC Releaseで誘導） の2つで、EPS Fallback と同型
• 移行先での緊急呼確立（緊急用PDU Session・緊急用P-CSCF・PSAP・優先度）は Emergency章 に委ねる
• 「速さ」が緊急呼ではとくに重要で、一般にHandoverベースが有利（ただし移行先RATは実装依存）

Practice — 理解度チェック・演習¶

理解度チェック¶

演習¶

• EPS Fallback と Emergency Services Fallback のCall Flowを並べ、「トリガー」「移行先」「UE状態」の3点がどこで分かれるかを図に描いてみましょう。
• N26あり（4G/EPSへHandover）／なし（E-UTRAへRedirect）の2ケースについて、緊急呼成立までのステップ数と遅延の違いを整理してみましょう。

Next Step¶

• Emergency（緊急通報） — 移行先での緊急呼確立（緊急登録・認証省略・緊急用PDU Session・PSAP）へ進む
• EPS Fallback（一般音声） — 一般音声版のフォールバック。トリガーと移行先の違いを対比して深める
• 4G-5G Interworking（N26 / 相互接続） — フォールバックを支える4G⇔5G相互接続の枠組み
• Handover（ハンドオーバ） — Handoverベースの移行が使うInter-RAT Handoverの詳細