JP2012195966A - 接続識別子システム及び方法 - Google Patents

Abstract

【課題】通信ネットワーク内のソースノードと宛先ノードとの間で実行される接続を確立するための方法を提供する。
【解決手段】通信ネットワーク内のソースノードと宛先ノードとの間に要求される接続を確立するための方法及びシステムが提案される。そのシステム及び方法は、３ＧＰＰネットワークとの関連で説明されるが、他のタイプのネットワークにも適用することができる。その方法は、ソースノード内の接続のためのソースアプリケーション識別子を生成すること、ソースノードのためのソースノード識別子を取り出すこと、及びソースアプリケーション識別子及びソースノード識別子を宛先に送信することであって、それによりソースノードと宛先ノードとの間に要求される接続のためのソース接続識別子を与え、送信することを含む。ソースノード、宛先ノードはそれぞれ、基地局を含む。
【選択図】図１

Description

本発明は、移動通信ネットワーク、限定はしないが、特に３ＧＰＰ標準規格、又はその等価物若しくは派生物に従って動作するネットワークにおけるバッファ接続の管理に関する。

通信ネットワークにおいて、ネットワークの構成要素間又はノード間に接続が確立される場合がある。たとえば、ネットワーク内の２つの基地局（ｅＮｏｄｅＢ）構成要素間、又は通信ネットワーク内のｅＮｏｄｅＢとゲートウェイ構成要素との間に接続が確立される場合がある。ゲートウェイ構成要素の一例はアクセスゲートウェイを含むことができ、それは移動管理エンティティ（ＭＭＥ）又はシステムアーキテクチャエボリューション（ＳＡＥ）ゲートウェイとすることができる。新たな移動通信デバイス又はユーザ装置（ＵＥ）がｅＮｏｄｅＢに接続するとき、たとえば、移動デバイスに電源が入れられるときに、又は移動デバイスがネットワーク内の１つのｅＮｏｄｅＢから異なるｅＮｏｄｅＢに移行するときに、接続が確立される場合がある。同様に、ｅＮｏｄｅＢ構成要素がネットワーク内の新たなゲートウェイデバイスと通信するときに、接続が確立される場合がある。

接続を確立する前に、ソースノード、たとえばｅＮｏｄｅＢは、その接続のためのアプリケーション識別子（ｅＮＢ Ｓ１−ＡＰ）を生成する。アプリケーション識別子は、ソースノード内で現在アクティブである接続に一意である。すなわち、ソースノードは、それぞれが自らのアプリケーション識別子を有する複数の接続を処理する場合がある。

アプリケーション識別子は、接続の確立を要求する、初期接続要求メッセージと共に宛先ノードに送信される。それに応答して、宛先ノードは、応答メッセージを送信し、その接続を確立する。その応答メッセージは、ソースノードによって生成されるアプリケーション識別子（ｅＮＢ Ｓ１−ＡＰ）及び宛先ノードによって生成されるアプリケーション識別子の双方を含む。宛先ノードのためのアプリケーション識別子は、その宛先ノードが別のｅＮｏｄｅＢである場合にはターゲットｅＮｏｄｅＢ識別子（ｅＮＢ Ｓ１−ＡＰ）の形をとることができ、又はその宛先ノードがＭＭＥである場合にはＭＭＥ識別子（ＭＭＥ Ｓ１−ＡＰ）の形をとることができる。宛先ノードによって生成されるアプリケーション識別子は、宛先ノードにおいて現在アクティブである接続に一意である。すなわち、宛先ノードは、それぞれが自らのアプリケーション識別子を有する複数の接続を処理する場合がある。

アプリケーション識別子は、それらの識別子を生成するソースノード及び宛先ノード内で一意であるが、アプリケーション識別子は必ずしも、受信側構成要素における接続を一意に特定しないことが認識されている。たとえば、２つの新たに接続する移動デバイスのための２つの接続要求メッセージが、その２つの接続要求メッセージが偶然にも同じｅＮＢ Ｓ１−ＡＰ識別子を割り当てられている２つの異なるｅＮｏｄｅＢから１つのＭＭＥにおいて受信される場合には、これが問題となる場合がある。複数の要求に同じＭＭＥ Ｓ１−ＡＰ識別子を割り当てている２つの異なるＭＭＥから、Ｓ１−ＡＰハンドオーバ要求メッセージが１つのｅＮｏｄｅＢにおいて受信される場合にも、問題が生じる場合がある。同様に、複数の要求に同じソースＸＰ−ＡＰ識別子を偶然に割り当てている２つの他のｅＮｏｄｅＢ構成要素から、１つのｅＮｏｄｅＢ構成要素がＸ２−ＡＰハンドオーバ要求メッセージを受信する場合にも、問題が生じる場合がある。これらの状況及び関連する問題のさらに詳しい説明が以下に与えられる。

通信ネットワークにおいて適用することができる種々の頭字語は、当然、当業者には既知であるが、一般の読者の便宜を図るために用語辞典が添付される。当業者が効率的に理解できるようにするために、本発明をＵＴＲＡＮ（次世代ユニバーサル地上無線ネットワーク）システムとの関連で詳細に説明するが、識別子システムの原理は、他のシステム、たとえば、ｅＮｏｄｅＢ構成要素のような基地局構成要素が互いに又は通信ネットワーク内のゲートウェイデバイスのような他のデバイスと通信する３Ｇ ＣＤＭＡ（符号分割多元接続）又は他の無線システムであって、必要に応じて該システムの対応する構成要素が変更されている、システムにも適用することができる。また、本発明の方法及びシステムは、無線ローカルエリアネットワーク（ＷＬＡＮ）又は他のローカルネットワーク（ＬＡＮ）若しくはワイドエリアネットワーク（ＷＡＮ）において実現することもできる。

一態様によれば、本発明は、通信ネットワーク内のソースノードと宛先ノードとの間で実行される接続を確立するための方法であって、
前記ソースノード内の前記接続のためのソースアプリケーション識別子を生成すること、
前記ソースノードのためのソースノード識別子を取り出すこと、及び
前記ソースアプリケーション識別子及び前記ソースノード識別子を前記宛先ノードに送信することであって、それにより前記ソースノードと前記宛先ノードとの間に要求される前記接続のためのソース接続識別子を与え、送信することを含み、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、方法を提供する。

それゆえ、ソースノードと宛先ノードとの間の接続のための識別子は、アプリケーション識別子及びソースノードそのものの識別子の双方を含む。アプリケーション識別子は、ソースノード内の接続を一意に特定することができる。この識別子は、アプリケーション識別子生成器によって生成することができ、その識別子は、ソースノードからの接続を設定し、管理するアプリケーションに関連付けることができる。アプリケーション識別子は、ネットワーク内のノードが異なると一意でない場合があり、すなわち、接続を確立する２つのソースノードが、それぞれの接続との関連で同じアプリケーション識別子を用いる場合がある。ソースノードそのものに基づくさらなる識別子を追加することによって、その新たな接続を、そのネットワーク内の他のノードによって確立されている他の接続と区別することができる。ソースノード識別子は、ソースノードに格納され、メモリから取り出される場合があるか、又はその識別子は、ソース接続識別子に組み込まれる前に生成される場合がある。

ネットワーク内のソースノードと宛先ノードとの間の接続は「コンテキスト」と呼ばれる場合もあり、接続識別子は「コンテキスト識別子」と呼ばれる場合もある。

一実施の形態では、本方法は、接続応答メッセージを受信することをさらに含むことができ、該応答メッセージは宛先接続識別子を含み、該宛先接続識別子は、宛先ノード内の接続を特定する宛先アプリケーション識別子と、宛先ノード識別子とを含む。

いくつかの実施態様においては、接続要求メッセージにおいてソースノードの識別子を与えることで十分であると考えることができる。

ソースノード識別子は、移動通信ネットワーク内、たとえば、単一の公衆陸上移動通信網（ＰＬＭＮ）ネットワーク内で一意である場合があるか、又はソースノード識別子は、グローバルに一意である場合がある。一実施の形態では、ソースノード識別子は、ソースネットワークの少なくとも一部の識別子（たとえば、ソースノードが動作しているＰＬＭＮネットワークの識別子）と、ソースネットワークの少なくとも一部の中にあるソースノードの識別子（たとえば、そのＰＬＭＮネットワーク内で一意であるソースノードの識別子）とを含むことができる。

説明される方法は、移動ネットワーク内の複数の異なるタイプの構成要素間で、また種々の異なるインターフェースを介して実施することができることは当業者には明らかであろう。しかしながら、特定の実施の形態では、ソース及び／又は宛先ノードは、基地局、たとえばｅＮｏｄｅＢ構成要素を含む場合がある。ソース及び／又は宛先構成要素は、ＭＭＥ構成要素のようなゲートウェイノードを含んでもよい。特定の接続の場合のソース及び宛先構成要素に応じて、その接続をＳ１又はＸ２インターフェースを介して確立することができる。

別の態様によれば、本発明は、通信ネットワークを含む装置であって、該ネットワークは複数のノードを含み、接続要求メッセージを用いて、該通信ネットワーク内の２つのノード間に接続を確立することができ、該ネットワークは、
該通信ネットワーク内の宛先ノードへの接続を開始するためのソースノードを含み、該ソースノードは、
ソースアプリケーション識別子を生成する手段と、
ソースノード識別子を格納する手段と、
ソースアプリケーション識別子及びソースノード識別子を宛先ノードに送信する送信手段であって、ソースノードと該宛先ノードとの間に要求される接続のためのソース接続識別子を与える、送信手段とを備え、
ネットワークは宛先ノードをさらに含み、該宛先ノードは、
ソースノードからソースアプリケーション識別子及びソースノード識別子を受信する受信手段であって、ソースノードと該宛先ノードとの間に要求される接続のためのソース接続識別子を形成する、受信手段と、
接続応答メッセージを生成する手段と、
通信ネットワークを介して前記接続応答メッセージをソースノードに送信する手段と、を備え、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置を提供する。

別の態様によれば、本発明は、通信ネットワークの宛先ノードへの接続を開始するためのソースノードを含む装置であって、該ソースノードは、
ソースアプリケーション識別子を生成する手段と、
ソースノード識別子を格納する手段と、
ソースアプリケーション識別子及びソースノード識別子を宛先ノードに送信する送信手段であって、ソースノードと宛先ノードとの間に要求される接続のためのソース接続識別子を与える、送信手段と、を備え、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置を提供する。

別の態様によれば、本発明は、通信ネットワークのソースノードからの接続を終端するための宛先ノードを含む装置であって、該宛先ノードは、
ソースアプリケーション識別子及びソースノード識別子を受信する受信手段であって、ソースノードと該宛先ノードとの間に要求される接続のためのソース接続識別子を形成する、受信手段と、
接続応答メッセージを生成する手段と、
該接続応答メッセージをソースノードに送信する手段と、を備え、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置を提供する。

さらなる一態様によれば、本発明は、通信ネットワーク内の宛先ノードにおいてソースノードからの接続を確立する方法であって、
ソースノードから接続要求メッセージを受信することを含み、該接続要求メッセージはネットワークにおいて用いられる或る範囲のアプリケーション識別子から選択される１つのアプリケーション識別子を含み、
該方法はさらに、
通信ネットワーク内の接続を特定するためのソースノード識別子を格納すること、
選択されたアプリケーション識別子を組み込む接続確立応答メッセージを生成すること、及び
前記接続確立応答メッセージをソースノードに送信することを含み、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、方法を提供する。

本方法の好ましい実施の形態は、通信ネットワークのためのネットワーク識別子を規定することを含むことができ、接続確立要求メッセージはネットワーク識別子をさらに含む。

本方法は、以前に確立された接続が依然としてノードにおいてアクティブである場合に特に、以前に確立された接続のためにどのアプリケーション識別子が用いられているかをモニタすること、及び新たな接続を確立するためにそれらのアプリケーション識別子を使用するのを避けることをさらに含むことができる。アプリケーション識別子は、利用可能なアプリケーション識別子のリスト内の識別子を順番に繰り返すことによって、又は接続のために現時点で使用中でない任意の識別子を選択することによって選択することができる。

さらなる一態様によれば、接続要求メッセージを送信することによって通信ネットワーク内のソースノードと宛先ノードとの間に接続を確立するための方法であって、接続要求メッセージはソースノード内の接続のためのソースアプリケーション識別子を有し、
メッセージは、ソースノードのためのソースノード識別子をさらに含み、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、方法が提供される。

さらなる一態様によれば、接続要求メッセージを送信することによって通信ネットワーク内のソースノードと宛先ノードとの間に接続を確立するためのシステムであって、メッセージはソースノード内の接続のためのソースアプリケーション識別子を有し、
前記メッセージは、ソースノードのためのソースノード識別子をさらに含み、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、システムが提供される。

さらなる一態様によれば、接続要求メッセージを受信することによって、通信ネットワーク内で宛先ノードにおいてソースノードからの接続を確立するための方法であって、メッセージはソースノード内の接続のためのソースアプリケーション識別子を有し、
前記メッセージは、ソースノードのためのソースノード識別子をさらに含み、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、方法が提供される。

さらなる一態様によれば、接続要求メッセージを受信することによって、通信ネットワーク内で宛先ノードにおいてソースノードからの接続を確立するためのシステムであって、メッセージはソースノード内の接続のためのソースアプリケーション識別子を有し、
前記メッセージは、ソースノードのためのソースノード識別子をさらに含み、
前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、システムが提供される。

上記の２つの態様は、第２のソースノードから第２の接続要求メッセージを受信することをさらに含むことができ、該第２の接続要求メッセージは第２のソースアプリケーション識別子を有し、該第２の接続要求メッセージは、第２のソースノードのための第２のソースノード識別子をさらに含み、ソースノードのためのソースノード識別子及び第２のソースノードのための第２のソースノード識別子は互いに異なる。

上記の２つの態様の一実施の形態では、ソースノード及び第２のソースノードはそれぞれｅＮｏｄｅＢを含み、宛先ノードはＭＭＥを含む。

上記の２つの態様の第２の実施の形態では、ソースノード及び第２のソースノードはそれぞれＭＭＥを含み、宛先ノードはｅＮｏｄｅＢを含む。

上記の２つの態様の第３の実施の形態では、ソースノード、第２のソースノード及び宛先ノードはそれぞれｅＮｏｄｅＢを含む。

本発明の態様が独立請求項において詳述されている。それらの態様の好ましい特徴が従属請求項において詳述されている。本発明は、開示される全ての方法に対して、対応する装置上で実行するための対応するコンピュータプログラム又はコンピュータプログラム製品と、装置そのもの（ユーザ装置、ノード、ネットワーク又はその構成要素）と、その装置を構成し、更新する方法とを提供する。１つの態様の特徴は、他の態様にも当てはまることができる。

ここで、一例として、添付の図面を参照しながら、本発明の一実施形態を説明する。

本発明の実施形態を適用することができるタイプの移動通信システムを示す概略図である。 図１に示されるシステムの一部を形成する基地局を示す概略図である。 図１に示されるシステムの一部を形成するゲートウェイデバイスを示す概略図である。 ｅＮｏｄｅＢとＭＭＥ構成要素との間の接続の確立を示す概略図である。 ２つのｅＮｏｄｅＢ間の接続の確立を示す概略図である。 従来技術のシステムにおいて生じる場合がある、起こり得る誤り状況を示す概略図である。 従来技術のシステムにおいて生じる場合がある、第２の起こり得る誤り状況を示す概略図である。 従来技術のシステムにおいて生じる場合がある、第３の起こり得る誤り状況を示す概略図である。 一実施形態による、ｅＮｏｄｅＢからＭＭＥへの最初のメッセージの概略図である。 一実施形態による、ＭＭＥからｅＮｏｄｅＢへの最初のメッセージの概略図である。

概説
以下の説明は、本明細書において請求される方法及びシステムの複数の具体的な実施形態を詳述する。それらの特徴及び方法ステップの変形形態を与えることができること、及び説明される特徴のうちの多くが本発明にとって不可欠ではないことは当業者には明らかであり、本発明の範囲は特許請求の範囲によって規定される。

図１は、移動（セルラー）通信システム１を概略的に示しており、そのシステムでは、移動（又はセルラー）電話（ＭＴ）３−０、３−１及び３−２のユーザが、基地局５−１又は５−２の一方及び電話網７を介して、他のユーザ（図示せず）と通信することができる。電話網７は、ゲートウェイ構成要素９−１、９−２を含む複数の構成要素を含む。各基地局５−１、５−２がいずれかのゲートウェイ９−１、９−２を介して電話網７に接続する場合があること、及び双方の基地局５−１、５−２が同じゲートウェイ９−１、９−２を介して接続する場合があることは当業者には理解されよう。同様に、各移動電話３はいずれかの基地局５を介して電話網７に接続する場合があり、双方の移動電話３が同じ基地局５を介して接続する場合もある。

この実施形態では、基地局５は、移動電話３に送信されるデータが複数のサブキャリア上に変調される直交周波数分割多元接続（ＯＦＤＭＡ）技法を使用する。既知の他のデータ伝送技法を用いることもできる。移動電話３が、たとえば、電源を入れることによってネットワーク７に入ると、移動電話３と基地局５との間に、且つ基地局５とゲートウェイ９との間に接続が確立される。これにより、移動電話３とネットワーク７内の他の構成要素との間での通信ができるようになる。

また、移動電話３がソース基地局（たとえば、基地局５−１）のセルから、ターゲット基地局（たとえば、基地局５−２）に移動すると、ソース基地局及びターゲット基地局５において、且つ移動電話３においてハンドオーバ手順（プロトコル）が実行され、ハンドオーバ過程が制御される。ハンドオーバは、ソース基地局とターゲット基地局５との間に接続を確立することによって実施できるようになる。ハンドオーバ過程の一部として、移動電話３からの通信が電話網に送信されるために経由するゲートウェイデバイス９−１、９−２が変化する場合がある。代替的には、通信が送信されるために経由するゲートウェイデバイス９−１、９−２は同じままであり得るが、移動デバイスが接続される基地局５−１、５−２が変化する場合がある。これらの移行は、基地局５とゲートウェイ９との間の接続の確立によっても実施できるようになる。

基地局
図２は、この実施形態において用いられる各基地局５の主要構成要素を示すブロック図である。図に示されるように、各基地局５は、トランシーバ回路２１を含み、トランシーバ回路２１は、１つ又は複数のアンテナ２３を介して、移動電話３に対し信号を送受信するように動作することができ、且つネットワークインターフェース２５を介して、電話網７に対し信号を送受信するように動作することができる。ネットワークインターフェース２５は、Ｓ１プロトコルを用いて、ゲートウェイノードのようなネットワーク構成要素と通信するためのＳ１ネットワークインターフェースを含む。ネットワークインターフェース２５は、Ｘ２プロトコルを用いて、他の基地局構成要素と通信するためのＸ２インターフェースも備える。コントローラ２７は、メモリ２９に格納されるソフトウエアに従って、トランシーバ回路２１の動作を制御する。そのソフトウエアは、中でも、オペレーティングシステム３１、アプリケーション識別子生成器３３及び接続識別子生成器３５を含み、接続識別子生成器はコンテキスト識別子生成器と呼ばれる場合もある。メモリ２９はノード識別子３４を格納し、実施形態によっては、基地局が関連付けられるネットワークのためのネットワーク識別子も格納する。アプリケーション識別子生成器３３及び接続識別子生成器３５の動作は後に説明する。

ゲートウェイ
図３は、この実施形態において用いられる各ゲートウェイ構成要素９の主要構成要素を示すブロック図である。図に示されるように、各ゲートウェイ９は、トランシーバ回路４１を備えており、トランシーバ回路４１は、基地局インターフェース４３を介して、少なくとも１つの基地局５に対し信号を送受信するように動作することができ、且つネットワークインターフェース４５を介して、電話網７の他の部分に対し信号を送受信するように動作することができる。コントローラ４７は、メモリ４９に格納されるソフトウエアに従って、トランシーバ回路４１の動作を制御する。そのソフトウエアは、中でも、オペレーティングシステム５１、アプリケーション識別子生成器５３及び接続識別子生成器５５を含み、接続識別子生成器はコンテキスト識別子生成器と呼ばれる場合もある。メモリ４９はノード識別子５４を格納し、実施形態によっては、基地局が関連付けられるネットワークのためのネットワーク識別子も格納する。アプリケーション識別子生成器５３及び接続識別子生成器５５の動作は後に説明する。

上記の説明では、理解を容易にするために、基地局５及びゲートウェイ９がいずれも、本明細書において記述される方法に従って動作するそれぞれ個別のモジュールを有するように説明される。このようにして、或る特定の応用形態、たとえば、本発明を実施するように既存のシステムが変更された場合の種々の特徴が与えられる場合があるが、他の応用形態、たとえば、始めから本発明の特徴に留意して設計されるシステムでは、これらの特徴は、全体のオペレーティングシステム又はコードに組み込まれる場合があるので、上記のモジュールは、個別のエンティティとして区別されない場合がある。

以下の説明は、ＵＴＲＡＮのロングタームエボリューション（ＬＴＥ）において用いられる用語を用いる。それゆえ、移動電話３はＵＥと呼ばれることになり、各基地局５はｅＮｏｄｅＢ（又はｅＮＢ）と呼ばれることになり、各ゲートウェイ構成要素はＭＭＥと呼ばれることになる。ＬＴＥにおいて用いられるプロトコルエンティティは、ＬＴＥでは外部ＡＲＱ（自動再送要求）エンティティと呼ばれる無線リンク制御（ＲＬＣ）エンティティを除いて、ＵＭＴＳ（ユニバーサル移動通信システム）において用いられるのと同じ名称を有する。ＬＴＥの外部ＡＲＱエンティティは、ＵＭＴＳのＲＬＣエンティティと（全く同じではないが）概ね同じ機能を有する。

誤りのシナリオ
上記で詳述されたように、従来技術のシステムでは、コンテキスト確立要求メッセージと共に送信されるアプリケーション識別子は必ずしも、受信側構成要素においてコンテキストを一意に特定しない。この実施形態においてコンテキスト設定メッセージ内で送信される識別子の詳細を後に与える。しかしながら、最初に、問題が生じる場合がある状況の例をより詳細に検討する。

ストリーム制御伝送プロトコル（ＳＣＴＰ）接続のようなトランスポートプロトコル接続は、異なるＵＥに関連する信号を搬送することができる。受信側ノード内の正しいＵＥコンテキストマネージャの内部にシグナリングを転送するために、Ｓ１又はＸ２アプリケーション（ＡＰ）メッセージ内に、アプリケーションルーティング情報が含まれる。これは、図４ａ及び図４ｂを参照しながら、後にさらに説明及び例示する。

暗示的に要求する場合もあるが、送信側ノードが、たとえば、Ｓ１−ＡＰ初期ＵＥメッセージを送信することによって、或る特定のＵＥのための専用Ｓ１／Ｘ２シグナリング接続の確立を要求するとき、そのノードは、Ｓ１／Ｘ２インターフェース上のピアノードに、そのＵＥのためにそのノードが割り当てたアプリケーション（ＡＰ）識別子を通知する。ｅＮｏｄｅＢ６１とＭＭＥ６３との間の接続の場合、このメッセージは、図４ａに示されるように「ｅＮＢ Ｓ１−ＡＰ」６５の形をとり、それは、「ｅＮＢ Ｓ１−ＡＰ ＵＥ ＩＤ」と書くこともできる。１つのｅＮｏｄｅＢ６９からピアｅＮｏｄｅＢ７１への転送の場合、そのメッセージは、図４ｂに示されるように、「ソースｅＮＢ Ｓ１−ＡＰ」７３の形である。その際、ピアノードの応答メッセージは、発信元ノード及びピアノード双方のＳ１／Ｘ２アプリケーション識別子、たとえば、「ｅＮＢ Ｓ１−ＡＰ ＵＥ ＩＤ、ＭＭＥ Ｓ１−ＡＰ ＵＥ ＩＤ」と書くこともできる、図４ａに示されるような「ｅＮＢ Ｓ１−ＡＰ、ＭＭＥ Ｓ１−ＡＰ」６７を含むか、又は図４ｂに示される事例では、「ソースｅＮＢ Ｓ１−ＡＰ、ターゲットｅＮＢ Ｓ１−ＡＰ」７５を含む。

Ｓ１及びＸ２インターフェースにおいて用いられるアプリケーション識別子についてのさらなる詳細を以下に与える。

ｅＮｏｄｅＢ Ｓ１−ＡＰ ＵＥ識別情報（identity）
ｅＮｏｄｅＢ Ｓ１−ＡＰ ＵＥ識別情報６５は、ｅＮｏｄｅＢ６１内のＳ１インターフェースを介してＵＥを一意に特定するために割り当てられる。ＭＭＥ６３がｅＮｏｄｅＢ Ｓ１−ＡＰ ＵＥ識別情報６５を受信するとき、ＭＭＥ６３は、このＵＥのためのＵＥ関連論理Ｓ１接続の持続時間にわたって、その識別情報を格納する。ＭＭＥ６３に知られると、この識別情報（ＩＥ）は、全てのＵＥ関連のＳ１−ＡＰシグナリング（アップリンク（ＵＬ）及びダウンリンク（ＤＬ））に含まれることができる。

ＭＭＥ Ｓ１−ＡＰ ＵＥ ＩＤ
ＭＭＥ Ｓ１−ＡＰ ＵＥ識別情報６７は、ＭＭＥ６３内のＳ１インターフェースを介してＵＥを一意に特定するために割り当てられる。ｅＮｏｄｅＢ６１がＭＭＥ Ｓ１−ＡＰ ＵＥ識別情報を受信するとき、ｅＮｏｄｅＢ６１は、このＵＥのためのＵＥ関連論理Ｓ１接続の持続時間にわたって、その識別情報を格納する。ｅＮｏｄｅＢ６１に知られると、このＩＥは、全てのＵＥ関連のＳ１−ＡＰシグナリング（ＵＬ及びＤＬ）に含まれることができる。

ソースｅＮｏｄｅＢ ＵＥコンテキストＩＤ
ソースｅＮｏｄｅＢ ＵＥコンテキストＩＤ（ソースｅＮＢ Ｓ１−ＡＰ）７３は、ソースｅＮｏｄｅＢ６９に伴うＸ２インターフェースを介して、ＵＥを一意に特定するために割り当てられる。ターゲットｅＮｏｄｅＢ７１がソースｅＮｏｄｅＢコンテキストＩＤを受信するとき、ターゲットｅＮｏｄｅＢ７１は、そのＵＥのためのコンテキストの持続時間にわたって、そのＩＤを格納する。ターゲットｅＮｏｄｅＢ７１に知られると、そのＩＥは全てのＵＥ関連Ｘ２−ＡＰシグナリングに含まれることができる。

ターゲットｅＮｏｄｅＢ ＵＥコンテキストＩＤ
ターゲットｅＮｏｄｅＢ ＵＥコンテキストＩＤ（ターゲットｅＮＢ Ｓ１−ＡＰ）７５は、ターゲットｅＮｏｄｅＢ７１に伴うＸ２インターフェースを介して、ＵＥを一意に特定するために割り当てられる。ソースｅＮｏｄｅＢ６９がターゲットｅＮｏｄｅＢコンテキストＩＤを受信するとき、ソースｅＮｏｄｅＢ６９は、そのＵＥのためのコンテキストの持続時間にわたって、そのＩＤを格納する。ソースｅＮｏｄｅＢ６９に知られると、そのＩＥは全てのＵＥ関連Ｘ２−ＡＰシグナリングに含まれることができる。

それゆえ、上記で詳述されたように、先行する実施形態では、アプリケーション識別子（ＡＰ ＩＤ）は生成側ノードにおいて一意である。結果として、それらの識別子は、受信側ピアノードが最初のメッセージを受信するときに（すなわち、シグナリング接続が存在する前に）、そのピアノードにおいて一意に特定されない場合がある。アプリケーション識別子が受信側ノードにおいて一意でない場合に起こり得る誤りの状況を示すいくつかのシナリオを以下に説明する。

いくつかの状況では、１つのノードが、発信元ノードから、同じＳ１／Ｘ２アプリケーション識別子を含む、Ｓ１又はＸ２接続の確立をトリガするための２つのメッセージを受信することに起因して誤りが生じる。

図５を参照しながら、第１の誤りの状況を説明する。図５では、２つのｅＮｏｄｅＢ７７、７９が同じＭＭＥ８１に接続される。ＭＭＥ８１は、２つのＳ１−ＡＰ初期ＵＥメッセージを受信し、そのメッセージによって、２つのＳ１接続の確立がトリガされることになる。しかしながら、２つのｅＮｏｄｅＢ７７、７９は偶然にも、そのメッセージに同じｅＮＢ Ｓ１−ＡＰ ＵＥ識別情報を割り当てた。ＭＭＥ８１内のアプリケーション層は、２つのメッセージを区別することができないので、誤りを引き起こす。その際、システムによって誤り処理が図られ、結果として、確立されている接続に遅れが生じる場合があるか、又は少なくとも一方の接続を確立し損なうおそれがある。

第２の起こり得る誤りの状況が図６に示されており、図６はフレックス（flex）のシナリオを概略的に示す。ｅＮｏｄｅＢ８３は、ＭＭＥが関与しているＬＴＥ内ハンドオーバ中に、ＭＭＥ１ ８５及びＭＭＥ２ ８７によってそれぞれサービスを受けるＵＥ１ ８９及びＵＥ２ ９１の双方にとってのターゲットである。ハンドオーバ過程中に、ＭＭＥ１ ８５はターゲットｅＮｏｄｅＢ８３にＳ１−ＡＰハンドオーバ要求メッセージを送信する。ターゲットｅＮｏｄｅＢ８３は、２つのＭＭＥ８５、８７から、同じＭＭＥ Ｓ１−ＡＰ ＵＥ識別情報を含む２つのＳ１−ＡＰハンドオーバ要求メッセージを受信する場合がある。ターゲットｅＮｏｄｅＢ８３内のアプリケーション層は、２つのメッセージを区別することができないので、誤りを引き起こす。その際、誤り処理が実行され、それにより、上記のように、遅延及び通信の問題が生じるおそれがある。

Ｓ１ハンドオーバ要求肯定応答が受信される前に、Ｓ１ハンドオーバ取消メッセージが送信される場合に、図６に示される状況においてさらなる問題が生じる。この状況では、ターゲットｅＮｏｄｅＢ８３は、どの資源を解放すべきかがわからない。

第３の起こり得る誤りの状況が図７に示されており、図７は、ＭＭＥが関与しないＬＴＥ内移動性を示す。この状況では、ｅＮｏｄｅＢ２ ９９は、ｅＮｏｄｅＢ１ ９７によってトリガされるＬＴＥ内ハンドオーバのためのターゲットｅＮｏｄｅＢであり、且つｅＮｏｄｅＢ３ ９３によってトリガされるＬＴＥ内ハンドオーバのためのターゲットｅＮｏｄｅＢである。結果として、ｅＮｏｄｅＢ２ ９９は、ｅＮｏｄｅＢ１ ９７及びｅＮｏｄｅＢ３ ９３から、偶然にも同じソースｅＮｏｄｅＢ ＵＥコンテキストＩＤを用いる２つのＸ２ハンドオーバ要求メッセージを受信する。ターゲットｅＮｏｄｅＢ２ ９９内のアプリケーション層は、２つのメッセージを混同する場合があり、２つのメッセージを区別することができない。その際、誤り処理が実行され、その状況が解決される。

ｅＮｏｄｅＢ２ ９９が元のハンドオーバ要求に応答できる前に、ｅＮｏｄｅＢ１ ９７又はｅＮｏｄｅＢ３ ９３からハンドオーバ取消要求が受信される場合には、図７に示される状況においてさらなる問題も生じる。この場合、ｅＮｏｄｅＢ２ ９９は、どの資源が解放されるべきであるかがわからない。

動作
上記で詳述されたような状況を回避するために、接続要求メッセージをさらに識別することが有用であることが認識されている。これは、Ｓ１及びＸ２インターフェースが別々のアプリケーション識別子を使用できるようにすることによって実現される。これは複数の異なる方法において達成される場合があり、これらの方法を後に要約し、さらに詳細に説明する。

一実施形態では、関連するＳ１／Ｘ２−ＡＰメッセージに新たなノード識別子が追加される。そのノード識別子は、ソースｅＮｏｄｅＢ又はＭＭＥを特定することができる。この実施形態では、ノード識別子は、接続確立が要求される最初のメッセージにおいてのみ用いられる。ノード識別子は、応答メッセージ及び後続のメッセージの場合には不要であり、それらのメッセージは、再びアプリケーション識別子のみを交換し始める。これにより、後続のメッセージにおいて搬送される必要がある情報（ビット）量が低減される。この実施態様が、図８ａ及び図８ｂにおいて概略的に示される。図８ａは、ｅＮＢ Ｓ１−ＡＰ ＵＥ ｉｄ及びｅＮＢグローバルｉｄの双方を含む、ｅＮｏｄｅＢからＭＭＥへの最初のメッセージを示す。図８ｂは、ＭＭＥ Ｓ１−ＡＰ ＵＥ ｉｄ及びＭＭＥグローバルｉｄの双方を含む、ＭＭＥからｅＮｏｄｅＢへの最初のメッセージを示す。それゆえ、ｅＮｏｄｅＢ又はＭＭＥのための識別子を表すために、初期Ｓ１−ＡＰメッセージにおいて所定のビット数が予約される。

代替の実施形態では、ノード識別子は、ｅＮＢ／ＭＭＥ Ｓ１−ＡＰ識別子ＩＥ内部に埋め込まれる。すなわち、接続要求メッセージは単一の識別子を含むが、その識別子は、ソースノードを特定するのに十分な情報、及びソースノード内の接続を特定するための情報の双方を組み込む。

さらなる実施形態では、或る論理識別子を表す新たなＩＥが追加され、その論理識別子は、既知の関数を用いて、そのノードのためのＩＰアドレス又はＳＣＴＰポートのような、そのノードのためのトランスポート層（ＴＮＬ）識別子に関連付けられる。たとえば、各ｅＮｏｄｅＢは異なるＩＰアドレスを有することになるので、これを用いて、ソースノード識別子を導出することができる。一般的な実施態様では、ＴＮＬはアプリケーションプロトコルにソースＩＰアドレスを通知しないので、アプリケーションプロトコルは、アプリケーションメッセージそのものにおいて指示されるまで、送信者ＩＤを知り得ないことにさらに留意されたい。これは、ＴＮＬ及びＲＮＬが独立して実装されるべきであるというＵＭＴＳの概念から生じる。

さらなる実施態様では、１つのｅＮｏｄｅＢ又はＭＭＥが割り当てることができるＳ１／Ｘ２−ＡＰ識別子の範囲は、２つのノードのための識別子範囲が重ならないように制限される。これは、たとえば、運用前の段階においてｅＮｏｄｅＢ又はＭＭＥ毎に異なる識別子範囲を構成することによって果たすことができる。その後、各ノードが、接続を確立するときに、その所定の識別子範囲を順番に繰り返す。この解決策によって、１つのネットワーク内の各ノードから、一意のアプリケーション識別子を与えることができるようになる。複数のネットワークが用いられるいくつかの実施態様では、そのネットワークを特定するために、さらなるネットワーク識別子（ＰＬＭＮ ＩＤなど）が必要とされる場合もある。これは、アプリケーション識別子に埋め込まれるか、又は別個の識別子として与えることができる。

上記の実施形態のいずれかによるシステムの実施態様が、上記で詳述された誤りの状況を解決する。

図５において例示された第１の誤りの状況では、ｅＮｏｄｅＢ１ ７７及びｅＮｏｄｅＢ２ ７９からの各Ｓ１−ＡＰ初期ＵＥメッセージにｅＮｏｄｅＢ識別子を追加するか、又は組み込むことによって、ＭＭＥにおいて受信される接続要求毎に一意の識別子が与えられ、それゆえ、ＭＭＥが、ｅＮＢ Ｓ１−ＡＰ ＵＥ ｉｄとＭＭＥ Ｓ１−ＡＰ ＵＥ ｉｄとの間の一対一マッピングを与えることができるようになる。

同様に、図６との関連で説明される第２の誤りの状況では、ＭＭＥ１ ８５及びＭＭＥ２ ８７からの各ＭＭＥ Ｓ１−ＡＰ ＵＥ識別子にＭＭＥ識別子を追加するか、又は組み込むことによって、ｅＮｏｄｅＢ８３において、ＭＭＥメッセージ（それゆえ、発信元のＭＭＥ）が一意に特定される。さらに、ハンドオーバ要求が取り消される場合には、ＭＭＥが初期メッセージにおいて一意に特定されるので、ｅＮｏｄｅＢ８３は、どの資源を解放すべきかがわかり、他の接続の確立に影響を及ぼすことなく、接続を取り消すことができるようになる。

最後に、図７との関連で説明される第３の誤りの状況では、ｅＮｏｄｅＢ１及びｅＮｏｄｅＢ３は、ソースｅＮｏｄｅＢ識別子を含むＸ２−ＡＰハンドオーバ要求を送信する。それゆえ、ｅＮｏｄｅＢ２は、２つのソースノードをそれぞれ一意に特定することができ、ハンドオーバ要求が取り消される場合には、どの資源を解放すべきであるかがわかる。

一実施形態では、図７との関連で説明される第３の状況において、ハンドオーバ要求メッセージはＭＭＥ Ｓ１−ＡＰ ＵＥ識別子も含み、その識別子は、Ｓ１シグナリング接続のためのＭＭＥ構成要素の識別子を含む。これにより、ＭＭＥ Ｓ１−ＡＰ ＵＥ識別子に注目することによって、ターゲットｅＮｏｄｅＢ２ ９９がＭＭＥとやりとりできるようになる。

接続設定メッセージに組み込まれるノード識別子はグローバルに一意である場合があるか、又はそのノードが動作する電話網内、たとえば、そのノードのＰＬＭＮネットワーク内でのみ一意である場合がある。一実施形態では、ノードＩＤ（ＰＬＭＮ内で一意）及びＰＬＭＮ識別子の双方を利用することによって、グローバルノード識別子を与えることができる。これにより、ＲＡＮ共有のシナリオにおいても、各Ｓ１／Ｘ２ ＡＰを一意にできるようになる。

その接続のためのアプリケーション識別子は、初期接続設定メッセージと共に送信される。後続のメッセージ内のオーバーヘッドを低減するために、その接続内で後に送信されるメッセージのうちの少なくともいくつかから、ノード識別子を省くことができる。

上記のように、移動通信ネットワーク内の接続の確立は、新たな移動デバイス（ＵＥ）がネットワークに入るとき、たとえば、その移動デバイスが電源を入れられるときに生じる場合がある。移動デバイスがネットワーク内で移動するときにハンドオーバできるようにするために、新たな接続が確立される場合もある。さらに、ネットワークノード内の構成変更に起因して、たとえば、新たな基地局が追加されるか、又はＭＭＥが故障する場合に、接続が確立される場合もある。

アプリケーション識別子の生成は、或るアルゴリズムを用いてアプリケーション識別子を動的に生成する生成器モジュールを設けることによって果たすことができる。代替の実施形態では、アプリケーション識別子は、メモリ又はバッファから取り出すことができ、ノードは、順次接続する場合に一連の異なるアプリケーション識別子を順番に繰り返すことができる。

ノード識別子を求めるために、そのノードは単に、メモリ内のストレージから一定の識別子を取り出すことができる。代替的には、ノードは、ノード識別子を動的に生成する生成器モジュールから、その識別子を得ることができる。上記で詳述されたように、ノード識別子は、そのノードのためのＩＰアドレスのような、そのノードのためのトランスポート層識別子に基づくことができる。

一実施形態では、アプリケーション識別子及びノード識別子を用いて、接続識別子が生成される。さらなる実施形態では、接続識別子は、アプリケーション識別子及びネットワーク識別子を用いて生成される。第３の実施形態では、接続識別子は、アプリケーション識別子、ノード識別子及びネットワーク識別子を用いて生成される。識別子を連結して、単一の接続識別子を形成することができるか、又は或る関数を用いて、識別子を合成することができる。識別子を合成するために関数を用いることによって、識別子が連結される場合よりも接続識別子を短くすることができる。しかしながら、識別子を連結することによって、接続が確立されると、後続のメッセージから個々の識別子を除去できる場合がある。

３ＧＰＰ用語の用語集
ＬＴＥ − （ＵＴＲＡＮの）ロングタームエボリューション
ｅＮｏｄｅＢ − Ｅ−ＵＴＲＡＮノードＢ
ＡＧＷ − アクセスゲートウェイ
ＵＥ − ユーザ装置 − 移動通信デバイス
ＤＬ − ダウンリンク − 基地局から移動局へのリンク
ＵＬ − アップリンク − 移動局から基地局へのリンク
ＡＭ − 確認応答モード
ＵＭ − 非確認応答モード
ＭＭＥ − 移動管理エンティティ
ＵＰＥ − ユーザプレーンエンティティ
ＨＯ − ハンドオーバ
ＲＬＣ − 無線リンク制御
ＲＲＣ − 無線資源制御
ＲＲＭ − 無線資源管理
ＳＤＵ − サービスデータユニット
ＰＤＵ − プロトコルデータユニット
ＮＡＳ − 非アクセス階層（Non Access Stratum）
ＲＯＨＣ − ロバストヘッダ圧縮
ＴＡ − トラッキングエリア
Ｕプレーン − ユーザプレーン
ＴＮＬ − トランスポートネットワーク層
Ｓ１インターフェース − アクセスゲートウェイとｅＮｏｄｅＢとの間のインターフェース
Ｘ２インターフェース − ２つのｅＮｏｄｅＢの間のインターフェース
ＭＭＥ／ＳＡＥゲートウェイ − ＭＭＥエンティティ及びＵＰＥエンティティの双方を有するアクセスゲートウェイのための新規の名称

以下において、現在提案されている３ＧＰＰ ＬＴＥ標準規格において本発明を実施することができる方法を詳細に説明する。種々の特徴が不可欠であるか又は必要であるように説明されるが、これは、たとえばその標準規格によって課せられる他の要件に起因して、提案されている３ＧＰＰ ＬＴＥ標準規格の場合にのみ当てはまり得る。それゆえ、これらの記載は、決して本発明を制限するものと解釈されるべきではない。

タイトル：アプリケーションルーティングを支援する際にグローバルノードｉｄを使用すること
１ 目的
本稿の目的は、
・グローバルに一意でないＳ１／Ｘ２アプリケーション識別子によって引き起こされるいくつかの誤りのシナリオを強調し、
・この問題を克服するいくつかの解決策を提案することである。

２ 検討
２．１ 現状
ＳＣＴＰ接続が異なるＵＥに関連するシグナリングを搬送する。正しいＵＥコンテキストマネージャにシグナリングを内部で転送するために、Ｓ１／Ｘ２ ＡＰメッセージ内にアプリケーションルーティング情報が含まれなければならない。

送信側ノードが、たとえば、Ｓ１−ＡＰ初期ＵＥメッセージを送信することによって、或る特定のＵＥのための専用のＳ１／Ｘ２シグナリング接続の確立を暗示的に要求するときはいつでも、そのノードは、ピアノードに、そのノードがそのＵＥのために割り当てたＳ１／Ｘ２ ＡＰ識別子を通知する。

ピアノードの応答メッセージは、通常のシナリオでは、発信元ノード及びピアノードの双方のＳ１／Ｘ２アプリケーションｉｄを含む（図４ａ及び図４ｂを参照）。

以下のＳ１及びＸ２双方のインターフェースにおけるアプリケーション識別子の規定を参照されたい［１］。

ｅＮＢ Ｓ１−ＡＰ ＵＥ識別情報
ｅＮＢ Ｓ１−ＡＰ ＵＥ識別情報Ｄは、ｅＮＢ内のＳ１インターフェースを介してＵＥを一意に特定するように割り当てられるべきである。ＭＭＥがｅＮＢ Ｓ１−ＡＰ ＵＥ識別情報を受信するとき、そのＭＭＥは、このＵＥのためのＵＥ関連論理Ｓ１接続の持続時間にわたって、その識別情報を格納する。ＭＭＥに知られると、このＩＥは全てのＵＥ関連Ｓ１−ＡＰシグナリング（ＵＬ及びＤＬ）に含まれる。

ＭＭＥ Ｓ１−ＡＰ ＵＥ識別情報
ＭＭＥ Ｓ１−ＡＰ ＵＥ識別情報は、ＭＭＥ内のＳ１インターフェースを介してＵＥを一意に特定するように割り当てられるべきである。ｅＮＢがＭＭＥ Ｓ１−ＡＰ ＵＥ識別情報を受信するとき、そのｅＮＢは、このＵＥのためのＵＥ関連論理Ｓ１接続の持続時間にわたって、その識別情報を格納する。ｅＮＢに知られると、このＩＥは全てのＵＥ関連Ｓ１−ＡＰシグナリング（ＵＬ及びＤＬ）に含まれる。

ソースｅＮＢ ＵＥコンテキストＩＤ
ソースｅＮＢ ＵＥコンテキストＩＤは、ソースｅＮＢ内のＸ２インターフェースを介してＵＥを一意に特定するように割り当てられるべきである。ターゲットｅＮＢがソースｅＮＢ ＵＥコンテキストＩＤを受信するとき、そのターゲットｅＮＢは、このＵＥのためのコンテキストの持続時間にわたって、そのＩＤを格納する。ターゲットｅＮＢに知られると、このＩＥは全てのＵＥ関連Ｘ２−ＡＰシグナリングに含まれる。

ターゲットｅＮＢ ＵＥコンテキスト ＩＤ
ターゲットｅＮＢ ＵＥコンテキストＩＤは、ターゲットｅＮＢ内のＸ２インターフェースを介してＵＥを一意に特定するように割り当てられるべきである。ターゲットｅＮＢがターゲットｅＮＢ ＵＥコンテキストＩＤを受信するとき、そのターゲットｅＮＢは、このＵＥのためのコンテキストの持続時間にわたって、そのＩＤを格納する。ソースｅＮＢに知られると、このＩＥは全てのＵＥ関連Ｘ２−ＡＰシグナリングに含まれる。

厳密な規定はまだ合意に達していないが、これらのアプリケーション識別子が生成側ノード内で一意であることは３ＧＰＰグループの間で既知であるか／合意に達している。

上記の規定によれば、これらのＡＰ ｉｄは、生成側ノード内で一意である。結果として、受信側ピアノードが最初のメッセージを受信する（すなわち、シグナリング接続が存在しない）とき、いくつかのノード特有の識別子もそのメッセージ内に存在しない限り、受信側ピアノードにおいて、それらのＡＰ ｉｄは一意には特定されない。項目２．３において、アプリケーションｉｄがグローバルに一意でない場合に起こり得る誤りの状況を示す、いくつかのシナリオが説明される。

２．２ Ｔプレーン識別子
制御プレーンは、Ｓ１及びＸ２双方のインターフェースにおいて、ＳＣＴＰ ｏｖｅｒ ＩＰを利用するので、以下のＴＮＬ識別子が存在する。
ＳＣＴＰ層
・ソースポート番号、宛先ポート番号
・ＳＣＴＰストリームｉｄ
ＩＰ層
・ソース／宛先ＩＰアドレス

ＬＴＥでは、Ｓ１／Ｘ２インターフェース毎に１つのＳＣＴＰアソシエーションが存在することになり、共通手順のための一対のＳＣＴＰストリームがあり、数対のＳＣＴＰストリームが全てのＳ１／Ｘ２専用シグナリング接続によって共有される。

ソースＩＰアドレス、ＳＣＴＰ宛先ポート、及び場合によっては宛先ＩＰアドレスと共に、ＳＣＴＰソースポートを用いて、このパケットが属するアソシエーションが特定される。

結果として、ＳＣＴＰアソシエーションはノード識別子として用いることができる（ＳＣＴＰストリームｉｄはこの目的を果たすのに有用ではない）。

しかしながら、ＵＭＴＳ原理を踏まえて、ＲＮＬ及びＴＮＬをできる限り独立させておくために、且つ、たとえば、ブレード／ＳＷエンティティ通信の場合の任意の実施制約を回避するために、アプリケーションプロトコルの目的のためにＴＮＬ識別子（すなわち、ＳＣＴＰアソシエーション）を使用しないことが提案される。

２．３ 起こり得る誤り状況のシナリオ
この段落は、発信元ノードから同じＳ１／Ｘ２アプリケーション識別子を含む２つのメッセージ（Ｓ１／Ｘ２接続の確立をトリガする）を受信するピアノードにおいて誤りの状況に繋がる恐れがあるいくつかの起こり得るシナリオを列挙する。

１）図５において、２つのｅＮＢが同じＭＭＥに接続される。そのＭＭＥは、偶然にも同じｅＮＢ Ｓ１−ＡＰ ＵＥ識別情報を割り当てられた２つの異なるｅＮＢから、２つのＳ１−ＡＰ初期ＵＥメッセージ（Ｓ１接続の確立をトリガすることになる）を受信する。ＭＭＥ内のアプリケーション層は混同することになり、そのメッセージが発信元ノードに関連する情報を全く含まないので、２つのメッセージを区別することはできない。その際、その実施態様によれば、誤り処理が実行されることになる。これは、グローバルに一意であるＳ１−ＡＰ識別子を用いることによって避けることができる。

２）図６において、Ｓ１フレックスのシナリオが示される。そのｅＮＢは、ＭＭＥが関与しているＬＴＥ内ハンドオーバ中に、それぞれＭＭＥ１及びＭＭＥ２によってサービスを受けるＵＥ１及びＵＥ２の双方にとってのターゲットｅＮＢである。ハンドオーバ準備中に、そのＭＭＥはターゲットｅＮＢにＳ１−ＡＰ：ハンドオーバ要求メッセージを送信する。ターゲットｅＮＢは、２つの異なるＭＭＥから、同じＭＭＥ Ｓ１−ＡＰ ＵＥ識別情報を含む２つのＳ１−ＡＰ：ハンドオーバ要求メッセージを受信する場合がある。ターゲットｅＮＢ内のアプリケーション層は混同することになり、そのメッセージが発信元ノードに関連する情報を全く含まない場合、２つのメッセージを区別することはできない。その際、その実施態様によれば、誤り処理が実行されることになる。これは、グローバルに一意であるＳ１−ＡＰ識別子を用いることによって避けることができる。

３）図７において、ｅＮｏｄｅＢ２は、ｅＮＢ１によってトリガされるＬＴＥ内ハンドオーバ、及びｅＮＢ３によってトリガされるＬＴＥ内ハンドオーバのためのターゲットｅＮＢである。結果として、ｅＮＢ２は、ｅＮＢ１及びｅＮＢ３から、偶然にも同じソースｅＮＢ ＵＥコンテキストＩＤを割り当てられた２つのＸ２：ハンドオーバ要求メッセージを受信する場合がある。ターゲットｅＮＢ２内のアプリケーション層は混同することになり、そのメッセージが発信元ノードに関連する情報を全く含まないので、２つのメッセージを区別することはできない。その際、その実施態様によれば、誤り処理が実行されることになる。これは、グローバルに一意であるソースｅＮＢ ＵＥコンテキストＩＤ（すなわち、Ｘ２ ＡＰ識別子）を用いることによって避けることができる。

２．４ 提案
これらの誤りを導く状況を回避するために、Ｓ１及びＸ２双方のインターフェースにおいてグローバルに一意のアプリケーションｉｄを用いることが提案される。これは、種々の方法において達成することができる。

解決策１：
関連するＳ１／Ｘ２−ＡＰメッセージ内に新たなＩＥ、すなわちグローバルノードｉｄを追加する。

解決策２：
ｅＮＢ／ＭＭＥ Ｓ１−ＡＰ識別子ＩＥ内部にグローバルノードｉｄを埋め込む。

解決策３：
ＴＮＬ識別子（ＩＰアドレス／ＳＣＴＰポート）に何らかの形で（既知の関数を用いて）関連付けられる論理識別子を表す新たなＩＥを追加する。

解決策４：
２つの異なるノードの範囲が重ならないように（たとえば、運用前の状態においてｅＮＢ毎に異なる範囲を構成することにより）、１つのｅＮＢが割り当てることができるＳ１／Ｘ２ＡＰ識別子の範囲を制限する。しかしながら、この解決策では、１つのネットワーク内で一意のＡｐ−ｉｄを有することができるようになるだけである。結果として、ネットワーク識別子（すなわち、ＰＬＭＮｉｄ）が、ＡＰ−ｉｄ ＩＥ内に埋め込まれる必要があるか、又は別個のＩＥとして与えられる必要がある。別個のＩＥの場合、これは、接続確立をトリガするメッセージにおいてのみ必要とされる。

解決策１及び２は、グローバルノード識別子の概念を利用しており、それは、
ノードｉｄ（１つのＰＬＭＮ内で一意）及びＰＬＭＮ識別子（これは、ＲＡＮを共有するシナリオの場合であっても、Ｓ１／Ｘ２ ＡＰが一意であることを保証する）を利用することである。

最初の３つの解決策は、実施態様の複雑さにおいて異なる。ＮＥＣの選択は解決策１である。

解決策１の場合、最初のメッセージの場合にのみ、グローバルノードｉｄが必要とされる。応答メッセージの場合にも、後続のメッセージの場合にも、グローバルノードｉｄは不要である。

それゆえ、後続のメッセージにおいて搬送される必要がある情報の量／ビットは、解決策１を適用することによって削減することができる。

解決策４では、運用前の状態においてノード内でいくつかの構成が行なわれる必要がある。

３ 結論
本稿では、Ｓ１／Ｘ２−ＡＰ ｉｄがグローバルに一意でないことに起因して起こり得るいくつかの誤りのシナリオを指摘してきた。

この問題を克服するために４つの提案がなされてきた。すなわち：
・関連するＳ１／Ｘ２メッセージ内にグローバルノードｉｄ ＩＥを導入すること。
・Ｓ１−ＡＰ ｉｄ ＩＥ内にグローバルノードｉｄを埋め込むこと。
・ＴＮＬ識別子に関連する論理識別子を表す新たなＩＥを追加すること。
・ネットワーク識別子と組み合わせて、各ｅＮＢ内でＳ１−ＡＰ範囲を構成すること（別個のＩＥとして与えられるか、又はＡＰ ｉｄ ＩＥ内に埋め込まれる）。

一意のアプリケーションｉｄを有しないことの結果を検討し、項目２．４において列挙される提案のうちの１つに関して合意に達することが提案される。

その原理が受け入れられる場合には、ＮＥＣは、関連するＣＲを作成する際に利用可能である。

４ 参考文献
Ｒ３−０７１３４４「Discussion and proposal for the AP ID handling」（ＮＥＣ）

本出願は、２００７年８月１５日に出願の英国特許出願第０７１５９４０．３号に基づいており、その特許出願からの優先権の利益を主張し、その特許出願の開示は参照によりその全体が本明細書に援用される。

Claims (40)

1. 通信ネットワーク内のソースノードと宛先ノードとの間で実行される接続を確立するための方法であって、
   前記ソースノード内の前記接続のためのソースアプリケーション識別子を生成すること、
   前記ソースノードのためのソースノード識別子を取り出すこと、及び
   前記ソースアプリケーション識別子及び前記ソースノード識別子を前記宛先ノードに送信することであって、それにより前記ソースノードと前記宛先ノードとの間に要求される前記接続のためのソース接続識別子を与え、送信することを含み、
   前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、方法。
2. 前記方法は、宛先接続識別子を含む接続応答メッセージを受信することをさらに含み、
   前記宛先接続識別子は、前記宛先ノード内の前記接続のための宛先アプリケーション識別子と、宛先ノード識別子とを含む、請求項１に記載の方法。
3. 前記ソースノード識別子は前記通信ネットワーク内で一意である、請求項１又は２に記載の方法。
4. 前記ソースノード識別子はグローバルに一意である、請求項１〜３のいずれか一項に記載の方法。
5. 前記ソースノード識別子は、ソースネットワークの少なくとも一部の識別子と、該ソースネットワークの該少なくとも一部の中にある前記ソースノードの識別子とを含む、請求項１〜４のいずれか一項に記載の方法。
6. 前記ソース接続識別子は、前記ソースアプリケーション識別子の前に追加されるか、又は後に追加される前記ソースノード識別子を含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記ソース接続識別子は、前記ソースアプリケーション識別子を含み、該ソースアプリケーション識別子の中に前記ソースノード識別子が埋め込まれる、請求項１〜５のいずれか一項に記載の方法。
8. 前記ソースノード識別子は、前記ソースノードのためのトランスポート層識別子に基づく、請求項１〜７のいずれか一項に記載の方法。
9. 前記宛先ノード識別子は前記通信ネットワーク内で一意である、請求項２に記載の方法。
10. 前記宛先ノード識別子はグローバルに一意である、請求項２に記載の方法。
11. 前記宛先ノード識別子は、宛先ネットワークの識別子と、前記宛先ネットワーク内の前記宛先ノードの識別子とを含む、請求項２、９、１０のいずれか一項に記載の方法。
12. 前記宛先接続識別子は、前記宛先アプリケーション識別子の前に追加されるか、又は後に追加される前記宛先ノード識別子を含む、請求項２に記載の方法。
13. 前記宛先接続識別子は、前記宛先アプリケーション識別子を含み、該宛先アプリケーション識別子の中に前記宛先ノード識別子が埋め込まれる、請求項２に記載の方法。
14. 前記宛先ノード識別子は、前記宛先ノードのためのトランスポート層識別子に基づく、請求項２に記載の方法。
15. 前記ソースノード及び前記宛先ノードのうちの少なくとも一方は基地局を含む、請求項１〜１４のいずれか一項に記載の方法。
16. 前記ソースノード及び前記宛先ノードはそれぞれｅＮｏｄｅＢを含み、前記接続の確立はＸ２インターフェースを介して実行される、請求項１〜１５のいずれか一項に記載の方法。
17. 通信ネットワークを含む装置であって、該ネットワークは複数のノードを含み、接続要求メッセージを用いて、該通信ネットワーク内の２つのノード間に接続を確立することができ、該ネットワークは、
    該通信ネットワーク内の宛先ノードへの接続を開始するためのソースノードを含み、該ソースノードは、
    ソースアプリケーション識別子を生成する手段と、
    ソースノード識別子を格納する手段と、
    前記ソースアプリケーション識別子及び前記ソースノード識別子を前記宛先ノードに送信する手段であって、前記ソースノードと該宛先ノードとの間に要求される前記接続のためのソース接続識別子を与える、送信手段とを備え、
    前記ネットワークは宛先ノードをさらに含み、該宛先ノードは、
    前記ソースノードから前記ソースアプリケーション識別子及び前記ソースノード識別子を受信する手段であって、前記ソースノードと該宛先ノードとの間に要求される前記接続のためのソース接続識別子を形成する、受信手段と、
    接続応答メッセージを生成する手段と、
    該通信ネットワークを介して前記接続応答メッセージを前記ソースノードに送信する手段と、を備え、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置。
18. 通信ネットワークの宛先ノードへの接続を開始するためのソースノードを含む装置であって、該ソースノードは、
    ソースアプリケーション識別子を生成する手段と、
    ソースノード識別子を格納する手段と、
    前記ソースアプリケーション識別子及び前記ソースノード識別子を前記宛先ノードに送信する手段であって、前記ソースノードと前記宛先ノードとの間に要求される前記接続のためのソース接続識別子を与える、送信手段と、を備え、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置。
19. 接続応答メッセージを受信する手段をさらに備え、該接続応答メッセージは宛先接続識別子を含み、該宛先接続識別子は、前記宛先ノード内の接続のための宛先アプリケーション識別子と、宛先ノード識別子とを含む、請求項１８に記載の装置。
20. 通信ネットワークのソースノードからの接続を終端するための宛先ノードを含む装置であって、該宛先ノードは、
    ソースアプリケーション識別子及びソースノード識別子を受信する手段であって、前記ソースノードと該宛先ノードとの間に要求される前記接続のためのソース接続識別子を形成する、受信手段と、
    接続応答メッセージを生成する手段と、
    前記接続応答メッセージを前記ソースノードに送信する手段と、を備え、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置。
21. 前記接続応答メッセージは宛先接続識別子を含み、該宛先接続識別子は、前記宛先ノード内の接続のための宛先アプリケーション識別子と、宛先ノード識別子とを含む、請求項２０に記載の装置。
22. 前記ソースノード識別子は前記通信ネットワーク内で一意である、請求項１７〜２１のいずれか一項に記載の装置。
23. 前記ソースノード識別子はグローバルに一意である、請求項１７〜２２のいずれか一項に記載の装置。
24. 前記ソースノード識別子は、ソースネットワークの少なくとも一部の識別子と、該ソースネットワークの該少なくとも一部の中にある前記ソースノードの識別子とを含む、請求項１７〜２３のいずれか一項に記載の装置。
25. 前記ソースノード及び前記宛先ノードのうちの少なくとも一方は基地局を含む、請求項１７〜２４のいずれか一項に記載の装置。
26. 前記ソースノード及び前記宛先ノードはそれぞれｅＮｏｄｅＢを含み、前記接続の確立はＸ２インターフェースを介して実行される、請求項１７〜２５のいずれか一項に記載の装置。
27. プログラム可能なコンピュータデバイスに、請求項１〜１６のいずれか一項に記載の方法を実行させるためのコンピュータ実施可能命令を含むプログラム。
28. 通信ネットワークを含む装置であって、該ネットワークは複数のノードを含み、接続要求メッセージを用いて、該通信ネットワーク内の２つのノード間に接続を確立することができ、該ネットワークは、
    該通信ネットワーク内の宛先ノードへの接続を開始するためのソースノードを含み、該ソースノードはプログラム制御下で、
    ソースアプリケーション識別子を生成し、
    ソースノード識別子を格納し、
    前記ソースアプリケーション識別子及び前記ソースノード識別子を前記宛先ノードに送信して、前記ソースノードと該宛先ノードとの間に要求される前記接続のためのソース接続識別子を与えるように動作することができ、
    前記ネットワークは宛先ノードをさらに含み、該宛先ノードは、
    前記ソースノードから前記ソースアプリケーション識別子及び前記ソースノード識別子を受信して、前記ソースノードと該宛先ノードとの間に要求される前記接続のためのソース接続識別子を形成し、
    接続応答メッセージを生成し、
    該通信ネットワークを介して前記接続応答メッセージを前記ソースノードに送信するように動作することができ、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置。
29. 通信ネットワークの宛先ノードへの接続を開始するためのソースノードを含む装置であって、該ソースノードはプログラム制御下で、
    ソースアプリケーション識別子を生成し、
    ソースノード識別子を格納し、
    前記ソースアプリケーション識別子及び前記ソースノード識別子を前記宛先ノードに送信して、前記ソースノードと前記宛先ノードとの間に要求される前記接続のためのソース接続識別子を与えるように動作することができ、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置。
30. 通信ネットワークのソースノードからの接続を終端するための宛先ノードを含む装置であって、該宛先ノードはプログラム制御下で、
    ソースアプリケーション識別子及びソースノード識別子を受信して、前記ソースノードと該宛先ノードとの間に要求される前記接続のためのソース接続識別子を形成し、
    接続応答メッセージを生成し、
    前記接続応答メッセージを前記ソースノードに送信するように動作することができ、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、装置。
31. 通信ネットワーク内の宛先ノードにおいてソースノードからの接続を確立する方法であって、
    前記ソースノードから接続要求メッセージを受信することを含み、該接続要求メッセージは前記ネットワークにおいて用いられる或る範囲のアプリケーション識別子から選択される１つのアプリケーション識別子を含み、
    該方法はさらに、
    前記通信ネットワーク内の接続を特定するためのソースノード識別子を格納すること、
    前記選択されたアプリケーション識別子を組み込む接続確立応答メッセージを生成すること、及び
    前記接続確立応答メッセージを前記ソースノードに送信することを含み、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、方法。
32. 前記通信ネットワークのためのネットワーク識別子を規定することをさらに含み、前記接続確立要求メッセージ及び前記接続確立応答メッセージのうちの少なくとも一方は前記ネットワーク識別子をさらに組み込む、請求項３１に記載の方法。
33. 接続要求メッセージを送信することによって通信ネットワーク内のソースノードと宛先ノードとの間で実行される接続を確立するための方法であって、前記メッセージは前記ソースノード内の前記接続のためのソースアプリケーション識別子を有し、
    前記メッセージは、前記ソースノードのためのソースノード識別子をさらに含み、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、方法。
34. 接続要求メッセージを受信することによって、通信ネットワーク内で宛先ノードにおいてソースノードからの接続を確立するための方法であって、前記メッセージは前記ソースノード内の前記接続のためのソースアプリケーション識別子を有し、
    前記メッセージは、前記ソースノードのためのソースノード識別子をさらに含み、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、方法。
35. 前記方法は、第２のソースノードから第２のソースアプリケーション識別子を有する第２の接続要求メッセージを受信することをさらに含み、
    前記第２の接続要求メッセージは前記第２のソースノードのための第２のソースノード識別子をさらに含み、前記ソースノードのための前記ソースノード識別子及び前記第２のソースノードのための前記第２のソースノード識別子は互いに異なる、請求項３４に記載の方法。
36. 前記ソースノード、前記第２のソースノード及び前記宛先ノードはそれぞれｅＮｏｄｅＢを含む、請求項３５に記載の方法。
37. 接続要求メッセージを送信することによって通信ネットワーク内のソースノードと宛先ノードとの間に接続を確立するためのシステムであって、前記メッセージは前記ソースノード内の前記接続のためのソースアプリケーション識別子を有し、
    前記メッセージは、前記ソースノードのためのソースノード識別子をさらに含み、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、システム。
38. 接続要求メッセージを受信することによって、通信ネットワーク内で宛先ノードにおいてソースノードからの接続を確立するためのシステムであって、前記メッセージは前記ソースノード内の前記接続のためのソースアプリケーション識別子を有し、
    前記メッセージは、前記ソースノードのためのソースノード識別子をさらに含み、
    前記ソースノード、前記宛先ノードはそれぞれ、基地局を含む、システム。
39. 前記システムは、第２のソースノードから第２の接続要求メッセージを受信することによって、前記宛先ノードにおいて第２のソースノードからの第２の接続を確立し、前記第２の接続要求メッセージは第２のソースアプリケーション識別子を有し、
    前記第２の接続要求メッセージは、前記第２のソースノードのための第２のソースノード識別子をさらに含み、前記ソースノードのための前記ソースノード識別子及び前記第２のソースノードのための前記第２のソースノード識別子は互いに異なる、請求項３８に記載のシステム。
40. 前記ソースノード、前記第２のソースノード及び前記宛先ノードはそれぞれｅＮｏｄｅＢを含む、請求項３９に記載のシステム。

Images