JP2009506639A - 共用の補助的な拡散符号を使用するボイス・オーバｉｐが組み込まれた無線通信ネットワークにおけるハンドオフ - Google Patents

Abstract

共用の補助的な拡散符号を用いて、ＶｏＩＰ（Voice over Internet Protocol）を組み込む無線通信ネットワーク中でハンドオフを実施するための方法およびシステムが開示される。この方法およびシステムでは、移動局には、第１および第２の主符号と、補助符号の第１および第２の組が割り当てられる。第１の主符号および補助符号の第１の組は、第１の基地局に関連付けられる。第２の主符号および補助符号の第２の組は、第２の基地局に関連付けられ、その移動局がハンドオフ状態に入ったとき、移動局に割り当てられる。補助符号の第１および第２の組は、それぞれ、第１および第２の基地局に関連付けられた共用の補助符号のプールに属する。完全なパケットが、第１および第２の主チャネル上で単一の送信時間間隔にわたり送信できなかった場合、補助符号の第１および第２の組のそれぞれから、特定の補助符号が割り当てられる。各特定の補助符号は、割り当てられ得る前に、現在利用可能でなければならない。割り当てられる特定の補助符号インジケータを、補助符号の第１および第２の組に属する特定の補助符号に関連付けるために、マッピング・テーブルを使用することができる。マッピング・テーブルは、ＴＦＣ（Transport Combination Format）マッピング・テーブルとすることができ、また割り当てられる特定の補助符号インジケータを、ＴＦＣＩ（Transport Combination Format Indicator）とすることができる。第１および第２の基地局のそれぞれで、同じまたは異なる補助符号を示すために、単一のＴＦＣＩまたはその均等物を使用することができる。

Description

本発明は、一般に、インターネット・プロトコル・アプリケーションに関し、詳細には、無線通信システムにおけるハンドオフに関する。

（関連出願）
関連する主題は、同時出願の、また本発明と同一譲受人に譲渡された以下の出願に開示される。すなわち、発明者Jens Mueckenheim、Anil RaoおよびMirko Schacht、「Wireless Communications Network Incorporating Voice Over IP Using Shared Supplemental Spreading Codes」と題する米国特許出願第 号である。

よく知られた第３世代ＵＭＴＳ（Universal Mobile Telecommunications System）技術に基づいた無線通信ネットワークなどの無線通信ネットワーク中にＶｏＩＰ（Voice over Internet Protocol、ボイス・オーバ・インターネット・プロトコル）サービスを組み込むことは、コア・ネットワーク設計を簡単化し、従来の回線交換（ＣＳ）音声と比較して、新規のかつ価値のあるサービスを加えることになる。しかし、ＶｏＩＰはまた、本質的に大量のヘッダおよびシグナリングの形の追加のオーバヘッドを加えることになり、したがって、システムの容量を低下させる。
[発明が解決しようとする課題]

Jens Mueckenheim、Anil RaoおよびMirko Schachtによる、「Wireless Communications Network Incorporating Voice Over IP Using Shared Supplemental Spreading Codes」と題する同時出願の関連出願では、システム容量に対するＶｏＩＰの悪影響を最小化するために、共用の補助的な拡散符号に対する概念が開示されている。しかし、この概念は、ソフト・ハンドオフを処理する手順を提供しない。したがって、共用の補助的な拡散符号を使用する、ＶｏＩＰが組み込まれた無線通信ネットワークで使用するための１組のソフト・ハンドオフ手順に対する必要性が存在する。

米国特許出願第 号、Jens Mueckenheim、Anil RaoおよびMirko Schacht、「Wireless Communications Network Incorporating Voice Over IP Using Shared Supplemental Spreading Codes」

本発明は、無線通信ネットワークにおいてハンドオフを実施するための方法およびシステムである。一実施形態では、無線通信ネットワークは、共用の補助的な拡散符号を用いて、ＶｏＩＰ（Voice over Internet Protocol）を組み込む。この実施形態では、移動局には、第１および第２の主符号と、補助符号の第１および第２の組が割り当てられる。第１の主符号および補助符号の第１の組は、第１の基地局に関連付けられる。第２の主符号および補助符号の第２の組は、第２の基地局に関連付けられ、その移動局がハンドオフ状態に入ったとき、移動局に割り当てられる。補助符号の第１および第２の組は、それぞれ、第１および第２の基地局に関連付けられた共用の補助符号のプールに属する。完全なパケットが、第１および第２の主チャネル上で単一の送信時間間隔にわたり送信できなかった場合、補助符号の第１および第２の組のそれぞれから、特定の補助符号が割り当てられる。各特定の補助符号は、割り当てられ得る前に、現在利用可能でなければならない。

他の諸実施形態では、割り当てられる特定の補助符号インジケータを、補助符号の第１および第２の組に属する特定の補助符号に関連付けるために、マッピング・テーブルが使用される。マッピング・テーブルは、ＴＦＣ（Transport Format Combination）マッピング・テーブルとすることができ、また割り当てられる特定の補助符号インジケータを、ＴＦＣＩ（Transport Format Combination Indicators）とすることができる。実施形態では、第１および第２の基地局のそれぞれで、同じまたは異なる補助符号を示すために、単一のＴＦＣＩまたはその均等物を使用することができる。

本発明の特徴、諸態様、および利点は、以下の説明、添付の特許請求の範囲、および添付の図面に関してよりよく理解されよう。

本発明は、共用の補助的な拡散符号を用いて、ＶｏＩＰ（Voice over Internet Protocol）が組み込まれた無線通信ネットワークにおけるソフト・ハンドオフのための方法、およびそのシステムである。本発明のソフト・ハンドオフを完全に説明するために、無線通信ネットワーク、およびＶｏＩＰコールのセットアップおよび進行中のＶｏＩＰコールを処理するための手順を最初に説明する必要がある。図１は、本発明によるＵＭＴＳ（Universal Mobile Telecommunications System）ベースの無線通信システム１００、インターネット１０５、およびＶｏＩＰ電話１１０を示す。無線通信システム１００は、少なくともコア・ネットワーク１３０、ＲＡＮ（Radio Access Network）１６０、およびＵＥ（User Equipment、ユーザ装置）または移動局１４０を備える。コア・ネットワーク１３０は、ＧＧＳＮ（Gateway GPRS Support Node）１２０、ＳＧＳＮ（Serving GPRS Support Node）１２５、およびＭＳＣ（Mobile Switching Center）１５０を含む。ＧＧＳＮ１２０は、インターネット１０５とコア・ネットワーク１３０の間のインターフェースであり、一方、ＳＧＳＮ１２５は、コア・ネットワーク１３０とＲＡＮ１６０の間のインターフェースである。ＲＡＮ（Radio Access Network）１６０は、１つまたは複数のＲＮＣ（Radio Network Controller）１７０、および１つまたは複数のノードＢ（または基地局）１８０を含む。ＲＮＣ１７０はＲＲＣ（Radio Resource Control）１７５を含む。ＲＲＣ１７５は、ＣＭ（Code Manager）１８５を含む無線資源を管理するための機能を有する。ＣＭ１８５は、ＲＮＣ１７０に接続された各ノードＢ１８０に対して、ＯＶＳＦ（Orthogonal Variable Spreading Factor、直交可変拡散率）を管理するための機能を含む。

ノードＢとＵＥ１４０の間の通信チャネルは、多数のＯＶＳＦ（Orthogonal Variable Spreading Factor）符号を用いて構成される。ＶｏＩＰコールの場合、ＣＭ１８５は、ダウンリンクＤＣＨ（Dedicated Channel、専用チャネル）を構成するために、ＯＶＳＦ符号をＵＥ１４０に割り当てる。ＤＣＨを構成するために使用されるＤＣＨおよびＯＶＳＦ符号はまた、本明細書で、それぞれ、「主チャネル」および「主ＯＶＳＦ符号」と呼ぶ。ＵＭＴＳでは、ＤＣＨは、ＤＰＤＣＨ（Dedicated Physical Data CHannel）およびＤＰＣＣＨ（Dedicated Physical Control CHannel）を含む。

ＵＥ１４０の機能に応じて、ＣＭ１８５はまた、ＵＭＴＳのマルチ符号技法に従って、１組のＮ個の補助チャネルを構成するために、１組のＮ個のＯＶＳＦ符号をＵＥ１４０に割り当てることができる。ただし、Ｎは１以上の何らかの整数である。一実施形態では、補助チャネルはＤＰＤＣＨだけから構成することができる。他の実施形態では、補助チャネルは、ＤＰＤＣＨとＤＰＣＣＨだけから構成することができる。さらに他の実施形態では、補助チャネルは、少なくともＤＰＤＣＨと、おそらく、ＤＰＣＣＨから構成することができる。以降では、「補助ＯＶＳＦ符号」の用語は、補助チャネルをサポートするＯＶＳＦ符号を指すために使用されることに留意されたい。好ましい実施形態では、主および補助ＯＶＳＦ符号は、１２８などの同じＳＦを有する。

基本的に、ＵＥ１４０が、２つ以上のＤＰＤＣＨを同時にサポートする、例えば、復号できる場合、ＣＭ１８５は、１組のＮ個の補助ＯＶＳＦ符号をＵＥ１４０に割り当てることができる。このようなＵＥを、本明細書では、「マルチ符号ＵＥ」と呼ぶ。そうではなくて、ＵＥ１４０がマルチ符号ＵＥではない場合、ＣＭ１８５は、いずれの補助ＯＶＳＦ符号もＵＥ１４０に割り当てることはない。

ＵＥ１４０に割り当てられたＮ個の補助ＯＶＳＦ符号の組は、１組のＭ個の補助ＯＶＳＦ符号から選択される。ただし、ＭはＮ以上である。そのＭ個の補助ＯＶＳＦ符号の組は、ノードＢ１８０でＣＭ１８５により予約された１組のＯＶＳＦ符号であり、またノードＢ１８０で、補助チャネル（またはＯＶＳＦ符号）の共用プールと関連付けられている。本発明によれば、ノードＢごとに、ＣＭ１８５により予約された１組のＭ個の補助ＯＶＳＦ符号があることに留意されたい。１つのノードＢで予約された補助ＯＶＳＦ符号は、他のノードＢで予約された補助ＯＶＳＦ符号のいくつか、またはすべてを含むことができるが、あるいは全く含まないこともあり得る。好ましい実施形態では、パラメータＭは、補助ＯＶＳＦ符号が過度に予約されるのを最小化することと、Ｍを超える補助ＯＶＳＦ符号が同時に必要となり得る可能性との間で平衡をとるように選択すべきである。パラメータＭは、負荷、補助ＯＶＳＦ符号の使用量などのシステム・メトリクスに応じて、静的にまたは動的に判定され得る。パラメータＮは、ＴＦＣＳ（Transport Format Combination Set）を合理的なサイズに保つこと、ＵＥの複雑性を制限すること、およびＵＥの機能など、様々な因子に基づいて選択すべきである。一実施形態では、パラメータＮは、３８４ｋｂｐｓ、７６８ｋｂｐｓ、および２０４８ｋｂｐｓのデータレートが可能なマルチ符号ＵＥに対して３に設定される。

無線通信ネットワークを介するＶｏＩＰコールを処理することは、プロトコル・スタックの使用を必要とする。図２は、ＵＭＴＳベースの無線通信ネットワーク１００に従って使用されるＶｏＩＰ電話１１０とＵＥ１４０の間のＶｏＩＰコールのために使用されるプロトコル・スタック２００を示す。ＶｏＩＰコールは、ＵＭＴＳベースの無線通信システム１００のＰＳドメインで処理される。いくつかのシステム展開では、ＶｏＩＰ電話１１０は、ＰＳＴＮ（Public Switched Telephone Network、公衆電話交換網）コールをＶｏＩＰコールに変換する電子装置とすることができる。他の展開では、ＰＳＴＮまたは無線通信ネットワークは、ＰＳＴＮコールをＶｏＩＰコールに変換するＩＷＦ（Inter-Working Function）またはＭＧＷ（Media GateWay）を有することができる。図２に示すように、プロトコル・スタック２００は、ＡＭＲ（Adaptive Multi-Rate）レイヤ２０５、ＲＴＰ（Real Time Protocol）レイヤ２１０、ＵＤＰ／ＩＰｖ６（User Datagram Protocol／Internet Protocol version 6）またはバーション４などインターネット・プロトコルの他のバージョンのレイヤ２１５、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤ２２０、ＲＬＣ（Radio Link Control）レイヤ２２５、ＭＡＣ−ｄ（dedicated Medium Access Control）レイヤ２３０、およびＰＨＹ（PHYsical：物理）レイヤ２３５を含む。ＡＭＲレイヤ２０５、ＲＴＰレイヤ２１０、およびＵＤＰ／ＩＰｖ６レイヤ２１５は、ＶｏＩＰ電話１１０に実装される。ＰＤＣＰレイヤ２２０、ＲＬＣレイヤ２２５、およびＭａｃ−ｄレイヤ２３０は、ＲＮＣ１７０に実装される。またＰＨＹレイヤ２３５は、ノードＢ１８０に実装される。ＵＤＰ／ＩＰｖ６レイヤ２１５が単一のレイヤとして示されているが、その実装形態は、おそらく、２つの別々のＵＤＰレイヤとＩＰｖ６レイヤになるはずであることに留意されたい。

例示のために、ＶｏＩＰ電話１１０からＵＥ１４０に音声情報が送られたと仮定する。ＶｏＩＰ電話１１０で、音声はＡＭＲレイヤ２０５で（ＡＭＲコーデックを介して）符号化されて、１５９音声ビットを有する音声フレームが生成される。ＲＴＰレイヤ２１０では、ＲＴＰペイロードが、１つまたは複数の音声フレームに、４ビットのＣＭＲ（Codec Mode Request）フィールドを付加し、ＲＴＰペイロードの各音声フレームに対して６ビットのＴＯＣ（Table Of Contents）フィールドを追加することにより、またオクテット調整のためにビットをパディングすることにより形成される。１５９音声ビットで７．９５ｋｂｐｓコーデックのＡＭＲの場合、ＲＴＰペイロードに７個のパディング・ビットが付加される。ＲＴＰパケットは、ＲＴＰシーケンス番号、タイムスタンプ、ＭおよびＸフィールド、同期化ソースＩＤなどの情報を搬送するために、ＲＴＰペイロードに、１２バイトのＲＴＰヘッダを付加することにより形成される。

ＵＤＰ／ＩＰｖ６レイヤ２１５では、８バイトのＵＤＰヘッダおよび４０バイトのＩＰヘッダがＲＴＰパケットに付加されて、ＵＤＰ／ＩＰｖ６パケットが生成される。ＵＤＰヘッダは、ソース／宛先ポート番号およびＵＤＰチェックサムを示し、ＩＰヘッダは、ソース／宛先ＩＰアドレスを示す。したがって、ヘッダおよび他の情報の形で６０バイトを超えるオーバヘッドが、ＲＴＰおよびＵＤＰ／ＩＰｖ６レイヤ２１０、２１５により元の１５９ビットの音声フレームに付加され、その結果、３００％を超えるビット・サイズの増加となる。

ＵＤＰ／ＩＰｖ６パケットは、ＶｏＩＰ電話１１０からインターネット１０５を介してＧＧＳＮ１２０に送られる。ＧＧＳＮ１２０から、ＵＤＰ／ＩＰｖ６パケットはＳＧＳＮ１２５に、次いでＲＡＮ１６０に転送される。幸いに、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダ中で搬送される情報の多くは静的であるため、ＵＤＰ／ＩＰｖ６パケットがＲＡＮ１６０に達した後、音声パケットごとに完全なＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダを無線インターフェースを介して送信することはもはや必要ではない。例えば、ＵＥ１４０などの指定受信者が、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダ中の静的な情報をすべて取得した後、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダは、ＲｏＨＣ（Robust Header Compression）を用いてＰＤＣＰレイヤ２２０で圧縮することができ、ＲＴＰペイロードおよび圧縮されたヘッダからなるＰＤＣＰパケットが形成される。圧縮されたヘッダは、ＲＴＰシーケンス番号、タイムスタンプ、ＭおよびＸフィールド、およびＵＤＰチェックサムなどの、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダ中の動的な情報を含む。大部分の状況では、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダは３バイトに圧縮することができる。特に、ＲＴＰヘッダは、シーケンス番号の６個のＬＳＢ（least significant bits、最下位ビット）を示す１バイトにまで圧縮することができる。ＵＤＰヘッダは、ＵＤＰチェックサムに応じて２バイトまで圧縮できる。他の状況では、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダ中の低い動的情報のいくつかが、例えば、再同期化中に、または会話区間の開始時に受信側で更新される必要があるはずなので、圧縮されるヘッダを３バイトまで圧縮することはできない。後者の状況では、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダを全く圧縮しないことも可能であることに留意されたい。ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダが圧縮されない場合、ＰＤＣＰパケットは、ＲＴＰペイロードおよび非圧縮のＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダとから構成されるはずである。したがって、ＰＤＣＰパケットは、３から６０バイトの間のいずれかとすることのできるＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダの表現を含むことになる。ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダ表現におけるこのような増減により、かなりのデータレート変動を生ずることになる。

ＲＬＣレイヤ２２５では、１バイトのＲＬＣ ＵＭヘッダがＰＤＣＰパケットに付加されてＲＬＣパケットが生成されるが、ＲＬＣ ＵＭヘッダは、ＲＬＣシーケンス番号を含む。ＲＬＣパケットは、その後、無線インターフェースを介してノードＢ経由でＵＥ１４０に送信される前に、ＭＡＣ−ｄレイヤ２３０およびＰＨＹレイヤ２３５で処理される。

ヘッダにより付加されるオーバヘッドに加えて、ＶｏＩＰと関連付けられたシグナリングもまた付加される。ＶｏＩＰは、ＲＴＣＰ（Real Time Control Protocol）およびＳＩＰ（Session Initiation Protocol）など追加のシグナリングを必要とする。この追加のシグナリングにより、最高４つのトランスポート・チャネル（音声フレームがそれを介して送信されるダウンリンクＤＣＨを含む）を多重化することができる。すなわち、ＳＲＢ（Signaling Radio Bearer）に対する第１のトランスポート・チャネルと、音声を搬送するための第２のトランスポート・チャネル、すなわち、ＤＣＨ、ＲＴＣＰに対する第３のトランスポート・チャネルと、ＳＩＰに対する第４のトランスポート・チャネルである。これらの各チャネルは、複数のデータレートと関連付けられている。ＳＲＢは、０および３．４ｋｂｐｓのデータレートと関連付けられている。音声は、０、１６、および３９．２ｋｂｐｓのデータレートと関連付けられている（ただし、３９．２ｋｂｐｓのデータレートは、非圧縮のＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダを有するパケットに対応する）。また、ＲＴＣＰおよびＳＩＰは、０、８、および１６ｋｂｐｓのデータレートと関連付けられている。これらの各チャネルに対する活動は、かなりのデータレート変動を生じ得る。

ヘッダおよびシグナリングの形のオーバヘッドの増減によるデータレート変動のため、本発明は、システム資源をさらに効率的に利用できるように、無線通信ネットワークにおいて共用の補助符号の概念を使用するが、それをここで説明する。図３は、本発明に従って、補助チャネルの共用プールを使用し、ダウンリンクＤＣＨを介してＶｏＩＰ（Voice over Internet Protocol）サービスを実施するためのコールセットアップ手順を示す流れ図４００を示す。ステップ４０５では、ＵＥ１４０に対するＶｏＩＰサービスが要求されている。ステップ４１０で、ＲＲＣ１７５は、ＵＥ１４０の機能に基づいて、補助ＯＶＳＦ符号をＵＥ１４０に割り当てるべきかどうか判定する。基本的には、ＵＥ１４０がマルチ符号ＵＥである場合、ＲＲＣ１７５は、補助ＯＶＳＦ符号をＵＥ１４０に割り当てるべきであると判定する。補助ＯＶＳＦ符号をＵＥ１４０に割り当てるべきではないと判定された場合、ステップ４２０で、ＲＲＣ１７５はパラメータＮの値を決定せず、またＣＭ１８５は、ＵＥ１４０に補助ＯＶＳＦ符号を何も割り当てない。ステップ４２０から、流れ図４００はステップ４２５に進み、ＣＭ１８５は、主ＯＶＳＦ符号をＵＥ１４０に割り当てる。

一方、補助ＯＶＳＦ符号をＵＥ１４０に割り当てるべきである場合、ステップ４１５で、ＲＲＣ１７５は、パラメータＮの値を決定し、ＣＭ１８５が、Ｎ個の補助ＯＶＳＦ符号をＵＥ１４０に割り当てる。Ｎ個の補助ＯＶＳＦ符号は、Ｍ個のＯＶＳＦ符号の組から選択される。ステップ４１５から、流れ図４００はステップ４２５に進み、ＣＭ１８５は主ＯＶＳＦ符号をＵＥ１４０に割り当てる。ステップ４３５で、ＲＮＣ１７０は、割り当てられた主ＯＶＳＦ符号の識別と、適用可能である場合、Ｎ個の補助ＯＶＳＦ符号の識別とを、ＤＣＣＨ（Dedicated Control Channel）または同様のダウンリンク制御チャネルを介し、ノードＢ１８０を経由してＵＥ１４０に伝える。ステップ４４０で、ＵＥ１４０は、主および補助ＯＶＳＦ符号（適用可能な場合）の識別を受け取る。ＵＥ１４０は、いまや主および補助ＯＶＳＦ符号で構成された主および補助チャネル、すなわち複数のＤＰＤＣＨを介して受信されたデータを記憶し始めることになる。ＵＥ１４０は、主チャネル上のデータを復号する。ＵＥ１４０がマルチ符号ＵＥであり、補助ＯＶＳＦ符号に割り当てられている場合、ＵＥ１４０は、特定の補助チャネルを復号するための何らかのタイプの標識を受け取らない限り、関連付けられたいずれの補助チャネルのデータも復号することはないが、それをここで説明する。

コールセットアップが完了した後、ＵＥはいつでもＶｏＩＰコールを受信することができる。図４は、本発明に従って、ダウンリンクＤＣＨを介する進行中のＶｏＩＰコールを示す流れ図５００を示す。ステップ５４０で、ＲＮＣ１７０は、ＲＡＮ１６０からパケットを受信し、ＵＥ１４０へのパケット送信のために、主チャネルに加えて補助チャネルを使用すべきかどうか判定する。基本的には、パケットがこれらの組合せのうちの１つを含む場合、補助チャネルを使用すべきではない。すなわち、音声、圧縮されたＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダおよびＳＲＢ、ＳＩＰおよびＳＲＢ、あるいはＲＴＣＰおよびＳＲＢである。パケットがこれらの組合せのうちの１つを含む場合、補助チャネルを使用すべきである。すなわち、音声、非圧縮のＲＴＰ／ＵＤＰ／ＩＰｖ６およびＳＲＢ、あるいは音声、圧縮されたＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダ、ＳＲＢおよびＳＩＰである。一実施形態では、補助チャネルを使用すべきがどうかの判定は、パケット・サイズに基づく。より具体的には、単一のＴＴＩ（Transmission Time Interval、送信時間区間）、例えば、２０ｍｓ中にＤＣＨを介してパケットを送信できない場合、補助チャネルを使用すべきである。パケット送信に補助チャネルを使用すべきではないと判定された場合、流れ図５００はステップ５６５に進む。

補助チャネルをパケット送信のために使用すべきであると判定された場合、ステップ５４５で、ＣＭ１８５は、補助ＯＶＳＦ符号をＵＥ１４０に割り当てることが実行可能であるかどうか判定する。一実施形態では、１組のＮ個の補助ＯＶＳＦ符号がＵＥ１４０に割り当てられていた場合、ＣＭ１８５は、これらの補助ＯＶＳＦ符号のいずれかが現在利用可能であるか、すなわち、他のＵＥで現在使用されていないかどうか調べるために検査する。１組のＮ個の補助ＯＶＳＦ符号がＵＥ１４０に割り当てられていなかった場合、または割り当てられたＮ個の補助ＯＶＳＦ符号のいずれも現在利用できない場合、補助ＯＶＳＦ符号をＵＥ１４０に割り当てることは実行できないと判定され、流れ図５００はステップ５５０に進む。ステップ５５０では、（続くプロトコル・レイヤでさらに処理された後）主チャネルだけを介して、ノードＢ経由でＵＥ１４０にパケットを送信するために、フレームスティーリング（frame stealing）と呼ばれるよく知られた技法がＲＮＣ１７０により使用される。よく知られているように、フレームスティーリングは、音声フレームを空けておき、その場所で（オーバヘッド情報の一部である）制御情報を送る技法である。フレームスティーリングは、音声品質に悪影響を与える可能性のある音声フレームの喪失となる。ステップ５５０から、流れ図５００はステップ５６５に進む。

一方、補助チャネルをＵＥ１４０に割り当てることが実行可能であると判定された場合、流れ図５００はステップ５５５に進み、ＣＭ１８５がＮ個の補助ＯＶＳＦ符号の割り当てられる組から特定の補助ＯＶＳＦ符号を割り当てる。特定の補助ＯＶＳＦ符号を割り当てると、ステップ５６０で、ＲＮＣ１７０は、ノードＢを経由して、（その後のプロトコル・レイヤでさらに処理された後）パケットの一部分、および割り当てられた特定の補助ＯＶＳＦ符号の識別（または補助ＯＶＳＦ符号またはそれに関連付けられた補助チャネルの標識）を、主チャネルのＤＰＤＣＨおよびＤＰＣＣＨをそれぞれ介して送信し、また（その後のプロトコル・レイヤでさらに処理された後）パケットの他の部分を、特定の補助ＯＶＳＦ符号で構成された補助チャネルのＤＰＤＣＨを介して送信する。割り当てられた特定の補助ＯＶＳＦ符号の識別およびパケットの両方の部分が同時に送られることが好ましい。他の諸実施形態では、割り当てられた特定の補助ＯＶＳＦ符号の識別は、パケットの両方の部分よりも早くまたは遅れて送ることができる。

一実施形態では、特定の補助ＯＶＳＦ符号の識別は、ＤＣＨのＤＰＣＣＨ上のＴＦＣＩ（Transport Format Combination Index）フィールドを用いて搬送される。ＴＦＣＩは、通常、フレームサイズ、例えば、３００ビットを示すだけであることに留意されたい。本発明のこの実施形態では、ＴＦＣＩは、フレームサイズと、適用可能である場合、割り当てられた特定の補助ＯＶＳＦ符号とを共に示すことになる。ＴＦＣＩ１は、３００ビットのフレームサイズであり、かつ割り当てられた補助ＯＶＳＦ符号がないことを示し、ＴＦＣＩ４は、６００ビットのフレームサイズであり、かつ割り当てられたＮ個の補助ＯＶＳＦ符号の組から割り当てられた特定の補助ＯＶＳＦ符号を示すことができる。割り当てられた特定の補助ＯＶＳＦ符号は、Ｎ個の補助ＯＶＳＦ符号の組の中のその相対的な位置によって、例えば、Ｎ個の補助ＯＶＳＦ符号の組の第１の補助ＯＶＳＦ符号によって示すことができ、あるいはその一意の識別、例えば、補助ＯＶＳＦ符号６７を参照することによって示すことができる。ＴＦＣＩに対するマッピングを示すために、コールセットアップ中に、ＵＥ１４０に対してＴＦＣＩマッピング・テーブルを提供することができる。すなわち、ＵＥ１４０がＴＦＣＩを受信したとき、ＴＦＣＩマッピング・テーブルを参照して、適切なＴＦＣと、適用可能な場合、補助ＯＶＳＦ符号を決定する。ＴＦＣマッピング・テーブルは、少なくとも、フレームサイズおよび、適用可能な場合、補助ＯＶＳＦ符号に対するＴＦＣＩのためのルックアップ・テーブル、またはそれと同様のものである。

流れ図５００はステップ５６５に進む。ステップ５６５で、ＵＥ１４０がマルチ符号ＵＥであると仮定すると、ＵＥ１４０は、主チャネルのＤＰＣＣＨ上の制御情報を復号して、（Ｎ個の補助ＯＶＳＦ符号の組からの）補助ＯＶＳＦ符号の１つが、ＵＥ１４０に割り当てられているかどうかを判定する。一実施形態では、補助ＯＶＳＦ符号の識別が制御情報中で示されている場合、ＵＥ１４０は、制御情報中で示された補助ＯＶＳＦ符号がそれに割り当てられていたと判定することになる。そうではない場合、ＵＥ１４０は、補助ＯＶＳＦ符号が何もそれに割り当てられていなかったと判定する。

ＵＥ１４０は、主チャネルのＤＰＤＣＨ上のデータを常に復号しようとすることに留意されたい。制御情報が、データを送るのに使用されている特定の補助ＯＶＳＦ符号（または、補助チャネル）の識別を示す場合、ＵＥ１４０はまた、識別された補助チャネル上のＤＰＤＣＨのデータも復号し、他の補助チャネル上のデータは廃棄する。制御情報が、データが主チャネル上だけに存在することを示す場合、ＵＥ１４０は、すべての補助チャネル上のデータを廃棄する。

ＵＥが、補助ＯＶＳＦ符号がそれに割り当てられていると判定した場合、流れ図５００はステップ５７０に進み、ＵＥ１４０は、その主チャネルのＤＰＤＣＨ上のデータを復号するのに加えて、割り当てられた補助チャネルのＤＰＤＣＨ上のデータを復号することになる。そうではない場合、流れ図５００はステップ５７５に進み、ＵＥ１４０は、その主チャネルのＤＰＤＣＨ上のデータを復号するが、Ｎ個の補助チャネルのその割り当てられた組のいずれのＤＰＤＣＨ上のデータも復号しない。

ＶｏＩＰコールが進行中であるとき、ＵＥ１４０が、１つのノードＢ１８０（本明細書ではまた「現在のノードＢ」と呼ぶ）の通達範囲から、他のノードＢ１８０（本明細書ではまた「新しいノードＢ」と呼ぶ）の通達範囲に移動することもあり得る。このような状況では、現在のノードＢから新しいノードＢへのハンドオフは、ＵＥ１４０がＶｏＩＰコールを打ち切ることのないように行われる必要がある。図５は、本発明による１組のハンドオフ手順を示す流れ図３００を示す。ステップ３０５で、ＵＥ１４０は、本明細書で「隣接セット」と呼ぶ１組のノードＢからのパイロット信号強度をモニタして、隣接セットのノードＢのいずれかが、閾値レベルで、またはそれ以上のパイロット信号強度で関連付けられているかどうかを判定する。本発明に関して、パイロット信号強度は、パイロット信号対ノイズ比またはパイロットの受信信号レベルなど、ＣＤＭＡシステムに対する任意の品質尺度と等価である。このような隣接セットのノードＢが存在しない場合、ＵＥ１４０は、ステップ３０５で、パイロット信号強度のモニタを続ける。このような隣接セットのノードＢが存在する場合、ステップ３１０で、ＵＥ１４０は、現在のノードＢと関連付けられたＲＮＣ（本明細書で「サービングＲＮＣ」または「Ｓ−ＲＮＣ」と呼ぶ）に、そのアクティブ・セットに対して新しいノードＢ（すなわち、閾値レベルで、またはそれを超えるパイロット信号強度で関連付けられた隣接セットのノードＢ）を追加するように要求する。通常、このような要求は、逆方向リンク制御チャネル、すなわち、逆方向リンクＤＣＣＨを介して現在のノードＢに送られ、ノードＢは、次にそれをＳ−ＲＮＣに転送する。

アクティブ・セットに新しいノードＢを追加する（またアクティブ・セットにおける基地局の数を１から２に増加する）このプロセスは、ハンドオフ状態に入ることとして知られていることに留意されたい。新しいノードＢがアクティブ・セットに追加されると、ＵＥはハンドオフ状態になる。

ステップ３１０で、Ｓ−ＲＮＣ（またはＣＭ１８５）は要求を受け取り、新しいノードＢがＳ−ＲＮＣと、または本明細書で「ドリフトＲＮＣ」すなわち「Ｄ−ＲＮＣ」と呼ぶ他のＲＮＣ１７０と関連付けられているかどうか判定するが、他のＲＮＣ１７０は、Ｓ−ＲＮＣにより制御できない、Ｄ−ＲＮＣの制御下の、ノードＢに対する別個の符号マネジャを所有する。新しいノードＢが、Ｄ−ＲＮＣに関連付けられていない場合、流れ図３００はステップ３３０に進み、Ｄ−ＲＮＣ状況を処理するための手順が実施される。Ｄ−ＲＮＣ状況を処理するためのいくつかの選択肢は以下のようになる。第１の選択肢は、現在のノードＢから新しいノードＢへのＵＥ１４０のソフト・ハンドオフを回避することを含む。ＵＥ１４０は、新しいノードＢとの無線リンク品質が改善されるまで、現在のノードＢとのその無線リンクを維持することになる。このようなイベントが生じた場合、現在のノードＢから新しいノードＢへのハード・ハンドオフが実施される。第２の選択肢は、ＳＲＮＳ（Serving Radio Network Subsystem）の再配置を実施することである。ＳＲＮＳの再配置では、Ｓ−ＲＮＣとコア・ネットワークの間の接続（以降、「Ｉｕ接続」と呼ぶ）がＤ−ＲＮＣに再配置される。この第２の選択肢は、第１の選択肢と組み合わせることができる、すなわち、ハード・ハンドオフがＳＲＮＳ再配置と組み合わされる。

第３の選択肢は、ＵＥ１４０を主ＯＶＳＦ符号に限定することを含む。この選択肢では、補助ＯＶＳＦ符号の割振りをもはや実施することができず、またフレームスティーリングなどの技法は、状況が必要とする場合、例えば、補助チャネルに対する必要性をトリガする状況で、実装されるはずである。最後の選択肢は、補助ＯＶＳＦ符号をＵＥ１４０に何も割り当てないことを含む。

ステップ３１０で、新しいノードＢが（Ｄ−ＲＮＣではなく）Ｓ−ＲＮＣに関連付けられている場合、流れ図３００はステップ３５０に進み、ＣＭ１８５が新しいノードＢに対して主符号を割り当て、必要な場合、ＵＥ１４０に現在割り当てられたＮ個の補助ＯＶＳＦ符号の組を、Ｎ個の補助ＯＶＳＦ符号の新しい組に変更する。本明細書で「交差セット実施形態」と呼ばれる一実施形態では、現在ＵＥ１４０に割り当てられているＮ個の補助ＯＶＳＦ符号の組が、新しいノードＢと関連付けられたＭ個の補助ＯＶＳＦ符号の共用プールの一部ではない場合、現在のノードＢに対するＮ個の補助ＯＶＳＦ符号の新しい組が、ＣＭ１８５によりＵＥ１４０に割り当てられることになる。このＮ個の補助ＯＶＳＦ符号の新しい組は、現在のノードＢと新しいノードＢに共通の、１組の共用の補助ＯＶＳＦ符号から選択される。言い換えると、現在および新しいノードＢはそれぞれ、補助ＯＶＳＦ符号の共用プールと関連付けられる。現在のノードＢに関連付けられた補助ＯＶＳＦ符号のいくつかまたはすべてが、新しいノードＢにも関連付けられる。これらの共通の補助ＯＶＳＦ符号はまた、本明細書で「交差セット」と呼ばれ、新しいＮ個の補助ＯＶＳＦ符号の組はまた、本明細書で「Ｎ個の補助ＯＶＳＦ符号の交差セット」と呼ばれる。交差セットは、同じＲＮＣまたは異なるＲＮＣと関連付けられたすべてのノードＢにわたり、全体的にまたは部分的に、同じものとすることができる。Ｎ個の補助ＯＶＳＦ符号の交差セットにおける補助ＯＶＳＦ符号が両方のノードＢに共通であるので、ＴＦＣＩを割り当てられた特定の補助ＯＶＳＦ符号に関連付けるために、同じＴＦＣマッピング・テーブルを使用することができる。

他の実施形態では、１組のＮ個の補助ＯＶＳＦ符号が、新しいノードＢに対してＵＥ１４０に割り当てられる。本明細書で「組合せセット実施形態」と呼ばれるこの実施形態では、新しいノードＢおよび現在のノードＢに関連付けられたＮ個の補助ＯＶＳＦ符号の組は、異なる補助ＯＶＳＦ符号を含む可能性が最も高い。各ノードＢに関連付けられた別々のＴＦＣマッピング・テーブルが、現在および新しいノードＢのコールセットアップ中など、１組のＮ個の補助ＯＶＳＦ符号が割り当てられるたびに、ＵＥ１４０に送られる。異なるノードＢでは、おそらく、ＴＦＣＩは、異なる特定の補助ＯＶＳＦ符号を指すことに留意されたい。

さらに他の実施形態では、各補助ＯＶＳＦ符号はクラスと関連付けられるが、クラスは、いつ補助ＯＶＳＦ符号を割り当てることができるかを指定する。例えば、補助ＯＶＳＦ符号に４クラスあると仮定する。補助ＯＶＳＦ符号の第１のクラスは、ソフト・ハンドオフではなく、１つの無線リンクでＵＥに割り当てることができるに過ぎない。補助ＯＶＳＦ符号の第２のクラスは、２つの無線リンク、すなわち、２つのノードＢだけとのソフト・ハンドオフでＵＥに割り当てることができるに過ぎない。同様に、補助ＯＶＳＦ符号の第３および第４のクラスは、それぞれ、３および４の無線リンクでＵＥに割り当てることができるに過ぎない。最初の（ソフト・ハンドオフの前の）コールセットアップの間、ＵＥ１４０は、第１のクラスに属する１組のＮ個の補助ＯＶＳＦ符号が割り当てられる。ＵＥ１４０が、新しいノードＢとソフト・ハンドオフに入ったとき、ＣＭ１８５は、現在と新しいノードＢの両方に対して、第２のクラスに属する１組のＮ個の補助ＯＳＶＦ符号を割り当てる（一方、第１のクラスに属する、現在のノードＢの最初に割り当てられたＮ個の補助ＯＳＶＦの組を置き換える）。両方のノードＢに関連付けられたＮ個の補助ＯＶＳＦ符号の組における補助ＯＶＳＦ符号は、完全に、または部分的に同一とすることも、または同一としないこともできる。ノードＢのそれぞれに関連付けられたＴＦＣマッピング・テーブルは、１組のＮ個の補助ＯＶＳＦ符号が割り当てられるたびに、ＵＥ１４０に送られる。

流れ図３００に戻ると、ステップ３６０で、現在のノードＢは、新しいノードＢの主ＯＶＳＦ符号、およびＮ個の補助ＯＶＳＦ符号の交差セットの識別を、ＤＣＣＨを介してＵＥ１４０に伝える。ステップ３７０で、ＵＥ１４０は、前述の識別を受け取り、（現在のノードＢの主ＯＶＳＦ符号で構成された主チャネルは維持しつつ）受信した主ＯＶＳＦ符号を用いて新しいノードＢとの主チャネルをセットアップする。ＵＥ１４０はまた、現在のノードＢおよび新しいノードＢから、Ｎ個の補助ＯＶＳＦ符号の交差セットで構成された補助チャネル上で受信されるデータの記憶を開始することになる。新しいノードＢと関連付けられた主および補助チャネルがセットアップされた後、ＵＥ１４０と各ノードＢの間のＶｏＩＰコールが、流れ図５００に関して本明細書で述べられた進行中のＶｏＩＰコールに対する手順に従って処理される。

交差セット実施形態に関して、（図４のステップ５４０から５５５で述べたように）補助チャネルが必要である場合、ＣＭ１８５は、両方のノードＢに対して、Ｎ個の補助ＯＶＳＦ符号の交差セットから同じ特定の補助ＯＶＳＦ符号を割り当てることに留意されたい。同じ特定の補助ＯＶＳＦ符号が割り当てられるので、割り当てられた特定の補助ＯＶＳＦ符号の識別は、同じインジケータまたは識別を用いて示すことができる。すなわち、現在のノードＢに対して、割り当てられた特定の補助ＯＶＳＦ符号の標識を、また新しいノードＢに対して、割り当てられた特定の補助ＯＶＳＦ符号の別個の標識を送るのではなく、１つの標識を両方で使用することができる。新しいノードＢは、すでにＵＥのアクティブ・セットに追加されているが（また、もはや隣接セットのノードＢとは見なされないが）、用語「新しいノードＢ」を、「現在のノードＢ」と区別するために本明細書で続けて使用することに留意されたい。すなわち、ノードＢは、新しいノードＢの前のアクティブ・セットであり現在もそうであるからである。

この割り当てられた特定の補助ＯＶＳＦ符号の識別（またはその標識）は、ステップ５６０に従って、現在のノードＢと新しいノードＢに関連付けられた両方の主チャネルのＤＰＣＣＨを介して送られる。有利には、両方の主チャネルのＤＰＣＣＨを介して、割り当てられた特定の補助ＯＶＳＦ符号の標識を送ることにより、ＤＰＣＣＨ上で送られる標識のソフトコンバインを可能にし、それにより、ソフト・ハンドオフでは暗黙のマクロ・ダイバーシティ利得を利用することができる。それに反して、異なる特定の補助ＯＶＳＦ符号が各ノードＢに割り当てられた場合、（両方の補助ＯＶＳＦ符号の識別の）別々の標識をＵＥ１４０に送る必要があるはずである。標識が異なっているため、ＤＰＣＣＨをソフトコンバインすることができない。

組合せセット実施形態に関して、補助チャネルが必要である場合、ＣＭ１８５は、まず、単一のＴＦＣＩにより参照される特定の補助ＯＶＳＦ符号が、いずれかの特定の補助ＯＶＳＦ符号を割り当てる前に、現在すべてが利用可能であることを検査する。すなわち、ＴＦＣＩは、現在のノードＢに関連付けられたＴＦＣマッピング・テーブルに基づいて、特定の補助ＯＶＳＦ符号を、また新しいノードＢと関連付けられたＴＦＣマッピング・テーブルに基づいて、異なる特定の補助ＯＶＳＦ符号を参照することができる。２つの異なる補助ＯＶＳＦ符号が、単一のＴＦＣＩで参照できるので、ＣＭ１８５は、次いで、いずれかの特定の補助ＯＶＳＦ符号の割当てを行う前に、（単一のＴＦＣＩにより参照された）その各ノードＢにおける特定の補助ＯＶＳＦ符号のすべてが、現在利用可能であることを検査する必要がある。割当てが行われると、ＴＦＣＩは、両方の主チャネルのＤＰＣＣＨを介して送信される。

階層化セット実施形態に関して、補助チャネルが必要である場合、ＣＭ１８５はまた、いずれかの特定の補助ＯＶＳＦ符号を割り当てる前に、単一のＴＦＣＩにより参照された特定の補助ＯＶＳＦ符号が、すべて現在利用可能であることを検査することになる。割当てが行われると、ＴＦＣＩは、両方の主チャネルのＤＰＣＣＨを介して送信される。

いくつかの実施形態を参照して本発明をかなり詳細に述べてきたが、他のバージョンも可能である。例えば、流れ図４００および５００における一連の諸ステップは、異なるものとすることができる。ＡＭＲ以外のコーデックを使用することができる。ＶｏＩＰ以外のデータ・アプリケーションを使用することもできる。さらに、諸実施形態は、２つのノードＢが存在するソフト・ハンドオフに関して本明細書で述べられているが、３以上のノードＢを含むソフト・ハンドオフに対して、本明細書の教示をどのように適用するかは、当業者にとって自明であることも留意されたい。したがって、本発明の趣旨および範囲を、本明細書に含まれる諸実施形態の記述に限定すべきではない。

本発明によるＵＭＴＳ（Universal Mobile Telecommunications System）ベースの無線通信システム、インターネット、およびＶｏＩＰ（Voice over Internet Protocol）電話を示す図である。 本発明のＵＭＴＳベースの無線通信ネットワークによる、ＶｏＩＰ電話とＵＥ（User Equipment）の間のＶｏＩＰコールのために使用されるプロトコル・スタックを示す図である。 本発明による補助チャネルの共用プールを使用し、ダウンリンクＤＣＨ（Dedicated Channel）を介してＶｏＩＰを実施するためのコールセットアップ手順を示す流れ図である。 本発明によるダウンリンクＤＣＨを介する進行中のＶｏＩＰコールを示す図である。 本発明による１組のハンドオフ手順を示す流れ図である。

Claims (10)

1. 無線通信ネットワークでハンドオフを実施する方法であって、
   第１の基地局に関連付けられた第１の主符号、および補助符号の第１の組を移動局に割り当てるステップであり、補助符号の前記第１の組が、前記第１の基地局に関連付けられた共用の補助符号の第１のプールに属しているステップと、
   前記移動局が、閾値を超える信号強度測定値で、第２の基地局から送信された信号を受信した後、前記第２の基地局に関連付けられた第２の主符号、および補助符号の第２の組を前記移動局に割り当てるステップであり、補助符号の前記第２の組が、前記第２の基地局に関連付けられた共用の補助符号の第２のプールに属しているステップと
   を含む方法。
2. 第１および第２の割り当てられる特定の補助符号を前記移動局に割り当てるステップであって、前記第１の割り当てられる特定の補助符号が、補助符号の前記第１の組に属しており、前記第２の割り当てられる特定の補助符号が、補助符号の前記第２の組に属しているステップと、
   前記第１の割り当てられる特定の補助符号の識別を示すために、第１の割り当てられる特定の補助符号インジケータを、第１の主チャネルを介して前記移動局に送信するステップであって、前記第１の主チャネルが、前記第１の主符号で構成されるステップと、
   前記第２の割り当てられる特定の補助符号の識別を示すために、第２の割り当てられる特定の補助符号インジケータを、第２の主チャネルを介して前記移動局に送信するステップであって、前記第２の主チャネルが、前記第２の主符号で構成され、前記第１および第２の割り当てられる特定の補助符号インジケータを同一にすることも、同一にしないことも可能であるステップとをさらに含む、請求項１に記載の方法。
3. パケットの第１の部分を、前記第１の主チャネルを介して、また前記パケットの第２の部分を第１の割り当てられる特定の補助チャネルを介して、前記基地局から送信するステップであって、前記第１の割り当てられる特定の補助チャネルが、前記第１の割り当てられる特定の補助符号で構成されるステップと、
   前記パケットの前記第１の部分を、前記第２の主チャネルを介して、また前記パケットの前記第２の部分を第２の割り当てられる特定の補助チャネルを介して、前記第２の基地局から送信するステップであって、前記第２の割り当てられる特定の補助チャネルが、前記第２の割り当てられる特定の補助符号で構成されるステップとをさらに含む、請求項２に記載の方法。
4. 前記第１および第２の割り当てられる特定の補助符号インジケータを送信する前記ステップの前に、前記第１および第２の割り当てられる特定の補助符号インジケータを、それぞれ、補助符号の前記第１および第２の組に属する第１および第２の割り当てられる特定の補助符号に関連付けるための、第１および第２のマッピング・テーブルを送信するステップをさらに含む、請求項２に記載の方法。
5. 前記第１および第２の割り当てられる特定の補助符号を割り当てる前記ステップの前に、送信すべきパケットが、主チャネルを介して、単一の送信時間間隔にわたり送信することができるかどうか判定するステップをさらに含む、請求項２に記載の方法。
6. 補助符号の前記第１および第２の組が、ハンドオフで使用するために、それぞれ、前記第１および第２の基地局で予約された補助符号のクラスに属している、請求項１に記載の方法。
7. 前記第１の主符号インジケータ、および補助符号の前記第１の組のインジケータを、前記移動局で受信するステップと、
   第２の基地局に関連付けられた信号強度測定値が閾値を超えているという標識を、前記移動局から送信するステップと、
   前記第２の主符号インジケータ、および補助符号の前記第２の組のインジケータを、前記移動局で受信するステップとをさらに含む、請求項１に記載の方法。
8. 無線通信ネットワークでハンドオフを実施する方法であって、
   第１の基地局に関連付けられた第１の主符号インジケータ、および補助符号の第１の組のインジケータを受信するステップであり、前記第１の主符号インジケータおよび補助符号の前記第１の組のインジケータが、それぞれ、第１の主符号および補助符号の第１の組の識別を示しており、補助符号の前記第１の組が、前記第１の基地局に関連付けられた共用の補助符号の第１のプールに属しているステップと、
   第２の基地局に関連付けられた信号強度測定値が閾値を超えているという標識を送信するステップと、
   前記第２の基地局に関連付けられた第２の主符号インジケータ、および補助符号の第２の組のインジケータを受信するステップであり、前記第２の主符号インジケータおよび補助符号の前記第２の組のインジケータが、それぞれ、第２の主符号および補助符号の第２の組の識別を示しており、補助符号の前記第２の組が、前記第２の基地局に関連付けられた共用の補助符号の第２のプールに属しているステップと
   を含む方法。
9. 第１および第２の割り当てられる特定の補助符号の識別を示すための、第１および第２の割り当てられる特定の補助符号インジケータを、第１および第２の主チャネルを介して受信するステップであって、前記第１および第２の割り当てられる特定の補助符号が、補助符号の前記第１および第２の組に属しており、前記第１および第２の主チャネルが、それぞれ、前記第１および第２の主符号を用いて構成されるステップをさらに含む、請求項８に記載の方法。
10. 前記第１および第２の割り当てられる特定の補助符号インジケータを受信する前記ステップの前に、前記第１および第２の割り当てられる特定の補助符号インジケータを、それぞれ、補助符号の前記第１および第２の組に属している第１および第２の割り当てられる特定の補助符号に関連付けるための、第１および第２のマッピング・テーブルを受信するステップをさらに含む、請求項９に記載の方法。

Images