IIJmio meeting 7 MVNOとSIMフリー端末の問題について
•
31 likes•95,639 views
この資料はIIJmio meeting 7で発表されたものです。詳細は下記blogをご覧下さい。 http://techlog.iij.ad.jp/archives/1464
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to IIJmio meeting 7 MVNOとSIMフリー端末の問題について
Similar to IIJmio meeting 7 MVNOとSIMフリー端末の問題について (20)
More from techlog (Internet Initiative Japan Inc.)
More from techlog (Internet Initiative Japan Inc.) (20)
IIJmio meeting 7 MVNOとSIMフリー端末の問題について
- 1. 1 株式会社インターネットイニシアティブ 大内 宗徳 IIJmio mtg #7 MVNOとSIMフリー端末について
- 2. 2 はじめに • ユーザの利用する端末が(キャリア白ROM端末)から (SIMフリー端末)へ急激に移行 高性能、低価格な端末の選択肢が増えて来たため。 • IIJもSIMフリー端末の種類が増え、ユーザの選択肢が 広がることは大歓迎！ • しかし、SIMフリー端末の普及で、接続問題が多く報告 されるようになってきた。 • IIJ側で遭遇した接続問題とその解析結果を共有しま す
- 4. 4 技適とMNOの相互接続テスト（IOT)について - 1 • 技適マークのある’’SIMフリー端末’’は、モバイルキャ リアのネットワークに合法的に接続可能 • 技適は下記の２つの制度を意味 （引用） 総務省 電波利用ホームページ|無線機器基準認証制度について良くある質問（ＦＡＱ） http://www.tele.soumu.go.jp/j/sys/equ/tech/faq/index.htm 1. 技術基準適合証明制度について (送信電波関連の制度） 詳細は IIJmio meeting #2 の資料に -> http://techlog.iij.ad.jp/archives/879 2. 技術基準適合認定制度について (電話、データ通信の制度) ⇒ 端末機器を電気通信事業者の電気通信回線設備に接続するためには、当該事業者の接続検査を 受けることが必要となっていますが、その端末機器を使用する者の利便の向上に資する等の観点から、 総務省令で定める端末機器について、登録認定機関が総務省令で定める技術基準に適合していること を認定する制度（技術基準適合認定制度）を特例として設けています。 この認定を受けた端末機器は、それを接続する場合に当該事業者による接続検 査が不要となる措置がとられており、その端末機器を使用する者の利便の向上 等に役立っています。 => SIMフリー端末はこの制度で利用可能になっているが。。。
- 5. 5 技適とMNOの相互接続テスト（IOT)について – ２ • モバイルキャリアは接続テスト(IOT)の実施を推奨 • 相互接続ガイドブック | 企業情報 | NTTドコモ https://www.nttdocomo.co.jp/corporate/disclosure/interconnection/guide/ -> 第2章 相互接続開始までの手順 -> 他事業者様が自ら移動無線装置を調達し接続される場合に必要となる事項、を抜粋 当社では、接続約款の中で混信等防止の規定を定めており、混信等が他事業者様が 自ら調達された移動無線装置に起因する場合は、発信停止等の対応を行うことになり ます。このような事態を未然に防ぐため、移動無線装置に係る確認試験により、事前 に当社ネットワークと正常な接続確認を行うことをおすすめします。 • IOTは非常に重要 • 接続時にやりとりされるパラメータや接続手順で、MNO側の設備との 接続に問題ないか確認しないと、接続が不安定になる要因に • 最初に端末を出す前やファームのバージョンアップの前には必須 • 一方、IOTはそれなりのコストがかかるため、SIMフリー端末の場合、 実施されない場合が多いが、これがトラブルにつながることに…
- 6. 6 MVNOで端末に起因する問題が発生した場合 • MNOのIOTを通してない端末で問題が発生した場合 はMVNOの責任で頑張らないといけない • しかし、MNOと端末でやりとりされる制御情報は、 IIJにほ とんど分からない => 問題の切り分けがほとんど出来ないことに… • 具体的なシーケンスを例にこの問題を説明 MNO (NTTドコモ) IIJ インターネット・ ・
- 7. 7 LTE端末の初期の接続シーケンス例 - 1 MME HSS端末 RRC Connection Request eNB S-GW IIJ P-GW RRC Connection Setup RRC Connection Setup Complete Attach Request Identity Request Identity Response Authentication Information Request Authentication Information Response Authentication Request Authentication Response Security Mode Command Security Mode Complete ESM Information Request ESM Information Response EIR Identity Check Request Identity Check Ack Update Location Request Update Location Answer Create Session Request Create Session Request MNO(NTTドコモ) ← モバイルネットワークへの 接続要求 ← IMSI or IMEI要求 ← SIM認証 ← ユーザ認証ベクトル生成 ← 端末とMME間の暗号化,IMEI要求 ← IMEIチェック ← 接続情報を通知:APN,PDP Type, PCO(user/pass,DNS要求) ← 位置情報更新/ユーザのサービス に利用する各種情報の取得 ← 下りデータ通信トンネルの 作成。MVNOのユーザ認証
- 8. 8 MNO(NTTドコモ) LTE端末の初期の接続シーケンス例 - 2 MME HSS端末 eNB S-GW IIJ P-GWEIR UE Capability Enquiry UE Capability Response Security Mode Command Security Mode Complete Create Session Response RRC Connection Reconfiguration(Attach Accept) RRC Connection Reconfiguration Complete Attach Complete Initial Context Setup Request(Attach Accept) Initial Context Setup Response Modify Bearer Response Modify Bearer Request Modify Bearer Request Modify Bearer Response UE Capability Info Indication 接続シーケンス中で赤の部分しか、IIJは分からない これだけの情報で端末側の問題の調査はほぼ不可能 ← 上りデータ通信トンネル作成 IPアドレス, DNSアドレス返信 ← 端末の無線(3G/LTE)能力の取得 Create Session Response ← 端末とeNB間の暗号化 ← 上りデータ通信トンネル作成 ← データ通信トンネル作成 IPアドレス, DNSアドレス返信
- 9. 9 端末の接続問題の調査のために • MVNOのネットワーク設備(P-GW/GGSN)だけでは、問 題の調査は不可能 • モバイルキャリアのネットワークを直接調べることは出来な いため • MVNOにできることは？ • 端末<->基地局間の無線区間でやりとりされ制御情報を何 らかの方法で調べることぐらい • この具体的な調査方法について解説 MNO (NTTドコモ) IIJ
- 11. 11 無線区間の制御信号を調べる調査手法 • MVNOで可能な下記の３種類を検討 1. 端末内のBasebandチップから制御情報を抜く 2. 無線区間で直接、制御情報を抜く 3. 基地局側(シミュレータ)で制御情報を抜く MNO (NTTドコモ)方法１ 方法2 方法3
- 12. 12 1. 端末内のBasebandチップから制御情報を抜く • Basebandチップとは？ • デジタル信号と無線信号の相互変換、モバイルネットワークとの接続制 御を行っている • 原理的には制御情報をここから抜くことが可能 • 利点: Qualcommチップであれば比較的容易に可能。製品も存在する 暗号化前/復号化後の基地局との制御情報を取得可能 ‘’後述の方法’’に比べると安価 • 欠点: 市販の端末から制御情報を抜くことは敷居が高い Qualcommチップ以外だと制御情報を抜くのが困難 Application Processor モバイル制御部分 アプリケーションOS(Android/iOS) 制御情報 IPパケット RF Baseband Processor (Qualcommなど) 制御情報 (製品例) Meritech社 Sigma-ML/LA/PA Accuver社 XCAP/XCAL SwissQual社 QualiPoc
- 13. 13 2. 無線区間で直接、制御情報を抜く • 利点: 端末や基地局に手を加えなくて済む Basebandチップの種類を問わない • 欠点: 調査対象の端末の電波だけを捕まえるのが困難 制御情報は暗号化されているので復号化するために工 夫がいる(暗号化キー入手のため、BasebandチップとSIM 間の情報を抜く必用がある) 非常に高価 MNO (NTTドコモ) (製品例) ABIT社 エアプロトコルモニター
- 14. 14 3. 基地局側(シミュレータ)で制御情報を抜く • 基地局シミュレータとは？ • 本来は端末開発時の動作確認用 • 基地局を含むモバイルネットワーク動作をシミュレート可能 • 利点: 端末に手を加えなくて済む 暗号化前/復号化後の基地局との制御情報を取得可能 Basebandチップの種類を問わない • 欠点: キャリアのネットワーク動作を完全にシミレーションさせ るには、ノウハウが必要 実際の問題を再現させられるとは限らない 非常に高価 MNO (NTTドコモ) 基地局シミュレータ (製品例) アンリツ社 シグナリングテスタ
- 15. 15 今回採用した無線区間の制御信号を調べる方法 • 端末内のQualcommなBasebandチップから制御情報を 抜く方法を採用した • Meritech社の Sigma-ML/LA/PA を利用した • 制御情報としては、’L3プロトコル’ を解析した
- 16. 16 Meritech社 Sigma-ML/LA • 通信品質測定ソフト • Baseband情報をリアルタイムで確認可能 • Android向けアプリ: Sigma-ML (下図参照) • PC接続のUSBモデム向け: Sigma-LA
- 19. 19 • 事象 • Lollipop(Android 5.0)から端末初期設定時に行われるだけ だったAPNサーチが、なぜか、電源on, 機内モード解除等を 契機(?)に再度行われて、接続に問題が生じる • 動作 Nexus5/Nexus6: 接続に時間がかかり、3G接続しか出来なくなる Nexus7(2013): 接続が不安定になる？ • 対策 • APN設定を現在契約しているMVNO以外は全て削除 • 3Gにしか接続出来なくなった場合は、一度機内モードにして 解除する • 原因 • Android側の問題？ • 詳細は次のページからで説明 事例1: LollipopでAPNサーチを頻繁に繰り返す問題
- 20. 20 Nexus5/5.1の場合の接続シーケンス - 1 MME HSS端末 RRC Connection Request eNB S-GW IIJ P-GW RRC Connection Setup RRC Connection Setup Complete Attach Request Identity Request Identity Response Authentication Information Request Authentication Information Response Authentication Request Authentication Response Security Mode Command Security Mode Complete ESM Information Request ESM Information Response EIR Identity Check Request Identity Check Ack Update Location Request Update Location Answer MNO(NTTドコモ,LTE) ←APN:mopera.net へ接続を試みる RRC Connection Release Attach Reject ← SIMが許可されてないAPNの ため拒否される 同じシーケンスをあと 2 回繰り返すが、APN:mopera.net から、次の APN検索に進まず、3Gにフォールバック。次のページに続く
- 21. 21 MNO(NTTドコモ,3G) Nexus5/5.1の場合の接続シーケンス - 2 SGSN HLR端末 NodeB RNC EIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Attach Request Authentication Data Request Authentication Data Response Authentication and Ciphering Request Authentication and Ciphering Response Security Mode Command Security Mode Complete Utran Mobility Information Utran Mobility Information Confirm Attach Accept Attach Complete GMM Information RRC Connection Release RRC Connection Release Complete IMEI Check Request IMEI Check Response Update Location Request Update Location Ack Insert Subscriber Data Insert Subscriber Data Ack モバイル網のPS Attachのみ。 次のページに続く ← APN接続/ユーザ認証失敗で、LTE接続 できずに、3Gにフォールバックした場合で ここで端末が無線接続能力を通知すると きに3G(UTRAN)だけの能力を通知 IIJ P-GWS-GW LTE
- 22. 22 MNO(NTTドコモ,3G) LTE Nexus5/5.1の場合の接続シーケンス - 3 SGSN HLR端末 NodeB RNC EIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Service Request Security Mode Command Security Mode Complete Utran Mobility Information Utran Mobility Information Confirm Activate PDP Context Reject RRC Connection Release RRC Connection Release Complete Activate PDP Context Request ← この接続拒否のシーケンスを下記のAPN順 で繰り返す APN: bmobile.ne.jp, user:bmobile@fr APN: bmobile.ne.jp, user:bmobile@u300 APN: bmobile.ne.jp, user:bmobile@spd APN: bmobile.ne.jp, user:bmobile@cm IIJ P-GWS-GW
- 23. 23 MNO(NTTドコモ,3G) LTE Nexus5/5.1の場合の接続シーケンス – 4 SGSN HLR端末 NodeB RNC IIJ P-GWEIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Service Request Security Mode Command Security Mode Complete Utran Mobility Information Utran Mobility Information Confirm Activate PDP Context Accept Activate PDP Context Request pdp-type=ipv4ipv6 で接続完了。ただし端末からは、 無線は3G接続だけの能力(UTRAN)しかないと通知し、 LTE能力を無効化しているため、LTE側に遷移しない 一度機内モードにして再接続すると、覚えたAPNへ 接続に行き、無線のLTE接続能力を広報するように なるので、LTEに接続可能に P-TMSI Reallocation Command P-TMSI Reallocation Complete Radio Bearer Setup Radio Bearer Setup Complete Create Session Request Create Session Response Measurement Control Transport Channel Reconfiguration Transport Channel Reconfiguration Complete Signaling Connection Release Indication RRC Connection Release RRC Connection Release Complete S-GW ↑ EPC capabilityがあるため、 S-GW経由でデータ接続を確立 ← APN:iijmio.jp, pdp-type=ipv4ipv6 で接続を要求
- 24. 24 • 事象 • 一部の端末が3Gで接続する際にAPNプロトコル: IPv4/IPv6 が選択されていると接続できなくなる • 動作 Nexus7(2013): 3G接続に落ちた場合で接続できなくなる Nexus5/Nexus6: 問題発生せず • 対策 • APNプロトコル:IPv4/IPv6 を選択しない • 5.1で、APN: IIJmio(3G端末) があれば、これ利用するようにして、これ以 外のAPN設定を全て削除。接続できない場合は一度機内モードにして 解除 • 原因 • キャリア側の問題？ • 詳細は次のページからで説明 事例2:APNプロトコル:IPv4/IPv6で接続できなくなる問題
- 25. 25 3.5. LTE端末のEPC Capabilityと EUTRAN Capabilityの関係について
- 26. 26 LTE端末のEPC CapabilityとEUTRAN Capabilityの関係 - 1 • EPC Capability:○/EUTRAN Capability:○の場合 • 3G/LTE無線両方に接続可能 • LTE網を経由のハンドオーバが可能 -> IPv6利用可能 3G NTTドコモ LTE NTTドコモ IIJ P-GW IIJ GGSN IPv6不可 IPv6可能 EPC Capability:○ の場合 横つなぎが利用される EUTRAN Capability: ○の場合 LTE基地局に接続可能
- 27. 27 3G NTTドコモ LTE NTTドコモ IIJ P-GW IIJ GGSN IPv6不可 IPv6可能 LTE端末のEPC CapabilityとEUTRAN Capabilityの関係 - 2 • EPC Capability:○/EUTRAN Capability:×の場合 • 端末が無線LTE能力を無効化 -> 3G基地局経由での接続 • コアネットワークはLTEを経由 -> IPv6利用可能 EPC Capability:○ の場合 横つなぎが利用される
- 28. 28 3G NTTドコモ LTE NTTドコモ IIJ P-GW IIJ GGSN IPv6不可 IPv6可能 LTE端末のEPC CapabilityとEUTRAN Capabilityの関係 - 3 • EPC Capability:×/EUTRAN Capability:×の場合 • 端末が無線LTE能力を無効化 -> 3G基地局経由での接続 • コアネットワークは3Gを経由 -> IPv6利用不可 NTTドコモではここのIPv6利用 はサポートしてない
- 29. 29 MNO(NTTドコモ,3G) LTE Nexus7(2013)/5.0.xで3Gの場合の接続シーケンス - 1 SGSN HLR端末 NodeB RNC EIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Attach Request Authentication Data Request Authentication Data Response Authentication and Ciphering Request Authentication and Ciphering Response Security Mode Command Security Mode Complete Utran Mobility Information Utran Mobility Information Confirm Attach Accept Attach Complete GMM Information RRC Connection Release RRC Connection Release Complete IMEI Check Request IMEI Check Response Update Location Request Update Location Ack Insert Subscriber Data Insert Subscriber Data Ack モバイル網のPS Attachのみ。 次のページに続く ← 3Gモードにしているため、ここで端末が 無線の3G(UTRAN)/LTE(EUTRAN)能力を 通知するときにUTRANだけの能力を通知 IIJ P-GWS-GW IIJ GGSN ここで端末のLTEコア接続能力 (EPC capability)を通知しない 3GPPの仕様では3Gに接続する 場合ででも、EPC capabilityを 通知する必要があるのだが…
- 30. 30 MNO(NTTドコモ,3G) LTE SGSN HLR端末 NodeB RNC IIJ P-GWEIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Service Request Security Mode Command Security Mode Complete Activate PDP Context Accept Activate PDP Context Request Radio Bearer Setup Radio Bearer Setup Complete Create PDP Context Request Create PDP Context Response Measurement Control Transport Channel Reconfiguration Transport Channel Reconfiguration Complete S-GW EPC capabilityがないため、 SGSN->GGSNに直接着信 ドコモ網はSGSN<->GGSN接続ではpdp-type=ipv4ipv6 をサポートしてない SGSNがpdp-type=ipv4に変換して接続要求を送信 IIJ GGSN pdp-type=ipv4ipv6の接続を要求 ← 端末には、 pdp-type=ipv4として要求を受け 付けた旨が通知され、アドレスが返る Activate PDP Context Reject Activate PDP Context Request Radio Bearer Release Radio Bearer Release Complete ← 端末はpdp-type=ipv4ipv6の要求が通らなかった ので、IPv6用にpdp-type=ipv6で追加で接続を要求 Measurement Control ← 3Gドコモ網はpdp-type=ipv6を受け付けないため、 接続が拒否され、接続を切断されてしまうRRC Connection Release RRC Connection Release Complete Nexus7(2013)/5.0.xで3Gの場合の接続シーケンス - 2 RRC Connection Release Complete
- 31. 31 MNO(NTTドコモ,3G) LTE SGSN HLR端末 NodeB RNC EIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Service Request Security Mode Command Security Mode Complete Activate PDP Context Reject RRC Connection Release RRC Connection Release Complete Activate PDP Context Request IIJ P-GWS-GW Nexus7(2013)/5.0.xで3Gの場合の接続シーケンス - 3 Service Request ← pdp-type=ipv6の要求が通らなかったので、 再度接続を要求 ← 3Gドコモ網はpdp-type=ipv6を受け付けないため、 接続が拒否され、接続が切断されてしまう RRC Connection Release Complete RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Service Request Service Reject RRC Connection Release RRC Connection Release Complete ← 一定時間後、pdp-type=ipv4の接続をデータ通信 に利用しようとするが、その接続はありませんと 網側から拒否されて切断される pdp-type=ipv4の接続がなくなってしまったので、 最初の接続要求pdp-type=ipv4ipv6に戻り、同様 のことを繰り返し、不安定な状態が延々と続く
- 32. 32 事例3:Nexus7(2013)で変なデータ接続をしようとする問題 • 事象 • LTEでデータ接続を確立した状態で、追加でデータ接続を要 求して、接続が不安定になっている？ • 再現させにくい問題のため、ユーザ影響が不明 • 動作 • Nexus7(2013): 5.0.1で発生を確認 • その他は発生せず • 対策 • 打つ手なし • 原因 • Basebandファームの問題？？ • 詳細は次のページからで説明
- 33. 33 MNO(NTTドコモ,LTE) Nexus7/5.0.1の場合の接続シーケンス - 1 MME HSS端末 RRC Connection Request eNB S-GW IIJ P-GW RRC Connection Setup RRC Connection Setup Complete Attach Request Identity Request Identity Response ESM Information Request ESM Information Response EIR ←APN:mopera.net, user: mio@iij, pass: iij で接続を試みる。user/passがおかしい… RRC Connection Release Attach Reject ← SIMが許可されてないAPNの ため拒否される 次へ続く
- 34. 34 MNO(NTTドコモ,LTE) Nexus7/5.0.1の場合の接続シーケンス - 2 MME HSS端末 RRC Connection Request eNB S-GW IIJ P-GW RRC Connection Setup RRC Connection Setup Complete Attach Request Authentication Request Authentication Response Security Mode Command Security Mode Complete ESM Information Request ESM Information Response EIR RRC Connection Release Attach Reject ←APN:mopera.net, user: mio@iij, pass: iij で再び接続を試みる。user/passがおかしい… ← SIMが許可されてないAPNの ため拒否される 次へ続く
- 35. 35 MNO(NTTドコモ,LTE) Nexus7/5.0.1の場合の接続シーケンス – 3 MME HSS端末 RRC Connection Request eNB S-GW IIJ P-GW RRC Connection Setup RRC Connection Setup Complete Attach Request Authentication Request Authentication Response Security Mode Command Security Mode Complete ESM Information Request ESM Information Response EIR Update Location Request Update Location Answer Create Session Request Create Session Request ←APN:iijmio.jp, user: mio@iij, pass: iij で再び接続を試みる -> OK 次へ続く
- 36. 36 MNO(NTTドコモ,LTE) Nexus7/5.0.1の場合の接続シーケンス - 4 MME HSS端末 eNB S-GW IIJ P-GWEIR UE Capability Enquiry UE Capability Response Security Mode Command Security Mode Complete Create Session Response RRC Reconfiguration(Attach Accept) RRC Reconfiguration Complete Attach Complete Initial Context Setup Request(Attach Accept) Initial Context Setup Response Modify Bearer Response Modify Bearer Request Modify Bearer Request Modify Bearer Response UE Capability Info Indication Create Session Response EMM Information ここまでは通常のシーケンスなのだが… 次へ続く
- 37. 37 MNO(NTTドコモ,LTE) Nexus7/5.0.1の場合の接続シーケンス - 5 MME HSS端末 eNB S-GW IIJ P-GWEIR PDN Connectivity Request PDN Connectivity Reject ←APN:dmjplat.net, user: mobile@rakutenbb.jp 追加の データ接続を要求するが許可されてないAPNのため拒 否される PDN Connectivity Request PDN Connectivity Reject ←APN:bmobile.ne.jp, user: bmobile@am で同様RRC Connection Reconfiguration RRC Connection Reconfiguration Complete PDN Connectivity Request ←APN:bmobile.ne.jp, user: bmobile@aeon で同様 Identity Request RRC Connection Reconfiguration RRC Connection Reconfiguration Complete PDN Connectivity Reject PDN Connectivity Request PDN Connectivity Reject RRC Connection Reconfiguration RRC Connection Reconfiguration Complete ←APN:bmobile.ne.jp, user: bmobile@zsim で同様 PDN Connectivity Request PDN Connectivity Reject RRC Connection Reconfiguration RRC Connection Reconfiguration Complete ←APN:bmobile.ne.jp, user: bmobile@fr で同様 次へ続く
- 38. 38 MNO(NTTドコモ,LTE) Nexus7/5.0.1の場合の接続シーケンス - 6 MME HSS端末 eNB S-GW IIJ P-GWEIR PDN Connectivity Request PDN Connectivity Reject ←APN:bmobile.ne.jp, user: bmobile@u300 で同様 RRC Connection Reconfiguration RRC Connection Reconfiguration Complete ←一旦切断されて再接続を試みる RRC Connection Release Service Request RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Security Mode Command Security Mode Complete PDN Connectivity Request UE Capability Enquiry UE Capability Response RRC Connection Reconfiguration RRC Connection Reconfiguration Complete PDN Connectivity Reject ←APN:bmobile.ne.jp, user: bmobile@spd で同様 次へ続く
- 39. 39 MNO(NTTドコモ,LTE) Nexus7/5.0.1の場合の接続シーケンス - 7 MME HSS端末 eNB S-GW IIJ P-GWEIR PDN Connectivity Request PDN Connectivity Reject ←APN:bmobile.ne.jp, user: bmobile@cm で同様 RRC Connection Reconfiguration RRC Connection Reconfiguration Complete ← ココで一旦終了。切断された後電波サーチ…RRC Connection Release
- 40. 40 事例4: 認証失敗時にEMM Cause #15が返ってくる問題 • 事象 • 事例1の事象に似ているのだが、3Gで接続後、3G->LTEの ハンドオーバに必ず失敗して、接続ができない状態に陥る • 2015年になってから問題が発生して３月下旬に収束 • 動作 • LTE端末(Androidに限らない)で広範囲に発生 • 対策 • 事例１と同様 • 現状は問題が発生しない状況になっている • 原因 • 原因は不明。キャリア設備の問題だった？？ • 詳細は次のページからで説明
- 41. 41 Nexus6/5.1.0の場合の接続シーケンス - 1 MME HSS端末 RRC Connection Request eNB A S-GW IIJ P-GW RRC Connection Setup RRC Connection Setup Complete Attach Request Identity Request Identity Response ESM Information Request ESM Information Response EIR MNO(NTTドコモ,LTE) RRC Connection Release Attach Reject ←APN:mopera.net へ接続を試みる ← SIMが許可されてないAPNのため拒否される。通常、 EMM Cause:ESM failure, ESM Cause:User authentication failed が返って来るが、 この場合は何故か EMM Cause:No suitable cells in Tracking Area(#15) が返ってきた。 #15 を受け取ると端末はその基地局（eNB A)に一定 時間接続できなくなる。 eNB B 接続可能なLTE基地局探索… 次へ続く
- 42. 42 MNO(NTTドコモ,LTE) Nexus6/5.1.0の場合の接続シーケンス - 2 MME HSS端末 eNB A S-GW IIJ P-GWEIReNB B RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Attach Request Authentication Request Authentication Response Security Mode Command Security Mode Complete ESM Information Request ESM Information Response RRC Connection Release Attach Reject ← eNB Aに接続できないので、新たに 見つけたeNB Bへ接続 ←APN:mopera.net へ接続を試みる ← SIMが許可されてないAPNのため拒否される。 EMM Cause:No suitable cells in Tracking Area(#15) が受け取るため、端末はその基地局（eNB B)に一定 時間接続できなくなる。 LTE基地局探索するも接続可能なものが見つか らないので、3Gへフォールバック。次へ続く
- 43. 43 MNO(NTTドコモ,3G) SGSN HLR端末 NodeB RNC EIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Attach Request Authentication Data Request Authentication Data Response Authentication and Ciphering Request Authentication and Ciphering Response Security Mode Command Security Mode Complete Utran Mobility Information Utran Mobility Information Confirm Attach Accept Attach Complete GMM Information RRC Connection Release RRC Connection Release Complete IMEI Check Request IMEI Check Response Update Location Request Update Location Ack Insert Subscriber Data Insert Subscriber Data Ack ← #15で3Gにフォールバックした際は、 無線接続能力を通知するときに UTRAN(3G)/EUTRAN(LTE)の両方の 能力を通知。 この点が事例１と異なる IIJ P-GWS-GW LTE Activate PDP Context Request ←APN:mopera.net へ接続を試みる attach後に連続してデータ接続要求を出したが、 網側から切られてしまう Nexus6/5.1.0の場合の接続シーケンス - 3
- 44. 44 MNO(NTTドコモ,3G) LTE SGSN HLR端末 NodeB RNC EIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Service Request Security Mode Command Security Mode Complete Utran Mobility Information Utran Mobility Information Confirm Activate PDP Context Reject RRC Connection Release RRC Connection Release Complete Activate PDP Context Request ← このページ全体のシーケンスとほぼ同じよう な手順で繰り返しつつ、データ接続要求を 下記のAPN順で繰り返す APN: bmobile.ne.jp, user:bmobile@fr APN: bmobile.ne.jp, user:bmobile@u300 APN: bmobile.ne.jp, user:bmobile@spd APN: bmobile.ne.jp, user:bmobile@cm IIJ P-GWS-GW Nexus6/5.1.0の場合の接続シーケンス - 4 RRC Connection Request RRC Connection Rejct ← EUTRANにredirection可能と通知して3Gに接続要求 ← Rejectの中にeNB A側へ接続しろとredirection指示が来る LTEのeNB Aは接続禁止のため、他の基地局を探索… 接続可能なLTE基地局がないため、3Gにフォールバック
- 45. 45 Physical Channel Reconfiguration Measurement Control Radio Bearer Setup LTE MNO(NTTドコモ,3G) LTE SGSN HLR端末 NodeB RNC IIJ P-GWEIR RRC Connection Request RRC Connection Setup RRC Connection Setup Complete Service Request Security Mode Command Security Mode Complete Utran Mobility Information Utran Mobility Information Confirm Activate PDP Context Accept Activate PDP Context Request ここまでは事例１の3Gの挙動とほぼ一緒 次へ続く P-TMSI Reallocation Command P-TMSI Reallocation Complete Radio Bearer Setup Complete Create Session Request Create Session Response S-GW ↑ APN:iijmio.jpに接続 EPC capabilityがあるので S-GW経由でデータ接続を確立 Nexus6/5.1.0の場合の接続シーケンス - 5 ← UTRAN/EUTRANの両方の無線能力を通知 この点が事例１と異なる eNB A
- 46. 46 Measurement Report LTE MNO(NTTドコモ,3G) LTE SGSN HLR端末 NodeB RNC IIJ P-GWEIR Measurement Control Measurement Report S-GW Nexus6/5.1.0の場合の接続シーケンス - 6 Handover From UTRAN Command - EUTRAN eNB A RRC Connection Reconfiguration RRC Connection Reconfiguration Complete ところが…。LTEのeNB Aは接続禁止であることを検出して、端末 から強制切断。 電波のサーチをしつつ、シーケンス–5 に戻って同じ繰り返しとなり、 接続できない状態が延々続く ← EUTRANの能力があるため、基地局がLTEへの ハンドオーバーのための、確認を端末へ要求。 端末がハンドオーバー先となるLTE基地局の電波 状況を報告。 基地局がLTEへハンドオーバーを指示。
- 47. 47 4. まとめ
- 48. 48 まとめ • MVNOの視点 • SIMフリー端末の接続問題の調査は簡単ではない • 無線区間でやりとりされる制御信号解析はトラブルシュー ティングには非常に有用 • 制御信号解析できないとMVNOは何も出来ない • ユーザの視点 接続問題を緩和するために、現状は • APN設定は利用するもの以外は全部削除する • APNプロトコルは IPv4 を利用 を推奨（全てが解決するわけではない！） • 今後について QualcommなAndroid端末以外での解析できるような環境の整 備を検討中
- 49. 49 SIMフリー端末メーカー様へのお願い • IIJはユーザの端末選択の選択肢が増えるように、SIM フリー端末の普及、促進を推進していきます • 一方で、モバイルキャリアとのIOT行っていない端末で の接続不具合はユーザの利便性を損ない、SIMフリー 端末の普及を妨げる要因になってしまいます • IOTを通してない場合でも、メーカー様が作られた端末 をIIJに持ち込んで頂いて、共同でテスト実施させて頂 ける機会を頂けないかと考えています • ご協力、よろしくお願いいたします
- 50. 50 おまけ
- 51. 51 制御メッセージを見てみよう！ • このツールインストール • http://3gppdecoder.free.fr/?q=node/1 • Wireshark入れるの忘れずに！ • メッセージの種類を選択＋HEXデータをコピペすると見れる • Nexus6(5.1)の初期シーケンスデータ
- 52. 52 (再掲) LTE端末の初期の接続シーケンス例 - 1 MME HSS端末 RRC Connection Request eNB S-GW IIJ P-GW RRC Connection Setup RRC Connection Setup Complete Attach Request Identity Request Identity Response Authentication Information Request Authentication Information Response Authentication Request Authentication Response Security Mode Command Security Mode Complete ESM Information Request ESM Information Response EIR Identity Check Request Identity Check Ack Update Location Request Update Location Answer Create Session Request Create Session Request MNO(NTTドコモ) ← モバイルネットワークへの 接続要求 ← IMSI or IMEI要求 ← SIM認証 ← ユーザ認証ベクトル生成 ← 端末とMME間の暗号化,IMEI要求 ← IMEIチェック ← 接続情報を通知:APN,PDP Type, PCO(user/pass,DNS要求) ← 位置情報更新/ユーザのサービス に利用する各種情報の取得 ← 下りデータ通信トンネルの 作成。MVNOのユーザ認証
- 53. 53 MNO(NTTドコモ) (再掲) LTE端末の初期の接続シーケンス例 - 2 MME HSS端末 eNB S-GW IIJ P-GWEIR UE Capability Enquiry UE Capability Response Security Mode Command Security Mode Complete Create Session Response RRC Connection Reconfiguration(Attach Accept) RRC Connection Reconfiguration Complete Attach Complete Initial Context Setup Request(Attach Accept) Initial Context Setup Response Modify Bearer Response Modify Bearer Request Modify Bearer Request Modify Bearer Response UE Capability Info Indication ← 上りデータ通信トンネル作成 IPアドレス, DNSアドレス返信 ← 端末の無線(3G/LTE)能力の取得 Create Session Response ← 端末とeNB間の暗号化 ← 上りデータ通信トンネル作成 ← データ通信トンネル作成 IPアドレス, DNSアドレス返信
- 54. 54 制御メッセージを見てみよう！ • RRC Connection Request (LTE -> LTE-RRC.UL.CCCH) 512FAA783606 • RRC Connection Setup (LTE -> LTE-RRC.DL.CCCH) 60129808FCCE018390BA002CAACB52CD86149B38060F4F194342D07A • RRC Connection Setup (LTE -> LTE-RRC.UL.DCCH) 203000EC942C0741710BF644F00100EC94EE00D07104F070C0400005020 8D011D1191DCE755C0A003103E5E0345D0103E1C161 • Identity Request (LTE -> NAS-EPS_plain) (略) • Identity Response (LTE -> NAS-EPS_plain) (略) • Authentication Request (LTE -> NAS-EPS_plain) 0752011BB3E53C4D980680023CA7B34D980680107626E6CBA489800296 ACCAE3741380E8B05F • Authentication Response (LTE -> NAS-EPS_plain) 0753100A6535FD74929176156FCEC6A3662FDFE4BC
- 55. 55 制御メッセージを見てみよう！ • Security Mode Command (LTE -> NAS-EPS_plain) 075D220105F070C04070C1AB2F • Security Mode Complete (LTE -> NAS-EPS_plain) 075E23093355740006999999F9000000000000BC7E • ESM Information Request (LTE -> NAS-EPS_plain) 0208D906A0 • ESM Information Response (LTE -> NAS-EPS_plain) 0208DA280A0669696A6D696F026A70275E80C2231C0100001C10B83848 48B8384848B8384848B83848486D696F4069696AC2231C0200001C10191 04AB5D27FBDDF70B2F4DD7ADFC1C66D696F4069696A80211001000010 810600000000830600000000000D00000A000005000010000000000000005 F83
- 56. 56 制御メッセージを見てみよう！ • UE Capability Enquiry (LTE -> LTE-RRC.DL.DCCH) 380404 • UE Capability Information (LTE -> LTE-RRC.UL.DCCH) 3802080B2C998009001282410307104CD8993FF97FFF27D72FFFE4FFE5F FFC9FFCBFFF937F97FFF27FF2FFFE4DFE5FFFC9FFCBFFF93FF97FFF2 7FF2FFFDFF3FFA7A20E008C853A208329D2A4A91C5FB00000001C07FC FFE9EC0000000709FF3FFA7B00000000EA0C1C200040470800E10002022 0400710001010820038E00080841001C9FFCBFFF93FF97FFF27FF2FFFE4 FFE5FFF800200005C40004000020002000003FD00000003F40000000FD00 000003F40000000180857FFFFFA8CAAB541A955AA22920C11200060005 4384271CFBDE899EBB65CA138E7DEF44CF5DB2F509C73EF7A267AED9 7684E39F7BD133D76CB73D033FD410B438F5E7A1A3B7A267AED97142 D0E3D79E868EDE899EBB65ED0B438F5E7A1A3B7A267AED96C20C7BC A0C7BEA0C7BDA0C7BDEA53000016925AD2200D9832042891A3C8A54E DE8D8
- 57. 57 制御メッセージを見てみよう！ • Security Mode Command (LTE -> LTE-RRC.DL.DCCH) 300220 • Security Mode Complete (LTE -> LTE-RRC.UL.DCCH) 2800 • RRC Connection Reconfiguration (LTE -> LTE-RRC.DL.DCCH) 201615A80010008A42F10C0CC06609900C8066099C1421AA89886019004380E8C8401280942024C9EEC24640854B41956F B650D07225E57BC2EE2FDAAFEE717B05587F50A5F0BB51849F9075C494CBB2CD6DB74D6B169636E23AEE582BFBDD73 B34888D98B1A98FC5277557A46361BFE5F8DBE04A59A0E30D0648CE23634A641B85C3B65BBAF77945391A98D1044905 C53146AD346B8605D3801C94FB7089F922F0D8AFB59E2BBF6827C8C66CD48F19107812B3430109FC3B3409A9C08FCCE 0193901F523781F56C0C0DC4E296975CE20898600980C150 • 上のメッセージに含まれているが、暗号化されている部分 • Attach Accept/ Activate Default Bearer Context Request (LTE -> NAS-EPS_plain) 07420149064044F0011410006A5223C101091D0669696A6D696F026A70066D6E63303130066D636334343004677072 7305010AC494A45D0100301022931F9396FEFE8648FFFF00FA00FA005E06FEFEDDDD1010272280000D04CAE8020 2000D04CAE80203802110030000108106CAE802028306CAE80203500BF644F001BC1403E166F1E35302172C59496 40108DDB8 • RRC Connection Reconfiguration Complete (LTE -> LTE-RRC.UL.DCCH) 1000 • Attach Complete (LTE -> NAS-EPS_plain) 074300035200C2000000000000E513