IIJmio meeting 7 MVNOとSIMフリー端末の問題について

1

株式会社インターネットイニシアティブ

大内宗徳

IIJmio mtg #7

MVNOとSIMフリー端末について

2

はじめに

• ユーザの利用する端末が(キャリア白ROM端末)から(SIMフリー端末)へ急激に移行高性能、低価格な端末の選択肢が増えて来たため。

• IIJもSIMフリー端末の種類が増え、ユーザの選択肢が広がることは大歓迎！

• しかし、SIMフリー端末の普及で、接続問題が多く報告されるようになってきた。

• IIJ側で遭遇した接続問題とその解析結果を共有します

3

1. 接続問題の背景について

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

技適とMNOの相互接続テスト（IOT)について – ２

• モバイルキャリアは接続テスト(IOT)の実施を推奨• 相互接続ガイドブック | 企業情報 | NTTドコモ

https://www.nttdocomo.co.jp/corporate/disclosure/interconnection/guide/

-> 第2章相互接続開始までの手順-> 他事業者様が自ら移動無線装置を調達し接続される場合に必要となる事項、を抜粋

当社では、接続約款の中で混信等防止の規定を定めており、混信等が他事業者様が自ら調達された移動無線装置に起因する場合は、発信停止等の対応を行うことになります。このような事態を未然に防ぐため、移動無線装置に係る確認試験により、事前に当社ネットワークと正常な接続確認を行うことをおすすめします。

• IOTは非常に重要• 接続時にやりとりされるパラメータや接続手順で、MNO側の設備との

接続に問題ないか確認しないと、接続が不安定になる要因に• 最初に端末を出す前やファームのバージョンアップの前には必須

• 一方、IOTはそれなりのコストがかかるため、SIMフリー端末の場合、実施されない場合が多いが、これがトラブルにつながることに…

https://www.nttdocomo.co.jp/corporate/disclosure/interconnection/guide/

6

MVNOで端末に起因する問題が発生した場合

• MNOのIOTを通してない端末で問題が発生した場合はMVNOの責任で頑張らないといけない• しかし、MNOと端末でやりとりされる制御情報は、 IIJにほ

とんど分からない=> 問題の切り分けがほとんど出来ないことに…

• 具体的なシーケンスを例にこの問題を説明

MNO(NTTドコモ)

IIJ インターネット・・

7

LTE端末の初期の接続シーケンス例 - 1

MME HSS端末

RRC Connection Request

eNB S-GWIIJ

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


MNO(NTTドコモ)

← モバイルネットワークへの接続要求

← IMSI or IMEI要求

← SIM認証

← ユーザ認証ベクトル生成

← 端末とMME間の暗号化,IMEI要求

← IMEIチェック

← 接続情報を通知:APN,PDP Type,PCO(user/pass,DNS要求)

← 位置情報更新/ユーザのサービスに利用する各種情報の取得

← 下りデータ通信トンネルの作成。MVNOのユーザ認証

8

MNO(NTTドコモ)

LTE端末の初期の接続シーケンス例 - 2

MME HSS端末 eNB S-GWIIJ

P-GWEIR

UE Capability Enquiry

UE Capability Response



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



UE Capability Info Indication

接続シーケンス中で赤の部分しか、IIJは分からないこれだけの情報で端末側の問題の調査はほぼ不可能

← 上りデータ通信トンネル作成IPアドレス, DNSアドレス返信

← 端末の無線(3G/LTE)能力の取得


← 端末とeNB間の暗号化

← 上りデータ通信トンネル作成

← データ通信トンネル作成IPアドレス, DNSアドレス返信

9

端末の接続問題の調査のために

• MVNOのネットワーク設備(P-GW/GGSN)だけでは、問題の調査は不可能• モバイルキャリアのネットワークを直接調べることは出来な

いため

• MVNOにできることは？• 端末<->基地局間の無線区間でやりとりされ制御情報を何

らかの方法で調べることぐらい

• この具体的な調査方法について解説

MNO(NTTドコモ)

IIJ

10

2. 無線区間の制御情報の調査手法について

11

無線区間の制御信号を調べる調査手法

• MVNOで可能な下記の３種類を検討1. 端末内のBasebandチップから制御情報を抜く2. 無線区間で直接、制御情報を抜く3. 基地局側(シミュレータ)で制御情報を抜く

MNO(NTTドコモ)方法１

方法2方法3

12

1. 端末内のBasebandチップから制御情報を抜く

• Basebandチップとは？• デジタル信号と無線信号の相互変換、モバイルネットワークとの接続制

御を行っている• 原理的には制御情報をここから抜くことが可能

• 利点: Qualcommチップであれば比較的容易に可能。製品も存在する暗号化前/復号化後の基地局との制御情報を取得可能‘’後述の方法’’に比べると安価

• 欠点: 市販の端末から制御情報を抜くことは敷居が高いQualcommチップ以外だと制御情報を抜くのが困難

Application Processor

モバイル制御部分

アプリケーションOS(Android/iOS)

制御情報

IPパケットRF

Baseband Processor

(Qualcommなど)

制御情報

(製品例)Meritech社 Sigma-ML/LA/PAAccuver社 XCAP/XCALSwissQual社 QualiPoc

13

2. 無線区間で直接、制御情報を抜く

• 利点: 端末や基地局に手を加えなくて済むBasebandチップの種類を問わない

• 欠点: 調査対象の端末の電波だけを捕まえるのが困難制御情報は暗号化されているので復号化するために工夫がいる(暗号化キー入手のため、BasebandチップとSIM間の情報を抜く必用がある)非常に高価

MNO(NTTドコモ)

(製品例)ABIT社エアプロトコルモニター

14

3. 基地局側(シミュレータ)で制御情報を抜く

• 基地局シミュレータとは？• 本来は端末開発時の動作確認用• 基地局を含むモバイルネットワーク動作をシミュレート可能

• 利点: 端末に手を加えなくて済む暗号化前/復号化後の基地局との制御情報を取得可能Basebandチップの種類を問わない

• 欠点: キャリアのネットワーク動作を完全にシミレーションさせるには、ノウハウが必要実際の問題を再現させられるとは限らない非常に高価

MNO(NTTドコモ)

基地局シミュレータ

(製品例)アンリツ社シグナリングテスタ

15

今回採用した無線区間の制御信号を調べる方法

• 端末内のQualcommなBasebandチップから制御情報を抜く方法を採用した• Meritech社の Sigma-ML/LA/PA を利用した• 制御情報としては、’L3プロトコル’ を解析した

16

Meritech社 Sigma-ML/LA

• 通信品質測定ソフト• Baseband情報をリアルタイムで確認可能

• Android向けアプリ: Sigma-ML (下図参照)• PC接続のUSBモデム向け: Sigma-LA

17

Meritech社 Sigma-PA

• Sigma-ML/LAで取得したデータを事後解析するソフト

18

3. 実際の問題での制御情報解析について

19

• 事象• Lollipop(Android 5.0)から端末初期設定時に行われるだけ

だったAPNサーチが、なぜか、電源on, 機内モード解除等を契機(?)に再度行われて、接続に問題が生じる

• 動作Nexus5/Nexus6: 接続に時間がかかり、3G接続しか出来なくなるNexus7(2013): 接続が不安定になる？

• 対策• APN設定を現在契約しているMVNO以外は全て削除• 3Gにしか接続出来なくなった場合は、一度機内モードにして

解除する

• 原因• Android側の問題？

• 詳細は次のページからで説明

事例1: LollipopでAPNサーチを頻繁に繰り返す問題

20

Nexus5/5.1の場合の接続シーケンス - 1

MME HSS端末


eNB S-GWIIJ

P-GW



Identity Request

Identity ResponseAuthentication Information Request








EIR


Identity Check Ack



MNO(NTTドコモ,LTE)

←APN:mopera.net へ接続を試みる

RRC Connection Release

Attach Reject← SIMが許可されてないAPNの

ため拒否される

同じシーケンスをあと 2 回繰り返すが、APN:mopera.net から、次のAPN検索に進まず、3Gにフォールバック。次のページに続く

21

MNO(NTTドコモ,3G)


SGSN HLR端末NodeB

RNC EIR



RRC Connection Setup Complete

Attach RequestAuthentication Data Request

Authentication Data Response

Authentication and Ciphering Request

Authentication and Ciphering Response



Utran Mobility Information

Utran Mobility Information Confirm

Attach Accept

Attach Complete

GMM Information


RRC Connection Release Complete

IMEI Check Request

IMEI Check Response


Update Location Ack

Insert Subscriber Data

Insert Subscriber Data Ack

モバイル網のPS Attachのみ。次のページに続く

← APN接続/ユーザ認証失敗で、LTE接続できずに、3Gにフォールバックした場合でここで端末が無線接続能力を通知するときに3G(UTRAN)だけの能力を通知

IIJ

P-GWS-GWLTE

22

MNO(NTTドコモ,3G) LTE


SGSN HLR端末NodeB

RNC EIR




Service Request





Activate PDP Context Reject



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

APN: bmobile.ne.jp, user:bmobile@frAPN: bmobile.ne.jp, user:bmobile@u300APN: bmobile.ne.jp, user:bmobile@spdAPN: bmobile.ne.jp, user:bmobile@cm

IIJ

P-GWS-GW

23


Nexus5/5.1の場合の接続シーケンス – 4

SGSN HLR端末NodeB

RNC IIJ

P-GWEIR




Service Request





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



Measurement Control

Transport Channel Reconfiguration

Transport Channel Reconfiguration Complete

Signaling Connection Release Indication



S-GW

↑ EPC capabilityがあるため、S-GW経由でデータ接続を確立

← APN:iijmio.jp, pdp-type=ipv4ipv6 で接続を要求

24

• 事象• 一部の端末が3Gで接続する際にAPNプロトコル: IPv4/IPv6

が選択されていると接続できなくなる

• 動作Nexus7(2013): 3G接続に落ちた場合で接続できなくなるNexus5/Nexus6: 問題発生せず

• 対策• APNプロトコル:IPv4/IPv6 を選択しない• 5.1で、APN: IIJmio(3G端末) があれば、これ利用するようにして、これ以

外のAPN設定を全て削除。接続できない場合は一度機内モードにして解除

• 原因• キャリア側の問題？


事例2:APNプロトコル:IPv4/IPv6で接続できなくなる問題

25

3.5. LTE端末のEPC Capabilityと EUTRAN

Capabilityの関係について

26

LTE端末のEPC CapabilityとEUTRAN Capabilityの関係 - 1

• EPC Capability:○/EUTRAN Capability:○の場合• 3G/LTE無線両方に接続可能• LTE網を経由のハンドオーバが可能 -> IPv6利用可能

3GNTTドコモ

LTENTTドコモ

IIJ P-GW

IIJ GGSN IPv6不可

IPv6可能

EPC Capability:○ の場合横つなぎが利用される

EUTRAN Capability:○の場合LTE基地局に接続可能

27

3GNTTドコモ

LTENTTドコモ

IIJ P-GW

IIJ GGSN IPv6不可

IPv6可能


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

EPC Capability:○ の場合横つなぎが利用される

28

3GNTTドコモ

LTENTTドコモ

IIJ P-GW

IIJ GGSN IPv6不可

IPv6可能


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

NTTドコモではここの IPv6利用はサポートしてない

29


Nexus7(2013)/5.0.xで3Gの場合の接続シーケンス - 1

SGSN HLR端末NodeB

RNC EIR





Authentication Data Response

Authentication and Ciphering Request






Attach Accept

Attach Complete

GMM Information



IMEI Check Request

IMEI Check Response


Update Location Ack



モバイル網のPS Attachのみ。次のページに続く

← 3Gモードにしているため、ここで端末が無線の3G(UTRAN)/LTE(EUTRAN)能力を通知するときにUTRANだけの能力を通知

IIJ

P-GWS-GWIIJ

GGSN

ここで端末のLTEコア接続能力(EPC capability)を通知しない

3GPPの仕様では3Gに接続する場合ででも、EPC capabilityを通知する必要があるのだが…

30

MNO(NTTドコモ,3G) LTESGSN HLR端末

NodeB

RNC IIJ

P-GWEIR




Service Request





Radio Bearer Setup


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として要求を受け付けた旨が通知され、アドレスが返る



Radio Bearer Release

Radio Bearer Release Complete

← 端末はpdp-type=ipv4ipv6の要求が通らなかったので、IPv6用にpdp-type=ipv6で追加で接続を要求

Measurement Control

← 3Gドコモ網はpdp-type=ipv6を受け付けないため、接続が拒否され、接続を切断されてしまうRRC Connection Release




31


NodeB

RNC EIR




Service Request







IIJ

P-GWS-GW


Service Request

← pdp-type=ipv6の要求が通らなかったので、再度接続を要求

← 3Gドコモ網はpdp-type=ipv6を受け付けないため、接続が拒否され、接続が切断されてしまう





Service Request

Service Reject



← 一定時間後、pdp-type=ipv4の接続をデータ通信に利用しようとするが、その接続はありませんと網側から拒否されて切断される

pdp-type=ipv4の接続がなくなってしまったので、最初の接続要求pdp-type=ipv4ipv6に戻り、同様のことを繰り返し、不安定な状態が延々と続く

32

事例3:Nexus7(2013)で変なデータ接続をしようとする問題

• 事象• LTEでデータ接続を確立した状態で、追加でデータ接続を要

求して、接続が不安定になっている？• 再現させにくい問題のため、ユーザ影響が不明

• 動作• Nexus7(2013): 5.0.1で発生を確認• その他は発生せず

• 対策• 打つ手なし

• 原因• Basebandファームの問題？？


33


Nexus7/5.0.1の場合の接続シーケンス - 1

MME HSS端末


eNB S-GWIIJ

P-GW



Identity Request

Identity Response



EIR

←APN:mopera.net, user: mio@iij, pass: iijで接続を試みる。user/passがおかしい…


Attach Reject ← SIMが許可されてないAPNのため拒否される

次へ続く

34



MME HSS端末


eNB S-GWIIJ

P-GW









EIR


Attach Reject

←APN:mopera.net, user: mio@iij, pass: iijで再び接続を試みる。user/passがおかしい…

← SIMが許可されてないAPNのため拒否される

次へ続く

35


Nexus7/5.0.1の場合の接続シーケンス – 3

MME HSS端末


eNB S-GWIIJ

P-GW









EIR





←APN:iijmio.jp, user: mio@iij, pass: iijで再び接続を試みる -> OK

次へ続く

36




P-GWEIR






RRC Reconfiguration(Attach Accept)

RRC Reconfiguration Complete

Attach Complete









EMM Information

ここまでは通常のシーケンスなのだが…次へ続く

37




P-GWEIR

PDN Connectivity Request

PDN Connectivity Reject

←APN:dmjplat.net, user: [email protected] 追加のデータ接続を要求するが許可されてないAPNのため拒否される



←APN:bmobile.ne.jp, user: bmobile@am で同様RRC Connection Reconfiguration


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

RRC Connection Reconfiguration







←APN:bmobile.ne.jp, user: bmobile@zsim で同様





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

次へ続く

mailto:[email protected]

38




P-GWEIR



←APN:bmobile.ne.jp, user: bmobile@u300 で同様RRC Connection Reconfiguration


←一旦切断されて再接続を試みるRRC Connection Release

Service Request












←APN:bmobile.ne.jp, user: bmobile@spd で同様

次へ続く

39




P-GWEIR



←APN:bmobile.ne.jp, user: bmobile@cm で同様RRC Connection Reconfiguration


← ココで一旦終了。切断された後電波サーチ…RRC Connection Release

40

事例4: 認証失敗時にEMM Cause #15が返ってくる問題

• 事象• 事例1の事象に似ているのだが、3Gで接続後、3G->LTEの

ハンドオーバに必ず失敗して、接続ができない状態に陥る• 2015年になってから問題が発生して３月下旬に収束

• 動作• LTE端末(Androidに限らない)で広範囲に発生

• 対策• 事例１と同様• 現状は問題が発生しない状況になっている

• 原因• 原因は不明。キャリア設備の問題だった？？


41


MME HSS端末


eNB A S-GWIIJ

P-GW


RRC Connection Setup CompleteAttach Request

Identity Request

Identity Response



EIR



Attach Reject


← 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



MME HSS端末 eNB A S-GWIIJ

P-GWEIReNB B











Attach Reject

← eNB Aに接続できないので、新たに見つけたeNB Bへ接続


← SIMが許可されてないAPNのため拒否される。EMM Cause:No suitable cells in Tracking Area(#15)が受け取るため、端末はその基地局（eNB B)に一定時間接続できなくなる。

LTE基地局探索するも接続可能なものが見つからないので、3Gへフォールバック。次へ続く

43

MNO(NTTドコモ,3G)

SGSN HLR端末NodeB

RNC EIR





Authentication Data ResponseAuthentication and Ciphering Request






Attach Accept

Attach Complete

GMM Information



IMEI Check Request

IMEI Check Response


Update Location Ack



← #15で3Gにフォールバックした際は、無線接続能力を通知するときにUTRAN(3G)/EUTRAN(LTE)の両方の能力を通知。

この点が事例１と異なる

IIJ

P-GWS-GWLTE

Activate PDP Context Request ←APN:mopera.net へ接続を試みるattach後に連続してデータ接続要求を出したが、網側から切られてしまう


44


NodeB

RNC EIR




Service Request








Activate PDP Context Request← このページ全体のシーケンスとほぼ同じよう

な手順で繰り返しつつ、データ接続要求を下記のAPN順で繰り返すAPN: bmobile.ne.jp, user:bmobile@frAPN: bmobile.ne.jp, user:bmobile@u300APN: bmobile.ne.jp, user:bmobile@spdAPN: bmobile.ne.jp, user:bmobile@cm

IIJ

P-GWS-GW



RRC Connection Rejct

← EUTRANにredirection可能と通知して3Gに接続要求← Rejectの中にeNB A側へ接続しろとredirection指示が来る

LTEのeNB Aは接続禁止のため、他の基地局を探索…接続可能なLTE基地局がないため、3Gにフォールバック

45

Physical Channel Reconfiguration

Measurement Control

Radio Bearer Setup

LTE MNO(NTTドコモ,3G) LTESGSN HLR端末

NodeB

RNC IIJ

P-GWEIR




Service Request







ここまでは事例１の3Gの挙動とほぼ一緒次へ続く

P-TMSI Reallocation Command

P-TMSI Reallocation Complete




S-GW

↑ APN:iijmio.jpに接続EPC capabilityがあるのでS-GW経由でデータ接続を確立


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

eNB A

46

Measurement Report

LTE MNO(NTTドコモ,3G) LTESGSN HLR端末

NodeB

RNC IIJ

P-GWEIR

Measurement Control

Measurement Report

S-GW


Handover From UTRAN Command - EUTRAN

eNB A



ところが…。LTEのeNB Aは接続禁止であることを検出して、端末から強制切断。電波のサーチをしつつ、シーケンス–5 に戻って同じ繰り返しとなり、接続できない状態が延々続く

← EUTRANの能力があるため、基地局がLTEへのハンドオーバーのための、確認を端末へ要求。端末がハンドオーバー先となるLTE基地局の電波状況を報告。基地局がLTEへハンドオーバーを指示。

47

4. まとめ

48

まとめ

•MVNOの視点• SIMフリー端末の接続問題の調査は簡単ではない•無線区間でやりとりされる制御信号解析はトラブルシューティングには非常に有用•制御信号解析できないとMVNOは何も出来ない

•ユーザの視点接続問題を緩和するために、現状は

• APN設定は利用するもの以外は全部削除する• APNプロトコルは IPv4 を利用

を推奨（全てが解決するわけではない！）

•今後についてQualcommなAndroid端末以外での解析できるような環境の整備を検討中

49

SIMフリー端末メーカー様へのお願い

• IIJはユーザの端末選択の選択肢が増えるように、SIMフリー端末の普及、促進を推進していきます

• 一方で、モバイルキャリアとのIOT行っていない端末での接続不具合はユーザの利便性を損ない、SIMフリー端末の普及を妨げる要因になってしまいます

• IOTを通してない場合でも、メーカー様が作られた端末をIIJに持ち込んで頂いて、共同でテスト実施させて頂ける機会を頂けないかと考えています

• ご協力、よろしくお願いいたします

50

おまけ

51

制御メッセージを見てみよう！

• このツールインストール• http://3gppdecoder.free.fr/?q=node/1• Wireshark入れるの忘れずに！• メッセージの種類を選択＋HEXデータをコピペすると見れる

• Nexus6(5.1)の初期シーケンスデータ

http://3gppdecoder.free.fr/?q=node/1

52

(再掲) LTE端末の初期の接続シーケンス例 - 1

MME HSS端末


eNB S-GWIIJ

P-GW



Identity Request

Identity Response

Authentication Information Request








EIR


Identity Check Ack





MNO(NTTドコモ)

← モバイルネットワークへの接続要求

← IMSI or IMEI要求

← SIM認証

← ユーザ認証ベクトル生成

← 端末とMME間の暗号化,IMEI要求

← IMEIチェック

← 接続情報を通知:APN,PDP Type,PCO(user/pass,DNS要求)

← 位置情報更新/ユーザのサービスに利用する各種情報の取得

← 下りデータ通信トンネルの作成。MVNOのユーザ認証

53

MNO(NTTドコモ)

(再掲) LTE端末の初期の接続シーケンス例 - 2


P-GWEIR






RRC Connection Reconfiguration(Attach Accept)


Attach Complete








← 上りデータ通信トンネル作成IPアドレス, DNSアドレス返信

← 端末の無線(3G/LTE)能力の取得


← 端末とeNB間の暗号化

← 上りデータ通信トンネル作成

← データ通信トンネル作成IPアドレス, DNSアドレス返信

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)203000EC942C0741710BF644F00100EC94EE00D07104F070C04000050208D011D1191DCE755C0A003103E5E0345D0103E1C161

• Identity Request (LTE -> NAS-EPS_plain)(略)

• Identity Response (LTE -> NAS-EPS_plain)(略)

• Authentication Request (LTE -> NAS-EPS_plain)0752011BB3E53C4D980680023CA7B34D980680107626E6CBA489800296ACCAE3741380E8B05F

• Authentication Response (LTE -> NAS-EPS_plain)0753100A6535FD74929176156FCEC6A3662FDFE4BC

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)0208DA280A0669696A6D696F026A70275E80C2231C0100001C10B8384848B8384848B8384848B83848486D696F4069696AC2231C0200001C1019104AB5D27FBDDF70B2F4DD7ADFC1C66D696F4069696A80211001000010810600000000830600000000000D00000A000005000010000000000000005F83

56


• UE Capability Enquiry (LTE -> LTE-RRC.DL.DCCH)380404

• UE Capability Information (LTE -> LTE-RRC.UL.DCCH)3802080B2C998009001282410307104CD8993FF97FFF27D72FFFE4FFE5FFFC9FFCBFFF937F97FFF27FF2FFFE4DFE5FFFC9FFCBFFF93FF97FFF27FF2FFFDFF3FFA7A20E008C853A208329D2A4A91C5FB00000001C07FCFFE9EC0000000709FF3FFA7B00000000EA0C1C200040470800E100020220400710001010820038E00080841001C9FFCBFFF93FF97FFF27FF2FFFE4FFE5FFF800200005C40004000020002000003FD00000003F40000000FD00000003F40000000180857FFFFFA8CAAB541A955AA22920C112000600054384271CFBDE899EBB65CA138E7DEF44CF5DB2F509C73EF7A267AED97684E39F7BD133D76CB73D033FD410B438F5E7A1A3B7A267AED97142D0E3D79E868EDE899EBB65ED0B438F5E7A1A3B7A267AED96C20C7BCA0C7BEA0C7BDA0C7BDEA53000016925AD2200D9832042891A3C8A54EDE8D8

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)201615A80010008A42F10C0CC06609900C8066099C1421AA89886019004380E8C8401280942024C9EEC24640854B41956FB650D07225E57BC2EE2FDAAFEE717B05587F50A5F0BB51849F9075C494CBB2CD6DB74D6B169636E23AEE582BFBDD73B34888D98B1A98FC5277557A46361BFE5F8DBE04A59A0E30D0648CE23634A641B85C3B65BBAF77945391A98D1044905C53146AD346B8605D3801C94FB7089F922F0D8AFB59E2BBF6827C8C66CD48F19107812B3430109FC3B3409A9C08FCCE0193901F523781F56C0C0DC4E296975CE20898600980C150

• 上のメッセージに含まれているが、暗号化されている部分• Attach Accept/ Activate Default Bearer Context Request (LTE ->

NAS-EPS_plain)07420149064044F0011410006A5223C101091D0669696A6D696F026A70066D6E63303130066D6363343430046770727305010AC494A45D0100301022931F9396FEFE8648FFFF00FA00FA005E06FEFEDDDD1010272280000D04CAE80202000D04CAE80203802110030000108106CAE802028306CAE80203500BF644F001BC1403E166F1E35302172C5949640108DDB8

• RRC Connection Reconfiguration Complete (LTE -> LTE-RRC.UL.DCCH)1000

• Attach Complete (LTE -> NAS-EPS_plain)074300035200C2000000000000E513

Internet

IIJmio meeting 7 MVNOとSIMフリー端末の問題について