JP6844548B2 - 無線アクセスネットワークノード、エッジサーバ、及びこれらの方法 - Google Patents

Description

本開示は、モバイル通信ネットワークに関し、特にモバイル・エッジ・コンピューティングのための装置及び方法に関する。

European Telecommunications Standards Institute（ETSI）は、Mobile Edge Computing（MEC）の標準化を開始している（非特許文献１及び２を参照）。MECは、アプリケーション開発者（application developers）及びコンテンツプロバイダに対して、モバイル加入者（mobile subscribers）に近接した無線アクセスネットワーク（Radio Access Network (RAN)）内でのクラウド・コンピューティング能力（capabilities）及びinformation technology（IT）サービス環境を提供する。この環境は、超低遅延（ultra-low latency）及び高帯域幅（high bandwidth）に加えて、アプリケーション及びサービスによって活用される（leveraged）ことができる無線ネットワーク情報（加入者位置、セル負荷など）への直接アクセスを提供する。

MECサーバは、RANノードと統合して配置される。具体的には、MECサーバは、Long Term Evolution（LTE）基地局（eNodeB）サイト、3G Radio Network Controller（RNC）サイト、又はmulti-technologyセル集約（cell aggregation）サイトに配置されることができる。multi-technologyセル集約サイトは、多数の局所的なmulti-technologyアクセスポイントを制御するために、企業の屋内（indoors within an enterprise）（e.g., 病院、大企業の本社）に置かれてもよいし、公共の建物又はアリーナ（e.g., ショッピングモール、スタジアム）の屋内／屋外に置かれてもよい。

MECサーバは、コンピューティング・リソース、ストレージ容量（capacity）、接続性（connectivity）、並びにユーザトラフィック及び無線ネットワーク情報へのアクセスをアプリケーション（MEC applications）に提供する。より具体的には、MECサーバは、Infrastructure as a Service（IaaS）又はPlatform as a Service（PaaS）機能（facility）を提供することによって、アプリケーションのためのホスティング環境を提供する。

MECは、Network Function Virtualization（NFV）と同様に、仮想化された（virtualized）プラットフォームに基づく。NFVはネットワーク機能に重点を置いているのに対して、MECは、ネットワークのエッジでのアプリケーションの実行を可能とする。MECをホストするインフラストラクチャは、NFV又はネットワーク機能をホストするインフラストラクチャと非常に類似している。したがって、Virtual Network Functions（VNFs）及びMECアプリケーション（MEC applications）の両方を同一のプラットフォーム上にホスティングすることで、NFVのインフラストラクチャ及びインフラストラクチャ管理をMECのために再利用することが有益である。

Yun Chao Hu, Milan Patel, Dario Sabella, Nurit Sprecher, and Valerie Young, ETSI White Paper No. 11 "Mobile Edge Computing A key technology towards 5G" First edition, the European Telecommunications Standards Institute, September 2015 ETSI GS MEC-IEG 004 V1.1.1 (2015-11) "Mobile-Edge Computing (MEC); Service Scenarios", the European Telecommunications Standards Institute, November 2015

本件の発明者等は、MECに関する幾つかの課題、特に無線端末の識別に関する課題を見出した。上述したように、MECは、無線端末に向けたアプリケーション及びサービスの低遅延化に寄与し、これによりユーザのQoEの向上に寄与することが期待される。しかしながら、例えば、多くの無線端末がRANに接続している状況では、RANは、MECを利用する又はMECに関係する無線端末が必要としている遅延要件を満足できないおそれがある。この問題を解決するためには、RAN内での無線リソース管理（Radio Resource Management: RRM）又はスケジューリング等に関して、MECを利用する又はMECに関係する特定の無線端末に対する特別な配慮をMECサーバからRANノード（e.g., 無線基地局（eNodeB／RNC））に求めることができると有効であるかもしれない。

しかしながら、ここで留意するべきは、MECサーバ又はMECサーバ上にホストされているMECアプリケーションが無線端末を識別するために使用する端末識別子は、RANノード（e.g.,無線基地局）が無線端末を識別するために使用する端末識別子と異なる点である。言い換えると、MECサーバ（又はMECサーバ上にホストされているMECアプリケーション）及びRANノードが共に使用する共通の端末識別子が存在しない。したがって、MECサーバが特定の無線端末に関する制御又は要求メッセージをRANノードに直接的に送ることは難しい。

具体的には、MECサーバ又はMECサーバ上にホストされているMECアプリケーションは、無線端末のInternet Protocol（IP）アドレス又は無線端末のアプリケーションレイヤでのID（又はname）を、無線端末を識別するために使用することができる。これに対して、RANノード（e.g.,無線基地局）は、当該RANノードに接続する無線端末を識別するために、RAN（又はAccess Stratum（AS））での端末識別子、RANノードとコアネットワークの間の制御コネクション上での端末識別子、及びRANノードとコアネットワークの間のデータベアラ上でのベアラ（セッション）識別子などを使用する。例えば、LTE無線基地局（eNB）は、無線端末（UE）をユニークに識別するために、Cell Radio Network Temporary Identifier（C-RNTI）、eNB UE S1AP ID、及びS1 eNB Tunnel Endpoint Identifier（TEID）、などを使用する。

本明細書に開示される実施形態が達成しようとする目的の１つは、特定の無線端末に関する制御メッセージ（messages）をお互いの間で直接的に交換することをMECサーバ（又はMECサーバ上にホストされているMECアプリケーション）及びRANノードに可能とすることに寄与する装置、方法、及びプログラムを提供することである。

第１の態様では、無線アクセスネットワークノードは、通信モジュールを含む。前記通信モジュールは、前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバと通信するよう構成されている。前記通信モジュールは、前記無線端末の識別のために前記サービス、前記アプリケーション、又は前記エッジサーバにより使用される第１の識別子を、コアネットワーク・ノードから受信するよう構成されている。前記通信モジュールは、前記第１の識別子を、前記無線端末の識別のために前記無線アクセスネットワークノードにより使用される第２の識別子に関連付けるよう構成されている。さらに、前記通信モジュールは、前記第１の識別子を使用して前記エッジサーバと通信するよう構成されている。

第２の態様では、無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法は、
（ａ）前記無線アクセスネットワークに接続するに接続する無線端末の識別のためにサービス、アプリケーション、又はエッジサーバにより使用される第１の識別子を、コアネットワーク・ノードから受信すること、ここで前記エッジサーバは、前記無線端末に向けた前記サービス又は前記アプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供する；
（ｂ）前記第１の識別子を、前記無線端末の識別のために前記無線アクセスネットワークノードにより使用される第２の識別子に関連付けること；及び
（ｃ）前記第１の識別子を使用して前記エッジサーバと通信すること；
を含む。

第３の態様では、エッジサーバは、エッジ・コンピューティング・プラットフォーム及び通信モジュールを含む。前記エッジ・コンピューティング・プラットフォームは、無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するよう構成されている。前記通信モジュールは、前記無線端末の識別のために前記無線アクセスネットワークノードにより使用される第１の識別子を、コアネットワーク・ノードから受信するよう構成されている。前記通信モジュールは、前記第１の識別子を、前記無線端末の識別のために前記サービス、前記アプリケーション、又は前記エッジサーバにより使用される第２の識別子に関連付けるよう構成されている。さらに、前記通信モジュールは、前記第１の識別子を使用して前記無線アクセスネットワークノードと通信するよう構成されている。

第４の態様では、エッジサーバにおける方法は、
（ａ）無線アクセスネットワークに接続する無線端末の識別のために無線アクセスネットワークノードにより使用される第１の識別子を、コアネットワーク・ノードから受信すること、
（ｂ）前記第１の識別子を、前記無線端末の識別のためにサービス、アプリケーション、又は前記エッジサーバにより使用される第２の識別子に関連付けること、及び
（ｃ）前記第１の識別子を使用して前記無線アクセスネットワークノードと通信すること、
を含む。

第５の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第２又は第４の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

上述の態様によれば、特定の無線端末に関する制御メッセージ（messages）をお互いの間で直接的に交換することをMECサーバ（又はMECサーバ上にホストされているMECアプリケーション）及びRANノードに可能とすることに寄与する装置、方法、及びプログラムを提供できる。

幾つかの実施形態に係るモバイル通信ネットワークの構成例を示す図である。 第１の実施形態に係るeNodeB、MECサーバ、及びS/P-GWの動作の一例を示す図である。 第２の実施形態に係るeNodeB、MECサーバ、及びMMEの動作の一例を示す図である。 第３の実施形態に係るeNodeB、MECサーバ、及びS/P-GWの動作の一例を示す図である。 第４の実施形態に係るeNodeB、MECサーバ、及びMMEの動作の一例を示す図である。 第５の実施形態に係るeNodeB、MECサーバ、及びMMEの動作の一例を示す図である。 第６の実施形態に係るeNodeB、MECサーバ、及びNFVコントローラの動作の一例を示す図である。 第７の実施形態に係るeNodeB及びMECサーバの動作の一例を示すシーケンス図である。 第８の実施形態に係るeNodeB及びMECサーバの動作の一例を示すシーケンス図である。 第９の実施形態に係るモバイル通信ネットワークの構成例を示す図である。 第９の実施形態に係るHeNB-GW、MECサーバ、及びS/P-GWの動作の一例を示す図である。 第９の実施形態に係るHeNB-GW、MECサーバ、及びMMEの動作の一例を示す図である。 第９の実施形態に係るHeNB-GW、MECサーバ、及びS/P-GWの動作の一例を示す図である。 第９の実施形態に係るHeNB-GW、MECサーバ、及びMMEの動作の一例を示す図である。 幾つかの実施形態に係るMECサーバの構成例を示す図である。 幾つかの実施形態に係るeNodeBの構成例を示す図である。 第９の実施形態に係るHeNB-GWの構成例を示す図である。

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

以下に示される複数の実施形態は、LTE及びLTE-Advancedを主な対象として説明される。しかしながら、これらの実施形態は、LTE及びLTE-Advancedに限定されるものではなく、他のモバイル通信ネットワーク又はシステム、例えば3rd Generation Partnership Project (3GPP) Universal Mobile Telecommunications System（UMTS）、3GPP2 CDMA2000システム、Global System for Mobile communications（GSM（登録商標））/ General packet radio service（GPRS）システム、WiMAXシステム、又はモバイルWiMAXシステム等に適用されてもよい。

＜第１の実施形態＞
図１は、本実施形態を含む幾つかの実施形態に係るモバイル通信ネットワークの構成例を示している。図１の例では、モバイル通信ネットワークは、RAN３（Evolved UMTS Terrestrial Radio Access Network（E-UTRAN））及びコアネットワーク４（Evolved Packet Core（EPC））を含む。RAN３は、eNodeB２を含む。eNodeB２は、RAN３に配置され、RAN３に接続する複数の無線端末１（User Equipment（UE））と通信し、これらUEs１のための無線リソース管理を提供するよう構成されている。無線リソース管理は、例えば、各UE１との無線接続（e.g., Radio Resource Control（RRC）コネクション）の確立・修正・解放、各UE１への無線リソースのスケジューリング、各UE１に対する個別スケジューリング要求（Dedicated Scheduling Request（D-SR））リソースの設定、及び各UE１のハンドオーバの制御を含む。図１に示されたeNodeB２は、マクロセル基地局であってもよいし、フェムトセル基地局であってもよい。

図１に示されたeNodeB２は、Centralized Radio Access Network（C-RAN）アーキテクチャで使用されるBaseband Unit（BBU）であってもよい。言い換えると、図１に示されたeNodeB２は、１又は複数のRemote Radio Head（RRH）に接続されるRANノードであってもよい。幾つかの実装において、BBUとしてのeNodeB２は、EPC４に接続されるとともに、無線リソース管理を含むコントロールプレーン処理とユーザプレーンのデジタルベースバンド信号処理とを担当する。一方、RRHは、アナログRadio Frequency（RF）信号処理（e.g., 周波数変換および信号増幅）を担当する。なお、C-RANは、Cloud RANと呼ばれることもある。また、BBUは、Radio Equipment Controller（REC）又はData Unit（DU）と呼ばれることもある。RRHは、Radio Equipment（RE）、Radio Unit（RU）、又はRemote Radio Unit（RRU）と呼ばれることもある。

さらに、ベースバンド信号処理の一部をリモートサイトに配置するC-RANアーキテクチャも存在する。いくつかの実装では、レイヤ１（物理レイヤ）のベースバンド信号処理がリモートサイトに配置され、レイヤ２（MACサブレイヤ、RLCサブレイヤ、及びPDCPサブレイヤ）及びレイヤ３信号処理がセントラルサイトに配置されてもよい。いくつかの実装では、レイヤ１並びにレイヤ２の一部又は全部の信号処理がリモートサイトに配置され、レイヤ３信号処理がセントラルサイト内に配置されてもよい。図１に示されたeNodeB２は、これらのC-RANアーキテクチャにおいてセントラルサイトに配置されるデータユニットであってもよい。

コアネットワーク４は、主にモバイル通信サービスを提供するオペレータによって管理されるネットワークである。コアネットワーク４は、複数のユーザープレーン・エンティティ（e.g., Serving Gateway (S-GW)及びPacket Data Network Gateway (P-GW)）、及び複数のコントロールプレーン・エンティティ（e.g., Mobility Management Entity（MME）及びHome Subscriber Server（HSS）、Policy and Charging Rule Function（PCRF））を含む。S/P-GW７を含む複数のユーザープレーン・エンティティは、RAN３と外部ネットワーク（Packet Data Network (PDN)）との間でUEs１のユーザデータを中継する。MME６を含む複数のコントロールプレーン・エンティティは、UEs１のモビリティ管理、セッション管理（ベアラ管理）、加入者情報管理、及び課金管理を含む様々な制御を行う。

Mobile Edge Computing（MEC）サーバ５は、無線アクセスネットワークノード（RANノード）と直接的に（つまり、コアネットワーク４を介さずに）通信できるように、RAN３内に配置される。MECサーバ５は、エッジサーバと呼ぶこともできる。図１の例では、MECサーバ５は、eNodeB２と直接的に通信できるように、RAN３内に配置される。上述したように、eNodeB２は、BBUであってもよい。幾つかの実装において、MECサーバ５は、eNodeB２と物理的に統合されてもよい。幾つかの実装において、MECサーバ５は、eNodeB２と同じ建物（サイト）に配置され、eNodeB２と通信できるように当該サイト内のLocal Area Network（LAN）に接続されてもよい。

MECサーバ５は、１又は複数のUE１に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソース（ストレージ容量（capacity））のうち少なくとも１つを提供するよう構成されている。幾つかの実装において、MECサーバ５は、IaaS又はPaaS機能（facility）を提供することによって、MECアプリケーションのためのホスティング環境を提供してもよい。

MECサーバ５は、さらに、コアネットワーク４の一部の機能を有してもよい。例えば、MECサーバ５は、S-GWまたはS/P-GWの機能を有し、MECを利用するUE１のベアラ（Evolved Packet System（EPS）ベアラ）を直接MECサーバ５で終端してもよい。上述したように、MECのアーキテクチャは、NFVのアーキテクチャと類似している。したがって、MECサーバ５は、MECアプリケーションをホストするだけでなく、仮想化された（virtualized）S/P-GW（vS/P-GW）８を含むネットワーク機能をホストしてもよい。

幾つかの実装において、MECサーバ５は、１又は複数のセントラル・サーバ９と通信してもよい。MECサーバ５は、コアネットワーク４を経由してセントラル・サーバ９と通信してもよいし、コアネットワーク４を経由しない通信回線又はネットワーク上でセントラル・サーバ９と通信してもよい。

続いて以下では、eNodeB２及びMECサーバ５が共通のUE識別子を使用できるようにするための手順について説明する。図２は、eNodeB２、MECサーバ５、及びS/P-GW７又は８の動作の一例を示している。なお、図２に示されたS/P-GW７又は８は、S-GWのみ、P-GWのみ、又はS/GW及びP-GWを意味する。S/P-GW７又は８は、コアネットワーク４に配置されたS/P-GW７でもよいし、MECサーバ５と共にeNodeB２のロケーションにコロケートされたS/P-GW８であってもよい。S/P-GW８は、MECサーバ５と同一のプラットフォーム上又は異なるプラットフォーム上に仮想化されたS/P-GWであってもよい。

ステップ２０１では、eNodeB２は、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子を、S/P-GW７又は８から受信する。第１の識別子は、MECサーバ５内又はMECサーバ５にホストされたアプリケーション（又はサービス）内でUE１をユニークに識別するために使用される。図２の例では、第１の識別子は、UE IP address、すなわちUE１のIPアドレスである。

幾つかの実装において、eNodeB２は、S-GW（S/P-GW７又は８）とeNodeB２との間のユーザプレーン・トンネル、すなわちS1ベアラ、を介して第１の識別子を受信してもよい。S1ベアラは、GTP for User Plane（GTP-U）に従うGTPトンネルである。例えば、eNodeB２は、S-GW（S/P-GW７又は８）からS1ベアラを介して受信したGTP-UシグナリングメッセージのPrivate Extension情報要素から第１の識別子を取得してもよい。

ステップ２０２では、eNodeB２は、S/P-GW７又は８から受信した第１の識別子を、UE１を識別するためにeNodeB２により使用される第２の識別子に関連付ける。幾つかの実装において、第２の識別子は、eNodeB２内でUE１をユニークに識別する。幾つかの実装において、第２の識別子は、eNodeB２が提供するセル内でUE１をユニークに識別してもよい。幾つかの実装において、第２の識別子は、eNodeB２とコントロールプレーン・コアネットワークノード（e.g., MME６）との間のインタフェース（e.g., S1-MMEインタフェース）上でUE１をユニークに識別してもよい。幾つかの実装において、第２の識別子は、eNodeB２とユーザプレーン・コアネットワークノード（e.g., S/P-GW７又は８）との間のインタフェース（S1-Uインタフェース）上でUE１又はUE１のためのベアラをユニークに識別してもよい。

より具体的には、第２の識別子は、C-RNTI、eNB UE S1AP ID、S1 eNB TEID、又はこれらの任意の組み合せであってもよい。第２の識別子は、これら１つ又は複数の識別子と他の識別子（e.g., MME UE S1AP ID、S1 S-GW TEID）との組み合せであってもよい。 C-RNTIは、eNodeB２によって割り当てられ、eNodeB２が提供するセル内でUE１をユニークに識別する。eNB UE S1AP IDは、eNodeB２によって割り当てられ、eNodeB２とMME６の間のS1-MMEインタフェース上でUE１をユニークに識別し、且つeNodeB２内でUE１をユニークに識別する。MME UE S1AP IDは、MME６によって割り当てられ、eNodeB２とMME６の間のS1-MMEインタフェース上でUE１をユニークに識別し、且つMME６内でUE１をユニークに識別する。S1 eNB TEIDは、eNodeB２によって割り当てられ、eNodeB２とS-GW（S/P-GW7又は８）の間に確立されるS1ベアラ（つまり、GTPトンネル）のダウンリンク（つまり、eNodeB２側）のエンドポイントを識別する。S1 eNB TEIDはeNodeB２内でユニークであるため、したがってS1 eNB TEIDは、S1ベアラを使用するUE１をeNodeB２内でユニークに識別できる。S1 S-GW TEIDは、S-GWによって割り当てられ、eNodeB２とS-GW（S/P-GW7又は８）の間に確立されるS1ベアラ（GTPトンネル）のアップリンク（つまり、S-GW側）のエンドポイントを識別する。S1 S-GW TEIDは、S1ベアラを使用するUE１をS-GW内でユニークであるため、したがってS1 S-GW TEIDは、S1ベアラを使用するUE１をS-GW（S/P-GW7又は８）内でユニークに識別できる。

第２の識別子は、MME UE S1AP ID、又はMME UE S1AP ID及びMME識別子（e.g., MME Code（MMEC）、MME Identifier（MMEI）、Globally Unique MMEI（GUMMEI））の組み合せを含んでもよい。例えば、eNodeB２が１つのMME６のみと接続されている配置では、MME UE S1AP IDは、eNodeB２内でUE１をユニークに識別するために使用されることができる。これに代えて、eNodeB２が複数のMME６と接続されている配置では、MME UE S1AP ID及びMME識別子の組み合せは、eNodeB２内でUE１をユニークに識別するために使用されることができる。

第２の識別子は、S1 S-GW TEID、又はS1 S-GW TEID及びS-GW識別子（e.g., S-GW address）の組み合せを含んでもよい。例えば、eNodeB２が１つのS-GW（S/P-GW7又は８）のみと接続されている配置では、S1 S-GW TEIDは、eNodeB２内でUE１をユニークに識別するために使用されることができる。これに代えて、eNodeB２が複数のS-GW（S/P-GW7又は８）と接続されている配置では、S1 S-GW TEID及びS-GW識別子の組み合せは、eNodeB２内でUE１をユニークに識別するために使用されることができる。

なお、eNodeB２及びS/P-GW７又は８は、UE１のS1ベアラを特定するために共通の識別子、すなわち、S1 eNB TEID及びS1 S-GW TEIDを使用する。したがって、eNodeB２は、S/P-GW７又は８から受信したUE１の第１の識別子（e.g., UE IP address）を、当該UE１が使用するS1ベアラを特定するためのS1 eNB TEID及びS1 S-GW TEIDと関連付けることができる。さらに、eNodeB２は、S1 eNB TEID及びS1 S-GW TEIDに基づいて、UE１の第１の識別子（e.g., UE IP address）を他の識別子（e.g., C-RNTI、eNodeB UE S1AP ID、MME UE S1AP ID）と関連付けることができる。

図２に戻り説明を続ける。ステップ２０３では、eNodeB２は、UE１を特定するために第１の識別子（e.g., UE IP address）を使用してMECサーバ５と通信する。幾つかの実装において、eNodeB２は、第１の識別子（e.g., UE IP address）を包含する要求メッセージをMECサーバ５から受信したことに応答して、第１の識別子によって識別されるUE１に関する無線リソース管理を行う。無線リソース管理は、例えば、UE１との無線接続（e.g., RRCコネクション）の確立・修正・解放、UE１への無線リソースのスケジューリング、UE１に対する個別スケジューリング要求（D-SR）リソースの設定、及びUE１のハンドオーバの制御を含む。幾つかの実装において、MECサーバ５は、第１の識別子によって識別される特定のUE１に関する遅延要件、スループット要件、及びプライオリティ要件の少なくとも１つを含むMEC制御情報をeNodeB２に知らせてもよい。

遅延要件は、最大遅延、平均遅延、遅延ジッタ、及び遅延保証に関する優先度、のうち少なくとも１つを指定してもよい。当該遅延要件は、遅延要件が必要とされる期間、スケジュール、又は回数を指定してもよい。当該遅延要件は、アップリンクとダウンリンクに個別に設定されてもよい。ここで言う遅延は、例えば、UE１がデータをRAN３に送信完了するまでの遅延、UE１のデータが当該データの送信先（e.g., MECサーバ５）に到達するまでの遅延、RAN３がデータをUE１に送信完了するまでの遅延、のいずれかでもよい。

スループット要件は、最低スループット（保証すべき最小スループット）、平均スループット、要求スループット（十分なスループット）、最小無線帯域、平均無線帯域、及び要求無線帯域のうち少なくとも１つを指定してもよい。

プライオリティ要件は、MECを利用するUE１間の相対的な優先度または絶対的な優先度、或いは、他のMECを利用していないUE１に対するMECを利用するUE１の相対的な優先度または絶対的な優先度、のうち少なくとも１つを指定してもよい。

モビリティ要件は、モビリティを保証するか否か、モビリティを保証する移動速度の値またはレベル（e.g. high, medium (or normal), low）、のうちの少なくとも１つを指定してもよい。

MEC制御情報は、当該MEC制御情報（e.g., 遅延要件）が適用されるべきデータフローを特定するために、データパターン、アプリケーション又はサービスの種別（e.g., 音声、動画、Machine-to-Machine（M2M）制御コマンド）を指定してもよい。さらに又はこれに代えて、当該MEC制御情報は、達成目標（e.g., 達成割合、成功数）を指定してもよい。

図２に示された例は、適宜変更されることができる。幾つかの実装において、S/P-GW７又は８は、第１の識別子（e.g., UE IP address）に加えて、UE１に関する他の識別子をeNodeB２に知らせてもよい。例えば、S/P-GW７又は８は、UE１のEPSベアラに関するTraffic Flow Template（TFT）情報をeNodeB２に知らせてもよい。TFTは、UE１の１又は複数のIPパケットフロー（Service Data Flow（SDF））をUE１のEPSベアラにマッピングするためのパケットフィルタである。TFT情報は、例えば、UE１が通信するMECアプリケーションのIPアドレス（i.e., アップリンク・ディスティネーション・アドレス、ダウンリンク・ソース・アドレス）を含む。

上述したように、図２の例によれば、eNodeB２は、UE１を識別するためにMECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）により使用される第１の識別子を取得し、当該第１の識別子を、UE１を識別するためにeNodeB２によって使用される第２の識別子と関連付ける。したがって、eNodeB２及びMECサーバ５は、共通のUE識別子、すなわち第１の識別子を使用できる。これにより、eNodeB２及びMECサーバ５は、特定のUE１を第１の識別子を用いて指定することにより、当該特定のUE１に関する制御メッセージをお互いの間で直接的に交換することができる。

さらに、幾つかの実装において、S/P-GW８からeNodeB２に第１の識別子（e.g., UE IP address）を知らせる構成は、他のノード（例えばMME６）からeNodeB２に第１の識別子を知らせる構成に比べて以下の利点がある。eNodeB２のサイトに設置されたMECサーバ５にホストされているMECアプリケーションがUE１とユーザプレーン上で通信するためには、当該UE１のEPSベアラを終端するP-GWの機能がeNodeB２に配置されることが好ましい。したがって、S/P-GWがMECサーバ５と共にeNodeB２のサイトに設置される配置は、MECにおける一般的な配置であると考えられる。さらに、既に説明したように、MECサーバ５が仮想化（virtualized）S/P-GW８を含むネットワーク機能をホストする構成も、MECにおける一般的な配置であるかもしれない。このようなMEC特有の事情を考慮すると、eNodeB２とコロケートされた仮想化S/P-GW８がeNodeB２に第１の識別子を供給するほうが、コアネットワーク４内のMME６がeNodeB２に第１の識別子を供給するよりも実装が容易である可能性が高い。なぜなら、仮想化S/P-GW８は、MECのためにMECサーバ５にホストされることができ、且つソフトウェアの修正が容易であるためである。これに対して、MME６は、MEC専用ではなく、通常のセルラー通信のために汎用的に利用されることが想定される。

さらに、上述したように、幾つかの実装において、S-GW（S/P-GW７又は８）からeNodeB２に第１の識別子（e.g., UE IP address）を伝えるためにGTP-UシグナリングメッセージのPrivate Extension情報要素が使用されてもよい。この例は、第１の識別子の転送のためのGTP-Uシグナリングメッセージに対する修正（modification）を必要としないという利点がある。

＜第２の実施形態＞
本実施形態では、eNodeB２及びMECサーバ５が共通のUE識別子を使用できるようにするための他の手順が説明される。本実施形態のモバイル通信ネットワークの構成例は、図１と同様である。

図３は、eNodeB２、MECサーバ５、及びMME６の動作の一例を示している。ステップ３０１では、eNodeB２は、第１の識別子（e.g., UE IP address）をMME６から受信する。第１の実施形態で説明したように、第１の識別子は、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によってUE１を識別するために使用される。幾つかの実装において、eNodeB２は、MME６とeNodeB２との間のシグナリング・インタフェース、すなわちS1-MMEインタフェースを介して第１の識別子を受信してもよい。eNodeB２は、MME６から受信したS1APメッセージの既存の又は新規の情報要素から第１の識別子を取得してもよい。eNodeB２は、UE１に関するMME６とのシグナリングを伴う任意の手順、例えばアタッチ手順又はサービス要求手順において、第１の識別子をMME６から受信してもよい。

ステップ３０２では、eNodeB２は、MME６から受信した第１の識別子を、UE１を識別するためにeNodeB２により使用される第２の識別子に関連付ける。第２の識別子の具体例は、第１の実施形態で説明した例と同様である。

なお、eNodeB２及びMME６は、UE１を特定するために共通の識別子、すなわちeNodeB UE S1AP ID及びMME UE S1AP IDを使用する。したがって、eNodeB２は、MME６から受信したUE１の第１の識別子（e.g., UE IP address）を、当該UE１のeNodeB UE S1AP ID及びMME UE S1AP IDと関連付けることができる。さらに、eNodeB２は、eNodeB UE S1AP ID及びMME UE S1AP IDに基づいて、UE１の第１の識別子（e.g., UE IP address）を他の識別子（e.g., C-RNTI、S1 eNB TEID、S1 S-GW TEID）と関連付けることができる。

ステップ３０３は、図２のステップ２０３と同様である。

図３の例によれば、eNodeB２は、UE１を識別するためにMECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）により使用される第１の識別子を取得し、当該第１の識別子を、UE１を識別するためにeNodeB２によって使用される第２の識別子と関連付ける。したがって、第１の実施形態と同様に、eNodeB２及びMECサーバ５は、共通のUE識別子、すなわち第１の識別子（e.g., UE IP address）を使用できる。

＜第３の実施形態＞
本実施形態では、eNodeB２及びMECサーバ５が共通のUE識別子を使用できるようにするための他の手順が説明される。本実施形態のモバイル通信ネットワークの構成例は、図１と同様である。

図４は、eNodeB２、MECサーバ５、及びS/P-GW７又は８の動作の一例を示している。なお、図４に示されたS/P-GW７又は８は、S-GWのみ、P-GWのみ、又はS/GW及びP-GWを意味する。S/P-GW７又は８は、コアネットワーク４に配置されたS/P-GW７でもよいし、MECサーバ５と共にeNodeB２のロケーションにコロケートされたS/P-GW８であってもよい。S/P-GW８は、MECサーバ５と同一のプラットフォーム上又は異なるプラットフォーム上に仮想化されたS/P-GWであってもよい。

ステップ４０１では、MECサーバ５は、UE１の識別のためにeNodeB２により使用される第２の識別子（e.g., S1 eNB TEID）を、S/P-GW７又は８から受信する。第２の識別子の具体例は、第１の実施形態で説明した例と同様である。なお、S/P-GW７又は８は、UE１のS1ベアラを特定するためのS1 eNB TEID及びS1 S-GW TEIDを管理する。したがって、ステップ４０１で送信される第２の識別子は、S1 eNB TEIDのみ、又はS1 eNB TEID及びS1 S-GW TEIDの組み合せを含んでもよい。ステップ４０１で送信される第２の識別子は、S1 S-GW TEID及びS-GW識別子（e.g., S-GW address）の組み合せを含んでもよい。

幾つかの実装において、MECサーバ５は、仮想化（virtualized）S/P-GW８からMME６にS11インタフェースで送信される制御メッセージ、すなわちGTP for Control plane（GTP-C）メッセージを解析することによって、第２の識別子を取得してもよい。

ステップ４０２では、MECサーバ５は、S/P-GW７又は８から受信した第２の識別子を、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子に関連付ける。第１の識別子は、例えば、UE IP address又はアプリケーションレイヤでのUE１のID（又はname）である。

なお、MECサーバ５及びS/P-GW７又は８は、UE１を特定するために共通の識別子、すなわち、UE IP addressを使用する。幾つかの実装において、MECサーバ５は、MECサーバ上にホストされたMECアプリケーションからUE１のUE IP addressを取得してもよい。したがって、MECサーバ５は、S/P-GW７又は８から受信したUE１の第２の識別子（e.g., S1 eNB TEID）を、当該UE１のUE IP addressと関連付けることができる。さらに、MECサーバ５は、UE IP addressに基づいて、UE１の第２の識別子（e.g., S1 eNB TEID）を他の識別子（e.g., アプリケーションレイヤでのUE１のID）と関連付けることができる。

ステップ４０３では、MECサーバ５は、UE１を特定するために第２の識別子（e.g., S1 eNB TEID）を使用してeNodeB２と通信する。幾つかの実装において、MECサーバ５は、第２の識別子（e.g., S1 eNB TEID）を包含する要求メッセージをeNodeB２に送信し、これにより、当該第２の識別子によって識別される特定のUE１のために特別な無線リソース管理を行うようeNodeB２に要求してもよい。幾つかの実装において、MECサーバ５は、第２の識別子によって識別される特定のUE１に関する遅延要件、スループット要件、又はプライオリティ要件をeNodeB２に知らせてもよい。

図４の例によれば、MECサーバ５は、UE１を識別するためにeNodeB２により使用される第２の識別子を取得し、当該第２の識別子を、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子と関連付ける。したがって、eNodeB２及びMECサーバ５は、共通のUE識別子、すなわち第２の識別子を使用できる。これにより、eNodeB２及びMECサーバ５は、特定のUE１を第２の識別子を用いて指定することにより、当該特定のUE１に関する制御メッセージをお互いの間で直接的に交換することができる。

さらに、幾つかの実装において、S/P-GW８からMECサーバ５に第２の識別子（e.g., S1 eNB TEID）を知らせる構成は、他のノード（例えばMME６）からMECサーバ５に第２の識別子を知らせる構成に比べて以下の利点がある。eNodeB２のサイトに設置されたMECサーバ５にホストされているMECアプリケーションがUE１とユーザプレーン上で通信するためには、当該UE１のEPSベアラを終端するP-GWの機能がeNodeB２に配置されることが好ましい。したがって、S/P-GWがMECサーバ５と共にeNodeB２のサイトに設置される配置は、MECにおける一般的な配置であると考えられる。さらに、既に説明したように、MECサーバ５が仮想化（virtualized）S/P-GW８を含むネットワーク機能をホストする構成も、MECにおける一般的な配置であるかもしれない。このようなMEC特有の事情を考慮すると、MECサーバ５とコロケートされた仮想化S/P-GW８がMECサーバ５に第２の識別子を供給するほうが、コアネットワーク４内のMME６がMECサーバ５に第２の識別子を供給するよりも実装が容易である可能性が高い。なぜなら、仮想化S/P-GW８は、MECのためにMECサーバ５にホストされることができ、且つソフトウェアの修正が容易であるためである。これに対して、MME６は、MEC専用ではなく、通常のセルラー通信のためにも汎用的に利用されることが想定される。

さらに、幾つかの実装において、S/P-GW７又は８からMECサーバ５に送られる第２の識別子は、eNB間ハンドオーバの前後で変更されない識別子であってもよい。これにより、MECサーバ５における第２の識別子の頻繁な更新を抑制できる。例えば、第２の識別子は、S1 S-GW TEID、又はS1 S-GW TEID及びS-GW識別子（e.g., S-GW address）の組み合せであってもよい。eNB間ハンドオーバによってS-GWが変更されなければ、S1 S-GW TEID及びS-GW識別子はeNB間ハンドオーバの前後で同一である。

＜第４の実施形態＞
本実施形態では、eNodeB２及びMECサーバ５が共通のUE識別子を使用できるようにするための他の手順が説明される。本実施形態のモバイル通信ネットワークの構成例は、図１と同様である。

図５は、eNodeB２、MECサーバ５、及びMME６の動作の一例を示している。ステップ５０１では、MECサーバ５は、UE１の識別のためにeNodeB２により使用される第２の識別子（e.g., eNB UE S1AP ID）をMME６から受信する。第２の識別子の具体例は、第１の実施形態で説明した例と同様である。なお、MME６は、eNodeB UE S1AP ID、MME UE S1AP ID 、S1 eNB TEID、及びS1 S-GW TEIDをUE１のために管理する。これらの識別子は、eNodeB２でもUE１のために管理される。したがって、ステップ５０１で送信される第２の識別子は、eNodeB UE S1AP ID及びS1 eNB TEIDのいずれか又は両方を含んでもよい。ステップ５０１で送信される第２の識別子は、eNodeB UE S1AP ID及びMME UE S1AP IDの組み合せを含んでもよい。ステップ５０１で送信される第２の識別子は、MME UE S1AP ID及びMME識別子（e.g., MMEC、MMEI、GUMMEI）の組み合せを含んでもよい。ステップ５０１で送信される第２の識別子は、S1 eNB TEID及びS1 S-GW TEIDの組み合せを含んでもよい。ステップ４５０１で送信される第２の識別子は、S1 S-GW TEID及びS-GW識別子（e.g., S-GW address）の組み合せを含んでもよい。

ステップ５０２は、図４のステップ４０２と同様である。すなわち、ステップ５０２では、MECサーバ５は、MME６から受信した第２の識別子を、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子に関連付ける。第１の識別子は、例えば、UE IP address又はアプリケーションレイヤでのUE１のID（又はname）である。

ステップ５０３は、図４のステップ４０３と同様である。すなわち、MECサーバ５は、UE１を特定するために第２の識別子（e.g., eNB UE S1AP ID）を使用してeNodeB２と通信する。

図５の例によれば、MECサーバ５は、UE１を識別するためにeNodeB２により使用される第２の識別子を取得し、当該第２の識別子を、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子と関連付ける。したがって、第３の実施形態と同様に、eNodeB２及びMECサーバ５は、共通のUE識別子、すなわち第２の識別子（e.g., eNB UE S1AP ID）を使用できる。

さらに、幾つかの実装において、MME６からMECサーバ５に送られる第２の識別子は、eNB間ハンドオーバの前後で変更されない識別子であってもよい。これにより、MECサーバ５における第２の識別子の頻繁な更新を抑制できる。例えば、第２の識別子は、MME UE S1AP ID、又はMME UE S1AP ID及びMME識別子（e.g., MMEC、MMEI、GUMMEI）の組み合せであってもよい。eNB間ハンドオーバによってMMEが変更されなければ、MME UE S1AP ID及びMME識別子はeNB間ハンドオーバの前後で同一である。

＜第５の実施形態＞
本実施形態では、第４の実施形態に係る図５に示された手順の変形が説明される。本実施形態のモバイル通信ネットワークの構成例は、図１と同様である。

図６は、eNodeB２、MECサーバ５、及びMME６の動作の一例を示している。図６の例では、UE１の識別のためにeNodeB２により使用されるC-RNTIがeNodeB２からMME６を介してMECサーバ５に送られる。言い換えると、図６の例では、C-RNTIが第２の識別子として使用される。

ステップ６０１では、eNodeB２は、UE１の識別のためにeNodeB２により使用されるC-RNTIをMME６に送信する。幾つかの実装において、eNodeB２は、UE１のためにS1-MMEインタフェースでMME６に送信されるS1APメッセージ、例えばS1AP Initial UE message、S1AP Path Switch Request、S1AP Handover Request Acknowledge、又はS1AP Handover NotifyにUE１のC-RNTIを含めてもよい。

なお、eNodeB２及びMME６は、UE１を特定するために共通の識別子、すなわちeNodeB UE S1AP ID及びMME UE S1AP IDを使用する。したがって、MME６は、eNodeB２から受信したUE１のC-RNTIを、当該UE１のeNodeB UE S1AP ID及びMME UE S1AP IDと関連付けることができる。さらに、MME６は、eNodeB UE S1AP ID及びMME UE S1AP IDに基づいて、UE１のC-RNTIをUE１のUE IP addressと関連付けることができる。

ステップ６０２では、MECサーバ５は、UE１の識別のためにeNodeB２により使用されるC-RNTIをMME６から受信する。ステップ６０３は、図５のステップ５０２と同様である。ただし、図６では、第２の識別子としてC-RNTIが使用され、MECサーバ５は、MME６から受信したC−RNTIを、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子に関連付ける。第１の識別子は、例えば、UE IP address又はアプリケーションレイヤでのUE１のID（又はname）である。ステップ６０４は、図５のステップ５０３と同様である。ただし、MECサーバ５は、UE１を特定するためにC-RNTIを使用してeNodeB２と通信する。

eNodeB２は、アクセス層（Access Stratum（AS））での無線リソース管理（e.g., スケジューリング）、及びUE１とのRRCコネクションにおいて、UE１を識別するためにC-RNTIを使用する。したがって、図６の例によれば、MECサーバ５は、特定のUE１のために特別な無線リソース管理を行うようeNodeB２に要求する際に、eNodeB２での無線リソース管理に沿ったUE識別子を用いてeNodeB２と通信できる。

＜第６の実施形態＞
幾つかの実装において、eNodeB２及びMECサーバ５が共通のUE識別子を使用できるようにするために、他のコントロールノード、例えばNFVコントローラ７００が使用されてもよい。他のコントロールノード（e.g., NFVコントローラ７００）は、eNodeB２とMECサーバ５の間の通信を仲介してもよい。

図７は、eNodeB２、MECサーバ５、及びNFVコントローラ７００の動作の一例を示している。ステップ７０１では、NFVコントローラ７００は、UE１の様々な識別子をMME６から受信する。さらに又はこれに代えて、NFVコントローラ７００は、UE１の様々な識別子をS/P-GW7又は８から受信してもよい（ステップ７０２）。これら様々な識別子は、上述の第１の識別子（e.g., UE IP address）及び第２の識別子（e.g., eNB UE S1AP ID）を含む。

ステップ７０３及び７０４では、NFVコントローラ７００は、互いに異なるUE識別子を使用するeNodeB２とMECサーバ５の間の通信を仲介する。例えば、NFVコントローラ７００は、第１の識別子（e.g., UE IP address）を包含するメッセージをMECサーバ５から受信したことに応答して、当該メッセージ内の第１の識別子を第２の識別子（e.g., eNB UE S1AP ID）に置き換え、置き換えられた第２の識別子を包含するメッセージをeNodeB２に送信する。さらに又はこれに代えて、NFVコントローラ７００は、第２の識別子を包含するメッセージをeNodeB２から受信したことに応答して、当該メッセージ内の第２の識別子を第１の識別子に置き換え、置き換えられた第１の識別子を包含するメッセージをMECサーバ５に送信する。

図７の例によれば、NFVコントローラ７００の仲介を利用することで、eNodeB２及びMECサーバ５は、特定のUE１に関する制御メッセージを交換することができる。

＜第７の実施形態＞
本実施形態では、共通のUE識別子を使用したeNodeB２及びMECサーバ５の間の通信の例が説明される。本実施形態のモバイル通信ネットワークの構成例は、図１と同様である。

図８は、eNodeB２及びMECサーバ５の動作の一例（処理８００）を示すシーケンス図である。ステップ８０１では、MECサーバ５は、特定のUE１を識別するための共通のUE識別子を包含する制御要求メッセージをeNodeB２に送信する。上述の第１又は第２の実施形態で説明された手順が使用される場合、共通のUE識別子は、第１の識別子（e.g., UE IP address）である。一方、上述の第３、第４、又は第５の実施形態で説明された手順が使用される場合、共通のUE識別子は、第２の識別子（e.g., S1 eNB TEID、eNB UE S1AP ID、C-RNTI）である。

幾つかの実装において、ステップ８０１の制御要求メッセージは、特定のUE１のための特別な無線リソース管理をeNodeB２に要求してもよい。無線リソース管理は、例えば、UE１との無線接続（e.g., RRCコネクション）の確立・修正・解放、UE１への無線リソースのスケジューリング、UE１に対する個別スケジューリング要求（D-SR）リソースの設定、及びUE１のハンドオーバの制御を含む。幾つかの実装において、MECサーバ５は、特定のUE１に関する遅延要件、スループット要件、又はプライオリティ要件をeNodeB２に知らせてもよい。

ステップ８０２では、eNodeB２は、ステップ８０１の要求に対する制御応答メッセージをMECサーバ５に送信する。制御応答メッセージは、特定のUE１を識別するための共通のUE識別子を包含する。幾つかの実装において、制御応答メッセージは、要求された制御の結果（e.g., 成功又は失敗）を示してもよい。

＜第８の実施形態＞
本実施形態では、共通のUE識別子を使用したeNodeB２及びMECサーバ５の間の通信の他の例が説明される。本実施形態のモバイル通信ネットワークの構成例は、図１と同様である。

図９は、eNodeB２及びMECサーバ５の動作の一例（処理９００）を示すシーケンス図である。図９の例では、MECサーバ５は、特定のUE１を識別するための共通のUE識別子を使用してeNodeB２と通信し、これにより当該特定のUE１のために設定された無線ベアラ又は論理チャネルに関する情報をeNodeB２から取得する。取得された無線ベアラ又は論理チャネルに関する情報を利用することによって、MECサーバ５は、特定のUE１内の無線ベアラ単位又は論理チャネル単位での制御要求をeNodeB２に行うことが容易になる。

ステップ９０１では、MECサーバ５は、特定のUE１を識別するための共通のUE識別子を包含するベアラ情報要求メッセージをeNodeB２に送信する。上述の第１又は第２の実施形態で説明された手順が使用される場合、共通のUE識別子は、第１の識別子（e.g., UE IP address）である。一方、上述の第３、第４、又は第５の実施形態で説明された手順が使用される場合、共通のUE識別子は、第２の識別子（e.g., S1 eNB TEID、eNB UE S1AP ID、C-RNTI）である。

ステップ９０２では、eNodeB２は、ステップ９０１の要求に応答して、特定のUE１に関するベアラ情報をMECサーバ５に送信する。当該ベアラ情報は、例えば、特定のUE１に関して設定された無線ベアラ又は論理チャネルの識別子を含んでもよい。幾つかの実装において、無線ベアラ又は論理チャネルの識別子は、EPS Bearer Identity、E-UTRAN Radio Access Bearer (E-RAB) ID、Data Radio Bearer (DRB) Identity、Logical Channel Identity（LCID）、及びLogical Channel Group (LCG) IDのうち少なくとも１つを含む。さらに又はこれに代えて、当該ベアラ情報は、特定のUE１に関して設定された無線ベアラ又は論理チャネルに関するQuality of Service（QoS）パラメータを含んでもよい。当該QoSパラメータは、eNodeB２により行われる無線リソース・スケジューリングにおいて考慮される。幾つかの実装において、当該QoSパラメータは、QoS Class Identifier (QCI)、Allocation and Retention Priority (ARP)、Guaranteed Bit rate (GBR) for GBR type EPS bearer、及びUE Aggregate Maximum Bit Rate (UE-AMBR) for non-GBR type EPS bearer、のうち少なくとも１つを含む。

＜第９の実施形態＞
上述の第１〜第８の実施形態では、MECサーバ５がRANノードとしてのeNodeB２に結合される例を示した。これらに代えて、MECサーバ５は、他のRANノードに結合されてもよい。本実施形態では、MECサーバ５がHome eNodeB Gateway（HeNB-GW）に結合される例が説明される。

図１０は、本実施形態に係るモバイル通信ネットワークの構成例を示している。図１０の例では、モバイル通信ネットワークは、HeNB-GW１０及びHeNB１１を含む。HeNB１１は、RAN３に配置され、eNodeBの機能を提供する。すなわち、HeNB１１は、RAN３に接続する１又は複数の無線端末１（User Equipment（UE））と通信し、UE(s)１のための無線リソース管理を提供するよう構成されている。

HeNB-GW１０は、HeNB１１とEPC４との間に配置され、HeNB１１とEPC４（i.e., MME６）との間でコントロールプレーン信号（i.e., S1APメッセージ）を中継する。より具体的には、HeNB-GW１０は、UEに関連付けられたS1APメッセージ（UE-associated S1AP messages）をMME６とHeNB１１との間で中継し、HeNB１１に向けられた及びMME６に向けられたUEに関連付けられていないS1APメッセージ（non-UE associated S1AP messages）を終端する。さらに、HeNB-GW１０は、S/P-GW７（又は仮想化S/P-GW８）とのS1-Uインタフェース及びHeNB１１とのS1-Uインタフェースを終端してもよい。

図１０の例では、MECサーバ５は、RANノードとしてのHeNB-GW１０と直接的に通信できるように、RAN３内に配置される。幾つかの実装において、MECサーバ５は、HeNB-GW１０と物理的に統合されてもよい。幾つかの実装において、MECサーバ５は、HeNB-GW１０と同じ建物（サイト）に配置され、HeNB-GW１０と通信できるように当該サイト内のLocal Area Network（LAN）に接続されてもよい。

本実施形態に係るHeNB-GW１０及びMECサーバ５が共通のUE識別子を使用できるようにするために、上述の第１〜第６の実施形態で説明されたいずれかの手順が使用されてもよい。HeNB-GW１０及びMECサーバ５は、第７又は第８の実施形態で説明された例に従って、共通のUE識別子を用いて通信してもよい。

以下では、HeNB-GW１０及びMECサーバ５が共通のUE識別子を使用できるようにするための手順のいくつかの例が説明される。図１１は、HeNB-GW１０、MECサーバ５、及びS/P-GW７又は８の動作の一例を示している。図１１に示されたS/P-GW７又は８は、S-GWのみ、P-GWのみ、又はS/GW及びP-GWを意味する。S/P-GW７又は８は、コアネットワーク４に配置されたS/P-GW７でもよいし、MECサーバ５と共にHeNB-GW１０のロケーションにコロケートされたS/P-GW８であってもよい。S/P-GW８は、MECサーバ５と同一のプラットフォーム上又は異なるプラットフォーム上に仮想化されたS/P-GWであってもよい。

図１１に示された例は、eNodeB２の代わりにHeNB-GW１０が使用される点を除いて、図２に示された例に対応する。すなわち、ステップ１１０１では、HeNB-GW１０は、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１の識別のために使用される第１の識別子（e.g., UE IP address）を、S/P-GW７又は８から受信する。

幾つかの実装において、HeNB-GW１０は、S-GW（S/P-GW７又は８）とHeNB-GW１０との間のユーザプレーン・トンネル、すなわちS1ベアラ、を介して第１の識別子を受信してもよい。例えば、HeNB-GW１０は、S-GW（S/P-GW７又は８）からS1ベアラを介して受信したGTP-UシグナリングメッセージのPrivate Extension情報要素から第１の識別子を取得してもよい。

ステップ１１０２では、HeNB-GW１０は、S/P-GW７又は８から受信した第１の識別子を、UE１を識別するためにHeNB-GW１０により使用される第２の識別子に関連付ける。第２の識別子は、eNB UE S1AP ID、及びS1 eNB TEIDのいずれか又は両方を含んでもよい。第２の識別子は、MME UE S1AP ID及びMME識別子（e.g., MME Code（MMEC）、MME Identifier（MMEI）、Globally Unique MMEI（GUMMEI））の組み合せを含んでもよい。第２の識別子は、S1 S-GW TEID及びS-GW識別子の組み合せを含んでもよい。

ステップ１１０３では、HeNB-GW１０は、UE１を特定するために第１の識別子（e.g., UE IP address）を使用してMECサーバ５と通信する。

図１１の例によれば、HeNB-GW１０は、UE１を識別するためにMECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）により使用される第１の識別子を取得し、当該第１の識別子を、UE１を識別するためにHeNB-GW１０によって使用される第２の識別子と関連付ける。したがって、HeNB-GW１０及びMECサーバ５は、共通のUE識別子、すなわち第１の識別子（e.g., UE IP address）を使用できる。

図１２は、HeNB-GW１０、MECサーバ５、及びMME６の動作の一例を示している。図１２に示された例は、eNodeB２の代わりにHeNB-GW１０が使用される点を除いて、図３に示された例に対応する。すなわち、ステップ１２０１では、HeNB-GW１０は、第１の識別子（e.g., UE IP address）をMME６から受信する。幾つかの実装において、HeNB-GW１０は、MME６とeNodeB２との間のシグナリング・インタフェース、すなわちS1-MMEインタフェースを介して第１の識別子を受信してもよい。HeNB-GW１０は、MME６から受信したS1APメッセージの既存の又は新規の情報要素から第１の識別子を取得してもよい。HeNB-GW１０は、UE１に関するMME６とのシグナリングを伴う任意の手順、例えばアタッチ手順又はサービス要求手順において、第１の識別子をMME６から受信してもよい。

ステップ１２０２では、HeNB-GW１０は、MME６から受信した第１の識別子を、UE１を識別するためにHeNB-GW１０により使用される第２の識別子に関連付ける。第２の識別子は、eNB UE S1AP ID及びS1 eNB TEIDのいずれか又は両方を含んでもよい。第２の識別子は、MME UE S1AP ID及びMME識別子の組み合せを含んでもよい。第２の識別子は、S1 S-GW TEID及びS-GW識別子の組み合せを含んでもよい。

ステップ１２０３は、図１１のステップ１１０３と同様である。

図１２の例によれば、図１１の例と同様に、HeNB-GW１０及びMECサーバ５は、共通のUE識別子、すなわち第１の識別子（e.g., UE IP address）を使用できる。

図１３は、HeNB-GW１０、MECサーバ５、及びS/P-GW７又は８の動作の一例を示している。図１３に示されたS/P-GW７又は８は、S-GWのみ、P-GWのみ、又はS/GW及びP-GWを意味する。S/P-GW７又は８は、コアネットワーク４に配置されたS/P-GW７でもよいし、MECサーバ５と共にHeNB-GW１０のロケーションにコロケートされたS/P-GW８であってもよい。S/P-GW８は、MECサーバ５と同一のプラットフォーム上又は異なるプラットフォーム上に仮想化されたS/P-GWであってもよい。

図１３に示された例は、eNodeB２の代わりにHeNB-GW１０が使用される点を除いて、図４に示された例に対応する。すなわち、ステップ１３０１では、MECサーバ５は、UE１の識別のためにHeNB-GW１０により使用される第２の識別子（e.g., S1 eNB TEID）を、S/P-GW７又は８から受信する。第２の識別子の具体例は、図１１に関して説明した例と同様である。なお、S/P-GW７又は８は、UE１のS1ベアラを特定するためのS1 eNB TEID及びS1 S-GW TEIDを管理する。したがって、ステップ１３０１で送信される第２の識別子は、S1 eNB TEIDのみ、又はS1 eNB TEID及びS1 S-GW TEIDの組み合せを含んでもよい。ステップ１３０１で送信される第２の識別子は、S1 S-GW TEID及びS-GW識別子（e.g., S-GW address）の組み合せを含んでもよい。

ステップ１３０２では、MECサーバ５は、S/P-GW７又は８から受信した第２の識別子を、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子に関連付ける。第１の識別子は、例えば、UE IP address又はアプリケーションレイヤでのUE１のID（又はname）である。

ステップ１３０３では、MECサーバ５は、UE１を特定するために第２の識別子（e.g., S1 eNB TEID）を使用してHeNB-GW１０と通信する。

図１３の例によれば、HeNB-GW１０及びMECサーバ５は、共通のUE識別子、すなわち第２の識別子（e.g., S1 eNB TEID）を使用できる。

図１４は、HeNB-GW１０、MECサーバ５、及びMME６の動作の一例を示している。図１４に示された例は、eNodeB２の代わりにHeNB-GW１０が使用される点を除いて、図５に示された例に対応する。すなわち、ステップ１４０１では、MECサーバ５は、UE１の識別のためにeNodeB２により使用される第２の識別子（e.g., eNB UE S1AP ID）をMME６から受信する。なお、MME６は、eNodeB UE S1AP ID及びMME UE S1AP IDをUE１のために管理する。これらの識別子は、HeNB-GW１０でもUE１のために管理される。したがって、ステップ１４０１で送信される第２の識別子は、eNodeB UE S1AP ID、又はeNodeB UE S1AP ID及びMME UE S1AP IDの組み合せであってもよい。ステップ１４０１で送信される第２の識別子は、MME UE S1AP ID及びMME識別子（e.g., MMEC、MMEI、GUMMEI）の組み合せを含んでもよい。

ステップ１４０２は、図１３のステップ１３０２と同様である。すなわち、ステップ１４０２では、MECサーバ５は、MME６から受信した第２の識別子を、MECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子に関連付ける。第１の識別子は、例えば、UE IP address又はアプリケーションレイヤでのUE１のID（又はname）である。

ステップ１４０３は、図１３のステップ１３０３と同様である。すなわち、MECサーバ５は、UE１を特定するために第２の識別子（e.g., eNB UE S1AP ID）を使用してeNodeB２と通信する。

図１４の例によれば、図１３の例と同様に、eNodeB２及びMECサーバ５は、共通のUE識別子、すなわち第２の識別子（e.g., eNB UE S1AP ID）を使用できる。

最後に、上述の複数の実施形態に係るMECサーバ５、eNodeB２、及びHeNB-GW１０の構成例について説明する。図１５は、MECサーバ５の構成例を示すブロック図である。図１５を参照すると、MECサーバ５は、ネットワークインターフェース１５０１、プロセッサ１５０２、及びメモリ（ストレージ）１５０３を含むハードウェア・コンポーネントを備える。ネットワークインターフェース１５０１は、eNodeB２、HeNB-GW１０、及びその他のネットワークノードと通信するために使用される。ネットワークインターフェース１５０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。

プロセッサ１５０２は、メモリ１５０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態において図面を用いて説明されたMECサーバ５の処理を行う。プロセッサ１５０２は、例えば、マイクロプロセッサ、Micro Processing Unit（MPU）、又はCentral Processing Unit（CPU）であってもよい。プロセッサ１５０２は、複数のプロセッサを含んでもよい。

メモリ１５０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１５０３は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ１５０３は、プロセッサ１５０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１５０２は、図示されていないI/Oインタフェースを介してメモリ１５０３にアクセスしてもよい。

図１５の例では、メモリ１５０３は、MECのためのソフトウェアモジュール群１５０４〜１５０７と、eNodeB２との通信を行う通信モジュール１５０８を格納するために使用される。仮想化管理（virtualization management）ソフトウェア１５０４は、プロセッサ１５０２において実行され、ネットワークインターフェース１５０１、プロセッサ１５０２、及びメモリ１５０３を含むハードウェア・コンポーネントを仮想化し、Infrastructure as a Service（IaaS）又はPlatform as a Service（PaaS）機能（facility）を提供し、これによりアプリケーションのためのホスティング環境を提供する。

アプリケーション・プラットフォーム・サービス（application platform services）ソフトウェア１５０５は、プロセッサ１５０２において実行され、通信サービス、無線ネットワーク情報サービス、トラフィックオフロード機能などのミドルウェア・サービスをアプリケーションに提供する。

アプリケーション・プラットフォーム・サービス・ソフトウェア１５０５は、仮想化S/P-GWソフトウェアモジュール１５０６を含んでもよい。仮想化S/P-GWソフトウェアモジュール１５０６は、仮想化管理（virtualization management）ソフトウェア１５０４によって提供されるホスティング環境を使用し、S-GW又はP-GW又はこれら両方の機能を提供する。

１又は複数のアプリケーション１５０７は、MECサーバ５上にホストされたMECアプリケーションである。１又は複数のアプリケーション１５０７は、アプリケーション・プラットフォーム・サービス・ソフトウェア１５０５又は通信モジュール１５０８によって提供される通信サービスを利用してUE１と通信する。

通信モジュール１５０８は、プロセッサ１５０２において実行され、上述の実施形態に係るRANノード（e.g., eNodeB２又はHeNB-GW１０）との通信サービスをMECアプリケーション１５０７に適用する。幾つかの実装において、通信モジュール１５０８は、アプリケーション・プラットフォーム・サービス・ソフトウェア１５０５に含まれてもよい。

図１６は、上述の実施形態に係るeNodeB２の構成例を示すブロック図である。図１６を参照すると、eNodeB２は、RFトランシーバ１６０１、ネットワークインターフェース１６０３、プロセッサ１６０４、及びメモリ１６０５を含む。RFトランシーバ１６０１は、UE１と通信するためにアナログRF信号処理を行う。RFトランシーバ１６０１は、複数のトランシーバを含んでもよい。RFトランシーバ１６０１は、アンテナ１６０２及びプロセッサ１６０４と結合される。幾つかの実装において、RFトランシーバ１６０１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ１６０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ１６０２に供給する。また、RFトランシーバ１６０１は、アンテナ１６０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ１６０４に供給する。なお、上述したように、eNodeB２は、C-RANアーキテクチャで使用されるBBU（REC）であってもよい。この場合、eNodeB２は、RFトランシーバ１６０１を有していなくてもよい。

ネットワークインターフェース１６０３は、ネットワークノード（e.g., MME６及びS/P-GW７）及びMECサーバ５と通信するために使用される。ネットワークインターフェース１６０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

プロセッサ１６０４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ１６０４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、プロセッサ１６０４によるコントロールプレーン処理は、S1プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

プロセッサ１６０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ１６０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。

メモリ１６０５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ１６０５は、プロセッサ１６０４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１６０４は、ネットワークインターフェース１６０３又は図示されていないI/Oインタフェースを介してメモリ１６０５にアクセスしてもよい。

メモリ１６０５は、上述の複数の実施形態で説明されたeNodeB２による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。幾つかの実装において、プロセッサ１６０４は、当該ソフトウェアモジュールをメモリ１６０５から読み出して実行することで、上述の実施形態で図面を用いて説明されたeNodeB２の処理を行うよう構成されてもよい。

図１６の例では、通信モジュール１６０６及び制御モジュール１６０７がメモリ１６０５に格納されている。プロセッサ１６０４は、通信モジュール１６０６を読み出して実行することで、MECサーバ５との通信を行うことができる。プロセッサ１６０４は、制御モジュール１６０７を読み出して実行することで、UE１の無線リソース管理を行うことができる。

図１７は、HeNB-GW１０の構成例を示すブロック図である。図１７を参照すると、HeNB-GW１０は、ネットワークインターフェース１７０１、プロセッサ１７０２、及びメモリ１７０３を含む。ネットワークインターフェース１７０１は、１又は複数のネットワークノード（e.g., (H)eNB１１、MME６、S/P-GW７、及びMECサーバ５）と通信するために使用される。ネットワークインターフェース１７０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

プロセッサ１７０２は、メモリ１７０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態において説明されたHeNB-GW１０の処理を行う。プロセッサ１７０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１７０２は、複数のプロセッサを含んでもよい。

メモリ１７０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１７０３は、プロセッサ１７０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１７０２は、図示されていないI/Oインタフェースを介してメモリ１７０３にアクセスしてもよい。

図１７の例では、通信モジュール１７０４及び制御モジュール１７０５がメモリ１７０３に格納されている。プロセッサ１７０２は、通信モジュール１７０４を読み出して実行することで、MECサーバ５との通信を行うことができる。プロセッサ１７０２は、制御モジュール１７０５を読み出して実行することで、HeNB-GWの機能を実行する。HeNB-GWの機能は、S1-MMEインタフェース又はS1-MME及びS1-Uインタフェースを提供することを含む。より具体的に述べると、HeNB-GWの機能は、UEに関連付けられたS1APメッセージ（UE-associated S1AP messages）をMME６とHeNB１１との間で中継すること、及びHeNB１１に向けられた及びMME６に向けられたUEに関連付けられていないS1APメッセージ（non-UE associated S1AP messages）を終端することを含む。HeNB-GWの機能は、S/P-GW７（又は仮想化S/P-GW８）とのS1-Uインタフェース及びHeNB１１とのS1-Uインタフェースを終端することを含んでもよい。

図１５〜図１７を用いて説明したように、上述の実施形態に係るMECサーバ５、eNodeB２、及びHeNB-GW１０が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
上述の第１〜第９の実施形態では、MECサーバ５がRANノードとしてのeNodeB２又はHeNB-GW１０に結合される例を示した。これらに代えて、MECサーバ５は、他のRANノードに結合されてもよい。MECサーバ５は、X2 Gateway（X2-GW）に結合されてもよい。あるいは、MECサーバ５は、上述のHeNB-GW１０及びX2-GWの機能を共に有する統合されたRANノードに結合されてもよい。X2-GWは、２つのeNodeBの間に配置され、これら２つのeNodeBの間でコントロールプレーン信号（i.e.,X2APメッセージ）を中継する。さらに、X2-GWは、２つのeNodeBの間でユーザプレーンデータを中継してもよい。

幾つかの実装において、X2-GW（又は統合されたRANノード）は、S/P-GW７又は８から受信した第１の識別子（e.g., UE IP address）を、UE１を識別するためにX2-GW（又は統合されたRANノード）により使用される第２の識別子（e.g., eNB UE X2AP ID）に関連付けてもよい。あるいは、X2-GW（又は統合されたRANノード）は、MME６から受信した第１の識別子（e.g., UE IP address）を、UE１を識別するためにX2-GW（又は統合されたRANノード）により使用される第２の識別子（e.g., eNB UE X2AP ID）に関連付けてもよい。あるいは、MECサーバ５は、S/P-GW７又は８から受信した第２の識別子（e.g., eNB UE X2AP ID）をMECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子（e.g., UE IP address）に関連付けてもよい。あるいは、MECサーバ５は、MME６から受信した第２の識別子（e.g., eNB UE X2AP ID）をMECサーバ５又はMECサーバ５にホストされたアプリケーション（又はサービス）によりUE１を識別するために使用される第１の識別子（e.g., UE IP address）に関連付けてもよい。

既に説明したように、上述の実施形態は、LTE及びLTE-Advanced以外の他のモバイル通信ネットワークに適用されてもよい。例えば、上述の実施形態が3GPP UMTSに適用される場合、MECサーバ５は、RANノード又は無線基地局としてのRNCと直接的に通信できるように配置されてもよい。幾つかの実装において、MECサーバ５は、RNCと物理的に統合されてもよい。幾つかの実装において、MECサーバ５は、RNCと同じ建物（サイト）に配置され、RNCと通信できるように当該サイト内のLANに接続されてもよい。上述の実施形態は、現在のLTE及びLTE-Advancedの発展（3GPP LTE-Advanced Pro 、LTE+、又はenhanced LTE（eLTE））の通信ネットワークに適用されてもよい。この場合、eNodeB２は、3GPP LTE-Advanced Pro 、LTE+、又はenhanced LTE（eLTE）の基地局であってもよい。さらに、eNodeB２は、3GPP Release 14として標準化される予定の新たな5Gエア・インタフェース（新たなRadio Access Technology（RAT））を提供する基地局であってもよい。

上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

この出願は、２０１５年１２月１１日に出願された日本出願特願２０１５−２４２６８６を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１ UE
２ eNodeB
３ 無線アクセスネットワーク
４ コアネットワーク
５ MECサーバ
６ MME
７ S/P-GW
１０ HeNB-GW
１１ HeNB
１５０５ アプリケーション・プラットフォーム・サービス・ソフトウェア
１５０８ 通信モジュール
１６０６ 通信モジュール
１６０７ 制御モジュール
１７０４ 通信モジュール
１７０５ 制御モジュール

Claims (10)

1. 無線アクセスネットワークに配置される無線アクセスネットワークノードであって、
   前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバと通信するよう構成された通信モジュールを備え、
   前記通信モジュールは、
   前記無線端末の識別のために前記サービス、前記アプリケーション、又は前記エッジサーバにより使用される第１の識別子を、コアネットワーク・ノードから受信するよう構成され、
   前記第１の識別子を、前記無線端末の識別のために前記無線アクセスネットワークノードにより使用される第２の識別子に関連付けるよう構成され、
   前記第１の識別子を使用して前記エッジサーバと通信するよう構成されている、
   無線アクセスネットワークノード。
2. 前記コアネットワーク・ノードは、ユーザプレーン・ノードを含み、
   前記通信モジュールは、前記ユーザプレーン・ノードと前記無線アクセスネットワークノードの間のユーザプレーン・トンネルを介して、前記ユーザプレーン・ノードから前記第１の識別子を受信するよう構成されている、
   請求項１に記載の無線アクセスネットワークノード。
3. 前記通信モジュールは、前記ユーザプレーン・ノードから前記ユーザプレーン・トンネルを介して受信したGTP-UシグナリングメッセージのPrivate Extension情報要素から前記第１の識別子を取得するよう構成されている、
   請求項２に記載の無線アクセスネットワークノード。
4. 前記ユーザプレーン・ノードは、前記エッジサーバと共に、前記無線アクセスネットワークノードのロケーションにコロケートされる、
   請求項２又は３に記載の無線アクセスネットワークノード。
5. 前記コアネットワーク・ノードは、移動管理ノードを含み、
   前記通信モジュールは、前記移動管理ノードから前記第１の識別子を受信するよう構成されている、
   請求項１に記載の無線アクセスネットワークノード。
6. 前記第１の識別子は、前記無線端末のIPアドレスを含み、
   前記第２の識別子は、C-RNTI、eNB UE S1AP ID、及びS1 eNB TEIDのうち少なくとも１つを含む、
   請求項１〜５のいずれか１項に記載の無線アクセスネットワークノード。
7. 前記通信モジュールは、前記第１の識別子を含む前記エッジサーバからの所定のメッセージを受信したことに応答して、前記無線端末のために設定された無線ベアラ又は論理チャネルを識別するための第３の識別子を前記エッジサーバに送信するよう構成されている、
   請求項１〜６のいずれか１項に記載の無線アクセスネットワークノード。
8. 無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法であって、
   前記無線アクセスネットワークに接続する無線端末の識別のためにサービス、アプリケーション、又はエッジサーバにより使用される第１の識別子を、コアネットワーク・ノードから受信すること、ここで前記エッジサーバは、前記無線端末に向けた前記サービス又は前記アプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供する；
   前記第１の識別子を、前記無線端末の識別のために前記無線アクセスネットワークノードにより使用される第２の識別子に関連付けること；及び
   前記第１の識別子を使用して前記エッジサーバと通信すること；
   を備える方法。
9. 無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法をコンピュータに行わせるためのプログラムであって、
   前記方法は、
   前記無線アクセスネットワークに接続する無線端末の識別のためにサービス、アプリケーション、又はエッジサーバにより使用される第１の識別子を、コアネットワーク・ノードから受信すること、ここで前記エッジサーバは、前記無線端末に向けた前記サービス又は前記アプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供する；
   前記第１の識別子を、前記無線端末の識別のために前記無線アクセスネットワークノードにより使用される第２の識別子に関連付けること；及び
   前記第１の識別子を使用して前記エッジサーバと通信すること；
   を含む、
   プログラム。
10. 無線アクセスネットワークに配置される無線アクセスネットワークノードに結合して配置されるエッジサーバであって、
    前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するよう構成されたエッジ・コンピューティング・プラットフォームと、
    通信モジュールと、
    を備え、
    前記通信モジュールは、
    前記無線端末の識別のために前記無線アクセスネットワークノードにより使用される第１の識別子を、コアネットワーク・ノードから受信するよう構成され、
    前記第１の識別子を、前記無線端末の識別のために前記サービス、前記アプリケーション、又は前記エッジサーバにより使用される第２の識別子に関連付けるよう構成され、
    前記第１の識別子を使用して前記無線アクセスネットワークノードと通信するよう構成されている、
    エッジサーバ。

Images