Emergency — 緊急通報（5GCにおける緊急呼）¶

学習目標¶

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

• 緊急通報（Emergency） が通常の音声呼（VoNR）と何が違うのかを説明できる
• 通常サービスを受けられないUE（SIM無し/認証不可/在圏規制）でも 緊急呼だけは受け付け得る 仕組みを説明できる
• Emergency Registration（緊急登録） という専用の登録種別が存在する理由を説明できる
• 認証省略（NIA0/NEA0） が「規制・事業者ポリシー依存」で許容され得ることを、断定せずに説明できる
• 緊急呼が 緊急用PDU Session と 優先度確保（ARP等） の上で成立する流れを図示できる

前提知識¶

• VoNR（Voice over NR） — 緊急呼は音声呼の特殊ケース。IMS＋QoS Flowの土台を共有する
• Registration（初回登録） — 通常登録の理解の上に「緊急登録」という別種別を重ねる
• Authentication（認証） — 緊急呼では認証が省略され得る点が最大の差分
• Security（セキュリティ） — NIA0/NEA0（Nullアルゴリズム）の文脈
• 補助: AMF / SMF / PCF / AUSF

この章で学べること¶

• Why — なぜ緊急呼だけを特別扱いするのか
• Basic Concept — 「通常サービスの門は閉じていても、緊急の窓口だけは開ける」という考え方
• 緊急呼固有の3つの差分 — 未登録受付・認証省略・優先度
• Architecture — 緊急呼に関わる5GC・IMS・PSAPの登場人物
• Procedure — Call Flow — 緊急登録 → 緊急用PDU Session → 緊急呼確立
• NIA0/NEA0の位置づけ — 認証できないUEへのNullアルゴリズム許容（規制/実装依存）
• VoNRとの比較 / Release差分 / Trouble Shooting / FAQ / Practice

Why — なぜ緊急呼だけを特別扱いするのか¶

通常、5GCは「正しく登録し、認証を通ったUE」にだけサービスを提供します。SIMが無い、認証に失敗する、在圏で規制がかかっている——such なUEは通常サービスを拒否されます。

しかし 緊急通報（110/119/911等）は例外 です。人命に関わるため、多くの国の規制は「通常サービスを受けられないUEであっても、緊急呼だけは可能な限り成立させる」ことを事業者に求めます。ここに、緊急呼を通常呼と分けて扱う根本的な理由があります。

緊急呼が通常呼と違うのは、主に次の3点です。

• 未登録UEの受付 — 通常なら弾かれるUEでも、緊急呼のためだけの特別な登録（Emergency Registration）を許し得る
• 認証省略の可能性 — 認証できないUEには、暗号化・完全性保護なし（NIA0/NEA0 = Nullアルゴリズム）で緊急呼を許容し得る
• 優先度 — 緊急呼は最優先。混雑時でも資源を優先確保する（ARP等）

Overview — 概要¶

緊急呼も、土台は通常のVoNRと同じ IMS（呼制御）＋5GCのQoS Flow（保証レーン） です。異なるのは「入口の門をどこまで開けるか」と「優先度」です。

1. 登録の入口 — UEは通常登録ができない場合でも、Emergency Registration（緊急登録）という別種別で最小限の受付を得られる（規制/実装依存）
2. 認証の門 — 認証できないUEには、暗号化なし（NIA0/NEA0）で先へ通す設定があり得る（規制/実装依存）
3. 緊急用の道 — 緊急呼専用の PDU Session（緊急用DNN） を張り、緊急用の P-CSCF を選んでIMSへ、最終的に PSAP（緊急呼受理機関） へつなぐ
4. 優先度 — 緊急呼のQoS Flowは ARP（Allocation and Retention Priority）等で優先確保 され、混雑時にも守られる

Basic Concept — 初心者向け説明¶

緊急呼は 「夜間に閉まったビルの、緊急用の通用口」 にたとえられます。

• 通常の正面玄関（通常登録・認証）は、身分証（SIM/認証）が無いと入れない
• しかし 緊急用の通用口 だけは、身分証が確認できなくても人命のために開ける（開けるかどうかはビル＝事業者/規制の方針次第）
• 中に入ったら、緊急連絡先（PSAP）まで 最優先で 案内される。他の来客より先に通す（優先度）

つまり緊急呼は「通常の門を通れないUEのための、限定的で最優先の別ルート」です。ただし 通用口を開けるかどうか自体が規制・事業者判断 である点が、通常のVoNRと決定的に違います。

緊急呼固有の3つの差分（VoNRとの差）¶

通常のVoNRの音声呼確立フロー（IMS用PDU Session → SIP登録 → 音声用QoS Flow）は VoNR章 に委ね、ここでは緊急呼だけの差分に集中します。

Architecture¶

graph LR
    UE["UE
(未登録でも可)"] -- "N1(NAS: Emergency Registration)" --> AMF["AMF"]
    UE -- "緊急呼(SIP/RTP)" --> IMS["IMS
(緊急用P-CSCF=AF)"]
    AMF -- "N11" --> SMF["SMF"]
    SMF -- "N4" --> UPF["UPF"]
    IMS -- "N5" --> PCF["PCF"]
    PCF -- "N7" --> SMF
    SMF -- "N2(via AMF)" --> RAN["NG-RAN"]
    UPF -- "N6(緊急用DNN)" --> IMS
    IMS -- "緊急呼ルーティング" --> PSAP["PSAP
(緊急呼受理機関)"]

図の読み方: 通常のVoNRと骨格は同じですが、入口が違います。UEは N1（NAS）で AMF に Emergency Registration を要求します（通常登録できないUEでも受付し得る）。認証は省略され得ます（NIA0/NEA0、規制/実装依存）。以後は 緊急用DNN のPDU Session（UE⇔UPF⇔N6⇔IMS）を張り、緊急用P-CSCFがAFとしてN5でPCFに優先度つきQoSを要求、緊急呼は最終的に PSAP へルーティングされます。

Network Function¶

Interface¶

Procedure — Call Flow¶

緊急呼は、(A) Emergency Registration（緊急登録） → (B) 緊急用PDU Session確立 → (C) IMS緊急呼確立（PSAPへ） の3段階で理解します。VoNRとの差分（未登録受付・認証省略・優先度）に注目してください。

sequenceDiagram
    participant UE
    participant AMF
    participant AUSF
    participant SMF
    participant PCF
    participant IMS as IMS(緊急用P-CSCF=AF)
    participant PSAP

    Note over UE,AMF: (A) Emergency Registration（未登録UEも受付し得る）
    UE->>AMF: Registration Request (5GS registration type = Emergency)
    alt 認証可能な場合
        AMF->>AUSF: 認証
        AUSF-->>AMF: 認証成功
    else 認証できない場合（規制/実装依存）
        Note over AMF,AUSF: 認証省略 → NIA0/NEA0（Null）で継続し得る
    end
    AMF-->>UE: Registration Accept (Emergency Registered)

    Note over UE,SMF: (B) 緊急用 PDU Session 確立（緊急用DNN）
    UE->>SMF: PDU Session Establishment Request (Emergency用)
    SMF->>PCF: N7 SM Policy (優先度: ARP等)
    SMF-->>UE: 緊急用PDU Session確立

    Note over UE,PSAP: (C) IMS緊急呼確立
    UE->>IMS: SIP INVITE (緊急呼, 緊急用P-CSCF)
    IMS->>PCF: N5 Npcf_PolicyAuthorization (優先QoS要求)
    PCF->>SMF: N7 SM Policy 更新 (5QI=1 GBR + 優先ARP)
    IMS->>PSAP: 緊急呼ルーティング
    UE->>PSAP: 通話確立 (RTP音声)

手順の説明:

1. (A) Emergency Registration — UEは 登録種別を「Emergency」 として Registration Request を送る。通常登録できないUE（SIM無し/認証不可/在圏規制）でも、この緊急登録は受付され得る（規制/実装依存）。認証できる場合は通常どおり認証するが、認証できない場合は認証を省略し、NIA0/NEA0（Nullアルゴリズム）で継続する設定があり得る（規制/実装依存）。
2. (B) 緊急用PDU Session確立 — UEは 緊急用DNN で専用のPDU Sessionを確立する。この際 PCF は 優先度（ARP等） を含むポリシーを渡し、SMFが優先確保する。
3. (C) IMS緊急呼確立 — UEは 緊急用P-CSCF へ SIP INVITE を送り、P-CSCFが AF として N5 で PCF に優先QoS（5QI=1, GBR＋優先ARP） を要求。IMSは緊急呼を検出して PSAP へルーティングし、音声（RTP）が確立する。音声用QoS Flowの確立メカニズム自体は VoNR の(C)と同じ。

Signal Flow¶

NIA0/NEA0の位置づけ（Nullアルゴリズム）¶

緊急呼で認証できないUEを受け付ける場合、暗号化・完全性保護をかけないNullアルゴリズム が使われ得ます。

VoNRとの比較¶

• 共通点: どちらも IMS（呼制御）＋5GCのQoS Flow（保証レーン） で成立する。音声用QoS Flowの確立メカニズム（P-CSCFがAFとしてN5でPCFにQoS要求 → PCF→N7→SMF→N4/N2）は同じで、5QI=1（会話音声, GBR）／5QI=5（IMSシグナリング, Non-GBR） を使う（TS 23.501 §5.7.4 の標準化5QI）。
• 差分: 緊急呼は (1) 未登録UEを受付し得る（Emergency Registration）／(2) 認証を省略し得る（NIA0/NEA0）／(3) 最優先で確保する（ARP等）／(4) 緊急用P-CSCF経由でPSAPへつなぐ 点が異なる。(1)(2)は 規制・事業者ポリシー依存 が大きい。

Release差分¶

• Rel-15: 5GSにおけるIMS緊急呼・緊急登録の枠組みが規定。ただし初期展開ではVoNR/緊急呼未提供エリアも多く、緊急呼が4G(EPS)へフォールバックする運用もあった（EPS Fallback の文脈）。
• Rel-16以降: 緊急呼・緊急サービス関連の拡充。詳細な機能追加・章番号は各TSを 要確認（本章では断定しない）。

Trouble Shooting¶

3GPP Specification¶

• 3GPP TS 23.501 — 5Gシステムアーキテクチャ。緊急サービスの一般規定（章番号は要確認）
• 3GPP TS 23.502 — 手続き。緊急登録・緊急用PDU Session確立の手順（章番号は要確認）
• 3GPP TS 24.501 — NAS(5GMM/5GSM)。緊急登録種別（registration type=Emergency）等（章番号は要確認）
• 3GPP TS 33.501 — セキュリティ。認証できないUEの緊急呼・NIA0/NEA0（Nullアルゴリズム）の許容条件（章番号は要確認）
• 3GPP TS 23.167 — IMS Emergency Sessions（IMS緊急呼・PSAPルーティング。本章では概要のみ・要参照）
• 3GPP TS 23.501 §5.7.4 — 標準化5QI表（5QI=1 会話音声/GBR, 5QI=5 IMSシグナリング/Non-GBR。緊急呼でも音声はこれを使う）

FAQ¶

Q. SIMが入っていないスマホでも緊急通報はできますか？ A. 規制・事業者ポリシー・実装に依存 します。3GPPの枠組みでは、通常登録できないUEでも Emergency Registration で緊急呼を受け付ける仕組みが用意されていますが、実際に有効かどうかは国の規制や事業者設定次第で、断定はできません。

Q. 認証できないUEの緊急呼は、どうやって通信するのですか？ A. NIA0/NEA0（Nullアルゴリズム） により、暗号化・完全性保護をかけずに継続する設定があり得ます（TS 33.501系、規制/実装依存）。これは緊急呼という限定的状況の例外で、通常呼では使いません。

Q. 緊急呼は通常呼と同じIMSを使うのですか？ A. IMSを使う点は同じですが、UEは 緊急用P-CSCF を選び、IMSは緊急呼を検出して PSAP（緊急呼受理機関） へルーティングします。音声用QoS Flowの確立メカニズム自体は VoNR と共通です。

Q. 混雑していても緊急呼はつながりますか？ A. 緊急呼は ARP（Allocation and Retention Priority）等で最優先 に確保されるため、混雑時でも通常呼より優先されます（優先の度合いは実装依存の面もあります）。

Summary¶

• 緊急通報（Emergency） は音声呼（VoNR）の特殊ケースで、土台（IMS＋QoS Flow）は共通だが「入口の門」と「優先度」が異なる
• 緊急呼固有の差分は (1)未登録UEの受付（Emergency Registration）／(2)認証省略（NIA0/NEA0）／(3)最優先確保（ARP等）／(4)緊急用P-CSCF経由でPSAPへ の4点
• (1)未登録受付・(2)認証省略・NIA0/NEA0許容は、国の規制・事業者ポリシー・実装に大きく依存 し、断定できない
• 手続きは (A)Emergency Registration → (B)緊急用PDU Session（緊急用DNN） → (C)IMS緊急呼（PSAPへ） の順
• 音声そのものは通常VoNRと同じ 5QI=1（会話音声, GBR） を使う（TS 23.501 §5.7.4）

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

理解度チェック¶

演習¶

• 通常のRegistrationとEmergency Registrationで、Call Flowのどこが同じでどこが違うかを図に描いてみましょう（ヒント: 認証ステップの扱いに注目）。
• 「SIM無しスマホの緊急通報」が成立する条件を、規制・事業者ポリシー・NIA0/NEA0の観点から整理してみましょう（断定を避け、依存関係で表現するのがコツ）。

Next Step¶

• VoNR（Voice over NR） — 緊急呼の土台となる通常の音声呼へ戻って深める
• Authentication（認証） — 緊急呼で省略され得る認証の本来の姿を確認する
• Security（セキュリティ） — NIA0/NEA0を含むセキュリティアルゴリズムの全体像
• QoS（5G QoSモデル） — ARP・5QI・GBRなど優先度確保の詳細