GPRS Fundamental

IIJmio mtg #7
MVNOとSIMフリー端末について
株式会社インターネットイニシアティブ
大内宗徳
1
はじめに
• ユーザの利用する端末が(キャリア白ROM端末)から
(SIMフリー端末)へ急激に移行
高性能、低価格な端末の選択肢が増えて来たため。
• IIJもSIMフリー端末の種類が増え、ユーザの選択肢が
広がることは大歓迎！
• しかし、SIMフリー端末の普及で、接続問題が多く報告
されるようになってきた。
• IIJ側で遭遇した接続問題とその解析結果を共有しま
す
2
1. 接続問題の背景について
3
技適と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フリー端末はこの制度で利用可能になっているが。。。
4
技適とMNOの相互接続テスト（IOT)について – ２
• モバイルキャリアは接続テスト(IOT)の実施を推奨
• 相互接続ガイドブック | 企業情報 | NTTドコモ
https://www.nttdocomo.co.jp/corporate/disclosure/interconnection/guide/
-> 第2章相互接続開始までの手順
-> 他事業者様が自ら移動無線装置を調達し接続される場合に必要となる事項、を抜粋
当社では、接続約款の中で混信等防止の規定を定めており、混信等が他事業者様が
自ら調達された移動無線装置に起因する場合は、発信停止等の対応を行うことになり
ます。このような事態を未然に防ぐため、移動無線装置に係る確認試験により、事前
に当社ネットワークと正常な接続確認を行うことをおすすめします。
• IOTは非常に重要
• 接続時にやりとりされるパラメータや接続手順で、MNO側の設備との
接続に問題ないか確認しないと、接続が不安定になる要因に
• 最初に端末を出す前やファームのバージョンアップの前には必須
• 一方、IOTはそれなりのコストがかかるため、SIMフリー端末の場合、
実施されない場合が多いが、これがトラブルにつながることに…
5
MVNOで端末に起因する問題が発生した場合
• MNOのIOTを通してない端末で問題が発生した場合
はMVNOの責任で頑張らないといけない
• しかし、MNOと端末でやりとりされる制御情報は、 IIJにほ
とんど分からない
=> 問題の切り分けがほとんど出来ないことに…
MNO
IIJ ・インターネット
(NTTドコモ)
・
• 具体的なシーケンスを例にこの問題を説明
6
LTE端末の初期の接続シーケンス例 - 1
MNO(NTTドコモ) IIJ
端末 eNB MME S-GW HSS EIR P-GW
RRC Connection Request
RRC Connection Setup ← モバイルネットワークへの

RRC Connection Setup Complete Attach Request 接続要求
Identity Request
← IMSI or IMEI要求
Identity Response
Authentication Information Request
Authentication Information Response

← ユーザ認証ベクトル生成
Authentication Request
Authentication Response
← SIM認証
Security Mode Command ← 端末とMME間の暗号化,IMEI要求
Security Mode Complete
Identity Check Request
← IMEIチェック
Identity Check Ack
ESM Information Request ← 接続情報を通知:APN,PDP Type,

ESM Information Response PCO(user/pass,DNS要求)
Update Location Request
← 位置情報更新/ユーザのサービス
Update Location Answer
に利用する各種情報の取得
Create Session Request

← 下りデータ通信トンネルの
作成。MVNOのユーザ認証
7
LTE端末の初期の接続シーケンス例 - 2
Create Session Response

← 上りデータ通信トンネル作成
Initial Context Setup Request(Attach Accept)
IPアドレス, DNSアドレス返信
UE Capability Enquiry
← 端末の無線(3G/LTE)能力の取得
UE Capability Response
UE Capability Info Indication
Security Mode Command

← 端末とeNB間の暗号化
RRC Connection Reconfiguration(Attach Accept) ← データ通信トンネル作成

RRC Connection Reconfiguration Complete IPアドレス, DNSアドレス返信
Initial Context Setup Response
Attach Complete
Modify Bearer Request ← 上りデータ通信トンネル作成
Modify Bearer Request
Modify Bearer Response

接続シーケンス中で赤の部分しか、IIJは分からない
これだけの情報で端末側の問題の調査はほぼ不可能
8
端末の接続問題の調査のために
• MVNOのネットワーク設備(P-GW/GGSN)だけでは、問
題の調査は不可能
• モバイルキャリアのネットワークを直接調べることは出来な
いため
• MVNOにできることは？
• 端末<->基地局間の無線区間でやりとりされ制御情報を何
らかの方法で調べることぐらい
• この具体的な調査方法について解説
MNO
IIJ
(NTTドコモ)
9
2. 無線区間の制御情報の調査手法に
ついて
10
無線区間の制御信号を調べる調査手法
• MVNOで可能な下記の３種類を検討
1. 端末内のBasebandチップから制御情報を抜く
2. 無線区間で直接、制御情報を抜く
3. 基地局側(シミュレータ)で制御情報を抜く
MNO
方法１ (NTTドコモ)
方法2
方法3
11
1. 端末内のBasebandチップから制御情報を抜く
• Basebandチップとは？
• デジタル信号と無線信号の相互変換、モバイルネットワークとの接続制
御を行っている
• 原理的には制御情報をここから抜くことが可能
• 利点: Qualcommチップであれば比較的容易に可能。製品も存在する
暗号化前/復号化後の基地局との制御情報を取得可能
‘’後述の方法’’に比べると安価
• 欠点: 市販の端末から制御情報を抜くことは敷居が高い
Qualcommチップ以外だと制御情報を抜くのが困難
モバイル制御部分制御情報
Baseband
RF
Processor IPパケット
(Qualcommなど)
(製品例)
Application Meritech社 Sigma-ML/LA/PA
制御情報 Processor Accuver社 XCAP/XCAL
SwissQual社 QualiPoc
アプリケーションOS(Android/iOS)
12
2. 無線区間で直接、制御情報を抜く
• 利点: 端末や基地局に手を加えなくて済む
Basebandチップの種類を問わない
• 欠点: 調査対象の端末の電波だけを捕まえるのが困難
制御情報は暗号化されているので復号化するために工
夫がいる(暗号化キー入手のため、BasebandチップとSIM
間の情報を抜く必用がある)
非常に高価
MNO
(NTTドコモ)
(製品例)
ABIT社エアプロトコルモニター
13
3. 基地局側(シミュレータ)で制御情報を抜く
• 基地局シミュレータとは？
• 本来は端末開発時の動作確認用
• 基地局を含むモバイルネットワーク動作をシミュレート可能
• 利点: 端末に手を加えなくて済む
暗号化前/復号化後の基地局との制御情報を取得可能
Basebandチップの種類を問わない
• 欠点: キャリアのネットワーク動作を完全にシミレーションさせ
るには、ノウハウが必要
実際の問題を再現させられるとは限らない
非常に高価
(製品例)
MNO アンリツ社
シグナリングテスタ
(NTTドコモ)
基地局シミュレータ
14
今回採用した無線区間の制御信号を調べる方法
• 端末内のQualcommなBasebandチップから制御情報を
抜く方法を採用した
• Meritech社の Sigma-ML/LA/PA を利用した
• 制御情報としては、’L3プロトコル’ を解析した
15
Meritech社 Sigma-ML/LA
• 通信品質測定ソフト
• Baseband情報をリアルタイムで確認可能
• Android向けアプリ: Sigma-ML (下図参照)
• PC接続のUSBモデム向け: Sigma-LA
16
Meritech社 Sigma-PA
• Sigma-ML/LAで取得したデータを事後解析するソフト
17
3. 実際の問題での制御情報解析について
18
事例1: LollipopでAPNサーチを頻繁に繰り返す問題
• 事象
• Lollipop(Android 5.0)から端末初期設定時に行われるだけ
だったAPNサーチが、なぜか、電源on, 機内モード解除等を
契機(?)に再度行われて、接続に問題が生じる
• 動作
Nexus5/Nexus6: 接続に時間がかかり、3G接続しか出来なくなる
Nexus7(2013): 接続が不安定になる？
• 対策
• APN設定を現在契約しているMVNO以外は全て削除
• 3Gにしか接続出来なくなった場合は、一度機内モードにして
解除する
• 原因
• Android側の問題？
• 詳細は次のページからで説明
19
Nexus5/5.1の場合の接続シーケンス - 1
MNO(NTTドコモ,LTE) IIJ
RRC Connection Setup
RRC Connection Setup Complete Attach Request
Identity Request
Identity Response


Identity Check Ack

ESM Information Request
←APN:mopera.net へ接続を試みる
ESM Information Response

Attach Reject
← SIMが許可されてないAPNの
RRC Connection Release ため拒否される
同じシーケンスをあと 2 回繰り返すが、APN:mopera.net から、次の

APN検索に進まず、3Gにフォールバック。次のページに続く
20
NodeB MNO(NTTドコモ,3G) LTE IIJ
端末 RNC SGSN HLR EIR S-GW P-GW
RRC Connection Setup Complete ← APN接続/ユーザ認証失敗で、LTE接続

Attach Request
Authentication Data Request
できずに、3Gにフォールバックした場合で
Authentication Data Response
ここで端末が無線接続能力を通知すると
Authentication and Ciphering Request きに3G(UTRAN)だけの能力を通知
Authentication and Ciphering Response
IMEI Check Request
IMEI Check Response
Insert Subscriber Data
Insert Subscriber Data Ack
Update Location Ack

Utran Mobility Information
Utran Mobility Information Confirm
Attach Accept
Attach Complete
モバイル網のPS Attachのみ。
GMM Information
次のページに続く
RRC Connection Release
RRC Connection Release Complete
21
RRC Connection Setup Complete
Service Request

Activate PDP Context Request ← この接続拒否のシーケンスを下記のAPN順

で繰り返す
Utran Mobility Information APN: bmobile.ne.jp, user:bmobile@fr
Utran Mobility Information Confirm APN: bmobile.ne.jp, user:bmobile@u300
APN: bmobile.ne.jp, user:bmobile@spd
Activate PDP Context Reject
APN: bmobile.ne.jp, user:bmobile@cm
22
Nexus5/5.1の場合の接続シーケンス – 4
Service Request

← APN:iijmio.jp, pdp-type=ipv4ipv6 で接続を要求
Activate PDP Context Request
Utran Mobility Information ↑ EPC capabilityがあるため、
S-GW経由でデータ接続を確立
P-TMSI Reallocation Command
P-TMSI Reallocation Complete
Radio Bearer Setup
Radio Bearer Setup Complete

pdp-type=ipv4ipv6 で接続完了。ただし端末からは、
Measurement Control
無線は3G接続だけの能力(UTRAN)しかないと通知し、
Activate PDP Context Accept
LTE能力を無効化しているため、LTE側に遷移しない
Transport Channel Reconfiguration
Transport Channel Reconfiguration Complete

一度機内モードにして再接続すると、覚えたAPNへ
Signaling Connection Release Indication
接続に行き、無線のLTE接続能力を広報するように

なるので、LTEに接続可能に
23
事例2:APNプロトコル:IPv4/IPv6で接続できなくなる問題
• 事象
• 一部の端末が3Gで接続する際にAPNプロトコル: IPv4/IPv6
が選択されていると接続できなくなる
• 動作
Nexus7(2013): 3G接続に落ちた場合で接続できなくなる
Nexus5/Nexus6: 問題発生せず
• 対策
• APNプロトコル:IPv4/IPv6 を選択しない
• 5.1で、APN: IIJmio(3G端末) があれば、これ利用するようにして、これ以
外のAPN設定を全て削除。接続できない場合は一度機内モードにして
解除
• 原因
• キャリア側の問題？
24
3.5. LTE端末のEPC Capabilityと EUTRAN
Capabilityの関係について
25
LTE端末のEPC CapabilityとEUTRAN Capabilityの関係 - 1
• EPC Capability:○/EUTRAN Capability:○の場合

• 3G/LTE無線両方に接続可能
• LTE網を経由のハンドオーバが可能 -> IPv6利用可能
3G IIJ GGSN IPv6不可

NTTドコモ
EPC Capability:○ の場合

横つなぎが利用される
LTE
IIJ P-GW IPv6可能
EUTRAN Capability: NTTドコモ
○の場合
LTE基地局に接続可能
26
• EPC Capability:○/EUTRAN Capability:×の場合

• 端末が無線LTE能力を無効化 -> 3G基地局経由での接続
• コアネットワークはLTEを経由 -> IPv6利用可能

NTTドコモ
EPC Capability:○ の場合

横つなぎが利用される
LTE
IIJ P-GW IPv6可能
NTTドコモ
27
• EPC Capability:×/EUTRAN Capability:×の場合

• 端末が無線LTE能力を無効化 -> 3G基地局経由での接続
• コアネットワークは3Gを経由 -> IPv6利用不可

NTTドコモ
NTTドコモではここのIPv6利用
はサポートしてない
LTE
IIJ P-GW IPv6可能
NTTドコモ
28
Nexus7(2013)/5.0.xで3Gの場合の接続シーケンス - 1
NodeB MNO(NTTドコモ,3G) LTE IIJ IIJ
端末 RNC SGSN HLR EIR S-GW P-GW GGSN
RRC Connection Setup Complete ← 3Gモードにしているため、ここで端末が

Attach Request
無線の3G(UTRAN)/LTE(EUTRAN)能力を
通知するときにUTRANだけの能力を通知
Authentication and Ciphering Request
IMEI Check Request
IMEI Check Response

ここで端末のLTEコア接続能力
(EPC capability)を通知しない
Update Location Ack 3GPPの仕様では3Gに接続する

Security Mode Command 場合ででも、EPC capabilityを
通知する必要があるのだが…
Attach Accept
Attach Complete
モバイル網のPS Attachのみ。
GMM Information
次のページに続く
29
NodeB MNO(NTTドコモ,3G) LTE IIJ IIJ
端末 RNC SGSN HLR EIR S-GW P-GW GGSN
pdp-type=ipv4ipv6の接続を要求
RRC Connection Setup Complete EPC capabilityがないため、 SGSN->GGSNに直接着信

Service Request ドコモ網はSGSN<->GGSN接続ではpdp-type=ipv4ipv6
Security Mode Command をサポートしてない
SGSNがpdp-type=ipv4に変換して接続要求を送信
Create PDP Context Request
Create PDP Context Response
Radio Bearer Setup
Measurement Control

← 端末には、 pdp-type=ipv4として要求を受け
Transport Channel Reconfiguration
付けた旨が通知され、アドレスが返る
Transport Channel Reconfiguration Complete
Activate PDP Context Request ← 端末はpdp-type=ipv4ipv6の要求が通らなかった

Radio Bearer Release ので、IPv6用にpdp-type=ipv6で追加で接続を要求
Radio Bearer Release Complete
Measurement Control
Activate PDP Context Reject ← 3Gドコモ網はpdp-type=ipv6を受け付けないため、

RRC Connection Release 接続が拒否され、接続を切断されてしまう
30
Service Request


← pdp-type=ipv6の要求が通らなかったので、
Service Request
再度接続を要求
Activate PDP Context Reject ← 3Gドコモ網はpdp-type=ipv6を受け付けないため、
RRC Connection Release 接続が拒否され、接続が切断されてしまう
RRC Connection Request ← 一定時間後、pdp-type=ipv4の接続をデータ通信

RRC Connection Setup に利用しようとするが、その接続はありませんと
RRC Connection Setup Complete 網側から拒否されて切断される
Service Request
Service Reject pdp-type=ipv4の接続がなくなってしまったので、

RRC Connection Release 最初の接続要求pdp-type=ipv4ipv6に戻り、同様
RRC Connection Release Complete のことを繰り返し、不安定な状態が延々と続く
31
事例3:Nexus7(2013)で変なデータ接続をしようとする問題
• 事象
• LTEでデータ接続を確立した状態で、追加でデータ接続を要
求して、接続が不安定になっている？
• 再現させにくい問題のため、ユーザ影響が不明
• 動作
• Nexus7(2013): 5.0.1で発生を確認
• その他は発生せず
• 対策
• 打つ手なし
• 原因
• Basebandファームの問題？？
32
Nexus7/5.0.1の場合の接続シーケンス - 1
Identity Request
Identity Response

←APN:mopera.net, user: mio@iij, pass: iij
で接続を試みる。user/passがおかしい…
Attach Reject ← SIMが許可されてないAPNの
次へ続く
33

←APN:mopera.net, user: mio@iij, pass: iij
で再び接続を試みる。user/passがおかしい…
← SIMが許可されてないAPNの
Attach Reject
次へ続く
34
Nexus7/5.0.1の場合の接続シーケンス – 3

←APN:iijmio.jp, user: mio@iij, pass: iij
で再び接続を試みる -> OK
次へ続く
35
RRC Reconfiguration(Attach Accept)
RRC Reconfiguration Complete
Attach Complete

EMM Information
ここまでは通常のシーケンスなのだが…
次へ続く
36
PDN Connectivity Request ←APN:dmjplat.net, user: mobile@rakutenbb.jp 追加の
PDN Connectivity Reject データ接続を要求するが許可されてないAPNのため拒
否される
PDN Connectivity Request
RRC Connection Reconfiguration ←APN:bmobile.ne.jp, user: bmobile@am で同様

RRC Connection Reconfiguration Complete
PDN Connectivity Reject

←APN:bmobile.ne.jp, user: bmobile@aeon で同様
Identity Request
RRC Connection Reconfiguration
PDN Connectivity Request ←APN:bmobile.ne.jp, user: bmobile@zsim で同様

PDN Connectivity Request ←APN:bmobile.ne.jp, user: bmobile@fr で同様


次へ続く
37
←APN:bmobile.ne.jp, user: bmobile@u300 で同様

←一旦切断されて再接続を試みる
Service Request

←APN:bmobile.ne.jp, user: bmobile@spd で同様
次へ続く
38
←APN:bmobile.ne.jp, user: bmobile@cm で同様
RRC Connection Release ← ココで一旦終了。切断された後電波サーチ…
39
事例4: 認証失敗時にEMM Cause #15が返ってくる問題
• 事象
• 事例1の事象に似ているのだが、3Gで接続後、3G->LTEの
ハンドオーバに必ず失敗して、接続ができない状態に陥る
• 2015年になってから問題が発生して３月下旬に収束
• 動作
• LTE端末(Androidに限らない)で広範囲に発生
• 対策
• 事例１と同様
• 現状は問題が発生しない状況になっている
• 原因
• 原因は不明。キャリア設備の問題だった？？
40
端末 eNB A eNB B MME S-GW HSS EIR P-GW

Attach Request
Identity Request
Identity Response

Attach Reject
← SIMが許可されてないAPNのため拒否される。通常、
EMM Cause:ESM failure,
ESM Cause:User authentication failed
が返って来るが、
この場合は何故か
接続可能なLTE基地局探索… EMM Cause:No suitable cells in Tracking Area(#15)
次へ続くが返ってきた。
#15 を受け取ると端末はその基地局（eNB A)に一定
時間接続できなくなる。
41
端末 eNB A eNB B MME S-GW HSS EIR P-GW
RRC Connection Request ← eNB Aに接続できないので、新たに
RRC Connection Setup 見つけたeNB Bへ接続

Attach Reject
RRC Connection Release ← SIMが許可されてないAPNのため拒否される。
EMM Cause:No suitable cells in Tracking Area(#15)
が受け取るため、端末はその基地局（eNB B)に一定
時間接続できなくなる。
LTE基地局探索するも接続可能なものが見つか
らないので、3Gへフォールバック。次へ続く
42

← #15で3Gにフォールバックした際は、
Attach Request
無線接続能力を通知するときに

UTRAN(3G)/EUTRAN(LTE)の両方の
Authentication and Ciphering Request 能力を通知。
IMEI Check Request
IMEI Check Response この点が事例１と異なる

Update Location Ack

Attach Accept
Attach Complete
GMM Information
Activate PDP Context Request ←APN:mopera.net へ接続を試みる

RRC Connection Release attach後に連続してデータ接続要求を出したが、
RRC Connection Release Complete 網側から切られてしまう
43

← EUTRANにredirection可能と通知して3Gに接続要求
RRC Connection Rejct
← Rejectの中にeNB A側へ接続しろとredirection指示が来る
LTEのeNB Aは接続禁止のため、他の基地局を探索…
接続可能なLTE基地局がないため、3Gにフォールバック
Service Request

← このページ全体のシーケンスとほぼ同じよう
な手順で繰り返しつつ、データ接続要求を
下記のAPN順で繰り返す
APN: bmobile.ne.jp, user:bmobile@fr
APN: bmobile.ne.jp, user:bmobile@u300
Activate PDP Context Reject APN: bmobile.ne.jp, user:bmobile@spd
APN: bmobile.ne.jp, user:bmobile@cm
44
LTE NodeB MNO(NTTドコモ,3G) LTE IIJ
端末 eNB A RNC SGSN HLR EIR S-GW P-GW

← UTRAN/EUTRANの両方の無線能力を通知
Service Request
この点が事例１と異なる

↑ APN:iijmio.jpに接続
EPC capabilityがあるので
S-GW経由でデータ接続を確立
P-TMSI Reallocation Command
P-TMSI Reallocation Complete
Radio Bearer Setup
Measurement Control
Physical Channel Reconfiguration

ここまでは事例１の3Gの挙動とほぼ一緒
次へ続く
45
LTE NodeB MNO(NTTドコモ,3G) LTE IIJ
端末 eNB A RNC SGSN HLR EIR S-GW P-GW
Measurement Control
Measurement Report
← EUTRANの能力があるため、基地局がLTEへの
ハンドオーバーのための、確認を端末へ要求。
Measurement Report
端末がハンドオーバー先となるLTE基地局の電波
Handover From UTRAN Command - EUTRAN 状況を報告。
基地局がLTEへハンドオーバーを指示。
ところが…。LTEのeNB Aは接続禁止であることを検出して、端末
から強制切断。
電波のサーチをしつつ、シーケンス–5 に戻って同じ繰り返しとなり、
接続できない状態が延々続く
46
4. まとめ
47
まとめ
• MVNOの視点
• SIMフリー端末の接続問題の調査は簡単ではない
• 無線区間でやりとりされる制御信号解析はトラブルシュー
ティングには非常に有用
• 制御信号解析できないとMVNOは何も出来ない
• ユーザの視点
接続問題を緩和するために、現状は
• APN設定は利用するもの以外は全部削除する
• APNプロトコルは IPv4 を利用
を推奨（全てが解決するわけではない！）
• 今後について
QualcommなAndroid端末以外での解析できるような環境の整
備を検討中
48
SIMフリー端末メーカー様へのお願い
• IIJはユーザの端末選択の選択肢が増えるように、SIM
フリー端末の普及、促進を推進していきます
• 一方で、モバイルキャリアとのIOT行っていない端末で
の接続不具合はユーザの利便性を損ない、SIMフリー
端末の普及を妨げる要因になってしまいます
• IOTを通してない場合でも、メーカー様が作られた端末
をIIJに持ち込んで頂いて、共同でテスト実施させて頂
ける機会を頂けないかと考えています
• ご協力、よろしくお願いいたします
49
おまけ
50
制御メッセージを見てみよう！
• このツールインストール
• http://3gppdecoder.free.fr/?q=node/1
• Wireshark入れるの忘れずに！
• メッセージの種類を選択＋HEXデータをコピペすると見れる
• Nexus6(5.1)の初期シーケンスデータ
51
(再掲) LTE端末の初期の接続シーケンス例 - 1
RRC Connection Setup ← モバイルネットワークへの

RRC Connection Setup Complete Attach Request 接続要求
Identity Request
← IMSI or IMEI要求
Identity Response

← ユーザ認証ベクトル生成
← SIM認証
Security Mode Command ← 端末とMME間の暗号化,IMEI要求
← IMEIチェック
Identity Check Ack
ESM Information Request ← 接続情報を通知:APN,PDP Type,

ESM Information Response PCO(user/pass,DNS要求)
← 位置情報更新/ユーザのサービス
に利用する各種情報の取得

← 下りデータ通信トンネルの
作成。MVNOのユーザ認証
52
(再掲) LTE端末の初期の接続シーケンス例 - 2

← 上りデータ通信トンネル作成
IPアドレス, DNSアドレス返信
← 端末の無線(3G/LTE)能力の取得

← 端末とeNB間の暗号化
RRC Connection Reconfiguration(Attach Accept) ← データ通信トンネル作成

RRC Connection Reconfiguration Complete IPアドレス, DNSアドレス返信
Attach Complete
Modify Bearer Request ← 上りデータ通信トンネル作成

53
• 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
54
• 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
55
• 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
56
• 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
57

GPRS Fundamental

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GPRS Fundamental

Uploaded by

Copyright:

Available Formats

IIJmio mtg #7

RRC Connection Setup ← モバイルネットワークへの

Authentication Information Response

ESM Information Request ← 接続情報を通知:APN,PDP Type,

Create Session Request

Create Session Response

Security Mode Command

RRC Connection Reconfiguration(Attach Accept) ← データ通信トンネル作成

Modify Bearer Response

RRC Connection Setup

RRC Connection Setup Complete Attach Request

Authentication Information Response

Security Mode Command

Security Mode Complete

Identity Check Ack

Update Location Answer

同じシーケンスをあと 2 回繰り返すが、APN:mopera.net から、次の

RRC Connection Setup

RRC Connection Setup Complete ← APN接続/ユーザ認証失敗で、LTE接続

IMEI Check Response

Update Location Request

Insert Subscriber Data

Insert Subscriber Data Ack

Update Location Ack

Utran Mobility Information

Utran Mobility Information Confirm

RRC Connection Release Complete

RRC Connection Setup

RRC Connection Setup Complete

Security Mode Command

Activate PDP Context Request ← この接続拒否のシーケンスを下記のAPN順

RRC Connection Release Complete

RRC Connection Setup

RRC Connection Setup Complete

Security Mode Command

P-TMSI Reallocation Complete

Radio Bearer Setup

Radio Bearer Setup Complete

Transport Channel Reconfiguration Complete

RRC Connection Release Complete

• EPC Capability:○/EUTRAN Capability:○の場合

3G IIJ GGSN IPv6不可

EPC Capability:○ の場合

• EPC Capability:○/EUTRAN Capability:×の場合

3G IIJ GGSN IPv6不可

EPC Capability:○ の場合

• EPC Capability:×/EUTRAN Capability:×の場合

3G IIJ GGSN IPv6不可

RRC Connection Setup

RRC Connection Setup Complete ← 3Gモードにしているため、ここで端末が

IMEI Check Response

Update Location Request

Update Location Ack 3GPPの仕様では3Gに接続する

Utran Mobility Information Confirm

RRC Connection Release Complete

RRC Connection Setup Complete EPC capabilityがないため、 SGSN->GGSNに直接着信

Radio Bearer Setup Complete

Activate PDP Context Accept

Activate PDP Context Request ← 端末はpdp-type=ipv4ipv6の要求が通らなかった

Activate PDP Context Reject ← 3Gドコモ網はpdp-type=ipv6を受け付けないため、

RRC Connection Setup

RRC Connection Setup Complete

Security Mode Command