iijmio meeting 14 iijmioタイプaとsimフリー端末について

© 2016 Internet Initiative Japan Inc. 1

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

大内宗徳

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


はじめに

IIJでは2016年10月からauの回線を利用したIIJmio モバイルサービスタイプAを提供しています。日本で流通している多くのSIMフリー端末ではタイプAサービスが利用できません。本セッションではなぜサービスが利用できないのか、その他諸々の問題等を含めて、調査で判明した内容をご紹介します。

• スピーカー• 大内宗徳

• IIJのモバイルサービスに関わる技術、製品調査、研究開発、機器動作検証を担当

• IIJmio meeting 5,6,7,8,10,11,12 でトークセッションを担当


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

• 結論• タイプ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. 各種制限や問題となる事項があります詳細は本トークセッションで説明

https://open-dev.kddi.com/information


結論 – 端末メーカー様向け

• 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網の構成• ユーザから見える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 インターネット

LTEIMS

(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が存在しない場合の応答が曲者




LTEIMS

(VoLTE/SMS)

3G-CS(音声/SMS)


3G-PS

CS Domain not availableの場合、端末は下記を実行1.音声利用優先モードの場合 (音声端末)

1-1. IMS在圏登録確認1-2. 1-1が失敗した場合は3G-CS在圏登録が可能な他網へ接続

2. データ利用優先モードの場合 (データ専用端末)2-1. 特になにもしない

•LTE(3G音声)端末のauへの在圏登録 – 2




LTEIMS

(VoLTE/SMS)

3G-CS(音声/SMS)

3G-PS

1-1. IMS在圏登録確認一定時間IMS在圏登録可能か待つため、端末の4Gマークがついた状態に。IMS接続機能をもたないため接続できない。

•LTE(3G音声)端末のauへの在圏登録 – 31. 音声利用優先モードの場合





LTEIMS

(VoLTE/SMS)

3G-CS(音声/SMS)

3G-PS

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

•LTE(3G音声)端末のauへの在圏登録 – 41. 音声利用優先モードの場合





LTEIMS

(VoLTE/SMS)

3G-CS(音声/SMS)

3G-PS

2-1. 特に何もしないデータ接続ができていれば、LTE通信は継続。データ利用優先モードな音声端末であれば、音声は使えないがデータ通信は可能

•LTE(3G音声)端末のauへの在圏登録 – 52. データ利用優先モードの場合

2-1. 特にもしない




LTEIMS

(VoLTE/SMS)

3G-CS(音声/SMS)

3G-PS

1-1. IMS在圏登録確認IMS在圏登録でき、VoLTE(IMS経由の音声

サービス)が利用可能な状態に。データ接続は継続される

•au向けLTE(VoLTE音声)端末のauへの在圏登録 – 11. 音声利用優先モードの場合




1. Combined EPS/IMSI attach での接続を試みる2. 応答が EPS only+EMM Cause(CS Domain not available)


•LTE(データ専用)端末のドコモへの在圏登録


LTE

3G-CS(音声/SMS)

IMS(VoLTE/SMS)

3G-PS

LTEへの在圏登録EPS only attach


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

GPRS attach3Gへの在圏登録



LTEIMS

(VoLTE/SMS)

3G-CS(音声/SMS)

3G-PS

データ専用の場合- combined EPS/IMSI attachでなく、EPS only attach- EPS onlyの返答が返ってくる

- CS Domain not available は網から返ってこない- LTE接続が維持される- ‘’データ専用の場合はVoLTE実装は必須でない’’

•LTE(データ専用)端末のauへの在圏登録


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


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.2W5MHz運用下:37.5Mbps上:12.5Mbps


15MHz運用下:112.5Mbps上:15Mbps


+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.684.32MHz



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


• サービス開始後に、SIMフリー端末で動作確認をしている際に発覚した問題がある

• au網を使うタイプAでは、ドコモでは気にする必要がなかった点のチューニングが必要になる

– デザリングが出来ない問題

– IP MTU問題

– 音声着呼時の発番号表示問題

– 開封直後のSIMが利用できない問題

タイプAサービスの各種問題


• デザリングが出来ない問題

• IP MTU問題

• 音声着呼時の発番号表示問題

• 開封直後のSIMが利用できない問題



• 問題

– タイプAを利用した場合にテザリングできない

• ユーザの対応策

– 端末によって状況が異なる

1. iPhone6S世代以降のSIMフリーiOS端末

-> 対応策なし

2. 一部のAndroid端末

-> IIJmioのAPN以外を全て削除することで回避可能

• 原因


テザリングが出来ない問題


1. iPhone6S世代以降のSIMフリーiOS端末問題点

1. auキャリア設定ではテザリング利用可否をauサーバで管理

2. タイプA SIMはauキャリア設定利用してしまう

3. IIJ(MVNO)にはテザリングを許可させる権限がない

4. IIJ(MVNO)からサーバにアクセスできない


au 4G LTE

インターネット

Entitlement serverstation01.ezweb.ne.jp

auユーザ

タイプA

IIJ

1. テザリング可能？-> OK

MVNOはこの経路でサーバへ到達2の問題

3の問題

4の問題


1. iPhone6S世代以降のSIMフリーiOS端末

(参考) 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 MTU1500bytesしか通らないので、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 MTU1420bytes

IP MTU1500bytes

(補足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=phone>

From: <sip:[email protected];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:[email protected]>;tag=398025e1f158dd6410c2aa2293223b35

To: <sip:[email protected]>

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:44050FPLMN:なし->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:44050FPLMN: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:44050FPLMN:なし

国際ローミングをONにすると、LTE音声端末と同様の挙動になるため、問題解消！


(再掲) 結論 – スマホ利用ユーザ向け

• IIJmioモバイルサービスタイプAを契約される方にお願い• タイプDと異なり、市場に流通する多くのSIMフリー端

末では利用できません• 下記の事項について必ず確認を行い納得の上で契約をお

願いします1. au端末はVoLTE対応でSIMロック解除が必要2. iPhone: iPhone6S世代以降の端末のみ対応3. iPhone以外: KDDI様の相互接続テストに通過した

SIMフリー端末のみ利用可能https://open-dev.kddi.com/information

4. 各種制限や問題となる事項があります詳細は本トークセッションで説明

https://open-dev.kddi.com/information


(再掲) 結論 – 端末メーカー様向け

• 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を中心に、上記を全部やってます!
