(57)【特許請求の範囲】
【請求項１】
携帯電話ネットワークに同一のＩＰ(Internet Protocol)ネットワークを介して収容さ
れる複数の携帯電話用無線基地局と、
前記ＩＰネットワークに設けられる呼制御装置とを含み、
前記呼制御装置は、
携帯電話端末の識別情報と、この携帯電話端末が利用可能な前記ＩＰネットワークを介して前記携帯電話ネットワークに収容された携帯電話用無線基地局のＩＰアドレスとを含む相手先情報を記憶する記憶部と、
発信側無線基地局としての前記複数の携帯電話用無線基地局の一つから、発信端末としての携帯電話端末からの携帯電話用プロトコルに基づく発信要求を受信する受信部と、
前記発信要求に含まれる着信先端末としての携帯電話端末の識別情報を取得し、取得された識別情報に対応する携帯電話用無線基地局のＩＰアドレスを前記記憶部から読み出す検索部と、
前記検索部によって携帯電話用無線基地局のＩＰアドレスが読み出された場合に、このＩＰアドレスを持つ携帯電話用無線基地局を着信側無線基地局として、このＩＰアドレス宛に前記発信要求を送信する送信部とを含み、
前記発信側無線基地局及び前記着信側無線基地局の夫々は、携帯電話端末との間で使用される携帯電話用プロトコルと、前記呼制御装置との間で使用されるＩＰ電話用プロトコルとの間での変換処理を行うプロトコル変換部を備え、
前記発信側無線基地局は、前記発信側無線基地局自身のプロトコル変換部で、前記発信端末から受信される前記携帯電話用プロトコルに基づく発信要求及び前記呼制御装置へ送信すべきメッセージを前記ＩＰ電話用プロトコルに基づく形式に変換した後に、前記呼制御装置に送信し、
前記着信側無線基地局は、前記着信側無線基地局自身の配下に前記着信先端末が存在する場合に、前記着信側無線基地局自身のプロトコル変換部で前記呼制御装置から受信される前記ＩＰ電話用プロトコルに基づく発信要求及び前記着信先端末へ送信すべきメッセージを前記携帯電話用プロトコルに基づく形式に変換した後に、前記着信先端末へ送信し、
前記着信側無線基地局自身の配下に前記着信先端末が存在する場合に、前記発信側無線基地局と前記着信側無線基地局とが、前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を、前記発信端末と前記着信先端末との
間で通信されるデータを伝送するために、前記発信側無線基地局と前記着信側無線基地局との間で前記呼制御装置を介して確立する
携帯電話端末間のデータ伝送路確立システム。
【請求項２】
前記着信側無線基地局は、前記着信先端末に送信した前記発信要求に対する応答を受け取ることができない場合に、前記着信側無線基地局の配下に前記着信先端末が存在しないことを示すメッセージを前記呼制御装置を介して前記発信側無線基地局に通知し、
前記発信側無線基地局は、前記発信側無線基地局と前記発信端末との間に第１のデータ伝送路を確立し、前記呼制御装置から前記メッセージを受け取った場合に、前記発信側無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１に記載の携帯電話端末間のデータ伝送路確立システム。
【請求項３】
前記呼制御装置は、前記発信要求に対応する相手先情報が前記記憶部に登録されていない場合に、接続すべき前記着信側無線基地局が存在しないことを示すメッセージを前記発信側無線基地局に通知し、前記発信側無線基地局は、前記発信側無線基地局と前記発信端末との間に第１のデータ伝送路を確立し、前記発信側無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１又は２に記載の携帯電話端末間のデータ伝送路確立システム。
【請求項４】
前記発信側無線基地局は、前記発信側無線基地局と前記発信端末との間で決定された第１の暗号で制御信号及びユーザデータを暗号化／復号化する第１暗号処理部と、前記発信側無線基地局と前記携帯電話ネットワークとの間で決定された第２の暗号で制御信号及びユーザデータを暗号化／復号化する第２暗号処理部とを有し、
前記発信側無線基地局は、前記第１の暗号で暗号化された制御信号及びユーザデータを前記発信端末から受信した場合には、前記制御信号及びユーザデータを前記第１暗号処理部で復号化し且つ復号化された制御信号及びユーザデータを前記第２暗号処理部で暗号化した後に、前記携帯電話ネットワークへ送信し、
前記発信側無線基地局は、前記第２の暗号で暗号化された制御信号及びユーザデータを前記携帯電話ネットワークから受信した場合には、前記制御信号及びユーザデータを前記第２暗号処理部で復号化し且つ復号化された制御信号及びユーザデータを前記第１暗号処理部で暗号化した後に、前記発信端末へ送信する
請求項２又は３に記載の携帯電話端末間のデータ伝送路確立システム。
【請求項５】
前記検索部によって、前記着信先端末の識別情報に対応する複数の無線基地局のＩＰアドレスが検索される場合には、前記送信部は、検索された各ＩＰアドレス宛に前記発信要求を送信し、
前記着信先端末を配下に持つ前記複数のＩＰアドレスを夫々有する無線基地局の一つが、前記着信側無線基地局として、前記発信側無線基地局との間で、前記発信側無線基地局と前記着信側無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を確立する
請求項１〜４のいずれか一項に記載の携帯電話端末間のデータ伝送路確立システム。
【請求項６】
携帯電話ネットワークに同一のＩＰ(Internet Protocol)ネットワークを介して収容さ
れる複数の携帯電話用無線基地局を備え、
発信側無線基地局としての前記複数の携帯電話用無線基地局の少なくとも１つは、
携帯電話端末の識別情報と、この携帯電話端末が利用可能な前記ＩＰネットワークを介して前記携帯電話ネットワークに収容された携帯電話用無線基地局のＩＰアドレスとを含む相手先情報を記憶する記憶部と、
携帯電話端末との間で使用される携帯電話用プロトコルとＩＰ電話用プロトコルとの間での変換処理を行うプロトコル変換部と、
発信端末としての携帯電話端末からの携帯電話用プロトコルに基づく発信要求を受信する受信部と、
前記携帯電話用プロトコルに基づく発信要求に含まれる着信先端末としての携帯電話端末の識別情報を取得し、取得された識別情報に対応する携帯電話用無線基地局のＩＰアドレスを前記記憶部から検索する検索部と、
前記対応する携帯電話用無線基地局のＩＰアドレスが検索された場合に、この検索されたＩＰアドレスを持つ携帯電話用無線基地局を着信側無線基地局として、この検索されたＩＰアドレス宛に、前記プロトコル変換部によって前記携帯電話用プロトコルに基づく形式がＩＰ電話用プロトコルに基づく形式に変換された発信要求を送信する送信部と、
前記着信側無線基地局自身の配下に前記着信先端末が存在する場合に前記着信側無線基地局から受信される、前記ＩＰ電話用プロトコルに基づく前記発信端末へ送信すべきメッセージを前記プロトコル変換部で前記携帯電話用プロトコルに基づく形式に変換して前記発信端末に送信し、前記発信側無線基地局と前記着信側無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を、前記発信端末と前記着信先端末との間で通信されるデータを伝送するために、前記発信側無線基地局と前記着信側無線基地局との間で確立する制御を行う制御手段とを含む
携帯電話端末間のデータ伝送路確立システム。
【請求項７】
前記着信側無線基地局は、前記着信先端末に送信した前記発信要求に対する応答を受け取ることができない場合に、前記着信側無線基地局の配下に前記着信先端末が存在しないことを示すメッセージを前記発信側無線基地局に通知し、
前記発信側無線基地局は、
前記発信側無線基地局と前記発信端末との間に第１のデータ伝送路を確立し、
前記着信側無線基地局から前記メッセージを受け取った場合に、前記発信側無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、
前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項６に記載の携帯電話端末間のデータ伝送路確立システム。
【請求項８】
前記発信側無線基地局は、
前記発信要求に対応する相手先情報が前記記憶部に登録されていない場合に、前記発信側無線基地局と前記発信端末との間に第１のデータ伝送路を確立し、
さらに、前記発信側無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、
前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項６又は７に記載の携帯電話端末間のデータ伝送路確立システム。
【請求項９】
前記発信側無線基地局は、
前記発信側無線基地局と前記発信端末との間で決定された第１の暗号化方式で制御信号及びユーザデータを暗号化／復号化する第１暗号処理部と、
前記発信側無線基地局と前記携帯電話ネットワークとの間で決定された第２の暗号化方式で制御信号及びユーザデータを暗号化／復号化する第２暗号処理部とを有し、
前記発信側無線基地局は、前記第１の暗号化方式で暗号化された制御信号及びユーザデ
ータを前記発信端末から受信した場合には、前記制御信号及びユーザデータを前記第１暗号処理部で復号化し且つ復号化された制御信号及びユーザデータを前記第２暗号処理部で暗号化した後に、前記携帯電話ネットワークへ送信し、
前記発信側無線基地局は、前記第２の暗号化方式で暗号化された制御信号及びユーザデータを前記携帯電話ネットワークから受信した場合には、前記制御信号及びユーザデータを前記第２暗号処理部で復号化し且つ復号化された制御信号及びユーザデータを前記第１暗号処理部で暗号化した後に、前記発信端末へ送信する
請求項７又は８に記載の携帯電話端末間のデータ伝送路確立システム。
【請求項１０】
前記検索部によって、前記着信先端末の識別情報に対応する複数の携帯電話用無線基地局のＩＰアドレスが検索される場合には、前記送信部は、検索された各ＩＰアドレス宛に前記発信要求を送信し、
前記着信先端末を配下に持つ前記複数のＩＰアドレスを夫々有する携帯電話用無線基地局の一つが、前記着信側無線基地局として、前記発信側無線基地局との間で、前記発信側無線基地局と前記着信側無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を確立する
請求項６〜９のいずれか一項に記載の携帯電話端末間のデータ伝送路確立システム。
【請求項１１】
携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して収容される携
帯電話端末の携帯電話用無線基地局であって、
発信端末としての携帯電話端末からの携帯電話用プロトコルに基づく発信要求を受信する受信部と、
前記携帯電話用プロトコルに基づく発信要求をＩＰ電話用プロトコルに基づく形式に変換するプロトコル変換部と、
前記ＩＰ電話用プロトコルに基づく形式に変換された発信要求を前記ＩＰネットワーク内の呼制御装置に送信する送信部と、
前記発信要求の着信先端末としての携帯電話端末が前記呼制御装置から送信される前記発信要求を前記ＩＰネットワークを介して前記携帯電話ネットワークに収容された異なる携帯電話用無線基地局を利用して受信できる場合に前記呼制御装置から受信される、前記ＩＰ電話用プロトコルに基づく前記発信端末へ送信すべきメッセージを前記プロトコル変換部で前記携帯電話用プロトコルに基づく形式に変換して前記発信端末に送信し、前記携帯電話用無線基地局と前記異なる携帯電話用無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを介して接続されたデータ伝送路を、前記発信端末と前記着信先端末との間で通信されるデータを伝送するために、前記携帯電話用無線基地局と前記異なる携帯電話用無線基地局との間で前記呼制御装置を通じて確立する制御を行う制御手段と、
を含む携帯電話端末の携帯電話用無線基地局。
【請求項１２】
携帯電話端末と前記携帯電話ネットワークとの間で実行される手順を、前記携帯電話ネットワークの代わりに代行する代行手段をさらに含む
請求項１１に記載の携帯電話端末の携帯電話用無線基地局。
【請求項１３】
前記携帯電話用無線基地局は、
発信側無線基地局として、前記発信端末との間に第１のデータ伝送路を確立し、
前記着信側無線基地局の配下に前記着信先端末が存在しないことを示すメッセージが前記呼制御装置を介して前記受信部で受信される場合に、前記携帯電話用無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、
前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１１又は１２に記載の携帯電話端末の携帯電話用無線基地局。
【請求項１４】
前記携帯電話用無線基地局は、
前記呼制御装置が前記発信要求を送信すべき前記異なる携帯電話用無線基地局を見つけることができない場合に、発信側無線基地局として前記携帯電話用無線基地局自身と前記発信端末との間に第１のデータ伝送路を確立し、
前記携帯電話用無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記携帯電話用無線基地局自身と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、
前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１１〜１３のいずれか一項に記載の携帯電話端末の携帯電話用無線基地局。
【請求項１５】
前記携帯電話用無線基地局は、第２のデータ伝送路を確立するために、前記第１のデータ伝送路を確立するために前記発信端末との間で行われた呼接続手順により得られた情報に基づいて、前記携帯電話用無線基地局自身を発信端末として前記携帯電話ネットワークに対して発信し、前記携帯電話ネットワークを介して前記着信先端末と前記携帯電話用無線基地局との間の呼接続手順を実行する
請求項１３又は１４に記載の携帯電話端末の携帯電話用無線基地局。
【請求項１６】
前記携帯電話用無線基地局は、前記携帯電話用無線基地局自身を発信端末として前記携帯電話ネットワークに発信する場合には、前記発信端末から見て前記携帯電話用無線基地局自身が前記携帯電話ネットワークに見え、且つ前記携帯電話ネットワークから見て前記携帯電話用無線基地局自身が発信端末に見えるように、前記発信端末及び前記携帯電話ネットワークから受信するメッセージに応じた応答メッセージを返信する
請求項１５に記載の携帯電話端末の携帯電話用無線基地局。
【請求項１７】
前記携帯電話用無線基地局自身と前記発信端末との間で決定された第１の暗号化方式で制御信号及びユーザデータを暗号化／復号化する第１暗号処理部と、
前記携帯電話用無線基地局自身と前記携帯電話ネットワークとの間で決定された第２の暗号化方式で制御信号及びユーザデータを暗号化／復号化する第２暗号処理部とをさらに含み、
前記第１の暗号化方式で暗号化された制御信号及びユーザデータを前記発信端末から受信した場合には、前記制御信号及びユーザデータを前記第１暗号処理部で復号化し且つ復号化された制御信号及びユーザデータを前記第２暗号処理部で暗号化した後に、前記携帯電話ネットワークへ送信し、
前記第２の暗号化方式で暗号化された制御信号及びユーザデータを前記携帯電話ネットワークから受信した場合には、前記制御信号及びユーザデータを前記第２暗号処理部で復号化し且つ復号化された制御信号及びユーザデータを前記第１暗号処理部で暗号化した後に、前記発信端末へ送信する
請求項１３〜１６のいずれか一項に記載の携帯電話端末の携帯電話用無線基地局。
【請求項１８】
携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して収容される携
帯電話用無線基地局であって、
携帯電話端末の識別情報と、この携帯電話端末が利用可能な前記ＩＰネットワークを介して前記携帯電話ネットワークに収容された携帯電話用無線基地局のＩＰアドレスとを含む相手先情報を記憶する記憶部と、
携帯電話端末との間で使用される携帯電話用プロトコルとＩＰ電話用プロトコルとの間での変換処理を行うプロトコル変換部と、
発信端末としての携帯電話端末からの携帯電話用プロトコルに基づく発信要求を受信す
る受信部と、
前記携帯電話用プロトコルに基づく発信要求に含まれる着信先端末としての携帯電話端末の識別情報を取得し、取得された識別情報に対応する携帯電話用無線基地局のＩＰアドレスを前記記憶部から検索する検索部と、
前記対応する携帯電話用無線基地局のＩＰアドレスが検索された場合に、この検索されたＩＰアドレスを持つ携帯電話用無線基地局を着信側無線基地局として、この検索されたＩＰアドレス宛に、前記プロトコル変換部によって前記携帯電話用プロトコルに基づく形式がＩＰ電話用プロトコルに基づく形式に変換された発信要求を送信する送信部と、
前記着信側無線基地局自身の配下に前記着信先端末が存在する場合に前記着信側無線基地局から受信される、前記ＩＰ電話用プロトコルに基づく前記発信端末へ送信すべきメッセージを前記プロトコル変換部で前記携帯電話用プロトコルに基づく形式に変換して前記発信端末に送信し、前記携帯電話用無線基地局自身と前記着信側無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を、前記発信端末と前記着信先端末との間で通信されるデータを伝送するために、前記携帯電話用無線基地局自身と前記着信側無線基地局との間で確立する制御を行う制御手段と、
を含む携帯電話端末の携帯電話用無線基地局。
【請求項１９】
携帯電話端末と前記携帯電話ネットワークとの間で実行される手順を、前記携帯電話ネットワークの代わりに代行する代行手段をさらに含む
請求項１８記載の携帯電話端末の携帯電話用無線基地局。
【請求項２０】
前記携帯電話用無線基地局は、
前記発信端末との間に第１のデータ伝送路を確立し、
前記着信側無線基地局の配下に前記着信先端末が存在しないことを示すメッセージを前記受信部が前記着信側無線基地局から受信した場合に、前記携帯電話用無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、
前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１８又は１９に記載の携帯電話端末の携帯電話用無線基地局。
【請求項２１】
前記携帯電話用無線基地局は、
前記発信要求に対応する相手先情報が前記記憶部に登録されていない場合に、前記携帯電話用無線基地局と前記発信端末との間に第１のデータ伝送路を確立し、
前記携帯電話用無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、
前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１８〜２０のいずれか一項に記載の携帯電話端末の携帯電話用無線基地局。
【請求項２２】
前記携帯電話用無線基地局は、第２のデータ伝送路を確立するために、前記第１のデータ伝送路を確立するために前記発信端末との間で行われた呼接続手順により得られた情報に基づいて、前記携帯電話用無線基地局自身を発信端末として前記携帯電話ネットワークに対して発信し、前記携帯電話ネットワークを介して前記着信先端末と前記携帯電話用無線基地局との間の呼接続手順を実行する
請求項２０又は２１に記載の携帯電話端末の携帯電話用無線基地局。
【請求項２３】
前記携帯電話用無線基地局は、前記携帯電話用無線基地局自身を発信端末として前記携帯電話ネットワークに発信する場合には、前記発信端末から見て前記携帯電話用無線基地
局自身が前記携帯電話ネットワークに見え、且つ前記携帯電話ネットワークから見て前記携帯電話用無線基地局自身が発信端末に見えるように、前記発信端末及び前記携帯電話ネットワークから受信するメッセージに応じた応答メッセージを返信する
請求項２２に記載の携帯電話端末の携帯電話用無線基地局。
【請求項２４】
前記携帯電話用無線基地局と前記発信端末との間で決定された第１の暗号で制御信号及びユーザデータを暗号化／復号化する第１暗号処理部と、
前記携帯電話用無線基地局と前記携帯電話ネットワークとの間で決定された第２の暗号で制御信号及びユーザデータを暗号化／復号化する第２暗号処理部とをさらに含み、
前記携帯電話用無線基地局は、前記第１の暗号で暗号化された制御信号及びユーザデータを前記発信端末から受信した場合には、前記制御信号及びユーザデータを前記第１暗号処理部で復号化し且つ復号化された制御信号及びユーザデータを前記第２暗号処理部で暗号化した後に、前記携帯電話ネットワークへ送信し、
前記携帯電話用無線基地局は、前記第２の暗号化で暗号化された制御信号及びユーザデータを前記携帯電話ネットワークから受信した場合には、前記制御信号及びユーザデータを前記第２暗号処理部で復号化し且つ復号化された制御信号及びユーザデータを前記第１暗号処理部で暗号化した後に、前記発信端末へ送信する
請求項２０〜２３のいずれか一項に記載の携帯電話端末の携帯電話用無線基地局。
【請求項２５】
前記携帯電話用無線基地局の内部には、ユーザデータが前記第１暗号処理部のみを通過する第１ルートと、ユーザデータが前記第１暗号処理部及び第２暗号処理部を通過する第２ルートとが設けられ、
前記ユーザデータの前記携帯電話用無線基地局内部における転送ルートを前記第１ルートと第２ルートとの間で切り替える切替部と、
前記携帯電話用無線基地局と前記異なる携帯電話用無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを介して接続されたデータ伝送路が確立される場合には前記切替部に第１ルートを選択させ、前記第１のデータ伝送路と前記第２のデータ伝送路が接続される場合には前記切替部に前記第２ルートを選択させる切替制御部と
をさらに含む請求項１７又は２４に記載の携帯電話端末の携帯電話用無線基地局。
【請求項２６】
前記着信先端末の呼び出し音を生成する呼び出し音生成部と、
前記携帯電話用無線基地局自身と前記着信側無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路が確立される場合に、前記着信先端末の呼び出し中を示すメッセージが受信されてから前記着信先端末が呼び出しに応じたことを示すメッセージが受信されるまでの間、前記発信端末と前記無線基地局との間に確立されているデータ伝送路に前記呼び出し音生成部からの呼び出し音を接続する呼び出し音制御部とをさらに含む
請求項１１〜２５のいずれか一項に記載の携帯電話端末の携帯電話用無線基地局。
【請求項２７】
通知音生成部と、
前記携帯電話用無線基地局自身が発信端末として前記第２のデータ伝送路を確立する場合に、前記発信端末と前記携帯電話用無線基地局との間に確立されている第１のデータ伝送路に前記通知音生成部で生成される通知音を接続する通知音制御部とをさらに含む
請求項１１，１４〜１７，及び２０〜２６のいずれか一項に記載の携帯電話端末の携帯電話用無線基地局。
【請求項２８】
携帯電話ネットワークに同一のＩＰ(Internet Protocol)ネットワークを介して収容さ
れる複数の携帯電話用無線基地局と、前記ＩＰネットワークに設けられる呼制御装置とを含むネットワークシステムにおいて、
前記呼制御装置が、発信側無線基地局としての前記複数の携帯電話用無線基地局の一つから、発信端末としての携帯電話端末からの携帯電話用プロトコルに基づく発信要求がＩＰ電話用プロトコルに基づく形式に変換された発信要求を受信し、
前記呼制御装置が、前記発信要求に含まれる着信先端末としての携帯電話端末の識別情報を取得し、取得された識別情報に対応する携帯電話用無線基地局のＩＰアドレスを、携帯電話端末の識別情報と、この識別情報を有する携帯電話端末が利用可能な前記ＩＰネットワークを介して前記携帯電話ネットワークに収容された携帯電話用無線基地局のＩＰアドレスとを含む相手先情報を記憶した記憶部から読み出し、
前記記憶部から携帯電話用無線基地局のＩＰアドレスが読み出された場合に、前記呼制御装置が、当該ＩＰアドレスを持つ携帯電話用無線基地局を着信側無線基地局として、このＩＰアドレス宛に前記発信要求を送信し、
前記着信側無線基地局は、前記着信側無線基地局自身の配下に前記着信先端末が存在する場合に、前記着信側無線基地局自身のプロトコル変換部で前記呼制御装置から受信される前記ＩＰ電話用プロトコルに基づく発信要求及び前記着信先端末へ送信すべきメッセージを前記携帯電話用プロトコルに基づく形式に変換した後に、前記着信先端末へ送信し、
前記着信側無線基地局自身の配下に前記着信先端末が存在する場合に、前記発信側無線基地局と前記着信側無線基地局とが、前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を、前記発信端末と前記着信先端末との間で通信されるデータを伝送するために、前記発信側無線基地局と前記着信側無線基地局との間で前記呼制御装置を介して確立する
ことを含む携帯電話端末間のデータ伝送路確立方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して収容される小型基地局を利用した通信方式に関する。
【背景技術】
【０００２】
携帯電話ネットワーク、例えば第３世代携帯電話ネットワーク(Third Generation mobile phone network)において、地図的に見てサービスエリア(基地局からの電波が届く範囲)ではあるが、電波が届きにくい地域(「不感地帯」と呼ぶ)が存在する。電波は基本的に直進するため、建物の影、屋内、地下などでは、基地局からの無線電波が十分に届かない場合があるからである。【０００３】
不感地帯の一つとして、例えば屋内があり、特に戸建て、或いは集合住宅における個人宅内がある。この個人宅内に小型基地局を配置し、個人宅内で携帯電話ネットワークからの電波を円滑に受信できることが望まれている。【０００４】
本発明に関連する先行技術としては、例えば、以下の特許文献１及び２に記載された技術がある。
【特許文献１】特表２００４−５０７９４６号公報
【特許文献２】特表２００２−５３５８８８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、携帯電話ネットワークの不感地帯にＩＰネットワークを介して設置される小型の無線基地局を用いて、効率的な携帯電話ネットワーク及びＩＰネットワークの利用を図ることができる技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して収容される無線基地局と；前記無線基地局が発信端末としての携帯電話端末から受信する発信要求の着信先の携帯電話端末が前記ＩＰネットワークに接続された前記無線基地局と異なる無線基地局を利用して前記発信要求を受信することができる場合に、前記無線基地局と前記異なる無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を、前記発信端末と前記着信先端末との間で通信されるデータを伝送するために確立することを試みる試行手段と；を含む携帯電話端末間のデータ伝送路確立システムである。【０００７】
本発明によれば、無線基地局間が直接接続され、携帯電話ネットワークを経由しないデータ伝送路が携帯電話端末間のデータ通信のために確立される。これによって、端末間のデータ(ユーザデータ)が携帯電話ネットワークを経由しないので、携帯電話ネットワークにおけるトラフィックの軽減を図ることができる。【０００８】
また、携帯電話ネットワークを経由する端末間のデータ伝送路が確立される場合には、データのトラフィックは２回ＩＰネットワークを通過することになる。これに対し、無線基地局間が直接接続されたデータ伝送路が確立される場合には、データのトラフィックがＩＰネットワークを通過する回数は１回となる。これによって、ＩＰネットワークのトラフィックの軽減を図ることができる。【０００９】
本発明に係るシステムは、前記データ通信路を確立できない場合に、前記携帯電話ネットワーク及び前記ＩＰネットワークを経由する代わりのデータ伝送路を、前記発信端末と前記着信先端末との間で通信されるデータを伝送するために確立する手段をさらに含むことができる。【００１０】
無線基地局間を直接接続するデータ伝送路が確立できない場合には、携帯電話ネットワーク及びＩＰネットワークを経由する代わりのデータ伝送路が確立される。これによって、発信端末と着信先端末との間の接続を補償することができる。  【００１１】
また、本発明は、携帯電話ネットワークに同一のＩＰ(Internet Protocol)ネットワークを介して収容される複数の無線基地局と；前記ＩＰネットワークに設けられる呼制御装置とを含み、
前記呼制御装置は、携帯電話端末の識別情報と、この携帯電話端末が利用可能な前記ＩＰネットワークに収容された無線基地局のＩＰアドレスとを含む相手先情報を記憶する記憶部と；発信側無線基地局としての前記複数の無線基地局の一つから、発信端末としての携帯電話端末の発信要求を受信する受信部と；前記発信要求に含まれる着信先端末としての携帯電話端末の識別情報を取得し、取得された識別情報に対応する無線基地局のＩＰアドレスを前記記憶部から読み出す検索部と；前記検索部によって無線基地局のＩＰアドレスが読み出された場合に、このＩＰアドレスを持つ無線基地局を着信側無線基地局として、このＩＰアドレス宛に前記発信要求を送信する送信部とを含み、
前記着信側無線基地局自身の配下に前記着信先端末が存在する場合に、前記発信側無線基地局と前記着信側無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を、前記発信端末と前記着信先端末との間で通信されるデータを伝送するために、前記発信側無線基地局と前記着信側無線基地局との間で前記呼制御装置を介して確立する、携帯電話端末間のデータ伝送路確立システムである。【００１２】
このシステムにおいて、前記着信側無線基地局は、前記着信先端末に送信した前記発信要求に対する応答を受け取ることができない場合に、前記着信側無線基地局の配下に前記着信先端末が存在しないことを示すメッセージを前記呼制御装置を介して前記発信側無線基地局に通知し、
前記発信側無線基地局は、前記発信側無線基地局と前記発信端末との間に第１のデータ伝送路を確立し、前記呼制御装置から前記メッセージを受け取った場合に、前記発信側無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立するように構成することができる。【００１３】
また、当該システムは、前記発信側無線基地局が、前記発信要求に対応する相手先情報が前記記憶部に登録されていない場合に、前記発信側無線基地局と前記発信端末との間に第１のデータ伝送路を確立し、前記発信側無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し、前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立するように構成することができる。【００１４】
本発明は、携帯電話ネットワークに同一のＩＰ(Internet Protocol)ネットワークを介して収容される複数の無線基地局を備え、
発信側無線基地局としての前記複数の無線基地局の少なくとも１つは、携帯電話端末の識別情報と、この携帯電話端末が利用可能な前記ＩＰネットワークに収容された無線基地局のＩＰアドレスとを含む相手先情報を記憶する記憶部と；発信端末としての携帯電話端末からの発信要求を受信する受信部と；前記発信要求に含まれる着信先端末としての携帯電話端末の識別情報を取得し、取得された識別情報に対応する無線基地局のＩＰアドレスを前記記憶部から検索する検索部と；    前記対応する無線基地局のＩＰアドレスが検索された場合に、このＩＰアドレスを持つ無線基地局を着信側無線基地局として、このＩＰアドレス宛に前記発信要求を送信する送信部と；前記着信側無線基地局自身の配下に前記着信側端末が存在する場合に、前記発信側無線基地局と前記着信側無線基地局とが前記携帯電話ネットワークを経由することなく前記ＩＰネットワークを通じて結ばれたデータ通信路を、前記発信端末と前記着信先端末との間で通信されるデータを伝送するために、前記着信側無線基地局との間で確立する制御手段とを含む携帯電話端末間のデータ伝送路確立システムである。【００１５】
このシステムは、前記着信側無線基地局が、前記着信先端末に送信した前記発信要求に対する応答を受け取ることができない場合に、前記着信側無線基地局の配下に前記着信先端末が存在しないことを示すメッセージを前記発信側無線基地局に通知し、
前記発信側無線基地局は、前記発信側無線基地局と前記発信端末との間に第１のデータ伝送路を確立し；前記着信側無線基地局から前記メッセージを受け取った場合に、前記発信側無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し；前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立するように構成することができる。【００１６】
また、このシステムは、前記発信側無線基地局が、前記発信要求に対応する相手先情報が前記記憶部に登録されていない場合に、前記発信側無線基地局と前記発信端末との間に第１のデータ伝送路を確立し；さらに、前記発信側無線基地局自身を発信端末として前記携帯電話ネットワークを介して前記発信側無線基地局と前記着信先端末との間を結ぶ第２のデータ伝送路を確立し；前記第１のデータ伝送路と前記第２のデータ伝送路とを接続することによって、前記発信端末と前記着信先端末との間のデータ伝送路を確立するように構成することができる。【００１７】
また、本発明は、上記したシステムを構成する無線基地局、呼制御装置、及び上記したシステムと同様の特徴を持つデータ伝送路の確立方法を実現することができる。
【発明の効果】
【００１８】
本発明によれば、携帯電話ネットワークの不感地帯にＩＰネットワークを介して設置される小型の無線基地局を用いて、効率的な携帯電話ネットワーク及びＩＰネットワークの利用を図ることができる。
【図面の簡単な説明】
【００１９】
【図１】図１は、本発明を適用可能な携帯電話ネットワークの構成例を示す図である。
【図２】図２は、現行の音声データが通るベアラルートを示した図である。
【図３】図３は、本発明による音声データが通るベアラルートを示した図である。
【図４】図４は、本発明の第１の態様を説明するためのネットワーク構成例を示す図であり、端末間をＣＡＢＳで直接接続可能な場合(第１のケース)を示す図である。
【図５】図５は。本発明の第１の態様を説明するためのシーケンス図であり、図４に対応している。
【図６】図６は、本発明の第１の態様を説明するためのネットワーク構成例を示す図であり、端末同士をＣＡＢＳで直接接続不可能な場合(第２のケース)を示す図である。
【図７】図７は、本発明の第１の態様を説明するためのシーケンス図であり、図６に対応している。
【図８】図８は、本発明の第２の態様を説明するためのネットワーク構成例を示す図であり、端末同士をＣＡＢＳで直接接続可能な場合(第３のケース)を示す図である。
【図９】図９は、本発明の第２の態様を説明するためのシーケンス図であり、図８に対応している。
【図１０】図１０は、本発明の第２の態様を説明するためのネットワーク構成例を示す図であり、端末同士をＣＡＢＳで直接接続不可能な場合(第４のケース)を示す図である。
【図１１】図１１は、本発明の第２の態様を説明するためのシーケンス図であり、図１０に対応している。
【図１２】図１２は、本発明の第３の態様(第１の態様において着信側未登録の場合)のシーケンスを示す図である。
【図１３】図１３は、本発明の第３の態様(第２の態様において着信側未登録の場合)のシーケンスを示す図である。
【図１４】図１４は、本発明の第１実施例(第１の態様におけるＣＡＢＳ直接接続可能な場合(第１のケース)の実施例)を示すシーケンス図である。
【図１５】図１５は、本発明の第１実施例(第１の形態におけるＣＡＢＳ直接接続可能な場合(第１のケース)の実施例)を示すシーケンス図である。
【図１６】図１６は、本発明の第２実施例(第１の形態におけるＣＡＢＳ直接接続不可能な場合(第２のケース)の実施例)を示すシーケンス図である。
【図１７】図１７は、本発明の第２実施例(第１の形態におけるＣＡＢＳ直接接続不可能な場合(第２のケース)の実施例)を示すシーケンス図である。
【図１８】図１８は、本発明の第２の形態におけるＣＡＢＳ直接接続可能な場合の実施例のシーケンス図である。
【図１９】図１９は、本発明の第２の形態におけるＣＡＢＳ直接接続不可能な場合の実施例のシーケンス図である。
【図２０】図２０は、本発明の第１の形態における着信側ＣＡＢＳがCA Serverに未登録であった場合のシーケンス図である。
【図２１】図２１は、本発明の第２の形態における着信側ＣＡＢＳが発信側ＣＡＢＳに未登録であった場合のシーケンス図である。
【図２２】図２２は、本発明に係る小型基地局(ＣＡＢＳ)の構成例を示すブロック図である。
【図２３】図２３は、本発明に係る呼制御装置の構成例を示すブロック図である。
【図２４】図２４は、本発明に係る小型基地局における相手先の割出部の構成例を示すブロック図である。
【符号の説明】
【００２０】
１０・・・ＣＡＢＳ(無線基地局)
１９・・・ＣＮＴ部(制御部，プロトコル変換部)
２０・・・端末側エミュレータ
２１・・・ネットワーク側エミュレータ
２２・・・第１暗号処理部
２３・・・第２暗号処理部
２４・・・ベアラセレクタ(切替部)
２５・・・トーン生成部
３０・・・呼制御装置
３１,４１・・・メッセージ受信部(受信部)
３２,４２・・・メッセージ解析部
３３,４３・・・相手先検索部(検索部)
３４,４４・・・メッセージ生成部
３５,４５・・・メッセージ送信部(送信部)
３６,４６・・・登録表記憶部(記憶部)
３６Ａ,４６Ａ・・・登録表
【発明を実施するための最良の形態】
【００２１】
〔本発明の経緯〕
最初に、本発明の経緯について説明する。携帯電話ネットワークのサービスエリア内に存在する不感地帯として、例えば戸建てや集合住宅における個人宅(user home)がある。このような個人宅内に小型の無線基地局を設置し、携帯電話のユーザが個人宅内から携帯電話を使用できることが望まれている。このような宅内用の小型基地局は、一般に設置されている基地局と比較して以下の特徴を有することが好ましい。【００２２】
(1) 宅内への設置を可能とすべく、小型で安価、かつサービスエリア（小型基地局からの電波の届く範囲）が狭小で、電波が低出力である（他の同様な基地局に対しできるだけ電波干渉を小さくする）。【００２３】
(2) ネットワークを形成するために、基地局と基地局制御装置間に物理回線を敷設しなければならない。この物理回線において、現在個人宅に普及が進んでいるインターネット接続用のブロードバンド回線（例：ｘＤＳＬ(x Digital Subscriber Line)回線サービス、或いはＣＡＴＶ(Cable TV)のインターネット接続サービス等）が持つＩＰパケット伝送路に相乗りする形式で、データを送受信する。【００２４】
(3) 宅内用の小型基地局は個人宅のユーザが費用を払って設置することが想定される。この点に鑑み、小型基地局の設置ユーザ（およびその関係者）のみに小型基地局に対する接続を許可するための認証機能(端末-小型基地局認証機能)が、基地局制御装置(ＲＮＳ：Radio Network Sub-system)と小型基地局との間に設けられている。【００２５】
図１は、携帯電話ネットワークと小型基地局との接続構成例を示す図である。図１において、ＭＳＣ(Mobile Services Switching Center:交換移動局)は携帯電話ネットワークの交換処理装置(交換機)である。ＭＳＣは、相互に接続されるとともに、少なくとも１つのＲＮＳを収容する。ＲＮＳは、配下の基地局を制御する基地局制御装置である。ＲＮＳは、少なくとも１つのＢＴＳ(Base Transceiver Station)を収容する。ＢＴＳは、移動端末(mobile station又はuser equipment(UE))と無線通信を行うための基地局である。以上が、携帯電話ネットワークに含まれる構成要素である。【００２６】
なお、図１には、携帯電話ネットワークの例として、３Ｇ(IMT-2000)のＵＭＴＳ(Universal Mobile Telecommunication System)の一部が示されている。ＵＭＴＳは、大略して、コアネットワークと、コアネットワークへのアクセスネットワーク(UTRAN(Universal Terrestrial Radio Access Network))とからなる。ＵＴＲＡＮは無線部分を含む。図１に示すＭＳＣは、コアネットワークに含まれる要素であり、ＲＮＳ及びＢＴＳはＵＴＲＡＮに含まれる要素である。【００２７】
図１に示すＣＡＢＳ(Cubicle Area BTS)が宅内用の小型基地局装置(very small BTS for home user)に相当する。ＣＡＢＳは、一般住宅内に設置され、携帯電話ネットワークのＲＮＳとＩＳＰ(Internet Service Provider)ネットワーク経由で接続される。【００２８】
図１に示す例では、ユーザの宅内には、ＩＳＰによって提供されるインターネット接続用のブロードバンド回線（例えばｘＤＳＬ）が導入されていることが想定されている。ＣＡＢＳは、ブロードバンド回線として利用される固定電話回線を収容するｘＤＳＬモデムのＩＰインタフェースに接続される。ｘＤＳＬモデムは、固定電話回線から分配されるｘＤＳＬ回線を介してＩＳＰネットワークに設けられたＤＳＬＡＭ(Digital Subscriber Line Access Multiplexer)に接続される。【００２９】
一方、ＲＮＳは、ＩＷＵ(Inter-Working Unit)を介してＩＳＰネットワークの入口に設けられたエッジルータ(ＥＲ)に接続される。これによって、携帯電話ネットワークとＩＳＰネットワークとが接続されている。【００３０】
ＩＷＵは、ＩＰレイヤと現在の携帯電話ネットワークの下位レイヤであるＡＴＭ(Asynchronous Transfer Mode)との変換装置である。ＲＮＳとＥＲとの間は、携帯電話ネットワークからの呼量に応じた数の回線で接続される。【００３１】
このようにして、ＣＡＢＳは、物理的には固定電話回線で接続される。また、ＣＡＢＳは、ＲＮＳとＩＰインタフェースで接続される。このようにして、或るＩＳＰネットワークに接続されているＣＡＢＳの全ては、携帯電話ネットワークに収容することができる。【００３２】
このようにして、ＣＡＢＳを宅内に既に敷設されているブロードバンド回線(ＩＳＰへの接続環境)を用いて携帯電話ネットワークに接続すれば、携帯電話ネットワーク(ＲＮＳ)への特別な回線をＣＡＢＳが設置される各住宅に敷設する必要がない。従って、ＣＡＢＳの導入に係るコストを削減することができる。【００３３】
また、ＣＡＢＳは、特定の端末のみにＣＡＢＳ自身に対する接続を許可する機能を有している。具体的には、ＣＡＢＳが端末からの接続要求を受け取った場合に、ＲＮＳ／ＭＳＣでＣＡＢＳとの対認証処理が行われる。ＣＡＢＳは、認証処理の結果を元に、接続要求元の端末が接続可能端末であれば、端末からの接続要求を許可する。【００３４】
図２は、図１に示したようなＣＡＢＳを収容する方式において、端末同士が同じＩＳＰに収容されているＣＡＢＳの配下で通信を行う場合を示す。【００３５】
図２で明らかなように、端末間で受け渡しされるデータ（例えば音声呼であれば音声データ）は、ＣＡＢＳ１ａ−ＲＮＳ１−ＭＳＣ−ＲＮＳ２−ＣＡＢＳ２ａの経路(図中において矢印で示す)を通過する。このとき、同じＩＳＰネットワーク（ＩＰネットワーク）を２度通ることになる。【００３６】
もし、図２に示すような経路を用いる通信において、図３に示すように、端末間で受け渡しされるデータがＣＡＢＳ間の直接的な接続により受け渡しできれば、ＩＳＰネットワーク内を通るトラフィックは半分になる。また、ＣＡＢＳ間のトラフィックは、ＩＳＰネットワークに上位に位置する携帯電話ネットワークを通らないので、設備的に有利であることは明らかである。【００３７】
各ＣＡＢＳは、ＩＳＰネットワーク内でユニークに割り当てられたＩＰアドレスを有している。ＣＡＢＳ間でお互いのＩＰアドレスを知ることができれば、ＩＰパケット(例えば、音声データが含まれたＩＰパケット)を直接的に(携帯電話ネットワークを経由することなく)やりとりすることが可能である。【００３８】
このような通信形態は、現在多くのＩＳＰがサービスを提供しているＩＰ電話による通信と同様の形態である。ＩＳＰはＩＰ電話サービスを行うためにＩＳＰネットワーク内に呼制御サーバ(CA(Call Agent) server)を設置し、ＩＰ電話端末と呼制御信号をやりとりして、通話サービスを提供する。このため、携帯電話端末＋ＣＡＢＳのセットをＩＰ電話端末に見立てれば、同様の手段でサービスを提供することができると考えられる。【００３９】
しかしながら、上述したようなＩＳＰネットワークを介してＣＡＢＳ間を直接的に接続するサービスを実際に実現するには大きな問題がある。【００４０】
まず、携帯電話端末及びＣＡＢＳは、ＩＳＰが通常提供しているＩＰ電話のプロトコル（ＳＩＰ(Session Initiation Protocol)など）とは異なる携帯電話のプロトコル（３ＧＰＰ標準）を採用している。このため、現状ではＣＡＢＳと呼制御サーバとの間で制御信号のやりとりはできない。また、携帯電話端末はいつもＣＡＢＳの通信範囲にいるわけではない。【００４１】
また、ＩＳＰの呼制御サーバは、或る携帯電話端末＋ＣＡＢＳからの発信要求に対し、着信先を登録されているであろうＣＡＢＳ＋携帯電話端末へ着信要求を出すことになる。この場合、この着信要求は相手先のＣＡＢＳに到達することができる。しかし、着信要求を受信したＣＡＢＳの通信範囲(ＣＡＢＳからの着信要求(無線電波)が届く範囲)に本来の着信先である携帯電話端末が存在しているとは限らない。【００４２】
着信先の携帯電話端末がＣＡＢＳの通信範囲に所在しない場合、この携帯電話端末が携帯電話ネットワーク内のどこかの或るＢＴＳの配下に所在する場合がある。この場合、着信要求がそのＢＴＳを通じて着信先の携帯電話端末に着信するようにすることが望まれる。【００４３】
しかし、呼制御サーバが、着信先の携帯電話端末が或るＢＴＳの配下に位置することを知ることはできない。また、呼制御サーバは、当該或るＢＴＳに着信要求を接続することもできない。【００４４】
本発明は、上述した問題に鑑みなされたものである。本発明は、同じＩＰネットワークに収容された小型基地局間を通じて端末間の通信が行われる場合において、携帯電話ネットワーク及びＩＰネットワークに対する負荷を低減することができる技術を提供することにある。【００４５】
〔本発明の概要〕
本発明は、携帯電話端末間のデータ伝送路確立方法及びそのシステムに関する。本発明では、同じＩＳＰネットワーク(アドレス付与体系が同一のＩＰネットワーク)に複数の小型基地局(ＣＡＢＳ)が接続されている場合において、発信端末としての携帯電話端末からの発信要求が複数のＣＡＢＳの一つで受信された場合に、この発信要求の着信先としての着信先端末と発信端末との間でデータを伝送するために、前記発信要求を受信した発信側ＣＡＢＳと前記着信先端末を配下に持つ着信側ＣＡＢＳとの間に移動通信ネットワークを経由することなくＣＡＢＳ間が直接的に接続された実質的なデータ伝送路を確立することを試みる。【００４６】
上記した実質的なデータ伝送路を確立できない場合には、携帯電話ネットワーク及びＩＰネットワークを通じた発信端末と着信先端末との間のデータ伝送路の確立が行われる。【００４７】
本発明は、ＩＳＰネットワーク内に設けられる呼制御装置を利用して実現することができる(第１の態様)。また、本発明は、呼制御装置を利用することなく実現することもできる(第２の態様)。【００４８】
本発明を呼制御装置の利用により実現する場合(第１の態様)では、ＩＳＰネットワークに呼制御装置を配置し、呼制御装置が、発信側のＣＡＢＳと着信側のＣＡＢＳとの間でメッセージのやりとりを行うことで、呼制御装置がＣＡＢＳ間の直接的な接続を制御するように構成される。【００４９】
呼制御装置として、専用の呼制御装置をＩＳＰネットワークに配置し、ＣＡＢＳ間の呼接続(データ伝送路の確立)を制御しても良い。しかし、呼制御装置として、従来からＩＳＰネットワークに設けられているＩＰ電話用の呼制御サーバ(「ＣＡ(call agent)サーバ」と呼ばれる)を利用するのが、システム構築に係るコストの上昇を抑える点で好ましい。【００５０】
呼制御サーバは、ＳＩＰなどの所定のＩＰ電話用のプロトコルを認識する機能を持つ。しかし、呼制御サーバは、携帯電話用のプロトコルを認識する機能を持たない。このため、発信側ＣＡＢＳ又は着信先ＣＡＢＳとなる各ＣＡＢＳには、携帯電話用プロトコルとＩＰ電話用プロトコルとの間のプロトコル変換を行うプロトコル変換機能(プロトコル変換部)が搭載される。【００５１】
ＣＡＢＳは、プロトコル変換機能を用いて、携帯電話用プロトコルに基づく移動端末からのメッセージ(発信要求など)を呼制御サーバで認識可能なＩＰ電話用プロトコルに基づく形式に変換したり、呼制御サーバから受信されるメッセージを移動端末で認識可能な携帯電話用プロトコルに基づく形式に変換したりする。【００５２】
また、呼制御装置(呼制御サーバ)が適用される場合には、呼制御装置において、発信要求の着信先端末が発信側ＣＡＢＳと同一のＩＳＰネットワークに接続されたＣＡＢＳを利用可能な携帯電話端末かが判断される。【００５３】
このような判断を行うため、例えば、発信側ＣＡＢＳと同一のＩＳＰネットワークに接続されたＣＡＢＳのＩＰアドレスと、このＣＡＢＳを利用可能な移動端末の識別情報(例えば移動端末の電話番号)とを含む相手先情報が登録された記憶装置(記憶部)を呼制御装置が有することが必要である。【００５４】
さらに、呼制御装置が、発信側ＣＡＢＳからの発信要求の受信を契機に、当該発信要求の送信元ＩＰアドレス(発信側ＣＡＢＳのＩＰアドレス)と当該発信要求に含まれる着信先端末の識別情報とに対応する相手先情報が記憶部に登録されているかを判断する機能(判断部)と、対応する相手先情報が記憶されている場合に、この相手先情報に含まれるＣＡＢＳのＩＰアドレスを発信要求の着信先として決定する機能(決定部)とが必要である。【００５５】
呼制御装置としてＩＰ電話用の呼制御サーバが適用される場合には、呼制御サーバに対して、上記登録部及び判断機能(判断部)を搭載するために、次のような改良を施すのが好ましい。【００５６】
呼制御サーバは、ＩＰ電話端末間の接続サービスを行うために、ＩＰ電話端末のＩＰアドレスとそのＩＰ電話端末の電話番号とを含むエントリリストが登録された登録表と、ＩＰ電話端末からの発信要求の受信を契機に、登録表から発信要求に対応するエントリを読み出して、発信要求の着信先のＩＰ電話端末のＩＰアドレスを割り出す割り出し機能(割り出し部)とを有している。【００５７】
なお、登録表の各エントリには、実際には、ＩＰ電話端末のＩＰアドレス及び電話番号に加えて、ＲＴＰ／ＵＤＰ(Real-time Transport Protocol／User Datagram Protocol)セッションを確立するためのポート番号や音声符号化方式が、音声呼を確立するための制御情報としてさらに登録されている。【００５８】
このような登録表に、上述したような相手先情報(ＣＡＢＳのＩＰアドレス及びこのＣＡＢＳの配下となり得る移動端末の識別情報)を含むエントリを登録すれば、呼制御サーバが各ＣＡＢＳ＋移動端末をＩＰ電話端末として認識できる。そして、呼制御サーバは上記した割り出し機能を用いて、着信先のＣＡＢＳ＋移動端末を割り出すことが可能となる。なお、登録表のエントリには、端末が移動端末であることの識別フラグを設けることもできる。【００５９】
さらに、呼制御サーバに登録されているＣＡＢＳの配下に接続したい端末(着信先端末)がいない場合に、このことを呼制御サーバが判断(認識)するためのメカニズム(構成(configuration))が必要である。【００６０】
さらに、着信先端末が登録ＣＡＢＳの配下にいないと判断される場合に、呼制御サーバが携帯電話ネットワークに対して発信処理を行うメカニズム(構成)が必要である。【００６１】
本発明を呼制御装置を用いることなく実現する場合(第２の態様)では、ＣＡＢＳが発信側ＣＡＢＳとして発信端末からの発信要求を受信したことを契機に、発信要求の着信先端末が、発信側ＣＡＢＳと同一のＩＳＰネットワークに接続されたＣＡＢＳを利用可能な移動端末か否かを判断する構成が必要である。【００６２】
このため、ＣＡＢＳには、上述した相手先情報が登録された記憶部が設けられる。さらに、ＣＡＢＳには、発信端末からの発信要求の受信を契機に、記憶部に発信要求に対応する相手先情報が登録されているかを判断する判断部と、判断部の判断結果に基づいて発信要求の着信先を決定する決定部が設けられる。【００６３】
〔本発明の態様〕
以下、本発明の態様を図面を参照して説明する。以下に説明する構成は例示であり、本発明はこれに限定されない。【００６４】
〈第１の態様〉
本発明の第１の態様として、ＩＳＰネットワーク内に存在するＩＰ電話の呼制御サーバを介して小型基地局間の携帯電話ネットワークを経由しないデータ通信路を確立する方式について説明する。【００６５】
《第１のケース》
図４は、第１のケースとして、ＩＳＰネットワーク(以下、単に「ＩＳＰ」と表記する)内に、呼制御装置としての呼制御サーバ(CA  Server)が存在する場合において、発信端末(calling terminal)としての移動端末(以下、単に「端末」と表記する)ＵＥ−ａおよび着信先端末(called terminal)としての端末ＵＥ−ｂの夫々がＩＳＰ１に接続されたＣＡＢＳ１及びＣＡＢＳ２と夫々通信可能な状態である場合のシーケンスを説明する図である。図５は、図４に示した状態、つまり端末ＵＥ−ｂがＩＳＰ１に接続されたＣＡＢＳ２と通信可能な場合のシーケンス図である。【００６６】
図４及び図５に示すように、端末ＵＥ−ａが発呼すると、ＣＡＢＳ１を介して、端末ＵＥ−ａと呼制御サーバとの間で、呼の前処理(CALL PREPROCESSES)が行われる(Ｓ０１)。【００６７】
ここでは、ＣＡＢＳ１が本来前処理を行うＲＮＳ１／ＭＳＣ１の代わりとなってプロトコル終端を代行し前処理を行う。この前処理は、具体的にはネットワークへの認証と暗号化キーの確定を含む。【００６８】
前処理におけるネットワーク認証、つまりこのＩＳＰ１内で端末ＵＥ−ａが通信を行って良いかは、呼制御サーバで端末ＵＥ−ａが通信を行って良い端末として登録されているかを確認することで判断される。このため、端末との認証要求のやりとりを呼制御サーバが持つ呼制御プロトコル(ＩＰ電話用プロトコル)に変換する機能をＣＡＢＳ１が持つことが必要である。【００６９】
このように、ＣＡＢＳ１が携帯電話ネットワーク側の上位装置(ＲＮＳ／ＭＳＣ)とのプロトコルを代行して終端処理できる機能が第１の特徴であり、端末のプロトコルと呼制御サーバとのプロトコル変換機能を持つことが、本発明の第２の特徴である。但し、前処理が端末ＵＥ−ａとＣＡＢＳ１との間でのみ実施される(呼制御サーバを利用しない)ように構成することもできる。【００７０】
前処理が終了すると、発呼要求(呼接続要求)であるSETUP信号が端末ＵＥ−ａからＣＡＢＳ１に送信される(Ｓ０２)。ＣＡＢＳ１は、このSETUP信号をプロトコル変換機能により呼制御サーバが処理できる発呼相当の信号(図６ではSETUPメッセージを例示)に変換して送信する(Ｓ０３)。これが本発明の第３の特徴である。【００７１】
ＣＡＢＳ１からのSETUPメッセージには、ＣＡＢＳ１のＩＰアドレス、端末ＵＥ−ａの電話番号(発信端末の識別情報)，着信先端末の電話番号(着信先端末の識別情報)等の情報が含まれている。呼制御サーバは、ＣＡＢＳ１からのSETUPメッセージを受信すると、ＣＡＢＳ１がＩＰ電話端末であるという認識で動作する。【００７２】
SETUPメッセージには、着信先端末たる端末ＵＥ−ｂの電話番号が含まれている。呼制御サーバは、端末の識別番号と登録情報(上述した登録表に登録された情報)と照らし合わせて着信先ＣＡＢＳ２を割り出す。即ち、端末ＵＥ−ｂに対応するＣＡＢＳのＩＰアドレスとして、ＣＡＢＳ２のＩＰアドレスを登録表から読み出すことにより、着信先ＣＡＢＳを割り出すことができる。呼制御サーバは、ＣＡＢＳ２へ向けて発呼メッセージ(SETUP)を送信する(Ｓ０４)。この動作は、ＣＡＢＳ２をＩＰ電話端末としてみなした動作と同じである。【００７３】
ＣＡＢＳ２は、発呼メッセージ(SETUP)を受け取った場合には、最初に、端末ＵＥ−ｂ(発呼メッセージに含まれる識別番号により特定される)が配下に所在するかどうかを確認する。【００７４】
このため、着信要求メッセージ“PAGE REQUEST”により端末ＵＥ−ｂに対して着信要求を送信する(Ｓ０５)。このとき、ＣＡＢＳ２は、ＣＡＢＳ２自身に搭載されたプロトコル変換機能を用いて、発呼メッセージを端末ＵＥ−ｂで認識可能な“PAGE REQUEST”にプロトコル変換する。このプロトコル変換も第３の特徴である。【００７５】
端末ＵＥ−ｂがＣＡＢＳ２の通信範囲に所在(在圏)する場合には、端末ＵＥ−ｂは、着信要求“PAGE REQUEST”に対する応答をＣＡＢＳ２に返す。ＣＡＢＳ２が応答を受け取る場合には、端末ＵＥ−ａ側と同じ呼の前処理(CALL PREPROCESSES)が起動され(Ｓ０６)、端末ＵＥ−ｂのネットワーク認証が実行される。【００７６】
端末ＵＥ−ｂのネットワーク認証に問題がなければ、ＣＡＢＳ２は呼接続要求のSETUP信号を端末ＵＥ−ｂに送る(Ｓ０７)。端末ＵＥ−ｂがSETUP信号に応答することで、次の段階に入る。【００７７】
ところで、呼制御サーバは、ＣＡＢＳ１からのSETUP信号(発呼メッセージ：Ｓ０３)を受信し、この発呼メッセージに基づいて着信先(ＣＡＢＳ２)を確認できたところで、その着信先のＩＰアドレス(ＣＡＢＳ２のＩＰアドレス)が含まれる応答メッセージ“SETUP ACK”をＣＡＢＳ１に送信する(Ｓ０８)。【００７８】
ＣＡＢＳ１は、応答メッセージの受信を契機に、メッセージ“CALL PROCEEDING”を端末ＵＥ−ａに送るとともに、ＣＡＢＳ１とＵＥ−ａとの間に無線通信チャネルベアラ（音声データがやりとりされる：「無線ベアラ」と表記することもある）を確立させる(Ｓ０９：NEW BEARER SET)。【００７９】
一方、ＣＡＢＳ２側では、ＣＡＢＳ２が端末ＵＥ−ｂからSETUP信号(Ｓ０７)に対する“CALL CONFIRM”メッセージを受信する(Ｓ１１)と、ＣＡＢＳ２は、端末ＵＥ−ｂとの間で無線通信チャネルベアラの確立を行う(Ｓ１２)。【００８０】
このとき、端末ＵＥ−ｂは、呼び出し音を発して端末ＵＥ−ｂのユーザ呼び出しを告げるとともに、ベアラ確立を契機に呼び出し中メッセージであるALERTをＣＡＢＳ２に送る(Ｓ１３)。【００８１】
このALERTは、ＣＡＢＳ２，呼制御サーバ，ＣＡＢＳ１を経由して端末ＵＥ−ａに伝達される(Ｓ１４，Ｓ１５，Ｓ１６)。端末ＵＥ−ａはALEATを受信することで、端末ＵＥ−ｂの呼び出し中であることを認識することができる。【００８２】
このとき、端末ＵＥ−ａにＲＢＴ(Ring Back Tone)を聞かせる必要がある。このため、ＣＡＢＳ１は、Tone(トーン)生成機能を持つ。これが、本発明の第４の特徴である。【００８３】
端末ＵＥ−ｂのユーザが呼び出し音に応じて端末ＵＥ−ｂをオフフックし、呼び出しに応答すると、着呼端末が応答したことを示すCONNECTメッセージが端末ＵＥ−ｂから送信される(Ｓ０１７)。【００８４】
CONNECTメッセージは、ＣＡＢＳ２及び呼制御サーバ経由でＣＡＢＳ１に送られる(Ｓ１８，Ｓ１９)。そして、CONNECTメッセージは、ＣＡＢＳ１から端末ＵＥ−ａに与えられる(Ｓ２０)。【００８５】
CONNECTメッセージが端末ＵＥ−ａに伝わると、ＣＡＢＳ１とＣＡＢＳ２との間にＶｏＩＰ(Voice over IP)セッション(実質的なデータ伝送路)が確立したことになり、通信が開始可能になる。以降は、端末からの音声データがＣＡＢＳでパケット化されＣＡＢＳ１−ＣＡＢＳ２間を送受信される。【００８６】
ＣＡＢＳ１−ＣＡＢＳ２間には、ベアラという概念は存在せず(ＩＰネットワークであるため)、これまでに示した呼制御信号のやりとりで、相手先のＣＡＢＳのＩＰアドレスをパケットの宛先ＩＰアドレスに設定することで、音声データが送受信可能な状態になっている（つまりベアラが確保されたとみなされる(Bearer Securing)）。【００８７】
なお、CONNECTメッセージ(Ｓ２０)が端末ＵＥ−ａに届いて通信が開始されると同時に、ＣＡＢＳ１の内部では、端末ＵＥ−ａへの音声ルートパスをTone生成部から、ＣＡＢＳ２との音声データ通信に内部的に切り替えを行う(Ｓ２１)。これは本発明の第５の特徴になる。【００８８】
なお、ＣＡＢＳ２及び端末ＵＥ−ａの夫々は、CONNECTメッセージを受信すると、これに対する応答メッセージ“CONNECT ACK”を端末ＵＥ−ｂ及びＣＡＢＳ１へ夫々返す(Ｓ２２，Ｓ２３)。その後、端末ＵＥ−ａと端末ＵＥ−ｂとの間で通話中(during communication)となる(Ｓ２４)。【００８９】
通信が切断される場合には、次の手順が行われる。即ち、端末ＵＥからの切断指示に対し、ＣＡＢＳ１−呼制御サーバ−ＣＡＢＳ２−端末ＵＥ−ｂ間で切断信号のやりとり(切断処理：DISCONNECT PROCESS)が行われる(Ｓ２５)。【００９０】
その後、端末ＵＥ−ａとＣＡＢＳ１との間の無線ベアラの解放処理が行われる(Ｓ２６)。さらにまた、端末ＵＥ−ｂとＣＡＢＳ２との間の無線ベアラの解放処理が行われる(Ｓ２７)。この通信の切断処理は、携帯電話端末が切断を行う場合における網側の動作と同様の動作で実現することができる。【００９１】
以上説明したように、図５に示すようなネットワークシステムは、第１のケースにおいて、無線基地局としてのＣＡＢＳ１と、ＣＡＢＳ１が発信端末たる端末ＵＥ−ａから受信する発信要求(SETUP)の着信先端末(端末ＵＥ−ｂ)がＣＡＢＳ１が接続されたＩＰネットワークと同一のＩＰネットワーク(ＩＳＰ１)に接続された異なる無線基地局(ＣＡＢＳ２)を利用して発信要求を受信できる場合に、ＣＡＢＳ１−ＣＡＢＳ２間でＩＳＰ１を通じたデータ伝送路を確立することを試みる試行手段とを備えた携帯電話端末間のデータ伝送路確立システムとして機能する。第３のケースでは、呼制御サーバが試行手段としての機能を実現する。【００９２】
《第２のケース》
図６は、第２のケースとして、図４に示した着信側端末ＵＥ−ｂが一般のＢＴＳ(図６ではＢＴＳ２)の配下に所在する場合において、どのように発信動作が切り替わるかを示す図である。図７は、第２のケースにおけるシーケンス図である。【００９３】
図７において、端末ＵＥ−ａからの発呼手続きは、第１のケースと同様であり、呼制御サーバからのSETUP信号がＣＡＢＳ２に届く(Ｓ０１〜Ｓ０４)。また、第１のケースと同様に、呼制御サーバからの“SETUP ACK”送信を契機に、ＣＡＢＳ１と端末ＵＥ−ａとの間で無線通信チャネルベアラが確立される(Ｓ０８〜Ｓ１０)。【００９４】
ＣＡＢＳ２は、“SETUP”を受け取ると、第１のケースと同様に、着信要求“PAGE REQUEST”を端末ＵＥ−ｂへ向けて送信する(Ｓ０５)。しかし、端末ＵＥ−ｂは、配下(ＣＡＢＳ２の通信範囲)に所在していない。このため、端末ＵＥ−ｂからの応答はない。【００９５】
一方、ＣＡＢＳ２は、着信要求の送信を契機に、着信要求に対する応答をタイマにより監視する(Ｓ１０６)。ＣＡＢＳ２は、タイマがタイムアウトした時点でＣＡＢＳ２の配下に端末ＵＥ−ｂがいないと判断し、呼制御サーバにタイムアウトを通知するために、呼制御サーバにタイムアウトメッセージを送る(Ｓ１０７；P.REQ Timeout)。【００９６】
呼制御サーバがタイムアウトメッセージを受け取ると、呼制御サーバは、呼制御サーバが属するＩＳＰ内でＣＡＢＳ間を直接接続することが不可能と判断する。この場合、呼制御サーバは、ＣＡＢＳ１に発呼をやり直させるためのメッセージ(再発呼要求メッセージ。図７では“P.REQ Timeout”メッセージを例示)を送る(Ｓ１０８)。【００９７】
ＣＡＢＳ１は、再発呼要求メッセージを受信すると、携帯電話ネットワーク側に向けて発呼のやり直し(再発呼)を行う。これが本発明の第６の特徴である。【００９８】
ここから先の手順は、現状の携帯電話ネットワークの発呼／着呼シーケンスと同じ処理である。しかし、ＣＡＢＳ１が端末ＵＥ−ａの代行端末として、呼の前処理からやり直す点で従来と異なる。この相違点は、端末ＵＥ−ａが既に行った処理を繰り返すことができないことから生じている。【００９９】
このため、ＣＡＢＳ１は、携帯電話ネットワークに対して発信端末として振る舞い、ＣＡＢＳ１と端末ＵＥ−ｂとの間にデータ通信のためのベアラを確立させる。そして、ＣＡＢＳ１は、確立されたベアラをＣＡＢＳ１と端末ＵＥ−ａとの無線通信チャネルベアラに接続する。このようにして、ＣＡＢＳ１は、端末ＵＥ−ａに対し、端末ＵＥ−ａ自身が送信した発呼要求によって通信呼が確立したと見せかける。【０１００】
この場合、端末ＵＥ−ａとＣＡＢＳ１との間での呼前処理(Ｓ０１)で決定した暗号化キーと、ＣＡＢＳ１とＲＮＳ１／ＭＳＣ１との間で決定した暗号化キーが違うものとなる。このため、ＣＡＢＳ１は、ＣＡＢＳ１を通るすべての制御メッセージ及び通信データを復号化／再暗号化処理する。これが第７の特徴になる。【０１０１】
このような復号化及び再暗号化処理は、発信／着信処理だけでなく、呼の切断処理においても行われる。これによって、現状と同等のシーケンス処理を実施することができる。【０１０２】
図７を用いて、Ｓ１０８以降の処理(ＣＡＢＳ１による発呼／着呼シーケンス)について説明する。図７では、端末ＵＥ−ｂが、ＭＳＣ２／ＲＮＳ２の配下に存在するＢＴＳ２の通信範囲に所在している場合が想定されている。【０１０３】
ＣＡＢＳ１の発呼を契機として、ＣＡＢＳ１とＲＮＳ１／ＭＳＣ１との間で呼の前処理(CALL PREPROCESS)が行われる(Ｓ１０９)。【０１０４】
その後、発呼要求としてのSETUP信号がＲＮＳ１を通じてＣＡＢＳ１からＭＳＣ１に与えられる(Ｓ１１１)。ＭＳＣ１は、ＭＳＣ１自身の管理範囲に端末ＵＥ−ｂが存在するか否かを判定する。この判定は、例えば、ＭＳＣ１の管理範囲に存在する端末の識別情報が登録されるＶＬＲ(Visitor Location Register)と呼ばれる端末の位置管理レジスタ(図示せず)に端末ＵＥ−ｂが登録されているかを判断することによって行われる。【０１０５】
ＭＳＣ１は、ＭＳＣ１自身の管理範囲に端末ＵＥ−ｂが存在しない場合、ＨＬＲ(Home location Register：携帯電話ネットワークに登録された全ての端末の識別情報とその位置情報とが登録される位置管理レジスタ：図示せず)から、端末ＵＥ―ｂの位置を割り出す。ここでは、端末ＵＥ−ｂがＭＳＣ２の管理範囲に位置しているので、ＭＳＣ１は、SETUP信号をＭＳＣ２へ送る(Ｓ１１１)。【０１０６】
ＭＳＣ２は、ＭＳＣ２の管理範囲に属するＲＮＳにSETUP信号を送る(Ｓ１１２)。また、ＭＳＣ２は、ＭＳＣ１に対し、確認メッセージ“SETUP ACK”を返す(Ｓ１１３)。“SETUP ACK”をＭＳＣ１が受け取ると、ＭＳＣ１は、“CALL PROCEEDING”をＣＡＢＳ１に送信する(Ｓ１１３Ａ)。ＣＡＢＳ１が“CALL PROCEEDING”を受信するのを契機に、ＣＡＢＳ１とＭＳＣ１との間でＲＮＳ１を介したデータ伝送用のベアラが確立される(Ｓ１１３Ｂ)。【０１０７】
Ｓ１１２でＭＳＣ２から送信されるSETUP信号は、ＭＳＣ２の配下に属するＲＮＳ２に到着する。ＲＮＳ２は、ＲＮＳ２の配下に属する全ての基地局に着信要求たる“PAGE REQUEST”を送信する。これによって、“PAGE REQUEST”は、ＢＴＳ２を通じて端末ＵＥ−ｂに届く(Ｓ１１４)。【０１０８】
端末ＵＥ−ｂが“PAGE REQUEST”を受信したことを契機に、呼の前処理がＢＴＳ２を介して端末ＵＥ−ｂとＲＮＳ２／ＭＳＣ２との間で実行される(Ｓ１１５)。【０１０９】
その後、ＭＳＣ２から端末ＵＥ−ｂへ発信要求としてのSETUP信号が与えられる(Ｓ１１６)。すると、端末ＵＥ−ｂからＭＳＣ２へ確認メッセージ“CALL CONFIRM”が送信される(Ｓ１１７)。これによって、端末ＵＥ−ｂとＭＳＣ１との間におけるデータ(ここでは音声データ)伝送用のベアラが確立される(Ｓ１１８)。【０１１０】
その後、端末ＵＥ−ｂからメッセージ“ALERT”が送信される(Ｓ１１９，Ｓ１２０，Ｓ１２１)。ＣＡＢＳ１が端末ＵＥ−ｂからの“ALERT”を受信すると、ＣＡＢＳ１は、この“ALERT”を端末ＵＥ−ａとの間で確立されているベアラに接続する(ベアラの切換を行う：Ｓ１２２)。【０１１１】
そして、ＣＡＢＳ１は、ＭＳＣ１からの“ALERT”を復号化及び再暗号化し、端末ＵＥ−ａが送信した“SETUP”に対する“ALERT”として端末ＵＥ−ａに送信する(Ｓ１２３)。【０１１２】
その後、端末ＵＥ−ｂのユーザが呼び出しに応答すると、メッセージ“CONNECT”が端末ＵＥ−ｂから送信される(Ｓ１２４，Ｓ１２５，Ｓ１２６，Ｓ１２７)。但し、ＣＡＢＳ１は、Ｓ１２７において、ＭＳＣ１からの“CONNECT”を復号化及び再暗号化して端末ＵＥ−ａに送る。【０１１３】
そして、ＭＳＣ２が“CONNECT”に対する“CONNECT ACK”を端末ＵＥ−ｂに送信し(Ｓ１２８)、端末ＵＥ−ａが“CONNECT”に対する“CONNECT ACK”をＭＳＣ１に送信する(Ｓ１２９，Ｓ１３０)。また、ＣＡＢＳ１は、Ｓ１３０において、端末ＵＥ−ａからの“CONNECT ACK”を復号化及び再暗号化してＭＳＣ１に送る。これによって、端末ＵＥ−ａと端末ＵＥ−ｂとの間が通話中(During Communication)となる(Ｓ１３１)。【０１１４】
上記した第２のケースにおいて、端末ＵＥ−ａとＣＡＢＳ１との間に確立されるデータ伝送路が第１のデータ伝送路に相当し、ＣＡＢＳ１と端末ＵＥ−ｂ間に確立されるデータ伝送路が第２のデータ伝送路に相当する。【０１１５】
以上説明したように、図５に示すネットワークシステムは、第２のケースにおいて、ＣＡＢＳ１−ＣＡＢＳ２間のデータ伝送路を確立できない場合に、携帯電話ネットワーク及びＩＰネットワークを経由する代わりのデータ伝送路を確立する手段(確立手段)を備えた携帯電話端末間のデータ伝送路確立システムとして機能する。該確立手段は、ＣＡＢＳ１によって実現されている。【０１１６】
〈第２の態様〉
次に、本発明の第２の態様として、第１の態様で述べたような呼制御サーバを利用することなく、ＣＡＢＳ間をＩＳＰネットワークを介して直接的に接続する方式について説明する。【０１１７】
呼制御サーバがＩＳＰネットワーク内に存在しない場合、或いは呼制御サーバを使用しない場合には、ＣＡＢＳ内に相手先の情報を持つように構成することで通信が可能である。【０１１８】
《第３のケース》
図８は、第２の態様として、呼制御サーバを利用することなく、ＩＳＰネットワークを介してＣＡＢＳ間で直接的な接続を行う形態〈第３のケース〉を示す図であり、図９は、第２の態様における呼接続(シグナリング)を示すシーケンス図である。第３のケースは、第１の態様における第１のケースに相当する。【０１１９】
第２の態様では、呼制御サーバ(CA Server)を利用しない。このため、図９に示すように、ＣＡＢＳ１とＣＡＢＳ２との間でメッセージのやりとりが直接行われる点で、図５に示した第１の態様の第１のケースにおけるシーケンスと異なっている。【０１２０】
ＣＡＢＳ間で直接的なやりとりをするために、各ＣＡＢＳ１,２には、相手のＩＰアドレス，ＣＡＢＳ自身に接続可能な端末の電話番号等の端末の識別情報が少なくとも登録されている。【０１２１】
これによって、例えば、図８に示すように、端末ＵＥ−ａがＣＡＢＳ１を用いて発呼を行う場合には、ＣＡＢＳ１でその相手先情報をチェックする。これによって、ＣＡＢＳ２経由で端末ＵＥ−ｂへの着信が可能であることを判断することができる。そして、ＣＡＢＳ１は、判断結果に基づいて、ＣＡＢＳ２経由で端末ＵＥ−ｂへ直接発信要求を送ることができる。【０１２２】
図９に示すシーケンス(Ｓ２０１〜Ｓ２２４)は、図５に示す第１の態様と次の様に異なっている。ＣＡＢＳ１は、発呼要求を契機として呼の前処理(Ｓ２０１)を行った後、端末ＵＥ−ａからのSETUP信号の受信を契機として、上述したような相手先情報のチェックを行う。【０１２３】
即ち、ＣＡＢＳ１は、“SETUP”に含まれる端末ＵＥ−ｂの情報を元に、ＣＡＢＳ１に予め登録されている相手先情報を参照し、端末ＵＥ−ｂがＣＡＢＳ２の配下の端末として登録されているかどうか(端末ＵＥ−ｂの識別情報に対応するＣＡＢＳ２のＩＰアドレスが登録されているか)を判断する。【０１２４】
ここでは、ＣＡＢＳ１は、端末ＵＥ−ｂの識別情報に対応するＣＡＢＳ２のＩＰアドレスを読み出すことができる。そして、ＣＡＢＳ１は、読み出したＣＡＢＳ２のＩＰアドレスを宛先としたSETUPメッセージを送信する(Ｓ２０３)。ＣＡＢＳ２は、着信要求たる“PAGE REQUEST”を端末ＵＥ−ｂへ送信する(Ｓ２０４)とともに、“SETUP”に対する“SETUP ACK”を送信する(Ｓ２０５)。【０１２５】
このように、呼制御サーバがないために、ＣＡＢＳ１とＣＡＢＳ２との間でメッセージのやりとりが行われる点を除き、動作は図５とほぼ同様である。但し、第２の態様では、呼制御サーバに対し、各ＣＡＢＳが自身をＩＰ電話端末のように見せかける必要がない。このため、第１の態様で説明したようなプロトコル変換機能は必須の構成要件ではない。【０１２６】
以上説明したように、図８に示すようなネットワークシステムは、第３のケースにおいて、無線基地局としてのＣＡＢＳ１と、ＣＡＢＳ１が発信端末たる端末ＵＥ−ａから受信する発信要求(SETUP)の着信先端末(端末ＵＥ−ｂ)がＣＡＢＳ１が接続されたＩＰネットワークと同一のＩＰネットワーク(ＩＳＰ１)に接続された異なる無線基地局(ＣＡＢＳ２)を利用して発信要求を受信できる場合に、ＣＡＢＳ１−ＣＡＢＳ２間でＩＳＰ１を通じたデータ伝送路を確立することを試みる試行手段とを備えた携帯電話端末間のデータ伝送路確立システムとして機能する。第３のケースでは、ＣＡＢＳ１が試行手段としての機能を実現する。【０１２７】
《第４のケース》
図１０は、第２の態様において、図８に示すようなネットワーク構成において、ＣＡＢＳ２の配下に端末ＵＥ−ｂが存在せず、一般のＢＴＳ２の配下に存在する場合〈第４のケース〉の説明図である。図１１は、第４のケースにおける動作を示すシーケンス図である。第４のケースは、第１の態様における第２のケースに相当する。【０１２８】
図１１に示すＳ２０１〜Ｓ２０７の動作は、第３のケースと同様である。しかし、図１０に示すように、着信先端末としての端末ＵＥ−ｂは、ＣＡＢＳ２の配下に存在していない。このため、ＣＡＢＳ２では、“PAGE REQUEST”(Ｓ２０４)の送信を契機に起動されるタイマがタイムアウトになる(Ｓ３０１)。この場合、ＣＡＢＳ２は、ＣＡＢＳ１に対してタイムアウトメッセージを送信する(Ｓ３０２)。【０１２９】
ＣＡＢＳ１は、タイムアウトメッセージを受信すると、ＣＡＢＳ２の配下に端末ＵＥ−ｂが所在しないと判断し、第２のケースにおけるＣＡＢＳ１と同様に、端末ＵＥ−ａの代わりに呼接続処理(シグナリング)を代行する。【０１３０】
図１１に示すように、ＣＡＢＳ１がＣＡＢＳ２の配下に端末ＵＥ−ｂが存在しないと判断した場合の動作は、図７に示した第２のケースと同様である(図１１；Ｓ１０９〜Ｓ１３１)。このため、説明は省略する。【０１３１】
以上説明した第２の態様によれば、第３のケースで示したように、呼制御サーバを利用しない場合でも、ＣＡＢＳ間で携帯電話ネットワークを経由しない呼接続(データ伝送路確立)を行い、端末間でデータ送受信を行うことができる。【０１３２】
また、第４のケースで示した様に、相手先のＣＡＢＳの配下に相手先端末が存在しない場合でも、発信端末と着信先端末との間で通話を行わせることができる。【０１３３】
上記した第３のケースにおいて、端末ＵＥ−ａとＣＡＢＳ１との間に確立されるデータ伝送路が第１のデータ伝送路に相当し、ＣＡＢＳ１と端末ＵＥ−ｂ間に確立されるデータ伝送路が第２のデータ伝送路に相当する。【０１３４】
以上説明したように、図８に示すネットワークシステムは、第４のケースにおいて、ＣＡＢＳ１−ＣＡＢＳ２間のデータ伝送路を確立できない場合に、携帯電話ネットワーク及びＩＰネットワークを経由する代わりのデータ伝送路を確立する手段(確立手段)を備えた携帯電話端末間のデータ伝送路確立システムとして機能する。該確立手段は、ＣＡＢＳ１によって実現されている。【０１３５】
〈第３の態様〉
次に、本発明の第３の態様について説明する。第１及び第２の態様では、呼制御サーバ或いはＣＡＢＳに相手先(着信先)情報(ＣＡＢＳのＩＰアドレス及び相手先端末の識別情報)が登録されている必要がある。【０１３６】
しかしながら、発信時に、この発信に対する相手先情報が呼制御サーバやＣＡＢＳに登録されていない場合が考えられる。この場合には、図７や図１１で示した着信先でのタイムアウトを待たずに（そもそも着信先が不明なので、着信処理ができない）、呼制御サーバや発信元のＣＡＢＳで着信不可と判断して、元の携帯電話ネットワークを使用した発信に切り替える。【０１３７】
第３の態様に係るシーケンスを図１２及び図１３に示す。図１２は、第１の態様において、呼制御サーバに発信要求に対応する相手先情報が登録されていない場合を示すシーケンス図である。【０１３８】
図１２に示すように、呼制御サーバは、ＣＡＢＳ１からのSETUPメッセージ(Ｓ０３)を受け取った場合に、このSETUPに含まれる相手先の端末ＵＥ−ｂの識別情報から着信先のＣＡＢＳを割り出す。【０１３９】
このとき、呼制御サーバは、着信先のＣＡＢＳが登録されていないと判断する場合(着信先を割り出すことができない場合：Ｓ４０１)には、着信先が存在しないことを示す不存在メッセージ(図１２では、“Don‘t Exist”)をＣＡＢＳ１に返信する(Ｓ４０２)。【０１４０】
ＣＡＢＳ１は、不存在メッセージの受信を契機に、第２のケース(図７)で説明したＳ１０９〜Ｓ１１３Ａと同様の動作が行われる。但し、第２のケース(図７)と異なり、ＣＡＢＳ１は、呼制御サーバからの“SETUP ACK”の受信を契機に、端末ＵＥ−ａに対して“CALL PROCEEDING”を送信する機会がない。【０１４１】
このため、ＣＡＢＳ１は、ＭＳＣ１から“CALL PROCEEDING”を受信することを契機に、端末ＵＥ−ａに対して“CALL PROCEEDING”を送信する(Ｓ４１１)。これを契機に、端末ＵＥ−ａとＭＳＣ１との間で、ＣＡＢＳ１及びＲＮＳ１を介して、データ伝送用の無線ベアラが確立される(Ｓ４１２)。このように、無線ベアラを端末ＵＥ−ａとＣＡＢＳ１との間で確立するタイミングが異なっている。【０１４２】
その後における、通話中に至るまでの動作は、第２のケース(図７)とほぼ同様である。なお、ＣＡＢＳ１は、ＣＡＢＳ１自身を通過するメッセージやデータに対して復号化及び再暗号化を行う点は、第２のケースと同様である。【０１４３】
図１３は、第３の態様として、第２の態様(ＩＳＰネットワーク内の呼制御サーバを利用しない場合)において、発信側のＣＡＢＳに発信要求に対応する相手先情報が登録されていない場合の動作例を示すシーケンス図である。【０１４４】
図１３において、ＣＡＢＳ１は、第４のケース(図１１)と同様に、端末ＵＥ−ａと前処理を行い(Ｓ２０１)、端末ＵＥ−ｂへの発信要求としてのSETUP信号を受け取る(Ｓ２０２)。【０１４５】
このとき、ＣＡＢＳ１は、端末ＵＥ−ｂに対する相手先情報としてＣＡＢＳ２が登録されていない(着信不可(相手先未登録))と判断する場合には(Ｓ４２１)、携帯電話ネットワークを用いて端末間のデータ伝送用のベアラを確立するための手順を行う。この手順は、図１２に示したＳ１０９以降の手順と同様であるため、説明を省略する。【０１４６】
〈第４の態様〉
第１〜第３の態様に係る説明では、呼制御サーバ(CA Server)やＣＡＢＳ内へ、端末の着信先を登録するデータとしてＣＡＢＳの情報(ＣＡＢＳのＩＰアドレス)を登録している。第１〜第３の説明では、着信先端末と着信側ＣＡＢＳとの対応関係は１対１で説明した。但し、この対応関係を１対Ｎ(Ｎは自然数)にすることが可能である。【０１４７】
即ち、或る端末に対する着信側ＣＡＢＳとして、複数のＣＡＢＳを登録することができる。この場合、呼制御サーバ又は発信側のＣＡＢＳは登録された全てのＣＡＢＳに着信要求を送信し、着信要求に応答したＣＡＢＳと通信を行う。【０１４８】
また、着信要求を送信した全てのＣＡＢＳから応答がない場合には、呼制御サーバ又は発信側のＣＡＢＳは携帯電話ネットワークへの切り換えを行い、発信を行うこともできる。【０１４９】
このように、或る端末が配下に所在する可能性のある全てのＣＡＢＳを登録することにより、端末のユーザへの利便性をより高めることができる。【０１５０】
〈本発明の効果〉
本発明によれば、現状の端末および携帯電話ネットワークを構成する各装置の構成を変更することなく（ＣＡＢＳを除く）、ＣＡＢＳ間で直接的に(携帯電話ネットワークを経由することなく)ベアラ(データ伝送路)を確保することができる。【０１５１】
これによって、ＩＳＰネットワーク内のトラフィック、携帯電話ネットワーク内のトラフィックを減少させることができる。従って、呼の接続数を増やすことができる。【０１５２】
また、ＩＳＰ主体のトラフィックは、ＩＳＰへの受益の可能性を増やし、ＩＳＰを利用することによる設備の縮小がもたらすコストダウンは、携帯電話キャリヤの利益を押し上げ、ユーザにその利益が還元され易くなる。従って、携帯電話キャリヤ、ＩＳＰ、及びユーザの三者に利益をもたらすことになる。【０１５３】
〔本発明の実施例〕
以下、本発明の実施例について説明する。本発明の実施例として、第３世代の携帯電話ネットワーク（以下「３ＧＮＷ」）における、具体的なシーケンスを例示する。なお、ＩＳＰ（ＩＰネットワーク）内のプロトコルは、例として、ＩＰ電話で最もよく採用されているＳＩＰプロトコルが適用されている場合を仮定する。【０１５４】
〈第１実施例〉
第１実施例として、第１の態様における第１のケースに対応する実施例について説明する。図１４は、図４に示すようなネットワーク構成において、端末ＵＥ−ａがＣＡＢＳ１の配下にあり、端末ＵＥ−ｂがＣＡＢＳ２の配下にある場合におけるシーケンスを示す。【０１５５】
即ち、図１４は、ＩＳＰネットワーク内の呼制御サーバ(CA Server)を介して、ＣＡＢＳ１−ＣＡＢＳ２間で直接的な通信(データ伝送路の確立)が可能な場合を示す。【０１５６】
最初に、各ＣＡＢＳ１及びＣＡＢＳ２は、ＣＡＢＳ自身を使用可能な端末を呼制御サーバに登録する(登録手順)。登録手順によって、呼制御サーバ内に、相手先情報として利用される情報が登録される。相手先情報として登録すべき情報は、ＣＡＢＳのＩＰアドレス，このＣＡＢＳを使用可能な端末の識別情報(例えば電話番号)，その他の必要な情報を含む。登録すべき情報の内容は例えば呼制御サーバ側で決定される。【０１５７】
登録手順の具体的な手順は次の通りである。図１４には、例として、ＣＡＢＳ１による登録手順が示されている。ＣＡＢＳ１は、ＣＡＢＳ１及びＣＡＢＳ１を利用可能な端末を登録する場合には、ＳＩＰメッセージによる登録要求(図１４ではメッセージ“REGISTER”)を呼制御サーバに送信する(Ｓ５０１)。【０１５８】
呼制御サーバは、ＣＡＢＳ１からの“REGISTER(ＳＩＰメッセージ)”に対し、一度その情報キーを“401  unauthorized”メッセージで送って、登録すべき情報の送信を促す(Ｓ５０２)。【０１５９】
ＣＡＢＳ１は、“401  unauthorized”に応じて、REGISTERメッセージに登録すべき情報を載せて再送信する(Ｓ５０３)。呼制御サーバは、“REGISTER”から登録すべき情報を抽出し、呼制御サーバ内の所定の登録位置に登録する。例えば、呼制御サーバは、登録表内に登録すべき情報を登録する。【０１６０】
呼制御サーバは、登録を完了すると、ＣＡＢＳ１に対してメッセージ“200 OK”を送信する(Ｓ５０４)。このようにして、登録手順が完了する。これによって、ＣＡＢＳ１を使用可能な端末ＵＥ−ａが呼制御サーバに登録される。【０１６１】
上述した端末登録手順(Ｓ５０１〜Ｓ５０４)は、ＣＡＢＳ２−呼制御サーバ間においても行われる(Ｓ５０５)。これによって、ＣＡＢＳ２は、ＣＡＢＳ２を使用可能な端末として、端末ＵＥ−ｂを呼制御サーバに登録する。【０１６２】
上述したＳ５０１〜Ｓ５０４(Ｓ５０５)のような登録手順は、ＣＡＢＳを最初にＩＰネットワークに接続した場合において、１回だけ行われる。【０１６３】
端末ＵＥ−ａがＣＡＢＳ１の配下に所在し、発信を行うと、呼前処理(CALL PREPROCESS)が行われる(Ｓ５０６)。具体的には、制御用の無線リンクが端末ＵＥ−ａとＣＡＢＳ１との間に設定され、認証手続き(Authentication Procedure)と、暗号化のためのキーを確定させるためのやりとり(Security Procedure)とが行われる。【０１６４】
このような前処理は、端末ＵＥ−ａから見て既存の携帯電話の発信処理前に行われる前処理と変わらない。但し、本来的には、このような前処理は、ＣＡＢＳ１が通常の基地局(ＢＴＳ)であると仮定した場合には、端末ＵＥ−ａとＣＡＢＳ１の上位装置であるＲＮＳやＭＳＣとの間で行われる。【０１６５】
Ｓ５０６では、ＣＡＢＳ１は、端末ＵＥ端末ＵＥ−ａからの前処理のための信号を終端し、ＲＮＳ／ＭＳＣの代わりに前処理を端末ＵＥ−ａとの間で行う。このように、ＣＡＢＳ１は、端末との間で前処理を行う機能を有し、携帯電話ネットワークで、端末ＵＥ−ａのネットワーク認証や暗号化キーの確定処理が行われるのを回避する。【０１６６】
これにより、携帯電話ネットワークで、呼確立(シグナリング)のための制御トラフィックが発生することが回避される。上記したＣＡＢＳ１による前処理は、ＲＮＳやＭＳＣが持つ前処理に係る機能をＣＡＢＳに搭載することにより実現可能である。【０１６７】
なお、図１４に示す例では、呼制御サーバに対して認証要求を送らない(呼制御サーバがネットワーク認証に関わらない)例が示されている。【０１６８】
前処理が終わると、端末ＵＥ−ａは、相手先電話番号(端末ＵＥ−ｂの識別情報)が含まれた発信要求である“SETUP”をＣＡＢＳ１に送信する(Ｓ５０７)。【０１６９】
ＣＡＢＳ１は、端末ＵＥ−ａからの“SETUP”を受信すると、この“SETUP”を、ＳＩＰの発信要求メッセージであるINVITEメッセージに変換し(Ｓ５０８)、呼制御サーバに送信する(Ｓ５０９)。【０１７０】
呼制御サーバは、ＣＡＢＳ１からのINVITEメッセージを分析し、発信元と着信先が登録されているかどうかをチェックする(Ｓ５１０)。具体的には、例えば、呼制御サーバは、INVITEメッセージの送信元アドレスから発信側ＣＡＢＳ(ＣＡＢＳ１)のＩＰアドレスを特定する。また、INVITEメッセージに含まれる発信端末の電話番号から発信端末を特定する。これらのＩＰアドレス及び電話番号を含む相手先情報のエントリが登録表に登録されているか否かを判定することによって、呼制御サーバは、発信側のＣＡＢＳ＋端末が登録されているか否かを判定する。【０１７１】
一方、呼制御サーバは、INVITEメッセージに含まれる着信先端末の電話番号をキーとして、対応するＣＡＢＳのＩＰアドレスを含む相手先情報のエントリを登録表から検索する。これによって、着信側のＣＡＢＳ＋端末が登録されているかを判断することができる。【０１７２】
ここでは、上述した登録手順(Ｓ５０１〜Ｓ５０４、Ｓ５０５)によって、発信側及び着信側の対応する情報が登録されている。従って、呼制御サーバは、発信要求の発信元及び着信先が登録されていると判断し、着信先端末(端末ＵＥ−ａ)の電話番号に対応するＣＡＢＳ２のＩＰアドレスを発信要求の着信先アドレスとして決定する。【０１７３】
そして、呼制御サーバは、処理中である旨の100 TryingメッセージをＣＡＢＳ１に応答する(Ｓ５１１)。また、呼制御サーバは、ＣＡＢＳ２のＩＰアドレス宛にINVITEメッセージを送って着信動作を開始する(Ｓ５１２)。【０１７４】
ＣＡＢＳ１は100 Tryingメッセージを受信すると、発信要求が受け付けられたことを認識し、発信要求が受け付けられたことをCALL PROCEEDINGメッセージで端末ＵＥ−ａに通知する(Ｓ５１３)。【０１７５】
そして、ＣＡＢＳ１と端末ＵＥ−ａとの間の無線ベアラの確立手順が実行される。即ち、ＣＡＢＳ１は、RADIO BEARER SETUPメッセージを送る(Ｓ５１４)。端末ＵＥ−ａはRADIO BEARER SETUPメッセージに対するRADIO BEARER SETUP COMPLETEメッセージを返す(Ｓ５１５)。これによって、端末ＵＥ−ａとＣＡＢＳ１との間の無線ベアラが確立する。この時、ＣＡＢＳ１内では、この無線ベアラの接続先がＣＡＢＳ１内のTone(トーン)生成部に設定される(Ｓ５１６)。【０１７６】
一方、ＣＡＢＳ２では、INVITEメッセージ(Ｓ５１２)が受信されると、呼制御サーバに100 Tryingメッセージを返信する(Ｓ５１７)。さらに、ＣＡＢＳ２は、INVITEメッセージ内の着信先電話番号(ＵＥ−ｂの電話番号)を着信要求たるPaging Type 1メッセージに載せて送信する(Ｓ５１８)。【０１７７】
端末ＵＥ−ｂは、Paging Type 1メッセージを受け取ると、ＣＡＢＳ２との間で呼の前処理を開始する(Ｓ５１９)。この前処理は、端末ＵＥ−ａとＣＡＢＳ１との間で行われた前処理(Ｓ５０６)と同じ処理である。【０１７８】
前処理が終了すると、発信元情報(端末ＵＥ−ａの情報：INVITE(Ｓ５１２)に含まれている)が含まれたSETUPメッセージがＣＡＢＳ２から端末ＵＥ−ｂに送信される(Ｓ５２０)。【０１７９】
端末ＵＥ−ｂは、SETUPメッセージに、CALL CONFIRMメッセージで応答する(Ｓ５２１)。その後、無線ベアラを確立するために、RADIO BEARER SETUPメッセージがＣＡＢＳ２から端末ＵＥ−ｂに送られ(Ｓ５２２)、端末ＵＥ−ｂがRADIO BEARER SETUP COMPLETEメッセージで応答する(Ｓ５２３)。これによって、ＣＡＢＳ２と端末ＵＥ−ｂとの間に無線ベアラが確立する。【０１８０】
端末ＵＥ−ｂは、無線ベアラが確立するとALERTINGメッセージをＣＡＢＳ２に送る(Ｓ５２４)。これと同時に、端末ＵＥ−ｂは、端末の着信音を鳴らし(Ｓ５２５)、着信があったことを端末ＵＥ−ｂユーザに告げる。【０１８１】
ALERTINGメッセージは、ＣＡＢＳ２でＳＩＰの呼び出しメッセージに相当する180 Ringingメッセージに変換され(Ｓ５２６)、呼制御サーバに送信される(Ｓ５２７)。180 Ringingメッセージは、呼制御サーバを経由してＣＡＢＳ１に送られる(Ｓ５２８)。【０１８２】
ＣＡＢＳ１は、180 RingingメッセージをALERTINGメッセージに戻し(Ｓ５２９)、端末ＵＥ−ａに送る(Ｓ５３０)。このとき、ＣＡＢＳ１は、ＣＡＢＳ１内のTone生成部から呼び出し音（Ring Back Tone: RBT）を端末ＵＥ−ａの無線ベアラに送る(Ｓ５３１)。これでＵＥ−ａのスピーカからはＲＢＴが聞こえる。【０１８３】
端末ＵＥ−ｂがオフフックにより呼び出しに応答すると、CONNECTメッセージがＣＡＢＳ２に送信される(Ｓ５３２)。ＣＡＢＳ２は、CONNECTメッセージをＳＩＰの応答メッセージである200 OKメッセージに変換し(Ｓ５３３)、呼制御サーバに送る(Ｓ５３４)。呼制御サーバは、ＣＡＢＳ２からの200 OKメッセージをＣＡＢＳ１に転送する(Ｓ５３５)。【０１８４】
ＣＡＢＳ１は、200 OKメッセージをCONNECTメッセージに戻し(Ｓ５３６)、端末ＵＥ−ａに送る(Ｓ５３７)。これと同時に、ＣＡＢＳ１は、端末ＵＥ−ａとの無線ベアラを本来のＣＡＢＳ２側に接続する(Ｓ５３８)。これによって、端末ＵＥ−ａは、発信に対する応答を認識することができ、無線ベアラを用いて通信を開始することができる。【０１８５】
端末ＵＥ−ａは、CONNECTメッセージに対するCONNECT ACKメッセージをＣＡＢＳ１に送信する(Ｓ５３９)。ＣＡＢＳ１は、CONNECT ACKメッセージをＳＩＰに基づくACKメッセージに変換し(Ｓ５４０)、呼制御サーバへ送る(Ｓ５４１)。【０１８６】
呼制御サーバは、ACKメッセージをＣＡＢＳ２へ転送する(Ｓ５４２)。ＣＡＢＳ２は、ACKメッセージをCONNECT ACKメッセージに変換し(Ｓ５４３)、端末ＵＥ−ｂに送信する(Ｓ５４４)。これにより、端末ＵＥ−ｂは、通信可能な状態となる。【０１８７】
以上のようにして、200 OKメッセージがＣＡＢＳ１に到着した時点で、ＣＡＢＳ１とＣＡＢＳ２との間に実質的なベアラが確保されたことと認識され、音声データを送受信することが可能となる。【０１８８】
即ち、端末ＵＥ−ａとＣＡＢＳ１との間，及びＣＡＢＳ２と端末ＵＥ−ｂとの間では、無線ベアラによる音声データ通信路が形成され、ＣＡＢＳ１とＣＡＢＳ２との間には、ＶｏＩＰによるパス(実質的なデータ伝送路)が形成された状態となり、端末ＵＥ−ａと端末ＵＥ−ｂとの間で、双方向の音声通信を行うことが可能となる。【０１８９】
図１５は、図１４に示した通信中の状態からの切断シーケンスを示す。図１５において、端末ＵＥ−ａのユーザがオンフック（切断動作）を行うと、DISCONNECTメッセージが端末ＵＥ−ａからＣＡＢＳ１に送られる(Ｓ６０１)。【０１９０】
ＣＡＢＳ１は、DISCONNECTメッセージをＳＩＰプロトコルのBYEメッセージに変換し(Ｓ６０２)、呼制御サーバ(CA Server)へ送る(Ｓ６０３)。BYEメッセージは、呼制御サーバを経由してＣＡＢＳ２に送られる(Ｓ６０４)。【０１９１】
また、ＣＡＢＳ１は、端末ＵＥ−ａに対してRELEASEメッセージを送り(Ｓ６０５)、端末ＵＥ−ａがRELEASE COMPLETEメッセージをＣＡＢＳ１に返送する(Ｓ６０６)。これによって、切断処理が合意されたことが認識される。【０１９２】
BYEメッセージを受信したＣＡＢＳ２は、BYEメッセージをDISCONNECTメッセージに変換し(Ｓ６０７)、端末ＵＥ−ｂに送る(Ｓ６０８)。端末ＵＥ−ｂはRELEASEメッセージで応答する(Ｓ６０９)。【０１９３】
すると、ＣＡＢＳ２は、呼制御サーバ経由で切断への応答(BYEメッセージの応答メッセージ)である200 OKメッセージをＣＡＢＳ１に送る(Ｓ６１０，Ｓ６１１)。【０１９４】
200 OKメッセージをＣＡＢＳ１が受け取ることによって、ＣＡＢＳ１とＣＡＢＳ２との間の切断が完了する。一方、ＣＡＢＳ２は、端末ＵＥ−ｂにRELEASE COMPLETEメッセージを送って切断合意を通知する(Ｓ６１２)。【０１９５】
切断が合意された状態になったＣＡＢＳ１は、端末ＵＥ−ａとの無線制御リンクを切断するため、RRC Connection releaseメッセージを送って無線制御リンクの切断を要求する(Ｓ６１３)。【０１９６】
端末ＵＥ−ａは、RRC Connection releaseメッセージに対するRRC Connection release completeメッセージで応答し、両者間の無線制御リンクを解放する(Ｓ６１４)。【０１９７】
同様にＣＡＢＳ２と端末ＵＥ−ｂとの間で、RRC Connection releaseメッセージとRRC Connection release completeメッセージとの送受信が行われ(Ｓ６１５，Ｓ６１６)、両者間の無線制御リンクが解放される。【０１９８】
図１４及び図１５の説明で示したように、ＣＡＢＳ１−呼制御サーバ−ＣＡＢＳ２間におけるシーケンスは、ＳＩＰプロトコルによる発信／着信／切断制御となんら変わらない（但し、メッセージ中のパラメータは一部追加になっており、呼制御サーバが追加のパラメータを参照する処理が追加されている）。【０１９９】
また、各端末ＵＥ−ａ及びＵＥ−ｂから見た発信／着信／切断シーケンスは、現状の携帯電話ネットワークにおける発信／着信／切断動作と変わらない。【０２００】
呼制御サーバの改変は、上述した登録手順によってＣＡＢＳからの登録すべき情報を受け付けて所定位置に登録する処理、及び呼制御サーバがＣＡＢＳからのINVITEに含まれた着信先端末の電話番号を参照し、この電話番号に対応する相手先のＣＡＢＳが登録されているかを判断し、判断結果に応じたメッセージを所定の宛先に送信する処理を追加することで実現可能である。このような処理は、呼制御サーバに搭載されたソフトウェア(プログラム)の改変により実現することが可能である。また、このような処理を行う特別のハードウェアを搭載するようにしても良い。【０２０１】
〈第２実施例〉
第２実施例として、上述した第１の態様における第２のケースに対応する実施例について説明する。【０２０２】
図１６及び図１７は、図６に示すような、着信先の端末ＵＥ−ｂが、ＣＡＢＳ２ではなくＢＴＳ２の配下に所在する場合のシーケンスを示す。即ち、ＣＡＢＳ間の直接的な通信が不可能であり、且つ呼制御サーバが存在する場合のシーケンスである。【０２０３】
図１６のシーケンスにおいては、呼制御サーバ(CA Server)に対し、図１４に示した登録手順(Ｓ５０１〜Ｓ５０４，Ｓ５０５)によって、予めＣＡＢＳ１／２とその配下の端末ＵＥ−ａ／ｂが登録されているものと仮定する。【０２０４】
端末ＵＥ−ａが発信を要求するために前処理を開始し(Ｓ５０６)、SETUPメッセージを送信し(Ｓ５０７)、SETUPメッセージがＣＡＢＳ１でINVITEメッセージに変換され(Ｓ５０８)、呼制御サーバに送信され(Ｓ５０９)、ＣＡＢＳ２に送られる(Ｓ５１２)までの手順は、図１４と同じである。【０２０５】
ＣＡＢＳ２は、着信要求としてPaging Type 1メッセージを配下(ＣＡＢＳ２の通信範囲)に送信する(Ｓ５１８)。しかし、メッセージに応答すべき端末ＵＥ−ｂが存在しない。このため、ＣＡＢＳ２は、端末ＵＥ−ｂからの応答メッセージ“Paging Response”を受信することができない。【０２０６】
ＣＡＢＳ２は、Paging Type 1メッセージを送信すると、“Paging Response”の受信を受け付けるタイマを設定する(Ｓ７０１)。この場合、タイマがタイムアウトになる。ＣＡＢＳ２は、タイムアウトを検出すると、端末ＵＥ−ｂが配下に存在しないことを認識する。【０２０７】
この場合、ＣＡＢＳ２は、タイムアウトをＳＩＰに基づくメッセージ“408 Request Timeout”で呼制御サーバに通知する(Ｓ７０２)。呼制御サーバは、“408 Request Timeout”をそのままＣＡＢＳ１に送る(Ｓ７０３)。【０２０８】
ＣＡＢＳ１は、“408 Request Timeout”を受信すると、端末ＵＥ−ｂとの通信はＣＡＢＳ２を通じて行うことができないと判断する。そこで、ＣＡＢＳ１は、本来ＣＡＢＳ１が所属する携帯電話ネットワークに対して発信手続きを開始する。この手続きはＲＮＳ１／ＭＳＣ１側(図６)から見て、端末が普通に発信動作してくるように見せなければならない。【０２０９】
このため、ＣＡＢＳ１は、端末動作機能を持ち、これを使用して、端末ＵＥ−ａが先に行った前処理等の発信動作で得た情報を使用して、ＵＥ−ａの代行発信動作を行う。【０２１０】
即ち、ＣＡＢＳ１は、Ｓ５０６の前処理の実行により得た情報を用いて、ＲＮＳ１との間で呼の前処理を行い(Ｓ７０４)、ＭＳＣ１に対して発呼要求たる“SETUP”を送信する(Ｓ７０５)。【０２１１】
これにより、携帯電話ネットワークは、通常の発呼があったのと同じ動作を行い、ＢＴＳ２の配下に位置する端末ＵＥ−ｂにPaging Type 1メッセージを着信させる(Ｓ７０６〜７０８)。端末ＵＥ−ｂは、Paging Type 1メッセージに応答することができる。なお、Ｓ７０６において、“SETUP”は、ＭＳＣ間通信に適用されるＢ−ＩＳＵＰ(Broad-ISDN (Integrated Service Digital Network) User Part)メッセージの一つであるＩＡＭ(アドレス(Initial Address))メッセージでＭＳＣ１からＭＳＣ２へ転送される。【０２１２】
以降の手順(Ｓ７０９〜Ｓ７１９)は、携帯電話ネットワークの通常の発着信シーケンスと全く同じシーケンスである。これによって、ＣＡＢＳ１とＭＳＣ１との間に音声データ通信用のベアラが確立され(Ｓ７１２)、且つＭＳＣ１と端末ＵＥ−ｂとの間に音声データ通信用のベアラが確立される(Ｓ７１９)。【０２１３】
なお、ＭＳＣ２は、ＩＡＭメッセージを受信すると、その確認メッセージたるＩＡＡ(アドレス確認(IAM acknowledgement))メッセージをＭＳＣ１へ送信する(Ｓ７１０)。また、ＭＳＣ２は、ＭＳＣ１に対し、ＡＣＭ(アドレス完了(Address complete))メッセージを送信する(Ｓ７１１)。【０２１４】
その後、図１７に示すように、端末ＵＥ−ｂから呼び出し中を示すALERTINGメッセージが送信され、携帯電話ネットワークを経由して端末ＵＥ−ａに伝達される(Ｓ７２０〜Ｓ７２４)。【０２１５】
また、端末ＵＥ−ｂのユーザがオフフック動作を行うことを契機に、端末ＵＥ−ｂから端末ＵＥ−ｂの着信応答を示すCONNECTメッセージが送信され、携帯電話ネットワークを経由して端末ＵＥ−ａに伝達される(Ｓ７２５〜Ｓ７２９)。【０２１６】
そして、CONNECTメッセージを受信したＭＳＣ２が応答メッセージ“CONNECT ACK”を端末ＵＥ−ｂに通知し、且つ端末ＵＥ−ａが“CONNECT ACK”をＭＳＣ１に通知する。これによって、端末ＵＥ−ａと端末ＵＥ−ｂとの間が音声通信中の状態となる(Ｓ７３４)。【０２１７】
但し、Ｓ７２０〜Ｓ７２４のシーケンスにおいて、ＣＡＢＳ１はＲＮＳ１／ＭＳＣ１側から送信されてくるALERTING及びCONNECTのメッセージを、ＣＡＢＳ１自身が端末として動作したときに(Ｓ７０４の前処理で)取り決めた暗号で一旦復号する。そして、ＣＡＢＳ１は、端末ＵＥ−ａが発信動作を行ったときにＣＡＢＳ１がＲＮＳ１／ＭＳＣ１を代行して行った前処理(Ｓ５０６)で取り決めた暗号で、ALERTING及びCONNECTのメッセージを暗号化して端末ＵＥ−ａ側に送信する(Ｓ７２３，Ｓ７２８)。【０２１８】
逆に、ＣＡＢＳ１は、端末ＵＥ−ａからのCONNECT ACKメッセージに対し、端末ＵＥ−ａとの前処理(Ｓ５０６)で決めた暗号で復号し、ＣＡＢＳ１が端末として行った前処理(Ｓ７０４)で決定した暗号で暗号化する(Ｓ７３２)。【０２１９】
その後、端末ＵＥ−ａ側から通信を切断する場合には、従来と同様の切断手順と同様の手順が端末ＵＥ−ａ側及び端末ＵＥ−ｂ側で行われる(Ｓ７３５〜Ｓ７５５)。【０２２０】
具体的な手順は次の通りである。端末ＵＥ−ａのユーザが切断操作(オンフック)を行うと、端末ＵＥ−ａからDISCONNECTメッセージが送信される(Ｓ７３５)。ＣＡＢＳ１は、DISCONNECTメッセージに対する復号及び再暗号化を行った(Ｓ７３６)後、ＲＮＳ１を介してＭＳＣ１に送信する(Ｓ７３７)。【０２２１】
ＭＳＣ１は、DISCONNECTメッセージに対するRELEASEメッセージを端末ＵＥ−ａへ向けて送信する(Ｓ７３８)。RELEASEメッセージは、ＣＡＢＳ１にて復号及び再暗号化され(Ｓ７３９)、その後、端末ＵＥ−ａに送信される(Ｓ７４０)。【０２２２】
端末ＵＥ−ａは、RELEASEメッセージに対するRELEASE  COMPLETEメッセージを送信する(Ｓ７４１)。ＣＡＢＳ１は、RELEASE  COMPLETEメッセージを復号及び再暗号化し(Ｓ７４２)、ＭＳＣ１へ送る(Ｓ７４３)。このようにして、端末ＵＥ−ａ−ＭＳＣ１間のベアラが解放される。【０２２３】
ＭＳＣ１は、端末ＵＥ−ａ(ＣＡＢＳ１)からのRELEASEメッセージを受け取ると、DISC(切断)メッセージをＭＳＣ２へ送る(Ｓ７４４)。ＭＳＣ２は、DISCメッセージに対するREL(解放)メッセージをＭＳＣ１に返す(Ｓ７４５)。すると、ＭＳＣ１は、RLC(解放完了)メッセージをＭＳＣ２へ送信する(Ｓ７４６)。このようにしてＭＳＣ１とＭＳＣ２との間のベアラが解放される。【０２２４】
ＭＳＣ１は、端末ＵＥ−ａとＲＮＳ１との間の無線制御リンクの解放を指示するためのIU RELEASE COMMANDメッセージをＲＮＳ１へ送る(Ｓ７４７)。すると、ＲＮＳ１と端末ＵＥ−ａとの間で無線制御リンクの解放処理が行われる(Ｓ７４８)。解放処理が終了すると、ＲＮＳ１からＭＳＣ１へ解放処理の終了を示すIU RELEASE COMPRETEメッセージが通知される(Ｓ７４９)。【０２２５】
ところで、ＭＳＣ２は、ＭＳＣ１からのDISCメッセージに応じて、DISCONNECTメッセージを端末ＵＥ−ｂに送る(Ｓ７５０)。端末ＵＥ−ｂは、DISCONNECTメッセージに対するRELEASEメッセージをＭＳＣ２へ送る(Ｓ７５１)。ＭＳＣ２は、RELEASEメッセージに対するRELEASE COMPLETEメッセージを端末ＵＥ−ｂに送る(Ｓ７５２)。これによって、端末ＵＥ−ｂとＭＳＣ２との間のベアラが解放される。【０２２６】
ＭＳＣ２は、端末ＵＥ−ｂとＲＮＳ２との間の無線制御リンクの解放を指示するためのIU RELEASE COMMANDメッセージをＲＮＳ２へ送る(Ｓ７５３)。すると、ＲＮＳ２と端末ＵＥ−ｂとの間で無線制御リンクの解放処理が行われる(Ｓ７５４)。解放処理が終了すると、ＲＮＳ２からＭＳＣ２へ解放処理の終了を示すIU RELEASE COMPRETEメッセージが通知される(Ｓ７５５)。【０２２７】
以上の動作において、ＣＡＢＳ１は、端末ＵＥ−ａとのやりとりでは、端末ＲＮＳ１／ＭＳＣ１の動作に見えるように動作し、ＲＮＳ１／ＭＳＣ１側とのやりとりでは、端末ＵＥ−ａの動作に見えるように動作する。【０２２８】
このため、ＣＡＢＳ１は、呼接続シーケンスにおけるメッセージ，通信中の音声データ，切断シーケンスに係るメッセージに対し、復号化及び再暗号化処理を行う必要がある(Ｓ７２３，Ｓ７２８，Ｓ７３２，Ｓ７３４Ａ，Ｓ７３６，Ｓ７３９，Ｓ７４２)。【０２２９】
しかし、シーケンス自体は、従来の携帯電話ネットワークでのやりとりと変わらない。このようなＣＡＢＳ１を用いれば、端末や携帯電話ネットワーク自体になんら変更を加えることなく、図１６及び図１７に示す動作を行うことができる。【０２３０】
〈第３実施例〉
第３実施例として、上述した第２の態様における第３のケースに対応する実施例を説明する。図１８は、図８に示すようなネットワーク構成において、呼制御サーバ(CA Server)を利用しない場合のシーケンスを示す。【０２３１】
図１８に示すシーケンスと、第１実施例に係るシーケンス(図１４)とを比較すると、第１実施例のシーケンスとの相違点は、ＳＩＰメッセージをＣＡＢＳ１とＣＡＢＳ２との間で直接やりとりする点だけである(図１８；Ｓ５０９Ａ，Ｓ５１７Ａ，Ｓ５２７Ａ，Ｓ５３４Ａ，Ｓ５４１Ａ，Ｓ６０３Ａ，Ｓ６１０Ａを参照)。このため、詳細な説明は省略する。【０２３２】
但し、図１８に示すシーケンスを実現するため、ＣＡＢＳ１及びＣＡＢＳ２には、第１実施例と異なり、相手側のＩＰアドレスや端末の識別情報(電話番号)などの相手先情報が相互に予め登録されており、発信要求の受信を契機にＣＡＢＳ１が着信先を割り出す処理を行う(Ｓ５０８)ように構成されている。【０２３３】
〈第４実施例〉
第４実施例として、上述した第２の態様における第４のケースに対応する実施例を説明する。図１９は、呼制御サーバを利用しない場合において、着信先端末(端末ＵＥ−ｂ)が、ＣＡＢＳ２の配下に所在しない場合(図１０参照)におけるシーケンスを示している。【０２３４】
図１９に示すシーケンスと、第２実施例のシーケンス(図１６)とを対比すると、二つのシーケンスの差分は、ＳＩＰメッセージがＣＡＢＳ１とＣＡＢＳ２との間で直接やりとりされている点だけである(図１９；Ｓ５０９Ａ，Ｓ５１７Ａ，Ｓ７０２Ａ参照)。【０２３５】
図１９に示すように、ＣＡＢＳ１が408 Request Timeoutメッセージを受信すると、図１６及び図１７に示したＳ７０４以降のシーケンスが実行される。当該シーケンスの説明は省略する。【０２３６】
〈第５実施例〉
第５実施例として、上述した第３の態様に対応する実施例を説明する。第５実施例は、第１実施例における呼制御サーバや第２実施例におけるＣＡＢＳに相手先情報が登録されていないケースである。【０２３７】
図２０は、第１実施例と同様に、呼制御サーバが利用される場合において、呼制御サーバに相手先情報が登録されていない場合の動作を示すシーケンス図である。【０２３８】
図２０に示すように、前処理(Ｓ５０６)からINVITEメッセージの送信(Ｓ５０９)までの処理は、第１及び第２実施例(図１４、１６)と同様である。【０２３９】
呼制御サーバは、第２実施例と同様に、INVITEメッセージに基づいて相手先情報のチェックを行う(Ｓ５１０)。但し、ここでは、相手先情報として、着信先端末たる端末ＵＥ−ｂに対応するＣＡＢＳ２の情報が登録されていないものと仮定する。【０２４０】
この場合、呼制御サーバは、登録表から対応する相手先情報を飲み出すことができない。このため、呼制御サーバは、相手先が存在しないことを示す404 Not FoundメッセージをＣＡＢＳ１に送信する(Ｓ５１１Ａ)。【０２４１】
すると、ＣＡＢＳ１は、発信端末として振る舞い、携帯電話ネットワークを通じた呼接続シーケンス(シグナリング)を開始する。このシーケンスは、図１６に示したＳ７０４〜Ｓ７１９の手順とほぼ同様である。【０２４２】
但し、図２０に示すシーケンスでは、発信端末たる端末ＵＥ−ａにCALL PROCEEDINGメッセージを返信する機会がない(100 TryingメッセージをＣＡＢＳ１が受信しないため)。このため、ＣＡＢＳ１は、ＣＡＢＳ１自身に対して送信されたCALL PROCEEDINGメッセージ(Ｓ７０９)をＭＳＣ１から受信したことを契機として、端末ＵＥ−ａからのSETUP(Ｓ５０７)に対するCALL PROCEEDINGメッセージを生成し(Ｓ７０９Ａ)、端末ＵＥ−ａへ送信する(Ｓ７０９Ｂ)。その後、端末ＵＥ−ａとＭＳＣ１間で無線ベアラ確立手順が実行される(Ｓ７１２Ａ)。これらの点で、第２実施例と異なる。【０２４３】
図２１は、第３実施例と同様に、呼制御サーバが利用されない場合において、発信側のＣＡＢＳに相手先情報が登録されていない場合の動作を示すシーケンス図である。【０２４４】
図２１において、前処理(Ｓ５０６)及びSETUP送信(Ｓ５０７)は、第３及び第４実施例と同様である。ＣＡＢＳ１は、SETUPに基づいて、対応する相手先情報が登録されているかをチェックする(Ｓ５０８Ａ)。このとき、相手先情報として、着信先端末たる端末ＵＥ−ｂに対応するＣＡＢＳ２の情報が登録されていない。この場合、ＣＡＢＳ１は、発信端末として振る舞い、携帯電話ネットワークを通じた呼接続シーケンス(シグナリング)を開始する。Ｓ５０８Ａ以降の処理は、図２０に示した処理と同様であるので、説明を省略する。【０２４５】
〈第６実施例〉
第６実施例として、ＣＡＢＳの実施例について説明する。図２２は、ＣＡＢＳの機能ブロック図である。図２２に示す構成を持つＣＡＢＳは、上述した第１〜第５実施例に適用可能である。【０２４６】
図２２において、ＣＡＢＳは、送信アンテナ１１が接続された送信部(Tx)１２と受信アンテナ１３が接続された受信部(Rx)１４とからなる無線処理部(ＲＦ)１５と、制御チャネル(Cch)及びユーザチャネル(Uch)に対する多重／分離部(Cch/Uch-Mux/Dmux)１６と、取り込み／挿入部(Drop/Insert)１７と、ＩＰ多重／分離部(IP Mux/Dmux)１８と、制御部(controller: CNT(IMT/SIP Converter))１９(制御手段に相当)と、端末側エミュレータ(Terminal Side Emulator)２０と、ネットワーク側エミュレータ(Network Side Emulator)２１(代行手段に相当)と、端末側の暗号化処理部(Cipher Decipher)２２(第１暗号処理部に相当)と、ネットワーク側の暗号化処理部２３(第２暗号処理部に相当)と、ベアラセレクタ(Bsel)２４と、トーン生成部(Tone Generator)２５とを備えている。【０２４７】
端末(ＵＥ)からの無線信号は、ＲＦ１５で受信され、多重／分離部１６で制御チャネルとユーザチャネルとに分けられる。これらの信号は、取り込み／挿入部１７で、ＩＰネットワーク側の通信相手により、ＣＮＴ部１９，端末側エミュレータ２０，ネットワーク側エミュレータ２１のいずれに引き渡し(ドロップ(Drop))するかが決定される。【０２４８】
つまり、ＩＰネットワークを介して異なるＣＡＢＳとの通信が行われる場合には、信号はＣＮＴ部１９に送られる。このとき、携帯電話(例えばIMT-2000)用のプロトコルをＩＰ電話用プロトコル(例えばＳＩＰ)に変換する機能(ＩＭＴ／ＳＩＰコンバータ：プロトコル変換部)が働き、相手先のＣＡＢＳ又は呼制御サーバと通信する。ＩＰ電話用プロトコルは、ＣＮＴ部１９で終端される。【０２４９】
異なるＣＡＢＳと通信できず、携帯電話ネットワークと通信する場合には、端末がＣＡＢＳ自身をネットワーク側と認識し、ネットワーク側がＣＡＢＳを端末と認識するように動作する必要がある。【０２５０】
このため、ネットワーク側エミュレータ部２１と端末側エミュレータ部２０とがＣＡＢＳ１０に搭載され、これらで端末としての機能と、携帯電話ネットワークとしての機能をエミュレートできるように構成されている。即ち、ネットワーク側エミュレータ部２１は、ＲＮＳ／ＭＳＣの代わりに端末との間で前処理のためのやりとりを行う機能や、ＲＮＳ／ＭＳＣの代わりに端末へ送信すべき携帯電話用プロトコルに基づくメッセージを生成する機能を持つ。【０２５１】
一方、端末側エミュレータ２０は、ＣＡＢＳ１が発信端末として振る舞うための機能を持つ。端末側エミュレータ２０は、ＣＡＢＳ１が発信端末としてＲＮＳ／ＭＳＣとの間で前処理を行ったり、呼接続のためのメッセージのやりとりを行ったりする処理を行う。【０２５２】
以上のブロックで変換された制御信号は取り込み／挿入部１７で挿入された後、ＩＰ多重／分離部１８でＩＰ多重(ＩＰパケット化を含む)され必要な相手（ＣＡＢＳ，呼制御サーバ，ＲＮＳの何れか）に送られる。ネットワーク側からの信号はこの逆ルートで無線処理部１５に送られ、端末に送信される。【０２５３】
具体例について説明する。例えば、図１４に示すようなシーケンスにおいて、端末ＵＥ−ａからの“SETUP”(Ｓ５０７)は、受信アンテナ１３，受信部１４，多重／分離部１６を経て取り込み／挿入部１７に入力され、ＣＮＴ部１９で取り込まれる。すると、ＣＮＴ部１９は、“SETUP”を“INVITE”に変換し、取り込み／挿入部１７に渡す。“INVITE”は、ＩＰ多重／分離部１８から呼制御サーバへ送信される。端末ＵＥ−ａからの“CONNECT ACK”(Ｓ５３９)についても同様の動作が行われる。【０２５４】
また、呼制御サーバからの“100 Trying”(Ｓ５１１)は、ＩＰ多重／分離部１８を介して取り込み／挿入部１７に入力される。取り込み／挿入部１７は、“100 Trying”をＣＮＴ部１９に渡す。ＣＮＴ部１９は、“100 Trying”を端末ＵＥ−ａで認識可能な“CALL PROCEEDING”に変換し、取り込み／挿入部１７に渡す。“CALL PROCEEDING”は、多重／分離部１６，送信部１２，送信アンテナ１１を経て端末ＵＥ−ａに送信される。呼制御サーバからの“180 Ringing”(Ｓ５２８)や“200 OK”(Ｓ５２５)に対しても同様の動作が行われる。【０２５５】
また、図１６に示すシーケンスにおいて、呼制御サーバからの“408 Request Timeout”(Ｓ７０３)は、ＩＰ多重／分離部１８を経て取り込み／挿入部１７に入力される。“408 Request Timeout”は、ＣＮＴ部１９に渡される。ＣＮＴ部１９は、“408 Request Timeout”をプロトコル変換した後、ネットワーク側エミュレータ２１に渡す。【０２５６】
すると、ネットワーク側エミュレータ２１は、端末ＵＥ−ａとＣＡＢＳ１との間で行われた前処理(Ｓ５０６)に係る情報を端末側エミュレータ２０に渡す。端末側エミュレータ２０は、ネットワーク側エミュレータ２１からの情報に基づいて、ＲＮＳ１／ＭＳＣ１との間で前処理(Ｓ７０４)に係るメッセージのやりとり、“SETUP”の送信(Ｓ７０５)、無線ベアラの確立手順(Ｓ７１２)を行う。【０２５７】
また、図１７に示すシーケンスにおいて、ＭＳＣ１からの“ALERTING”(Ｓ７２２)は、取り込み／挿入部１７から端末側エミュレータ２０にドロップされる。端末側エミュレータ２０は、“ALERTING”を前処理(Ｓ７０４)で決定した暗号化キーで復号し、ネットワーク側エミュレータ２１に渡す。ネットワーク側エミュレータは、“ALERTING”を前処理(Ｓ５０６)で決定した暗号化キーで暗号化し、取り込み／挿入部１７に渡す(Ｓ７２３の復号／再暗号化処理)。【０２５８】
“ALERTING”は、取り込み／挿入部１７，多重／分離部１６，送信部１２，送信アンテナを経て端末ＵＥ−ａに送信される。ＭＳＣ１からの“CONNECT”(Ｓ７２７)，“RELEASE”(Ｓ７３８)についても“ALERTING”と同様の動作が行われる。【０２５９】
一方、図１７に示すシーケンスにおいて、端末ＵＥ−ａからの“CONNECT ACK”(Ｓ７３１)は、取り込み／挿入部１７からネットワーク側エミュレータ２１にドロップされる。すると、ネットワーク側エミュレータ２１は、“CONNECT ACK”を前処理(Ｓ５０６)で決定した暗号化キーで復号し、端末側エミュレータ２０に渡す。端末側エミュレータ２０は、“CONNECT ACK”を前処理(Ｓ７０４)にて決定した暗号化キーで暗号化し、取り込み／挿入部１７に渡す(Ｓ７３２の復号／再暗号化処理)。“CONNECT ACK”は、ＩＰ多重／分離部１９を経てＭＳＣ１へ送信される(Ｓ７３３)。端末ＵＥ−ａからの“DISCONNECT”(Ｓ７２７)，“RELEASE COMPLETE”(Ｓ７４３)についても“CONNECT ACK”と同様の動作が行われる。【０２６０】
上述したＣＡＢＳ１０内における動作は、図１８〜２１における動作においても、ほぼ同様である。但し、呼制御サーバを利用するか否かによって、ＣＡＢＳ１からのメッセージの宛先が呼制御サーバと異なるＣＡＢＳとの間で変更される。【０２６１】
図２２において、ユーザチャネルもまた、ネットワーク側の通信相手が呼制御サーバ又は異なるＣＡＢＳであるか、ＲＮＳ／ＭＳＣであるかによって２つのルートに分かれる。即ち、ＲＮＳ側へのユーザチャネルと、ＣＡＢＳ／呼制御サーバ側へのユーザチャネルとに分かれる。【０２６２】
通信相手がＣＡＢＳである場合には、端末からの暗号を解くだけでよく、暗号処理部２２のみを通るルート(第１のルート)でユーザデータがＣＡＢＳ１０内を転送される。【０２６３】
即ち、受信部１４でユーザデータが受信されると、そのユーザデータは多重／分離部１６を経て暗号処理部２２に入力される。暗号処理部２２は、ネットワーク側エミュレータ２１から得られる暗号化キーを用いてユーザデータを復号し、ベアラセレクタ２４へ出力する。このとき、ベアラセレクタは、ＣＮＴ部１９の制御により、暗号化処理部２２からのユーザデータを直接ＩＰ多重／分離部１８に渡す。そして、ＩＰ／多重分離部１８からＣＡＢＳへのユーザチャネルへユーザデータが送出される。【０２６４】
これに対し、通信相手がＲＮＳである場合には、端末からのユーザデータに施された暗号を解いた後、ＲＮＳ側の暗号で暗号化しなければならない。このため、ユーザデータはＣＡＢＳ内において、暗号処理部２２及び２３を通る第２のルートを通過する。このような、ユーザデータが暗号化処理部を通過する回数は、ＣＮＴ部１９で判断され、判断結果に基づいてベアラセレクタ２４が制御される。【０２６５】
即ち、受信部１４でユーザデータが受信されると、そのユーザデータは多重／分離部１６を経て暗号処理部２２に入力される。暗号処理部２２は、ネットワーク側エミュレータ２１から得られる暗号化キーを用いてユーザデータを復号し、ベアラセレクタ２４へ出力する。このとき、ベアラセレクタは、ＣＮＴ部１９の制御により、暗号化処理部２２からのユーザデータを暗号化処理部２３に渡す。暗号化処理部２３は、端末側エミュレータ２０からの暗号化キーでユーザデータを暗号化した後、ＩＰ多重／分離部１８に渡す。そして、ＩＰ／多重分離部１８からＲＮＳへのユーザチャネルへデータが送出される。【０２６６】
ＣＡＢＳやＲＮＳから受信されるユーザデータ(逆ルートのデータ)についても、同様の処理(ユーザデータの復号／暗号化やベアラセレクタ２４の制御)が行われる。このように、ベアラセレクタ２４は、切替部として機能し、ＣＮＴ部１９は、切替制御部として機能する。【０２６７】
また、ＩＰネットワーク通信時や、発呼切り替え時には、発信端末のユーザにこれらを通知する必要がある。これらをトーン（あるいはメッセージ）で聞かせるためのトーン生成部２５がＣＡＢＳ１０に設けられており、ＣＮＴ１９からの指示で切り替えを可能としている。【０２６８】
例えば、ＣＮＴ部１９は、図１４に示すシーケンスにおいて、“ALERTING”を端末ＵＥ−ａに送信すると(Ｓ５３０)、トーン生成部２５にＲＢＴの出力指示を与える。トーン生成部２５は、ＲＢＴを生成し、ベアラセレクタ２４に出力する。また、ＣＮＴ部１９は、ベアラセレクタ２４に対し、ＲＢＴを選択するための制御信号を与える。これによって、ＲＢＴがベアラセレクタ２４を通じて暗号化処理部２２に入力され、暗号化される。そして、ＲＢＴは送信部１２を経て端末ＵＥ−ａに送信される(Ｓ５３１)。【０２６９】
また、図１４に示すシーケンスにおいて、端末ＵＥ−ａに“CONNECT”を送信すると、ＣＮＴ部１９は、トーン生成部２５にＲＢＴの生成を停止する指示を与えるとともに、ベアラセレクタ２４に対し、ＩＰ多重／分離部からのユーザデータを選択するための制御信号を与える。これによって、相手先端末(端末ＵＥ−ｂ)からのユーザデータを端末ＵＥ−ａへ転送できる状態となる。【０２７０】
このように、トーン生成部２５は、呼び出し音生成部として機能し、ＣＮＴ部１９は、呼び出し音制御部として機能する。【０２７１】
また、例えば、図１６に示すシーケンスにおいて、ＣＡＢＳ１が“408 Request Timeout”を受信した場合には、発呼先が携帯電話ネットワーク(ＲＮＳ)に切り替えられる。この場合、発信端末のユーザの待ち時間が長くなる。これに鑑み、トーン生成部２５が発呼先が切り替えられたことを示す特別なトーンを生成するとともに、この特別なトーンを発信端末との間で既に確立されたユーザチャネルに接続し、ユーザに発呼先が切り替えられたことが通知されるように構成しても良い。特別なトーンの接続処理は、ＣＮＴ部１９によるベアラセレクタ２４の制御により実行することができる。【０２７２】
このように、トーン生成部２５は、通知音生成部として機能し、ＣＮＴ部１９は、通知音制御部として機能する。【０２７３】
本発明に係るＣＡＢＳは、基本的なＣＡＢＳの構成に図２２の太枠及び太字で示された機能がさらに搭載された装置であり、これらの機能を具備したＣＡＢＳを使用することで本発明の目的が達成される。各機能は、専用のハードウェアチップにより構成しても良く、或いは、所定のプログラムがプロセッサ(ＣＰＵ等)によって実行されることで実現されるように構成しても良い。【０２７４】
〈第７実施例〉
最後に、実施例に係る呼制御サーバ及びＣＡＢＳによる着信先の割り出し機能の実施例について説明する。【０２７５】
図２３は、第１,２及び５実施例に適用可能な呼制御装置(呼制御サーバ)の構成例を示すブロック図である。図２３において、呼制御装置３０は、ＣＡＢＳからのメッセージを受信するメッセージ受信部３１(受信部に相当)と、メッセージ受信部３１で受信されたメッセージを解析するメッセージ解析部３２と、メッセージ解析部３２の解析結果に従ってメッセージの転送先や応答メッセージの送信先を検索する相手先検索部３３(検索部、判断部、決定部に相当)と、解析結果に従ってメッセージの編集や応答メッセージの作成を行うメッセージ生成部３４と、メッセージ生成部３４からのメッセージを送信するメッセージ送信部３５(送信部に相当)と、相手先検索部３３によって参照・検索される登録表３６Ａを記憶した登録表記憶部３６(記憶部に相当)とを備えている。【０２７６】
メッセージ受信部３１は、ＣＡＢＳからの制御チャネルに接続されており、この制御チャネルを通じて送信されてくるメッセージ(例えばＳＩＰメッセージ)を受信する。【０２７７】
メッセージ解析部３２は、メッセージ受信部３１で受信されたメッセージの内容を解析し、メッセージと解析結果とをメッセージ生成部３４に渡す。【０２７８】
相手先検索部３３は、メッセージ解析部３２から、登録表３６Ａを参照するためのパラメータを受け取り、このパラメータを用いて対応するエントリを登録表３６Ａから検索し、検索されたエントリに含まれるパラメータをメッセージ生成部３４に渡す。【０２７９】
メッセージ生成部３４は、メッセージの解析結果と、相手先検索部３３の検索結果とに基づいて、メッセージの編集や、応答メッセージの作成を行い、メッセージ送信部３５に渡す。【０２８０】
メッセージ送信部３５は、メッセージ生成部３４から受け取ったメッセージを、ＣＡＢＳへの制御チャネルへ送出する。【０２８１】
登録表３６Ａには、呼制御装置１０が設けられたＩＳＰネットワークに接続されたＣＡＢＳに係る相手先情報のエントリが登録される。各エントリには、ＣＡＢＳのＩＰアドレスと、そのＣＡＢＳを利用可能な携帯電話端末の識別情報としての端末電話番号と、その他の必要な情報(既存の登録表に登録される情報等)が登録される。【０２８２】
図２３に示す例では、ＣＡＢＳ１のＩＰアドレスと、ＣＡＢＳ１を利用可能な携帯電話端末の識別情報としての端末ＵＥ−ａの電話番号とを含む相手先情報のエントリと、ＣＡＢＳ２のＩＰアドレスと、ＣＡＢＳ２を利用可能な携帯電話端末の識別情報としての端末ＵＥ−ｂの電話番号とを含む相手先のエントリとが示されている。【０２８３】
呼制御装置３０の具体的な動作例について説明する。例えば、図１４のシーケンスにおいて、ＣＡＢＳ１から送信される“INVITE”(端末ＵＥ−ａからの発信要求：Ｓ５０９)は、メッセージ受信部３１にて受信される。すると、Ｓ５１０の処理として、次の様な処理が行われる。【０２８４】
即ち、メッセージ解析部３２は、“INVITE”の送信元ＩＰアドレスと、“INVITE”に含まれる発信端末の電話番号及び着信先端末の電話番号を検索パラメータとして抽出し、相手先検索部３３に与える。【０２８５】
相手先検索部３３は、最初に、送信元ＩＰアドレス及び発信端末の電話番号を含むエントリを登録表から検索する。このとき、登録表３６から、対応するエントリとしてエントリ番号１のエントリ(ＣＡＢＳ１のＩＰアドレス及び端末ＵＥ−ａの電話番号を含むエントリ)が検索される。これによって、相手先検索部３３は、発信側のＣＡＢＳ＋端末が登録されていると判断する。【０２８６】
次に、相手先検索部３３は、着信先端末(端末ＵＥ−ｂ)の電話番号をキーとして、対応するエントリを登録表３６から検索する。このとき、端末ＵＥ−ｂの電話番号に対応するＣＡＢＳ２のＩＰアドレスを含むエントリ番号２のエントリが検索される。【０２８７】
すると、相手先検索部３３は、発信側及び着信側の双方が登録されていると判断し、ＣＡＢＳ間直接接続が可能と判断して、検索されたＣＡＢＳ２のＩＰアドレスを“INVITE”の宛先アドレスとして決定する。この着信先のＩＰアドレス(ＣＡＢＳ２のＩＰアドレス)を含む決定結果は、相手先検索部３３からメッセージ生成部３４に与えられる。【０２８８】
メッセージ生成部３４は、メッセージ解析部３２から“INVITE”を受け取るとともに、相手先検索部３３からＣＡＢＳ２のＩＰアドレスを含む決定結果を受け取る。すると、メッセージ生成部３４は、“INVITE”の送信元ＩＰアドレスに呼制御装置３０のＩＰアドレスを設定するとともに、宛先アドレスにＣＡＢＳ２のＩＰアドレスを設定し、メッセージ送信部３５に与える。メッセージ送信部３５は、ＣＡＢＳ２へ向けて“INVITE”を送信する(図１４；Ｓ５１２)。【０２８９】
これに対し、相手先検索部３３が、“INVITE”に含まれる着信先端末の電話番号に対応するエントリ(ここでは、エントリ番号２のエントリ)が登録表３６に登録されていない場合には、相手先検索部３３は、対応するエントリを検索できない。この場合、相手先検索部３３は、着信先が未登録である(即ち、ＣＡＢＳ間直接接続を実施できない)と判定する(図２０；Ｓ５１０参照)。【０２９０】
この場合には、相手先検索部３３は、着信先が未登録であるとの決定結果をメッセージ生成部３４に渡す。すると、メッセージ生成部３４は、メッセージ解析部３２からの“INVITE”に対する“404 Not Found”メッセージを生成し、メッセージ送信部３５に渡す。このとき、メッセージの宛先ＩＰアドレスは、“INVITE”の送信元ＩＰアドレスに基づいて、ＣＡＢＳ１に設定される。メッセージ送信部３５は、“404 Not Found”メッセージをＣＡＢＳ１に送信する(図２０；Ｓ５１１Ａ)。【０２９１】
図２４は、ＣＡＢＳ内に設けられる発信要求の相手先の割り出し機能の構成例を示す図である。図２４における構成(相手先の割出部４０)は、図２２に示すＣＮＴ部１９(制御手段に相当)に搭載することが可能である。【０２９２】
図２４において、相手先の割出部４０は、メッセージ受信部４１(受信部に相当)，メッセージ解析部４２，相手先検索部４３(検索部、判断部、決定部に相当)，メッセージ生成部４４，メッセージ送信部４５(送信部に相当)，及び登録表４６Ａを記憶した登録表記憶部４６(記憶部に相当)から構成することができる。各部の一般的な機能は、図２３に示した各部と同じ機能を持つ。【０２９３】
割出部４０の具体的な動作例は次の通りである。例えば、図１８に示すように、端末ＵＥ−ａからの“SETUP”がＣＮＴ部１９(図２２)
に入力されると、“SETUP”はメッセージ受信部４１を経てメッセージ解析部４２に入力される。【０２９４】
メッセージ解析部４２は、“SETUP”から着信先端末の識別情報(端末ＵＥ−ｂの電話番号)を抽出し、相手先検索部４３に与える。相手先検索部４３は、登録表４６から対応するエントリを検索する。ここでは、対応するエントリとしてＣＡＢＳ２のＩＰアドレスを含むエントリ番号１のエントリが検索される(ここでは、図２４において、エントリ番号１のエントリのみが登録されているものと仮定する)。これにより、相手先検索部４３は、“SETUP”の宛先をＣＡＢＳ２に決定し、この決定結果をメッセージ生成部３４に与える。【０２９５】
メッセージ生成部４４は、メッセージ解析部４２から“SETUP”を受け取ると、ＩＭＴ／ＳＩＰコンバータ(図２２)を用いて“SETUP”を“INVITE”に変換し、“INVITE”の宛先ＩＰアドレスにＣＡＢＳ２のＩＰアドレスを設定してメッセージ送信部４５に渡す。メッセージ送信部４５は、取り込み／挿入部１７(図２２)に“INVITE”を渡す。これによって、“INVITE”がＣＡＢＳ１からＣＡＢＳ２へ送信される(図１８；Ｓ５０９Ａ)。【０２９６】
ところで、相手先検索部４３が、着信先端末に対応する相手先情報を検索できない場合(ここでは、エントリ番号１のエントリが登録されていない場合)には、発信要求の相手先が未登録(ＣＡＢＳ間の直接接続は不可能)と判断し、発信要求の着信先を携帯電話ネットワークと決定し(図２１；Ｓ５０８Ａ)て、その決定結果をメッセージ生成部４４に伝える。【０２９７】
すると、メッセージ生成部４４は、ネットワーク側エミュレータ２１(図２２)に、端末側エミュレータ２０による発信を開始することを指示する発信開始指示(ＣＡＢＳ内の内部メッセージである)を生成し、メッセージ送信部４５に渡す。メッセージ送信部４５は、発信開始指示をネットワーク側エミュレータ２１に渡す。これによって、ネットワーク側エミュレータ２１から前処理に係る情報が端末側エミュレータ２０に渡され、端末側エミュレータが図２１のＳ７０４以降の処理を開始する。【０２９８】
なお、図２４に示す登録表４６のエントリ番号２のエントリは、端末ＵＥ−ｂがＣＡＢＳ２とＣＡＢＳ３(図示せず)との何れかを用いて携帯電話ネットワークに接続できる場合(端末とＣＡＢＳとの関係が１：Ｎ(Ｎは自然数)である場合)を想定したエントリである。【０２９９】
この場合には、ＣＡＢＳ２及びＣＡＢＳ３の夫々に宛てた“INVITE”がＣＡＢＳ１から送信される。また、このようなエントリを呼制御装置３０の登録表３６に登録し、呼制御装置３０からの“INVITE”がＣＡＢＳ２及びＣＡＢＳ３に送信されるようにしても良い。【０３００】
なお、図２２及び図２４に示す実施例では、ＣＡＢＳがＩＭＴ／ＳＩＰコンバータを有し、プロトコル変換を行う例について説明したが、ＣＡＢＳ間でメッセージが直接やりとりされる場合には、プロトコル変換を行う必要はない。このため、ＩＭＴ／ＳＩＰコンバータを省略することができる。【０３０１】
〈実施例の作用効果〉
以上説明した本発明の実施例によれば、端末間で同一のＩＳＰ(ＩＰ)ネットワークに接続された二つのＣＡＢＳを用いてデータ通信が行われる場合には、携帯電話ネットワークを経由することなく二つのＣＡＢＳ間が直接接続されたデータ伝送路が確立され、このデータ伝送路を用いて端末間のユーザデータの通信が行われる。これによって、携帯電話ネットワーク及びＩＳＰネットワークのトラフィック量の軽減を図ることができる。【０３０２】
また、発信側のＣＡＢＳにおいて、最初に、携帯電話ネットワーク側(ＲＮＳ)ではなく、呼制御サーバ又は着信側のＣＡＢＳに発信要求が送信される。このため、携帯電話ネットワークに制御用のトラフィックが発生しないので、携帯電話ネットワークの負荷を低減することができる。【０３０３】
また、ＩＳＰ網に設けられたＩＰ電話用の呼制御サーバを用いてＣＡＢＳ間の直接接続を行う場合には、各ＣＡＢＳにプロトコル変換部が設けられ、呼制御サーバが各ＣＡＢＳをＩＰ電話として取り扱うことが可能にされている。これによって、呼制御サーバに対する改変を最小に抑えることができるので、本発明の実施に要するコストの低減を図ることができる。【０３０４】
また、呼制御サーバを利用しない場合には、ＩＳＰネットワークの構成要素に対する改変は不要となる。また、本発明の実施に当たって、携帯電話ネットワーク及び携帯電話端末に対する改変は不要である。従って、本発明の実施するためのコストを抑えることができる。【０３０５】
また、呼制御サーバを利用するか否かに拘わらず、着信側のＣＡＢＳの配下に着信先端末が存在しない場合、或いは、着信側の相手先情報が登録されていない場合には、発信側のＣＡＢＳが端末として機能し、着信先端末との接続処理を行い、この接続処理によって確立したベアラを、発信側ＣＡＢＳと発信端末との間で確立されたベアラに接続する。これによって、発信端末が行った発信動作(前処理を含む)を無駄にすることなく、発信端末と着信先端末との接続を補償することができる。この場合においても、携帯電話ネットワーク及び携帯電話端末に対する改変は不要であるので、本発明の導入のコストを抑えることが可能である。
【図１】
0004584263.tif 000002
【図２】
0004584263.tif 000003
【図３】
0004584263.tif 000004
【図４】
0004584263.tif 000005
【図５】
0004584263.tif 000006
【図６】
0004584263.tif 000007
【図７】
0004584263.tif 000008
【図８】
0004584263.tif 000009
【図９】
0004584263.tif 000010
【図１０】
0004584263.tif 000011
【図１１】
0004584263.tif 000012
【図１２】
0004584263.tif 000013
【図１３】
0004584263.tif 000014
【図１４】
0004584263.tif 000015
【図１５】
0004584263.tif 000016
【図１６】
0004584263.tif 000017
【図１７】
0004584263.tif 000018
【図１８】
0004584263.tif 000019
【図１９】
0004584263.tif 000020
【図２０】
0004584263.tif 000021
【図２１】
0004584263.tif 000022
【図２２】
0004584263.tif 000023
【図２３】
0004584263.tif 000024
【図２４】
0004584263.tif 000025