とうほぐモバイルミーティング #2 (https://tohogu.connpass.com/event/84268/)の発表資料です。

1. 楽天MNの求める国内ローミング
接続における課題
とうほぐモバイルミーティング #2
2018/04/21
@oyaguma3

2. ■はじめに
• 楽天モバイルネットワーク（以降楽天MNと表記）が
検討している、NTTドコモへのローミング接続。
• 課題はたくさんあるが、どんなものがありそうなのか、
見える範囲で並べてみたい。
• そもそもどんなローミング接続を求めているのか？
• 日本経済新聞の記事
• ドコモを蹴った 楽天ケータイ、波高し
• https://www.nikkei.com/article/DGXMZO29375140T10C18A4000000/
以下、一部引用。
• 「だが楽天が求めているのは、全部ローミングしてくれ、というよう
な契約。これは受けられないという話になっている」
• 楽天網の未整備地域が含まれるドコモTracking Areaの
利用だけではなく、もっと密な接続形態なのでは？
→ RANシェアリングを求めているのではないか？

3. RANシェアリング

4. ■RANシェアリングについて
• 3GPP TS 23.251 にアーキテクチャの記載がある。
• ググってみると、定義されていないアーキテクチャも出てくる。
(MORAN : Multi-Operator Radio Access Networkとか)
• GWCN
• “Gateway Core Network” configuration の略称。
• ゲートウェイ設備(MME/S-GW/MSC/S-GW)とRANまで共有して、
HSS/P-GWはオペレータ個別で運用するアーキテクチャ。
• 日本におけるフルMVNOの接続形態はこれが一番近いと思われる。
（とはいえMVNOはRANを持っていないので共有とは言い難いが...）
• MOCN
• “Multi-Operator Core Network” configuration の略称。
• RANまでは共有し、ゲートウェイ設備より上はオペレータ個別で運用する
アーキテクチャ。
• RANで運用周波数が分かれるモデルは定義されていないが、どうやら
このモデルはMORANと呼ばれている模様。
• 楽天MNの求めるRANシェアリングは恐らく、MORANとMOCNの中間
（ドコモ周波数は共有、楽天MN周波数は個別）ではないか。

5. ■GWCN■GWCN （LTEのみ記載）
HSS
(OP 1)
HSS
(OP 2)
P-GW
(OP 1)
P-GW
(OP 2)
IMS
(OP 1)
IMS
(OP 2)
MME
(Share)
S-GW
(Share)
eNB
(Share)
OP1
加入者
OP2
加入者
OP1
加入者
OP2
加入者
Internet

6. ■MOCN （LTEのみ記載）
HSS
(OP 1)
HSS
(OP 2)
P-GW
(OP 1)
P-GW
(OP 2)
IMS
(OP 1)
IMS
(OP 2)
MME
(OP 1)
S-GW
(OP 1)
MME
(OP 2)
S-GW
(OP 2)
eNB
(Share)
OP1
加入者
OP2
加入者
OP1
加入者
OP2
加入者
Internet
MOCNケース MORANケース

7. 想定される課題

8. ■GWCN/MOCN共通の課題
• ドコモ加入者と楽天MN加入者の相互乗り入れ
• ドコモ加入者を受け入れるなら、最低でも楽天MNからs6a/Cx/Rxを
開放してドコモと相互接続する必要がありそう。
• 乗り入れ時の課金周り調整はかなり難航しそう...
• 多分やらない。
• 事業者を渡るモビリティの整備
• 楽天MNのエリア端で位置登録／更新のピンポン移動が発生して余計な
シグナリング負荷が発生し得る。
• 楽天MNとしてはドコモ網にリダイレクションする制御は必要だが、
ドコモからすると楽天加入者の押し付けに見える。
• 端末のPLMN SelectionやCell Selectionを踏まえて、楽天MN網に優先
して在圏するよう、eNB／SIMのチューニングが必要。

9. ■GWCN時の課題
• 楽天MN設備がS6a/S5/S8をドコモ仕様に合わせる
必要がある。
• IMS関連を除けば、実質的にフルMVNOとしての接続と同じのはず。
よって、事業者間接続でPOIを持つノードは、ドコモとの接続試験が
必要になり、その対応のための追加開発が発生する。
• ドコモからすると一度蹴られた接続形態を再協議するようなもので、
心情的にも受け入れられがたいと思われ...
• 位置登録・更新時のTA IDやCell IDなど在圏情報を通知してもらえ
ない可能性もある（機密情報と思われるため）
• 事業者間移動で呼断が発生し得る
• RANが分断されているので、楽天MN網在圏からドコモ網に移動する
(逆も然り)と、旧在圏MMEからUE情報を取得できず位置更新を弾く
ことになり、端末の再Attachによる呼断が発生すると思われる。

10. ■MOCN時の課題
• GWCN時より密接にIF繋ぎ込みが必要。
• 何ら開放されていないIFを協議して開放してもらう必要がある。
一番重要なのはS1インターフェースだが、RANの肝でもあるため、
ドコモが開放に応じてくれるとは到底思えない...
• S1開放はTracking Area設計に影響してNW最適化にも絡むため、
ドコモ自身の網キャパシティ改善業務に影響する懸念がある。
• ドコモeNB/RNC/BTSにもかなりの改修（網改造）が必要
• ドコモ基地局から楽天MNのPLMNも吹いてもらわねばならないが、
報知情報に手を入れるということは局データの変更を伴う。
• シームレスな事業者間ハンドオーバーを実現したい場合、楽天MNと
ドコモの間で近隣セルテーブル（HO先候補）を共有せねばならず、
再接続時のUE情報保持タイマ管理など、かなりきめ細かい設定の
再チューニングも必要になる可能性が高い
• 楽天MNが「ドコモ網のTracking AreaとCell ID」でTA設計・運用
する必要あり。報知情報（SIB1）の仕様上、PLMNごとにTA IDと
Cell IDを分けられるのはRelease 14以降のため。
• 楽天MME/S-GWとドコモeNBの接続試験が必要だが、ドコモeNBは
マルチベンダ運用であり、試験規模が膨れ上がることが想定される。
→ 仮にIF開放されたとしても莫大な網改造費を要求される上、
楽天MN側の追加開発の規模も膨れ上がると容易に想像される...

11. その他の課題

12. ■その他の課題（１）
• MOCNでないとシームレスハンドオーバーは無理
• MME／eNBレベルで連携できている必要がある。
近隣セル情報を相互に持っていないとそもそもHO候補先測定すら
端末に指示できないので。
• シームレスHOでなくRelease with Redirection（RwR）で良いなら、
楽天MNからドコモへのモビリティは実現できる可能性はある。
例えば、受信品質悪化でのevent A2トリガーを仕込み、品質悪化で
近くのドコモ網にRwRする、など。
• ただしRRC Connection Releaseは、リダイレクト先のEARFCNは
指定できても、PLMNごとの指定はできないので運用に注意が必要。
• SIMパラメータ関連
• 端末でデータローミング設定をONにせず別PLMNに繋がせようとする
には、EF_EHPLMNにドコモPLMN（440-10）を入れる必要がある。
• しかし、これはドコモ網もHome PLMNと扱うことを意味するため、
端末のPLMN Selectionで楽天MN網を優先させることも困難になる。
• ドコモ網に一旦AttachしてしまうとRegistered PLMNが440-10と
なるため、その後のPLMN Selectionで440-10が優先的に選択されて
しまう課題もある。
→ EF_LRPLMNSIを適切に使えば若干マシになるかも？

13. ■その他の課題（２）
• 3Gノードの繋ぎ込み
• 楽天MNは3G設備を持たないが、ドコモ網は3G網も運用中。
楽天MN加入者を利用させたいなら、3G設備との相互接続も必要。
• 仮に利用させるとして、3G在圏の楽天MN加入者への音声通話着信は
かなりハードルが高そう。
楽天MN網IMS設備とドコモMSC間にシグナリング変換GWでも置く
べきかもしれない？
• ドコモ3G網ではMulti PDNが使えないため、LTE → 3GのInter RAT
移動時にはIMSベアラのEPS contextが解放され、音声通話中なら
SRVCCが走る。
3G繋ぎ込みで音声通話も対応したい場合は、このシチュエーションで
発生する上記動作とこれに伴うドコモ網の設備構成・仕様を確認して
楽天MN網設備の追加・改修が必要になる。
• そもそも東京オリンピック後に3G網は畳んでいきたいとコメントして
いる状況で、3G網の追加開発をドコモが受けるかどうか...
（受けるとしても莫大な網改造費と長大な開発期間を要求されそう）

14. まとめ（らしきもの）

15. ■色々書いたものの...
• そもそもシェアリングではなく緊急対応的ローミング
• ドコモの心情は最初に挙げた日経新聞記事の通り
• シームレスな接続が可能なパターンは接続先事業者の
開放IF数と情報開示量が多すぎる
• 協議も長引く。
• 網改造費用も高騰する。
• 双方の開発に要する期間も長くなる。
→ 分かってはいたが現実的には非常に厳しい...
と思われる。

16. ■参照した仕様ドキュメント
• 3GPP
• TS 23.251
• RANシェアリングのアーキテクチャとか仕様とか。
• TR 22.852
• RANシェアリングのユースケースや要求事項とか。
• TS 24.008 / TS 24.301
• NASレイヤ関連
(AttachとかTA Updateなど位置登録関連、EPS/PDP接続はこの辺。分量多い)
• TS 25.331 / TS 36.331
• RRCレイヤ関連
(HO動作とかMeasurement関連はこの辺だがとにかく分量が多い)
• TS 23.122
• Idle状態時の端末関連NASレイヤ関連機能
（PLMN Selectionはこの辺）
• TS 25.304 / TS 36.304
• Idle状態の端末動作
（Cell Selectionはこの辺）
• TS 31.102
• USIM関連