(57)【特許請求の範囲】
【請求項１】
パケットデータネットワーク(GPRS-NW)内でデータパケットを送信するためのパラメータとして送出順序属性(DOA)を設定するための方法において、
異なる送信プロトコル形式に対応する送出順序属性のためのマッピング情報を確立し、
データパケットを送信するための送信プロトコル形式を検出し(S22)、
上記検出されたプロトコル形式が所定の形式であるかどうか判断し(S23)、そして
所定のプロトコル形式が存在しないと判断された場合に、上記マッピング情報及び上記判断結果に基づいて、送出順序属性(DOA)を設定する(S24)、
という段階を含むことを特徴とする方法。
【請求項２】
上記設定された送出順序属性(DOA)は、送信されるデータパケットの順序が維持されねばならないことを示す請求項１に記載の方法。
【請求項３】
上記送出順序属性(DOA)は、所定のプロトコル形式が存在すると判断された場合には設定されない(S25)請求項１に記載の方法。
【請求項４】
上記送出順序属性が設定されないことは、送信されるデータパケットの順序を維持する必要がないことを示す請求項３に記載の方法。
【請求項５】
上記所定のプロトコル形式は、リアルタイム送信に使用されるプロトコル形式である請求項１に記載の方法。
【請求項６】
上記送信プロトコル形式は、ＰＤＰコンテキスト情報又はＰＤＰ形式情報から導出される請求項１に記載の方法。
【請求項７】
パケットデータネットワーク内でデータパケットを送信するための方法であって、データパケットを送信するためのパラメータとして少なくとも送出順序属性(DOA)を検出する(S31)段階を含む方法において、
上記送出順序属性パラメータが設定されたかどうか判断し(S32)、そしてもしそうであれば、
送信されるデータパケットのトラフィッククラスを決定し(S34)、そして
その決定されたトラフィッククラスに基づいて上記送信されるデータパケットを処理する(S35-S39,S310-S315)、
という段階を備えたことを特徴とする方法。
【請求項８】
上記送出順序属性が設定された場合に、それは、送信されるデータパケットの順序が維持されるべきであることを指示する請求項７に記載の方法。
【請求項９】
上記送出順序属性が設定されない場合に、それは、送信されるデータパケットの順序を維持する必要がないことを指示する請求項７に記載の方法。
【請求項１０】
送信されるべきデータパケットは、トラフィッククラスに関わりなくそれらの行先へ直ちに送られる(S33)請求項９に記載の方法。
【請求項１１】
決定されたトラフィッククラスが所定のトラフィッククラスであるかどうか判断し(S35)、そしてもしそうであれば、
受信されたデータパケットのうち、後続送信されたデータパケットの後に受け取られたデータパケットを破棄する(S36)、
という段階を更に備えた請求項７又は８に記載の方法。
【請求項１２】
決定されたトラフィッククラスが所定のトラフィッククラスであるかどうか判断し(S35)、そしてもしそうでなければ、
受信されたデータパケットの間でシーケンス関係を監視し(S37)、
その監視されたシーケンスにおいてデータパケットが欠落するかどうか検出し(S38)、そして
欠落データパケットの検出に応答して、受信されたデータパケットをバッファする(S311)、
という段階を更に備えた請求項７又は８の記載の方法。
【請求項１３】
バッファ時間ウインドウを設定し(S310)、その時間ウインドウの間に、受信されたデータパケットがバッファされる請求項１２に記載の方法。
【請求項１４】
バッファ時間ウインドウの間に欠落データパケットが受信されたかどうかチェックする(S314)段階を更に含む請求項１３に記載の方法。
【請求項１５】
上記欠落データパケットがバッファ時間ウインドウの間に受信されない場合には(S314,S312)、上記バッファされたデータパケットが欠落データパケットに関わりなく送られ(S313)、欠落データパケットは、バッファ時間ウインドウの後に受信された場合でも破棄される請求項１４に記載の方法。
【請求項１６】
上記欠落データパケットがバッファ時間ウインドウの間に受信されない場合には(S314,S312)、上記バッファされたデータパケットが欠落データパケットに関わりなく送られ(S313)、欠落データパケットは、バッファ時間ウインドウの後に受信された場合でもシーケンスから外れて送出される請求項１４に記載の方法。
【請求項１７】
上記欠落データパケットがバッファ時間ウインドウの間に受信された場合には(S314)、上記バッファされたデータパケットは、その最初のシーケンス順序に再順序付けされ、そしてその最初のシーケンス順序で送られる(S315)請求項１４に記載の方法。
【請求項１８】
上記再順序付けは、パケットのヘッダに含まれたパケットのシーケンス番号をベースとする請求項１７に記載の方法。
【請求項１９】
上記ヘッダは、ＧＴＰヘッダ（ＧＴＰ＝ＧＰＲＳトンネルプロトコル）、ＲＬＣヘッダ（ＲＬＣ＝無線リンク制御）ヘッダ、ＬＬＣヘッダ（ＬＬＣ＝論理的リンク制御）、又はパケットのＳＮＤＣＰヘッダである請求項１８に記載の方法。
【請求項２０】
パケットデータネットワーク内でデータパケットの送信を制御するためのネットワーク要素であって、データパケットを送信するためのパラメータとして少なくとも送出順序属性(DOA)を検出するための第１検出手段を備えたネットワーク要素において、
上記送出順序属性パラメータが設定されたかどうか判断するための第１の判断手段と、
肯定の判断結果に応答して、送信されるデータパケットのトラフィッククラスを決定するための第１の決定手段と、
その決定されたトラフィッククラスに基づいて上記送信されるデータパケットを処理するための処理手段と、
を備えたことを特徴とするネットワーク要素。
【請求項２１】
上記処理手段は、更に、
決定されたトラフィッククラスが所定のトラフィッククラスであるかどうか判断するための第２の判断手段と、
上記第２判断手段の肯定結果に応答して、受信されたデータパケットのうち、後続送信されたデータパケットの後に受け取られたデータパケットを破棄するための破棄手段と、
を備えた請求項２０に記載のネットワーク要素。
【請求項２２】
上記処理手段は、更に、
決定されたトラフィッククラスが所定のトラフィッククラスであるかどうか判断するための第２の判断手段と、
上記判断手段の否定結果に応答して、受信されたデータパケット間のシーケンス関係を監視するための監視手段と、
監視されたシーケンスにおいてデータパケットが欠落するかどうか検出するための第２検出手段と、
欠落データパケットの検出に応答して、受信されたデータパケットをバッファするためのバッファ手段と、
を備えた請求項２０に記載のネットワーク要素。
【請求項２３】
上記処理手段は、更に、バッファ時間ウインドウを設定するための設定手段を備え、その時間ウインドウの間に、受信されたデータパケットがバッファされる請求項２２に記載のネットワーク要素。
【請求項２４】
上記処理手段は、更に、バッファ時間ウインドウの間に欠落データパケットが受信されたかどうかチェックするためのチェック手段を備えた請求項２３に記載のネットワーク要素。
【請求項２５】
上記処理手段は、上記欠落データパケットがバッファ時間ウインドウの間に受信されない場合には、上記バッファされたデータパケットを欠落データパケットに関わりなく転送し、そして欠落データパケットを、バッファ時間ウインドウの後に受信された場合でも破棄するよう構成された転送手段を更に備えた請求項２４に記載のネットワーク要素。
【請求項２６】
上記処理手段は、上記欠落データパケットがバッファ時間ウインドウの間に受信されない場合には、上記バッファされたデータパケットをその初期シーケンス順序に再順序付けし、そしてバッファされたデータパケットをその初期シーケンス順序で転送するための再順序付け手段を更に備えた請求項２４に記載のネットワーク要素。
【請求項２７】
上記ネットワーク要素は、パケットデータネットワークにおいてダウンリンク方向にデータパケットの送信を制御する無線ネットワークコントローラ(RNC)である請求項２０ないし２６のいずれかに記載のネットワーク要素。
【請求項２８】
上記ネットワーク要素は、パケットデータネットワークにおいてアップリンク方向にデータパケットの送信を制御するＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）である請求項２０ないし２６のいずれかに記載のネットワーク要素。
【発明の詳細な説明】
【０００１】
【技術分野】
本発明は、パケットデータネットワーク内でデータパケットを送信するためのパラメータとして送出順序属性を設定するための方法と、パケットデータネットワーク内でデータパケットを送信するための方法と、パケットデータネットワークに基づいて動作してそのネットワークにおけるデータパケットの送信を制御するためのネットワーク要素とに係る。
特に、本発明は、現在開発されているＵＭＴＳ（ユニバーサル移動テレコミュニケーションシステム）に関連した方法及びネットワーク要素に係り、より詳細には、ＰＤＰコンテキストＱｏＳパラメータ、並びに入手可能な情報からそれらを導出すること及びそれらの使い方に係る（ＰＤＰ＝パケットデータプロトコル、ＱｏＳ＝サービスクオリティ）。
【０００２】
【背景技術】
近年、テレコミュニケーションは、著しく進歩している。この進歩の一部分は、ユーザが移動ステーションＭＳのような単一のターミナル装置から異なるネットワークにアクセスしそしてそのターミナルで異なる種類のデータを送信／受信できることから明らかである。例えば、著しい進歩は、自分の移動ステーションからインターネットにアクセスしそしてインターネットと自分の移動ステーションとの間でデータ転送を実行できることである。
このようなデータ転送は、データをパケットの単位で送信するパケットデータ送信に基づくものである。このようなパケットデータ送信を可能にするパケットデータネットワークの一例が、説明の目的で図１に概略的に示すＧＰＲＳネットワークＧＰＲＳ−ＮＷである（ＧＰＲＳ＝汎用パケット無線サービス）。この図１は、ＵＭＴＳにおける第３世代のＧＰＲＳネットワーク部分（３Ｇ−ＧＰＲＳ）及びそれに対応する各ＧＰＲＳ要素を示す。
【０００３】
パケットデータは、例えば、インターネット（又はＰＳＴＮ＝公衆交換電話ネットワーク）のような外部ネットワークから移動ステーションＭＳのようなユーザターミナル装置へ送信される（ダウンリンクＤＬ送信）か、又はそれとは逆に送信される（アップリンクＵＬ送信）。以下、ダウンリンクＤＬ送信について、パケットデータ送信を簡単に説明する。
ＵＭＴＳ（ＧＰＲＳ部分）ネットワークＵＭＴＳと外部ネットワークとの間の接続は、いわゆる３Ｇ−ＧＧＳＮ（第３世代のゲートウェイＧＰＲＳサポートノード）を経て確立される。ネットワーク要素としての３Ｇ−ＧＧＳＮは、受信したデータを、３Ｇ−ＳＧＳＮ（第３世代のサービスＧＰＲＳサポートノード）（将来のＵＭＴＳ規格公表においてはＧＧＳＮがＳＧＳＮとしても働き得るのでこれは任意であるが、現在のところ、ＳＧＳＮは必須である）を経て、（無線）ネットワークコントローラ装置ＲＮＣ（ＵＭＴＳにおける；ＧＰＲＳのベースステーションコントローラＢＳＣに対応する）へ転送し、このＲＮＣは、少なくとも１つのノードＢより成る（無線）アクセスネットワーク（ＵＭＴＳにおける）（これは、ＧＰＲＳにおけるベーストランシーバステーションＢＴＳに対応する）（無線アクセスネットワークの場合）を制御するように構成される。次いで、アクセスネットワークがユーザターミナルにアクセスして通信する。
【０００４】
ダウンリンクＤＬでは、ＲＮＣが、行先である移動ステーションへのデータパケットの転送を制御し、一方、アップリンクでは、ＧＧＳＮが、行先である外部ネットワークへのデータパケットの転送を制御する。
ＧＰＲＳネットワークのようなパケットデータネットワークを経てデータパケットを転送するときには、データパケットの送信について充分なサービスクオリティを与えることが重要である。これをＱｏＳと称する。
ＧＰＲＳフェーズ１ではＱｏＳを与えることが首尾良く確立されていない。その後のＧＰＲＳフェーズ２、ひいては、ＵＭＴＳネットワークでは、異なる送信プロトコル形式を使用してデータパケットを送信することができる。例えば、次のプロトコル形式がサポートされる。リアルタイムアプリケーションに最も使用されるＵＤＰ（ユーザデータグラムプロトコル）；ＴＣＰ（送信制御プロトコル）；ＰＰＰ（ポイント対ポイントプロトコル）；Ｘ．２５プロトコル；ＩＰ（インターネットプロトコル）；ＯＳＰ：ＩＨＯＳＳ（オクテットストリーミングプロトコル：インターネットホステッドオクテットストリーミングサービス）。
【０００５】
これら全てのＰＤＰ形式は、各異なる要求の基礎となる。又、上記ＰＤＰ形式のＰＤＰコンテキストの最上部において異なるアプリケーション（例えば、リアルタイムアプリケーション及び／又は非リアルタイムアプリケーション）を実行することができる。しかしながら、異なるアプリケーションは、ネットワークから各異なるサービスを要求する。
例えば、Ｘ．２５プロトコルは、データパケットが確実に送信され、且つ然るべき順序で、即ち最初に送信／転送されたのと同じシーケンスで送出されることを要求する。一方、ＰＰＰプロトコルは、あまり信頼性の高い送信を必要とせず、即ち若干のデータパケットが失われてもＱｏＳに著しく影響しないが、失われなかったデータパケットは、然るべきシーケンスで送出されねばならない。更に、ＩＰプロトコルをベースとする送信は、送信されたパケットの順序を保持しなくてもよいし、又、データパケットが失われてはならないという意味で確実なものでなくてもよい。
【０００６】
このため、最近、ＰＤＰコンテキストＱｏＳパラメータとしての送出順序属性(delivery order attribute)が定義されている。これは、１組のＵＭＴＳベアラＱｏＳパラメータに含まれるべきものである。これらのパラメータは、結論の出ていない標準化プロセスを依然受けている。送出順序属性は、３ＧＰＰテクニカル・スペシフィケーション・グループ・サービス・アンド・システム・アスペクト、ＱｏＳコンセプト（３ＧＴＲ２３．９０７；１９９９年５月、バージョン１．１．０）に定義されている。
送出順序属性パラメータ（ＤＯＡ）は、ＵＭＴＳに対し、送信されるパケットの順序を維持すべきかどうかを定義する。順序を維持すべき場合には、ネットワークのノード又はネットワーク要素（ＵＭＴＳのＧＰＲＳ適合部分）が、受信された（無秩序の）データパケットを再配置して、データパケットが送信されたときの初期シーケンスを再構成する必要性を招く。
【０００７】
しかしながら、この付加的なパラメータは、テレコミュニケーションネットワークにおいて専門家でないことが予想されるエンドユーザによって定義することが困難である。即ち、このような「通常」のエンドユーザは、アクチベートされたサービスに対してこのような特性（然るべき順序のパケット）が必要であるかどうか及び／又はこの特性がオペレーションにいかに影響するかをおそらく知らない。
更に、ＵＭＴＳベアラの最上部において異なるアプリケーションをサポートするために、４つのトラフィッククラスが開発されている。即ち、それは、各々、会話、ストリーミング、対話、及びバックグランドトラフィッククラスである。
上述したＰＤＰ形式は、トラフィッククラスとは独立している。換言すれば、各ＰＤＰ形式（プロトコル形式）は、多数のトラフィッククラスの上で実行される。更に、トラフィッククラスの選択は、送信されるデータパケットのスケジューリング及び／又はバッファリングに関して優勢なトラフィックを取り扱うための幾つかの要件を設定する。又、各トラフィッククラスにおいて送出順序が定義されるが、これは、現在、トラフィッククラスに課せられた要件に合致しない。更に別の公知技術が文書ＷＯ９７／２２２０１号から分かる。
【０００８】
【発明の開示】
そこで、本発明の目的は、ユーザに利用できるサービスを構成するのに必要なユーザインターフェイスを簡単化しながらも異なるサービスに対するデータパケット送信を最適化することである。
本発明の第１の特徴によれば、この目的は、パケットデータネットワーク内でデータパケットを送信するためのパラメータとして送出順序属性を設定するための方法において、異なる送信プロトコル形式に対応する送出順序属性のためのマッピング情報を確立し、データパケットを送信するための送信プロトコル形式を検出し、上記検出されたプロトコル形式が所定の形式であるかどうか判断し、そして所定のプロトコル形式が存在しないと判断された場合に、上記マッピング情報及び上記判断結果に基づいて、送出順序属性を設定するという段階を含む方法によって達成される。
【０００９】
本発明の第２の特徴によれば、この目的は、パケットデータネットワーク内でデータパケットを送信するための方法において、データパケットを送信するためのパラメータとして少なくとも送出順序属性を検出し、上記送出順序属性パラメータが設定されたかどうか判断し、そしてもしそうであれば、送信されるデータパケットのトラフィッククラスを決定し、そしてその決定されたトラフィッククラスに基づいて上記送信されるデータパケットを処理するという段階を含む方法により達成される。
更に、この目的は、パケットデータネットワーク内でデータパケットの送信を制御するためのネットワーク要素において、データパケットを送信するためのパラメータとして少なくとも送出順序属性を検出するための第１検出手段と、上記送出順序属性パラメータが設定されたかどうか判断するための第１判断手段と、肯定の判断結果に応答して、送信されるデータパケットのトラフィッククラスを決定するための第１の決定手段と、その決定されたトラフィッククラスに基づいて上記送信されるデータパケットを処理するための処理手段とを備えたネットワーク要素によって達成される。
【００１０】
本発明の好ましい形態は、各従属請求項に記載する。
本発明の第１の特徴によれば、送出順序属性は、ＰＤＰ形式、即ち送信プロトコル形式に基づいて設定される。従って、送出順序属性の値は、エンドユーザの相互作用を必要とせずに導出される。従って、このパラメータは、エンドユーザから隠され、ユーザインターフェイスＵＩの設計をより簡単なものにする。
本発明の第２の特徴によれば、データパケットは、送出順序パラメータ及びトラフィッククラスの合成評価に基づいて送信／転送される。即ち、本発明のこの特徴は、送出順序をいかに維持するかが接続のトラフィック形式に依存することを提案する。例えば、リアルタイムＲＴ接続及びＲＴトラフィッククラスの場合に、パケットＰｉの後に受け取られる遅延されたデータパケットＰｋ（ｉ＞ｋ）が破棄され、一方、非リアルタイムＮＲＴ接続の場合には、パケットがバッファされそして再順序付けされる。これは、送出順序を維持することが必要とされる場合に行われる。換言すれば、ＮＲＴパケット送出は、シーケンスに従い（もし必要であれば）そして信頼性が高い。要約すれば、データパケットの再順序付けプロセスは、異なるサービスに対して最適化される。
【００１１】
【発明を実施するための最良の形態】
以下、添付図面を参照して、本発明の好ましい実施形態を詳細に説明する。
本発明の第１の特徴によれば、送出順序属性ＤＯＡは、ＰＤＰ形式、即ち送信プロトコル形式から各々導出される。例えば、トラフィック、即ちデータパケットの送信が、ほとんどの場合にリアルタイムトラフィックに使用されるＵＤＰプロトコルに依存するケースについて考える。リアルタイムトラフィックについては、データパケットのバッファ動作を開始しそして失われるか又は少なくともある程度遅れて受信される個々のパケットを待機するのではなく、幾つかのデータパケットを破棄するのが好ましい。このような場合には、送出順序属性を設定してはならず、即ち例えば０の値に設定しなければならず、これは、データパケットが、最初に送信されたシーケンス順序で送出／転送されなくてよい（順序付けが必要でない）ことを示す。他方、例えば、ＰＰＰ及びＸ．２５プロトコルは、送信側から送信された最初の順序（シーケンス）で送出／転送される（即ち行先に受信される）パケットを必要とするか又は又は少なくともそれらパケットから利益を得るアプリケーションを実行するのに使用される。更に、送出順序が保持されることを必要としないＴＣＰは、送出順序が維持されることから利益を得る。又、このような場合に、ＰＤＰ形式、即ちプロトコル形式は、送出順序属性を設定すべきであるかどうか判断するのに使用でき、そしてこのようなプロトコル形式が存在する場合には、送出順序属性は、データパケットの送出があるシーケンス（初期送信シーケンス）で必要とされることを指示する値に設定される。ＵＭＴＳに定義されたＭＡＣ（媒体アクセス制御）／ＲＬＣ（無線リンク制御）のような新たな無線インターフェイスは、データパケットを必ずしも順序正しく送出せず、即ち順序が外れた送出を許すようなデータパケット送出構成が必要とされる。
【００１２】
図２は、パケットデータネットワークにおいてデータパケットを送信するためのパラメータとして送出順序属性を設定するためのここに提案する方法を示す詳細なフローチャートである。
この方法は、ステップＳ２０で始まり、その後、ステップＳ２１においてパケットデータ送信が開始される。
その後、ステップＳ２２において、マッピング情報が確立された後にＰＤＰ形式が検出され、このマッピング情報は、異なる送信プロトコル形式に対応する送出順序属性に対して確立されたものである。即ち、使用する送信プロトコル形式（及びそれに関連した送出順序属性）に関する情報が収集される。
【００１３】
次のステップＳ２３において、検出されたプロトコルが所定のものであるかどうか判断される。又、これは、検出されたプロトコルが、所定のプロトコルグループ（最も簡単なケースにおけるプロトコルグループは、１つのプロトコルのみで構成される）の一部分であるかどうか判断することも意味する。即ち、一部分がシーケンスに従う送出を必要としそして一部分がシーケンスに従う送出を必要としない異なるプロトコルが存在する。以下に述べる所定形式のプロトコルは、シーケンスに従う送出を必要としないプロトコル又は１組のプロトコルを指す。  所定形式のプロトコルが存在すると判断された場合には（ステップＳ２３においてイエス）、ステップＳ２５へ分岐する。換言すれば、ステップＳ２２及びＳ２３は、ＰＤＰ形式を検出し、そしてシーケンスに従う送出を必要とするかどうか判断する。これは、リアルタイム送信用のプロトコルであるＵＤＰが、上述したように、存在すると検出された場合である。次いで、ステップＳ２５において、送出順序属性は設定されず、即ち例えば、値０を仮定する。
【００１４】
他方、上記所定形式が検出されなかった場合には（ステップＳ２３においてノー）（例えば、ＲＴには使用されないがＮＲＴ送信に使用される形式が検出された場合）、ステップＳ２４に分岐する。ステップＳ２４では、送出順序属性は、データパケットをシーケンス（初期の送信シーケンス）に従って送出することを必要とする値（例えば、ＤＯＡ＝１）に設定される。
ステップＳ２４の後、及びステップＳ２５の後に、流れが合流しそしてステップＳ２６へ進む。ステップＳ２６において、パケットデータは、送出順序属性ＤＯＡ（（ＤＯＡ＝１）にセットされるか又は（ＤＯＡ＝０）にセットされない）と共に送信される。
次いで、流れは、ステップＳ２７で終りとなる。
【００１５】
更に別の実施形態として（図示せず）、送出順序パラメータの自動設定のために、他の効果的な幾つかの送信特性が悪影響を受ける（例えば、送信クオリティが所定のクオリティスレッシュホールドより下がる）場合には、ＤＯＡパラメータの設定についての最終的な判断が再びユーザに委ねられるか、又はパラメータが固定値に設定されてもよい。
本発明の第２の特徴によれば、上記設定及び／又は非設定の送出順序属性は、データパケットの送信中に評価される。より詳細には、送信は、ＰＤＰ形式要件とトラフィッククラスとの合成評価に基づいて行われ、各トラフィッククラスにおける送出順序パラメータの適切な取り扱いがそこから得られる。
【００１６】
簡単に述べると、リアルタイムトラフィッククラスでは、データパケットスケジューリング及び転送は高速でなければならず、即ちバッファ動作をほとんど伴わずにリアルタイムでなければならないので、たとえパケットが間違った順序で受け取られてもデータパケットをバッファすることができず、一方、データパケットのシーケンスに従った送出が要求される（即ち、ＰＤＰコンテキスト、即ちプロトコル形式に対して、送出順序パラメータＤＯＡが、ＤＯＡ＝１にセットされる）。順序がずれて受け取られるパケットは、削除及び／又は破棄される。従って、例えば、＃１、＃２、＃３、＃５、＃６、＃４、＃７、＃８のパケット流が受け取られる場合に、パケット＃４が削除される。
【００１７】
他方、非リアルタイムトラフィックに関しては、パケットの流れを再順序付けできるようにするために、まだ到着しないデータパケットをある時間待機することが賢明である。特定例として、順序付けは、データパケットのＧＴＰヘッダ（ＧＰＲＳトンネルプロトコル）に含まれたシーケンス番号に基づいて行われる。しかし、更に別の例として、無線インターフェイスのＲＬＣナンバリング、即ちＲＬＣヘッダに含まれた情報に基づいて順序付けを行うこともできる。一般的に、これは、各ヘッダがパケットのシーケンスに関連した指示を含む限り、いかなるヘッダに含まれた情報に基づいてもよい。
それ故、本発明の第２の特徴により、データパケットの送信、即ち送出／転送は、次のように処理されるものと提案される。
【００１８】
Ｉ）会話及びストリーミングトラフィッククラス
（より一般的には、第１形式のトラフィッククラス又は第１形式のトラフィッククラスグループ）
送出順序属性が設定されない場合には、到来する全てのデータパケットが直ちに（又は少なくともできるだけ即座に）転送される。
しかしながら、送出順序属性が設定された場合には、ネットワーク要素（例えば、ダウンリンク方向のＲＮＣ、アップリンク送信方向のＧＧＳＮ）が、各行先（ダウンリンク方向では移動ステーションターミナル、アップリンク方向ではインターネットのような外部ネットワーク）へデータパケットを転送する前にそれらデータパケットの順序即ちシーケンシャル関係をチェックする。（このチェックは、送信後の最も近いネットワークノード、例えば、ＳＧＳＮでも実行できることに注意されたい。）後続パケット（送信時のパケットの初期順序に基づき）の後に１つ（又はそれ以上の）データパケットが到着し、従って、データパケットが間違った順序で到着する場合には、その順序ずれしたパケット（１つ又は複数）を破棄して、正しいパケット順序を保持する。というのは、このリアルタイムトラフィック関連のトラフィッククラスの場合には、その順序ずれしたデータパケットをバッファしたり待機したりすることが賢明でないからである。
【００１９】
ＩＩ）対話及びバックグランドトラフィッククラス
（より一般的には、第２形式のトラフィッククラス又は第２形式のトラフィッククラスグループ）
送出順序属性が設定されない場合には、到来する全てのデータパケットが直ちに（又は少なくともできるだけ即座に）転送される。（この点においてその振舞いは、第１のケースと同様である。）
送出順序属性パラメータが設定された場合には、ネットワーク要素（例えば、ダウンリンク方向のＲＮＣ、アップリンク送信方向のＧＧＳＮ）が、各行先（ダウンリンク方向では移動ステーションターミナル、アップリンク方向ではインターネットのような外部ネットワーク）へデータパケットを転送する前にそれらデータパケットの順序即ちシーケンシャル関係をチェックする。
【００２０】
データパケットが欠落する場合には、（次の）データパケットをバッファし、そして欠落データパケットを、少なくとも、以下「バッファ時間ウインドウ」と称する特定の待機時間中、待機する。これは、例えば、バッファ動作及び待機を制御するタイミング装置によって制御される。タイマーが時間切れし、即ちバッファ時間ウインドウが経過すると、それまでバッファされているデータパケットが送信され、そしておそらく順序ずれしたデータパケットは、たとえ後で到着してもドロップ即ち破棄される。バッファ時間ウインドウが経過する前に欠落データパケットが到着する場合には、バッファを空にして、次のパケットが欠落するまで送信／転送を続けることができる。この場合に、当然、バッファされたデータパケットは、再順序付けされ、そしてそれらの初期のシーケンスで送信され、この再順序付けは、パケットのＧＴＰヘッダ又はＲＬＣヘッダ（或いはシーケンス番号情報を含む他の適当なヘッダ）のようなヘッダに含まれたシーケンス番号に基づいて行われる。
【００２１】
これは、ほとんどの送信時間中に、ＮＲＴ（非リアルタイム）パケット送出が、シーケンスに従い（もし必要であれば）且つ確実に（若干のデータパケットしか欠落せずそして行先で順序ずれしたデータ流のために送信クオリティが低下しないという点で）実行されることを保証する。この場合に生じる遅延は、著しい質低下を生じない。というのは、ＮＲＴは、遅延に変化があっても遅延に対処し得るからである。
上述したトラフィッククラス情報に加えて、ビットエラー率（ＢＥＲ）及び／又はパケットロス比パラメータ値を参照して、あるＰＤＰコンテキスト即ち送信プロトコルに対してデータパケットをバッファすべきかどうかの判断を行ってもよい。又、以前の属性値及び最大転送遅延値を組み合わせて考慮して、バッファ時間ウインドウ（及び／又はバッファサイズ）としての適当な値を定義してもよい。
【００２２】
図３は、本発明によりパケットデータネットワークにおいてデータパケットを送信するためのここに提案する方法を詳細に示すフローチャートである。
図３Ａを参照すれば、この方法は、ステップＳ３０でスタートする。その後、ステップＳ３１において、ＰＤＰコンテキストＱｏＳパラメータが検出される。これらのパラメータの中で、少なくとも送出順序属性パラメータＤＯＡが検出される。
ステップＳ３２において、上記送出順序属性ＤＯＡが設定されたかどうか判断される。上記送出順序属性ＤＯＡが設定されない（ステップＳ３２においてノーである）場合には、ステップＳ３３へ流れが分岐する。ステップＳ３３では、データパケットが、それらの受信順に、行先へ直ちに（又は少なくともできるだけ即座に）転送される。次いで、その後のステップＳ３３３で終了となる。
【００２３】
しかしながら、ステップＳ３２において、ＤＯＡパラメータが設定された（ステップＳ３２においてイエスである）場合には、ステップＳ３４へ流れが分岐する。
ステップＳ３４では、優勢なトラフィックのトラフィッククラスが決定される。その後の処理は、その決定されたトラフィッククラスに依存する。
即ち、その後のステップＳ３５では、その決定されたトラフィッククラスが所定のクラスである（或いは、例えばＲＴ又はＮＲＴトラフィッククラスのような所定のトラフィッククラスグループに属する）かどうか判断される。より詳細には、ステップＳ３５では、その決定されたトラフィックが第１形式のトラフィッククラス（１つ又は複数）に属するかどうか判断される。選択された例では、この第１形式のトラフィッククラスは、リアルタイムトラフィッククラスを表わすと定義される。
【００２４】
ステップＳ３５でこれが確認され（ステップＳ３５においてイエスであり）、即ち上記トラフィックが会話／ストリーミングトラフィックのようなＲＴトラフィックである場合には、流れが分岐してステップＳ３６へ進む。ステップＳ３６では、順序ずれしたパケットが破棄され、そして残りのパケットだけが、それらが送信された最初の順序で行先へ送信／転送される。例えば、パケット＃１、＃２及び＃３のデータパケット流がこの順序で最初に送信され、そしてこれらパケットが移動ステーションＭＳのような行先への送信中にネットワーク要素により＃１、＃３及び＃２の順序で受信された場合には、パケットのヘッダ情報（例えば、ＧＴＰヘッダ、ＲＬＣヘッダ又は他の適当なヘッダに含まれた情報）の比較により順序ずれが検出され、パケット＃２が破棄され、そしてパケット＃１及び＃３（それらの正しい順序にある）だけが更に行先へ転送される。次いで、ステップＳ３３３において流れが終了となる。
【００２５】
これに対し、ステップＳ３５において、所定の第１形式のトラフィックが存在すると判断されず、即ちここに述べる例では、ＮＲＴトラフィックが存在すると結論される場合に、流れがステップＳ３７へ進む（図３Ｂを参照）。
ステップＳ３７によれば、受信したデータパケットのシーケンスが決定され、即ち受信したパケットの間のシーケンシャル関係が監視される。その後のステップＳ３８では、受信／監視されたデータパケットのシーケンスにおいてデータパケットが欠落するかどうか検出される。
上記例を参照すれば、パケット＃１、＃２及び＃３がこの順序で受信されるかどうか、又は例えば、パケット＃２が欠落するかどうかチェックされる。
パケットが欠落しない（ステップＳ３８においてノーである）場合には、ステップＳ３９に流れが分岐し、そして受信したパケットは、受信した順序（この場合には、パケットが最初に送信された順序でもある）で送信／転送される。次いで、ステップＳ３３３において流れが終了となる。
【００２６】
しかしながら、パケット（例えば、パケット＃２）が欠落する（ステップＳ３８においてイエスである）場合には、ステップＳ３１０へ進む。
ステップＳ３１０では、バッファタイマーが設定されて、バッファ時間ウインドウが設定され、この時間ウインドウの間に受信したデータパケットがバッファされる。受信したデータパケットは、ステップＳ３１１においてバッファされ、そして欠落データパケット（１つ又は複数）の受信を待機する。この待機中に、タイマーが時間切れしたがどうか（時間ウインドウが経過したかどうか）チェックされる。
タイマーが時間切れした（ステップＳ３１２においてイエスである）場合には、ステップＳ３１３へ流れが進み、バッファされたデータパケットがバッファから行先へ送信／転送される。これは、欠落データパケットが、もし後で受信されても、破棄されることを意味する。３つのパケットに関連した例を参照すれば、バッファ時間ウインドウの間にパケット＃２が受信されない場合には、パケット＃１及び＃２だけが転送され、そしてパケット＃２は、後で受信された場合に破棄される。次いで、ステップＳ３３３で流れが終了となる。（パケット＃２のような「後で受信される」即ち順序ずれしたパケットの破棄はあらゆる場合に必要とされるのではなく、所与の例では、パケット＃２も行先へ送信されるケースもあることに注意されたい。）
【００２７】
しかしながら、タイマーが時間切れしない（ステップＳ３１２においてノーである）場合には、ステップＳ３１４へ進み、そこで、欠落データパケット（又は複数の欠落パケット）が受信されたかどうかチェックされる。
パケット（１つ又は複数）が受信された（ステップＳ３１４においてイエスである）場合には、流れがステップＳ３１５へ進む。ステップ３１５において、バッファされたデータパケットがそれらの最初のシーケンス順序に再順序付けされ（例えば、ＧＴＰヘッダ、ＲＬＣヘッダ、ＬＬＣヘッダ、ＳＮＤＣＰヘッダ（ＧＰＲＳにおけるＬＬＣの最上部の層）等の適当なヘッダに含まれたシーケンス番号に基づいて）、そしてそれらの最初のシーケンス順序で転送される。
上記例を参照すれば、パケット＃１及び＃３がバッファされそしてパケット＃２がバッファ時間ウインドウの間に受信されて、パケット＃１、＃３及び＃２が存在する場合には、これらが、パケット＃１、＃２及び＃３の初期送信シーケンス順序に再順序付けされそしてそれらの行先へ転送される。
【００２８】
しかしながら、パケットが受信されない（ステップＳ３１４においてノーである）場合には、流れがステップＳ３１１へ戻り、そしてタイマーが時間切れするか又は欠落パケットが受信されるまで、欠落パケットに対するバッファ動作及び待機が続けられる。
以上の詳細な説明は、特に方法を参照して行った。しかしながら、本発明は、パケットデータネットワーク内でデータパケットの送信を制御するための対応する装置及び／又はネットワーク要素であって、データパケットを送信するためのパラメータとして少なくとも送出順序属性を検出するための第１の検出手段と、上記送出順序属性パラメータが設定されたかどうか判断するための第１判断手段と、肯定の判断結果に応答して、送信されるデータパケットのトラフィッククラスを決定するための第１の決定手段と、その決定されたトラフィッククラスに基づいて上記送信されるデータパケットを処理するための処理手段とを備えたネットワーク要素にも係る。
【００２９】
このようなネットワーク要素ＮＷ−ＥＬＥＭＥＮＴが図４に詳細に示されている。送信されるデータパケットはこのネットワーク要素に供給され、そして第１検出手段に入力され、該検出手段は、第１判断手段に接続され、そしてこの判断手段は、第１決定手段及びその後の処理手段に接続される。
処理手段は、図４の下部に示すように、第２判断手段と、この第２判断手段の各判断結果に応答するようにそれに接続された破棄手段及び監視手段とを備えている。
監視手段は、第２検出手段に接続され、その出力信号はバッファ手段に供給される。バッファ手段は、第２検出手段から供給される信号に応答して入力（図示せず）を経て送り込まれるデータパケットをバッファする。バッファ手段は、設定手段により設定され、一方、チェック手段は、パケットに関してバッファ手段をチェックし及び／又はそこにバッファされたパケットの順序をチェックする。
【００３０】
バッファされたデータは、バッファ手段から読み出され、そして転送／再順序付け手段へ送られ、この転送／再順序付け手段は、チェック手段からこれに送られる制御信号に基づいてそのバッファされたデータを転送するか又はそのバッファされたデータパケットを記録する。（これら後者の手段によって行われる処理は、実質的に、図３Ｂのフローチャートを参照して述べたもの、特に、ステップＳ３１１ないしＳ３１５である。）
ネットワーク内におけるこのような装置／ネットワーク要素の位置は、データパケットの送信方向に依存する。例えば、ダウンリンクＤＬ送信では、装置がネットワーク要素としてＴＮＣの一部分として実施され、一方、アップリンクトラフィックでは、装置がネットワーク要素としてＧＧＳＮの一部分として実施される。
当業者に明らかなように、以上に述べた各方法ステップ及びその機能は、その方法ステップに関連して述べたものと同じ機能を遂行する対応するハードウェア手段に移管することができ、従って、それに対応する装置の詳細な説明を省略できると考えられる。
【００３１】
以上に述べたように、本発明は、パケットデータネットワーク内でデータパケットを送信するための方法において、データパケットを送信するためのパラメータとして少なくとも送出順序属性ＤＯＡを検出し(S31)、上記送出順序属性パラメータが設定されたかどうか判断し(S32)、そしてもしそうであれば、送信されるデータパケットのトラフィッククラスを決定し(S34)、そしてその決定されたトラフィッククラスに基づいて上記送信されるデータパケットを処理する(S35-S315)という段階を備えた方法を提案する。又、本発明は、対応的に構成されたネットワーク要素にも向けられる。更に、本発明は、パケットデータネットワーク内でデータパケットを送信するためのパラメータとして送出順序属性ＤＯＡを設定する方法にも関する。
以上の説明及び添付図面は、本発明を一例として示すものに過ぎないことを理解されたい。従って、本発明の好ましい実施形態は、請求の範囲内で種々変更し得るものである。
【図面の簡単な説明】
【図１】  ＧＰＲＳネットワーク及び／又はＵＭＴＳの対応する機能ユニットを示す簡単なブロック図である。
【図２】  本発明の第１の特徴を詳細に説明するためのフローチャートである。
【図３Ａ】  本発明の第２の特徴を詳細に説明するためのフローチャートである。
【図３Ｂ】  本発明の第２の特徴を詳細に説明するためのフローチャートである。
【図４】  本発明によるネットワーク要素のブロック図である。
【図１】
0003712363.tif 000002
【図２】
0003712363.tif 000003
【図３Ａ】
0003712363.tif 000004
【図３Ｂ】
0003712363.tif 000005
【図４】
0003712363.tif 000006