添付された図面を参照する次の説明は、請求範囲及びこの等価物により定義されるような本開示の多様な実施形態の包括的な理解を助けるために提供される。本発明の実施形態は本発明の理解を助けるために多様な特定詳細事項を含むが、これらはただ例示的なことで見なされなければならない。したがって、本技術分野の通常の技術を有する者であれば本明細書に記載された多様な実施形態の多様な変更及び修正が本発明の範囲及び思想から逸脱せず成ることができるということを認識するだろう。さらに、公知された機能及び構成に対する説明は明確性及び簡潔性のために省略されることができる。
次の詳細な説明及び請求範囲で用いられた用語及び単語は、書誌意味に限定されず、ただ本発明の明確で一貫性ある理解のために用いられる。したがって、本発明の多様な実施形態に対する次の説明は、ただ例示を目的と提供され、添付された請求範囲及びこの等価物により定義される本発明を制限するための目的ではないということが当業者に明白であろう。
単数形態“a”、“an”及び“the”は文脈がはっきり異なり指示しなければ複数の対象を含むことに理解されなければならない。したがって、例えば、“構成要素表面”に対する言及はこのようなの1つ以上に表面に対する言及を含む。
本明細書では、“UE(user equipment)”という用語は、“端末”、“UE装置”などと交換可能である。用語“進化したノードB(eNB)”は“基地局”などと交換可能である。
<第1実施形態>
現在までの無線通信システムの発展は、主にユーザと基地局もしくはネットワーク装備との接続及び通信に基づいてサービスを提供して来た。近年、無線通信システムを用いて端末間の直接通信をするための機器間の通信(Device−to−device、D2D)技術に対する関心が増加しつつあり、これを近接サービス(Proximity−based services、ProSe)と称することができる。
ProSeユーザは、端末(user equipment(ユーザ装備)、UE、terminalなどと混用可能)間の信号を交換しながらサービスを用いることができる。例えば、関心あるユーザをサーチするために探索(Discovery)動作を行うか、関心あるユーザと通信(Communication)するための動作を行うことができる。ProSeは商業的用途として用いられ、または公衆安全サービス(Public Safety)のために用いられる。
ProSeユーザは、周波数リソースを使用するから、ProSeサービスは基地局及びネットワーク装備の助けを受けて提供されることができる。より具体的に、基地局及びネットワークはユーザが使用する無線リソースを割り当てることができ、ユーザは割り当てられた無線リソースを介してデータを送受信することができる。
ProSe端末は、ProSeに対する制御を担当するProSeファンクション(Function)というネットワーク装置(Network Entity)とLTE網を介して接続される。ProSe Functionは、ProSe端末が用いるサービス(直接探索(DirectDiscovery)、直接通信(Direct Communication)、端末−ネットワークリレー(UE−to−network relay)など)を提供するための交渉及びパラメーターを管理、提供する役目を行う。ProSe Functionには基地局(進化したノードB、evolved NodeB、eNBと混用可能)及びコア核心網(Core Network、コアネットワークと混用されることができる)と接続されたインターフェースがなくProSe端末のユーザに対するプロフィール(Profile)は、HSS(Home Subscriber Server)と交渉して獲得したり自体的に記憶することができる。ProSe FunctionはProSe端末がLTEネットワークで用いることができるパラメーターを提供することができ、例えば、無線リソース(Radio resource)情報、特定PLMN(Publicl and Mobile Network)に対してProSeサービスを用いることができるか(Authorization)に対する情報、ProSe Functionと接続するためのアクセスポイントネーム(Access Point Name、APN)などがある。
ProSeにおいてProSe制御部を意味するProSe Functionは、ProSe可能(ProSe−enable)端末との交渉を介してProSe−enable端末がProSeのために用いることができる情報を提供する。ProSe端末は、ネットワークカバレッジ内部に位置する場合、ネットワーク接続を介してProSe Functionと交渉したり基地局により提供される無線リソースを介してProSe端末どうし直接探索もしくは直接通信を行うことができる。
また、ネットワークカバレッジ内部に位置する端末は近くの端末がネットワークカバレッジ外部に位置する場合、端末−ネットワークリレー機能を行ってネットワークカバレッジ外部に位置する端末(リモート(Remote)UE)にネットワーク接続を提供することができる。
ProSeでは公衆安全サービスのために基地局のカバレッジ外部に位置する端末(以下、リモートUE)とリレー(Relay)を介してネットワークに接続することができる機能を提供する。基地局はカバレッジの外に移動することで期待する端末を潜在的リモートUEと見なすことができ、端末が基地局に提供する測定(measurement)情報でこれを判断することができる。リモートUEは探索動作を介してリレー機能を提供する端末(以下、リレーUE)を探索するようになり、リレーUEと直接通信接続を確立する。
リレーUEは、IPアドレスが割り当てられるデリゲート(Delegate)役目を行ってリモートUEにIPアドレスを割り当てる。リモートUEとリレーUEとの接続は一対一直接通信(one−to−one direct communication)方法を用いることができる。リモートUEは、前記接続を介してリレーUEを経てネットワークに接続することができる。リモートUEはパケットをリレーUEに伝達し、リレーUEはリレーパケットを伝達するためのパケットネットワーク接続を介して当該データをネットワークへ送信する。また、リレーUEはネットワークからリモートUEに伝達されるパケットをリレー接続を確立した直接通信を介して伝達することができる。
本実施形態の全般にかけてProSeは端末対端末の探索及び通信サービスのうちのいずれか一つを示す。本実施形態は3GPPで定義した長期間進化(Long Term Evolution、LTE)システムに基づいて説明しているが、無線近距離通信網(wireless LAN(local area network)、WLAN)、ブルートゥース(登録商標)(Bluetooth(登録商標))など無線通信全般で類似に用いられることができる。本実施形態において公衆安全サービスのためのProSe機能中の一つである端末−網リレー機能をサポートするためにコアネットワークと基地局間のリレー関連情報を交換する方法及び装置、そして基地局でリレー機能をサポートするために端末を制御する方法及び装置を提案する。
本発明の用語は本発明における機能を考慮して定義された用語とし、これはユーザ、運用者の意図または慣例などによって変わることができる。また、本実施形態を具体的に説明するにおいて、3GPPが規格を定めた無線接続網、コアネットワークであるLTEと進化したパケットコア(Evolved Packet Core、EPC)を主な対象とするが、本実施形態の主な要旨は類似の技術的背景を有するそのほかの通信システムにも本実施形態の範囲を大きく逸脱せず範囲で僅かの変形で適用可能であり、これは本実施形態の技術分野で熟練された技術的知識を有する者の判断で可能であろう。本実施形態に係るD2Dサービスは機器間の通信をサポートするサービスを総称し、3GPP標準技術のProSeなどがその例示である。本発明において前述したD2DシステムはProSeと称する。
図1は、ProSe端末がリレー役目を行うためにAttach手続きを行う方法を示した図面である。
図1によれば、ProSe端末はリレー役目を行うために網にリレーであることを通知しながらAttach手続きを行い、その手続きを介してコアネットワークは基地局に当該端末のリレー実行に対する情報を提供することができる。また、基地局が前記情報に基づいてリレー端末を選択し、カバレッジの外に移動することで予想される端末にリレーを探索するようにトリガーすることができる。
ProSe利用端末であるUE2(110)は、ネットワークに接続するためにネットワーク装置中の移動性管理装置であるMME(Mobility Management Entity)130でAttach Requestを送信する(s100)。前記端末は、Attach Requestメッセージを用いて自分がリレー動作を行う端末もしくはリレー動作が可能な端末であることを次のような方法で通知することができる。第1に、Attach RequestメッセージのType情報領域に自分がリレー動作を行うことができるというインジケータ(indication)を含むことができる。第2にAttach RequestメッセージのAPN情報領域にリレー用PDN(Packet Data Network)接続のためのAPNを設定することができる。前記リレー用PDNConnectionのためのAPNはProSe端末がProSe動作のためにProSe Functionとサービス認可(Service Authorization)手続きを行う時、ProSe Functionから提供されることができる。または、ProSe端末のUICC(Universal IC Card)に予め設定された値を用いることができる。第3にAttach RequestメッセージのUE network Capability情報領域にリレー能力(Relay Capability)を示すインジケータを設定することができる。第4にAttach RequestメッセージのDevice Property情報領域にProSeリレー端末であることを示すインジケータを設定することができる。UE2は前記4つ方法のうちの少なくとも一つ以上を用いて自分がProSeリレー端末であることを通知することができる。
前記の4つの方法のうちの少なくとも一つ以上を用いて構成されたAttach Requestメッセージを受信したMME130は、前記の4つの方法に対する情報領域に基づいてAttach Requestを送信した端末がProSe端末−ネットワークリレーを行う端末であることを認知することができる。MMEはAttach Requestメッセージを参照してリレー用PDN接続のためのAPN値がAPN情報領域に設定された場合、当該端末がリレー用ベアラー(Bearer)が必要と判断することができる。同様にAttach RequestメッセージのTypeがリレーを示すと、その端末にリレー動作のためのベアラーコンテクスト(Bearer context)を決定することができる。また、Attach RequestメッセージのUE network Capabilityに端末のRelay capabilityが表示されているか、Device Propertyにリレー端末であることが設定されていると、その端末がProSeリレーサービスを用いる場合に備えてProSeリレートラフィック送信に適合したベアラーコンテクストを決定することができる。
MME130は、Attach Requestを送信したUE2(110)がリレーを行っても良いサブスクリプション(subscription)を持っているか確認するためにHSSと交渉してUEのサブスクリプション情報を確認し、リレー機能のための端末コンテクスト(Context)を獲得することができる(s105)。端末コンテクストは、UEがリレー役目を行うことができるかに対する情報、リレー用ベアラー接続を確立する時に用いられるARP(Allocation and Retention Priority)、QCI(QoSClassIdentifier)、UE−AMBR(Aggregate Maximum Bit Rate)、リレー用APNに対するAPN−AMBRなどを含むことができる。MMEがAttach Requestを送信したUE2がリレーを行うのに必要なサブスクリプション情報を持っていると、前記HSSとのネゴシエーションを省略することができる。
MME130は、Attach Requestを送信した端末にベアラー接続を提供するためにS−GW(Serving Gateway)/P−GW(PDN Gateway)140でCreate Session Requestを送信する(s110)。追加的に前記Create Session Request送信時のリレー用ベアラー接続確立を他のベアラー接続確立より先ず処理することができ、このためにS−GW/P−GWで当該リクエストを速やかに処理するようにCreate Session RequestメッセージのIndication FlagあるいはSignaling Priority Indication、もしくはベアラーコンテクストのQoS値に高い優先順位を有する値を含んで送信することができる。前記メッセージを受信したS−GW/P−GWは、Indication flagもしくはSignaling Priority Indicationを確認して他の端末またはMMEからのリクエストよりさらに優先的にメッセージを処理することができ、または、ベアラー情報でQoS値を確認してリレーサービスのために提供することができるQCIまたはARP値を持つと、前記リクエストを優先的に処理しなければならないと判断することができる。
S−GW/P−GW140は、Create Session Responseで前記Create Session Requestに対する応答を行い(s115)、これを受信したMME130はInitial Context SetupRequestにAttach Acceptメッセージとベアラーコンテクスト情報を含んでeNBに伝達する(s120)。
前記120段階によってMME130は、前記Initial Context Setup RequestのProSe authorized情報領域にProSe端末−ネットワークリレー値を設定して当該UEがProSe端末−ネットワークリレーを用いる端末であることをeNB120に通知することができる。または、MMEはE−TRABtobesetuplist情報領域のE−RAB level QoS parameterにリレー用QCI値あるいはARP値を設定してeNBが当該UEがリレーを用いることができることを認知する。前記のような方法でInitial Context Setup Requestを受信したeNBはUE2(110)がProSe UE to Networkリレーを用いる端末であることを認知する。
eNB120は、UE2(110)にRRC Connection ReconfigurationメッセージでAttach Acceptを伝達し(s125、Initial Context Setup Requestにあるベアラーコンテクストに基づいて端末とeNB間のベアラー接続を確立するようになる(s130)。端末とeNB間のベアラー接続が確立されると、eNBはInitial context Setup responseをMME130に送信してベアラーが設定されたことを通知し(s135)、MMEはS−GW/P−GW140にModify Bearer Requestを送信してeNBとS−GW/P−GW間のベアラー接続を確立する。UE2はAttach CompleteメッセージをMMEに送信してAttach手続きを終了する(s140)。
前記140段階による結果でProSeリレーを行う端末に対する情報を獲得したeNB120は当該端末のコンテクストを記憶する(s150)。前記情報は端末がProSe端末−ネットワークリレー動作を行うことができるという許可(Authorization)情報及び/または端末がProSe端末−ネットワークリレー動作を行うことができる能力(capability)を持っていることを指示(Indication)する情報であってもよい。
eNB120はProSe端末−ネットワークリレーサービスを提供するためにリレーUEを選択することができる(s155)。eNBは前記155段階を介してMMEから伝達された特定UEに対するリレー実行許可もしくはリレー実行指示に基ついて特定UEをリレーUEで選択することができる。eNBはリレーUEを選択する動作のために専用の(Dedicated) 無線リソース制御(Radio Resource Control、RRC)シグナリング(signaling)を利用したりシステム情報ブロック(System Information Block、SIB)ブロードキャスト(broadcast)を用いることができる。例えば、eNBはUE2(110)にdedicated RRC Signalingを用いてリレーUEであることを通知することができる。
Dedicated RRC Signalingを用いる場合、eNB120は特定端末に対するRRCメッセージをC−RNTIで区分して伝達することができる。eNBはこのRRCメッセージに当該UEがリレー動作を行うことができるという許可情報を含むか、当該UEがリレー動作を行うようにトリガーするインジケータを含むことができる。または、このRRCメッセージにリレーのために用いるリソースプール(Resource Pool)を伝達することができ、前記RRCメッセージを受信したUEはリレー用リソースプールに係る情報がRRCメッセージに含まれていると、リレーを行うように指示を受けたと判断したり、リレーを行うように許可を受けたと判断することができる。
eNB120がSIB broadcastを用いてリレーを選択する場合、SIBメッセージにリレー役目を行う端末のC−RNTIを含んでブロードキャストすることができる。もしくはeNBはSIBメッセージにリレーのためのリソースプール情報を含ませることができ、リレー機能を行うことができるUEは前記リソースプール情報を参照してリレー動作可否を決定したり、もしくはリレーリソースプールが明示された場合、動作上の手続きでリレー機能実行を開始することができる。
eNB120は自分がサービスするセル(cell)に位置した端末に測定報告(Measurement report)を受信するようになるのに、この測定報告に基づいて端末が受信する信号の強度が特定しきい値(threshold)以下であることが分かるようになれば、当該端末が直ちにネットワークカバレッジを外れるようになると判断することができる。便宜上、このUEを潜在的リモートUE(Potential RemoteUE)と称する。
この場合、eNB120は前記測定報告を送信した端末がProSe端末−ネットワークリレーサービスを用いることができるためにリレー探索動作を行うようにトリガーすることができる(s160)。例えば、eNBは測定報告を送信したUE1(100)の信号の強度が特定しきい値以下であればリレー探索動作を行うようにトリガーすることができる。前記トリガー動作を行う前に、eNBは自分がサービスするUEのうちのリレー動作を行うことができるか、リレー動作を行うように許可を受けたUEがあるか確認し、少なくとも1個以上のUEが前記確認手続きに符合すると判断される場合、潜在的リモートUEにリレー探索手続きを開始するようにトリガーすることができる。この動作はリレー可能端末がないにもかかわらず潜在的リモートUEにリレー探索を開始するようにする不必要な動作を無くすためである。端末はeNBからしきい値を受信する代わりにProSe Functionから伝達されたしきい値を用いてリレー探索可否を判断することができる。
eNBが潜在的リモートUEがリレー探索を行うようにトリガーする方法は、第1にdedicated RRCメッセージを使用したり、第2にSIBを介してBroadcastする方法がある。第1にdedicated RRCメッセージを使用する場合、潜在的リモートUEにセル信号強度に対するしきい値を提供して潜在的リモートUEが行ったセル信号に対する測定値が前記しきい値以下であればリレー探索過程を行うようにできる。前記セル信号は、eNB120がブロードキャストするSIB signalingの信号強度であるか、もしくはD2Dのためのサイドリンク(Side link)信号の強度であってもよい。もしくはeNBはdedicated RRCメッセージにリレー探索を指示する識別子を含んで潜在的リモートUEに伝達することができ、これを受信した潜在的リモートUEはリレー探索を行う。
eNBがSIBを介してリレー探索をトリガーする場合、セル信号強度に対するしきい値をSIB情報で提供して潜在的リモートUEが行ったセル信号に対する測定値が前記しきい値以下であればリレー探索を行うようにできる。前記セル信号はeNBがブロードキャストするSIB signalingの信号強度であるか、もしくはD2Dのためのサイドリンク信号の強度であってもよい。前記しきい値は予め定まるか、またはeNB、もしくはProSe Functionが端末に通知することができる。
図2は、ProSe端末がリレー役目を行うためにPDN接続確立手続きを行う方法を示した図面である。
図2によれば、ProSe端末はリレー役目を行うためにネットワークにリレーであることを通知しながらリレー用PDN接続確立手続きを行い、その手続きを介してコアネットワークは基地局に当該端末のリレー実行に係る情報を提供し、基地局は前記情報に基づいてリレー端末を選択してカバレッジの外に移動することで予想される端末にリレーを探索するようにトリガーすることができる。
ProSe利用端末であるUE2(110)はネットワークにPDN接続を確立するためにネットワーク装置中の移動性管理装置であるMME130にPDN Connectivity Requestメッセージを送信する(s200)。前記端末はPDN Connectivity Requestメッセージを用いて自分がリレー動作を行う端末、もしくはリレー動作が可能な端末であることを次のような方法で通知することができる。第1にPDN Connectivity RequestメッセージのAPN情報領域にリレー用PDN接続のためのAPNを設定することができる。前記リレー用PDN接続のためのAPNはProSe端末がProSe動作のためにProSe Functionとサービス認可(Service Authorization)手続きを行う時、ProSe Functionから提供されることができる。または端末はProSe端末のUICC(Universal IC Card)に予め設定された値を用いて設定することができる。第2に端末はPDN Connectivity RequestメッセージのDevice Property情報領域にProSeリレー端末であることを示すインジケータ(indication)を設定することができる。第3に端末はPDN Connectivity RequestメッセージのProtocol Configuration Options情報領域のAdditional parameter部分にリレーであることを示す識別子を設定することができる。UE2は前記3つ方法のうちの少なくとも一つ以上を用いて自分がProSeリレー端末であることを通知することができる。
前記の3つ方法のうちの少なくとも一つ以上を用いて構成されたPDN Connectivity Requestメッセージを受信したMME130は、前記の方法による情報領域に基づいてPDN Connectivity Requestを送信した端末がProSe端末−ネットワークリレーを行う端末であることを認知することができる。MMEはPDN Connectivity Requestメッセージに基づいてリレー用PDN接続のためのAPN値がAPN情報領域に設定された場合、当該端末がリレー用ベアラーが必要と判断することができる。または、Device Propertyにリレー端末であることが設定されているか、もしくはProtocol Configuration Options情報領域にリレーであることを示す識別子があればその端末のProSeリレートラフィック送信に適合したベアラーコンテクストを決定することができる。
MMEは、PDN Connectivity Requestを送信したUE2(110)がリレーを行っても良いサブスクリプションを持っているか確認するためにHSSと交渉してUEのサブスクリプション情報を確認し、リレー機能のための端末コンテクストを獲得することができる(s205)。端末コンテクストはUEがリレー役目を行うことができるかに対する情報、リレー用ベアラー接続を確立する時に用いられるARP、QCI、UE−AMBR、リレー用APNに対するAPN−AMBRなどを含むことができる。MMEがPDN Connectivity Requestを送信したUE2がリレーを行うのに必要なサブスクリプション情報を持っていると、前記HSSとのネゴシエーションを省略することができる。
MME130は、PDN Connectivity Requestを送信した端末にBearer接続を提供するためにS−GW/P−GW140でCreate Session Requestを送信する(s210)。追加的に、前記Create Session Request送信時のリレー用ベアラー接続確立を他のベアラー接続確立より先ず処理することができ、このためにS−GW/P−GWで当該リクエストを速やかに処理するようにMMEはCreate Session RequestメッセージのIndicationFlagあるいはSignaling Priority Indication、もしくはBearerContextのQoS値に高い優先順位を有する値を含んで送信することができる。前記メッセージを受信したS−GW/P−GWはIndication flagもしくはSignaling Priority Indicationを確認して他の端末またはMMEからのリクエストよりさらに優先的に前記メッセージを処理することができ、またはベアラー情報でQoS値を確認してリレーサービスのために提供することができるQCIまたはARP値を持つと、前記リクエストを優先的に処理しなければならないと判断することができる。
S−GW/P−GW140は、Create Session Responseで前記Create Session Requestに対する応答を行い(s215)、これを受信したMME130はBearer Setup RequestメッセージにBearerContext情報を含んでeNB120に伝達する(s220)。
前記220段階によってMMEは前記Bearer Setup RequestのProSe関連情報領域にProSe端末−ネットワークリレー値を設定して当該UEがProSe端末−ネットワークリレーを用いる端末であることをeNBに通知することができる。または、MMEはE−TRABtobesetuplist情報領域のE−RAB level QoS parameterにリレー用QCI値もしくはARP値を示してeNBが当該UEがリレーを用いることができることを認知するようにできる。前記のような方法でBearer Setup Requestを受信したeNBはUE2(110)がProSe端末−ネットワークリレーを用いる端末であることを認知する。
eNB120は端末とRRCメッセージを介して無線ベアラー接続を確立する(s225)。この時、eNBはUE2がリレー機能を行うように選択することができ、RRC Connection ReconfigurationメッセージにUE2がリレーで動作することができることを許可するインジケータを含むか、リレーで動作するようにする指示を含むことができる。UE2(110)はeNBが送信したRRC Connection Reconfigurationメッセージの前記指示を識別してリレー実行可否を判断することができる。
端末とeNB120間のベアラー接続が確立されると、eNBはBearer Setup responseをMME130へ送信してベアラーが設定されたことを通知し(s230)、MMEはS−GW/P−GW140にModify Bearer Requestを送信してeNBとS−GW/P−GW間のベアラー接続を確立する(s235)。
前記各段階による結果でProSeリレーを行う端末に対する情報を獲得したeNBは当該端末のコンテクストを記憶する(s240)。前記情報は、端末がProSe端末−ネットワークリレー動作を行うことができるという許可(Authorization)に対する指示及び/または端末がProSe端末−ネットワークリレー動作を行うことができる能力(capability)を持っていることを指示する情報であってもよい。
eNB120はProSe端末−ネットワークリレーサービスを提供するためにリレーUEを選択することができる(s245)。eNBは前記245段階を介してMME130から伝達された特定UEに対するリレー実行許可もしくはリレー実行指示に基づいて特定UEをリレーUEで選択することができる。
eNBはリレーUEを選択する動作のために専用RRCシグナリング(Dedicated RRC signaling)を利用したりSIBブロードキャストを利用することができる。Dedicated RRC Signalingを利用する場合、eNBは特定端末に対するRRCメッセージをC−RNTIで区分して伝達することができる。このRRCメッセージに当該UEがリレー動作を行うことができるという許可情報を含むか、当該UEがリレー動作を行うようにトリガーする指示を含むことができる。または、このRRCメッセージにリレーのために用いるリソースプール(Resource Pool)を伝達することができ、前記RRCメッセージを受信したUEはリレー用リソースプール関連情報がRRCメッセージに含まれていると、リレーを行うように指示を受けたと判断したり、リレーを行うように許可を受けたと判断することができる。
eNBがSIBブロードキャストを用いてリレーを選択する場合、SIBメッセージにリレー役目を行う端末のC−RNTIを含んでブロードキャストすることができる。もしくはeNBはSIBメッセージにリレーのためのリソースプール関連情報を含ませることができ、リレー機能を行うことができるUEは前記リソースプール情報を参照してリレー動作可否を決定したり、もしくはリレーリソースプールが明示された場合、動作上の手続きでリレー機能を開始することができる。
eNB120は自分がサービスするセルに位置した端末から測定報告を受信するようになるのに、この測定報告に基づいてeNBが端末が受信する信号の強度が特定しきい値以下であることが分かるようになれば、当該端末が直ちにネットワークカバレッジを外れるようになると判断することができる。便宜上、このUEを潜在的リモートUEと称する。
この場合、eNB120は前記測定報告を送信した端末がProSe端末−ネットワークリレーサービスを用いることができるようにするためにリレー探索動作を行うようにトリガーすることができる(s250)。前記トリガー動作を行う前に、eNBは自分がサービスするUEの中でリレー動作を行うことができるか、リレー動作を行うように許可を受けたUEがあるか確認し、少なくとも1個以上のUEが前記確認手続きに符合すると判断される場合、潜在的リモートUEにリレー探索手続きの開始をトリガーすることができる。この動作はリレー可能端末がないにもかかわらず潜在的リモートUEにリレー探索を開始するようにする不必要な動作を無くすためである。また、端末はeNBからしきい値を受信する代わりにProSe Functionから伝達されたしきい値を用いてリレー探索手続き実行可否を判断することができる。
eNB120が潜在的リモートUE(この場合、UE1(100)が潜在的リモートUEとなることができる)がリレー探索を行うようにトリガーする方法は、第1にdedicated RRCメッセージを用いるか、第2にSIBを介してブロードキャストする方法がある。第1にdedicated RRCメッセージを用いる場合、eNBは潜在的リモートUEにセル信号強度に対するしきい値を提供して潜在的リモートUEが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はeNBがブロードキャストするSIBシグナリングの強度であるか、もしくはD2Dのためのサイドリンク(Side link) 信号の強度であってもよい。または、eNBはdedicated RRCメッセージにリレー探索を指示する識別子を含んで伝達することができ、これを受信した潜在的リモートUEはリレー探索を行う。
eNBがSIBを介してリレー探索手続きをトリガーする場合、セル信号強度に対するしきい値をSIB情報で提供して潜在的リモートUEが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はeNBがブロードキャストするSIBシグナリングの強度であるか、もしくはD2Dのためのサイドリンク信号の強度であってもよい。前記しきい値は予め定まるか、またはeNB、もしくはProSe Functionが端末に通知することができる。
図3は、ProSe端末がリレー役目を行うためにService Request手続きを行う方法を示した図面である。
図3によれば、ProSe端末がリレー役目を行うためにネットワークにリレーであることを通知しながらService Request手続きを行い、その手続きを介してコアネットワークが基地局に当該端末のリレー実行に係る情報を提供し、基地局が前記情報に基づいてリレー端末を選択してカバレッジの外に移動することで予想される端末にリレーを探索するようにトリガーすることができる。
ProSe利用端末であるUE2(110)は、ネットワークにリレー用ベアラー接続を確立するためにネットワーク装置中の移動性管理装置であるMME130にService Requestメッセージを送信する(s300)。またはUE2はMMEにExtended Service Requestメッセージを送信することができる。前記端末は、Extended Service Requestメッセージを用いて自分がリレー動作を行う端末もしくはリレー動作が可能な端末であることを次のような方法で通知することができる。第1に、端末はExtended Service RequestメッセージのServiceTypeFieldにProSe端末−ネットワークリレーサービスを用いるという意味を示す識別子を含むことができる。第2に、端末はExtended Service RequestメッセージのDevice PropertyfieldにProSe端末−ネットワークリレー利用端末であることを明示することができる。前記の方法のうちの少なくとも一つ以上を用いて構成されたExtended Service Requestメッセージを受信したMMEは前記の方法による情報領域に基づいてExtended Service Requestを送信した端末がProSe端末−ネットワークリレーを行う端末であることを認知することができる。
MME130は、Service requestまたはExtended Service Requestを送信したUE2(110)がリレーを行っても良いサブスクリプション(subscription)を持っているか確認するためにHSS150と交渉してUEのサブスクリプション情報を確認し、リレー機能のための端末コンテクストを獲得することができる。端末コンテクストはUEがリレー役目を行うことができるかに対する情報、リレー用ベアラー接続を確立する時に用いられるARP、QCI、UE−AMBR、リレー用APNに対するAPN−AMBRなどを含むことができる。MMEがService Requestを送信したUE2がリレーを行うのに必要なサブスクリプション情報を予め持っていると、前記HSSとのネゴシエーションを省略することができる(s305)。
MME130は、Service RequestまたはExtended Service Requestを送信した端末にベアラー接続を提供するためにInitial Context Setup Requestにベアラーコンテクスト情報を含んでeNB120に伝達する(s310)。前記310段階によりMMEは前記Initial Context Setup RequestのProSe authorized情報領域にProSe端末−ネットワークリレー値を設定して当該UEがProSe端末−ネットワークリレーを用いる端末であることをeNBに通知することができる。または、MMEはE−TRAB to be setup list情報領域のE−RABlevelQoSparameterにリレー用QCI値もしくはARP値を含ませてこれを介してeNBが当該UEがリレーを用いることができることを認知することができる。前記のような方法でInitial Context Setup Requestを受信したeNBはUE2(110)がProSe端末−ネットワークリレーを用いる端末であることを認知する。
eNB120は端末(この場合、UE2(110)になることができる)とRRCメッセージを介して無線ベアラー接続を確立する(s315)。この時、eNBはUE2がリレー機能を行うように選択することができ、RRC Connection ReconfigurationメッセージにUE2がリレーで動作することができることを許可する指示(または、インジケータ)を含むか、リレーで動作するようにする指示を含むことができる。UE2は、RRC Connection Reconfigurationメッセージの前記指示を識別してリレー実行可否を判断することができる。
UE2(110)とeNB120間のベアラー接続が確立されると、eNBはInitialcontext Setup responseをMME130に送信してベアラーが設定されたことを通知し(s320)、MMEはS−GW/P−GW140にModify Bearer Requestを送信してeNBとS−GW/P−GW間のベアラー接続を確立する(s325)。
前述した段階による結果でProSeリレーを行う端末に対する情報を獲得したeNB120は当該端末のコンテクストを記憶する(s330)。前記情報は端末がProSe端末−ネットワークリレー動作を行うことができるという許可(Authorization)に対する指示及び/または端末がProSe端末−ネットワークリレー動作を行うことができる能力(capability)を持っていることを指示する情報であってもよい。
eNB120は、ProSe端末−ネットワークリレーサービスを提供するためにリレーUEを選択することができる(s335)。eNBは前記335段階を介してMME130から伝達された特定UEに対するリレー実行許可もしくはリレー実行指示に基づいて特定UEをリレーUEで選択することができる。この場合、eNBはUE2(110)をリレーUEで選択することができる。eNBはリレーUEを選択する動作のために専用RRCシグナリング(Dedicated RRC signaling)を用いるかSIBブロードキャストを用いることができる。
Dedicated RRC signalingを用いる場合、eNBは特定端末に対するRRCメッセージをC−RNTIで区分して伝達することができる。このRRCメッセージに当該UEがリレー動作を行うことができるという許可情報を含むか、当該UEがリレー動作を行うようにトリガーする指示を含むことができる。または、このRRCメッセージにリレーのために用いるリソースプール(Resource Pool)関連情報を伝達することができ、前記RRCメッセージを受信したUEはリレー用リソースプール関連情報がRRCメッセージに含まれていると、リレーを行うように指示を受けたと判断したり、リレーを行うように許可を受けたと判断することができる。
eNBがSIBブロードキャストを用いてリレーを選択する場合、eNBはSIBメッセージにリレー役目を行う端末のC−RNTIを含んでブロードキャストすることができる。または、eNBはSIBメッセージにリレーのためのリソースプール関連情報を含ませることができ、リレー機能を行うことができるUEは前記リソースプール情報に基づいてリレー動作可否を決定したり、もしくはリレーリソースプール情報が含まれた場合、動作上の手続きでリレー機能を実行を開始することができる。
eNB120は自分がサービスするセルに位置した端末に測定報告を受信するようになるのに、この測定報告に基づいて端末が受信する信号の強度が特定しきい値以下であることが分かるようになれば、当該端末が直ちにネットワークカバレッジを外れるようになると判断することができる。便宜上、このUEを潜在的リモートUEと称する。この場合、UE1(100)が潜在的リモートUEになることができる。
この場合、eNB120は前記測定報告を送信した端末がProSe端末−ネットワークリレーサービスを用いることができるようにするためにリレー探索動作を行うようにトリガーすることができる(s340)。前記トリガー動作を行う前に、eNBは自分がサービスするUEの中でリレー動作を行うことができるか、リレー動作を行うように許可を受けたUEがあるか確認して少なくとも1個以上のUEが前記確認手続きに符合すると判断される場合、潜在的リモートUEにリレー探索手続きの開始をトリガーすることができる。この動作は、リレー可能端末がないにもかかわらず潜在的リモートUEにリレー探索を開始するようにする不必要な動作を無くすためである。端末はeNBからしきい値を受信する代わりにProSe Functionから伝達されたしきい値を用いてリレー探索可否を判断することができる。
eNB120が潜在的リモートUEがリレー探索を行うようにトリガーする方法は、第1にdedicated RRCメッセージを用いるか、第2にSIBを介してブロードキャストする方法があり得る。第1にdedicated RRCメッセージを用いる場合、eNBは潜在的リモートUEにセル信号強度に対するしきい値を提供して潜在的リモートUEが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はeNBがブロードキャストするSIBシグナリングの強度であるか、もしくはD2Dのためのサイドリンク(Side link)信号の強度であってもよい。もしくはdedicated RRCメッセージにリレー探索を実行を指示する識別子を含んで伝達することができ、これを受信した潜在的リモートUEはリレー探索を行う。
eNBがSIBを介してリレー探索をトリガーする場合、セル信号強度に対するしきい値をSIB情報で提供して潜在的リモートUEが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はeNBがbroadcastするSIBシグナリングの強度であるか、もしくはD2Dのためのサイドリンク信号の強度であってもよい。前記しきい値は予め定まるか、またはeNB、もしくはProSe Functionが端末に通知することができる。
図4は、ProSe端末がリレー役目を行うためにBearer Resource Allocation手続きを行う方法を示した図面である。
図4によれば、ProSe端末はリレー役目を行うためにネットワークにリレーであることを通知しながらBearer Resource Allocation手続きを行い、その手続きを介してコアネットワークが基地局に当該端末のリレー実行に係る情報を提供し、基地局は前記情報に基づいてリレー端末を選択してカバレッジの外に移動することで予想される端末にリレーを探索するようにトリガーすることができる。
ProSe利用端末であるUE2(110)は、ネットワークにリレー用ベアラー接続を確立するためにネットワーク装置中の移動性管理装置であるMME130にBearer Resource Allocation requestメッセージを送信する(s400)。前記端末はBearer Resource Allocation requestメッセージを用いて自分がリレー動作を行う端末もしくはリレー動作が可能な端末であることを次のような方法で通知することができる。第1に端末はBearer Resource Allocation requestメッセージのRequired traffic flow QoS FieldにProSe端末−ネットワークリレーサービスに該当するQCIまたはARP値を含むことができる。第2に端末はBearer Resource Allocation requestメッセージのProtocol Configuration Option fieldのadditional paramater領域にProSe端末−ネットワークリレー利用端末であることを明示することができる。第3に端末はBearer Resource Allocation requestメッセージのDevice Properties情報領域にProSe端末−ネットワークリレー利用端末であることを明示することができる。
前記の方法中の少なくとも一つ以上を用いて構成されたBearer Resource Allocation requestメッセージを受信したMMEは前記の方法による情報領域に基づいてBearer Resource Allocation requestを送信した端末がProSe端末−ネットワークリレーを行う端末であることを認知することができる。
MME130はBearer Resource Allocation requestメッセージを送信したUE2(110)がリレーを行っても良いサブスクリプション(subscription)を持っているか確認するためにHSS150と交渉してUEのサブスクリプション情報を確認し、リレー機能のための端末コンテクストを獲得することができる。端末コンテクストはUEがリレー役目を行うことができるかに対する情報、リレー用ベアラー接続を確立する時に用いられるARP、QCI、UE−AMBR、リレー用APNに対するAPN−AMBRなどを含むことができる。MMEがBearer Resource Allocation requestを送信したUE2がリレーを行うのに必要なサブスクリプション情報を持っていると、前記HSSとのネゴシエーションを省略することができる(s405)。
以後、MME130はActivated Dedicated Bearer Context Request及びModify EPS Bearer Context RequestメッセージをUE2(110)で送信し、または、Bearer Resource CommandメッセージをS−GW及びP−GW140で送信する。以後、S−GW/P−GW140はCreate Bearer RequestメッセージをMME130で送信する。
MME130は、Bearer Resource Allocation requestメッセージを送信した端末にベアラー接続を提供するためにE−RAB Setup requestメッセージにベアラーコンテクスト情報を含んでeNBに伝達する(s425)。前記425段階によってMMEは前記E−RAB Setup requestのProSe関連情報領域にProSe端末−ネットワークリレー値を設定して当該UEがProSe端末−ネットワークリレーを用いる端末であることをeNB120に通知することができる。または、E−TRAB to be setup list情報領域のE−RABlevelQoSparameterにリレー用QCI値もしくはARP値を含ませてeNBが当該UEがリレーを用いることができることを認知するようにできる。前記のような方法でE−RAB Setup Requestを受信したeNBはUE2(110)がProSe端末−ネットワークリレーを用いる端末であることを認知することができる。
eNB120は、端末とRRCメッセージを介して無線ベアラー接続を確立する(s430、s435)。この時、eNBはUE2(110)がリレー機能を行うように選択することができ、RRC Connection ReconfigurationメッセージにUE2がリレーで動作することができることを許可する指示(または、インジケータ)を含むか、リレーで動作するようにする指示を含むことができる。UE2はRRC Connection Reconfigurationメッセージの前記指示を識別してリレー実行可否を判断することができる。
前述した段階による結果でProSeリレーを行う端末に対する情報を獲得したeNBは当該端末のコンテクストを記憶する(s440)。前記情報は端末がProSe端末−ネットワークリレー動作を行うことができるという許可(Authorization)に対する指示及び/または端末がProSe端末−ネットワークリレー動作を行うことができる能力(capability)を持っていることを指示する情報であってもよい。
端末とeNB120間のベアラー接続が確立されると、eNBはE−RAB Setup responseをMME130に送信してBearerが設定されたことを通知する(s445)。以後、MME130は前記内容によってCreate Bearer RequestメッセージをS−GW/P−GW140へ送信する(s450)。
eNB120はProSe端末−ネットワークリレーサービスを提供するためにリレーUEを選択することができる(s455)。eNBは前記段階を介してMMEから伝達された特定UEに対するリレー実行許可もしくはリレー実行指示に基づいてeNBが特定UEをリレーUEで選択することができる。この場合、特定UEはUE2(110)となることができる。eNBはリレーUEを選択する動作のために専用RRCシグナリング(Dedicated RRC signaling)を用いるかSIBブロードキャストを用いることができる。
Dedicated RRC signalingを用いる場合、eNBは特定端末に対するRRCメッセージをC−RNTIで区分して伝達することができる。このRRCメッセージにeNBは当該UEがリレー動作を行うことができるという許可情報を含むか、当該UEがリレー動作を行うようにトリガーする指示を含むことができる。または、このRRCメッセージにリレーのために用いるリソースプール(Resource Pool)関連情報を伝達することができ、前記RRCメッセージを受信したUEはリレー用リソースプール関連情報がRRCメッセージに含まれていると、リレーを行うように指示を受けたと判断したり、リレーを行うように許可を受けたと判断することができる。
eNB120がSIBブロードキャストを用いてリレーを選択する場合、eNBはSIBメッセージにリレー役目を行う端末のC−RNTIを含んでブロードキャストすることができる。
もしくはeNBはSIBメッセージにリレーのためのリソースプール情報を含ませることができ、リレー機能を行うことができるUEは前記リソースプール情報に基づいてリレー動作可否を決定したり、もしくはリレーリソースプール情報が明示された場合、動作上の手続きでリレー機能を実行を開始することができる。
eNB120は、自分がサービスするセルに位置した端末に測定報告を受信するようになるのに、この測定報告を参照して端末が受信する信号の強度が特定しきい値以下であることが分かるようになれば、当該端末が直ちにネットワークカバレッジを外れるようになると判断することができる。便宜上、このUEを潜在的リモートUEと称する。この場合、潜在的リモートUEはUE1(100)となることができる。
この場合、eNBは前記測定報告を送信した端末がProSe端末−ネットワークリレーサービスを用いることができるようにするためにリレー探索動作を行うようにトリガーすることができる(s460)。前記トリガー動作を行う前に、eNBは自分がサービスするUE中のリレー動作を行うことができるか、リレー動作を行うように許可を受けたUEがあるか確認し、少なくとも1個以上のUEが前記確認手続きに符合すると判断される場合、潜在的リモートUEにリレー探索手続きの開始をトリガーすることができる。この動作はリレー可能端末がないにもかかわらず潜在的リモートUEにリレー探索を開始するようにする不必要な動作を無くすためである。端末はeNBからしきい値を受信する代わりにProSe Functionから伝達を受けたしきい値を用いてリレー探索可否を判断することができる。
eNBが潜在的リモートUEがリレー探索を行うようにトリガーする方法は、第1にdedicated RRCメッセージを用いるか、第2にSIBを介してブロードキャストする方法がある。第1にdedicated RRCメッセージを用いる場合、eNBは潜在的リモートUEにセル信号強度に対するしきい値を提供して潜在的リモートUEが行ったCell信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はeNBがブロードキャストするSIBシグナリングの強度であるか、もしくはD2Dのためのサイドリンク(Side link) 信号の強度であってもよい。もしくはeNBはdedicated RRCメッセージにリレー探索を実行を指示する識別子を含んで伝達することができ、これを受信した潜在的リモートUEはリレー探索を行う。
eNBがSIBを介してリレー探索をトリガーする場合、eNBはセル信号強度に対するしきい値をSIB情報で提供して潜在的リモートUEが行ったセル信号に対する測定値がしきい値以下であればリレー探索を行うようにできる。前記セル信号はeNBがブロードキャストするSIBシグナリングの強度であるか、もしくはD2Dのためのサイドリンク信号の強度であってもよい。
図5は、本実施形態を行うことができる装置の内部構造を示したブロック図である。
具体的に、前記装置はリレーUEまたはリモートUE100、110、eNB120、MME130、S−GWまたはP−GW140及びHSS150となることができる。前記装置は送受信部500、制御部510及び記憶部520から構成され、送受信部は各装置が他の装置と送受信する信号を送受信し、記憶部は各装置に必要な情報を記憶し、制御部は送受信部が信号を送受信するように制御し、記憶部が前記情報を記憶して出力するように制御する。
<第2実施形態>
本実施形態はProSe端末−ネットワークリレーを介してリレーサービスを提供する過程で必要なリレーサービスコード(relay service code)関連パラメーターを提供する方法及びProSe端末−ネットワークリレーを介してMBMS(Multimedia Broadcast Multicast Service)トラフィックを伝達する場合、使用するようになるLayer2 Group IDを割り当てるための方法を提案する。
図6は、端末間の近接サービス(Proximity−based service)を介してProSe端末−ネットワークリレーを用いてサービスを受けるためのProSeネットワーク構造を示した図面である。
図6によれば、端末−ネットワークリレーUE610は、eNB620のカバレッジ内に位置し、セルラー網で提供するサービスをネットワークカバレッジ外に位置するリモート(remote)UEに伝達するリレー役目を行う。また、ネットワークにはProSeに対するサービス認可及びプロビジョニング(provisioning)を行うProSe Function(660)、呼出し処理関連動作を行うMME(Mobility Management Entity)(650)、加入者情報を記憶するHSS(Home Subscriber Server)、S−GW(Serving Gateway)、P−GW(PDN−Gateway)を含む各種ゲートウェー(640)などが含まれることができ、この時のネットワークはEPS(Evolved Packet System)であってもよい。
このために端末−ネットワークリレーUE(以下リレーUE)はEPSネットワークを介してリレーであることを登録してリレーサービスを提供するための各種情報を受信したり、リモートUEにIPサービスを提供するためのPDN(Packet Data Network)接続を生成するなどのリレーサービスのための準備を行う。以後、リレーサービスが用意した場合には探索(discovery)方法によりリレーUEが直接自分がリレーであることを通知するための放送(announcement)メッセージを放送したり、隣近のリモートUEがリレーをサーチする時、送信する探索誘導(discovery solicitation)メッセージを受信して探索誘導メッセージにより該当する条件を満足する場合に探索応答(discovery response)メッセージを送信することによってリモートUEがリレーUEを発見するようになる。
リモートUEは、発見されたリレーUE中で望むリレーUEを選択して当該リレーUEとリモートUE間に接続を設定(setup)し、前記接続を介してリモートUEはネットワークを通じるサービスを受けることができるようになる。
本実施形態では前記リモートUEとリレーUE間の探索過程で必要となる端末−ネットワークリレーが提供するサービスを通知するリレーサービスコード関連情報が提供される過程とリモートUEがリレーUEにリクエストしてMBMSトラフィックが送信される時、MBMSトラフィックを送信するためのレイヤー2グループ(Layer2 Group)関連情報を獲得するための方案に対する方法及び装置を開始する。リレーサービスコードは端末−ネットワークリレーが提供するサービスを通知してリモートUEが端末−ネットワークリレーでサービスを受けることができるように許可されたユーザであるか否かを識別することができるようにするコードであり、レイヤー2グループIDはリモートUEにMBMSトラフィックを送信する時に用いられる通信グループを識別することができるようにするコードである。
図7は、リレーサービスコード値を受信する手続きを示した図面である。
図7によれば、ProSe端末はセルラネットワークのカバレッジ内に位置する時、サービス認可(Service Authorization)過程を介してProSeサービスを受けるための手続きを行う。勿論、端末がセルラネットワークのカバレッジ外部に位置してProSe FunctionなどのEPSネットワークに接続が不可能な場合、端末内部にあるUSIM(Universal Subscriber Identity Module)の設定値を介してProSeサービスを用いることもできる。
一般的なProSe端末中のリモートUE700はサービス認可過程のためにService authorization request(サービス認可リクエスト)メッセージをProSe Function720に送信し(s701)、ProSe Functionは必要によってHSS740からリモートUE200に対するProSeサービスのための情報を段階721及び741を介して受信する。ProSe Function720は自分が記憶していた値により、またはs241のメッセージを介してHSS740から受信した情報によりリモートUEにリレーを介してサービスを受ける場合にサービスを受けることができるリレーサービスコード値と当該リレーサービスコードを介してどんなサービスを受けることができるかに対する用例(usage)(例えば、消防署員ネットワークサービス、警察官ネットワークサービスなど)に対する情報をService authorization response(サービス認可応答)メッセージ(s722)を介して伝達するようになる。
一方、リレーサービスを提供することができるか、リレーサービスを提供するリレー端末710はService authorization requestメッセージ(s711)を送信する時のリレーサービスを提供することができるか、リレーサービスを提供する端末であることを示すためのリレー指示(indication、またはインジケータ)を含むこともできる。
ProSe Function720は当該端末がリレーサービスを行っても良い端末であるかを自分の情報(前記情報は端末コンテクストになることができる)に基づいて、またはHSS740に問い合わせて723及び742段階を介して確認することができる。HSS740は723/742段階を介してサブスクリプション(subscription)情報をProSe Function720に提供することができる。以後、ProSe Function720は自分が記憶していた値により、またはs742メッセージを介してHSS740から受信した情報により前記リレーUE710がリレーサービスを行う時の提供することができるリレーサービスコード値と当該リレーサービスコードを介してどんなサービスを受けることができるかに対する用例(例えば、消防署員ネットワークサービス、警察官ネットワークサービスなど)に対する情報及び当該サービスのためにリレーUE710がPDN接続をリクエストする時、使用すべきAPN(Access Point Name)情報、及び必要な場合には当該リレーサービスコードをいつまで用いることができるかに対する情報、すなわち、有効期間(lifetime、または有効期間で理解することができる)関連情報を含むリストをService authorization responseメッセージ(s724)を介してリレーUE710へ伝達するようになる。
前記リレーサービスコード値と用例関連情報と当該APN値を受信したリレーUE710はUE requested PDN Connectivity Request(端末リクエストPDN接続リクエスト)(s712)メッセージを前記受信したAPN情報を含んでMME730へ送信し、リレーUE710は適当なP−GWを選択してPDN接続を設定する手続きを段階s731及びs713のdefault EPS bearer activation(EPSベアラー活性化)過程を介して行う。
PDN接続が設定されてEPSベアラーが活性化されると、この時からリレーUE710はリレー機能を行うことができるようになるので段階s714のようにリレーサービスコードなどの情報を含む放送メッセージを介して探索過程を行うことができる。
一方、以後にリレーUE710が自分のリレーサービスコード中で一部を使用しないか、変更をしようとする場合にはs211段階のようにService authorization requestメッセージをProSe Function720に送信しながら前記メッセージに解除(release)することを望むリレーサービスコード値を含ませるか、有効期間(lifetime)に対する延長をリクエストするために前記メッセージにリレーサービスコードとともに延長リクエスト指示(indication)を含むこともできる。これにより、ProSe Function720はs723及びs742段階のようにHSS740にリクエストして受信した情報または自分が持っている情報に基づいて変更された値をs724段階のようにService authorization responseメッセージを介してリレーUE710に伝達して変更された値に基づいてリレーサービスを提供するようにできる。
また、ProSe Function720が当該リレーサービスコード値に対する情報を修正しようとする場合にはプッシュ(push)メッセージ(例えば、SMS)をリレーUE710もしくはリモートUE700に送信してProSe Functionに接続するようにして(例えば、Service authorization request過程を行うようにできる)端末に新しく変更された値を同一の方法を介して伝達することもできる。
図8は、リレーUEがレイヤー2グループIDを受信する方法を示した図面である。
図8は、リモートUE800がリレーUE810に接続した以後にTMGI(Temporary Mobile Group Identity)モニタリング(monitoring)をリクエストしてMBMSトラフィック送信をリクエストした時、使用するようになるレイヤー2グループID(Layer2(L2) Group ID)を割り当てるための方法に対することで、本実施形態ではリレーUE810がProSe Function820からサービス認可(Service Authorization)を受ける過程で当該値を受信する方法を説明する。
図8によれば、リレーUE810はService Authroziation requestメッセージを送信する811段階で自分がリレーサービスを提供することができるか、リレーサービスを提供する端末であることを示すためのリレー指示(indication、インジケータでも理解することができる)を含むことができる。ProSe Function820は当該端末がリレーサービスを行っても良い端末であるかを自分が記憶している情報またはHSS830にs823及びs832段階を介して問い合わせて獲得した情報を介して確認することができる。また、ProSe Function820は自分が記憶していた値または832段階のメッセージを介してHSS830から受信した値によって前記リレーUE824がMBMSトラフィックをリレーする時、使用することができるレイヤー2グループIDのプール(pool)、すなわち、レイヤー2グループIDのリストもしくは範囲(range)値をService authorization responseメッセージに含ませてリレーUE810に提供するようになる(s824)。この時、ProSe Function820はレイヤー2グループIDのプール使用に対する有効期間(lifetime)を前記メッセージに含ませることもできる。
したがって、802段階のようにリモートUE800とリレーUE810間の接続が設定されてリレーサービスを行う過程でリモートUE800がTMGI monitoring request(TMGIモニタリングリクエスト)メッセージをリレーUE810に送信して(s803)リレーUE810が前記リクエストに該当するTMGIに対するリレーサービスを承諾する場合、リレーUE810は前記824段階で獲得したレイヤー2グループIDプールで一つのレイヤー2グループID値を選択して当該TMGI値に対するMBMSトラフィックを伝達するためのグループ値で決定し(s812)、813段階のようにTMGI monitoring response(TMGIモニタリング応答)メッセージに当該TMGIに該当するレイヤー2グループID値を含ませてリモートUE800に伝達することができる。
一方、以後にリレーUE810が自分に割り当てられたレイヤー2グループIDの一部を使用しないか変更しようとする場合には811段階のようにリレーUE810はService authorization requestメッセージをProSe Function820に送信しながら前記メッセージに解除することを望むレイヤー2グループID値を含ませるか、特定レイヤー2グループIDの有効期間に対する延長をリクエストするためにレイヤー2グループIDとともに延長リクエスト指示を含ませることもできる。これにより、ProSe Function820は823及び832段階を用いてHSS830にリクエストして獲得したりもしくは自分が持っている情報に基づいて変更された値を824段階のようにService authorization responseメッセージを介してリレーUE810に伝達して変更された値でリレーサービスを提供するようにできる。
また、ProSe Function820が当該レイヤー2グループIDプールに対する情報を修正しようとする場合にはプッシュ(push)メッセージ(例えば、SMS)をリレーUE810に送信してProSe Function820に接続するようにして(例えば、Service authorization request過程を行うようにできる)新たに変更された値を同一の方法を介して伝達することもできる。
図9は、リレーUEがレイヤー2グループIDを受信する他の方法を示した図面である。
図9は、リモートUE900がリレーUE910に接続した以後にTMGIモニタリングをリクエストしてMBMSトラフィック送信をリクエストした時、使用するようになるレイヤー2グループIDを割り当てるための方法に対するので、本実施形態ではリレーUE910がリモートUE900からTMGIモニタリングリクエストを受ける時、ProSe Function920から当該値を受信する方法を説明する。
リレーUE910が902段階のようにリモートUE900との接続後のリレーサービスを行う過程でリモートUE900がTMGI monitoring requestメッセージを送信して(s903)、リレーUE910が前記リクエストに該当するTMGIに対するリレーサービスを承諾する場合に、リレーUE910はProSe Function920にGroup ID assignment request(グループID割り当てリクエスト)メッセージを介して当該TMGIに対するMBMBトラフィックを伝達するためのレイヤー2グループID値をリクエストする(s912)。前記段階でProSe Function920はHSS930から921及び931段階を介して問い合わせて獲得した情報に基づいてサービスが可能なリレーUEであるか否かなどを判断する手続きを経ることができる。
一方、前記グループID割り当てリクエストメッセージによってProSe Function920から922段階のGroup ID assignment response(グループID割り当て応答)メッセージを介してレイヤー2グループIDが割り当てられたリレーUE910は913段階のように前記グループID割り当て応答メッセージに含まれた当該TMGIにあたるレイヤー2グループID値を含むTMGI monitoring responseメッセージをリモートUE900に伝達するようになる。
一方、リレーUE910がこれ以上レイヤー2グループIDを使用しない場合にはリレーUE910はGroupI Drelease request(グループID解除リクエスト)メッセージをProSe Function920へ送信して当該レイヤー2グループIDに対する使用中断をリクエストし、その応答でProSe Function920がGroup ID release ack(グループID解除受信確認)メッセージをリリースUE910へ送信してリクエストが処理されたことを通知することができる。
図10は、本実施形態を行うことができる装置の内部構造を示したブロック図である。
具体的に前記装置はリレーUE、リモートUE、ProSe Function及びHSSなどになることができる。前記装置は、送受信部1000、制御部1010及び記憶部1020から構成され、送受信部は各装置が相違する装置と送受信する信号を送受信し、記憶部は各装置に必要な情報を記憶し、制御部は送受信部が信号を送受信するように制御し、記憶部が前記情報を記憶して出力するように制御する。
<第3実施形態>
3GPP3rd Generation Partnership Project)からLTE(Long−Term Evolution)に基づいた災難安全網研究が現在活発に進行しつつある。そのなかで、Mission Critical Push to Talk(以下、MCPTT)サービスは既存ウォーキートーキーサービスと類似にアプリケーション端でのグループ通信を定義する。特に、災難状況で基地局が機能を行うことができない場合にもグループ通信ができるようにするために3GPPでは端末間の直接通信を要求事項に含んでいる。グループ通信が正常に成り立つためには通信のためのセッションが予め生成されなければならない必要が(以下、Call Setup(呼出し設定)という)ある。メッセージ公知を介してセッションを生成する過程で音声、イメージもしくは映像などのメディアを送信するためのメディアのタイプ、コーデック、ポート番号などに対する情報がグループに属した端末間に共有される。呼出し設定が完了された以後、任意のユーザが発言をするためにはPush Button(プッシュボタン)を押してフロアを獲得しなければならない。フロアを獲得したユーザはグループメンバーに音声及び予め公知されたメディア類型(Media type)に限ってメディアを送信することができる。
MCPTTサービスを提供する従来方法で基地局及びネットワークに接続された(On−Network)環境でMCPTTサーバーとここに接続されたMCPTTクライアント(client、以下、端末、ユーザ装置などと混用可能)を用いる方法がある。On−Network環境でSession Initiation Protocol(SIP)が呼出し設定に一般的に用いられる。セッションを生成しようとする端末がSIPサーバーにINVITE(招待)メッセージを送信すると、SIPサーバーは当該セッションと関連ある端末にINVITEメッセージを送信する。セッションに参加しようとする端末は200OKメッセージに応答する。保安のための通信秘密鍵交換及びメディアタイプ、コーデック、ポートに対する情報はINVIEメッセージに含まれ、以後の端末内のMCPTTクライアントがMCPTT動作を行う。
この時、On−Network環境でフロア・コントロールに用いられる方法は、Binary Floor Control Protocol(BFCP)とMedia Burst Control Protocol(MBCP)で、これは中央に常に存在する(Always On)サーバーでフロアリクエストを処理する方式である。サーバーに送信したRequest(リクエスト)に対するGrant(許与)メッセージを受けた端末はフロアを有すると見られる。On−Network状況では中央集中的な方式ですべての端末がすべてのリクエストをサーバーに送信した後にサーバーがこれを処理する方式で動作する。
これと異なるようにMCPTTサービスを基地局及びネットワークが機能を行うことができない(Off−Network)災難状況で用いるためには端末と端末間の直接通信を用いて音声を送受信するべきである。また、中央制御サーバーが存在しないので各端末は分散的に動作しなければならない。グループメンバー間の音声を送受信できようとすればGroupCallSetup(グループ呼出し設定)を介して呼出しで用いるメディア送信に係る設定情報、すなわち、メディアパラメーターとその値をメンバー間に互いに共有しなければならない。メディアパラメーターはMedia type(メディア類型)、codec(コーデック)、bandwidth(帯域幅)、Media送信のためのMulticast port(マルチキャストポート)、Floor Control(フロア・コントロール)メッセージ送信のためのプロトコル及び送信port(ポート)、Media Encryption(メディア暗号化)のためのGroupKey(グループ鍵)などが含まれる。メディアパラメーターと当該値を共有する方法は多様でれば良いが、代表的な2つの方法を後述する。
第1方法は、端末がグループ呼出しで用いるメディア送信に係る項目とその値をサービスを受けようとするすべての端末に予め設定した後、任意の端末がグループ呼出しを開始すると公知して予め設定されたMedia type、送信port及びコーデックを用いてメンバー端末にメディアを送信する方法である。該方法はresponse(応答)を必ず要しないので早い設定が可能であると長所がある。しかし、グループ呼出しメディア送信設定情報が参加する端末間に予め定義されていなければならないので、生成されることができるグループ呼出しのリソースをサービス事業者が定めた設定を脱して用いることができなくなるという限界がある。
第2方法は、グループ呼出しを開設する端末がグループ呼出しに用いるメディア送信関連項目を任意に選択してこれを他のメンバー端末に公知する方法である。ここでGroupCallAnnouncement(グループ呼出し公知メッセージ、グループ呼出しメッセージと混用されることができる)を送信する理由はグループ通信に参加する端末にとって音声のようなメディアを受信することができるように準備するようにすることである。
図11は、グループ呼出しを開設する端末がグループ呼出しに用いるメディア送信関連項目を任意に選択してこれを他のメンバー端末に公知する方法を示した図面である。
図11によれば、グループ呼出しを開始するMCPTTクライアント1(1100)はグループ呼出しで用いるメディアに対する複数のパラメーター値を決定し、これをグループ呼出し公知メッセージに含ませて近くのMCPTTクライアント1110、1120に送信する(s1100)。前記公知メッセージを受信したMCPTTクライアント1110、1120は送信されたメディアパラメーターを設定してグループコルネ伝達するメディアを受信するために準備し(s1110)、応答メッセージを生成してグループ内の他のMCPTTクライアントに送信することによって自分がグループに参加したことを通知する(s1120)。前記応答メッセージは参加可否を通知するメッセージであるのでメディアパラメーター情報を含まない。また、応答メッセージはすべてのグループ呼出し公知メッセージを受信する度に毎度送信されることができるが、ネットワークリソースを効果的に用いるためにMCPTTクライアントは同様のGroupIDに対する公知メッセージに対しては最初1回に限って応答メッセージを送信することもできる。グループ呼出しに参加するすべての参加者らはグループ呼出し公知メッセージと応答メッセージによってグループに参加する参加者らを確認することができる。
前記のような方法を用いてMCPTTクライアントはMCPTT Off−Networkグループ呼出し手続きを介してメディア(例えば、音声)を送受信することができるように準備する。
ところで最初グループ呼出し公知メッセージ送信時、メッセージ伝達範囲内になかったがグループ呼出し範囲内に入るか、公知メッセージ送信以後にMCPTTクライアントを活性化させた場合、当該MCPTTクライアントを既存のグループ呼出しに参加させる方法が必要である。
本実施形態によれば、グループ呼出しサービス範囲に遅くジョインしたMCPTTクライアントにグループ呼出しで用いているメディアパラメーターを伝達することによって、当該MCPTTクライアントが伝達されたメディアパラメーターを用いてメディア送受信のための設定を行うことによって既存のグループ呼出しに新しいMCPTTクライアントを参加させることができる。
本実施形態は直接通信を通じるPush to Talk(PTT)ソリューションで予め生成されたグループ呼出しに新しいMCPTTクライアントを参加させる方法を提案しており、特にグループ呼出しを直ちに生成するためにGroup Announcementメッセージを送信することによって予め生成された同一IDのグループ呼出しに能動的に参加する場合と、周期的に送信されるGroup Announcementメッセージを受信することでグループ呼出しに参加する受動的参加の場合、そし、前記2つの場合のいずれにも該当する場合を含む。
図12は、端末間の直接通信基盤のMCPTTシステムを示した図面である。
図12によれば、端末間の直接通信基盤のMCPTTシステムにはサーバーが存在しないことが特徴で、それぞれのMCPTT端末1(1200)、端末2(1210)及び端末3(1220)は自分の直接通信範囲にある他の端末と通信可能である。
図13aは、MCPTT端末の構造を示したブロック図である。
図13aによれば、MCPTT端末はMCPTT発言のためのプッシュボタン1300とボリュームUp/Downボタン1302、グループ情報を表示する画面(ディスプレー、1304)、音声入/出力のためのスピーカー(図示せず)、マイク(図示せず)などの周辺装置を含み、搭載されたMCPTTシステムが周辺装置とモデム1320を用いて端末間MCPTT動作を介してサービスを行う。MCPTT端末は、PTT UNIT(PTT部)1310を含み、前記PTT部グループ呼出し生成のためのCall Setup UNIT(呼出し設定部)1312、フロア・コントロールのためのFloor Control UNIT(フロア・コントロール部)1314、音声送受信のためのMediaTx/Rx UNIT(メディア送受信部)1316から構成されて直接通信のためにこれをサポートするモデム1320を用いる。図示しないが、端末の間通信をサポートするためのネットワークレイヤー(layer)を担当するProSe(Proximity−based service)UNIT(ProSe部)を含むこともできる。
図13bは、MCPTT端末の他の構造を示したブロック図である。
図13bによれば、MCPTT端末は送受信部1350、制御部1360及び記憶部130から構成されることができ、送受信部は他の端末とのメッセージを送受信し、記憶部は前記メッセージに含まれたパラメーターなどの情報を記憶することができ、制御部は前記送受信部と記憶部を本実施形態の内容によって動作するように制御することができる。また、図13aのPTT部で行われる動作は図13bの制御部によって行われることができる。
本実施形態はMCPTT端末の呼出し設定部を用いてグループ呼出し公知メッセージ及び応答メッセージを生成してMCPTT端末間のメッセージを送受信することによって予め生成されたグループ呼出しに新しいMCPTT端末を参加させる方法を提供する。この時、グループ呼出しはグループIDで区分してグループ呼出し別で用いるメディアパラメーターは最初グループ呼出しを開始するMCPTTクライアントによって決定されるので、グループ呼出し別でメディアパラメーターは違うことができるが、同じパラメーターが用いられることもできる。
予め生成されたグループ呼出しに新しいMCPTTクライアントを参加させる方法で、新しいMCPTTクライアントが能動的にグループ呼出し公知メッセージを送信することによって予め生成されたグループ呼出しに参加する方法と、周期的に送信されるグループ呼出し公知メッセージを受信することによって参加するようになる受動的方法があり得る。
図14は、新しいMCPTTクライアントが周期的に送信されるグループ呼出し公知メッセージを受信してグループ呼出しに参加する方法を示した図面である。
図14によれば、MCPTTクライアント1(1400)、2(1410)、3(1420)間には前述した方法でグループ呼出しこの予め生成されている(s1400)。グループ呼出しに参加したMCPTTクライアントは呼出しが生成された後、新たに現われたMCPTTクライアントがメディアパラメーター情報を設定し、このグループ呼出しに参加するように周期的に現在用いているメディアパラメーター情報を公知する(s1410)。新たに現われたMCPTTクライアント4(1430)(s1420)は、一定時間の間に待って予め生成されたグループ呼出しメンバークライアント(図14ではMCPTTクライアント2(1410))が異なるクライアントに送信するグループ呼出し公知メッセージを受信し(s1430)、当該公知メッセージに含まれたメディアパラメーターの内容どおりグループ呼出しに用いるメディアパラメーターを設定してメディアを送受信することができるように準備して(s1440)自分がグループ呼出しに参加したことを通知する応答メッセージをグループ内他のクライアントに送信する(s1450)。この応答メッセージにはメディアパラメーターが含まれない。前記応答メッセージを介してMCPTTクライアント1(1400)、2(1410)、3(1420)はMCPTTクライアントがグループ呼出しに参加したことを認知することができる。以後にもグループ呼出しメンバーは周期的にグループ呼出し公知メッセージを送信する。
この時、グループ呼出し公知メッセージを送信する周期はRFC2974Session Announcement Protocol(SAP)を用いる場合、300秒とグループ呼出し公知メッセージを送信する回数*公知メッセージ大きさを設定された帯域幅(bit/sec)で分けて求めた値のうちの大きい値で決定することができる。SAPでサービス提供時に別に設定されていない場合、前記帯域幅は4000bits/secが基本値で設定される。例えば、グループ呼出し公知メッセージを送信する周期が300秒と仮定し、偶然にMCPTTクライアントが公知メッセージ送信直後にグループに入ると、この場合299秒を待つとグループ呼出しに参加することができる場合が生ずる。これはサービスのユーザ経験を低下させて3GPPのMCPTTQoS要求事項を満足させることができる事ができない。このような状況を防止するために能動的に予め生成されたグループ呼出しに参加する方法を提案しようとする。
図15は、新しいMCPTTクライアントが能動的にグループ呼出し公知メッセージを送信することによって予め生成されたグループ呼出しに参加する方法を示した図面である。
図15によれば、この場合にもMCPTTクライアント1(1500)、2(1510)、3(1520)間にはグループ呼出しが予め生成されている(s1500)。また、予め生成されたグループ内で周期的にグループ呼出し公知メッセージが送信されることができる(s1510)。MCPTTクライアント4(1530)は、活性化された後(s1520)、グループ呼出し公知メッセージ受信を待ませず直接グループ呼出しを生成するために自分がグループ呼出しを生成しようとするグループを選択してメディアパラメーターを選定してメディアパラメーターを含ませたグループ呼出し公知メッセージを生成して他のクライアントにマルチキャスト方式で送信する(s1530)。前記公知メッセージを受信したMCPTTクライアント1(1500)、2(1510)、3(1520)はメッセージに含まれたグループIDが予め生成されたグループ呼出しのグループIDと比べてもIDが同一であれば、MCPTTクライアント4(1530)が新しくグループ呼出しに参加するということを認知する。また、MCPTTクライアント4(1530)が送信した公知メッセージに含まれたメディアパラメーターを用いてグループ呼出しを設定せず代わりに応答メッセージに予め生成されたグループ呼出しで用いるメディアパラメーターを含んで応答メッセージを送信する(s1540)。
この時、すべてのMCPTTクライアントが応答メッセージを送信する必要がないので各MCPTTクライアントはMCPTTクライアント4(1530)から公知メッセージを受信すると [0、最大値]中一つの数字を任意的に選択した後、その数字に該当する送信スロット(slot)ほど待機した後、応答メッセージを送信する。前記最大値は予め決定されることができ、もしくは呼出しグループ生成時に決定されることができる。各MCPTTクライアントが応答メッセージを送信する前に他のMCPTTクライアント(図15ではMCPTTクライアント2(1510))が送信した応答メッセージを受信すると、前記MCPTTクライアントを除いた他のMCPTTクライアント(図15ではMCPTTクライアント1(1500)、3(1520))は応答メッセージを送信する必要がない。
MCPTTクライアント2(1510)が送信した応答メッセージを受信したMCPTTクライアント4(1530)はグループID及び応答メッセージに含まれたメディアパラメーターを介して生成しようとするグループ呼出しが既に存在していることを判断し、自分が設定したメディアパラメーターの値を応答メッセージに含まれたメディアパラメーターの値に変更して(s1550) 当該グループ呼出しから送信されるメディア(音声)を受信する。以後、周期的なグループ呼出し公知メッセージが送信されることができる(s1560)。
予め生成されたグループ呼出しカバレッジに2つのMCPTTクライアントが新たに現われ、一方のクライアントは能動的にグループ呼出し公知メッセージを送信し、他方の一つのクライアントは受動的にグループ呼出し公知メッセージを受信してグループ呼出しに参加する場合、後者の受動的なMCPTTクライアントは公知メッセージと応答メッセージに含まれて送信されたメディアパラメーターが異なり、同一グループIDの呼出しにもグループ呼出しに参加することができない場合が生ずる。
このような場合を解決するために予め生成されたグループ呼出しで用いられるメディアパラメーターを送信する応答メッセージを受信する場合、新たに現われたMCPTTクライアントは予め設定されたメディアパラメーター値を応答メッセージに含まれたメディアパラメーターに変更して設定することができる。
図16は、能動的なMCPTTクライアントと受動的なMCPTTクライアントが共存する場合、2つのMCPTTクライアントをいずれもグループ呼出しに参加させる方法を示した図面である。
図16によれば、MCPTTクライアント1(1600)、2(1610)は予めグループ呼出しを生成して通信をしており(s1600)、周期的なグループ呼出し公知メッセージを送受信している(s1610)。この時、MCPTTクライアント3(1620)、4(1630)が新たに現われた状況でMCPTTクライアント3(1620)がグループ呼出しを生成するためにMCPTTクライアント1(1600)、2(1610)が予め生成したグループ呼出しのグループIDを含むグループ呼出し公知メッセージを送信する(s1630)。これを受信したMCPTTクライアント4(1630)はMCPTTクライアント3(1620)が送信したグループ呼出し公知メッセージに含まれたメディアパラメーターに基づいて自分のパラメーターを設定し、グループ呼出しに参加するという応答メッセージを送信する(s1640)。
この時、MCPTTクライアント1(1600)、2(1610)はMCPTTクライアント3(1620)が送信したグループ呼出し公知メッセージを受信し、公知メッセージに含まれたグループIDに該当するグループ呼出しが生成されていることを判断し、応答メッセージに予め生成されたグループ呼出しに用いているメディアパラメーター情報を含んで送信する(s1650)。図16の場合、MCPTTクライアント2(1610)が前記応答メッセージを送信する。この応答メッセージを受信したMCPTTクライアント3(1620)、4(1630)は予め生成されたグループ呼出しが存在することを認知して予め設定されていたメディアパラメーターを受信した応答メッセージに含まれたメディアパラメーターの値に変更設定してメディア送受信を行うようにする(s1660)。以後、周期的なグループ呼出し公知メッセージが送受信されることができる(s1670)。
前記のような手続きでMCPTTクライアント4(1630)が応答メッセージを送信する前にMCPTTクライアント1(1600)もしくは2(1610)がMCPTTクライアント3(1620)の公知メッセージに対する応答メッセージ(予め生成されたグループ呼出しで用いるメディアパラメーター情報を含み)を送信することができる。MCPTTクライアント4(1630)は前記応答メッセージを受信し、これに対する応答メッセージを送信することもできる。予め生成されたグループ呼出しに属したMCPTTクライアントはMCPTTクライアント3(1620)が送信したグループ呼出し公知メッセージとMCPTTクライアント4(1630)が送信した応答メッセージによって二つのMCPTTクライアントがグループ呼出しに参加したことを分かる。
前記MCPTTグループ呼出し設定及びグループ呼出しに参加する方案を具現する方法でSAPを活用することができる。
図17は、SAPのPacket Format(パケットフォーマット)を示した図面である。
図17のそれぞれのHeader(ヘッダー)の意味と使用方法に対しては予め公知された技術として本発明で詳述しない。ただ、本発明ではグループ呼出し公知メッセージと応答メッセージを具現するためにパケットフォーマットのRビット1700とTビット1710を活用して区分しようとする。RビットはRFC上で追後使用のために予約されたビットでTビットはSAPのメッセージ類型を定義するbitである。SAPではTビットの値が0であれば公知メッセージで1であればセッションを終了する用途として使用している。したがって、以下の表1のように応答メッセージを特定するためにRビットの値を1で設定してTビットを0で設定して用いることができる。
本実施形態を適用することによって端末間の直接通信で予め生成されたグループ呼出しにメンバーではないMCPTTクライアントを参加させることができる。
<第4実施形態>
公衆安全網(Public Safety−LTE:PS−LTE)はMCPTT(Mission Critical Push to Talk over LTE)技術を用いてユーザに災難状況で公衆安全のための通信ができるサービスを提供する。
したがって、緊急発生時の端末は他の端末に自分が緊急を通知すべきである。前記MCPTT技術を用いてMCPTTユーザは緊急に対する救護に役に立つことができる。
本実施形態が達成しようとする技術的課題は、無線通信システムでサービス提供方法及び装置を提供するものである。
本実施形態が達成しようとする技術的課題は、無線通信システムで優先順位サービス提供方法及び装置を提供するものである。
本実施形態が達成しようとする技術的課題は、MCPTTシステムでユーザ、グループ及びサービスに対する優先順位を設定する方法及び手続きを提供するものである。また、本発明が達成しようとする技術的課題は、優先順位基盤で端末及びサーバーでサービスを制御する方法に必要な手続き及び装置と、そのシステムを提供するものである。また、本発明が達成しようとする技術的課題は、優先順位基盤のサービス提供のためのメッセージフローを提供するものである。
本実施形態が達成しようとする技術的課題は、緊急で端末が他の端末に緊急であることを通知するメッセージ送信と呼出しを設定する方法及び装置を提供するものである。
本実施形態によれば、無線通信システムで優先順位サービス提供方法及び装置を提供することができる。
本実施形態によれば、優先順位基盤のサービス提供及び処理が可能で、このような優先順位サービス提供を介してQoS(quality of service)が保障されたサービスを提供することができる。
また、本実施形態によれば、緊急で端末が他の端末に緊急を通知するメッセージ送信と呼出しを設定する方法及び装置を提供することができる。また、緊急が発生する場合、端末が収集したメディアを管理者に送信することによって、緊急に対する救護に役に立つことができる。
また、本実施形態を具体的に説明するにあたり、3GPPが規格を定めた無線IMS及びUE(User equipment)とIETFのSIP(Session Initiation Protocol)を主な対象とするが、本実施形態の主な要旨は類似の技術的背景を有するそのほかの通信システムにもその範囲を大きく逸脱せず範囲で僅かの変形で適用可能であり、これは本実施形態の技術分野で熟練された技術的知識を有する者の判断で可能であろう。
本実施形態は、MCPTTユーザ、グループ及びサービスを対象で優先順位を設定することを特徴とし、その設定された優先順位を基づいた端末及びサーバー動作過程を本実施形態の特徴とする。
また、本実施形態によってMCPTTユーザとMCPTTサーバー間に優先順位基盤サービス提供のためのメッセージフロー過程を本実施形態の特徴とする。
災難安全網(Public Safety LTE、PS−LTE)はMCPTT(Mission Critical Push To Talk overLTE)技術を用いてユーザに災難状況もしくは公衆安全のための通信ができるサービスを提供する。MCPTTは3GPPで定義した技術中の一つであり、ユーザ間のグループ通信、一対一通信、緊急通貨、災難通知、及び周辺音聴取などを含む機能を提供する。
MCPTTサービスは端末とEPS(Evolved Packet System)、SIP(Session Initiation Protocol)Core、及びMCPTT Application Serverから構成される。EPSはLTE網を意味することができ、SIP CoreはSIPを用いるネットワーク装置でIMSを意味することができる。MCPTTサービスは多様な構造で配置されることができる。MCPTT事業者がEPSとSIP Core、そしてMCPTT Application Serverまで運営することができ、MCPTT事業者がSIP CoreとMCPTT Application Serverを運営して他の事業者のEPSと連動してサービスを提供することができる。また、MCPTT事業者がMCPTT Application Serverだけ運営して他の事業者のEPSとSIP Coreと連動してサービスを提供することができる。
MCPTTサービスは大きくグループ管理、セッション制御、メディア制御で機能的要素を区分することができる。グループ管理は、ユーザが属したグループに対する加入情報、グループの優先順位、グループ内許容された役目、グループ内用いることができる呼出し類型(Call type)などを管理する。セッション制御はユーザのMCPTTサービスに登録及びグループ通話を開始もしくは変更、又は終了するなどの通話セッションのための信号を制御する。MCPTTユーザが送信するセッション管理信号はいずれもMCPTT Application Serverを介して制御/管理される。
メディア制御はユーザがMCPTTサービスが提供するグループ通話、一対一通話、もしくは災難通知などを用いるために送信するメディアに対する送/受信許可リソース制御を担当する。MCPTTユーザが送信するすべてのメディア情報はMCPTTサービスが提供するメディアゲートウェー(Media gateway)を介して他のユーザに伝達する。グループ管理のためのグループ管理サーバー(Group Management Server)はMCPTT Application Serverとともに位置することができ、機能によって論理的に区別される。メディア制御のためのメディアゲートウェー(Media Gateway)はSIP Coreを経ず端末とEPS、及びMCPTT Application Serverに接続されることができる。メディアゲートウェー(Media Gateway)はユーザの送/受信権限を制御するようになり、これをフロア・コントロール(Floor control)と称することができる。Media GatewayはMCPTT Application Serverとともに位置することができ、論理的に区別された機能を示す。
MCPTTサービスは大きくグループ通話と一対一通話、及び緊急通知で区分することができる。グループ通話は公衆安全のためにグループ通信が必要な一般グループ通話、緊急/応急状況が発生した場合に対して最優先の順位で通信を提供することができる緊急呼出し(EmergencyCall)、及び緊急呼出し(Emergency Call)より優先順位は低いが切迫した緊急/応急状況に備えてグループ通信ができる緊急危険呼出し(Imminent Peril Call)をサポートすることができる。一対一通話は一般通話と緊急呼出し(Emergency Call)、そして相手の周辺音を聴取することができる周辺聴取(Ambient Listening)機能をサポートすることができる。
MCPTTユーザは多くのカテゴリーで分けられることができる。(公認されない)一般MCPTTユーザ、公認されたMCPTTユーザ、公認されたMCPTTサービス提供者がそれである。
MCPTTユーザはいくつかのMCPTTサービス提供者からサービスを受けることができる。MCPTTユーザの主要MCPTTサービス提供者以外にパートナーシップ(Partnership)を持っているMCPTTサービス提供者と連動してパートナーシップ(Partnership)のMCPTTユーザとグループ通信及び一対一通信を行うことができる。
MCPTT端末はMCPTTサービスが提供されるための基本的な情報をMCPTTサービス提供者から受信することができる。ユーザ識別子、グループ識別子、グループ内の役目及びグループ内の許可されたCall type、一対一通話可能可否、配置Type、MCPTT serverに報告しなければならないReport情報、及び多様な配置TypeをサポートするためのEPS、SIP Core、MCPTT Application Serverに接続するための情報が受信されることができる。
MCPTTサービス提供者は優先順位によってサービスを提供及び制御することができる。MCPTT端末はサービス優先順位によってサービスを制御することができる。
現在の通信システムで提供するsubscription、fixed differentiation、制限的な事業者提供サービス基盤のPriority及びQoS LevelではMCPTT Priority service要求事項を満足させることができない。したがって、細分化されたレベルのPriority設定及び処理方法が必要である。
以下の実施形態はMCPTTシステムでユーザ、グループ及びサービスに対する優先順位を設定する方法及び手続きを提案する。また、優先順位基盤で端末及びサーバーでサービスを制御する方法に必要な手続き及び装置と、そのシステムを提案する。また、及び優先順位基盤のサービス提供のためのメッセージフローを提案する。
優先順位を設定する対象は3つである。ユーザ別の優先順位が決まることができ、グループ別優先順位が決まることができ、サービス別の優先順位が決まることができる。
当該優先順位はMCPTTサービスを提供するサービス提供者または公認されたMCPTTユーザが設定することができる。
設定された優先順位値はMCPTTユーザとMCPTTサーバー間に共有されることができる。共有される方法はサービスが開始される前に予め共有されることもでき、サービスリクエストとともに共有されることができる。
設定された優先順位値を用いる個体はMCPTTサーバー、MCPTTユーザ及びSIP Coreがある。
優先順位使用は一つ以上の優先順位値の組合で用いられることができる。MCPTTサーバーはMCPTTユーザにサービスリクエストがある時、サービスリクエストを処理するのに優先順位値を用いることができる。また、MCPTTユーザが現在進行中のサービスを管理するのに用いることができる。また、フロア・コントロール(floor control)に用いられることができる。MCPTTユーザはサービスリクエストがある時、サービスリクエストを処理するのに優先順位値を用いることができる。また、現在進行中のサービスを管理するのに用いることができる。SIP Coreはネットワークリソース管理のために優先順位値を用いることができる。
本発明の実施形態において優先順位によるサービス処理方法の特徴は次の通りである。既存通信システムで適用されない優先順位値基盤のサービス処理が変わる。また、サービスに必要なメディア種類(オーディオ、ビデオ、テキストなど)によってサービス処理が変わる。メディア種類は追加の分類体系を有することができる。本発明の実施形態では同時にサービスが可能なメディア(メディアタイプA)と同時にサービスが不可能なメディア(メディアタイプB)で分けることができる。例えば、チャットの場合、同時にサービスが可能なので(メディアタイプA)、優先順位が高いサービスと優先順位の低いサービスが同時にサービスが可能である。一方、同時にサービスが不可能なオーディオの場合(メディアタイプB)、優先順位が高いサービスのオーディオを先ず聞かせる。また、ユーザが多くの端末を保有する時、優先順位によってどの端末でサービスを提供するか変わる。また、ネットワークがサポートすることができるユーザ数以上のユーザが一つのネットワークにある時、QoS保障のために優先順位が高いユーザに先ずサービスを提供することができる。
図18は、本実施形態による優先順位基盤サービス処理動作を示した図面である。
図18を参照すれば、1805動作でMCPTT端末はサービスリクエストを受信することができる。前記サービスリクエストは新しい(新規)サービスリクエストであってもよい。
1810動作でMCPTT端末は現在進行中のサービスがあるか判断することができる。サービスはMCPTTサービスであってもよい。現在進行中のサービスがある場合、1815動作へ進行し、現在進行中のサービスがない場合、1820動作へ進行する。
1820動作でMCPTT端末は1805動作でリクエストされたサービスを処理することができる。
1815動作でMCPTT端末は現在進行中のサービスと新しいサービスリクエストに対応するサービス(新規サービス)が同時に提供可能なサービスであるか判断することができる。現在進行中のサービスと新しいサービスリクエストに対応するサービスが同時に提供可能な場合、1823動作へ進行し、同時に提供可能ではない場合、1830動作へ進行する。一方、1823動作は省略可能で、1823動作が省略される場合、1825動作へ進行することができる。例えば、各サービスが提供するメディアがオーディオの場合、オーディオサービスは同時に提供することができない。例えば、各サービスが提供するメディアがテキストまたはイメージの場合、両サービスは同時に提供されることもできる。一つのサービスはオーディオを提供して一つのサービスはテキストを提供する場合、端末の性能によって各サービスのメディアは同時に提供されることもできる。このように、各サービスが同時に提供可能であるか否かはサービスの類型及び端末の性能により決定されることができる。
1823動作でMCPTT端末は現在進行中のサービスと新規サービスの優先順位を判断することができる。現在進行中のサービスが提供するメディアと新規サービスが提供するメディアの優先順位を判断することもできる。判断された優先順位は1825動作で用いられることができる。
1825動作でMCPTT端末は現在進行中のサービスと新しいサービスリクエストに対応するサービス(新規サービス)を同時に提供する。サービスを同時に提供する時、1823動作で判断した優先順位情報を用いることができる。同時に提供可能なサービスも優先順位によってサービス提供に加重値を付与することができる。例えば、テキストを提供する場合、優先順位がより高いサービスのテキストをMCPTT端末の上端に表示し、優先順位がより低いサービスのテキストをMCPTT端末の下端に表示するように制御することができる。また、先ず順位がより高いサービスに対してテキストまたはイメージ大きさに加重値を適用することができる。また、サービスを提供する時間に加重値を適用することもできる。
一方、1825動作で必ず現在進行中のサービスと新規サービスを同時に提供しなければならないことではない。例えば、同時に両サービスが提供可能な場合と言ってもMCPTT端末は一つのサービスを優先的に提供した後、他のサービスを提供することができる。また、この場合、1823動作で判断した優先順位情報に基づいて特定サービスを優先的に提供することもできる。このような場合、1835動作で説明する優先順位基盤サービス処理方法を適用することもできる。
1830動作へ進行する場合、MCPTT端末は優先順位を判断する。MCPTT端末は現在進行中のサービスと新しいサービスリクエストに対応するサービスの優先順位を判断することができる。
1835動作でMCPTT端末は優先順位に基づいて現在進行中のサービスと新しいサービスリクエストに対応するサービスの優先順位に基づいてサービスを提供することができる。例えば、優先順位がより高いサービスを先に処理することができる。MCPTT端末は後順位サービスをドロップ(drop)したり、ホールド(hold)できる。また、同時に提供可能なサービスで切り替えて提供したり、MCPTT端末ユーザの他の端末で伝達することができる。
1835動作は下記のように具体化されることができる。MCPTT端末は優先順位に基づいてサービスを調整することができる。現在進行中のサービスと新規サービス中で優先順位がより低いサービスを調整することができる。優先順位がより低いサービスを後順位サービスと指称する。MCPTT端末は後順位サービスリクエストを拒絶することができる。後順位サービスリクエストを拒絶した場合、MCPTT端末はこれをMCPTTサーバーまたは相手端末に通知することができる。
MCPTT端末は後順位サービスの当該メディアをMCPTT端末またはサーバーに記憶後に送信することができる。MCPTT端末は後順位サービスリクエストをホールドした後、現在進行中のサービスが終了される場合、提供することができる。この時、先順位サービスで一部メディアが先ず終了される場合、ホールドされた後順位サービス中の先順位サービスのメディアと衝突しないメディアを先ず提供することができる。また、後順位サービス情報を記憶した後、記憶された情報を確認することができる時期に実行されるようにできる。
また、後順位サービスの当該メディアタイプを変換することができる。例えば、後順位サービスの当該メディアタイプを変換しては順位サービスと衝突しないメディアで変換して提供したり、先順位サービスが提供するメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。後順位サービスで複数のメディアを提供する場合、複数のメディア中で先順位サービスが提供しているメディアと同時に提供可能なメディアは共に提供し、同時に提供可能ではないメディアだけ調整することができる。
また、後順位サービスをMCPTT端末ユーザの他の端末で送信することもできる。当該サービスの当該メディアを同じユーザの他の端末で送信するために同一のユーザが保有した他の端末の装置性能(device capability)が考慮されることができる。
一方、前記図18の動作はMCPTT端末だけではなくMCPTTサーバーにも適用可能である。MCPTTサーバーは第1端末からサービスリクエストを受信する場合、これを第2端末でサービスリクエストを伝達する。前記図18で説明した内容はサービスリクエストを受信した第2端末の動作である。しかし、前記図18の内容は第1端末からサービスリクエストを受信したMCPTTサーバーで第2端末でサービスリクエストを伝達する前に適用されることもできる。
すなわち、MCPTTサーバーで前記第2端末に現在進行中のサービスがあるか否かを判断することができる。進行中のサービスがない場合、リクエストされたサービスを直ちに伝達し、進行中のサービスがある場合、現在第2端末で提供中のサービスが新しいサービスリクエストと同時に提供可能であるか否かを判断することができる。判断結果によって両サービスを同時に提供するようにサービスリクエストを伝達したり、同時に提供可能ではないことで判断する場合、両サービスの優先順位を判断し、優先順位に基づいて第2端末がサービスを提供するようにサービスリクエストを送信することができる。
図19は、本発明の一実施形態による優先順位基盤サービス処理のための端末の動作を示した図面である。
図19を参照すれば、1905動作でMCPTT端末は新しい新規サービスリクエストを受信する。1910動作でMCPTT端末は現在進行中のサービスがあるか判断することができる。現在進行中のサービスがある場合、1920動作へ進行し、現在進行中のサービスがない場合、1915動作へ進行する。
現在進行中のサービスがない場合、1915動作へ進行したMCPTT端末はサービスリクエストを受諾する。MCPTT端末はリクエスト受けたサービスを処理することができる。
現在進行中のサービスがある場合、1920動作へ進行したMCPTT端末は現在進行中のサービスと新しくリクエストされたサービスの優先順位を比べる。
現在進行中のサービスの優先順位がより高い場合には1925動作へ進行し、新しくリクエストされたサービスの優先順位がより高い場合には1950動作へ進行する。
現在進行中のサービスの優先順位がより高い場合、1925動作へ進行したMCPTT端末は各サービスが提供するメディアを比べる。MCPTT端末は当該サービスのメディアタイプを比べて同時にサービスが可能であるか否かを判断することができる。同時にサービス提供が可能な場合、1930動作へ進行し、同時にサービス提供が可能ではない場合、1935動作へ進行する。
同時にサービス提供が可能な場合、MCPTT端末は1930動作へ進行して各サービスを同時に提供することができる。
同時にサービス提供が不可能なメディアの場合、1935動作へ進行した端末は各サービスが提供するメディアを比べてサービスを処理することができる。例えば、1935動作で現在サービスと新規サービスのメディアがいずれも重複されるか否かによってサービスを処理することができる。例えば、一部サービスを調整することができる。この時、調整はMCPTTサーバーまたはサービスリクエストを送信した相手端末と当該サービスの当該メディアを調整することができる。
例えば、新規サービスのすべてのメディアが現在サービスのすべてのメディアと重複される場合、1940動作へ進行する。1940動作でMCPTT端末はサービスを調整することができる。現在進行中のサービスの優先順位がより高い場合であるのでMCPTT端末は新しくリクエストされたサービス(新規サービス)を調整することができる。MCPTT端末は新規サービスリクエストを拒絶することができる。サービスリクエストを拒絶した場合、これをMCPTTサーバーまたは相手端末に通知することができる。
当該サービスの当該メディアをMCPTT端末またはサーバーに記憶した後に送信することができる。MCPTT端末は新規サービスリクエストをホールドした後、現在進行中のサービスが終了される場合、提供することができる。この時、現在進行中のサービスで一部メディアが先ず終了される場合、ホールドされた新規サービス中で現在進行中のサービスのメディアと衝突しないメディアを先ず提供することができる。また、新規サービス情報を記憶した後、記憶された情報を確認することができる時期に実行されるようにできる。
また、新規サービスの当該メディアタイプを変換することができる。例えば、新規サービスの当該メディアタイプを変換して現在進行中のサービスと衝突しないメディアで変換して提供したり、現在進行中のメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。
また、新規サービスをMCPTT端末ユーザの他の端末で送信することもできる。当該サービスの当該メディアを同じユーザの他の端末で送信するために同一のユーザが保有した他の端末の装置性能(device capability)が考慮されることができる。
新規サービスのすべてのメディアが現在サービスのメディアと一部だけ重複される場合、1945動作へ進行する。1945動作でMCPTT端末はメディアネゴシエーションを行って現在サービスのメディアと重複されないメディアに対してだけ新規サービスを開始する。この時、MCPTT端末は他の端末で呼出しフォワーディング(call forwarding)をするようにサーバーにリクエストすることができる。
1920動作で新規サービスの優先順位がより高いと、1950動作へ進行する。MCPTT端末は各サービスが提供するメディアを比べる。MCPTT端末は当該サービスのメディアタイプを比べて両サービスが提供するメディアが同一のメディアであるか否かを判断する。互いに相違するメディアを提供する場合、1955動作へ進行し、両サービスが同一メディアを提供する場合、1960動作へ進行する。
互いに相違するメディアを提供する場合、同時にサービス提供が可能なことで判断し、MCPTT端末は1955動作へ進行して各サービスを同時に提供することができる。
両サービスの提供するメディアが同一の場合、MCPTT端末は1960動作へ進行してメディアタイプを判断する。MCPTT端末はメディアタイプを判断して同時に提供可能なメディアであるか否かを判断することができる。例えば、本実施形態で各メディアはメディアタイプAとメディアタイプBで区分されることができる。メディアタイプAは同時に2つのメディアが同時に提供可能なタイプで、メディアタイプBは同時に提供可能ではないメディアタイプである。
両サービスが同時に提供可能なメディアを提供する場合、1965動作へ進行して2つのメディアを同時に提供する方法でサービスを提供する。
両サービスが同時に提供可能なメディアではない場合、1970動作へ進行する。1970動作でMCPTT端末は現在進行中のサービスを調整してサービスを提供することができる。1920動作で新規サービスの優先順位が高い場合であるので現在進行中のサービスが調整されることができる。
MCPTT端末は現在進行中のサービスを拒絶することができる。サービスを拒絶した場合、これをMCPTTサーバーまたは相手端末に通知することができる。
現在進行中のサービスをMCPTT端末またはサーバーに記憶後に送信することができる。MCPTT端末は現在進行中のサービスをホールドした後、新規サービスが終了される場合、提供することができる。この時、新規サービスで一部メディアが先ず終了される場合、ホールドされたサービスのメディア中で衝突しないメディアを先ず提供することができる。また、現在進行中のサービス情報を記憶した後、記憶された情報を確認することができる時期に実行されるようにできる。
また、現在進行中のサービスの当該メディアタイプを変換することができる。例えば、現在進行中のサービスの当該メディアタイプを変換して新規サービスが提供するメディアと衝突しないように変換して提供することができる。現在進行中のサービスのメディアを新規サービスのメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。
前記のような方法で優先順位に基づいたMCPTTサービスを提供することができる。
図20は、本発明の一実施形態による優先順位基盤のサービス処理のためのサーバーの動作を示した図面である。
2005動作でMCPTTサーバーは第1端末から新規サービスリクエストを受信する。MCPTTユーザ(第1端末ユーザ)から新しい新規サービスリクエストを受信する場合、当該リクエストはMCPTTサーバーをパスして目的端末(第2端末)で伝達する。
2010動作で、新規サービスリクエストを受けたMCPTTサーバーは当該MCPTT端末(第2端末)で現在の別のサービスが進行中であるか確認することができる。第2端末に現在進行中のサービスがない場合、2015動作へ進行し、現在進行中のサービスがある場合、2020動作へ進行する。
2015動作でMCPTTサーバーは第2端末で実行中のMCPTTサービスがないから当該新規サービスリクエストを第2端末で伝達する。
現在進行中のサービスがある場合、2020動作へ進行する。2020動作へ進行したMCPTT端末は現在進行中のサービスと新しくリクエストされたサービスの優先順位を比べる。
現在進行中のサービスの優先順位がより高い場合には2025動作へ進行し、新しくリクエスト受けたサービスの優先順位がより高い場合には2050動作へ進行する。
現在進行中のサービスの優先順位がより高い場合、2025動作へ進行したMCPTTサーバーは各サービスが提供するメディアを比べる。MCPTTサーバーは当該サービスのメディアタイプを比べて同時にサービスが可能であるか否かを判断することができる。同時にサービス提供が可能な場合、2030動作へ進行し、同時にサービス提供が可能ではない場合、2035動作へ進行する。
同時にサービス提供が可能な場合、MCPTT端末は2030動作へ進行してサービスリクエストメッセージをフォワーディングし、サービスリクエストメッセージが伝達された端末がサービスリクエストを受諾するかを決定することができる。端末がサービスリクエストを受諾する場合、各サービスが同時に提供されることができる。
同時にサービス提供が不可能なメディアの場合、2035動作へ進行したサーバーは各サービスが提供するメディアを比べてサービスを処理することができる。例えば、2035動作で現在サービスと新規サービスのメディアがいずれも重複されるか否かによってサービスを処理することができる。例えば、一部サービスを調整することができる。この時、調整はMCPTTサーバーまたはサービスリクエストを送信した相手端末と当該サービスの当該メディアを調整することができる。
例えば、新規サービスのすべてのメディアが現在サービスのすべてのメディアと重複される場合、2040動作へ進行する。2040動作でMPTTサーバーはサービスを調整することができる。現在進行中のサービスの優先順位がより高い場合であるのでMCPTTサーバーは新しくリクエストされたサービス(新規サービス)を調整することができる。MCPTTサーバーは新規サービスリクエストを拒絶することができる。サービスリクエストを拒絶した場合、これをサービス関連端末に通知することができる。
当該サービスの当該メディアをMCPTTサーバーに記憶後に送信することができる。MCPTTサーバーは新規サービスリクエストをホールドした後、現在進行中のサービスが終了される場合、提供することができる。この時、現在進行中のサービスで一部メディアが先ず終了される場合、ホールドされた新規サービス中で現在進行中のサービスのメディアと衝突しないメディアを先ず提供することができる。また、新規サービス情報を記憶した後、記憶された情報を確認することができる時期に実行されるようにできる。
また、MCPTTサーバーは新規サービスの当該メディアタイプを変換することができる。例えば、新規サービスの当該メディアタイプを変換して現地進行中のサービスと衝突しないメディアで変換して提供したり、現在進行中のメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。
また、MCPTTサーバーは新規サービスをMCPTT端末ユーザの他の端末で送信することもできる。当該サービスの当該メディアを同じユーザの他の端末で送信するために同一のユーザが保有した他の端末の装置性能(device capability)が考慮されることができる。
新規サービスのすべてのメディアが現在サービスのメディアと一部だけ重複される場合、2045動作へ進行する。2045動作でMCPTT端末はメディアネゴシエーション(negotiation)を行って現在サービスのメディアと重複されないメディアに対してだけ新規サービスを開始する。この時、MCPTT端末は予め登録された他の端末で呼出しフォワーディング(call forwarding)をするようにサーバーにリクエストすることができる。
2020動作で新規サービスの優先順位がより高い場合、2050動作へ進行する。MCPTTサーバーは各サービスが提供するメディアを比べる。MCPTTサーバーは当該サービスのメディアタイプを比べて両サービスの提供するメディアが同一メディアであるか否かを判断する。互いに相違するメディアを提供する場合、2055動作へ進行し、両サービスが同一メディアを提供する場合2060動作へ進行する。
互いに相違するメディアを提供する場合、同時にサービス提供が可能なことで判断し、MCPTTサーバーは2055動作へ進行してサービスリクエストメッセージをフォワーディングし、サービスリクエストメッセージが伝達された端末がサービスリクエストを受諾するかを決定することができる。端末がサービスリクエストを受諾する場合、各サービスが同時に提供されることができる。
両サービスが提供するメディアが同一の場合、MCPTTサーバーは2060動作へ進行してメディアタイプを判断する。MCPTTサーバーはメディアタイプを判断して同時に提供可能なメディアであるか否かを判断することができる。例えば、本実施形態で各メディアはメディアタイプAとメディアタイプBに区分されることができる。メディアタイプAは同時に2つのメディアが同時に提供可能なタイプで、メディアタイプBは同時に提供可能ではないメディアタイプである。
両サービスが同時に提供可能なメディアを提供する場合、2065動作へ進行してサービスを提供する。
両サービスが同時に提供可能なメディアではない場合、2070動作へ進行する。2070動作でMCPTTサーバーは現在進行中のサービスを調整してサービスを提供することができる。2020動作で新規サービスの優先順位が高い場合であるので現在進行中のサービスが調整されることができる。
MCPTTサーバーは現在進行中のサービスを拒絶することができる。サービスを拒絶した場合、これをMCPTTサービス関連端末で通知することができる。
MCPTTサーバーは現在進行中のサービスを記憶後に送信することができる。MCPTTサーバーは現在進行中のサービスをホールドした後、新規サービスが終了される場合、提供することができる。この時、新規サービスで一部メディアが先ず終了される場合、ホールドされたサービスのメディア中で衝突しないメディアを先ず提供することができる。
また、MCPTTサーバーは現在進行中のサービスの当該メディアタイプを変換することができる。例えば、現在進行中のサービスの当該メディアタイプを変換して新規サービスが提供するメディアと衝突しないように変換して提供することができる。現在進行中のサービスのメディアを新規サービスのメディアと同時に提供可能なメディアに変更して提供することもできる。例えば、オーディオの場合、テキストで転換してユーザ端末で表示することができる。また、新規サービス情報をテキストで提供することもできる。
前記のような方法でMCPTTサーバーは第2端末に現在進行中のサービスと新規サービスの優先順位に基づいて必要な場合、各サービスが提供するメディアを調整してMCPTTサービスを提供することができる。
サービスリクエストメッセージを受けたSIP Coreは当該サービスのためのネットワークリソースを管理するのに優先順位値を用いることができる。
図21は、本発明の一実施形態による優先順位値を基づいたフロア・コントロール(floorcontrol)過程を示した図面である。
図21を参照すれば、MCPTTサーバー2110はMCPTT Client1(2120) 及びMCPTT Client2(2130)からフロアリクエスト(floor request)メッセージを受信することができる。例えば、図21の状況はグループ通信状況であることで仮定する。グループ通信はグループ呼出し(groupcall)であってもよい。
グループ呼出しでは複数のClient(2120、2130)が参加することができる。複数のClientがグループ呼出しに参加する場合、互いに異なるクライアントから通信衝突を阻むためにデータを送信しようとする端末はフロアリクエストメッセージをMCPTTサーバー2110へ送信する。フロアリクエストメッセージを受信したMCPTTサーバー2110はフロアグラント(floor grant)メッセージを送信する。フロアグラントメッセージを受信したクライアント(client)はデータを送信することができる。
本実施形態ではフロアリクエストメッセージを受信したMCPTTサーバー2110がフロアグラントメッセージを送信する時、複数の端末の中で優先順位がより高い端末に優先的にフロアグラントメッセージを送信することができる。図21の実施形態においてMCPTT Client2(2130)はMCPTT Client1(2120)より優先順位が高いことで仮定する。したがって、MCPTTサーバー2110はMCPTT Client1(2120)とMCPTT Client2(2130)からフロアリクエストメッセージを受信する場合、さらに高い優先順位を有するMCPTT Client2(430)にフロアグラントを送信することができる。優先順位が同一の場合、フロアリクエストが受信された手順などが追加的に考慮されることができる。
図22は、本実施形態による優先順位及び端末の位置情報に基づいてネットワークでQoSを提供する過程を示した図面である。
図22を参照すれば、MCPTTサーバーがグループ通信(例えば、グループ呼出しサービス) リクエストを受信した場合、グループに属した各ユーザにグループ呼出しサービスリクエストを伝達し、グループ呼出しサービスを提供しなければならないが、この時、サービスリクエストを伝達する手順を各グループ呼出しに参加するユーザの数及び/またはユーザの優先順位に基づいて適用する方法を説明する。
2205動作でMCPTTサーバーはサービスリクエストを受信することができる。前記サービスリクエストはグループ通信リクエスト、グループ呼出しサービスであってもよい。
2210動作でMCPTTサーバーはリクエストされたサービスがグループサービスリクエストであるかを判断することができる。グループサービスはグループ通信リクエスト、グループ呼出しサービスを含むことができる。MCPTTサーバーはグループサービスリクエストではない場合、2215動作へ進行し、グループサービスリクエストの場合2220動作へ進行する。
2215動作へ進行する場合、MCPTTサーバーは一般的な手続きによってリクエストされたサービスを処理することができる。例えば、図18乃至図20で説明した方法でサービスを処理することができる。
220動作へ進行する場合、MCPTTサーバーはグループサービスを処理するための動作を行うことができる。グループサービスの場合にも図18乃至図20を介して説明した実施形態の適用は可能である。
2220動作でMCPTTサーバーはグループサービス対象端末の位置情報を獲得することができる。
MCPTTサーバーはグループサービスに対象ユーザの位置情報を獲得するために以下のような方法を適用することができる。第1方法は、MCPTT端末がネットワークに接続してMCPTTサーバーに登録する時、現在端末が接続したネットワークのID情報を送信することができる。また、端末が動きながら接続したネットワークを変える度に接続したネットワークID情報をアップデートレポーティングする。第2方法はMCPTTサーバーがグループ呼出しサービスリクエストを受ける時、網に端末の位置情報を照会して分かる。網は当該情報が分かっている時、MCPTTサーバーに通知することができる。網は当該情報が分からない時、idle(アイドル)状態である端末にメッセージを送信してネットワークID情報を獲得することができる。第2方法の場合、当該ネットワークに接続しているリアルタイムユーザ数の情報を通知することができる。MCPTTサーバーはグループ呼出しサービスリクエストを受信後、グループ呼出しサービス対象端末にSIP inviteを送信することができる。各グループ呼出しサービス対象端末は応答メッセージを送信することができ、応答メッシュには各グループ呼出しサービス対象端末の位置情報が含まれることができる。
グループ呼出しサービスをリクエストした端末の位置情報は、サービスMCPTTサーバーでサービスリクエストを受信する時、確認することもできる。例えば、グループ呼出しサービスリクエストで位置情報が送信することもできる。IMS基盤のSIPプロトコルを用いる場合、グループ呼出しサービスをリクエストする端末はSIP requestのヘッダー(header) 中にユーザ位置情報を含んで送信することができる。すなわち、Group call request inviteを送信する時、リクエストメッセージのヘッダー中に自分のネットワーク情報を含ませることができる。ネットワーク情報は位置情報であってもよく、端末が接続したセルのセルアイディーであってもよい。グループ呼出しrequestの位置情報がないか、これを利用しない場合、前記で言及した位置情報獲得方式を利用することもできる。グループ呼出しをリクエストしたグループ対象者の情報はSIP Invite requestで得ることができ、当該リクエストを受けた他の対象者の情報はSIP responseにその位置情報が含まれることができる。
MCPTTサーバーは位置情報獲得以後に2225動作へ進行することができる。2225動作でMCPTTサーバーはグループ呼出しサービス対象端末の数が予め設定された臨界条件を満足するか判断することができる。前記臨界条件はグループサービスを提供する時、マルチキャストで提供するか、ユニキャストで提供するか否かを決定するための臨界条件である。例えば、予め設定されたしきい値以上の端末がグループ呼出しサービス対象端末の場合、マルチキャストでグループサービスのためのメディアを提供することができる。グループサービスは複数の対象者に同一のメディアが送信されるから、一定数以上のグループサービス対象端末が存在する場合、マルチキャスト方法を用いる方がリソース効率側面で有利することができる。
グループサービス対象端末の数が予め設定された臨界条件を満足する場合、2230動作へ進行する。MCPTTサーバーはグループサービスのためのメディアをマルチキャスト方式を用いて提供することができる。一方、メディアはマルチキャスト方式で提供するが、シグナリングの場合、相変らずユニキャスト方式を用いることができる。シグナリングを送信する時、グループサービス対象端末の優先順位に基づいてシグナリング手順が決定されることができる。例えば、グループサービスのためのセルの収容力が200人と仮定し、グループサービス対象端末の数が250の場合、50個の端末に対してはグループサービスを提供することができない。この場合、端末の優先順位によって上位200個の端末に限ってシグナリングしてグループサービスを提供することができる。
グループサービス対象端末の数が予め設定された臨界条件を満足することができない場合、2235動作へ進行することができる。MCPTTサーバーはグループサービスのためのメディアをユニキャスト方式で提供することができる。MCPTTサーバーはメディア提供時の優先順位に基づいててグループサービス対象端末に順次にメディアを提供することができる。だけでなくシグナリングを送信する時、グループサービス対象端末の優先順位に基づいてシグナリング手順が決定されることができる。
このような端末の位置情報に基づいてMCPTTサーバーは特定ネットワークに端末が集中して集まっている時、もし、ネットワークサポートユーザ数よりその数が多い場合、ユーザの優先順位によって優先順位が高いユーザに先ずサービスを提供する。
緊急グループ呼出しはMCPTTで高い優先順位を提供するサービスの一例である。MCPTTシステムは端末及び多くの個体を経てMCPTT端末にMCPTT優先順位サービスを提供する。
図23乃至図31は、優先順位サービスの一例である緊急グループ呼出しサービスがMCPTTシステムを介して提供される過程のメッセージフローを示す。
MCPTT(Mission Critical Push to Talk over LTE)端末はMCPTT網を介してAlertメッセージを送信することができる。Alertメッセージは端末位置情報、ユーザID、グループID、所属団体情報を含む。Alertメッセージを送信するMCPTTサーバーはAlertメッセージを送信するユーザの権限を確認する。Alertメッセージに十分な情報が含まれていない時または含まれていてもAlertメッセージに情報を修正したり追加、削除することができる。本発明の実施形態においてクライアントは端末と混用して用いることができる。緊急発生時の端末は他の端末に自分が緊急であることを通知すべきである。以下の各実施形態を用いてMCPTTユーザは緊急に対する救護に役に立つことができる。
図23乃至図25は、本実施形態でAlertメッセージを送信することができる方法を示す。AlertメッセージはMCPTTサービスで、例えば、緊急呼出しをinviteする前に送信されることができる。Alert message関連手続きはMCPTTサービス提供においてオプションであってもよい。
図23は、本実施形態によるSIP MESSAGEメソッドを用いてAlertメッセージを送信する過程を示す。
図23を参照すれば、移動通信システムはMCPTT Client1(2305)、SIP Core2310、MCPTT server2315、MCPTT Group management server2320を含むことができる。また、MCPTT Client2(2325)、MCPTT Client3(2330)をさらに含むことができる。MCPTT ClientはMCPTT端末と混用して用いることができる。MCPTTalertは端末または端末のユーザが緊急を通知するメッセージであってもよい。
2341過程でMCPTT Client1(2305)はMCPTTAlert動作を開始する。2343過程でMCPTT Client1(2305)はSIP Core2310でSIPメッセージを送信する。前記SIPメッセージは端末の位置情報、ユーザID、グループID、所属団体情報を含むことができる。SIP Core2310は前記SIPメッセージをMCPTT server2315へ伝達することができる。実施形態において位置情報はMCPTT Client1の位置を指示するだけでなく、メッセージを送信する特定対象を選択するのに用いられることもできる。
2347過程でMCPTT server2315はユーザ権限及び/またはユーザ位置をチェックすることができる。MCPTT server2315はMCPTT group management server2320と通信してユーザ権限及び位置をチェックすることができる。MCTPPサーバー2315はAlertメッセージを送信するユーザ権限及び/または位置情報を確認して修正が必要な場合、Alertメッセージの情報を修正、追加、削除することができる。
2349過程でMCPTT server2315はSIPメッセージをSIP Core2310で送信する。前記SIPメッセージはMCPTT server2315で一部情報が修正、追加、削除されたメッセージであってもよい。
2351過程でSIP Core2310は、2349過程で受信したSIPメッセージに基づいてMCPTT Client2(2325)でSIPメッセージを送信する。
2353過程でMCPTT server2315はSIPメッセージをSIP Core2310で送信する。前記SIPメッセージはMCPTT server2315で一部情報が修正、追加、削除されたメッセージであってもよい。
2355過程でSIP Core2310は、2353過程で受信したSIPメッセージに基づいてMCPTT Client3(2330)でSIPメッセージを送信する。
2357過程でMCPTT Client2(2325)はSIP Core2310でSIP200OKを送信する。2359過程でSIP Core2310は、2357過程で受信したSIP200OKに基づいてSIP200OKをMCPTT server2315で送信する。
2361過程でMCPTT Client3(2330)はSIP Core2310でSIP200OKを送信する。2363過程でSIP Core2310は、2361過程で受信したSIP200OKに基づいてSIP200OKをMCPTT server2315で送信する。
2367過程でMCPTT server2315は受信したSIP200OKに基づいてSIP200OKをSIP Core2310で送信する。2369過程でSIP Core2310はMCPTT server2315から受信したSIP200OKに基づいてSIP200OKをMCPTT Client1(2305)で送信する。
前記のような方法でSIPメッセージプロトコルを用いてAlertメッセージを送信することができる。
図24は、本実施形態で端末がSIPではない他のプロトコルを用いてAlertメッセージを送信する過程を示す図面である。
図24を、参照すれば、移動通信システムはClient1(2405)、SIP Core2410、MCPTT server2415、MCPTT Group management server2420を含むことができる。また、MCPTT Client2(2425)、MCPTT Client3(2430)をさらに含むことができる。図24で端末はHTTPrequest/response、SMSなどを用いることができる。
2441過程でClient1(2405)はMCPTTAlert動作を開始する。
2443過程でclient1(2405)はMCPTT server2415でMCPTTalertSMSを送信する。または、2445過程でclient1(2405)はMCPTT server2415でMCPTT alert HTTP requestを送信することができる。
前記MCPTTalertSMS及びMCPTTalertHTTPrequestは端末の位置情報、ユーザID、グループID、所属団体情報を含むことができる。
2447過程でMCPTT server2415はユーザ権限及び/またはユーザ位置をチェックすることができる。MCPTT server2415はMCPTT Group management server2420と通信してユーザ権限及び位置をチェックすることができる。MCTPPサーバー2415はMCPTTalertSMSまたはMCPTTalertHTTPrequestを送信するユーザのユーザ権限及び/または位置情報を確認して修正が必要な場合、Alertメッセージの情報を修正、追加、削除することができる。MCPTTユーザではない場合、SIP以外の方法を用いて特定番号でSMSを送信したり、HTTP request/responseを送信するようにできる。また、MCPTT server2415は臨時ユーザID及びグループを割り当ててMCPTTメッセージを構成して当該グループユーザに送信することができる。
2449過程でMCPTT server2415はclient1に応答を送信することができる。応答はMCPTT alert HTTP responseまたはSMSで送信することができる。
2451過程でMCPTT server2415はSIPメッセージをSIP Core2410で送信する。前記SIPメッセージはMCPTT server2415で一部情報が修正、追加、削除されたメッセージであってもよい。
2453過程でSIP Core2410は、2451過程で受信したSIPメッセージに基づいてMCPTT Client2(2425)でSIPメッセージを送信する。
2455過程でMCPTT server2415はSIPメッセージをSIP Core2410で送信する。前記SIPメッセージはMCPTT server2415で一部情報が修正、追加、削除されたメッセージであってもよい。
2457過程でSIP Core2410は、2455過程で受信したSIPメッセージに基づいてMCPTT Client3(2430)でSIPメッセージを送信する。
2459過程でMCPTT Client2(2425)はSIP Core710でSIP200OKを送信する。2461過程でSIP Core2410は、2459過程で受信したSIP200OKに基づいてSIP200OKをMCPTT server2415で送信する。
2463過程でMCPTT Client3(2430)はSIP Core2410でSIP200OKを送信する。2465過程でSIP Core2410は、2463過程で受信したSIP200OKに基づいてSIP200OKをMCPTT server2415で送信する。
前記のような方法でSIPメッセージプロトコルではない、SMS及び/またはHTTPを用いてAlertメッセージを送信することができる。
図25は、本実施形態によるSIP SUBSCRIBE及びNOTIFYメソッドを用いてAlertメッセージを送信する過程を示す図面である。
図25の実施形態で端末はSIP SUBSCRIBEメソッドを用いて特定イベント状況に対して予め登録しておいて、MCPTTサーバーは当該イベントが発生時イベントが発生したことをイベントに登録した端末にSIP NOTIFYで通知する。イベントの発生した端末はMCPTTサーバーにイベントが発生したことをAlertメッセージを送信して通知する。Alertメッセージ送信方法はSIPメソッドを用いるか、SIP以外のプロトコル(HTTP、SMSなど)を用いることができる。
図25を参照すれば、移動通信システムはClient1(2505)、SIP Core2510)、MCPTT server2515、MCPTT Group management server2520を含むことができる。また、MCPTT Client2(2525)、MCPTT Client3(2530)をさらに含むことができる。
2541過程乃至2555過程はSIP SUBSCRIBE方法を用いて特定イベントを登録する過程を示す。
2541過程でMCPTT Client2(2525)はSIP Core2510でSIP SUBSCRIBEメッセージを送信する。MCPTT Client2(2525)はSIP SUBSCRIBEメッセージを用いて特定イベント状況を登録する。2543過程でSIP Core2510はSIP SUBSCRIBEメッセージをMCPTT server2515で送信する。MCPTT server2515はMCPTT Client2(2525)に対する特定イベントを登録する。2545過程でMCPTT server2515はSIP200OKをSIP Core2510で送信する。2547過程でSIP Core2510はMCPTT Client2(2525)でSIP200OKを送信する。前記過程でMCPTT Client2に対する特定イベントを登録する。
2549過程でMCPTT Client3(2530)はSIP Core2510でSIP SUBSCRIBEメッセージを送信する。MCPTT Client3(2530)はSIP SUBSCRIBEメッセージを用いて特定イベント状況を登録する。2551過程でSIP Core2510はSIP SUBSCRIBEメッセージをMCPTT server2515で送信する。MCPTT server2515はMCPTT Client3(2530)に対する特定イベントを登録する。2553過程でMCPTT server2515はSIP200OKをSIP Core2510で送信する。2555過程でSIP Core2510はMCPTT Client3(2530)でSIP200OKを送信する。前記過程でMCPTT Client2(2525)に対する特定イベントを登録する。
2557過程でMCPTT Client1(2505)はMCPTTAlert動作を開始する。
図25の図面ではAlertメッセージ送信方法でSIPメッセージを送信する構成を示しているが、前記で説明したように、Alertメッセージを送信する方法はSIPメッセージだけではなく他のプロトコルを用いることができる。例えば、図24で説明したHTTP、SMSなどを用いることもできる。
2559過程でMCPTT Client1(2505)はSIP Core2510でSIPメッセージを送信する。前記SIPメッセージは端末の位置情報、ユーザID、グループID、所属団体情報を含むことができる。2561過程でSIP Core2510は前記SIPメッセージをMCPTT server2515で伝達することができる。
2563過程でMCPTT server815はユーザ権限及び/またはユーザ位置をチェックすることができる。MCPTT server2515はMCPTT Group management server2520と通信してユーザ権限及び位置をチェックすることができる。
MCPTT server2515は特定イベントが発生したか否かを確認することができる。MCPTT serverは特定イベント発生可否によって特定イベント状況を予め登録したクライアントにSIP NOTIFYを送信するようにできる。
2565過程でMCPTT server2515はSIP Core2510でSIP NOTIFYを送信することができる。前記SIP NOTIFYメッセージは特定イベント状況を指示することができる。2567過程でSIP Core2510はMCPTT Client2(2525でSIP NOTIFYを送信することができる。
2569過程でMCPTT server2515はSIP Core2510でSIP NOTIFYを送信することができる。前記SIP NOTIFYメッセージは特定イベント状況を指示することができる。2571過程でSIP Core2510はMCPTT Client3(2530)でSIP NOTIFYを送信することができる。
2573過程でMCPTT Client2(2525)はSIP Core(2510)でSIP200OKを送信する。2575過程でSIP Core2510は2573過程で受信したSIP200OKに基づいてSIP200OKをMCPTTサーバ2515で送信する。
2577過程でMCPTT Client2(2530)はSIP Core(2510)でSIP200OKを送信する。2579過程でSIP Core2510は2577過程で受信したSIP200OKに基づいてSIP200OKをMCPTTサーバ2515で送信する。
2581過程でMCPTT server2515は2579過程で受信したSIP200OKに基づいてSIP20020OKをSIP Core2510で送信する。2583過程でSIP Core2510はMCPTT server2515から受信したSIP200OKに基づいてSIP200OKをMCPTT Client1(2505)で送信する。
前記のような方法でSIP NOTIFY方法を用いてAlertメッセージを送信することができる。
図26は、本実施形態によるAlertメッセージに端末の位置情報を含んで送信する過程を示した図面である。
端末が送信するAlertメッセージは端末の位置情報を含むことができる。図26は位置情報を獲得する方法及び位置情報をAlertメッセージに挿入する方法を示す。端末はAlertメッセージに端末のGPS(global positioning system)位置情報を含んで送信することができる。もし、GPS機能がオフされていると、オンすることができる。Alertメッセージを受けたSIP CoreはSIP Coreが記憶している情報に基づいて端末の位置情報をAlertメッセージに追加することができる。Alertメッセージを受けたMCPTTサーバーはSIP Coreまたは網から端末の位置情報を獲得して当該情報をAlertメッセージに追加することができる。
図26を参照すれば、移動通信システムはMCPTT Client1(2605)、SIP Core2610、PCRF(policy and charging rule function、2615、MCPTT server2620、MCPTT Group management server2625及びHSS(Home Subscriber Server、2630)を含むことができる。
2641過程でMCPTT Client1(2605)はMCPTTalert動作を開始する。
2643過程でMCPTT Client1(2605)は位置情報確認器機の状態を確認することができる。例えば、前記位置情報確認機器はGPSを含むことができる。MCPTT Client1(2605)はGPSがオフ状態の場合、GPSの状態をオン状態に変更することができる。
2645過程でSIPclient1(2605)はSIP Core2610でSIPメッセージを送信することができる。SIPメッセージは端末のGPS情報を含むことができる。2647過程でSIP Core2610はPCRF2615でユーザ位置情報リクエストを送信することができる。2649過程でPCRF2615はSIP Core2610でユーザ情報応答情報を送信することができる。2647過程及び2649過程は省略されることができる。
2651過程でSIP Core2610はSIPclient1(2605)及び/またはPCRFから受信したユーザ位置情報を追加することができる。
2653過程でSIP Core2605はMCPTT server2620でSIPメッセージを送信することができる。前記SIPメッセージにはユーザ位置情報が含まれることができる。2655過程でMCPTT server2620はユーザ権限及び/またはユーザ位置をチェックすることができる。MCPTT server2620はMCPTT Group management server2625と通信してユーザ権限及び位置をチェックすることができる。MCTPPサーバー2620はAlertメッセージを送信するユーザ権限及び/または位置情報を確認して修正が必要な場合、Alertメッセージの情報を修正、追加、削除することができる。
2657過程でMCPTT server2620はHSS2630でユーザ位置情報リクエストを送信することができる。2659過程でHSS2630はMCPTT server2620でユーザ位置情報応答を送信することができる。2657過程及び2659過程は省略されることができる。
2661過程でMCPTT server2620はユーザ位置情報を比べる。GPS情報、PCRFから獲得された情報、HSSから獲得された情報のうちの少なくとも一つの情報を比べることができる。MCPTSSserver2620はMCPTTAlertメッセージをグループメンバーに送信することができる。
2663過程でMCPTT server2620はSIP200OKをSIP Core2610で送信する。2665過程でSIP Core2610はMCPTT Client1(2605)でSIP200OKを送信する。
前記のような方法でAlertメッセージに端末の位置情報を含んで送信することができる。
図27乃至図31でMCPTT端末またはMCOPTTサーバーはMCPTT優先順位サービスを提供することができる。図27乃至図31でMCPTT端末またはMCPTTサーバーはサービスリクエストを受信する場合、図18乃至図22で説明した端末またはサーバーの動作を行うことができる。
図27は本実施形態によるグループ呼出しを設定する過程を示す図面である。
MCPTT端末は、MCPTT網を介して緊急(Emergency)グループ呼出しを開始することができる。端末からグループ呼出しリクエストを受けたサーバーは当該ユーザがグループ呼出しリクエストができる権限があるか確認する。また、グループ呼出しリクエストを受けたSIP Coreはグループ呼出しに該当するリソースを割り当てる。
図27を参照すれば、2741過程でMCPTT Client1(2705)はMCPTT優先順位サービス(priority service)を開始する。2743過程でMCPTT Client1(2705)はSIP INVITEをSIP Core2710で送信する。2745過程でSIP Core2710はMCPTT server2715でSIP INVITEを送信する。
2747過程でMCPTT server2715はユーザ権限をチェックする。また、MCPTT server2715はサービス優先順位をチェックする。MCPTT server2715はMCPTT Group management server2720と通信してユーザ権限及びサービス優先順位をチェックすることができる。2749過程でMCPTT server2715はチェック結果に基づいてSIP Core2710でSIP INVITEを送信する。2751過程でSIP Core2710はSIP INVITEをMCPTT Client2(2725)で送信することができる。
2753過程でMCPTT server2715はチェック結果に基づいてSIP Core2710でSIP INVITEを送信する。2755過程でSIP Core2710はSIP INVITEをMCPTT Client3(2730)で送信することができる。
2757過程でMCPTT Client2(2725)はSIP Core2710でSIP200OKを送信することができる。2759過程でSIP Core2710はMCPTT server2715でSIP200OKを送信することができる。2761過程でMCPTT Client3(2730)はSIP Core2710でSIP200OKを送信することができる。
2763過程でSIP Core2710はMCPTT server2715でSIP200OKを送信することができる。
2765過程でMCPTT server2715はSIP Core2710でSIP200OKを送信する。2767過程でSIP Core2710はベアラーリクエストメッセージをPCRF2735で送信することができる。SIP Core2710は高い優先順位のベアラーをリクエストすることができる。2769過程でPCRF2735はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであることができ、専用ベアラーであってもよい。2771過程でPCRF2735はSIP Core2710でベアラー応答メッセージを送信することができる。2773過程でSIP Core2710はMCPTT Client1(2705)でSIP200OKを送信することができる。
前記のような方法で緊急グループ呼出しを設定することができる。
図28は、本実施形態による一般グループ呼出しを緊急グループ呼出しに変更する過程を示す図面である。
端末は現在グループ呼出し中の当該グループ呼出しを緊急グループ呼出しに変更することができる。サーバーはユーザが当該リクエストをする権限があるか確認する。SIP Coreは緊急グループ呼出しに当たるようにリソースを変更する。
図28を参照すれば、移動通信システムはClient1(2805)、SIP Core2810)、MCPTT server2815、MCPTT Group management server2820を含むことができる。また、MCPTT Client2(2825)、MCPTT Client3(2830)、PCRF2835をさらに含むことができる。
2841過程でMCPTT Client1(2805)はグループ呼出しを実行中である。MCPTT Client1(2805)はMCPTT Client2(2825)及びMCPTT Client3(2830)とグループ呼出しを実行中である。
2843過程でMCPTT Client1(2805)はMCPTT優先順位サービス(priority service)を開始する。優先順位サービス(Priority service)はMCPTTpriority group callサービであることで仮定する。2845過程でMCPTT Client1(2805)はSIP re−INVITEをSIP Core2810で送信する。2847過程でSIP Core2810はMCPTT server2815でSIP re−INVITEを送信する。
2849過程でMCPTT server2815はユーザ権限をチェックする。また、MCPTT server2815はサービス優先順位をチェックする。MCPTT server2815はMCPTT Group management server2820と通信してユーザ権限及びサービス優先順位をチェックすることができる。2851過程でMCPTT server2815はチェック結果に基づいてSIP Core2810でSIP re−INVITEを送信する。2853過程でSIP Core2810はSIP re−INVITEをMCPTT Client2(2825)で送信することができる。2855過程でMCPTT server2815はチェック結果に基づいてSIP Core2810でSIP re−INVITEを送信する。2857過程でSIP Core2810はSIP re−INVITEをMCPTT Client2(2825)で送信することができる。
2859過程でMCPTT Client2(2825)はSIP200OKをSIP Core2810でSIP200OKを送信する。2861過程でSIP Core2810はMCPTT server2815でSIP200OKを送信する。2863過程でMCPTT Client3(2830)はSIP200OKをSIP Core2810でSIP200OKを送信する。2865過程でSIP Core2810はMCPTT server2815でSIP200OKを送信する。2867過程でMCPTT server2815はSIP200OKをSIP Core2810で送信する。
2869過程でSIP Core2810はベアラーリクエストメッセージをPCRF2835で送信することができる。SIP Core2810は緊急呼出しのための高い優先順位のベアラーをリクエストすることができる。2871過程でPCRF2835はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであってもよく、専用ベアラーであることができる。2873過程でPCRF2835はSIP Core2810でベアラー応答メッセージを送信することができる。2875過程でSIP Core2810はMCPTT Client1(2805)でSIP200OKを送信することができる。
前記のような方法で一般グループ呼出しを緊急グループ呼出しに変更することができる。
図29は、本実施形態による端末が他のサービス中で緊急グループ呼出しのリクエストを処理する過程を示す図面である。
緊急グループ呼出しリクエストを受けた端末は当該リクエストを無視して既存のサービスを続くか、既存サービスを止めて緊急グループ呼出しを開始したり。現在サービスと緊急グループ呼出しサービスのうちのいずれか1つ以上のサービスのメディアを修正することができる。
図29を参照すれば、移動通信システムはClient1(2905)、SIP Core2910、MCPTT server2915、MCPTT Group management server2920を含むことができる。また、MCPTT Client2(2925)、MCPTT Client3(2930)、PCRF2935をさらに含むことができる。
2941過程でMCPTT Client1(2905)はMCPTTpriorityserviceを開始する。2943過程でMCPTT Client1(2905)はSIP INVITEをSIP Core2910で送信する。2945過程でSIP Core2910はMCPTT server2915でSIP INVITEを送信する。
2947過程でMCPTT server2915はユーザ権限をチェックする。また、MCPTT server2915はサービス優先順位をチェックする。MCPTT server2915はMCPTT Group management server2920と通信してユーザ権限及びサービス優先順位をチェックすることができる。2951過程でMCPTT server2915はチェック結果に基づいてSIP Core2910でSIP INVITEを送信する。
2953過程でSIP Core2910はSIP INVITEをMCPTT Client2(2925)で送信することができる。一方、2949過程でMCPTT Client2(2925)とMCPTT Client3(2930)はprivate callを実行中である。SIP Core2910からSIP INVITEを受信したMCPTT Client2(2925)は、2955過程でMCPTT Client3(2930)でSIP−reINVITEを送信する。2957過程でMCPTT Client3(2930)はSIP200OKをMCPTT Client2(2925)で送信する。2959過程でMCPTT Client2(2925)とMCPTT Client3(2930)のprivate callはホールド状態となる。
2961過程でMCPTT Client2(2925)はSIP Core2910でSIP200OKを送信する。2963過程でSIP Core2910はMCPTT server2915でSIP200OKを送信する。2965過程でMCPTT server2915はSIP200OKをSIP Core2910で送信する。
2967過程でSIP Core2910はベアラーリクエストメッセージをPCRF2935で送信することができる。SIP Core2910は緊急呼出しのための高い優先順位のベアラーをリクエストすることができる。2969過程でPCRF2935はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであってもよく、専用ベアラーであってもよい。2971過程でPCRF2935はSIP Core2910でベアラー応答メッセージを送信することができる。2973過程でSIP Core2910はMCPTT Client1(2905)でSIP200OKを送信することができる。
前記のような方法で他のサービス株緊急グループ呼出しがリクエストされることができる。
端末は緊急グループ呼出しサービスをリクエストする前に当該グループメンバーにAlertメッセージを送信することができる。すなわち、端末は図23乃至図26で記述した方法のうちの一つでAlertメッセージを送信し、図27乃至図29で記述した方法のうちの一つで緊急グループ呼出しサービスをリクエストするようになる。
図30は、本実施形態による緊急グループ呼出しリクエストメッセージにAlertメッセージを含んで送信する過程を示す図面である。
図30を、参照すれば、移動通信システムはMCPTT Client13005、SIP Core3010、MCPTT server3015、MCPTT Group management server3020を含むことができる。また、MCPTT Client23025、MCPTT Client3(3030)をさらに含むことができる。
3041過程でMCPTT Client13005はMCPTTprioritygrouptcall動作を開始する。3043過程でMCPTT Client13005はSIP Core3010でSIP INVITEメッセージを送信する。本実施形態において、MCPTT Client13005はSIP INVITEメッセージにAlertメッセージを共に送信することができる。Alertメッセージが含まれたSIP INVITEメッセージをSIP INVITE w/Alertで表記する。
3045過程でSIP Core3010は前記SIP INVITE w/AlertをMCPTT server3015で送信することができる。3047過程でMCPTT server3015はユーザ権限をチェックする。また、MCPTT server3015はサービス優先順位をチェックする。MCPTT server3015はMCPTT Group management server3020と通信してユーザ権限及びサービス優先順位をチェックすることができる。3049過程でMCPTT server3015はチェック結果に基づいてSIP Core3010でSIP INVITE w/Alertを送信する。
3051過程でSIP Core3010はSIP INVITE w/AlertをMCPTT Client23025で送信することができる。3053過程でMCPTT server3015はチェック結果に基づいてSIP Core3010でSIP INVITEを送信する。3055過程でSIP Core3010はSIP INVITE w/AlertをMCPTT Client3(3030)で送信することができる。
3057過程でMCPTT Client23025はSIP Core3010でSIP200OKを送信することができる。3059過程でSIP Core3010はMCPTT server3015でSIP200OKを送信することができる。3061過程でMCPTT Client3(3030)はSIP Core3010でSIP200OKを送信することができる。
3063過程でSIP Core3010はMCPTT server3015でSIP200OKを送信することができる。
3065過程でMCPTT server3015はSIP Core3010でSIP200OKを送信する。3067過程でSIP Core3010はベアラーリクエストメッセージをPCRF3035で送信することができる。SIP Core3010は高い優先順位のベアラーをリクエストすることができる。3069過程でPCRF3035はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであってもよく、専用ベアラーであってもよい。3071過程でPCRF3035はSIP Core3010でベアラー応答メッセージを送信することができる。3073過程でSIP Core3010はMCPTT Client13005でSIP200OKを送信することができる。
図31は、本実施形態による一般グループ呼出し中でAlertメッセージを受信して緊急グループ呼出しで転換する過程を示す図面である。
AlertメッセージはSIPメソッド(SIP MESSAGE、SUBSCRIBE/NOTIFYなど) 及びSIP以外のプロトコル(HTTP、SMSなど)が可能である。当該Alertメッセージを受けたSIP Coreは一般グループ呼出しに割り当てられたリソースを緊急グループ呼出しに該当するように修正する。
図31を参照すれば、移動通信システムはMCPTT Client13105、SIP Core3110、MCPTT server3115、MCPTT Group management server3120を含むことができる。また、MCPTT Client2(3125)、MCPTT Client3(3130)をさらに含むことができる。
3141過程で通信システムのエンティティーは一般グループ呼出しを実行中である。
3143過程でMCPTT Client13105はMCPTTAlert動作を開始する。
3145過程でMCPTT Client13105はSIP Core3110でSIPメッセージを送信する。前記SIPメッセージは端末の位置情報、ユーザID、グループID、所属団体情報を含むことができる。3147過程でSIP Core3110は前記SIPメッセージをMCPTT server3115で伝達することができる。
3149過程でMCPTT server3115はユーザ権限及び/またはユーザ位置をチェックすることができる。MCPTT server3115はMCPTT Group management server3120と通信してユーザ権限及び位置をチェックすることができる。MCTPPサーバー3115はAlertメッセージを送信するユーザ権限及び/または位置情報を確認して修正が必要な場合、Alertメッセージの情報を修正、追加、削除することができる。
3151過程でMCPTT server3115はSIPメッセージをSIP Core3110で送信する。前記SIPメッセージはMCPTT server3115で一部情報が修正、追加、削除されたメッセージであってもよい。3153過程でSIP Core3110は、3151過程で受信したSIPメッセージに基づいてMCPTT Client2(3125)でSIPメッセージを送信する。3155過程でMCPTT server3115はSIPメッセージをSIP Core3110で送信する。前記SIPメッセージはMCPTT server3115で一部情報が修正、追加、削除されたメッセージであってもよい。3157過程でSIP Core3110は、3155過程で受信したSIPメッセージに基づいてMCPTT Client2(3125)でSIPメッセージを送信する。
3159過程でMCPTT Client2(3125)はSIP Core3110でSIP200OKを送信する。3161過程でSIP Core3110は、3159過程で受信したSIP200OKに基づいてSIP200OKをMCPTT server3115で送信する。
3163過程でMCPTT Client3(3130)はSIP Core3110でSIP200OKを送信する。3165過程でSIP Core3110は、3163過程で受信したSIP200OKに基づいてSIP200OKをMCPTT server3115で送信する。
3167動作でMCPTT server3115は受信したSIP200OKに基づいてSIP200OKをSIP Core3110で送信する。3169過程でSIP Core3110はベアラーリクエストメッセージをPCRF3135で送信することができる。SIP Core3110は高い優先順位のベアラーをリクエストすることができる。3171過程でPCRF3135はベアラーを割り当てることができる。前記ベアラーは高い優先順位のベアラーであってもよく、専用ベアラーであってもよい。3173過程でPCRF3135はSIP Core3110でベアラー応答メッセージを送信することができる。
3175過程でSIP Core3110はMCPTT Client13105でSIP200OKを送信することができる。以後、3177過程で一般グループ呼出し中のエンティティーは緊急グループ呼出しで転換される。各エンティティーはMCPTTprioritygroupcallを行うことができる。
前記のような方法で一般グループ呼出し中の端末らがAlertメッセージを受信した後緊急呼出しで転換することができる。
図32は、本実施形態による端末を示す図面である。
図32を参照すれば、本発明の端末3200は送受信部3210及び制御部3230を含むことができる。送受信部3210は受信機及び送信機を含むことができる。送受信部は他のネットワークエンティティーと信号を送受信することができる。前記信号は制御情報とデータ及びパイロットのうちの少なくとも一つを含むことができる。制御部3230は端末の全般的な動作を制御することができる。
送受信部3210は送信される信号の周波数を上昇変換及び増幅するRF送信機と、受信される信号を低雑音増幅して周波数を下降変換するRF受信機などから構成されることができる。また、送受信部は無線チャンネルを介して信号を受信して制御部3230に出力し、制御部3230から出力された信号を無線チャンネルを介して送信することができる。
例えば、制御部3230はMCPTTサーバーから第1サービスリクエストを受信し、前記第1サービスリクエストに対応する第1サービスと現在実行中の第2サービスが同時に提供しするか否かを判断し、同時に提供可能ではないことで判断すると、前記各サービスに係る優先順位に基づいて各サービスを処理するように制御することができる。
また、前記制御部3230は前記各サービス中で後順位サービスに対するメディアを調整して前記各サービスを処理するように制御することができる。この時、前記調整は前記後順位サービスを終了、拒絶、先順位サービスの終了時までホールド、先順位サービスのメディアと同時に提供可能なサービスで変換、または予め設定された他の端末にフォワーディングする動作中の少なくとも一つを含むことができる。また、優先順位はユーザ別に優先順位、グループ別優先順位またはサービス別の優先順位中の少なくとも一つを含むことができる。
一方、端末3200及び制御部3230の動作及び機能は図32で言及した内容に限定しない。制御部3230は上述した本発明の実施形態によって端末3200が動作するように一連の過程を制御することができる。
図33は、本実施形態によるMCPTTサーバーの構造を示すブロック図である。
図33を参照すれば、本発明のMCPTTサーバー3300は送受信部3310及び制御部3330を含むことができる。送受信部は受信機及び送信機を含むことができる。送受信部3310は他のネットワークエンティティーと信号を送受信することができる。制御部3330は前記MCPTTサーバー3300の全般的な動作を制御することができる。
本発明の実施形態によれば、制御部3330は第1端末から第2端末に対する第1サービスリクエストを受信し、前記第2端末で前記第1サービスリクエストに対応する第1サービスと現在第2端末で実行中の第2サービスが同時に提供可能である否かを判断し、同時に提供可能ではないと判断すれば、前記各サービスに係る優先順位に基づいて各サービスの処理を決定し、前記決定に基づいて前記第2端末でサービスリクエストメッセージを送信するように制御することができる。
また、前記制御部3330は前記各サービス中の後順位サービスに対するメディアを調整するように制御することができる。前記調整は前記後順位サービスを終了、拒絶、先順位サービスの終了時までホールド、先順位サービスのメディアと同時に提供可能なサービスで変換、または予め設定された他の端末にフォワーディングするように処理する動作中の少なくとも一つを含むことができる。前記優先順位は、ユーザ別の優先順位、グループ別優先順位またはサービス別の優先順位のうちの少なくとも一つを含むことができる。
また、前記制御部3330は前記第1端末からフロアリクエスト(floor request)メッセージを受信し、前記第2端末からフロアリクエストメッセージを受信し、前記第1端末と前記第2端末の優先順位に基づいて先順位端末に前記フロアグラント(floor grant)メッセージを送信するように制御することができる。
また、前記制御部3330は前記サービスリクエストがグループサービスをリクエストの場合、前記グループサービスに対するグループサービス対象端末の数が予め設定された臨界条件を満足するか判断し、前記臨界条件判断結果に基ついで前記グループサービスをマルチキャストまたはユニキャスト方法で提供するか否かを決定するように制御することができる。
一方、MCPTTサーバー3300及び制御部3330の動作及び機能は図33で言及した内容で限定しない。制御部1630は、上述した本発明の実施形態によってMCPTTサーバー1600が動作するように一連の過程を制御することができる。
一方、図23乃至図31で各エンティティーは各エンティティーを制御するための制御部及び各エンティティーが他のネットワークエンティティーと信号を送受信するための送受信部を含んでいる。
本発明の実施形態によれば、リレー端末はPDN接続を生成して端末−ネットワークリレーを効果的に行うことができる。
本明細書及び図面に開示された実施形態は本発明の内容を容易に説明し、理解を助けるために特定例を提示したものであって、本発明の範囲を限定しようとするものではない。したがって、本発明の範囲はここに開示された実施形態以外にも本発明の技術的思想に基づいて導出されるすべての変更または変形された形態が本発明の範囲に含まれることに解釈されなければならない。