JP4680890B2 - インターネットデータパケットの通信の通信装置及び通信方法 - Google Patents

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：以下、ＨＬＲという。）３１０にアクセスする。ＳＧＳＮ３０６は、インターネットデータパケットを無線ネットワーク制御装置（ＲＮＣ）３１２、３１４にルーティングし、ＲＮＣ３１２、３１４は、ＵＴＲＡＮ無線アクセス機能によって、移動通信ユーザ機器（以下、ＵＥという。）３１６、３１８と通信する。このＵＴＲＡＮ無線アクセス機能は、ノードＢ装置３２０、３２２、３２４、３２６、３２８によって提供され、これらのノードＢ装置３２０、３２２、３２４、３２６、３２８は、移動無線通信ネットワークによって提供される範囲のサービスエリア（radio coverage）を有する基地局を構成している。各ＲＮＣ３１２、３１４とノードＢ装置３２０、３２２、３２４、３２６、３２８間のＩｕｂの符号を付したインタフェース３３０、３３２、３３４、３３６、３３８は、制定された又は開発中の規格に準拠している。一方、ＳＧＳＮ３０６と各ＲＮＣ３１２、３１４間のＩｕ−ｐｓの符号を付したインタフェース３４０、３４２は、開発中の規格に準拠している。

重要度が異なるデータの通信
本発明の実施の形態は、ＩＰパケットのペイロード内のデータの重要度に応じて無線リソースを最適化することを試みる方法で、データをＩＰパケットの形式でＵＥ３１６、３１８に／から通信する機能を提供する。ＩＰパケット内の通信されるデータは、重要度が等しくない異なるパラメータ又はフィールドを有する部分（section）を含むことができる。重要度が等しくないフィールドを有するデータの一具体例としては、音声符号化フレーム、例えば、適応マルチレート（Adaptive Multi-Rate：以下、ＡＭＲという。）コーデックによって生成されたデータがある。

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

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

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

ＧＧＳＮ３００及びＳＧＳＮ３０６内のプロトコルに関して、ＵＥ３５０に送信され、及びＵＥ３５０から受信されるＩＰパケットは、データパケットユニット（Packet Data Unit：以下、ＰＤＵという。）を形成している。ＰＤＵの形式は、ＧＧＳＮ３００、ＳＳＧＮ３０６、ＲＮＣ３１４及びノードＢ装置内のプロトコルに理解されていなければならない。ＰＤＵは、ＧＰＲＳネットワーク内で通信されるパケットの形式を指す総称である。なお、ＰＤＵは、ＵＴＲＡＮの無線リンク制御（Radio Link Control：以下、ＲＬＣという。）層に通信されるデータパケットについて言及するときは、サービスデータユニット（Service Data Unit：以下、ＳＤＵという。）と呼ばれ、一方、コアネットワーク内の特にＳＧＳＮ３０６及びＧＧＳＮ３００においてデータパケットに言及するときは、ＰＤＵの語が通常用いられる。

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

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

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

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

無線ネットワーク制御装置（以下、ＲＮＣという。）３１４は、無線リソースの使用及び完全性を制御する。ＲＮＣ３１４は、無線リソース制御（以下、ＲＲＣという。）層４２２と、無線リンク制御（以下、ＲＬＣという。）層４２４と、メディアアクセス制御（以下、ＭＡＣという。）層４２６と、物理層４２８との４つの異なる層に分割することができる機能を備える。

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

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

ＲＡＮＡＰプロトコルは、コアネットワーク（すなわち、ＳＧＳＮ３０６）とＵＴＲＡＮ間のインタフェース用の無線ネットワーク層のシグナリングプロトコルである。ＵＴＲＡＮは、ＲＮＣ３１４とノードＢ装置とを備えるＵＭＴＳネットワークの一部である。ＲＡＮＡＰプロトコルは、ＲＮＣ３１４とＳＧＳＮ３０６間のパケット交換データのためのシグナリングを処理する。また、ＲＡＮＡＰプロトコルは、ＲＮＣ３１４と移動交換機（図示せず）間の回線交換データのためのシグナリングも処理することができる。ＲＡＮＡＰプロトコルが実行できる汎用機能としては、コアネットワーク（ＳＧＳＮ３０６）からの汎用ＵＴＲＡＮ手順、例えばページングを容易にする機能と、移動体固有のシグナリング管理のために、プロトコルレベル上で各ＵＥを分離する機能と、非アクセスシグナリングを転送する機能と、サービング無線ネットワークサブシステムリロケーションを実行する機能と、様々な種類のＵＴＲＡＮ無線アクセスベアラ（ＲＡＢ）を要求し、管理する機能とがある。ＳＧＳＮ３０６は、本発明に基づくＲＡＮＡＰプロトコルを用いて、ＰＤＰコンテキスト起動要求に含まれているＱｏＳデータに基づいて、ＲＮＣ３１４の無線アクセスベアラサブフローの確立を要求する。

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

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

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

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

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

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

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

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

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

制御プロトコル層８０３は、ユーザデータグラムプロトコル（ＵＤＰ）を用いて、ＩＰパケットを転送する層である。

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

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

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

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

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

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

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

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

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

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

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

Ａビット、Ｂビット及びＣビットを含むＡＭＲフレームのための、異なるフィールドからのデータは、各フィールドからのデータの重要度及び特性に一致した、それぞれ異なるＱｏＳを提供するＲＡＢサブフローＡ、ＲＡＢサブフローＢ、ＲＡＢサブフローＣの異なるサブフローを介して伝送される。

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

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

要約すれば、例えば、ＡＭＲ−ＷＢ音声符号化フレームを含むＩＰパケットは、図１６及び図１７に示すように、以下に説明する動作によって、移動無線通信ネットワークを介して転送される。

図１６は、ＳＧＳＮ３０６のユーザプレーンプロトコルスタックによって、インターネットデータパケットに対して実行される処理を概略的に示している。図１６に示すように、ＳＧＳＮ３０６において、ＩＰヘッダ８５２と、ＵＤＰ／ＲＴＰフィールド８５４と、ＡＭＲ−ＷＢ音声符号化フレームを有するデータフィールド（以下、ＡＭＲ−ＷＢ音声コーデックフィールドともいう。）８５６とを含むＩＰパケット８５０は、ＩＰ処理副層８２４で受信される。そして、受信ＩＰパケットは、矢印８５８によって示すように、以下の動作に基づいて処理される。ＩＰ処理副層８２４は、矢印８６２によって示すように、ＡＭＲ−ＷＢ音声コーデックフィールド８５６を解析する。この解析の結果、Ａデータフィールド、Ｂデータフィールド、Ｃデータフィールドのそれぞれのビットの数が識別され、これらのビットの数から、ＡＭＲ音声コーデックフレームを識別するＲＦＣＩ８６６を生成することができる。矢印８６４によって示すように、ＩＰ処理副層８２４は、ＶｏＩＰパケットに付加するＲＦＣＩ８６６を生成して、Ｉｕ−ｐｓフレーム内に別のフィールドを形成する。

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

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

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

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

ＵＥ３５２内において、ＡＭＲ−ＷＢ音声符号化フレームは、ＰＨＹ層８１２及びＭＡＣ層８１４を介して転送された後、ＲＬＣ層８１６で再形成される。そして、ＰＤＣＰ層８１８は、ＩＰ／ＵＤＰ／ＲＴＰヘッダを再生し、ＵＥ３５２のアプリケーション層８２０に渡す。

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

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

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

インターネットプロトコル（ＩＰ）は、インターネット上でデータパケット通信をサポートしている。インターネットは、コネクションレス方式として設計されており、これは、送信元ホストマシンと宛先ホストマシンとの間でパスが固定されていないことを意味する。したがって、ＩＰトラフィックルーティングは、固定接続がないので、所定の接続に関してデータテーブルが維持されないという意味において、ステートレス（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：ＩＣＭＰ）に対応し、値が６のプロトコルアドレスは、伝送制御プロトコル（ＴＣＰ）に対応し、値が１７のプロトコルアドレスは、ユーザデータグラムプロトコル（ＵＤＰ）に対応している。ヘッダチェックサムフィールド２９０は、ヘッダの妥当性を検証するために用いられる１６ビットの値を含む。ヘッダチェックサムフィールド２９０の値は、有効期間フィールド２８６が減少される毎に、各ルータで再計算される。チェックは、ユーザデータストリームに対しては行われない。送信元ＩＰアドレスフィールド２９２は、応答を送信元ネットワーク装置のＩＰ層に送るために、宛先ネットワーク装置のＩＰ層によって用いられる。宛先ＩＰアドレスフィールド２９４は、データグラムが正しい宛先に配信されたことを確認するために、宛先ネットワーク装置のＩＰ層によって用いられる。データペイロード２９６は、ＴＣＰ又はＵＤＰによって配信する、例えば数千バイトからなる可変長のデータを含む。

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

Claims (24)

1. 複数の異なる種類のデータを含むペイロードデータを搬送するインターネットデータパケットを、移動通信ユーザ機器と通信する機能を提供する電気通信システムにおいて、
   上記移動通信ユーザ機器とデータパケット通信ネットワーク間で、上記インターネットデータパケットを通信するインタフェースを提供するゲートウェイサポートノードと、
   上記移動通信ユーザ機器と上記インターネットデータパケットを通信するための複数の無線アクセスベアラサブフローを提供する無線ネットワーク制御装置を用いて、上記ゲートウェイサポートノードと該移動通信ユーザ機器間で、該インターネットデータパケットを通信するサービスサポートノードとを備え、
   上記ゲートウェイサポートノードと上記移動通信ユーザ機器のうちの少なくとも１つは、
   各インターネットデータパケット内の上記ペイロードデータを解析して、データの異なる種類の数及び該データの異なる種類毎のビットの数を判定し、
   上記ペイロードデータ内のデータの異なる種類の数及びデータの異なる種類毎のビットの数を示す無線アクセスベアラサブフロー組合せインディケータを生成し、
   各インターネットデータパケットの上記ペイロードデータを上記無線アクセスベアラサブフロー組合せインディケータと結合することによって、上記ゲートウェイサポートノードと上記無線ネットワーク制御装置間で上記サービスサポートノードを介して各インターネットデータパケットを通信するのに用いられる転送フレームを形成し、
   上記無線アクセスベアラサブフロー組合せインディケータを検出し、該無線アクセスベアラサブフロー組合せインディケータに基づいて、データの異なる種類に適した異なるサービス品質パラメータを提供する異なる無線アクセスベアラサブフローを介して通信する異なるデータフィールドのそれぞれにデータを配置することによって、上記インターネットデータパケットを上記無線ネットワーク制御装置と上記移動通信ユーザ機器間で通信することを特徴とする電気通信システム。
2. 上記ゲートウェイサポートノード及び上記移動通信ユーザ機器の少なくとも一方は、インターネットデータパケット毎に上記ペイロードデータ及びインターネットプロトコルヘッダからサービスデータユニットを生成し、上記サービスデータユニットに上記無線アクセスベアラサブフロー組合せインディケータを結合することによって、上記転送フレームを形成することを特徴とする請求項１記載の電気通信システム。
3. 上記移動通信ユーザ機器及び上記無線ネットワーク制御装置は、通信前に上記サービスデータユニットから上記インターネットプロトコルヘッダを除去し、上記無線アクセスベアラサブフローのそれぞれを介した上記ペイロードデータの通信後に、該インターネットプロトコルヘッダを該サービスデータユニットに追加するデータパケットプロトコル層を備えることを特徴とする請求項２記載の電気通信システム。
4. 上記サービスデータユニットを形成するために上記ペイロードデータに結合される前に、上記インターネットプロトコルヘッダは、圧縮符号化されることを特徴とする請求項２又は３記載の電気通信システム。
5. 上記ゲートウェイサポートノード内で上記インターネットデータパケットを再生するために上記サービスデータユニットから除去される時に、上記圧縮されたインターネットプロトコルヘッダは、伸張されることを特徴とする請求項４記載の電気通信システム。
6. 上記インターネットデータパケットの上記ペイロードデータは、適応マルチレート音声符号化によって形成された、上記複数の異なる種類のデータを提供するデータフレームを含むことを特徴とする請求項１乃至５いずれか１項記載の電気通信システム。
7. 上記ゲートウェイサポートノードは、ゲートウェイＧＰＲＳサポートノードであり、上記サービスサポートノードは、サービスＧＰＲＳサポートノードであり、上記データパケット通信ネットワークは、ＧＰＲＳ（General Packet Radio System）規格に従って動作することを特徴とする請求項１乃至６いずれか１項記載の電気通信システム。
8. 複数の異なる種類のデータを含むペイロードデータを搬送するインターネットデータパケットを、移動通信ユーザ機器と通信する通信方法において、
   上記移動通信ユーザ機器とデータパケット通信ネットワーク間で、上記インターネットデータパケットを通信するインタフェースを提供するステップと、
   上記移動通信ユーザ機器との間で上記インターネットデータパケットを通信するための複数の無線アクセスベアラサブフローを提供する無線ネットワーク制御装置を用いて、上記インタフェースと該移動通信ユーザ機器間で、該インターネットデータパケットを通信するステップとを有し、
   上記インタフェースと移動通信ユーザ機器間でインターネットデータパケットを通信するステップは、
   各インターネットデータパケット内の上記ペイロードデータを解析して、データの異なる種類の数及び該データの異なる種類毎のビットの数を判定するステップと、
   上記ペイロードデータ内のデータの異なる種類の数及びデータの異なる種類毎のビットの数を示す無線アクセスベアラサブフロー組合せインディケータを生成するステップと、
   各インターネットデータパケットの上記ペイロードデータを上記無線アクセスベアラサブフロー組合せインディケータと結合することによって、上記インタフェースと上記無線ネットワーク制御装置間で各インターネットデータパケットを通信するのに用いられる、転送フレームを形成するステップと、
   上記無線アクセスベアラサブフロー組合せインディケータを検出し、該無線アクセスベアラサブフロー組合せインディケータに基づいて、上記データの異なる種類に適した異なるサービス品質パラメータを提供する異なる無線アクセスベアラサブフローを介して通信する異なるデータフィールドのそれぞれにデータを配置することによって、上記インターネットデータパケットを上記移動通信ユーザ機器と上記無線ネットワーク制御装置間で通信するステップとを有することを特徴とする通信方法。
9. 上記転送フレームを形成するステップは、
   インターネットデータパケット毎に上記ペイロードデータとインターネットプロトコルヘッダとからサービスデータユニットを生成するステップと、
   上記サービスデータユニットを上記無線アクセスベアラサブフロー組合せインディケータに結合するステップとを有することを特徴とする請求項８記載の通信方法。
10. 上記インターネットデータパケットを上記移動通信ユーザ機器と上記無線ネットワーク制御装置との間で通信するステップは、
    通信前に上記インターネットプロトコルヘッダを上記サービスデータユニットから除去するステップと、
    上記無線アクセスベアラのそれぞれを介した上記ペイロードデータの通信後に上記インターネットプロトコルヘッダを上記サービスデータユニットに追加するステップとを有することを特徴とする請求項９記載の通信方法。
11. 上記転送フレームを形成するステップは、上記サービスデータユニットを形成するために上記ペイロードデータに結合する前に、上記インターネットプロトコルヘッダを圧縮符号化するステップを有することを特徴とする請求項９又は１０記載の通信方法。
12. 上記ゲートウェイサポートノード内で上記インターネットデータパケットを再生するために上記サービスデータユニットから除去する時に、圧縮された上記インターネットプロトコルヘッダを伸張するステップを更に有する請求項１１記載の通信方法。
13. 上記インターネットデータパケットの上記ペイロードデータは、適応マルチレート音声符号化により形成された、上記複数の異なる種類のデータを提供するデータフレームを含むことを特徴とする請求項８乃至１２いずれか１項記載の通信方法。
14. 複数の異なる種類のデータを含むペイロードデータを搬送するインターネットデータパケットを、移動通信ユーザ機器とデータパケット通信ネットワーク間で通信するゲートウェイサポートノードにおいて、
    データパケット処理層と、
    上記データパケット処理層で処理されたインターネットデータパケットを、インターネットプロトコル通信層を介して通信する仮想チャネルを提供するユーザデータトンネリング層とを備え、
    上記データパケット処理層は、
    各インターネットデータパケット内の上記ペイロードデータを解析して、データの異なる種類の数及び該データの異なる種類毎のビットの数を判定し、
    上記ペイロードデータ内のデータの異なる種類の数及びデータの異なる種類毎のビットの数を示す無線アクセスベアラサブフロー組合せインディケータを生成し、
    各インターネットデータパケットの上記ペイロードデータを上記無線アクセスベアラサブフロー組合せインディケータと結合することによって、当該ゲートウェイサポートノードと無線ネットワーク制御装置間で上記サービスサポートノードを介して処理された各インターネットデータパケットを通信するのに用いられる、転送フレームを形成することを特徴とするゲートウェイサポートノード。
15. 上記データパケット処理層は、インターネットデータパケット毎に上記ペイロードデータ及びインターネットプロトコルヘッダからサービスデータユニットを生成し、該サービスデータユニットに上記無線アクセスベアラサブフロー組合せインディケータを結合することによって、上記転送フレームを形成することを特徴とする請求項１４記載のゲートウェイサポートノード。
16. 上記データパケット処理層は、上記サービスデータユニットを形成するために、上記インターネットプロトコルヘッダを上記ペイロードデータに結合する前に、該インターネットプロトコルヘッダを圧縮符号化することを特徴とする請求項１５記載のゲートウェイサポートノード。
17. 上記データパケット処理層は、上記インターネットデータパケットを再生するために上記サービスデータユニットから除去する時に、上記インターネットプロトコルヘッダを復号することを特徴とする請求項１６記載のゲートウェイサポートノード。
18. 上記ゲートウェイサポートノードは、ゲートウェイ汎用パケット無線システム（ＧＰＲＳ）サポートノードであることを特徴とする請求項１７記載のゲートウェイサポートノード。
19. 請求項１４乃至１８いずれか１項記載のゲートウェイサポートノードから、無線ネットワーク制御装置を介して、複数の異なる種類のデータを含むペイロードデータを搬送するインターネットデータパケットを受信する移動通信ユーザ機器において、
    上記無線ネットワーク制御装置と協働して、上記インターネットデータパケットのデータの異なる種類のうちの１つを受信するのに適したサービス品質パラメータを提供する複数の無線アクセスベアラサブフローと、
    上記複数の無線アクセスベアラサブフローのそれぞれから受信されるデータのビットの数から判定されるデータフレームに上記異なる種類のデータを結合することによって、上記インターネットデータパケットを再形成するデータパケット処理層とを備える移動無線ユーザ機器。
20. 上記無線アクセスベアラサブフローのそれぞれを介した上記ペイロードデータの通信の後に、インターネットプロトコルヘッダを付加するデータパケットプロトコル層を更に備える請求項１９記載の移動無線ユーザ機器。
21. 複数の異なる種類のデータを含むペイロードデータを搬送するインターネットデータパケットを、無線ネットワーク制御装置を介して、請求項１４乃至１８いずれか１項記載のゲートウェイサポートノードに送信する移動通信ユーザ機器において、
    データパケット処理層を備え、
    上記データパケット処理層は、
    各インターネットデータパケット内の上記ペイロードデータを解析して、データの異なる種類の数及び該データの異なる種類毎のビットの数を判定し、
    上記ペイロードデータ内のデータの異なる種類の数及びデータの異なる種類毎のビットの数を示す無線アクセスベアラサブフロー組合せインディケータを生成し、
    上記無線アクセスベアラサブフロー組合せインディケータに基づいて、上記データの異なる種類に適した異なるサービス品質パラメータを提供する異なる無線アクセスベアラサブフローを介して通信する異なるデータフィールドのそれぞれにデータを配置することを特徴とする移動無線ユーザ機器。
22. 請求項１４乃至１８いずれか１項記載のゲートウェイサポートノードと、請求項１９乃至２１いずれか１項記載の移動無線ユーザ機器との間でデータを通信する無線ネットワーク制御装置。
23. ロードされたときに、請求項１４乃至１８いずれか１項記載のゲートウェイサポートノード、請求項１９乃至２１いずれか１項記載の移動無線ユーザ機器、又は請求項２２記載の無線ネットワーク制御装置として動作するデータプロセッサを構成する、コンピュータで実行可能な命令を有するコンピュータプログラム。
24. ロードされたときに、データプロセッサに、請求項８乃至１３いずれか１項記載の通信方法を実行させる、コンピュータで実行可能な命令を有するコンピュータプログラム。

Images