WO2004077792A1

WO2004077792A1 - プロトコル変換装置及び方法

Info

Publication number: WO2004077792A1
Application number: PCT/JP2004/001407
Authority: WO
Inventors: Masayuki Sakata; Masahiko Kojima
Original assignee: Nec Corporation
Priority date: 2003-02-26
Filing date: 2004-02-10
Publication date: 2004-09-10
Also published as: US20060159121A1; JPWO2004077792A1; JP4010330B2; EP1599010A1; CN1754369A; EP1599010A4

Abstract

ＩＷＦ装置（３）は、シグナリングを制御するＣプレーン装置であるＩＷＦ−ｃ（３１）と、ユーザデータを制御するＵプレーン装置であるＩＷＦ−ｕ（３２，３３）とに分離されている。これにより、スケーラビリティに富んだ構成をとることができる。

Description

明細書プロトコル変換装置及び方法技術分野

本発明は、プロトコル変換装置及び方法に関し、特に、互いに異なる物理回線を利用する装置同士を接続する際に適用されるプロトコル変換装置及び方法に関する。 . 背景技術

WCDMA (Wi d e b a n d CDMA) システムにおける無線インタフエースのプロトコルアーキテクチャには物理レイヤ (レイヤ 1) と、データリンクレイヤ (レイヤ 2) と、ネットワークレイヤ (レイヤ 3) とがある。また、レイャ 2においては、制御信号を転送するシグナリングのための Cプレーン (C-P l a n e) と、ユーザ情報を転送する Uプレーン（U— P l a n e) とがある。異なる物理回線を利用する装置を接続する際には、 IWF (I n t e r Wo r k i n g F 1 n c t i p n) 装置がプロトコル変換装置として適用されている。従来の IWF装置は、その構成において上記の C一 P 1 a n eと U_P 1 a n eとに分離されていない（例えば、文献 1 (3GPP TR 25. 933 V 5. 2. 0 (2002-09) ) 参照) 。

このため、実際に C— P 1 a n eと U—P 1 a n eとが分離された構成にすると、各プロトコルをどのように終端するか、リソース確保のためのパラメータをどのように取得するかというようなリソース確保の方法に問題が生じ、 U— P 1 a n eが増減するといったスケーラビリティに富んだ構成をとることができなレ、。リソース確保については、上記の文献 1において何も記載されていない。発明の開示

本発明はこのような課題を解決するためになされたものであり、その目的は、スケーラビリティに富んだ構成をとることができるプロトコル変換装置及び方法を提供することにある。

このような目的を達成するために、本発明は、互いに異なる物理回線を利用する第 1の装置と第 2の装置との間に接続されるプロトコル変換装置であって、第 1の装置と第 2の装置との間のシグナリングを制御する Cプレーン装置と、第 1 の装置と第 2の装置との間でのユーザデータの転送を制御する Uプレーン装置とを備えることを特徴とする。

本発明はまた、互いに異なる物理回線を利用する第 1の装置と第 2の装置との間を接続する際に適用されるプロトコル変換方法であって、 Cプレーン装置で第 1の装置と第 2の装置との間のシグナリングを制御する第 1のステップと、 Cプレーン装置と独立に配設された Uプレーン装置で第 1の装置と第 2の装置との間でのユーザデータの転送を制御する第 2のステップとを備えることを特徴とする。図面の簡単な説明

図 1は、第 1の実施例による I W F装置の構成を示すプロック図である。

図 2は、図 1の I WF— c及び I WF— uの構成を示すブロック図であ。

図 3は、第 1の実施例における C一 P 1 a n eのプロトコルスタックを示す図である。

図 4は、第 1の実施例による C S発呼時における動作を示すシーケンスチヤ一トである。

図 5は、第 1の実施例による P S発呼時における動作を示すシーケンスチヤ一トである。

図 6は、図 1の I W F— cの動作を示すフローチヤ一トである。

図 7は、図 1の I W F— cの動作を示すフローチャートである。

図 8は、図 1の I WF— uの動作を示すフローチャートである。

図 9は、図 1の I W F— uの動作を示すフローチャートである。

図 1 0は、第 2の実施例による I WF装置の構成を示すプロック図である。図 1 1は、図 1 0の I WF— c及ぴ I WF— uの構成を示すプロック図である。図 1 2は、第 2の実施例における C一 P 1 a n eのプロトコルスタックを示す図である。

図 1 3は第 2の実施例による C S発呼時における動作を示すシーケンスチヤートである,

図 14は第 2の実施例による P S発呼時における動作を示すシーケンスチヤートである

図 1 5は図 10の I WF_uの動作を示すフローチヤ一トである発明を実施するための最良の形態

次に、本発明の実施例について図面を参照して説明する。

第 1の実施例

図 1は本発明に係るプロトコル変換装置の第 1の実施例による IWF ( I n t e r Wo r k i n g F u n c t i o n) 装置の構成を示すブロック図である。図 1において、 IWF装置 3は主にシグナリング制御を行う I WF— c 31と、主にユーザデータの転送を行う I WF— u 32, 33とから構成されている。 I WF- c 3 1は制御信号を転送するシグナリングのための Cプレーン (C-P 1 a n e) に対応し、 IWF_u 32， 33はユーザ情報を転送する Uプレーン (U— P l a n e) に対応している。なお、シグナリングとは回線を接続するための処理のことであり、ユーザ情報とはシグナリングによって接続された回線を流れるバケツトのことである。

I WF装置 3は、第 1の装置としての MS C (Mo b i l e S w i t c h i n g C e n t e r) 4または SGSN [S e r v i n g GPRS (Ge n e r a 1 P a c k e t R a d i o S e r v i c e) S u p p o r t No d e] 5と、第 2の装置としての RNC (Ra d i o Ne two r k C o n t r o 1 1 e r ：基地局制御装置） 1との間に接続される。 IWF装置 3と MS C 4または SGSN 5との間は、 3GPP (3 r d Ge n e r a t i o n P a r t n e r s h i p P r o j e c t s) R e l e a s e 99で定義された ATM (A s yn c h r o n o u s Tr a n s f e r Mo d e) T r a n s p o r tのプロトコルスタックである。また、 I WF装置 3と RNC 1との間は、 3GPP R e 1 e a s e 5で定義された I P (I n t e r n e t P r o t o c o l ) T r a n s p o r tのプロトコノレスタックである。これらは I u インタフェースとして、文献 2 (3GPP TS 25. 412 V5. 1. 0 (2002-09) ) 等に詳しく述べられている。

I WF装置 3の I WF_ c 31はシグナリングにおける ATM T r a n s p

0 r tのプロトコノレスタックと I P T r a n s p o r tのプロトコノレスタックとの変換を行う。また、 I WF装置 3の I WF— u 32， 33はユーザ情報転送における ATM T r a n s p o r tのプロトコノレスタックと I P T r a n s p o r tのプロトコルスタックとの変換を行う。

RNC 1は制御信号を送受信する制御信号送受信部 [シダナリング制御装置] 1 1〜1 3と、ユーザ情報を送受信するデータ送受信部 21〜23とから構成されている。

図 2は図 1の I WF - c 31及び I WF一 u 32の構成を示すブロック図であ。図 2において、 I WF - c 31はリソース管理部 31 1と、プロトコル終端部 3 12， 314と、 I WF— u 32とのインタフェース（I F) 部 313とから構成されている。 I WF— u 32はスィッチ制御部 321と、スィッチ 322と、

1 WF - c 31とのインタフェース（I F) 部 323と、 ATM側のプロトコル終端部 324〜 326と、 I P (I n t e r n e t P r o t o c o l ) 側のプ口トコル終端部 327〜329とから構成されている。

図 3は本実施例における C一 P 1 a n eのプロトコルスタックを示す図である。図 3において、 RNC 1は D a t a l i n kレイヤと、 I Pレイヤと、 SCT P S t r e am C o n t r o l f r a n s m i s s i o n P r o t o c o l) レイヤと、 M3UA [S S 7 (S i g n a l l i n g S y s t em N o . 7) MT P 3 (Me s s a g e T r a n s f e r P a r t 3) U s e r Ad a p t a t i o n] レイヤと、 SCCP (S i g n a l 1 i n g Co n n e c t i o n C o n t r o l P a r t) レイヤと、 RANAP (R a d i o Ac c e s s Ne two r k Ap p l i c a t i o n P a r t) レイヤとからなる。

I WF— c 31は RNC 1側が D a t a l i n kレイヤと、 I Pレイヤと、 SCTPレイヤと、 M3UAレイヤと、 SCCPレイヤと、 RANAPレイヤとからなり、 MSC4及び SGSN5側が ATMレイヤと、 SAAL— NN I (S i g n a l l i n g ATM Ad a p t a t i o n L a y e r— Ne two r k No d e I n t e r f a c e) レイヤと、 MTP 3—B (M e s s a g e T r a n s f e r P a r t 3— B) レイヤと、 SCCPレイヤと、 RA NAPレイヤとからなる。

MS C4及び SGSN5は ATMレイヤと、 SAAL— NN Iレイヤと、 MT P 3—Bレイヤと、 SCCPレイヤと、 RANAPレイヤとからなる。

この場合、 SCCPレイヤは I WF装置 3で一端終端する。これに対し、最上位のシグナリング ·プロトコルである RANAPレイヤは、一部判別する必要があるものの、 RNC 1と MS C 4または S G SN 5との間で終端することになる。一部のメッセージについてはリソースァドレスについての内容変更を行う。

S CCPレイヤが I WF装置 3で一端終端する結果、 1つの呼に対して SCC Pコネクションが RNC 1一 I WF間と I WF-MS C 4または S G S N 5間とに二本設定されることになる。 SCCPレイヤは、その二本の S C C Pコネクシヨンを対応付ける S CCP対応表を IWF装置 3のリソース管理部 31 1に持つている。このため、 I WF装置 3で S CCPを一端終端して呼情報を認識し、適切な宛先へ再度送信することで、 RNC 1内の複数ある制御信号送受信部 1 1〜 1 3の中から適切な送受信部を選択することが可能となる。

なお、ここでは C S (C i r c u i t Sw i t c h e d) 呼について詳細に説明したが、 MS C 4の代わりに S G S N 5を用いた P S (P a c k e t S w i t c h e d) 呼についても、上記と同じように説明することができる。 CS呼は M S C 4を利用した音声回線呼、 P S呼は S G S N 5を利用したパケット通信呼である。

図 4は本実施例による C S発呼時における動作を示すシーケンスチヤ一トである。この図 4を参照して、本実施例による C S発呼時における各装置のリソース確保までの動作について説明する。

端末 (UE : U s e r E q u i pme n t) 力 S、「 C o nn e c t i o n Re q u e s t」（図 4の a l) を RNC 1に送信することで、発呼シーケンスが開始される。 RNC 1は「 I n i t i a l UE Me s s a g e」を MS C 4に向けて送信する際、 RNC 1と I WF— _c 31との間で、及び I WF— c 3 1と MSC4との間でそれぞれ S CC Pコネクションが設定される（図 4の a 2, a 3) 。このとき、 RNC 1と IWF— C 31との間の S C C Pコネクションを S C C Pコネクション # 1、 I WF— c 3 1と MS C 4との間の S CC Pコネクションを S C CPコネクション # 2とする。

I WF- c 31ではこの「 I n i t i a l UE Me s s a g e」を中継するのみで、 SCCPを SCCPコネクション # 1から SCCPコネクション # 2 に載せ変えて、 MS C 4へ送信する（図 4の a 4， a 5) 。 IWF_ c 3 1のリソース管理部 31 1では、 SCCPコネクション # 1と SCCPコネクション # 2とが同じ呼で利用していることを認識する S C C P対応表が作成される。なお、 P a g i n g等の MS C 4側から最初に S CCPコネクションが設定される場合、 IWF-c 31が制御信号送受信部を任意に選択する機能を持つ。

呼利用中のマルチコールでは、 I MS I (I n t e r n a t i o n a l Mo b i l e S u b s c r i b e r I d e n t i t y) 等の端末固有の情報によつて、 I WF- c 3 1内でその端末が利用中かどうかを判断し、同じ制御信号送受信部を利用可能にする手段も持つ。

認証、秘匿を行った後 (図 4の a 6) 、 MS C 4はユーザデータ用のリソースを確保し（図 4の a 7) 、無線リソースを確保するための「RAB A s s i g nme n t Re q u e s t] (第 1のリソース要求) (図 4の a 8) を RNC 1へ送信する。 I WF- c 31では、このメッセージを受信したとき、 I WF- u 32, 33のリソースの確保を行う必要があると判断する。以下では、 IWF 一 u 32のリソースの確保を行う場合について説明する。

「RAB A s s i g nme n t Re q u e s t」には、 MS C 4でユーザデータ転送に利用されるァドレス等の第 1のパラメータが含まれている。 I WF 一 c 3 1のリソース管理部 31 1は、この第 1のパラメータを「RAB A s s i g nme n t R e q u e s t」より取得し、リソース要求（第 2のリソース要求）に付カ卩し、 IWF— u 32に送信する（図 4の a 9) 。

I WF-u 32のスィツチ制御部 321は、受信されたリソース要求より第 1 のパラメータを取得し、ユーザデータ用のリソースを確保し（図 4の a 10) 、リソースを確保した旨の通知を I WF— c 3 1に送信する（図 4の a 1 1) 。この通知には、 IWF— u 32でユーザデータ転送に利用される RNC 1側のァドレス等の第 2のパラメータが付加されている。

I WF— c 31のリソース管理部 31 1は、受信された通知より第 2のパラメータを取得する。そして、「RAB As s i g nme n t Re q u e s t」内のユーザデータ転送先ァドレスである MS C 4のァドレスを I WF— u 32のァドレスに書換え、書換え後の「RAB A s s i g nme n t R e q u e s t J を RNC 1内の適切な制御信号送受信部へ転送する（図 4の a 12) 。この際の適切な制御信号送受信部の選択には S C C P対応表を利用する。

その後、 RNC 1はユーザデータ用のリソースを確保する (図 4の a 1 3) 。そして、 RNC 1は U—P l a n eの設定を行うために、「RAB As s i g nm e n t Re q u e s t」で通知された I WF-u 32のァドレスへ向けて「 E s t a b l i s h R e q u e s t] を送信する（図 4の a 14) 。この通知には RNC 1のユーザデータ用のァドレスが格納されている。この通知の送信 ίこ ίま、 I P A L C A P (I P Ac c e s s L i n k C o n t r o l A p p l i c a t i o n P r o t o c o l) を利用することができる。

この通知を受け取った I WF— u 32は、 M S C 4へ向けて A L C A P (A c c e s s L i n k C o n t r o l Ap p l i c a t i o n P r o t o c o l) で「 E s t a b l i s h R e q u e s t] を送信する (図 4の a 1 5) 。この MS C 4の宛先には、事前に I WF- c 31から通知されている MS C 4の了ドレスを利用する。

MS C 4カら I WF— u 32へ、 I WF-u 32から RNC 1へ、確認のメッセージとして「E s t a b 1 i s h C o n f i r mj を送信する (図 4の a 1 6， a 17) 。その後、 UEと RNC 1との間で無線リソースを確保する（図 4 の a 1 8) 。無線リソースが確保されると、 RNC 1から IWF— u 32へ、 I WF— u 32から MS C4へ「RAB As s i g nme n t Re s p o n s ej を送信することによって、ユーザデータ転送用のパス設定が完了する（図 4 の a 1 9， a 20) 。

その後、設定されたパスを用いてユーザデータの転送が行われる。なお、 I WF— u 33のリソースの確保を行う場合についても、同様の処理が行われる。

図 5は本実施例による P S発呼時における各装置のリソース確保までの動作を示すシーケンスチャートである。この図 5を参照して、本実施例による P S発呼時における各装置のリソース確保までの動作について説明する。

図 5を参照すると、 P S発呼時における各装置のリソース確保までの動作は、上述した C S発呼時における各装置のリソース確保までの動作とほとんど同じである。すなわち、図 5の b l〜b 1 3の動作は図 4の a l〜a 1 3と同様である。しかし、 P S呼では AL CAPや I PAL CAPを利用しないため、最後の「R AB A s s i g nme n t R e s p o n s e」異なっている。

I WF- c 31では、 UEと RNC 1との間で無線リソースが確保された後 (図 5の b l 4) 、「RAB A s s i g nme n t Re s p o n s eJ によつて、ユーザ転送用のパス設定が完了すると（図 5の b 1 5) 、 I WF- c 31 は「RAB As s i g nme n t Re s p o n s eJ より RNC 1のユーザデータ用のァドレスを取得し、 I WF-u 32に通知する (図 5の b 1 6) 。その応答として、 I WF— u 32は I WF_ c 31に I WF— u 32の MS C 4側のアドレスを通知する（図 5の b 1 7) 。 I WF— c 31はこのアドレスを取得し、「RAB As s i g nme n t R e s p o n s eJ 内のユーザテータ早送先ァドレスである RNC 1のァドレスを I WF-u 32のァドレスに書換え、書換え後の ΓΚΑΒ A s s i g nme n t Re s p o n s e] を MS C 4へ送信する (図 5の b 18) 。

この際、 S CCPコネクションは S C CP対応表を利用する。 SCCPにはそれぞれのリンクが確認できるように、リンク番号が付与されている。 SCCP対応表にはそのリンク番号毎に、 MSC4またはSGSN5向けの何番とRNC 1 向けの何番とが対応しているという情報が格納されている。

その後の処理は、上述した C S発呼時の処理と同様である。

なお、 IWF— u 33のリソースの確保を行う場合についても、同様の処理が行われる。

上述した図 4及び図 5に示す動作では、リソースを確保するときのシーケンスについて詳細に説明したが、リソースを解放するときにも上記と同様の手順で行うことができる。

図 6及び図 7は図 1の IWF— c 31の動作を示すフローチャートである。これら図 6及び図 7を参照して IWF装置 3内の IWF— c 31の動作について説明する。

I WF— c 31はシグナリングを受信したとき（図 6ステップ S I) 、 RNC 1側から受信したシグナリングか、 MS C 4側から受信したシグナリングかの判別を行う (図 6ステップ S 2) 。

I WF- c 31は RNC 1側から受信した R A N A Pシグナリングの場合、 P S呼のときでリソース確保応答を示す「RAB A s s i g nme n t R e s p o n s e J のときだけ (図 7ステップ S 14) 、 IWF— u 32, 33に RN Cァドレスを通知する (図 7ステップ S I 5) 。

I WF— c 31は I WF— u 32, 33からの応答を待って I WF— u (RN C 1側) ァドレスを取得し (図 7ステップ S 1 6) 、シグナリング内のユーザデータ用 RNCアドレスを I WF— u 32， 33のアドレスに書換え (図 7ステツプ S 1 7) 、 R AN A Pシグナリングを MS C 4へ送信する (図 7ステップ S 1 8) I WF-c 31は上記以外の場合、 R AN A Pシグナリングをそのまま M S C 4へ送信する (図 7ステップ S 1 8) 。

I WF- c 31は MS C 4側から RANAPシグナリングを受信すると (図 6 ステップ S 3) 、まず P a g i n g等の MS C 4からの最初の RAN A Pシグナリングで、制御信号送受信部の番号と SCCPコネクションとの S CCP対応表ができていない場合 (図 6ステップ S 4) 、制御信号送受信部を任意に選択し、 RANAPシグナリングをそのまま制御信号送受信部へ送信する (図 6ステップ S 1 1〜S 1 3) 。

SCCPコネクションと制御信号送受信部の番号との対応付けができていない場合には、 SCCP対応表を作成する（図 6ステップ S 1 2) 。この SCCP対応表は、呼の終了 (SCCPコネクションの終了) と同時に無くなる。

次に、 I WF— c 31はその RANAPシグナリングがユーザデータ用のリソースを確保する「RAB A s s i g nm e n t R e q u e s t」かどうかを判断する（図 6ステップ S 6) 。 IWF— c 3 1はユーザデ一タ用のリソースを確保するリクエストである場合、 IWF— u 32， 33とシグナリングのやりとりを行い、 IWF— U 32, 33のリソースを確保した後で、 RANAPシグナリングのユーザデータ転送先である MS C 4のァドレス力ら I WF— u 32, 3 3のアドレスに書換え（図 6ステップ S 7〜S 9) 、制御信号送受信部の宛先を S C C P対応表から取得してその制御信号送受信部ヘシダナリングを送信する (図 6ステップ S 10) 。

I WF- c 31はユーザデータ用のリソースを確保するリクエストでない場合、 R A N A Pには何も手を加えず、そのまま適切な制御信号送受信部へ R ANAP シグナリングを送信する (図 6ステップ S 10) 。

図 8及び図 9は図 1の IWF— U 3 2, 33の動作を示すフローチャートである。これら図 8及び図 9を参照して IWF— U 32， 33の動作について説明する。

I WF-u 32, 33は I WF— c 31からリソース確保のシグナリングを受信した場合（図 8ステップ S 23、図 9ステップ S 28) 、 I WF-u 32, 3 3内のリソースを確保し（図 9ステップ S 29) 、そのシグナリングで通知された MS C 4のァドレスをその IWF— uァドレスと対応付けて記憶し、 I WF— c 3 1へその I WF— uァドレスを通知する (図 9ステップ S 30) 。

I WF-u 32, 33は R N C 1側からシグナリングを受信した場合 (図 8ステツプ S 24) 、その I P ALCAPシグナリングを ALCAPに載せかえて、対応付けられた MS Cアドレスへ向けて送信する（図 8ステップ S 27) 。

I WF-u 32, 33は M S C 4側からシグナリングを受信した場合 (図 8ステツプ S 25 ) 、その A L CAPシグナリングを I P A L C A Pに載せかえて、対応付けされた RNCアドレスへ向けて送信する（図 8ステップ S 26) 。

上述したように、 IWF— u 32， 33では、ユーザデータの流れも、 RNC 1側や MS C 4側からシグナリングを受信するときと同様に、プロトコル変換を行う。

このように、本実施例では、 IWF装置 3を C_P 1 a n e装置（IWF— c 31) と U— P 1 a n e装置（ IWF— u 32， 33) とに分離したので、 I W F装置 3がスケーラビリティに富んだ構成をとることができる。具体的には、 I WF-u 32, 33の数の増減時に、 I WF— c 31が影響を受けない。

また、本実施例では、 I WF装置 3で呼毎の SC CPを終端しているため、 R NC 1内に制御信号送受信部 1 1〜13を複数設置することが可能になる。従来、 RNC 1としては一つである必要がある。

さらに、本実施例では、 I WF装置 3を C一 P 1 a n e装置（IWF— c 3 1) と U_P 1 a n e装置（ I WF— u 32， 33) とに分離したときに、 C一 P l a n e装置（ I WF_ c 31) からの要求に応答して U— P 1 a n e装置

(I WF-u 32, 33) でリソースの確保を行うことによって、最短経路を利用する I P t r a f f i cの負荷分散を行うことができる。

第 2の実施例

図 1Όは本発明に係るプロトコル変換装置の第 2の実施例による IWF装置の：構成を示すブロック図である。図 10において、本実施例は IWF装置 7内において IWF— c 31と IWF— u 71, 72との間で信号の送受信を行わず、 R NC 6の制御信号送受信部 6 1〜63から I WF— u 71， 72を制御する点が、上述した第 1の実施例と異なる。同一構成要素には第 1の実施例と同一符号を付しある o

第 1の実施例では I WF— c 3 1で RAN A Pシグナリングを認識する必要があるので、全てのシグナリングをデコードし、「RAB A s s i g nme n t

Re q u e s t」であるかどうかを認識しなければならない。これに対し、本実施例では、 IWF_u 71， 72のリソース管理を RNC 6内の制御信号送受信部 6 1〜63で行うことで、 I WF- c 3 1では RAN A Pシグナリングをデコードする必要が無くなるため、 I WF_ c 31の処理を軽くすることができる。図 1 1は図 10の I WF_ c 31及び I WF— u 71の構成を示すプロック図である。図 1 1において、 I WF— c 31はプロトコル終端部 31 2， 3 14と、信号転送部 31 5とから構成されている。 I WF— u 71はリソース管理部 71 1と、スィッチ 322と、 ATM側のプロトコル終端部 324〜326と、 I P (I n t e r n e t P r o t o c o l ) 側のプロトコル終端部 327 ~ 329， 71 2とから構成されている。図 12は本実施例における C一 P l a n eのプロトコルスタックを示す図である。図 12において、本実施例は、プロトコルスタックで SCCPレイヤと RA NAPレイヤとを I WF— c 31で終端しない点が、上述した第 1の実施例と異なっており、他の部分は第 1の実施例と同様である。

図 13は本実施例による C S発呼時における動作を示すシーケンスチャートである。この図 13を参照して、本実施例による CS発呼時における各装置のリソース確保までの動作について説明する。

図 1 3において、本実施例では、 SCCPコネクションを RNC 6と MSC4 との間で終端し、この終端に I WF— c 3 1は関与しない。し力しながら、 SC C Pコネクション内に R N C 6で利用されている制御信号送受信部を識別するフラグを添付しているので、 I WF- c 31ではそのフラグを判別することによつて、適切な制御信号送受信部を選択することが可能になっている。

MS C 4力、ら送信された「RAB As s i g nme n t R e q u e s t」 (第 4のリソース要求）は、 I WF— c 3 1に関知されず RNC 6まで届く（図 13の c 6) 。この「RAB A s s i g nme n t R e q u e s t」を受信した RNC 6は、ユーザデータ用のリソースを確保する（図 13の c 7) 。リソースを確保した R N C 6は、 I WF-u 71のリソースを確保するリソース要求 (第 3のリソース要求) を I WF-u 71に送信する (図 1 3の c 8) 。このリソース要求に MS C 4のァドレスとともに RNC 6のァドレスを付加することでこのリソース要求が I PALCAPの「 E s t a b l i s h R e q u e s t」の代わりにもなる。

I WF-u 71はユーザデータ転送先である MS C 4のァドレスを取得し、ュ一ザデータ用のリソースを確保する (図 1 3の c 9) 。その後、 ALCAPで M SC4に「 E s t a b l i s h Re q u e s t] を送信する（図 13の c 1 0) 。これに対して ALCAPで I WF— u 71に返信される「E s t a b 1 i s h C o n f i rm」を待って（図 13の c 1 1 ) 、 I WF-u 71は RNC 6へ I WF— u 71のァドレスを通知する（図 1 3の c 1 2) 。

その後の処理は、上述した第 1の実施例と同様である。

なお、 IWF— u 72のリソースの確保を行う場合についても、同様の処理が行われる。

図 14は本実施例による P S発呼時における動作を示すシーケンスチャートである。この図 14を参照して、本実施例による P S発呼時における各装置のリソース確保までの動作について説明する。

P S呼では AL C AP 「E s t a b l i s h Re q u e s t」を利用しないため、「RAB A s s i g nme n t Re s p o n s e」で（図 14の d l 2) 、 CS呼と P S呼とで異なる動きをしなくてもよくなる。

本実施例では、 I WF_ c 31がリソース確保を行わず、 RNC6内の制御信号送受信部 6 ：!〜 63がリソース確保を行うことによって、 I WF- c 3 1では図 6及ぴ図 7に示す判別ステップが不要となり、下位レイヤのプロトコル変換を行うのみの動作となる。

図 1 5は図 10の I WF-u 71の動作を示すフローチヤ一トである。図 1 5 において、ステップ S 41〜S 48の処理は、図 8及び図 9に示す処理と同様である。ただし、ステップ S 23, S 28の判断式がなく、全体として判断式が少なくなっていることから、 I WF-u 71でも処理を軽くすることが可能になつている。

このように、本実施例では、 R N C 6内の制御信号送受信部 6 1〜 63力 S I W F - u 7 1 , 72のリソース確保のためのシグナリングを制御しているので、 I WF—c 3 1で RAN A Pシグナリングをデコードしなくても良く、 SCCPコネクシヨンも終端しなくても良いという効果が得られる。また、 I WF- c 3 1 と IWF— U 71, 72との関係が無くなることから、実装にもフレキシビリティが確保され、 I WF-u 71, 72を RNC 6内に実装することも容易となる。以上説明したように、上述した実施例による I WF装置 3， 7はシグナリングを制御する Cプレーン装置と、ユーザデータを制御する Uプレーン装置とに分離しているので、スケーラビリティに富んだ構成をとることができる。さらに、 R NC 1, 6もまた、スケーラビリティに富んだ構成をとることができる。なお、上述した IWF装置 3， 7は、異なる物理回線の間に接続される場合ばかりではなく、同じ物理回線で中間のプロトコルが異なる場合でも適用可能である。

Claims

請求の範囲

1 . 互いに異なる物理回線を利用する第 1の装置と第 2の装置との間に接続されるプロトコル変換装置であって、

前記第 1の装置と前記第 2の装置との間のシグナリングを制御する Cプレーン装置と、

前記第 1の装置と前記第 2の装置との間でのユーザデータの転送を制御する U プレーン装置と

を備えることを特徴とするプロトコル変換装置。

2 . 請求の範囲第 1項に記載のプロトコル変換装置において、

前記 Cプレーン装置は、前記第 1の装置よりユーザデータ用のリソースを確保するための第 1のリソース要求を受信したときに前記 Uプレーン装置に第 2のリソース要求を送信するリソース管理部を備え、

前記 Uプレーン装置は、第 2のリソース要求を受信したときに前記 Uプレーン装置内でユーザデータ用のリソースを確保する制御部を備えることを特徴とするプロトコル変換装置。

3 . 請求の範囲第 2項に記載のプロトコル変換装置において、

前記リソース管理部は、第 1のリソース要求に含まれる前記第 1の装置におけるユーザデータ転送用の第 1のパラメータを取得しこのパラメータを第 2のリソース要求に付加することを特徴とするプロトコル変換装置。

4 . 請求の範囲第 3項に記載のプロトコル変換装置において、

前記制御部は、リソースを確保した後に前記 Uプレーン装置におけるユーザデ一タ転送用の第 2のパラメータが付加されたリソース確保通知を前記 Cプレーン装置に送信し、

前記リソース管理部は、受信されたリソース確保通知から第 2のパラメータを取得し第 1のリソース要求に含まれる第 1のパラメータを第 2のパラメータに書き換え書換後の第 1のリソース要求を前記第 2の装置に転送することを特徴とするプロトコル変換装置。

5. 請求の範囲第 1項に記載のプロトコル変換装置において、

前記 Uプレーン装置は、前記第 2の装置よりユーザデータ用のリソースを確保するための第 3のリソース要求を受信したときに前記 Uプレーン装置内でユーザデータ用のリソースを確保するリソース管理部を備えることを特徴とするプロトコル変換装置。

6. 請求の範囲第 5項に記載のプロトコル変換装置において、

前記リソース管理部は、第 3のリソース要求に含まれる前記第 1及び第 2の装置におけるユーザデータ転送用のパラメータを取得することを特徴とするプロトコル変換装置。

7. 請求の範囲第 5項に記載のプロトコル変換装置において、

前記第 2の装置は、前記第 1の装置よりユーザデータ用のリソースを確保するための第 4のリソース要求を受信したときに前記 Uプレーン装置に第 3のリソース要求を送信することを特徴とするプロトコル変換装置。

8. 請求の範囲第 1項に記載のプロトコル変換装置において、

目 iJSti第 1の装感は、 ATM (As y n c h r o n o u s T r a n s f e r Mo d e) トランスポートのプロトコルスタックを用いる MS C (Mo b i l e

Sw i t c h i n g C e n t e r) 及び SGSN [S e r v i n g GPR S (g e n e r a l P a c k e t Ra d i o S e r v i c e) S u p p o r t No d e] の少なくとも一方であり、

前記第 2の装置は、 I P (I n t e r n e t P r o t o c o l ) トランスポートのプロトコルスタックを用いる基地局制御装置であることを特徴とするプロトコル変換装置。

9. 請求の範囲第 8項に記載のプロトコル変換装置において、

前記 Cプレーン装置と前記 MS C及び SGSNの少なくとも一方との間、及び前記 Cプレーン装置と前記基地局制御装置との間には、それぞれ SCCP (S i g n a l l i n g C o nn e c t i o n C o n t r o l P a r t) コネクシヨンが設定されることを特徴とするプロトコル変換装置。

10. 請求の範囲第 9項に記載のプロトコル変換装置において、

前記基地局制御装置は、制御信号の送受信を行うシグナリング制御装置を複数備え、

前記 Cプレーン装置は、前記シグナリング制御装置の番号と S C C Pコネクシヨンとが対応付けられた S C C P対応表を記憶し、前記 M S C及び S G S Nの少なくとも一方からシグナリングを受信したときに S C C P対応表に基づいて前記シグナリング制御装置のいずれかを選択することを特徴とするプロトコル変換装置。

1 1 . 互いに異なる物理回線を利用する第 1の装置と第 2の装置との間を接続する際に適用されるプロトコル変換方法であって、

Cプレーン装置で前記第 1の装置と前記第 2の装置との間のシグナリングを制御する第 1のステップと、

前記 Cプレーン装置と独立に配設された Uプレーン装置で前記第 1の装置と前記第 2の装置との間でのユーザデータの転送を制御する第 2のステップとを備えることを特徴とするプロトコル変換方法。

1 2 . 請求の範囲第 1 1項に記載のプロトコル変換方法において、

前記第 1のステップは、

前記第 1の装置より前記 Cプレーン装置にユーザデータ用のリソースを確保するための第 1のリソース要求を送信する第 3のステップと、

前記 Cプレーン装置で第 1のリソース要求を受信したときに前記 Uプレーン装置に第 2のリソース要求を送信する第 4のステップと、

前記 Uプレーン装置で第 2のリソース要求を受信したときに前記 Uプレーン装置内でユーザデータ用のリソースを確保する第 5のステップと

を備えることを特徴とするプロトコル変換方法。

1 3 . 請求の範囲第 1 2項に記載のプロトコル変換方法において、

前記第 4のステップは、第 1のリソース要求に含まれる前記第 1の装置におけるユーザデータ転送用の第 1のパラメータを取得しこのパラメータを第 2のリソース要求に付加するステップを備えることを特徴とするプロトコル変換方法。

1 4 . 請求の範囲第 1 3項に記載のプロトコル変換方法において、

前記第 1のステップは、

前記第 5のステップの後に前記 Uプレーン装置におけるユーザデータ転送用の第 2のパラメータが付加されたリソース確保通知を前記 Cプレーン装置に送信する第 6のステップと、

受信されたリソース確保通知から第 2のパラメータを取得し第 1のリソース要求に含まれる第 1のパラメータを第 2のパラメータに書き換え書換後の第 1のリソース要求を前記第 2の装置に転送する第 7のステップと

をさらに備えることを特徴とするプロトコル変換方法。

1 5. 請求の範囲第 1 1項に記載のプロトコル変換方法において、

前記第 1のステップは、

前記第 2の装置より前記 Uプレーン装置にユーザデータ用のリソースを確保するための第 3のリソース要求を送信する第 8のステップと、

前記 Uプレーン装置で第 3のリソース要求を受信したときに前記 Uプレーン装置内でユーザデータ用のリソースを確保する第 9のステップと

を備えることを特徴とするプロトコル変換方法。

16. 請求の範囲第 15項に記載のプロトコル変換方法において、

前記第 9のステップは、第 3のリソース要求に含まれる前記第 1及び第 2の装置におけるユーザデータ転送用のパラメータを取得するステップを備えることを特徴とするプロトコル変換方法。

1 7. 請求の範囲第 1 5項に記載のプロトコル変換方法において、

前記第 1のステツプは、前記第 8のステップの前に前記第 1の装置より前記第 2の装置にユーザデータ用のリソースを確保するための第 4のリソース要求を送信する第 1 0のステップをさらに備え、

前記第 8のステップは、前記第 2の装置で第 4のリソース要求を受信したときに前記 Uプレーン装置に第 3のリソース要求を送信するステップであることを特徴とするプロトコル変換方法。

1 8. 請求の範囲第 1 1項に記載のプロトコル変換方法において、

前記第 1の装置は、 ATM (As y n c h r o n o u s T r a n s f e r Mo d e) トランスポートのプロトコルスタックを用いる MS C (Mo b i l e

Sw i t c h i n g C e n t e r) ¾Ό« SGSN [S e r v i n g GPR S (Ge n e r a l P a c k e t Ra d i o S e r v i c e) S u p p o r t N o d e] の少なくとも一方であり、

前記第 2の装置は、 I P (I n t e r n e t P r o t o c o l) トランスポートのプロトコルスタックを用いる基地局制御装置であることを特徴とするプロトコル変換方法。

19. 請求の範囲第 1 8項に記載のプロトコル変換方法において、

前記第 1のステップは、前記 Cプレーン装置と前記 MS C及ぴ SGSNの少なくとも一方との間、及ぴ前記 Cプレーン装置と前記基地局制御装置との間にそれぞれ SCCP (S i g n a l l i n g C o nn e c t i o n Co n t r o l P a r t) コネクションを設定する第 1 1のステップを備えることを特徴とするプロトコル変換方法。

20. 請求の範囲第 1 9項に記載のプロトコル変換方法において、

前記第 1のステップは、前記基地局制御装置が複数備えるシグナリング制御装置の番号と S C C Pコネクシヨンとが対応付けられた S C C P対応表に基づいて. 前記 MS C及ぴ SGSNの少なくとも一方からシグナリングを受信したときに前記シグナリング制御装置のいずれかを選択する第 1 2のステップをさらに備えることを特徴とするプロトコル変換方法。