JP6922925B2 - 移動管理エンティティ、ネットワーク・エンティティ、及びこれらの方法 - 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）サイト、又はセル集約（cell aggregation）サイトに配置されることができる。セル集約サイトは、多数の局所的なアクセスポイントを制御するために、企業の屋内（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サーバの動作の一例を示すシーケンス図である。 第２の実施形態に係るeNodeB、MME、HSS、及びMECサーバの動作の一例を示すシーケンス図である。 第３の実施形態に係るeNodeB、MME、及びMECサーバの動作の一例を示すシーケンス図である。 第４の実施形態に係るeNodeB、MME、及びMECサーバの動作の一例を示すシーケンス図である。 第５の実施形態に係るeNodeB、MME、及びMECサーバの動作の一例を示すシーケンス図である。 第６の実施形態に係るeNodeB、MME、及びMECサーバの動作の一例を示すシーケンス図である。 第６の実施形態に係るeNodeB、MME、及びMECサーバの動作の一例を示すシーケンス図である。 第６の実施形態に係るeNodeB、MME、及びMECサーバの動作の一例を示すシーケンス図である。 第６実施形態に係るeNodeB、MME、及びMECサーバの動作の一例を示すシーケンス図である。 第７の実施形態に係るeNodeB及びMECサーバの動作の一例を示すシーケンス図である。 第８の実施形態に係るeNodeB及びMECサーバの動作の一例を示すシーケンス図である。 幾つかの実施形態に係るMECサーバの構成例を示す図である。 幾つかの実施形態に係るeNodeBの構成例を示す図である。 幾つかの実施形態に係るMMEの構成例を示す図である。

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

以下に示される複数の実施形態は、LTE及びLTE-Advancedを主な対象として説明される。しかしながら、これらの実施形態は、LTE及びLTE-Advancedに限定されるものではなく、他のモバイル通信ネットワーク又はシステム、例えば既存のThird Generation Partnership Project (3GPP) Universal Mobile Telecommunications System（UMTS）、3GPP2 CDMA2000システム、Global System for Mobile communications（GSM（登録商標））/ General packet radio service（GPRS）システム、WiMAXシステム、又はモバイルWiMAXシステム等に適用されてもよい。また、これらの実施形態は、現在3GPPにより標準化作業が行われている第5世代移動通信システム（5G）に適用されてもよい。5Gは、LTE及びLTE-Advancedの継続的な改良・発展（enhancement/evolution）と新たな5Gエア・インタフェース（新たなRadio Access Technology（RAT））の導入による革新的な改良・発展の組合せで実現されると想定されている。新たなRATは、例えば、LTE/LTE-Advancedの継続的発展が対象とする周波数帯（e.g., 6 GHz以下）よりも高い周波数帯、例えば10 GHz以上のセンチメートル波帯及び30 GHz以上のミリ波帯をサポートする。

＜第１の実施形態＞
図１Ａは、本実施形態を含む幾つかの実施形態に係るモバイル通信ネットワークの構成例を示している。図１Ａの例では、モバイル通信ネットワークは、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１のハンドオーバの制御を含む。図１Ａに示されたeNodeB２は、マクロセル基地局であってもよいし、フェムトセル基地局であってもよい。

図１Ａに示されたeNodeB２は、Centralized Radio Access Network（C-RAN）アーキテクチャで使用されるDigital Unit（DU）であってもよい。DUは、Baseband Unit（BBU）又はCentral Unit（CU）と呼ばれる。言い換えると、図１Ａに示されたeNodeB２は、１又は複数のRadio Unit（RU）に接続されるRANノードであってもよい。RUは、Remote Radio Head（RRH）、Remote Radio Equipment（RRE）、又はDistributed Unit（DU）とも呼ばれる。幾つかの実装において、DU（又はBBU）としてのeNodeB２は、EPC４に接続されるとともに、無線リソース管理を含むコントロールプレーン処理とユーザプレーンのデジタルベースバンド信号処理とを担当する。一方、RU（又は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サブレイヤ、及びPacket Data Convergence Protocol（PDCP）サブレイヤ）及びレイヤ３信号処理がセントラルサイトに配置されてもよい。幾つかの実装では、レイヤ１並びにレイヤ２の一部又は全部の信号処理がリモートサイトに配置され、レイヤ３信号処理がセントラルサイト内に配置されてもよい。図１Ａに示されたeNodeB２は、これらのC-RANアーキテクチャにおいてセントラルサイトに配置されるデータユニットであってもよい。

コアネットワーク４は、主にモバイル通信サービスを提供するオペレータによって管理されるネットワークである。コアネットワーク４は、複数のコントロールプレーン・エンティティ及び複数のユーザープレーン・エンティティを含む。複数のコントロールプレーン・エンティティは、例えば、Mobility Management Entity（MME）６、Home Subscriber Server（HSS）９、及びPolicy and Charging Rule Function（PCRF）１０を含む。複数のユーザープレーン・エンティティは、例えば、S/P-GW７を含む。S/P-GW７は、Serving Gateway（S-GW）若しくはPacket Data Network Gateway（P-GW）又はこれら両方を含む。MME６を含む複数のコントロールプレーン・エンティティは、UEs１のモビリティ管理、セッション管理（ベアラ管理）、加入者情報管理、及び課金管理を含む様々な制御を行う。S/P-GW７を含む複数のユーザープレーン・エンティティは、RAN３と外部ネットワーク（Packet Data Network (PDN)）との間で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のアーキテクチャは、NFVのアーキテクチャと類似している。したがって、MECサーバ５は、MECアプリケーションをホストするだけでなく、仮想化された（virtualized）S/P-GW（vS/P-GW）８を含むネットワーク機能をホストしてもよい。

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

図１Ａに示されたネットワーク構成は一例に過ぎない。例えば、Selected IP Traffic Offload（SIPTO）技術が、UEs１のトラフィックをEPC４を経由せずにMECサーバ５にオフロードするために使用されてもよい。SIPTOは、トラフィックオフローディング技術の１つであり、コアネットワーク（i.e., EPC）をバイパスしつつ、ユーザプレーン（user plane（U-plane））のデータトラフィックを直接的にインターネット又はその他のInternet Protocol（IP）ネットワークに送ることを可能にする。SIPTOは、“SIPTO above RAN”アーキテクチャ及び“SIPTO at the Local Network”アーキテクチャを含む。 “SIPTO above RAN” アーキテクチャは、モバイルオペレータのコアネットワーク（EPC）に配置されたPGWを通じてのトラフィックオフロードに対応する。これに対して、“SIPTO at the Local Network”アーキテクチャは、RANに配置されたLocal Gateway（LGW）を通じてのトラフィックオフロードに対応する。

SIPTO at the Local Network機能は、(H)eNBを介して接続されたIP capable UEに、ユーザプレーンがコアネットワーク（EPC）を経由することなく、定められた（defined）IPネットワーク（e.g., the internet）へアクセスすることを可能にする。SIPTO at the Local Networkは、(H)eNBと一体的に配置された（collocated）LGW機能を選択すること、又はローカルネットワーク内のスタンドアロンGWを選択することによって達成されることができる。“SIPTO at the Local Network with stand-alone GW”及び“SIPTO at the Local Network with L-GW collocated with the (H)eNB”のどちらの場合も、選択されたIPトラフィックはローカルネットワークを介してオフロードされる。なお、ローカルネットワークは、ローカル・ホーム・ネットワーク（Local Home Network（LHN））と同義である。ローカル・ホーム・ネットワークは、LGW及び当該LGWによってIP接続性（connectivity）を提供される少なくとも１つの(H)eNBにより構成されるネットワークである。

SIPTO at the Local Network with stand-alone GWでは、スタンドアロンGWは、複数の(H)eNBsにIP接続性を提供するために使用されることができる。スタンドアロンGWは、ローカルネットワークに配置され、Serving GW（SGW）の機能（functionality）及びLGWの機能（functionality）の両方を含む。一方、SIPTO at the Local Network with L-GW collocated with the (H)eNBでは、LGWは、当該LGW と一体的に配置された(H)eNBにIP接続性を提供するために使用されることができる。

図１Ｂは、図１Ａに示された複数のエンティティの間のインタフェース（参照点（reference points））の一例を示している。図１Ｂに示されたアプリケーション・サーバ２１は、MECサーバ５上にホスティングされてもよい。図１Ｂにおいて、実線で示されたインタフェースは、ユーザプレーン（U-plane）インタフェースであり、点線で示されたインタフェースは、コントロールプレーン（C-plane）インタフェースである。図１Ｂの例では、MECサーバ５は、eNodeB２、MME６、S/P-GW７（又は８）、HSS９、及びPCRF１０、及びアプリケーション・サーバ２１とC-planeインタフェースを介して通信し、さらにS/P-GW７（又は８）及びアプリケーション・サーバ２１とU-planeインタフェースを介して通信する。具体的には、図１Ｂに示されるように、MECサーバ５は、MME６へのT6bインタフェース、HSS９へのS6tインタフェース、PCRF１０へのRxインタフェース、eNodeB２への新たなC-planeインタフェース（e.g., ME1aインタフェース）、S/P-GW７（又は８）への新たなC-planeインタフェース（e.g., ME1bインタフェース）、及びアプリケーション・サーバ２１への新たなC-planeインタフェース（e.g., ME1cインタフェース）を有してよい。さらに、MECサーバ５は、S/P-GW７（又は８）へのSGiインタフェース、及びアプリケーション・サーバ２１へのSGiインタフェースを有してもよい。

図１Ｂに示されたMECサーバ５は、MME６、HSS９及びPCRF１０へのC-Planeインタフェースを有しているから、Service Capability Exposure Function（SCEF）の機能を有すると言うこともできる。すなわち、MECサーバ５は、3GPP標準に規定されたSCEFとして動作してもよい。さらに、図１Ｂに示されたMECサーバ５は、S/P-GW７（又は８）及びアプリケーション・サーバ２１へのU-planeインタフェースを有しているから、Service Capability Server（SCS）の機能を有すると言うこともできる。すなわち、MECサーバ５は、3GPP標準に規定されたSCSとして動作してもよい。

続いて以下では、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又は８）内でユニークに識別できる。S1 eNB TEIDはS1 TEID (DL)と呼ばれることがあり、S1 S-GW TEID はS1 TEID (UL)と呼ばれることがある。

第２の識別子は、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サーバ５、及び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サーバ５、及び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 S-GW TEID 又はS1 eNB TEID）を、S/P-GW７又は８から受信する。第２の識別子の具体例は、第１の実施形態で説明した例と同様である。なお、S/P-GW７又は８は、UE１のS1ベアラを特定するためのS1 eNB TEID及びS1 S-GW TEIDを管理する。したがって、ステップ４０１で送信される第２の識別子は、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サーバ５、及びMME６の動作の一例を示している。ステップ５０１では、MECサーバ５は、UE１の識別のためにeNodeB２により使用される第２の識別子（e.g., MME UE S1AP ID 又は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、MME UE S1AP ID 、S1 eNB TEID、及びS1 S-GW TEIDの任意の組合せを含んでもよい。例えば、ステップ５０１で送信される第２の識別子は、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識別子を包含する制御要求（control request）メッセージをeNodeB２に送信する。上述の第１又は第２の例で説明された手順が使用される場合、共通のUE識別子は、第１の識別子（e.g., UE IP address）である。一方、上述の第３、第４、又は第５の例で説明された手順が使用される場合、共通のUE識別子は、第２の識別子（e.g., S1 S-GW TEID、S1 eNB TEID、MME UE S1AP ID、eNB UE S1AP ID、又はC-RNTI）である。

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

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

図９は、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 S-GW TEID、S1 eNB TEID、MME UE S1AP ID、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、のうち少なくとも１つを含む。

＜第２の実施形態＞
本実施形態では、上述の第４の例（図５）及び第５の例（図６）がより詳細に説明される。本実施形態のモバイル通信ネットワークの構成例は、図１Ａと同様である。

図１０は、eNodeB、MME、HSS、及びMECサーバの動作の一例（処理１０００）を示している。ステップ１００２では、MECサーバ５（e.g., SCEF）は、UE１を識別するためにeNodeB２により使用される第２の識別子を報告するようMME６およびHSS９の少なくとも一方を設定するために、HSS９に要求メッセージを送る。MECサーバ５は、アプリケーション・サーバ２１からの制御要求（ステップ１００１）に応答して、ステップ１００２の要求メッセージを送信してもよい。ステップ１００２の要求メッセージは、UE１を特定するための外部識別子（e.g., IPアドレス）又はMobile Station International Subscriber Directory Number（MSISDN）を含む。HSS９は、MECサーバ５から受信した要求メッセージを検査（examine）し、当該要求メッセージにより示されたUE１を管理しているMME６を特定し、特定されたMME６に要求メッセージ（ステップ１００３）を送信する。ステップ１００３の要求メッセージは、UE１を指定するために当該UE１のInternational Mobile Subscriber Identity（IMSI）を含んでもよく、MECサーバ５の識別子（e.g., IPアドレス, SCEF ID, SCEF Reference ID）を含んでもよい。

MME６は、HSS９から要求メッセージ（ステップ１００３）に応答して、UE１を識別するためにeNodeB２により使用される第２の識別子（e.g., S1 S-GW TEID）を包含する応答メッセージ（ステップ１００６）をHSS９に送る。なお、C-RNTIが第２の識別子として使用される場合、MME６は、UE１のC-RNTIを取得するためにeNodeB２に要求メッセージ（ステップ１００４）を送信し、UE１のC-RNTIを包含する応答メッセージ（ステップ１００５）をeNodeB２から受信してもよい。

HSS９は、第２の識別子（e.g., S1 S-GW TEID）を包含する応答メッセージ（ステップ１００７）をMECサーバ５に送信する。MECサーバ５は、制御要求（ステップ１００１）に基づいてネットワークを制御するための準備（設定）完了したことを示す応答メッセージ（ステップ１００８）をアプリケーション・サーバ２１に送信してもよい。

図１０に示された手順は、以下のように変形されてもよい。MECサーバ５は、HSS９を介さずに、MECサーバ５に直接的に要求メッセージ（ステップ１００２）を送信してもよい。MME６は、HSS９を介さずに、MECサーバ５に直接的に応答メッセージ（ステップ１００６）を送信してもよい。

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

＜第３の実施形態＞
本実施形態では、共通のUE識別子として使用される第２の識別子（e.g., S1 S-GW TEID、MME UE S1AP ID、又はC-RNTI）の変更（更新）をMECサーバ５に知らせるための手順が説明される。

図１１は、eNodeB２、MME６、及びMECサーバ５の動作の一例（処理１１００）を示している。ステップ１１０２では、MME６は、eNodeB２とMECサーバ５の間の共通UE識別子として使用される第２の識別子（e.g., S1 S-GW TEID、MME UE S1AP ID、又はC-RNTI）の変更を検出する。第２の識別子は、eNodeB２により変更されてもよい。ステップ１１０３では、MME６は、変更された（更新された）第２の識別子を示すUE ID報告をMECサーバ５に送信する。C-RNTIが第２の識別子として使用される場合、MME６は、C-RNTIの変更を示すUE ID報告をeNodeB２から受信してもよい。なおeNodeB２は、第２の識別子の変更を示すUE ID報告を直接MECサーバ５に送信してもよい。

MME６は、第２の識別子の変更を引き起こすイベントに関する手順において、第２の識別子の変更を検出してもよい。C-RNTI、S1 eNB TEID、又はeNB UE S1AP IDが第２の識別子として使用される場合、第２の識別子は、UE１のコネクテッドモード（i.e., RRC_CONNECTEDモード）とアイドルモード（i.e., RRC_IDLEモード）との間の状態遷移に起因して変更され、さらにUE１のeNB間ハンドオーバに起因して変更される。MME UE S1AP IDが第２の識別子として使用される場合、第２の識別子は、MME変更（リロケーション）又はS-GW変更（リロケーション）を伴うUE１のアイドルモード・モビリティ及びコネクテッドモード・モビリティ（i.e., ハンドオーバ）に起因して更新される。S1 SGW TEIDが第２の識別子として使用される場合、第２の識別子は、S-GW変更（リロケーション）を伴うUE１のアイドルモード・モビリティ及びコネクテッドモード・モビリティ（i.e., ハンドオーバ）に起因して更新される。ここで、アイドルモード・モビリティは、トラッキングエリア更新（Tracking Area Update（TAU））を含む。コネクテッドモード・モビリティは、ハンドオーバを含む。

MME６は、第２の識別子の変更をHSS９を介してMECサーバ５に知らせてもよい。MME６は、第２の識別子の変更が発生するたびにこれをMECサーバ５に継続的に報告するよう設定されてもよい。例えば、図１０のステップ１００２の要求メッセージは、第２の識別子の変更を継続的に報告することをHSS９に引き起こしてもよい。さらに又はこれに代えて、図１０のステップ１００３の要求メッセージは、第２の識別子の変更を継続的に報告することをMME６に引き起こしてもよい。これにより、MECサーバ５は、共通UE識別子としての第２の識別子が変更されるたびに、第２の識別子の更新された値をMME６から直接的に又はHSS９を介して受信することができる。

＜第４の実施形態＞
本実施形態では、UE１のコネクテッドモード（i.e., RRC_CONNECTED又はECM-CONNECTED）とアイドルモード（i.e., RRC_IDLE又はECM-IDLE）との間の状態遷移の発生をMECサーバ５に知らせるための手順が説明される。

図１２は、eNodeB２、MME６、及びMECサーバ５の動作の一例（処理１２００）を示している。ステップ１２０１では、MME６は、UE１がアイドルモードに遷移すること（又は遷移したこと）を検出する。これに応答して、ステップ１２０２では、MME６は、UE１がアイドルモードに遷移すること（又は遷移したこと）を示す状態変更報告をMECサーバ５に送信する。MME６の代わりに、eNodeB２は、UE１がアイドルモードに遷移すること（又は遷移したこと）を検出し（ステップ１２０３）、UE１がアイドルモードに遷移すること（又は遷移したこと）を示す状態変更報告をMECサーバ５に送信してもよい（ステップ１２０４）。

IPアドレス、MME UE S1AP ID、又はS1 S-GW TEIDが共通UE識別子として使用される場合、MME６またはeNodeB２は、UE１のコネクテッドモードへの遷移に応答して、UE１がコネクテッドモードに遷移したことを示す状態変更報告をMECサーバ５に送信してもよい。

C-RNTI、S1 eNB TEID、又はeNB UE S1AP IDが共通UE識別子として使用される場合、MME６またはeNodeB２は、UE１がコネクテッドモードに遷移したことを示す状態変更報告を共通UE識別子の変更を示すUE ID報告と一緒にMECサーバ５に送信してもよい。

状態変更報告は、送信元のMMEまたはeNBのID、及び送信先のMECサーバ５の識別子（e.g., IPアドレス, SCEF ID, SCEF Reference ID）とともに送信されてもよい。

本実施形態で説明された動作によれば、MECサーバ５は、UE１の状態変化を認識することができる。

＜第５の実施形態＞
本実施形態では、UE１のアイドルモード・モビリティに起因するMMEの変更をMECサーバ５に知らせる手順が説明される。

図１３は、MME変更を伴うTAU手順におけるeNodeB２、古い（old）MME６Ａ、新しい（new）MME６Ｂ、及びMECサーバ５の動作の一例（処理１３００）を示している。ステップ１３０１では、UE１は、TAU要求メッセージを送る。当該TAU要求メッセージは、図示されないeNodeB２のMME選択に基づいて、新しいMME６Bに送られる。ステップ１３０２では、新しいMME６Ｂは、受信したTAU要求メッセージから古いMME６Ａを導出し、コンテキスト要求メッセージを古いMME６Ａに送る。ステップ１３０３では、古いMME６Ａは、コンテキスト要求メッセージに応答して、コンテキスト応答メッセージを新しいMME６Ｂに送る。当該コンテキスト応答メッセージは、MEC関連（MEC-related）コンテキストを含む。MEC関連コンテキストは、MECサーバ５の識別子（e.g., IPアドレス, SCEF ID, SCEF Reference ID）を含んでもよい。新しいMME６Ｂは、受信したMEC関連コンテキストに基づいてMECサーバ５と通信することができる。ステップ１３０４では、新しいMME６Ｂは、TAU受理（accept）メッセージをUE１に送る。なお、図１３では、通常のTAU手順において行われるその他の処理（e.g., MME６とHSS９のインタラクション）は省略されている。

ステップ１３０５では、新しいMME６Ｂは、UE１の移動管理を提供するMMEが変更されたことを示すMME変更報告をMECサーバ５に送信する。MME変更報告は、更新されたMME６のアドレス（つまり、新しいMME６Ｂのアドレス）を示す。なお、MME UE S1AP IDが共通UE識別子として使用される場合、共通UE識別子は、MME変更を伴うTAUに起因して変化する。また、S1 S-GW TEIDが共通UE識別子として使用される場合、共通UE識別子は、S-GW変更を伴うTAUに起因して変化する。したがって、新しいMME６Ｂは、変更された（更新された）MME UE S1AP ID又は、S1 S-GW TEIDを示すUE ID報告を、MME変更報告とともにMECサーバ５に送信してもよい。

本実施形態で説明された動作によれば、MECサーバ５は、UE１の移動管理を提供するMMEが変更されたことを認識することができる。

＜第６の実施形態＞
本実施形態では、UE１のコネクテッドモード・モビリティ（i.e., ハンドオーバ）に起因するeNBの変更をMECサーバ５に知らせる手順が説明される。

図１４は、X2-basedハンドオーバ手順およびS1-basedハンドオーバ手順におけるソースeNodeB２Ａ、ターゲットeNodeB２Ｂ、ソースMME６Ａ、ターゲットMME６Ｂ、及びMECサーバ５の動作の一例（処理１４００）を示している。ステップ１４０１〜１４０４は、X2-basedハンドオーバ手順に関する処理である。当該X2-basedハンドオーバ手順は、MME変更を伴わない。ステップ１４０１では、UE１、ソースeNodeB２Ａ、ターゲットeNodeB２Ｂ、及びＭＭＥ６Ａは、X2-basedハンドオーバ手順を実行する。ソースeNodeB２Ａは、MEC関連（MEC-related）コンテキストをターゲットeNodeB２Ｂに送信する（ステップ１４０２）。MEC関連コンテキストは、MECサーバ５の識別子（e.g., IPアドレス, SCEF ID, SCEF Reference ID）を含んでもよい。UE１の第１の識別子（e.g., UE IP address）が共通UE識別子として使用される場合、MEC関連コンテキストは、さらに、UE１の第１の識別子（e.g., UE IP address）を含んでもよい。ターゲットeNodeB２Ｂは、受信したMEC関連コンテキストに基づいてMECサーバ５と通信することができる。

ステップ１４０３では、MME６Ａは、UE１が接続するeNodeBが変更されたことを示すeNB変更報告をMECサーバ５に送信する。これに代えて、ターゲットeNodeB２ＢがeNB変更報告をMECサーバ５に送信してもよい（ステップ１４０４）。eNB変更報告は、更新されたeNodeB２のアドレス（つまり、ターゲットeNodeB２Ｂのアドレス）を示す。

ステップ１４０５〜１４０８は、S1-basedハンドオーバ手順に関する処理を示している。当該S1-basedハンドオーバ手順はMME変更を伴う。ステップ１４０５では、UE１、ソースeNodeB２Ａ、ターゲットeNodeB２Ｂ、ソースＭＭＥ６Ａ、及びターゲットMME６Ｂは、S1-basedハンドオーバ手順を実行する。ソースMME６Ａは、MEC関連（MEC-related）コンテキストをターゲットMME６Ｂに送信する（ステップ１４０６）。ターゲットMME６Ｂは、受信したMEC関連コンテキストに基づいてMECサーバ５と通信することができる。ステップ１４０７では、ターゲットMME６Ｂは、UE１が接続するeNodeBが変更されたことを示すeNB変更報告をMECサーバ５に送信する。これに代えて、ターゲットeNodeB２ＢがeNB変更報告をMECサーバ５に送信してもよい（ステップ１４０８）。

なお、C-RNTI、eNB UE S1AP ID、又はS1 eNB TEIDが共通UE識別子として使用される場合、共通UE識別子は、X2-basedハンドオーバ及びS1-basedハンドオーバに起因して変化する。MME UE S1AP IDが共通UE識別子として使用される場合、共通UE識別子は、MME再配置（relocation）を伴うS1-basedハンドオーバに起因して変化する。また、S1 S-GW TEIDが共通UE識別子として使用される場合、共通UE識別子は、S-GW再配置を伴うX2-basedハンドオーバ及びS-GW再配置を伴うS1-basedハンドオーバに起因して変化する。したがって、図１５〜図１７に示されるように、ターゲットMME６Ｂ又はターゲットeNodeB２Ｂは、変更された（更新された）共通UE識別子を、eNB変更報告とともにMECサーバ５に送信してもよい。なおターゲットeNB２Ｂは、eNB変更報告とともに送信先のMECサーバ５の識別子（e.g., IPアドレス, SCEF ID, SCEF Reference ID）を送信してもよい。

図１５は、C-RNTI、eNB UE S1AP ID、又はS1 eNB TEIDが共通UE識別子として使用される場合の手順（処理１５００）を示している。この場合、共通UE識別子は、X2-basedハンドオーバ手順（ステップ１５０１）に起因して変化する。したがって、MME６Ａ又はターゲットeNodeB２Ｂは、X2-basedハンドオーバ手順に伴って変更された（更新された）共通UE識別子（e.g., S1 eNB TEID）を示すUE ID報告をMECサーバ５に送信する（ステップ１５０２又は１５０３）。同様に、共通UE識別子（e.g., S1 eNB TEID）は、S1-basedハンドオーバ手順（ステップ１５０４）に起因して変化する。したがって、ターゲットMME６Ｂ又はターゲットeNodeB２Ｂは、S1-basedハンドオーバ手順に伴って変更された（更新された）共通UE識別子を示すUE ID報告をMECサーバ５に送信する（ステップ１５０５又は１５０６）。

図１６は、S1 S-GW TEIDが共通UE識別子として使用される場合の手順（処理１６００）を示している。この場合、共通UE識別子は、S-GW再配置を伴うX2-basedハンドオーバ手順（ステップ１６０１）に起因して変化する。したがって、MME６Ａ又はターゲットeNodeB２Ｂは、X2-basedハンドオーバ手順に伴って変更された（更新された）共通UE識別子（i.e., S1 S-GW TEID）を示すUE ID報告をMECサーバ５に送信する（ステップ１６０２又は１６０３）。同様に、共通UE識別子（i.e., S1 S-GW TEID）は、S-GW再配置を伴うS1-basedハンドオーバ手順（ステップ１６０４）に起因して変化する。したがって、ターゲットMME６Ｂ又はターゲットeNodeB２Ｂは、S-GW再配置を伴うS1-basedハンドオーバ手順に伴って変更された（更新された）共通UE識別子を示すUE ID報告をMECサーバ５に送信する（ステップ１６０５又は１６０６）。

図１７は、MME UE S1AP IDが共通UE識別子として使用される場合の手順（処理１７００）を示している。この場合、共通UE識別子は、MME再配置を伴うS1-basedハンドオーバ手順（ステップ１７０１）に起因して変化する。したがって、ターゲットMME６Ｂ又はターゲットeNodeB２Ｂは、MME再配置を伴うS1-basedハンドオーバ手順に伴って変更された（更新された）共通UE識別子を示すUE ID報告をMECサーバ５に送信する（ステップ１７０２又は１７０３）。

本実施形態で説明された動作によれば、MECサーバ５は、UE１が接続するeNodeBが変更されたことを認識することができる。

＜第７の実施形態＞
本実施形態では、eNodeB２とMECサーバ５との間の通信の具体例が説明される。図１８は、eNodeB２及びMECサーバ５の動作の他の一例（処理１８００）を示すシーケンス図である。ステップ１８０１では、eNodeB２は、制御メッセージをMECサーバ５に送信する。当該制御メッセージは、以下のうち少なくとも１つを示してもよい：
（ａ）各UE１の無線リンク品質情報；
（ｂ）各UE１のためのダウンリンク送信バッファ内のデータ量；
（ｃ）各UE１のためのアップリンク送信バッファ内のデータ量；
（ｄ）各UE１のダウンリンク送信データの破棄回数；
（ｅ）各UE１のアップリンク送信データの破棄回数；
（ｆ）各UE１の破棄されたダウンリンク送信データ量；及び
（ｇ）各UE１の破棄されたアップリンク送信データ量。

当該制御メッセージは、各UE１の共通識別子、送信元のeNodeB２の識別子、送信先のMECサーバ５の識別子（e.g., IPアドレス, SCEF ID, SCEF Reference ID）、及び制御メッセージの送信方向（アップリンクやダウンリンク）を示す情報のうち少なくとも１つと一緒に送信されてもよい。

各UE１の無線リンク品質情報は、ダウンリンク品質若しくはアップリンク品質又は両方を含む。eNodeB２は、コネクテッドモード（RRC_CONNECTED）の全てのUE１の無線リンク品質情報をMECサーバ５に送ってもよい。これに代えて、eNodeB２は、保留されているアップリンクデータ又はダウンリンクデータがあるUE１のみの無線リンク品質情報をMECサーバ５に送ってもよい。無線リンク品質情報は、所定の帯域（Resource Blocks（RBs））に渡る平均品質（e.g., Reference Signal Received Power（RSRP）又はReference Signal Received Quality（RSRQ））を示してもよいし、所定の帯域を分割して得られる複数のRBグループの各々の平均品質を示してもよい。また無線リンク品質情報は、所定の帯域のインデックスを示す情報（Resource Blocks Identifier（RBID））とともに送信されてもよい。MECサーバ５は、無線リンク品質情報の報告の設定（e.g., 報告間隔）をeNodeB２に送信してもよい。

各UE１のためのダウンリンク送信バッファ内のデータ量は、eNodeB２内で保留されている各UE１のダウンリンクデータの合計サイズを示す。eNodeB２は、特定のUE１へのデータを送信したタイミングで、ダウンリンク送信バッファ内のデータ量をMECサーバ５に送信してもよい。各UE１のためのアップリンク送信バッファ内のデータ量は、各UE１内で保留されているアップリンクデータの合計サイズを示す。eNodeB２は、特定のUE１からバッファサイズに関する報告を受信したタイミングで、アップリンク送信バッファ内のデータ量をMECサーバ５に送信してもよい。MECサーバ５は、送信バッファ内のデータ量の報告の設定（e.g., 報告間隔）をeNodeB２に送信してもよい。

各UE１のダウンリンク送信データの破棄回数は、各UE１のためのダウンリンク送信バッファ内に保留されていたダウンリンク送信データが送信されずに破棄された回数を示す。各UE１の破棄されたダウンリンク送信データ量は、送信されずに破棄されたダウンリンクデータの合計サイズを示す。各UE１のアップリンク送信データの破棄回数は、各UE１のアップリンク送信バッファ内に保留されていたアップリンク送信データが送信されずに破棄された回数を示す。各UE１の破棄されたアップリンク送信データ量は、送信されずに破棄されたアップリンクデータの合計サイズを示す。MECサーバ５は、ダウンリンク（又はアップリンク）送信データの破棄回数若しくは破棄されたダウンリンク（又はアップリンク）送信データ量又はこれら両方に基づいて、各UE１へのリソース割当の際に考慮されるスケジューリング・パラメータの調整をeNodeB２に要求してもよい。

図１９は、eNodeB２及びMECサーバ５の動作の他の一例（処理１９００）を示すシーケンス図である。ステップ１９０１では、MECサーバ５は、制御メッセージをeNodeB２に送信する。当該制御メッセージは、以下のうち少なくとも１つを示してもよい：
（ａ）対象のUE１の通信イベントで送信される複数のデータパケットの合計サイズと複数のデータパケットの送信デッドライン；
（ｂ）eNodeB２のアップリンク・スケジューラ又はダウンリンク・スケジューラによって考慮される対象のUE１又は他のUE１の優先度レベル；
（ｃ）アップリンク・スケジューラ又はダウンリンク・スケジューラによって考慮される対象のUE１の遅延閾値；及び
（ｄ）対象のUE１のアップリンク送信又はダウンリンク送信の停止要求。

当該制御メッセージは、各UE１の共通識別子、送信元のMECサーバ５の識別子（e.g., IPアドレス, SCEF ID, SCEF Reference ID）、送信先のeNodeB２の識別子、及び制御メッセージの送信方向（アップリンクやダウンリンク）を示す情報のうち少なくとも１つと一緒に送信されてもよい。

UE１のアプリケーションとMECアプリケーションとの間の１回の通信イベントは、通信トランザクション又は通信フローと言うこともできる。１回の通信イベント、通信トランザクション、又は通信フローは、特定のサービスに関する一方向（i.e., DL又はUL）又は双方向（i.e., DL及びUL）のデータ送信を含む。１回の通信イベントは、アプリケーションレイヤにおいて取り扱われるデータ（e.g., 画像データ、又はGlobal Navigation Satellite Systems（GNSS）位置データ）の送信であってもよい。具体例を示すと、例えば、１回の通信イベントは、MECアプリケーションからUE１のアプリケーションへの１又は複数の画像データの送信であってもよい。この場合、通信イベントは、MECサーバ５からUE１への１又は複数の画像データのDL送信を少なくとも含む。さらに、この通信イベントは、UE１からMECサーバ５へのユーザデータ（e.g., 画像データの要求メッセージ、及び画像データ受信に基づく応答メッセージ）のUL送信を含んでもよい。

複数のデータパケットの合計サイズは、１回の通信イベントにおいて、一方向（i.e., DL又はUL）送信で送られる複数のデータパケットの合計サイズを示してもよい。これに代えて、複数のデータパケットの合計サイズは、１回の通信イベントにおいて、DL送信される複数のDLデータパケットの合計サイズとUL送信される複数のULデータパケットの合計サイズを示してもよい。

複数のデータパケットの送信デッドラインは、１回の通信イベントに関する複数のデータパケットの送信を完了するべき期限を意味する。送信デッドラインは、アプリケーションによって要求される。送信デッドラインは、UE１によって送信されてもよい。送信デッドラインは、送信期限と言うこともできる。あるいは、送信デッドラインは、アプリケーションによって許容される最大送信遅延と言うこともできる。送信デッドラインは、様々に定義することができる。例えば、送信デッドラインは、アプリケーションレイヤの発信者（sender）（i.e., UE１のアプリケーション又はMECアプリケーション）による送信の完了期限を示してもよい。あるいは、送信デッドラインは、無線レイヤの発信者（i.e., UE１又はeNB２）による送信の完了期限を示してもよい。あるいは、送信デッドラインは、アプリケーションレイヤの受信者（receiver）（i.e., UE１のアプリケーション又はMECアプリケーション）による受信の完了期限を示してもよい。あるいは、送信デッドラインは、無線レイヤの受信者（i.e., UE１又はeNodeB２）による受信の完了期限を示してもよい。あるいは、より具体的に、送信デッドラインは、アプリケーションレイヤの発信者（sender）が１回の通信イベントに関する最初のデータパケットを送信開始してからアプリケーションレイヤの受信者（receiver）が１回の通信イベントに関する最後のデータパケットを受信完了する期限を示してもよい。あるいは、また、送信デッドラインは、無線レイヤの発信者が１回の通信イベントに関する最初のデータパケットを送信開始してから無線レイヤの受信者が１回の通信イベントに関する最後のデータパケットを受信完了する期限を示してもよい。

UE１とMECアプリケーションとの間の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインは、eNodeB２の動作をMECアプリケーションの通信特性に適応させるためにeNodeB２によって使用される。言い換えると、合計サイズ及び送信デッドラインを示す当該MEC制御情報は、eNodeB２がeNodeB２の動作をMECアプリケーションの通信特性に適応させることを支援する。具体的には、eNodeB２は、当該通信イベントに関するeNodeB２によるDL送信履歴又はUE１によるUL送信履歴を取得し、取得した送信履歴と上述の合計サイズに基づいて残りの未送信データパケットのサイズを計算してもよい。

MECサーバ５は、MEC制御情報を、eNodeB２から送信された制御メッセージに含まれる内容に基づいて決定または変更してもよい。またMECサーバ５は、eNodeB５から送信された各UE１の無線チャネル品質（e.g., Channel Quality Indicator（CQI））に基づいて、スループットまたは送信デッドラインが達成される確率を判断してもよく、当該確率基づいてMEC制御情報を決定または変更してもよい。

各UE１の優先度レベルは、eNodeB２のスケジューラによって考慮される。各UE１の遅延閾値（又はdelay budget）もeNodeB２のスケジューラによって考慮される。幾つかの実装において、eNodeB２のスケジューラは、受信した優先度レベルに基づいて複数のUE１を優先度付けし（prioritize）、各送信ピリオド（i.e., サブフレーム）にスケジュールされる１又はそれ以上のUEs１を選択してもよい。幾つかの実装おいて、eNodeB２のスケジューラは、Earliest Deadline First（EDF）アプローチに基づくスケジューリング・メトリック（i.e., EDFメトリック）を用いてもよい。EDFメトリックは、遅延閾値（delay threshold）とhead of line delayとの差分の逆数に比例する。head of line delayは、ユーザの送信待ちの先頭パケットの遅延を意味する。

アップリンク送信又はダウンリンク送信の停止要求は、指定されたUE１のアップリンク送信又はダウンリンク送信へのリソース割り当ての停止をeNodeB２に要求する。当該停止要求は、停止期間を示してもよい。

最後に、上述の複数の実施形態に係るMECサーバ５、eNodeB２、MME６、及びHSS９の構成例について説明する。図２０は、MECサーバ５の構成例を示すブロック図である。図２０を参照すると、MECサーバ５は、ネットワークインターフェース２００１、プロセッサ２００２、及びメモリ（ストレージ）２００３を含むハードウェア・コンポーネントを備える。ネットワークインターフェース２００１は、eNodeB２、MME６、HSS９、及びその他のネットワークノードと通信するために使用される。ネットワークインターフェース２００１は、例えば、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２）及びコアネットワークノード（e.g., MME６及びHSS９）との通信サービスを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２の処理を行うよう構成されてもよい。

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

プロセッサ２２０２は、例えば、マイクロプロセッサ、MPU）、又はCPUであってもよい。プロセッサ２２０２は、複数のプロセッサを含んでもよい。

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

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

HSS９も、図２２に示されたMME６と同様の構成を有してもよい。

図２０〜図２２を用いて説明したように、上述の実施形態に係るMECサーバ５、eNodeB２、MME６、及びHSS９が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（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）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
既に述べたように、上述の実施形態は、現在3GPPにより標準化作業が行われている第5世代移動通信システム（5G）に適用されてもよい。第5世代移動通信システムは、Next Generation (NextGen) System（NG System）とも呼ばれる。NG Systemのための新たなRATは、New Radio（NR）、5G RAT、又はNG RATと呼ばれる。NG Systemのための新たな無線アクセスネットワーク（Radio Access Network（RAN））及びコアネットワークは、それぞれNextGen RAN（NG RAN）又はNew RAN、及びNextGen Core（NG Core）と呼ばれる。NG Systemに接続する無線端末（User Equipment（UE））は、NextGen UE（NG UE）と呼ばれる。New Radio（NR）をサポートする基地局は、NG NodeB（NG NB）、NR NodeB（NR NB）、又はgNBと呼ばれる。LTEのMME、HSS、及びS/P-GWのコントロールプレーン等に相当するNG Core内の１又はそれ以上のコントロールプレーン・エンティティは、コントロールプレーン・ネットワーク機能（Control Plane Network Functions（CP NFs））と呼ばれる。LTEのS/P-GWのユーザプレーンに相当するNG Core内の１又はそれ以上のユーザープレーン・エンティティは、ユーザプレーン・ネットワーク機能（User Plane Network Functions（UP NFs））と呼ばれる。NG SystemのためのRAT、UE、無線アクセスネットワーク、コアネットワーク、ネットワーク・エンティティ（ノード）、及びプロトコルレイヤ等の正式な名称は、標準化作業が進む過程で将来的に決定されるであろう。

上述の第１〜第９の実施形態では、MECサーバ５がRANノードとしてのeNodeB２に結合される例を示した。これらに代えて、MECサーバ５は、他のRANノードに結合されてもよい。MECサーバ５は、Home eNodeB Gateway（HeNB-GW）又はX2 Gateway（X2-GW）に結合されてもよい。あるいは、MECサーバ５は、HeNB-GW及びX2-GWの機能を共に有する統合されたRANノードに結合されてもよい。HeNB-GWは、HeNBとEPC４との間に配置され、HeNBとEPC４（i.e., MME６）との間でコントロールプレーン信号（i.e., S1APメッセージ）を中継する。さらに、HeNB-GWは、S/P-GW７（又は仮想化S/P-GW８）とのS1-Uインタフェース及びHeNBとのS1-Uインタフェースを終端してもよい。X2-GWは、２つのeNodeBの間に配置され、これら２つのeNodeBの間でコントロールプレーン信号（i.e.,X2APメッセージ）を中継する。さらに、X2-GWは、２つのeNodeBの間でユーザプレーンデータを中継してもよい。

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

例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記Ａ１）
ネットワーク・エンティティであって、
少なくとも１つのメモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子が変更されるたびに、前記第２の識別子の更新された値を前記無線アクセスネットワークノード又は移動管理エンティティから受信するよう構成され、且つ
前記第２の識別子を使用して前記無線アクセスネットワークノードと通信するよう構成されている、
ネットワーク・エンティティ。

（付記Ａ２）
前記少なくとも１つのプロセッサは、前記第２の識別子を、前記無線端末の識別のためにサービス、アプリケーション、又は前記ネットワーク・エンティティにより使用される第１の識別子に関連付けるよう構成されている、
付記Ａ１に記載のネットワーク・エンティティ。

（付記Ａ３）
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作する、
付記Ａ１又はＡ２に記載のネットワーク・エンティティ。

（付記Ａ４）
前記ネットワーク・エンティティは、前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
付記Ａ１〜Ａ３のいずれか１項に記載のネットワーク・エンティティ。

（付記Ａ５）
前記第２の識別子は、前記移動管理エンティティによって割り当てられ、
前記少なくとも１つのプロセッサは、前記移動管理エンティティの変更を伴う前記無線端末のモビリティに起因して前記第２の識別子が変更された場合に、前記第２の識別子の更新された値を、前記モビリティの前の古い移動管理エンティティ、前記モビリティの後の新しい移動管理エンティティ、又は前記無線アクセスネットワークノードから受信するよう構成されている、
付記Ａ１〜Ａ４のいずれか１項に記載のネットワーク・エンティティ。

（付記Ａ６）
前記第２の識別子は、MME UE S1AP IDを含む、
付記Ａ５に記載のネットワーク・エンティティ。

（付記Ａ７）
前記第２の識別子は、前記無線端末のユーザデータ転送を提供するユーザプレーン・ノードによって割り当てられ、
前記少なくとも１つのプロセッサは、前記ユーザプレーン・ノードの変更を伴う前記無線端末のモビリティに起因して前記第２の識別子が変更された場合に、前記第２の識別子の更新された値を、前記移動管理エンティティ又は前記無線アクセスネットワークノードから受信するよう構成されている、
付記Ａ１〜Ａ４のいずれか１項に記載のネットワーク・エンティティ。

（付記Ａ８）
前記第２の識別子は、S1 S-GW TEIDを含む、
付記Ａ７に記載のネットワーク・エンティティ。

（付記Ａ９）
前記第２の識別子は、前記無線アクセスネットワークノードによって割り当てられ、
前記少なくとも１つのプロセッサは、前記無線アクセスネットワークノードの変更を伴う前記無線端末のモビリティ又は前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移に起因して前記第２の識別子が変更された場合に、前記第２の識別子の更新された値を、前記モビリティの前の古い無線アクセスネットワークノード、前記モビリティの後の新しい無線アクセスネットワークノード、又は前記移動管理エンティティから受信するよう構成されている、
付記Ａ１〜Ａ４のいずれか１項に記載のネットワーク・エンティティ。

（付記Ａ１０）
前記第２の識別子は、C-RNTI、eNB UE S1AP ID、及びS1 eNB TEIDのうち少なくとも１つを含む、
付記Ａ９に記載のネットワーク・エンティティ。

（付記Ａ１１）
ネットワーク・エンティティにおける方法であって、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子が変更されるたびに、前記第２の識別子の更新された値を前記無線アクセスネットワークノード又は移動管理エンティティから受信すること、及び
前記第２の識別子を使用して前記無線アクセスネットワークノードと通信すること、
を備える、方法。

（付記Ａ１１）
ネットワーク・エンティティにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子が変更されるたびに、前記第２の識別子の更新された値を前記無線アクセスネットワークノード又は移動管理エンティティから受信すること、及び
前記第２の識別子を使用して前記無線アクセスネットワークノードと通信すること、
を備える、プログラム。

（付記Ｂ１）
無線アクセスネットワークに配置される無線アクセスネットワークノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
ソース無線アクセスネットワークノードからの無線端末の内向きハンドオーバ手順において、ネットワーク・エンティティとの通信に関するコンテキストを前記ソース無線アクセスネットワークノード又は移動管理エンティティから受信するよう構成され、且つ
前記コンテキストを用いて前記ネットワーク・エンティティと通信するよう構成されており、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
無線アクセスネットワークノード。

（付記Ｂ２）
前記コンテキストは、前記ネットワーク・エンティティの識別子を含む、
付記Ｂ１に記載の無線アクセスネットワークノード。

（付記Ｂ３）
前記少なくとも１つのプロセッサは、前記無線端末が接続する無線アクセスネットワークノードが変更されたことを前記ネットワーク・エンティティに通知するよう構成されている、
付記Ｂ１又はＢ２に記載の無線アクセスネットワークノード。

（付記Ｂ４）
前記少なくとも１つのプロセッサは、前記無線端末の識別のために使用される第２の識別子が変更されたことを前記ネットワーク・エンティティに通知するよう構成されている、
付記Ｂ１〜Ｂ３のいずれか１項に記載の無線アクセスネットワークノード。

（付記Ｂ５）
前記第２の識別子は、C-RNTI、eNB UE S1AP ID、及びS1 eNB TEIDのうち少なくとも１つを含む、
付記Ｂ４に記載の無線アクセスネットワークノード。

（付記Ｂ６）
無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法であって、
ソース無線アクセスネットワークノードからの無線端末の内向きハンドオーバ手順において、ネットワーク・エンティティとの通信に関するコンテキストを前記ソース無線アクセスネットワークノード又は移動管理エンティティから受信すること、及び
前記コンテキストを用いて前記ネットワーク・エンティティと通信すること、
を備え、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
方法。

（付記Ｂ７）
無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
ソース無線アクセスネットワークノードからの無線端末の内向きハンドオーバ手順において、ネットワーク・エンティティとの通信に関するコンテキストを前記ソース無線アクセスネットワークノード又は移動管理エンティティから受信すること、及び
前記コンテキストを用いて前記ネットワーク・エンティティと通信すること、
を備え、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
プログラム。

（付記Ｃ１）
移動管理エンティティであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
移動管理エンティティの変更を伴う無線端末のモビリティ手順において、ネットワーク・エンティティとの通信に関するコンテキストを旧移動管理エンティティから受信するよう構成され、且つ
前記コンテキストを用いて前記ネットワーク・エンティティと通信するよう構成されており、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
移動管理エンティティ。

（付記Ｃ２）
前記コンテキストは、前記ネットワーク・エンティティの識別子を含む、
付記Ｃ１に記載の移動管理エンティティ。

（付記Ｃ３）
前記少なくとも１つのプロセッサは、前記無線端末の移動管理を提供する移動管理ノードが変更されたことを前記ネットワーク・エンティティに通知するよう構成されている、
付記Ｃ１又はＣ２に記載の移動管理エンティティ。

（付記Ｃ４）
前記少なくとも１つのプロセッサは、前記無線端末の識別のために使用される第２の識別子が変更されたことを前記ネットワーク・エンティティに通知するよう構成されている、
付記Ｃ１〜Ｃ３のいずれか１項に記載の移動管理エンティティ。

（付記Ｃ５）
前記第２の識別子は、C-RNTI、MME UE S1AP ID、eNB UE S1AP ID、S1 S-GW TEID、及びS1 eNB TEIDのうち少なくとも１つを含む、
付記Ｃ４に記載の移動管理エンティティ。

（付記Ｃ６）
移動管理エンティティにおける方法であって、
移動管理エンティティの変更を伴う無線端末のモビリティ手順において、ネットワーク・エンティティとの通信に関するコンテキストを旧移動管理エンティティから受信すること、及び
前記コンテキストを用いて前記ネットワーク・エンティティと通信すること、
を備え、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
方法。

（付記Ｃ７）
移動管理エンティティにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
移動管理エンティティの変更を伴う無線端末のモビリティ手順において、ネットワーク・エンティティとの通信に関するコンテキストを旧移動管理エンティティから受信すること、及び
前記コンテキストを用いて前記ネットワーク・エンティティと通信すること、
を備え、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
プログラム。

（付記Ｄ１）
無線アクセスネットワークに配置される無線アクセスネットワークノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、制御メッセージをネットワーク・エンティティに送信するよう構成され、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作し、
前記制御メッセージは、以下のうち少なくとも１つを示す：
（ａ）各無線端末の無線リンク品質情報；
（ｂ）各無線端末のためのダウンリンク送信バッファ内のデータ量；
（ｃ）各無線端末のためのアップリンク送信バッファ内のデータ量；
（ｄ）各無線端末のダウンリンク送信データの破棄回数；
（ｅ）各無線端末のアップリンク送信データの破棄回数；
（ｆ）各無線端末の破棄されたダウンリンク送信データ量；及び
（ｇ）各無線端末の破棄されたアップリンク送信データ量、
無線アクセスネットワークノード。

（付記Ｄ２）
ネットワーク・エンティティであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、制御メッセージを無線アクセスネットワークノードに送信するよう構成され、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作し、
前記制御メッセージは、以下のうち少なくとも１つを示す：
（ａ）前記無線端末の通信イベントで送信される複数のデータパケットの合計サイズと前記複数のデータパケットの送信デッドライン；
（ｂ）前記無線アクセスネットワークノードのアップリンク・スケジューラ又はダウンリンク・スケジューラによって考慮される前記無線端末又は他の無線端末の端末優先度レベル；
（ｃ）前記アップリンク・スケジューラ又は前記ダウンリンク・スケジューラによって考慮される前記無線端末の遅延閾値；及び
（ｄ）前記無線端末のアップリンク送信又はダウンリンク送信の停止要求、
ネットワーク・エンティティ。

（付記Ｄ３）
無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法であって、
制御メッセージをネットワーク・エンティティに送信することを備え、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作し、
前記制御メッセージは、以下のうち少なくとも１つを示す：
（ａ）各無線端末の無線リンク品質情報；
（ｂ）各無線端末のためのダウンリンク送信バッファ内のデータ量；
（ｃ）各無線端末のためのアップリンク送信バッファ内のデータ量；
（ｄ）各無線端末のダウンリンク送信データの破棄回数；
（ｅ）各無線端末のアップリンク送信データの破棄回数；
（ｆ）各無線端末の破棄されたダウンリンク送信データ量；及び
（ｇ）各無線端末の破棄されたアップリンク送信データ量、
方法。

（付記Ｄ４）
ネットワーク・エンティティにおける方法であって、
制御メッセージを無線アクセスネットワークノードに送信することを備え、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作し、
前記制御メッセージは、以下のうち少なくとも１つを示す：
（ａ）前記無線端末の通信イベントで送信される複数のデータパケットの合計サイズと前記複数のデータパケットの送信デッドライン；
（ｂ）前記無線アクセスネットワークノードのアップリンク・スケジューラ又はダウンリンク・スケジューラによって考慮される前記無線端末又は他の無線端末の端末優先度レベル；
（ｃ）前記アップリンク・スケジューラ又は前記ダウンリンク・スケジューラによって考慮される前記無線端末の遅延閾値；及び
（ｄ）前記無線端末のアップリンク送信又はダウンリンク送信の停止要求、
方法。

（付記Ｄ５）
無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、制御メッセージをネットワーク・エンティティに送信することを備え、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作し、
前記制御メッセージは、以下のうち少なくとも１つを示す：
（ａ）各無線端末の無線リンク品質情報；
（ｂ）各無線端末のためのダウンリンク送信バッファ内のデータ量；
（ｃ）各無線端末のためのアップリンク送信バッファ内のデータ量；
（ｄ）各無線端末のダウンリンク送信データの破棄回数；
（ｅ）各無線端末のアップリンク送信データの破棄回数；
（ｆ）各無線端末の破棄されたダウンリンク送信データ量；及び
（ｇ）各無線端末の破棄されたアップリンク送信データ量、
プログラム。

（付記Ｄ６）
ネットワーク・エンティティにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、制御メッセージを無線アクセスネットワークノードに送信することを備え、
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作するか、又は無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作し、
前記制御メッセージは、以下のうち少なくとも１つを示す：
（ａ）前記無線端末の通信イベントで送信される複数のデータパケットの合計サイズと前記複数のデータパケットの送信デッドライン；
（ｂ）前記無線アクセスネットワークノードのアップリンク・スケジューラ又はダウンリンク・スケジューラによって考慮される前記無線端末又は他の無線端末の端末優先度レベル；
（ｃ）前記アップリンク・スケジューラ又は前記ダウンリンク・スケジューラによって考慮される前記無線端末の遅延閾値；及び
（ｄ）前記無線端末のアップリンク送信又はダウンリンク送信の停止要求、
プログラム。

（付記１）
ネットワーク・エンティティであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう移動管理エンティティを設定するために前記移動管理エンティティ又は加入者サーバに要求メッセージを送るよう構成され、
前記移動管理エンティティから直接的に又は前記加入者サーバを介して前記第２の識別子を受信するよう構成され、且つ
前記第２の識別子を使用して前記無線アクセスネットワークノードと通信するよう構成されている、
ネットワーク・エンティティ。

（付記２）
前記少なくとも１つのプロセッサは、前記第２の識別子を、前記無線端末の識別のためにサービス、アプリケーション、又は前記ネットワーク・エンティティにより使用される第１の識別子に関連付けるよう構成されている、
付記１に記載のネットワーク・エンティティ。

（付記３）
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作する、
付記１又は２に記載のネットワーク・エンティティ。

（付記４）
前記ネットワーク・エンティティは、前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
付記１〜３のいずれか１項に記載のネットワーク・エンティティ。

（付記５）
前記要求メッセージは、前記第２の識別子の変更を継続的に報告することを前記移動管理エンティティ又は前記加入者サーバに引き起こし、
前記少なくとも１つのプロセッサは、前記第２の識別子が変更されるたびに、前記第２の識別子の更新された値を前記移動管理エンティティから直接的に又は前記加入者サーバを介して受信するよう構成されている、
付記１〜４のいずれか１項に記載のネットワーク・エンティティ。

（付記６）
前記第２の識別子は、前記無線端末のモビリティに起因して、又は前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移に起因して変更される、
付記５に記載のネットワーク・エンティティ。

（付記７）
前記少なくとも１つのプロセッサは、さらに、前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移の発生を示す通知を、前記移動管理エンティティ又は前記無線アクセスネットワークノードから受信するよう構成されている、
付記１〜６のいずれか１項に記載のネットワーク・エンティティ。

（付記８）
前記少なくとも１つのプロセッサは、さらに、前記無線端末が接続する前記無線アクセスネットワークノードが変更された場合に、前記無線アクセスネットワークノードの変更を示す通知を、前記移動管理エンティティ、変更前の無線アクセスネットワークノード、又は変更後の無線アクセスネットワークノードから受信するよう構成されている、
付記１〜７のいずれか１項に記載のネットワーク・エンティティ。

（付記９）
前記少なくとも１つのプロセッサは、さらに、前記移動管理エンティティの変更を伴う前記無線端末のモビリティに起因して前記第２の識別子が変更された場合に、前記第２の識別子の更新された値を、前記モビリティの前の古い移動管理エンティティ又は前記モビリティの後の新しい移動管理エンティティから受信するよう構成されている、
付記１〜８のいずれか１項に記載のネットワーク・エンティティ。

（付記１０）
前記第２の識別子は、C-RNTI、MME UE S1AP ID、eNB UE S1AP ID、S1 S-GW TEID、及びS1 eNB TEIDのうち少なくとも１つを含む、
付記１〜９のいずれか１項に記載のネットワーク・エンティティ。

（付記１１）
移動管理エンティティであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう前記移動管理エンティティを設定するためにネットワーク・エンティティから直接的に又は加入者サーバを介して送られる要求メッセージを受信するよう構成され、且つ
前記ネットワーク・エンティティに直接的に又は前記加入者サーバを介して前記第２の識別子を送るよう構成されている、
移動管理エンティティ。

（付記１２）
前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作する、
付記１１に記載の移動管理エンティティ。

（付記１３）
前記ネットワーク・エンティティは、前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
付記１１又は１２に記載の移動管理エンティティ。

（付記１４）
前記要求メッセージは、前記第２の識別子の変更を継続的に報告することを前記移動管理エンティティ又は前記加入者サーバに引き起こし、
前記少なくとも１つのプロセッサは、前記第２の識別子が変更されるたびに、前記第２の識別子の更新された値を前記ネットワーク・エンティティに直接的に又は前記加入者サーバを介して前記第２の識別子を送るよう構成されている、
付記１１〜１３のいずれか１項に記載の移動管理エンティティ。

（付記１５）
前記第２の識別子は、前記無線端末のモビリティに起因して、又は前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移に起因して変更される、
付記１４に記載の移動管理エンティティ。

（付記１６）
前記少なくとも１つのプロセッサは、さらに、前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移の発生を前記ネットワーク・エンティティに通知するよう構成されている、
付記１１〜１５のいずれか１項に記載の移動管理エンティティ。

（付記１７）
前記少なくとも１つのプロセッサは、さらに、前記無線端末が接続する前記無線アクセスネットワークノードが変更された場合に、前記無線アクセスネットワークノードの変更を前記ネットワーク・エンティティに通知するよう構成されている、
付記１１〜１６のいずれか１項に記載の移動管理エンティティ。

（付記１８）
前記第２の識別子は、C-RNTI、MME UE S1AP ID、eNB UE S1AP ID、S1 S-GW TEID、及びS1 eNB TEIDのうち少なくとも１つを含む、
付記１１〜１７のいずれか１項に記載の移動管理エンティティ。

（付記１９）
ネットワーク・エンティティにおける方法であって、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう移動管理エンティティを設定するために前記移動管理エンティティ又は加入者サーバに要求メッセージを送ること、
前記移動管理エンティティから直接的に又は前記加入者サーバを介して前記第２の識別子を受信すること、及び
前記第２の識別子を使用して前記無線アクセスネットワークノードと通信すること、
を備える、方法。

（付記２０）
移動管理エンティティにおける方法であって、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう前記移動管理エンティティを設定するためにネットワーク・エンティティから直接的に又は加入者サーバを介して送られる要求メッセージを受信すること、及び
前記ネットワーク・エンティティに直接的に又は前記加入者サーバを介して前記第２の識別子を送ること、
を備える、方法。

（付記２１）
ネットワーク・エンティティにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう移動管理エンティティを設定するために前記移動管理エンティティ又は加入者サーバに要求メッセージを送ること、
前記移動管理エンティティから直接的に又は前記加入者サーバを介して前記第２の識別子を受信すること、及び
前記第２の識別子を使用して前記無線アクセスネットワークノードと通信すること、
を備える、プログラム。

（付記２２）
移動管理エンティティにおける方法をコンピュータに行わせるためのプログラムであって、
無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう前記移動管理エンティティを設定するためにネットワーク・エンティティから直接的に又は加入者サーバを介して送られる要求メッセージを受信すること、及び
前記ネットワーク・エンティティに直接的に又は前記加入者サーバを介して前記第２の識別子を送ること、
を備える、プログラム。

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

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

Claims (18)

1. ネットワーク・エンティティであって、
   少なくとも１つのメモリと、
   前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう移動管理エンティティを設定するために前記移動管理エンティティ又は加入者サーバに要求メッセージを送るよう構成され、
   前記移動管理エンティティから直接的に又は前記加入者サーバを介して前記第２の識別子を受信するよう構成され、且つ
   前記第２の識別子を使用して前記無線アクセスネットワークノードと通信するよう構成され、
   前記第２の識別子は、C-RNTI、MME UE S1AP ID、eNB UE S1AP ID、S1 S-GW TEID、及びS1 eNB TEIDのうち少なくとも１つを含む、
   ネットワーク・エンティティ。
2. 前記少なくとも１つのプロセッサは、前記第２の識別子を、前記無線端末の識別のためにサービス、アプリケーション、又は前記ネットワーク・エンティティにより使用される第１の識別子に関連付けるよう構成されている、
   請求項１に記載のネットワーク・エンティティ。
3. 前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作する、
   請求項１又は２に記載のネットワーク・エンティティ。
4. 前記ネットワーク・エンティティは、前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
   請求項１〜３のいずれか１項に記載のネットワーク・エンティティ。
5. 前記要求メッセージは、前記第２の識別子の変更を継続的に報告することを前記移動管理エンティティ又は前記加入者サーバに引き起こし、
   前記少なくとも１つのプロセッサは、前記第２の識別子が変更されるたびに、前記第２の識別子の更新された値を前記移動管理エンティティから直接的に又は前記加入者サーバを介して受信するよう構成されている、
   請求項１〜４のいずれか１項に記載のネットワーク・エンティティ。
6. 前記第２の識別子は、前記無線端末のモビリティに起因して、又は前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移に起因して変更される、
   請求項５に記載のネットワーク・エンティティ。
7. 前記少なくとも１つのプロセッサは、さらに、前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移の発生を示す通知を、前記移動管理エンティティ又は前記無線アクセスネットワークノードから受信するよう構成されている、
   請求項１〜６のいずれか１項に記載のネットワーク・エンティティ。
8. 前記少なくとも１つのプロセッサは、さらに、前記無線端末が接続する前記無線アクセスネットワークノードが変更された場合に、前記無線アクセスネットワークノードの変更を示す通知を、前記移動管理エンティティ、変更前の無線アクセスネットワークノード、又は変更後の無線アクセスネットワークノードから受信するよう構成されている、
   請求項１〜７のいずれか１項に記載のネットワーク・エンティティ。
9. 前記少なくとも１つのプロセッサは、さらに、前記移動管理エンティティの変更を伴う前記無線端末のモビリティに起因して前記第２の識別子が変更された場合に、前記第２の識別子の更新された値を、前記モビリティの前の古い移動管理エンティティ又は前記モビリティの後の新しい移動管理エンティティから受信するよう構成されている、
   請求項１〜８のいずれか１項に記載のネットワーク・エンティティ。
10. 移動管理エンティティであって、
    少なくとも１つのメモリと、
    前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
    を備え、
    前記少なくとも１つのプロセッサは、
    無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう前記移動管理エンティティを設定するためにネットワーク・エンティティから直接的に又は加入者サーバを介して送られる要求メッセージを受信するよう構成され、且つ
    前記ネットワーク・エンティティに直接的に又は前記加入者サーバを介して前記第２の識別子を送るよう構成され、
    前記第２の識別子は、C-RNTI、MME UE S1AP ID、eNB UE S1AP ID、S1 S-GW TEID、及びS1 eNB TEIDのうち少なくとも１つを含む、
    移動管理エンティティ。
11. 前記ネットワーク・エンティティは、Third Generation Partnership Project（3GPP）標準に規定されたService Capability Exposure Function（SCEF）として動作する、
    請求項１０に記載の移動管理エンティティ。
12. 前記ネットワーク・エンティティは、前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバとして動作する、
    請求項１０又は１１に記載の移動管理エンティティ。
13. 前記要求メッセージは、前記第２の識別子の変更を継続的に報告することを前記移動管理エンティティ又は前記加入者サーバに引き起こし、
    前記少なくとも１つのプロセッサは、前記第２の識別子が変更されるたびに、前記第２の識別子の更新された値を前記ネットワーク・エンティティに直接的に又は前記加入者サーバを介して前記第２の識別子を送るよう構成されている、
    請求項１０〜１２のいずれか１項に記載の移動管理エンティティ。
14. 前記第２の識別子は、前記無線端末のモビリティに起因して、又は前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移に起因して変更される、
    請求項１３に記載の移動管理エンティティ。
15. 前記少なくとも１つのプロセッサは、さらに、前記無線端末のコネクテッドモードとアイドルモードとの間の状態遷移の発生を前記ネットワーク・エンティティに通知するよう構成されている、
    請求項１０〜１４のいずれか１項に記載の移動管理エンティティ。
16. 前記少なくとも１つのプロセッサは、さらに、前記無線端末が接続する前記無線アクセスネットワークノードが変更された場合に、前記無線アクセスネットワークノードの変更を前記ネットワーク・エンティティに通知するよう構成されている、
    請求項１０〜１５のいずれか１項に記載の移動管理エンティティ。
17. ネットワーク・エンティティにおける方法であって、
    無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう移動管理エンティティを設定するために前記移動管理エンティティ又は加入者サーバに要求メッセージを送ること、
    前記移動管理エンティティから直接的に又は前記加入者サーバを介して前記第２の識別子を受信すること、及び
    前記第２の識別子を使用して前記無線アクセスネットワークノードと通信すること、
    を備え、
    前記第２の識別子は、C-RNTI、MME UE S1AP ID、eNB UE S1AP ID、S1 S-GW TEID、及びS1 eNB TEIDのうち少なくとも１つを含む、
    方法。
18. 移動管理エンティティにおける方法であって、
    無線端末の識別のために無線アクセスネットワークノードにより使用される第２の識別子を報告するよう前記移動管理エンティティを設定するためにネットワーク・エンティティから直接的に又は加入者サーバを介して送られる要求メッセージを受信すること、及び
    前記ネットワーク・エンティティに直接的に又は前記加入者サーバを介して前記第２の識別子を送ること、
    を備え、
    前記第２の識別子は、C-RNTI、MME UE S1AP ID、eNB UE S1AP ID、S1 S-GW TEID、及びS1 eNB TEIDのうち少なくとも１つを含む、
    方法。

Images