JP6028085B2 - インターネット・プロトコル・マルチメディア・サブシステム（ｉｍｓ）における移動局国際サブスクライバ・ディレクトリ番号（ｍｓｉｓｄｎ）を用いないショート・メッセージ・サービス・モバイル発信／モバイル着信 - Google Patents

Description

関連出願の相互参照

本願は、2012年4月10日に提出された、米国特許仮出願第61/622,166号の優先権を主張するものである。先に提出された当該出願の内容全体を参照によって本願明細書に引用したものとする。

背景

［分野］
本発明の実施形態は、全般的に、次に限定はされないが、ユニバーサル・モバイル通信システム（UMTS：Universal Mobile Telecommunications System）地上無線アクセス・ネットワーク（UTRAN：UMTS Terrestrial Radio Access Network）、および/またはロング・ターム・エボリューション（LTE：Long Term Evolution）進化型UTRAN（E-UTRAN：Evolved UTRAN）などの、ワイヤレス通信ネットワークに関する。

［関連技術の説明］
ユニバーサル・モバイル通信システム（UMTS）地上無線アクセス・ネットワーク（UTRAN）は、基地局、すなわちNode B、および例えば無線ネットワーク・コントローラ（RNC：radio network controller）を備える通信ネットワークを指す。UTRANは、ユーザ機器（UE：user equipment）と、コア・ネットワークとの間の接続性を可能にする。RNCは、１つ以上のNode Bの制御機能性を提供する。RNCおよびそれに関連するNode Bは、無線ネットワーク・サブシステム（RNS：Radio Network Subsystem）と呼ばれる。E-UTRAN（進化型UTRAN）の場合、RNCは存在せず、RNCの機能性の多くはeNodeB（拡張Node B：enhanced Node B）に含まれる。

ロング・ターム・エボリューション（LTE）またはE-UTRANは、効率性およびサービスの改善、コストの低減、および新たなスペクトル機会の使用によるUMTSの改善を指す。具体的には、LTEは、少なくとも50メガビット/秒（Mbps：megabits per second）のアップリンク・ピーク速度と、少なくとも100Mbpsのダウンリンク・ピーク速度とを提供する3GPP標準である。LTEは、20MHzから、下は1.4MHzまでのスケーラブルなキャリア帯域幅をサポートし、周波数分割複信（FDD：Frequency Division Duplexing）および時分割複信（TDD：Time Division Duplexing）両方をサポートする。

上記のように、LTEは、3Gネットワークにおけるスペクトル効率を改善して、キャリアが所与の帯域幅でより多くのデータおよび音声サービスを提供できるようにすることも期待されている。したがって、LTEは、大容量音声のサポートに加えて、データおよびメディアの高速搬送に対する将来的なニーズを満たすよう設計されている。LTEの利点は、例えば、高スループット、低レイテンシ、同一プラットフォームにおけるFDDおよびTDDのサポート、エンドユーザ体験の改善、および低運用コストにつながる簡潔なアーキテクチャである。

3GPP LTEの後続リリース（例えばLTE Rel-10、LTE-Rel-11）は、将来の国際モバイル通信アドバンスト（IMT-A：international mobile telecommunications advanced）システムに向けたものである。本願明細書では、便宜上、これを単にLTEアドバンスト（LTE-A：LTE-Advanced）と呼ぶ。

LTE-Aは、3GPP LTE無線アクセス技術を拡張し、最適化することを目標としたものである。LTE-Aの目的は、データ速度の高速化およびレイテンシの低減により大幅に強化されたサービスを、より低いコストで提供することである。LTE-Aは、下位互換性を保ちながらIMTアドバンストに関する国際電気通信連合無線通信（ITU-R：international telecommunication union-radio）の要件を満たす、さらに最適化の進んだ無線システムとなるであろう。

インターネット・プロトコル（IP：internet protocol）マルチメディア・サブシステム（IMS：IP multimedia subsystem）は、IPマルチメディア・サービスを提供するための構造的枠組みである。IMSは、インターネットとの統合を促進するために、セッション開始プロトコル（SIP：session initiation protocol）などのインターネット技術タスク・フォース（IETF：internet engineering task force）プロトコルを可能な限り使用する。IMSは、ワイヤレス端末またはデバイスからの音声アプリケーションおよびマルチメディア・アプリケーションのアクセスを支援するよう設計されている。

摘要

ある実施形態は、ショート・メッセージ・サービス（SMS：short message service）メッセージを送信するデバイスのセッション開始プロトコル統一リソース識別子（SIP-URI：session initiation protocol uniform resource identifier）および/または国際モバイル・サブスクライバ・アイデンティティ（IMSI：International Mobile Subscriber Identity）を、ゲートウェイによって保存することを含む方法に関する。この方法は、送信するデバイスからSMSメッセージを受信すること、SMSメッセージの受信側である受信するデバイスのセッション開始プロトコル統一リソース識別子（SIP-URI）を取得することをさらに含んでもよい。受信するデバイスのSIP-URIは、SMSメッセージの「toヘッダ」から取得されてもよい。本方法は、受信するデバイスのホーム・サブスクリプション・サーバ（HSS：home subscription server）に、受信するデバイスの国際モバイル・サブスクライバ・アイデンティティ（IMSI）およびルーティング情報を問い合わせることと、受信するデバイスに、SMSメッセージを、国際モバイル・サブスクライバ・アイデンティティ（IMSI）およびルーティング情報を使用して配信することとをさらに含んでもよい。実施形態によっては、送信するデバイスまたは受信するデバイスのうちの少なくとも１つは、移動局国際サブスクライバ・ディレクトリ番号（MSISDN：mobile station international subscriber directory number）を有しない。

別の実施形態は、装置に関連する。この装置は、少なくとも１つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも１つのメモリとを備える。少なくとも１つのメモリおよびコンピュータ・プログラム・コードは、少なくとも１つのプロセッサとともに、装置に少なくとも、ショート・メッセージ・サービス（SMS）メッセージを送信するデバイスのセッション開始プロトコル統一リソース識別子（SIP-URI）および/または国際モバイル・サブスクライバ・アイデンティティ（IMSI）を保存することと、送信するデバイスからSMSメッセージを受信することと、SMSメッセージの受信側である受信するデバイスのセッション開始プロトコル統一リソース識別子（SIP-URI）を取得することとを行わせるよう構成される。受信するデバイスのSIP-URIは、SMSメッセージの「toヘッダ」から取得される。前記装置にはさらに、受信するデバイスのホーム・サブスクリプション・サーバ（HSS）に、受信するデバイスの国際モバイル・サブスクライバ・アイデンティティ（IMSI）およびルーティング情報を問い合わせることと、受信するデバイスに、SMSメッセージを、国際モバイル・サブスクライバ・アイデンティティ（IMSI）およびルーティング情報を使用して配信することとを行わせてもよい。実施形態によっては、送信するデバイスまたは受信するデバイスのうちの少なくとも１つは、移動局国際サブスクライバ・ディレクトリ番号（MSISDN）を有しない。

別の実施形態は、コンピュータ可読媒体上に具現化されたコンピュータ・プログラムを対象とする。このコンピュータ・プログラムは、プロセスを実行するようにプロセッサを制御するよう構成される。当該プロセスは、ショート・メッセージ・サービス（SMS）メッセージを送信するデバイスのセッション開始プロトコル統一リソース識別子（SIP-URI）および/または国際モバイル・サブスクライバ・アイデンティティ（IMSI）を保存することを含む。前記プロセスは、送信するデバイスからSMSメッセージを受信すること、SMSメッセージの受信側である受信するデバイスのセッション開始プロトコル統一リソース識別子（SIP-URI）を取得することをさらに含んでもよい。受信するデバイスのSIP-URIは、SMSメッセージの「toヘッダ」から取得されてもよい。プロセスは、受信するデバイスのホーム・サブスクリプション・サーバ（HSS）に、受信するデバイスの国際モバイル・サブスクライバ・アイデンティティ（IMSI）およびルーティング情報を問い合わせることと、受信するデバイスに、SMSメッセージを、国際モバイル・サブスクライバ・アイデンティティ（IMSI）およびルーティング情報を使用して配信することとをさらに含んでもよい。実施形態によっては、送信するデバイスまたは受信するデバイスのうちの少なくとも１つは、移動局国際サブスクライバ・ディレクトリ番号（MSISDN）を有しない。

別の実施形態は、ユーザ機器によってショート・メッセージ・サービス（SMS）メッセージを構築することを含む方法に関連する。前記構築することは、SMSメッセージの受信側である受信するデバイスが移動局国際サブスクライバ・ディレクトリ番号（MSISDN）を用いずにアドレス指定されることを示すよう設定された値を、SMSの転送プロトコル宛先アドレス（TP-DA：transfer protocol destination address）フィールドに入れること、リクエスト統一リソース識別子（R-URI：request uniform resource identifier）に、ショート・メッセージ・サービス・センターのパブリック・サービス・アイデンティティ（PSI：public service identity）またはアドレスを設定すること、およびSMSの「toヘッダ」に、受信するデバイスのセッション開始プロトコル統一リソース識別子（SIP URI）を設定することを含む。前記方法は、続いて、SMSをゲートウェイに送信することを含んでもよい。

別の実施形態は、装置に関連する。この装置は、少なくとも１つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも１つのメモリとを備える。少なくとも１つのメモリおよびコンピュータ・プログラム・コードは、少なくとも１つのプロセッサとともに、装置に少なくとも、ショート・メッセージ・サービス（SMS）メッセージを構築させるよう構成される。前記構築は、SMSメッセージの受信側である受信するデバイスが移動局国際サブスクライバ・ディレクトリ番号（MSISDN）を用いずにアドレス指定されることを示すよう設定された値を、SMSの転送プロトコル宛先アドレス（TP-DA）フィールドに入れること、R-URIに、パブリック・サービス・アイデンティティ（PSI）を設定すること、およびSMSの「toヘッダ」に、受信するデバイスのセッション開始プロトコル統一リソース識別子（SIP URI）を設定することを含む。前記装置にはさらに、SMSをゲートウェイへ送信させてもよい。

別の実施形態は、コンピュータ可読媒体上に具現化されたコンピュータ・プログラムに関連する。このコンピュータ・プログラムは、プロセスを実行するようにプロセッサを制御するように構成される。前記プロセスは、ショート・メッセージ・サービス（SMS）メッセージを構築することを含む。前記構築することは、SMSメッセージの受信側である受信するデバイスが移動局国際サブスクライバ・ディレクトリ番号（MSISDN）を用いずにアドレス指定されることを示すよう設定された値を、SMSの転送プロトコル宛先アドレス（TP-DA）フィールドに入れること、R-URIに、パブリック・サービス・アイデンティティ（PSI）を設定すること、およびSMSの「toヘッダ」に、受信するデバイスのセッション開始プロトコル統一リソース識別子（SIP URI）を設定することを含む。プロセスは、続いて、SMSをゲートウェイへ送信することを含んでもよい。

別の実施形態は、送信するデバイスから移動局国際サブスクライバ・ディレクトリ番号（MSISDN）を用いずに送信されたショート・メッセージ・サービス（SMS）メッセージを含むセッション開始プロトコル（SIP）メッセージを、ユーザ機器によってゲートウェイから受信することと；送信するデバイスのアイデンティティを判断するために、p-asserted-identityヘッダを使用してSMSメッセージをデコードすることとを含む方法に関連する。

別の実施形態は、装置に関連する。前記装置は、少なくとも１つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも１つのメモリとを備える。前記少なくとも１つのメモリおよびコンピュータ・プログラム・コードは、少なくとも１つのプロセッサとともに、前記装置に少なくとも、送信するデバイスから移動局国際サブスクライバ・ディレクトリ番号（MSISDN）を用いずに送信されたショート・メッセージ・サービス（SMS）メッセージを含むセッション開始プロトコル（SIP）メッセージを、ゲートウェイから受信することと；送信するデバイスのアイデンティティを判断するために、p-asserted-identityヘッダを使用してSMSメッセージをデコードすることとを行わせるよう構成される。

別の実施形態は、コンピュータ可読媒体上に具現化されたコンピュータ・プログラムを対象とする。このコンピュータ・プログラムは、プロセスを実行するようにプロセッサを制御するよう構成される。前記プロセスは、送信するデバイスから移動局国際サブスクライバ・ディレクトリ番号（MSISDN）を用いずに送信されたショート・メッセージ・サービス（SMS）メッセージを含むセッション開始プロトコル（SIP）メッセージを、ゲートウェイから受信することと；送信するデバイスのアイデンティティを判断するために、p-asserted-identityヘッダを使用してSMSメッセージをデコードすることとを含む。

本発明を適切に理解するために、添付の図面を参照されたい。

実施形態によるシグナリング図を示す。 実施形態によるシグナリング図を示す。 実施形態によるシグナリング図を示す。 別の実施形態によるシグナリング図を示す。 別の実施形態によるシグナリング図を示す。 別の実施形態によるシグナリング図を示す。 実施形態による装置を示す。 一実施形態による方法のフローチャートを示す。 別の実施形態による方法のフローチャートを示す。 別の実施形態による方法のフローチャートを示す。 別の実施形態による方法のフローチャートを示す。

詳細説明

インターネット・プロトコル（IP）マルチメディア・サブシステム（IMS）上でのショート・メッセージ・サービス（SMS）配信は、TS23.204により3GPPリリース7以降規定されている。SMSのルーティングは、IMSデバイスの場合でも依然として移動局国際サブスクライバ・ディレクトリ番号（MSISDN）に基づいている。結果として、TS23.204で定義されたSMS over IPアーキテクチャでは、SMSを正しくルーティングするには受信側のMSISDNを使用する必要がある。さらに、受信側のデバイスが送信側を識別してこのSMSに返信するために、送信側のMSISDNも必要である。

3GPPは、3GPPリリース11の中で、MSISDNを用いずにIMSにおいてSMSをサポートする方法についての検討をTR23.863において開始した。この検討における１つの論題は、MSISDNなしのIMSユーザ機器（UE）間の、SMSを介した通信である。MSISDNを用いない場合、「SMS over IP」は、ルーティング、機能ノードの挙動、およびデバイスの手続に、いくつかの根本的な変更を要する。したがって、本発明の実施形態は、MSISDNを使用しないSMS配信に関係する。

TR23.863では、１つの選択肢が「IP-SM-GWインターワーキングを用いた直接配信（Direct delivery with IP-SM-GW interworking）」に関するセクション5.2.1において提案されている。要約すると、当該ソリューションでは、以下の案が提案されている。
１．送信するユーザ機器（UE）が、その送信側のセッション開始プロトコル-統一リソース識別子（SIP-URI）および受信側のSIP-URIを、SMSペイロード内に埋め込む。
２．SMSプロトコル・レベルにおいて、送信するUEは、受信するUEのアイデンティティがSMSペイロード内にあることをインターネット・プロトコル・ショート・メッセージ・ゲートウェイ（IP-SM-GW：internet protocol short message gateway）に示す所定の「MTショート・コード（MT short code）」を転送プロトコル宛先アドレス（TP-DA）に入れ、ルーティング・プロトコル発信アドレス（RP-OA：routing protocol originating address）には、送信するUEのアイデンティティがSMSペイロード内にあることをIP-SM-GWに示す所定の「MOショート・コード（MO short code）」が入れられる。
３．IP-SM-GWは、受信するUEのセッション開始プロトコル統一リソース識別子（SIP-URI）をSMSペイロードから取得して、着信側のサービング呼セッション制御機能（S-CSCF：serving call session control function）へのルーティングのために、ホーム・サブスクリプション・サーバ（HSS）に問い合わせを行う。
４．IP-SM-GWは、RP-OAおよびTP-OAにそれ自体のアドレスを入れて、R-URIおよびToヘッダ＝受信するUEのSIP URIであるSIP MESSAGEを、着信側S-CSCFへ送信する。
５．着信側デバイスは、SMSペイロードをパース（parse）し、送信するUEのSIP URIを発見して、それをSMS返信に使用する。

しかしながら、上記の手続にはいくつかの欠点がある。例えば、SMSペイロードが、事実上、かなり小さくなる（例えば、160文字−（送信側のSIP URI＋受信側のSIP URI））。この場合、１つのSMSを複数部分に分割する必要が生じ得るため（すなわちSMSセグメント化を行う必要が生じ得るため）、このことは、課金に影響を及ぼすこともあり得る。もう１つの欠点は、所定のショート・コード（short code）がUEに供給されなければならないということである。非アクセス層（NAS：non-access stratum）ベースのSMSとの互換性が欠けている。IP-SM-GWに対して何らかの変更等を行わない限り、保存および転送もサポートされない。なお、保存および転送は、ショート・メッセージ・サービス・センター（SMSC：short message service center）によって提供される機能性である。なおSMSCは、本明細書で開示される技術では利用されない

図1aは、本発明の実施形態による、送信するデバイス（例えばUE-A）からMSISDNを用いずにSMSをサブミットすることに関するシグナリング図を示す。図1aに示されているように、ステップ1にて、IP-SM-GW-Aが、サードパーティ・レジストレーション（3rd party registration）の一環として含まれている。IP-SM-GW-Aは、あるパーティー（例えばUE-Aおよび/またはUE-B）がMSISDNを有しないことを認識しており、S-CSCFからサードパーティ・レジストレーションの一環として受信したUE-AのSIP-URI（IMSパブリック・ユーザ・アイデンティティ（IMPU：IMS public user identity）およびIMSプライベート・ユーザ・アイデンティティ（IMPI：IMS private user identity））または国際モバイル・サブスクライバ・アイデンティティ（IMSI）を保存する。IP-SM-GW-Aは、IMPU/IMSIおよび/またはSIP-URIをサードパーティ・レジストレーション手続の一環として受信しなかった場合は、この情報を取得するために、UE-AのHSSに問い合わせることができる。UE-AがSMS（例えば、モバイル発信SMS（MO：mobile originated SMS）またはモバイル着信SMS（MT：mobile terminated SMS））を構築し、続いてそのSMSが、既存の手続に基づいてIP-SM-GW-Aに配信されてもよい。

図1bは、一実施形態による、登録手続のシグナリング図の例を示す。図1bに示されているように、1にて、UEがIP接続を確立する。IP接続の確立後、任意の時点の2において、UEが、IMS登録手続に従ってS-CSCFに登録する。次に、3にて、S-CSCFが、IMS登録手続の間にHSSから取得した初期フィルタ基準を確認する。IMS登録に成功した後、取得された初期フィルタ基準に基づき、4にてS-CSCFが、ユーザの登録についてIP-SM-GW（AS）に通知する。UEのIMSサブスクリプション・プロファイル内にMSISDNがない場合、IMSIも、IP-SM-GW（AS）に通知されてもよい。5にてIP-SM-GW（AS）は、OKメッセージをS-CSCFに返し、6にてIP-SM-GW（AS）は、IP-SM-GW登録リクエストをHSSに送信する。HSSは、受信したIP-SM-GWアドレスを、必要に応じて保存し、またはMSISDNを用いないMT-SMSの場合、UEがIMSを介してアクセス可能であるという通知情報（indication）として使用して、メッセージ・ウェイティング・フラグ（message waiting flag）が設定されていればアラート・サービス・センター（Alert service center）メッセージをトリガする。7にて、HSSは、IP-SM-GW登録レスポンスによりIP-SM-GW（AS）に応答する。IP-SM-GWは、登録イベント・パッケージからのTEL-URIを用いないSMS配信のためにIMPU（SIP URI）を得る。IP-SM-GW登録レスポンスは、サブスクライバ・データ内に、このユーザに対して使用されるSCアドレスを含むことができる。IP-SM-GWアドレスのHSSでの登録が成功した後、8にてHSSは、メッセージ・ウェイティング・データ（message waiting data）が保存されているかどうかを確認し、すべてのSCにアラートを発する。

図1aに戻る。実施形態によれば、受信するデバイス（UE-B）にはMSISDNがないので、UE-Aは、TP-DAフィールドにダミー値（例えば000000s）を入れる。この実施形態では、UE-Aは、MESSAGEにおいて、R-URI（リクエスト統一リソース識別子）にパブリック・サービス・アイデンティティ（PSI）（例えば、ショート・メッセージ・サービス・センター・アドレス）を設定し、ToヘッダにUE-BのSIP-URIを設定する。プロキシ呼セッション制御機能（P-CSCF：proxy call session control function）は、例えば、MESSAGEをサービング呼セッション制御機能（S-CSCF）に送信する前に、p-asserted-identityにUE-AのデフォルトURIを入れる。本実施形態では、UE-Aには、MSISDNがないので、tel URIもない。したがって、デフォルトURIとは、UE-AのSIP URIである。S-CSCFは、iFCを実行し、MESSAGEをIP-SM-GW-Aに転送する。

図1aにさらに示されているように、ステップ2にて、IP-SM-GW-Aは、ToヘッダからUE-BのSIP URIを取得する。IP-SM-GW-Aは、UE-Bのホーム・サブスクライバ・サーバ（HSS）（HSS-B）に、UE-BのIMSIおよびSMSルーティング情報を問い合わせる。基本的には、HSSと、マシン・タイプ通信インターワーキング機能（MTC-IWF：machine type communication interworking function）との間のマシン・タイプ・トリガリング・メッセージのために、TS23.682で定義された「サブスクライバ情報リクエスト（Subscriber Info Request）」メッセージが、再利用されてもよい。TS23.682で定義された外部アイデンティティ（external identity）は、デバイス固有識別子であり、ここではIMSパブリック・ユーザ・アイデンティティ（IMPU）、すなわちSIP URIを含むよう設定されるということを明確化しておく。したがって、IP-SM-GWがUE-Bの外部識別子としてSIP URIを用いてHSSに問い合わせると、HSSはIMSI-Bを返す。その結果、ステップ3にてHSSは、UE-BのIMSIおよびUE-BへのSMS配信に関わるUE-Bの現在のサービング・ノードを返す。

一実施形態によれば、図1aのオプション1に示されているように、IP-SM-GW-Aが直接、SMSをUE-Bに、IP-SM-GW-Bを介して配信することをポリシーが許可する。上記で説明したステップ3において、IP-SM-GW-Aが、TP-DAがダミー値を有すること、およびToヘッダがSIP URIを含むことを検出し、その結果として、ステップ4aにおいてIP-SM-GW-Aは、まずSMSCを通すことなく、IMSドメインを介した直接配信を試行してもよい。IP-SM-GW-Aは、ステップ3に基づき、IP-SM-GW-Bのアドレスを認識している。IP-SM-GW-Aは、｛p-asserted-identity：AのSIP-URI，To：BのSIP-URI,R-URI＝IP-SM-GW-B,SMS Deliver｝｛TP-OA＝ダミー,RP-OA＝IP-SM-GW-A,RP-DA＝BのIMSI，smsペイロード｝を有するSIP MESSAGEを構築する。ステップ4bにおいて、IP-SM-GW-Bが、それ自体のURIを一番上のp-asserted-identityに追加して、UE-Bが確実に配信レポートをIP-SM-GW-Bに送信するようにする。IP-SM-GW-Bは、Toヘッダ・フィールドにおいて受信したUE-BのSIP URIを使用して、SIP MESSAGEをUE-Bに配信する。UE-Bは、p-asserted-identityの一番上のURIを保存して削除し、それを配信レポートのR-URIとして使用する。p-asserted-identityに残ったURIは、UE-AのSIP URIを含む。IMSを介してUE-Bに到達可能でなければ、IP-SM-GW-Bは、回線交換（CS：circuit switched）またはサービングGPRSサポート・ノード（SGSN：Serving GPRS Support Node）を介した配信を試行してもよい。これは、IP-SM-GWがHSSクエリを介してUE-BのSIP URIをIMSI-Bに変換しなければならないということを除いては、現在の手続に基づく。

ステップ4cにおいて、成功または失敗通知がIP-SM-GW-Aに返送される。UE-Bは、一時的に圏外であることも、またはメモリが一杯であることもあり、それにより配信の失敗が生じ得る。ステップ4dにおいて、IP-SM-GW-Aは、保存および転送機能のためにUE-AのSMSCにこのSMSをサブミットする。

図1aに示されたオプション2または3など、一部の実施形態によると、直接配信が許可されず、シグナリングがまずSMSCを通過しなければならないと仮定される。例えば、IP-SM-GW-Aは、SMSをSMSC-Aにサブミットする。実施形態によっては、UE-AのSIP URIも含められるオプション2（ステップ5）に関する新たな追加と併せて、IP-SM-GW-Aは、SMSCとMTC-IWF（T4参照点）との間のマシン・タイプ・トリガリング・メッセージのためにTS23.682で定義されたサブミット・トリガ（Submit Trigger）を再利用する。オプション3の場合、ステップ6に示されているように、UE-AのIMSIのみが含められ、T4に対する拡張は何ら要求されない。

なお、図1aは、２つの別々のゲートウェイ（例えばIP-SM-GW-AおよびIP-SM-GW-B）を示すが、一部の実施形態は、単一のゲートウェイしか備えなくてもよい。

図1cは、一実施形態による、MSISDNを用いないSMSメッセージ・モバイル発信手続を示すシグナリング図の例を示す。図1cに示されているように、1にて、UE-Aは、IMS登録手続に従ってS-CSCFに登録する。2にて、UE-Aは、カプセル化されたショート・メッセージ（SMS-SUBMIT,SCアドレス）を適切なSIPメソッドを使用してS-CSCFへサブミットしてもよい。受信側UEにはMSISDNがないので、UE-Aは、TP-DAフィールドに、受信側UEがMSISDNを用いずにアドレス指定されることを示す値を入れ、受信側のSIP URIをSIP MESSAGE内で示してもよい（例えば、UE-AはMESSAGEにおいて、R-URIにPSI（SMSCアドレス）を設定し、Toヘッダに受信側のSIP URIを設定する）。P-CSCFは、MESSAGEをS-CSCFへ送信する前に、UE-AのデフォルトURIをp-asserted-identityに入れてもよい。続いて、3にて、S-CSCFは、カプセル化されたショート・メッセージ（SMS-SUBMIT,SCアドレス）を、保存されているiFCに基づいてIP-SM-GW（AS）へ転送してもよい。IP-SM-GW（AS）は、4にて、SIPメッセージの受信確認を行ってもよい。続いて5にて、SIPメッセージの受信確認は、S-CSCFによりUE-Aへ転送されてもよい。

一実施形態では、IP-SM-GWは、保存されているサブスクライバ・データに基づいてサービス承認を実行してもよい。ショート・メッセージがCSまたはPSドメインを介して配信される場合にMSC/SGSNによって実行される承認と同様に、IP-SM-GWは、サブスクライバがショート・メッセージ・サービスの使用を承認されているかどうかを確認してもよい（例えば、事業者決定制約（Operator Determined Barring）設定）。さらにIP-SM-GWは、ユーザが、IMSを介したカプセル化されたショート・メッセージの配信の使用を承認されているかどうかも確認してもよい。サービス承認の結果が否定的であれば、IP-SM-GWは、メッセージを転送してはならず、適切なエラー情報を失敗レポートの中でUEに返してもよい。その他の場合、IP-SM-GW（AS）は、ショート・メッセージ（SMS-SUBMIT）を抽出して、SMS-DELIVERを構築し、それを6にて着信側IMSネットワークへ向けて送信する。7にて、着信側IMSネットワークは、SMを、指定された受信側へ向けて配信しようと試行する。8a、8b、または8cにて、着信側IMSネットワークは、以下のうちの１つにより応答する：8a）着信側IMSネットワークは、恒久的エラーを返送することによって、MSISDNなしの動作によるSMS配信を拒否するか、または許可しない；8b）着信側IMSネットワークは、指定された受信側にSMを配信できず、後からの再試行を可能にするために相関ID（correlation ID）を返し、続いてIP-SM-GWが、SMを、保存および転送動作のためにSMSCに転送する；または8c）着信側IMSネットワークは、指定された受信側に向けてSMを配信するのに成功。9にて、ステップ8a、8b、または8cで決定した適切なレスポンス・レポートがUE-Aに返される。8aの場合、レスポンスは、この受信側へのSMSが恒久的に失敗したことをUE-Aに示す。8bの場合、レスポンスは、SMSCから受信されるサブミット・レポート（Submit report）である。8cの場合、レスポンスは、受信側へのSM配信の成功を示す。

図2aは、一実施形態による、SMSC-AがUE-Bへ向けてSMSを配信する方法を示すシグナリング図を示す。図2aのステップ1は、上記で説明した図1aに示されたサブミットの部分に対応する。図2aのステップ2にて、SMSC-Aは、配信のためにIP-SM-GW-Bを選択して、IP-SM-GW-Bに、forwardshortMsgを伴うSMSを送信する。このメッセージは、UE-AのSIP URIまたはIMSIを含む。TP-OAフィールドには、受信側UE（例えばUE-B）がMSISDNを用いずにアドレス指定されることを示す値が入れられる。例えば、一実施形態では、これは、TP-OAフィールドに何らかのダミー値（例えば000s）を設定することによって行われてもよい。ステップ3にて、IP-SM-GW-Bは、UE-AにMSISDNがないことを、TP-OAフィールド内のダミー値、またはUE-AのSIP URIが含まれていることから認識する。IMSIのみが受信されれば、IP-SM-GW-Bは、UE-AのSIP URIを、例えばShインターフェースを介してHSS-Aに問い合わせる。

図2aのステップ4にて、IP-SM-GW-Bは、SIP MESSAGEをUE-Bに配信するが、これは、IP-SM-GW-BがHSSにおけるSIP URI（すなわち外部識別子）-IMSIバインディングを使用でき、HSSに問い合わせることによりIMSI-BをUE-BのSIP URIに変換するということを除いては、図1aのステップ4bと同様に行われる。IP-SM-GW-Bが、（例えば以前のHSSクエリから）このSIP-URIとIMSIとのバインディング情報を保存していれば、この追加のHSSクエリは不要である。IP-SM-GW-Bは、UE-Bが、MSISDNなしのUEからのSMSをデコードできることを認識している（すなわち、例えばSIP REGISTERおよびサードパーティ・レジストレーション手続における新たな機能タグなど、UE-Bの能力は先に通知されている）。当該SMSがMSISDNなしのUEからであることをUE-Bに通知するために、SIP MESSAGEにおける新たな通知情報が使用されてもよい。

いくつかの実施形態では、UE-BはTP-OA値を使用しない。代わりにUE-Bは、上記で説明したように、p-asserted-identityヘッダを使用して送信側の（UE-A）アイデンティティを判断してもよい。

いくつかの実施形態では、UE-Bは、TP-OAのダミー値を使用して、第1のp-asserted-identityヘッダがIP-SM-GW-Bのアドレスを搬送し、他のp-asserted-identityヘッダが送信側のアイデンティティ（すなわちUE-A）を搬送すると判断してもよい。

いくつかの実施形態では、IP-SM-GW-Bは、送信側のSIP URIが他のSIPヘッダ内、例えばReferred-Byにおいて搬送されることをUE-Bに示すダミー値を、TP-OAに入れてもよい。

Deliver-reportについては、メッセージの受信確認にMSISDNを使用しないので、TS23.040およびTS24.341に定義された既存のメカニズムを再利用可能である。唯一の違いは、UE-BにはMSISDNもtel URIもないため、IP-SM-GW-Bが、UE-BのSIP URIを、deliver-reportを搬送するMESSAGE内のp-asserted-identityにおいて受信し、IP-SM-GW-Bが、UE-BのSIP URIを使用して、deliver-reportを以前のSMS-deliverにバインディングする必要があるかもしれないということである。なお、この要件は、SMS-over-IPが使用されるときのTS23.682におけるMSISDNなしのT4にも当てはまる。

submit-reportについては、メッセージの受信確認にMSISDNを使用しないので、TS23.040に定義された既存のメカニズムが再利用可能である。唯一の違いは、UE-AにはMSISDNもtel URIもないため、IP-SM-GW-Aが、submit-reportを搬送するMESSAGE内のR-URIにある、UE-AのSIP URIを使用する必要があるかもしれないということである。

status-reportについては、SMS-deliverおよび上記で説明したのと同様のメカニズムが使用される。唯一の違いは、status-reportは、TP-OAを含まないが、代わりにTP-RA（受信側アドレス）を含むということであると思われ、これは現在、配信ステータスがレポートされるSMSのもとの受信側のMSISDNでなければならない。SMSCは、宛先の（例えばUE-B）IMSIしか認識していない。したがって、SMSCは、TP-RAにおいてIMSIを使用することができる。これは、モバイル・アプリケーション・パート（MAP：mobile application part）に対する拡張でもあるが、同じくTS23.682にある、SMS配信のMSISDNなしの動作のためにいずれにせよ要求されるものと類似する。IP-SM-GWは、SMSCからstatus-reportを受信すると、図1aのオプション3と同様に逆HSSクエリを行って、IMSIをSIP URIに変換する必要があるかもしれない。実施形態によっては、IP-SM-GWは、SIP URIがSIPヘッダ内、例えばReferred-Byにおいて搬送されることをUEに示すダミー値を、TP-RAに入れてもよい。

Alert-SC手続については、現在、HLRおよびMSC/SGSN/IP-SM-GWの間に要求されるMAPサービスは、再送されるSMSを識別するために、MSISDNまたはMSISDN-alert（すなわちIMSIが複数のMSISDNを有する場合）の使用を要求する。このMAPサービスには、MAP-ALERT-SERVICE-CENTREサービス、MAP-INFORM-SERVICE-CENTRE、MAP-REPORT-SM-DELIVERY-STATUSサービスが含まれる。一実施形態によれば、MAPは、UE-BのSIP URIを搬送するよう拡張され、既存のMSISDNまたはMSISDN-alertにダミー値（例えば0s）が設定される。

IMSソリューション空間については、IP-SM-GW-Bは、SMS配信が失敗すると、Shインターフェースを使用して、UE-BのHSSにおいてメッセージ・ウェイティング・フラグをアクティブに設定することができる。UE-Bが、再度アクティブになるか、またはそのメモリがSMSの受信に再度利用可能となったことを示すと、IP-SM-GW-Bは、UE-BのHSSに再試行するよう通知することができる。再試行のためにHSSは、SMSC-AにUE-BのIMSIを用いて通知し、図2aのSMSC-Aおよびステップ2が繰り返される。なお、Alert-SCに関するこの要件は、TS23.682のMSISDNなしのT4にも当てはまる。

複数のデバイス間のIMSアイデンティティの共有に関して、現在のIMS仕様によれば、SIP URI（IMSパブリック・ユーザ・アイデンティティ）は複数のIMSクライアント間で共有されることが可能である。Tel URIにも同じことが当てはまり、Tel URIは、IMSドメインにおいて共有され得るが、CSドメインでは単一のIMSI、ひいては単一のデバイスに拘束される。現在のSMS over IP（TS24.341）は、これを次の方法で解決する：IMSでは、MT SMS-deliverは決してフォークされない（これは、「no-fork」命令をMESSAGE内に設定することによって保証される）。これは、SMS-deliverを搬送するMESSAGEが、１つのデバイスのみに配信されることを意味する。同様の形で、SMS-status-reportは、１つのデバイスのみに送信され、このデバイスは、ステータスがレポートされるSMSをもともと送信した同じデバイスでないことさえあり得る。SMS-submit-reportは、登録されたすべてのデバイスに送信されるが、もとのSMSをサブミットしなかったデバイスは、SMS-submit-reportを搬送するMESSAGE内のIn-Reply-Toヘッダ内のCall-idに従ってレポートを無視できる。

図2bは、実施形態による、配信のためにSMSCに転送されるSMSを示すシグナリング図の例を示す。例として、直接配信が失敗した場合（例えば図1cのステップ8b）、またはSMSの再配信が必要とされ得る他の任意の理由で、SMSを配信のためにSMSCに転送する必要が生じ得る。図2bに示されているように、1にて、IP-SM-GWがSMを、図1cのステップ8bにおいて受信された相関IDとともにSMS-SC/SMS-IWMSCに転送してもよい。2aにて、SMS-SC/SMS-GMSCは、HSSからSMSの再配信のトリガを受信して、相関IDを使用してサービング・ノード情報をHSSに問い合わせてもよい。実施形態によっては、相関IDは、着信側ネットワークのIP-SM-GWをポイントする。2bにて、SMS-GMSCは、ステップ2aにおいてHSSから受信されたアドレスを使用してIP-SM-GWにSMを転送してもよい。続いて、3aおよび3bにて、IP-SM-GW（着信側）が、HSSに問い合わせを行い、この相関IDに対応する、送信側および受信側のアイデンティティ（SIP-URI）を取得してもよい。IP-SM-GW（着信側）は、4にて、SIP MESSAGEを介してSMをUE-Bに配信してもよい。

図2cは、一実施形態による、MSISDNを用いないショート・メッセージ着信手続を示すシグナリング図の例を示す。図2cの例に示されているように、1にてUE-Bは、IMS登録手続に従ってS-CSCFに登録する。2にて、UE-AからSMを受信した発信元IMSネットワークが、ショート・メッセージ（SMS-DELIVER）を着信側IMSネットワークに転送してもよく、ショート・メッセージは、UE-Bを担当するIP-SM-GWに到達する。続いて、3にて、ローカル・ポリシーがMSISDNなしのSMS動作を許可する場合、IP-SM-GWが、SMをUE-Bに配信することを試行してもよい。SMのUE-Bへの配信が成功した場合、4aおよび4bにて、配信成功レポート（success delivery report）が発信元IMSネットワークに送信されてもよい。5aにて、IP-SM-GWがSMの配信を試行したが、何らかのエラーに遭遇した場合（例えばUEのメモリが一杯である、UEが到達不可能であるなど）、5bにてIP-SM-GWが、MSISDNなしのSMS相関IDをHSSにリクエストしてもよい。この例では、HSSは、SMSC-Aアドレス、UE-AのSIP URI、およびUE-BのSIP URIを保存する。HSSはさらに、メッセージ・ウェイティング・フラグを、SMSC-Aアドレスでマークする。続いて5cにて、HSSは、MSISDNなしのSMS相関IDをIP-SM-GWに返し、5dにてIP-SM-GWは、これを発信元IMSネットワークに一時的失敗の通知情報とともに返す。6aにて、IP-SM-GWが、ローカル・ポリシーまたはその他の恒久的エラー（例えばプロトコル・エラー）が原因でMSISDNなしのSMS動作を拒否すれば、6bにてIP-SM-GWは、恒久的エラー通知情報を発信元IMSネットワークに返す。

図3は、別の実施形態による装置10を示す。実施形態によっては、装置10は、ゲートウェイ、サービス・センター、制御機能、サブスクリプション・サーバなどのネットワーク構成要素であってもよい。他の実施形態では、装置10は、ユーザ機器（UE）などのモバイル・デバイスであってもよい。なお、図3は、必ずしも装置10のすべてのコンポーネントを示すものではない。本発明の実施形態を理解するのに必要な当該コンポーネントのみが示されているが、当業者には当然のことながら、装置10は、示されていない追加のコンポーネントを備えてもよい。

装置10は、情報を処理して命令または動作を実行するプロセッサ22を備える。プロセッサ22は、任意のタイプの汎用または専用プロセッサとされてもよい。図3には単一のプロセッサ22が示されているが、他の実施形態に従って複数のプロセッサが利用されてもよい。実際、プロセッサ22は、例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（DSP：digital signal processor）、フィールド・プログラマブル・ゲート・アレイ（FPGA：field-programmable gate array）、特定用途向け集積回路（ASIC：application-specific integrated circuit）、およびマルチコア・プロセッサ・アーキテクチャに基づくプロセッサのうちの１つ以上を含んでもよい。

装置10は、プロセッサ22に結合され、情報と、プロセッサ22によって実行され得る命令とを保存する、メモリ14をさらに備える。メモリ14は、１つ以上のメモリであってもよく、ローカル・アプリケーション環境に適した任意のタイプのものであってもよく、さらに、半導体ベースのメモリ・デバイス、磁気メモリ・デバイスおよびシステム、光メモリ・デバイスおよびシステム、固定メモリ、ならびに取り外し可能メモリなど、任意の適切な揮発性または不揮発性データ・ストレージ技術を使用して実装され得る。例えば、メモリ14は、ランダム・アクセス・メモリ（RAM：random access memory）、読み取り専用メモリ（ROM：read only memory）、磁気もしくは光ディスクなどのスタティック・ストレージ、またはその他任意のタイプの非一時的な機械もしくはコンピュータ可読媒体の、任意の組み合わせから成ることができる。メモリ14に保存された命令は、プロセッサ22によって実行されると装置10が本願明細書に記載のタスクを実行することを可能にする、プログラム命令またはコンピュータ・プログラム・コードを含んでもよい。

装置10はさらに、装置10へ、および装置10から信号および/またはデータを送受信するために、１つ以上のアンテナ（図示せず）を備えてもよい。装置10は、アンテナ（単数または複数）による送信のために搬送波形へと情報を変調し、かつ、アンテナ（単数または複数）を介して受信された情報を装置10の他の構成要素によるさらなる処理のために復調する、送受信機28をさらに備えてもよい。他の実施形態では、送受信機28は、信号またはデータを直接送受信できてもよい。

プロセッサ22は、アンテナ利得/位相パラメータのプリコーディング、通信メッセージを構成する個々のビットのエンコードおよびデコード、情報のフォーマッティング、および通信リソースの管理に関係するプロセスを含む装置10の全体的な制御を含むがこれに限定はされない、装置10の動作に関連する機能を実行してもよい。

実施形態では、メモリ14は、プロセッサ22によって実行されると機能性を提供するソフトウェア・モジュールを保存する。モジュールは、装置10のオペレーティング・システム機能性を提供するオペレーティング・システム15を含んでもよい。メモリはさらに、装置10に追加の機能性を提供するために、アプリケーションまたはプログラムなどの１つ以上の機能モジュール18を保存してもよい。装置10のコンポーネントは、ハードウェアにおいて実装されても、またはハードウェアとソフトウェアとの任意の適切な組み合わせとして実装されてもよい。

一実施形態では、装置10は、上記で説明した図1に示したIP-SM-GW-Aであってもよい。この実施形態では、装置10は、メモリ14内に、SMSを送信するデバイスのSIP-URIおよびIMSIを保存するよう、メモリ14およびプロセッサ22によって制御されてもよい。その場合、装置10は、送信するデバイスから送受信機28を介してSMSを受信するよう、メモリ14およびプロセッサ22によって制御されてもよい。特定の実施形態によれば、SMSは、例えばMO-SMSまたはMT-SMSであってもよい。

実施形態では、MO-SMSのTP-DAフィールドには、ダミー値が入れられるなど、受信側UEがMSISDNを用いずにアドレス指定されることを示す値（単数または複数）が入れられ、R-URIにはPSIが設定され、「toヘッダ」には受信するデバイスのSIP URIが設定される。装置10は、受信するデバイスのSIP URIを「toヘッダ」から取得して、受信するデバイスのHSSに、受信するデバイスのIMSIおよびルーティング情報を問い合わせるよう、メモリ14およびプロセッサ22によってさらに制御されてもよい。続いて、装置10は、リクエストした受信デバイスのIMSIおよびルーティング情報を、送受信機28を介して受信するよう、メモリ14およびプロセッサ22によって制御されてもよい。装置10は、受信するデバイスにSMSを直接配信するか、または受信するデバイスにSMSCを介してSMSを配信するよう、メモリ14およびプロセッサ22によってさらに制御されてもよい。

別の実施形態では、装置10は、上記で説明した図1に示したUE-Aであってもよい。この実施形態では、装置10は、SMS（例えばMO-SMSまたはMT-SMS）を構築するよう、メモリ14およびプロセッサ22によって制御されてもよい。実施形態によっては、装置10は、SMSのTP-DAフィールドに、ダミー値など、受信側UEがMSISDNを用いずにアドレス指定されることを示す値（単数または複数）を入れ、R-URIにPSIを設定し、「toヘッダ」に受信するデバイスのSIP URIを設定するよう構成される。その結果、装置10は、送受信機28を介してSMSをゲートウェイに送信するよう、メモリ14およびプロセッサ22によって制御されてもよい。

別の実施形態では、装置10は、上記で説明した図1に示したIP-SM-GW-Bであってもよい。この実施形態では、装置10は、forwardshortMsgなどのメッセージをSMSCから受信するよう、メモリ14およびプロセッサ22によって制御されてもよい。実施形態によれば、メッセージは、SMSを送信するデバイスのSIP URIおよび/またはIMSIを含んでもよい。その結果、装置10は、SIPメッセージを宛先デバイスに配信するよう、メモリ14およびプロセッサ22によって制御されてもよい。実施形態によっては、SIPメッセージの配信は、宛先デバイスの登録中に保存されたSIP URI-IMSIバインディングを使用して実行されてもよい。しかしながら、上記で説明したように、IP-SM-GW-Bの機能性は、単一のIP-SM-GWにおいてIP-SM-GW-Aと組み合わされてもよい。

別の実施形態では、装置10は、上記で説明した図1に示したUE-Bであってもよい。この実施形態では、装置10は、送信するデバイスからMSISDNを用いずに送信されたSMSを含むSIPメッセージをゲートウェイから受信するよう、メモリ14およびプロセッサ22によって制御されてもよい。その場合、装置10は、SMSをデコードし、p-asserted-identityヘッダを使用して、送信するデバイスのアイデンティティを判断するよう、メモリ14およびプロセッサ22によって制御されてもよい。

図4は、一実施形態による方法のフローチャートを示す。実施形態によっては、図4の方法は、上記で説明した図1に示したIP-SM-GW-Aによって実行されてもよい。方法は、400にて、SMSを送信するデバイスのSIP-URIおよびIMSIを保存することを含む。方法は、410にて、送信するデバイスからSMS（例えばMO-SMSまたはMT-SMS）を受信することをさらに含んでもよい。実施形態によっては、MO-SMSのTP-DAフィールドには、ダミー値など、受信側UEがMSISDNを用いずにアドレス指定されることを示す値（単数または複数）が入れられ、R-URIにはPSIが設定され、「toヘッダ」には受信するデバイスのSIP URIが設定される。方法は、420にて、受信するデバイスのSIP URIを「toヘッダ」から取得すること、ならびに430にて、受信するデバイスのIMSIおよびルーティング情報を、受信するデバイスのHSSに問い合わせることを含んでもよい。方法は次に、440にて、リクエストした受信デバイスのIMSIおよびルーティング情報を受信することを含んでもよい。方法は、450にて、受信するデバイスにSMSを直接配信すること、または受信するデバイスにSMSCを介してSMSを配信することをさらに含んでもよい。

図5は、一実施形態による方法のフローチャートを示す。実施形態によっては、図5の方法は、図1で示したUE-Aによって実行されてもよい。一実施形態によれば、方法は、500にて、SMS（例えばMO-SMSまたはMT-SMS）を構築することを含む。この構築は、SMSのTP-DAフィールドに、ダミー値など、受信側UEがMSISDNを用いずにアドレス指定されることを示す値（単数または複数）を入れること、R-URIにPSIを設定すること、および「toヘッダ」に受信するデバイスのSIP URIを設定することを含んでもよい。方法は、510にて、SMSをゲートウェイに送信することをさらに含んでもよい。

図6は、一実施形態による方法のフローチャートを示す。実施形態によっては、方法は、上記で説明した図1に示したIP-SM-GW-Bによって実行されてもよい。一実施形態によれば、方法は、600にて、forwardshortMsgなどのメッセージをSMSCから受信することを含んでもよい。実施形態によっては、メッセージは、SMSを送信するデバイスのSIP URIおよび/またはIMSIを含んでもよい。方法は次に、610にて、SIPメッセージを宛先デバイスに配信することを含んでもよい。実施形態によっては、SIPメッセージの配信は、宛先デバイスの登録中に保存されたSIP URI-IMSIバインディングを使用して実行されてもよい。

図7は、一実施形態による方法のフローチャートを示す。実施形態によっては、方法は、上記で説明した図1に示したUE-Bによって実行されてもよい。方法は、700にて、送信するデバイスからMSISDNを用いずに送信されたSMSを含むSIPメッセージを、ゲートウェイから受信することを含んでもよい。方法は次に、710にて、SMSをデコードし、p-asserted-identityヘッダを使用して、送信するデバイスのアイデンティティを判断することを含んでもよい。

一部の実施形態では、本願明細書に記載された方法のいずれかの機能性は、メモリまたはその他コンピュータ可読もしくは有形の媒体に保存されてプロセッサにより実行される、ソフトウェアおよび/またはコンピュータ・プログラム・コードによって実装されてもよい。他の実施形態では、機能性は、例えば特定用途向け集積回路（ASIC）、プログラマブル・ゲート・アレイ（PGA：programmable gate array）、フィールド・プログラマブル・ゲート・アレイ（FPGA）、またはハードウェアとソフトウェアとの任意の他の組み合わせを利用して、ハードウェアによって実行されてもよい。

本発明の実施形態は、IP-SM-GWからSMSCに対してUE-AのIMSIまたはSIP URI（または両方）を含めるために、MAPプロトコルに影響を与えるかもしれない。しかしながら、これにより、SMSペイロードおよびSMSプロトコル（例えば、RP/TPフィールド、TS23.040）をもとのままとすることができる。さらに、SMS配信のために本発明の実施形態が強いる追加は、MAPが不可能である場合、Diameterにより実現可能である。

本発明の記載された機能、利点、および特徴は、１つ以上の実施形態において任意の適切な形で組み合わされ得る。当業者には当然のことながら、本発明は、特定の実施形態の特定の特徴または利点のうちの１つ以上を伴わずに実施されてもよい。他の場合には、本発明のすべての実施形態には存在しないかもしれない追加の特徴および利点が、特定の実施形態において認識されるかもしれない。

当業者であれば当然のことであるが、上記で説明した本発明は、他の順序のステップを用いて、さらに/または開示されているものとは異なる構成のハードウェア構成要素を用いて実施されてもよい。したがって、本発明は、これらの好適な実施形態に基づいて記載されたが、当業者であれば当然のことながら、本発明の意図および範囲内にとどまりつつ、特定の変更、変形、および代わりの構造が明らかとなり得る。

Claims (20)

1. ショート・メッセージ・サービス・メッセージを送信する送信側デバイスのセッション開始プロトコル統一リソース識別子および/または国際モバイル・サブスクライバ・アイデンティティを、ゲートウェイによって保存することと；
   前記送信側デバイスから前記ショート・メッセージ・サービス・メッセージを受信することと；
   前記ショート・メッセージ・サービス・メッセージの受信側である受信側デバイスのセッション開始プロトコル統一リソース識別子を取得すること、ただし、前記受信側デバイスの前記セッション開始プロトコル統一リソース識別子は、前記ショート・メッセージ・サービス・メッセージの「toヘッダ」から取得される、前記取得することと；
   前記受信側デバイスのホーム・サブスクリプション・サーバに、前記受信側デバイスの国際モバイル・サブスクライバ・アイデンティティおよびルーティング情報を問い合わせることと；
   前記受信側デバイスに、前記ショート・メッセージ・サービス・メッセージを、前記国際モバイル・サブスクライバ・アイデンティティおよび前記ルーティング情報を使用して配信することと；
   を含む方法であって、前記送信側デバイスまたは前記受信側デバイスのうちの少なくとも１つは、移動局国際サブスクライバ・ディレクトリ番号を有せず、前記受信側デバイスが前記移動局国際サブスクライバ・ディレクトリ番号を用いずにアドレス指定されることを示すよう設定された値が、前記ショート・メッセージ・サービス・メッセージの転送プロトコル宛先アドレス・フィールドに入れられ、リクエスト統一リソース識別子に、パブリック・サービス・アイデンティティが設定され、前記ショート・メッセージ・サービス・メッセージの前記「toヘッダ」に、前記受信側デバイスの前記セッション開始プロトコル統一リソース識別子が設定される、方法。
2. 前記配信することは、前記受信側デバイスに前記ショート・メッセージ・サービス・メッセージを直接配信すること、または前記受信側デバイスに前記ショート・メッセージ・サービス・メッセージを、ショート・メッセージ・サービス・センターを介して配信することを含む、請求項１に記載の方法。
3. 前記ショート・メッセージ・サービス・メッセージは、モバイル発信ショート・メッセージ・サービス（MO-SMS）またはモバイル着信ショート・メッセージ・サービス（MT-SMS）を含む、請求項１または２に記載の方法。
4. 前記方法は、前記ショート・メッセージ・サービス・センターからメッセージを受信することをさらに含み、前記メッセージは、前記送信側デバイスのセッション開始プロトコル統一リソース識別子および/または国際モバイル・サブスクライバ・アイデンティティを含む、請求項２に記載の方法。
5. 前記方法は、前記受信側デバイスにセッション開始プロトコル・メッセージを配信することをさらに含み、前記セッション開始プロトコル・メッセージの前記配信は、前記受信側デバイスの登録中に保存された、セッション開始プロトコル統一リソース識別子と国際モバイル・サブスクライバ・アイデンティティとのバインディングを使用して実行される、請求項１〜４のいずれかに記載の方法。
6. 少なくとも１つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも１つのメモリとを有する装置であって、前記コンピュータ・プログラム・コードは、前記少なくとも１つのプロセッサに実行されることにより、前記装置に少なくとも、
   ショート・メッセージ・サービス・メッセージを送信する送信側デバイスのセッション開始プロトコル統一リソース識別子および/または国際モバイル・サブスクライバ・アイデンティティを保存することと；
   前記送信側デバイスから前記ショート・メッセージ・サービス・メッセージを受信することと；
   前記ショート・メッセージ・サービス・メッセージの受信側である受信側デバイスのセッション開始プロトコル統一リソース識別子を取得すること、ただし、前記受信側デバイスの前記セッション開始プロトコル統一リソース識別子は、前記ショート・メッセージ・サービス・メッセージの「toヘッダ」から取得される、前記取得することと；
   前記受信側デバイスのホーム・サブスクリプション・サーバに、前記受信側デバイスの国際モバイル・サブスクライバ・アイデンティティおよびルーティング情報を問い合わせることと；
   前記受信側デバイスに、前記ショート・メッセージ・サービス・メッセージを、前記国際モバイル・サブスクライバ・アイデンティティおよび前記ルーティング情報を使用して配信することと
   を行わせるよう構成され、前記送信側デバイスまたは前記受信側デバイスのうちの少なくとも１つは、移動局国際サブスクライバ・ディレクトリ番号を有せず、前記受信側デバイスが前記移動局国際サブスクライバ・ディレクトリ番号を用いずにアドレス指定されることを示すよう設定された値が、前記ショート・メッセージ・サービス・メッセージの転送プロトコル宛先アドレス・フィールドに入れられ、リクエスト統一リソース識別子に、パブリック・サービス・アイデンティティが設定され、前記ショート・メッセージ・サービス・メッセージの前記「toヘッダ」に、前記受信側デバイスの前記セッション開始プロトコル統一リソース識別子が設定される、装置。
7. 前記コンピュータ・プログラム・コードは、前記少なくとも１つのプロセッサに実行させることにより、前記装置に、前記受信側デバイスに前記ショート・メッセージ・サービス・メッセージを直接配信すること、または前記受信側デバイスに前記ショート・メッセージ・サービス・メッセージを、ショート・メッセージ・サービス・センターを介して配信することを行わせるようさらに構成される、請求項６に記載の装置。
8. 前記ショート・メッセージ・サービス・メッセージは、モバイル発信ショート・メッセージ・サービス（MO-SMS）またはモバイル着信ショート・メッセージ・サービス（MT-SMS）を含む、請求項６または７に記載の装置。
9. 前記コンピュータ・プログラム・コードは、前記少なくとも１つのプロセッサに実行されることにより、前記装置に、前記ショート・メッセージ・サービス・センターからメッセージを受信させるようさらに構成され、前記メッセージは、前記送信側デバイスのセッション開始プロトコル統一リソース識別子および/または国際モバイル・サブスクライバ・アイデンティティを含む、請求項７に記載の装置。
10. 前記コンピュータ・プログラム・コードは、前記少なくとも１つのプロセッサに実行されることにより、前記装置に、前記受信側デバイスにセッション開始プロトコル・メッセージを配信させるようさらに構成され、前記セッション開始プロトコル・メッセージの前記配信は、前記受信側デバイスの登録中に保存された、セッション開始プロトコル統一リソース識別子と国際モバイル・サブスクライバ・アイデンティティとのバインディングを使用して実行される、請求項６〜９のいずれかに記載の装置。
11. 前記装置は、インターネット・プロトコル・ショート・メッセージ・ゲートウェイを含む、請求項６〜１０のいずれかに記載の装置。
12. ユーザ機器によってショート・メッセージ・サービス・メッセージを構築することと；
    前記ショート・メッセージ・サービス・メッセージを送信することと；
    を含む方法であって、ここで、前記構築することは、
    前記ショート・メッセージ・サービス・メッセージの受信側である受信側デバイスが移動局国際サブスクライバ・ディレクトリ番号を用いずにアドレス指定されることを示すよう設定された値を、前記ショート・メッセージ・サービス・メッセージの転送プロトコル宛先アドレス・フィールドに入れること；
    リクエスト統一リソース識別子に、パブリック・サービス・アイデンティティを設定すること；
    前記ショート・メッセージ・サービス・メッセージの「toヘッダ」に、前記受信側デバイスのセッション開始プロトコル統一リソース識別子を設定すること；
    を含む、方法。
13. 前記ユーザ機器は、移動局国際サブスクライバ・ディレクトリ番号を有しない、請求項１２に記載の方法。
14. 前記ショート・メッセージ・サービス・メッセージは、モバイル発信ショート・メッセージ・サービス（MO-SMS）またはモバイル着信ショート・メッセージ・サービス（MT-SMS）を含む、請求項１２または１３に記載の方法。
15. 前記ゲートウェイは、インターネット・プロトコル・ショート・メッセージ・ゲートウェイを含む、請求項１〜５のいずれかに記載の方法。
16. 少なくとも１つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも１つのメモリとを有する装置であって、前記コンピュータ・プログラム・コードは、前記少なくとも１つのプロセッサに実行されることにより、前記装置に少なくとも、
    ショート・メッセージ・サービス・メッセージを構築することと；
    前記ショート・メッセージ・サービス・メッセージを送信することと
    を行わせるよう構成され、ここで、前記構築することは、
    前記ショート・メッセージ・サービス・メッセージの受信側である受信側デバイスが移動局国際サブスクライバ・ディレクトリ番号を用いずにアドレス指定されることを示すよう設定された値を、前記ショート・メッセージ・サービス・メッセージの転送プロトコル宛先アドレス・フィールドに入れること；
    リクエスト統一リソース識別子に、パブリック・サービス・アイデンティティを設定すること；
    前記ショート・メッセージ・サービス・メッセージの「toヘッダ」に、前記受信側デバイスのセッション開始プロトコル統一リソース識別子を設定すること；
    を含む、装置。
17. 前記装置は、ユーザ機器を含み、前記ユーザ機器は、移動局国際サブスクライバ・ディレクトリ番号を有しない、請求項１６に記載の装置。
18. 前記ショート・メッセージ・サービス・メッセージは、モバイル発信ショート・メッセージ・サービス（MO-SMS）またはモバイル着信ショート・メッセージ・サービス（MT-SMS）を含む、請求項１６または１７に記載の装置。
    
    
19. コンピュータ可読媒体上に具現化されたコンピュータ・プログラムであって、前記コンピュータ・プログラムは、プロセスを実行するようにプロセッサを制御するよう構成され、前記プロセスは、
    ショート・メッセージ・サービス・メッセージを送信する送信側デバイスのセッション開始プロトコル統一リソース識別子および/または国際モバイル・サブスクライバ・アイデンティティを保存することと；
    前記送信側デバイスから前記ショート・メッセージ・サービス・メッセージを受信することと；
    前記ショート・メッセージ・サービス・メッセージの受信側である受信側デバイスのセッション開始プロトコル統一リソース識別子を取得すること、ただし、前記受信側デバイスの前記セッション開始プロトコル統一リソース識別子は、前記ショート・メッセージ・サービス・メッセージの「toヘッダ」から取得される、前記取得することと；
    前記受信側デバイスのホーム・サブスクリプション・サーバに、前記受信側デバイスの国際モバイル・サブスクライバ・アイデンティティおよびルーティング情報を問い合わせることと；
    前記受信側デバイスに、前記ショート・メッセージ・サービス・メッセージを、前記国際モバイル・サブスクライバ・アイデンティティおよび前記ルーティング情報を使用して配信することと；
    を含み、前記送信側デバイスまたは前記受信側デバイスのうちの少なくとも１つは、移動局国際サブスクライバ・ディレクトリ番号を有せず、前記受信側デバイスが前記移動局国際サブスクライバ・ディレクトリ番号を用いずにアドレス指定されることを示すよう設定された値が、前記ショート・メッセージ・サービス・メッセージの転送プロトコル宛先アドレス・フィールドに入れられ、リクエスト統一リソース識別子に、パブリック・サービス・アイデンティティが設定され、前記ショート・メッセージ・サービス・メッセージの前記「toヘッダ」に、前記受信側デバイスの前記セッション開始プロトコル統一リソース識別子が設定される、コンピュータ・プログラム。
20. コンピュータ可読媒体上に具現化されたコンピュータ・プログラムであって、前記コンピュータ・プログラムは、プロセスを実行するようにプロセッサを制御するよう構成され、前記プロセスは、
    ショート・メッセージ・サービス・メッセージを構築することと；
    前記ショート・メッセージ・サービス・メッセージをゲートウェイに送信することと
    を含み、ここで前記構築することは、
    前記ショート・メッセージ・サービス・メッセージの受信側である受信側デバイスが移動局国際サブスクライバ・ディレクトリ番号を用いずにアドレス指定されることを示すよう設定された値を、前記ショート・メッセージ・サービス・メッセージの転送プロトコル宛先アドレス・フィールドに入れること；
    リクエスト統一リソース識別子に、パブリック・サービス・アイデンティティを設定すること、および前記ショート・メッセージ・サービス・メッセージの「toヘッダ」に、前記受信側デバイスのセッション開始プロトコル統一リソース識別子を設定すること；
    を含む、コンピュータ・プログラム。

Images