(57)【要約】  手動応答無視モード実行過程を簡略化するためのプッシュツートークオーバーセルラーシステムユーザの応答モードによる呼処理システム及び方法を提供する。本発明は、プッシュツートークオーバーセルラーシステムユーザの応答モードによる呼処理システム及び方法に関し、手動応答無視を指すインジケーターを新しいデータフィールド形態でリアルタイム転送制御プロトコルのペイロードに挿入するデータフォーマットを定義し、ＰｏＣ通話要請者が受信側ＰｏＣユーザの応答モードに関係なく通話を連結できる手動応答無視（Manual Answer Override）を指示すれば、要請確認手続を経ることなく、直ちに自動応答モードを行うことができると同時に、受信側ＰｏＣユーザが、自身のＰｏＣ端末機にホームＰｏＣサーバーと事前セッションを設定した場合は、一層早く呼処理が行われることができる。
2008514155.tif 000002
【特許請求の範囲】
【請求項１】
プッシュツートークオーバーセルラー（Push-to talk over Cellular：ＰｏＣ）網の手動応答無視モードの呼処理システムにおいて、
送信側ＰｏＣクライアントと、手動応答無視モード指示子（ＭＡＯ indication）が含まれたＰｏＣ通話要請メッセージを受信側ＰｏＣサーバーに転送する送信側ＰｏＣサーバーとを備える送信側ＰｏＣシステムと；
前記送信側ＰｏＣサーバーから受信した前記ＰｏＣ通話要請メッセージに含まれた前記手動応答無視モード指示子（ＭＡＯ indication）を認識し、前記ＰｏＣ通話要請メッセージに対する応答メッセージを前記送信側ＰｏＣシステムに転送する受信側ＰｏＣサーバーと、手動応答無視モード指示子（ＭＡＯ indication）を含むトークバースト信号を前記受信側ＰｏＣサーバーから受信する受信側ＰｏＣクライアントとを備える受信側ＰｏＣシステムと；
を含むことを特徴とする呼処理システム。
【請求項２】
前記手動応答無視モード指示子（ＭＡＯ indication）は、前記送信側ＰｏＣクライアント、前記送信側ＰｏＣサーバー、及び受信側ＰｏＣサーバーのうちいずれか１つにより前記トークバースト信号に含まれることを特徴とする請求項１に記載の呼処理システム。
【請求項３】
前記トークバースト信号は、ＲＴＣＰ（Real-time Transport control protocol）ペイロード形態で具現されることを特徴とする請求項１に記載の呼処理システム。
【請求項４】
前記ＲＴＣＰは、バージョン情報フィールド、サブタイプ情報フィールド、長さフィールド、一般転送関連情報フィールド、ＰｏＣユーザのアドレスフィールド、名前情報フィールド、及び手動応答モード指示子ＭＡＯ（Manual Answer Override indication）情報フィールドを含むことを特徴とする請求項３に記載の呼処理システム。
【請求項５】
前記受信側ＰｏＣサーバーは、前記ＰｏＣ通話要請メッセージを前記受信側ＰｏＣクライアントに転送せず、前記応答メッセージを前記送信側ＰｏＣシステムに転送することを特徴とする請求項１に記載の呼処理システム。
【請求項６】
前記トークバースト信号は、前記送信側ＰｏＣシステムから前記受信側ＰｏＣサーバーに転送されることを特徴とする請求項１に記載の呼処理システム。
【請求項７】
プッシュツートークオーバーセルラー（Push-to talk over Cellular：ＰｏＣ）網の手動応答無視モードの呼処理方法において、
手動応答無視モード指示子（ＭＡＯ indication）が含まれたＰｏＣ通話要請メッセージが送信側ＰｏＣサーバーから受信側ＰｏＣサーバーに送信される段階と；
受信側ＰｏＣサーバーが、前記ＰｏＣ通話要請メッセージに含まれた前記手動応答モード指示子を認識し、前記ＰｏＣ通話要請メッセージに対する応答メッセージを前記送信側Ｐｏｃサーバーに転送する段階と；
受信側ＰｏＣクライアントが、手動応答無視モード指示子（ＭＡＯ indication）を含むトークバースト信号を前記受信側ＰｏＣサーバーから受信する段階と；
を含むことを特徴とする呼処理方法。
【請求項８】
前記手動応答無視モード指示子（ＭＡＯ indication）は、前記送信側ＰｏＣクライアント、前記送信側ＰｏＣサーバー、及び受信側ＰｏＣサーバーのうちいずれか１つにより前記トークバースト信号に含まれることを特徴とする請求項７に記載の呼処理方法。
【請求項９】
前記受信側ＰｏＣサーバーは、前記ＰｏＣ通話要請メッセージを前記受信側ＰｏＣクライアントに転送せず、前記応答メッセージを前記送信側ＰｏＣシステムに転送することを特徴とする請求項７に記載の呼処理方法。
【請求項１０】
前記トークバースト信号は、ＲＴＣＰ（Real-time Transport control protocol）ペイロード形態で具現されることを特徴とする請求項７に記載の呼処理方法。
【請求項１１】
前記ＲＴＣＰは、バージョン情報フィールド、サブタイプ情報フィールド、長さフィールド、一般転送関連情報フィールド、ＰｏＣユーザのアドレスフィールド、名前情報フィールド、及び手動応答モード指示子ＭＡＯ（Manual Answer Override indication）情報フィールドを含むことを特徴とする請求項７に記載の呼処理方法。
【請求項１２】
前記トークバースト信号は、前記送信側ＰｏＣシステムから前記受信側ＰｏＣサーバーに転送されることを特徴とする請求項７に記載の呼処理方法。
【請求項１３】
プッシュツートークオーバーセルラー（Push-to talk over Cellular：ＰｏＣ）網の手動応答無視モードを行う方法において、
ＰｏＣサーバーから手動応答無視モード指示子（ＭＡＯ indication）を含むトークバースト信号を受信する段階と；
前記トークバースト信号に含まれた手動応答無視モード指示子（ＭＡＯ indication）を検出し、前記手動応答無視モード指示子（ＭＡＯ indication）は、前記ＰｏＣサーバーから前記ＰｏＣクライアントに伝達される最初の手動応答無視モード情報である段階と；  を含むことを特徴とする方法。
【請求項１４】
前記トークバースト信号は、ＲＴＣＰ（Real-time Transport control protocol）ペイロード形態で具現されることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ＲＴＣＰは、バージョン情報フィールド、サブタイプ情報フィールド、長さフィールド、一般転送関連情報フィールド、ＰｏＣユーザのアドレスフィールド、名前情報フィールド、及び手動応答モード指示子ＭＡＯ（Manual Answer Override indication）情報フィールドを含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
前記手動応答無視モード指示子（ＭＡＯ indication）の検出によって手動応答無視モードの使用が許可されたユーザからＰｏＣ通話が要請されることを前記Ｐｏｃクライアントのユーザに表示する段階をさらに含むことを特徴とする請求項１３に記載の方法。
【請求項１７】
前記表示段階は、前記ＰｏＣ通話要請者に関する情報を表示する段階をさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記ＰｏＣ通話要請者に関する情報は、通話要請者の名前を含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記ＰｏＣ通話要請者に関する情報は、通話要請者のＰｏＣアドレスを含むことを特徴とする請求項１７に記載の方法。
【請求項２０】
プッシュツートークオーバーセルラー（Push-to talk over Cellular：ＰｏＣ）網で手動応答無視モードを行うＰｏＣクライアントにおいて、
ＰｏＣサーバーから手動応答無視モード指示子（ＭＡＯ indication）を含むトークバースト信号を受信し、前記トークバースト信号に含まれた手動応答無視モード指示子（ＭＡＯ indication）を検出し、前記手動応答無視モード指示子（ＭＡＯ indication）は、前記ＰｏＣサーバーから前記ＰｏＣクライアントに伝達される最初の手動応答無視モード情報であることを特徴とするＰｏＣクライアント。
【請求項２１】
前記トークバースト信号は、ＲＴＣＰ（Real-time Transport control protocol）ペイロード形態で受信されることを特徴とする請求項２０に記載のＰｏＣクライアント。
【請求項２２】
前記ＲＴＣＰは、バージョン情報フィールド、サブタイプ情報フィールド、長さフィールド、一般転送関連情報フィールド、ＰｏＣユーザのアドレスフィールド、名前情報フィールド、及び手動応答モード指示子ＭＡＯ（Manual Answer Override indication）情報フィールドを含むことを特徴とする請求項２０に記載のＰｏＣクライアント。
【請求項２３】
前記手動応答無視モード指示子（ＭＡＯ indication）の検出によって手動応答無視モードの使用が許可されたユーザからＰｏＣ通話が要請されることを前記ＰｏＣクライアントのユーザに表示する段階をさらに含むことを特徴とする請求項２０に記載のＰｏＣクライアント。
【請求項２４】
前記表示段階は、前記ＰｏＣ通話要請者に関する情報を表示する段階をさらに含むことを特徴とする請求項２３に記載のＰｏＣクライアント。
【請求項２５】
前記ＰｏＣ通話要請者に関する情報は、通話要請者の名前を含むことを特徴とする請求項２４に記載のＰｏＣクライアント。
【請求項２６】
前記ＰｏＣ通話要請者に関する情報は、通話要請者のＰｏＣアドレスを含むことを特徴とする請求項２４に記載のＰｏＣクライアント。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プッシュツートークオーバーセルラーシステムユーザの応答モードによる呼処理システム及び方法に関する。
【背景技術】
【０００２】
移動通信が画期的に発展し、通信網が拡大するにしたがって、携帯電話を用いたサービスやアプリケーションがさらに拡張され、多様化されている。また、ユーザの要求も多様化され、単純な通話サービスから離れて位置サービス、マルチメディアサービス、ＰＴＴサービスなどに拡大されている。特に、ＰＴＴサービスは、従来、無線機やＴＲＳなどで可能であったグループ通話と音声通話はもちろん、インスタントメッセンジャー、状態表示など多様な付加機能をサポートする。
【０００３】
現在、このようなＰＴＴ（Push To Talk）概念を、移動通信網を用いてサービスするＰｏＣ（Push-to-talk over cellular：以下、ＰｏＣという）サービスに対する標準制定が活発に論議されている。既存の移動通信サービスと区別されるＰｏＣサービスの特徴の１つは、ユーザが複数のセッションに属していて、必要に応じてセッション間を移動しつつ通話をすることができるという点である。ユーザが複数のセッションを移動しつつ通話をすることができなければならないという要求事項は、移動通信サービスを定義している団体であるＯＭＡ（Open Mobile Alliance）の要求事項に明示されている。
【０００４】
以下、一般的なＰｏＣサービスシステムの構造を説明する。図１は、一般的なＰｏＣ（Push-to-talk over Cellular）基本構造を示す概念図である。図１を参照すれば、ＰｏＣクライアント１０は、移動端末に内蔵されるサービス要請者であり、一般的に、アクセス網２０を介してＳＩＰ（Session Initiation Protocol）及びＩＰ（Internet Protocol）マルチメディアをサポートする核心網であるＳＩＰ／ＩＰコア（core）３０網に連結される。
【０００５】
この時、ＰｏＣクライアント１０は、ＰｏＣユーザ端末機に常駐しながらＰｏＣサービスへの接続を可能にする。主な機能は、ＰｏＣユーザの側面からＰｏＣセッションを生成し、既存のセッションに参加し、セッションを終了するものである。その他、トークバーストを形成し伝達する機能、インスタントパーソナルアラート(Instant Personal alert)をサポートする機能、及びＰｏｃサービスに接続した時に認証する機能等の役目を行う。以下、特に言及がない限り、ＰｏＣクライアント１０という用語は、ＰｏＣサービス加入者と同じ意味として使われる。
【０００６】
ＳＩＰ／ＩＰ基盤のコア網は、ＰｏＣサービスをサポートするために、ＰｏＣサーバ６０、ＧＬＭＳ（Group List and Management System）５０、及びプレゼンスサーバ７０等に連結され、サービスを提供する。
【０００７】
この時、ＰｏＣサーバ６０は、ＰｏＣセッションを維持し管理するＰｏＣ管理機能（Controlling PoC Function）を行ったり、一対一の通話や多者間の通話のために開設されるＰｏＣセッションに参加するためのＰｏＣ参加機能（Participating ＰｏＣ Function）などの機能を有する。
【０００８】
前記ＰｏＣサーバは、ＰｏＣセッションを全般的に維持、管理するＰｏＣ管理機能（Controlling PoC Function）（以下、‘ＣＦ’という）と、各セッション間の維持管理を担当するＰｏＣ参加機能（Participating ＰｏＣ Function）（以下、‘ＰＦ’という）とに区分される。以下、各表を参照してさらに詳細に説明する。
【０００９】
【表１】
2008514155.tif 000003
【００１０】
ＣＦは、表１のように、ＰｏＣサーバの機能のうちＰｏＣセッションを総合的に管理する役目をし、特に、ＰｏＣクライアントの話す権利（floor）要請（発言権）を受け入れて、順序を定め、権限を付与し、任意のクライアントが要請したトークバースト（talk burst）をグループ呼び出しに参加した全ての他のクライアントに分配し、グループ呼び出しに参加したクライアントの情報を提供する。
【００１１】
ＰＦは、下記の表２のように、ＰｏＣセッションにおいてＣＦ及び各クライアントに関連したセッションを管理し、特に、クライアントが発言権を要求したり、ＣＦにおいてクライアントに発言権を付与する時、ＰＦが中継する役目をする。また、ＰＦは、ＣＦとクライアントとの間にメディアを中継する役目（１）、両者が異なるコーデックを使用している場合、トランスコーディングする役目（２）、及び同時セッションの場合、例えば１つのセッションにおいて話している時に他のセッションでも話す時、ＰｏＣユーザの選択によって１つをフィルタリングする役目（３）を行う。
【００１２】
【表２】
2008514155.tif 000004
【００１３】
前述のように構成されたＰｏＣシステムは、ＰｏＣユーザが自身の端末機を介してＧＬＭＳ４０にグループ及びグループメンバーに関する情報を入力することができ、または、ＧＬＭＳ４０から転送された個人あるいはグループ目録を用いて自身が呼出することができるＰｏＣユーザの情報を知ることができる。ＧＬＭＳにグループ及びグループメンバーの生成、修正及び管理をすることができる他の方法は、インターネットやイントラネットなどＰｏＣサービス提供者が信頼できる通信網を介して入力できる方法がある。
【００１４】
ＰｏＣ呼び出しサービスを利用するために、ＰｏＣユーザは、ＳＩＰ／ＩＰに自身のＰｏＣアドレスを登録する。この時、ＳＩＰ／ＩＰコアでは、ＰｏＣユーザの要請に基づいてＰｏＣユーザに関する情報を格納する。したがって、他のＰｏＣユーザがＰｏＣグループ呼び出しをしようとする時、前述したように、自身の情報をＳＩＰ／ＩＰコア網にまず登録し、ＧＬＭＳから転送されたグループ識別情報を用いて自身のＳＩＰ／ＩＰコア網に呼び出し要請をする。この時、ＳＩＰ／ＩＰコアは、要請するＰｏＣユーザ情報を用いてアドレス決定及びドメイン位置決定過程を実行した後、要請するＰｏＣユーザが登録されたホームＰｏＣサーバにＰｏＣ通話要請を伝達する。ＰｏＣサーバは、このようなＰｏＣ通話要請に対してＰｏＣセッション開設を準備し、ＧＬＭＳサーバから各々のユーザ情報を獲得した後、当該ＳＩＰ／ＩＰコア網に通話要請信号を伝達する。この時、イントラドメイン内のユーザに対する通話要請である場合、ＰｏＣサーバは、ＰＦ及びＣＦの機能を全て行う。通話要請されたＰｏＣユーザを管理するＰｏＣサーバは、自身に伝達されたＰｏＣユーザの情報を利用し、ＳＩＰ／ＩＰコア網の位置決定過程を実行した後、ＰｏＣユーザに通話要請をする。
【００１５】
本発明は、上記のように３ＧＰＰ（3rd Generation Partnership Project）や３ＧＰＰ２で標準化中であるか、完成されたＩＭＳ（IP multimedia Subsystem）網を利用し、半二重通信（half duplex）形態の通話とユーザのプレゼンス情報を用いて通話要請によるインスタント通話を可能にするＰｏＣシステムの通話を連結するための呼処理に関するものである。
【００１６】
以下、ＰｏＣ通話設定のための呼処理について送信側及び受信側観点別に区分して説明する。まず、送信側と受信側の設定によってＯＭＡで要求しているＰｏＣシステムの特徴は、次の通りである。
【００１７】
第一に、受信側は、ＰｏＣユーザの要求に応じて自身の応答モードを設定することができ、大きく自動応答モードと手動応答モードとに分類することができる。
【００１８】
自動応答モードは、受信側で指定したＰｏＣユーザリストに含まれれば、受信者の手動応答に代えてネットワークから送信側に直ちに応答を送ることを意味する。一方、手動応答モードは、自動応答ユーザリストに含まれていない場合、不明な場合、または受信者が全てのユーザに対して手動応答で設定した場合に該当し、ＰｏＣ通話要請は、受信ネットワークを経てユーザの端末まで転送され、ＰｏＣユーザの許諾により通話が連結されることを意味する。この時、各々の応答モードとリスト情報は、各ＰｏＣユーザのホームネットワークに属するＰｏＣサーバーに設定され、格納される。
【００１９】
第二に、ＰｏＣシステムは、ユーザのホームネットワーク内でＰｏＣサーバーとの連結設定可否によってオンデマンド(on-demand)セッションモードとあらかじめ決められた(pre-established) セッションモードとに分類される。あらかじめ決められた セッションモードは、ＰｏＣユーザが自身の要求によってＰｏＣクライアント（ＰｏＣ Client）と自身のホームネットワークに属するＰｏＣサーバーとの間にあらかじめ特定のセッションを設定することを意味する。このようなあらかじめ決められたセッションは、ＰｏＣユーザが、自身が使用するメディアパラメーターをＰｏＣサーバーと事前に交渉し、今後使用されるサーバー−クライアント間のメディアパラメーターを再交渉する必要なく、早い通話設定をするために必要な機能である。事前セッションの設定のためには、ＰｏＣクライアントがＳＩＰ  ＩＮＶＩＴＥのメソード（method）を通じて本文部（ＳＤＰ body）にサポートするメディアパラメーターを提供し、サーバーから提供されたメディアパラメーターに対する応答をすることによって具現され、サーバーからの応答メッセージに新しく設定される事前セッションの識別情報をコンファレンスＵＲＩ（conference ＵＲＩ）と共にＰｏＣユーザに回答するようになる。このような事前セッションを利用する場合、ＩＰアドレス、ポート番号、使用されるコーデック（codec）及びトークバーストの制御のためのプロトコル（talk burst control protocol）などの事前設定が可能である。
【００２０】
オンデマンドセッションモードは、ＰｏＣユーザが事前セッションを設定しない状態を意味し、他のＰｏＣユーザの招待メッセージを受けた後、ＰｏＣ呼連結手続を行うことを意味する。
【００２１】
一方、ＯＭＡで標準化中のＰｏＣスペックは、前述のような通信システムの基本的機能以外に、次のような特別な特徴を含む。まず、ＰｏＣシステムは、受信者があらかじめ設定した許可されたＰｏＣユーザに対してＰｏＣ受信者の応答モードに関係なく自動応答を送り、受信端末機で通話を連結する手動応答無視モード（Manual Answer Override、以下‘ＭＡＯ’という）の機能をサポートする。ＭＡＯの要請は、許可された通話要請者に限ってサポートされ、ＰｏＣ通話要請メッセージ（ＩＮＶＩＴＥ）にＭＡＯ指示子が含まれて伝達される。このようなＭＡＯ要請は、（事故や災難救護、命令など）緊急な目的及び公共サービス目的に考案された機能である。
【００２２】
次に、ＰｏＣシステムは、通話要請に対する応答モードの設定をネットワーク上のエレメントであるＰｏＣサーバー及びユーザ側の端末であるＰｏＣクライアントで共に行うことができる。
【００２３】
ネットワークで応答モードを設定する時、ＰｏＣクライアントが属しているホームネットワーク内でセッション参加機能（participating function、ＰＦ）をするＰｏＣサーバーで応答モードが具現される。このようなネットワーク側の応答モードを設定する場合、通話要請時に、ＰｏＣクライアントの応答モードをＰＦに反映してクライアントに連結した後、応答が行われる手続に比べて通話要請の手続を簡略化することができるという特徴がある。
【００２４】
次に、ＰｏＣユーザは、自身のクライアントを用いて応答モードを設定することができ、この時、自身のクライアントの応答モードがネットワーク上に設定された応答モードに優先されるという特徴がある。このような理由は、ＰｏＣユーザが端末機を介して自身の応答モードを変更し、ＰｏＣサーバーに応答モード更新を要求する時、無線接続網（Radio access network）やＩＰ核心網で信号遅延やエラーに起因してリアルタイムで応答モードが反映されない時に発生するプライバシー問題を解決するためである。すなわち、ＰｏＣサービスは、ユーザの応答モードをＰｏＣサーバー及びＰｏＣクライアントに共に設定することができ、ユーザの意志と同じＰｏＣクライアントの応答モードにより動作が決定される。
【００２５】
前記ＰｏＣシステムの様々な機能と特徴を考慮すれば、多様なＰｏＣ呼処理手続が発生することができる。本発明では、特にＰｏＣ通話受信側に事前セッションが設定され、ＰｏＣ送信側で手動応答無視を要求する一対一通話を要請した時、通話要請を受諾し、呼処理を行う手続及び方法に関するものである。
【００２６】
実際にＰｏＣ送信側で手動応答無視モードを要請する場合の大部分は、緊急状況の発生時であるが、実際に手動応答無視モードを要求する過程において不要な段階を行うようになるので、このため、時間遅延が発生するという問題点がある。
【００２７】
上記の問題点を把握するために、従来の技術を送信側と受信側とに区分して説明する。図２は、従来技術に係るＭＡＯのための送信側ＰｏＣ通話設定過程を示す流れ図であり、図３は、従来技術に係るＭＡＯのための受信側ＰｏＣ通話設定過程を示す流れ図である。図２及び図３は、ＰｏＣ通話送信者がＭＡＯ指示子を含んで呼処理を要請し、受信側に事前セッションが設定された場合、従来の技術で具現される通話送信側及び通話受信側の呼処理手続を各々示している。
【００２８】
まず、図２を参照すれば、ＰｏＣクライアントＡは、自身が招待しようとする受信者のＳＩＰアドレス情報を含む招待メッセージ（ＩＮＶＩＴＥ）要請をＳＩＰ／ＩＰコアＡに送る（ステップ１０１）。
【００２９】
この時、ＩＮＶＩＴＥ要請は、ＭＡＯであることを指示する情報エレメントを含み、ＤＨＣＰサーバーやＤＮＳサーバーなどでの経路質疑（query）を通じてＩＭＳ網内での該当サーバー（Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦ）を経由してＰｏＣ参加サーバーＡに伝達される（ステップ１０２）。
【００３０】
一般的な通話要請時、ＰｏＣユーザが連結されたＰｏＣ参加サーバーは、開設されるセッションのトークバーストを管理するＰｏＣ管理サーバーと分離して具現されることができるので、ステップ１０１及びステップ１０２から送られたＩＮＶＩＴＥ要請は、各ネットワークのＳＩＰ／ＩＰ核心網を経由してＰｏＣ管理サーバーＸに伝達される（ステップ１０３〜１０５）。
【００３１】
ＣＦを含む制御ネットワークは、前記ステップ１０５から伝達されたＩＮＶＩＴＥ要請メッセージを該当ＳＩＰ／ＩＰ核心網に伝達した後、応答メッセージを受信するようになる。受信側ネットワークから応答されるＳＩＰメッセージは、１ＸＸの臨時応答メッセージ（provisional response）や２ＸＸの成功応答メッセージ（successful response）または４ＸＸ〜６ＸＸなどのエラー応答メッセージであることができるが、本発明では、根本趣旨から逸脱しない範囲で正常的な呼処理手続を中心として説明する。
【００３２】
ステップ１０５以後、ＣＦは、自動応答（ＡＵＴＯ−ＡＮＳＷＥＲ）やＯＫ応答などで受信することができる。
【００３３】
選択的に、図２のように、ＡＵＴＯ−ＡＮＳＷＥＲ応答の場合、183セッションプログレス(183 Session progress)信号で受信することができ、これにより、通話要請者のＩＭＳ網でＰｏＣサーバーとクライアントとの間の連結を進行することができる。受信者の通話許諾信号は、最終的なＯＫ応答（response）として応答され、ＣＦとＰＦのＰｏＣサーバーを経由してＰｏＣクライアントＡに伝達するようになる（ステップ１０６〜１１０）。一方、ＣＦは、受信クライアントのＯＫ応答信号を受信した後、ＰｏＣ呼が連結されたことを判断し、クライアントＡに対してトークバースト発言権を付与する発言権付与（floor granted）信号を送るようになる。
【００３４】
ＰｏＣクライアントＡは、ＩＮＶＩＴＥ要請信号に対するＯＫ信号と発言権付与（floor granted）信号を受信した後、通話連結音をユーザに聞かせるに先立って、ＰｏＣクライアントのユーザがトークバーストを送る信号（send talk burst）をＲＴＣＰ（Real-time Transport Control Protocol）を用いてまず送信するようになる。この時、トークバースト送信（send talk burst）信号は、送信側ＰｏＣクライアントのＰｏＣアドレスとディスプレイ名称などの情報を含み、メディアベアラーの経路を利用するので、ＳＩＰ／ＩＰ核心網を経ることなく、転送されることができる。
【００３５】
トークバースト送信（send talk burst）信号を送った後、ＰｏＣクライアントは、通話連結をユーザに通知し、ユーザのメディア（代表的に音声）をＲＴＰプロトコルを用いて転送するようになる。
【００３６】
図３は、送信側通話手続に対応して事前セッションが設定された場合、ＭＡＯ要請が伝達された時、従来技術に係る受信側の手続を示す。ステップ２０１〜２０３は、ＭＡＯ要請が含まれたＩＮＶＩＴＥメッセージがＳＩＰ／ＩＰ核心網をＩＭＳ網の呼処理手続によって受信側ＰｏＣクライアントのホームネットワークに属するＰｏＣサーバーまで伝達される手続を示す。
【００３７】
この時、ＰｏＣ参加サーバーＢは、自身の応答モード設定値を有していることができるが、ＩＮＶＩＴＥ要請メッセージ内にＭＡＯ指示子を確認した後、通話要請ネットワークにＡＵＴＯ−ＡＮＳＷＥＲメッセージを伝達するようになる（ステップ２０４〜２０６）。
【００３８】
このようなＡＵＴＯ−ＡＮＳＷＥＲメッセージは、一般的に、前述したように、183セッションプログレス(183 Session progress)というＳＩＰメッセージとして管理ネットワーク（controlling network）に伝達される。ＰｏＣ参加サーバーＢは、ステップ２０４〜２０６の手続と共に、該当ＰｏＣアドレスを有するＰｏＣクライアントにＩＮＶＩＴＥまたはｒｅ−ＩＮＶＩＴＥ要請メッセージを伝達するようになる（ステップ２０７〜２０８）。ステップ２０７〜２０８は、ＰｏＣクライアントＢにＭＡＯ要請をするＰｏＣ通話要請が来たことを伝達する役目をし、この時、ＰｏＣクライアントＢは、ＰｏＣユーザの確認無しに自動でＯＫ応答を送るようになる（ステップ２０９〜２１０）。
【００３９】
該当ＯＫ応答を受信したＰｏＣ参加サーバーＢは、ＭＡＯ  ＩＮＶＩＴＥに対する応答メッセージを送信側ネットワークに伝達し、ＰｏＣ呼処理手続を完成するようにし（ステップ２１１〜２１５）、クライアントがメディアを転送するに先立って、ＰｏＣ通話者のＰｏＣアドレスやディスプレイ名称を含んで転送されるトークバースト受信（receiving talk burst）信号をＰｏＣクライアントＢに転送するようになる（ステップ２１７〜２１８）。
【００４０】
最後に、送信側から送ったメディア（音声）は、連結されたメディアベアラーでＲＴＰプロトコルを用いてクライアントＢに伝達され、通話が開始される。
【００４１】
図４は、前記ＰｏＣ呼要請のためのＩＮＶＩＴＥに含まれる情報を示す図である。前記送信側で要請するＩＮＶＩＴＥメッセージに含まれる情報要素として、ＰｏＣ通話要請者及び受信者のＰｏＣアドレス、クライアントやサーバーが提示するメディアパラメーター情報、ＰｏＣ通話であることを通知する指示子、ＰｏＣサーバーで設定する指示子、送受信ネットワーク両端で相互交渉するトークバースト制御プロトコル、及び選択的にＭＡＯ指示子などを含むことが分かる。
【００４２】
前記従来技術で説明した事前セッションが存在するクライアントに対するＭＡＯ通話要請処理手続は、ＰＦでＭＡＯ要請指示子を確認した後、ＡＵＴＯ−ＡＮＳＷＥＲを回答する手続を含んでいるが、送信側ネットワーク及びクライアント間の最終的なＰｏＣ通話連結に大きい影響を与えず、クライアントから受信されるＯＫ応答メッセージがＣＦと送信側ネットワークに到達した後、実際ＰｏＣ通話のためのメディアベアラーの連結及び発言権付与（floor granted）信号の伝達が行われる。
【００４３】
しかし、ＭＡＯを含む通話要請メッセージは、受信側ユーザの応答に関係なく進行されることができるという特徴があり、受信側クライアントにメディアが伝達されるに先立って送信側クライアントのＰｏＣアドレス情報とディスプレイ名称を表示するように、ＲＴＣＰ(Real-time Transport Control Protocol）を用いてトークバースト転送メッセージを送る機能があるので、図２のような従来の手続は、繰り返しの要請−応答シグナルリングに起因してＭＡＯ呼処理に対する最適化された手続とは言えない。特に、ＭＡＯのように緊急で且つ公共の目的のためのサービスでは、早い呼処理による通話が可能でなければならない。
【発明の開示】
【発明が解決しようとする課題】
【００４４】
従って、本発明は、前述のような問題点を解決するためになされたものであって、その目的は、緊急状況発生のように時間を争う場合に対処するために、手動応答無視モード実行過程を簡略化するためのプッシュツートークオーバーセルラーシステムユーザの応答モードによる呼処理システム及び方法を提供することにある。
【課題を解決するための手段】
【００４５】
上記目的を達成するために、本発明に係るプッシュツートークオーバーセルラー（Push-to talk over Cellular：ＰｏＣ）網の手動応答無視モードの呼処理システムは、送信側ＰｏＣクライアントと、手動応答無視モード指示子（ＭＡＯ indication）が含まれたＰｏＣ通話要請メッセージを受信側ＰｏＣサーバーに転送する送信側ＰｏＣサーバーとを備える送信側ＰｏＣシステムと；前記送信側ＰｏＣサーバーから受信される前記ＰｏＣ通話要請メッセージに含まれた前記手動応答無視モード指示子（ＭＡＯ indication）を認識し、前記ＰｏＣ通話要請メッセージに対する応答メッセージを前記送信側ＰｏＣシステムに転送する受信側ＰｏＣサーバーと、手動応答無視モード指示子（ＭＡＯ indication）を含むトークバースト信号を前記受信側ＰｏＣサーバーから受信する受信側ＰｏＣクライアントとを備える受信側ＰｏＣシステムと；を含む。
【００４６】
また、本発明に係るプッシュツートークオーバーセルラー（Push-to talk over Cellular：ＰｏＣ）網の手動応答無視モードの呼処理方法は、手動応答無視モード指示子（ＭＡＯ indication）が含まれたＰｏＣ通話要請メッセージが送信側ＰｏＣサーバーから受信側ＰｏＣサーバーに送信される段階と；受信側ＰｏＣサーバーが、前記ＰｏＣ通話要請メッセージに含まれた前記手動応答モード指示子を認識し、前記ＰｏＣ通話要請メッセージに対する応答メッセージを前記送信側Ｐｏｃサーバーに転送する段階と；受信側ＰｏＣクライアントが、手動応答無視モード指示子（ＭＡＯ indication）を含むトークバースト信号を前記受信側ＰｏＣサーバーから受信する段階と；を含む。
【発明の効果】
【００４７】
本発明によれば、ＰｏＣシステムの様々な機能と特徴を考慮する時、発生する多様なＰｏＣ呼処理手続のうち、特にＰｏＣ通話受信側に事前セッションが設定され、ＰｏＣ送信側で手動応答無視を要求する一対一通話を要請した時、通話要請を受諾し、呼処理をするために、従来の技術に比べて改善された手続を有するようにする手続及び方法を提案する。
【００４８】
一般的に、ＭＡＯ要請は、緊急通話や公共サービスなどの場合に使われる技術であるから、呼処理のための最も早い手続を要求するサービスである。
【００４９】
本発明は、このようなＭＡＯ通話要請に対してＲＴＣＰを利用した簡単なデータフィールドの追加により相対的に早い通話処理をするようにして、ＰｏＣユーザの側面で向上したサービスを提供され得るようにし、サービス提供者にも付随的なシグナリングを節約して、通信リソースを効率的に管理するようにする効果をもちらす。特に、ＰｏＣユーザの端末とＰｏＣサーバーとの間の応答モードが同期されないので、発生するレース（race）条件の環境下でもこれと関係なく具現されることができる早い通話処理方法を提示し、技術的波及効果が大きい。
【発明を実施するための最良の形態】
【００５０】
以下、本発明の属する技術分野においての通常の知識を有する者が本発明を容易に実施できるように本発明の好適な実施形態を添付の図面を参照して詳細に説明する。
【００５１】
図５は、本発明に係るＭＡＯのための改善されたＰｏＣ通話設定過程を示す図である。図５は、事前セッションが存在するクライアントに対するＭＡＯ通話要請処理手続を示す図であり、本発明で提案するＰｏＣ通話呼処理手続を示す。まず、ＰｏＣ管理サーバーは、ＰｏＣ通話要請者のネットワークからＭＡＯ指示を含むＩＮＶＩＴＥメッセージを受信した後（ステップ１００１）、管理ネットワークのＳＩＰ／ＩＰ核心網と受信側ホームネットワークのＳＩＰ／ＩＰ核心網を経由して（ステップ１００２）、受信ＰｏＣユーザのホームネットワークに属するＰｏＣサーバー（participating PoC Server）にＩＮＶＩＴＥメッセージを伝達する（ステップ１００３）。
【００５２】
この時、ＰｏＣ参加サーバーは、ＩＮＶＩＴＥメッセージに含まれているＰｏＣ通話受信者に関するＰｏＣアドレス情報、ＰｏＣ通話要請者のＰｏＣアドレス情報及びＭＡＯ指示子の情報をプロセシングし、呼処理に利用する。
【００５３】
一方、ＰｏＣ参加サーバーは、アドレス情報を用いて該当ＰｏＣユーザと事前セッションが存在することが分かり、ＭＡＯ指示子を認識してＰｏＣユーザの応答に関係なく、前記ＩＮＶＩＴＥ要請メッセージに対してＯＫ応答を送る（ステップ１００４〜１００６）。
【００５４】
この時、ＯＫ応答は、ＩＭＳ網のルーティング規則によってＩＮＶＩＴＥ要請メッセージの経路に回答するようになる。
【００５５】
前記ステップ１００４〜１００６の自動応答手続の設定は、ＰｏＣ参加サーバーが受信ＰｏＣユーザへ予め交渉する所定のセッションメディアパラメータをＰｏＣ参加サーバーが使用するので、可能である。また、ＭＡＯ指示子の情報を用いてＰｏＣ通話要請者が該当ＰｏＣ受信者に対して許可されたユーザであり、受信側ＰｏＣクライアントが自動でＰｏＣ通話要請を受諾することをあらかじめ予測することができる。
【００５６】
このような予測された手続は、現在ＯＭＡ規格で記述する要求事項とユーザーケースとに機能的に互換可能なので、互換性の問題が全くない。
【００５７】
前述したＯＫ応答信号は、管理ネットワークのＰｏＣサーバー（ＰｏＣ管理サーバー）に回答された後、ＰｏＣ通話要請者のホームネットワークに伝達される（ステップ１００７）。この時、ＯＫ応答信号は、ＰｏＣ通話送信側の立場では、受信ＰｏＣユーザが直接通話を許諾したことと同様に認識され、通話要請者のＰｏＣクライアントまでＯＫ応答が回答されることによって、１つのダイアローグ（dialog）が成立し、ＳＩＰ通話手続が完了するようになる。
【００５８】
一方、上記図２で説明したように、ＯＫ応答と発言権付与（Floor granted）信号が該当ＰｏＣ管理サーバーからＰｏＣ送信クライアントに全て伝達された後（ステップ１００７〜１００８）、送信側ＰｏＣクライアントは、自身のＰｏＣアドレスとディスプレイ名称とＭＡＯ指示子とを含む‘トークバースト’転送信号を設定されたＲＴＣＰ経路に送る（ステップ１００９）。最後に、管理ネットワークのＰｏＣサーバーは、受信側ＰｏＣサーバーを介してＭＡＯ指示子が含まれた‘トークバースト’転送信号を受信側ＰｏＣクライアントに伝達し（ステップ１０１０〜１０１１）、この時、受信側ＰｏＣユーザは、自身に手動応答無視が許可されたユーザがＰｏＣ通話を要請したことを認識するようになり（この時、通話要請者の名前、ＰｏＣアドレスなども表示されることができる）、直ちに転送されるメディア（音声信号）を受信するようになる。
【００５９】
図６は、本発明に係るＭＡＯ指示子を含むＲＴＣＰペイロードフォーマットを示す図である。図６を参照すれば、前記送信側ＰｏＣクライアントが送るＲＴＣＰパケットの構成は、ＲＴＣＰペイロード形態で具現されることができる。ＲＴＣＰパケットの構成は、バージョン情報、サブタイプ情報、長さなど一般的な転送関連情報とＰｏＣユーザのアドレス、名前情報以外に、ＭＡＯ指示子（Manual Answer Override indication）情報を含む。
【００６０】
本発明の他の実施形態として、ＭＡＯ指示子を含む段階は、前述したように、ユーザの端末に属する送信側ＰｏＣクライアントが行うこともできるが、管理ネットワークのＰｏＣサーバーや受信側ホームネットワークのＰｏＣサーバーが行うこともできることを注目すべきである。
【００６１】
一方、事前セッションの用途によってＰｏＣサーバーとクライアントとの間の経路及び追加的リソース予約（resource reservation）を含むこともできるが、本発明の核心要旨から外れるので、詳述しない。本発明で要求する事前セッションに対する要求事項は、前記事前セッションの定義に影響を受けずに、事前セッションの拡張された定義によってさらに容易な実現が可能であることができる。
【００６２】
以上において説明した本発明は、本発明が属する技術の分野における通常の知識を有する者であれば、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能であるので、上述した実施形態及び添付された図面に限定されるものではない。
【図面の簡単な説明】
【００６３】
【図１】一般的なＰｏＣサービスシステムを示すブロック図である。
【図２】従来技術に係るＭＡＯのための送信側ＰｏＣ通話設定過程を示す流れ図である。
【図３】従来技術に係るＭＡＯのための受信側ＰｏＣ通話設定過程を示す流れ図である。
【図４】ＰｏＣ呼び要請のためのＩＮＶＩＴＥに含まれる情報を示す図である。
【図５】本発明に係るＭＡＯのための改善されたＰｏＣ通話設定過程を示す図である。
【図６】本発明に係るＭＡＯ指示子を含むＲＴＣＰペイロードフォーマットを示す図である。
【符号の説明】
【００６４】
１０  ＰｏＣクライアント
２０  アクセス網
３０  ＳＩＰ／ＩＰコア
４０  ＧＬＭＳ管理部
５０  ＧＬＭＳ
６０  ＰｏＣサーバー
７０  プレゼンスサーバー
８０  遠隔ＰｏＣ網
【図１】
2008514155.tif 000005
【図２】
2008514155.tif 000006
【図３】
2008514155.tif 000007
【図４】
2008514155.tif 000008
【図５】
2008514155.tif 000009
【図６】
2008514155.tif 000010
【国際調査報告】
2008514155.tif 000011
2008514155.tif 000012