JP2018524883A - 端末のパケットデータネットワーク接続を生成する方法及び装置 - Google Patents

端末のパケットデータネットワーク接続を生成する方法及び装置 Download PDF

Info

Publication number
JP2018524883A
JP2018524883A JP2017564717A JP2017564717A JP2018524883A JP 2018524883 A JP2018524883 A JP 2018524883A JP 2017564717 A JP2017564717 A JP 2017564717A JP 2017564717 A JP2017564717 A JP 2017564717A JP 2018524883 A JP2018524883 A JP 2018524883A
Authority
JP
Japan
Prior art keywords
terminal
service
relay
mcptt
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017564717A
Other languages
English (en)
Other versions
JP6791885B2 (ja
Inventor
ヨンキョ・ベク
スンフン・キム
ホヨン・イ
サンスー・ジョン
スンジン・パク
ヒョンモク・コー
ユンスン・ベク
ソンヤン・チョ
エリック・グットマン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2018524883A publication Critical patent/JP2018524883A/ja
Application granted granted Critical
Publication of JP6791885B2 publication Critical patent/JP6791885B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/14—Mobility data transfer between corresponding nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

本開示は５Ｇ通信技術及びＩｏＴ関連技術に基づいて知能型サービス(例えば、スマートホーム、スマートビルディング、スマートシティ、スマートカーあるいはコネクテッドカー、ヘルスケア、デジタル教育、小売り業、保安及び安全関連サービスなど)に適用されることができる。本発明は第１ネットワーク装置でサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを送信する段階と、及び前記第１ネットワーク装置からサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを受信する段階と、を含み、前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)機能を行うことができるリレー端末であり、前記第１ネットワーク装置は近接サービス(ＰｒｏＳｅ)関連機能を行うＰｒｏＳｅファンクション(ｆｕｎｃｔｉｏｎ)であり、前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(ＡＰＮ)及びサービス認可に係る有効期間情報を含むことを特徴とする。

Description

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

Claims (14)

  1. 第１端末が信号を送信する方法であって、
    第１ネットワーク装置でサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを送信する段階と、前記第１ネットワーク装置は近接サービス(Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ ｓｅｒｖｉｃｅ、ＰｒｏＳｅ)機能を含み、及び
    前記第１ネットワーク装置からサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを受信する段階と、を含み、
    前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)機能を行うことができる端末であり、
    前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(ＡＰＮ) 及びサービス認可に係る有効期間情報を含むことを特徴とする、信号送信方法。
  2. 前記サービス認可応答メッセージに含まれた情報は前記第１ネットワーク装置が持っている端末−ネットワークリレーサービスを行うことができる端末であるか確認するための情報に基づいて決定されることを特徴とする、請求項１に記載の信号送信方法。
  3. 第２端末と前記サービス認可応答メッセージに含まれた情報に基づいて端末−ネットワークリレー接続を設定する段階をさらに含むことを特徴とする、請求項1に記載の信号送信方法。
  4. 第１ネットワーク装置が信号を送信する方法であって、
    第１端末からサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを受信する段階と、前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)機能を行うことができ、及び
    前記第１端末でサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを送信する段階を含み、
    前記第１ネットワーク装置はＰｒｏファンクション(ｆｕｎｃｔｉｏｎ)を含み、
    前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(ＡＰＮ) 及びサービス認可に係る有効期間情報を含むことを特徴とする、信号送信方法。
  5. 前記サービス認可リクエストメッセージを受信した後前記第１端末が端末−ネットワークリレーサービスを行うことができる端末であるか確認する段階をさらに含むことを特徴とする、請求項４に記載の信号送信方法。
  6. 前記第１端末が前記端末−ネットワークリレーサービスを行うことができる端末であるか決定するための情報を記憶していない場合、ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ)から前記情報を獲得する段階をさらに含むことを特徴とする、請求項５に記載の信号送信方法。
  7. 前記第１端末は前記サービス認可応答メッセージに含まれた情報に基づいて第２端末と端末−ネットワークリレー接続を設定することを特徴とする、請求項４に記載の信号送信方法。
  8. 信号を送信する第１端末であって、
    送受信部と、及び
    第１ネットワーク装置でサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを送信し、前記第１ネットワーク装置は近接サービス(Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ ｓｅｒｖｉｃｅ、ＰｒｏＳｅ)機能を含み、前記第１ネットワーク装置からサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを受信するように制御する制御部と、を含み、
    前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ) 機能を行うことができる端末であり、前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(ＡＰＮ)及びサービス認可に係る有効期間情報を含むことを特徴とする第１端末。
  9. 前記サービス認可応答メッセージに含まれた情報は前記第１ネットワーク装置が持っている端末−ネットワークリレーサービスを行うことができる端末であるか確認するための情報に基づいて前記第１端末が前記端末−ネットワークリレーサービスを行うことができる端末であるか確認されることを特徴とする、請求項８に記載の第１端末。
  10. 前記制御部は第２端末と前記サービス認可応答メッセージに含まれた情報に基づいて端末−ネットワークリレー接続を設定するようにさらに制御することを特徴とする、請求項８に記載の第１端末。
  11. 信号を送信する第１ネットワーク装置であって、
    信号を送受信する送受信部と、及び
    第１端末からサービス認可リクエスト(Ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを受信し、前記第１端末は端末−ネットワークリレー(ＵＥ−ｔｏ−ｎｅｔｗｏｒｋ ｒｅｌａｙ)機能を行うことができ、前記第１端末でサービス認可応答(ｓｅｒｖｉｃｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｓｐｏｎｓｅ)メッセージを送信するように制御する制御部と、を含み、
    前記第１ネットワーク装置はＰｒｏＳｅファンクション(ｆｕｎｃｔｉｏｎ)を含み、
    前記サービス認可応答メッセージはリレーサービスコード、アクセスポイントネーム(ＡＰＮ)及びサービス認可に係る有効期間情報を含むことを特徴とする、第１ネットワーク装置。
  12. 前記制御部は前記サービス認可リクエストメッセージを受信した後、前記第１端末が端末−ネットワークリレーサービスを行うことができる端末であるか確認するようにさらに制御することを特徴とする、請求項１１に記載の第１ネットワーク装置。
  13. 前記制御部は前記第１端末が前記端末−ネットワークリレーサービスを行うことができる端末であるか確認するための情報を記憶していない場合、ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ)から前記情報を獲得するようにさらに制御することを特徴とする、請求項１２に記載の第１ネットワーク装置。
  14. 前記第１端末は前記サービス認可応答メッセージに含まれた情報に基づいて第２端末と端末−ネットワークリレー接続を設定することを特徴とする、請求項１１に記載の第１ネットワーク装置。
JP2017564717A 2015-06-29 2016-06-28 端末のパケットデータネットワーク接続を生成する方法及び装置 Active JP6791885B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562185771P 2015-06-29 2015-06-29
US62/185,771 2015-06-29
PCT/KR2016/006917 WO2017003161A1 (en) 2015-06-29 2016-06-28 Method and apparatus for generating packet data network connection of user equipment

Publications (2)

Publication Number Publication Date
JP2018524883A true JP2018524883A (ja) 2018-08-30
JP6791885B2 JP6791885B2 (ja) 2020-11-25

Family

ID=57601467

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017564717A Active JP6791885B2 (ja) 2015-06-29 2016-06-28 端末のパケットデータネットワーク接続を生成する方法及び装置

Country Status (6)

Country Link
US (2) US10455406B2 (ja)
EP (1) EP3314978B1 (ja)
JP (1) JP6791885B2 (ja)
KR (1) KR102591864B1 (ja)
CN (1) CN107852591B (ja)
WO (1) WO2017003161A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021220971A1 (ja) * 2020-04-27 2021-11-04 株式会社Ｎｔｔドコモ 端末及び通信方法

Families Citing this family (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9749377B2 (en) * 2011-08-01 2017-08-29 Intel Corporation Method and system for network access control
CN108770074B (zh) * 2014-12-22 2022-09-30 中兴通讯股份有限公司 实现设备直通中继选择的方法、网络控制节点和用户设备
JP2018093252A (ja) * 2015-04-07 2018-06-14 シャープ株式会社 端末装置、ｍｍｅ、ｐｇｗ、及び通信制御方法
CN111372204B (zh) * 2015-05-15 2021-08-13 华为技术有限公司 一种发现方法及设备
WO2017002855A1 (ja) * 2015-06-29 2017-01-05 シャープ株式会社 端末装置、ＰｒｏＳｅ機能を備える装置、端末装置の通信方法及びＰｒｏＳｅ機能を備える装置の通信方法
KR102568265B1 (ko) * 2015-07-23 2023-08-18 애플 인크. 레이어 2 릴레이 프로토콜 및 이동성 릴레이 방법
CN107852759B (zh) * 2015-08-07 2020-02-14 华为技术有限公司 连接控制装置及方法
KR101763471B1 (ko) * 2015-08-12 2017-08-02 한국철도기술연구원 콜 발생자 및 발언권 중재자 다중화에 의한 ptt 제어 방법
CN113794524A (zh) * 2015-11-09 2021-12-14 华为技术有限公司 一种信号强度测量方法及设备
KR102540311B1 (ko) * 2015-12-08 2023-06-07 삼성전자주식회사 사용자 단말 장치 및 그 제어 방법
WO2017113264A1 (zh) * 2015-12-31 2017-07-06 华为技术有限公司 通信方法及设备
EP3376788B1 (en) * 2015-12-31 2019-09-18 Huawei Technologies Co., Ltd. Method for user equipment to access network, core network entity, base station, and first ue
WO2017118199A1 (zh) * 2016-01-07 2017-07-13 华为技术有限公司 一种数据调度方法、基站及系统
US10271370B2 (en) 2016-02-12 2019-04-23 Ofinno Technologies, Llc Mission critical communications
US20170257751A1 (en) * 2016-03-05 2017-09-07 Ofinno Technologies, Llc Off-Network Wireless Mission Critical Session Initiation
KR102484306B1 (ko) * 2016-03-10 2023-01-03 삼성전자주식회사 동적 그룹을 생성하기 위한 장치 및 방법
US10149225B1 (en) * 2016-03-28 2018-12-04 Sprint Spectrum L.P. Systems and methods for excluding relay nodes from multi-user multiple-input-multiple-output (MU-MIMO) pairing
US11096086B2 (en) * 2016-04-14 2021-08-17 Lg Electronics Inc. Method for transmitting feedback information in FED2D environment and apparatus therefor
CN109479057B (zh) * 2016-07-15 2021-11-23 三星电子株式会社 用于管理mcptt通信中的音频切入策略的系统和方法
WO2018109986A1 (ja) * 2016-12-13 2018-06-21 日本電気株式会社 ネットワーク選択のための装置
EP3554158B1 (en) * 2016-12-27 2024-09-04 Huawei Technologies Co., Ltd. Method for transmitting system information, and terminal device
WO2018129543A1 (en) * 2017-01-09 2018-07-12 Idac Holdings, Inc. Relay for wireless communication system
US10630661B2 (en) 2017-02-03 2020-04-21 Qualcomm Incorporated Techniques for securely communicating a data packet via at least one relay user equipment
US11146346B2 (en) 2017-03-29 2021-10-12 Motorola Mobility Llc Transmitting a message in response to receiving a message
US10299185B1 (en) * 2017-04-24 2019-05-21 Sprint Communications Company L.P. Wireless relay quality-of-service based on relay-delivered media services
US10827558B2 (en) 2017-06-26 2020-11-03 Qualcomm Incorporated Techniques and apparatuses for communication relay discovery
CN109379171A (zh) * 2017-08-10 2019-02-22 索尼公司 用于无线通信的电子设备和方法、存储介质
CN111108789B (zh) * 2017-09-29 2024-05-24 索尼公司 通信设备和通信方法
KR102438683B1 (ko) * 2017-12-18 2022-08-31 삼성전자주식회사 Mcptt 서비스에 기초하여 설정된 그룹 콜에 참여하는 단말 및 이의 동작 방법
KR102569131B1 (ko) * 2018-05-11 2023-08-24 삼성전자주식회사 차량 통신 서비스를 수행하는 장치 및 방법
US11159935B2 (en) * 2018-05-16 2021-10-26 Qualcomm Incorporated Resource slicing on a sidelink interface
US10701539B2 (en) 2018-07-02 2020-06-30 Qualcomm Incorporated Enhanced public warning system
CN109100944B (zh) * 2018-08-24 2021-11-09 福建星网智慧科技有限公司 一种基于ims的数据采集与处理系统
KR102456859B1 (ko) 2018-10-05 2022-10-20 삼성전자 주식회사 5g 시스템에서 제공하는 서비스 파라미터를 단말과 네트워크에 프로비져닝하는 방법
US10743205B2 (en) * 2018-11-01 2020-08-11 Nokia Technologies Oy Isolating false base stations in communication systems
WO2020091281A1 (ko) * 2018-11-02 2020-05-07 엘지전자 주식회사 무선 통신 시스템 엑세스 허가를 위한 단말의 대행 인증 방법 및 장치
CN111294821A (zh) * 2018-12-10 2020-06-16 索尼公司 用于回传网的电子设备、方法以及介质
CN109799719B (zh) 2019-01-31 2021-01-08 广东美的制冷设备有限公司 家电设备的控制方法、服务器、家电设备及存储介质
US11026061B2 (en) * 2019-02-05 2021-06-01 Motorola Solutions, Inc. Method for real-time talk-group creation within a push to talk for an Internet of Things system
CN110177344B (zh) * 2019-04-15 2021-12-24 海能达通信股份有限公司 一种组附着方法、客户端和服务器端
CN112040424B (zh) * 2019-06-04 2022-04-05 成都鼎桥通信技术有限公司 一种紧急抢占话权的方法和系统
US11647383B2 (en) * 2019-06-11 2023-05-09 Qualcomm Incorporated UE capability signaling techniques for wireless communications systems with relays
US11238866B2 (en) * 2019-06-17 2022-02-01 Motorola Solutions, Inc. Intelligent alerting of individuals in a public-safety communication system
CN113498615B (zh) * 2019-08-16 2022-12-20 Oppo广东移动通信有限公司 通信方法、终端设备和网络设备
EP4247115A3 (en) * 2019-10-04 2023-11-15 Samsung Electronics Co., Ltd. Method and device for activating 5g user
TWI761720B (zh) * 2019-10-24 2022-04-21 緯創資通股份有限公司 自適應設定存取點名稱的方法
US11632665B2 (en) * 2019-11-06 2023-04-18 Qualcomm Incorporated Proximity services session authorization and provisioning support over a 5G system
CN112822644B (zh) * 2019-11-18 2022-04-26 成都鼎桥通信技术有限公司 群组建立方法及设备
CN111311873B (zh) * 2020-02-24 2021-08-20 赣州光通电子有限公司 用于智能家庭的实时传输安防报警信息的方法及系统
CN113438652B (zh) * 2020-03-04 2022-12-23 维沃移动通信有限公司 一种授权和策略参数配置方法、终端及网络功能
US11825330B2 (en) * 2020-03-13 2023-11-21 Qualcomm Incorporated Techniques for quality of service support in sidelink communications
US11689957B2 (en) 2020-03-13 2023-06-27 Qualcomm Incorporated Quality of service support for sidelink relay service
CN111417102A (zh) * 2020-03-31 2020-07-14 倪航标 用于实时传输智能家居安防报警信息的方法及系统
CN111901840A (zh) * 2020-04-09 2020-11-06 中兴通讯股份有限公司 一种启动、重选方法、装置、设备和存储介质
CN113518319B (zh) * 2020-04-09 2023-03-17 华为技术有限公司 一种临近服务的业务处理方法、设备及系统
US11477848B2 (en) * 2020-06-29 2022-10-18 At&T Intellectual Property I, L.P. Disseminating alerts or other notifications using ProSe direct discovery signaling
KR102271638B1 (ko) * 2020-07-07 2021-07-02 (주) 큰사람커넥트 대용량 ｐｔｔ를 위한 sip 기반 서버
EP4185071A4 (en) * 2020-07-31 2023-08-30 Guangdong Oppo Mobile Telecommunications Corp., Ltd. SESSION ESTABLISHMENT METHOD, ELECTRONIC DEVICE AND STORAGE MEDIA
EP4171168A4 (en) * 2020-07-31 2023-08-02 Guangdong Oppo Mobile Telecommunications Corp., Ltd. METHOD, APPARATUS AND DEVICE FOR RELAY SESSION ESTABLISHMENT AND STORAGE MEDIUM
US11997668B2 (en) 2020-11-25 2024-05-28 Qualcomm Incorporated Resource selection with transmitter sensing
US11706764B2 (en) * 2020-11-25 2023-07-18 Qualcomm Incorporated Resource selection with sidelink receiver sensing
CN112752228B (zh) * 2020-12-11 2022-05-20 武汉信科移动通信技术有限公司 一种集群组呼下行承载建立方法及系统
JP2024509035A (ja) * 2021-01-28 2024-02-29 オッポ広東移動通信有限公司 データ伝送方法、端末装置及びネットワーク装置
US20220263605A1 (en) * 2021-02-18 2022-08-18 Qualcomm Incorporated Harq procedure for cooperative relay in sidelink networks
US11509493B1 (en) 2021-06-14 2022-11-22 Motorola Mobility Llc Electronic device that enables host toggling of presenters from among multiple remote participants in a communication session
US11743065B2 (en) 2021-06-14 2023-08-29 Motorola Mobility Llc Electronic device that visually monitors hand and mouth movements captured by a muted device of a remote participant in a video communication session
US11604623B2 (en) 2021-06-14 2023-03-14 Motorola Mobility Llc Electronic device with imaging based mute control
US11507342B1 (en) * 2021-06-14 2022-11-22 Motorola Mobility Llc Electronic device with automatic prioritization and scheduling of speakers in a multiple participant communication session
CN115412993A (zh) * 2022-09-02 2022-11-29 中国电信股份有限公司 中继发现方法、系统、设备及存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105163398B (zh) * 2011-11-22 2019-01-18 华为技术有限公司 连接建立方法和用户设备
KR20150120348A (ko) * 2013-02-28 2015-10-27 엘지전자 주식회사 근접 서비스 제공을 위한 그룹 통신 방법 및 장치
US10484838B2 (en) 2013-02-28 2019-11-19 Lg Electronics Inc. Group communication method and device for providing proximity service
WO2015026111A1 (ko) * 2013-08-18 2015-02-26 엘지전자 주식회사 무선 통신 시스템에서 중계기 동작 방법 및 장치
US10512022B2 (en) * 2013-11-05 2019-12-17 Sharp Kabushiki Kaisha Terminal apparatus, relay terminal apparatus, and communication control method
US9609680B2 (en) * 2014-03-18 2017-03-28 Qualcomm Incorporated Signaling flows and buffer status report for a group in device-to-device broadcast communication
US10142847B2 (en) * 2014-05-23 2018-11-27 Qualcomm Incorporated Secure relay of discovery information in wireless networks
US9338627B1 (en) * 2015-01-28 2016-05-10 Arati P Singh Portable device for indicating emergency events

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021220971A1 (ja) * 2020-04-27 2021-11-04 株式会社Ｎｔｔドコモ 端末及び通信方法
JPWO2021220971A1 (ja) * 2020-04-27 2021-11-04

Also Published As

Publication number Publication date
WO2017003161A1 (en) 2017-01-05
US10455406B2 (en) 2019-10-22
KR102591864B1 (ko) 2023-10-20
KR20180014421A (ko) 2018-02-08
EP3314978B1 (en) 2021-01-27
CN107852591B (zh) 2021-10-26
EP3314978A1 (en) 2018-05-02
EP3314978A4 (en) 2018-05-02
US20200053547A1 (en) 2020-02-13
JP6791885B2 (ja) 2020-11-25
CN107852591A (zh) 2018-03-27
US20160381720A1 (en) 2016-12-29

Similar Documents

Publication Publication Date Title
JP6791885B2 (ja) 端末のパケットデータネットワーク接続を生成する方法及び装置
JP7518842B2 (ja) ５ｇにおける接続指向の車両対全て（ｖｔｘ）通信のための装置、システム、方法、およびコンピュータ可読媒体
KR102505803B1 (ko) 디바이스 대 디바이스 통신을 지원하는 무선 통신 시스템에서 통신 방법 및 장치
US10506554B2 (en) Communication system
US20160381528A1 (en) Method and apparatus for providing service in a wireless communication system
CN104812025B (zh) 设备间发现及通信方法和系统
EP2830337B1 (en) Broadband digital trunking service implementation method and trunking scheduling management centre
EP2833694A2 (en) Method of relay discovery and communication in a wireless communications system
US20230354144A1 (en) Path Selection for Sidelink Communications in NR Network
WO2015117292A1 (zh) 一种设备到设备广播通信的方法和用户设备
CN103024682B (zh) 数字集群通信系统实现半双工单呼业务的方法
US20230096763A1 (en) Ran-5gc interactions for session join, session start, session leave, session stop, and session delete for 5g multicast broadcast services
CA2890030A1 (en) Scalable broadband group call via unicast downlink traffic consolidation and local re-broadcast
CN107852576B (zh) 用于在无线通信系统中提供服务的方法和装置
WO2021028549A1 (en) Sidelink rrc procedure
CN115396823B (zh) 一种传输业务数据的方法和通信装置
US11412354B2 (en) Terminal participating in group call established based on MCPTT service and method of operating the terminal
EP3376784A1 (en) Method and device for multi-service in wireless communications system
JP7399263B2 (ja) Ｉｏｐｓでのｍｂｍｓサポート
WO2022152625A1 (en) 5mbs smf service discovery for mb-smf
WO2020201317A1 (en) Presence service support for mission critical services
EP4049506A1 (en) Iops ip connectivity announcement method
Bindaj et al. DEVICE-TO-DEVICE (D2D) COMMUNICATION UNDER LTE NETWORKS USING HYBRID MODEL

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190403

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200217

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200309

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200609

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20201026

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201105

R150 Certificate of patent or registration of utility model

Ref document number: 6791885

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250