IP相互接続による通信事業者どうしの直接接続を可能とするため、PSTN（Public Switched Telephone Network：公衆交換電話網）が提供している信号の中継機能や番号ポータビリティ機能をIP網で実現することになります。これらの機能を可能とするための新規設備として、ENUM（E.164 NUmber Mapping）/DNS（Domain Name System）とNNI-SBC（Network-Network-Interface Session Border Controller）を導入しています。
ENUMは、E.164番号＊1をインターネットのIPアドレス体系と統合させる国際規格です。E.164番号を管理し、電話番号を接続先事業者情報に番号解決するのがENUMサーバとなります。各事業者のENUMは各事業者の管理する番号帯の番号ポータビリティ接続情報（番ポ情報）を保持しており、NTT東日本・西日本（NTT東西）ENUMが番号管理元事業者のENUMへ問い合わせることにより、接続先番号が移転しているかを確認します。
NTT東西では従来番ポ情報を加入者交換機で管理していましたが、IP-POI（Point of Interface）からの番ポ問合せに対応するために、番ポ情報をENUMに移行しました。PSTNマイグレーション移行期においては、STM-POI/IP-POI双方からの番ポ問合せに対応するため、交換機およびENUM双方に番ポ情報を設定し保持していました。2025年の移行完了後は、ENUMによる番ポ情報管理・番号解決に一本化しています。
IP相互接続では、通信の確立や切断などのセッション制御を行うためのプロトコルとしてSIP（Session Initiation Protocol）が利用されます。IP直接接続の相互接続性を担保するため、一般社団法人情報通信技術委員会（TTC）では標準 JJ-90.30が制定されていますが、JT-Q3401に基づき実装されてきたNGN（Next Generation Network）網内信号と、網間の標準化された信号には、その仕様に差分があります。この信号差分に対しては、NNI-SBCが具備する信号編集機能（マニピュレーション機能）を用いて網内信号と網間信号を相互に変換することで、NGN網内のSIPサーバの開発コスト圧縮や網内信号仕様の終端処理を行っています。また、NNI-SBCは接続先事業者により許容するベアラ条件やコーデックの許容・非許容が設定可能なことで柔軟な接続形態に対応し、音声処理では高速なNAPT（Network Address Port Translation）変換やQoS（Quality of Service）制御を行います。

＊1 E.164番号：ITU-T E.164で定められている形式の電話番号。

事業者間においては、コアネットワークをIP化する際の技術的な課題が議題にあがりました。特に、相互接続におけるインタフェースのあり方が議論となり、JJ-90.10相互接続共通インタフェース仕様（ISUP）と比較し、SIP信号では実現できない方式が多数あることから、SIP信号で標準化されていないISUP信号を、どのような用途で利用しているか調査を実施しました。
SIP信号の標準化においては、すでにNGNにおいてNTT東西間でIP接続を実現しており、その接続方式として2007年にTTCで制定されたJT-Q3401が存在していました。しかし、国際標準の世界では、3GPP（3rd Generation Partnership Project）にて2008年にTS-29.165が存在しており、移動通信網では3GPPの仕様が実装の基準となっていました。本取り組みを完遂するには固定・移動網双方の接続が必要であり、双方の接続仕様を合わせる必要があったことから、相互接続性を担保する新たな方式として、TS-1020が制定されました^{（1）～（3）}。
また、上記に合わせ、IP網における番号ポータビリティの要件の議論も行われました。
PSTNでは、各事業者網において番号解決を行う際、NTT東西から他事業者への片方向番ポであったことから、まずNTT東西網に接続し、NTT東西網で番号帯により接続網を特定していました。加えて、番号ポータビリティの対象となっている番号帯においては、NTT東西網で番号を保有する事業者に番号でルーチングし、番号を保有する事業者がどの事業者網に番号が移転しているか特定したうえで、発信事業者に対し、NTT東西網から接続先を特定するNRN（Network Routing Number）＊2を返送することで番号解決を行っていました。
一方、IP網では、PSTNとは異なり、番号取得事業者網が提供するコーデックや付加サービスの提供条件に左右されず、番号取得事業者の呼制御サーバに障害が発生している際においても、番号解決が可能となる「発側データベース参照方式」を採用することが事業者間で合意できたことから、本方式の標準化が開始されました。3GPP標準等で利用されるキャリアENUMを採用し、2015年にJJ-90.31「キャリアENUMの相互接続共通インタフェース」として制定され、同じ2015年にTS-1020からJJ-90.30として制定された「IMS事業者網間の相互接続共通インタフェース」^（4）に対し、JJ-90.31に対応した改版が行われました。
図1にIP-IP接続における呼処理の接続方法を示します。

＊2 NRN：移転先事業者網を特定可能なネットワークルーチング番号。

まず、IP網において回線保留の代わりに「コールバック」での導入が可能になったことから、緊急通報回線のIP網での導入に向けIP接続に必要な要件をまとめ、事業者間で方式・要件について合意を行いました。必要要件に基づき、IP網での緊急呼接続を可能とするためのJJ-90.28「緊急通報呼に関するNNI仕様」について標準化を行いました。また、事業者意識合わせの場において、IP接続に必要な要件や事業者間料金精算に必要な要件が整理され、TTCに対し「標準化要望」が出されたことから、信号制御委員会において要望された要件に基づき、JJ-90.30「IMS事業者網間の相互接続共通インタフェース」、JJ-90.31「キャリアENUMの相互接続共通インタフェース」の改版が行われました。
また、事業者網間を接続する要件として、IPレベルでの事業者間の接続プロトコルやIPアドレス付与条件が整理されるとともに、各事業者のドメイン名等についても整理されたことから、ドメインからIPアドレスを解決する方法について、JJ-90.32「SIPドメイン解決のためのDNS相互接続共通インタフェース」が制定されました。加えて、INS（Information Network System）ディジタル通信モードを暫定的に利用することを希望するユーザ保護を目的に、INS代替サービスの導入を実現する必要があったことから、他の標準化活動と同様にINS代替サービスを利用する事業者間で議論を踏まえた要望に基づき、TS-1025「ISUP情報のカプセル化に関する技術仕様」の制定を行いました。

ENUMでは、接続インタフェースを運用面と試験面に割り当てを行い、このインタフェース単位でENUM応答を切り替えることで、運用中の事業者と接続前事業者が混在する環境においても自社の網内着信先を振り分けることを可能としました。この機能を活用して、自社の網内ルーチング試験や、他社と事前接続試験を行う際の試験設備への接続、IP相互接続開始時の試験設備から運用設備への接続切替制御を行っています。

JJ-90.30では、事業者網間の相互接続性を向上させるためのオプション項目が規定されており、NNI-SBC機能で具備されている基本機能と信号編集機能を組み合わせてオプション項目の条件を満たすインタワーク（信号変換）を実現しています。保守運用機能としては、IP相互接続の実現に向けた他社との接続試験を容易にできるように、自網内のインタフェースを運用インタフェースと試験インタフェースの2面構成にして、各事業者とは商用接続開始前にIP相互接続をNNI-SBCの試験インタフェースを経由して自社の試験設備と接続し、事前接続試験を行える機能を具備しています。試験インタフェースと運用インタフェースのどちらを利用するのかは、ENUM応答値によって定まる設計を行っており、試験ドメインと運用ドメインの変更だけで、NNI-SBCから網内設備の接続先を試験設備と運用設備のどちらに接続するのかを切り替えできる仕組みにして、安全なIP相互接続を開始できる方法を確立しています。また、商用サービス開始前に網間から網内装置へのルーチング設定を確認できるように、NNI-SBCでSIP信号を折り返すことで網内の試験をする機能を具備しています。
これらの機能により、IP相互接続前の事業者とIP相互接続後の事業者が混在する環境において、NNI-SBCとENUMの設定により接続を切り替える仕組みを活用して、事前接続試験環境を用いた試験からIP相互接続開始までを円滑に実現しています。

PSTNマイグレーションを実施するにあたり、中継網IP化対応、JJ-90.30対応、緊急通報指令台収容の機能を具備しています。中継網IP化対応としては、維持限界を迎える共通線交換機や中継交換機を撤廃するため、ISUP・SIP変換装置が直接加入者交換機を収容する接続形態としISUPをSIPに置き換えています。また、網間インタフェースのJJ-90.30対応に基づき、NNI-SBCの信号インタワークでは吸収しきれない信号は、発側や着側の加入者SIPサーバで呼制御信号の標準化対応を実施しています。例としては、転送呼において発番号を保持するSIP信号を網間インタフェースに準拠にするように変更しました。また、メタル収容装置も維持限界がいずれ訪れるため、メタル収容装置で収容している緊急通報指令台を加入者SIPサーバに収容できる機能として、緊急通報指令台からの呼び返し機能、緊急特番通知機能、発ID取得機能、緊急通報指令台からの呼び返し呼を確実に着信させることができるユーザ発着信防止機能などを実現しました。
さらに、STM-POI接続からIP-POI接続へ円滑に移行するにあたり、ひかり電話発他事業者着、他事業者発メタルIP電話着、メタルIP電話発他事業者着のステップで切り替えるため、番号帯ごとに番号ルーチングからドメインルーチングに切り替えできる機能や、IP相互接続の開始前にドメインルーチングの確認を行うためにENUMの問合せ先を選択できる試験機能を具備しました。

各社とのIP相互接続開始に向け、NNI-SBC、ENUM等のIP-POI接続用装置は短期間の設備構築完遂が求められる中で、効率的な構築と確実な商用運用開始、その実現に向けた手順確立、マニュアル整備、習熟のための商用ネットワーク環境を利用した品質確保試験を実施しています。商用サービスの設備規模で、負荷試験や冗長切替試験、伝送路も含めた装置故障を模擬した試験や予防保全としての取替・切替手順を実施し、システムトータルの品質確保を行いました。また、他事業者との従来のSTM-POIからIP-POIに切り替える際には、段階的な切替に応じたサービス影響確認を行って品質確保する取り組みを行っています。

NNI-SBCの呼制御のインタワークの仕様を明確にするために、接続方向や接続先サーバの種別ごとにSIP信号のメッセージ、ヘッダ、パラメータまでのインタワーク信号処理をドキュメント化しました。また、問題発生時にはNNI-SBC自身の不具合だけでなく、NNI-SBC以外の装置で発生した不具合をNNI-SBCの信号編集機能を活用して対処するケースがあったことから、NNI-SBCの信号編集設定を変更した場合に迅速に品質確認する必要がありました。そのため、NNI-SBCの呼制御信号インタワーク処理試験において、疑似呼装置を試験シナリオに応じて自動制御することで、試験の自動実行、入出信号パケットキャプチャの自動取得、取得したパケットキャプチャから入出信号を抽出しその呼制御の信号シーケンスのチェックおよびヘッダやパラメータのインタワーク処理の自動チェック、自動で試験を実施した試験結果の自動集計に取り組むことで、品質確保の迅速化、目視によるチェックミスを防止しています。

商用サービスに向けて構築した、NNI-SBCとENUM/DNSのサービス提供開始前設備を活用して、終局トラフィック相当の試験条件で品質試験を実施しました（図2）。
試験では、定常状態におけるシステムの安定運用の確認に加えて、運用の習熟に向けた保守手順および各種装置故障時の回復手順を確立しました。
併せて、NTT東西網内・他事業者間のネットワークにおける保守作業や装置故障による影響についても確認しました。
これらの確認より、例えば、ネットワーク装置の故障発生時におけるNNI-SBCのSIP信号、ENUM/DNS信号、内部制御信号の再送間間隔やリトライ回数の見直しにより、信号疎通能力の改善を行いました。また、ネットワーク復旧時のストームコントロールの設定やスイッチのポートにおける起動順番の見直しにより、ネットワークの切替復旧時間の短縮化を実現しました。さらに、ルータやスイッチのファームウェアのバージョンアップなどの計画的な保守作業に対して、装置の迂回や切替を実施する制御ポイントを明確にした手順を確立したことにより、サービス影響の最小化を実現しました。

PSTNにおいては、事業者間の接続はNTTのPSTNを経由して相互接続が実現されていました。また、通信事業者は、NTT交換機のインタフェース仕様に合わせるだけで簡単に相互接続が可能でした。
前述のとおり、IP相互接続では呼制御プロトコルとしてSIPを用います。SIPの標準化は行われましたが、接続のためにはメッセージの1つひとつが整合している必要があります。各通信事業者がフルメッシュで接続するため、1社でも仕様に差異があると相互接続の支障となり、PSTNマイグレーションの阻害要因となります。
このため、IP相互接続および相互接続試験に先立ち、各通信事業者の技術的条件等を確認するため、各通信事業者がフルメッシュで事前接続試験を実施しています。
試験項目は、基本呼接続（正常・準正常動作）、代表的な付加サービス（着信転送サービス、コールウェイティング、DTMF等）、緊急呼等の3桁特番接続、およびNNI-SBC、ENUM/DNSにおける故障検知、迂回動作、復旧検知等の保守運用項目を各通信事業者の共通試験項目（110項目）としています。これに、各社固有のサービス呼や付加サービスバリエーション、端末バリエーション等の各社独自試験項目を加えて事前接続試験項目としました。
共通試験項目について、各通信事業者が協力して、SIPシーケンス、メッセージ例を確認し、共通シーケンスを作成しています。机上での事前確認作業、実機での接続試験実施による試験ログ確認の2段階で、SIPシーケンス・メッセージを確認することで品質向上を図りました。この共通シーケンスは、「IMS事業者網間の相互接続共通インタフェースシーケンス/メッセージ例」^（5）としてまとめられるとともに、一部はJJ-90.30等の標準ドキュメントに反映されています。
各通信事業者との事前接続試験は、呼種ごとの切替ステップを踏まえ、2020年11月よりひかり電話発着・メタルIP電話着より開始しました。以降は切替の進行に応じて、メタルIP電話発、サービス呼と順次試験を実施し、2024年12月にすべての事前接続試験が完了しました。NTT東西累計で約1.1万項目の試験実施により品質向上を図ることで、円滑な事業者間IP相互接続開始を可能にしました。

メタルIP電話発他事業者着切替では多数の電話サービスおよびNGN・PSTN・他事業者の複数網への接続や県域、エリア、全国、事業者単位の段階的な切替があり、検証パターンは無数に考えられ、すべてのパターンを網羅的に検証するには非常に多くの時間がかかります。必要なパターンの抜け漏れがないように、検証するパターンの絞り込みを以下に重点を置いて行いました。
（1）　ユーザ利用シーンの整理
ユーザの電話サービス利用シーンとしては、音声通話を基本呼とし、コールウェイティングや転送などの付加サービスを用いた「使い方」と、同一市内発着、東発西着等の「接続先」を2つの軸としました。検証においては、「接続先」は発着網の組合せ（NGN・PSTN・他事業者）や接続先（県内・県間・他事業者）、番号帯（NGN番号・PSTN番号）等、お客さまの接続先ルートを横軸として、「使い方」は付加サービスありでの発着信や特番（1XY）系のダイヤルバリエーション等のサービス観点を縦軸とし、2軸のマトリクスで網羅性を整理し、接続品質およびサービス品質を確認しました。
（2）　切替工事ごとの影響範囲の明確化
切替工事ごとに上記で作成したマトリクス上に影響範囲をマッピングすることで、切替工事ごとの影響範囲を明確にしました。その際、なるべく効率的に実施できるように、過去トラブルや切替工事ごとの検証実績を踏まえて実施済みパターンは省略するなど、切替範囲拡大に応じた見極めを実施しました。

■参考文献
（1）　永徳：“3GPPにおけるIP相互接続仕様の標準化動向, ”　NTT技術ジャーナル，Vol. 32, No. 9, pp. 107-111, 2020.
（2）　坂谷・荒井・鐘ヶ江：“IP相互接続仕様に関する標準化活動，”NTT技術ジャーナル，Vol.26, No. 7, pp. 63-65, 2014.
（3）　小川・上茶：“緊急通報の標準化動向とIP網間インタフェース仕様の標準化，”NTT技術ジャーナル，Vol. 30, No. 2, pp. 57-61, 2018.
（4）　https://www.ttc.or.jp/document_db/information/view_express_entity/300
（5）　https://www.ttc.or.jp/document_db/information/view_express_entity/1376