(57)【特許請求の範囲】
【請求項１】
移動ユーザ機器に／から、複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信する移動通信システムにおいて、
パケット無線ネットワークを備え、
上記パケット無線ネットワークは、
ゲートウェイサポートノードと、
サービングサポートノードと、
無線ネットワーク制御装置とを有し、
上記ゲートウェイサポートノードは、上記移動ユーザ機器と上記パケット無線ネットワーク間で上記インターネットパケットを通信するインタフェースを提供し、
上記サービングサポートノードは、上記ゲートウェイサポートノードと上記移動ユーザ機器間のインターネットパケットの通信を、上記無線ネットワーク制御装置を用いて制御し、
上記無線ネットワーク制御装置は、上記移動ユーザ機器に／から、上記インターネットパケットを通信するための無線アクセスベアラを提供し、
上記ゲートウェイサポートノードは、上記サービングサポートノードと協働して、上記異なる種類のデータを含むインターネットパケットを通信する仮想通信チャンネルの要求を表す上記移動ユーザ機器からのコンテキストアプリケーション要求データに応答して、当該ゲートウェイサポートノードと該移動ユーザ機器間に、該サービングサポートノードを介して該仮想通信チャンネルを確立し、
上記コンテキストアプリケーション要求データは、各組が上記インターネットパケットの異なる種類のデータのそれぞれに対して提供されるサービス品質パラメータのメインの組を指定するデータフィールドと、該サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含み、
上記仮想通信チャンネルは、上記ゲートウェイサポートノードと上記サービングサポートノード間で上記インターネットパケットを通信するためのベアラと、該インターネットパケットの異なる種類のペイロードデータのそれぞれに対して提供される複数の無線アクセスベアラとを含み、
上記無線アクセスベアラのそれぞれは、上記コンテキストアプリケーション要求データによって指定される異なる種類のデータのサービス品質パラメータのメインの組及び他の組のうちの１つを提供することを特徴とする移動通信システム。
【請求項２】
上記サービングサポートノードは、上記仮想通信チャンネルの確立に応答して、無線アクセス要求データを、無線アクセスネットワークアプリケーションパートプロトコルに基づいて上記無線ネットワーク制御装置に通信し、
上記無線ネットワーク制御装置は、無線リソース制御層と協働して、媒体アクセス制御層を用いて、上記異なる種類のデータに指定される上記複数のサービス品質パラメータのそれぞれに対して、上記複数の無線アクセスベアラのうちの１つを確立することを特徴とする請求項１記載の移動通信システム。
【請求項３】
上記無線リソース制御層は、
上記無線アクセスベアラを、上記媒体アクセス制御層のメインのサービス品質パラメータに基づいて、メインの無線アクセスベアラとして確立し、
上記異なる種類のデータのそれぞれに対する無線アクセスベアラを、上記媒体アクセス制御層の上記メインの無線アクセスベアラ内のサブフローとして確立することを特徴とする請求項２記載の移動通信システム。
【請求項４】
上記インターネットパケットのペイロードデータは、適応マルチレート音声コーデックによって生成され、上記複数の異なる種類のデータを提供するデータフレームを含むことを特徴とする請求項１乃至３いずれか１項記載の移動通信システム。
【請求項５】
上記移動ユーザ機器は、パケットデータプロトコルコンテキスト起動手順に基づいて、上記コンテキストアプリケーション要求データを上記ゲートウェイサポートノードに通信することを特徴とする請求項１乃至４いずれか１項記載の移動通信システム。
【請求項６】
複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを、ゲートウェイサポートノードと、サービングサポートノードと、無線ネットワーク制御装置とを含むパケット無線ネットワークを介して、移動ユーザ機器に／から通信する移動通信方法において、
上記ゲートウェイサポートノードと上記移動ユーザ機器間のインターネットパケットの通信であって、該移動ユーザ機器に／から該インターネットパケットを通信するための無線アクセスベアラを提供する上記無線ネットワーク制御装置を用いた該インターネットパケットの通信を、上記パケット無線ネットワークの上記サービングサポートノードを用いて制御するステップと、
上記異なる種類のデータを含むインターネットパケットを上記パケット無線ネットワークを介して通信する仮想通信チャンネルの要求を表すとともに、各組が該インターネットパケットの異なる種類のデータのそれぞれに対して提供されるサービス品質パラメータのメインの組を指定するデータフィールドと、該サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含むコンテキストアプリケーション要求データを、上記ゲートウェイサポートノードに通信するステップと、
上記コンテキストアプリケーション要求データに応答して、上記ゲートウェイサポートノードと上記移動ユーザ機器間に、上記インターネットパケットを通信する仮想通信チャンネルを確立するステップとを有し、
上記仮想通信チャンネルを確立するステップは、上記サービス品質パラメータの各組に基づいて、上記インターネットパケットの異なる種類のペイロードデータのそれぞれを通信するために提供される複数の無線アクセスベアラを確立するステップを含むことを特徴とする移動通信方法。
【請求項７】
上記仮想通信チャンネルを確立するステップは、
無線アクセスネットワークアプリケーションパートプロトコルに基づいて、無線アクセス要求データを上記無線ネットワーク制御装置に通信するステップと、
上記無線ネットワーク制御装置の媒体アクセス制御層を用いて、上記異なる種類のデータの上記複数のサービス品質パラメータのそれぞれに対して、無線アクセスベアラを確立するステップとを有することを特徴する請求項６記載の移動通信方法。
【請求項８】
上記媒体アクセス制御層を用いるステップは、
上記媒体アクセス制御層のメインのサービス品質パラメータに基づいて、メインの無線アクセスベアラを確立するステップと、
上記異なる種類のデータのそれぞれに対する無線アクセスベアラを、上記媒体アクセス制御層の上記メインの無線アクセスベアラ内のサブフローとして確立するステップとを有することを特徴とする請求項７記載の移動通信方法。
【請求項９】
上記インターネットパケットのペイロードデータは、適応マルチレート音声符号化によって生成され、上記複数の異なる種類のデータを提供するデータフレームを含むことを特徴とする請求項６乃至８いずれか１項記載の移動通信方法。
【請求項１０】
上記コンテキストアプリケーション要求データは、パケットデータプロトコルコンテキスト起動手順に基づいて通信されることを特徴とする請求項６乃至９いずれか１項記載の移動通信方法。
【請求項１１】
移動ユーザ機器に／から、ヘッダ及び複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信するパケット無線ネットワークのサービングサポートノードにおいて、
インターネットプロトコル通信層と、
上記移動ユーザ機器と上記パケット無線ネットワークのゲートウェイサポートノード間でユーザデータを通信する仮想通信チャンネルを提供するユーザデータトンネル層とを備え、
上記ゲートウェイサポートノードと協働して、上記移動ユーザ機器からのコンテキストアプリケーション要求データに応答し、
上記ゲートウェイサポートノードと上記移動ユーザ機器間に、当該サービングサポートノードを介して、インターネットパケットを通信する上記仮想通信チャンネルを確立し、
各組が上記インターネットパケットの異なる種類のデータのそれぞれに必要なサービス品質パラメータのメインの組を表すデータフィールドと、該サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含む上記コンテキストアプリケーション要求データに応答し、
上記サービス品質パラメータの複数の組のそれぞれに基づいて、上記インターネットパケットの異なる種類のペイロードデータのそれぞれに対して提供される複数の無線アクセスベアラを確立することを特徴とするサービングサポートノード。
【請求項１２】
無線アクセスネットワークアプリケーションパートプロトコル層を更に備え、
上記無線アクセスネットワークアプリケーションパートプロトコル層において、上記ユーザデータトンネル層による上記仮想通信チャンネルの確立に応答し、
無線アクセス要求データを、上記無線アクセスネットワークアプリケーションパートプロトコル層を用いて無線ネットワーク制御装置に通信し、該無線ネットワーク制御装置の媒体アクセス制御層を用いて、上記サービス品質パラメータの各組に基づく異なる種類のデータのそれぞれに対する無線アクセスベアラを確立することを特徴とする請求項１１記載のサービングサポートノード。
【請求項１３】
サービングサポートノードと移動通信ユーザ機器間で、複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信するパケット無線ネットワークの無線ネットワーク制御装置において、
上記インターネットパケットを通信する無線リソースを制御する無線リソース層と、
上記インターネットパケットを、無線アクセスインタフェースを介して上記移動通信ユーザ機器に通信するための無線アクセスベアラを提供する媒体アクセス制御層を制御するとともに、上記無線リソース層によって制御された無線リソースを提供する無線リンク制御層とを備え、
上記無線リソース層は、
無線アクセス要求データに応答し、無線アクセスネットワークアプリケーションパートプロトコル層を用いて上記無線リンク制御層を制御し、上記媒体アクセス制御層を用いて、サービス品質パラメータのメインの組に基づく異なる種類のデータのうちの１つのメインの無線アクセスベアラを確立し、
上記異なる種類のデータのそれぞれに対する無線アクセスベアラを、上記媒体アクセス制御層の上記メインの無線アクセスベアラ内のサブフローとして確立することを特徴する無線ネットワーク制御装置。
【請求項１４】
複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信する移動ユーザ機器において、
上記異なる種類のデータを含むインターネットパケットを通信する仮想通信チャンネルの要求を表すコンテキストアプリケーション要求データを、パケット無線ネットワークのサービングサポートノードに通信する手段を備え、
上記コンテキストアプリケーション要求データは、サービス品質パラメータのメインの組を指定するデータフィールドと、異なるサービス品質パラメータを提供するための少なくとも１つの他の無線アクセスベアラの要求を表す少なくとも１つの他のデータフィールドとを含み、
上記他の無線アクセスベアラのそれぞれは、上記インターネットパケットのペイロードの異なる種類のデータに対して提供されることを特徴とする移動ユーザ機器。
【請求項１５】
データプロセッサにロードされて、該データプロセッサに、ゲートウェイサポートノードと、サービングサポートノードと、無線ネットワーク制御装置とを含むパケット無線ネットワークを介して、移動ユーザ機器に／から、複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信する移動通信方法を実行させるコンピュータにより実行可能な命令を提供するコンピュータプログラムにおいて、
上記移動通信方法は、
上記ゲートウェイサポートノードと上記移動ユーザ機器間のインターネットパケットの通信であって、該移動ユーザ機器に／から該インターネットパケットを通信するための無線アクセスベアラを提供する上記無線ネットワーク制御装置を用いた該インターネットパケットの通信を、上記パケット無線ネットワークの上記サービングサポートノードを用いて制御するステップと、
上記異なる種類のデータを含むインターネットパケットを上記パケット無線ネットワークを介して通信する仮想通信チャンネルの要求を表すとともに、各組が該インターネットパケットの異なる種類のデータのそれぞれに対して提供されるサービス品質パラメータのメインの組を指定するデータフィールドと、該サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含むコンテキストアプリケーション要求データを、上記ゲートウェイサポートノードに通信するステップと、
上記コンテキストアプリケーション要求データに応答して、上記ゲートウェイサポートノードと上記移動ユーザ機器間に、上記インターネットパケットを通信する仮想通信チャンネルを確立するステップとを有し、
仮想通信チャンネルを確立するステップは、上記サービス品質パラメータの各組に基づいて、上記インターネットパケットの異なる種類のペイロードデータのそれぞれを通信するために提供される複数の無線アクセスベアラを確立するステップを含むことを特徴するコンピュータプログラム。
【請求項１６】
コンピュータにより読取可能な媒体に格納されていることを特徴とする請求項１５記載のコンピュータプログラム。
【請求項１７】
移動ユーザ機器に／からゲートウェイサポートノードを介して、複数の異なる種類のデータを搬送するインターネットパケットを通信する移動通信装置において、
上記移動ユーザ機器と上記ゲートウェイサポートノード間で上記インターネットパケットを通信するパケットデータ通信手段と、
上記移動ユーザ機器と上記ゲートウェイサポートノード間のインターネットパケットの通信を、上記移動ユーザ機器に／からインターネットパケットを通信するための無線アクセスベアラを提供する無線ネットワーク制御装置を用いて制御する制御手段と、
上記異なる種類のデータを含むインターネットパケットを通信する仮想通信チャンネルの要求を表すとともに、各組が該インターネットパケットの異なる種類のデータのそれぞれに対して提供されるサービス品質パラメータのメインの組を指定するデータフィールドと、該サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含むコンテキストアプリケーション要求データを、上記ゲートウェイサポートノードに通信するコンテキストアプリケーション要求データ通信手段と、
上記コンテキストアプリケーション要求データに応答して、上記ゲートウェイサポートノードと上記移動ユーザ機器間に、仮想通信チャンネルを確立する仮想通信チャンネル確立手段と、
上記サービス品質パラメータの各組に基づいて、上記異なる種類のデータを通信するための無線アクセスベアラを確立する無線アクセスベアラ確立手段とを備える移動通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信ユーザ機器（mobile communications user equipment）に／からインターネットパケットを通信する機能を提供する移動通信システムに関連する。
【背景技術】
【０００２】
移動無線ネットワーク（Mobile radio networks）、例えばＧＭＳ（Global System for Mobiles communications：第２世代デジタル移動通信システム）及びＵＭＴＳ（Universal Mobile Telecommunications System：第３世代デジタル移動通信システム）は、回線交換モード又はパケット交換モードでデータを通信する機能を提供することができる。回線交換モードでは、物理通信チャンネルを、呼が通る論理通信チャンネルに割り当てる。一方、データパケットの通信については、汎用パケット無線サービス（General Packet Radio Service：以下、ＧＰＲＳという。）が開発されている。ＧＰＲＳは、例えばインターネットパケット（ＩＰ）等のパケットデータ通信用のネットワーク及び無線リソースを最適化することを試みるパケット指向サービスをサポートしている。ＧＰＲＳは、移動無線システムの回線交換アーキテクチャに関連する論理アーキテクチャを提供する。
【０００３】
移動通信ユーザ機器（mobile communications user equipment：以下、ＵＥという。）とパケットデータネットワーク（packet data network）間でデータを通信するシステムは、パケットデータネットワークとユーザ機器間で移動通信ネットワークを介してデータパケットを通信するためのインタフェースを提供するゲートウェイＧＰＲＳサポートノード（gateway GPRS support node：以下、ＧＧＳＮという。）と、移動通信ネットワークの無線リソースを制御する無線ネットワーク制御装置（radio network controller、以下、ＲＮＣという。）を用いて、ゲートウェイサポートノードとユーザ機器間のデータパケットの通信を制御するサービングＧＰＲＳサポートノード（serving GPRS support node：以下、ＳＧＳＮという。）とを備える。パケットデータプロトコル（Packet Data Protocol：以下、ＰＤＰという。）コンテキスト要求は、ＧＧＳＮとＵＥ間の通信を可能にする仮想通信チャンネルを確立するために用いられる。
【０００４】
各データパケットは、サービス品質（quality of service：以下、ＱｏＳという。）パラメータの１つの組を指定し、無線アクセスベアラは、このＱｏＳパラメータの組に基づいて、ＲＮＣによって供給される。移動通信ネットワークによって提供される、ＵＥとＲＮＣ間でデータパケットを通信するための無線リソースは、貴重なリソース（valuable commodity）であり、例えば、ネットワークの現在の負荷に基づいて、特定の無線アクセスベアラをサポートできるか否かが制約されることもある。したがって、本発明の目的は、可能な限り効率的に無線リソースを利用することである。
【０００５】
欧州特許ＥＰ１０９６７４２Ａには、移動ユーザ機器に／からのマルチメディアデータの通信をサポートする無線ネットワークが開示されている。マルチメディアデータは、異なるデータ送信元からの複数の異なる種類のデータを含んでいる。マルチサービスパケットデータプロトコル（ＰＤＰ）コンテキストでは、ＰＤＰは、各データ送信元の１つ以上のＰＤＰアドレスに加入するために用いられる。したがって、マルチサービスＰＤＰコンテキストは、１つ以上のＱｏＳクラスの加入要求のために生成される。これにより、データ送信元の１つからのデータをユーザ機器に／から通信するのに適したＱｏＳを有するベアラを、確立することができる。
【０００６】
国際特許出願番号ＷＯ０２／０９８０７７Ａには、ＩＰパケットのペイロードから異なるクラスのデータビットを、無線インタフェースを介して通信する移動無線通信ネットワークが開示されている。異なるクラスを含む各データフレームは、アプリケーション層又はより下位のＩＰ層において、それぞれが異なるクラスのデータを含むより小さなペイロード断片に分割される。そして、アプリケーション層又はＩＰ層は、対応する処理情報と共にＩＰパケットを生成する。各ＩＰパケットは、パケット無線ネットワークを介して転送されるそれぞれ異なるクラスのデータビットを含んでいる。各ＩＰパケットに対して、ペイロードにおいて提供されるデータのクラスに一致するサービス品質を有する無線アクセスベアラが確立される。
【０００７】
【非特許文献１】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
【発明の開示】
【発明が解決しようとする課題】
【０００８】
移動通信ユーザ機器（ＵＥ）とパケットデータネットワーク間でデータを通信するシステムは、パケットデータネットワークとＧＰＲＳ／ＵＭＴＳ間で移動通信ネットワークを介してデータパケットを通信するためのインタフェースを提供するゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）と、移動通信ネットワークの無線リソースを制御する無線ネットワーク制御装置（ＲＮＣ）を用いて、ゲートウェイサポートノードとユーザ機器間のデータパケットの通信を制御するサービングＧＰＲＳサポートノード（ＳＧＳＮ）とを備える。パケットデータプロトコル（ＰＤＰ）コンテキスト要求は、ＧＧＳＮとＵＥ間の通信を可能にする仮想通信チャンネルを確立するために用いられる。各データパケットは、サービス品質（ＱｏＳ）パラメータの１つの組を指定し、無線アクセスベアラは、このサービス品質パラメータの組に基づいて、ＲＮＣによって供給される。移動通信ネットワークによって提供される、ＵＥとＲＮＣ間でデータパケットを通信するための無線リソースは、貴重なリソースであり、例えば、ネットワークの現在の負荷に基づいて、特定の無線アクセスベアラをサポートできるか否かが制約されることもある。したがって、本発明の目的は、可能な限り効率的に無線リソースを利用することである。
【課題を解決するための手段】
【０００９】
本発明に係る移動通信システムは、移動ユーザ機器に／から、複数の異なる種類のデータからなるペイロードデータを有するインターネットパケットを通信する電気通信システムにおいて、パケット無線ネットワークを備え、上記パケット無線ネットワークは、ゲートウェイサポートノードと、サービングサポートノードと、無線ネットワーク制御装置とを有し、上記ゲートウェイサポートノードは、上記移動ユーザ機器と上記パケット無線ネットワーク間で上記インターネットパケットを通信するインタフェースを提供し、上記サービングサポートノードは、上記ゲートウェイサポートノードと上記移動ユーザ機器間のインターネットパケットの通信を、上記無線ネットワーク制御装置を用いて制御し、上記無線ネットワーク制御装置は、上記移動ユーザ機器に／から、上記インターネットパケットを通信するための無線アクセスベアラを提供し、上記ゲートウェイサポートノードは、上記サービングサポートノードと協働して、上記異なる種類のデータを含むインターネットパケットを通信する仮想通信チャンネルの要求を表す上記移動ユーザ機器からのコンテキストアプリケーション要求データに応答して、当該ゲートウェイサポートノードと該移動ユーザ機器間に、該サービングサポートノードを介して該仮想通信チャンネルを確立し、上記コンテキストアプリケーション要求データは、各組が上記インターネットパケットの異なる種類のデータのそれぞれに対して提供されるサービス品質パラメータのメインの組を指定するデータフィールドと、該サービス品質パラメータの異なる組の要求を表す少なくとも１つの他のデータフィールドとを含み、上記仮想通信チャンネルは、上記ゲートウェイサポートノードと上記サービングサポートノード間で上記インターネットパケットを通信するためのベアラと、該インターネットパケットの異なる種類のペイロードデータのそれぞれに対して提供される複数の無線アクセスベアラとを含み、上記無線アクセスベアラのそれぞれは、上記コンテキストアプリケーション要求データによって指定される異なる種類のデータのサービス品質パラメータのメインの組及び他の組のうちの１つを提供する。
【００１０】
特定のサービス品質（ＱｏＳ）を提供する従来のシステムは、同じサービス品質パラメータに基づいて、データパケットの全てのペイロードを送信する無線アクセスベアラを設定するという点において、柔軟性が低い。このため、データパケットのペイロードが、異なるＱｏＳ要求を有し及び／又は重要度が等しくない異なる種類のデータを含むとき、無線リソースを効率的に利用することができなかった。
【００１１】
本発明の実施の形態では、データパケット、例えばインターネットプロトコルのデータパケット内で異なる種類のデータをサポートする無線アクセスベアラを提供する。無線アクセスベアラは、各データの種類毎に提供される。各無線アクセスベアラによってサポートされるサービス品質パラメータは、各異なるデータの種類の特性及び／又は重要度に適応化することができる。このように、無線ネットワークによって提供される無線リソースをより効率的に利用することができる。
【００１２】
幾つかの実施の形態では、各異なるデータの種類のための無線アクセスベアラは、サービス品質パラメータのメインの組に基づくメインの無線アクセスベアラ内のサブフローとして提供される。したがって、例えば、ＧＰＲＳ等の既存のネットワークアーキテクチャのために開発された無線ネットワーク制御装置を実質的に変更する必要はない。
【００１３】
本発明の様々な更なる特徴及び機能は、特許請求の範囲で定義されており、複数の異なる種類のデータを搬送するインターネットパケットを通信する通信方法、サービングサポートノード、無線ネットワークコントローラ及び移動ユーザ機器が含まれる。
【発明を実施するための最良の形態】
【００１４】
ボイスオーバＩＰ
ボイスオーバＩＰ（Voice over IP：以下、ＶｏＩＰという。）は、公衆交換電話網（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：以下、ＨＬＲという。）３１０にアクセスする。ＳＧＳＮ３０６は、データパケットを無線ネットワーク制御装置（ＲＮＣ）３１２、３１４にルーティングし、ＲＮＣ３１２、３１４は、ＵＴＲＡＮ無線アクセス機能によって、移動ユーザ機器（以下、ＵＥという。）３１６、３１８と通信する。このＵＴＲＡＮ無線アクセス機能は、ノードＢ装置３２０、３２２、３２４、３２６、３２８によって提供され、これらのノードＢ装置３２０、３２２、３２４、３２６、３２８は、移動無線通信ネットワークによって提供される範囲のサービスエリア（radio coverage）を有する基地局を構成している。ＲＮＣ３１２、３１４とノードＢ装置３２０、３２２、３２４、３２６、３２８間のＩｕｂの符号を付したインタフェース３３０、３３２、３３４、３３６、３３８は、制定された又は開発中の規格に準拠している。一方、ＳＧＳＮ３０６とＲＮＣ３１２、３１４間のＩｕ−ｐｓの符号を付したインタフェース３４０、３４２は、開発中の規格に準拠している。
【００２１】
重要度が異なるデータの通信
本発明の実施の形態は、ある意味では、ＩＰパケットのペイロード内のデータの重要度に応じて無線リソースを最適化することを試みるＵＥ３１６、３１８に／からのデータを、ＩＰパケットの形で通信する機能を提供する。ＩＰパケット内で通信されるデータは、重要度が等しくない異なるパラメータ又はフィールドを有する部分（sections）を含むことができる。重要度が等しくないフィールドを有するデータの一具体例としては、音声符号化フレーム、例えば適応マルチレート（Adaptive Multi-Rate：以下、ＡＭＲという。）音声コーデックによって生成されたデータがある。
【００２２】
ＡＭＲ音声コーデックは、異なる種類の特性を有し、及び／又は重要度が等しくない、異なる種類のデータのフィールドを含む所定の長さのデータフレームを生成することが知られている。このような音声コーデックの具体例は、欧州電気通信標準化機構（European Telecommunications Standards Institute：以下、ＥＴＳＩという。）によって標準化され、３ＧＰＰによって異なるレートに指定されているＡＭＲ音声コーデックとして知られている（非特許文献２参照）。ＡＭＲ音声コーデックは、Ａビット、Ｂビット、Ｃビットと呼ばれる異なる重要度を有する最大３個のデータフィールドを有するデータフレームを生成する。Ａビットは、音声を理解できる程度の基本レベルの音声情報を提供するが、話者を識別するのに十分なレベルの忠実度は有していない。Ｂビット及びＣビットは、更に高いレベルの忠実度を有する。ここで、Ａビット、Ｂビット及びＣビットの数は、データフィールドを通信するために利用可能な無線リソースに基づいて適応化することができる。このように、異なるフィールドのそれぞれに異なるサービス品質（ＱｏＳ）を適用することができ、このようなフィールドの具体例として、ＵＭＴＳ用の広帯域ＡＭＲ（wideband AMR：以下、ＡＭＲ−ＷＢという。）符号化フレームが、非特許文献２に記載されている。ＡＭＲ−ＷＢでは、広帯域ＵＭＴＳを介して通信できるデータの容量が制限されているため、Ｃビットは使用されていない。
【００２３】
ＡＭＲデータフレームの３つのフィールドのそれぞれにおけるデータビット数を決定するために、回線交換移動体ネットワーク（circuit switched mobile network）の移動交換機（Mobile Switching Centre）は、無線アクセスベアラサブフローコンビネーションインディケータ（Radio Access Bearer sub-Flow Combination Indicator：以下、ＲＦＣＩという。）を生成することが知られている。したがって、パケットベースの移動無線通信ネットワークには、対応するＲＦＣＩが必要である。本発明の実施の形態として後述するように、ＩＰパケットによって搬送されるＡＭＲデータフレームに対して、ＧＧＳＮは、ＡＭＲフレームの異なるフィールドのデータビットを識別して、適切なＲＦＣＩを与えなければならない。
【００２４】
図５は、図４に示すＧＰＲＳをサポートする移動無線通信ネットワークの構成を概略的に示している。図５に示す構成は、本発明の実施の形態に基づき、ＩＰパケットを介して、重要度が等しくないフィールドを含むペイロードデータを通信するピアツーピア通信パスを提供する。ＩＰパケットは、図４に示す移動無線通信ネットワークのＧＧＳＮ３００、ＳＧＳＮ３０６及びＲＮＣ３１４を介して、ＵＥ３５０、３５２間で通信される。図５に示すように、ＲＮＣ３１４とＵＥ３５０間をＩＰパケットによって搬送されるデータは、ＡＭＲ音声符号化データフレームのＡ、Ｂ及びＣの３つのフィールドを含んでいる。
【００２５】
ＧＧＳＮ３００及びＳＧＳＮ３０６内のプロトコルに関して、ＵＥ３５０に送信され、及びＵＥ３５０から受信されるＩＰパケットは、パケットデータユニット（Packet Data Unit：以下、ＰＤＵという。）を形成している。ＰＤＵの形式は、ＧＧＳＮ３００、ＳＧＳＮ３０６、ＲＮＣ３１４及びノードＢ装置内のプロトコルに知られていなければならない。ＰＤＵは、ＧＰＲＳネットワーク内で通信されるパケットの形式を指す総称用語である。なお、ＰＤＵは、ＵＴＲＡＮの無線リンク制御（Radio Link Control：以下、ＲＬＣという。）層に通信されるデータパケットについて言及するときは、サービスデータユニット（Service Data Unit：以下、ＳＤＵという。）と呼ばれ、一方、ＰＤＵは、通常、データパケットを、特にコアネットワーク内のＳＧＳＮ３０６及びＧＧＳＮ３００に供給するために用いられる。
【００２６】
本発明の実施の形態は、無線リソースの利用効率を高めて、データを、無線アクセスネットワークを介してＩＰパケットの形で通信する機能を提供する。このために、パケットアクセスをサポートする移動無線通信ネットワークの一部は、異なるレベルの重要度を有する異なるデータフィールドを識別し、データの種類に一致した異なるＱｏＳを提供するサブフローを有する無線アクセスベアラを確立するように改造されている。これは、ＩＰパケットが、音声符号化情報、例えばＡＭＲ音声コーデックによって生成された情報を搬送するとき、ＵＴＲＡＮは、データの相対的重要度に一致した無線アクセスベアラを使用する必要があるためである。各無線アクセスベアラは、異なるデータフィールドの相対的重要度及び特性に基づいて最適化される。
【００２７】
３ＧＰＰ規格仕様書、３ＧＰＰ ＴＳ２３．１０７（非特許文献３）に定義されているように、現在のところ、会話（Conversational）クラスと、ストリーミング（Streaming）クラスと、対話（Interactive）クラスと、背景（Background）クラスと呼ばれる４つの異なるＱｏＳタイプがある。本発明の実施の形態では、それぞれが異なるＱｏＳを提供する複数のサブフローを有する無線アクセスベアラの要求を含むようにＰＤＰコンテキスト起動要求（PDP context activation request）を適応化する。各サブフローに対して無線アクセスベアラをどのように提供するかの一具体例として、各サブフロー無線アクセスベアラに不均一誤り保護（Un-equal Error Protection：以下、ＵＥＰという。）を提供してもよい。これについては、以下でより更に詳細に説明する。
【００２８】
ＰＤＰコンテキスト起動
図６は、３つの異なる種類の音声データに対するＱｏＳパラメータの制御プレーン通信（control plane communication）の構成を示している。この構成は、ユーザ機器（ＵＥ）３５２と、無線ネットワーク制御装置（ＲＮＣ）３１４と、サービング汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＳＧＳＮ）３０６と、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）３００とを備える。
【００２９】
ＵＥ３５２は、少なくとも１つのＵＭＴＳ加入者識別モジュールを有する移動機器の１つである。ＵＭＴＳセッションマネージャ４１２と呼ばれるアプリケーションは、無線リソースにアクセスするために、ＳＧＳＮ３０６と交渉する役割を果たす。このアクセスは、パケットデータプロトコル（Packet Data Protocol：以下、ＰＤＰという。）を用いて調停される。ユーザがデータを転送できるようにするために、ＵＥ３５２、ＳＧＳＮ３０６及びＧＧＳＮ３００において「ＰＤＰコンテキスト」を起動しなければならない。ＰＤＰコンテキストの起動は、要求された宛先ネットワークへのログオンに類する処理であり、ユーザ機器３５２上のアプリケーションによって開始される。
【００３０】
無線ネットワーク制御装置（Radio Network Controller：以下、ＲＮＣという。）３１４は、無線リソースの使用及び完全性を制御する。ＲＮＣ３１４は、無線リソース制御（Radio Resource Control：以下、ＲＲＣという。）層４２２と、無線リンク制御（Radio Link Control：以下、ＲＬＣという。）層４２４と、媒体アクセス制御（Media Access Control：以下、ＭＡＣという。）層４２６と、物理層４２８との４つの異なる層に分割することができる機能を備える。
【００３１】
ＲＲＣ層４２２は、制御プレーンにおいてＳＧＳＮ３０６と交渉し、ＳＧＳＮ３０６からの無線アクセスベアラ（ＲＡＢ）設定要求に基づいて、無線リソースに対するアクセスを確立する。ＲＬＣ層４２４は、制御データを通過させるのではなく、ユーザデータ用の接続を設定する。ＭＡＣ層４２６は、各データフローのデータをどのように伝送するかを決定する。例えば、ＭＡＣ層４２６は、データフローのために、専用チャンネル又は共有チャンネル（帯域幅の消費量が少ない）を割り当てて、管理する役割を果たす。無線アクセスベアラ（ＲＡＢ）サブフローは、ＭＡＣ層４２６によって割り当てられる。物理層４２８は、データを、伝送媒体に渡す電子パルス又はアナログパルスのストリームに変換し、データ伝送を監視する役割を果たす。物理層４２８は、例えば、適切な誤り訂正符号を発信データストリームに適用する役割を果たす。例えば、物理層４２８は、ＭＡＣ層４２６によって定義されたＲＡＢサブフローのそれぞれに対して、異なる誤り訂正符号化レベルを適用することができる。
【００３２】
ＳＧＳＮ３０６は、ＵＥ３５２から、ユーザアプリケーションによって要求された所望のデータリンクのためのＱｏＳを指定するＰＤＰコンテキスト起動要求メッセージを、受信する。ＳＧＳＮ３０６は、指定されたＱｏＳパラメータに基づいて、ＲＮＣ３１４と無線アクセスベアラについて交渉する。ＳＧＳＮ３０６は、関連する登録された各加入者のパケット交換サービスに関する加入者情報（subscription information）及び位置情報（location information）を保存する。ＱｏＳ情報は、無線アクセスネットワークアプリケーションパート（Radio Access Network Application Part：以下、ＲＡＮＡＰという。）プロトコルと呼ばれる信号プロトコルを用いて、ＳＧＳＮ３０６からＲＮＣ３１４に通信される。
【００３３】
ＲＡＮＡＰプロトコルは、コアネットワーク（すなわちＳＧＳＮ３０６）とＵＴＲＡＮ間のインタフェース用の無線ネットワーク層の信号プロトコルである。ＵＴＲＡＮは、ＵＭＴＳネットワークの一部であり、ＲＮＣ３１４と、ノードＢ装置とを備える。ＲＡＮＡＰプロトコルは、ＲＮＣ３１４とＳＧＳＮ３０６間のパケット交換データのためのシグナリングを処理する。また、ＲＡＮＡＰプロトコルは、ＲＮＣ３１４と移動交換機（図示せず）間の回線交換データのためのシグナリングも処理することができる。ＲＡＮＡＰプロトコルが実行できる汎用機能としては、コアネットワークからの汎用ＵＴＲＡＮ手順（general UTRAN procedures）、例えばページング（paging）を容易にする機能と、移動体固有のシグナリング管理のために、プロトコルレベル上で各ＵＥを分離する機能と、非アクセスシグナリング（non-access signalling）を転送する機能と、サービング無線ネットワークサブシステムリロケーション（Serving Radio Network Subsystem Relocation）を実行する機能と、様々な種類のＵＴＲＡＮ無線アクセスベアラ（ＲＡＢ）を要求し、管理する機能とがある。ＳＧＳＮ３０６は、本発明に基づくＲＡＮＡＰプロトコルを用いて、ＰＤＰコンテキスト起動要求に含まれているＱｏＳデータに基づいて、ＲＮＣ３１４の無線アクセスベアラサブフロー（Radio Access Bearer sub-flows）の確立を要求する。
【００３４】
ＧＧＳＮ３００は、ＵＭＴＳ無線パケットバックボーンと、外部のパケットデータネットワーク３０２との間のＧｉインタフェース３０４として機能し、すなわち、データネットワークとＩＰネットワーク間のインタフェースを提供する。Ｇｉインタフェース３０４を介して、ＧＧＳＮ３００によって受信されたパケットは、対応するＳＧＳＮ３０６に転送される。このために、ＧＧＳＮ３００は、ユーザプロファイルの現在のＳＧＳＮアドレスをロケーションレジスタに保存する。また、ＧＧＳＮ３００は、少なくとも１つのアクティブなＰＤＰコンテキストを有する各加入者の加入者情報及び経路情報（routing information）を保存する。
【００３５】
図６に示す構成における制御プレーン通信シーケンスの例示的な動作のフローチャートを図７に示す。ステップ５１０において、ＵＥ３５２のユーザアプリケーションは、ＵＭＴＳセッションマネージャ４１２を介して、ＰＤＰコンテキスト起動要求（PDP context request activation）を開始する。コンテキスト起動手順（Context Activation procedure）は、それ自体、無線リソースの割当を必要とする。ステップ５１２において、ＵＥ３５２は、「ＰＤＰコンテキスト起動」要求をＳＧＳＮ３０６に送信する。ＰＤＰコンテキスト要求に含まれる情報要素は、ＡビットのＱｏＳパラメータを指定する必須フィールドと、ＢビットのＱｏＳパラメータとＣビットのＱｏＳパラメータを独立して指定する更に２つの任意のフィールドとを有する。ＰＤＰコンテキスト起動メッセージ（PDP context activation message）は、更に、接続が要求された外部ネットワークのアクセスポイント名と、ユーザ識別情報と、ＩＰ構成パラメータとを含んでいる。ステップ５１４において、ＳＧＳＮ３０６は、ＰＤＰコンテキスト要求を受信し、加入者記録からユーザを確認する。そして、要求が有効な場合、ＳＧＳＮ３０６は、要求されたアクセスポイント名を含むクエリを、ドメインネームサーバ（図示せず）に送信する。ステップ５１６において、ドメインネームサーバは、供給されたアクセスポイント名の情報を用いて、外部ネットワークへの必要な接続を提供する少なくとも１つのＧＧＳＮ３００のＩＰアドレスを決定する。選択されたＧＧＳＮ３００のＩＰアドレスは、ＳＧＳＮ３０６に供給される。ステップ５１８において、ＳＧＳＮ３０６は、供給されたＧＧＳＮ３００のＩＰアドレスを用いて、ＧＰＲＳトンネリングプロトコルを用いる仮想接続チャンネルを、ＧＧＳＮ３００に要求する。ステップ５２０において、ＧＧＳＮ３００は、トンネルを外部ネットワーク接続に関連付ける。接続トンネル（connection Tunnel）は、カプセル化されたユーザデータ（encapsulated user data）を伝送できる所定の仮想チャンネルである。ステップ５２２において、ＧＧＳＮ３００は、接続トンネル要求を受信し、要求されたトンネルを確立し、搬送するＩＰアドレスをＵＥ３５２に返す。これにより、ＵＥ３５２とＧＧＳＮ３００間に仮想接続が確立される。更に、ＧＧＳＮ３００は、接続トンネルと、外部ネットワークへの物理インタフェースとの関連付けも行う。これにより、ＵＥ３５２と外部ネットワーク間でデータ転送が可能になる。
【００３６】
図８は、音声データのＡビット、Ｂビット及びＣビットで異なるＱｏＳ要求に基づいて無線リソースを割り当てる、ＳＧＳＮ３０６とＲＮＣ３１４間の制御プレーン折衝のフローチャートである。ステップ５３０において、Ａビット、Ｂビット及びＣビットのそれぞれに対する３組の独立したＱｏＳパラメータを指定するＰＤＰコンテキスト情報要素を受信すると、ＳＧＳＮ３０６は、ユーザアプリケーションによって要求されたデータ転送のための無線アクセスベアラの設定を要求するＲＡＮＡＰ要求を、ＲＮＣ３１４に送信する。ステップ５３２において、ＲＮＣ３１４のＲＲＣ層４２２は、ＲＡＮＡＰ要求を受信し、ＲＡＮＡＰ要求をＭＡＣ層４２６に渡す。ステップ５３４において、ＭＡＣ層４２６は、Ａビット、Ｂビット及びＣビットのそれぞれに対する３つの独立したＲＡＢサブフローを確立する。各サブフローは、予め定義されている。選択されたサブフローのカテゴリは、ＲＡＮＡＰによって、３つの音声カテゴリのそれぞれに指定される。最後にステップ５３６において、３つのサブフローのそれぞれに物理層パラメータを設定する。特に、３つのサブフローのそれぞれに、異なるレベルの誤り保護を適用する。
【００３７】
不均一誤り保護（すなわち、音声データビットの異なるクラスに対する異なるレベルの誤り保護）をサポートするために、音声ビット（Ａビット、Ｂビット及びＣビット）の各クラスに対して、複数のＱｏＳパラメータを別々に構成するしなければならない。ＳＧＳＮ３０６は、ＰＤＰコンテキスト要求内の情報に基づいて、ＲＡＢ割当手順を開始する。そして、ＲＮＣ３１４は、ＱｏＳパラメータに基づいて、ＵＭＴＳ無線アクセスベアラを確立する。ＰＤＰコンテキスト要求当たり１つのＲＡＢしか割り当てることができないが、１つのＲＡＢは、１つ以上のＲＡＢ調整サブフローに分割される。表１（図９Ａ、９Ｂ）は、ＱｏＳに関連した幾つかのＲＡＢサービス属性（RAB service attributes）及びこれらに対応するＲＡＢサービス属性値を示している。この表１は、広帯域適応マルチレート符号化（wideband adaptive multi-rate coding）のＲＡＢパラメータを示している（非特許文献２の表５．１参照）。本発明基づく同じ所定のＲＡＢパラメータを、回線交換音声（packet switched voice）と同じように、パケット交換音声（circuit switched voice）にも用いることができる。表１に示すように、第１のＲＡＢサブフローは、Ａビットに関連し、第２のＲＡＢサブフローは、Ｂビットに関連している。第１のＲＡＢサブフローの残留ビット誤り率（residual bit error ratio）は１０−６であり、第２のＲＡＢサブフローの残留ビット誤り率は１０−３である。これは、Ａビットに適用される誤り訂正レベルがＢビットに適用される誤り訂正レベルよりも高いことを反映している。サービスデータユニット（ＳＤＵ）フォーマットでは、５つの所定の音声コーデックデータフレームタイプ（speech codec data frame types）のそれぞれ（１〜５）について、音声データクラスＡ、Ｂ、Ｃのそれぞれに異なるビット数を割り当てる。Ｗ−ＡＭＲの各フレームタイプに対するビット割当の具体例を表２（図１０）に示す。このデータセットは、非特許文献３から引用した。ＲＡＢサブフローの数及びこれらに関連した属性、例えば残留ビット誤り率及び誤ったＳＤＵの配信は、ＳＧＳＮ３０６におけるＲＡＢ確立の段階で、ＰＤＰコンテキスト要求の情報要素に基づいて定義される。図６に示すように、ＲＡＢサブフロー属性は、ＲＡＮＡＰ無線アクセスベアラ確立要求を用いて、ＲＮＣ３１４に知らされる。１つのＲＡＢサブフローコンビネーション（RAB sub-flow combination：以下、ＲＦＣという。）の全てのサブフローのビットの総数は、対応する汎用広帯域ＡＭＲコーデックモード（フレームタイプに関連している）について、表２に指定されているＡビット、Ｂビット及びＣビットに対するビット割当の合計に対応しなければならない。非特許文献２から引用する表３（図１１）は、データの相対的重要度に基づいて、各ＲＡＢサブフローにビット数を設定する指針を示している。
【００３８】
図１２は、非特許文献５に記載されているように、１つの無線アクセスベアラのＱｏＳパラメータを指定する既知のＱｏＳ情報要素のデータ構造を示している。この情報要素は、所定の無線アクセスベアラに関連した様々なＱｏＳパラメータを指定するデータの１３個のオクテットを含んでいる。
【００３９】
図１３は、本発明に基づくＰＤＰコンテキスト情報要素のデータ構造を示しており、ＰＤＰコンテキスト情報要素は、第１の無線アクセスベアラのＱｏＳパラメータを指定する１つのデータフィールドと、異なるＲＡＢサブフローの異なるＱｏＳパラメータを指定する更に２つの任意のデータフィールドとを有している。図１２に示す既存の標準ＱｏＳ情報要素におけるオクテット５の予備ビット５〜８は、図１３に示すように、本発明に基づいて変更されたＱｏＳ情報要素においては、任意のＱｏＳ情報ビットとして利用されている。この本発明に基づいて変更されたＱｏＳ情報要素は、更に２つの任意のフィールド１、２を含んでいる。任意のフィールド１は、ＱｏＳ情報要素のオクテット１４〜２２を占めている。オクテット１４〜２２は、オクテット５〜１４と同じフォーマットを有する。任意のフィールド２は、ＱｏＳ情報要素のオクテット２３〜３１を占めている。オクテット２３〜３１も、オクテット５〜１４と同じフォーマットを有する。オクテット５のビット８がゼロに設定されている場合、如何なる任意のデータフィールド１又は任意のデータフィールド２も存在しないことを示している。一方、オクテット５のビット８が１に設定されている場合、ＱｏＳ情報要素内に、少なくとも任意のフィールド１と、可能性として任意のフィールド２が存在することを示している。ＱｏＳ情報要素の任意のフィールド１は、ＡビットのＲＡＢサブフローのＱｏＳパラメータを指定するために用いることができ、任意のフィールド２は、ＢビットのＲＡＢサブフローのＱｏＳパラメータを指定するために用いることができる。
【００４０】
ユーザプレーン適応化
図１４は、ＩＰパケットのペイロード内のデータフィールドのそれぞれに対して、無線アクセスベアラを確立した後、これらのＩＰパケットをＵＥ３５２と容易に通信するように適応化された、ＧＧＳＮ３００、ＳＧＳＮ３０６、ＲＮＣ３１４及びＵＥ３５２内のプロトコルスタックを示している。
【００４１】
ＧＧＳＮ３００、ＳＧＳＮ３０６及びＲＮＣ３１４は、ＧＰＲＳトンネリングプロトコル（GPRS tunnelling protocol：以下、ＧＴＰという。）をリンク層に有し、ＧＴＰは、ユーザデータ（ＧＴＰ−Ｕ）と、シグナリングデータ（ＧＴＰ＿Ｃ）との両方を通信する。ＧＴＰ−Ｕは、ユーザデータを、ＧＧＳＮ３００、ＳＧＳＮ３０６及びＲＮＣ３１４の間でトンネリングする。トランスポートプロトコル（Transport protocols）は、ＧＴＰデータユニットを、ＧＧＳＮ３００、ＳＧＳＮ３０６及びＲＮＣ３１４を介して搬送する。一実施の形態では、Ｉｕ−ｐｓインタフェース上のこれらのＧＴＰデータユニットを、Ｉｕ−ｐｓフレームと呼ぶ。Ｉｕ−ｐｓフレームの構造を図１５に示す。Ｉｕ−ｐｓフレームは、ＲＡＢサブフローコンビネーションインデクス（RAB sub-flow combination index：ＲＦＣＩ）部８３０と、ＩＰ／ＵＤＰ／ＲＴＰヘッダ部８３２と、適応マルチレート符号化音声データのＶｏＩＰペイロード８３４とからなる。トランスポートプロトコルは、Ｉｕ−ｐｓフレームを、ＧＧＳＮ３００からＵＥ３５２にインターネットプロトコルを用いて通信するユーザデータグラムプロトコル（ＵＤＰ）を含んでいる。基本的には、図１４に示すように、ＧＴＰ−Ｕは、Ｉｕ−ｐｓフレームを、ＳＧＳＮ３０６とＲＮＣ３１４間で下位層のプロトコルを用いて搬送する。これは、非特許文献１に開示されており、ＧＰＲＳ／ＵＭＴＳアーキテクチャの当業者に知られている技術であるので、ここでは詳細には説明しない。ここで、ＲＮＣ３１４及びＵＥ３５２でＩＰパケットを通信するためのプロトコル及び層を表す、図１４で用いた略語について、以下に説明する。
【００４２】
ＲＮＣ３１４において
ＩＰトランスポート層８００は、インターネットプロトコルを用いて、パケット形式でデータを通信する層である。
【００４３】
制御プロトコル層８０３は、ユーザデータグラムプロトコルを用いて、ＩＰパケットを転送する層である。
【００４４】
ＧＴＰ−Ｕ層８０４は、ＧＴＰ−Ｕプロトコルの層である。
【００４５】
パケットデータコンバージェンスプロトコル（Packet Data Convergence Protocol：以下、ＰＤＣＰという。）層８０６は、無線アクセスベアラを介した転送のために、ネットワークレベルのプロトコルを、リンク層のプロトコル、例えば無線リンク制御（ＲＬＣ）層８０８のプロトコルにマッピングする層である。ＰＤＣＰは、ＩＰヘッダの圧縮及び伸張を実行することができる。ヘッダ圧縮方法は、特定のネットワーク層、トランスポート層及び上位層で用いられたプロトコル、例えばＲＴＰ／ＵＤＰ／ＩＰに対して固有である。
【００４６】
ＲＬＣ層８０８は、ＰＤＣＰ層８０６からのデータを、無線アクセスベアラ上にマッピングする層である。
【００４７】
媒体アクセス制御（ＭＡＣ）層８１０は、各無線アクセスベアラからのデータを、ＵＴＲＡＮの物理無線チャンネル（physical radio channel）にマッピングする副層（sub-layer）である。
【００４８】
ＵＥ３５２について
物理（ＰＨＹ）層８１２は、ＲＮＣ３１４から、ノードＢ装置を介して、ＵＴＲＡＮに基づいて提供された物理無線チャンネルの伝送を含む層を表す。
【００４９】
ＭＡＣ層８１４は、ＲＮＣ３１４のＭＡＣ層８１０に対応する層である。
【００５０】
ＲＬＣ層８１６は、ＲＮＣ３１４のＲＬＣ層８０８に対応する副層である。
【００５１】
ＰＤＣＰ層８１８は、ＲＮＣ３１４のＰＤＣＰ層８０６に対応する副層である。
【００５２】
ＧＧＳＮ３００は、図４及び図５に示すように、外部ネットワーク３０２からＩＰパケットを受信し、このＩＰパケットを、ＧＴＰ−Ｕを介してＳＧＳＮ３０６に転送する。ＳＧＳＮ３０６内のＩＰ処理副層８２４は、ＩＰパケットのデータフィールドを解析して、重要度が異なるデータフィールド内に存在するビットの数を識別する。一例として、ＡＭＲ音声コーデックからのデータフレームの場合、この解析により、これらのデータフィールド内の所定数のビットに基づいて、Ａフィールド、Ｂフィールド及びＣフィールド内のビット数が識別される。ＩＰ処理副層８２４は、異なるフィールド内に存在するビット数から、データフレームが、データフォーマットの所定の組のうちのどのデータフォーマットを表しているかの指示を、他のネットワーク構成要素、すなわちＳＧＳＮ３０６、ＲＮＣ３１４、ＵＥ３５２のそれぞれに提供するＲＦＣＩフィールドを生成する。この情報に基づいて、重要度が異なるデータフィールドは、適切な無線アクセスベアラにマッピングすることができる。
【００５３】
ＩＰ処理副層８２４は、ＩＰデータパケットのペイロードを解析する。ＲＮＣ３１４内のＰＤＣＰ層８０６は、ＩＰデータパケットのヘッダを圧縮する。ＳＧＳＮ３０６は、ビットフォーマットを一旦理解すると、ＲＦＣＩを生成し、そして、Ｉｕ−ｐｓフォーマットを生成することができる。
【００５４】
Ｉｕ−ｐｓフレームは、ＩＰ処理副層８２４によって、ＲＦＣＩ及びＳＤＵから形成される。したがって、Ｉｕ−ｐｓフレームは、ＳＧＳＮ３０６を介して、ＲＮＣ３１４に伝送できる、すなわちＲＮＣ３１４のＩＰトランスポート層８００、制御プロトコル層８０３を介して、ＧＴＰ−Ｕ層８０４に伝送できる形式である。ＲＮＣ３１４のＰＤＣＰ層８０６内では、ＩＰヘッダ及びＵＤＰ／ＲＴＰフィールドが、ＰＤＣＰ層８０６によって取り除かれた後、ＳＤＵ内の残りデータは、ＲＬＣ層８０８及びＭＡＣ層８１０を介して、ＵＥ３５２に転送される。ゼロバイトヘッダ圧縮（zero-byte header compression）は、ＲＦＣ３２４３に基づいて実行される。
【００５５】
Ａビット、Ｂビット及びＣビットを含むフレームのための、異なるフィールドからのデータは、各フィールドからのデータの重要度及び特性に一致したそれぞれ異なるＱｏＳを提供する無線アクセスベアラＲＡＢサブフローＡ、ＲＡＢサブフローＢ、ＲＡＢサブフローＣの異なるサブフローを介して、伝送される。
【００５６】
本発明の実施の形態によって、ＩＰパケットからのデータを、重要度が等しくない異なるフィールドによって通信するために、ＲＮＣのアーキテクチャを変更する必要がないという効果が得られる。したがって、ＲＮＣは、ＳＤＵによって提供されるＲＦＣＩを検出できるので、ペイロードデータを適切なベアラに対応させることができる。
【００５７】
ＵＥ３５２においては、ＰＨＹ層８１２、ＭＡＣ層８１４及びＲＬＣ層８１６を介して通信データが渡された後に、ＰＤＣＰ層８１８は、データにＩＰ／ＵＤＰ／ＲＴＰヘッダを再び適用し、これにより、ＩＰプロトコルに準拠するＩＰパケットを、アプリケーション層８２０に、例えばＳＩＰアプリケーションに渡すことができる。
【００５８】
要約すれば、例えばＡＭＲ音声フレームを含むＩＰパケットは、図１６及び図１７に示すように、以下に説明する動作によって、移動無線通信ネットワークを介して転送される。
【００５９】
図１６は、ＳＧＳＮ３０６のユーザプレーンプロトコルスタックによって、データパケットに対して実行される処理を概略的に示している。図１６に示すように、ＳＧＳＮ３０６において、ＩＰヘッダ８５２と、ＵＤＰ／ＲＴＰフィールド８５４と、ＡＭＲ−ＷＢ音声符号化フレームを有するデータフィールド（以下、ＡＭＲ−ＷＢ音声コーデックフィールドともいう。）８５６とを含むＩＰパケット８５０は、ＩＰ処理副層８２４で受信される。そして、受信ＩＰパケットは、矢印８５８によって示すように、以下の動作に基づいて処理される。ＩＰ処理副層８２４は、矢印８６２によって示すように、ＡＭＲ音声コーデックフィールド８５６を解析する。この解析の結果、Ａデータフィールド、Ｂデータフィールド、Ｃデータフィールドのそれぞれのビット数が識別され、これらのビット数から、ＡＭＲ音声フレームを識別するＲＦＣＩ８６６を生成することができる。矢印８６４によって示すように、ＩＰ処理副層８２４は、ＶｏＩＰパケットに付加するＲＦＣＩ８６６を生成して、Ｉｕ−ｐｓフレーム内に別のフィールドを形成する。
【００６０】
そして、ＳＧＳＮ３０６のＩＰ処理副層８２４（図１４参照）は、矢印８６８によって示すように、ＡＭＲ音声フレームのＡビット、Ｂビット、ＣビットからＩｕ−ｐｓフレームの残りの部分を生成する。
【００６１】
そして、Ｉｕ−ｐｓフレームは、ＳＧＳＮ３０６から、ＩＰプロトコルに基づき、ＧＴＰ−Ｕ層８０４を含む様々なプロトコル層を介してＲＮＣ３１４に転送される。
【００６２】
Ｉｕ−ｐｓフレームが、ＲＮＣ３１４のＧＴＰ−Ｕ層８０４で受信されたとき、Ｉｕ−ｐｓフレームは、ＰＤＣＰ層８１８に渡され、処理された後、無線アクセスインタフェースを介し、及びノードＢ装置を介してＵＥ３５２に伝送される。
【００６３】
図１７は、ＲＮＣ３１４のユーザプレーンプロトコルスタックによって、データパケットに対して実行される処理を概略的に示している。図１７に示すように、処理ステップ８７０に示すように、ＲＮＣ３１４のＰＤＣＰ層８０６は、Ｉｕ−ｐｓフレームを受け取り、そして、ＩＰ／ＵＤＰ／ＲＴＰヘッダ８６０を取り除いた後、矢印８７２によって示すように、ＳＤＵの残りの部分をＲＬＣ層８０８に渡す。そして、ＲＬＣ層８０８は、矢印８７４によって示すように、ＲＦＣＩ８６６を用いて、Ａデータフィールド、Ｂデータフィールド及びＣデータフィールドを分離する。矢印８７６によって示すように、Ａデータフィールド、Ｂデータフィールド及びＣデータフィールドは、それぞれＭＡＣ層８１０内の無線アクセスベアラＲＡＢ Ａ、ＲＡＢ Ｂ及びＲＡＢ Ｃを介して、ＵＥ３５２に転送される。
【００６４】
ＵＥ３５２内において、ＡＭＲ音声フレームは、ＰＨＹ層８１２及びＭＡＣ層８１４を介して転送された後、ＲＬＣ層８１６でリフォームされる。そして、ＰＤＣＰ層８１８は、ＩＰ／ＵＤＰ／ＲＴＰヘッダ３０６を再生し、ＵＥ３５２のアプリケーション層８２０に渡す。
【００６５】
本発明の更なる様々な特徴及び機能は、特許請求の範囲において定義されている。この特許請求の範囲から逸脱することなく、上述した実施の形態を様々に変更することができる。
【００６６】
添付資料１
ボイスオーバインターネットプロトコル（ＶｏＩＰ）は、パケットによる音声データの伝送に関するものである。パケットは、パケットをどのようにルーティングするかを指定するヘッダに付加されたデジタルユーザデータの離散的なユニットである。パケットは、長さ及び継続弛緩を変えることができる。対照的に、電話ベースのトラフィックは、パケット交換ではなく、回線交換であり、各データユニットは、固定長であり、継続時間も固定されている。音声データのパケット交換は、複数のアプリケーションソフトウェアによって要求されるように、音声、データ及びビデオトラフィックを統合したいという要求によって、始まったものである。音声及びデータトラフィックを統合することにより、通信チャンネル帯域幅をより効率的に使用することができる。回線交換電話方式は、通常、時分割多重化方式（ＴＤＭ）を用いて、帯域幅を割り当てている。このようなＴＤＭ方式では、電話ユーザには、ユーザが話していないときでも、常に、固定チャンネルのタイムスロットで帯域幅が割り当てられている。（発話が交互に行われ、意見を考える等のために、）通常の会話音声パターンの約５０％が無音であることを考慮すると、常に帯域幅を割り当てるＴＤＭ方式は、無駄が多い。ＶｏＩＰは、パケット交換により、会話における実際の発話中の必要なときだけ帯域幅の使用が認められ、会話における無音の部分では、帯域幅を他のユーザに割り当てる方式の一例である。この効率的な帯域割当方式は、統計的ＴＤＭ（ＳＴＤＭ）として知られている。パケット交換音声の更なる利点は、回線交換ＴＤＭチャンネルは、６４ｋｂｉｔ／ｓのデータレートを必要とするが、パケットベースの音声チャンネルは、４．８〜８ｋｂｉｔ／ｓのデータレートで動作できるという点である。
【００６７】
従来の回線交換電話網は、ハードワイヤード構造（６４ｋｂｉｔ／ｓ ＴＤＭアーキテクチャ）を有し、容易には変更できない。例えば、近年、５〜８ｋｂｉｔ／ｓで動作する狭い帯域幅のコーデックが利用可能になっているが、電話網、電話交換機及び他の構成要素の柔軟性の欠如のために、この利益を享受することができない。コーデック（コーダ／デコーダ）は、パケットネットワークに亘る転送のために、アナログ音声信号をデジタルサンプルに変換する。ＶｏＩＰは、変更をサポートし、提供されるサービスレベルの柔軟性を高めるインフラストラクチャである。例えば、ＶｏＩＰを用いることにより、データレート、使用される符号化技術、ＩＰアドレス、ポート番号及びＱｏＳ要求、例えば最大遅延時間を折衝することができる。
【００６８】
インターネットプロトコル（ＩＰ）は、インターネット上でパケットデータ通信をサポートしている。インターネットは、コネクションレス方式として設計されており、これは、送信元ホストマシンと宛先ホストマシンとの間でパスが固定されていないことを意味する。したがって、ＩＰトラフィックルーティングは、固定接続がないので、所定の接続に関してデータテーブルが維持されないという意味において、ステートレス（stateless）である。これは、発呼側と被呼側の間に接続指向の固定パス（connection-oriented fixed paths）を設定する回線交換電話網とは大きく異なる。このような固定接続は、音声のリアルタイム、且つ短い遅延時間要求をサポートするように設計されている。インターネットは、音声トラフィックではなく、主にデータのために設計され、「ベストエフォート型」の配信ネットワークである。これは、データを配信している間に、（例えば、ネットワークの輻輳、又は雑音によるデータの破損のために）問題が発生した場合、又は宛先ホストマシンを見つけることができない場合、パケットが破棄（discarded）されることを意味する。
【００６９】
パケット音声データをリアルタイムモードでデジタル信号からアナログ信号に逆変換する場合、会話における不自然な遅延をユーザに感じさせないように、音声パケットの双方向遅延は、一定で、通常、３００ｍｓ未満でなければならない。しかしながら、標準の（非音声）データパケットは、送信側と受信側のタイミングの取り決めに関係なく、ネットワークを介して非同期で伝送することができる。音声パケットは、標準のデータトラフィックに比べて、誤りに対する許容度（tolerance）が高い。特に、音声再生の忠実度にひどく影響を及ぼすことなく、音声データパケットの最大５％を欠落させることができる。多くの低ビットレート音声コーデックによって生成される音声パケットのサイズは、非常に短く、通常、１０〜３０バイト程度（継続弛緩の１０〜３０ｍｓに相当する）である。音声パケットに付加する典型的なＩＰヘッダは、約２０バイトの長さである。小さな音声データパケットを用いることにより、ルータでの処理遅延を短くできるという利点がある。
【００７０】
伝送制御プロトコル（Transmission Control Protocol：以下、ＴＣＰという。）は、誤り検査、データの受信の確認応答、欠落した又は誤ったデータの再送、フロー制御管理を含むデータの保全動作に関する総合的なサポートを提供するので、インターネット上の殆どのユーザトラフィックは、ＴＣＰヘッダによって転送される。しかしながら、総合的なＴＣＰサポート機能により、音声に必要なリアルタイム性能では許容し難い４００〜５００ｍｓの全体的な遅延が導入される。また、ＴＣＰは、ネットワークが混雑しているときに、パケット伝送を遅らせるという、音声トラフィックに関する短所がある。このため、音声トラフィックのためには、ユーザデータグラムプロトコル（ＵＤＰ）として知られている異なるプロトコルが用いられる。
【００７１】
ＴＣＰは、接続指向プロトコルであり、これは、あらゆるデータをネットワークノード間で転送する前に、送信装置及び受信装置は、協力して、双方向通信チャンネルを確立しなくてはならないことを意味する。その後、送信装置は、ローカルネットワークを介して送信したデータの各パッケージに対する確認応答を受信し、各データパッケージが誤ることなく受信されたことを保証する状態情報を記録する。
【００７２】
対照的に、ＵＤＰは、コネクションレスプロトコルであり、これは、送信装置が、データがルーティングされていることを受信装置に通知しないで、一方的にデータパケットを送信ことを意味する。受信装置は、各データパケットデータを受信したときに、送信装置に状態情報を返さない。接続指向プロトコルであるＴＣＰは、ＵＤＰよりも信頼性が高いが、ＴＣＰによって実行される追加的な誤り検査及びフロー制御により、速度は、ＵＤＰよりも遅い。更に、ＵＤＰは、ネットワークが混雑しているときであっても、パケットを送信し続ける。
【００７３】
図１は、ＶｏＩＰプロトコルスタックの構造を示している。これは、ＶｏＩＰが他のインターネットプロトコルによって、どのように動作するかを示している。プロトコルスタックは、物理層１１０と、データリンク層１２０と、インターネットプロトコル（ＩＰ）層１３０と、ユーザデータグラムプロトコル（ＵＤＰ）層１４０と、リアルタイムプロトコル（ＲＴＰ）層１５０と、音声層１６０とを含んでいる。
【００７４】
物理層１１０は、媒体及び信号の物理面（例えば電圧）を定義する。また、物理層１１０は、クロッキング及び同期動作、並びに物理的なコネクタを定義する。データの誤り訂正符号化は、物理層手順である。データリンク層１２０は、１つのデータリンク上のトラフィックの転送をサポートする。このデータリンク層１２０で採用された特定のプロトコルに基づいて、誤り検出及び再送を実行することができる。ＩＰ層１３０は、データパケット（データグラムとも呼ばれる。）をどのように生成し、ネットワークを介して転送するかを決定する。ＩＰ層１３０は、データを送信するとき、一組のタスクを実行し、データを受信するとき、他の一組のタスクを実行する。データの送信時には、ＩＰ層１３０は、宛先アドレスがローカル（すなわち、同じネットワーク内）にあるか、又はリモートにあるかを判定する。ＩＰ層１３０は、ローカルの宛先に対しては、直接通信を開始することができるが、宛先がリモートにある場合は、ゲートウェイ（ルータ）を介して通信しなければならない。宛先ネットワークノードがデータを受信したとき、ＩＰ層１３０は、データパケットが伝送中に破損していないことを検証するとともに、データが正しい宛先に配信されたことを確認する。そして、ＩＰ層１３０は、ＩＰデータグラム内のデータフィールドの内容を調べて、送信元のＩＰ層がどのような命令を送ったかを判定する。これらの命令は、通常、ある機能、例えば、プロトコルスタックの次の上位層、この場合ＵＤＰ層１４０にデータを渡す機能を実行させる。図３（後述）は、ＩＰデータパケットの構造を示している。
【００７５】
ＵＤＰ層１４０は、主に、ＩＰトラフィックを送信するマルチプレクサ又はＩＰトラフィックを受信するデマルチプレクサとして機能する。ＵＤＰデータグラムは、宛先ポート番号と、送信元ポート番号とを含んでいる。宛先ポート番号は、受信装置のＵＤＰ層１４０及びオペレーティングシステムによって用いられ、トラフィックを適切な受信者（例えば、適切なアプリケーションプログラム）に配信する。ＵＤＰポート番号及びＩＰアドレスは、結合されて、「ソケット」を形成する。連結されたアドレスは、インターネット内で固有でなければならず、一対のソケットは、各エンドポイント接続を識別している。幾つかのＶｏＩＰのベースの呼処理プロトコルは、ポート番号にアクセスすることなく、効果的に機能することができない。例えば、セッション開始プロトコル（Session Initiation Protocol：ＳＩＰ）は、呼設定及び呼解放（tear-down）に用いられ、特に、アプリケーション間における、パケット通話中に用いられるポート番号の受け渡しをサポートするように機能する。図２（後述）は、ＵＤＰデータパケットの構造を示している。
【００７６】
ＲＴＰ層１５０は、リアルタイムトラフィック、すなわち宛先アプリケーションにおける時間に敏感な再生を必要とするトラフィックをサポートする機能を提供する。ＲＴＰ層１５０によって提供されるサービスは、ペイロードタイプ識別（例えば音声トラフィック）、シーケンス番号付け、タイムスタンピング、配信監視を含む。ＲＴＰ層１５０は、基底に存在するネットワークがマルチキャスト配信をサポートしている場合、このマルチキャスト配信によって、複数の宛先へのデータ転送をサポートする。ＲＴＰ層１５０のシーケンス番号により、受信装置は、元のパケットシーケンスを再現することができる。また、シーケンス番号を用いて、パケットの正しい位置を決定することができる。ＲＴＰ層１５０は、タイムリな配信を補償する機構、又は他のＱｏＳ保証を提供する機構を備えていない。このような保証は、下位の層が担っている。音声データは、原則として、直接ＩＰ層上に、又はＩＰ層の上のＵＤＰ層上に乗せることができるが、技術的に最良の代替例は、図１のプロトコルスタックに示すように、ＩＰ層１３０の上のＵＤＰ層１４０の上のＲＴＰ層１５０上に乗せることである。
【００７７】
図２は、ＵＤＰデータグラムの構造を示す図であり、ＵＤＰデータグラムは、データグラムヘッダ２５０と、データペイロード２６０とからなる。データグラムヘッダ２５０は、４つの１６ビットフィールド、すなわち、送信元ポートフィールド２５２と、宛先ポートフィールド２５４と、データ長フィールド２５６と、チェックサムフィールド２５８とからなる。送信元ポートフィールド２５２は、通常、送信装置の適切なＵＤＰポート番号を有する。送信元ポートフィールド２５２に値が設けられている場合、受信装置は、この値を返信用のアドレスとして用いる。送信元ポートフィールド２５２に有効な値を設けるか否かは任意である。宛先ポートフィールド２５４は、データグラムを配信すべき受信装置上のＵＤＰポートアドレスを指定する。データ長フィールド２５６は、ＵＤＰデータグラムの全体の長さ（ヘッダとペイロードの長さ）をオクテットで指定する。チェックサムフィールド２５８は、データグラムが伝送中に破損していないことを証明するために用いられる。データペイロード２６０は、可変長である。ＵＤＰでは、最大６４ｋｂｉｔのサイズ（ＩＰによって許可されている最大パケットサイズ）を有するメッセージを送信することができる。データグラムヘッダ２５０は、送信元ＩＰアドレス又は宛先ＩＰアドレスを含んでいなく、ＵＤＰポートアドレスのみを含むが、チェックサムデータが、宛先ＩＰアドレス情報を含むことにより、受信装置は、ＵＤＰデータグラムが誤って配信されたか否かを判定することができる。
【００７８】
図３は、ＩＰデータグラムヘッダ２７０と、データペイロード２９６とからなるＩＰデータグラムの構造を示している。ＩＰデータグラムヘッダ２７０は、４ビット、８ビット、１６ビット又は３２ビットの長さの１２個の異なるフィールドを含んでいる。送信元ネットワーク装置（コンピュータ又は移動端末）のＩＰ層は、ＩＰデータグラムヘッダ２７０を形成し、宛先ネットワーク装置のＩＰ層は、ＩＰデータグラムヘッダ２７０の内容を調べて、ＩＰデータグラムのデータペイロード２９６によって何を行うべきかを決定する。ＩＰデータグラムヘッダ２７０には、送信元ホストマシン及び宛先ホストマシンのＩＰアドレスを含む多くの情報が含まれている。バージョンフィールド２７２は、どのバージョンのＩＰが用いられているかを示している。インターネットプロトコルヘッダ長（Internet header length：以下、ＩＨＬという。）フィールド２７４は、４ビットからなり、ＩＰデータグラムヘッダ２７０の長さを３２ビットワード内で指定する。通常、ＩＰデータグラムヘッダ２７０は、２０バイトからなり、この場合、ＩＨＬフィールド２７４の値は、５である。なお、ヘッダ長は、固定ではない。サービスタイプ（type of service field：ＴＯＳ）フィールド２７６によって、送信元ネットワーク装置のＩＰ層は、特別な経路情報、例えば通常の又は短い遅延、通常の又は高いスループット、通常の又は高い信頼度を指定することができる。値が０の最も低い優先順位から、値が７の最も高い優先順位までの優先順位の値は、データグラムの相対的重要度を示している。この優先順位の値を用いて、ネットワーク内のフロー制御及び輻輳機構を実行し、ネットワークに輻輳が生じた場合に、ルータ、サーバ及びホストノードによって、データグラムをどの順番で破棄するかを決定することができる。全長フィールド２７８は、ＩＰデータグラムの全体の長さ（すなわち、ヘッダとペイロードの長さ）をオクテットで指定する。データグラムの可能な最大長は、２１６バイトである。識別フィールド２８０は、送信元ネットワーク装置のＩＰ層によってＩＰデータグラムに割り当てられた増加するシーケンス番号を含んでいる。フラグフィールド２８２は、データの断片化の可能性を示している。「断片化せず（don't fragment：ＤＦ）」フラグは、断片化が可能か否かを指定する。「より断片（more fragments：ＭＦ）」フラグは、関連するデータグラムが断片であることを示している。ＭＦ＝０の場合、断片が殆ど存在せず、又はデータが全く断片化されていないことを示している。断片オフセットフィールド２８４は、連続した断片のそれぞれに割り当てられた数値であり、この数値は、ＩＰ宛先ネットワーク装置で、受信した断片を正しい順序に再構成するために用いられる。有効期間フィールド（time to live field）２８６は、ＩＰデータグラムが破棄される前の生き残ることができる時間を、秒又はルータホップ（router hops）で示している。ネットワークをデータグラムが通過するとき、各ルータは、この有効期間フィールド２８６を調べ、その値を、例えばデータグラムがルータ内で遅延された秒数だけ減らす。この有効期間フィールド２８６の値がゼロに達したとき、データグラムは破棄される。プロトコルフィールド２８８は��ＩＰ層がデータペイロード２９６を配信する宛先のプロトコルアドレスを有する。値が１のプロトコルアドレスは、インターネット制御メッセージプロトコル（Internet Control Message Protocol：ＩＣＭＰ）に対応し、値が６のプロトコルアドレスは、伝送制御プロトコル（ＴＣＰ）に対応し、値が１７のプロトコルアドレスは、ユーザデータグラムプロトコル（ＵＤＰ）に対応している。ヘッダチェックサムフィールド２９０は、ヘッダの妥当性を検証するために用いられる１６ビットの値を含む。ヘッダチェックサムフィールド２９０の値は、有効期間フィールド２８６が減少される毎に、各ルータで再計算される。チェックは、ユーザデータストリームに対しては行われない。送信元ＩＰアドレスフィールド２９２は、応答を送信元ネットワーク装置のＩＰ層に送るために、宛先ネットワーク装置のＩＰ層によって用いられる。宛先ＩＰアドレスフィールド２９４は、データグラムが正しい宛先に配信されたことを確認するために、宛先ネットワーク装置のＩＰ層によって用いられる。データペイロード２９６は、ＴＣＰ又はＵＤＰによって配信する、例えば数千バイトからなる可変長のデータを含む。
【図面の簡単な説明】
【００７９】
【図１】 ＶｏＩＰプロトコルスタックの構造を示す図である。
【図２】 ＵＤＰデータパケットの構造を示す図である。
【図３】 ＩＰｖ４データパケットの構造を示す図である。
【図４】 パケットデータ通信をサポートするように構成された移動無線通信ネットワークの例示的なアーキテクチャを示す図である。
【図５】 図４に示すＧＰＲＳをサポートする移動無線通信ネットワークの構成を概略的に示す図である。
【図６】 ３つの異なるカテゴリの音声データに対するＱｏＳパラメータの制御プレーン通信の構成を示す図である。
【図７】 図６に示す構成における制御プレーン通信シーケンスの例示的な動作を説明するフローチャートである。
【図８】 図６に示す構成における制御プレーン通信シーケンスの更なる動作を説明するフローチャートである。
【図９Ａ】 非特許文献２から引用した、サービス品質（ＱｏＳ）に関連した様々な無線アクセスベアラサービス属性及びこれらに対応するＲＡＢサービス属性値の表１を示す図である。
【図９Ｂ】 非特許文献２から引用した、サービス品質（ＱｏＳ）に関連した様々な無線アクセスベアラサービス属性及びこれらに対応するＲＡＢサービス属性値を示す表１である。
【図１０】 非特許文献４から引用した、５つの所定の音声コーデックデータフレームタイプのそれぞれの広帯域適応マルチレート（ＡＭＲ−ＷＢ）ビットフォーマットを列挙した表２である。
【図１１】 非特許文献２から引用した、データの相対的重要度に基づいて、各ＲＡＢサブフローにビット数を設定する指針を示す表３である。
【図１２】  １つの無線アクセスベアラのＱｏＳパラメータを指定する既知のＱｏＳ情報要素のデータ構造を示す図である。
【図１３】 第１の無線アクセスベアラに対してＱｏＳパラメータを指定する１つのデータフィールドと、ＵＭＴＳベアラ内の異ＱｏＳオプションに対して２つの異なるＱｏＳパラメータを指定する更に２つの任意のデータフィールドとを有する本発明に基づくＰＤＰコンテキスト情報要素のデータ構造を示す図である。
【図１４】  音声データのＩＰパケットをＵＥと容易に通信するように適応化された、ユーザプレーン内のプロトコルスタックを示す図である。
【図１５】 ＶｏＩＰ用のＩｕ−ｐｓフレームの構造を示す図である。
【図１６】  ＳＧＳＮのユーザプレーンプロトコルスタックによって、データパケットに対して実行される処理を説明する図である。
【図１７】 ＲＮＣのユーザプレーンプロトコルスタックによって、データパケットデータに対して実行される処理を説明する図である。
【図１】
0004702852.tif 000002
【図２】
0004702852.tif 000003
【図３】
0004702852.tif 000004
【図４】
0004702852.tif 000005
【図５】
0004702852.tif 000006
【図６】
0004702852.tif 000007
【図７】
0004702852.tif 000008
【図８】
0004702852.tif 000009
【図９Ａ】
0004702852.tif 000010
【図９Ｂ】
0004702852.tif 000011
【図１０】
0004702852.tif 000012
【図１１】
0004702852.tif 000013
【図１２】
0004702852.tif 000014
【図１３】
0004702852.tif 000015
【図１４】
0004702852.tif 000016
【図１５】
0004702852.tif 000017
【図１６】
0004702852.tif 000018
【図１７】
0004702852.tif 000019