JP2012519436A

JP2012519436A - ネットワークの動作方法およびネットワーク

Info

Publication number: JP2012519436A
Application number: JP2011552342A
Authority: JP
Inventors: コルベ、ハンス−ヨルグ; シュミット、ミーシャ
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2009-03-02
Filing date: 2010-02-18
Publication date: 2012-08-23
Anticipated expiration: 2030-02-18
Also published as: JP5331903B2; US20110320619A1; CN102342078A; US8661109B2; KR20110125662A; WO2010099876A1; KR101332968B1; EP2404425B1; CN102342078B; EP2404425A1

Abstract

簡単な形でネットワークアプリケーションの多様性の向上を可能にするため、ネットワーク、特にＩＰ（Internet Protocol）ネットワークの動作方法を提供する。該ネットワークには、ゲートウェイを介してローカルネットワークが接続され、ローカルネットワークのＵＥ（ユーザ機器）が、ＵＥ関連および／またはセッション関連のアプリケーションと通信するため、または、該アプリケーションを開始するために、ネットワークの機能エンティティと通信することによってセッション確立を実行する。本方法は、アプリケーションがローカルネットワークコントローラと通信し、ネットワークコントローラが、アプリケーションからＵＥ関連および／またはセッション関連のパラメータ（ＬＩＤ、ローカル識別子）を受信し、受信したパラメータに基づいてローカルネットワーク内のＵＥおよび／または特定のセッションを探索することを特徴とする。また、対応するネットワーク、好ましくは上記方法を実行するネットワークが提供される。

Description

本発明は、ネットワーク、特にＩＰ（Internet Protocol）ネットワークの動作方法に関する。該ネットワークには、ゲートウェイを介してローカルネットワークが接続される。ローカルネットワークのＵＥ（User Equipment, ユーザ機器）が、ＵＥ関連および／またはセッション関連のアプリケーションと通信するため、または、該アプリケーションを開始するために、ネットワークの機能エンティティと通信することによってセッション確立を実行する。また、本発明は、ネットワーク、特にＩＰ（Internet Protocol）ネットワークに関する。該ネットワークには、ゲートウェイを介してローカルネットワークが接続される。ローカルネットワークのＵＥ（User Equipment, ユーザ機器）が、ＵＥ関連および／またはセッション関連のアプリケーションと通信するため、または、該アプリケーションを開始するために、ネットワークの機能エンティティと通信することによってセッション確立を実行する。

現在のネットワーク配備において、ＵＥは、ネットワークすなわち事業者ネットワークに直接にはアタッチしない。ＵＥは、ゲートウェイすなわちホームゲートウェイ（Home gateway, ＨＧＷ）にローカルにアタッチし、ローカルネットワークまたはホームネットワーク内でのみ有効なローカルＩＰアドレスを受け取る。ネットワークすなわち事業者ネットワークあるいはインターネットにおけるサービスにアクセス可能とするために、このアドレスは、ＮＡＴ／ＮＡＰＴ（Network Address Translation/Network Address Port Translation）技術を用いて、ネットワークコントローラまたはＨＧＷの公的なグローバルにルーティングされるＩＰアドレスに変換される。以下、本明細書では、ＮＡＴ／ＮＡＰＴ技術をＮＡＴと称する。

ＩＰネットワーク上のマルチメディア（Multimedia, ＭＭ）セッションに対するエンドツーエンドのサービス品質（ＱｏＳ）保証は、ネットワークのすべての部分における適切な動的ポリシー設定とともに、リソースおよびアドミッション制御を必要とする。オンパスシグナリング（例えば、ＲＳＶＰ（Resource reSerVation Protocol）やＮＳＩＳ（Next Steps In Signaling）を用いたもの）やローカルなアプリケーション層ゲートウェイ（application layer gateway, ＡＬＧ）に基づいてネットワークリソースを予約しポリシーを設定する方法にもかかわらず、ＥＴＳＩＴＩＳＰＡＮＲＡＣＳ、ＩＴＵ−ＴＲＡＣＦあるいは現在開発中のBroadband ForumのＢＰＣＦのようなリソース制御システム（Resource Control System, ＲＣＳ）は、一般化されたアプリケーション機能（Application Function, ＡＦ）によってトリガされるリソースを予約し制御することができる。ＥＴＳＩＴＩＳＰＡＮＲＡＣＳは、非特許文献１に記載されている。ＩＴＵ−ＴＲＡＣＦは、非特許文献２に記載されている。ＡＦは、ＵＥ（ユーザ機器）がマルチメディアセッションを確立するために通信する相手となる機能エンティティである。

現在のＲＣＳは、ＡＦによるリソース要求を受信し、許可または拒否のいずれかのメッセージによって応答する。許可する場合、さらに、メディアパスにおけるネットワーク要素に対して適切なポリシーを設定する。

これは、サービス品質保証を必要とするアプリケーションにおいてだけでなく、デバイスおよび／またはセッションを探索する他のアプリケーションにおいても有益と考えられる。多くの場合、特定のデバイスまたはユーザ機器および／またはセッションに関する情報は、セッション確立手順中に失われる。

セッション確立プロトコルに関連する文献および本発明の背景をなす文献として、例えば、非特許文献３、非特許文献４および非特許文献５がある。

ETSI ES 282 003 V2.0.0, Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS): Functional Architecture ITU-T Recommendation Y.2111 Resource and admission control functions in Next generation networks ETSI TISPAN TS 183 063: "IMS-based IPTV stage 3 specification" RFC 4566: "SDP: Session Description Protocol" (http://www.ietf.org/rfc/rfc4566.txt) RFC 4091 : "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework" (http://www.ietf.org/rfc/rfc4091.txt)

本発明の目的は、簡単な形でネットワークアプリケーションの多様性の向上を可能にするために、ネットワークの動作方法および対応するネットワークの改良およびさらなる展開を行うことである。

本発明によれば、上記の目的は、請求項１の構成を備えた方法および請求項２２の構成を備えたネットワークによって達成される。請求項１に記載の通り、本方法は、以下のことを特徴とする。すなわち、アプリケーションはローカルネットワークコントローラと通信し、ネットワークコントローラは、アプリケーションからＵＥ関連および／またはセッション関連のパラメータ（ＬＩＤ（Local Identifier）、ローカル識別子）を受信し、受信したパラメータに基づいてローカルネットワーク内のＵＥおよび／または特定のセッションを探索する。請求項２２に記載の通り、本ネットワークは、以下のことを特徴とする。すなわち、アプリケーションはローカルネットワークコントローラと通信する手段を備え、ネットワークコントローラは、アプリケーションからＵＥ関連および／またはセッション関連のパラメータ（ＬＩＤ、ローカル識別子）を受信し、受信したパラメータに基づいてローカルネットワーク内のＵＥおよび／または特定のセッションを探索する手段を備える。

本発明によって認識されたこととして、簡単な形でローカルネットワーク内のＵＥおよび／または特定のセッションを探索することが可能である。具体的には、アプリケーションは、ローカルネットワークのネットワークコントローラと通信しなければならない。ネットワークコントローラは、アプリケーションからＵＥ関連および／またはセッション関連のパラメータを受信する。このようなパラメータは、ＬＩＤ（ローカル識別子）と呼ぶことができる。ＬＩＤは、ローカルネットワーク内のＵＥおよび／または特定のセッションを識別する。こうして、ネットワークコントローラは、受信したパラメータに基づいて、ＵＥおよびローカルネットワークを通じてＵＥへ向かうパスおよび／または特定のセッションを探索することができる。

このような方法またはネットワークに基づいて、ネットワークアプリケーションの多様性の向上が容易に可能となる。ローカルネットワークはホームネットワークであることが可能であり、ゲートウェイはホームゲートウェイであることが可能である。一般的に、ゲートウェイがネットワークコントローラを含んでもよい。

好ましい実施形態において、アプリケーションは、ネットワーク内のセッションに対して要求されるネットワークリソースの制御および／または予約を行うＲＣＳ（リソース制御システム）と、ＵＥによって要求されるアプリケーションロジックを処理する機能とに分割される。この場合、ＲＣＳは、ローカルネットワーク、好ましくはホームネットワーク内のセッションに対して要求されるネットワークリソースの制御および／または予約を行うために、ネットワークコントローラと通信することが可能である。

ローカルまたはホームネットワークをＲＣＳの有効範囲内に含めるため、ネットワークコントローラまたはホームネットワークコントローラ（Home Network Controller, ＨＮＣ）は、ＲＣＳからリソース要求を受信してもよい。ローカルまたはホームネットワークはますます複雑になっているので、ネットワークコントローラまたはＨＮＣは、セッション確立を開始したＵＥを識別することができるようにしてもよい。このためには、ネットワークコントローラまたはＨＮＣが、ＵＥの一意的なローカル識別子（ＬＩＤ）、例えばローカルＩＰアドレスを知ることにしてもよい。ＩＰにおいてローカルまたはホームネットワークで事業者ネットワークへのＮＡＴ／ＮＡＰＴが実行される場合、この情報はほとんどの場合に失われる。マルチキャストセッションでは、現在、この情報は常に失われる。すなわち、ＡＦ／ＲＣＳへトランスポートされない。また、ローカルまたはホームネットワーク内のＵＥが、例えば認可またはリソース予約のために、ネットワークコントローラまたはＨＮＣとローカルセッションについて交渉している場合、セッションを関連づけるために、対応するセッション識別子をＲＣＳからのリモート要求に含める必要がある。

好ましくは、パラメータは、ポート番号を伴う、または伴わない、ＵＥのローカルネットワークアドレス、好ましくはローカルＩＰアドレスを含み、またはそれから構成されてもよい。この場合、上記の方法におけるパラメータを識別するものとして、既存のパラメータを用いることができる。

別法として、パラメータは、ＵＥの特定のローカルな特性、文字列またはローカルセッションＩＤを含み、またはそれから構成されてもよい。

さらに別法として、パラメータは、乱数、バイトコード配列、または、ローカルネットワーク内のデバイス間でブートストラップアルゴリズムを通じて交渉された識別子を含み、またはそれから構成されてもよい。

換言すれば、パラメータは、任意の種類のローカルに有意なジェネリック識別子を含み、またはそれから構成されてもよい。

非常に簡単な使用事例に関して、パラメータは、ネットワークコントローラによって、好ましくはＵＥがネットワーク、ローカルネットワークまたはネットワークコントローラにアタッチしている間、あるいは、好ましくはＵＥによる特定の要求後に、生成されてもよい。別法として、本方法の非常に簡単な実施形態に関して、パラメータは、ＵＥによって生成されてもよい。したがって、パラメータは、セッション確立の実行前に生成されてもよい。

別の好ましい実施形態において、パラメータは、セッション確立を実行しているＵＥとは無関係であってもよい。したがって、パラメータは、セッション確立を実行しているＵＥとは異なるアドレスを有する１つまたは複数の受信ポイントに対してメディアを要求するために使用されてもよい。換言すれば、ＵＥは、他のＵＥに対してセッションを要求することができる。

別の好ましい実施形態において、パラメータは、セッション確立中にＵＥから機能エンティティを介して１つまたは複数のアプリケーションへトランスポートされてもよい。このような処理により、アプリケーションにおけるパラメータの非常に信頼性の高い提供を保証することが可能である。

本発明の方法において、パラメータは、ローカルネットワークから、パラメータが意味をもたないネットワークドメインを経由して、同一または異なるネットワークパスを介してローカルネットワークに戻るようにループされるのが好ましい。具体的な実施形態において、パラメータは、ローカルネットワークから、パラメータが意味をもたないＲＣＳを経由して、ローカルネットワークに戻るようにループされてもよい。

非常に簡単な手順に関して、機能エンティティ、好ましくはＡＦ（アプリケーション機能）は、アプリケーションに対する要求において、パラメータを含むことができるようにしてもよい。すでに計画された要求にパラメータを統合することは、非常にすぐれた手順を提供する。

意図しない効果を避けるため、パラメータは、ネットワークドメインにおいて不透明としてもよく、変更なしにネットワークドメインを通過してもよい。

好ましくは、セッション確立は、セッション記述プロトコルによって、好ましくはＳＤＰ（Session Description Protocol）によって実行されてもよい。本発明の方法とともに、既知のプロトコルを使用可能である。

したがって、パラメータは、セッション記述プロトコルの一部であっても、特に問題を生じない。具体的には、パラメータは、ａライン、ｉラインまたはｏラインによって伝えられてもよく、ａラインが好ましい。

本発明の方法は、ユニキャストおよびマルチキャストのセッションをサポートすることができる。これに関して制限はない。

別の好ましい具体的な実施形態において、パラメータは、ローカルセッションを、アプリケーションまたはＲＣＳから到来するリソース要求と関連づけるために使用されてもよい。これにより、ネットワーク内のリソースと、ローカルネットワーク内のリソースとを関連づけることができる。

好ましくは、ローカルセッションは、アプリケーションまたはネットワークアタッチメントセッションによって特徴づけられてもよい。

上記方法の別の好ましい実施形態において、ローカルアドミッション制御手続きは、パラメータに基づいて、ローカルまたはホームネットワーク内のＵＥへのネットワークパスを取得することに基づいてもよい。

好ましくは、ネットワークコントローラまたはアプリケーション機能は、ＬＩＤまたはパラメータに基づいて、どのサービスを提供するかに関する独立の決定をしてもよい。

本発明による方法では、パラメータが、セッションを開始するＵＥのローカル識別子（ＬＩＤ）の形態で、パラメータが意味をもたない異なるネットワークドメインを経由してトランスポートされることが可能である。本方法は、ユニキャストおよびマルチキャストのセッションに対して設計される。それらのセッションは、例えば、ＳＩＰ／ＳＤＰ（Session Initiation Protocol/Session Description Protocol）またはＲＴＳＰ／ＳＤＰ（Real Time Streaming Protocol/Session Description Protocol）を用いて確立される。ＨＮＣが、受信した識別子に基づいて、ホームネットワーク内のＵＥを探索する手続きが提供される。ＬＩＤ自体は、ＨＮＣによってローカルに生成され、ネットワークアタッチメント中に、または、特定の要求後に、ＵＥに転送される不透明な文字列として使用されることも可能である。

本発明においては、ローカル識別子（ＬＩＤ）が作成される。ＬＩＤは、ローカルアドレスまたは任意の種類のローカルに有意なジェネリック識別子、例えば、文字列やローカルセッションＩＤ、から構成されることが可能である。こうして、ＬＩＤは、アプリケーションやアプリケーション機能にプライベートなホームネットワーク情報を開示しないような方法で作成されることが可能である。

セッションシグナリングのためにＳＤＰを使用する場合、ＳＤＰ情報は拡張されることが可能である。ＳＤＰ情報は、ホームネットワーク内のユニキャストまたはマルチキャストストリーム受信器ローカルアドレス、または他の種類のローカルに一意的な識別子を含むように、セッション確立シグナリングにおいて伝送される。

本発明によれば、ローカルネットワークコントローラまたはＨＮＣは、ＬＩＤに基づいて、ローカルまたはホームネットワーク内のＵＥおよび／または特定のセッションを探索することが可能となる。

簡潔に要約すれば、実現可能な重要な特徴は以下の通りである。
１）ローカル識別子を定義し、ＵＥおよび／またはセッションに割り当てる
２）ＬＩＤが意味をもたないネットワークドメインを経由してＬＩＤをトランスポートし、発信元のドメインに戻す
３）新たなローカル識別子（ＬＩＤ）パラメータをＳＤＰに追加する
４）ＡＦが、ＬＩＤ情報をＲＣＳまたは他のアプリケーションに渡すことを可能にする
５）ローカル識別子がセッション識別子を伝えることにより、ローカルアプリケーションおよび／またはネットワークアタッチメントセッションをリモート要求（例えばＩＰ電話の場合、所定時間内の電話の予約に対する要求）と相互接続させることを可能にする
６）ＨＮＣが、ＬＩＤに基づいてＵＥおよび／またはＵＥセッションを探索することを可能にする

本発明の効果は以下のように要約することができる。
・従来の技術は、ホーム内のマルチキャスト受信ポイントを識別することができない。この識別は、ホーム内リソース制御メカニズムにとって大いに有用となり得る。
・特に、ユニキャストの場合、ホームネットワーク内またはローカルネットワーク内のデバイスを探索するメカニズムもまだ規定されていない。
・ＳＤＰを用いてＬＩＤを伝えることにより、本発明は、例えばＩＭＳ方式のＩＰＴＶのようなＩＭＳ（IP Multimedia Subsystem）方式のサービスに容易に統合可能であるが、ＳＩＰ方式のサービスには限定されず、例えばＲＴＳＰにも適用可能である。
・基礎技術を規定することにより、パス内メカニズムを実装することを必要とせずに、暗号化されたシグナリングセッションをサポート可能なホームネットワークに対するリモートリソース制御を可能にする。
・既存のインフラストラクチャ、例えば、セッション確立の認証（例えばＳＩＰＩｎｖｉｔｅ）を使用する。作り直すものはなく、単に新たなパラメータを追加するだけである。
・ＵＥソフトウェアに対する影響は最小限である。
・ＲＣＳ以外のアプリケーションが、ＡＦおよびＨＮＣに接続することにより、本方法を利用することができる。

本発明を好ましい態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。

本発明によるネットワークの動作方法の第１の好ましい実施形態を例示する図である。本発明によるネットワークの動作方法の第２の好ましい実施形態を例示する図である。

図１は、ネットワークの動作方法の第１の好ましい実施形態を例示している。ホームネットワークの形態でのローカルネットワークが、ホームゲートウェイを介してネットワークに接続している。ホームゲートウェイは、ローカルなホームネットワークコントローラ（ＨＮＣ）を含んでもよい。ホームネットワークのＵＥは、ネットワークの機能エンティティ、すなわちアプリケーション機能ＡＦと通信することによってセッション確立を実行する。そして、アプリケーション機能ＡＦは、ＲＣＳと通信する。

ＵＥは、ＨＮＣを含むＨＧＷ（ホームゲートウェイ）を通じてＡＦへセッション開始要求を送信する。ＡＦは、ＳＤＰから必要なリソースを抽出し、ＲＣＳへ要求を送信する。すると、ＲＣＳは、事業者ネットワーク（図示せず）においてリソースを予約する。要求はＨＧＷの公的なＩＰアドレスを含むので、ＲＣＳは、ホームネットワークを探索し、ホームネットワークへのリソース予約を実行することができる。ホームネットワーク内でリソースを予約するため、ＨＮＣは、ホームネットワーク内のＵＥを探索することが可能とされる。このために、ＨＮＣは、ＲＣＳからローカル識別子（ＬＩＤ）を受信する。

具体的な実施態様において、ホームネットワーク内のＵＥを探索するため、ＵＥのローカルＩＰアドレスがＨＮＣによって使用されることが可能である。要求がＲＣＳへ送信される前に、シグナリングパス内のどのシグナリングプロキシもＳＤＰの内容を変更しない場合、ローカルアドレスは、ａラインおよびｃラインから抽出することができる。ただし、ローカルアドレスは、ＲＣＳへの要求には明示的に含める必要があり、ＨＮＣは、後述するクライアントを探索する機能を含む必要がある。しかし、これはユニキャストサービスの場合にのみ機能する。というのは、マルチキャストサービスの場合には、ＳＤＰフォーマットが異なり、ｃラインまたはａラインにおいてＵＥのＩＰアドレスを伝えないからである。マルチキャストサービスに対するセッションネゴシエーションの場合、現在、ＳＤＰは、ローカルＩＰアドレスを含まない。というのは、これは、ホームネットワーク内でメディアを転送するためには不要だからである（メディアの宛先アドレスはストリームのマルチキャストアドレスである）（例えば非特許文献３を参照）。

ＳＤＰが、例えばＮＡＴ通過を容易にするために書き換えられる場合、ＵＥからのセッション確立要求にローカルアドレスまたはジェネリックＬＩＤを含めるべきである。というのは、さもなければ、この情報は、受信側メディアに対するａラインおよびｃラインが書き換えられているので失われてしまうからである。

クライアントのＩＰアドレスをトランスポートするためにＳＩＰの「ＶＩＡ」ヘッダを使用することは適切でない。というのは、これは、シグナリングクライアントのＩＰアドレスが、メディア受信器が有しているものと同一であることを暗黙に仮定し、ＬＩＤの使用を（例えばセッションではなく）ＩＰアドレスに限定するからである。また、このような目的で「Ｖｉａヘッダ」を抽出することは、３ＧＰＰおよびＴＩＳＰＡＮのアーキテクチャに準拠しておらず、「Ｖｉａヘッダ」が現在および将来のネットワークにおいて所望の情報を含むことを保証することはできない。ローカルＢ２ＢＵＡ（back-to-back user agent）がシグナリングパス内にある場合には、いずれにせよ、ｖｉａヘッダは所望の情報を含まない。

ホームネットワーク内でのセッション確立メッセージのローカルなスヌーピングは、ホームネットワーク内のエンドポイントを識別するためであれば適切である。この方法は、ＩＭＳＡＫＡ（Authentication and Key Agreement）によって規定される暗号化されたシグナリングに対しては機能しないので、ホームネットワークは、ＲＣＳからＵＥのＬＩＤを取得すべきである。

ＬＩＤは、ローカルセッション（例えば、ＡＦとのセッションを確立する前にホームネットワーク内のリソースを予約するためにＵＥとＨＮＣとの間で行われる）を、ＲＣＳから到来するリソース要求と関連づけるためにも使用可能である。その場合、ＬＩＤは、デバイスを探索するために使用可能なＩＤではなく、セッションＩＤを伝える。このような場合は、第２の好ましい実施形態による図２に例示されている。

さらに、この新しいパラメータは、ＳＤＰ非対応のエンドデバイスであるような受信ポイントに対するメディアを要求するために使用可能である。このような受信ポイントは、「ホームハブ」であってもよい。「ホームハブ」は、ホームネットワーク内で、要求されたメディアを受信・配信するために使用可能である。メディアに対する要求は、ＵＥによって実行されてもよく、その結果、メディアが「ホームハブ」に配信される。

また、ＲＣＳ以外のアプリケーションが、ＬＩＤによって与えられるこのようなＵＥ関連および／またはセッション関連の情報から利益を受ける可能性もある。

ＨＮＣは、ホームゲートウェイ内に存在してもよいが、アプリケーションから到達可能なホームネットワーク内の他のエンティティに実装されることも可能である。

実施形態の重要な特徴を以下でさらに詳細に説明する。

１）パラメータ（ＬＩＤ、ローカル識別子）を定義し割り当てる：
セッション確立をローカルまたはホームネットワーク内のデバイス（ＵＥ）および／またはセッションと関連づけるため、ジェネリックなローカル識別子（ＬＩＤ）が提案される。ＬＩＤは、例えば以下のものから構成されることが可能である。
・メディアを交換するＵＥ（シグナリングを実行するデバイスである必要はない）のローカルＩＰアドレス（ポート番号を伴っても伴わなくてもよい）
・ＵＥの特定のローカルな特性（例えば、ＭＡＣ（Media Access Control）アドレス、ＩＭＥＩ，ＳＩＰアドレス、ＵＲＬ、シリアル番号、「居間」「台所」のような事前に割り当てられた識別子）
・例えばＤＨＣＰ（Dynamic Host Configuration Protocol）を用いたネットワークアタッチメント中に、ＨＮＣによって生成されＵＥに送信された識別子
・ＵＥによる要求後にＨＮＣによって生成された識別子（例えば、ＱｏＳ付きで予約されたパスに対する予約番号）
・ＵＥによって生成されＨＮＣへの登録のために送信された識別子、例えば、乱数、バイトコード配列、ローカルネットワーク内のデバイス間でブートストラップアルゴリズムを通じて交渉された識別子

ＬＩＤの名前空間は、ローカルネットワーク、すなわちホームネットワークに限定される。

拡張として、ＬＩＤは、セッション確立のためのシグナリングを実行しているデバイスとは異なるＩＰアドレスを有する１つまたは複数の受信ポイントに対してメディアを要求するために使用されることが可能である。

使用事例として、ＵＰｎＰ（Universal Plug and Play）を通じてさまざまなエンドデバイスを制御することができるＳＩＰ／ＳＤＰクライアントを備えた「ホームハブ」が挙げられる。「ホームハブ」は、音声付きＩＰＴＶに対して、複数のｍラインでメディアセッションを要求し、相異なるｍラインに対して相異なるＬＩＤパラメータを指定することにより、例えば、ビデオストリームを受信するＳＴＢ（Set Top Box）のＩＰアドレスと、オーディオストリームを受信するステレオに対する別のＩＰアドレスとを指示する。その場合、ＵＰｎＰのような別のプロトコルを用いて、ステレオおよびＳＴＢをトリガして、目的のマルチキャストグループに「同調」させることも可能である。

２）ＬＩＤが意味をもたない他のネットワークドメインを経由してＬＩＤを渡し、ホームネットワークに戻す
ＬＩＤは、例えばＳＤＰ上でＡＦに伝えられる際に、ＬＩＤが意味をもつドメインを出るセッション確立のためのシグナリングに含まれることが可能である。

ＬＩＤは、他のネットワークドメインを経由して渡された後、ホームネットワーク、すなわちＨＮＣへ向かう同一または異なるシグナリングチャネル上で戻されることが可能である。

外部ドメイン、すなわち非ローカルネットワークでは、ＬＩＤは不透明であり、変更なしに渡される。

この一例として、図１および図２に示す使用事例がある。この場合、ＬＩＤはＡＦにおいて受信され、ＲＣＳに渡され、ＨＮＣへ向かうＲＣＳシグナリング（異なるシグナリングチャネル／パス）で戻される。

３）新たなパラメータ（ＬＩＤ、ローカル識別子）をＳＤＰに追加する
マルチメディア（ＭＭ）シグナリングの場合、通常はＳＤＰが使用される。ＳＤＰは、例えば、ＳＩＰにおけるＩＭＳ方式のネットワークで伝えられる。しかし、ＳＤＰは、例えばＲＴＳＰ方式のサービスでも使用され、ＵＥのローカルＩＰアドレスを伝えるための良い選択肢となり得る。したがって、本発明は、ローカルＩＰアドレスおよび／またはポート番号またはジェネリックなローカル識別子（ＬＩＤ）を指示するための追加的なＳＤＰパラメータを定義することが可能である。ＩＰアドレスおよびポートは、ＬＩＤの実装とみなすことができる。ＵＥのようなサービスエンドポイントは、このパラメータを設定することによって、送信するＭＭシグナリングを拡張することができる。

本発明においては、セッション確立を開始したＵＥのローカル識別子に関する情報をＳＤＰに追加する。ＬＩＤは、ローカルＩＰアドレスおよびポートから構成されることが可能である。シリアル番号や、ＨＧＷへのＵＥのネットワークアタッチメント（例えばＤＨＣＰオプションを用いて）中に取得した識別子のような他のデバイス固有のパラメータも適用可能である。

一例として、ａラインパラメータが、ローカルアドレス情報を伝えることができる。このａラインは、例えば、ＩＭＳ方式のＩＰＴＶの場合、Ｐ−ＣＳＣＦ（Proxy-Call Session Control Function）からＴＩＳＰＡＮＲＡＣＳに渡され、例えば、ホームゲートウェイ内のホームＲＡＣＳコントローラに、メディアトラフィックがどこを流れるかに関する追加情報を提供することができる。これにより、ＨＮＣは、ホームネットワーク内のリソース要求を満たすことができるかどうかをユニキャストおよびマルチキャストの両方のサービスに対して正確に判定するために必要なホームネットワーク内のデバイスを探索することができる。新たなパラメータは、「ローカル識別子」（ＬＩＤ）と呼ぶことができる。

ａラインは、例えば分散メディアセッションが使用される場合には、セッションレベルであることもメディアレベルであることも可能であり、複数回現れることもある。一般的に、ａラインは、ａ＝＜フラグ＞またはａ＝＜属性＞：＜値＞という形式とすべきである。後者のほうが、ＬＩＤを伝えるという意図された使用法にはより適切であるが、本発明は両方の方法を包含する。

例は、以下の通りである。
ａ＝ＬＩＤ：＜ＩＰｖ４アドレス＞
ａ＝ＬＩＤ：＜ＩＰｖ６アドレス＞
ａ＝ＬＩＤ：＜ＩＰｖ６アドレス：ポート＞
ａ＝ＬＩＤ：＜ＩＰｖ４アドレス：ポート＞
ａ＝ＬＩＤ：＜オクテット列＞

正確な属性名はＩＡＮＡ（Internet Assigned Numbers Authority）の登録または実装に従う。

ＬＩＤ属性は、例えばＳＤＰのＡＮＡＴ（Alternative Network Address Types）セマンティクスと組み合わせることによって、（インターネットであまり一般的に使用されない）他の形式のアドレス情報を伝えることも可能である。ＬＩＤは、ホームネットワーク内の一意的識別子、例えばＤＨＣＰオプションを用いたＵＥのネットワークアタッチメント中にＨＧＷによって発行される英数字列、を表すオクテット列を伝えることも可能である。ポート情報を含む記法が使用される場合、提供されるポート情報は、メディアラインで渡されるポート情報と同一でなければならない。したがって、ポート拡張ＬＩＤ属性の使用はｍラインレベルで推奨されるが、セッションレベルＬＩＤ属性はポートを含んではならない。また、ユニキャストサービスの場合、ｃラインパラメータは、分散メディア受信が使用されるのでなければ、ＬＩＤ属性で提供される値と同一とすべきである（下記参照）。

本発明は、他のすべての適切なＳＤＰライン、例えばｉラインやｏラインを包含し、パラメータの名称もまた、厳密に「ＬＩＤ」に限定されるものではない。

ＡＦへのｏラインにローカルＩＰアドレスを用いることは、例えばａラインを用いた現在のＳＤＰの拡張となる。

複数のｍラインで複数の異なるＬＩＤａラインを使用することにより、例えば分散メディア受信セッションを実現することが可能となり、例えば１つのコントローラエンティティが、複数のエンドポイントに直接に配信されるマルチメディアを要求することが可能となる（例えば「ホームハブ」の例）。

ＩＭＳ方式のＩＰＴＶＳＴＢは、それらのセッション確立シグナリングにおいてＬＩＤを伝えることで、ＡＦがＥ２Ｅ（End to End）アドミッション制御およびリソース予約のためにＲＣＳ（およびおそらくはホームＨＮＣ）に通知することができるようにすべきである。

４）ＡＦが、パラメータまたはＬＩＤ情報をＲＣＳまたは他のアプリケーションに渡すことを可能にする
ＡＦは、次の２つの方法でＬＩＤを受信することができる。
・直接に。すなわち、ＵＥがＬＩＤパラメータを使用したときに明示的に。
・間接に。すなわち、ＳＤＰにおいて（例えばａラインを通じて）変更されていないＩＰアドレス（ゲートウェイまたはホームゲートウェイによるＮＡＴが実行されていない場合）を受信した場合に暗黙的に。その場合、ＬＩＤはローカルＩＰアドレスとなる。

そして、ＡＦは、ＤｉａｍｅｔｅｒＡＶＰとして、または類似のプロトコル（例えばＲＡＤＩＵＳ）を使用して、リソース要求においてＲＣＳへＬＩＤを送信する。

一例として、ＴＩＳＰＡＮＲＡＣＳまたは３ＧＰＰＲｘにおいて、ＬＩＤは、ａラインでトランスポートされるときには、すでに指定されている「コーデックデータ」ＡＶＰを通じてトランスポート可能である。ｏラインの使用は、Ｐ−ＣＳＣＦ挙動のより詳細な指定を必要とし、標準準拠ではない。同じことはＳＩＰにおけるＶＩＡヘッダにも当てはまる。

ＲＣＳ以外のアプリケーションもまた、ホームネットワーク内のデバイスを探索することが可能となることから多大な利益を受けることができる。したがって、使用事例はＲＣＳのものに限定されない。

５）パラメータまたはローカル識別子がセッション識別子を伝えることにより、ローカルセッションをリモート要求と相互接続させることを可能にする（例えば、図２）
ＬＩＤは、アドレスを伝えるのとともに、または単独で、セッションＩＤを含むために使用されることも可能である。このセッションＩＤは、ＵＥとＨＮＣまたはネットワークコントローラとの間で行われていたセッションまたは依然として開かれているセッションを記述する。一例として、ＵＥからＨＮＣまたはネットワークコントローラに対して、与えられた優先度で特定のトラフィッククラスのある一定の帯域幅を予約する要求が挙げられる。その場合、このＩＤは、ＲＣＳからのリソース要求に含められる。すると、ＨＮＣまたはネットワークコントローラは、内部セッションとリモート要求との両者を関連づけ、ローカル予約がそのセッションＩＤを用いてすでに完了している場合にリソース要求に直ちに応答することを可能にする。

現在のＩＥＴＦによるＳＤＰの定義（ＲＦＣ４５６６）では、必須のｏラインがグローバルセッション識別子もトランスポートすることができる。本発明では、識別子はローカルのみとする必要がある。というのは、識別子と継続中のセッションとの組合せにはそのほうが好ましいからである。

６）ＨＮＣまたはネットワークコントローラが、パラメータまたはＬＩＤに基づいてＵＥまたはＵＥセッションを探索することを可能にする
ローカルまたはホームネットワーク内のＵＥへのパス上のリソースを計算するため、ネットワークコントローラまたはＨＮＣは、ＵＥを探索する必要がある。ネットワークコントローラまたはＨＮＣは、パラメータまたはＬＩＤを受信した後、次のように作用する。

ＬＩＤパラメータで１つ以上のローカルＩＰアドレスを受信した後、レイヤ２アドレスおよび割り当てられたＩＰアドレスが保存されているローカルネットワークアタッチメント機能のデータベースを参照する。ここで、レイヤ２アドレスは、ＵＥの位置を暗黙的に指定している。というのは、例えばイーサーネット配備において、レイヤ２アドレス（ＭＡＣアドレス）は、ＵＥが直接にアタッチされている物理ポート上で取得されるからである。

（ＵＥまたはセッションを参照する）１つ以上のパラメータまたはジェネリック識別子を受信した後、ネットワークコントローラまたはＨＮＣは、そのローカルデータベースの参照を開始したのと同じステップを実行する。その後のステップは上記の通りである。

通常、ネットワークコントローラまたはＨＮＣおよびローカルネットワークアタッチメント機能は、ＨＧＷ内にコロケートされていると考えられる。

使用事例
例ａ）：ユニキャストのためのＩＰアドレスとしての暗黙的なＬＩＤ、マルチキャストのための明示的なＳＤＰ−ＬＩＤ
この場合、ユニキャストを使用するデバイスは、ＬＩＤをサポートするために変更する必要はない。マルチキャストサービスのためにＳＤＰによるセッション確立を使用するデバイスのみ、アップグレードの必要がある。これが影響を及ぼすのは、ＳＩＰまたはＲＴＳＰを用いた現在のＩＰＴＶデバイスのみであるので、必要とされるＵＥのアップグレードは、ＩＰＴＶＳＴＢに限定され、配備は実現可能である。

例ｂ）すべてのセッションに対して要求される明示的なＬＩＤ
この場合、保証されたＱｏＳを要求するすべてのデバイスがＬＩＤを実装する必要があり、その結果、それらのすべてのアップグレードが必要である。最悪の場合、ＬＩＤを実装しないデバイスには、ホームネットワーク内でＱｏＳが与えられない。ＨＧＷのアップリンク上のＱｏＳは依然としてＲＣＳにより可能である。というのは、その場合、ＬＩＤは不要だからである。

追加的な使用事例
ＱｏＳの使用事例（ＲＣＳ）以外のアプリケーションが、ＬＩＤを利用することが可能である。一例として、「午後１１時以降は居間で音楽を再生してはならない」のようなローカルパラメータに基づくセッションを可能にするアプリケーションがある。

本発明の方法およびネットワークによれば、例えばＬＩＤまたはパラメータをトランスポートするようにＳＤＰを拡張することによって一部のセッションが暗号化されたシグナリングを使用する場合であっても、オンパスシグナリングまたはＡＬＧを配備することを必要とせずに、リモートのホーム内ＱｏＳ制御のためのサポートメカニズムを定義することが可能である。本発明は、従来のＵＥに対する影響を最小限としたメカニズムを提供する。

上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。

Claims

ネットワーク、特にＩＰ（Internet Protocol）ネットワークの動作方法において、該ネットワークには、ゲートウェイを介してローカルネットワークが接続され、ローカルネットワークのＵＥ（ユーザ機器）が、ＵＥ関連および／またはセッション関連のアプリケーションと通信するため、または、該アプリケーションを開始するために、ネットワークの機能エンティティと通信することによってセッション確立を実行し、
アプリケーションがローカルネットワークコントローラと通信し、ネットワークコントローラが、アプリケーションからＵＥ関連および／またはセッション関連のパラメータ（ＬＩＤ、ローカル識別子）を受信し、受信したパラメータに基づいてローカルネットワーク内のＵＥおよび／または特定のセッションを探索することを特徴とする、ネットワークの動作方法。
アプリケーションが、ネットワーク内のセッションに対して要求されるネットワークリソースの制御および／または予約を行うＲＣＳ（リソース制御システム）と、ＵＥによって要求されるアプリケーションロジックを処理する機能とに分割されることを特徴とする請求項１に記載の方法。
ＲＣＳが、ローカルネットワーク内のセッションに対して要求されるネットワークリソースの制御および／または予約を行うために、ネットワークコントローラと通信することを特徴とする請求項２に記載の方法。
パラメータが、ポート番号を伴う、または伴わない、ＵＥのローカルネットワークアドレス、好ましくはローカルＩＰアドレスを含み、またはそれから構成されることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
パラメータが、ＵＥの特定のローカルな特性、文字列またはローカルセッションＩＤを含み、またはそれから構成されることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
パラメータが、乱数、バイトコード配列、または、ローカルネットワーク内のデバイス間でブートストラップアルゴリズムを通じて交渉された識別子を含み、またはそれから構成されることを特徴とする請求項１ないし５のいずれか１項に記載の方法。
パラメータが、ネットワークコントローラによって、好ましくはＵＥがネットワーク、ローカルネットワークもしくはネットワークコントローラにアタッチしている間、または、好ましくはＵＥによる特定の要求後に、生成されることを特徴とする請求項１ないし６のいずれか１項に記載の方法。
パラメータが、ＵＥによって生成されることを特徴とする請求項１ないし６のいずれか１項に記載の方法。
パラメータが、セッション確立を実行しているＵＥとは異なるアドレスを有する１つまたは複数の受信ポイントに対してメディアを要求するために使用されることを特徴とする請求項１ないし８のいずれか１項に記載の方法。
パラメータが、セッション確立中にＵＥから機能エンティティを介して１つまたは複数のアプリケーションへトランスポートされることを特徴とする請求項１ないし９のいずれか１項に記載の方法。
パラメータが、ローカルネットワークから、パラメータが意味をもたないネットワークドメインを経由して、同一または異なるネットワークパスを介してローカルネットワークに戻るようにループされることを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
機能エンティティ、好ましくはＡＦ（アプリケーション機能）が、アプリケーションに対する要求において、パラメータを含むことができることを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
パラメータが、ネットワークドメインにおいて不透明であり、変更なしにネットワークドメインを通過することを特徴とする請求項１ないし１２のいずれか１項に記載の方法。
セッション確立が、セッション記述プロトコルによって、好ましくはＳＤＰ（Session Description Protocol）によって実行されることを特徴とする請求項１ないし１３のいずれか１項に記載の方法。
パラメータが、セッション記述プロトコルの一部であることを特徴とする請求項１４に記載の方法。
パラメータが、ａライン、ｉラインまたはｏラインによって伝えられることを特徴とする請求項１４または１５に記載の方法。
セッションが、ユニキャストまたはマルチキャストのセッションであることを特徴とする請求項１ないし１６のいずれか１項に記載の方法。
パラメータが、ローカルセッションを、アプリケーションまたはＲＣＳから到来するリソース要求と関連づけるために使用されることを特徴とする請求項１ないし１７のいずれか１項に記載の方法。
ローカルセッションが、アプリケーションまたはネットワークアタッチメントセッションによって特徴づけられることを特徴とする請求項１ないし１８のいずれか１項に記載の方法。
ローカルアドミッション制御手続きが、パラメータに基づいて、ローカルまたはホームネットワーク内のＵＥへのネットワークパスを取得することに基づくことを特徴とする請求項１ないし１９のいずれか１項に記載の方法。
ネットワークコントローラまたはアプリケーション機能が、ＬＩＤに基づいて、どのサービスを提供するかに関する独立の決定を行うことを特徴とする請求項１ないし２０のいずれか１項に記載の方法。
ネットワーク、特にＩＰ（Internet Protocol）ネットワークであって、好ましくは請求項１ないし２１のいずれか１項に記載の方法を実行するネットワークにおいて、該ネットワークには、ゲートウェイを介してローカルネットワークが接続され、ローカルネットワークのＵＥ（ユーザ機器）が、ＵＥ関連および／またはセッション関連のアプリケーションと通信するため、または、該アプリケーションを開始するために、ネットワークの機能エンティティと通信することによってセッション確立を実行し、
アプリケーションが、ローカルネットワークコントローラと通信する手段を備え、ネットワークコントローラが、アプリケーションからＵＥ関連および／またはセッション関連のパラメータ（ＬＩＤ、ローカル識別子）を受信し、受信したパラメータに基づいてローカルネットワーク内のＵＥおよび／または特定のセッションを探索する手段を備えたことを特徴とするネットワーク。