JP2006522518A - 異なる種類のデータを含むインターネットデータパケットを通信する無線電気通信装置及び方法 - Google Patents

Abstract

電気通信システムは、移動体であるユーザ機器に／から複数の異なる種類のデータを搬送するインターネットデータパケットを通信する。システムは、ゲートウェイサポートノード（ＧＧＳＮ）（３００）と、サービスサポートノード（ＳＧＳＮ）（３０６）と、無線ネットワークコントローラ（ＲＮＣ）（３１４）とを含む。移動体であるユーザ機器（ＵＥ）は、サービスサポートノード（ＳＧＳＮ）にメインのサービス品質パラメータと、サービス品質パラメータの異なる組の要求を表す他の少なくとも１つのデータフィールドとを特定するコンテキストアプリケーション要求を供給する。各サービス品質パラメータは、データパケット内のデータの異なる種類の１つに対応する。サービスサポートノード（ＳＧＳＮ）は、コンテキストアプリケーション要求に応答して、サービスサポートノード（ＳＧＳＮ）を介して、ゲートウェイサポートノード（ＧＧＳＮ）とユーザ機器の間で、各複数のサービス品質パラメータに基づき、異なるデータタイプを通信するための無線アクセスベアラを含む仮想チャンネルを確立する。この結果、通信するデータの種類に無線アクセスベアラを対応させることができるため、無線リソースをより効率的に利用できる。

Description

本発明は、モバイル通信ユーザ機器へ／からインターネットデータパケットを通信するための機能を提供する電気通信システムに関連する。

例えば、モバイル機器のためのグローバルシステム（Global System for Mobiles：以下、ＧＳＭという。）及びユニバーサルモバイル電気通信システム（Universal Mobile Telecommunications System：以下、ＵＭＴＳという。）等の移動体無線ネットワークは、回線交換モード又はパケット交換モードでデータを通信するための機能を提供できる。回線交換モードでは、呼の全体に亘る論理的な通信チャンネルに、物理的な通信チャンネルを割り当てる。一方、データパケット通信については、汎用パケット無線サービス（General Packet Radio Service：以下、ＧＰＲＳという。）が開発されている。ＧＰＲＳは、例えば、インターネットパケット（ＩＰ）等のデータパケット通信のためにネットワーク及び無線リソースを最適化することを試みるパケット指向サービスをサポートする。ＧＰＲＳは、モバイル無線システムの回線交換アーキテクチャに関連する論理的なアーキテクチャを提供する。

モバイル通信のユーザ機器（user equipment：以下、ＵＥという。）と、データパケット通信ネットワークとの間でデータを通信するためのシステムは、移動通信ネットワークを介して、データパケット通信ネットワーク及びユーザ機器の間でデータパケットを通信するためのインタフェースを提供するゲートウェイサポートノード（gateway support node：以下、ＧＧＳＮという。）と、電気通信ネットワークの無線リソースを制御する無線ネットワークコントローラ（radio network controller、以下、ＲＮＣという。）を用いて、ゲートウェイサポートノード及びユーザ機器の間でデータパケットの通信を制御するサービスサポートノード（service support node：以下、ＳＧＳＮという。）とを備える。

データパケットは、データパケットのペイロードに関連するサービス品質（quality of service：以下、ＱｏＳという。）パラメータの単一の所定の組に基づいて、ＲＮＣによって確立された単一の無線アクセスベアラを用いてＵＥからＧＧＳＮに、又はＧＧＳＮからＵＥに伝送される。移動通信ネットワークによって提供される、ＵＥ及びＲＮＣの間でデータパケットを通信するための無線リソースは、貴重なリソースであり、例えば、ネットワークの現在の負荷に基づいて、特定の無線アクセスベアラをサポートできるか否かが制約されることもある。したがって、本発明の目的は、可能な限り効率的に無線リソースを利用することである。

R. Steele, C-C Lee and P. Gould,"GSM, cdmaOne and 3G Systems," published by Wiley International ISBN 0 471 491853 3GPP TS 26.202 V5.1.0 (2002-09) 3GPP TS 23.107 3GPP TS 26.201 V1.1.0 (2000-12) 3GPP TS 24.008

モバイル通信ユーザ機器（ＵＥ）とパケットデータネットワークの間でデータを通信するためのシステムは、パケットデータネットワークとＧＰＲＳ／ＵＭＴＳの間で移動通信ネットワークを介してデータパケットを通信するためのインタフェースを提供するゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）と、電気通信ネットワークの無線リソースを制御する無線ネットワークコントローラ（ＲＮＣ）を用いて、ゲートウェイサポートノードとユーザ機器の間でデータパケットの通信を制御するサービスＧＰＲＳサポートノード（ＳＧＳＮ）とを備える。パケットデータプロトコル（ＰＤＰ）コンテキスト要求は、ＧＧＳＮとＵＥとの間の通信を実現する仮想通信チャンネルを確立するために用いられる。各データパケットは、サービス品質（ＱｏＳ）パラメータの単一の組を指定し、無線アクセスベアラは、このサービス品質パラメータの組に基づいて、ＲＮＣによって提供される。移動通信ネットワークによって提供される、ＵＥ及びＲＮＣの間でデータパケットを通信するための無線リソースは、貴重なリソースであり、例えば、ネットワークの現在の負荷に基づいて、特定の無線アクセスベアラをサポートできるか否かが制約されることもある。したがって、本発明の目的は、可能な限り効率的に無線リソースを利用することである。

本発明に係る電気通信システムは、移動体通信を行うユーザ機器に／から、複数の異なる種類のデータを搬送するインターネットデータパケットを通信するための電気通信システムにおいて、ユーザ機器とパケットデータネットワークの間でデータパケットを通信するためのインタフェースを提供するゲートウェイサポートノードと、ユーザ機器に／からデータパケットを通信するための無線アクセスベアラを提供する無線ネットワークコントローラを用いて、ゲートウェイサポートノードとユーザ機器との間のデータパケットの通信を制御するサービスサポートノードとを備え、ユーザ機器は、異なる種類のデータを含むデータパケットを通信する仮想通信チャンネルの要求を表し、サービス品質パラメータのメインの組を特定するデータフィールドと、サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含み、各サービス品質パラメータの組がデータパケット内の異なる種類のデータの１つに提供される、コンテキストアプリケーション要求データをサービスサポートノードに供給し、サービスサポートノードは、コンテキストアプリケーション要求データに応答して、異なる種類のデータを通信するための各複数のサービス品質パラメータに基づき、無線アクセスベアラを含むサービスサポートノードを介してゲートウェイサポートノードとユーザ機器の間で、仮想チャンネルを確立する。

特定のサービス品質（ＱｏＳ）を提供する従来の装置は、同じサービス品質パラメータに基づいて、データパケットの全体のペイロードを送信する無線ベアラを設定するという点において、柔軟性が低い。このため、データパケットペイロードが異なるＱｏＳ要求を有し及び／又は重要度が均等ではない異なる種類のデータを含む場合、無線リソースを効率的に利用することができなかった。

本発明の実施形態では、例えば、インターネットプロトコルデータパケット等のデータパケット内で異なる種類のデータをサポートする無線アクセスベアラを提供する。無線アクセスベアラは、各データの種類毎に提供される。各無線アクセスベアラによってサポートされるサービス品質パラメータは、各異なるデータの種類の特徴及び／又は重要度に適応化することができる。これにより、ネットワークによって提供される無線リソースをより効率的に利用することができる。

幾つかの実施形態では、各異なるデータの種類のための無線アクセスベアラは、サービス品質パラメータのメインの組に基づいて、メインの無線アクセスベアラ内のサブフローとして提供される。したがって、例えば、ＧＰＲＳ等の既存のネットワークアーキテクチャのために開発された無線ネットワークコントローラを実質的に変更する必要はない。

本発明の様々な更なる側面及び特徴は、添付の特許請求の範囲に定義されており、これらの側面には、複数の異なる種類のデータを搬送するインターネットパケットを通信するための通信方法、サービスサポートノード、無線ネットワークコントローラ及び移動体であるユーザ機器が含まれる。

ボイスオーバＩＰ
ボイスオーバＩＰ（ＶｏＩＰ）は、公衆交換電話網（public switched telephone network：ＰＳＴＮ）のコミットされた回線を用いず、インターネットプロトコルを介して、デジタルボイスデータをパケットで伝送する。ＶｏＩＰ及び関連するプロトコルは、本出願の図１〜図３に示されており、より詳しくは、添付資料１に開示されている。

ＶｏＩＰプロトコルスタックの構造を図１に示す。プロトコルスタックは、物理層１１０と、データリンク層１２０と、インターネットプロトコル（internet protocol：以下、ＩＰという。）層１３０と、ユーザデータグラムプロトコル（user datagram protocol：以下、ＵＤＰという。）層１４０と、実時間プロトコル（real-time protocol：以下、ＲＴＰという。）層１５０と、ボイス層１６０とを含む。更なる詳細は、添付資料１に開示されている。

図２は、ＵＤＰデータパケットの構造を示している。ＵＤＰパケットの各フィールドのコンテンツは、添付資料１に詳細に開示されている。

図３は、ＩＰデータパケットの構造を示している。ＩＰパケットの各フィールドのコンテンツは、添付資料１に詳細に開示されている。

モバイルパケット無線ネットワークアーキテクチャ
データパケット通信をサポートする移動体無線ネットワークの例示的なアーキテクチャを図４に示す。図４で用いている用語及びアーキテクチャは、ＵＭＴＳのために用いられ、第３世代の移動体通信システムの標準化プロジェクト（Third Generation Partnership Project：以下、３ＧＰＰという。）によって管理される３Ｇのために提案された用語及びアーキテクチャに対応している。図４に示すように、ゲートウェイＧＰＲＳサポートノード（Gateway GPRS Support Node：以下、ＧＧＳＮという。）は、データパケットネットワーク（Packet Data network：以下、ＰＤＮという。）３０２に接続されている。ＰＤＮは、インターネットプロトコル（ＩＰ）を用いてパケットとして通信されたデータを含む。ＧＧＳＮと外部ネットワークとの間のインタフェース３０４には、標準化されたＧｉのラベルを付している。但し、これ以外の更なる側面も標準化されている。また、ＧＧＳＮには、標準化されたＧｎ／Ｇｐのラベルが付されたインタフェース３６８を介して、サービスＧＰＲＳサポートノード（Serving GPRS Support Node：以下、ＳＧＳＮという。）３０６が接続されている。

ＧＧＳＮ及びＳＧＳＮは、ＧＰＲＳをサポートする必要がある２つのネットワークコンポーネントである。ＧＧＳＮは、外部のデータパケットネットワーク（ＰＤＮ）と、ＧＰＲＳをサポートするモバイルネットワークとの間のゲートウェイとして機能する。ＧＧＳＮは、受け取ったＩＰデータパケットを、移動通信ネットワークによって提供された無線アクセス設備を介してデータを受け取る、モバイル機器である特定のＵＥに用いられるＳＧＳＮにルーティングするために十分な情報を含んでいる。例えば、一実施形態においては、３ＧＰＰ規格によって定義されている汎用陸上無線アクセスネットワーク（Universal Terrestrial Radio Access Network：以下、ＵＴＲＡＮという。）方式に基づいて無線アクセス設備が提供される。ＳＧＳＮは、ＳＧＳＮが同じ公衆陸上移動体ネットワーク（Public Land Mobile Network：以下、ＰＬＭＮという。）内にある場合、Ｇｎインタフェースを介して、ＧＧＳＮに接続され、Ｇｐインタフェースを介して、他のＰＬＭＮに属するＧＧＳＮに接続される。

ＳＧＳＮは、移動体無線ネットワークによってサポートされた領域内で移動するＵＥの移動性管理（mobility management）を提供する。この目的で、ＳＧＳＮは、ホーム位置レジスタ（Home Location Register：以下、ＨＬＲという。）３１０にアクセスする。ＳＧＳＮは、ＵＴＲＡＮ無線アクセス設備を介して、モバイルユーザＵＥ３１６、３１８と通信を行うために、データパケットを無線ネットワークコントローラ（ＲＮＣ）３１２、３１４にルーティングするよう構成されている。ＵＴＲＡＮ無線アクセス設備は、移動通信ネットワークの領域の無線通信可能範囲を提供する基地局を構成するノードＢ装置３２０、３２２、３２４、３２６、３２８によって提供される。Ｉｕｂのラベルが付されている、各ＲＮＣ３１２、３１４と、ノードＢ装置３２０、３２２、３２４、３２６、３２８との間のインタフェース３３０、３３２、３３４、３３６、３３８は、確立されている又は開発中の規格に従う。一方、Ｉｕ−ｐｓのラベルが付されている、ＳＧＳＮと、各ＲＮＣ３１２、３１４との間のインタフェース３４０、３４２は、開発中の規格に従う。

重要度が異なるデータの通信
本発明の実施形態は、ＩＰパケットのペイロード内のデータの重要度に応じて無線リソースを最適化するように、ＵＥ３１６、３１８に／から、ＩＰパケットの形式でデータを通信する機能を提供する。ＩＰパケットを介して通信されるデータは、重要度が均等ではない、異なるパラメータ又はフィールドを有するセクションを含む場合がある。重要度が均等ではないフィールドを有するデータの一具体例としては、例えば、ＡＲＭコーデックによって生成されたデータ等の音声符号化されたデータフレームがある。

ＡＭＲ音声コーデックは、異なる種類の特徴を有し、及び／又は重要度が等しくない、異なる種類のデータフィールドを含む所定の長さのデータフレームを生成することが知られている。このような音声コーデックの具体例は、欧州電気通信標準化機構（European Telecommunications Standards Institute：以下、ＥＴＳＩという。）によって標準化され、３ＧＰＰによって異なるレートに指定されている適応型マルチレート音声（Adaptive Multi-Rate Speech：以下、ＡＭＲという。）コーデックとして知られている（非特許文献２参照）。ＡＭＲは、Ａビット、Ｂビット、Ｃビットと呼ばれる異なる重要度を有する最大３個のデータフィールドを有するデータフレームを提供する。Ａビットは、音声を理解できる程度の基本レベルのオーディオ情報を提供するが、話者を特定するために十分なレベルの忠実度は有していない。Ｂビット及びＣビットは、更に高いレベルの忠実度を提供する。ここで、Ａビット、Ｂビット及びＣビットの数は、データフィールドを通信するために利用可能な無線リソースに基づいて適応化することができる。このため、各異なるフィールドに異なるＱｏＳを適用でき、このようなフィールドの具体例は、ＵＭＴＳ用に広帯域ＡＭＲ（wideband AMR：以下、ＡＭＲ−ＷＢという）符号化されたフレームとして、非特許文献２に開示されている。ＡＭＲ−ＷＢについては、広帯域ＵＭＴＳを介して通信できるデータの容量が制限されているため、Ｃビットを使用しない。

ＡＭＲデータフレームの３つのフィールドのそれぞれにおけるデータビット数を判定するために、回線交換モバイルネットワークのモバイル交換局は、無線アクセスベアラサブフローコンビネーションインディケータ（Radio Access Bearer sub-Flow Combination Indicator：以下、ＲＦＣＩという。）を生成する。したがって、パケットベースの移動通信ネットワークには、対応するＲＦＣＩが必要である。本発明の実施形態として後述するように、ＩＰパケットによって搬送されるＡＭＲデータフレームに関しては、ＧＧＳＮは、ＡＭＲフレームの異なるフィールドについて、データビットを特定し、適切なＲＦＣＩを提供する必要がある。

図５は、図４に示すＧＰＲＳをサポートするモバイルネットワークの構成を概略的に示している。図５に示す構成は、本発明の実施形態に基づき、ＩＰパケットを介して、重要度が均等ではないフィールドを含むペイロードデータを通信するピアツーピア通信パスを提供する。ＩＰパケットは、図４に示すモバイルネットワークのＧＧＳＮ３００、ＳＧＳＮ３０６及びＲＮＣ３１４を介して、ＵＥ３５０、３５２の間で通信される。図５に示すように、ＲＮＣ及びＵＥの間で、ＩＰパケットによって搬送されるデータは、ＡＭＲ音声符号化データフレームのＡ、Ｂ及びＣの３つのフィールドを含む。

ＧＧＳＮ及びＳＧＳＮ内のプロトコルに関して、ＵＥに送信され、及びＵＥから受信されるＩＰパケットは、データパケットユニット（Packet Data Unit：以下、ＰＤＵという。）を構成する。ＰＤＵの形式は、ＧＧＳＮ、ＳＳＧＮ、ＲＮＣ及びノードＢ装置内で、プロトコルにとって既知でなければならない。ＰＤＵは、ＧＰＲＳネットワーク内で通信されるパケットの形式を指す総称的な用語である。なお、ＰＤＵは、ＵＴＲＡＮのＲＬＣに通信されるデータパケットについて言及する場合、サービスデータユニット（Service Data Unit：以下、ＳＤＵという。）と呼ばれ、コアネットワーク内の特にＳＧＳＮ及びＧＧＳＮの場合には、ＰＤＵは、通常、データパケットを指す。

本発明の実施形態は、無線リソースの利用効率を高めるように、無線アクセスネットワークを介して、ＩＰパケットの形式でデータを通信する機能を提供する。このために、パケットアクセスをサポートする移動体無線ネットワークの一部は、異なるレベルの重要度を有する異なるデータフィールドを特定するように適応化され、データの種類に対応した異なるＱｏＳを提供するサブフローを有する無線アクセスベアラを確立する。これは、ＩＰパケット情報が、例えば、ＡＭＲコーデックによって生成された、音声符号化された情報を搬送する場合、ＵＴＲＡＮは、データの相対的な重要度に一致するように、無線アクセスベアラを適応化する必要があるためである。各無線ベアラは、相対的な重要度及び異なるデータフィールドの特徴に基づいて、最適化される。

３ＧＰＰ規格仕様書、３ＧＰＰ ＴＳ２３．１０７（非特許文献３）に定義されているように、現在のところ、コンベンショナル、インタラクティブ及びバックグランドクラスと呼ばれる４つの異なるＱｏＳタイプがある。本発明の実施形態では、それぞれが異なるＱｏＳを提供する複数のサブフローを有する無線ベアラの要求を含むようにＰＤＰコンテキストアクティブ化要求を適応化する。各サブフローについて無線アクセスベアラを提供する一具体例として、各サブフロー無線アクセスベアラに不均一誤り保護（Un-equal Error Protection：以下、ＵＥＰという。）を提供してもよい。これについては、以下のセクションで更に詳細に説明する。

ＰＤＰコンテキストアクティブ化
図６は、３つの異なる種類のボイスデータのＱｏＳパラメータの制御プレーン通信のための装置の構成を示している。この構成は、ユーザ機器（ＵＥ）３５２と、無線ネットワークコントローラ（ＲＮＣ）３１４と、汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＳＧＳＮ）３０６と、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）３００とを備える。

ＵＥ３５２は、少なくとも１つのＵＭＴＳ加入者識別モジュールを有するモバイル機器の１つである。ＵＭＴＳセッションマネージャ４１２と呼ばれるアプリケーションは、無線リソースへのアクセスのためにＳＧＳＮ４３０と交渉する機能を担っている。アクセスは、データパケットプロトコル（Packet Data Protocol：以下、ＰＤＰという。）を用いて調停される。ユーザがデータを送信できるようにするためには、ＵＥ３５２、ＳＧＳＮ３０６及びＧＧＳＮ３００において「ＰＤＰコンテキスト」をアクティブ化する必要がある。ＰＤＰコンテキストのアクティブ化は、要求された宛先ネットワークへのログオンに類する処理であり、ユーザ機器３５２の上のアプリケーションによって開始される。

無線ネットワークコントローラ（Radio Network Controller：以下、ＲＮＣという）３１４は、無線リソースの使用及び完全性を制御する。ＲＮＣ３１４は、無線リソース制御（Radioi Resource Control：以下、ＲＲＣという）層４２２と、無線リンク制御（Radio Link Control：以下、ＲＬＣという）層４２４と、メディアアクセス制御（Media Access Control：以下、ＭＡＣという）層４２６と、物理層４２８との４つの別個の層に分離することができる機能を提供する。

ＲＲＣ層４２２は、制御プレーンにおいて、ＳＧＳＮ３０６と交渉し、ＳＧＳＮからのＲＡＢセットアップ要求に基づいて、無線リソースへのアクセスを確立する。ＲＬＣ層４２４は、制御データを単に通過させるのではなく、ユーザデータのための接続を確立する。ＭＡＣ層４２６は、各データフローのデータがどのように伝送されるかを決定する。例えば、ＭＡＣ層４２６は、データフローのために、専用チャンネル又は共有チャンネル（帯域幅の消費量が少ない）の割当及び管理を担う。無線アクセスベアラ（ＲＡＢ）サブフローは、ＭＡＣ層４２６によって割り当てられる。物理層４２８は、データを、伝送媒体に渡される電子パルス又はアナログパルスのストリームに変換し、及びデータ伝送を監視する。また、物理層４２８は、例えば、出力データストリームに適切なエラー訂正符号を適用する役割も担っている。例えば、物理層４２８は、ＭＡＣ層４２６によって定義された各ＲＡＢサブフローに対し、異なるエラー訂正符号化レベルを適用できる。

ＳＧＳＮ３０６は、所望のデータリンクのためにユーザアプリケーションによって要求されたＱｏＳを指定するＰＤＰコンテキストアクティブ化要求メッセージをＵＥ３５２から受け取る。ＳＧＳＮ３０６は、特定のＱｏＳパラメータに基づいて、無線アクセスについてＲＮＣ３１４と交渉する。ＳＧＳＮ３０６は、関連する登録された各加入者のパケット交換サービスについて、加入者情報及び位置情報を保存する。ＱｏＳ情報は、無線アクセスネットワークアプリケーションパート（Radio Access Network Application Part：以下、ＲＡＮＡＰという。）プロトコルと呼ばれる信号プロトコルを用いて、ＳＧＳＮ３０６からＲＮＣ３１４に供給される。

ＲＡＮＡＰは、コアネットワーク（すなわち、ＳＧＳＮ３０６）とＵＴＲＡＮとの間のインタフェースのためのプロトコルをシグナリングする無線ネットワーク層である。ＵＴＲＡＮは、ＲＮＣ及びノードＢを含むＵＭＴＳネットワークの一部である。ＲＡＮＡＰは、ＲＮＣ３１４とＳＧＳＮ３０６の間で送受されるパケット交換データのシグナリングを処理する。また、ＲＡＮＡＰは、ＲＮＣ３１４とモバイル交換点（図示せず）との間で送受される回線交換データのシグナリングも処理できる。ＲＡＮＡＰが実行できる包括的な機能としては、例えば、ページング等、コアネットワークからの包括的なＵＴＲＡＮ手続き実現する機能、モバイル固有のシグナリング管理のために、プロトコルレベル上で各ＵＥを分離する機能、非アクセスシグナリングを送信する機能、無線ネットワークサブシステムリロケーションを行う機能、及び様々な種類のＵＴＲＡＮ無線アクセスベアラ（ＲＡＢ）を要求し、管理する機能等がある。本発明では、ＳＧＳＮは、ＲＡＮＡＰを用いて、ＰＤＰコンテキストアクティブ化要求に含まれているＱｏＳデータに基づいて、ＲＮＣ３１４における無線アクセスベアラサブフローの確立を要求する。

ＧＧＳＮ３００は、ＵＭＴＳ無線パケットバックボーンと、外部のデータパケットネットワークとの間のインタフェースとして機能し、すなわち、データネットワークと、ＩＰネットワークとの間のインタフェースを提供する。Ｇｉインタフェースを介して、ＧＧＳＮが受け取ったパケットは、対応するＳＧＳＮ３０６に供給される。この目的で、ＧＧＳＮ３００は、ユーザプロファイルの現在のＳＧＳＮアドレスをロケーションレジスタに保存する。また、ＧＧＳＮ３００は、少なくとも１つのアクティブなＰＤＰコンテキストを有する各加入者の加入者情報及びルーティング情報を保存する。

図６に示す構成における制御プレーン通信シーケンスの例示的な動作のフローチャートを図７に示す。ステップ５１０において、ＵＥ３５２のユーザアプリケーションは、ＵＭＴＳセッションマネージャ４１２を介してＰＤＰコンテキスト要求アクティブ化を開始する。コンテキストアクティブ化手続きは、それ自体、無線リソースの割当を必要とする。ステップ５１２において、ＵＥ３５２は、「ＰＤＰコンテキストアクティブ化」要求をＳＧＳＮ３０６に送信する。ＰＤＰコンテキスト要求に含まれる情報要素は、ＡビットのＱｏＳパラメータを特定するために必要なフィールドと、Ｂビット及びＣビットの独立したＱｏＳパラメータを特定する更に２つの任意のフィールドとを有する。ＰＤＰコンテキストアクティブ化メッセージは、更に、接続が要求された外部ネットワークのアクセスポイント名と、ユーザ識別情報と、ＩＰコンフィグレーションパラメータとを含む。ＳＧＮＳ３０６は、ステップ５１４において、ＰＤＰコンテキスト要求を受け取り、加入者記録に基づいてユーザを検証する。要求が有効である場合、ＳＧＳＮ３０６は、ドメイン名サーバ（図示せず）に要求されたアクセスポイント名を含むクエリを送る。ステップ５１６では、ドメイン名サーバは、供給されたアクセスポイント名情報を用いて、外部ネットワークへの必要な接続を提供する少なくとも１つのＧＧＳＮ３００のアドレスを判定する。選択されたＧＧＳＮ３００のＩＰアドレスは、ＳＧＳＮ３０６に供給される。ステップ５１８では、ＳＧＳＮは、供給されたＧＧＳＮＩＰアドレスに基づき、ＧＰＲＳトンネルプロトコルを用いてＧＧＳＮ３００に仮想接続チャンネルを要求する。接続トンネルは、カプセル化されたユーザデータを送信することができる予め定義された仮想チャンネルである。ＧＧＳＮは、ステップ５２２において、接続トンネル要求を受け取り、要求されたトンネルを確立し、ＵＥ３５２に伝えるべきＩＰアドレスを返す。これにより、ＵＥ３５２とＧＧＳＮ３００の間で仮想接続が確立される。更に、ＧＧＳＮ３００は、接続トンネルと、外部ネットワークへの物理インタフェースとの関連付けも行う。これにより、ＵＥ３５２と外部ネットワークの間でデータ伝送が可能になる。

図８は、ボイスデータのＡビット、Ｂビット及びＣビットの個別のＱｏＳ要求に基づいて、無線リソースを割り当てるためにＳＧＳＮ３０６とＲＮＣ３１４の間で行われる制御プレーン折衝処理のフローチャートである。ステップ５３０において、Ａビット、Ｂビット及びＣビットのそれぞれについて、３組の独立したのＱｏＳパラメータを特定するＰＤＰコンテキスト情報要素を受け取ると、ＳＧＳＮ３０６は、ユーザアプリケーションによって要求されたデータ転送のために無線アクセスベアラのセットアップを要求するＲＡＮＡＰ要求をＲＮＣ３１４に送る。ステップ５３２において、ＲＮＣ３１４のＲＲＣ層４２２は、ＲＡＮＡＰ要求を受け取り、ＭＡＣ層４２６にこの要求を渡す。ＭＡＣ層４２６は、ステップ５３４において、Ａビット、Ｂビット及びＣビットのそれぞれについて、３つの独立したＲＡＢサブフローを確立する。各サブフローは、予め定義された選択されたサブフローのカテゴリは、ＲＡＮＡＰによって、３つのボイスカテゴリのいずれかに特定される。そして、ステップ５３６において、３つのサブフローのそれぞれの物理層パラメータを設定する。具体的には、３つのサブフローのそれぞれに、異なるレベルの誤り保護を適用する。

不均一誤り保護（すなわち、ボイスデータビットの異なるクラスに対する異なるレベルの誤り保護）をサポートするために、各クラスのボイスビット（Ａビット、Ｂビット及びＣビット）について、複数のＱｏＳパラメータを個別に構成する必要がある。ＳＧＳＮ３０６は、ＰＤＰコンテキスト要求内の情報に基づいて、ＲＡＢ割当処理を開始する。そして、ＲＮＣ３１４は、ＱｏＳパラメータに基づいて、ＵＭＴＳ無線アクセスベアラを確立する。１つのＰＤＰコンテキスト要求につき、１つのＲＡＢしか割り当てることができないが、単一のＲＡＢは、１つ以上のＲＡＢ調整されたサブフローに分割される。表１は、ＱｏＳに関連する様々なＲＡＢサービス属性及びこれらに対応するＲＡＢサービス属性値を示している。この表は、広帯域適応型マルチレートコーディングのためのＲＡＢパラメータを示している（非特許文献２の表５．１参照）。この技術では、所定のＲＡＢパラメータを、回線交換ボイスと同様に、のようにパケット交換ボイスに用いることができる。表１に示すように、第１のＲＡＢサブフローは、Ａビットに関連し、第２のＲＡＢサブフローは、Ｂビットに関連する。第１のＲＡＢサブフローのための残りのビット誤り率（residual bit error ratio）は１０^−６であり、第２のＲＡＢサブフローのための残りのビット誤り率は１０^−３である。これは、Ａビットに適用されるエラー訂正レベルがＢビットに適用されるエラー訂正レベルより高いことを反映している。サービスデータユニット（ＳＤＵ）フォーマットでは、５つの所定の音声コーデックデータフレームタイプのそれぞれ（１〜５）について、ボイスデータクラスＡ、Ｂ、Ｃのそれぞれに異なるビット数を割り当てる。Ｗ−ＡＭＲの各フレームタイプのためのビット割当の具体例を表２に示す。このデータセットは、非特許文献３から引用した。ＲＡＢサブフローの数と、例えば、残りのビット誤り率、誤りを含むＳＤＵの配信等、これらに関連する属性は、ＳＧＳＮ４３０におけるＲＡＢ確立の段階で、ＰＤＰコンテキスト要求の情報要素に基づいて定義される。図６に示すように、ＲＡＢサブフロー属性は、ＲＡＮＡＰ無線アクセスベアラ確立要求を用いて、ＲＮＣ３１４にシグナリングされる。１つのＲＡＢサブフローコンビネーション（RAB sub-flow combination：以下、ＲＦＣという。）の全てのサブフローのビットの総数は、対応する汎用広帯域ＡＭＲコーデックモード（フレームタイプに関連している）について、表２に指定されているＡビット、Ｂビット及びＣビットへのビット割当の合計に対応する必要がある。非特許文献２から引用する表３は、データの相対的な重要度に基づく各ＲＡＢサブフローにおけるビット数の設定例を示している。

図１２は、非特許文献５に開示されているように、単一の無線アクセスベアラについて、ＱｏＳパラメータを指定する既知のＱｏＳ情報要素のデータ構造を示している。この情報要素は、所定の無線アクセスベアラに関連する様々なＱｏＳパラメータを指定するデータの１３個のオクテットを含んでいる。

図１３は、第１の無線アクセスベアラのＱｏＳパラメータを指定し、及び個別のＲＡＢサブフローのために２つの異なるＱｏＳパラメータを指定する更なる任意のデータフィールドを有する本発明に基づくＰＤＰコンテキスト情報要素のデータ構造を示している。図１２に示す既存の標準のＱｏＳ情報要素におけるオクテット５の予備ビット５〜８は、図１３に示すように、本発明に基づく変更されたＱｏＳ情報要素においては、任意のＱｏＳ情報ビットとして利用される。改善されたＱｏＳ情報要素は、２つの更なる任意のフィールドを含む。任意のフィールド１は、情報要素のオクテット１４〜２２を占める。オクテット１４〜２２は、オクテット５〜オクテット１４と同じフォーマットを有する。任意のフィールド２は、情報要素のオクテット２３〜３１を占める。オクテット２３〜３１も、オクテット５〜オクテット１４と同じフォーマットを有する。オクテット５のビット８は、ゼロに設定され、これは、如何なる任意のデータフィールド１又は任意のデータフィールド２も存在しないことを示している。また、オクテット５のビット８は、１に設定され、これは、情報要素内に、少なくとも任意のフィールド１と、可能性として任意のフィールド２が存在していることを意味する。ＱｏＳの任意のフィールド１は、ＡビットのＲＡＢサブフローのＱｏＳパラメータを指定するために用いることができ、任意のフィールド２は、ＢビットのＲＡＢサブフローのＱｏＳパラメータを指定するために用いることができる。

ユーザプレーン適応化
図１４は、ＩＰパケットのペイロード内の各データフィールドに無線アクセスベアラを確立した後に、ＧＧＳＮ３００、ＳＧＳＮ３０６、ＲＮＣ３１４及びＵＥ３５２内で、これらのＩＰをＵＥと送受するために適応化されたプロトコルスタックを示している。

ＧＧＳＮ３００、ＳＧＳＮ３０６及びＲＮＣは、リンク層において、ユーザデータ（ＧＴＰ−Ｕ）及びシグナリングデータ（ＧＴＰ＿Ｃ）の両方を通信するためのＧＰＲＳトンネルプロトコル（GPRS tunnelling protocol：以下、ＧＴＰという。）を有する。ＧＴＰ−Ｕは、ＧＧＳＮと、ＳＧＳＮと、ＲＮＣとの間でユーザデータをトンネリングする。トランスポートプロトコルは、ＧＧＳＮ、ＳＧＳＮ及びＲＮＣを介してＧＴＰデータユニットを搬送する。一実施形態では、Ｉｕ−ｐｓインタフェースに亘るこれらのデータ単位をＩｕ−ｐｓフレームと呼ぶ。Ｉｕ−ｐｓフレームの構造を図１５に示す。Ｉｕ−ｐｓフレームは、ＲＡＢサブフローコンビネーションインデクス（RAB sub-flow combination index：ＲＦＣＩ）部８３０と、ＩＰ／ＵＤＰ／ＲＴＰヘッダ部８３２と、適応マルチレート符号化されたボイスデータのＶｏＩＰペイロード８３４とを含む。トランスポートプロトコルは、インターネットプロトコルを用いて、ＧＧＳＮからＵＥにＩｕ−ｐｓフレームを通信するユーザデータグラムプロトコル（ＵＤＰ）を含む。基本的には、図１４に示すように、ＧＴＰ−Ｕは、下位層のプロトコルを用いて、ＳＧＳＮ及びＲＮＣの間でＩｕ−ｐｓフレームを搬送する。これは、非特許文献１に開示されており、ＧＲＰＳ／ＵＭＴＳアーキテクチャの当業者に知られている技術であるため、ここでは詳細には説明しない。ここで、ＲＮＣ及びＵＥでＩＰパケットを通信するためのプロトコル及び層を表す、図１４で用いた略語を以下に説明する。

ＲＮＣについて
層８００は、インターネットプロトコルを用いてパケット形式でデータを通信するＩＰトランスポート層である。

層８０３は、ユーザデータグラムプロトコルを用いてＩＰパケットをトランスポートする制御プロトコル層である。

層８０４は、ＧＴＰ−Ｕプロトコルである。

層８０６は、無線アクセスベアラを介したトランスポートのために、ネットワークレベルのプロトコルを無線リンク制御（ＲＬＣ）層等のリンク層プロトコルにマッピングするデータパケットコンバージェンスプロトコル（Packet Data Convergence Protocol：以下、ＰＤＣＰという。）層である。ＰＤＣＰは、ＩＰヘッダを圧縮及び伸張できる。ヘッダ圧縮法は、例えば、ＲＴＰ／ＵＤＰ／ＩＰ等、用いられる特定のネットワーク層、トランスポート層及び上位層プロトコルに固有である。

層８０８は、ＰＤＣＰ層から無線アクセスベアラにデータをマッピングするＲＬＣ層である。

層８１０は、各無線アクセスベアラからのデータをＵＴＲＡＮの物理的な無線チャンネルにマッピングするメディアアクセスコントロール（ＭＡＣ）副層である。

ＵＥについて
層８１２ＰＨＹは、ＲＮＣから、ノードＢ装置を介して、ＵＴＲＡＮに基づいて提供された物理的な無線チャンネルの伝送を含む物理層を表す。

層８１４は、ＲＮＣのＭＡＣ層に対応するＭＡＣ層である。

層８１６は、ＲＮＣのＲＬＣ副層に対応するＲＬＣである。

層８１８は、ＲＮＣのＰＤＣＰ層に対応するＰＤＣＰ副層である。

ＧＧＳＮ３００は、図４及び図５に示すように、外部ネットワークからＩＰパケットを受け取り、ＧＴＰＵを介して、ＳＧＳＮにこれを転送する。ＳＧＳＮ３０６内のＩＰ処理副層８２４は、ＩＰデータパケットフィールドを解析し、重要度が異なるデータフィールド内に含まれるビットの数を特定する。一例として、ＡＭＲ音声コーデックからのデータフレームの場合、この解析により、各フィールド内の所定数のビットに基づいて、Ａフィールド、Ｂフィールド及びＣフィールド内のビット数が特定される。ＩＰ処理副層は、異なるフィールド内に存在するビット数からＲＦＣＩフィールドを生成し、他方のネットワーク構成要素ＳＧＳＮ、ＲＮＣ、ＵＥのそれぞれに、データフレームが、所定の組のデータフォーマットのうちのどのデータフォーマットを表しているかに関する指示を提供する。この情報に基づき、重要度が異なる各データフィールドを適切な無線アクセスベアラにマッピングすることができる。

ＩＰ処理副層８２４は、ＩＰペイロードを解析する。ＲＮＣ内のＰＤＣＰは、ＩＰデータパケットのヘッダを圧縮する。ＳＧＳＮは、ビットフォーマットを知ると、ＲＦＣＩを生成し、次に、Ｉｕ−ｐｓフォーマットを生成することができる。

Ｉｕ−ｐｓフレームは、ＩＰ処理副層８２４によって、ＲＦＣＩ及びＳＤＵから生成される。したがって、Ｉｕ−ｐｓフレームは、ＳＧＳＮ３０６を介して、ＲＮＣ３１４に伝送でき、ＲＮＣのＩＰトランスポート層８００、ＵＤＰ層８０２を介して、ＧＴＰ−ｕ層８０４に伝送できる形式を有する。ＲＮＣのＰＤＰＣ層８０６内では、ＩＰヘッダ及びＵＤＰ／ＲＴＰフィールドは、ＰＤＰＣ８０６によって取り除かれ、この後、ＳＤＵ内の残りデータは、ＲＬＣ及びＭＡＣ層を介して、ＵＥにトランスポートされる。ゼロバイトヘッダ圧縮は、ＲＦＣ３２４３に基づいて実行される。

ＡＭＲフレームのためにＡビット、Ｂビット及びＣビットを含む異なるフィールドからのデータは、無線アクセスベアラ内で異なるサブフローを介して伝送され、ＲＡＢサブフローＡ、ＲＡＢサブフローＢ、ＲＡＢサブフローＣは、各フィールドからのデータの重要度及び特徴に対応するそれぞれ異なるＱｏＳを提供する。

本発明の実施形態の利点として、ＲＮＣのアーキテクチャを変更することなく、重要度が均等ではない異なるフィールドを有するデータを含むＩＰパケットからのデータを通信することができる。したがって、ＲＮＣは、ＳＤＵによって、ＲＦＣＩを検出できるので、ペイロードデータを適切なベアラに対応させることができる。

ＵＥにおいては、ＰＨＹ層８２１、ＭＡＣ層８１４及びＲＬＣ層８１６を介して通信データが渡された後に、ＰＤＣＰ層がデータにＩＰ／ＵＤＰ／ＲＴＰヘッダを再び適用し、これにより、ＩＰプロトコルに準拠するＩＰパケットをＳＩＰアプリケーション等のアプリケーション層３５２に渡すことができる。

要約すれば、例えば、ＡＭＲ音声フレームを含むＩＰパケットは、図１６及び図１７に示すように、以下に説明する動作によって、移動体無線ネットワークを介してトランスポートされる。

図１６は、ＧＧＳＮのユーザプレーンプロトコルスタックによって、データパケットに対して実行される処理を図式的に示している。図１６に示すように、ＧＧＳＮにおいて、ＩＰヘッダ８５２、ＵＤＰ／ＲＴＰフィールド８５４及びＡＭＲ−ＷＢ音声符号化されたフレーム８５６を提供するデータフィールドを含むＩＰパケット８５０は、ＩＰ処理副層８２４に受け取られる。そして、受け取られたＩＰパケットは、矢印８５８によって表されるように、以下の動作に基づいて処理される。ＩＰ処理副層８２４は、矢印８６２によって示すように、ＡＭＲ音声コーデックフィールド８５６を解析する。この解析の結果、Ａデータフィールド、Ｂデータフィールド、Ｃデータフィールドのそれぞれのビット数が特定され、この情報から、ＡＭＲ音声コーデックフレームを特定するＲＦＣＩ８６６を生成することができる。矢印８６４によって示すように、ＩＰ処理層は、Ｉｕ−ｐｓフレーム内で独立したフィールド８６６を生成するために、ＶｏＩＰパケットに添付されるＲＦＣＩを生成する。

そして、ＧＧＳＮのＩＰ処理副層８２４（図１４参照）は、矢印８６８によって示すように、ＡＭＲ音声フレームのＡビット、Ｂビット、ＣビットからＩｕ−ｐｓフレームの残りの部分を生成する。

そして、Ｉｕ−ｐｓフレームは、ＩＰプロトコルに基づいて、ＧＴＰ−Ｕを含む様々なプロトコル層を介して、ＳＧＳＮ３０６からＲＮＣ３１４にトランスポートされる。

ＲＮＣ３１４において、ＧＴＰ−Ｕプロトコル層８０４がＩｕ−ｐｓフレームを受け取ると、Ｉｕ−ｐｓフレームは、ＰＤＣＰに渡され、処理された後、無線アクセスインタフェースを介して、及びノードＢ装置を介してＵＥ３５２に伝送される。

図１７は、ＲＮＣのユーザプレーンプロトコルスタックによって、データパケット対して実行される処理を示している。図１７に示すように、処理ステップ８７０では、ＲＮＣのＰＤＣＰ層８０６がＩｕ−ｐｓフレームを受け取り、ＩＰ／ＵＤＰ／ＲＴＰヘッダ８６０を取り除いた後、矢印８７２によって示すように、ＳＤＵの残りの部分をＲＬＣ層８０８に渡す。そして、ＲＬＣ層８０８は、矢印８７４によって示すように、ＲＦＣＩ８６６を用いてＡデータフィールド、Ｂデータフィールド及びＣデータフィールドを分離する。矢印８７６によって示すように、Ａデータフィールド、Ｂデータフィールド及びＣデータフィールドは、それぞれＭＡＣ層８１０内の無線アクセスベアラＲＡＢ Ａ、ＲＡＢ Ｂ及びＲＡＢ Ｃを介して、ＵＥ３５２にトランスポートされる。

ＵＥ３５２内では、ＡＭＲ音声フレームは、ＰＨＹ層８１２及びＭＡＣ層８１４を介してトランスポートされた後、ＲＬＣ層８１６で再生される。そして、ＰＤＣＰ層８１８は、ＩＰ／ＵＰＤ／ＲＴＰヘッダを再生し、ＵＥのアプリケーション層８２０に渡す。

本発明の更なる様々な側面及び特徴は、添付の請求の範囲において定義されている。この請求の範囲から逸脱することなく、上述した実施の形態を様々に変更することができる。

添付資料１
ボイスオーバインターネットプロトコル（ＶｏＩＰ）は、パケットによるボイスデータの伝送に関連する。パケットは、パケットをどのようにルーティングするかを指定するヘッダに添付されるデジタルユーザデータの離散的なユニットである。パケットは、長さと期間を変えることができる。対称的に、電話回線を用いたトラヒックは、パケット交換型ではなく回線交換型であり、各データユニットは、固定長あり、期間も固定されている。ボイスデータのパケット交換は、マルチアプリケーションソフトウェアによって指示されるボイス、データ及びビデオトラヒックの統合の要求に基づいて実行される。ボイス及びデータトラヒックを統合することにより、通信チャンネル帯域幅をより効率的に使用することができる。回線交換電話方式は、通常、時分割多重化スキーム（ＴＤＭ）を用いて帯域幅を割り当てる。このようなＴＤＭスキームでは、電話機ユーザには、ユーザが話していないときでも、継続的に、固定チャンネルのタイムスロットに帯域幅を割り当てる。（発話が交互に行われ、あるいは返答を思案する時間のため）通常の会話音声パターンの約５０％が無音であることを考慮すると、継続的に帯域幅を割り当てるＴＤＭスキームは、無駄が多いと言える。ＶｏＩＰは、パケット交換により、会話における実際の発話の間に相当する必要な場合のみ帯域幅の使用を許可し、会話における無音の部分では、帯域幅を他のユーザに割り当てるスキームの一例である。この効率的な帯域割当スキームは、統計的ＴＤＭとして知られている（ＳＴＤＭ）。パケット交換ボイスの更なる利点は、回線交換ＴＤＭチャンネルは、１秒あたり６４キロビットのデータレートを必要とするが、パケットを用いた音声チャンネルは、１秒あたり４．８〜８キロビットのデータレートで動作できるという点である。

周知の回線交換電話網は、ハードワイヤード構造（６４ｋｂｉｔ／ｓ ＴＤＭアーキテクチャ）を有し、容易には変更できない。例えば、近年、５〜８キロビット／秒の範囲で動作する狭帯域幅コーデックが利用可能になっているが、電話網、電話交換機及び他のコンポーネントの柔軟性の欠如のために、この利益を享受することができない。コーデック（コーダ／デコーダ）は、パケットネットワークに亘るトランスポートのために、アナログ音声信号をデジタルサンプルに変換する。ＶｏＩＰは、変化をサポートし、提供されるサービスレベルの柔軟性を高めるインフラストラクチャである。例えば、ＶｏＩＰを用いることにより、データレート、使用される符号化技術、ＩＰアドレス、ポート番号及び例えば最大遅延等のＱｏＳ要求を折衝することができる。

インターネットプロトコル（ＩＰ）は、インターネット上のデータパケット通信をサポートする。インターネットは、コネクションレスなシステムとして設計され、これは、ソースと宛先ホストマシンとの間でパスが固定されていないことを意味する。したがって、ＩＰトラヒックルーティングは、固定接続がないために、所定の接続に関してデータテーブルが維持されないという意味において、ステートレス（stateless）である。これは、発呼側と被呼側の間にコネクション型の固定経路を確立する回線交換電話網と大きく異なる点である。このような固定接続は、音声の実時間の低遅延要求をサポートするように設計される。インターネットは、ボイストラヒックではなく、主にデータのために設計された、「ベストエフォート型」の配信ネットワークである。これは、データを配信する際、（例えば、網輻輳、又は雑音によるデータ欠落のため）問題が発生し、又は宛先のホストを見つけることができない場合、パケットが削除されることを意味する。

パケットボイスデータを実時間モードでデジタル信号からアナログ信号に逆変換する場合、会話における不自然な遅延をユーザに感じさせないためには、ボイスパケットのための双方向の遅延は、等しく、通常、３００ミリ秒未満である必要がある。しかしながら、標準の（非ボイス）データパケットは、ネットワークを介して、送信機と受信機との間でのタイミング構成を考慮することなく非同期通信される場合がある。ボイスパケットは、標準のデータトラヒックに比べて、誤りに対するトレランスが高い。具体的には、ボイス再生の忠実度に大きく影響することなく、最大５％のボイスデータパケットを欠落させることができる。多くの低ビットレートボイスコーデックによって生成されるボイスパケットのサイズは、非常に短く、通常、１０〜３０バイト程度（期間にして１０〜３０ミリ秒）である。ボイスパケットに添付される典型的なＩＰヘッダは、約２０バイト長である。小さなデータパケットを用いることにより、ルータでの処理遅延を短くできるという利点がある。

ＴＣＰは、誤り検査、データの確認応答、欠落し又は誤まりを含んだデータの再送信、フロー制御管理等のデータ保全動作に関する包括的なサポートを提供するので、インターネット上の殆どのユーザトラヒックは、伝送制御プロトコル（ＴＣＰ）ヘッダと共にトランスポートされる。ここで、包括的なＴＣＰサポート機能により、音声に必要な実時間性能では許容し難い４００〜５００ミリ秒の総合的な遅延が導入される。また、ＴＣＰは、ボイストラヒックに関して、ネットワークが混雑しているときにパケット伝送を遅らせるという、短所がある。このため、ボイストラヒックのために、ユーザデータグラムプロトコル（ＵＤＰ）として知られている異なるプロトコルが用いられている。

ＴＣＰは、接続指向プロトコルであり、これは、何らかのデータをネットワークノード間で伝送する前に、送信装置及び受信装置が協力して、双方向通信チャンネルを確立しなくてはならないことを意味する。次に、ローカルネットワークを介して送信されたデータの各パッケージに対しては、確認応答が返され、送信側の機器は、各データパッケージが誤りなしで受信されたことを確認するために、状態情報を記録する。

対照的に、ＵＤＰは、コネクションレスプロトコルであり、これは、送信側の機器がデータがルーティングされていることを受信装置に通知しないで、一方的にデータパケットを送ることを意味する。受信装置は、各データパケットを受け取っても、送信側の機器に状態情報を返さない。接続指向プロトコルであるＴＣＰは、ＵＤＰより信頼性が高いが、ＴＣＰによって実行される追加的な誤り検査及びフロー制御のために、処理速度は、ＵＤＰより遅い。更に、ＵＤＰは、ネットワークが混雑している場合であってもパケットを送信し続ける。

図１は、ＶｏＩＰプロトコルスタックの構造を示している。これは、ＶｏＩＰが他のインターネットプロトコルとともに、どのように動作するかを示している。プロトコルスタックは、物理層１１０と、データリンク層１２０と、インターネットプロトコル（ＩＰ）層１３０と、ユーザデータグラムプロトコル（ＵＤＰ）層１４０と、実時間プロトコル（ＲＴＰ）層１５０と、ボイス層１６０とを含む。

物理層１１０は、媒体及び信号物理的側面（例えば、電圧）を定義する。また、物理層１１０は、クロッキング及び同期動作、並びに物理的なコネクタを定義する。データの誤り訂正符号化は、物理層１１０が行う。データリンク層１２０は、１つのデータのリンクを介したトラヒックの転送をサポートする。データリンク層１２０で用いられる特定のプロトコルによって、誤り検出及び再送信を実行できる。ＩＰ層１３０は、データパケット（データグラムとも呼ばれる。）をどのように生成し、ネットワークを介してトランスポートするかを決定する。ＩＰ層１３０は、データを送信する場合、一組のタスクを実行し、データを受信する場合、他の一組のタスクを実行する。データの送信時には、ＩＰ層１３０は、宛先アドレスがローカル（すなわち、同じネットワーク内）であるか又はリモートであるかを判定する。ＩＰ層１３０は、ローカルの宛先については、ダイレクト通信を開始し、宛先がリモートにある場合、ゲートウェイ（ルータ）を介して通信する必要がある。宛先ネットワークノードがデータを受信すると、ＩＰ層１３０は、データパケットが伝送中に破損していないことを確認し、及びデータが正しい宛先に届けられたことを確認する。そして、ＩＰ層１３０は、ＩＰデータグラム内のデータフィールドのコンテンツをチェックし、ソースＩＰが如何なる指示を送ったかを判定する。これらの指示は、通常、例えば、プロトコルスタックの次の上位層、この場合、ＵＤＰ層１４０にデータを供給する等、何らかの動作を実行するための指示である。図３（後述）は、ＩＰデータパケットの構造を示している。

ＵＤＰ層１４０は、主に、ＩＰトラヒックの送信及び受信のためのマルチプレクサ／デマルチプレクサとして機能する。ＵＤＰデータグラムは、宛先ポート番号及びソースポート番号を含んでいる。宛先ポート番号は、ＵＤＰ及び受信装置のオペレーティングシステムによって使用され、適切な受信者（例えば、適切なアプリケーションプログラム）へのトラヒックを提供する。ＵＤＰポート番号及びＩＰアドレスは、結合されて「ソケット」を形成する。連結されたアドレスは、インターネット内で一意的である必要があり、ソケットの対は、各エンドポイント接続を特定する。幾つかのＶｏＩＰのベースの発呼処理プロトコルは、ポート番号へのアクセスなしでは効果的に機能できない。例えば、呼の確立及び分解（tear-down）のために用いられるセッション開始プロトコル（ＳＩＰ）は、特に、アプリケーション間での、パケット通話の間に用いられるポート番号の受け渡しをサポートする。図２（後述）は、ＵＤＰデータパケットの構造を示している。

ＲＴＰ層１５０は、実時間トラヒックをサポートする機能を提供し、すなわち宛先アプリケーションにおいて、実時間での再生を必要とするトラヒックをサポートする。ＲＴＰ層１５０によって提供されるサービスは、ペイロードタイプ識別（例えば、オーディオトラヒック）、シーケンスへの番号付け、タイムスタンピング、配信監視等を含む。ＲＴＰは、基底に存在するネットワークがマルチキャスト配信をサポートしている場合、このマルチキャスト配信を介する複数の宛先へのデータ転送をサポートする。ＲＴＰシーケンス番号により、受信機は、元のパケットシーケンスを再構築することができる。また、シーケンス番号を用いて、パケットの正しい位置を判定することもできる。ＲＴＰは、タイムリな配信を約束し、又は他のＱｏＳ保証を提供するような如何なるメカニズムも有していない。このような保証は、下位の層が担っている。ボイスデータは、原理的には、ＩＰ上に、又はＩＰ上のＵＤＰ上に設けることができるが、技術的に最良の代替例は、図１のプロトコルスタックに示すように、ＩＰ上のＵＤＰ上のＲＴＰ上にボイスを設けることである。

図２は、データグラムヘッダ２５０及びデータペイロード２６０を含むＵＤＰデータグラムの構造を示している。データグラムヘッダ２５０は、４つの１６ビットのフィールドと、ソースポートフィールド２５２と、宛先ポートフィールド２５４と、データ長フィールド２５６と、チェックサムフィールド２５８とを含んでいる。ソースポートフィールド２５２には、通常、送信側の機器の適切なＵＤＰポート番号が格納される。ソースポートフィールド値を用いる場合、受信装置は、ソースポートフィールド値を返信用のアドレスとして用いる。有効なソースポートフィールドを設けるか否かは任意である。宛先ポートフィールド２５４は、データグラムを配信すべき受信装置上のＵＤＰポートアドレスを指定する。データ長フィールド２５６は、ＵＤＰデータグラムの総データ長（ヘッダ及びペイロード）をオクテットで特定する。チェックサムフィールド２５８は、データグラムが伝送中に破損していないことを確認するために用いられる。データペイロード２６０は、可変長である。ＵＤＰでは、最大６４のキロバイトのサイズ（ＩＰによって許可されている最大パケットサイズ）を有するメッセージを送信することができる。データグラムヘッダ２５０は、ＵＤＰポートアドレスのみを含み、ソース又は宛先ＩＰアドレスを含んでいないが、チェックサムデータは、宛先ＩＰアドレス情報を含み、これにより、受信装置は、ＵＤＰデータグラムが誤って配信されたか否かを判断することができる。

図３は、ＩＰデータグラムヘッダ２７０及びデータペイロード２９６を含むＩＰデータグラムの構造を示している。ＩＰデータグラムヘッダ２７０は、４ビット、８ビット、１６ビット又は３２ビットの長さの１２個の個別のフィールドを含んでいる。ソースネットワーク装置（コンピュータ又はモバイル端末）上のＩＰは、ＩＰデータグラムヘッダ２７０を構築し、宛先におけるＩＰは、ＩＰヘッダのコンテンツを調べ、ＩＰデータグラムのデータペイロードをどう処理したらよいかを判定する。ＩＰヘッダには、ソースホスト及び宛先のホストのＩＰアドレスを含む多くの情報が含まれている。バージョンフィールド２７２は、どのバージョンのＩＰが用いられているかを示す。インターネットプロトコルヘッダ長（Internet header length：ＩＨＬ）フィールド２７４は、３２ビットワード内のＩＰヘッダの長さを特定する４ビットを含んでいる。通常、ヘッダは、２０バイトを含み、この場合、ＩＨＬ値は、５になる。なお、ヘッダ長は、固定ではない。サービスタイプフィールド（type of service field：ＴＯＳ）２７６により、ソースＩＰは、例えば、長い又は短い遅延、通常の又は高いスループット、及び通常の又は高い信頼度等、固有のルーティングを情報に指定することができる。最も低い優先順位０から最も高い優先順位７までの範囲の優先順位値は、データグラムの相対的な重要度を示す。この優先順位値を用いて、ネットワーク内のフロー制御及び輻輳メカニズムが実現され、ルータ、サーバ及びホストノードは、網輻輳が生じている場合、どのような順序でデータグラムを削除するかを決定することができる。全長フィールド２７８は、ＩＰデータグラムの総データ長（すなわち、ヘッダ及びペイロード）をオクテットで指定する。データグラムの可能な最大長は、２^１６バイトである。識別フィールド２８０は、ソースＩＰによってＩＰデータグラムに割り当てられた、インクリメントされるシーケンス番号を含んでいる。フラグフィールド２８２は、データのフラグメント化の可能性を示す。「フラグメント不可」（don't fragment：ＤＦ）フラグは、フラグメント化が可能か否かを指定する。「モアフラグメント」（more fragments：ＭＦ）フラグは、関連するデータグラムがフラグメントであることを示す。ＭＦ＝０の場合、更なるフラグメントが存在せず、又はデータが全くフラグメント化されていないことを意味する。フラグメントオフセットフィールド２８４は、ＩＰ宛先において、受け取ったフラグメントを正しい順序で再構築するために用いられる連続したフラグメントのそれぞれに割り当てられた数値である。有効期間フィールド（time to live field）２８６は、秒又はルータホップによって、ＩＰデータグラムが削除されるまでの有効期間を示している。ネットワークをデータグラムが通過する際、各ルータは、このフィールドを調べて、例えば、データグラムがルータ内で遅延した秒数に応じて、このフィールドをデクリメントする。このフィールドがゼロに達すると、データグラムは、削除される。プロトコルフィールド２８８は、ＩＰがデータペイロードを配信するべきプロトコルアドレスを格納する。プロトコルアドレス１は、インターネット制御メッセージプロトコル（ＩＣＭＰ）に対応し、プロトコルアドレス６は、伝送制御プロトコル（ＴＣＰ）に対応し、プロトコルアドレス１７は、ユーザデータグラムプロトコル（ＵＤＰ）に対応している。ヘッダチェックサムフィールド２９０は、ヘッダの妥当性を確認するために用いられる１６ビット値を含む。ヘッダチェックサム値は、有効期間フィールド２８６がデクリメントされる都度、各ルータで再計算される。チェックは、ユーザデータストリームに対しては行われない。ソースＩＰアドレスフィールド２９２は、応答をソースＩＰに送るために宛先ＩＰによって用いられる。宛先ＩＰアドレスフィールド２９４は、データが正しい宛先に配信されたことを確認するために宛先ＩＰによって用いられる。

ＶｏＩＰプロトコルスタックの構造を示す図である。 ＵＤＰデータパケットの構造を示す図である。 ＩＰｖ４データパケットの構造を示す図である。 データパケット通信をサポートするよう構成された移動体無線ネットワークの例示的アーキテクチャを示す図である。 図４に示すＧＰＲＳをサポートするモバイルネットワークを概略的に示す図である。 ３つの異なるカテゴリのボイスデータについて、ＱｏＳパラメータの制御プレーン通信のための構成を示す図である。 図６に示す構成のための制御プレーン通信シーケンスの例示的動作を説明するフローチャートである。 図６に示す構成のための制御プレーン通信シーケンスの更なる処理手順を説明するフローチャートである。 非特許文献２から引用した、サービス品質（ＱｏＳ）に関連する様々な無線アクセスベアラサービス属性及びこれらに対応するＲＡＢサービス属性値の表を示す図である。 非特許文献２から引用した、サービス品質（ＱｏＳ）に関連する様々な無線アクセスベアラサービス属性及びこれらに対応するＲＡＢサービス属性値の表を示す図である。 非特許文献４から引用した、５つの所定の音声コーデックデータフレームタイプのそれぞれの広帯域適応型マルチレート（ＡＭＲ−ＷＢ）ビットフォーマットを列挙する表を示す図である。 非特許文献２から引用した、データの相対的な重要度に基づく各ＲＡＢサブフローにおけるビット数の設定例の表を示す図である。 単一の無線アクセスベアラについて、ＱｏＳパラメータを指定する既知のＱｏＳ情報要素のデータ構造を示す図である。 第１の無線アクセスベアラのＱｏＳパラメータを指定し、及びＵＭＴＳベアラ内のとなるＱｏＳオプションについて、２つの異なるＱｏＳパラメータを指定する更なる任意のデータフィールドを有する本発明に基づくＰＤＰコンテキスト情報要素のデータ構造を示す図である。 ＩＰをＵＥと送受するために適応化されたユーザプレーン内のプロトコルスタックを示す図である。 ＶｏＩＰ用のＩｕ−ｐｓフレームの構造を示す図である。 ＧＧＳＮのユーザプレーンプロトコルスタックによって、データパケットに対して実行される処理を説明する図である。 ＲＮＣのユーザプレーンプロトコルスタックによって、データパケット対して実行される処理を説明する図である。

Claims (19)

1. 移動体通信を行うユーザ機器に／から、複数の異なる種類のデータを搬送するインターネットデータパケットを通信するための電気通信システムにおいて、
   上記ユーザ機器とパケットデータネットワークの間でデータパケットを通信するためのインタフェースを提供するゲートウェイサポートノードと、
   上記ユーザ機器に／からデータパケットを通信するための無線アクセスベアラを提供する無線ネットワークコントローラを用いて、上記ゲートウェイサポートノードとユーザ機器との間のデータパケットの通信を制御するサービスサポートノードとを備え、
   上記ユーザ機器は、異なる種類のデータを含むデータパケットを通信する仮想通信チャンネルの要求を表し、サービス品質パラメータのメインの組を特定するデータフィールドと、サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含み、各サービス品質パラメータの組がデータパケット内の異なる種類のデータの１つに提供される、コンテキストアプリケーション要求データを上記サービスサポートノードに供給し、
   上記サービスサポートノードは、上記コンテキストアプリケーション要求データに応答して、異なる種類のデータを通信するための各複数のサービス品質パラメータに基づき、無線アクセスベアラを含む該サービスサポートノードを介して上記ゲートウェイサポートノードとユーザ機器の間で、仮想チャンネルを確立する電気通信システム。
2. 上記サービスサポートノードは、確立された上記仮想チャンネルに応じて、無線アクセスネットワークアプリケーションパートプロトコルに基づいて、無線アクセス要求データを上記無線ネットワークコントローラに送信し、上記無線ネットワークコントローラは、無線リソース制御層と協働して、メディアアクセス制御層を用いて、異なる種類のデータの１つのための各複数のサービス品質パラメータ用の無線アクセスベアラを確立することを特徴とする請求項１記載の電気通信システム。
3. 上記無線リソース制御層は、
   メディアアクセス制御層内のサービス品質パラメータに基づき、無線アクセスベアラを確立し、
   メディアアクセス制御層において、無線アクセスベアラ内で異なるデータの各種類について無線アクセスベアラでサブフローを確立することを特徴とする請求項２記載の電気通信システム。
4. 上記インターネットパケットのペイロードデータは、適応型マルチレート音声符号化によって生成された、複数の異なる種類のデータを提供するデータフレームを含むことを特徴とする請求項１乃至３いずれか１項記載の電気通信システム。
5. 上記コンテキストアプリケーション要求データは、パケットデータプロトコルコンテキストアクティブ化処理に基づき、ゲートウェイサポートノードに供給されることを特徴とする請求項１乃至４いずれか１項記載の電気通信システム。
6. 移動体通信を行うユーザ機器に／から、複数の異なる種類のデータを搬送するインターネットデータパケットを通信するための通信方法において、
   上記ユーザ機器とパケットデータネットワークの間でデータパケットを通信するためのインタフェースを準備するステップと、
   上記ユーザ機器に／からデータパケットを通信するための無線アクセスベアラを提供する無線ネットワークコントローラを用いて、上記インタフェースとユーザ機器との間のデータパケットの通信を制御するステップと、
   異なる種類のデータを含むデータパケットを通信する仮想の通信チャンネルの要求を表し、サービス品質パラメータのメインのデータの組を特定するデータフィールドと、サービス品質パラメータの異なる組の要求を表す他の少なくとも１つのデータフィールドとを含み、各サービス品質パラメータの組がデータパケット内の異なる種類のデータの１つに提供されるコンテキストアプリケーション要求データを上記インタフェースに供給するステップと、
   上記コンテキストアプリケーション要求データに応答して、上記ゲートウェイサポートノードとユーザ機器の間で、仮想チャンネルを確立するステップと、
   上記各サービス品質パラメータの組に基づき、異なる種類のデータを通信するための無線アクセスベアラを確立するステップとを有する通信方法。
7. 無線アクセスネットワークアプリケーションパートプロトコルに基づいて、無線アクセス要求データを上記無線ネットワークコントローラに送信するステップと、
   上記無線ネットワークコントローラのメディアアクセス制御層を用いて、異なる種類のデータの１つのための各複数のサービス品質パラメータ用の無線アクセスベアラを確立するステップとを更に有する請求項６記載の通信方法。
8. 上記メディアアクセス制御層を用いるステップは、
   メディアアクセス制御層内のメインのサービス品質パラメータに基づき、無線アクセスベアラを確立するステップと、
   異なるデータの各種類について、メディアアクセス制御層のメインの無線アクセスベアラ内のサブフローとして無線アクセスベアラを確立するステップとを有することを特徴とする請求項７記載の通信方法。
9. 上記インターネットパケットのペイロードデータは、適応型マルチレート音声符号化によって生成された、複数の異なる種類のデータを提供するデータフレームを含むことを特徴とする請求項５乃至７いずれか１項記載の通信方法。
10. 上記コンテキストアプリケーション要求データは、パケットデータプロトコルコンテキストアクティブ化処理に基づいて通信されることを特徴とする請求項５乃至８いずれか１項記載の電気通信システム。
11. 移動体通信を行うユーザ機器に／から、ヘッダ及び複数の異なる種類のデータを含むペイロードデータを含むインターネットデータパケットを通信するサービスサポートノードにおいて、
    インターネットプロトコル通信層と、
    移動ユーザ機器とゲートウェイサポートノードの間でユーザデータを通信する仮想チャンネルを提供するユーザデータトンネル層とを備え、当該サービスポートノードは、ユーザ機器からのコンテキストアプリケーション要求データに応答して、
    当該サービスサポートノードを介して、上記ゲートウェイサポートノードとユーザ機器の間で、仮想チャンネルを確立し、
    コンテキストアプリケーション要求データに応答して、データフィールドを含むデータパケット内の異なる種類のデータの１つに必要なサービス品質パラメータを表す、サービス品質パラメータのメインの組及びサービス品質パラメータの異なる組の要求を表す他の少なくとも１つのデータフィールドに応答して、
    異なる種類のデータを通信するためのサービス品質パラメータの各組に基づいて無線アクセスベアラを確立するサービスポートノード。
12. 無線アクセスネットワークアプリケーションパートプロトコル層を備え、当該サービスサポートノードは、ユーザデータトンネル層を介して確立された仮想チャンネルに応じて、
    上記無線アクセスネットワークアプリケーションプロトコル層を用いて、上記無線ネットワークコントローラにアクセス要求データを送信し、該無線ネットワークコントローラのメディアアクセス制御層を用いて、上記サービス品質パラメータの各組に基づいて、異なる種類の各データについて、無線アクセスベアラを確立することを特徴とする請求項１１記載のサービスポートノード。
13. サービスサポートノードとモバイル通信ユーザ機器の間で、それぞれが、複数の異なる種類のデータを搬送するインターネットデータパケットを通信するための無線ネットワークコントローラにおいて、
    データパケットを通信するための無線リソースを制御する無線リソース層と、
    無線アクセスインタフェースを介してユーザ機器にデータパケットを通信するための無線アクセスベアラを提供するメディアアクセス制御層を制御し、無線アクセス要求データに応答して、無線アクセスネットワークアプリケーションプロトコル層を用いて無線リンク制御層を制御し、メディアアクセス制御層を用いて、サービス品質パラメータの各組に基づいて異なる種類の各データのための無線アクセスベアラを確立する無線リソース層によって制御され、無線リソースを提供する無線リンク制御層とを備える無線ネットワークコントローラ。
14. それぞれが複数の異なる種類のデータを搬送するインターネットデータパケットを通信する移動体であるユーザ機器において、異なる種類のデータを含むデータパケットを通信するための仮想の通信チャンネルの要求であって、サービス品質パラメータのメインの組と、他の少なくとも１つのデータフィールドとを特定するデータフィールドを含む異なるサービス品質パラメータを提供するそれぞれがデータパケット内の異なる種類のデータ用の複数の無線アクセスベアラの要求を表すコンテキストアプリケーション要求データをサービスサポートノードに送信するユーザ機器。
15. データプロセッサにロードされて、該データプロセッサに、通信方法を実行させるコンピュータにより実行可能な命令を提供するコンピュータプログラムにおいて、該通信方法は、移動体通信を行うユーザ機器に／から、複数の異なる種類のデータを搬送するインターネットデータパケットを通信するための通信方法において、
    上記ユーザ機器とパケットデータネットワークの間でデータパケットを通信するためのインタフェースを準備するステップと、
    上記ユーザ機器に／からデータパケットを通信するための無線アクセスベアラを提供する無線ネットワークコントローラを用いて、上記インタフェースとユーザ機器との間のデータパケットの通信を制御するステップと、
    異なる種類のデータを含むデータパケットを通信する仮想の通信チャンネルの要求を表し、サービス品質パラメータのメインのデータの組を特定するデータフィールドと、サービス品質パラメータの異なる組の要求を表す他の少なくとも１つのデータフィールドとを含み、各サービス品質パラメータの組がデータパケット内の異なる種類のデータの１つに提供されるコンテキストアプリケーション要求データを上記インタフェースに供給するステップと、
    上記コンテキストアプリケーション要求データに応答して、上記ゲートウェイサポートノードとユーザ機器の間で、仮想チャンネルを確立するステップと、
    上記各サービス品質パラメータの組に基づき、異なる種類のデータを通信するための無線アクセスベアラを確立するステップとを有するコンピュータプログラム。
16. 請求項１５記載のコンピュータプログラムを表す情報信号が記録されたコンピュータにより読取可能な媒体を備えるコンピュータプログラム製品。
17. 移動体通信を行うユーザ機器に／から、複数の異なる種類のデータを搬送するインターネットデータパケットを通信するための通信装置において、
    上記ユーザ機器とパケットデータネットワークの間でデータパケットを通信するためのインタフェースを準備する手段と、
    上記ユーザ機器に／からデータパケットを通信するための無線アクセスベアラを提供する無線ネットワークコントローラを用いて、上記インタフェースとユーザ機器との間のデータパケットの通信を制御する手段と、
    異なる種類のデータを含むデータパケットを通信する仮想の通信チャンネルの要求を表し、サービス品質パラメータのメインのデータの組を特定するデータフィールドと、サービス品質パラメータの異なる組の要求を表す他の少なくとも１つのデータフィールドとを含み、各サービス品質パラメータの組がデータパケット内の異なる種類のデータの１つに提供されるコンテキストアプリケーション要求データを上記インタフェースに供給する手段と、
    上記コンテキストアプリケーション要求データに応答して、上記ゲートウェイサポートノードとユーザ機器の間で、仮想チャンネルを確立する手段と、
    上記各サービス品質パラメータの組に基づき、異なる種類のデータを通信するための無線アクセスベアラを確立する手段とを備える通信装置。
18. 添付の図面を参照して、実質的に明細書に説明する電気通信システム、ゲートウェイサポートノード、サービスサポートノード、無線ネットワークコントローラ又は移動体であるユーザ機器。
19. 添付の図面を参照して、実質的に明細書に説明するインターネットデータパケットの通信方法。

Images