NTMobile の経路生成方式の提案

黒宮 魁人^†∗，清水 一輝^†，鈴木 秀和^†，内藤 克浩^‡，渡邊 晃^† (^†名城大学，^‡愛知工業大学)

A Study on Route Generation of NTMobile for Smart Devices

Kaito Kuromiya^†, Kazuki Shimizu^†, Hidekazu Suzuki^†, Katsuhiro Naito^‡, Akira Watanabe^† (^†Meijo University,^‡Aichi Institute of Technology)

1 はじめに

スマートデバイスの普及に伴いモバイルデータトラフィックの 爆発的な増加が見込まれている．そこでデータオフロードによ る通信負荷の低減が求められているが，IPネットワークでは接 続先が変わると通信が断絶する問題と，インターネット側から NAT配下の端末へ通信を開始できない問題が存在する．これら の問題を解決する技術としてNTMobile(Network Traversal with Mobility)[1]がある．本稿ではスマートデバイスに対するサービ スとしてGoogle Inc.が提供するFCM(Firebase Cloud Messaging) を利用し，スマートデバイスに実装したNTMobileの通信経路生 成方式について提案する．

2 NTMobileとFCM

<2・1 >NTMobile概要 NTMobileは，インターネット上に設

置されたDC(Direction Coordinator)とNTMobileを実装した端 末(以後NTM端末)によって構成される．DCは端末情報の管理 と通信経路の指示を行う．NTM端末は，起動時にDCに実IPア ドレスを登録し，位置に依存しない仮想IPアドレスを受け取る．

NTM端末が通信を行う際，アプリケーションは仮想IPアドレ スを用いてセッションを確立するが，実際の通信は仮想IPアド レスに基づいたパケットを実IPアドレスでカプセル化する．こ れにより実IPアドレスの変化をアプリケーションに対して隠蔽 する．

<2・2 >FCM概要 FCMは，Google Inc.の提供するAndroid OS とiOS間でクロスプラットフォーム化されたプッシュ通知機能 である．Google Inc.が提供するFCMサーバとアプリケーション 開発者が設置するサーバ(以後アプリサーバ)によって構成され る．スマートデバイスへの通知は，アプリサーバからFCMサー バを経由し，クライアントに通知したいデータを送信することで 実現する[2]．FCMから送信されたプッシュ通知メッセージは，

スマートデバイスのアプリケーション起動トリガーとして使用 することが可能である．FCMはGCM(Google Cloud Messaging) の機能を継承しており，OSレベルでのKeep Aliveを行える．そ のためNAT配下に置かれた端末に対して通知を行うことがで きる．

3 提案方式

Fig.1にFCMを用いた提案方式の動作シーケンスを示す．

MN(Mobile Node)はWi-Fiを用いてIPv4ネットワークに接続 したスマートデバイスであり，CN(Correspondent Node)はLTE ネットワークに接続したスマートデバイスである．モバイル ネットワークで使用されるNATはFull Cone NATであるた め，Fig.1におけるNATCNはFull Cone NATである．本稿では FCMを利用する際に必要なアプリサーバの機能をDCに組み 込み，DCがFCMサーバに送信するメッセージをNotification Request，FCMサーバからCN に送信するプッシュ通知メッ

Autonomous Tunnel Response Hole Punch

Encapsulated Packet Autonomous Tunnel Request

Route Direction Direction Request

MN NATMN DC FCM Server NATCN CN

LAN WAN WAN LAN

Notification Request

Notification

ACK Route Direction

LTE

Fig1 Sequence of proposed method using FCM

セージをNotificationとする．提案方式では，MNが経路要求 としてDirection RequestをDCに送信するまでの処理は従来の NTMobileの動作と同じである．DCがCNに経路を指示する Route Directionを送信するため，まずFCMサーバにNotification Requestを送信する．FCMサーバは，Notification Requestに格納 されている情報をNAT配下に存在するCNにNotificationとし て送信する．Notificationをアプリケーション起動トリガーとし てCNはNTMobileを起動する．その後CNは，Hole Punchを DCに送信することで，DCからRoute Directionを受信すること ができるようになる．DCは，Route Directionに対するACKを 確認した後に，MN宛のRoute Directionの中にNAT_CNのポー ト番号を格納して送信する．その後MNは，Autonomous Tunnel

Requestと呼ばれるUDPトンネル構築を開始するためのパケッ

トをNATCN のポート番号に向けて送信する．NATCNはFull Cone NATであるので，Autonomous Tunnel RequestはCNに到 達する．CNはAutonomous Tunnel Responseを返信することに より，UDPトンネルの構築が完了する．以上より，FCMを利用 したNTMobileの通信経路が構築できる．

4 まとめ

本稿ではFCMを用いることにより，スマートデバイスにおけ

るNTMobileの通信経路生成方式について提案した．今後は提案

方式を実装し，性能評価を行っていく．

文 献

[1] 納堂．他：情報処理学会論文誌Vol.54, No.1, pp.394–403, 2012.

[2] Firebase Cloud Messaging - Google

<https://firebase.google.com/?hl=ja>(accessed 2017-6-15)

スマートデバイスにおける

NTMobile の経路生成方式の提案

黒宮 魁人

†

†

†

‡

†

†

‡

/

研究背景

•

Ø

•

Ø

•

Ø

Ø

1

あらゆるネットワークで移動透過性と通信接続性を実現する技術

NTMobile(Network Traversal with Mobility)

/

研究の目的

2

研究の目的

スマートデバイス向けに提供されているプッシュ通知機能を利用して スマートデバイスに適した

NTMobile

プッシュ通知機能を利用した経路方式の利点

• NTMobile

KeepAlive

Ø

• NTMobile

現在，

10

1

Keep Alive

/

Firebase

プッシュ通知機能とは

•

Ø

•

3

GCM:Google Cloud Messaging FCM:Firebase Cloud Messaging

APNs:Apple Push Notification service

/

Firebase

Firebase Cloud Messaging（FCM）

•

Ø

4

Application Server FCM Server

NAT

Smart Device

Registration

Send ID ID

Notification Request

Notification

OS

Keep Alive

参考

: https://firebase.google.com/?hl=ja

/

Firebase

Firebase Cloud Messaging（FCM）

•

Ø

5

Application Server FCM Server

NAT

Smart Device

Registration

Send ID ID

Notification Request

Notification

OS

Keep Alive

参考

: https://firebase.google.com/?hl=ja

/

Firebase

Firebase Cloud Messaging（FCM）

•

Ø

6

Application Server FCM Server

NAT

Smart Device

Registration

Send ID ID

Notification Request

Notification

OS

Keep Alive

参考

: https://firebase.google.com/?hl=ja

/

Firebase

Firebase Cloud Messaging（FCM）

•

Ø

7

Application Server FCM Server

NAT

Smart Device

Registration

Send ID ID

Notification Request

Notification

OS

Keep Alive

参考

: https://firebase.google.com/?hl=ja

/

Firebase

Firebase Cloud Messaging（FCM）

•

Ø

8

Application Server FCM Server

NAT

Smart Device

Registration

Send ID ID

Notification Request

Notification

OS

Keep Alive

参考

: https://firebase.google.com/?hl=ja

/

NTMobile

Virtual Dual Stack Network NTMobile概要

•

Ø

9

Dual Stack Network

DC RS

NAT IPv6 Network

IPv4 Global Network

仮想

IP

IPv4 Private Network

DC,RS

Dual Stack Network

IPv4-IPv6

RS

Application

IP

DC:Direction Coordinator RS:Relay Server

/

NTMobile

NTMobileのシーケンス

10

MN

NAT

DC RS

NAT

CN

Keep Alive Keep Alive

Direction Request

Relay Direction ACK Route Direction Route Direction

Tunnel Request

Hole Punch ACK

Tunnel Request

Tunnel Response Tunnel Response

10

Keep Alive

/

NTMobile

参考:NATの制約

Symmetric NAT

Port-Restricted Cone NAT

Address-Restricted Cone NAT

Full Cone NAT

11

Cone

NAT

弱 制約

/

NTMobile

NTMobileのシーケンス（自律的経路最適化）

12

MN

NAT

DC RS

NAT

CN

Keep Alive Keep Alive

Direction Request

Relay Direction ACK Route Direction Route Direction

Autonomous Tunnel Request

Autonomous Tunnel Response

納堂

.

:

Vol.54, No.1, pp.394–403, 2012.

Tunnel Request

Tunnel Request

Tunnel Response Tunnel Response

自律的経路最適化について

•

NAT

Cone

NAT

•

NAT

%

Cone

NAT

•

Full Cone NAT

RS

制御パケットを投げ合う．

制御パケットが到達した場合は

RS

/

提案方式の実装方法

13

実装方法

NTMobile

DC

Direction Coordinator

FCM

Application Server

DC FCM Server

NAT

Smart Device

Registration Send ID

Notification Request

Notification

OS

Keep Alive

/

提案方式

Mobile Network IPv4 Private Network

Internet 提案方式のシーケンス図

14

MN

NAT

DC

NAT

CN

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

Direction Request

Internet-Mobile Network

NAT

Full Cone NAT

/

提案方式のシーケンス図

15

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

NTMobile

Keep Alive

/

提案方式のシーケンス図

16

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

/

提案方式のシーケンス図

17

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

OS

Keep Alive

NAT

CN

NTMobile

/

提案方式のシーケンス図

18

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

/

提案方式のシーケンス図

19

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

/

提案方式のシーケンス図

20

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

/

提案方式のシーケンス図

21

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

ACK

CN

NAT

/

提案方式のシーケンス図

22

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

3G/LTE

全て自律的経路最適化が可能．

Route Direction

CN

NAT

/

提案方式のシーケンス図

23

MN

NAT

DC

NAT

CN

Direction Request

Notification Request

Route Direction Route Direction

Autonomous Tunnel Request

Hole Punch

ACK

Autonomous Tunnel Response FCM Server

Notification

LTE

/

まとめ

•

Ø

p NTMobileが行うKeep Aliveを省略

ü スマートデバイスの低消費電力化を実現

p NTMobileのシグナリング処理の簡単化

p 自律的経路最適化によるRSを経由しない通信

•

Ø

Ø

Ø

素材

: http://www.wanpug.com/illust/

/30

GCMではなくFCMを利用する理由 補足

•

Ø

•

Ø

•

25

参考

: http://qiita.com/srea/items/f0836a0857cab743a94a https://stackoverflow.com/questions/37311188/

migration-from-gcm-to-fcm-needed

https://firebase.google.com/support/faq/#gcm-fcm

/30

For iOS 補足

•

画像引用

:https://developers-jp.googleblog.com/2017/02/

debugging-firebase-cloud-messaging-on.html

/30

CNがWi-fiに接続している場合 補足

•

Ø

•

Ø

•

Ø

•

27

/30

NATの型について 補足

引用

:

.

:

Vol.54, No.1, pp.394–403, 2012.

外部端末によらず 通過

アドレス整合性を チェック

アドレス/ポート整 合性をチェック

マッピング生成規 則

外部端末によらず

同一 Full Cone *Restricted Cone Port Restricted Cone

アドレス単位

Symmetric アドレス/ポート単

位

フィルタリング特性

外部端末から

NAT

マッピング生成規則

NAT

NAT

NAT

*Restricted Cone NATはAddress Restricted Cone NATと等価

/30

関連研究と課題 補足

•

Ø

p HAは通信の中継を行う

Ø

29

DSMIPv6

•

HA

HA

• IPv4

NAT

HA

Ø HA

IP

/30

関連研究と課題 補足

•

Ø

Ø

30

HIP

• ICE

•