てくろぐ: アンテナピクト問題・セルスタンバイ問題とは何か

2013/9/25追記アンテナピクト問題・セルスタンバイ問題を回避する事ができるSMS対応SIMの提供を始めます。

2013/11/6追記この件についての追加の調査を行っています。Android・iOS・MVNOネットワーク (IIJmio meeting #1資料公開)セッション2も合わせてご覧下さい。

実はこの原稿、随分前から書き始めたのですが、色々あって塩漬けになっていました。正直に告白すると、調査が行き詰まったのです。状況証拠は押さえられたのですが、それが本当に原因なのか、最終的なとこまでは突き止められませんでした。ただ、今でもこの現象は発生していますし、不思議に思われている方もいらっしゃるようですので、わかっている話だけでもまとめておこうと思います。

MVNO通信サービスだとアンテナが立たない？

IIJの提供するIIJmio高速モバイル/Dを初めとして、MVNOの無線データ通信サービスが普及しています。MVNO¹とは、MNO²と呼ばれる無線通信事業者から無線通信設備を借り受けてサービスを提供する事業者のことです。たとえば、IIJmio高速モバイル/DはNTT docomoの3G(FOMA)網とLTE(Xi)網を借り受けてサービスを提供しています。この場合、IIJがMVNOで、docomoがMNOです。

無線通信部分を借り受けているため、携帯端末と基地局の間の通信は、網を貸しだしているMNOと同じ条件になります。通信に使う周波数や変調方式は一緒なので端末はMNOと同じものが使えますし、電波のエリアや強さもMNOと全く同じです。³

ですので、本来は端末(スマートフォン)をMNOで使おうが、MVNOで使おうが、基本的な動作は変わらないはず……なのですが、実際には挙動が異なる場合があります。その中でも特に目立つのが「アンテナピクト問題」「セルスタンバイ問題」と呼ばれているものです。

アンテナピクトというのは右の写真のアイコンです。説明するまでもありませんが、端末(スマートフォン)に届いている電波の強さを示しているものですね。実は、いくつかのスマートフォンでMVNOの通信サービスを使うと、電波が届いていて通信が可能なのに、アンテナピクトが表示されず、圏外のように見えるという現象が発生します。これが「アンテナピクト問題」です。

アンテナピクトは目で見てわかるためよく取り上げられますが、類似の問題が他にも確認されています。色々あるので表にまとめてみました。

現象		説明
1.	アンテナピクトが表示されない	通信はできているのにアンテナピクトが表示されない(圏外となる)
2.	データ通信ピクト⁴が表示されない	通信はできているのにピクトグラムが表示されない。
3.	待ち受け状態でバッテリーの消費が速い	端末本来の状態(MNOの契約で使っている場合)と比べて、異常に早くバッテリーが無くなってしまう
4.	「ネットワークに接続していません」ポップアップ表示が出る	ブラウザなどを起動すると「ネットワークに接続していません」と一瞬表示されることがある。しかし、画面をタップすると何事もなかったかのように動作する。

「3.待ち受け状態でバッテリーの消費が早い」について補足しておきます。Androidスマートフォンでこの現象が発生した場合、「セルスタンバイ」というプロセス(プログラム)の電力消費が多くなっているのが観測されます。⁵そのプロセス名から、この問題を「セルスタンバイ問題」と呼んでいます。また、バッテリー消耗が激しいことを指して「バッテリードレイン問題」と呼ぶ場合もあります。

ちなみに、元々セルスタンバイはバッテリーの消費が多いプロセスなので、電力の消費状況だけで問題の有無を確認するのは困難です。Androidのバージョンによっては、セルスタンバイプロセスの詳細を表示したときに「圏外時間」項目が表示される場合があり、こちらで確認する方がわかりやすいでしょう。セルスタンバイ問題が発生している際には、明らかに電波が届いているところにいる(通信ができている)のに、圏外時間が100%と表示されます。

問題が発生する端末・発生しない端末

これらの問題ですが、実は端末(スマートフォン)によって発生したり、発生しなかったりします。発生する場合でも、1～4のすべてが発生するわけではありません、端末によって状況がばらばらなのです。

たとえば、私が個人的に使っている端末で言えば、SO-03D (Xperia acro HD)では、1,2の問題は発生していませんが、3,4の問題が発生しているように見うけられます。しかし、SC-04D(Galaxy NEXUS)では、1,2,3,4全部発生しているように見えます。

どの端末でどんな問題が発生するかは、実際にその端末で実験してみないとわかりません。また、同じ端末でもOSのアップデートがあると挙動が変わることがあります。ですので、こういった問題が起こるときは、どの機種の、どのバージョンのOSかまで特定して議論を行う必要があります。

MVNOのサービスだと必ず発生するのか？

ここまで、「MVNOのサービスだと必ず問題が発生する」かのような書き方をしていましたが、実はMVNOのサービスであっても問題が発生しないケースがあります。それは、音声通話に対応したMVNOサービスを利用している場合、です。ほとんどのMVNO事業者はデータ通信専用サービスしか提供していませんので、「MVNOだと問題が起こる」と言われているのですが、そうではありません。

では、問題は「データ通信専用」のサービスをスマートフォンで使うことなのでしょうか？ところが、MNOであるdocomoのデータ通信専用サービスをスマートフォンで使った場合、問題が起こらないのです。

	MNO(docomo)	MVNO
データ+音声契約	問題なし	問題なし
データ専用契約	問題なし	問題あり

3G通信網の仕組み

問題の原因を考える前に、3G(W-CDMA)通信網の仕組みを説明します。

W-CDMA上の通信には、CS domain(Circuit Switched/回線交換)とPS domain(Packet Switched/パケット交換)が規定されています。CSは音声通信のために使われています。⁶一方、スマートフォンで使われるデータ通信はPSを使っています。

W-CDMAでは、通信端末が「待ち受け」状態になるために、基地局を管理するシステムに対して、端末が通信可能であるという「登録(Registration)」を行います。このRegistrationは、CS domain・PS domainそれぞれ別個に管理されています。CS/PSは片側だけ利用する事も、両方同時に利用することも可能です。

端末から要求されたCS/PSのRegistrationが受け付けられるかどうかは、端末から通知されるID⁷によって、携帯電話網側が判定します。端末側がRegistrationを要求しても、契約条件などにより網側でRegistrationが拒否された場合、そのdomainは利用できません。

音声+データのサービスはCSとPSの両方のRegistrationを許可しており、データ専用のサービスはPSだけを許可していると言うことになります。

さて、AndroidやiPhoneなどのスマートフォンは、通話も、データ通信も利用します。当然通話の待ち受けのためにCSを、データ通信のためにPSもRegistrationしているはずです。ごく普通にdocomoでスマートフォン用の契約をしていれば、CSもPSも許可されているはずですが、データ専用契約はPSしか許可しないはずです。これは怪しい……

契約と、CS/PSの許可状況

ところが、ここでやっかいな例外があります。「docomoのデータ通信専用契約だとアンテナピクト問題が発生しない」というやつです。もし、「CSが許可されないときに端末側で問題が発生する」のであれば、docomoであってもデータ通信専用契約で問題が発生しそうなものです。

これは、実験してみるしかありません。

実験のために、次の各契約のSIMカードを用意しました。

回線事業者	契約タイプ
IIJmio	データ専用
docomo	音声+データ(スマホ用)
docomo	データ専用(モバイルルータ用)
某MVNO	音声+データ
某MVNO	データ専用

また、CS/PSのRegistrationが許可されるかの確認には、USB接続のデータ通信端末(法人向けIIJモバイルで提供している120FU)を使います。この端末はパソコンに接続すると仮想シリアルポートとしてアクセスできるタイプで、TeraTermなどのターミナルソフトからATコマンドを送ることで制御することができます。

ATコマンドの詳細は省きますが、興味がある方は、3GPPの規格書⁸に情報がありますので、参考にして下さい。ポイントは”+CREG?”と”+CGREG”コマンドの応答です。”+CREG?”はCSのRegistration状況、”+CGREG?”はPSのRegistrationの状況を表示します。二つ目の返値が「1: Registration成功」「3: Registration拒否」を示します。⁹IIJmio高速モバイル/DのSIMでは、CSは失敗、PSのみ成功しています。想定通りです。

同じようにしてそれぞれのSIMについて確認してみたところ、次のような結果となりました。

回線事業者	契約タイプ	+CREG?(CS)	+CGREG?(PS)
IIJmio	データ専用	3:拒否	1:成功
docomo	音声+データ	1:成功	1:成功
docomo	データ専用	1:成功	1:成功
某MVNO	音声+データ	1:成功	1:成功
某MVNO	データ専用	3:拒否	1:成功

なんと、docomoのデータ通信専用契約ではCSへのRegistrationに成功しています……。不思議な話ですが、実際のそういう結果が出ているので、そうなんでしょう。¹⁰とはいえ、これで状況証拠は集まりました。状況だけ見れば、アンテナピクト等の問題が起こるかどうかは、契約がMVNOかどうかには関係なく、CSのRegistrationが許可されているかどうかに依存している可能性が非常に高いと言えます。

※追記

Twitterなどでご指摘頂きましたが、docomoのデータ通信専用サービスではSMSが利用できるという件とも関係があります。SMS(Short Message Service)はCS domainを用いて提供されるサービスですので、SMSが使えるということは、CS domainへのRegistrationは許可されているということを示しています。

SMSを利用可能にするためにCSを許可したのか、別の理由でCSを許可したからSMSが使えるのか……目的や経緯は判りませんが、目の前にあるものがそういう動作をしているのは事実です。

Androidのソースに突撃する……が、

状況証拠的にはこれでほとんど固まった感があります。ですが、この推測が正しいかどうかの裏付けはとれていません。そこで、公開されているAndroidのソースコードに当たってみることにしました。

Androidの中で3Gの通信状態を管理しているのはGsmServiceStateTrackerというクラスのようです。¹¹この中の507行目付近を見ていると、次のような記述があります。¹²

case EVENT_CHECK_REPORT_GPRS: if (ss != null && !isGprsConsistent(gprsState, ss.getState())) { // Can't register data service while voice service is ok // i.e. CREG is ok while CGREG is not // possible a network or baseband side error GsmCellLocation loc = ( (GsmCellLocation)phone.getCellLocation() ); EventLog.writeEvent(EventLogTags.DATA_NETWORK_REGISTRATION_FAIL, ss.getOperatorNumeric(), loc != null ? loc.getCid() : -1); mReportedGprsNoReg = true; } mStartedGprsRegCheck = false; break;

1
2
3
4
5
6
7
8
9
10
11
12

case EVENT_CHECK_REPORT_GPRS:
    if (ss != null && !isGprsConsistent(gprsState, ss.getState())) {
       // Can't register data service while voice service is ok
       // i.e. CREG is ok while CGREG is not
       // possible a network or baseband side error
       GsmCellLocation loc = ( (GsmCellLocation)phone.getCellLocation() );
       EventLog.writeEvent(EventLogTags.DATA_NETWORK_REGISTRATION_FAIL,
               ss.getOperatorNumeric(), loc != null ? loc.getCid() : -1);
       mReportedGprsNoReg = true;
    }
    mStartedGprsRegCheck = false;
break;

コメントを読む限り「音声サービス(CS)がRegistrationできているのにデータサービス(PS)がRegistrationできていない場合は、ネットワーク(携帯網)もしくはベースバンド(端末内の無線処理部分)のエラーかもしれない」なんてことが書いてあります。

一方、1042行目あたりを見ると、

if (! isGprsConsistent(gprsState, ss.getState())) { if (!mStartedGprsRegCheck && !mReportedGprsNoReg) { mStartedGprsRegCheck = true; int check_period = Settings.Secure.getInt( phone.getContext().getContentResolver(), Settings.Secure.GPRS_REGISTER_CHECK_PERIOD_MS, DEFAULT_GPRS_CHECK_PERIOD_MILLIS); sendMessageDelayed(obtainMessage(EVENT_CHECK_REPORT_GPRS), check_period); } } else { mReportedGprsNoReg = false; } } /** * Check if GPRS got registered while voice is registered. * * @param gprsState for GPRS registration state, i.e. CGREG in GSM * @param serviceState for voice registration state, i.e. CREG in GSM * @return false if device only register to voice but not gprs */ private boolean isGprsConsistent(int gprsState, int serviceState) { return !((serviceState == ServiceState.STATE_IN_SERVICE) && (gprsState != ServiceState.STATE_IN_SERVICE)); }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

    if (! isGprsConsistent(gprsState, ss.getState())) {
        if (!mStartedGprsRegCheck && !mReportedGprsNoReg) {
            mStartedGprsRegCheck = true;

            int check_period = Settings.Secure.getInt(
                    phone.getContext().getContentResolver(),
                    Settings.Secure.GPRS_REGISTER_CHECK_PERIOD_MS,
                    DEFAULT_GPRS_CHECK_PERIOD_MILLIS);
            sendMessageDelayed(obtainMessage(EVENT_CHECK_REPORT_GPRS),
                    check_period);
        }
    } else {
        mReportedGprsNoReg = false;
    }
}

/**
* Check if GPRS got registered while voice is registered.
*
* @param gprsState for GPRS registration state, i.e. CGREG in GSM
* @param serviceState for voice registration state, i.e. CREG in GSM
* @return false if device only register to voice but not gprs
*/
private boolean isGprsConsistent(int gprsState, int serviceState) {
    return !((serviceState == ServiceState.STATE_IN_SERVICE) &&
            (gprsState != ServiceState.STATE_IN_SERVICE));
}

とか何とか書いてあり、CSのRegistrationができているのにPSのRegistrationができていない場合の処理は何かしら考慮されているようです。

どうやら、Android2.xでは「CSが使えてPSが使えない場合は想定していても、PSが使えてCSが使えないときは異常だと判断する」ような気配が感じられます。

このあたりの動作が、アンテナピクトを初め諸々の不思議な動作に影響しているのではないか。どうもそんな気配が感じられます。が、残念ながら私の調査はここまでです。仕事の合間にちくちくとコードを追いかけていたのですが、力尽きてしまいました。

現在の到達点は、コメントとクラス名を斜め読みして「ふーん」と推測したところまでです。本当は、アンテナピクトの表示部分のコードも見て、原因を確定させなければならないのですが、私には調べきれませんでした。

余談

同じファイルの1257行目あたりにこんな記述がありまして。

/** code is registration state 0-5 from TS 27.007 7.2 */ private int regCodeToServiceState(int code) { switch (code) { case 0: case 2: // 2 is "searching" case 3: // 3 is "registration denied" case 4: // 4 is "unknown" no vaild in current baseband case 10:// same as 0, but indicates that emergency call is possible. case 12:// same as 2, but indicates that emergency call is possible. case 13:// same as 3, but indicates that emergency call is possible. case 14:// same as 4, but indicates that emergency call is possible. return ServiceState.STATE_OUT_OF_SERVICE; case 1: return ServiceState.STATE_IN_SERVICE; case 5: // in service, roam return ServiceState.STATE_IN_SERVICE; default: Log.w(LOG_TAG, "unexpected service state " + code); return ServiceState.STATE_OUT_OF_SERVICE; } }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

/** code is registration state 0-5 from TS 27.007 7.2 */
private int regCodeToServiceState(int code) {
    switch (code) {
        case 0:
        case 2: // 2 is "searching"
        case 3: // 3 is "registration denied"
        case 4: // 4 is "unknown" no vaild in current baseband
        case 10:// same as 0, but indicates that emergency call is possible.
        case 12:// same as 2, but indicates that emergency call is possible.
        case 13:// same as 3, but indicates that emergency call is possible.
        case 14:// same as 4, but indicates that emergency call is possible.
            return ServiceState.STATE_OUT_OF_SERVICE;

        case 1:
            return ServiceState.STATE_IN_SERVICE;
        case 5:
            // in service, roam
            return ServiceState.STATE_IN_SERVICE;
        default:
            Log.w(LOG_TAG, "unexpected service state " + code);
            return ServiceState.STATE_OUT_OF_SERVICE;
    }
}

これ、先ほど紹介したATコマンドの返値を解釈している部分です。この辺を少々いじってやることで、CSにRegistration失敗しているのに、成功しているように見せかけることはできそうに思われます。ただ、このメソッドはCSとPSの解釈の両方に使われているので、これを書き換えてしまうとPSの圏外/圏内判定についてもおかしくなってしまうような気もします。

Registrationとバッテリー消費

ここで、少し横道にそれますが、携帯電話・スマートフォンの無線部分の消費電力について、少し紹介しておきます。

携帯電話もスマートフォンも、一度の充電でできるだけ長時間持ち歩けるように、省電力化にはいろいろな工夫が凝らされています。無線部分で電気を食うのは電波を送受信するところですので、省電力化のために「待ち受け」状態の時は受信部分の動作を間欠的にしか行いません。通信相手の基地局と調整して、特定のタイミングだけ受信機を起動させているのです。

しかし、無線網への位置登録(Registration)を行う場合はそうは行きません。位置登録を行う際には、基地局からの電波をとらえ直すことになるので、受信機を連続してONにしておく必要があります。もちろんこんな事をすると電力の消費が大きくなります。

普通は、位置登録がそんなに頻繁に行われることはありません。端末の電源を入れた直後とか、一つの基地局の電波の届く範囲を離れ、別の基地局につなぎ直す(ハンドオーバー)のときぐらいです。

しかし、先ほど紹介したとおり、Android端末は「PSにRegistrationしているのに、CSにRegistrationできない」ときは何かのエラーとして解釈します。エラーが起こったら……リトライしますよね。つまり、CSが使えない状態に置かれたAndroid端末は、通常時よりも高頻度で位置登録を繰り返しているのではないか、そんな様子が推測できるわけです。

これも、本来であればソースコードを追いかけて裏を取るべきなのですが、そこまでには至っていません。ただ、現象から推測するに、これがセルスタンバイ(バッテリードレイン)問題の原因である可能性は高いと考えています。

再び、端末の話

さて、Androidのソースコードから「なにか怪しい」雰囲気までは感じられました。しかし、市販のAndroidスマートフォンでは前述の通り、問題が起こらない端末もあります。いったいどういうことでしょうか。

これはもう、端末を開発したメーカーがAndroidのソースに手を加えているとしか考えられません。実際、市販の端末で国内のサービスに対応するためにメーカー毎にあちこち手が入っていますので、無線部分についても何らかの修正が行われているのでしょう。そして、その修正はメーカー間で共有されておらず、ばらばらに行われていると考えると、端末毎に問題の出方が全く異なるというのも納得できます。

ちなみに、iPhoneでもアンテナピクト問題があります。(ピクトが表示されません)こちらはソースコードが一切開示されていないので調べようがありません。が、表面的な現象の類似性を考えると、もしかするとCS/PS問題なのかなという気がしてきます。

LTEに向けて

最後にLTEについての情報を補足しておきます。LTEではCS/PS問題が発生するのかどうか……実は、そもそもLTEにはCS/PSという区別がありません。PS(相当のパケット交換通信)しか存在しないのです。

LTEで音声通話を行う場合は、VoLTE(Voice over LTE)という方式で、パケット交換網上で音声通話を行う仕組みを使う事が予定されています。予定されている、というのは、実は日本国内の事業者でVoLTEのサービスを提供している事業者はまだないのです。¹³じゃあ今のLTEスマートフォンはどうやって通話しているのかというと、スマートフォンを3G\LTE両対応にしておいて、通話の時は3GのCSを使っているのです。LTEは元々従来の通信方式である3Gからのスムーズな移行を想定して作られた規格なので、通話は3G・データはLTEと言うことが問題なく行えます。

Andoridもそういうことを意識しているのか、最近のバージョンのソースコードを見ると、無線関係のところでなにやら色々書き換えられているようです。詳細は調べていません今後VoLTEが開始されると、LTEのみのスマートフォンも出てくる可能性はありますが、その頃には無線周りががらっと変わっているかもしれないですね。その時は音声通話ができない契約でも問題なく動作できるようなコードになっているといいのですが。

おつきあいありがとうございました

ここまででアンテナピクト問題・セルスタンバイ問題についての紹介は終了です。冒頭でお断りしたとおり、肝心なところで調査が中断しており、少々情けない状態ですが、とりあえず正直にわかっていることを書いてみました。皆さんの参考になれば幸いです。

本日の関連コンテンツ

え、「IIJmioでもCSにRegisrationを許可して欲しい」ですか？それができるなら私も個人的に嬉しいのですが。ぶっちゃけ無視できないレベルのコスト上昇になるそうなんですよ……うーん……

Mobile Virtual Network Operator [↩]
Mobile Network Operator [↩]
もちろんサービス内容には違いがあり、たとえば高速モバイル/Dでは、通信速度を敢えて制限する事で、月額料金を低価格に抑えるというアレンジを加えています。 [↩]
これの正式名称なんて言うのでしょう？ [↩]
Androidは設定画面から各プロセスの消費電力を確認することができます。 [↩]
回線交換を用いたデータ通信も可能ですが最近はあまり利用されていません。 [↩]
SIMカードに格納されたID [↩]
3GPP TS 27.007 [↩]
返値は1～10まで定義されています。詳しくは規格書(ry [↩]
回線交換モードのデータ通信サービスの名残でしょうか？ [↩]
リンク先はgingerbread(Android2.3)のbranchです。何しろ、調べていたのが半年以上前なので……。後述しますが、3G以外の通信手段(WiMaxやLTE)に対応するために、最近のバージョンのAndroidではこのあたりの構造が大幅に変わっているようです。 [↩]
これ以降で出てくるGSM(Global System for Mobile Communications)は、日本以外で使われている2G携帯通信規格のことです。Androidのクラス名こそGSMになっていますが、実際にはW-CDMA方式であってもこの部分で処理されています。また、GPRS(General Packet Radio Service)GSMにおけるデータ通信の規格のことです。ここではGPRSは3GのPS domainに対応すると思っておけばいいでしょう。 [↩]
世界的に見ても、韓国の2キャリアが2012/08/08に限定的にサービスを開始しただけ、です [↩]