(57)【要約】第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションが確立される。第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に第１のトラフィック・チャネルが確立される。第１のトラフィック・チャネルを介して第１の複数のパケットが送信および受信される。これらの第１の複数のパケットは、第２の無線ネットワーク・コントローラを通過することなく、第１の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に、第１のトラフィック・チャネルが保持される。第２の複数のパケットが、別の無線ネットワーク・コントローラを通過することなく、第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。無線アクセス・ネットワークにおいては、複数の無線ネットワーク・コントローラが、ネットワークを使用していくつかの無線ノードに接続される。相互接続された無線ネットワーク・コントローラおよび無線ノードは、アドレス指定が可能であり、したがってそれぞれの無線ネットワーク・コントローラは、それぞれの無線ノードと直接通信することができ、逆もまた同様である。無線アクセス・ネットワークは、アクセス端末と無線ネットワーク・コントローラとの間におけるトラフィック・チャネルのセットアップをフローとしてさえ保持することによって、無線ネットワーク・コントローラどうしの間におけるアクティブなハンドオフを回避するように構成することができる。
2007538476.tif 000002
【特許請求の範囲】
【請求項１】
第１および第２の無線ネットワーク・コントローラと、第１および第２の無線ノードとを含むモバイル無線ネットワークに関連して、
前記第１の無線ノードを介して前記第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、
前記第２の無線ノードを介して前記第２の無線ネットワーク・コントローラ上の第２のモバイル・アクセス端末のための第２のセッションを確立する工程と、
前記第１のモバイル・アクセス端末と前記第１の無線ネットワーク・コントローラとの間に第１のトラフィック・チャネルを確立する工程と、
前記第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信する工程であって、前記第１の複数のパケットが、前記第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと前記第１の無線ネットワーク・コントローラとの間を移動する工程と、
前記第１のアクセス端末が前記第１の無線ノードのサービス・エリアから前記第２の無線ノードのサービス・エリアへ移動する際に、前記第１のトラフィック・チャネルを保持する工程と、
前記第１のトラフィック・チャネルを介して第２の複数のパケットを送信および受信する工程であって、前記第２の複数のパケットが、前記第１の無線ネットワーク・コントローラを通過することなく前記第２の無線ノードと前記第１の無線ネットワーク・コントローラとの間を移動する工程と、
前記第１のアクセス端末が、前記第１の無線ノードのサービス・エリアから前記第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、前記第２の無線ネットワーク・コントローラ上の前記第１のモバイル・アクセス端末のための新たなセッションを確立するか、または前記第１の無線ネットワーク・コントローラから前記第２の無線ネットワーク・コントローラへＲＮＣ間での休眠中のハンドオフを実行する工程とを含む方法。
【請求項２】
前記第２の無線ノードと前記第２の無線ネットワーク・コントローラとの間における第１の関連付けを確立する工程と、前記第２の無線ノードと前記第１の無線ネットワーク・コントローラとの間における第２の関連付けを確立する工程とをさらに含む請求項１に記載の方法。
【請求項３】
前記第１の関連付けを確立する工程が、ＰＮオフセットおよびＩＰアドレスの情報を前記第２の無線ノードから前記第２の無線ネットワーク・コントローラに渡す工程を含み、
前記第２の関連付けを確立する工程が、ＰＮオフセットおよびＩＰアドレスの情報を前記第２の無線ノードから前記第１の無線ネットワーク・コントローラに渡す工程を含む請求項２に記載の方法。
【請求項４】
前記第１の無線ノードによって、第１のサブネット識別子を放送する工程と、
前記第２の無線ノードによって、前記第１のサブネット識別子とは異なる第２のサブネット識別子を放送する工程と、
前記第１のアクセス端末によって、前記休眠中の状態にある間に前記サブネット識別子をモニタする工程と、
前記サブネット識別子における変化を検知すると、前記新たなセッションの確立、または前記第１の無線ネットワーク・コントローラから前記第２の無線ネットワーク・コントローラへの前記休眠中のＲＮＣ間でのハンドオフを引き起こす工程とをさらに含む請求項１または２に記載の方法。
【請求項５】
それぞれの無線ノードをそのそれぞれのサブネット識別子と共に個々に構成する工程をさらに含む請求項４に記載の方法。
【請求項６】
前記第２または第３の無線ノードが、自分が第１の関連付けを確立している前記それぞれの無線ネットワーク・コントローラから自分のサブネット識別子を得る工程をさらに含む請求項４に記載の方法。
【請求項７】
引き起こす工程が、前記第１のアクセス端末によってＵＡＴＩ  Ｒｅｑｕｅｓｔメッセージを送信することによって、前記新たなセッションの確立、または前記第１の無線ネットワーク・コントローラから前記第２の無線ネットワーク・コントローラへの前記休眠中のＲＮＣ間でのハンドオフを引き起こす工程を含む請求項４に記載の方法。
【請求項８】
それぞれの無線ノードをそのそれぞれのサブネット識別子と共に個々に構成する工程をさらに含む請求項７に記載の方法。
【請求項９】
前記第２または第３の無線ノードが、自分が第１の関連付けを確立している前記それぞれの無線ネットワーク・コントローラから自分のサブネット識別子を得る工程をさらに含む請求項７に記載の方法。
【請求項１０】
第３の無線ノードと前記第１の無線ネットワーク・コントローラとの間における第１の関連付けを確立する工程と、
前記第３の無線ノードと前記第２の無線ネットワーク・コントローラとの間における第２の関連付けを確立する工程と、
前記第３の無線ノードによって、前記第１および第２の無線ノードに関連付けられている第１および第２のサブネット識別子とは異なる第３のサブネット識別子を放送する工程と、
前記第１のアクセス端末が、前記第１の無線ノードのサービス・エリアから前記第３の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、前記第１の無線ネットワーク・コントローラが、新たなＵＡＴＩを前記第１のアクセス端末に割り当てる工程と、
前記サブネット識別子における変化を検知すると、ＵＡＴＩ  Ｒｅｑｕｅｓｔメッセージを送信することによって、前記新たなＵＡＴＩの割り当てを引き起こす工程とをさらに含む請求項４に記載の方法。
【請求項１１】
それぞれの無線ノードをそのそれぞれのサブネット識別子と共に個々に構成する工程をさらに含む請求項１０に記載の方法。
【請求項１２】
前記第２または第３の無線ノードが、自分が第１の関連付けを確立している前記それぞれの無線ネットワーク・コントローラから自分のサブネット識別子を得る工程をさらに含む請求項１０に記載の方法。
【請求項１３】
１つまたは複数の無線ネットワーク・コントローラによってサービスを提供されているセッションに関するセッション情報を保存するためのＲＮＣリソース・コントロール・エージェントを採用する工程をさらに含む請求項２に記載の方法。
【請求項１４】
前記ＲＮＣリソース・コントロール・エージェントによって、無線ネットワーク・コントローラの障害を検知する工程と、
無線ネットワーク・コントローラの前記障害を検知すると、ユーザ・セッションを残りの無線ネットワーク・コントローラに割り当て直す工程と、セッション情報をこれらの残りの無線ネットワーク・コントローラに渡す工程とをさらに含む請求項７に記載の方法。
【請求項１５】
複数のサーバ・カードを有するシャーシベースのハードウェア・プラットフォームを採用して、前記無線ネットワーク・コントローラのそれぞれを実装する工程をさらに含む請求項１または２に記載の方法。
【請求項１６】
前記第１の無線ネットワーク・コントローラ上の前記サーバ・カードのうちの１つを本拠とすることによって、前記第２の無線ノードと前記第１の無線ネットワーク・コントローラとの間に関連付けを確立する工程と、
前記第２の無線ネットワーク・コントローラ上の前記サーバ・カードのうちの１つを本拠とすることによって、前記第２の無線ノードと前記第２の無線ネットワーク・コントローラとの間に関連付けを確立する工程とをさらに含む請求項１５に記載の方法。
【請求項１７】
前記関連付けを確立する工程が、前記第２の無線ノードから、前記第２の無線ノードが本拠とされている前記サーバ・カードへＰＮオフセット情報を渡す工程を含む方法であって、
前記ＰＮオフセット情報を受信している前記サーバ・カードから前記シャーシベースのハードウェア・プラットフォーム内のその他のサーバ・カードへ前記ＰＮオフセット情報を配信する工程をさらに含む請求項１６に記載の方法。
【請求項１８】
それぞれの無線ノードと、前記無線ネットワーク・コントローラ内でそれぞれの無線ノードが本拠とされている前記サーバ・カードとの間で信号を伝達するためにトランスポート層接続を確立する工程をさらに含む請求項１６に記載の方法。
【請求項１９】
前記関連付けを確立する工程が、前記第２の無線ノードから、前記第２の無線ノードが本拠とされている前記サーバ・カードへＰＮオフセット情報を渡す工程を含む方法であって、
前記ＰＮオフセット情報を受信している前記サーバ・カードから前記シャーシベースのハードウェア・プラットフォーム内のその他のサーバ・カードへ前記ＰＮオフセット情報を配信する工程をさらに含む請求項１８に記載の方法。
【請求項２０】
前記ＲＮＣ間でのハンドオフの手続きが、１ｘＥＶ−ＤＯ  ＩＯＳ仕様のＡ１３インターフェースに準拠する請求項１に記載の方法。
【請求項２１】
前記無線ネットワーク・コントローラがＰＤＳＮ機能を含む請求項１に記載の方法。
【請求項２２】
前記第１の無線ネットワーク・コントローラおよび前記第１の無線ノードが、同一の場所に配置されており、前記第２の無線ネットワーク・コントローラおよび前記第２の無線ノードが、同一の場所に配置されている請求項１に記載の方法。
【請求項２３】
情報搬送波内において目に見える形で具体化され、第１および第２の無線ネットワーク・コントローラと、第１および第２の無線ノードとを含むモバイル無線ネットワーク内で機能するように適合されているコンピュータ・プログラム製品であって、
前記第１の無線ノードを介して前記第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、
前記第２の無線ノードを介して前記第２の無線ネットワーク・コントローラ上の第２のモバイル・アクセス端末のための第２のセッションを確立する工程と、
前記第１のモバイル・アクセス端末と前記第１の無線ネットワーク・コントローラとの間に第１のトラフィック・チャネルを確立する工程と、
前記第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信する工程であって、前記第１の複数のパケットが、前記第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと前記第１の無線ネットワーク・コントローラとの間を移動する工程と、
前記第１のアクセス端末が前記第１の無線ノードのサービス・エリアから前記第２の無線ノードのサービス・エリアへ移動する際に、前記第１のトラフィック・チャネルを保持する工程であって、第２の複数のパケットが、別の無線ネットワーク・コントローラを通過することなく前記第２の無線ノードと前記第１の無線ネットワーク・コントローラとの間を移動する工程とをデータ処理装置に実行させるように機能する命令を含むコンピュータ・プログラム製品。
【請求項２４】
前記命令が、
前記第１のアクセス端末が、前記第１の無線ノードのサービス・エリアから前記第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、前記第２の無線ネットワーク・コントローラ上の前記第１のモバイル・アクセス端末のための新たなセッションを確立するか、または前記第１の無線ネットワーク・コントローラから前記第２の無線ネットワーク・コントローラへＲＮＣ間での休眠中のハンドオフを実行する工程を前記データ処理装置に実行させるようにさらに機能する請求項２３に記載のコンピュータ・プログラム製品。
【請求項２５】
第１の無線ネットワーク・コントローラと、
第２の無線ネットワーク・コントローラと、
第１の無線ノードと、
第２の無線ノードと、
前記第１の無線ノードを介して前記第１の無線ネットワーク・コントローラ上に確立されている第１のセッションと、前記第１の無線ネットワーク・コントローラと共に確立されている第１のトラフィック・チャネルとに関連付けられている第１のモバイル・アクセス端末であって、前記第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信し、前記第１の複数のパケットが、前記第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと前記第１の無線ネットワーク・コントローラとの間を移動する第１のモバイル・アクセス端末と、
前記第２の無線ノードを介して前記第２の無線ネットワーク・コントローラ上に確立されている第２のセッションに関連付けられている第２のモバイル・アクセス端末とを含むモバイル無線ネットワークであって、
前記第１のアクセス端末が前記第１の無線ノードのサービス・エリアから前記第２の無線ノードのサービス・エリアへ移動する際に、前記第１のトラフィック・チャネルが保持され、第２の複数のパケットが、前記第２の無線ネットワーク・コントローラを通過することなく前記第２の無線ノードと前記第１の無線ネットワーク・コントローラとの間を移動するモバイル無線ネットワーク。
【請求項２６】
前記第１のアクセス端末が、前記第１の無線ノードのサービス・エリアから前記第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、前記第２の無線ネットワーク・コントローラ上の前記第１のモバイル・アクセス端末のための新たなセッションが確立されるか、または前記第１の無線ネットワーク・コントローラから前記第２の無線ネットワーク・コントローラへのＲＮＣ間での休眠中のハンドオフが実行される請求項２０に記載のモバイル無線ネットワーク。
【請求項２７】
無線ネットワーク内でモバイル・アクセス端末を使用してデジタル情報をやり取りする方法であって、
第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードを介して、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に確立された第１のトラフィック・チャネルを介してパケットを送信する工程と、
第１の無線ネットワーク・コントローラを通過することなく第２の無線ノードを介して、第２のモバイル・アクセス端末と第２の無線ネットワーク・コントローラとの間に確立された第２のトラフィック・チャネルを介してパケットを送信する工程と、
前記第２の無線ノードを介して前記第１のアクセス端末との間でパケットが受信または送信される場合に、前記第１のアクセス端末と前記第１の無線ネットワーク・コントローラとの間における前記第１のトラフィック・チャネルを保持する工程と、
前記第１のアクセス端末から受信したパケットを外部のネットワークへ送信する工程とを含む方法。
【請求項２８】
前記第１のアクセス端末が第３の無線ノードの付近にあることを検知すると、前記第１の無線ネットワーク・コントローラから前記第２の無線ネットワーク・コントローラへ前記第１のトラフィック・チャネルのアクティブなハンドオフを実行する工程をさらに含む請求項２７に記載の方法。
【請求項２９】
前記第１のアクセス端末が第３の無線ノードの付近にあることを検知すると、前記第１の無線ネットワーク・コントローラによって前記第１のトラフィック・チャネルを閉じる工程をさらに含む請求項２７に記載の方法。
【請求項３０】
前記第１の無線ノードを介して前記第１の無線ネットワーク・コントローラ上の第３のモバイル・アクセス端末のための第１のセッションを確立する工程と、
前記アクセス端末によって送信される位置更新メッセージに基づいて前記第３のアクセス端末の大まかな位置を追跡把握する工程と、
前記第３のアクセス端末が休眠中の状態にある間に、前記第１の無線ネットワーク・コントローラにおいて前記第３のアクセス端末のためのパケットを受信する工程と、
前記第２の無線コントローラが前記第３のアクセス端末を呼び出すことを要求するメッセージを前記第２の無線コントローラへ送信する工程と、
第３の無線ノードを介して前記第２の無線ネットワーク・コントローラから前記アクセス端末を呼び出す工程とをさらに含む請求項２７に記載の方法。
【請求項３１】
前記第３の無線ノードにおいて、アクセス・チャネルを介して前記第３のモバイル・アクセス端末からトラフィック・チャネル要求メッセージを受信する工程と、
前記第３の無線ノードから前記第２の無線ネットワーク・コントローラへ前記トラフィック・チャネル要求メッセージを転送する工程と、
前記第１の無線ネットワーク・コントローラから前記第２の無線ネットワーク・コントローラへの前記第１のセッションのハンドオフを実行する工程と、
前記ハンドオフが完了した後に、前記第２の無線ネットワーク・コントローラと前記第３のアクセス端末との間にトラフィック・チャネルを確立する工程とをさらに含む請求項３０に記載の方法。
【請求項３２】
前記第１の無線ネットワーク・コントローラが複数のサーバ・カードを含む方法であって、
前記複数のサーバ・カードから選択されたサーバ・カードのうちの１つの上で前記無線ネットワーク・コントローラと前記第１のモバイル・アクセス端末との間に前記第１のトラフィック・チャネルを確立する工程と、
前記選択されたサーバ・カードのアドレスを前記無線ネットワーク・コントローラから前記第１の無線ノードへ送信する工程と、
リバース・リンクのトラフィック・チャネル・パケットを前記第１の無線ノードから前記選択されたサーバ・カードの前記アドレスへ送信する工程と、
前記選択されたサーバ・カードの前記アドレスを前記第１の無線ネットワーク・コントローラから前記第２の無線ノードへ送信する工程と、
リバース・リンクのトラフィック・チャネル・パケットを前記第２の無線ノードから前記選択されたサーバ・カードの前記アドレスへ送信する工程とをさらに含む請求項２７に記載の方法。
【請求項３３】
前記第１の無線ノードが、第１の周波数チャネル上で機能し、前記第２の無線ノードが、前記第１の無線ノードと同一の場所に配置されて、第２の周波数チャネル上で機能する請求項２７に記載の方法。
【請求項３４】
前記第１の周波数チャネル上で機能する前記第１の無線ノードを介して前記第１の無線ネットワーク・コントローラ上の前記第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、
前記第２の周波数チャネル上で機能する前記第２の無線ノードを介して前記第２の無線ネットワーク・コントローラ上の前記第２のモバイル・アクセス端末のための第２のセッションを確立する工程と、
前記第２の周波数チャネル上で機能する前記第２の無線ノードを介して前記第１の無線ネットワーク・コントローラ上の前記第３のモバイル・アクセス端末のための第３のセッションを確立する工程とをさらに含む請求項３３に記載の方法。
【請求項３５】
前記第１の周波数チャネル上で機能する前記第１の無線ノードと前記第１の無線ネットワーク・コントローラとの間における第１の関連付けを確立する工程と、
前記第２の周波数チャネル上で機能する前記第２の無線ノードと前記第１の無線ネットワーク・コントローラとの間における第２の関連付けを確立する工程と、
前記第１の周波数チャネル上で機能する前記第１の無線ノードを介して前記第１の無線ネットワーク・コントローラ上の前記第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、
アクセス端末が、休眠中のモードにある前記第２の無線ノードのモニタリングを開始した場合は常に、前記第１のセッションを前記第２の無線ネットワーク・コントローラへ転送する工程とをさらに含む請求項３３に記載の方法。
【請求項３６】
前記第１の周波数チャネル上で機能する前記第１の無線ノードを介して前記第１の無線ネットワーク・コントローラにおいて前記第１のモバイル・アクセス端末からの接続要求を受信する工程と、
前記第１の無線ネットワーク・コントローラ上の前記第１のアクセス端末のための第３のトラフィック・チャネルを確立する工程であって、前記トラフィック・チャネルが、前記第２の周波数チャネル上で機能する前記第２の無線ノードを介して流れる工程とをさらに含む請求項３３に記載の方法。
【請求項３７】
前記第１の無線ネットワーク・コントローラによって前記第１および第２の無線ノードから受信される実際の負荷の情報に基づいて前記第２の周波数チャネル上で機能する前記第２の無線ノードを介して流れる前記第３のトラフィック・チャネルを確立する工程をさらに含む請求項３６に記載の方法。
【請求項３８】
前記第１および第２の無線ノード上の負荷の見積もりに基づいて前記第２の周波数チャネル上で機能する前記第２の無線ノードを介して流れる第３のトラフィック・チャネルを確立する工程をさらに含む請求項３６に記載の方法。
【請求項３９】
前記第１および第２の無線ネットワーク・コントローラが、それぞれ複数のサーバ・カードを含む方法であって、
前記第１の無線ネットワーク・コントローラ内の第１のサーバ・カード上の複数のトラフィック・チャネルを処理する工程と、
前記第１のサーバ・カードにおける過負荷の状況を検知する工程と、
別のサーバ・カードへ転送するために、前記第１のサーバ・カード上でサービスを提供されているトラフィック・チャネルを選択する工程と、
前記トラフィック・チャネルを中断することなく、前記選択されたトラフィック・チャネルを前記無線ネットワーク・コントローラのうちの１つの中の別のサーバ・カードへ転送する工程とをさらに含む請求項２７に記載の方法。
【請求項４０】
転送するために前記トラフィック・チャネルを選択する工程が、前記選択されたトラフィック・チャネルによって使用されている処理中のリソースの量に少なくとも部分的に基づく請求項３９に記載の方法。
【請求項４１】
転送するために前記トラフィック・チャネルを選択する工程が、前記複数のトラフィック・チャネル上の前記トラフィックのサービスの質の要件に少なくとも部分的に基づく請求項３９に記載の方法。
【請求項４２】
前記無線ネットワーク・コントローラ内のその他のカードの負荷および利用可能度に少なくとも部分的に基づいて、前記選択されたトラフィック・チャネルの転送先となるターゲット・サーバ・カードを決定する工程をさらに含む請求項３９に記載の方法。
【請求項４３】
前記第１のサーバ・カードおよびターゲット・サーバ・カードが、双方とも同じ無線ネットワーク・コントローラ内に配置されている請求項３９に記載の方法。
【請求項４４】
サーバ・カードの負荷に関する情報が、中央集権化されたロード・トラッカーによって提供される請求項４２に記載の方法。
【請求項４５】
前記中央集権化されたロード・トラッカーが、無線ネットワーク・コントローラ内に配置されている請求項４４に記載の方法。
【請求項４６】
前記中央集権化されたロード・トラッカーが、すべての無線ネットワーク・コントローラに対して外部にある請求項４４に記載の方法。
【請求項４７】
前記中央集権化されたロード・トラッカーが、前記第１のサーバ・カードから前記ターゲット・サーバ・カードへのトラフィック・チャネルの転送を引き起こすように構成されている請求項４４に記載の方法。
【請求項４８】
負荷の情報が、前記第１のサーバ・カードによって直接その他のサーバ・カードから得られる請求項４１に記載の方法。
【請求項４９】
前記第３の無線ノードおよび前記第１の無線ノードが、別々のサブネットワークに属する請求項３０に記載の方法。
【請求項５０】
Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌネットワークを使用して、前記第１の無線ネットワーク・コントローラと前記第１および第２の無線ノードとの間でデータ・パケットをやり取りする工程をさらに含む請求項２７に記載の方法。
【請求項５１】
前記第１の無線ネットワーク・コントローラが、パケット・データ・スイッチング・ノードとして機能するように構成されている請求項２７に記載の方法。
【請求項５２】
前記第１および第２の無線ネットワーク・コントローラが、前記第１および第２の無線ノードと同一の場所に配置されている請求項２７に記載の方法。
【請求項５３】
前記外部のネットワークが、Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌネットワークを含む請求項２７に記載の方法。
【請求項５４】
モバイル・アクセス端末と無線通信するための無線アクセス・ネットワークであって、
ネットワークを使用して複数の無線ネットワーク・コントローラと相互接続されている複数の無線ノードであって、それぞれの前記無線ノードが、それぞれの前記無線ネットワーク・コントローラをアドレス指定することができ、それぞれの前記無線ネットワーク・コントローラが、それぞれの前記無線ノードをアドレス指定することができる無線ノードと、
前記無線アクセス・ネットワークと外部のネットワークとの間でパケットをやり取りするためのインターフェースとを含む無線アクセス・ネットワーク。
【請求項５５】
前記無線ノードと無線ネットワーク・コントローラを相互接続する前記ネットワークが、Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌネットワークを含む請求項５４に記載の無線アクセス・ネットワーク。
【請求項５６】
それぞれの無線ネットワーク・コントローラが、トラフィック・チャネルがどの無線ノードを流れているかにかかわらず、前記トラフィック・チャネルを保持するように構成されている請求項５４に記載の無線アクセス・ネットワーク。
【請求項５７】
前記無線ネットワーク・コントローラが、前記無線ノードのうちのいずれか１つを介して前記アクセス端末との間でパケットを経路指定することによって、前記トラフィック・チャネルを保持する請求項５６に記載の無線アクセス・ネットワーク。
【請求項５８】
前記複数の無線ノードおよび前記複数の無線ネットワーク・コントローラが、共通のサブネットワークに関連付けられている請求項５６に記載の無線アクセス・ネットワーク。
【請求項５９】
前記無線ノードのそれぞれが、前記複数の無線ネットワーク・コントローラから選択された第１の無線ネットワーク・コントローラに関連付けられている請求項５４に記載の無線アクセス・ネットワーク。
【請求項６０】
前記複数の無線ネットワーク・コントローラのそれぞれが、前記無線ノードのうちのいずれか１つを介して呼び出しメッセージをアクセス端末へ送信することができる請求項５４に記載の無線アクセス・ネットワーク。
【請求項６１】
それぞれの無線ネットワーク・コントローラが、
それぞれ前記ネットワークに接続されており、前記複数の無線ノードのそれぞれによってアドレス指定することができる複数のサーバ・カードであって、それぞれの無線ネットワーク・コントローラが、前記複数のサーバ・カードのそれぞれの上でアクセス端末とのトラフィック・チャネルを確立するように構成されている複数のサーバ・カードを含む請求項５４に記載の無線アクセス・ネットワーク。
【請求項６２】
前記無線ネットワーク・コントローラが、１つまたは複数の無線ノードへのトラフィック・チャネルが確立されているサーバ・カードのアドレスを提供するように構成されている請求項６１に記載の無線アクセス・ネットワーク。
【請求項６３】
前記複数の無線ノードが、
第１の周波数チャネル上で機能するように構成されている第１の無線ノードと、
第２の周波数チャネル上で機能するように構成されている第２の無線ノードとを含み、前記第１および第２の無線ノードが同一の場所に配置されている請求項５４に記載の無線アクセス・ネットワーク。
【請求項６４】
それぞれの無線ネットワーク・コントローラが、自分の複数のサーバ・カードのうちの１つにおける過負荷の状況を検知して、別のカードへ転送するために、過負荷になっているカードによって処理されている１つまたは複数のトラフィック・チャネルを選択するように構成されている請求項６１に記載の無線アクセス・ネットワーク。
【請求項６５】
前記インターフェースが、パケット・データ・スイッチング・ノードを含む請求項５４に記載の無線アクセス・ネットワーク。
【請求項６６】
前記インターフェースが、無線ネットワーク・コントローラの一部である請求項５４に記載の無線アクセス・ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
この説明は、無線ネットワーク・コントロールに関する。
【背景技術】
【０００２】
ＨＤＲ（Ｈｉｇｈ  Ｄａｔａ  Ｒａｔｅ）は、新興のモバイル無線アクセス・テクノロジーであり、これによって、パーソナル・ブロードバンド・インターネット・サービスにいつでもどこでもアクセスできるようになる（Ｐ．Ｂｅｎｄｅｒら、「ＣＤＭＡ／ＨＤＲ：Ａ  Ｂａｎｄｗｉｄｔｈ−Ｅｆｆｉｃｉｅｎｔ  Ｈｉｇｈ−Ｓｐｅｅｄ  Ｗｉｒｅｌｅｓｓ  Ｄａｔａ  Ｓｅｒｖｉｃｅ  ｆｏｒ  Ｎｏｍａｄｉｃ  Ｕｓｅｒｓ」、ＩＥＥＥ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｍａｇａｚｉｎｅ、２０００年７月、および３ＧＰＰ２、「Ｄｒａｆｔ  Ｂａｓｅｌｉｎｅ  Ｔｅｘｔ  ｆｏｒ  １ｘＥＶ−ＤＯ」、2000年8月21日を参照されたい）。Ｑｕａｌｃｏｍｍによって開発されたＨＤＲは、わずか（１Ｘ）１．２５ＭＨｚのスペクトルを使用してセクタあたり最大２．４６Ｍｂｉｔ／ｓの共有されたフォワード・リンクの伝送速度を実現することができるＩＰパケット・データ・サービス用に最適化された無線インターフェースである。ＣＤＭＡ２０００無線アクセス（TIA/EIA/IS-2001、「Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＯＳ）ｆｏｒ  ＣＤＭＡ２０００  Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｉｎｔｅｒｆａｃｅｓ」、２０００年５月）、および無線ＩＰネットワーク・インターフェース（ＴＩＡ／ＥＩＡ／ＴＳＢ−１１５、「Ｗｉｒｅｌｅｓｓ  ＩＰ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｂａｓｅｄ  ｏｎ  ＩＥＴＦ  Ｐｒｏｔｏｃｏｌｓ」、２０００年６月６日、およびＴＩＡ／ＥＩＡ／ＩＳ−８３５、「Ｗｉｒｅｌｅｓｓ  ＩＰ  Ｎｅｔｗｏｒｋ  Ｓｔａｎｄａｒｄ」、３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  ２（３ＧＰＰ２）、Ｖｅｒｓｉｏｎ  １．０、２０００年７月１４日）と互換性があるため、ＨＤＲネットワークは、モバイルＡＴ（Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ）からグローバルなインターネットに至るまで、完全にＩＰテクノロジー上で構築することができ、したがってＩＰネットワークの拡張性、冗長性、および低コストを十分に活用することができる。
【０００３】
ＨＤＲは、ＣＤＭＡ２０００ファミリーにおける新しい標準として、すなわち以前はＨＲＰＤ（Ｈｉｇｈ  Ｒａｔｅ  Ｐａｃｋｅｔ  Ｄａｔａ）と呼ばれており、１ｘＥＶ−ＤＯまたはＩＳ−８５６としても知られている高速のＤＯ（ｄａｔａ−ｏｎｌｙ）サービス用の現行の１ｘＲＴＴ標準を進化させたものとして、ＴＩＡ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｉｎｄｕｓｔｒｙ  Ａｓｓｏｃｉａｔｉｏｎ）によって採用されている。
【０００４】
ＩＳ−８５６のシステムは通常、図１に示されている無線アクセス・ネットワーク・アーキテクチャを使用して実装される。ここでは、ＡＴ（Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ）１０は、ＩＳ−８５６のサポートを内蔵したラップトップ・コンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、デュアルモードのボイス／データ・ハンドセット、または別のデバイスとすることができる。
【０００５】
無線アクセス・プロバイダの管理サービス・エリアの全体は、１つまたは複数のサブネットワーク（すなわちサブネット）１２、１４へと分割することができる。それぞれのサブネット１２は、１組のＲＮ（Ｒａｄｉｏ  Ｎｏｄｅ）１６、１８と、１つまたは複数のＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）２０、２２とを含む。ＲＮは、帰路ネットワーク２４を介してＲＮＣに接続される。既存の２Ｇおよび３Ｇ無線ネットワークにおいては、それぞれのＲＮは、専用回線またはＡＴＭ  ＰＶＣ（ｐｅｒｍａｎｅｎｔ  ｖｉｒｔｕａｌ  ｃｉｒｃｕｉｔ）を使用して、１つのＲＮＣのみに接続される。さらにＲＮＣは、専用回線またはＡＴＭ  ＰＶＣを使用して、相互に接続される。新しい世代のＩＰベースの無線アクセス・ネットワークにおいては、ＲＮとＲＮＣの間で多対多の接続をサポートする共有されたＩＰまたは大都市のイーサネット（登録商標）・ネットワークを使用して、帰路を実装することができる。
【０００６】
それぞれのＲＮＣは通常、２５〜１００個のＲＮをコントロールする。それぞれのＲＮは通常、それぞれ１．２５ＭＨｚの帯域幅の１〜４個の搬送波をサポートする。さらに、それぞれのセル・エリア（図示せず）は通常、複数のセクタ（通常は３つまたは６つ）へと分割され、ＲＮは、それぞれのセクタごとに１つの無線トランシーバ２７を有する。
【０００７】
それぞれのＲＮＣは、ＩＰネットワーク２６を介して１つまたは複数のＰＤＳＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｓｅｒｖｉｎｇ  Ｎｏｄｅ）２８に接続される（前述のＴＩＡの参考文献を参照されたい）。ＲＮＣは、Ｒ−Ｐ（Ｒａｄｉｏ−Ｐａｃｋｅｔ）インターフェース３０と呼ばれる標準的なインターフェースを介してＰＤＳＮと通信する。Ｒ−Ｐインターフェースは、データを搬送するために使用されるＡ１０インターフェース、および信号を搬送するために使用されるＡ１１インターフェースという２つのインターフェースへとさらに分けられる。ＰＤＳＮは、モビリティをサポートするエッジ・ルータとみなすことができ、アクセス・ネットワークを通じてＡＴへのリンク層の接続を維持する。ＰＤＳＮは、ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ，Ａｕｔｈｏｒｉｚａｔｉｏｎ，ａｎｄ  Ａｃｃｏｕｎｔｉｎｇ）のためのＡＡＡサーバ３２へのインターフェースの役割も果たす。
【０００８】
ＡＴは、ネットワークに接続すると、ＲＮＣとのセッションを確立し、ＲＮＣからリンク層アドレスを受信する。このセッションは、ＲＮＣがＡＴにサービスを提供するために必要とするすべての情報を表す。現在３ＧＰＰ２によって１ｘＥＶ−ＤＯ  ＩＯＳ  Ｐｈａｓｅ  １（ＩＳ−８７８）において定義されているようなＩＳ−８５６の無線アクセス・ネットワークにおいては、それぞれのＲＮは、１つのＲＮＣに一意に関連付けられ、それぞれのサブネットは、ＲＮＣを１つしか含まない。結果として、あるＡＴが、あるＲＮＣのサービス・エリアから別のＲＮＣのサービス・エリアへ移動した場合には、そのＡＴはハンドオフを実行し、これには、セッションの転送が含まれる。
【０００９】
休眠中のＡＴは、サブネットの境界を越えるたびに、ＵＡＴＩ＿Ｒｅｑｕｅｓｔを送信することによって、休眠中のハンドオフを開始する。ＡＴは、セクタによって放送されている１２８−ビットのＳｅｃｔｏｒＩＤをモニタすることによって、休眠中のハンドオフの必要性を認識する。同じサブネットに属するすべてのセクタは、一定の範囲内に収まるＳｅｃｔｏｒＩＤを有する。所与のサブネット内で１つのＡＴに割り当てられる１２８−ビットのＵＡＴＩ（Ｕｎｉｖｅｒｓａｌ  Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ  Ｉｄｅｎｔｉｆｉｅｒ）は、同じ範囲内に収まる。ＡＴは、別のサブネットのサービス・エリアへと移動した場合には、自分のＵＡＴＩと、そのサービス提供中のセクタによって放送されているＳｅｃｔｏｒＩＤとを比較する。これらが同じ範囲に属していない場合には、ＡＴは、自分がサブネットの境界を越えたことを知り、ＵＡＴＩ＿Ｒｅｑｕｅｓｔを送信することによって、休眠中のハンドオフを開始する。
【非特許文献１】Ｐ．Ｂｅｎｄｅｒら、「ＣＤＭＡ／ＨＤＲ：Ａ  Ｂａｎｄｗｉｄｔｈ−Ｅｆｆｉｃｉｅｎｔ  Ｈｉｇｈ−Ｓｐｅｅｄ  Ｗｉｒｅｌｅｓｓ  Ｄａｔａ  Ｓｅｒｖｉｃｅ  ｆｏｒ  Ｎｏｍａｄｉｃ  Ｕｓｅｒｓ」、ＩＥＥＥ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｍａｇａｚｉｎｅ、２０００年７月
【非特許文献２】３ＧＰＰ２、「Ｄｒａｆｔ  Ｂａｓｅｌｉｎｅ  Ｔｅｘｔ  ｆｏｒ  １ｘＥＶ−ＤＯ」、２０００年８月２１日
【非特許文献３】ＴＩＡ／ＥＩＡ／ＩＳ−２００１、「Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＯＳ）ｆｏｒ  ＣＤＭＡ２０００  Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｉｎｔｅｒｆａｃｅｓ」、２０００年５月
【非特許文献４】ＴＩＡ／ＥＩＡ／ＴＳＢ−１１５、「Ｗｉｒｅｌｅｓｓ  ＩＰ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｂａｓｅｄ  ｏｎ  ＩＥＴＦ  Ｐｒｏｔｏｃｏｌｓ」、２０００年６月６日
【非特許文献５】ＴＩＡ／ＥＩＡ／ＩＳ−８３５、「Ｗｉｒｅｌｅｓｓ  ＩＰ  Ｎｅｔｗｏｒｋ  Ｓｔａｎｄａｒｄ」、３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  ２（３ＧＰＰ２）、Ｖｅｒｓｉｏｎ  １．０、２０００年７月１４日
【発明の開示】
【発明が解決しようとする課題】
【００１０】
休眠中のハンドオフの第１の目的は、そのＡＴ用に着信するパケットを新たなサービス提供側ＲＮＣへ送信するようＰＤＳＮに知らせることである。休眠中のハンドオフには、Ｒ−Ｐ（Ａ１０）セッションを古いサービス提供側ＲＮＣから新たなサービス提供側ＲＮＣへ移転することが含まれる。このようなハンドオフがなければ、ＰＤＳＮは、パケットを古いサービス提供側ＲＮＣへ送信してしまうであろう。古いサービス提供側ＲＮＣは、自分のサブネットの外のＡＴの位置を知らないため、ＡＴのパケットは、失われる可能性がある。
【００１１】
休眠中のハンドオフの第２の目的は、ＲＮＣどうしの間でセッション情報を転送することである。ＩＳ−８５６においては、それぞれのＲＮＣは、ＡＴに関する一定のセッション情報を保持する。このようなセッション情報は、無線インターフェースを介した通信のために必要とされる。セッション情報には、ＵＡＴＩ（Ｕｎｉｖｅｒｓａｌ  Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ  Ｉｄｅｎｔｉｆｉｅｒ）、アクセス・チャネルの認証および暗号化のためのセキュリティー・キー、ならびにその他のプロトコル定数が含まれる。ＡＴがＲＮＣの境界（この場合は、サブネット）を越えるたびに、新たなＵＡＴＩをそのＡＴに割り当てることが必要となり、残りのセッション情報を古いサービス提供側ＲＮＣから新たなサービス提供側ＲＮＣへ転送することが必要となる。このような転送には、ＲＮＣどうしの間におけるネットワーク・リンクが必要である。このようなセッションの転送がなければ、ＲＮＣどうしの間におけるすべてのハンドオフは、新たに長時間かけてセッションを確立し、貴重な無線リソースを費やし、遅延を引き起こす結果となる。ＲＮＣの電波到達範囲が小さい場合には、休眠中のハンドオフが頻繁に行われ、結果として（新たなＵＡＴＩを割り当てるための）無線リンク・リソースの過剰な使用、ＲＮＣがセッションの転送を実施するための余分な処理、ならびにＲＮＣおよびＰＤＳＮがＡ１０接続を移転するための余分な処理が発生する。
【課題を解決するための手段】
【００１２】
一態様においては、１つの方法が存在する。この方法は、第１および第２の無線ネットワーク・コントローラと、第１および第２の無線ノードとを含むモバイル無線ネットワークに関連して、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程を含む。この方法はまた、第２の無線ノードを介して第２の無線ネットワーク・コントローラ上の第２のモバイル・アクセス端末のための第２のセッションを確立する工程と、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に第１のトラフィック・チャネルを確立する工程とを含む。この方法はまた、第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信する工程を含み、この場合には、第１の複数のパケットは、第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。この方法はまた、第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に第１のトラフィック・チャネルを保持する工程を含み、この場合には、第２の複数のパケットは、別の無線ネットワーク・コントローラを通過することなく第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。この方法はまた、第１のアクセス端末が、第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、第２の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための新たなセッションを確立するか、または第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへＲＮＣ間での休眠中のハンドオフを実行する工程を含む。
【００１３】
別の態様においては、１つの方法が存在する。この方法は、複数のサーバ・カードを有するシャーシベースのハードウェア・プラットフォーム上にそれぞれ実装されている第１および第２の無線ネットワーク・コントローラと、第１および第２の無線ノードとを含むモバイル無線ネットワークに関連して、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程を含む。この方法はまた、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラの間に第１のトラフィック・チャネルを確立する工程と、第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信する工程とを含み、この場合には、第１の複数のパケットは、その他のいかなる無線ネットワーク・コントローラも通過することなく第１の無線ノードと第１の無線ネットワーク・コントローラの間を移動する。この方法はまた、第２のモバイル・アクセス端末と第２の無線ネットワーク・コントローラとの間に第２のトラフィック・チャネルを確立する工程と、第２のトラフィック・チャネルを介して第２の複数のパケットを送信および受信する工程とを含み、この場合には、第２の複数のパケットは、その他のいかなる無線ネットワーク・コントローラも通過することなく第２の無線ノードと第２の無線ネットワーク・コントローラとの間を移動する。この方法はまた、第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に第１のトラフィック・チャネルを保持する工程であって、第３の複数のパケットが、別の無線ネットワーク・コントローラを通過することなく第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する工程と、第１のモバイル・アクセス端末が第２の無線ノードのサービス・エリアへ移動するときに第１のセッションを保持する工程とを含む。
【００１４】
別の態様においては、情報搬送波内において目に見える形で具体化され、第１および第２の無線ネットワーク・コントローラと、第１および第２の無線ノードとを含むモバイル無線ネットワーク内で機能するように適合されているコンピュータ・プログラム製品が存在する。このコンピュータ・プログラム製品は、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、第２の無線ノードを介して第２の無線ネットワーク・コントローラ上の第２のモバイル・アクセス端末のための第２のセッションを確立する工程とをデータ処理装置に実行させるように機能する命令を含む。このコンピュータ・プログラム製品はまた、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に第１のトラフィック・チャネルを確立する工程と、第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信する工程であって、その第１の複数のパケットが、第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと第１の無線ネットワーク・コントローラの間を移動する工程とをデータ処理装置に実行させるようにさらに機能する命令を含む。このコンピュータ・プログラム製品はまた、第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に第１のトラフィック・チャネルを保持する工程であって、第２の複数のパケットが、別の無線ネットワーク・コントローラを通過することなく第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する工程をデータ処理装置に実行させるようにさらに機能する命令を含む。
【００１５】
別の態様においては、１つのモバイル無線ネットワークが存在する。このモバイル無線ネットワークは、第１の無線ネットワーク・コントローラと、第２の無線ネットワーク・コントローラと、第１の無線ノードと、第２の無線ノードと、第１のモバイル・アクセス端末と、第２のモバイル・アクセス端末とを含む。第１のモバイル・アクセス端末は、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上に確立されている第１のセッションと、第１の無線ネットワーク・コントローラと共に確立されている第１のトラフィック・チャネルとに関連付けられている。第１のモバイル・アクセス端末は、第１のトラフィック・チャネルを介して第１の複数のパケットを送信および受信し、その第１の複数のパケットは、第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。第２のモバイル・アクセス端末は、第２の無線ノードを介して第２の無線ネットワーク・コントローラ上に確立されている第２のセッションに関連付けられている。第１のトラフィック・チャネルは、第１のアクセス端末が第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動する際に保持される。第２の複数のパケットが、別の無線ネットワーク・コントローラを通過することなく第２の無線ノードと第１の無線ネットワーク・コントローラとの間を移動する。
【００１６】
上述の態様のすべてに関するその他の例は、下記の特徴のうちの１つまたは複数を含むことができる。第１の関連付けは、第２の無線ノードと第２の無線ネットワーク・コントローラとの間において確立することができる。第２の関連付けは、第２の無線ノードと第１の無線ネットワーク・コントローラとの間において確立することができる。第１の関連付けを確立する工程は、ＰＮオフセットおよびＩＰアドレスの情報を第２の無線ノードから第２の無線ネットワーク・コントローラに渡す工程を含むことができる。第２の関連付けを確立する工程は、ＰＮオフセットおよびＩＰアドレスの情報を第２の無線ノードから第１の無線ネットワーク・コントローラに渡す工程を含むことができる。第１の無線ノードは、第１のサブネット識別子を放送することができる。第２の無線ノードは、第１のサブネット識別子とは異なる第２のサブネット識別子を放送することができる。それぞれの無線ノードは、そのそれぞれのサブネット識別子と共に個々に構成することができる。これらの無線ノードは、自分が第１の関連付けを確立している自分のそれぞれの無線ネットワーク・コントローラから自分のサブネット識別子をそれぞれ得ることができる。
【００１７】
第１のアクセス端末は、休眠中の状態にある間にサブネット識別子をモニタし、そのサブネット識別子における変化を検知すると、新たなセッションの確立、または第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへの休眠中のＲＮＣ間でのハンドオフを引き起こすことができる。第１のアクセス端末は、ＵＡＴＩ  Ｒｅｑｕｅｓｔメッセージを送信することによって、新たなセッションの確立、または第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへの休眠中のＲＮＣ間でのハンドオフを引き起こすことができる。
【００１８】
第１の関連付けは、第３の無線ノードと第１の無線ネットワーク・コントローラの間において確立することができる。第２の関連付けは、第３の無線ノードと第２の無線ネットワーク・コントローラの間において確立することができる。第３の無線ノードは、第１および第２の無線ノードに関連付けられている第１および第２のサブネット識別子とは異なる第３のサブネット識別子を放送することができる。第１の無線ネットワーク・コントローラは、第１のアクセス端末が、第１の無線ノードのサービス・エリアから第３の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、新たなＵＡＴＩを第１のアクセス端末に割り当てることができる。１つまたは複数の無線ネットワーク・コントローラによってサービスを提供されているセッションに関するセッション情報を保存するためのＲＮＣリソース・コントロール・エージェントを採用することができる。ＲＮＣリソース・コントロール・エージェントは、無線ネットワーク・コントローラの障害を検知することができ、無線ネットワーク・コントローラの障害を検知すると、ユーザ・セッションを残りの無線ネットワーク・コントローラに割り当て直し、セッション情報をこれらの残りの無線ネットワーク・コントローラに渡す。セッションを閉じるためのメッセージを送信するために第１のアクセス端末に関する十分な情報を新たな無線ネットワーク・コントローラに提供する部分的なセッション情報を渡すことができる。
【００１９】
複数のサーバ・カードを有するシャーシベースのハードウェア・プラットフォームを採用して、無線ネットワーク・コントローラのそれぞれを実装することができる。第１の無線ネットワーク・コントローラ上のサーバ・カードのうちの１つを本拠とすることによって、第２の無線ノードと第１の無線ネットワーク・コントローラの間に関連付けを確立することができる。第２の無線ネットワーク・コントローラ上のサーバ・カードのうちの１つを本拠とすることによって、第２の無線ノードと第２の無線ネットワーク・コントローラの間に関連付けを確立することができる。それぞれの無線ノードと、無線ネットワーク・コントローラ内でそれぞれの無線ノードが本拠とされているサーバ・カードとの間で信号を伝達するために、ＴＣＰやＳＣＴＰなどのトランスポート層接続を確立することができる。関連付けを確立する工程は、第２の無線ノードから、その第２の無線ノードが本拠とされているサーバ・カードへＰＮオフセット情報を渡す工程を含むことができる。ＰＮオフセット情報は、そのＰＮオフセット情報を受信しているサーバ・カードからシャーシベースのハードウェア・プラットフォーム内のその他のサーバ・カードへ配信することができる。ＲＮＣ間でのハンドオフの手続きは、１ｘＥＶ−ＤＯ  ＩＯＳ仕様のＡ１３インターフェースに準拠することができる。
【００２０】
アクセス・チャネル・パケットは、第１および第２のアクセス端末に関連付けられているセッション識別子に基づいて第１および第２の無線ノードにおいて経路指定することができる。第１のアクセス端末に関連付けられているセッション識別子は、１ｘＥＶ−ＤＯ標準に基づくＡＴＩ（ａｃｃｅｓｓ  ｔｅｒｍｉｎａｌ  ｉｄｅｎｔｉｆｉｅｒ）に基づくことができる。第２のアクセス端末に関連付けられているセッション識別子は、ｃｄｍａ２０００標準に基づくＴＭＳＩ（ｔｅｍｐｏｒａｒｙ  ｍｏｂｉｌｅ  ｓｕｂｓｃｒｉｂｅｒ  ｉｄｅｎｔｉｔｙ）に基づくことができる。無線ネットワーク・コントローラは、ＰＤＳＮ機能を含むことができる。第１のアクセス端末が、第１の無線ノードのサービス・エリアから第２の無線ノードのサービス・エリアへ移動した後に休眠中の状態にある場合に、第２の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための新たなセッションを確立することができ、または第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへＲＮＣ間での休眠中のハンドオフを実行することができる。第１の無線ネットワーク・コントローラおよび第１の無線ノードは、同一の場所に配置することができる。第２の無線ネットワーク・コントローラおよび第２の無線ノードは、同一の場所に配置することができる。
【００２１】
一態様においては、本発明は、無線ネットワーク内でモバイル・アクセス端末を使用してデジタル情報をやり取りする方法を特徴とする。この方法は、第２の無線ネットワーク・コントローラを通過することなく第１の無線ノードを介して、第１のモバイル・アクセス端末と第１の無線ネットワーク・コントローラとの間に確立された第１のトラフィック・チャネルを介してパケットを送信する工程と、第１の無線ネットワーク・コントローラを通過することなく第２の無線ノードを介して、第２のモバイル・アクセス端末と第２の無線ネットワーク・コントローラとの間に確立された第２のトラフィック・チャネルを介してパケットを送信する工程とを含む。この方法はまた、第２の無線ノードを介して第１のアクセス端末との間でパケットが受信または送信される場合に、第１のアクセス端末と第１の無線ネットワーク・コントローラとの間における第１のトラフィック・チャネルを保持する。この方法はまた、第１のアクセス端末から受信したパケットを外部のネットワーク（たとえばインターネット）へ送信する工程を含む。
【００２２】
実装形態は、下記の特徴のうちの１つまたは複数を含むことができる。この方法はまた、第１のアクセス端末が第３の無線ノードの付近にあることを検知すると、第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへ第１のトラフィック・チャネルのアクティブなハンドオフを実行する工程を含むことができる。この方法はまた、第１のアクセス端末が第３の無線ノードの付近にあることを検知すると、第１の無線ネットワーク・コントローラによって第１のトラフィック・チャネルを閉じる工程を含むことができる。
【００２３】
この方法はまた、第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第３のモバイル・アクセス端末のための第１のセッションを確立する工程と、アクセス端末によって送信される位置更新メッセージに基づいて第３のアクセス端末の大まかな位置を追跡把握する工程と、第３のアクセス端末が休眠中の状態にある間に、第１の無線ネットワーク・コントローラにおいて第３のアクセス端末のためのパケットを受信する工程と、第２の無線コントローラが第３のアクセス端末を呼び出すことを要求するメッセージを第２の無線コントローラへ送信する工程と、第３の無線ノードを介して第２の無線ネットワーク・コントローラからアクセス端末を呼び出す工程とを含むことができる。この方法はまた、第３の無線ノードにおいて、アクセス・チャネルを介して第３のモバイル・アクセス端末からトラフィック・チャネル要求メッセージを受信する工程と、第３の無線ノードから第２の無線ネットワーク・コントローラへトラフィック・チャネル要求メッセージを転送する工程と、第１の無線ネットワーク・コントローラから第２の無線ネットワーク・コントローラへの第１のセッションのハンドオフを実行する工程と、ハンドオフが完了した後に、第２の無線ネットワーク・コントローラと第３のアクセス端末との間にトラフィック・チャネルを確立する工程とを含むことができる。
【００２４】
無線ネットワーク・コントローラ（たとえば、第１の無線ネットワーク・コントローラ）は、複数のサーバ・カードを含むことができ、この方法はまた、複数のサーバ・カードから選択されたサーバ・カードのうちの１つの上で無線ネットワーク・コントローラと第１のモバイル・アクセス端末との間に第１のトラフィック・チャネルを確立する工程と、その選択されたサーバ・カードのアドレスを無線ネットワーク・コントローラから第１の無線ノードへ送信する工程と、リバース・リンクのトラフィック・チャネル・パケットを第１の無線ノードからその選択されたサーバ・カードのアドレスへ送信する工程と、その選択されたサーバ・カードのアドレスを第１の無線ネットワーク・コントローラから第２の無線ノードへ送信する工程と、リバース・リンクのトラフィック・チャネル・パケットを第２の無線ノードからその選択されたサーバ・カードのアドレスへ送信する工程とを含むことができる。
【００２５】
第１の無線ノードは、第１の周波数チャネル上で機能するように構成することができ、その一方で第２の無線ノードは、第１の無線ノードと同一の場所に配置して、第２の周波数チャネル上で機能するように構成することができる。この方法はまた、第１の周波数チャネル上で機能する第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、第２の周波数チャネル上で機能する第２の無線ノードを介して第２の無線ネットワーク・コントローラ上の第２のモバイル・アクセス端末のための第２のセッションを確立する工程と、第２の周波数チャネル上で機能する第２の無線ノードを介して第１の無線ネットワーク・コントローラ上の第３のモバイル・アクセス端末のための第３のセッションを確立する工程とを含むことができる。
【００２６】
この方法はまた、第１の周波数チャネル上で機能する第１の無線ノードと第１の無線ネットワーク・コントローラとの間における第１の関連付けを確立する工程と、第２の周波数チャネル上で機能する第２の無線ノードと第１の無線ネットワーク・コントローラとの間における第２の関連付けを確立する工程と、第１の周波数チャネル上で機能する第１の無線ノードを介して第１の無線ネットワーク・コントローラ上の第１のモバイル・アクセス端末のための第１のセッションを確立する工程と、アクセス端末が、休眠中のモードにある第２の無線ノードのモニタリングを開始した場合は常に、第１のセッションを第２の無線ネットワーク・コントローラへ転送する工程とを含むことができる。
【００２７】
この方法はまた、第１の周波数チャネル上で機能する第１の無線ノードを介して第１の無線ネットワーク・コントローラにおいて第１のモバイル・アクセス端末からの接続要求を受信する工程と、第１の無線ネットワーク・コントローラ上の第１のアクセス端末のための第３のトラフィック・チャネルを確立する工程であって、そのトラフィック・チャネルが、第２の周波数チャネル上で機能する第２の無線ノードを介して流れる工程とを含むことができる。
【００２８】
この方法はまた、第１の無線ネットワーク・コントローラによって第１および第２の無線ノードから受信される実際の負荷の情報に基づいて第２の周波数チャネル上で機能する第２の無線ノードを介して流れる第３のトラフィック・チャネルを確立する工程を含むことができる。この方法はまた、第１および第２の無線ノード上の負荷の見積もりに基づいて第２の周波数チャネル上で機能する第２の無線ノードを介して流れる第３のトラフィック・チャネルを確立する工程をさらに含むことができる。
【００２９】
第１および第２の無線ネットワーク・コントローラは、それぞれ複数のサーバ・カードを含むことができ、この方法は、第１の無線ネットワーク・コントローラ内の第１のサーバ・カード上の複数のトラフィック・チャネルを処理する工程と、第１のサーバ・カードにおける過負荷の状況を検知する工程と、別のサーバ・カードへ転送するために、第１のサーバ・カード上でサービスを提供されているトラフィック・チャネルを選択する工程と、そのトラフィック・チャネルを中断することなく、その選択されたトラフィック・チャネルを無線ネットワーク・コントローラのうちの１つの中の別のサーバ・カードへ転送する工程とをさらに含むことができる。
【００３０】
転送するためにトラフィック・チャネルを選択する工程は、選択されたトラフィック・チャネルによって使用されている処理中のリソースの量に、および／または複数のトラフィック・チャネル上のトラフィックのサービスの質の要件に少なくとも部分的に基づくことができる。無線ネットワーク・コントローラ内のその他のカードの負荷および利用可能度に少なくとも部分的に基づいて、選択されたトラフィック・チャネルの転送先となるターゲット・サーバ・カードを決定する。ターゲット・サーバ・カードは、第１のサーバ・カードと同じ無線ネットワーク・コントローラ内に配置することもでき、あるいは第１のサーバ・カードとは異なる無線ネットワーク・コントローラ内に配置することもできる。
【００３１】
１つまたは複数の無線ネットワーク・コントローラ内におけるサーバ・カードの負荷に関する情報は、中央集権化されたロード・トラッカーによって提供することができ、このロード・トラッカーは、無線ネットワーク・コントローラ内に配置されているか、またはすべての無線ネットワーク・コントローラに対して外部にある。中央集権化されたロード・トラッカーは、第１のサーバ・カードからターゲット・サーバ・カードへのトラフィック・チャネルの転送を引き起こすように構成することができる。いくつかの実装形態においては、負荷の情報は、１つのサーバ・カードによって直接その他のサーバ・カードから得ることができる。
【００３２】
この方法はまた、Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌネットワークを使用して、第１の無線ネットワーク・コントローラと第１および第２の無線ノードとの間でデータ・パケットをやり取りする工程を含むことができる。
【００３３】
別の態様においては、本発明は、モバイル・アクセス端末と無線通信するための無線アクセス・ネットワークを特徴とし、この無線アクセス・ネットワークは、ネットワーク（たとえばＩＰネットワーク）を使用して複数の無線ネットワーク・コントローラと相互接続されている複数の無線ノードであって、それぞれの前記無線ノードが、それぞれの前記無線ネットワーク・コントローラをアドレス指定することができ、それぞれの前記無線ネットワーク・コントローラが、それぞれの前記無線ノードをアドレス指定することができる複数の無線ノードと、無線アクセス・ネットワークと外部のネットワークとの間でパケットをやり取りするためのインターフェースとを含む。
【００３４】
実装形態は、下記の特徴のうちの１つまたは複数を含むことができる。無線ノードおよび無線ネットワーク・コントローラは、共通のサブネットワークに関連付けることができる。それぞれの無線ネットワーク・コントローラは、トラフィック・チャネルがどの無線ノードを流れているかにかかわらず、そのトラフィック・チャネルを保持するように構成することができる。無線ネットワーク・コントローラは、無線ノードのうちのいずれか１つを介してアクセス端末との間でパケットを経路指定することによって、トラフィック・チャネルを保持することができる。それぞれの無線ノードは、複数の無線ネットワーク・コントローラから選択された第１の無線ネットワーク・コントローラに関連付けることができ、それらの無線ネットワーク・コントローラのそれぞれは、無線ノードのうちのいずれかを介して呼び出しメッセージをアクセス端末へ送信することを可能にすることができる。
【００３５】
それぞれの無線ネットワーク・コントローラは、複数のサーバ・カードを含むことができ、それらの複数のサーバ・カードは、それぞれネットワークに接続されており、無線ノードのそれぞれによってアドレス指定することができる。無線ネットワーク・コントローラは、複数のサーバ・カードのそれぞれの上でアクセス端末とのトラフィック・チャネルを確立するように構成することができる。無線ネットワーク・コントローラは、１つまたは複数の無線ノードへのトラフィック・チャネルが確立されているサーバ・カードのアドレスを提供するように構成することもできる。それぞれの無線ネットワーク・コントローラは、自分の複数のサーバ・カードのうちの１つにおける過負荷の状況を検知して、別のカードへ転送するために、過負荷になっているカードによって処理されている１つまたは複数のトラフィック・チャネルを選択するように構成することもできる。
【００３６】
複数の無線ノードは、同一の場所に配置されている２つの無線ノードを含むことができ、第１の無線ノードは、第１の周波数チャネル上で機能するように構成されており、第２の無線ノードは、第２の周波数チャネル上で機能するように構成されている。
【００３７】
インターフェースは、パケット・データ・スイッチング・ノードとすることもでき、あるいは無線ネットワーク・コントローラのうちの１つの一部とすることもできる。
【００３８】
実装形態は、下記の利点のうちの１つまたは複数を実現することができる。すべての無線ノードとすべての無線ノード・コントローラとの間に第１または第２の関連付けを確立することによって、無線ノード・コントローラは、アクセス端末が１つの無線ノードのサービス・エリアから別の無線ノードのサービス・エリアへ移動する際に、ＩＰの帰路上の任意の無線ノードを見つけて通信するのに必要な情報を有する。これによって無線ネットワークは、アクセス端末が、その時点で自分にサービスを提供しているＲＮＣとは異なる第１のＲＮＣを有する無線ノードのサービス・エリア内へ移動した場合でさえ、通常のソフト・ハンドオフを実行することができる。これによって、エラーが発生しやすく、さらなる待ち時間がもたらされることで知られている、より伝統的なＲＮＣ間でのハンドオフの手続きが回避される。本発明の一実装形態は、上述の利点のすべてを提供する。
【発明を実施するための最良の形態】
【００３９】
ＩＳ−８５６に関して前述したものを含む既存の３Ｇ無線ネットワーク・アーキテクチャは、ＲＮとＲＮＣとの間における固定された関係を前提としている。すなわち、１つのＲＮから、または１つのＲＮへと流れるすべてのトラフィックは、同じＲＮＣを経由する。これは、ＲＮＣどうしの間における休眠中のハンドオフを処理するために複雑な階層構造を必要とし、頻繁で遅延しやすいＲＮＣ間での（ソフト）ハンドオフを必要とする。図１および図２に示されているように、ＲＮとＲＮＣとの間における帰路接続のためにポイントツーポイントの専用回線が使用されている場合には、回線交換方式の音声用途において、ＲＮとＲＮＣとの間における固定された関連付けが必要とされる。
【００４０】
以降の例においては、ＲＮＣは、ＩＰネットワークに直接接続されている無線ネットワーク・コントローラを表している。直接接続されているということは、ＲＮＣが、ＩＰ層の上でいかなる中間処理も伴わずにＩＰネットワーク内のその他のノードとの間でＩＰパケットを送信／受信することができるということを意味している。ＲＮＣは、シャーシベースのハードウェア・プラットフォーム上に実装することができ、このシャーシベースのハードウェア・プラットフォームは、複数のサーバ・カードから構成することができる。この場合には、シャーシ全体は、ＩＰネットワークに直接接続されているＲＮＣとみなすことができ、個々のサーバ・カードは、ＩＰネットワーク内のその他のノードとの間でＩＰパケットを送信／受信するようにＩＰ層の上で機能する中間ノード（またはＩ／Ｏサーバ・カード）を必要とする。ある代替実装形態においては、シャーシベースのハードウェア・プラットフォーム内の個々のサーバ・カードは、ＩＰネットワークに直接接続することができる。この場合には、これらのサーバ・カードは、個々のＩＰアドレスを有することができ、そしてそれらは、それぞれＲＮＣとみなすことができる。ＲＮＣは、従来の計算サーバやブレード・サーバなど、スタンドアロンのサーバ・ハードウェア上に実装することもできる。この場合には、サーバは、ＲＮＣとみなすことができ、無線アクセス・ネットワーク内のその他のＲＮおよびＲＮＣにとって明らかなＩＰアドレスを有する。
【００４１】
ＲＮＣ間での信号伝達を伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャ
はじめに、図３に示されているように、１組のＲＮＣ  ６０が同一のデータ・センタ内に配置されており、Ｇｉｇａｂｉｔ  Ｅｔｈｅｒｎｅｔ（登録商標）  ＬＡＮなどの高速ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）６２を介して共に接続されている場合について考察する。この場合には、ＲＮＣは、ＬＡＮインターフェースを介してネットワークに接続され、ルータ６４は、外部のネットワークへの接続を提供する。このような構成は、ＲＮＣクラスタ（またはプール）と呼ぶことができる（以降の記述は、大都市エリアのネットワークなど、より一般的なＩＰネットワークを介して接続されるＲＮＣへ同じコンセプトをいかに拡張することができるかについて説明する）。かつて、無線ネットワークを通じて搬送される主なトラフィック・タイプが回線交換方式の音声であった時代には、イーサネット（登録商標）ＬＡＮを使用したこのようなクラスタリングは、実現可能ではなかった。ＲＮは、専用回線６６を使用してデータ・センタ内のルータへ接続することができる。ＲＮおよびＲＮＣは、すべてＩＰアドレスの指定が可能であると想定される。すなわち、クラスタによってサービスを提供されるいかなるＲＮも、そのクラスタ内のその他のＲＮＣのいずれともＩＰレベルにおいて直接通信することができる。
【００４２】
上述のものなどのＲＮＣクラスタにおいては、個々のＲＮＣどうしの間におけるいかなるハンドオフ境界も回避することが重要であり、それによってクラスタ全体は、まるでそのクラスタが１つの大きなＲＮＣであるかのように機能することができる。これによって、モビリティに起因する不要なハンドオフがなくなり、それによって、拡張性および信頼性が大幅に改善されることになる。
【００４３】
これを達成するためには、たとえば１つの例においては、ＩＳ−８５６サブネット７０は、１つのＲＮＣのみの電波到達範囲ではなく、ＲＮＣクラスタの電波到達範囲の全体であると定義される。すなわち、クラスタによってサービスを提供されるすべてのＲＮは、同じサブネットに属することになる。システムのオペレーションを単純化するために、サブネット内のそれぞれのＲＮは、クラスタ内の１つのＲＮＣに関連付けられる（たとえば、第１の関連付け）。この関連付けは、ＲＮが最初に電源を投入されたときに確立される。この関連付けの詳細な意味については、後ほど説明する。
【００４４】
アクセス・チャネル・パケットの経路指定
１つのＲＮ内のそれぞれのセクタは、フォワード・トラフィックまたはコントロール・チャネル７２を介してＡＴへの送信を行うことができる。同様に、１つのＲＮ内のそれぞれのセクタは、リバース・トラフィックまたはアクセス・チャネル７４を介してＡＴからの受信を行うことができる。アクセス・チャネルとリバース・トラフィック・チャネルは、Ｌｏｎｇ  Ｃｏｄｅ  Ｍａｓｋを使用した符号分割多重化によって切り離されており、その一方でコントロール・チャネルとフォワード・トラフィック・チャネルは、プリアンブルを使用した時分割多重化によって切り離されている。プリアンブルは、フォワード・リンクの物理層パケットをコントロール・チャネル・パケットとして、または特定のＭＡＣ  Ｉｎｄｅｘに関連付けられているトラフィック・チャネル・パケットとして識別する。０〜６３の整数であるＭＡＣ  Ｉｎｄｅｘは、１つのセクタ内で一意であり、トラフィック・チャネルが確立された時点でＲＮおよびＲＮＣによって割り当てられる。同様に、Ｌｏｎｇ  Ｃｏｄｅ  Ｍａｓｋは、リバース・リンクの物理層パケットをアクセス・チャネル・パケットとして、または特定のトラフィック・チャネル・パケットとして識別する。Ｌｏｎｇ  Ｃｏｄｅ  Ｍａｓｋは、トラフィック・チャネルに関してはＡＴのＵＡＴＩに基づき、アクセス・チャネルに関してはサービス提供中のセクタのＳｅｃｔｏｒＩＤに基づく。アクセス・チャネル・パケットの送信側ＡＴ、およびコントロール・チャネル・パケットの受信側ＡＴは、ＭＡＣ  ＬａｙｅｒヘッダのＡＴＩフィールド内に示されている。
【００４５】
ＲＮは、そのアクセス・チャネルの１つの上でＭＡＣ  Ｌａｙｅｒパケットを受信した場合は常に、そのパケットを、その中身を見ることさえせずに、そのＲＮが関連付けられているクラスタ内のその第１の（すなわちＤｅｆａｕｌｔの）ＲＮＣへ転送する。そのようなものとして、ＵＡＴＩ＿Ｒｅｑｕｅｓｔメッセージを搬送しているパケットがＡＴから受信されると、そのパケットは、受信側ＲＮによって第１のＲＮＣへ転送される。そのＲＮは、ＭＡＣ  Ｌａｙｅｒパケットを、（場合によっては、その他のＡＴのＭＡＣ  Ｌａｙｅｒパケットと共に多重化して）サービス提供側ＲＮＣのＩＰアドレスに相当する送信先のＩＰアドレスと共に１つのＩＰパケット内にカプセル化する。そのＩＰパケットは、帰路ネットワークを介してデータ・センタの集約ルータへ搬送され、このルータは、そのパケットを、イーサネット（登録商標）ＬＡＮを介してサービス提供側ＲＮＣへ転送する。
【００４６】
すべてのアクセス・チャネル・パケットには、送信側ＡＴを識別する１つのアドレス・フィールドが含まれる。送信側ＡＴが、ＲＮＣによって既にＵＡＴＩを割り当てられている場合には、アドレス・フィールドには、そのＵＡＴＩが含まれる。送信側ＡＴが、まだＵＡＴＩを有していない場合には、アドレス・フィールドには、ＲＡＴＩ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ  Ｉｄｅｎｔｉｆｉｅｒ）が含まれ、これは、そのＡＴによって無作為に選択される。アドレス・フィールドの最初の２ビットは、そのアドレスがＵＡＴＩであるか、またはＲＡＴＩであるかを示している。
【００４７】
あるＲＮＣの（イーサネット（登録商標））Ｉ／Ｏサブシステムが、ＲＡＴＩまたは認識されていないＵＡＴＩを含むアドレス・フィールドを有するＡＴからのＵＡＴＩ＿Ｒｅｑｕｅｓｔメッセージを受信した場合には、そのＲＮＣは、セッションを処理するサービス提供側ＲＮＣの役割を担う。そのＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、そのＲＮＣは、そのセッションをそのサーバ・カードのうちの１つに割り当てる。次いでそのＡＴには、何らかの所定の範囲内のＵＡＴＩが割り当てられる。この範囲は、クラスタ内におけるその他のすべてのＲＮＣに対するサービス提供側ＲＮＣを識別し、クラスタ内のすべてのＲＮＣに知られているが、ＡＴには知られていない。そのＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、特定のＲＮＣに属するＵＡＴＩの範囲は、そのセッションを処理しているサービス提供側ＲＮＣ内のサーバ・カードを識別するためにさらに分割することができる。サービス提供側ＲＮＣはまた、ＡＴとＰＤＳＮとの間におけるデータの転送を容易にするためにＰＤＳＮとのＡ１０接続を確立する。Ａ１０接続は、そのセッションを処理しているサーバ・カード上で終了する。
【００４８】
休眠している間、ＡＴは、必要に応じてＲｏｕｔｅＵｐｄａｔｅメッセージを送信して、その現在の位置に関する情報を提供する。このモビリティ情報は、サービス提供側ＲＮＣ内のＭｏｂｉｌｉｔｙ  Ｍａｎａｇｅｒにおいて保持される。サブネットは、ＲＮＣクラスタの電波到達範囲の全体をカバーしているため、ＡＴは、同じクラスタ内の２つのＲＮＣの間の境界を越えたときに、サブネットの変化を検知せず、したがって休眠中のハンドオフを開始しない。しかしＡＴが、クラスタ内の別のＲＮＣ（ブローカーＲＮＣ）に関連付けられているＲＮへアクセス・チャネル・メッセージを送信すると、そのメッセージを搬送している（１つまたは複数の）パケットは、そのＲＮによってブローカーＲＮＣへ送信される。ブローカーＲＮＣ内のＩ／Ｏサブシステムは、着信するすべてのアクセス・チャネル・パケットのアドレス・フィールドを検査して、ＵＡＴＩを読み取る。そのＵＡＴＩから、Ｉ／Ｏサブシステムは、テーブルの参照によって、どのサービス提供側ＲＮＣかを割り出し、高速ＬＡＮを介してそのＲＮＣへアクセス・チャネル・パケットを転送する。そのアクセス・チャネル・パケット上のＵＡＴＩが、受信側ＲＮＣによってサービスを提供されたときに、その受信側ＲＮＣは、そのパケットをローカルで処理する。受信側ＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、そのＩ／Ｏサブシステムは、ＵＡＴＩ（セッション）を処理しているサーバ・モジュール（カード）をはじめに割り出し、次いでサービス提供側ＲＮＣの内部バスを使用して、そのカードへパケットを転送する。
【００４９】
呼び出しの経路指定
パケット・データが、休眠中のＡＴ用としてＰＤＳＮから受信された場合には、それらのパケットは、Ａ１０インターフェースを介してサービス提供側ＲＮＣ上の特定のサーバ・カードへ転送される。次いでそのサーバ・カードは、そのＡＴに関する位置情報を検索する。そしてサービス提供側ＲＮＣは、そのＡＴから受信された最新のＲｏｕｔｅＵｐｄａｔｅメッセージに基づいて割り出される１組のＲＮを介して呼び出しメッセージを送信する。この呼び出しメッセージは、そのＲＮＣクラスタに属する１つまたは複数のセクタのコントロール・チャネルを介して送信される。この呼び出しメッセージを送信しているＲＮは、サービス提供側ＲＮＣに関連付けられていない可能性がある（すなわち、別の第１のＲＮＣを有する可能性がある）が、そのクラスタ内のＲＮＣのうちの１つに関連付ける必要がある。
【００５０】
接続（トラフィック・チャネル）の確立
サービス提供側ＲＮＣは、ＡＴから直接、またはブローカーＲＮＣを介してＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを受信すると、そのＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージに添付されているＲｏｕｔｅＵｐｄａｔｅメッセージ内でそのＡＴによって報告されているパイロット強度を検査する。システムのオペレーションを単純化するために、それぞれのＲＮの無線リソースは、そのＲＮが関連付けられているＲＮＣ内のＲａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ機能によって管理されるものと仮定する。さらに、１つのＲＮは、自分が関連付けられているＲＮＣとしか信号をやり取りすることができない。したがって、サービス提供側ＲＮＣは、その他のＲＮＣに関連付けられているＲＮを含むトラフィック・チャネルを確立したい場合には、はじめにそれらのＲＮＣ上のＲａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ機能と直接通信して、リソースが利用可能かどうかをチェックする。このような通信は、高速ＬＡＮを介して行われる（サービス提供側ＲＮＣは、ルックアップ・テーブルを使用して、ＲＮの第１のＲＮＣを割り出すことができる）。十分な無線リソースが利用可能である場合には、サービス提供側ＲＮＣは、ＲＮが関連付けられているＲＮＣを介してこれらのＲＮとの必要なトラフィック・チャネル通信リンクを確立し、ＴｒａｆｆｉｃＣｈａｎｎｅｌＡｓｓｉｇｎｍｅｎｔメッセージをＡＴへ送信して、トラフィック・チャネルのセットアップを開始する。トラフィック・チャネルが確立されると、パケットは、いかなるブローカーＲＮＣのいかなる関与も伴わずにＲＮとサービス提供側ＲＮＣの間で直接流れる。このような直接の経路指定によって、別のＲＮＣを通じた三者間での経路指定を含むソフト・ハンドオフの手続きに典型的に見られる遅延がなくなる。
【００５１】
新たなトラフィック・チャネルが、ＲＮＣクラスタの電波到達範囲の外側（別のサブネット）にあるＲＮを含む場合には、同様の手続きが実施される。この場合には、サービス提供側ＲＮＣは、ＩＰネットワーク（大都市エリアのネットワーク）を介してそのクラスタの外側のＲＮＣと通信して、無線リソースを入手する。無線リソースが利用可能である場合には、サービス提供側ＲＮＣは、これらのＲＮが関連付けられているＲＮＣを介して信号をやり取りすることによって、そのＲＮとの通信リンクを確立する。
【００５２】
この方法によって、サービス提供側ＲＮＣは、そのサービス提供側ＲＮＣとは異なるＲＮＣに関連付けられているＲＮのサービス・エリア内へＡＴが移動した場合でさえ、トラフィック・チャネルを保持することができる。
【００５３】
ＲＮＣ間での信号伝達を伴わない改良されたＩＰベースの無線ネットワーク・アーキテクチャ
ここまで説明したスキームは、２〜３の領域で改良することができる。第１に、経路指定機能をＲＮへ移転することによって、ブローカーＲＮＣを介したアクセス・チャネル・パケットの三者間での経路指定をなくすことができる。これによって、ＲＮにおける処理能力をいくらか増強することと引き換えに、たとえばトラフィック・チャネルのセットアップ中にアクセス・チャネル・パケットを処理する際の遅延が少なくなる。さらに、ＲＮＣどうしの間におけるすべての信号伝達をなくすことができ、その代わりにＲＮＣは、無線アクセス・ネットワーク内のすべてのＲＮと信号を直接やり取りすることができる。これは、展開および保守がさらに容易なより単純なネットワーク・アーキテクチャを作成する上で役に立つ。
【００５４】
Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ機能は、ＲＮＣからＲＮへ移転することもでき、それによって、トラフィック・チャネルのセットアップ手続きにおける遅延がさらに少なくなる。
【００５５】
本明細書に記載のＩＰベースの無線アクセス・ネットワークとその拡張バージョンの双方によって、ＩＰおよび大都市のイーサネット（登録商標）・ネットワークの柔軟性を活用することができ、その結果、より分散されたシステムが形成され、ＡＴは、そのＡＴとサービス提供側ＲＮＣとの間の距離が過大になった場合を除いて、その位置を問わずに、そのサービス提供側ＲＮＣとの接続を保持することができる。これらの機能を提供するために、それぞれのＲＮは、複数のＲＮＣに、場合によってはＩＰベースの無線アクセス・ネットワーク内のすべてのＲＮＣに関連付けることができるが、ここでは、ＲＮＣのうちの１つを第１のＲＮＣとして機能させる必要はない。
【００５６】
アクセス・チャネル・パケットの三者間での経路指定の回避
はじめて電源を入れたときに、ＡＴは、次のようにしてＩＳ−８５６ネットワークへの登録を行う。ＡＴは、近隣のセクタのうちの１つによって放送されているＩＳ−８５６パイロットを入手して、システムと同期化する。セッションの確立を開始するために、ＡＴは、ＵＡＴＩ＿Ｒｅｑｕｅｓｔを送信する。前述のように、ＡＴは、ＭＡＣ  Ｌａｙｅｒヘッダ内のＲＡＴＩ（Ｒａｎｄｏｍ  ＡＴＩ）を使用して、この要求を送信する。
【００５７】
ＲＮは、アクセス・チャネル・パケットのアドレス・フィールドを検査して、メッセージの送信元が、割り当てられたＵＡＴＩを有していないということを認識し、そのＲＮが関連付けられているその第１のＲＮＣへパケットを転送する。アドレス・フィールドを検査するために、ＲＮはまず、受信したＭＡＣ  ＬａｙｅｒパケットからＭＡＣ  Ｌａｙｅｒカプセルの断片を抽出して、ＭＡＣ  Ｌａｙｅｒカプセルを形成する。次いでＲＮは、ＭＡＣ  Ｌａｙｅｒヘッダ内のアドレス・フィールドを読み取る。
【００５８】
ＵＡＴＩ＿Ｒｅｑｕｅｓｔを受信すると、第１のＲＮＣは、サービス提供側ＲＮＣの役割を担い、ＵＡＴＩをＡＴに割り当てる。次いで第１のＲＮＣは、セッション確立の残り、とりわけセキュリティー・キーの交換およびプロトコルの構成を進める（利用可能度を高めるため、およびより良好な負荷バランシングを提供するためのこの手続きの改良されたバージョンについては、以降でさらに詳しく説明する）。ＲＮＣはまた、ＡＴをそのＮＡＩ（Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｉｄｅｎｔｉｆｉｅｒ）に基づいて認証するためのＰＰＰ／ＣＨＡＰ手続きを実施する。ＮＡＩと端末の実際のＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）との間には、１対１の対応付けが存在する。この対応付けは、ＡＡＡ（Ｒａｄｉｕｓ）サーバ（図示せず）内に保持される。ＡＡＡサーバは、ＡＴのＩＭＳＩの値をサービス提供側ＲＮＣに渡す。
【００５９】
サービス提供側ＲＮＣ内のＰＣＦ（ｐａｃｋｅｔ  ｃｏｎｔｒｏｌ  ｆｕｎｃｔｉｏｎ）機能は、このＩＭＳＩの値を使用して、ＩＳ−２００１の規格に記載されているようにＰＤＳＮを選択し、そのＰＤＳＮへのＡ１０接続を確立する。Ａ１１  Ｒｅｇｉｓｔｒａｔｉｏｎメッセージにおいては、ＰＣＦ機能は、ＡＴのＩＭＳＩの値を、そのＡＴ自身のＳＩＤ／ＮＩＤ／ＰＺＩＤ識別子と共にＰＤＳＮに提供する。次いでＡＴおよびＰＤＳＮは、ＰＰＰリンクをセットアップし、Ｓｉｍｐｌｅ  ＩＰまたはＭｏｂｉｌｅ  ＩＰのセットアップを行い、ユーザレベルの認証を実行する。
【００６０】
それぞれのＲＮは、ＵＡＴＩとサービス提供側ＲＮＣとの間における対応付けのための経路指定テーブルを保持する。この経路指定テーブルは、ネットワーク管理システムによってＲＮに提供することができる。前のシステムの場合と同様に、それぞれのＲＮＣは、一定の範囲内に収まるＵＡＴＩの値を有する。ＲＮは、Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌパケットを受信した場合は常に、ＭＡＣ  Ｌａｙｅｒ  Ｈｅａｄｅｒ内のＵＡＴＩの値から、どのサービス提供側ＲＮＣかを割り出し、そのサービス提供側ＲＮＣのＩＰアドレスをＩＰヘッダの送信先アドレス・フィールド内に置くことによって、パケットをそのＲＮＣへ経路指定する。したがってアクセス・チャネル・パケットは、いずれのＲＮによっても、直接サービス提供側ＲＮＣへ送達される。それぞれのＲＮＣが有するＵＡＴＩの値の範囲は、そのＲＮＣによってＲＮへ直接伝達することができ、これによって、ＵＡＴＩの範囲を用いて管理システムからＲＮを明示的に構成する必要がなくなる。
【００６１】
上述の方法は、ＲＮが、ＵＡＴＩをＲＮＣのＩＰアドレスに対応付けるためのテーブルを保持することを必要とする。あるいは、ＵＡＴＩのスペースをすべてのＲＮＣの間で分割し、それぞれのＲＮＣに一意のサブスペースを割り当てることもでき、ＲＮＣのＩＰアドレスとＵＡＴＩのサブスペースとの間でアルゴリズム的な関係を確立することができる。次いでＲＮは、いかなるテーブルも使用することなく、ＡＴのＵＡＴＩからアルゴリズム的にＲＮＣのＩＰアドレスを割り出すことができる。
【００６２】
アクセス・チャネル・パケットの経路指定が、中央の要素において、また分散された方法でＲＮにおいての双方で処理される複合型のスキームを有することも可能である。ここでは、場合によっては１つのＲＮＣ内に配置される中央のＵＡＴＩサーバが、ＵＡＴＩおよび関連付けられている新たなセッションをサービス提供側ＲＮＣに割り当てることを担当することができる。新たなセッションを最初に確立したときに、ＲＮＣは、新たなＵＡＴＩを中央のＵＡＴＩサーバに要求することができる。サービス提供側ＲＮＣは、ＵＡＴＩとサービス提供側ＲＮＣの間の結び付きを確立する中央集権化されたＡＣルータに登録することもできる。ＲＮは、はじめてＡＴにサービスを提供しているときに、パケットをＵＡＴＩルータへ転送することができ、次いでそれが、パケットをＵＡＴＩルータへ転送することができる。次いでサービス提供側ＲＮＣは、サービス提供側ＲＮとの結び付きの更新を実行することができ、それによって、その後のすべてのトランザクションにおいて、アクセス・チャネル・パケットを直接サービス提供側ＲＮＣへ送信することができ、三者間での経路指定が回避される。
【００６３】
ＲＮＣ間でのハンドオフの回避
前述のように、所与のＡＴに関するモビリティ管理は、もっぱらサービス提供側ＲＮＣによって処理される。ＡＴは、休眠中モードでは、距離に基づく位置の更新を提供するように構成されている。すなわち、サービス提供中のセクタが、ＲｏｕｔｅＵｐｄａｔｅメッセージを最後に送信したセクタから一定の距離以上離れた場合は常に、ＡＴは、Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌを介して、サービス提供中のセクタへ新たなＲｏｕｔｅＵｐｄａｔｅメッセージを送信する。このＲｏｕｔｅＵｐｄａｔｅメッセージは、ＲＮによってサービス提供側ＲＮＣへ転送され、そしてサービス提供側ＲＮＣは、ＡＴの位置を追跡把握する。
【００６４】
サービス提供側ＲＮＣは、ＡＴを呼び出したい場合には、そのＡＴから受信した最新のＲｏｕｔｅＵｐｄａｔｅメッセージ内に示されている時間および位置によって、呼び出しの送信元としたい１つまたは複数のＲＮをはじめに割り出す。ここでは、サービス提供側ＲＮＣが、無線アクセス・ネットワーク内のすべてのＲＮのＩＰアドレスを知っているものと仮定する。このＲＮＣは、ネットワーク管理システムから、または最初の電源投入中にＲＮがそのＲＮＣに関連付けられたときにそれらのＲＮから直接、この情報を入手することができる。サービス提供側ＲＮＣは、呼び出しメッセージをＲＮの適切なセットへ直接送信する。次いでこれらのＲＮは、自分のそれぞれのコントロール・チャネルを介してＡＴを呼び出す。
【００６５】
ＩＳ−８５６ネットワーク内のすべてのセクタは、自分のオーバーヘッド・チャネル内で自分のＳｅｃｔｏｒＩＤおよびＳｕｂｎｅｔ  Ｍａｓｋを放送している。比較的小さなネットワークに関しては、Ｓｕｂｎｅｔ  Ｍａｓｋをゼロに設定することができ、それによって、ネットワークの全体が１つの大きなサブネットであるということが示される。このシナリオにおいては、ＡＴがサブネットの変化を検知することはない。したがってＡＴは、最初のサービス提供側ＲＮＣへの接続を保持し、休眠中のＲＮＣ間でのハンドオフを引き起こさない。ＰＤＳＮへのＡ１０接続も、ＡＴの位置を問わずに固定されたままとなる。
【００６６】
無線アクセス・ネットワークは、地理的に広いエリアをカバーしている場合には、ＡＴがサービス提供側ＲＮＣからあまりにも遠くへ移動したときに、休眠中のＲＮＣ間でのハンドオフを強行することを自重する可能性がある。これは、サービス提供側ＲＮＣによって、たとえばＡＴからＲｏｕｔｅＵｐｄａｔｅメッセージを受信した際に引き起こされる可能性がある。あるいは、ゼロよりも大きいＳｕｂｎｅｔ  Ｍａｓｋを選択して、あまりにも遠く離れたＲＮＣどうしの間にサブネットの境界を導入することもできる。そしてＡＴがサブネットの境界を越えたときに、休眠中のハンドオフが発生し、Ａ１０接続が移転される。さらに、ＡＴには新たなＵＡＴＩが割り当てられ、セッション・パラメータが、古いサービス提供側ＲＮＣから新たなサービス提供側ＲＮＣへ転送される。
【００６７】
分散されたＲａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌを使用したより迅速なトラフィック・チャネルのセットアップ
以降に続くのは、Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  ＣｏｎｔｒｏｌをＲＮＣからＲＮへ移転すること、および無線アクセス・ネットワーク内のすべてのＲＮＣとＲＮとの間で直接の信号リンクを確立することによって、（前のスキームでは）複数のＲＮＣを含んでいたトラフィック・チャネルのためのセットアップ時間がいかに短くなるかに関する説明である。ＡＴが、新たなトラフィック・チャネルを始動するためにアクセス・チャネルを介してＲｏｕｔｅＵｐｄａｔｅメッセージと共にＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを送信する場合は常に、そのメッセージは、受信側ＲＮからサービス提供側ＲＮＣへすぐに転送される。サービス提供側ＲＮＣは、ＲｏｕｔｅＵｐｄａｔｅメッセージを検査して、Ａｃｔｉｖｅ  Ｓｅｔ内に含まれる可能性のあるセクタの見込みの高いセットを割り出す。次いでサービス提供側ＲＮＣは、これらのセクタが属するＲＮと直接通信して、トラフィック・チャネルおよび帰路リソースを要求する。これらのＲＮは、拒否するか、または受け入れて、必要とされている無線リソースを割り当てる。リソースがＲＮの十分なセットから利用可能である場合には、サービス提供側ＲＮＣは、トラフィック・チャネルの要求を受け入れて、Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌを介してＴｒａｆｆｉｃＣｈａｎｎｅｌ割り当てメッセージをＡＴへ送信する。次いでＡＴは、ＲＴＣ（Ｒｅｖｅｒｓｅ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）上で送信を開始する。ＲＮがＲＴＣを入手すると、ＲＴＣＡｃｋメッセージがＡＴへ送信されて、ＲＴＣ信号が入手されたことを示す。次いでＡＴは、ＴｒａｆｆｉｃＣｈａｎｎｅｌＣｏｍｐｌｅｔｅメッセージを用いて応答して、Ｔｒａｆｆｉｃチャネルのセットアップが完了したことを示す。
【００６８】
この手続きでは、それぞれのＲＮが、そのＲＮ上で利用可能なハードウェア・リソース、ならびにそのセクタの全体にわたる干渉の管理の双方に関して自分自身の無線リソースをコントロールする。結果として、承認コントロール機能が、ＲＮとサービス提供側ＲＮＣの間で分割される。ＲＮは、自分がコントロールするセクタに関するローカルな承認コントロールを提供し、その一方でサービス提供側ＲＮＣは、グローバルな承認コントロールを提供する。同様に、所与のトラフィック・チャネル内のあるセクタが、しばらくの間非アクティブになった場合には、そのセクタは、そのトラフィック・チャネルを閉じたいという要求をサービス提供側ＲＮＣへ送信することによって、そのトラフィック・チャネルを閉じるための手続きを開始することができる。次いでサービス提供側ＲＮＣは、そのセクタをそのトラフィック・チャネルから外してそのトラフィック・チャネルの全体を閉じるか、または何もしないかに関して全体的な決定を行う。
【００６９】
ＡＴとサービス提供側ＲＮＣの間でトラフィック・チャネルがセットアップされると、そのトラフィック・チャネルは、ＡＴがＩＰベースの無線アクセス・ネットワーク内のその他のＲＮのサービス・エリアへと移動した場合でさえ、そのサービス提供側ＲＮＣに固定されたままとなる。
【００７０】
ＲＮとＲＮＣとの間におけるパケットの経路指定に関するさらなる詳細
ＲＮ内のあるセクタが、リバース・トラフィック・チャネル上でＭＡＣ  Ｌａｙｅｒパケットを受信した場合には、そのセクタは、Ｃｏｎｎｅｃｔｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒを含むＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒを追加してから、そのパケットをＩ／Ｏカードへ転送する。Ｉ／Ｏカードは、Ｃｏｎｎｅｃｔｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒの値を使用して、サービス提供側ＲＮＣのＩＰアドレスを検索する。次いでＩ／Ｏカードは、ＭＡＣ  ＬａｙｅｒパケットをそのＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒと共に１つのＩＰパケット内にカプセル化し、そのＩＰパケットの送信先アドレスは、サービス提供側ＲＮＣのＩＰ  Ａｄｄｒｅｓｓに設定される。サービス提供側ＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、そのサービス提供側ＲＮＣ内のＩ／Ｏモジュールは、パケットを受信すると、ＵＡＴＩの値を読み取って、このセッションを処理するサーバ・モジュールを割り出す。次いでＩ／Ｏカードは、さらなる処理のために、そのパケットをＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒと共にそのサーバ・モジュールへ渡す。
【００７１】
ＲＮ内のあるセクタが、アクセス・チャネル上でＭＡＣ  Ｌａｙｅｒパケットを受信した場合には、そのセクタは、ＭＡＣ  Ｌａｙｅｒ  ＨｅａｄｅｒのＡＴＩフィールド内のＵＡＴＩをはじめに読み取り、次いでサービス提供中のセクタのＳｅｃｔｏｒＩＤと共に送信側ＡＴのＵＡＴＩを含むＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒを追加してから、そのパケットをＩ／Ｏカードへ転送する。ＲＮ内のＩ／Ｏカードは、この場合もやはりＵＡＴＩの値を使用して、サービス提供側ＲＮＣのＩＰアドレスを検索する。Ｉ／Ｏカードは、ＭＡＣ  ＬａｙｅｒパケットをそのＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒと共に１つのＩＰパケット内にカプセル化し、そのＩＰパケットの送信先アドレスは、サービス提供側ＲＮＣのＩＰ  Ａｄｄｒｅｓｓに設定される。そのＲＮＣが、シャーシベースのハードウェア・プラットフォーム上に実装されている場合には、そのサービス提供側ＲＮＣ内のＩ／Ｏモジュールは、パケットを受信すると、ＵＡＴＩの値を読み取って、このセッションにサービスを提供するサーバ・モジュールを割り出す。次いでＩ／Ｏカードは、さらなる処理のために、そのＭＡＣ  ＬａｙｅｒパケットをＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒと共にそのサーバ・モジュールへ渡す。
【００７２】
サービス提供側ＲＮＣは、フォワード・トラフィック・チャネル上で送信する準備の整ったＭＡＣ  Ｌａｙｅｒパケットを有している場合には、そのパケットの送信先となるＲＮのＩＰアドレスをはじめに検索する。次いでサービス提供側ＲＮＣは、そのＭＡＣ  ＬａｙｅｒパケットをＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒと共に１つのＩＰパケット内にカプセル化し、そのＩＰパケットの送信先アドレスは、ＲＮのＩＰ  Ａｄｄｒｅｓｓに設定される。ＲＮは、パケットを受信すると、Ｓｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒ内のＳｅｃｔｏｒＩＤの値を読み取って、そのパケットを送信することになるセクタを割り出す。次いでＲＮは、そのＭＡＣ  ＬａｙｅｒパケットをＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒと共に適切なモデム・カードへ渡し、そのモデム・カードは、ＭＡＣ  Ｉｎｄｅｘをプリアンブルとして使用してＦｏｒｗａｒｄ  Ｌｉｎｋ上で送信するようにＭＡＣ  Ｌａｙｅｒパケットをスケジュールする。
【００７３】
同様に、フォワード・リンク上において、サービス提供側ＲＮＣは、特定のセクタのＣｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ上で送信する準備の整ったＭＡＣ  Ｌａｙｅｒパケットを有している場合には、そのパケットの送信先となるＲＮのＩＰアドレスを割り出す。次いでサービス提供側ＲＮＣは、ＭＡＣ  ＬａｙｅｒパケットをそのＳｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒと共に１つのＩＰパケット内にカプセル化し、そのＩＰパケットの送信先アドレスは、ＲＮのＩＰ  Ａｄｄｒｅｓｓに設定される。ＲＮは、パケットを受信すると、Ｓｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒ内のＳｅｃｔｏｒＩＤの値を読み取って、そのパケットを送信することになるセクタを割り出す。次いでＲＮは、そのＭＡＣ  ＬａｙｅｒパケットをＳｅｃｔｏｒＩＤおよびＭＡＣ  Ｉｎｄｅｘと共に適切なモデム・カードへ渡す。そのモデム・カードは、コントロール・チャネル上で送信するようにそのパケットをスケジュールする。
【００７４】
障害回復および負荷バランシング
前述の改良されたＩＰベースの無線アクセス・ネットワーク・アーキテクチャは、無線ネットワークの全体的な信頼性を高めるようにさらに拡張することができる。
【００７５】
セッションの保持を伴わない障害回復
はじめに考察するアプローチでは、それぞれのＲＮは、電源投入時に、まずは第１のＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔと通信し、このＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、ＲＮＣのうちの１つまたは複数の中に存在することができ、あるいは別個の計算エンジンまたはサーバ上に存在することもできる。第１のＲｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、それぞれのＲＮをＰｒｉｍａｒｙ  ＲＮＣに割り当てる。次いでＲＮは、すべての新たなセッションの要求をそのＰｒｉｍａｒｙ  ＲＮＣへ経路指定する。
【００７６】
あるＲＮＣが、何らかの障害によって完全に連絡不可能になった場合には、そのＲＮＣによってサービスを提供されているすべてのＡＴは、自分たちのＩＳ−８５６セッションが失われたことを最終的に認識することになる。これらのＡＴのそれぞれは、Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌを介してＵＡＴＩ＿Ｒｅｑｕｅｓｔを送信することによって、新たなセッションを開始する。これらの要求のうちの１つを受信するすべてのＲＮは、それらの要求を自分の第１のＲＮＣへ経路指定する。任意の時点において、ＲＮが自分の第１のＲＮＣに連絡できない場合には、そのＲＮは、新たな第１のＲＮＣを第１のＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔにすぐに要求する。第１のＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔにも連絡できない場合には、ＲＮは、同様の要求を第２のＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔへ送信する。ＵＡＴＩ＿ＲｅｑｕｅｓｔがＰｒｉｍａｒｙ  ＲＮＣによって受信されると、Ｐｒｉｍａｒｙ  ＲＮＣは、ＡＴとの新たなＩＳ−８５６セッションをすぐに確立し、ＰＤＳＮとの新たなＡ１０接続をセットアップするための手続きをさらに開始する。
【００７７】
新たなＰｒｉｍａｒｙ  ＲＮＣの割り当ては、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔによって開始することもできる。これは、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔにサブネットワーク内のすべてのＲＮＣの健全性を継続的にモニタさせることによって達成することができる。ＲＮＣの障害を検知すると、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、影響されるすべてのＲＮとすぐに通信し、それらのＲＮを新たなＰｒｉｍａｒｙ  ＲＮＣに割り当てる。ＲＮをＰｒｉｍａｒｙ  ＲＮＣに割り当てる際に、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、負荷バランシングを実行して、そのユーザ・セッションが、利用可能なすべてのＲＮＣにわたって均等に配分されるようにすることができる。
【００７８】
負荷バランシング・セッションの割り当て
上述の方法は、ユーザ・セッションをＲＮＣに割り当てることをＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔに最終的に担当させることによって、さらに強化することができる。この場合には、第１の（すなわちＤｅｆａｕｌｔの）ＲＮＣ、または場合によってはＲＮそのものが、新たなＵＡＴＩ＿Ｒｅｑｕｅｓｔを受信すると、そのＰｒｉｍａｒｙ  ＲＮＣ（またはそのＲＮ）は、セッションをＲＮＣに割り当てるようＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔに要求する。ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、リソースの利用可能度、負荷、およびＲＮＣと、その時点でＡＴにサービスを提供しているＲＮとの距離に基づいて、セッションをＲＮＣに割り当てる。このアプローチは、ＲＮＣどうしの間でさらに良好な負荷バランシングを提供し、ＲＮＣの全体にわたってさらに動的にユーザ・セッションを配分しつつ、ＡＴの現在の位置を考慮に入れることも可能にする。ＲＮＣの障害の場合には、すべての新たなセッションの要求は、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔに着信し、次いでＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔが、やはり負荷およびその他の考慮事項に基づいて、これらのセッションを新たなＲＮＣに割り当てることになる。
【００７９】
ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔを使用して、負荷バランシングまたはその他の目的で休眠中のハンドオフを引き起こすこともできる。Ｐｈａｓｅ  １  ＩＳ−８５６ネットワークにおいては、休眠中のＲＮＣ間でのハンドオフは常に、サブネットの変化が検知された際にＡＴによって引き起こされる。上述のように、すぐに休眠中のハンドオフを行わないと、呼び出しデータが失われる結果になる可能性がある。
【００８０】
図３および図４に示されている改良されたＩＳ−８５６ネットワークにおいては、休眠中のハンドオフは、ＡＴの位置に基づいてネットワークによって開始することができる。ＲｏｕｔｅＵｐｄａｔｅを受信した際に、サービス提供側ＲＮＣは、（負荷バランシングまたはその他の理由で）ユーザ・セッションを別のＲＮＣへ転送することが望ましいと判断した場合には、Ｄｏｒｍａｎｔ  Ｈａｎｄｏｆｆ要求をＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔへ送信し、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔが、そのセッションを新たなＲＮＣに割り当てる。次いで新たなサービス提供側ＲＮＣは、新たなＵＡＴＩを割り当て、前のサービス提供側ＲＮＣからのセッションの転送を実行する。
【００８１】
ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔのコンセプトのさらに分散された実装形態においては、ＲＮＣは、ＲＮおよびその他のＲＮＣと絶え間なく通信して、すべてのＲＮに（それらの負荷を含む）経路指定情報を提供することができ、それによってそれらのＲＮは、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔを経由することなく、着信するセッション要求を正しいＲＮＣへ経路指定することができる。たとえばそれぞれのＲＮは、好ましいＲＮＣのリストを有することができ、新たなセッションをＲＮＣに割り当てることが必要な場合は常に、何らかのアルゴリズム（擬似ランダム選択、ラウンドロビンなど）に従ってこのリスト内のＲＮＣのうちの１つを選択する。もしも好ましいリスト内のあるＲＮＣが利用不可能になった場合には、ＲＮは、それを検知し（ＲＮがＲＮＣの障害を検知する上で役立つように、ＲＮとＲＮＣとの間でＫｅｅｐＡｌｉｖｅメッセージングを使用することができる）、そのＲＮＣをその好ましいリストから外す。このアプローチの欠点は、そのような動的な負荷情報をやり取りする結果として、何らかの帰路信号トラフィックが生じることである。
【００８２】
セッションの保持を伴う障害回復
いくつかのネットワークにおいては、ＲＮＣの障害の場合にユーザ・セッション情報を回復することが必要となる可能性がある。これによって、ＲＮＣの障害の直後に何百もの新たなセッションの要求のために引き起こされる可能性がある無線リンクの混雑がなくなる。ＲＮＣの障害の場合にセッションを保持するために、（サブネットワーク内のすべてのセッションに関して）そのような情報のコピーをＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔ内に保存することができる。
【００８３】
ＲＮＣに障害が発生して、ＡＴが新たなセッションを開始した場合には、その新たなセッションの要求は、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔに届く。次いでＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、新たなサービス提供側ＲＮＣをそれぞれのセッションに割り当てるだけでなく、セッション情報も提供し、それによって冗長なセッション確立の手続きを回避する。新たなＵＡＴＩがＡＴに首尾よく割り当てられると、ネットワークとの通信を再開することができる。ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、ＲＮＣが同じＰＤＳＮとＡ１０セッションを確立できるようにするために、Ａ１０インターフェースに関連する情報をさらに提供し、それによって新たなＰＰＰおよびＭｏｂｉｌｅ／Ｓｉｍｐｌｅ  ＩＰセッションのセットアップを回避する。
【００８４】
シャーシベースのＲＮＣにおいては、ＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、ホット・スタンバイを利用して特定の余分なカード上で作動することができる。そしてＲＮＣ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ａｇｅｎｔは、セッション情報の保存を担当する。サーバ・モジュールに障害が発生した場合には、セッションは、内部で別のサーバ・モジュールに割り当て直される。原理としては、このシステムのオペレーションは、ネットワークの全体にわたって機能するオペレーションと同じである。さらに、この場合には、ＰＤＳＮによって見られるＰＣＦの外部のＩＰアドレスを維持することができるため、ＰＤＳＮへのＡ１０セッションを再び確立することが不要である。
【００８５】
ＲＮＣとＰＤＳＮの統合
上述したＩＰベースの無線アクセス・ネットワーク・アーキテクチャの別の利点は、ＲＮＣの機能とＰＤＳＮの機能を単一のネットワーク要素内で結合することができるという点である。階層化された３Ｇパケット・データ・ネットワークにおいては、ＰＤＳＮは、階層内の最も高いポイントを表し、したがって複数のＲＮＣをサポートすることができる。新たな世代のＰＤＳＮは、数十万人のユーザおよび数個のＲＮＣをサポートすることを期待されている。
【００８６】
ＲＮとＲＮＣの間に専用のポイントツーポイントのリンクを有する既存の無線アクセス・ネットワークにおいては、ＰＤＳＮの機能をＲＮＣへ移行すると、サポートできるセッションの数が減ることになり、新たなＰＰＰおよびＳｉｍｐｌｅ／Ｍｏｂｉｌｅ  ＩＰの登録を含むＰＤＳＮどうしの間におけるハンドオフが頻繁に生じてコストがかさむ結果となるため、望ましくない。
【００８７】
本明細書に記載のＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、ＲＮＣどうしの間におけるハンドオフが発生する頻度は非常に低く、したがってＰＤＳＮの機能をＲＮＣへ統合することが可能となる。１つのアクティブな呼び出しに対しては、常に同じＲＮＣによってサービスを提供することができるため、ＰＤＳＮ間でのハンドオフは、１つのアクティブな呼び出しの間には通常は必要とされない。このようなアプローチはまた、ＲＮＣとＰＤＳＮの間におけるネットワークの形成を単純化し、拡張性および信頼性をさらに高める。
【００８８】
統合されたＰＤＳＮを有するＲＮＣにおいては、ＰＤＳＮの機能は、ＰＰＰの終了、Ｓｉｍｐｌｅ  ＩＰおよび／またはＭｏｂｉｌｅ  ＩＰのフォーリン・エージェント、およびＡＡＡクライアントの機能を含む。ＡＴが、１つのサブネット（たとえば１つのＲＮＣクラスタ）内に留まっている限り、ＰＤＳＮ間でのハンドオフは、まったく必要とされないであろう。
【００８９】
統合されたＲＮＣ／ＰＤＳＮに障害が発生した場合には、ＡＴをサポートしているすべてのセッション（無線インターフェース、ＰＰＰ、およびＳｉｍｐｌｅ／Ｍｏｂｉｌｅ  ＩＰのセッションを含む）は、別のＲＮＣ／ＰＤＳＮへ転送され、それによって、ＡＴと無線ネットワークの間におけるいかなる新たなセッションの確立も回避される。
【００９０】
ＲＮＣ／ＰＤＳＮをＲＮと統合することも可能である。この場合には、ＲＮＣ／ＰＤＳＮの機能は、同じ場所のＲＮと、あるいは同じ筐体内のＲＮとさえ同一の場所に配置することができる。
【００９１】
本開示に記載の方法は、ＲＮＣとＰＤＳＮとが、あるいはＲＮと、ＲＮＣと、ＰＤＳＮとが統合されている、すなわち同一の場所に配置されているネットワークに等しく適用することができるということが理解できるはずである。
【００９２】
第１／第２のＲＮＣの関連付けを伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャ
それぞれのＲＮは、上述のように、そのＲＮが関連付けられる（たとえば、第１の関連付けを確立する）第１の（たとえばデフォルトの）ＲＮＣを有する。帰路ネットワーク８０を使用して、それぞれのＲＮは、ＩＰ  ＲＡＮ内の１つまたは複数のその他のＲＮＣに関連付けることもでき、これらのＲＮＣは、そのＲＮに関する第２のＲＮＣと呼ばれる（たとえば、第２の関連付けを確立する）。ＲＮＣとの関連付けを行うために、そのＲＮは、自分自身に関する十分な情報を第２のＲＮＣに提供して、これらのＲＮＣがそのＲＮを介してＡＴと通信できるようにする。さらに、そのＲＮと第２のＲＮＣとの間における信号のやり取りをサポートするために、それらの間に信号接続が確立される。ＲＮＣはまた、第１のＲＮと第２のＲＮとを区別する。第１のＲＮは、そのＲＮＣとの第１の関連付けを有するＲＮである。第２の関連付けは、たとえばＲＮの電源が入ったときに確立することができる。
【００９３】
ＲＮは、ＡＴからアクセス・チャネル・パケットを受信すると、そのパケットを無分別に自分の第１のＲＮＣへ転送する。ＲＮのサービス・エリア内における休眠中のＡＴは、そのＲＮの第１のＲＮＣによってサービスを提供される。基本的な実装形態においては、同じ第１のＲＮＣを共有するすべてのＲＮは、同じ１ｘＥＶ−ＤＯサブネットに属する。ＡＴは、サブネットの境界を越えた場合には、ＵＡＴＩ−Ｒｅｑｕｅｓｔを自分のサービス提供側ＲＮへ送信し、次いでそのサービス提供側ＲＮは、その要求を自分の第１のＲＮＣへ転送する。このＵＡＴＩは、そのＲＮＣによってサービスを提供されていないため、そのＲＮＣは、１ｘＥＶ−ＤＯ  ＩＯＳにおいて定義されているＡ１３インターフェースに従って、古いサービス提供側ＲＮＣと共に休眠中のＲＮＣ間でのハンドオフのための通常の手続きを開始する。新たなＲＮＣも、Ａ１０ハンドオフを実行する。要するに、この方法は、ＲＮＣどうしの間における休眠中のハンドオフの境界を実際に保持する。
【００９４】
別々の１ｘＥＶ−ＤＯサブネットに属するＲＮが同じ第１のＲＮＣを共有できるようにすることも可能である。この場合には、ＡＴが、サブネットの境界を越えた際にＵＡＴＩ−Ｒｅｑｕｅｓｔを送信すると、そのメッセージは、その時点でそのＡＴにサービスを提供している同じ第１のＲＮＣへ転送される（というのは、その同じＲＮＣが、双方のサブネット内のＲＮにとって第１のＲＮＣであるためである）。次いで、自分がこのＵＡＴＩに既にサービスを提供していることを認識している第１のＲＮＣは、Ａ１３手続きまたはＡ１０ハンドオフを伴わずにＵＡＴＩの割り当てを進めることができる。
【００９５】
第１のＲＮＣは、休眠中のＡＴに関してＡ１０接続を介して着信データを受信した場合には、通常どおり呼び出し手続きを進める。この呼び出しメッセージは、このＲＮＣを第１のＲＮＣとして有するすべてのＲＮ、またはそれらのサブセットを介して再び送信される。
【００９６】
サービス提供側ＲＮＣは、トラフィック・チャネルのセットアップを要求するＡＴからのトラフィック・チャネル要求メッセージを受信した場合には、はじめにＲｏｕｔｅＵｐｄａｔｅメッセージを検査して、必要とされているパイロットを割り出し、それらのパイロットが配置されているＲＮを見つけ出す。次いでサービス提供側ＲＮＣは、これらのＲＮと連絡を取って、通常どおりトラフィック・チャネルをセットアップする。第１／第２の関連付けによって、ＲＮＣは、要求されているパイロットのＰＮオフセットをＲＮのＩＰアドレスに対応付けて、これらのＲＮとの間であらかじめ確立されている信号接続を使用して、すべてのハンドオフ行程をセットアップすることができる。いったんアクティブなトラフィック・チャネルが確立されると、サービス提供側ＲＮＣは、そのトラフィック・チャネル用のＲＮＣとして固定されたままとなる。サービス提供側ＲＮＣは、ＲＮの第２の関連付けを使用して、ＡＴが複数のサービス・エリアを通じて移動するにつれてＲＮを追加および除外する。
【００９７】
たとえば、あるＡＴが第１のＲＮとはじめて通信した際に、そのＲＮは、上述のように、自分の第１のＲＮＣ（すなわち、その第１のＲＮが第１の関連付けを有しているＲＮＣ）へ要求を転送する。いったんトラフィック・チャネルが確立されると、第１のＲＮＣは、ＡＴが第１のＲＮのサービス・エリアから第２のＲＮのサービス・エリアへ移動した際に、たとえその第２のＲＮがサービス提供側ＲＮＣとの第１の関連付けを有していなくても、そのトラフィック・チャネルの全体に関して依然としてサービス提供側ＲＮＣのままである。これによって、ユーザの行動（たとえば電話、データの転送）は、途切れることなく継続することができる。ＡＴは、第１のＲＮのサービス・エリアから第２のＲＮのサービス・エリアへ移動している間に、ＲｏｕｔｅＵｐｄａｔｅメッセージを送信することによって、第２のＲＮに関するパイロット強度情報をサービス提供側ＲＮＣに伝達する。同じ第１のＲＮＣを有するＲＮどうしの間における通常のソフト・ハンドオフの場合と同様に、この伝達は、ＡＴがまだ第１のＲＮを使用している間に行われる。ＲｏｕｔｅＵｐｄａｔｅメッセージを受信すると、サービス提供側ＲＮＣは、確立されている第２の関連付けのために第２のＲＮと通信することができ、この第２の関連付けは、上述のように、パイロット信号のＰＮオフセットおよびＲＮのＩＰアドレスなどの情報を含み、サービス提供側ＲＮＣは、第２のＲＮと連絡を取って、通信チャネルを確立することができる。上述のハンドオフの手続きの１つの魅力的な側面は、通常のソフト・ハンドオフとまったく同様に機能するという点である。唯一の相違点は、ＲＮとＲＮＣとの間における第２の関連付けであり、この第２の関連付けによって、ＲＮＣは、第１の関連付けを有していないＲＮとのトラフィック・チャネルをセットアップすることができる。
【００９８】
ＲＮは、自分のアクセス・チャネル・パケットを自分の第１のＲＮＣへ常に転送しているため、もはやＵＡＴＩに基づいてアクセス・チャネル・パケットの経路指定を実行する必要はない。これによって、ＩＰベースの無線アクセス・ネットワークの実装形態が大幅に単純化される。
【００９９】
シャーシベースのシステム
上述のコンセプトは、たとえばそれぞれのサーバ・カードをＩＰアドレスの指定が可能なＲＮＣとして、またはそれぞれのモデム・カードをＩＰアドレスの指定が可能なＲＮとして取り扱うことによって、シャーシベースのシステム内で使用することもできる。システムの論理的なオペレーションは変わらない。
【０１００】
しかし、多くのサーバ・カードを有する大きなネットワークにおいては、それぞれのサーバ・カードを１つの独立したＲＮＣとして取り扱うと、結果としてＲＮＣの数があまりにも多くなる可能性があり、ひいては多くの信号接続、およびＲＮとＲＮＣの関連付けが生じる可能性がある。この複雑さを隠す１つの方法は、シャーシ全体をＩＰアドレスの指定が可能な１つのＲＮＣとして取り扱い、内部のプロトコルを使用してシャーシ間での通信を処理することである。やはり上述のコンセプトを同じ方法で使用することができ、外側から見たときのＲＮＣおよびＲＮの論理なオペレーションは変わらない。以降の記述は、これらのコンセプトがシャーシベースのＲＮＣの内部のオペレーションにいかに影響を与えるかに関して、さらに詳しく説明している。
【０１０１】
上述の例のうちのいくつかにおいては、あるＲＮが、その第１のすなわちデフォルトのＲＮＣに関連付けられる際に、そのＲＮとＲＮＣとの間に信号接続が確立される。シャーシベースのシステムにおいては、サーバ・カードのうちの１つが、関連付けを実行して信号接続を終了させる役割を担うことができる。つまり、新たなＲＮがＲＮＣとの関連付けを望む場合には、そのＲＮは、サーバ・カードのうちの１つに内部で割り当てられる（そこの本拠とされる）。それ以降、そのＲＮＣとそのＲＮとの間におけるすべての信号伝達は、そのサーバ・カードを介して実行される。ＲＮＣ間での信号伝達を伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、シャーシベースのＲＮＣは、ＳＣ（ｓｙｓｔｅｍ  ｃｏｎｔｒｏｌｌｅｒ）カード内に存在することができるＲＮＣ間のトポロジ・マネージャを使用して、これらのＲＮがサービスを提供するＰＮオフセットおよびそれらがコントロールするＵＡＴＩスペースを含むその他のＲＮＣを見つけ出すことができる。システム・コントローラ・カードは、ＲＮに関する必要な情報を学習してその他のＲＮＣへ渡すために、サーバ・カードと通信する。
【０１０２】
シャーシベースのＲＮＣを利用するいくつかの実装形態においては、あるＲＮが、受信したＡＣパケットをシャーシベースのＲＮＣへ転送した場合に、そのパケットは、はじめにＩ／Ｏカードによって傍受され、このＩ／Ｏカードは、そのＡＣパケット内のＵＡＴＩアドレスを点検して、そのＵＡＴＩにサービスを提供しているサーバ・カードを割り出し、そのサーバ・カードへパケットを転送する。そのＵＡＴＩがローカルにサービスを提供されている場合には、Ｉ／Ｏカードは、そのＵＡＴＩにサービスを提供している特定のサーバ・カードを割り出し、そのサーバ・カードへパケットを転送する。このような転送を実行するために、Ｉ／Ｏカードは、ＵＡＴＩアドレスをＲＮＣに対応付けるテーブルを保持し、ローカルなＵＡＴＩアドレスをサーバ・カードにさらに対応付ける。
【０１０３】
シャーシベースのＲＮＣ内のあるサーバ・カードが、トラフィック・チャネルのセットアップを求める要求をＡＴから受信した場合には、このサーバ・カードはまず、受信したＰＮオフセットをＲＮ  ＩＰアドレスに対応付けることによって、アクティブなセットにとって必要とされるパイロットを有するＲＮのセットをＲｏｕｔｅＵｐｄａｔｅメッセージから割り出す。次いでこのサーバ・カードは、このサーバ・カードの本拠とされているＲＮと直接信号をやり取りして、必要とされるトラフィック・チャネル区間を確立する。同じＲＮＣシャーシの本拠とされているその他のＲＮが存在する場合、それらのＲＮに関しては、このサーバ・カードはまず、それらのＲＮが本拠とされているサーバ・カードを割り出す。このサーバ・カードは、同じシャーシを共有するこれらのサーバ・カードと連絡を取り、次いでこれらのサーバ・カードは、ＲＮと連絡を取って、トラフィック・チャネル区間を確立する。その他のＲＮＣシャーシの本拠とされているその他のＲＮに関しては、このサーバ・カードは、これらのＲＮＣと連絡を取る。次いでこれらのＲＮＣ内のＩ／Ｏカードは、それらのＲＮが本拠とされているサーバ・カードへ要求を経路指定する。そしてこれらのサーバ・カードは、それらのＲＮと連絡を取って、必要とされるトラフィック・チャネル区間を確立する。
【０１０４】
ＩＰ  ＲＡＮ内のすべてのＲＮとＲＮＣとの間では直接のＩＰ通信が可能であるため、すべてのトラフィック・チャネル区間は、ＲＮとサービス提供側ＲＮＣとの間で直接機能する。シャーシベースのＲＮＣのＩ／Ｏカードがトラフィック・チャネル・パケットを受信した場合には、そのＩ／Ｏカードは、そのトラフィック・チャネルが一意の接続識別子に基づいて処理されているサーバ・カードにそのパケットを転送する。
【０１０５】
いくつかの実装形態においては、それぞれのサーバ・カードに１つのＩＰアドレスを割り当てることができ、そのそれぞれのサーバ・カードは、トラフィック・チャネルにサービスを提供しているＲＮにそのアドレスを提供することができる。次いでそれらのＲＮは、トラフィック・チャネル・パケットを直接サービス提供側ＲＮＣへ送信することができる。次いでそれらのパケットは、接続識別子に基づいたさらに高い層の参照を必要とすることなく、Ｉ／Ｏカードを介してサーバ・カードへ経路指定される。
【０１０６】
シャーシベースのＲＮＣは、自分が第１のＲＮＣではないＲＮのサービス・エリア内にＡＴがいる場合でさえ、そのＡＴとの通信を保持することができる。すべてのユーザ・トラフィックは、直接ＲＮとサービス提供側ＲＮＣとの間で流れる。休眠中のＡＴがＩＰ  ＲＡＮの全体にわたって移動する場合には、サービス提供側ＲＮＣはＩＰ  ＲＡＮ内のいずれのＲＮを介してもＡＴを呼び出すことができるため、ＲＮＣ間でのハンドオフは（可能ではあるが）必要とされない。
【０１０７】
ＲＮＣ間での信号伝達を伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、上述のように、Ｓｙｓｔｅｍ  Ｃｏｎｔｒｏｌｌｅｒカードを介してＲＮＣどうしの間で見つけ出して通信が行われる。このアーキテクチャは、第１のＲＮＣがサービス提供側ＲＮＣではなく、パケットが別のシャーシベースのＲＮＣのＩ／Ｏカードを介して経路指定される場合には、アクセス・チャネル・パケットの三者間での経路指定を結果的にもたらすこともできる。また、ＲＮＣサーバ・カードの障害は、そのＲＮＣサーバ・カードの本拠とされているすべてのＲＮの障害をもたらす結果となる。ＲＮＣシャーシの全体に障害が発生した場合には、すべての第１のＲＮが失われる。
【０１０８】
ＲＮＣ間での信号伝達を伴わない改良されたＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、ＲＮは、ＩＰ  ＲＡＮ内の複数のＲＮＣとの関連付けを行い、ＵＡＴＩアドレスをサービス提供側ＲＮＣに対応付けるためのテーブルを保持する。このアプローチにおいては、ＲＮは、サブネットの情報と共に構成することができ、その一方で第１のＲＮＣを伴うその他の方法においては、この情報は、その第１のＲＮＣによって提供することができる。ＲＮはまた、ＩＰ  ＲＡＮ内の複数のＲＮＣとの信号接続を保持する。すべての信号伝達は、これでシャーシベースのＲＮＣ上のサーバ・カードのうちの１つにおいて終了するようになり、そのサーバ・カードは、そのＲＮを本拠とするように割り当てられる。ＲＮは、自分が本拠とされているサーバ・カードに自分のＩＰアドレスを含む自分自身に関する情報を提供する。次いでこのサーバ・カードは、その情報をシャーシベースのＲＮＣ内のその他のすべてのサーバ・カードに配信する。
【０１０９】
これらの例においては、ＲＮは、ＡＴからアクセス・チャネル・パケットを受信した場合には、ＵＡＴＩアドレス・フィールドを点検し、そのテーブルからサービス提供側ＲＮＣのＩＰアドレスを割り出し、次いでそのＲＮＣへパケットを転送する。シャーシベースのＲＮＣ内のＩ／Ｏカードは、そのパケットを傍受し、そのパケットをアクセス・チャネル・パケットとして識別し、ＵＡＴＩアドレスを点検し、このＡＴを取り扱っているサーバ・カードへそのパケットを経路指定する。トラフィック・チャネルのセットアップにおいては、サーバ・カードは、そのサーバ・カードの本拠とされているＲＮに直接連絡を取って、トラフィック・チャネル区間のセットアップを要求する。その他のＲＮに関しては、サーバ・カードはまず、そのＲＮが本拠とされている他のサーバ・カードを割り出し、その他のサーバ・カードと連絡を取り、次いでその他のサーバ・カードが、ＲＮと連絡を取って、トラフィック・チャネル区間をセットアップする。このアプローチにおいては、ＲＮＣは、経路指定を最適化するために発生しうるＲＮＣ間でのハンドオフを処理することを除いてＲＮＣ間での通信をまったく伴わない自律的なエンティティとして機能することができる。しかし、本拠の設定を処理するためのカード間での通信は存在する。
【０１１０】
たとえＲＮＣシャーシどうしの間における三者間での経路指定がなくなっても、すべてのパケットがＩ／Ｏカードを介して移動し、そのＩ／Ｏカードがさらに高い層の経路指定機能を実行する場合には、シャーシ内部での間接的な経路指定が存在する可能性がある。１つのサーバ・カードの障害は、そのサーバ・カードの本拠とされているＲＮの障害をもたらす結果となる。これらのＲＮは、ＲＮＣ上に存在するセッションのいずれにも、障害が発生したサーバ・カード以外のサーバ・カード上で依然として無事でいるセッションにさえ、もはやサービスを提供することはできない。このような問題は、シャーシ内のそれぞれのサーバ・カードがＩＰアドレスの指定が可能なＲＮＣとして機能する場合には、発生しない。この場合には、パケットは、直接ＲＮとＲＮＣサーバ・カードとの間で経路指定され、１つのサーバ・カードの障害が、ＲＮまたはその他のサーバ・カードに影響を及ぼすことはない。
【０１１１】
第１／第２の関連付けを伴うＩＰベースの無線アクセス・ネットワーク・アーキテクチャにおいては、１組のシャーシベースのＲＮＣが、ＩＰ帰路ネットワークを介して１組のＲＮに接続され、ＲＮのすべてとＲＮＣのすべてとの間で第１または第２の関連付けが存在する。
【０１１２】
それぞれのＲＮは、上述のようにそのＲＮが関連付けられる第１のシャーシベースのＲＮＣを有する。それぞれのＲＮは、ＩＰ  ＲＡＮ内のその他のシャーシベースのＲＮＣにも関連付けられ、これらは、そのＲＮに関する第２のＲＮＣと呼ばれる。そのＲＮは、自分自身に関する十分な情報を第２のＲＮＣに提供して、これらのＲＮＣがそのＲＮを介してＡＴと通信できるようにする。さらに、そのＲＮと第２のＲＮＣとの間における信号のやり取りをサポートするために、そのＲＮとその第２のＲＮＣとの間に信号接続が確立される。それぞれの場合において、ＲＮとシャーシベースのＲＮＣとの間における関連付けは、ＲＮＣシャーシ内のサーバ・カードのうちの１つを介して処理される。
【０１１３】
ＲＮが自分の第１のＲＮＣへ無分別に転送するアクセス・チャネル・パケットは、Ｉ／Ｏカードによって傍受され、このＩ／Ｏカードは、ＵＡＴＩフィールドを点検し、その時点でそのＵＡＴＩを処理しているサーバ・カードへそのパケットを転送する。ＲＮのサービス・エリア内における休眠中のＡＴは、そのＲＮの第１のＲＮＣ内のサーバ・カードによってサービスを提供される。同じ第１のＲＮＣを共有するすべてのＲＮは、同じ１ｘＥＶ−ＤＯサブネットに属する。ＡＴは、サブネットの境界を越えた場合には、ＵＡＴＩ−Ｒｅｑｕｅｓｔを自分のサービス提供側ＲＮへ送信し、次いでそのサービス提供側ＲＮは、その要求を自分の第１のＲＮＣへ転送する。このＵＡＴＩは、そのＲＮＣによってサービスを提供されていないため、ＵＡＴＩフィールドを点検した後のＩ／Ｏカードは、その要求をそのサーバ・カードのうちのいずれか１つへ転送する。次いでサーバ・カードは、１ｘＥＶ−ＤＯ  ＩＯＳにおいて定義されているＡ１３インターフェースに従って、古いサービス提供側ＲＮＣと共に休眠中のＲＮＣ間でのハンドオフのための通常の手続きを開始することができる。新たなサーバ・カードも、Ａ１０ハンドオフを実行する。
【０１１４】
別々の１ｘＥＶ−ＤＯサブネットに属するＲＮが同じ第１のＲＮＣを共有できるようにすることも可能である。この場合には、ＡＴが、サブネットの境界を越えた際にＵＡＴＩ−Ｒｅｑｕｅｓｔを送信すると、そのメッセージは、その時点でそのＡＴにサービスを提供している同じ第１のＲＮＣへ転送される（というのは、その同じＲＮＣが、別々のサブネット内のＲＮにとって第１のＲＮＣであるためである）。ＵＡＴＩアドレスを点検することによって、第１のＲＮＣ内のＩ／Ｏカードは、その時点でそのＵＡＴＩにサービスを提供しているサーバ・カードへそのパケットを転送することができ、次いでそのサーバ・カードは、Ａ１３手続きまたはＡ１０ハンドオフを伴わずにＵＡＴＩの割り当てを進めることができる。
【０１１５】
第１のＲＮＣが、休眠中のＡＴに関してＡ１０接続を介して着信データを受信した場合には、パケットは、やはりＩ／Ｏカードによって傍受され、そのＩ／Ｏカードは、点検後に、そのＡ１０リンクを処理しているサーバ・カードへそのパケットを転送する。次いでサーバ・カードは、通常どおり呼び出し手続きを進める。この呼び出しメッセージは、このＲＮＣを第１のＲＮＣとして有するすべてのＲＮ、またはそれらのサブセットを介して再び送信される。
【０１１６】
サーバ・カードは、トラフィック・チャネルのセットアップを要求するＡＴからのトラフィック・チャネル要求メッセージを受信した場合には、ＲｏｕｔｅＵｐｄａｔｅメッセージを検査して、必要とされているパイロットを割り出し、その時点でそれらのパイロットを処理している他のサーバ・カードを見つけ出す。そのサーバ・カードは、これらの他のサーバ・カードと連絡を取り、次いでこれらの他のサーバ・カードが、ＲＮと連絡を取って、通常どおりトラフィック・チャネルをセットアップする。第１／第２の関連付けによって、サーバ・カードは、要求されているパイロットのＰＮオフセットを、それらのＲＮが本拠とされているサーバ・カードに関する識別子に対応付け、これらの本拠とされているＲＮを通じてあらかじめ確立されている信号接続を使用して、すべてのハンドオフ区間をセットアップすることができる。
【０１１７】
上述の説明をさらに拡張して、サーバ・カードの障害の場合に信頼性を高めることができる。いくつかの例においては、１つのサーバ・カードに障害が発生すると、そのカードによってサービスを提供されるすべてのユーザ・セッションも失われる。つまりユーザは、かなりの時間にわたって連絡不可能なままとなる可能性がある。ユーザは、自分が連絡不可能であることに気づかない可能性もある。これを防止するために、ユーザ・セッションがはじめて確立されたときに、セッションの状態に関する情報のコピーが、別個のカード、たとえばシステム・コントローラ・カード上に保存される。セッション情報には、さまざまなプロトコル構成、モビリティ情報、ＵＡＴＩなどが含まれる。セッション・パラメータが変わると、システム・コントローラ・カード上のセッション情報が更新される。
【０１１８】
システム・コントローラ・カードは、ハートビート・シグナリング・メカニズムを使用して、サーバ・カードの障害を検知し、残りのサーバ・カードのうちのいずれか１つにセッションを割り当てる。新たなサーバ・カードは、自分が必ずＡＴとの接続を有するようにＵＡＴＩを割り当て直すことができる。この方法では、負荷のバランスがとれたＮ＋ｌの冗長性構成において余分なサーバ・カードを１つだけ使用することによって、障害の発生したサーバ・カード上にセッションを割り当て直すための十分なヘッドルームが存在するようになる。
【０１１９】
上述の技術のうちのいくつかは、１ｘＥＶ−ＤＯ無線インターフェース標準を採用しているが、これらの技術は、その他のＣＤＭＡおよびＣＤＭＡ以外の無線インターフェース・テクノロジーにも同様に適用することができる。この場合には、リンク層アドレス（ＡＴＩ）は、１ｘＥＶ−ＤＯにおいて使用されているＡＴＩとは若干異なるもの（たとえば、ｃｄｍａ２０００におけるＴＭＳＩ）にすることができ、呼び出しゾーン、ＰＣＦゾーンなど、その他のＲＮゾーンを、１ｘＥＶ−ＤＯサブネットの代わりに使用することができる。
【０１２０】
シャーシベースのＲＮＣにおける接続レベルでの負荷バランシングおよび過負荷コントロール
シャーシベースのＲＮＣにおいては、サーバ・カード上の負荷が、そのカードの処理能力および記憶能力を超えた場合には、そのカードによってサービスを提供されているすべてのユーザのパフォーマンスが影響を受ける可能性がある。そのような過負荷の状況を防止するために、接続レベルでの負荷バランシングを使用することができる。
【０１２１】
たとえば、処理およびメモリ使用量が過大になった場合には、サーバ・カードは、リソースが利用可能である可能性のある１つまたは複数のその他のカードへの、１つまたは複数の接続に関するアクティブなセッションの転送を引き起こすことができる。このような負荷バランシング・スキームまたは過負荷コントロール・スキームにおいては、シャーシ上のそれぞれのサーバ・カードの個々の負荷を追跡把握するためのシャーシ内の何らかの中央のエンティティ、たとえばシステム・コントローラ・カードを有することが望ましい。いくつかの実装形態においては、サーバ・カードは、過負荷になると、どの接続を別のカードへ転送するかを決定する。ここでは、サーバ・カードは、接続内の個々の流れのＱｏＳニーズ、このところ接続がどれぐらい多くの処理リソースおよびメモリ・リソースを使用しているかという点、ユーザのＱｏＳクラスなどを含むいくつかの基準のうちの１つを使用することができる。サーバ・カードは、どの（１つまたは複数の）接続を別のサーバ・カードへ転送したいかを決定したら、ＲＮＣに関連付けられている中央のロード・トラッカーに連絡を取り、これらの接続を転送できる（１つまたは複数の）ターゲット・サーバ・カードを要求する。
【０１２２】
中央のロード・トラッカーが、利用可能なサーバ・カードのリストを提供すると、過負荷になっているカードは、それらの利用可能なサーバ・カードのうちの１つまたは複数に直接連絡を取って、以降で論じるアクティブなＲＮＣ間でのハンドオフの手続きと同様のアクティブなセッションの転送（すなわちハンドオフ）を開始する。
【０１２３】
いくつかの実装形態においては、中央のロード・トラッカーは、事前対処的に負荷バランシングを引き起こす。たとえば中央のロード・トラッカーが、ＲＮＣサーバ・カードに不均等に負荷がかかっていることを検知した場合には、その中央のロード・トラッキング・エンティティは、アクティブなセッションの転送要求を、接続にサービスを提供できる比較的負荷の少ないサーバ・カードのＩＤと共に、過負荷になっているサーバ・カードへ送信する。
【０１２４】
いくつかの実装形態においては、負荷バランシングは、ＩＰベースの無線ネットワーク内における１つのクラスタ内の複数のＲＮＣにわたって実行される。たとえば、１つのクラスタ内のすべてのＲＮＣに対する中央のロード・トラッキング・エンティティは、それぞれのＲＮＣ内のローカルなロード・トラッカーと対話することによって、個々のＲＮＣの負荷全体を追跡把握する。中央のロード・トラッキング・エンティティは、クラスタ化されたＲＮＣどうしの間で負荷の不均衡を検知した場合には、過負荷になっているＲＮＣから比較的負荷の少ないＲＮＣへのアクティブなセッションの転送を引き起こす。１つのクラスタに関する中央のトラッキング・エンティティは、そのクラスタ内のＲＮＣのうちの１つの中に存在することもでき、あるいはそのクラスタ内のＲＮＣの外部に存在することもできる。
【０１２５】
上述の負荷バランシング・メカニズムおよび過負荷コントロール・メカニズムは、ＲＮＣの内部および／またはクラスタの内部に分散された方法で実装することができる。たとえば、１つのクラスタに関連付けられている中央のロード・トラッキング・エンティティの代わりに、そのクラスタ内のＲＮＣ内におけるローカルなロード・トラッキング・エンティティどうしが、お互いに直接負荷情報を共有することができる。このようにすると、ＲＮＣは、過負荷を経験しているときに、たとえばその他のローカルなロード・トラッキング・エンティティに連絡を取ってクラスタ内のその他のＲＮＣの利用可能度を割り出すことによって、アクティブなセッションをクラスタ内のどのＲＮＣへ転送するかを決定することができる。次いでＲＮＣは、利用可能なＲＮＣへのアクティブなハンドオフを引き起こすことができる。同様の戦略は、１つのＲＮＣ内における負荷バランシングを処理するために使用することもできる。
【０１２６】
１つのサーバ・カードに障害が発生した場合には、ＲＮＣ内の別の場所またはクラスタ内の外部の接続状態に関する重要な情報を保存するための何らかのメカニズムがない限り、そのサーバ・カードによって処理されているすべての接続も失われる。いくつかの実装形態においては、接続状態に関する情報は、ＲＮＣのシステム・コントローラ・カード上に提供することができる。したがって、１つのサーバ・カードに障害が発生した場合には、システム・コントローラは、その障害が発生したサーバ・カード上のトラフィック・チャネルをシステム内のその他のサーバ・カードに割り当てることができる。次いで、サーバ・カードに対する責任を負うサーバは、接続にサービスを提供しているすべてのセクタへのトラフィック・チャネル区間を確立し、ＰＤＳＮへのＡ１０リンクを復元し、無線リンク・プロトコルを初期化し、トラフィック・チャネルのオペレーションを再開する。
【０１２７】
部分的に接続された無線ネットワークにおける休眠中のハンドオフ
ＩＰベースの無線ネットワークにおいては、休眠中のＡＴは、その時点で自分にサービスを提供しているＲＮにかかわらず、複数のＲＮＣを介してネットワークに接続することができる。これらのＲＮＣは、自分たちがサービスを提供するＲＮと共に、１つのクラスタを形成する。すべてのＲＮが、すべてのＲＮＣとの完全な関連付けを有する場合には、そのようなクラスタは、メッシュＲＮＣクラスタと呼ばれる。メッシュＲＮＣクラスタの内部においては、休眠中のＡＴは、自分のサービス提供側ＲＮＣが、そのクラスタ内のＲＮのうちのいずれか１つを介してそのＡＴと通信することができるため、そのサービス提供側ＲＮＣへの接続を常に保持することができる。つまりサービス提供側ＲＮＣは、クラスタ内のどこでもＡＴを呼び出すことができ、休眠中のＡＴは、クラスタ内のどこでもサービス提供側ＲＮＣへアクセス・チャネル・メッセージを送信することができる。
【０１２８】
１つのＲＮが、１つのクラスタ内のそれぞれのＲＮＣとの関連付けを有さない場合には、そのクラスタは、部分的に接続されたクラスタと呼ばれる。部分的に接続されたクラスタにおいては、ＡＴは、その時点で自分にサービスを提供しているＲＮが、自分のサービス提供側ＲＮＣとの関連付けを有さない場合には、ネットワークの接続を失う可能性がある。つまりＡＴは、連絡不可能となる可能性があり、あるいは、たとえば新たな接続を要求するためにアクセス・チャネル・メッセージを自分のサービス提供側ＲＮＣへ送信することができないかもしれない。これが発生するのを防止するために、ＡＴのセッションは、サービス提供側ＲＮＣから、そのＡＴが接続を保持できる別のＲＮＣへ移転される。
【０１２９】
いくつかの実装形態においては、１つのクラスタ内のＲＮＣおよびＲＮは、複数のメッシュ・クラスタへとさらに分割され、別々のクラスタに属するＲＮどうしの間に１ｘＥＶ−ＤＯサブネットの境界が形成される。次いで休眠中のＡＴは、クラスタどうしの間におけるサブネットの境界を越えた場合は常に、ＵＡＴＩＲｅｑｕｅｓｔを送信して、いわゆるＡ１３のＲＮＣ間における休眠中のハンドオフを引き起こす。そのＵＡＴＩＲｅｑｕｅｓｔを受信したＲＮは、それを自分の第１のＲＮＣ（または自分のクラスタ内のＲＮＣのうちの１つ）へ転送し、次いでこのＲＮＣは、そのＵＡＴＩから、その時点でＡＴのセッションにサービスを提供しているＲＮＣを割り出し、Ａ１３の休眠中のハンドオフを引き起こす。したがってクラスタどうしの間でサブネットを作成することによって、休眠中のＡＴは、必ず常にネットワークに接続されたままとなる。
【０１３０】
アクティブなＡＴが、クラスタどうしの間におけるサブネットの境界を越えた場合には、サービス提供側ＲＮＣが、その他のクラスタ内のＲＮにトラフィック・チャネルを割り当てるのに必要な関連付けを有している限り、依然として接続を保持することができる。そうでない場合には、接続の境界に達する前に、アクティブなＲＮＣのハンドオフを実行しなければならない。
【０１３１】
いくつかの実装形態においては、部分的に接続されたクラスタは、ＡＴが、自分のサービス提供側ＲＮＣとの関連付けを有していないＲＮのサービス・エリアへ移動することができ、そのＡＴがもはや連絡不可能であることにそのサービス提供側ＲＮＣが気づかないようにすることができるように構成される。たとえば、ＡＴがＲｏｕｔｅＵｐｄａｔｅを最後に送信したセクタのＲｏｕｔｅＵｐｄａｔｅＲａｄｉｕｓによって割り出されるＡＴの現在の呼び出しエリアは、サービス提供側ＲＮＣとの関連付けを有さないＲＮを含むことができる。したがってＲＮＣは、このＡＴに関する呼び出しデータを受信した場合には、これらのＲＮを介してそのＡＴを直接呼び出すことはできない。この問題に対処するために、ＲＮＣは、自分が関連付けを保持しているすべてのＲＮに関して、呼び出しエリアのリストを保持する。この呼び出しエリアのリストは、ＲＮのＲｏｕｔｅＵｐｄａｔｅＲａｄｉｕｓによって割り出される。このリストは、ＲＮＣが関連付けを有している呼び出しエリア内のすべてのＲＮのＩＰアドレスを含むだけでなく、そのＲＮＣが関連付けをまったく有していないＲＮに関する第１のＲＮＣのＩＰアドレスも含む。サービス提供側ＲＮＣは、呼び出しデータを受信した場合には、関連付けを有しているＲＮへ直接Ｐａｇｅメッセージを送信し、その他のＲＮに関するＰａｇｅ要求をそれらの第１のＲＮＣへ転送し、次いでそれらの第１のＲＮＣが、呼び出しエリア内のそれらのＲＮを介してＡＴを呼び出す。サービス提供側ＲＮＣは、呼び出しメッセージを別のＲＮＣへ転送する場合には、その他のＲＮＣが、自分のＲＮのうちのどれを介して呼び出しメッセージを送信する必要があるかを割り出すことができるようにするためのさらなる情報を含める。
【０１３２】
いくつかの実装形態においては、サービス提供側ＲＮＣは、自分が第１のＲＮＣであるＲＮを介してのみ直接呼び出しメッセージを送信し、その他のＲＮに関しては、呼び出しメッセージをそれらの第１のＲＮＣへ転送し、次いでそれらの第１のＲＮＣが、呼び出しエリア内の自分のＲＮを介してＡＴを呼び出す。
【０１３３】
部分的に接続されたクラスタにおいては、ＡＴは、サービス提供側ＲＮＣとの関連付けをまったく有していないＲＮのサービス・エリア内にいる場合には、アクセス・チャネル・メッセージをネットワークに送信することができる。この場合には、サービス提供側ＲＮは、アクセス・チャネル・パケット内のＵＡＴＩフィールドから、自分が関連付けをまったく有していないＲＮＣによってそのパケットがサービスを提供されているということを認識すると、そのパケットを自分の第１のＲＮＣ（または負荷バランシング・アルゴリズムに基づいて選択するその他の何らかのＲＮＣ）へ転送する。そのＲＮの第１のＲＮＣは、受信したアクセス・チャネル・メッセージを処理する前に、Ａ１３の休眠中のハンドオフを引き起こし、この場合には、ＡＴのセッションは、ハンドオフ中にＳｏｕｒｃｅ  ＲＮＣの役割を担うことになるサービス提供側ＲＮＣから、ハンドオフ中にＴａｒｇｅｔ  ＲＮＣの役割を担うことになるそのＲＮの第１のＲＮＣへ転送される。Ｔａｒｇｅｔ  ＲＮＣは、受信したアクセス・チャネル・パケット内のＵＡＴＩからＳｏｕｒｃｅ  ＲＮＣのＩＰアドレスを得て、Ａ１３の要求メッセージをそのＳｏｕｒｃｅ  ＲＮＣへ送信する。ＡＴのセッション情報をＳｏｕｒｃｅ  ＲＮＣから受信した後に、Ｔａｒｇｅｔ  ＲＮＣは、そのＡＴに新たなＵＡＴＩを割り当て、Ａ１３のハンドオフを完了し、そして受信したアクセス・チャネル・メッセージを処理する。たとえば、そのアクセス・チャネル・メッセージがＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージであった場合には、Ｔａｒｇｅｔ  ＲＮＣは、含まれるＲＮに対するトラフィック・チャネル区間をセットアップし、Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ  Ａｓｓｉｇｎｍｅｎｔメッセージを送信する。ＡＴ内でタイマが切れる前にＴＣＡメッセージを送信するためには、Ｔａｒｇｅｔ  ＲＮＣがＡ１３のハンドオフの手続きを時間内に完了することが重要である。
【０１３４】
このセクションで説明した方法は、ＲＮＣの機能とＲＮの機能が、同じ基地局内で同一の場所に配置されている、すなわち統合されている分散されたＩＰベースの無線ネットワークにおいて使用することもできる。
【０１３５】
部分的に接続された無線ネットワークにおけるアクティブなハンドオフ
ＩＰベースの無線アクセス・ネットワークにおいては、ＲＮＣが、ネットワーク内のすべてのＲＮとの関連付けを有さないことも可能である。したがってサービス提供側ＲＮＣは、１つのＡＴ（ａｃｃｅｓｓ  ｔｅｒｍｉｎａｌ）のために１つのトラフィック・チャネルを無期限に保持することはできない。ＡＴは、サービス提供側ＲＮＣとの関連付けを有していないＲＮのサービス・エリア内へ移動した場合には、自分のサービス提供側ＲＮＣへの無線接続を徐々に失うことになる。接続が失われると、ＡＴは、上述のアクティビティによって引き起こされる休眠中のハンドオフの手続きを開始して、新たな接続を再び確立しようと試みる。関連付けの欠如によって引き起こされる中断を少なくするための１つの方法は、サービス提供側ＲＮＣが、自分が接続を有していないセクタによってＡＴにさらに良好にサービスを提供することができるということを認識すると、ＡＴが接続を閉じることを決定するまでに長い時間を要する可能性を回避するために、すぐに接続を閉じるという方法である。サービス提供側ＲＮＣによるこのような事前対処的な行動によって、いわゆる「無線周波数を引きずる問題」（ＲＦ  ｄｒａｇｇｉｎｇ  ｐｒｏｂｌｅｍ）を回避することができる。
【０１３６】
上述の接続の中断を完全に防止するために、サービス提供側ＲＮＣから、ＡＴの現在位置の付近にあるＲＮとの関連付けを有する別のＲＮＣへハンドオフを実行することができる。
【０１３７】
ＡＴは、１つのＲＮのサービス・エリアから別のＲＮのサービス・エリアへ移動する際に、ＲｏｕｔｅＵｐｄａｔｅメッセージを自分のサービス提供側ＲＮＣへ送信し、そのサービス提供側ＲＮＣは、このＲｏｕｔｅＵｐｄａｔｅメッセージを使用して、通常のソフト・ハンドオフを実行する。これらのＲｏｕｔｅＵｐｄａｔｅメッセージを通じて、サービス提供側ＲＮＣは、ＡＴがどこに位置しているかに関するかなり正確な見積もりを得て、この情報を使用して、下記のようにアクティブなＲＮＣのハンドオフを引き起こすことができる。
【０１３８】
それぞれのＲＮＣは、それぞれの本拠とされているＲＮの第１のＲＮＣを示すテーブルを伴って構成することができる。ＲＮＣは、アクティブなハンドオフを引き起こすことを決定した場合には、ＨａｎｄｏｆｆＲｅｑｕｅｓｔメッセージをサービス提供側ＲＮの第１のＲＮＣへ送信して、ハンドオフを開始することができる。アクティブなハンドオフのためのＴａｒｇｅｔ  ＲＮＣを選択する上で、その他の方法を工夫することもできる。
【０１３９】
アクティブなハンドオフにおいては、アクティブな呼び出しの状態も、Ｓｏｕｒｃｅ  ＲＮＣからＴａｒｇｅｔ  ＲＮＣへ転送する必要があるため、アクティブなハンドオフは、休眠中のハンドオフよりも実施する上でさらに複雑である。また、ＲＬＰ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｐｒｏｔｏｃｏｌ）が使用されている場合には、そのＲＬＰの処理をＳｏｕｒｃｅ  ＲＮＣからＴａｒｇｅｔ  ＲＮＣへ最小限の中断で移動させることが重要となる。アクティブなハンドオフを実施する別の方法も存在する。たとえば、古いＲＮＣを介して既存のＲＬＰリンクを中断する前に、新たなＲＮＣを介して新たなＲＬＰリンクを確立することができる。これによってＡＴは、ハンドオフが進行している間に、Ｓｏｕｒｃｅ  ＲＮＣを介して受信を継続することができる。ハンドオフが完了すると、Ｓｏｕｒｃｅ  ＲＮＣへのＲＬＰリンクを終了することができ、すべてのパケットは、Ｔａｒｇｅｔ  ＲＮＣを介して流れることができる。３ＧＰＰ２は、このようなアクティブなハンドオフを実施するための現在標準化されているプロトコルであり、別々のベンダのＲＮＣ機器どうしの間で相互運用を可能にする。
【０１４０】
このセクションで説明した方法は、ＲＮＣの機能とＲＮの機能とが、同じ基地局内で同一の場所に配置されている、すなわち統合されている分散されたＩＰベースの無線ネットワークにおいて使用することもできる。
【０１４１】
ＩＰベースのネットワーク内における複数搬送波のオペレーション
ＩＰベースの無線アクセス・ネットワークの別の利点は、大容量の複数搬送波（複数の周波数チャネル）の展開の中にある。厳密なＲＮＣの境界を有する従来のシステムにおいては、新たな搬送波を追加すると、第１の搬送波上のＲＮＣによってサービスを提供されているＲＮを分割し、それによって同じＲＮＣが、第２の搬送波上の同一の場所に配置されているＲＮの新たなセットにサービスを提供できるようにすることが必要となる可能性がある。同じＲＮＣが、同一の場所に配置されている搬送波にサービスを提供することは、必ず適切な複数搬送波の負荷バランシング・アルゴリズムを適用できるようにする上で、従来のシステムにおいては決定的に重要な要件である。ユーザの経験全体を最大化するために、複数搬送波の負荷バランシングを使用して、利用可能な搬送波の全体にわたってトラフィック・チャネルの負荷を公平に分配する。負荷バランシングを使用すると、パケット・データ・ユーザの経験が改善され、音声ユーザにとっては、閉塞率が最小限に抑えられる。結果として、新たな搬送波が追加される場合には、第２の搬送波上のＲＮのための余地を作るために、第１の搬送波上のＲＮのうちのいくつかをそれらのサービス提供側ＲＮＣから除外することが必要となる。これによって、不必要なサービスの途絶が生じる。
【０１４２】
ＩＰベースの無線アクセス・ネットワークにおいては、１つのＲＮＣは、ＲＮのより大きなセットとの関連付けを保持することができるため、第１の搬送波上の既存のＲＮのうちのいずれも、それらの（１つまたは複数の）ＲＮＣから除外する必要はない。それどころか、第２のＲＮＣを追加し、すべての既存のＲＮをそれに関連付け、その一方で、それらの第１のＲＮＣとの関連付けを依然として保持することができる。これによって、いかなるサービスの途絶も回避される。さらに多くのＲＮが第２の搬送波上に追加されるにつれて、これらは、第１および第２の双方のＲＮＣとの関連付けを確立する。
【０１４３】
ＡＴが新たなセッションを要求した場合には、サービス提供側ＲＮは、何らかのＲＮＣ間での負荷バランシング・メカニズムに基づいて、２つのＲＮＣのうちのいずれか一方へそのセッション要求を転送することができ、あるいはそのセッションをデフォルトのＲＮＣへ転送することもできる。そしてこのＲＮＣが、そのセッションにとってのサービス提供側ＲＮＣとなり、ＡＴがＲＮＣクラスタ全体の電波到達範囲内に留まっている限り、そのＡＴがどの搬送波をモニタしているかにかかわらず、そのＡＴにサービスを提供する。また、トラフィック・チャネルが確立された時点で、サービス提供側ＲＮＣは、利用可能な搬送波のうちのいずれか１つの上で機能する１組のＲＮにＡＴを割り当てることができる。ＲＮが、自分が関連付けられているすべてのＲＮＣに自分の負荷情報を提供するのであれば、搬送波の全体にわたって負荷のバランスを取るために、このようなトラフィック・チャネルの割り当てを実施することができる。すべての搬送波上のすべてのＲＮは、同じ１ｘＥＶ−ＤＯサブネット上で機能することができるため、ＡＴが、自分がモニタしている搬送波を変更するときに、ＲＮＣ間での休眠中のハンドオフは必要とされない。
【０１４４】
あるいは、第１／第２の関連付けを有するＩＰベースの無線アクセス・ネットワークにおいては、第１の搬送波上で機能しているＲＮは、第１のＲＮＣを自分の第１のＲＮＣとして使用し、その一方で第２の搬送波上で機能しているＲＮは、第２のＲＮＣを自分の第１のＲＮＣとして使用する。同時に、すべてのＲＮは、その他のＲＮＣとの第２の関連付けも有する。この場合には、新たなセッション要求が第１の搬送波上に着信すると、サービス提供側ＲＮは、そのセッション要求を自分の第１のＲＮＣへ転送し、そしてその第１のＲＮＣが、サービス提供側ＲＮＣとなる。あるいは、新たなセッション要求が第２の搬送波上に着信すると、サービス提供側ＲＮは、そのセッション要求を自分の第２のＲＮＣへ転送し、その第２のＲＮＣが、サービス提供側ＲＮＣとなる。この場合もやはり、いずれのＲＮＣも、搬送波の全体にわたってトラフィックの負荷のバランスを取るために、搬送波のうちのいずれか１つの上のトラフィック・チャネルに１つのＡＴを割り当てることができる。やはりこれによって、ＲＮが、自分の負荷情報をすべてＲＮＣに、すなわち第１および第２の双方のＲＮＣに提供することが必要となる。第１／第２の関連付けを有するＩＰベースの無線アクセス・ネットワークの唯一の欠点は、もしもＡＴが、自分がモニタしている搬送波を変更したならば、ＲＮＣ間での休眠中のハンドオフを実行しなければならないという点である。ＡＴは、たとえば自分のサービス提供側ＲＮＣによって送信先を変更された後に、自分がモニタしている搬送波を変更する可能性がある。このような送信先の変更は、たとえば、ＡＴにサービスを提供する上でより良好に整備されている搬送波へＡＴを導くために発生する可能性がある。ミックスト・リビジョン・ネットワークにおいては、１つの搬送波が、１ｘＥＶ−ＤＯ標準のいわゆるＲｅｖｉｓｉｏｎ  ０をサポートし、その一方で第２の搬送波が、いわゆるＲｅｖｉｓｉｏｎ  Ａをサポートし、このネットワークは、Ｒｅｖ  Ａユーザの送信先をＲｅｖ  ０搬送波からＲｅｖ  Ａ搬送波へ変更することができる。このような送信先の変更は、搬送波の受信可能範囲が途切れる可能性がある場合に、あるいはＲＮの障害の場合に、搬送波の境界において発生する可能性もある。ＡＴは、第１の搬送波上における所与のＲＮへのＲＦリンクを失った場合には、第２の搬送波上の同一の場所に配置されているＲＮに接続することができる。この場合もやはり、このような搬送波間でのハンドオフを実行する上で、ＲＮＣ間での休眠中のハンドオフが必要とされる。
【０１４５】
このセクションで説明した方法は、ＲＮＣの機能とＲＮの機能とが、同じ基地局内で同一の場所に配置されている、すなわち統合されている分散されたＩＰベースの無線ネットワークにおいて使用することもできる。
【０１４６】
境界のセルの呼び出し
ＩＰベースの無線ネットワークにおいては、大きなクラスタを形成することによって、ハンドオフの境界を大幅に減らすことができる。しかし大きなクラスタを形成しても、ハンドオフを完全になくすことはできない。休眠中のハンドオフにおいてしばしば見受けられるよく知られている問題は、休眠中のハンドオフの間に呼び出しデータが失われることである。休眠中のＲＮＣ間でのハンドオフにおいては、ＡＴは、一度に１つのセクタのみをモニタしていることになる。ＡＴが、サービス提供側ＲＮＣによって連絡を取ることができないセクタのモニタリングを開始した瞬間に、そのサービス提供側ＲＮＣは、もはやそのＡＴを呼び出すことはできない。ＡＴは、そのセッションが新たなＲＮＣへ転送された後に再び呼び出しが可能となり、そしてＰＤＳＮは、ＡＴパケットを新たなＲＮＣへ転送する。呼び出しデータが失われるのを防止するために、サービス提供側ＲＮＣは、Ａ１３の休眠中のハンドオフ中に自分が新たなＲＮＣへ送信するセッション情報内に、いかなる未着信の呼び出しデータも含めることができる。サービス提供側ＲＮＣは、Ａ１３の休眠中のハンドオフが完了すると、次いでＡＴを呼び出すことができる。これによって、ＡＴは、休眠中のＲＮＣ間における呼び出し手続きの間に必ず呼び出し可能なままとなる。
【０１４７】
本発明の複数の実施形態について説明した。しかしながら、本発明の趣旨および範囲から逸脱することなくさまざまな修正を行うことができ、したがってその他の実施形態も、添付の特許請求の範囲内であるということが理解できるであろう。
【図面の簡単な説明】
【０１４８】
【図１】ネットワークを示す図である。
【図２】ネットワークを示す図である。
【図３】ネットワークを示す図である。
【図４】ネットワークを示す図である。
【図１】
2007538476.tif 000003
【図２】
2007538476.tif 000004
【図３】
2007538476.tif 000005
【図４】
2007538476.tif 000006
【国際調査報告】
2007538476.tif 000007
2007538476.tif 000008
2007538476.tif 000009