携帯電話端末間のデータ伝送路確立システム
【課題】携帯電話網にＩＰ網を介して収容された基地局を用いて携帯電話ネットワーク及びＩＰ網の効率的な利用を図る。
【解決手段】携帯電話網にＩＰ網を介して収容された基地局を含むネットワークシステムにおいて、発信端末からの発信要求を発信側基地局から携帯電話網へ送信し、この発信要求が携帯電話網から着信側基地局を通じて着信先端末に着信される場合に、発信側基地局と着信側基地局との双方が同一のＩＰ網を介して携帯電話網に接続されているかを判定し、発信側基地局と着信側基地局との双方が同一のＩＰ網を介して携帯電話ネットワークに接続されている場合に、携帯電話網を経由することなく発信側基地局と着信側基地局とが同一のＩＰ網を介して直接接続された発信端末と着信先端末との間のデータ伝送路を確立する。
【解決手段】携帯電話網にＩＰ網を介して収容された基地局を含むネットワークシステムにおいて、発信端末からの発信要求を発信側基地局から携帯電話網へ送信し、この発信要求が携帯電話網から着信側基地局を通じて着信先端末に着信される場合に、発信側基地局と着信側基地局との双方が同一のＩＰ網を介して携帯電話網に接続されているかを判定し、発信側基地局と着信側基地局との双方が同一のＩＰ網を介して携帯電話ネットワークに接続されている場合に、携帯電話網を経由することなく発信側基地局と着信側基地局とが同一のＩＰ網を介して直接接続された発信端末と着信先端末との間のデータ伝送路を確立する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話ネットワークおよびＩＰ(Internet Protocol)ネットワークを使用
した通信方式に関する。
【背景技術】
【０００２】
携帯電話ネットワーク、例えば第３世代携帯電話ネットワーク(Third Generation mobile phone network)において、地図的に見てサービスエリア(基地局からの電波が届く範囲)ではあるが、電波が届きにくい地域(「不感地帯」と呼ぶ)が存在する。電波は基本的に
直進するため、建物の影、屋内、地下などでは、基地局からの無線電波が十分に届かない場合があるからである。
【０００３】
不感地帯の一つとして、例えば屋内があり、特に戸建て、或いは集合住宅における個人宅内がある。この個人宅内に小型基地局を配置し、個人宅内で携帯電話ネットワークからの電波を円滑に受信できることが望まれている。
【０００４】
本発明に関連する先行技術としては、例えば、以下の特許文献１及び２に記載された技術がある。
【特許文献１】特表２００４−５０７９４６号公報
【特許文献２】特表２００２−５３５８８８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、携帯電話ネットワークにＩＰネットワークを介して設置される基地局を用いて、効率的な携帯電話ネットワーク及びＩＰネットワークの利用を図ることができる技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、上記した目的を達成するために以下の構成を採用する。
【０００７】
即ち、本発明は、携帯電話ネットワークにＩＰネットワークを介して収容された基地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立システムであって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信させる場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定する判定手段と、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する確立手段とを含む。
【０００８】
本発明によれば、発信側基地局と着信側基地局との間が直接接続された端末間のデータ伝送路が確立される。これによって、携帯電話ネットワーク及びＩＰネットワークのトラフィックを減少させることができる。従って、ネットワーク負荷の軽減や、設備設置の負担の軽減を図ることができる。
【０００９】
本発明における「データ」は、テキスト、画像データの他、音声及び音声データを含むことができる。
【００１０】
好ましくは、本発明は、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されていない場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する。
【００１１】
また、好ましくは、本発明は、発信端末と着信先端末との一方がＩＰネットワークを介して前記携帯電話ネットワークに接続されていない基地局の配下に属する場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する。
【００１２】
これらのように、ＩＰネットワークが同一でない場合、及び発信端末と着信端末との少なくとも一方がＩＰネットワークを介して携帯電話ネットワークに接続されていない基地局の配下に存在する場合には、携帯電話ネットワークを経由するデータ伝送路が確立される。このように、基地局間が直接接続されたデータ伝送路を確立できない場合には、携帯電話ネットワークを経由したデータ伝送路を確立することで、端末間でのデータ通信を補償することができる。
【００１３】
本発明は、発信側基地局制御装置となる第１基地局制御装置と、着信側基地局制御装置となる第２基地局制御装置と、前記第１基地局制御装置と前記第２基地局制御装置とを接続する少なくとも１つの交換機とを有する携帯電話ネットワークを含むネットワークシステムであって、
前記第１基地局制御装置は、ＩＰネットワークを介して接続された発信側基地局から、発信端末としての携帯電話端末の発信要求を受信した場合に、この発信要求に前記発信側基地局が接続されるＩＰネットワークの識別情報と前記発信側基地局のＩＰアドレスとを付加し、
前記第２基地局制御装置は、前記少なくとも１つの交換機を介して前記発信要求を受け取り、この発信要求を自装置にＩＰネットワークを介して接続された着信側基地局を通じて着信先端末としての携帯電話端末に送信する場合に、前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致するかを判断し、
ＩＰネットワークの識別情報が一致する場合には、前記第２基地局制御装置が前記発信要求に含まれた前記発信側基地局のＩＰアドレスを前記着信側基地局に通知するとともに、前記着信側基地局のＩＰアドレスを前記発信側基地局に通知し、
前記第１及び第２基地局制御装置は、前記発信側基地局及び前記着信側基地局に指示を与えて、前記発信側基地局と前記着信側基地局とが前記携帯電話ネットワークを経由することなく同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立させる。
【００１４】
好ましくは、本発明における第１基地局制御装置は、発信要求に、前記識別情報と、前記ＩＰアドレスと、前記発信側基地局と前記着信側基地局との間で確立すべきデータ伝送路の識別情報とを付加する。
【００１５】
このようにすれば、発信側基地局と着信側基地局との間に複数の端末の組に対する複数のデータ伝送路が同時に確立される場合に、データ伝送路を識別してデータ伝送路の確立及びデータ伝送を行うことができる。
【００１６】
好ましくは、本発明における前記第１基地局制御装置，前記少なくとも１つの交換機は、前記発信要求の受信を契機に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間にデータ通信路を確立し、
前記少なくとも１つの交換機は、前記着信先端末の呼び出し中に、前記データ通信路を用いて呼び出し音を前記発信側基地局に送信し、
前記発信側基地局は、前記データ通信路を介して前記受信される前記呼び出し音を前記発信端末に送信する。
【００１７】
このようにすれば、携帯電話ネットワークからの呼び出し音を発信端末に接続することができる。
【００１８】
好ましくは、本発明における前記少なくとも１つの交換機及び前記第１基地局制御装置は、前記発信側基地局と前記着信側基地局との間に前記データ伝送路が確立され、且つ前記着信先端末が呼び出しに応答した場合に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間に確立されたデータ通信路を削除する。
【００１９】
このようにすれば、不要となったデータ通信路が削除(解放)されることで、ＩＰネットワーク及び携帯電話ネットワークのリソースの浪費を抑えることができる。
【００２０】
本発明は、携帯電話ネットワークにＩＰネットワークを介して接続される基地局であって、
発信端末としての携帯電話端末からの発信要求を受信する受信部と、
前記発信要求を前記ＩＰネットワークを介して携帯電話ネットワークへ送信する送信部と、
前記発信要求が前記ＩＰネットワークと同一のＩＰネットワークを介して前記携帯電話ネットワークに接続された異なる基地局を通じて着信先端末としての携帯電話端末に着信する場合に、前記異なる基地局のＩＰアドレスを前記携帯電話ネットワーク又は前記異なる基地局から受け取り、このＩＰアドレスを用いて、前記異なる基地局との間で、前記携帯電話ネットワークを経由することなく前記基地局自身と前記異なる基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立するデータ伝送路確立／切断部とを含む。
【００２１】
好ましくは、本発明の基地局と前記発信端末との間には、前記発信端末との間で通信されるデータを伝送するためのデータ通信路が確立され、
前記データ通信路を伝送されるデータは、前記発信端末と前記携帯電話ネットワークとの間で決定された暗号で暗号化され、
前記基地局は、
前記データ通信路からの暗号化されたデータを復号し、且つ前記データ通信路へ送信すべきデータを前記暗号で暗号化する暗号化処理部と、
データが前記暗号処理部を通過する第１ルートと、
データが前記暗号処理部を通過しない第２ルートと、
前記発信端末と前記着信先端末との間を前記携帯電話ネットワークを介して伝送されるデータを前記第２のルートに接続し、前記発信端末と前記着信先端末との間を前記データ伝送路を介して伝送されるデータを前記第１のルートに接続する接続部と、
前記データ伝送路の確立／切断に応じて、前記接続部の接続先のルートを制御する接続制御部とをさらに含む。
【００２２】
基地局及び端末は、相手側の基地局及び端末について適用される暗号を知らない。このため、暗号化されたデータをデータ伝送路を通じて相手方に送信しても、相手方でデータ
を復号することができない。上記した構成によれば、相手方に送信すべきデータは復号されて相手方に送られる。これによって、相手方が受信したデータを復号できないという問題を回避することができる。
【００２３】
また、本発明は、上記したシステムや基地局と同様の特徴を持つ方法の発明を実現することができる。
【発明の効果】
【００２４】
本発明によれば、携帯電話ネットワークにＩＰネットワークを介して設置される小型基地局を用いて、効率的な携帯電話ネットワーク及びＩＰネットワークの利用を図ることができる。
【発明を実施するための最良の形態】
【００２５】
以下、図面を参照して本発明を説明する。以下に説明する構成は例示であり、本発明はその構成に限定されない。
【００２６】
〔本発明の経緯〕
最初に、本発明の経緯について説明する。携帯電話ネットワークのサービスエリア内に存在する不感地帯として、例えば戸建てや集合住宅における個人宅(user home)内がある
。このような個人宅内に小型の無線基地局を設置し、携帯電話のユーザが個人宅内で携帯電話を使用できることが望まれている。このような宅内用の小型基地局装置は、一般に設置されている基地局と比較して以下の特徴を有することが好ましい。
【００２７】
(1) 宅内への設置を可能とすべく、小型で安価、かつサービスエリア（小型基地局からの電波の届く範囲）が狭小で、電波が低出力である（他の同様な基地局に対しできるだけ電波干渉を小さくする）。
【００２８】
(2) ネットワークを形成するために、基地局装置と基地局制御装置間に物理回線を敷設しなければならない。この物理回線において、現在個人宅に普及が進んでいるインターネット接続用のブロードバンド回線（例：ｘＤＳＬ(x Digital Subscriber Line)回線サー
ビス、或いはＣＡＴＶ(Cable TV)のインターネット接続サービス等）が持つＩＰパケット伝送路に相乗りする形式で、データを送受信する。
【００２９】
(3) 宅内用の小型基地局は個人宅のユーザが費用を払って設置することが想定される。
【００３０】
これらの点に鑑み、小型基地局の設置ユーザ（およびその関係者）のみに小型基地局に対する接続を許可するための認証機能(端末-小型基地局認証機能)が、基地局制御装置(ＲＮＳ：Radio Network Sub-system)と小型基地局との間に設けられる。
【００３１】
図１は、携帯電話ネットワークと小型基地局との接続構成例を示す図である。図１において、ＭＳＣ(Mobile services Switching Center:交換移動局)は、携帯電話ネットワー
クの交換処理装置(交換機)である。ＭＳＣは、相互に接続されるとともに、少なくとも１つのＲＮＳを収容する。ＲＮＳは、配下の基地局を制御する基地局制御装置である。ＲＮＳは、少なくとも１つのＢＴＳ(Base Transceiver station)を収容する。ＢＴＳは、端末(mobile station又はUE(user equipment))と無線通信を行うための基地局である。以上が、携帯電話ネットワークに含まれる構成要素である。
【００３２】
なお、図１には、携帯電話ネットワークの例として、３Ｇ(IMT-2000)のＵＭＴＳ(Universal Mobile Telecommunication System)の一部が示されている。ＵＭＴＳは、大略して
、コアネットワークと、コアネットワークへのアクセスネットワーク(UTRAN(Universal T
errestrial Radio Access Network))とからなる。ＵＴＲＡＮは無線部分を含む。図１に
示すＭＳＣは、コアネットワークに含まれる要素であり、ＲＮＳ及びＢＴＳはＵＴＲＡＮに含まれる要素である。
【００３３】
図１に示すＣＡＢＳ(Cubicle Area BTS)が宅内用の小型基地局に相当する。ＣＡＢＳは、通常、ユーザの住宅内に設置され、携帯電話ネットワークのＲＮＳとＩＳＰ(Internet Service Provider)ネットワーク(ＩＰネットワーク)経由で接続される。
【００３４】
図１に示す例では、ユーザの宅内には、ＩＳＰによって提供されるインターネット接続用のブロードバンド回線（例えばｘＤＳＬ）が導入されていることが想定されている。ＣＡＢＳは、ブロードバンド回線として利用される固定電話回線を収容するｘＤＳＬモデムのＩＰインタフェースに接続される。ｘＤＳＬモデムは、固定電話回線から分配されるｘＤＳＬ回線を介してＩＳＰネットワークに設けられたＤＳＬＡＭ(Digital Subscriber Line Access Multiplexer)に接続される。
【００３５】
一方、ＲＮＳは、ＩＷＵ(Inter-Working Unit)を介してＩＳＰネットワークの入口に設けられたエッジルータ(ＥＲ)に接続される。これによって、携帯電話ネットワークとＩＳＰネットワークとが接続されている。
【００３６】
ＩＷＵは、ＩＰレイヤと現在の携帯電話ネットワークの下位レイヤであるＡＴＭ(Asynchronous Transfer Mode)との変換装置である。ＲＮＳとＥＲとの間は、携帯電話ネットワークからの呼量に応じた数の回線で接続される。
【００３７】
このようにして、ＣＡＢＳは、物理的には固定電話回線で接続される。また、ＣＡＢＳはＲＮＳとＩＰインタフェースで接続される。このようにして、或るＩＳＰ網に接続されているＣＡＢＳの全ては、ＩＳＰ(ＩＰ)ネットワークを介して携帯電話ネットワークに収容される。
【００３８】
このように、ＣＡＢＳを宅内に既に敷設されているブロードバンド回線(ＩＳＰへの接
続環境)を用いて携帯電話ネットワークに接続すれば、携帯電話ネットワーク(ＲＮＳ)へ
の特別な回線を各住宅に敷設する必要がない。従って、ＣＡＢＳの導入に係るコストを削減することができる。
【００３９】
また、ＣＡＢＳは、特定の端末のみにＣＡＢＳ自身に対する接続を許可する機能を有している。具体的には、ＣＡＢＳが端末からの接続要求を受け取った場合に、ＲＮＳ／ＭＳＣでＣＡＢＳとの対認証処理が行われる。ＣＡＢＳは、認証処理の結果を元に、接続要求元の端末が接続可能端末であれば、端末からの接続要求を許可する。
【００４０】
図２は、図１に示したようなＣＡＢＳを収容する方式において、二つのＣＡＢＳが同じＩＳＰネットワークに収容されており、この二つのＣＡＢＳを通じて端末間で通信が行われる場合が示されている。
【００４１】
図２で明らかなように、端末間で受け渡しされるデータ（例えば音声呼であれば音声データ）は、ＣＡＢＳ１ａ−ＲＮＳ１−ＭＳＣ−ＲＮＳ２−ＣＡＢＳ２ａの経路(図２の矢
印参照)を通過する。この場合、端末間で送受信されるデータは、ＩＳＰネットワーク（
ＩＰネットワーク）を２度通過する。
【００４２】
もし、図３に示すように、端末間で受け渡しされるデータがＣＡＢＳ間の直接的な接続により、携帯電話ネットワークを経由することなく受け渡しできれば、図２に示す場合に比べてＩＳＰネットワーク内を通過するトラフィックは半分になる。また、ＣＡＢＳ間の
トラフィックは、ＩＳＰネットワークの上位に位置する携帯電話ネットワークを通らないので、設備的に有利であることは明らかである。
【００４３】
各ＣＡＢＳは、ＩＳＰ内でユニークに割り当てられるＩＰアドレスを有している。ＣＡＢＳ間でお互いのＩＰアドレスを知ることができれば、ＩＰパケット(例えば、音声デー
タが含まれたＩＰパケット)を直接的に(携帯電話ネットワークを経由することなく)やり
とりすることが可能である。
【００４４】
しかしながら、図３に示したようなＣＡＢＳ間を直接的に接続するサービスを実際に実現するには大きな問題がある。図４は課題を説明するためのネットワーク構成図である。図４において、端末ＵＥ−ａ（ＣＡＢＳ１と無線接続可能）が、端末ＵＥ−ｂ（ＣＡＢＳ２と無線接続可能）に対し発信する場合を考える。発呼の一連の手続きにより、制御信号は端末ＵＥ−ａからＣＡＢＳ１−ＲＮＳ−ＭＳＣへ伝達され、ＭＳＣで端末ＵＥ−ｂへの着信が決定される。
【００４５】
しかし、現在の携帯電話ネットワークでは、各端末の現在位置をＬＡ(Location Area)
と呼ばれる単位でしか把握していない。ＬＡは、複数のＲＮＳ／ＢＴＳ(ＣＡＢＳ含む)が所属する比較的広範囲なエリアで構成されている。ＭＳＣは、Ｈ／ＶＬＲ(Home/Visitor Location Register)と呼ばれる端末位置登録情報記録装置に接続されており、Ｈ／ＶＬＲには、各ＬＡ内に存在する端末の識別情報が登録されるように構成されている。
【００４６】
ＭＳＣは、端末ＵＥ−ａからの制御信号に応じて、Ｈ／ＶＬＲを参照し、着信端末が存在しているＬＡを読み出し、着信エリアＬＡを決定する。ここでは、端末ＵＥ−ｂはＬＡ１に存在しているので、ＭＳＣはＬＡ１に所属する全てのＲＮＳ（この場合ＲＮＳ１及び２）に着信要求メッセージを送る。
【００４７】
各ＲＮＳ１及び２は、着信要求メッセージをＲＮＳ自身の配下の全てのＢＴＳ(ＣＡＢ
Ｓも含まれる)に送信する。これにより、端末ＵＥ−ｂは、端末自身が接続しているＣＡ
ＢＳ２を介して着信要求メッセージを受け取ることができる。
【００４８】
端末ＵＥ−ｂは、ＣＡＢＳ２からの着信要求メッセージを受信し、着信要求メッセージに応答する(応答信号を送信する)ことで自分の存在位置を示す。この応答信号は、ＣＡＢＳ２→ＲＮＳ２→ＭＳＣと伝わり、さらにＲＮＳ１→ＣＡＢＳ１→端末ＵＥ−ａと送られ、端末ＵＥ−ｂからの応答があったことが示される。これによって通信経路が決定され、ＲＮＣ／ＭＳＣが端末間で音声データを伝送するための通信路(ベアラ)を確保する。
【００４９】
このとき、ＭＳＣはＲＮＳ１及びＲＮＳ２とのベアラを確保するだけで、どのＢＴＳ又はＣＡＢＳの配下に端末が存在しているかは知らない(知らなくても良い)ように構成されている。
【００５０】
したがって、ＭＳＣがベアラを確保する場合に、ＣＡＢＳ１及びＣＡＢＳ２との間に直接的な(携帯電話ネットワークを経由しない)ベアラを確保できるか(ＣＡＢＳ１及びＣＡ
ＢＳ２が同一のＩＳＰネットワークに所属しているか）を判断することはできなかった。また、ＭＳＣは、ＣＡＢＳ１及びＣＡＢＳ２の夫々に相手先のＣＡＢＳがどれであるかを指示することはできなかった。
【００５１】
まあ、各ＲＮＳ１及びＲＮＳ２は、現状では、ＲＮＳ自身の配下のＣＡＢＳの状態を知ることができるだけであり、相手先のＣＡＢＳを知る構成を持たない。このため、ＣＡＢＳ間を直接的に接続するベアラを確保するかどうかの判断を行うことはできなかった。
【００５２】
〔本発明の概要〕
本発明は、ＲＮＳ／ＭＳＣによって確保される端末間の音声データ用のベアラの代わりに、ＣＡＢＳ間をＩＰネットワークを介して直接的に結ぶベアラを確保する。
【００５３】
この確保は、ＣＡＢＳ１及び２の夫々が端末からの応答を受け取った時点で、相手のＣＡＢＳのＩＳＰ内でのＩＰアドレス(ＩＳＰネットワークはＩＰネットワークである)を知ることで、実現することができる。
【００５４】
しかし、現状の構成では、ＣＡＢＳのＩＰアドレスを知っているのは、その上位に位置するＲＮＳのみである。即ち、ＣＡＢＳ１のＩＰアドレスを知っているのはＲＮＳ１のみであり、ＣＡＢＳ２のＩＰアドレスを知っているのはＲＮＳ２のみである。このため、ＣＡＢＳの夫々が相手のＣＡＢＳのＩＰアドレスを知る手段が必要である。
【００５５】
また、各ＣＡＢＳ１及び２は、同じＩＳＰに接続されていることで直接的に両者間でデータ伝送を行うためのベアラを確保することができる。このため、ＣＡＢＳ１及びＣＡＢＳ２が同じＩＳＰに接続されているかどうかを判断する構成が必要である（言い換えると、ＲＮＳ１及び２、ＣＡＢＳ１及び２が同じＩＰネットワークに接続されているかの判断が必要である）。
【００５６】
さらに、上記した判断に基づいてＭＳＣ−ＲＮＳ−ＣＡＢＳ間のベアラを確保するかどうかの判断も必要である。以下に、本発明の目的を達成するための構成について説明する。
【００５７】
図５は、本発明を説明するためのネットワーク構成例を示す図であり、説明に必要な装置以外は省略している。ネットワークの構成例として、ＵＭＴＳが想定されている。
【００５８】
Ｈ／ＶＬＲは、端末の位置(端末が存在するＬＡ)が登録される端末位置登録記憶装置である。各ＭＳＣ１及び２は携帯電話ネットワークの交換処理装置(交換機)である。各ＲＮＳ１及び２は基地局制御装置である。各ＣＡＢＳ１,２及び３は宅内用の小型の無線基地
局装置(本発明の基地局)である。ＢＴＳ２は一般の基地局である。
【００５９】
図５において、携帯電話端末(以下、単に「端末」と表記する)ＵＥ−ａが発呼し、端末ＵＥ−ｂに着呼させる場合を考える。この場合における動作概要のシーケンスを図６に示す。図７は、図６のシーケンスに応じた状態遷移図である。
【００６０】
図６に示すシーケンスにおいては、端末ＵＥ−ａは、発信端末(calling terminal)に相当する。ＣＡＢＳ１は、発信側基地局(source base station)に相当する。ＲＮＳ１は、
第１基地局制御装置に相当する。ＭＳＣ１及びＭＳＣ２は、少なくとも一つの交換機に相当する。ＲＮＳ２は、第２基地局制御装置に相当する。ＣＡＢＳ２は、着信側基地局(destination base station)に相当する。端末ＵＥ−ｂは、着信先端末(called terminal)に
相当する。
【００６１】
図６において、端末ＵＥ−ａが発呼すると、まず呼の前処理(CALL PREPROCESS)が起動
する(Ｓ０１)。この前処理には、無線制御リンクの確立，端末ＵＥ−ａのネットワーク認証（端末ＵＥ−ａがこの携帯電話ネットワークのサービスを受けられるかを認証する），無線部分の暗号化のための暗号化キーのやりとりなどが含まれる。前処理は現状の処理となんら変わらない。
【００６２】
その後、端末ＵＥ−ａは、呼設定信号(発信要求)である“SETUP”をネットワークに送
る(Ｓ０２)。“SETUP”中には、着信を希望する相手先端末(端末ＵＥ−ｂ)の電話番号が
含まれている。“SETUP”を受信したＣＡＢＳ１は、“SETUP”を発信側ＲＮＳ(source-RNS:S-RNS)であるＲＮＳ１に送り、ＲＮＳ１は“SETUP”をＭＳＣ１に送る。
【００６３】
このとき、ＲＮＳ１は、例えば、“SETUP”がＩＰインタフェース(ＩＰネットワーク)
から受信されたことを認識することによって、“SETUP”がＣＡＢＳから送信されたこと
を認識(判断)することができる。さらに、ＲＮＳ１は、“SETUP”の送信元ＩＰアドレス
を検出することによって、“SETUP”の送信元のＣＡＢＳがＣＡＢＳ１であることを知る
ことができる。この場合、ＲＮＳ１は、ＭＳＣへ送信すべき“SETUP”に対し、ＣＡＢＳ
１のＩＰアドレスと、ＲＮＳ１とＣＡＢＳ１との間を中継しているＩＳＰ１の識別子(Ｉ
ＳＰ−ＩＤ：ＩＰネットワークの識別情報に相当)を付加する(Ｓ０２Ａ)。これは、本発
明の第１の特徴である。
【００６４】
これに対し、“SETUP”がＩＰネットワークを介して送信されたものでない場合(通常のＢＴＳから送信されたものである場合)には、上述したようなＩＰアドレス及びＩＳＰ−
ＩＤの付与は行われない。
【００６５】
最終的に“SETUP”を受信したＭＳＣ１は、相手先端末(着信先端末)の電話番号を元に
、Ｈ／ＶＬＲに相手先端末の所在を問い合わせる。ＭＳＣ１は、Ｈ／ＶＬＲからの応答結果より、ＭＳＣ２配下の位置登録エリア(ＬＡ)に相手先端末としての端末ＵＥ−ｂが存在すると分かった場合には、ＭＳＣ２に対してSETUPメッセージを送信する(Ｓ０３)。
【００６６】
ＭＳＣ２は、ＭＳＣ１からの“SETUP”を元に、まず着信要求メッセージ(PAGE REQUEST)を作成し、位置登録エリア内すべてのＲＮＳに送る(Ｓ０４)。これと同時に、ＭＳＣ２
は、ＭＳＣ１に“SETUP”に対する応答を返し(Ｓ０５)、着信動作に入ったことを通知す
る。
【００６７】
ＭＳＣ１は、応答をもらった時点で、端末ＵＥ−ａに対して音声データ伝送のためのベアラ(データ通信路)を構築するベアラ設定手順(BEARER SET)を行い(Ｓ０６)、通話に備える。
【００６８】
ここまでの手順(図６の〈１〉の破線より上の手順：Ｓ０１〜Ｓ０６)によるベアラ確立イメージは、図７(Ａ)に示すベアラ確立状態の遷移図のステップ〈１〉に示されている。即ち、ここまでに説明した手順Ｓ０１〜Ｓ０６で、端末ＵＥ−ａとＣＡＢＳ１との間，ＣＡＢＳ１とＲＮＳ１との間，及びＲＮＳ１とＭＳＣ１との間に、端末ＵＥ−ａと端末ＵＥ−ｂとの間の音声データ通信に使用されるベアラＢ１(第１のデータ通信路)，ベアラＢ２(第２のデータ通信路)，及びベアラＢ３が確立された状態となる。
【００６９】
図６に戻って、着信要求メッセージを受け取ったＲＮＳ(着信側ＲＮＳ(destination-RNS:D-RNS))は、ＲＮＳ自身の配下の全ての基地局に着信要求メッセージを送信する(Ｓ０７)。着信要求メッセージを受け取った基地局は、着信要求メッセージを無線信号に変換し
て送信する。したがって、図５に示す場合では、ＭＳＣ２から送信される着信要求メッセージは、ＲＮＳ１を介してＣＡＢＳ２，ＣＡＢＳ３及びＢＴＳ２から送信される。
【００７０】
着信要求メッセージには端末ＵＥ−ｂの端末番号が含まれており、この着信要求メッセージに応答できるのは着信先端末である端末ＵＥ−ｂのみである。ここでは、端末ＵＥ−ｂは、ＣＡＢＳ２の無線信号から着信要求メッセージを受け取る。
【００７１】
端末ＵＥ−ｂは、着信要求メッセージに対する応答メッセージを返した後(図示せず)、発信端末(端末ＵＥ−ａ)と同様の呼の前処理(CALL PREPROCESS)を行う(Ｓ０８)。
【００７２】
前処理が終了した後、ようやく、発信側のSETUPメッセージがＭＳＣ２から端末ＵＥ−
ｂに向けて送信される(Ｓ０９)。このとき、SETUPメッセージは、ＲＮＳ２及びＣＡＢＳ
２(着信側基地局に相当)を経て端末ＵＥ−ｂに届く。
【００７３】
このとき、ＲＮＳ２は、ＲＮＳ１で付加されたＩＳＰ−ＩＤをSETUPメッセージから取
得し、ＲＮＳ２とＣＡＢＳ２との間を中継しているＩＳＰの識別子(予めＲＮＳ２に登録
されている)と同じかどうかをチェックする(Ｓ０９Ａ)。これが、本発明の第２の特徴で
ある。
【００７４】
もし、ＩＳＰ−ＩＤ同士が同じでない場合（例えば、図５において端末ＵＥ−ｂがＣＡＢＳ３の配下に存在する場合には、ＲＮＳに予め登録されるＩＳＰ−ＩＤは“ＩＳＰ２”であるので、“SETUP”中のＩＳＰ−ＩＤ(“ＩＳＰ１”)と一致しない）には、ＲＮＳ２
にて、ＣＡＢＳ間の直接的な通信はできないと判断される。この場合、以降の手順において、従来と同様のシーケンスによる発着信処理が行われる。
【００７５】
また、SETUPメッセージにＩＳＰ−ＩＤのパラメータが含まれていない場合(例えば、図５において端末ＵＥ−ａがＢＴＳ２の配下にある場合には、端末ＵＥ−ａからのSETUPメ
ッセージにはＲＮＳ２にてＩＳＰ−ＩＤが付加されない)にも、ＲＮＳにて、ＣＡＢＳ間
の直接的な通信はできないと判断される。
【００７６】
図６のシーケンスでは、ＲＮＳ２とＣＡＢＳ２との間は、ＲＮＳ１とＣＡＢＳ１との間と同様に、ＩＳＰ１で中継されている(図５)。このため、ＲＮＳ２において、ＩＳＰ−ＩＤが同じであると判断され、ＣＡＢＳ間で直接的な通信が可能と判断される。
【００７７】
この場合、ＲＮＳ２は、“SETUP”に対する端末ＵＥ−ｂからの応答メッセージ“CALL CONFIRM”(Ｓ１０)を受信すると、本発明の第３の特徴である新しいベアラ確立手順(NEW BEARER SET)に入る(Ｓ１１)。
【００７８】
現状では、従来のベアラ確立手順として、ＲＮＳ２が“CALL CONFIRM”を受信することを契機に、ＭＳＣ２と端末ＵＥ−ｂ間のベアラが確立される。また、ＭＳＣ１−ＭＳＣ２間のベアラも別途確保される。
【００７９】
これに対し、新しいベアラ確立手順(Ｓ１１)では、ＭＳＣ２と端末ＵＥ−ｂ間のベアラ，及びＭＳＣ１−ＭＳＣ２間のベアラの確立手順は行われない。その代わりに、ＣＡＢＳ１とＣＡＢＳ２との間にＩＳＰ１のＩＰネットワークを使用したＣＡＢＳ１とＣＡＢＳ２とを直接的に接続するデータ伝送路(ＣＡＢＳ間直接コネクション)の確立手順と、端末ＵＥ−ｂとＣＡＢＳ２との間に無線リンクによるベアラを確立する手順とが行われる。
【００８０】
具体的には、新しいベアラ確立手順(Ｓ１１)において、ＲＮＳ２は、ＣＡＢＳ２のＩＰアドレスをＲＮＳ１に通知する。ＣＡＢＳ２のＩＰアドレスはＭＳＣ２及びＭＳＣ１を経てＲＮＳ１に到達する。また、ＲＮＳ２は、ＣＡＢＳ２に対し、“SETUP”メッセージか
ら予め取得しておいたＣＡＢＳ１のＩＰアドレスを通知する。このようにして、各ＣＡＢＳ１及び２は、相手先のＣＡＢＳのＩＰアドレスを知ることができる。
【００８１】
ＣＡＢＳ１及びＣＡＢＳ２は、通知された相手先のＣＡＢＳのＩＰアドレスを用いて、直接やりとりを行い、両者間にＣＡＢＳ間直接コネクション(ＣＡＢＳ間直接ベアラ)としてのＶｏＩＰ(Voice over IP)パスセッションを確立する。
【００８２】
新しいベアラ確立手順における１つの重要な点は、無線区間に確立されたセキュリティを確保するための暗号化処理である。呼の前処理において暗号化のためのキー受け渡しが
ＲＮＳ(ＭＳＣ)と端末との間で行われており、ＲＮＳ−端末間での通信は暗号化キーにより暗号化されている。このままではＣＡＢＳでこの暗号化を解くことができない。
【００８３】
このため、ＣＡＢＳ間通信が確定したこの時点で、ＩＰアドレスとともに暗号化キーをＣＡＢＳに渡し、ＣＡＢＳで暗号が解けるようにしておく。或いは、暗号化キーを相手側に送る代わりに、送信側のＣＡＢＳで暗号化データを復号し、復号されたデータを送信するように構成する。そして、ＣＡＢＳ２と端末ＵＥ−ｂとの間の無線リンクのベアラのみが、従来と同様の手順で確立される。なお、ＩＰネットワークのデータ伝送路上を伝送されるデータについては、ＩＰｓｅｃ等の既存のＩＰネットワークにおけるセキュリティ確保の技術を適用することができる。
【００８４】
ここまで(図６の〈２〉の破線より上：Ｓ０８〜Ｓ１１)のベアラ確立状態のイメージは、図７(Ｂ)におけるステップ〈２〉にて示されている。図７(Ｂ)では、図７(Ａ)で示すベアラＢ１,Ｂ２,Ｂ３に加えて、ＣＡＢＳ１ＣＡＢＳ２との間にデータ伝送路ＶＳが確立され、且つＣＡＢＳ２と端末ＵＥ−ｂとの間にベアラＢ４が夫々確立されている。
【００８５】
ここで注意すべき点は、ＣＡＢＳ１から２つのベアラＢ２，ＶＳが同時に確立されていることであり、この時点では、端末ＵＥ−ａとＣＡＢＳ１との間のベアラＢ１はＣＡＢＳ１でＭＳＣ１側のベアラＢ２に接続されている。
【００８６】
端末ＵＥ−ｂは無線ベアラＢ４を確立した後、端末自身の着信音を鳴らし始めるとともに、ALERT信号により呼び出し中であることを発信側に伝える(Ｓ１２)。ALERT信号は、ＭＳＣ２及びＭＳＣ１を経由し(Ｓ１３)、そのまま端末ＵＥ−ａに通知される(Ｓ１４)。
【００８７】
これと同時にＭＳＣ１から呼び出し音（通常ＲＢＴ[Ring Back Tone]）がベアラＢ３，Ｂ２及びＢ１を通じて端末ＵＥ−ａに送られる。これによって、端末ＵＥ−aのスピーカ(図示せず)からは、ＲＢＴによる呼び出し音が出力される。このように、ＭＳＣ１からの
ＲＢＴを端末ＵＥ−ａに伝達するために、ＣＡＢＳ１はＭＳＣ１側のベアラＢ２を選択している。
【００８８】
端末ＵＥ−ｂがユーザのオフフックにより呼び出しに応答すると、CONNECT信号が送信
される(Ｓ１５，Ｓ１６)。CONNECT信号がＭＳＣ１側に伝わった時点で、本発明の４つ目
の特徴であるベアラの切替／削除処理(BEARER CHANGE/DELETE)が行われる(Ｓ１８)。
【００８９】
ベアラの切替処理では、ＣＡＢＳ１のベアラ選択がＭＳＣ１側(ベアラＢ２)からＣＡＢＳ２側(データ伝送路ＶＳ)に切り替えられる。これと同時に、ＣＡＢＳ１とＲＮＳ１との間，及びＲＮＳ１とＭＳＣ１との間の各ベアラＢ２及びＢ３が削除される。
【００９０】
このような切替／削除処理(Ｓ１８)によって、ベアラは図７(Ｃ)に示すステップ〈３〉のイメージとなる。このようにして、ＣＡＢＳ間が直接接続された端末間のデータ伝送用のベアラ(端末ＵＥ−a−ＣＡＢＳ１−ＣＡＢＳ２−端末ＵＥ−ｂのベアラ)が完成する。
【００９１】
その後、端末ＵＥ−ｂからのCONNECT信号がＭＳＣ１から端末ＵＥ−ａに送られる(Ｓ１９)。そして、CONNECT信号に対する応答(CONNECT ACKの送信)を待って(Ｓ１７，Ｓ２０)
、通話が開始される(Ｓ２１)。
【００９２】
通信中状態(During Communication)からの切断処理は、現状とあまり変わらない形式で実現可能である。いずれか一方の端末のオンフックにより呼の切断要求があると、まず、切断メッセージのやりとり(DISCONNECT PROCESS)が行われる(Ｓ２２)。ここでのやりとりは現状と同様である。
【００９３】
続いて、ＭＳＣ１及びＭＳＣ２の夫々から配下の装置(ＲＮＳ)に対してベアラの解放指示(REL REQ(release request))が与えられる(Ｓ２３，Ｓ２４)。
【００９４】
このような解放指示に対し、現状(従来)では、端末ＵＥ−aとＣＡＢＳ１との間，ＣＡ
ＢＳ１とＲＮＳ１との間，ＲＮＳ１とＭＳＣ１との間のベアラ解放処理が行われる。端末ＵＥ−ｂ側も同様に、端末ＵＥ−ｂとＣＡＢＳ２との間，ＣＡＢＳ２とＲＮＳ２との間，ＲＮＳ２とＭＳＣ２との間のベアラ解放処理が行われる。
【００９５】
これに対し、本発明では（ここが第５の特徴である）、従来のベアラ解放処理の代わりに、端末ＵＥ−ａとＣＡＢＳ１との間(従来と同じ)、ＣＡＢＳ１とＣＡＢＳ２との間，ＣＡＢＳ２と端末ＵＥ−ｂとの間の各ベアラの解放処理(BEARER DELETE)が行われる(Ｓ２５，Ｓ２６，Ｓ２７)。これらのベアラ解放処理により端末間におけるすべてのベアラが解
放される。
【００９６】
その後は、不要となった制御信号用のリンクが解放される(Ｓ２８，Ｓ２９)。この解放処理は従来と同様である。制御信号用のリンクの解放終了後、それがＭＳＣ１及びＭＳＣ２に夫々通知される(Ｓ３０，Ｓ３１)。これで、端末間の通信開始から終了までのすべてのシーケンスが終了する。
【００９７】
ところで、基地局(ＣＡＢＳ)の配下には複数の端末が存在することが可能である。このため、図５〜図７に示した手順が複数の端末間で同時に行われることが想定される。ＣＡＢＳに割り当てられたＩＰアドレスだけでは、複数の端末に対する複数の通信ベアラを区別することはできない。
【００９８】
この問題については、上記に述べたＣＡＢＳのＩＰアドレスに加えて、セッションを区別するセッション番号を通知対象に導入することで、解決を図ることができる。この場合では、上記に述べた動作内容において、“ＩＰアドレス”の代わりに“ＩＰアドレス＋セッション番号”にすればよいだけである。
【００９９】
このようにすれば、複数の端末が１つのＣＡＢＳ配下に存在し、それぞれが異なる端末と通信する場合でも、上記と同様な方式により、ＣＡＢＳ間が直接接続されたベアラを用いて通信を行うことができる。
【０１００】
以上述べたように、本発明に係る５つの特徴を持つ、各装置、および方式を使用すれば、現状の端末を変更することなく、ＣＡＢＳ間に直接ベアラを確保することができる。
【０１０１】
これによって、ＩＳＰネットワーク内のトラフィック、携帯電話ネットワーク内のトラフィックが軽減されて、より多くの呼を接続することができるようになる。
【０１０２】
また、ＩＳＰ主体のトラフィックはＩＳＰへの受益の可能性を増やし、それによる設備の縮小がもたらすコストダウンは、携帯電話キャリヤの利益を押し上げ、ユーザにその利益が還元され易くなって、キャリヤ、ＩＳＰ、ユーザ三者に利益をもたらすことになる。
【０１０３】
〔本発明の実施例〕
以下、本発明の実施例について説明する。
【０１０４】
〈実施例におけるシーケンス〉
本発明の実施例として、第３世代の携帯電話ネットワーク（以下「３ＧＮＷ」と表記する）における、具体的なシーケンスを例示する。図８は、現状の３ＧＮＷにおける発着信
から通話中までのシーケンス図であり、図９は、本発明による発着信から通話中までのシーケンスを示す。
【０１０５】
図８及び図９のシーケンスにおけるネットワーク形態は、概要説明と一致させるべく、図５に示したネットワーク形態(トポロジ)となっている。
【０１０６】
３ＧＮＷにおける発呼動作は、図８の最初の部分(前処理：PREPROCESS)に示したとおりで、図９では１つの処理イメージになっている(Ｓ１０１参照)。本発明の概要で説明したとおり、前処理の内容は現状と変わらない。
【０１０７】
その後、発信端末たる端末ＵＥ−ａからCC(呼制御)プロトコル(3G(IMT-2000)標準のプ
ロトコル)によるCC:SETUP信号が携帯電話ネットワーク(ＭＳＣ１)へ向けて送信される(Ｓ１０２)。このとき、ＲＮＳ１において、ＣＡＢＳ１のＩＰアドレス及びＩＳＰ１のＩＳ
Ｐ−ＩＤがSETUP信号に付加される(図９；[Ａ])。
【０１０８】
ＭＳＣ１は、“SETUP”に含まれる端末ＵＥ−ｂの電話番号に基づいて、Ｈ／ＶＬＲか
ら端末ＵＥ−ｂの存在するＬＡを割り出し、このＬＡを管理するＭＳＣ(ここではＭＳＣ
２)に“SETUP”を渡す。
【０１０９】
ここでは、ＲＮＳに“SETUP”は、ＭＳＣ１からＭＳＣ２へ、ＩＳＵＰ(ISDN (Integrated Service Digital Network) User Part)のメッセージ(ＩＡＭ：アドレス(Initial Address))を用いて送信される(Ｓ１０３)。また、ＭＳＣ１は、“SETUP”に対する“CALL PROCEEDING”を端末ＵＥ−ａに返す(Ｓ１０４)。
【０１１０】
なお、ＭＳＣ２は、ＩＡＭメッセージを受信すると、その確認メッセージたるＩＡＡ(
アドレス確認(IAM acknowledgement))メッセージをＭＳＣ１へ送信する(Ｓ１０５)。
【０１１１】
ＭＳＣ２は、“SETUP”を受信すると、これを元に着信要求たるPAGINGメッセージを作
成し、配下のＲＮＳ(ここではＲＮＳ２)に送る(Ｓ１０６)。また、ＭＳＣ２は、ＭＳＣ１に対し、ＡＣＭ(アドレス完了(Address complete))メッセージを送信する(Ｓ１０７)。
【０１１２】
ＲＮＳ２は、ＭＳＣ２からのPAGINGメッセージを元に、着信要求たるPAGING TYPE1メッセージを作成し、配下の全ての基地局に送信する(Ｓ１０８)。これによって、PAGING TYPE1メッセージは、ＣＡＢＳ２を通じて着信端末たる端末ＵＥ−ｂに到着する。
【０１１３】
端末ＵＥ−ｂがPAGING TYPE1メッセージに応答すると、図８に示した手順と同様の前処理が行われ、無線リンクが確立される(Ｓ１０９)。ＭＳＣ２は、前処理の終了後、“SETUP”を端末ＵＥ−ｂに向けて送信する(Ｓ１１０)。
【０１１４】
この“SETUP”メッセージは、ＲＮＳ２を通過する。このとき、ＲＮＳ２は、ＣＡＢＳ
１のＩＰアドレスとＩＳＰ−ＩＤとを“SETUP”から取得し、ＩＳＰ−ＩＤを用いてＣＡ
ＢＳ間ベアラを確立可能かどうかを判断する(図９；[Ｂ])。 ここでは、ＲＮＳ２に予め登録されているＩＳＰ−ＩＤと、“SETUP”から取得されるＩＳＰ−ＩＤが一致するので
、ＲＮＳ２は、ＣＡＢＳ間直接ベアラが確立可能(双方のＣＡＢＳがＩＳＰネットワーク(ＩＰネットワーク)に接続されている)と判断し、ＣＡＢＳ間ベアラの確立を決定する。
【０１１５】
端末が“SETUP”に対する“CALL CONFIRM”を応答すると、この“CALL CONFIRM”は、
ＭＳＣ２まで伝達される(Ｓ１１１)。すると、ＭＳＣ２は、ＭＳＣ２と端末ＵＥ−ｂとの間にベアラを確立するため、RAB ASSIGNMENT REQUEST(RANAP(Radio Access Network Application Protocol)プロトコル)をＲＮＳ２に送信する(Ｓ１１２)。
【０１１６】
ここで、ＲＮＳ２が、ＣＡＢＳ間ベアラの確立を決定している場合には、ＲＮＳ２は、ベアラ確立手続きを行うことなく、ＣＡＢＳ２に対し、RADIO LINK RECONFIGURATION PREPAREメッセージ(Ｓ１１３)で、ＣＡＢＳ１のＩＰアドレスを送るとともに、ＣＡＢＳ１からの直接的なＶｏＩＰセッション確立を待つことを指示する(図９；[Ｃ])。
【０１１７】
また、ＲＮＳ２は、ＭＳＣ２に対し、RAB INTER-CAB MODEメッセージ（RANAPプロトコ
ルにない新しいメッセージである。既存のメッセージのパラメータを変更して使用することも可能である）により、ＣＡＢＳ２のＩＰアドレス(ＲＮＳ２が予め知っている)を送るとともに、ＭＳＣ１側にＣＡＢＳ１とＣＡＢＳ２との間のセッション確立起動を促す(Ｓ
１１４)。ＭＳＣ２は、ＣＡＢＳ２のＩＰアドレス及びセッション確立起動指示は、CPG(Call Progress：呼経過)メッセージ(新規)により、ＭＳＣ１へ伝達される(Ｓ１１５)。
【０１１８】
ＣＡＢＳ２のＩＰアドレス及びセッション確立起動指示は、ＭＳＣ１からのRAB ASSIGNMENT REQUESTメッセージによってＲＮＳ１に伝えられ(Ｓ１１６)、さらにRADIO LINK RECONFIGURATION PREPAREメッセージによってＣＡＢＳ１に伝えられる(Ｓ１１７)。
【０１１９】
すると、ＣＡＢＳ１は、ＣＡＢＳ２のＩＰアドレスを使用してＶｏＩＰセッション（具体的にはＵＤＰ(User Datagram Protocol)でＲＴＰ(Real-time Transport Protocol)セッション）の確立を行う。即ち、ＣＡＢＳ１とＣＡＢＳ２との間で直接ＶｏＩＰセッションの確立手順が行われる。
【０１２０】
図９には、ＶｏＩＰセッション確立手順として、ＣＡＢＳ１からＣＡＢＳ２へのLINK ESTABLISH REQUEST(セッション確立要求)の送信(Ｓ１１８)と、ＣＡＢＳ２からＣＡＢＳ１へのLINK ESTABLISH ACK(セッション確立確認)の送信(Ｓ１１９)とが示されている。これでＣＡＢＳ１とＣＡＢＳ２との間のベアラが確保される。
【０１２１】
ＣＡＢＳ間のベアラが確保されると、各ＣＡＢＳ１及び２は、RADIO LINK RECONFIGURATION READYメッセージでベアラ確保を上位のＲＮＳ１又は２に通知する(Ｓ１２０，Ｓ１
２１)。
【０１２２】
ＲＮＳ１は、RADIO LINK RECONFIGURATION READYメッセージを受け取ると、RAB ASSIGNMENT REQUESTメッセージに対するRAB ASSIGNMENT RESPONSEメッセージをＭＳＣ１に返し
て準備完了を告げる(Ｓ１２２)。
【０１２３】
一方、ＲＮＳ２は、残った（もともと実施すべきである）端末ＵＥ−ｂとの無線ベアラ確立のためのRADIO BEARER SETUPメッセージを端末ＵＥ−ｂに送る(Ｓ１２３)。
【０１２４】
端末ＵＥ−ｂは、RADIO BEARER SETUPメッセージに応じて無線ベアラを確立し、RADIO BEARER SETUP COMPLETEメッセージで無線ベアラ確立完了を通知する(Ｓ１２４)。
【０１２５】
ＲＮＳ２は、RADIO BEARER SETUP COMPLETEメッセージを受け取ると、RAB ASSIGNMENT RESPONSEメッセージをＭＳＣ２に応答して準備完了を告げる(Ｓ１２５)。
【０１２６】
端末ＵＥ−ｂは、無線ベアラが確立すると、CC:ALERTINGメッセージを送る(Ｓ１２６)
。これと同時に、端末ＵＥ−ｂは、端末ＵＥ−ｂ自身の着信音を起動させ、ユーザに着信を告げる。
【０１２７】
ALERTINGメッセージは、ＭＳＣ２，ＭＳＣ１を通じて(Ｓ１２７：CPGメッセージ(既存)により伝達される)、端末ＵＥ−ａまで届けられる(Ｓ１２８)。また、ＭＳＣ１は、ALERT
INGメッセージの送信を契機にＲＢＴを端末ＵＥ−ａに送る(図示せず)。端末ＵＥ−ａの
ユーザは、ＲＢＴを聞くことができる。
【０１２８】
その後、端末ＵＥ−ｂのユーザがオフフック（つまり応答）を行うと、CC:CONNECTメッセージが送られる(Ｓ１２９)。CONNECTメッセージは、ＭＳＣ２を介してＭＳＣ１に伝達
される(Ｓ１３０；ANM(Answer:応答)で伝達される)。すると、ベアラの切替／削除処理が起動される(図９；[Ｄ])。
【０１２９】
即ち、ＭＳＣ１は、ＲＮＳ１に対し、IU RELEASE COMMANDで、ＲＮＳ１−ＭＳＣ１間のベアラの削除を指示するとともに、ＲＮＳ１-ＣＡＢＳ１間のベアラの削除及びＣＡＢＳ
１−２間ベアラへの切り替え指示を行う(Ｓ１３１)。
【０１３０】
ＲＮＳ１は、ベアラの削除及び切替指示をRADIO LINK RECONFIGURATION PREPAREメッセージでＣＡＢＳ１に通知する(Ｓ１３２)。ＣＡＢＳ１は、RADIO LINK RECONFIGURATION PREPAREメッセージに従って、ＭＳＣ１側のベアラをＣＡＢＳ１−２間ベアラへ切り替える処理を実施する。その後、ＲＮＳ１との間のベアラを切断する(図９；[Ｅ])。
【０１３１】
その後、ＣＡＢＳ１は、RADIO LINK RECONFIGURATION READYメッセージでベアラの切替及び削除が完了したことをＲＮＳ１に通知する(Ｓ１３３)。すると、ＲＮＳ１は、ＲＮＳ１−ＭＳＣ１間のベアラを切断し、ＭＳＣ１にIU RELEASE COMPLETEメッセージでベアラ
の切り替えと切断の完了を通知する(Ｓ１３４)。
【０１３２】
以降は、CC:CONNECTメッセージがＭＳＣ１から端末ＵＥ−ａに向けて送信され(Ｓ１３
５)、呼接続が完了する。なお、“CONNECT”に対する“CONNECT ACK”がＭＳＣ１及び端
末ＵＥ−ｂに夫々返信される(Ｓ１３６，Ｓ１３７)。
【０１３３】
図９に示したシーケンスにおいて、Ｓ１１２〜Ｓ１２５の処理が、図６の概要に示した新たなベアラ設定(Ｓ１１)に相当する。また、Ｓ１３１〜Ｓ１３４の処理が、図６に示したベアラ変更／削除処理(Ｓ１８)に相当する。
【０１３４】
図９に示したメッセージは一例であり、特に新しいシーケンス部分に関してはパラメータ等により取り決めを行うことでどのメッセージでも使用可能である。この実施例はシーケンスの実行に使用されるメッセージのタイプを限定するものではない。また、ＣＡＢＳ１とＣＡＢＳ２との間のセッションの確立も一例を示したものであり、本発明におけるＣＡＢＳ間のベアラの確立は実施例に限定されない。
【０１３５】
なお、図９に示すシーケンスにおいて、ＲＮＳ２がＣＡＢＳ１のＩＰアドレスを用い、ＣＡＢＳ２のＩＰアドレスをＩＰネットワークを介して直接ＣＡＢＳ１に通知するように構成することができる。また、ＣＡＢＳ２がＲＮＳ２からＣＡＢＳ１のＩＰアドレスを受けとった場合に、これを用いてＣＡＢＳ２のＩＰアドレスを直接ＣＡＢＳ１に通知するように構成することもできる。
【０１３６】
図１０は、現状における３ＧＮＷの切断シーケンスを示す図であり、図１１は、本発明の実施例における３ＧＮＷの切断シーケンスを示す図である。
【０１３７】
図１１に示すように、例えば端末ＵＥ−ａのオンフックが行われると、端末ＵＥ−ａからCC:DISCONNECTメッセージがＭＳＣ１に送信される(Ｓ１４１)。ＭＳＣ１は、CC:RELEASEメッセージを端末ＵＥ−ａに送信する(Ｓ１４２)。端末ＵＥ−ａはCC:RELEASEメッセー
ジに対し、CC:RELEASE COMPLETEメッセージで応答する(Ｓ１４３)。
【０１３８】
また、ＭＳＣ１は、REL(Release：解放)メッセージをＭＳＣ２に送信する(Ｓ１４４)。ＭＳＣ２は、RLC(Release Complete)をＭＳＣ１に返す(Ｓ１４５)。 また、ＭＳＣ２は
、CC:DISCONNECTメッセージを端末ＵＥ−ｂに送信する(Ｓ１４６)。端末ＵＥ−ｂは、Ｍ
ＳＣ２にCC:RELEASEメッセージを返す(Ｓ１４７)。ＭＳＣ２は、CC:RELEASEメッセージに対し、CC:RELEASE COMPLETEメッセージで応答する(Ｓ１４８)。
【０１３９】
その後、ＭＳＣ１は、ＲＮＳ１に対し、IU RELEASE COMMANDメッセージでベアラの切断を指示する(Ｓ１４９)。これに応じて、ＲＮＳ１は、RRC Connectionの解放処理を行い、端末ＵＥ−ａとＣＡＢＳ１との間の無線リンクの切断を行う(Ｓ１５０)。
【０１４０】
同様に、ＭＳＣ２は、ＲＮＳ２に対し、IU RELEASE COMMANDメッセージでベアラの切断を指示する(Ｓ１５１)。これに応じて、ＲＮＳ２は、RRC Connectionの解放処理を行い、端末ＵＥ−ｂとＣＡＢＳ２との間の無線リンクの切断を行う(Ｓ１５２)。
【０１４１】
以上のようなＳ１４１〜Ｓ１５２の処理は、現状と同様の処理である(図１０参照)。しかし、図１１に示す実施例に係るシーケンスでは、RRC Connection Releaseの指示をＣＡＢＳ１及び２の夫々で確認し、ＣＡＢＳ１とＣＡＢＳ２との間のＶｏＩＰセッションを解放する(Ｓ１５３，Ｓ１５４)。ここが本発明の特徴に係る部分である。
【０１４２】
ＣＡＢＳ１−２間のベアラが解放されることによって、ベアラの解放は完了する。このため、各ＲＮＳ１及び２は、IU RELEASE COMPLETEメッセージで、ベアラの解放完了をＭ
ＳＣ１又はＭＳＣ２に夫々通知する(Ｓ１５５，Ｓ１５６)。
【０１４３】
その後、現行では(図１０)、ＣＡＢＳ−ＲＮＳ間，及びＲＮＳ−ＭＳＣ間の各ベアラ及び各制御リンクの切断処理が行われる。これに対し、本発明の実施例では、ＣＡＢＳ−ＲＮＳ間及びＲＮＳ−ＭＳＣ間の各ベアラは存在しない。このため、ＲＮＳ−ＭＳＣ間，ＲＮＳ−ＣＡＢＳ間の各制御リンクの切断処理のみが実行される(Ｓ１５７，Ｓ１５８，Ｓ
１５９，Ｓ１６０)。
【０１４４】
従って、図１０に示すように、現状では、ＣＡＢＳ−ＲＮＳ間についてAAL2 LINK ReleaseとSCCP Connection Releaseによる二つのリンクの解放処理が必要であり、ＣＡＢＳ−ＲＮＳ間について二つのIP LINK Releaseが必要である。これに対し、図１１に示す実施
例では、SCCP Connection Releaseによる解放処理と、一つのIP LINK Releaseで済む。
【０１４５】
なお、図１１に示したＳ１５０，Ｓ１５３及びＳ１５４の処理が、図６の概要に示したベアラ削除処理(Ｓ２５)に相当する。
【０１４６】
〈ＣＡＢＳの構成〉
図１２は、本発明を実施する場合のＣＡＢＳ１０(ＣＡＢＳの実施例)の機能ブロック図である。図１２において、ＣＡＢＳ１０は、無線インタフェース部(ＲＦ)１１と、ＲＦ１１に接続される多重／分離部(Cch/Uch-Mux/Dmux)１２と、多重／分離部１２と制御チャネル(Cch)を介して接続される取り込み／挿入部(Drop/Insert)１３と、多重／分離部１２とユーザチャネル(Uch)を介して接続されるベアラセレクタ(Bsel)１４とを備えている。
【０１４７】
さらに、ＣＡＢＳ１０は、ベアラセレクタ１４とユーザチャネルを介して接続されるとともに、取り込み／挿入部１３と制御チャネルを介して接続されるＩＰ多重／分離部(IP Mux/Dmux)１５と、ＩＰ多重／分離部１５とベアラセレクタとの間のユーザチャネル上に
配置される暗号処理部(Cipher Decipher)１６と、取り込み／挿入部１３と接続されると
ともに、ベアラセレクタ１４及びＩＰ多重／分離部１５を制御する制御部(ＣＮＴ部(セッション確立／切断部(Session est./disc.)を含む))１７とを備えている。
【０１４８】
ＲＦ１１は、送信アンテナが接続された送信部(Ｔｘ)と受信アンテナが接続された受信部(Ｒｘ)とを有している。端末との通信はＲＦ１１によって行われる。端末からのデータはＲＦ１１の受信部で受信され、多重／分離部１２に入力される。
【０１４９】
多重／分離部１２は、入力された制御用のデータを制御チャネルに振り分け、ユーザデータをユーザチャネルに振り分ける。制御用のデータは取り込み／挿入部１３に入力され、ユーザデータはベアラセレクタ１４に入力される。
【０１５０】
多重／分離部１２からの制御用データは、取り込み／挿入部１３を通過してＩＰ多重／分離部１５でＩＰパケット化される。そして、通常は、ＣＡＢＳ１０の上位装置であるＲＮＳに送信される。
【０１５１】
逆に、ＲＮＳからの制御データパケット(端末へ送るべき制御データ)はＩＰ多重／分離部１５で分離され、取り込み／挿入部１３を通過する。そして、多重／分離部１２からＲＦ１１の送信部に与えられ、端末側へ無線で送信される。
【０１５２】
これに対し、ＲＮＳ−ＣＡＢＳ間でやりとりされる制御データは、ＩＰ多重／分離部１２から取り込み／挿入部１３に与えられると、ＣＮＴ部１７に取り込み(ドロップ)され、ＣＮＴ部１７で終端処理される。
【０１５３】
ＣＮＴ部１７は、ＲＮＳへ送信すべき制御データを作成し、取り込み／挿入部１３に挿入される。この制御データは、ＩＰ多重／分離部１２から制御チャネルを通じてＲＮＳへ送信される。
【０１５４】
一方、端末からのユーザデータは、多重／分離部１２でユーザチャネルに振り分けられ、ベアラセレクタ１４に与えられる。
【０１５５】
ベアラセレクタ１４とＩＰ多重分離部との間には、ユーザデータが暗号処理部１６を通過しない第１ルートＸと、暗号処理部１６を通過する第２ルートＹとが設けられている。
【０１５６】
ユーザ用ベアラが携帯電話ネットワーク内を通る場合（ＲＮＳ−ＭＳＣ経由）では、ユーザデータはベアラセレクタ１４から第１ルートＸへ出力され、暗号化されることなくＩＰ多重／分離部１５に入力され、ＩＰパケット化されて、ＲＮＳへのユーザチャネルへ送出される。
【０１５７】
一方、ＲＮＳからのユーザデータは、ＩＰ多重／分離部１５で第１ルートＸに振り分けられる。そして、ベアラセレクタ１４，多重／分離部１２を経て、ＲＦ１１の送信部から無線で端末に送られる。
【０１５８】
これに対し、ＣＡＢＳ間通信が実施される場合には、端末からのユーザデータはユーザチャネル側に振り分けられた後、ベアラセレクタ１４に入力される。このとき、ベアラセレクタ１４は、ユーザデータを第２ルートＹへ出力する。
【０１５９】
これにより、ユーザデータは暗号処理部１６を通過する。このとき暗号化処理部１６において、端末において施されたユーザデータの暗号化が復号される。これは、相手ＣＡＢＳ(correspondence CABS)ではユーザデータに施された暗号化を解除できないからである
。その後、復号されたユーザデータは、ＩＰ多重／分離部１５でＩＰパケット化され、ＣＡＢＳ間に確立されたセッションで相手先のＣＡＢＳに送られる。
【０１６０】
一方、相手ＣＡＢＳからのデータは、ＩＰ多重／分離部１５から第２ルートＹに振り分けられ、暗号処理部１６で暗号化された後、ベアラセレクタ１４，多重／分離部１２を経てＲＦ部１１から端末に送られる。
【０１６１】
ＣＡＢＳ間のセッション処理(セッションの確立及び切断処理)を行うのはＣＮＴ部１７であり、セッションを確立するための制御データはすべてＣＮＴ部１７で終端され、ＩＰ多重／分離部を通して相手ＣＡＢＳの制御部(ＣＮＴ部)と通信することになる。
【０１６２】
ＣＮＴ部１７は、ベアラセレクタ１４によるルート選択を制御する。即ち、ＣＡＢＳ間にセッションが確立されている場合には、ＣＮＴ部１７はベアラセレクタ１４に第２ルートＹを選択するための制御信号を与える。一方、ＣＡＢＳ間にセッションが確立されていない場合には、ＣＮＴ部１７はベアラセレクタ１４に第１ルートＸを選択するための制御信号を与える。
【０１６３】
ここでの注意点は、図１２の右側に示した４つの制御チャネル及びユーザチャネルは論理リンクであり、物理的には１本のＩＰインタフェース(ＩＰ−ＩＦ)上で多重されていることである。そしてこれらの論理リンクは同時に保持が可能であることも重要な機能である。
【０１６４】
以上示したように、ＣＡＢＳ１０は、通常の基地局機能に加えて、ユーザチャネルにおけるデータルートを第１ルートＸと第２ルートＹとに分離し、必要に応じて暗号化/復号
化を行う機能を持つ。さらに、ＣＡＢＳ１０は、データルートを制御チャネルからの信号に基づいて切り替える機能を持つ。さらに、ＣＡＢＳ１０は、ＣＡＢＳ間でセッションを確立/切断する機能を持つ。このようなＣＡＢＳ１０を適用することによって、図９や図
１１で示したシーケンスを実施することができる。
【０１６５】
なお、図１２に示すＣＡＢＳ１０において、ＲＦ１１が本発明の受信部に相当し、ＩＰ多重／分離部が本発明の送信部に相当し、ＣＮＴ部１７が本発明のデータ伝送路確立／切断部に相当する。また、ＣＮＴ部１７は、本発明のデータ通信路確立／切断部，切替制御部，接続制御部としても機能する。ベアラセレクタ１４は、本発明の切替部，接続部として機能する。
【０１６６】
〈ＲＮＳによる処理〉
図１３は、本発明による着信側の基地局制御装置(ＲＮＳ)の処理について、現状のＲＮＳ装置からの変更部分に関連する処理を示すフローチャートである。図１３に示す処理は、発信側からのSETUP信号が、着信側ＲＮＳ(destination RNS:D-RNS)で受信された場合に開始される。図９のシーケンスでは、ＲＮＳ２が着信側ＲＮＳに該当する。
【０１６７】
ＲＮＳ２は、SETUP信号を受信すると(Ｓ２０１：CC SETUP)、SETUP信号の中にＩＳＰ−ＩＤが存在するかをチェックする(Ｓ２０２：Is there ISP-ID in STUP)。
【０１６８】
ＩＳＰ−ＩＤが存在する場合(Ｓ２０２；Ｙ)には、ＲＮＳ２は、ＲＮＳ２内の記憶装置上に予め記憶されているＩＳＰ−ＩＤとＣＡＢＳ２のＩＰアドレスとを取り出し(Ｓ２０
３：Get ISP-ID and IP address of CABS2 in source RNS)、ＩＳＰ−ＩＤが一致するか
どうかをチェックする(Ｓ２０４：Is ISP-ID corresponding?)。
【０１６９】
このとき、ＩＳＰ−ＩＤが一致する場合(Ｓ２０５)には、ＲＮＳ２は、ＣＡＢＳ間の直接通信が可能であるとして、直接通信可能フラグ(D.C.Pフラグ)をセット(オン)する(Ｓ２０６：Set the Direct Connection Possible flag between CABS)。
【０１７０】
ＩＳＰ−ＩＤが存在しない場合(Ｓ２０２；Ｎ)、或いはＩＳＰ−ＩＤが一致しない場合(Ｓ２０４；Ｎ)には、ＲＮＳ２は、D.C.Pフラグをクリア(オフ)する(Ｓ２０６：Clear the Direct Connection Possible flag between CABS)。
【０１７１】
Ｓ２０５又はＳ２０６の処理が終了した後、ＲＮＳ２は、受信した“SETUP”をＣＡＢ
Ｓ２に送る(Ｓ２０７)。ここまで説明したＳ２０１〜Ｓ２０７の処理が、図９の[Ｂ]で示す内部処理である。
【０１７２】
その後、ＣＡＢＳ２側から“CALL CONFIRM”を受信すると(Ｓ２０８)、“CALL CONFIRM”をＭＳＣ２側へ送る(Ｓ２０９)。
【０１７３】
次に、ＲＮＳ２は、ＭＳＣ２から“RAB ASSIGNMENT REQUEST”によるベアラ確保指示を受け取る(Ｓ２１０)。すると、ＲＮＳ２は、Ｓ２０３又はＳ２０６にて設定したD.C.Pフ
ラグの値を“RADIO LINK RECONFIGURATION PREPARE”にセットし(Ｓ２１１)、ＣＡＢＳ２に送信する(Ｓ２１２)。Ｓ２１０〜Ｓ２１２の処理が、図９の[Ｃ]で示す内部処理である。
【０１７４】
さらに、ＲＮＳ２は、D.C.P.フラグがセットされているかをチェックする(Ｓ２１３)。D.C.P.フラグがセット(オン)されていれば(Ｓ２１３；Ｙ)、着信側ＣＡＢＳ(ＣＡＢＳ２
のＩＰアドレス)を載せたRAB INTER-CAB MODE（新メッセージ）を送信し(Ｓ２１４)、発
信側にＣＡＢＳ間でのリンクの直接確立処理を促す。このような処理で、図９のＳ１１０〜Ｓ１１４のシーケンスが実現できる。
【０１７５】
〈ＭＳＣによる処理〉
図１４は、本発明に係る交換機(ＭＳＣ)の、CPGメッセージを受信した際における処理
を示すフローチャートであり、現状の処理からの変更部分に関連した部分が示されている。
【０１７６】
図９に示すように、本発明の実施例では、図９に示すＳ１１５にて送信される新規のCPGメッセージと、Ｓ１２７にて送信される既存のCPGメッセージとの二種類のメッセージが存在する。既存のCPGメッセージは、ALERTINGメッセージを意味する。これに対し、新規
のCPGメッセージは、“RAB INTER-CAB MODE”を指示するためのメッセージである。
【０１７７】
CPGメッセージが既存のメッセージであるか新規のメッセージであるか(CPGメッセージ
のタイプ)は、ＭＳＣがCPGメッセージ内に設定されたパラメータを参照することによって区別(識別)することができる。
【０１７８】
図１４において、ＭＳＣ(図９ではＭＳＣ１)は、CPGメッセージを受信すると(Ｓ３０１)、CPGメッセージ内の所定のパラメータを参照することによって、CPGメッセージが新規
のメッセージであるかを判定する(Ｓ３０２)。
【０１７９】
CPGメッセージが既存のCBGメッセージである場合(Ｓ３０２；Ｎ)には、ＭＳＣは、従来と同様に、ALERTINGメッセージをＲＮＳ(ＲＮＳ１)に送信し(Ｓ３０８)、次の処理へ進む。
【０１８０】
これに対し、CPGメッセージが新規のCPGメッセージである場合(Ｓ３０２；Ｙ)には、このCPGメッセージから着信側ＣＡＢＳ(ＣＡＢＳ２)のＩＰアドレスを取得する(Ｓ３０３：Get IP address of CABS2 from CPG (NEW))。
【０１８１】
ここに、新規のCPGメッセージは、着信側ＣＡＢＳのＩＰアドレスを含むRAB INTER-CAB
MODEを送信するためのメッセージであり、新規のCPGメッセージは着信側ＣＡＢＳのＩＰアドレスを含んでいる。Ｓ３０３では、このＩＰアドレスが取得される。
【０１８２】
次に、ＭＳＣは、ＣＡＢＳ間リンクを確立する指示を出すためのRAB ASSIGNMENT REQUESTメッセージに、取得された着信側ＣＡＢＳのＩＰアドレスを含め(Ｓ３０４：Set IP address of CABS2 in RAB ASSIGNMENT REQUEST)、ＲＮＳに送信する(Ｓ３０５：図９のＳ１１６参照)。これによって、図９に示すようなＣＡＢＳ間リンクの確立処理(Ｓ１１８，Ｓ１１９)が行われる。
【０１８３】
ＭＳＣの下位の装置は、ＣＡＢＳ間リンクの確立処理が終了するとRAB ASSIGNMENT RESPONSEメッセージをＭＳＣに送信する(図９のＳ１２２参照)。ＭＳＣは、RAB ASSIGNMENT RESPONSEメッセージを受信する(Ｓ３０６)。すると、ＭＳＣは、この呼についてＣＡＢＳ間直接通信モードになったことの内部フラグをセットする(Ｓ３０７：Set INTER-CAB MODE about this call)。そして、次の処理へ進む。
【０１８４】
図１５は、実施例におけるＭＳＣの処理を示すフローチャートで、ANMメッセージ(図９のＳ１３０参照)を受信した場合の処理を示す。ANMメッセージがＭＳＣで受信されると(
Ｓ４０１)、ＭＳＣは、この呼についての内部フラグの値をチェックし、内部フラグ(図１４のＳ３０７で説明した)の値がINTER-CAB MODE、つまりＣＡＢＳ間直接通信モードにな
っているかをチェックする(Ｓ４０２)。
【０１８５】
内部フラグがINTER-CAB MODEを示す場合(Ｓ３０７で内部フラグがセットされている場
合：Ｓ４０２；Ｙ)には、ＭＳＣは、先にＲＮＳとＭＳＣとの間に確立されていたベアラ
を削除するため、ＲＮＳに向けてIU RELEASE COMMANDメッセージを送信する(Ｓ４０３；
図９のＳ１３１参照)。
【０１８６】
IU RELEASE COMMANDの送信を契機に、ＲＮＳ及びＣＡＢＳによって、ＣＡＢＳ(ＣＡＢ
Ｓ１)−ＲＮＳ(ＲＮＳ１)間及びＲＮＳ(ＲＮＳ１)−ＭＳＣ(ＭＳＣ１)間のベアラが削除
される(図９のＳ１３２，Ｓ１３３参照)。
【０１８７】
その後、ＭＳＣは、ベアラの削除が終了を契機にＲＮＳから送信されるIU RELEASE COMPLETEメッセージを受信する(Ｓ４０４)。以後は、現状のANMメッセージを受信した場合と同様に、CC:CONNECTメッセージをＲＮＳ(ＲＮＳ１)に送信する(Ｓ４０５)。
【０１８８】
なお、Ｓ４０２において、INTER-CAB MODEがセットされていないと判定される場合(Ｓ
４０２；Ｎ)には、処理がＳ４０５に進む。即ち、現状と同様の処理が行われる。
【０１８９】
図１６は、実施例におけるＭＳＣの処理を示すフローチャートであり、新メッセージであるRAB INTER-CAB MODEメッセージ(図９のＳ１１４)をＲＮＳから受信した場合におけるＭＳＣ(図９ではＭＳＣ２)の内部処理を示す。
【０１９０】
図１６において、ＭＳＣ２は、RAB INTER-CAB MODEメッセージを受信すると(Ｓ５０１)、ＭＳＣ２は、RAB INTER-CAB MODEメッセージ中からＣＡＢＳ２のＩＰアドレスを取得する(Ｓ５０２；Get IP address of CABS2 from RAB INTER-CAB MODE)。
【０１９１】
次に、ＭＳＣ２は、取得したＩＰアドレスを、新規のCPGメッセージのパラメータの一
つとして、新規のCPGメッセージに設定する(Ｓ５０３：Set IP address of CABS2 in CPG
(NEW))。そして、ＭＳＣ２は、新規のCPGメッセージを発信側ＭＳＣ(ＭＳＣ１)に送信する(Ｓ５０４)。新規のCPGメッセージが発信側ＭＳＣ(ＭＳＣ１)で受信されると、図１４
のフローチャートに示す処理が実行される。
【０１９２】
〈ＣＡＢＳによる処理〉
図１７は、本発明の実施例に係る無線基地局装置(ＣＡＢＳ)の処理を示すフローチャートであり、ベアラに関する処理の現状からの変更部分に係る処理を示している。図１７に示す処理は、図９に示す発信側ＣＡＢＳ(Ｓ−ＣＡＢＳ：図９ではＣＡＢＳ１)及び着信側ＣＡＢＳ(Ｄ−ＣＡＢＳ：図９ではＣＡＢＳ２)の双方に適用される。
【０１９３】
ＣＡＢＳ１は、ＲＮＳ１からRADIO LINK RECONFIGURATION PREPAREメッセージを受信すると(Ｓ６０１)、このメッセージがＣＡＢＳ間直接接続を指示するメッセージか否かをチェックする(Ｓ６０２：Is the instruction which connects between CABS)。
【０１９４】
ここに、ＲＮＳ１は、ＭＳＣ１からRAB ASSIGINMENT REQUESTメッセージを受信する(図９；Ｓ１１６)。このメッセージ中には、ＭＳＣ１で設定されたＣＡＢＳ２のＩＰアドレ
スを含んでいる(図１４；Ｓ３０４，Ｓ３０５)。ＲＮＳ１は、このＣＡＢＳ２のＩＰアドレスを含むRADIO LINK RECONFIGURATION PREPAREメッセージを生成し、ＣＡＢＳ１に送る(図９のＳ１１７)。
【０１９５】
このRADIO LINK RECONFIGURATION PREPAREメッセージを、ＣＡＢＳ１はＳ６０１で受信する。ＣＡＢＳ１は、当該メッセージを参照し、当該メッセージ中からＣＡＢＳ間直接接続を指示するパラメータ(例えばフラグ：ＲＮＳ１で設定される)を検出することで、当該メッセージがＣＡＢＳ間直接接続を指示するメッセージであると判断(認識)することができる。
【０１９６】
ＣＡＢＳ１は、RADIO LINK RECONFIGURATION PREPAREメッセージがＣＡＢＳ間直接接続を指示するメッセージであると判断すると、当該メッセージに含まれているＣＡＢＳ２のＩＰアドレスを取得する(Ｓ６０３：Get IP address of CABS2 from RADIO LINK RECONFIGRATION PREPARE)。
【０１９７】
次に、ＣＡＢＳ１は、取得されたＣＡＢＳ２のＩＰアドレス宛に、ＣＡＢＳ２へＩＰネットワークを通してＣＡＢＳ間直接接続(直接リンク確立)を要求するメッセージとしてのLINK ESTABLISH REQUESTメッセージを送信する(Ｓ６０４)。
【０１９８】
その後、ＣＡＢＳ１は、ＣＡＢＳ２から直接リンク確立のＯＫ(了承)を示すLINK ESTABLISH ACKメッセージを受信すると(Ｓ６０５)、RADIO LINK RECONFIGRATION PREPAREメッ
セージに対して本来行うべき処理（フローチャートで“Other Processing(他の処理)”で示されている）を行う(Ｓ６０９)。
【０１９９】
即ち、ＣＡＢＳ１は、Ｓ６０５でLINK ESTABLISH ACKメッセージを受信すると、次のＳ６０６の判断でＮＯを選択し、Ｓ６１０に処理を進める。そして、RADIO LINK RECONFIGURATION READYをRNSに返送して処理完了を通知する(Ｓ６１０)。
【０２００】
一方、ＣＡＢＳ２も、ＲＮＳ２からのRADIO LINK RECONFIGRATION PREPAREメッセージ(図９のＳ１１３参照)を受信する(Ｓ６０１)。このRADIO LINK RECONFIGRATION PREPAREメッセージには、図１３のＳ２１１でセットされたD.C.P.フラグの値(オン又はオフ)がセットされている。但し、当該メッセージには、Ｓ６０２で検出されるようなＣＡＢＳ間直接接続指示は含まれていない。
【０２０１】
従って、ＣＡＢＳ２は、受信されたメッセージについて、Ｓ６０２でＮＯの判断を行い、処理をＳ６０６に進める。Ｓ６０６では、ＣＡＢＳ２は、D.C.P.フラグの値の値がオンであるかオフであるかを判断する。これによって、ＣＡＢＳ２は、ＣＡＢＳ間接続(ＣＡ
ＢＳ１からのLINK ESTABLISH REQUESTメッセージ)を待つ指示があるか否かを判定する(Ｓ６０６：Is the instruction which waits for the connection between CABS?)。
【０２０２】
ここでは、ＣＡＢＳ２は、D.C.P.フラグの値の値がオンであれば、待機指示があると判断し、D.C.P.フラグの値がオフであれば、待機指示がないと判断する。待機指示がない場合(Ｓ６０６；Ｎ)には、ＣＡＢＳ２は、処理をＳ６０９に進める。
【０２０３】
これに対し、待機指示がある場合(Ｓ６０６；Ｙ)には、ＣＡＢＳ２は、ＣＡＢＳ１からのLINK ESTABLISH REQUESTメッセージを待ち、当該メッセージを受信すると(Ｓ６０７)、ＣＡＢＳ１−２間にリンク(セッション)の確立処理を行った後、LINK ESTABLISH ACKメッセージをＣＡＢＳ１に送信する(Ｓ６０８)。その後、ＣＡＢＳ２は、処理をＳ６０９に進め、他の処理を行った後、RADIO LINK RECONFIGURATION READYをＲＮＳ２に返送して処理完了を通知する(Ｓ１０)。
【０２０４】
なお、各ＣＡＢＳ１及び２の夫々は、リンクの確立指示も待機指示も含まないRADIO LINK RECONFIGURATION PREPAREメッセージを受信した場合には、Ｓ６０３〜Ｓ６０５，Ｓ６０７,Ｓ６０８の処理をスキップしてＳ６０９及びＳ６１０の処理のみを行う。
【０２０５】
図１７に示した処理は、図１２に示したＣＡＢＳ１０のＣＮＴ部１７において行われる。図１７に示す処理は、ＣＡＢＳ内において、メモリに格納された所定の制御プログラムをプロセッサが実行することによるソフトウェア処理によって実現されるようにしても良く、ハードウェアチップを用いたハードウェア処理によって実現されるようにしても良い。
【０２０６】
〈ＲＮＳの構成〉
図１８は、本発明の実施例における基地局制御装置(ＲＮＳ)の構成例を示す図である。図１８において、ＲＮＳ３０は、スイッチ(ＳＷ)３１と、スイッチ３１に接続されたＭＳＣ−ＩＦ３２，ＲＮＳ−ＩＦ３３，ＣＡＢＳ−ＩＦ３４，ＰＡＧＥ３５，ＤＨＴ３６，ＭＭＵＸ３７，ＩＳＵ３８，ＲＳＵ３９，ＢＳＵ４０，ＯＰＳ−ＩＦ４１，及びＣＮＴ４２と、ＣＮＴ４２に接続されたＦＭ４３とを備えている。
【０２０７】
スイッチ３１は、ＣＮＴ４２(ＣＮＴ搭載のソフトウェア)からの指示に従って、各ブロック間の接続切り替えを行う。
【０２０８】
ＭＳＣ−ＩＦ３２は、ＭＳＣとのインタフェース接続部であり、ＡＴＭインタフェースでＭＳＣと接続される。ＲＮＳ−ＩＦ３３は、異なるＲＮＳとのインタフェース接続部でありＩＰ／ＡＴＭインタフェースで異なるＲＮＳと接続される。ＣＡＢＳ−ＩＦ３４は、ＣＡＢＳとのインタフェース接続部であり、ＩＰインタフェースでＣＡＢＳと接続される。二重枠線で示されたＲＮＳ−ＩＦ３３及びＣＡＢＳ−ＩＦ３４は、一つのＲＮＳに対して複数個搭載されることともある。
【０２０９】
スイッチ３１の右側に並んでいるブロック３５〜４０は、チャネルやプロトコルの終端部である。ＰＡＧＥ３５は、PAGINGチャネルの処理を行う。ＤＨＴ３６は、ハンドオーバに係る処理を行う。ＭＭＵＸ３７は、各種共通チャネルの制御（多重／分離）を行う。ＩＳＵ３８は、対ＭＳＣ局間信号を終端制御する。ＲＳＵ３９は、対ＲＮＳ局間信号を終端する。ＢＳＵ４０は、対基地局（CABS,BTS）局間信号を終端する。
【０２１０】
ＣＮＴ４２は、高速ＣＰＵ(Central Processing Unit)を具備するＲＮＳ装置全体を制
御するソフトウェアが搭載された制御部である。ＣＮＴ４２に接続されるＦＭ４３は、ＲＮＳ３０の各ブロックを制御するためのソフトウェアが世代管理されて格納されているフ
ァイルメモリである。
【０２１１】
図１３に示したＲＮＳのフローチャートによる制御は、このＣＮＴ４２に収容されるソフトウェアにより実行される。図１３に示す処理は、ＣＮＴ４２のソフトウェアに改良を加えることで実現される。但し、ハードウェアによって実現されるように構成することもできる。
【０２１２】
ＯＰＳ−ＩＦ４１は、保守用端末や制御装置(OPS：operation system)へのインタフェ
ースの接続部である。ＯＰＳ−ＩＦ４１は、ＩＰインタフェースで保守用端末やＯＰＳと接続される。
【０２１３】
〈ＭＳＣの構成〉
図１９は、本発明の実施例における交換機(ＭＳＣ)の構成例を示すブロック図である。図１９において、ＭＳＣ５０は、スイッチ(ＳＷ)５１と、スイッチ５１に接続されたＭＳＣ−ＩＦ５２，ＳＴＭ−ＩＦ５３，ＲＮＳ−ＩＦ５４，ＮＳＵ５５，ＴＮＳ５７，ＰＢ／ＭＦ５８，Ｃ／ＦＰＴ５９，ＰＫＴ６０，ＩＰＵ６１，ＢＣＩ６２，及びＯＰＳ−ＩＦ４１と、ＣＮＴ５６に接続されたＦＭ６４とを備えている。
【０２１４】
スイッチ５１は、ＣＮＴ５６(ＣＮＴ搭載のソフトウェア)からの指示に従って、各ブロック間の接続切り替えを行う。ＭＳＣ−ＩＦ５２は、異なるＭＳＣとのインタフェース接続部であり、ＡＴＭインタフェースで異なるＭＳＣと接続される。ＳＴＭ(Synchronous Transfer Mode)−ＩＦ５３は、他の網とのインタフェース接続部であり、ＳＴＭインタフ
ェースで他の網に接続される。ＲＮＳ−ＩＦ５４は、ＲＮＳとのインタフェース接続部であり、ＡＴＭインタフェースでＲＮＳと接続される。各インタフェース５２〜５４は、複数個搭載されることもある。
【０２１５】
スイッチ５１の右側に示されている各ブロック５７〜６２は、ＭＳＣの主たる機能を実現するブロックである。
【０２１６】
ＴＮＳ５７は可聴音(ＲＢＴ等)を端末に配信するトーンセンダ部である。ＰＢ／ＭＦ５８は、受信信号をＰＢ(Push Button)音などに分析するＰＢ／ＭＦ信号送受信部で、外部
からの音声信号も配信する。Ｃ／ＦＰＴ５９は、警察/消防関連のトランク機能を持つ機
能ブロックである。
【０２１７】
ＰＫＴはＩＰパケットのインタフェース部で、ＩＰネットワークに接続されている。ＩＰＵ６１は、ＩＰパケットの終端制御部である。ＢＣＩ６２は料金明細センタへの接続インタフェースであり、他のシステムへのインタフェースの一種である。
【０２１８】
ＮＳＵ５５は、ＡＴＭ信号で来る共通線インタフェースの処理を行う部分である。ＣＮＴ５６は、高速ＣＰＵを具備するＭＳＣ装置全体を制御するソフトウェアが搭載される制御機能ブロックである。ＦＭはＣＮＴ５６に搭載されるソフトウェアが世代管理されて格納されているファイルメモリである。
【０２１９】
図１４〜１６に示したＭＳＣのフローチャートによる制御は、ＣＮＴ部５６に収容されるソフトウェアによって実行される。当該制御は、現状のソフトウェアに改良を加えることで実現可能である。ＯＰＳ−ＩＦ６３は、保守用端末や制御装置(ＯＰＳ)へのインタフェースを司る機能ブロックである。
【０２２０】
〈実施例の効果〉
本発明の実施例によれば、図９に示したシーケンスにおいて、ＲＮＳ２でＩＳＰ−ＩＤ
が一致するかが判定されることによって、ＣＡＢＳ間直接接続ベアラを確立できるか否かが判断される。そして、確立可能と判断される場合には、ＣＡＢＳ１とＣＡＢＳ２との間で、端末ＵＥ−ａと端末ＵＥ−ｂとのデータ通信に利用されるデータ伝送路(ＶｏＩＰパ
スセッション)が確立される。このように、実施例に示したネットワークシステムは、本
発明による判定手段及び確立手段を備える。
【０２２１】
ＣＡＢＳ間直接ベアラ(データ伝送路)が確立される場合には、端末ＵＥ−ａと端末ＵＥ−ｂとの間のトラフィックは、携帯電話ネットワークを通過しない。また、当該トラフィックがＩＰネットワークを通過する回数は１回となる。従って、トラフィックの減少により、携帯電話ネットワーク及びＩＰネットワークの負荷を軽減することができる。
【０２２２】
また、ＲＮＳ２において、ＩＳＰ−ＩＤが一致しないと判定される場合、及び、“SETUP”にＩＳＰ−ＩＤが含まれていない場合には、ＣＡＢＳ間直接ベアラができないと判断
される。この場合、着信側のシーケンスは、図８の右側に示すものとなり、携帯電話ネットワークを経由する(ＲＮＳ１−ＭＳＣ１−ＭＳＣ２−ＲＮＳ２を通過する)端末ＵＥ−ａと端末ＵＥ−ｂとの間のデータ伝送路が確立される。このように、ＣＡＢＳ間直接ベアラが確立できない場合には、現行と同様の手順で端末間のデータ伝送路が確立される。これによって、発信端末からの発信要求に対する呼接続を補償することができる。
【０２２３】
また、実施例において、ＲＮＳ１がＩＰアドレスとＩＳＰ−ＩＤに加えて、セッション番号を“SETUP”に付加するように構成することができる。この場合、セッション番号は
、発信側ＣＡＢＳ(ＣＡＢＳ１)及び着信側ＣＡＢＳ(ＣＡＢＳ２)に通知され、発信側ＣＡＢＳ及び着信側ＣＡＢＳはそのセッション番号でＣＡＢＳ間直接ベアラ(ＶｏＩＰパスセ
ッション)を確立する。
【０２２４】
これによって、例えば、ＣＡＢＳ１−ＣＡＢＳ２間で端末ＵＥ−ａと端末ＵＥ−ｂとの通信のためのＣＡＢＳ間直接ベアラ(「第１のＣＡＢＳ間ベアラ」と称する)が確立されている場合に、さらに、ＣＡＢＳ１の配下の端末ＵＥ−ｃ(図示せず)とＣＡＢＳ２の配下の端末ＵＥ−ｄ(図示せず)との間で呼接続が行われる場合には、第１のＣＡＢＳ間ベアラのセッション番号と異なるセッション番号で端末ＵＥ−ｃと端末ＵＥ−ｄとの通信のためのＣＡＢＳ間直接ベアラ(「第２のＣＡＢＳ間ベアラ」と称する)が確立される。このように、ＣＡＢＳ間直接ベアラをセッション番号で区別することにより、ＣＡＢＳ間で同時に複数のＣＡＢＳ間直接ベアラを確立することができる。
【０２２５】
また、図９に示す実施例においては、ＣＡＢＳ１−ＲＮＳ１間のベアラ(第２のデータ
通信路)Ｂ２及びＲＮＳ１−ＭＳＣ１間のベアラＢ３が確立され、これらのベアラＢ２及
びＢ３を用いてＭＳＣ１から呼び出し音がＣＡＢＳ１に送信され、ＣＡＢＳ１が呼び出し音をＣＡＢＳ１と端末ＵＥ−ａとの間のベアラＢ１(第１のデータ通信路)を通じて端末ＵＥ−ａに送信する。これによって、携帯電話ネットワークからの呼び出し音を端末ＵＥ−ａに与え、ユーザに聞かせることができる。
【０２２６】
その後、ＣＡＢＳ間直接ベアラ(データ伝送路ＶＳ)が確立され、端末ＵＥ−ｂが呼び出しに応じた場合には、ベアラＢ１の接続先がベアラＢ２からデータ伝送路ＶＳに切り替えられるとともに、ベアラＢ２及びＢ３が解放される。これによって、ＩＰネットワーク及び携帯電話ネットワークのリソースの浪費を抑えることができる。
【０２２７】
〔その他〕
上述した「発明を実施するための最良の形態」の項は、以下の発明を開示する。以下に開示される発明は、必要に応じて適宜組み合わせることができる。
【０２２８】
（付記１） 携帯電話ネットワークにＩＰネットワークを介して収容された基地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立システムであって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信させる場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定する判定手段と、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する確立手段とを含む携帯電話端末間のデータ伝送路確立システム。（１）
【０２２９】
（付記２） 前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されていない場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
付記１記載の携帯電話端末間のデータ伝送路確立システム。（２）
【０２３０】
（付記３） 発信端末と着信先端末との少なくとも一方がＩＰネットワークを介して前記携帯電話ネットワークに接続されていない基地局の配下に属する場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
付記１又は２記載の携帯電話端末間のデータ伝送路確立システム。（３）
【０２３１】
（付記４） 発信側基地局制御装置となる第１基地局制御装置と、着信側基地局制御装置となる第２基地局制御装置と、前記第１基地局制御装置と前記第２基地局制御装置とを接続する少なくとも１つの交換機とを有する携帯電話ネットワークを含むネットワークシステムであって、
前記第１基地局制御装置は、ＩＰネットワークを介して接続された発信側基地局から、発信端末としての携帯電話端末の発信要求を受信した場合に、この発信要求に前記発信側基地局が接続されるＩＰネットワークの識別情報と前記発信側基地局のＩＰアドレスとを付加し、
前記第２基地局制御装置は、前記少なくとも１つの交換機を介して前記発信要求を受け取り、この発信要求を自装置にＩＰネットワークを介して接続された着信側基地局を通じて着信先端末としての携帯電話端末に送信する場合に、前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致するかを判断し、
ＩＰネットワークの識別情報が一致する場合には、前記第２基地局制御装置が前記発信要求に含まれた前記発信側基地局のＩＰアドレスを前記着信側基地局に通知するとともに、前記着信側基地局のＩＰアドレスを前記発信側基地局に通知し、
前記第１及び第２基地局制御装置は、前記発信側基地局及び前記着信側基地局に指示を与えて、前記発信側基地局と前記着信側基地局とが前記携帯電話ネットワークを経由することなく同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立させる
ネットワークシステム。（４）
【０２３２】
（付記５） 前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致しない場合には、前記第１基地局制御装置，前記第２基地局制御装置，及び前記少なくとも１つの交換機は、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立するため
の処理を行う
付記４記載のネットワークシステム。
【０２３３】
（付記６） 前記第２基地局制御装置で受信される発信要求にＩＰネットワークの識別子が含まれていない場合には、前記第１基地局制御装置，前記第２基地局制御装置及び前記少なくとも１つの交換機は、前記携帯電話ネットワークを経由する発信端末と着信先端末との間のデータ伝送路を確立するための処理を行う
付記４又は５記載のネットワークシステム。
【０２３４】
（付記７） 前記第１基地局制御装置は、発信要求に、前記識別情報と、前記ＩＰアドレスと、前記発信側基地局と前記着信側基地局との間で確立すべきデータ伝送路の識別情報とを付加する
付記４〜６のいずれかに記載のネットワークシステム。（５）
【０２３５】
（付記８） 前記第２基地局制御装置は、前記少なくとも１つの交換機及び前記第１基地局制御装置を通じて、前記着信側基地局のＩＰアドレスを前記発信側基地局装置に通知する
付記４〜７のいずれかに記載のネットワークシステム。
【０２３６】
（付記９） 前記第２基地局制御装置は、前記発信要求から取得される前記発信側基地局のＩＰアドレスを用い、ＩＰネットワーク経由で前記発信側基地局に前記着信側基地局のＩＰアドレスを通知する
付記４〜７のいずれかに記載のネットワークシステム。
【０２３７】
（付記１０） 前記第２基地局制御装置は、前記発信側基地局のＩＰアドレスを前記着信側基地局に通知し、
前記着信側基地局は、前記発信側基地局のＩＰアドレスを用いてＩＰネットワーク経由で前記着信側基地局のＩＰアドレスを前記着信側基地局に通知する付記４〜７のいずれかに記載のネットワークシステム。
【０２３８】
（付記１１） 前記第１基地局制御装置，前記少なくとも１つの交換機は、前記発信要求の受信を契機に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間にデータ通信路を確立し、
前記少なくとも１つの交換機は、前記着信先端末の呼び出し中に、前記データ通信路を用いて呼び出し音を前記発信側基地局に送信し、
前記発信側基地局は、前記データ通信路を介して前記受信される前記呼び出し音を前記発信端末に送信する
付記４〜１０のいずれかに記載のネットワークシステム。（６）
【０２３９】
（付記１２） 前記発信側基地局は、前記着信先端末が呼び出しに応答したときに前記着信先端末から前記発信端末へ送信される接続メッセージの受信を契機として、前記発信端末に接続すべきデータ通信路を、前記第１基地局制御装置との間に確立された前記データ通信路から前記発信側基地局と前記着信側基地局との間に確立されたデータ伝送路に切り替える
付記１１記載のネットワークシステム。
【０２４０】
（付記１３） 前記少なくとも１つの交換機及び前記第１基地局制御装置は、前記着信先端末が呼び出しに応答したときに前記着信先端末から前記発信端末へ送信される接続メッセージの受信を契機として、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間に確立されたデータ通信路を削除する
付記１１又は１２記載のネットワークシステム。（７）
【０２４１】
（付記１４） 前記発信端末と前記着信先端末とが前記発信側基地局と前記着信側基地局との間に確立されたデータ伝送路を用いて通信を行っている場合に、前記発信端末と前記着信先端末との一方から切断要求が送信されたときには、前記発信側基地局及び前記着信側基地局は、前記発信端末と前記発信側基地局との間のリンク及び前記着信端末と前記着信側基地局との間のリンクを切断した後に、前記データ伝送路を切断する
付記４〜１３のいずれかに記載のネットワークシステム。
【０２４２】
（付記１５） 携帯電話ネットワークにＩＰネットワークを介して接続される基地局であって、
発信端末としての携帯電話端末からの発信要求を受信する受信部と、
前記発信要求を前記ＩＰネットワークを介して携帯電話ネットワークへ送信する送信部と、
前記発信要求が前記ＩＰネットワークと同一のＩＰネットワークを介して前記携帯電話ネットワークに接続された異なる基地局を通じて着信先端末としての携帯電話端末に着信する場合に、前記異なる基地局のＩＰアドレスを前記携帯電話ネットワーク又は前記異なる基地局から受け取り、このＩＰアドレスを用いて、前記異なる基地局との間で、前記携帯電話ネットワークを経由することなく前記基地局自身と前記異なる基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立するデータ伝送路確立／切断部と
を含む基地局。（８）
【０２４３】
（付記１６） 前記発信要求を前記携帯電話ネットワークへ送信した後に、前記基地局自身と前記発信端末との間に第１のデータ通信路を確立し、前記基地局自身と前記携帯電話ネットワークとの間に第２のデータ通信路を確立するデータ通信路確立／切断部と、
前記第１のデータ通信路の接続先を前記第２のデータ通信路と前記データ伝送路との間で切り替える切替部と、
前記着信先端末の呼び出し中では、前記切替部に前記第２のデータ通信路を選択させて前記携帯電話ネットワークから送信される呼び出し音を前記第１のデータ伝送路に送出させ、前記着信先端末が呼び出しに応答した場合には、前記切替部に前記データ伝送路を選択させる切替制御部とをさらに含む付記１５記載の基地局。
【０２４４】
（付記１７） 前記データ通信路確立／切断部は、前記着信先端末が呼び出しに応答した場合に、前記第２のデータ伝送路を切断する付記１６記載の基地局。
【０２４５】
（付記１８） 前記データ伝送路確立／切断部は、前記データ通信路確立／切断部によって前記第１のデータ通信路が切断された後に、前記データ伝送路を切断する
付記１６又は１７記載の基地局。
【０２４６】
（付記１９） 前記第１のデータ通信路を伝送されるデータは、前記発信端末と前記携帯電話ネットワークとの間で決定された暗号で暗号化され、
前記第１のデータ通信路からの暗号化されたデータを復号し、且つ前記第１のデータ通信路へ送信すべきデータを前記暗号で暗号化する暗号化処理部と、
前記暗号処理部を通過する第１ルートと、
前記暗号処理部を通過しない第２ルートと、
前記発信端末と前記着信先端末との間を前記携帯電話ネットワークを介して伝送されるデータを前記第２のルートに接続し、前記発信端末と前記着信先端末との間を前記データ伝送路を介して伝送されるデータを前記第１のルートに接続する接続部と、
前記データ伝送路の確立／切断に応じて、前記接続部の接続先のルートを制御する接続
制御部とをさらに含む付記１６〜１８のいずれかに記載の基地局。（９）
【０２４７】
（付記２０） 携帯電話ネットワークにＩＰネットワークを介して収容された基地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立方法であって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、
この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信される場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定し、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する
ことを含む携帯電話端末間のデータ伝送路確立方法。（１０）
【０２４８】
（付記２１） 前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されていない場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
付記２０記載の携帯電話端末間のデータ伝送路確立方法。
【０２４９】
（付記２２） 前記着信先端末がＩＰネットワークを介して前記携帯電話ネットワークに接続されていない基地局の配下に属する場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
付記２０又は２１記載の携帯電話端末間のデータ伝送路確立方法。
【０２５０】
（付記２３） 発信側基地局制御装置となる第１基地局制御装置と、着信側基地局制御装置となる第２基地局制御装置と、前記第１基地局制御装置と前記第２基地局制御装置とを接続する少なくとも１つの交換機とを有する携帯電話ネットワークを含むネットワークシステムにおいて、
前記第１基地局制御装置は、ＩＰネットワークを介して接続された発信側基地局から、発信端末としての携帯電話端末の発信要求を受信した場合に、この発信要求に前記発信側基地局が接続されるＩＰネットワークの識別情報と前記発信側基地局のＩＰアドレスとを付加し、
前記第２基地局制御装置は、前記少なくとも１つの交換機を介して前記発信要求を受け取り、この発信要求を自装置にＩＰネットワークを介して接続された着信側基地局を通じて着信先端末としての携帯電話端末に送信する場合に、前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致するかを判断し、
ＩＰネットワークの識別情報が一致する場合には、前記第２基地局制御装置が前記発信要求に含まれた前記発信側基地局のＩＰアドレスを前記着信側基地局に通知するとともに、前記着信側基地局のＩＰアドレスを前記発信側基地局に通知し、
前記第１及び第２基地局制御装置は、前記発信側基地局及び前記着信側基地局に指示を与えて、前記発信側基地局と前記着信側基地局とが前記携帯電話ネットワークを経由することなく同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立させることを含む携帯電話端末間のデータ伝送路確立方法。
【０２５１】
（付記２４） 前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致しない場合には、前記第１基地局制御装置，前記第２基地局制御装置，及び前記少なくとも１つの交換機は、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立するた
めの処理を行う付記２３記載の携帯電話端末間のデータ伝送路確立方法。
【０２５２】
（付記２５） 前記第２基地局制御装置で受信される発信要求にＩＰネットワークの識別子が含まれていない場合には、前記第１基地局制御装置，前記第２基地局制御装置及び前記少なくとも１つの交換機は、前記携帯電話ネットワークを経由する発信端末と着信先端末との間のデータ伝送路を確立するための処理を行う
付記２３又は２４記載の携帯電話端末間のデータ伝送路確立方法。
【０２５３】
（付記２６） 前記第１基地局制御装置は、発信要求に、前記識別情報と、前記ＩＰアドレスと、前記発信側基地局と前記着信側基地局との間で確立すべきデータ伝送路の識別情報とを付加する
付記２３〜２５のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５４】
（付記２７） 前記第２基地局制御装置は、前記少なくとも１つの交換機及び前記第１基地局制御装置を通じて、前記着信側基地局のＩＰアドレスを前記発信側基地局装置に通知する付記２３〜２６のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５５】
（付記２８） 前記第２基地局制御装置は、前記発信要求から取得される前記発信側基地局のＩＰアドレスを用い、ＩＰネットワーク経由で前記発信側基地局に前記着信側基地局のＩＰアドレスを通知する
付記２３〜２６のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５６】
（付記２９） 前記第２基地局制御装置は、前記発信側基地局のＩＰアドレスを前記着信側基地局に通知し、
前記着信側基地局は、前記発信側基地局のＩＰアドレスを用いてＩＰネットワーク経由で前記着信側基地局のＩＰアドレスを前記着信側基地局に通知する付記２３〜２６のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５７】
（付記３０） 前記第１基地局制御装置，前記少なくとも１つの交換機は、前記発信要求の受信を契機に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間にデータ通信路を確立し、
前記少なくとも１つの交換機は、前記着信先端末の呼び出し中に、前記データ通信路を用いて呼び出し音を前記発信側基地局に送信し、
前記発信側基地局は、前記データ通信路を介して前記受信される前記呼び出し音を前記発信端末に送信する
付記２３〜２９のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５８】
（付記３１） 前記発信側基地局は、前記着信先端末が呼び出しに応答したときに前記着信先端末から前記発信端末へ送信される接続メッセージの受信を契機として、前記発信端末に接続すべきデータ通信路を、前記第１基地局制御装置との間に確立された前記データ通信路から前記発信側基地局と前記着信側基地局との間に確立されたデータ伝送路に切り替える付記３０記載の携帯電話端末間のデータ伝送路確立方法。
【０２５９】
（付記３２） 前記少なくとも１つの交換機及び前記第１基地局制御装置は、前記着信先端末が呼び出しに応答したときに前記着信先端末から前記発信端末へ送信される接続メッセージの受信を契機として、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間に確立されたデータ通信路を削除する
付記３０又は３１記載の携帯電話端末間のデータ伝送路確立方法。
【０２６０】
（付記３３） 前記発信端末と前記着信先端末とが前記発信側基地局と前記着信側基地
局との間に確立されたデータ伝送路を用いて通信を行っている場合に、前記発信端末と前記着信先端末との一方から切断要求が送信されたときには、前記発信側基地局及び前記着信側基地局は、前記発信端末と前記発信側基地局との間のリンク及び前記着信端末と前記着信側基地局との間のリンクを切断した後に、前記データ伝送路を切断する
付記２３〜３２のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【図面の簡単な説明】
【０２６１】
【図１】図１は、本発明を適用可能な携帯電話ネットワークの構成例を示す図である。
【図２】図２は、現行の音声データが通るベアラルートを示した図である。
【図３】図３は、本発明により実現される音声データが通るベアラルートを示した図である。
【図４】図４は、本発明が解決する課題を説明するためのネットワーク構成例を示す図である。
【図５】図５は、本発明の概要及び実施例を説明するためのネットワーク構成例を示す図である。
【図６】図６は、本発明の概要を示すシーケンス図である。
【図７】図７は、本発明に係る呼接続処理におけるベアラ状態の遷移を示す図である。
【図８】図８は、現行の３ＧＮＷの発着信シーケンスを示す図である。
【図９】図９は、本発明の実施例における３ＧＮＷの発着信シーケンスを示す図である。
【図１０】図１０は、現行の３ＧＮＷの切断シーケンスを示す図である。
【図１１】図１１は、本発明の実施例における３ＧＮＷの切断シーケンスを示す図である。
【図１２】図１２は、本発明の実施例におけるＣＡＢＳの構成例を示すブロック図である。
【図１３】図１３は、本発明の実施例における着信側ＲＮＳ(Ｄ−ＲＮＳ)による処理を示すフローチャートである。
【図１４】図１４は、本発明の実施例における発信側ＭＳＣ(Ｓ−ＭＳＣ)による処理を示すフローチャートである。
【図１５】図１５は、本発明の実施例における発信側ＭＳＣ(Ｓ−ＭＳＣ)による処理を示すフローチャートである。
【図１６】図１６は、本発明の実施例における着信側ＭＳＣ(Ｄ−ＭＳＣ)による処理を示すフローチャートである。
【図１７】図１７は、本発明の実施例における発信側ＣＡＢＳ(Ｓ−ＣＡＢＳ)及び着信側(Ｄ−ＣＡＢＳ)による処理を示すフローチャートである。
【図１８】図１８は、本発明の実施例におけるＲＮＳの構成例を示すブロック図である。
【図１９】図１９は、本発明の実施例におけるＭＳＣの構成例を示すブロック図である。
【符号の説明】
【０２６２】
１０・・・ＣＡＢＳ
１１・・・無線処理部
１２・・・多重／分離部
１３・・・取り込み／挿入部
１４・・・ベアラセレクタ
１５・・・ＩＰ多重／分離部
１６・・・暗号処理部
１７・・・制御部(ＣＮＴ部；セッション確立／切断部含む)
３０・・・ＲＮＳ
４２，５６・・・ＣＮＴ部
５０・・・ＭＳＣ
【技術分野】
【０００１】
本発明は、携帯電話ネットワークおよびＩＰ(Internet Protocol)ネットワークを使用
した通信方式に関する。
【背景技術】
【０００２】
携帯電話ネットワーク、例えば第３世代携帯電話ネットワーク(Third Generation mobile phone network)において、地図的に見てサービスエリア(基地局からの電波が届く範囲)ではあるが、電波が届きにくい地域(「不感地帯」と呼ぶ)が存在する。電波は基本的に
直進するため、建物の影、屋内、地下などでは、基地局からの無線電波が十分に届かない場合があるからである。
【０００３】
不感地帯の一つとして、例えば屋内があり、特に戸建て、或いは集合住宅における個人宅内がある。この個人宅内に小型基地局を配置し、個人宅内で携帯電話ネットワークからの電波を円滑に受信できることが望まれている。
【０００４】
本発明に関連する先行技術としては、例えば、以下の特許文献１及び２に記載された技術がある。
【特許文献１】特表２００４−５０７９４６号公報
【特許文献２】特表２００２−５３５８８８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、携帯電話ネットワークにＩＰネットワークを介して設置される基地局を用いて、効率的な携帯電話ネットワーク及びＩＰネットワークの利用を図ることができる技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、上記した目的を達成するために以下の構成を採用する。
【０００７】
即ち、本発明は、携帯電話ネットワークにＩＰネットワークを介して収容された基地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立システムであって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信させる場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定する判定手段と、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する確立手段とを含む。
【０００８】
本発明によれば、発信側基地局と着信側基地局との間が直接接続された端末間のデータ伝送路が確立される。これによって、携帯電話ネットワーク及びＩＰネットワークのトラフィックを減少させることができる。従って、ネットワーク負荷の軽減や、設備設置の負担の軽減を図ることができる。
【０００９】
本発明における「データ」は、テキスト、画像データの他、音声及び音声データを含むことができる。
【００１０】
好ましくは、本発明は、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されていない場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する。
【００１１】
また、好ましくは、本発明は、発信端末と着信先端末との一方がＩＰネットワークを介して前記携帯電話ネットワークに接続されていない基地局の配下に属する場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する。
【００１２】
これらのように、ＩＰネットワークが同一でない場合、及び発信端末と着信端末との少なくとも一方がＩＰネットワークを介して携帯電話ネットワークに接続されていない基地局の配下に存在する場合には、携帯電話ネットワークを経由するデータ伝送路が確立される。このように、基地局間が直接接続されたデータ伝送路を確立できない場合には、携帯電話ネットワークを経由したデータ伝送路を確立することで、端末間でのデータ通信を補償することができる。
【００１３】
本発明は、発信側基地局制御装置となる第１基地局制御装置と、着信側基地局制御装置となる第２基地局制御装置と、前記第１基地局制御装置と前記第２基地局制御装置とを接続する少なくとも１つの交換機とを有する携帯電話ネットワークを含むネットワークシステムであって、
前記第１基地局制御装置は、ＩＰネットワークを介して接続された発信側基地局から、発信端末としての携帯電話端末の発信要求を受信した場合に、この発信要求に前記発信側基地局が接続されるＩＰネットワークの識別情報と前記発信側基地局のＩＰアドレスとを付加し、
前記第２基地局制御装置は、前記少なくとも１つの交換機を介して前記発信要求を受け取り、この発信要求を自装置にＩＰネットワークを介して接続された着信側基地局を通じて着信先端末としての携帯電話端末に送信する場合に、前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致するかを判断し、
ＩＰネットワークの識別情報が一致する場合には、前記第２基地局制御装置が前記発信要求に含まれた前記発信側基地局のＩＰアドレスを前記着信側基地局に通知するとともに、前記着信側基地局のＩＰアドレスを前記発信側基地局に通知し、
前記第１及び第２基地局制御装置は、前記発信側基地局及び前記着信側基地局に指示を与えて、前記発信側基地局と前記着信側基地局とが前記携帯電話ネットワークを経由することなく同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立させる。
【００１４】
好ましくは、本発明における第１基地局制御装置は、発信要求に、前記識別情報と、前記ＩＰアドレスと、前記発信側基地局と前記着信側基地局との間で確立すべきデータ伝送路の識別情報とを付加する。
【００１５】
このようにすれば、発信側基地局と着信側基地局との間に複数の端末の組に対する複数のデータ伝送路が同時に確立される場合に、データ伝送路を識別してデータ伝送路の確立及びデータ伝送を行うことができる。
【００１６】
好ましくは、本発明における前記第１基地局制御装置，前記少なくとも１つの交換機は、前記発信要求の受信を契機に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間にデータ通信路を確立し、
前記少なくとも１つの交換機は、前記着信先端末の呼び出し中に、前記データ通信路を用いて呼び出し音を前記発信側基地局に送信し、
前記発信側基地局は、前記データ通信路を介して前記受信される前記呼び出し音を前記発信端末に送信する。
【００１７】
このようにすれば、携帯電話ネットワークからの呼び出し音を発信端末に接続することができる。
【００１８】
好ましくは、本発明における前記少なくとも１つの交換機及び前記第１基地局制御装置は、前記発信側基地局と前記着信側基地局との間に前記データ伝送路が確立され、且つ前記着信先端末が呼び出しに応答した場合に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間に確立されたデータ通信路を削除する。
【００１９】
このようにすれば、不要となったデータ通信路が削除(解放)されることで、ＩＰネットワーク及び携帯電話ネットワークのリソースの浪費を抑えることができる。
【００２０】
本発明は、携帯電話ネットワークにＩＰネットワークを介して接続される基地局であって、
発信端末としての携帯電話端末からの発信要求を受信する受信部と、
前記発信要求を前記ＩＰネットワークを介して携帯電話ネットワークへ送信する送信部と、
前記発信要求が前記ＩＰネットワークと同一のＩＰネットワークを介して前記携帯電話ネットワークに接続された異なる基地局を通じて着信先端末としての携帯電話端末に着信する場合に、前記異なる基地局のＩＰアドレスを前記携帯電話ネットワーク又は前記異なる基地局から受け取り、このＩＰアドレスを用いて、前記異なる基地局との間で、前記携帯電話ネットワークを経由することなく前記基地局自身と前記異なる基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立するデータ伝送路確立／切断部とを含む。
【００２１】
好ましくは、本発明の基地局と前記発信端末との間には、前記発信端末との間で通信されるデータを伝送するためのデータ通信路が確立され、
前記データ通信路を伝送されるデータは、前記発信端末と前記携帯電話ネットワークとの間で決定された暗号で暗号化され、
前記基地局は、
前記データ通信路からの暗号化されたデータを復号し、且つ前記データ通信路へ送信すべきデータを前記暗号で暗号化する暗号化処理部と、
データが前記暗号処理部を通過する第１ルートと、
データが前記暗号処理部を通過しない第２ルートと、
前記発信端末と前記着信先端末との間を前記携帯電話ネットワークを介して伝送されるデータを前記第２のルートに接続し、前記発信端末と前記着信先端末との間を前記データ伝送路を介して伝送されるデータを前記第１のルートに接続する接続部と、
前記データ伝送路の確立／切断に応じて、前記接続部の接続先のルートを制御する接続制御部とをさらに含む。
【００２２】
基地局及び端末は、相手側の基地局及び端末について適用される暗号を知らない。このため、暗号化されたデータをデータ伝送路を通じて相手方に送信しても、相手方でデータ
を復号することができない。上記した構成によれば、相手方に送信すべきデータは復号されて相手方に送られる。これによって、相手方が受信したデータを復号できないという問題を回避することができる。
【００２３】
また、本発明は、上記したシステムや基地局と同様の特徴を持つ方法の発明を実現することができる。
【発明の効果】
【００２４】
本発明によれば、携帯電話ネットワークにＩＰネットワークを介して設置される小型基地局を用いて、効率的な携帯電話ネットワーク及びＩＰネットワークの利用を図ることができる。
【発明を実施するための最良の形態】
【００２５】
以下、図面を参照して本発明を説明する。以下に説明する構成は例示であり、本発明はその構成に限定されない。
【００２６】
〔本発明の経緯〕
最初に、本発明の経緯について説明する。携帯電話ネットワークのサービスエリア内に存在する不感地帯として、例えば戸建てや集合住宅における個人宅(user home)内がある
。このような個人宅内に小型の無線基地局を設置し、携帯電話のユーザが個人宅内で携帯電話を使用できることが望まれている。このような宅内用の小型基地局装置は、一般に設置されている基地局と比較して以下の特徴を有することが好ましい。
【００２７】
(1) 宅内への設置を可能とすべく、小型で安価、かつサービスエリア（小型基地局からの電波の届く範囲）が狭小で、電波が低出力である（他の同様な基地局に対しできるだけ電波干渉を小さくする）。
【００２８】
(2) ネットワークを形成するために、基地局装置と基地局制御装置間に物理回線を敷設しなければならない。この物理回線において、現在個人宅に普及が進んでいるインターネット接続用のブロードバンド回線（例：ｘＤＳＬ(x Digital Subscriber Line)回線サー
ビス、或いはＣＡＴＶ(Cable TV)のインターネット接続サービス等）が持つＩＰパケット伝送路に相乗りする形式で、データを送受信する。
【００２９】
(3) 宅内用の小型基地局は個人宅のユーザが費用を払って設置することが想定される。
【００３０】
これらの点に鑑み、小型基地局の設置ユーザ（およびその関係者）のみに小型基地局に対する接続を許可するための認証機能(端末-小型基地局認証機能)が、基地局制御装置(ＲＮＳ：Radio Network Sub-system)と小型基地局との間に設けられる。
【００３１】
図１は、携帯電話ネットワークと小型基地局との接続構成例を示す図である。図１において、ＭＳＣ(Mobile services Switching Center:交換移動局)は、携帯電話ネットワー
クの交換処理装置(交換機)である。ＭＳＣは、相互に接続されるとともに、少なくとも１つのＲＮＳを収容する。ＲＮＳは、配下の基地局を制御する基地局制御装置である。ＲＮＳは、少なくとも１つのＢＴＳ(Base Transceiver station)を収容する。ＢＴＳは、端末(mobile station又はUE(user equipment))と無線通信を行うための基地局である。以上が、携帯電話ネットワークに含まれる構成要素である。
【００３２】
なお、図１には、携帯電話ネットワークの例として、３Ｇ(IMT-2000)のＵＭＴＳ(Universal Mobile Telecommunication System)の一部が示されている。ＵＭＴＳは、大略して
、コアネットワークと、コアネットワークへのアクセスネットワーク(UTRAN(Universal T
errestrial Radio Access Network))とからなる。ＵＴＲＡＮは無線部分を含む。図１に
示すＭＳＣは、コアネットワークに含まれる要素であり、ＲＮＳ及びＢＴＳはＵＴＲＡＮに含まれる要素である。
【００３３】
図１に示すＣＡＢＳ(Cubicle Area BTS)が宅内用の小型基地局に相当する。ＣＡＢＳは、通常、ユーザの住宅内に設置され、携帯電話ネットワークのＲＮＳとＩＳＰ(Internet Service Provider)ネットワーク(ＩＰネットワーク)経由で接続される。
【００３４】
図１に示す例では、ユーザの宅内には、ＩＳＰによって提供されるインターネット接続用のブロードバンド回線（例えばｘＤＳＬ）が導入されていることが想定されている。ＣＡＢＳは、ブロードバンド回線として利用される固定電話回線を収容するｘＤＳＬモデムのＩＰインタフェースに接続される。ｘＤＳＬモデムは、固定電話回線から分配されるｘＤＳＬ回線を介してＩＳＰネットワークに設けられたＤＳＬＡＭ(Digital Subscriber Line Access Multiplexer)に接続される。
【００３５】
一方、ＲＮＳは、ＩＷＵ(Inter-Working Unit)を介してＩＳＰネットワークの入口に設けられたエッジルータ(ＥＲ)に接続される。これによって、携帯電話ネットワークとＩＳＰネットワークとが接続されている。
【００３６】
ＩＷＵは、ＩＰレイヤと現在の携帯電話ネットワークの下位レイヤであるＡＴＭ(Asynchronous Transfer Mode)との変換装置である。ＲＮＳとＥＲとの間は、携帯電話ネットワークからの呼量に応じた数の回線で接続される。
【００３７】
このようにして、ＣＡＢＳは、物理的には固定電話回線で接続される。また、ＣＡＢＳはＲＮＳとＩＰインタフェースで接続される。このようにして、或るＩＳＰ網に接続されているＣＡＢＳの全ては、ＩＳＰ(ＩＰ)ネットワークを介して携帯電話ネットワークに収容される。
【００３８】
このように、ＣＡＢＳを宅内に既に敷設されているブロードバンド回線(ＩＳＰへの接
続環境)を用いて携帯電話ネットワークに接続すれば、携帯電話ネットワーク(ＲＮＳ)へ
の特別な回線を各住宅に敷設する必要がない。従って、ＣＡＢＳの導入に係るコストを削減することができる。
【００３９】
また、ＣＡＢＳは、特定の端末のみにＣＡＢＳ自身に対する接続を許可する機能を有している。具体的には、ＣＡＢＳが端末からの接続要求を受け取った場合に、ＲＮＳ／ＭＳＣでＣＡＢＳとの対認証処理が行われる。ＣＡＢＳは、認証処理の結果を元に、接続要求元の端末が接続可能端末であれば、端末からの接続要求を許可する。
【００４０】
図２は、図１に示したようなＣＡＢＳを収容する方式において、二つのＣＡＢＳが同じＩＳＰネットワークに収容されており、この二つのＣＡＢＳを通じて端末間で通信が行われる場合が示されている。
【００４１】
図２で明らかなように、端末間で受け渡しされるデータ（例えば音声呼であれば音声データ）は、ＣＡＢＳ１ａ−ＲＮＳ１−ＭＳＣ−ＲＮＳ２−ＣＡＢＳ２ａの経路(図２の矢
印参照)を通過する。この場合、端末間で送受信されるデータは、ＩＳＰネットワーク（
ＩＰネットワーク）を２度通過する。
【００４２】
もし、図３に示すように、端末間で受け渡しされるデータがＣＡＢＳ間の直接的な接続により、携帯電話ネットワークを経由することなく受け渡しできれば、図２に示す場合に比べてＩＳＰネットワーク内を通過するトラフィックは半分になる。また、ＣＡＢＳ間の
トラフィックは、ＩＳＰネットワークの上位に位置する携帯電話ネットワークを通らないので、設備的に有利であることは明らかである。
【００４３】
各ＣＡＢＳは、ＩＳＰ内でユニークに割り当てられるＩＰアドレスを有している。ＣＡＢＳ間でお互いのＩＰアドレスを知ることができれば、ＩＰパケット(例えば、音声デー
タが含まれたＩＰパケット)を直接的に(携帯電話ネットワークを経由することなく)やり
とりすることが可能である。
【００４４】
しかしながら、図３に示したようなＣＡＢＳ間を直接的に接続するサービスを実際に実現するには大きな問題がある。図４は課題を説明するためのネットワーク構成図である。図４において、端末ＵＥ−ａ（ＣＡＢＳ１と無線接続可能）が、端末ＵＥ−ｂ（ＣＡＢＳ２と無線接続可能）に対し発信する場合を考える。発呼の一連の手続きにより、制御信号は端末ＵＥ−ａからＣＡＢＳ１−ＲＮＳ−ＭＳＣへ伝達され、ＭＳＣで端末ＵＥ−ｂへの着信が決定される。
【００４５】
しかし、現在の携帯電話ネットワークでは、各端末の現在位置をＬＡ(Location Area)
と呼ばれる単位でしか把握していない。ＬＡは、複数のＲＮＳ／ＢＴＳ(ＣＡＢＳ含む)が所属する比較的広範囲なエリアで構成されている。ＭＳＣは、Ｈ／ＶＬＲ(Home/Visitor Location Register)と呼ばれる端末位置登録情報記録装置に接続されており、Ｈ／ＶＬＲには、各ＬＡ内に存在する端末の識別情報が登録されるように構成されている。
【００４６】
ＭＳＣは、端末ＵＥ−ａからの制御信号に応じて、Ｈ／ＶＬＲを参照し、着信端末が存在しているＬＡを読み出し、着信エリアＬＡを決定する。ここでは、端末ＵＥ−ｂはＬＡ１に存在しているので、ＭＳＣはＬＡ１に所属する全てのＲＮＳ（この場合ＲＮＳ１及び２）に着信要求メッセージを送る。
【００４７】
各ＲＮＳ１及び２は、着信要求メッセージをＲＮＳ自身の配下の全てのＢＴＳ(ＣＡＢ
Ｓも含まれる)に送信する。これにより、端末ＵＥ−ｂは、端末自身が接続しているＣＡ
ＢＳ２を介して着信要求メッセージを受け取ることができる。
【００４８】
端末ＵＥ−ｂは、ＣＡＢＳ２からの着信要求メッセージを受信し、着信要求メッセージに応答する(応答信号を送信する)ことで自分の存在位置を示す。この応答信号は、ＣＡＢＳ２→ＲＮＳ２→ＭＳＣと伝わり、さらにＲＮＳ１→ＣＡＢＳ１→端末ＵＥ−ａと送られ、端末ＵＥ−ｂからの応答があったことが示される。これによって通信経路が決定され、ＲＮＣ／ＭＳＣが端末間で音声データを伝送するための通信路(ベアラ)を確保する。
【００４９】
このとき、ＭＳＣはＲＮＳ１及びＲＮＳ２とのベアラを確保するだけで、どのＢＴＳ又はＣＡＢＳの配下に端末が存在しているかは知らない(知らなくても良い)ように構成されている。
【００５０】
したがって、ＭＳＣがベアラを確保する場合に、ＣＡＢＳ１及びＣＡＢＳ２との間に直接的な(携帯電話ネットワークを経由しない)ベアラを確保できるか(ＣＡＢＳ１及びＣＡ
ＢＳ２が同一のＩＳＰネットワークに所属しているか）を判断することはできなかった。また、ＭＳＣは、ＣＡＢＳ１及びＣＡＢＳ２の夫々に相手先のＣＡＢＳがどれであるかを指示することはできなかった。
【００５１】
まあ、各ＲＮＳ１及びＲＮＳ２は、現状では、ＲＮＳ自身の配下のＣＡＢＳの状態を知ることができるだけであり、相手先のＣＡＢＳを知る構成を持たない。このため、ＣＡＢＳ間を直接的に接続するベアラを確保するかどうかの判断を行うことはできなかった。
【００５２】
〔本発明の概要〕
本発明は、ＲＮＳ／ＭＳＣによって確保される端末間の音声データ用のベアラの代わりに、ＣＡＢＳ間をＩＰネットワークを介して直接的に結ぶベアラを確保する。
【００５３】
この確保は、ＣＡＢＳ１及び２の夫々が端末からの応答を受け取った時点で、相手のＣＡＢＳのＩＳＰ内でのＩＰアドレス(ＩＳＰネットワークはＩＰネットワークである)を知ることで、実現することができる。
【００５４】
しかし、現状の構成では、ＣＡＢＳのＩＰアドレスを知っているのは、その上位に位置するＲＮＳのみである。即ち、ＣＡＢＳ１のＩＰアドレスを知っているのはＲＮＳ１のみであり、ＣＡＢＳ２のＩＰアドレスを知っているのはＲＮＳ２のみである。このため、ＣＡＢＳの夫々が相手のＣＡＢＳのＩＰアドレスを知る手段が必要である。
【００５５】
また、各ＣＡＢＳ１及び２は、同じＩＳＰに接続されていることで直接的に両者間でデータ伝送を行うためのベアラを確保することができる。このため、ＣＡＢＳ１及びＣＡＢＳ２が同じＩＳＰに接続されているかどうかを判断する構成が必要である（言い換えると、ＲＮＳ１及び２、ＣＡＢＳ１及び２が同じＩＰネットワークに接続されているかの判断が必要である）。
【００５６】
さらに、上記した判断に基づいてＭＳＣ−ＲＮＳ−ＣＡＢＳ間のベアラを確保するかどうかの判断も必要である。以下に、本発明の目的を達成するための構成について説明する。
【００５７】
図５は、本発明を説明するためのネットワーク構成例を示す図であり、説明に必要な装置以外は省略している。ネットワークの構成例として、ＵＭＴＳが想定されている。
【００５８】
Ｈ／ＶＬＲは、端末の位置(端末が存在するＬＡ)が登録される端末位置登録記憶装置である。各ＭＳＣ１及び２は携帯電話ネットワークの交換処理装置(交換機)である。各ＲＮＳ１及び２は基地局制御装置である。各ＣＡＢＳ１,２及び３は宅内用の小型の無線基地
局装置(本発明の基地局)である。ＢＴＳ２は一般の基地局である。
【００５９】
図５において、携帯電話端末(以下、単に「端末」と表記する)ＵＥ−ａが発呼し、端末ＵＥ−ｂに着呼させる場合を考える。この場合における動作概要のシーケンスを図６に示す。図７は、図６のシーケンスに応じた状態遷移図である。
【００６０】
図６に示すシーケンスにおいては、端末ＵＥ−ａは、発信端末(calling terminal)に相当する。ＣＡＢＳ１は、発信側基地局(source base station)に相当する。ＲＮＳ１は、
第１基地局制御装置に相当する。ＭＳＣ１及びＭＳＣ２は、少なくとも一つの交換機に相当する。ＲＮＳ２は、第２基地局制御装置に相当する。ＣＡＢＳ２は、着信側基地局(destination base station)に相当する。端末ＵＥ−ｂは、着信先端末(called terminal)に
相当する。
【００６１】
図６において、端末ＵＥ−ａが発呼すると、まず呼の前処理(CALL PREPROCESS)が起動
する(Ｓ０１)。この前処理には、無線制御リンクの確立，端末ＵＥ−ａのネットワーク認証（端末ＵＥ−ａがこの携帯電話ネットワークのサービスを受けられるかを認証する），無線部分の暗号化のための暗号化キーのやりとりなどが含まれる。前処理は現状の処理となんら変わらない。
【００６２】
その後、端末ＵＥ−ａは、呼設定信号(発信要求)である“SETUP”をネットワークに送
る(Ｓ０２)。“SETUP”中には、着信を希望する相手先端末(端末ＵＥ−ｂ)の電話番号が
含まれている。“SETUP”を受信したＣＡＢＳ１は、“SETUP”を発信側ＲＮＳ(source-RNS:S-RNS)であるＲＮＳ１に送り、ＲＮＳ１は“SETUP”をＭＳＣ１に送る。
【００６３】
このとき、ＲＮＳ１は、例えば、“SETUP”がＩＰインタフェース(ＩＰネットワーク)
から受信されたことを認識することによって、“SETUP”がＣＡＢＳから送信されたこと
を認識(判断)することができる。さらに、ＲＮＳ１は、“SETUP”の送信元ＩＰアドレス
を検出することによって、“SETUP”の送信元のＣＡＢＳがＣＡＢＳ１であることを知る
ことができる。この場合、ＲＮＳ１は、ＭＳＣへ送信すべき“SETUP”に対し、ＣＡＢＳ
１のＩＰアドレスと、ＲＮＳ１とＣＡＢＳ１との間を中継しているＩＳＰ１の識別子(Ｉ
ＳＰ−ＩＤ：ＩＰネットワークの識別情報に相当)を付加する(Ｓ０２Ａ)。これは、本発
明の第１の特徴である。
【００６４】
これに対し、“SETUP”がＩＰネットワークを介して送信されたものでない場合(通常のＢＴＳから送信されたものである場合)には、上述したようなＩＰアドレス及びＩＳＰ−
ＩＤの付与は行われない。
【００６５】
最終的に“SETUP”を受信したＭＳＣ１は、相手先端末(着信先端末)の電話番号を元に
、Ｈ／ＶＬＲに相手先端末の所在を問い合わせる。ＭＳＣ１は、Ｈ／ＶＬＲからの応答結果より、ＭＳＣ２配下の位置登録エリア(ＬＡ)に相手先端末としての端末ＵＥ−ｂが存在すると分かった場合には、ＭＳＣ２に対してSETUPメッセージを送信する(Ｓ０３)。
【００６６】
ＭＳＣ２は、ＭＳＣ１からの“SETUP”を元に、まず着信要求メッセージ(PAGE REQUEST)を作成し、位置登録エリア内すべてのＲＮＳに送る(Ｓ０４)。これと同時に、ＭＳＣ２
は、ＭＳＣ１に“SETUP”に対する応答を返し(Ｓ０５)、着信動作に入ったことを通知す
る。
【００６７】
ＭＳＣ１は、応答をもらった時点で、端末ＵＥ−ａに対して音声データ伝送のためのベアラ(データ通信路)を構築するベアラ設定手順(BEARER SET)を行い(Ｓ０６)、通話に備える。
【００６８】
ここまでの手順(図６の〈１〉の破線より上の手順：Ｓ０１〜Ｓ０６)によるベアラ確立イメージは、図７(Ａ)に示すベアラ確立状態の遷移図のステップ〈１〉に示されている。即ち、ここまでに説明した手順Ｓ０１〜Ｓ０６で、端末ＵＥ−ａとＣＡＢＳ１との間，ＣＡＢＳ１とＲＮＳ１との間，及びＲＮＳ１とＭＳＣ１との間に、端末ＵＥ−ａと端末ＵＥ−ｂとの間の音声データ通信に使用されるベアラＢ１(第１のデータ通信路)，ベアラＢ２(第２のデータ通信路)，及びベアラＢ３が確立された状態となる。
【００６９】
図６に戻って、着信要求メッセージを受け取ったＲＮＳ(着信側ＲＮＳ(destination-RNS:D-RNS))は、ＲＮＳ自身の配下の全ての基地局に着信要求メッセージを送信する(Ｓ０７)。着信要求メッセージを受け取った基地局は、着信要求メッセージを無線信号に変換し
て送信する。したがって、図５に示す場合では、ＭＳＣ２から送信される着信要求メッセージは、ＲＮＳ１を介してＣＡＢＳ２，ＣＡＢＳ３及びＢＴＳ２から送信される。
【００７０】
着信要求メッセージには端末ＵＥ−ｂの端末番号が含まれており、この着信要求メッセージに応答できるのは着信先端末である端末ＵＥ−ｂのみである。ここでは、端末ＵＥ−ｂは、ＣＡＢＳ２の無線信号から着信要求メッセージを受け取る。
【００７１】
端末ＵＥ−ｂは、着信要求メッセージに対する応答メッセージを返した後(図示せず)、発信端末(端末ＵＥ−ａ)と同様の呼の前処理(CALL PREPROCESS)を行う(Ｓ０８)。
【００７２】
前処理が終了した後、ようやく、発信側のSETUPメッセージがＭＳＣ２から端末ＵＥ−
ｂに向けて送信される(Ｓ０９)。このとき、SETUPメッセージは、ＲＮＳ２及びＣＡＢＳ
２(着信側基地局に相当)を経て端末ＵＥ−ｂに届く。
【００７３】
このとき、ＲＮＳ２は、ＲＮＳ１で付加されたＩＳＰ−ＩＤをSETUPメッセージから取
得し、ＲＮＳ２とＣＡＢＳ２との間を中継しているＩＳＰの識別子(予めＲＮＳ２に登録
されている)と同じかどうかをチェックする(Ｓ０９Ａ)。これが、本発明の第２の特徴で
ある。
【００７４】
もし、ＩＳＰ−ＩＤ同士が同じでない場合（例えば、図５において端末ＵＥ−ｂがＣＡＢＳ３の配下に存在する場合には、ＲＮＳに予め登録されるＩＳＰ−ＩＤは“ＩＳＰ２”であるので、“SETUP”中のＩＳＰ−ＩＤ(“ＩＳＰ１”)と一致しない）には、ＲＮＳ２
にて、ＣＡＢＳ間の直接的な通信はできないと判断される。この場合、以降の手順において、従来と同様のシーケンスによる発着信処理が行われる。
【００７５】
また、SETUPメッセージにＩＳＰ−ＩＤのパラメータが含まれていない場合(例えば、図５において端末ＵＥ−ａがＢＴＳ２の配下にある場合には、端末ＵＥ−ａからのSETUPメ
ッセージにはＲＮＳ２にてＩＳＰ−ＩＤが付加されない)にも、ＲＮＳにて、ＣＡＢＳ間
の直接的な通信はできないと判断される。
【００７６】
図６のシーケンスでは、ＲＮＳ２とＣＡＢＳ２との間は、ＲＮＳ１とＣＡＢＳ１との間と同様に、ＩＳＰ１で中継されている(図５)。このため、ＲＮＳ２において、ＩＳＰ−ＩＤが同じであると判断され、ＣＡＢＳ間で直接的な通信が可能と判断される。
【００７７】
この場合、ＲＮＳ２は、“SETUP”に対する端末ＵＥ−ｂからの応答メッセージ“CALL CONFIRM”(Ｓ１０)を受信すると、本発明の第３の特徴である新しいベアラ確立手順(NEW BEARER SET)に入る(Ｓ１１)。
【００７８】
現状では、従来のベアラ確立手順として、ＲＮＳ２が“CALL CONFIRM”を受信することを契機に、ＭＳＣ２と端末ＵＥ−ｂ間のベアラが確立される。また、ＭＳＣ１−ＭＳＣ２間のベアラも別途確保される。
【００７９】
これに対し、新しいベアラ確立手順(Ｓ１１)では、ＭＳＣ２と端末ＵＥ−ｂ間のベアラ，及びＭＳＣ１−ＭＳＣ２間のベアラの確立手順は行われない。その代わりに、ＣＡＢＳ１とＣＡＢＳ２との間にＩＳＰ１のＩＰネットワークを使用したＣＡＢＳ１とＣＡＢＳ２とを直接的に接続するデータ伝送路(ＣＡＢＳ間直接コネクション)の確立手順と、端末ＵＥ−ｂとＣＡＢＳ２との間に無線リンクによるベアラを確立する手順とが行われる。
【００８０】
具体的には、新しいベアラ確立手順(Ｓ１１)において、ＲＮＳ２は、ＣＡＢＳ２のＩＰアドレスをＲＮＳ１に通知する。ＣＡＢＳ２のＩＰアドレスはＭＳＣ２及びＭＳＣ１を経てＲＮＳ１に到達する。また、ＲＮＳ２は、ＣＡＢＳ２に対し、“SETUP”メッセージか
ら予め取得しておいたＣＡＢＳ１のＩＰアドレスを通知する。このようにして、各ＣＡＢＳ１及び２は、相手先のＣＡＢＳのＩＰアドレスを知ることができる。
【００８１】
ＣＡＢＳ１及びＣＡＢＳ２は、通知された相手先のＣＡＢＳのＩＰアドレスを用いて、直接やりとりを行い、両者間にＣＡＢＳ間直接コネクション(ＣＡＢＳ間直接ベアラ)としてのＶｏＩＰ(Voice over IP)パスセッションを確立する。
【００８２】
新しいベアラ確立手順における１つの重要な点は、無線区間に確立されたセキュリティを確保するための暗号化処理である。呼の前処理において暗号化のためのキー受け渡しが
ＲＮＳ(ＭＳＣ)と端末との間で行われており、ＲＮＳ−端末間での通信は暗号化キーにより暗号化されている。このままではＣＡＢＳでこの暗号化を解くことができない。
【００８３】
このため、ＣＡＢＳ間通信が確定したこの時点で、ＩＰアドレスとともに暗号化キーをＣＡＢＳに渡し、ＣＡＢＳで暗号が解けるようにしておく。或いは、暗号化キーを相手側に送る代わりに、送信側のＣＡＢＳで暗号化データを復号し、復号されたデータを送信するように構成する。そして、ＣＡＢＳ２と端末ＵＥ−ｂとの間の無線リンクのベアラのみが、従来と同様の手順で確立される。なお、ＩＰネットワークのデータ伝送路上を伝送されるデータについては、ＩＰｓｅｃ等の既存のＩＰネットワークにおけるセキュリティ確保の技術を適用することができる。
【００８４】
ここまで(図６の〈２〉の破線より上：Ｓ０８〜Ｓ１１)のベアラ確立状態のイメージは、図７(Ｂ)におけるステップ〈２〉にて示されている。図７(Ｂ)では、図７(Ａ)で示すベアラＢ１,Ｂ２,Ｂ３に加えて、ＣＡＢＳ１ＣＡＢＳ２との間にデータ伝送路ＶＳが確立され、且つＣＡＢＳ２と端末ＵＥ−ｂとの間にベアラＢ４が夫々確立されている。
【００８５】
ここで注意すべき点は、ＣＡＢＳ１から２つのベアラＢ２，ＶＳが同時に確立されていることであり、この時点では、端末ＵＥ−ａとＣＡＢＳ１との間のベアラＢ１はＣＡＢＳ１でＭＳＣ１側のベアラＢ２に接続されている。
【００８６】
端末ＵＥ−ｂは無線ベアラＢ４を確立した後、端末自身の着信音を鳴らし始めるとともに、ALERT信号により呼び出し中であることを発信側に伝える(Ｓ１２)。ALERT信号は、ＭＳＣ２及びＭＳＣ１を経由し(Ｓ１３)、そのまま端末ＵＥ−ａに通知される(Ｓ１４)。
【００８７】
これと同時にＭＳＣ１から呼び出し音（通常ＲＢＴ[Ring Back Tone]）がベアラＢ３，Ｂ２及びＢ１を通じて端末ＵＥ−ａに送られる。これによって、端末ＵＥ−aのスピーカ(図示せず)からは、ＲＢＴによる呼び出し音が出力される。このように、ＭＳＣ１からの
ＲＢＴを端末ＵＥ−ａに伝達するために、ＣＡＢＳ１はＭＳＣ１側のベアラＢ２を選択している。
【００８８】
端末ＵＥ−ｂがユーザのオフフックにより呼び出しに応答すると、CONNECT信号が送信
される(Ｓ１５，Ｓ１６)。CONNECT信号がＭＳＣ１側に伝わった時点で、本発明の４つ目
の特徴であるベアラの切替／削除処理(BEARER CHANGE/DELETE)が行われる(Ｓ１８)。
【００８９】
ベアラの切替処理では、ＣＡＢＳ１のベアラ選択がＭＳＣ１側(ベアラＢ２)からＣＡＢＳ２側(データ伝送路ＶＳ)に切り替えられる。これと同時に、ＣＡＢＳ１とＲＮＳ１との間，及びＲＮＳ１とＭＳＣ１との間の各ベアラＢ２及びＢ３が削除される。
【００９０】
このような切替／削除処理(Ｓ１８)によって、ベアラは図７(Ｃ)に示すステップ〈３〉のイメージとなる。このようにして、ＣＡＢＳ間が直接接続された端末間のデータ伝送用のベアラ(端末ＵＥ−a−ＣＡＢＳ１−ＣＡＢＳ２−端末ＵＥ−ｂのベアラ)が完成する。
【００９１】
その後、端末ＵＥ−ｂからのCONNECT信号がＭＳＣ１から端末ＵＥ−ａに送られる(Ｓ１９)。そして、CONNECT信号に対する応答(CONNECT ACKの送信)を待って(Ｓ１７，Ｓ２０)
、通話が開始される(Ｓ２１)。
【００９２】
通信中状態(During Communication)からの切断処理は、現状とあまり変わらない形式で実現可能である。いずれか一方の端末のオンフックにより呼の切断要求があると、まず、切断メッセージのやりとり(DISCONNECT PROCESS)が行われる(Ｓ２２)。ここでのやりとりは現状と同様である。
【００９３】
続いて、ＭＳＣ１及びＭＳＣ２の夫々から配下の装置(ＲＮＳ)に対してベアラの解放指示(REL REQ(release request))が与えられる(Ｓ２３，Ｓ２４)。
【００９４】
このような解放指示に対し、現状(従来)では、端末ＵＥ−aとＣＡＢＳ１との間，ＣＡ
ＢＳ１とＲＮＳ１との間，ＲＮＳ１とＭＳＣ１との間のベアラ解放処理が行われる。端末ＵＥ−ｂ側も同様に、端末ＵＥ−ｂとＣＡＢＳ２との間，ＣＡＢＳ２とＲＮＳ２との間，ＲＮＳ２とＭＳＣ２との間のベアラ解放処理が行われる。
【００９５】
これに対し、本発明では（ここが第５の特徴である）、従来のベアラ解放処理の代わりに、端末ＵＥ−ａとＣＡＢＳ１との間(従来と同じ)、ＣＡＢＳ１とＣＡＢＳ２との間，ＣＡＢＳ２と端末ＵＥ−ｂとの間の各ベアラの解放処理(BEARER DELETE)が行われる(Ｓ２５，Ｓ２６，Ｓ２７)。これらのベアラ解放処理により端末間におけるすべてのベアラが解
放される。
【００９６】
その後は、不要となった制御信号用のリンクが解放される(Ｓ２８，Ｓ２９)。この解放処理は従来と同様である。制御信号用のリンクの解放終了後、それがＭＳＣ１及びＭＳＣ２に夫々通知される(Ｓ３０，Ｓ３１)。これで、端末間の通信開始から終了までのすべてのシーケンスが終了する。
【００９７】
ところで、基地局(ＣＡＢＳ)の配下には複数の端末が存在することが可能である。このため、図５〜図７に示した手順が複数の端末間で同時に行われることが想定される。ＣＡＢＳに割り当てられたＩＰアドレスだけでは、複数の端末に対する複数の通信ベアラを区別することはできない。
【００９８】
この問題については、上記に述べたＣＡＢＳのＩＰアドレスに加えて、セッションを区別するセッション番号を通知対象に導入することで、解決を図ることができる。この場合では、上記に述べた動作内容において、“ＩＰアドレス”の代わりに“ＩＰアドレス＋セッション番号”にすればよいだけである。
【００９９】
このようにすれば、複数の端末が１つのＣＡＢＳ配下に存在し、それぞれが異なる端末と通信する場合でも、上記と同様な方式により、ＣＡＢＳ間が直接接続されたベアラを用いて通信を行うことができる。
【０１００】
以上述べたように、本発明に係る５つの特徴を持つ、各装置、および方式を使用すれば、現状の端末を変更することなく、ＣＡＢＳ間に直接ベアラを確保することができる。
【０１０１】
これによって、ＩＳＰネットワーク内のトラフィック、携帯電話ネットワーク内のトラフィックが軽減されて、より多くの呼を接続することができるようになる。
【０１０２】
また、ＩＳＰ主体のトラフィックはＩＳＰへの受益の可能性を増やし、それによる設備の縮小がもたらすコストダウンは、携帯電話キャリヤの利益を押し上げ、ユーザにその利益が還元され易くなって、キャリヤ、ＩＳＰ、ユーザ三者に利益をもたらすことになる。
【０１０３】
〔本発明の実施例〕
以下、本発明の実施例について説明する。
【０１０４】
〈実施例におけるシーケンス〉
本発明の実施例として、第３世代の携帯電話ネットワーク（以下「３ＧＮＷ」と表記する）における、具体的なシーケンスを例示する。図８は、現状の３ＧＮＷにおける発着信
から通話中までのシーケンス図であり、図９は、本発明による発着信から通話中までのシーケンスを示す。
【０１０５】
図８及び図９のシーケンスにおけるネットワーク形態は、概要説明と一致させるべく、図５に示したネットワーク形態(トポロジ)となっている。
【０１０６】
３ＧＮＷにおける発呼動作は、図８の最初の部分(前処理：PREPROCESS)に示したとおりで、図９では１つの処理イメージになっている(Ｓ１０１参照)。本発明の概要で説明したとおり、前処理の内容は現状と変わらない。
【０１０７】
その後、発信端末たる端末ＵＥ−ａからCC(呼制御)プロトコル(3G(IMT-2000)標準のプ
ロトコル)によるCC:SETUP信号が携帯電話ネットワーク(ＭＳＣ１)へ向けて送信される(Ｓ１０２)。このとき、ＲＮＳ１において、ＣＡＢＳ１のＩＰアドレス及びＩＳＰ１のＩＳ
Ｐ−ＩＤがSETUP信号に付加される(図９；[Ａ])。
【０１０８】
ＭＳＣ１は、“SETUP”に含まれる端末ＵＥ−ｂの電話番号に基づいて、Ｈ／ＶＬＲか
ら端末ＵＥ−ｂの存在するＬＡを割り出し、このＬＡを管理するＭＳＣ(ここではＭＳＣ
２)に“SETUP”を渡す。
【０１０９】
ここでは、ＲＮＳに“SETUP”は、ＭＳＣ１からＭＳＣ２へ、ＩＳＵＰ(ISDN (Integrated Service Digital Network) User Part)のメッセージ(ＩＡＭ：アドレス(Initial Address))を用いて送信される(Ｓ１０３)。また、ＭＳＣ１は、“SETUP”に対する“CALL PROCEEDING”を端末ＵＥ−ａに返す(Ｓ１０４)。
【０１１０】
なお、ＭＳＣ２は、ＩＡＭメッセージを受信すると、その確認メッセージたるＩＡＡ(
アドレス確認(IAM acknowledgement))メッセージをＭＳＣ１へ送信する(Ｓ１０５)。
【０１１１】
ＭＳＣ２は、“SETUP”を受信すると、これを元に着信要求たるPAGINGメッセージを作
成し、配下のＲＮＳ(ここではＲＮＳ２)に送る(Ｓ１０６)。また、ＭＳＣ２は、ＭＳＣ１に対し、ＡＣＭ(アドレス完了(Address complete))メッセージを送信する(Ｓ１０７)。
【０１１２】
ＲＮＳ２は、ＭＳＣ２からのPAGINGメッセージを元に、着信要求たるPAGING TYPE1メッセージを作成し、配下の全ての基地局に送信する(Ｓ１０８)。これによって、PAGING TYPE1メッセージは、ＣＡＢＳ２を通じて着信端末たる端末ＵＥ−ｂに到着する。
【０１１３】
端末ＵＥ−ｂがPAGING TYPE1メッセージに応答すると、図８に示した手順と同様の前処理が行われ、無線リンクが確立される(Ｓ１０９)。ＭＳＣ２は、前処理の終了後、“SETUP”を端末ＵＥ−ｂに向けて送信する(Ｓ１１０)。
【０１１４】
この“SETUP”メッセージは、ＲＮＳ２を通過する。このとき、ＲＮＳ２は、ＣＡＢＳ
１のＩＰアドレスとＩＳＰ−ＩＤとを“SETUP”から取得し、ＩＳＰ−ＩＤを用いてＣＡ
ＢＳ間ベアラを確立可能かどうかを判断する(図９；[Ｂ])。 ここでは、ＲＮＳ２に予め登録されているＩＳＰ−ＩＤと、“SETUP”から取得されるＩＳＰ−ＩＤが一致するので
、ＲＮＳ２は、ＣＡＢＳ間直接ベアラが確立可能(双方のＣＡＢＳがＩＳＰネットワーク(ＩＰネットワーク)に接続されている)と判断し、ＣＡＢＳ間ベアラの確立を決定する。
【０１１５】
端末が“SETUP”に対する“CALL CONFIRM”を応答すると、この“CALL CONFIRM”は、
ＭＳＣ２まで伝達される(Ｓ１１１)。すると、ＭＳＣ２は、ＭＳＣ２と端末ＵＥ−ｂとの間にベアラを確立するため、RAB ASSIGNMENT REQUEST(RANAP(Radio Access Network Application Protocol)プロトコル)をＲＮＳ２に送信する(Ｓ１１２)。
【０１１６】
ここで、ＲＮＳ２が、ＣＡＢＳ間ベアラの確立を決定している場合には、ＲＮＳ２は、ベアラ確立手続きを行うことなく、ＣＡＢＳ２に対し、RADIO LINK RECONFIGURATION PREPAREメッセージ(Ｓ１１３)で、ＣＡＢＳ１のＩＰアドレスを送るとともに、ＣＡＢＳ１からの直接的なＶｏＩＰセッション確立を待つことを指示する(図９；[Ｃ])。
【０１１７】
また、ＲＮＳ２は、ＭＳＣ２に対し、RAB INTER-CAB MODEメッセージ（RANAPプロトコ
ルにない新しいメッセージである。既存のメッセージのパラメータを変更して使用することも可能である）により、ＣＡＢＳ２のＩＰアドレス(ＲＮＳ２が予め知っている)を送るとともに、ＭＳＣ１側にＣＡＢＳ１とＣＡＢＳ２との間のセッション確立起動を促す(Ｓ
１１４)。ＭＳＣ２は、ＣＡＢＳ２のＩＰアドレス及びセッション確立起動指示は、CPG(Call Progress：呼経過)メッセージ(新規)により、ＭＳＣ１へ伝達される(Ｓ１１５)。
【０１１８】
ＣＡＢＳ２のＩＰアドレス及びセッション確立起動指示は、ＭＳＣ１からのRAB ASSIGNMENT REQUESTメッセージによってＲＮＳ１に伝えられ(Ｓ１１６)、さらにRADIO LINK RECONFIGURATION PREPAREメッセージによってＣＡＢＳ１に伝えられる(Ｓ１１７)。
【０１１９】
すると、ＣＡＢＳ１は、ＣＡＢＳ２のＩＰアドレスを使用してＶｏＩＰセッション（具体的にはＵＤＰ(User Datagram Protocol)でＲＴＰ(Real-time Transport Protocol)セッション）の確立を行う。即ち、ＣＡＢＳ１とＣＡＢＳ２との間で直接ＶｏＩＰセッションの確立手順が行われる。
【０１２０】
図９には、ＶｏＩＰセッション確立手順として、ＣＡＢＳ１からＣＡＢＳ２へのLINK ESTABLISH REQUEST(セッション確立要求)の送信(Ｓ１１８)と、ＣＡＢＳ２からＣＡＢＳ１へのLINK ESTABLISH ACK(セッション確立確認)の送信(Ｓ１１９)とが示されている。これでＣＡＢＳ１とＣＡＢＳ２との間のベアラが確保される。
【０１２１】
ＣＡＢＳ間のベアラが確保されると、各ＣＡＢＳ１及び２は、RADIO LINK RECONFIGURATION READYメッセージでベアラ確保を上位のＲＮＳ１又は２に通知する(Ｓ１２０，Ｓ１
２１)。
【０１２２】
ＲＮＳ１は、RADIO LINK RECONFIGURATION READYメッセージを受け取ると、RAB ASSIGNMENT REQUESTメッセージに対するRAB ASSIGNMENT RESPONSEメッセージをＭＳＣ１に返し
て準備完了を告げる(Ｓ１２２)。
【０１２３】
一方、ＲＮＳ２は、残った（もともと実施すべきである）端末ＵＥ−ｂとの無線ベアラ確立のためのRADIO BEARER SETUPメッセージを端末ＵＥ−ｂに送る(Ｓ１２３)。
【０１２４】
端末ＵＥ−ｂは、RADIO BEARER SETUPメッセージに応じて無線ベアラを確立し、RADIO BEARER SETUP COMPLETEメッセージで無線ベアラ確立完了を通知する(Ｓ１２４)。
【０１２５】
ＲＮＳ２は、RADIO BEARER SETUP COMPLETEメッセージを受け取ると、RAB ASSIGNMENT RESPONSEメッセージをＭＳＣ２に応答して準備完了を告げる(Ｓ１２５)。
【０１２６】
端末ＵＥ−ｂは、無線ベアラが確立すると、CC:ALERTINGメッセージを送る(Ｓ１２６)
。これと同時に、端末ＵＥ−ｂは、端末ＵＥ−ｂ自身の着信音を起動させ、ユーザに着信を告げる。
【０１２７】
ALERTINGメッセージは、ＭＳＣ２，ＭＳＣ１を通じて(Ｓ１２７：CPGメッセージ(既存)により伝達される)、端末ＵＥ−ａまで届けられる(Ｓ１２８)。また、ＭＳＣ１は、ALERT
INGメッセージの送信を契機にＲＢＴを端末ＵＥ−ａに送る(図示せず)。端末ＵＥ−ａの
ユーザは、ＲＢＴを聞くことができる。
【０１２８】
その後、端末ＵＥ−ｂのユーザがオフフック（つまり応答）を行うと、CC:CONNECTメッセージが送られる(Ｓ１２９)。CONNECTメッセージは、ＭＳＣ２を介してＭＳＣ１に伝達
される(Ｓ１３０；ANM(Answer:応答)で伝達される)。すると、ベアラの切替／削除処理が起動される(図９；[Ｄ])。
【０１２９】
即ち、ＭＳＣ１は、ＲＮＳ１に対し、IU RELEASE COMMANDで、ＲＮＳ１−ＭＳＣ１間のベアラの削除を指示するとともに、ＲＮＳ１-ＣＡＢＳ１間のベアラの削除及びＣＡＢＳ
１−２間ベアラへの切り替え指示を行う(Ｓ１３１)。
【０１３０】
ＲＮＳ１は、ベアラの削除及び切替指示をRADIO LINK RECONFIGURATION PREPAREメッセージでＣＡＢＳ１に通知する(Ｓ１３２)。ＣＡＢＳ１は、RADIO LINK RECONFIGURATION PREPAREメッセージに従って、ＭＳＣ１側のベアラをＣＡＢＳ１−２間ベアラへ切り替える処理を実施する。その後、ＲＮＳ１との間のベアラを切断する(図９；[Ｅ])。
【０１３１】
その後、ＣＡＢＳ１は、RADIO LINK RECONFIGURATION READYメッセージでベアラの切替及び削除が完了したことをＲＮＳ１に通知する(Ｓ１３３)。すると、ＲＮＳ１は、ＲＮＳ１−ＭＳＣ１間のベアラを切断し、ＭＳＣ１にIU RELEASE COMPLETEメッセージでベアラ
の切り替えと切断の完了を通知する(Ｓ１３４)。
【０１３２】
以降は、CC:CONNECTメッセージがＭＳＣ１から端末ＵＥ−ａに向けて送信され(Ｓ１３
５)、呼接続が完了する。なお、“CONNECT”に対する“CONNECT ACK”がＭＳＣ１及び端
末ＵＥ−ｂに夫々返信される(Ｓ１３６，Ｓ１３７)。
【０１３３】
図９に示したシーケンスにおいて、Ｓ１１２〜Ｓ１２５の処理が、図６の概要に示した新たなベアラ設定(Ｓ１１)に相当する。また、Ｓ１３１〜Ｓ１３４の処理が、図６に示したベアラ変更／削除処理(Ｓ１８)に相当する。
【０１３４】
図９に示したメッセージは一例であり、特に新しいシーケンス部分に関してはパラメータ等により取り決めを行うことでどのメッセージでも使用可能である。この実施例はシーケンスの実行に使用されるメッセージのタイプを限定するものではない。また、ＣＡＢＳ１とＣＡＢＳ２との間のセッションの確立も一例を示したものであり、本発明におけるＣＡＢＳ間のベアラの確立は実施例に限定されない。
【０１３５】
なお、図９に示すシーケンスにおいて、ＲＮＳ２がＣＡＢＳ１のＩＰアドレスを用い、ＣＡＢＳ２のＩＰアドレスをＩＰネットワークを介して直接ＣＡＢＳ１に通知するように構成することができる。また、ＣＡＢＳ２がＲＮＳ２からＣＡＢＳ１のＩＰアドレスを受けとった場合に、これを用いてＣＡＢＳ２のＩＰアドレスを直接ＣＡＢＳ１に通知するように構成することもできる。
【０１３６】
図１０は、現状における３ＧＮＷの切断シーケンスを示す図であり、図１１は、本発明の実施例における３ＧＮＷの切断シーケンスを示す図である。
【０１３７】
図１１に示すように、例えば端末ＵＥ−ａのオンフックが行われると、端末ＵＥ−ａからCC:DISCONNECTメッセージがＭＳＣ１に送信される(Ｓ１４１)。ＭＳＣ１は、CC:RELEASEメッセージを端末ＵＥ−ａに送信する(Ｓ１４２)。端末ＵＥ−ａはCC:RELEASEメッセー
ジに対し、CC:RELEASE COMPLETEメッセージで応答する(Ｓ１４３)。
【０１３８】
また、ＭＳＣ１は、REL(Release：解放)メッセージをＭＳＣ２に送信する(Ｓ１４４)。ＭＳＣ２は、RLC(Release Complete)をＭＳＣ１に返す(Ｓ１４５)。 また、ＭＳＣ２は
、CC:DISCONNECTメッセージを端末ＵＥ−ｂに送信する(Ｓ１４６)。端末ＵＥ−ｂは、Ｍ
ＳＣ２にCC:RELEASEメッセージを返す(Ｓ１４７)。ＭＳＣ２は、CC:RELEASEメッセージに対し、CC:RELEASE COMPLETEメッセージで応答する(Ｓ１４８)。
【０１３９】
その後、ＭＳＣ１は、ＲＮＳ１に対し、IU RELEASE COMMANDメッセージでベアラの切断を指示する(Ｓ１４９)。これに応じて、ＲＮＳ１は、RRC Connectionの解放処理を行い、端末ＵＥ−ａとＣＡＢＳ１との間の無線リンクの切断を行う(Ｓ１５０)。
【０１４０】
同様に、ＭＳＣ２は、ＲＮＳ２に対し、IU RELEASE COMMANDメッセージでベアラの切断を指示する(Ｓ１５１)。これに応じて、ＲＮＳ２は、RRC Connectionの解放処理を行い、端末ＵＥ−ｂとＣＡＢＳ２との間の無線リンクの切断を行う(Ｓ１５２)。
【０１４１】
以上のようなＳ１４１〜Ｓ１５２の処理は、現状と同様の処理である(図１０参照)。しかし、図１１に示す実施例に係るシーケンスでは、RRC Connection Releaseの指示をＣＡＢＳ１及び２の夫々で確認し、ＣＡＢＳ１とＣＡＢＳ２との間のＶｏＩＰセッションを解放する(Ｓ１５３，Ｓ１５４)。ここが本発明の特徴に係る部分である。
【０１４２】
ＣＡＢＳ１−２間のベアラが解放されることによって、ベアラの解放は完了する。このため、各ＲＮＳ１及び２は、IU RELEASE COMPLETEメッセージで、ベアラの解放完了をＭ
ＳＣ１又はＭＳＣ２に夫々通知する(Ｓ１５５，Ｓ１５６)。
【０１４３】
その後、現行では(図１０)、ＣＡＢＳ−ＲＮＳ間，及びＲＮＳ−ＭＳＣ間の各ベアラ及び各制御リンクの切断処理が行われる。これに対し、本発明の実施例では、ＣＡＢＳ−ＲＮＳ間及びＲＮＳ−ＭＳＣ間の各ベアラは存在しない。このため、ＲＮＳ−ＭＳＣ間，ＲＮＳ−ＣＡＢＳ間の各制御リンクの切断処理のみが実行される(Ｓ１５７，Ｓ１５８，Ｓ
１５９，Ｓ１６０)。
【０１４４】
従って、図１０に示すように、現状では、ＣＡＢＳ−ＲＮＳ間についてAAL2 LINK ReleaseとSCCP Connection Releaseによる二つのリンクの解放処理が必要であり、ＣＡＢＳ−ＲＮＳ間について二つのIP LINK Releaseが必要である。これに対し、図１１に示す実施
例では、SCCP Connection Releaseによる解放処理と、一つのIP LINK Releaseで済む。
【０１４５】
なお、図１１に示したＳ１５０，Ｓ１５３及びＳ１５４の処理が、図６の概要に示したベアラ削除処理(Ｓ２５)に相当する。
【０１４６】
〈ＣＡＢＳの構成〉
図１２は、本発明を実施する場合のＣＡＢＳ１０(ＣＡＢＳの実施例)の機能ブロック図である。図１２において、ＣＡＢＳ１０は、無線インタフェース部(ＲＦ)１１と、ＲＦ１１に接続される多重／分離部(Cch/Uch-Mux/Dmux)１２と、多重／分離部１２と制御チャネル(Cch)を介して接続される取り込み／挿入部(Drop/Insert)１３と、多重／分離部１２とユーザチャネル(Uch)を介して接続されるベアラセレクタ(Bsel)１４とを備えている。
【０１４７】
さらに、ＣＡＢＳ１０は、ベアラセレクタ１４とユーザチャネルを介して接続されるとともに、取り込み／挿入部１３と制御チャネルを介して接続されるＩＰ多重／分離部(IP Mux/Dmux)１５と、ＩＰ多重／分離部１５とベアラセレクタとの間のユーザチャネル上に
配置される暗号処理部(Cipher Decipher)１６と、取り込み／挿入部１３と接続されると
ともに、ベアラセレクタ１４及びＩＰ多重／分離部１５を制御する制御部(ＣＮＴ部(セッション確立／切断部(Session est./disc.)を含む))１７とを備えている。
【０１４８】
ＲＦ１１は、送信アンテナが接続された送信部(Ｔｘ)と受信アンテナが接続された受信部(Ｒｘ)とを有している。端末との通信はＲＦ１１によって行われる。端末からのデータはＲＦ１１の受信部で受信され、多重／分離部１２に入力される。
【０１４９】
多重／分離部１２は、入力された制御用のデータを制御チャネルに振り分け、ユーザデータをユーザチャネルに振り分ける。制御用のデータは取り込み／挿入部１３に入力され、ユーザデータはベアラセレクタ１４に入力される。
【０１５０】
多重／分離部１２からの制御用データは、取り込み／挿入部１３を通過してＩＰ多重／分離部１５でＩＰパケット化される。そして、通常は、ＣＡＢＳ１０の上位装置であるＲＮＳに送信される。
【０１５１】
逆に、ＲＮＳからの制御データパケット(端末へ送るべき制御データ)はＩＰ多重／分離部１５で分離され、取り込み／挿入部１３を通過する。そして、多重／分離部１２からＲＦ１１の送信部に与えられ、端末側へ無線で送信される。
【０１５２】
これに対し、ＲＮＳ−ＣＡＢＳ間でやりとりされる制御データは、ＩＰ多重／分離部１２から取り込み／挿入部１３に与えられると、ＣＮＴ部１７に取り込み(ドロップ)され、ＣＮＴ部１７で終端処理される。
【０１５３】
ＣＮＴ部１７は、ＲＮＳへ送信すべき制御データを作成し、取り込み／挿入部１３に挿入される。この制御データは、ＩＰ多重／分離部１２から制御チャネルを通じてＲＮＳへ送信される。
【０１５４】
一方、端末からのユーザデータは、多重／分離部１２でユーザチャネルに振り分けられ、ベアラセレクタ１４に与えられる。
【０１５５】
ベアラセレクタ１４とＩＰ多重分離部との間には、ユーザデータが暗号処理部１６を通過しない第１ルートＸと、暗号処理部１６を通過する第２ルートＹとが設けられている。
【０１５６】
ユーザ用ベアラが携帯電話ネットワーク内を通る場合（ＲＮＳ−ＭＳＣ経由）では、ユーザデータはベアラセレクタ１４から第１ルートＸへ出力され、暗号化されることなくＩＰ多重／分離部１５に入力され、ＩＰパケット化されて、ＲＮＳへのユーザチャネルへ送出される。
【０１５７】
一方、ＲＮＳからのユーザデータは、ＩＰ多重／分離部１５で第１ルートＸに振り分けられる。そして、ベアラセレクタ１４，多重／分離部１２を経て、ＲＦ１１の送信部から無線で端末に送られる。
【０１５８】
これに対し、ＣＡＢＳ間通信が実施される場合には、端末からのユーザデータはユーザチャネル側に振り分けられた後、ベアラセレクタ１４に入力される。このとき、ベアラセレクタ１４は、ユーザデータを第２ルートＹへ出力する。
【０１５９】
これにより、ユーザデータは暗号処理部１６を通過する。このとき暗号化処理部１６において、端末において施されたユーザデータの暗号化が復号される。これは、相手ＣＡＢＳ(correspondence CABS)ではユーザデータに施された暗号化を解除できないからである
。その後、復号されたユーザデータは、ＩＰ多重／分離部１５でＩＰパケット化され、ＣＡＢＳ間に確立されたセッションで相手先のＣＡＢＳに送られる。
【０１６０】
一方、相手ＣＡＢＳからのデータは、ＩＰ多重／分離部１５から第２ルートＹに振り分けられ、暗号処理部１６で暗号化された後、ベアラセレクタ１４，多重／分離部１２を経てＲＦ部１１から端末に送られる。
【０１６１】
ＣＡＢＳ間のセッション処理(セッションの確立及び切断処理)を行うのはＣＮＴ部１７であり、セッションを確立するための制御データはすべてＣＮＴ部１７で終端され、ＩＰ多重／分離部を通して相手ＣＡＢＳの制御部(ＣＮＴ部)と通信することになる。
【０１６２】
ＣＮＴ部１７は、ベアラセレクタ１４によるルート選択を制御する。即ち、ＣＡＢＳ間にセッションが確立されている場合には、ＣＮＴ部１７はベアラセレクタ１４に第２ルートＹを選択するための制御信号を与える。一方、ＣＡＢＳ間にセッションが確立されていない場合には、ＣＮＴ部１７はベアラセレクタ１４に第１ルートＸを選択するための制御信号を与える。
【０１６３】
ここでの注意点は、図１２の右側に示した４つの制御チャネル及びユーザチャネルは論理リンクであり、物理的には１本のＩＰインタフェース(ＩＰ−ＩＦ)上で多重されていることである。そしてこれらの論理リンクは同時に保持が可能であることも重要な機能である。
【０１６４】
以上示したように、ＣＡＢＳ１０は、通常の基地局機能に加えて、ユーザチャネルにおけるデータルートを第１ルートＸと第２ルートＹとに分離し、必要に応じて暗号化/復号
化を行う機能を持つ。さらに、ＣＡＢＳ１０は、データルートを制御チャネルからの信号に基づいて切り替える機能を持つ。さらに、ＣＡＢＳ１０は、ＣＡＢＳ間でセッションを確立/切断する機能を持つ。このようなＣＡＢＳ１０を適用することによって、図９や図
１１で示したシーケンスを実施することができる。
【０１６５】
なお、図１２に示すＣＡＢＳ１０において、ＲＦ１１が本発明の受信部に相当し、ＩＰ多重／分離部が本発明の送信部に相当し、ＣＮＴ部１７が本発明のデータ伝送路確立／切断部に相当する。また、ＣＮＴ部１７は、本発明のデータ通信路確立／切断部，切替制御部，接続制御部としても機能する。ベアラセレクタ１４は、本発明の切替部，接続部として機能する。
【０１６６】
〈ＲＮＳによる処理〉
図１３は、本発明による着信側の基地局制御装置(ＲＮＳ)の処理について、現状のＲＮＳ装置からの変更部分に関連する処理を示すフローチャートである。図１３に示す処理は、発信側からのSETUP信号が、着信側ＲＮＳ(destination RNS:D-RNS)で受信された場合に開始される。図９のシーケンスでは、ＲＮＳ２が着信側ＲＮＳに該当する。
【０１６７】
ＲＮＳ２は、SETUP信号を受信すると(Ｓ２０１：CC SETUP)、SETUP信号の中にＩＳＰ−ＩＤが存在するかをチェックする(Ｓ２０２：Is there ISP-ID in STUP)。
【０１６８】
ＩＳＰ−ＩＤが存在する場合(Ｓ２０２；Ｙ)には、ＲＮＳ２は、ＲＮＳ２内の記憶装置上に予め記憶されているＩＳＰ−ＩＤとＣＡＢＳ２のＩＰアドレスとを取り出し(Ｓ２０
３：Get ISP-ID and IP address of CABS2 in source RNS)、ＩＳＰ−ＩＤが一致するか
どうかをチェックする(Ｓ２０４：Is ISP-ID corresponding?)。
【０１６９】
このとき、ＩＳＰ−ＩＤが一致する場合(Ｓ２０５)には、ＲＮＳ２は、ＣＡＢＳ間の直接通信が可能であるとして、直接通信可能フラグ(D.C.Pフラグ)をセット(オン)する(Ｓ２０６：Set the Direct Connection Possible flag between CABS)。
【０１７０】
ＩＳＰ−ＩＤが存在しない場合(Ｓ２０２；Ｎ)、或いはＩＳＰ−ＩＤが一致しない場合(Ｓ２０４；Ｎ)には、ＲＮＳ２は、D.C.Pフラグをクリア(オフ)する(Ｓ２０６：Clear the Direct Connection Possible flag between CABS)。
【０１７１】
Ｓ２０５又はＳ２０６の処理が終了した後、ＲＮＳ２は、受信した“SETUP”をＣＡＢ
Ｓ２に送る(Ｓ２０７)。ここまで説明したＳ２０１〜Ｓ２０７の処理が、図９の[Ｂ]で示す内部処理である。
【０１７２】
その後、ＣＡＢＳ２側から“CALL CONFIRM”を受信すると(Ｓ２０８)、“CALL CONFIRM”をＭＳＣ２側へ送る(Ｓ２０９)。
【０１７３】
次に、ＲＮＳ２は、ＭＳＣ２から“RAB ASSIGNMENT REQUEST”によるベアラ確保指示を受け取る(Ｓ２１０)。すると、ＲＮＳ２は、Ｓ２０３又はＳ２０６にて設定したD.C.Pフ
ラグの値を“RADIO LINK RECONFIGURATION PREPARE”にセットし(Ｓ２１１)、ＣＡＢＳ２に送信する(Ｓ２１２)。Ｓ２１０〜Ｓ２１２の処理が、図９の[Ｃ]で示す内部処理である。
【０１７４】
さらに、ＲＮＳ２は、D.C.P.フラグがセットされているかをチェックする(Ｓ２１３)。D.C.P.フラグがセット(オン)されていれば(Ｓ２１３；Ｙ)、着信側ＣＡＢＳ(ＣＡＢＳ２
のＩＰアドレス)を載せたRAB INTER-CAB MODE（新メッセージ）を送信し(Ｓ２１４)、発
信側にＣＡＢＳ間でのリンクの直接確立処理を促す。このような処理で、図９のＳ１１０〜Ｓ１１４のシーケンスが実現できる。
【０１７５】
〈ＭＳＣによる処理〉
図１４は、本発明に係る交換機(ＭＳＣ)の、CPGメッセージを受信した際における処理
を示すフローチャートであり、現状の処理からの変更部分に関連した部分が示されている。
【０１７６】
図９に示すように、本発明の実施例では、図９に示すＳ１１５にて送信される新規のCPGメッセージと、Ｓ１２７にて送信される既存のCPGメッセージとの二種類のメッセージが存在する。既存のCPGメッセージは、ALERTINGメッセージを意味する。これに対し、新規
のCPGメッセージは、“RAB INTER-CAB MODE”を指示するためのメッセージである。
【０１７７】
CPGメッセージが既存のメッセージであるか新規のメッセージであるか(CPGメッセージ
のタイプ)は、ＭＳＣがCPGメッセージ内に設定されたパラメータを参照することによって区別(識別)することができる。
【０１７８】
図１４において、ＭＳＣ(図９ではＭＳＣ１)は、CPGメッセージを受信すると(Ｓ３０１)、CPGメッセージ内の所定のパラメータを参照することによって、CPGメッセージが新規
のメッセージであるかを判定する(Ｓ３０２)。
【０１７９】
CPGメッセージが既存のCBGメッセージである場合(Ｓ３０２；Ｎ)には、ＭＳＣは、従来と同様に、ALERTINGメッセージをＲＮＳ(ＲＮＳ１)に送信し(Ｓ３０８)、次の処理へ進む。
【０１８０】
これに対し、CPGメッセージが新規のCPGメッセージである場合(Ｓ３０２；Ｙ)には、このCPGメッセージから着信側ＣＡＢＳ(ＣＡＢＳ２)のＩＰアドレスを取得する(Ｓ３０３：Get IP address of CABS2 from CPG (NEW))。
【０１８１】
ここに、新規のCPGメッセージは、着信側ＣＡＢＳのＩＰアドレスを含むRAB INTER-CAB
MODEを送信するためのメッセージであり、新規のCPGメッセージは着信側ＣＡＢＳのＩＰアドレスを含んでいる。Ｓ３０３では、このＩＰアドレスが取得される。
【０１８２】
次に、ＭＳＣは、ＣＡＢＳ間リンクを確立する指示を出すためのRAB ASSIGNMENT REQUESTメッセージに、取得された着信側ＣＡＢＳのＩＰアドレスを含め(Ｓ３０４：Set IP address of CABS2 in RAB ASSIGNMENT REQUEST)、ＲＮＳに送信する(Ｓ３０５：図９のＳ１１６参照)。これによって、図９に示すようなＣＡＢＳ間リンクの確立処理(Ｓ１１８，Ｓ１１９)が行われる。
【０１８３】
ＭＳＣの下位の装置は、ＣＡＢＳ間リンクの確立処理が終了するとRAB ASSIGNMENT RESPONSEメッセージをＭＳＣに送信する(図９のＳ１２２参照)。ＭＳＣは、RAB ASSIGNMENT RESPONSEメッセージを受信する(Ｓ３０６)。すると、ＭＳＣは、この呼についてＣＡＢＳ間直接通信モードになったことの内部フラグをセットする(Ｓ３０７：Set INTER-CAB MODE about this call)。そして、次の処理へ進む。
【０１８４】
図１５は、実施例におけるＭＳＣの処理を示すフローチャートで、ANMメッセージ(図９のＳ１３０参照)を受信した場合の処理を示す。ANMメッセージがＭＳＣで受信されると(
Ｓ４０１)、ＭＳＣは、この呼についての内部フラグの値をチェックし、内部フラグ(図１４のＳ３０７で説明した)の値がINTER-CAB MODE、つまりＣＡＢＳ間直接通信モードにな
っているかをチェックする(Ｓ４０２)。
【０１８５】
内部フラグがINTER-CAB MODEを示す場合(Ｓ３０７で内部フラグがセットされている場
合：Ｓ４０２；Ｙ)には、ＭＳＣは、先にＲＮＳとＭＳＣとの間に確立されていたベアラ
を削除するため、ＲＮＳに向けてIU RELEASE COMMANDメッセージを送信する(Ｓ４０３；
図９のＳ１３１参照)。
【０１８６】
IU RELEASE COMMANDの送信を契機に、ＲＮＳ及びＣＡＢＳによって、ＣＡＢＳ(ＣＡＢ
Ｓ１)−ＲＮＳ(ＲＮＳ１)間及びＲＮＳ(ＲＮＳ１)−ＭＳＣ(ＭＳＣ１)間のベアラが削除
される(図９のＳ１３２，Ｓ１３３参照)。
【０１８７】
その後、ＭＳＣは、ベアラの削除が終了を契機にＲＮＳから送信されるIU RELEASE COMPLETEメッセージを受信する(Ｓ４０４)。以後は、現状のANMメッセージを受信した場合と同様に、CC:CONNECTメッセージをＲＮＳ(ＲＮＳ１)に送信する(Ｓ４０５)。
【０１８８】
なお、Ｓ４０２において、INTER-CAB MODEがセットされていないと判定される場合(Ｓ
４０２；Ｎ)には、処理がＳ４０５に進む。即ち、現状と同様の処理が行われる。
【０１８９】
図１６は、実施例におけるＭＳＣの処理を示すフローチャートであり、新メッセージであるRAB INTER-CAB MODEメッセージ(図９のＳ１１４)をＲＮＳから受信した場合におけるＭＳＣ(図９ではＭＳＣ２)の内部処理を示す。
【０１９０】
図１６において、ＭＳＣ２は、RAB INTER-CAB MODEメッセージを受信すると(Ｓ５０１)、ＭＳＣ２は、RAB INTER-CAB MODEメッセージ中からＣＡＢＳ２のＩＰアドレスを取得する(Ｓ５０２；Get IP address of CABS2 from RAB INTER-CAB MODE)。
【０１９１】
次に、ＭＳＣ２は、取得したＩＰアドレスを、新規のCPGメッセージのパラメータの一
つとして、新規のCPGメッセージに設定する(Ｓ５０３：Set IP address of CABS2 in CPG
(NEW))。そして、ＭＳＣ２は、新規のCPGメッセージを発信側ＭＳＣ(ＭＳＣ１)に送信する(Ｓ５０４)。新規のCPGメッセージが発信側ＭＳＣ(ＭＳＣ１)で受信されると、図１４
のフローチャートに示す処理が実行される。
【０１９２】
〈ＣＡＢＳによる処理〉
図１７は、本発明の実施例に係る無線基地局装置(ＣＡＢＳ)の処理を示すフローチャートであり、ベアラに関する処理の現状からの変更部分に係る処理を示している。図１７に示す処理は、図９に示す発信側ＣＡＢＳ(Ｓ−ＣＡＢＳ：図９ではＣＡＢＳ１)及び着信側ＣＡＢＳ(Ｄ−ＣＡＢＳ：図９ではＣＡＢＳ２)の双方に適用される。
【０１９３】
ＣＡＢＳ１は、ＲＮＳ１からRADIO LINK RECONFIGURATION PREPAREメッセージを受信すると(Ｓ６０１)、このメッセージがＣＡＢＳ間直接接続を指示するメッセージか否かをチェックする(Ｓ６０２：Is the instruction which connects between CABS)。
【０１９４】
ここに、ＲＮＳ１は、ＭＳＣ１からRAB ASSIGINMENT REQUESTメッセージを受信する(図９；Ｓ１１６)。このメッセージ中には、ＭＳＣ１で設定されたＣＡＢＳ２のＩＰアドレ
スを含んでいる(図１４；Ｓ３０４，Ｓ３０５)。ＲＮＳ１は、このＣＡＢＳ２のＩＰアドレスを含むRADIO LINK RECONFIGURATION PREPAREメッセージを生成し、ＣＡＢＳ１に送る(図９のＳ１１７)。
【０１９５】
このRADIO LINK RECONFIGURATION PREPAREメッセージを、ＣＡＢＳ１はＳ６０１で受信する。ＣＡＢＳ１は、当該メッセージを参照し、当該メッセージ中からＣＡＢＳ間直接接続を指示するパラメータ(例えばフラグ：ＲＮＳ１で設定される)を検出することで、当該メッセージがＣＡＢＳ間直接接続を指示するメッセージであると判断(認識)することができる。
【０１９６】
ＣＡＢＳ１は、RADIO LINK RECONFIGURATION PREPAREメッセージがＣＡＢＳ間直接接続を指示するメッセージであると判断すると、当該メッセージに含まれているＣＡＢＳ２のＩＰアドレスを取得する(Ｓ６０３：Get IP address of CABS2 from RADIO LINK RECONFIGRATION PREPARE)。
【０１９７】
次に、ＣＡＢＳ１は、取得されたＣＡＢＳ２のＩＰアドレス宛に、ＣＡＢＳ２へＩＰネットワークを通してＣＡＢＳ間直接接続(直接リンク確立)を要求するメッセージとしてのLINK ESTABLISH REQUESTメッセージを送信する(Ｓ６０４)。
【０１９８】
その後、ＣＡＢＳ１は、ＣＡＢＳ２から直接リンク確立のＯＫ(了承)を示すLINK ESTABLISH ACKメッセージを受信すると(Ｓ６０５)、RADIO LINK RECONFIGRATION PREPAREメッ
セージに対して本来行うべき処理（フローチャートで“Other Processing(他の処理)”で示されている）を行う(Ｓ６０９)。
【０１９９】
即ち、ＣＡＢＳ１は、Ｓ６０５でLINK ESTABLISH ACKメッセージを受信すると、次のＳ６０６の判断でＮＯを選択し、Ｓ６１０に処理を進める。そして、RADIO LINK RECONFIGURATION READYをRNSに返送して処理完了を通知する(Ｓ６１０)。
【０２００】
一方、ＣＡＢＳ２も、ＲＮＳ２からのRADIO LINK RECONFIGRATION PREPAREメッセージ(図９のＳ１１３参照)を受信する(Ｓ６０１)。このRADIO LINK RECONFIGRATION PREPAREメッセージには、図１３のＳ２１１でセットされたD.C.P.フラグの値(オン又はオフ)がセットされている。但し、当該メッセージには、Ｓ６０２で検出されるようなＣＡＢＳ間直接接続指示は含まれていない。
【０２０１】
従って、ＣＡＢＳ２は、受信されたメッセージについて、Ｓ６０２でＮＯの判断を行い、処理をＳ６０６に進める。Ｓ６０６では、ＣＡＢＳ２は、D.C.P.フラグの値の値がオンであるかオフであるかを判断する。これによって、ＣＡＢＳ２は、ＣＡＢＳ間接続(ＣＡ
ＢＳ１からのLINK ESTABLISH REQUESTメッセージ)を待つ指示があるか否かを判定する(Ｓ６０６：Is the instruction which waits for the connection between CABS?)。
【０２０２】
ここでは、ＣＡＢＳ２は、D.C.P.フラグの値の値がオンであれば、待機指示があると判断し、D.C.P.フラグの値がオフであれば、待機指示がないと判断する。待機指示がない場合(Ｓ６０６；Ｎ)には、ＣＡＢＳ２は、処理をＳ６０９に進める。
【０２０３】
これに対し、待機指示がある場合(Ｓ６０６；Ｙ)には、ＣＡＢＳ２は、ＣＡＢＳ１からのLINK ESTABLISH REQUESTメッセージを待ち、当該メッセージを受信すると(Ｓ６０７)、ＣＡＢＳ１−２間にリンク(セッション)の確立処理を行った後、LINK ESTABLISH ACKメッセージをＣＡＢＳ１に送信する(Ｓ６０８)。その後、ＣＡＢＳ２は、処理をＳ６０９に進め、他の処理を行った後、RADIO LINK RECONFIGURATION READYをＲＮＳ２に返送して処理完了を通知する(Ｓ１０)。
【０２０４】
なお、各ＣＡＢＳ１及び２の夫々は、リンクの確立指示も待機指示も含まないRADIO LINK RECONFIGURATION PREPAREメッセージを受信した場合には、Ｓ６０３〜Ｓ６０５，Ｓ６０７,Ｓ６０８の処理をスキップしてＳ６０９及びＳ６１０の処理のみを行う。
【０２０５】
図１７に示した処理は、図１２に示したＣＡＢＳ１０のＣＮＴ部１７において行われる。図１７に示す処理は、ＣＡＢＳ内において、メモリに格納された所定の制御プログラムをプロセッサが実行することによるソフトウェア処理によって実現されるようにしても良く、ハードウェアチップを用いたハードウェア処理によって実現されるようにしても良い。
【０２０６】
〈ＲＮＳの構成〉
図１８は、本発明の実施例における基地局制御装置(ＲＮＳ)の構成例を示す図である。図１８において、ＲＮＳ３０は、スイッチ(ＳＷ)３１と、スイッチ３１に接続されたＭＳＣ−ＩＦ３２，ＲＮＳ−ＩＦ３３，ＣＡＢＳ−ＩＦ３４，ＰＡＧＥ３５，ＤＨＴ３６，ＭＭＵＸ３７，ＩＳＵ３８，ＲＳＵ３９，ＢＳＵ４０，ＯＰＳ−ＩＦ４１，及びＣＮＴ４２と、ＣＮＴ４２に接続されたＦＭ４３とを備えている。
【０２０７】
スイッチ３１は、ＣＮＴ４２(ＣＮＴ搭載のソフトウェア)からの指示に従って、各ブロック間の接続切り替えを行う。
【０２０８】
ＭＳＣ−ＩＦ３２は、ＭＳＣとのインタフェース接続部であり、ＡＴＭインタフェースでＭＳＣと接続される。ＲＮＳ−ＩＦ３３は、異なるＲＮＳとのインタフェース接続部でありＩＰ／ＡＴＭインタフェースで異なるＲＮＳと接続される。ＣＡＢＳ−ＩＦ３４は、ＣＡＢＳとのインタフェース接続部であり、ＩＰインタフェースでＣＡＢＳと接続される。二重枠線で示されたＲＮＳ−ＩＦ３３及びＣＡＢＳ−ＩＦ３４は、一つのＲＮＳに対して複数個搭載されることともある。
【０２０９】
スイッチ３１の右側に並んでいるブロック３５〜４０は、チャネルやプロトコルの終端部である。ＰＡＧＥ３５は、PAGINGチャネルの処理を行う。ＤＨＴ３６は、ハンドオーバに係る処理を行う。ＭＭＵＸ３７は、各種共通チャネルの制御（多重／分離）を行う。ＩＳＵ３８は、対ＭＳＣ局間信号を終端制御する。ＲＳＵ３９は、対ＲＮＳ局間信号を終端する。ＢＳＵ４０は、対基地局（CABS,BTS）局間信号を終端する。
【０２１０】
ＣＮＴ４２は、高速ＣＰＵ(Central Processing Unit)を具備するＲＮＳ装置全体を制
御するソフトウェアが搭載された制御部である。ＣＮＴ４２に接続されるＦＭ４３は、ＲＮＳ３０の各ブロックを制御するためのソフトウェアが世代管理されて格納されているフ
ァイルメモリである。
【０２１１】
図１３に示したＲＮＳのフローチャートによる制御は、このＣＮＴ４２に収容されるソフトウェアにより実行される。図１３に示す処理は、ＣＮＴ４２のソフトウェアに改良を加えることで実現される。但し、ハードウェアによって実現されるように構成することもできる。
【０２１２】
ＯＰＳ−ＩＦ４１は、保守用端末や制御装置(OPS：operation system)へのインタフェ
ースの接続部である。ＯＰＳ−ＩＦ４１は、ＩＰインタフェースで保守用端末やＯＰＳと接続される。
【０２１３】
〈ＭＳＣの構成〉
図１９は、本発明の実施例における交換機(ＭＳＣ)の構成例を示すブロック図である。図１９において、ＭＳＣ５０は、スイッチ(ＳＷ)５１と、スイッチ５１に接続されたＭＳＣ−ＩＦ５２，ＳＴＭ−ＩＦ５３，ＲＮＳ−ＩＦ５４，ＮＳＵ５５，ＴＮＳ５７，ＰＢ／ＭＦ５８，Ｃ／ＦＰＴ５９，ＰＫＴ６０，ＩＰＵ６１，ＢＣＩ６２，及びＯＰＳ−ＩＦ４１と、ＣＮＴ５６に接続されたＦＭ６４とを備えている。
【０２１４】
スイッチ５１は、ＣＮＴ５６(ＣＮＴ搭載のソフトウェア)からの指示に従って、各ブロック間の接続切り替えを行う。ＭＳＣ−ＩＦ５２は、異なるＭＳＣとのインタフェース接続部であり、ＡＴＭインタフェースで異なるＭＳＣと接続される。ＳＴＭ(Synchronous Transfer Mode)−ＩＦ５３は、他の網とのインタフェース接続部であり、ＳＴＭインタフ
ェースで他の網に接続される。ＲＮＳ−ＩＦ５４は、ＲＮＳとのインタフェース接続部であり、ＡＴＭインタフェースでＲＮＳと接続される。各インタフェース５２〜５４は、複数個搭載されることもある。
【０２１５】
スイッチ５１の右側に示されている各ブロック５７〜６２は、ＭＳＣの主たる機能を実現するブロックである。
【０２１６】
ＴＮＳ５７は可聴音(ＲＢＴ等)を端末に配信するトーンセンダ部である。ＰＢ／ＭＦ５８は、受信信号をＰＢ(Push Button)音などに分析するＰＢ／ＭＦ信号送受信部で、外部
からの音声信号も配信する。Ｃ／ＦＰＴ５９は、警察/消防関連のトランク機能を持つ機
能ブロックである。
【０２１７】
ＰＫＴはＩＰパケットのインタフェース部で、ＩＰネットワークに接続されている。ＩＰＵ６１は、ＩＰパケットの終端制御部である。ＢＣＩ６２は料金明細センタへの接続インタフェースであり、他のシステムへのインタフェースの一種である。
【０２１８】
ＮＳＵ５５は、ＡＴＭ信号で来る共通線インタフェースの処理を行う部分である。ＣＮＴ５６は、高速ＣＰＵを具備するＭＳＣ装置全体を制御するソフトウェアが搭載される制御機能ブロックである。ＦＭはＣＮＴ５６に搭載されるソフトウェアが世代管理されて格納されているファイルメモリである。
【０２１９】
図１４〜１６に示したＭＳＣのフローチャートによる制御は、ＣＮＴ部５６に収容されるソフトウェアによって実行される。当該制御は、現状のソフトウェアに改良を加えることで実現可能である。ＯＰＳ−ＩＦ６３は、保守用端末や制御装置(ＯＰＳ)へのインタフェースを司る機能ブロックである。
【０２２０】
〈実施例の効果〉
本発明の実施例によれば、図９に示したシーケンスにおいて、ＲＮＳ２でＩＳＰ−ＩＤ
が一致するかが判定されることによって、ＣＡＢＳ間直接接続ベアラを確立できるか否かが判断される。そして、確立可能と判断される場合には、ＣＡＢＳ１とＣＡＢＳ２との間で、端末ＵＥ−ａと端末ＵＥ−ｂとのデータ通信に利用されるデータ伝送路(ＶｏＩＰパ
スセッション)が確立される。このように、実施例に示したネットワークシステムは、本
発明による判定手段及び確立手段を備える。
【０２２１】
ＣＡＢＳ間直接ベアラ(データ伝送路)が確立される場合には、端末ＵＥ−ａと端末ＵＥ−ｂとの間のトラフィックは、携帯電話ネットワークを通過しない。また、当該トラフィックがＩＰネットワークを通過する回数は１回となる。従って、トラフィックの減少により、携帯電話ネットワーク及びＩＰネットワークの負荷を軽減することができる。
【０２２２】
また、ＲＮＳ２において、ＩＳＰ−ＩＤが一致しないと判定される場合、及び、“SETUP”にＩＳＰ−ＩＤが含まれていない場合には、ＣＡＢＳ間直接ベアラができないと判断
される。この場合、着信側のシーケンスは、図８の右側に示すものとなり、携帯電話ネットワークを経由する(ＲＮＳ１−ＭＳＣ１−ＭＳＣ２−ＲＮＳ２を通過する)端末ＵＥ−ａと端末ＵＥ−ｂとの間のデータ伝送路が確立される。このように、ＣＡＢＳ間直接ベアラが確立できない場合には、現行と同様の手順で端末間のデータ伝送路が確立される。これによって、発信端末からの発信要求に対する呼接続を補償することができる。
【０２２３】
また、実施例において、ＲＮＳ１がＩＰアドレスとＩＳＰ−ＩＤに加えて、セッション番号を“SETUP”に付加するように構成することができる。この場合、セッション番号は
、発信側ＣＡＢＳ(ＣＡＢＳ１)及び着信側ＣＡＢＳ(ＣＡＢＳ２)に通知され、発信側ＣＡＢＳ及び着信側ＣＡＢＳはそのセッション番号でＣＡＢＳ間直接ベアラ(ＶｏＩＰパスセ
ッション)を確立する。
【０２２４】
これによって、例えば、ＣＡＢＳ１−ＣＡＢＳ２間で端末ＵＥ−ａと端末ＵＥ−ｂとの通信のためのＣＡＢＳ間直接ベアラ(「第１のＣＡＢＳ間ベアラ」と称する)が確立されている場合に、さらに、ＣＡＢＳ１の配下の端末ＵＥ−ｃ(図示せず)とＣＡＢＳ２の配下の端末ＵＥ−ｄ(図示せず)との間で呼接続が行われる場合には、第１のＣＡＢＳ間ベアラのセッション番号と異なるセッション番号で端末ＵＥ−ｃと端末ＵＥ−ｄとの通信のためのＣＡＢＳ間直接ベアラ(「第２のＣＡＢＳ間ベアラ」と称する)が確立される。このように、ＣＡＢＳ間直接ベアラをセッション番号で区別することにより、ＣＡＢＳ間で同時に複数のＣＡＢＳ間直接ベアラを確立することができる。
【０２２５】
また、図９に示す実施例においては、ＣＡＢＳ１−ＲＮＳ１間のベアラ(第２のデータ
通信路)Ｂ２及びＲＮＳ１−ＭＳＣ１間のベアラＢ３が確立され、これらのベアラＢ２及
びＢ３を用いてＭＳＣ１から呼び出し音がＣＡＢＳ１に送信され、ＣＡＢＳ１が呼び出し音をＣＡＢＳ１と端末ＵＥ−ａとの間のベアラＢ１(第１のデータ通信路)を通じて端末ＵＥ−ａに送信する。これによって、携帯電話ネットワークからの呼び出し音を端末ＵＥ−ａに与え、ユーザに聞かせることができる。
【０２２６】
その後、ＣＡＢＳ間直接ベアラ(データ伝送路ＶＳ)が確立され、端末ＵＥ−ｂが呼び出しに応じた場合には、ベアラＢ１の接続先がベアラＢ２からデータ伝送路ＶＳに切り替えられるとともに、ベアラＢ２及びＢ３が解放される。これによって、ＩＰネットワーク及び携帯電話ネットワークのリソースの浪費を抑えることができる。
【０２２７】
〔その他〕
上述した「発明を実施するための最良の形態」の項は、以下の発明を開示する。以下に開示される発明は、必要に応じて適宜組み合わせることができる。
【０２２８】
（付記１） 携帯電話ネットワークにＩＰネットワークを介して収容された基地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立システムであって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信させる場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定する判定手段と、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する確立手段とを含む携帯電話端末間のデータ伝送路確立システム。（１）
【０２２９】
（付記２） 前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されていない場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
付記１記載の携帯電話端末間のデータ伝送路確立システム。（２）
【０２３０】
（付記３） 発信端末と着信先端末との少なくとも一方がＩＰネットワークを介して前記携帯電話ネットワークに接続されていない基地局の配下に属する場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
付記１又は２記載の携帯電話端末間のデータ伝送路確立システム。（３）
【０２３１】
（付記４） 発信側基地局制御装置となる第１基地局制御装置と、着信側基地局制御装置となる第２基地局制御装置と、前記第１基地局制御装置と前記第２基地局制御装置とを接続する少なくとも１つの交換機とを有する携帯電話ネットワークを含むネットワークシステムであって、
前記第１基地局制御装置は、ＩＰネットワークを介して接続された発信側基地局から、発信端末としての携帯電話端末の発信要求を受信した場合に、この発信要求に前記発信側基地局が接続されるＩＰネットワークの識別情報と前記発信側基地局のＩＰアドレスとを付加し、
前記第２基地局制御装置は、前記少なくとも１つの交換機を介して前記発信要求を受け取り、この発信要求を自装置にＩＰネットワークを介して接続された着信側基地局を通じて着信先端末としての携帯電話端末に送信する場合に、前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致するかを判断し、
ＩＰネットワークの識別情報が一致する場合には、前記第２基地局制御装置が前記発信要求に含まれた前記発信側基地局のＩＰアドレスを前記着信側基地局に通知するとともに、前記着信側基地局のＩＰアドレスを前記発信側基地局に通知し、
前記第１及び第２基地局制御装置は、前記発信側基地局及び前記着信側基地局に指示を与えて、前記発信側基地局と前記着信側基地局とが前記携帯電話ネットワークを経由することなく同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立させる
ネットワークシステム。（４）
【０２３２】
（付記５） 前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致しない場合には、前記第１基地局制御装置，前記第２基地局制御装置，及び前記少なくとも１つの交換機は、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立するため
の処理を行う
付記４記載のネットワークシステム。
【０２３３】
（付記６） 前記第２基地局制御装置で受信される発信要求にＩＰネットワークの識別子が含まれていない場合には、前記第１基地局制御装置，前記第２基地局制御装置及び前記少なくとも１つの交換機は、前記携帯電話ネットワークを経由する発信端末と着信先端末との間のデータ伝送路を確立するための処理を行う
付記４又は５記載のネットワークシステム。
【０２３４】
（付記７） 前記第１基地局制御装置は、発信要求に、前記識別情報と、前記ＩＰアドレスと、前記発信側基地局と前記着信側基地局との間で確立すべきデータ伝送路の識別情報とを付加する
付記４〜６のいずれかに記載のネットワークシステム。（５）
【０２３５】
（付記８） 前記第２基地局制御装置は、前記少なくとも１つの交換機及び前記第１基地局制御装置を通じて、前記着信側基地局のＩＰアドレスを前記発信側基地局装置に通知する
付記４〜７のいずれかに記載のネットワークシステム。
【０２３６】
（付記９） 前記第２基地局制御装置は、前記発信要求から取得される前記発信側基地局のＩＰアドレスを用い、ＩＰネットワーク経由で前記発信側基地局に前記着信側基地局のＩＰアドレスを通知する
付記４〜７のいずれかに記載のネットワークシステム。
【０２３７】
（付記１０） 前記第２基地局制御装置は、前記発信側基地局のＩＰアドレスを前記着信側基地局に通知し、
前記着信側基地局は、前記発信側基地局のＩＰアドレスを用いてＩＰネットワーク経由で前記着信側基地局のＩＰアドレスを前記着信側基地局に通知する付記４〜７のいずれかに記載のネットワークシステム。
【０２３８】
（付記１１） 前記第１基地局制御装置，前記少なくとも１つの交換機は、前記発信要求の受信を契機に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間にデータ通信路を確立し、
前記少なくとも１つの交換機は、前記着信先端末の呼び出し中に、前記データ通信路を用いて呼び出し音を前記発信側基地局に送信し、
前記発信側基地局は、前記データ通信路を介して前記受信される前記呼び出し音を前記発信端末に送信する
付記４〜１０のいずれかに記載のネットワークシステム。（６）
【０２３９】
（付記１２） 前記発信側基地局は、前記着信先端末が呼び出しに応答したときに前記着信先端末から前記発信端末へ送信される接続メッセージの受信を契機として、前記発信端末に接続すべきデータ通信路を、前記第１基地局制御装置との間に確立された前記データ通信路から前記発信側基地局と前記着信側基地局との間に確立されたデータ伝送路に切り替える
付記１１記載のネットワークシステム。
【０２４０】
（付記１３） 前記少なくとも１つの交換機及び前記第１基地局制御装置は、前記着信先端末が呼び出しに応答したときに前記着信先端末から前記発信端末へ送信される接続メッセージの受信を契機として、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間に確立されたデータ通信路を削除する
付記１１又は１２記載のネットワークシステム。（７）
【０２４１】
（付記１４） 前記発信端末と前記着信先端末とが前記発信側基地局と前記着信側基地局との間に確立されたデータ伝送路を用いて通信を行っている場合に、前記発信端末と前記着信先端末との一方から切断要求が送信されたときには、前記発信側基地局及び前記着信側基地局は、前記発信端末と前記発信側基地局との間のリンク及び前記着信端末と前記着信側基地局との間のリンクを切断した後に、前記データ伝送路を切断する
付記４〜１３のいずれかに記載のネットワークシステム。
【０２４２】
（付記１５） 携帯電話ネットワークにＩＰネットワークを介して接続される基地局であって、
発信端末としての携帯電話端末からの発信要求を受信する受信部と、
前記発信要求を前記ＩＰネットワークを介して携帯電話ネットワークへ送信する送信部と、
前記発信要求が前記ＩＰネットワークと同一のＩＰネットワークを介して前記携帯電話ネットワークに接続された異なる基地局を通じて着信先端末としての携帯電話端末に着信する場合に、前記異なる基地局のＩＰアドレスを前記携帯電話ネットワーク又は前記異なる基地局から受け取り、このＩＰアドレスを用いて、前記異なる基地局との間で、前記携帯電話ネットワークを経由することなく前記基地局自身と前記異なる基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立するデータ伝送路確立／切断部と
を含む基地局。（８）
【０２４３】
（付記１６） 前記発信要求を前記携帯電話ネットワークへ送信した後に、前記基地局自身と前記発信端末との間に第１のデータ通信路を確立し、前記基地局自身と前記携帯電話ネットワークとの間に第２のデータ通信路を確立するデータ通信路確立／切断部と、
前記第１のデータ通信路の接続先を前記第２のデータ通信路と前記データ伝送路との間で切り替える切替部と、
前記着信先端末の呼び出し中では、前記切替部に前記第２のデータ通信路を選択させて前記携帯電話ネットワークから送信される呼び出し音を前記第１のデータ伝送路に送出させ、前記着信先端末が呼び出しに応答した場合には、前記切替部に前記データ伝送路を選択させる切替制御部とをさらに含む付記１５記載の基地局。
【０２４４】
（付記１７） 前記データ通信路確立／切断部は、前記着信先端末が呼び出しに応答した場合に、前記第２のデータ伝送路を切断する付記１６記載の基地局。
【０２４５】
（付記１８） 前記データ伝送路確立／切断部は、前記データ通信路確立／切断部によって前記第１のデータ通信路が切断された後に、前記データ伝送路を切断する
付記１６又は１７記載の基地局。
【０２４６】
（付記１９） 前記第１のデータ通信路を伝送されるデータは、前記発信端末と前記携帯電話ネットワークとの間で決定された暗号で暗号化され、
前記第１のデータ通信路からの暗号化されたデータを復号し、且つ前記第１のデータ通信路へ送信すべきデータを前記暗号で暗号化する暗号化処理部と、
前記暗号処理部を通過する第１ルートと、
前記暗号処理部を通過しない第２ルートと、
前記発信端末と前記着信先端末との間を前記携帯電話ネットワークを介して伝送されるデータを前記第２のルートに接続し、前記発信端末と前記着信先端末との間を前記データ伝送路を介して伝送されるデータを前記第１のルートに接続する接続部と、
前記データ伝送路の確立／切断に応じて、前記接続部の接続先のルートを制御する接続
制御部とをさらに含む付記１６〜１８のいずれかに記載の基地局。（９）
【０２４７】
（付記２０） 携帯電話ネットワークにＩＰネットワークを介して収容された基地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立方法であって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、
この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信される場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定し、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する
ことを含む携帯電話端末間のデータ伝送路確立方法。（１０）
【０２４８】
（付記２１） 前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されていない場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
付記２０記載の携帯電話端末間のデータ伝送路確立方法。
【０２４９】
（付記２２） 前記着信先端末がＩＰネットワークを介して前記携帯電話ネットワークに接続されていない基地局の配下に属する場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
付記２０又は２１記載の携帯電話端末間のデータ伝送路確立方法。
【０２５０】
（付記２３） 発信側基地局制御装置となる第１基地局制御装置と、着信側基地局制御装置となる第２基地局制御装置と、前記第１基地局制御装置と前記第２基地局制御装置とを接続する少なくとも１つの交換機とを有する携帯電話ネットワークを含むネットワークシステムにおいて、
前記第１基地局制御装置は、ＩＰネットワークを介して接続された発信側基地局から、発信端末としての携帯電話端末の発信要求を受信した場合に、この発信要求に前記発信側基地局が接続されるＩＰネットワークの識別情報と前記発信側基地局のＩＰアドレスとを付加し、
前記第２基地局制御装置は、前記少なくとも１つの交換機を介して前記発信要求を受け取り、この発信要求を自装置にＩＰネットワークを介して接続された着信側基地局を通じて着信先端末としての携帯電話端末に送信する場合に、前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致するかを判断し、
ＩＰネットワークの識別情報が一致する場合には、前記第２基地局制御装置が前記発信要求に含まれた前記発信側基地局のＩＰアドレスを前記着信側基地局に通知するとともに、前記着信側基地局のＩＰアドレスを前記発信側基地局に通知し、
前記第１及び第２基地局制御装置は、前記発信側基地局及び前記着信側基地局に指示を与えて、前記発信側基地局と前記着信側基地局とが前記携帯電話ネットワークを経由することなく同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立させることを含む携帯電話端末間のデータ伝送路確立方法。
【０２５１】
（付記２４） 前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致しない場合には、前記第１基地局制御装置，前記第２基地局制御装置，及び前記少なくとも１つの交換機は、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立するた
めの処理を行う付記２３記載の携帯電話端末間のデータ伝送路確立方法。
【０２５２】
（付記２５） 前記第２基地局制御装置で受信される発信要求にＩＰネットワークの識別子が含まれていない場合には、前記第１基地局制御装置，前記第２基地局制御装置及び前記少なくとも１つの交換機は、前記携帯電話ネットワークを経由する発信端末と着信先端末との間のデータ伝送路を確立するための処理を行う
付記２３又は２４記載の携帯電話端末間のデータ伝送路確立方法。
【０２５３】
（付記２６） 前記第１基地局制御装置は、発信要求に、前記識別情報と、前記ＩＰアドレスと、前記発信側基地局と前記着信側基地局との間で確立すべきデータ伝送路の識別情報とを付加する
付記２３〜２５のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５４】
（付記２７） 前記第２基地局制御装置は、前記少なくとも１つの交換機及び前記第１基地局制御装置を通じて、前記着信側基地局のＩＰアドレスを前記発信側基地局装置に通知する付記２３〜２６のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５５】
（付記２８） 前記第２基地局制御装置は、前記発信要求から取得される前記発信側基地局のＩＰアドレスを用い、ＩＰネットワーク経由で前記発信側基地局に前記着信側基地局のＩＰアドレスを通知する
付記２３〜２６のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５６】
（付記２９） 前記第２基地局制御装置は、前記発信側基地局のＩＰアドレスを前記着信側基地局に通知し、
前記着信側基地局は、前記発信側基地局のＩＰアドレスを用いてＩＰネットワーク経由で前記着信側基地局のＩＰアドレスを前記着信側基地局に通知する付記２３〜２６のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５７】
（付記３０） 前記第１基地局制御装置，前記少なくとも１つの交換機は、前記発信要求の受信を契機に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間にデータ通信路を確立し、
前記少なくとも１つの交換機は、前記着信先端末の呼び出し中に、前記データ通信路を用いて呼び出し音を前記発信側基地局に送信し、
前記発信側基地局は、前記データ通信路を介して前記受信される前記呼び出し音を前記発信端末に送信する
付記２３〜２９のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【０２５８】
（付記３１） 前記発信側基地局は、前記着信先端末が呼び出しに応答したときに前記着信先端末から前記発信端末へ送信される接続メッセージの受信を契機として、前記発信端末に接続すべきデータ通信路を、前記第１基地局制御装置との間に確立された前記データ通信路から前記発信側基地局と前記着信側基地局との間に確立されたデータ伝送路に切り替える付記３０記載の携帯電話端末間のデータ伝送路確立方法。
【０２５９】
（付記３２） 前記少なくとも１つの交換機及び前記第１基地局制御装置は、前記着信先端末が呼び出しに応答したときに前記着信先端末から前記発信端末へ送信される接続メッセージの受信を契機として、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間に確立されたデータ通信路を削除する
付記３０又は３１記載の携帯電話端末間のデータ伝送路確立方法。
【０２６０】
（付記３３） 前記発信端末と前記着信先端末とが前記発信側基地局と前記着信側基地
局との間に確立されたデータ伝送路を用いて通信を行っている場合に、前記発信端末と前記着信先端末との一方から切断要求が送信されたときには、前記発信側基地局及び前記着信側基地局は、前記発信端末と前記発信側基地局との間のリンク及び前記着信端末と前記着信側基地局との間のリンクを切断した後に、前記データ伝送路を切断する
付記２３〜３２のいずれかに記載の携帯電話端末間のデータ伝送路確立方法。
【図面の簡単な説明】
【０２６１】
【図１】図１は、本発明を適用可能な携帯電話ネットワークの構成例を示す図である。
【図２】図２は、現行の音声データが通るベアラルートを示した図である。
【図３】図３は、本発明により実現される音声データが通るベアラルートを示した図である。
【図４】図４は、本発明が解決する課題を説明するためのネットワーク構成例を示す図である。
【図５】図５は、本発明の概要及び実施例を説明するためのネットワーク構成例を示す図である。
【図６】図６は、本発明の概要を示すシーケンス図である。
【図７】図７は、本発明に係る呼接続処理におけるベアラ状態の遷移を示す図である。
【図８】図８は、現行の３ＧＮＷの発着信シーケンスを示す図である。
【図９】図９は、本発明の実施例における３ＧＮＷの発着信シーケンスを示す図である。
【図１０】図１０は、現行の３ＧＮＷの切断シーケンスを示す図である。
【図１１】図１１は、本発明の実施例における３ＧＮＷの切断シーケンスを示す図である。
【図１２】図１２は、本発明の実施例におけるＣＡＢＳの構成例を示すブロック図である。
【図１３】図１３は、本発明の実施例における着信側ＲＮＳ(Ｄ−ＲＮＳ)による処理を示すフローチャートである。
【図１４】図１４は、本発明の実施例における発信側ＭＳＣ(Ｓ−ＭＳＣ)による処理を示すフローチャートである。
【図１５】図１５は、本発明の実施例における発信側ＭＳＣ(Ｓ−ＭＳＣ)による処理を示すフローチャートである。
【図１６】図１６は、本発明の実施例における着信側ＭＳＣ(Ｄ−ＭＳＣ)による処理を示すフローチャートである。
【図１７】図１７は、本発明の実施例における発信側ＣＡＢＳ(Ｓ−ＣＡＢＳ)及び着信側(Ｄ−ＣＡＢＳ)による処理を示すフローチャートである。
【図１８】図１８は、本発明の実施例におけるＲＮＳの構成例を示すブロック図である。
【図１９】図１９は、本発明の実施例におけるＭＳＣの構成例を示すブロック図である。
【符号の説明】
【０２６２】
１０・・・ＣＡＢＳ
１１・・・無線処理部
１２・・・多重／分離部
１３・・・取り込み／挿入部
１４・・・ベアラセレクタ
１５・・・ＩＰ多重／分離部
１６・・・暗号処理部
１７・・・制御部(ＣＮＴ部；セッション確立／切断部含む)
３０・・・ＲＮＳ
４２，５６・・・ＣＮＴ部
５０・・・ＭＳＣ
【特許請求の範囲】
【請求項１】
携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して収容された基
地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立システムであって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信させる場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定する判定手段と、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する確立手段とを含む携帯電話端末間のデータ伝送路確立システム。
【請求項２】
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されていない場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１記載の携帯電話端末間のデータ伝送路確立システム。
【請求項３】
発信端末と着信先端末との少なくとも一方がＩＰネットワークを介して前記携帯電話ネットワークに接続されていない基地局の配下に属する場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１又は２記載の携帯電話端末間のデータ伝送路確立システム。
【請求項４】
発信側基地局制御装置となる第１基地局制御装置と、着信側基地局制御装置となる第２基地局制御装置と、前記第１基地局制御装置と前記第２基地局制御装置とを接続する少なくとも１つの交換機とを有する携帯電話ネットワークを含むネットワークシステムであって、
前記第１基地局制御装置は、ＩＰ(Internet Protocol)ネットワークを介して接続され
た発信側基地局から、発信端末としての携帯電話端末の発信要求を受信した場合に、この発信要求に前記発信側基地局が接続されるＩＰネットワークの識別情報と前記発信側基地局のＩＰアドレスとを付加し、
前記第２基地局制御装置は、前記少なくとも１つの交換機を介して前記発信要求を受け取り、この発信要求を自装置にＩＰネットワークを介して接続された着信側基地局を通じて着信先端末としての携帯電話端末に送信する場合に、前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致するかを判断し、
ＩＰネットワークの識別情報が一致する場合には、前記第２基地局制御装置が前記発信要求に含まれた前記発信側基地局のＩＰアドレスを前記着信側基地局に通知するとともに、前記着信側基地局のＩＰアドレスを前記発信側基地局に通知し、
前記第１及び第２基地局制御装置は、前記発信側基地局及び前記着信側基地局に指示を与えて、前記発信側基地局と前記着信側基地局とが前記携帯電話ネットワークを経由することなく同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立させる
ネットワークシステム。
【請求項５】
前記第１基地局制御装置は、発信要求に、前記識別情報と、前記ＩＰアドレスと、前記発信側基地局と前記着信側基地局との間で確立すべきデータ伝送路の識別情報とを付加す
る
請求項４記載のネットワークシステム。
【請求項６】
前記第１基地局制御装置，前記少なくとも１つの交換機は、前記発信要求の受信を契機に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間にデータ通信路を確立し、
前記少なくとも１つの交換機は、前記着信先端末の呼び出し中に、前記データ通信路を用いて呼び出し音を前記発信側基地局に送信し、
前記発信側基地局は、前記データ通信路を介して前記受信される前記呼び出し音を前記発信端末に送信する
請求項４又は５記載のネットワークシステム。
【請求項７】
前記少なくとも１つの交換機及び前記第１基地局制御装置は、前記発信側基地局と前記着信側基地局との間に前記データ伝送路が確立され、且つ前記着信先端末が呼び出しに応答した場合に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間に確立されたデータ通信路を削除する
請求項６記載のネットワークシステム。
【請求項８】
携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して接続される基
地局であって、
発信端末としての携帯電話端末からの発信要求を受信する受信部と、
前記発信要求を前記ＩＰネットワークを介して携帯電話ネットワークへ送信する送信部と、
前記発信要求が前記ＩＰネットワークと同一のＩＰネットワークを介して前記携帯電話ネットワークに接続された異なる基地局を通じて着信先端末としての携帯電話端末に着信する場合に、前記異なる基地局のＩＰアドレスを前記携帯電話ネットワーク又は前記異なる基地局から受け取り、このＩＰアドレスを用いて、前記異なる基地局との間で、前記携帯電話ネットワークを経由することなく前記基地局自身と前記異なる基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立するデータ伝送路確立／切断部と
を含む基地局。
【請求項９】
前記基地局と前記発信端末との間には、前記発信端末との間で通信されるデータを伝送するためのデータ通信路が確立され、
前記データ通信路を伝送されるデータは、前記発信端末と前記携帯電話ネットワークとの間で決定された暗号で暗号化され、
前記データ通信路からの暗号化されたデータを復号し、且つ前記データ通信路へ送信すべきデータを前記暗号で暗号化する暗号化処理部と、
データが前記暗号処理部を通過する第１ルートと、
データが前記暗号処理部を通過しない第２ルートと、
前記発信端末と前記着信先端末との間を前記携帯電話ネットワークを介して伝送されるデータを前記第２のルートに接続し、前記発信端末と前記着信先端末との間を前記データ伝送路を介して伝送されるデータを前記第１のルートに接続する接続部と、
前記データ伝送路の確立／切断に応じて、前記接続部の接続先のルートを制御する接続制御部と
をさらに含む請求項８記載の基地局。
【請求項１０】
携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して収容された基
地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立方法であって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、
この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信される場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定し、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する
ことを含む携帯電話端末間のデータ伝送路確立方法。
【請求項１】
携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して収容された基
地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立システムであって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信させる場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定する判定手段と、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する確立手段とを含む携帯電話端末間のデータ伝送路確立システム。
【請求項２】
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されていない場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１記載の携帯電話端末間のデータ伝送路確立システム。
【請求項３】
発信端末と着信先端末との少なくとも一方がＩＰネットワークを介して前記携帯電話ネットワークに接続されていない基地局の配下に属する場合には、前記携帯電話ネットワークを経由する前記発信端末と前記着信先端末との間のデータ伝送路を確立する
請求項１又は２記載の携帯電話端末間のデータ伝送路確立システム。
【請求項４】
発信側基地局制御装置となる第１基地局制御装置と、着信側基地局制御装置となる第２基地局制御装置と、前記第１基地局制御装置と前記第２基地局制御装置とを接続する少なくとも１つの交換機とを有する携帯電話ネットワークを含むネットワークシステムであって、
前記第１基地局制御装置は、ＩＰ(Internet Protocol)ネットワークを介して接続され
た発信側基地局から、発信端末としての携帯電話端末の発信要求を受信した場合に、この発信要求に前記発信側基地局が接続されるＩＰネットワークの識別情報と前記発信側基地局のＩＰアドレスとを付加し、
前記第２基地局制御装置は、前記少なくとも１つの交換機を介して前記発信要求を受け取り、この発信要求を自装置にＩＰネットワークを介して接続された着信側基地局を通じて着信先端末としての携帯電話端末に送信する場合に、前記発信要求に含まれたＩＰネットワークの識別情報と前記着信側基地局が接続されたＩＰネットワークの識別情報とが一致するかを判断し、
ＩＰネットワークの識別情報が一致する場合には、前記第２基地局制御装置が前記発信要求に含まれた前記発信側基地局のＩＰアドレスを前記着信側基地局に通知するとともに、前記着信側基地局のＩＰアドレスを前記発信側基地局に通知し、
前記第１及び第２基地局制御装置は、前記発信側基地局及び前記着信側基地局に指示を与えて、前記発信側基地局と前記着信側基地局とが前記携帯電話ネットワークを経由することなく同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立させる
ネットワークシステム。
【請求項５】
前記第１基地局制御装置は、発信要求に、前記識別情報と、前記ＩＰアドレスと、前記発信側基地局と前記着信側基地局との間で確立すべきデータ伝送路の識別情報とを付加す
る
請求項４記載のネットワークシステム。
【請求項６】
前記第１基地局制御装置，前記少なくとも１つの交換機は、前記発信要求の受信を契機に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間にデータ通信路を確立し、
前記少なくとも１つの交換機は、前記着信先端末の呼び出し中に、前記データ通信路を用いて呼び出し音を前記発信側基地局に送信し、
前記発信側基地局は、前記データ通信路を介して前記受信される前記呼び出し音を前記発信端末に送信する
請求項４又は５記載のネットワークシステム。
【請求項７】
前記少なくとも１つの交換機及び前記第１基地局制御装置は、前記発信側基地局と前記着信側基地局との間に前記データ伝送路が確立され、且つ前記着信先端末が呼び出しに応答した場合に、前記第１基地局制御装置と前記発信側基地局との間、及び前記第１基地局制御装置と前記交換機との間に確立されたデータ通信路を削除する
請求項６記載のネットワークシステム。
【請求項８】
携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して接続される基
地局であって、
発信端末としての携帯電話端末からの発信要求を受信する受信部と、
前記発信要求を前記ＩＰネットワークを介して携帯電話ネットワークへ送信する送信部と、
前記発信要求が前記ＩＰネットワークと同一のＩＰネットワークを介して前記携帯電話ネットワークに接続された異なる基地局を通じて着信先端末としての携帯電話端末に着信する場合に、前記異なる基地局のＩＰアドレスを前記携帯電話ネットワーク又は前記異なる基地局から受け取り、このＩＰアドレスを用いて、前記異なる基地局との間で、前記携帯電話ネットワークを経由することなく前記基地局自身と前記異なる基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立するデータ伝送路確立／切断部と
を含む基地局。
【請求項９】
前記基地局と前記発信端末との間には、前記発信端末との間で通信されるデータを伝送するためのデータ通信路が確立され、
前記データ通信路を伝送されるデータは、前記発信端末と前記携帯電話ネットワークとの間で決定された暗号で暗号化され、
前記データ通信路からの暗号化されたデータを復号し、且つ前記データ通信路へ送信すべきデータを前記暗号で暗号化する暗号化処理部と、
データが前記暗号処理部を通過する第１ルートと、
データが前記暗号処理部を通過しない第２ルートと、
前記発信端末と前記着信先端末との間を前記携帯電話ネットワークを介して伝送されるデータを前記第２のルートに接続し、前記発信端末と前記着信先端末との間を前記データ伝送路を介して伝送されるデータを前記第１のルートに接続する接続部と、
前記データ伝送路の確立／切断に応じて、前記接続部の接続先のルートを制御する接続制御部と
をさらに含む請求項８記載の基地局。
【請求項１０】
携帯電話ネットワークにＩＰ(Internet Protocol)ネットワークを介して収容された基
地局を含むネットワークシステムにおける携帯電話端末間のデータ伝送路確立方法であって、
発信端末としての携帯電話端末からの発信要求を発信側基地局から携帯電話ネットワークへ送信し、
この発信要求を携帯電話ネットワークから着信側基地局を通じて着信先端末としての携帯電話端末に着信される場合に、前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されているかを判定し、
前記発信側基地局と前記着信側基地局との双方が同一のＩＰネットワークを介して前記携帯電話ネットワークに接続されている場合に、前記携帯電話ネットワークを経由することなく前記発信側基地局と前記着信側基地局とが前記同一のＩＰネットワークを介して直接接続された前記発信端末と前記着信先端末との間のデータ伝送路を確立する
ことを含む携帯電話端末間のデータ伝送路確立方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２００６−１２１１８０（Ｐ２００６−１２１１８０Ａ）
【公開日】平成１８年５月１１日（２００６．５．１１）
【国際特許分類】
【出願番号】特願２００４−３０４２７９（Ｐ２００４−３０４２７９）
【出願日】平成１６年１０月１９日（２００４．１０．１９）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成１８年５月１１日（２００６．５．１１）
【国際特許分類】
【出願日】平成１６年１０月１９日（２００４．１０．１９）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]