JP5117188B2 - 無線ネットワーク・コントロール - Google Patents

Description

この説明は、無線ネットワーク・コントロールに関する。

ＨＤＲ（Ｈｉｇｈ Ｄａｔａ Ｒａｔｅ）は、新興のモバイル無線アクセス・テクノロジーであり、これによって、パーソナル・ブロードバンド・インターネット・サービスにいつでもどこでもアクセスできるようになる（Ｐ．Ｂｅｎｄｅｒら、「ＣＤＭＡ／ＨＤＲ：Ａ Ｂａｎｄｗｉｄｔｈ−Ｅｆｆｉｃｉｅｎｔ Ｈｉｇｈ−Ｓｐｅｅｄ Ｗｉｒｅｌｅｓｓ Ｄａｔａ Ｓｅｒｖｉｃｅ ｆｏｒ Ｎｏｍａｄｉｃ Ｕｓｅｒｓ」、ＩＥＥＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｇａｚｉｎｅ、２０００年７月、および３ＧＰＰ２、「Ｄｒａｆｔ Ｂａｓｅｌｉｎｅ Ｔｅｘｔ ｆｏｒ １ｘＥＶ−ＤＯ」、2000年8月21日を参照されたい）。Ｑｕａｌｃｏｍｍによって開発されたＨＤＲは、わずか（１Ｘ）１．２５ＭＨｚのスペクトルを使用してセクタあたり最大２．４６Ｍｂｉｔ／ｓの共有されたフォワード・リンクの伝送速度を実現することができるＩＰパケット・データ・サービス用に最適化された無線インターフェースである。ＣＤＭＡ２０００無線アクセス（TIA/EIA/IS-2001、「Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＯＳ）ｆｏｒ ＣＤＭＡ２０００ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｎｔｅｒｆａｃｅｓ」、２０００年５月）、および無線ＩＰネットワーク・インターフェース（ＴＩＡ／ＥＩＡ／ＴＳＢ−１１５、「Ｗｉｒｅｌｅｓｓ ＩＰ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｂａｓｅｄ ｏｎ ＩＥＴＦ Ｐｒｏｔｏｃｏｌｓ」、２０００年６月６日、およびＴＩＡ／ＥＩＡ／ＩＳ−８３５、「Ｗｉｒｅｌｅｓｓ ＩＰ Ｎｅｔｗｏｒｋ Ｓｔａｎｄａｒｄ」、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２（３ＧＰＰ２）、Ｖｅｒｓｉｏｎ １．０、２０００年７月１４日）と互換性があるため、ＨＤＲネットワークは、モバイルＡＴ（Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）からグローバルなインターネットに至るまで、完全にＩＰテクノロジー上で構築することができ、したがってＩＰネットワークの拡張性、冗長性、および低コストを十分に活用することができる。

ＨＤＲは、ＣＤＭＡ２０００ファミリーにおける新しい標準として、すなわち以前はＨＲＰＤ（Ｈｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ）と呼ばれており、１ｘＥＶ−ＤＯまたはＩＳ−８５６としても知られている高速のＤＯ（ｄａｔａ−ｏｎｌｙ）サービス用の現行の１ｘＲＴＴ標準を進化させたものとして、ＴＩＡ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｉｎｄｕｓｔｒｙ Ａｓｓｏｃｉａｔｉｏｎ）によって採用されている。

ＩＳ−８５６のシステムは通常、図１に示されている無線アクセス・ネットワーク・アーキテクチャを使用して実装される。ここでは、ＡＴ（Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）１０は、ＩＳ−８５６のサポートを内蔵したラップトップ・コンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、デュアルモードのボイス／データ・ハンドセット、または別のデバイスとすることができる。

無線アクセス・プロバイダの管理サービス・エリアの全体は、１つまたは複数のサブネットワーク（すなわちサブネット）１２、１４へと分割することができる。それぞれのサブネット１２は、１組のＲＮ（Ｒａｄｉｏ Ｎｏｄｅ）１６、１８と、１つまたは複数のＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）２０、２２とを含む。ＲＮは、帰路ネットワーク２４を介してＲＮＣに接続される。既存の２Ｇおよび３Ｇ無線ネットワークにおいては、それぞれのＲＮは、専用回線またはＡＴＭ ＰＶＣ（ｐｅｒｍａｎｅｎｔ ｖｉｒｔｕａｌ ｃｉｒｃｕｉｔ）を使用して、１つのＲＮＣのみに接続される。さらにＲＮＣは、専用回線またはＡＴＭ ＰＶＣを使用して、相互に接続される。新しい世代のＩＰベースの無線アクセス・ネットワークにおいては、ＲＮとＲＮＣの間で多対多の接続をサポートする共有されたＩＰまたは大都市のイーサネット（登録商標）・ネットワークを使用して、帰路を実装することができる。

それぞれのＲＮＣは通常、２５〜１００個のＲＮをコントロールする。それぞれのＲＮは通常、それぞれ１．２５ＭＨｚの帯域幅の１〜４個の搬送波をサポートする。さらに、それぞれのセル・エリア（図示せず）は通常、複数のセクタ（通常は３つまたは６つ）へと分割され、ＲＮは、それぞれのセクタごとに１つの無線トランシーバ２７を有する。

それぞれのＲＮＣは、ＩＰネットワーク２６を介して１つまたは複数のＰＤＳＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｓｅｒｖｉｎｇ Ｎｏｄｅ）２８に接続される（前述のＴＩＡの参考文献を参照されたい）。ＲＮＣは、Ｒ−Ｐ（Ｒａｄｉｏ−Ｐａｃｋｅｔ）インターフェース３０と呼ばれる標準的なインターフェースを介してＰＤＳＮと通信する。Ｒ−Ｐインターフェースは、データを搬送するために使用されるＡ１０インターフェース、および信号を搬送するために使用されるＡ１１インターフェースという２つのインターフェースへとさらに分けられる。ＰＤＳＮは、モビリティをサポートするエッジ・ルータとみなすことができ、アクセス・ネットワークを通じてＡＴへのリンク層の接続を維持する。ＰＤＳＮは、ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ，Ａｕｔｈｏｒｉｚａｔｉｏｎ，ａｎｄ Ａｃｃｏｕｎｔｉｎｇ）のためのＡＡＡサーバ３２へのインターフェースの役割も果たす。

ＡＴは、ネットワークに接続すると、ＲＮＣとのセッションを確立し、ＲＮＣからリンク層アドレスを受信する。このセッションは、ＲＮＣがＡＴにサービスを提供するために必要とするすべての情報を表す。現在３ＧＰＰ２によって１ｘＥＶ−ＤＯ ＩＯＳ Ｐｈａｓｅ １（ＩＳ−８７８）において定義されているようなＩＳ−８５６の無線アクセス・ネットワークにおいては、それぞれのＲＮは、１つのＲＮＣに一意に関連付けられ、それぞれのサブネットは、ＲＮＣを１つしか含まない。結果として、あるＡＴが、あるＲＮＣのサービス・エリアから別のＲＮＣのサービス・エリアへ移動した場合には、そのＡＴはハンドオフを実行し、これには、セッションの転送が含まれる。

休眠中のＡＴは、サブネットの境界を越えるたびに、ＵＡＴＩ＿Ｒｅｑｕｅｓｔを送信することによって、休眠中のハンドオフを開始する。ＡＴは、セクタによって放送されている１２８−ビットのＳｅｃｔｏｒＩＤをモニタすることによって、休眠中のハンドオフの必要性を認識する。同じサブネットに属するすべてのセクタは、一定の範囲内に収まるＳｅｃｔｏｒＩＤを有する。所与のサブネット内で１つのＡＴに割り当てられる１２８−ビットのＵＡＴＩ（Ｕｎｉｖｅｒｓａｌ Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ Ｉｄｅｎｔｉｆｉｅｒ）は、同じ範囲内に収まる。ＡＴは、別のサブネットのサービス・エリアへと移動した場合には、自分のＵＡＴＩと、そのサービス提供中のセクタによって放送されているＳｅｃｔｏｒＩＤとを比較する。これらが同じ範囲に属していない場合には、ＡＴは、自分がサブネットの境界を越えたことを知り、ＵＡＴＩ＿Ｒｅｑｕｅｓｔを送信することによって、休眠中のハンドオフを開始する。
Ｐ．Ｂｅｎｄｅｒら、「ＣＤＭＡ／ＨＤＲ：Ａ Ｂａｎｄｗｉｄｔｈ−Ｅｆｆｉｃｉｅｎｔ Ｈｉｇｈ−Ｓｐｅｅｄ Ｗｉｒｅｌｅｓｓ Ｄａｔａ Ｓｅｒｖｉｃｅ ｆｏｒ Ｎｏｍａｄｉｃ Ｕｓｅｒｓ」、ＩＥＥＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｇａｚｉｎｅ、２０００年７月 ３ＧＰＰ２、「Ｄｒａｆｔ Ｂａｓｅｌｉｎｅ Ｔｅｘｔ ｆｏｒ １ｘＥＶ−ＤＯ」、２０００年８月２１日 ＴＩＡ／ＥＩＡ／ＩＳ−２００１、「Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＯＳ）ｆｏｒ ＣＤＭＡ２０００ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｎｔｅｒｆａｃｅｓ」、２０００年５月 ＴＩＡ／ＥＩＡ／ＴＳＢ−１１５、「Ｗｉｒｅｌｅｓｓ ＩＰ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｂａｓｅｄ ｏｎ ＩＥＴＦ Ｐｒｏｔｏｃｏｌｓ」、２０００年６月６日 ＴＩＡ／ＥＩＡ／ＩＳ−８３５、「Ｗｉｒｅｌｅｓｓ ＩＰ Ｎｅｔｗｏｒｋ Ｓｔａｎｄａｒｄ」、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２（３ＧＰＰ２）、Ｖｅｒｓｉｏｎ １．０、２０００年７月１４日

休眠中のハンドオフの第１の目的は、そのＡＴ用に着信するパケットを新たなサービス提供側ＲＮＣへ送信するようＰＤＳＮに知らせることである。休眠中のハンドオフには、Ｒ−Ｐ（Ａ１０）セッションを古いサービス提供側ＲＮＣから新たなサービス提供側ＲＮＣへ移転することが含まれる。このようなハンドオフがなければ、ＰＤＳＮは、パケットを古いサービス提供側ＲＮＣへ送信してしまうであろう。古いサービス提供側ＲＮＣは、自分のサブネットの外のＡＴの位置を知らないため、ＡＴのパケットは、失われる可能性がある。

休眠中のハンドオフの第２の目的は、ＲＮＣどうしの間でセッション情報を転送することである。ＩＳ−８５６においては、それぞれのＲＮＣは、ＡＴに関する一定のセッション情報を保持する。このようなセッション情報は、無線インターフェースを介した通信のために必要とされる。セッション情報には、ＵＡＴＩ（Ｕｎｉｖｅｒｓａｌ Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ Ｉｄｅｎｔｉｆｉｅｒ）、アクセス・チャネルの認証および暗号化のためのセキュリティー・キー、ならびにその他のプロトコル定数が含まれる。ＡＴがＲＮＣの境界（この場合は、サブネット）を越えるたびに、新たなＵＡＴＩをそのＡＴに割り当てることが必要となり、残りのセッション情報を古いサービス提供側ＲＮＣから新たなサービス提供側ＲＮＣへ転送することが必要となる。このような転送には、ＲＮＣどうしの間におけるネットワーク・リンクが必要である。このようなセッションの転送がなければ、ＲＮＣどうしの間におけるすべてのハンドオフは、新たに長時間かけてセッションを確立し、貴重な無線リソースを費やし、遅延を引き起こす結果となる。ＲＮＣの電波到達範囲が小さい場合には、休眠中のハンドオフが頻繁に行われ、結果として（新たなＵＡＴＩを割り当てるための）無線リンク・リソースの過剰な使用、ＲＮＣがセッションの転送を実施するための余分な処理、ならびにＲＮＣおよびＰＤＳＮがＡ１０接続を移転するための余分な処理が発生する。

一態様においては、１つの方法が存在する。この方法は、第１および第２の無線ネットワーク・コントローラと、第１および第２の無線ノードとを含むモバイル無線ネットワークに関連して、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程を含む。この方法はまた、第２の無線ノードを介して第２の無線ネットワーク・コントローラ上の第２のモバイル・アクセス端末のための第２のセッションを確立する工程と、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に第１のトラフィック・チャネルを確立する工程とを含む。この方法はまた、第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信する工程を含み、この場合には、第１の複数のパケットは、第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。この方法はまた、第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に第１のトラフィック・チャネルを保持する工程を含み、この場合には、第２の複数のパケットは、別の無線ネットワーク・コントローラを通過することなく第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。この方法はまた、第１のアクセス端末が、第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、第２の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための新たなセッションを確立するか、または第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへＲＮＣ間での休眠中のハンドオフを実行する工程を含む。

別の態様においては、１つの方法が存在する。この方法は、複数のサーバ・カードを有するシャーシベースのハードウェア・プラットフォーム上にそれぞれ実装されている第１および第２の無線ネットワーク・コントローラと、第１および第２の無線ノードとを含むモバイル無線ネットワークに関連して、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程を含む。この方法はまた、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラの間に第１のトラフィック・チャネルを確立する工程と、第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信する工程とを含み、この場合には、第１の複数のパケットは、その他のいかなる無線ネットワーク・コントローラも通過することなく第１の無線ノードと第１の無線ネットワーク・コントローラの間を移動する。この方法はまた、第２のモバイル・アクセス端末と第２の無線ネットワーク・コントローラとの間に第２のトラフィック・チャネルを確立する工程と、第２のトラフィック・チャネルを介して第２の複数のパケットを送信および受信する工程とを含み、この場合には、第２の複数のパケットは、その他のいかなる無線ネットワーク・コントローラも通過することなく第２の無線ノードと第２の無線ネットワーク・コントローラとの間を移動する。この方法はまた、第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に第１のトラフィック・チャネルを保持する工程であって、第３の複数のパケットが、別の無線ネットワーク・コントローラを通過することなく第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する工程と、第１のモバイル・アクセス端末が第２の無線ノードのサービス・エリアへ移動するときに第１のセッションを保持する工程とを含む。

別の態様においては、情報搬送波内において目に見える形で具体化され、第１および第２の無線ネットワーク・コントローラと、第１および第２の無線ノードとを含むモバイル無線ネットワーク内で機能するように適合されているコンピュータ・プログラム製品が存在する。このコンピュータ・プログラム製品は、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、第２の無線ノードを介して第２の無線ネットワーク・コントローラ上の第２のモバイル・アクセス端末のための第２のセッションを確立する工程とをデータ処理装置に実行させるように機能する命令を含む。このコンピュータ・プログラム製品はまた、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に第１のトラフィック・チャネルを確立する工程と、第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信する工程であって、その第１の複数のパケットが、第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと第１の無線ネットワーク・コントローラの間を移動する工程とをデータ処理装置に実行させるようにさらに機能する命令を含む。このコンピュータ・プログラム製品はまた、第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に第１のトラフィック・チャネルを保持する工程であって、第２の複数のパケットが、別の無線ネットワーク・コントローラを通過することなく第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する工程をデータ処理装置に実行させるようにさらに機能する命令を含む。

別の態様においては、１つのモバイル無線ネットワークが存在する。このモバイル無線ネットワークは、第１の無線ネットワーク・コントローラと、第２の無線ネットワーク・コントローラと、第１の無線ノードと、第２の無線ノードと、第１のモバイル・アクセス端末と、第２のモバイル・アクセス端末とを含む。第１のモバイル・アクセス端末は、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上に確立されている第１のセッションと、第１の無線ネットワーク・コントローラと共に確立されている第１のトラフィック・チャネルとに関連付けられている。第１のモバイル・アクセス端末は、第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信し、その第１の複数のパケットは、第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。第２のモバイル・アクセス端末は、第２の無線ノードを介して第２の無線ネットワーク・コントローラ上に確立されている第２のセッションに関連付けられている。第１のトラフィック・チャネルは、第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に保持される。第２の複数のパケットが、別の無線ネットワーク・コントローラを通過することなく第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。

上述の態様のすべてに関するその他の例は、下記の特徴のうちの１つまたは複数を含むことができる。第１の関連付けは、第２の無線ノードと第２の無線ネットワーク・コントローラとの間において確立することができる。第２の関連付けは、第２の無線ノードと第１の無線ネットワーク・コントローラとの間において確立することができる。第１の関連付けを確立する工程は、ＰＮオフセットおよびＩＰアドレスの情報を第２の無線ノードから第２の無線ネットワーク・コントローラに渡す工程を含むことができる。第２の関連付けを確立する工程は、ＰＮオフセットおよびＩＰアドレスの情報を第２の無線ノードから第１の無線ネットワーク・コントローラに渡す工程を含むことができる。第１の無線ノードは、第１のサブネット識別子を放送することができる。第２の無線ノードは、第１のサブネット識別子とは異なる第２のサブネット識別子を放送することができる。それぞれの無線ノードは、そのそれぞれのサブネット識別子と共に個々に構成することができる。これらの無線ノードは、自分が第１の関連付けを確立している自分のそれぞれの無線ネットワーク・コントローラから自分のサブネット識別子をそれぞれ得ることができる。

第１のアクセス端末は、休眠中の状態にある間にサブネット識別子をモニタし、そのサブネット識別子における変化を検知すると、新たなセッションの確立、または第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへの休眠中のＲＮＣ間でのハンドオフを引き起こすことができる。第１のアクセス端末は、ＵＡＴＩ Ｒｅｑｕｅｓｔメッセージを送信することによって、新たなセッションの確立、または第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへの休眠中のＲＮＣ間でのハンドオフを引き起こすことができる。

第１の関連付けは、第３の無線ノードと第１の無線ネットワーク・コントローラの間において確立することができる。第２の関連付けは、第３の無線ノードと第２の無線ネットワーク・コントローラの間において確立することができる。第３の無線ノードは、第１および第２の無線ノードに関連付けられている第１および第２のサブネット識別子とは異なる第３のサブネット識別子を放送することができる。第１の無線ネットワーク・コントローラは、第１のアクセス端末が、第１の無線ノードのサービス・エリアから第３の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、新たなＵＡＴＩを第１のアクセス端末に割り当てることができる。１つまたは複数の無線ネットワーク・コントローラによってサービスを提供されているセッションに関するセッション情報を保存するためのＲＮＣリソース・コントロール・エージェントを採用することができる。ＲＮＣリソース・コントロール・エージェントは、無線ネットワーク・コントローラの障害を検知することができ、無線ネットワーク・コントローラの障害を検知すると、ユーザ・セッションを残りの無線ネットワーク・コントローラに割り当て直し、セッション情報をこれらの残りの無線ネットワーク・コントローラに渡す。セッションを閉じるためのメッセージを送信するために第１のアクセス端末に関する十分な情報を新たな無線ネットワーク・コントローラに提供する部分的なセッション情報を渡すことができる。

複数のサーバ・カードを有するシャーシベースのハードウェア・プラットフォームを採用して、無線ネットワーク・コントローラのそれぞれを実装することができる。第１の無線ネットワーク・コントローラ上のサーバ・カードのうちの１つを本拠とすることによって、第２の無線ノードと第１の無線ネットワーク・コントローラの間に関連付けを確立することができる。第２の無線ネットワーク・コントローラ上のサーバ・カードのうちの１つを本拠とすることによって、第２の無線ノードと第２の無線ネットワーク・コントローラの間に関連付けを確立することができる。それぞれの無線ノードと、無線ネットワーク・コントローラ内でそれぞれの無線ノードが本拠とされているサーバ・カードとの間で信号を伝達するために、ＴＣＰやＳＣＴＰなどのトランスポート層接続を確立することができる。関連付けを確立する工程は、第２の無線ノードから、その第２の無線ノードが本拠とされているサーバ・カードへＰＮオフセット情報を渡す工程を含むことができる。ＰＮオフセット情報は、そのＰＮオフセット情報を受信しているサーバ・カードからシャーシベースのハードウェア・プラットフォーム内のその他のサーバ・カードへ配信することができる。ＲＮＣ間でのハンドオフの手続きは、１ｘＥＶ−ＤＯ ＩＯＳ仕様のＡ１３インターフェースに準拠することができる。

アクセス・チャネル・パケットは、第１および第２のアクセス端末に関連付けられているセッション識別子に基づいて第１および第２の無線ノードにおいて経路指定することができる。第１のアクセス端末に関連付けられているセッション識別子は、１ｘＥＶ−ＤＯ標準に基づくＡＴＩ（ａｃｃｅｓｓ ｔｅｒｍｉｎａｌ ｉｄｅｎｔｉｆｉｅｒ）に基づくことができる。第２のアクセス端末に関連付けられているセッション識別子は、ｃｄｍａ２０００標準に基づくＴＭＳＩ（ｔｅｍｐｏｒａｒｙ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ）に基づくことができる。無線ネットワーク・コントローラは、ＰＤＳＮ機能を含むことができる。第１のアクセス端末が、第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、第２の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための新たなセッションを確立することができ、または第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへＲＮＣ間での休眠中のハンドオフを実行することができる。第１の無線ネットワーク・コントローラおよび第１の無線ノードは、同一の場所に配置することができる。第２の無線ネットワーク・コントローラおよび第２の無線ノードは、同一の場所に配置することができる。

一態様においては、本発明は、無線ネットワーク内でモバイル・アクセス端末を使用してデジタル情報をやり取りする方法を特徴とする。この方法は、第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードを介して、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に確立された第１のトラフィック・チャネルを介してパケットを送信する工程と、第１の無線ネットワーク・コントローラを通過することなく第２の無線ノードを介して、第２のモバイル・アクセス端末と第２の無線ネットワーク・コントローラとの間に確立された第２のトラフィック・チャネルを介してパケットを送信する工程とを含む。この方法はまた、第２の無線ノードを介して第１のアクセス端末との間でパケットが受信または送信される場合に、第１のアクセス端末と第１の無線ネットワーク・コントローラとの間における第１のトラフィック・チャネルを保持する。この方法はまた、第１のアクセス端末から受信したパケットを外部のネットワーク（たとえばインターネット）へ送信する工程を含む。

実装形態は、下記の特徴のうちの１つまたは複数を含むことができる。この方法はまた、第１のアクセス端末が第３の無線ノードの付近にあることを検知すると、第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへ第１のトラフィック・チャネルのアクティブなハンドオフを実行する工程を含むことができる。この方法はまた、第１のアクセス端末が第３の無線ノードの付近にあることを検知すると、第１の無線ネットワーク・コントローラによって第１のトラフィック・チャネルを閉じる工程を含むことができる。

この方法はまた、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第３のモバイル・アクセス端末のための第１のセッションを確立する工程と、アクセス端末によって送信される位置更新メッセージに基づいて第３のアクセス端末の大まかな位置を追跡把握する工程と、第３のアクセス端末が休眠中の状態にある間に、第１の無線ネットワーク・コントローラにおいて第３のアクセス端末のためのパケットを受信する工程と、第２の無線コントローラが第３のアクセス端末を呼び出すことを要求するメッセージを第２の無線コントローラへ送信する工程と、第３の無線ノードを介して第２の無線ネットワーク・コントローラからアクセス端末を呼び出す工程とを含むことができる。この方法はまた、第３の無線ノードにおいて、アクセス・チャネルを介して第３のモバイル・アクセス端末からトラフィック・チャネル要求メッセージを受信する工程と、第３の無線ノードから第２の無線ネットワーク・コントローラへトラフィック・チャネル要求メッセージを転送する工程と、第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへの第１のセッションのハンドオフを実行する工程と、ハンドオフが完了した後に、第２の無線ネットワーク・コントローラと第３のアクセス端末との間にトラフィック・チャネルを確立する工程とを含むことができる。

無線ネットワーク・コントローラ（たとえば、第１の無線ネットワーク・コントローラ）は、複数のサーバ・カードを含むことができ、この方法はまた、複数のサーバ・カードから選択されたサーバ・カードのうちの１つの上で無線ネットワーク・コントローラと第１のモバイル・アクセス端末との間に第１のトラフィック・チャネルを確立する工程と、その選択されたサーバ・カードのアドレスを無線ネットワーク・コントローラから第１の無線ノードへ送信する工程と、リバース・リンクのトラフィック・チャネル・パケットを第１の無線ノードからその選択されたサーバ・カードのアドレスへ送信する工程と、その選択されたサーバ・カードのアドレスを第１の無線ネットワーク・コントローラから第２の無線ノードへ送信する工程と、リバース・リンクのトラフィック・チャネル・パケットを第２の無線ノードからその選択されたサーバ・カードのアドレスへ送信する工程とを含むことができる。

第１の無線ノードは、第１の周波数チャネル上で機能するように構成することができ、その一方で第２の無線ノードは、第１の無線ノードと同一の場所に配置して、第２の周波数チャネル上で機能するように構成することができる。この方法はまた、第１の周波数チャネル上で機能する第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、第２の周波数チャネル上で機能する第２の無線ノードを介して第２の無線ネットワーク・コントローラ上の第２のモバイル・アクセス端末のための第２のセッションを確立する工程と、第２の周波数チャネル上で機能する第２の無線ノードを介して第１の無線ネットワーク・コントローラ上の第３のモバイル・アクセス端末のための第３のセッションを確立する工程とを含むことができる。

この方法はまた、第１の周波数チャネル上で機能する第１の無線ノードと第１の無線ネットワーク・コントローラとの間における第１の関連付けを確立する工程と、第２の周波数チャネル上で機能する第２の無線ノードと第１の無線ネットワーク・コントローラとの間における第２の関連付けを確立する工程と、第１の周波数チャネル上で機能する第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、アクセス端末が、休眠中のモードにある第２の無線ノードのモニタリングを開始した場合は常に、第１のセッションを第２の無線ネットワーク・コントローラへ転送する工程とを含むことができる。

この方法はまた、第１の周波数チャネル上で機能する第１の無線ノードを介して第１の無線ネットワーク・コントローラにおいて第１のモバイル・アクセス端末からの接続要求を受信する工程と、第１の無線ネットワーク・コントローラ上の第１のアクセス端末のための第３のトラフィック・チャネルを確立する工程であって、そのトラフィック・チャネルが、第２の周波数チャネル上で機能する第２の無線ノードを介して流れる工程とを含むことができる。

この方法はまた、第１の無線ネットワーク・コントローラによって第１および第２の無線ノードから受信される実際の負荷の情報に基づいて第２の周波数チャネル上で機能する第２の無線ノードを介して流れる第３のトラフィック・チャネルを確立する工程を含むことができる。この方法はまた、第１および第２の無線ノード上の負荷の見積もりに基づいて第２の周波数チャネル上で機能する第２の無線ノードを介して流れる第３のトラフィック・チャネルを確立する工程をさらに含むことができる。

第１および第２の無線ネットワーク・コントローラは、それぞれ複数のサーバ・カードを含むことができ、この方法は、第１の無線ネットワーク・コントローラ内の第１のサーバ・カード上の複数のトラフィック・チャネルを処理する工程と、第１のサーバ・カードにおける過負荷の状況を検知する工程と、別のサーバ・カードへ転送するために、第１のサーバ・カード上でサービスを提供されているトラフィック・チャネルを選択する工程と、そのトラフィック・チャネルを中断することなく、その選択されたトラフィック・チャネルを無線ネットワーク・コントローラのうちの１つの中の別のサーバ・カードへ転送する工程とをさらに含むことができる。

転送するためにトラフィック・チャネルを選択する工程は、選択されたトラフィック・チャネルによって使用されている処理中のリソースの量に、および／または複数のトラフィック・チャネル上のトラフィックのサービスの質の要件に少なくとも部分的に基づくことができる。無線ネットワーク・コントローラ内のその他のカードの負荷および利用可能度に少なくとも部分的に基づいて、選択されたトラフィック・チャネルの転送先となるターゲット・サーバ・カードを決定する。ターゲット・サーバ・カードは、第１のサーバ・カードと同じ無線ネットワーク・コントローラ内に配置することもでき、あるいは第１のサーバ・カードとは異なる無線ネットワーク・コントローラ内に配置することもできる。

１つまたは複数の無線ネットワーク・コントローラ内におけるサーバ・カードの負荷に関する情報は、中央集権化されたロード・トラッカーによって提供することができ、このロード・トラッカーは、無線ネットワーク・コントローラ内に配置されているか、またはすべての無線ネットワーク・コントローラに対して外部にある。中央集権化されたロード・トラッカーは、第１のサーバ・カードからターゲット・サーバ・カードへのトラフィック・チャネルの転送を引き起こすように構成することができる。いくつかの実装形態においては、負荷の情報は、１つのサーバ・カードによって直接その他のサーバ・カードから得ることができる。

この方法はまた、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌネットワークを使用して、第１の無線ネットワーク・コントローラと第１および第２の無線ノードとの間でデータ・パケットをやり取りする工程を含むことができる。

別の態様においては、本発明は、モバイル・アクセス端末と無線通信するための無線アクセス・ネットワークを特徴とし、この無線アクセス・ネットワークは、ネットワーク（たとえばＩＰネットワーク）を使用して複数の無線ネットワーク・コントローラと相互接続されている複数の無線ノードであって、それぞれの前記無線ノードが、それぞれの前記無線ネットワーク・コントローラをアドレス指定することができ、それぞれの前記無線ネットワーク・コントローラが、それぞれの前記無線ノードをアドレス指定することができる複数の無線ノードと、無線アクセス・ネットワークと外部のネットワークとの間でパケットをやり取りするためのインターフェースとを含む。

実装形態は、下記の特徴のうちの１つまたは複数を含むことができる。無線ノードおよび無線ネットワーク・コントローラは、共通のサブネットワークに関連付けることができる。それぞれの無線ネットワーク・コントローラは、トラフィック・チャネルがどの無線ノードを流れているかにかかわらず、そのトラフィック・チャネルを保持するように構成することができる。無線ネットワーク・コントローラは、無線ノードのうちのいずれか１つを介してアクセス端末との間でパケットを経路指定することによって、トラフィック・チャネルを保持することができる。それぞれの無線ノードは、複数の無線ネットワーク・コントローラから選択された第１の無線ネットワーク・コントローラに関連付けることができ、それらの無線ネットワーク・コントローラのそれぞれは、無線ノードのうちのいずれかを介して呼び出しメッセージをアクセス端末へ送信することを可能にすることができる。

それぞれの無線ネットワーク・コントローラは、複数のサーバ・カードを含むことができ、それらの複数のサーバ・カードは、それぞれネットワークに接続されており、無線ノードのそれぞれによってアドレス指定することができる。無線ネットワーク・コントローラは、複数のサーバ・カードのそれぞれの上でアクセス端末とのトラフィック・チャネルを確立するように構成することができる。無線ネットワーク・コントローラは、１つまたは複数の無線ノードへのトラフィック・チャネルが確立されているサーバ・カードのアドレスを提供するように構成することもできる。それぞれの無線ネットワーク・コントローラは、自分の複数のサーバ・カードのうちの１つにおける過負荷の状況を検知して、別のカードへ転送するために、過負荷になっているカードによって処理されている１つまたは複数のトラフィック・チャネルを選択するように構成することもできる。

複数の無線ノードは、同一の場所に配置されている２つの無線ノードを含むことができ、第１の無線ノードは、第１の周波数チャネル上で機能するように構成されており、第２の無線ノードは、第２の周波数チャネル上で機能するように構成されている。

インターフェースは、パケット・データ・スイッチング・ノードとすることもでき、あるいは無線ネットワーク・コントローラのうちの１つの一部とすることもできる。

実装形態は、下記の利点のうちの１つまたは複数を実現することができる。すべての無線ノードとすべての無線ノード・コントローラとの間に第１または第２の関連付けを確立することによって、無線ノード・コントローラは、アクセス端末が１つの無線ノードのサービス・エリアから別の無線ノードのサービス・エリアへ移動する際に、ＩＰの帰路上の任意の無線ノードを見つけて通信するのに必要な情報を有する。これによって無線ネットワークは、アクセス端末が、その時点で自分にサービスを提供しているＲＮＣとは異なる第１のＲＮＣを有する無線ノードのサービス・エリア内へ移動した場合でさえ、通常のソフト・ハンドオフを実行することができる。これによって、エラーが発生しやすく、さらなる待ち時間がもたらされることで知られている、より伝統的なＲＮＣ間でのハンドオフの手続きが回避される。本発明の一実装形態は、上述の利点のすべてを提供する。

ＩＳ−８５６に関して前述したものを含む既存の３Ｇ無線ネットワーク・アーキテクチャは、ＲＮとＲＮＣとの間における固定された関係を前提としている。すなわち、１つのＲＮから、または１つのＲＮへと流れるすべてのトラフィックは、同じＲＮＣを経由する。これは、ＲＮＣどうしの間における休眠中のハンドオフを処理するために複雑な階層構造を必要とし、頻繁で遅延しやすいＲＮＣ間での（ソフト）ハンドオフを必要とする。図１および図２に示されているように、ＲＮとＲＮＣとの間における帰路接続のためにポイントツーポイントの専用回線が使用されている場合には、回線交換方式の音声用途において、ＲＮとＲＮＣとの間における固定された関連付けが必要とされる。

以降の例においては、ＲＮＣは、ＩＰネットワークに直接接続されている無線ネットワーク・コントローラを表している。直接接続されているということは、ＲＮＣが、ＩＰ層の上でいかなる中間処理も伴わずにＩＰネットワーク内のその他のノードとの間でＩＰパケットを送信／受信することができるということを意味している。ＲＮＣは、シャーシベースのハードウェア・プラットフォーム上に実装することができ、このシャーシベースのハードウェア・プラットフォームは、複数のサーバ・カードから構成することができる。この場合には、シャーシ全体は、ＩＰネットワークに直接接続されているＲＮＣとみなすことができ、個々のサーバ・カードは、ＩＰネットワーク内のその他のノードとの間でＩＰパケットを送信／受信するようにＩＰ層の上で機能する中間ノード（またはＩ／Ｏサーバ・カード）を必要とする。ある代替実装形態においては、シャーシベースのハードウェア・プラットフォーム内の個々のサーバ・カードは、ＩＰネットワークに直接接続することができる。この場合には、これらのサーバ・カードは、個々のＩＰアドレスを有することができ、そしてそれらは、それぞれＲＮＣとみなすことができる。ＲＮＣは、従来の計算サーバやブレード・サーバなど、スタンドアロンのサーバ・ハードウェア上に実装することもできる。この場合には、サーバは、ＲＮＣとみなすことができ、無線アクセス・ネットワーク内のその他のＲＮおよびＲＮＣにとって明らかなＩＰアドレスを有する。

ＲＮＣ間での信号伝達を伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャ
はじめに、図３に示されているように、１組のＲＮＣ ６０が同一のデータ・センタ内に配置されており、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標） ＬＡＮなどの高速ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）６２を介して共に接続されている場合について考察する。この場合には、ＲＮＣは、ＬＡＮインターフェースを介してネットワークに接続され、ルータ６４は、外部のネットワークへの接続を提供する。このような構成は、ＲＮＣクラスタ（またはプール）と呼ぶことができる（以降の記述は、大都市エリアのネットワークなど、より一般的なＩＰネットワークを介して接続されるＲＮＣへ同じコンセプトをいかに拡張することができるかについて説明する）。かつて、無線ネットワークを通じて搬送される主なトラフィック・タイプが回線交換方式の音声であった時代には、イーサネット（登録商標）ＬＡＮを使用したこのようなクラスタリングは、実現可能ではなかった。ＲＮは、専用回線６６を使用してデータ・センタ内のルータへ接続することができる。ＲＮおよびＲＮＣは、すべてＩＰアドレスの指定が可能であると想定される。すなわち、クラスタによってサービスを提供されるいかなるＲＮも、そのクラスタ内のその他のＲＮＣのいずれともＩＰレベルにおいて直接通信することができる。

上述のものなどのＲＮＣクラスタにおいては、個々のＲＮＣどうしの間におけるいかなるハンドオフ境界も回避することが重要であり、それによってクラスタ全体は、まるでそのクラスタが１つの大きなＲＮＣであるかのように機能することができる。これによって、モビリティに起因する不要なハンドオフがなくなり、それによって、拡張性および信頼性が大幅に改善されることになる。

これを達成するためには、たとえば１つの例においては、ＩＳ−８５６サブネット７０は、１つのＲＮＣのみの電波到達範囲ではなく、ＲＮＣクラスタの電波到達範囲の全体であると定義される。すなわち、クラスタによってサービスを提供されるすべてのＲＮは、同じサブネットに属することになる。システムのオペレーションを単純化するために、サブネット内のそれぞれのＲＮは、クラスタ内の１つのＲＮＣに関連付けられる（たとえば、第１の関連付け）。この関連付けは、ＲＮが最初に電源を投入されたときに確立される。この関連付けの詳細な意味については、後ほど説明する。

アクセス・チャネル・パケットの経路指定
１つのＲＮ内のそれぞれのセクタは、フォワード・トラフィックまたはコントロール・チャネル７２を介してＡＴへの送信を行うことができる。同様に、１つのＲＮ内のそれぞれのセクタは、リバース・トラフィックまたはアクセス・チャネル７４を介してＡＴからの受信を行うことができる。アクセス・チャネルとリバース・トラフィック・チャネルは、Ｌｏｎｇ Ｃｏｄｅ Ｍａｓｋを使用した符号分割多重化によって切り離されており、その一方でコントロール・チャネルとフォワード・トラフィック・チャネルは、プリアンブルを使用した時分割多重化によって切り離されている。プリアンブルは、フォワード・リンクの物理層パケットをコントロール・チャネル・パケットとして、または特定のＭＡＣ Ｉｎｄｅｘに関連付けられているトラフィック・チャネル・パケットとして識別する。０〜６３の整数であるＭＡＣ Ｉｎｄｅｘは、１つのセクタ内で一意であり、トラフィック・チャネルが確立された時点でＲＮおよびＲＮＣによって割り当てられる。同様に、Ｌｏｎｇ Ｃｏｄｅ Ｍａｓｋは、リバース・リンクの物理層パケットをアクセス・チャネル・パケットとして、または特定のトラフィック・チャネル・パケットとして識別する。Ｌｏｎｇ Ｃｏｄｅ Ｍａｓｋは、トラフィック・チャネルに関してはＡＴのＵＡＴＩに基づき、アクセス・チャネルに関してはサービス提供中のセクタのＳｅｃｔｏｒＩＤに基づく。アクセス・チャネル・パケットの送信側ＡＴ、およびコントロール・チャネル・パケットの受信側ＡＴは、ＭＡＣ ＬａｙｅｒヘッダのＡＴＩフィールド内に示されている。

ＲＮは、そのアクセス・チャネルの１つの上でＭＡＣ Ｌａｙｅｒパケットを受信した場合は常に、そのパケットを、その中身を見ることさえせずに、そのＲＮが関連付けられているクラスタ内のその第１の（すなわちＤｅｆａｕｌｔの）ＲＮＣへ転送する。そのようなものとして、ＵＡＴＩ＿Ｒｅｑｕｅｓｔメッセージを搬送しているパケットがＡＴから受信されると、そのパケットは、受信側ＲＮによって第１のＲＮＣへ転送される。そのＲＮは、ＭＡＣ Ｌａｙｅｒパケットを、（場合によっては、その他のＡＴのＭＡＣ Ｌａｙｅｒパケットと共に多重化して）サービス提供側ＲＮＣのＩＰアドレスに相当する送信先のＩＰアドレスと共に１つのＩＰパケット内にカプセル化する。そのＩＰパケットは、帰路ネットワークを介してデータ・センタの集約ルータへ搬送され、このルータは、そのパケットを、イーサネット（登録商標）ＬＡＮを介してサービス提供側ＲＮＣへ転送する。

すべてのアクセス・チャネル・パケットには、送信側ＡＴを識別する１つのアドレス・フィールドが含まれる。送信側ＡＴが、ＲＮＣによって既にＵＡＴＩを割り当てられている場合には、アドレス・フィールドには、そのＵＡＴＩが含まれる。送信側ＡＴが、まだＵＡＴＩを有していない場合には、アドレス・フィールドには、ＲＡＴＩ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ Ｉｄｅｎｔｉｆｉｅｒ）が含まれ、これは、そのＡＴによって無作為に選択される。アドレス・フィールドの最初の２ビットは、そのアドレスがＵＡＴＩであるか、またはＲＡＴＩであるかを示している。

あるＲＮＣの（イーサネット（登録商標））Ｉ／Ｏサブシステムが、ＲＡＴＩまたは認識されていないＵＡＴＩを含むアドレス・フィールドを有するＡＴからのＵＡＴＩ＿Ｒｅｑｕｅｓｔメッセージを受信した場合には、そのＲＮＣは、セッションを処理するサービス提供側ＲＮＣの役割を担う。そのＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、そのＲＮＣは、そのセッションをそのサーバ・カードのうちの１つに割り当てる。次いでそのＡＴには、何らかの所定の範囲内のＵＡＴＩが割り当てられる。この範囲は、クラスタ内におけるその他のすべてのＲＮＣに対するサービス提供側ＲＮＣを識別し、クラスタ内のすべてのＲＮＣに知られているが、ＡＴには知られていない。そのＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、特定のＲＮＣに属するＵＡＴＩの範囲は、そのセッションを処理しているサービス提供側ＲＮＣ内のサーバ・カードを識別するためにさらに分割することができる。サービス提供側ＲＮＣはまた、ＡＴとＰＤＳＮとの間におけるデータの転送を容易にするためにＰＤＳＮとのＡ１０接続を確立する。Ａ１０接続は、そのセッションを処理しているサーバ・カード上で終了する。

休眠している間、ＡＴは、必要に応じてＲｏｕｔｅＵｐｄａｔｅメッセージを送信して、その現在の位置に関する情報を提供する。このモビリティ情報は、サービス提供側ＲＮＣ内のＭｏｂｉｌｉｔｙ Ｍａｎａｇｅｒにおいて保持される。サブネットは、ＲＮＣクラスタの電波到達範囲の全体をカバーしているため、ＡＴは、同じクラスタ内の２つのＲＮＣの間の境界を越えたときに、サブネットの変化を検知せず、したがって休眠中のハンドオフを開始しない。しかしＡＴが、クラスタ内の別のＲＮＣ（ブローカーＲＮＣ）に関連付けられているＲＮへアクセス・チャネル・メッセージを送信すると、そのメッセージを搬送している（１つまたは複数の）パケットは、そのＲＮによってブローカーＲＮＣへ送信される。ブローカーＲＮＣ内のＩ／Ｏサブシステムは、着信するすべてのアクセス・チャネル・パケットのアドレス・フィールドを検査して、ＵＡＴＩを読み取る。そのＵＡＴＩから、Ｉ／Ｏサブシステムは、テーブルの参照によって、どのサービス提供側ＲＮＣかを割り出し、高速ＬＡＮを介してそのＲＮＣへアクセス・チャネル・パケットを転送する。そのアクセス・チャネル・パケット上のＵＡＴＩが、受信側ＲＮＣによってサービスを提供されたときに、その受信側ＲＮＣは、そのパケットをローカルで処理する。受信側ＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、そのＩ／Ｏサブシステムは、ＵＡＴＩ（セッション）を処理しているサーバ・モジュール（カード）をはじめに割り出し、次いでサービス提供側ＲＮＣの内部バスを使用して、そのカードへパケットを転送する。

呼び出しの経路指定
パケット・データが、休眠中のＡＴ用としてＰＤＳＮから受信された場合には、それらのパケットは、Ａ１０インターフェースを介してサービス提供側ＲＮＣ上の特定のサーバ・カードへ転送される。次いでそのサーバ・カードは、そのＡＴに関する位置情報を検索する。そしてサービス提供側ＲＮＣは、そのＡＴから受信された最新のＲｏｕｔｅＵｐｄａｔｅメッセージに基づいて割り出される１組のＲＮを介して呼び出しメッセージを送信する。この呼び出しメッセージは、そのＲＮＣクラスタに属する１つまたは複数のセクタのコントロール・チャネルを介して送信される。この呼び出しメッセージを送信しているＲＮは、サービス提供側ＲＮＣに関連付けられていない可能性がある（すなわち、別の第１のＲＮＣを有する可能性がある）が、そのクラスタ内のＲＮＣのうちの１つに関連付ける必要がある。

接続（トラフィック・チャネル）の確立
サービス提供側ＲＮＣは、ＡＴから直接、またはブローカーＲＮＣを介してＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを受信すると、そのＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージに添付されているＲｏｕｔｅＵｐｄａｔｅメッセージ内でそのＡＴによって報告されているパイロット強度を検査する。システムのオペレーションを単純化するために、それぞれのＲＮの無線リソースは、そのＲＮが関連付けられているＲＮＣ内のＲａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ機能によって管理されるものと仮定する。さらに、１つのＲＮは、自分が関連付けられているＲＮＣとしか信号をやり取りすることができない。したがって、サービス提供側ＲＮＣは、その他のＲＮＣに関連付けられているＲＮを含むトラフィック・チャネルを確立したい場合には、はじめにそれらのＲＮＣ上のＲａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ機能と直接通信して、リソースが利用可能かどうかをチェックする。このような通信は、高速ＬＡＮを介して行われる（サービス提供側ＲＮＣは、ルックアップ・テーブルを使用して、ＲＮの第１のＲＮＣを割り出すことができる）。十分な無線リソースが利用可能である場合には、サービス提供側ＲＮＣは、ＲＮが関連付けられているＲＮＣを介してこれらのＲＮとの必要なトラフィック・チャネル通信リンクを確立し、ＴｒａｆｆｉｃＣｈａｎｎｅｌＡｓｓｉｇｎｍｅｎｔメッセージをＡＴへ送信して、トラフィック・チャネルのセットアップを開始する。トラフィック・チャネルが確立されると、パケットは、いかなるブローカーＲＮＣのいかなる関与も伴わずにＲＮとサービス提供側ＲＮＣの間で直接流れる。このような直接の経路指定によって、別のＲＮＣを通じた三者間での経路指定を含むソフト・ハンドオフの手続きに典型的に見られる遅延がなくなる。

新たなトラフィック・チャネルが、ＲＮＣクラスタの電波到達範囲の外側（別のサブネット）にあるＲＮを含む場合には、同様の手続きが実施される。この場合には、サービス提供側ＲＮＣは、ＩＰネットワーク（大都市エリアのネットワーク）を介してそのクラスタの外側のＲＮＣと通信して、無線リソースを入手する。無線リソースが利用可能である場合には、サービス提供側ＲＮＣは、これらのＲＮが関連付けられているＲＮＣを介して信号をやり取りすることによって、そのＲＮとの通信リンクを確立する。

この方法によって、サービス提供側ＲＮＣは、そのサービス提供側ＲＮＣとは異なるＲＮＣに関連付けられているＲＮのサービス・エリア内へＡＴが移動した場合でさえ、トラフィック・チャネルを保持することができる。

ＲＮＣ間での信号伝達を伴わない改良されたＩＰベースの無線ネットワーク・アーキテクチャ
ここまで説明したスキームは、２〜３の領域で改良することができる。第１に、経路指定機能をＲＮへ移転することによって、ブローカーＲＮＣを介したアクセス・チャネル・パケットの三者間での経路指定をなくすことができる。これによって、ＲＮにおける処理能力をいくらか増強することと引き換えに、たとえばトラフィック・チャネルのセットアップ中にアクセス・チャネル・パケットを処理する際の遅延が少なくなる。さらに、ＲＮＣどうしの間におけるすべての信号伝達をなくすことができ、その代わりにＲＮＣは、無線アクセス・ネットワーク内のすべてのＲＮと信号を直接やり取りすることができる。これは、展開および保守がさらに容易なより単純なネットワーク・アーキテクチャを作成する上で役に立つ。

Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ機能は、ＲＮＣからＲＮへ移転することもでき、それによって、トラフィック・チャネルのセットアップ手続きにおける遅延がさらに少なくなる。

本明細書に記載のＩＰベースの無線アクセス・ネットワークとその拡張バージョンの双方によって、ＩＰおよび大都市のイーサネット（登録商標）・ネットワークの柔軟性を活用することができ、その結果、より分散されたシステムが形成され、ＡＴは、そのＡＴとサービス提供側ＲＮＣとの間の距離が過大になった場合を除いて、その位置を問わずに、そのサービス提供側ＲＮＣとの接続を保持することができる。これらの機能を提供するために、それぞれのＲＮは、複数のＲＮＣに、場合によってはＩＰベースの無線アクセス・ネットワーク内のすべてのＲＮＣに関連付けることができるが、ここでは、ＲＮＣのうちの１つを第１のＲＮＣとして機能させる必要はない。

アクセス・チャネル・パケットの三者間での経路指定の回避
はじめて電源を入れたときに、ＡＴは、次のようにしてＩＳ−８５６ネットワークへの登録を行う。ＡＴは、近隣のセクタのうちの１つによって放送されているＩＳ−８５６パイロットを入手して、システムと同期化する。セッションの確立を開始するために、ＡＴは、ＵＡＴＩ＿Ｒｅｑｕｅｓｔを送信する。前述のように、ＡＴは、ＭＡＣ Ｌａｙｅｒヘッダ内のＲＡＴＩ（Ｒａｎｄｏｍ ＡＴＩ）を使用して、この要求を送信する。

ＲＮは、アクセス・チャネル・パケットのアドレス・フィールドを検査して、メッセージの送信元が、割り当てられたＵＡＴＩを有していないということを認識し、そのＲＮが関連付けられているその第１のＲＮＣへパケットを転送する。アドレス・フィールドを検査するために、ＲＮはまず、受信したＭＡＣ ＬａｙｅｒパケットからＭＡＣ Ｌａｙｅｒカプセルの断片を抽出して、ＭＡＣ Ｌａｙｅｒカプセルを形成する。次いでＲＮは、ＭＡＣ Ｌａｙｅｒヘッダ内のアドレス・フィールドを読み取る。

ＵＡＴＩ＿Ｒｅｑｕｅｓｔを受信すると、第１のＲＮＣは、サービス提供側ＲＮＣの役割を担い、ＵＡＴＩをＡＴに割り当てる。次いで第１のＲＮＣは、セッション確立の残り、とりわけセキュリティー・キーの交換およびプロトコルの構成を進める（利用可能度を高めるため、およびより良好な負荷バランシングを提供するためのこの手続きの改良されたバージョンについては、以降でさらに詳しく説明する）。ＲＮＣはまた、ＡＴをそのＮＡＩ（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ）に基づいて認証するためのＰＰＰ／ＣＨＡＰ手続きを実施する。ＮＡＩと端末の実際のＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）との間には、１対１の対応付けが存在する。この対応付けは、ＡＡＡ（Ｒａｄｉｕｓ）サーバ（図示せず）内に保持される。ＡＡＡサーバは、ＡＴのＩＭＳＩの値をサービス提供側ＲＮＣに渡す。

サービス提供側ＲＮＣ内のＰＣＦ（ｐａｃｋｅｔ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）機能は、このＩＭＳＩの値を使用して、ＩＳ−２００１の規格に記載されているようにＰＤＳＮを選択し、そのＰＤＳＮへのＡ１０接続を確立する。Ａ１１ Ｒｅｇｉｓｔｒａｔｉｏｎメッセージにおいては、ＰＣＦ機能は、ＡＴのＩＭＳＩの値を、そのＡＴ自身のＳＩＤ／ＮＩＤ／ＰＺＩＤ識別子と共にＰＤＳＮに提供する。次いでＡＴおよびＰＤＳＮは、ＰＰＰリンクをセットアップし、Ｓｉｍｐｌｅ ＩＰまたはＭｏｂｉｌｅ ＩＰのセットアップを行い、ユーザレベルの認証を実行する。

それぞれのＲＮは、ＵＡＴＩとサービス提供側ＲＮＣとの間における対応付けのための経路指定テーブルを保持する。この経路指定テーブルは、ネットワーク管理システムによってＲＮに提供することができる。前のシステムの場合と同様に、それぞれのＲＮＣは、一定の範囲内に収まるＵＡＴＩの値を有する。ＲＮは、Ａｃｃｅｓｓ Ｃｈａｎｎｅｌパケットを受信した場合は常に、ＭＡＣ Ｌａｙｅｒ Ｈｅａｄｅｒ内のＵＡＴＩの値から、どのサービス提供側ＲＮＣかを割り出し、そのサービス提供側ＲＮＣのＩＰアドレスをＩＰヘッダの送信先アドレス・フィールド内に置くことによって、パケットをそのＲＮＣへ経路指定する。したがってアクセス・チャネル・パケットは、いずれのＲＮによっても、直接サービス提供側ＲＮＣへ送達される。それぞれのＲＮＣが有するＵＡＴＩの値の範囲は、そのＲＮＣによってＲＮへ直接伝達することができ、これによって、ＵＡＴＩの範囲を用いて管理システムからＲＮを明示的に構成する必要がなくなる。

上述の方法は、ＲＮが、ＵＡＴＩをＲＮＣのＩＰアドレスに対応付けるためのテーブルを保持することを必要とする。あるいは、ＵＡＴＩのスペースをすべてのＲＮＣの間で分割し、それぞれのＲＮＣに一意のサブスペースを割り当てることもでき、ＲＮＣのＩＰアドレスとＵＡＴＩのサブスペースとの間でアルゴリズム的な関係を確立することができる。次いでＲＮは、いかなるテーブルも使用することなく、ＡＴのＵＡＴＩからアルゴリズム的にＲＮＣのＩＰアドレスを割り出すことができる。

アクセス・チャネル・パケットの経路指定が、中央の要素において、また分散された方法でＲＮにおいての双方で処理される複合型のスキームを有することも可能である。ここでは、場合によっては１つのＲＮＣ内に配置される中央のＵＡＴＩサーバが、ＵＡＴＩおよび関連付けられている新たなセッションをサービス提供側ＲＮＣに割り当てることを担当することができる。新たなセッションを最初に確立したときに、ＲＮＣは、新たなＵＡＴＩを中央のＵＡＴＩサーバに要求することができる。サービス提供側ＲＮＣは、ＵＡＴＩとサービス提供側ＲＮＣの間の結び付きを確立する中央集権化されたＡＣルータに登録することもできる。ＲＮは、はじめてＡＴにサービスを提供しているときに、パケットをＵＡＴＩルータへ転送することができ、次いでそれが、パケットをＵＡＴＩルータへ転送することができる。次いでサービス提供側ＲＮＣは、サービス提供側ＲＮとの結び付きの更新を実行することができ、それによって、その後のすべてのトランザクションにおいて、アクセス・チャネル・パケットを直接サービス提供側ＲＮＣへ送信することができ、三者間での経路指定が回避される。

ＲＮＣ間でのハンドオフの回避
前述のように、所与のＡＴに関するモビリティ管理は、もっぱらサービス提供側ＲＮＣによって処理される。ＡＴは、休眠中モードでは、距離に基づく位置の更新を提供するように構成されている。すなわち、サービス提供中のセクタが、ＲｏｕｔｅＵｐｄａｔｅメッセージを最後に送信したセクタから一定の距離以上離れた場合は常に、ＡＴは、Ａｃｃｅｓｓ Ｃｈａｎｎｅｌを介して、サービス提供中のセクタへ新たなＲｏｕｔｅＵｐｄａｔｅメッセージを送信する。このＲｏｕｔｅＵｐｄａｔｅメッセージは、ＲＮによってサービス提供側ＲＮＣへ転送され、そしてサービス提供側ＲＮＣは、ＡＴの位置を追跡把握する。

サービス提供側ＲＮＣは、ＡＴを呼び出したい場合には、そのＡＴから受信した最新のＲｏｕｔｅＵｐｄａｔｅメッセージ内に示されている時間および位置によって、呼び出しの送信元としたい１つまたは複数のＲＮをはじめに割り出す。ここでは、サービス提供側ＲＮＣが、無線アクセス・ネットワーク内のすべてのＲＮのＩＰアドレスを知っているものと仮定する。このＲＮＣは、ネットワーク管理システムから、または最初の電源投入中にＲＮがそのＲＮＣに関連付けられたときにそれらのＲＮから直接、この情報を入手することができる。サービス提供側ＲＮＣは、呼び出しメッセージをＲＮの適切なセットへ直接送信する。次いでこれらのＲＮは、自分のそれぞれのコントロール・チャネルを介してＡＴを呼び出す。

ＩＳ−８５６ネットワーク内のすべてのセクタは、自分のオーバーヘッド・チャネル内で自分のＳｅｃｔｏｒＩＤおよびＳｕｂｎｅｔ Ｍａｓｋを放送している。比較的小さなネットワークに関しては、Ｓｕｂｎｅｔ Ｍａｓｋをゼロに設定することができ、それによって、ネットワークの全体が１つの大きなサブネットであるということが示される。このシナリオにおいては、ＡＴがサブネットの変化を検知することはない。したがってＡＴは、最初のサービス提供側ＲＮＣへの接続を保持し、休眠中のＲＮＣ間でのハンドオフを引き起こさない。ＰＤＳＮへのＡ１０接続も、ＡＴの位置を問わずに固定されたままとなる。

無線アクセス・ネットワークは、地理的に広いエリアをカバーしている場合には、ＡＴがサービス提供側ＲＮＣからあまりにも遠くへ移動したときに、休眠中のＲＮＣ間でのハンドオフを強行することを自重する可能性がある。これは、サービス提供側ＲＮＣによって、たとえばＡＴからＲｏｕｔｅＵｐｄａｔｅメッセージを受信した際に引き起こされる可能性がある。あるいは、ゼロよりも大きいＳｕｂｎｅｔ Ｍａｓｋを選択して、あまりにも遠く離れたＲＮＣどうしの間にサブネットの境界を導入することもできる。そしてＡＴがサブネットの境界を越えたときに、休眠中のハンドオフが発生し、Ａ１０接続が移転される。さらに、ＡＴには新たなＵＡＴＩが割り当てられ、セッション・パラメータが、古いサービス提供側ＲＮＣから新たなサービス提供側ＲＮＣへ転送される。

分散されたＲａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌを使用したより迅速なトラフィック・チャネルのセットアップ
以降に続くのは、Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ ＣｏｎｔｒｏｌをＲＮＣからＲＮへ移転すること、および無線アクセス・ネットワーク内のすべてのＲＮＣとＲＮとの間で直接の信号リンクを確立することによって、（前のスキームでは）複数のＲＮＣを含んでいたトラフィック・チャネルのためのセットアップ時間がいかに短くなるかに関する説明である。ＡＴが、新たなトラフィック・チャネルを始動するためにアクセス・チャネルを介してＲｏｕｔｅＵｐｄａｔｅメッセージと共にＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを送信する場合は常に、そのメッセージは、受信側ＲＮからサービス提供側ＲＮＣへすぐに転送される。サービス提供側ＲＮＣは、ＲｏｕｔｅＵｐｄａｔｅメッセージを検査して、Ａｃｔｉｖｅ Ｓｅｔ内に含まれる可能性のあるセクタの見込みの高いセットを割り出す。次いでサービス提供側ＲＮＣは、これらのセクタが属するＲＮと直接通信して、トラフィック・チャネルおよび帰路リソースを要求する。これらのＲＮは、拒否するか、または受け入れて、必要とされている無線リソースを割り当てる。リソースがＲＮの十分なセットから利用可能である場合には、サービス提供側ＲＮＣは、トラフィック・チャネルの要求を受け入れて、Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌを介してＴｒａｆｆｉｃＣｈａｎｎｅｌ割り当てメッセージをＡＴへ送信する。次いでＡＴは、ＲＴＣ（Ｒｅｖｅｒｓｅ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）上で送信を開始する。ＲＮがＲＴＣを入手すると、ＲＴＣＡｃｋメッセージがＡＴへ送信されて、ＲＴＣ信号が入手されたことを示す。次いでＡＴは、ＴｒａｆｆｉｃＣｈａｎｎｅｌＣｏｍｐｌｅｔｅメッセージを用いて応答して、Ｔｒａｆｆｉｃチャネルのセットアップが完了したことを示す。

この手続きでは、それぞれのＲＮが、そのＲＮ上で利用可能なハードウェア・リソース、ならびにそのセクタの全体にわたる干渉の管理の双方に関して自分自身の無線リソースをコントロールする。結果として、承認コントロール機能が、ＲＮとサービス提供側ＲＮＣの間で分割される。ＲＮは、自分がコントロールするセクタに関するローカルな承認コントロールを提供し、その一方でサービス提供側ＲＮＣは、グローバルな承認コントロールを提供する。同様に、所与のトラフィック・チャネル内のあるセクタが、しばらくの間非アクティブになった場合には、そのセクタは、そのトラフィック・チャネルを閉じたいという要求をサービス提供側ＲＮＣへ送信することによって、そのトラフィック・チャネルを閉じるための手続きを開始することができる。次いでサービス提供側ＲＮＣは、そのセクタをそのトラフィック・チャネルから外してそのトラフィック・チャネルの全体を閉じるか、または何もしないかに関して全体的な決定を行う。

ＡＴとサービス提供側ＲＮＣの間でトラフィック・チャネルがセットアップされると、そのトラフィック・チャネルは、ＡＴがＩＰベースの無線アクセス・ネットワーク内のその他のＲＮのサービス・エリアへと移動した場合でさえ、そのサービス提供側ＲＮＣに固定されたままとなる。

ＲＮとＲＮＣとの間におけるパケットの経路指定に関するさらなる詳細
ＲＮ内のあるセクタが、リバース・トラフィック・チャネル上でＭＡＣ Ｌａｙｅｒパケットを受信した場合には、そのセクタは、Ｃｏｎｎｅｃｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒを含むＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒを追加してから、そのパケットをＩ／Ｏカードへ転送する。Ｉ／Ｏカードは、Ｃｏｎｎｅｃｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒの値を使用して、サービス提供側ＲＮＣのＩＰアドレスを検索する。次いでＩ／Ｏカードは、ＭＡＣ ＬａｙｅｒパケットをそのＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒと共に１つのＩＰパケット内にカプセル化し、そのＩＰパケットの送信先アドレスは、サービス提供側ＲＮＣのＩＰ Ａｄｄｒｅｓｓに設定される。サービス提供側ＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、そのサービス提供側ＲＮＣ内のＩ／Ｏモジュールは、パケットを受信すると、ＵＡＴＩの値を読み取って、このセッションを処理するサーバ・モジュールを割り出す。次いでＩ／Ｏカードは、さらなる処理のために、そのパケットをＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒと共にそのサーバ・モジュールへ渡す。

ＲＮ内のあるセクタが、アクセス・チャネル上でＭＡＣ Ｌａｙｅｒパケットを受信した場合には、そのセクタは、ＭＡＣ Ｌａｙｅｒ ＨｅａｄｅｒのＡＴＩフィールド内のＵＡＴＩをはじめに読み取り、次いでサービス提供中のセクタのＳｅｃｔｏｒＩＤと共に送信側ＡＴのＵＡＴＩを含むＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒを追加してから、そのパケットをＩ／Ｏカードへ転送する。ＲＮ内のＩ／Ｏカードは、この場合もやはりＵＡＴＩの値を使用して、サービス提供側ＲＮＣのＩＰアドレスを検索する。Ｉ／Ｏカードは、ＭＡＣ ＬａｙｅｒパケットをそのＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒと共に１つのＩＰパケット内にカプセル化し、そのＩＰパケットの送信先アドレスは、サービス提供側ＲＮＣのＩＰ Ａｄｄｒｅｓｓに設定される。そのＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、そのサービス提供側ＲＮＣ内のＩ／Ｏモジュールは、パケットを受信すると、ＵＡＴＩの値を読み取って、このセッションにサービスを提供するサーバ・モジュールを割り出す。次いでＩ／Ｏカードは、さらなる処理のために、そのＭＡＣ ＬａｙｅｒパケットをＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒと共にそのサーバ・モジュールへ渡す。

サービス提供側ＲＮＣは、フォワード・トラフィック・チャネル上で送信する準備の整ったＭＡＣ Ｌａｙｅｒパケットを有している場合には、そのパケットの送信先となるＲＮのＩＰアドレスをはじめに検索する。次いでサービス提供側ＲＮＣは、そのＭＡＣ ＬａｙｅｒパケットをＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒと共に１つのＩＰパケット内にカプセル化し、そのＩＰパケットの送信先アドレスは、ＲＮのＩＰ Ａｄｄｒｅｓｓに設定される。ＲＮは、パケットを受信すると、Ｓｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒ内のＳｅｃｔｏｒＩＤの値を読み取って、そのパケットを送信することになるセクタを割り出す。次いでＲＮは、そのＭＡＣ ＬａｙｅｒパケットをＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒと共に適切なモデム・カードへ渡し、そのモデム・カードは、ＭＡＣ Ｉｎｄｅｘをプリアンブルとして使用してＦｏｒｗａｒｄ Ｌｉｎｋ上で送信するようにＭＡＣ Ｌａｙｅｒパケットをスケジュールする。

同様に、フォワード・リンク上において、サービス提供側ＲＮＣは、特定のセクタのＣｏｎｔｒｏｌ Ｃｈａｎｎｅｌ上で送信する準備の整ったＭＡＣ Ｌａｙｅｒパケットを有している場合には、そのパケットの送信先となるＲＮのＩＰアドレスを割り出す。次いでサービス提供側ＲＮＣは、ＭＡＣ ＬａｙｅｒパケットをそのＳｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒと共に１つのＩＰパケット内にカプセル化し、そのＩＰパケットの送信先アドレスは、ＲＮのＩＰ Ａｄｄｒｅｓｓに設定される。ＲＮは、パケットを受信すると、Ｓｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒ内のＳｅｃｔｏｒＩＤの値を読み取って、そのパケットを送信することになるセクタを割り出す。次いでＲＮは、そのＭＡＣ ＬａｙｅｒパケットをＳｅｃｔｏｒＩＤおよびＭＡＣ Ｉｎｄｅｘと共に適切なモデム・カードへ渡す。そのモデム・カードは、コントロール・チャネル上で送信するようにそのパケットをスケジュールする。

障害回復および負荷バランシング
前述の改良されたＩＰベースの無線アクセス・ネットワーク・アーキテクチャは、無線ネットワークの全体的な信頼性を高めるようにさらに拡張することができる。

セッションの保持を伴わない障害回復
はじめに考察するアプローチでは、それぞれのＲＮは、電源投入時に、まずは第１のＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔと通信し、このＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、ＲＮＣのうちの１つまたは複数の中に存在することができ、あるいは別個の計算エンジンまたはサーバ上に存在することもできる。第１のＲｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、それぞれのＲＮをＰｒｉｍａｒｙ ＲＮＣに割り当てる。次いでＲＮは、すべての新たなセッションの要求をそのＰｒｉｍａｒｙ ＲＮＣへ経路指定する。

あるＲＮＣが、何らかの障害によって完全に連絡不可能になった場合には、そのＲＮＣによってサービスを提供されているすべてのＡＴは、自分たちのＩＳ−８５６セッションが失われたことを最終的に認識することになる。これらのＡＴのそれぞれは、Ａｃｃｅｓｓ Ｃｈａｎｎｅｌを介してＵＡＴＩ＿Ｒｅｑｕｅｓｔを送信することによって、新たなセッションを開始する。これらの要求のうちの１つを受信するすべてのＲＮは、それらの要求を自分の第１のＲＮＣへ経路指定する。任意の時点において、ＲＮが自分の第１のＲＮＣに連絡できない場合には、そのＲＮは、新たな第１のＲＮＣを第１のＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔにすぐに要求する。第１のＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔにも連絡できない場合には、ＲＮは、同様の要求を第２のＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔへ送信する。ＵＡＴＩ＿ＲｅｑｕｅｓｔがＰｒｉｍａｒｙ ＲＮＣによって受信されると、Ｐｒｉｍａｒｙ ＲＮＣは、ＡＴとの新たなＩＳ−８５６セッションをすぐに確立し、ＰＤＳＮとの新たなＡ１０接続をセットアップするための手続きをさらに開始する。

新たなＰｒｉｍａｒｙ ＲＮＣの割り当ては、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔによって開始することもできる。これは、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔにサブネットワーク内のすべてのＲＮＣの健全性を継続的にモニタさせることによって達成することができる。ＲＮＣの障害を検知すると、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、影響されるすべてのＲＮとすぐに通信し、それらのＲＮを新たなＰｒｉｍａｒｙ ＲＮＣに割り当てる。ＲＮをＰｒｉｍａｒｙ ＲＮＣに割り当てる際に、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、負荷バランシングを実行して、そのユーザ・セッションが、利用可能なすべてのＲＮＣにわたって均等に配分されるようにすることができる。

負荷バランシング・セッションの割り当て
上述の方法は、ユーザ・セッションをＲＮＣに割り当てることをＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔに最終的に担当させることによって、さらに強化することができる。この場合には、第１の（すなわちＤｅｆａｕｌｔの）ＲＮＣ、または場合によってはＲＮそのものが、新たなＵＡＴＩ＿Ｒｅｑｕｅｓｔを受信すると、そのＰｒｉｍａｒｙ ＲＮＣ（またはそのＲＮ）は、セッションをＲＮＣに割り当てるようＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔに要求する。ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、リソースの利用可能度、負荷、およびＲＮＣと、その時点でＡＴにサービスを提供しているＲＮとの距離に基づいて、セッションをＲＮＣに割り当てる。このアプローチは、ＲＮＣどうしの間でさらに良好な負荷バランシングを提供し、ＲＮＣの全体にわたってさらに動的にユーザ・セッションを配分しつつ、ＡＴの現在の位置を考慮に入れることも可能にする。ＲＮＣの障害の場合には、すべての新たなセッションの要求は、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔに着信し、次いでＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔが、やはり負荷およびその他の考慮事項に基づいて、これらのセッションを新たなＲＮＣに割り当てることになる。

ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔを使用して、負荷バランシングまたはその他の目的で休眠中のハンドオフを引き起こすこともできる。Ｐｈａｓｅ １ ＩＳ−８５６ネットワークにおいては、休眠中のＲＮＣ間でのハンドオフは常に、サブネットの変化が検知された際にＡＴによって引き起こされる。上述のように、すぐに休眠中のハンドオフを行わないと、呼び出しデータが失われる結果になる可能性がある。

図３および図４に示されている改良されたＩＳ−８５６ネットワークにおいては、休眠中のハンドオフは、ＡＴの位置に基づいてネットワークによって開始することができる。ＲｏｕｔｅＵｐｄａｔｅを受信した際に、サービス提供側ＲＮＣは、（負荷バランシングまたはその他の理由で）ユーザ・セッションを別のＲＮＣへ転送することが望ましいと判断した場合には、Ｄｏｒｍａｎｔ Ｈａｎｄｏｆｆ要求をＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔへ送信し、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔが、そのセッションを新たなＲＮＣに割り当てる。次いで新たなサービス提供側ＲＮＣは、新たなＵＡＴＩを割り当て、前のサービス提供側ＲＮＣからのセッションの転送を実行する。

ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔのコンセプトのさらに分散された実装形態においては、ＲＮＣは、ＲＮおよびその他のＲＮＣと絶え間なく通信して、すべてのＲＮに（それらの負荷を含む）経路指定情報を提供することができ、それによってそれらのＲＮは、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔを経由することなく、着信するセッション要求を正しいＲＮＣへ経路指定することができる。たとえばそれぞれのＲＮは、好ましいＲＮＣのリストを有することができ、新たなセッションをＲＮＣに割り当てることが必要な場合は常に、何らかのアルゴリズム（擬似ランダム選択、ラウンドロビンなど）に従ってこのリスト内のＲＮＣのうちの１つを選択する。もしも好ましいリスト内のあるＲＮＣが利用不可能になった場合には、ＲＮは、それを検知し（ＲＮがＲＮＣの障害を検知する上で役立つように、ＲＮとＲＮＣとの間でＫｅｅｐＡｌｉｖｅメッセージングを使用することができる）、そのＲＮＣをその好ましいリストから外す。このアプローチの欠点は、そのような動的な負荷情報をやり取りする結果として、何らかの帰路信号トラフィックが生じることである。

セッションの保持を伴う障害回復
いくつかのネットワークにおいては、ＲＮＣの障害の場合にユーザ・セッション情報を回復することが必要となる可能性がある。これによって、ＲＮＣの障害の直後に何百もの新たなセッションの要求のために引き起こされる可能性がある無線リンクの混雑がなくなる。ＲＮＣの障害の場合にセッションを保持するために、（サブネットワーク内のすべてのセッションに関して）そのような情報のコピーをＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔ内に保存することができる。

ＲＮＣに障害が発生して、ＡＴが新たなセッションを開始した場合には、その新たなセッションの要求は、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔに届く。次いでＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、新たなサービス提供側ＲＮＣをそれぞれのセッションに割り当てるだけでなく、セッション情報も提供し、それによって冗長なセッション確立の手続きを回避する。新たなＵＡＴＩがＡＴに首尾よく割り当てられると、ネットワークとの通信を再開することができる。ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、ＲＮＣが同じＰＤＳＮとＡ１０セッションを確立できるようにするために、Ａ１０インターフェースに関連する情報をさらに提供し、それによって新たなＰＰＰおよびＭｏｂｉｌｅ／Ｓｉｍｐｌｅ ＩＰセッションのセットアップを回避する。

シャーシベースのＲＮＣにおいては、ＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、ホット・スタンバイを利用して特定の余分なカード上で作動することができる。そしてＲＮＣ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ａｇｅｎｔは、セッション情報の保存を担当する。サーバ・モジュールに障害が発生した場合には、セッションは、内部で別のサーバ・モジュールに割り当て直される。原理としては、このシステムのオペレーションは、ネットワークの全体にわたって機能するオペレーションと同じである。さらに、この場合には、ＰＤＳＮによって見られるＰＣＦの外部のＩＰアドレスを維持することができるため、ＰＤＳＮへのＡ１０セッションを再び確立することが不要である。

ＲＮＣとＰＤＳＮの統合
上述したＩＰベースの無線アクセス・ネットワーク・アーキテクチャの別の利点は、ＲＮＣの機能とＰＤＳＮの機能を単一のネットワーク要素内で結合することができるという点である。階層化された３Ｇパケット・データ・ネットワークにおいては、ＰＤＳＮは、階層内の最も高いポイントを表し、したがって複数のＲＮＣをサポートすることができる。新たな世代のＰＤＳＮは、数十万人のユーザおよび数個のＲＮＣをサポートすることを期待されている。

ＲＮとＲＮＣの間に専用のポイントツーポイントのリンクを有する既存の無線アクセス・ネットワークにおいては、ＰＤＳＮの機能をＲＮＣへ移行すると、サポートできるセッションの数が減ることになり、新たなＰＰＰおよびＳｉｍｐｌｅ／Ｍｏｂｉｌｅ ＩＰの登録を含むＰＤＳＮどうしの間におけるハンドオフが頻繁に生じてコストがかさむ結果となるため、望ましくない。

本明細書に記載のＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、ＲＮＣどうしの間におけるハンドオフが発生する頻度は非常に低く、したがってＰＤＳＮの機能をＲＮＣへ統合することが可能となる。１つのアクティブな呼び出しに対しては、常に同じＲＮＣによってサービスを提供することができるため、ＰＤＳＮ間でのハンドオフは、１つのアクティブな呼び出しの間には通常は必要とされない。このようなアプローチはまた、ＲＮＣとＰＤＳＮの間におけるネットワークの形成を単純化し、拡張性および信頼性をさらに高める。

統合されたＰＤＳＮを有するＲＮＣにおいては、ＰＤＳＮの機能は、ＰＰＰの終了、Ｓｉｍｐｌｅ ＩＰおよび／またはＭｏｂｉｌｅ ＩＰのフォーリン・エージェント、およびＡＡＡクライアントの機能を含む。ＡＴが、１つのサブネット（たとえば１つのＲＮＣクラスタ）内に留まっている限り、ＰＤＳＮ間でのハンドオフは、まったく必要とされないであろう。

統合されたＲＮＣ／ＰＤＳＮに障害が発生した場合には、ＡＴをサポートしているすべてのセッション（無線インターフェース、ＰＰＰ、およびＳｉｍｐｌｅ／Ｍｏｂｉｌｅ ＩＰのセッションを含む）は、別のＲＮＣ／ＰＤＳＮへ転送され、それによって、ＡＴと無線ネットワークの間におけるいかなる新たなセッションの確立も回避される。

ＲＮＣ／ＰＤＳＮをＲＮと統合することも可能である。この場合には、ＲＮＣ／ＰＤＳＮの機能は、同じ場所のＲＮと、あるいは同じ筐体内のＲＮとさえ同一の場所に配置することができる。

本開示に記載の方法は、ＲＮＣとＰＤＳＮとが、あるいはＲＮと、ＲＮＣと、ＰＤＳＮとが統合されている、すなわち同一の場所に配置されているネットワークに等しく適用することができるということが理解できるはずである。

第１／第２のＲＮＣの関連付けを伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャ
それぞれのＲＮは、上述のように、そのＲＮが関連付けられる（たとえば、第１の関連付けを確立する）第１の（たとえばデフォルトの）ＲＮＣを有する。帰路ネットワーク８０を使用して、それぞれのＲＮは、ＩＰ ＲＡＮ内の１つまたは複数のその他のＲＮＣに関連付けることもでき、これらのＲＮＣは、そのＲＮに関する第２のＲＮＣと呼ばれる（たとえば、第２の関連付けを確立する）。ＲＮＣとの関連付けを行うために、そのＲＮは、自分自身に関する十分な情報を第２のＲＮＣに提供して、これらのＲＮＣがそのＲＮを介してＡＴと通信できるようにする。さらに、そのＲＮと第２のＲＮＣとの間における信号のやり取りをサポートするために、それらの間に信号接続が確立される。ＲＮＣはまた、第１のＲＮと第２のＲＮとを区別する。第１のＲＮは、そのＲＮＣとの第１の関連付けを有するＲＮである。第２の関連付けは、たとえばＲＮの電源が入ったときに確立することができる。

ＲＮは、ＡＴからアクセス・チャネル・パケットを受信すると、そのパケットを無分別に自分の第１のＲＮＣへ転送する。ＲＮのサービス・エリア内における休眠中のＡＴは、そのＲＮの第１のＲＮＣによってサービスを提供される。基本的な実装形態においては、同じ第１のＲＮＣを共有するすべてのＲＮは、同じ１ｘＥＶ−ＤＯサブネットに属する。ＡＴは、サブネットの境界を越えた場合には、ＵＡＴＩ−Ｒｅｑｕｅｓｔを自分のサービス提供側ＲＮへ送信し、次いでそのサービス提供側ＲＮは、その要求を自分の第１のＲＮＣへ転送する。このＵＡＴＩは、そのＲＮＣによってサービスを提供されていないため、そのＲＮＣは、１ｘＥＶ−ＤＯ ＩＯＳにおいて定義されているＡ１３インターフェースに従って、古いサービス提供側ＲＮＣと共に休眠中のＲＮＣ間でのハンドオフのための通常の手続きを開始する。新たなＲＮＣも、Ａ１０ハンドオフを実行する。要するに、この方法は、ＲＮＣどうしの間における休眠中のハンドオフの境界を実際に保持する。

別々の１ｘＥＶ−ＤＯサブネットに属するＲＮが同じ第１のＲＮＣを共有できるようにすることも可能である。この場合には、ＡＴが、サブネットの境界を越えた際にＵＡＴＩ−Ｒｅｑｕｅｓｔを送信すると、そのメッセージは、その時点でそのＡＴにサービスを提供している同じ第１のＲＮＣへ転送される（というのは、その同じＲＮＣが、双方のサブネット内のＲＮにとって第１のＲＮＣであるためである）。次いで、自分がこのＵＡＴＩに既にサービスを提供していることを認識している第１のＲＮＣは、Ａ１３手続きまたはＡ１０ハンドオフを伴わずにＵＡＴＩの割り当てを進めることができる。

第１のＲＮＣは、休眠中のＡＴに関してＡ１０接続を介して着信データを受信した場合には、通常どおり呼び出し手続きを進める。この呼び出しメッセージは、このＲＮＣを第１のＲＮＣとして有するすべてのＲＮ、またはそれらのサブセットを介して再び送信される。

サービス提供側ＲＮＣは、トラフィック・チャネルのセットアップを要求するＡＴからのトラフィック・チャネル要求メッセージを受信した場合には、はじめにＲｏｕｔｅＵｐｄａｔｅメッセージを検査して、必要とされているパイロットを割り出し、それらのパイロットが配置されているＲＮを見つけ出す。次いでサービス提供側ＲＮＣは、これらのＲＮと連絡を取って、通常どおりトラフィック・チャネルをセットアップする。第１／第２の関連付けによって、ＲＮＣは、要求されているパイロットのＰＮオフセットをＲＮのＩＰアドレスに対応付けて、これらのＲＮとの間であらかじめ確立されている信号接続を使用して、すべてのハンドオフ行程をセットアップすることができる。いったんアクティブなトラフィック・チャネルが確立されると、サービス提供側ＲＮＣは、そのトラフィック・チャネル用のＲＮＣとして固定されたままとなる。サービス提供側ＲＮＣは、ＲＮの第２の関連付けを使用して、ＡＴが複数のサービス・エリアを通じて移動するにつれてＲＮを追加および除外する。

たとえば、あるＡＴが第１のＲＮとはじめて通信した際に、そのＲＮは、上述のように、自分の第１のＲＮＣ（すなわち、その第１のＲＮが第１の関連付けを有しているＲＮＣ）へ要求を転送する。いったんトラフィック・チャネルが確立されると、第１のＲＮＣは、ＡＴが第１のＲＮのサービス・エリアから第２のＲＮのサービス・エリアへ移動した際に、たとえその第２のＲＮがサービス提供側ＲＮＣとの第１の関連付けを有していなくても、そのトラフィック・チャネルの全体に関して依然としてサービス提供側ＲＮＣのままである。これによって、ユーザの行動（たとえば電話、データの転送）は、途切れることなく継続することができる。ＡＴは、第１のＲＮのサービス・エリアから第２のＲＮのサービス・エリアへ移動している間に、ＲｏｕｔｅＵｐｄａｔｅメッセージを送信することによって、第２のＲＮに関するパイロット強度情報をサービス提供側ＲＮＣに伝達する。同じ第１のＲＮＣを有するＲＮどうしの間における通常のソフト・ハンドオフの場合と同様に、この伝達は、ＡＴがまだ第１のＲＮを使用している間に行われる。ＲｏｕｔｅＵｐｄａｔｅメッセージを受信すると、サービス提供側ＲＮＣは、確立されている第２の関連付けのために第２のＲＮと通信することができ、この第２の関連付けは、上述のように、パイロット信号のＰＮオフセットおよびＲＮのＩＰアドレスなどの情報を含み、サービス提供側ＲＮＣは、第２のＲＮと連絡を取って、通信チャネルを確立することができる。上述のハンドオフの手続きの１つの魅力的な側面は、通常のソフト・ハンドオフとまったく同様に機能するという点である。唯一の相違点は、ＲＮとＲＮＣとの間における第２の関連付けであり、この第２の関連付けによって、ＲＮＣは、第１の関連付けを有していないＲＮとのトラフィック・チャネルをセットアップすることができる。

ＲＮは、自分のアクセス・チャネル・パケットを自分の第１のＲＮＣへ常に転送しているため、もはやＵＡＴＩに基づいてアクセス・チャネル・パケットの経路指定を実行する必要はない。これによって、ＩＰベースの無線アクセス・ネットワークの実装形態が大幅に単純化される。

シャーシベースのシステム
上述のコンセプトは、たとえばそれぞれのサーバ・カードをＩＰアドレスの指定が可能なＲＮＣとして、またはそれぞれのモデム・カードをＩＰアドレスの指定が可能なＲＮとして取り扱うことによって、シャーシベースのシステム内で使用することもできる。システムの論理的なオペレーションは変わらない。

しかし、多くのサーバ・カードを有する大きなネットワークにおいては、それぞれのサーバ・カードを１つの独立したＲＮＣとして取り扱うと、結果としてＲＮＣの数があまりにも多くなる可能性があり、ひいては多くの信号接続、およびＲＮとＲＮＣの関連付けが生じる可能性がある。この複雑さを隠す１つの方法は、シャーシ全体をＩＰアドレスの指定が可能な１つのＲＮＣとして取り扱い、内部のプロトコルを使用してシャーシ間での通信を処理することである。やはり上述のコンセプトを同じ方法で使用することができ、外側から見たときのＲＮＣおよびＲＮの論理なオペレーションは変わらない。以降の記述は、これらのコンセプトがシャーシベースのＲＮＣの内部のオペレーションにいかに影響を与えるかに関して、さらに詳しく説明している。

上述の例のうちのいくつかにおいては、あるＲＮが、その第１のすなわちデフォルトのＲＮＣに関連付けられる際に、そのＲＮとＲＮＣとの間に信号接続が確立される。シャーシベースのシステムにおいては、サーバ・カードのうちの１つが、関連付けを実行して信号接続を終了させる役割を担うことができる。つまり、新たなＲＮがＲＮＣとの関連付けを望む場合には、そのＲＮは、サーバ・カードのうちの１つに内部で割り当てられる（そこの本拠とされる）。それ以降、そのＲＮＣとそのＲＮとの間におけるすべての信号伝達は、そのサーバ・カードを介して実行される。ＲＮＣ間での信号伝達を伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、シャーシベースのＲＮＣは、ＳＣ（ｓｙｓｔｅｍ ｃｏｎｔｒｏｌｌｅｒ）カード内に存在することができるＲＮＣ間のトポロジ・マネージャを使用して、これらのＲＮがサービスを提供するＰＮオフセットおよびそれらがコントロールするＵＡＴＩスペースを含むその他のＲＮＣを見つけ出すことができる。システム・コントローラ・カードは、ＲＮに関する必要な情報を学習してその他のＲＮＣへ渡すために、サーバ・カードと通信する。

シャーシベースのＲＮＣを利用するいくつかの実装形態においては、あるＲＮが、受信したＡＣパケットをシャーシベースのＲＮＣへ転送した場合に、そのパケットは、はじめにＩ／Ｏカードによって傍受され、このＩ／Ｏカードは、そのＡＣパケット内のＵＡＴＩアドレスを点検して、そのＵＡＴＩにサービスを提供しているサーバ・カードを割り出し、そのサーバ・カードへパケットを転送する。そのＵＡＴＩがローカルにサービスを提供されている場合には、Ｉ／Ｏカードは、そのＵＡＴＩにサービスを提供している特定のサーバ・カードを割り出し、そのサーバ・カードへパケットを転送する。このような転送を実行するために、Ｉ／Ｏカードは、ＵＡＴＩアドレスをＲＮＣに対応付けるテーブルを保持し、ローカルなＵＡＴＩアドレスをサーバ・カードにさらに対応付ける。

シャーシベースのＲＮＣ内のあるサーバ・カードが、トラフィック・チャネルのセットアップを求める要求をＡＴから受信した場合には、このサーバ・カードはまず、受信したＰＮオフセットをＲＮ ＩＰアドレスに対応付けることによって、アクティブなセットにとって必要とされるパイロットを有するＲＮのセットをＲｏｕｔｅＵｐｄａｔｅメッセージから割り出す。次いでこのサーバ・カードは、このサーバ・カードの本拠とされているＲＮと直接信号をやり取りして、必要とされるトラフィック・チャネル区間を確立する。同じＲＮＣシャーシの本拠とされているその他のＲＮが存在する場合、それらのＲＮに関しては、このサーバ・カードはまず、それらのＲＮが本拠とされているサーバ・カードを割り出す。このサーバ・カードは、同じシャーシを共有するこれらのサーバ・カードと連絡を取り、次いでこれらのサーバ・カードは、ＲＮと連絡を取って、トラフィック・チャネル区間を確立する。その他のＲＮＣシャーシの本拠とされているその他のＲＮに関しては、このサーバ・カードは、これらのＲＮＣと連絡を取る。次いでこれらのＲＮＣ内のＩ／Ｏカードは、それらのＲＮが本拠とされているサーバ・カードへ要求を経路指定する。そしてこれらのサーバ・カードは、それらのＲＮと連絡を取って、必要とされるトラフィック・チャネル区間を確立する。

ＩＰ ＲＡＮ内のすべてのＲＮとＲＮＣとの間では直接のＩＰ通信が可能であるため、すべてのトラフィック・チャネル区間は、ＲＮとサービス提供側ＲＮＣとの間で直接機能する。シャーシベースのＲＮＣのＩ／Ｏカードがトラフィック・チャネル・パケットを受信した場合には、そのＩ／Ｏカードは、そのトラフィック・チャネルが一意の接続識別子に基づいて処理されているサーバ・カードにそのパケットを転送する。

いくつかの実装形態においては、それぞれのサーバ・カードに１つのＩＰアドレスを割り当てることができ、そのそれぞれのサーバ・カードは、トラフィック・チャネルにサービスを提供しているＲＮにそのアドレスを提供することができる。次いでそれらのＲＮは、トラフィック・チャネル・パケットを直接サービス提供側ＲＮＣへ送信することができる。次いでそれらのパケットは、接続識別子に基づいたさらに高い層の参照を必要とすることなく、Ｉ／Ｏカードを介してサーバ・カードへ経路指定される。

シャーシベースのＲＮＣは、自分が第１のＲＮＣではないＲＮのサービス・エリア内にＡＴがいる場合でさえ、そのＡＴとの通信を保持することができる。すべてのユーザ・トラフィックは、直接ＲＮとサービス提供側ＲＮＣとの間で流れる。休眠中のＡＴがＩＰ ＲＡＮの全体にわたって移動する場合には、サービス提供側ＲＮＣはＩＰ ＲＡＮ内のいずれのＲＮを介してもＡＴを呼び出すことができるため、ＲＮＣ間でのハンドオフは（可能ではあるが）必要とされない。

ＲＮＣ間での信号伝達を伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、上述のように、Ｓｙｓｔｅｍ Ｃｏｎｔｒｏｌｌｅｒカードを介してＲＮＣどうしの間で見つけ出して通信が行われる。このアーキテクチャは、第１のＲＮＣがサービス提供側ＲＮＣではなく、パケットが別のシャーシベースのＲＮＣのＩ／Ｏカードを介して経路指定される場合には、アクセス・チャネル・パケットの三者間での経路指定を結果的にもたらすこともできる。また、ＲＮＣサーバ・カードの障害は、そのＲＮＣサーバ・カードの本拠とされているすべてのＲＮの障害をもたらす結果となる。ＲＮＣシャーシの全体に障害が発生した場合には、すべての第１のＲＮが失われる。

ＲＮＣ間での信号伝達を伴わない改良されたＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、ＲＮは、ＩＰ ＲＡＮ内の複数のＲＮＣとの関連付けを行い、ＵＡＴＩアドレスをサービス提供側ＲＮＣに対応付けるためのテーブルを保持する。このアプローチにおいては、ＲＮは、サブネットの情報と共に構成することができ、その一方で第１のＲＮＣを伴うその他の方法においては、この情報は、その第１のＲＮＣによって提供することができる。ＲＮはまた、ＩＰ ＲＡＮ内の複数のＲＮＣとの信号接続を保持する。すべての信号伝達は、これでシャーシベースのＲＮＣ上のサーバ・カードのうちの１つにおいて終了するようになり、そのサーバ・カードは、そのＲＮを本拠とするように割り当てられる。ＲＮは、自分が本拠とされているサーバ・カードに自分のＩＰアドレスを含む自分自身に関する情報を提供する。次いでこのサーバ・カードは、その情報をシャーシベースのＲＮＣ内のその他のすべてのサーバ・カードに配信する。

これらの例においては、ＲＮは、ＡＴからアクセス・チャネル・パケットを受信した場合には、ＵＡＴＩアドレス・フィールドを点検し、そのテーブルからサービス提供側ＲＮＣのＩＰアドレスを割り出し、次いでそのＲＮＣへパケットを転送する。シャーシベースのＲＮＣ内のＩ／Ｏカードは、そのパケットを傍受し、そのパケットをアクセス・チャネル・パケットとして識別し、ＵＡＴＩアドレスを点検し、このＡＴを取り扱っているサーバ・カードへそのパケットを経路指定する。トラフィック・チャネルのセットアップにおいては、サーバ・カードは、そのサーバ・カードの本拠とされているＲＮに直接連絡を取って、トラフィック・チャネル区間のセットアップを要求する。その他のＲＮに関しては、サーバ・カードはまず、そのＲＮが本拠とされている他のサーバ・カードを割り出し、その他のサーバ・カードと連絡を取り、次いでその他のサーバ・カードが、ＲＮと連絡を取って、トラフィック・チャネル区間をセットアップする。このアプローチにおいては、ＲＮＣは、経路指定を最適化するために発生しうるＲＮＣ間でのハンドオフを処理することを除いてＲＮＣ間での通信をまったく伴わない自律的なエンティティとして機能することができる。しかし、本拠の設定を処理するためのカード間での通信は存在する。

たとえＲＮＣシャーシどうしの間における三者間での経路指定がなくなっても、すべてのパケットがＩ／Ｏカードを介して移動し、そのＩ／Ｏカードがさらに高い層の経路指定機能を実行する場合には、シャーシ内部での間接的な経路指定が存在する可能性がある。１つのサーバ・カードの障害は、そのサーバ・カードの本拠とされているＲＮの障害をもたらす結果となる。これらのＲＮは、ＲＮＣ上に存在するセッションのいずれにも、障害が発生したサーバ・カード以外のサーバ・カード上で依然として無事でいるセッションにさえ、もはやサービスを提供することはできない。このような問題は、シャーシ内のそれぞれのサーバ・カードがＩＰアドレスの指定が可能なＲＮＣとして機能する場合には、発生しない。この場合には、パケットは、直接ＲＮとＲＮＣサーバ・カードとの間で経路指定され、１つのサーバ・カードの障害が、ＲＮまたはその他のサーバ・カードに影響を及ぼすことはない。

第１／第２の関連付けを伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、１組のシャーシベースのＲＮＣが、ＩＰ帰路ネットワークを介して１組のＲＮに接続され、ＲＮのすべてとＲＮＣのすべてとの間で第１または第２の関連付けが存在する。

それぞれのＲＮは、上述のようにそのＲＮが関連付けられる第１のシャーシベースのＲＮＣを有する。それぞれのＲＮは、ＩＰ ＲＡＮ内のその他のシャーシベースのＲＮＣにも関連付けられ、これらは、そのＲＮに関する第２のＲＮＣと呼ばれる。そのＲＮは、自分自身に関する十分な情報を第２のＲＮＣに提供して、これらのＲＮＣがそのＲＮを介してＡＴと通信できるようにする。さらに、そのＲＮと第２のＲＮＣとの間における信号のやり取りをサポートするために、そのＲＮとその第２のＲＮＣとの間に信号接続が確立される。それぞれの場合において、ＲＮとシャーシベースのＲＮＣとの間における関連付けは、ＲＮＣシャーシ内のサーバ・カードのうちの１つを介して処理される。

ＲＮが自分の第１のＲＮＣへ無分別に転送するアクセス・チャネル・パケットは、Ｉ／Ｏカードによって傍受され、このＩ／Ｏカードは、ＵＡＴＩフィールドを点検し、その時点でそのＵＡＴＩを処理しているサーバ・カードへそのパケットを転送する。ＲＮのサービス・エリア内における休眠中のＡＴは、そのＲＮの第１のＲＮＣ内のサーバ・カードによってサービスを提供される。同じ第１のＲＮＣを共有するすべてのＲＮは、同じ１ｘＥＶ−ＤＯサブネットに属する。ＡＴは、サブネットの境界を越えた場合には、ＵＡＴＩ−Ｒｅｑｕｅｓｔを自分のサービス提供側ＲＮへ送信し、次いでそのサービス提供側ＲＮは、その要求を自分の第１のＲＮＣへ転送する。このＵＡＴＩは、そのＲＮＣによってサービスを提供されていないため、ＵＡＴＩフィールドを点検した後のＩ／Ｏカードは、その要求をそのサーバ・カードのうちのいずれか１つへ転送する。次いでサーバ・カードは、１ｘＥＶ−ＤＯ ＩＯＳにおいて定義されているＡ１３インターフェースに従って、古いサービス提供側ＲＮＣと共に休眠中のＲＮＣ間でのハンドオフのための通常の手続きを開始することができる。新たなサーバ・カードも、Ａ１０ハンドオフを実行する。

別々の１ｘＥＶ−ＤＯサブネットに属するＲＮが同じ第１のＲＮＣを共有できるようにすることも可能である。この場合には、ＡＴが、サブネットの境界を越えた際にＵＡＴＩ−Ｒｅｑｕｅｓｔを送信すると、そのメッセージは、その時点でそのＡＴにサービスを提供している同じ第１のＲＮＣへ転送される（というのは、その同じＲＮＣが、別々のサブネット内のＲＮにとって第１のＲＮＣであるためである）。ＵＡＴＩアドレスを点検することによって、第１のＲＮＣ内のＩ／Ｏカードは、その時点でそのＵＡＴＩにサービスを提供しているサーバ・カードへそのパケットを転送することができ、次いでそのサーバ・カードは、Ａ１３手続きまたはＡ１０ハンドオフを伴わずにＵＡＴＩの割り当てを進めることができる。

第１のＲＮＣが、休眠中のＡＴに関してＡ１０接続を介して着信データを受信した場合には、パケットは、やはりＩ／Ｏカードによって傍受され、そのＩ／Ｏカードは、点検後に、そのＡ１０リンクを処理しているサーバ・カードへそのパケットを転送する。次いでサーバ・カードは、通常どおり呼び出し手続きを進める。この呼び出しメッセージは、このＲＮＣを第１のＲＮＣとして有するすべてのＲＮ、またはそれらのサブセットを介して再び送信される。

サーバ・カードは、トラフィック・チャネルのセットアップを要求するＡＴからのトラフィック・チャネル要求メッセージを受信した場合には、ＲｏｕｔｅＵｐｄａｔｅメッセージを検査して、必要とされているパイロットを割り出し、その時点でそれらのパイロットを処理している他のサーバ・カードを見つけ出す。そのサーバ・カードは、これらの他のサーバ・カードと連絡を取り、次いでこれらの他のサーバ・カードが、ＲＮと連絡を取って、通常どおりトラフィック・チャネルをセットアップする。第１／第２の関連付けによって、サーバ・カードは、要求されているパイロットのＰＮオフセットを、それらのＲＮが本拠とされているサーバ・カードに関する識別子に対応付け、これらの本拠とされているＲＮを通じてあらかじめ確立されている信号接続を使用して、すべてのハンドオフ区間をセットアップすることができる。

上述の説明をさらに拡張して、サーバ・カードの障害の場合に信頼性を高めることができる。いくつかの例においては、１つのサーバ・カードに障害が発生すると、そのカードによってサービスを提供されるすべてのユーザ・セッションも失われる。つまりユーザは、かなりの時間にわたって連絡不可能なままとなる可能性がある。ユーザは、自分が連絡不可能であることに気づかない可能性もある。これを防止するために、ユーザ・セッションがはじめて確立されたときに、セッションの状態に関する情報のコピーが、別個のカード、たとえばシステム・コントローラ・カード上に保存される。セッション情報には、さまざまなプロトコル構成、モビリティ情報、ＵＡＴＩなどが含まれる。セッション・パラメータが変わると、システム・コントローラ・カード上のセッション情報が更新される。

システム・コントローラ・カードは、ハートビート・シグナリング・メカニズムを使用して、サーバ・カードの障害を検知し、残りのサーバ・カードのうちのいずれか１つにセッションを割り当てる。新たなサーバ・カードは、自分が必ずＡＴとの接続を有するようにＵＡＴＩを割り当て直すことができる。この方法では、負荷のバランスがとれたＮ＋ｌの冗長性構成において余分なサーバ・カードを１つだけ使用することによって、障害の発生したサーバ・カード上にセッションを割り当て直すための十分なヘッドルームが存在するようになる。

上述の技術のうちのいくつかは、１ｘＥＶ−ＤＯ無線インターフェース標準を採用しているが、これらの技術は、その他のＣＤＭＡおよびＣＤＭＡ以外の無線インターフェース・テクノロジーにも同様に適用することができる。この場合には、リンク層アドレス（ＡＴＩ）は、１ｘＥＶ−ＤＯにおいて使用されているＡＴＩとは若干異なるもの（たとえば、ｃｄｍａ２０００におけるＴＭＳＩ）にすることができ、呼び出しゾーン、ＰＣＦゾーンなど、その他のＲＮゾーンを、１ｘＥＶ−ＤＯサブネットの代わりに使用することができる。

シャーシベースのＲＮＣにおける接続レベルでの負荷バランシングおよび過負荷コントロール
シャーシベースのＲＮＣにおいては、サーバ・カード上の負荷が、そのカードの処理能力および記憶能力を超えた場合には、そのカードによってサービスを提供されているすべてのユーザのパフォーマンスが影響を受ける可能性がある。そのような過負荷の状況を防止するために、接続レベルでの負荷バランシングを使用することができる。

たとえば、処理およびメモリ使用量が過大になった場合には、サーバ・カードは、リソースが利用可能である可能性のある１つまたは複数のその他のカードへの、１つまたは複数の接続に関するアクティブなセッションの転送を引き起こすことができる。このような負荷バランシング・スキームまたは過負荷コントロール・スキームにおいては、シャーシ上のそれぞれのサーバ・カードの個々の負荷を追跡把握するためのシャーシ内の何らかの中央のエンティティ、たとえばシステム・コントローラ・カードを有することが望ましい。いくつかの実装形態においては、サーバ・カードは、過負荷になると、どの接続を別のカードへ転送するかを決定する。ここでは、サーバ・カードは、接続内の個々の流れのＱｏＳニーズ、このところ接続がどれぐらい多くの処理リソースおよびメモリ・リソースを使用しているかという点、ユーザのＱｏＳクラスなどを含むいくつかの基準のうちの１つを使用することができる。サーバ・カードは、どの（１つまたは複数の）接続を別のサーバ・カードへ転送したいかを決定したら、ＲＮＣに関連付けられている中央のロード・トラッカーに連絡を取り、これらの接続を転送できる（１つまたは複数の）ターゲット・サーバ・カードを要求する。

中央のロード・トラッカーが、利用可能なサーバ・カードのリストを提供すると、過負荷になっているカードは、それらの利用可能なサーバ・カードのうちの１つまたは複数に直接連絡を取って、以降で論じるアクティブなＲＮＣ間でのハンドオフの手続きと同様のアクティブなセッションの転送（すなわちハンドオフ）を開始する。

いくつかの実装形態においては、中央のロード・トラッカーは、事前対処的に負荷バランシングを引き起こす。たとえば中央のロード・トラッカーが、ＲＮＣサーバ・カードに不均等に負荷がかかっていることを検知した場合には、その中央のロード・トラッキング・エンティティは、アクティブなセッションの転送要求を、接続にサービスを提供できる比較的負荷の少ないサーバ・カードのＩＤと共に、過負荷になっているサーバ・カードへ送信する。

いくつかの実装形態においては、負荷バランシングは、ＩＰベースの無線ネットワーク内における１つのクラスタ内の複数のＲＮＣにわたって実行される。たとえば、１つのクラスタ内のすべてのＲＮＣに対する中央のロード・トラッキング・エンティティは、それぞれのＲＮＣ内のローカルなロード・トラッカーと対話することによって、個々のＲＮＣの負荷全体を追跡把握する。中央のロード・トラッキング・エンティティは、クラスタ化されたＲＮＣどうしの間で負荷の不均衡を検知した場合には、過負荷になっているＲＮＣから比較的負荷の少ないＲＮＣへのアクティブなセッションの転送を引き起こす。１つのクラスタに関する中央のトラッキング・エンティティは、そのクラスタ内のＲＮＣのうちの１つの中に存在することもでき、あるいはそのクラスタ内のＲＮＣの外部に存在することもできる。

上述の負荷バランシング・メカニズムおよび過負荷コントロール・メカニズムは、ＲＮＣの内部および／またはクラスタの内部に分散された方法で実装することができる。たとえば、１つのクラスタに関連付けられている中央のロード・トラッキング・エンティティの代わりに、そのクラスタ内のＲＮＣ内におけるローカルなロード・トラッキング・エンティティどうしが、お互いに直接負荷情報を共有することができる。このようにすると、ＲＮＣは、過負荷を経験しているときに、たとえばその他のローカルなロード・トラッキング・エンティティに連絡を取ってクラスタ内のその他のＲＮＣの利用可能度を割り出すことによって、アクティブなセッションをクラスタ内のどのＲＮＣへ転送するかを決定することができる。次いでＲＮＣは、利用可能なＲＮＣへのアクティブなハンドオフを引き起こすことができる。同様の戦略は、１つのＲＮＣ内における負荷バランシングを処理するために使用することもできる。

１つのサーバ・カードに障害が発生した場合には、ＲＮＣ内の別の場所またはクラスタ内の外部の接続状態に関する重要な情報を保存するための何らかのメカニズムがない限り、そのサーバ・カードによって処理されているすべての接続も失われる。いくつかの実装形態においては、接続状態に関する情報は、ＲＮＣのシステム・コントローラ・カード上に提供することができる。したがって、１つのサーバ・カードに障害が発生した場合には、システム・コントローラは、その障害が発生したサーバ・カード上のトラフィック・チャネルをシステム内のその他のサーバ・カードに割り当てることができる。次いで、サーバ・カードに対する責任を負うサーバは、接続にサービスを提供しているすべてのセクタへのトラフィック・チャネル区間を確立し、ＰＤＳＮへのＡ１０リンクを復元し、無線リンク・プロトコルを初期化し、トラフィック・チャネルのオペレーションを再開する。

部分的に接続された無線ネットワークにおける休眠中のハンドオフ
ＩＰベースの無線ネットワークにおいては、休眠中のＡＴは、その時点で自分にサービスを提供しているＲＮにかかわらず、複数のＲＮＣを介してネットワークに接続することができる。これらのＲＮＣは、自分たちがサービスを提供するＲＮと共に、１つのクラスタを形成する。すべてのＲＮが、すべてのＲＮＣとの完全な関連付けを有する場合には、そのようなクラスタは、メッシュＲＮＣクラスタと呼ばれる。メッシュＲＮＣクラスタの内部においては、休眠中のＡＴは、自分のサービス提供側ＲＮＣが、そのクラスタ内のＲＮのうちのいずれか１つを介してそのＡＴと通信することができるため、そのサービス提供側ＲＮＣへの接続を常に保持することができる。つまりサービス提供側ＲＮＣは、クラスタ内のどこでもＡＴを呼び出すことができ、休眠中のＡＴは、クラスタ内のどこでもサービス提供側ＲＮＣへアクセス・チャネル・メッセージを送信することができる。

１つのＲＮが、１つのクラスタ内のそれぞれのＲＮＣとの関連付けを有さない場合には、そのクラスタは、部分的に接続されたクラスタと呼ばれる。部分的に接続されたクラスタにおいては、ＡＴは、その時点で自分にサービスを提供しているＲＮが、自分のサービス提供側ＲＮＣとの関連付けを有さない場合には、ネットワークの接続を失う可能性がある。つまりＡＴは、連絡不可能となる可能性があり、あるいは、たとえば新たな接続を要求するためにアクセス・チャネル・メッセージを自分のサービス提供側ＲＮＣへ送信することができないかもしれない。これが発生するのを防止するために、ＡＴのセッションは、サービス提供側ＲＮＣから、そのＡＴが接続を保持できる別のＲＮＣへ移転される。

いくつかの実装形態においては、１つのクラスタ内のＲＮＣおよびＲＮは、複数のメッシュ・クラスタへとさらに分割され、別々のクラスタに属するＲＮどうしの間に１ｘＥＶ−ＤＯサブネットの境界が形成される。次いで休眠中のＡＴは、クラスタどうしの間におけるサブネットの境界を越えた場合は常に、ＵＡＴＩＲｅｑｕｅｓｔを送信して、いわゆるＡ１３のＲＮＣ間における休眠中のハンドオフを引き起こす。そのＵＡＴＩＲｅｑｕｅｓｔを受信したＲＮは、それを自分の第１のＲＮＣ（または自分のクラスタ内のＲＮＣのうちの１つ）へ転送し、次いでこのＲＮＣは、そのＵＡＴＩから、その時点でＡＴのセッションにサービスを提供しているＲＮＣを割り出し、Ａ１３の休眠中のハンドオフを引き起こす。したがってクラスタどうしの間でサブネットを作成することによって、休眠中のＡＴは、必ず常にネットワークに接続されたままとなる。

アクティブなＡＴが、クラスタどうしの間におけるサブネットの境界を越えた場合には、サービス提供側ＲＮＣが、その他のクラスタ内のＲＮにトラフィック・チャネルを割り当てるのに必要な関連付けを有している限り、依然として接続を保持することができる。そうでない場合には、接続の境界に達する前に、アクティブなＲＮＣのハンドオフを実行しなければならない。

いくつかの実装形態においては、部分的に接続されたクラスタは、ＡＴが、自分のサービス提供側ＲＮＣとの関連付けを有していないＲＮのサービス・エリアへ移動することができ、そのＡＴがもはや連絡不可能であることにそのサービス提供側ＲＮＣが気づかないようにすることができるように構成される。たとえば、ＡＴがＲｏｕｔｅＵｐｄａｔｅを最後に送信したセクタのＲｏｕｔｅＵｐｄａｔｅＲａｄｉｕｓによって割り出されるＡＴの現在の呼び出しエリアは、サービス提供側ＲＮＣとの関連付けを有さないＲＮを含むことができる。したがってＲＮＣは、このＡＴに関する呼び出しデータを受信した場合には、これらのＲＮを介してそのＡＴを直接呼び出すことはできない。この問題に対処するために、ＲＮＣは、自分が関連付けを保持しているすべてのＲＮに関して、呼び出しエリアのリストを保持する。この呼び出しエリアのリストは、ＲＮのＲｏｕｔｅＵｐｄａｔｅＲａｄｉｕｓによって割り出される。このリストは、ＲＮＣが関連付けを有している呼び出しエリア内のすべてのＲＮのＩＰアドレスを含むだけでなく、そのＲＮＣが関連付けをまったく有していないＲＮに関する第１のＲＮＣのＩＰアドレスも含む。サービス提供側ＲＮＣは、呼び出しデータを受信した場合には、関連付けを有しているＲＮへ直接Ｐａｇｅメッセージを送信し、その他のＲＮに関するＰａｇｅ要求をそれらの第１のＲＮＣへ転送し、次いでそれらの第１のＲＮＣが、呼び出しエリア内のそれらのＲＮを介してＡＴを呼び出す。サービス提供側ＲＮＣは、呼び出しメッセージを別のＲＮＣへ転送する場合には、その他のＲＮＣが、自分のＲＮのうちのどれを介して呼び出しメッセージを送信する必要があるかを割り出すことができるようにするためのさらなる情報を含める。

いくつかの実装形態においては、サービス提供側ＲＮＣは、自分が第１のＲＮＣであるＲＮを介してのみ直接呼び出しメッセージを送信し、その他のＲＮに関しては、呼び出しメッセージをそれらの第１のＲＮＣへ転送し、次いでそれらの第１のＲＮＣが、呼び出しエリア内の自分のＲＮを介してＡＴを呼び出す。

部分的に接続されたクラスタにおいては、ＡＴは、サービス提供側ＲＮＣとの関連付けをまったく有していないＲＮのサービス・エリア内にいる場合には、アクセス・チャネル・メッセージをネットワークに送信することができる。この場合には、サービス提供側ＲＮは、アクセス・チャネル・パケット内のＵＡＴＩフィールドから、自分が関連付けをまったく有していないＲＮＣによってそのパケットがサービスを提供されているということを認識すると、そのパケットを自分の第１のＲＮＣ（または負荷バランシング・アルゴリズムに基づいて選択するその他の何らかのＲＮＣ）へ転送する。そのＲＮの第１のＲＮＣは、受信したアクセス・チャネル・メッセージを処理する前に、Ａ１３の休眠中のハンドオフを引き起こし、この場合には、ＡＴのセッションは、ハンドオフ中にＳｏｕｒｃｅ ＲＮＣの役割を担うことになるサービス提供側ＲＮＣから、ハンドオフ中にＴａｒｇｅｔ ＲＮＣの役割を担うことになるそのＲＮの第１のＲＮＣへ転送される。Ｔａｒｇｅｔ ＲＮＣは、受信したアクセス・チャネル・パケット内のＵＡＴＩからＳｏｕｒｃｅ ＲＮＣのＩＰアドレスを得て、Ａ１３の要求メッセージをそのＳｏｕｒｃｅ ＲＮＣへ送信する。ＡＴのセッション情報をＳｏｕｒｃｅ ＲＮＣから受信した後に、Ｔａｒｇｅｔ ＲＮＣは、そのＡＴに新たなＵＡＴＩを割り当て、Ａ１３のハンドオフを完了し、そして受信したアクセス・チャネル・メッセージを処理する。たとえば、そのアクセス・チャネル・メッセージがＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージであった場合には、Ｔａｒｇｅｔ ＲＮＣは、含まれるＲＮに対するトラフィック・チャネル区間をセットアップし、Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ Ａｓｓｉｇｎｍｅｎｔメッセージを送信する。ＡＴ内でタイマが切れる前にＴＣＡメッセージを送信するためには、Ｔａｒｇｅｔ ＲＮＣがＡ１３のハンドオフの手続きを時間内に完了することが重要である。

このセクションで説明した方法は、ＲＮＣの機能とＲＮの機能が、同じ基地局内で同一の場所に配置されている、すなわち統合されている分散されたＩＰベースの無線ネットワークにおいて使用することもできる。

部分的に接続された無線ネットワークにおけるアクティブなハンドオフ
ＩＰベースの無線アクセス・ネットワークにおいては、ＲＮＣが、ネットワーク内のすべてのＲＮとの関連付けを有さないことも可能である。したがってサービス提供側ＲＮＣは、１つのＡＴ（ａｃｃｅｓｓ ｔｅｒｍｉｎａｌ）のために１つのトラフィック・チャネルを無期限に保持することはできない。ＡＴは、サービス提供側ＲＮＣとの関連付けを有していないＲＮのサービス・エリア内へ移動した場合には、自分のサービス提供側ＲＮＣへの無線接続を徐々に失うことになる。接続が失われると、ＡＴは、上述のアクティビティによって引き起こされる休眠中のハンドオフの手続きを開始して、新たな接続を再び確立しようと試みる。関連付けの欠如によって引き起こされる中断を少なくするための１つの方法は、サービス提供側ＲＮＣが、自分が接続を有していないセクタによってＡＴにさらに良好にサービスを提供することができるということを認識すると、ＡＴが接続を閉じることを決定するまでに長い時間を要する可能性を回避するために、すぐに接続を閉じるという方法である。サービス提供側ＲＮＣによるこのような事前対処的な行動によって、いわゆる「無線周波数を引きずる問題」（ＲＦ ｄｒａｇｇｉｎｇ ｐｒｏｂｌｅｍ）を回避することができる。

上述の接続の中断を完全に防止するために、サービス提供側ＲＮＣから、ＡＴの現在位置の付近にあるＲＮとの関連付けを有する別のＲＮＣへハンドオフを実行することができる。

ＡＴは、１つのＲＮのサービス・エリアから別のＲＮのサービス・エリアへ移動する際に、ＲｏｕｔｅＵｐｄａｔｅメッセージを自分のサービス提供側ＲＮＣへ送信し、そのサービス提供側ＲＮＣは、このＲｏｕｔｅＵｐｄａｔｅメッセージを使用して、通常のソフト・ハンドオフを実行する。これらのＲｏｕｔｅＵｐｄａｔｅメッセージを通じて、サービス提供側ＲＮＣは、ＡＴがどこに位置しているかに関するかなり正確な見積もりを得て、この情報を使用して、下記のようにアクティブなＲＮＣのハンドオフを引き起こすことができる。

それぞれのＲＮＣは、それぞれの本拠とされているＲＮの第１のＲＮＣを示すテーブルを伴って構成することができる。ＲＮＣは、アクティブなハンドオフを引き起こすことを決定した場合には、ＨａｎｄｏｆｆＲｅｑｕｅｓｔメッセージをサービス提供側ＲＮの第１のＲＮＣへ送信して、ハンドオフを開始することができる。アクティブなハンドオフのためのＴａｒｇｅｔ ＲＮＣを選択する上で、その他の方法を工夫することもできる。

アクティブなハンドオフにおいては、アクティブな呼び出しの状態も、Ｓｏｕｒｃｅ ＲＮＣからＴａｒｇｅｔ ＲＮＣへ転送する必要があるため、アクティブなハンドオフは、休眠中のハンドオフよりも実施する上でさらに複雑である。また、ＲＬＰ（Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ）が使用されている場合には、そのＲＬＰの処理をＳｏｕｒｃｅ ＲＮＣからＴａｒｇｅｔ ＲＮＣへ最小限の中断で移動させることが重要となる。アクティブなハンドオフを実施する別の方法も存在する。たとえば、古いＲＮＣを介して既存のＲＬＰリンクを中断する前に、新たなＲＮＣを介して新たなＲＬＰリンクを確立することができる。これによってＡＴは、ハンドオフが進行している間に、Ｓｏｕｒｃｅ ＲＮＣを介して受信を継続することができる。ハンドオフが完了すると、Ｓｏｕｒｃｅ ＲＮＣへのＲＬＰリンクを終了することができ、すべてのパケットは、Ｔａｒｇｅｔ ＲＮＣを介して流れることができる。３ＧＰＰ２は、このようなアクティブなハンドオフを実施するための現在標準化されているプロトコルであり、別々のベンダのＲＮＣ機器どうしの間で相互運用を可能にする。

このセクションで説明した方法は、ＲＮＣの機能とＲＮの機能とが、同じ基地局内で同一の場所に配置されている、すなわち統合されている分散されたＩＰベースの無線ネットワークにおいて使用することもできる。

ＩＰベースのネットワーク内における複数搬送波のオペレーション
ＩＰベースの無線アクセス・ネットワークの別の利点は、大容量の複数搬送波（複数の周波数チャネル）の展開の中にある。厳密なＲＮＣの境界を有する従来のシステムにおいては、新たな搬送波を追加すると、第１の搬送波上のＲＮＣによってサービスを提供されているＲＮを分割し、それによって同じＲＮＣが、第２の搬送波上の同一の場所に配置されているＲＮの新たなセットにサービスを提供できるようにすることが必要となる可能性がある。同じＲＮＣが、同一の場所に配置されている搬送波にサービスを提供することは、必ず適切な複数搬送波の負荷バランシング・アルゴリズムを適用できるようにする上で、従来のシステムにおいては決定的に重要な要件である。ユーザの経験全体を最大化するために、複数搬送波の負荷バランシングを使用して、利用可能な搬送波の全体にわたってトラフィック・チャネルの負荷を公平に分配する。負荷バランシングを使用すると、パケット・データ・ユーザの経験が改善され、音声ユーザにとっては、閉塞率が最小限に抑えられる。結果として、新たな搬送波が追加される場合には、第２の搬送波上のＲＮのための余地を作るために、第１の搬送波上のＲＮのうちのいくつかをそれらのサービス提供側ＲＮＣから除外することが必要となる。これによって、不必要なサービスの途絶が生じる。

ＩＰベースの無線アクセス・ネットワークにおいては、１つのＲＮＣは、ＲＮのより大きなセットとの関連付けを保持することができるため、第１の搬送波上の既存のＲＮのうちのいずれも、それらの（１つまたは複数の）ＲＮＣから除外する必要はない。それどころか、第２のＲＮＣを追加し、すべての既存のＲＮをそれに関連付け、その一方で、それらの第１のＲＮＣとの関連付けを依然として保持することができる。これによって、いかなるサービスの途絶も回避される。さらに多くのＲＮが第２の搬送波上に追加されるにつれて、これらは、第１および第２の双方のＲＮＣとの関連付けを確立する。

ＡＴが新たなセッションを要求した場合には、サービス提供側ＲＮは、何らかのＲＮＣ間での負荷バランシング・メカニズムに基づいて、２つのＲＮＣのうちのいずれか一方へそのセッション要求を転送することができ、あるいはそのセッションをデフォルトのＲＮＣへ転送することもできる。そしてこのＲＮＣが、そのセッションにとってのサービス提供側ＲＮＣとなり、ＡＴがＲＮＣクラスタ全体の電波到達範囲内に留まっている限り、そのＡＴがどの搬送波をモニタしているかにかかわらず、そのＡＴにサービスを提供する。また、トラフィック・チャネルが確立された時点で、サービス提供側ＲＮＣは、利用可能な搬送波のうちのいずれか１つの上で機能する１組のＲＮにＡＴを割り当てることができる。ＲＮが、自分が関連付けられているすべてのＲＮＣに自分の負荷情報を提供するのであれば、搬送波の全体にわたって負荷のバランスを取るために、このようなトラフィック・チャネルの割り当てを実施することができる。すべての搬送波上のすべてのＲＮは、同じ１ｘＥＶ−ＤＯサブネット上で機能することができるため、ＡＴが、自分がモニタしている搬送波を変更するときに、ＲＮＣ間での休眠中のハンドオフは必要とされない。

あるいは、第１／第２の関連付けを有するＩＰベースの無線アクセス・ネットワークにおいては、第１の搬送波上で機能しているＲＮは、第１のＲＮＣを自分の第１のＲＮＣとして使用し、その一方で第２の搬送波上で機能しているＲＮは、第２のＲＮＣを自分の第１のＲＮＣとして使用する。同時に、すべてのＲＮは、その他のＲＮＣとの第２の関連付けも有する。この場合には、新たなセッション要求が第１の搬送波上に着信すると、サービス提供側ＲＮは、そのセッション要求を自分の第１のＲＮＣへ転送し、そしてその第１のＲＮＣが、サービス提供側ＲＮＣとなる。あるいは、新たなセッション要求が第２の搬送波上に着信すると、サービス提供側ＲＮは、そのセッション要求を自分の第２のＲＮＣへ転送し、その第２のＲＮＣが、サービス提供側ＲＮＣとなる。この場合もやはり、いずれのＲＮＣも、搬送波の全体にわたってトラフィックの負荷のバランスを取るために、搬送波のうちのいずれか１つの上のトラフィック・チャネルに１つのＡＴを割り当てることができる。やはりこれによって、ＲＮが、自分の負荷情報をすべてＲＮＣに、すなわち第１および第２の双方のＲＮＣに提供することが必要となる。第１／第２の関連付けを有するＩＰベースの無線アクセス・ネットワークの唯一の欠点は、もしもＡＴが、自分がモニタしている搬送波を変更したならば、ＲＮＣ間での休眠中のハンドオフを実行しなければならないという点である。ＡＴは、たとえば自分のサービス提供側ＲＮＣによって送信先を変更された後に、自分がモニタしている搬送波を変更する可能性がある。このような送信先の変更は、たとえば、ＡＴにサービスを提供する上でより良好に整備されている搬送波へＡＴを導くために発生する可能性がある。ミックスト・リビジョン・ネットワークにおいては、１つの搬送波が、１ｘＥＶ−ＤＯ標準のいわゆるＲｅｖｉｓｉｏｎ ０をサポートし、その一方で第２の搬送波が、いわゆるＲｅｖｉｓｉｏｎ Ａをサポートし、このネットワークは、Ｒｅｖ Ａユーザの送信先をＲｅｖ ０搬送波からＲｅｖ Ａ搬送波へ変更することができる。このような送信先の変更は、搬送波の受信可能範囲が途切れる可能性がある場合に、あるいはＲＮの障害の場合に、搬送波の境界において発生する可能性もある。ＡＴは、第１の搬送波上における所与のＲＮへのＲＦリンクを失った場合には、第２の搬送波上の同一の場所に配置されているＲＮに接続することができる。この場合もやはり、このような搬送波間でのハンドオフを実行する上で、ＲＮＣ間での休眠中のハンドオフが必要とされる。

このセクションで説明した方法は、ＲＮＣの機能とＲＮの機能とが、同じ基地局内で同一の場所に配置されている、すなわち統合されている分散されたＩＰベースの無線ネットワークにおいて使用することもできる。

境界のセルの呼び出し
ＩＰベースの無線ネットワークにおいては、大きなクラスタを形成することによって、ハンドオフの境界を大幅に減らすことができる。しかし大きなクラスタを形成しても、ハンドオフを完全になくすことはできない。休眠中のハンドオフにおいてしばしば見受けられるよく知られている問題は、休眠中のハンドオフの間に呼び出しデータが失われることである。休眠中のＲＮＣ間でのハンドオフにおいては、ＡＴは、一度に１つのセクタのみをモニタしていることになる。ＡＴが、サービス提供側ＲＮＣによって連絡を取ることができないセクタのモニタリングを開始した瞬間に、そのサービス提供側ＲＮＣは、もはやそのＡＴを呼び出すことはできない。ＡＴは、そのセッションが新たなＲＮＣへ転送された後に再び呼び出しが可能となり、そしてＰＤＳＮは、ＡＴパケットを新たなＲＮＣへ転送する。呼び出しデータが失われるのを防止するために、サービス提供側ＲＮＣは、Ａ１３の休眠中のハンドオフ中に自分が新たなＲＮＣへ送信するセッション情報内に、いかなる未着信の呼び出しデータも含めることができる。サービス提供側ＲＮＣは、Ａ１３の休眠中のハンドオフが完了すると、次いでＡＴを呼び出すことができる。これによって、ＡＴは、休眠中のＲＮＣ間における呼び出し手続きの間に必ず呼び出し可能なままとなる。

本発明の複数の実施形態について説明した。しかしながら、本発明の趣旨および範囲から逸脱することなくさまざまな修正を行うことができ、したがってその他の実施形態も、添付の特許請求の範囲内であるということが理解できるであろう。

ネットワークを示す図である。 ネットワークを示す図である。 ネットワークを示す図である。 ネットワークを示す図である。

Claims (65)

1. 第１の無線ネットワーク・コントローラ及び第２の無線ネットワーク・コントローラと、第１の無線ノード及び第２の無線ノードとを含む無線ネットワークに関連して実行される方法であって、
   該第１の無線ノードを介して該第１の無線ネットワーク・コントローラ上の第１のアクセス端末のための第１のセッションを確立するステップと、
   該第２の無線ノードを介して該第２の無線ネットワーク・コントローラ上の第２のアクセス端末のための第２のセッションを確立するステップと、
   該第１の無線ノードを使用して、且つ、複数の第１のパケットを該第２の無線ネットワーク・コントローラを通過させることなく、該第１のアクセス端末と該第１の無線ネットワーク・コントローラとの間で第１のトラフィック・チャネルを介して該複数の第１のパケットを通信するステップと、
   該第１のアクセス端末が該第１の無線ノードのサービス・エリアから該第２の無線ノードのサービス・エリアへ移動する際に、該第１のトラフィック・チャネルを保持するステップと、
   該第１のアクセス端末が該第２の無線ノードのサービス・エリアのいずれかの部分でアクティブな状態にとどまっている間に、該第２の無線ノードを使用して、且つ、複数の第２のパケットを該第２の無線ネットワーク・コントローラを通過させることなく、該第１のアクセス端末と該第１の無線ネットワーク・コントローラの間で該第１のトラフィック・チャネルを介して複数の第２のパケットを通信するステップと、
   該第１のアクセス端末が、該第２の無線ノードのサービス・エリア内のいずれかの部分で休眠中の状態にある場合に、該第２の無線ネットワーク・コントローラ上の該第１のアクセス端末のための新たなセッションを確立するか、又は該第１の無線ネットワーク・コントローラから該第２の無線ネットワーク・コントローラへＲＮＣ間での休眠中のハンドオフを実行するステップとを含む方法。
2. 請求項１に記載の方法において、
   該第２の無線ノードと該第２の無線ネットワーク・コントローラとの間における第１の関連付けを確立するステップと、該第２の無線ノードと該第１の無線ネットワーク・コントローラとの間における第２の関連付けを確立するステップとをさらに含む方法。
3. 請求項２に記載の方法において、
   該第１の関連付けを確立するステップが、ＰＮオフセット及びＩＰアドレスの情報を該第２の無線ノードから該第２の無線ネットワーク・コントローラに渡すステップを含み、
   該第２の関連付けを確立するステップが、ＰＮオフセット及びＩＰアドレスの情報を該第２の無線ノードから該第１の無線ネットワーク・コントローラに渡すステップを含む方法。
4. 請求項１又は２に記載の方法において、
   該第１の無線ノードによって、第１のサブネット識別子を放送するステップと、
   該第２の無線ノードによって、該第１のサブネット識別子とは異なる第２のサブネット識別子を放送するステップと、
   該第１のアクセス端末によって、該休眠中の状態にある間に該サブネット識別子をモニタするステップと、
   該サブネット識別子における変化を検知すると、該新たなセッションの確立、又は該第１の無線ネットワーク・コントローラから該第２の無線ネットワーク・コントローラへの該休眠中のＲＮＣ間でのハンドオフを引き起こすステップとをさらに含む方法。
5. 請求項４に記載の方法において、
   それぞれの無線ノードをそのそれぞれのサブネット識別子と共に個々に構成するステップをさらに含む方法。
6. 請求項４に記載の方法において、
   該第２又は第３の無線ノードが、自分が第１の関連付けを確立している該それぞれの無線ネットワーク・コントローラから自分のサブネット識別子を得るステップをさらに含む方法。
7. 請求項４に記載の方法において、
   引き起こすステップが、該第１のアクセス端末によってＵＡＴＩ Ｒｅｑｕｅｓｔメッセージを送信することによって、該新たなセッションの確立、又は該第１の無線ネットワーク・コントローラから該第２の無線ネットワーク・コントローラへの該休眠中のＲＮＣ間でのハンドオフを引き起こすステップを含む方法。
8. 請求項７に記載の方法において、
   それぞれの無線ノードをそのそれぞれのサブネット識別子と共に個々に構成するステップをさらに含む方法。
9. 請求項７に記載の方法において、
   該第２又は第３の無線ノードが、自分が第１の関連付けを確立している該それぞれの無線ネットワーク・コントローラから自分のサブネット識別子を得るステップをさらに含む方法。
10. 請求項４に記載の方法において、
    第３の無線ノードと該第１の無線ネットワーク・コントローラとの間における第１の関連付けを確立するステップと、
    該第３の無線ノードと該第２の無線ネットワーク・コントローラとの間における第２の関連付けを確立するステップと、
    該第３の無線ノードによって、該第１及び第２の無線ノードに関連付けられている第１及び第２のサブネット識別子とは異なる第３のサブネット識別子を放送するステップと、
    該第１のアクセス端末が、該第１の無線ノードのサービス・エリアから該第３の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、該第１の無線ネットワーク・コントローラが、新たなＵＡＴＩを該第１のアクセス端末に割り当てるステップと、
    該サブネット識別子における変化を検知すると、ＵＡＴＩ Ｒｅｑｕｅｓｔメッセージを送信することによって、該新たなＵＡＴＩの割り当てを引き起こすステップとをさらに含む方法。
11. 請求項１０に記載の方法において、
    それぞれの無線ノードをそのそれぞれのサブネット識別子と共に個々に構成するステップをさらに含む方法。
12. 請求項１０に記載の方法において、
    該第２又は第３の無線ノードが、自分が第１の関連付けを確立している該それぞれの無線ネットワーク・コントローラから自分のサブネット識別子を得るステップをさらに含む方法。
13. 請求項２に記載の方法において、
    １つ又は複数の無線ネットワーク・コントローラによってサービスを提供されているセッションに関するセッション情報を保存するためのＲＮＣリソース・コントロール・エージェントを採用するステップをさらに含む方法。
14. 請求項７に記載の方法において、
    該ＲＮＣリソース・コントロール・エージェントによって、無線ネットワーク・コントローラの障害を検知するステップと、
    無線ネットワーク・コントローラの該障害を検知すると、ユーザ・セッションを残りの無線ネットワーク・コントローラに割り当て直すステップと、セッション情報をこれらの残りの無線ネットワーク・コントローラに渡すステップとをさらに含む方法。
15. 請求項１又は２に記載の方法において、
    複数のサーバ・カードを有するシャーシベースのハードウェア・プラットフォームを採用して、該無線ネットワーク・コントローラのそれぞれを実装するステップをさらに含む方法。
16. 請求項１５に記載の方法において、
    該第１の無線ネットワーク・コントローラ上の該サーバ・カードのうちの１つを本拠とすることによって、該第２の無線ノードと該第１の無線ネットワーク・コントローラとの間に関連付けを確立するステップと、
    該第２の無線ネットワーク・コントローラ上の該サーバ・カードのうちの１つを本拠とすることによって、該第２の無線ノードと該第２の無線ネットワーク・コントローラとの間に関連付けを確立するステップとをさらに含む方法。
17. 請求項１６に記載の方法において、
    該関連付けを確立するステップが、該第２の無線ノードから、該第２の無線ノードが本拠とされている該サーバ・カードへＰＮオフセット情報を渡すステップを含む方法であって、
    該ＰＮオフセット情報を受信している該サーバ・カードから該シャーシベースのハードウェア・プラットフォーム内のその他のサーバ・カードへ該ＰＮオフセット情報を配信するステップをさらに含む方法。
18. 請求項１６に記載の方法において、
    それぞれの無線ノードと、該無線ネットワーク・コントローラ内でそれぞれの無線ノードが本拠とされている該サーバ・カードとの間で信号を伝達するためにトランスポート層接続を確立するステップをさらに含む方法。
19. 請求項１８に記載の方法において、
    該関連付けを確立するステップが、該第２の無線ノードから、該第２の無線ノードが本拠とされている該サーバ・カードへＰＮオフセット情報を渡すステップを含む方法であって、
    該ＰＮオフセット情報を受信している該サーバ・カードから該シャーシベースのハードウェア・プラットフォーム内のその他のサーバ・カードへ該ＰＮオフセット情報を配信するステップをさらに含む方法。
20. 請求項１に記載の方法において、
    該ＲＮＣ間でのハンドオフの手続きが、１ｘＥＶ−ＤＯ ＩＯＳ仕様のＡ１３インターフェースに準拠する方法。
21. 請求項１に記載の方法において、該無線ネットワーク・コントローラがＰＤＳＮ機能を含む方法。
22. 請求項１に記載の方法において、
    該第１の無線ネットワーク・コントローラ及び該第１の無線ノードが、同一の場所に配置されており、該第２の無線ネットワーク・コントローラ及び該第２の無線ノードが、同一の場所に配置されている方法。
23. 情報搬送波内において具体化され、第１の無線ネットワーク・コントローラ及び第２の無線ネットワーク・コントローラと、第１の無線ノード及び第２の無線ノードとを含む無線ネットワーク内で機能するように適合されているコンピュータ・プログラムであって、
    該第１の無線ノードを介して該第１の無線ネットワーク・コントローラ上の第１のアクセス端末のための第１のセッションを確立するステップと、
    該第２の無線ノードを介して該第２の無線ネットワーク・コントローラ上の第２のアクセス端末のための第２のセッションを確立するステップと、
    該第１のアクセス端末と該第１の無線ネットワーク・コントローラとの間に第１のトラフィック・チャネルを確立するステップと、
    複数の第１のパケットを該第２の無線ネットワーク・コントローラを通過させることなく、該第１の無線ノードと該第１の無線ネットワーク・コントローラとの間で該第１のトラフィック・チャネルを介して該複数の第１のパケットを通信するステップと、
    該第１のアクセス端末が該第１の無線ノードのサービス・エリアから該第２の無線ノードのサービス・エリアへ移動する際に、該第１のトラフィック・チャネルを保持するステップと、
    該第１のアクセス端末が該第２の無線ノードのサービス・エリアのいずれかの部分でアクティブな状態にとどまっている間に、該第２の無線ノードを使用して、且つ、複数の第２のパケットを別の無線ネットワーク・コントローラを通過させることなく、該第１のアクセス端末と該第１の無線ネットワーク・コントローラとの間で該第１のトラフィック・チャネルを介して複数の第２のパケットを通信するステップとをデータ処理装置に実行させるように機能する命令を含むコンピュータ・プログラム。
24. 請求項２３に記載のコンピュータ・プログラムにおいて、
    該命令が、
    該第１のアクセス端末が、該第１の無線ノードのサービス・エリアから該第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、該第２の無線ネットワーク・コントローラ上の該第１のモバイル・アクセス端末のための新たなセッションを確立するか、又は該第１の無線ネットワーク・コントローラから該第２の無線ネットワーク・コントローラへＲＮＣ間での休眠中のハンドオフを実行するステップを該データ処理装置に実行させるようにさらに機能するコンピュータ・プログラム。
25. 無線ネットワークであって、
    第１の無線ネットワーク・コントローラと、
    第２の無線ネットワーク・コントローラと、
    第１の無線ノードと、
    第２の無線ノードと、
    該第１の無線ノードを介して該第１の無線ネットワーク・コントローラ上に確立されている第１のセッションと、該第１の無線ネットワーク・コントローラによって確立されている第１のトラフィック・チャネルとに関連付けられている第１のモバイル・アクセス端末であって、複数の第１のパケットを該第２の無線ネットワーク・コントローラを通過させることなく、該第１の無線ノードと該第１の無線ネットワーク・コントローラとの間で該第１のトラフィック・チャネルを介して該複数の第１のパケットを通信する第１のモバイル・アクセス端末と、
    該第２の無線ノードを介して該第２の無線ネットワーク・コントローラ上に確立されている第２のセッションに関連付けられている第２のモバイル・アクセス端末とを含み、
    該第１のアクセス端末が該第１の無線ノードのサービス・エリアから該第２の無線ノードのサービス・エリアへ移動する際に、該第１のトラフィック・チャネルが保持され、
    該第１のアクセス端末が該第２の無線ノードのサービス・エリアのいずれかの部分でアクティブな状態にとどまっている間に、該第２の無線ノードを使用して、且つ、複数の第２のパケットを該第２の無線ネットワーク・コントローラを通過させることなく、該複数の第２のパケットが、該第１のアクセス端末と該第１のネットワーク・コントローラとの間で通信される無線ネットワーク。
26. 請求項２５に記載の無線ネットワークにおいて、
    該第１のアクセス端末が、該第１の無線ノードのサービス・エリアから該第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、該第２の無線ネットワーク・コントローラ上の該第１のモバイル・アクセス端末のための新たなセッションが確立されるか、又は該第１の無線ネットワーク・コントローラから該第２の無線ネットワーク・コントローラへのＲＮＣ間での休眠中のハンドオフが実行される無線ネットワーク。
27. 無線ネットワーク内でモバイル・アクセス端末を使用してデジタル情報をやり取りする方法であって、
    複数のパケットを第２の無線ネットワーク・コントローラ通過させることなく、第１の無線ノードを介して、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に確立された第１のトラフィック・チャネルを介して該複数のパケットを送信するステップであって、該第１の無線ネットワーク・コントローラと該第２の無線ネットワーク・コントローラは、それぞれ、第１のサーバ・カードと第２のサーバ・カードとを含んでおり、該第１のサーバ・カードは、該第１の無線ノードと該第１の無線ネットワーク・コントローラとの間でシグナリングを実行するように構成されているステップと、
    複数のパケットを該第１の無線ネットワーク・コントローラを通過させることなく、第２の無線ノードを介して、第２のモバイル・アクセス端末と第２の無線ネットワーク・コントローラとの間に確立された第２のトラフィック・チャネルを介して該複数のパケットを送信するステップであって、該第２のサーバ・カードは、該第２の無線ノードと該第２の無線ネットワーク・コントローラとの間のシグナリングを実行するように構成されているステップと、
    複数のパケットが、該第２の無線ノードを介して該第１のトラフィック・チャネル上で、該第１のモバイル・アクセス端末に送信され又は該第１のモバイル・アクセス端末から受信されるように、該第１のアクセス端末と該第１の無線ネットワーク・コントローラとの間における該第１のトラフィック・チャネルを保持するステップと、
    該第１のモバイル・アクセス端末から受信したパケットを外部のネットワークへ送信するステップと、
    該第１のサーバ・カードの過負荷の状態を検出するステップと、
    該第１のサーバ・カードの過負荷の状態を検出した場合に、ターゲット・サーバ・カードへの転送のために、該第１のサーバ・カード上でサービスを提供されているトラフィック・チャネルを選択するステップであって、該第１のサーバ・カードが、中央集権化されたロード・トラッカーによって提供される１つ又は複数のターゲット・サーバ・カードのリストから該ターゲット・サーバ・カードを選択するステップと、
    該選択されたトラフィック・チャネルを中断することなく、該選択されたトラフィック・チャネルを該第１の無線ネットワーク・コントローラ及び該第２の無線ネットワーク・コントローラのうちの１つの中の該ターゲット・サーバ・カードへ転送するステップとを含む方法。
28. 請求項２７に記載の方法において、
    該第１のアクセス端末が第３の無線ノードの付近にあることを検知すると、該第１の無線ネットワーク・コントローラから該第２の無線ネットワーク・コントローラへ該第１のトラフィック・チャネルのアクティブなハンドオフを実行するステップをさらに含む方法。
29. 請求項２７に記載の方法において、
    該第１のアクセス端末が第３の無線ノードの付近にあることを検知すると、該第１の無線ネットワーク・コントローラによって該第１のトラフィック・チャネルを閉じるステップをさらに含む方法。
30. 請求項２７に記載の方法において、
    該第１の無線ノードを介して該第１の無線ネットワーク・コントローラ上の第３のモバイル・アクセス端末のための第１のセッションを確立するステップと、
    該アクセス端末によって送信される位置更新メッセージに基づいて該第３のアクセス端末の大まかな位置を追跡把握するステップと、
    該第３のアクセス端末が休眠中の状態にある間に、該第１の無線ネットワーク・コントローラにおいて該第３のアクセス端末のためのパケットを受信するステップと、
    該第２の無線コントローラが該第３のアクセス端末を呼び出すことを要求するメッセージを該第２の無線コントローラへ送信するステップと、
    第３の無線ノードを介して該第２の無線ネットワーク・コントローラから該アクセス端末を呼び出すステップとをさらに含む方法。
31. 請求項３０に記載の方法において、
    該第３の無線ノードにおいて、アクセス・チャネルを介して該第３のモバイル・アクセス端末からトラフィック・チャネル要求メッセージを受信するステップと、
    該第３の無線ノードから該第２の無線ネットワーク・コントローラへ該トラフィック・チャネル要求メッセージを転送するステップと、
    該第１の無線ネットワーク・コントローラから該第２の無線ネットワーク・コントローラへの該第１のセッションのハンドオフを実行するステップと、
    該ハンドオフが完了した後に、該第２の無線ネットワーク・コントローラと該第３のアクセス端末との間にトラフィック・チャネルを確立するステップとをさらに含む方法。
32. 請求項２７に記載の方法において、
    該第１の無線ネットワーク・コントローラが複数のサーバ・カードを含む方法であって、
    該複数のサーバ・カードから選択されたサーバ・カードのうちの１つの上で該無線ネットワーク・コントローラと該第１のモバイル・アクセス端末との間に該第１のトラフィック・チャネルを確立するステップと、
    該選択されたサーバ・カードのアドレスを該無線ネットワーク・コントローラから該第１の無線ノードへ送信するステップと、
    リバース・リンクのトラフィック・チャネル・パケットを該第１の無線ノードから該選択されたサーバ・カードの該アドレスへ送信するステップと、
    該選択されたサーバ・カードの該アドレスを該第１の無線ネットワーク・コントローラから該第２の無線ノードへ送信するステップと、
    リバース・リンクのトラフィック・チャネル・パケットを該第２の無線ノードから該選択されたサーバ・カードの該アドレスへ送信するステップとをさらに含む方法。
33. 請求項２７に記載の方法において、
    該第１の無線ノードが、第１の周波数チャネル上で機能し、該第２の無線ノードが、該第１の無線ノードと同一の場所に配置されて、第２の周波数チャネル上で機能する方法。
34. 請求項３３に記載の方法において、
    該第１の周波数チャネル上で機能する該第１の無線ノードを介して該第１の無線ネットワーク・コントローラ上の該第１のモバイル・アクセス端末のための第１のセッションを確立するステップと、
    該第２の周波数チャネル上で機能する該第２の無線ノードを介して該第２の無線ネットワーク・コントローラ上の該第２のモバイル・アクセス端末のための第２のセッションを確立するステップと、
    該第２の周波数チャネル上で機能する該第２の無線ノードを介して該第１の無線ネットワーク・コントローラ上の該第３のモバイル・アクセス端末のための第３のセッションを確立するステップとをさらに含む方法。
35. 請求項３３に記載の方法において、
    該第１の周波数チャネル上で機能する該第１の無線ノードと該第１の無線ネットワーク・コントローラとの間における第１の関連付けを確立するステップと、
    該第２の周波数チャネル上で機能する該第２の無線ノードと該第１の無線ネットワーク・コントローラとの間における第２の関連付けを確立するステップと、
    該第１の周波数チャネル上で機能する該第１の無線ノードを介して該第１の無線ネットワーク・コントローラ上の該第１のモバイル・アクセス端末のための第１のセッションを確立するステップと、
    アクセス端末が、休眠中のモードにある該第２の無線ノードのモニタリングを開始した場合は常に、該第１のセッションを該第２の無線ネットワーク・コントローラへ転送するステップとをさらに含む方法。
36. 請求項３３に記載の方法において、
    該第１の周波数チャネル上で機能する該第１の無線ノードを介して該第１の無線ネットワーク・コントローラにおいて該第１のモバイル・アクセス端末からの接続要求を受信するステップと、
    該第１の無線ネットワーク・コントローラ上の該第１のアクセス端末のための第３のトラフィック・チャネルを確立するステップであって、該トラフィック・チャネルが、該第２の周波数チャネル上で機能する該第２の無線ノードを介して流れるステップとをさらに含む方法。
37. 請求項３６に記載の方法において、
    該第１の無線ネットワーク・コントローラによって該第１及び第２の無線ノードから受信される実際の負荷の情報に基づいて該第２の周波数チャネル上で機能する該第２の無線ノードを介して流れる該第３のトラフィック・チャネルを確立するステップをさらに含む方法。
38. 請求項３６に記載の方法において、
    該第１及び第２の無線ノード上の負荷の見積もりに基づいて該第２の周波数チャネル上で機能する該第２の無線ノードを介して流れる第３のトラフィック・チャネルを確立するステップをさらに含む方法。
39. 無線ネットワーク内でモバイル・アクセス端末を使用してデジタル情報をやり取りする方法であって、
    複数のパケットを第２の無線ネットワーク・コントローラ通過させることなく、第１の無線ノードを介して、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に確立された第１のトラフィック・チャネルを介して該複数のパケットを送信するステップと、
    複数のパケットを該第１の無線ネットワーク・コントローラを通過させることなく、第２の無線ノードを介して、第２のモバイル・アクセス端末と第２の無線ネットワーク・コントローラとの間に確立された第２のトラフィック・チャネルを介して該複数のパケットを送信するステップと、
    複数のパケットが、該第２の無線ノードを介して該第１のトラフィック・チャネル上で、該第１のモバイル・アクセス端末に送信され又は該第１のモバイル・アクセス端末から受信されるように、該第１のアクセス端末と該第１の無線ネットワーク・コントローラとの間における該第１のトラフィック・チャネルを保持するステップと、
    該第１のモバイル・アクセス端末から受信したパケットを外部のネットワークへ送信するステップとを含み、
    該第１の無線ネットワーク・コントローラと該第２の無線ネットワーク・コントローラは、それぞれ、第１のサーバ・カードと第２のサーバ・カードとを含んでおり、該第１のサーバ・カードは、該第１の無線ノードと該第１の無線ネットワーク・コントローラとの間でシグナリングを実行するように構成され、該第２のサーバ・カードは、該第２の無線ノードと該第２の無線ネットワーク・コントローラとの間のシグナリングを実行するように構成されており、
    該第１の無線ネットワーク・コントローラ内の第１のサーバ・カード上の複数のトラフィック・チャネルを処理するステップと、
    該第１のサーバ・カードにおける過負荷の状況を検知するステップと、
    該第１のサーバ・カードにおける過負荷の状況を検知した場合に、ターゲット・サーバ・カードへ転送するために、該第１のサーバ・カード上でサービスを提供されているトラフィック・チャネルを選択するステップであって、該第１のサーバ・カードが、中央集権化されたロード・トラッカーによって提供される１つ又は複数のターゲット・サーバ・カードのリストから該ターゲット・サーバ・カードを選択するステップと、
    該選択されたトラフィック・チャネルを中断することなく、該選択されたトラフィック・チャネルを該無線ネットワーク・コントローラのうちの１つの中の別のサーバ・カードへ転送するステップとをさらに含む方法。
40. 請求項３９に記載の方法において、
    転送するために該トラフィック・チャネルを選択するステップが、該選択されたトラフィック・チャネルによって使用されている処理中のリソースの量に少なくとも部分的に基づく方法。
41. 請求項３９に記載の方法において、
    転送するために該トラフィック・チャネルを選択するステップが、該複数のトラフィック・チャネル上の該トラフィックのサービスの質の要件に少なくとも部分的に基づく方法。
42. 請求項３９に記載の方法において、
    該無線ネットワーク・コントローラ内のその他のカードの負荷及び利用可能度に少なくとも部分的に基づいて、該選択されたトラフィック・チャネルの転送先となるターゲット・サーバ・カードを決定するステップをさらに含む方法。
43. 請求項４２に記載の方法において、
    サーバ・カードの負荷に関する情報が、中央集権化されたロード・トラッカーによって提供される方法。
44. 請求項３９に記載の方法において、
    該中央集権化されたロード・トラッカーが、無線ネットワーク・コントローラ内に配置されている方法。
45. 請求項３９に記載の方法において、
    該中央集権化されたロード・トラッカーが、すべての無線ネットワーク・コントローラに対して外部にある方法。
46. 請求項４３に記載の方法において、
    該中央集権化されたロード・トラッカーが、該第１のサーバ・カードから該ターゲット・サーバ・カードへのトラフィック・チャネルの転送を引き起こすように構成されている方法。
47. 請求項４１に記載の方法において、負荷の情報が、該第１のサーバ・カードによって直接その他のサーバ・カードから得られる方法。
48. 請求項３０に記載の方法において、該第３の無線ノード及び該第１の無線ノードが、別々のサブネットワークに属する方法。
49. 請求項２７に記載の方法において、
    Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌネットワークを使用して、該第１の無線ネットワーク・コントローラと該第１及び第２の無線ノードとの間でデータ・パケットをやり取りするステップをさらに含む方法。
50. 請求項２７に記載の方法において、該第１の無線ネットワーク・コントローラが、パケット・データ・スイッチング・ノードとして機能するように構成されている方法。
51. 請求項２７に記載の方法において、該第１及び第２の無線ネットワーク・コントローラが、該第１及び第２の無線ノードと同一の場所に配置されている方法。
52. 請求項２７に記載の方法において、該外部のネットワークが、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌネットワークを含む方法。
53. モバイル・アクセス端末と無線通信するための無線アクセス・ネットワークであって、
    ネットワークを使用して複数の無線ネットワーク・コントローラと相互接続されている複数の無線ノードを含み、該複数の無線ネットワーク・コントローラは、それぞれ、サーバ・カードを含み、該サーバ・カードは、
    第１のサーバ・カードにおける過負荷の状況を検知し、
    該第１のサーバ・カードにおける過負荷の状況を検知した場合に、ターゲット・サーバ・カードへ転送するために、該第１のサーバ・カード上でサービスを提供されているトラフィック・チャネルを選択し、
    該選択されたトラフィック・チャネルを中断することなく、該選択されたトラフィック・チャネルを該複数の無線ネットワーク・コントローラのうちの１つの中の該ターゲット・サーバ・カードへ転送し、
    該複数無線ノードのうちの１つ又はそれ以上の無線ノードと、該サーバ・カードを含むそれぞれの無線ネットワーク・コントローラとの間でシグナリングを実行するように構成され、該複数の無線ノードは、該複数の無線ネットワーク・コントローラをアドレス指定することができ、該複数の無線ネットワーク・コントローラは、該複数の無線ノードをアドレス指定することができ、
    該無線アクセス・ネットワークと外部のネットワークとの間でパケットをやり取りするためのインターフェースとを含む無線アクセス・ネットワーク。
54. 請求項５３に記載の無線アクセス・ネットワークにおいて、
    該無線ノードと無線ネットワーク・コントローラを相互接続する該ネットワークが、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌネットワークを含む無線アクセス・ネットワーク。
55. 請求項５３に記載の無線アクセス・ネットワークにおいて、
    それぞれの無線ネットワーク・コントローラが、トラフィック・チャネルがどの無線ノードを流れているかにかかわらず、該トラフィック・チャネルを保持するように構成されている無線アクセス・ネットワーク。
56. 請求項５５に記載の無線アクセス・ネットワークにおいて、
    該無線ネットワーク・コントローラが、該無線ノードのうちのいずれか１つを介して該アクセス端末との間でパケットを経路指定することによって、該トラフィック・チャネルを保持する無線アクセス・ネットワーク。
57. 請求項５５に記載の無線アクセス・ネットワークにおいて、
    該複数の無線ノード及び該複数の無線ネットワーク・コントローラが、共通のサブネットワークに関連付けられている無線アクセス・ネットワーク。
58. 請求項５３に記載の無線アクセス・ネットワークにおいて、
    該無線ノードのそれぞれが、該複数の無線ネットワーク・コントローラから選択された第１の無線ネットワーク・コントローラに関連付けられている無線アクセス・ネットワーク。
59. 請求項５３に記載の無線アクセス・ネットワークにおいて、
    該複数の無線ネットワーク・コントローラのそれぞれが、該無線ノードのうちのいずれか１つを介して呼び出しメッセージをアクセス端末へ送信することができる無線アクセス・ネットワーク。
60. モバイル・アクセス端末と無線通信するための無線アクセス・ネットワークであって、
    ネットワークを使用して複数の無線ネットワーク・コントローラと相互接続されている複数の無線ノードを含み、該複数の無線ノードは、該複数の無線ネットワーク・コントローラをアドレス指定することができ、該複数の無線ネットワーク・コントローラは、該複数の無線ノードをアドレス指定することができ、
    該複数の無線ネットワーク・コントローラは、それぞれ該ネットワークに接続されており、該複数の無線ノードのそれぞれによってアドレス指定することができる複数のサーバ・カードを含み、該それぞれのサーバ・カードは、
    第１のサーバ・カードにおける過負荷の状況を検知し、
    該第１のサーバ・カードにおける過負荷の状況を検知した場合に、ターゲット・サーバ・カードへ転送するために、該第１のサーバ・カード上でサービスを提供されているトラフィック・チャネルを選択し、該第１のサーバ・カードが、中央集権化されたロード・トラッカーによって提供される１つ又は複数のターゲット・サーバ・カードのリストから該ターゲット・サーバ・カードを選択し、
    該選択されたトラフィック・チャネルを中断することなく、該選択されたトラフィック・チャネルを該複数の無線ネットワーク・コントローラのうちの１つの中の該ターゲット・サーバ・カードへ転送し、
    該複数無線ノードのうちの１つ又はそれ以上の無線ノードと、該サーバ・カードを含むそれぞれの無線ネットワーク・コントローラとの間でシグナリングを実行するように構成され、該無線ネットワーク・コントローラは、該それぞれのサーバ・カード上で該モバイル・アクセス端末とのトラフィック・チャネルを確立するように構成されている無線アクセス・ネットワーク。
61. 請求項６０に記載の無線アクセス・ネットワークにおいて、
    該無線ネットワーク・コントローラが、１つ又は複数の無線ノードへのトラフィック・チャネルが確立されているサーバ・カードのアドレスを提供するように構成されている無線アクセス・ネットワーク。
62. 請求項６０に記載の無線アクセス・ネットワークにおいて、
    該複数の無線ノードが、
    第１の周波数チャネル上で機能するように構成されている第１の無線ノードと、
    第２の周波数チャネル上で機能するように構成されている第２の無線ノードとを含み、該第１及び第２の無線ノードが同一の場所に配置されている無線アクセス・ネットワーク。
63. 請求項６０に記載の無線アクセス・ネットワークにおいて、
    それぞれの無線ネットワーク・コントローラが、自分の複数のサーバ・カードのうちの１つにおける過負荷の状況を検知して、別のカードへ転送するために、過負荷になっているカードによって処理されている１つ又は複数のトラフィック・チャネルを選択するように構成されている無線アクセス・ネットワーク。
64. 請求項６０に記載の無線アクセス・ネットワークにおいて、
    該インターフェースが、パケット・データ・スイッチング・ノードを含む無線アクセス・ネットワーク。
65. 請求項６０に記載の無線アクセス・ネットワークにおいて、
    該インターフェースが、無線ネットワーク・コントローラの一部である無線アクセス・ネットワーク。

Images