【手続補正書】
【提出日】平成21年3月13日(2009.3.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ゲートウェイサポートノードと、サービスサポートノードと、無線ネットワークコントローラとを含むパケット無線ネットワークを備え、移動体であるユーザ機器に／から、複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信する電気通信システムにおいて、
上記ゲートウェイサポートノードは、上記ユーザ機器と上記パケットデータネットワーク間でインターネットパケットを通信するインタフェースを提供し、
上記サービスサポートノードは、上記ゲートウェイサポートノードと上記移動ユーザ機器間のインターネットパケットの通信を、該ユーザ機器に／からインターネットパケットを通信する無線アクセスベアラを提供する無線ネットワークコントローラを用いて制御し、
上記ゲートウェイサポートノードは、上記サービスサポートノードと協働し、上記移動ユーザ機器からのコンテキストアプリケーション要求データに応答して、該ゲートウェイサポートノードと該移動ユーザ機器間に、該サービスサポートノードを介して仮想通信チャンネルを確立し、
上記コンテキストアプリケーション要求データは、異なる種類のデータを含むインターネットパケットを通信するための仮想通信チャンネルの要求を表し、サービス品質パラメータのメインの組を特定し、該サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドを含み、
上記サービス品質パラメータの各組は、上記インターネットパケットの異なる種類のデータのために提供され、
上記仮想通信チャンネルは、上記ゲートウェイサポートノードと、上記サービスサポートノードとの間でインターネットパケットを通信するためのベアラと、複数の無線アクセスベアラとを含み、
上記複数の無線アクセスベアラは、上記インターネットパケットの異なる種類のペイロードデータのために提供され、上記コンテキストアプリケーション要求データによって特定された異なる種類のデータのためのサービス品質パラメータのメインの組及び他の組のうちの１つを提供することを特徴とする電気通信システム。
【請求項２】
上記サービスサポートノードは、上記確立された仮想通信チャンネルに応じて、上記無線アクセス要求データを、無線アクセスネットワークアプリケーションパートプロトコルに基づいて上記無線ネットワークコントローラに通信し、
上記無線ネットワークコントローラは、無線リソース制御層と協働して、媒体アクセス制御層を用いて、異なる種類のデータに指定された上記各複数のサービス品質パラメータ用の無線アクセスベアラの１つを確立することを特徴とする請求項１記載の電気通信システム。
【請求項３】
上記無線リソース制御層は、
上記無線アクセスベアラを、上記媒体アクセス制御層のメインのサービス品質パラメータに基づいて、メインの無線アクセスベアラとして確立し、
上記媒体アクセス制御層において、上記メインの無線アクセスベアラ内で、サブフローとして、異なるデータのそれぞれについて上記無線アクセスベアラを確立することを特徴とする請求項２記載の電気通信システム。
【請求項４】
上記インターネットパケットのペイロードデータは、適応型マルチレート音声符号化によって生成され、上記複数の異なる種類のデータを提供するデータフレームを含むことを特徴とする請求項１乃至３いずれか１項記載の電気通信システム。
【請求項５】
上記移動ユーザ機器は、パケットデータプロトコルコンテキストアクティブ化処理に基づいて、上記コンテキストアプリケーション要求データを上記ゲートウェイサポートノードに通信することを特徴とする請求項１乃至４いずれか１項記載の電気通信システム。
【請求項６】
複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを、ゲートウェイサポートノードと、サービスサポートノードと、無線ネットワークコントローラとを含むパケット無線ネットワークを介して、移動体であるユーザ機器に／から通信する通信方法において、
上記パケット無線ネットワークのサービスサポートノードを用いて、上記ユーザ機器に／からインターネットパケットを通信するための無線アクセスベアラを提供する上記無線ネットワークコントローラを用いた、上記ゲートウェイサポートノードと上記移動ユーザ機器間のインターネットパケットの通信を制御するステップと、
サービス品質パラメータのメインの組を特定するデータフィールドと、サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含み、上記サービス品質パラメータのそれぞれは、上記インターネットパケットの異なる種類のデータのために提供され、該異なる種類のデータを含むインターネットパケットを上記パケット無線ネットワークを介して通信するための仮想通信チャンネルの要求を表すコンテキストアプリケーション要求データを、上記ゲートウェイサポートノードに通信するステップと、
上記コンテキストアプリケーション要求データに応答して、上記インターネットパケットを通信するための仮想通信チャンネルを、上記ゲートウェイサポートノードとユーザ機器の間で確立するステップと、
上記サービス品質パラメータの各組に基づき、それぞれがインターネットパケットの異なる種類のペイロードデータの１つを通信するために提供される複数の無線アクセスベアラを確立するステップとを有する通信方法。
【請求項７】
上記仮想通信チャンネルを確立するステップは、
無線アクセスネットワークアプリケーションパートプロトコルに基づいて、無線アクセス要求データを上記無線ネットワークコントローラに通信するステップと、
上記異なる種類のデータの１つのための各複数のサービス品質パラメータ用の無線アクセスベアラを、上記無線ネットワークコントローラの媒体アクセス制御層を用いて確立するステップとを更に有する請求項６記載の通信方法。
【請求項８】
上記媒体アクセス制御層を用いるステップは、
上記媒体アクセス制御層のメインのサービス品質パラメータに基づき、メインの無線アクセスベアラを確立するステップと、
異なるデータの各種類について、上記媒体アクセス制御層の上記メインの無線アクセスベアラ内のサブフローとして上記無線アクセスベアラを確立するステップとを有することを特徴とする請求項７記載の通信方法。
【請求項９】
上記インターネットパケットのペイロードデータは、適応型マルチレート音声符号化によって生成された、複数の異なる種類のデータを提供するデータフレームを含むことを特徴とする請求項６乃至８いずれか１項記載の通信方法。
【請求項１０】
上記コンテキストアプリケーション要求データは、パケットデータプロトコルコンテキストアクティブ化処理に基づいて通信されることを特徴とする請求項６乃至９いずれか１項記載の通信方法。
【請求項１１】
移動体であるユーザ機器に／から、ヘッダ及び複数の異なる種類のデータを含むペイロードデータを含むインターネットパケットを通信する、パケット無線ネットワークのサービスサポートノードにおいて、
インターネットプロトコル通信層と、
上記移動ユーザ機器と上記パケット無線ネットワークのゲートウェイサポートノードとの間でユーザデータを通信する仮想通信チャンネルを提供するユーザデータトンネル層とを備え、
当該サービスサポートノードは、上記ゲートウェイサポートノードと協働して、上記移動ユーザ機器からのコンテキストアプリケーション要求データに応答し、
上記ゲートウェイサポートノードと上記ユーザ機器の間で、当該サービスサポートノードを介して、インターネットパケットを通信するための仮想通信チャンネルを確立し、
サービス品質パラメータのそれぞれが、インターネットパケットの異なる種類のデータの１つに必要である、サービス品質パラメータのメインの組を表すデータフィールドと、サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含む上記コンテキストアプリケーション要求データに応答し、
それぞれがインターネットパケットの異なる種類のペイロードデータの１つを通信するために提供され、サービス品質パラメータの組の１つに基づいて、複数の無線アクセスベアラを確立することを特徴とするサービスサポートノード。
【請求項１２】
当該サービスサポートノードは、無線アクセスネットワークアプリケーションパートプロトコル層を備え、ユーザデータトンネル層を介して確立された仮想チャンネルに応じて、
上記無線アクセスネットワークアプリケーションプロトコル層を用いて無線ネットワークコントローラに無線アクセス要求データを送信し、上記サービス品質パラメータの各組に基づいて、該無線ネットワークコントローラの媒体アクセス制御層を用いて、異なる種類の各データについて無線アクセスベアラを確立することを特徴とする請求項１１記載のサービスサポートノード。
【請求項１３】
サービスサポートノードと移動通信ユーザ機器の間で、複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信するパケット無線ネットワークの無線ネットワークコントローラにおいて、
パケットデータを通信する無線リソースを制御する無線リソース層と、
無線アクセスインタフェースを介して上記移動ユーザ機器にパケットデータを通信する無線アクセスベアラを提供する媒体アクセス制御層を制御し、無線アクセス要求データに応答して、無線アクセスネットワークアプリケーションプロトコル層を用いて上記無線リンク制御層を制御し、上記媒体アクセス制御層を用いて、サービス品質パラメータのメインの組に基づいて異なる種類のデータのためのメインの無線アクセスベアラを確立する上記無線リソース層によって制御された、無線リソースを提供する無線リンク制御層とを備え、
上記媒体アクセス制御層において、上記メインの無線アクセスベアラ内で、サブフローとして、異なるデータの各種類について無線アクセスベアラを確立する無線ネットワークコントローラ。
【請求項１４】
複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信する移動体であり、コンテキストアプリケーション要求データを、パケット無線ネットワークのサービスサポートノードに通信するユーザ機器において、
上記コンテキスト要求データは、上記異なる種類のデータを含むインターネットパケットを通信する仮想通信チャンネルの要求を表し、サービス品質パラメータのメインの組を特定するデータフィールドと、上記インターネットパケットのペイロードの異なる種類のデータのために提供され、該サービス品質パラメータの異なる組に提供される少なくとも１つの他の無線アクセスベアラの要求を表す少なくとも１つの他のデータフィールドとを含むことを特徴とするユーザ機器。
【請求項１５】
データプロセッサにロードされて、該データプロセッサに、ゲートウェイサポートノードと、サービスサポートノードと、無線ネットワークコントローラとを含むパケット無線ネットワークを介して、移動体であるユーザ機器に／から、ペイロードデータが複数の異なる種類のデータであるインターネットパケットを通信する通信方法を実行させるコンピュータにより実行可能な命令を提供するコンピュータプログラムにおいて、
上記ユーザ機器に／からインターネットパケットを通信するための無線アクセスベアラを提供する上記無線ネットワークコントローラを用いて、上記ゲートウェイサポートノードと上記移動ユーザ機器との間のインターネットパケットの通信を制御するステップと、
上記ゲートウェイサポートノードと上記移動ユーザ機器との間で異なる種類のデータを含むインターネットパケットを通信する仮想通信チャンネルの要求を表し、それぞれが上記インターネットパケット内の異なる種類のデータのために提供され、サービス品質パラメータのメインの組を特定するデータフィールドと、該サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含むコンテキストアプリケーション要求データを該ゲートウェイサポートノードに通信するステップと、
上記コンテキストアプリケーション要求データに応答して、それぞれがインターネットパケットの異なる種類のペイロードデータを通信するサービス品質パラメータのそれぞれの組の無線アクセスベアラを確立し、仮想通信チャンネルを確立するステップとを有するコンピュータプログラム。
【請求項１６】
コンピュータにより読取可能な媒体に格納されていることを特徴とする請求項１５記載のコンピュータプログラム。
【請求項１７】
移動体であるユーザ機器に／から、ゲートウェイサポートノードを介して、複数の異なる種類のデータを搬送するインターネットパケットを通信するための通信装置において、
上記ユーザ機器と上記ゲートウェイサポートノードとの間でパケットデータを通信するパケットデータ通信手段と、
上記ユーザ機器に／からパケットデータを通信する無線アクセスベアラを提供する無線ネットワークコントローラを用いて、上記移動ユーザ機器間のパケットデータの通信を制御する制御手段と、
上記異なる種類のデータを含むインターネットパケットを通信する仮想通信チャンネルの要求を表し、サービス品質パラメータのメインの組を特定するデータフィールドと、サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含み、該サービス品質パラメータのそれぞれは上記インターネットパケット内の異なる種類のデータに提供されるコンテキストアプリケーション要求データを上記ゲートウェイサポートノードに通信するコンテキストアプリケーション要求データ通信手段と、
上記コンテキストアプリケーション要求データに応答して、上記ゲートウェイサポートノードとユーザ機器の間で、仮想通信チャンネルを確立する仮想通信チャンネル確立手段と、
上記各サービス品質パラメータの組に基づき、それぞれが異なる種類のデータを通信する無線アクセスベアラを確立する無線アクセスベアラ確立手段とを備える通信装置。
【請求項１８】
添付の図面を参照して、実質的に明細書に説明する電気通信システム、ゲートウェイサポートノード、サービスサポートノード、無線ネットワークコントローラ又は移動体であるユーザ機器。
【請求項１９】
添付の図面を参照して、実質的に明細書に説明するインターネットパケットの通信方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【発明の名称】異なる種類のデータを含むインターネットパケットを通信する無線電気通信装置及び方法
【技術分野】
【０００１】
本発明は、移動通信ユーザ機器へ／からインターネットパケットを通信するための機能を提供する電気通信システムに関連する。
【背景技術】
【０００２】
例えば、移動機器のためのグローバルシステム（Global System for Mobiles：以下、ＧＳＭという。）及びユニバーサル移動電話システム（Universal Mobile Telecommunications System：以下、ＵＭＴＳという。）等の移動体無線ネットワークは、回線交換モード又はパケット交換モードでデータを通信するための機能を提供できる。回線交換モードでは、呼の全体に亘る論理的な通信チャンネルに、物理的な通信チャンネルを割り当てる。一方、パケットデータ通信については、汎用パケット無線サービス（General Packet Radio Service：以下、ＧＰＲＳという。）が開発されている。ＧＰＲＳは、例えば、インターネットパケット（ＩＰ）等のパケットデータ通信のためにネットワーク及び無線リソースを最適化することを試みるパケット指向サービスをサポートする。ＧＰＲＳは、移動無線方式の回線交換アーキテクチャに関連する論理アーキテクチャを提供する。
【０００３】
移動通信ユーザ機器（user equipment：以下、ＵＥという。）と、パケットデータ通信ネットワークとの間でデータを通信するためのシステムは、移動通信ネットワークを介して、パケットデータ通信ネットワークとユーザ機器の間でパケットデータを通信するためのインタフェースを提供するゲートウェイＧＰＲＳサポートノード（gateway GPRS support node：以下、ＧＧＳＮという。）と、電気通信ネットワークの無線リソースを制御する無線ネットワークコントローラ（radio network controller、以下、ＲＮＣという。）を用いて、ゲートウェイサポートノードとユーザ機器の間でパケットデータの通信を制御するサービングＧＰＲＳサポートノード（serving GPRS support node：以下、ＳＧＳＮという。）とを備える。パケットデータプロトコル（ＰＤＰ）コンテキスト要求は、ＧＧＳＮとＵＥとの間の通信を実現する仮想通信チャンネルを確立するために用いられる。
【０００４】
パケットデータは、サービス品質（quality of service：以下、ＱｏＳという。）パラメータの単一の組を指定し、無線アクセスベアラは、このＱｏＳパラメータの組に基づいて、ＲＮＣによって提供される。移動通信ネットワークによって提供される、ＵＥとＲＮＣの間でパケットデータを通信するための無線リソースは、貴重なリソース（valuable commodity）であり、例えば、ネットワークの現在の負荷に基づいて、特定の無線アクセスベアラをサポートできるか否かが制約されることもある。したがって、本発明の目的は、可能な限り効率的に無線リソースを利用することである。
【０００５】
欧州特許ＥＰ１０９６７４２Ａには、移動体であるユーザ機器に／からのマルチメディアデータの通信をサポートする無線ネットワークが開示されている。マルチメディアデータは、異なるデータソースからの複数の異なる種類のデータを含む。マルチサービスパケットデータプロトコル（Packet Data Protocol：ＰＤＰ）コンテキストでは、ＰＤＰは、各データソースの１つ以上のＰＤＰアドレスに加入するために用いられる。したがって、マルチサービスＰＤＰコンテキストは、１つ以上のＱｏＳクラスの加入要求のために生成される。これにより、データソースの１つからのデータをユーザ機器に／から通信するために適切なＱｏＳを有するベアラを確立できる。
【０００６】
国際特許出願番号ＷＯ０２／０９８０７７Ａ号には、ＩＰパケットのペイロードから異なるクラスのデータビットを、無線インタフェースを介して通信する移動無線ネットワークが開示されている。異なるクラスを含む各データフレームは、アプリケーション層又はより下位のＩＰ層において、それぞれが異なるクラスのデータを含む、より小さなペイロードフラグメントに分割される。アプリケーション層又はＩＰ層は、対応する処理情報と共にＩＰパケットを生成する。各ＩＰパケットは、パケット無線ネットワークを介してトランスポートされるそれぞれ異なるクラスのデータビットを含む。そして、各ＩＰパケットについて、ペイロードにおいて提供されるデータのクラスに一致するサービス品質を有する無線アクセスベアラが確立される。
【０００７】
【非特許文献１】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：以下、ＳＤＵという。）と呼ばれ、ＰＤＵは、通常、パケットデータ、特にコアネットワーク内のＳＧＳＮ及びＧＧＳＮを指す。
【００２６】
本発明の実施の形態は、無線リソースの利用効率を高めるように、無線アクセスネットワークを介して、ＩＰパケットの形式でデータを通信する機能を提供する。このために、パケットアクセスをサポートする移動体無線ネットワークの一部は、異なるレベルの重要度を有する異なるデータフィールドを特定するように適応化され、データの種類に対応した異なるＱｏＳを提供するサブフローを有する無線アクセスベアラを確立する。これは、ＩＰパケット情報が、例えば、ＡＭＲコーデックによって生成された、音声符号化された情報を搬送する場合、ＵＴＲＡＮは、データの相対的な重要度に一致するように、無線アクセスベアラを適応化する必要があるためである。各無線ベアラは、相対的な重要度及び異なるデータフィールドの特徴に基づいて最適化される。
【００２７】
３ＧＰＰ規格仕様書、３ＧＰＰ ＴＳ２３．１０７（非特許文献３）に定義されているように、現在のところ、会話（Conversational）、ストリーミング（Streaming）、対話（Interactive）、及び背景（Background）クラスと呼ばれる４つの異なるＱｏＳタイプがある。本発明の実施の形態では、それぞれが異なるＱｏＳを提供する複数のサブフローを有する無線ベアラの要求を含むようにＰＤＰコンテキストアクティブ化要求を適応化する。各サブフローについて無線アクセスベアラを提供する一具体例として、各サブフロー無線アクセスベアラに不均一誤り保護（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）である。これは、発呼側と被呼側の間にコネクション型の固定経路を確立する回線交換電話網と大きく異なる点である。このような固定接続は、音声の実時間の低遅延要求をサポートするように設計される。インターネットは、ボイストラヒックではなく、主にデータのために設計された、「ベストエフォート型」の配信ネットワークである。これは、データを配信する際、（例えば、網輻輳、又は雑音によるデータ欠落のため）問題が発生し、又は宛先のホストを見つけることができない場合、パケットが削除されることを意味する。
【００６９】
パケットボイスデータを実時間モードでデジタル信号からアナログ信号に逆変換する場合、会話における不自然な遅延をユーザに感じさせないためには、ボイスパケットのための双方向の遅延は、等しく、通常、３００ミリ秒未満である必要がある。しかしながら、標準の（非ボイス）パケットデータは、ネットワークを介して、送信機と受信機との間でのタイミング構成を考慮することなく非同期通信される場合がある。ボイスパケットは、標準のデータトラヒックに比べて、誤りに対する許容（tolerance）が高い。具体的には、ボイス再生の忠実度に大きく影響することなく、最大５％のボイスパケットデータを欠落させることができる。多くの低ビットレートボイスコーデックによって生成されるボイスパケットのサイズは、非常に短く、通常、１０〜３０バイト程度（期間にして１０〜３０ミリ秒）である。ボイスパケットに添付される典型的なＩＰヘッダは、約２０バイト長である。小さなパケットデータを用いることにより、ルータでの処理遅延を短くできるという利点がある。
【００７０】
ＴＣＰは、誤り検査、データの確認応答、欠落した又は誤まりを含んだデータの再送信、フロー制御管理等のデータ保全動作に関する包括的なサポートを提供するので、インターネット上の殆どのユーザトラヒックは、伝送制御プロトコル（ＴＣＰ）ヘッダと共にトランスポートされる。ここで、包括的なＴＣＰサポート機能により、音声に必要な実時間性能では許容し難い４００〜５００ミリ秒の総合的な遅延が導入される。また、ＴＣＰは、ボイストラヒックに関して、ネットワークが混雑しているときにパケット伝送を遅らせるという、短所がある。このため、ボイストラヒックのために、ユーザデータグラムプロトコル（ＵＤＰ）として知られている異なるプロトコルが用いられている。
【００７１】
ＴＣＰは、接続指向プロトコルであり、これは、何らかのデータをネットワークノード間で伝送する前に、送信装置及び受信装置が協力して、双方向通信チャンネルを確立しなくてはならないことを意味する。次に、ローカルネットワークを介して送信されたデータの各パッケージに対しては、確認応答が返され、送信側の機器は、各データパッケージが誤りなしで受信されたことを確認するために、状態情報を記録する。
【００７２】
対照的に、ＵＤＰは、コネクションレスプロトコルであり、これは、送信側の機器がデータがルーティングされていることを受信装置に通知しないで、一方的にパケットデータを送ることを意味する。受信装置は、各パケットデータを受け取っても、送信側の機器に状態情報を返さない。接続指向プロトコルであるＴＣＰは、ＵＤＰより信頼性が高いが、ＴＣＰによって実行される追加的な誤り検査及びフロー制御のために、処理速度は、ＵＤＰより遅い。更に、ＵＤＰは、ネットワークが混雑している場合であってもパケットを送信し続ける。
【００７３】
図１は、ＶｏＩＰプロトコルスタックの構造を示している。これは、ＶｏＩＰが他のインターネットプロトコルとともに、どのように動作するかを示している。プロトコルスタックは、物理層１１０と、データリンク層１２０と、インターネットプロトコル（ＩＰ）層１３０と、ユーザデータグラムプロトコル（ＵＤＰ）層１４０と、実時間プロトコル（ＲＴＰ）層１５０と、ボイス層１６０とを含む。
【００７４】
物理層１１０は、媒体及び信号物理的側面（例えば、電圧）を定義する。また、物理層１１０は、クロッキング及び同期動作、並びに物理的なコネクタを定義する。データの誤り訂正符号化は、物理層１１０が行う。データリンク層１２０は、１つのデータのリンクを介したトラヒックの転送をサポートする。データリンク層１２０で用いられる特定のプロトコルによって、誤り検出及び再送信を実行できる。ＩＰ層１３０は、パケットデータ（データグラムとも呼ばれる。）をどのように生成し、ネットワークを介してトランスポートするかを決定する。ＩＰ層１３０は、データを送信する場合、一組のタスクを実行し、データを受信する場合、他の一組のタスクを実行する。データの送信時には、ＩＰ層１３０は、宛先アドレスがローカル（すなわち、同じネットワーク内）であるか又はリモートであるかを判定する。ＩＰ層１３０は、ローカルの宛先については、ダイレクト通信を開始し、宛先がリモートにある場合、ゲートウェイ（ルータ）を介して通信する必要がある。宛先ネットワークノードがデータを受信すると、ＩＰ層１３０は、パケットデータが伝送中に破損していないことを確認し、及びデータが正しい宛先に届けられたことを確認する。そして、ＩＰ層１３０は、ＩＰデータグラム内のデータフィールドのコンテンツをチェックし、ソースＩＰが如何なる指示を送ったかを判定する。これらの指示は、通常、例えば、プロトコルスタックの次の上位層、この場合、ＵＤＰ層１４０にデータを供給する等、何らかの動作を実行するための指示である。図３（後述）は、ＩＰデータパケットの構造を示している。
【００７５】
ＵＤＰ層１４０は、主に、ＩＰトラヒックの送信及び受信のためのマルチプレクサ／デマルチプレクサとして機能する。ＵＤＰデータグラムは、宛先ポート番号及びソースポート番号を含んでいる。宛先ポート番号は、ＵＤＰ及び受信装置のオペレーティングシステムによって使用され、適切な受信者（例えば、適切なアプリケーションプログラム）へのトラヒックを提供する。ＵＤＰポート番号及びＩＰアドレスは、結合されて「ソケット」を形成する。連結されたアドレスは、インターネット内で一意的である必要があり、ソケットの対は、各エンドポイント接続を特定する。幾つかのＶｏＩＰのベースの発呼処理プロトコルは、ポート番号へのアクセスなしでは効果的に機能できない。例えば、呼の確立及び分解（tear-down）のために用いられるセッション開始プロトコル（ＳＩＰ）は、特に、アプリケーション間での、パケット通話の間に用いられるポート番号の受け渡しをサポートする。図２（後述）は、ＵＤＰデータパケットの構造を示している。
【００７６】
ＲＴＰ層１５０は、実時間トラヒックをサポートする機能を提供し、すなわち宛先アプリケーションにおいて、実時間での再生を必要とするトラヒックをサポートする。ＲＴＰ層１５０によって提供されるサービスは、ペイロードタイプ識別（例えば、オーディオトラヒック）、シーケンスへの番号付け、タイムスタンピング、配信監視等を含む。ＲＴＰは、基底に存在するネットワークがマルチキャスト配信をサポートしている場合、このマルチキャスト配信を介する複数の宛先へのデータ転送をサポートする。ＲＴＰシーケンス番号により、受信機は、元のパケットシーケンスを再構築することができる。また、シーケンス番号を用いて、パケットの正しい位置を判定することもできる。ＲＴＰは、タイムリな配信を約束し、又は他のＱｏＳ保証を提供するような如何なるメカニズムも有していない。このような保証は、下位の層が担っている。ボイスデータは、原理的には、ＩＰ上に、又はＩＰ上のＵＤＰ上に設けることができるが、技術的に最良の代替例は、図１のプロトコルスタックに示すように、ＩＰ上のＵＤＰ上のＲＴＰ上にボイスを設けることである。
【００７７】
図２は、データグラムヘッダ２５０及びデータペイロード２６０を含むＵＤＰデータグラムの構造を示している。データグラムヘッダ２５０は、４つの１６ビットのフィールドと、ソースポートフィールド２５２と、宛先ポートフィールド２５４と、データ長フィールド２５６と、チェックサムフィールド２５８とを含んでいる。ソースポートフィールド２５２には、通常、送信側の機器の適切なＵＤＰポート番号が格納される。ソースポートフィールド値を用いる場合、受信装置は、ソースポートフィールド値を返信用のアドレスとして用いる。有効なソースポートフィールドを設けるか否かは任意である。宛先ポートフィールド２５４は、データグラムを配信すべき受信装置上のＵＤＰポートアドレスを指定する。データ長フィールド２５６は、ＵＤＰデータグラムの総データ長（ヘッダ及びペイロード）をオクテットで特定する。チェックサムフィールド２５８は、データグラムが伝送中に破損していないことを確認するために用いられる。データペイロード２６０は、可変長である。ＵＤＰでは、最大６４ｋｂｉｔのサイズ（ＩＰによって許可されている最大パケットサイズ）を有するメッセージを送信することができる。データグラムヘッダ２５０は、ＵＤＰポートアドレスのみを含み、ソース又は宛先ＩＰアドレスを含んでいないが、チェックサムデータは、宛先ＩＰアドレス情報を含み、これにより、受信装置は、ＵＤＰデータグラムが誤って配信されたか否かを判断することができる。
【００７８】
図３は、ＩＰデータグラムヘッダ２７０及びデータペイロード２９６を含むＩＰデータグラムの構造を示している。ＩＰデータグラムヘッダ２７０は、４ビット、８ビット、１６ビット又は３２ビットの長さの１２個の個別のフィールドを含んでいる。ソースネットワーク装置（コンピュータ又は移動端末）上のＩＰは、ＩＰデータグラムヘッダ２７０を構築し、宛先におけるＩＰは、ＩＰヘッダのコンテンツを調べ、ＩＰデータグラムのデータペイロードをどう処理したらよいかを判定する。ＩＰヘッダには、ソースホスト及び宛先のホストのＩＰアドレスを含む多くの情報が含まれている。バージョンフィールド２７２は、どのバージョンのＩＰが用いられているかを示す。インターネットプロトコルヘッダ長（Internet header length：ＩＨＬ）フィールド２７４は、３２ビットワード内のＩＰヘッダの長さを特定する４ビットを含んでいる。通常、ヘッダは、２０バイトを含み、この場合、ＩＨＬ値は、５になる。なお、ヘッダ長は、固定ではない。サービスタイプフィールド（type of service field：ＴＯＳ）２７６により、ソースＩＰは、例えば、長い又は短い遅延、通常の又は高いスループット、及び通常の又は高い信頼度等、固有のルーティングを情報に指定することができる。最も低い優先順位０から最も高い優先順位７までの範囲の優先順位値は、データグラムの相対的な重要度を示す。この優先順位値を用いて、ネットワーク内のフロー制御及び輻輳メカニズムが実現され、ルータ、サーバ及びホストノードは、網輻輳が生じている場合、どのような順序でデータグラムを削除するかを決定することができる。全長フィールド２７８は、ＩＰデータグラムの総データ長（すなわち、ヘッダ及びペイロード）をオクテットで指定する。データグラムの可能な最大長は、２１６バイトである。識別フィールド２８０は、ソースＩＰによってＩＰデータグラムに割り当てられた、インクリメントされるシーケンス番号を含んでいる。フラグフィールド２８２は、データのフラグメント化の可能性を示す。「フラグメント不可」（don't fragment：ＤＦ）フラグは、フラグメント化が可能か否かを指定する。「モアフラグメント」（more fragments：ＭＦ）フラグは、関連するデータグラムがフラグメントであることを示す。ＭＦ＝０の場合、更なるフラグメントが存在せず、又はデータが全くフラグメント化されていないことを意味する。フラグメントオフセットフィールド２８４は、ＩＰ宛先において、受け取ったフラグメントを正しい順序で再構築するために用いられる連続したフラグメントのそれぞれに割り当てられた数値である。有効期間フィールド（time to live field）２８６は、秒又はルータホップによって、ＩＰデータグラムが削除されるまでの有効期間を示している。ネットワークをデータグラムが通過する際、各ルータは、このフィールドを調べて、例えば、データグラムがルータ内で遅延した秒数に応じて、このフィールドをデクリメントする。このフィールドがゼロに達すると、データグラムは、削除される。プロトコルフィールド２８８は、ＩＰがデータペイロードを配信するべきプロトコルアドレスを格納する。プロトコルアドレス１は、インターネット制御メッセージプロトコル（ＩＣＭＰ）に対応し、プロトコル���ドレス６は、伝送制御プロトコル（ＴＣＰ）に対応し、プロトコルアドレス１７は、ユーザデータグラムプロトコル（ＵＤＰ）に対応している。ヘッダチェックサムフィールド２９０は、ヘッダの妥当性を確認するために用いられる１６ビット値を含む。ヘッダチェックサム値は、有効期間フィールド２８６がデクリメントされる都度、各ルータで再計算される。チェックは、ユーザデータストリームに対しては行われない。ソースＩＰアドレスフィールド２９２は、応答をソースＩＰに送るために宛先ＩＰによって用いられる。宛先ＩＰアドレスフィールド２９４は、データが正しい宛先に配信されたことを確認するために宛先ＩＰによって用いられる。ＩＰデータペイロードフィールド２９６は、ＴＣＰ又はＵＤＰを宛先とする、例えば数千バイト程度の、可変量のデータを含む。
【図面の簡単な説明】
【００７９】
【図１】ＶｏＩＰプロトコルスタックの構造を示す図である。
【図２】ＵＤＰデータパケットの構造を示す図である。
【図３】ＩＰｖ４データパケットの構造を示す図である。
【図４】パケットデータ通信をサポートするよう構成された移動体無線ネットワークの例示的アーキテクチャを示す図である。
【図５】図４に示すＧＰＲＳをサポートする移動ネットワークを概略的に示す図である。
【図６】３つの異なるカテゴリのボイスデータについて、ＱｏＳパラメータの制御プレーン通信のための構成を示す図である。
【図７】図６に示す構成のための制御プレーン通信シーケンスの例示的動作を説明するフローチャートである。
【図８】図６に示す構成のための制御プレーン通信シーケンスの更なる処理手順を説明するフローチャートである。
【図９Ａ】非特許文献２から引用した、サービス品質（ＱｏＳ）に関連する様々な無線アクセスベアラサービス属性及びこれらに対応するＲＡＢサービス属性値の表を示す図である。
【図９Ｂ】非特許文献２から引用した、サービス品質（ＱｏＳ）に関連する様々な無線アクセスベアラサービス属性及びこれらに対応するＲＡＢサービス属性値の表を示す図である。
【図１０】非特許文献４から引用した、５つの所定の音声コーデックデータフレームタイプのそれぞれの広帯域適応型マルチレート（ＡＭＲ−ＷＢ）ビットフォーマットを列挙する表を示す図である。
【図１１】非特許文献２から引用した、データの相対的な重要度に基づく各ＲＡＢサブフローにおけるビット数の設定例の表を示す図である。
【図１２】単一の無線アクセスベアラについて、ＱｏＳパラメータを指定する既知のＱｏＳ情報要素のデータ構造を示す図である。
【図１３】第１の無線アクセスベアラのＱｏＳパラメータを指定し、及びＵＭＴＳベアラ内のとなるＱｏＳオプションについて、２つの異なるＱｏＳパラメータを指定する更なる任意のデータフィールドを有する本発明に基づくＰＤＰコンテキスト情報要素のデータ構造を示す図である。
【図１４】ＩＰをＵＥと送受するために適応化されたユーザプレーン内のプロトコルスタックを示す図である。
【図１５】ＶｏＩＰ用のＩｕ−ｐｓフレームの構造を示す図である。
【図１６】ＧＧＳＮのユーザプレーンプロトコルスタックによって、パケットデータに対して実行される処理を説明する図である。
【図１７】ＲＮＣのユーザプレーンプロトコルスタックによって、パケットデータ対して実行される処理を説明する図である。