Contenu connexe
Similaire à 開幕SIMがB41に入れない仕組みについて (18)
Plus de とうほぐモバイルミーティング (8)
開幕SIMがB41に入れない仕組みについて
- 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方式を除きます」と記載された箇所がある。
- 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. ■流れを説明する前に(その1)
• 用語やシステムについての補足
– 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. ■流れを説明する前に(その2)
• 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. ■流れを説明する前に(その3)
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
- 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)
在圏継続
- 16. (1) 「その1」スライドのBand 41Band 41Band 41Band 41セルが最良だった場合…………
■Rejectケース(ソフトバンクMVNO回線時)その2-1
UE eNB MME
EMM Cause #15を受けて
在圏をあきらめて
セルサーチ開始
端末の対応Bandに応じて
受信品質の良いセルを
リストアップ
最良セルの報知情報を受信
報知情報でTAC確認 報知情報のTAC : 9F019F019F019F01 (Band 41)
Reject時のTACと同じで
あるため、次点のセルを
サーチ
報知情報を受信
報知情報でTAC確認 報知情報のTAC : 1813181318131813 (Band 8)
TACが同じなので
そのままIdleで在圏
報知情報受信&TAC確認を繰り返して最適セルをサーチし続ける
- 17. (2) TAC : 300CTAC : 300CTAC : 300CTAC : 300Cを持つBand 3Band 3Band 3Band 3セルが最良だった場合…………
■Rejectケース(ソフトバンクMVNO回線時)その2-2
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. (3) TAC : 1813TAC : 1813TAC : 1813TAC : 1813を持つBand 8Band 8Band 8Band 8セルが最良だった場合…………
■Rejectケース(ソフトバンクMVNO回線時)その2-3
UE eNB MME
EMM Cause #15を受けて
在圏をあきらめて
セルサーチ開始
端末の対応Bandに応じて
受信品質の良いセルを
リストアップ
最良セルの報知情報を受信
報知情報でTAC確認 報知情報のTAC : 1813181318131813 (Band 8)
登録済TAI ListのTACと
セルのTACを比較
Reject時のTACと異なる
&登録済TAI Listにある
TACであると確認
TACが同じなので
そのままIdleで在圏
- 21. TAC : 1813TAC : 1813TAC : 1813TAC : 1813を持つBand 8Band 8Band 8Band 8セルが最良だった場合…………
■Attach時からRejectされるケース その2
UE eNB MME
EMM Cause #15を受けて
在圏をあきらめて
セルサーチ開始
端末の対応Bandに応じて
受信品質の良いセルを
リストアップ
最良セルの報知情報を受信
報知情報でTAC確認 報知情報のTAC : 1813181318131813 (Band 8)
Reject時のTACと異なる
Attach処理を再試行
次スライドに続く
無線区間の接続処理を実施
最後に在圏していたTACと自分のGUTI(識別子)を含めて
「Attach Request」を送信
最初の接続であることを通知し「Attach Request」を転送
- 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 ]