JP2006517064A5

JP2006517064A5 -

Info

Publication number: JP2006517064A5
Application number: JP2005518439A
Authority: JP
Filing date: 2004-03-01
Publication date: 2008-06-26

Description

一時的に対応不能なネットワークユーザーへのメッセージのルーティング方法、システム、およびネットワーク装置

本発明は、一時的に対応不能なネットワークユーザー、例えば、IPマルチメディアサブシステム（IMS）等の加入者への、例えば、マルチメディアメッセージサービス（MMS）通知等のメッセージのルーティング方法、システム、およびネットワーク装置に関する。

アクセスの独立性を達成し、インターネット全体の有線端末によるスムーズな相互運用を維持するために、例えば、3GPP規格のTS23.228に指定されているIMSは、IETF（インターネット技術特別調査委員会）の「インターネット規格」に適合するように開発されている。IPマルチメディアコアネットワーク（IMCN）によって、モバイルまたはセルラーネットワークのネットワークオペレータは、インターネットのアプリケーション、サービスおよびプロトコルに基づいてこれらを構築し、加入者に提供することができる。これが意図するところは、インターネットおよびIMCNサブシステムによって提供される機構を用いたインターネット空間にそれらを包含するモバイルネットワークのオペレータおよびサードパーティーのサプライヤによるこうしたサービスの開発である。従って、IMSは、無線ユーザーのための音声、映像、データおよびウェブベースの技術の変換や利用を可能にし、またインターネットの成長とモバイルコミュニケーションの成長の両立を可能にする。

図１は、上記の3GPP（第３世代移動体通信システムの国際規格検討機関）規格に基づくIMSネットワークのアーキテクチャを示す。このアーキテクチャは、例えばサービングコールステートコントロールファンクション（S-CSCF）をホームネットワークHNに設置する等の、ローミング加入者のための家庭用加入サービスのサービス制御がホームネットワークHNに存在するという概念に基づいている。図１に、現行または旧S-CSCFo10、および将来のまたは新規S-CSCFn12を示す。例えば、加入者のプロファイルまたはユーザー装置（UE）40のネットワークのサービス区域の変更によって生じる要求能力の変化によって端末装置またはユーザー装置UE40間の転送が可能になる。

一般的に、S-CSCFは、サービスを受けるUEのセッション制御サービスを行う。また、ホームネットワークHNまたは訪問先ネットワークVNに配置可能なアプリケーションサーバー（AS）60による提供が可能なサービスをサポートするためのネットワークオペレータが必要とするセッションの状態を維持する。オペレータのネットワーク内では、様々なS-CSCFが種々の機能を有することができる。それぞれのセッション中にS-CSCFによって実行される機能は、例えば、登録、セッションフローの管理、課金およびリソースの活用管理等である。加入者が訪問先ネットワークVNをローミングする場合、訪問先のネットワークVNは、ホームネットワークHNに配置され、サービス制御を提供するセッション制御をそれぞれのS-CSCFに渡すことが可能なProxy-CSCF（P-CSCF）30をサポートする。さらに、Interrogating-CSCF（I-CSCF）50は、そのネットワークオペレータの加入者、または現在そのネットワークオペレータのサービスエリア内に位置するローミング加入者への予約されたすべての接続のためのオペレータのネットワーク内のコンタクトポイントとしてホームネットワーク HN内に提供される。オペレータのネットワーク内に、複数のI-CSCFを置くことができる。I-CSCF50が実行する機能には、登録手続きを行うユーザーへのS-CSCFの割り当て、別のネットワークから受信したリクエストのS-CSCFへのルーティング、加入者データベースからのS-CSCFのアドレスの維持、例えば図１に示すホームサブスクライバサーバー（HSS）20、あるいはHSS20からの変更アドレスに基づいて確定したS-CSCFへのリクエスト送信または応答等が挙げられる。

P-CSCF30は、IMS内の最初のコンタクトポイントである。そのアドレスは、PDP（パケットデータプロトコル）コンテキストのアクティブ化に従ってUE40によって発見される。P-CSCF30は、プロキシのように機能する。すなわち、おそらくは変換後、内部的にリクエストを受け入れ、サービスの提供、または転送を行う。P-CSCF30は、ユーザーエージェントとしても機能することができる。すなわち、異常状態において終了させること、および独立して処理を生成することができる。P-CSCF30が実行する機能には、UE40からの登録のリクエストをUE40が提供するホームドメイン名を用いて決定されるI-CSCF、例えば、I-CSCF50に転送し、UE40にリクエストまたは応答を転送する。

さらに図１に示される、異なるCSCF要素の機能に関する詳細を上記3GPP規格より得ることができる。

IFTFは、"draft-ietf-sipping-reg-event"に定義されるように、登録のためのセッションイニシエーションプロトコル（SIP）イベントパッケージを定めている。このREGISTERメソッドによって、SIPは、ユーザーエージェントが登録を作成、修正および削除することを可能とする。（ユーザーエージェントは、ユーザーとネットワークとの間のインターフェース（例えば、ブラウザ）である。）登録は、ポリシーを執行するために管理者が変更することもできる。その結果、これらの登録は動的な変化が可能なネットワークにおける状態の一部を表すことになる。ユーザーエージェントが、この状態の変化の通知を受けたいとする場合が多くある。イベントパッケージは、これらのユーザーエージェントがこうした通知をリクエストおよび獲得できることによってある機構を形成する。

SIP REGISTERメソッドは、ユーザーエージェントが登録を操作するための方法を提供している。Contactは、追加および削除が可能で、現行の一連のContactのクエリーを行うことができる。登録は、管理者のポリシーを受けて変更することもできる。例えば、ユーザーに不正行為の嫌疑がある場合、いずれのリクエストも受けられないように、そのユーザーの登録を削除することができる。登録は、リフレッシュされなければ、しばらく後に期限切れとなる。このように、登録はネットワークが維持する動的な状態の一部を表す。SIP Events Frameworkでは、SIPシステムに関連するイベントの受信申込みおよび通知のための一般的なフレームワークが規定されている。このフレームワークは、SUBSCRIBE法およびNOTIFY法を規定し、またパッケージの概念を導入している。パッケージとは、例えば、登録の状態等のイベントの特定のクラスに対するイベントフレームワークの具体的なアプリケーションである。

登録パッケージ用のSUBSCRIBEメッセージは、受信申し込みをフィルタリングするためのボディ部を含んでいてもよい。このメッセージは、ボディ部の有無にかかわらず送信することができる。デフォルトの登録ポリシーでは、通知がSUBSCRIBEメッセージから発せられ、また受信申込みするリソースに対するいずれかの登録済みContactの状態の変更がある場合に毎回発行される。それらの通知には、状態が変更されたContactに関する情報が含まれるだけである。この通知は、特定のAddress-of-Recordと関連する一部またはすべてのContactを記載した登録情報ドキュメントのボディ部に含まれるNOTIFYメッセージを用いて転送される。

3GPP IMS Release 5規格のTS24.229、24.228および23.218では、SIP登録状態イベントパッケージがイベントパッケージの受信申込者へのユーザー登録状態に関する通知のために使用される。3GPP IMS Release 6では、例えばPresence、Messages、ConferencingおよびMMS等の新たなサービスがシステムに導入される。IMSネットワークの機能を用いることが可能なMMSのようなサービスがある。IMSネットワークは、SIP登録状態イベントパッケージを用いてユーザー登録状態に関する正確な情報を提供するとともに、例えば、SIP MESSAGEリクエストを用いてMMS通知を行うことも可能である。

IMS加入者は、IMS Release 5の規格に基づいて、登録あるいは登録の取り消しを行う。しかしながら、IMS加入者は、登録はされているが、例えば、バッテリー切れ等による加入者の現在の位置での一時的な無線サービス区域の喪失により到達不可能となることがある。これは無線サービス区域が何らかの理由で不均一である大都市やエリアにおいてはごく普通のことである。結果的に、IMSネットワークを用いる外部サービスは、サービスユーザーに到達できなければ通知を受けることができない。

従って、本発明の目的は、メッセージを転送するためのIMSネットワークを用いたアプリケーションサーバーに、サービスユーザーが対応不能であるかどうかを認識させることができるような方法、システム、およびネットワーク装置を提供することにある。

本目的は、一時的に対応不能なネットワークユーザーへのメッセージのルーティング方法であって、
・前記ネットワークユーザーの状態イベントパッケージを受信するように申し込むステップと、
・前記ネットワークユーザーが再び対応可能になった時又は前記ネットワークユーザーが再登録された時を示すべく前記ネットワークユーザーの状態が変わる時に通知を生成するステップと、
・前記通知の受信に応答して前記ネットワークユーザーへの前記メッセージのルーティングを行うステップと、
を含む、ルーティング方法によって達成される。

さらに、上記目的は、データネットワークにおいてネットワークユーザーのために働くネットワーク装置であって、前記ネットワークユーザーが未登録または登録済みであるが到達不可能であることを示す状態イベントパッケージを格納し、また前記状態が前記ネットワークユーザーが対応可能であることを示す場合に前記状態イベントパッケージの受信申込者への通知を生成するように構成される、前記ネットワーク装置によって達成される。

さらに、上記目的は、ネットワークユーザーへルーティングするメッセージを生成するためのネットワークサーバーであって、対応不能なネットワークユーザーの状態を受信するように登録、また前記対応不能なネットワークユーザーが対応可能であることを示す状態通知の受信に応答して、前記対応不能なネットワークユーザーへメッセージをルーティングするように構成される、前記ネットワークサーバーによって達成される。

最終的に、上記目的は、一時的に対応不能なユーザーへメッセージをルーティングするためのシステムであって、上述のネットワークサーバーおよびネットワーク装置を備える前記システムにより達成される。

よって、外部のアプリケーションサーバーは、ネットワークユーザーの登録状態を受信することへの申込みが可能で、従ってネットワークユーザーが登録されているかどうかの通知を受けることができる。

さらに、ネットワークユーザーは、登録されていても対応不能な場合がある。それに関し、前記IMSネットワークを利用する外部サービスは、IMSネットワークによる経験として対応可能性に関する通知を受けることができる。

本発明において、「対応可能」という用語は、加入者が到達可能でない場合の、すなわち、ネットワークユーザーが会議等により意図的に妨げられたくないような状況等の、すべてのシナリオに当てはまる意味において解釈される。

登録ステップは、前記ネットワークユーザーが対応不能か、または登録されていないことを示すメッセージの受信に応答して実行することができる。

さらに、通知は、登録状態が影響を受けなくても前記ネットワークユーザーが再び到達可能になったことを示す情報を含むことができる。特に、この情報は、イベントまたはフラグ情報である場合がある。前記ネットワークユーザーの端末装置が、発信セッションのセットアップまたは着信セッションのセットアップ試行が成功した後に、前記ネットワークユーザーが対応可能であることを示す状態に設定することができる。再登録は、前記ネットワークユーザーの再割り当てに関する通知に基づいて決定することができる。その後、受信申込は再登録の通知に応答してリフレッシュすることができる。

さらに有益な変形または発展形が従属クレームに明記される。

以下において、添付図面を参照しながら、好適な実施態様に基づき本発明を更に詳細に説明する。

好適な実施形態の説明

好適な実施態様を、図１に示すIMSネットワークにおけるMMS通知の配信に基づいて説明する。図１に示されるIMSアーキテクチャは、マルチメディアサービスを提供するためのパケット交換ドメインが提供するサービスを用いる一組のコアネットワークエンティティに関する。HSS20は、所与のユーザーのためのマスタデータベースであり、従来のホームロケーションレジスタ（HLR）の機能に加えて、例えばIMS等のようなIPネットワークに指定される新規の機能を備える。また、HSS20は、実際にコールあるいはセッションを扱うネットワークエンティティをサポートするため、加入関連情報を包含するエンティティである。

図２は、第１の好適な実施態様に基づく信号送信の模式図であって、加入者が再び登録されて対応可能になった場合に、AS60は登録状態イベントパッケージの登録済み／未登録情報を用いてUE40のIMS加入者へMMS通知を配信して通知を受ける。

第１の好適な実施態様によれば、IMSネットワークの既存の機能を利用したMMS通知のためのSIPベースのソリューションが提案されている。

MMSサーバーでありうるAS60が、IMSユーザーまたは加入者へMMS通知を配信しようとする場合、SIP MESSAGEリクエストを生成し、リクエストのペイロードとして直接的または間接的な通知を含める（ステップ1）。この時点でIMS加入者が登録されていない場合、MESSAGEリクエストがUE40に配信されるのではなく、むしろ例えば、SIP 480 Temporary Unavailable等のSIPエラー応答を用いて、デフォルトのS-CSCF、例えば、S-CSCFo10によって拒絶される。ここでAS60は、IMSネットワークアーキテクチャ内のSIP ASに対応し、SIP ユーザーエージェントとして作用する。AS60は自身のリクエストを生成可能であり、また例えば、Shインターフェース上のユーザーのS-CSCFのためのクエリーを行うか、またはI-CSCF50にリクエストを送信することによって、ユーザーの代理となりうると仮定される。また、ユーザーは現在登録されていないので、ユーザーが未登録の場合、登録状態の情報も提供されると仮定される。したがって、登録状態の提供は、未登録の状態にも関連するサービスに等しい。ユーザーが未登録の状態に関連したサービスを有する場合、すなわち、HSS20が未登録状態に対するユーザー情報を格納している場合、その後デフォルトのS-CSCFが割り当てられてリクエストを処理する。ユーザーは登録されていないので、UE40に対してS-CSCFo10が格納する経路がなく、その結果、4xx SIPの失敗応答に反応して、S-CSCFo10は、着信SIP MESSAGEリクエストを拒絶する。

経路生成に関する更なる詳細は、3GPP規格TS24.229から得ることができる。

図２によれば、I-CSCF50は、AS60からのSIP MESSAGEリクエストの受信に応答してHSS20（ステップ２）へのクエリーを開始し、ルーティング情報を得る。その後、ステップ３においてMESSAGEリクエストをデフォルトのS-CSCFo10に転送するが、ステップ４aおよび4bにおいてSIP 480 Temporary Unavailableの応答によってAS60に応答する。MESSAGEリクエストが拒絶されるため、AS60は、例えば、I-CSCF50へのリクエストの代用となって（ステップ５）以前に送信されたMESSAGEリクエストと同じ方法で、登録状態イベントに対してSUBSCRIBEリクエストを転送してユーザー登録状態の受信申込みを行うが、ステップ６においてユーザーのS-CSCFに対してクエリーを行うことができる。事実に基づき、以前に割り当てられたS-CSCFo10が割り当てを取り消されていてもいなくても、新しいデフォルトのS-CSCFを割り当ててSUBSCRIBEリクエストを処理する必要性が生じることがある。

ステップ７において、S-CSCFo10がSUBSCRIBEリクエストを受信する場合、IETF規格RFC3265によって要求されているように、認証して許可を与える必要がある。正常な申し込みは、ステップ８aおよび8bのSIP 200 OK応答によって承認される。3GPP IMSにおいて、認証はIETF規格RFC3325を用いて解決され、ここで、AS60はSIPリクエストに信頼できるアイデンティティを挿入する。これに基づいて、S-CSCFo10はAS60が特定のユーザー登録状態に対して許可を与えられた受信申込者であるかどうかを決定することができ、正しければ受信申込情報を組み込むことができる。HNの全てのアプリケーションサーバーは、3GPP規格N1-030285に基づいて登録のイベントパッケージの受信を申し込む許可を与えられる。

従って、HNに属していればAS60は許可を与えられる。

しかしながら、ステップ９においてユーザーまたはIMS加入者が（再び）登録した場合、ステップ10aおよび10bにおいてS-CSCFo10が送信するNOTIFYリクエストは、ユーザー登録状態の変更についてAS60に通知する。AS60は、ステップ11aおよび11bにおいて、SIP 200 OK応答によって受信を了解する。従って、AS60は、ステップ12および14（ステップ13においてI-CSCF50によるHSSクエリー）において、MESSAGEリクエストの再開およびS-CSCFo10を経由してUE40へのルーティングが可能になり、最終的にステップ15においてMMS通知をUE40のIMS加入者へ転送および配信することができる。

図３は、第２の好適な実施態様に基づく模式的な信号送信図であって、AS60は、受信申込情報のリフレッシュを用いて、新規に割り当てられたS-CSCFn12への受信申込状態の移行に基づいてUE40のIMS加入者へのMMS通知を配信する。

図３において、ステップ1〜9は、図２に示す第１の好適な実施態様と一致するため、それらの説明は簡素化の理由からここでは省略する。

しかしながら、ステップ９において、ユーザーまたはIMS加入者が（再び）登録する場合、割り当てられるS-CSCFは登録された状態に関連した適切な機能を有する必要があるため、新規のS-CSCFn12をそれに対して割り当てることが可能である。この場合、3GPP規格TS23.228に記載されているように、古いS-CSCFo10は、Cxインターフェースを経て再割り当て（ステップ10）について通知を受ける。この時点で、S-CSCFo10がユーザープロファイルをドロップする前に、ステップ11aおよび11bにおいて、値「終了」を含む受信申込状態ヘッダーを備えるSIP NOTIFYリクエストを発行することによって、新規に割り当てられたS-CSCFn12へ受信申込状態を移行する。AS60は、ステップ12aおよび12bにおいてSIP 200 OKの肯定応答に応答する。

IETF規格RFC3265に基づいて受信申込状態の移行を実行する場合、ステップ13において、AS60は再受信申込を開始する。ステップ14におけるI-CSCF50によるHSSクエリーの後、ステップ15においてSUBSCRIBEリクエストがS-CSCFn12に転送される。S-CSCFn12は、ステップ16aおよび16bにおいてSIP 200 OKの肯定応答に応答する。従って、移行を利用して、受信申込状態をリフレッシュするSUBSCRIBEリクエストは新規に割り当てられたS-CSCFn12で終了するが、そのS-CSCFn12は、上述のように認証および許可ステップを実行し、受信申込情報を組み込む。

これでユーザーまたはIMS加入者が登録されたため、ステップ17aおよび17bにおいて、新しいS-CSCFn12によって送信されるNOTIFYリクエストは、ユーザー登録状態の変更についてAS60に通知する。従って、肯定応答後（図示せず）、AS60は、ステップ18および20において、MESSAGEリクエストの再開およびS-CSCFn12（ステップ19におけるHSSクエリー）を経由するUE40へのルーティングが可能になり、最終的にステップ２1において、MMS通知をUE40のIMS加入者へ転送および配信することができる。

この時点でAS60は、ユーザー登録状態についての受信申込み状態の終了を決定するか、または受信申込状態を保持することがある。後者の場合であると仮定すれば、ユーザーがそれ自体の登録を取り消すか、またはネットワークがネットワーク起動登録取り消し手続きの実行を決定する場合に、申込が終了する。これは、S-CSCFn12がこの時点で割当てを取り消され、未登録状態を処理するために別のS-CSCFが割り当てられることがあるためである。この手続きは、3GPP規格のN1-030296およびTS24.229に記載されている。

従って、AS60の受信申し込みが終了する、すなわち値「終了」を含む受信申込状態ヘッダーを備えるNOTIFYリクエストを受信する場合、それでもユーザー登録状態に関する更なる情報を受信したいときには、S-CSCFn12に一致する受信申込状態をリフレッシュする必要がある。

第３の好適な実施態様によれば、ネットワークユーザーまたはIMS加入者は、登録はされるが、なお到達不可能であると識別される。これを実現するために、S-CSCFは、登録済み状態イベントパッケージまたは新規の状態イベントパッケージにおいて、この加入者が到達可能であるかどうかを示す更なる情報を維持するように適合させられる。一例として、加入者の現在の位置でバッテリー切れまたは一時的な無線サービス区域の喪失があれば、加入者は到達不可能になることが挙げられる。S-CSCFは、終端トラフィックが加入者に正常に配信されない場合、この状況を認識することができる。このように、加入者が登録されたが到達不可能である場合の状態に対する新しいイベント、すなわち「到達不可能」または「サービス区域外」が導入される。従って、加入者が登録される場合、状態は「到達可能」または「到達不可能」のどちらかになりうる。

特に、加入者への終端トラフィックが成功するか、または着信セッションのセットアップの試行が成功する場合、または端末装置またはUE40が通常の発信セッションのセットアップを行う場合、またはUE40の通常の再登録が行われる場合に、状態は「到達可能」に設定することができる。しかしながら、状態が「到達不可能」に設定されている場合は、やはり終端トラフィックを妨げない。しかし、例えば、MMSサーバー等のAS60からのメッセージ送信が失敗した場合、AS60は、加入者がいつ再び到達可能になったのかを調査するためにS-CSCFに受信申込を行うことができる。これを達成するために、AS60は、加入者の登録イベントパッケージまたは他の新規なイベントパッケージのために申し込みを受ける。

従って、登録イベントパッケージのためのより細かいデータの塊が提供されるため、このイベントパッケージへの申し込みを受けるAS60は、加入者の対応可能性についてより正確な情報を得ることができる。

図４は、UE40のIMS加入者の状態イベントパッケージへのAS60の申し込みを示す信号送信図を示す。ステップ1において、MMS通知は、IETF規格RFC3428において定義されるように、SIP MESSAGEリクエスト内でI-CSCF50へとルーティングされる。I-CSCF50は、ステップ２において、UE40のために働いている現在のS-CSCFo10へのルーティング情報を得るため、HSS20にクエリーを開始する。ステップ３において、I-CSCF50は、ルーティング情報を受信して、S-CSCFo10にSIP MESSAGEリクエストを転送する。その後、UE40が現在到達不可能であることを決定することができる。終端S-CSCFo10は、直接のメッセージが終端ユーザーへ転送されない時点で決定することができる。この決定は、あるアプリケーションロジック基づくか、または例えば、発信側の好みあるいは受信側の機能等に基づくことができる。必要な情報は、例えば、SIP 480 Temporarily Unavailable等の応答メッセージのエラーの原因における到達不可能状態を示すことができるP-CSCF30において得ることができる。IETF規格RFC 3261に基づいて、応答メッセージにおける理由フレーズをイベント状態情報の伝達に用いることができる。対応するStatus Lineは、次のようになる。

Status Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF

UE40の到達不可能状態の判定は、UE40にあてられたMESSAGEリクエストへの応答を待っているP-CSCF30での期限切れのタイムアウトに基づくことができる。その結果、P-CSCF30は、UE40が到達不可能であると仮定し、到達不可能状態を示す応答メッセージを生成する。

従って、加入者が見つかっていないか、または到達不可能であるかを示すメッセージSIP 480 Temporary Unavailableは、ステップ４aおよび4bにおいて、I-CSCF50を経てAS60へ発行される。

AS60は、この否定回答に応答して、I-CSCFを経てSIP SUBSCRIBEリクエストを転送し、ステップ５aおよび5bにおいて、S-CSCFo10にHSSクエリー（図示せず）を行う。S-CSCFo10は、ステップ６aおよび6bにおいて、I-CSCFを経てAS60へルーティングされるSIP 200 OKの肯定応答によって加入を承認する。モバイルを起源とする処理、モバイル端末処理またはUE40の再登録等の、S-CSCFo10によってUE40の正常な処理が決定されるとすぐに、S-CSCFo10は、ステップ７aおよび7bにおいて、AS60へI-CSCFを経て状態「登録済」およびイベント「到達可能」を備えるSIP NOTIFYリクエストを発行する。このNOTIFYリクエストは、ステップ８aおよび8bにおいて、SIP 200 OK応答を対応させてAS60が承認する。

従って、AS60は、UE40が再び到達可能になり、ステップ９（ステップ10におけるI-CSCFによるHSSクエリーを含む）に示すようにI-CSCF50を経た、またステップ11aから11cに示すようにS-CSCFo10およびP-CSCF30を経た、UE40へのMMS通知を備えるSIP MESSAGEの転送が現在可能であること通知される。UE40は、ステップ12aから12dにおいて、それに応答してSIP 200 OKの肯定応答をAS60に転送する。

その結果、AS60は、UE40の接続状態の通知を受けることができ、従ってMMS通知をUE40に正常に転送することが可能になる。

本発明は、上述の好適な実施態様に制限されない点に留意する。本発明は、あらゆるデータネットワークにおいて実行することが可能であって、加入者の登録状態への申し込みを実行することができ、それによって到達可能または到達不可能状態、または関係するネットワークユーザーの再登録を通知することができる。したがって、本実施態様は、添付の請求の範囲内で異なることがある。

本発明の好適な実施態様を実行できるネットワークアーキテクチャの模式的ブロック図を示す。第１の好適な実施態様に基づいて、IMS加入者への通知の配信を示すメッセージ信号送信および処理図を示す。第２の好適な実施態様に基づいて、IMS加入者への通知の配信を示すメッセージ信号送信および処理図を示す。第３の好適な実施態様に基づいて、登録状態イベントパッケージの受信申込みを示すメッセージ信号送信および処理図を示す。