JP2012517720A

JP2012517720A - 同じパブリックユーザｉｄを共有するいくつかのユーザ機器を区別する方法および装置

Info

Publication number: JP2012517720A
Application number: JP2011548517A
Authority: JP
Inventors: ワン，ジー; ジヤン，チンボー
Original assignee: アルカテル−ルーセント
Priority date: 2009-02-11
Filing date: 2009-12-23
Publication date: 2012-08-02
Anticipated expiration: 2029-12-23
Also published as: EP2398193A1; KR101602521B1; KR20110113630A; US20110289223A1; WO2010091588A1; CN101800945A; US8966091B2; EP2398193A4; JP5718827B2

Abstract

本発明では、ＩＭＳネットワーク内で同じパブリックユーザＩＤを共有するいくつかのユーザ機器を区別するための方法および装置が提供される。発呼者ネットワーク内で共有のパブリックユーザＩＤを使用する発呼側ユーザ機器が、被呼者ネットワーク内の特定の被呼側ユーザ機器とのセッション接続の確立を要求する場合、発呼側Ｓ−ＣＳＣＦは、被呼側ユーザ機器がセッション要求メッセージ内の拡張ＩＤ、および発呼側ユーザ機器によって使用された共有のパブリックユーザＩＤに従って誰が実際の発呼側ユーザ機器であるか知ることができるように、発呼側ユーザ機器に対応する取得された拡張ＩＤを発呼側ユーザ機器からのセッション要求メッセージ内に追加し、拡張ＩＤが追加されたセッション要求メッセージを被呼者ネットワーク内の被呼側ユーザ機器に送信する。したがって、セッションの終了後、被呼側ユーザ機器は、拡張ＩＤおよび発呼側ユーザ機器の使用された共有のパブリックユーザＩＤに従って、発呼側ユーザ機器とのセッション接続を再確立することができる。

Description

本発明は、ＩＭＳネットワークに関し、詳細には、ＩＭＳネットワーク内の発呼側サービス呼セッション制御機能（発呼側Ｓ−ＣＳＣＦ）および被呼側サービス呼セッション制御機能（被呼側Ｓ−ＣＳＣＦ）に関する。

ＩＰマルチメディアサブシステム（ＩＭＳ：ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ）は、ＩＰマルチメディアサービスをサポートできる、第３世代パートナーシッププロジェクト（３ＧＰＰ：３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）によって提案されたサブシステムである。ＩＭＳの顕著な特徴は、セッション開始プロトコル（ＳＩＰ：ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）が採用されており、その通信がアクセスモードと全く関係がなく、複数のメディアサービスが提供されてよく、制御機能とベアリング機能、呼とセッション、アプリケーションとサービス、サービスとネットワークの間に階層型の設計があり、また移動網とインターネットサービスの間の融合があるということである。ＩＭＳは、通信網の融合進展の傾向に沿うものである。

ＩＭＳＲ６では、１つのパブリックユーザＩＤ（ＰＵＩＤ：ｐｕｂｌｉｃｕｓｅｒｉｄｅｎｔｉｔｙ）を複数のユーザ機器（ＵＥ：ｕｓｅｒｅｑｕｉｐｍｅｎｔ）が共有することを可能にするために共有のパブリックユーザ識別情報が導入され、複数のＵＥによって共有されるＰＵＩＤは、共有のＰＵＩＤと呼ばれる。共有のＰＵＩＤを使用することは、共同作業モード、たとえばサービスホットライン、緊急通報１１０番などにかなり有益である。一方、それは、同じユーザのそれぞれ異なるＵＥ、たとえば自宅の固定電話、会社の固定電話および携帯電話などの間でも共有されてよい。

しかし、共有のＰＵＩＤを使用することは、共有のＰＵＩＤが複数ユーザによって使用されているので、共有のＰＵＩＤを有する発呼者によって呼が開始される場合、どのＵＥが実際の発呼者であるか被呼者が知り得ないといういくつかの問題をも引き起こす。たとえば、ユーザＡが、何らかの問題のために採用された共有のＰＵＩＤを有するユーザＢから呼を受信したというシナリオについて考慮されたい。呼が終了された後、ユーザＡは、呼がどのＵＥから行われているか分からないので、より詳細に話し合うためにユーザＢにコールバックすることができない。

さらに、複数のＵＥがＰＵＩＤを共有するという場合では、複数のＵＥは、互いに直接通信することができない。

連絡先アドレスは、ＰＵＩＤを共有する複数のＵＥを識別するために使用され得るが、ＵＥに恒久的には結び付けられておらず、次の登録で変更されることがある。

従来技術では、上記問題に対処するために、ＳＩＰグローバルルーティング可能ユーザエージェントＵＲＩの機構が提案されているが、依然としてＧＲＵＵに不利な以下の点がある。

ＧＲＵＵは、ＵＥとの組合せであるので、ユーザではなくＵＥに結合され、したがって、ユーザが別のＵＥに登録するために切り換わると、他のユーザは、彼が以前に保存したＧＲＵＵから彼を見つけることができない。

さらに、ＧＲＵＵの使用は、ＵＥがどの程度ＳＩＰをサポートするかに依存する。ＩＭＳネットワークでは、それらのレガシーＵＥによってＳＩＰがサポートされていないので、ＧＲＵＵ機構は使用され得ない。

従来技術の上記の欠点に対処するために、ＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別する方法および装置、およびそれに対応して、ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する方法および装置が提供される。

本発明の第１の態様によれば、ＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別する方法が提供される。この方法は：ａ．セッションの確立を要求するためのセッション要求メッセージを発呼側ＵＥから受信するステップと、ｃ．前記複数の発呼側ＵＥを区別するために使用される、前記発呼側ＵＥに対応する拡張識別情報を前記セッション要求メッセージ内に追加するステップと、ｄ．前記ステップｃによって更新されたセッション要求メッセージを被呼側ＵＥに送信するステップとを含む。

好ましくは、ステップａの後、かつステップｃの前に、上記方法はさらに：ｂ１．前記セッション要求メッセージから前記発呼側ＵＥのＰＵＩＤを抽出するステップと、ｂ２．前記ＰＵＩＤが共有のＰＵＩＤかどうか判断するステップとを含み、前記ステップｃがさらに：前記ＰＵＩＤが共有のＰＵＩＤである場合は、前記発呼側ＵＥに対応する前記拡張識別情報を前記セッション要求メッセージ内に追加するステップを含む。

好ましくは、ステップｂ２の後、かつステップｃの前に、上記方法はさらに：前記発呼側ＵＥの前記拡張識別情報機能が使用可能となるかどうか判断するステップを含み、前記ステップｃがさらに：前記拡張識別情報機能が使用可能となる場合は、前記発呼側ＵＥに対応する前記拡張識別情報を前記セッション要求メッセージ内に追加するステップを含む。

本発明の第２の態様によれば、ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する方法が提供される。この方法は：ｉ．セッションの確立を要求するためのセッション要求メッセージを前記発呼側ＵＥから受信するステップと、ｉｉ．前記セッション要求メッセージに従って、前記被呼側ＵＥが共有のＰＵＩＤを使用するかどうか判断するステップと、ｉｉｉ．前記被呼側ＵＥが共有のＰＵＩＤを使用する場合は、前記セッション要求メッセージが、前記複数の被呼側ＵＥを区別するために使用される前記被呼側ＵＥに対応する拡張識別情報を含むかどうか判断するステップと、ｉｖ．前記セッション要求メッセージが前記拡張識別情報を含む場合は、前記拡張識別情報および前記被呼側ＵＥの共有のＰＵＩＤに従って前記被呼側ＵＥに前記セッション要求メッセージを送信するステップとを含む。

好ましくは、ステップｉｉｉの後、上記方法はさらに：ｖ．前記セッション要求メッセージが前記拡張識別情報を含まない場合は、前記被呼側ＵＥに対応する拡張識別情報が備わっているかどうか前記発呼側ＵＥに問い合わせるために使用される問合せメッセージを前記発呼側ＵＥに送信するステップと、ｖｉ．前記発呼側ＵＥによって提供された前記被呼側ＵＥに対応する前記拡張識別情報、および前記被呼側ＵＥの前記共有のＰＵＩＤに従って、前記被呼側ＵＥに前記セッション要求メッセージを送信するステップとを含む。

好ましくは、ステップｉｉｉの後、かつステップｉｖの前に、上記方法はさらに：前記セッション要求メッセージが前記拡張識別情報を含む場合は、前記被呼側ＵＥの拡張識別情報機能が使用可能となるかどうか判断するステップを含み、前記ステップｉｖがさらに：前記拡張識別情報機能が使用可能となる場合は、前記拡張識別情報および前記被呼側ＵＥの前記共有のＰＵＩＤに従って前記被呼側ＵＥに前記セッション要求メッセージを送信するステップを含む。

本発明の第３の態様によれば、ＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別するための第１の制御装置が提供される。第１の制御装置は：セッションの確立を要求するためのセッション要求メッセージを発呼側ＵＥから受信する第１の受信手段と、前記複数の発呼側ＵＥを区別するために使用される、前記発呼側ＵＥに対応する拡張識別情報を前記セッション要求メッセージ内に追加する追加手段と、前記追加手段によって更新されたセッション要求メッセージを被呼側ＵＥに送信する第１の送信手段とを備える。

好ましくは、第１の制御装置はさらに：前記セッション要求メッセージから前記発呼側ＵＥのＰＵＩＤを抽出する第１の抽出手段と、前記ＰＵＩＤが共有のＰＵＩＤかどうか判断する第１の判断手段とを備え、前記追加手段がさらに、前記ＰＵＩＤが共有のＰＵＩＤである場合は、前記発呼側ＵＥに対応する前記拡張識別情報を前記セッション要求メッセージ内に追加するために使用される。

好ましくは、第１の制御装置はさらに：前記発呼側ＵＥの前記拡張識別情報機能が使用可能となるかどうか判断する第２の判断手段を備え、前記追加手段がさらに、前記拡張識別情報機能が使用可能となる場合は、前記発呼側ＵＥに対応する前記拡張識別情報を前記セッション要求メッセージ内に追加するために使用される。

本発明の第４の態様によれば、ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する第２の制御装置が提供される。第２の制御装置は：セッションの確立を要求するためのセッション要求メッセージを前記発呼側ＵＥから受信する第２の受信手段と、前記セッション要求メッセージに従って、前記被呼側ＵＥが共有のＰＵＩＤを使用するかどうか判断するための第３の判断手段と、前記被呼側ＵＥが共有のＰＵＩＤを使用する場合は、前記セッション要求メッセージが、前記複数の被呼側ＵＥを区別するために使用される前記被呼側ＵＥに対応する拡張識別情報を含むかどうか判断する第４の判断手段と、前記セッション要求メッセージが前記拡張識別情報を含む場合は、前記拡張識別情報および前記被呼側ＵＥの共有のＰＵＩＤに従って前記被呼側ＵＥに前記セッション要求メッセージを送信する第２の送信手段とを備える。

好ましくは、第２の制御装置はさらに：前記セッション要求メッセージが前記拡張識別情報を含まない場合は、前記被呼側ＵＥに対応する拡張識別情報が備わっているかどうか前記発呼側ＵＥに問い合わせるために使用される問合せメッセージを前記発呼側ＵＥに送信する第３の送信手段と、前記発呼側ＵＥによって提供された前記被呼側ＵＥに対応する前記拡張識別情報、および前記被呼側ＵＥの前記共有のＰＵＩＤに従って、前記被呼側ＵＥに前記セッション要求メッセージを送信する第４の送信手段とを備える。

好ましくは、第２の制御装置はさらに：前記セッション要求メッセージが前記拡張識別情報を含む場合は、前記被呼側ＵＥの拡張識別情報機能が使用可能となるかどうか判断する第５の判断手段を備え、前記第２の送信手段がさらに、前記拡張識別情報機能が使用可能となる場合は、前記拡張識別情報および前記被呼側ＵＥの前記共有のＰＵＩＤに従って前記被呼側ＵＥに前記セッション要求メッセージを送信するために使用される。

本発明の方法および装置によって、ＩＭＳネットワーク内でＰＵＩＤを共有する複数の発呼側ＵＥが区別され得る。具体的には、発呼側ネットワーク内で共有ＰＵＩＤを使用する発呼側ＵＥが、被呼側ネットワーク内の特定の被呼側ＵＥとのセッション確立を要求する場合、発呼者ネットワークの発呼側Ｓ−ＣＳＣＦは、セッション要求メッセージ内の拡張識別情報、および発呼側ＵＥによって使用された共有のＰＵＩＤに従って被呼側ＵＥが発呼側ＵＥを識別できるように、発呼側ＵＥから受信されたセッション要求メッセージ内に発呼側ＵＥに対応する拡張識別情報を追加し、拡張識別情報が追加されたセッション要求メッセージを被呼者ネットワーク内の被呼側ＵＥに送信する。したがって、このセッションの完了後、被呼側ＵＥは、発呼側ＵＥの拡張識別情報、および発呼側ＵＥで使用された共有のＰＵＩＤに従って、発呼側ＵＥとのセッションを再確立してよい。

複数のＵＥが１つのＰＵＩＤを共有する場合でも、それらは、セッション要求メッセージ内に拡張識別情報を追加することによって、ＵＥ間でセッションを直接確立することもできる。

本発明の特徴、態様および利点は、添付の図面を用いて非限定的な実施形態についての下記の説明を読むことによってより明らかになろう。

本発明の一実施形態による、ＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別する方法のフローチャートである。本発明の一実施形態による、ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する方法のフローチャートである。本発明の一実施形態による、ＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別する第１の制御装置の機能ブロック図である。本発明の一実施形態による、ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する第２の制御装置の機能ブロック図である。

図では、同じまたは類似の参照符号は、同じまたは類似の装置（モジュール）または方法ステップを指す。

添付の図を参照して、本発明の詳細な説明を行う。

本発明の解決策を実施するために、まずサービスプロバイダまたは事業者は、パブリック識別クラスに、任意のデータ型のアドレスであってよい拡張識別情報（拡張ＩＤ）の新しい属性を定義する。好ましくは、拡張識別情報は、少なくとも１つの非負整数を含み、たとえば拡張識別情報は、０から９のいずれか１つまたは複数の数で構成される。それは、同じＰＵＩＤを共有する複数のＵＥの各ＵＥに対応する拡張識別情報が一意である限り許容可能であってよい。

ＵＥは、ＩＭＳネットワークにアクセスする前に、登録許可を要求するためにＳ−ＣＳＣＦに登録要求メッセージを送信する必要がある。Ｓ−ＣＳＣＦが登録要求メッセージを受信した後、登録要求メッセージ内のＵＥに対応するプライベートユーザＩＤに従って、ホーム加入者サーバ（ＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）のセキュリティデータ許可センタ（ＡｕＣ：ａｕｔｈｏｒｉｚａｔｉｏｎｃｅｎｔｅｒ）によってＵＥに対する許可が行われる。一方、Ｓ−ＣＳＣＦは、ＨＳＳからＵＥのユーザプロファイルをダウンロードし、ユーザプロファイルを用いてＳ−ＣＳＣＦは、ＵＥに対応する拡張識別情報を取得することができる。

ＵＥがＩＭＳネットワークにアクセスする前の登録許可手順は従来技術で使用されており、単純にするために本明細書では冗長な説明は行われないことに留意されたい。

登録許可手順において、ＵＥの共有のＰＵＩＤと拡張識別情報の両方がＩＰアドレスに結び付けられる。後のセッション手順では、共有のＰＵＩＤおよび拡張識別情報に送信されたセッション要求メッセージはすべて、ＩＰアドレスが対応しているＵＥに転送される。同じＰＵＩＤを共有する複数のＵＥに対応する拡張識別情報がそれぞれ異なるので、同じＰＵＩＤを共有する複数のＵＥについて、共有のＰＵＩＤと拡張識別情報は共に、複数のＵＥのうちの１つを一意に識別することができ、それによって、同じＰＵＩＤを共有する複数のＵＥを区別する目的が達成される。

図１を参照して、本発明の解決策について詳細に説明される。

図１は、本発明の一実施形態によるＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別する方法のフローチャートを示している。

図１のＩＭＳネットワークでは、単純にするために、発呼者ネットワーク内のＵＥ、Ｓ−ＣＳＣＦ、Ｐ−ＣＳＣＦおよびのＩ−ＣＳＣＦはそれぞれ、発呼側ＵＥ、発呼側Ｓ−ＣＳＣＦ、発呼側Ｐ−ＣＳＣＦおよび発呼側Ｉ−ＣＳＣＦと呼ばれ、被呼者ネットワーク内のＵＥは、被呼側ＵＥと呼ばれる。

第１に、ステップＳ１１で、発呼側Ｓ−ＣＳＣＦが、セッションの確立を要求するためのセッション要求メッセージ（ＩＮＶＩＴＥ）を発呼側ＵＥから受信する。

具体的には、セッションの確立を要求するために発呼側ＵＥから発呼側Ｓ−ＣＳＣＦによって受信されるセッション要求メッセージは、発呼側Ｐ−ＣＳＣＦおよび発呼側Ｉ−ＣＳＣＦのルーティングによって発呼側Ｓ−ＣＳＣＦに転送される。

ただし、セッション要求メッセージは、発呼側ＵＥのＰＵＩＤと、発呼側ＵＥがこれからセッションを確立しようとしている被呼側ＵＥのＰＵＩＤとを含む。確かに、セッション要求メッセージは、従来技術に属する他の情報をさらに含んでもよく、単純にするために本明細書では冗長な説明は行われない。

第２に、ステップＳ１２で、発呼側Ｓ−ＣＳＣＦが、発呼側ＵＥに対応する取得された拡張識別情報をセッション要求メッセージ内に追加する。

ただし、拡張識別情報は、共有のＰＵＩＤを使用する複数の発呼側ＵＥを区別するために使用される。

さらに、発呼側Ｓ−ＣＳＣＦによってセッション要求メッセージ内に追加された、ＵＥに対応する拡張識別情報は、ＵＥがそれへの登録を適用するときに発呼側Ｓ−ＣＳＣＦがＨＳＳからユーザプロファイルをダウンロードした後、ＵＥに対応するユーザプロファイルから取得される。

好ましくは、発呼側Ｓ−ＣＳＣＦは、発呼側ＵＥからセッション要求メッセージを受信した後、まずセッション要求メッセージに従って、発呼側ＵＥが共有のＰＵＩＤを使用するかどうか判断する。

具体的には、発呼側第１のＳ−ＣＳＣＦはまず、受信されたセッション要求メッセージから発呼側ＵＥのＰＵＩＤを抽出し、次いで、ＰＵＩＤが共有のＰＵＩＤかどうか判断する。すべての共有のＰＵＩＤがＩＭＳネットワーク内に登録されているので、発呼側Ｓ−ＣＳＣＦは、セッション要求メッセージ内の発呼側ＵＥに対応するＰＵＩＤに従って、ＰＵＩＤが共有のＰＵＩＤかどうかに関する判断を得ることができる。

発呼側ＵＥのＰＵＩＤが共有のＰＵＩＤである場合は、発呼側Ｓ−ＣＳＣＦは、発呼側ＵＥに対応する取得された拡張識別情報をセッション要求メッセージ内に追加する。

より好ましくは、発呼側Ｓ−ＣＳＣＦは、発呼側ＵＥが共有のＰＵＩＤを使用するという判断を得るとき、発呼側ＵＥの拡張識別情報機能が使用可能となるどうかさらに判断する。

発呼側ＵＥの拡張識別情報機能が使用可能となる場合は、発呼側Ｓ−ＣＳＣＦは、発呼側ＵＥに対応する取得された拡張識別情報をセッション要求メッセージ内に追加する。

確かに、発呼側ＵＥの拡張識別情報機能が使用可能とならない場合は、発呼側ＵＥが共有のＰＵＩＤを使用する場合でも、発呼側Ｓ−ＣＳＣＦは、発呼側ＵＥに対応する拡張識別情報をセッション要求メッセージ内に追加しない。

好ましくは、発呼側ＵＥに対応する拡張識別情報は、セッション要求メッセージ内の共有のＰＵＩＤ内に追加されるべき発呼側ＵＥの共有のＰＵＩＤの一部として供給されてよい。したがって、被呼側ＵＥは、修正の必要なしに、拡張識別情報が含まれた発呼側ＵＥに対応する共有のＰＵＩＤを受信することができ、したがって、被呼側ＵＥは、発呼側ＵＥへのセッション要求を開始する必要があるとき、拡張識別情報を含む共有のＰＵＩＤによって発呼側ＵＥとのセッションを確立することができる。

確かに、発呼側ＵＥに対応する拡張識別情報は、共有のＰＵＩＤに関係なく独立したパラメータとしてセッション要求メッセージ内に追加されてよい。したがって、被呼側ＵＥは、拡張識別情報を受信できるように修正されるべきである。

その後、ステップＳ１３で、発呼側Ｓ−ＣＳＣＦは、拡張識別情報が追加されたセッション要求メッセージを被呼側ＵＥに送信する。

次いで、被呼側ＵＥは、２００ＯＫによってセッション要求に応答する。発呼側ＵＥは、被呼側ＵＥから２００ＯＫの応答を受信した後、発呼側ＵＥがこのセッション要求メッセージへの最後の応答を受信したことを被呼側ＵＥに通知するために被呼側ＵＥにＡＣＫを送信するが、当業者にはそれが、従来技術に属するものであり、冗長な説明を必要としないことが理解されよう。

したがって、セッションは、発呼側ＵＥと被呼側ＥＵの間で確立されている。

発呼側Ｓ−ＣＳＣＦが、発呼側ＵＥに対応する拡張識別情報を発呼側ＵＥから受信されたセッション要求メッセージ内に追加するので、被呼側ＵＥは、セッション要求メッセージを受信するとき、セッション要求メッセージ内の拡張識別情報によって、発呼側ＵＥが、同じＰＵＩＤを共有する複数のＵＥのうちのどのＵＥであるか識別できることに留意されたい。したがって、こうしたセッションの完了後、被呼側ＵＥは、最後の呼を開始する発呼側ＥＵとのセッション接続を進んで再確立する場合、発呼側ＵＥの拡張識別情報、および発呼側ＵＥで使用された共有のＰＵＩＤの拡張識別情報に従って発呼側ＵＥとのセッションを確立してよい。

図１は、発呼側ＵＥが共有のＰＵＩＤを使用するという態様から本発明の一実施形態を示しており、図２を参照して、被呼側ＵＥが共有のＰＵＩＤを使用するという態様から、本発明の別の実施形態について説明される。

図２は、本発明の一実施形態による、ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する方法のフローチャートを示している。

図２のＩＭＳネットワークでは、単純にするために、発呼者ネットワーク内のＵＥ、Ｓ−ＣＳＣＦ、Ｐ−ＣＳＣＦおよびのＩ−ＣＳＣＦはそれぞれ、発呼側ＵＥ、発呼側Ｓ−ＣＳＣＦ、発呼側Ｐ−ＣＳＣＦおよび発呼側Ｉ−ＣＳＣＦと呼ばれ、被呼者ネットワーク内のＵＥおよびＳ−ＣＳＣＦは、被呼側ＵＥおよび被呼側Ｓ−ＣＳＣＦと呼ばれる。

発呼側ＵＥは、まず、被呼側ＵＥとのセッションの確立を要求するためのセッション要求メッセージを送信する。

ただし、セッション要求メッセージは、発呼者ネットワーク内の発呼側Ｐ−ＣＳＣＦ、発呼側Ｉ−ＣＳＣＦおよび発呼側Ｓ−ＣＳＣＦのルーティングにより、被呼者ネットワーク内の被呼側Ｓ−ＣＳＣＦに転送される。

ステップＳ２１で、被呼側Ｓ−ＣＳＣＦは、発呼側ＵＥから、セッション確立を要求するためのセッション要求メッセージを受信し、セッション要求メッセージは、発呼側Ｐ−ＣＳＣＦ、発呼側Ｉ−ＣＳＣＦおよび発呼側Ｓ−ＣＳＣＦのルーティングにより転送される。

ただし、セッション要求メッセージは、発呼側ＵＥのＰＵＩＤと被呼側ＵＥのＰＵＩＤとを含む。確かに、セッション要求メッセージはさらに、他の情報を含むことができ、この他の情報は従来技術に属するものであり、したがって単純にするために、本明細書では冗長な説明を行う必要はない。

次いで、ステップＳ２２で、被呼側Ｓ−ＣＳＣＦは、受信されたセッション要求メッセージに従って、被呼側ＵＥが共有のＰＵＩＤを使用するかどうか判断する。

具体的には、被呼側Ｓ−ＣＳＣＦは、受信されたセッション要求メッセージから被呼側ＵＥのＰＵＩＤを抽出し、次いで、ＰＵＩＤが共有のＰＵＩＤかどうか判断する。すべての共有ＰＵＩＤがＩＭＳネットワーク内に登録されているので、被呼側Ｓ−ＣＳＣＦは、セッション要求メッセージ内の被呼側ＵＥに対応するＰＵＩＤに従って、それが共有のＰＵＩＤかどうかについて判断に達することができる。

ＰＵＩＤが共有のＰＵＩＤである場合、ステップＳ２３で、被呼側Ｓ−ＣＳＣＦは、セッション要求メッセージが被呼側ＵＥに対応する拡張識別情報を含むかどうか判断する。ただし、拡張識別情報は、同じ共有のＰＵＩＤを使用する複数の被呼側ＵＥを区別するために使用される。

セッション要求メッセージが、被呼側ＵＥに対応する拡張識別情報を含む場合、ステップＳ２４で、被呼側Ｓ−ＣＳＣＦは、拡張識別情報および被呼側ＵＥの共有のＰＵＩＤに従って被呼側ＵＥにセッション要求メッセージを送信する。

さらに、被呼側ＵＥが被呼側Ｓ−ＣＳＣＦへの登録を適用するためにＩＭＳネットワークにアクセスしようとする場合、被呼側Ｓ−ＣＳＣＦは、被呼側ＵＥに対応するユーザプロファイルをＨＳＳからダウンロードし、ＵＥに対応する拡張識別情報をユーザプロファイルから取得する。その後、拡張識別情報と被呼側ＵＥの共有のＰＵＩＤの両方が、ＩＰアドレスに結び付けられる。したがって、ステップＳ２４で、被呼側Ｓ−ＣＳＣＦは、拡張識別情報および被呼側ＵＥの共有のＰＵＩＤに従って、結び付けられたＩＰアドレスに対応する被呼側ＵＥにセッション要求メッセージを送信する。

セッション要求メッセージが、被呼側ＵＥに対応する拡張識別情報を含まない場合は、被呼側Ｓ−ＣＳＣＦはさらに、従来技術に既にある送信機構に従ってセッション要求メッセージを転送することができる。

好ましくは、セッション要求メッセージが、被呼側ＵＥに対応する拡張識別情報を含まない場合は、被呼側Ｓ−ＣＳＣＦは、被呼側ＵＥに対応する拡張識別情報が備わっているかどうかに関して発呼側ＵＥに問い合わせるために使用される問合せメッセージを発呼側ＵＥに送信してよい。

発呼側ＵＥが、被呼側ＵＥに対応する拡張識別情報を有しており、被呼側Ｓ−ＣＳＣＦに拡張識別情報を提供する場合は、被呼側Ｓ−ＣＳＣＦは、拡張識別情報および被呼側ＵＥの共有のＰＵＩＤに従って被呼側ＵＥにセッション要求メッセージを送信してよい。

好ましくは、セッション要求メッセージが、被呼側ＵＥに対応する拡張識別情報を含む場合は、被呼側Ｓ−ＣＳＣＦはさらに、被呼側ＵＥの拡張識別情報機能が使用可能となるかどうか判断してよい。

被呼側ＵＥの拡張識別情報機能が使用可能となる場合は、被呼側Ｓ−ＣＳＣＦは、拡張識別情報および被呼側ＵＥの共有のＰＵＩＤに従って被呼側ＵＥにセッション要求メッセージを送信する。

確かに、被呼側ＵＥの拡張識別情報機能が使用可能とならない場合は、セッション要求メッセージが被呼側ＵＥに対応する拡張識別情報を含む場合でも、被呼側Ｓ−ＣＳＣＦは、対応する措置を講じず、しかし、従来技術に既にある送信機構に従ってセッション要求メッセージをさらに転送する。

対応する被呼側ＵＥは、発呼側ＵＥからセッション要求メッセージを受信した後、セッション要求への応答として２００ＯＫメッセージを送信してよい。発呼側ＵＥは、２００ＯＫ応答を受信した後、発呼側ＵＥがこのセッション要求メッセージへの最後の応答メッセージを受信したことを被呼側ＵＥに通知するために被呼側ＵＥにＡＣＫを送信するが、当業者にはそれが、従来技術に属するものであり、本明細書では冗長な説明は必要ないことが理解されよう。

それに基づいて、発呼側ＵＥは、被呼側ＵＥとのセッション接続を確立する。

上記に本発明の解決策についての説明が方法の観点から説明されており、下記では、図３および図４と組み合わせて装置の観点から、本発明の解決策について説明される。

図３は、本発明の一実施形態による、ＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別する第１の制御装置の機能ブロック図を示している。

図３に関わるＩＭＳネットワークでは、単純にするために、発呼者ネットワーク内のＵＥ、Ｓ−ＣＳＣＦ、Ｐ−ＣＳＣＦおよびのＩ−ＣＳＣＦはそれぞれ、発呼側ＵＥ、発呼側Ｓ−ＣＳＣＦ、発呼側Ｐ−ＣＳＣＦおよび発呼側Ｉ−ＣＳＣＦと呼ばれ、被呼者ネットワーク内のＵＥは、被呼側ＵＥと呼ばれる。

第１に、発呼側Ｓ−ＣＳＣＦの第１の制御装置１０内の第１の受信手段１０１が、セッションの確立を要求するためのセッション要求メッセージ（ＩＮＶＩＴＥ）を発呼側ＵＥから受信する。

具体的には、第１の受信手段１０１によって発呼側ＵＥから受信される、セッションの確立を要求するためのセッション要求メッセージは、発呼側Ｐ−ＣＳＣＦおよび発呼側Ｉ−ＣＳＣＦのルーティングによって発呼側Ｓ−ＣＳＣＦに転送される。

ただし、セッション要求メッセージは、発呼側ＵＥのＰＵＩＤと、発呼側ＵＥがセッションを確立しようとしている被呼側ＵＥのＰＵＩＤとを含む。確かに、セッション要求メッセージはさらに、従来技術に属する他の情報を含んでもよく、単純にするために本明細書では冗長な説明は行われない。

第２に、発呼側Ｓ−ＣＳＣＦの第１の制御装置１０内の第１の追加手段１０２が、発呼側ＵＥに対応する取得された拡張識別情報をセッション要求メッセージ内に追加する。

さらに、追加手段１０２によってセッション要求メッセージ内に追加されたＵＥに対応する拡張識別情報は、ＵＥがそれへの登録を適用するときに発呼側Ｓ−ＣＳＣＦがＨＳＳからユーザプロファイルをダウンロードした後、ＵＥに対応するユーザプロファイルから取得される。

好ましくは、第１の受信手段１０１が発呼側ＵＥからセッション要求メッセージを受信した後、まず、発呼側Ｓ−ＣＳＣＦの第１の制御装置１０内の第１の抽出手段（単純にするために図示せず）は、受信されたセッション要求メッセージから発呼側のＵＥのＰＵＩＤを抽出し、次いで、第１の制御装置１０内の第１の判断手段（単純にするために図示せず）は、ＰＵＩＤが共有のＰＵＩＤかどうか判断する。すべての共有のＰＵＩＤがＩＭＳネットワーク内に登録されているので、発呼側Ｓ−ＣＳＣＦは、セッション要求メッセージ内の発呼側ＵＥに対応するＰＵＩＤに従って、ＰＵＩＤが共有のＰＵＩＤかどうかに関する判断を得ることができる。

発呼側ＵＥのＰＵＩＤが共有のＰＵＩＤである場合は、追加手段１０２は、発呼側ＵＥに対応する取得された拡張識別情報をセッション要求メッセージ内に追加する。

より好ましくは、第１の判断手段１０２が、発呼側ＵＥが共有のＰＵＩＤを使用するという判断を得るとき、第１の制御装置１０内の第２の判断手段（単純にするために図３に図示せず）はさらに、発呼側ＵＥの拡張識別情報機能が使用可能となるどうか判断する。

発呼側ＵＥの拡張識別情報機能が使用可能となる場合、追加手段１０２は、発呼側ＵＥに対応する取得された拡張識別情報をセッション要求メッセージ内に追加する。

確かに、発呼側ＵＥの拡張識別情報機能が使用可能とならない場合は、発呼側ＵＥが共有のＰＵＩＤを使用する場合でも、追加手段１０２は、発呼側ＵＥに対応する拡張識別情報をセッション要求メッセージ内に追加しない。

確かに、発呼側ＵＥに対応する拡張識別情報は、共有のＰＵＩＤに関係なく独立したパラメータとしてセッション要求メッセージ内に追加されてよい。したがって、被呼側ＵＥは、拡張識別情報の受信を使用可能とするように修正されるべきである。

その後、発呼側Ｓ−ＣＳＣＦの第１の制御装置１０内の第１の送信手段１０３は、拡張識別情報が追加されたセッション要求メッセージを被呼側ＵＥに送信する。

発呼側Ｓ−ＣＳＣＦが、発呼側ＵＥに対応する拡張識別情報を発呼側ＵＥから受信されたセッション要求メッセージ内に追加するので、被呼側ＵＥは、セッション要求メッセージを受信するとき、セッション要求メッセージ内の拡張識別情報によって、発呼側ＵＥが、同じＰＵＩＤを共有する複数のＵＥのうちのどのＵＥであるか識別できることに留意されたい。したがって、こうしたセッションの完了後、被呼側ＵＥは、最後の呼を開始する発呼側ＥＵとのセッション接続を進んで再確立する場合、発呼側ＵＥの拡張識別情報、および発呼側ＵＥで使用された共有のＰＵＩＤに従って発呼側ＵＥとのセッションを確立してよい。

図３は、発呼側ＵＥが共有のＰＵＩＤを使用するという態様から本発明の一実施形態を示しており、図４を参照して、被呼側ＵＥが共有のＰＵＩＤを使用するという態様から、本発明の別の実施形態について説明される。

図４は、本発明の一実施形態による、ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する第２の制御装置の機能ブロック図を示している。

図４のＩＭＳネットワークでは、単純にするために、発呼者ネットワーク内のＵＥ、Ｓ−ＣＳＣＦ、Ｐ−ＣＳＣＦおよびのＩ−ＣＳＣＦはそれぞれ、発呼側ＵＥ、発呼側Ｓ−ＣＳＣＦ、発呼側Ｐ−ＣＳＣＦおよび発呼側Ｉ−ＣＳＣＦと呼ばれ、被呼者ネットワーク内のＵＥおよびＳ−ＣＳＣＦは、被呼側ＵＥおよび被呼側Ｓ−ＣＳＣＦと呼ばれる。

被呼側Ｓ−ＣＳＣＦ内の第２の制御装置２０内の第２の受信手段２０１は、発呼側ＵＥから、セッション確立を要求するためのセッション要求メッセージを受信し、セッション要求メッセージは、発呼側Ｐ−ＣＳＣＦ、発呼側Ｉ−ＣＳＣＦおよび発呼側Ｓ−ＣＳＣＦのルーティングにより転送される。

ただし、セッション要求メッセージは、発呼側ＵＥのＰＵＩＤと被呼側ＵＥのＰＵＩＤとを含む。確かに、セッション要求メッセージはさらに、他の情報を含むことができ、それは従来技術に属するものであり、したがって、単純にするために本明細書では冗長な説明は必要ない。

次いで、被呼側Ｓ−ＣＳＣＦの第２の制御装置２０内の第３の判断手段２０２は、受信されたセッション要求メッセージに従って、被呼側ＵＥが共有のＰＵＩＤを使用するかどうか判断する。

具体的には、第３の判断手段２０２内の第２の抽出手段（単純にするために図４に図示せず）は、受信されたセッション要求メッセージから被呼側ＵＥのＰＵＩＤを抽出し、次いで、第３の判断手段２０２内の第６の判断手段（単純にするために図４に図示せず）は、ＰＵＩＤが共有のＰＵＩＤかどうか判断する。すべての共有ＰＵＩＤがＩＭＳネットワーク内に登録されているので、被呼側Ｓ−ＣＳＣＦは、セッション要求メッセージ内の被呼側ＵＥに対応するＰＵＩＤに従って、それが共有のＰＵＩＤかどうかについて判断に達することができる。

ＰＵＩＤが共有のＰＵＩＤである場合は、被呼側Ｓ−ＣＳＣＦの第２の制御装置２０内の第４の判断手段２０３は、セッション要求メッセージが被呼側ＵＥに対応する拡張識別情報を含むかどうか判断する。ただし、拡張識別情報は、同じ共有のＰＵＩＤを使用する複数の被呼側ＵＥを区別するために使用される。

セッション要求メッセージが、被呼側ＵＥに対応する拡張識別情報を含む場合は、被呼側Ｓ−ＣＳＣＦの第２の制御装置２０内の第２の送信手段２０４は、拡張識別情報および被呼側ＵＥの共有のＰＵＩＤに従って被呼側ＵＥにセッション要求メッセージを送信する。

さらに、被呼側ＵＥが被呼側Ｓ−ＣＳＣＦへの登録を適用するためにＩＭＳネットワークにアクセスしようとする場合、被呼側Ｓ−ＣＳＣＦは、被呼側ＵＥに対応するユーザプロファイルをＨＳＳからダウンロードし、ＵＥに対応する拡張識別情報をユーザプロファイルから取得する。その後、拡張識別情報と被呼側ＵＥの共有のＰＵＩＤの両方が、ＩＰアドレスに結び付けられる。したがって、第２の送信手段２０４は、拡張識別情報および被呼側ＵＥの共有のＰＵＩＤに従って、結び付けられたＩＰアドレスに対応する被呼側ＵＥにセッション要求メッセージを送信する。

セッション要求メッセージが、被呼側ＵＥに対応する拡張識別情報を含まない場合は、第２の送信手段２０４はさらに、従来技術に既にある送信機構に従ってセッション要求メッセージを転送することができる。

好ましくは、セッション要求メッセージが、被呼側ＵＥに対応する拡張識別情報を含まない場合は、被呼側Ｓ−ＣＳＣＦの第２の制御装置２０内の第３の送信手段（単純にするために図４に図示せず）は、被呼側ＵＥに対応する拡張識別情報が備わっているかどうかに関して発呼側ＵＥに問い合わせるために使用される問合せメッセージを発呼側ＵＥに送信してよい。

発呼側ＵＥが、被呼側ＵＥに対応する拡張識別情報を有しており、被呼側Ｓ−ＣＳＣＦに拡張識別情報を提供する場合、被呼側Ｓ−ＣＳＣＦの第２の制御装置２０内の第４の送信手段（単純にするために図４に図示せず）は、拡張識別情報および被呼側ＵＥの共有のＰＵＩＤに従って被呼側ＵＥにセッション要求メッセージを送信してよい。

好ましくは、セッション要求メッセージが、被呼側ＵＥに対応する拡張識別情報を含む場合は、被呼側Ｓ−ＣＳＣＦの第２の制御装置２０内の第５の判断手段（単純にするために図４に図示せず）はさらに、被呼側ＵＥの拡張識別情報機能が使用可能となるかどうか判断してよい。

被呼側ＵＥの拡張識別情報機能が使用可能となる場合は、第２の送信手段２０４は、拡張識別情報および被呼側ＵＥの共有のＰＵＩＤに従って被呼側ＵＥにセッション要求メッセージを送信する。

本発明の一部の実施形態への説明が行われている。本発明は、上記の特定の実施形態に限定されず、当業者は、添付の特許請求の範囲内の様々な変更または修正を行ってよいことを理解されたい。

Claims

ＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別する方法であって、
ａ．セッションの確立を要求するためのセッション要求メッセージを発呼側ＵＥから受信するステップと、
ｃ．前記複数の発呼側ＵＥを区別するために使用される、前記発呼側ＵＥに対応する拡張識別情報を前記セッション要求メッセージ内に追加するステップと、
ｄ．前記ステップｃによって更新されたセッション要求メッセージを被呼側ＵＥに送信するステップとを含む、方法。
前記ステップａの後、かつ前記ステップｃの前に、
ｂ１．前記セッション要求メッセージから前記発呼側ＵＥのＰＵＩＤを抽出するステップと、
ｂ２．前記ＰＵＩＤが共有のＰＵＩＤかどうか判断するステップとをさらに含み、
前記ステップｃがさらに、前記ＰＵＩＤが共有のＰＵＩＤである場合、前記発呼側ＵＥに対応する前記拡張識別情報を前記セッション要求メッセージ内に追加するステップを含む、請求項１に記載の方法。
前記ステップｂ２の後、かつ前記ステップｃの前に、
− 前記発呼側ＵＥの前記拡張識別情報機能が使用可能となるかどうか判断するステップをさらに含み、
前記ステップｃがさらに、
前記拡張識別情報機能が使用可能となる場合、前記発呼側ＵＥに対応する前記拡張識別情報を前記セッション要求メッセージ内に追加するステップを含む、請求項２に記載の方法。
前記拡張識別情報が任意のデータ型のアドレスである、請求項１から３のいずれかに記載の方法。
前記拡張識別情報が少なくとも１つの非負整数を含む、請求項４に記載の方法。
ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する方法であって、
ｉ．セッションの確立を要求するためのセッション要求メッセージを前記発呼側ＵＥから受信するステップと、
ｉｉ．前記セッション要求メッセージに従って、前記被呼側ＵＥが共有のＰＵＩＤを使用するかどうか判断するステップと、
ｉｉｉ．前記被呼側ＵＥが共有のＰＵＩＤを使用する場合は、前記セッション要求メッセージが、前記複数の被呼側ＵＥを区別するために使用される、前記被呼側ＵＥに対応する拡張識別情報を含むかどうか判断するステップと、
ｉｖ．前記セッション要求メッセージが前記拡張識別情報を含む場合は、前記拡張識別情報および前記被呼側ＵＥの共有のＰＵＩＤに従って前記被呼側ＵＥに前記セッション要求メッセージを送信するステップとを含む、方法。
前記ステップｉｉｉの後、
ｖ．前記セッション要求メッセージが前記拡張識別情報を含まない場合は、前記被呼側ＵＥに対応する拡張識別情報が備わっているかどうか前記発呼側ＵＥに問い合わせるために使用される問合せメッセージを前記発呼側ＵＥに送信するステップと、
ｖｉ．前記発呼側ＵＥによって提供された前記被呼側ＵＥに対応する前記拡張識別情報、および前記被呼側ＵＥの前記共有のＰＵＩＤに従って、前記被呼側ＵＥに前記セッション要求メッセージを送信するステップとをさらに含む、請求項６に記載の方法。
前記ステップｉｉｉの後、かつステップｉｖの前に、
− 前記セッション要求メッセージが前記拡張識別情報を含む場合は、前記被呼側ＵＥの拡張識別情報機能が使用可能となるかどうか判断するステップをさらに含み、
前記ステップｉｖがさらに、前記拡張識別情報機能が使用可能となる場合は、前記拡張識別情報および前記被呼側ＵＥの前記共有のＰＵＩＤに従って前記被呼側ＵＥに前記セッション要求メッセージを送信するステップを含む、請求項６に記載の方法。
前記ステップｉｉがさらに、
ｉｉ１．前記セッション要求メッセージから前記被呼側ＵＥのＰＵＩＤを抽出するステップと、
ｉｉ２．前記ＰＵＩＤが共有のＰＵＩＤかどうか判断するステップとを含み、
前記ステップｉｉｉがさらに、前記ＰＵＩＤが共有のＰＵＩＤである場合は、前記セッション要求メッセージが、前記被呼側ＵＥに対応する拡張識別情報を含むかどうか判断するステップを含む、請求項６から８のいずれかに記載の方法。
前記拡張識別情報が任意のデータ型のアドレスである、請求項６から９のいずれかに記載の方法。
前記拡張識別情報が少なくとも１つの非負整数を含む、請求項１０に記載の方法。
ＩＭＳネットワークの発呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の発呼側ＵＥを区別するための第１の制御装置であって、第１の制御装置が、
セッションの確立を要求するためのセッション要求メッセージを発呼側ＵＥから受信する第１の受信手段と、
前記複数の発呼側ＵＥを区別するために使用される、前記発呼側ＵＥに対応する拡張識別情報を前記セッション要求メッセージ内に追加する追加手段と、
前記追加手段によって更新されたセッション要求メッセージを被呼側ＵＥに送信する第１の送信手段とを備える、第１の制御装置。
前記セッション要求メッセージから前記発呼側ＵＥのＰＵＩＤを抽出する第１の抽出手段と、
前記ＰＵＩＤが共有のＰＵＩＤかどうか判断する第１の判断手段とをさらに備え、
前記追加手段がさらに、前記ＰＵＩＤが共有のＰＵＩＤである場合は、前記発呼側ＵＥに対応する前記拡張識別情報を前記セッション要求メッセージ内に追加するために使用される、請求項１２に記載の第１の制御装置。
前記発呼側ＵＥの前記拡張識別情報機能が使用可能となるかどうか判断する第２の判断手段をさらに備え、
前記追加手段がさらに、前記拡張識別情報機能が使用可能となる場合は、前記発呼側ＵＥに対応する前記拡張識別情報を前記セッション要求メッセージ内に追加するために使用される、請求項１３に記載の第１の制御装置。
前記拡張識別情報が任意のデータ型のアドレスである、請求項１２から１４のいずれかに記載の第１の制御装置。
前記拡張識別情報が少なくとも１つの非負整数を含む、請求項１５に記載の第１の制御装置。
ＩＭＳネットワークの被呼側Ｓ−ＣＳＣＦ内でＰＵＩＤを共有する複数の被呼側ＵＥのうちの１つの被呼側ＵＥに、発呼側ＵＥからセッション要求メッセージを転送する第２の制御装置であって、
セッションの確立を要求するためのセッション要求メッセージを前記発呼側ＵＥから受信する第２の受信手段と、
前記セッション要求メッセージに従って、前記被呼側ＵＥが共有のＰＵＩＤを使用するかどうか判断する第３の判断手段と、
前記被呼側ＵＥが共有のＰＵＩＤを使用する場合は、前記セッション要求メッセージが、前記複数の被呼側ＵＥを区別するために使用される前記被呼側ＵＥに対応する拡張識別情報を含むかどうか判断する第４の判断手段と、
前記セッション要求メッセージが前記拡張識別情報を含む場合は、前記拡張識別情報および前記被呼側ＵＥの共有のＰＵＩＤに従って前記被呼側ＵＥに前記セッション要求メッセージを送信する第２の送信手段とを備える、第２の制御装置。
前記セッション要求メッセージが前記拡張識別情報を含まない場合は、前記被呼側ＵＥに対応する拡張識別情報が備わっているかどうか前記発呼側ＵＥに問い合わせるために使用される問合せメッセージを前記発呼側ＵＥに送信する第３の送信手段と、
前記発呼側ＵＥによって提供された前記被呼側ＵＥに対応する前記拡張識別情報、および前記被呼側ＵＥの前記共有のＰＵＩＤに従って、前記被呼側ＵＥに前記セッション要求メッセージを送信する第４の送信手段とをさらに備える、請求項１７に記載の第２の制御装置。
前記セッション要求メッセージが前記拡張識別情報を含む場合は、前記被呼側ＵＥの拡張識別情報機能が使用可能となるかどうか判断する第５の判断手段を備え、
前記第２の送信手段がさらに、前記拡張識別情報機能が使用可能となる場合は、前記拡張識別情報および前記被呼側ＵＥの前記共有のＰＵＩＤに従って前記被呼側ＵＥに前記セッション要求メッセージを送信するために使用される、請求項１７に記載の第２の制御装置。
前記第３の判断手段がさらに、
前記セッション要求メッセージから前記被呼側ＵＥのＰＵＩＤを抽出する第２の抽出手段と、
前記ＰＵＩＤが共有のＰＵＩＤかどうか判断する第６の判断手段とを備え、
前記第４の判断手段がさらに、前記ＰＵＩＤが共有のＰＵＩＤである場合は、前記セッション要求メッセージが、前記被呼側ＵＥに対応する拡張識別情報を含むかどうか判断するために使用される、請求項１７から１９のいずれかに記載の第２の制御装置。
前記拡張識別情報が任意のデータ型のアドレスである、請求項１７から２０のいずれかに記載の第２の制御装置。
前記拡張識別情報が少なくとも１つの非負整数を含む、請求項２１に記載の第２の制御装置。