Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 開幕SIMがB41に入れない仕組みについて
Similar a 開幕SIMがB41に入れない仕組みについて (18)
Más de とうほぐモバイルミーティング
開幕SIMがB41に入れない仕組みについて
- 2. ■開幕SIMってそもそも何？ • 日本通信が提供する「ソフトバンク回線のMVNO サービス」を利用するSIM（のデータ専用SIM） – http://www.bmobile.ne.jp/sb/index.html – U-NEXTも「U-mobile S」としてサービス提供中。 ※今回使用した回線は「U-mobile S」のSIM。
- 3. ■開幕SIMがBand 41を使えない理由 • Band 41を運用しているのはSofbankではなく Wireless City Planning（以降WCPと表記） • Softbankは「Wireless City PlanningのMVNO」として、 自社網と接続していることになる。 – ちなみにau MVNOのケースでは、au-UQ間で結んでいる契約の 関係でWiMAX2+（という名のTD-LTE B41）が使用可能ということ らしい。 • 公式「MVNOとして事業をご検討の事業者さまへ」 – https://www.softbank.jp/corp/group/sbm/public/mvno/operator/ – MVNOさま向け標準プランに「4G通信サービスの通信方式は AXGP方式を除きます」と記載された箇所がある。
- 5. ■どんな仕組みか • idle時とConnected時でそれぞれの仕組みが存在しつつ、 両方を組み合わせて運用する必要がある。 • Idle時 – 位置更新（Tracking Area Update）動作をトリガーにした Band 41エリアでのReject処理。 ※ 基本的にはローミング接続時に網から弾く処理に近い。 • Connected時 – ハンドオーバー用の測定対象にBand 41を含めない処理。 ※ そもそもBand 41をハンドオーバー対象にしない、というだけ。 測定対象に含めない処理はかなりの推測を含むため、 今回の説明では割愛。
- 6. ■仕組みの片方だけだと... • Idle時の仕組みだけだと... – Connected時のセル間移動は原則としてハンドオーバーのみ。 ハンドオーバーの制御は基地局（eNB）が実施。 – 基地局側でも「回線種別から」B41許可／不可を識別できないと、 B41接続不可SIMをB41対応端末に挿したケースで、B41に遷移 させてしまう状況が発生してしまう。 • Connected時の仕組みだけだと... – B1 / B3 / B8 / B11 / B41の報知情報全てにB41のセルサーチ用 パラメータが含まれており、B41対応端末だと、B41セルがサーチ 対象に入ってしまう。 – そもそも報知情報は、専用の共通チャネルで広報されているので、 特定の端末や回線契約にだけ隠す、ということはできない。 – 圏外から復帰するケースだと端末は報知情報関係なくサーチする ので、運悪く（運良く？）B41を見つけたら接続しに行ってしまう。
- 8. ■仕組みの概要（Idle時） • 位置更新（Tracking Area Update）動作をトリガーにした Band 41エリアでのReject処理 • B41のTracking Areaに入った時に、端末がTA Update処理を実行する ようなパラメータが設定されている。 • もし、B41のTracking Areaに所属するセルでTAU Requestが上がって きたら、EMM causeに「#15 No suitable cells in tracking area」を持つ TAU Rejectを返す。 • このcauseを受けた端末はセルサーチを行って、在圏できる他のセルを 探しに行くが、Rejectを受信したTracking Area以外なら、同じ事業者の セルを在圏先にすることもできる。 （そして結果的に、B1やB8のセルに在圏することになる）
- 9. ■流れを説明する前に（その１） • 用語やシステムについての補足 – Tracking Area（TA） LTEネットワーク上のエリア区分を指すが、このエリア単位で着信の 呼び出し信号（Paging）が送出される。1つあるいは複数のMMEに 属しており、地域単位や周波数単位で分かれていることが多い。 • Tracking Areaには識別番号が振られており、これをTA Code（TAC）と呼ぶ。 TACは0x0000-FFFFの値を取るが、0000とFFFEは使用されない。 PLMNとセットで用いる場合は、TAI（TA Identifier）と呼ぶ。 • セルの報知情報にはTACとCell IDが含まれている。 • GSM / UMTSではLocation Area（LA）やRouting Area（RA）という名称になる。 – Tracking Area Update（TAU） その名の通り「端末が在圏しているTracking Areaの更新」処理。 「位置更新」と呼んだりもする（らしい） • 電源ON時から見て最初のTAU処理がいわゆる「Attach」である、と理解すると 分かりやすい。 • セル遷移時にセルのTACを確認して、自分の在圏していたTAと異なっていた 場合、端末はTracking Area Update処理のトリガーを引く。 • なお、Connected時もTAU処理は発生する。 • ちなみに3G遷移時などRATをまたぐ場合も、位置更新のトリガーとなる。
- 10. ■流れを説明する前に（その２） • Tracking Area Update処理で今回関係する部分 ※ この処理自体は他にも色々とやっていること多いので割愛 – 在圏しているTracking Area（TA）の更新 • NW側から見て「端末がどこにいるか」の情報を、TAレベルで更新する。 • 同時に、NW側から端末へ「現在の在圏TAがどこであるか」を通知する。 • キーとなるポイント – 「現在の在圏TAがどこであるか」は、TACで通知される。 しかし、在圏TAは複数のTAC（どころかTAI）で構成できる。 – そのため、在圏TAの通知に「TAI List」というパラメータが用いられる。 TAI Listは例えば、以下のような構成で通知される。 • PLMN 1 : 440 20 TAC 1 : 1813 TAC 2 : 300C TAC 3 : 9F01 – これを受け取った端末は、現在の在圏TAはTAC : 1813 / 300C / 9F01 だと 認識することになる。 これらのTACを含むセルに在圏する限り、端末はTAU処理をトリガーしない。 （ただし、idle状態で一定時間同じセルに居続けると、存在確認のための定期TAUはトリガーされる）
- 11. ■流れを説明する前に（その３） MME 1 MME 2 MME 3 eNB 1 eNB 2 eNB 3 eNB 4 eNB 5 eNB 6 TAC:1813 TAC:9F01 TAC:300C TAC:9F01 CID:A543D098 TAC:9F01 CID:A543D099 TAC:9F01 CID:A543D09A TAC:1813 CID:1CA20570 TAC:1813 CID:1CA20571 TAC:1813 CID:1CA20572 TAC:1813 CID:1CA20573 TAC:1813 CID:1CA26472 TAC:1813 CID:1CA26473 TAC:1813 CID:1CA26474 TAC:1813 CID:1CA26475 TAC:1813 CID:8E9AF180 TAC:1813 CID:8E9AF181 TAC:1813 CID:8E9AF182 TAC:1813 CID:8E9AF183 TAC:300C CID:338B2944 TAC:300C CID:338B2945 TAC:300C CID:338B2946 TAC:300C CID:338B2947 TAC:300C CID:338B10CD TAC:300C CID:338B10CE TAC:300C CID:338B10CF Tracking AreaTracking AreaTracking AreaTracking Area観点でのNWNWNWNW構成例 （あくまで例です、念のため。実際はCACACACAの兼ね合いとかでもっと複雑） Band 41 Band 1 Band 1 Band 8 Band 3 Band 3
- 12. 実際の流れは？
- 13. ■TA Update成功ケース（SB純正/Yモバ） UE eNB MME 遷移先セルの報知情報を受信 Idle中にセル遷移 報知情報でTAC確認 無線区間の接続処理を実施 前に在圏していたTACと自分のGUTI（識別子）を含めて 「Tracking Area Update Request」を送信 登録済TAI ListのTACと セルのTACを比較 TACが異なるので TAU処理をトリガー 「Tracking Area Update Request」を転送 上がってきたユーザ情報を 確認して在圏可否を判定 在圏OKなので 新規TAI Listを構成新規TAI ListとGUTIを載せて 「Tracking Area Update Accept」を送信新規TAI LsitとGUTIを「Tracking Area Update Accept」で 受領 登録済みTAI List（旧） TAC1 : 1813 TAC2 : 9F01 報知情報のTAC : 9F029F029F029F02 （Band 41） 新規TAI List TAC1 : 1813 TAC2 : 9F029F029F029F02 登録済TAI Listを更新 登録済みTAI List（新） TAC1 : 1813 TAC2 : 9F029F029F029F02
- 14. ■TA Update未発生ケース（SB純正/Yモバ） UE eNB MME 遷移先セルの報知情報を受信 Idle中にセル遷移 報知情報でTAC確認 登録済TAI ListのTACと セルのTACを比較 TACが同じなので そのままIdleで在圏 登録済みTAI List（旧） TAC1 : 1813 TAC2 : 9F02 報知情報のTAC : 9F029F029F029F02 （Band 41） 在圏継続
- 15. ■Rejectケース（ソフトバンクMVNO回線時）その１ UE eNB MME 遷移先セルの報知情報を受信 Idle中にセル遷移 報知情報でTAC確認 無線区間の接続処理を実施 前に在圏していたTACと自分のGUTI（識別子）を含めて 「Tracking Area Update Request」を送信 登録済TAI ListのTACと セルのTACを比較 TACが異なるので TAU処理をトリガー 「Tracking Area Update Request」を転送 上がってきたユーザ情報を 確認して在圏可否を判定 在圏NGだが回線利用OK なのでEMM Cause #15で Rejectする EMM Cause #15を載せて 「Tracking Area Update Reject」を送信 「Tracking Area Update Reject」でEMM Cause #15受領 登録済みTAI List TAC1 : 1813 報知情報のTAC : 9F019F019F019F01 （Band 41） 次スライドに続く
- 16. （１） 「その１」スライドのBand 41Band 41Band 41Band 41セルが最良だった場合………… ■Rejectケース（ソフトバンクMVNO回線時）その２-１ UE eNB MME EMM Cause #15を受けて 在圏をあきらめて セルサーチ開始 端末の対応Bandに応じて 受信品質の良いセルを リストアップ 最良セルの報知情報を受信 報知情報でTAC確認 報知情報のTAC : 9F019F019F019F01 （Band 41） Reject時のTACと同じで あるため、次点のセルを サーチ 報知情報を受信 報知情報でTAC確認 報知情報のTAC : 1813181318131813 （Band 8） TACが同じなので そのままIdleで在圏 報知情報受信＆TAC確認を繰り返して最適セルをサーチし続ける
- 17. （２） TAC : 300CTAC : 300CTAC : 300CTAC : 300Cを持つBand 3Band 3Band 3Band 3セルが最良だった場合………… ■Rejectケース（ソフトバンクMVNO回線時）その２-２ UE eNB MME EMM Cause #15を受けて 在圏をあきらめて セルサーチ開始 端末の対応Bandに応じて 受信品質の良いセルを リストアップ 最良セルの報知情報を受信 報知情報でTAC確認 報知情報のTAC : 300C300C300C300C （Band 3） 登録済TAI ListのTACと セルのTACを比較 Reject時のTACと異なる ＆登録済TAI Listに無い TACであると確認 TACが異なるので TAU処理をトリガー TAU処理を実施
- 18. （３） TAC : 1813TAC : 1813TAC : 1813TAC : 1813を持つBand 8Band 8Band 8Band 8セルが最良だった場合………… ■Rejectケース（ソフトバンクMVNO回線時）その２-３ UE eNB MME EMM Cause #15を受けて 在圏をあきらめて セルサーチ開始 端末の対応Bandに応じて 受信品質の良いセルを リストアップ 最良セルの報知情報を受信 報知情報でTAC確認 報知情報のTAC : 1813181318131813 （Band 8） 登録済TAI ListのTACと セルのTACを比較 Reject時のTACと異なる ＆登録済TAI Listにある TACであると確認 TACが同じなので そのままIdleで在圏
- 19. Attachからの流れは？
- 20. ■Attach時からRejectされるケース その１ UE eNB MME 最良セルの報知情報を受信 端末の電源ON Attach処理を開始 無線区間の接続処理を実施 最後に在圏していたTACと自分のGUTI（識別子）を含めて 「Attach Request」を送信 最初の接続であることを通知し「Attach Request」を転送 上がってきたユーザ情報を 確認して処理可否を判定 処理NGと判定 EMM Cause #15で Rejectする EMM Cause #15を載せて 「Attach Reject」を送信 「Attach Reject」でEMM Cause #15受領 次スライドに続く SIMカードのIMSIを 読み込んでPLMN等を 確認し、セルサーチ開始
- 21. TAC : 1813TAC : 1813TAC : 1813TAC : 1813を持つBand 8Band 8Band 8Band 8セルが最良だった場合………… ■Attach時からRejectされるケース その２ UE eNB MME EMM Cause #15を受けて 在圏をあきらめて セルサーチ開始 端末の対応Bandに応じて 受信品質の良いセルを リストアップ 最良セルの報知情報を受信 報知情報でTAC確認 報知情報のTAC : 1813181318131813 （Band 8） Reject時のTACと異なる Attach処理を再試行 次スライドに続く 無線区間の接続処理を実施 最後に在圏していたTACと自分のGUTI（識別子）を含めて 「Attach Request」を送信 最初の接続であることを通知し「Attach Request」を転送
- 22. ■Attach時からRejectされるケース その３ UE eNB MME OKと判定し処理継続 HSSへ加入者認証に 必要な情報を転送 加入者認証を実施し、認証OK 端末－NW間のセキュリティ設定を確立 上がってきたユーザ情報を 確認して処理可否を判定 HSSで在圏OKと判定後 TAI Listを構成 新規TAI ListとGUTIを載せて 「Attach Accept」を送信 新規TAI LsitとGUTIを「Attach Accept」で受領 新規TAI List TAC1 : 1813TAI Listを更新＆ GUTIを更新 登録済みTAI List TAC1 : 1813 「Attach Complete」を送信 「Attach Complete」を転送 Attach完了
- 23. まとめ
- 24. ■まとめ • LTEの基本的な移動管理システムに沿った仕組みを用いて、 ソフトバンクMVNO回線のB41セル利用を抑止している。 → 独自仕様は必要ないが、MMEやHSSに若干の開発が 必要だっただろうと推測される。 • 端末がB41に対応していても、B41に在圏できない仕組みと なっている。 → ユーザに見えないレベルで接続を試みているがすぐに 弾かれている。 • 端末側の設定は特に必要なく、NW側が適切なパラメータを 通知すれば、技術仕様に則った動作の組み合わせで実現。 → つまり、ほぼ全ての端末で動作する。
- 25. ■参照仕様／参考資料 • 3GPP – TS 23.003 – TS 24.301 / TS 24.008 – TS 36.331 – TS 36.304 • NTTドコモ テクニカル・ジャーナル Vol.19 No.1 「LTEを収容するコアネットワーク（EPC）を支える技術」 [ End of document ]