JP4705159B2 - プッシュ・トゥ・トーク移動体通信サービスにおける応答モード - Google Patents

Description

本発明は、プッシュ・トゥ・トーク移動体通信サービスにおいて使用可能な応答モードに関する。

オープン・モバイル・アライアンス（ＯＭＡ）として知られる業界団体は、標準的な移動体無線通信ネットワーク上でトランシーバーサービスに似たサービス、即ち、加入者がボタンを押すとすぐに１以上の他の加入者と接続可能なサービスの提供を可能にすることを目的とした、プッシュ・トゥ・トーク・オーバー・セルラ（ＰｏＣ）の仕様を開発してきた。ＰｏＣは現在、オープン・モバイル・アライアンスによって発行されている文書である「"Push to talk over Cellular (PoC) - Architecture", Candidate Version 1.0 - 17 March 2005」及び「"OMA PoC Control Plane", Candidate Version 1.0 - 17 March 2005」において規定されている。ＰｏＣ標準規格によれば、音声データは、パケットネットワークを介して搬送されるトーク・「バースト」(talk "bursts")を含み、ＰｏＣセッションを確立して制御するために使用されるシグナリングは、やはりパケットネットワークを介して搬送されるセッション開始プロトコル（ＳＩＰ）シグナリングを含む。ＰｏＣは、モバイルオペレータのネットワーク内に提供されるＩＰマルチメディアサブシステム（ＩＭＳ）基盤に依拠している。ＰｏＣは、一般的なプッシュ・トゥ・トーク（ＰＴＴ）サービスの特定の実施形である。

図１は、ＵＥ−Ａ及びＵＥ−Ｂとして識別される無線端末（ＳＩＰクライアント）のペア間でＰｏＣセッションを促進(facilitate)するＰｏＣ基盤を、極めて基本的な用語において、示す。ＵＥは、それぞれの無線アクセスネットワーク（ＲＡＮ−Ａ及びＲＡＮ−Ｂ）にアタッチしており、ＲＡＮ−Ａ及びＲＡＮ−Ｂは同様に、ＩＰバックボーンを含むパケット交換方式のコアネットワークに接続している。ＳＩＰシグナリングは、ＰｏＣサーバとして機能するＳＩＰアプリケーションサーバを含むＩＭＳを介して、ルーティングされる。ＵＥは、それぞれのＰｏＣサーバに登録されている（なお、両方のＵＥが同一のＰｏＣサーバに登録されることも可能である）。

ＰｏＣの基底に存在する基本的な概念は、あるユーザがほとんど瞬間的に他のユーザに接続することを可能にしたいという欲求であり、これにより、ユーザはコールボタンを押して発声するだけで、彼又は彼女の声が他のユーザの端末上で即座に再生される。しかしながら、このことは少なくとも被呼側の観点からは常に望ましいわけではないかもしれないということが、プッシュ・トゥ・トークサービスの開発における極めて初期の段階で認識された。そこで、従来の電話呼のために提供されるのと略同様の方法で、被呼端末における着信音の再生が提供されるようになった（プッシュ・トゥ・トークサービスはそれでも極めて迅速にセッションを確立し、これは従来の電話呼が確立されるよりもかなり迅速である）。そして、ユーザには、自動応答モード又は手動（着信音）応答モードのいずれかを選択する選択肢が与えられた。

ＰｏＣ標準の最新バージョンによれば、ユーザ（ユーザＢ）は自己のローカルＰｏＣサーバに、自動応答モードの適用を望む他のユーザ（ユーザＡ）の識別情報に関する「ホワイト」リストを登録する。ホワイトリスト上のユーザのいずれかによってＰｏＣセッションが要求された場合には、この要求がユーザＢのローカルＰｏＣサーバによって認識され、このＰｏＣサーバは、ユーザＢへ転送されるＳＩＰ ＩＮＶＩＴＥメッセージ中に自動応答フラグを含ませる。ユーザＢの端末はそのフラグを検出し、ＳＩＰ ２００ＯＫ（応答）メッセージを自動的に返す。そしてセッションが確立される。発呼側のユーザがホワイトリスト上にない（或いは、ホワイトリストが定義されていない）場合、ユーザＢの端末へ転送されるＳＩＰ ＩＮＶＩＴＥメッセージ中に手動フラグが含まれる。このフラグは端末によって検出され、着信音が再生される。ユーザが応答するまで、端末はＳＩＰ ２００ＯＫをローカルＰｏＣサーバへ送信しない。ＩＥＴＦのドラフト「"A Session Initiation Protocol (SIP) Event Package and Data Format for various settings in support for the Push-to-talk Over Cellular (PoC) service", Miguel-Angel Garcia-Martin, draft-garcia-sipping-poc-isb-am-01」には、ホワイトリスト上のユーザに対して適用可能な応答モードをローカルＰｏＣサーバに通知する方法が記載されている。ＰｏＣ標準に規定されているＳＩＰ ＰＵＢＬＩＳＨメッセージを使用して所望のモードをＰｏＣサーバへ信号伝達することにより、ユーザは、手動応答モードと自動応答モードとを切り替えることができる。

自動応答モードの設定とセッションの確立とを含むシグナリングプロセスを、図２に示す。ユーザプレーンにおけるシグナリングフロー（例えば、トーク・バースト・コントロールプロトコル(Talk Burst Control Protocol)のメッセージの交換）は、図中に示されていない。図中に示されるステップは以下の通りである。

１．ＰｏＣクライアントＢは、ネットワーク内でＰＵＢＬＩＳＨリクエストを用いて、自動モードに設定する。
２．ＰｏＣサーバＢは、２００「ＯＫ」レスポンスを用いて自動応答モードの設定に対して確認応答を返し、「自動」設定を記憶する。

ＰｏＣユーザＡがＰｏＣボタンを押した場合は、ステップは以下の通りである。

３．ＰｏＣクライアントＡはＰｏＣユーザＢをＰｏＣセッションに招待することを決定し、ＰｏＣサーバＡへＩＮＶＩＴＥリクエストを送信する。
４．ＰｏＣサーバＡは、ＰｏＣユーザＢのホームネットワーク内のＰｏＣサーバＢへＩＮＶＩＴＥリクエストを送信する。
５．ＰｏＣサーバＢはＰｏＣユーザＡを許可(authorize)し、設定された応答モードを選択し、１８３「Ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ」レスポンスをＰｏＣサーバＡへ送信する。
６．ＰｏＣサーバＡは２００ＯＫレスポンスをユーザＡへ送信し、ＰｏＣユーザＡは通話開始可能であるという指示情報を受信する。
７．ＰｏＣサーバＢはＩＮＶＩＴＥリクエストをＰｏＣクライアントＢへ送信する。ＩＮＶＩＴＥリクエストは、自動応答モードの要求を含む。
８．クライアントＢは、ＰｏＣユーザＢに何も要求せずに招待を受け付ける。
９．ＰｏＣサーバＢは、２００ＯＫをＰｏＣサーバＡへ転送する。

ＰｏＣ標準は、被呼側のユーザが指定した手動応答モードの設定を発呼側が覆す（無効にする）ことを許可するメカニズムを規定している。これは、ＰｏＣセッションを開始する発呼側のユーザが送信するＳＩＰ ＩＮＶＩＴＥメッセージ中に「ＭＡＯ」パラメータを含めることを伴う。被呼側の端末でＭＡＯパラメータを含むＩＮＶＩＴＥが受信されると、その端末は、手動モードの無効化を発呼側のユーザに許可するか否かを自動的に判定する。許可する場合、２００ＯＫ応答がローカルＰｏＣサーバへ自動的に返され、被呼側のユーザへ転送されるＩＮＶＩＴＥはＭＡＯパラメータを含む。許可しない場合、着信音が再生され、被呼側のユーザが応答した場合にのみその時に応答メッセージが送出される。

本発明の発明者は、手動応答モードの設定を無効化するための現在のメカニズムに加えて、被呼側の端末における自動応答モードの設定を発呼側が無効化することを許可する、ＰｏＣにおけるメカニズムを提供することが望ましいと認識した。この追加的な特徴は、例えば、自己の言葉が秘密にされることを発呼側が望み、聞こえる範囲に人々がいるにも関わらず被呼側の端末上で自己の言葉が再生されることを回避したいと望む場合に、有用である。無効化メカニズムに関する要求は、実行中のＰｏＣセッションへＰｏＣユーザが招待される場合や、事前に確立されたセッションを使用してＰｏＣセッションを開始する場合にも当てはまる。

本発明の第１の態様によれば、移動体無線通信ネットワークを介したプッシュ・トゥ・トークサービスを動作させる方法であって、移動体無線端末のユーザは、少なくとも何人かの他のユーザに対して、着信するセッションの招待メッセージについて自動応答モード又は手動応答モードを選択可能であり、当該方法は、
発呼側から被呼側へ送信されるプッシュ・トゥ・トークセッションの招待メッセージ中に手動応答モードのリクエストを含めるステップと、
前記被呼側にサービスを提供するプッシュ・トゥ・トークサーバにおいて前記セッションの招待メッセージが受信されると、前記被呼側のためのいかなる自動応答モード設定にも関わらず、前記手動応答モードのリクエストを含む前記招待メッセージを前記被呼側へ転送するステップと、
前記被呼側において前記招待メッセージを受信し、前記被呼側の端末においてアラートを生成するステップと、
を備えることを特徴とする方法が提供される。

好適には、プッシュ・トゥ・トークセッションを確立して制御するために使用されるシグナリングプロトコルはセッション開始プロトコルである。前記手動応答モードのリクエストを含む前記招待メッセージは、セッション開始プロトコルのＩＮＶＩＴＥメッセージ又はＲＥＦＥＲメッセージであり得る。

プッシュ・トゥ・トークセッションの前記招待メッセージは、前記プッシュ・トゥ・トークサーバによって実行される許可手順に続いてのみ、前記プッシュ・トゥ・トークサーバによって前記被呼側へ転送され得る。本方法はまた、前記発呼側にサービスを提供するプッシュ・トゥ・トークサーバにおいて許可手順を実行するステップを備えてもよく、前記リクエストは、許可が承認された場合にのみ、前記被呼側にサービスを提供する前記プッシュ・トゥ・トークサーバへ転送される前記招待メッセージ中に含まれる。２つの許可手順の一方又は両方は、前記発呼側の識別情報及び前記被呼側の識別情報のうちの少なくとも一方を、（一方又は両方の）前記プッシュ・トゥ・トークサーバに事前に記憶された識別情報の１以上のリストと比較することによって、実行され得る。

好適には、本方法は、手動応答モードを要求するユーザプロンプトを前記発呼側において受信するステップを備え、その結果、前記発呼側において前記リクエストを前記招待メッセージに含める。或いは、前記リクエストを含めることは、例えば前記発呼側における事前設定の結果として、自動的に実行されてもよい。

本発明は、特に、プッシュ・トゥ・トーク・オーバー・セルラサービスに対して適用可能である。

本発明の第２の態様によれば、プッシュ・トゥ・トーク対応の移動体無線端末を動作させる方法であって、当該端末によって通信相手の端末へ送信される招待メッセージ中に手動応答モードのリクエストを含めるステップを備えることを特徴とする方法が提供される。

本発明の第３の態様によれば、移動体無線通信ネットワーク内のプッシュ・トゥ・トークサーバを動作させる方法であって、
手動応答モードのリクエストを含むプッシュ・トゥ・トークの招待メッセージを発呼側のクライアント端末から受信するステップと、
前記手動応答モードのリクエストを含む前記リクエストを被呼側のクライアント端末へ転送するステップと、
セッション確立を進行させる前に前記被呼側のクライアント端末からの応答メッセージの受信を待つステップと、
を備えることを特徴とする方法が提供される。

本発明の第４の態様によれば、移動体無線端末であって、
移動体無線通信ネットワークによって促進されるプッシュ・トゥ・トークセッションへの当該端末の参加を促進するように構成されるプロセッサ及びメモリと、
ユーザが前記プロセッサ及び前記メモリとやり取りできるようにするユーザインタフェースと、
を備え、
前記プロセッサは、
プッシュ・トゥ・トークセッションを開始させるユーザ入力を前記ユーザインタフェースから受信し、
被呼側の端末へ送信するためのプッシュ・トゥ・トークの招待メッセージを生成し、
手動応答モードのリクエストを前記招待メッセージに含め、
前記招待メッセージを前記被呼側の端末へ送信する
ように適合される
ことを特徴とする移動体無線端末が提供される。

本発明の第５の態様によれば、無線移動体端末にプッシュ・トゥ・トークサービスを提供する移動体無線通信ネットワーク内で使用するためのプッシュ・トゥ・トークサーバであって、
第２の無線移動体端末へ宛てられた、手動応答モードのリクエストを含むことができるプッシュ・トゥ・トークの招待メッセージを第１の無線移動体端末から受信するための入力部と、
受信したプッシュ・トゥ・トークの招待メッセージを宛先である前記第２の無線移動体端末へ転送する出力部と、
受信した招待メッセージが手動応答モードのリクエストを含むか否かを判定し、含む場合に前記第２の無線移動体端末のために自動応答モードが設定されていれば、前記自動応答モードの設定を無効化し、前記手動応答モードのリクエストを含む前記招待メッセージを、前記出力部を介して前記第２の無線移動体端末へ転送するようにプログラムされたプロセッサと、
を備えることを特徴とするプッシュ・トゥ・トークサーバが提供される。

上では図１を参照して、プッシュ・トゥ・トーク・オーバー・セルラ（ＰｏＣ）サービスを説明してきた。また、図２を参照して、手動応答モードの無効化について論じてきた。以下の議論は、追加的な無効化の特徴、即ち、自動応答モードを無効化する特徴の導入を提案する。自動応答モードを無効化する特徴の必要性は、これまでは認識されていなかったものである。当業者であれば、この新しい特徴を広範に使用するためには、ＰｏＣ仕様の修正及び拡張の少なくとも一方が必要であるということを認識できよう。

第１のＰｏＣユーザ（ユーザＡ）が手動応答モードを使用して第２のＰｏＣユーザ（ユーザＢ）と通信したいと望む場合、即ち、会話を立ち聞きできる他人が誰もいない場所にユーザＢが所在するまでは会話したくないとユーザＡが望む場合、ユーザＡは、ユーザＢへ送信される招待（メッセージ）中に、ユーザＢが設定したかもしれないあらゆる自動応答モードを無効化して手動応答モードを使用するというリクエストを含めることができる。図３は、ＰｏＣユーザＡが他のＰｏＣユーザＢをＰｏＣセッションに招待し、手動応答モードのリクエストを招待メッセージ中に含める場合の、単純化したシグナリングフローの例を示す。このリクエストは、ＰｏＣ仕様において提供されている、既存の手動応答モードのリクエストの形式を持つ（但し、現在は、ユーザＡのローカルＰｏＣサーバにおいてのみ、招待メッセージに追加することが意図されている）。

応答モードは、以下のように設定される。

１．ＰｏＣクライアントＢは、ネットワーク内でＰＵＢＬＩＳＨリクエストを用いて、自動モードに設定する。
２．ＰｏＣサーバＢは、２００「ＯＫ」レスポンスを用いて自動応答モードの設定に対して確認応答を返し、「自動」設定を記憶する。

ＰｏＣユーザＡが自己の端末上のＰｏＣボタンを押した場合は、ステップは以下の通りである。

３．ＰｏＣクライアントＡはＰｏＣユーザＢをＰｏＣセッションに招待することを決定し、ＰｏＣサーバＡへＩＮＶＩＴＥリクエストを送信する。クライアントＡにおいて手動応答モードがＩＮＶＩＴＥリクエスト中に含められる。
４．ＰｏＣサーバＡは、ＰｏＣユーザＢのホームネットワーク内のＰｏＣサーバＢへＩＮＶＩＴＥリクエストを送信する。手動応答モードがＩＮＶＩＴＥリクエスト中に含まれている。
５．ＰｏＣサーバＢは、ＩＮＶＩＴＥリクエストをＰｏＣクライアントＢへ送信する。ＩＮＶＩＴＥリクエストは、ＰｏＣサーバＡからのＩＮＶＩＴＥリクエスト中で受信された、手動応答モードのリクエストを含む。設定されている応答モードの代わりに手動応答モードの指示情報を含めることは、ＰｏＣサーバＢにおける許可(authorisation)を条件としてもよい。即ち、ＰｏＣサーバＢは、ユーザＡによる自動応答モードの無効化をユーザＢが許可しているか否かを判定する。
６．ＰｏＣクライアントＢは、１８０ＲｉｎｇｉｎｇレスポンスをＰｏＣサーバＢへ送信し、ＰｏＣセッションへの招待が受信されたということをＰｏＣユーザＢに示す。
７．ＰｏＣサーバＢは、１８０「Ｒｉｎｇｉｎｇ」レスポンスをＰｏＣサーバＡへ送信する。
８．ＰｏＣサーバＡは、１８０「Ｒｉｎｇｉｎｇ」レスポンスをＰｏＣクライアントＡへ送信する。ＰｏＣクライアントＡは、ＰｏＣユーザＢが招待について通知されており、ＰｏＣクライアントＢがＰｏＣユーザＢによる受け付けを待っていること、例えばクライアントＢにおいて呼出音が再生されていることを、ＰｏＣユーザＡに示す。
９．ユーザＢが招待を受け付けると、ＰｏＣクライアントＢは、ＩＮＶＩＴＥリクエストをＰｏＣサーバＢへ送信する。
１０．ＰｏＣサーバＢは、２００ＯＫをＰｏＣサーバＡへ転送する。
１１．ＰｏＣサーバＡは、２００ＯＫレスポンスをユーザＡへ送信し、ＰｏＣユーザＡは、通話開始可能であることを示すものを受け取る。こうして、ＰｏＣセッションが確立される。

ここに記載された手順によって、発呼側のクライアントであるＰｏＣクライアントＡが、クライアントＢのための応答モードに関してＰｏＣサーバＢによってなされる決定に対して影響を与えることが可能であるということが、容易に認識できるであろう。

ここに記載された手順は同様に、実行中のＰｏＣセッションに参加するようにＰｏＣユーザが招待されるシナリオ、及び事前に確立されたセッションを使用してＰｏＣセッションが開始されるシナリオに対しても適用可能である。後者の場合、上述のアプローチとの重要な違いは、手動応答モードのリクエストが、ＩＮＶＩＴＥメッセージ中ではなく、ＰｏＣユーザを招待するＰｏＣクライアントによって送信されるＲＥＦＥＲリクエスト中に含まれるということだけである。

当業者であれば、本発明の範囲から逸脱することなく、上述の実施形態に対して多用な修正を施すことが可能であるということを認識できよう。

プッシュ・トゥ・トーク・オーバー・セルラサービスを促進する移動体無線通信ネットワークを概略的に示す図である。 自動応答モードにおけるセッション確立に関連する、図１のネットワークにおけるシグナリングを示す図である。 セッション確立中の、自動応答モードを無効化する手順に関連する、図１のネットワークにおけるシグナリングを示す図である。

Claims (10)

1. 移動体無線通信ネットワークを介したプッシュ・トゥ・トークサービスを動作させる方法であって、移動体無線端末のユーザは、少なくとも何人かの他のユーザに対して、着信するセッションの招待メッセージについて自動応答モード又は手動応答モードを選択可能であり、当該方法は、
   発呼側から被呼側へ送信されるプッシュ・トゥ・トークセッションの招待メッセージ中に、前記被呼側によって選択されたあらゆる自動応答モードを無効化して手動応答モードが使用されるようにするリクエストを含めるステップと、
   前記被呼側にサービスを提供するプッシュ・トゥ・トークサーバにおいて前記セッションの招待メッセージが受信されると、前記被呼側のためのいかなる自動応答モード設定にも関わらず、前記リクエストを含む前記招待メッセージを前記被呼側へ転送するステップと、
   前記被呼側において前記招待メッセージを受信し、前記被呼側の端末においてアラートを生成するステップと、
   を備えることを特徴とする方法。
2. プッシュ・トゥ・トークセッションを確立して制御するために使用されるシグナリングプロトコルはセッション開始プロトコルであり、
   前記リクエストを含む前記招待メッセージは、セッション開始プロトコルのＩＮＶＩＴＥメッセージ及びＲＥＦＥＲメッセージのうちのいずれかである
   ことを特徴とする請求項１に記載の方法。
3. プッシュ・トゥ・トークセッションの前記招待メッセージは、前記プッシュ・トゥ・トークサーバによって実行される許可手順に続いてのみ、前記プッシュ・トゥ・トークサーバによって前記被呼側へ転送されることを特徴とする請求項１又は２に記載の方法。
4. 前記発呼側にサービスを提供するプッシュ・トゥ・トークサーバにおいて許可手順を実行するステップを備え、
   前記リクエストは、許可が承認された場合にのみ、前記被呼側にサービスを提供する前記プッシュ・トゥ・トークサーバへ転送される前記招待メッセージ中に含まれる
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記許可手順は、前記発呼側の識別情報及び前記被呼側の識別情報のうちの少なくとも一方を、前記プッシュ・トゥ・トークサーバに事前に記憶された識別情報の１以上のリストと比較することによって、実行されることを特徴とする請求項３又は４に記載の方法。
6. 手動応答モードを要求するユーザプロンプトを前記発呼側において受信するステップを備え、その結果、前記発呼側において前記リクエストを前記招待メッセージに含めることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記リクエストを前記発呼側において自動的に含めるステップを備えることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
8. 前記プッシュ・トゥ・トークサービスはプッシュ・トゥ・トーク・オーバー・セルラサービスであることを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 移動体無線通信ネットワーク内のプッシュ・トゥ・トークサーバを動作させる方法であって、
   被呼側のクライアント端末のために選択されたあらゆる自動応答モードを無効化して手動応答モードが使用されるようにするリクエストを含むプッシュ・トゥ・トークの招待メッセージを発呼側のクライアント端末から受信するステップと、
   前記リクエストを含む前記招待メッセージを前記被呼側のクライアント端末へ転送するステップと、
   セッション確立を進行させる前に前記被呼側のクライアント端末からの応答メッセージの受信を待つステップと、
   を備えることを特徴とする方法。
10. 無線移動体端末にプッシュ・トゥ・トークサービスを提供する移動体無線通信ネットワーク内で使用するためのプッシュ・トゥ・トークサーバであって、
    第２の無線移動体端末へ宛てられた、前記第２の無線移動体端末によって選択されたあらゆる自動応答モードを無効化して手動応答モードが使用されるようにするリクエストを含むプッシュ・トゥ・トークの招待メッセージを第１の無線移動体端末から受信するための入力部と、
    受信したプッシュ・トゥ・トークの招待メッセージを宛先である前記第２の無線移動体端末へ転送する出力部と、
    受信した招待メッセージが前記リクエストを含むか否かを判定し、含む場合に前記第２の無線移動体端末のために自動応答モードが設定されていれば、前記自動応答モードの設定を無効化し、前記自動応答モードの無効化リクエストを含む前記招待メッセージを、前記出力部を介して前記第２の無線移動体端末へ転送するようにプログラムされたプロセッサと、
    を備えることを特徴とするプッシュ・トゥ・トークサーバ。

Images