(57)【要約】【課題】  端末-HA間のパケットがMobile IPv6でカプセル化される場合、PDSNはMobile IPv6トンネル内のIPフローを識別することが出来ない。そのため、EV-DO RANにおいてサービスに適したQoSを適用できない。【解決手段】  PCRFがIPフローを特定するフィルタ情報と、前記IPフローに対して割り当てたFlow LabelをHAに通知する。HAは前記フィルタ情報に合致するパケットの外側IPv6ヘッダに、前記Flow Labelを設定して転送する。PDSNは外側IPv6ヘッダに設定されたFlow Labelを参照することで、Mobile IPv6トンネル内のIPフローを識別する。これにより、Mobile IPv6を使用する場合にもEV-DO RANにおいてサービスに適したQoSを適用可能となる。【選択図】  図1
2008311974.tif 000002
【特許請求の範囲】
【請求項１】
端末、前記端末に対して転送するパケットをカプセル化するサーバ、前記サーバから受信したパケットを前記端末に転送する通信装置、および前記サーバに接続される制御装置を含む通信システムにおいて、
前記通信装置は、
前記端末との間に確立されるチャネルのＱｏＳ情報と該チャネルに対応するIDの情報を備え、
前記制御装置は、
前記通信装置から通知される前記通信装置と前記端末との間に確立されるチャネルのＱｏＳ情報と、受信するフローのＱｏＳ情報とを比較し、前記フローに対して前記チャネルを割り当て、
前記フローを識別するためのフロー識別条件と、前記フローに対して割り当てられた前記チャネルの前記IDを前記サーバに通知し、
前記サーバは、
前記フロー識別条件に一致するパケットを前記端末に転送する際に前記IDを前記パケットのカプセル化後のヘッダ領域に設定し、
前記通信装置は、
前記サーバから受信したパケットを前記端末に転送する際に、受信パケットの前記IDを参照することにより、前記IDに対応するチャネルにパケットを転送することを特徴とする通信システム。
【請求項２】
請求項１に記載の通信システムであって、
前記端末が、通信中に前記通信装置のエリアと異なるエリアに移動した場合に、
前記制御装置は、前記端末と前記移動先の通信装置との間に確立されるチャネルのＱｏＳ情報と受信するフローのＱｏＳ情報を参照し、前記フローにＩＤを割り当て、該割り当てたＩＤとフローのフロー識別条件とを移動先の前記通信装置に通知し、
前記サーバは、一定時間移動元と移動先通信装置にパケットをバイキャストすることを特徴とする通信システム。
【請求項３】
請求項1に記載の通信システムであって、
前記サーバは、
前記端末に転送するパケットをIPv6ヘッダによりカプセル化し、前記IDを前記IPv6ヘッダのFlow Labelフィールド、またはTraffic Classフィールドに設定することを特徴とする通信システム。
【請求項４】
請求項１に記載の通信システムであって、前記QoS情報とは、QoSを適用すべきサービス名、優先度、保証帯域、保証遅延、またはジッタのうち少なくともいずれかひとつ若しくはこれらのうち少なくともいずれか二つの組み合わせに対して割り当てられた識別子であることを特徴とする通信システム。
【請求項５】
端末、前記端末に対して転送するパケットをカプセル化するサーバ、前記サーバから受信したパケットを前記端末に転送する通信装置、および前記サーバに接続される制御装置を含む通信システムにおいて、
前記制御装置は、
受信するフローのＱｏＳ情報に基づいて前記端末と前記通信装置との間に確立されるチャネルに適応すべきＱｏＳを決定し、
該決定したチャネルのＱｏＳの情報と前記チャネルに対応づけられたＩＤを前記通信装置に通知し、
さらに、前記フローの識別条件と前記ＩＤを前記サーバに通知し、
前記サーバは、
前記フロー識別条件に一致するパケットを前記端末に転送する際に前記IDを前記パケットのカプセル化後のヘッダ領域に設定し、
前記通信装置は、
前記サーバから受信したパケットを前記端末に転送する際に、受信パケットの前記IDを参照することにより、前記IDに対応するチャネルにパケットを転送することを特徴とする通信システム。
【請求項６】
ネットワークを介して制御装置と接続され、受信したパケットをカプセル化して通信装置を介して端末に転送するサーバであって、
前記制御装置から、フローを識別するためのフロー識別条件及び
前記通信装置と前記端末との間に確立されたチャネルに対応するＩＤを受信し、
前記フロー識別条件に一致するパケットを前記端末に転送する際に前記IDを前記パケットのカプセル化後のヘッダ領域に設定し、前記端末にパケットを転送することを特徴とするサーバ。
【請求項７】
ネットワークを介してパケットをカプセル化するサーバ及び前記カプセル化されたパケットを前記サーバから受信して端末に転送する通信装置と接続される制御装置であって、
前記通信装置と前記端末の間に確立されたチャネルのＱｏＳ情報と該チャネルに対応するＩＤの情報を備え、
前記サーバにフロー識別条件と該フロー識別条件に一致する場合にヘッダ領域に設定すべき前記ＩＤを通知することを特徴とする制御装置。
【請求項８】
ネットワークを介して制御装置に接続され、サーバから送信されるカプセル化された端末宛のパケットを転送する通信装置であって、
前記端末との間に確立されるチャネルのＱｏＳ情報と該チャネルに対応するIDの情報を備え、
前記サーバから受信したパケットを前記端末に転送する際に、前記サーバにおいて受信パケットが前記制御装置から通知されるフロー識別条件に一致する場合に前記パケットのカプセル化後のヘッダ領域に設定される前記IDを参照することにより、前記IDに対応するチャネルにパケットを転送することを特徴とする通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス制御と連動してアクセス網のQoS制御を行う通信システムに関する。中でも、Mobile IPv6を使用して移動通信制御を行う移動通信システムに関する。
【背景技術】
【０００２】
Mobile IPv6は、ネットワークを移動しても同一IPアドレスを使用して通信可能とするためのプロトコルである(非特許文献1参照)。Mobile IPv6の網構成要素には、複数のネットワークを移動しながら通信を行うMN (Mobile Node)、MNの位置情報を管理するHA (Home Agent)、MNと通信を行うCN (Correspondent Node)がある。MNは、移動しても変わらないIPアドレス(HoA: Home Address)と、移動先のネットワークで動的に割り当てられるIPアドレス(CoA: Care of Address)の対応付け(Binding情報)を定期的にHAに登録する。HAは、CNがHoA宛てに送信したIPパケットを捕捉し、自身のアドレスを送信元アドレス、MNのCoAを宛先アドレスに設定したIPv6ヘッダでカプセル化してMNに転送する。MNは、HAから受信したパケットのカプセル化されていた中身を取り出して処理する。一方、MNからCN宛てのパケットは、MNが自身を送信元アドレス、HAを宛先アドレスに設定したIPv6ヘッダでカプセル化してHAに転送する。HAは、受信したパケットのカプセル化されていた中身を取り出してCNに転送する。以上により、ネットワークを移動した際にも同一IPアドレスを使用した通信が可能となる。
【０００３】
Mobile IPv6を使用する通信システムの例として、3GPP2(3rd Generation Partnership Project2)により標準化されている第3世代(3G)移動体通信システムがある。
【０００４】
3G移動体通信システムは、無線アクセスネットワーク(RAN: Radio Access Network)とコアネットワーク(Core Network)から構成される。RANは、無線伝送機能を終端、制御する機能を備える。コアネットワークは、移動制御とサービス制御の機能を備える。コアネットワークには、MNとPPPで接続しIP接続機能を提供するアクセスゲートウェイ(PDSN: Packet Data Serving Node)とHAが設置され、Mobile IPに基づくIP通信機能を提供する。
【０００５】
一方、3GPP2では、コアネットワークに接続されるサービス制御網をMMD (Multimedia Domain)として規格化している(非特許文献2〜3)。MMDでは、電話やIM(Instant Messaging)サービスの制御プロトコルとしてSIP (Session Initiation Protocol) / SDP(Session Description Protocol)を使用する。
【０００６】
さらに3GPP2では、サービスに適したQoS制御を行うために、MMDのサービス制御とRANのQoS制御の連携方式(SBBC: Service Based Bearer Control)を規定している(非特許文献4〜6)。SBBCでは、MMDのサービス制御サーバ(AS: Application Server)とアクセス網の間にQoSポリシーサーバ(PCRF: Policy and Charging Rules Function)が設置される。ASは、SIP/SDP等のサービス制御プロトコルを処理する際に取得したサービス情報(通信アドレス、ポート番号、コーデック、帯域等)を、PCRFに対して通知する。PCRFは、ASから通知されたサービス情報に基づいて適用すべきQoSを決定し、PDSNを介してRANに通知する。
【０００７】
RANは、PCRFが決定したQoSパラメータに基づいて、各アプリケーションに適したQoS制御を行う(非特許文献7)。例えば、リアルタイム性が要求される音声トラフィックは、一定の帯域が保証された、遅延やジッタの小さい通信チャネル上で伝送する。一方、IMやWebサービスは、ベストエフォートの通信チャネル上で伝送する。
【０００８】
RANにおいて、各アプリケーションに属するIPフローはTFT (Traffic Flow Template)と呼ばれるフィルタ情報(送信元/宛先 IPアドレス、ポート番号等）を用いて特定される。MNとPDSNは、IPフローを適切な通信チャネルに転送するために、TFT と通信チャネルの対応付けを管理する。端末は、TFTに一致する上り(Reverse)方向のパケットを、そのTFTと対応付けられた通信チャネルに転送する。PDSNは、下り(Forward)方向のパケットに対して同様の処理を行う。
【０００９】
【非特許文献１】IETF RFC3775、 Mobility Support in IPv6
【非特許文献２】3GPP2 X.P0013-002-B v0.3、All-IP Core Network Multimedia Domain; IP Multimedia Subsystem  Stage2
【非特許文献３】3GPP2 X.P0013-004-B v0.06、All-IP Core Network Multimedia Domain; IP Multimedia Call Control Protocol Based on SIP and SDP Stage3
【非特許文献４】3GPP2 X.P0013-012-0 v0.21、All-IP Core Network Multimedia Domain; Service Based Bearer Control - Stage2
【非特許文献５】3GPP2 X.P0013-013-0 v0.11、All-IP Core Network Multimedia Domain; Service Based Bearer Control  Tx Interface Stage3
【非特許文献６】3GPP2 X.P0013-014-0 v0.11、All-IP Core Network Multimedia Domain; Service Based Bearer Control  Ty Interface Stage3
【非特許文献７】3GPP2 X.P0011-004-D v1.0、cdma2000 Wireless IP Network Standard: Quality of Service and Header Reduction
【発明の開示】
【発明が解決しようとする課題】
【００１０】
以上で説明したように、従来の通信システムでは、MNとPDSNがTFTを用いてIPフローを識別し、RANにおいて適切なQoSを適用する。これは、端末がSimple IPまたはMobile IPv4を使用する場合には問題なく動作する。
【００１１】
しかし、端末がMobile IPv6を使用する場合は、端末-HA間のパケットが全て共通のIPv6ヘッダによりカプセル化されるため、PDSNは下りパケットのIPフローを識別することが出来ない。そのため、RANにおいて下り方向のパケットに適切なQoSを適用できないという課題がある。
【００１２】
本発明の目的は、Mobile IPv6によりパケットがカプセル化される場合にも、PDSNが下り方向のIPフローを識別し、RANにおいてサービス種別に適したQoSを適用することにある。
【課題を解決するための手段】
【００１３】
上記の問題を解決するために、本発明では、PCRFがサービスに属するIPフローを特定するためのフィルタ情報と、前記IPフローに対して割り当てたIDをHAに通知し、HAは前記フィルタ情報に合致するパケットを転送する際に、前記IDをカプセル化後の外側ヘッダに設定し、PDSNは外側ヘッダに設定された前記IDを参照することにより、サービス種別を識別して適切なQoSを適用することを特徴とする。
【発明の効果】
【００１４】
本発明により、Mobile IPv6を使用する場合にも、PDSNで下り方向のIPフローを識別し、RANにおいてサービス種別に適したQoSを適用することが可能となる。
【発明を実施するための最良の形態】
【００１５】
本発明の好ましい例においては、HAは前記IDを外側IPv6ヘッダのFlow LabelあるいはTraffic Classフィールドに設定する。この場合、TFTには、送信元IPアドレスとしてHAが、宛先IPアドレスとしてMNのCoAが、Flow LabelまたはTraffic Classとして前記IDが設定される。あるいは、HAは前記IDをIPsec ESP/AHヘッダのSPIフィールドに設定してもよい。この場合、TFTには、送信元IPアドレスとしてHAが、宛先IPアドレスとしてMNのCoAが、SPIとして前記IDが設定される。
【００１６】
RANの通信チャネルの設定が端末主導で行われる通信システムにおいては、PCRFは通信チャネルのQoS情報と、前記IDをPDSNから受信し、IPフローに適した通信チャネルを前記QoS情報に基づいて選択し、選択した通信チャネルのIDを、前記IPフローに対して割り当ててHAに通知してもよい
RANの通信チャネルの設定がネットワーク主導で行われる通信システムにおいては、PCRFはSIPサーバ等のAF（Application Function）から通知されたサービス情報に基づいてIPフローに割り当てるQoSとIDを決定し、PDSNとHAに通知してもよい。この場合、PDSNはPCRFから通知される前記QoS情報と前記IDに基づいてRANの通信チャネルおよびTFTの設定を行う。
以下、本発明の実施例を、図面を用いて説明する。
【実施例１】
【００１７】
本発明の第1の実施例は、RANの通信チャネルの設定を、端末主導で行うことを想定する。
【００１８】
図1は、本発明における通信システムの構成例である。本発明の通信システムは、Home Network1、Visited Network2から構成される。Home Network1には、サービス制御を行うAF 11、サービス情報に基づいてRANのQoS制御を行うPCRF12、Mobile IPv6の通信制御を行うHA13、およびCN14が接続される。Visited Network2には、PDSN(21a、21b)、EV-DO RAN(22a、22b)、MN23が接続される。
【００１９】
図2(a)は、PCRF12の装置構成を示す。PCRF12は、Hard Disk51、CPU52、Memory53、IF(54a、54b)から構成され、これらはバス55を介して接続されている。PCRF12の機能を実現するためのプログラムはMemory 53に格納されており、CPU52が順次それを読み出して実行する。
【００２０】
PCRF12は、Memory 53またはHard Disk51において、図3のService Table70、図4のPPP Session Table80、図5のMobile IP Table90、図6のEncapsulation Rule Table100、図7(a)のDecapsulation Rule Table110を管理する。
【００２１】
図3のService Table70は、AF11から通知されるサービス情報を管理するテーブルである。Service Table70は、AFおよびサービスセッションを識別するID(Service Session ID71)と、サービスセッションに属するフロー情報(Flow Information72)から構成される。Flow Information72は、PCRF12内でフローを一意に識別するフローID(Flow ID72a)、フローを特定するためのフィルタ情報(Flow Filter72b)、フローの方向性(Direction72c)、フロータイプ(Type72d)、フローの帯域(Bandwidth72e)、コーデック情報(CODEC72f)等から構成される。フィルタ情報(Flow Filter72bには、例えば送信元、宛先アドレスや、ポート番号等が設定される。Service Table70の設定例(70a、70b、70c)は、同一のサービスセッションに属する双方向のaudioフローと、out(Reverse)方向のvideoフローの情報を示す。このように、Service Table70では一つのサービスセッションに対して複数のフロー情報を設定することも可能である。このようなテーブル構成とすることで、1つのサービスセッション内で複数のフローを通信する場合にも柔軟に対応できる効果がある。
【００２２】
図4のPPP Session Table80は、PDSN(21a、21b)から通知されるPPPセッション情報を管理するテーブルである。PPP Session Table80は、PDSNおよびPPPセッションを一意に識別するID(PPP Session ID81)、端末IPアドレス(Terminal IP Address82)、ベアラ情報(Bearer Information83)から構成される。本実施例において「ベアラ」とは、特定のQoS属性を備えるRAN(22a、22b)の通信チャネルを意味する。背景技術の説明で述べたように、PDSN(21a、21b)は、RANの通信チャネル(すなわちベアラ)とTFTの対応付けを管理する。本実施例では、PDSN(21a、21b)がMobile IPv6トンネル内のIPフローを適切なベアラに振り分け可能とするために、TFTの中にベアラ毎に異なるFlow Labelを設定する。PCRF12は、PPP Session Table80を備えることで、Flow LabelとベアラのQoS属性の対応付けを管理できる効果がある。なお、Flow LabelはIPv6ヘッダのTraffic Classフィールド、IPsec ESP/AHヘッダのSPI等で代用することもできる。
【００２３】
Bearer Information83は、PCRF12内でベアラを一意に識別するID (Bearer ID83a)、ベアラの用途(Usage83b)、優先度(Priority83c)、保証帯域(Bandwidth83ｄ)、ベアラに割り当てられたFlow Label(Flow Label83e)、ベアラの状態(Status83f)から構成される。Bearer Table80の設定例(80a〜80d)は、同一のPPP Sessionに属するベアラの情報を示す。このように、Bearer Table80では1つのPPP Sessionに対して複数のベアラ情報を設定することも可能である。このようなテーブル構成とすることで、1つのPPP Sessionに対して複数のベアラが設定される場合にも柔軟に対応できる効果がある。
【００２４】
図5のMobile IP Table90は、HA13からPCRF12に対して通知されるHoAとCoAのBinding情報を管理するテーブルである。Mobile IP Table90は、HAとBinding情報を一意に識別するID(Mobile ID91)、Home Address (HoA92)、Care of Address (CoA93)、有効期限(Expires94)から構成される。 
図6のEncapsulation Rule Table100は、HA13がパケットをカプセル化する際に適用するルール(Encapsulation Rule)を管理するテーブルである。Encapsulation Ruleは、PCRF12が生成し、HA13に設定する。Encapsulation Rule Table100は、ルールに関連する情報へのポインタ(Source101)と、カプセル化ルール(Encapsulation Rule102)から構成される。Source101の(101a、101b、101c、101d)には、ルールに関係するFlow ID72a、Mobile ID91、PPP Session ID81、Bearer ID83aがそれぞれ設定される。Encapsulation Rule102には、フローを識別するためのフィルタ情報(Flow Filter 102a)、パケットカプセル化時に設定するCare of Address (CoA102b)およびFlow Label (Flow Lable102c)、ルールの有効期限(Expires102d)が設定される。
【００２５】
図7(a)のDecapsulation Rule Table110は、HA13がパケットをデカプセル化する際に適用するルール(Decapsulation Rule)を管理するテーブルである。Decapsulation Ruleは、PCRF12が生成し、HA13に設定する。Decapsulation Rule Table110は、ルールに関連する情報へのポインタ(Source111)と、デカプセル化ルール(Decapsulation Rule112)から構成される。Source111の111a、111b、111cには、ルールに関連するFlow ID72a、Mobile ID91、PPP Session ID81がそれぞれ設定される。Decapsulation Rule112には、フローを識別するためのフィルタ情報(Flow Filter 112a)、デカプセル化後に設定すべきTraffic Class(Traffic Class112b)、ルールの有効期限(Expires112c)が設定される。
【００２６】
図2(b)は、HA13の装置構成を示す。HA13は、Hard Disk61、CPU62、Memory63、IF(64a、64b)から構成され、これらはバス65を介して接続されている。HA13の機能を実現するためのプログラムはMemory 63に格納されており、CPU62が順次それを読み出して実行する。
【００２７】
HA13は、Memory 63またはHard Disk61において、図8のMobile IP Table130、図9(a)のEncapsulation Rule Table140、図9(b)のDecapsulation Rule Table150を管理する。
【００２８】
図8のMobile IP Table130は、MN23がHA13に登録するHoAとCoAのBinding情報を管理するテーブルである。Mobile IP Table130は、Binding情報を識別するID(Mobile ID131)、Home Address (HoA132)、Care of Address (CoA133)、有効期限(Expires134)、関連するEncapsulation Ruleへのポインタ(Encap. Rule IDs135)、関連するDecapsulation Ruleへのポインタ(Decap. Rule IDs136)から構成される。ポインタEncap.Rule IDs135とDecap. Rule IDs136を保持することで、Encapsulation RuleとDecapsulation Ruleの検索を高速化できる効果がある。
【００２９】
図9(a)のEncapsulation Rule Table140は、HA13がPCRF12から通知されたEncapsulation Ruleを管理するテーブルである。Encapsulation Rule Table140は、ルールを識別するID(Encap. Rule ID141)、フローを識別するためのフィルタ情報(Flow Filter 142)、カプセル化時に設定するCare of Address (CoA143)およびFlow Label (Flow Lable144)、ルールの有効期限(Expires145)が設定される。
【００３０】
図9(b)のDecapsulation Rule Table150は、HA13がPCRF12から通知されたDecapsulation Ruleを管理するテーブルである。Decapsulation Rule Table150は、ルールを識別するID(Decap. Rule ID151)、フローを識別するためのフィルタ情報(Flow Filter 152)、デカプセル化後に設定すべきTraffic Class(Traffic Class153)、ルールの有効期限(Expires154)が設定される。
【００３１】
図23は、PDSN(21a、21b)の装置構成を示す。PDSN(21a、21b)は、Hard Disk401、CPU402、Memory403、IF(404a、404b)、から構成され、これらはバス405を介して接続されている。PDSN(21a、21b)の機能を実施するためのプログラムはMemory403に格納されており、CPU402が順次それを読み出して実行する。
【００３２】
図24は、PDSN(21a、21b)のMemory403またはHard Disk401に格納されるPPP Session Table420を示す。PPP Session Table420は、PDSN(21a、21b)内でPPPセッションを一意に識別するID(PPP Session ID421)、端末IPアドレス(Terminal IP Address422)、ベアラ情報(Bearer Information423)から構成される。Bearer Information423は、ベアラの用途(Usage423a)、優先度(Priority423b)、保証帯域(Bandwidth423c)、フィルタ情報(TFT423d)、ベアラの状態(Status423e)から構成される。
【００３３】
PPP Session Table420の設定例(420a〜402d)に示すように、本実施例では、フィルタ情報(TFT423d)として送信元IPアドレス、宛先IPアドレス、Flow Labelが設定される。PDSN(21a、21b)は、PPP Session Table420を管理することで、ベアラとフィルタ情報の対応付けを管理できる効果がある。
【００３４】
図10は、MN23がEV-DO RAN22aに接続した後、サービスセッションを確立するシーケンスを示す。以下、このシーケンスの詳細を説明する。
【００３５】
ステップ201〜209は、MN23がEV-DO RAN22aに接続した際に実施されるシーケンスを示す。最初に、MN23はEV-DO RAN22aに接続し、PDSN21aに対してPPP Sessionの確立、およびベアラとTFTの設定を行う(201)。このステップの中で、PDSN21aのPPP Session Table420が設定される。本実施例では、TFT423dの送信元アドレスにHA13のIPアドレスが、宛先アドレスにMN23のCoAが設定される。また、TFT423dのFlow Labelはベアラ毎に異なる値が設定される。
【００３６】
次に、PDSN21aは、PCRF12に対してDiameter CCR(202)を送信し、端末に割り当てたIPアドレス(すなわちCoA)と、端末が確立したベアラ情報を通知する。ここで通知されるベアラ情報には、少なくともベアラ毎に割り当てられたFlow Labelの値とベアラのQoS情報を含む。好ましい例では、ベアラのQoS情報として、ベアラの用途を示す文字列、優先度、保証帯域、ベアラ状態等が指定される。PCRF12は、通知された情報をPPP Session Table80に記憶する(203)。PCRF12は、Diameter CCA(204)でPDSN21aに返信する。
【００３７】
次に、MN23はHA13に対してHoAとCoAのBinding情報を登録する(205)。HA13は、この情報をMobile IP Table130に記憶すると共に、Diameter CCR(207)を送信してPCRF12にBinding情報を通知する。PCRF12は、HA13から通知されたBinding情報をMobile IP Table90に記憶し(208)、HA13にDiameter CCA(209)を返信する。
【００３８】
ステップ210〜217は、サービスセッション確立時のシーケンスを示す。まず、MN23はAF11を介してCN14とサービスセッションを確立する(210)。AF11は、サービス制御信号(SIP/SDP等)から抽出したサービス情報をPCRF12に対して通知する(211)。PCRF12は、通知された情報をService Table70に記憶し(212)、このサービス情報に対応するカプセル化/デカプセル化ルールを生成する(213)。以下、図11と図12を用いて、PCRF12のカプセル化/デカプセル化ルール生成処理(213)を詳しく説明する。
【００３９】
図11は、PCRF12のカプセル化ルール生成処理を示す。カプセル化ルール生成処理では、図10のステップ212でService Table70に記憶したフローに関して、ループ501〜511の処理を行う。まず、フローの方向(Direction72c)がinであるかどうかをチェックする(502)。inで無い場合はそのフローに対する処理を終了する。inである場合は、フローのFlow ID72aとFlow Filter72bをEncapsulation Rule Table100の101a、102aに設定する(503)。また、Flow Filter72bから宛先IPアドレスを抽出する(504)。さらに、抽出したIPアドレスを、Mobile IP Table90のHoA92から検索する(505)。該当するエントリが存在しない場合は、そのフローに対する処理を終了する。該当するエントリが存在する場合は、そのMobile ID91とCoA93をEncapsulation Rule Table100の101b、102bに設定する(506)。次に、PPP Session Table80のTerminal IP Address82から505で検索したエントリのCoA93を検索する(507)。該当するエントリが存在しない場合は、そのフローに対する処理を終了する。該当するエントリが存在する場合は、そのエントリのPPP Session ID81をEncapsulation Rule Table100の101cに設定する(508)。また、507で検索したエントリのBearerの中からフローに対して適切なものを選択する(509)。Bearerを選択する際には、例えばフローのType72d、Bandwidth72e、Codec72f等をBearerのUsage83b、Priority83c、Bandwidth83d等と比較してもよい。そして、509で選択したBearerのBearer ID83a、Flow Label83eをEncapsulation Rule Table100の101d、102cに設定する(510)。PCRF12は、Encapsulation Rule Table100を保持することで、各フローに対して適切なFlow Label(すなわち適切なQoS属性を備えるベアラ)を割り当てることが可能となる。また、PPPセッション、モバイルIPセッションとIPフローの対応付けを管理することが可能になる。
【００４０】
図12は、PCRF12のデカプセル化ルール生成処理を示す。デカプセル化ルール生成処理では、図10のステップ212でService Table70に記憶したフローに関して、ループ521〜530の処理を行う。まず、フローの方向(Direction72c)がoutであるかどうかをチェックする(522)。outで無い場合はそのフローに対する処理を終了する。outである場合は、フローのFlow ID72aとFlow Filter72bをDecapsulation Rule Table110の111a、112aに設定する(523)。また、Flow Filter72bから送信元IPアドレスを抽出する(524)。さらに、抽出したIPアドレスを、Mobile IP Table90のHoA92から検索する(525)。該当するエントリが存在しない場合は、そのフローに対する処理を終了する。該当するエントリが存在する場合は、そのMobile ID91をDecapsulation Rule Table110の111bに設定する(526)。そして、PPP Session Table80のTerminal IP Address82から525で検索したエントリのCoA93を検索する(527)。該当するエントリが存在しない場合は、そのフローに対する処理を終了する。該当するエントリが存在する場合は、527で検索したエントリのPPP Session ID81をDecapsulation Rule Table110の111cに設定する(528)。そして、デカプセル化したパケットに設定すべきTraffic Classを決定し、Decapsulation Rule Table110 の112bに設定する(529)。PCRF12は、図7bに示すFlow TypeとTraffic Classのマッピングテーブルを管理し、Traffic Classを決定する際に参照してもよい。PCRF12は、Decapsulation Rule Table110を保持することで、Home Network1内のQoS制御に使用するTraffic Classを各フローに対して割り当てることができる。また、PPPセッション、モバイルIPセッションとIPフローの対応付けを管理することが可能になる。
【００４１】
図10に戻り、シーケンスの説明を続ける。PCRF12はHA13にDiameter RAR(214)を送信し、ステップ213で生成したカプセル化/デカプセル化ルールをMobile ID(101b、111b)と対応付けて通知する。HA13は、通知されたルールをEncapsulation Rule Table140、Decapsulation Rule Table150、Mobile IP Table130に記憶し(215)、Diameter RAA(216)でPCRF12に応答する。PCRF12はAF11に対してDiameter AAA(217)を送信し、Diameter AAR(211)に応答する。以上で、サービスセッション確立時の処理が完了する。
【００４２】
図13を用いて、MN23-CN14間のパケット送受信処理を説明する。ステップ231〜235は、CN14からMN23に対するパケット送信処理を示す。CN14は、宛先アドレスにMN23のHoAを、送信元アドレスに自身のアドレスを設定したパケットを送信する(231)。HA13は、231のパケットを捕捉し、IPv6ヘッダでカプセル化する(232)。カプセル化後の送信元アドレスには自身(HA)を設定する。また、宛先アドレス(MN23のCoA)とFlow LabelはEncapsulation Rule Table140を参照して設定する。そして、カプセル化したパケットをPDSN21aに転送する(233)。PDSN21aは、PPP Session Table420のフィルタ情報(TFT423d)と、パケットのヘッダ領域に含まれるFlow Label、宛先/送信元IPアドレスを比較することにより、使用するベアラを決定し(234)、MN23にパケットを転送する(235)。
【００４３】
図14を用いて、HA13のパケットカプセル化処理(232)を詳しく説明する。HA13はまずパケットの宛先IPアドレスを抽出する(541)。そしてMobile IP Table 130のHoA132からステップ541で抽出したIPアドレスを検索する(542)。該当するエントリが存在しない場合は処理を終了する。該当するエントリが存在する場合は、ステップ542で検索したエントリのEncap. Rule IDs135が指し示すEncapsulation Rule Table140のエントリに関して、ループ543〜547の処理を行う。まず、パケットがFlow Filter142に一致するかどうかをチェックする(544)。一致するか否かの判定は、パケットのヘッダ領域に含まれる送信元/宛先アドレス、ポート番号と、Flow Filter142の条件を比較することにより行う。一致しない場合は、そのEncapsulation Ruleに対する処理を終了する。一致する場合は、パケットをIPv6ヘッダでカプセル化し、宛先アドレスをCoA143に、送信元アドレスをHA13に、Flow LabelをFlow Label144に設定する(545)。そして、カプセル化したパケットをCoA143宛に送信する(546)。なお、ループ543〜547において、パケットに一致するFlow Filter142が一つも存在しない場合、HA13はカプセル化後の宛先アドレスをステップ542で検索したエントリのCoA133に、送信元アドレスをHA13に、Flow Labelを予め設定されたデフォルト値(例えば0)にして転送してもよい。あるいは、パケットを転送せずに破棄してもよい。
【００４４】
図13に戻り、MN23からCN14に対するパケット送信処理(ステップ236〜238)を説明する。MN23は、CN14宛てのパケットをカプセル化して送信する(236)。このとき、カプセル化前の宛先アドレスにはCN14が、送信元アドレスにはMN23のHoAアドレスが設定される。また、カプセル化後の宛先アドレスにはHA13が、送信元アドレスにはMN23のCoAアドレスが設定される。パケット236は、PDSN21aを経由してHA13に到達する。HA13は、パケット236を受信すると、外側のIPv6ヘッダを取り除く。また、Decapsulation Rule Table150を参照してTraffic Classを設定し(237)、パケットをCN14に転送する(238)。
【００４５】
図15を用いて、HA13におけるパケットデカプセル化後のTraffic Class設定処理(237)を詳しく説明する。HA13はまずパケットの送信元IPアドレスを抽出する(561)。そしてMobile IP Table 130のHoA132からステップ561で抽出したIPアドレスを検索する(562)。該当するエントリが存在しない場合は処理を終了する。該当するエントリが存在する場合は、ステップ562で検索したエントリのDecap. Rule IDs136が指し示すDecapsulation Rule Table150のエントリに関して、ループ563〜567の処理を行う。まず、パケットがFlow Filter152に一致するかどうかをチェックする(564)。一致しない場合は、そのDecapsulation Ruleに対する処理を終了する。一致する場合は、パケットのTraffic ClassをTraffic Class153に設定し(565)、パケットを送信して(567)、ループ563〜567を終了する。
【００４６】
次に、図16を用いてサービスセッション終了時の処理を説明する。まず、MN23はAF11を介してCN14とのサービスセッションを終了する(251)。AF11は、PCRF12に対してDiameter STR(252)を送信し、サービスセッションの終了を通知する。PCRF12は、HA13に対してDiameter RAR(253)を送信し、サービスに関連するカプセル化ルール/デカプセル化ルールを削除する。HA13は、Encapsulation Rule Table140、Decapsulation Rule Table150、Mobile IP Table130から該当するルールを削除し(254)、PCRF12にDiameter RAA(255)を返信する。PCRF12はService Table70、Encapsulation Rule Table100、Decapsulation Rule Table110から関連する情報を削除し(256)、AF11にDiameter STA(257)で応答する。以上の手順を実施することにより、サービスセッション終了時にPCRF12、HA13から関連するエントリを削除することができる。
【００４７】
図17は、MN23-CN14間でパケット通信中に、MN23の無線リンクが消失した際のシーケンスを示す。最初、MN23とCN14は、PDSN21a、HA13経由で通信中の状態にある(271)が、MN23が圏外に移動し、無線リンクが消失する(272)。MN23の無線リンク消失を検知したPDSN21aは、PPP Session Table420のStatus423eをinactiveに設定し、PCRF12に対してDiameter CCR(273)を送信する。PCRF12は、PPP Session Table80 のStatus83fをinactiveに設定し(274)、Diameter CCA(275)で応答する。またPCRF12は、274でinactiveに設定したPPP Sessionを使用するサービスを、Encapsulation Rule Table100とDecapsulation Rule Table110から検索する(276)。そして、AF11に対してDiameter RAR(277)を送信し、サービスの無線リンク消失を通知する。AF11は、Diameter RAA(278)を返信し、該当するサービスセッションを切断する(279)。以降の処理は、図16のステップ252〜257と同じである。以上の手順を実施することにより、無線リンク消失時にAF11、PCRF12、HA13、CN14内のリソースを即座に開放できる効果がある。
【００４８】
図18は、MN23-CN14間でパケット通信中に、MN23がPDSN21aからPDSN21bに移動した際の処理を示す。最初、MN23とCN14は、PDSN21a、HA13経由で通信中の状態にある(291)。MN23はEV-DO RAN22bの無線リンクを検知し、PDSN21bに対してPPP Sessionの確立、およびベアラとTFTの設定を行う(292)。このステップにおいて、PDSN21b内のPPP Session Table420が設定される。次に、PDSN21bは、PCRF12に対してDiameter CCR(293)を送信し、端末に割り当てたIPアドレス(CoA)と、端末が確立したベアラ情報を通知する。PCRF12は、通知された情報をPPP Session Table80に記憶し(294)、Diameter CCA(295)でPDSN21bに返信する。
【００４９】
次に、MN23はHA13に対してHoAとCoAのBinding情報を登録する(296)。HA13は、Mobile IP Table130の情報を更新すると共に(297)、Diameter CCR(298)を送信してPCRF12に通知する。PCRF12は、Mobile IP Table90を更新し(299)、HA13にDiameter CCA(230)を返信する。PCRF12は、Mobile IP Table90が更新されたことを契機に、カプセル化ルールとデカプセル化ルールの再計算を行う(301)。
【００５０】
図19を用いて、PCRF12のカプセル化ルール再計算処理を詳しく説明する。最初に、ステップ299で更新したエントリのMobile ID91を、Encapsulation Rule Table100の101bから検索する(581)。581で検索したエントリに関して、ループ582〜586の処理を実行する。まず、エントリのコピーを作成し、Encapsulation Rule Table100に追加する(583)。次に、583のコピー元のエントリの有効期限(Expires102d)を一定値(例えば10秒)まで減少させる(584)。そして、図11の506〜510を実施し、検索/決定した値を583のコピー先のエントリに設定する(585)。以上でカプセル化ルールの再計算処理を説明したが、デカプセル化ルールに関しても、同様の手順で再計算を行う。なお、ステップ584に示すように、旧エントリを一定期間保持することで、HA13が一時的に新旧ネットワークにパケットをバイキャストすることになる。これは、MN23がネットワーク移動時に途切れることなくパケットを送受信するために必要な処理である。
【００５１】
図18に戻りシーケンスの説明を続ける。PCRF12は、HA13に対してDiameter RAR(302)を送信し、ステップ301で再計算したルールを設定する。HA13は、通知されたルールをEncapsulation Rule Table140、Decapsulation Rule Table150、Mobile IP Table130に設定し(303)、Diameter RAA(304)でPCRF12に応答する。
【実施例２】
【００５２】
本発明の第2の実施例は、RANの通信チャネルの設定を、ネットワーク主導(すなわちPCRF12主導)で行うことを想定する。
【００５３】
実施例2のネットワーク構成は、実施例1と同じである。装置構成は、PCRF12が図25のQoS Profile Table440を備える点を除き、実施例1と同じである。
【００５４】
図25のQoS Profile Table440は、各端末が在圏網において使用可能なQoS Profileを管理するテーブルである。PCRF12は、このテーブルを備えることにより、サービス開始時に、ネットワーク条件に適したQoSパラメータ決定することが可能になる。QoS Profile Table440は、PDSNおよびPPPセッションを一意に識別するID(PPP Session ID441)、端末IPアドレス(Terminal IP Address442)、ベアラ情報(Bearer Information443)から構成される。ベアラ情報(Bearer Information443)は、ベアラの用途(Usage443a)、優先度(Priority443b)、保証帯域(Bandwidth443c)、から構成される。
【００５５】
図20と図21を用いて、実施例2における端末接続/サービスセッション確立シーケンスを説明する。ステップ321〜329は、MN23がEV-DO RAN22aに接続した際に実施されるシーケンスを示す。最初に、MN23はEV-DO RAN22aに接続し、PDSN21aに対してPPP Sessionを確立する(321)。実施例2では、この時点でメディア(音声/映像)通信用ベアラの設定を行わない。そのため、PDSN21aのPPP Session Table420には、PPP Session ID421とTerminal IP Address422のみが設定される。
【００５６】
次に、PDSN21aは、PCRF12に対してDiameter CCR(322)を送信し、端末に割り当てたIPアドレス(CoA)と、MN23がVisited Network2において使用可能なベアラのQoS Profileを通知する。PCRF12は、通知された情報をPPP Session Table80とQoS Profile Table440に記憶し(323)、PDSN21aにDiameter CCA(324)を返信する。
【００５７】
次に、MN23はHA13に対してHoAとCoAのBinding情報を登録する(325)。HA13は、この情報をMobile IP Table130に記憶する(326)と共に、PCRF12にDiameter CCR(327)を送信する。PCRF12は、HA13から通知された情報をMobile IP Table90に記憶し(328)、HA13にDiameter CCA(329)を返信する。
【００５８】
ステップ330〜340は、サービスセッション確立時のシーケンスを示す。まず、MN23はAF11を介してCN14とサービスセッションを確立する(330)。AF11は、サービス制御信号(SIP/SDP等)から抽出したサービス情報をPCRF12に対して通知する(331)。PCRF12は、通知された情報をService Table70に記憶し(332)、サービスで使用するベアラ情報(すなわち、QoSパラメータとTFT)の選択/生成と、カプセル化/デカプセル化ルールの生成を行う(333)。ベアラ情報は、ステップ323でQoS Profile Table440に記憶したQoS Profileの中から選択してもよいし、PCRF12がサービス情報に基づいて新たにパラメータを決定してもよい。サービスで使用するベアラをQoS Profile Table440から選択する場合は、PCRF12におけるパラメータ決定処理の一部を省略できる効果がある。一方、PCRF12がサービス情報に基づいて新たにパラメータを決定する場合は、Visited Network2において予め想定されていないサービスに対しても柔軟に対応できる効果がある。カプセル化ルール、デカプセル化ルールの生成方法は、実施例1で説明した図11、図12と同じである。
【００５９】
次に、PCRF12はPDSN21aに対してDiameter RAR(334)を送信し、ステップ333で選択/決定したベアラ情報を通知する。PDSN21aは、通知された情報をPPP Session Table420に設定し、ベアラを確立した後(335)、Diameter RAR(336)でPCRF12に応答する。以上の手順を実施することにより、サービスセッション確立時にサービスに適したベアラ情報を動的に設定できる効果がある。
【００６０】
次に、図21に進みシーケンスの説明を続ける。PCRF12は、HA13に対してDiameter RAR(337)を送信し、ステップ333で生成したカプセル化/デカプセル化ルールを設定する。HA13は、ルールをEncapsulation Table140、Decapsulation Table150、Mobile IP Table130に記憶し(338)、Diameter RAA(339)でPCRF12に応答する。PCRF12は、AF11にDiameter AAA(340)を送信し、ステップ331のDiameter AARに応答する。 
図22は、実施例2におけるサービスセッション終了時の処理を示す。まず、MN23はAF11を介してCN14とのサービスセッションを終了する(361)。AF11は、PCRF12に対してDiameter STR(362)を送信し、サービスセッションの終了を通知する。PCRF12は、HA13に対してDiameter RAR(363)を送信し、サービスに関連するカプセル化ルール/デカプセル化ルールを削除する。HA13は、Encapsulation Rule Table140、Decapsulation Rule Table150、Mobile IP Table130から該当するルールを削除し(364)、PCRF12にDiameter RAA(365)を返信する。PCRF12は、続いてPDSN21aにDiameter RAR(366)を送信し、ベアラの削除を要求する。PDSN21aはベアラを削除し(367)、PPP Session Table420から該当するベアラ情報を削除した後、Diameter RAA(368)でPCRF12に応答する。PCRF12は、Service Table70、PPP Session Table80、Encapsulation Rule Table100、Decapsulation Rule Table110から関連する情報を削除し(369)、AF11にDiameter STA(370)で応答する。以上の手順を実施することにより、サービスセッション終了時にベアラを解放し、かつPCRF12、HA13、PDSN21aから関連するエントリを削除できる効果がある。
【００６１】
実施例2では、サービスセッション確立時に動的にベアラを設定することにより、QoSパラメータやTFTを予め決定できない場合にも柔軟に適用できる効果がある。
【図面の簡単な説明】
【００６２】
【図１】実施例(1、2)における通信網の構成例。
【図２ａ】PCRF12の装置構成例。
【図２ｂ】HA13の装置構成。
【図３】PCRF12が備えるService Tableの構成例。
【図４】PCRF12が備えるPPP Session Tableの構成例。
【図５】PCRF12が備えるMobile IP Tableの構成例。
【図６】PCRF12が備えるEncapsulation Rule Tableの構成例。
【図７ａ】PCRF12が備えるDecapsulation Rule Tableの構成例。
【図７ｂ】PCRF12が備えるFlow Type-Traffic Class Mapping Tableの構成例。
【図８】HA13が備えるMobile IP Tableの構成例。
【図９ａ】HA13が備えるEncapsulation Rule Tableの構成例。
【図９ｂ】HA13が備えるDecapsulation Rule Tableの構成例。
【図１０】実施例１における端末接続/サービスセッション確立シーケンス図。
【図１１】PCRF12のカプセル化ルール生成ルーチン図。
【図１２】PCRF12のデカプセル化ルール生成ルーチン図。
【図１３】実施例１におけるMN23-CN14間のパケット転送シーケンス図。
【図１４】HA13におけるパケットカプセル化ルーチン図。
【図１５】HA13におけるパケットデカプセル化後のTraffic Class設定ルーチン図。
【図１６】実施例１におけるサービスセッション切断シーケンス図。
【図１７】実施例1におけるMN23の無線リンク消失シーケンス図。
【図１８】実施例1におけるMN23の移動シーケンス図。
【図１９】PCRF12のカプセル化ルール再計算ルーチン図。
【図２０】実施例2における端末接続/サービスセッション確立シーケンス図。
【図２１】実施例2における端末接続/サービスセッション確立シーケンス図(図20の続き)。
【図２２】実施例2におけるサービスセッション切断シーケンス図。
【図２３】PDSN(21a、21b)の装置構成例。
【図２４】PDSN(21a、21b)が備えるPPP Session Tableの構成例。
【図２５】PCRF12が備えるQoS Profile Tableの構成例。
【符号の説明】
【００６３】
1 Home Netowrk、2 Visited Network、11 AF、12 PCRF、13 HA、14 CN、21(a、b) PDSN、22(a、b) EV-DO RAN、23 MN、70 Service Table (PCRF12)、80 PPP Session Table (PCRF12)、90 Mobile IP Table (PCRF12)、100 Encapsulation Rule Table (PCRF12)、110 Decapsulation Rule Table (PCRF12)、120 Flow Type-Traffic Class Mapping Table (PCRF12)、130 Mobile IP Table (HA13)、140 Encapsulation Rule Table (HA13)、150 Decapsulation Rule Table (HA13)、420 PPP Session Table (PDSN(21a、21b))、440 QoS Profile Table (PCRF12)、500 カプセル化ルール生成ルーチン(PCRF12)、520 デカプセル化ルール生成ルーチン(PCRF12)、540 パケットカプセル化ルーチン(HA13)、560 パケットデカプセル化後のTraffic Class設定ルーチン(HA13)、580 カプセル化ルール再計算ルーチン(PCRF12)。
【図１】
2008311974.tif 000003
【図２ａ】
2008311974.tif 000004
【図２ｂ】
2008311974.tif 000005
【図３】
2008311974.tif 000006
【図４】
2008311974.tif 000007
【図５】
2008311974.tif 000008
【図６】
2008311974.tif 000009
【図７ａ】
2008311974.tif 000010
【図７ｂ】
2008311974.tif 000011
【図８】
2008311974.tif 000012
【図９ａ】
2008311974.tif 000013
【図９ｂ】
2008311974.tif 000014
【図１０】
2008311974.tif 000015
【図１１】
2008311974.tif 000016
【図１２】
2008311974.tif 000017
【図１３】
2008311974.tif 000018
【図１４】
2008311974.tif 000019
【図１５】
2008311974.tif 000020
【図１６】
2008311974.tif 000021
【図１７】
2008311974.tif 000022
【図１８】
2008311974.tif 000023
【図１９】
2008311974.tif 000024
【図２０】
2008311974.tif 000025
【図２１】
2008311974.tif 000026
【図２２】
2008311974.tif 000027
【図２３】
2008311974.tif 000028
【図２４】
2008311974.tif 000029
【図２５】
2008311974.tif 000030