IIJmio meeting 25 発表資料 https://techlog.iij.ad.jp/archives/2653

1. ©Internet Initiative Japan Inc. 1
スマホはなぜ「つながらない」のか
2019/10/19 ・ 10/26
株式会社インターネットイニシアティブ
木野 純武

2. ©Internet Initiative Japan Inc. 2
【目次】
１．今回のネタについて
２．輻輳で「つながらない」
３．ランダムアクセス手順の発生ケース
４．ランダムアクセス手順の失敗パターン
５．「圏外」に至るコンボ
６．まとめ

3. ©Internet Initiative Japan Inc. 3
１．今回のネタについて

4. ©Internet Initiative Japan Inc. 4
■前回のミーティングで
• 「MVNO素朴な疑問解決編」のスライド26
というパートがあります。
【地獄のハンドオーバー】...
うっかりバズワードになりそうな、
いい響きです。
そしてせっかくなら、なぜ「地獄」なのかという話を
次回のネタにしてみよう、と考えてみたのでした。
• 通勤電車は地獄のハンドオーバー
• 1編成の定員1500名(乗車率200%だと3000名)が、
短時間に移動します
• 屋外と異なり基地局の数が少なく、一つの基地局に
大量の利用者が集中します
• 電車がエリアに入ってきたときの負荷が高い

5. ©Internet Initiative Japan Inc. 5
■タイトルの元ネタ
• 元ネタ
日経BP「携帯電話はなぜつながるのか」
https://shop.nikkeibp.co.jp/front/commodity/0000/P84900/
第2版ですが内容は流石にいささか古いです。
とはいえ、大変良いテキストだと思います。
－ 帯に「10年後も通用する“基本”を身につけよう」とある。
第2版が2012年2月27日なので10年経過してないからセーフ？
－ せっかくなので第3版の出版を希望したいところ。
（もうすぐ5G時代がやってくるわけですし）

6. ©Internet Initiative Japan Inc. 6
２．輻輳で「つながらない」

7. ©Internet Initiative Japan Inc. 7
■「つながらない」のイメージ
• 一般的には「受信電力／品質が悪くなり基地局の電波を
つかめなくなったとき」というイメージ。
• しかし、受信電力／品質が良くても通信できなかったり、
一時的に「圏外」になるケースがある。
• 基地局やコアネットワークが混雑(輻輳)してる時に発生
しやすい。
https://www.nttdocomo.co.jp/corporate/csr/disaster/secure_connection/
より引用。 ホーム > 企業・IR情報 > CSR > 災害対策 > 重要通信の確保

8. ©Internet Initiative Japan Inc. 8
■基地局の輻輳発生は災害時だけとは限らない
• 輻輳に近い状況が頻発する環境、というのもある。
▼ 地下鉄の構内
－ アンテナの設置場所が限られる
－ 地下鉄では地上よりも少ないセルで
多数の端末を収容しなければならない
▼ 乗降客数の多い駅周辺
－ 品川駅、新宿駅、渋谷駅など
－ 特に品川駅はキャパシティ改善が難しいと聞く
▼ イベント会場
－ 何といってもコミケ
－ 隅田川花火大会
...などなど

9. ©Internet Initiative Japan Inc. 9
■基地局輻輳時の「つながらない」
• 基地局の輻輳時は、なかなかデータが通らない......
パケットが詰まったような感じになるのは、なぜか？
「データ送受信開始・再開時」や「ハンドオーバー・
再接続発生時」に必要な手順が失敗し続けている
という可能性が高い。
(上のレイヤで輻輳しているケースもありますが、今回のスコープ外)
通信を始めようとする「取っかかり」なので、ここが
完了しないと、そもそもデータが通らない。
では、その「取っかかり」の手順とは何か。
これは、
ランダムアクセス手順 (Random Access Procedure)
といい、基地局と端末との間で行われる手順である。

10. ©Internet Initiative Japan Inc. 10
■ランダムアクセス手順とは
• ランダムアクセス手順(Random Access procedure)とは...
※長いので以降は RA手順 と表記。
• 基地局との通信に必要な同期を取るための手順。
– 基地局の電波を掴むための「物理レイヤ(PHY)での同期」とは
別物で、上り通信の同期を取る意味合いが強い。
→ そもそも基地局からの同期信号(PSS/SSS)によって電波が
見えた時点で、下り方向の同期は取れている状態。
– LTEでは、複数端末からの上り通信に関して、基地局への到来
タイミングを合わせる必要があるため、FD-LTEでもある程度の
上り同期が必要になる。
• 以下のシチュエーションで必要となる。
– Idle状態から通信を始めるとき(Idle to Active)
– Connected状態で「上り同期外れ(UL out of sync)」状態から
通信を始めるとき
– ハンドオーバー開始時、再接続開始時

11. ©Internet Initiative Japan Inc. 11
■なぜ「ランダムアクセス」なのか
• 上り方向の通信開始タイミングは、端末の使用目的や
アプリケーション操作などで、基本的にはバラバラ。
– 通信を始める文脈（コンテクスト）は本当に様々なので。
• このため、多少のタイミング衝突を前提としつつ、端末
主導で任意のタイミングで送信を試みる仕組みの方が、
限られた無線リソースを効率的に使用できる。
・衝突で負けた端末は後回しにされ、
リトライすることを期待される。
・リソースが空いている状況なら適切な
タイミングでリソース割り当てが可能。
→ 総体で見ると、必要な時に必要な端末へリソースが
一定以上割り当てられる状態となっている。

12. ©Internet Initiative Japan Inc. 12
４．ランダムアクセス手順の発生ケース

13. ©Internet Initiative Japan Inc. 13
■Idle to Activeケース
• Idle to Activeとは、基地局との接続設定を持たない
Idle状態から、通信可能となるConnected状態へ移行
するプロセス。
RA手順は、この初期段階でトリガーされる。
基地局の報知情報取得
RA手順
idle
Connected
接続要求をトリガー
基地局個別のRRC設定受領＆データ通信開始
RRC接続の初期設定完了
1. RA Preamble
2. RA Response
3. Message 3
(RRC Connection Request)
4. Message 4
(RRC Connection Setup)
5. Message 5
(RRC Connection Setup Complete)

14. ©Internet Initiative Japan Inc. 14
１．RA Preamble（Message 1）
• ランダムアクセス手順における最初の制御信号
– Preambleは「予告、先触れ」という意味。
– Preambleを送信できるタイミングは報知情報で周知される。
→ 基地局ごとに異なる設定を適用可能。
• RA Preambleには以下の情報が含まれる。
– Preamble id (0～63)
・衝突ベース(Contention Based)のRA手順に使うidレンジと
非衝突ベース(non-Contention Based)のRA手順に使うレン
ジに分かれます。レンジの区切りは基地局ごとに設定可能。
→ 衝突ベース用idは自由席、非衝突ベース用idは予約席
と認識すれば、だいたいOKか。
・RA手順を開始する際、端末は衝突ベース用idからランダムに
ピックアップして、RA Preambleにセット。
・非衝突ベース用idは、HO開始時に基地局から指定される。
– RA-RNTI
・RA手順用のRNTI（RNTIについては次スライドで補足）

15. ©Internet Initiative Japan Inc. 15
補足：RNTIについて
• RNTIは「Radio Network Temporary Identifier」の
略称。
– 無線ネットワーク内で、端末や使用チャネルを識別するための
識別子で、0000～FFFFの範囲を持つ。
– 用途によってレンジが定義されている。
3GPP TS 36.321 7.1 RNTI Values から引用。

16. ©Internet Initiative Japan Inc. 16
２．RA Response（Message 2）
• RA Preambleに対して基地局が返す応答。
– なので「Response」という名称。
– 下りの「共通」制御チャネルでRA-RNTIを付けて送信される。
• RA Responseには以下の情報が含まれる。
– 対応するRA Preamble id
– 次のMessage 3送信に使うための上り無線リソース
– 送信タイミング調整用のTiming Advance command
– Message 3送信者識別用のTemporary C-RNTI
(長いので以降TC-RNTIと表記)
→ 端末はRA Preambleを送信後、自分の使ったRA-RNTIの付いた
下り制御チャネルを一定時間チェックし続ける。
→ つまり同じRA-RNTIを使った端末全てが、同じRA Responseを
受信することになる。
しかし、自分が使ったPreamble idではないResponseはスルー。
→ 一定時間内に自分宛のResponseが受信できなければ最初に戻る。

17. ©Internet Initiative Japan Inc. 17
３．Message 3
• RRC接続を要求する RRC Connection Request
メッセージの送信。
– 含まれる内容はRRC Connection Requestそのもの。
再接続の時は RRC Connection Reestablishment Request
– シチュエーションによって含まれるメッセージが変わるので、
Message 3と表現している模様。
• 端末はTC-RNTIを付与して送信する。
– 基地局から見ると、同じTC-RNTIの付いた RRC Connection
Requestが複数上がってくることになる。が......
→ ここからもう1段階、ランダムアクセスの衝突を解決するため、
識別子をもう一つ使う。これは RRC Connection Request の
本体に含まれる「GUTIの一部(M-TMSI)」であり、Message 4
による衝突解決に使われる。
→ GUTIはEPCから割り当てられた「IMSIに紐付いている
識別子」なので、これが被ることは基本的にない。

18. ©Internet Initiative Japan Inc. 18
４．Message 4
• 接続させる端末を指定し、Message 5以降から使用する
RRC初期設定を渡す RRC Connection Setup の受信。
– Message 4と同様、シチュエーションによりRRCメッセージが
変わる。再接続の時は RRC Connection Reestablishment に。
– 基地局は、Message 3に付与されたTC-RNTIを用いて返送する
ため、同じTC-RNTIを使った端末全てがこのMessage 4を受信
する。しかし、ここには接続させたい端末のM-TMSIも入る。
→ 上記により、このRA手順で接続確立する端末が一意に決定
される。これを「衝突解決(Contention-Resolution)」という。
– なお、自分宛のMessage 4でないと識別した端末は、RA手順の
リトライに入る（RA Preamble送信からやり直し）
• この時点で、基地局からTemporaryではないC-RNTIが
払い出される。以降の通信はこのC-RNTIが使われる。

19. ©Internet Initiative Japan Inc. 19
５．Message 5
• RRC設定の適用完了通知（＋NASメッセージ送信）
– 端末から、RRC Connection Setup に含まれている初期設定の
適用完了を通知する RRC Connection Setup Complete 送信。
→ RRC Connection Setup Complete にはNASメッセージが
含まれ、シチュエーションによりメッセージが異なる。
（Attach Request だったり Service Request だったり）
– 再接続の時は RRC connection Reestablishment Complete に
なるが、これにはNASメッセージは含まれない。
→ 以降は、Connected状態での通信となる。

20. ©Internet Initiative Japan Inc. 20
Idle to Activeケースのおさらい（１）
基地局の報知情報取得
idle
在圏セルと同期
■以下の報知情報からRA手順関連設定を取得
・System Information Block Type2
- 衝突／非衝突ベースのid比率
- RA Preambleの送信電力計算用パラメータ
- RA Preamble再送上限数
- RA Response受信ウィンドウ
- 衝突解決待ちタイマー値
- RA Preamble用無線リソース設定
......などなど
接続要求をトリガー
UE eNB

21. ©Internet Initiative Japan Inc. 21
Idle to Activeケースのおさらい（２）
UE eNB
・衝突ベースのidレンジから、ランダムで値を
選んでPreamble idにセット
例：32
・仕様と設定に基づきRA-RNTIをセット
例：0008
他のUE
RA Preamble 送信
・受信したRA Preamble idから1つ選択
例：32
・受信したRA-RNTIから1つ選択
例：0008
・Temporary C-RNTIの払い出し
例：10AC
・Timing Advance Commandをセット
・Message 3送信用のUL Grant情報をセット
■他の端末も同じタイミングでRA Preamble送信
- Preamble idは様々（被る端末もいる）
- FD-LTEだとRA-RNTIは他の端末も同じになる
ことが多い。

22. ©Internet Initiative Japan Inc. 22
Idle to Activeケースのおさらい（３）
UE eNB
他のUE
RA Response 返送
■一つのRA Responseを複数の端末が受信。
- Preamble idとRA-RNTIが一致する端末群が受信
他のUE
Message 3 送信
(RRC Connection Request)
・Message 3用に、RA Responseで払い出された
TC-RNTIをセット
例：10AC
・位置登録／更新時に割り当てられたGUTIから
M-TMSIを抽出し、Message 3(RRC Connection
Request)に埋め込み。
例：e58544f2
・TA Commandの情報を用いて、Message 3の
送信タイミングを計算
・Message 3用無線リソースに合わせて送信準備
■複数の端末から同じ無線リソースでMessage 3が
送信される。

23. ©Internet Initiative Japan Inc. 23
Idle to Activeケースのおさらい（４）
UE eNB
・受信できたMessage 3からM-TMSIを抽出し、
Message 4のMACレイヤ部分に埋め込み。
例：e58544f2
・C-RNTIの払い出し
例：10AC
・Message 4となるRRC Connection Setupに
含める情報をセット。
Message 4 送信
(RRC Connection Setup)
他のUE
■Message 4を受信するが、
自分宛ではないと判定。
↓ ↓ ↓
RA手順を最初からやり直し
RA手順
リトライへ
Scheduling Request送信
（Message 5送信の上り無線リソース割り当てを要求）
制御チャネルで割り当てる上り用リソースを通知
（端末個別なので、ここで早速C-RNTIが使われる）
衝突解決！
（Contention Resolved）

24. ©Internet Initiative Japan Inc. 24
Idle to Activeケースのおさらい（５）
UE eNB
・送信すべきNASメッセージを形成。
例：Service Request
・RRC Connection Setup CompleteにNAS
メッセージを包む。
・割り当てられた上り用リソースにC-RNTIを
付与。
Message 5 送信
(RRC Connection Setup Complete
＋Service Request)
Connected
基地局個別のRRC設定受領 ＆ データ通信開始

25. ©Internet Initiative Japan Inc. 25
■上り同期外れ状態から通信を始めるケース（１）
• そもそも「上り同期外れ(UL out of sync)」状態とは？
１．送信タイミングを補正する情報がない状態
・RA手順完了後は、送信タイミング調整のためのTiming
Advance command(以後TA commandと表記)という
制御信号が、基地局から一定間隔で送られてくる。
・上りの送信タイミングは常に調整が必要。
しかし、上りデータが無い時にTA Commandを送るのは
リソースの無駄遣いなので、一定時間が経過すると基地局
側がTA Command送信を止める（ことが多い）
→ 端末としては、送信タイミングを調整するための
情報が失われたことになる。
よって「上り同期外れ」と見なす。
→ 同期を取り直すためにRA手順をやり直す。

26. ©Internet Initiative Japan Inc. 26
■上り同期外れ状態から通信を始めるケース（２）
２．上り用リソースを要求しても応答がなくなった状態
・端末が上りデータを送信するには、端末側から上り通信を
始めたいことを通知する制御信号 Scheduling Request を
を送信し、基地局から「使用してよい上りの無線リソース
情報(UL Grant)」を提示してもらう必要がある。
・しかし、Scheduling Requestを何度送信してもリソース
割り当てが来ないときは、そもそもScheduling Request
自体の送信が同期できていない可能性がある。
・この時点で仕様上「上り同期外れ」と見なす。
→ 端末としては、RA手順を通して同期を取り直し、
Scheduling Request送信からやり直そうとする。
※なお、Scheduling Request再送上限回数は Message 4
時点で端末に通知される。
上限回数はキャリアによってまちまちの模様。

27. ©Internet Initiative Japan Inc. 27
■ハンドオーバー(HO)のケース
• HOは「基地局を移って通信を再開する」プロセス
– つまり、HO先の基地局と同期する必要がある。
– HO時には一般的に、非衝突ベース(non-Contention Based)の
Preamble idが使われる。
→ HO処理の関係で基地局間で端末情報も引き渡せるので、
改めて無線区間でC-RNTIの払い出しや設定通知を実施
する意義が薄い。
UE eNB
RA Preamble 送信
RA Response 返送
ハンドオーバー完了＆Message 3 送信
(RRC Connection Reconfiguration Complete)
ハンドオーバー指示
(RRC Connection Reconfiguration)
■このRRCメッセージ内に
RA Preambleで使用すべき
Preamble id と移動先での
C-RNTIが入っている。
■指定されたPreamble
idをセットして送信。
HO処理の時点で衝突解決が
不要なので、Message 4以降は
発生しない。

28. ©Internet Initiative Japan Inc. 28
■再接続のケース
• 何らかの理由で一時的に無線リンク断などが発生し、
どこかの基地局へ再接続を試みるとき。
– 概ね、Idle to Activeの時とフローは同じ。
再接続しようとする基地局と同期を取る必要がある。
– Message 3 / 4 / 5 が再接続用のRRCメッセージになる。
・Message 3：RRC Connection Reestablishment Request
・Message 4：RRC Connection Reestablishment
・Message 5：RRC Connection Reestablishment Complete
※なお、HO時のように、移動先の基地局に端末情報が転送されて
いるとは限らない(再接続できるなら接続を試みる処理のため)
→ しかし基地局は、自分の把握していない端末が再接続を
試みてきた時、一旦は再接続要求をRejectする。
その上で、Idle to Activeのフローを踏んで接続を再確立
させる流れとなる。
→ 結局はRA手順が必要となる。

29. ©Internet Initiative Japan Inc. 29
５．ランダムアクセス手順の失敗パターン

30. ©Internet Initiative Japan Inc. 30
■RA手順の失敗パターン（１）
• 失敗パターンは以下の2つに大別される。
– １．RA Responseを時間内に受信できなかった。
・Responseに対する受信ウィンドウ内で、自分が使った
Preamble idを含むResponseが来なかった。
→ RA Preambleを再送する。しかし再送超過すると...
→ Idle to Activeケース
端末は無線リンク断（Radio Link Failure）と
判断し、RA手順を諦めてセルサーチを開始。
（アンテナピクトが「圏外」になることも）
→ 上り同期外れ通信開始ケース
「Random Access problem」発生と判断され
再接続ケースへ移行。
→ HOケース
HO失敗と判断され、再接続ケースへ移行。
→ 再接続ケース
再接続待ちタイマー(T311)起動中にどこかへ
再接続できなければ、Idle状態に遷移。

31. ©Internet Initiative Japan Inc. 31
■RA手順の失敗パターン（２）
– ２．Message 4を時間内に受信できなかった or
受信したMessage 4が自分宛てではなかった。
・一般的には、衝突解決で負けたケース。
・下りの受信品質劣化で(本来なら受信できているはずの)
Message 4を取り損ねたケースも発生し得る。
→ いずれにせよ、RA手順を最初からやり直す。

32. ©Internet Initiative Japan Inc. 32
参考：RA Preamble再送超過→再接続
※上野東京ライン宇都宮線(下り)での端末ログを、Sigma-PAで解析したものです。

33. ©Internet Initiative Japan Inc. 33
６．「圏外」に至るコンボ

34. ©Internet Initiative Japan Inc. 34
■RA手順単体の失敗は大した話ではない
• 失敗が連続するか、複数の失敗パターンが絡まって
発生するのが問題である。
– つまるところ「失敗パターンのコンボ」である。
– 失敗パターンが多発するならそのコンボも発生しやすくなる。
• 考えられる失敗パターンのコンボ例を以下2つ提示。
– 地下鉄ケース
– イベント会場ケース
※実際に発生している端末ログを取得して紹介
したかったが、状況的に色々と難しい。
- 混雑する車両内でPCと端末を繋いでログ取得してる姿、
端から見ると怪しい人ですよね...
また、最近はキャリア側の輻輳対策もしっかり
していることが多い（すばらしいことです）

35. ©Internet Initiative Japan Inc. 35
■失敗コンボ（地下鉄のケース）
• 地下鉄の車両内でスマートフォン使って通信している
状態から...
1. Connected状態で通信中
2. HO実施
3. HOケースでの失敗パターン発生
4. 再接続処理スタート
5. 再接続ケースでの失敗パターン連続発生
6. 再接続待ちタイマ(T311)満了
7. Idle状態に遷移（ここで圏外ピクトになっていることも）
漏洩同軸ケーブルによる
A駅からのエリア
漏洩同軸ケーブルによる
B駅のエリア
１
２～３
７
６
４～５

36. ©Internet Initiative Japan Inc. 36
■失敗コンボ（イベント会場のケース）
• イベント会場でイベントを見ながらスマートフォンで
通信している状態から...
1. Connected状態で通信中
2. Scheduling Request(SR)送信し続けるが無反応
3. SR再送超過
4. 上り同期外れ状態に移行
5. 上り同期外れ通信開始ケースで失敗パターン発生
6. 再接続処理スタート
7. 再接続ケースでの失敗パターン連続発生
8. 再接続待ちタイマ(T311)満了
9. Idle状態に遷移
10. 送受信すべきデータが残っているためIdle to Active開始
11. Idle to Activeでの失敗パターン発生
12. 無線リンク断を検出し「圏外」判定

37. ©Internet Initiative Japan Inc. 37
７．まとめ

38. ©Internet Initiative Japan Inc. 38
■輻輳していると...
• RA手順による接続試行が激増する。
– 個々の端末で、通信を開始するタイミングも
トラフィック量も異なる。
– 基地局も頑張るものの、RA手順を完了できない
端末が溢れかえることに。
– RA Preamble再送を繰り返し、RA手順が通っても衝突解決で
負けてリトライし、その間に通信はまったく通らない...
→ まさに「地獄」

39. ©Internet Initiative Japan Inc. 39
■MVNOの立ち位置から何とか改善できないのか？
• この問題は無線区間の話なので、MVNOもMNOも等しく
影響を受ける。
– MVNO素朴な疑問解決編 (IIJ 堂前)のスライド18から引用
• 残念ながら、MVNO単独で改善する
ことはまず不可能...
• また、MVNOがこの現象を追うには端末ログを
取得して調査していくしかない。
MVNO分岐
キャリア本管
MVNO設備
← ここで発生している問題である

40. ©Internet Initiative Japan Inc. 40
■5G NRについては？
• 絶賛勉強中・調査中...
• とはいえRA手順のコンセプトは4G(LTE)と一緒の模様。
– しかし、細かい処理や条件はさらに複雑化する。
– 例えば、4Gと5Gが並存するNSAはDual Connectivityが前提。
片方が同期外れとなった場合など処理パターンがさらに増える。
• IIJとしても、引き続き調査・解析できるよう努力して
いくが、5G NRの基地局シミュレータはお値段が...
– 5G NRはマルチアンテナ前提なので、シミュレータ設備の規模
拡張は避けられない。
• 5G時代を見据えた調査体制をどのように
構築していくべきか、悩ましいところ。

41. ©Internet Initiative Japan Inc. 41
ご清聴ありがとうございました

42. ©Internet Initiative Japan Inc. 42
■補記
本資料において、一部のスライドに「いらすとや」さんのフリー素材を
利用させていただいております。
https://www.irasutoya.com/
本資料で使用されている右の「バリーくん」は、
弊社内で開発中のアラート通知・エスカレーション
支援システム「Barry」で使われている、マスコット
キャラクターです。
「Barry」とバリーくんについての紹介はこちら。
～ IIJ Technical NIGHT vol.8 ～
- モチベ高い障害対応のためにアプリ作ってみた
https://eng-blog.iij.ad.jp/archives/3903

43. ©Internet Initiative Japan Inc. 43
■参考資料・仕様
• 資料
– インプレス標準教科書シリーズ 5G教科書 LTE/IoTから5Gまで
https://book.impress.co.jp/books/1118101004
– 3G Evolutionのすべて LTEモバイルブロード方式技術
https://www.maruzen-publishing.co.jp/item/b293796.html
• 3GPP spec (基本的にRelease 15を参照)
– TS 23.122
• Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode
– TS 24.301
• Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)
– TS 36.133
• Evolved Universal Terrestrial Radio Access (E-UTRA);Requirements for support of radio resource
management
– TS 36.211
• Evolved Universal Terrestrial Radio Access (E-UTRA);Physical channels and modulation
– TS 36.213
• Evolved Universal Terrestrial Radio Access (E-UTRA);Physical layer procedures
– TS 36.304
• Evolved Universal Terrestrial Radio Access (E-UTRA);UE Procedures in Idle Mode
– TS 36.321
• Evolved Universal Terrestrial Radio Access (E-UTRA);Medium Access Control (MAC) protocol specification
– TS 36.331
• Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Resource Control (RRC);Protocol specification