【実務・中級編】 VoLTE(Voice over LTE)のSIP/RTPシグナリングとQoS専用ベアラ – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

なぜ「通話」だけが途切れないのか？VoLTEのQoSベアラとSIPシグナリングを解剖する

ネットワークエンジニアとして現場に立っていると、「Web APIはサクサク動くのに、なぜか通話だけは極限状態でも繋がるのか？」という質問を後輩から受けることがあります。

パケットの優先順位がフラットなベストエフォートの世界で生きるWebエンジニアにとって、LTEの「QoS専用ベアラ」は魔法のように見えるかもしれません。しかし、これは魔法ではなく、3GPPが策定した極めて泥臭く、かつ緻密な階層制御の賜物です。

今日は、VoLTEの裏側で何が起きているのか、SIPシグナリングからQCI=1のベアラ制御まで、エンジニアの視点で深掘りしていきましょう。

VoLTEを支える二階建て構造：シグナリングとメディア

VoLTEにおける通信は、大きく分けて二つの層で成り立っています。

1. SIPシグナリング（制御プレーン）: 通話の開始、終了、相手の特定を行うための「お膳立て」。
2. RTPメディア（ユーザープレーン）: 実際の音声データが流れる実体。

ここでのポイントは、これら二つが同じネットワーク上を通っていても、背後で適用されるネットワークの「扱い」が全く異なる点です。

1. SIPによるセッション確立

SIP（Session Initiation Protocol）は、Webの世界で言えば HTTP に近い存在です。IMS（IP Multimedia Subsystem）ネットワークに対して INVITE を投げ、相手を呼び出します。

もし皆さんがVoLTEのデバッグ環境でSIPメッセージを解析するなら、tshark 等で以下のようなヘッダーを確認することになるでしょう。

# INVITEメッセージの例（簡略化）
INVITE sip:receiver@ims.mnc001.mcc440.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bK-12345
From: <sip:sender@ims.mnc001.mcc440.3gppnetwork.org>;tag=abc
To: <sip:receiver@ims.mnc001.mcc440.3gppnetwork.org>
Content-Type: application/sdp
# このSDPの中に、音声コーデック(AMR-WB等)やRTPのポート番号が含まれる

2. QoS専用ベアラ（QCI=1）の真実

ここからが本題です。SIPでのハンドシェイクが終わると、コアネットワーク（EPC）は「これから音声通話が始まる」と判断し、専用ベアラ（Dedicated Bearer）を生成します。

LTEにおいて最も重要なパラメーターが QCI（QoS Class Identifier）です。

QCI=1: 音声通話用。遅延保証型（GBR: Guaranteed Bit Rate）。
QCI=5: IMSシグナリング用。遅延に敏感な制御通信。
QCI=9: 一般的なデータ通信。ベストエフォート（Non-GBR）。

QCI=1が割り当てられたパケットは、無線区間（MACスケジューラ）で他のWeb通信（YouTubeやブラウジング）よりも優先的にリソースが割り当てられます。混雑したスタジアムで、周囲のスマホがWebに繋がらない中でも通話だけができるのは、この QCI=1 が他のトラフィックを押し退けて優先パスを確保しているからです。

実務で役立つデバッグの思考法

もし皆さんがインフラのトラブルシューティングを行う際、VoLTEの切断や音質劣化を疑うなら、まずは以下のフローを頭に入れてください。

1. シグナリングの可視化: SIP 488 Not Acceptable Here などが出ていないかを確認。これはコーデックの不一致が原因であることが多いです。
2. ベアラのステータス確認: UE（端末）側で RRC の状態遷移を確認します。専用ベアラが正常に確立されたか、Bearer Resource Modification Request が正しく応答されているかを見てください。

Pythonによる簡易的なシグナリング解析のイメージ

実際の現場では pcap ファイルを解析することが多いですが、Pythonで解析ロジックを組むなら scapy を使うのが定石です。

from scapy.all import rdpcap, UDP

def analyze_voip_packets(pcap_file):
    packets = rdpcap(pcap_file)
    for pkt in packets:
        # 5060番ポートはSIPシグナリング
        if pkt.haslayer(UDP) and pkt[UDP].dport == 5060:
            print(f"SIP Signaling detected: {pkt.summary()}")
        # RTPパケットの特定（メディアフロー）
        elif pkt.haslayer(UDP) and 10000 <= pkt[UDP].dport <= 20000:
            print(f"RTP Media packet: {len(pkt)} bytes")

# 実際の現場ではここからQoSフラグ（DSCP値）などもチェックします

エンジニアへのアドバイス：ブラックボックスを紐解く

Web APIを設計する際、「なぜ遅延が起きるのか」と悩むことがあるかと思います。その時、もしその通信がモバイルネットワークを介しているのであれば、単にサーバー側の負荷だけでなく、「通信事業者がパケットをどう優先順位付けしているか」を想像してみてください。

VoLTEの QCI=1 のような明示的な優先制御は、Web APIの世界では DSCP（Differentiated Services Code Point）として抽象化されます。最近のクラウドネイティブなインフラでも、パケットのクラス分けを意識した設計は、高負荷時の安定性を左右する大きな武器になります。

「ネットワークは繋がって当たり前」。そう思えるのは、裏でこういった泥臭いベアラ制御がパケットを必死に守ってくれているからです。皆さんの設計するシステムも、そんな「信頼性の根拠」を少しだけ意識してみると、一段上のエンジニアリングが見えてくるはずですよ。

それでは、また次回の現場でお会いしましょう。