JP4536990B2 - アプリケーション影響ポリシー - Google Patents
アプリケーション影響ポリシー Download PDFInfo
- Publication number
- JP4536990B2 JP4536990B2 JP2001586858A JP2001586858A JP4536990B2 JP 4536990 B2 JP4536990 B2 JP 4536990B2 JP 2001586858 A JP2001586858 A JP 2001586858A JP 2001586858 A JP2001586858 A JP 2001586858A JP 4536990 B2 JP4536990 B2 JP 4536990B2
- Authority
- JP
- Japan
- Prior art keywords
- policy
- gate
- network
- support node
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 claims abstract description 72
- 238000001914 filtration Methods 0.000 claims abstract description 38
- 230000007246 mechanism Effects 0.000 claims abstract description 25
- 230000000977 initiatory effect Effects 0.000 claims abstract description 7
- 230000006870 function Effects 0.000 claims description 88
- 230000011664 signaling Effects 0.000 claims description 30
- 238000013475 authorization Methods 0.000 claims description 24
- 230000004044 response Effects 0.000 claims description 19
- 230000009471 action Effects 0.000 claims description 17
- 230000004913 activation Effects 0.000 claims description 9
- 238000012986 modification Methods 0.000 claims description 9
- 230000004048 modification Effects 0.000 claims description 9
- HRULVFRXEOZUMJ-UHFFFAOYSA-K potassium;disodium;2-(4-chloro-2-methylphenoxy)propanoate;methyl-dioxido-oxo-$l^{5}-arsane Chemical compound [Na+].[Na+].[K+].C[As]([O-])([O-])=O.[O-]C(=O)C(C)OC1=CC=C(Cl)C=C1C HRULVFRXEOZUMJ-UHFFFAOYSA-K 0.000 claims description 7
- 238000012546 transfer Methods 0.000 claims description 6
- 230000008859 change Effects 0.000 claims description 2
- 238000012217 deletion Methods 0.000 claims 1
- 230000037430 deletion Effects 0.000 claims 1
- 238000007726 management method Methods 0.000 description 27
- 238000010586 diagram Methods 0.000 description 16
- 239000008186 active pharmaceutical agent Substances 0.000 description 8
- 238000004891 communication Methods 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 238000013507 mapping Methods 0.000 description 6
- 238000013519 translation Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 230000001960 triggered effect Effects 0.000 description 4
- 230000008520 organization Effects 0.000 description 3
- 238000011144 upstream manufacturing Methods 0.000 description 3
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000013468 resource allocation Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 238000007493 shaping process Methods 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 230000005641 tunneling Effects 0.000 description 2
- 238000012550 audit Methods 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012946 outsourcing Methods 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- VEMKTZHHVJILDY-UHFFFAOYSA-N resmethrin Chemical compound CC1(C)C(C=C(C)C)C1C(=O)OCC1=COC(CC=2C=CC=CC=2)=C1 VEMKTZHHVJILDY-UHFFFAOYSA-N 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/1403—Architecture for metering, charging or billing
- H04L12/1407—Policy-and-charging control [PCC] architecture
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/15—Flow control; Congestion control in relation to multipoint traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/18—End to end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2491—Mapping quality of service [QoS] requirements between different networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/801—Real time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/808—User-type aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/824—Applicable to portable or mobile terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
- H04L65/103—Media gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1033—Signalling gateways
- H04L65/104—Signalling gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- Quality & Reliability (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
- Waveguide Aerials (AREA)
- Fittings On The Vehicle Exterior For Carrying Loads, And Devices For Holding Or Mounting Articles (AREA)
- Transducers For Ultrasonic Waves (AREA)
- Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)
Description
【０００１】
(背景技術)
本出願は一般的にパケットデータ網に関し、特にポリシー機構を使用してパケットデータ網内のデータをフィルタリングおよびゲーティングする方法に関する。
【０００２】
元々、インターネットプロトコル（“ＩＰ”）網等のパケットデータ網は“ベストエフォート”トラフィックを運ぶように設計された。すなわち、網はユーザパケットが受け手に到達することを保証しなかった。ＩＰ網市場の成功により、ＩＰ網がさまざまなタイプのアプリケーションをサポートできるようにする機構が今日明らかに必要とされている。これらのアプリケーションのいくつかはサービス品質（“ＱｏＳ”）要求条件を有する。このようなアプリケーションの例としてさまざまなリアルタイムアプリケーション（ＩＰ電話、ビデオ会議）、ストリーミングサービス（オーディオまたはビデオ）、または高品質データサービス（有限ダウンロード遅延ブラウジング）が含まれる。これらの要求条件を認識して、ＩＰ網に対する主要な標準化組織であるＩＥＴＦ(Internet Engineering Task Force)は最近ＩＰ網オペレータがＱｏＳイネーブルドＩＰ網を形成することができる一組のプロトコルおよび機構を標準化した。
【０００３】
図１はＱｏＳプロビジョニングを説明するのに有用なＩＰ網の単純化されたハイレベルモデルを示す。このモデルは二人のユーザを含んでいるが、網の基本的機能を変えずにより多くのユーザを含むように容易に拡張できることがお判りであろう。
【０００４】
図１において、ユーザＡ１０１はユーザＢ１０２またはアプリケーションサーバ１０３と通信することができる。例えば、ＩＰ電話セッションの場合には、ユーザＡ１０１はユーザＢ１０２と通信することができる。同様に、ストリーミングサービスの場合には、ユーザＡ１０１はアプリケーションサーバ１０３と通信することができ、それはビデオサーバとして構成することができる。いずれの場合にも、ユーザＡ１０１は電話、移動通信用グローバルシステム（“ＧＳＭ”）、またはＵＭＴＳ（Universal Mobile Telecommunication System）網等のローカルアクセス網１０５を介してＩＰバックボーン網１０４にアクセスする。ユーザＢ１０２は同様にローカルアクセス網１０６を介してＩＰ網１０４に接続される。しかしながら、ユーザＡ１０１およびユーザＢ１０２は同じタイプのアクセス網を使用する必要はないことがお判りであろう。
【０００５】
一般的に知られているように、ＩＰ網１０４は一緒にＩＰ網の入口および出口ポイント間の接続性を提供して２パーティ通信を可能とするいくつかのＩＰルータおよび相互接続リンクを含むことができる。
【０００６】
ユーザに関する限り、知覚されるＱｏＳはアクセス網１０５，１０６およびＩＰバックボーン網１０４内の両方の機構によって決まる。特に興味深いのは、少なくとも一つのアクセス網がＵＭＴＳ網である特定のケースである。
【０００７】
ユーザがＩＰベースサービスにアクセスする時は、典型的にユーザが特定のサービスにアクセスするためのインターフェイスを提供するアプリケーションを実行する装置を使用する。例えば、図１では、ユーザＡはＩＰ網ベース会議に参加する会議アプリケーションプログラムを実行するラップトップコンピュータを使用することができ、会議の参加者はさまざまなプログラムを使用して協議する。このようなプログラムは従来技術でよく知られている。
【０００８】
さまざまなアプリケーションがアプリケーションプログラミングインターフェイス（“ＡＰＩ”）を介して網サービスにアクセスすることができる。ＡＰＩはアプリケーションプログラマが基本的なシステムリソースにアクセスするための均一なインターフェイスを提供する。例えば、ＡＰＩは所与のアプリケーションから発信される特定のＩＰパケットが、特定のＱｏＳ等の、ある処置を網から受けることを要求するように網リソースマネージャを構成するのに使用することができる。例えば、ＩＰ網がDifferentiated Services ＩＰ網であれば、アプリケーションプログラムはその全てのＩＰパケットが“Expedited Forwarding”処置を受けるよう要求することができる。
【０００９】
ユーザ（およびユーザの装置内のＡＰＩ）はさまざまなアクセス網およびＩＰバックボーン網がend-to-end ＱｏＳを提供するために利用する異なる技術を知らないことがある。例えば、ユーザはＲＳＶＰ/IntServベースＡＰＩを使用することができ、ユーザが関与するend-to-end実施例はＵＭＴＳアクセス網および非ＲＳＶＰイネーブルドＩＰ網を含むことがある。このような場合、さまざまな技術間のある相互作用機構はＱｏＳがend-to-endで提供されることを確かめることが必要となることがある。
【００１０】
統合サービス（“IntServ”）は多数の中からそのデータパケットに対する配信サービスの制御されたレベルを選択するアプリケーション能力を提供する。この能力をサポートするために、二つのことが必要である。第１に、アプリケーションのデータパケットが続くパスに沿った、サブネットおよびＩＰルータ等の、個別の網要素がこれらのパケットに配信されるＱｏＳを制御する機構をサポートしなければならない。第２に、アプリケーションの要求条件をパスに沿って網要素に伝えＱｏＳ管理情報を網要素およびアプリケーション間で運ぶ方法を提供しなければならない。
【００１１】
IntServは制御された負荷（IETF RFC2211で規定される）および保証（IETF RFC2212で規定される）等のいくつかのサービスを規定する。サービス規定はサービスを配信するために網装置の必要な特性を規定する。例えば、保証サービスはend-to-endデータグラム待ち行列遅延の固定した、数学的に証明可能な範囲を与え遅延および帯域幅の両方を保証するサービスを提供できるようにする。制御された負荷サービスは同じフローが無負荷網要素から受信するが、容量制御（許可）制御を使用して網要素が過負荷である時でもこのサービスが受信されることを保証するＱｏＳを精密に近似するＱｏＳをクライアントデータフローに提供する。サービスをサポートする個別の網要素（サブネットおよびＩＰルータ）はそのサービスに対して規定された規定に従わなければならない。
【００１２】
サービス規定はサービスを確立するために網の両端間で提供しなければならない情報も規定する。この機能はいくつかの方法で提供することができるが、ＲＳＶＰ（IETF RFC2205で規定される）等のリソース保存セットアッププロトコルにより頻繁にインプリメントされる。
【００１３】
ＲＳＶＰ(Resource reSerVation Protocol)はIntServ Internet（IETF RFC1633, 2205、および2210で規定される）に対して設計されたリソース保存セットアッププロトコルである。ＲＳＶＰプロトコルはホストが特定のアプリケーションデータストリームすなわちフローに対して網から特定のサービス品質を要求するのに使用される。ＲＳＶＰはルータがフローのパスに沿った全てのノードにＱｏＳ要求を配信し要求されたサービスを提供する状態を確立して維持するのにも使用される。ＲＳＶＰ要求の結果、一般的に、リソースはデータパスに沿った各ノード内に保存される。
【００１４】
図２はホスト間のend-to-end統合サービスを示す。サービスは要求されたサービスに対して規定されたサービス規定をサポートするルータおよびホストを使用してノード間での関連情報のシグナリングを介して提供される。
【００１５】
ＲＳＶＰは主としてend-to-endに設計されるプロトコルであるため、送り手がend-to-endパスのある部分だけでリソース保存するためにＲＳＶＰを使用したい状況では、ある特別な機能が必要となる。これはＲＳＶＰがアクセス網内で使用されバックボーン網内でオーバプロビジョニングが使用される場合に生じることがある。このような状況では、ＲＳＶＰ Ｐｒｏｘｙの概念が有用である。
【００１６】
ＲＳＶＰ Ｐｒｏｘｙはルータまたはスイッチ等の網装置により提供される機能であり、網装置はＰＡＴＨメッセージにより識別される一人以上の受け手のために着信ＰＡＴＨメッセージに応答してＲＥＳＶメッセージを発信する。すなわち、ＲＳＶＰ Ｐｒｏｘｙは遠隔ホストのために作用して発信ホストとＲＳＶＰ Ｐｒｏｘｙ間のリソース保存を容易にする。これは図３に示されている。ＲＳＶＰ ＰｒｏｘｙはＲＳＶＰ Ｐｒｏｘｙと非ＲＳＣＰホスト間の網状況の知識を使用することができる。
【００１７】
インターネットプロトコルへのDifferentiated Services（“DiffServ”）エンハンスメントはパーフロー状態およびホップ毎のシグナリングを必要とせずインターネット内でスケーラブルサービス識別をできるようにするものである。網ノード内に展開されるビルディングブロックの小さなよく規定されたセットから多様なサービスを組み立てることができる。サービスはend-to-endまたはintra-domainとすることができ、サービスは量的性能要求条件（例えば、ピーク帯域幅）を満たすことができるものおよび相対性能に基づくもの（例えば、“クラス”区別）を含んでいる。サービスは網境界（自律システム境界、内部管理境界、またはホスト）におけるＩＰヘッダーフィールド内の設定ビットの組合せにより構成することができ、これらのビットを使用して網内のノードによりパケットがどのように転送されるかを決定し、各サービスの要求条件またはルールに従って網境界においてマークされたパケットを調節する。
【００１８】
Differentiated Servicesは網境界におけるエッジルータ、および網内のコアルータを規定する。エッジおよびコアルータは異なる責務を有する。エッジルータはトラフィックがサービス協定に従うことを保証するようにトラフィックを調節しなければならない。エッジルータは、また、パケットトラフィックに適切なDifferentiated Services Code Point（“ＤＳＣＰ”）をマークし、次にＤＳＣＰに対して規定されたサービス挙動に従ってパケットを転送する。Per Hop Behavior（“ＰＨＢ”）と呼ばれるサービス挙動はそのトラフィックに異なるタイプの他のトラフィックよりも良好なトラフィックを与えるためのそのタイプのトラフィックの優先化すなわち重み付けを規定することができる。コアノードはＤＳＣＰを調べてそのサービスに対して適切なサービス挙動を適用する。
【００１９】
図４はend-to-endサービスを示す。ＤＳエッジルータがトラフィック調整を行い、ＤＳコアルータはＰＨＢを適用するだけである。
【００２０】
IntServアーキテクチュアが同質網を介したアプリケーションへのend-to-end QoSの配信手段を提供する。このend-to-endモデルをサポートするために、IntServアーキテクチュアは多様な異なるタイプの網要素を介してサポートされなければならない。この状況において、Differentiated Serviceをサポートする網は全体end-to-endパス内の網要素と見なすことができる。
【００２１】
IntServの観点から、網のDiffServ領域はIntServケーパブルルータすなわちホストを接続する仮想リンクとして扱われる（イーサネット（Ｒ）ＬＡＮが仮想リンクとして扱われるように）。網のDiffServ領域内で、ルータは特定のＰＨＢ（集合トラフィック制御）をインプリメントする。あるＰＨＢを受信するDiffServ領域内に許可されるトラフィックの総量はエッジルータにおける調整により制御される。エッジルータにおいて許可制御およびトラフィック調整を適用し、かつDiffServドメイン両端間でＲＳＶＰを使用してシグナリングすることによりDiffServドメイン両端間でIntServサービスを提供することができる。ＲＳＶＰシグナリングにおいて提供される情報はDiffServドメイン両端間のサービスに対して適切でなければならない。これは図５に示されている。
【００２２】
明確に規定された特性および機能を有するＱｏＳベアラサービスを実現するために、ベアラはサービスの送り手から受け手にセットアップしなければならない。ベアラサービスは契約したＱｏＳの提供を可能とするあらゆる側面を含んでいる。これらの側面は、とりわけ、制御シグナリング、ユーザプレーントランスポート、およびＱｏＳ管理機能である。
【００２３】
General Packet Radio Service（“ＧＲＰＳ”）およびＵＭＴＳを含む移動アクセスデータ網は全体網の一部を形成することができそれに接続された顧客に対するend-to-endベアラサービスにおいて重要な役割を果たす。したがって、ＧＰＲＳ/ＵＭＴＳを介して提供されるサービスは制御シグナリングおよびユーザプレーントランスポートの前記した側面において所要のend-to-endベアラサービスを提供するのに適切でなければならない。
【００２４】
ＧＰＲＳ/ＵＭＴＳ網は、例えば、移動局（“ＭＳ”）等のホストとユーザを接続する外部パケット交換網との間に一組の網要素を含んでいる。ホストはコンピュータ、personal data assistant（“ＰＤＳ”）等のいくつかの網通信装置の一つとすることもできる。ＭＳホストが実例として図６に示されている。
【００２５】
Gateway GPRS Support Node（“ＧＧＳＮ”）が外部パケット交換網との相互作用を提供する。
【００２６】
パケット交換（“ＰＳ”）データを送受信するために、ＭＳはそれが使用したいパケットデータプロトコルコンテキストを活性化しなければならない。この操作により対応するＧＧＳＮ内で知られ外部データ網と相互作用するＭＳを開始できるようにする。
【００２７】
ユーザデータはカプセル化およびトンネリングとして知られる方法によりＭＳと外部データ網との間でトランスペアレントに転送され、データパケットは特定ＰＳプロトコル情報を備えてＭＳおよびＧＧＳＮ間で転送される。
【００２８】
ＱｏＳは第３世代（“３Ｇ”）移動網においても極端に重要な中心的役割を果たす。ＱｏＳはエンドユーザに満足するサービスを提供する手段であり、知識に関して網管理にとっても重要である。ＱｏＳは網内のトラフィックの知識を示唆し、したがって、スペクトルリソースの効率的使用も可能とする。
【００２９】
本発明はＵＭＴＳ ＱｏＳアーキテクチュアに関して説明される。したがって、均一なレベルの理解を提供するために、ＵＭＴＳにおけるＱｏＳの技術水準の概要が与えられる。Third Generation Partnership Project（“３ＧＰＰ”） ＵＭＴＳ ＱｏＳアーキテクチュアが説明され、パケットデータプロトコル（“ＰＤＰ”）コンテキスト、トラフィックフローテンプレート（“ＴＦＴ”）、および活性化されたＵＭＴＳベアラに対するＱｏＳ保守手順の説明が含まれる。
【００３０】
無線に関連する帯域幅はend-to-endチェイン内で最も高価かつ貴重であると考えられる。ＵＭＴＳアクセス網内で、無線網リソースはＰＤＰコンテキスト粒度当たりで管理され、それはユーザフローおよびあるＱｏＳレベルに対応する。
【００３１】
Ｒ９９ ３Ｇ網に対するＱｏＳフレームワークはTS23.107 V.3.4.0.内に指定されている。主要な焦点はＵＭＴＳレベル内で使用されるＱｏＳアーキテクチュアであり、ＵＭＴＳベアラサービスおよび無線アクセスベアラサービスに適用できるＱｏＳ属性のリストが適切なマッピングルールと共に指定される。
【００３２】
TS23.060 V.3.4.0はＵＭＴＳレベル内でＰＳ接続性サービスのためにＲ９９ ３Ｇ網により使用される一般的機構を指定する。これは３Ｇ網のパケットドメインに対するサービス記述を規定し、それにはＧＳＭおよびＵＭＴＳ内のＧＰＲＳが含まれる。
【００３３】
ＵＭＴＳ ＱｏＳアーキテクチュアにおいて、網サービスは端末装置（“ＴＥ”）からもう一つのＴＥへのend-to-endと考えられる。end-to-endサービスはあるＱｏＳを有することができ、それは網サービスのユーザに与えられる。
【００３４】
ある網ＱｏＳを実現するために、明確に規定された特性および機能を有するベアラサービスがサービスの送り手から受け手にセットアップされる。ベアラサービスは契約したＱｏＳの提供を可能にするあらゆる側面、例えば、制御シグナリング、ユーザプレーントランスポート、ＱｏＳ管理機能等を含んでいる。
【００３５】
ＵＭＴＳベアラサービスレイヤードアーキテクチュアが図７に示されている。特定レイヤ上の各ベアラサービスが下のレイヤにより提供されるサービスを使用してその個別のサービスを提供する。ベアラは下層ベアラに分解され、各々が他のベアラとは独立した実現によりＱｏＳを提供する。網構成要素間でサービス協定がなされ、図７においてそれらは縦に配置されている。サービス協定はサービスの一つ以上のレイヤにより実行することができる。
【００３６】
例えば、ＵＭＴＳベアラサービスは無線アクセスベアラ（“ＲＡＢ”）サービスおよびコア網(“ＣＮ”)ベアラサービスを含んでいる。ＲＡＢサービスは無線ベアラサービスとｌｕベアラサービスに分割される。ｌｕインターフェイスは無線アクセス網とコア網間のインターフェイスである。
【００３７】
以下は図７に示すエンティティの例である。端末装置(“ＴＥ”)はラップトップコンピュータとすることができ、移動端末(“ＭＴ”)はハンドセット、例えば、移動局とすることができる。ＵＭＴＳ地上無線アクセス網(“ＵＴＲＡＮ”)はノードＢと無線網コントローラ(“ＲＮＣ”)の組合せにより構成することができる。ＣＮ ｌｕエッジノードはServing GPRS Support Node（“ＳＧＳＮ”）とすることができ、ＣＮゲートウェイ(“ＧＷ”)はＧＧＳＮとすることができる。
【００３８】
ＵＭＴＳ内のＱｏＳ管理機能は、特定のＱｏＳ属性により規定される、特定のＱｏＳによりＵＭＴＳベアラサービスを確立、修正および維持するのに使用される。組み合わされた全ＵＭＴＳエンティティのＱｏＳ管理機能が交渉したＵＭＴＳベアラサービスの提供を保証する。
【００３９】
ＵＭＴＳアーキテクチュアはコントロールパネル内の四つの管理機能およびユーザプレーンの四つの管理機能を含んでいる。コントロールパネル管理機能は、下記のものである。
対応するベアラサービスをセットアップ、制御、および終結するベアラサービス（“ＢＳ”）マネージャ。各ＢＳマネージャはサービス要求中にそのレベルの属性を基本的ベアラサービスの属性に変換もする。
外部サービスシグナリングおよびサービス属性の変換を含む内部サービスプリミティブ間の変換を行い、ＭＴおよびＧＷ内に配置される変換機能。
網エンティティが要求された特定のサービスをサポートするかどうか、また要求されたリソースが利用可能かどうかを決定する許可/ケーパビリティ制御。
ユーザが要求されているベアラに加入しているかどうかを決定する加入制御である。
【００４０】
ユーザプレーン管理機能は、
データユニットの転送を実施するベアラサービスに関連する特定のＱｏＳ表示により各データユニットをマークするマッピング機能。例えば、マッピング機能はDiffServコードポイントをパケットに付加した後でパケットをｌｕすなわちＣＮベアラに与えることができる。
ＧＧＳＮおよびＭＴ内に常駐し、外部ベアラサービス（または、ローカルベアラサービス）から受信したユーザデータユニットを、各ユーザデータユニットのＱｏＳ要求条件に従って適切なＵＭＴＳベアラサービスに割り当てる分類機能。後述するように、これはトラフィックフローテンプレート（“ＴＦＴ”）およびパケットフィルタが配置される所である。
そのリソースをそれらを要求している全ベアラサービス間に分散させるリソースマネージャ。リソースマネージャは個別の各ベアラサービスに対して要求されるＱｏＳ属性を提供しようと試みる。リソースマネージャの例はパケットスケジューラである。
ユーザデータトラフィックと関連するＵＭＴＳベアラサービスのＱｏＳ属性との適合を提供する整形およびポリシング機能であるトラフィック調整器。トラフィック調整器はＵＴＲＡＮ内だけでなくＧＧＳＮおよびＭＴ内に常駐する。
【００４１】
ＵＭＴＳベアラサービスを制御するＱｏＳ管理機能が図８に示されている。これらの制御機能の目的はＴＥ内のローカルサービスコントロールおよび外部網内の外部サービスコントロールとの相互作用を介してＵＭＴＳベアラサービスの確立および修正をサポートすることである。
【００４２】
ユーザプレーン内のＵＭＴＳベアラサービスのＱｏＳ管理機能が図９に示されている。これらの機能は、ベアラサービス属性により表わされる、ＵＭＴＳベアラサービス制御機能により確立されるコミットメントに従って一緒にデータ転送特性を維持する。ユーザプレーンはＱｏＳ属性を使用する。関連する属性がＱｏＳ管理制御機能によりユーザプレーン管理制御に与えられる。
【００４３】
四つの異なるＱｏＳクラスがＵＭＴＳ内で標準化され図１０に示されている。アプリケーションデータの対応するタイプまたはあるクラスのベアラサービスに対してデータトランスポートを最適化することができる。これらのクラス間の主要な識別要因はトラフィックがどれだけ遅延に敏感であるかということであり、従来のクラスは非常に遅延に敏感なトラフィックに対するものであり（リアルタイムサービスに対する）、背景クラスは最も遅延に鈍感なトラフィッククラスである（非リアルタイムサービスに対する）。
【００４４】
ベアラサービスを詳細に特徴づけるために、下記の表に示すように一組のベアラサービス属性がＵＭＴＳ内で標準化される。ベアラ要求条件を記述する一組の属性値を選択することによりあるＱｏＳが要求される。パラメータは要求されたベアラサービスのタイプに応じて異なる。
【００４５】
図１１はどの属性がどのトラフィッククラスに適用できるかを示す。図１２は異なるＱｏＳ属性が何のために使用されるかの概観を提供する。ＱｏＳ属性の正確な規定は、現在はバージョン3.4.0.である、TS23.107で見つけることができる。
【００４６】
加入は一つ以上のＰＤＰアドレス、すなわちＩＰトラフィックの場合のＩＰアドレス、と関連づけられる。各ＰＤＰアドレスはＭＳ，ＳＧＳＮ，およびＧＧＳＮ内に格納された一つ以上のＰＤＰコンテキストにより記述される。加入情報を保持するＨＬＲ内でデフォルト値も手に入る。各ＰＤＰコンテキストはトラフィックフローテンプレート（“ＴＦＴ”）と関連づけることができる。任意の時間にせいぜい一つのＰＤＰコンテキスト（同じＰＤＰアドレスが関連づけられる）しか存在することができず、それにはＴＦＴは割り当てられない。ＰＤＰアドレス、ＰＤＰコンテキスト、およびＴＦＴ間の関係は図１３に与えられている。
【００４７】
ＰＤＰコンテキストはＭＳおよびＧＧＳＮ間でＰＤＰ ＰＤＵを転送するために必要な全情報、例えば、アドレッシング情報、フロー制御変数、ＱｏＳプロファイル、課金情報等、を含むデータエントリのダイナミックテーブルである。ＵＭＴＳベアラサービスとＰＤＰコンテキスト間の関係は一対一マッピングである、すなわち一つのＰＤＰアドレスに対して二つのＵＭＴＳベアラサービスが確立される場合には、二つのＰＤＰコンテキストが規定される。
【００４８】
ＰＤＰコンテキスト手順は、現在はバージョン3.4.0である、TS23.060内で標準化されている。ＱｏＳプロファイルおよびトラフィックフローテンプレート（“ＴＦＴ”）を取り巻く概念はＱｏＳの観点から適切である。
【００４９】
ＵＭＴＳ ＱｏＳ属性は主として効率的な無線実現をサポートするために選択され規定されている。ＱｏＳプロファイルは一組のＵＭＴＳ ＱｏＳ属性により規定される。ＲＮＣはＰＤＰコンテキスト活性化中に関連するＲＡＢ ＱｏＳプロファイルをＳＧＳＮから得る。ＰＤＰコンテキスト活性化内に含まれる三つの異なるＱｏＳプロファイルがある−要求されたＱｏＳプロファイル、交渉したＱｏＳプロファイル、および加入したＱｏＳプロファイル（すなわちデフォールトＱｏＳプロファイル）。
【００５０】
表１に示すように、必要な情報のタイプに応じて、格納されたＰＤＰコンテキスト情報はＭＳ，ＲＮＳ，ＳＧＳＮ，ＧＧＳＮ，およびＨＬＲが異なる。
【表１】
【００５１】
ＴＦＴはパケットを正しいＰＤＰコンテキストに関連づけて、適切なＧＰＲＳトンネリングプロトコル（“ＧＴＰ”）トンネル内に転送されることを保証するパケットフィルタ（または、フィルタセット）である。ＴＦＴは、単一ＰＤＰアドレスに関連づけられた、変動するＱｏＳプロファイルを有するいくつかのＰＤＰコンテキストを有する可能性を可能とする。ＴＦＴはアップリンクおよびダウンリンクフローの両方に対してＭＴにより管理され開始される。アップリンクＴＦＴはＭＴ内に常駐し、ダウンリンクＴＦＴはＧＧＳＮ内に常駐する。ダウンリンクＴＦＴはＰＤＰコンテキスト活性化/修正中にＭＴからＧＧＳＮに送られる。ダウンリンクＴＦＴは１なしで作り出されたＰＤＰコンテキストに加えることができ、コンテンツは修正することもできる。
【００５２】
図１４はＴＦＴパケットフィルタ属性および有効な組合せを示す。各ＴＦＴは識別子および同じＰＤＰアドレスを共有するＰＤＰコンテキストに関連づけられた全てのＴＦＴ内で一意的な評価優先インデクスを有する。ＭＳはパケットフィルタコンテンツだけでなくＴＦＴの識別子および評価優先インデクスを管理する。
【００５３】
図１４におけるいくつかの属性はパケットフィルタ内に共存することができ他は互いに排除する。単一パケットフィルタに対しては“Ｘ”をマークした属性しか指定することができない。マークされた全属性を指定することができ、少なくとも一つを指定しなければならない。
【００５４】
ＰＤＰコンテキストシグナリングは要求され交渉したＱｏＳプロファイルをＵＭＴＳ網内のノード間で運ぶための手段である。ＰＤＰコンテキストシグナリングはＱｏＳレベル上のベアラの許可制御、交渉、および修正に関してＱｏＳ処理に対する中心的役割を有する。図１５の数字を参照して以下にＰＤＰコンテキストシグナリングメッセージ交換について説明する。
【００５５】
ステップ１において、ＲＲＣ接続が確立される。この手順はＭＳおよびＵＴＲＡＮ間の接続を確立するのに必要である。しかしながら、ＱｏＳ観点から、確立フェーズは典型的に使用されている無線チャネルのタイプを表示する以外はほとんどなにも行わない。
【００５６】
ステップ２において、ＭＳはＳＧＳＮにＰＤＰメッセージを送ってＰＤＰコンテキストを活性化させる。要求されたＱｏＳプロファイルはこのメッセージ内に含まれる。この段階において、ＳＧＳＮは許可チェックを行いシステムが過負荷であれば要求されたＱｏＳを制限することができる。
【００５７】
ステップ３において、ＳＧＳＮはＲＡＮＡＰメッセージ“ＲＡＢ割当て要求”をＲＮＣに送る。ＲＡＮＡＰ、すなわち無線アクセス網アプリケーション部、は無線アクセス網（“ＲＡＮ”）および外部ＣＮ間のシグナリングおよび制御伝送をサポートするアプリケーションプロトコルである。ＲＡＮＡＰはＲＡＮおよび回線交換またはパケット交換網間の通信を許す。無線アクセスベアラサービスを確立するこの要求はＲＡＢ ＱｏＳ属性を運び、それはＳＧＳＮにより修正されていることがある。
【００５８】
ステップ４において、ＲＮＣはＲＡＢ ＱｏＳ属性を使用してＱｏＳプロファイルに対応する無線関連パラメータを決定する。これらのパラメータはトランスポートフォーマットセットおよびトランスポートフォーマット組合せセットを含むことができる。さらに、ＵＴＲＡＮがこのベアラの許可制御を実施する。
【００５９】
ステップ５において、ＲＮＣはＲＲＣメッセージ、“無線ベアラセットアップ”をＭＳに送る。ＲＲＣメッセージはステップ４において決定された無線関連パラメータを含んでいる。
【００６０】
ステップ６において、ＵＴＲＡＮおよびＭＳは無線パラメータを適用しトラフィック転送準備が完了する。これをシグナルするために、ＭＳは“無線ベアラセットアップ完了”ＲＲＣメッセージをＲＮＣに送る。
【００６１】
ステップ７において、ＵＴＲＡＮは“ＲＡＢ割当て完了”ＲＡＮＡＰメッセージをＳＧＳＮに送る。
【００６２】
ステップ８において、トレース手順を開始することができる。これは加入者を監査する動作および保守機能である。
【００６３】
ステップ９において、ＳＧＳＮは“ＰＤＰコンテキスト要求生成”をＧＧＳＮに送り、ＱｏＳプロファイルを運ぶ。しかしながら、ＱｏＳプロファイルはステップ２においてＭＳにより要求されるものとは異なるパラメータを有することがある。このプロファイルに基づいて、ＧＧＳＮレベルで許可制御が実行され、例えば、システムが過負荷であればＧＧＳＮはＱｏＳを制限することができる。ＧＧＳＮはＰＤＰコンテキストをそのデータベース内に格納する。
【００６４】
ステップ１０において、ＧＧＳＮは交渉したＱｏＳを“ＰＤＰコンテキスト応答生成”メッセージ内のＳＧＳＮに戻し、ＳＧＳＮはＰＤＰコンテキストをそのデータベース内に格納する。
【００６５】
ステップ１１において、交渉したＱｏＳはＳＧＳＮから“アクティブＰＤＰコンテキスト受理”メッセージ内のＭＳに送られる。ＳＧＳＮまたはＧＧＳＮがＱｏＳプロファイルを修正しておれば、ＭＳはこのプロファイルを受理または拒否しなければならない。
【００６６】
手順内で行われるいくつかのローカル許可制御がある。しかしながら、無線に関連する帯域幅は最も高価なリソースであるため、ＵＴＲＡＮに相談してＰＤＰコンテキスト活性化または修正中に無線リソースを利用できるかどうかを決定する。したがって、ＵＭＴＳ内での許可制御は無線中心で実施される。
【００６７】
ＩＰ ＱｏＳ end-to-endを提供するために、各ドメイン内のＱｏＳを管理することが必要である。ゲートウェイ内のＩＰ ＢＳマネージャが外部ＩＰベアラサービスを制御するのに使用される。ＩＰ網内で使用される異なる技術により、これは変換機能を介してＵＭＴＳ ＢＳに伝えられる。
【００６８】
同様に、ＵＥ内に提供されるＩＰベアラサービスマネージャ機能も必要とされており、ベアラサービスマネージャはアプリケーションのＱｏＳ要求条件を適切なＱｏＳ機構にマッピングする。
【００６９】
図１６はＵＥおよびゲートウェイノード内の両方の可能な場所においてＩＰ ＢＳマネージャを使用するＩＰサービス制御の実施例を示す。図１６はＵＥおよびゲートウェイノード内のＩＰ ＢＳマネージャ間のオプショナル通信パスも示している。
【００７０】
ＩＰ ＢＳマネージャは標準ＩＰ機構を使用してＩＰベアラサービスを管理する。これらの機構はＵＭＴＳ内で使用されるものとは異なることがあり、サービスを制御する異なるパラメータを有することがある。変換/マッピング機能はＵＭＴＳベアラサービス内で使用される機構およびパラメータとＩＰベアラサービス内で使用されるものとの間の相互作用を提供し、かつＩＰ ＢＳマネージャと相互作用する。
【００７１】
ＩＰ ＢＳマネージャがＵＥおよびゲートウェイノード内の両方に存在する場合には、これらのＩＰ ＢＳマネージャは関連するシグナリングプロトコルを使用して互いに直接通信することができる。
【００７２】
ＩＰマルチメディアサービス（“ＩＭＳ”）がＧＰＲＳベアラサービスの頂部に規定される。ＩＰマルチメディアサービスはユーザへのマルチメディアセッションを提供する。ＩＰマルチメディアをサポートするベアラのＱｏＳ側面はTS23.207に規定されＩＰマルチメディア（“ＩＭ”）仕様はTS23.228に規定されている。
【００７３】
ＩＭＳは、例えば、セッション開始プロトコル（“ＳＩＰ/ＳＤＰ”）等のＩＰアプリケーションシグナリングに基づいている。エンドユーザはシグナリングＧＰＲＳベアラ上のセッションを要求し、それはセッションセットアップの前に確立されなければならない。図１７はＩＰマルチメディアシステムのＧＰＲＳベアラとの相互関係を示す。ＧＰＲＳベアラは端末ＡまたはＢ１７００，１７５０とＵＭＴＳ網１７１０，１７６０およびバックボーン１７４０間の各ゲートウェイ１７２０，１７７０との間に確立される。ゲートウェイはいくつかのＧＰＲＳユーザからのトラフィックの集約ポイントとしての働きもする。
【００７４】
一つのＧＰＲＳベアラは遠隔端末１７００，１７５０と交換されてＩＭセッションをセットアップするアプリケーションレベルシグナリング１７８０（ＳＩＰ/ＳＤＰ等）を運ぶ。アプリケーションは網内の一つまたはいくつかのプロクシによりサポートされる。実際のメディアストリームを運ぶために、一つのＧＰＲＳベアラが各メディアストリームに対して集約ポリシー１７２０，１７７０まで確立される。専用ＧＰＲＳベアラおよびバックボーンを介した共有集約トランスポートによりリソースがend-to-endで利用できる場合には、マルチメディアセッションが接続されて開始することができる。このようにして、いくつかのパラレルＧＰＲＳベアラがマルチメディアセッションをサポートするように確立される。
【００７５】
一般的に、ＱｏＳプロトコルは必要な網リソースを保存しトラフィックを区別する機構を提供し、ポリシールールはそれらがどのように使用されるかを規定する。例えば、ＩＥＴＦ ＱｏＳ機構ＲＳＶＰおよびIntServは、それぞれ、リソース保存セットアッププロトコルおよび一組のサービス規定を規定する。しかしながら、IntServの許可制御機構は許可制御の重要な側面を含んでいない。特に、網マネージャおよびサービスプロバイダは、ユーザおよびアプリケーションのアイデンティティ/オーソリティレベル（例えば、マネージャ、エンジニア、見習い、等）、トラフィック帯域幅要求条件（例えば、狭帯域、広帯域、等）、セキュリティ配慮（例えば、ミッションクリティカルリソースへのアクセス）、および一日の時間/週、等の規準から引き出されるポリシーに基づいて網リソースおよびサービスの使用を監視、制御および実施できなければならない。
【００７６】
トラフィックオーナー、エンドユーザ、アプリケーション、イーサネット（Ｒ）ホスト、等に要求するサービスが与えられる変動する状況があるため、ルール、これらのルールの実施方法およびそれらをいつ適用するかの“判断”が必要である。したがって、ポリシーシステムの三つの主要な構成要素はポリシールールおよびそれらの記憶装置（典型的にはポリシーデータベース内の）、ポリシー実施ポイント（“ＥＰ”）を使用する実施方法、およびポリシー判断ポイント（“ＤＰ”）である。さらに、ＩＥＴＦはCommon Open Policy Service (“COPS”)条項でＥＰおよびＤＰ間の情報交換プロトコルを標準化している。
【００７７】
ポリシーは特定の状況が存在する時に一つ以上のアクションを生じるルールの集まりと見なすことができる。ＩＥＴＦポリシーフレームワークが図１８に例示されている。ＥＰとＤＰおよびＤＰとポリシーレポジトリ間の分離は機能性およびオープンインターフェイスに基づいた論理的なものであり、必ずしも物理的な分離ではない。また、網ドメイン内には典型的に多数のＥＰがあり、各ＥＰ上に多数のインターフェイスがあることもある。例えば、管理ドメインの全てのまたはいくつかのルータはＩＰ網内にＥＰ機能をインプリメントすることができ、中央サーバはそのドメイン内にＤＰ機能をインプリメントすることができる。次に、ＤＰはポリシー（ルール）レポジトリに接続しポリシー判断を行うためにそこからデータをフェッチすることができる。例えば、Lightweight Directory Access Protocol（“ＬＤＡＰ”）をＤＰとポリシーレポジトリ間のプロトコルとして使用することができる。ＤＰは他のプロトコル、例えば、Simple Network Management Protocol（“ＳＮＭＰ”）を使用して網管理エンティティ等の他の網構成要素にポリシー情報を伝達かつエクスポートすることができる。
【００７８】
３Ｇ網内で、ＧＧＳＮは３Ｇリソースを容易に制御することができるゲートウェイノードとして作用するため、適切なＥＰとすることができる。ＤＰ（しばしば、ポリシーサーバ（“ＰＳ”）と呼ばれる）はＧＧＳＮの内部または外部に常駐することができる。しかしながら、典型的にＤＰはＧＧＳＮから分割されＰＳとＧＧＳＮとの間にオープンインターフェイスがある。
【００７９】
ポリシーシステムの異なる機能が別々の論理エンティティ内に配置されるため、ポリシー（データベース）、ポリシークライアント（エンホーサ）、およびポリシーサーバ（デシジョンメーカ）間の媒介として機能するポリシートランザクションプロトコルが必要である。ポリシートランザクションプロトコルはこれら二つのノード間でポリシー要求およびポリシー応答を転送する責任がある。このようなポリシートランザクションプロトコルに対するデファクト標準はＩＥＴＦ標準化プロトコルＣＯＰＳである。
【００８０】
ＣＯＰＳはポリシーサーバとそのクライアント間でポリシー情報を交換する単純な質問-および-応答プロトコルである。ポリシーサーバが判断を行うと、ポリシークライアントはその特定のポリシー判断の実施に対する責任がある。また、ＣＯＰＳはその判断の有効性を決定するためにポリシークライアントおよびポリシーサーバ間でポリシー制御判断を伝達できるようにするユニークな特徴を有する。現在、ＣＯＰＳは主としてＲＳＶＰ許可制御プロトコルとして使用されているが、ＩＥＴＦはＣＯＰＳを一般化されたポリシー通信プロトコルとして拡張するアイデアを現在検討している。
【００８１】
ＧＰＲＳ ＩＰ接続性およびＩＰマルチメディアサービスの両方を提供するオペレータにとって、ＩＭＳユーザおよびＧＰＲＳ ＩＰ接続性ユーザを課金、優先化、その他の目的について異なる取り扱いをする能力を有する必要がある。例えば、高ＱｏＳベアラのＧＰＲＳベアラはＩＭＳメディアをトランスポートするのにしか使用許可されないようにしなければならない。この要求条件は接続するサブネットワークやサービス網、あるいは操作するアプリケーションに応じて、異なるタイプのベアラを制御するように論理的に拡張することができる。この要求条件はアプリケーションから制御されるＧＰＲＳベアラタイプの制限を許すように論理的に拡張することもできる。
【００８２】
オペレータが適用したい制限は、例えば、網に入ることが許されるデータに対する受け手の厳格な制御であり、それはサービスが受け手に依存して課金されることがありかつ/または接続のためのリソース保存を実施することがあるためである。
【００８３】
課金がＩＭセッション開始からＩＭセッション終りまでの時間に基づく場合には、ユーザは課金されずにこれらのベアラリソースを使用することができない、すなわち、いかなる期間でも課金されずにアクセス網リソースを利用することをユーザに許可すべきではないことが絶対必要である。
【００８４】
従来のＧＰＲＳおよびＩＭＳ機構は現在セッション状態に無関係にベアラサービスが確立されることを許す。ユーザは呼課金を開始する前にアクセス網（例えば、ＵＭＴＳ）リソースを使用することを許されるが、アクティブフェーズの前の非認可データフローに対してはアクセスベアラ用課金レートが適用される。すなわち、アクセスベアラに適用される料金は現在のセッション状態に応じて異なる。セッションが既に存在する場合には、アクセスベアラ料金は無いことがあるが、それが存在しない場合には、たとえベアラ上で送られた任意のデータがその後廃棄されてもアクセスベアラ料金があることがある。この方法を使用することの欠点は非常に複雑な課金モデルが必要とされることである。
【００８５】
さらに、認可されず適切に課金されないリソースは保存すべきではない。しかしながら、音声クリッピングを回避するために、ベアラはイベントを介してセッションを開始する前に利用でき確立できなければならない。したがって、衝突する事柄がある。
【００８６】
したがって、ポリシー機構を使用する網データフローのより良好なフィルタリングおよびゲーティング制御が必要とされている。
【００８７】
（発明の開示）
本発明はTS23.207に規定されたアーキテクチュアを使用して、ＵＭＴＳ/ＧＰＲＳ網等の、パケットデータ網におけるＱｏＳ接続を介したデータフローのポリシー駆動フィルタリングおよびゲーティングを提供するポリシー機構を利用してこれらおよびその他の問題に取り組むものである。ローカルＳＩＰプロクシサーバは任意のローカルアプリケーションサーバとすることができ、ポリシー制御機能（“ＰＣＦ”）がポリシーサーバ等の個別のノード内に配置され、アプリケーションサーバとＰＣＦとの間およびＧＧＳＮとＰＣＦとの間にはインターフェイスがある。
【００８８】
一側面に従って、ポリシー制御機構を使用するパケットデータ網内の遠隔ホストとユーザ装置間のＱｏＳ接続においてデータフローをフィルタリングおよびゲーティングする方法は、ＳＩＰプロクシサーバ、リアルタイムストリーミングプロトコル（“ＲＴＳＰ”）サーバ、またはend-to-endシグナリングにより制御されるＩＰベースアプリケーションをサポートする任意タイプのＩＰベースアプリケーションサーバ等のアプリケーションサーバ内のアプリケーションを開始し、かつアプリケーションサーバを介して遠隔ホストとＵＥ間の対応するセッションを開始する遠隔ホスト、またはユーザ装置間、を含んでいる。ＵＥは、網のＧＧＳＮに、ＵＥと遠隔ホスト間の網ベアラサービスの確立を要求する。ポリシーサーバ内の対応するＰＣＦが、アプリケーションサーバから、セッション中にアプリケーションサーバにより受信されたセッションデータから引き出されたフィルタリングデータを受信する。ＧＧＳＮはポリシーサーバ内の対応するＰＣＦに問い合わせてＧＧＳＮにおけるポリシー制御フィルタリングデータを使用してゲートを初期化する。次に、ゲートはポリシー制御フィルタリングデータに従ってＱｏＳ接続内のデータフローをフィルタリングする。
【００８９】
もう一つの側面に従って、アプリケーションサーバがイベントトリガをポリシーサーバに送ってゲート開放を要求し、ポリシーサーバが対応するゲートオープンコマンドをゲートウェイサポートノードに送ってゲートを開く時にゲートが開かれる。ポリシー制御フィルタリングデータに従ってフィルタリングされるデータフローによりＱｏＳ接続内のデータフローを開始するゲートウェイサポートノードによりゲートが開かれる。
【００９０】
さらにもう一つの側面に従って、アプリケーションサーバがイベントトリガをポリシーサーバに送ってゲート閉成を要求し、ポリシーサーバが対応するゲートクローズコマンドをゲートウェイサポートノードに送ってゲートを閉じる時にゲートが閉じられる。ゲートはＱｏＳ接続内のデータフローを終了するゲートウェイサポートノードにより閉じられる。また、セッションはアプリケーションサーバにより終結され網ベアラサービスが終結される。
【００９１】
さらにもう一つの側面において、アプリケーションサーバはオープンインターフェイスを介してポリシーサーバと情報を交換する。
【００９２】
さらにもう一つの側面において、ポリシー制御機能からゲートウェイサポートノードにポリシー判断を転送するのにＣＯＰＳプロトコルが使用される。ポリシー制御機能はＣＯＰＳポリシー判断ポイントとして作用し、ゲートウェイサポートノードはＣＯＰＳポリシー実施ポイントとして作用する。ポリシー実施ポイントはパケット分類子とマッチする所与のＩＰパケットセットに対するＱｏＳにアクセスする。ポリシー判断はポリシー制御機能によりゲートウェイサポートノードにプッシュされるか、あるいはＩＰベアラリソース要求を受けた時にゲートウェイサポートノードがポリシー制御機能からのポリシー情報を要求する。
【００９３】
（詳細な説明）
以下に添付図を参照して本発明の好ましい実施例について説明する。以下の説明では、不要な詳細により本発明が判らなくなるのを回避するために既知の機能および/または構造については詳細に説明はしない。
【００９４】
以下の説明において、ユーザ装置（“ＵＥ”）はユーザが網サービスにアクセスできるようにする装置である。３ＧＰＰ仕様の目的で、ＵＥと網間のインターフェイスは無線インターフェイスである。ＵＥはいくつかのドメインに細分することができ、ドメインは基準点により分離される。ＵＥをいくつかのドメインに分離する側面は本発明の説明には不要であり、したがって、明細書の一部ではない。
【００９５】
無線アクセス網ドメインは、そのリソースを管理する、物理的エンティティを含みコア網にアクセスする機構をユーザに提供する。アクセス網ドメインはアクセス技術に特有の機能を含んでいる。
【００９６】
再び図面に戻って、図１９は本発明に従ってポリシー制御機能を有する制御プレーン内のＵＭＴＳに対するＱｏＳ管理機能およびend-to-end ＩＰ ＱｏＳに対するＱｏＳ管理機能のブロック図である。図２０の制御フロー図を参照して、遠隔ホストがここでは電話呼であるアプリケーションをＳＩＰシグナリングを使用して開始する（１）。ＳＩＰシグナリングは網内のＳＩＰプロクシサーバ内を通過する。ＳＩＰセッションは電話網のアドレススペース内に常駐するそれらのＩＰアドレスにより電話網内のエンドポイントを識別する。しかしながら、呼がこの電話網内で終端しなければ、アドレスはベアラが通過する電話網内のゲートウェイアドレスである。
【００９７】
セッションが開始された後で（２）、ＵＥはデータプレーンに対するＱｏＳイネーブルドＧＰＲＳベアラを確立する必要がある。これはセッションに対する必要条件の一部としてセッション確立中に生じることがある。ＵＥは、従来のベアラのような、要求された特性に基づいて使用されるアクセスベアラタイプを選択しなければならず、ベアラレベルに対するＰＤＰコンテキストを開始する。
【００９８】
次に、ＵＥはＵＭＴＳベアラの確立を要求する（３）。ＧＧＳＮ内の変換/マッピング機能がアクセス網を介して使用するために提供されるＩＰサービスの詳細説明内にＵＭＴＳベアラサービスをマッピングする。ＧＧＳＮ内で、ベアラ要求はＰＣＦと関連づけられ、ＧＧＳＮがそれに問い合わせて特定アクセスＩＰベアラサービスの確立が許可されるかどうかを決定する（４）。ＰＣＦはローカルＳＩＰプロクシサーバの包含等の網要因に応じて特定のアクセスベアラの使用を制限するルールを適用することができる。ＰＣＦはローカルＳＩＰプロクシサーバがこの接続に使用されていることを知らされるため、このベアラタイプの使用が認可される。
【００９９】
アクセスベアラを確立する機関は電話網にデータを送信する機関から独立している。ベアラが確立されると、どのデータが電話網に入るのを許可されるかを制御するＧＧＳＮにおいて“ゲート”が確立される（６）。このゲートは、ＤＳエッジ機能と同様な、データの分類およびポリシングを実施する。ゲートはＰＣＦを介してアプリケーションから受信されるデータにより制御される。
【０１００】
アクティブフェーズに達するセッションの前に、ＵＥはアクセスベアラの提案された使用に関するデータをＧＧＳＮに送ることができる。この情報はＲＳＶＰ等のＩＰレベルシグナリングを介してＧＧＳＮに送ることができ、あるいはＧＰＲＳベアラパラメータから引出すことができる。
【０１０１】
ＧＧＳＮがこのベアラに対するトラフィック使用に関する情報を受信すると、ＩＰ ＢＳマネージャはベアラの使用を認可することができる（５）。提案された使用がＳＩＰプロクシサーバにより認可されたものと一致しなければ、ＧＧＳＮはベアラ確立、またはＲＳＶＰの場合のセッション確立を拒否することができる。この時までにＳＩＰプロクシサーバは認可されたトラフィック記述子に関する情報をＰＣＦに供給していなければならない（２）。
【０１０２】
セッションが適切な状態に達すると（すなわち、アクティブフェーズ）、ＳＩＰプロクシは“session thru”イベントトリガをＰＣＦに送り、それはゲートオープンコマンドをＧＧＳＮに送るようＰＣＦに通知し、ＧＧＳＮにおいてゲートが開いてユーザ装置からのデータを網に入れることができる（７）。
【０１０３】
セッションが終了すると、ＳＩＰプロクシサーバはセッションおよびベアラレベルの両方に対する認可を取り消す。また、ＳＩＰプロクシサーバはＧＧＳＮから電話網に向かって開いているゲートも閉じる。このアクションはいくつかの異なるレベルで生じる。ＳＩＰプロクシサーバは直接ＵＥへのセッションを終結して“セッション終結”イベントトリガをＰＣＦに送り、それはゲートクローズコマンドをＧＧＳＮに送るようＰＣＦに通知し、ＧＧＳＮにおいてゲートが閉じる。最後に、ベアラ終結がまだＵＥから開始されていなければ、ＳＩＰプロクシサーバはベアラを終結させる情報をＰＣＦに送る。
【０１０４】
あるいは、ＰＣＦはさまざまな機能に制御を適用したい情報を異なるアプリケーションから受信することができる。網内のアプリケーションサーバサポートはプロクシサーバ、網内のリアルタイムストリーミングプロトコル（“ＲＴＳＰ”）サーバ、または任意タイプのＩＰベースアプリケーションサポートにより提供することができ、ＩＰベースアプリケーションはend-to-endシグナリングにより制御される。異なるアプリケーションがＧＧＳＮ内で制御している機能は同じであることがあるが、アプリケーションにより供給される実際の情報およびその情報がどのように使用されるかは異なることがある。したがって、ＰＣＦとアプリケーションとの間にはある範囲のプロトコルがあることがある。
【０１０５】
セッションはベアラサービスが認可される前に適切な状態でなければならない。ＧＧＳＮ内のＩＰ ＢＳマネージャがＰＣＦとコンタクトする時は、ＰＣＦはＵＥがベアラタイプに対して認可されるかどうかだけでなく、この時接続がなされることをアプリケーションが認可しているかどうかも判断する。特定のアプリケーションに対していくつかのイベントトリガを規定することができる。アプリケーションイベントが生じる時は、アプリケーションサーバからＰＣＦにイベントトリガが送られる。ＰＣＦにおいて、これはＧＧＳＮに送られるコマンドおよび、前記した典型的な“session thru”および“session termination” イベントトリガのような、ＧＧＳＮ内の対応するポリシー実施アクションとなる。
【０１０６】
ＩＰ ＢＳマネージャにより適用されることがあるポリシー実施内に異なるアクションがある。例えば、ゲートを通ることが許されないデータが受信される場合には、ＩＰ ＢＳマネージャはデータを廃棄したりベアラを終結させる等のアクションをとることができる。ＩＰ ＢＳマネージャと各ポリシー機能に対するＰＣＦとの間で使用されるプロトコルを選択する時は、ポリシー実施オプションの範囲を決定して考慮しなければならない。
【０１０７】
本発明の一つの側面はＧＧＳＮ内の“ゲーティング”機能がＰＣＦを介してＳＩＰプロクシサーバから構成データを受信することである。構成データは一つだけの受け手アドレスに使用を制限する。
【０１０８】
もう一つの実施例では、本発明はＵＭＴＳおよびＧＰＲＳシステムに適用されるＣＯＰＳの専門用語、概念およびフレームワークを使用して説明される。ＩＰポリシーフレームワークおよびプロクシを取り巻くＩＥＴＦにおける最近の発展はベストエフォートサービスよりも良好なサービスに支出したいユーザに適切なＱｏＳを有するサービスを提供する産業攻勢を反映している。この課題の関連するＩＥＴＦ ＲＦＣは[RFC 2573]“A Framework for Policy-based Admission Control”, [RFC 2748]“The COPS Protocol”, [RFC 2749]“COPS usage for RSVP”,等を含んでいる。
【０１０９】
ＵＭＴＳに利用されるＰＣＦ機能はメインストリームＩＰコミュニティにおける専門的技術および開発に勢力を与えるＩＥＴＦ標準に従わせることができる。
【０１１０】
ＰＣＦは標準ＩＰ機構を使用してＩＰベアラレイヤ内にポリシーをインプリメントする論理的ポリシー判断要素である。これらの機構は、例えば、ＩＥＴＦ[RFC 2753]“A Framework for Policy-based Admission Control”に従うことができ、ＰＣＦは実際上ＤＰである。ＰＣＦはポリシールールを使用して網ベースＩＰポリシーに関する判断を行い、これらの判断をＩＰ ＥＰであるＧＧＳＮ内のＩＰ ＢＳマネージャに伝える。
【０１１１】
ＰＣＦおよびＧＧＳＮ間のプロトコルインターフェイスはＧＧＳＮ内のＤＰおよびＩＰ ＢＳマネージャ間の情報およびポリシー判断の転送をサポートする。
【０１１２】
ＣＯＰＳプロトコルはＥＰおよびＰＣＦ間のクライアント/サーバプロトコルとして使用される。ＣＯＰＳクライアント（ＥＰ）はＱｏＳイネーブルド無線ベアラ要求メッセージによりトリガされるＰＣＦからポリシー情報を要求することができる。あるいは、例えば、ＳＩＰプロクシを通すＳＩＰメッセージによりトリガされる外部out-of-band ＱｏＳサービス要求、あるいは網内の任意のアプリケーションサーバを通す他のアプリケーションシグナリングに基づいてＰＣＦが行ったポリシー判断をＣＯＰＳクライアント（ＥＰ）にプッシュすることができる。これらのポリシー判断はＥＰによりアクセスされるローカルポリシー判断ポイント内のＣＯＰＳクライアント（ゲートウェイ内）内に格納されてＰＣＦとの追加インタラクション無しで許可制御判断を行う。
【０１１３】
ＰＣＦはＳＩＰプロクシから内部で得られる情報に基づいてポリシー判断を行う。ＰＣＦはＧＧＳＮと同じドメイン内にあるか、あるいはＧＧＳＮと信頼関係を有する。
【０１１４】
ＥＰはＵＭＴＳアーキテクチュア要求条件を満たすためにＧＧＳＮ内のＩＰベアラサービスマネージャ内にインプリメントされる。ＥＰはパケット分類子とマッチする一組のＩＰパケットに対するＱｏＳへのアクセスを制御する。ポリシー判断はポリシー制御機能によりＧＧＳＮに“プッシュされる”か、あるいは、ＧＧＳＮはＩＰベアラリソース要求を受信するとポリシー制御機能からポリシー情報を要求することができる。
【０１１５】
ポリシー実施はＧＧＳＮ内にインプリメントされたゲートに関して規定される。ゲートはパケットの一方向フロー、例えば、アップストリームまたはダウンストリーム方向に対するポリシー実施機能である。ハイレベルにおいて、ゲートはパケット分類子、リソース“エンベロープ”、および分類子にマッチするパケットセットがリソースエンベロープを越える時にとられるアクションを含んでいる。
【０１１６】
ＩＰベアラサービスリソース割当ての基本単位は一方向フローに対するものであるため、一方向ゲートが使用される。例えば、ＵＥ上のアプリケーションが受信オンリーモードでＩＰマルチキャストセッションに加入している時はダウンストリームオンリーゲートが使用される。ＩＰ電話アプリケーションにおける“遠隔呼出”をサポートするのにダウンストリームオンリーフローも必要であり、呼出信号はＰＳＴＮゲートウェイまたは遠隔ＵＥにより遠隔発生される。このアプリケーションに対して、サービスシナリオのある盗難を回避するために、遠隔ＵＥがピックアップするまでパケットのアップストリームフローをイネーブルしないで、セッションオリジネータへのパケットのダウンストリームフローをイネーブルする必要がある。パケットの両方向フローに対するＱｏＳへのアクセスが所望される場合には、一対のゲートが使用される。
【０１１７】
次に、ゲートと関連づけることができる情報について説明する。この情報は必ずしも使用することができる唯一の情報ではなく、現在理解されたアプリケーションのいくつかをカバーするものである。ゲートは下記の情報により記述される。
【表２】
【０１１８】
各ゲートに関連づけられるパケット分類子は下記の情報により記述される。
【表３】
【０１１９】
方向はゲートがアップストリームゲートであるかダウンストリームゲートであるかを示す。ＧＧＳＮにおいて見られるように、送り手ＩＰアドレスおよびポートは送り手ＩＰｖ４またはＩＰｖ６アドレスおよびポートを識別する。ＧＧＳＮにおいて見られるように、受け手ＩＰアドレスおよびポートは受け手ＩＰｖ４またはＩＰｖ６アドレスおよびポートを識別する。プロトコルフィールドはパケットのＩＰプロトコルタイプを識別する。方向を除いて、フィールドにワイルドカードを使用することができる。例えば、ＳＩＰセッション内で、ベアラに対する送り手ポートはＳＩＰシグナリングメッセージ内で交換されず、したがって、ゲートが初期化される時にセットアップすることができない。
【０１２０】
認可されたエンベロープはパケット分類子により規定されたパケットセットに対して認可されるリソースの上部境界、すなわち“エンベロープ”、を規定する。認可されたエンベロープは実際に使用されるよりも多くのリソースを認可することができる。認可されたエンベロープは外部網に対するＩＰベアラリソースを規定するため、ピーク情報レート、平均情報レート、および外部網に対するトークンバケットサイズ等のＩＰベアラリソースに関してそれを表現するのが適切である。例えば、InsServ Flowspec はＩＰベアラリソースの適切な表現である。認可されたエンベロープは必要ならばＧＧＳＮ内の変換機能により（ある範囲の）ＵＭＴＳベアラリソースにマッピングされる。認可されたエンベロープにより、ＵＥがリソースの割当てを要求する前に、ＰＣＦはフローを予認可することができる（“プッシュモード”）。
【０１２１】
このアクションはパケット分類子により規定されたパケットセットが認可されたエンベロープまたは保存されたエンベロープ（下記に規定される）を越える時にどんなアクションがとられるかを規定する。このアクションは特異なDiffServ Code Point（“ＤＳＣＰ”）で out-of-profile をマーキングする、特異なＤＳＣＰで in-profile パケットをマーキングする、トークンバケットに整形する、またはパケットドロッピングすることを含む。
【０１２２】
前記規定に従って、一組のパケットは二つ以上の分類子とマッチすることができる。これが生じると、適用可能な各ゲートに関連づけられるアクションは、ゲートがＧＧＳＮ内に構成された順序で、逐次実行されると考えられる。ゲートによりマーキングされたパケットは後続ゲートによりより良いサービスクラスに対応するＤＳＣＰに再マーキングされないことがある。
【０１２３】
リソース識別子は、例えば、いくつかのセッションに対する多数のゲートにより共有されることがある一組のリソースを識別する。例えば、リソース識別子はＵＥが、呼待機中等に、リソースを同時使用しない二つのセッションに対して一組のリソースを共有できるようにする。リソース識別子はＰＤＰコンテキスト活性化/修正要求のＩＰベアラサービス情報要素内に含められてこの機能をサポートする。
【０１２４】
保存されたエンベロープはベアラに対して保存されるリソースの上部境界すなわち“エンベロープ”を規定する。保存されたエンベロープはＵＥに対して実際に使用されるよりも多くのリソースを保存できる場合に有利である。例えば、呼待機中に、ＵＥはアクティブセッションに対しては低品位コーデックを使用しながら一時的なイナクティブセッションに対しては高品質コーデックの保存を維持することができる。保存されたエンベロープはリソース保存が許可制御を実施することを暗示し、成功すれば、要求されたリソースをプリアンブルモードにしておく。この機能のサポートには保存要求とリソース使用とを区別するＰＤＰコンテキスト活性化および修正手順が必要である。
【０１２５】
認可トークンはＧＧＳＮにおける一つ以上のゲートに対応するポリシー情報を一意的に識別する。認可トークンはＵＥからのリソース保存要求（例えば、ＰＤＰコンテキスト活性化要求）をＰＣＦからの認可コマンドと相関させるのに使用することができる。この機能をサポートするために、認可トークンはＰＤＰコンテキスト活性化要求（無線ベアラセットアップ要求）、ポリシー制御インターフェイス（判断がＰＣＦからＧＧＳＮに転送される時はＰＣＦとゲートウェイ間）、およびプロクシＣＳＣＦとＵＥまたは任意他の関連するアプリケーションシグナリング間のＳＩＰシグナリングメッセージ内に含める必要がある。認可トークンはゲートウェイ内で開始される一つ以上のゲートに対する一意的識別子を含み、確立された無線ベアラのＰＣＦが行った判断へのバインディングであり、判断はメッセージ内でＰＣＦからゲートウェイに転送される。
【０１２６】
ＩＰ ＱｏＳ許可制御は管理ポリシーおよび利用可能なリソースに基づいてＱｏＳリソースの割当てを管理する。管理ポリシーに基づいた許可制御はＧＧＳＮ、およびＰＣＦ内のＩＰベアラサービスマネージャ内のポリシー実施を伴うクライアント/サーバアーキテクチュアを使用して実施される。ＣＯＰＳプロトコルはこのインターフェイスに理想的である。
【０１２７】
ＣＯＰＳプロトコルはＥＰおよびＰＣＦ間のクライアント/サーバプロトコルとして使用される。ＣＯＰＳクライアント（ＥＰ）はＱｏＳシグナリング要求によりトリガーされたＰＣＦからポリシー情報を要求することができる。あるいは、ＰＣＦが行った判断を、例えば、ＳＩＰシグナリングによりトリガーされた、外部 out-of-band ＱｏＳサービス要求に基づいてＣＯＰＳクライアント（ＥＰ）にプッシュすることができる。これらのポリシー判断はＥＰによりアクセスされるローカルポリシー判断ポイントにおけるＣＯＰＳクライアント内に格納され、ＰＣＦとの追加インタラクションを要求することなく許可制御判断を行う。
【０１２８】
ＣＯＰＳプロトコルはクライアントおよびサーバ間のいくつかのメッセージをサポートする。これらのメッセージには実施できる下記の操作が含まれる。
【表４】
【０１２９】
プル（アウトソーシング）モデルはクライアント-駆動方法を表わし、ＰＣＦはＥＰからの着信ポリシー要求にアクティブに応答する。一つのＥＰ要求に二三のＰＣＦ判断が続くことがある。非同期通知によりＰＣＦは前の判断の変更、エラー発生、等が必要な時はいつでもＧＧＳＮ内のＥＰに通知することができる。
【０１３０】
プルモデルはＰＤＰコンテキスト活性化およびＰＤＰ修正において使用することができる。後続フェーズにおいて、プルモデルを使用することができる。
【０１３１】
ポリシー認可に対するＣＯＰＳプルモデルを考えると、ＥＰから送られるメッセージは要求、更新、報告およびメッセージ削除であり、ＰＣＦから送られるメッセージは判断および更新である。
【０１３２】
ＵＭＴＳ ＱｏＳアーキテクチュアをサポートするために追加情報要素をＣＯＰＳ内に含める必要がある。ＣＯＰＳフレームワークと一貫して、ＵＭＴＳクライアント（ＧＧＳＮ）に割り当てられる一意的“クライアントタイプ”によりポリシー制御インターフェイスが識別される。アーキテクチュア内に必要なオブジェクトは表５および６に記載され、以下に説明される。
【表５】
【０１３３】
認可トークンはコマンドまたは応答内で参照されている一つ以上のゲートに対する一意的識別子を含む。認可トークンはＧＧＳＮのポリシー制御を提供していることがある多数のポリシー制御機能をサポートする。
【０１３４】
ＰＣＦからＥＰに使用されるコマンドは下記のコマンドを含む。
【表６】
【０１３５】
ＥＰからＰＣＦに必要な応答は受信応答および/またはこれらの各コマンドに対するエラー応答を含む。
【０１３６】
ゲートスペックオブジェクトは応答内にセットされたり応答で戻されるゲートパラメータの仕様を含む。コマンドまたは応答は、表７に示すような、認可トークンに関連する一つ以上のゲートスペックオブジェクトを含むことができなければならない。
【表７】
【０１３７】
イベント発生infoはＩＰ ＱｏＳベアラに必要なことがある使用記録に関する情報を含む。これは、同じセッションに関連する全記録が対応できるように、ＧＧＳＮからのイベント記録をプロクシＣＳＣＦからのイベント記録と相関させるのに必要な“課金識別子”を含むことができる。課金識別子を一意的とするためにそれは、例えば、ＰＣＦのアイデンティティと共にＰＣＦにより発生される長い数値を含むことがある。
【０１３８】
エンドポイント識別子およびマックスゲートフィールドは過剰数の同時セッションのセットアップを試みるサービスアタックのＵＥ-開始否定を防止するのに使用され、多数のゲートの割当てを生じる。エンドポイント識別子は認可トークンに関連するエンドポイントのアイデンティティ（例えば、ＩＰアドレス）を含み、マックスゲートフィールドはこの特定エンドポイントに割り当てることができる最大数のゲートを含んでいる。割り当てられたゲート数がマックスゲートを越える場合には、ＧＧＳＮはエラーを戻すことができる。
【０１３９】
説明された発明は３ＧＰＰシステム内で有利に標準化することができる。
【０１４０】
前記した方法のステップは適切なプロセッサにより実行されるソフトウェアまたは、特定応用集積回路（“ＡＳＩＣ”）等の、ハードウェアにより容易にインプリメントすることができる。
【０１４１】
通信システムに関して説明してきたが、当業者ならば本発明はその本質的特徴から逸脱することなく他の特定形式で実施できることがお判りであろう。例えば、本発明は任意のマルチプロセッサで使用することができる。したがって、前記した実施例はあらゆる側面において説明用であって制約的意味合いは無い。
【０１４２】
いくつかの典型的な実施例に関して本発明のさまざまな側面について説明してきた。本発明の理解を容易にするために、本発明の多くの側面はコンピュータシステムの要素により実施することができる一連のアクションに関して説明された。例えば、各実施例において、さまざまなアクションは特殊化された回路（例えば、特殊化された機能を実施するように相互接続された個別論理ゲート）、一つ以上のプロセッサにより実行されるプログラム命令、または両者の組合せにより実施できることが認識される。
【０１４３】
さらに、ここに記載された技術をプロセッサに実施させる適切なコンピュータ命令セットを内部に格納している任意形状のコンピュータ読取り可能記憶媒体内で本発明の全体を実施することも考えられる。したがって、本発明のさまざまな側面は多くの異なる形式で実施することができ、このような形式は全て本発明の範囲に入るものとする。本発明のさまざまな側面の各々について、実施例の任意のこのような形式をここでは記述されたアクションを実施“するように論理的に構成されている”、もしくは記述されたアクションを実施する“論理”と言うことができる。
【０１４４】
“含む(comprisesおよびcomprising)”という用語は、特許請求の範囲だけでなく本明細書で使われる場合、述べられた特徴、ステップまたはコンポーネントの存在を指定するものととられるが、これらの用語の使用一つ以上の他の特徴、ステップ、コンポーネントまたはそれらのグループの存在を排除するものではないことを強調しなければならない。
【０１４５】
出願人の発明のさまざまな実施例について説明してきたが、当業者ならばこれらの実施例は単なる説明用であって任意他の実施例が可能であることがお判りであろう。意図する発明の範囲は明細書ではなく特許請求の範囲に記載されており、特許請求の範囲内に入るあらゆるバリエーションがそこに含まれるものとする。
【０１４６】
関連出願の相互参照
本出願は2000年5月22日に出願された米国仮出願第60/206,186号“All IPPolicy Architecture”および2000年11月6日に出願された第60/246,501号“Enable User Choice in a System Using Application Influenced Policy”に関連し、かつ優先権を請求するものであり、それらの開示は本開示の一部としてここに組み入れられている。
【図面の簡単な説明】
【図１】 ハイレベルＩＰ網のブロック図である。
【図２】 end-to-end統合サービスを利用する網の例を示すブロック図である。
【図３】 ＲＳＶＰプロクシを利用する網の例を示すブロック図である。
【図４】 end-to-end differentiated services を利用する網の例を示すブロック図である。
【図５】 differentiated services と相互作用するＲＳＶＰシグナリングを利用する網の例を示すブロック図である。
【図６】 DiffServとしてモデル化された移動アクセスデータ網を示すブロック図である。
【図７】 ＵＭＴＳ ＱｏＳアーキテクチュアのブロック図である。
【図８】 制御プレーン内のＵＭＴＳベアラサービスに対するＱｏＳ管理機能を示すブロック図である。
【図９】 ユーザプレーン内のＵＭＴＳベアラサービスに対するＱｏＳ管理機能を示すブロック図である。
【図１０】 ＵＭＴＳ ＱｏＳクラスのテーブルである。
【図１１】 ＱｏＳ属性のテーブルである。
【図１２】 図１１のＱｏＳ属性に対するある使用の概観を提供するテーブルである。
【図１３】 ＰＤＰアドレス、ＰＤＰコンテキスト、およびＴＦＴ間の関係のブロック図である。
【図１４】 ＴＦＴパケットフィルタ属性の有効な組合せのテーブルである。
【図１５】 ＰＤＰコンテキストメッセージ交換を示す図である。
【図１６】 制御プレーン内のＵＭＴＳベアラサービスに対するＱｏＳ管理機能およびend-to-end ＩＰ ＱｏＳに対するＱｏＳ管理機能のブロック図である。
【図１７】 ＩＰマルチメディアシステムのＧＰＲＳベアラへの相互関係を示す図である。
【図１８】 ＩＥＴＦポリシーフレームワークを示す図である。
【図１９】 制御プレーン内のＵＭＴＳベアラサービスに対するＱｏＳ管理機能および本発明に従ったポリシー制御機能を有するend-to-end ＩＰ ＱｏＳに対するＱｏＳ管理機能のブロック図である。
【図２０】 本発明の実施例に従った図１９の要素間のメッセージフロー図である。
(背景技術)
本出願は一般的にパケットデータ網に関し、特にポリシー機構を使用してパケットデータ網内のデータをフィルタリングおよびゲーティングする方法に関する。
【０００２】
元々、インターネットプロトコル（“ＩＰ”）網等のパケットデータ網は“ベストエフォート”トラフィックを運ぶように設計された。すなわち、網はユーザパケットが受け手に到達することを保証しなかった。ＩＰ網市場の成功により、ＩＰ網がさまざまなタイプのアプリケーションをサポートできるようにする機構が今日明らかに必要とされている。これらのアプリケーションのいくつかはサービス品質（“ＱｏＳ”）要求条件を有する。このようなアプリケーションの例としてさまざまなリアルタイムアプリケーション（ＩＰ電話、ビデオ会議）、ストリーミングサービス（オーディオまたはビデオ）、または高品質データサービス（有限ダウンロード遅延ブラウジング）が含まれる。これらの要求条件を認識して、ＩＰ網に対する主要な標準化組織であるＩＥＴＦ(Internet Engineering Task Force)は最近ＩＰ網オペレータがＱｏＳイネーブルドＩＰ網を形成することができる一組のプロトコルおよび機構を標準化した。
【０００３】
図１はＱｏＳプロビジョニングを説明するのに有用なＩＰ網の単純化されたハイレベルモデルを示す。このモデルは二人のユーザを含んでいるが、網の基本的機能を変えずにより多くのユーザを含むように容易に拡張できることがお判りであろう。
【０００４】
図１において、ユーザＡ１０１はユーザＢ１０２またはアプリケーションサーバ１０３と通信することができる。例えば、ＩＰ電話セッションの場合には、ユーザＡ１０１はユーザＢ１０２と通信することができる。同様に、ストリーミングサービスの場合には、ユーザＡ１０１はアプリケーションサーバ１０３と通信することができ、それはビデオサーバとして構成することができる。いずれの場合にも、ユーザＡ１０１は電話、移動通信用グローバルシステム（“ＧＳＭ”）、またはＵＭＴＳ（Universal Mobile Telecommunication System）網等のローカルアクセス網１０５を介してＩＰバックボーン網１０４にアクセスする。ユーザＢ１０２は同様にローカルアクセス網１０６を介してＩＰ網１０４に接続される。しかしながら、ユーザＡ１０１およびユーザＢ１０２は同じタイプのアクセス網を使用する必要はないことがお判りであろう。
【０００５】
一般的に知られているように、ＩＰ網１０４は一緒にＩＰ網の入口および出口ポイント間の接続性を提供して２パーティ通信を可能とするいくつかのＩＰルータおよび相互接続リンクを含むことができる。
【０００６】
ユーザに関する限り、知覚されるＱｏＳはアクセス網１０５，１０６およびＩＰバックボーン網１０４内の両方の機構によって決まる。特に興味深いのは、少なくとも一つのアクセス網がＵＭＴＳ網である特定のケースである。
【０００７】
ユーザがＩＰベースサービスにアクセスする時は、典型的にユーザが特定のサービスにアクセスするためのインターフェイスを提供するアプリケーションを実行する装置を使用する。例えば、図１では、ユーザＡはＩＰ網ベース会議に参加する会議アプリケーションプログラムを実行するラップトップコンピュータを使用することができ、会議の参加者はさまざまなプログラムを使用して協議する。このようなプログラムは従来技術でよく知られている。
【０００８】
さまざまなアプリケーションがアプリケーションプログラミングインターフェイス（“ＡＰＩ”）を介して網サービスにアクセスすることができる。ＡＰＩはアプリケーションプログラマが基本的なシステムリソースにアクセスするための均一なインターフェイスを提供する。例えば、ＡＰＩは所与のアプリケーションから発信される特定のＩＰパケットが、特定のＱｏＳ等の、ある処置を網から受けることを要求するように網リソースマネージャを構成するのに使用することができる。例えば、ＩＰ網がDifferentiated Services ＩＰ網であれば、アプリケーションプログラムはその全てのＩＰパケットが“Expedited Forwarding”処置を受けるよう要求することができる。
【０００９】
ユーザ（およびユーザの装置内のＡＰＩ）はさまざまなアクセス網およびＩＰバックボーン網がend-to-end ＱｏＳを提供するために利用する異なる技術を知らないことがある。例えば、ユーザはＲＳＶＰ/IntServベースＡＰＩを使用することができ、ユーザが関与するend-to-end実施例はＵＭＴＳアクセス網および非ＲＳＶＰイネーブルドＩＰ網を含むことがある。このような場合、さまざまな技術間のある相互作用機構はＱｏＳがend-to-endで提供されることを確かめることが必要となることがある。
【００１０】
統合サービス（“IntServ”）は多数の中からそのデータパケットに対する配信サービスの制御されたレベルを選択するアプリケーション能力を提供する。この能力をサポートするために、二つのことが必要である。第１に、アプリケーションのデータパケットが続くパスに沿った、サブネットおよびＩＰルータ等の、個別の網要素がこれらのパケットに配信されるＱｏＳを制御する機構をサポートしなければならない。第２に、アプリケーションの要求条件をパスに沿って網要素に伝えＱｏＳ管理情報を網要素およびアプリケーション間で運ぶ方法を提供しなければならない。
【００１１】
IntServは制御された負荷（IETF RFC2211で規定される）および保証（IETF RFC2212で規定される）等のいくつかのサービスを規定する。サービス規定はサービスを配信するために網装置の必要な特性を規定する。例えば、保証サービスはend-to-endデータグラム待ち行列遅延の固定した、数学的に証明可能な範囲を与え遅延および帯域幅の両方を保証するサービスを提供できるようにする。制御された負荷サービスは同じフローが無負荷網要素から受信するが、容量制御（許可）制御を使用して網要素が過負荷である時でもこのサービスが受信されることを保証するＱｏＳを精密に近似するＱｏＳをクライアントデータフローに提供する。サービスをサポートする個別の網要素（サブネットおよびＩＰルータ）はそのサービスに対して規定された規定に従わなければならない。
【００１２】
サービス規定はサービスを確立するために網の両端間で提供しなければならない情報も規定する。この機能はいくつかの方法で提供することができるが、ＲＳＶＰ（IETF RFC2205で規定される）等のリソース保存セットアッププロトコルにより頻繁にインプリメントされる。
【００１３】
ＲＳＶＰ(Resource reSerVation Protocol)はIntServ Internet（IETF RFC1633, 2205、および2210で規定される）に対して設計されたリソース保存セットアッププロトコルである。ＲＳＶＰプロトコルはホストが特定のアプリケーションデータストリームすなわちフローに対して網から特定のサービス品質を要求するのに使用される。ＲＳＶＰはルータがフローのパスに沿った全てのノードにＱｏＳ要求を配信し要求されたサービスを提供する状態を確立して維持するのにも使用される。ＲＳＶＰ要求の結果、一般的に、リソースはデータパスに沿った各ノード内に保存される。
【００１４】
図２はホスト間のend-to-end統合サービスを示す。サービスは要求されたサービスに対して規定されたサービス規定をサポートするルータおよびホストを使用してノード間での関連情報のシグナリングを介して提供される。
【００１５】
ＲＳＶＰは主としてend-to-endに設計されるプロトコルであるため、送り手がend-to-endパスのある部分だけでリソース保存するためにＲＳＶＰを使用したい状況では、ある特別な機能が必要となる。これはＲＳＶＰがアクセス網内で使用されバックボーン網内でオーバプロビジョニングが使用される場合に生じることがある。このような状況では、ＲＳＶＰ Ｐｒｏｘｙの概念が有用である。
【００１６】
ＲＳＶＰ Ｐｒｏｘｙはルータまたはスイッチ等の網装置により提供される機能であり、網装置はＰＡＴＨメッセージにより識別される一人以上の受け手のために着信ＰＡＴＨメッセージに応答してＲＥＳＶメッセージを発信する。すなわち、ＲＳＶＰ Ｐｒｏｘｙは遠隔ホストのために作用して発信ホストとＲＳＶＰ Ｐｒｏｘｙ間のリソース保存を容易にする。これは図３に示されている。ＲＳＶＰ ＰｒｏｘｙはＲＳＶＰ Ｐｒｏｘｙと非ＲＳＣＰホスト間の網状況の知識を使用することができる。
【００１７】
インターネットプロトコルへのDifferentiated Services（“DiffServ”）エンハンスメントはパーフロー状態およびホップ毎のシグナリングを必要とせずインターネット内でスケーラブルサービス識別をできるようにするものである。網ノード内に展開されるビルディングブロックの小さなよく規定されたセットから多様なサービスを組み立てることができる。サービスはend-to-endまたはintra-domainとすることができ、サービスは量的性能要求条件（例えば、ピーク帯域幅）を満たすことができるものおよび相対性能に基づくもの（例えば、“クラス”区別）を含んでいる。サービスは網境界（自律システム境界、内部管理境界、またはホスト）におけるＩＰヘッダーフィールド内の設定ビットの組合せにより構成することができ、これらのビットを使用して網内のノードによりパケットがどのように転送されるかを決定し、各サービスの要求条件またはルールに従って網境界においてマークされたパケットを調節する。
【００１８】
Differentiated Servicesは網境界におけるエッジルータ、および網内のコアルータを規定する。エッジおよびコアルータは異なる責務を有する。エッジルータはトラフィックがサービス協定に従うことを保証するようにトラフィックを調節しなければならない。エッジルータは、また、パケットトラフィックに適切なDifferentiated Services Code Point（“ＤＳＣＰ”）をマークし、次にＤＳＣＰに対して規定されたサービス挙動に従ってパケットを転送する。Per Hop Behavior（“ＰＨＢ”）と呼ばれるサービス挙動はそのトラフィックに異なるタイプの他のトラフィックよりも良好なトラフィックを与えるためのそのタイプのトラフィックの優先化すなわち重み付けを規定することができる。コアノードはＤＳＣＰを調べてそのサービスに対して適切なサービス挙動を適用する。
【００１９】
図４はend-to-endサービスを示す。ＤＳエッジルータがトラフィック調整を行い、ＤＳコアルータはＰＨＢを適用するだけである。
【００２０】
IntServアーキテクチュアが同質網を介したアプリケーションへのend-to-end QoSの配信手段を提供する。このend-to-endモデルをサポートするために、IntServアーキテクチュアは多様な異なるタイプの網要素を介してサポートされなければならない。この状況において、Differentiated Serviceをサポートする網は全体end-to-endパス内の網要素と見なすことができる。
【００２１】
IntServの観点から、網のDiffServ領域はIntServケーパブルルータすなわちホストを接続する仮想リンクとして扱われる（イーサネット（Ｒ）ＬＡＮが仮想リンクとして扱われるように）。網のDiffServ領域内で、ルータは特定のＰＨＢ（集合トラフィック制御）をインプリメントする。あるＰＨＢを受信するDiffServ領域内に許可されるトラフィックの総量はエッジルータにおける調整により制御される。エッジルータにおいて許可制御およびトラフィック調整を適用し、かつDiffServドメイン両端間でＲＳＶＰを使用してシグナリングすることによりDiffServドメイン両端間でIntServサービスを提供することができる。ＲＳＶＰシグナリングにおいて提供される情報はDiffServドメイン両端間のサービスに対して適切でなければならない。これは図５に示されている。
【００２２】
明確に規定された特性および機能を有するＱｏＳベアラサービスを実現するために、ベアラはサービスの送り手から受け手にセットアップしなければならない。ベアラサービスは契約したＱｏＳの提供を可能とするあらゆる側面を含んでいる。これらの側面は、とりわけ、制御シグナリング、ユーザプレーントランスポート、およびＱｏＳ管理機能である。
【００２３】
General Packet Radio Service（“ＧＲＰＳ”）およびＵＭＴＳを含む移動アクセスデータ網は全体網の一部を形成することができそれに接続された顧客に対するend-to-endベアラサービスにおいて重要な役割を果たす。したがって、ＧＰＲＳ/ＵＭＴＳを介して提供されるサービスは制御シグナリングおよびユーザプレーントランスポートの前記した側面において所要のend-to-endベアラサービスを提供するのに適切でなければならない。
【００２４】
ＧＰＲＳ/ＵＭＴＳ網は、例えば、移動局（“ＭＳ”）等のホストとユーザを接続する外部パケット交換網との間に一組の網要素を含んでいる。ホストはコンピュータ、personal data assistant（“ＰＤＳ”）等のいくつかの網通信装置の一つとすることもできる。ＭＳホストが実例として図６に示されている。
【００２５】
Gateway GPRS Support Node（“ＧＧＳＮ”）が外部パケット交換網との相互作用を提供する。
【００２６】
パケット交換（“ＰＳ”）データを送受信するために、ＭＳはそれが使用したいパケットデータプロトコルコンテキストを活性化しなければならない。この操作により対応するＧＧＳＮ内で知られ外部データ網と相互作用するＭＳを開始できるようにする。
【００２７】
ユーザデータはカプセル化およびトンネリングとして知られる方法によりＭＳと外部データ網との間でトランスペアレントに転送され、データパケットは特定ＰＳプロトコル情報を備えてＭＳおよびＧＧＳＮ間で転送される。
【００２８】
ＱｏＳは第３世代（“３Ｇ”）移動網においても極端に重要な中心的役割を果たす。ＱｏＳはエンドユーザに満足するサービスを提供する手段であり、知識に関して網管理にとっても重要である。ＱｏＳは網内のトラフィックの知識を示唆し、したがって、スペクトルリソースの効率的使用も可能とする。
【００２９】
本発明はＵＭＴＳ ＱｏＳアーキテクチュアに関して説明される。したがって、均一なレベルの理解を提供するために、ＵＭＴＳにおけるＱｏＳの技術水準の概要が与えられる。Third Generation Partnership Project（“３ＧＰＰ”） ＵＭＴＳ ＱｏＳアーキテクチュアが説明され、パケットデータプロトコル（“ＰＤＰ”）コンテキスト、トラフィックフローテンプレート（“ＴＦＴ”）、および活性化されたＵＭＴＳベアラに対するＱｏＳ保守手順の説明が含まれる。
【００３０】
無線に関連する帯域幅はend-to-endチェイン内で最も高価かつ貴重であると考えられる。ＵＭＴＳアクセス網内で、無線網リソースはＰＤＰコンテキスト粒度当たりで管理され、それはユーザフローおよびあるＱｏＳレベルに対応する。
【００３１】
Ｒ９９ ３Ｇ網に対するＱｏＳフレームワークはTS23.107 V.3.4.0.内に指定されている。主要な焦点はＵＭＴＳレベル内で使用されるＱｏＳアーキテクチュアであり、ＵＭＴＳベアラサービスおよび無線アクセスベアラサービスに適用できるＱｏＳ属性のリストが適切なマッピングルールと共に指定される。
【００３２】
TS23.060 V.3.4.0はＵＭＴＳレベル内でＰＳ接続性サービスのためにＲ９９ ３Ｇ網により使用される一般的機構を指定する。これは３Ｇ網のパケットドメインに対するサービス記述を規定し、それにはＧＳＭおよびＵＭＴＳ内のＧＰＲＳが含まれる。
【００３３】
ＵＭＴＳ ＱｏＳアーキテクチュアにおいて、網サービスは端末装置（“ＴＥ”）からもう一つのＴＥへのend-to-endと考えられる。end-to-endサービスはあるＱｏＳを有することができ、それは網サービスのユーザに与えられる。
【００３４】
ある網ＱｏＳを実現するために、明確に規定された特性および機能を有するベアラサービスがサービスの送り手から受け手にセットアップされる。ベアラサービスは契約したＱｏＳの提供を可能にするあらゆる側面、例えば、制御シグナリング、ユーザプレーントランスポート、ＱｏＳ管理機能等を含んでいる。
【００３５】
ＵＭＴＳベアラサービスレイヤードアーキテクチュアが図７に示されている。特定レイヤ上の各ベアラサービスが下のレイヤにより提供されるサービスを使用してその個別のサービスを提供する。ベアラは下層ベアラに分解され、各々が他のベアラとは独立した実現によりＱｏＳを提供する。網構成要素間でサービス協定がなされ、図７においてそれらは縦に配置されている。サービス協定はサービスの一つ以上のレイヤにより実行することができる。
【００３６】
例えば、ＵＭＴＳベアラサービスは無線アクセスベアラ（“ＲＡＢ”）サービスおよびコア網(“ＣＮ”)ベアラサービスを含んでいる。ＲＡＢサービスは無線ベアラサービスとｌｕベアラサービスに分割される。ｌｕインターフェイスは無線アクセス網とコア網間のインターフェイスである。
【００３７】
以下は図７に示すエンティティの例である。端末装置(“ＴＥ”)はラップトップコンピュータとすることができ、移動端末(“ＭＴ”)はハンドセット、例えば、移動局とすることができる。ＵＭＴＳ地上無線アクセス網(“ＵＴＲＡＮ”)はノードＢと無線網コントローラ(“ＲＮＣ”)の組合せにより構成することができる。ＣＮ ｌｕエッジノードはServing GPRS Support Node（“ＳＧＳＮ”）とすることができ、ＣＮゲートウェイ(“ＧＷ”)はＧＧＳＮとすることができる。
【００３８】
ＵＭＴＳ内のＱｏＳ管理機能は、特定のＱｏＳ属性により規定される、特定のＱｏＳによりＵＭＴＳベアラサービスを確立、修正および維持するのに使用される。組み合わされた全ＵＭＴＳエンティティのＱｏＳ管理機能が交渉したＵＭＴＳベアラサービスの提供を保証する。
【００３９】
ＵＭＴＳアーキテクチュアはコントロールパネル内の四つの管理機能およびユーザプレーンの四つの管理機能を含んでいる。コントロールパネル管理機能は、下記のものである。
対応するベアラサービスをセットアップ、制御、および終結するベアラサービス（“ＢＳ”）マネージャ。各ＢＳマネージャはサービス要求中にそのレベルの属性を基本的ベアラサービスの属性に変換もする。
外部サービスシグナリングおよびサービス属性の変換を含む内部サービスプリミティブ間の変換を行い、ＭＴおよびＧＷ内に配置される変換機能。
網エンティティが要求された特定のサービスをサポートするかどうか、また要求されたリソースが利用可能かどうかを決定する許可/ケーパビリティ制御。
ユーザが要求されているベアラに加入しているかどうかを決定する加入制御である。
【００４０】
ユーザプレーン管理機能は、
データユニットの転送を実施するベアラサービスに関連する特定のＱｏＳ表示により各データユニットをマークするマッピング機能。例えば、マッピング機能はDiffServコードポイントをパケットに付加した後でパケットをｌｕすなわちＣＮベアラに与えることができる。
ＧＧＳＮおよびＭＴ内に常駐し、外部ベアラサービス（または、ローカルベアラサービス）から受信したユーザデータユニットを、各ユーザデータユニットのＱｏＳ要求条件に従って適切なＵＭＴＳベアラサービスに割り当てる分類機能。後述するように、これはトラフィックフローテンプレート（“ＴＦＴ”）およびパケットフィルタが配置される所である。
そのリソースをそれらを要求している全ベアラサービス間に分散させるリソースマネージャ。リソースマネージャは個別の各ベアラサービスに対して要求されるＱｏＳ属性を提供しようと試みる。リソースマネージャの例はパケットスケジューラである。
ユーザデータトラフィックと関連するＵＭＴＳベアラサービスのＱｏＳ属性との適合を提供する整形およびポリシング機能であるトラフィック調整器。トラフィック調整器はＵＴＲＡＮ内だけでなくＧＧＳＮおよびＭＴ内に常駐する。
【００４１】
ＵＭＴＳベアラサービスを制御するＱｏＳ管理機能が図８に示されている。これらの制御機能の目的はＴＥ内のローカルサービスコントロールおよび外部網内の外部サービスコントロールとの相互作用を介してＵＭＴＳベアラサービスの確立および修正をサポートすることである。
【００４２】
ユーザプレーン内のＵＭＴＳベアラサービスのＱｏＳ管理機能が図９に示されている。これらの機能は、ベアラサービス属性により表わされる、ＵＭＴＳベアラサービス制御機能により確立されるコミットメントに従って一緒にデータ転送特性を維持する。ユーザプレーンはＱｏＳ属性を使用する。関連する属性がＱｏＳ管理制御機能によりユーザプレーン管理制御に与えられる。
【００４３】
四つの異なるＱｏＳクラスがＵＭＴＳ内で標準化され図１０に示されている。アプリケーションデータの対応するタイプまたはあるクラスのベアラサービスに対してデータトランスポートを最適化することができる。これらのクラス間の主要な識別要因はトラフィックがどれだけ遅延に敏感であるかということであり、従来のクラスは非常に遅延に敏感なトラフィックに対するものであり（リアルタイムサービスに対する）、背景クラスは最も遅延に鈍感なトラフィッククラスである（非リアルタイムサービスに対する）。
【００４４】
ベアラサービスを詳細に特徴づけるために、下記の表に示すように一組のベアラサービス属性がＵＭＴＳ内で標準化される。ベアラ要求条件を記述する一組の属性値を選択することによりあるＱｏＳが要求される。パラメータは要求されたベアラサービスのタイプに応じて異なる。
【００４５】
図１１はどの属性がどのトラフィッククラスに適用できるかを示す。図１２は異なるＱｏＳ属性が何のために使用されるかの概観を提供する。ＱｏＳ属性の正確な規定は、現在はバージョン3.4.0.である、TS23.107で見つけることができる。
【００４６】
加入は一つ以上のＰＤＰアドレス、すなわちＩＰトラフィックの場合のＩＰアドレス、と関連づけられる。各ＰＤＰアドレスはＭＳ，ＳＧＳＮ，およびＧＧＳＮ内に格納された一つ以上のＰＤＰコンテキストにより記述される。加入情報を保持するＨＬＲ内でデフォルト値も手に入る。各ＰＤＰコンテキストはトラフィックフローテンプレート（“ＴＦＴ”）と関連づけることができる。任意の時間にせいぜい一つのＰＤＰコンテキスト（同じＰＤＰアドレスが関連づけられる）しか存在することができず、それにはＴＦＴは割り当てられない。ＰＤＰアドレス、ＰＤＰコンテキスト、およびＴＦＴ間の関係は図１３に与えられている。
【００４７】
ＰＤＰコンテキストはＭＳおよびＧＧＳＮ間でＰＤＰ ＰＤＵを転送するために必要な全情報、例えば、アドレッシング情報、フロー制御変数、ＱｏＳプロファイル、課金情報等、を含むデータエントリのダイナミックテーブルである。ＵＭＴＳベアラサービスとＰＤＰコンテキスト間の関係は一対一マッピングである、すなわち一つのＰＤＰアドレスに対して二つのＵＭＴＳベアラサービスが確立される場合には、二つのＰＤＰコンテキストが規定される。
【００４８】
ＰＤＰコンテキスト手順は、現在はバージョン3.4.0である、TS23.060内で標準化されている。ＱｏＳプロファイルおよびトラフィックフローテンプレート（“ＴＦＴ”）を取り巻く概念はＱｏＳの観点から適切である。
【００４９】
ＵＭＴＳ ＱｏＳ属性は主として効率的な無線実現をサポートするために選択され規定されている。ＱｏＳプロファイルは一組のＵＭＴＳ ＱｏＳ属性により規定される。ＲＮＣはＰＤＰコンテキスト活性化中に関連するＲＡＢ ＱｏＳプロファイルをＳＧＳＮから得る。ＰＤＰコンテキスト活性化内に含まれる三つの異なるＱｏＳプロファイルがある−要求されたＱｏＳプロファイル、交渉したＱｏＳプロファイル、および加入したＱｏＳプロファイル（すなわちデフォールトＱｏＳプロファイル）。
【００５０】
表１に示すように、必要な情報のタイプに応じて、格納されたＰＤＰコンテキスト情報はＭＳ，ＲＮＳ，ＳＧＳＮ，ＧＧＳＮ，およびＨＬＲが異なる。
【表１】
ＴＦＴはパケットを正しいＰＤＰコンテキストに関連づけて、適切なＧＰＲＳトンネリングプロトコル（“ＧＴＰ”）トンネル内に転送されることを保証するパケットフィルタ（または、フィルタセット）である。ＴＦＴは、単一ＰＤＰアドレスに関連づけられた、変動するＱｏＳプロファイルを有するいくつかのＰＤＰコンテキストを有する可能性を可能とする。ＴＦＴはアップリンクおよびダウンリンクフローの両方に対してＭＴにより管理され開始される。アップリンクＴＦＴはＭＴ内に常駐し、ダウンリンクＴＦＴはＧＧＳＮ内に常駐する。ダウンリンクＴＦＴはＰＤＰコンテキスト活性化/修正中にＭＴからＧＧＳＮに送られる。ダウンリンクＴＦＴは１なしで作り出されたＰＤＰコンテキストに加えることができ、コンテンツは修正することもできる。
【００５２】
図１４はＴＦＴパケットフィルタ属性および有効な組合せを示す。各ＴＦＴは識別子および同じＰＤＰアドレスを共有するＰＤＰコンテキストに関連づけられた全てのＴＦＴ内で一意的な評価優先インデクスを有する。ＭＳはパケットフィルタコンテンツだけでなくＴＦＴの識別子および評価優先インデクスを管理する。
【００５３】
図１４におけるいくつかの属性はパケットフィルタ内に共存することができ他は互いに排除する。単一パケットフィルタに対しては“Ｘ”をマークした属性しか指定することができない。マークされた全属性を指定することができ、少なくとも一つを指定しなければならない。
【００５４】
ＰＤＰコンテキストシグナリングは要求され交渉したＱｏＳプロファイルをＵＭＴＳ網内のノード間で運ぶための手段である。ＰＤＰコンテキストシグナリングはＱｏＳレベル上のベアラの許可制御、交渉、および修正に関してＱｏＳ処理に対する中心的役割を有する。図１５の数字を参照して以下にＰＤＰコンテキストシグナリングメッセージ交換について説明する。
【００５５】
ステップ１において、ＲＲＣ接続が確立される。この手順はＭＳおよびＵＴＲＡＮ間の接続を確立するのに必要である。しかしながら、ＱｏＳ観点から、確立フェーズは典型的に使用されている無線チャネルのタイプを表示する以外はほとんどなにも行わない。
【００５６】
ステップ２において、ＭＳはＳＧＳＮにＰＤＰメッセージを送ってＰＤＰコンテキストを活性化させる。要求されたＱｏＳプロファイルはこのメッセージ内に含まれる。この段階において、ＳＧＳＮは許可チェックを行いシステムが過負荷であれば要求されたＱｏＳを制限することができる。
【００５７】
ステップ３において、ＳＧＳＮはＲＡＮＡＰメッセージ“ＲＡＢ割当て要求”をＲＮＣに送る。ＲＡＮＡＰ、すなわち無線アクセス網アプリケーション部、は無線アクセス網（“ＲＡＮ”）および外部ＣＮ間のシグナリングおよび制御伝送をサポートするアプリケーションプロトコルである。ＲＡＮＡＰはＲＡＮおよび回線交換またはパケット交換網間の通信を許す。無線アクセスベアラサービスを確立するこの要求はＲＡＢ ＱｏＳ属性を運び、それはＳＧＳＮにより修正されていることがある。
【００５８】
ステップ４において、ＲＮＣはＲＡＢ ＱｏＳ属性を使用してＱｏＳプロファイルに対応する無線関連パラメータを決定する。これらのパラメータはトランスポートフォーマットセットおよびトランスポートフォーマット組合せセットを含むことができる。さらに、ＵＴＲＡＮがこのベアラの許可制御を実施する。
【００５９】
ステップ５において、ＲＮＣはＲＲＣメッセージ、“無線ベアラセットアップ”をＭＳに送る。ＲＲＣメッセージはステップ４において決定された無線関連パラメータを含んでいる。
【００６０】
ステップ６において、ＵＴＲＡＮおよびＭＳは無線パラメータを適用しトラフィック転送準備が完了する。これをシグナルするために、ＭＳは“無線ベアラセットアップ完了”ＲＲＣメッセージをＲＮＣに送る。
【００６１】
ステップ７において、ＵＴＲＡＮは“ＲＡＢ割当て完了”ＲＡＮＡＰメッセージをＳＧＳＮに送る。
【００６２】
ステップ８において、トレース手順を開始することができる。これは加入者を監査する動作および保守機能である。
【００６３】
ステップ９において、ＳＧＳＮは“ＰＤＰコンテキスト要求生成”をＧＧＳＮに送り、ＱｏＳプロファイルを運ぶ。しかしながら、ＱｏＳプロファイルはステップ２においてＭＳにより要求されるものとは異なるパラメータを有することがある。このプロファイルに基づいて、ＧＧＳＮレベルで許可制御が実行され、例えば、システムが過負荷であればＧＧＳＮはＱｏＳを制限することができる。ＧＧＳＮはＰＤＰコンテキストをそのデータベース内に格納する。
【００６４】
ステップ１０において、ＧＧＳＮは交渉したＱｏＳを“ＰＤＰコンテキスト応答生成”メッセージ内のＳＧＳＮに戻し、ＳＧＳＮはＰＤＰコンテキストをそのデータベース内に格納する。
【００６５】
ステップ１１において、交渉したＱｏＳはＳＧＳＮから“アクティブＰＤＰコンテキスト受理”メッセージ内のＭＳに送られる。ＳＧＳＮまたはＧＧＳＮがＱｏＳプロファイルを修正しておれば、ＭＳはこのプロファイルを受理または拒否しなければならない。
【００６６】
手順内で行われるいくつかのローカル許可制御がある。しかしながら、無線に関連する帯域幅は最も高価なリソースであるため、ＵＴＲＡＮに相談してＰＤＰコンテキスト活性化または修正中に無線リソースを利用できるかどうかを決定する。したがって、ＵＭＴＳ内での許可制御は無線中心で実施される。
【００６７】
ＩＰ ＱｏＳ end-to-endを提供するために、各ドメイン内のＱｏＳを管理することが必要である。ゲートウェイ内のＩＰ ＢＳマネージャが外部ＩＰベアラサービスを制御するのに使用される。ＩＰ網内で使用される異なる技術により、これは変換機能を介してＵＭＴＳ ＢＳに伝えられる。
【００６８】
同様に、ＵＥ内に提供されるＩＰベアラサービスマネージャ機能も必要とされており、ベアラサービスマネージャはアプリケーションのＱｏＳ要求条件を適切なＱｏＳ機構にマッピングする。
【００６９】
図１６はＵＥおよびゲートウェイノード内の両方の可能な場所においてＩＰ ＢＳマネージャを使用するＩＰサービス制御の実施例を示す。図１６はＵＥおよびゲートウェイノード内のＩＰ ＢＳマネージャ間のオプショナル通信パスも示している。
【００７０】
ＩＰ ＢＳマネージャは標準ＩＰ機構を使用してＩＰベアラサービスを管理する。これらの機構はＵＭＴＳ内で使用されるものとは異なることがあり、サービスを制御する異なるパラメータを有することがある。変換/マッピング機能はＵＭＴＳベアラサービス内で使用される機構およびパラメータとＩＰベアラサービス内で使用されるものとの間の相互作用を提供し、かつＩＰ ＢＳマネージャと相互作用する。
【００７１】
ＩＰ ＢＳマネージャがＵＥおよびゲートウェイノード内の両方に存在する場合には、これらのＩＰ ＢＳマネージャは関連するシグナリングプロトコルを使用して互いに直接通信することができる。
【００７２】
ＩＰマルチメディアサービス（“ＩＭＳ”）がＧＰＲＳベアラサービスの頂部に規定される。ＩＰマルチメディアサービスはユーザへのマルチメディアセッションを提供する。ＩＰマルチメディアをサポートするベアラのＱｏＳ側面はTS23.207に規定されＩＰマルチメディア（“ＩＭ”）仕様はTS23.228に規定されている。
【００７３】
ＩＭＳは、例えば、セッション開始プロトコル（“ＳＩＰ/ＳＤＰ”）等のＩＰアプリケーションシグナリングに基づいている。エンドユーザはシグナリングＧＰＲＳベアラ上のセッションを要求し、それはセッションセットアップの前に確立されなければならない。図１７はＩＰマルチメディアシステムのＧＰＲＳベアラとの相互関係を示す。ＧＰＲＳベアラは端末ＡまたはＢ１７００，１７５０とＵＭＴＳ網１７１０，１７６０およびバックボーン１７４０間の各ゲートウェイ１７２０，１７７０との間に確立される。ゲートウェイはいくつかのＧＰＲＳユーザからのトラフィックの集約ポイントとしての働きもする。
【００７４】
一つのＧＰＲＳベアラは遠隔端末１７００，１７５０と交換されてＩＭセッションをセットアップするアプリケーションレベルシグナリング１７８０（ＳＩＰ/ＳＤＰ等）を運ぶ。アプリケーションは網内の一つまたはいくつかのプロクシによりサポートされる。実際のメディアストリームを運ぶために、一つのＧＰＲＳベアラが各メディアストリームに対して集約ポリシー１７２０，１７７０まで確立される。専用ＧＰＲＳベアラおよびバックボーンを介した共有集約トランスポートによりリソースがend-to-endで利用できる場合には、マルチメディアセッションが接続されて開始することができる。このようにして、いくつかのパラレルＧＰＲＳベアラがマルチメディアセッションをサポートするように確立される。
【００７５】
一般的に、ＱｏＳプロトコルは必要な網リソースを保存しトラフィックを区別する機構を提供し、ポリシールールはそれらがどのように使用されるかを規定する。例えば、ＩＥＴＦ ＱｏＳ機構ＲＳＶＰおよびIntServは、それぞれ、リソース保存セットアッププロトコルおよび一組のサービス規定を規定する。しかしながら、IntServの許可制御機構は許可制御の重要な側面を含んでいない。特に、網マネージャおよびサービスプロバイダは、ユーザおよびアプリケーションのアイデンティティ/オーソリティレベル（例えば、マネージャ、エンジニア、見習い、等）、トラフィック帯域幅要求条件（例えば、狭帯域、広帯域、等）、セキュリティ配慮（例えば、ミッションクリティカルリソースへのアクセス）、および一日の時間/週、等の規準から引き出されるポリシーに基づいて網リソースおよびサービスの使用を監視、制御および実施できなければならない。
【００７６】
トラフィックオーナー、エンドユーザ、アプリケーション、イーサネット（Ｒ）ホスト、等に要求するサービスが与えられる変動する状況があるため、ルール、これらのルールの実施方法およびそれらをいつ適用するかの“判断”が必要である。したがって、ポリシーシステムの三つの主要な構成要素はポリシールールおよびそれらの記憶装置（典型的にはポリシーデータベース内の）、ポリシー実施ポイント（“ＥＰ”）を使用する実施方法、およびポリシー判断ポイント（“ＤＰ”）である。さらに、ＩＥＴＦはCommon Open Policy Service (“COPS”)条項でＥＰおよびＤＰ間の情報交換プロトコルを標準化している。
【００７７】
ポリシーは特定の状況が存在する時に一つ以上のアクションを生じるルールの集まりと見なすことができる。ＩＥＴＦポリシーフレームワークが図１８に例示されている。ＥＰとＤＰおよびＤＰとポリシーレポジトリ間の分離は機能性およびオープンインターフェイスに基づいた論理的なものであり、必ずしも物理的な分離ではない。また、網ドメイン内には典型的に多数のＥＰがあり、各ＥＰ上に多数のインターフェイスがあることもある。例えば、管理ドメインの全てのまたはいくつかのルータはＩＰ網内にＥＰ機能をインプリメントすることができ、中央サーバはそのドメイン内にＤＰ機能をインプリメントすることができる。次に、ＤＰはポリシー（ルール）レポジトリに接続しポリシー判断を行うためにそこからデータをフェッチすることができる。例えば、Lightweight Directory Access Protocol（“ＬＤＡＰ”）をＤＰとポリシーレポジトリ間のプロトコルとして使用することができる。ＤＰは他のプロトコル、例えば、Simple Network Management Protocol（“ＳＮＭＰ”）を使用して網管理エンティティ等の他の網構成要素にポリシー情報を伝達かつエクスポートすることができる。
【００７８】
３Ｇ網内で、ＧＧＳＮは３Ｇリソースを容易に制御することができるゲートウェイノードとして作用するため、適切なＥＰとすることができる。ＤＰ（しばしば、ポリシーサーバ（“ＰＳ”）と呼ばれる）はＧＧＳＮの内部または外部に常駐することができる。しかしながら、典型的にＤＰはＧＧＳＮから分割されＰＳとＧＧＳＮとの間にオープンインターフェイスがある。
【００７９】
ポリシーシステムの異なる機能が別々の論理エンティティ内に配置されるため、ポリシー（データベース）、ポリシークライアント（エンホーサ）、およびポリシーサーバ（デシジョンメーカ）間の媒介として機能するポリシートランザクションプロトコルが必要である。ポリシートランザクションプロトコルはこれら二つのノード間でポリシー要求およびポリシー応答を転送する責任がある。このようなポリシートランザクションプロトコルに対するデファクト標準はＩＥＴＦ標準化プロトコルＣＯＰＳである。
【００８０】
ＣＯＰＳはポリシーサーバとそのクライアント間でポリシー情報を交換する単純な質問-および-応答プロトコルである。ポリシーサーバが判断を行うと、ポリシークライアントはその特定のポリシー判断の実施に対する責任がある。また、ＣＯＰＳはその判断の有効性を決定するためにポリシークライアントおよびポリシーサーバ間でポリシー制御判断を伝達できるようにするユニークな特徴を有する。現在、ＣＯＰＳは主としてＲＳＶＰ許可制御プロトコルとして使用されているが、ＩＥＴＦはＣＯＰＳを一般化されたポリシー通信プロトコルとして拡張するアイデアを現在検討している。
【００８１】
ＧＰＲＳ ＩＰ接続性およびＩＰマルチメディアサービスの両方を提供するオペレータにとって、ＩＭＳユーザおよびＧＰＲＳ ＩＰ接続性ユーザを課金、優先化、その他の目的について異なる取り扱いをする能力を有する必要がある。例えば、高ＱｏＳベアラのＧＰＲＳベアラはＩＭＳメディアをトランスポートするのにしか使用許可されないようにしなければならない。この要求条件は接続するサブネットワークやサービス網、あるいは操作するアプリケーションに応じて、異なるタイプのベアラを制御するように論理的に拡張することができる。この要求条件はアプリケーションから制御されるＧＰＲＳベアラタイプの制限を許すように論理的に拡張することもできる。
【００８２】
オペレータが適用したい制限は、例えば、網に入ることが許されるデータに対する受け手の厳格な制御であり、それはサービスが受け手に依存して課金されることがありかつ/または接続のためのリソース保存を実施することがあるためである。
【００８３】
課金がＩＭセッション開始からＩＭセッション終りまでの時間に基づく場合には、ユーザは課金されずにこれらのベアラリソースを使用することができない、すなわち、いかなる期間でも課金されずにアクセス網リソースを利用することをユーザに許可すべきではないことが絶対必要である。
【００８４】
従来のＧＰＲＳおよびＩＭＳ機構は現在セッション状態に無関係にベアラサービスが確立されることを許す。ユーザは呼課金を開始する前にアクセス網（例えば、ＵＭＴＳ）リソースを使用することを許されるが、アクティブフェーズの前の非認可データフローに対してはアクセスベアラ用課金レートが適用される。すなわち、アクセスベアラに適用される料金は現在のセッション状態に応じて異なる。セッションが既に存在する場合には、アクセスベアラ料金は無いことがあるが、それが存在しない場合には、たとえベアラ上で送られた任意のデータがその後廃棄されてもアクセスベアラ料金があることがある。この方法を使用することの欠点は非常に複雑な課金モデルが必要とされることである。
【００８５】
さらに、認可されず適切に課金されないリソースは保存すべきではない。しかしながら、音声クリッピングを回避するために、ベアラはイベントを介してセッションを開始する前に利用でき確立できなければならない。したがって、衝突する事柄がある。
【００８６】
したがって、ポリシー機構を使用する網データフローのより良好なフィルタリングおよびゲーティング制御が必要とされている。
【００８７】
（発明の開示）
本発明はTS23.207に規定されたアーキテクチュアを使用して、ＵＭＴＳ/ＧＰＲＳ網等の、パケットデータ網におけるＱｏＳ接続を介したデータフローのポリシー駆動フィルタリングおよびゲーティングを提供するポリシー機構を利用してこれらおよびその他の問題に取り組むものである。ローカルＳＩＰプロクシサーバは任意のローカルアプリケーションサーバとすることができ、ポリシー制御機能（“ＰＣＦ”）がポリシーサーバ等の個別のノード内に配置され、アプリケーションサーバとＰＣＦとの間およびＧＧＳＮとＰＣＦとの間にはインターフェイスがある。
【００８８】
一側面に従って、ポリシー制御機構を使用するパケットデータ網内の遠隔ホストとユーザ装置間のＱｏＳ接続においてデータフローをフィルタリングおよびゲーティングする方法は、ＳＩＰプロクシサーバ、リアルタイムストリーミングプロトコル（“ＲＴＳＰ”）サーバ、またはend-to-endシグナリングにより制御されるＩＰベースアプリケーションをサポートする任意タイプのＩＰベースアプリケーションサーバ等のアプリケーションサーバ内のアプリケーションを開始し、かつアプリケーションサーバを介して遠隔ホストとＵＥ間の対応するセッションを開始する遠隔ホスト、またはユーザ装置間、を含んでいる。ＵＥは、網のＧＧＳＮに、ＵＥと遠隔ホスト間の網ベアラサービスの確立を要求する。ポリシーサーバ内の対応するＰＣＦが、アプリケーションサーバから、セッション中にアプリケーションサーバにより受信されたセッションデータから引き出されたフィルタリングデータを受信する。ＧＧＳＮはポリシーサーバ内の対応するＰＣＦに問い合わせてＧＧＳＮにおけるポリシー制御フィルタリングデータを使用してゲートを初期化する。次に、ゲートはポリシー制御フィルタリングデータに従ってＱｏＳ接続内のデータフローをフィルタリングする。
【００８９】
もう一つの側面に従って、アプリケーションサーバがイベントトリガをポリシーサーバに送ってゲート開放を要求し、ポリシーサーバが対応するゲートオープンコマンドをゲートウェイサポートノードに送ってゲートを開く時にゲートが開かれる。ポリシー制御フィルタリングデータに従ってフィルタリングされるデータフローによりＱｏＳ接続内のデータフローを開始するゲートウェイサポートノードによりゲートが開かれる。
【００９０】
さらにもう一つの側面に従って、アプリケーションサーバがイベントトリガをポリシーサーバに送ってゲート閉成を要求し、ポリシーサーバが対応するゲートクローズコマンドをゲートウェイサポートノードに送ってゲートを閉じる時にゲートが閉じられる。ゲートはＱｏＳ接続内のデータフローを終了するゲートウェイサポートノードにより閉じられる。また、セッションはアプリケーションサーバにより終結され網ベアラサービスが終結される。
【００９１】
さらにもう一つの側面において、アプリケーションサーバはオープンインターフェイスを介してポリシーサーバと情報を交換する。
【００９２】
さらにもう一つの側面において、ポリシー制御機能からゲートウェイサポートノードにポリシー判断を転送するのにＣＯＰＳプロトコルが使用される。ポリシー制御機能はＣＯＰＳポリシー判断ポイントとして作用し、ゲートウェイサポートノードはＣＯＰＳポリシー実施ポイントとして作用する。ポリシー実施ポイントはパケット分類子とマッチする所与のＩＰパケットセットに対するＱｏＳにアクセスする。ポリシー判断はポリシー制御機能によりゲートウェイサポートノードにプッシュされるか、あるいはＩＰベアラリソース要求を受けた時にゲートウェイサポートノードがポリシー制御機能からのポリシー情報を要求する。
【００９３】
（詳細な説明）
以下に添付図を参照して本発明の好ましい実施例について説明する。以下の説明では、不要な詳細により本発明が判らなくなるのを回避するために既知の機能および/または構造については詳細に説明はしない。
【００９４】
以下の説明において、ユーザ装置（“ＵＥ”）はユーザが網サービスにアクセスできるようにする装置である。３ＧＰＰ仕様の目的で、ＵＥと網間のインターフェイスは無線インターフェイスである。ＵＥはいくつかのドメインに細分することができ、ドメインは基準点により分離される。ＵＥをいくつかのドメインに分離する側面は本発明の説明には不要であり、したがって、明細書の一部ではない。
【００９５】
無線アクセス網ドメインは、そのリソースを管理する、物理的エンティティを含みコア網にアクセスする機構をユーザに提供する。アクセス網ドメインはアクセス技術に特有の機能を含んでいる。
【００９６】
再び図面に戻って、図１９は本発明に従ってポリシー制御機能を有する制御プレーン内のＵＭＴＳに対するＱｏＳ管理機能およびend-to-end ＩＰ ＱｏＳに対するＱｏＳ管理機能のブロック図である。図２０の制御フロー図を参照して、遠隔ホストがここでは電話呼であるアプリケーションをＳＩＰシグナリングを使用して開始する（１）。ＳＩＰシグナリングは網内のＳＩＰプロクシサーバ内を通過する。ＳＩＰセッションは電話網のアドレススペース内に常駐するそれらのＩＰアドレスにより電話網内のエンドポイントを識別する。しかしながら、呼がこの電話網内で終端しなければ、アドレスはベアラが通過する電話網内のゲートウェイアドレスである。
【００９７】
セッションが開始された後で（２）、ＵＥはデータプレーンに対するＱｏＳイネーブルドＧＰＲＳベアラを確立する必要がある。これはセッションに対する必要条件の一部としてセッション確立中に生じることがある。ＵＥは、従来のベアラのような、要求された特性に基づいて使用されるアクセスベアラタイプを選択しなければならず、ベアラレベルに対するＰＤＰコンテキストを開始する。
【００９８】
次に、ＵＥはＵＭＴＳベアラの確立を要求する（３）。ＧＧＳＮ内の変換/マッピング機能がアクセス網を介して使用するために提供されるＩＰサービスの詳細説明内にＵＭＴＳベアラサービスをマッピングする。ＧＧＳＮ内で、ベアラ要求はＰＣＦと関連づけられ、ＧＧＳＮがそれに問い合わせて特定アクセスＩＰベアラサービスの確立が許可されるかどうかを決定する（４）。ＰＣＦはローカルＳＩＰプロクシサーバの包含等の網要因に応じて特定のアクセスベアラの使用を制限するルールを適用することができる。ＰＣＦはローカルＳＩＰプロクシサーバがこの接続に使用されていることを知らされるため、このベアラタイプの使用が認可される。
【００９９】
アクセスベアラを確立する機関は電話網にデータを送信する機関から独立している。ベアラが確立されると、どのデータが電話網に入るのを許可されるかを制御するＧＧＳＮにおいて“ゲート”が確立される（６）。このゲートは、ＤＳエッジ機能と同様な、データの分類およびポリシングを実施する。ゲートはＰＣＦを介してアプリケーションから受信されるデータにより制御される。
【０１００】
アクティブフェーズに達するセッションの前に、ＵＥはアクセスベアラの提案された使用に関するデータをＧＧＳＮに送ることができる。この情報はＲＳＶＰ等のＩＰレベルシグナリングを介してＧＧＳＮに送ることができ、あるいはＧＰＲＳベアラパラメータから引出すことができる。
【０１０１】
ＧＧＳＮがこのベアラに対するトラフィック使用に関する情報を受信すると、ＩＰ ＢＳマネージャはベアラの使用を認可することができる（５）。提案された使用がＳＩＰプロクシサーバにより認可されたものと一致しなければ、ＧＧＳＮはベアラ確立、またはＲＳＶＰの場合のセッション確立を拒否することができる。この時までにＳＩＰプロクシサーバは認可されたトラフィック記述子に関する情報をＰＣＦに供給していなければならない（２）。
【０１０２】
セッションが適切な状態に達すると（すなわち、アクティブフェーズ）、ＳＩＰプロクシは“session thru”イベントトリガをＰＣＦに送り、それはゲートオープンコマンドをＧＧＳＮに送るようＰＣＦに通知し、ＧＧＳＮにおいてゲートが開いてユーザ装置からのデータを網に入れることができる（７）。
【０１０３】
セッションが終了すると、ＳＩＰプロクシサーバはセッションおよびベアラレベルの両方に対する認可を取り消す。また、ＳＩＰプロクシサーバはＧＧＳＮから電話網に向かって開いているゲートも閉じる。このアクションはいくつかの異なるレベルで生じる。ＳＩＰプロクシサーバは直接ＵＥへのセッションを終結して“セッション終結”イベントトリガをＰＣＦに送り、それはゲートクローズコマンドをＧＧＳＮに送るようＰＣＦに通知し、ＧＧＳＮにおいてゲートが閉じる。最後に、ベアラ終結がまだＵＥから開始されていなければ、ＳＩＰプロクシサーバはベアラを終結させる情報をＰＣＦに送る。
【０１０４】
あるいは、ＰＣＦはさまざまな機能に制御を適用したい情報を異なるアプリケーションから受信することができる。網内のアプリケーションサーバサポートはプロクシサーバ、網内のリアルタイムストリーミングプロトコル（“ＲＴＳＰ”）サーバ、または任意タイプのＩＰベースアプリケーションサポートにより提供することができ、ＩＰベースアプリケーションはend-to-endシグナリングにより制御される。異なるアプリケーションがＧＧＳＮ内で制御している機能は同じであることがあるが、アプリケーションにより供給される実際の情報およびその情報がどのように使用されるかは異なることがある。したがって、ＰＣＦとアプリケーションとの間にはある範囲のプロトコルがあることがある。
【０１０５】
セッションはベアラサービスが認可される前に適切な状態でなければならない。ＧＧＳＮ内のＩＰ ＢＳマネージャがＰＣＦとコンタクトする時は、ＰＣＦはＵＥがベアラタイプに対して認可されるかどうかだけでなく、この時接続がなされることをアプリケーションが認可しているかどうかも判断する。特定のアプリケーションに対していくつかのイベントトリガを規定することができる。アプリケーションイベントが生じる時は、アプリケーションサーバからＰＣＦにイベントトリガが送られる。ＰＣＦにおいて、これはＧＧＳＮに送られるコマンドおよび、前記した典型的な“session thru”および“session termination” イベントトリガのような、ＧＧＳＮ内の対応するポリシー実施アクションとなる。
【０１０６】
ＩＰ ＢＳマネージャにより適用されることがあるポリシー実施内に異なるアクションがある。例えば、ゲートを通ることが許されないデータが受信される場合には、ＩＰ ＢＳマネージャはデータを廃棄したりベアラを終結させる等のアクションをとることができる。ＩＰ ＢＳマネージャと各ポリシー機能に対するＰＣＦとの間で使用されるプロトコルを選択する時は、ポリシー実施オプションの範囲を決定して考慮しなければならない。
【０１０７】
本発明の一つの側面はＧＧＳＮ内の“ゲーティング”機能がＰＣＦを介してＳＩＰプロクシサーバから構成データを受信することである。構成データは一つだけの受け手アドレスに使用を制限する。
【０１０８】
もう一つの実施例では、本発明はＵＭＴＳおよびＧＰＲＳシステムに適用されるＣＯＰＳの専門用語、概念およびフレームワークを使用して説明される。ＩＰポリシーフレームワークおよびプロクシを取り巻くＩＥＴＦにおける最近の発展はベストエフォートサービスよりも良好なサービスに支出したいユーザに適切なＱｏＳを有するサービスを提供する産業攻勢を反映している。この課題の関連するＩＥＴＦ ＲＦＣは[RFC 2573]“A Framework for Policy-based Admission Control”, [RFC 2748]“The COPS Protocol”, [RFC 2749]“COPS usage for RSVP”,等を含んでいる。
【０１０９】
ＵＭＴＳに利用されるＰＣＦ機能はメインストリームＩＰコミュニティにおける専門的技術および開発に勢力を与えるＩＥＴＦ標準に従わせることができる。
【０１１０】
ＰＣＦは標準ＩＰ機構を使用してＩＰベアラレイヤ内にポリシーをインプリメントする論理的ポリシー判断要素である。これらの機構は、例えば、ＩＥＴＦ[RFC 2753]“A Framework for Policy-based Admission Control”に従うことができ、ＰＣＦは実際上ＤＰである。ＰＣＦはポリシールールを使用して網ベースＩＰポリシーに関する判断を行い、これらの判断をＩＰ ＥＰであるＧＧＳＮ内のＩＰ ＢＳマネージャに伝える。
【０１１１】
ＰＣＦおよびＧＧＳＮ間のプロトコルインターフェイスはＧＧＳＮ内のＤＰおよびＩＰ ＢＳマネージャ間の情報およびポリシー判断の転送をサポートする。
【０１１２】
ＣＯＰＳプロトコルはＥＰおよびＰＣＦ間のクライアント/サーバプロトコルとして使用される。ＣＯＰＳクライアント（ＥＰ）はＱｏＳイネーブルド無線ベアラ要求メッセージによりトリガされるＰＣＦからポリシー情報を要求することができる。あるいは、例えば、ＳＩＰプロクシを通すＳＩＰメッセージによりトリガされる外部out-of-band ＱｏＳサービス要求、あるいは網内の任意のアプリケーションサーバを通す他のアプリケーションシグナリングに基づいてＰＣＦが行ったポリシー判断をＣＯＰＳクライアント（ＥＰ）にプッシュすることができる。これらのポリシー判断はＥＰによりアクセスされるローカルポリシー判断ポイント内のＣＯＰＳクライアント（ゲートウェイ内）内に格納されてＰＣＦとの追加インタラクション無しで許可制御判断を行う。
【０１１３】
ＰＣＦはＳＩＰプロクシから内部で得られる情報に基づいてポリシー判断を行う。ＰＣＦはＧＧＳＮと同じドメイン内にあるか、あるいはＧＧＳＮと信頼関係を有する。
【０１１４】
ＥＰはＵＭＴＳアーキテクチュア要求条件を満たすためにＧＧＳＮ内のＩＰベアラサービスマネージャ内にインプリメントされる。ＥＰはパケット分類子とマッチする一組のＩＰパケットに対するＱｏＳへのアクセスを制御する。ポリシー判断はポリシー制御機能によりＧＧＳＮに“プッシュされる”か、あるいは、ＧＧＳＮはＩＰベアラリソース要求を受信するとポリシー制御機能からポリシー情報を要求することができる。
【０１１５】
ポリシー実施はＧＧＳＮ内にインプリメントされたゲートに関して規定される。ゲートはパケットの一方向フロー、例えば、アップストリームまたはダウンストリーム方向に対するポリシー実施機能である。ハイレベルにおいて、ゲートはパケット分類子、リソース“エンベロープ”、および分類子にマッチするパケットセットがリソースエンベロープを越える時にとられるアクションを含んでいる。
【０１１６】
ＩＰベアラサービスリソース割当ての基本単位は一方向フローに対するものであるため、一方向ゲートが使用される。例えば、ＵＥ上のアプリケーションが受信オンリーモードでＩＰマルチキャストセッションに加入している時はダウンストリームオンリーゲートが使用される。ＩＰ電話アプリケーションにおける“遠隔呼出”をサポートするのにダウンストリームオンリーフローも必要であり、呼出信号はＰＳＴＮゲートウェイまたは遠隔ＵＥにより遠隔発生される。このアプリケーションに対して、サービスシナリオのある盗難を回避するために、遠隔ＵＥがピックアップするまでパケットのアップストリームフローをイネーブルしないで、セッションオリジネータへのパケットのダウンストリームフローをイネーブルする必要がある。パケットの両方向フローに対するＱｏＳへのアクセスが所望される場合には、一対のゲートが使用される。
【０１１７】
次に、ゲートと関連づけることができる情報について説明する。この情報は必ずしも使用することができる唯一の情報ではなく、現在理解されたアプリケーションのいくつかをカバーするものである。ゲートは下記の情報により記述される。
【表２】
各ゲートに関連づけられるパケット分類子は下記の情報により記述される。
【表３】
方向はゲートがアップストリームゲートであるかダウンストリームゲートであるかを示す。ＧＧＳＮにおいて見られるように、送り手ＩＰアドレスおよびポートは送り手ＩＰｖ４またはＩＰｖ６アドレスおよびポートを識別する。ＧＧＳＮにおいて見られるように、受け手ＩＰアドレスおよびポートは受け手ＩＰｖ４またはＩＰｖ６アドレスおよびポートを識別する。プロトコルフィールドはパケットのＩＰプロトコルタイプを識別する。方向を除いて、フィールドにワイルドカードを使用することができる。例えば、ＳＩＰセッション内で、ベアラに対する送り手ポートはＳＩＰシグナリングメッセージ内で交換されず、したがって、ゲートが初期化される時にセットアップすることができない。
【０１２０】
認可されたエンベロープはパケット分類子により規定されたパケットセットに対して認可されるリソースの上部境界、すなわち“エンベロープ”、を規定する。認可されたエンベロープは実際に使用されるよりも多くのリソースを認可することができる。認可されたエンベロープは外部網に対するＩＰベアラリソースを規定するため、ピーク情報レート、平均情報レート、および外部網に対するトークンバケットサイズ等のＩＰベアラリソースに関してそれを表現するのが適切である。例えば、InsServ Flowspec はＩＰベアラリソースの適切な表現である。認可されたエンベロープは必要ならばＧＧＳＮ内の変換機能により（ある範囲の）ＵＭＴＳベアラリソースにマッピングされる。認可されたエンベロープにより、ＵＥがリソースの割当てを要求する前に、ＰＣＦはフローを予認可することができる（“プッシュモード”）。
【０１２１】
このアクションはパケット分類子により規定されたパケットセットが認可されたエンベロープまたは保存されたエンベロープ（下記に規定される）を越える時にどんなアクションがとられるかを規定する。このアクションは特異なDiffServ Code Point（“ＤＳＣＰ”）で out-of-profile をマーキングする、特異なＤＳＣＰで in-profile パケットをマーキングする、トークンバケットに整形する、またはパケットドロッピングすることを含む。
【０１２２】
前記規定に従って、一組のパケットは二つ以上の分類子とマッチすることができる。これが生じると、適用可能な各ゲートに関連づけられるアクションは、ゲートがＧＧＳＮ内に構成された順序で、逐次実行されると考えられる。ゲートによりマーキングされたパケットは後続ゲートによりより良いサービスクラスに対応するＤＳＣＰに再マーキングされないことがある。
【０１２３】
リソース識別子は、例えば、いくつかのセッションに対する多数のゲートにより共有されることがある一組のリソースを識別する。例えば、リソース識別子はＵＥが、呼待機中等に、リソースを同時使用しない二つのセッションに対して一組のリソースを共有できるようにする。リソース識別子はＰＤＰコンテキスト活性化/修正要求のＩＰベアラサービス情報要素内に含められてこの機能をサポートする。
【０１２４】
保存されたエンベロープはベアラに対して保存されるリソースの上部境界すなわち“エンベロープ”を規定する。保存されたエンベロープはＵＥに対して実際に使用されるよりも多くのリソースを保存できる場合に有利である。例えば、呼待機中に、ＵＥはアクティブセッションに対しては低品位コーデックを使用しながら一時的なイナクティブセッションに対しては高品質コーデックの保存を維持することができる。保存されたエンベロープはリソース保存が許可制御を実施することを暗示し、成功すれば、要求されたリソースをプリアンブルモードにしておく。この機能のサポートには保存要求とリソース使用とを区別するＰＤＰコンテキスト活性化および修正手順が必要である。
【０１２５】
認可トークンはＧＧＳＮにおける一つ以上のゲートに対応するポリシー情報を一意的に識別する。認可トークンはＵＥからのリソース保存要求（例えば、ＰＤＰコンテキスト活性化要求）をＰＣＦからの認可コマンドと相関させるのに使用することができる。この機能をサポートするために、認可トークンはＰＤＰコンテキスト活性化要求（無線ベアラセットアップ要求）、ポリシー制御インターフェイス（判断がＰＣＦからＧＧＳＮに転送される時はＰＣＦとゲートウェイ間）、およびプロクシＣＳＣＦとＵＥまたは任意他の関連するアプリケーションシグナリング間のＳＩＰシグナリングメッセージ内に含める必要がある。認可トークンはゲートウェイ内で開始される一つ以上のゲートに対する一意的識別子を含み、確立された無線ベアラのＰＣＦが行った判断へのバインディングであり、判断はメッセージ内でＰＣＦからゲートウェイに転送される。
【０１２６】
ＩＰ ＱｏＳ許可制御は管理ポリシーおよび利用可能なリソースに基づいてＱｏＳリソースの割当てを管理する。管理ポリシーに基づいた許可制御はＧＧＳＮ、およびＰＣＦ内のＩＰベアラサービスマネージャ内のポリシー実施を伴うクライアント/サーバアーキテクチュアを使用して実施される。ＣＯＰＳプロトコルはこのインターフェイスに理想的である。
【０１２７】
ＣＯＰＳプロトコルはＥＰおよびＰＣＦ間のクライアント/サーバプロトコルとして使用される。ＣＯＰＳクライアント（ＥＰ）はＱｏＳシグナリング要求によりトリガーされたＰＣＦからポリシー情報を要求することができる。あるいは、ＰＣＦが行った判断を、例えば、ＳＩＰシグナリングによりトリガーされた、外部 out-of-band ＱｏＳサービス要求に基づいてＣＯＰＳクライアント（ＥＰ）にプッシュすることができる。これらのポリシー判断はＥＰによりアクセスされるローカルポリシー判断ポイントにおけるＣＯＰＳクライアント内に格納され、ＰＣＦとの追加インタラクションを要求することなく許可制御判断を行う。
【０１２８】
ＣＯＰＳプロトコルはクライアントおよびサーバ間のいくつかのメッセージをサポートする。これらのメッセージには実施できる下記の操作が含まれる。
【表４】
プル（アウトソーシング）モデルはクライアント-駆動方法を表わし、ＰＣＦはＥＰからの着信ポリシー要求にアクティブに応答する。一つのＥＰ要求に二三のＰＣＦ判断が続くことがある。非同期通知によりＰＣＦは前の判断の変更、エラー発生、等が必要な時はいつでもＧＧＳＮ内のＥＰに通知することができる。
【０１３０】
プルモデルはＰＤＰコンテキスト活性化およびＰＤＰ修正において使用することができる。後続フェーズにおいて、プルモデルを使用することができる。
【０１３１】
ポリシー認可に対するＣＯＰＳプルモデルを考えると、ＥＰから送られるメッセージは要求、更新、報告およびメッセージ削除であり、ＰＣＦから送られるメッセージは判断および更新である。
【０１３２】
ＵＭＴＳ ＱｏＳアーキテクチュアをサポートするために追加情報要素をＣＯＰＳ内に含める必要がある。ＣＯＰＳフレームワークと一貫して、ＵＭＴＳクライアント（ＧＧＳＮ）に割り当てられる一意的“クライアントタイプ”によりポリシー制御インターフェイスが識別される。アーキテクチュア内に必要なオブジェクトは表５および６に記載され、以下に説明される。
【表５】
認可トークンはコマンドまたは応答内で参照されている一つ以上のゲートに対する一意的識別子を含む。認可トークンはＧＧＳＮのポリシー制御を提供していることがある多数のポリシー制御機能をサポートする。
【０１３４】
ＰＣＦからＥＰに使用されるコマンドは下記のコマンドを含む。
【表６】
ＥＰからＰＣＦに必要な応答は受信応答および/またはこれらの各コマンドに対するエラー応答を含む。
【０１３６】
ゲートスペックオブジェクトは応答内にセットされたり応答で戻されるゲートパラメータの仕様を含む。コマンドまたは応答は、表７に示すような、認可トークンに関連する一つ以上のゲートスペックオブジェクトを含むことができなければならない。
【表７】
イベント発生infoはＩＰ ＱｏＳベアラに必要なことがある使用記録に関する情報を含む。これは、同じセッションに関連する全記録が対応できるように、ＧＧＳＮからのイベント記録をプロクシＣＳＣＦからのイベント記録と相関させるのに必要な“課金識別子”を含むことができる。課金識別子を一意的とするためにそれは、例えば、ＰＣＦのアイデンティティと共にＰＣＦにより発生される長い数値を含むことがある。
【０１３８】
エンドポイント識別子およびマックスゲートフィールドは過剰数の同時セッションのセットアップを試みるサービスアタックのＵＥ-開始否定を防止するのに使用され、多数のゲートの割当てを生じる。エンドポイント識別子は認可トークンに関連するエンドポイントのアイデンティティ（例えば、ＩＰアドレス）を含み、マックスゲートフィールドはこの特定エンドポイントに割り当てることができる最大数のゲートを含んでいる。割り当てられたゲート数がマックスゲートを越える場合には、ＧＧＳＮはエラーを戻すことができる。
【０１３９】
説明された発明は３ＧＰＰシステム内で有利に標準化することができる。
【０１４０】
前記した方法のステップは適切なプロセッサにより実行されるソフトウェアまたは、特定応用集積回路（“ＡＳＩＣ”）等の、ハードウェアにより容易にインプリメントすることができる。
【０１４１】
通信システムに関して説明してきたが、当業者ならば本発明はその本質的特徴から逸脱することなく他の特定形式で実施できることがお判りであろう。例えば、本発明は任意のマルチプロセッサで使用することができる。したがって、前記した実施例はあらゆる側面において説明用であって制約的意味合いは無い。
【０１４２】
いくつかの典型的な実施例に関して本発明のさまざまな側面について説明してきた。本発明の理解を容易にするために、本発明の多くの側面はコンピュータシステムの要素により実施することができる一連のアクションに関して説明された。例えば、各実施例において、さまざまなアクションは特殊化された回路（例えば、特殊化された機能を実施するように相互接続された個別論理ゲート）、一つ以上のプロセッサにより実行されるプログラム命令、または両者の組合せにより実施できることが認識される。
【０１４３】
さらに、ここに記載された技術をプロセッサに実施させる適切なコンピュータ命令セットを内部に格納している任意形状のコンピュータ読取り可能記憶媒体内で本発明の全体を実施することも考えられる。したがって、本発明のさまざまな側面は多くの異なる形式で実施することができ、このような形式は全て本発明の範囲に入るものとする。本発明のさまざまな側面の各々について、実施例の任意のこのような形式をここでは記述されたアクションを実施“するように論理的に構成されている”、もしくは記述されたアクションを実施する“論理”と言うことができる。
【０１４４】
“含む(comprisesおよびcomprising)”という用語は、特許請求の範囲だけでなく本明細書で使われる場合、述べられた特徴、ステップまたはコンポーネントの存在を指定するものととられるが、これらの用語の使用一つ以上の他の特徴、ステップ、コンポーネントまたはそれらのグループの存在を排除するものではないことを強調しなければならない。
【０１４５】
出願人の発明のさまざまな実施例について説明してきたが、当業者ならばこれらの実施例は単なる説明用であって任意他の実施例が可能であることがお判りであろう。意図する発明の範囲は明細書ではなく特許請求の範囲に記載されており、特許請求の範囲内に入るあらゆるバリエーションがそこに含まれるものとする。
【０１４６】
関連出願の相互参照
本出願は2000年5月22日に出願された米国仮出願第60/206,186号“All IPPolicy Architecture”および2000年11月6日に出願された第60/246,501号“Enable User Choice in a System Using Application Influenced Policy”に関連し、かつ優先権を請求するものであり、それらの開示は本開示の一部としてここに組み入れられている。
【図面の簡単な説明】
【図１】 ハイレベルＩＰ網のブロック図である。
【図２】 end-to-end統合サービスを利用する網の例を示すブロック図である。
【図３】 ＲＳＶＰプロクシを利用する網の例を示すブロック図である。
【図４】 end-to-end differentiated services を利用する網の例を示すブロック図である。
【図５】 differentiated services と相互作用するＲＳＶＰシグナリングを利用する網の例を示すブロック図である。
【図６】 DiffServとしてモデル化された移動アクセスデータ網を示すブロック図である。
【図７】 ＵＭＴＳ ＱｏＳアーキテクチュアのブロック図である。
【図８】 制御プレーン内のＵＭＴＳベアラサービスに対するＱｏＳ管理機能を示すブロック図である。
【図９】 ユーザプレーン内のＵＭＴＳベアラサービスに対するＱｏＳ管理機能を示すブロック図である。
【図１０】 ＵＭＴＳ ＱｏＳクラスのテーブルである。
【図１１】 ＱｏＳ属性のテーブルである。
【図１２】 図１１のＱｏＳ属性に対するある使用の概観を提供するテーブルである。
【図１３】 ＰＤＰアドレス、ＰＤＰコンテキスト、およびＴＦＴ間の関係のブロック図である。
【図１４】 ＴＦＴパケットフィルタ属性の有効な組合せのテーブルである。
【図１５】 ＰＤＰコンテキストメッセージ交換を示す図である。
【図１６】 制御プレーン内のＵＭＴＳベアラサービスに対するＱｏＳ管理機能およびend-to-end ＩＰ ＱｏＳに対するＱｏＳ管理機能のブロック図である。
【図１７】 ＩＰマルチメディアシステムのＧＰＲＳベアラへの相互関係を示す図である。
【図１８】 ＩＥＴＦポリシーフレームワークを示す図である。
【図１９】 制御プレーン内のＵＭＴＳベアラサービスに対するＱｏＳ管理機能および本発明に従ったポリシー制御機能を有するend-to-end ＩＰ ＱｏＳに対するＱｏＳ管理機能のブロック図である。
【図２０】 本発明の実施例に従った図１９の要素間のメッセージフロー図である。
Claims (41)
- ポリシー制御機構を使用してパケットデータ網内の遠隔ホストとユーザ装置間のＱｏＳ接続におけるデータフローをフィルタリングおよびゲーティングする方法であって、
遠隔ホストおよびユーザ装置の一方により、網内のアプリケーションサーバによりサポートされるアプリケーション、およびアプリケーションサーバを介した遠隔ホストとユーザ装置間の対応するセッションを開始するステップと、
ユーザ装置により網のゲートウェイサポートノードに、ユーザ装置と遠隔ホスト間の網ベアラサービスの確立を要求するステップであって、前記網ベアラサービスは異なる程度のＱｏＳを許すことにより区別されるステップと、
ポリシーサーバ内の対応するポリシー制御機能により、セッション中にユーザ装置および遠隔ホストからアプリケーションサーバにより受信されるセッションデータから引き出されたフィルタリングデータを受信するステップであって、前記フィルタリングデータはポリシー制御機能により処理されて対応するポリシー制御フィルタリングデータを引出すものである前記受信ステップと、
ゲートウェイサポートノードにより、ポリシーサーバ内の対応するポリシー制御機能に問い合わせて網ベアラサービスの確立が許されるかどうかを決定するステップと、
網ベアラサービスの確立が許される場合には、ゲートウェイサポートノードにおいてゲートを確立するステップであって、前記ゲートはゲートウェイサポートノードがポリシー制御機能を問い合わせた結果あるいはポリシーサーバによりゲートウェイサポートノードにプッシュされるポリシー制御フィルタリングデータの結果受信されるポリシー制御フィルタリングデータにより初期化され、前記ゲートはＱｏＳ接続におけるデータフローをフィルタリングするように初期化されるステップと、
を含む方法。 - 請求項１記載の方法であって、さらに、
アプリケーションサーバにより、イベントトリガをポリシーサーバに送ってゲート開放を要求するステップと、
ポリシーサーバにより、対応するゲートオープンコマンドをゲートウェイサポートノードに送ってゲートを開くステップであって、前記ゲート開放によりＱｏＳ接続におけるデータフローが開始されるステップと、
ゲートにより、ポリシー制御フィルタリングデータに従ってＱｏＳ接続におけるデータフローをフィルタリングするステップと、
を含む方法。 - 請求項２記載の方法であって、さらに、
アプリケーションサーバにより、イベントトリガをポリシーサーバに送ってゲート閉成を要求するステップと、
ポリシーサーバにより、対応するゲートクローズコマンドをゲートウェイサポートノードに送ってゲートを閉じるステップと、
ゲートクローズコマンドに応答してゲートを閉じてデータフローを終了するステップと、
アプリケーションサーバによりユーザ装置とのセッションを終結するステップと、
網ベアラサービスを終結するステップと、
を含む方法。 - 請求項１記載の方法であって、アプリケーションサーバはＳＩＰプロクシサーバである方法。
- 請求項４記載の方法であって、前記ＳＩＰプロクシサーバはオープンインターフェイスを介してポリシーサーバと情報を交換する方法。
- 請求項１記載の方法であって、アプリケーションサーバはリアルタイムストリーミングプロトコル（“ＲＴＳＰ”）である方法。
- 請求項６記載の方法であって、前記ＲＴＳＰサーバはオープンインターフェイスを介してポリシーサーバと情報を交換する方法。
- 請求項１記載の方法であって、アプリケーションサーバは任意タイプのＩＰベースアプリケーションをサポートし、前記ＩＰベースアプリケーションはend-to-endシグナリングにより制御される方法。
- 請求項８記載の方法であって、前記ＩＰベースアプリケーションサーバはオープンインターフェイスを介してポリシーサーバと情報を交換する方法。
- 請求項１記載の方法であって、前記ゲートウェイサポートノードはオープンインターフェイスを介してポリシーサーバと情報を交換する方法。
- 請求項１記載の方法であって、フィルタリングデータはトラフィック記述子を含む方法。
- 請求項１記載の方法であって、ゲートはポリシー制御フィルタリングデータに含まれたオブジェクトを受信し、前記オブジェクトは応答内にセットされるまたは応答により戻されるゲートパラメータの仕様を含み、前記オブジェクトは方向、送り手ＩＰアドレス、受け手ＩＰアドレス、送り手ポート、受け手ポート、プロトコル、アクション、ＤＳＣＰフィールド、およびFlowspecを含む方法。
- 請求項１記載の方法であって、ユーザ装置は遠隔ホストとユーザ装置間のセッション確立中に接続に対するＱｏＳイネーブルドＧＰＲＳ無線ベアラサービスを確立し、前記ＱｏＳイネーブルドＧＰＲＳ無線ベアラサービスはユーザ装置と遠隔ホスト間のecd-to-endトランスポートの一セグメントとしてユーザ装置とゲートウェイサポートノード間のＩＰパケットのＱｏＳイネーブルドトランスポートに対して使用される方法。
- 請求項１３記載の方法であって、ＱｏＳイネーブルドＧＰＲＳ無線ベアラサービスはゲートウェイサポートノードで使用するために供給されているＩＰサービスの詳細記述に変換される方法。
- 請求項１４記載の方法であって、ゲートウェイサポートノードはユーザ装置から受信した使用情報に基づいてＱｏＳイネーブルド無線ベアラサービスの使用を決定し、使用がゲートウェイサポートノードで確立されたポリシー判断に従わない場合には無線ベアラサービス要求を拒否する方法。
- 請求項１記載の方法であって、ポリシー制御機能はフィルタリングデータに応じて特定のアクセスベアラの使用を制限するルールを適用する方法。
- 請求項１記載の方法であって、ゲートウェイサポートノード内のポリシー実施の一部として、ゲートは非認可データが検出される時に廃棄データの一つによりデータフローをフィルタリングするかまたは網ベアラサービスを終了する方法。
- 請求項１記載の方法であって、ポリシー制御機能からゲートウェイサポートノードにポリシー判断を転送するのにＣＯＰＳプロトコルが使用され、ポリシー制御機能はＣＯＰＳポリシー判断ポイントとして作用しゲートウェイサポートノードはＣＯＰＳポリシー実施ポイントとして作用し、前記ポリシー実施ポイントはパケット分類子にマッチングするＩＰパケットの所与のセットに対するＱｏＳへのアクセスを制御する方法。
- 請求項１８記載の方法であって、ポリシー判断はポリシー制御機能によりゲートウェイサポートノードにプッシュされるか、あるいはＩＰベアラリソース要求を受信するとゲートウェイサポートノードがポリシー制御機能からポリシー情報を要求する方法。
- 請求項１８記載の方法であって、ポリシー制御機能およびゲートウェイサポートノードは少なくとも下記のタイプのＣＯＰＳ情報および手順を交換する方法、クライアント-オープン/クライアント-受理/クライアント-クローズ、要求、判断、報告、状態、要求状態削除、キープアライブ、状態要求同期化/状態完了同期化。
- 請求項１８記載の方法であって、ポリシー制御機能およびゲートウェイサポートノードは少なくとも下記のポリシー関連無線網特定要素を交換する方法、認可トークン、コマンド/応答、一つ以上のゲートスペック、イベント発生情報、エンドポイント識別子、マックスゲート。
- 請求項２１記載の方法であって、コマンドは少なくとも、認可トークンを割り当てる、一つ以上のメディアフローに対してＱｏＳリソースを認可する、ＱｏＳリソースをコミットする、ＱｏＳリソースの認可を取り消す、認可トークンに関連するパラメータ/情報を得る、コマンドを含み、応答は受信応答および/またはこれらの各コマンドへのエラー応答を含む方法。
- 請求項２１記載の方法であって、イベント発生情報はＩＰＱｏＳベアラに使用された使用記録に関連する情報を含み、この情報はゲートウェイサポートノードからのイベントレコードをプロクシ呼状態制御機能からのイベントレコードと相関させて同じセッションに関連する全レコードを関連づけられるようにする課金識別子を含む方法。
- 請求項２１記載の方法であって、エンドポイント識別子およびマックスゲートフィールドは多数のゲートの割当てを生じる過剰数の同時セッションのセットアップを試みるサービスアタックのユーザ装置開始否定を防止するのに使用され、エンドポイント識別子は認可トークンに関連するエンドポイントのアイデンティティを含み、マックスゲートフィールドはこの特異のエンドポイントに割り当てることができる最大数のゲートを含む方法。
- 請求項２１記載の方法であって、ＩＰベアラリソース要求を受信した時に、ポリシー制御機能からのポリシー情報に対する一つのゲートウェイサポートノード要求（プル要求）には二三のポリシー制御機能判断が続くことがあり非同期通知によりポリシー制御機能は必要ならばいつでもゲートウェイサポートノード内のポリシー実施ポイントを通知して前の判断を変更するかエラーを発生することができ、プル要求は網ベアラセットアップおよび網ベアラ修正において使用することができ後続フェーズにおいてポリシー判断はポリシー制御機能によりゲートウェイサポートノードにプッシュされる方法。
- 請求項２１記載の方法であって、認可トークンはゲートウェイサポートノードにおける一つ以上のゲートに対応するポリシー情報を一意的に識別しユーザ装置からのリソース保存要求をポリシー制御機能からの認可コマンドと相関させるのに使用され、認可トークンはポリシー制御機能からゲートウェイサポートノードに判断が転送される時に使用されるポリシー制御機能とゲートウェイサポートノード間のポリシー制御インターフェイスを介して使用されるメッセージ内、およびＳＩＰプロクシサーバであるアプリケーションサーバとユーザ装置間のＳＩＰシグナリングメッセージ内の網ベアラ要求メッセージに含まれ、認可トークンはゲートウェイサポートノード内で開始される一つ以上のゲートに対する一意的識別子を含み確立された無線ベアラのポリシー制御機能が行った判断へのバインディングであり、前記判断はメッセージ内でポリシー制御機能からゲートウェイサポートノードに転送される方法。
- 請求項２６記載の方法であって、網ベアラ要求はＧＰＲＳ活性化/修正要求メッセージ内の認可トークンを運ぶＱｏＳイネーブルドＧＰＲＳ無線ベアラサービスである方法。
- 請求項２６記載の方法であって、認可トークンはゲートウェイサポートノードのポリシー制御を提供することができる多数のポリシー制御機能をサポートする方法。
- 請求項１記載の方法であって、ゲートは少なくともパケット識別子、認可されたエンベロープ、アクション、リソース識別子、および保存されたエンベロープにより記述される方法。
- 請求項２９記載の方法であって、各ゲートに関連するパケット識別子は少なくとも方向、送り手ＩＰアドレス、受け手ＩＰアドレス、送り手ポート、受け手ポート、およびプロトコルにより記述される方法。
- 請求項１記載の方法であって、パケットデータ網はＵＭＴＳ網である方法。
- 請求項１記載の方法であって、セッションはＳＩＰセッションである方法。
- 請求項１記載の方法であって、接続はend-to-end ＩＰＱｏＳ接続である方法。
- ポリシー制御機構を使用してパケットデータ網内のパケットデータフローをフィルタリングおよびゲーティングする方法であって、
網内のアプリケーションサーバによりサポートされるアプリケーション、およびアプリケーションサーバを介した遠隔ホストとユーザ装置間の対応するセッションを開始するステップと、
ユーザ装置により網のゲートウェイサポートノードに、ユーザ装置と遠隔ホスト間の網ベアラサービスの確立を要求するステップと、
ポリシーサーバ内の対応するポリシー制御機能により、セッション中にユーザ装置および遠隔ホストからアプリケーションサーバにより受信されるセッションデータから引き出されたフィルタリングデータを受信するステップであって、前記フィルタリングデータはポリシー制御機能により処理されて対応するポリシー制御フィルタリングデータを引出すものである前記受信ステップと、
ポリシー制御フィルタリングに従って網ベアラサービスを確立しゲートウェイサポートノードにおけるゲートを初期化するステップであって、前記ゲートは網内のパケットデータフローをフィルタリングするように初期化されるステップと、を含む方法。 - 請求項３４記載の方法であって、さらに、
アプリケーションサーバにより、イベントトリガをポリシーサーバに送ってゲート開放を要求するステップと、
ポリシーサーバにより、対応するゲートオープンコマンドをゲートウェイサポートノードに送ってゲートを開くステップであって、前記ゲート開放によりＱｏＳ接続におけるデータフローが開始される前記ステップと、
ゲートにより、ポリシー制御フィルタリングデータに従ってＱｏＳ接続におけるデータフローをフィルタリングするステップと、
を含む方法。 - 請求項３５記載の方法であって、さらに、
アプリケーションサーバにより、イベントトリガをポリシーサーバに送ってゲート閉成を要求するステップと、
ポリシーサーバにより、対応するゲートクローズコマンドをゲートウェイサポートノードに送ってゲートを閉じるステップと、
ゲートクローズコマンドに応答してゲートを閉じてデータフローを終了するステップと、
アプリケーションサーバによりユーザ装置とのセッションを終結するステップと、
網ベアラサービスを終結するステップと、
を含む方法。 - 請求項３４記載の方法であって、アプリケーションサーバはＳＩＰプロクシサーバである方法。
- ポリシー制御機構を使用してＵＭＴＳ網内の遠隔ホストとユーザ装置間のend-to-end ＱｏＳ接続におけるデータフローをフィルタリングおよびゲーティングする方法であって、
遠隔ホストおよびユーザ装置の一方により、プロクシサーバによりサポートされるアプリケーション、およびプロクシサーバを介した遠隔ホストとユーザ装置間の対応するセッションを開始するステップと、
ユーザ装置により網のゲートウェイサポートノードに、ユーザ装置と遠隔ホスト間の網ベアラサービスの確立を要求するステップであって、前記網ベアラサービスは異なる程度のＱｏＳを許すことにより区別されるステップと、
ポリシーサーバ内の対応するポリシー制御機能により、セッション中にユーザ装置および遠隔ホストからプロクシサーバにより受信されるセッションデータから引き出されたフィルタリングデータを受信するステップであって、前記フィルタリングデータはポリシー制御機能により処理されて対応するポリシー制御フィルタリングデータを引出すステップと、
ゲートウェイサポートノードにより、ポリシーサーバ内の対応するポリシー制御機能に問い合わせて網ベアラサービスの確立が許されるかどうかを決定するステップと、
網ベアラサービスの確立が許される場合には、ゲートウェイサポートノードにおいてゲートを確立するステップであって、前記ゲートはゲートウェイサポートノードがポリシー制御機能を問い合わせた結果あるいはポリシーサーバによりゲートウェイサポートノードにプッシュされるポリシー制御フィルタリングデータの結果受信されるポリシー制御フィルタリングデータにより初期化され、前記ゲートはend-to-end ＱｏＳ接続におけるデータフローをフィルタリングするように初期化されるステップと、
を含む方法。 - 請求項３８記載の方法であって、さらに、
プロクシサーバにより、イベントトリガをポリシーサーバに送ってゲート開放を要求するステップと、
ポリシーサーバにより、対応するゲートオープンコマンドをゲートウェイサポートノードに送ってゲートを開くステップであって、前記ゲート開放によりＱｏＳ接続におけるデータフローが開始されるステップと、
ゲートにより、ポリシー制御フィルタリングデータに従ってＱｏＳ接続におけるデータフローをフィルタリングするステップと、
を含む方法。 - 請求項３９記載の方法であって、さらに、
プロクシサーバにより、イベントトリガをポリシーサーバに送ってゲート閉成を要求するステップと、
ポリシーサーバにより、対応するゲートクローズコマンドをゲートウェイサポートノードに送ってゲートを閉じるステップと、
ゲートクローズコマンドに応答してゲートを閉じてデータフローを終了するステップと、
アプリケーションサーバによりユーザ装置とのセッションを終結するステップと、
網ベアラサービスを終結するステップと、
を含む方法。 - 請求項３８記載の方法であって、プロクシサーバはＳＩＰプロクシサーバである方法。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US20618600P | 2000-05-22 | 2000-05-22 | |
| US60/206,186 | 2000-05-22 | ||
| US09/861,817 | 2001-05-21 | ||
| US09/861,817 US6621793B2 (en) | 2000-05-22 | 2001-05-21 | Application influenced policy |
| PCT/SE2001/001175 WO2001091389A2 (en) | 2000-05-22 | 2001-05-22 | Policy driven filtering of packet flow in qos connection in umts/gprs network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003534716A JP2003534716A (ja) | 2003-11-18 |
| JP4536990B2 true JP4536990B2 (ja) | 2010-09-01 |
Family
ID=26901126
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001586858A Expired - Lifetime JP4536990B2 (ja) | 2000-05-22 | 2001-05-22 | アプリケーション影響ポリシー |
Country Status (7)
| Country | Link |
|---|---|
| EP (1) | EP1284073B1 (ja) |
| JP (1) | JP4536990B2 (ja) |
| CN (1) | CN1201534C (ja) |
| AT (1) | ATE371321T1 (ja) |
| AU (1) | AU2001260941A1 (ja) |
| DE (1) | DE60130114T2 (ja) |
| WO (1) | WO2001091389A2 (ja) |
Families Citing this family (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8144690B2 (en) | 2000-06-08 | 2012-03-27 | Thomson Licensing S.A. | ATM multicasting for delivering information over a network |
| WO2002037869A2 (en) * | 2000-11-06 | 2002-05-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for coordinating quality of service requirements for media flows in a multimedia session with ip bearer resources |
| US7483989B2 (en) * | 2001-03-13 | 2009-01-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for establishing a protocol proxy for a mobile host terminal in a multimedia session |
| US7443835B2 (en) | 2001-12-03 | 2008-10-28 | Nokia Corporation | Policy based mechanisms for selecting access routers and mobile context |
| US6661780B2 (en) * | 2001-12-07 | 2003-12-09 | Nokia Corporation | Mechanisms for policy based UMTS QoS and IP QoS management in mobile IP networks |
| AU2002357144A1 (en) * | 2001-12-15 | 2003-06-30 | Thomson Licensing S.A. | Quality of service setup on a time reservation basis |
| WO2003065750A1 (en) * | 2001-12-27 | 2003-08-07 | Nokia Corporation | Method and system for locating a mobile terminal |
| KR100438430B1 (ko) * | 2002-01-24 | 2004-07-03 | 삼성전자주식회사 | 이동통신시스템에서 트래픽 플로우 탬플릿 재정렬 장치 및방법 |
| FR2836315B1 (fr) * | 2002-02-21 | 2005-02-18 | Cit Alcatel | Correlation des requetes en qualite de service au sein d'un systeme de controle d'un reseau de donnees |
| GB0207454D0 (en) * | 2002-03-28 | 2002-05-08 | British Telecomm | Method of data transfer in mobile and fixed telecommunications systems |
| US8619718B2 (en) | 2002-04-05 | 2013-12-31 | Interdigital Technology Corporation | Method and apparatus for coordinating a radio network controller and node B resource management for high speed downlink packet data service |
| FI115687B (fi) | 2002-04-09 | 2005-06-15 | Nokia Corp | Pakettidatan siirtäminen langattomaan päätelaitteeseen |
| US7206324B2 (en) * | 2002-05-03 | 2007-04-17 | Telefonaktiebolaget Lm Ericsson (Publ) | QoS translator |
| FI20021093A0 (fi) * | 2002-06-07 | 2002-06-07 | Nokia Corp | Tiedonsiirtomenetelmä ja -järjestelmä |
| AU2002314148A1 (en) * | 2002-06-07 | 2003-12-22 | Siemens Aktiengesellschaft | Method and device for authenticating a subscriber for utilizing services in a wireless lan (wlan) |
| US7209458B2 (en) * | 2002-09-27 | 2007-04-24 | Nokia Corporation | Enhanced QoS control |
| CN100337414C (zh) * | 2002-10-18 | 2007-09-12 | 华为技术有限公司 | 一种宽带码分多址系统中的服务质量协商方法 |
| FR2850828B1 (fr) * | 2003-01-31 | 2005-04-29 | Evolium Sas | Procede pour la gestion de la qualite de service dans un systeme de radiocommunications mobiles |
| GB2398458B (en) | 2003-02-15 | 2005-05-25 | Ericsson Telefon Ab L M | Conversational bearer negotiation |
| US7478159B2 (en) | 2003-02-21 | 2009-01-13 | Nokia Corporation | Policy information in multiple PDFs |
| GB0328756D0 (en) * | 2003-12-11 | 2004-01-14 | Nokia Corp | Controlling transportation of data packets |
| GB0329221D0 (en) * | 2003-12-17 | 2004-01-21 | Nokia Corp | Session control in a communication system |
| PL1763964T3 (pl) * | 2004-07-05 | 2011-04-29 | Ericsson Telefon Ab L M | Urządzenia i sposoby dla usługi uaktywnianej komunikatem typu push |
| CN100514961C (zh) * | 2004-08-02 | 2009-07-15 | 华为技术有限公司 | 一种网际协议服务质量的信令交互方法 |
| US8477605B2 (en) * | 2004-09-29 | 2013-07-02 | Rockstar Consortium Us Lp | Preventing illicit communications |
| CN1870635B (zh) | 2005-10-18 | 2010-11-10 | 华为技术有限公司 | 一种服务质量授权方法 |
| WO2007071369A1 (en) * | 2005-12-19 | 2007-06-28 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Communication device and method for filtering data according to a data policy |
| DE602006010910D1 (de) * | 2006-02-05 | 2010-01-14 | Ericsson Telefon Ab L M | Verfahren und einrichtungen zum installieren von paketfiltern bei einer datenübertragung |
| US20080194233A1 (en) * | 2007-02-12 | 2008-08-14 | Bridgewater Systems Corp. | Systems and methods for context-aware service subscription management |
| CN101369909A (zh) * | 2007-08-15 | 2009-02-18 | 华为技术有限公司 | 上报策略执行结果的方法、网络通信系统和设备 |
| CN101399826B (zh) * | 2007-09-26 | 2012-09-26 | 朗讯科技公司 | 用于会话初始协议的信令管理系统和方法 |
| ES2817080T3 (es) * | 2007-11-19 | 2021-04-06 | Ericsson Telefon Ab L M | Autorización previa de establecimiento de portador |
| CN103856484B (zh) * | 2007-11-19 | 2017-01-25 | 艾利森电话股份有限公司 | 承载建立的预授权 |
| US9066354B2 (en) | 2008-09-26 | 2015-06-23 | Haipeng Jin | Synchronizing bearer context |
| US9106541B2 (en) * | 2008-12-10 | 2015-08-11 | Telefonaktiebolaget L M Ericsson (Publ) | Token-based correlation of control sessions for policy and charging control of a data session through a NAT |
| US11695818B2 (en) * | 2019-03-15 | 2023-07-04 | Koninklijke Kpn N.V. | Facilitating real-time transport of data streams |
| CN110417888A (zh) * | 2019-07-30 | 2019-11-05 | 中国工商银行股份有限公司 | 流量控制方法、流量控制装置和电子设备 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6021263A (en) * | 1996-02-16 | 2000-02-01 | Lucent Technologies, Inc. | Management of ATM virtual circuits with resources reservation protocol |
| KR100658293B1 (ko) * | 1998-04-03 | 2006-12-14 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | 범용 이동 전화 시스템에서 유연한 무선 액세스 및 자원할당 |
-
2001
- 2001-05-22 AU AU2001260941A patent/AU2001260941A1/en not_active Abandoned
- 2001-05-22 AT AT01934791T patent/ATE371321T1/de active
- 2001-05-22 DE DE60130114T patent/DE60130114T2/de not_active Expired - Lifetime
- 2001-05-22 CN CNB018132219A patent/CN1201534C/zh not_active Expired - Lifetime
- 2001-05-22 EP EP01934791A patent/EP1284073B1/en not_active Expired - Lifetime
- 2001-05-22 JP JP2001586858A patent/JP4536990B2/ja not_active Expired - Lifetime
- 2001-05-22 WO PCT/SE2001/001175 patent/WO2001091389A2/en active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| AU2001260941A1 (en) | 2001-12-03 |
| CN1201534C (zh) | 2005-05-11 |
| ATE371321T1 (de) | 2007-09-15 |
| EP1284073A2 (en) | 2003-02-19 |
| WO2001091389A3 (en) | 2002-03-28 |
| DE60130114T2 (de) | 2008-05-15 |
| WO2001091389A2 (en) | 2001-11-29 |
| CN1443414A (zh) | 2003-09-17 |
| DE60130114D1 (de) | 2007-10-04 |
| EP1284073B1 (en) | 2007-08-22 |
| JP2003534716A (ja) | 2003-11-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4536990B2 (ja) | アプリケーション影響ポリシー | |
| US6621793B2 (en) | Application influenced policy | |
| US7546376B2 (en) | Media binding to coordinate quality of service requirements for media flows in a multimedia session with IP bearer resources | |
| EP1250787B1 (en) | Rsvp handling in 3g networks | |
| US20030120135A1 (en) | Method for remote medical consultation and care | |
| KR101098715B1 (ko) | 데이터 전송 시에 패킷 필터를 설치하는 방법 및 장치 | |
| US20020062379A1 (en) | Method and apparatus for coordinating quality of service requirements for media flows in a multimedia session with IP bearer services | |
| US6714515B1 (en) | Policy server and architecture providing radio network resource allocation rules | |
| EP1964421B1 (en) | Mapping of packet flows to bearers in a communication system | |
| EP1834449B1 (en) | Priority bearers in a mobile telecommunication network | |
| EP1382214B1 (en) | Binding information for ip media flows | |
| EP1332627B1 (en) | Method and apparatus for coordinated charging of services in a multimedia session | |
| US20060168303A1 (en) | Method and apparatus for coordinating charging for services provided in a multimedia session | |
| US20020165966A1 (en) | Method and apparatus for coordinating end-to-end quality of service requirements for media flows in a multimedia session | |
| US20080107119A1 (en) | Method and system for guaranteeing QoS between different radio networks | |
| EP1820305B1 (en) | Method and system for implementation of sblp for a wlan-gsm/3g integrated system | |
| WO2002037753A2 (en) | Media binding to coordinate quality of service requirements for media flows in a multimedia session with ip bearer resources | |
| WO2002037869A2 (en) | Method and apparatus for coordinating quality of service requirements for media flows in a multimedia session with ip bearer resources | |
| KR100879164B1 (ko) | 통신 네트워크에서 서비스 품질 관리를 위한 결합 메커니즘 | |
| Zhao et al. | Providing end-to-end quality of service in CDMA2000 networks | |
| Zhuang | End to End Quality of Service in UMTS Systems | |
| Gouveia et al. | Understanding the Issues of Providing IMS Capabilities on Different Access Networks–The Use of Policies for QoS Provision |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20060411 |
|
| RD05 | Notification of revocation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7425 Effective date: 20060629 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080512 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100521 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100617 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130625 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4536990 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |