JP2011004140A - 基地局制御装置および無線パケット処理装置 - Google Patents

Abstract

【課題】異なるＳｕｂｎｅｔ配下でもＵＡＴＩの再割り当てや無線セッションの引き継ぎなしに呼接続やメッセージの処理を行なう。
【解決手段】異なるＳｕｂｎｅｔに属し隣接しあうＲＡＮ同士でお互いのＣｏｌｏｒＣｏｄｅや基地局制御装置のＩＰアドレス、無線基地局の無線リソース情報などをメッセージ等で交換し合う。ＡＴから自分のＣｏｌｏｒＣｏｄｅと異なるメッセージを受信したＲＡＮは、ＣｏｌｏｒＣｏｄｅが一致するＲＡＮの基地局制御装置へメッセージを転送する。
【選択図】図４

Description

本発明は、基地局制御装置および無線パケット処理装置に係り、異なるＳｕｂｎｅｔからのメッセージを受信した際に呼接続、メッセージの処理を行なう基地局制御装置および無線パケット処理装置に関する。

データ通信専用に特化した移動体無線通信方式であるｃｄｍａ２０００ １ｘＥＶ−ＤＯ（1xEvolution-Data Only）は、国際標準化機関である３ＧＰＰ２（3rd Generation Partnership Project 2）において、非特許文献１として規格化されている。１ｘＥＶ−ＤＯは、データ通信に特化することにより周波数利用効率を向上させている。

移動端末であるＡＴ（Access Terminal）がＲＡＮ（Radio Access Network）と通信を行なう際、ＲＡＮは、ＡＴをユニークに識別するための識別子としてＵＡＴＩ（Unicast Access Terminal Identifier）３２とＵＡＴＩ１２８を、ＡＴに割り当てる。図１と図２を参照して、非特許文献１で規定されるＵＡＴＩ３２とＵＡＴＩ１２８の構成を説明する。

図１において、ＵＡＴＩ３２ ２００は、３２ｂｉｔで構成される。ＵＡＴＩ３２ ２００の上位８ｂｉｔは、ＲＡＮを識別するＣｏｌｏｒＣｏｄｅ２０１である。ＵＡＴＩ３２ ２００の下位２４ｂｉｔは、ＵＡＴＩ２４ ２０２としてＲＡＮが自由に割り当てることができる。

図２において、ＵＡＴＩ１２８ ２１０は、１２８ｂｉｔで構成される。ＵＡＴＩ１２８ ２１０の上位１０４ｂｉｔは、ＲＡＮを識別するＳｕｂｎｅｔ情報２１１である。ＵＡＴＩ１２８ ２１０の下位２４ｂｉｔは、ＵＡＴＩ２４ ２１２としてＲＡＮが自由に割り当てることができる。ここでＵＡＴＩ３２ ２００とＵＡＴＩ１２８ ２１０を纏めてＵＡＴＩと呼ぶことにする。

ＡＴにＵＡＴＩが割り当てられると、ＡＴとＲＡＮは、相互間で無線セッションのコンフィグレーションを行なう。無線セッションとは、ＡＴとＲＡＮがお互いにサポート可能な機能を確認し、それを元に決定されたプロトコルおよびパラメータの集合である。

ＡＴとＲＡＮがデータ通信を行う際、ＡＴとＲＡＮとの間で無線コネクションの確立、ＡＴとＰＤＳＮ（Packet Data Service Node）との間でＰＰＰ（Point-to-Point Protocol）の確立を行ない、データ通信を行なう。この場合のＡＴの状態をＡｃｔｉｖｅ状態と呼ぶ。

一定の無通信状態が発生すると、ＡＴとＲＡＮは、無線コネクションを開放する。この時、無線セッションは、ＲＡＮ内に保持される。また、ＡＴとＰＤＳＮとの間のＰＰＰも維持される。この場合のＡＴの状態をドーマント状態と呼ぶ。

ＡＴは、ＲＡＮ内の無線基地局から定期的に図３Ａに示すＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージなどの報知情報を受信する。図３Ａにおいて、ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００は、ＭｅｓｓａｇｅＩＤ、ＣｏｕｎｔｒｙＣｏｄｅ、ＳｅｃｔｏｒＩＤ４０１、ＳｕｂｎｅｔＭａｓｋ、ＳｅｃｔｏｒＳｉｇｎａｔｕｒｅ、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅＩｎｃｌｕｄｅｄ、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅＣｏｕｎｔ、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２、Ｒｅｓｅｒｖｅｄ等のＦｉｅｌｄと、それぞれのＦｉｅｌｄのＬｅｎｇｔｈ（ｂｉｔ）で構成される。
図３Ｂにおいて、１２８ｂｉｔのＳｅｃｔｏｒＩＤ４０１は、１０４ｂｉｔのＳｕｂｎｅｔ情報４０１１と、２４ｂｉｔのセクタ識別子４０１２とから構成される。

ＡＴは、ＲＡＮ間を移動する際、移動先のＲＡＮのＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００に含まれるＳｅｃｔｏｒＩＤ４０１のＳｕｂｎｅｔ情報４０１１とＡＴのＵＡＴＩ１２８ ２１０に含まれるＳｕｂｎｅｔ情報２１１が異なる事を検知する。移動を検知したＡＴは、新しいＵＡＴＩの割り当てを求めるためにＵＡＴＩＲｅｑｕｅｓｔメッセージを移動先のＲＡＮへ送信する。ＵＡＴＩＲｅｑｕｅｓｔメッセージを受信したＲＡＮは、移動元のＲＡＮからＡＴの無線セッションを取り寄せ、ＡＴに新しいＵＡＴＩを割り当てる。このハンドオフ形態をＲＡＮ間ドーマントハンドオフと呼ぶ。

これに対して、Ａｃｔｉｖｅ状態のＡＴがＲＡＮ間を移動してハンドオフを行う形態をＲＡＮ間Ａｃｔｉｖｅハンドオフと呼ぶ。ＲＡＮ間Ａｃｔｉｖｅハンドオフは、無線コネクションを確立した状態で、ＲＡＮ間での無線セッションの引き継ぎとＡＴへのＵＡＴＩ再割り当てを行なう。

ＡＴが複数のＲＡＮの境界に位置していると、そのＡＴは、それぞれのＲＡＮのＳｕｂｎｅｔ情報４０１１を含むＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００を代わる代わる受信する。それをトリガーとして、ＡＴとＲＡＮ間でのＵＡＴＩの割り当てと、境界に位置するＲＡＮ間での無線セッションの転送が頻繁に行われる。これはＲＡＮ内のネットワーク装置のＣＰＵ使用率やネットワークリソース、無線リソースの浪費を引き起こす。これは一般にピンポン効果と呼ばれている。

この問題を回避するため、非特許文献１ではＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅの使用が提言されている。これはお互いのＲＡＮの境界に位置する無線基地局が送信するＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００の中に相手のＲＡＮのＣｏｌｏｒＣｏｄｅをＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２として登録する。ＡＴは、自分のＵＡＴＩ３２ ２００に含まれるＣｏｌｏｒＣｏｄｅ２０１とＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００に含まれるＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２が一致している限り、ＵＡＴＩＲｅｑｕｅｓｔメッセージを送信しない。これにより、１ｘＥＶ−ＤＯは、ＲＡＮ境界でのピンポン効果を抑止する。

"cdma2000 High Rate Packet Data Air Interface Specification"、3GPP2 C.S0024-A Version 3.0 September 2006

ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅを使用しない場合、ＡＴは、ＲＡＮ間を移動するたびにＲＡＮ間ドーマントハンドオフを行なう。その時、ＲＡＮは、ＵＡＴＩの再割り当てと無線セッションのＲＡＮ間での引き継ぎを実施する。このため、ＡＴが別のＲＡＮへ移動して呼接続を行ってもＵＡＴＩの再割り当てや無線セッションの引き継ぎなしに呼接続処理を行なうことができる。

ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅは、ＲＡＮ境界上でのＲＡＮ間ドーマントハンドオフを抑止する機能である。このため、ＡＴが別のＲＡＮへ移動して呼接続を行なう前にＵＡＴＩの再割り当てや無線セッションの引き継ぎは行われない。このためＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅを使用する場合、無線セッションが存在しないＲＡＮ上でも呼接続を行なう必要性がある。しかし、その方法については非特許文献１で規定されていない。

発明者の検討に依れば、ＡＴが呼接続を要求した際にまずＲＡＮ間ドーマントハンドオフを行ない、その後呼接続を行う方法が考えられる。これは、従来のシーケンスと非常に近い方法である。しかし、ＲＡＮ間ドーマントハンドオフは、無線環境でのメッセージ欠落によるＵＡＴＩの再割り当て失敗、無線セッションの引き継ぎに時間がかかるなどの問題がある。特に、ＵＡＴＩの再割り当ては、無線コネクションを確立せずに行なうため、メッセージが無線環境で欠落するリスクが高い。

ＲＡＮは、ＵＡＴＩの再割り当てに失敗すると無線セッションの解放を行なう。このため、再度ＡＴとＲＡＮとの間で無線セッションのコンフィグレーションを行なう必要がある。この結果、呼接続が完了するまでに非常に時間がかかる。これらの問題は、リアルタイム性を要求されるＶｏＩＰ（Voice over Internet Protocol）、ＰＴＴ（Push To Talk）などのアプリケーションにおいて、特に問題である。

以上のことを考えると無線セッションが存在しないＲＡＮ上でもＲＡＮ間ドーマントハンドオフを行なわずに呼接続を行なうことが望ましい。
また、市場にはＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ機能をサポートしていないＡＴも存在する。このようなＡＴは、ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００にＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２が含まれていても、ＲＡＮの境界を移動する度にＵＡＴＩＲｅｑｕｅｓｔメッセージを送信する。このため、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅを行なっているＲＡＮであっても、ＡＴによっては従来通りのＲＡＮ間ドーマントハンドオフを行なう必要がある。

また、非特許文献１で規定されるＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージは、無線コネクションを確立せずに小さいサイズのデータをＡＣ（Access Channel）上またはＣＣ（Control Channel）上で送受信することができる。ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅがサポートされているＲＡＮ境界で、ＡＴがＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージを送信した場合にも、呼接続時と同様な問題が起きる。具体的には、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージを受信したＲＡＮに、ＡＴの無線セッションが存在しない場合がある。すなわち、無線セッションがないＲＡＮも、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージなどのメッセージを処理する必要性が出てきた。

上記課題を解決するため、異なるＳｕｂｎｅｔに属し、隣接しあうＲＡＮ同士でお互いのＣｏｌｏｒＣｏｄｅ、基地局制御装置のＩＰアドレス、無線基地局の無線リソース情報などをメッセージ等で交換し合う。

隣接するＲＡＮのＣｏｌｏｒＣｏｄｅを受信したＲＡＮは、自身の報知するＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００のＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２に隣接するＲＡＮのＣｏｌｏｒＣｏｄｅを含めて報知する。

ＡＴから自分のＣｏｌｏｒＣｏｄｅと異なるＵＡＴＩを持つＡＣでのメッセージを受信したＲＡＮは、ＣｏｌｏｒＣｏｄｅが一致するＲＡＮの基地局制御装置へメッセージを転送する。このとき転送先のＲＡＮに候補となる基地局制御装置が複数存在する場合、同一のＡＴから複数のメッセージを受信しても常に同じ基地局制御装置が選択されるように基地局制御装置を選択する。ただし、ＡＴからＵＡＴＩＲｅｑｕｅｓｔメッセージが送信されてきた場合、ＲＡＮは、隣接するＲＡＮへ転送せず、ＲＡＮ間ドーマントハンドオフを行なう。これによりＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ機能をサポートしていないＡＴがＲＡＮ境界を移動してきても対応可能とする。

ＣｏｌｏｒＣｏｄｅが一致するＲＡＮには、ＡＴの無線セッションが存在する。この結果、ＲＡＮ間ドーマントハンドオフを行なわずともメッセージの処理や呼接続を行うことができる。

ＲＡＮは、ＡＴとの距離、電波強度など条件が最もよい無線基地局を選択して、ＡＴとの間で無線コネクションを確立する。ＲＡＮ間では隣接するＲＡＮの無線基地局に関する情報を交換しているため、別のＲＡＮへメッセージを転送して呼接続を行う場合でも、転送元のＲＡＮに含まれる無線基地局を選択して呼接続を行なうことができる。これによりＡＴとの条件が最も優れた無線基地局を選択して、呼接続処理を行うことができる。

別のＲＡＮへメッセージを転送して呼接続を行う場合、ＲＡＮ同士は、メッセージのルートを記録しあう。これにより、以降にやり取りされるメッセージも、同じ経路で送受信できるようになる。メッセージのルートに関する情報は、無線コネクションが維持される間保持される。

呼接続が完了した後、ＲＡＮ間Ａｃｔｉｖｅハンドオフを行ない、ＲＡＮ間での無線セッションの引き継ぎとＡＴへのＵＡＴＩ再割り当てを行なってもよい。この場合、無線コネクションを確立した後にＵＡＴＩの再割り当てを行なうので、ＵＡＴＩ再割り当て失敗のリスクを非常に小さくすることができる。

別のＳｕｂｎｅｔ配下でＡＴが送信してきたメッセージを処理する他の手段として、隣接するＲＡＮ同士で無線セッションを保持してもよい。この場合、移動前のＲＡＮは、ＵＡＴＩの管理やＰＤＳＮとの接続を担い、移動先のＲＡＮは、ＡＴとのメッセージのやり取りや無線コネクションの管理を行う。

別のＳｕｂｎｅｔ配下でＡＴが送信してきたメッセージを処理する更に他の手段として、ＲＡＮ間で無線セッションの引き継ぎを行った後にメッセージの処理を行なってもよい。呼接続を行う際、ＲＡＮは、まず無線セッションの引き継ぎを行なう。ＲＡＮは、次に無線コネクションの確立を行なう。最後に、ＲＡＮは、ＵＡＴＩの再割り当てを行なう。この場合、無線コネクションの確立後にＵＡＴＩの再割り当てを行なうので、ＵＡＴＩ再割り当て失敗のリスクを低減し呼接続時間の短縮を図ることができる。

上述した課題は、移動端末と接続する複数の無線基地局を配下として制御する基地局制御装置において、第１の無線基地局から制御チャネル上でのメッセージを受信したとき、このメッセージに含まれる識別情報が自身の識別情報と一致するか判定し、不一致のときメッセージが移動端末識別子要求メッセージか判定し、メッセージが移動端末識別子要求メッセージのとき、ドーマントハンドオフ処理を実施し、メッセージが移動端末識別子要求メッセージでないとき、識別情報に該当する他の基地局制御装置にメッセージを転送する基地局制御装置によって、達成できる。

無線セッションが存在しないＲＡＮ上でも呼接続、メッセージの処理を行なうことができる。

ＵＡＴＩ ３２のフォーマットである。 ＵＡＴＩ １２８のフォーマットである。 ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージのフォーマットである。 ＳｅｃｔｏｒＩＤのフォーマットである。 無線通信システムのブロック図である。 ＢＳＣのシステムパラメータテーブルを説明する図である。 ＢＴＳのシステムパラメータテーブルを説明する図である。 隣接ＢＳＣ情報を説明する図である。 ＲｏｕｔｅＵｐｄａｔｅメッセージのフォーマットである。 ＢＴＳのトラフィックチャネルテーブルを説明する図である。 ＢＳＣのＡＴ管理テーブルを説明する図である。 異なるＳｕｂｎｅｔ配下で呼接続を行った場合のシーケンス図である。 ＡＣ上でメッセージを受信したときのＢＳＣのフローチャートである。 異なるＳｕｂｎｅｔ配下でＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージを送信した場合のシーケンス図である。

以下、本発明の実施の形態について、実施例を用い図面を参照しながら詳細に説明する。なお、実質同一部位には、同じ参照番号を振り、説明は繰り返さない。

図４を参照して、無線通信システムを説明する。図４において、無線通信システム１０００は、ＰＤＳＮ１００、ＩＰネットワーク網３００、ＲＡＮ５００、ＡＴ６００から構成される。また、ＲＡＮ５００は、ＰＣＦ−ＳＣ（無線パケット処理装置：Packet Control Function/Session Control）５１０、Ｌ（layer）３−ＳＷ（switch）５２０、ＢＳＣ（基地局制御装置：Base Station Controller）５３０、ＢＴＳ（無線基地局：Base station Transceiver Subsystem）５４０から、構成される。

ＰＤＳＮ１００は、図示しないＩｎｔｅｒｎｅｔ側からのパケットを終端する。ＰＣＦ−ＳＣ５１０は、無線セッションの管理と、ＢＳＣ５３０およびＰＤＳＮ１００から受信するパケットの中継を行なう。Ｌ３−ＳＷ５２０は、ＰＣＦ−ＳＣ５１０とＢＳＣ５３０また複数のＲＡＮ５００をネットワーク網３００経由で接続する。ＢＳＣ５３０は、ＡＴ６００との間で送受信するメッセージの制御、ＢＴＳ５４０の制御、ＢＴＳ５４０からトラフィックを受信し、ＰＣＦ−ＳＣ５１０への転送を行なう。ＢＴＳ５４０は、ＡＴ６００との間で無線リソースの管理や無線パケットの送受信を行なう。ＢＳＣ５３０とＢＴＳ５４０は、広域イーサ網または専用線などで接続される。ＡＴ６００は、移動端末である。

ＲＡＮ５００−１のＰＣＦ−ＳＣ５１０−１とＢＳＣ５３０−１、ＢＳＣ５３０−２は、ＣｏｌｏｒＣｏｄｅとして、「１」を保持する。ＲＡＮ５００−２のＰＣＦ−ＳＣ５１０−２
、ＢＳＣ５３０−３とＢＳＣ５３０−４は、ＣｏｌｏｒＣｏｄｅとして、「２」を保持する。ＲＡＮ５００−１のＲＡＮ５００−２に隣接するＢＳＣ５３０−２は、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅとして、「２」を保持する。ＲＡＮ５００−２のＲＡＮ５００−１に隣接するＢＳＣ５３０−３は、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅとして、「１」を保持する。

ＢＳＣ５３０は、それぞれ図５に示すシステムパラメータテーブル４１０を保持する。図５において、システムパラメータテーブル４１０は、ＣｏｌｏｒＣｏｄｅ４１１、Ｓｕｂｎｅｔ４１２、ＢＴＳＩＰＡｄｄｒｅｓｓ４１３、ＰｉｌｏｔＰＮ４１４、ＮｅｉｇｈｂｒＢＳＣＡｄｄｒｅｓｓ４１５を含む。システムパラメータテーブル４１０のＢＴＳＩＰＡｄｄｒｅｓｓ４１３とＰｉｌｏｔＰＮ４１４には、ＢＳＣ５３０が制御するＢＴＳ５４０のＩＰアドレスとＰｉｌｏｔＰＮ（Pilot Pseudo Noise）を登録する。ＢＴＳＩＰＡｄｄｒｅｓｓ４１３とＰｉｌｏｔＰＮ４１４は、一つのＢＳＣ５３０で収容可能なＢＴＳ５４０数分登録可能な配列である。

同様にＢＴＳ５４０は、それぞれ図６に示すシステムパラメータテーブル４２０を保持する。システムパラメータテーブル４２０は、ＢＳＣＩＰＡｄｄｒｅｓｓ４２１を含む。ＢＳＣＩＰＡｄｄｒｅｓｓ４２１は、ＢＴＳ５４０を制御するＢＳＣ５３０のＩＰアドレスを登録する。図４の構成では、ＢＳＣ５３０−１とＢＴＳ５４０−０とＢＴＳ５４０−１にお互いの情報が登録される。ＢＳＣ５３０−２とＢＴＳ５４０−２とＢＴＳ５４０−３にお互いの情報が登録される。ＢＳＣ５３０−３とＢＴＳ５４０−４とＢＴＳ５４０−５にお互いの情報が登録される。ＢＳＣ５３０−４とＢＴＳ５４０−６とＢＴＳ５４０−７にお互いの情報が登録される。

ＢＳＣ５３０のシステムパラメータテーブル４１０は、ＣｏｌｏｒＣｏｄｅ４１１とＳｕｎｂｅｔ４１２を含み、それぞれのＲＡＮのＣｏｌｏｒＣｏｄｅとＳｕｎｂｅｔを登録する。ＲＡＮ５００−１に含まれるＢＳＣ５３０−１とＢＳＣ５３０−２は、ＣｏｌｏｒＣｏｄｅ４１１に１をＳｕｂｎｅｔ４１２にＲＡＮ５００−１を示す情報を割り当てる。ＲＡＮ５００−２に含まれるＢＳＣ５３０−３とＢＳＣ５３０−４は、ＣｏｌｏｒＣｏｄｅ４１１に２をＳｕｂｎｅｔ４１２にＲＡＮ５００−２を示す情報を割り当てる。

ＢＳＣ５３０のシステムパラメータテーブル４１０は、ＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４１５を含み、ＲＡＮ間で隣接するＢＳＣ５３０のＩＰアドレスを登録する。ＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４１５は一つのＢＳＣ５３０で隣接し得るＢＳＣ数分登録可能な配列である。

図４の構成では、ＢＳＣ５３０−２のＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４１５にＢＳＣ５３０−３のＩＰアドレスを登録する。ＢＳＣ５３０−３のＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４１５にＢＳＣ５３０−２のＩＰアドレスを登録する。ＢＳＣ５３０は、ＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４１５で登録された隣接ＢＳＣに自ＢＳＣに関する情報を図７に示す隣接ＢＳＣ情報としてメッセージで送信する。

図７において、隣接ＢＳＣ情報４３０は、ＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４３１、ＣｏｌｏｒＣｏｄｅ４３２、ＢＴＳＩＰＡｄｄｒｅｓｓ４３３、ＰｉｌｏｔＰＮ４３４などを含む。ＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４３１とＣｏｌｏｒＣｏｄｅ４３２は、自ＢＳＣのＩＰアドレスとＣｏｌｏｒＣｏｄｅ４１１を記録する。ＢＴＳＩＰＡｄｄｒｅｓｓ４３３とＰｉｌｏｔＰＮ４３４は、自ＢＳＣで管理するＢＴＳのＢＴＳＩＰＡｄｄｒｅｓｓ４１３とＰｉｌｏｔＰＮ４１４を含める。

隣接ＢＳＣ情報４３０をメッセージで受け取ったＢＳＣ５３０は、隣接ＢＳＣ情報４３０を保存する。隣接ＢＳＣ情報４３０について、ＢＳＣ５３０は、複数のＢＳＣ５３０から受信するので隣接するＢＳＣ毎に管理する。なお、管理するテーブルは、システムパラメータテーブル４１０のＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４１５以降に、ＣｏｌｏｒＣｏｄｅ４３２〜ＰｉｌｏｔＰＮ４３４を追加する。

図４の構成では、ＢＳＣ５３０−２に隣接ＢＳＣ情報４３０としてＢＳＣ５３０−３のＩＰアドレスとＣｏｌｏｒＣｏｄｅ、ＢＴＳ５４０−４とＢＴＳ５４０−５のＩＰアドレスとＰｉｌｏｔＰＮが保存される。ＢＳＣ５３０−３に隣接ＢＳＣ情報４３０としてＢＳＣ５３０−２のＩＰアドレスとＣｏｌｏｒＣｏｄｅ、ＢＴＳ５４０−２とＢＴＳ５４０−３のＩＰアドレスとＰｉｌｏｔＰＮが保存される。

ＢＳＣ５３０は、自身の配下のＢＴＳ５４０にＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００の内容を指示する。ＢＳＣ５３０は、配下のＢＴＳ５４０に自身のＳｕｂｎｅｔ４１２を通知する。ＢＴＳ５４０は、通知されたＳｕｂｎｅｔ４１２をＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００のＳｅｃｔｏｒＩＤ４０１のＳｕｂｎｅｔ情報４０１１に含める。またＢＳＣ５３０は、隣接ＢＳＣ情報４３０に自分のＣｏｌｏｒＣｏｄｅ４１１と異なるＣｏｌｏｒＣｏｄｅ４３２が含まれる場合、ＢＴＳ５４０に隣接ＢＳＣ情報４３０のＣｏｌｏｒＣｏｄｅ４３２をＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅとして通知する。ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅを受け取ったＢＴＳ５４０は、ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００のＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２にＢＳＣ５３０から受け取った情報を含める。ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００の内容を受け取ったＢＴＳ５４０は、ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００を定期的に報知する。

図４の構成ではＲＡＮ５００−１に含まれるＢＴＳ５４０−０〜ＢＴＳ５４０−３が報知するＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００のＳｅｃｔｏｒＩＤ４０１のＳｕｂｎｅｔ情報４０１１は、ＲＡＮ５００−１を示す情報が含まれる。ＲＡＮ５００−２に含まれるＢＴＳ５４０−４〜ＢＴＳ５４０−７のＳｕｂｎｅｔ情報４０１１は、ＲＡＮ５００−２を示す情報が含まれる。またＲＡＮ５００−２と隣接するＢＴＳ５４０−２とＢＴＳ５４０−３が報知するＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００のＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２は、ＲＡＮ５００−２のＣｏｌｏｒＣｏｄｅである２が含まれる。ＲＡＮ５００−１と隣接するＢＴＳ５４０−４とＢＴＳ５４０−５のＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２は、ＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅである１が含まれる。

ＡＴ６００とＲＡＮ５００−１は、初期接続時にＵＡＴＩの割り当てと無線セッションのコンフィグレーションを行なう。無線セッションは、ＰＣＦ−ＳＣ５１０−１内に保持される。また、ＡＴ６００のＵＡＴＩ３２ ２００のＣｏｌｏｒＣｏｄｅ２０１は、ＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅである１がセットされる。また、ＵＡＴＩ１２８ ２１０のＳｕｂｎｅｔ情報２１１には、ＲＡＮ５００−１を示す情報がセットされる。

ＡＴ６００とＲＡＮ５００−１がデータ通信を行う際、ＡＴ６００とＲＡＮ５００−１との間で無線コネクションを確立する。一方、ＡＴ６００とＰＤＳＮ１００との間でＰＰＰの確立を行ない、データ通信を行う。この時ＡＴ６００は、Ａｃｔｉｖｅ状態となる。

一定の無通信状態が発生すると、ＡＴ６００とＲＡＮ５００−１とは、無線コネクションを開放する。この時、無線セッションは、ＰＣＦ−ＳＣ５１０−１内に保持される。また、ＡＴ６００とＰＤＳＮ１００との間のＰＰＰも維持される。この時、ＡＴ６００は、ドーマント状態となる。

ＡＴ６００は、ＲＡＮ５００−１とＲＡＮ５００−２の境界に位置する場合、ＢＴＳ５４０−２やＢＴＳ５４０−３、ＢＴＳ５４０−４、ＢＴＳ５４０−５のＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００を代わる代わる受信する。このときＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００のＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２には、ＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅ＝１またはＲＡＮ５００−２のＣｏｌｏｒＣｏｄｅ＝２を含んでいる。このため、ＡＴ６００は、ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００に含まれるＳｅｃｔｏｒＩＤ４０１のＳｕｂｎｅｔ情報４０１１とＡＴのＵＡＴＩ１２８ ２１０に含まれるＳｕｂｎｅｔ情報２１１が異なる事を検知してもＵＡＴＩの再割り当て要求としてのＵＡＴＩＲｅｑｕｅｓｔメッセージを送信しない。

図８を参照して、ドーマント状態にあるＡＴがＢＴＳに送信するＲｏｕｔｅＵｐｄａｔｅメッセージを説明する。図８において、ＲｏｕｔｅＵｐｄａｔｅメッセージ４６０は、ＭｅｓｓａｇｅＩＤ、ＭｅｓｓａｇｅＳｅｑｕｅｎｃｅ、ＲｅｆｅｒｅｎｃｅＰｉｌｏｔＰＮ、ＲｅｆｅｒｎｃｅＰｉｌｏｔＳｔｒｅｎｇｔｈ、ＲｅｆｆｅｒｅｎｃｅＫｅｅｐ、ＮｕｍＰｉｌｏｔ、ＰｉｌｏｔＰＮＰｈａｓｅ、ＣｈａｎｎｅｌＩｎｃｌｕｄｅｄ、Ｃｈａｎｎｅｌ、ＰｉｌｏｔＳｔｒｅｎｇｔｈ、Ｋｅｅｐ、Ｒｅｓｅｒｖｅｄの各Ｆｉｅｌｄと、そのＬｅｎｇｔｈ（ｂｉｔ）を含む。ＲｏｕｔｅＵｐｄａｔｅメッセージ４６０は、複数の受信パイロット情報をＢＴＳに通知するメッセージである。

図９を参照して、トラフィックチャネルテーブルを説明する。図９において、トラフィックチャネルテーブル４５０は、トラフィックチャネル識別子４５１とＵＡＴＩ ３２ ４５２を保持する。トラフィックチャネルテーブル４５０は、ＢＴＳが保持するテーブルである。ＢＴＳは、トラフィックチャネルを確立したＡＴのＵＡＴＩ ３２をトラフィックチャネル識別子と対応付けて保持する。

図１０を参照して、ＡＴ管理テーブルを説明する。図１０において、ＡＴ管理テーブル４４０は、ＵＡＴＩ ３２ ４４１、ＢＳＣＩＩＰＡｄｄｒｅｓｓ４４２、ＢＴＳＩＰＡｄｄｒｅｓｓ４４３を保持する。ＡＴ管理テーブル４４０は、ＢＳＣが保持するテーブルである。ＡＴ管理テーブル４４０は、ＡＴと、ＢＳＣと、ＢＴＳとを対応付ける。

ＡＴ６００がＲＡＮ５００−１配下でドーマント状態になり、地理的にＲＡＮ５００−２に移動しＢＴＳ５４０−４の配下で呼接続要求を行った際のシーケンスについて、図１１を参照して説明する。

ドーマント状態（ｓｔａｔｅ−ａ）であるＡＴ６００は、呼接続要求を行うためにＢＴＳ５４０−４に対して、ＲｏｕｔｅＵｐｄａｔｅメッセージとＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを送信する（ｓｔｅｐ−ｂ）。ＲｏｕｔｅＵｐｄａｔｅメッセージとＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージは、ＡＣ上で送信される。ＡＣのＭＡＣ Ｌａｙｅｒ ＨｅａｄｅｒのＡＴＩ ＲｅｃｏｒｄにはＵＡＴＩ３２ ２００が含まれる。ＵＡＴＩ３２ ２００内のＣｏｌｏｒＣｏｄｅ２０１にはＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅである１がセットされている。ＢＴＳ５４０−４は、システムパラメータテーブル４２０のＢＳＣＩＰＡｄｄｒｅｓｓ４２１を参照し、ＡＴ６００から受信したメッセージをＢＳＣ５３０−３へ転送する（ｓｔｅｐ−ｃ）。

ＢＳＣ５３０−３は、転送先ＢＳＣを選択する（ｓｔｅｐ−ｄ）。この場合、ＢＳＣ５３０−３は、ＳＣ５３０−２を選択して、ＲｏｕｔｅＵｐｄａｔｅメッセージとＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージをＢＳＣ５３０−２に転送する（ｓｔｅｐ−ｅ）。ＢＳＣ５３０−２は、ＰＣＦ−ＳＣ５１０との間で無線セッションを取得する（ｓｔｅｐ−ｆ）。ＢＳＣ５３０−２は、ＢＴＳを選択する（ｓｔｅｐ−ｇ）。ＢＳＣ５３０−２は、ＢＳＣ５３０−３にトラフィックチャンネル確立要求を送信する（ｓｔｅｐ−ｈ）。

ＢＳＣ５３０−３は、ＢＳＣ５３０−２が選択したＢＴＳであるＢＴＳ５４０−４にトラフィックチャンネル確立要求を送信する（ｓｔｅｐ−ｉ）。ＢＳＣ５３０−２とＰＣＦ−ＳＣ５１０とは、Ａ８コネクションを確立し、ＰＣＦ−ＳＣ５１０とＰＤＳＮ１００とは、Ａ１０コネクションを確立する（ｓｔｅｐ−ｊ）。ＢＳＣ５３０−２は、ＡＴ６００と無線セッションを確立する（ｓｔｅｐ−ｋ）。ＡＴ６００と、ＰＤＳＮ１００とは、Ａｃｔｉｖｅ状態（ｓｔａｔｅ−ｌ）に遷移する。

ＢＳＣ５３０−３がＡＣ上でメッセージを受信した時の動作について、図１２を参照して、説明する。図１２において、ＢＳＣ５３０は、ＡＣのメッセージに含まれるＵＡＴＩ３２ ２００のＣｏｌｏｒＣｏｄｅ２０１とシステムパラメータテーブル４１０に登録されている自分のＣｏｌｏｒＣｏｄｅ４１１が一致するか比較する（Ｓ９０１）。一致する場合、ＢＳＣ５３０は、別のＲＡＮへ転送する必要がないので受信したＲｏｕｔｅＵｐｄａｔｅメッセージとＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを処理し、ＡＴと呼接続処理を行ない（Ｓ９０６）、終了する。ステップ９０１で不一致の場合、ＢＳＣ５３０は、ＡＣのメッセージの中にＵＡＴＩＲｅｑｕｅｓｔメッセージが含まれるかどうかチェックする（Ｓ９０２）。ＵＡＴＩＲｅｑｕｅｓｔメッセージが含まれる場合、ＢＳＣ５３０は、ＰＣＦ−ＳＣ５１０から無線セッションを取り寄せると共に、ＡＴに新しいＵＡＴＩを割り当て、ＲＡＮ間ドーマントハンドオフを行ない（Ｓ９０７）、終了する。ステップ９０７により、ＢＳＣ５３０は、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ機能をサポートしていないＡＴがＲＡＮ境界を移動してきても対応可能である。ステップ９０２において、ＵＡＴＩＲｅｑｕｅｓｔメッセージが含まれない場合、ＢＳＣ５３０は、ＡＣのメッセージに含まれるＣｏｌｏｒＣｏｄｅ２０１と隣接ＢＳＣ情報４３０のＣｏｌｏｒＣｏｄｅ４３２が一致するＢＳＣがあるか判定する（Ｓ９０３）。

選択出来ない場合、ＢＳＣ５３０は、メッセージを破棄して（Ｓ９０８）、終了する。ステップ９０３でＢＳＣを選択出来た場合、ＢＳＣ５３０は、転送先の候補となるＢＳＣが複数存在する場合は一つのＢＳＣに絞る（Ｓ９０４）。ＢＳＣ５３０は、選択したＢＳＣのＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４３１に向けてＡＣのメッセージを転送して（Ｓ９０５）、終了する。

この時ＡＴとＢＳＣの間では複数のメッセージをＡＣ上でやり取りする場合があるため、特定のＡＴに対して選択されるＢＳＣは常に同一のＢＳＣであることが望ましい。この解決のため、ＡＣのＭＡＣ Ｌａｙｅｒ ＨｅａｄｅｒのＵＡＴＩ３２ ２００に含まれるＵＡＴＩ２４ ２０２と転送先の候補となるＢＳＣ数を使って、式１のＨａｓｈｉｎｇを行ない、転送先のＢＳＣを決定する。

Ｈａｓｈ値 ＝ ＵＡＴＩ２４ Ｍｏｄ 転送先の候補となるＢＳＣ数 …（式１）

具体的には、転送先の候補となるＢＳＣがＢＳＣ１００、ＢＳＣ２００、ＢＳＣ３００の３台あり、それぞれのＢＳＣにＩｎｄｅｘを０〜２と割り振ったとする。この時ＡＴから受信したＵＡＴＩ２４ ２０２が０ｘ０１３４５６であれば、「０ｘ０１３４５６ Ｍｏｄ ３ ＝ １」となりＩｎｄｅｘ１であるＢＳＣ２００を選択する。同様に０ｘ０１２３４５であれば「０ｘ０１２３４５ Ｍｏｄ ３ ＝ ０」となりＩｎｄｅｘ０であるＢＳＣ１００を選択する。ＡＣ上でのメッセージを受信するたびに式１の方法で転送先のＢＳＣを決定することで、特定のＡＴに対して常に同じＢＳＣを選択することができる。ＢＳＣを決定したとき、ＢＳＣ５３０は、ＮｅｉｇｈｂｏｒＢＳＣＡｄｄｒｅｓｓ４３１に向けてＡＣのメッセージを転送する（ｓｔｅｐ−ｅ）。

ＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを受信したＢＳＣ５３０−２は、ＰＣＦ−ＳＣ５１０−１から無線セッションを取得する（ｓｔｅｐ−ｆ）。次にＢＳＣ５３０−２は、ＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージと同時に通知されたＲｏｕｔｅＵｐｄａｔｅメッセージの中から使用するＰｉｌｏｔＰＮを抽出し、無線コネクションを確立するＢＴＳを決定する（ｓｔｅｐ−ｇ）。具体的には、ＲｏｕｔｅＵｐｄａｔｅメッセージ内のＲｅｆｅｒｅｎｃｅＫｅｅｐフィールドが１であれば、ＢＳＣ５３０−２は、ＲｅｆｅｒｅｎｃｅＰｉｌｏｔＰＮフィールドに含まれるＰｉｌｏｔＰＮを使用する。ＲｅｆｅｒｅｎｃｅＫｅｅｐフィールドが０であれば、ＢＳＣ５３０−２は、Ｋｅｅｐフィールドが１でありＰｉｌｏｔＳｔｒｅｎｇｔｈフィールドが示すＰｉｌｏｔ強度が最も大きいＰｉｌｏｔＰＮを選択する。ＢＳＣ５３０−２は、選択したＰｉｌｏｔＰＮとシステムパラメータテーブル４１０のＰｉｌｏｔＰＮ４１４、隣接ＢＳＣ情報４３０のＰｉｌｏｔＰＮ４３４を比較し、無線コネクションを確立するＢＴＳを決定する。このときＢＳＣ５３０−２が選択するＢＴＳの中には隣接するＲＡＮ５００−２のＢＴＳであるＢＴＳ５４０−４とＢＴＳ５４０−５も含まれている。したがって、ＲＡＮ５００−２からＲＡＮ５００−１へＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを転送して呼接続を行う場合でも、ＢＴＳ５４０−４またはＢＴＳ５４０−５を選択することができる。図１１のシーケンスではＢＴＳ５４０−４を選択する。

ＢＴＳを決定したあと、ＢＳＣ５３０−２は、ＡＴ毎に管理するＡＴ管理テーブル４４０にＡＴのＵＡＴＩ３２ ２００をＵＡＴＩ３２ ４４１に登録する。ＢＳＣ５３０−２は、選択したＢＴＳを管理するＢＳＣのＩＰアドレスをＢＳＣＩＰＡｄｄｒｅｓｓ４４２に登録する。ＢＳＣは、選択したＢＴＳのＩＰアドレスをＢＴＳＩＰＡｄｄｒｅｓｓ４４３に登録する。図１１のシーケンスではＢＳＣ５３０−２のＡＴ管理テーブル４４０のＵＡＴＩ３２ ４４１にＡＴ６００のＵＡＴＩ３２ ２００、ＢＳＣＩＰＡｄｄｒｅｓｓ４４２にＢＳＣ５３０−３のＩＰアドレス、ＢＴＳＩＰＡｄｄｒｅｓｓ４４３にＢＴＳ５４０−４のＩＰアドレスを登録する。

ＢＳＣ５３０−２は、トラフィックチャネル確立要求の中にＵＡＴＩ３２ ４４１とＢＴＳＩＰＡｄｄｒｅｓｓ４４３を含めてＢＳＣ５３０−３に送信する（ｓｔｅｐ−ｈ）。トラフィックチャネル確立要求を受信したＢＳＣ５３０−３は、トラフィックチャネル確立要求に含まれるＡＴ６００のＵＡＴＩ３２ ４４１とＢＴＳ５４０−４のＩＰアドレス、トラフィックチャネル確立要求送信元のＢＳＣ５３０−２のＩＰアドレスをＢＳＣ５３０−３のＡＴ管理テーブル４４０のＵＡＴＩ３２ ４４１、ＢＴＳＩＰＡｄｄｒｅｓｓ４４３、ＢＳＣＩＰＡｄｄｒｅｓｓ４４２にそれぞれ登録する。

ＢＳＣ５３０−３は、ＢＳＣ５３０−２から受信したトラフィックチャネル確立要求をＡＴ管理テーブル４４０に登録されているＢＴＳＩＰＡｄｄｒｅｓｓ４４３に対して送信する（ｓｔｅｐ−ｉ）。トラフィックチャネル確立要求を受信したＢＴＳ５４０−４は、ＡＴ６００に対するトラフィックチャネルを確立する。このときトラフィックチャネル毎に管理するトラフィックチャネルテーブル４５０にトラフィックチャネル識別子４５１とＵＡＴＩ３２４５２を登録する。トラフィックチャネル識別子４５１にはトラフィックチャネルを確保した時の識別子を、ＵＡＴＩ３２ ４５２にはトラフィックチャネル確立要求に含まれるＵＡＴＩ３２を登録する。

ここまでの手順においてＢＳＣ５３０−２、ＢＳＣ５３０−３、ＢＴＳ５４０−４にはＡＴ６００に関するメッセージのルートがそれぞれのＡＴ管理テーブル４４０またはトラフィックチャネルテーブル４５０に記録される。したがって、以降のメッセージ送受信は、ＢＴＳ５４０−４＜−＞ＢＳＣ５３０−３＜−＞ＢＳＣ５３０−２のルートで行われる。またＡＴ管理テーブル４４０とトラフィックチャネルテーブル４５０は、無線コネクションが解放されるまで保持される。また以降にやり取りするメッセージの中には、ＡＴを特定するための情報であるＵＡＴＩ３２を含める。

次にＢＳＣ５３０−２とＰＣＦ−ＳＣ５１０−１との間でＡ８コネクションを確立する（ｓｔｅｐ−ｊ）。
次にＢＳＣ２とＡＴとの間でＴｒａｆｆｉｃＣｈａｎｎｅｌＡｓｓｉｇｎｍｅｎｔメッセージ、ＲＴＣＡｃｋメッセージ、ＴｒａｆｆｉｃＣｈａｎｎｅｌＣｏｍｐｌｅｔｅメッセージなどのやり取りを行い無線コネクションの確立を行う（ｓｔｅｐ−ｋ）。これらのメッセージ送受信は、ＢＴＳ５４０−４＜−＞ＢＳＣ５３０−３＜−＞ＢＳＣ５３０−２のルートで行われる。このときＡＴ６００は、Ａｃｔｉｖｅ状態となる（ｓｔａｔｅ−ｌ）。

次にＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ機能をサポートしていないＡＴ６００がドーマント状態のまま地理的にＲＡＮ５００−１からＲＡＮ５００−２の配下に移動した時の動作について説明する。

ＡＴ６００は、ＢＴＳ５４０−４のＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００を受信する。ＢＴＳ５４０−４のＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００のＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２には、ＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅ＝１が含まれる。しかし、ＡＴ６００は、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ機能をサポートしていないので、ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００に含まれるＳｅｃｔｏｒＩＤ４０１のＳｕｂｎｅｔ情報４０１１とＡＴのＵＡＴＩ１２８ ２１０に含まれるＳｕｂｎｅｔ情報２１１が異なることを検知し、ＵＡＴＩＲｅｑｕｅｓｔメッセージを送信する。ＵＡＴＩＲｅｑｕｅｓｔメッセージはＡＣ上で送信される。ＵＡＴＩＲｅｑｕｅｓｔメッセージをＢＴＳ５４０−４経由で受信したＢＳＣ５３０−３は、図１２を用いて説明したフローチャートに従って、ＲＡＮ間ドーマントハンドオフを行なう。つまり、ＰＣＦ−ＳＣ５１０−１とＰＣＦ−ＳＣ５１０−２との間で無線セッションの引き継ぎを行ない、ＡＴ６００に新しいＵＡＴＩを割り当ててＲＡＮ間ドーマントハンドオフを行なう。これによりＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ機能をサポートしていないＡＴがＲＡＮ境界を移動してきても対応可能とする。

上記の動作はドーマント状態のＡＴ６００が地理的にＲＡＮ５００−１からＲＡＮ５００−２に移動し、さらに、呼接続要求を行わないままＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００の中にＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２が含まれないエリアであるＢＴＳ５４０−６配下に移動したときも同様である。ＡＴ６００は、ＢＴＳ５４０−６のＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００を受信する。しかしがＢＴＳ５４０−６のＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００にはＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ４０２が含まれていない。また、ＳｅｃｔｏｒＰａｒａｍｅｔｅｒｓメッセージ４００に含まれるＳｅｃｔｏｒＩＤ４０１のＳｕｂｎｅｔ情報４０１１とＡＴのＵＡＴＩ１２８ ２１０に含まれるＳｕｂｎｅｔ情報２１１が異なる。このため、ＡＴ６００は、ＵＡＴＩＲｅｑｕｅｓｔメッセージを送信する。ＵＡＴＩＲｅｑｕｅｓｔメッセージを受信したＢＳＣ５３０−４は、図１２に従ってＲＡＮ間ドーマントハンドオフを行なう。

上述した実施例では、無線セッションが存在しないＲＡＮ上でも呼接続やメッセージの処理を行なうことができる。またＲＡＮ間ドーマントハンドオフを行なわずに呼接続を行なうのでＵＡＴＩ再割り当て失敗の確率を減らすと共に呼接続時間の短縮図ることができる。これはリアルタイム性を求めるアプリケーションでは特に有効な手段となる。

またＲＡＮ上でＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ機能を有効にしていても、ＳｅｃｏｎｄａｒｙＣｏｌｏｒＣｏｄｅ機能をサポートしていないＡＴはＲＡＮ間ドーマントハンドオフを行うことができる。
なお、ＣＣおよびＡＣを本明細書では、制御チャネルと呼ぶ。制御チャネル上では、ドーマント状態でも通信できる。

ドーマント状態のＡＴがＳｕｂｎｅｔを跨いで移動した際に、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージをＡＣ上で送信した場合について、図１３を参照して説明する。

非特許文献１で規定されるＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージは、無線コネクションを確立せずに小さいサイズのデータをＡＣ上またはＣＣ上で送受信することができる。図１３は、ＡＴがＡＣ上でＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージを送信する処理のシーケンス図である。図１３において、ドーマント状態（Ｓｔａｔｅ−ｍ）のＡＴ６００は、地理的にＲＡＮ５００−１からＲＡＮ５００−２に移動し、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージを送信する（ｓｔｅｐ−ｎ）。ＡＣのメッセージに含まれるＵＡＴＩ３２ ２００内のＣｏｌｏｒＣｏｄｅ２０１には、ＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅである１がセットされている。ＢＴＳ５４０−４は、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージをＢＳＣ５３０−３へ転送する（ｓｔｅｐ−ｏ）。ＢＳＣ５３０−３は、ＡＣ上でメッセージを受信した際、図１２従って、転送先のＢＳＣを決定する（ｓｔｅｐ−ｐ）。図１３のシーケンスではＢＳＣ５３０−２が選択される。ＢＳＣ５３０−３は、ＢＳＣ５３０−２に対してＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージを送信する（ｓｔｅｐ−ｑ）。この時、ＢＳＣ５３０−３は、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージにＢＴＳ５４０−４のＩＰアドレス４１３を付加して送信する。

ＢＳＣ５３０−２は、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージを受信したＢＳＣ５３０−３のＩＰアドレスに対してＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇＡｃｋメッセージを送信する（ｓｔｅｐ−ｒ）。また、ＢＳＣ５３０−２は、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇＡｃｋメッセージにＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージに付加されたＢＴＳ５４０−４のＩＰアドレス４１３を付加して送信する。ＢＳＣ５３０−３は、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇＡｃｋメッセージに付加されたＢＴＳ５４０−４のＩＰアドレスに対してＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇＡｃｋメッセージを送信する（ｓｔｅｐ−ｓ）。このときＢＳＣ５３０−３はＢＴＳ５４０−４のＩＰアドレスは取り除いてＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇＡｃｋメッセージのみ送信する。ＢＴＳ５４０−４は、ＡＴ６００にＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇＡｃｋメッセージを送信する（ｓｔｅｐ−ｔ）。

ＢＳＣ５３０−２は、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージをＡ９−ＳｈｏｒｔＤａｔａＤｅｌｉｖｅｒｙメッセージに載せてＰＣＦ−ＳＣ５１０−１に送信する（ｓｔｅｐ−ｕ）。ＰＣＦ−ＳＣ５１０−１は、ＡＴ６００の無線セッションを確認し、ＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージに含まれるデータをＰＤＳＮ１００に送信する（ｓｔｅｐ−ｖ）。ＡＴ６００は、ドーマント状態のままである（ｓｔａｔｅ−ｗ）。
図１３のシーケンスでは、ＡＴ６００の無線コネクションを確立しないためＢＳＣのＡＴ管理テーブル４４０とＢＴＳのトラフィックチャネルテーブル４５０は使用しない。

上述した実施例はＤａｔａＯｖｅｒＳｉｇｎａｌｉｎｇメッセージのみでなくＡＣで送信されるすべてのメッセージに適用可能である。これにより無線セッションが存在しないＲＡＮ上でもＡＣで送信されるメッセージの処理が可能となる。

図１１のシーケンスにおいて、ＡＴ６００の呼接続が完了し、ＡＴ６００がＡｃｔｉｖｅ状態となった後に（ｓｔａｔｅ−ｌ）、ＲＡＮ５００−１とＲＡＮ５００−２の間でＲＡＮ間Ａｃｔｉｖｅハンドオフを行ってもよい。以下にその方法を記載する。

ＡＴ６００の呼接続が完了後（ｓｔａｔｅ−ｌ）、ＢＳＣ５３０−２とＰＣＦ−ＳＣ５１０−１は、Ａ８とＡ１０のコネクションを解放し、ＰＣＦ−ＳＣ５１０−１とＰＣＦ−ＳＣ５１０−２の間で無線セッションの引き継ぎを行なう。次にＢＳＣ５３０−３とＰＣＦ−ＳＣ５１０−２は、Ａ８とＡ１０のコネクションを確立する。ＢＳＣ５３０−２のＡＴ管理テーブル４４０は、解放する。ＢＳＣ５３０−３は、ＡＴ管理テーブル４４０のＢＳＣＩＰＡｄｄｒｅｓｓをＢＳＣ５３０−２のＩＰアドレスからＢＳＣ５３０−３のＩＰアドレスに書き換える。ＢＳＣ５３０−３は、ＡＴ６００に対してＵＡＴＩの再割り当てを行い、ＵＡＴＩ３２ ２００とＵＡＴＩ１２８ ２１０にＲＡＮ５００−２のＣｏｌｏｒＣｏｄｅである２とＲＡＮ５００−２のＳｕｂｎｅｔ情報が含まれるようにする。

上述した実施例では、ＵＡＴＩの再割り当ては、無線コネクションを確立した後に行なっているので、ＵＡＴＩの再割り当て失敗のリスクが非常に小さい。またｓｔａｔｅ−ｌの状態ではＡＴ６００とＰＤＳＮ１００との間でデータを送受信する際にＡＴ６００＜−＞ＢＴＳ５４０−４＜−＞ＢＳＣ５３０−３＜−＞ＢＳＣ５３０−２＜−＞ＰＣＦ−ＳＣ５１０−１＜−＞ＰＤＳＮ１００の経路でデータが流れるが、ＲＡＮ間Ａｃｔｉｖｅハンドオフを行うことでＡＴ６００＜−＞ＢＴＳ５４０−４＜−＞ＢＳＣ５３０−３＜−＞ＰＣＦ−ＳＣ５１０−２＜−＞ＰＤＳＮ１００の経路でデータが流れるようになり遅延を小さくすることができる。

図１１のシーケンスにおいて、ＢＳＣ５３０−３は、ＢＳＣ５３０−２にメッセージを転送する代わりに、ＰＣＦ−ＳＣ５１０−１から無線セッションを取得し、ＢＳＣ５３０−３とＰＣＦ−ＳＣ５１０−１との間でメッセージのやり取りを行なってもよい。以下にその方法を記載する。

ＢＳＣ５３０−３は、ＰＣＦ−ＳＣ５１０−１のＩＰアドレスとＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅを隣接ＰＣＦ−ＳＣ情報として記録しておく。ＢＳＣ５３０−３は、ＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅを持つＡＣのメッセージを受信した際、隣接ＰＣＦ−ＳＣ情報を参照してＰＣＦ−ＳＣ５１０−１から無線セッションを取得する。または、ＢＳＣ５３０−３は、ＰＣＦ−ＳＣ５１０−１にメッセージを転送し、メッセージの処理を行なう。無線コネクションを確立する際、ＢＳＣ５３０−３とＰＣＦ−ＳＣ５１０−１は、お互いのＩＰアドレス、ＡＴのＵＡＴＩなどの情報を記録し、以降にやり取りされるメッセージも同じ経路でやりとりする。

図１１のシーケンスにおいて、ＢＳＣ５３０−３は、ＢＳＣ５３０−２にメッセージを転送する代わりに、ＰＣＦ−ＳＣ５１０−１とＰＣＦ−ＳＣ５１０−２の間で無線セッションの引き継ぎを行ない、その後、ＢＳＣ５３０−３は、ＰＣＦ−ＳＣ５１０−２の間でメッセージのやり取りを行なってもよい。以下にその方法を記載する。

ＰＣＦ−ＳＣ５１０−２は、ＰＣＦ−ＳＣ５１０−１のＩＰアドレスとＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅを隣接ＰＣＦ−ＳＣ情報として記録しておく。ＢＳＣ５３０−３は、ＲＡＮ５００−１のＣｏｌｏｒＣｏｄｅを持つＡＣのメッセージを受信した際、ＡＣのメッセージに付与されたＣｏｌｏｒＣｏｄｅをＰＣＦ−ＳＣ５１０−２に通知する。ＰＣＦ−ＳＣ５１０−２は、隣接ＰＣＦ−ＳＣ情報を参照し、ＰＣＦ−ＳＣ５１０−１から無線セッションを取得する。

ＢＳＣ５３０−３は、ＰＣＦ−ＳＣ５１０−２から無線セッションを取得する。または、ＢＳＣ５３０−３は、ＰＣＦ−ＳＣ５１０−２にメッセージを転送しメッセージの処理を行なう。

１００…ＰＤＳＮ、３００…ＩＰ−ＮＷ、４１０…システムパラメータテーブル４１０、４２０…システムパラメータテーブル、４３０…隣接ＢＳＣ情報、４４０…ＡＴ管理テーブル、４５０…トラフィックチャネルテーブル、５００…ＲＡＮ、５１０…ＰＣＦ−ＳＣ、５２０…Ｌ３−ＳＷ、５３０…ＢＳＣ、５４０…ＢＴＳ、６００…ＡＴ、１０００…無線通信システム。

Claims (13)

1. 移動端末と接続する複数の無線基地局を配下として制御する基地局制御装置において、
   第１の無線基地局から制御チャネル上でのメッセージを受信したとき、このメッセージに含まれる識別情報が自身の識別情報と一致するか判定し、不一致のとき前記メッセージが移動端末識別子要求メッセージか判定し、前記メッセージが前記移動端末識別子要求メッセージのとき、ドーマントハンドオフ処理を実施し、前記メッセージが前記移動端末識別子要求メッセージでないとき、前記識別情報に該当する他の基地局制御装置に前記メッセージを転送することを特徴とする基地局制御装置。
2. 請求項１に記載の基地局制御装置であって、
   前記自身の識別情報と、前記複数の無線基地局のアドレスと無線管理情報、前記他の基地局制御装置のアドレスと、前記他の基地局制御装置の識別情報と、前記他の基地局制御装置配下の無線基地局のアドレスと無線管理情報、からなるテーブルを保持することを特徴とする基地局制御装置。
3. 請求項１に記載の基地局制御装置であって、
   前記他の基地局制御装置との間で、前記識別情報と、配下の無線基地局のアドレスとを交換することを特徴とする基地局制御装置。
4. 請求項１に記載の基地局制御装置であって、
   メッセージの処理ルートをお互いに記録し、以降にやり取りするメッセージも同じルートで処理することを特徴とする基地局制御装置。
5. 請求項１に記載の基地局制御装置であって、
   移動端末の識別情報と、メッセージ送信先の前期基地局制御装置のアドレスと、メッセージ送信先の無線基地局のアドレスからなるテーブルを保持することを特徴とする基地局制御装置。
6. 請求項１に記載の基地局制御装置であって、
   移動端末の識別情報に該当する前期他の基地局制御装置が複数ある場合、同一の移動端末から複数のメッセージを受信しても常に同じ前期他の基地局制御装置が選択されるように転送先の前期他の基地局制御装置を決定することを特徴とする基地局制御装置。
7. 請求項１に記載の基地局制御装置であって、
   前期他の基地局制御装置から転送されてきたメッセージを受信し、自身の配下の複数の無線基地局と、前期他の基地局制御装置配下の無線基地局の中から距離や電波強度など条件が最も良い無線基地局を選択して呼接続を行うことを特徴とする基地局制御装置。
8. 請求項１に記載の基地局制御装置であって、
   移動端末からのメッセージが前期他の基地局制御装置を経由して転送された際に、移動端末への折り返しメッセージも同じルートで前期他の基地局制御装置を経由して送信することを特徴とする基地局制御装置。
9. 請求項１に記載の基地局制御装置と無線セッションの管理を行う無線パケット処理装置において、
   複数の前期基地局制御装置を跨いでメッセージを転送して呼接続を行い、以降のメッセージやデータも複数の前期基地局制御装置を跨いで処理されている状態において、前期無線パケット処理装置間で無線セッションの転送を行って、片方の前期基地局制御装置のルートを削除し、一つの前期基地局制御装置と前期無線パケット処理装置のルートでメッセージやデータ処理することを特徴とする無線パケット処理装置。
10. 移動端末と接続する複数の無線基地局を配下として制御する基地局制御装置と無線セッションの管理を行なう無線パケット処理装置において、
    前記基地局制御装置は、第１の無線基地局から制御チャネル上でのメッセージを受信したとき、このメッセージに含まれる識別情報が自身の識別情報と一致するか判定し、不一致のとき前記メッセージが移動端末識別子要求メッセージか判定し、前記メッセージが前記移動端末識別子要求メッセージのとき、ドーマントハンドオフ処理を実施し、前記メッセージが前記移動端末識別子要求メッセージでないとき、前記識別情報に該当する前記無線パケット処理装置から無線セッションを取得する、または前記識別情報に該当する前記無線パケット処理装置へメッセージを転送することを特徴とする無線パケット処理装置。
11. 請求項１０に記載の無線パケット処理装置であって、
    メッセージの処理ルートをお互いに記録し、以降にやり取りするメッセージも同じルートで処理することを特徴とする無線パケット処理装置。
12. 移動端末と接続する複数の無線基地局を配下として制御する基地局制御装置と無線セッションの管理を行なう無線パケット処理装置において、
    前記基地局制御装置は、第１の無線基地局から制御チャネル上でのメッセージを受信したとき、このメッセージに含まれる識別情報が自身の識別情報と一致するか判定し、不一致のとき前記メッセージが移動端末識別子要求メッセージか判定し、前記メッセージが前記移動端末識別子要求メッセージのとき、ドーマントハンドオフ処理を実施し、前記メッセージが前記移動端末識別子要求メッセージでないとき、メッセージに含まれる識別情報を前期無線パケット処理装置に通知し、前期無線パケット処理装置は通知された識別情報に該当する前記無線パケット処理装置から無線セッションを取得し、基地局制御装置は前記無線パケット処理装置から無線セッションを取得する、または前記無線パケット処理装置へメッセージを転送することを特徴とする無線パケット処理装置。
13. 請求項１２に記載の無線パケット処理装置であって、
    前記自身の識別情報と、前記の無線パケット処理装置のアドレスと、前記の無線パケット処理装置の識別情報とからなるテーブルを保持することを特徴とする無線パケット処理装置。

Images