JP4998316B2 - 通信システム及び通信処理方法並びにノード - Google Patents

通信システム及び通信処理方法並びにノード Download PDF

Info

Publication number
JP4998316B2
JP4998316B2 JP2008038595A JP2008038595A JP4998316B2 JP 4998316 B2 JP4998316 B2 JP 4998316B2 JP 2008038595 A JP2008038595 A JP 2008038595A JP 2008038595 A JP2008038595 A JP 2008038595A JP 4998316 B2 JP4998316 B2 JP 4998316B2
Authority
JP
Japan
Prior art keywords
node
signal
communication
enb
nodes
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
Application number
JP2008038595A
Other languages
English (en)
Other versions
JP2009200689A (ja
Inventor
照義 渡邊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2008038595A priority Critical patent/JP4998316B2/ja
Priority to US12/273,232 priority patent/US8089936B2/en
Priority to EP20080170106 priority patent/EP2093975A1/en
Publication of JP2009200689A publication Critical patent/JP2009200689A/ja
Application granted granted Critical
Publication of JP4998316B2 publication Critical patent/JP4998316B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/16Interfaces between hierarchically similar devices
    • H04W92/20Interfaces between hierarchically similar devices between access points

Description

本発明は、通信システム及び通信処理方法並びにノードに関する。例えば、SCTP(Stream Control Transmission Protocol)やIPSec(Security Architecture for Internet Protocol)を用いて通信装置(ノード)間で通信を行なう際に、本発明が用いられる場合がある。
図13は、次世代無線移動通信システム(LTE:Long Term Evolution)の構成例を示す図である。この図13に示すシステムは、例えば、ユーザ端末(UE:User Equipment)の一例としての無線端末が無線リンクによりアクセスする無線アクセス網(Evolved Universal Terrestrial Radio Access Network:E-UTRAN)のエンティティである複数の無線基地局装置(eNode B、以下、eNBと略記する)と、その上位装置であるMME(Mobility Management Entity)/S−GW(Serving-Gateway)と、をそなえる。
かかるシステムにおいて、eNBとMME/S−GWとの間との通信は、S1インタフェースと呼ばれる装置(エンティティ)間インタフェースを介して行なわれ、eNB間の通信は、X2インタフェースと呼ばれる装置(エンティティ)間インタフェースを介して行なわれる。
ここで、S1インタフェースは、無線移動通信システムのネットワークエンティティであるeNBと、その上位装置であるMME/S−GW装置との間を、IP(Internet Protocol)を用いて接続し、制御プレーン(C-Plane)及び/又はユーザプレーン(U-plane)の信号を伝送するのに用いられるインタフェースである。
一方、X2インタフェースは、eNB間を、IPを用いて接続し、制御プレーン及び/又はユーザプレーンの信号を伝送するために用いられるインタフェースである。このX2インタフェースは、例えば図14に示すように、UEが或るeNBの無線エリア(セル又はセクタ)から別のeNBの無線エリアへ移動して接続先を前記別のeNBに切り替えるハンドオーバ(HO)を行なう場合に、MME/S−GWからUEのHO元eNB(Source eNB)に送られてきたパケットデータ(以下、単に「パケット」ともいう)を、UEのHO先eNB(Target eNB)に転送するのに用いることが可能である(一点鎖線参照)。なお、HO処理に関しては、例えば下記の非特許文献3に記述がある。
S1インタフェース及びX2インタフェースなどのインタフェースにおいて、装置(ノード)間制御信号を伝送する際に用いるプロトコルの一つに、SCTP(Stream Control Transmission Protocol)と呼ばれるプロトコルがある。
SCTPとは、IP上でシーケンス番号とチェックサムとを基にパケットの正統性を検証することで、パケットの多重送信、喪失などをできるだけ回避して信頼性を確保しつつ情報転送を行なえるようにするトランスポート層のプロトコルの一つであり、例えば、下記の非特許文献1(RFC4960)によって規定されている。
SCTP機能をもつネットワークエンティティ(以下、ノードともいう)は、1又は複数のエンドポイントと呼ばれる論理的な終端点をもち、他のノードのエンドポイントとアソシエーションと呼ばれる論理的な接続(SCTPリンク)を確立する。その際、ノード(エンドポイント)は、クライアントとサーバという2つの状態をもち、クライアントは接続(アソシエーション)確立要求の送信側として動作し、サーバは前記接続確立要求の受信側として動作することが要求される。
SCTPにおけるパケットは、SCTP共通ヘッダと、これに続く1又は複数のチャンクと呼ばれるデータブロックからなる。チャンクには、制御信号(メッセージ)が格納される制御チャンクと、ユーザデータが格納されるデータチャンクとがある。制御チャンクは、アソシエーションの確立(初期化:INIT)や解放のときなどに送信される。
例えば、アソシエーション確立時には、制御チャンクとして、INITチャンク、INIT-ACKチャンク、COOKIE-ECHOチャンク、COOKIE-ACKチャンク等が用いられる。一方、アソシエーション解放時には、制御チャンクとして、SHUTDOWNチャンク、SHUTDOWN-ACKチャンク、SHUTDOWN-COMPLETEチャンク等が用いられる。
図15に、SCTPパケットのフォーマットの一例を示す。この図15に示すように、SCTPパケットは、共通ヘッダとして、送信元ポート(Source Port)フィールド(16ビット)、宛先ポート(Destination Port)フィールド(16ビット)、認証タグ(Verification Tag)フィールド(32ビット)、チェックサムフィールド(32ビット)を有するとともに、この共通ヘッダに続く1又は複数のチャンク(制御又はユーザチャンク)を有する。
まず、共通ヘッダにおいて、送信元ポートフィールドには、送信元エンドポイントのポート番号が設定され、宛先ポートフィールドには、宛先エンドポイントのポート番号が設定される。これらのポート番号によってアソシエーションの識別が行なわれる。
認証タグフィールドには、以前のアソシエーションからの古いSCTPパケットの到着を防ぐ(現在の有効なアソシエーションを識別する)ための鍵情報が設定される。
チェックサムフィールドには、SCTPパケットがIPネットワークを伝送される際のデータの完全性を保証する(破損パケット(転送エラー)を検知する)ためにSCTPパケットのチェックサムが設定される。
一方、共通ヘッダに続くチャンクには、先頭32ビットを用いてそのチャンクの種別(Type)や長さ(Length)が表示され、その後にユーザ又は制御データが格納される。なお、図15には、N個のユーザチャンクが共通ヘッダに続いて設定されて1つのSCTPパケットが構成される様子を示している。
次に、アソシエーション確立に用いる制御チャンクである初期化(INIT)チャンク(chunk)のフォーマットの一例を、図16に示し、前記制御チャンク(初期化チャンク)の応答である初期化応答(INIT-ACK)チャンクのフォーマットの一例を図17に示す。
図16に示すように、アソシエーションの確立要求を意味するINITチャンクは、チャンク種別(Type)=1でINITチャンクであることが表示され、アソシエーションの確立に必要な情報の初期値が設定される。
これに対し、INIT-ACKチャンクは、図17に示すように、チャンク種別(Type)=2でINIT-ACKチャンクであることが表示され、INITチャンクを受信したエンドポイント(サーバ)が、その受信情報を基に生成したアソシエーションの確立要求を識別する情報(クッキー)等が付与される。SCTPでは、クッキーを用いることで、DoS(Denial of Service)攻撃の影響(システムリソース不足等)を回避することが可能である。
図18に、SCTPにおけるアソシエーション確立時のハンドシェイク(4ウェイハンドシェイク)シーケンスの一例を示す。
まず、クライアント側エンドポイントは、アソシエーションを確立するためにINITチャンクをサーバ側エンドポイントへ送信する。
サーバ側エンドポイントは、INITチャンクを受信すると、クッキーを含んだINIT-ACKチャンクをクライアント側エンドポイント送信する。
クライアント側エンドポイントは、INIT-ACKチャンクを受信すると、クッキーを取り出し、COOKIE-ECHOチャンクに含めてサーバ側エンドポイントへ送信する。
サーバ側エンドポイントは、COOKIE-ECHOチャンクを受信すると、クッキーを取り出して、COOKIE-ACKチャンクを送信する。
以上のようにして、クライアント−サーバ間のアソシエーションが確立される。
次に、LTEにおけるS1インタフェースの制御プレーンのプロトコルスタックの一例を図19に示し、LTEにおけるX2インタフェースの制御プレーンのプロトコルスタックの一例を図20に示す。なお、これらは、例えば下記の非特許文献2に記述されている。
図19に示すように、S1インタフェースでは、制御プレーンのプロトコルスタックとして、下位層から順に、物理層、データリンク層、IP層、SCTP層、S1−AP(アプリケーション)層が規定される。一方、X2インタフェースでは、図20に示すように、制御プレーンのプロトコルスタックとして、下位層から順に、物理層、データリンク層、IP層、SCTP層、X2−AP(アプリケーション)層が規定される。
ここで、S1インタフェースとX2インタフェースとでは、エンティティ(eNB、MME/S−GW)のとるアソシエーションの確立動作が異なる。
S1インタフェースの区間では、例えば図21(A)に示すように、eNBがクライアント、MME/S−GWがサーバとしてそれぞれ動作し、先に述べたようなSCTPアソシエーションの確立(ハンドシェイク)を行なう。
これに対し、X2インタフェースの区間では、例えば図21(B)に示すように、eNBは、クライアント、サーバのどちらとしても動作して対向eNBとハンドシェイク可能であることが要求される。
RFC4960(IETF Network Working Group)、[online]平成19年9月、[平成20年2月6日検索]、インターネット<URL:http://www.ietf.org/rfc/rfc4960.txt> 3GPP TS36.300 V8.3.0 第20.2章、[online]、平成20年1月3日、[平成20年2月6日検索]、インターネット<URL:http://www.3gpp.org/ftp/Specs/html-info/36300.htm> 3GPP TS36.423 V8.0.0 第9.1章、[online]、平成19年12月13日、[平成20年2月6日検索]、インターネット<URL:http://www.3gpp.org/ftp/Specs/html-info/36423.htm>
先に述べたように、eNB間でX2インタフェースを介して通信を行なうために、eNB間でSCTPアソシエーションを確立する場合、eNBは接続確立要求(INITチャンク)の送信元であるクライアント、当該要求を受信して応答(INIT-ACKチャンク)を返すサーバのどちらにもなりえる。したがって、対向する2つのeNBが互いにクライアントとして動作することも可能である。
この場合、例えば図22に示すように、複数のLAN(Local Area Network)ポートをもつ異なるeNBがそれぞれクライアントとして対向eNBに対して接続確立要求(INITチャンク)を送信すると、eNB間で複数の(冗長な)アソシエーションが確立されてしまう可能性がある。
即ち、図22の(1)に示すように、一方のeNB#1がクライアントとして動作して、送信元エンドポイントを表すトランスポートアドレスa(IPアドレス=192.168.0.1、ポート番号=100)を使い、宛先エンドポイントを表すトランスポートアドレスc(IPアドレス=192.168.0.3、ポート番号=200)に向かって接続確立要求(INITチャンク)を送信したとする。
その際、対向のeNB#2も、送信元エンドポイントを表すトランスポートアドレスd(IPアドレス=192.168.0.4、ポート番号=200)を使い、宛先エンドポイントを表すトランスポートアドレスb(IPアドレス=192.168.0.2、ポート番号=100)へ接続確立要求(INITチャンク)を送信すると、図22の(2)に示すように、eNB#1−eNB#2間で複数のアソシエーション(A,B)が確立されることになる。
このようなケースは、例えば、既述のHO処理において発生する可能性がある。即ち、UEが第1のeNBから別の第2のeNBの無線エリアに移動した後、当該UEあるいは別のUEが第2のeNBから第1のeNBの無線エリアに移動したような場合である。
しかし、HO処理等のノード間通信に用いられる通信アプリケーション(アプリケーション層のプロトコル)では、その下位層であるトランスポート層に属するSCTP又はトランスポート層のさらに下位層であるネットワーク層に属するIPの情報からは、eNBを識別(特定)することができない場合がある。
つまり、図15に示したSCTPの共通ヘッダ情報や、図16や図17に示したINITチャンク、INIT-ACKチャンクに含まれる情報(パラメータ)からは、対向eNBのもつポート番号やそのアソシエーションを規定するパラメータを取得することは可能であり、SCTPの属するトランスポート層の下位層(ネットワーク層)に属するIPからIPアドレスも取得することは可能ではあるが、それらのパラメータはどのeNBとアソシエーションを確立したかを表現できる類のパラメータではないため、eNB#1、eNB#2ともにノード間で複数のアソシエーションを確立していることが識別できないのである。
このように、eNB間で複数のアソシエーションが確立されると、必要以上のアソシエーション管理が要求され、eNBでアソシエーション管理に割り当てるメモリ容量が増加して装置リソースが枯渇したり、アソシエーション毎に発生するハートビートによる生存確認(heartbeat keep-alive mechanism)等の処理量が増大したりして、eNBの性能劣化を招く場合がある。
なお、ハートビートによる生存確認とは、ある一定期間データ送信に使用されていない宛先アドレスに対して定期的にハートビートパケットを送り、その使用していないアドレスがアクティブかどうかを確認する処理のことである。
本システムの目的の一つは、ノード間の論理的な複数の通信リンクの確立を識別できるようにすることにある。
また、ノード間の冗長な論理的な通信リンクを解放できるようにすることも本システムの目的の一つである。
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本システムの他の目的の一つとして位置付けることができる。
例えば、以下の手段を用いる。
(1)ノード間で通信をする通信システムにおいて、信号に前記信号の送信元のノードを示す識別情報を付与し、前記ノード間に確立された通信リンクに、前記識別情報が付与された信号を伝送する手段と、前記通信リンクを介して受信した信号に付与された前記識別情報に基づいて、前記ノード間に重複して確立された通信リンクを検出し、前記検出した通信リンク数より少ない数分の前記ノード間に確立された通信リンクを解放する手段と、をそなえる、通信システムを用いることができる。
(2)ここで、前記伝送する信号は、前記通信リンクの確立に用いたプロトコルと異なるプロトコルの信号であることとしてもよい。
(3)また、ノード間で通信をする通信システムにおける通信処理方法であって、信号に前記信号の送信元のノードを示す識別情報を付与し、前記ノード間に確立された通信リンクに、前記識別情報を付与した信号を伝送し、前記第1及び第2のノードは、前記通信リンクを介して受信した信号に付与された前記識別情報に基づいて、前記ノード間に重複して確立された通信リンクを検出し、前記検出した通信リンク数より少ない数分の前記ノード間に確立された通信リンクを解放する、通信処理方法を用いることができる。
(4)ここで、前記伝送する信号は、前記通信リンクの確立に用いたプロトコルと異なるプロトコルの信号であることとしてもよい。
(5)さらに、他ノードと通信をするノードであって、他ノードを示す識別情報が付与された信号を、前記他ノードとの間に確立された通信リンクを介して、受信する受信手段と、前記受信した信号に付与された前記識別情報に基づいて、前記他ノードとの間に重複して確立された通信リンクを検出し、前記検出した通信リンク数より少ない数分の前記他ノードとの間に確立された通信リンクを解放する管理手段と、をそなえる、ノードを用いることができる。
)ここで、自ノードを示す識別情報を付与し、前記識別情報を付与した信号を前記他ノードとの間に確立された通信リンクへ送信する送信手段をさらにそなえてもよい。
)さらに、前記自ノードを示す識別情報と、前記他ノードを示す識別情報と、に基づいて、前記解放する通信リンクを決定することとしてもよい。
)また、ノードが起点となって確立した通信リンクを前記解放の対象とすることとしてもよい。
(9)ここで、前記通信リンクに伝送する信号は、前記通信リンクの確立に用いたプロトコルと異なるプロトコルの信号であることとしてもよい。
(10)また、他ノードと通信を行なうノードであって、自ノードを示す識別情報を信号に付与する識別情報付与手段と、前記識別情報が付与された信号を、前記他ノードと自ノードとの間に確立される通信リンクを介して、前記他ノードへ送信することで、前記他ノードに、前記通信リンクが自ノードとの間に確立されていることを通知することで、前記自ノードとの間に重複して確立された通信リンク数より少ない数分の前記ノード間に確立された通信リンクを解放させる送信手段と、をそなえる、ノードを用いることもできる。
ノード間の複数アソシエーションの確立を識別することができる。
また、ノード間の冗長なアソシエーションを解放することも可能である。
以下、図面を参照して実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本実施形態は、その趣旨を逸脱しない範囲で種々変形(各実施例を組み合わせる等)して実施することができる。
〔A〕概要
ノード(例えば、eNB)間のX2インタフェースで確立される論理的な通信リンクの一例としてのアソシエーションは、SCTPパケット(制御チャンク)をeNB間で伝送するのに用いることが可能である。例えば、HOシーケンスにおいて、X2インタフェース上を、「Handover Request」メッセージや、「Handover Request Acknowledge」メッセージ等を制御プレーン信号の一例として伝送することが可能である。
これらのメッセージ内のパラメータに、ノード(eNB)の識別情報(ノードID)を付与することで、該当アソシエーションを使ってHOシーケンスの制御プレーン信号を送受信している対向eNBを認識することが可能となる。なお、HOシーケンスは、eNB間通信の一例である。eNB間通信には、ノード(eNB)の起動時や再起動時などに必要となる他の通信(情報の送受信)も含まれる。したがって、その通信での制御プレーン信号に対してノードIDを付与することも、もちろん可能である(以下、同様)。
したがって、eNBは、アソシエーションの対向eNBを認識し、同一eNBに対し複数アソシエーションが確立されている場合には、不要なアソシエーションに対して、例えば、シャットダウン信号(SHUTDOWNチャンク)や中止信号(ABORTチャンク)を送信することで、不要アソシエーションの削除を行なうことが可能となる。これにより、eNBで使用するメモリ容量の削減、アソシエーション管理処理量の削減を図ることができる。
〔B〕第1実施形態
図1は、第1実施形態に係る無線通信システムの一例を示す図である。この図1に例示する無線通信システムは、無線アクセス網のエンティティ(ノード)の一例としての複数のeNB10と、eNB10の上位装置に相当するネットワークエンティティであるMME/S−GW20と、eNB10が形成する無線エリア(セル又はセクタ)においてeNB10と無線リンクにより通信する1又は複数のUE30と、をそなえる。
eNB10は、例えば図13や図14に示したように、他のeNB10とX2インタフェースにより通信することが可能であり、また、MME/S−GW20とS1インタフェースと通信することが可能である。
一方、UE30は、その移動に伴って接続先eNB10を切り替える(HOする)ことが可能であり、その際、HO元(Source)eNB10とHO先(Target)eNB10との間では、X2インタフェースにてHOシーケンスにおける制御プレーン信号(「Handover Request」メッセージや、「Handover Request Acknowledge」メッセージ等)を、例えばSCTPパケット(制御チャンク)により送受信することが可能である。
そして、この図1に示すeNB10は、例えば、1又は複数のアンテナ11と、1又は複数の増幅器(MHA:Mast Head Amplifier12)と、送信電力増幅器(TPA:Transmit Power Amplifier)13と、1又は複数の送受信機(TRX:Transmitter Receiver)141及び1又は複数のベースバンドユニット(BB)142を具備するRE(Radio Equipment)14と、スイッチ(SW)151、ハイウェイインタフェース(HWIF)152、共有メモリ(CM:Common Memory)153、呼処理ユニット(CPU:Call Processing Unit)154及びデータベースユニット(DB)155を具備するREC(Radio Equipment Controller)15と、をそなえる。
ここで、アンテナ11は、UE30との間で無線信号を送受信する無線インタフェースである。
MHA12は、アンテナ11とTPA13との間で送受される無線信号を増幅する。
TPA13は、MHA12とRE14(TRX141)との間で送受される無線信号を増幅する。
RE14において、TRX141は、BB142からの送信ベースバンド信号(UE30宛のダウンリンク信号)を無線周波数に周波数変換(アップコンバージョン)してTPA13に送信する一方、TPA13から受信した無線信号(アップリンク信号)をベースバンド周波数に周波数変換(ダウンコンバージョン)してBB142に送信する。
BB142は、REC15のSW151からの送信信号について所定の符号化、変調等を含むベースバンド処理を施してTRX141へ送信する一方、TRX141から受信したベースバンド信号について所定の復調、復号等を含むベースバンド処理を施してREC15のスイッチ151へ送信する。
REC15において、SW151は、CPU154からの制御の下、BB142とHWIF151との間の接続を切り替えて、BB142からの信号はHWIFへ、HWIF152からの信号はいずれかのBB142へ出力する。
HWIF152は、前記のS1インタフェース、X2インタフェースとしての機能を具備し、他のeNB10、MME/S−GW20と通信する。本例において、このHWIF152は、S1インタフェース、X2インタフェースを介して制御プレーン信号を送信する送信手段としての機能と、S1インタフェース、X2インタフェースを介して制御プレーン信号を受信する受信手段としての機能と、を具備する。
CM153は、CPU154が動作する上で用いるデータを保持する。このCM153には、例えば、DB155のデータが読み出されて展開される場合もある。
CPU154は、CM153及び/又はDB155に保持されたデータ(呼制御のためのアプリケーションデータや設定データ等が含まれる)を基に、SW151を制御して、UE30や他のeNB10、MME/S−GW20との間で送受される信号を適切な経路へ転送する。また、本例のCPU154は、他のeNB10との間のアソシエーションの確立、解放、X2インタフェース上で送受される制御プレーン信号に対する自ノード(eNB)IDの付与、対向ノードから制御プレーン信号にて受信したノードIDとアソシエーションとの関連付け、不要なアソシエーションの識別、削除(解放)などの処理も行なう。
つまり、CPU154は、X2インタフェースを介して前記HWIF152で受信した制御プレーン信号に付与されたノードIDと関連付けてアソシエーションを管理する管理手段としての機能と、X2インタフェースへ送信する制御プレーン信号に自ノードのノードIDを付与するノードID付与手段としての機能と、を具備する。
更に、前記管理手段の一例としてのCPU154は、前記ノードIDを基に、他の(対向)eNB10との間に重複して確立されたアソシエーションを識別する識別部としての機能と、識別したアソシエーションのいずれか一方を削除(解放)する解放部としての機能とを具備する。
DB155は、eNB10が動作する上で必要なデータを保持する。このDB155には、他のeNB10との間で確立、解放するアソシエーションを管理する情報も登録される。例えば、アソシエーション番号、自ノード10で使用しているエンドポイント、送信元/宛先ポート番号(SCTPパラメータ)、自ノード10(エンドポイント)のIPアドレス、他ノード10(エンドポイント)のIPアドレス等の情報を管理することが可能である。
次に、図2に、或るeNB10間(eNB#1−eNB#2間)で複数のアソシエーションが確立された場合における、eNB間HOシーケンスの一例を示す。本シーケンスを例にして、eNB#1−eNB#2間に複数のアソシエーションが確立された場合の不要アソシエーションの識別、削除動作を説明する。
eNB#1とeNB#2とがお互いにクライアントとしてトランスポート層に属するSCTPのアソシエーション確立動作を実施して、eNB#1−eNB#2間で複数のアソシエーションA,Bが確立された状態にあるとする(処理501)。即ち、本例において、トランスポート層は第1のレイヤの一例であり、SCTPは第1のレイヤに属する第1のプロトコルの一例である。
この場合、eNB#1(CPU154)は、自身がクライアントとして動作しeNB#2との間で確立したアソシエーションAと、eNB#1自身がサーバとなり確立したアソシエーションB(対向eNBは不明)と、をそれぞれ管理している。
例えば、図22と同様に、eNB#1(CPU154)は、送信元エンドポイントを表すトランスポートアドレスa(IPアドレス=192.168.0.1、ポート番号=100)を使い、宛先エンドポイントを表すトランスポートアドレスc(IPアドレス=192.168.0.3、ポート番号=200)に向かって接続確立要求(INITチャンク)を送信したとする。
一方、対向のeNB#2(CPU154)は、送信元エンドポイントを表すトランスポートアドレスd(IPアドレス=192.168.0.4、ポート番号=200)を使い、宛先エンドポイントを表すトランスポートアドレスb(IPアドレス=192.168.0.2、ポート番号=100)へ接続確立要求(INITチャンク)を送信したとする。
この場合、eNB#1は、アソシエーションA,Bに関する情報をアソシエーション管理テーブル等として管理する。その一例を図6の(1)に示す。この図6の(1)の例では、eNB#1は、「対向eNBのノードID」(ただし、この段階では不明)、確立したアソシエーションを識別する情報である「アソシエーション番号」、アソシエーションの確立が可能か否かを示す「アソシエーション確立可能判定フラグ」、自ノードで「使用しているエンドポイント」を識別する情報、「送信元ポート番号(SCTPパラメータ)」、「自ノードIPアドレス」、「宛先ポート番号(SCTPパラメータ)」、「他ノードのIPアドレス」等の情報をテーブル形式のデータとして管理する。なお、このアソシエーション管理テーブルは、例えば前記DB155に保持される。
同様に、eNB#2(CPU154)は、自身がクライアントとして動作しeNB#1との間で確立したアソシエーションBと、eNB#2自身がサーバとなり確立したアソシエーションA(ただし、対向eNB(ノードID)は不明)と、をそれぞれ自ノード#2内のアソシエーション管理テーブル(DB155)にて管理する。なお、eNB#2におけるアソシエーション管理テーブルは、図6の(1)に例示するeNB#1におけるアソシエーション管理テーブルの、送信元ポート番号と宛先ポート番号とを入れ替え、かつ、自ノードのIPアドレスと他ノードのIPアドレスとを入れ替えたものに相当する。
その後、eNB#1配下のUE30の移動に伴ってeNB#1がeNB#2へのHOを決定すると、eNB#1は、HOアプリケーションによりeNB#2とX2インタフェースを介してHO処理に関連する通信を行なう。
即ち、eNB#1(CPU154)は、X2インタフェースのアプリケーション層(X2−APレイヤ)の制御プレーン信号である「Handover Request」メッセージを生成し、これを自ノード#1がクライアントとして動作して確立したアソシエーションAを介して、eNB#2宛に送信する(処理502)。その際、eNB#1は、自ノード#1のノードIDを「Handover Request」メッセージに付与する。
つまり、本例において、X2インタフェースのアプリケーション層は、前記第1のレイヤ(トランスポート層)よりも上位の第2のレイヤの一例であり、前記制御プレーン信号は、前記第2のレイヤに属するプロトコルの信号(eNB間制御信号)の一例である。
なお、前記HOの要否の決定は、例えば、UE30からの受信電力等の受信品質の測定値を基準にして実施することができる。また、HOの決定は、eNB10ではなくUE30主導で実施することも可能である。この点は、以降も同様である。
次に、eNB#2は、受信した前記「Handover Request」メッセージから前記ノードIDを取得し、対向eNB(本例では、eNB#1)を確認する。eNB#2は、確認したeNB#1のノードIDを前記アソシエーション管理テーブルの該当エントリに登録する。
また、eNB#2は、受信した「Handover Request」メッセージに対する応答信号(X2−APレイヤの制御プレーン信号)として「Handover Request Acknowledge」メッセージを、「Handover Request」メッセージを受信したアソシエーションAを介して、対向のeNB#1へ送信する。その際、eNB#2は、自ノードのノードIDを「Handover Request Acknowledge」メッセージに付与してeNB#1へ送信する(処理503)。
なお、「Handover Request」や「Handover Request Acknowledge」メッセージ等のX2−APレイヤの制御プレーン信号にノードIDを付与する場合、例えば、既存のX2−APレイヤ信号内にノードIDの格納領域を設ける。この格納領域は、X2−APレイヤの制御プレーン信号内の任意の位置に設けることができる。また、この格納領域は、ネットワーク規模によりノードIDの取り得る範囲が変わることを想定し、可変長とすることができる。X2−APレイヤの制御プレーン信号内にノードIDと同等のパラメータが存在する場合は、ノードIDを付与せずに、当該パラメータを利用することも可能である。
eNB#1は、前記「Handover Request Acknowledge」メッセージを対向のeNB#2から受信すると、受信した「Handover Request Acknowledge」に付与されたノードIDを取得して、対向eNB#2を認識する。eNB#1は、取得したeNB#2のノードIDを前記アソシエーション管理テーブルの該当エントリに登録する。
次に、eNB#2配下のUE30の移動に伴ってeNB#2がeNB#1へのHOを決定すると、eNB#2は、X2−APレイヤの制御プレーン信号である「Handover Request」メッセージを、自ノード#2がクライアントとして動作して確立したアソシエーションBを介して、eNB#1へ送信する(処理504)。その際、eNB#2は、自ノード#2のノードIDを「Handover Request」メッセージに付与する。
eNB#1は、受信した「Handover Request」メッセージからノードIDを取得し、対向eNB(本例では、eNB#2)を確認する。eNB#1は、確認したeNB#2のノードIDを前記アソシエーション管理テーブルの該当エントリに登録する。
また、eNB#1は、受信した「Handover Request」メッセージに対する応答信号(X2−APレイヤの制御プレーン信号)として「Handover Request Acknowledge」メッセージを、「Handover Request」メッセージを受信したアソシエーションBを介して、対向のeNB#2へ送信する。その際、eNB#1は、自ノードのノードIDを「Handover Request Acknowledge」メッセージに付与してeNB#2へ送信する(処理505)。
eNB#2は、前記「Handover Request Acknowledge」メッセージを対向のeNB#1から受信すると、受信した「Handover Request Acknowledge」に付与されたノードIDを取得して、対向eNB#1を認識する。eNB#2は、取得したeNB#1のノードIDを前記アソシエーション管理テーブルの該当エントリに登録する。
なお、図3に、アソシエーションA,Bにおいて、それぞれ上述の「Handover Request」メッセージ、「Handover Request Acknowledge」メッセージが伝送される方向を示す。なお、エンドポイントの数は図3ではeNB10毎に2つとしているが、もちろん、これに限定されない。エンドポイントの数は、eNB10毎に3つ以上存在する場合もあるし、eNB10毎に異なる数である場合もある。また、図3の例では、異なるエンドポイント間で異なるアソシエーションが確立されているが、ポイントツーマルチポイントのように1つのエンドポイントに対して複数のアソシエーションが確立される場合もある。以下、同様である。
次に、eNB#1及びeNB#2(CPU154)は、それぞれ、上述のごとくX2−APレイヤの制御プレーン信号の送受信により互いのノードIDを取得して互いの対向ノードを識別すると(図5の処理601)、対向eNBとの間に複数のアソシエーションA,Bを確立しているか否かを判定する(図5の処理602)。
例えば、eNB10(CPU154)は、前記アソシエーション管理テーブルにおける「対向eNBのノードID」のエントリをチェックすることで、複数のアソシエーションが確立されているか否かを判定する。即ち、eNB10は、同じ「対向eNBのノードID」のエントリが複数登録されていることをもって、複数のアソシエーションが確立されていることを認識する。
eNB10(CPU154)は、複数アソシエーションが確立されていることを認識すると(図5の処理602のYesルート)、重複アソシエーションの削除シーケンスを実施する。その際、eNB10(CPU154)は、(a)アソシエーションの削除元(シャットダウン信号又は中止信号等のアソシエーション切断(削除)シーケンスの送信元)となるeNB10と、(b)eNB#1,#2間で削除対象とするアソシエーションと、を決定する(図5の処理603及び処理604)。
前記(a)については、例えば、eNB10間でノードIDを比較し、番号情報としてより小さなノードIDをもつeNBをアソシエーションの削除元と決定することができる。前記(b)については、アソシエーション削除元となったeNB10がクライアントとして動作して確立したアソシエーションを削除対象と決定することができる。
つまり、先に述べた解放部としてのCPU154は、番号情報としての自ノードの識別情報が対向eNB10から受信したノードID(対向eNB10のノードID)よりも小さい場合に、自eNB10がアソシエーション削除を実施するeNBであると決定し、自eNB10が起点となって確立したアソシエーションを削除(解放)の対象とするのである。
ここでは、一例として、eNB#1とeNB#2の各ノードIDを比較した結果、eNB#1のノードIDが番号情報として小さいと仮定し、(a)アソシエーション削除元となるeNB10は「eNB#1」、(b)削除対象のアソシエーションはeNB#1がクライアントとして確立した「アソシエーションA」と、決定したと仮定する。
アソシエーションAの削除元であるeNB#1(CPU154)は、図4の(1)に示すように、削除対象として決定したアソシエーションAに対してシャットダウン信号(SHUTDOWNチャンク)や中止信号(ABORTチャンク)を送信して、アソシエーション切断(削除)シーケンスを実施する(図5の処理605)。
ここで、eNB#1及びeNB#2は、eNB#1−eNB#2間で削除したアソシエーションAを再確立しないようにするため、それぞれ、SCTPパケット(INIT chunk)を送信しないよう情報(確立不可)を例えば図6の(2)に示すように前記アソシエーション管理テーブル(「アソシエーション確立可能判定フラグ」)に設定(保持)することも可能である。ただし、何らかの要因によりSCTPパケット(INIT chunk)を受信した場合は、応答信号(INIT ACK)を返し、アソシエーション確立シーケンスの実行を許容することとしてもよい。
以後、eNB#1−eNB#2間でHO処理が発生した場合、図4の(2)に示すように、残ったアソシエーションBを使用して、eNB#1,#2は、制御プレーン信号の送受信を行なう。
以上のように、本例によれば、eNB10間にSCTPのアソシエーションが確立された後に、当該eNB間で送受信される制御プレーン信号にノードIDを付与して、そのアソシエーションがどのノード間で確立されているかチェック(識別)することができるから、不要なアソシエーションを判定、削除することが可能となる。
したがって、eNB10で使用するメモリ容量の削減、アソシエーション管理処理量の削減を図ることができ、eNB10の性能劣化を防止することが可能となる。
〔C〕第2実施形態
上述した第1実施形態では、eNB10間のHOを一例にして重複アソシエーションの識別、削除処理を説明したが、eNB10に限らず、次世代無線通信ネットワークにおいてSCTPを実装するノードや、IPSec(Security Architecture for Internet Protocol)を実装するノードなど、ノードがクライアント及びサーバの関係になるネットワークにおいても、第1実施形態で説明した処理を適用することが可能である。
ここで、IPSecとは、ネットワーク層のプロトコルの一つであり、ネットワーク層のプロトコル(IP等)に対し、暗号化機能を用いて、データの完全性保証やデータの暗号化による改竄防止を実現するプロトコルである。
IPSecには、トランスポートモードとトンネルモードの2つのモードが存在する。トランスポートモードとは、2つのノード間をIPSecで接続する際に適用されるモードであり、トンネルモードとは、2つのセグメント(ゲートウェイ)間を接続する際に適用されるモードである。トンネルモードは、主に、VPN(Virtual Private Network)などの、仮想ネットワークを構築する際に用いられる。図7に、トランスポートモードとトンネルモードが適用される通信システムのイメージを示す。
この図7に示す例では、或るネットワーク#1に、ノードの一例としての、コンピュータ(ユーザ端末)50(#1,#2)とセキュリティゲートウェイ(SG)60とが存在し、他のネットワーク#2にも、ノードの一例としての、コンピュータ(ユーザ端末)50(#3)とセキュリティゲートウェイ(SG)60とが存在しており、各ネットワーク#1,#2(SG60)間がルータ70を介して接続されている。
つまり、この例では、コンピュータ#1は、自身が属するネットワーク#1内の他のコンピュータ#2とIPSecのトランスポートモードにより接続して通信することが可能である。また、コンピュータ#1は、セキュリティゲートウェイ60間でのIPSecのトンネルモードによる接続を介して、他のネットワーク#2に属するコンピュータ#3とIPSecによる通信も可能である。
なお、図7において、符号201は、IPSecによる通信を可能にするIPSec機能部、符号202はIPSecの属するネットワーク層よりも上位のアプリケーション層に属するプロトコルを扱うアプリケーション部、符号203はノード50又は60が動作する際に用いられる各種データを保持するメモリ(記憶部)を表す。IPSec機能部201及びアプリケーション部202は、例えば、通信制御部200として機能するCPU(Central Processing Unit)等の演算装置によって実現することができる。
トランスポートモードとトンネルモードとの違いとしては、IPSec適用後のデータに付与するIPヘッダを、IPSec適用前のデータに付与していたオリジナルのIPヘッダとするか(トランスポートモード)、IPSec適用前のデータに付与していたオリジナルのIPヘッダはデータ(ペイロード)の一部として、新たにトンネルモード用のヘッダであるトンネルIPヘッダを付与するか(トンネルモード)の違いがある。
このIPSecに用いられる機能を次表1に示す。
Figure 0004998316
なお、IPSecを使用する場合、上記機能のすべてを使用する必要はなく、一部の機能を組み合わせて使用することも可能である。
IPSecは、セキュリティアソシエーション(SA:Security Association)と呼ばれる概念をもつ。SAの中には、SPD(Security Policy Database)という、対向ノード(IPアドレス)との間でIPSec通信が可能か判定するためのデータベースと、SAD(Security Association Database)というセキュリティ情報(暗号アルゴリズムや鍵情報、通信プロトコル情報など)をもったデータベースと、が存在する。なお、SPD、SADは例えば前記メモリ203に保持される。
SAについて以下に説明する。
1.アプリケーション部202から、データを受信したIPSec機能部201は、相手先ノードとの間で、IPSec通信が可能か否かを判定するために、SPDを検索する。
2.SPDを検索した結果、IPSec通信が不可であれば、IPSec機能部201は、アプリケーションから受信したデータを相手先ノードに対しIPSecを適用せずに送信する。
3.SPDを検索した結果、IPSec通信が可能であれば、IPSec機能部201は、SADを検索し、その相手先ノードとの間の通信に用いるセキュリティ情報を取得する。もし、セキュリティ情報が存在しない場合は、IPSec機能部201は、IKEプロトコルにより相手先ノードとの間で使用するセキュリティ情報を取得し、SADに登録する。そして、IPSec機能部201は、SADに登録されたセキュリティ情報を元に相手先ノードとIPSec通信を行なう。
4.データを受け取った相手先ノードのIPSec機能部201は、SADを検索し、該当データのセキュリティ情報を元にIPSec復号処理を行なう。
5.相手先ノードのIPSec機能部201は、IPSec復号処理を施されたデータの処理可否を判定するため、SPDを検索する。処理可能であれば、IPSec機能部201は、受信パケットと判断し処理を行ない、処理不可であれば、受信パケットを破棄する。
次に、前記IKEプロトコルについて説明する。
ノード間でIPSecによる通信を行なう場合、IKEプロトコルによりノード間にSAを確立する。図8にIKEプロトコルによるSA確立イメージを示す。
ノード#1(IPSec機能部201)は、フェーズ1で相手方ノード#2との間にISAKMP SAを確立する。ISAKMP(Internet Security Association and Key Management Protocol)とは、鍵交換相手の認証と鍵交換を行なうためのプロトコルである。このとき、SAは、双方向に確立されIKEメッセージ自体を保証するために用いられる。
次に、ノード#1(IPSec機能部201)は、フェーズ2で相手方ノード#2との間にIPSec SAとIPCA(IPComp Association)とを確立する。IPSec SAは、実際のデータ通信に使用するAHやESPのアルゴリズムを決定するために確立するSAである。IPCAは、IPComp(データ圧縮)を行なうために確立するSAである。
これらのSAは片方向であり、双方のノード#1,#2でAH、ESP、IPCAを確立する場合は、計6本のSAが必要になる。その場合、ノード#1,#2(IPSec機能部201)は、お互いにIPSec確立の起点(クライアント)となるため、第1実施形態で説明したSCTPと同様にノード間に複数のIPSecのアソシエーション(SA)が確立されてしまう可能性がある。なお、前記ノード間には、図7に例示するノード50間、ノード50とノード60との間、ノード60間のいずれか1又は複数が含まれ得る。
このような複数のSAについても、ノード#1,#2が具備する前記通信制御部200において、第1実施形態と同様の処理を実施することが可能である。即ち、通信制御部200は、SAに関する管理手段(SAの識別部、解放部)、ノードID付与手段としての機能を具備する。
そして、通信制御部200は、他ノードとの間のSAの確立、解放、IPSec(第1のプロトコル)の属する第1のレイヤ(ネットワーク層)よりも上位の第2のレイヤ(アプリケーション層)に属する(第2の)プロトコルで送受される信号(制御プレーン信号)に対する自ノードIDの付与、対向ノードから制御プレーン信号にて受信したノードIDとSAとの関連付け、不要なSAの識別、削除(解放)などの処理を行なう。
以下、その一例について説明する。
例えば図9に示すように、ノード#1とノード#2とがお互いにIPSecのアソシエーション確立動作を実施し、ノード#1,#2間で複数のアソシエーションA,Bが確立された状態にあるとする(処理701)。
この場合、ノード#1は、自身がクライアントとして動作して対向ノード#2との間で確立したアソシエーションAと、ノード#1自身がサーバとして動作して確立したアソシエーションB(対向ノードは不明)と、をそれぞれ管理する。
同様に、ノード#2は、自身がクライアントとして動作して対向ノード#1との間で確立したアソシエーションBと、ノード#2自身がサーバとして動作して確立したアソシエーションA(対向ノードは不明)と、をそれぞれ管理する。ノード#1,#2でのそれぞれの管理手法は、第1実施形態と同様でよい。
その後、ノード#1とノード#2との間で或るアプリケーション(IPSecの属するネットワーク層よりも上位のアプリケーション層のプロトコル)による通信を行なう場合を考える。
例えば、ノード#1は、或るアプリケーションにより対向ノード#2宛に何らかの要求を行なう場合に、その旨を表すアプリケーション層のノード間制御プレーン信号(Request)を、自ノード#1がクライアントとして動作して確立したアソシエーションAを介して、対向ノード#2宛に送信する(処理702)。その際、ノード#1は、当該制御プレーン信号(Request)に、自ノード#1のノードIDを付与する。
ノード#2は、受信した前記制御プレーン信号(Request)から前記ノードIDを取得し、対向ノード#1を確認する。ノード#2は、確認した対向ノード#1のノードIDをアソシエーション管理テーブル(例えば、前記メモリ203に保持される)の該当エントリに登録する。
また、ノード#2は、受信した制御プレーン信号(Request)に対する応答信号(制御プレーン信号(Reply)を、制御プレーン信号(Request)を受信したアソシエーションAを介して、対向ノード#1へ送信する。その際、ノード#2は、自ノードのノードIDを制御プレーン信号(Reply)に付与する(処理703)。
なお、制御プレーン信号(Request、Reply)にノードIDを付与する場合、例えば、既存の制御プレーン内にノードIDの格納領域を設ける。この格納領域は、制御プレーン信号内の任意の位置に設けることができる。また、この格納領域は、ネットワーク規模によりノードIDの取り得る範囲が変わることを想定し、可変長とすることができる。制御プレーン信号内にノードIDと同等のパラメータが存在する場合は、ノードIDを付与せずに、当該パラメータを利用することも可能である。
ノード#1は、前記制御プレーン信号(Reply)を対向ノード#2から受信すると、受信した制御プレーン信号(Reply)に付与されたノードIDを取得して、対向ノード#2を認識する。ノード#1は、取得したノード#2のノードIDをアソシエーション管理テーブル(例えば、前記メモリ203に保持される)の該当エントリに登録する。
次に、eNB#2も、対向ノード#1宛に何らかの要求を行なう場合に、その旨を表すノード間制御プレーン信号(Request)を、自ノード#2がクライアントとして動作して確立したアソシエーションBを介して、対向ノード#1宛に送信する(処理704)。その際、ノード#2は、当該制御プレーン信号(Request)に、自ノード#2のノードIDを付与する。
ノード#1は、受信した制御プレーン信号(Request)からノードIDを取得し、対向ノード#2を確認する。ノード#1は、確認したノード#2のノードIDをアソシエーション管理テーブルの該当エントリに登録する。
また、ノード#1は、受信した制御プレーン信号(Request)に対する応答信号として制御プレーン信号(Reply)を、制御プレーン信号(Request)を受信したアソシエーションBを介して、対向ノード#2へ送信する。その際、ノード#1は、自ノード#1のノードIDを制御プレーン信号(Reply)に付与してノード#2へ送信する(処理705)。
ノード#2は、前記制御プレーン信号(Reply)を対向ノード#1から受信すると、受信した制御プレーン信号(Reply)に付与されたノードIDを取得して、対向ノード#1を認識する。ノード#2は、取得したノード#1のノードIDをアソシエーション管理テーブルの該当エントリに登録する。
なお、図10に、アソシエーションA,Bにおいて、それぞれ上述の制御プレーン信号(Request、Reply)が伝送される方向を示す。
次に、ノード#1及び#2は、それぞれ、上述のごとく制御プレーン信号の送受信により互いのノードIDを取得して互いの対向ノードを識別すると(図12の処理801)、対向ノードとの間に複数のアソシエーションA,Bを確立しているか否かを判定する(図12の処理802)。
例えば、ノード#1及び#2は、アソシエーション管理テーブルにおける「対向ノードID」のエントリをチェックすることで、複数のアソシエーションが確立されているか否かを判定する。即ち、ノード#1及び#2は、同じ「対向ノードID」のエントリが複数登録されていることをもって、複数のアソシエーションが確立されていることを認識する。
ノード#1及び#2は、複数アソシエーションが確立されていることを認識すると(図12の処理802のYesルート)、重複アソシエーションの削除シーケンスを実施する。その際、ノード#1及び#2は、(a)アソシエーションの削除元(シャットダウン信号又は中止信号等のアソシエーション切断(削除)シーケンスの送信元)となるノードと、(b)ノード#1,#2間で削除対象とするアソシエーションと、を決定する(図12の処理803及び処理804)。
前記(a)については、例えば、ノードIDを比較し、番号情報としてより小さなノードIDをもつノードをアソシエーションの削除元と決定することができる。前記(b)については、アソシエーション削除元となったノードがクライアントとして動作して確立したアソシエーションを削除対象と決定することができる。
ここでは、ノード#1とノード#2の各ノードIDを比較した結果、ノード#1のノードIDが番号情報として小さいと仮定し、(a)アソシエーション削除元となるノードは「ノード#1」、(b)削除対象のアソシエーションはノード#1がクライアントとして確立した「アソシエーションA」と、決定したと仮定する。
アソシエーションAの削除元であるノード#1は、図11の(1)に示すように、削除対象として決定したアソシエーションAに対してシャットダウン信号や中止信号を送信して、アソシエーション切断(削除)シーケンスを実施する(図12の処理805)。
ここで、ノード#1及び#2は、ノード#1−ノード#2間で削除したアソシエーションAを再確立しないようにするため、それぞれ、IPSec確立用制御パケットを送信しないよう情報(確立不可)をアソシエーション管理テーブル(「アソシエーション確立可能判定フラグ」)に保持する。ただし、何らかの要因により制御プレーン信号を受信した場合は、応答信号(Reply)を返し、アソシエーション確立シーケンスの実行を許容することとしてもよい。
以後、ノード#1−ノード#2間で制御プレーン信号を送受信する場合、図11の(2)に示すように、残ったアソシエーションBを使用して、eNB#1,#2は、制御プレーン信号の送受信を行なう。
以上のように、本例によれば、IPSecのアソシエーションに関しても、或るノード間に複数アソシエーションが確立された後に、当該ノード間で送受信される制御プレーン信号にノードIDを付与して、そのアソシエーションがどのノード間で確立されているかチェック(識別)することができるから、不要なアソシエーションを判定、削除することが可能となる。
したがって、IPSecによる通信機能を具備するノードで使用するメモリ容量の削減、アソシエーション管理処理量の削減を図ることができ、IPSecによる通信機能を具備するノードの性能劣化を防止することが可能となる。
〔D〕その他
なお、上述した第1実施形態では、eNB間でアソシエーションを確立するのに用いる第1のレイヤに属する第1のプロトコルの一例としてトランスポート層に属するSCTPを挙げ、前記アソシエーションを伝送する上位(第2)のレイヤに属する第2のプロトコルの信号の一例としてアプリケーション層に属するeNB間制御プレーン信号を挙げたが、これらに限定されない。
同様に、第2実施形態では、ノード間でセキュリティアソシエーション(SA)を確立するのに用いる第1のレイヤに属する第1のプロトコルの一例としてネットワーク層に属するIPSecを挙げ、前記SAを伝送する上位(第2)のレイヤに属する第2のプロトコルの信号の一例としてアプリケーション層に属するノード間制御プレーン信号を挙げたが、これらに限定されない。
これらのレイヤ、プロトコルの従属関係にあるプロトコル通信にも上述した実施形態は適用可能である。
〔E〕付記
(付記1)
第1のノードと、前記第1のノードと通信する第2のノードと、をそなえた通信システムにおいて、
前記第1のノードと前記第2のノードとの間で第1のレイヤに属する第1のプロトコルを用いて確立された論理的な通信リンクへ、前記第1のレイヤよりも上位の第2のレイヤに属する第2のプロトコルの信号であり、かつ、送信元のノード識別情報を付与した信号を伝送する手段と、
前記通信リンクを介して受信した信号に付与された前記ノード識別情報と関連付けて前記通信リンクを管理する手段と、
をそなえたことを特徴とする、通信システム。
(付記2)
第1のノードと、前記第1のノードと通信する第2のノードと、をそなえた通信システムにおける通信処理方法であって、
前記第1のノードと前記第2のノードとの間で第1のレイヤに属する第1のプロトコルを用いて確立された論理的な通信リンクへ、前記第1のレイヤよりも上位の第2のレイヤに属する第2のプロトコルの信号であり、かつ、送信元のノード識別情報を付与した信号を伝送し、
前記第1及び第2のノードは、前記通信リンクを介して受信した信号に付与された前記ノード識別情報と関連付けて前記通信リンクを管理する、
ことを特徴とする、通信処理方法。
(付記3)
前記管理は、
前記ノード識別情報を基に、前記第1のノードと前記第2のノードとの間に重複して確立された前記通信リンクを識別し、いずれか一方の通信リンクを解放する処理を含む、ことを特徴とする、付記2記載の通信処理方法。
(付記4)
前記解放を実施するノードは、番号情報としての前記ノード識別情報が小さいノードである、ことを特徴とする、付記3記載の通信処理方法。
(付記5)
前記解放の対象とする通信リンクは、前記番号情報の小さいノードが起点となって確立した通信リンクである、ことを特徴とする、付記4記載の通信処理方法。
(付記6)
前記第1及び第2のノードは、それぞれ、無線基地局であり、
前記第1のプロトコルは、前記第1のレイヤとしてのトランスポート層に属するSCTP(Stream Control Transmission Protocol)であり、
前記第2のプロトコルの信号は、前記第2のレイヤとしてのアプリケーション層に属する無線基地局間の制御信号である、ことを特徴とする、付記2〜5のいずれか1項に記載の通信処理方法。
(付記7)
前記制御信号は、ハンドオーバ処理関連の制御信号である、ことを特徴とする、付記6記載の通信処理方法。
(付記8)
前記第1及び第2のノードは、それぞれ、前記第1のレイヤとしてのネットワーク層に属する前記第1のプロトコルとしてのIPSec(Security Architecture for Internet Protocol)による通信機能を具備するノードであり、
前記第2のプロトコルの信号は、前記第2のレイヤとしてのアプリケーション層に属するノード間制御信号である、ことを特徴とする、付記2〜5のいずれか1項に記載の通信処理方法。
(付記9)
第1のノードと通信する第2のノードであって、
前記第1のノードとの間で第1のレイヤに属する第1のプロトコルを用いて確立された論理的な通信リンクから、前記第1のレイヤよりも上位の第2のレイヤに属する第2のプロトコルの信号であり、かつ、前記第1のノードのノード識別情報が付与された信号を受信する受信手段と、
前記受信手段で受信した信号に付与された前記ノード識別情報と関連付けて前記通信リンクを管理する管理手段と、
をそなえたことを特徴とする、ノード。
(付記10)
前記第2のプロトコルの信号に前記第2のノードのノード識別情報を付与した信号を前記通信リンクへ送信する送信手段をさらにそなえたことを特徴とする、付記9記載のノード。
(付記11)
前記管理手段は、
前記ノード識別情報を基に、前記第1のノードとの間に重複して確立された前記通信リンクを識別する識別部と、
前記識別した通信リンクのいずれか一方を解放する解放部と、
をさらにそなえたことを特徴とする、付記9又は10に記載のノード。
(付記12)
前記解放部は、
番号情報としての前記第2のノードの識別情報が前記第1のノードから受信したノード識別情報よりも小さい場合に、前記解放を実施する、ことを特徴とする、付記11記載のノード。
(付記13)
前記解放部は、
前記第2のノードが起点となって確立した通信リンクを前記解放の対象とする、ことを特徴とする、付記12記載のノード。
(付記14)
前記第1及び第2のノードは、それぞれ、無線基地局であり、
前記第1のプロトコルは、前記第1のレイヤとしてのトランスポート層に属するSCTP(Stream Control Transmission Protocol)であり、
前記第2のプロトコルの信号は、前記第2のレイヤとしてのアプリケーション層に属する無線基地局間の制御信号である、ことを特徴とする、付記9〜13のいずれか1項に記載のノード。
(付記15)
前記制御信号は、ハンドオーバ処理関連の制御信号である、ことを特徴とする、付記14記載のノード。
(付記16)
前記第1及び第2のノードは、それぞれ、前記第1のレイヤとしてのネットワーク層に属する前記第1のプロトコルとしてのIPSec(Security Architecture for Internet Protocol)による通信機能を具備するノードであり、
前記第2のプロトコルの信号は、前記第2のレイヤとしてのアプリケーション層に属するノード間制御信号である、ことを特徴とする、付記9〜14のいずれか1項に記載のノード。
(付記17)
第2のノードと通信する第1のノードであって、
前記第2のノードとの間で第1のレイヤに属する第1のプロトコルを用いて確立された論理的な通信リンクへ送信する信号であって、前記第1のレイヤよりも上位の第2のレイヤに属する第2のプロトコルの信号に、前記第1のノードのノード識別情報を付与するノード識別情報付与手段と、
前記ノード識別情報が付与された前記第2のプロトコルの信号を前記通信リンクへ送信する送信手段と、
をそなえたことを特徴とする、ノード。
第1実施形態に係る無線通信システムの一例を示す図である。 図1に示す無線通信システムにおけるHOシーケンスの一例を示すシーケンス図である。 図2に示すHOシーケンスにおいてeNB間で伝送される制御プレーン信号の伝送方向を示すイメージ図である。 図1に示す無線通信システムのeNB間で重複して確立されたアソシエーションの削除動作を説明するイメージ図である。 図1に示す無線通信システムのeNB間で重複して確立されたアソシエーションの削除動作を説明するフローチャートである。 図1に示すeNBで管理されるアソシエーション管理テーブルの一例を示す図である。 第2実施形態に係る通信システムの一例を示す図である。 図7に示す通信システムにおけるノード間にSAを確立するシーケンス例を示す図である。 図7に示すノード間で確立されたSAを用いた信号シーケンスの一例を示す図である。 図9に示す信号シーケンスにおいてノード間で伝送される制御プレーン信号の伝送方向を示すイメージ図である。 図7に示す通信システムのノード間で重複して確立されたアソシエーションの削除動作を説明するイメージ図である。 図7に示す通信システムのノード間で重複して確立されたアソシエーションの削除動作を説明するフローチャートである。 LTEの無線通信システムの構成例を示す図である。 LTEの無線通信システムにおけるHO処理を説明するイメージ図である。 SCTPパケットのフォーマット例を示す図である。 INITチャンクのフォーマット例を示す図である。 INIT-ACKチャンクのフォーマット例を示す図である。 SCTPのアソシエーション確立時のハンドシェイクの一例を示すシーケンス図である。 S1インタフェースの制御プレーンのプロトコルスタックの一例を示す図である。 X2インタフェースの制御プレーンのプロトコルスタックの一例を示す図である。 LTEの無線通信システムにおけるSCTPの接続開始シーケンスの一例を示す図であり、(A)はS1インタフェース上の接続開始シーケンス、(B)はX2インタフェース上の接続開始シーケンスの一例をそれぞれ示す図である。 ノード(eNB)間で複数のアソシエーションが確立される様子を示すイメージ図である。
符号の説明
10 無線基地局(eNB)
11 アンテナ
12 MHA(Mast Head Amplifier)
13 TPA(Transmit Power Amplifier)
14 RE(Radio Equipment)
141 TRX(Transmitter Receiver)
142 BB(Baseband Unit)
15 REC(Radio Equipment Controller)
151 スイッチ(SW)
152 HWIF(High Way Interface)
153 CM(Common Memory)
154 CPU(Call Processing Unit)
155 DB(Data Base)
20 MME/S−GW
30 無線端末(UE)
50 コンピュータ(ユーザ端末(ノード))
60 セキュリティゲートウェイ(SG(ノード))
70 ルータ
200 通信制御部
201 IPSec機能部
202 アプリケーション部
203 メモリ(記憶部)

Claims (10)

  1. ノード間で通信をする通信システムにおいて、
    信号に前記信号の送信元のノードを示す識別情報を付与し、前記ノード間に確立された通信リンクに、前記識別情報が付与された信号を伝送する手段と、
    前記通信リンクを介して受信した信号に付与された前記識別情報に基づいて、前記ノード間に重複して確立された通信リンクを検出し、前記検出した通信リンク数より少ない数分の前記ノード間に確立された通信リンクを解放する手段と、
    をそなえたことを特徴とする、通信システム。
  2. 前記伝送する信号は、前記通信リンクの確立に用いたプロトコルと異なるプロトコルの信号であることを特徴とする、請求項1記載の通信システム。
  3. ノード間で通信をする通信システムにおける通信処理方法であって、
    信号に前記信号の送信元のノードを示す識別情報を付与し、前記ノード間に確立された通信リンクに、前記識別情報を付与した信号を伝送し、
    前記通信リンクを介して受信した信号に付与された前記識別情報に基づいて、前記ノード間に重複して確立された通信リンクを検出し、前記検出した通信リンク数より少ない数分の前記ノード間に確立された通信リンクを解放することを特徴とする、通信処理方法。
  4. 前記伝送する信号は、前記通信リンクの確立に用いたプロトコルと異なるプロトコルの信号であることを特徴とする、請求項3記載の通信処理方法。
  5. 他ノードと通信をするノードであって、
    他ノードを示す識別情報が付与された信号を、前記他ノードとの間に確立された通信リンクを介して、受信する受信手段と、
    前記受信した信号に付与された前記識別情報に基づいて、前記他ノードとの間に重複して確立された通信リンクを検出し、前記検出した通信リンク数より少ない数分の前記他ノードとの間に確立された通信リンクを解放する管理手段と、
    をそなえたことを特徴とする、ノード。
  6. 自ノードを示す識別情報を付与し、前記識別情報を付与した信号を、前記他ノードとの間に確立された通信リンクへ送信する送信手段をさらにそなえたことを特徴とする、請求項5記載のノード。
  7. 前記自ノードを示す識別情報と、前記他ノードを示す識別情報と、に基づいて、前記解放する通信リンクを決定することを特徴とする、請求項5記載のノード。
  8. 自ノードが起点となって確立した通信リンクを、前記解放の対象とすることを特徴とする、請求項5記載のノード。
  9. 前記通信リンクに伝送する信号は、前記通信リンクの確立に用いたプロトコルと異なるプロトコルの信号であることを特徴とする、請求項5〜8のいずれか1項に記載のノード。
  10. 他ノードと通信を行なうノードであって、
    自ノードを示す識別情報を信号に付与する識別情報付与手段と、
    前記識別情報が付与された信号を、前記他ノードと自ノードとの間に確立される通信リンクを介して、前記他ノードへ送信することで、前記他ノードに、前記通信リンクが自ノードとの間に確立されていることを通知することで、前記自ノードとの間に重複して確立された通信リンク数より少ない数分の前記ノード間に確立された通信リンクを解放させる送信手段と、
    をそなえたことを特徴とする、ノード。
JP2008038595A 2008-02-20 2008-02-20 通信システム及び通信処理方法並びにノード Expired - Fee Related JP4998316B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008038595A JP4998316B2 (ja) 2008-02-20 2008-02-20 通信システム及び通信処理方法並びにノード
US12/273,232 US8089936B2 (en) 2008-02-20 2008-11-18 Communications system, communications processing method, and nodes
EP20080170106 EP2093975A1 (en) 2008-02-20 2008-11-27 Communications system, nodes, and method for releasing redundant connections

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008038595A JP4998316B2 (ja) 2008-02-20 2008-02-20 通信システム及び通信処理方法並びにノード

Publications (2)

Publication Number Publication Date
JP2009200689A JP2009200689A (ja) 2009-09-03
JP4998316B2 true JP4998316B2 (ja) 2012-08-15

Family

ID=40756953

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008038595A Expired - Fee Related JP4998316B2 (ja) 2008-02-20 2008-02-20 通信システム及び通信処理方法並びにノード

Country Status (3)

Country Link
US (1) US8089936B2 (ja)
EP (1) EP2093975A1 (ja)
JP (1) JP4998316B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200004854A (ko) * 2017-05-05 2020-01-14 지티이 코포레이션 통신 방법, 장비, 시스템 및 컴퓨터 저장 매체

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9444823B2 (en) * 2008-12-24 2016-09-13 Qualcomm Incorporated Method and apparatus for providing network communication association information to applications and services
CN102349319B (zh) * 2009-03-11 2015-07-22 瑞典爱立信有限公司 中继节点的设置和配置
US20100271979A1 (en) * 2009-04-27 2010-10-28 Alcatel-Lucent Usa Inc. Methods To Facilitate Automatic System Configuration
EP2288221B1 (en) * 2009-08-18 2015-10-21 Institute for Imformation Industry System and connection initialization method thereof
CN102065565B (zh) * 2009-11-11 2015-04-01 中兴通讯股份有限公司 建立家庭基站间直接接口所需信息的上报方法及家庭基站
KR101599557B1 (ko) * 2010-01-19 2016-03-07 삼성전자주식회사 무선 통신 시스템에서 스트림 제어 전송 프로토콜 연결을 제어하는 방법 및 장치
US9332582B2 (en) * 2010-04-30 2016-05-03 Qualcomm Incorporated System, apparatus and method for coordinating peer communication in wireless systems
US9451018B2 (en) * 2011-03-30 2016-09-20 Telefonaktiebolaget Lm Ericsson (Publ) SCTP endpoint migration
CN102726082B (zh) * 2012-01-04 2014-11-05 华为技术有限公司 X2安全通道建立方法与系统、以及基站
KR101941505B1 (ko) * 2012-02-15 2019-01-23 삼성전자주식회사 다수의 기지국들이 협력하는 무선 통신 시스템에서 서비스 제공 방법 및 장치와 그 시스템
EP2832149B1 (en) * 2012-03-30 2019-01-16 Nokia Solutions and Networks Oy Devices, methods and computer program products for an improved handover in inter-site carrier aggregation scenarios
EP2693832B1 (en) 2012-07-31 2019-05-22 Alcatel Lucent Notification of the break of an SCTP association between an X2 Routing Proxy and an eNB
US9451530B2 (en) 2012-11-02 2016-09-20 Telefonaktiebolaget L M Ericsson (Publ) Methods for base-station-to-base-station connection management
CN103945432B (zh) * 2013-01-18 2017-08-29 中国普天信息产业股份有限公司 集群系统基站的工作模式转换方法
CN103974228B (zh) * 2013-01-30 2019-05-07 中兴通讯股份有限公司 一种实现x2代理的方法及系统
WO2014131464A1 (en) * 2013-03-01 2014-09-04 Nokia Solutions And Networks Oy Voice-over-lte interface specific application protocol
GB2512656A (en) * 2013-04-05 2014-10-08 Nec Corp Communication system
US10117147B2 (en) * 2014-06-06 2018-10-30 Nec Corporation Server device, base station, information processing method, and storage medium
US10514683B2 (en) 2015-09-16 2019-12-24 Profire Energy, Inc. Distributed networking system and method to implement a safety state environment
US10432754B2 (en) 2015-09-16 2019-10-01 Profire Energy, Inc Safety networking protocol and method
CN109155777B (zh) * 2016-06-02 2021-09-14 瑞典爱立信有限公司 用于处置sctp分组的方法和网络节点
WO2018159204A1 (ja) * 2017-02-28 2018-09-07 日本電気株式会社 通信装置、方法、プログラム、及び記録媒体
CN110290563A (zh) * 2019-05-28 2019-09-27 菜鸟智能物流控股有限公司 无线接入切换方法、装置和系统以及电子设备
WO2021149233A1 (ja) * 2020-01-23 2021-07-29 日本電信電話株式会社 分離システム、分離方法および分離プログラム
WO2022112646A1 (en) * 2020-11-25 2022-06-02 Nokia Solutions And Networks Oy Method and apparatus for reducing redundancy of internet security

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3251077B2 (ja) * 1992-12-25 2002-01-28 沖電気工業株式会社 アソシエーション管理方法
US6260158B1 (en) * 1998-05-11 2001-07-10 Compaq Computer Corporation System and method for fail-over data transport
JP2001217839A (ja) * 2000-01-31 2001-08-10 Fujitsu Ltd ノード装置
US6826198B2 (en) * 2000-12-18 2004-11-30 Telefonaktiebolaget Lm Ericsson (Publ) Signaling transport protocol extensions for load balancing and server pool support
WO2003105438A1 (en) * 2002-06-07 2003-12-18 Nokia Corporation Method for sending connection-oriented or connectionless data
JP4623918B2 (ja) * 2002-06-26 2011-02-02 日本電気株式会社 移動通信システム並びにその動作制御方法
JP4145821B2 (ja) * 2004-03-17 2008-09-03 松下電器産業株式会社 コネクション管理機能を備えたクライアント、サーバ、システム、コネクション管理方法、及びそのプログラム
JP4153502B2 (ja) * 2005-03-29 2008-09-24 富士通株式会社 通信装置及び論理リンク異常検出方法
JP4725228B2 (ja) * 2005-07-28 2011-07-13 日本電気株式会社 Ponシステム、ロジカルリンク割当方法およびロジカルリンク割当装置
JP4679415B2 (ja) * 2006-04-03 2011-04-27 シャープ株式会社 通信システム及び通信方法
JP4751759B2 (ja) * 2006-04-21 2011-08-17 株式会社エヌ・ティ・ティ・ドコモ 基地局及び通信方法
US7849211B2 (en) * 2006-05-12 2010-12-07 Broadcom Corporation Method and system for reliable multicast datagrams and barriers
US8447349B2 (en) * 2008-02-15 2013-05-21 Motorola Solutions, Inc. Method and apparatus for inter-technology handoff of a multi-mode mobile station

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200004854A (ko) * 2017-05-05 2020-01-14 지티이 코포레이션 통신 방법, 장비, 시스템 및 컴퓨터 저장 매체
KR102277936B1 (ko) * 2017-05-05 2021-07-15 지티이 코포레이션 통신 방법, 장비, 시스템 및 컴퓨터 저장 매체
US11071165B2 (en) 2017-05-05 2021-07-20 Zte Corporation Communication method, equipment, system, and computer storage medium

Also Published As

Publication number Publication date
JP2009200689A (ja) 2009-09-03
EP2093975A1 (en) 2009-08-26
US20090207855A1 (en) 2009-08-20
US8089936B2 (en) 2012-01-03

Similar Documents

Publication Publication Date Title
JP4998316B2 (ja) 通信システム及び通信処理方法並びにノード
US10462229B2 (en) Method and apparatus for initiating and maintaining sessions between endpoints
US8867428B2 (en) Split-cell relay application protocol
US7483995B2 (en) Coordinating a transition of a roaming client between wireless access points using another client in physical proximity
US6691227B1 (en) Location-independent packet routing and secure access in a short-range wireless networking environment
US8272046B2 (en) Network mobility over a multi-path virtual private network
JP5715147B2 (ja) パケットデータ集束プロトコル状態報告の取得方法及びパケットデータ集束プロトコルエンティティ
US20220361072A1 (en) Communication method and apparatus
WO2019185062A1 (zh) 一种通信方法及装置
US20200045612A1 (en) Managing Mobility Between a Cellular Network and a Wireless Local Area Network (WLAN)
WO2020166396A1 (ja) 基地局装置、移動局装置および通信方法
JP5840575B2 (ja) マルチホーム通信方法およびシステム
WO2019056206A1 (en) MULTINUEUD SUPPORT FOR SCTP COMMUNICATIONS
RU2806798C1 (ru) Способ и устройство связи
CA2419865C (en) Providing secure network access for short-range wireless computing devices
Baboescu et al. INTAREA S. Kanugovi Internet-Draft S. Vasudevan Intended status: Standards Track Nokia Expires: January 4, 2018 J. Zhu Intel
CN116888946A (zh) 边缘应用服务器发现的方法和设备
AU2001286799A1 (en) Providing secure network access for short-range wireless computing devices

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100917

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110811

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110823

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111021

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120131

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120330

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: 20120417

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120430

R150 Certificate of patent or registration of utility model

Ref document number: 4998316

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150525

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees