IIJmio meeting 14 IIJmioタイプAとSIMフリー端末について

© 2016 Internet Initiative Japan Inc. 1
株式会社インターネットイニシアティブ
大内宗徳
IIJmio meeting 14
IIJmio タイプAとSIMフリー端末について

はじめに
IIJでは2016年10月からauの回線を利用したIIJmio
モバイルサービスタイプAを提供しています。
日本で流通している多くのSIMフリー端末ではタイ
プAサービスが利用できません。本セッションでは
なぜサービスが利用できないのか、その他諸々の問
題等を含めて、調査で判明した内容をご紹介します。
• スピーカー
• 大内宗徳
• IIJのモバイルサービスに関わる技術、製品調査、研
究開発、機器動作検証を担当
• IIJmio meeting 5,6,7,8,10,11,12 でトークセッ
ションを担当

• 結論
• タイプAとSIMフリー端末
• タイプAサービスの各種問題
• まとめ

• 結論
• まとめ

結論 – スマホ利用ユーザ向け
• IIJmioモバイルサービスタイプAを契約される方に
お願い
• タイプDと異なり、市場に流通する多くのSIMフリー端
末では利用できません
• 下記の事項について必ず確認を行い納得の上で契約をお
願いします
1. au端末はVoLTE対応でSIMロック解除が必要
2. iPhone: iPhone6S世代以降の端末のみ対応
3. iPhone以外: KDDI様の相互接続テストに通過した
SIMフリー端末のみ利用可能
https://open-dev.kddi.com/information
4. 各種制限や問題となる事項があります
詳細は本トークセッションで説明

結論 – 端末メーカー様向け
• IIJmioモバイルサービスタイプAが利用するau
VoLTE SIM向け端末を製造している端末メーカー
様向けにお願い
• auのIOT(相互接続)テストを通過させた上で、相互
接続テストには含まれていない（？）と思われる問
題があるため、本セッションで説明する事項の追加
対応を是非お願いします

• 結論
• まとめ

au網は3G(C2K/CDMA2000)を採用し、また、割り当てを
受けている周波数の関係でグローバルから見ると特殊な
キャリアとなっており、下記の問題があります。
1. タイプAは3G(WCDMA)がないLTEのみ
2. au 4G LTEで利用するBand 1の上り周波数の問題
日本で流通するSIMフリー端末の多くは、この問題に対応
してないため利用ができません。
次のページ以降でこの問題を解説します。
タイプAとSIMフリー端末

• 問題
– 日本で流通する多くのSIMフリー端末は、LTEと
3G(WCDMA)の両方が使える前提で作られている
• 音声/SMSは3G(WCDMA)の設備を利用するため
– タイプAが利用するau 4G LTEのみの網に接続した場合、
上記前提が崩れて正常に動作しない
• 対応
– 音声端末はau VoLTE対応が必須
– 一方、データ専用端末は必須ではない
• 音声端末は3G(WCDMA)が無いとなぜ駄目なのかを次の
ページ以降で解説

• 端末から見えるau網の構成
• 端末から見えるドコモ網の構成
• LTE(3G音声)端末のドコモへの在圏登録
• LTE(3G音声)端末のauへの在圏登録
• au向けLTE(VoLTE音声)端末のauへの在圏登録
• LTE(データ専用)端末のドコモへの在圏登録
• LTE(データ専用)端末のauへの在圏登録

• ユーザから見えるau網は3種類
• SIMによって接続できる網が異なる
au IIJ インターネット
LTE
3G(c2k)
(データ/音声/SMS)
IMS(VoLTE/SMS)
LTE
au 4G LTE(VoLTE専用)
(PLMN:44051)
au 4G LTE
(PLMN:44050)
タイプAではこちらのネット
ワークのみ利用可能
IMSI:44051…
IMSI:44050…
IMS(SMS)
au 3G(c2k)

（参考）純正au iPhone6以降のVoLTE対応
• 既存ユーザSIM(PLMN:44050)を使いつつ、2つの網にまたがる設備
を使い、無理やり対応している（？）
• iPhoneキャリア設定を見ると実現の苦労が見て取れる
LTE IMS(VoLTE/SMS)
LTE
(PLMN:44051)
IMSI:44050…
3G(c2k)
au 4G LTE
(PLMN:44050)
au 3G(c2k)
IMS(SMS)

• 大まかに3G(WCDMA)とLTEの2つの網が見える
• 3Gは更に3G-PS/3G-CSがある
ドコモ IIJ インターネット
LTE
3G-CS
(音声/SMS)
IMS
(VoLTE/SMS)
3G-PS
（データ）
3G(WCDMA)
LTE
一般的なLTE(3G音声)対応端末は、3G-
CSが利用できる前提で作られている！
これが利用できないと問題が生じる。

• LTE(3G音声)端末のドコモへの在圏登録 – 1
• 在圏登録=サービス利用開始時に端末情報を登録する動作
• グローバル仕様の端末で音声/SMSを利用するには3G-CSを利用
LTE
3G-CS
(音声/SMS)
IMS
(VoLTE/SMS)
3G-PS
(データ)
3Gの在圏登録
(Combined GPRS
IMSI attach)
LTEの在圏登録
(Combined EPS/
IMSI attach)
3G or LTE在圏に関わらず、音声
利用前提なので、3G-CSに間接的
に在圏登録

• LTE(3G音声)端末のドコモへの在圏登録 – 2
• (参考) VoLTE対応端末の場合
LTE
3G-CS
(音声/SMS)
IMS
(VoLTE/SMS)
3G-PS
(データ)
LTEの在圏登録
(Combined EPS/
IMSI attach)
LTE在圏時に、IMSと3G-CSの両方に
在圏登録
両方利用可能な場合は、通常はIMSを
優先して利用

au 4G LTE
(VoLTE専用) IIJ インターネット
LTE
IMS
(VoLTE/SMS)
3G-CS
(音声/SMS)
LTEへの在圏登録
1. Combined EPS/IMSI attach での接続を試みる
2. 応答が EPS only+EMM Cause(CS Domain not available)
3G-PS
• LTE(3G音声)端末のauへの在圏登録 – 1
• 3G-CSが存在しない場合の応答が曲者

au 4G LTE
LTE
IMS
(VoLTE/SMS)
3G-CS
(音声/SMS)
3G-PS
CS Domain not availableの場合、端末は下記を実行
1. 音声利用優先モードの場合 (音声端末)
1-1. IMS在圏登録確認
1-2. 1-1が失敗した場合は3G-CS在圏登録が可能な他網へ接続
2. データ利用優先モードの場合 (データ専用端末)
2-1. 特になにもしない

au 4G LTE
LTE
IMS
(VoLTE/SMS)
3G-CS
(音声/SMS)
3G-PS
一定時間IMS在圏登録可能か待つため、
端末の4Gマークがついた状態に。
IMS接続機能をもたないため接続できない。
1. 音声利用優先モードの場合

au 4G LTE
LTE
IMS
(VoLTE/SMS)
3G-CS
(音声/SMS)
3G-PS
1-2. 1-1.が失敗した場合は3G-CS在圏登録が可能な他網へ接続
• LTE網との接続を切断 -> 圏外になる
• 3G-CS在圏登録が可能な網を探すが見つからない -> 圏外状態のままに

au 4G LTE
LTE
IMS
(VoLTE/SMS)
3G-CS
(音声/SMS)
3G-PS
2-1. 特に何もしない
データ接続ができていれば、LTE通信は継続。
データ利用優先モードな音声端末であれば、
音声は使えないがデータ通信は可能
2. データ利用優先モードの場合
2-1. 特にもしない

au 4G LTE
LTE
IMS
(VoLTE/SMS)
3G-CS
(音声/SMS)
3G-PS
IMS在圏登録でき、VoLTE(IMS経由の音声
サービス)が利用可能な状態に。
データ接続は継続される
• au向けLTE(VoLTE音声)端末のauへの在圏登録 – 1
1. Combined EPS/IMSI attach での接続を試みる
2. 応答が EPS only+EMM Cause(CS Domain not available)

LTE
3G-CS
(音声/SMS)
IMS
(VoLTE/SMS)
3G-PS
EPS only attach
データ専用の場合
- 3G: combined GPRS IMSI attachでなく、GPRS attach
- LTE: combined EPS/IMSI attachでなく、EPS only attach
- 3G-CSに在圏登録はしない
- 3G or LTE接続が維持される
GPRS attach
3Gへの在圏登録

au 4G LTE
LTE
IMS
(VoLTE/SMS)
3G-CS
(音声/SMS)
3G-PS
データ専用の場合
- combined EPS/IMSI attachでなく、EPS only attach
- EPS onlyの返答が返ってくる
- CS Domain not available は網から返ってこない
- LTE接続が維持される
- ‘’データ専用の場合はVoLTE実装は必須でない’’
EPS only attachを試みる
-> EPS only の返答が帰ってくる

• 問題
– auのLTE Band1(2GHz帯)の上り周波数は、PHSと隣接
するため、帯域外発射(スプリアス発射)の制約が厳しい
• 対応
– Band 1に対応するタイプAで利用するSIMフリー端末は、
日本のこの周波数向け帯域外発射を満たす認証を通す必
用がある
– PHSへの帯域外発射を抑えるには、端末送信電力が最大
+23dBm(0.2W)の場合、ガードバンドとして
(4MHz + 利用帯域) 必要と言われている
– au(KDDI)は十分なガードバンドが確保できない
– 詳細は次のページ以降で解説
2. au 4G LTEで利用するBand 1の上り周波数の問題

2. au 4G LTEで利用するBand 1の上り周波数の問題 - 1
PHS KDDI ドコモ SB
1920.01915.851884.65 1940.0 1960.0 1980.0
4+10MHz
5MHz運用
下:37.5Mbps
上:12.5Mbps
10MHz運用
下:75Mbps
上:25Mbps
15MHz運用
下:112.5Mbps
上:37.5Mbps
20MHz運用
下:150Mbps
上:50Mbps
4+15MHz
4+20MHz
4+5MHz
MHz
-> OK
-> OK?NG?
-> NG
-> NG
総務省が周波数割当の際に確保しているガードバンド(約4MHz)
PHSへの帯域外発射を規制値内に収めるために、実際に必要なガードバンド
実際に使える周波数帯

上り周波数の制約のため下記の２つの実装をとっ
ている
1. PHS隣接周波数での端末の送信電力の制限
• 利点 : 割り当てられた周波数帯をLTEで有効活用可能
• 欠点 : Band 1でカバーできるエリアが大幅に狭くなる
2. 15MHz,20MHzで利用する場合は、利用可能な上り
周波数帯を制限
• 利点: 送信電力を制限することなくエリアを作れる
• 欠点: 上りの送信帯域が大幅に減る
• SIMフリー端末では上記の制限の場合に、PHSへ
の帯域外発射が規定値以内に収まるような設計を
して、技適を通す必用がある

端末の実装の例(iPhone7, [R]003-160134)
PHS KDDI ドコモ SB
1920.01915.851884.65 1940.0 1960.0 1980.0
+23dBm/0.2W
5MHz運用
下:37.5Mbps
上:12.5Mbps
10MHz運用
下:75Mbps
上:25Mbps
15MHz運用
下:112.5Mbps
上:15Mbps
20MHz運用
下:150Mbps
上:12Mbps
+19.1dBm/
0.082W
+17.2dBm/0.052W
+12.0dBm/0.016W
1922.5 1927.1 1977.5
1925.0 1934.6 1975.0
1942.2 1972.5
1949.7 1970.0
1927.5
1927.19 1937.815.4MHz
1930.0
1925.32 1934.68
4.32MHz

• 結論
• まとめ
• おまけ

• サービス開始後に、SIMフリー端末で動作確認を
している際に発覚した問題がある
• au網を使うタイプAでは、ドコモでは気にする必
要がなかった点のチューニングが必要になる
– デザリングが出来ない問題
– IP MTU問題
– 音声着呼時の発番号表示問題
– 開封直後のSIMが利用できない問題
タイプAサービスの各種問題

• デザリングが出来ない問題
• IP MTU問題
• 音声着呼時の発番号表示問題
• 開封直後のSIMが利用できない問題

• 問題
– タイプAを利用した場合にテザリングできない
• ユーザの対応策
– 端末によって状況が異なる
1. iPhone6S世代以降のSIMフリーiOS端末
-> 対応策なし
2. 一部のAndroid端末
-> IIJmioのAPN以外を全て削除することで回避可能
• 原因
テザリングが出来ない問題

問題点
1. auキャリア設定ではテザリング利用可否をauサーバで管理
2. タイプA SIMはauキャリア設定利用してしまう
3. IIJ(MVNO)にはテザリングを許可させる権限がない
4. IIJ(MVNO)からサーバにアクセスできない
au 4G LTE
インターネット
Entitlement server
station01.ezweb.ne.jp
auユーザ
タイプA
IIJ
1. テザリング可能？
-> OK
MVNOはこの経路でサーバへ到達2の問題
3の問題
4の問題

(参考) UQ Mobileの場合
1. UQ Mobile専用キャリア設定が存在
-> 無制限でテザリング可能
2. UQ Mobile SIMを指す
SIM内のICCIDの値で、UQ Mobileを識別してUQ
Mobileキャリア設定を適用
3. テザリングし放題！
UQ Mobileと他のau網利用MVNOとの差は何？

2. 一部のAndroid端末 - 1
他社APN設定の影響でテザリングから接続できない
– 発生条件
• タイプA SIMを指すと複数APN設定が存在
• その一つのAPNタイプに’dun’という設定が存在
– 現象
• テザリングON時に’dun’が設定されている他社APNへ接続
• 他社APNへの接続が失敗 -> テザリングが出来ない
(注)複数SIMを同時にさして利用できるDSDS端末の
場合、SIMスロット位置でテザリングが出来る場合も

2. 一部のAndroid端末 – ２
Zenfone3の例
UQ Mobile
APNタイプに
dun設定あり
IIJmio
APNタイプに
dun設定なし

• IP MTU問題

• 問題
– タイプAを利用した場合に速度が安定しない
• ユーザの対応策
– 対応策なし
– 端末での対応が必要に
• 原因
– 一般的なIP MTU=1500bytesの長さのパケットを
au網で送信しようとするとIPパケットの分割/組み
立てがau網の中で発生するため、通信スループッ
トが大幅に低下する問題がある
IP MTU問題

ドコモ網 IIJ
GTP
インターネット
IPパケット
au網 IIJ インターネット
ドコモ網にIPパケット(1500bytes)を投げる際に、GTPヘッダー(40bytes)を付ける
IP MTU 1540bytesをそのまま通せて、端末到着前にGTPヘッダーを外す
au網ではGTPを含めてIP MTU
1500bytesしか通らないので、
IPパケットを２分割して送信
端末にIPパケットが送られる
前に網側でパケットを組み立
ててから送信 -> スループットに影響？
IP MTU問題
IPパケット IPパケット
IPパケット GTP IP #1
GTP IP #2
IPパケット

フラグメントを避ける実装がIIJでは困難なため、au 4G
LTE SIM(PLMN:44051)の場合に、端末側に下記の実装が
必須
1. スマートフォン/タブレットの場合
– 端末のモバイル側のインターフェースをIP MTU 1420 bytesに
• 1420bytesはau端末の標準実装の値のため
• AndroidではAPN設定ファイルで apns-conf.xml 等で可能？！
• (注) ユーザはAPN設定からMTUは設定出来ない
2. WiFiルータ/スマホのテザリング利用する場合
– ルータ側がTCPの3-way handshakeの際に交換される
MSS(Maximum Segment Size)の値をチェックして、
1380bytesへ上書きする
• WiFi側につながるデバイスはDHCPではMTU変更が難しい場合があるため
IP MTU問題

(参考) IIJmio Type A と Nexus5X(7.0) で端末側のIP
MTUを変更して速度を計測
– Speedtest.net [サーバ Sumida(denpa893)] で計測
• IP MTU = 1500 : 下り 2.80Mbps, 上り 10.15Mbps
– RBB SPEED TEST で計測
• 端末側のIP MTU(TCP MSS)をチューニングして速度計測する場合
の注意点
– 速度計測アプリ(サイト)が利用するサーバ側のIP MTU(or TCP MSS)が
異なる場合もあるので注意する必用がある
– 事前に速度計測サイトとの通信をWireshark/tcpdump等のパケット
キャプチャツールでキャプチャを行いTCP MSSの値が適切なものに
なっているか確認が必要
IP MTU問題

• IPフラグメントを避けるために、TCP通信開始時の3-way
handshakeのTCP optionで、1 TCP/IPパケットで送信可能な最大
サイズをネゴシエーション
• TCP MSS はTCPのデータ部分の長さを表す
TCPヘッダー
標準は20bytesで
option設定で＋α
IPヘッダー
通常20bytes
TCPデータ
通常は
(TCP MSS)=(IP MTU) - (IPヘッダー) - (TCPヘッダー)
が利用される。1460bytesのことが多い。
IP MTU部分
TCP SYN (MSS 1380)
TCP SYN+ACK
(MSS 1460)
TCP ACK
TCP MSS 1380bytes利用
(自身のもともとの値を採用)
TCP MSS 1380bytesに変更
SYN or SYN+ACKで交換した
MSSで小さい方の値を採用
IP MTU
1420bytes
IP MTU
1500bytes
(補足1) 対向サーバなどのIP MTUは直接わからないが、TCP 3-way handshakeのTCP MSSを通じて
間接的に IP MTUを知ることが出来る
(補足2) TCP MSSを明示的に小さくすることでIP MTUを小さくした場合と同様の効果が得られる
IP MTU問題 – おまけ

• IP MTU問題

• 問題
– タイプA利用時に一部のAndroid端末で着呼時に、+81… と
いう電話番号表示になってしまう
• ユーザで出来る対策
– なし。端末メーカーに修正してもらうしか無い
• 原因
– au IMSの仕様に端末が対応していないため
– 補足
• +81…は国識別番号
• 通常は海外の音声端末とやり取りする場合に利用する形式
• 国内では +81は使わず+81->0 と置き換えて使っている
(例) +8170-XXXX-XXX -> 070-XXXX-XXXX
次のページで詳細を解説
音声着呼時の発番号表示問題

• 詳細解説
– VoLTEはSIPプロトコルを利用して音声の発着呼を制御
– 端末は着呼時にSIP INVITEメッセージを受け取る
– その中に発信側番号が記載されており、これが端末に表
示される
– au IMS網の仕様(?)のため、発信側番号が国内の 0 で始
まる番号でなく、+81 で記載されている
– 端末の電話アプリで、+81 で始まる場合は 0 に置き換
える実装が必要
– これが実装されてないと、+81表示になる
• 具体的なメッセージの内容は次のページで

• タイプA+iPhone7 Plusで受信したSIP INVITE例
INVITE sip:[2001:268:b27d:c0b1:7e:25ef:4dcd:3062]:49156 SIP/2.0
Max-Forwards: 62
Via: SIP/2.0/UDP
[2001:268:E606:8010::B]:7777;branch=z9hG4bKg3Zqkv7iusd1onsucniqxqvm8vw289hpf
To: <sip:0703836XXXX;phone-
context=ims.mnc051.mcc440.3gppnetwork.org@ims.mnc051.mcc440.3gppnetwork.org;user=p
hone>
From: <sip:+81809360XXXX@ims.mnc051.mcc440.3gppnetwork.org;user=phone>;tag=h7g4Esb
g_p65552t1484647362m140915c1055402409s1_1721974645-1984494589
Call-ID: p65552t1484647362m140915c1055402409s2
CSeq: 1 INVITE
Contact: <sip:sgc_c@[2001:268:E606:8010::B]:7777;transport=udp>;+g.3gpp.icsi-
ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
発信者番号が+81で始まっている

• タイプD+iPhone7 Plusで受信したSIP INVITE例
INVITE sip:[240a:5:4875:f51b:484:cce2:45fa:6cb0]:49184 SIP/2.0
Via: SIP/2.0/TCP
[240a:2:4401:41::9]:4503;branch=z9hG4bKee32428878cd45049c83ec9e6557dcda
From: <sip:09055XXXXXX@dcmip.net>;tag=398025e1f158dd6410c2aa2293223b35
To: <sip:0809286XXXX@dcmip.net>
Call-ID: fd5dcddba4e9d2af30342d28da9184d8@240a:2:4401:41::9
CSeq: 1 INVITE
Contact: <sip:[240a:2:4401:41::9]:4500>;+g.3gpp.mid-call
Record-Route: <sip:[240a:2:4401:41::9]:4500>;+g.3gpp.srvcc;+g.3gpp.srvcc-alerting
Supported: timer
Require: 100rel,precondition
Session-Expires: 300
発信者番号が0で始まっている

• IP MTU問題

• 問題
– タイプAでパッケージ開封直後のSIMを指した場合に、
一部のモバイルルータ(NEC MR04LN/MR05LN)で利用
できない問題
• ユーザで出来る対策
– 国際ローミングを有効化すると接続可能に
– 一度接続できた後は国際ローミング無効してOK
• 原因
– タイプA SIMとモバイルルータの仕様との相性問題で接
続ができない状態になっていた
– 次のページで詳細を解説
開封直後のSIMが利用できない問題

(前提1)
– SIM内には最後に在圏した/在圏を試みたネットワーク関
する情報が保存されている（下記のSIMファイル)
• EF_LOCI : 3G-CS在圏情報 (音声端末が利用)
• EF_PSLOCI : 3G-PS在圏情報 (データ専用端末が利用)
– ここに最後に在圏した網の情報、RPLMN(Registered
PLMN)がある
（例）RPLMN => 44050,44051とか
– 次回端末が在圏を試みる際には、RPLMNへ最初に在圏を
試みる
• RPLMNへの在圏に失敗すると、Home PLMN (例:
IMSI:44051…) に在圏を試みる
– タイプA SIMはPLMN:44051の網を利用するのだが、
EF_LOCI/EF_PSLOCIの初期値がRPLMN:44050になっている

(前提2)
– ローミングとは、SIMのHome PLMN(IMSI:44051…)
と在圏を試みるPLMN(例:44050)が異なる状態
– ローミング状態での挙動
1. 一般的なLTE対応音声端末の場合
– データローミングがOFFでも、音声サービス利用のための
LTE or 3Gへ在圏登録を試みる
2. モバイルルータ(NEC MR04LN/MR05LN)の場合
– 国際ローミングをOFFだと、LTE or 3Gへ在圏登録を一切行
わない(デフォルト状態)
– ローミング状態で不要な在圏登録を減らすため、網側か
らローミング在圏禁止の応答が返ってきたら、SIMに
EF_FPLMN(Forbidden PLMN) として書き込まれる
• FPLMNへは一切在圏登録を試みない

1. 一般的なLTE対応音声端末の場合 – 1
LTE
3G(c2k)
IMS(VoLTE/SMS)
LTE
(PLMN:44051)
au 4G LTE
(PLMN:44050)
ローミング在圏: する
IMSI:44051…
RPLMN:44050
FPLMN:なし->44050
IMS(SMS)
au 3G(c2k)
タイプA
- 開封直後のSIM(IMSI:44051…)内のRPLMNが44050のため、RPLMNに
ローミング在圏を試みる
- タイプA SIMはローミング網(PLMN:44050)への在圏が禁止されている
ため、ローミング在圏禁止の応答が返る
- FPLMNに 44050 が追加される

1. 一般的なLTE対応音声端末の場合 – 2
LTE
3G(c2k)
IMS(VoLTE/SMS)
LTE
(PLMN:44051)
au 4G LTE
(PLMN:44050)
IMS(SMS)
au 3G(c2k)
タイプA
- FPLMN:44050であるため、RPLMN:44050へ在圏登録はしない
- 次にタイプA SIMのHome PLMN(IMSI:44051…)に在圏を試みる
- 接続OK!
ローミング在圏: する
IMSI:44051…
RPLMN:44050
FPLMN:44050

2. モバイルルータ(NEC MR04LN/MR05LN)の場合
LTE
3G(c2k)
IMS(VoLTE/SMS)
LTE
(PLMN:44051)
au 4G LTE
(PLMN:44050)
IMS(SMS)
au 3G(c2k)
タイプA
- 開封直後のSIM(IMSI:44051)内のRPLMNが44050のため、RPLMNに
ローミング在圏を試みたいが、ローミング在圏をしない設定のため、在
圏登録ができない
- RPLMNへの在圏登録が禁止されている状態にならないため、内部的に
RPLMNへの在圏を試みるループになり、圏外状態が継続
ローミング在圏:しない
IMSI:44051…
RPLMN:44050
FPLMN:なし
国際ローミングをONにする
と、LTE音声端末と同様の挙
動になるため、問題解消！

• 結論
• まとめ

(再掲) 結論 – スマホ利用ユーザ向け
• IIJmioモバイルサービスタイプAを契約される方に
お願い
• タイプDと異なり、市場に流通する多くのSIMフリー端
末では利用できません
• 下記の事項について必ず確認を行い納得の上で契約をお
願いします
1. au端末はVoLTE対応でSIMロック解除が必要
2. iPhone: iPhone6S世代以降の端末のみ対応
3. iPhone以外: KDDI様の相互接続テストに通過した
SIMフリー端末のみ利用可能
https://open-dev.kddi.com/information
4. 各種制限や問題となる事項があります
詳細は本トークセッションで説明

(再掲) 結論 – 端末メーカー様向け
• IIJmioモバイルサービスタイプAが利用するau
VoLTE SIM向け端末を製造している端末メーカー
様向けにお願い
• auのIOT(相互接続)テストを通過させた上で、相互
接続テストには含まれていない（？）と思われる問
題があるため、本セッションで説明する事項の追加
対応を是非お願いします

まとめ
• タイプAサービスが一般的なSIMフリー端末で利用
できない理由や問題点を解説しました
• タイプAサービスの利用に関して２点メッセージを
お伝えしました
1. スマホ利用ユーザ向けの注意
2. SIMフリー端末メーカー様へのお願い
• IIJではタイプAをタイプDと同様にSIMフリー端末
で利用して頂けるような取り組みを進めていきます
• タイプAでIIJmioの端末の動作確認を行う際には本セッ
ションで指摘した問題点の確認
• SIMフリー端末メーカー様に、タイプAで発生する問題
点を修正をお願いする取り組み

モバイルエンジニア募集中! - 1
• IIJ MVNOサービスの加入者は急拡大中！
2016 Q2決算資料

• サービス、加入者の急拡大に伴い、MVNOサービ
スのインフラを支えるモバイルエンジニアの増強
を行っています！
• 日本のMVNOをリードするIIJで、モバイルサービ
スを支えるエンジニアとして活躍してみません
か？
• IIJではこんなことが出来ます!
• 新技術を取り入れたサービス、インフラの企画、
設計、開発
• モバイル最新技術の調査、研究、開発、検証
• 誰もやってないことへの挑戦

• IIJキャリア採用情報
IIJ キャリア採用で検索してください
募集職種:
モバイルエンジニア(MVNOサービスインフラ開発)
• モバイルエンジニアの職務
1. MVNOサービスインフラ(EPC、認証、顧客管理等)の
企画、設計、開発
2. モバイル関連の基礎技術、要素技術、製品の調査、
評価、検証 (R&D）
3. モバイルサービス事業者との技術的協議
• ちなみに、大内は…
• R&Dを中心に、上記を全部やってます!

IIJmio meeting 14 IIJmioタイプAとSIMフリー端末について

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to IIJmio meeting 14 IIJmioタイプAとSIMフリー端末について (15)

More from techlog (Internet Initiative Japan Inc.) (20)

IIJmio meeting 14 IIJmioタイプAとSIMフリー端末について