JP6933284B2 - 専用コアネットワーク（ｄｃｎ）選択 - Google Patents

Description

本開示は、専用コアネットワーク（ＤＣＮ）選択に関する。

３ＧＰＰネットワークは、マシンタイプ通信（ＭＴＣ）、Internet of Things（ＩｏＴ）、データ利用等のための機器のような、非常に異なる特性を有する機器及び顧客をサポートし始めつつある。これらの種類の機器及び顧客は、オプション機能のサポート、トラヒック特性のサポート、利用可能性、輻輳管理、シグナリングのユーザプレーントラヒックに対する比、等の観点において、コアネットワークとは異なる要件を有することがある。時代が進むにつれて、機器／顧客の種類は増え続けることになる。

事業者がこれらの異なる種類の機器及び顧客をサポートするためのコスト効率の良い仕組みの１つは、これらの異なる機器及び顧客の要件を満たすために設計され配置された、特化型コアネットワーク要素からなる別個の専用コアネットワークを作り出すことである。ネットワーク利用可能性又は冗長性要件が、様々なハードウェア及び／又はソフトウェアに対して、既存のコアネットワークよりも容易に満たされる場合があるので、その手法はコスト効率が良い。また、別個のコアネットワークを作り出すことは、特定のユーザ又はトラヒックタイプに対する独立したスケーリング、又は特定の機能の提供を可能にし、特定のユーザ及びトラヒックを互いに分離するのを可能にする。

３ＧＰＰが、Ｒｅｌ−１３（ＴＲ２３．７０７）において専用コアネットワークの標準化に取り組み始めており、ユーザ装置（ＵＥ）に影響を及ぼさないネットワーク解決策に合意した。ＴＳ２３．４０１、ｓ４．３．２．５を参照されたい。このＲｅｌ−１３の特徴によれば、事業者が、公衆陸上移動体ネットワーク（ＰＬＭＮ）内で、それぞれが１つ以上のコアネットワークノードからなる複数のＤＣＮ（専用コアネットワーク）を配置できるようになる。各ＤＣＮは、特定のタイプ（複数の場合もある）の加入者又はデバイスにサービスを提供することに特化してもよい。これは、オプションの特徴であり、１または複数のＲＡＴ（無線アクセス技術；ＧＥＲＡＮ、ＵＴＲＡＮ及びＥ−ＵＴＲＡＮ）用にＤＣＮを配置できるようになる。

ＤＣＮがサポートされる（配置される）とき、ネットワークへの初期アクセス時に、ＲＡＮ（無線アクセスネットワーク）が特定のＤＣＮを選択するだけの十分な情報を入手できない場合には、ＲＡＮは、デフォルトコアネットワーク（ＣＮ）からコアネットワークノードを選択してもよい。その際、ＤＣＮへのリダイレクションが必要となりうる。

モバイル端末をデフォルトＣＮから専用ＣＮにリダイレクトするために、ＴＳ２３．４０１の５．１９．１節において記述されている、ＲＡＮを介してのリダイレクション手続を用いて、非アクセス層（ＮＡＳ）メッセージをＵＥからターゲットＤＣＮに転送する。ＵＥに適したＤＣＮを選択し、維持するために、ＲＡＮノードのネットワークノード選択機能（ＮＮＳＦ）を含む、全ての選択機能がＤＣＮ（複数の場合もある）を認識している。

Ｒｅｌ−１３のＤＣＮ選択の解決策は、Ｒｅｌ−１３及びそれより早期にリリースされたモバイル端末をサポートするＵＥに影響を及ぼすことが許容されなかった。この理由から、その解決策は大きな不都合を有し、ネットワークへの初期アクセス時に、最初にデフォルトの進化型パケットコア（ＥＰＣ）ノード（例えば、移動管理エンティティ（ＭＭＥ）又はパケット交換機（ＳＧＳＮ））を選択し、その後、モバイル端末を正しいＤＣＮに再ルーティングする代わりに、ＲＡＮが、はじめから正しい専用ＤＣＮを選択できるようにするだけの十分な情報を入手できない。これは余分なシグナリング及び遅延を引き起こす。

Ｒｅｌ−１４において、３ＧＰＰは、以下の目的を有する、改善されたＤＣＮに関する
作業項目（Ｓ２−１５２６６１）を開始した。

−ＵＥから支援情報を提供することによって、ＤＣＮ選択手法を改善する。
この支援情報は、Ｒｅｌ−１３のＤＥＣＯＲ手法を補完する。これにより、ＤＣＮに登録したり維持したりするために必要となるシグナリングを削減することができる。またこれにより、異なるＤＣＮ間のリダイレクトが不要になるので、専用コアネットワーク間の分離も改善することができる。この更新された選択手法は、ＵＥ及びＲＡＮに影響を及ぼすが、支援情報の提供はコアネットワークに影響を及ぼしうる。ＵＥがＰＬＭＮを変更するときにこの解決策が機能する場合には好都合である。

しかしながら、ＲＡＮがＵＥのメッセージをコアネットワークに向かってルーティングするための決定をいかに行うのかは不明確である。

この新しい進行中の作業に関して、本発明が解決しようとする課題は、どのようにして、ＲＡＮノード（例えば、evolved Node B（ｅＮＢ）又は無線ネットワーク制御局（ＲＮＣ）又はＣｅｌｌｕａｒ ＩｏＴ（ＣＩｏＴ） ＲＡＮ）が正しい（専用）コアネットワークに向かうＵＥのメッセージ（例えば、ＮＡＳメッセージ）のルーティングを決定できるかである。

一態様において、本発明は、無線アクセスネットワークノードであって、該無線アクセスネットワークノードに接続されるコアネットワークノードから、該コアネットワークノードによってサポートされる専用コアネットワークを構成するためのメッセージを受信するように構成された受信機、を備える、無線アクセスネットワークノードを提供する。

一態様において、本発明は、無線アクセスネットワークノードのための通信方法であって、前記無線アクセスネットワークノードに接続されるコアネットワークノードから、該コアネットワークノードによってサポートされる専用コアネットワークを構成するためのメッセージを受信する、通信方法を提供する。

一態様において、本発明は、無線アクセスネットワークノードに、該無線アクセスネットワークノードに含まれるネットワーク内の新たなロケーションへの登録時に専用コアネットワークを示すための情報を送信するように構成された送信機を備えるモバイル端末を提供する。

一態様において、本発明は、無線アクセスネットワークノードに、該無線アクセスネットワークノードに含まれるネットワーク内の新たなロケーションへの登録時に専用コアネットワークを示すための情報を送信する、モバイル端末のための通信方法を提供する。

一態様において、本発明は、通信システムのための通信方法であって、無線アクセスネットワークによって、該無線アクセスネットワークノードに接続されるコアネットワークノードから、該コアネットワークノードによってサポートされる専用コアネットワークを構成するためのメッセージを受信し；モバイル端末から前記無線アクセスネットワークノードに、前記無線アクセスネットワークノードに含まれるネットワーク内の新たなロケーションへの登録時に専用コアネットワークを示すための情報を送信し；前記無線アクセスネットワークノードによって、前記モバイル端末から受信された前記専用コアネットワークを示すための前記情報に基づいて、前記コアネットワークノードを選択する；通信システムのための通信方法を提供する。

専用タイプのＣＮノードを有するＲＡＮノード設定手法を示す図である。 ＭＭＥ設定更新メッセージ（MME Configuration Update message）内の、ＲＡＮノードがサポートしているＤＣＮタイプのリストを示す図である。 ＲＡＮノードでのＤＣＮタイプリスト設定手法を示す図である。 システム情報メッセージ／ブロックのうちの１つと、そのＲＡＮノードがサポートしている全てのＤＣＮタイプのリストとを示す図である。 初期ＵＥメッセージ又は任意の他のＮＡＳメッセージ内でＲＡＮノードからＥＰＣノードに更に渡すこともできるＤＣＮタイプを示す図である。 Ｓ１−ＡＰの初期ＵＥメッセージ内でＲＡＮがＵＥのＵＥ Ｕｓａｇｅタイプの指示情報をＥＰＣノードに転送しうることを示す図である。 正しいＤＣＮを選択する方法の１つの具体例を示す図である。 ネットワークが、無線リソース制御（ＲＲＣ）接続確立中にＵＥがＲＡＮノードに示した同じタイプのＤＣＮをサポートしないシナリオを示す図である。 ネットワークノードの設定のための例示的なアーキテクチャを示す図である。

解決策形態１
図１における以下の解決策は、複数のモバイル端末によって提供される専用コアネットワークタイプ（ＤＣＮタイプ、ＣＩｏＴタイプ、ＵＥ Ｕｓａｇｅタイプ、又はコアネットワークの専用タイプを識別する任意の他のタイプ）に基づいて、複数のモバイル端末による専用コアネットワーク（ＤＣＮ）選択を支援することを提案するものである。

ステップ１）専用タイプのＣＮノードを有するＲＡＮノード設定手法−複数のＲＡＮノード（ｅＮＢ又はＲＮＣ又はＣＩｏＴ ＲＡＮノード）に、ＲＡＮノードが接続される複数のＥＰＣノード（ＭＭＥ又はＳＧＳＮ又はＣＩｏＴ ＥＰＣノード）の１つ又は複数のＤＣＮ（専用コアネットワーク）タイプを提供する。ＥＰＣノード（ＭＭＥ／ＳＧＳＮ／ＣＩｏＴ ＥＰＣ）のＤＣＮタイプ、すなわち、ＥＰＣノードが特化する又は専用にする、ユーザ、サービス又はデバイスのタイプは、加入者情報管理装置（ＨＳＳ）内でＵＥ加入者情報のタイプを識別するために３ＧＰＰで既に合意されたものと同じタイプ、すなわち、「ＵＥ Ｕｓａｇｅタイプ」（ＴＳ２３．４０１を参照）で、又は代替的には、３ＧＰＰ Ｒｅｌ−１３において専用ＭＭＥプール又はＳＧＳＮプールを識別するために合意された、ＭＭＥＧＩ又はＮＵＬ−ＮＲＩ／ＳＧＳＮグループＩｄで識別されえる。ＭＭＥのＤＣＮタイプは、既存の「ＵＥ Ｕｓａｇｅタイプ」との互換性を可能にする、いわゆる「ＭＭＥ Ｕｓａｇｅタイプ」（それはＭＭＥごとのＵＥ Ｕｓａｇｅタイプになるであろう）でも識別されえる。複数のＥＰＣノード（例えば、複数のＭＭＥ）の複数のＤＣＮタイプは、事業者の設定又はポリシーに基づいて、オペレーション・メンテナンス機能ノード（ＯＡＭ）を介して、又はローカルに設定されてもよい。

ＵＥがＲＡＮノードに接続するときに、ＲＡＮノードが正しい専用ネットワークを選択できるように、ＥＰＣノードは、接続されているＲＡＮノードに、ＥＰＣノードがサービスを提供するために特化された、複数のユーザ又は複数のモバイル端末（複数のＵＥ）のタイプ（ＤＣＮタイプリスト）を示す。

上記で言及されたように、ある形態は、複数のＵＥ及び複数のＥＰＣノードがＤＣＮタイプの指示情報として「ＵＥ Ｕｓａｇｅタイプ」を使用する場合であるが、他の指示情報も使用されえる。別の形態は、ＤＣＮタイプに関するＲＡＮノードへのＭＭＥの指示情報が、ＲＡＮノードへのＵＥの指示情報と異なることである。この場合、ＲＡＮノードは、ＵＥからのＤＣＮタイプを正しい専用ＥＰＣノードにマッピングする内部マッピング手法を有する必要がある。後者の形態の一例は、ＵＥがＤＣＮタイプにおいて、例えば「遅延許容」を示すのに対して、ＥＰＣノード（例えば、ＭＭＥ）が「Ｍ２Ｍ」のＤＣＮタイプを示す場合である。ＲＡＮノードにおけるＵＥの指示情報とＥＰＣノードの指示情報との間のマッピングは、例えば、ＯＡＭシステム上の設定によって行われえるか、又はＲＡＮノード内の内部ロジックによって行われえる。

さらに、ＤＣＮは関連するＤＣＮプロファイルを有してもよく、ＤＣＮプロファイルは、ＤＣＮタイプとともにＲＡＮノードに送信されえる。ＤＣＮプロファイルは、１つ又は複数の所定のサービスを提供するのに特化された、ＤＣＮ特性を規定する複数のパラメータを含んでもよい。ＤＣＮタイプは、ネットワークスライシング手法と見なすことができ、それゆえ、関連するＤＣＮプロファイルは、ネットワークスライス特性を規定してもよい。

ＤＣＮタイプリスト（例えば、「ＵＥ Ｕｓａｇｅタイプ」リスト又はＭＭＥＧＩ／ＳＧＳＮグループＩＤリスト）は、以下の複数のメッセージとともに、ＥＰＣノードからＲＡＮノードに提供することができる。

ステップ１Ａ）ＭＭＥ設定更新メッセージ（MME Configuration Update message）。ＭＭＥの設定中に、複数のＭＭＥは、ＭＭＥ設定更新メッセージ（ＴＳ３６．４１３、ｓ８．７．５）内で、サポートされたＤＣＮタイプのリストをＲＡＮノードに提供する（図２を参照されたい）。これにより、ＵＥがサービスを受けるために接続するときに、ＲＡＮノードが接続された複数のＭＭＥによってサービスを提供されるＵＥのＤＣＮタイプ（例えば、「ＵＥ Ｕｓａｇｅタイプ」又は指定されたＭＭＥＧＩ）についての情報を用いて正しいＭＭＥを選択するように、そのＲＡＮノードはこの情報で設定できるようになる。ＤＣＮタイプのために、「ＵＥ Ｕｓａｇｅタイプ」以外の複数のパラメータが使用される場合には、ＤＣＮタイプの指示情報とＵＥの加入者タイプとの間のマッピングが必要となりうる。このマッピングは、ＲＡＮノード内で設定される必要がある。

ステップ１Ｂ）Ｓ１設定応答メッセージ（S1 Setup Response message）（ＴＳ３６．４１３、ｓ９．１．８．５）。Ｓ１設定（S1 Setup）の手続中に、ＥＰＣノード（例えば、ＭＭＥ）は、ＲＡＮノードにおいてＤＣＮタイプリスト（例えば、「ＵＥ Ｕｓａｇｅタイプ」リスト又はＭＭＥＧＩリスト）の設定を提供する、又は更新してもよい（図３を参照されたい）。これは、ＲＡＮノード内のＤＣＮタイプの設定を可能にするだけでなく、事業者のポリシー又は事業者の設定に基づいて、ＲＡＮノード内のＤＣＮタイプのリストの動的な設定更新も可能にする。

ステップ１Ｃ）−ＥＰＣノード（ＭＭＥ又はＳＧＳＮ又はＣＩｏＴ ＥＰＣノード又は任意の他の名称の専用ネットワークノード）の間の任意の他のシグナリング交換が、ＲＡＮノードを専用ＥＰＣノードの特化タイプで設定するために使用されえる。

上記のオプションＡ１）、１Ｂ）又は１Ｃ）のいずれかに適用可能な更に別の態様において、ＲＡＮノードは、ＥＰＣノードからのＤＣＮタイプのリストに基づいて、ＲＡＮノードがＥＰＣノード（例えば、ＭＭＥ）の選択機能の特徴をサポートするか否かをＥＰＣノードに示すことが可能となる。ＲＡＮノードからのこの種の能力指示情報は、ＤＣＮタイプのリストがＥＰＣノードからＲＡＮノードへのシグナリングの中に設定される必要があるか否かを決定するために、ＥＰＣノードによって使用されてもよい。特に、ＥＰＣノードから報知されるＤＣＮタイプのリストが頻繁に変化する場合で、かつ、ＥＰＣノードがＲＡＮノードを頻繁に更新する必要がある場合には、全てのＲＡＮノードの代わりに、サポートしている複数のＲＡＮノードのみを更新することが有用でありうる。

図２及び図３に示されるように、いったんＲＡＮノードが、関連する複数のＥＰＣノード（例えば、複数のＭＭＥ）からＤＣＮタイプを取得すると、ＲＡＮノードは、ＤＣＮタイプ及び関連するＤＣＮプロファイルを利用して、１つ又は複数のサービスごとにＲＡＮスライシングを実行してもよい。もしＲＡＮノードが複数のＥＰＣノードから同じＤＣＮタイプを受信したなら、ＲＡＮノードは、異なる複数のＥＰＣノードからの同じＤＣＮタイプに関連付けられる全てのＤＣＮプロファイルを、複数のＥＰＣノードに及ぶ１つの集約(aggregated)ネットワークスライスと見なすものとする。

一態様において、図２及び図３に示されるように、ＲＡＮノードが関連する複数のＥＰＣノード（例えば、複数のＭＭＥ）からＤＣＮタイプを取得するとき、ＲＡＮノードは、そのＲＡＮノードがサポートしている全ての複数のＤＣＮタイプのリスト（例えば、ＤＣＮタイプのリスト）を、複数のシステム情報メッセージ／複数のブロックのうちの１つによって（例えば、ＢＣＣＨチャネル上で）ブロードキャストされてもよい（図４を参照されたい）。これにより、複数のＵＥは、ＲＡＮノードによってサポートされている複数のＤＣＮタイプについての情報を取得できるようになり、複数のＵＥは、もし自らが加入したＤＣＮタイプがサポートされている場合、その場合にのみ接続しようと試みることになる。これは、そのＲＡＮノードにおいてサポートされないか、又は一時的に利用できないか（過負荷又は障害）、又は事業者のポリシー及び設定に基づく任意の他の理由から、１つ又は複数の特定のＤＣＮへのアクセスを制限することによって、効率的なＤＣＮアクセス制御を可能にする。このようにして、複数のアクセス障害からの過剰なシグナリングを回避することができ、ＵＥの電池電力を節約することができる。

もしＲＡＮノード（事業者のポリシー又は設定に基づく）が、特定の専用の１つ又は複数のＭＭＥが利用できないときに、デフォルトＭＭＥを選択するように構成されるなら、ＲＡＮノードは、ＤＣＮタイプのリストをブロードキャストしない（すなわち、ＤＣＮアクセス制限はない）。

別の態様において、ＲＡＮノードにおける全てのＵＥに対する全般的な設定の代わりに、これはＵＥごとに行うこともできる。すなわち、ＥＰＣノード（例えば、ＭＭＥ）は、ＵＥが初期ＵＥメッセージを送信するときにＤＣＮタイプのリストを提供する。その後、ＥＰＣノードは、インバウンドローミングユーザのために、ローカル（ＶＰＬＭＮ）ＤＣＮタイプを上記ＵＥのＨＰＬＭＮにおいてサポートされているＤＣＮタイプにマッピングすることができる。例えば、もしＵＥタイプの意味が、異なる複数のネットワーク内で異なり、かつＵＥによって送信されるＵＥ Ｕｓａｇｅタイプが、当分の間、不変であると見なされる場合、ＶＰＬＭＮへの初期アタッチの時点において、ＶＰＬＭＮのＥＰＣノードは、ＤＣＮタイプを含む、ＨＰＬＭＮのＥＰＣノードの加入者プロファイルを受信することになる。ＶＰＬＭＮのＥＰＣノードは、その際、このＵＥに適したＤＣＮタイプを選択し、それを応答メッセージ、例えば、Ｓ１ＡＰにて、ＲＡＮノードに送信することになる。これは、同じＭＭＥが、異なる複数のインバウンドローマごとに、同じＲＡＮノードに異なる複数のサポート値を送信できることを意味する。ＤＣＮタイプの意味は、その際、ＵＥ粒度(granularity)によって決まる。

ＥＰＣノードから「ＤＣＮタイプのリスト」の指示情報を受信した後に、ＲＡＮノードは、ＥＰＣノードＩＤ（例えば、ＭＭＥ ＩＤ）とともに「ＤＣＮタイプのリスト」を記憶する。ＲＡＮノードは、全ての受信した複数のＤＣＮタイプと、対応する複数のＭＭＥ ＩＤとのマッピングテーブルを生成することができる。このマッピングテーブルは、ＵＥから示される同じＤＣＮタイプを扱う複数のサービングノードが存在するときに、ＵＥのＮＡＳメッセージを送るための、直接一致するか、又は最も適したサービングノードを選択するために、ＲＡＮノードが使用しうる。

ステップ２）。複数のモバイル端末（例えば、ＵＥ、ＭＳ、ＭＴＣ機器、ＣＩｏＴ機器又は任意の他のタイプの３ＧＰＰ互換端末）によるＤＣＮタイプの指示情報。ＵＥは、ＲＲＣ接続確立手続中に、自らのＤＣＮタイプ（「ＵＥ Ｕｓａｇｅタイプ」加入者情報、又は必要な専用リソースのためのＭＭＥＧＩ識別情報、又は任意の他のタイプの加入者指示情報、又はユーザ特性、又はターゲットサービスプロバイダ、又はＵＥ、ＳＩＭ若しくはＵＩＣＣにおいてあらかじめ設定されえるターゲットアプリケーション）を示すことができる。ＲＡＮノードは、はじめから正しいタイプのＤＣＮ（ＭＭＥ、ＳＧＳＮ又はＣＩｏＴ ＥＰＣノードのようなＥＰＣノード）を選択することができる。すなわち、デフォルトＥＰＣノードから専用ＥＰＣノードへのリルーティングのいかなる可能性も回避することができる。ＤＣＮタイプは、図５に示されるような、ＲＲＣ接続設定完了メッセージにおいて、又は接続確立手続内の任意の他のメッセージにおいて、又はＮＡＳメッセージを介して示すことができる。

ＲＡＮノードは、自らが接続される各ＭＭＥによってサポートされているＤＣＮタイプのリストで設定されている（ステップ１を参照されたい）。ＲＲＣ接続確立中に、ＵＥは、接続する正しいＭＭＥを選択するためにＲＡＮノードによって使用される自らのＤＣＮタイプ（「ＵＥ Ｕｓａｇｅタイプ」又は専用リソースのＭＭＥＧＩ）を示す。ＵＥはオプションで、モバイル発信（ＭＯ：Mobile Originated）サービスのためのＲＲＣ接続確立中にのみ自らのＤＣＮタイプを示すことができる。もしＲＡＮノードが、（例えば、複数のホーム及び訪問先ＰＬＭＮの一方又は両方がＤＣＮタイプごとに複数のＰＬＭＮ特有値を展開する複数のローミングシナリオにおいて、又は複数のＤＣＮの不均一なカバレッジにおいて）ＵＥから受信したＤＣＮタイプとは異なるＤＣＮタイプで複数のＥＰＣノードによって設定されている場合、事業者のポリシー又は設定に基づいて、ＵＥからのＤＣＮタイプと、複数のＥＰＣノードからの複数のＤＣＮタイプとの間のマッピングが必要となる。

モバイル端末からＲＡＮノードへＵＥのＤＣＮタイプを示すために、他の複数のＲＲＣ接続確立メッセージ（例えば、ＲＲＣ接続要求）をも使用することができ、その場合、ＲＡＮノードの挙動は、ＵＥからＤＣＮタイプを示すことがＲＲＣ接続設定完了メッセージ(RRC Connection Setup Complete message)で受信される場合に類似であるか、又は同じであろう。

もしＵＥが、ＲＡＮノードへのいかなるＤＣＮタイプも示さないなら、ＲＡＮノードの挙動はＲｅｌ−１３のＴＳ２３．４０１において指定されるとおりとなり、ＲＡＮノードは、もしＵＥ又はユーザのＤＣＮ専用情報についての他の入手可能な情報がないなら、ＵＥをデフォルトＭＭＥに転送することになる。

任意選択で、もしＲＡＮノードが複数のＤＣＮタイプ（例えば、「ＵＥ Ｕｓａｇｅタイプ」又はＭＭＥＧＩ又は専用ＥＰＣリソースのための任意の他の識別方法）で設定されていないか、又はＲＡＮノードが、ＵＥによって示されるＤＣＮタイプを復号できないなら、図５に示されるように、ＤＣＮタイプは、初期ＵＥメッセージ又は任意の他のＮＡＳメッセージでＲＡＮノードからＥＰＣノード（例えば、ＭＭＥ又はＳＧＳＮ又はＣＩｏＴ ＥＰＣノード）に、更に渡すこともできる。そのようにして、ＥＰＣノードは、事業者のポリシー又はローカル設定に基づいて、ＵＥからのＤＣＮタイプを解析し、それを正しい専用ネットワークにマッピングすることができる。

別の態様（図６）において、ＤＣＮタイプが標準化されていないタイプ（例えば、ＤＣＮタイプがＰＬＭＮに特有な値を有するＵＥ Ｕｓａｇｅタイプである、図６を参照）であるときに特に、ＵＥは、自らのＤＣＮタイプ（上記で言及された複数のＲＲＣメッセージ（例えば、ＲＲＣ接続設定完了又はＲＲＣ接続要求）又は任意の他のＡＳ若しくはＮＡＳメッセージ内のコンテナ内の加入(subscribed)ＵＥ Ｕｓａｇｅタイプ）を示すことができる。上記の複数のメッセージ内の「ＵＥ Ｕｓａｇｅタイプ」フラグのパラメータが、ＵＥ Ｕｓａｇｅコンテナ内の「ＵＥ Ｕｓａｇｅタイプ」が標準化されているか、又はＰＬＭＮ特有であるか（例えば、１／０、又は真／偽又は標準化／ＰＬＭＮ特有によって、ＵＥ Ｕｓａｇｅタイプコンテナ内の「ＵＥ Ｕｓａｇｅタイプ」要素のタイプを示す簡単なフラグ）を示すことになる。

もし「ＵＥ Ｕｓａｇｅタイプ」がグローバルに標準化されているなら、ＵＥからの「ＵＥ Ｕｓａｇｅタイプ」コンテナが、標準化された「ＵＥ Ｕｓａｇｅタイプ」値そのものになるであろう。

もし「ＵＥ Ｕｓａｇｅタイプ」がＰＬＭＮに特有（標準化されていない）であるのなら、ＵＥ Ｕｓａｇｅタイプコンテナは、
−事業者のローミング、マッピング並びに設定及びポリシーに基づいて、ＲＡＮノード又はＥＰＣノードによって解析されることになる、ＵＥ Ｕｓａｇｅタイプコンテナ内に「ＵＥ Ｕｓａｇｅタイプ」のためのホームＰＬＭＮ特有値を含むことになるか、
−又は、ＵＥが、ローミング時にＵＥ Ｕｓａｇｅタイプコンテナ内の訪問先ＰＬＭＮの「ＵＥ Ｕｓａｇｅタイプ」値を使用できるように、ホームＰＬＭＮが、ＵＥに（無線で、又は端末／ＳＩＭ／ＵＩＣＣ設定を介して）、複数のローミングパートナのための複数の「ＵＥ Ｕｓａｇｅタイプ」値を与える。

図６は、ＲＡＮがＳ１−ＡＰの初期ＵＥメッセージ内で、ＵＥのＵＥ Ｕｓａｇｅタイプの指示情報をＥＰＣノードに転送してもよいことを更に示す。ＵＥからのＵＥ Ｕｓａｇｅタイプの指示情報は、ＵＥの加入者情報の妥当性を（例えば、ＨＳＳによって）検証するために、ＥＰＣノードによって使用されえる。そのような場合、ＵＥがＮＡＳシグナリングにおいて「ＤＣＮタイプ」を示す必要はない。ＡＳシグナリング上のＵＥの指示情報を、Ｓ１−ＭＭＥインタフェース上のＳ１−ＡＰシグナリングに転送するか否かを決定するために、ＲＡＮノードは、内部処理ユニットを有することが必要となりうる。一例において、ｅＮＢは常に、ＵＥのＡＳの指示情報をＳ１−ＭＭＥインタフェース上でＥＰＣノードに転送してもよい。別の例において、ｅＮＢは、指示情報の値に応じて、ＵＥのＡＳの指示情報を転送してもよい。更に別の例において、ＲＡＮノードは、複数の利用可能なＤＣＮのいずれかにマッピングするために、ＵＥのＡＳの指示情報の値がＲＡＮノードに知られているか否か（又はＲＡＮノードがその値で設定されているか否か）に応じて、ＵＥのＡＳの指示情報を転送してもよい。

図７のダイアグラムは、上記のステップに基づいて、正しいＤＣＮを選択する方法の１つの具体例を示す。

１−２）複数のＥＰＣノード（例えば、複数のＭＭＥ）が、ＭＭＥ設定メッセージ（ＴＳ３６．４１３、ｓ８．７．５）又はＭＭＥ／ｅＮＢインタフェース上の任意の他のメッセージの、サポートされている１つ又は複数のＤＣＮタイプのリストをＲＡＮノードに提供する。ＤＣＮタイプは、既に３ＧＰＰにおいて規定されている「ＵＥ Ｕｓａｇｅタイプ」（すなわち、Ｒｅｌ−１３の場合のＴＳ２３．４０１における「ＵＥ Ｕｓａｇｅタイプの加入者情報の値」にあった複数のＤＣＮタイプ値）で表すことができるか、又は専用ＭＭＥのプールのために指定されるＭＭＥＧＩ又は任意の他の専用リソース識別方法によって表すことができる。これにより、ＵＥがサービスを受けるために接続するときに、ＲＡＮノードがこの情報を用いて正しいＭＭＥを選択するように、ＲＡＮノードが接続されるＭＭＥによってサービスを受ける複数のＤＣＮタイプについての情報でＲＡＮノードを設定できるようになる。上記の例において、複数のＭＭＥのうちの１つは「デフォルト」タイプ（従来の非専用ＭＭＥ）からなり、別のＭＭＥは、「ｍｔｃ」（マシンタイプ通信）及び「ｃｉｏｔ」（Cellular Internet of Things）タイプ（例えば、複数の「ｍｔｃ」及び「ｃｉｏｔ」ＵＥ Ｕｓａｇｅタイプ値）からなる。また、複数のデフォルトＭＭＥは、いかなるＤＣＮタイプリストも示さない（例えば、リストが存在しないか、又は空である）ことも可能であり、それは、全てのＤＣＮタイプがサポートされることを意味することになる。

このようにして、ＲＡＮノードは、ＲＡＮノードが接続される各ＭＭＥによってサポートされた複数のＤＣＮタイプのリストで設定される。

３Ａ）ＵＥがＭＯサービスのためのＲＲＣ接続確立をトリガするとき、ＵＥは（例えば、ＲＲＣ接続設定完了メッセージ(RRC Connection Setup Complete message)において）、例えば、ＤＣＮタイプパラメータ＝「ｍｔｃ」によって自らのＤＣＮ加入者情報を示す。
４Ａ）ＵＥからのＤＣＮタイプ＝「ｍｔｃ」指示情報に基づいて、ＲＡＮノードは、「ｍｔｃ」専用ＥＰＣノードを（ＵＥから受信されたＤＣＮタイプと同じタイプから）選択する。ＲＡＮノードは、ＨＳＳでの加入者情報の検証のためのＵＥからＤＣＮタイプの指示情報のパラメータとともに「ｍｔｃ」タイプ専用情報を持つＮＡＳメッセージを、ＵＥからＭＭＥに転送する。

３Ｂ）ＵＥがＭＯサービスのためのＲＲＣ接続確立をトリガするとき、ＵＥは（例えば、ＲＲＣ接続設定完了メッセージにおいて）、例えば、ＤＣＮタイプパラメータ＝「ｃｉｏｔ」を介して、自らのＤＣＮ加入者情報を示す。
４Ｂ）ＵＥからのＤＣＮタイプ＝「ｃｉｏｔ」指示情報に基づいて、ＲＡＮノードは、「ｃｉｏｔ」専用ＥＰＣノードを（ＵＥから受信されたＤＣＮタイプと同じタイプから）選択する。ＲＡＮノードは、ＨＳＳでの加入者情報の検証のためにＵＥからのＤＣＮタイプの指示情報のパラメータとともに「ｃｉｏｔ」専用情報を持つＮＡＳメッセージを、ＵＥからＭＭＥに転送する。

３Ｃ）もしＵＥがＭＯサービスのためのＲＲＣ接続確立をトリガするなら、ＵＥは（例えば、ＲＲＣ接続設定完了メッセージにおいて）、例えば、ＤＣＮタイプパラメータ＝「ｓｄｔ」を介して、自らのＤＣＮ加入者情報を示す。
４Ｃ）ＵＥからのＤＣＮタイプ＝「ｓｄｔ」（スモールデータ伝送）指示情報に基づいて、ＲＡＮノードは、（ＵＥから受信されたＤＣＮタイプと同じタイプから）「ｓｄｔ」専用のＥＰＣノードを選択しようと試みる。「ｓｄｔ」タイプ専用の専用ＭＭＥが使用できないとき、ＲＡＮノードは、事業者設定又はポリシーに基づいて、
・ＵＥからのＤＣＮタイプの指示情報パラメータとともにＵＥからのＮＡＳメッセージを、「デフォルト」タイプ専用のＭＭＥに転送する。デフォルトＭＭＥは、事業者の設定に基づいて、ＵＥにサービスを提供するか、又は拒絶に含まれるバックオフタイマを用いてＵＥからのＮＡＳメッセージを拒絶することができるか、又は代替的には、事業者のポリシー若しくは設定によって必要に応じて、ＵＥからのＮＡＳメッセージを異なる専用のＭＭＥに転送することができる、又は、
・ＲＡＮノードは、ローカル設定又は複数の事業者ポリシーに基づいて、再び、ＵＥからのＮＡＳメッセージを別の専用リソース（ＭＭＥ）に転送する。

図８のダイアグラムは、ＵＥがＲＲＣ接続確立中に（例えば、ＲＲＣ接続設定完了メッセージ又はＲＲＣ接続要求メッセージ(RRC Connection Request message)又は任意の他のＲＲＣシグナリングにおいて）ＲＡＮノードに示した同じタイプからのＤＣＮをネットワークがサポートしない、すなわち、ＲＡＮノードが、ＵＥによって示された「ＤＣＮタイプ」の専用ネットワークが関連付けられていないときのシナリオを示す。この場合、（ＵＥをデフォルトＥＰＣノードに転送すること以外の）１つの取り得る挙動は、既に生成されているＲＲＣ接続を、新たな解放原因とともに、ＵＥに返送されるＲＲＣ接続解放メッセージ(RRC Connection Release message)によって解放することによって、ＲＡＮノードがＵＥを拒絶することであり、解放原因(Release cause)は、例えば、以下である。
−「ＤＣＮサポートなし」（又は同様の意味を有する任意の他の名称のもの）−ＵＥによるＤＣＮタイプの指示情報のＤＣＮがこのＲＡＮノードによってサポートされていない。
−「ＤＣＮ利用不可」（又は同様の意味を有する任意の他の名称のもの）−ＤＣＮは、障害又は任意の他の理由から一時的に利用不可である。

解放原因「ＤＣＮサポートなし」を伴うＲＲＣ接続解放メッセージを受信すると、ＵＥが同じＴＡ／ＬＡ内にある間、ＵＥは、同じＤＣＮへのＲＲＣ接続のための別の試行を開始してはいけない。
解放原因「ＤＣＮ利用不可」を伴うＲＲＣ接続解放メッセージを受信すると、ＵＥが同じセル内にある間、ＵＥは、ＲＲＣ接続確立のための別の試行を開始してはいけない。もしＲＲＣ接続解放メッセージ内に「延長待機タイマ(extended wait timer)」が存在するなら、「延長待機タイマ」が満了するとき、ＵＥは同じセル内で別のＲＲＣ接続確立を試みることができる。

解決策形態２：
上記の問題の別の取り得る解決策は、ＵＥのメッセージを正しいＤＣＮに転送するために適切な方法において複数のＲＡＮノード（例えば、複数のｅＮＢ）を設定することである。この設定は、例えば、ＯＡＭシステムを介して行われえる。形態２は、ＯＡＭによる、より静的な設定方法である。それゆえ、この解決策は、そのＤＣＮ設定が頻繁に変化しないネットワークに適用可能である。

図９は、運用、管理及び保守（ＯＡＭ）システムを用いて、ＲＡＮノード、及びサービングネットワークノード、より詳細には、基地局、ｅＮＢ及びＭＭＥを設定する方法の例示的なアーキテクチャを示す。一般に、ＲＡＮノード（例えば、ｅＮＢ）及びネットワークノード（例えば、ＭＭＥ）は、エレメントマネージャ（ＥＭ）を実現する。ＥＭは、ネットワーク事業者によって運用されるＯＡＭシステムの一部である、ネットワークマネージャ（ＮＭ）に接続される。

本発明の特定のシナリオにおいて、ネットワーク事業者は、ＯＡＭシステムを用いて、複数のＲＡＮノード（複数のｅＮＢ）をＵＥのＤＣＮタイプの指示情報と特定のＤＣＮの指示情報を扱うサービングノードとの特定のマッピングで設定することができる。また、ＯＡＭシステムを用いて、サービングネットワークノードを対応するＤＣＮタイプで設定することもできる。また、ｅＮＢは、ＵＥからの「ＤＣＮタイプ」の指示情報に基づいて、正しいサービングネットワークノードにＵＥのＮＡＳメッセージを送ることができる。言い換えると、ＵＥからの「ＤＣＮタイプ」の指示情報をサービングノードの利用可能なＤＣＮタイプにマッピングするためにＲＡＮノードを設定することは、上記の形態１のｅＮＢの設定と類似している。

設定は、例えば、下記を含むようなある種のテーブルにおいて行われうる。
−１つ又は複数のＭＭＥＧＩ又はＳＧＳＮグループＩＤとマップする複数のＵＥ「ＤＣＮ
タイプ」の指示情報、
−ＭＭＥ ＩＤ又はＳＧＳＮ ＩＤとマップする複数のＵＥ「ＤＣＮタイプ」の指示情報、
−…

そのような設定を有するとき、ｅＮＢは、ＵＥのＮＡＳメッセージが転送される特定のサービングノード（ＭＭＥ)を選択する方法を決定することができる。

本発明において提案される解決策は、その説明及び例において大抵の場合に４Ｇの用語（ＵＥ、ＭＭＥ、ｅＮＢ等）を使用するが、その解決策は、３Ｇ／２Ｇ技術（ＭＳ（Mobile Station）として示される端末、及びネットワークノード、ＳＧＳＮ、ＭＳＣ、ＲＮＣ、基地局等）に、及び任意の新旧の３ＧＰＰ互換技術、ＩｏＴネットワーク及び端末等にも同じく適用可能である。

本開示の態様の要約
１．ＭＭＥ設定更新（MME Configuration Update）（ＤＣＮタイプリスト）−接続されるＭＭＥによってサポートされているＤＣＮタイプ（例えば、ＵＥ Ｕｓａｇｅタイプ又はＭＭＥＧＩ又は専用ＥＰＣリソースの任意の他の識別方法）のリストを含むＭＭＥ設定更新メッセージ（MME Configuration Update message）の新たなパラメータＤＣＮタイプのリスト。これにより、（特定のＲＡＮノードに接続される）複数のＭＭＥが、専用にサービスを提供する複数のＤＣＮタイプでそのＲＡＮノードを設定できるようになる。

２．ＲＲＣ接続設定完了（RRC Connection Setup Complete）（ＤＣＮタイプ）−ＲＲＣ接続設定完了メッセージ（RRC Connection Setup Complete message）（又はＵＥからの任意の他のＡＳ又はＮＡＳメッセージ）の新たなパラメータであるＤＣＮタイプにより、ＵＥがＲＡＮノードに、専用ネットワークに対する自らの加入者情報を（例えば、「ＵＥ Ｕｓａｇｅタイプ」又はＭＭＥＧＩ又はＵＥの専用ネットワーク加入者情報を識別する任意の他の方法を介して）示すことができる。
実施態様では、２つの新たなパラメータをＲＲＣ接続設定メッセージ（RRC Connection Setup Complete message）に追加することができる。−このＲＲＣ接続設定完了（ＵＥ Ｕｓａｇｅタイプフラグ、ＵＥ Ｕｓａｇｅタイプコンテナ）は複数のＰＬＭＮのうちの一方又は両方がＵＥ Ｕｓａｇｅタイプ用に複数のＰＬＭＮに特有の値を使用する場合の、複数のＰＬＭＮ間のローミングをカバーする。この場合、ＵＥ Ｕｓａｇｅタイプフラグは、ＵＥからのＵＥ ＵｓａｇｅタイプコンテナのＵＥ Ｕｓａｇｅタイプの値が、標準化されたものであるか、ＰＬＭＮに特有のものであるかを示すことになる。

３．ＲＡＮノード（例えば、ｅＮＢ）による専用ＥＰＣノードの選択−ＵＥからのＤＣＮタイプのリスト及びＤＣＮタイプの指示情報でのＭＭＥへの設定に基づいて、ＲＡＮノードは、ＵＥにサービスを提供する正しい専用ＥＰＣノードを選択する。

４．初期ＵＥメッセージ（Initial UE message）（ＤＣＮタイプ）−専用ＭＭＥがＤＣＮのためのＵＥ加入を検証できるような、又は代替的には、専用コアネットワーク選択がＥＰＣノードによって行われるとき（例えば、ＲＡＮノード内の専用リソース選択情報が依然として不十分であるとき）の初期ＵＥメッセージ内の新たなパラメータ。

５．ＲＲＣ接続解放(RRC Connection Release)（解放原因）(Release cause)−ＵＥによって示されたＤＣＮタイプの専用ネットワークが利用できないか、又はサポートされていないときに、ＲＡＮノードはＵＥを拒絶することができる。解放原因のための新たな複数の値は、−ＤＣＮサポートなし及びＤＣＮ利用不可である。

６．システム情報によるＤＣＮタイプのリストのブロードキャスト−ＲＡＮノードは、そのＲＡＮノードによってサポートされる複数のＤＣＮのリストをブロードキャストしてもよい。これはつまりＲＡＮノードによるＤＣＮアクセス制御である。もしデフォルトＭＭＥがＭＭＥループ（サービスエリア）内に存在するなら、デフォルトＭＭＥが、（事業者のポリシーに基づいて）ＤＣＮサポートがない複数のＵＥにサービスを提供するように設定されることが可能であるので、ＲＡＮノードは、いかなるＤＣＮタイプのリストもブロードキャストしなくてよい。

本開示の例示的な利点
１．ＵＥ ＮＡＳメッセージのリルートが回避される。ＵＥがＤＣＮパラメータを介して専用ネットワークに対する自らの加入者情報を提供し、ＲＡＮノードも複数のＭＭＥのＤＣＮタイプで設定されるので、ＲＡＮノードは、ＮＡＳメッセージをＵＥからデフォルトＭＭＥに転送することなく、正しい専用リソースを選択することができる。

２．ＲＡＮノードによる改善されたロードバランシング。ＲＡＮノードには、接続される複数のＭＭＥによってサポートされる複数のＤＣＮタイプが与えられるので、ＲＡＮノードは、同じＤＣＮタイプの複数のＭＭＥに対してのみ既存の複数のロードバランシング原理を適用することによって、専用ＭＭＥを選択することができる。

この出願は、２０１５年１０月９日に出願された欧州特許出願第１５１８９２４０．３を基礎とする優先権を主張し、その開示のすべてをここに取り込む。

Claims (4)

1. コアネットワークノードから、過負荷である少なくとも１つのネットワークスライスを示す過負荷メッセージを受信する第１の受信手段と、
   モバイル端末が使用するサービスに対応する第１のネットワークスライスを含む無線リソース制御（ＲＲＣ）メッセージを前記モバイル端末から受信する第２の受信手段と、
   前記第１のネットワークスライスが前記少なくとも１つのネットワークスライスに含まれる場合に、前記ＲＲＣメッセージを拒絶するためのメッセージを前記モバイル端末へ送信する送信手段と、
   を備え、
   前記メッセージは前記モバイル端末のさらなるＲＲＣメッセージ送信を制限するタイマを含む、
   無線アクセスネットワークノード。
2. モバイル端末であって、
   前記モバイル端末が使用するサービスに対応する第１のネットワークスライスを含む無線リソース制御（ＲＲＣ）メッセージを無線アクセスネットワークノードへ送信する送信手段と、
   前記無線アクセスネットワークノードがコアネットワークノードから受信した、過負荷メッセージに含まれる少なくとも１つのネットワークスライスが前記第１のネットワークスライスを含む場合に、前記ＲＲＣメッセージを拒絶するためのメッセージを前記無線アクセスネットワークノードから受信する受信手段と、
   を備え、
   前記メッセージは前記モバイル端末のさらなるＲＲＣメッセージ送信を制限するタイマを含む、
   モバイル端末。
3. コアネットワークノードから、過負荷である少なくとも１つのネットワークスライスを示す過負荷メッセージを受信し、
   モバイル端末が使用するサービスに対応する第１のネットワークスライスを含む無線リソース制御（ＲＲＣ）メッセージを前記モバイル端末から受信し、
   前記第１のネットワークスライスが前記少なくとも１つのネットワークスライスに含まれる場合に、前記ＲＲＣメッセージを拒絶するためのメッセージを前記モバイル端末へ送信する、
   ことを備え、
   前記メッセージは前記モバイル端末のさらなるＲＲＣメッセージ送信を制限するタイマを含む、
   通信制御方法。
4. モバイル端末における通信制御方法であって、
   前記モバイル端末が使用するサービスに対応する第１のネットワークスライスを含む無線リソース制御（ＲＲＣ）メッセージを無線アクセスネットワークノードへ送信し、
   前記無線アクセスネットワークノードがコアネットワークノードから受信した、過負荷メッセージに含まれる少なくとも１つのネットワークスライスが前記第１のネットワークスライスを含む場合に、前記ＲＲＣメッセージを拒絶するためのメッセージを前記無線アクセスネットワークノードから受信する、
   ことを備え、
   前記メッセージは前記モバイル端末のさらなるＲＲＣメッセージ送信を制限するタイマを含む、
   通信制御方法。

Images