JP4010330B2 - プロトコル変換装置及び方法 - Google Patents
プロトコル変換装置及び方法 Download PDFInfo
- Publication number
- JP4010330B2 JP4010330B2 JP2005502828A JP2005502828A JP4010330B2 JP 4010330 B2 JP4010330 B2 JP 4010330B2 JP 2005502828 A JP2005502828 A JP 2005502828A JP 2005502828 A JP2005502828 A JP 2005502828A JP 4010330 B2 JP4010330 B2 JP 4010330B2
- Authority
- JP
- Japan
- Prior art keywords
- protocol conversion
- plane
- user data
- resource request
- iwf
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/02—Inter-networking arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/14—Multichannel or multilink protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/14—Backbone network devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/04—Interfaces between hierarchically different network devices
- H04W92/14—Interfaces between hierarchically different network devices between access point controllers and backbone network device
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
Description
本発明は、プロトコル変換装置及び方法に関し、特に、互いに異なる物理回線を利用する装置同士を接続する際に適用されるプロトコル変換装置及び方法に関する。
ＷＣＤＭＡ（Ｗｉｄｅｂａｎｄ ＣＤＭＡ）システムにおける無線インタフェースのプロトコルアーキテクチャには物理レイヤ（レイヤ１）と、データリンクレイヤ（レイヤ２）と、ネットワークレイヤ（レイヤ３）とがある。また、レイヤ２においては、制御信号を転送するシグナリングのためのＣプレーン（Ｃ−Ｐｌａｎｅ）と、ユーザ情報を転送するＵプレーン（Ｕ−Ｐｌａｎｅ）とがある。
異なる物理回線を利用する装置を接続する際には、ＩＷＦ（Ｉｎｔｅｒ Ｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ）装置がプロトコル変換装置として適用されている。従来のＩＷＦ装置は、その構成において上記のＣ−ＰｌａｎｅとＵ−Ｐｌａｎｅとに分離されていない（例えば、文献１（３ＧＰＰ ＴＲ２５．９３３ Ｖ５．２．０（２００２−０９））参照）。
このため、実際にＣ−ＰｌａｎｅとＵ−Ｐｌａｎｅとが分離された構成にすると、各プロトコルをどのように終端するか、リソース確保のためのパラメータをどのように取得するかというようなリソース確保の方法に問題が生じ、Ｕ−Ｐｌａｎｅが増減するといったスケーラビリティに富んだ構成をとることができない。リソース確保については、上記の文献１において何も記載されていない。
異なる物理回線を利用する装置を接続する際には、ＩＷＦ（Ｉｎｔｅｒ Ｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ）装置がプロトコル変換装置として適用されている。従来のＩＷＦ装置は、その構成において上記のＣ−ＰｌａｎｅとＵ−Ｐｌａｎｅとに分離されていない（例えば、文献１（３ＧＰＰ ＴＲ２５．９３３ Ｖ５．２．０（２００２−０９））参照）。
このため、実際にＣ−ＰｌａｎｅとＵ−Ｐｌａｎｅとが分離された構成にすると、各プロトコルをどのように終端するか、リソース確保のためのパラメータをどのように取得するかというようなリソース確保の方法に問題が生じ、Ｕ−Ｐｌａｎｅが増減するといったスケーラビリティに富んだ構成をとることができない。リソース確保については、上記の文献１において何も記載されていない。
本発明はこのような課題を解決するためになされたものであり、その目的は、スケーラビリティに富んだ構成をとることができるプロトコル変換装置及び方法を提供することにある。
このような目的を達成するために、本発明は、互いに異なる物理回線を利用する第１の装置と第２の装置との間に接続されるプロトコル変換装置であって、第１の装置と第２の装置との間のシグナリングを制御するＣプレーン装置と、第１の装置と第２の装置との間でのユーザデータの転送を制御するＵプレーン装置とを備えることを特徴とする。
本発明はまた、互いに異なる物理回線を利用する第１の装置と第２の装置との間を接続する際に適用されるプロトコル変換方法であって、Ｃプレーン装置で第１の装置と第２の装置との間のシグナリングを制御する第１のステップと、Ｃプレーン装置と独立に配設されたＵプレーン装置で第１の装置と第２の装置との間でのユーザデータの転送を制御する第２のステップとを備えることを特徴とする。
このような目的を達成するために、本発明は、互いに異なる物理回線を利用する第１の装置と第２の装置との間に接続されるプロトコル変換装置であって、第１の装置と第２の装置との間のシグナリングを制御するＣプレーン装置と、第１の装置と第２の装置との間でのユーザデータの転送を制御するＵプレーン装置とを備えることを特徴とする。
本発明はまた、互いに異なる物理回線を利用する第１の装置と第２の装置との間を接続する際に適用されるプロトコル変換方法であって、Ｃプレーン装置で第１の装置と第２の装置との間のシグナリングを制御する第１のステップと、Ｃプレーン装置と独立に配設されたＵプレーン装置で第１の装置と第２の装置との間でのユーザデータの転送を制御する第２のステップとを備えることを特徴とする。
図１は、第１の実施例によるＩＷＦ装置の構成を示すブロック図である。
図２は、図１のＩＷＦ−ｃ及びＩＷＦ−ｕの構成を示すブロック図であ。
図３は、第１の実施例におけるＣ−Ｐｌａｎｅのプロトコルスタックを示す図である。
図４は、第１の実施例によるＣＳ発呼時における動作を示すシーケンスチャートである。
図５は、第１の実施例によるＰＳ発呼時における動作を示すシーケンスチャートである。
図６は、図１のＩＷＦ−ｃの動作を示すフローチャートである。
図７は、図１のＩＷＦ−ｃの動作を示すフローチャートである。
図８は、図１のＩＷＦ−ｕの動作を示すフローチャートである。
図９は、図１のＩＷＦ−ｕの動作を示すフローチャートである。
図１０は、第２の実施例によるＩＷＦ装置の構成を示すブロック図である。
図１１は、図１０のＩＷＦ−ｃ及びＩＷＦ−ｕの構成を示すブロック図である。
図１２は、第２の実施例におけるＣ−Ｐｌａｎｅのプロトコルスタックを示す図である。
図１３は、第２の実施例によるＣＳ発呼時における動作を示すシーケンスチャートである。
図１４は、第２の実施例によるＰＳ発呼時における動作を示すシーケンスチャートである。
図１５は、図１０のＩＷＦ−ｕの動作を示すフローチャートである。
図２は、図１のＩＷＦ−ｃ及びＩＷＦ−ｕの構成を示すブロック図であ。
図３は、第１の実施例におけるＣ−Ｐｌａｎｅのプロトコルスタックを示す図である。
図４は、第１の実施例によるＣＳ発呼時における動作を示すシーケンスチャートである。
図５は、第１の実施例によるＰＳ発呼時における動作を示すシーケンスチャートである。
図６は、図１のＩＷＦ−ｃの動作を示すフローチャートである。
図７は、図１のＩＷＦ−ｃの動作を示すフローチャートである。
図８は、図１のＩＷＦ−ｕの動作を示すフローチャートである。
図９は、図１のＩＷＦ−ｕの動作を示すフローチャートである。
図１０は、第２の実施例によるＩＷＦ装置の構成を示すブロック図である。
図１１は、図１０のＩＷＦ−ｃ及びＩＷＦ−ｕの構成を示すブロック図である。
図１２は、第２の実施例におけるＣ−Ｐｌａｎｅのプロトコルスタックを示す図である。
図１３は、第２の実施例によるＣＳ発呼時における動作を示すシーケンスチャートである。
図１４は、第２の実施例によるＰＳ発呼時における動作を示すシーケンスチャートである。
図１５は、図１０のＩＷＦ−ｕの動作を示すフローチャートである。
次に、本発明の実施例について図面を参照して説明する。
第１の実施例
図１は本発明に係るプロトコル変換装置の第１の実施例によるＩＷＦ（Ｉｎｔｅｒ Ｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ）装置の構成を示すブロック図である。図１において、ＩＷＦ装置３は主にシグナリング制御を行うＩＷＦ−ｃ３１と、主にユーザデータの転送を行うＩＷＦ−ｕ３２，３３とから構成されている。ＩＷＦ−ｃ３１は制御信号を転送するシグナリングのためのＣプレーン（Ｃ−Ｐｌａｎｅ）に対応し、ＩＷＦ−ｕ３２，３３はユーザ情報を転送するＵプレーン（Ｕ−Ｐｌａｎｅ）に対応している。なお、シグナリングとは回線を接続するための処理のことであり、ユーザ情報とはシグナリングによって接続された回線を流れるパケットのことである。
ＩＷＦ装置３は、第１の装置としてのＭＳＣ（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ）４またはＳＧＳＮ［Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ］５と、第２の装置としてのＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：基地局制御装置）１との間に接続される。ＩＷＦ装置３とＭＳＣ４またはＳＧＳＮ５との間は、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔｓ） Ｒｅｌｅａｓｅ９９で定義されたＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ） Ｔｒａｎｓｐｏｒｔのプロトコルスタックである。また、ＩＷＦ装置３とＲＮＣ１との間は、３ＧＰＰ Ｒｅｌｅａｓｅ５で定義されたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｔｒａｎｓｐｏｒｔのプロトコルスタックである。これらはＩｕインタフェースとして、文献２（３ＧＰＰ ＴＳ２５．４１２ Ｖ５．１．０（２００２−０９））等に詳しく述べられている。
ＩＷＦ装置３のＩＷＦ−ｃ３１はシグナリングにおけるＡＴＭ ＴｒａｎｓｐｏｒｔのプロトコルスタックとＩＰ Ｔｒａｎｓｐｏｒｔのプロトコルスタックとの変換を行う。また、ＩＷＦ装置３のＩＷＦ−ｕ３２，３３はユーザ情報転送におけるＡＴＭ ＴｒａｎｓｐｏｒｔのプロトコルスタックとＩＰ Ｔｒａｎｓｐｏｒｔのプロトコルスタックとの変換を行う。
ＲＮＣ１は制御信号を送受信する制御信号送受信部［シグナリング制御装置］１１〜１３と、ユーザ情報を送受信するデータ送受信部２１〜２３とから構成されている。
図２は図１のＩＷＦ−ｃ３１及びＩＷＦ−ｕ３２の構成を示すブロック図であ。図２において、ＩＷＦ−ｃ３１はリソース管理部３１１と、プロトコル終端部３１２，３１４と、ＩＷＦ−ｕ３２とのインタフェース（ＩＦ）部３１３とから構成されている。ＩＷＦ−ｕ３２はスイッチ制御部３２１と、スイッチ３２２と、ＩＷＦ−ｃ３１とのインタフェース（ＩＦ）部３２３と、ＡＴＭ側のプロトコル終端部３２４〜３２６と、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）側のプロトコル終端部３２７〜３２９とから構成されている。
図３は本実施例におけるＣ−Ｐｌａｎｅのプロトコルスタックを示す図である。図３において、ＲＮＣ１はＤａｔａ ｌｉｎｋレイヤと、ＩＰレイヤと、ＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤと、Ｍ３ＵＡ［ＳＳ７（Ｓｉｇｎａｌｌｉｎｇ Ｓｙｓｔｅｍ Ｎｏ．７） ＭＴＰ３（Ｍｅｓｓａｇｅ Ｔｒａｎｓｆｅｒ Ｐａｒｔ ３） Ｕｓｅｒ Ａｄａｐｔａｔｉｏｎ］レイヤと、ＳＣＣＰ（Ｓｉｇｎａｌｌｉｎｇ Ｃｏｎｎｅｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐａｒｔ）レイヤと、ＲＡＮＡＰ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）レイヤとからなる。
ＩＷＦ−ｃ３１はＲＮＣ１側がＤａｔａ ｌｉｎｋレイヤと、ＩＰレイヤと、ＳＣＴＰレイヤと、Ｍ３ＵＡレイヤと、ＳＣＣＰレイヤと、ＲＡＮＡＰレイヤとからなり、ＭＳＣ４及びＳＧＳＮ５側がＡＴＭレイヤと、ＳＡＡＬ−ＮＮＩ（Ｓｉｇｎａｌｌｉｎｇ ＡＴＭ Ａｄａｐｔａｔｉｏｎ Ｌａｙｅｒ−Ｎｅｔｗｏｒｋ Ｎｏｄｅ Ｉｎｔｅｒｆａｃｅ）レイヤと、ＭＴＰ３−Ｂ（Ｍｅｓｓａｇｅ Ｔｒａｎｓｆｅｒ Ｐａｒｔ ３−Ｂ）レイヤと、ＳＣＣＰレイヤと、ＲＡＮＡＰレイヤとからなる。
ＭＳＣ４及びＳＧＳＮ５はＡＴＭレイヤと、ＳＡＡＬ−ＮＮＩレイヤと、ＭＴＰ３−Ｂレイヤと、ＳＣＣＰレイヤと、ＲＡＮＡＰレイヤとからなる。
この場合、ＳＣＣＰレイヤはＩＷＦ装置３で一端終端する。これに対し、最上位のシグナリング・プロトコルであるＲＡＮＡＰレイヤは、一部判別する必要があるものの、ＲＮＣ１とＭＳＣ４またはＳＧＳＮ５との間で終端することになる。一部のメッセージについてはリソースアドレスについての内容変更を行う。
ＳＣＣＰレイヤがＩＷＦ装置３で一端終端する結果、１つの呼に対してＳＣＣＰコネクションがＲＮＣ１−ＩＷＦ間とＩＷＦ−ＭＳＣ４またはＳＧＳＮ５間とに二本設定されることになる。ＳＣＣＰレイヤは、その二本のＳＣＣＰコネクションを対応付けるＳＣＣＰ対応表をＩＷＦ装置３のリソース管理部３１１に持っている。このため、ＩＷＦ装置３でＳＣＣＰを一端終端して呼情報を認識し、適切な宛先へ再度送信することで、ＲＮＣ１内の複数ある制御信号送受信部１１〜１３の中から適切な送受信部を選択することが可能となる。
なお、ここではＣＳ（Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ）呼について詳細に説明したが、ＭＳＣ４の代わりにＳＧＳＮ５を用いたＰＳ（Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ）呼についても、上記と同じように説明することができる。ＣＳ呼はＭＳＣ４を利用した音声回線呼、ＰＳ呼はＳＧＳＮ５を利用したパケット通信呼である。
図４は本実施例によるＣＳ発呼時における動作を示すシーケンスチャートである。この図４を参照して、本実施例によるＣＳ発呼時における各装置のリソース確保までの動作について説明する。
端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）が、「Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ」（図４のａ１）をＲＮＣ１に送信することで、発呼シーケンスが開始される。ＲＮＣ１は「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」をＭＳＣ４に向けて送信する際、ＲＮＣ１とＩＷＦ−ｃ３１との間で、及びＩＷＦ−ｃ３１とＭＳＣ４との間でそれぞれＳＣＣＰコネクションが設定される（図４のａ２，ａ３）。このとき、ＲＮＣ１とＩＷＦ−ｃ３１との間のＳＣＣＰコネクションをＳＣＣＰコネクション＃１、ＩＷＦ−ｃ３１とＭＳＣ４との間のＳＣＣＰコネクションをＳＣＣＰコネクション＃２とする。
ＩＷＦ−ｃ３１ではこの「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」を中継するのみで、ＳＣＣＰをＳＣＣＰコネクション＃１からＳＣＣＰコネクション＃２に載せ変えて、ＭＳＣ４へ送信する（図４のａ４，ａ５）。ＩＷＦ−ｃ３１のリソース管理部３１１では、ＳＣＣＰコネクション＃１とＳＣＣＰコネクション＃２とが同じ呼で利用していることを認識するＳＣＣＰ対応表が作成される。なお、Ｐａｇｉｎｇ等のＭＳＣ４側から最初にＳＣＣＰコネクションが設定される場合、ＩＷＦ−ｃ３１が制御信号送受信部を任意に選択する機能を持つ。
呼利用中のマルチコールでは、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）等の端末固有の情報によって、ＩＷＦ−ｃ３１内でその端末が利用中かどうかを判断し、同じ制御信号送受信部を利用可能にする手段も持つ。
認証、秘匿を行った後（図４のａ６）、ＭＳＣ４はユーザデータ用のリソースを確保し（図４のａ７）、無線リソースを確保するための「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」（第１のリソース要求）（図４のａ８）をＲＮＣ１へ送信する。ＩＷＦ−ｃ３１では、このメッセージを受信したとき、ＩＷＦ−ｕ３２，３３のリソースの確保を行う必要があると判断する。以下では、ＩＷＦ−ｕ３２のリソースの確保を行う場合について説明する。
「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」には、ＭＳＣ４でユーザデータ転送に利用されるアドレス等の第１のパラメータが含まれている。ＩＷＦ−ｃ３１のリソース管理部３１１は、この第１のパラメータを「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」より取得し、リソース要求（第２のリソース要求）に付加し、ＩＷＦ−ｕ３２に送信する（図４のａ９）。
ＩＷＦ−ｕ３２のスイッチ制御部３２１は、受信されたリソース要求より第１のパラメータを取得し、ユーザデータ用のリソースを確保し（図４のａ１０）、リソースを確保した旨の通知をＩＷＦ−ｃ３１に送信する（図４のａ１１）。この通知には、ＩＷＦ−ｕ３２でユーザデータ転送に利用されるＲＮＣ１側のアドレス等の第２のパラメータが付加されている。
ＩＷＦ−ｃ３１のリソース管理部３１１は、受信された通知より第２のパラメータを取得する。そして、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」内のユーザデータ転送先アドレスであるＭＳＣ４のアドレスをＩＷＦ−ｕ３２のアドレスに書換え、書換え後の「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」をＲＮＣ１内の適切な制御信号送受信部へ転送する（図４のａ１２）。この際の適切な制御信号送受信部の選択にはＳＣＣＰ対応表を利用する。
その後、ＲＮＣ１はユーザデータ用のリソースを確保する（図４のａ１３）。そして、ＲＮＣ１はＵ−Ｐｌａｎｅの設定を行うために、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」で通知されたＩＷＦ−ｕ３２のアドレスへ向けて「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」を送信する（図４のａ１４）。この通知にはＲＮＣ１のユーザデータ用のアドレスが格納されている。この通知の送信には、ＩＰＡＬＣＡＰ（ＩＰ Ａｃｃｅｓｓ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を利用することができる。
この通知を受け取ったＩＷＦ−ｕ３２は、ＭＳＣ４へ向けてＡＬＣＡＰ（Ａｃｃｅｓｓ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）で「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」を送信する（図４のａ１５）。このＭＳＣ４の宛先には、事前にＩＷＦ−ｃ３１から通知されているＭＳＣ４のアドレスを利用する。
ＭＳＣ４からＩＷＦ−ｕ３２へ、ＩＷＦ−ｕ３２からＲＮＣ１へ、確認のメッセージとして「Ｅｓｔａｂｌｉｓｈ Ｃｏｎｆｉｒｍ」を送信する（図４のａ１６，ａ１７）。その後、ＵＥとＲＮＣ１との間で無線リソースを確保する（図４のａ１８）。無線リソースが確保されると、ＲＮＣ１からＩＷＦ−ｕ３２へ、ＩＷＦ−ｕ３２からＭＳＣ４へ「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」を送信することによって、ユーザデータ転送用のパス設定が完了する（図４のａ１９，ａ２０）。
その後、設定されたパスを用いてユーザデータの転送が行われる。
なお、ＩＷＦ−ｕ３３のリソースの確保を行う場合についても、同様の処理が行われる。
図５は本実施例によるＰＳ発呼時における各装置のリソース確保までの動作を示すシーケンスチャートである。この図５を参照して、本実施例によるＰＳ発呼時における各装置のリソース確保までの動作について説明する。
図５を参照すると、ＰＳ発呼時における各装置のリソース確保までの動作は、上述したＣＳ発呼時における各装置のリソース確保までの動作とほとんど同じである。すなわち、図５のｂ１〜ｂ１３の動作は図４のａ１〜ａ１３と同様である。しかし、ＰＳ呼ではＡＬＣＡＰやＩＰＡＬＣＡＰを利用しないため、最後の「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」が異なっている。
ＩＷＦ−ｃ３１では、ＵＥとＲＮＣ１との間で無線リソースが確保された後（図５のｂ１４）、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」によって、ユーザ転送用のパス設定が完了すると（図５のｂ１５）、ＩＷＦ−ｃ３１は「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」よりＲＮＣ１のユーザデータ用のアドレスを取得し、ＩＷＦ−ｕ３２に通知する（図５のｂ１６）。その応答として、ＩＷＦ−ｕ３２はＩＷＦ−ｃ３１にＩＷＦ−ｕ３２のＭＳＣ４側のアドレスを通知する（図５のｂ１７）。ＩＷＦ−ｃ３１はこのアドレスを取得し、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」内のユーザデータ転送先アドレスであるＲＮＣ１のアドレスをＩＷＦ−ｕ３２のアドレスに書換え、書換え後の「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」をＭＳＣ４へ送信する（図５のｂ１８）。
この際、ＳＣＣＰコネクションはＳＣＣＰ対応表を利用する。ＳＣＣＰにはそれぞれのリンクが確認できるように、リンク番号が付与されている。ＳＣＣＰ対応表にはそのリンク番号毎に、ＭＳＣ４またはＳＧＳＮ５向けの何番とＲＮＣ１向けの何番とが対応しているという情報が格納されている。
その後の処理は、上述したＣＳ発呼時の処理と同様である。
なお、ＩＷＦ−ｕ３３のリソースの確保を行う場合についても、同様の処理が行われる。
上述した図４及び図５に示す動作では、リソースを確保するときのシーケンスについて詳細に説明したが、リソースを解放するときにも上記と同様の手順で行うことができる。
図６及び図７は図１のＩＷＦ−ｃ３１の動作を示すフローチャートである。これら図６及び図７を参照してＩＷＦ装置３内のＩＷＦ−ｃ３１の動作について説明する。
ＩＷＦ−ｃ３１はシグナリングを受信したとき（図６ステップＳ１）、ＲＮＣ１側から受信したシグナリングか、ＭＳＣ４側から受信したシグナリングかの判別を行う（図６ステップＳ２）。
ＩＷＦ−ｃ３１はＲＮＣ１側から受信したＲＡＮＡＰシグナリングの場合、ＰＳ呼のときでリソース確保応答を示す「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」のときだけ（図７ステップＳ１４）、ＩＷＦ−ｕ３２，３３にＲＮＣアドレスを通知する（図７ステップＳ１５）。
ＩＷＦ−ｃ３１はＩＷＦ−ｕ３２，３３からの応答を待ってＩＷＦ−ｕ（ＲＮＣ１側）アドレスを取得し（図７ステップＳ１６）、シグナリング内のユーザデータ用ＲＮＣアドレスをＩＷＦ−ｕ３２，３３のアドレスに書換え（図７ステップＳ１７）、ＲＡＮＡＰシグナリングをＭＳＣ４へ送信する（図７ステップＳ１８）。ＩＷＦ−ｃ３１は上記以外の場合、ＲＡＮＡＰシグナリングをそのままＭＳＣ４へ送信する（図７ステップＳ１８）。
ＩＷＦ−ｃ３１はＭＳＣ４側からＲＡＮＡＰシグナリングを受信すると（図６ステップＳ３）、まずＰａｇｉｎｇ等のＭＳＣ４からの最初のＲＡＮＡＰシグナリングで、制御信号送受信部の番号とＳＣＣＰコネクションとのＳＣＣＰ対応表ができていない場合（図６ステップＳ４）、制御信号送受信部を任意に選択し、ＲＡＮＡＰシグナリングをそのまま制御信号送受信部へ送信する（図６ステップＳ１１〜Ｓ１３）。
ＳＣＣＰコネクションと制御信号送受信部の番号との対応付けができていない場合には、ＳＣＣＰ対応表を作成する（図６ステップＳ１２）。このＳＣＣＰ対応表は、呼の終了（ＳＣＣＰコネクションの終了）と同時に無くなる。
次に、ＩＷＦ−ｃ３１はそのＲＡＮＡＰシグナリングがユーザデータ用のリソースを確保する「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」かどうかを判断する（図６ステップＳ６）。ＩＷＦ−ｃ３１はユーザデータ用のリソースを確保するリクエストである場合、ＩＷＦ−ｕ３２，３３とシグナリングのやりとりを行い、ＩＷＦ−ｕ３２，３３のリソースを確保した後で、ＲＡＮＡＰシグナリングのユーザデータ転送先であるＭＳＣ４のアドレスからＩＷＦ−ｕ３２，３３のアドレスに書換え（図６ステップＳ７〜Ｓ９）、制御信号送受信部の宛先をＳＣＣＰ対応表から取得してその制御信号送受信部へシグナリングを送信する（図６ステップＳ１０）。
ＩＷＦ−ｃ３１はユーザデータ用のリソースを確保するリクエストでない場合、ＲＡＮＡＰには何も手を加えず、そのまま適切な制御信号送受信部へＲＡＮＡＰシグナリングを送信する（図６ステップＳ１０）。
図８及び図９は図１のＩＷＦ−ｕ３２，３３の動作を示すフローチャートである。これら図８及び図９を参照してＩＷＦ−ｕ３２，３３の動作について説明する。
ＩＷＦ−ｕ３２，３３はＩＷＦ−ｃ３１からリソース確保のシグナリングを受信した場合（図８ステップＳ２３、図９ステップＳ２８）、ＩＷＦ−ｕ３２，３３内のリソースを確保し（図９ステップＳ２９）、そのシグナリングで通知されたＭＳＣ４のアドレスをそのＩＷＦ−ｕアドレスと対応付けて記憶し、ＩＷＦ−ｃ３１へそのＩＷＦ−ｕアドレスを通知する（図９ステップＳ３０）。
ＩＷＦ−ｕ３２，３３はＲＮＣ１側からシグナリングを受信した場合（図８ステップＳ２４）、そのＩＰＡＬＣＡＰシグナリングをＡＬＣＡＰに載せかえて、対応付けられたＭＳＣアドレスへ向けて送信する（図８ステップＳ２７）。
ＩＷＦ−ｕ３２，３３はＭＳＣ４側からシグナリングを受信した場合（図８ステップＳ２５）、そのＡＬＣＡＰシグナリングをＩＰＡＬＣＡＰに載せかえて、対応付けされたＲＮＣアドレスへ向けて送信する（図８ステップＳ２６）。
上述したように、ＩＷＦ−ｕ３２，３３では、ユーザデータの流れも、ＲＮＣ１側やＭＳＣ４側からシグナリングを受信するときと同様に、プロトコル変換を行う。
このように、本実施例では、ＩＷＦ装置３をＣ−Ｐｌａｎｅ装置（ＩＷＦ−ｃ３１）とＵ−Ｐｌａｎｅ装置（ＩＷＦ−ｕ３２，３３）とに分離したので、ＩＷＦ装置３がスケーラビリティに富んだ構成をとることができる。具体的には、ＩＷＦ−ｕ３２，３３の数の増減時に、ＩＷＦ−ｃ３１が影響を受けない。
また、本実施例では、ＩＷＦ装置３で呼毎のＳＣＣＰを終端しているため、ＲＮＣ１内に制御信号送受信部１１〜１３を複数設置することが可能になる。従来、ＲＮＣ１としては一つである必要がある。
さらに、本実施例では、ＩＷＦ装置３をＣ−Ｐｌａｎｅ装置（ＩＷＦ−ｃ３１）とＵ−Ｐｌａｎｅ装置（ＩＷＦ−ｕ３２，３３）とに分離したときに、Ｃ−Ｐｌａｎｅ装置（ＩＷＦ−ｃ３１）からの要求に応答してＵ−Ｐｌａｎｅ装置（ＩＷＦ−ｕ３２，３３）でリソースの確保を行うことによって、最短経路を利用するＩＰ ｔｒａｆｆｉｃの負荷分散を行うことができる。
第２の実施例
図１０は本発明に係るプロトコル変換装置の第２の実施例によるＩＷＦ装置の構成を示すブロック図である。図１０において、本実施例はＩＷＦ装置７内においてＩＷＦ−ｃ３１とＩＷＦ−ｕ７１，７２との間で信号の送受信を行わず、ＲＮＣ６の制御信号送受信部６１〜６３からＩＷＦ−ｕ７１，７２を制御する点が、上述した第１の実施例と異なる。同一構成要素には第１の実施例と同一符号を付してある。
第１の実施例ではＩＷＦ−ｃ３１でＲＡＮＡＰシグナリングを認識する必要があるので、全てのシグナリングをデコードし、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」であるかどうかを認識しなければならない。これに対し、本実施例では、ＩＷＦ−ｕ７１，７２のリソース管理をＲＮＣ６内の制御信号送受信部６１〜６３で行うことで、ＩＷＦ−ｃ３１ではＲＡＮＡＰシグナリングをデコードする必要が無くなるため、ＩＷＦ−ｃ３１の処理を軽くすることができる。
図１１は図１０のＩＷＦ−ｃ３１及びＩＷＦ−ｕ７１の構成を示すブロック図である。図１１において、ＩＷＦ−ｃ３１はプロトコル終端部３１２，３１４と、信号転送部３１５とから構成されている。ＩＷＦ−ｕ７１はリソース管理部７１１と、スイッチ３２２と、ＡＴＭ側のプロトコル終端部３２４〜３２６と、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）側のプロトコル終端部３２７〜３２９，７１２とから構成されている。
図１２は本実施例におけるＣ−Ｐｌａｎｅのプロトコルスタックを示す図である。図１２において、本実施例は、プロトコルスタックでＳＣＣＰレイヤとＲＡＮＡＰレイヤとをＩＷＦ−ｃ３１で終端しない点が、上述した第１の実施例と異なっており、他の部分は第１の実施例と同様である。
図１３は本実施例によるＣＳ発呼時における動作を示すシーケンスチャートである。この図１３を参照して、本実施例によるＣＳ発呼時における各装置のリソース確保までの動作について説明する。
図１３において、本実施例では、ＳＣＣＰコネクションをＲＮＣ６とＭＳＣ４との間で終端し、この終端にＩＷＦ−ｃ３１は関与しない。しかしながら、ＳＣＣＰコネクション内にＲＮＣ６で利用されている制御信号送受信部を識別するフラグを添付しているので、ＩＷＦ−ｃ３１ではそのフラグを判別することによって、適切な制御信号送受信部を選択することが可能になっている。
ＭＳＣ４から送信された「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」（第４のリソース要求）は、ＩＷＦ−ｃ３１に関知されずＲＮＣ６まで届く（図１３のｃ６）。この「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」を受信したＲＮＣ６は、ユーザデータ用のリソースを確保する（図１３のｃ７）。リソースを確保したＲＮＣ６は、ＩＷＦ−ｕ７１のリソースを確保するリソース要求（第３のリソース要求）をＩＷＦ−ｕ７１に送信する（図１３のｃ８）。このリソース要求にＭＳＣ４のアドレスとともにＲＮＣ６のアドレスを付加することで、このリソース要求がＩＰＡＬＣＡＰの「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」の代わりにもなる。
ＩＷＦ−ｕ７１はユーザデータ転送先であるＭＳＣ４のアドレスを取得し、ユーザデータ用のリソースを確保する（図１３のｃ９）。その後、ＡＬＣＡＰでＭＳＣ４に「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」を送信する（図１３のｃ１０）。これに対してＡＬＣＡＰでＩＷＦ−ｕ７１に返信される「Ｅｓｔａｂｌｉｓｈ Ｃｏｎｆｉｒｍ」を待って（図１３のｃ１１）、ＩＷＦ−ｕ７１はＲＮＣ６へＩＷＦ−ｕ７１のアドレスを通知する（図１３のｃ１２）。
その後の処理は、上述した第１の実施例と同様である。
なお、ＩＷＦ−ｕ７２のリソースの確保を行う場合についても、同様の処理が行われる。
図１４は本実施例によるＰＳ発呼時における動作を示すシーケンスチャートである。この図１４を参照して、本実施例によるＰＳ発呼時における各装置のリソース確保までの動作について説明する。
ＰＳ呼ではＡＬＣＡＰ「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」を利用しないため、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」で（図１４のｄ１２）、ＣＳ呼とＰＳ呼とで異なる動きをしなくてもよくなる。
本実施例では、ＩＷＦ−ｃ３１がリソース確保を行わず、ＲＮＣ６内の制御信号送受信部６１〜６３がリソース確保を行うことによって、ＩＷＦ−ｃ３１では図６及び図７に示す判別ステップが不要となり、下位レイヤのプロトコル変換を行うのみの動作となる。
図１５は図１０のＩＷＦ−ｕ７１の動作を示すフローチャートである。図１５において、ステップＳ４１〜Ｓ４８の処理は、図８及び図９に示す処理と同様である。ただし、ステップＳ２３，Ｓ２８の判断式がなく、全体として判断式が少なくなっていることから、ＩＷＦ−ｕ７１でも処理を軽くすることが可能になっている。
このように、本実施例では、ＲＮＣ６内の制御信号送受信部６１〜６３がＩＷＦ−ｕ７１，７２のリソース確保のためのシグナリングを制御しているので、ＩＷＦ−ｃ３１でＲＡＮＡＰシグナリングをデコードしなくても良く、ＳＣＣＰコネクションも終端しなくても良いという効果が得られる。また、ＩＷＦ−ｃ３１とＩＷＦ−ｕ７１，７２との関係が無くなることから、実装にもフレキシビリティが確保され、ＩＷＦ−ｕ７１，７２をＲＮＣ６内に実装することも容易となる。
以上説明したように、上述した実施例によるＩＷＦ装置３，７はシグナリングを制御するＣプレーン装置と、ユーザデータを制御するＵプレーン装置とに分離しているので、スケーラビリティに富んだ構成をとることができる。さらに、ＲＮＣ１，６もまた、スケーラビリティに富んだ構成をとることができる。なお、上述したＩＷＦ装置３，７は、異なる物理回線の間に接続される場合ばかりではなく、同じ物理回線で中間のプロトコルが異なる場合でも適用可能である。
第１の実施例
図１は本発明に係るプロトコル変換装置の第１の実施例によるＩＷＦ（Ｉｎｔｅｒ Ｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ）装置の構成を示すブロック図である。図１において、ＩＷＦ装置３は主にシグナリング制御を行うＩＷＦ−ｃ３１と、主にユーザデータの転送を行うＩＷＦ−ｕ３２，３３とから構成されている。ＩＷＦ−ｃ３１は制御信号を転送するシグナリングのためのＣプレーン（Ｃ−Ｐｌａｎｅ）に対応し、ＩＷＦ−ｕ３２，３３はユーザ情報を転送するＵプレーン（Ｕ−Ｐｌａｎｅ）に対応している。なお、シグナリングとは回線を接続するための処理のことであり、ユーザ情報とはシグナリングによって接続された回線を流れるパケットのことである。
ＩＷＦ装置３は、第１の装置としてのＭＳＣ（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ）４またはＳＧＳＮ［Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ］５と、第２の装置としてのＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：基地局制御装置）１との間に接続される。ＩＷＦ装置３とＭＳＣ４またはＳＧＳＮ５との間は、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔｓ） Ｒｅｌｅａｓｅ９９で定義されたＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ） Ｔｒａｎｓｐｏｒｔのプロトコルスタックである。また、ＩＷＦ装置３とＲＮＣ１との間は、３ＧＰＰ Ｒｅｌｅａｓｅ５で定義されたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｔｒａｎｓｐｏｒｔのプロトコルスタックである。これらはＩｕインタフェースとして、文献２（３ＧＰＰ ＴＳ２５．４１２ Ｖ５．１．０（２００２−０９））等に詳しく述べられている。
ＩＷＦ装置３のＩＷＦ−ｃ３１はシグナリングにおけるＡＴＭ ＴｒａｎｓｐｏｒｔのプロトコルスタックとＩＰ Ｔｒａｎｓｐｏｒｔのプロトコルスタックとの変換を行う。また、ＩＷＦ装置３のＩＷＦ−ｕ３２，３３はユーザ情報転送におけるＡＴＭ ＴｒａｎｓｐｏｒｔのプロトコルスタックとＩＰ Ｔｒａｎｓｐｏｒｔのプロトコルスタックとの変換を行う。
ＲＮＣ１は制御信号を送受信する制御信号送受信部［シグナリング制御装置］１１〜１３と、ユーザ情報を送受信するデータ送受信部２１〜２３とから構成されている。
図２は図１のＩＷＦ−ｃ３１及びＩＷＦ−ｕ３２の構成を示すブロック図であ。図２において、ＩＷＦ−ｃ３１はリソース管理部３１１と、プロトコル終端部３１２，３１４と、ＩＷＦ−ｕ３２とのインタフェース（ＩＦ）部３１３とから構成されている。ＩＷＦ−ｕ３２はスイッチ制御部３２１と、スイッチ３２２と、ＩＷＦ−ｃ３１とのインタフェース（ＩＦ）部３２３と、ＡＴＭ側のプロトコル終端部３２４〜３２６と、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）側のプロトコル終端部３２７〜３２９とから構成されている。
図３は本実施例におけるＣ−Ｐｌａｎｅのプロトコルスタックを示す図である。図３において、ＲＮＣ１はＤａｔａ ｌｉｎｋレイヤと、ＩＰレイヤと、ＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤと、Ｍ３ＵＡ［ＳＳ７（Ｓｉｇｎａｌｌｉｎｇ Ｓｙｓｔｅｍ Ｎｏ．７） ＭＴＰ３（Ｍｅｓｓａｇｅ Ｔｒａｎｓｆｅｒ Ｐａｒｔ ３） Ｕｓｅｒ Ａｄａｐｔａｔｉｏｎ］レイヤと、ＳＣＣＰ（Ｓｉｇｎａｌｌｉｎｇ Ｃｏｎｎｅｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐａｒｔ）レイヤと、ＲＡＮＡＰ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）レイヤとからなる。
ＩＷＦ−ｃ３１はＲＮＣ１側がＤａｔａ ｌｉｎｋレイヤと、ＩＰレイヤと、ＳＣＴＰレイヤと、Ｍ３ＵＡレイヤと、ＳＣＣＰレイヤと、ＲＡＮＡＰレイヤとからなり、ＭＳＣ４及びＳＧＳＮ５側がＡＴＭレイヤと、ＳＡＡＬ−ＮＮＩ（Ｓｉｇｎａｌｌｉｎｇ ＡＴＭ Ａｄａｐｔａｔｉｏｎ Ｌａｙｅｒ−Ｎｅｔｗｏｒｋ Ｎｏｄｅ Ｉｎｔｅｒｆａｃｅ）レイヤと、ＭＴＰ３−Ｂ（Ｍｅｓｓａｇｅ Ｔｒａｎｓｆｅｒ Ｐａｒｔ ３−Ｂ）レイヤと、ＳＣＣＰレイヤと、ＲＡＮＡＰレイヤとからなる。
ＭＳＣ４及びＳＧＳＮ５はＡＴＭレイヤと、ＳＡＡＬ−ＮＮＩレイヤと、ＭＴＰ３−Ｂレイヤと、ＳＣＣＰレイヤと、ＲＡＮＡＰレイヤとからなる。
この場合、ＳＣＣＰレイヤはＩＷＦ装置３で一端終端する。これに対し、最上位のシグナリング・プロトコルであるＲＡＮＡＰレイヤは、一部判別する必要があるものの、ＲＮＣ１とＭＳＣ４またはＳＧＳＮ５との間で終端することになる。一部のメッセージについてはリソースアドレスについての内容変更を行う。
ＳＣＣＰレイヤがＩＷＦ装置３で一端終端する結果、１つの呼に対してＳＣＣＰコネクションがＲＮＣ１−ＩＷＦ間とＩＷＦ−ＭＳＣ４またはＳＧＳＮ５間とに二本設定されることになる。ＳＣＣＰレイヤは、その二本のＳＣＣＰコネクションを対応付けるＳＣＣＰ対応表をＩＷＦ装置３のリソース管理部３１１に持っている。このため、ＩＷＦ装置３でＳＣＣＰを一端終端して呼情報を認識し、適切な宛先へ再度送信することで、ＲＮＣ１内の複数ある制御信号送受信部１１〜１３の中から適切な送受信部を選択することが可能となる。
なお、ここではＣＳ（Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ）呼について詳細に説明したが、ＭＳＣ４の代わりにＳＧＳＮ５を用いたＰＳ（Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ）呼についても、上記と同じように説明することができる。ＣＳ呼はＭＳＣ４を利用した音声回線呼、ＰＳ呼はＳＧＳＮ５を利用したパケット通信呼である。
図４は本実施例によるＣＳ発呼時における動作を示すシーケンスチャートである。この図４を参照して、本実施例によるＣＳ発呼時における各装置のリソース確保までの動作について説明する。
端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）が、「Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ」（図４のａ１）をＲＮＣ１に送信することで、発呼シーケンスが開始される。ＲＮＣ１は「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」をＭＳＣ４に向けて送信する際、ＲＮＣ１とＩＷＦ−ｃ３１との間で、及びＩＷＦ−ｃ３１とＭＳＣ４との間でそれぞれＳＣＣＰコネクションが設定される（図４のａ２，ａ３）。このとき、ＲＮＣ１とＩＷＦ−ｃ３１との間のＳＣＣＰコネクションをＳＣＣＰコネクション＃１、ＩＷＦ−ｃ３１とＭＳＣ４との間のＳＣＣＰコネクションをＳＣＣＰコネクション＃２とする。
ＩＷＦ−ｃ３１ではこの「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」を中継するのみで、ＳＣＣＰをＳＣＣＰコネクション＃１からＳＣＣＰコネクション＃２に載せ変えて、ＭＳＣ４へ送信する（図４のａ４，ａ５）。ＩＷＦ−ｃ３１のリソース管理部３１１では、ＳＣＣＰコネクション＃１とＳＣＣＰコネクション＃２とが同じ呼で利用していることを認識するＳＣＣＰ対応表が作成される。なお、Ｐａｇｉｎｇ等のＭＳＣ４側から最初にＳＣＣＰコネクションが設定される場合、ＩＷＦ−ｃ３１が制御信号送受信部を任意に選択する機能を持つ。
呼利用中のマルチコールでは、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）等の端末固有の情報によって、ＩＷＦ−ｃ３１内でその端末が利用中かどうかを判断し、同じ制御信号送受信部を利用可能にする手段も持つ。
認証、秘匿を行った後（図４のａ６）、ＭＳＣ４はユーザデータ用のリソースを確保し（図４のａ７）、無線リソースを確保するための「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」（第１のリソース要求）（図４のａ８）をＲＮＣ１へ送信する。ＩＷＦ−ｃ３１では、このメッセージを受信したとき、ＩＷＦ−ｕ３２，３３のリソースの確保を行う必要があると判断する。以下では、ＩＷＦ−ｕ３２のリソースの確保を行う場合について説明する。
「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」には、ＭＳＣ４でユーザデータ転送に利用されるアドレス等の第１のパラメータが含まれている。ＩＷＦ−ｃ３１のリソース管理部３１１は、この第１のパラメータを「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」より取得し、リソース要求（第２のリソース要求）に付加し、ＩＷＦ−ｕ３２に送信する（図４のａ９）。
ＩＷＦ−ｕ３２のスイッチ制御部３２１は、受信されたリソース要求より第１のパラメータを取得し、ユーザデータ用のリソースを確保し（図４のａ１０）、リソースを確保した旨の通知をＩＷＦ−ｃ３１に送信する（図４のａ１１）。この通知には、ＩＷＦ−ｕ３２でユーザデータ転送に利用されるＲＮＣ１側のアドレス等の第２のパラメータが付加されている。
ＩＷＦ−ｃ３１のリソース管理部３１１は、受信された通知より第２のパラメータを取得する。そして、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」内のユーザデータ転送先アドレスであるＭＳＣ４のアドレスをＩＷＦ−ｕ３２のアドレスに書換え、書換え後の「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」をＲＮＣ１内の適切な制御信号送受信部へ転送する（図４のａ１２）。この際の適切な制御信号送受信部の選択にはＳＣＣＰ対応表を利用する。
その後、ＲＮＣ１はユーザデータ用のリソースを確保する（図４のａ１３）。そして、ＲＮＣ１はＵ−Ｐｌａｎｅの設定を行うために、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」で通知されたＩＷＦ−ｕ３２のアドレスへ向けて「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」を送信する（図４のａ１４）。この通知にはＲＮＣ１のユーザデータ用のアドレスが格納されている。この通知の送信には、ＩＰＡＬＣＡＰ（ＩＰ Ａｃｃｅｓｓ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を利用することができる。
この通知を受け取ったＩＷＦ−ｕ３２は、ＭＳＣ４へ向けてＡＬＣＡＰ（Ａｃｃｅｓｓ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）で「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」を送信する（図４のａ１５）。このＭＳＣ４の宛先には、事前にＩＷＦ−ｃ３１から通知されているＭＳＣ４のアドレスを利用する。
ＭＳＣ４からＩＷＦ−ｕ３２へ、ＩＷＦ−ｕ３２からＲＮＣ１へ、確認のメッセージとして「Ｅｓｔａｂｌｉｓｈ Ｃｏｎｆｉｒｍ」を送信する（図４のａ１６，ａ１７）。その後、ＵＥとＲＮＣ１との間で無線リソースを確保する（図４のａ１８）。無線リソースが確保されると、ＲＮＣ１からＩＷＦ−ｕ３２へ、ＩＷＦ−ｕ３２からＭＳＣ４へ「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」を送信することによって、ユーザデータ転送用のパス設定が完了する（図４のａ１９，ａ２０）。
その後、設定されたパスを用いてユーザデータの転送が行われる。
なお、ＩＷＦ−ｕ３３のリソースの確保を行う場合についても、同様の処理が行われる。
図５は本実施例によるＰＳ発呼時における各装置のリソース確保までの動作を示すシーケンスチャートである。この図５を参照して、本実施例によるＰＳ発呼時における各装置のリソース確保までの動作について説明する。
図５を参照すると、ＰＳ発呼時における各装置のリソース確保までの動作は、上述したＣＳ発呼時における各装置のリソース確保までの動作とほとんど同じである。すなわち、図５のｂ１〜ｂ１３の動作は図４のａ１〜ａ１３と同様である。しかし、ＰＳ呼ではＡＬＣＡＰやＩＰＡＬＣＡＰを利用しないため、最後の「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」が異なっている。
ＩＷＦ−ｃ３１では、ＵＥとＲＮＣ１との間で無線リソースが確保された後（図５のｂ１４）、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」によって、ユーザ転送用のパス設定が完了すると（図５のｂ１５）、ＩＷＦ−ｃ３１は「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」よりＲＮＣ１のユーザデータ用のアドレスを取得し、ＩＷＦ−ｕ３２に通知する（図５のｂ１６）。その応答として、ＩＷＦ−ｕ３２はＩＷＦ−ｃ３１にＩＷＦ−ｕ３２のＭＳＣ４側のアドレスを通知する（図５のｂ１７）。ＩＷＦ−ｃ３１はこのアドレスを取得し、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」内のユーザデータ転送先アドレスであるＲＮＣ１のアドレスをＩＷＦ−ｕ３２のアドレスに書換え、書換え後の「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」をＭＳＣ４へ送信する（図５のｂ１８）。
この際、ＳＣＣＰコネクションはＳＣＣＰ対応表を利用する。ＳＣＣＰにはそれぞれのリンクが確認できるように、リンク番号が付与されている。ＳＣＣＰ対応表にはそのリンク番号毎に、ＭＳＣ４またはＳＧＳＮ５向けの何番とＲＮＣ１向けの何番とが対応しているという情報が格納されている。
その後の処理は、上述したＣＳ発呼時の処理と同様である。
なお、ＩＷＦ−ｕ３３のリソースの確保を行う場合についても、同様の処理が行われる。
上述した図４及び図５に示す動作では、リソースを確保するときのシーケンスについて詳細に説明したが、リソースを解放するときにも上記と同様の手順で行うことができる。
図６及び図７は図１のＩＷＦ−ｃ３１の動作を示すフローチャートである。これら図６及び図７を参照してＩＷＦ装置３内のＩＷＦ−ｃ３１の動作について説明する。
ＩＷＦ−ｃ３１はシグナリングを受信したとき（図６ステップＳ１）、ＲＮＣ１側から受信したシグナリングか、ＭＳＣ４側から受信したシグナリングかの判別を行う（図６ステップＳ２）。
ＩＷＦ−ｃ３１はＲＮＣ１側から受信したＲＡＮＡＰシグナリングの場合、ＰＳ呼のときでリソース確保応答を示す「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」のときだけ（図７ステップＳ１４）、ＩＷＦ−ｕ３２，３３にＲＮＣアドレスを通知する（図７ステップＳ１５）。
ＩＷＦ−ｃ３１はＩＷＦ−ｕ３２，３３からの応答を待ってＩＷＦ−ｕ（ＲＮＣ１側）アドレスを取得し（図７ステップＳ１６）、シグナリング内のユーザデータ用ＲＮＣアドレスをＩＷＦ−ｕ３２，３３のアドレスに書換え（図７ステップＳ１７）、ＲＡＮＡＰシグナリングをＭＳＣ４へ送信する（図７ステップＳ１８）。ＩＷＦ−ｃ３１は上記以外の場合、ＲＡＮＡＰシグナリングをそのままＭＳＣ４へ送信する（図７ステップＳ１８）。
ＩＷＦ−ｃ３１はＭＳＣ４側からＲＡＮＡＰシグナリングを受信すると（図６ステップＳ３）、まずＰａｇｉｎｇ等のＭＳＣ４からの最初のＲＡＮＡＰシグナリングで、制御信号送受信部の番号とＳＣＣＰコネクションとのＳＣＣＰ対応表ができていない場合（図６ステップＳ４）、制御信号送受信部を任意に選択し、ＲＡＮＡＰシグナリングをそのまま制御信号送受信部へ送信する（図６ステップＳ１１〜Ｓ１３）。
ＳＣＣＰコネクションと制御信号送受信部の番号との対応付けができていない場合には、ＳＣＣＰ対応表を作成する（図６ステップＳ１２）。このＳＣＣＰ対応表は、呼の終了（ＳＣＣＰコネクションの終了）と同時に無くなる。
次に、ＩＷＦ−ｃ３１はそのＲＡＮＡＰシグナリングがユーザデータ用のリソースを確保する「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」かどうかを判断する（図６ステップＳ６）。ＩＷＦ−ｃ３１はユーザデータ用のリソースを確保するリクエストである場合、ＩＷＦ−ｕ３２，３３とシグナリングのやりとりを行い、ＩＷＦ−ｕ３２，３３のリソースを確保した後で、ＲＡＮＡＰシグナリングのユーザデータ転送先であるＭＳＣ４のアドレスからＩＷＦ−ｕ３２，３３のアドレスに書換え（図６ステップＳ７〜Ｓ９）、制御信号送受信部の宛先をＳＣＣＰ対応表から取得してその制御信号送受信部へシグナリングを送信する（図６ステップＳ１０）。
ＩＷＦ−ｃ３１はユーザデータ用のリソースを確保するリクエストでない場合、ＲＡＮＡＰには何も手を加えず、そのまま適切な制御信号送受信部へＲＡＮＡＰシグナリングを送信する（図６ステップＳ１０）。
図８及び図９は図１のＩＷＦ−ｕ３２，３３の動作を示すフローチャートである。これら図８及び図９を参照してＩＷＦ−ｕ３２，３３の動作について説明する。
ＩＷＦ−ｕ３２，３３はＩＷＦ−ｃ３１からリソース確保のシグナリングを受信した場合（図８ステップＳ２３、図９ステップＳ２８）、ＩＷＦ−ｕ３２，３３内のリソースを確保し（図９ステップＳ２９）、そのシグナリングで通知されたＭＳＣ４のアドレスをそのＩＷＦ−ｕアドレスと対応付けて記憶し、ＩＷＦ−ｃ３１へそのＩＷＦ−ｕアドレスを通知する（図９ステップＳ３０）。
ＩＷＦ−ｕ３２，３３はＲＮＣ１側からシグナリングを受信した場合（図８ステップＳ２４）、そのＩＰＡＬＣＡＰシグナリングをＡＬＣＡＰに載せかえて、対応付けられたＭＳＣアドレスへ向けて送信する（図８ステップＳ２７）。
ＩＷＦ−ｕ３２，３３はＭＳＣ４側からシグナリングを受信した場合（図８ステップＳ２５）、そのＡＬＣＡＰシグナリングをＩＰＡＬＣＡＰに載せかえて、対応付けされたＲＮＣアドレスへ向けて送信する（図８ステップＳ２６）。
上述したように、ＩＷＦ−ｕ３２，３３では、ユーザデータの流れも、ＲＮＣ１側やＭＳＣ４側からシグナリングを受信するときと同様に、プロトコル変換を行う。
このように、本実施例では、ＩＷＦ装置３をＣ−Ｐｌａｎｅ装置（ＩＷＦ−ｃ３１）とＵ−Ｐｌａｎｅ装置（ＩＷＦ−ｕ３２，３３）とに分離したので、ＩＷＦ装置３がスケーラビリティに富んだ構成をとることができる。具体的には、ＩＷＦ−ｕ３２，３３の数の増減時に、ＩＷＦ−ｃ３１が影響を受けない。
また、本実施例では、ＩＷＦ装置３で呼毎のＳＣＣＰを終端しているため、ＲＮＣ１内に制御信号送受信部１１〜１３を複数設置することが可能になる。従来、ＲＮＣ１としては一つである必要がある。
さらに、本実施例では、ＩＷＦ装置３をＣ−Ｐｌａｎｅ装置（ＩＷＦ−ｃ３１）とＵ−Ｐｌａｎｅ装置（ＩＷＦ−ｕ３２，３３）とに分離したときに、Ｃ−Ｐｌａｎｅ装置（ＩＷＦ−ｃ３１）からの要求に応答してＵ−Ｐｌａｎｅ装置（ＩＷＦ−ｕ３２，３３）でリソースの確保を行うことによって、最短経路を利用するＩＰ ｔｒａｆｆｉｃの負荷分散を行うことができる。
第２の実施例
図１０は本発明に係るプロトコル変換装置の第２の実施例によるＩＷＦ装置の構成を示すブロック図である。図１０において、本実施例はＩＷＦ装置７内においてＩＷＦ−ｃ３１とＩＷＦ−ｕ７１，７２との間で信号の送受信を行わず、ＲＮＣ６の制御信号送受信部６１〜６３からＩＷＦ−ｕ７１，７２を制御する点が、上述した第１の実施例と異なる。同一構成要素には第１の実施例と同一符号を付してある。
第１の実施例ではＩＷＦ−ｃ３１でＲＡＮＡＰシグナリングを認識する必要があるので、全てのシグナリングをデコードし、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」であるかどうかを認識しなければならない。これに対し、本実施例では、ＩＷＦ−ｕ７１，７２のリソース管理をＲＮＣ６内の制御信号送受信部６１〜６３で行うことで、ＩＷＦ−ｃ３１ではＲＡＮＡＰシグナリングをデコードする必要が無くなるため、ＩＷＦ−ｃ３１の処理を軽くすることができる。
図１１は図１０のＩＷＦ−ｃ３１及びＩＷＦ−ｕ７１の構成を示すブロック図である。図１１において、ＩＷＦ−ｃ３１はプロトコル終端部３１２，３１４と、信号転送部３１５とから構成されている。ＩＷＦ−ｕ７１はリソース管理部７１１と、スイッチ３２２と、ＡＴＭ側のプロトコル終端部３２４〜３２６と、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）側のプロトコル終端部３２７〜３２９，７１２とから構成されている。
図１２は本実施例におけるＣ−Ｐｌａｎｅのプロトコルスタックを示す図である。図１２において、本実施例は、プロトコルスタックでＳＣＣＰレイヤとＲＡＮＡＰレイヤとをＩＷＦ−ｃ３１で終端しない点が、上述した第１の実施例と異なっており、他の部分は第１の実施例と同様である。
図１３は本実施例によるＣＳ発呼時における動作を示すシーケンスチャートである。この図１３を参照して、本実施例によるＣＳ発呼時における各装置のリソース確保までの動作について説明する。
図１３において、本実施例では、ＳＣＣＰコネクションをＲＮＣ６とＭＳＣ４との間で終端し、この終端にＩＷＦ−ｃ３１は関与しない。しかしながら、ＳＣＣＰコネクション内にＲＮＣ６で利用されている制御信号送受信部を識別するフラグを添付しているので、ＩＷＦ−ｃ３１ではそのフラグを判別することによって、適切な制御信号送受信部を選択することが可能になっている。
ＭＳＣ４から送信された「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」（第４のリソース要求）は、ＩＷＦ−ｃ３１に関知されずＲＮＣ６まで届く（図１３のｃ６）。この「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｑｕｅｓｔ」を受信したＲＮＣ６は、ユーザデータ用のリソースを確保する（図１３のｃ７）。リソースを確保したＲＮＣ６は、ＩＷＦ−ｕ７１のリソースを確保するリソース要求（第３のリソース要求）をＩＷＦ−ｕ７１に送信する（図１３のｃ８）。このリソース要求にＭＳＣ４のアドレスとともにＲＮＣ６のアドレスを付加することで、このリソース要求がＩＰＡＬＣＡＰの「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」の代わりにもなる。
ＩＷＦ−ｕ７１はユーザデータ転送先であるＭＳＣ４のアドレスを取得し、ユーザデータ用のリソースを確保する（図１３のｃ９）。その後、ＡＬＣＡＰでＭＳＣ４に「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」を送信する（図１３のｃ１０）。これに対してＡＬＣＡＰでＩＷＦ−ｕ７１に返信される「Ｅｓｔａｂｌｉｓｈ Ｃｏｎｆｉｒｍ」を待って（図１３のｃ１１）、ＩＷＦ−ｕ７１はＲＮＣ６へＩＷＦ−ｕ７１のアドレスを通知する（図１３のｃ１２）。
その後の処理は、上述した第１の実施例と同様である。
なお、ＩＷＦ−ｕ７２のリソースの確保を行う場合についても、同様の処理が行われる。
図１４は本実施例によるＰＳ発呼時における動作を示すシーケンスチャートである。この図１４を参照して、本実施例によるＰＳ発呼時における各装置のリソース確保までの動作について説明する。
ＰＳ呼ではＡＬＣＡＰ「Ｅｓｔａｂｌｉｓｈ Ｒｅｑｕｅｓｔ」を利用しないため、「ＲＡＢ Ａｓｓｉｇｎｍｅｎｔ Ｒｅｓｐｏｎｓｅ」で（図１４のｄ１２）、ＣＳ呼とＰＳ呼とで異なる動きをしなくてもよくなる。
本実施例では、ＩＷＦ−ｃ３１がリソース確保を行わず、ＲＮＣ６内の制御信号送受信部６１〜６３がリソース確保を行うことによって、ＩＷＦ−ｃ３１では図６及び図７に示す判別ステップが不要となり、下位レイヤのプロトコル変換を行うのみの動作となる。
図１５は図１０のＩＷＦ−ｕ７１の動作を示すフローチャートである。図１５において、ステップＳ４１〜Ｓ４８の処理は、図８及び図９に示す処理と同様である。ただし、ステップＳ２３，Ｓ２８の判断式がなく、全体として判断式が少なくなっていることから、ＩＷＦ−ｕ７１でも処理を軽くすることが可能になっている。
このように、本実施例では、ＲＮＣ６内の制御信号送受信部６１〜６３がＩＷＦ−ｕ７１，７２のリソース確保のためのシグナリングを制御しているので、ＩＷＦ−ｃ３１でＲＡＮＡＰシグナリングをデコードしなくても良く、ＳＣＣＰコネクションも終端しなくても良いという効果が得られる。また、ＩＷＦ−ｃ３１とＩＷＦ−ｕ７１，７２との関係が無くなることから、実装にもフレキシビリティが確保され、ＩＷＦ−ｕ７１，７２をＲＮＣ６内に実装することも容易となる。
以上説明したように、上述した実施例によるＩＷＦ装置３，７はシグナリングを制御するＣプレーン装置と、ユーザデータを制御するＵプレーン装置とに分離しているので、スケーラビリティに富んだ構成をとることができる。さらに、ＲＮＣ１，６もまた、スケーラビリティに富んだ構成をとることができる。なお、上述したＩＷＦ装置３，７は、異なる物理回線の間に接続される場合ばかりではなく、同じ物理回線で中間のプロトコルが異なる場合でも適用可能である。
Claims (18)
- 互いに異なる物理回線を利用する第１の装置と第２の装置との間に接続されるプロトコル変換装置であって、
前記第１の装置と前記第２の装置との間のシグナリングを制御するＣプレーン装置と、
前記第１の装置と前記第２の装置との間でのユーザデータの転送を制御するＵプレーン装置とを備え、
前記Ｃプレーン装置は、前記第１の装置よりユーザデータ用のリソースを確保するための第１のリソース要求を受信したときに前記Ｕプレーン装置に第２のリソース要求を送信するリソース管理部を備え、
前記Ｕプレーン装置は、第２のリソース要求を受信したときに前記Ｕプレーン装置内でユーザデータ用のリソースを確保する制御部を備えることを特徴とするプロトコル変換装置。 - 請求の範囲第２項に記載のプロトコル変換装置において、
前記リソース管理部は、第１のリソース要求に含まれる前記第１の装置におけるユーザデータ転送用の第１のパラメータを取得しこのパラメータを第２のリソース要求に付加することを特徴とするプロトコル変換装置。 - 請求の範囲第３項に記載のプロトコル変換装置において、
前記制御部は、リソースを確保した後に前記Ｕプレーン装置におけるユーザデータ転送用の第２のパラメータが付加されたリソース確保通知を前記Ｃプレーン装置に送信し、
前記リソース管理部は、受信されたリソース確保通知から第２のパラメータを取得し第１のリソース要求に含まれる第１のパラメータを第２のパラメータに書き換え書換後の第１のリソース要求を前記第２の装置に転送することを特徴とするプロトコル変換装置。 - 互いに異なる物理回線を利用する第１の装置と第２の装置との間に接続されるプロトコル変換装置であって、
前記第１の装置と前記第２の装置との間のシグナリングを制御するＣプレーン装置と、
前記第１の装置と前記第２の装置との間でのユーザデータの転送を制御するＵプレーン装置とを備え、
前記Ｕプレーン装置は、前記第２の装置よりユーザデータ用のリソースを確保するための第３のリソース要求を受信したときに前記Ｕプレーン装置内でユーザデータ用のリソースを確保するリソース管理部を備えることを特徴とするプロトコル変換装置。 - 請求の範囲第５項に記載のプロトコル変換装置において、
前記リソース管理部は、第３のリソース要求に含まれる前記第１及び第２の装置におけるユーザデータ転送用のパラメータを取得することを特徴とするプロトコル変換装置。 - 請求の範囲第５項に記載のプロトコル変換装置において、
前記第２の装置は、前記第１の装置よりユーザデータ用のリソースを確保するための第４のリソース要求を受信したときに前記Ｕプレーン装置に第３のリソース要求を送信することを特徴とするプロトコル変換装置。 - 互いに異なる物理回線を利用する第１の装置と第２の装置との間に接続されるプロトコル変換装置であって、
前記第１の装置と前記第２の装置との間のシグナリングを制御するＣプレーン装置と、
前記第１の装置と前記第２の装置との間でのユーザデータの転送を制御するＵプレーン装置とを備え、
前記第１の装置は、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）トランスポートのプロトコルスタックを用いるＭＳＣ（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ）及びＳＧＳＮ［Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ］の少なくとも一方であり、
前記第２の装置は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）トランスポートのプロトコルスタックを用いる基地局制御装置であることを特徴とするプロトコル変換装置。 - 請求の範囲第８項に記載のプロトコル変換装置において、
前記Ｃプレーン装置と前記ＭＳＣ及びＳＧＳＮの少なくとも一方との間、及び前記Ｃプレーン装置と前記基地局制御装置との間には、それぞれＳＣＣＰ（Ｓｉｇｎａｌｌｉｎｇ Ｃｏｎｎｅｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐａｒｔ）コネクションが設定されることを特徴とするプロトコル変換装置。 - 請求の範囲第９項に記載のプロトコル変換装置において、
前記基地局制御装置は、制御信号の送受信を行うシグナリング制御装置を複数備え、
前記Ｃプレーン装置は、前記シグナリング制御装置の番号とＳＣＣＰコネクションとが対応付けられたＳＣＣＰ対応表を記憶し、前記ＭＳＣ及びＳＧＳＮの少なくとも一方からシグナリングを受信したときにＳＣＣＰ対応表に基づいて前記シグナリング制御装置のいずれかを選択することを特徴とするプロトコル変換装置。 - 互いに異なる物理回線を利用する第１の装置と第２の装置との間を接続する際に適用されるプロトコル変換方法であって、
Ｃプレーン装置で前記第１の装置と前記第２の装置との間のシグナリングを制御する第１のステップと、
前記Ｃプレーン装置と独立に配設されたＵプレーン装置で前記第１の装置と前記第２の装置との間でのユーザデータの転送を制御する第２のステップとを備え、
前記第１のステップは、
前記第１の装置より前記Ｃプレーン装置にユーザデータ用のリソースを確保するための第１のリソース要求を送信する第３のステップと、
前記Ｃプレーン装置で第１のリソース要求を受信したときに前記Ｕプレーン装置に第２のリソース要求を送信する第４のステップと、
前記Ｕプレーン装置で第２のリソース要求を受信したときに前記Ｕプレーン装置内でユーザデータ用のリソースを確保する第５のステップと
を備えることを特徴とするプロトコル変換方法。 - 請求の範囲第１２項に記載のプロトコル変換方法において、
前記第４のステップは、第１のリソース要求に含まれる前記第１の装置におけるユーザデータ転送用の第１のパラメータを取得しこのパラメータを第２のリソース要求に付加するステップを備えることを特徴とするプロトコル変換方法。 - 請求の範囲第１３項に記載のプロトコル変換方法において、
前記第１のステップは、
前記第５のステップの後に前記Ｕプレーン装置におけるユーザデータ転送用の第２のパラメータが付加されたリソース確保通知を前記Ｃプレーン装置に送信する第６のステップと、
受信されたリソース確保通知から第２のパラメータを取得し第１のリソース要求に含まれる第１のパラメータを第２のパラメータに書き換え書換後の第１のリソース要求を前記第２の装置に転送する第７のステップと
をさらに備えることを特徴とするプロトコル変換方法。 - 互いに異なる物理回線を利用する第１の装置と第２の装置との間を接続する際に適用されるプロトコル変換方法であって、
Ｃプレーン装置で前記第１の装置と前記第２の装置との間のシグナリングを制御する第１のステップと、
前記Ｃプレーン装置と独立に配設されたＵプレーン装置で前記第１の装置と前記第２の装置との間でのユーザデータの転送を制御する第２のステップとを備え、
前記第１のステップは、
前記第２の装置より前記Ｕプレーン装置にユーザデータ用のリソースを確保するための第３のリソース要求を送信する第８のステップと、
前記Ｕプレーン装置で第３のリソース要求を受信したときに前記Ｕプレーン装置内でユーザデータ用のリソースを確保する第９のステップと
を備えることを特徴とするプロトコル変換方法。 - 請求の範囲第１５項に記載のプロトコル変換方法において、
前記第９のステップは、第３のリソース要求に含まれる前記第１及び第２の装置におけるユーザデータ転送用のパラメータを取得するステップを備えることを特徴とするプロトコル変換方法。 - 請求の範囲第１５項に記載のプロトコル変換方法において、
前記第１のステップは、前記第８のステップの前に前記第１の装置より前記第２の装置にユーザデータ用のリソースを確保するための第４のリソース要求を送信する第１０のステップをさらに備え、
前記第８のステップは、前記第２の装置で第４のリソース要求を受信したときに前記Ｕプレーン装置に第３のリソース要求を送信するステップであることを特徴とするプロトコル変換方法。 - 互いに異なる物理回線を利用する第１の装置と第２の装置との間を接続する際に適用されるプロトコル変換方法であって、
Ｃプレーン装置で前記第１の装置と前記第２の装置との間のシグナリングを制御する第１のステップと、
前記Ｃプレーン装置と独立に配設されたＵプレーン装置で前記第１の装置と前記第２の装置との間でのユーザデータの転送を制御する第２のステップとを備え、
前記第１の装置は、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）トランスポートのプロトコルスタックを用いるＭＳＣ（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ）及びＳＧＳＮ［Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ］の少なくとも一方であり、
前記第２の装置は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）トランスポートのプロトコルスタックを用いる基地局制御装置であることを特徴とするプロトコル変換方法。 - 請求の範囲第１８項に記載のプロトコル変換方法において、
前記第１のステップは、前記Ｃプレーン装置と前記ＭＳＣ及びＳＧＳＮの少なくとも一方との間、及び前記Ｃプレーン装置と前記基地局制御装置との間にそれぞれＳＣＣＰ（Ｓｉｇｎａｌｌｉｎｇ Ｃｏｎｎｅｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐａｒｔ）コネクションを設定する第１１のステップを備えることを特徴とするプロトコル変換方法。 - 請求の範囲第１９項に記載のプロトコル変換方法において、
前記第１のステップは、前記基地局制御装置が複数備えるシグナリング制御装置の番号とＳＣＣＰコネクションとが対応付けられたＳＣＣＰ対応表に基づいて、前記ＭＳＣ及びＳＧＳＮの少なくとも一方からシグナリングを受信したときに前記シグナリング制御装置のいずれかを選択する第１２のステップをさらに備えることを特徴とするプロトコル変換方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003048411 | 2003-02-26 | ||
| JP2003048411 | 2003-02-26 | ||
| PCT/JP2004/001407 WO2004077792A1 (ja) | 2003-02-26 | 2004-02-10 | プロトコル変換装置及び方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2004077792A1 JPWO2004077792A1 (ja) | 2006-06-08 |
| JP4010330B2 true JP4010330B2 (ja) | 2007-11-21 |
Family
ID=32923292
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005502828A Expired - Fee Related JP4010330B2 (ja) | 2003-02-26 | 2004-02-10 | プロトコル変換装置及び方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20060159121A1 (ja) |
| EP (1) | EP1599010A4 (ja) |
| JP (1) | JP4010330B2 (ja) |
| CN (1) | CN1754369A (ja) |
| WO (1) | WO2004077792A1 (ja) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006069025A2 (en) * | 2004-12-20 | 2006-06-29 | Nextel Communications, Inc. | Systems and method for a dispatch communication router |
| CN100466612C (zh) * | 2005-11-18 | 2009-03-04 | 华为技术有限公司 | 实现无线网络控制器间通信的方法和*** |
| CN101188609B (zh) * | 2007-12-05 | 2012-05-23 | 中兴通讯股份有限公司 | 一种atm与ip的转换装置、***及方法 |
| GB2473399B (en) * | 2008-07-16 | 2012-06-27 | Nec Corp | Method for reporting information about result of Iu-UP protocol negotiation protocol conversion method,communication network system |
| CN102171664B (zh) * | 2008-08-06 | 2014-12-03 | 莫维克网络公司 | 无线电接入网(ran)中的内容高速缓存 |
| CN102301794A (zh) * | 2008-11-10 | 2011-12-28 | 阿尔卡特朗讯公司 | 在包括互通功能iwf的仅分组移动***上支持cs域服务的方法和设备 |
| US8208430B2 (en) * | 2008-12-23 | 2012-06-26 | Movik Networks | Transparent interaction with multi-layer protocols via selective bridging and proxying |
| US9144113B2 (en) * | 2008-12-30 | 2015-09-22 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus to migrate transport protocols |
| CN102282550A (zh) * | 2009-01-30 | 2011-12-14 | 莫维克网络公司 | 应用和使用以及无线链路感知传输网络调度程序 |
| CN101594640A (zh) * | 2009-06-30 | 2009-12-02 | 中兴通讯股份有限公司 | 用户面数据转发***及方法 |
| US8503434B2 (en) * | 2009-09-28 | 2013-08-06 | Stoke, Inc. | Method and system for inserting a new node into a communications path between two existing nodes without disruption |
| WO2011057292A1 (en) * | 2009-11-09 | 2011-05-12 | Movik Networks, Inc. | Burst packet scheduler for improved ran efficiency in umts/hspa networks |
| CN102598628A (zh) * | 2010-03-15 | 2012-07-18 | 莫维克网络公司 | 用于多媒体传送的自适应分块和内容感知同步设备及方法 |
| US8799480B2 (en) | 2010-07-19 | 2014-08-05 | Movik Networks | Content pre-fetching and CDN assist methods in a wireless mobile network |
| WO2012040608A2 (en) | 2010-09-24 | 2012-03-29 | Movik Networks | Destination learning and mobility detection in transit network device in lte & umts radio access networks |
| CN102487499B (zh) * | 2010-12-01 | 2015-05-27 | 华为技术有限公司 | 隧道重定向的方法及互通功能实体 |
| WO2013038167A2 (en) * | 2011-09-12 | 2013-03-21 | Sca Ipla Holdings Inc | Mobile communications network, infrastructure equipment and method |
| US9049251B2 (en) * | 2012-02-28 | 2015-06-02 | Futurewei Technologies, Inc. | Method and apparatus for internet protocol based content router |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09275402A (ja) * | 1996-04-04 | 1997-10-21 | Sony Corp | 通信制御システムおよび通信制御装置並びにデータ送受信装置および通信制御方法 |
| SE9601606D0 (sv) * | 1996-04-26 | 1996-04-26 | Ericsson Telefon Ab L M | Sätt vid radiotelekommunikationssystem |
| JPH10229400A (ja) * | 1997-02-14 | 1998-08-25 | Nippon Telegr & Teleph Corp <Ntt> | Ａｔｍ加入者線信号用仮想チャネルの設定方法 |
| US6208633B1 (en) * | 1998-02-05 | 2001-03-27 | Telefonaktiebolaget Lm Ericsson | System and method for mobile data services |
| US6311072B1 (en) * | 1998-06-30 | 2001-10-30 | Lucent Technologies, Inc. | Methods and apparatus for translating between telephone signaling protocols |
| US6298059B1 (en) * | 1998-12-23 | 2001-10-02 | Nortel Networks Limited | Multiple quality of service asynchronous transfer mode-frame relay interworking function and method |
| US6466556B1 (en) * | 1999-07-23 | 2002-10-15 | Nortel Networks Limited | Method of accomplishing handover of packet data flows in a wireless telecommunications system |
| US6801542B1 (en) * | 1999-08-19 | 2004-10-05 | Nokia Corporation | Method and apparatus for providing an interworking unit between ATM networks and IP networks |
| US6445922B1 (en) * | 1999-12-15 | 2002-09-03 | Lucent Technologies Inc. | Method and system for support of overlapping IP addresses between an interworking function and a mobile IP foreign agent |
| JP2002026994A (ja) * | 2000-05-31 | 2002-01-25 | Nec Corp | 無線ネットワークシステム |
| US6771983B1 (en) * | 2000-11-02 | 2004-08-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Signaling in a mobile cellular communication network with pooled MSCs |
| DE60019817T2 (de) * | 2000-11-17 | 2006-01-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobiles Kommunikationsnetz |
| FI111777B (fi) * | 2001-01-16 | 2003-09-15 | Nokia Corp | IP-datan siirtäminen tietoliikennejärjestelmässä |
| JP2003110622A (ja) * | 2001-07-24 | 2003-04-11 | Ntt Docomo Inc | コネクション解放方法、リンク切断通知方法、中継装置、通信装置、交換機、プログラムおよび記録媒体 |
| GB0202278D0 (en) * | 2002-01-31 | 2002-03-20 | Nokia Corp | A system |
| US7254639B1 (en) * | 2002-05-20 | 2007-08-07 | Cisco Technology, Inc. | Methods and apparatus for directing packets among a group of processors |
-
2004
- 2004-02-10 EP EP04709752A patent/EP1599010A4/en not_active Withdrawn
- 2004-02-10 US US10/546,802 patent/US20060159121A1/en not_active Abandoned
- 2004-02-10 CN CNA2004800051099A patent/CN1754369A/zh active Pending
- 2004-02-10 JP JP2005502828A patent/JP4010330B2/ja not_active Expired - Fee Related
- 2004-02-10 WO PCT/JP2004/001407 patent/WO2004077792A1/ja active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| JPWO2004077792A1 (ja) | 2006-06-08 |
| US20060159121A1 (en) | 2006-07-20 |
| WO2004077792A1 (ja) | 2004-09-10 |
| EP1599010A1 (en) | 2005-11-23 |
| CN1754369A (zh) | 2006-03-29 |
| EP1599010A4 (en) | 2008-11-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4010330B2 (ja) | プロトコル変換装置及び方法 | |
| US6791988B1 (en) | Processing of calls terminating in a packet switched protocol based cellular communication network | |
| US7466991B2 (en) | Method and system using a conference bridge for handoff of a multi-mode mobile station | |
| CN100556032C (zh) | 对话承载协商 | |
| US6760325B1 (en) | Processing of mobile originated calls in packet switched protocol based communication networks | |
| US20140022955A1 (en) | Multiple-termination routing in a wireless network environment with an internet protocol core | |
| WO2000004736A1 (en) | Optimal connection set up between terminals in two networks | |
| JP2003535526A (ja) | セルラ移動システムにおけるベアラ選択 | |
| JP2003530767A (ja) | インターネット・プロトコル移動通信ネットワークの技術分野で呼設定を行うための手法 | |
| US20060211425A1 (en) | Method and apparatus for acquiring user equipment capability information in a communication in a communication network | |
| EP1195066A1 (en) | Implementation of call setup procedures with separation of call control and bearer control | |
| KR100697119B1 (ko) | 무선 통신 네트워크에서 베어러 인가를 위한 방법 및 시스템 | |
| US6928067B1 (en) | Basic architecture for packet switched protocol based GSM networks | |
| EP2175594B1 (en) | Extension connection method and route selection device | |
| WO2005112410A2 (en) | Providing voice and data service for wireless cellular subscribers operating in a wireless local area network | |
| US20070249357A1 (en) | Method for Switching Between Two Telephone Services | |
| US20120264437A1 (en) | Call Switching in Packet-Based Communication Networks | |
| US7016679B2 (en) | Mobile network domain having a voice capable serving GPRS support node | |
| KR100570898B1 (ko) | 패킷 기반의 이동전화 구내 교환 장치 및 이를 이용한 호처리 방법 | |
| WO2012055437A1 (en) | Reducing latency in circuit switched data calls | |
| KR101233388B1 (ko) | 무선 공중망과 연동되는 사설 유무선 망에서 통화중인 무선 단말기의 호 처리 시스템 및 그 제어 방법 | |
| KR100668708B1 (ko) | 화상 통화의 통화 요금 부과 방법 | |
| JP2011166369A (ja) | 内線通話方法および通信システム | |
| EP1863220A2 (en) | Method and system for bearer authorization in a wireless communication network | |
| KR20080018062A (ko) | Ｗｃｄｍａ를 이용한 사설 무선 서비스 시스템 및 그 제어방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070605 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070814 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070827 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100914 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |