(57)【特許請求の範囲】
【請求項１】
第１端末が信号を送信する方法であって、
前記第１端末が端末−ネットワークリレー（UE-to-network relay）に対する設定情報を設定するために第１ネットワーク装置にサービス認可リクエスト（Service authorization request）メッセージを送信する段階と、前記第１ネットワーク装置は近接サービス（Proximity-based service、ＰｒｏＳｅ）機能を含み、及び
前記第１端末が前記第１ネットワーク装置からサービス認可応答（service authorization response）メッセージを受信する段階と、を含み、
前記第１端末は端末−ネットワークリレー（UE-to-network relay）機能を行うことができる端末であり、
前記サービス認可応答メッセージはリレーサービスコード、前記リレーサービスコードに係るアクセスポイントネーム（ＡＰＮ）及びサービス認可に係る有効期間情報を含み、
前記第１端末が前記サービス認可応答メッセージに含まれる前記アクセスポイントネームに基づいて前記端末−ネットワークリレーに係るパケットデータネットワーク（Packet Data Network、ＰＤＮ）接続（connection）リクエストメッセージを送信する段階をさらに含み、
前記リレーサービスコードは、前記端末−ネットワークリレーによって提供されるサービスを識別するために使用される
ことを特徴とする、信号送信方法。
【請求項２】
前記サービス認可応答メッセージに含まれた情報は前記第１ネットワーク装置が持っている端末−ネットワークリレーサービスを行うことができる端末であるか確認するための情報に基づいて決定される
ことを特徴とする、請求項１に記載の信号送信方法。
【請求項３】
前記第１端末が、前記サービス認可応答メッセージに含まれた情報に基づいて前記端末−ネットワークリレーを行うための探索を行う段階をさらに含む
ことを特徴とする、請求項１に記載の信号送信方法。
【請求項４】
第１ネットワーク装置が信号を送信する方法であって、
前記第１ネットワーク装置が端末−ネットワークリレー（UE-to-network relay）に対する設定情報を設定するための第１端末からサービス認可リクエスト（Service authorization request）メッセージを受信する段階と、前記第１端末は端末−ネットワークリレー（UE-to-network relay）機能を行うことができ、及び
前記第１ネットワーク装置が前記第１端末にサービス認可応答（service authorization response）メッセージを送信する段階を含み、
前記第１ネットワーク装置はＰｒｏＳｅファンクション（function）を含み、
前記サービス認可応答メッセージはリレーサービスコード、前記リレーサービスコードに係るアクセスポイントネーム（ＡＰＮ）及びサービス認可に係る有効期間情報を含み、
前記サービス認可応答メッセージに含まれる前記アクセスポイントネームに基づいて前記端末−ネットワークリレーに係るパケットデータネットワーク（Packet Data Network、ＰＤＮ）接続（connection）リクエストメッセージが送信され、
前記リレーサービスコードは、前記端末−ネットワークリレーによって提供されるサービスを識別するために使用される
ことを特徴とする、信号送信方法。
【請求項５】
前記サービス認可リクエストメッセージを受信した後、前記第１端末が端末−ネットワークリレーサービスを行うことができる端末であるか否かを、前記第１ネットワーク装置が確認する段階をさらに含む
ことを特徴とする、請求項４に記載の信号送信方法。
【請求項６】
前記第１端末が前記端末−ネットワークリレーサービスを行うことができる端末であるか決定するための情報を記憶していない場合、ＨＳＳ（Home Subscriber Server）から前記情報を前記第１ネットワーク装置が獲得する段階をさらに含む
ことを特徴とする、請求項５に記載の信号送信方法。
【請求項７】
前記サービス認可応答メッセージに含まれた情報に基づいて端末−ネットワークリレーを行うための探索が行われる
ことを特徴とする、請求項４に記載の信号送信方法。
【請求項８】
信号を送信する第１端末であって、
送受信部と、及び
第１ネットワーク装置に端末−ネットワークリレー（UE-to-network relay）に対する設定情報を設定するためにサービス認可リクエスト（Service authorization request）メッセージを送信し、前記第１ネットワーク装置は近接サービス（Proximity-based service、ＰｒｏＳｅ）機能を含み、前記第１ネットワーク装置からサービス認可応答（service authorization response）メッセージを受信し、
前記第１端末は端末−ネットワークリレー（UE-to-network relay）機能を行うことができる端末であり、前記サービス認可応答メッセージはリレーサービスコード、前記リレーサービスコードに係るアクセスポイントネーム（ＡＰＮ）及びサービス認可に係る有効期間情報を含み、
前記サービス認可応答メッセージに含まれる前記アクセスポイントネームに基づいて前記端末−ネットワークリレーに係るパケットデータネットワーク（Packet Data Network、ＰＤＮ）接続（connection）リクエストメッセージを送信するように制御する制御部と、を含み、
前記リレーサービスコードは、前記端末−ネットワークリレーによって提供されるサービスを識別するために使用される
ことを特徴とする第１端末。
【請求項９】
前記サービス認可応答メッセージに含まれた情報は前記第１ネットワーク装置が持っている端末−ネットワークリレーサービスを行うことができる端末であるか確認するための情報に基づいて決定される
ことを特徴とする、請求項８に記載の第１端末。
【請求項１０】
前記制御部は前記サービス認可応答メッセージに含まれた情報に基づいて前記端末−ネットワークリレーを行うための探索を行うようにさらに制御する
ことを特徴とする、請求項８に記載の第１端末。
【請求項１１】
信号を送信する第１ネットワーク装置であって、
信号を送受信する送受信部と、及び
第１端末から端末−ネットワークリレー（UE-to-network relay）に対する設定情報を設定するためのサービス認可リクエスト（Service authorization request）メッセージを受信し、前記第１端末は端末−ネットワークリレー（UE-to-network relay）機能を行うことができ、前記第１端末がサービス認可応答（service authorization response）メッセージを送信するように制御する制御部と、を含み、
前記第１ネットワーク装置はＰｒｏＳｅファンクション（function）を含み、
前記サービス認可応答メッセージはリレーサービスコード、前記リレーサービスコードに係るアクセスポイントネーム（ＡＰＮ）及びサービス認可に係る有効期間情報を含み、
前記サービス認可応答メッセージに含まれる前記アクセスポイントネームに基づいて前記端末−ネットワークリレーに係るパケットデータネットワーク（Packet Data Network、ＰＤＮ）接続（connection）リクエストメッセージが送信され、
前記リレーサービスコードは、前記端末−ネットワークリレーによって提供されるサービスを識別するために使用される
ことを特徴とする、第１ネットワーク装置。
【請求項１２】
前記制御部は前記サービス認可リクエストメッセージを受信した後、前記第１端末が端末−ネットワークリレーサービスを行うことができる端末であるか確認するようにさらに制御する
ことを特徴とする、請求項１１に記載の第１ネットワーク装置。
【請求項１３】
前記制御部は前記第１端末が前記端末−ネットワークリレーサービスを行うことができる端末であるか確認するための情報を記憶していない場合、ＨＳＳ（Home Subscriber Server）から前記情報を獲得するようにさらに制御する
ことを特徴とする、請求項１２に記載の第１ネットワーク装置。
【請求項１４】
前記サービス認可応答メッセージに含まれた情報に基づいて端末−ネットワークリレー接続を行うための探索が行われる
ことを特徴とする、請求項１１に記載の第１ネットワーク装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムにおいて端末のパケットデータネットワーク(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ、ＰＤＮ)接続(ｃｏｎｎｅｃｔｉｏｎ)を生成する方法及び装置に関し、より詳しくはリレー端末(Ｒｅｌａｙ ＵＥ)のＰＤＮ接続を生成する方法及び装置に関する。
【背景技術】
【０００２】
４Ｇ通信システムの商用化以後に増加趨勢にある無線データトラフィック需要を満たすため、改善した５Ｇ通信システム又はｐｒｅ−５Ｇ通信システムを開発するための努力が成っている。このような理由で、５Ｇ通信システム又はｐｒｅ−５Ｇ通信システムは、４Ｇネットワーク以後(Ｂｅｙｏｎｄ ４Ｇ Ｎｅｔｗｏｒｋ)通信システム又はＬＴＥシステム以後(Ｐｏｓｔ ＬＴＥ)のシステムと呼ばれられている。高いデータ送信率を達成するため、５Ｇ通信システムは超高周波(ｍｍＷａｖｅ)帯域(例えば、６０ギガ６０ＧＨｚ)帯域のような)での具現が考慮されている。超高周波帯域での電波の経路損失緩和及び電波の伝達距離を増加させるため、５Ｇ通信システムではビームフォーミング(ｂｅａｍｆｏｒｍｉｎｇ)、巨大な多重入出力(ｍａｓｓｉｖｅＭＩＭＯ)、全次元多重入出力(Ｆｕｌｌ Ｄｉｍｅｎｓｉｏｎａｌ ＭＩＭＯ：ＦＤ−ＭＩＭＯ)、アレイアンテナ(ａｒｒａｙ ａｎｔｅｎｎａ)、アナログビームフォーミング(ａｎａｌｏｇ ｂｅａｍ−ｆｏｒｍｉｎｇ)、及び大規模アンテナ(ｌａｒｇｅ ｓｃａｌｅ ａｎｔｅｎｎａ)技術が論議されている。また、システムのネットワーク改善のために、５Ｇ通信システムでは進化した小型セル、改善した小型セル(ａｄｖａｎｃｅｄ ｓｍａｌｌ ｃｅｌｌ)、クラウド無線アクセスネットワーク(ｃｌｏｕｄ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ：ｃｌｏｕｄ ＲＡＮ)、超高密度ネットワーク(ｕｌｔｒａ−ｄｅｎｓｅ ｎｅｔｗｏｒｋ)、機器間の通信(Ｄｅｖｉｃｅｔｏ Ｄｅｖｉｃｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ：Ｄ２Ｄ)、無線バックホール(ｗｉｒｅｌｅｓｓ ｂａｃｋｈａｕｌ)、移動ネットワーク(ｍｏｖｉｎｇ ｎｅｔｗｏｒｋ)、協力通信(ｃｏｏｐｅｒａｔｉｖｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ)、ＣｏＭＰ(Ｃｏｏｒｄｉｎａｔｅｄ Ｍｕｌｔｉ−Ｐｏｉｎｔｓ)、及び受信干渉除去(ｉｎｔｅｒｆｅｒｅｎｃｅ ｃａｎｃｅｌｌａｔｉｏｎ)などの技術開発が成っている。この外にも、５Ｇシステムでは進歩したコーディング変調(Ａｄｖａｎｃｅｄ Ｃｏｄｉｎｇ Ｍｏｄｕｌａｔｉｏｎ：ＡＣＭ)方式であるＦＱＡＭ(Ｈｙｂｒｉｄ ＦＳＫ ａｎｄ ＱＡＭ Ｍｏｄｕｌａｔｉｏｎ)及びＳＷＳＣ(Ｓｌｉｄｉｎｇ Ｗｉｎｄｏｗ Ｓｕｐｅｒｐｏｓｉｔｉｏｎ Ｃｏｄｉｎｇ)と、進歩した接続技術であるＦＢＭＣ(Ｆｉｌｔｅｒ Ｂａｎｋ Ｍｕｌｔｉ Ｃａｒｒｉｅｒ)、ＮＯＭＡ(ｎｏｎｏｒｔｈｏｇｏｎａｌ ｍｕｌｔｉｐｌｅａｃｃｅｓｓ)、及びＳＣＭＡ(ｓｐａｒｓｅ ｃｏｄｅ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ)などが開発されている。
【０００３】
一方、インターネットは人間が情報を生成して消費する人間中心の接続網から事物など分散した構成要素間に情報を取り交わして処理するＩｏＴ(Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ、事物インターネット)網に進化しつつある。クラウドサーバなどとの接続を通じるビックデータ(Ｂｉｇ ｄａｔａ)処理技術などがＩｏＴ技術に結合されたＩｏＥ(Ｉｎｔｅｒｎｅｔ ｏｆ Ｅｖｅｒｙｔｈｉｎｇ)技術も台頭されている。ＩｏＴを具現するためにセンシング技術、有無線通信及びネットワークインフラ、サービスインターフェース技術、及び保安技術のような技術要素が要求され、近年、事物間の接続のためのセンサーネットワーク(ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ)、マシンツーマシン(Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ、Ｍ２Ｍ)、ＭＴＣ(Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)などの技術が研究されている。ＩｏＴ環境では接続された事物で生成されたデータを収集、分析して人間の生活に新しい価値を創出する知能型ＩＴ(Ｉｎｔｅｒｎｅｔ Ｔｅｃｈｎｏｌｏｇｙ)サービスが提供されることができる。ＩｏＴは既存のＩＴ(ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ)技術と多様な産業間の融合及び複合を介してスマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、スマートグリッド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用されることができる。
【０００４】
これに、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みが成っている。例えば、センサーネットワーク(ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ)、マシンツーマシン(Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ、Ｍ２Ｍ)、ＭＴＣ(Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)などの５Ｇ通信技術がビームフォーミング、ＭＩＭＯ、及びアレイアンテナなどの技法により具現されていることである。前述したビックデータ処理技術としてクラウド無線アクセスネットワーク(ｃｌｏｕｄ ＲＡＮ)が適用されることも５Ｇ技術とＩｏＴ技術融合の一例と言えるだろう。
【０００５】
前記情報は背景情報だけで提示され、本発明の理解を助けるために提供される。上記事項の中のいずれも本開示に係って先行技術として適用されることができるか否かについてはどんな決定も下さず、どんな主張も申し立てられなかった。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本開示の態様は、少なくとも上述した問題及び／または欠点に解消し、少なくとも後述する利点を提供することである。したがって、本開示の一態様は、リレー端末がリモート(Ｒｅｍｏｔｅ)端末のためのＰＤＮ接続を生成しようとするとき、リレー端末のパケットデータネットワー(ＰＤＮ)接続を生成し、リレー関連情報を取得する方法および装置を提供することである。
【課題を解決するための手段】
【０００７】
本発明の一態様によれば、第１端末が信号を送信する方法であって、第１ネットワーク装置でサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを送信する段階と、及び前記第１ネットワーク装置からサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを受信する段階と、を含み、前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)機能を行うことができるリレー端末であり、前記第１ネットワーク装置は近接サービス(ＰｒｏＳｅ)関連機能を行う近接サービス(Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ  Ｓｅｒｖｉｃｅ；ＰｒｏＳｅ)ファンクション(ｆｕｎｃｔｉｏｎ)であり、前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ)及びサービス認可に係る有効期間情報を含むことを特徴とする。
【０００８】
本発明の他の態様によれば、第１ネットワーク装置が信号を送信する方法であって、第１端末からサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを受信する段階と、及び前記第１端末でサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを送信する段階と、を含み、前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)機能を行うことができるリレー端末であり、前記第１ネットワーク装置は近接サービス(ＰｒｏＳｅ)関連機能を行うＰｒｏＳｅファンクション(ｆｕｎｃｔｉｏｎ)であり、前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(ＡＰＮ)及びサービス認可に係る有効期間情報を含むことを特徴とする。
【０００９】
本発明の他の態様によれば、信号を送信する第１端末であって、信号を送受信する送受信部と、及び第１ネットワーク装置でサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを送信し、前記第１ネットワーク装置からサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを受信するように制御する制御部と、を含み、前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)機能を行うことができるリレー端末であり、前記第１ネットワーク装置は近接サービス(ＰｒｏＳｅ)関連機能を行うＰｒｏＳｅファンクション(ｆｕｎｃｔｉｏｎ)であり、前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(ＡＰＮ)及びサービス認可に係る有効期間情報を含むことを特徴とする。
【００１０】
本発明の他の態様によれば、信号を送信する第１ネットワーク装置であって、信号を送受信する送受信部と、及び第１端末からサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを受信し、前記第１端末でサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを送信するように制御する制御部と、を含み、前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)機能を行うことができるリレー端末であり、前記第１ネットワーク装置は近接サービス(ＰｒｏＳｅ)関連機能を行うＰｒｏＳｅファンクション(ｆｕｎｃｔｉｏｎ)であり、前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(ＡＰＮ) 及びサービス認可に係る有効期間情報を含むことを特徴とする。
【００１１】
本開示の様々な態様を開示する以下の詳しい説明から本開示の態様、利点、及び顕著な特徴は当業者には明らかになるだろう。
【発明の効果】
【００１２】
本発明の実施形態によれば、リレー端末はＰＤＮ接続を生成して端末−ネットワークリレーを効果的に行うことができる。
【図面の簡単な説明】
【００１３】
【図１】ＰｒｏＳｅ端末がリレー役目を行うためにＡｔｔａｃｈ手続きを行う方法を示した図面である。
【図２】ＰｒｏＳｅ端末がリレー役目を行うためにＰＤＮ接続確立手続きを行う方法を示した図面である。
【図３】ＰｒｏＳｅ端末がリレー役目を行うためにＳｅｒｖｉｃｅｒｅｑｕｅｓｔ手続きを行う方法を示した図面である。
【図４】ＰｒｏＳｅ端末がリレー役目を行うためにＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ手続きを行う方法を示した図面である。
【図５】本実施形態を行うことができる装置の内部構造を示したブロック図である。
【図６】端末間の近接サービス(Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ ｓｅｒｖｉｃｅ)を介してＰｒｏＳｅ端末−ネットワークリレーを用いてサービスを受けるためのＰｒｏＳｅネットワーク構造を示した図面である。
【図７】リレーサービスコード値を受信する手続きを示した図面である。
【図８】リレーＵＥがレイヤー２グループＩＤを受信する方法を示した図面である。
【図９】リレーＵＥがレイヤー２グループＩＤを受信する他の方法を示した図面である。
【図１０】本実施形態を行うことができる装置の内部構造を示したブロック図である。
【図１１】グループ呼出しを開設する端末がグループ呼出しに用いるメディア送信関連項目を任意に選択し、これを他のメンバー端末に公知する方法を示した図面である。
【図１２】端末間の直接通信に基づくＭＣＰＴＴシステムを示した図面である。
【図１３ａ】ＭＣＰＴＴ端末の構造を示したブロック図である。
【図１３ｂ】ＭＣＰＴＴ端末の他の構造を示したブロック図である。
【図１４】新しいＭＣＰＴＴクライアントが周期的に送信されるグループ呼出し公知メッセージを受信してグループ呼出しに参加する方法を示した図面である。
【図１５】新しいＭＣＰＴＴクライアントが能動的にグループ呼出し公知メッセージを送信することによって予め生成されたグループ呼出しに参加する方法を示した図面である。
【図１６】能動的なＭＣＰＴＴクライアントと受動的なＭＣＰＴＴクライアントが共存する場合、２つのＭＣＰＴＴクライアントを全てのグループ呼出しに参加させる方法を示した図面である。
【図１７】ＳＡＰのＰａｃｋｅｔ Ｆｏｒｍａｔ(パケットフォーマット)を示した図面である。
【図１８】本実施形態による優先順位基盤サービス処理動作を示した図面である。
【図１９】本発明の一実施形態による優先順位基盤サービス処理のための端末の動作を示した図面である。
【図２０】本発明の一実施形態による優先順位基盤のサービス処理のためのサーバーの動作を示した図面である。
【図２１】本発明の一実施形態による優先順位値を基づいたフロア・コントロール(ｆｌｏｏｒｃｏｎｔｒｏｌ)過程を示した図面である。
【図２２】本実施形態による優先順位及び端末の位置情報に基づいてネットワークでＱｏＳを提供する過程を示した図面である。
【図２３】本実施形態によるＳＩＰ ＭＥＳＳＡＧＥメソッドを用いてＡｌｅｒｔメッセージを送信する過程を示した図面である。
【図２４】本実施形態で端末がＳＩＰではない他のプロトコルを用いてＡｌｅｒｔメッセージを送信する過程を示す図面である。
【図２５】本実施形態によるＳＩＰ ＳＵＢＳＣＲＩＢＥ及びＮＯＴＩＦＹメソッドを用いてＡｌｅｒｔメッセージを送信する過程を示す図面である。
【図２６】本実施形態によるＡｌｅｒｔメッセージに端末の位置情報を含んで送信する過程を示した図面である。
【図２７】本実施形態によるグループ呼出しを設定する過程を示す図面である。
【図２８】本実施形態による一般グループ呼出しを緊急グループ呼出しに変更する過程を示す図面である。
【図２９】本実施形態による端末が他のサービス中の緊急グループ呼出しリクエストを処理する過程を示す図面である。
【図３０】本実施形態による緊急グループ呼出しリクエストメッセージにＡｌｅｒｔメッセージを含んで送信する過程を示す図面である。
【図３１】本実施形態による一般グループ呼出し中のＡｌｅｒｔメッセージを受信して緊急グループ呼出しで転換する過程を示す図面である。
【図３２】本実施形態による端末を示す図面である。
【図３３】本実施形態によるＭＣＰＴＴサーバーの構造を示すブロック図である。
【発明を実施するための形態】
【００１４】
添付された図面を参照する次の説明は、請求範囲及びこの等価物により定義されるような本開示の多様な実施形態の包括的な理解を助けるために提供される。本発明の実施形態は本発明の理解を助けるために多様な特定詳細事項を含むが、これらはただ例示的なことで見なされなければならない。したがって、本技術分野の通常の技術を有する者であれば本明細書に記載された多様な実施形態の多様な変更及び修正が本発明の範囲及び思想から逸脱せず成ることができるということを認識するだろう。さらに、公知された機能及び構成に対する説明は明確性及び簡潔性のために省略されることができる。
【００１５】
次の詳細な説明及び請求範囲で用いられた用語及び単語は、書誌意味に限定されず、ただ本発明の明確で一貫性ある理解のために用いられる。したがって、本発明の多様な実施形態に対する次の説明は、ただ例示を目的と提供され、添付された請求範囲及びこの等価物により定義される本発明を制限するための目的ではないということが当業者に明白であろう。
【００１６】
単数形態“ａ”、“ａｎ”及び“ｔｈｅ”は文脈がはっきり異なり指示しなければ複数の対象を含むことに理解されなければならない。したがって、例えば、“構成要素表面”に対する言及はこのようなの１つ以上に表面に対する言及を含む。
【００１７】
本明細書では、“ＵＥ(ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ)”という用語は、“端末”、“ＵＥ装置”などと交換可能である。用語“進化したノードＢ（ｅＮＢ）”は“基地局”などと交換可能である。
【００１８】
<第１実施形態>
【００１９】
現在までの無線通信システムの発展は、主にユーザと基地局もしくはネットワーク装備との接続及び通信に基づいてサービスを提供して来た。近年、無線通信システムを用いて端末間の直接通信をするための機器間の通信(Ｄｅｖｉｃｅ−ｔｏ−ｄｅｖｉｃｅ、Ｄ２Ｄ)技術に対する関心が増加しつつあり、これを近接サービス(Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ ｓｅｒｖｉｃｅｓ、ＰｒｏＳｅ)と称することができる。
【００２０】
ＰｒｏＳｅユーザは、端末(ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ(ユーザ装備)、ＵＥ、ｔｅｒｍｉｎａｌなどと混用可能)間の信号を交換しながらサービスを用いることができる。例えば、関心あるユーザをサーチするために探索(Ｄｉｓｃｏｖｅｒｙ)動作を行うか、関心あるユーザと通信(Ｃｏｍｍｕｎｉｃａｔｉｏｎ)するための動作を行うことができる。ＰｒｏＳｅは商業的用途として用いられ、または公衆安全サービス(Ｐｕｂｌｉｃ Ｓａｆｅｔｙ)のために用いられる。
【００２１】
ＰｒｏＳｅユーザは、周波数リソースを使用するから、ＰｒｏＳｅサービスは基地局及びネットワーク装備の助けを受けて提供されることができる。より具体的に、基地局及びネットワークはユーザが使用する無線リソースを割り当てることができ、ユーザは割り当てられた無線リソースを介してデータを送受信することができる。
【００２２】
ＰｒｏＳｅ端末は、ＰｒｏＳｅに対する制御を担当するＰｒｏＳｅファンクション(Ｆｕｎｃｔｉｏｎ)というネットワーク装置(Ｎｅｔｗｏｒｋ Ｅｎｔｉｔｙ)とＬＴＥ網を介して接続される。ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎは、ＰｒｏＳｅ端末が用いるサービス(直接探索(ＤｉｒｅｃｔＤｉｓｃｏｖｅｒｙ)、直接通信(Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)、端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)など)を提供するための交渉及びパラメーターを管理、提供する役目を行う。ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎには基地局(進化したノードＢ、ｅｖｏｌｖｅｄ ＮｏｄｅＢ、ｅＮＢと混用可能)及びコア核心網(Ｃｏｒｅ Ｎｅｔｗｏｒｋ、コアネットワークと混用されることができる)と接続されたインターフェースがなくＰｒｏＳｅ端末のユーザに対するプロフィール(Ｐｒｏｆｉｌｅ)は、ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ)と交渉して獲得したり自体的に記憶することができる。ＰｒｏＳｅ ＦｕｎｃｔｉｏｎはＰｒｏＳｅ端末がＬＴＥネットワークで用いることができるパラメーターを提供することができ、例えば、無線リソース(Ｒａｄｉｏ ｒｅｓｏｕｒｃｅ)情報、特定ＰＬＭＮ(Ｐｕｂｌｉｃｌ ａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ)に対してＰｒｏＳｅサービスを用いることができるか(Ａｕｔｈｏｒｉｚａｔｉｏｎ)に対する情報、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎと接続するためのアクセスポイントネーム(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ)などがある。
【００２３】
ＰｒｏＳｅにおいてＰｒｏＳｅ制御部を意味するＰｒｏＳｅ Ｆｕｎｃｔｉｏｎは、ＰｒｏＳｅ可能(ＰｒｏＳｅ−ｅｎａｂｌｅ)端末との交渉を介してＰｒｏＳｅ−ｅｎａｂｌｅ端末がＰｒｏＳｅのために用いることができる情報を提供する。ＰｒｏＳｅ端末は、ネットワークカバレッジ内部に位置する場合、ネットワーク接続を介してＰｒｏＳｅ Ｆｕｎｃｔｉｏｎと交渉したり基地局により提供される無線リソースを介してＰｒｏＳｅ端末どうし直接探索もしくは直接通信を行うことができる。
【００２４】
また、ネットワークカバレッジ内部に位置する端末は近くの端末がネットワークカバレッジ外部に位置する場合、端末−ネットワークリレー機能を行ってネットワークカバレッジ外部に位置する端末(リモート(Ｒｅｍｏｔｅ)ＵＥ)にネットワーク接続を提供することができる。
【００２５】
ＰｒｏＳｅでは公衆安全サービスのために基地局のカバレッジ外部に位置する端末(以下、リモートＵＥ)とリレー(Ｒｅｌａｙ)を介してネットワークに接続することができる機能を提供する。基地局はカバレッジの外に移動することで期待する端末を潜在的リモートＵＥと見なすことができ、端末が基地局に提供する測定(ｍｅａｓｕｒｅｍｅｎｔ)情報でこれを判断することができる。リモートＵＥは探索動作を介してリレー機能を提供する端末(以下、リレーＵＥ)を探索するようになり、リレーＵＥと直接通信接続を確立する。
【００２６】
リレーＵＥは、ＩＰアドレスが割り当てられるデリゲート(Ｄｅｌｅｇａｔｅ)役目を行ってリモートＵＥにＩＰアドレスを割り当てる。リモートＵＥとリレーＵＥとの接続は一対一直接通信(ｏｎｅ−ｔｏ−ｏｎｅ ｄｉｒｅｃｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ)方法を用いることができる。リモートＵＥは、前記接続を介してリレーＵＥを経てネットワークに接続することができる。リモートＵＥはパケットをリレーＵＥに伝達し、リレーＵＥはリレーパケットを伝達するためのパケットネットワーク接続を介して当該データをネットワークへ送信する。また、リレーＵＥはネットワークからリモートＵＥに伝達されるパケットをリレー接続を確立した直接通信を介して伝達することができる。
【００２７】
本実施形態の全般にかけてＰｒｏＳｅは端末対端末の探索及び通信サービスのうちのいずれか一つを示す。本実施形態は３ＧＰＰで定義した長期間進化(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ、ＬＴＥ)システムに基づいて説明しているが、無線近距離通信網(ｗｉｒｅｌｅｓｓ ＬＡＮ(ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ)、ＷＬＡＮ)、ブルートゥース（登録商標）(Ｂｌｕｅｔｏｏｔｈ（登録商標）)など無線通信全般で類似に用いられることができる。本実施形態において公衆安全サービスのためのＰｒｏＳｅ機能中の一つである端末−網リレー機能をサポートするためにコアネットワークと基地局間のリレー関連情報を交換する方法及び装置、そして基地局でリレー機能をサポートするために端末を制御する方法及び装置を提案する。
【００２８】
本発明の用語は本発明における機能を考慮して定義された用語とし、これはユーザ、運用者の意図または慣例などによって変わることができる。また、本実施形態を具体的に説明するにおいて、３ＧＰＰが規格を定めた無線接続網、コアネットワークであるＬＴＥと進化したパケットコア(Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ、ＥＰＣ)を主な対象とするが、本実施形態の主な要旨は類似の技術的背景を有するそのほかの通信システムにも本実施形態の範囲を大きく逸脱せず範囲で僅かの変形で適用可能であり、これは本実施形態の技術分野で熟練された技術的知識を有する者の判断で可能であろう。本実施形態に係るＤ２Ｄサービスは機器間の通信をサポートするサービスを総称し、３ＧＰＰ標準技術のＰｒｏＳｅなどがその例示である。本発明において前述したＤ２ＤシステムはＰｒｏＳｅと称する。
【００２９】
図１は、ＰｒｏＳｅ端末がリレー役目を行うためにＡｔｔａｃｈ手続きを行う方法を示した図面である。
【００３０】
図１によれば、ＰｒｏＳｅ端末はリレー役目を行うために網にリレーであることを通知しながらＡｔｔａｃｈ手続きを行い、その手続きを介してコアネットワークは基地局に当該端末のリレー実行に対する情報を提供することができる。また、基地局が前記情報に基づいてリレー端末を選択し、カバレッジの外に移動することで予想される端末にリレーを探索するようにトリガーすることができる。
【００３１】
ＰｒｏＳｅ利用端末であるＵＥ２(１１０)は、ネットワークに接続するためにネットワーク装置中の移動性管理装置であるＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)１３０でＡｔｔａｃｈ Ｒｅｑｕｅｓｔを送信する(ｓ１００)。前記端末は、Ａｔｔａｃｈ Ｒｅｑｕｅｓｔメッセージを用いて自分がリレー動作を行う端末もしくはリレー動作が可能な端末であることを次のような方法で通知することができる。第１に、Ａｔｔａｃｈ ＲｅｑｕｅｓｔメッセージのＴｙｐｅ情報領域に自分がリレー動作を行うことができるというインジケータ(ｉｎｄｉｃａｔｉｏｎ)を含むことができる。第２にＡｔｔａｃｈ ＲｅｑｕｅｓｔメッセージのＡＰＮ情報領域にリレー用ＰＤＮ(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ)接続のためのＡＰＮを設定することができる。前記リレー用ＰＤＮＣｏｎｎｅｃｔｉｏｎのためのＡＰＮはＰｒｏＳｅ端末がＰｒｏＳｅ動作のためにＰｒｏＳｅ Ｆｕｎｃｔｉｏｎとサービス認可(Ｓｅｒｖｉｃｅ Ａｕｔｈｏｒｉｚａｔｉｏｎ)手続きを行う時、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎから提供されることができる。または、ＰｒｏＳｅ端末のＵＩＣＣ(Ｕｎｉｖｅｒｓａｌ ＩＣ Ｃａｒｄ)に予め設定された値を用いることができる。第３にＡｔｔａｃｈ ＲｅｑｕｅｓｔメッセージのＵＥ ｎｅｔｗｏｒｋ Ｃａｐａｂｉｌｉｔｙ情報領域にリレー能力(Ｒｅｌａｙ Ｃａｐａｂｉｌｉｔｙ)を示すインジケータを設定することができる。第４にＡｔｔａｃｈ ＲｅｑｕｅｓｔメッセージのＤｅｖｉｃｅ Ｐｒｏｐｅｒｔｙ情報領域にＰｒｏＳｅリレー端末であることを示すインジケータを設定することができる。ＵＥ２は前記４つ方法のうちの少なくとも一つ以上を用いて自分がＰｒｏＳｅリレー端末であることを通知することができる。
【００３２】
前記の４つの方法のうちの少なくとも一つ以上を用いて構成されたＡｔｔａｃｈ Ｒｅｑｕｅｓｔメッセージを受信したＭＭＥ１３０は、前記の４つの方法に対する情報領域に基づいてＡｔｔａｃｈ Ｒｅｑｕｅｓｔを送信した端末がＰｒｏＳｅ端末−ネットワークリレーを行う端末であることを認知することができる。ＭＭＥはＡｔｔａｃｈ Ｒｅｑｕｅｓｔメッセージを参照してリレー用ＰＤＮ接続のためのＡＰＮ値がＡＰＮ情報領域に設定された場合、当該端末がリレー用ベアラー(Ｂｅａｒｅｒ)が必要と判断することができる。同様にＡｔｔａｃｈ ＲｅｑｕｅｓｔメッセージのＴｙｐｅがリレーを示すと、その端末にリレー動作のためのベアラーコンテクスト(Ｂｅａｒｅｒ ｃｏｎｔｅｘｔ)を決定することができる。また、Ａｔｔａｃｈ ＲｅｑｕｅｓｔメッセージのＵＥ ｎｅｔｗｏｒｋ Ｃａｐａｂｉｌｉｔｙに端末のＲｅｌａｙ ｃａｐａｂｉｌｉｔｙが表示されているか、Ｄｅｖｉｃｅ Ｐｒｏｐｅｒｔｙにリレー端末であることが設定されていると、その端末がＰｒｏＳｅリレーサービスを用いる場合に備えてＰｒｏＳｅリレートラフィック送信に適合したベアラーコンテクストを決定することができる。
【００３３】
ＭＭＥ１３０は、Ａｔｔａｃｈ Ｒｅｑｕｅｓｔを送信したＵＥ２(１１０)がリレーを行っても良いサブスクリプション(ｓｕｂｓｃｒｉｐｔｉｏｎ)を持っているか確認するためにＨＳＳと交渉してＵＥのサブスクリプション情報を確認し、リレー機能のための端末コンテクスト(Ｃｏｎｔｅｘｔ)を獲得することができる(ｓ１０５)。端末コンテクストは、ＵＥがリレー役目を行うことができるかに対する情報、リレー用ベアラー接続を確立する時に用いられるＡＲＰ(Ａｌｌｏｃａｔｉｏｎ ａｎｄ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ)、ＱＣＩ(ＱｏＳＣｌａｓｓＩｄｅｎｔｉｆｉｅｒ)、ＵＥ−ＡＭＢＲ(Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ)、リレー用ＡＰＮに対するＡＰＮ−ＡＭＢＲなどを含むことができる。ＭＭＥがＡｔｔａｃｈ Ｒｅｑｕｅｓｔを送信したＵＥ２がリレーを行うのに必要なサブスクリプション情報を持っていると、前記ＨＳＳとのネゴシエーションを省略することができる。
【００３４】
ＭＭＥ１３０は、Ａｔｔａｃｈ Ｒｅｑｕｅｓｔを送信した端末にベアラー接続を提供するためにＳ−ＧＷ(Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ)／Ｐ−ＧＷ(ＰＤＮ Ｇａｔｅｗａｙ)１４０でＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔを送信する(ｓ１１０)。追加的に前記Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ送信時のリレー用ベアラー接続確立を他のベアラー接続確立より先ず処理することができ、このためにＳ−ＧＷ／Ｐ−ＧＷで当該リクエストを速やかに処理するようにＣｒｅａｔｅ Ｓｅｓｓｉｏｎ ＲｅｑｕｅｓｔメッセージのＩｎｄｉｃａｔｉｏｎ ＦｌａｇあるいはＳｉｇｎａｌｉｎｇ Ｐｒｉｏｒｉｔｙ Ｉｎｄｉｃａｔｉｏｎ、もしくはベアラーコンテクストのＱｏＳ値に高い優先順位を有する値を含んで送信することができる。前記メッセージを受信したＳ−ＧＷ／Ｐ−ＧＷは、Ｉｎｄｉｃａｔｉｏｎ ｆｌａｇもしくはＳｉｇｎａｌｉｎｇ Ｐｒｉｏｒｉｔｙ Ｉｎｄｉｃａｔｉｏｎを確認して他の端末またはＭＭＥからのリクエストよりさらに優先的にメッセージを処理することができ、または、ベアラー情報でＱｏＳ値を確認してリレーサービスのために提供することができるＱＣＩまたはＡＲＰ値を持つと、前記リクエストを優先的に処理しなければならないと判断することができる。
【００３５】
Ｓ−ＧＷ／Ｐ−ＧＷ１４０は、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅで前記Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔに対する応答を行い(ｓ１１５)、これを受信したＭＭＥ１３０はＩｎｉｔｉａｌ Ｃｏｎｔｅｘｔ ＳｅｔｕｐＲｅｑｕｅｓｔにＡｔｔａｃｈ Ａｃｃｅｐｔメッセージとベアラーコンテクスト情報を含んでｅＮＢに伝達する(ｓ１２０)。
【００３６】
前記１２０段階によってＭＭＥ１３０は、前記Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ ＲｅｑｕｅｓｔのＰｒｏＳｅ ａｕｔｈｏｒｉｚｅｄ情報領域にＰｒｏＳｅ端末−ネットワークリレー値を設定して当該ＵＥがＰｒｏＳｅ端末−ネットワークリレーを用いる端末であることをｅＮＢ１２０に通知することができる。または、ＭＭＥはＥ−ＴＲＡＢｔｏｂｅｓｅｔｕｐｌｉｓｔ情報領域のＥ−ＲＡＢ ｌｅｖｅｌ ＱｏＳ ｐａｒａｍｅｔｅｒにリレー用ＱＣＩ値あるいはＡＲＰ値を設定してｅＮＢが当該ＵＥがリレーを用いることができることを認知する。前記のような方法でＩｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを受信したｅＮＢはＵＥ２(１１０)がＰｒｏＳｅ ＵＥ ｔｏ Ｎｅｔｗｏｒｋリレーを用いる端末であることを認知する。
【００３７】
ｅＮＢ１２０は、ＵＥ２(１１０)にＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージでＡｔｔａｃｈ Ａｃｃｅｐｔを伝達し(ｓ１２５、Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔにあるベアラーコンテクストに基づいて端末とｅＮＢ間のベアラー接続を確立するようになる(ｓ１３０)。端末とｅＮＢ間のベアラー接続が確立されると、ｅＮＢはＩｎｉｔｉａｌ ｃｏｎｔｅｘｔ Ｓｅｔｕｐ ｒｅｓｐｏｎｓｅをＭＭＥ１３０に送信してベアラーが設定されたことを通知し(ｓ１３５)、ＭＭＥはＳ−ＧＷ／Ｐ−ＧＷ１４０にＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔを送信してｅＮＢとＳ−ＧＷ／Ｐ−ＧＷ間のベアラー接続を確立する。ＵＥ２はＡｔｔａｃｈ ＣｏｍｐｌｅｔｅメッセージをＭＭＥに送信してＡｔｔａｃｈ手続きを終了する(ｓ１４０)。
【００３８】
前記１４０段階による結果でＰｒｏＳｅリレーを行う端末に対する情報を獲得したｅＮＢ１２０は当該端末のコンテクストを記憶する(ｓ１５０)。前記情報は端末がＰｒｏＳｅ端末−ネットワークリレー動作を行うことができるという許可(Ａｕｔｈｏｒｉｚａｔｉｏｎ)情報及び／または端末がＰｒｏＳｅ端末−ネットワークリレー動作を行うことができる能力(ｃａｐａｂｉｌｉｔｙ)を持っていることを指示(Ｉｎｄｉｃａｔｉｏｎ)する情報であってもよい。
【００３９】
ｅＮＢ１２０はＰｒｏＳｅ端末−ネットワークリレーサービスを提供するためにリレーＵＥを選択することができる(ｓ１５５)。ｅＮＢは前記１５５段階を介してＭＭＥから伝達された特定ＵＥに対するリレー実行許可もしくはリレー実行指示に基ついて特定ＵＥをリレーＵＥで選択することができる。ｅＮＢはリレーＵＥを選択する動作のために専用の(Ｄｅｄｉｃａｔｅｄ) 無線リソース制御(Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ、ＲＲＣ)シグナリング(ｓｉｇｎａｌｉｎｇ)を利用したりシステム情報ブロック(Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ、ＳＩＢ)ブロードキャスト(ｂｒｏａｄｃａｓｔ)を用いることができる。例えば、ｅＮＢはＵＥ２(１１０)にｄｅｄｉｃａｔｅｄ ＲＲＣ Ｓｉｇｎａｌｉｎｇを用いてリレーＵＥであることを通知することができる。
【００４０】
Ｄｅｄｉｃａｔｅｄ ＲＲＣ Ｓｉｇｎａｌｉｎｇを用いる場合、ｅＮＢ１２０は特定端末に対するＲＲＣメッセージをＣ−ＲＮＴＩで区分して伝達することができる。ｅＮＢはこのＲＲＣメッセージに当該ＵＥがリレー動作を行うことができるという許可情報を含むか、当該ＵＥがリレー動作を行うようにトリガーするインジケータを含むことができる。または、このＲＲＣメッセージにリレーのために用いるリソースプール(Ｒｅｓｏｕｒｃｅ Ｐｏｏｌ)を伝達することができ、前記ＲＲＣメッセージを受信したＵＥはリレー用リソースプールに係る情報がＲＲＣメッセージに含まれていると、リレーを行うように指示を受けたと判断したり、リレーを行うように許可を受けたと判断することができる。
【００４１】
ｅＮＢ１２０がＳＩＢ ｂｒｏａｄｃａｓｔを用いてリレーを選択する場合、ＳＩＢメッセージにリレー役目を行う端末のＣ−ＲＮＴＩを含んでブロードキャストすることができる。もしくはｅＮＢはＳＩＢメッセージにリレーのためのリソースプール情報を含ませることができ、リレー機能を行うことができるＵＥは前記リソースプール情報を参照してリレー動作可否を決定したり、もしくはリレーリソースプールが明示された場合、動作上の手続きでリレー機能実行を開始することができる。
【００４２】
ｅＮＢ１２０は自分がサービスするセル(ｃｅｌｌ)に位置した端末に測定報告(Ｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔ)を受信するようになるのに、この測定報告に基づいて端末が受信する信号の強度が特定しきい値(ｔｈｒｅｓｈｏｌｄ)以下であることが分かるようになれば、当該端末が直ちにネットワークカバレッジを外れるようになると判断することができる。便宜上、このＵＥを潜在的リモートＵＥ(Ｐｏｔｅｎｔｉａｌ ＲｅｍｏｔｅＵＥ)と称する。
【００４３】
この場合、ｅＮＢ１２０は前記測定報告を送信した端末がＰｒｏＳｅ端末−ネットワークリレーサービスを用いることができるためにリレー探索動作を行うようにトリガーすることができる(ｓ１６０)。例えば、ｅＮＢは測定報告を送信したＵＥ１(１００)の信号の強度が特定しきい値以下であればリレー探索動作を行うようにトリガーすることができる。前記トリガー動作を行う前に、ｅＮＢは自分がサービスするＵＥのうちのリレー動作を行うことができるか、リレー動作を行うように許可を受けたＵＥがあるか確認し、少なくとも１個以上のＵＥが前記確認手続きに符合すると判断される場合、潜在的リモートＵＥにリレー探索手続きを開始するようにトリガーすることができる。この動作はリレー可能端末がないにもかかわらず潜在的リモートＵＥにリレー探索を開始するようにする不必要な動作を無くすためである。端末はｅＮＢからしきい値を受信する代わりにＰｒｏＳｅ Ｆｕｎｃｔｉｏｎから伝達されたしきい値を用いてリレー探索可否を判断することができる。
【００４４】
ｅＮＢが潜在的リモートＵＥがリレー探索を行うようにトリガーする方法は、第１にｄｅｄｉｃａｔｅｄ ＲＲＣメッセージを使用したり、第２にＳＩＢを介してＢｒｏａｄｃａｓｔする方法がある。第１にｄｅｄｉｃａｔｅｄ ＲＲＣメッセージを使用する場合、潜在的リモートＵＥにセル信号強度に対するしきい値を提供して潜在的リモートＵＥが行ったセル信号に対する測定値が前記しきい値以下であればリレー探索過程を行うようにできる。前記セル信号は、ｅＮＢ１２０がブロードキャストするＳＩＢ ｓｉｇｎａｌｉｎｇの信号強度であるか、もしくはＤ２Ｄのためのサイドリンク(Ｓｉｄｅ ｌｉｎｋ)信号の強度であってもよい。もしくはｅＮＢはｄｅｄｉｃａｔｅｄ ＲＲＣメッセージにリレー探索を指示する識別子を含んで潜在的リモートＵＥに伝達することができ、これを受信した潜在的リモートＵＥはリレー探索を行う。
【００４５】
ｅＮＢがＳＩＢを介してリレー探索をトリガーする場合、セル信号強度に対するしきい値をＳＩＢ情報で提供して潜在的リモートＵＥが行ったセル信号に対する測定値が前記しきい値以下であればリレー探索を行うようにできる。前記セル信号はｅＮＢがブロードキャストするＳＩＢ ｓｉｇｎａｌｉｎｇの信号強度であるか、もしくはＤ２Ｄのためのサイドリンク信号の強度であってもよい。前記しきい値は予め定まるか、またはｅＮＢ、もしくはＰｒｏＳｅ Ｆｕｎｃｔｉｏｎが端末に通知することができる。
【００４６】
図２は、ＰｒｏＳｅ端末がリレー役目を行うためにＰＤＮ接続確立手続きを行う方法を示した図面である。
【００４７】
図２によれば、ＰｒｏＳｅ端末はリレー役目を行うためにネットワークにリレーであることを通知しながらリレー用ＰＤＮ接続確立手続きを行い、その手続きを介してコアネットワークは基地局に当該端末のリレー実行に係る情報を提供し、基地局は前記情報に基づいてリレー端末を選択してカバレッジの外に移動することで予想される端末にリレーを探索するようにトリガーすることができる。
【００４８】
ＰｒｏＳｅ利用端末であるＵＥ２(１１０)はネットワークにＰＤＮ接続を確立するためにネットワーク装置中の移動性管理装置であるＭＭＥ１３０にＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔメッセージを送信する(ｓ２００)。前記端末はＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔメッセージを用いて自分がリレー動作を行う端末、もしくはリレー動作が可能な端末であることを次のような方法で通知することができる。第１にＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ ＲｅｑｕｅｓｔメッセージのＡＰＮ情報領域にリレー用ＰＤＮ接続のためのＡＰＮを設定することができる。前記リレー用ＰＤＮ接続のためのＡＰＮはＰｒｏＳｅ端末がＰｒｏＳｅ動作のためにＰｒｏＳｅ Ｆｕｎｃｔｉｏｎとサービス認可(Ｓｅｒｖｉｃｅ Ａｕｔｈｏｒｉｚａｔｉｏｎ)手続きを行う時、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎから提供されることができる。または端末はＰｒｏＳｅ端末のＵＩＣＣ(Ｕｎｉｖｅｒｓａｌ ＩＣ Ｃａｒｄ)に予め設定された値を用いて設定することができる。第２に端末はＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ ＲｅｑｕｅｓｔメッセージのＤｅｖｉｃｅ Ｐｒｏｐｅｒｔｙ情報領域にＰｒｏＳｅリレー端末であることを示すインジケータ(ｉｎｄｉｃａｔｉｏｎ)を設定することができる。第３に端末はＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ ＲｅｑｕｅｓｔメッセージのＰｒｏｔｏｃｏｌ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｏｐｔｉｏｎｓ情報領域のＡｄｄｉｔｉｏｎａｌ ｐａｒａｍｅｔｅｒ部分にリレーであることを示す識別子を設定することができる。ＵＥ２は前記３つ方法のうちの少なくとも一つ以上を用いて自分がＰｒｏＳｅリレー端末であることを通知することができる。
【００４９】
前記の３つ方法のうちの少なくとも一つ以上を用いて構成されたＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔメッセージを受信したＭＭＥ１３０は、前記の方法による情報領域に基づいてＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔを送信した端末がＰｒｏＳｅ端末−ネットワークリレーを行う端末であることを認知することができる。ＭＭＥはＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔメッセージに基づいてリレー用ＰＤＮ接続のためのＡＰＮ値がＡＰＮ情報領域に設定された場合、当該端末がリレー用ベアラーが必要と判断することができる。または、Ｄｅｖｉｃｅ Ｐｒｏｐｅｒｔｙにリレー端末であることが設定されているか、もしくはＰｒｏｔｏｃｏｌ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｏｐｔｉｏｎｓ情報領域にリレーであることを示す識別子があればその端末のＰｒｏＳｅリレートラフィック送信に適合したベアラーコンテクストを決定することができる。
【００５０】
ＭＭＥは、ＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔを送信したＵＥ２(１１０)がリレーを行っても良いサブスクリプションを持っているか確認するためにＨＳＳと交渉してＵＥのサブスクリプション情報を確認し、リレー機能のための端末コンテクストを獲得することができる(ｓ２０５)。端末コンテクストはＵＥがリレー役目を行うことができるかに対する情報、リレー用ベアラー接続を確立する時に用いられるＡＲＰ、ＱＣＩ、ＵＥ−ＡＭＢＲ、リレー用ＡＰＮに対するＡＰＮ−ＡＭＢＲなどを含むことができる。ＭＭＥがＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔを送信したＵＥ２がリレーを行うのに必要なサブスクリプション情報を持っていると、前記ＨＳＳとのネゴシエーションを省略することができる。
【００５１】
ＭＭＥ１３０は、ＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔを送信した端末にＢｅａｒｅｒ接続を提供するためにＳ−ＧＷ／Ｐ−ＧＷ１４０でＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔを送信する(ｓ２１０)。追加的に、前記Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ送信時のリレー用ベアラー接続確立を他のベアラー接続確立より先ず処理することができ、このためにＳ−ＧＷ／Ｐ−ＧＷで当該リクエストを速やかに処理するようにＭＭＥはＣｒｅａｔｅ Ｓｅｓｓｉｏｎ ＲｅｑｕｅｓｔメッセージのＩｎｄｉｃａｔｉｏｎＦｌａｇあるいはＳｉｇｎａｌｉｎｇ Ｐｒｉｏｒｉｔｙ Ｉｎｄｉｃａｔｉｏｎ、もしくはＢｅａｒｅｒＣｏｎｔｅｘｔのＱｏＳ値に高い優先順位を有する値を含んで送信することができる。前記メッセージを受信したＳ−ＧＷ／Ｐ−ＧＷはＩｎｄｉｃａｔｉｏｎ ｆｌａｇもしくはＳｉｇｎａｌｉｎｇ Ｐｒｉｏｒｉｔｙ Ｉｎｄｉｃａｔｉｏｎを確認して他の端末またはＭＭＥからのリクエストよりさらに優先的に前記メッセージを処理することができ、またはベアラー情報でＱｏＳ値を確認してリレーサービスのために提供することができるＱＣＩまたはＡＲＰ値を持つと、前記リクエストを優先的に処理しなければならないと判断することができる。
【００５２】
Ｓ−ＧＷ／Ｐ−ＧＷ１４０は、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅで前記Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔに対する応答を行い(ｓ２１５)、これを受信したＭＭＥ１３０はＢｅａｒｅｒ Ｓｅｔｕｐ ＲｅｑｕｅｓｔメッセージにＢｅａｒｅｒＣｏｎｔｅｘｔ情報を含んでｅＮＢ１２０に伝達する(ｓ２２０)。
【００５３】
前記２２０段階によってＭＭＥは前記Ｂｅａｒｅｒ Ｓｅｔｕｐ ＲｅｑｕｅｓｔのＰｒｏＳｅ関連情報領域にＰｒｏＳｅ端末−ネットワークリレー値を設定して当該ＵＥがＰｒｏＳｅ端末−ネットワークリレーを用いる端末であることをｅＮＢに通知することができる。または、ＭＭＥはＥ−ＴＲＡＢｔｏｂｅｓｅｔｕｐｌｉｓｔ情報領域のＥ−ＲＡＢ ｌｅｖｅｌ ＱｏＳ ｐａｒａｍｅｔｅｒにリレー用ＱＣＩ値もしくはＡＲＰ値を示してｅＮＢが当該ＵＥがリレーを用いることができることを認知するようにできる。前記のような方法でＢｅａｒｅｒ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを受信したｅＮＢはＵＥ２(１１０)がＰｒｏＳｅ端末−ネットワークリレーを用いる端末であることを認知する。
【００５４】
ｅＮＢ１２０は端末とＲＲＣメッセージを介して無線ベアラー接続を確立する(ｓ２２５)。この時、ｅＮＢはＵＥ２がリレー機能を行うように選択することができ、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージにＵＥ２がリレーで動作することができることを許可するインジケータを含むか、リレーで動作するようにする指示を含むことができる。ＵＥ２(１１０)はｅＮＢが送信したＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの前記指示を識別してリレー実行可否を判断することができる。
【００５５】
端末とｅＮＢ１２０間のベアラー接続が確立されると、ｅＮＢはＢｅａｒｅｒ Ｓｅｔｕｐ ｒｅｓｐｏｎｓｅをＭＭＥ１３０へ送信してベアラーが設定されたことを通知し(ｓ２３０)、ＭＭＥはＳ−ＧＷ／Ｐ−ＧＷ１４０にＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔを送信してｅＮＢとＳ−ＧＷ／Ｐ−ＧＷ間のベアラー接続を確立する(ｓ２３５)。
【００５６】
前記各段階による結果でＰｒｏＳｅリレーを行う端末に対する情報を獲得したｅＮＢは当該端末のコンテクストを記憶する(ｓ２４０)。前記情報は、端末がＰｒｏＳｅ端末−ネットワークリレー動作を行うことができるという許可(Ａｕｔｈｏｒｉｚａｔｉｏｎ)に対する指示及び／または端末がＰｒｏＳｅ端末−ネットワークリレー動作を行うことができる能力(ｃａｐａｂｉｌｉｔｙ)を持っていることを指示する情報であってもよい。
【００５７】
ｅＮＢ１２０はＰｒｏＳｅ端末−ネットワークリレーサービスを提供するためにリレーＵＥを選択することができる(ｓ２４５)。ｅＮＢは前記２４５段階を介してＭＭＥ１３０から伝達された特定ＵＥに対するリレー実行許可もしくはリレー実行指示に基づいて特定ＵＥをリレーＵＥで選択することができる。
【００５８】
ｅＮＢはリレーＵＥを選択する動作のために専用ＲＲＣシグナリング(Ｄｅｄｉｃａｔｅｄ ＲＲＣ ｓｉｇｎａｌｉｎｇ)を利用したりＳＩＢブロードキャストを利用することができる。Ｄｅｄｉｃａｔｅｄ ＲＲＣ Ｓｉｇｎａｌｉｎｇを利用する場合、ｅＮＢは特定端末に対するＲＲＣメッセージをＣ−ＲＮＴＩで区分して伝達することができる。このＲＲＣメッセージに当該ＵＥがリレー動作を行うことができるという許可情報を含むか、当該ＵＥがリレー動作を行うようにトリガーする指示を含むことができる。または、このＲＲＣメッセージにリレーのために用いるリソースプール(Ｒｅｓｏｕｒｃｅ Ｐｏｏｌ)を伝達することができ、前記ＲＲＣメッセージを受信したＵＥはリレー用リソースプール関連情報がＲＲＣメッセージに含まれていると、リレーを行うように指示を受けたと判断したり、リレーを行うように許可を受けたと判断することができる。
【００５９】
ｅＮＢがＳＩＢブロードキャストを用いてリレーを選択する場合、ＳＩＢメッセージにリレー役目を行う端末のＣ−ＲＮＴＩを含んでブロードキャストすることができる。もしくはｅＮＢはＳＩＢメッセージにリレーのためのリソースプール関連情報を含ませることができ、リレー機能を行うことができるＵＥは前記リソースプール情報を参照してリレー動作可否を決定したり、もしくはリレーリソースプールが明示された場合、動作上の手続きでリレー機能を開始することができる。
【００６０】
ｅＮＢ１２０は自分がサービスするセルに位置した端末から測定報告を受信するようになるのに、この測定報告に基づいてｅＮＢが端末が受信する信号の強度が特定しきい値以下であることが分かるようになれば、当該端末が直ちにネットワークカバレッジを外れるようになると判断することができる。便宜上、このＵＥを潜在的リモートＵＥと称する。
【００６１】
この場合、ｅＮＢ１２０は前記測定報告を送信した端末がＰｒｏＳｅ端末−ネットワークリレーサービスを用いることができるようにするためにリレー探索動作を行うようにトリガーすることができる(ｓ２５０)。前記トリガー動作を行う前に、ｅＮＢは自分がサービスするＵＥの中でリレー動作を行うことができるか、リレー動作を行うように許可を受けたＵＥがあるか確認し、少なくとも１個以上のＵＥが前記確認手続きに符合すると判断される場合、潜在的リモートＵＥにリレー探索手続きの開始をトリガーすることができる。この動作はリレー可能端末がないにもかかわらず潜在的リモートＵＥにリレー探索を開始するようにする不必要な動作を無くすためである。また、端末はｅＮＢからしきい値を受信する代わりにＰｒｏＳｅ Ｆｕｎｃｔｉｏｎから伝達されたしきい値を用いてリレー探索手続き実行可否を判断することができる。
【００６２】
ｅＮＢ１２０が潜在的リモートＵＥ(この場合、ＵＥ１(１００)が潜在的リモートＵＥとなることができる)がリレー探索を行うようにトリガーする方法は、第１にｄｅｄｉｃａｔｅｄ ＲＲＣメッセージを用いるか、第２にＳＩＢを介してブロードキャストする方法がある。第１にｄｅｄｉｃａｔｅｄ ＲＲＣメッセージを用いる場合、ｅＮＢは潜在的リモートＵＥにセル信号強度に対するしきい値を提供して潜在的リモートＵＥが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はｅＮＢがブロードキャストするＳＩＢシグナリングの強度であるか、もしくはＤ２Ｄのためのサイドリンク(Ｓｉｄｅ ｌｉｎｋ) 信号の強度であってもよい。または、ｅＮＢはｄｅｄｉｃａｔｅｄ ＲＲＣメッセージにリレー探索を指示する識別子を含んで伝達することができ、これを受信した潜在的リモートＵＥはリレー探索を行う。
【００６３】
ｅＮＢがＳＩＢを介してリレー探索手続きをトリガーする場合、セル信号強度に対するしきい値をＳＩＢ情報で提供して潜在的リモートＵＥが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はｅＮＢがブロードキャストするＳＩＢシグナリングの強度であるか、もしくはＤ２Ｄのためのサイドリンク信号の強度であってもよい。前記しきい値は予め定まるか、またはｅＮＢ、もしくはＰｒｏＳｅ Ｆｕｎｃｔｉｏｎが端末に通知することができる。
【００６４】
図３は、ＰｒｏＳｅ端末がリレー役目を行うためにＳｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ手続きを行う方法を示した図面である。
【００６５】
図３によれば、ＰｒｏＳｅ端末がリレー役目を行うためにネットワークにリレーであることを通知しながらＳｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ手続きを行い、その手続きを介してコアネットワークが基地局に当該端末のリレー実行に係る情報を提供し、基地局が前記情報に基づいてリレー端末を選択してカバレッジの外に移動することで予想される端末にリレーを探索するようにトリガーすることができる。
【００６６】
ＰｒｏＳｅ利用端末であるＵＥ２(１１０)は、ネットワークにリレー用ベアラー接続を確立するためにネットワーク装置中の移動性管理装置であるＭＭＥ１３０にＳｅｒｖｉｃｅ Ｒｅｑｕｅｓｔメッセージを送信する(ｓ３００)。またはＵＥ２はＭＭＥにＥｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔメッセージを送信することができる。前記端末は、Ｅｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔメッセージを用いて自分がリレー動作を行う端末もしくはリレー動作が可能な端末であることを次のような方法で通知することができる。第１に、端末はＥｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ ＲｅｑｕｅｓｔメッセージのＳｅｒｖｉｃｅＴｙｐｅＦｉｅｌｄにＰｒｏＳｅ端末−ネットワークリレーサービスを用いるという意味を示す識別子を含むことができる。第２に、端末はＥｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ ＲｅｑｕｅｓｔメッセージのＤｅｖｉｃｅ ＰｒｏｐｅｒｔｙｆｉｅｌｄにＰｒｏＳｅ端末−ネットワークリレー利用端末であることを明示することができる。前記の方法のうちの少なくとも一つ以上を用いて構成されたＥｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔメッセージを受信したＭＭＥは前記の方法による情報領域に基づいてＥｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔを送信した端末がＰｒｏＳｅ端末−ネットワークリレーを行う端末であることを認知することができる。
【００６７】
ＭＭＥ１３０は、Ｓｅｒｖｉｃｅ  ｒｅｑｕｅｓｔまたはＥｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔを送信したＵＥ２(１１０)がリレーを行っても良いサブスクリプション(ｓｕｂｓｃｒｉｐｔｉｏｎ)を持っているか確認するためにＨＳＳ１５０と交渉してＵＥのサブスクリプション情報を確認し、リレー機能のための端末コンテクストを獲得することができる。端末コンテクストはＵＥがリレー役目を行うことができるかに対する情報、リレー用ベアラー接続を確立する時に用いられるＡＲＰ、ＱＣＩ、ＵＥ−ＡＭＢＲ、リレー用ＡＰＮに対するＡＰＮ−ＡＭＢＲなどを含むことができる。ＭＭＥがＳｅｒｖｉｃｅ Ｒｅｑｕｅｓｔを送信したＵＥ２がリレーを行うのに必要なサブスクリプション情報を予め持っていると、前記ＨＳＳとのネゴシエーションを省略することができる(ｓ３０５)。
【００６８】
ＭＭＥ１３０は、Ｓｅｒｖｉｃｅ ＲｅｑｕｅｓｔまたはＥｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔを送信した端末にベアラー接続を提供するためにＩｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔにベアラーコンテクスト情報を含んでｅＮＢ１２０に伝達する(ｓ３１０)。前記３１０段階によりＭＭＥは前記Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ ＲｅｑｕｅｓｔのＰｒｏＳｅ ａｕｔｈｏｒｉｚｅｄ情報領域にＰｒｏＳｅ端末−ネットワークリレー値を設定して当該ＵＥがＰｒｏＳｅ端末−ネットワークリレーを用いる端末であることをｅＮＢに通知することができる。または、ＭＭＥはＥ−ＴＲＡＢ ｔｏ ｂｅ ｓｅｔｕｐ ｌｉｓｔ情報領域のＥ−ＲＡＢｌｅｖｅｌＱｏＳｐａｒａｍｅｔｅｒにリレー用ＱＣＩ値もしくはＡＲＰ値を含ませてこれを介してｅＮＢが当該ＵＥがリレーを用いることができることを認知することができる。前記のような方法でＩｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを受信したｅＮＢはＵＥ２(１１０)がＰｒｏＳｅ端末−ネットワークリレーを用いる端末であることを認知する。
【００６９】
ｅＮＢ１２０は端末(この場合、ＵＥ２(１１０)になることができる)とＲＲＣメッセージを介して無線ベアラー接続を確立する(ｓ３１５)。この時、ｅＮＢはＵＥ２がリレー機能を行うように選択することができ、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージにＵＥ２がリレーで動作することができることを許可する指示(または、インジケータ)を含むか、リレーで動作するようにする指示を含むことができる。ＵＥ２は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの前記指示を識別してリレー実行可否を判断することができる。
【００７０】
ＵＥ２(１１０)とｅＮＢ１２０間のベアラー接続が確立されると、ｅＮＢはＩｎｉｔｉａｌｃｏｎｔｅｘｔ Ｓｅｔｕｐ ｒｅｓｐｏｎｓｅをＭＭＥ１３０に送信してベアラーが設定されたことを通知し(ｓ３２０)、ＭＭＥはＳ−ＧＷ／Ｐ−ＧＷ１４０にＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔを送信してｅＮＢとＳ−ＧＷ／Ｐ−ＧＷ間のベアラー接続を確立する(ｓ３２５)。
【００７１】
前述した段階による結果でＰｒｏＳｅリレーを行う端末に対する情報を獲得したｅＮＢ１２０は当該端末のコンテクストを記憶する(ｓ３３０)。前記情報は端末がＰｒｏＳｅ端末−ネットワークリレー動作を行うことができるという許可(Ａｕｔｈｏｒｉｚａｔｉｏｎ)に対する指示及び／または端末がＰｒｏＳｅ端末−ネットワークリレー動作を行うことができる能力(ｃａｐａｂｉｌｉｔｙ)を持っていることを指示する情報であってもよい。
【００７２】
ｅＮＢ１２０は、ＰｒｏＳｅ端末−ネットワークリレーサービスを提供するためにリレーＵＥを選択することができる(ｓ３３５)。ｅＮＢは前記３３５段階を介してＭＭＥ１３０から伝達された特定ＵＥに対するリレー実行許可もしくはリレー実行指示に基づいて特定ＵＥをリレーＵＥで選択することができる。この場合、ｅＮＢはＵＥ２(１１０)をリレーＵＥで選択することができる。ｅＮＢはリレーＵＥを選択する動作のために専用ＲＲＣシグナリング(Ｄｅｄｉｃａｔｅｄ ＲＲＣ ｓｉｇｎａｌｉｎｇ)を用いるかＳＩＢブロードキャストを用いることができる。
【００７３】
Ｄｅｄｉｃａｔｅｄ ＲＲＣ ｓｉｇｎａｌｉｎｇを用いる場合、ｅＮＢは特定端末に対するＲＲＣメッセージをＣ−ＲＮＴＩで区分して伝達することができる。このＲＲＣメッセージに当該ＵＥがリレー動作を行うことができるという許可情報を含むか、当該ＵＥがリレー動作を行うようにトリガーする指示を含むことができる。または、このＲＲＣメッセージにリレーのために用いるリソースプール(Ｒｅｓｏｕｒｃｅ Ｐｏｏｌ)関連情報を伝達することができ、前記ＲＲＣメッセージを受信したＵＥはリレー用リソースプール関連情報がＲＲＣメッセージに含まれていると、リレーを行うように指示を受けたと判断したり、リレーを行うように許可を受けたと判断することができる。
【００７４】
ｅＮＢがＳＩＢブロードキャストを用いてリレーを選択する場合、ｅＮＢはＳＩＢメッセージにリレー役目を行う端末のＣ−ＲＮＴＩを含んでブロードキャストすることができる。または、ｅＮＢはＳＩＢメッセージにリレーのためのリソースプール関連情報を含ませることができ、リレー機能を行うことができるＵＥは前記リソースプール情報に基づいてリレー動作可否を決定したり、もしくはリレーリソースプール情報が含まれた場合、動作上の手続きでリレー機能を実行を開始することができる。
【００７５】
ｅＮＢ１２０は自分がサービスするセルに位置した端末に測定報告を受信するようになるのに、この測定報告に基づいて端末が受信する信号の強度が特定しきい値以下であることが分かるようになれば、当該端末が直ちにネットワークカバレッジを外れるようになると判断することができる。便宜上、このＵＥを潜在的リモートＵＥと称する。この場合、ＵＥ１(１００)が潜在的リモートＵＥになることができる。
【００７６】
この場合、ｅＮＢ１２０は前記測定報告を送信した端末がＰｒｏＳｅ端末−ネットワークリレーサービスを用いることができるようにするためにリレー探索動作を行うようにトリガーすることができる(ｓ３４０)。前記トリガー動作を行う前に、ｅＮＢは自分がサービスするＵＥの中でリレー動作を行うことができるか、リレー動作を行うように許可を受けたＵＥがあるか確認して少なくとも１個以上のＵＥが前記確認手続きに符合すると判断される場合、潜在的リモートＵＥにリレー探索手続きの開始をトリガーすることができる。この動作は、リレー可能端末がないにもかかわらず潜在的リモートＵＥにリレー探索を開始するようにする不必要な動作を無くすためである。端末はｅＮＢからしきい値を受信する代わりにＰｒｏＳｅ Ｆｕｎｃｔｉｏｎから伝達されたしきい値を用いてリレー探索可否を判断することができる。
【００７７】
ｅＮＢ１２０が潜在的リモートＵＥがリレー探索を行うようにトリガーする方法は、第１にｄｅｄｉｃａｔｅｄ ＲＲＣメッセージを用いるか、第２にＳＩＢを介してブロードキャストする方法があり得る。第１にｄｅｄｉｃａｔｅｄ ＲＲＣメッセージを用いる場合、ｅＮＢは潜在的リモートＵＥにセル信号強度に対するしきい値を提供して潜在的リモートＵＥが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はｅＮＢがブロードキャストするＳＩＢシグナリングの強度であるか、もしくはＤ２Ｄのためのサイドリンク(Ｓｉｄｅ ｌｉｎｋ)信号の強度であってもよい。もしくはｄｅｄｉｃａｔｅｄ ＲＲＣメッセージにリレー探索を実行を指示する識別子を含んで伝達することができ、これを受信した潜在的リモートＵＥはリレー探索を行う。
【００７８】
ｅＮＢがＳＩＢを介してリレー探索をトリガーする場合、セル信号強度に対するしきい値をＳＩＢ情報で提供して潜在的リモートＵＥが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はｅＮＢがｂｒｏａｄｃａｓｔするＳＩＢシグナリングの強度であるか、もしくはＤ２Ｄのためのサイドリンク信号の強度であってもよい。前記しきい値は予め定まるか、またはｅＮＢ、もしくはＰｒｏＳｅ Ｆｕｎｃｔｉｏｎが端末に通知することができる。
【００７９】
図４は、ＰｒｏＳｅ端末がリレー役目を行うためにＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ手続きを行う方法を示した図面である。
【００８０】
図４によれば、ＰｒｏＳｅ端末はリレー役目を行うためにネットワークにリレーであることを通知しながらＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ手続きを行い、その手続きを介してコアネットワークが基地局に当該端末のリレー実行に係る情報を提供し、基地局は前記情報に基づいてリレー端末を選択してカバレッジの外に移動することで予想される端末にリレーを探索するようにトリガーすることができる。
【００８１】
ＰｒｏＳｅ利用端末であるＵＥ２(１１０)は、ネットワークにリレー用ベアラー接続を確立するためにネットワーク装置中の移動性管理装置であるＭＭＥ１３０にＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを送信する(ｓ４００)。前記端末はＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを用いて自分がリレー動作を行う端末もしくはリレー動作が可能な端末であることを次のような方法で通知することができる。第１に端末はＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージのＲｅｑｕｉｒｅｄ  ｔｒａｆｆｉｃ  ｆｌｏｗ  ＱｏＳ  ＦｉｅｌｄにＰｒｏＳｅ端末−ネットワークリレーサービスに該当するＱＣＩまたはＡＲＰ値を含むことができる。第２に端末はＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージのＰｒｏｔｏｃｏｌ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｏｐｔｉｏｎ ｆｉｅｌｄのａｄｄｉｔｉｏｎａｌ ｐａｒａｍａｔｅｒ領域にＰｒｏＳｅ端末−ネットワークリレー利用端末であることを明示することができる。第３に端末はＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージのＤｅｖｉｃｅ Ｐｒｏｐｅｒｔｉｅｓ情報領域にＰｒｏＳｅ端末−ネットワークリレー利用端末であることを明示することができる。
【００８２】
前記の方法中の少なくとも一つ以上を用いて構成されたＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを受信したＭＭＥは前記の方法による情報領域に基づいてＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔを送信した端末がＰｒｏＳｅ端末−ネットワークリレーを行う端末であることを認知することができる。
【００８３】
ＭＭＥ１３０はＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを送信したＵＥ２(１１０)がリレーを行っても良いサブスクリプション(ｓｕｂｓｃｒｉｐｔｉｏｎ)を持っているか確認するためにＨＳＳ１５０と交渉してＵＥのサブスクリプション情報を確認し、リレー機能のための端末コンテクストを獲得することができる。端末コンテクストはＵＥがリレー役目を行うことができるかに対する情報、リレー用ベアラー接続を確立する時に用いられるＡＲＰ、ＱＣＩ、ＵＥ−ＡＭＢＲ、リレー用ＡＰＮに対するＡＰＮ−ＡＭＢＲなどを含むことができる。ＭＭＥがＢｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔを送信したＵＥ２がリレーを行うのに必要なサブスクリプション情報を持っていると、前記ＨＳＳとのネゴシエーションを省略することができる(ｓ４０５)。
【００８４】
以後、ＭＭＥ１３０はＡｃｔｉｖａｔｅｄ Ｄｅｄｉｃａｔｅｄ Ｂｅａｒｅｒ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ及びＭｏｄｉｆｙ ＥＰＳ Ｂｅａｒｅｒ Ｃｏｎｔｅｘｔ ＲｅｑｕｅｓｔメッセージをＵＥ２(１１０)で送信し、または、Ｂｅａｒｅｒ Ｒｅｓｏｕｒｃｅ ＣｏｍｍａｎｄメッセージをＳ−ＧＷ及びＰ−ＧＷ１４０で送信する。以後、Ｓ−ＧＷ／Ｐ−ＧＷ１４０はＣｒｅａｔｅ Ｂｅａｒｅｒ ＲｅｑｕｅｓｔメッセージをＭＭＥ１３０で送信する。
【００８５】
ＭＭＥ１３０は、Ｂｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを送信した端末にベアラー接続を提供するためにＥ−ＲＡＢ Ｓｅｔｕｐ ｒｅｑｕｅｓｔメッセージにベアラーコンテクスト情報を含んでｅＮＢに伝達する(ｓ４２５)。前記４２５段階によってＭＭＥは前記Ｅ−ＲＡＢ Ｓｅｔｕｐ ｒｅｑｕｅｓｔのＰｒｏＳｅ関連情報領域にＰｒｏＳｅ端末−ネットワークリレー値を設定して当該ＵＥがＰｒｏＳｅ端末−ネットワークリレーを用いる端末であることをｅＮＢ１２０に通知することができる。または、Ｅ−ＴＲＡＢ ｔｏ ｂｅ ｓｅｔｕｐ ｌｉｓｔ情報領域のＥ−ＲＡＢｌｅｖｅｌＱｏＳｐａｒａｍｅｔｅｒにリレー用ＱＣＩ値もしくはＡＲＰ値を含ませてｅＮＢが当該ＵＥがリレーを用いることができることを認知するようにできる。前記のような方法でＥ−ＲＡＢ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを受信したｅＮＢはＵＥ２(１１０)がＰｒｏＳｅ端末−ネットワークリレーを用いる端末であることを認知することができる。
【００８６】
ｅＮＢ１２０は、端末とＲＲＣメッセージを介して無線ベアラー接続を確立する(ｓ４３０、ｓ４３５)。この時、ｅＮＢはＵＥ２(１１０)がリレー機能を行うように選択することができ、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージにＵＥ２がリレーで動作することができることを許可する指示(または、インジケータ)を含むか、リレーで動作するようにする指示を含むことができる。ＵＥ２はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの前記指示を識別してリレー実行可否を判断することができる。
【００８７】
前述した段階による結果でＰｒｏＳｅリレーを行う端末に対する情報を獲得したｅＮＢは当該端末のコンテクストを記憶する(ｓ４４０)。前記情報は端末がＰｒｏＳｅ端末−ネットワークリレー動作を行うことができるという許可(Ａｕｔｈｏｒｉｚａｔｉｏｎ)に対する指示及び／または端末がＰｒｏＳｅ端末−ネットワークリレー動作を行うことができる能力(ｃａｐａｂｉｌｉｔｙ)を持っていることを指示する情報であってもよい。
【００８８】
端末とｅＮＢ１２０間のベアラー接続が確立されると、ｅＮＢはＥ−ＲＡＢ Ｓｅｔｕｐ ｒｅｓｐｏｎｓｅをＭＭＥ１３０に送信してＢｅａｒｅｒが設定されたことを通知する(ｓ４４５)。以後、ＭＭＥ１３０は前記内容によってＣｒｅａｔｅ Ｂｅａｒｅｒ ＲｅｑｕｅｓｔメッセージをＳ−ＧＷ／Ｐ−ＧＷ１４０へ送信する(ｓ４５０)。
【００８９】
ｅＮＢ１２０はＰｒｏＳｅ端末−ネットワークリレーサービスを提供するためにリレーＵＥを選択することができる(ｓ４５５)。ｅＮＢは前記段階を介してＭＭＥから伝達された特定ＵＥに対するリレー実行許可もしくはリレー実行指示に基づいてｅＮＢが特定ＵＥをリレーＵＥで選択することができる。この場合、特定ＵＥはＵＥ２(１１０)となることができる。ｅＮＢはリレーＵＥを選択する動作のために専用ＲＲＣシグナリング(Ｄｅｄｉｃａｔｅｄ ＲＲＣ ｓｉｇｎａｌｉｎｇ)を用いるかＳＩＢブロードキャストを用いることができる。
【００９０】
Ｄｅｄｉｃａｔｅｄ ＲＲＣ ｓｉｇｎａｌｉｎｇを用いる場合、ｅＮＢは特定端末に対するＲＲＣメッセージをＣ−ＲＮＴＩで区分して伝達することができる。このＲＲＣメッセージにｅＮＢは当該ＵＥがリレー動作を行うことができるという許可情報を含むか、当該ＵＥがリレー動作を行うようにトリガーする指示を含むことができる。または、このＲＲＣメッセージにリレーのために用いるリソースプール(Ｒｅｓｏｕｒｃｅ Ｐｏｏｌ)関連情報を伝達することができ、前記ＲＲＣメッセージを受信したＵＥはリレー用リソースプール関連情報がＲＲＣメッセージに含まれていると、リレーを行うように指示を受けたと判断したり、リレーを行うように許可を受けたと判断することができる。
【００９１】
ｅＮＢ１２０がＳＩＢブロードキャストを用いてリレーを選択する場合、ｅＮＢはＳＩＢメッセージにリレー役目を行う端末のＣ−ＲＮＴＩを含んでブロードキャストすることができる。
【００９２】
もしくはｅＮＢはＳＩＢメッセージにリレーのためのリソースプール情報を含ませることができ、リレー機能を行うことができるＵＥは前記リソースプール情報に基づいてリレー動作可否を決定したり、もしくはリレーリソースプール情報が明示された場合、動作上の手続きでリレー機能を実行を開始することができる。
【００９３】
ｅＮＢ１２０は、自分がサービスするセルに位置した端末に測定報告を受信するようになるのに、この測定報告を参照して端末が受信する信号の強度が特定しきい値以下であることが分かるようになれば、当該端末が直ちにネットワークカバレッジを外れるようになると判断することができる。便宜上、このＵＥを潜在的リモートＵＥと称する。この場合、潜在的リモートＵＥはＵＥ１(１００)となることができる。
【００９４】
この場合、ｅＮＢは前記測定報告を送信した端末がＰｒｏＳｅ端末−ネットワークリレーサービスを用いることができるようにするためにリレー探索動作を行うようにトリガーすることができる(ｓ４６０)。前記トリガー動作を行う前に、ｅＮＢは自分がサービスするＵＥ中のリレー動作を行うことができるか、リレー動作を行うように許可を受けたＵＥがあるか確認し、少なくとも１個以上のＵＥが前記確認手続きに符合すると判断される場合、潜在的リモートＵＥにリレー探索手続きの開始をトリガーすることができる。この動作はリレー可能端末がないにもかかわらず潜在的リモートＵＥにリレー探索を開始するようにする不必要な動作を無くすためである。端末はｅＮＢからしきい値を受信する代わりにＰｒｏＳｅ Ｆｕｎｃｔｉｏｎから伝達を受けたしきい値を用いてリレー探索可否を判断することができる。
【００９５】
ｅＮＢが潜在的リモートＵＥがリレー探索を行うようにトリガーする方法は、第１にｄｅｄｉｃａｔｅｄ ＲＲＣメッセージを用いるか、第２にＳＩＢを介してブロードキャストする方法がある。第１にｄｅｄｉｃａｔｅｄ ＲＲＣメッセージを用いる場合、ｅＮＢは潜在的リモートＵＥにセル信号強度に対するしきい値を提供して潜在的リモートＵＥが行ったＣｅｌｌ信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はｅＮＢがブロードキャストするＳＩＢシグナリングの強度であるか、もしくはＤ２Ｄのためのサイドリンク(Ｓｉｄｅ ｌｉｎｋ) 信号の強度であってもよい。もしくはｅＮＢはｄｅｄｉｃａｔｅｄ ＲＲＣメッセージにリレー探索を実行を指示する識別子を含んで伝達することができ、これを受信した潜在的リモートＵＥはリレー探索を行う。
【００９６】
ｅＮＢがＳＩＢを介してリレー探索をトリガーする場合、ｅＮＢはセル信号強度に対するしきい値をＳＩＢ情報で提供して潜在的リモートＵＥが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はｅＮＢがブロードキャストするＳＩＢシグナリングの強度であるか、もしくはＤ２Ｄのためのサイドリンク信号の強度であってもよい。
【００９７】
図５は、本実施形態を行うことができる装置の内部構造を示したブロック図である。
【００９８】
具体的に、前記装置はリレーＵＥまたはリモートＵＥ１００、１１０、ｅＮＢ１２０、ＭＭＥ１３０、Ｓ−ＧＷまたはＰ−ＧＷ１４０及びＨＳＳ１５０となることができる。前記装置は送受信部５００、制御部５１０及び記憶部５２０から構成され、送受信部は各装置が他の装置と送受信する信号を送受信し、記憶部は各装置に必要な情報を記憶し、制御部は送受信部が信号を送受信するように制御し、記憶部が前記情報を記憶して出力するように制御する。
【００９９】
<第２実施形態>
【０１００】
本実施形態はＰｒｏＳｅ端末−ネットワークリレーを介してリレーサービスを提供する過程で必要なリレーサービスコード(ｒｅｌａｙ ｓｅｒｖｉｃｅ ｃｏｄｅ)関連パラメーターを提供する方法及びＰｒｏＳｅ端末−ネットワークリレーを介してＭＢＭＳ(Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ)トラフィックを伝達する場合、使用するようになるＬａｙｅｒ２ Ｇｒｏｕｐ ＩＤを割り当てるための方法を提案する。
【０１０１】
図６は、端末間の近接サービス(Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ ｓｅｒｖｉｃｅ)を介してＰｒｏＳｅ端末−ネットワークリレーを用いてサービスを受けるためのＰｒｏＳｅネットワーク構造を示した図面である。
【０１０２】
図６によれば、端末−ネットワークリレーＵＥ６１０は、ｅＮＢ６２０のカバレッジ内に位置し、セルラー網で提供するサービスをネットワークカバレッジ外に位置するリモート(ｒｅｍｏｔｅ)ＵＥに伝達するリレー役目を行う。また、ネットワークにはＰｒｏＳｅに対するサービス認可及びプロビジョニング(ｐｒｏｖｉｓｉｏｎｉｎｇ)を行うＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ(６６０)、呼出し処理関連動作を行うＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)(６５０)、加入者情報を記憶するＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ)、Ｓ−ＧＷ(Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ)、Ｐ−ＧＷ(ＰＤＮ−Ｇａｔｅｗａｙ)を含む各種ゲートウェー(６４０)などが含まれることができ、この時のネットワークはＥＰＳ(Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ)であってもよい。
【０１０３】
このために端末−ネットワークリレーＵＥ(以下リレーＵＥ)はＥＰＳネットワークを介してリレーであることを登録してリレーサービスを提供するための各種情報を受信したり、リモートＵＥにＩＰサービスを提供するためのＰＤＮ(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ)接続を生成するなどのリレーサービスのための準備を行う。以後、リレーサービスが用意した場合には探索(ｄｉｓｃｏｖｅｒｙ)方法によりリレーＵＥが直接自分がリレーであることを通知するための放送(ａｎｎｏｕｎｃｅｍｅｎｔ)メッセージを放送したり、隣近のリモートＵＥがリレーをサーチする時、送信する探索誘導(ｄｉｓｃｏｖｅｒｙ ｓｏｌｉｃｉｔａｔｉｏｎ)メッセージを受信して探索誘導メッセージにより該当する条件を満足する場合に探索応答(ｄｉｓｃｏｖｅｒｙ ｒｅｓｐｏｎｓｅ)メッセージを送信することによってリモートＵＥがリレーＵＥを発見するようになる。
【０１０４】
リモートＵＥは、発見されたリレーＵＥ中で望むリレーＵＥを選択して当該リレーＵＥとリモートＵＥ間に接続を設定(ｓｅｔｕｐ)し、前記接続を介してリモートＵＥはネットワークを通じるサービスを受けることができるようになる。
【０１０５】
本実施形態では前記リモートＵＥとリレーＵＥ間の探索過程で必要となる端末−ネットワークリレーが提供するサービスを通知するリレーサービスコード関連情報が提供される過程とリモートＵＥがリレーＵＥにリクエストしてＭＢＭＳトラフィックが送信される時、ＭＢＭＳトラフィックを送信するためのレイヤー２グループ(Ｌａｙｅｒ２ Ｇｒｏｕｐ)関連情報を獲得するための方案に対する方法及び装置を開始する。リレーサービスコードは端末−ネットワークリレーが提供するサービスを通知してリモートＵＥが端末−ネットワークリレーでサービスを受けることができるように許可されたユーザであるか否かを識別することができるようにするコードであり、レイヤー２グループＩＤはリモートＵＥにＭＢＭＳトラフィックを送信する時に用いられる通信グループを識別することができるようにするコードである。
【０１０６】
図７は、リレーサービスコード値を受信する手続きを示した図面である。
【０１０７】
図７によれば、ＰｒｏＳｅ端末はセルラネットワークのカバレッジ内に位置する時、サービス認可(Ｓｅｒｖｉｃｅ Ａｕｔｈｏｒｉｚａｔｉｏｎ)過程を介してＰｒｏＳｅサービスを受けるための手続きを行う。勿論、端末がセルラネットワークのカバレッジ外部に位置してＰｒｏＳｅ ＦｕｎｃｔｉｏｎなどのＥＰＳネットワークに接続が不可能な場合、端末内部にあるＵＳＩＭ(Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ)の設定値を介してＰｒｏＳｅサービスを用いることもできる。
【０１０８】
一般的なＰｒｏＳｅ端末中のリモートＵＥ７００はサービス認可過程のためにＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ(サービス認可リクエスト)メッセージをＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ７２０に送信し(ｓ７０１)、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎは必要によってＨＳＳ７４０からリモートＵＥ２００に対するＰｒｏＳｅサービスのための情報を段階７２１及び７４１を介して受信する。ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ７２０は自分が記憶していた値により、またはｓ２４１のメッセージを介してＨＳＳ７４０から受信した情報によりリモートＵＥにリレーを介してサービスを受ける場合にサービスを受けることができるリレーサービスコード値と当該リレーサービスコードを介してどんなサービスを受けることができるかに対する用例(ｕｓａｇｅ)(例えば、消防署員ネットワークサービス、警察官ネットワークサービスなど)に対する情報をＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ(サービス認可応答)メッセージ(ｓ７２２)を介して伝達するようになる。
【０１０９】
一方、リレーサービスを提供することができるか、リレーサービスを提供するリレー端末７１０はＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔメッセージ(ｓ７１１)を送信する時のリレーサービスを提供することができるか、リレーサービスを提供する端末であることを示すためのリレー指示(ｉｎｄｉｃａｔｉｏｎ、またはインジケータ)を含むこともできる。
【０１１０】
ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ７２０は当該端末がリレーサービスを行っても良い端末であるかを自分の情報(前記情報は端末コンテクストになることができる)に基づいて、またはＨＳＳ７４０に問い合わせて７２３及び７４２段階を介して確認することができる。ＨＳＳ７４０は７２３／７４２段階を介してサブスクリプション(ｓｕｂｓｃｒｉｐｔｉｏｎ)情報をＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ７２０に提供することができる。以後、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ７２０は自分が記憶していた値により、またはｓ７４２メッセージを介してＨＳＳ７４０から受信した情報により前記リレーＵＥ７１０がリレーサービスを行う時の提供することができるリレーサービスコード値と当該リレーサービスコードを介してどんなサービスを受けることができるかに対する用例(例えば、消防署員ネットワークサービス、警察官ネットワークサービスなど)に対する情報及び当該サービスのためにリレーＵＥ７１０がＰＤＮ接続をリクエストする時、使用すべきＡＰＮ(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ)情報、及び必要な場合には当該リレーサービスコードをいつまで用いることができるかに対する情報、すなわち、有効期間(ｌｉｆｅｔｉｍｅ、または有効期間で理解することができる)関連情報を含むリストをＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅメッセージ(ｓ７２４)を介してリレーＵＥ７１０へ伝達するようになる。
【０１１１】
前記リレーサービスコード値と用例関連情報と当該ＡＰＮ値を受信したリレーＵＥ７１０はＵＥ ｒｅｑｕｅｓｔｅｄ ＰＤＮ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒｅｑｕｅｓｔ(端末リクエストＰＤＮ接続リクエスト)(ｓ７１２)メッセージを前記受信したＡＰＮ情報を含んでＭＭＥ７３０へ送信し、リレーＵＥ７１０は適当なＰ−ＧＷを選択してＰＤＮ接続を設定する手続きを段階ｓ７３１及びｓ７１３のｄｅｆａｕｌｔ ＥＰＳ ｂｅａｒｅｒ ａｃｔｉｖａｔｉｏｎ(ＥＰＳベアラー活性化)過程を介して行う。
【０１１２】
ＰＤＮ接続が設定されてＥＰＳベアラーが活性化されると、この時からリレーＵＥ７１０はリレー機能を行うことができるようになるので段階ｓ７１４のようにリレーサービスコードなどの情報を含む放送メッセージを介して探索過程を行うことができる。
【０１１３】
一方、以後にリレーＵＥ７１０が自分のリレーサービスコード中で一部を使用しないか、変更をしようとする場合にはｓ２１１段階のようにＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔメッセージをＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ７２０に送信しながら前記メッセージに解除(ｒｅｌｅａｓｅ)することを望むリレーサービスコード値を含ませるか、有効期間(ｌｉｆｅｔｉｍｅ)に対する延長をリクエストするために前記メッセージにリレーサービスコードとともに延長リクエスト指示(ｉｎｄｉｃａｔｉｏｎ)を含むこともできる。これにより、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ７２０はｓ７２３及びｓ７４２段階のようにＨＳＳ７４０にリクエストして受信した情報または自分が持っている情報に基づいて変更された値をｓ７２４段階のようにＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅメッセージを介してリレーＵＥ７１０に伝達して変更された値に基づいてリレーサービスを提供するようにできる。
【０１１４】
また、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ７２０が当該リレーサービスコード値に対する情報を修正しようとする場合にはプッシュ(ｐｕｓｈ)メッセージ(例えば、ＳＭＳ)をリレーＵＥ７１０もしくはリモートＵＥ７００に送信してＰｒｏＳｅ Ｆｕｎｃｔｉｏｎに接続するようにして(例えば、Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ過程を行うようにできる)端末に新しく変更された値を同一の方法を介して伝達することもできる。
【０１１５】
図８は、リレーＵＥがレイヤー２グループＩＤを受信する方法を示した図面である。
【０１１６】
図８は、リモートＵＥ８００がリレーＵＥ８１０に接続した以後にＴＭＧＩ(Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ)モニタリング(ｍｏｎｉｔｏｒｉｎｇ)をリクエストしてＭＢＭＳトラフィック送信をリクエストした時、使用するようになるレイヤー２グループＩＤ(Ｌａｙｅｒ２(Ｌ２) Ｇｒｏｕｐ ＩＤ)を割り当てるための方法に対することで、本実施形態ではリレーＵＥ８１０がＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ８２０からサービス認可(Ｓｅｒｖｉｃｅ Ａｕｔｈｏｒｉｚａｔｉｏｎ)を受ける過程で当該値を受信する方法を説明する。
【０１１７】
図８によれば、リレーＵＥ８１０はＳｅｒｖｉｃｅ Ａｕｔｈｒｏｚｉａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを送信する８１１段階で自分がリレーサービスを提供することができるか、リレーサービスを提供する端末であることを示すためのリレー指示(ｉｎｄｉｃａｔｉｏｎ、インジケータでも理解することができる)を含むことができる。ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ８２０は当該端末がリレーサービスを行っても良い端末であるかを自分が記憶している情報またはＨＳＳ８３０にｓ８２３及びｓ８３２段階を介して問い合わせて獲得した情報を介して確認することができる。また、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ８２０は自分が記憶していた値または８３２段階のメッセージを介してＨＳＳ８３０から受信した値によって前記リレーＵＥ８２４がＭＢＭＳトラフィックをリレーする時、使用することができるレイヤー２グループＩＤのプール(ｐｏｏｌ)、すなわち、レイヤー２グループＩＤのリストもしくは範囲(ｒａｎｇｅ)値をＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅメッセージに含ませてリレーＵＥ８１０に提供するようになる(ｓ８２４)。この時、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ８２０はレイヤー２グループＩＤのプール使用に対する有効期間(ｌｉｆｅｔｉｍｅ)を前記メッセージに含ませることもできる。
【０１１８】
したがって、８０２段階のようにリモートＵＥ８００とリレーＵＥ８１０間の接続が設定されてリレーサービスを行う過程でリモートＵＥ８００がＴＭＧＩ ｍｏｎｉｔｏｒｉｎｇ ｒｅｑｕｅｓｔ(ＴＭＧＩモニタリングリクエスト)メッセージをリレーＵＥ８１０に送信して(ｓ８０３)リレーＵＥ８１０が前記リクエストに該当するＴＭＧＩに対するリレーサービスを承諾する場合、リレーＵＥ８１０は前記８２４段階で獲得したレイヤー２グループＩＤプールで一つのレイヤー２グループＩＤ値を選択して当該ＴＭＧＩ値に対するＭＢＭＳトラフィックを伝達するためのグループ値で決定し(ｓ８１２)、８１３段階のようにＴＭＧＩ ｍｏｎｉｔｏｒｉｎｇ ｒｅｓｐｏｎｓｅ(ＴＭＧＩモニタリング応答)メッセージに当該ＴＭＧＩに該当するレイヤー２グループＩＤ値を含ませてリモートＵＥ８００に伝達することができる。
【０１１９】
一方、以後にリレーＵＥ８１０が自分に割り当てられたレイヤー２グループＩＤの一部を使用しないか変更しようとする場合には８１１段階のようにリレーＵＥ８１０はＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔメッセージをＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ８２０に送信しながら前記メッセージに解除することを望むレイヤー２グループＩＤ値を含ませるか、特定レイヤー２グループＩＤの有効期間に対する延長をリクエストするためにレイヤー２グループＩＤとともに延長リクエスト指示を含ませることもできる。これにより、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ８２０は８２３及び８３２段階を用いてＨＳＳ８３０にリクエストして獲得したりもしくは自分が持っている情報に基づいて変更された値を８２４段階のようにＳｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅメッセージを介してリレーＵＥ８１０に伝達して変更された値でリレーサービスを提供するようにできる。
【０１２０】
また、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ８２０が当該レイヤー２グループＩＤプールに対する情報を修正しようとする場合にはプッシュ(ｐｕｓｈ)メッセージ(例えば、ＳＭＳ)をリレーＵＥ８１０に送信してＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ８２０に接続するようにして(例えば、Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ過程を行うようにできる)新たに変更された値を同一の方法を介して伝達することもできる。
【０１２１】
図９は、リレーＵＥがレイヤー２グループＩＤを受信する他の方法を示した図面である。
【０１２２】
図９は、リモートＵＥ９００がリレーＵＥ９１０に接続した以後にＴＭＧＩモニタリングをリクエストしてＭＢＭＳトラフィック送信をリクエストした時、使用するようになるレイヤー２グループＩＤを割り当てるための方法に対するので、本実施形態ではリレーＵＥ９１０がリモートＵＥ９００からＴＭＧＩモニタリングリクエストを受ける時、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ９２０から当該値を受信する方法を説明する。
【０１２３】
リレーＵＥ９１０が９０２段階のようにリモートＵＥ９００との接続後のリレーサービスを行う過程でリモートＵＥ９００がＴＭＧＩ ｍｏｎｉｔｏｒｉｎｇ ｒｅｑｕｅｓｔメッセージを送信して(ｓ９０３)、リレーＵＥ９１０が前記リクエストに該当するＴＭＧＩに対するリレーサービスを承諾する場合に、リレーＵＥ９１０はＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ９２０にＧｒｏｕｐ ＩＤ ａｓｓｉｇｎｍｅｎｔ ｒｅｑｕｅｓｔ(グループＩＤ割り当てリクエスト)メッセージを介して当該ＴＭＧＩに対するＭＢＭＢトラフィックを伝達するためのレイヤー２グループＩＤ値をリクエストする(ｓ９１２)。前記段階でＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ９２０はＨＳＳ９３０から９２１及び９３１段階を介して問い合わせて獲得した情報に基づいてサービスが可能なリレーＵＥであるか否かなどを判断する手続きを経ることができる。
【０１２４】
一方、前記グループＩＤ割り当てリクエストメッセージによってＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ９２０から９２２段階のＧｒｏｕｐ ＩＤ ａｓｓｉｇｎｍｅｎｔ ｒｅｓｐｏｎｓｅ(グループＩＤ割り当て応答)メッセージを介してレイヤー２グループＩＤが割り当てられたリレーＵＥ９１０は９１３段階のように前記グループＩＤ割り当て応答メッセージに含まれた当該ＴＭＧＩにあたるレイヤー２グループＩＤ値を含むＴＭＧＩ ｍｏｎｉｔｏｒｉｎｇ ｒｅｓｐｏｎｓｅメッセージをリモートＵＥ９００に伝達するようになる。
【０１２５】
一方、リレーＵＥ９１０がこれ以上レイヤー２グループＩＤを使用しない場合にはリレーＵＥ９１０はＧｒｏｕｐＩ Ｄｒｅｌｅａｓｅ ｒｅｑｕｅｓｔ(グループＩＤ解除リクエスト)メッセージをＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ９２０へ送信して当該レイヤー２グループＩＤに対する使用中断をリクエストし、その応答でＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ９２０がＧｒｏｕｐ ＩＤ ｒｅｌｅａｓｅ ａｃｋ(グループＩＤ解除受信確認)メッセージをリリースＵＥ９１０へ送信してリクエストが処理されたことを通知することができる。
【０１２６】
図１０は、本実施形態を行うことができる装置の内部構造を示したブロック図である。
【０１２７】
具体的に前記装置はリレーＵＥ、リモートＵＥ、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ及びＨＳＳなどになることができる。前記装置は、送受信部１０００、制御部１０１０及び記憶部１０２０から構成され、送受信部は各装置が相違する装置と送受信する信号を送受信し、記憶部は各装置に必要な情報を記憶し、制御部は送受信部が信号を送受信するように制御し、記憶部が前記情報を記憶して出力するように制御する。
【０１２８】
<第３実施形態>
【０１２９】
３ＧＰＰ３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)からＬＴＥ(Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)に基づいた災難安全網研究が現在活発に進行しつつある。そのなかで、Ｍｉｓｓｉｏｎ Ｃｒｉｔｉｃａｌ Ｐｕｓｈ ｔｏ Ｔａｌｋ(以下、ＭＣＰＴＴ)サービスは既存ウォーキートーキーサービスと類似にアプリケーション端でのグループ通信を定義する。特に、災難状況で基地局が機能を行うことができない場合にもグループ通信ができるようにするために３ＧＰＰでは端末間の直接通信を要求事項に含んでいる。グループ通信が正常に成り立つためには通信のためのセッションが予め生成されなければならない必要が(以下、Ｃａｌｌ Ｓｅｔｕｐ(呼出し設定)という)ある。メッセージ公知を介してセッションを生成する過程で音声、イメージもしくは映像などのメディアを送信するためのメディアのタイプ、コーデック、ポート番号などに対する情報がグループに属した端末間に共有される。呼出し設定が完了された以後、任意のユーザが発言をするためにはＰｕｓｈ Ｂｕｔｔｏｎ(プッシュボタン)を押してフロアを獲得しなければならない。フロアを獲得したユーザはグループメンバーに音声及び予め公知されたメディア類型(Ｍｅｄｉａ ｔｙｐｅ)に限ってメディアを送信することができる。
【０１３０】
ＭＣＰＴＴサービスを提供する従来方法で基地局及びネットワークに接続された(Ｏｎ−Ｎｅｔｗｏｒｋ)環境でＭＣＰＴＴサーバーとここに接続されたＭＣＰＴＴクライアント(ｃｌｉｅｎｔ、以下、端末、ユーザ装置などと混用可能)を用いる方法がある。Ｏｎ−Ｎｅｔｗｏｒｋ環境でＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ(ＳＩＰ)が呼出し設定に一般的に用いられる。セッションを生成しようとする端末がＳＩＰサーバーにＩＮＶＩＴＥ(招待)メッセージを送信すると、ＳＩＰサーバーは当該セッションと関連ある端末にＩＮＶＩＴＥメッセージを送信する。セッションに参加しようとする端末は２００ＯＫメッセージに応答する。保安のための通信秘密鍵交換及びメディアタイプ、コーデック、ポートに対する情報はＩＮＶＩＥメッセージに含まれ、以後の端末内のＭＣＰＴＴクライアントがＭＣＰＴＴ動作を行う。
【０１３１】
この時、Ｏｎ−Ｎｅｔｗｏｒｋ環境でフロア・コントロールに用いられる方法は、Ｂｉｎａｒｙ Ｆｌｏｏｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ(ＢＦＣＰ)とＭｅｄｉａ Ｂｕｒｓｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ(ＭＢＣＰ)で、これは中央に常に存在する(Ａｌｗａｙｓ Ｏｎ)サーバーでフロアリクエストを処理する方式である。サーバーに送信したＲｅｑｕｅｓｔ(リクエスト)に対するＧｒａｎｔ(許与)メッセージを受けた端末はフロアを有すると見られる。Ｏｎ−Ｎｅｔｗｏｒｋ状況では中央集中的な方式ですべての端末がすべてのリクエストをサーバーに送信した後にサーバーがこれを処理する方式で動作する。
【０１３２】
これと異なるようにＭＣＰＴＴサービスを基地局及びネットワークが機能を行うことができない(Ｏｆｆ−Ｎｅｔｗｏｒｋ)災難状況で用いるためには端末と端末間の直接通信を用いて音声を送受信するべきである。また、中央制御サーバーが存在しないので各端末は分散的に動作しなければならない。グループメンバー間の音声を送受信できようとすればＧｒｏｕｐＣａｌｌＳｅｔｕｐ(グループ呼出し設定)を介して呼出しで用いるメディア送信に係る設定情報、すなわち、メディアパラメーターとその値をメンバー間に互いに共有しなければならない。メディアパラメーターはＭｅｄｉａ ｔｙｐｅ(メディア類型)、ｃｏｄｅｃ(コーデック)、ｂａｎｄｗｉｄｔｈ(帯域幅)、Ｍｅｄｉａ送信のためのＭｕｌｔｉｃａｓｔ ｐｏｒｔ(マルチキャストポート)、Ｆｌｏｏｒ Ｃｏｎｔｒｏｌ(フロア・コントロール)メッセージ送信のためのプロトコル及び送信ｐｏｒｔ(ポート)、Ｍｅｄｉａ Ｅｎｃｒｙｐｔｉｏｎ(メディア暗号化)のためのＧｒｏｕｐＫｅｙ(グループ鍵)などが含まれる。メディアパラメーターと当該値を共有する方法は多様でれば良いが、代表的な２つの方法を後述する。  
【０１３３】
第１方法は、端末がグループ呼出しで用いるメディア送信に係る項目とその値をサービスを受けようとするすべての端末に予め設定した後、任意の端末がグループ呼出しを開始すると公知して予め設定されたＭｅｄｉａ ｔｙｐｅ、送信ｐｏｒｔ及びコーデックを用いてメンバー端末にメディアを送信する方法である。該方法はｒｅｓｐｏｎｓｅ(応答)を必ず要しないので早い設定が可能であると長所がある。しかし、グループ呼出しメディア送信設定情報が参加する端末間に予め定義されていなければならないので、生成されることができるグループ呼出しのリソースをサービス事業者が定めた設定を脱して用いることができなくなるという限界がある。
【０１３４】
第２方法は、グループ呼出しを開設する端末がグループ呼出しに用いるメディア送信関連項目を任意に選択してこれを他のメンバー端末に公知する方法である。ここでＧｒｏｕｐＣａｌｌＡｎｎｏｕｎｃｅｍｅｎｔ(グループ呼出し公知メッセージ、グループ呼出しメッセージと混用されることができる)を送信する理由はグループ通信に参加する端末にとって音声のようなメディアを受信することができるように準備するようにすることである。
【０１３５】
図１１は、グループ呼出しを開設する端末がグループ呼出しに用いるメディア送信関連項目を任意に選択してこれを他のメンバー端末に公知する方法を示した図面である。
【０１３６】
図１１によれば、グループ呼出しを開始するＭＣＰＴＴクライアント１(１１００)はグループ呼出しで用いるメディアに対する複数のパラメーター値を決定し、これをグループ呼出し公知メッセージに含ませて近くのＭＣＰＴＴクライアント１１１０、１１２０に送信する(ｓ１１００)。前記公知メッセージを受信したＭＣＰＴＴクライアント１１１０、１１２０は送信されたメディアパラメーターを設定してグループコルネ伝達するメディアを受信するために準備し(ｓ１１１０)、応答メッセージを生成してグループ内の他のＭＣＰＴＴクライアントに送信することによって自分がグループに参加したことを通知する(ｓ１１２０)。前記応答メッセージは参加可否を通知するメッセージであるのでメディアパラメーター情報を含まない。また、応答メッセージはすべてのグループ呼出し公知メッセージを受信する度に毎度送信されることができるが、ネットワークリソースを効果的に用いるためにＭＣＰＴＴクライアントは同様のＧｒｏｕｐＩＤに対する公知メッセージに対しては最初１回に限って応答メッセージを送信することもできる。グループ呼出しに参加するすべての参加者らはグループ呼出し公知メッセージと応答メッセージによってグループに参加する参加者らを確認することができる。
【０１３７】
前記のような方法を用いてＭＣＰＴＴクライアントはＭＣＰＴＴ Ｏｆｆ−Ｎｅｔｗｏｒｋグループ呼出し手続きを介してメディア(例えば、音声)を送受信することができるように準備する。
【０１３８】
ところで最初グループ呼出し公知メッセージ送信時、メッセージ伝達範囲内になかったがグループ呼出し範囲内に入るか、公知メッセージ送信以後にＭＣＰＴＴクライアントを活性化させた場合、当該ＭＣＰＴＴクライアントを既存のグループ呼出しに参加させる方法が必要である。
【０１３９】
本実施形態によれば、グループ呼出しサービス範囲に遅くジョインしたＭＣＰＴＴクライアントにグループ呼出しで用いているメディアパラメーターを伝達することによって、当該ＭＣＰＴＴクライアントが伝達されたメディアパラメーターを用いてメディア送受信のための設定を行うことによって既存のグループ呼出しに新しいＭＣＰＴＴクライアントを参加させることができる。
【０１４０】
本実施形態は直接通信を通じるＰｕｓｈ ｔｏ Ｔａｌｋ(ＰＴＴ)ソリューションで予め生成されたグループ呼出しに新しいＭＣＰＴＴクライアントを参加させる方法を提案しており、特にグループ呼出しを直ちに生成するためにＧｒｏｕｐ Ａｎｎｏｕｎｃｅｍｅｎｔメッセージを送信することによって予め生成された同一ＩＤのグループ呼出しに能動的に参加する場合と、周期的に送信されるＧｒｏｕｐ Ａｎｎｏｕｎｃｅｍｅｎｔメッセージを受信することでグループ呼出しに参加する受動的参加の場合、そし、前記２つの場合のいずれにも該当する場合を含む。
【０１４１】
図１２は、端末間の直接通信基盤のＭＣＰＴＴシステムを示した図面である。
【０１４２】
図１２によれば、端末間の直接通信基盤のＭＣＰＴＴシステムにはサーバーが存在しないことが特徴で、それぞれのＭＣＰＴＴ端末１(１２００)、端末２(１２１０)及び端末３(１２２０)は自分の直接通信範囲にある他の端末と通信可能である。
【０１４３】
図１３ａは、ＭＣＰＴＴ端末の構造を示したブロック図である。
【０１４４】
図１３ａによれば、ＭＣＰＴＴ端末はＭＣＰＴＴ発言のためのプッシュボタン１３００とボリュームＵｐ／Ｄｏｗｎボタン１３０２、グループ情報を表示する画面(ディスプレー、１３０４)、音声入／出力のためのスピーカー(図示せず)、マイク(図示せず)などの周辺装置を含み、搭載されたＭＣＰＴＴシステムが周辺装置とモデム１３２０を用いて端末間ＭＣＰＴＴ動作を介してサービスを行う。ＭＣＰＴＴ端末は、ＰＴＴ ＵＮＩＴ(ＰＴＴ部)１３１０を含み、前記ＰＴＴ部グループ呼出し生成のためのＣａｌｌ Ｓｅｔｕｐ ＵＮＩＴ(呼出し設定部)１３１２、フロア・コントロールのためのＦｌｏｏｒ Ｃｏｎｔｒｏｌ ＵＮＩＴ(フロア・コントロール部)１３１４、音声送受信のためのＭｅｄｉａＴｘ／Ｒｘ ＵＮＩＴ(メディア送受信部)１３１６から構成されて直接通信のためにこれをサポートするモデム１３２０を用いる。図示しないが、端末の間通信をサポートするためのネットワークレイヤー(ｌａｙｅｒ)を担当するＰｒｏＳｅ(Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ ｓｅｒｖｉｃｅ)ＵＮＩＴ(ＰｒｏＳｅ部)を含むこともできる。
【０１４５】
図１３ｂは、ＭＣＰＴＴ端末の他の構造を示したブロック図である。
【０１４６】
図１３ｂによれば、ＭＣＰＴＴ端末は送受信部１３５０、制御部１３６０及び記憶部１３０から構成されることができ、送受信部は他の端末とのメッセージを送受信し、記憶部は前記メッセージに含まれたパラメーターなどの情報を記憶することができ、制御部は前記送受信部と記憶部を本実施形態の内容によって動作するように制御することができる。また、図１３ａのＰＴＴ部で行われる動作は図１３ｂの制御部によって行われることができる。
【０１４７】
本実施形態はＭＣＰＴＴ端末の呼出し設定部を用いてグループ呼出し公知メッセージ及び応答メッセージを生成してＭＣＰＴＴ端末間のメッセージを送受信することによって予め生成されたグループ呼出しに新しいＭＣＰＴＴ端末を参加させる方法を提供する。この時、グループ呼出しはグループＩＤで区分してグループ呼出し別で用いるメディアパラメーターは最初グループ呼出しを開始するＭＣＰＴＴクライアントによって決定されるので、グループ呼出し別でメディアパラメーターは違うことができるが、同じパラメーターが用いられることもできる。
【０１４８】
予め生成されたグループ呼出しに新しいＭＣＰＴＴクライアントを参加させる方法で、新しいＭＣＰＴＴクライアントが能動的にグループ呼出し公知メッセージを送信することによって予め生成されたグループ呼出しに参加する方法と、周期的に送信されるグループ呼出し公知メッセージを受信することによって参加するようになる受動的方法があり得る。
【０１４９】
図１４は、新しいＭＣＰＴＴクライアントが周期的に送信されるグループ呼出し公知メッセージを受信してグループ呼出しに参加する方法を示した図面である。
【０１５０】
図１４によれば、ＭＣＰＴＴクライアント１(１４００)、２(１４１０)、３(１４２０)間には前述した方法でグループ呼出しこの予め生成されている(ｓ１４００)。グループ呼出しに参加したＭＣＰＴＴクライアントは呼出しが生成された後、新たに現われたＭＣＰＴＴクライアントがメディアパラメーター情報を設定し、このグループ呼出しに参加するように周期的に現在用いているメディアパラメーター情報を公知する(ｓ１４１０)。新たに現われたＭＣＰＴＴクライアント４(１４３０)(ｓ１４２０)は、一定時間の間に待って予め生成されたグループ呼出しメンバークライアント(図１４ではＭＣＰＴＴクライアント２(１４１０))が異なるクライアントに送信するグループ呼出し公知メッセージを受信し(ｓ１４３０)、当該公知メッセージに含まれたメディアパラメーターの内容どおりグループ呼出しに用いるメディアパラメーターを設定してメディアを送受信することができるように準備して(ｓ１４４０)自分がグループ呼出しに参加したことを通知する応答メッセージをグループ内他のクライアントに送信する(ｓ１４５０)。この応答メッセージにはメディアパラメーターが含まれない。前記応答メッセージを介してＭＣＰＴＴクライアント１(１４００)、２(１４１０)、３(１４２０)はＭＣＰＴＴクライアントがグループ呼出しに参加したことを認知することができる。以後にもグループ呼出しメンバーは周期的にグループ呼出し公知メッセージを送信する。
【０１５１】
この時、グループ呼出し公知メッセージを送信する周期はＲＦＣ２９７４Ｓｅｓｓｉｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ(ＳＡＰ)を用いる場合、３００秒とグループ呼出し公知メッセージを送信する回数＊公知メッセージ大きさを設定された帯域幅(ｂｉｔ／ｓｅｃ)で分けて求めた値のうちの大きい値で決定することができる。ＳＡＰでサービス提供時に別に設定されていない場合、前記帯域幅は４０００ｂｉｔｓ／ｓｅｃが基本値で設定される。例えば、グループ呼出し公知メッセージを送信する周期が３００秒と仮定し、偶然にＭＣＰＴＴクライアントが公知メッセージ送信直後にグループに入ると、この場合２９９秒を待つとグループ呼出しに参加することができる場合が生ずる。これはサービスのユーザ経験を低下させて３ＧＰＰのＭＣＰＴＴＱｏＳ要求事項を満足させることができる事ができない。このような状況を防止するために能動的に予め生成されたグループ呼出しに参加する方法を提案しようとする。
【０１５２】
図１５は、新しいＭＣＰＴＴクライアントが能動的にグループ呼出し公知メッセージを送信することによって予め生成されたグループ呼出しに参加する方法を示した図面である。
【０１５３】
図１５によれば、この場合にもＭＣＰＴＴクライアント１(１５００)、２(１５１０)、３(１５２０)間にはグループ呼出しが予め生成されている(ｓ１５００)。また、予め生成されたグループ内で周期的にグループ呼出し公知メッセージが送信されることができる(ｓ１５１０)。ＭＣＰＴＴクライアント４(１５３０)は、活性化された後(ｓ１５２０)、グループ呼出し公知メッセージ受信を待ませず直接グループ呼出しを生成するために自分がグループ呼出しを生成しようとするグループを選択してメディアパラメーターを選定してメディアパラメーターを含ませたグループ呼出し公知メッセージを生成して他のクライアントにマルチキャスト方式で送信する(ｓ１５３０)。前記公知メッセージを受信したＭＣＰＴＴクライアント１(１５００)、２(１５１０)、３(１５２０)はメッセージに含まれたグループＩＤが予め生成されたグループ呼出しのグループＩＤと比べてもＩＤが同一であれば、ＭＣＰＴＴクライアント４(１５３０)が新しくグループ呼出しに参加するということを認知する。また、ＭＣＰＴＴクライアント４(１５３０)が送信した公知メッセージに含まれたメディアパラメーターを用いてグループ呼出しを設定せず代わりに応答メッセージに予め生成されたグループ呼出しで用いるメディアパラメーターを含んで応答メッセージを送信する(ｓ１５４０)。
【０１５４】
この時、すべてのＭＣＰＴＴクライアントが応答メッセージを送信する必要がないので各ＭＣＰＴＴクライアントはＭＣＰＴＴクライアント４(１５３０)から公知メッセージを受信すると [０、最大値]中一つの数字を任意的に選択した後、その数字に該当する送信スロット(ｓｌｏｔ)ほど待機した後、応答メッセージを送信する。前記最大値は予め決定されることができ、もしくは呼出しグループ生成時に決定されることができる。各ＭＣＰＴＴクライアントが応答メッセージを送信する前に他のＭＣＰＴＴクライアント(図１５ではＭＣＰＴＴクライアント２(１５１０))が送信した応答メッセージを受信すると、前記ＭＣＰＴＴクライアントを除いた他のＭＣＰＴＴクライアント(図１５ではＭＣＰＴＴクライアント１(１５００)、３(１５２０))は応答メッセージを送信する必要がない。
【０１５５】
ＭＣＰＴＴクライアント２(１５１０)が送信した応答メッセージを受信したＭＣＰＴＴクライアント４(１５３０)はグループＩＤ及び応答メッセージに含まれたメディアパラメーターを介して生成しようとするグループ呼出しが既に存在していることを判断し、自分が設定したメディアパラメーターの値を応答メッセージに含まれたメディアパラメーターの値に変更して(ｓ１５５０) 当該グループ呼出しから送信されるメディア(音声)を受信する。以後、周期的なグループ呼出し公知メッセージが送信されることができる(ｓ１５６０)。
【０１５６】
予め生成されたグループ呼出しカバレッジに２つのＭＣＰＴＴクライアントが新たに現われ、一方のクライアントは能動的にグループ呼出し公知メッセージを送信し、他方の一つのクライアントは受動的にグループ呼出し公知メッセージを受信してグループ呼出しに参加する場合、後者の受動的なＭＣＰＴＴクライアントは公知メッセージと応答メッセージに含まれて送信されたメディアパラメーターが異なり、同一グループＩＤの呼出しにもグループ呼出しに参加することができない場合が生ずる。
【０１５７】
このような場合を解決するために予め生成されたグループ呼出しで用いられるメディアパラメーターを送信する応答メッセージを受信する場合、新たに現われたＭＣＰＴＴクライアントは予め設定されたメディアパラメーター値を応答メッセージに含まれたメディアパラメーターに変更して設定することができる。
【０１５８】
図１６は、能動的なＭＣＰＴＴクライアントと受動的なＭＣＰＴＴクライアントが共存する場合、２つのＭＣＰＴＴクライアントをいずれもグループ呼出しに参加させる方法を示した図面である。
【０１５９】
図１６によれば、ＭＣＰＴＴクライアント１(１６００)、２(１６１０)は予めグループ呼出しを生成して通信をしており(ｓ１６００)、周期的なグループ呼出し公知メッセージを送受信している(ｓ１６１０)。この時、ＭＣＰＴＴクライアント３(１６２０)、４(１６３０)が新たに現われた状況でＭＣＰＴＴクライアント３(１６２０)がグループ呼出しを生成するためにＭＣＰＴＴクライアント１(１６００)、２(１６１０)が予め生成したグループ呼出しのグループＩＤを含むグループ呼出し公知メッセージを送信する(ｓ１６３０)。これを受信したＭＣＰＴＴクライアント４(１６３０)はＭＣＰＴＴクライアント３(１６２０)が送信したグループ呼出し公知メッセージに含まれたメディアパラメーターに基づいて自分のパラメーターを設定し、グループ呼出しに参加するという応答メッセージを送信する(ｓ１６４０)。
【０１６０】
この時、ＭＣＰＴＴクライアント１(１６００)、２(１６１０)はＭＣＰＴＴクライアント３(１６２０)が送信したグループ呼出し公知メッセージを受信し、公知メッセージに含まれたグループＩＤに該当するグループ呼出しが生成されていることを判断し、応答メッセージに予め生成されたグループ呼出しに用いているメディアパラメーター情報を含んで送信する(ｓ１６５０)。図１６の場合、ＭＣＰＴＴクライアント２(１６１０)が前記応答メッセージを送信する。この応答メッセージを受信したＭＣＰＴＴクライアント３(１６２０)、４(１６３０)は予め生成されたグループ呼出しが存在することを認知して予め設定されていたメディアパラメーターを受信した応答メッセージに含まれたメディアパラメーターの値に変更設定してメディア送受信を行うようにする(ｓ１６６０)。以後、周期的なグループ呼出し公知メッセージが送受信されることができる(ｓ１６７０)。
【０１６１】
前記のような手続きでＭＣＰＴＴクライアント４(１６３０)が応答メッセージを送信する前にＭＣＰＴＴクライアント１(１６００)もしくは２(１６１０)がＭＣＰＴＴクライアント３(１６２０)の公知メッセージに対する応答メッセージ(予め生成されたグループ呼出しで用いるメディアパラメーター情報を含み)を送信することができる。ＭＣＰＴＴクライアント４(１６３０)は前記応答メッセージを受信し、これに対する応答メッセージを送信することもできる。予め生成されたグループ呼出しに属したＭＣＰＴＴクライアントはＭＣＰＴＴクライアント３(１６２０)が送信したグループ呼出し公知メッセージとＭＣＰＴＴクライアント４(１６３０)が送信した応答メッセージによって二つのＭＣＰＴＴクライアントがグループ呼出しに参加したことを分かる。
【０１６２】
前記ＭＣＰＴＴグループ呼出し設定及びグループ呼出しに参加する方案を具現する方法でＳＡＰを活用することができる。
【０１６３】
図１７は、ＳＡＰのＰａｃｋｅｔ Ｆｏｒｍａｔ(パケットフォーマット)を示した図面である。
【０１６４】
図１７のそれぞれのＨｅａｄｅｒ(ヘッダー)の意味と使用方法に対しては予め公知された技術として本発明で詳述しない。ただ、本発明ではグループ呼出し公知メッセージと応答メッセージを具現するためにパケットフォーマットのＲビット１７００とＴビット１７１０を活用して区分しようとする。ＲビットはＲＦＣ上で追後使用のために予約されたビットでＴビットはＳＡＰのメッセージ類型を定義するｂｉｔである。ＳＡＰではＴビットの値が０であれば公知メッセージで１であればセッションを終了する用途として使用している。したがって、以下の表１のように応答メッセージを特定するためにＲビットの値を１で設定してＴビットを０で設定して用いることができる。
【０１６５】
【表１】
0006791885.tif 000002
【０１６６】
本実施形態を適用することによって端末間の直接通信で予め生成されたグループ呼出しにメンバーではないＭＣＰＴＴクライアントを参加させることができる。
【０１６７】
<第４実施形態>
【０１６８】
公衆安全網(Ｐｕｂｌｉｃ Ｓａｆｅｔｙ−ＬＴＥ：ＰＳ−ＬＴＥ)はＭＣＰＴＴ(Ｍｉｓｓｉｏｎ Ｃｒｉｔｉｃａｌ Ｐｕｓｈ ｔｏ Ｔａｌｋ ｏｖｅｒ ＬＴＥ)技術を用いてユーザに災難状況で公衆安全のための通信ができるサービスを提供する。
【０１６９】
したがって、緊急発生時の端末は他の端末に自分が緊急を通知すべきである。前記ＭＣＰＴＴ技術を用いてＭＣＰＴＴユーザは緊急に対する救護に役に立つことができる。
【０１７０】
本実施形態が達成しようとする技術的課題は、無線通信システムでサービス提供方法及び装置を提供するものである。
【０１７１】
本実施形態が達成しようとする技術的課題は、無線通信システムで優先順位サービス提供方法及び装置を提供するものである。
【０１７２】
本実施形態が達成しようとする技術的課題は、ＭＣＰＴＴシステムでユーザ、グループ及びサービスに対する優先順位を設定する方法及び手続きを提供するものである。また、本発明が達成しようとする技術的課題は、優先順位基盤で端末及びサーバーでサービスを制御する方法に必要な手続き及び装置と、そのシステムを提供するものである。また、本発明が達成しようとする技術的課題は、優先順位基盤のサービス提供のためのメッセージフローを提供するものである。
【０１７３】
本実施形態が達成しようとする技術的課題は、緊急で端末が他の端末に緊急であることを通知するメッセージ送信と呼出しを設定する方法及び装置を提供するものである。
【０１７４】
本実施形態によれば、無線通信システムで優先順位サービス提供方法及び装置を提供することができる。
【０１７５】
本実施形態によれば、優先順位基盤のサービス提供及び処理が可能で、このような優先順位サービス提供を介してＱｏＳ(ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ)が保障されたサービスを提供することができる。
【０１７６】
また、本実施形態によれば、緊急で端末が他の端末に緊急を通知するメッセージ送信と呼出しを設定する方法及び装置を提供することができる。また、緊急が発生する場合、端末が収集したメディアを管理者に送信することによって、緊急に対する救護に役に立つことができる。
【０１７７】
また、本実施形態を具体的に説明するにあたり、３ＧＰＰが規格を定めた無線ＩＭＳ及びＵＥ(Ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ)とＩＥＴＦのＳＩＰ(Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ)を主な対象とするが、本実施形態の主な要旨は類似の技術的背景を有するそのほかの通信システムにもその範囲を大きく逸脱せず範囲で僅かの変形で適用可能であり、これは本実施形態の技術分野で熟練された技術的知識を有する者の判断で可能であろう。
【０１７８】
本実施形態は、ＭＣＰＴＴユーザ、グループ及びサービスを対象で優先順位を設定することを特徴とし、その設定された優先順位を基づいた端末及びサーバー動作過程を本実施形態の特徴とする。
【０１７９】
また、本実施形態によってＭＣＰＴＴユーザとＭＣＰＴＴサーバー間に優先順位基盤サービス提供のためのメッセージフロー過程を本実施形態の特徴とする。
【０１８０】
災難安全網(Ｐｕｂｌｉｃ Ｓａｆｅｔｙ ＬＴＥ、ＰＳ−ＬＴＥ)はＭＣＰＴＴ(Ｍｉｓｓｉｏｎ Ｃｒｉｔｉｃａｌ Ｐｕｓｈ Ｔｏ Ｔａｌｋ ｏｖｅｒＬＴＥ)技術を用いてユーザに災難状況もしくは公衆安全のための通信ができるサービスを提供する。ＭＣＰＴＴは３ＧＰＰで定義した技術中の一つであり、ユーザ間のグループ通信、一対一通信、緊急通貨、災難通知、及び周辺音聴取などを含む機能を提供する。
【０１８１】
ＭＣＰＴＴサービスは端末とＥＰＳ(Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ)、ＳＩＰ(Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ)Ｃｏｒｅ、及びＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒから構成される。ＥＰＳはＬＴＥ網を意味することができ、ＳＩＰ ＣｏｒｅはＳＩＰを用いるネットワーク装置でＩＭＳを意味することができる。ＭＣＰＴＴサービスは多様な構造で配置されることができる。ＭＣＰＴＴ事業者がＥＰＳとＳＩＰ Ｃｏｒｅ、そしてＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒまで運営することができ、ＭＣＰＴＴ事業者がＳＩＰ ＣｏｒｅとＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒを運営して他の事業者のＥＰＳと連動してサービスを提供することができる。また、ＭＣＰＴＴ事業者がＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒだけ運営して他の事業者のＥＰＳとＳＩＰ Ｃｏｒｅと連動してサービスを提供することができる。
【０１８２】
ＭＣＰＴＴサービスは大きくグループ管理、セッション制御、メディア制御で機能的要素を区分することができる。グループ管理は、ユーザが属したグループに対する加入情報、グループの優先順位、グループ内許容された役目、グループ内用いることができる呼出し類型(Ｃａｌｌ ｔｙｐｅ)などを管理する。セッション制御はユーザのＭＣＰＴＴサービスに登録及びグループ通話を開始もしくは変更、又は終了するなどの通話セッションのための信号を制御する。ＭＣＰＴＴユーザが送信するセッション管理信号はいずれもＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒを介して制御／管理される。
【０１８３】
メディア制御はユーザがＭＣＰＴＴサービスが提供するグループ通話、一対一通話、もしくは災難通知などを用いるために送信するメディアに対する送／受信許可リソース制御を担当する。ＭＣＰＴＴユーザが送信するすべてのメディア情報はＭＣＰＴＴサービスが提供するメディアゲートウェー(Ｍｅｄｉａ ｇａｔｅｗａｙ)を介して他のユーザに伝達する。グループ管理のためのグループ管理サーバー(Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ)はＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒとともに位置することができ、機能によって論理的に区別される。メディア制御のためのメディアゲートウェー(Ｍｅｄｉａ Ｇａｔｅｗａｙ)はＳＩＰ Ｃｏｒｅを経ず端末とＥＰＳ、及びＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒに接続されることができる。メディアゲートウェー(Ｍｅｄｉａ Ｇａｔｅｗａｙ)はユーザの送／受信権限を制御するようになり、これをフロア・コントロール(Ｆｌｏｏｒ ｃｏｎｔｒｏｌ)と称することができる。Ｍｅｄｉａ ＧａｔｅｗａｙはＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒとともに位置することができ、論理的に区別された機能を示す。
【０１８４】
ＭＣＰＴＴサービスは大きくグループ通話と一対一通話、及び緊急通知で区分することができる。グループ通話は公衆安全のためにグループ通信が必要な一般グループ通話、緊急／応急状況が発生した場合に対して最優先の順位で通信を提供することができる緊急呼出し(ＥｍｅｒｇｅｎｃｙＣａｌｌ)、及び緊急呼出し(Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ)より優先順位は低いが切迫した緊急／応急状況に備えてグループ通信ができる緊急危険呼出し(Ｉｍｍｉｎｅｎｔ Ｐｅｒｉｌ Ｃａｌｌ)をサポートすることができる。一対一通話は一般通話と緊急呼出し(Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ)、そして相手の周辺音を聴取することができる周辺聴取(Ａｍｂｉｅｎｔ Ｌｉｓｔｅｎｉｎｇ)機能をサポートすることができる。
【０１８５】
ＭＣＰＴＴユーザは多くのカテゴリーで分けられることができる。(公認されない)一般ＭＣＰＴＴユーザ、公認されたＭＣＰＴＴユーザ、公認されたＭＣＰＴＴサービス提供者がそれである。
【０１８６】
ＭＣＰＴＴユーザはいくつかのＭＣＰＴＴサービス提供者からサービスを受けることができる。ＭＣＰＴＴユーザの主要ＭＣＰＴＴサービス提供者以外にパートナーシップ(Ｐａｒｔｎｅｒｓｈｉｐ)を持っているＭＣＰＴＴサービス提供者と連動してパートナーシップ(Ｐａｒｔｎｅｒｓｈｉｐ)のＭＣＰＴＴユーザとグループ通信及び一対一通信を行うことができる。
【０１８７】
ＭＣＰＴＴ端末はＭＣＰＴＴサービスが提供されるための基本的な情報をＭＣＰＴＴサービス提供者から受信することができる。ユーザ識別子、グループ識別子、グループ内の役目及びグループ内の許可されたＣａｌｌ ｔｙｐｅ、一対一通話可能可否、配置Ｔｙｐｅ、ＭＣＰＴＴ ｓｅｒｖｅｒに報告しなければならないＲｅｐｏｒｔ情報、及び多様な配置ＴｙｐｅをサポートするためのＥＰＳ、ＳＩＰ Ｃｏｒｅ、ＭＣＰＴＴ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒに接続するための情報が受信されることができる。
【０１８８】
ＭＣＰＴＴサービス提供者は優先順位によってサービスを提供及び制御することができる。ＭＣＰＴＴ端末はサービス優先順位によってサービスを制御することができる。
【０１８９】
現在の通信システムで提供するｓｕｂｓｃｒｉｐｔｉｏｎ、ｆｉｘｅｄ ｄｉｆｆｅｒｅｎｔｉａｔｉｏｎ、制限的な事業者提供サービス基盤のＰｒｉｏｒｉｔｙ及びＱｏＳ ＬｅｖｅｌではＭＣＰＴＴ Ｐｒｉｏｒｉｔｙ ｓｅｒｖｉｃｅ要求事項を満足させることができない。したがって、細分化されたレベルのＰｒｉｏｒｉｔｙ設定及び処理方法が必要である。
【０１９０】
以下の実施形態はＭＣＰＴＴシステムでユーザ、グループ及びサービスに対する優先順位を設定する方法及び手続きを提案する。また、優先順位基盤で端末及びサーバーでサービスを制御する方法に必要な手続き及び装置と、そのシステムを提案する。また、及び優先順位基盤のサービス提供のためのメッセージフローを提案する。
【０１９１】
優先順位を設定する対象は３つである。ユーザ別の優先順位が決まることができ、グループ別優先順位が決まることができ、サービス別の優先順位が決まることができる。
【０１９２】
当該優先順位はＭＣＰＴＴサービスを提供するサービス提供者または公認されたＭＣＰＴＴユーザが設定することができる。
【０１９３】
設定された優先順位値はＭＣＰＴＴユーザとＭＣＰＴＴサーバー間に共有されることができる。共有される方法はサービスが開始される前に予め共有されることもでき、サービスリクエストとともに共有されることができる。
【０１９４】
設定された優先順位値を用いる個体はＭＣＰＴＴサーバー、ＭＣＰＴＴユーザ及びＳＩＰ Ｃｏｒｅがある。
【０１９５】
優先順位使用は一つ以上の優先順位値の組合で用いられることができる。ＭＣＰＴＴサーバーはＭＣＰＴＴユーザにサービスリクエストがある時、サービスリクエストを処理するのに優先順位値を用いることができる。また、ＭＣＰＴＴユーザが現在進行中のサービスを管理するのに用いることができる。また、フロア・コントロール(ｆｌｏｏｒ ｃｏｎｔｒｏｌ)に用いられることができる。ＭＣＰＴＴユーザはサービスリクエストがある時、サービスリクエストを処理するのに優先順位値を用いることができる。また、現在進行中のサービスを管理するのに用いることができる。ＳＩＰ Ｃｏｒｅはネットワークリソース管理のために優先順位値を用いることができる。
【０１９６】
本発明の実施形態において優先順位によるサービス処理方法の特徴は次の通りである。既存通信システムで適用されない優先順位値基盤のサービス処理が変わる。また、サービスに必要なメディア種類(オーディオ、ビデオ、テキストなど)によってサービス処理が変わる。メディア種類は追加の分類体系を有することができる。本発明の実施形態では同時にサービスが可能なメディア(メディアタイプＡ)と同時にサービスが不可能なメディア(メディアタイプＢ)で分けることができる。例えば、チャットの場合、同時にサービスが可能なので(メディアタイプＡ)、優先順位が高いサービスと優先順位の低いサービスが同時にサービスが可能である。一方、同時にサービスが不可能なオーディオの場合(メディアタイプＢ)、優先順位が高いサービスのオーディオを先ず聞かせる。また、ユーザが多くの端末を保有する時、優先順位によってどの端末でサービスを提供するか変わる。また、ネットワークがサポートすることができるユーザ数以上のユーザが一つのネットワークにある時、ＱｏＳ保障のために優先順位が高いユーザに先ずサービスを提供することができる。
【０１９７】
図１８は、本実施形態による優先順位基盤サービス処理動作を示した図面である。
【０１９８】
図１８を参照すれば、１８０５動作でＭＣＰＴＴ端末はサービスリクエストを受信することができる。前記サービスリクエストは新しい(新規)サービスリクエストであってもよい。
【０１９９】
１８１０動作でＭＣＰＴＴ端末は現在進行中のサービスがあるか判断することができる。サービスはＭＣＰＴＴサービスであってもよい。現在進行中のサービスがある場合、１８１５動作へ進行し、現在進行中のサービスがない場合、１８２０動作へ進行する。
【０２００】
１８２０動作でＭＣＰＴＴ端末は１８０５動作でリクエストされたサービスを処理することができる。  
【０２０１】
１８１５動作でＭＣＰＴＴ端末は現在進行中のサービスと新しいサービスリクエストに対応するサービス(新規サービス)が同時に提供可能なサービスであるか判断することができる。現在進行中のサービスと新しいサービスリクエストに対応するサービスが同時に提供可能な場合、１８２３動作へ進行し、同時に提供可能ではない場合、１８３０動作へ進行する。一方、１８２３動作は省略可能で、１８２３動作が省略される場合、１８２５動作へ進行することができる。例えば、各サービスが提供するメディアがオーディオの場合、オーディオサービスは同時に提供することができない。例えば、各サービスが提供するメディアがテキストまたはイメージの場合、両サービスは同時に提供されることもできる。一つのサービスはオーディオを提供して一つのサービスはテキストを提供する場合、端末の性能によって各サービスのメディアは同時に提供されることもできる。このように、各サービスが同時に提供可能であるか否かはサービスの類型及び端末の性能により決定されることができる。
【０２０２】
１８２３動作でＭＣＰＴＴ端末は現在進行中のサービスと新規サービスの優先順位を判断することができる。現在進行中のサービスが提供するメディアと新規サービスが提供するメディアの優先順位を判断することもできる。判断された優先順位は１８２５動作で用いられることができる。
【０２０３】
１８２５動作でＭＣＰＴＴ端末は現在進行中のサービスと新しいサービスリクエストに対応するサービス(新規サービス)を同時に提供する。サービスを同時に提供する時、１８２３動作で判断した優先順位情報を用いることができる。同時に提供可能なサービスも優先順位によってサービス提供に加重値を付与することができる。例えば、テキストを提供する場合、優先順位がより高いサービスのテキストをＭＣＰＴＴ端末の上端に表示し、優先順位がより低いサービスのテキストをＭＣＰＴＴ端末の下端に表示するように制御することができる。また、先ず順位がより高いサービスに対してテキストまたはイメージ大きさに加重値を適用することができる。また、サービスを提供する時間に加重値を適用することもできる。
【０２０４】
一方、１８２５動作で必ず現在進行中のサービスと新規サービスを同時に提供しなければならないことではない。例えば、同時に両サービスが提供可能な場合と言ってもＭＣＰＴＴ端末は一つのサービスを優先的に提供した後、他のサービスを提供することができる。また、この場合、１８２３動作で判断した優先順位情報に基づいて特定サービスを優先的に提供することもできる。このような場合、１８３５動作で説明する優先順位基盤サービス処理方法を適用することもできる。
【０２０５】
１８３０動作へ進行する場合、ＭＣＰＴＴ端末は優先順位を判断する。ＭＣＰＴＴ端末は現在進行中のサービスと新しいサービスリクエストに対応するサービスの優先順位を判断することができる。
【０２０６】
１８３５動作でＭＣＰＴＴ端末は優先順位に基づいて現在進行中のサービスと新しいサービスリクエストに対応するサービスの優先順位に基づいてサービスを提供することができる。例えば、優先順位がより高いサービスを先に処理することができる。ＭＣＰＴＴ端末は後順位サービスをドロップ(ｄｒｏｐ)したり、ホールド(ｈｏｌｄ)できる。また、同時に提供可能なサービスで切り替えて提供したり、ＭＣＰＴＴ端末ユーザの他の端末で伝達することができる。
【０２０７】
１８３５動作は下記のように具体化されることができる。ＭＣＰＴＴ端末は優先順位に基づいてサービスを調整することができる。現在進行中のサービスと新規サービス中で優先順位がより低いサービスを調整することができる。優先順位がより低いサービスを後順位サービスと指称する。ＭＣＰＴＴ端末は後順位サービスリクエストを拒絶することができる。後順位サービスリクエストを拒絶した場合、ＭＣＰＴＴ端末はこれをＭＣＰＴＴサーバーまたは相手端末に通知することができる。
【０２０８】
ＭＣＰＴＴ端末は後順位サービスの当該メディアをＭＣＰＴＴ端末またはサーバーに記憶後に送信することができる。ＭＣＰＴＴ端末は後順位サービスリクエストをホールドした後、現在進行中のサービスが終了される場合、提供することができる。この時、先順位サービスで一部メディアが先ず終了される場合、ホールドされた後順位サービス中の先順位サービスのメディアと衝突しないメディアを先ず提供することができる。また、後順位サービス情報を記憶した後、記憶された情報を確認することができる時期に実行されるようにできる。
【０２０９】
また、後順位サービスの当該メディアタイプを変換することができる。例えば、後順位サービスの当該メディアタイプを変換しては順位サービスと衝突しないメディアで変換して提供したり、先順位サービスが提供するメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。後順位サービスで複数のメディアを提供する場合、複数のメディア中で先順位サービスが提供しているメディアと同時に提供可能なメディアは共に提供し、同時に提供可能ではないメディアだけ調整することができる。
【０２１０】
また、後順位サービスをＭＣＰＴＴ端末ユーザの他の端末で送信することもできる。当該サービスの当該メディアを同じユーザの他の端末で送信するために同一のユーザが保有した他の端末の装置性能(ｄｅｖｉｃｅ ｃａｐａｂｉｌｉｔｙ)が考慮されることができる。
【０２１１】
一方、前記図１８の動作はＭＣＰＴＴ端末だけではなくＭＣＰＴＴサーバーにも適用可能である。ＭＣＰＴＴサーバーは第１端末からサービスリクエストを受信する場合、これを第２端末でサービスリクエストを伝達する。前記図１８で説明した内容はサービスリクエストを受信した第２端末の動作である。しかし、前記図１８の内容は第１端末からサービスリクエストを受信したＭＣＰＴＴサーバーで第２端末でサービスリクエストを伝達する前に適用されることもできる。
【０２１２】
すなわち、ＭＣＰＴＴサーバーで前記第２端末に現在進行中のサービスがあるか否かを判断することができる。進行中のサービスがない場合、リクエストされたサービスを直ちに伝達し、進行中のサービスがある場合、現在第２端末で提供中のサービスが新しいサービスリクエストと同時に提供可能であるか否かを判断することができる。判断結果によって両サービスを同時に提供するようにサービスリクエストを伝達したり、同時に提供可能ではないことで判断する場合、両サービスの優先順位を判断し、優先順位に基づいて第２端末がサービスを提供するようにサービスリクエストを送信することができる。
【０２１３】
図１９は、本発明の一実施形態による優先順位基盤サービス処理のための端末の動作を示した図面である。
【０２１４】
図１９を参照すれば、１９０５動作でＭＣＰＴＴ端末は新しい新規サービスリクエストを受信する。１９１０動作でＭＣＰＴＴ端末は現在進行中のサービスがあるか判断することができる。現在進行中のサービスがある場合、１９２０動作へ進行し、現在進行中のサービスがない場合、１９１５動作へ進行する。
【０２１５】
現在進行中のサービスがない場合、１９１５動作へ進行したＭＣＰＴＴ端末はサービスリクエストを受諾する。ＭＣＰＴＴ端末はリクエスト受けたサービスを処理することができる。
【０２１６】
現在進行中のサービスがある場合、１９２０動作へ進行したＭＣＰＴＴ端末は現在進行中のサービスと新しくリクエストされたサービスの優先順位を比べる。
【０２１７】
現在進行中のサービスの優先順位がより高い場合には１９２５動作へ進行し、新しくリクエストされたサービスの優先順位がより高い場合には１９５０動作へ進行する。
【０２１８】
現在進行中のサービスの優先順位がより高い場合、１９２５動作へ進行したＭＣＰＴＴ端末は各サービスが提供するメディアを比べる。ＭＣＰＴＴ端末は当該サービスのメディアタイプを比べて同時にサービスが可能であるか否かを判断することができる。同時にサービス提供が可能な場合、１９３０動作へ進行し、同時にサービス提供が可能ではない場合、１９３５動作へ進行する。
【０２１９】
同時にサービス提供が可能な場合、ＭＣＰＴＴ端末は１９３０動作へ進行して各サービスを同時に提供することができる。
【０２２０】
同時にサービス提供が不可能なメディアの場合、１９３５動作へ進行した端末は各サービスが提供するメディアを比べてサービスを処理することができる。例えば、１９３５動作で現在サービスと新規サービスのメディアがいずれも重複されるか否かによってサービスを処理することができる。例えば、一部サービスを調整することができる。この時、調整はＭＣＰＴＴサーバーまたはサービスリクエストを送信した相手端末と当該サービスの当該メディアを調整することができる。
【０２２１】
例えば、新規サービスのすべてのメディアが現在サービスのすべてのメディアと重複される場合、１９４０動作へ進行する。１９４０動作でＭＣＰＴＴ端末はサービスを調整することができる。現在進行中のサービスの優先順位がより高い場合であるのでＭＣＰＴＴ端末は新しくリクエストされたサービス(新規サービス)を調整することができる。ＭＣＰＴＴ端末は新規サービスリクエストを拒絶することができる。サービスリクエストを拒絶した場合、これをＭＣＰＴＴサーバーまたは相手端末に通知することができる。
【０２２２】
当該サービスの当該メディアをＭＣＰＴＴ端末またはサーバーに記憶した後に送信することができる。ＭＣＰＴＴ端末は新規サービスリクエストをホールドした後、現在進行中のサービスが終了される場合、提供することができる。この時、現在進行中のサービスで一部メディアが先ず終了される場合、ホールドされた新規サービス中で現在進行中のサービスのメディアと衝突しないメディアを先ず提供することができる。また、新規サービス情報を記憶した後、記憶された情報を確認することができる時期に実行されるようにできる。
【０２２３】
また、新規サービスの当該メディアタイプを変換することができる。例えば、新規サービスの当該メディアタイプを変換して現在進行中のサービスと衝突しないメディアで変換して提供したり、現在進行中のメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。
【０２２４】
また、新規サービスをＭＣＰＴＴ端末ユーザの他の端末で送信することもできる。当該サービスの当該メディアを同じユーザの他の端末で送信するために同一のユーザが保有した他の端末の装置性能(ｄｅｖｉｃｅ  ｃａｐａｂｉｌｉｔｙ)が考慮されることができる。
【０２２５】
新規サービスのすべてのメディアが現在サービスのメディアと一部だけ重複される場合、１９４５動作へ進行する。１９４５動作でＭＣＰＴＴ端末はメディアネゴシエーションを行って現在サービスのメディアと重複されないメディアに対してだけ新規サービスを開始する。この時、ＭＣＰＴＴ端末は他の端末で呼出しフォワーディング(ｃａｌｌ ｆｏｒｗａｒｄｉｎｇ)をするようにサーバーにリクエストすることができる。
【０２２６】
１９２０動作で新規サービスの優先順位がより高いと、１９５０動作へ進行する。ＭＣＰＴＴ端末は各サービスが提供するメディアを比べる。ＭＣＰＴＴ端末は当該サービスのメディアタイプを比べて両サービスが提供するメディアが同一のメディアであるか否かを判断する。互いに相違するメディアを提供する場合、１９５５動作へ進行し、両サービスが同一メディアを提供する場合、１９６０動作へ進行する。
【０２２７】
互いに相違するメディアを提供する場合、同時にサービス提供が可能なことで判断し、ＭＣＰＴＴ端末は１９５５動作へ進行して各サービスを同時に提供することができる。
【０２２８】
両サービスの提供するメディアが同一の場合、ＭＣＰＴＴ端末は１９６０動作へ進行してメディアタイプを判断する。ＭＣＰＴＴ端末はメディアタイプを判断して同時に提供可能なメディアであるか否かを判断することができる。例えば、本実施形態で各メディアはメディアタイプＡとメディアタイプＢで区分されることができる。メディアタイプＡは同時に２つのメディアが同時に提供可能なタイプで、メディアタイプＢは同時に提供可能ではないメディアタイプである。
【０２２９】
両サービスが同時に提供可能なメディアを提供する場合、１９６５動作へ進行して２つのメディアを同時に提供する方法でサービスを提供する。
【０２３０】
両サービスが同時に提供可能なメディアではない場合、１９７０動作へ進行する。１９７０動作でＭＣＰＴＴ端末は現在進行中のサービスを調整してサービスを提供することができる。１９２０動作で新規サービスの優先順位が高い場合であるので現在進行中のサービスが調整されることができる。
【０２３１】
ＭＣＰＴＴ端末は現在進行中のサービスを拒絶することができる。サービスを拒絶した場合、これをＭＣＰＴＴサーバーまたは相手端末に通知することができる。
【０２３２】
現在進行中のサービスをＭＣＰＴＴ端末またはサーバーに記憶後に送信することができる。ＭＣＰＴＴ端末は現在進行中のサービスをホールドした後、新規サービスが終了される場合、提供することができる。この時、新規サービスで一部メディアが先ず終了される場合、ホールドされたサービスのメディア中で衝突しないメディアを先ず提供することができる。また、現在進行中のサービス情報を記憶した後、記憶された情報を確認することができる時期に実行されるようにできる。
【０２３３】
また、現在進行中のサービスの当該メディアタイプを変換することができる。例えば、現在進行中のサービスの当該メディアタイプを変換して新規サービスが提供するメディアと衝突しないように変換して提供することができる。現在進行中のサービスのメディアを新規サービスのメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。
【０２３４】
前記のような方法で優先順位に基づいたＭＣＰＴＴサービスを提供することができる。
【０２３５】
図２０は、本発明の一実施形態による優先順位基盤のサービス処理のためのサーバーの動作を示した図面である。
【０２３６】
２００５動作でＭＣＰＴＴサーバーは第１端末から新規サービスリクエストを受信する。ＭＣＰＴＴユーザ(第１端末ユーザ)から新しい新規サービスリクエストを受信する場合、当該リクエストはＭＣＰＴＴサーバーをパスして目的端末(第２端末)で伝達する。
【０２３７】
２０１０動作で、新規サービスリクエストを受けたＭＣＰＴＴサーバーは当該ＭＣＰＴＴ端末(第２端末)で現在の別のサービスが進行中であるか確認することができる。第２端末に現在進行中のサービスがない場合、２０１５動作へ進行し、現在進行中のサービスがある場合、２０２０動作へ進行する。
【０２３８】
２０１５動作でＭＣＰＴＴサーバーは第２端末で実行中のＭＣＰＴＴサービスがないから当該新規サービスリクエストを第２端末で伝達する。
【０２３９】
現在進行中のサービスがある場合、２０２０動作へ進行する。２０２０動作へ進行したＭＣＰＴＴ端末は現在進行中のサービスと新しくリクエストされたサービスの優先順位を比べる。
【０２４０】
現在進行中のサービスの優先順位がより高い場合には２０２５動作へ進行し、新しくリクエスト受けたサービスの優先順位がより高い場合には２０５０動作へ進行する。
【０２４１】
現在進行中のサービスの優先順位がより高い場合、２０２５動作へ進行したＭＣＰＴＴサーバーは各サービスが提供するメディアを比べる。ＭＣＰＴＴサーバーは当該サービスのメディアタイプを比べて同時にサービスが可能であるか否かを判断することができる。同時にサービス提供が可能な場合、２０３０動作へ進行し、同時にサービス提供が可能ではない場合、２０３５動作へ進行する。
【０２４２】
同時にサービス提供が可能な場合、ＭＣＰＴＴ端末は２０３０動作へ進行してサービスリクエストメッセージをフォワーディングし、サービスリクエストメッセージが伝達された端末がサービスリクエストを受諾するかを決定することができる。端末がサービスリクエストを受諾する場合、各サービスが同時に提供されることができる。
【０２４３】
同時にサービス提供が不可能なメディアの場合、２０３５動作へ進行したサーバーは各サービスが提供するメディアを比べてサービスを処理することができる。例えば、２０３５動作で現在サービスと新規サービスのメディアがいずれも重複されるか否かによってサービスを処理することができる。例えば、一部サービスを調整することができる。この時、調整はＭＣＰＴＴサーバーまたはサービスリクエストを送信した相手端末と当該サービスの当該メディアを調整することができる。
【０２４４】
例えば、新規サービスのすべてのメディアが現在サービスのすべてのメディアと重複される場合、２０４０動作へ進行する。２０４０動作でＭＰＴＴサーバーはサービスを調整することができる。現在進行中のサービスの優先順位がより高い場合であるのでＭＣＰＴＴサーバーは新しくリクエストされたサービス(新規サービス)を調整することができる。ＭＣＰＴＴサーバーは新規サービスリクエストを拒絶することができる。サービスリクエストを拒絶した場合、これをサービス関連端末に通知することができる。
【０２４５】
当該サービスの当該メディアをＭＣＰＴＴサーバーに記憶後に送信することができる。ＭＣＰＴＴサーバーは新規サービスリクエストをホールドした後、現在進行中のサービスが終了される場合、提供することができる。この時、現在進行中のサービスで一部メディアが先ず終了される場合、ホールドされた新規サービス中で現在進行中のサービスのメディアと衝突しないメディアを先ず提供することができる。また、新規サービス情報を記憶した後、記憶された情報を確認することができる時期に実行されるようにできる。
【０２４６】
また、ＭＣＰＴＴサーバーは新規サービスの当該メディアタイプを変換することができる。例えば、新規サービスの当該メディアタイプを変換して現地進行中のサービスと衝突しないメディアで変換して提供したり、現在進行中のメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。
【０２４７】
また、ＭＣＰＴＴサーバーは新規サービスをＭＣＰＴＴ端末ユーザの他の端末で送信することもできる。当該サービスの当該メディアを同じユーザの他の端末で送信するために同一のユーザが保有した他の端末の装置性能(ｄｅｖｉｃｅ ｃａｐａｂｉｌｉｔｙ)が考慮されることができる。
【０２４８】
新規サービスのすべてのメディアが現在サービスのメディアと一部だけ重複される場合、２０４５動作へ進行する。２０４５動作でＭＣＰＴＴ端末はメディアネゴシエーション(ｎｅｇｏｔｉａｔｉｏｎ)を行って現在サービスのメディアと重複されないメディアに対してだけ新規サービスを開始する。この時、ＭＣＰＴＴ端末は予め登録された他の端末で呼出しフォワーディング(ｃａｌｌ ｆｏｒｗａｒｄｉｎｇ)をするようにサーバーにリクエストすることができる。
【０２４９】
２０２０動作で新規サービスの優先順位がより高い場合、２０５０動作へ進行する。ＭＣＰＴＴサーバーは各サービスが提供するメディアを比べる。ＭＣＰＴＴサーバーは当該サービスのメディアタイプを比べて両サービスの提供するメディアが同一メディアであるか否かを判断する。互いに相違するメディアを提供する場合、２０５５動作へ進行し、両サービスが同一メディアを提供する場合２０６０動作へ進行する。
【０２５０】
互いに相違するメディアを提供する場合、同時にサービス提供が可能なことで判断し、ＭＣＰＴＴサーバーは２０５５動作へ進行してサービスリクエストメッセージをフォワーディングし、サービスリクエストメッセージが伝達された端末がサービスリクエストを受諾するかを決定することができる。端末がサービスリクエストを受諾する場合、各サービスが同時に提供されることができる。
【０２５１】
両サービスが提供するメディアが同一の場合、ＭＣＰＴＴサーバーは２０６０動作へ進行してメディアタイプを判断する。ＭＣＰＴＴサーバーはメディアタイプを判断して同時に提供可能なメディアであるか否かを判断することができる。例えば、本実施形態で各メディアはメディアタイプＡとメディアタイプＢに区分されることができる。メディアタイプＡは同時に２つのメディアが同時に提供可能なタイプで、メディアタイプＢは同時に提供可能ではないメディアタイプである。
【０２５２】
両サービスが同時に提供可能なメディアを提供する場合、２０６５動作へ進行してサービスを提供する。
【０２５３】
両サービスが同時に提供可能なメディアではない場合、２０７０動作へ進行する。２０７０動作でＭＣＰＴＴサーバーは現在進行中のサービスを調整してサービスを提供することができる。２０２０動作で新規サービスの優先順位が高い場合であるので現在進行中のサービスが調整されることができる。
【０２５４】
ＭＣＰＴＴサーバーは現在進行中のサービスを拒絶することができる。サービスを拒絶した場合、これをＭＣＰＴＴサービス関連端末で通知することができる。
【０２５５】
ＭＣＰＴＴサーバーは現在進行中のサービスを記憶後に送信することができる。ＭＣＰＴＴサーバーは現在進行中のサービスをホールドした後、新規サービスが終了される場合、提供することができる。この時、新規サービスで一部メディアが先ず終了される場合、ホールドされたサービスのメディア中で衝突しないメディアを先ず提供することができる。
【０２５６】
また、ＭＣＰＴＴサーバーは現在進行中のサービスの当該メディアタイプを変換することができる。例えば、現在進行中のサービスの当該メディアタイプを変換して新規サービスが提供するメディアと衝突しないように変換して提供することができる。現在進行中のサービスのメディアを新規サービスのメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。
【０２５７】
前記のような方法でＭＣＰＴＴサーバーは第２端末に現在進行中のサービスと新規サービスの優先順位に基づいて必要な場合、各サービスが提供するメディアを調整してＭＣＰＴＴサービスを提供することができる。
【０２５８】
サービスリクエストメッセージを受けたＳＩＰ Ｃｏｒｅは当該サービスのためのネットワークリソースを管理するのに優先順位値を用いることができる。
【０２５９】
図２１は、本発明の一実施形態による優先順位値を基づいたフロア・コントロール(ｆｌｏｏｒｃｏｎｔｒｏｌ)過程を示した図面である。
【０２６０】
図２１を参照すれば、ＭＣＰＴＴサーバー２１１０はＭＣＰＴＴ Ｃｌｉｅｎｔ１(２１２０) 及びＭＣＰＴＴ Ｃｌｉｅｎｔ２(２１３０)からフロアリクエスト(ｆｌｏｏｒ ｒｅｑｕｅｓｔ)メッセージを受信することができる。例えば、図２１の状況はグループ通信状況であることで仮定する。グループ通信はグループ呼出し(ｇｒｏｕｐｃａｌｌ)であってもよい。
【０２６１】
グループ呼出しでは複数のＣｌｉｅｎｔ(２１２０、２１３０)が参加することができる。複数のＣｌｉｅｎｔがグループ呼出しに参加する場合、互いに異なるクライアントから通信衝突を阻むためにデータを送信しようとする端末はフロアリクエストメッセージをＭＣＰＴＴサーバー２１１０へ送信する。フロアリクエストメッセージを受信したＭＣＰＴＴサーバー２１１０はフロアグラント(ｆｌｏｏｒ ｇｒａｎｔ)メッセージを送信する。フロアグラントメッセージを受信したクライアント(ｃｌｉｅｎｔ)はデータを送信することができる。
【０２６２】
本実施形態ではフロアリクエストメッセージを受信したＭＣＰＴＴサーバー２１１０がフロアグラントメッセージを送信する時、複数の端末の中で優先順位がより高い端末に優先的にフロアグラントメッセージを送信することができる。図２１の実施形態においてＭＣＰＴＴ Ｃｌｉｅｎｔ２(２１３０)はＭＣＰＴＴ Ｃｌｉｅｎｔ１(２１２０)より優先順位が高いことで仮定する。したがって、ＭＣＰＴＴサーバー２１１０はＭＣＰＴＴ Ｃｌｉｅｎｔ１(２１２０)とＭＣＰＴＴ Ｃｌｉｅｎｔ２(２１３０)からフロアリクエストメッセージを受信する場合、さらに高い優先順位を有するＭＣＰＴＴ Ｃｌｉｅｎｔ２(４３０)にフロアグラントを送信することができる。優先順位が同一の場合、フロアリクエストが受信された手順などが追加的に考慮されることができる。
【０２６３】
図２２は、本実施形態による優先順位及び端末の位置情報に基づいてネットワークでＱｏＳを提供する過程を示した図面である。
【０２６４】
図２２を参照すれば、ＭＣＰＴＴサーバーがグループ通信(例えば、グループ呼出しサービス) リクエストを受信した場合、グループに属した各ユーザにグループ呼出しサービスリクエストを伝達し、グループ呼出しサービスを提供しなければならないが、この時、サービスリクエストを伝達する手順を各グループ呼出しに参加するユーザの数及び／またはユーザの優先順位に基づいて適用する方法を説明する。
【０２６５】
２２０５動作でＭＣＰＴＴサーバーはサービスリクエストを受信することができる。前記サービスリクエストはグループ通信リクエスト、グループ呼出しサービスであってもよい。
【０２６６】
２２１０動作でＭＣＰＴＴサーバーはリクエストされたサービスがグループサービスリクエストであるかを判断することができる。グループサービスはグループ通信リクエスト、グループ呼出しサービスを含むことができる。ＭＣＰＴＴサーバーはグループサービスリクエストではない場合、２２１５動作へ進行し、グループサービスリクエストの場合２２２０動作へ進行する。
【０２６７】
２２１５動作へ進行する場合、ＭＣＰＴＴサーバーは一般的な手続きによってリクエストされたサービスを処理することができる。例えば、図１８乃至図２０で説明した方法でサービスを処理することができる。
【０２６８】
２２０動作へ進行する場合、ＭＣＰＴＴサーバーはグループサービスを処理するための動作を行うことができる。グループサービスの場合にも図１８乃至図２０を介して説明した実施形態の適用は可能である。
【０２６９】
２２２０動作でＭＣＰＴＴサーバーはグループサービス対象端末の位置情報を獲得することができる。
【０２７０】
ＭＣＰＴＴサーバーはグループサービスに対象ユーザの位置情報を獲得するために以下のような方法を適用することができる。第１方法は、ＭＣＰＴＴ端末がネットワークに接続してＭＣＰＴＴサーバーに登録する時、現在端末が接続したネットワークのＩＤ情報を送信することができる。また、端末が動きながら接続したネットワークを変える度に接続したネットワークＩＤ情報をアップデートレポーティングする。第２方法はＭＣＰＴＴサーバーがグループ呼出しサービスリクエストを受ける時、網に端末の位置情報を照会して分かる。網は当該情報が分かっている時、ＭＣＰＴＴサーバーに通知することができる。網は当該情報が分からない時、ｉｄｌｅ(アイドル)状態である端末にメッセージを送信してネットワークＩＤ情報を獲得することができる。第２方法の場合、当該ネットワークに接続しているリアルタイムユーザ数の情報を通知することができる。ＭＣＰＴＴサーバーはグループ呼出しサービスリクエストを受信後、グループ呼出しサービス対象端末にＳＩＰ ｉｎｖｉｔｅを送信することができる。各グループ呼出しサービス対象端末は応答メッセージを送信することができ、応答メッシュには各グループ呼出しサービス対象端末の位置情報が含まれることができる。
【０２７１】
グループ呼出しサービスをリクエストした端末の位置情報は、サービスＭＣＰＴＴサーバーでサービスリクエストを受信する時、確認することもできる。例えば、グループ呼出しサービスリクエストで位置情報が送信することもできる。ＩＭＳ基盤のＳＩＰプロトコルを用いる場合、グループ呼出しサービスをリクエストする端末はＳＩＰ ｒｅｑｕｅｓｔのヘッダー(ｈｅａｄｅｒ) 中にユーザ位置情報を含んで送信することができる。すなわち、Ｇｒｏｕｐ ｃａｌｌ ｒｅｑｕｅｓｔ ｉｎｖｉｔｅを送信する時、リクエストメッセージのヘッダー中に自分のネットワーク情報を含ませることができる。ネットワーク情報は位置情報であってもよく、端末が接続したセルのセルアイディーであってもよい。グループ呼出しｒｅｑｕｅｓｔの位置情報がないか、これを利用しない場合、前記で言及した位置情報獲得方式を利用することもできる。グループ呼出しをリクエストしたグループ対象者の情報はＳＩＰ Ｉｎｖｉｔｅ ｒｅｑｕｅｓｔで得ることができ、当該リクエストを受けた他の対象者の情報はＳＩＰ ｒｅｓｐｏｎｓｅにその位置情報が含まれることができる。
【０２７２】
ＭＣＰＴＴサーバーは位置情報獲得以後に２２２５動作へ進行することができる。２２２５動作でＭＣＰＴＴサーバーはグループ呼出しサービス対象端末の数が予め設定された臨界条件を満足するか判断することができる。前記臨界条件はグループサービスを提供する時、マルチキャストで提供するか、ユニキャストで提供するか否かを決定するための臨界条件である。例えば、予め設定されたしきい値以上の端末がグループ呼出しサービス対象端末の場合、マルチキャストでグループサービスのためのメディアを提供することができる。グループサービスは複数の対象者に同一のメディアが送信されるから、一定数以上のグループサービス対象端末が存在する場合、マルチキャスト方法を用いる方がリソース効率側面で有利することができる。
【０２７３】
グループサービス対象端末の数が予め設定された臨界条件を満足する場合、２２３０動作へ進行する。ＭＣＰＴＴサーバーはグループサービスのためのメディアをマルチキャスト方式を用いて提供することができる。一方、メディアはマルチキャスト方式で提供するが、シグナリングの場合、相変らずユニキャスト方式を用いることができる。シグナリングを送信する時、グループサービス対象端末の優先順位に基づいてシグナリング手順が決定されることができる。例えば、グループサービスのためのセルの収容力が２００人と仮定し、グループサービス対象端末の数が２５０の場合、５０個の端末に対してはグループサービスを提供することができない。この場合、端末の優先順位によって上位２００個の端末に限ってシグナリングしてグループサービスを提供することができる。
【０２７４】
グループサービス対象端末の数が予め設定された臨界条件を満足することができない場合、２２３５動作へ進行することができる。ＭＣＰＴＴサーバーはグループサービスのためのメディアをユニキャスト方式で提供することができる。ＭＣＰＴＴサーバーはメディア提供時の優先順位に基づいててグループサービス対象端末に順次にメディアを提供することができる。だけでなくシグナリングを送信する時、グループサービス対象端末の優先順位に基づいてシグナリング手順が決定されることができる。
【０２７５】
このような端末の位置情報に基づいてＭＣＰＴＴサーバーは特定ネットワークに端末が集中して集まっている時、もし、ネットワークサポートユーザ数よりその数が多い場合、ユーザの優先順位によって優先順位が高いユーザに先ずサービスを提供する。
【０２７６】
緊急グループ呼出しはＭＣＰＴＴで高い優先順位を提供するサービスの一例である。ＭＣＰＴＴシステムは端末及び多くの個体を経てＭＣＰＴＴ端末にＭＣＰＴＴ優先順位サービスを提供する。
【０２７７】
図２３乃至図３１は、優先順位サービスの一例である緊急グループ呼出しサービスがＭＣＰＴＴシステムを介して提供される過程のメッセージフローを示す。
【０２７８】
ＭＣＰＴＴ(Ｍｉｓｓｉｏｎ Ｃｒｉｔｉｃａｌ Ｐｕｓｈ ｔｏ Ｔａｌｋ ｏｖｅｒ ＬＴＥ)端末はＭＣＰＴＴ網を介してＡｌｅｒｔメッセージを送信することができる。Ａｌｅｒｔメッセージは端末位置情報、ユーザＩＤ、グループＩＤ、所属団体情報を含む。Ａｌｅｒｔメッセージを送信するＭＣＰＴＴサーバーはＡｌｅｒｔメッセージを送信するユーザの権限を確認する。Ａｌｅｒｔメッセージに十分な情報が含まれていない時または含まれていてもＡｌｅｒｔメッセージに情報を修正したり追加、削除することができる。本発明の実施形態においてクライアントは端末と混用して用いることができる。緊急発生時の端末は他の端末に自分が緊急であることを通知すべきである。以下の各実施形態を用いてＭＣＰＴＴユーザは緊急に対する救護に役に立つことができる。
【０２７９】
図２３乃至図２５は、本実施形態でＡｌｅｒｔメッセージを送信することができる方法を示す。ＡｌｅｒｔメッセージはＭＣＰＴＴサービスで、例えば、緊急呼出しをｉｎｖｉｔｅする前に送信されることができる。Ａｌｅｒｔ ｍｅｓｓａｇｅ関連手続きはＭＣＰＴＴサービス提供においてオプションであってもよい。
【０２８０】
図２３は、本実施形態によるＳＩＰ ＭＥＳＳＡＧＥメソッドを用いてＡｌｅｒｔメッセージを送信する過程を示す。
【０２８１】
図２３を参照すれば、移動通信システムはＭＣＰＴＴ Ｃｌｉｅｎｔ１(２３０５)、ＳＩＰ Ｃｏｒｅ２３１０、ＭＣＰＴＴ ｓｅｒｖｅｒ２３１５、ＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２３２０を含むことができる。また、ＭＣＰＴＴ Ｃｌｉｅｎｔ２(２３２５)、ＭＣＰＴＴ Ｃｌｉｅｎｔ３(２３３０)をさらに含むことができる。ＭＣＰＴＴ ＣｌｉｅｎｔはＭＣＰＴＴ端末と混用して用いることができる。ＭＣＰＴＴａｌｅｒｔは端末または端末のユーザが緊急を通知するメッセージであってもよい。
【０２８２】
２３４１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２３０５)はＭＣＰＴＴＡｌｅｒｔ動作を開始する。２３４３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２３０５)はＳＩＰ Ｃｏｒｅ２３１０でＳＩＰメッセージを送信する。前記ＳＩＰメッセージは端末の位置情報、ユーザＩＤ、グループＩＤ、所属団体情報を含むことができる。ＳＩＰ Ｃｏｒｅ２３１０は前記ＳＩＰメッセージをＭＣＰＴＴ ｓｅｒｖｅｒ２３１５へ伝達することができる。実施形態において位置情報はＭＣＰＴＴ Ｃｌｉｅｎｔ１の位置を指示するだけでなく、メッセージを送信する特定対象を選択するのに用いられることもできる。
【０２８３】
２３４７過程でＭＣＰＴＴ ｓｅｒｖｅｒ２３１５はユーザ権限及び／またはユーザ位置をチェックすることができる。ＭＣＰＴＴ ｓｅｒｖｅｒ２３１５はＭＣＰＴＴ ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２３２０と通信してユーザ権限及び位置をチェックすることができる。ＭＣＴＰＰサーバー２３１５はＡｌｅｒｔメッセージを送信するユーザ権限及び／または位置情報を確認して修正が必要な場合、Ａｌｅｒｔメッセージの情報を修正、追加、削除することができる。
【０２８４】
２３４９過程でＭＣＰＴＴ ｓｅｒｖｅｒ２３１５はＳＩＰメッセージをＳＩＰ Ｃｏｒｅ２３１０で送信する。前記ＳＩＰメッセージはＭＣＰＴＴ ｓｅｒｖｅｒ２３１５で一部情報が修正、追加、削除されたメッセージであってもよい。
【０２８５】
２３５１過程でＳＩＰ Ｃｏｒｅ２３１０は、２３４９過程で受信したＳＩＰメッセージに基づいてＭＣＰＴＴ Ｃｌｉｅｎｔ２(２３２５)でＳＩＰメッセージを送信する。
【０２８６】
２３５３過程でＭＣＰＴＴ ｓｅｒｖｅｒ２３１５はＳＩＰメッセージをＳＩＰ Ｃｏｒｅ２３１０で送信する。前記ＳＩＰメッセージはＭＣＰＴＴ ｓｅｒｖｅｒ２３１５で一部情報が修正、追加、削除されたメッセージであってもよい。
【０２８７】
２３５５過程でＳＩＰ Ｃｏｒｅ２３１０は、２３５３過程で受信したＳＩＰメッセージに基づいてＭＣＰＴＴ Ｃｌｉｅｎｔ３(２３３０)でＳＩＰメッセージを送信する。
【０２８８】
２３５７過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２３２５)はＳＩＰ Ｃｏｒｅ２３１０でＳＩＰ２００ＯＫを送信する。２３５９過程でＳＩＰ Ｃｏｒｅ２３１０は、２３５７過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴ ｓｅｒｖｅｒ２３１５で送信する。
【０２８９】
２３６１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(２３３０)はＳＩＰ Ｃｏｒｅ２３１０でＳＩＰ２００ＯＫを送信する。２３６３過程でＳＩＰ Ｃｏｒｅ２３１０は、２３６１過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴ ｓｅｒｖｅｒ２３１５で送信する。
【０２９０】
２３６７過程でＭＣＰＴＴ ｓｅｒｖｅｒ２３１５は受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ２３１０で送信する。２３６９過程でＳＩＰ Ｃｏｒｅ２３１０はＭＣＰＴＴ ｓｅｒｖｅｒ２３１５から受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴ Ｃｌｉｅｎｔ１(２３０５)で送信する。
【０２９１】
前記のような方法でＳＩＰメッセージプロトコルを用いてＡｌｅｒｔメッセージを送信することができる。
【０２９２】
図２４は、本実施形態で端末がＳＩＰではない他のプロトコルを用いてＡｌｅｒｔメッセージを送信する過程を示す図面である。
【０２９３】
図２４を、参照すれば、移動通信システムはＣｌｉｅｎｔ１(２４０５)、ＳＩＰ Ｃｏｒｅ２４１０、ＭＣＰＴＴ ｓｅｒｖｅｒ２４１５、ＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２４２０を含むことができる。また、ＭＣＰＴＴ Ｃｌｉｅｎｔ２(２４２５)、ＭＣＰＴＴ Ｃｌｉｅｎｔ３(２４３０)をさらに含むことができる。図２４で端末はＨＴＴＰｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、ＳＭＳなどを用いることができる。
【０２９４】
２４４１過程でＣｌｉｅｎｔ１(２４０５)はＭＣＰＴＴＡｌｅｒｔ動作を開始する。
【０２９５】
２４４３過程でｃｌｉｅｎｔ１(２４０５)はＭＣＰＴＴ ｓｅｒｖｅｒ２４１５でＭＣＰＴＴａｌｅｒｔＳＭＳを送信する。または、２４４５過程でｃｌｉｅｎｔ１(２４０５)はＭＣＰＴＴ ｓｅｒｖｅｒ２４１５でＭＣＰＴＴ ａｌｅｒｔ ＨＴＴＰ ｒｅｑｕｅｓｔを送信することができる。
【０２９６】
前記ＭＣＰＴＴａｌｅｒｔＳＭＳ及びＭＣＰＴＴａｌｅｒｔＨＴＴＰｒｅｑｕｅｓｔは端末の位置情報、ユーザＩＤ、グループＩＤ、所属団体情報を含むことができる。
【０２９７】
２４４７過程でＭＣＰＴＴ ｓｅｒｖｅｒ２４１５はユーザ権限及び／またはユーザ位置をチェックすることができる。ＭＣＰＴＴ ｓｅｒｖｅｒ２４１５はＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２４２０と通信してユーザ権限及び位置をチェックすることができる。ＭＣＴＰＰサーバー２４１５はＭＣＰＴＴａｌｅｒｔＳＭＳまたはＭＣＰＴＴａｌｅｒｔＨＴＴＰｒｅｑｕｅｓｔを送信するユーザのユーザ権限及び／または位置情報を確認して修正が必要な場合、Ａｌｅｒｔメッセージの情報を修正、追加、削除することができる。ＭＣＰＴＴユーザではない場合、ＳＩＰ以外の方法を用いて特定番号でＳＭＳを送信したり、ＨＴＴＰ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅを送信するようにできる。また、ＭＣＰＴＴ ｓｅｒｖｅｒ２４１５は臨時ユーザＩＤ及びグループを割り当ててＭＣＰＴＴメッセージを構成して当該グループユーザに送信することができる。
【０２９８】
２４４９過程でＭＣＰＴＴ ｓｅｒｖｅｒ２４１５はｃｌｉｅｎｔ１に応答を送信することができる。応答はＭＣＰＴＴ ａｌｅｒｔ ＨＴＴＰ ｒｅｓｐｏｎｓｅまたはＳＭＳで送信することができる。
【０２９９】
２４５１過程でＭＣＰＴＴ ｓｅｒｖｅｒ２４１５はＳＩＰメッセージをＳＩＰ Ｃｏｒｅ２４１０で送信する。前記ＳＩＰメッセージはＭＣＰＴＴ ｓｅｒｖｅｒ２４１５で一部情報が修正、追加、削除されたメッセージであってもよい。
【０３００】
２４５３過程でＳＩＰ Ｃｏｒｅ２４１０は、２４５１過程で受信したＳＩＰメッセージに基づいてＭＣＰＴＴ Ｃｌｉｅｎｔ２(２４２５)でＳＩＰメッセージを送信する。
【０３０１】
２４５５過程でＭＣＰＴＴ ｓｅｒｖｅｒ２４１５はＳＩＰメッセージをＳＩＰ Ｃｏｒｅ２４１０で送信する。前記ＳＩＰメッセージはＭＣＰＴＴ ｓｅｒｖｅｒ２４１５で一部情報が修正、追加、削除されたメッセージであってもよい。
【０３０２】
２４５７過程でＳＩＰ Ｃｏｒｅ２４１０は、２４５５過程で受信したＳＩＰメッセージに基づいてＭＣＰＴＴ Ｃｌｉｅｎｔ３(２４３０)でＳＩＰメッセージを送信する。
【０３０３】
２４５９過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２４２５)はＳＩＰ Ｃｏｒｅ７１０でＳＩＰ２００ＯＫを送信する。２４６１過程でＳＩＰ Ｃｏｒｅ２４１０は、２４５９過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴ ｓｅｒｖｅｒ２４１５で送信する。
【０３０４】
２４６３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(２４３０)はＳＩＰ Ｃｏｒｅ２４１０でＳＩＰ２００ＯＫを送信する。２４６５過程でＳＩＰ Ｃｏｒｅ２４１０は、２４６３過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴ ｓｅｒｖｅｒ２４１５で送信する。
【０３０５】
前記のような方法でＳＩＰメッセージプロトコルではない、ＳＭＳ及び／またはＨＴＴＰを用いてＡｌｅｒｔメッセージを送信することができる。
【０３０６】
図２５は、本実施形態によるＳＩＰ ＳＵＢＳＣＲＩＢＥ及びＮＯＴＩＦＹメソッドを用いてＡｌｅｒｔメッセージを送信する過程を示す図面である。
【０３０７】
図２５の実施形態で端末はＳＩＰ ＳＵＢＳＣＲＩＢＥメソッドを用いて特定イベント状況に対して予め登録しておいて、ＭＣＰＴＴサーバーは当該イベントが発生時イベントが発生したことをイベントに登録した端末にＳＩＰ ＮＯＴＩＦＹで通知する。イベントの発生した端末はＭＣＰＴＴサーバーにイベントが発生したことをＡｌｅｒｔメッセージを送信して通知する。Ａｌｅｒｔメッセージ送信方法はＳＩＰメソッドを用いるか、ＳＩＰ以外のプロトコル(ＨＴＴＰ、ＳＭＳなど)を用いることができる。
【０３０８】
図２５を参照すれば、移動通信システムはＣｌｉｅｎｔ１(２５０５)、ＳＩＰ Ｃｏｒｅ２５１０)、ＭＣＰＴＴ ｓｅｒｖｅｒ２５１５、ＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２５２０を含むことができる。また、ＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５２５)、ＭＣＰＴＴ Ｃｌｉｅｎｔ３(２５３０)をさらに含むことができる。
【０３０９】
２５４１過程乃至２５５５過程はＳＩＰ ＳＵＢＳＣＲＩＢＥ方法を用いて特定イベントを登録する過程を示す。
【０３１０】
２５４１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５２５)はＳＩＰ Ｃｏｒｅ２５１０でＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージを送信する。ＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５２５)はＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージを用いて特定イベント状況を登録する。２５４３過程でＳＩＰ Ｃｏｒｅ２５１０はＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージをＭＣＰＴＴ ｓｅｒｖｅｒ２５１５で送信する。ＭＣＰＴＴ ｓｅｒｖｅｒ２５１５はＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５２５)に対する特定イベントを登録する。２５４５過程でＭＣＰＴＴ ｓｅｒｖｅｒ２５１５はＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ２５１０で送信する。２５４７過程でＳＩＰ Ｃｏｒｅ２５１０はＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５２５)でＳＩＰ２００ＯＫを送信する。前記過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２に対する特定イベントを登録する。
【０３１１】
２５４９過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(２５３０)はＳＩＰ Ｃｏｒｅ２５１０でＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージを送信する。ＭＣＰＴＴ Ｃｌｉｅｎｔ３(２５３０)はＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージを用いて特定イベント状況を登録する。２５５１過程でＳＩＰ Ｃｏｒｅ２５１０はＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージをＭＣＰＴＴ ｓｅｒｖｅｒ２５１５で送信する。ＭＣＰＴＴ ｓｅｒｖｅｒ２５１５はＭＣＰＴＴ Ｃｌｉｅｎｔ３(２５３０)に対する特定イベントを登録する。２５５３過程でＭＣＰＴＴ ｓｅｒｖｅｒ２５１５はＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ２５１０で送信する。２５５５過程でＳＩＰ Ｃｏｒｅ２５１０はＭＣＰＴＴ Ｃｌｉｅｎｔ３(２５３０)でＳＩＰ２００ＯＫを送信する。前記過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５２５)に対する特定イベントを登録する。
【０３１２】
２５５７過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２５０５)はＭＣＰＴＴＡｌｅｒｔ動作を開始する。
【０３１３】
図２５の図面ではＡｌｅｒｔメッセージ送信方法でＳＩＰメッセージを送信する構成を示しているが、前記で説明したように、Ａｌｅｒｔメッセージを送信する方法はＳＩＰメッセージだけではなく他のプロトコルを用いることができる。例えば、図２４で説明したＨＴＴＰ、ＳＭＳなどを用いることもできる。
【０３１４】
２５５９過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２５０５)はＳＩＰ Ｃｏｒｅ２５１０でＳＩＰメッセージを送信する。前記ＳＩＰメッセージは端末の位置情報、ユーザＩＤ、グループＩＤ、所属団体情報を含むことができる。２５６１過程でＳＩＰ Ｃｏｒｅ２５１０は前記ＳＩＰメッセージをＭＣＰＴＴ ｓｅｒｖｅｒ２５１５で伝達することができる。
【０３１５】
２５６３過程でＭＣＰＴＴ ｓｅｒｖｅｒ８１５はユーザ権限及び／またはユーザ位置をチェックすることができる。ＭＣＰＴＴ ｓｅｒｖｅｒ２５１５はＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２５２０と通信してユーザ権限及び位置をチェックすることができる。
【０３１６】
ＭＣＰＴＴ ｓｅｒｖｅｒ２５１５は特定イベントが発生したか否かを確認することができる。ＭＣＰＴＴ ｓｅｒｖｅｒは特定イベント発生可否によって特定イベント状況を予め登録したクライアントにＳＩＰ ＮＯＴＩＦＹを送信するようにできる。
【０３１７】
２５６５過程でＭＣＰＴＴ ｓｅｒｖｅｒ２５１５はＳＩＰ Ｃｏｒｅ２５１０でＳＩＰ ＮＯＴＩＦＹを送信することができる。前記ＳＩＰ ＮＯＴＩＦＹメッセージは特定イベント状況を指示することができる。２５６７過程でＳＩＰ Ｃｏｒｅ２５１０はＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５２５でＳＩＰ ＮＯＴＩＦＹを送信することができる。
【０３１８】
２５６９過程でＭＣＰＴＴ ｓｅｒｖｅｒ２５１５はＳＩＰ Ｃｏｒｅ２５１０でＳＩＰ ＮＯＴＩＦＹを送信することができる。前記ＳＩＰ ＮＯＴＩＦＹメッセージは特定イベント状況を指示することができる。２５７１過程でＳＩＰ Ｃｏｒｅ２５１０はＭＣＰＴＴ Ｃｌｉｅｎｔ３(２５３０)でＳＩＰ ＮＯＴＩＦＹを送信することができる。
【０３１９】
２５７３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５２５)はＳＩＰ Ｃｏｒｅ(２５１０)でＳＩＰ２００ＯＫを送信する。２５７５過程でＳＩＰ Ｃｏｒｅ２５１０は２５７３過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴサーバ２５１５で送信する。
【０３２０】
２５７７過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２５３０)はＳＩＰ Ｃｏｒｅ(２５１０)でＳＩＰ２００ＯＫを送信する。２５７９過程でＳＩＰ Ｃｏｒｅ２５１０は２５７７過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴサーバ２５１５で送信する。
【０３２１】
２５８１過程でＭＣＰＴＴ ｓｅｒｖｅｒ２５１５は２５７９過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００２０ＯＫをＳＩＰ Ｃｏｒｅ２５１０で送信する。２５８３過程でＳＩＰ Ｃｏｒｅ２５１０はＭＣＰＴＴ ｓｅｒｖｅｒ２５１５から受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴ Ｃｌｉｅｎｔ１(２５０５)で送信する。
【０３２２】
前記のような方法でＳＩＰ ＮＯＴＩＦＹ方法を用いてＡｌｅｒｔメッセージを送信することができる。
【０３２３】
図２６は、本実施形態によるＡｌｅｒｔメッセージに端末の位置情報を含んで送信する過程を示した図面である。
【０３２４】
端末が送信するＡｌｅｒｔメッセージは端末の位置情報を含むことができる。図２６は位置情報を獲得する方法及び位置情報をＡｌｅｒｔメッセージに挿入する方法を示す。端末はＡｌｅｒｔメッセージに端末のＧＰＳ(ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ)位置情報を含んで送信することができる。もし、ＧＰＳ機能がオフされていると、オンすることができる。Ａｌｅｒｔメッセージを受けたＳＩＰ ＣｏｒｅはＳＩＰ Ｃｏｒｅが記憶している情報に基づいて端末の位置情報をＡｌｅｒｔメッセージに追加することができる。Ａｌｅｒｔメッセージを受けたＭＣＰＴＴサーバーはＳＩＰ Ｃｏｒｅまたは網から端末の位置情報を獲得して当該情報をＡｌｅｒｔメッセージに追加することができる。
【０３２５】
図２６を参照すれば、移動通信システムはＭＣＰＴＴ Ｃｌｉｅｎｔ１(２６０５)、ＳＩＰ Ｃｏｒｅ２６１０、ＰＣＲＦ(ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｒｕｌｅ ｆｕｎｃｔｉｏｎ、２６１５、ＭＣＰＴＴ ｓｅｒｖｅｒ２６２０、ＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２６２５及びＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ、２６３０)を含むことができる。
【０３２６】
２６４１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２６０５)はＭＣＰＴＴａｌｅｒｔ動作を開始する。
【０３２７】
２６４３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２６０５)は位置情報確認器機の状態を確認することができる。例えば、前記位置情報確認機器はＧＰＳを含むことができる。ＭＣＰＴＴ Ｃｌｉｅｎｔ１(２６０５)はＧＰＳがオフ状態の場合、ＧＰＳの状態をオン状態に変更することができる。
【０３２８】
２６４５過程でＳＩＰｃｌｉｅｎｔ１(２６０５)はＳＩＰ Ｃｏｒｅ２６１０でＳＩＰメッセージを送信することができる。ＳＩＰメッセージは端末のＧＰＳ情報を含むことができる。２６４７過程でＳＩＰ Ｃｏｒｅ２６１０はＰＣＲＦ２６１５でユーザ位置情報リクエストを送信することができる。２６４９過程でＰＣＲＦ２６１５はＳＩＰ Ｃｏｒｅ２６１０でユーザ情報応答情報を送信することができる。２６４７過程及び２６４９過程は省略されることができる。
【０３２９】
２６５１過程でＳＩＰ Ｃｏｒｅ２６１０はＳＩＰｃｌｉｅｎｔ１(２６０５)及び／またはＰＣＲＦから受信したユーザ位置情報を追加することができる。
【０３３０】
２６５３過程でＳＩＰ Ｃｏｒｅ２６０５はＭＣＰＴＴ ｓｅｒｖｅｒ２６２０でＳＩＰメッセージを送信することができる。前記ＳＩＰメッセージにはユーザ位置情報が含まれることができる。２６５５過程でＭＣＰＴＴ ｓｅｒｖｅｒ２６２０はユーザ権限及び／またはユーザ位置をチェックすることができる。ＭＣＰＴＴ ｓｅｒｖｅｒ２６２０はＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２６２５と通信してユーザ権限及び位置をチェックすることができる。ＭＣＴＰＰサーバー２６２０はＡｌｅｒｔメッセージを送信するユーザ権限及び／または位置情報を確認して修正が必要な場合、Ａｌｅｒｔメッセージの情報を修正、追加、削除することができる。
【０３３１】
２６５７過程でＭＣＰＴＴ ｓｅｒｖｅｒ２６２０はＨＳＳ２６３０でユーザ位置情報リクエストを送信することができる。２６５９過程でＨＳＳ２６３０はＭＣＰＴＴ ｓｅｒｖｅｒ２６２０でユーザ位置情報応答を送信することができる。２６５７過程及び２６５９過程は省略されることができる。
【０３３２】
２６６１過程でＭＣＰＴＴ ｓｅｒｖｅｒ２６２０はユーザ位置情報を比べる。ＧＰＳ情報、ＰＣＲＦから獲得された情報、ＨＳＳから獲得された情報のうちの少なくとも一つの情報を比べることができる。ＭＣＰＴＳＳｓｅｒｖｅｒ２６２０はＭＣＰＴＴＡｌｅｒｔメッセージをグループメンバーに送信することができる。
【０３３３】
２６６３過程でＭＣＰＴＴ ｓｅｒｖｅｒ２６２０はＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ２６１０で送信する。２６６５過程でＳＩＰ Ｃｏｒｅ２６１０はＭＣＰＴＴ Ｃｌｉｅｎｔ１(２６０５)でＳＩＰ２００ＯＫを送信する。
【０３３４】
前記のような方法でＡｌｅｒｔメッセージに端末の位置情報を含んで送信することができる。
【０３３５】
図２７乃至図３１でＭＣＰＴＴ端末またはＭＣＯＰＴＴサーバーはＭＣＰＴＴ優先順位サービスを提供することができる。図２７乃至図３１でＭＣＰＴＴ端末またはＭＣＰＴＴサーバーはサービスリクエストを受信する場合、図１８乃至図２２で説明した端末またはサーバーの動作を行うことができる。
【０３３６】
図２７は本実施形態によるグループ呼出しを設定する過程を示す図面である。
【０３３７】
ＭＣＰＴＴ端末は、ＭＣＰＴＴ網を介して緊急(Ｅｍｅｒｇｅｎｃｙ)グループ呼出しを開始することができる。端末からグループ呼出しリクエストを受けたサーバーは当該ユーザがグループ呼出しリクエストができる権限があるか確認する。また、グループ呼出しリクエストを受けたＳＩＰ Ｃｏｒｅはグループ呼出しに該当するリソースを割り当てる。
【０３３８】
図２７を参照すれば、２７４１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２７０５)はＭＣＰＴＴ優先順位サービス(ｐｒｉｏｒｉｔｙ ｓｅｒｖｉｃｅ)を開始する。２７４３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２７０５)はＳＩＰ ＩＮＶＩＴＥをＳＩＰ Ｃｏｒｅ２７１０で送信する。２７４５過程でＳＩＰ Ｃｏｒｅ２７１０はＭＣＰＴＴ ｓｅｒｖｅｒ２７１５でＳＩＰ ＩＮＶＩＴＥを送信する。
【０３３９】
２７４７過程でＭＣＰＴＴ ｓｅｒｖｅｒ２７１５はユーザ権限をチェックする。また、ＭＣＰＴＴ ｓｅｒｖｅｒ２７１５はサービス優先順位をチェックする。ＭＣＰＴＴ ｓｅｒｖｅｒ２７１５はＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２７２０と通信してユーザ権限及びサービス優先順位をチェックすることができる。２７４９過程でＭＣＰＴＴ ｓｅｒｖｅｒ２７１５はチェック結果に基づいてＳＩＰ Ｃｏｒｅ２７１０でＳＩＰ ＩＮＶＩＴＥを送信する。２７５１過程でＳＩＰ Ｃｏｒｅ２７１０はＳＩＰ ＩＮＶＩＴＥをＭＣＰＴＴ Ｃｌｉｅｎｔ２(２７２５)で送信することができる。
【０３４０】
２７５３過程でＭＣＰＴＴ ｓｅｒｖｅｒ２７１５はチェック結果に基づいてＳＩＰ Ｃｏｒｅ２７１０でＳＩＰ ＩＮＶＩＴＥを送信する。２７５５過程でＳＩＰ Ｃｏｒｅ２７１０はＳＩＰ ＩＮＶＩＴＥをＭＣＰＴＴ Ｃｌｉｅｎｔ３(２７３０)で送信することができる。
【０３４１】
２７５７過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２７２５)はＳＩＰ Ｃｏｒｅ２７１０でＳＩＰ２００ＯＫを送信することができる。２７５９過程でＳＩＰ Ｃｏｒｅ２７１０はＭＣＰＴＴ ｓｅｒｖｅｒ２７１５でＳＩＰ２００ＯＫを送信することができる。２７６１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(２７３０)はＳＩＰ Ｃｏｒｅ２７１０でＳＩＰ２００ＯＫを送信することができる。
【０３４２】
２７６３過程でＳＩＰ Ｃｏｒｅ２７１０はＭＣＰＴＴ ｓｅｒｖｅｒ２７１５でＳＩＰ２００ＯＫを送信することができる。
【０３４３】
２７６５過程でＭＣＰＴＴ ｓｅｒｖｅｒ２７１５はＳＩＰ Ｃｏｒｅ２７１０でＳＩＰ２００ＯＫを送信する。２７６７過程でＳＩＰ Ｃｏｒｅ２７１０はベアラーリクエストメッセージをＰＣＲＦ２７３５で送信することができる。ＳＩＰ Ｃｏｒｅ２７１０は高い優先順位のベアラーをリクエストすることができる。２７６９過程でＰＣＲＦ２７３５はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであることができ、専用ベアラーであってもよい。２７７１過程でＰＣＲＦ２７３５はＳＩＰ Ｃｏｒｅ２７１０でベアラー応答メッセージを送信することができる。２７７３過程でＳＩＰ Ｃｏｒｅ２７１０はＭＣＰＴＴ Ｃｌｉｅｎｔ１(２７０５)でＳＩＰ２００ＯＫを送信することができる。
【０３４４】
前記のような方法で緊急グループ呼出しを設定することができる。
【０３４５】
図２８は、本実施形態による一般グループ呼出しを緊急グループ呼出しに変更する過程を示す図面である。
【０３４６】
端末は現在グループ呼出し中の当該グループ呼出しを緊急グループ呼出しに変更することができる。サーバーはユーザが当該リクエストをする権限があるか確認する。ＳＩＰ Ｃｏｒｅは緊急グループ呼出しに当たるようにリソースを変更する。
【０３４７】
図２８を参照すれば、移動通信システムはＣｌｉｅｎｔ１(２８０５)、ＳＩＰ Ｃｏｒｅ２８１０)、ＭＣＰＴＴ ｓｅｒｖｅｒ２８１５、ＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２８２０を含むことができる。また、ＭＣＰＴＴ Ｃｌｉｅｎｔ２(２８２５)、ＭＣＰＴＴ Ｃｌｉｅｎｔ３(２８３０)、ＰＣＲＦ２８３５をさらに含むことができる。
【０３４８】
２８４１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２８０５)はグループ呼出しを実行中である。ＭＣＰＴＴ Ｃｌｉｅｎｔ１(２８０５)はＭＣＰＴＴ Ｃｌｉｅｎｔ２(２８２５)及びＭＣＰＴＴ Ｃｌｉｅｎｔ３(２８３０)とグループ呼出しを実行中である。
【０３４９】
２８４３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２８０５)はＭＣＰＴＴ優先順位サービス(ｐｒｉｏｒｉｔｙ ｓｅｒｖｉｃｅ)を開始する。優先順位サービス(Ｐｒｉｏｒｉｔｙ ｓｅｒｖｉｃｅ)はＭＣＰＴＴｐｒｉｏｒｉｔｙ ｇｒｏｕｐ ｃａｌｌサービであることで仮定する。２８４５過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２８０５)はＳＩＰ ｒｅ−ＩＮＶＩＴＥをＳＩＰ Ｃｏｒｅ２８１０で送信する。２８４７過程でＳＩＰ Ｃｏｒｅ２８１０はＭＣＰＴＴ ｓｅｒｖｅｒ２８１５でＳＩＰ ｒｅ−ＩＮＶＩＴＥを送信する。
【０３５０】
２８４９過程でＭＣＰＴＴ ｓｅｒｖｅｒ２８１５はユーザ権限をチェックする。また、ＭＣＰＴＴ ｓｅｒｖｅｒ２８１５はサービス優先順位をチェックする。ＭＣＰＴＴ ｓｅｒｖｅｒ２８１５はＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２８２０と通信してユーザ権限及びサービス優先順位をチェックすることができる。２８５１過程でＭＣＰＴＴ ｓｅｒｖｅｒ２８１５はチェック結果に基づいてＳＩＰ Ｃｏｒｅ２８１０でＳＩＰ ｒｅ−ＩＮＶＩＴＥを送信する。２８５３過程でＳＩＰ Ｃｏｒｅ２８１０はＳＩＰ ｒｅ−ＩＮＶＩＴＥをＭＣＰＴＴ Ｃｌｉｅｎｔ２(２８２５)で送信することができる。２８５５過程でＭＣＰＴＴ ｓｅｒｖｅｒ２８１５はチェック結果に基づいてＳＩＰ Ｃｏｒｅ２８１０でＳＩＰ ｒｅ−ＩＮＶＩＴＥを送信する。２８５７過程でＳＩＰ Ｃｏｒｅ２８１０はＳＩＰ ｒｅ−ＩＮＶＩＴＥをＭＣＰＴＴ Ｃｌｉｅｎｔ２(２８２５)で送信することができる。
【０３５１】
２８５９過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２８２５)はＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ２８１０でＳＩＰ２００ＯＫを送信する。２８６１過程でＳＩＰ Ｃｏｒｅ２８１０はＭＣＰＴＴ ｓｅｒｖｅｒ２８１５でＳＩＰ２００ＯＫを送信する。２８６３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(２８３０)はＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ２８１０でＳＩＰ２００ＯＫを送信する。２８６５過程でＳＩＰ Ｃｏｒｅ２８１０はＭＣＰＴＴ ｓｅｒｖｅｒ２８１５でＳＩＰ２００ＯＫを送信する。２８６７過程でＭＣＰＴＴ ｓｅｒｖｅｒ２８１５はＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ２８１０で送信する。
【０３５２】
２８６９過程でＳＩＰ Ｃｏｒｅ２８１０はベアラーリクエストメッセージをＰＣＲＦ２８３５で送信することができる。ＳＩＰ Ｃｏｒｅ２８１０は緊急呼出しのための高い優先順位のベアラーをリクエストすることができる。２８７１過程でＰＣＲＦ２８３５はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであってもよく、専用ベアラーであることができる。２８７３過程でＰＣＲＦ２８３５はＳＩＰ Ｃｏｒｅ２８１０でベアラー応答メッセージを送信することができる。２８７５過程でＳＩＰ Ｃｏｒｅ２８１０はＭＣＰＴＴ Ｃｌｉｅｎｔ１(２８０５)でＳＩＰ２００ＯＫを送信することができる。
【０３５３】
前記のような方法で一般グループ呼出しを緊急グループ呼出しに変更することができる。
【０３５４】
図２９は、本実施形態による端末が他のサービス中で緊急グループ呼出しのリクエストを処理する過程を示す図面である。
【０３５５】
緊急グループ呼出しリクエストを受けた端末は当該リクエストを無視して既存のサービスを続くか、既存サービスを止めて緊急グループ呼出しを開始したり。現在サービスと緊急グループ呼出しサービスのうちのいずれか１つ以上のサービスのメディアを修正することができる。
【０３５６】
図２９を参照すれば、移動通信システムはＣｌｉｅｎｔ１(２９０５)、ＳＩＰ Ｃｏｒｅ２９１０、ＭＣＰＴＴ ｓｅｒｖｅｒ２９１５、ＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２９２０を含むことができる。また、ＭＣＰＴＴ Ｃｌｉｅｎｔ２(２９２５)、ＭＣＰＴＴ Ｃｌｉｅｎｔ３(２９３０)、ＰＣＲＦ２９３５をさらに含むことができる。
【０３５７】
２９４１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２９０５)はＭＣＰＴＴｐｒｉｏｒｉｔｙｓｅｒｖｉｃｅを開始する。２９４３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１(２９０５)はＳＩＰ ＩＮＶＩＴＥをＳＩＰ Ｃｏｒｅ２９１０で送信する。２９４５過程でＳＩＰ Ｃｏｒｅ２９１０はＭＣＰＴＴ ｓｅｒｖｅｒ２９１５でＳＩＰ ＩＮＶＩＴＥを送信する。
【０３５８】
２９４７過程でＭＣＰＴＴ ｓｅｒｖｅｒ２９１５はユーザ権限をチェックする。また、ＭＣＰＴＴ ｓｅｒｖｅｒ２９１５はサービス優先順位をチェックする。ＭＣＰＴＴ ｓｅｒｖｅｒ２９１５はＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ２９２０と通信してユーザ権限及びサービス優先順位をチェックすることができる。２９５１過程でＭＣＰＴＴ ｓｅｒｖｅｒ２９１５はチェック結果に基づいてＳＩＰ Ｃｏｒｅ２９１０でＳＩＰ ＩＮＶＩＴＥを送信する。
【０３５９】
２９５３過程でＳＩＰ Ｃｏｒｅ２９１０はＳＩＰ ＩＮＶＩＴＥをＭＣＰＴＴ Ｃｌｉｅｎｔ２(２９２５)で送信することができる。一方、２９４９過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２９２５)とＭＣＰＴＴ Ｃｌｉｅｎｔ３(２９３０)はｐｒｉｖａｔｅ ｃａｌｌを実行中である。ＳＩＰ Ｃｏｒｅ２９１０からＳＩＰ ＩＮＶＩＴＥを受信したＭＣＰＴＴ Ｃｌｉｅｎｔ２(２９２５)は、２９５５過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(２９３０)でＳＩＰ−ｒｅＩＮＶＩＴＥを送信する。２９５７過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(２９３０)はＳＩＰ２００ＯＫをＭＣＰＴＴ Ｃｌｉｅｎｔ２(２９２５)で送信する。２９５９過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２９２５)とＭＣＰＴＴ Ｃｌｉｅｎｔ３(２９３０)のｐｒｉｖａｔｅ ｃａｌｌはホールド状態となる。
【０３６０】
２９６１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(２９２５)はＳＩＰ Ｃｏｒｅ２９１０でＳＩＰ２００ＯＫを送信する。２９６３過程でＳＩＰ Ｃｏｒｅ２９１０はＭＣＰＴＴ ｓｅｒｖｅｒ２９１５でＳＩＰ２００ＯＫを送信する。２９６５過程でＭＣＰＴＴ ｓｅｒｖｅｒ２９１５はＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ２９１０で送信する。
【０３６１】
２９６７過程でＳＩＰ Ｃｏｒｅ２９１０はベアラーリクエストメッセージをＰＣＲＦ２９３５で送信することができる。ＳＩＰ Ｃｏｒｅ２９１０は緊急呼出しのための高い優先順位のベアラーをリクエストすることができる。２９６９過程でＰＣＲＦ２９３５はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであってもよく、専用ベアラーであってもよい。２９７１過程でＰＣＲＦ２９３５はＳＩＰ Ｃｏｒｅ２９１０でベアラー応答メッセージを送信することができる。２９７３過程でＳＩＰ Ｃｏｒｅ２９１０はＭＣＰＴＴ Ｃｌｉｅｎｔ１(２９０５)でＳＩＰ２００ＯＫを送信することができる。
【０３６２】
前記のような方法で他のサービス株緊急グループ呼出しがリクエストされることができる。
【０３６３】
端末は緊急グループ呼出しサービスをリクエストする前に当該グループメンバーにＡｌｅｒｔメッセージを送信することができる。すなわち、端末は図２３乃至図２６で記述した方法のうちの一つでＡｌｅｒｔメッセージを送信し、図２７乃至図２９で記述した方法のうちの一つで緊急グループ呼出しサービスをリクエストするようになる。
【０３６４】
図３０は、本実施形態による緊急グループ呼出しリクエストメッセージにＡｌｅｒｔメッセージを含んで送信する過程を示す図面である。
【０３６５】
図３０を、参照すれば、移動通信システムはＭＣＰＴＴ Ｃｌｉｅｎｔ１３００５、ＳＩＰ Ｃｏｒｅ３０１０、ＭＣＰＴＴ ｓｅｒｖｅｒ３０１５、ＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ３０２０を含むことができる。また、ＭＣＰＴＴ Ｃｌｉｅｎｔ２３０２５、ＭＣＰＴＴ Ｃｌｉｅｎｔ３(３０３０)をさらに含むことができる。
【０３６６】
３０４１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１３００５はＭＣＰＴＴｐｒｉｏｒｉｔｙｇｒｏｕｐｔｃａｌｌ動作を開始する。３０４３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１３００５はＳＩＰ Ｃｏｒｅ３０１０でＳＩＰ ＩＮＶＩＴＥメッセージを送信する。本実施形態において、ＭＣＰＴＴ Ｃｌｉｅｎｔ１３００５はＳＩＰ ＩＮＶＩＴＥメッセージにＡｌｅｒｔメッセージを共に送信することができる。Ａｌｅｒｔメッセージが含まれたＳＩＰ ＩＮＶＩＴＥメッセージをＳＩＰ ＩＮＶＩＴＥ ｗ／Ａｌｅｒｔで表記する。
【０３６７】
３０４５過程でＳＩＰ Ｃｏｒｅ３０１０は前記ＳＩＰ ＩＮＶＩＴＥ ｗ／ＡｌｅｒｔをＭＣＰＴＴ ｓｅｒｖｅｒ３０１５で送信することができる。３０４７過程でＭＣＰＴＴ ｓｅｒｖｅｒ３０１５はユーザ権限をチェックする。また、ＭＣＰＴＴ ｓｅｒｖｅｒ３０１５はサービス優先順位をチェックする。ＭＣＰＴＴ ｓｅｒｖｅｒ３０１５はＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ３０２０と通信してユーザ権限及びサービス優先順位をチェックすることができる。３０４９過程でＭＣＰＴＴ ｓｅｒｖｅｒ３０１５はチェック結果に基づいてＳＩＰ Ｃｏｒｅ３０１０でＳＩＰ ＩＮＶＩＴＥ ｗ／Ａｌｅｒｔを送信する。
【０３６８】
３０５１過程でＳＩＰ Ｃｏｒｅ３０１０はＳＩＰ ＩＮＶＩＴＥ ｗ／ＡｌｅｒｔをＭＣＰＴＴ Ｃｌｉｅｎｔ２３０２５で送信することができる。３０５３過程でＭＣＰＴＴ ｓｅｒｖｅｒ３０１５はチェック結果に基づいてＳＩＰ Ｃｏｒｅ３０１０でＳＩＰ ＩＮＶＩＴＥを送信する。３０５５過程でＳＩＰ Ｃｏｒｅ３０１０はＳＩＰ ＩＮＶＩＴＥ ｗ／ＡｌｅｒｔをＭＣＰＴＴ Ｃｌｉｅｎｔ３(３０３０)で送信することができる。
【０３６９】
３０５７過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２３０２５はＳＩＰ Ｃｏｒｅ３０１０でＳＩＰ２００ＯＫを送信することができる。３０５９過程でＳＩＰ Ｃｏｒｅ３０１０はＭＣＰＴＴ ｓｅｒｖｅｒ３０１５でＳＩＰ２００ＯＫを送信することができる。３０６１過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(３０３０)はＳＩＰ Ｃｏｒｅ３０１０でＳＩＰ２００ＯＫを送信することができる。
【０３７０】
３０６３過程でＳＩＰ Ｃｏｒｅ３０１０はＭＣＰＴＴ ｓｅｒｖｅｒ３０１５でＳＩＰ２００ＯＫを送信することができる。
【０３７１】
３０６５過程でＭＣＰＴＴ ｓｅｒｖｅｒ３０１５はＳＩＰ Ｃｏｒｅ３０１０でＳＩＰ２００ＯＫを送信する。３０６７過程でＳＩＰ Ｃｏｒｅ３０１０はベアラーリクエストメッセージをＰＣＲＦ３０３５で送信することができる。ＳＩＰ Ｃｏｒｅ３０１０は高い優先順位のベアラーをリクエストすることができる。３０６９過程でＰＣＲＦ３０３５はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであってもよく、専用ベアラーであってもよい。３０７１過程でＰＣＲＦ３０３５はＳＩＰ Ｃｏｒｅ３０１０でベアラー応答メッセージを送信することができる。３０７３過程でＳＩＰ Ｃｏｒｅ３０１０はＭＣＰＴＴ Ｃｌｉｅｎｔ１３００５でＳＩＰ２００ＯＫを送信することができる。
【０３７２】
図３１は、本実施形態による一般グループ呼出し中でＡｌｅｒｔメッセージを受信して緊急グループ呼出しで転換する過程を示す図面である。
【０３７３】
ＡｌｅｒｔメッセージはＳＩＰメソッド(ＳＩＰ ＭＥＳＳＡＧＥ、ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹなど) 及びＳＩＰ以外のプロトコル(ＨＴＴＰ、ＳＭＳなど)が可能である。当該Ａｌｅｒｔメッセージを受けたＳＩＰ Ｃｏｒｅは一般グループ呼出しに割り当てられたリソースを緊急グループ呼出しに該当するように修正する。
【０３７４】
図３１を参照すれば、移動通信システムはＭＣＰＴＴ Ｃｌｉｅｎｔ１３１０５、ＳＩＰ Ｃｏｒｅ３１１０、ＭＣＰＴＴ ｓｅｒｖｅｒ３１１５、ＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ３１２０を含むことができる。また、ＭＣＰＴＴ Ｃｌｉｅｎｔ２(３１２５)、ＭＣＰＴＴ Ｃｌｉｅｎｔ３(３１３０)をさらに含むことができる。
【０３７５】
３１４１過程で通信システムのエンティティーは一般グループ呼出しを実行中である。
【０３７６】
３１４３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１３１０５はＭＣＰＴＴＡｌｅｒｔ動作を開始する。
【０３７７】
３１４５過程でＭＣＰＴＴ Ｃｌｉｅｎｔ１３１０５はＳＩＰ Ｃｏｒｅ３１１０でＳＩＰメッセージを送信する。前記ＳＩＰメッセージは端末の位置情報、ユーザＩＤ、グループＩＤ、所属団体情報を含むことができる。３１４７過程でＳＩＰ Ｃｏｒｅ３１１０は前記ＳＩＰメッセージをＭＣＰＴＴ ｓｅｒｖｅｒ３１１５で伝達することができる。
【０３７８】
３１４９過程でＭＣＰＴＴ ｓｅｒｖｅｒ３１１５はユーザ権限及び／またはユーザ位置をチェックすることができる。ＭＣＰＴＴ ｓｅｒｖｅｒ３１１５はＭＣＰＴＴ Ｇｒｏｕｐ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ３１２０と通信してユーザ権限及び位置をチェックすることができる。ＭＣＴＰＰサーバー３１１５はＡｌｅｒｔメッセージを送信するユーザ権限及び／または位置情報を確認して修正が必要な場合、Ａｌｅｒｔメッセージの情報を修正、追加、削除することができる。
【０３７９】
３１５１過程でＭＣＰＴＴ ｓｅｒｖｅｒ３１１５はＳＩＰメッセージをＳＩＰ Ｃｏｒｅ３１１０で送信する。前記ＳＩＰメッセージはＭＣＰＴＴ ｓｅｒｖｅｒ３１１５で一部情報が修正、追加、削除されたメッセージであってもよい。３１５３過程でＳＩＰ Ｃｏｒｅ３１１０は、３１５１過程で受信したＳＩＰメッセージに基づいてＭＣＰＴＴ Ｃｌｉｅｎｔ２(３１２５)でＳＩＰメッセージを送信する。３１５５過程でＭＣＰＴＴ ｓｅｒｖｅｒ３１１５はＳＩＰメッセージをＳＩＰ Ｃｏｒｅ３１１０で送信する。前記ＳＩＰメッセージはＭＣＰＴＴ ｓｅｒｖｅｒ３１１５で一部情報が修正、追加、削除されたメッセージであってもよい。３１５７過程でＳＩＰ Ｃｏｒｅ３１１０は、３１５５過程で受信したＳＩＰメッセージに基づいてＭＣＰＴＴ Ｃｌｉｅｎｔ２(３１２５)でＳＩＰメッセージを送信する。
【０３８０】
３１５９過程でＭＣＰＴＴ Ｃｌｉｅｎｔ２(３１２５)はＳＩＰ Ｃｏｒｅ３１１０でＳＩＰ２００ＯＫを送信する。３１６１過程でＳＩＰ Ｃｏｒｅ３１１０は、３１５９過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴ ｓｅｒｖｅｒ３１１５で送信する。
【０３８１】
３１６３過程でＭＣＰＴＴ Ｃｌｉｅｎｔ３(３１３０)はＳＩＰ Ｃｏｒｅ３１１０でＳＩＰ２００ＯＫを送信する。３１６５過程でＳＩＰ Ｃｏｒｅ３１１０は、３１６３過程で受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＭＣＰＴＴ ｓｅｒｖｅｒ３１１５で送信する。
【０３８２】
３１６７動作でＭＣＰＴＴ ｓｅｒｖｅｒ３１１５は受信したＳＩＰ２００ＯＫに基づいてＳＩＰ２００ＯＫをＳＩＰ Ｃｏｒｅ３１１０で送信する。３１６９過程でＳＩＰ Ｃｏｒｅ３１１０はベアラーリクエストメッセージをＰＣＲＦ３１３５で送信することができる。ＳＩＰ Ｃｏｒｅ３１１０は高い優先順位のベアラーをリクエストすることができる。３１７１過程でＰＣＲＦ３１３５はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであってもよく、専用ベアラーであってもよい。３１７３過程でＰＣＲＦ３１３５はＳＩＰ Ｃｏｒｅ３１１０でベアラー応答メッセージを送信することができる。
【０３８３】
３１７５過程でＳＩＰ Ｃｏｒｅ３１１０はＭＣＰＴＴ Ｃｌｉｅｎｔ１３１０５でＳＩＰ２００ＯＫを送信することができる。以後、３１７７過程で一般グループ呼出し中のエンティティーは緊急グループ呼出しで転換される。各エンティティーはＭＣＰＴＴｐｒｉｏｒｉｔｙｇｒｏｕｐｃａｌｌを行うことができる。
【０３８４】
前記のような方法で一般グループ呼出し中の端末らがＡｌｅｒｔメッセージを受信した後緊急呼出しで転換することができる。
【０３８５】
図３２は、本実施形態による端末を示す図面である。
【０３８６】
図３２を参照すれば、本発明の端末３２００は送受信部３２１０及び制御部３２３０を含むことができる。送受信部３２１０は受信機及び送信機を含むことができる。送受信部は他のネットワークエンティティーと信号を送受信することができる。前記信号は制御情報とデータ及びパイロットのうちの少なくとも一つを含むことができる。制御部３２３０は端末の全般的な動作を制御することができる。
【０３８７】
送受信部３２１０は送信される信号の周波数を上昇変換及び増幅するＲＦ送信機と、受信される信号を低雑音増幅して周波数を下降変換するＲＦ受信機などから構成されることができる。また、送受信部は無線チャンネルを介して信号を受信して制御部３２３０に出力し、制御部３２３０から出力された信号を無線チャンネルを介して送信することができる。
【０３８８】
例えば、制御部３２３０はＭＣＰＴＴサーバーから第１サービスリクエストを受信し、前記第１サービスリクエストに対応する第１サービスと現在実行中の第２サービスが同時に提供しするか否かを判断し、同時に提供可能ではないことで判断すると、前記各サービスに係る優先順位に基づいて各サービスを処理するように制御することができる。
【０３８９】
また、前記制御部３２３０は前記各サービス中で後順位サービスに対するメディアを調整して前記各サービスを処理するように制御することができる。この時、前記調整は前記後順位サービスを終了、拒絶、先順位サービスの終了時までホールド、先順位サービスのメディアと同時に提供可能なサービスで変換、または予め設定された他の端末にフォワーディングする動作中の少なくとも一つを含むことができる。また、優先順位はユーザ別に優先順位、グループ別優先順位またはサービス別の優先順位中の少なくとも一つを含むことができる。
【０３９０】
一方、端末３２００及び制御部３２３０の動作及び機能は図３２で言及した内容に限定しない。制御部３２３０は上述した本発明の実施形態によって端末３２００が動作するように一連の過程を制御することができる。
【０３９１】
図３３は、本実施形態によるＭＣＰＴＴサーバーの構造を示すブロック図である。
【０３９２】
図３３を参照すれば、本発明のＭＣＰＴＴサーバー３３００は送受信部３３１０及び制御部３３３０を含むことができる。送受信部は受信機及び送信機を含むことができる。送受信部３３１０は他のネットワークエンティティーと信号を送受信することができる。制御部３３３０は前記ＭＣＰＴＴサーバー３３００の全般的な動作を制御することができる。
【０３９３】
本発明の実施形態によれば、制御部３３３０は第１端末から第２端末に対する第１サービスリクエストを受信し、前記第２端末で前記第１サービスリクエストに対応する第１サービスと現在第２端末で実行中の第２サービスが同時に提供可能である否かを判断し、同時に提供可能ではないと判断すれば、前記各サービスに係る優先順位に基づいて各サービスの処理を決定し、前記決定に基づいて前記第２端末でサービスリクエストメッセージを送信するように制御することができる。
【０３９４】
また、前記制御部３３３０は前記各サービス中の後順位サービスに対するメディアを調整するように制御することができる。前記調整は前記後順位サービスを終了、拒絶、先順位サービスの終了時までホールド、先順位サービスのメディアと同時に提供可能なサービスで変換、または予め設定された他の端末にフォワーディングするように処理する動作中の少なくとも一つを含むことができる。前記優先順位は、ユーザ別の優先順位、グループ別優先順位またはサービス別の優先順位のうちの少なくとも一つを含むことができる。
【０３９５】
また、前記制御部３３３０は前記第１端末からフロアリクエスト(ｆｌｏｏｒ ｒｅｑｕｅｓｔ)メッセージを受信し、前記第２端末からフロアリクエストメッセージを受信し、前記第１端末と前記第２端末の優先順位に基づいて先順位端末に前記フロアグラント(ｆｌｏｏｒ ｇｒａｎｔ)メッセージを送信するように制御することができる。
【０３９６】
また、前記制御部３３３０は前記サービスリクエストがグループサービスをリクエストの場合、前記グループサービスに対するグループサービス対象端末の数が予め設定された臨界条件を満足するか判断し、前記臨界条件判断結果に基ついで前記グループサービスをマルチキャストまたはユニキャスト方法で提供するか否かを決定するように制御することができる。
【０３９７】
一方、ＭＣＰＴＴサーバー３３００及び制御部３３３０の動作及び機能は図３３で言及した内容で限定しない。制御部１６３０は、上述した本発明の実施形態によってＭＣＰＴＴサーバー１６００が動作するように一連の過程を制御することができる。
【０３９８】
一方、図２３乃至図３１で各エンティティーは各エンティティーを制御するための制御部及び各エンティティーが他のネットワークエンティティーと信号を送受信するための送受信部を含んでいる。
【０３９９】
本発明の実施形態によれば、リレー端末はＰＤＮ接続を生成して端末−ネットワークリレーを効果的に行うことができる。
【０４００】
本明細書及び図面に開示された実施形態は本発明の内容を容易に説明し、理解を助けるために特定例を提示したものであって、本発明の範囲を限定しようとするものではない。したがって、本発明の範囲はここに開示された実施形態以外にも本発明の技術的思想に基づいて導出されるすべての変更または変形された形態が本発明の範囲に含まれることに解釈されなければならない。
【符号の説明】
【０４０１】
５００  送受信部
５１０  制御部
５２０  記憶部
６４０  ゲートウェー
１０００  送受信部
１０１０  制御部
１０２０  記憶部
１２００  端末
１２１０  端末
１２２０  端末
１３００  発言ノタメノプッシュボタン
１３０２  ボタン
１３２０  モデム
１３５０  送受信部
１３６０  制御部
２１１０  サーバー
２１２０  Ｃｌｉｅｎｔ
２１３０  Ｃｌｉｅｎｔ
３２００  端末
３２１０  送受信部
３２３０  制御部
３３００  サーバー
３３１０  送受信部
３３３０  制御部
【図１】
0006791885.tif 000003
【図２】
0006791885.tif 000004
【図３】
0006791885.tif 000005
【図４】
0006791885.tif 000006
【図５】
0006791885.tif 000007
【図６】
0006791885.tif 000008
【図７】
0006791885.tif 000009
【図８】
0006791885.tif 000010
【図９】
0006791885.tif 000011
【図１０】
0006791885.tif 000012
【図１１】
0006791885.tif 000013
【図１２】
0006791885.tif 000014
【図１３ａ】
0006791885.tif 000015
【図１３ｂ】
0006791885.tif 000016
【図１４】
0006791885.tif 000017
【図１５】
0006791885.tif 000018
【図１６】
0006791885.tif 000019
【図１７】
0006791885.tif 000020
【図１８】
0006791885.tif 000021
【図１９】
0006791885.tif 000022
【図２０】
0006791885.tif 000023
【図２１】
0006791885.tif 000024
【図２２】
0006791885.tif 000025
【図２３】
0006791885.tif 000026
【図２４】
0006791885.tif 000027
【図２５】
0006791885.tif 000028
【図２６】
0006791885.tif 000029
【図２７】
0006791885.tif 000030
【図２８】
0006791885.tif 000031
【図２９】
0006791885.tif 000032
【図３０】
0006791885.tif 000033
【図３１】
0006791885.tif 000034
【図３２】
0006791885.tif 000035
【図３３】
0006791885.tif 000036