JP2019009515A - プロトコル変換装置、プロトコル変換及びプログラム - Google Patents

Abstract

【課題】公衆交換電話網（ＰＳＴＮ）とＩＰ網の接続コストの低減。【解決手段】共通信号線方式を用いた公衆交換電話網とＩＰ網との間にプロトコル変換装置を配置する。このプロトコル変換装置は、前記公衆交換電話網と、前記ＩＰ網間で授受されるメッセージについて、前記公衆交換電話網のレイヤ２のＭＴＰ２メッセージと、前記ＩＰ網側のレイヤ２のＭ２ＰＡメッセージとを相互に変換するプロトコル変換部を備える。【選択図】図１

Description

本発明は、プロトコル変換装置、プロトコル変換及びプログラムに関し、特に、共通線信号方式を用いた公衆交換電話網（ＰＳＴＮ）とＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網とを相互接続するプロトコル変換装置、プロトコル変換及びプログラムに関する。

オールＩＰ化の一環として、共通線信号方式で信号伝達メッセージをやり取りする公衆交換電話網（ＰＳＴＮ）を廃止し、ＳＩＧＴＲＡＮ形式の信号伝達メッセージをやり取りするＩＰ網に置き換える構想が示されている。公衆交換電話網とＩＰ網を接続する装置として、シグナリングゲートウェイやＩＰ−ＳＴＰという装置が知られている。ＩＰ−ＳＴＰは、ＩＰ信号中継装置（ＩＰ Ｓｉｇｎａｌｌｉｎｇ Ｔｒａｎｓｆｅｒ Ｐｏｉｎｔ）とも呼ばれ、シグナリングゲートウェイと同様に、公衆交換電話網（ＰＳＴＮ）側に配置されたＳＴＰ（Ｓｉｇｎａｌｌｉｎｇ Ｔｒａｎｓｆｅｒ Ｐｏｉｎｔ）とプロトコル変換を行う。なお、共通線信号方式は、Ｃｏｍｍｏｎ Ｃｈａｎｎｅｌ Ｓｉｇｎａｌｉｎｇ Ｓｙｓｔｅｍ Ｎｏ．７のことであり、ＳＳ７、ＣＣＳＳ７、Ｃ７ （ＣＣＩＴＴ ｎｕｍｂｅｒ ７）等と呼ばれている。

特許文献１に、ＩＰを介してシグナリングトラフィックのルーティングを行うシグナリングゲートウェイの一例が開示されている。同文献の図５及び段落００３０−００３１に特許文献１のシグナリングゲートウェイを用いた場合のトラフィックの流れが示されている。

特表２００４−５３３７４２号公報

以下の分析は、本発明によって与えられたものである。オールＩＰ化の過程において、公衆交換電話網（ＰＳＴＮ）の利用は高コストのため、通信キャリア事業者から区間利用短縮化の要望がある。上記したＩＰ−ＳＴＰの配置により、公衆交換電話網の区間短縮を実現できるが、ＩＰ−ＳＴＰの装置価格は高価であり、全国に数千個単位の対象箇所への設置は現実的ではない。

ここで、図３を参照して、ＩＰ−ＳＴＰの動作について説明する。まず、ＩＰ−ＳＴＰは、ＭＴＰ３（Ｍｅｓｓａｇｅ Ｔｒａｎｓｆｅｒ Ｐａｒｔ ３）のプロトコル変換を行う場合、ＭＴＰ３としては一旦終端させる。その上で、ＩＰ−ＳＴＰは、上位のＳＣＣＰ（Ｓｉｇｎａｌｌｉｎｇ Ｃｏｎｎｅｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐａｒｔ）レイヤにてルーチングを行い、改めて別のＭＴＰ３プロトコルを使用して別対地（ｏｔｈｅｒ ｐｅｅｒ）と繋げている。これは特許文献１のシグナリングゲートウェイも同様である。

このようにＩＰ−ＳＴＰやＳＴＰで信号を終端させることは、公衆交換電話網（ＰＳＴＮ）と、ＩＰ網（ＳＩＧＴＲＡＮ網）側とが別々の通信を行うことになるため、高機能なソフトウェアを搭載することになる。これが、ＩＰ−ＳＴＰのコストを押し上げる要因となっている。

本発明は、公衆交換電話網（ＰＳＴＮ）とＩＰ網の接続コストの低減に貢献できるプロトコル変換装置、プロトコル変換及びプログラムを提供することを目的とする。

第１の視点によれば、共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置され、前記公衆交換電話網と、前記ＩＰ網間で授受されるメッセージについて、前記公衆交換電話網のレイヤ２のＭＴＰ２メッセージと、前記ＩＰ網側のレイヤ２のＭ２ＰＡメッセージとを相互に変換するプロトコル変換部を備えたプロトコル変換装置が提供される。

第２の視点によれば、共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置されたプロトコル変換装置が、前記公衆交換電話網側から受信したメッセージからレイヤ２のＭＴＰ２メッセージを取り出してレイヤ２のＭ２ＰＡメッセージに変換するステップと、前記変換後のレイヤ２のＭ２ＰＡメッセージを、ＩＰ網側に送信するステップと、を含むメッセージ中継方法が提供される。

第３の視点によれば、共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置されたプロトコル変換装置が、前記ＩＰ網側から受信したメッセージからレイヤ２のＭ２ＰＡメッセージを取り出してレイヤ２のＭＴＰ２メッセージに変換するステップと、前記変換後のレイヤ２のＭＴＰ２メッセージを、公衆交換電話網側に送信するステップと、を含むメッセージ中継方法が提供される。上記した各メッセージ中継方法は、共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置されたプロトコル変換装置という、特定の機械に結びつけられている。

第４の視点によれば、プロトコル変換装置の機能を実現するためのコンピュータプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジエントな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、公衆交換電話網（ＰＳＴＮ）とＩＰ網の接続コストを低減することが可能となる。

本発明の一実施形態の構成を示す図である。 ＳＴＰとＩＰ−ＳＴＰを直接接続した方式を説明するための図である。 ＳＴＰとＩＰ−ＳＴＰを直接接続した方式の動作を説明するための図である。 本発明の第１の実施形態の構成を示す図である。 本発明の第１の実施形態のＭＴＰＣの論理的構成を示す機能ブロック図である。 本発明の第１の実施形態のＭＴＰＣにおけるメッセージの流れを示した図である。 本発明の第１の実施形態のＳＴＰとＭＴＰＣ間で授受されるＭＳＵのフォーマットを示す図である。 本発明の第１の実施形態のＳＴＰとＭＴＰＣ間で授受されるＬＳＳＵのフォーマットを示す図である。 本発明の第１の実施形態のＳＴＰとＭＴＰＣ間で授受されるＦＩＳＵのフォーマットを示す図である。 図７〜図９の各信号ユニット内のフィールドの内容を説明するための図である。 本発明の第１の実施形態の動作（リンク確立）を表した詳細シーケンス図である。 本発明の第１の実施形態の動作（リンク確立済みの通常シーケンス）を表した詳細シーケンス図である。 本発明の第１の実施形態の動作（死活監視）を表した詳細シーケンス図である。 本発明の第１の実施形態の動作（リンク障害検出時）を表した詳細シーケンス図である。

はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。また、以降の説明で参照する図面等のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。

本発明は、その一実施形態において、図１に示すように、共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置されたプロトコル変換装置２００にて実現できる。より具体的には、このプロトコル変換装置２００は、上記ＳＴＰに代表される公衆交換電話網側の装置（公衆交換電話網側装置１００）と、上記ＩＰ−ＳＴＰに代表されるＩＰ網側の装置（ＩＰ網側装置３００）との間で授受されるメッセージについて、前記公衆交換電話網のレイヤ２のＭＴＰ２メッセージと、前記ＩＰ網側のレイヤ２のＭ２ＰＡ（Ｍｅｓｓａｇｅ Ｔｒａｎｓｆｅｒ Ｐａｒｔ ２ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ａｄａｐｔａｔｉｏｎ Ｌａｙｅｒ）メッセージとを相互に変換するプロトコル変換部を備える。

上記プロトコル変換装置２００は、公衆交換電話網とＩＰ網の各信号局間でメッセージをやり取りする際、レイヤ２でプロトコル変換を行う。そのため、図３のＳＴＰにおけるレイヤ３で終端し、上位のＳＣＣＰでルーチングする必要がなくなる。従って、各装置で複雑なアプリケーションを搭載する必要がなくなる。従って、公衆交換電話網（ＰＳＴＮ）とＩＰ網の接続コストの低減が実現される。

［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。はじめに、参考例として、共通線信号方式の公衆交換電話網（以下、「ＳＳ７網」と記す。）のＳＴＰと、ＩＰ網側のＩＰ−ＳＴＰとの間で直接プロトコル変換を行う場合の構成と動作について説明する。

図２は、ＳＴＰとＩＰ−ＳＴＰを直接接続した方式を説明するための図である。図２のＩＰ−ＳＴＰ９３０が、ＳＳ７網とＩＰ網のプロトコル差分を吸収するためのプロトコル変換を行うゲートウェイとして機能する。図２において、ＭＴＰは信号方式のレイヤ１〜３に相当するプロトコルの総称であり、メッセージ転送部（Ｍｅｓｓａｇｅ Ｔｒａｎｓｆｅｒ Ｐａｒｔ）の略称である。ＭＴＰ１（レイヤ１）は、信号データリンク部、ＭＴＰ２（レイヤ２）は信号リンク機能部、ＭＴＰ３（レイヤ３）は信号網機能部として機能する。なお、図２のＳＣＰ９１０は、サービス制御点の略称であり、ＣＡ９４０は、コールエージェントの略称である。

ＳＴＰ９２０及びＩＰ−ＳＴＰ９３０は、図３に示すように、指定された宛先までメッセージ転送するために、それぞれ信号内のＭＴＰ３まで確認してから、宛先を確認してルーチングを行っている。より具体的には、ＳＴＰ９２０及びＩＰ−ＳＴＰ９３０は、ＭＴＰ３のＯＰＣ（発信号局コード）とＤＰＣ（着信号局コード）を参照し、指定された宛先を確認する。そして、これらＯＰＣ及びＤＰＣ（以下、両者を総称してＰＣ（ポイントコード）と記す。）情報を保持した後、メッセージ転送を行っている。

上記レイヤ３でのメッセージ転送は、上記確認したＰＣを保持した上で、Ｍ３ＵＡ（ＭＴＰ３ Ｕｓｅｒ Ａｄａｐｔａｔｉｏｎ Ｌａｙｅｒ）へのプロトコル変換を実施し、メッセージルーティングを行う必要がある。

また、ＳＳ７網と、ＩＰ網では各網内の交換機で１対１通信を行う際のプロトコルが異なり、前者はＭＴＰ２で通信を行い、後者はＭ２ＰＡで通信を行っている。このように、ＳＴＰ９２０とＩＰ−ＳＴＰ９３０は、別々の通信を行っているため、上記ＭＴＰ３においてプロトコル変換を行う際に、信号を一旦終端させる必要がある。この終端のため、ＳＴＰ９２０とＩＰ−ＳＴＰ９３０は、それぞれバッファが必要となる。加えて、ＳＴＰ９２０とＩＰ−ＳＴＰ９３０は、各対向装置に対してプロトコルを意識した通信を行うことが必要になり、高度なソフトウェア開発が必要になり、コストを増大させている。

図４は、本発明の第１の実施形態の構成を示す図である。本発明の第１の実施形態では、上記参考例と比較してよりコストを低減させるために以下の構成を採用している。図４を参照すると、ＳＳ７網と、ＩＰ網との間に、上記したプロトコル変換装置に相当するＭＴＰＣ（ＭＴＰ Ｃｏｎｖｅｒｔｅｒ）５０を配置した構成が示されている。なお、以下の説明では、ＳＳ７網に、ＳＣＰ１０と、ＳＴＰ２０とが配置され、ＩＰ網に、ＩＰ−ＳＴＰ３０と、ＣＡ４０とが配置されているものとして説明する。

ＭＴＰＣ５０は、ＳＳ７とＩＰのプロトコル差分を吸収し、ＭＴＰ２プロトコル変換を行うプロトコル変換部５１を備えている。また、このプロトコル変換部５１は、ＩＰ網側のノードとＳＳ７網のノード間のメッセージをやり取りする際、終端せずレイヤ２でプロトコル変換を行う。これにより、参考例に見られるレイヤ３までの確認とＰＣ保持が不要になる。また、ＳＴＰとして終端しルーチングする必要がなくなるので、複雑なアプリケーションを搭載する必要もなくなるという利点がある。以下、上記ＭＴＰＣ５０の構成について詳細に説明する。

図５は、ＭＴＰＣ５０の論理的構成を示す機能ブロック図である。図５を参照すると、ＭＴＰＣ５０内のプロトコル変換部５１は、ＳＳ７網側とのインタフェースとなるＭＴＰ１処理部５１２と、ＭＴＰ２処理部５１１とを備えている。さらに、プロトコル変換部５１は、ＩＰ網側とのインタフェースとなるＥｔｈｅｒ処理部５２４と、ＩＰ処理部５２３と、ＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）処理部５２２と、Ｍ２ＰＡ処理部５２１とを備えている。

図６は、ＭＴＰＣ５０におけるメッセージの流れを示した図である。ＳＳ７網からＩＰ網向けのメッセージを受信した場合のメッセージの流れは、以下のとおりとなる。ＳＳ７網側のＳＴＰ２０から送信されたメッセージは、ＭＴＰＣ５０のＳＳ７網側のレイヤ１のＭＴＰ１処理部５１２にて受信される。ＭＴＰ１処理部５１２は、受信したメッセージをＭＴＰ２処理部５１１に送る。ＭＴＰ２処理部５１１は、ＭＴＰ１処理部５１２から送られたメッセージからＭＴＰ２メッセージを取り出して、ＩＰ網側のレイヤ２のＭ２ＰＡメッセージに変換する。ＭＴＰ２処理部５１１は、変換後のＭ２ＰＡメッセージをＭ２ＰＡ処理部５２１に送る。なお、後記するように、ＭＴＰ２メッセージとＭ２ＰＡメッセージは１対１の割り当てが可能なため、変換可能である。

Ｍ２ＰＡ処理部５２１にて受信されたＭ２ＰＡメッセージはＳＣＴＰ処理部５２２、ＩＰ処理部５２３及びＥｔｈｅｒ処理部５２４を経て、ＩＰ網側のＩＰ−ＳＴＰ３０に送信される。

反対に、ＩＰ網からＳＳ７網向けのメッセージを受信した場合のメッセージの流れは、以下のとおりとなる。ＩＰ網側のＩＰ−ＳＴＰ３０から受信したメッセージは、ＭＴＰＣ５０のＩＰ網側のレイヤ１のＥｔｈｅｒ処理部５２４にて受信される。Ｅｔｈｅｒ処理部５２４は、受信したメッセージのボディを取り出してＩＰ処理部５２３に送る。ＩＰ処理部５２３は、受信したメッセージのボディを取り出してＳＣＴＰ処理部５２２に送る。ＳＣＴＰ処理部５２２は、受信したメッセージのボディを取り出してＭ２ＰＡ処理部５２１に送る。Ｍ２ＰＡ処理部５２１は、ＳＣＴＰ処理部５２２から送られたメッセージからＭ２ＰＡメッセージを取り出して、ＳＳ７網側のレイヤ２のＭＴＰ２メッセージに変換する。Ｍ２ＰＡ処理部５２１は、変換後のＭＴＰ２メッセージをＭＴＰ２処理部５１１に送る。

ＭＴＰ２処理部５１１にて受信されたＭＴＰ２メッセージはＭＴＰ１処理部５１２を経て、ＳＳ７網側のＳＴＰ２０に送信される。

なお、図５、図６に示したＭＴＰＣ５０の各部（処理手段）は、ＭＴＰＣ５０に搭載されたプロセッサに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することもできる。

［シーケンス番号を用いた送達確認］
本実施形態において、レイヤ２でのプロトコル変換時に、より望ましくは以下の処理が行われる。ＳＳ７網とＩＰ網でメッセージ中継する際、メッセージ内のシーケンス番号をリンクのＥｎｄ ｔｏ Ｅｎｄ送達確認に利用することができる。従って、本実施形態では、ＳＳ７網側のＳＴＰ２０とＩＰ網側のＩＰ−ＳＴＰ３０で送達確認を実施することができる。

ここで、図７〜図１０を参照してＭＴＰ２メッセージのフォーマットについて説明する。ＭＴＰ２メッセージのフォーマットには、フィールドが設けられているが、信号ユニット毎にメッセージフォーマットが若干異なる。

図７は、信号ユニットの一つであるＭＳＵ（Ｍｅｓｓａｇｅ Ｓｉｇｎａｌ Ｕｎｉｔ；有意信号ユニット）のフォーマットを示している。図８は、信号ユニットの一つであるＬＳＳＵ（Ｌｉｎｋ Ｓｔａｔｕｓ Ｓｉｇｎａｌ Ｕｎｉｔ；リンク状態信号ユニット）のフォーマットを示している。図９は、信号ユニットの一つであるＦＩＳＵ（Ｆｉｌｌ Ｉｎ Ｓｉｇｎａｌ Ｕｎｉｔ；フィル・イン信号ユニット）のフォーマットを示している。図１０は、図７〜図９の各フィールドの内容を説明するための図である。

図７〜図９のＭＴＰ２の信号フォーマット上で、ＦＳＮ（順方向シーケンス番号）がある。これは送出される信号ユニットのシーケンス番号を設定するフィールドである。本実施形態では、このシーケンス番号は０〜１２７までを許容する。一方、ＢＳＮ（逆方向シーケンス番号）は、応答として返す受信信号ユニットのシーケンス番号を示すが、これも同様に０〜１２７まで設定可能とする。

これは、ＩＴＵ−ＴのＱ．７００シリーズ勧告において、ＭＴＰ２における送出される信号ユニットのシーケンス番号は０から１２７の範囲という規定にも整合する。一方で、ＩＰ網側のレイヤ２のＭ２ＰＡのシーケンス番号については、前記勧告上、０〜６５５３５まで拡大されている（なお、ＲＦＣ４１６５ではＭ２ＰＡのシーケンス番号の範囲は、０〜１６，７７７，２１５と規定されている。）。このため、ＭＴＰ２とＭ２ＰＡのシーケンス番号数に差異があることになる。

ＭＴＰＣ５０のプロトコル変換においてシーケンス番号のマッピング変換を行う際、Ｍ２ＰＡ処理部５２１は、ＩＰ網側の対向装置であるＩＰ−ＳＴＰ３０を含め、シーケンス番号を０〜１２７に限定し、マッピング変換を行うものとする。また、本実施形態では、Ｍ２ＰＡ側についても、回線帯域は、ＭＴＰ２側の６４ｋｂｐｓ乃至４８ｋｂｐｓ以上に利用することはできないようにしている。

上記シーケンス番号制限のメリットを検討するために、仮に、Ｍ２ＰＡ側とＭＴＰ２側でシーケンス番号の制限数を合わせない場合を想定する。この場合、メッセージ受信時、ＭＴＰＣ５０が、Ｍ２ＰＡ側の装置ＩＰ−ＳＴＰ３０とＭＴＰＣ５０、及び、ＭＴＰＣ５０とＳＴＰ２０において、各々の装置で送達確認の実施が必要になってしまう。これは即ち、ＭＴＰＣ５０が、レイヤ２として終端し、バッファを持つことを意味する。

一方、本実施形態では、ＭＴＰＣ５０でレイヤ２通信を終端させないため、ＭＴＰＣ５０がバッファを持つ必要がなく、シーケンス番号のマッピングも不要になる、という利点がある。またこの利点は、単にバッファの省略を実現するに止まらず、ＳＳ７網、ＩＰ網への影響を最小化し、現有のリソースを最大限活用でできるという副次的効果を奏する。

続いて、本実施形態のＭＴＰＣ５０における具体的な動作について説明する。上記参考例と、本実施形態とを対比すると、上記参考例と、本実施形態との差異は、以下の２点に集約される。
・本実施形態では、ＳＳ７網側のＳＴＰとＩＰ網側のＩＰ−ＳＴＰとの間に、ＭＴＰＣがある。
・参考例ではレイヤ３までの確認と、ＯＰＣ／ＤＰＣの参照で正確に転送し、これらポイントコード（ＰＣ）を保持している。またプロトコル変換をしないので、通信を一旦終端させている。これに対し、本実施形態ではレイヤ２までの確認とプロトコル変換の実施で、通信を終端させないため、各網でプロトコル差異を意識させない。

続いて、本実施形態のＭＴＰＣ５０における、レイヤ２変換の具体的な動作について、シーケンス図を用いて説明する。以下の説明では、次の各動作の変換例について説明する。
（１）リンク確立する場合
（２）リンク確立＆単純にマッピングする場合
（３）死活監視した場合
（４）リンク障害を検出した場合

（１）リンク確立
図１１は、ＳＳ７網とＩＰ網側ノード間のリンク確立を行う際のシーケンスを示す。まず、信号リンク確立のため、信号リンク初期設定手順を踏むが、これは新設リンクあるいは障害検出されたリンクの運用のために、対向局との間において実施される手続きである。この初期設定手順は、初期設定すべき信号リンクに対してのみ適用され、リンク状態信号ユニット（ＬＳＳＵ）の状態表示（ＳＦ）に設定される。

○リンク状態確認
最初にリンク状態を確認する。図１１において、ＳＳ７網側のＳＴＰ２０でリンク起動されると、ＭＴＰＣ５０に対し、ＭＴＰ２のＬＳＳＵにＳＩＯ（Ｓｔａｔｕｓ Ｉｎｄｉｃａｔｉｏｎ “Ｏｕｔ ｏｆ ａｌｉｇｎｍｅｎｔ”）が設定されたメッセージが送信される（ステップＳ００１）。このＳＩＯが設定されたメッセージは、信号リンクが起動され、かつ、ＳＩＯ、ＳＩＥのいずれも受信されない時に送出される。

ＭＴＰＣ５０は、ここで、Ｍ２ＰＡへ変換、つまりＳＩＯをＬｉｎｋ Ｓｔａｔｕｓ Ａｌｉｇｎｍｅｎｔに変換し、ＩＰ網側のＩＰ−ＳＴＰ３０に対し、変換後のメッセージを送信する（ステップＳ００１ａ）。ＩＰ−ＳＴＰ３０は信号リンクの起動を確認し、リンク確立承認が行われると、ＭＴＰＣ５０に対し、Ｌｉｎｋ Ｓｔａｔｕｓ（Ａｌｉｇｎｍｅｎｔ）を返信する（ステップＳ００２ａ）。ＭＴＰＣ５０は、受信したＭ２ＰＡメッセージをＭＴＰ２メッセージに変換して、ＳＴＰ２０に対し、ＳＩＯ設定のＬＳＳＵを送信する（ステップＳ００２）。

○リンク状態立証
ＳＴＰ２０は、ＭＴＰＣ５０から受信したＭＴＰ２メッセージのＬＳＳＵ（リンク状態信号ユニット）のＳＦにて指定されたノード間のリンク状態を確認した後、リンクを確立する。次に、ＳＴＰ２０は、ＳＦ（状態表示）にＳＩＥを設定したメッセージを送信する（ステップＳ００３）。なお、ＳＩＥ（Ｓｔａｔｕｓ Ｉｎｄｉｃａｔｉｏｎ “Ｅｍｅｒｇｅｎｃｙ ａｌｉｇｎｍｅｎｔ”）は信号リンクを起動後、ＳＩＯ又はＳＩＥを受信した場合に送出される。

前記ＬＳＳＵ−ＳＦ（ＳＩＯ）を受信したＭＴＰＣ５０は、Ｍ２ＰＡメッセージに変換するため、ＳＩＥをＬｉｎｋ Ｓｔａｔｕｓ（Ｐｒｏｖｉｎｇ）に変換し、ＩＰ−ＳＴＰ３０に対し、前記変換後のへメッセージを送信する（ステップＳ００３ａ）。ＩＰ−ＳＴＰ３０は、リンク確立を確認すると、ＭＴＰＣ５０に対し、Ｌｉｎｋ Ｓｔａｔｕｓ（Ｐｒｏｖｉｎｇ）を返信する（ステップＳ００４ａ）。ＭＴＰＣ５０は受信したＭ２ＰＡメッセージをＭＴＰ２メッセージに変換して、ＳＴＰ２０に対しＳＩＥ設定のＬＳＳＵを送信する（ステップＳ００４）。

なお、ここでは、信号リンクが正常なので、ＳＴＰ２０からＭＴＰＣ５０に対しＦＩＳＵ（図９参照）が送信される（ステップＳ００５）。ＦＩＳＵは、周期的に送出され、ＭＴＰＣ５０は、ＳＴＰ２０に対してＦＩＳＵを応答する（ステップＳ００６）。

この状態で、レイヤ２でのプロトコル変換とリンク確立は出来ているが、ＳＴＰ２０からのＦＩＳＵ受信により、Ｍ２ＰＡ側のＩＰ−ＳＴＰ３０にリンク確立化完了を伝えるため、ＭＴＰＣ５０は、ＩＰ−ＳＴＰ３０との間で、Ｌｉｎｋ Ｓｔａｔｕｓ（Ｒｅａｄｙ）を送受信する（ステップＳ００７ａ、Ｓ００８ａ）。

（２）リンク確立＆単純にマッピングする場合
図１２は、ＳＳ７網とＩＰ網側ノード間のリンクが確立済みで、レイヤ２の変換のみ行う際のシーケンスを示している。

ＳＴＰ２０からＭＴＰＣ５０に対し、ＦＩＳＵが送信される（ステップＳ１０５）。ＭＴＰＣ５０は、このＦＩＳＵを、Ｍ２ＰＡに変換する。本例では、すでにリンク確立済なので、ＭＴＰＣ５０は、空（ｅｍｐｔｙ）メッセージをＩＰ−ＳＴＰ３０に送信する（ステップＳ１０５ａ）。

ＩＰ−ＳＴＰ３０は、リンク確立済みであることを確認できると、ＭＴＰＣ５０に対し空（ｅｍｐｔｙ）メッセージを送信し（ステップＳ１０６ａ）、ＭＴＰＣ５０は、ＭＴＰ２メッセージに変換し、ＳＴＰ２０に対しＦＩＳＵを送信する（ステップＳ１０６）。

この処理では、シーケンス番号としてのＦＩＳＵ／ｅｍｐｔｙのマッピングを行っていることになる。

（３）死活監視の場合
図１３は、ＳＳ７網とＩＰ網側ノード間のリンクが確立済みで、対向装置の死活監視を行う場合のシーケンスを示している。前述のとおり、ＳＴＰ２０は、所定の周期でＭＴＰＣ５０に対しＦＩＳＵを送信し、ＭＴＰＣ５０はＦＩＳＵを返信する（ステップＳ２０１、Ｓ２０２）。ＭＴＰＣ５０は、Ｍ２ＰＡメッセージへ変換せず、独立した制御を行う。なお、図１３の例では、Ｍ２ＰＡ側の死活監視に関しては、別ノードで行われるものとしている。

（４）リンク障害を検出した場合
図１４は、ＳＴＰ２０とＭＴＰＣ５０間又はＭＴＰＣ５０とＩＰ−ＳＴＰ３０間に障害が発生している場合のシーケンスを示す。

ＭＴＰＣ５０は、ＳＴＰ２０との間のリンク障害を検出した場合には、他方に対してリンク障害通知をする。具体的には、ＭＴＰＣ５０は、ＳＴＰ２０のリンク障害を検出すると、ＩＰ−ＳＴＰ３０に対し、Ｍ２ＰＡメッセージのＬｉｎｋ Ｓｔａｔｕｓ（Ｏｕｔ ｏｆ Ｓｅｒｖｉｃｅ）を送信する（ステップＳ３０１ａ）。

また、ＭＴＰＣ５０は、ＩＰ−ＳＴＰ３０との間のリンク障害を検出すると、ＳＴＰ２０に対し、ＬＳＳＵにＳＩＯＳを設定したＭＴＰ２メッセージを送信する（ステップＳ３０２）。なお、ＳＩＯＳは、Ｓｔａｔｕｓ Ｉｎｄｉｃａｔｉｏｎ “Ｏｕｔ ｏｆ Ｓｅｒｖｉｃｅ”の略であり、自ノードが送受信不可能な状態にあることを相手ノードに通知する場合に送出される。

最後に、本実施形態から導かれる効果についてまとめる。ＡＬＬ−ＩＰ化に向けて、プロトコル変換装置乃至シグナリングゲートウェイを全国配置した場合、参考例に示したようなＩＰ−ＳＴＰを設置する方法と、本実施形態のＭＴＰＣを設置する方法が考えられる。本実施形態のＭＴＰＣを設置する方法の方が、以下の２点で優れている。

・各装置でのバッファ軽減
参考例のＩＰ−ＳＴＰやＳＴＰではレイヤ３で変換し、通信を終端しているが、本実施形態のＭＴＰＣは通信を終端しない。レイヤ２変換の実施で、通信終端させず、通信を一対一で実施させている。例として、参考例では、ＩＰ−ＳＴＰとＳＴＰの装置間でレイヤ３での通信を傍受するが、一旦各装置で通信を終端させ、シーケンス番号の保持が必要になる。また、リンク障害の場合、参考例では、ＭＴＰ３信号のＣＯＯ／ＣＯＡ／ＸＣＯ／ＸＣＡ信号で到達済みのシーケンス番号を通知する必要があり、それには、各装置がＭＴＰ３信号を捕まえて中身の書換が必要になる。

一方、本実施形態のＭＴＰＣでは、シーケンス番号の書換は実施せず、レイヤ２の変換を実施し、バッファを抱えないで済むという利点がある。

・ＡＬＬ−ＩＰ化における費用面でのメリット
上記したとおり、本実施形態のＭＴＰＣは単純構成で安価な開発ができる。一般に下位レイヤの処理を行うソフトウェアは、上位レイヤの処理を行うソフトウェアに比べ、比較的単純な構造のため安価になる。反対に、上位レイヤになる程、また１つ目の利点として挙げたバッファ保持により、ソフトウェアは複雑な構成を取るので、高額なソフト開発が必要になる。

一方、本実施形態のＭＴＰＣでは、低位レイヤに着目し開発とバッファを保持しない方式を採っている。これにより、参考例のＩＰ−ＳＴＰに比べ、安価な製品として提供することが可能となる。これは、ＡＬＬ−ＩＰ化に向けて、ＴＤＭ区間短縮とＳＩＧＴＲＡＮ網を増強する際、費用面でＩＰ−ＳＴＰよりも、ＭＴＰＣを全国配置する方が優位である。具体的には、ＡＬＬーＩＰ化の対応のため、参考例のＩＰ−ＳＴＰを用いてＳＳ７網とＩＰ網を接続しようとすると、全国に数千単位のＩＰ−ＳＴＰを設置する必要がある。これは、理論的には可能であるが、設置と開発コストが高額になる。

一方、ＡＬＬーＩＰ化の対応に、本実施形態のＭＴＰＣを用いることで、開発、設置、工事、維持管理の費用を大幅に低減することが可能となる。特に、ＭＴＰＣの設置箇所が全国規模となり、その設置数量が多い程、その差は顕著となる。また本実施形態のＭＴＰＣを用いることで、ＴＤＭ区間を短縮したいという通信キャリア事業者からの要望にも応えることが可能となる。

以上、本発明の各実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、各図面に示したネットワーク構成、各要素の構成、メッセージの表現形態は、本発明の理解を助けるための一例であり、これらの図面に示した構成に限定されるものではない。

また、上記した実施形態では公衆交換電話網がＳＳ７（Ｃｏｍｍｏｎ Ｃｈａｎｎｅｌ Ｓｉｇｎａｌｉｎｇ Ｓｙｓｔｅｍ Ｎｏ．７）網であるものとして説明したが、その他の共通線信号方式であってもよい。また、上記した実施形態ではＭＴＰ２メッセージと、Ｍ２ＰＡメッセージとを相互に変換するものとして説明したが、これらの派生プロトコルや後継プロトコルが含まれることは勿論である。

最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点によるプロトコル変換装置参照）
［第２の形態］
上記したプロトコル変換装置の前記プロトコル変換部は、前記公衆交換電話網と前記ＩＰ網との間の通信を終端せずに、プロトコル変換を行うことが好ましい。
［第３の形態］
上記したプロトコル変換装置は、前記公衆交換電話網側のＳＴＰと、前記ＩＰ網側のＩＰ−ＳＴＰとの間に配置されることが好ましい。
［第４の形態］
上記したプロトコル変換装置は、さらに、前記公衆交換電話網側のＳＴＰと所定のメッセージを授受することにより、リンクの死活監視を行う機能を備えることが好ましい。
［第５の形態］
上記したプロトコル変換装置は、さらに、前記公衆交換電話網側のＳＴＰ及び前記ＩＰ網側のＩＰ−ＳＴＰのいずれか一方との間のリンク障害を検出した場合に、他方の装置に対し、リンク障害を通知する機能を備えることが好ましい。
［第６の形態］
（上記第２の視点によるメッセージ中継方法参照）
［第７の形態］
（上記第３の視点によるメッセージ中継方法参照）
［第８の形態］
（上記第４の視点によるプログラム参照）
なお、上記第６〜第８の形態は、第１の形態と同様に、第２〜第５の形態に展開することが可能である。

なお、上記の特許文献の開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１０、９１０ ＳＣＰ
２０、９２０ ＳＴＰ
３０、９３０ ＩＰ−ＳＴＰ
４０、９４０ ＣＡ
５０ ＭＴＰＣ（ＭＴＰ Ｃｏｎｖｅｒｔｅｒ）
５１ プロトコル変換部
１００ 公衆交換電話網側装置
２００ プロトコル変換装置
３００ ＩＰ網側装置
５１１ ＭＴＰ２処理部
５１２ ＭＴＰ１処理部
５２１ Ｍ２ＰＡ処理部
５２２ ＳＣＴＰ処理部
５２３ ＩＰ処理部
５２４ Ｅｔｈｅｒ処理部
９３０ ＩＰ−ＳＴＰ

Claims (9)

1. 共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置され、
   前記公衆交換電話網と、前記ＩＰ網間で授受されるメッセージについて、
   前記公衆交換電話網のレイヤ２のＭＴＰ２メッセージと、前記ＩＰ網側のレイヤ２のＭ２ＰＡメッセージとを相互に変換するプロトコル変換部を備えたこと、
   を特徴とするプロトコル変換装置。
2. 前記プロトコル変換部は、前記公衆交換電話網と前記ＩＰ網との間の通信を終端せずに、プロトコル変換を行う請求項１のプロトコル変換装置。
3. 前記プロトコル変換装置は、前記公衆交換電話網側のＳＴＰと、前記ＩＰ網側のＩＰ−ＳＴＰとの間に配置される請求項１又は２のプロトコル変換装置。
4. さらに、前記公衆交換電話網側のＳＴＰと所定のメッセージを授受することにより、リンクの死活監視を行う機能を備える請求項１から３いずれか一のプロトコル変換装置。
5. さらに、前記公衆交換電話網側のＳＴＰ及び前記ＩＰ網側のＩＰ−ＳＴＰのいずれか一方との間のリンク障害を検出した場合に、他方の装置に対し、リンク障害を通知する請求項１から４いずれか一のプロトコル変換装置。
6. 共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置されたプロトコル変換装置が、
   前記公衆交換電話網側から受信したメッセージからレイヤ２のＭＴＰ２メッセージを取り出してレイヤ２のＭ２ＰＡメッセージに変換するステップと、
   前記変換後のレイヤ２のＭ２ＰＡメッセージを、ＩＰ網側に送信するステップと、
   を含むメッセージ中継方法。
7. 共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置されたプロトコル変換装置が、
   前記ＩＰ網側から受信したメッセージからレイヤ２のＭ２ＰＡメッセージを取り出してレイヤ２のＭＴＰ２メッセージに変換するステップと、
   前記変換後のレイヤ２のＭＴＰ２メッセージを、公衆交換電話網側に送信するステップと、
   を含むメッセージ中継方法。
8. 共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置されたプロトコル変換装置に搭載されたコンピュータに、
   前記公衆交換電話網側から受信したメッセージからレイヤ２のＭＴＰ２メッセージを取り出してレイヤ２のＭ２ＰＡメッセージに変換する処理と、
   前記変換後のレイヤ２のＭ２ＰＡメッセージを、ＩＰ網側に送信する処理と、
   を実行させるプログラム。
9. 共通信号線方式を用いた公衆交換電話網とＩＰ網との間に配置されたプロトコル変換装置に搭載されたコンピュータに、
   前記ＩＰ網側から受信したメッセージからレイヤ２のＭ２ＰＡメッセージを取り出してレイヤ２のＭＴＰ２メッセージに変換する処理と、
   前記変換後のレイヤ２のＭＴＰ２メッセージを、公衆交換電話網側に送信する処理と、
   を実行させるプログラム。

Images