(57)【特許請求の範囲】
【請求項１】
移動無線ネットワークの無線ネットワークコントローラ（ＲＮＣ）（２）と他の機器との間でＩＰパケットを伝送するための方法において、
（Ａ）前記ＲＮＣ（２）は、アップリンク方向において移動端末（１）によって送信されたＩＰパケットを受信し、
当該ＩＰパケットは第１のコーデックモード指示（ＡＭＲ ｒｅｑ．）を含み、当該第１のコーデックモード指示はダウンリンクに対するリクエストされたコーデックモードを表しており；
（Ｂ）前記ＩＰパケットのカプセルの形成は、前記ＲＮＣによって、ヘッダを作成することによって行われ、当該ヘッダは第２のコーデックモード指示（ＲＦＣＩ ｒｅｑ．）を含み；
（Ｃ）当該カプセル化されたＩＰパケットをコーデックモード指示交換装置（ＤＣＦ）（５）へ転送し、当該コーデックモード指示交換装置は、前記第１のコーデックモード指示（ＡＭＲ ｒｅｑ．）を前記第２のコーデックモード指示（ＲＦＣＩ ｒｅｑ．）に相応して交換し；
（Ｄ）当該第２のコーデックモード指示を含んでいるＩＰパケットを他の機器に転送することを特徴とする、移動無線ネットワークの無線ネットワークコントローラ（ＲＮＣ）（２）と他の機器との間でＩＰパケットを伝送するための方法。
【請求項２】
前記第２のコーデックモード指示は前記ＲＮＣによって、エアーインターフェースにおける瞬時の状態に基づいて設定される、請求項１の方法。
【請求項３】
前記ＩＰパケットはアップリンク方向において移動端末（１）によって送信され、ＲＮＣ内に到達する前に既に元来のカプセル内にカプセル化されており、
当該元来のカプセルは第３のコーデックモード指示（ＴＦＣＩ ｒｅｑ．）を含んでおり、当該第３のコーデックモード指示は、請求項１に記載されたカプセル形成の枠内で、前記第２のコーデックモード指示（ＲＦＣＩ ｒｅｑ．）によって交換される、請求項１または２記載の方法。
【請求項４】
ＩＰパケットは最適化されたコーデックサポートフレームフォーマット(Optimized Codec Support Frame Format)（ＯＣＳＦ）にＧＴＰトンネルにおけるトランスポートのために変換され、無線ネットワークコントローラ（ＲＮＣ）（２）と移動端末（ＭＴ）（１）との間のトランスポートのためにＲＡＢサブフロー（１２）に分割される、請求項１〜３のうちの１項記載の方法。
【請求項５】
ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）（４）の中間局および／またはサービングＧＰＲＳサポートノード（ＳＧＳＮ）（３）の中間局を介して、前記カプセル化されたＩＰパケットをコーデックモード指示交換装置（ＤＣＦ）（５）へ前記ステップ（Ｃ）に従って転送する、請求項１〜４のうちの１項記載の方法。
【請求項６】
移動無線ネットワークの無線ネットワークコントローラ（ＲＮＣ）（２）と他の機器との間でＩＰパケットを伝送するための装置において、
当該装置は無線ネットワークコントローラ（ＲＮＣ）（２）とコーデックモード指示交換装置（ＤＣＦ）（５）を有しており、
（Ａ）前記ＲＮＣ（２）は、アップリンク方向において移動端末（１）によって送信されＩＰパケットを受信し、
当該ＩＰパケットは第１のコーデックモード指示（ＡＭＲ ｒｅｑ．）を含み、当該第１のコーデックモード指示はダウンリンクに対するリクエストされたコーデックモードを表しており；
（Ｂ）前記ＲＮＣ（２）は、前記ＩＰパケットのカプセルを、ヘッダを作成することによって形成し、当該ヘッダは第２のコーデックモード指示（ＲＦＣＩ ｒｅｑ．）を含み；
（Ｃ）前記コーデックモード指示交換装置（ＤＣＦ）（５）は前記カプセル化されたＩＰパケットを受信し、前記第１のコーデックモード指示（ＡＭＲ ｒｅｑ．）を前記第２のコーデックモード指示（ＲＦＣＩ ｒｅｑ．）に相応して交換し；
（Ｄ）前記コーデックモード指示交換装置（ＤＣＦ）（５）は、当該第２のコーデックモード指示を含んでいるＩＰパケットを他の機器に転送することを特徴とする、移動無線ネットワークの無線ネットワークコントローラ（ＲＮＣ）（２）と他の機器との間でＩＰパケットを伝送するための装置。
【請求項７】
前記ＲＮＣ（２）は、前記第２のコーデックモード指示を、エアーインターフェースにおける瞬時の状態に基づいて設定する、請求項６の装置。
【請求項８】
アップリンク方向において移動端末（１）によって送信された前記ＩＰパケットは、ＲＮＣ（２）内に到達する前に既に元来のカプセル内にカプセル化されており、
当該元来のカプセルは第３のコーデックモード指示（ＴＦＣＩ ｒｅｑ．）を含んでおり、当該第３のコーデックモード指示は、請求項６に記載された、前記ＲＮＣ（２）によるカプセル形成の枠内で、前記第２のコーデックモード指示（ＲＦＣＩ ｒｅｑ．）によって交換される、請求項６または７記載の装置。
【請求項９】
ＩＰパケットは最適化されたコーデックサポートフレームフォーマット(Optimized Codec Support Frame Format)（ＯＣＳＦ）にＧＴＰトンネルにおけるトランスポートのために変換され、無線ネットワークコントローラ（ＲＮＣ）（２）と移動端末（ＭＴ）（１）との間のトランスポートのためにＲＡＢサブフロー（１２）に分割される、請求項６〜８のうちの１項記載の装置。
【請求項１０】
前記コーデックモード指示交換装置（ＤＣＦ）（５）は、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）（４）の中間局および／またはサービングＧＰＲＳサポートノード（ＳＧＳＮ）（３）の中間局を介して、前記カプセル化されたＩＰパケットを前記ステップ（Ｃ）に従って受信する、請求項６〜９のうちの１項記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動無線ネットワークにおける方法及び装置に関し、この方法によって移動無線加入者間で伝送すべきＩＰパケットにおいて中央コーデックモード（codec-mode）変更が実施される。
【０００２】
本発明の課題は、冒頭に挙げたような方法及び装置を最適化して、シグナリング負荷の低減がコーデックモード変更の中央での処理によって実現されるようにすることである。
【０００３】
上記課題は、本発明によれば、方法及び装置に関する独立請求項の対象によって解決される。本発明の改良実施形態は従属請求項に記載されている。移動無線ネットワークの無線ネットワークコントローラ（ＲＮＣ）と他の装置との間でのＩＰパケットの本発明による伝送は、無線ネットワークコントローラが今日存在し将来存在するであろうコーデックモードを知っておく必要がないという利点を有する。これによってソフトウェアアップデートが無線ネットワークコントローラ（ＲＮＣ）において省略される。このＲＮＣ（２）は完全にデータと見なされるＩＰパケット（ユーザレベルＩＰパケット）を開かなければならない。従って、このＲＮＣ（２）はデータがどのように構造化されているかを知っておく必要はない。このＲＮＣ（２）は同様にどのＲＴＰプロトコルヘッダ、ＩＰプロトコルヘッダ、ＵＤＰプロトコルヘッダ及びＲＴＰペイロードヘッダが使用されるのかを知っておく必要はない。
【０００４】
本発明を図面に図示された実施例に基づいて詳しく説明する。
図１はコーデックモード変更を支援するための装置（ＤＣＦ）を有する本発明のネットワークアーキテクチャを示し、
図２は呼の際のコーデック及びモードに関するデータの交換を示し、
図３はアクセスネットワークの結びつきを示し、
図４はコアネットワークの結びつきを示し、
図５はＯＣＳフレーム（ＯＣＳＦ）の構造を示し、
図６は使用されるＲＡＢサブフローの情報を示し、
図７は２つの移動端末間の呼におけるＩＰパケットの処理を示し、
図８は固定局と移動端末との間の呼におけるＩＰパケットの処理を示し、
図９は２つの移動端末間の呼のための個々の局におけるデータパケットを示し、
図１０は移動端末と固定局との間の呼のための個々の局におけるデータパケットを示す。
【０００５】
ＩＰパケットは２つの無線ネットワークコントローラの間のトランスポートのために最適化されたコーデックサポートフレームに変換され、無線ネットワークコントローラと移動端末との間のトランスポートのために異なるＲＡＢサブフロー(RAB subflows=RAB Teilstroeme)に分割される。
【０００６】
図１はネットワークアーキテクチャを示し、このネットワークアーキテクチャは移動端末間の呼における無線ネットワークコントローラ（ＲＮＣ）間のＩＰパケットの伝送のための方法のために使用される。第１の移動端末１からＩＰパケット（例えばＡＭＲ符号化された音声）が無線ネットワークコントローラ２に到達し、このＩＰパケットはそこでＯＣＳフレーム内にカプセル化され、そこからサービスＧＰＲＳサポートノード３を介してゲートウェアＧＰＲＳサポートノード４に転送される。移動端末１、１１は、移動無線機器、ハンドヘルドコンピュータ、モバイルコンピュータ、これらの機器などの結合である。このために、ＲＮＣ２はテーブルを有し、このテーブルはＴＦＣＩ値を相応するＲＦＣＩ値と及びＴＦＣＩ  ｒｅｑ．値を相応するＲＦＣＩ ｒｅｑ．値と交換するためにダイナミックにコネクションセットアップの際に作成される。この場合、ＲＮＣ２には情報（ＲＡＮＡＰ：ＲＡＢ assignment）が与えられ、この情報はエアーインターフェースにおける瞬時の状態に基づいて相応のコーデックモードをプリセットすることをこのＲＮＣ２に可能にさせる。ＲＮＣ２はコーデックモードを知っている必要はないが、その特性（例えば必要とされる帯域幅）を知ることは必要である。ＯＣＳフレームはフィールドＲＦＣＩ、ＲＦＣＩ ｒｅｑ．、オプショナルフィールド及びＩＰパケットを有し、これらのフィールドの順番はインプリメンテーションフェーズにおいて決定される。トランスポートは例えばＧＴＰ−Ｕヘッダを用いて行われ、このＧＴＰ−ＵヘッダはＲＮＣ２によって作成される。ＧＧＳＮ４はＯＣＳフレームをコーデックモード指示交換装置ＤＣＦ５に与え、このＤＣＦ５はテーブル５ａに基づいて使用されるコーデックモード指示を検査し、これを場合によっては他のコーデックモード指示と取り替える。この場合、ＯＣＳフレームはＧＧＳＮ４とＤＣＦ５との間で１つの部分（アーギュメント）又は異なるアーギュメント（ＲＦＣＩ＝アーギュメント１、ＲＦＣＩ ｒｅｑ．＝アーギュメント２、ＩＰパケット＝アーギュメント３）に分割されてトランスポートされる。コーデックモード指示交換装置ＤＣＦ５は中央装置又は分散装置として通信ネットワークに統合される。この場合、ＤＣＦ５は独自のノードであっても、ＧＧＳＮ４の又は他のノードの装置であってもよい。中央ＤＣＦ５において送信側のＲＦＣＩ値は受信側のＲＦＣＩ値に変換され、送信側のＲＦＣＩ ｒｅｑ．値は受信側のＲＦＣＩ ｒｅｑ．値に変換される。ＤＣＦ５の更なる任務は、リクエストされたコーデックモード（ＡＭＲ ｒｅｑ．値によって表される）をＲＦＣＩ ｒｅｑ．値と比較することである。これらが異なる場合、ＤＣＦ５はＡＭＲ ｒｅｑ．値をＲＦＣＩ ｒｅｑ．値に相応して交換する。
【０００７】
ＧＧＳＮ４毎にＤＣＦ５がある場合、ＤＣＦ５はＲＦＣＩ値、ＲＦＣＩ ｒｅｑ．値及びＩＰパケットをＧＧＳＮ４から受け取る。次いで、ＤＣＦ５はＡＭＲコーデックモードｒｅｑ．をＲＦＣＩ ｒｅｑ．値と比較し、これらの値が互いに合わない場合にはＡＭＲ ｒｅｑ．値を交換する。受信側方向に対しては、ＧＧＳＮ４によってインジケータ（例えば、ＴＦＴ評価）に基づいてＩＰパケットがＤＣＦ５に転送され、そこでＡＭＲコーデックモード及びＡＭＲコーデックモードｒｅｑ．が検出され、相応のＲＦＣＩ値、ＲＦＣＩ ｒｅｑ．値によって置き換えられる。中央ＤＣＦ５と分散ＤＣＦ５との間の差違とは、分散ＤＣＦ５の場合には２つの移動端末１、１１の間の呼に対して２回ＤＣＦ呼び出しが行われることである。交換は例えば負荷に依存してＲＮＣ２によってＲＦＣＩ ｒｅｑ．値に基づいてＤＣＦ５に割り当てられる。ＯＣＳフレームは再びＧＧＳＮ４に送信され、受信側移動端末１１に個別ノードＳＧＳＮ３及びＲＮＣ２を介して転送される。非カプセル化がＲＮＣ２で再び行われる。受信側が固定局１５である場合には、ＩＰパケットはＧＧＳＮ４又はＤＣＦ５自体からファイヤウォール８、インターネット９及び外部ネットワーク１０を介して固定局１５に転送される。
【０００８】
図２はどのように２つの移動端末１と１１との間で呼に使用されるコーデックモードが決定されるのかを示している。この場合、移動端末１が例えばＳＩＰメッセージのトランスポートのためのベアラを指定したことが保証されなければならない。ＳＩＰメッセージは発呼者から見て全ての可能な交渉すべきコーデックモードを有するリストを含む。移動端末１は例えば提案されたコーデックモードを含むＳＤＰ情報を有するＳＩＰメッセージを送信する。ＳＤＰプロトコルはコーデックモードのトランスポートには有利であるが、ｈｔｍｌ又はｘｍｌのような別のプロトコルも使用できる。被呼側の移動端末１１は返答としてそれによって会話をしたいと思うコーデックモードを送信する。ＩＰネットワーク６を介して実現されうるＩＰマルチメディアサブシステム（ＩＭＳ）の呼状態制御機能（Call State Control Funktion（ＣＳＣＦ））７は、移動端末１、１１によって提案されたものとは異なるコーデックモードが使用されなければならない場合には、使用されるコーデックモードの決定に介入することができる。ＩＰネットワークはいわゆるオペレータ固有のＩＰネットワーク（３ＧＰＰ２９０６１）である。今や、両方の移動端末は双方で使用されうるコーデックモードの伝送の準備が整っている。ＡＭＲ符号化された音声の場合には、移動端末は伝送するコーデックモードを例えばＳＤＵパラメータに変換しなければならない。ＣＳＣＦ７又は会話セットアップの間にコーデックモードの伝送に関与する別のノードが既にコーデックモードをＳＤＵパラメータに変換した場合、ＳＤＰ又はＳＩＰプロトコルの改善のためにＳＤＵパラメータが移動端末１、１１に転送される必要がある。ＳＤＵパラメータのシーケンスは、交渉されるコーデックモードを含むＳＤＰ／ＳＩＰリストにおける伝送されるコーデックモードと同一である。
【０００９】
図３はアクセスネットワークの初期化を示している。この場合、ＳＧＳＮ３は呼に使用すべきコーデックモードを知っている。これは例えばＳＤＵパラメータを介して行われる。３ＧＰＰセッションマネージメントプロトコルプロシージャ「ＰＤＰコンテクストを活性化せよ」、「ＰＤＰコンテクストを修正せよ」又は「２次ＰＤＰコンテクストを活性化せよ」は（コーデックモード伝送の相応するコーデックモードと同じシーケンスによる）ＳＤＵパラメータ伝送のために拡張され、これはＳＧＳＮ３におけるコーデックモードを表す。この場合、ＳＧＳＮ３はサービスのタイプを知らないことが、つまり、ＳＧＳＮ３が呼のためにリクエストされるかもしれない全ての異なるコーデックモードによって初期化される必要はないことが実現される。ＳＧＳＮ３は、よって、伝送されるサービスに関して何も知らない。移動端末に与えられるＳＤＵパラメータを含むＲＡＮＡＰ（ＲＡＢアロケーション）リクエストをＳＧＳＮ３は伝送のために呼び出す。ＲＡＢサブフローをＳＤＵパラメータに従って決定するＲＲＣプロトコルメッセージはＲＮＣ２によって呼び出される。データパケットの中のヘッダフィールド（トランスポートフォーマットコンビネーションアイデンティファイア＝Transport Format Combination Identifier）ＴＦＣＩ及び（ＲＡＢサブフローコンビネーションアイデンティファイア＝RAB Subflow Combination Identifier）ＲＦＣＩは、受け取ったＳＤＵパラメータに従う呼のためにＲＮＣ２に格納されている。ＴＦＣＩ及びＲＦＣＩのシーケンスは受け取ったＳＤＵパラメータに相応する。ＴＦＣＩ及びＲＦＣＩはコーデックモードの識別のために使用されるが、この場合、ＲＮＣ２がコーデックモードに関する知識を持つことはない。これによって、ＲＮＣ２は伝送されるサービスについて何も知る必要はない。ＲＡＢサブフローのセットアップが成功裡に完了した場合には、コネクションセットアップは完了したとのＲＲＣプロトコルメッセージがＲＡＢサブフローによって送信される。移動端末１、１１、ＲＮＣ２及びＤＣＦ５は、ＳＤＵパラメータにおけるＲＦＣＩのマッピングを知っているエンティティである。
【００１０】
図４はコアネットワークにおけるコーデックモードの初期化を示す。固定局と移動端末との間でも２つの移動端末の間でも呼のために、ＤＣＦ５はどのＲＦＣＩがどのＳＤＵパラメータを表しているかを知っている。よって、ＲＦＣＩとこれらのＲＦＣＩの相応するコーデックモードとの間のマッピング及びＩＰパケットのＯＣＳフレームへの変換の準備ができている。代替的に、ＤＣＦ５は２つの移動端末間の呼においてＲＦＣＩ及びリクエストされたＲＦＣＩの値を交換することができる。なぜなら、ＲＮＣ２は、相応する受信側移動端末１１を操作する相応するＲＮＣ２とは別のＲＦＣＩによる特定のコーデックモードに対するＳＤＵパラメータのタイプを表現するからである。簡略化のためには、使用されるＲＦＣＩがＳＤＵパラメータ及びＳＩＰ／ＳＤＰ関連コーデックモードと同じシーケンスを有するべきである。ＤＣＦ５はＲＦＣＩ及びＯＣＳフレームをＩＰパケットに変換及びその逆に変換することができるようにテーブルを使用する。テーブルにはＲＦＣＩ及び相応するＳＤＵパラメータならびに相応するＲＦＣＩのマッピングのためのＰＤＰコンテクストに対するトンネルエンドポイントアイデンティファイア（Tunnel Endpoint Identifier）が含まれている。ＲＲＣ呼セットアップメッセージによるポジティブな応答の後で、ＲＮＣ２はＲＡＮＡＰメッセージによって応答し、呼に対してＲＦＣＩ及びその重要性を付加する。ＳＧＳＮ３はＧＴＰ−Ｃ拡張ヘッダを介してＲＦＣＩ及びその重要性をＧＧＳＮ４に送信する。受け取った後で、ＧＧＳＮ４はＲＦＣＩ及びその重要性をＤＣＦ５に送信し、そこでは会話に対する初期化が行われる。ＤＣＦ５はＲＦＣＩの格納及びＩＰパケットのＯＣＳフレームへの変換及びその逆変換の準備ができている。
【００１１】
図５はＯＣＳフレームの構造を示す。使用されるコーデックモードはＲＦＣＩ値によってＯＣＳフレームにおいて指示される。データパケット内の更なるテーブルフィールドは付加的に加えられうる。しかし、これらの更なるテーブルフィールドは受信側によって解釈可能でなければならない。ＩＰヘッダフィールドはＩＰパケットヘッダのリコンフィギュレーションのための情報を含む。ＯＣＳフレームのいくつかの情報はＧＴＰ拡張ヘッダを介して伝達されうるが、これはネットワークにおける標準化乃至はインプリメンテーションに依存する。
【００１２】
図６は異なるＲＡＢサブフローに分割するためのテーブル情報を示す。
【００１３】
図７はＩＰパケットがどのように移動端末１から個々のネットワークノードを介して他の移動端末１１に伝送されるかを示す。送信されるＩＰパケットは移動端末１によって異なるＲＡＢサブフロー１２に分割される。この場合、ＴＦＣＩ、ＴＦＣＩ ｒｅｑ．の値及び場合によっては更に別の値がＩＰパケットから由来する値によって充填される。ＲＡＢサブフロー１２はＩＰパケットをＲＮＣ２にトランスポートする。エアーインターフェースを介するＩＰ／ＵＤＰ／ＲＴＰヘッダのようなヘッダ圧縮はオプショナルである。ＲＮＣ２ではＴＦＣＩの値が相応するＲＦＣＩの値と交換され、ＴＦＣＩ ｒｅｑ．の値が相応するＲＦＣＩ ｒｅｑ．の値と交換される。ＲＮＣ２はこのために適当なテーブル又はアレイを有する。結果として、ＲＡＢサブフロー１２に分割されたＩＰパケットはＯＣＳフレームに変換される。この後でＲＮＣによってＧＴＰ−Ｕヘッダが作成され、ＯＣＳフレーム１３の前に置かれ、サービングＧＰＲＳサポートノード（ＳＧＳＮ）３を介してゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）４に転送される。ＧＧＳＮ４はこのフレームをコーデックモード指示交換装置（ＤＣＦ）５に転送する。中央ＤＣＦ５がある場合には、このＤＣＦ５はＲＦＣＩとＲＦＣＩ ｒｅｑ．値を２つの移動端末１、１１の間で交換する。さらにＤＣＦ５はＩＰパケット内のＡＭＲ ｒｅｑ．値をＲＦＣＩ ｒｅｑ．値と比較し、場合によってはそれを交換する。ＧＧＳＮ４毎にＤＣＦ５がある場合には、ＤＣＦ５はＲＦＣＩ及びＲＦＣＩ ｒｅｑ．値を除去し、ＡＭＲ ｒｅｑ．値をＲＦＣＩ ｒｅｑ．値によって上書きする。ＩＰパケットだけをＧＧＳＮ４に戻し、これがＧＴＰ−Ｕヘッダ（プラスＧＴＰ−Ｕ拡張ヘッダ）を加え、このパケットを２つの移動端末１、１１の間の呼における受信側ＲＮＣ２の方向に送信する。予めこのＩＰパケットが受信側ＧＧＳＮ４を介して受信側ＤＣＦ５に転送され、移動無線端末１１に対して交渉されたＲＦＣＩ及びＲＦＣＩ ｒｅｑ．値がセットされ、再びＧＧＳＮ４に返送される。受信側が固定局１５である場合、ＩＰパケットは直ぐにＧＧＳＮ４から転送される。ＧＧＳＮ４は場合によってはＧＴＰ−Ｕヘッダを交換乃至は修正し、ＯＣＳフレーム１３をＳＧＳＮ３に送信し、このＳＧＳＮ３はこれをＲＮＣ２に転送する。ＲＮＣ２はＲＦＣＩ値を相応するＴＦＣＩ値によって及びＲＦＣＩ ｒｅｑ．値を相応するＴＦＣＩ ｒｅｑ．値によって置き換え、ＩＰパケットを複数のＲＡＢサブフロー１４に分割し、これらのＲＡＢサブフロー１４がこのＩＰパケットをエアーインターフェースを介して移動端末１１に転送する。
【００１４】
図８は移動端末１と固定局１５との間の呼におけるＩＰパケットの変換及び送信を示す。移動端末１からの固定局１５への呼において、ＤＣＦ５はＩＰパケットをＯＣＳフレームに変換及び逆変換する。アップリンク（移動端末からＲＮＣへ）で送信されるＩＰパケットは移動端末１によってＲＡＢサブフロー１２に分割され、ＲＮＣ２へ転送される。ＴＦＣＩ、ＴＦＣＩ ｒｅｑ．の値及び付加的な値はこの場合ＩＰパケットから由来する（ＡＭＲ及びＡＭＲ ｒｅｑ．値）。ＩＰデータパケットヘッダ及び暗号化されたデータも同様にＩＰパケットから取り出される。ヘッダ圧縮、例えばエアインターフェースを介するＩＰ／ＵＤＰ／ＲＴＰヘッダはオプショナルである。ＲＮＣ２はＴＦＣＩ値を相応するＲＦＣＩ値と交換し、ＴＦＣＩ ｒｅｑ．値を相応するＲＦＣＩ ｒｅｑ．値と交換する。これによって、ＲＡＢサブフロー１２はＯＣＳフレームに変換される。この後で、ＲＮＣ２によってＧＴＰ−ＵヘッダがＯＣＳフレームに前置され、ＳＧＳＮ３を介してＧＧＳＮ４に転送される。このＧＧＳＮ４はＯＣＳフレーム１３を非カプセル化し、例えばＧＴＰ−Ｕヘッダのトンネルエンドポイントアイデンティファイアによって、予めＩＰパケットに変換されなければならないＧＴＰ−Ｕヘッダを有するこのＯＣＳフレーム１３が固定局１５へ送信されるべきであることを識別する。変換のためにＧＧＳＮ４がＯＣＳフレーム１３をＧＴＰ−ＵヘッダなしでＤＣＦ５に転送する。このＤＣＦ５はフレームを変換し、これを再びＧＧＳＮ４に返送する。最後にＩＰパケットが固定局１５の方向にＧＧＳＮ４から転送される。代替的に、ＩＰパケットはダイレクトに、ＧＧＳＮ４へ返送される必要なしに、ＤＣＦ５によって固定局１５の方向に転送されることも可能である。
【００１５】
ＧＧＳＮ４がＩＰパケットを固定局１５から逆に受け取るならば、このＩＰパケットは、１つ以上のＰＤＰコンテクストが移動端末１に対して活性化されている時には、例えばＩＰアドレス又はＴＦＴフィルタに従って、固有のＰＤＰコンテクストによって識別される。この識別によってＧＧＳＮ４は、このＩＰパケットをＤＣＦ５に、そこでこれがＯＣＳフレームに変換されるために、転送しなければならないことを知る。相応するＲＦＣＩ及びＲＦＣＩ ｒｅｑ．値をリクエストするアイデンティファイアと共に、このＩＰパケットはＯＣＳフレームへの変換のためにＤＣＦ５に転送され、その後再びＧＧＳＮ４に返送される。次に、ＧＴＰ−ＵヘッダがＯＣＳフレームに前置され、ＳＧＳＮ３に送信され、このＳＧＳＮ３がこのフレーム１３をＲＮＣ２に転送する。ＧＴＰ−Ｕヘッダが除去された後で、ＲＮＣ２はＲＦＣＩ値を相応するＴＦＣＩ値に交換し、ＲＦＣＩ ｒｅｑ．値を相応するＴＦＣＩ ｒｅｑ．値に交換し、ＩＰパケットをＲＡＢサブフロー１２に分割し、移動端末１に送信し、この移動端末１がこれを再び統合する。
移動端末におけるコーデックモード変更要求の実施
別のコーデックモードによるデータのデジタル化へのリクエストは、インバンドで移動端末、コンピュータなどに存在するアプリケーションによって移動無線ネットワークから受信される。コーデックモード変更はＲＮＣ２によって指示される。これはアップリンクでは移動端末１、１１によって行われ、この移動端末１、１１はＴＦＣＩ ｒｅｑ．値によって所定のコーデックモードを要求し、ＲＮＣによって監視され、ダウンリンクでは受信側移動端末１、１１がＲＦＣＩ ｒｅｑ．値を介して別のコーデックモードを使用するように要求される。この値はＲＮＣ２によって監視され、場合によってはこれがこの値をＴＦＣＩ ｒｅｑ．値に交換する前に訂正される。これは、移動端末によって（例えばＲＴＰペイロードヘッダフィールドＡＭＲ ｒｅｑ．によって）ＲＮＣ２の監視下で指示されることもありうる。符号化されたデータを受信する移動端末１１によって操作ＲＮＣ２に送信されるエアーインターフェース品質レポートのために又は例えば時刻のようなトリガによって、ＲＮＣ２は送信側移動端末１にコーデックモード変更を要求することができ、このコーデックモード変更は送信側移動端末に送信されるＯＣＳフレームのＲＦＣＩ ｒｅｑ．値の修正によって実現される。ＲＮＣ２はコーデックモード変更のリクエストにＳＧＳＮ３を介して瞬時の状況（例えば瞬時に使用される帯域幅及び時刻）に従って影響を及ぼすことができる。移動端末はコーデックモード変更リクエストをＴＦＣＩ ｒｅｑ．値を介して受け取る。移動端末内のアプリケーションは同一のコーデックモード変更リクエストをＩＰパケットから例えばＲＴＰペイロードヘッダフィールドＡＭＲ ｒｅｑ．ＩＦ１のようなフィールド値を介して受け取る。この後で、ＩＰパケットはリクエストされたコーデックモードによってデジタル化され、より低いレイヤ（例えばＰＤＣＰレイヤ）に転送される。このより低いレイヤは使用されるコーデックモードに関する情報を含むＩＰパケットのフィールドを解釈することができる。結局、このより低いレイヤは受け取ったＩＰパケットをＴＦＣＩ ｒｅｑ．値と相関するコーデックモードによって検査し、このＩＰパケットを通過させるか又は拒否する。この移動端末はデータをＲＮＣ２によりリクエストされたコーデックモードで符号化する。他方で、失われたパケットのために呼の品質が激しく低下する。
ＤＣＦにおけるコーデックモード変更リクエストの実施
ＤＣＦはコーデックモード変更リクエストをＲＦＣＩ ｒｅｑ．値の形式で受け取る。アプリケーションは同一のリクエストをＩＰパケットの相応のフィールドの形式で受け取る。さらに固定局に存在するアプリケーションはデータをＩＰパケットの相応のフィールドから得られるリクエストされたコーデックモードでデータを符号化する。その後で、ＩＰパケットがリクエストされたコーデックモードによってＧＧＳＮ４を介してＤＣＦ５に送信される。
【００１６】
結局は、このＤＣＦ５はこの受信したＩＰパケットにおいてコーデックモードを、このコーデックモードがＲＦＣＩ ｒｅｑ．値と相関するかどうか検査し、このＩＰパケットを通過させるか又は拒否する。エアーインターフェースを介するＩＰパケットの伝送は変換符号化されて又は変換符号化されずに行われる。
【００１７】
図９は２つの移動端末間の呼における個々の局でのデータパケットの様子を示す。フィールドの順番はインプリメンテーション及び標準化に基づいて決められる。コーデックモードに関する情報（ＲＦＣＩ／ＴＦＣＩ値及びＡＭＲ値、ＲＦＣＩ ｒｅｑ．／ＴＦＣＩ ｒｅｑ値及びＡＭＲ ｒｅｑ．値）はこの例では二重に伝送される。これを除去するためには、移動端末１、１１とＤＣＦとの間でＲＴＰペイロードヘッダ（ＡＭＲ値及びＡＭＲ ｒｅｑ．値を含む）が修正される。これはＩＥＴＦプロトコルが変化されることを意味する。
【００１８】
図１０は移動端末と固定局との間の呼における個々の局でのデータパケットの様子を示す。フィールドの順番はインプリメンテーション及び標準化に基づいて決められる。
【図面の簡単な説明】
【００１９】
【図１】コーデックモード変更を支援するための装置（ＤＣＦ）を有する本発明のネットワークアーキテクチャを示す。
【図２】呼の際のコーデック及びモードに関するデータの交換を示す。
【図３】アクセスネットワークの結びつきを示す。
【図４】コアネットワークの結びつきを示す。
【図５】ＯＣＳフレーム（ＯＣＳＦ）の構造を示す。
【図６】使用されるＲＡＢサブフローの情報を示す。
【図７】２つの移動端末間の呼におけるＩＰパケットの処理を示す。
【図８】固定局と移動端末との間の呼におけるＩＰパケットの処理を示す。
【図９】２つの移動端末間の呼のための個々の局におけるデータパケットを示す。
【図１０】移動端末と固定局との間の呼のための個々の局におけるデータパケットを示す。
【符号の説明】
【００２０】
１  移動端末
２  ＲＮＣ（無線ネットワークコントローラ）
３  ＳＧＳＮ（サービングＧＰＲＳサポートノード）
４  ＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）
５  ＤＣＦ（コーデックモード指示交換装置）
５ａ  テーブル
６  ＩＰネットワーク
７  ＣＳＣＦ（呼状態制御機能）
８  ＦＷ（ファイヤウォール）
９  インターネット
１０  外部ネットワーク
１１  移動端末
１２  ＲＡＢサブフロー
１３  ＯＣＳ（最適化された（optimized）コーデックサポート）フレーム
１５  ＦＴ（固定局）
【図１】
0004024797.tif 000002
【図２】
0004024797.tif 000003
【図３】
0004024797.tif 000004
【図４】
0004024797.tif 000005
【図５】
0004024797.tif 000006
【図６】
0004024797.tif 000007
【図７】
0004024797.tif 000008
【図８】
0004024797.tif 000009
【図９】
0004024797.tif 000010
【図１０】
0004024797.tif 000011