Rich Communication Services における Presence

平成 26 年度
修士学位論文
Rich Communication Services にお
ける Presence Service 実現に関する
研究
A Study on Presence Service implementation in
Rich Communcation Services
1175069
小笠原 一聡
指導教員
島村 和典
2015 年 2 月 3 日
高知工科大学大学院 工学研究科 基盤工学専攻
情報システム工学コース
要 旨
Rich Communication Services における Presence Service 実現
に関する研究
小笠原 一聡
近年, 次世代ネットワーク（Next Generation Network）の導入が進んでいる. Next
Generation Network を実現するための技術として IP Multimedia Subsystem が国際標
準に採用されている. その中で基本サービスとして期待されている Rich Communication
Services は利便性・快適さをユーザに提供し, 次世代ネットワークの標準サービスになる
とされている. RCS とは電話・メールにとって代わる基本コミュニケーションサービス
の群である. 群には 7 種類のサービスがあり, Instant Message, Short Message Service,
Multimedia Message Service, Presence Service, Voice Call, Video Share, Image Share
である.
本稿では, Rich Communication Services の Presence Service に着目した. 現在, Pres-
ence Service を有しているアプリケーションは幾つか存在しているが, アプリケーション同
士でしか Presence 通知を行うことができない. また, 既存の Presence Service の Presence
情報の変更は手動が前提となっている. そこで, より利便性が高く快適な Rich Com-
munication Services を提供する容易な Presence 情報の自動取得を行う PARS(Presence
Automatic Recognition System ) の提案を行った. 提案方式では端末自身に状態を推定さ
せ, その状態を基に Presence 情報に変換する機能を提案した.
検証では端末が状態推定を行うアプリを作成し, 作成した API による端末の状態推定の
値の出力を行った. その API から出力された値を基にゾーン判定項目を作成し, 値による
Presence 情報への変換を確認し, 提案方式の有用性を示した. その結果, 既存の Presence 情
–i–
報の中で自動検知すべき 15 種類の内 8 種類を自動化できることを確認した.
キーワード
Next Generation Network, Rich Communication Service, Presence Ser-
vice, プレゼンスの自動取得, PARS
– ii –
Abstract
A Study on Presence Service implementation in Rich
Communcation Services
Kazutoshi Ogasahara
In recent years, the next-generation networks has been introduced. As a technique
for realizing the Next Generation Network, IP Multimedia Subsystem embodied in the
network node is employed in the international standards. Rich Communication Service
is expected as the basic service applications set which provides the new convenience and
more comfortable communication. It is described as a basic standard service set for nextgeneration networks. Rich Communication Services is a group of basic communications
services that substitute the basic current combination of telephone and mail. Rich
Communication Services includes seven types of services, which are Instant messaging,
Short Message Service, Multimedia Messaging Service, Presence Service, Voice Call,
Video Share and Image Share.
This article focuses on the presence service of the rich communication service. Currently, communication applications which provide a presence service are few. They are
not possible to carry out the presence notification to the others applications. The presence status information acquisition of existing presence of communicators is expected
to be done with present manual manipulations. Therefore, the PARS which is Presence
Automatic Recognition System is proposed as a automatic presence status recognition
and registration method for the presence control. In the proposed system, smart phone
itself recognizes the user’s activity on going and translate it to one of the presence status
– iii –
automatically.
The PARS could define the movement reference values due to movement of the
device holded. The PARS operator using the Application Programming Interface application validation of the smart phone device. Through the PARS verification experiment,
the API reference values could be categorized into the value zones, respectively. And
the categorized zones could judge the presence status of the device holded. It was confirmed that PARS would be operated to recognize the 8 type of presence status among
the 15 types of communicator’s presence status among the 28 type status defined in the
international standard. The verification experiment clarified that PARS is effectively
used to register the communicator’s status without input manipulation.
key words
Next Generation Network, Rich Communication Service, Presence Ser-
vice, Presence infomation automatic acquisition, PARS
– iv –
目次
第1章
序論
1
1.1
電気通信サービスの動向 . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Next Generation Network の導入 . . . . . . . . . . . . . . . . . . . . . .
2
1.3
IP Multimedia Subsystem . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Rich Communication Services . . . . . . . . . . . . . . . . . . . . . . .
4
1.5
1.4.1
Presence Service . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4.2
Instant Message . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4.3
Short Message Service . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4.4
Multimedia Message Service . . . . . . . . . . . . . . . . . . . . .
6
1.4.5
Voice Call(VoLTE) . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4.6
Video Share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.4.7
Image Share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Presence Service の現状 . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.5.1
既存の Presence Service . . . . . . . . . . . . . . . . . . . . . . .
7
1.5.2
RCS における Presence Service . . . . . . . . . . . . . . . . . . .
8
1.6
研究目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.7
論文構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
第2章
Presence Service の仕組み
11
2.1
緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3
Presence Service のアーキテクチャ . . . . . . . . . . . . . . . . . . . . .
15
2.3.1
2.4
IMS における Presence Service . . . . . . . . . . . . . . . . . . .
15
Presence 情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
–v–
目次
2.5
2.4.1
PIDF(Presence Information Data Format) による Presence . . . .
19
2.4.2
RPID(Rich Presence Information Format) . . . . . . . . . . . . .
19
2.4.3
CIPD(Contact Information in Presence Information Data Format) 20
結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
提案する PARS 方式
23
3.1
緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2
PARS 方式の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3
PARS 方式の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.4
PARS 方式の動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.5
Presence 情報の推定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
第3章
3.5.1
前提条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.5.2
端末による Presence 情報の推定方法 . . . . . . . . . . . . . . . . .
25
3.5.3
自動推定を行う Presence 情報 . . . . . . . . . . . . . . . . . . . .
26
結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
端末による状態推定の検証
29
4.1
緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.3
Presence 情報の推定の検証 . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.6
第4章
4.3.1
検証を行う部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3.2
検証環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3.3
検証環境下 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.3.4
検証方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3.5
検証結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.4
考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.5
結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
– vi –
目次
第5章
結論
43
5.1
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2
今後の検討課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
謝辞
45
参考文献
47
– vii –
図目次
1.1
情報通信端末の世帯保有数率の推移 . . . . . . . . . . . . . . . . . . . . . .
2
1.2
NGN の統合アーキテクチャの概念図 . . . . . . . . . . . . . . . . . . . . .
3
1.3
RCS の市場状況 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1
SIP の動作例
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2
IMS における Presence Service の概念 . . . . . . . . . . . . . . . . . . . .
16
2.3
SIP ベースの Presence アーキテクチャ . . . . . . . . . . . . . . . . . . . .
16
3.1
PARS のシステム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2
端末による状態推定画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1
XPERIA SX SO-05D の表面, 裏面 . . . . . . . . . . . . . . . . . . . . . .
31
4.2
端末の状態推定の中央値 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.3
端末の状態推定結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
– ix –
表目次
2.1
メソッドの種類と役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2
ステータスコードの種類と意味 . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3
重要なヘッダフィールドの説明 . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4
格納している情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.5
活動状態 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1
自動検知すべきプレゼンスの有無 . . . . . . . . . . . . . . . . . . . . . . .
27
4.1
自動検知する Presence 情報 . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.2
XPERIA SX SO-05D の技術仕様 . . . . . . . . . . . . . . . . . . . . . .
31
4.3
Away の出力平均 (％)【1】 . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.4
Away の出力平均 (％)【2】 . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.5
In-transit の出力平均 (％)【1】
. . . . . . . . . . . . . . . . . . . . . . .
35
4.6
In-transit の出力平均 (％)【2】
. . . . . . . . . . . . . . . . . . . . . . .
35
4.7
Steering の出力平均 (％)【1】 . . . . . . . . . . . . . . . . . . . . . . . .
36
4.8
Steering 出力平均 (％)【2】 . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.9
Public-transportation 出力平均 (％) . . . . . . . . . . . . . . . . . . . . .
37
– xi –
第1章
序論
1.1
電気通信サービスの動向
近年, 移動通信ネットワークが進展し, 情報通信端末の普及が全体的に飽和状態の中, ス
マートフォンの世帯普及率が急速に増加している. 情報通信端末の世帯保有数率の推移を図
1.1 に示す [1]. 情報通信端末は依然として固定電話は減少傾向にあるが, 携帯電話・PHS 及
びパソコンの普及率はそれぞれ 94.8 ％, 81.7 ％となっており安定している. その中でも携帯
電話・PHS の内数であるスマートフォンは平成 22 年に 7.2 ％だったものが, 平成 25 年には
62.6 ％と急速に広まっている. 普及している要因として, 携帯電話やスマートフォンは移動
通信ネットワークが進展し, サービスが高性能化している事により増加していると考えられ
る. また, サービスの高性能化に伴い電話サービスだけでなく, 電子メール, インターネット
アクセス, SNS 等のマルチメディアサービスが日々進歩しコミュニケーションの手段が増加
している. 将来的には Fixed Mobile Convergence(以下, FMC) による移動通信と固定通信
が融合した通信サービスの形態になると考えられる. FMC を実現する方式として電話網と
IP 網を統合した次世代ネットワーク, Next Generation Network が注目を浴びている.
–1–
第 1 章 序論
図 1.1 情報通信端末の世帯保有数率の推移
1.2
Next Generation Network の導入
Next Generation Networ(以下, NGN) とは, インターネットで使用されている中核的な
技術である IPInternet Protocol(以下, IP) を使用した次世代の安全性や信頼性の高いネッ
トワークの総称である [2]. 国際標準機関である ITU-T が標準化し, マルチメディアサービ
スの提供を目的に広帯域で QoS 制御可能なパケットベースのネットワークである.
NGN は, 従来の電話網と IP 網を統合したネットワークであり, 双方面の良い面を採用
して構成されている. 電話網の特徴である QoS が保証されているギャランティ型のネット
ワークでセキュリティ性も高く, 相手との接続関係を確立した上で通信するため, 信頼性・
安全性が高い. また, IP 網の特徴であるパケット交換方式でパケットデータを扱い, IP プロ
トコル, ルータを使って接続するため高い柔軟性がある. NGN 統合アーキテクチャの概念
図を図 1.2 に示す. NGN は Session Initiation Protocol を標準プロトコルとして採用して
いる [3]. また, 音声通信や映像通信などのセッション制御を行うためのシステムとして IP
–2–
1.3 IP Multimedia Subsystem
Multimedia Subsystem を採用した Rich Communication Services が標準サービスとして
提唱されている.
NGN の代表的なサービスとして NTT が提供しているフレッツ光ネクストがある. 光
ファイバを用いることで高速通信を実現しており, 平成 26 年に総務省東海総合通信局によ
る発表では 25 年 12 月末で普及率は 43.5 ％であり, 今後も普及が進むと考えられる.
図 1.2 NGN の統合アーキテクチャの概念図
1.3
IP Multimedia Subsystem
IMS とは音声通信や映像通信などのマルチメディアのセッション制御を行うシステ
ムである. IMS では, 音声や映像などのリアルタイム・アプリケーションをパケット通
信でベースとした IP 網上で提供することが可能である. IMS は携帯電話のコアネット
ワークの IP 化を目的として, 第 3 世代携帯電話システムについて規格の標準化を行う
3GPP(Third Generation Partnership Project) によって標準化が行われた [10]. 標準化の
際に，IETF(Internet Engineering Task Force) でこれまでに標準化されたインターネット
–3–
第 1 章 序論
のプロトコルが利用できるようになされている. また, IMS は NGN の中核の技術として注
目されており, NGN の標準化を進める ITU-T などにおける標準化の基盤となっている.
IMS では，既存の移動網と電話網等で IP 電話として使用される SIP を標準採用し
ており，SIP によりセッション制御を実現している．また，他にも RTP（Real-Time
TransferProtocol) や RTCP（RTP Control Protocol）といったプロトコルを用いて映像や
音声といったリアルタイムメディアを転送している [10].
1.4
Rich Communication Services
Rich Communication Services は GSMA(Global System for Mobile Communications
Association) が標準化を進めている電話メールにとって代わる基本コミュニケーションの
サービス群であり, 利便性・快適さを利用者に提供する [4]. RCS の市場状況を図 1.3 に示
す [5]. RCS は欧州を中心に普及しており, 近年ではアジア圏にも徐々に普及しているが日
本での普及は皆無である. RCS は利用者が契約している携帯電話会社の加入者だけでなく,
国内や海外の他の携帯電話事業者の利用者, さらにはパソコンでインターネット接続してい
る人も同じように使えることが想定されている. Rich Communication Services のサービス
群には Presence Service, Instant Message, Short Message Service, Multimedia Message
Service, Voice Call, Video Share, Image Share の 7 つのサービスが定義されている. 以下
でそれぞれのサービスについて説明を行う.
–4–
1.4 Rich Communication Services
図 1.3
1.4.1
RCS の市場状況
Presence Service
Presence Service とは現在通信しようとする相手の状態（プレゼンス）を通知するサービ
スである. 狭い意味では, オンラインであるかオフラインであるかの通信可否に関する状態
情報のことを指す. ただし, 一般的にはオンライン/オフラインの状態だけでなく, 現在会議
中か食事中かなどの利用者の活動状態や通話の可否など利用者に関係する状態はプレゼン
ス情報となる [5]. 利用者がプレゼンスをネットワーク上でやり取りするため, IP 電話の呼
制御で使われる SIP 上でプレゼンスをやりとりする SIMPLE（SIP for instant messaging
and presence leveraging extensions）という仕様を用いている.
–5–
第 1 章 序論
1.4.2
Instant Message
IM は，メッセージを通信相手に送信するサービスである．メッセージは通常，テキスト
形式であるが，HTML ページや画像，音声ファイル，音楽ファイル，ビデオクリップ，そ
の他の一般ファイルを乗せることも可能となっている．IM はリアルタイムで，メッセージ
内容がネットワークノードに送信されないのが特徴で，これらの点が電子メールのサービス
と異なっている．通信相手は 1 人に限らず，複数とやり取りすることが可能である.
1.4.3
Short Message Service
Short Message Service とは携帯電話同士で短いメッセージを送受信できるサービスであ
り, 相手の番号を指定して加入者間で即時に交換できるシステムである. 世界的には GSMA
規格の一部として 140Bytes（7bits：アルファベットで 160 文字）までのメッセージ交換で
きる標準規格が普及した. 日本では第 2 世代携帯電話で複数の方式が並立したこともあり,
キャリアごとに独自の仕様が採用され, 他のキャリアの加入者や国外とはやりとりはでき
なかったが 2011 年 7 頃から国内キャリア同士で相互接続されるようになった. NGN では
キャリアを意識せずに接続することが可能であり, 異なるキャリア間でメッセージができる.
1.4.4
Multimedia Message Service
Multimedia Message Service とは携帯電話同士で文字や音声・画像等短いメッセージに
して送受信できるサービスであり, SMS と相互運用性を保ちつつ機能拡張が行われている.
MMS は 3GPP で標準化されている. NGN でも同様に扱うことができ, 文字や音声・画像
のやり取りができる.
1.4.5
Voice Call(VoLTE)
Voice Call とは IP 網を利用した音声通話サービスであり, NGN でも IP 網を用いた音声
通信が行われる.
–6–
1.5 Presence Service の現状
また, モバイル端末では VoLTE（Voice over Long Term Evolution）を採用している.
VoLTE は第 3 世代 (3G 携帯電話) のデータ通信を高速化した LTE 方式で, 音声通話をパ
ケット通信として提供する技術である.
1.4.6
Video Share
Video Share とは通話相手と動画を共有するサービスである. NGN では共有中に動画の
再生, 一時停止, 再開操作が行える.
1.4.7
Image Share
Image Share とは通話相手とイメージを共有するサービスである. NGN では画像上に文
字, 図などを書き加え, 書き加えた図をお互いが保存できる.
1.5
1.5.1
Presence Service の現状
既存の Presence Service
Presence Service とは自身の通信相手として登録されているネットワークユーザの通信の
可否状況などを Messaging して通知を受け, それをユーザ自身に知らしめ, 一般に表示, 即
知プレゼンスするサービス機能を指す. 近年 Presence Service は一般人のみならず, 企業が
積極的に取り入れて使用している. その背景として連絡を取りたい相手が外出していたり,
離れた場所にいてもプレゼンス情報を把握することで最適なコミュニケーションを選択でき
る. そのため, プレゼンス情報を把握することでコミュニケーションの際に無駄な時間を削
減することができる. また, 携帯端末が飛躍的に進歩しスマートフォンやタブレット PC な
どでブラウジングが容易になり, 本来 PC でしか扱えなかった Skype などのアプリケーショ
ンが使えるようになったことも要因の一つと考えられる. しかし, Presence Service を有し
ているアプリケーションは幾つか存在しているが, 携帯端末の電話やメールのような基本
サービスとは連携しておらず, アプリケーション内のサービスにしか対応していない. また,
–7–
第 1 章 序論
プレゼンスを通知するために利用者が一部手動でプレゼンスを変更しなくてはならない. そ
のため, 利用者毎に利用水準が異なるとリアルタイムにプレゼンスを知る事ができない. ま
た, 利用者毎にプレゼンスの通知先を制御する機能がなく, 詳細なプレゼンス情報を提供し
ていないことなどが問題点としてあげられる.
1.5.2
RCS における Presence Service
既存研究により, RCS の Instant Message, Short Message Service, Multimedia Messag-
ing Service, Voice Call(VoLTE), Video Share, Image Share の 6 つのサービスと Presence
Service の連携が提案されている [6]. 連携することにより, RCS の中から相手の状態を見
て最適な連絡手段が選択できるようになる. また, 既存研究の提案方式を利用することで,
利用者の連絡先と Presence 情報を処理, 管理でき利用者のリクエストに応じて, 連絡を取
りたい相手の Presence 情報を監視, 取得できるようになっている. さらに利用者が任意に
Presence 情報の公開や通知を設定できるようになり, かつ, RCS と連携した Presence 情報
の表示が可能になる [6].
1.6
研究目的
RCS は標準サービスとして提唱はされているが, サービス内容については具体化されて
ない. サービスが具体化されていないと各サービス間での連携がとれていないと考えられ
る. また, 現在の Presence Service での状態変更は手動が前提となっている. ゆえに RCS
に対応した有用な Presence Service 実現が必要不可欠である. 本研究では RCS における
Presence Service に着目し, 従来の Presence Service より利便性が高く快適な RCS を提供
する容易な Presence 情報の取得の実現を行う.
–8–
1.7 論文構成
1.7
論文構成
本論では, まず第 2 章で Presence Service を実現するための基盤技術である SIP と
Presence Service の仕組み及び既存研究について説明する. 第 3 章では Presence Service
のプレゼンス情報を一部自動取得する提案方式 Presence Automatic Recognition System
を提案する. 第 4 章では, Presence Automatic Recognition System の有用性を検証するた
めに端末による状態推定の検証実験, 結果及び考察を述べる. 第 5 章では, 本研究のまとめを
述べ, 今後の課題についても述べる.
–9–
第2章
Presence Service の仕組み
2.1
緒言
本章では, IP Multimedia Subsystem（以下, IMS）で Presence Service を実現するため
の中核である Session Initiation Protocol（以下, SIP）や IMS のアーキテクチャ, 既存の
Presence Service について述べる.
2.2
Session Initiation Protocol
IMS では, セッション制御プロトコルとして SIP を採用している. SIP は IP ネット
ワーク上でマルチメディアセッションを確立・変更・終了などを管理するためのプロトコ
ルとして IETF(Internet Engineering Task Force) によって規定され, ベース仕様である
RFC3261 の他多数の関連 RFC から構成されている [7]. IMS の呼制御プロトコルとして採
用されたことをきっかけに SIP の普及が進み, IETF で仕様拡張検討が続いている. SIP は
HTTP(HyperText Transfer Protocol) をベースにしているため, リクエスト-レスポンス型
の通信, ヘッダ部とボディ部でメッセージ構成, テキスト記述といった HTTP との共通点が
ある [7]. これにより, 解析や開発の容易さ, 高い拡張性を有していることが SIP の特徴で
もある. また, SIP URI(Uniform Resource Identifier) というメールアドレスに似た形式を
使用可能なため, インターネット親和性が高いと言える. SIP によって実現可能なサービス
には, ビデオ会議や電話, IM, Presence Service が挙げられる. SIP による通信では, 基本的
に UAC(User Agent Client) がリクエストを生成・送信し, それに対して UAS(User Agent
– 11 –
第 2 章 Presence Service の仕組み
1 は UAC から UAS への
Server) がレスポンスで応答する. SIP の動作例を図 2.1 に示す. ⃝
2 は UAS から UAC に対して送信されるレスポンス, ⃝
3 が成功応答/
セッション確立要求, ⃝
4 はセッション確立要求に対するレスポンスを受け取った
リクエストは成功のレスポンス, ⃝
事を通知する.
図 2.1 SIP の動作例
SIP では前述したように HTTP ベースにしたテキストを用いた SIP メッセージフォー
マットによってやり取りを行う. メッセージフォーマットではリクエストの場合はリクエス
ト行 (request line), レスポンスの場合はステータス行 (status line) と呼ばれる開始行 (start
line) から始まる. 開始行の後に複数のヘッダフィールドが続き, 空行 (empty line) を挟んで
メッセージボディ (message body) が続く. 以下でそれぞれの説明を行う.
• リクエスト行
リクエスト行では, メソッド名, Request-URI 及びプロトコルバージョン (SIP/2.0) が
含まれている. メソッド名がリクエストの役割を示す. Request-URI はそのリクエスト
の宛先を示す. 現在定義されているメソッドの種類と役割を表 2.1 に示す [7].
– 12 –
2.2 Session Initiation Protocol
表 2.1
メソッドの種類と役割
メソッド名
役割
規定 RFC
REGISTER
現在位置情報の登録
RFC3261
INVITE
セッションの確立
RFC3261
ACK
最終レスポンスに対する確認
RFC3261
BYE
セッションの切断
RFC3261
CANCEL
確立途中のセッションのキャンセル
RFC3261
OPTIONS
能力の問い合わせ
RFC3261
PRACK
暫定レスポンスに対する確認
RFC3262
SUBSCRIBE
プレゼンス等の情報要求
RFC3265
NOTIFY
プレゼンス情報等の情報要求に対する通知
RFC3265
PUBLISH
プレゼンス等の情報送信
RFC3903
UPDATE
セッションの更新
RFC3311
MESSAGE
テキストメッセージの送信
RFC3428
PEFER
転送要求
RFC3515
INFO
セッション中の情報送信
RFC2976
• ステータス行
ステータス行では, プロトコルバージョン (SIP 2.0), トランザクションステータスを示
すステータス番号, ステータスコードに対応した説明を記す文字列が含まれている. ス
テータスコードの種類を表 4.2 に示す [7]. Presence Service ではステータスコード 200
を返す事が多い.
– 13 –
第 2 章 Presence Service の仕組み
表 2.2 ステータスコードの種類と意味
ステータスコード
意味
1xx
暫定
2xx
成功
3xx
リダイレクト
4xx
クライアントエラー
5xx
サーバエラー
6xx
グローバルな失敗
• ヘッダフィールドヘッダフィールド値は複数の要素からなっている. その中でも重要
なヘッダフィールドは To ヘッダ, From ヘッダ, Cseq ヘッダ, Call-ID ヘッダ, Max-
Forwards ヘッダ, Via ヘッダである. 重要なヘッダフィールドの説明を表 2.3 に示す
[7]. 各ヘッダフィールドを使用することで SIP 上でのやり取りを実現している.
表 2.3 重要なヘッダフィールドの説明
ヘッダ名
説明
To ヘッダ
リクエストの宛先の URI を含
From ヘッダ
リクエスト送信者の URI を含む
Cseq ヘッダ
メソッド名, シーケンス番号を含む
Call-ID ヘッダ
SIP メッセージ交換を特定する ID を含む
Max-Forwards ヘッダ
ルーティング処理のループ状態を未然に防ぐ
Via ヘッダ
リクエストが経由するプロキシサーバを記録
• メッセージボディ SIP メッセージでは, MIME(Multipurpose Internet Mail Extensions) エンコーディングを利用することで, 任意の種類のメッセージボディを複数含め
ることが可能であり, SIP はこの MIME の機構を利用してメッセージボディを設定し
– 14 –
2.3 Presence Service のアーキテクチャ
ている. つまり, SIP のメッセージボディでは電子メールの添付ファイルと同じように,
映像データや画像データはメッセージ内に記述される.
2.3
Presence Service のアーキテクチャ
Presence Service は, ユーザの通信可否状態, 通信に応じる意思があるかどうかなどの
Presence 情報を通信相手に知らせるサービスである. Presence Service を利用するメリッ
トとして, ユーザは通信手段や通知するタイミングを自由に選択できるなど, 汎用性の高
い通信が利用可能になる. 現在の Presence Service は SIP を用いて実現されおり, IMS で
Presence Service を利用するためには現状の Presence Service のアーキテクチャを IMS に
置き換える必要がある. 以下で IMS における Presence Service のアーキテクチャについて
説明する.
2.3.1
IMS における Presence Service
IMS における Presence Service は Presence Service 以外の他のサービスからも Presence
情報が利用可能であることが特徴である. すなわち IMS を利用した Presence Service は
RCS と連携することが可能であると言える. IMS における Presence Service の概念を図
2.2 に示す [10].
– 15 –
第 2 章 Presence Service の仕組み
図 2.2 IMS における Presence Service の概念
この概念を用いて実現した SIP ベースの Presence アーキテクチャの図 2.3 に示す.
図 2.3 SIP ベースの Presence アーキテクチャ
このアーキテクチャの中核は, ホームネットワークに位置して PA(Presence Agent) と
して動作する Presence Server である. Presence Server はコンテンツサーバ, Presence
– 16 –
2.3 Presence Service のアーキテクチャ
XDMS, Presence コンテンツ XDMS から構成されている. IMS アーキテクチャの観点か
ら, これらは全て Application Server に位置付けられる. また, Presence においてはリスト
の管理が必要となり, その役割を果たしているのが Resource List Server である. このサー
バは, Presnce に必要な様々なリストを管理する機能を提供している. Resource List Server
は RLS XDMS, 共有 XDMS から構成されており, 同様に Application Server として位置
付けられる. Application Server 間は S-CSCF を用いて Presence 情報のやり取りを行う.
次節では主要機能となる S-CSCF, P-CSCF, I-CSCF, HSS について説明していく.
• S-CSCF (Serving-Call/ Session Control Function)
S-CSCF は, 利用者が契約している通信事業者のネットワークに存在し, 利用者にサー
ビスを提供する際に中心的な役割を行う SIP サーバである. 主の機能は次の通りで
ある．
-利用者の端末情報を HSS に転送する
-HSS から取得した加入者情報を保持する
-セッション開始, 終了, 転送を行う
-付加サービスの提供が必要な場合, 該当するアプリケーションサーバのサービス処理を
起動する
• P-CSCF (Proxy-Call/ Session Control Function)
P-CSCF は, 利用者が IMS ネットワークにアクセスする際に最初に接続されるポイン
トであり, 利用者が登録する際に割り当てられる SIP サーバである. P-CSCF の主な機
能は次の通りである.
-IMS に対応した端末から送信された SIP メッセージをチェックすることで不正メッ
セージをチェックし，不正メッセージの流入を防止する
-リクエストメッセージを他の CSCF へ転送をする
-IMS 対応端末からのリクエストがない場合の切断処理を行う
• I-CSCF (Interrogating-Call/ Session Control Function)
– 17 –
第 2 章 Presence Service の仕組み
I-CSCF は, 他のネットワークからの SIP メッセージを受信するゲートウェイの役割を
する SIP サーバである. 主な機能は次の通りである.
-利用者がプレゼンスを変更する際，該当する HSS を求める-ネットワーク内の適切な
S-CSCF に IMS 対応端末からのメッセージを転送する
• HSS(Home Subscriber Server)
HSS とは，セッション制御，サービス制御に必要な全ての情報を格納しているデータ
ベースである．HSS は，IMS を利用する利用者の加入契約情報や位置情報，IP 情報を
保持している．HSS が格納している主な情報を表 2.4 に示す.
表 2.4
格納している情報
格納している情報加入者識別情報
ユーザ認識情報
S-CSCF 選択情報
個別アプリケーションを選択するための情報（ユーザプロファイル）
2.4
Presence 情報
Presence 情報には属性 (Characteristics) と状態 (Status) がある. 属性は静的な情報で
あり, 更新されることがあまりない. 状態は動的な情報であり, 頻繁に更新がされる. また,
Presence 情報は大別して 3 つの要素に分類することができる. これら 3 つは RFC4479 の
A Data Model for Presence[9] で Person, Service, Device と定義されている. 以下でそれ
ぞれについて説明する.
• Service 要素
一定の様式や内容を生むユーザ間で相互作用するシステム [10].
例: 通信サービス (IM, VoIP) など
– 18 –
2.4 Presence 情報
• Device 要素
通信デバイスは, 通信を開始もしくは受信するためにユーザが相互作用する物理的要素
である [10].
例: 電話機, PDA, PC など
• Person 要素
エンドユーザは, Presence の対象として, 通信の可否や意思に影響を与える [10].
例: 取り込み中, ”楽しい”といった気分など
2.4.1
PIDF(Presence Information Data Format) による Presence
Presence 情報は PIDF によって表す. PIDF は RFC3863 で規定され, プレゼンスシステ
ムの 2 つのエンティティ間でプレゼンス情報をの意味内容を伝達するために設計された, 特
定のプロトコルの用途に限定されない XML 文書である. PIDF で定義されている状態は
Open と Close の 2 種類しかなく, 不十分であるため自身で拡張して扱う必要がある. また,
PIDF を拡張した RPID や CIPD というものがある.
2.4.2
RPID(Rich Presence Information Format)
PIDF を拡張したもので, 通知者 (プレゼンティティ) が詳細で高度な Presence 情報を受
信者 (ウォッチャー) に通知することができる. RPID は PIDF と同様に XML 文章で作成
され, PIDF に対する後方互換性がある. RPID は RFC4480 で規定されており, 活動状態
(Activities Status) を 27 種類表わすことができる. 表 2.5 に活動状態の種類と内容を示す.
– 19 –
第 2 章 Presence Service の仕組み
表 2.5
活動状態
活動状態
説明
活動状態
説明
Appointment
予約
Away
外出
Breakfast
朝食
Busy
忙しい
Dinner
夕食
Holiday
休日
In-transit
移動中 (運転以外)
Looking-for-work
求職中
Lunch
昼食
Meal
食事
Meeting
会合
On-the-phone
電話中
Other
その他
Performance
映画, 演劇など
Permanent-absence
永久不在
Playng
遊んでいる
Presentation
講義, 正式な会議
Shopping
買い物中
Sleeping
睡眠中
Spectator
見物, 観戦
Steering
運転中
Travel
旅行
TV
テレビ観賞
Unknown
不明
Vacation
休暇
Working
作業中
Worship
礼拝
Public-transportation
公共交通機関を利用
2.4.3
CIPD(Contact Information in Presence Information Data
Format)
Presence 情報に, ビジネスカードやホームページ, 地図, などへの参照情報を追加するため
の RPID の拡張仕様である. CIPD は RFC4482 により規定されている. CIPD には Card,
Display-name, Homepage, Icon, Map, Sound の要素がある. CIPD は主に Characteristics
の拡張とも言える.
– 20 –
2.5 結言
2.5
結言
本章では, 新たな Presence Service における Presence 情報取得にあたって必要な SIP に
よる通信, IMS における Presnce Service のアーキテクチャ, Presence 情報の種類, 中身に
ついて説明した.
– 21 –
第3章
提案する PARS 方式
3.1
緒言
本章では, より利便性が高く快適な RCS を提供する容易な Presence 情報取得方法の提案
を行い, 提案するシステムの構成, 動作, Presence 情報の推定方法について説明する.
3.2
PARS 方式の概要
現在の Presence Service は手動での状態変更が前提となっているため, ユーザが状態
の変更が発生する度に自身によって操作する必要がある. 今後, RCS を利用した際には
Presence Service は自動推定及び取得できる事が望ましいと考えられる [8]. そこで本章で
は, 端末のセンサを用いることで端末保持者の状態を自動推定を行う, Presence Automatic
Recognition System を提案する.
3.3
PARS 方式の構成
PARS 方式のシステム構成を図 3.1 に示す. 図に示す構成要素についてそれぞれ説明する.
– 23 –
第 3 章 提案する PARS 方式
図 3.1 PARS のシステム構成
• スマートフォン (通知者)
通知者のスマートフォンは, Presence 情報を取得するために利用する端末である. ス
マートフォンには端末自身による状態推定を行うためのセンサ, 処理系が備わっている
ものとする.
• IP Multimedia Subsystem
既存の IP Multimedia subsystem はキャリアごとに分かれているが本提案方式の IP
Multimedia Subsystem はキャリアを意識せず, 相互に接続できるものとする. 現在,
IP multimedia Subsystem 間の相互接続インタフェースの標準化が行われており, 今後
は IP Multimedi Subsystem と IP multimedia Subsystem 間の通信の実現されること
が想定され, キャリア間を意識する必要がなくなると考えるからである.
• Presence Server
ネットワークに接続している通信者 (通知者) のプレゼンス情報を把握している. 受信
– 24 –
3.4 PARS 方式の動作
者にその情報を通知したり, 通知者の Presenec 情報の変更があるかどうかの検出処理
も行う. Presence Server はコンテンツサーバ, Presence XDMS, Presence コンテンツ
XDMS から構成されている. また, Presence Server によって RCS のサービスの利用
制御を行う. これによって Presence Server が各 RCS のプロキシサーバともなる.
3.4
PARS 方式の動作
通知者のプレゼンス情報は所持しているスマートフォンに備わっているセンサを利用して
プレゼンス情報を自動推定, 生成させる. スマートフォンから推定されたプレゼンス情報は
Presence Server に送信される.
3.5
Presence 情報の推定
本提案方式を実現するためには, 端末に内蔵されているセンサを用いて通知者のプレゼン
ス情報を推定する必要がある. 端末は常時ネットワークに接続していると想定した. 本提案
では以下の方法によりプレゼンスの取得を行う.
3.5.1
前提条件
Presence 情報取得のための前提条件を以下に示す.
• RCS を対象とした Presence Service とする.
• 使用する端末はスマートフォン及びタブレット端末を対象とする.
3.5.2
端末による Presence 情報の推定方法
GooglePlayServices の Location APIs を利用することで, 端末の状態から通知者の
Presence 情報推定を行うことができ, 通知者の Presene 状態を自動で入力させることが可
能である. 端末による状態推定画面を図 3.2 も示す. 本来の PS で規定されている Presence
– 25 –
第 3 章 提案する PARS 方式
情報は手動で変更を行うが, 本研究では規定されている Presence 情報の中で, 自動推定に
よって一部のプレゼンス情報の変更入力を支援する.
図 3.2
3.5.3
端末による状態推定画面
自動推定を行う Presence 情報
規定されているプレゼンス情報 [11] の中で一部自動設定を行う. プレゼンス情報の中で自
動検知すべきと考えたプレゼンスを表 3.1 に示す. 規定されている Presence 情報から自動
検知すべきものを”⃝”, 自動検知が望ましいものを”△”, 自動検知が厳しいものを”×”とす
る. 自動検知すべきもの”⃝”が 8 種類, 自動検知が望ましいもの”△”が 8 種類, 自動検知が
厳しいもの”×”が 12 種類となった. 自動検知すべきものは動く, 止まる, といった人による
動作が伴うため, 端末による推定が容易であると考える. 自動検知すべきものは, 長期間, 長
時間の活動を計測しなければ, 端末では推定できないと考えているからである. 自動検知が
厳しいものは端末だけでは推定が不可能であると考えているからである.
– 26 –
3.5 Presence 情報の推定
表 3.1
自動検知すべきプレゼンスの有無
活動状態
自動推定の有無
活動状態
自動推定の有無
Appointment
×
Away
⃝
Breakfast
△
Busy
△
Dinner
△
Holiday
×
In-transit
⃝
Looking-for-work
×
Lunch
△
Meal
⃝
Meeting
△
On-the-phone
⃝
Other
×
Performance
×
Premanent-absence
×
Playing
△
Presentation
×
Shopping
△
Sleeping
⃝
Spectator
×
Steering
⃝
Travel
×
TV
×
Unknown
△
Vacation
×
Working
⃝
Worship
×
Public-transportation
⃝
本研究で自動検知を行う Presence 情報は, Away(外出), In-transit(車内: 運転中以外),
Meal(食事中), On-the-phone(端末操作), Sleeping(睡眠中), Steering(運転中), Working(机
で作業), Public-taransportation(公共交通機関利用), 状態を予め想定しておく. また自動
検知が望ましい Presence 情報は,Breakfast(朝食), Busy(忙しい), Dinner(夕食), Lunch(昼
食), Meeting(会議), Playng(遊び) ある. 残りの 12 種類の Presence 情報については端末だ
けでの取得が難しく, 本研究の端末のみでの推定は厳しいと考え, 今回は取得目標にはしな
いことにした.
– 27 –
第 3 章 提案する PARS 方式
3.6
結言
本章では, RCS におけるより快適かつ利便性の高い Presence Service における Presence
情報自動取得方法の提案を行い, 提案方式の構成, 動作, Presence 情報の推定方法について
述べた.
– 28 –
第4章
端末による状態推定の検証
4.1
緒言
本章では, 提案方式の有用性の検証のための検証実験方法と検証結果, 考察について述
べる.
4.2
概要
提案システムによる実用性を調べるため, 端末に状態推定のアプリを作成し実際にそれぞ
れ設定した通知者の PS 状態の推定が行えるか検証した. また, その状態推定結果を基にプ
レゼンスの自動化が行えることを確認し, 従来の PS と提案方式の PS を比較した.
4.3
Presence 情報の推定の検証
Presecen 情報の推定を検証するために, 端末で状態推定行い, 各状態の数値を取得す
る. より詳細な検証環境については節 4.3.1 で説明する. また, 状態推定から自動検知する
Presence 情報を表 4.1 に示す. これらの Presence 情報を端末状態推定によって推定させる.
– 29 –
第4章
表 4.1
端末による状態推定の検証
自動検知する Presence 情報
プレゼンス情報
4.3.1
Away
In-transit
On-the-phone
Meal
Sleeping
Steering
Working
Public-transportation
Breakfast
Busy
Dinner
Lunch
Meeting
Playing
Shopping
検証を行う部分
提案する PARS の検証において, 本研究ではエンドユーザ (通知者側) の端末で状態推定
を行い, Presence 情報を自動で推定及び生成できるかを確認した.
4.3.2
検証環境
本研究の実験では, 統合開発環境 Eclipse を利用し, 開発言語は Java を使用した. その中
の Android SDK で公開されている Google Play Services を用いた. 自動推定において使
用するスマートデバイスとして, 検証するための充分な機能を備えたかつ上記の特徴を持つ
ものとして, SONY 社の開発した携帯端末 (スマートフォン)XPERIA SX SO-05D を使用
した. XPERIA SX SO-05D の表面・裏面を図 4.1 に示す. また,XPERIA SX SO-05D の
技術仕様を表 4.2 に示す.
– 30 –
4.3 Presence 情報の推定の検証
図 4.1 XPERIA SX SO-05D の表面, 裏面
表 4.2 XPERIA SX SO-05D の技術仕様
4.3.3
項目
性能
サイズ (高さ×幅×厚さ)
約 115mm ×約 54mm ×約 9.4mm
OS
Google Android4.1.2 JELLY BEANS
ディスプレイ
約 3.7 インチ Reality Display
解像度
960 × 540
プロセッサ
1.5GHz デュアルコア
センサ
加速度センサ, ジャイロセンサ, 近接センサ
RAM
1GB
ストレージ
8GB
検証環境下
本研究の検証での検証環境下を以下に示す.
• 端末の保持状態
– 31 –
第4章
端末による状態推定の検証
端末を体の正面になるように手で保持する. In-transit, Steering については乗り物での
移動であるため, 端末を助手席・ドアポケットにおいて計測を行った.
• 検証回数
検証回数は２名で行い, それぞれの行動を各 Presence 情報ごとに 10 回ずつの合計 20
回行った. Public transportation については 10 回の検証のみとした. 本検証では公共
交通機関として路面電車を利用しており, 電車の速度は一定であるため検証回数を増や
してもあまり値に違いがでなかった.
• 検証場所
Away の際の検証場所は高知工科大学の敷地内を利用し, In-transit・Steering について
は高知工科大学から自宅までの道のり (8.2km) を利用した. Publict transportation で
は路面電車を利用し,Meal, Sleeping, Working については高知工科大学 A 棟の A358
を利用し状態推定及び検証を行った.
また, Away の際には敷地内をいつもの歩調で歩くことを条件とした. これにより平均
的な歩行している際の数値を正確に計測できると考える. In-transit・Steering につい
ては運転のスキルの違いや速度の違いがあると考えたため, 2 人検証によって出力され
る値の違いを検証した.
4.3.4
検証方法
使用端末のみで状態を推定するという条件で検証を行った. 判定の際の値はそれぞて％で
出力するようにしており, 端末自身が推定する状態の最低値は 0 ％, 最大値は 100 ％である.
端末保持者の状態に応じて出力された値の確認を行う.
4.3.5
検証結果
被験者 2 人で端末の状態推定を 10 回ずつ行ったそれぞれの結果を Away の出力平均
値【1】を表 4.3, Away の出力平均値【2】を表 4.4, In-transit の出力平均値【1】を表 4.5,
– 32 –
4.3 Presence 情報の推定の検証
In-transit の出力平均値【2】を表 4.6, Steering の出力平均値【1】を表 4.7, Steering の出
力平均値【2】を表 4.8, Public-taransportation の出力平均値を表 4.9 に示す. 各表の端末
状態の項目を 静止中を静止, 徒歩で移動中を徒歩, 走って移動中を走って, 自転車で移動中
を自転車, 自動車で移動中を車と表している.
• Away の検証
Away の検証では検証場所で述べたように, 高知工科大学の敷地内で徒歩による移動を
計測した. 具体的には敷地内で 1 分間, 被験者に端末を手で保持した状態で歩いてもら
う. 普段の歩調で歩いてもらうために人通りの少ない夕方に検証を行い, 直進だけでな
く右左折をしながら徒歩移動を行った. この移動を 1 分間ごとに区切り端末が静止中
(100 ％) になれば歩き出す動作を 2 人に 10 回ずつ試行してもらい, 試行 1 回ごとに出
力された平均を算出した.
表 4.3 Away の出力平均 (％)【1】
端末状態
1回
2回
3回
4回
5回
6回
7回
8回
9回
10 回
静止
41.25
-
-
1
1
0.5
-
-
-
0.71
徒歩
37.75
71.13
77
56.25
81.75
32
63.3
74.14
58.4
62.14
走って
-
-
-
-
-
-
-
-
-
-
自転車
0.75
2.63
2.75
2.38
1
10.5
1.33
2.57
15
8.57
車
12.75
23
15.5
23.63
15.38
27
21.8
23.7
20.2
23.85
傾き
-
-
-
-
-
-
-
-
-
-
不明
9.5
7
1
6.25
1
26.33
12.66
7.14
7.71
4.71
– 33 –
第4章
端末による状態推定の検証
表 4.4 Away の出力平均 (％)【2】
端末状態
1回
2回
3回
4回
5回
6回
7回
8回
9回
10 回
静止
14.5
0.67
5
0.5
4.67
19
-
-
-
0.33
徒歩
6.25
7
14.67
54.5
23.67
8
14
88.5
78.8
12.66
走って
-
-
-
-
-
-
-
-
-
-
自転車
2
1
2
6
3.67
3.67
3
0.5
4.8
10.67
車
28.75
35
21
39
29
27.67
19.67
10.5
21.4
13.33
傾き
-
-
-
-
-
-
-
-
-
-
不明
44.75
50
1.75
34.67
19
34.33
50
0.75
7.6
0.33
• In-transit の検証
In-transit の検証では検証場所で述べたように, 高知工科大学から自宅までの道のり
(8.2km) の間で 1 分間ごとに車の移動を区切り, 1 分間の移動で出力される値を計測し
た. 計測の際には車の通りが少ない夜に行い, 1 分間の試行を 2 人で 10 回ずつ行い, 1
回ごとの出力された値の平均を算出した. 検証の際に被験者には助手席で端末を保持し
てもらった.
– 34 –
4.3 Presence 情報の推定の検証
表 4.5 In-transit の出力平均 (％)【1】
端末状態
1回
2回
3回
4回
5回
6回
7回
8回
9回
10 回
静止
-
3.1
0.6
11
57.75
9
8.2
2
2.66
47.4
徒歩
52.25
0.6
-
-
-
-
-
-
-
-
走って
-
-
-
-
-
-
-
-
-
-
自転車
12.33
1.33
-
1.14
-
-
-
-
0.8
-
車
36.5
12.33
88.5
87.57
28
73.6
80.63
80.88
86.64
42.2
傾き
-
-
-
-
-
-
-
-
-
-
不明
5
25
11
-
19.33
19.2
9.13
16.13
10.11
10.4
表 4.6 In-transit の出力平均 (％)【2】
端末状態
1回
2回
3回
4回
5回
6回
7回
8回
9回
10 回
静止
16
11
-
2
7.25
6.75
3.6
2.2
-
-
徒歩
-
-
-
-
-
-
-
-
-
-
走って
-
-
-
-
-
-
-
-
-
-
自転車
0.6
8.5
6.8
-
9.75
6.25
5.6
8.4
10.6
9.5
車
51.8
42.5
73.2
82.75
58.5
81
75.4
68.8
84.6
69.25
傾き
-
-
-
-
-
-
-
-
-
-
不明
31.6
38
25
15.5
34.75
5
15.4
21
4.6
21
– 35 –
第4章
端末による状態推定の検証
• Steering の検証
Steering の検証では検証場所で述べたように, In-transit と同様に高知工科大学から自
宅までの道のり (8.2km) を被験者が車を運転した. 移動を 1 分間ごとに区切りその際に
出力される値を計測し, 1 回の試行で出力された値の平均を算出した. 検証の際に被験
者には端末を保持してもらわず, 運転席側のドアポケットに端末を置いて行った.
表 4.7
Steering の出力平均 (％)【1】
端末状態
1回
2回
3回
4回
5回
6回
7回
8回
9回
10 回
静止
44.5
11.5
10.33
0.83
3.5
0.83
15.83
10
5.4
12.83
徒歩
0.75
-
-
-
-
-
-
-
-
-
走って
1.3
-
-
-
-
-
-
-
-
自転車
0.6
0.66
-
-
-
0.6
-
0.4
-
車
36.1
62.17
75
82
93.5
82.5
64
1.33
45.8
77
傾き
-
-
-
-
-
-
-
-
-
-
不明
10.83
24.33
14.66
15.8
3
16.66
16.2
42
45.2
12.83
表 4.8 Steering 出力平均 (％)【2】
端末状態
1回
2回
3回
4回
5回
6回
7回
8回
9回
10 回
静止
2.5
30.25
0.57
12.29
9.14
8.86
9.86
11
8.86
13.14
徒歩
-
-
-
1.14
-
-
-
-
-
-
走って
-
-
-
-
-
-
-
-
-
-
自転車
2
1
-
-
0.57
0.29
0.43
1.14
-
14.29
車
57.25
42
90.71
84.85
83.29
75.57
85.57
86.43
90.14
66.29
傾き
-
-
-
-
-
-
-
-
-
-
不明
38.5
27
8.71
2.43
6.14
15.43
4.29
1.57
1.14
6.29
– 36 –
4.3 Presence 情報の推定の検証
• Public-transportation の検証
Public-transportation の検証では検証場所で述べたように, 路面電車を利用して検証を
行った. 路面電車での移動も駅から発車して 1 分間を計測し, 試行を 10 回行った. 試行
1 回で出力された値の平均を算出した. 検証の際には端末を手で保持して, 出力される
値を検証した.
表 4.9 Public-transportation 出力平均 (％)
端末状態
1回
2回
3回
4回
5回
6回
7回
8回
9回
10 回
静止
19.42
3.14
9.75
32.33
25.25
5.5
2.2
10.286
13.75
3.29
徒歩
1.14
-
-
0.75
0.25
3
17.4
0.14
-
-
走って
-
-
-
-
-
-
-
-
-
-
自転車
-
-
-
-
-
1.75
3.4
0.14
-
1.14
車
48.57
80.43
57.75
12
20
37.75
25.8
67.85
37
67.14
傾き
-
-
-
-
-
-
-
-
-
-
不明
28.28
16.42
32.75
22.14
44.25
50
41.6
7.14
50
22.57
– 37 –
第4章
図 4.2
端末による状態推定の検証
端末の状態推定の中央値
以下, 中央値で特徴を論ずる.
• Away の場合
20 回の出力結果から徒歩で移動中が 46.33 ％, 自転車で移動中が 4.24 ％, 自動車で移
動中が 22.63 ％, 不明が 19.76 ％という中央値を得ることができた. これら 4 つの値
を基準とした 4 種の API 出力に適切となる Zone 値を設定することで Away という
Presence 情報として推定することが可能である.
• In-transit の場合
20 回の出力結果から静止中が 10.01 ％, 徒歩で移動中が 2.64 ％, 自転車で移動中が 4.08
％, 自動車で移動中が 65.23 ％, 不明が 15.61 ％という中央値を得ることができた. こ
れら 5 つの値を基準とした 5 種の API 出力に適切となる Zone 知を設定することで
In-transit という Presence 情報として推定することが可能である.
• Meal の場合
20 回の出力結果から静止中が 100 ％という中央値を得ることができた. 本研究で Meal
の場合は端末を操作しなかったためこの値が得られた. 1 つの値を基準とした 1 種の
API 出力に適切となる Zone 値を設定することで Meal という Presence 情報として推
定することが可能である.
– 38 –
4.3 Presence 情報の推定の検証
• On-the-phone の場合
20 回の出力結果から端末の傾きが 100 ％という中央値を得ることができた. 1 つの値を
基準とした 1 種の API 出力に適切となる Zone 値を設定することで On-the-phone と
いう Presence 情報として推定することが可能である.
• Sleeping の場合
20 回の出力結果から静止中が 100 ％という中央値を得ることができた. 本研究で
Sleeping の場合は端末を操作しなかったためこの値が得られた. 1 つの値を基準とした
1 種の API 出力に適切となる Zone 値を設定することで Sleeping という Presence 情報
として推定することが可能である.
• Steering
20 回の出力結果から静止中が 10.49 ％, 徒歩で移動中が 0.16 ％, 走って移動中が 0.07
％, 自転車で移動中が 1.03 ％, 自動車で移動中が 69.8 ％, 不明が 15.12 ％という中央値
を得ることができた. これら 6 つの値を基準とした 6 種の API 出力に適切となる Zone
値を設定することで Steering という Presence 情報として推定することが可能である.
• Working の場合
20 回の出力結果から静止中が 100 ％という中央値を得ることができた. 本研究で
Working を机で作業と想定したため, 机の上に放置して端末を操作しなかったためこの
値が得られた. 1 つの値を基準とした 1 種の API 出力に適切となる Zone 値を設定する
ことで Working という Presence 情報として推定することが可能である.
• Public transpotation
10 回の出力結果から静止中が 11.59 ％, 徒歩で移動中が 2.27 ％, 自転車で移動中が 0.64
％, 自動車で移動中が 45.21 ％, 不明が 31.50 ％という中央値を得ることができた. こ
れら 5 つの値を基準とした 5 種の API 出力に適切となる Zone 知を設定することで
Public-transportation という Presence 情報として推定することが可能である.
– 39 –
第4章
端末による状態推定の検証
ここまで各 API 出力の中央値, 中央値群で述べたが, 各出力のゾーン決定に参照した 20
回の API 出力値を図 4.2 に示す. 得られた Presence 情報への変換結果を図 4.3 に示す. 各
API 出力の Zone 値を設定することで, 端末の状態推定から Presence Service の Presence
情報へ自動化できるこが確認できた.
図 4.3
4.4
端末の状態推定結果
考察
端末自体による状態推定の値から, 規定されている PS の一部自動入力の方法を提案した.
PARS 方式では自動設定が一部状態で可能になることは, 将来の Presence Srvice 活用に途
を開いた. 既存の Presence Service で規定されている自動検知が可能である 15 種類の内 8
種類を自動化できることを確認した.
– 40 –
4.4 考察
また, 自動化できる Presence 情報の Zone 値を Away では徒歩で移動中が 40 ％から 70
％, 自転車で移動中が 3 ％から 5 ％, 自動車で移動中が 15 ％から 25 ％, 不明が 0 ％から 25
％と設定することができた. In-transit では静止中が 5 ％から 20 ％, 徒歩で移動中が 0 ％か
ら 5 ％, 自転車で移動中が 0 ％から 2 ％, 自動車で移動中が 40 ％から 54 ％不明が 0 ％か
ら 25 ％と設定することができた. Meal では静止中の Zone 値をを 100 ％と設定することが
できた. On-the-phone では端末が傾いているの Zone 値をを 100 ％と設定することができ
た. Sleeping では静止中の Zone 値をを 100 ％と設定することができた. Steering では静
止中が 5 ＆から 20 ％, 徒歩で移動中が 0 ％から 5 ％, 走って移動中が 0 ％から 5 ％, 自転
車で移動中が 0 ％から 2 ％, 自動車で移動中が 40 ％から 54 ％, 不明が 0 ％から 25 ％と設
定することができた. Working では静止中の Zone 値をを 100 ％と設定することができた.
Public-transportation では静止中が 5 ％から 20 ％, 徒歩で移動中が 0 ％から 5 ％, 自転車
で移動中が 0 ％から 2 ％, 自動車で移動中が 55 ％から 65 ％不明が 26 ％から 35 ％と設定
することができた.
本研究では Android 端末を持って Presence 情報の自動取得を行ってきたが, iOS におけ
る端末でも Android 同様に加速度センサ, ジャイロセンサを有していれば Presence 情報を
自動で取得することは可能であると考える.
また, API 出力から Presence 情報への実現手法として, 前述した Zone 値を用いた判定が
有効であると考える. 端末による Zone 値の判定を行い, 出力された値が各 Zone 値に最も
近いものをユーザの状態として推定する. そして, 推定された結果から, Zone 値ごとに決め
てある Presence 情報に変換, 生成を行い, Presence 情報に応じて各 Rich Communication
Services の利用可能制御を行い. その後 Rich Communication Services の利用可能通知を
端末に通知する.
– 41 –
第4章
4.5
端末による状態推定の検証
結言
本章では提案方式である Presence Automatic Recognition System の有用性を検証する
ために, 端末自身による状態推定を行い, 検証結果について述べた.
– 42 –
第5章
結論
5.1
まとめ
本研究では, Rich Communication Services における新たな Presence Service の取得方
法として, 端末自身に利用者の状態推定をし, API から出力された値を基にゾーン判定を設
け, Presence 情報を取得できるようにした. 状態推定を実現するために, 端末の状態推定を
行うアプリを作成し, 実際に状態推定が行われるか確認した.
本提案では, 通知者の端末に状態推定を行うアプリを導入し, IMS 内には通知者の
Presence 情報を把握, 管理, 通知を行うための Presence Server を設置した. これにより
RCS に対応した Presence Service が実現できた.
提案方式の検証では Android SDK で公開されている Google Play Services と使用端末
である SONY XPEROA SX SO-05D を持ちて状態推定の値を計測し, Presence 情報の基
準となる値を求めた. その値を中央値とした Presence 情報自動取得の実用性を確認した. そ
の結果, 提案方式は Rich Communication Services に対応し, かつ既存の Presence Service
内の自動検知すべき 15 種類の Presence 情報の内 8 種類の Presence 情報を自動取得できる
ことを検証し, 提案方式の有用性を示した.
5.2
今後の検討課題
今後の検討課題としては, 既存の Presence Service で規定されている Presence 情報を全
て自動化するための手法を検討する必要があると考える. 本研究では端末のみに着目した
– 43 –
第 5 章 結論
Presence 情報の取得を目指していたが, 将来的には全ての Presence 情報が端末によって
取得されると想定される. 規定されている Presence 情報を全て自動で取得するには, GPS
による位置情報や標高情報, クラウド型のスケジュールなどと連携を図ることで全ての
Presence 情報を取得することが実現できると考える. しかし, GPS に関しては屋外での位
置情報に関しての精度は高いが, 屋内の情報 (地下のデパート地下鉄など) に関しては精度が
かなり低くなっていしまう. 屋内の位置情報取得に関しては別の手法を考える必要がある.
– 44 –
謝辞
本研究を進めるにあたり，指導教員としてご指導頂きました高知工科大学情報学群の島村
和典教授に心より感謝いたします. 研究では私が悩んだ際には, 方向性や問題の解決方法な
どで的確なアドバイスをいただきました. また, 研究だけでなく, 就職活動や社会人としての
道の進み方, マナーについてもアドバイスをいただけたことを深く感謝しております. この
ような私を学部 3 年生から修士 2 年生まで面倒を見て下さり本当に感謝してもしきれない所
存です. また, 福本昌弘教授には学部時代には担任の先生として助言や指導をしてくださっ
たり, 研究論文では的確なご助言をいただき大変お世話になりました. この経験を糧に社会
人になっても活かしていきたい所存です. 横山和俊教授には大学院の講義や研究で大変お世
話になり, 親身に相談に乗ってくださったことで私の考えていなかった部分や新たな発見を
することができました. 大変お世話になりました. 福本昌弘教授, 横山和俊教授, 本研究論文
の副査をお引き受けくださり, 貴重なご助言, ご指摘をいただきました. 感謝の念を表し, こ
こに心より厚くお礼申し上げます.
修士 2 年の京極海氏, 島田裕幸氏, 辻際宗和氏は短いようで長かった 4 年間島村研究室で
共に過ごして来ました. 研究ではお互いに気づいた点を言い合ったり, アドバイス等をした
りして切磋琢磨して来ました. この 4 年間本当にお世話になりました. 心より感謝しており
ます. 卒業後は就職し別の道を歩みますが, お体には十二分に気をつけて日々をお過ごしく
ださい. 修士 1 年の竹本万里雄氏, 赤澤将太氏には私が研究や就職活動で忙しい時や不在の
間, 研究室の運営を任せっきりとなっていました. お二方が運営をしている間は就職活動, 研
究にに専念することができ, 無事に内定を勝ち取ることがで, 本論文も完成致しました. 心よ
り感謝しております. 赤澤氏には卒業までの間にバッティングフォームを教わりたいと思っ
ております. そして, 研究室の後輩として, 共に研究室活動に励んだ学部 4 年の上田安柚香
氏, 國和武司氏, 仙波紗和氏, 中島春菜氏, 三角隆太氏, 吉本圭佑氏, 渡部弘章氏には 2 年間
という短い間でしたがお世話になりました. 皆様は就職ということで, 場所は違えど同じ社
– 45 –
謝辞
会人として今後も切磋拓磨していきましょう. 学部 3 年の今田七海氏, 高野雅裕氏, 中村真
也氏, 宮野拓洋氏, 山崎秋音氏, 吉崎友拓氏には心より感謝致します. 最後に私を支えてくだ
さった皆様に心から感謝の気持ちと御礼を申し上げたく, 謝辞に代えさせて頂きます. また,
無理を言って大学院まで進学させてくださった両親に, 心より感謝申し上げます. 24 年間育
てて頂き本当にありがとうございました.
– 46 –
参考文献
[1] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h26/html/nc253110.html
総務省 情報通信の現況・政策の動向 閲覧日 平成 27 年 1 月 30 日.
[2] 松岡 紗代, 島村 和典, ”IP 電話における利用者の位置情報を用いた着信制御の研究”,
平成 21 年度学士学位論文.
[3] Sayo Matsuoka, Yuta Kinoshita, Kazunori Shimamura, ”Arraival control of IP
telephon using location management of an arrival person by the RFID sysstem”,
NEINE’08, pp310-313, 2008.
[4] 小笠原 一聡, 山下 寛晃, 島村 和典, ”Voice Call における Presence Service の方式の
一検討”, 平成 24 年度電気関係学会四国支部連合大会講演論文集, pp.189.
[5] http://www.gsma.com/network2020/rcs/ Rich Communications 閲覧日 2015 年 2
月 2 日.
[6] 小笠原 一聡, 島村 和典, ”Presence Service における機能向上に関する研究”, 平成 24
年度学士学位論文.
[7] NTT アドバンステクノロジ株式会社, ”やさしい NGN/IP ネットワーク技術箱”,
pp194, pp199, pp200.
[8] 小笠原 一聡, 島村 和典, ”次世代 Presence Service における Presence 取得方式の一検
討”, 平成 26 年度電気関係学会四国支部連合大会講演論文集, pp.332 .
[9] J. Rosenberg. ”A Data Model for Presence” ,RFC4479, Internet Engineering Task
Force, July 2006.
[10] ゴンザロ・カマリロ, ミゲール・A・マーチン 共著, 澤田 拓也, 鹿島 拓也, 海老原 成,
永松 良一, ”IMS 標準テキスト 改訂版”, pp.3-59 pp.410, pp.442 .
[11] RFC4480-RPID, ”https://tools.ietf.org/html/rfc4480”, 閲覧日 平成 27 年 1 月 28 日.
– 47 –