JP5059006B2 - 共用された補助拡散符号を用いてボイスオーバーｉｐを組み込む無線通信ネットワーク - Google Patents

Description

本発明は、一般的にインターネット・プロトコルの適用に関し、詳細には、無線通信システムにおけるボイスオーバー・インターネット・プロトコル（ＶｏＩＰ：Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）に関する。

関連した対象が、同時に出願され、同一の譲受人に譲渡された次の出願、タイトルが「Ｈａｎｄｏｆｆｓ ｉｎ Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｎｅｔｗｏｒｋ Ｉｎｃｏｒｐｏｒａｔｉｎｇ Ｖｏｉｃｅ Ｏｖｅｒ ＩＰ Ｕｓｉｎｇ Ｓｈａｒｅｄ Ｓｕｐｐｌｅｍｅｎｔａｌ Ｓｐｒｅａｄｉｎｇ Ｃｏｄｅｓ」、発明者がＲａｉｎｅｒ Ｂａｃｈｌ、Ｊｅｎｓ Ｍｕｅｃｋｅｎｈｅｉｍ、Ａｎｉｌ ＲａｏおよびＭｉｒｋｏ Ｓｃｈａｃｈｔである米国特許出願第１１／２１３，３８３号（米国特許出願公開第２００７／００４７４８９号）で開示される。

よく知られた第三世代のユニバーサル移動体通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）技法に基づく無線通信ネットワークなどの無線通信ネットワークにボイスオーバー・インターネット・プロトコル（ＶｏＩＰ）サービスを組み込むことは、コア・ネットワーク設計を簡単にし、従来の回線交換（ＣＳ：ｃｉｒｃｕｉｔ ｓｗｉｔｃｈ）の音声と比べて新しく有用なサービスを追加する。しかし、ＶｏＩＰはまた、本質的に大きなヘッダーおよびシグナリングの形で追加のオーバーヘッドを加え、したがってシステム容量を減少させる。

図１は、従来技法によるＵＭＴＳベースの無線通信システム１００、インターネット１０５およびＶｏＩＰ電話１１０を示す。無線通信システム１００は、少なくともコア・ネットワーク１３０、無線アクセス・ネットワーク（ＲＡＮ：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１６０、および移動機（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）または移動局１４０を含む。コア・ネットワーク１３０は、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ：Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）１２０、サービングＧＰＲＳサポート・ノード（ＳＧＳＮ：Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）１２５、および移動交換局（ＭＳＣ：Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ）１５０を含む。ＧＧＳＮ１２０は、インターネット１０５とコア・ネットワーク１３０の間のインターフェースであり、ＳＧＳＮ１２５は、コア・ネットワーク１３０とＲＡＮ１６０の間のインターフェースである。無線アクセス・ネットワーク（ＲＡＮ）１６０は、１つまたは複数の無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）１７０および１つまたは複数のＮｏｄｅ Ｂ（または基地局）１８０を含む。

図２は、従来技法のＵＭＴＳベースの無線通信ネットワーク１００による、ＶｏＩＰ電話１１０とＵＥ１４０の間のＶｏＩＰ通話に用いられるプロトコル・スタック２００を示す。ＶｏＩＰ通話は、ＵＭＴＳベースの無線通信システム１００のＰＳドメインで処理されている。いくつかのシステム配置では、ＶｏＩＰ電話１１０は、公衆交換電話網（ＰＳＴＮ：Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）通話をＶｏＩＰ通話に変換する電子装置であってよい。他の配置では、ＰＳＴＮまたは無線通信ネットワークは、ＰＳＴＮ通話をＶｏＩＰ通話に変換する相互動作機能（ＩＷＦ：Ｉｎｔｅｒ−Ｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ）またはメディア・ゲートウェイ（ＭＧＷ：Ｍｅｄｉａ ＧａｔｅＷａｙ）を有してよい。図２に示すように、プロトコル・スタック２００は、適応マルチレート（ＡＭＲ：Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ−Ｒａｔｅ）層２０５、リアル・タイム・プロトコル（ＲＴＰ：Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）層２１０、ユーザ・データグラム・プロトコル／インターネット・プロトコル６版またはインターネット・プロトコルの他の版、例えば４版（ＵＤＰ／ＩＰｖ６）層２１５、パケット・データ収斂プロトコル（ＰＤＣＰ：Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）層２２０、無線リンク制御（ＲＬＣ：Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）層２２５、専用メディア・アクセス制御（ＭＡＣ−ｄ：ｄｅｄｉｃａｔｅｄ Ｍｅｄｉｕｍ Ａｃｃｏｃｓ Ｃｏｎｔｒｏｌ）層２３０および物理（ＰＨＹ：ＰＨＹｓｉｃａｌ）層２３５を含む。ＡＭＲ層２０５、ＲＴＰ層２１０およびＵＤＰ／ＩＰｖ６層２１５はＶｏＩＰ電話１１０で実装されている。ＰＤＣＰ層２２０、ＲＬＣ層２２５およびＭａｃ−ｄ層２３０はＲＮＣ１７０で実装されている。また、ＰＨＹ層２３５はＮｏｄｅ Ｂ１８０で実装されている。ＵＤＰ／ＩＰｖ６層２１５は単一層として示されているが、その実際の実装は、おそらく２つの別のＵＤＰ層およびＩＰｖ６層として存在することに留意されたい。

説明のために、音声情報がＶｏＩＰ電話１１０からＵＥ１４０に送信されていると仮定する。ＶｏＩＰ電話１１０で、音声はＡＭＲ層２０５で（ＡＭＲコーデックを介して）符号化され、それにより１５９音声ビットを有する音声フレームを生成する。ＲＴＰ層２１０で、ＲＴＰペイロードは、１つまたは複数の音声フレームにＲＴＰペイロード内の各音声フレームに対して４ビットのコーデック・モード要求（ＣＭＲ：Ｃｏｄｅｃ Ｍｏｄｅ Ｒｅｑｕｅｓｔ）フィールドおよび６ビットの目次（ＴＯＣ：Ｔａｂｌｅ Ｏｆ Ｃｏｎｔｅｎｔｓ）フィールド、ならびにオクテットの位置合わせのためのパディング・ビットを加えることにより形成される。１５９音声ビットを用いるＡＭＲ７．９５ｋｂｐｓコーデックでは、ＲＴＰペイロードに７パディング・ビットが加えられる。ＲＴＰパケットは、ＲＴＰシーケンス番号、タイム・スタンプ、ＭフィールドおよびＸフィールド、同期化ソース同一性等などの情報を搬送するために１２バイトのＲＴＰヘッダーをＲＴＰペイロードに加えることにより形成される。

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

ＵＤＰ／ＩＰｖ６パケットは、ＶｏＩＰ電話１１０からインターネット１０５を通ってＧＧＳＮ１２０へ送信される。ＧＧＳＮ１２０から、ＵＤＰ／ＩＰｖ６パケットは、ＳＧＳＮ１２５に転送され次にＲＡＮ１６０に転送される。幸運にも、一度ＵＤＰ／ＩＰｖ６パケットがＲＡＮ１６０に届くと、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーで搬送される情報の多くが静的であるため、完全なＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーを各音声パケットに対してエア・インターフェースを介して送信する必要はもはやない。目的の受信側、例えばＵＥ１４０が、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダー内の静的な情報のすべてを得た後、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーは、ＰＤＣＰ層２２０でロバスト・ヘッダー圧縮（ＲｏＲＣ：Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）を用いて圧縮でき、それによりＲＴＰペイロードおよび圧縮されたヘッダーを含むＰＤＣＰパケットを形成する。圧縮されたヘッダーは、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーにＲＴＰシーケンス番号、タイム・スタンプ、ＭフィールドおよびＸフィールド、ならびにＵＤＰチェックサムなどの動的な情報を含んでいる。多くの場合、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーは、３バイトに圧縮可能である。具体的には、ＲＴＰヘッダーはシーケンス番号の６最下位ビット（ＬＳＢ：ｌｅａｓｔ ｓｉｇｎｉｆｉｃａｎｔ ｂｉｔ）を示す１バイトに圧縮可能である。ＵＤＰヘッダーは、ＵＤＰチェックサムに対応する２バイトに圧縮可能である。他の場合、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダー内のあまり動的でない情報のいくつかは、例えば再同期化の間または会話区間の開始時に受信側で更新される必要があるため、圧縮されたヘッダーは３バイトに圧縮できない。後者の場合、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーは全然圧縮されない可能性があることに留意されたい。ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーが圧縮されないと、ＰＤＣＰパケットはＲＴＰペイロードおよび圧縮されていないＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーから成り立つことになる。

ＲＬＣ層２２５で、１バイトのＲＬＣ ＵＭヘッダーがＰＤＣＰパケットに加えられ、それによりＲＬＣパケットを生成し、ＲＬＣ ＵＭヘッダーはＲＬＣシーケンス番号を含む。その後ＲＬＣパケットは、Ｎｏｄｅ Ｂを介してＵＥ１４０にエア・インターフェースで送信される前にＭＡＣ−ｄ層２３０およびＰＨＹ層２３５で処理される。

６０バイトのＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーが多くの場合３バイトに縮小可能であるが、専用チャネル（ＤＣＨ）が現在ＤＣＨ上のピーク・データ速度に適合するのに十分な直交可変拡散率（ＯＶＳＦ：Ｏｒｔｈｏｇｏｎａｌ Ｖａｒｉａｂｌｅ Ｓｐｒｅａｄｉｎｇ Ｆａｃｔｏｒ）符号を用いて構成されているため、ダウンリンクＤＣＨを介するＶｏＩＰの現在の実装は圧縮から利益を得ていない。例えば、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダー圧縮が最適であると、すなわちヘッダーが３バイトに縮小されると、１２８の拡散率（ＳＦ：Ｓｐｒｅａｄｉｎｇ Ｆａｃｔｏｒ）を持つＯＶＳＦ符号はダウンリンクＤＣＨのトラフィックに適合するのに十分である。しかし、通話設定または再同期化の間など、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダー圧縮が最適でないと、１２８より小さいＳＦを持つＯＶＳＦ符号が必要とされる。ＶｏＩＰの現在の方法は、最適でないＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダー圧縮に関連付けられるデータ速度に適合するために、おそらく１２８より小さいＳＦを持つＯＶＳＦ符号を用いる必要がある。無線通信ネットワーク分野でよく知られるように、より高いＳＦで構成される通信チャネルはシステム・リソース、例えば帯域幅のより効率的な使用およびシステム容量の増加をもたらす。

３９．２ｋｂｐｓのデータ速度がダウンリンクＤＣＨ上でのＶｏＩＰのための適切なピーク・データ速度であると推奨されている。このデータ速度を達成するために、６４のＳＦを持つＯＶＳＦ符号がチャネル構成に必要とされる。一方、従来のＣＳ音声では、１２８のＳＦを持つＯＶＳＦ符号がＤＣＨ上のピーク・データ速度に適合するのに十分である。６４のＯＶＳＦ符号（すなわち、６４のＳＦを持つＯＶＳＦ符号）を用いて構成される１つのチャネルをサポートするために用いられるリソースが、１２８のＯＶＳＦ符号群（すなわち、６４のＳＦを持つＯＶＳＦ符号）を用いて構成される２つのチャネルをサポートするために用いられるリソースと等しい。したがって、ダウンリンクＤＣＨ上のＶｏＩＰは、帯域幅割り当ての観点から従来のＣＳ音声に比べて５０％までシステム容量を減少させる可能性がある。

ヘッダーを介して加えられるオーバーヘッドに加えて、ＶｏＩＰに関連付けられるシグナリングも付加される。ＶｏＩＰは、リアルタイム制御プロトコル（ＲＴＣＰ：Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）およびセッション確立プロトコル（ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などの追加のシグナリングを必要とする。この追加のシグナリングは、４つの送信チャネル（音声フレームが送信されるダウンリンクＤＣＨを含む）までの多重化をもたらすことができ、これらの送信チャネルは、シグナリング無線ベアラ（ＳＲＢ：Ｓｉｇｎａｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ）のための第１の送信チャネル、音声を搬送するための第２の送信チャネル、すなわちＤＣＨ、ＲＴＣＰのための第３の送信チャネル、およびＳＩＰのための第４の送信チャネルである。これらのチャネルのそれぞれは複数のデータ速度に関連付けられる。ＳＲＢは０および３．４ｋｂｐｓのデータ速度に関連付けられている。音声は０、１６および３９．２ｋｂｐｓのデータ速度に関連付けられている（３９．２ｋｂｐｓのデータ速度は圧縮されていないＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーを持つパケットに対応する）。そしてＲＴＣＰおよびＳＩＰは０、８および１６ｋｂｐｓのデータ速度に関連付けられている。これらのチャネルのそれぞれの動作がかなりのデータ速度のばらつきにつながる可能性がある。送信チャネルがすべてそれらの関連付けられた最大データ速度を同時に必要とすることは起こりそうにないとすると、送信チャネルを最大データ速度に適合するのに十分なＯＶＳＦ符号を用いて構成することは、システム・リソースを非効率に使用することになる。したがって、ダウンリンクＤＣＨを介してＶｏＩＰを実装することに関連するシステム・リソースへの悪影響を最小化する必要が存在する。

本発明は、より高い拡散率（ＳＦ）に関連付けられる直交可変拡散率（ＯＶＳＦ）符号が使用可能であるような無線通信ネットワークにおいてボイスオーバー・インターネット・プロトコル（ＶｏＩＰ）パケットを主チャネルおよび補助チャネル群の共用プールに属する主チャネルおよび補助チャネルを介して送信し、それによりダウンリンク専用チャネル（ＤＣＨ）を介してＶｏＩＰを実装することに関連するシステム・リソースへの悪影響を最小化する方法およびそのシステムである。ＶｏＩＰパケットは、音声ビットを有し、ＶｏＩＰ技法によって処理されるパケットであり、主および補助チャネルは専用物理データ・チャネルを有している。本発明では、ＶｏＩＰパケットの全体が単一の送信時間間隔の間に主チャネル上で送信できない場合、特定の補助チャネル（またはそれに関連付けられる符号）が、そのＶｏＩＰパケットが目的とする移動機（ＵＥ）に割り当てられる。ＶｏＩＰパケットの一部が、そのＵＥに主チャネル上の専用物理データ・チャネル（ＤＰＤＣＨ）を介して送信され、ＶｏＩＰパケットの他の部分が、そのＵＥに補助チャネル上のＤＰＤＣＨを介して送信される。ＵＥは、主チャネル上のＤＰＣＣＨを調べ、それにより特定の補助チャネル（またはそれに関連付けられる符号）がＵＥに割り当てられているかを判定する。特定の補助チャネル（または符号）が割り当てられた場合、ＵＥは、割り当てられた特定の補助チャネル上のデータをその主チャネル上のデータと共に復号する。それ以外の場合、ＵＥはその主チャネル上のデータのみを復号する。

一実施形態では、割り当てられた特定の補助チャネル（またはそれに関連付けられる符号）は、そのＵＥに割り当てられた補助チャネルのセットに属し、割り当てられた補助チャネルのセットは、Ｎｏｄｅ Ｂの補助チャネル（または符号）の共用プールに属する。割り当てられた特定の補助チャネル（または符号）の同一性は、そのＵＥに主チャネル上の専用物理制御チャネル（ＤＰＣＣＨ）を介して指示される。好ましい実施形態では、主および補助チャネルの両方は、同一の拡散率（ＳＦ）、例えば１２８を持つ直交可変拡散率（ＯＶＳＦ）符号を用いて構成される。

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

本発明は、例えば、専用チャネル（ＤＣＨ）上の単一の送信時間間隔の間でＶｏＩＰパケット全体が送信できない場合、ＶｏＩＰパケットの一部を送信するために、補助チャネル群の共用プールを用いダウンリンクＤＣＨを介してボイスオーバー・インターネット・プロトコル（ＶｏＩＰ）サービスを配信するシステムおよび方法である。本発明は、よく知られたユニバーサル移動体通信システム（ＵＭＴＳ）規格に準拠して実装された無線通信ネットワークを参照して本明細書で説明されている。本発明は、他の多元接続技法を実装する無線通信ネットワークに、同様に適用可能であることを理解されたい。さらに、この出願で用いられる用語「補助チャネル」は、ＵＭＴＳのマルチコード概念で用いられる第２の専用物理データ・チャネル（ＤＰＤＣＨ）、またはなんらかの他の多元接続技法のなんらかの同等の通信チャネルを指し、ＶｏＩＰパケットという用語は、音声ビットを有しＶｏＩＰ技法により処理されるパケットを指すことに留意されたい。

図３は、本発明によるＵＭＴＳベースの無線通信システム３００を示す。無線通信システム３００は、少なくともコア・ネットワーク１３０、無線アクセス・ネットワーク（ＲＡＮ）１６０、および移動機（ＵＥ）または移動局１４０を含む。コア・ネットワーク１３０は、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）１２０、サービングＧＰＲＳサポート・ノード（ＳＧＳＮ）１２５、および移動交換局（ＭＳＣ）１５０を含む。ＧＧＳＮ１２０は、インターネット１０５とコア・ネットワーク１３０の間のインターフェースであり、ＳＧＳＮ１２５は、コア・ネットワーク１３０とＲＡＮ１６０の間のインターフェースである。無線アクセス・ネットワーク（ＲＡＮ）１６０は、１つまたは複数の無線ネットワーク制御装置（ＲＮＣ）１７０および１つまたは複数のＮｏｄｅ Ｂ（または基地局）１８０を含む。ＲＮＣ１７０は、無線リソース制御（ＲＲＣ：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）１７５を含む。無線リソースを管理する機能を有するＲＲＣ１７５は、コード・マネジャー（ＣＭ：Ｃｏｄｅ Ｍａｎａｇｅｒ）１８５を含んでいる。ＣＭ１８５は、ＲＮＣ１７０に接続された各Ｎｏｄｅ Ｂ１８０のための直交可変拡散率（ＯＶＳＦ）符号を管理する機能を含む。

Ｎｏｄｅ ＢとＵＥ１４０の間の通信チャネルは、多数の直交可変拡散率（ＯＶＳＦ）符号を用いて構成される。ＶｏＩＰ通話に対して、ＣＭ１８５は、ダウンリンク専用チャネル（ＤＣＨ）を構成するためにＯＶＳＦ符号をＵＥ１４０に割り当てる。また、ＤＣＨを構成するために用いられているＤＣＨおよびＯＶＳＦ符号は、本明細書でそれぞれ「主チャネル」および「主ＯＶＳＦ符号」として参照される。ＵＭＴＳでは、ＤＣＨは、専用物理データ・チャネル（ＤＰＤＣＨ）および専用物理制御チャネル（ＤＰＣＣＨ）を含む。

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

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

ＵＥ１４０に割り当てられたＮ個の補助ＯＶＳＦ符号のセットはＭ個の補助ＯＶＳＦ符号のセットから選択され、ＭはＮより大きいかまたは等しい。Ｍ個の補助ＯＶＳＦ符号のセットは、Ｎｏｄｅ Ｂ１８０でＣＭ１８５により確保されたＯＶＳＦ符号のセットであり、Ｎｏｄｅ Ｂ１８０で補助チャネル（またはＯＶＳＦ符号）の共用プールに関連付けられている。ＵＥ間で共用されるＯＶＳＦ符号のプールから補助ＯＶＳＦ符号を用いることは、本発明の基本概念の１つである。本発明によると、各Ｎｏｄｅ Ｂに対してＣＭ１８５により確保されたＭ個の補助ＯＶＳＦ符号のセットが存在することに留意されたい。１つのＮｏｄｅ Ｂで確保された補助ＯＶＳＦ符号は、他のＮｏｄｅ Ｂで確保された、いくつかの、すべての、または０個の補助ＯＶＳＦ符号を含んでよい。好ましい実施形態では、パラメータＭは、必要以上の補助ＯＶＳＦ符号の確保を最小化することと、Ｍより多い補助ＯＶＳＦ符号が同時に必要とされる可能性があることとの間でバランスをとるように選択されるべきである。パラメータＭは固定であってよく、または負荷、補助ＯＶＳＦ符号の用い方等などのシステム・メトリクスにより動的に決定されてよい。パラメータＮは、転送フォーマット組み合わせセット（ＴＦＣＳ：Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｃｏｍｂｉｎａｔｉｏｎ Ｓｅｔ）を適当な大きさに保つこと、ＵＥの複雑さを制限すること、およびＵＥの機能などの様々な要因に基づき選択されるべきである。一実施形態では、パラメータＮは、３８４ｋｂｐｓ、７６８ｋｂｐｓおよび２０４８ｋｂｐｓのデータ速度が可能であるマルチコードＵＥに対して３に等しく設定される。

図４は、本発明による、補助チャネルの共用プールを用いてダウンリンクＤＣＨを介してボイスオーバー・インターネット・プロトコル（ＶｏＩＰ）サービスを実装する通話設定の手続きを示す流れ図４００を示す。ステップ４０５で、ＶｏＩＰサービスがＵＥ１４０に対して要求されている。ステップ４１０で、ＲＲＣ１７５は補助ＯＶＳＦ符号がＵＥ１４０の機能に基づきＵＥ１４０に割り当てられるべきかを決定する。基本的に、ＵＥ１４０がマルチコードＵＥである場合、ＲＲＣ１７５は、補助ＯＶＳＦ符号がＵＥ１４０に割り当てられると決定する。補助ＯＶＳＦ符号がＵＥ１４０に割り当てられないと決定された場合、ステップ４２０でＲＲＣ１７５はパラメータＮの値を決定せず、ＣＭ１８５はいかなる補助ＯＶＳＦ符号もＵＥ１４０に割り当てない。ステップ４２０から、流れ図４００はステップ４２５に進み、このステップでＣＭ１８５は主ＯＶＳＦ符号をＵＥ１４０に割り当てる。

一方、補助ＯＶＳＦ符号がＵＥ１４０に割り当てられるべき場合、ステップ４１５でＲＲＣ１７５はパラメータＮの値を決定し、ＣＭ１８５はＮ個の補助ＯＶＳＦ符号をＵＥ１４０に割り当てる。Ｎ個の補助ＯＶＳＦ符号はＭ個の補助ＯＶＳＦ符号のセットから選択されている。ステップ４１５から、流れ図４００はステップ４２５に続き、このステップでＣＭ１８５は主ＯＶＳＦ符号をＵＥ１４０に割り当てる。ステップ４３５で、ＲＮＣ１７０はＮｏｄｅ Ｂ１８０を介して割り当てられた主ＯＶＳＦ符号の同一性、および該当する場合、Ｎ個の補助ＯＶＳＦ符号の同一性をＵＥ１４０に専用制御チャネル（ＤＣＣＨ：Ｄｅｄｉｃａｔｅｄ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）で伝える。ステップ４４０で、ＵＥ１４０は主ＯＶＳＦ符号および補助ＯＶＳＦ符号（該当する場合）の同一性を受信する。次にＵＥ１４０は、主ＯＶＳＦ符号および補助ＯＶＳＦ符号で構成される主チャネルおよび補助チャネル、すなわち複数のＤＰＤＣＨを介して受信されるデータの格納を開始する。ＵＥ１４０は、主チャネルのデータを復号する。ＵＥ１４０がマルチコードＵＥであり、補助ＯＶＳＦ符号を割り当てられた場合、ＵＥ１４０は、本明細書で説明されるように特定の補助チャネルを復号するためのある種の指示を受信しなければ、いかなる関連した補助チャネルのデータも復号しない。

通話設定が完了した後、ＵＥはＶｏＩＰ通話を受信する用意ができる。図５は、本発明による、ダウンリンクＤＣＨを介する通話中のＶｏＩＰ通話を示す流れ図５００を示す。ステップ５４０で、ＲＮＣ１７０はＲＡＮ１６０からパケットを受信し、補助チャネルがＵＥ１４０へのパケットの送信のために主チャネルに加えて用いられるべきかを決定する。基本的に、パケットが、音声と圧縮されたＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーとＳＲＢ、ＳＩＰとＳＲＢ、またはＲＴＣＰとＳＲＢの組み合わせのうちの１つを含む場合、補助チャネルが用いられるべきではない。パケットが、音声と圧縮されていないＲＴＰ／ＵＤＰ／ＩＰｖ６とＳＲＢ、または音声と圧縮されたＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダーとＳＲＢとＳＩＰの組み合わせのうちの１つを含む場合、補助チャネルが用いられるべきである。一実施形態では、補助チャネルが用いられるべきかの決定は、パケットの大きさに基づく。より詳細には、パケットがＤＣＨを介して単一の送信時間間隔（ＴＴＩ）、例えば２０ｍｓで送信できない場合、補助チャネルが用いられるべきである。補助チャネルがパケット送信に用いられるべきでないと決定される場合、流れ図５００はステップ５６５に続く。

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

一方、補助チャネルをＵＥ１４０に割り当てることが実行可能であると決定される場合、流れ図５００はステップ５５５に続き、このステップでＣＭ１８５は、Ｎ個の補助ＯＶＳＦ符号の割り当てられたセットから特定の補助ＯＶＳＦ符号を割り当てる。特定の補助ＯＶＳＦ符号を割り当てると、ステップ５６０でＲＮＣ１７０は、Ｎｏｄｅ Ｂを介して（後のプロトコル層でさらに処理された後に）パケットの一部、および割り当てられた特定の補助ＯＶＳＦ符号の同一性（あるいは補助ＯＶＳＦ符号またはそれに関連付けられた補助チャネルの指示）をそれぞれ主チャネルのＤＰＤＣＨおよびＤＰＣＣＨを介して送信し、（後のプロトコル層でさらに処理された後に）パケットの他の部分を特定の補助ＯＶＳＦ符号で構成された補助チャネルのＤＰＤＣＨを介して送信する。割り当てられた特定の補助ＯＶＳＦ符号の同一性、およびパケットの２つの部分は同時に送信されることが好ましい。他の実施形態では、割り当てられた特定の補助ＯＶＳＦ符号の同一性は、パケットの２つの部分より早く送信されても遅く送信されてもよい。

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

流れ図５００は、ステップ５６５に続く。ステップ５６５で、ＵＥ１４０がマルチコードＵＥであると仮定すると、ＵＥ１４０は主チャネルのＤＰＣＣＨ上の制御情報を復号し、それにより（Ｎ個の補助ＯＶＳＦ符号のセットからの）補助ＯＶＳＦ符号の１つがＵＥ１４０に割り当てられているかを判定する。一実施形態では、補助ＯＶＳＦ符号の同一性が制御情報内に示されている場合、ＵＥ１４０は制御情報内に示される補助ＯＶＳＦ符号がＵＥ１４０に割り当てられていると判定する。その他の場合、ＵＥ１４０は補助ＯＶＳＦ符号がＵＥ１４０に割り当てられていないと判定する。

ＵＥ１４０は常に主チャネルのＤＰＤＣＨ上のデータを復号することを留意されたい。制御情報が、データを送信するために用いられている特定の補助ＯＶＳＦ符号（または補助チャネル）の同一性を示す場合、ＵＥ１４０は識別された補助チャネルのＤＰＤＣＨ上のデータも復号し、それ以外の補助チャネル上のデータを破棄する。制御情報が、データが主チャネル上にのみ存在することを示す場合、ＵＥ１４０はすべての補助チャネル上のデータを破棄する。

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

ＶｏＩＰ通話が通話中であるとき、ＵＥ１４０は、あるＲＮＣに関連付けられるＮｏｄｅ Ｂ（本明細書で「現在使用中のＮｏｄｅ Ｂ」としても参照される）のカバレージエリアから他のＲＮＣに関連付けられるＮｏｄｅ Ｂ１８０（本明細書で「新しいＮｏｄｅ Ｂ」としても参照される）のカバレージエリアに移動する可能性がある。前者のＲＮＣは本明細書で「サービングＲＮＣ（ｓｅｒｖｉｎｇ ＲＮＣ）」または「Ｓ−ＲＮＣ」として参照され、後者のＲＮＣは本明細書で「ドリフティングＲＮＣ（ｄｒｉｆｔｉｎｇ ＲＮＣ）」または「Ｄ−ＲＮＣ」として参照される。この状態で、ソフト・ハンドオフが用いられる場合、いくつかの問題が発生する可能性がある。第１の問題は、２つの異なるＲＮＣが今やＮｏｄｅ Ｂのリソースに対する制御を行うことになるということである。第２の問題は、本明細書でＳ−ＲＮＣとＤ−ＲＮＣの間の「Ｉｕｒ」接続として参照される接続を介する符号状態情報の高速シグナリングには限定された選択肢しかないということである。

これらの問題に対処するいくつかの選択肢は次のものである。第１の選択肢は、現在使用中のＮｏｄｅ Ｂから新しいＮｏｄｅ ＢへのＵＥ１４０のソフト・ハンドオフを回避するというものである。ＵＥ１４０は、新しいＮｏｄｅ Ｂとの無線リンク品質が良くなるまで現在使用中のＮｏｄｅ Ｂとの無線リンクを維持する。このような状態になると、ハード・ハンドオフが現在使用中のＮｏｄｅ Ｂから新しいＮｏｄｅ Ｂへ行われる。第２の選択肢は、サービング無線ネットワーク・サブシステム（ＳＲＮＳ：Ｓｅｒｖｉｎｇ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｓｕｂｓｙｓｔｅｍ）再配置を実行することである。ＳＲＮＳ再配置では、Ｓ−ＲＮＣとコア・ネットワークの間の接続（今後、「Ｉｕ接続」と呼ぶ）は、Ｄ−ＲＮＣに再配置される。この第２の選択肢は、第１の選択肢と組み合わせて、すなわちＳＲＮＳ再配置と組み合わせたハード・ハンドオフを行うことができる。

第３の選択肢は、ＵＥ１４０を主ＯＶＳＦ符号に制限すること要する。この選択肢では、補助ＯＶＳＦ符号の割り当てはもはや実行できず、例えば補助チャネルに対する要求を引き起こす状況など、状況が補助ＯＶＳＦ符号の割り当てを必要とする場合、フレーム・スティーリングなどの技法が実行される。最後の選択肢は、固定の補助ＯＶＳＦ符号をＵＥ１４０に割り当てることを要する。

本発明がある実施形態に関してかなり詳細に説明されてきたが、他の種類も可能である。例えば、流れ図４００および５００のステップの順序は異なってよい。ＡＭＲ以外のコーデックが用いられてよい。ＶｏＩＰ以外のデータ・アプリケーションが用いられてよい。したがって、本発明の精神と範囲は、本明細書に含まれる実施形態の説明に限定されるべきではない。

従来技法による、ユニバーサル移動体通信システム（ＵＭＴＳ）ベースの無線通信システム、インターネット、およびボイスオーバー・インターネット・プロトコル（ＶｏＩＰ）電話を示す図である。 従来技法のＵＭＴＳベースの無線通信ネットワークによるＶｏＩＰ電話と移動機（ＵＥ）の間のＶｏＩＰ通話に用いられるプロトコル・スタックを示す図である。 本発明によるＵＭＴＳベースの無線通信システムを示す図である。 本発明による、補助チャネルの共用プールを用いダウンリンク専用チャネル（ＤＣＨ）を介してＶｏＩＰサービスを実装する通話設定の手続きを示す流れ図である。 本発明による、ダウンリンクＤＣＨを介して通話中のＶｏＩＰ通話を示す流れ図である。

Claims (9)

1. 無線通信ネットワークにおいてパケットを主チャネル及び補助チャネルを介して受信器にパケットを送信する方法であって、
   制御チャネルを介して、主符号の指示と該受信器に割り当てられたＮ個の補助符号のセットの指示を無線ネットワーク・ノードから送信するステップと、
   パケットが補助チャネルを介して送信されるべきかを無線ネットワーク・ノードにおいて決定するステップと、
   該パケットが該補助チャネルを介して送信されるべきである場合、該主チャネル上の同一且つ単一のパケット送信時間間隔を介して該パケットの第１の部分及び１つの補助チャネル・インジケータを送信し、該１つの補助チャネル・インジケータに対応する１つの補助チャネル上の該同一且つ単一のパケット送信時間間隔を介して該パケットの第２の部分を送信するステップであって、該１つの補助チャネルは、該受信器に割り当てられたＮ個の補助符号のセットに属する割り当てられた特定の補助符号を用いて構成されるステップと、
   該パケットが補助チャネルを介して送信されるべきでない場合、該主チャネルを介して該パケットを送信するステップとを含む方法。
2. 請求項１に記載の方法において、
   該パケットの該第１及び第２の部分ならびに該補助チャネル・インジケータを該主及び補助チャネルを介して送信する該ステップに先立って、
   Ｎ個の補助符号の該セットを該受信器にＭ個の補助符号のセットのサブセットとして割り当て、Ｍ個の補助符号の該セットは送信側で確保され動的に複数の受信側の間で共用される方法。
3. 請求項１に記載の方法において、
   該パケットの該第１及び第２の部分は、専用物理データ・チャネル（ＤＰＤＣＨ：Ｄｅｄｉｃａｔｅｄ Ｐｈｙｓｉｃａｌ Ｄａｔａ ＣＨａｎｎｅｌ）を介して該主及び補助チャネル上を送信され、該補助チャネル・インジケータは、専用物理制御チャネル（ＤＰＣＣＨ：Ｄｅｄｉｃａｔｅｄ Ｐｈｙｓｉｃａｌ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ）を介して該主チャネル上を送信される方法。
4. 請求項３に記載の方法において、
   該補助チャネル・インジケータは、転送フォーマット組み合わせインデックス（ＴＦＣＩ：Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｃｏｍｂｉｎａｔｉｏｎ Ｉｎｄｅｘ）の一部として該ＤＰＣＣＨ上を送信される方法。
5. 請求項１に記載の方法において、
   追加のステップとして、
   サービングＲＮＣに関連付けられる第１のＮｏｄｅ Ｂの第１のカバレージエリアからドリフティングＲＮＣに関連付けられる第２のＮｏｄｅ Ｂの第２のカバレージエリアに該受信器が移動しているとき、
   該受信器のハード・ハンドオフを該第１のＮｏｄｅ Ｂから該第２のＮｏｄｅ Ｂに実行するステップ、又は
   該受信器を該主チャネルのみに制限するステップ、又は
   固定の補助チャネルを該受信器に割り当てるステップを含む方法。
6. 請求項１に記載の方法において、
   追加のステップとして、
   該補助チャネルを示す該主チャネル上の補助チャネル・インジケータが存在する場合、該受信器で該主及び補助チャネル上を送信される該パケットの該第１及び第２の部分を復号するステップと、
   該主チャネル上に補助チャネル・インジケータが存在しない場合、該受信器で該主チャネル上を送信される該パケットのみを復号するステップとを含む方法。
7. 無線通信ネットワークのエア・インターフェースを介して送信されるデータを受信する方法であって、
   制御チャネルを介して、主チャネルの指示とＮ個の補助チャネルのセットの指示とを受信器で受信するステップと、
   主チャネル及びＮ個の補助チャネルのセットのサブセットを介して送信されるデータを該受信器で受信するステップであって、該主チャネルは主符号を用いて構成され、Ｎ個の補助チャネルの該セットのサブセットはＮ個の補助符号のセットのサブセットを用いて構成されるステップと、
   該主チャネル上で同一且つ単一のパケット受信時間間隔を介して該受信器で受信される該データを復号するステップと、
   該主チャネル上の該同一且つ単一のパケット受信時間間隔を介して受信される１つの補助チャネル・インジケータが１つの特定の補助チャネルを示す場合、該１つの特定の補助チャネル上で受信される該データを復号するステップであって、該１つの特定の補助チャネルはＮ個の補助チャネルの該セットのサブセットに属するステップと、
   補助チャネル・インジケータが該主チャネル上の該同一且つ単一のパケット受信時間間隔を介して受信されなかった場合、任意のＮ個の補助チャネルの該セットのサブセット上で受信される任意の該データを復号しないステップとを含む方法。
8. 請求項７に記載の方法において、
   追加のステップとして、
   該データを受信する該ステップに先立ち、該主チャネル及びＮ個の補助チャネルの該セットの指示を制御チャネル上で受信するステップとを含む方法。
9. 無線通信ネットワークであって、
   主符号及びＮ個の補助符号のセットを受信器に割り当て、１つの特定の補助符号を該Ｎ個の補助符号の該セットから割り当てる無線ネットワーク制御装置と、
   同一且つ単一のパケット送信時間間隔を介して、パケット及び割り当てられた主チャネルの指示と少なくとも１つの補助チャネルの指示を該受信器に送信する基地局とを備え、
   該受信器が、対応する同一且つ単一のパケット受信時間間隔の間に同時に該主チャネル及び補助チャネルをサポートできる場合、該パケットの第１の部分及び１つの補助チャネル・インジケータは、該割り当てられた主符号を用いて構成される主チャネル上の該同一且つ単一のパケット送信時間間隔を介して送信され、該パケット第２の部分は、該１つの補助チャネル・インジケータに対応する１つの補助チャネル上の該同一且つ単一のパケット送信時間間隔を介して送信され、該補助チャネルは、該割り当てられた１つの特定の補助符号を使用して構成され、
   該受信器が同時に該主チャネル及び補助チャネルをサポートできない場合、該パケットは、該割り当てられた主符号を用いて構成される該主チャネルを介してフレーム・スティーリング技法を用い送信される無線通信ネットワーク。

Images