JP2024001281A - Ｕｅ及び通信方法 - Google Patents

Abstract

【課題】通信におけるセキュリティリスクを低減することができる通信システムを提供すること。【解決手段】通信システム（１００）は、Ｌ２ＩＤ（Layer 2 Identity）及び検証情報を含むメッセージを送信する第１のＵＥ（ユーザ機器）（１１０）と、第１のＵＥ（１１０）からメッセージを受信し、検証情報を用いてＬ２ＩＤを受け入れるか否かを判定する第２のＵＥ（１２０）と、を備える。【選択図】図１

Description

本開示は、通信システム、ユーザ機器、通信方法およびコンピュータ可読媒体に関する。

移動通信技術についての発展があった。例えば、３ＧＰＰ（3rd Generation Partnership Project）のリリース１４およびリリース１５では、ＬＴＥ（Long Term Evolution）におけるＶ２Ｘ（Vehicle-to-Everything）通信が定義されている。

Ｖ２Ｘ通信に関して、非特許文献１にはＶ２ＸサービスのＬＴＥサポートのセキュリティ面に関する研究が記載されている。非特許文献１には、車両が追跡されて、プライバシーが侵害される危険性が指摘されている。

3GPP TS 33.185: "Security aspect for LTE support of Vehicle-to-Everything (V2X) services", 2017

以上のような状況を考慮して、本開示は、通信におけるセキュリティリスクを低減することができる通信システム、ユーザ機器、通信方法及びコンピュータ可読媒体を提供することを目的とする。

第１の例示的な態様における、通信システムは、
Ｌ２ＩＤ（Layer 2 Identity）及び検証情報を含むメッセージを送信する第１のＵＥ（ユーザ機器）と、
前記第１のＵＥから前記メッセージを受信し、前記検証情報を用いて前記Ｌ２ＩＤを受け入れるか否かを判定する第２のＵＥと、を備える。

第２の例示的な態様における、ＵＥ（ユーザ機器）は、
Ｌ２ＩＤ及び検証情報を含むメッセージを他のＵＥに送信する送信手段を備え、
前記検証情報は、別のＵＥが新しい前記Ｌ２ＩＤを受け入れるか否かを判定することを可能にする。

第３の例示的な態様における、ＵＥ（ユーザ機器）は、
他のＵＥからＬ２ＩＤ及び検証情報を含むメッセージを受信する受信手段と、
前記検証情報を用いて前記Ｌ２ＩＤを受け入れるか否かを判定する判定手段と、を備える。

第４の例示的な態様における、通信方法は、
Ｌ２ＩＤ及び検証情報を含むメッセージをＵＥへ送信し、
前記検証情報は、前記ＵＥが新しい前記Ｌ２ＩＤを受け入れるか否かを判定することを可能にする、方法である。

第５の例示的な態様における、通信方法は、
ＵＥからＬ２ＩＤ及び検証情報を含むメッセージを受信し、
前記検証情報を用いて前記Ｌ２ＩＤを受け入れるか否かを判定する、方法である。

第６の例示的な態様における、非一時的なコンピュータ可読媒体は、
Ｌ２ＩＤ及び検証情報を含むメッセージをＵＥに送信する処理をコンピュータに実行させ、
前記検証情報によって、前記ＵＥが新しい前記Ｌ２ＩＤを受け入れるか否かを判定することを可能にする、
プログラムを格納した非一時的なコンピュータ可読媒体である。

第７の例示的な態様における、非一時的なコンピュータ可読媒体は、
ＵＥからＬ２ＩＤと検証情報を含むメッセージを受信する処理と、
前記検証情報を用いて前記Ｌ２ＩＤを受け入れるか否かを判定する処理と、
をコンピュータに実行させるためのプログラムを格納した非一時的なコンピュータ可読媒体である。

本開示によれば、通信におけるセキュリティリスクを低減することができる通信システム、ユーザ機器、通信方法及びコンピュータ可読媒体を提供することができる。

図１は、通信システムのブロック図である。 図２は、通信システムの手順を示すシーケンス図である。 図３は、送信側のＫＤＦ関数の一例を示す図である。 図４は、受信側のＫＤＦ関数の一例を示す図である。 図５は、送信側のＫＤＦ関数の一例を示す図である。 図６は、受信側のＫＤＦ関数の一例を示す図である。 図７は、通信システムの手順を示すシーケンス図である。 図８は、通信システムの手順を示すシーケンス図である。 図９Ａは、送信元ＵＥからの繰り返しメッセージを示す図である。 図９Ｂは、ＵＥからの中継メッセージを示す図である。 図９Ｃは、ＵＥからのフラッディングされたメッセージを示す図である。 図９Ｄは、ＵＥから繰り返され、中継され、およびフラッディングされたメッセージの組み合わせを示す図である。 図１０は、新しいシーケンス番号を導出するためのＫＤＦ関数の一例を示す図である。 図１１は、Ｌ２ＩＤを再確立するメカニズムを示すシーケンス図である。 図１２は、「デフォルト」Ｌ２ＩＤを提供するメカニズムを示すシーケンス図である。 図１３は、移動通信システム１を示す図である。 図１４は、ＵＥ３の主要な構成要素を示すブロック図である。 図１５は、例示的な（Ｒ）ＡＮノード５の主要な構成要素を示すブロック図である。 図１６は、例示的なコアネットワークノードの主要な構成要素を示すブロック図である。

本開示の実施の形態を説明する前に、以下の説明を行う。

（略語）
本開示の目的のために、以下の略語が適用される。
3GPP 3rd Generation Partnership Project
4G 4th Generation
5G 5th Generation
5GC 5G Core Network
5GS 5G System
AF Application Function
AMF Access and Mobility Management Function
AN Access Node
AID Application Identifier
AKA Authentication and Key Agreement
ARPF Authentication credential Repository and Processing Function
AS Access Stratum
AUSF Authentication Server Function
CP Control Plane
D2D Device to Device
EAP Extensible Authentication Protocol
eNB evolved NodeB
EPS Evolved Packet System
EPC Evolved Packet Core
ETSI European Telecommunications Standards Institute
E-UTRA Evolved Universal Terrestrial Radio Access
gNB next Generation NodeB
IEEE Institute of Electrical and Electronics Engineers
IoT Internet of Things
ITS Intelligent Transport Systems
KDF Key Derivation Function
L2 ID Layer 2 Identity
LTE Long Term Evolution ("4G")
M2M Machine to Machine
MAC Message Authentication Code
MBMS Multimedia Broadcast and Multicast Service
MitM Man in the Middle
MME Mobility Management Entity
MTC Machine Type Communication
MVNO Mobile Virtual Network Operator
NAS Non-Access Stratum
NB-IoT Narrow Band IoT
NEF Network Exposure Function
NF Network Function
NG-RAN Next Generation Radio Access Network
NID Network identifier
NR New Radio (5G)
NRF Network Repository Function
NW NetWork
PCF Policy Control Function
PLMN Public Land Mobile Network
PSID Provider Service IDentity
QoS Quality of Service
(R)AN (Radio) Access Network
RRC Radio Resource Control
SEAF Security Anchor Functionality
SIDF Subscription Identifier De-concealing Function
SMF Session Management Function
UDM Unified Data Management
UE User Equipment
UPF User Plane Function
UDR Unified Data Repository
V2X Vehicle to Everything

（定義）
本開示の目的のために、以下の定義が適用される。
ＰＣ５ ２つ以上のＵＥ間の無線インタフェース
Ｕｕ ＵＥと基地局間の無線インタフェース
グループキャスト グループ内の２つ以上のメンバーが相互に通信する通信モード。グループのメンバーシップは、管理されていてもされていなくてもよい。管理されている場合は、アプリケーション層で行うことが想定されている。管理されていない場合は、事前設定などの他の方法でグループのメンバーシップを定義するものとする。

（関連技術）
前述の通り、３ＧＰＰ（3rd Generation Partnership Project）のリリース１４およびリリース１５では、ＬＴＥにおけるＶ２Ｘ（Vehicle-to-Everything）通信が定義されている。３ＧＰＰ ＳＡ ＷＧ１（ＳＡ１）によるステージ１の仕様は、Ｖ２Ｘ通信のアーキテクチャおよびセキュリティ要件を定義している。リリース１６のＳＡ１で指定された高度なユースケースに基づいて、５Ｇ Ｖ２Ｘを含むように追加のアーキテクチャ拡張が定義される。これらの仕様に基づき、ＬＴＥ Ｖ２Ｘ通信は、ＬＴＥ Ｕｕインタフェース上での通信とＬＴＥ ＰＣ５インタフェース上で通信との２種類の通信をサポートする。ＬＴＥ Ｕｕインタフェースはユニキャストモードの通信のみをサポートし、ＬＴＥ ＰＣ５インタフェースはブロードキャストのみをサポートする。

ＬＴＥ ＰＣ５インタフェース上での通信において、３ＧＰＰ層上では最小限のセキュリティの考慮と仕組みのみであり、ほとんどのセキュリティの仕組みはアプリケーション層で対応することが想定されている。これは、ＩＥＥＥ ８０２．１１ｐ、ＩＥＥＥ １６０９、およびＥＴＳＩ ＩＴＳなどの他のＶ２Ｘ規格と一致する。３ＧＰＰ ＳＡ ＷＧ２（ＳＡ２）は、リリース１６の５Ｇ ＮＲベースＶ２Ｘ通信用のリリース１５のステージ１で定義されたアーキテクチャ拡張要件に基づいて、リリース１６のｅＶ２Ｘアーキテクチャ拡張に関する標準作業を完了した。これらの仕様から、５Ｇ Ｖ２Ｘは、ＬＴＥ Ｖ２Ｘと同様に、２種類の通信（５Ｇ Ｕｕインタフェースと５Ｇ ＰＣ５インタフェース）をサポートしている。５Ｇ Ｕｕ上の通信は、ＬＴＥ Ｕｕインタフェースと同様にユニキャストモードのみをサポートしている。一方、５Ｇ ＰＣ５インタフェースでは、ブロードキャストモードに加えて、ユニキャストモードとグループキャストモードとの２つの通信モードをサポートしている。このため、５Ｇ Ｖ２Ｘの新機能を実現するためには、セキュリティ面での追加の検討が必要となり、３ＧＰＰ ＳＡ ＷＧ３（ＳＡ３）では、５ＧにおけるｅＶ２Ｘ通信のセキュリティ面における検討を開始した。Ｒｅｌ－１５ ＬＴＥ Ｖ２Ｘの仕様上のアーキテクチャの拡張は、以下に述べるようないくつかの新しいユースケースに基づいている。

ＬＴＥおよび５Ｇの全体的なセキュリティアーキテクチャは、それぞれ、３ＧＰＰ ＴＳ ３３．４０１：「3GPP System Architecture Evolution（SAE）；Security architecture」および3GPP TS 33.501：「Security architecture and procedures for 5G system」で規定されている。

前述したように、Ｖ２Ｘ通信では、２種類の無線アクセス技術（ＲＡＴｓ）と２種類のインタフェースがあり、結果として合計４種類の通信が行われている。
１． Ｕｕ
ａ） ＬＴＥ Ｕｕ
ｂ） ５Ｇ Ｕｕ
２． ＰＣ５
ａ） ＬＴＥ ＰＣ５
ｂ） ５Ｇ ＰＣ５

これらの動作モードは、各々独立に使用される。ＬＴＥ Ｖ２Ｘ仕様のプライバシー要件には、「ＵＥが複数のブロードキャストメッセージで同じＩＤを使用している場合、車両が追跡されてプライバシーが侵害される可能性がある。」と記されている。これは、車両およびユーザのトレーサビリティおよびリンク可能性につながる恐れがある。上述のプライバシーの問題は、ＰＣ５インタフェースにのみ適用され、Ｕｕインタフェースに適用されないことに注意することが重要である。Ｕｕインタフェースには、既存のＬＴＥ－Ｕｕユニキャストセキュリティソリューションが適用される。

前述のように、ＳＡ２仕様は、ＰＣ５上のＶ２Ｘ通信のための手順を規定しており、レイヤ２リンク確立、リンク識別子更新、レイヤ２リンク解放およびレイヤ２リンク修正を含む。また、現在ＳＡ３で行われている研究では、特にユニキャストおよびグループキャスト通信におけるプライバシーに関して、例えば車両やユーザの送信元のＬ２ＩＤの追跡などのプライバシーの問題をどのように防ぐかが重要な課題となっている。Ｌ２アイデンティティを実在のまたは長期的（恒久的）なｅＶ２Ｘエンドポイントのアイデンティティに接続しリンクする能力を持つ敵対者は、空間と時間を超えてエンドポイントを追跡し、トレースすることができる。このようなトレーサビリティとリンク能力は、ｅＶ２Ｘエンドポイントのプライバシーに対する攻撃となる。

ユニキャスト通信では、受信ピアがメッセージの送信元を識別し続けるために、送信元のＬ２ＩＤの変更が不可欠である。ブロードキャストまたはグループキャストのＶ２Ｘ通信では、宛先Ｌ２ＩＤ＝ブロードキャストＬ２ＩＤまたはグループキャストＬ２ＩＤであり、送信元Ｌ２ＩＤ＝メッセージを送信する個々のグループメンバＵＥのＩＤである。

グループキャストまたはブロードキャストモードでは、送信元Ｌ２ＩＤを変更すると、すべてのグループメンバＵＥがこの変更を追跡して、メッセージの送信元を識別し続ける必要があり、つまり、常に「誰がメッセージをグループに送信したか」を追跡する必要がある。

したがって、ブロードキャストまたはグループキャストモードにおいて、あるＵＥが他のグループメンバＵＥからのＬ２ＩＤ更新メッセージを見逃した場合、受信側ＵＥはブロードキャスト／グループキャストメッセージを受信することはできるものの（宛先Ｌ２ＩＤは変更されない）、受信側ＵＥはもはや「誰がメッセージを送信したか」を識別することができない。このような状況を緩和し、回復可能にする必要がある。

これはまた、悪意のあるＵＥが正当なＵＥの通信を妨害することを回避するために、ＵＥによって開始された送信元Ｌ２ＩＤ変更が受信側のＵＥによって検証可能でなければならないことを意味する。ブロードキャストモードでの通信は、管理されておらず（受信者の番号とＩＤが不明）、またグループキャストでのメンバーシップ管理は、ユニキャスト通信の確立よりも厳しくないため、このような検証可能性が求められる。したがって、ブロードキャストおよびグループキャスト内のすべてのメンバーＵＥは、ＵＥのＬ２ＩＤ変更に関して同期している必要がある。

プライバシー保護については、ＬＴＥおよび５Ｇ Ｖ２Ｘ通信の３ＧＰＰ仕様では、ＵＥがＰＣ５インタフェースを介した通信で同一のＩＤを使用している場合、車両が追跡され、プライバシーが侵害される可能性があると述べられている。したがって、ユーザまたは車両が追跡されるリスクを軽減するために、ＰＣ５インタフェース上の通信プライバシー保護が必要である。
ａ）既存のＳＡ３研究には、ユニキャストモード通信におけるＬ２ＩＤ更新のためのプライバシーとセキュリティ面の解決策が含まれている。ユニキャストモードと同様に、プライバシー保護はブロードキャストおよびグループキャスト動作モードにも同様に適用できる。ブロードキャストモードでは、送信側ＵＥは、誰がブロードキャストメッセージを聞いているかを知らない。グループキャストモードでは、グループを脱退したメンバーＵＥまたはグループキャストの宛先Ｌ２ＩＤを知っている者が、メッセージの送信元（車両またはユーザＩＤ）を追跡して特定できる。
ｂ）ＰＣ５通信での送信元Ｌ２ＩＤの変更は、悪意のあるＵＥが正当なＵＥとそのブロードキャストおよびグループキャスト通信モードを妨害することを回避するために、受信側ＵＥによって検証可能である必要がある。
ｃ）アプリケーション層のメッセージ（例えば基本的な安全メッセージなど）は、Ｌ２ＩＤ更新イベントとは無関係に継続する。アプリケーション層のメッセージには、交通事故を防ぐための安全メッセージが含まれることが多い。これらのメッセージは通常、低遅延の通信を必要とする。Ｌ２ＩＤ変更イベントは、進行中のアプリケーション層のメッセージングを妨害すべきではない。

前述したように、Ｖ２Ｘ通信には、ＰＣ５リファレンスポイント上の通信とＵｕリファレンスポイント上の通信との２つの動作モードがある。これら２つの動作は、ＵＥが送信と受信のために独立して用いることができる。ＰＣ５リファレンスポイントを介したＶ２Ｘ通信は、ＬＴＥやＮＲでサポートされる。Ｕｕリファレンスポイント上のＶ２Ｘ通信は、ＥＰＣまたは５ＧＣに接続されたＥ－ＵＴＲＡおよび／または５ＧＣに接続されたＮＲによってサポートされる。本リリースでは、Ｕｕリファレンスポイントを介したＶ２Ｘ通信は、ユニキャスト送受信のみを使用する。ＬＴＥ ＰＣ５通信では、ブロードキャストモードのみがサポートされている。一方、５Ｇ ＰＣ５では、ユニキャストモードの通信に加えて、ブロードキャストモード及びグループキャストモードがサポートされている。

Ｖ２Ｘ通信手順の識別子：
ａ）各ＵＥは、ＰＣ５リファレンスポイントを介したＶ２Ｘ通信のためのＬ２ＩＤを有する。これは、ＵＥがレイヤ２リンク上で送信する各フレームの送信元レイヤ２ＩＤフィールドに含まれる。ＵＥは、ＰＣ５リファレンスポイントを介したＶ２Ｘ通信のためのレイヤ２ＩＤを自己割り当てする。
ｂ）ＩＰベースのＶ２Ｘメッセージがサポートされている場合、ＵＥは送信元ＩＰアドレスとして使用するリンクローカルＩＰｖ６アドレスを自動設定する。ＵＥは、重複アドレス検出のために近隣探索と近隣広告メッセージを送信せずに、ＰＣ５リファレンスポイント上のＶ２Ｘ通信のために自動設定されたリンクローカルＩＰアドレスを使用することができる。
ｃ）ＵＥが、設定により特定された現在の地理的領域でプライバシーサポートを必要とするアクティブなＶ２Ｘアプリケーションを持っている場合、アプリケーションによって要求される所定の短い時間を超えて、送信元ＵＥ（例えば車両）が他のＵＥ（例えば車両）によって追跡または識別されないようにするために、送信元レイヤ２ＩＤを時間の経過とともに変更し、ランダム化する必要がある。ＰＣ５リファレンスポイントを介したＩＰベースのＶ２Ｘ通信では、送信元ＩＰアドレスも時間の経過とともに変更し、ランダム化する必要がある。送信元ＵＥの識別子の変更は、例えば、アプリケーション層識別子が変更された場合や送信元レイヤ２ＩＤ及び送信元ＩＰアドレスを変更する必要がある場合など、ＰＣ５で使用されるレイヤ間で同期されなければならない。
ｄ）Ｖ２Ｘサービスに使用される宛先レイヤ２ＩＤをＵＥに設定する。Ｖ２Ｘメッセージのレイヤ２ＩＤは、設定に基づいて選択される。
ｅ）ＰＣ５インタフェースで使用される送信元Ｌ２ＩＤは、同じＵＥ内の各動作モードおよび異なるＲＡＴごとに、異なっていてもよい。以下の表は、ＬＴＥ Ｖ２Ｘ及び５Ｇ Ｖ２Ｘの動作モードの違いと送信元Ｌ２ＩＤの違いの概要を示している。異なるＬ２ＩＤに対する異なる指定は、これらのＩＤ値が異なる可能性があることを示す。

表１：ＰＣ５通信用のＲＡＴの種類とモード

これらの送信元Ｌ２ＩＤの各々は、ＵＥによって独立して割り当てられるか、または再割り当てされている。宛先ＩＤは事前に設定されていてもよく、通信モードに依存する。

５ＧにおけるＶ２Ｘのセキュリティに関する調査項目（3GPP TR 33.836: 「Study on security aspects of 3GPP support for advanced V2X services」）には、既存の重要課題と解決策が示されている。ＰＣ５インタフェース上のグループキャストメッセージのプライバシー保護が重要な課題の１つである。

本開示は、主に、移動通信システムにおけるＵＥに対するトレーサビリティ攻撃を軽減する方法に関連し、ブロードキャストおよびグループキャスト通信のプライバシー保護に焦点を当てている。ただし、ユニキャスト通信におけるプライバシー保護にも同様に適用できる。

また、本開示は、送信元Ｌ２ＩＤ更新手順が、ブロードキャスト、グループキャスト、またはユニキャストＶ２Ｘ通信におけるユーザのプライバシー保護をどのように提供するかという文脈において、５ＧにおけるＶ２Ｘ通信をサポートする５Ｇシステムの態様に関する。

（実施形態の説明）
本開示は、複数の実施形態および各実施形態における変形例を説明する。これらの実施形態および変形例は、互いに任意に組み合わせることができる。

（実施形態１：ブロードキャスト及びグループキャストモードにおける検証可能なＬ２ＩＤ更新）
（実施形態１、変形例１ａ、一般的な説明）
この提案された実施形態では、通信システム１００は、図１のＵＥ１１０（第１のＵＥ）およびＵＥ１２０（第２のＵＥ）を備える。図１では、１つのＵＥ１１０および１つのＵＥ１２０が示されているが、複数のＵＥ１１０および／または複数のＵＥ１２０が存在してもよい。

ＵＥ１１０は、Ｌ２ＩＤ（Layer 2 Identity）及び検証情報を含むメッセージをＵＥ１２０に送信する。図１は、ＵＥ１１０が送信部１１１を含み、送信部１１１がＬ２ＩＤおよび検証情報を含むメッセージを他のＵＥ、特にＵＥ１２０に送信することを示している。検証情報により、他のＵＥは新Ｌ２ＩＤを受け入れるか否かを判定することができる。

ＵＥ１２０は、ＵＥ１１０からのメッセージを受信し、検証情報を用いてＬ２ＩＤを受け入れるか否かを判定する。図１より、ＵＥ１２０が受信部１２１および判定部１２２を含む。受信部１２１は、他のＵＥ、特にＵＥ１１０からＬ２ＩＤ及び検証情報を含むメッセージを受信する。判定部１２２は、検証情報を用いてＬ２ＩＤを受け入れるか否かを判定する。

本変形例１ａでは、ＵＥ１１０が検証情報を送信し、ＵＥ１２０がこの情報を用いてＬ２ＩＤを受け入れるか否かを判定する。したがって、ＵＥ１２０は、悪意のあるＵＥからの通信を拒否することができ、通信におけるセキュリティリスクを低減することができる。

（実施形態１、変形例１ｂ、一般的説明）
本変形例１ｂでは、実施形態１をより詳細に説明する。

図２より、送信側ＵＥは、Ｌ２ＩＤ更新要求メッセージにおいて、新たに導出したＬ２ＩＤをピアＵＥに送信する。受信側ＵＥは、更新メッセージの送信者の正当性を検証する。これにより、悪意のあるＵＥがブロードキャスト、グループキャスト、またはユニキャスト通信で、１つまたは複数のＵＥに偽の更新メッセージを送信することを防止できる。セキュリティ（例えば暗号化及び完全性保護）は、アプリケーション層（ＩＥＥＥ８０２．１１ｐ、ＩＥＥＥ １６０９、ＥＴＳＩ ＩＴＳなどの他のＶ２Ｘテクノロジーと一致する）で提供されるものとする。

任意のメンバーＵＥからのメッセージを検証するために、更新メッセージは、当該メッセージが有効なものであるか、すなわち、本物のユーザが送信したことを示す情報を含む。使用される情報要素の例は以下の通りである。
１．現在のＬ２ＩＤ
２．新Ｌ２ＩＤ
３．グループＩＤ（グループキャストのみ）
４．Ｖ２ＸサービスＩＤ（例：ＰＳＩＤまたはＩＴＳ－ＡＩＤ）
５．その他の情報（例：時刻／位置情報）
６．上記情報のＭＡＣ（Message Authentication Code）またはハッシュ値
メッセージフローの例を次の図に示す。本開示では、Ｖ２Ｘは、Ｖ２Ｖ、Ｖ２Ｉ、Ｖ２Ｎ、およびＶ２Ｐを含む。

図２のＳ１ａ～Ｓ１ｃは、送信側のＵＥ（ＵＥ－Ｔｘ）が検証情報を含むＬ２ＩＤ更新要求メッセージを送信することを示す。この情報により、受信側ＵＥはメッセージの送信元の有効性を検証できる。

図２のＳ２ａ～Ｓ２ｃは、受信側ＵＥ（図２のＵＥ－１～ＵＥ－３）が、ＵＥ－ＴｘからのＬ２ＩＤ更新メッセージに含まれる情報を用いて、メッセージの送信元の有効性及び真正性を検証し、受信したメッセージが正当なＵＥによって送信されたものか否かを判定することを示している。メッセージの送信元の有効性及び真正性が確認されると、受信側ＵＥは受信した更新メッセージを受け入れる。確認できない場合、受信側ＵＥは受信した更新メッセージを受け入れない。受信側ＵＥによるこの動作により、悪意のあるＵＥがブロードキャスト、グループキャスト、またはユニキャスト通信に偽の更新メッセージを送信することを防止できる。

ブロードキャストおよびグループキャスト通信の場合、Ｌ２ＩＤ更新メッセージを受信するメンバーＵＥは１つ以上存在できる。ユニキャスト通信の場合、Ｌ２ＩＤ更新メッセージを受信するＵＥは１つのみである。

（実施形態１、変形例２、説明：ブロードキャストおよびグループキャスト通信における検証可能なＬ２ＩＤ更新）
本変形例では、キー導出関数（ＫＤＦ）を導入し、前節で説明したような適切な入力を用いて、新Ｌ２ＩＤとＭＡＣ（または「ハッシュ値」）を導出する。

「ＫＤＦ」という用語は、入力パラメータのセットを受け取り、１つまたは複数の出力パラメータを生成する関数を一般的に指すために使用されることに留意されたい。この特定の例では、ＫＤＦは「キー」を生成しない。しかしながら、この用語は、一般的に、他のタイプの類似の関数に適用することができる。したがって、本開示においてもＫＤＦという用語を使用する。

このＫＤＦの例として、前節で述べたように、これらの入力には、現在のＬ２ＩＤ、サービスタイプ、グループＩＤ（グループキャストのみに適用）、Ｖ２ＸサービスＩＤ（例：ＰＳＩＤまたはＩＴＳ－ＡＩＤ）、及び時刻や位置の情報などの他の情報を含めることができる。これらの入力に基づいて、ＫＤＦ関数の出力として、ＭＡＣ（すなわち、上記情報のハッシュ）及び新Ｌ２ＩＤが生成される。図３は、送信側のＫＤＦ関数の一例を示す。

新Ｌ２ＩＤおよびＭＡＣ値を導出するための例示的な式は、以下のように定義することができる。（新Ｌ２ＩＤ、ＭＡＣ）＝ＫＤＦ（現在のＬ２ＩＤ、グループＩＤ、Ｖ２ＸサービスＩＤ、位置情報または時刻情報など。）。

別の例においては、追加のまたは異なるタイプの入力パラメータを使用してＫＤＦ関数を導出し、同じ結果を達成し、Ｌ２ＩＤ更新メッセージおよび送信者の妥当性を一意に識別することができる。この新しく生成されたＬ２ＩＤとＭＡＣは、グループキャスト、ブロードキャスト、またはユニキャスト通信における、すべてのピアメンバーＵＥで更新される。

受信側ＵＥは、Ｌ２ＩＤ更新メッセージを受信すると、メッセージの送信者の有効性および真正性を検証する。受信側のＵＥは、送信側が使用するものと同じ、ピアの現在のＬ２ＩＤと入力パラメータのセットを使用する。受信側ＵＥは、入力パラメータのＭＡＣ（ハッシュ値）を算出する。次に、受信側ＵＥは、このＭＡＣ（ハッシュ）値をＬ２ＩＤ更新メッセージで受信した値と比較する。これらが一致する場合、受信側ＵＥはメッセージが正当なＵＥからのものであるとみなし、受信したメッセージで送信される新しいＬ２ＩＤを受け入れる。しかしながら、これらが一致しない場合、受信側ＵＥはそのメッセージが悪意のあるＵＥからのものであるとみなし、受信メッセージにおける新Ｌ２ＩＤを拒否する。図４は、受信側のＫＤＦ関数の一例を示す。

本変形例では、送信側ＵＥは、ＫＤＦ関数を用いて新Ｌ２ＩＤと第１のＭＡＣとを生成する生成部を含み、送信部（図１の１１１）は、ＭＡＣを付加してメッセージを送信する。受信側ＵＥは、ＫＤＦを用いて第２のＭＡＣを生成する生成部を備え、判定部（図１の１２２）は、第１のＭＡＣと第２のＭＡＣとを比較して、Ｌ２ＩＤを受け入れるか否かを判定する。ＫＤＦを用いることにより、送信側ＵＥは新しいレイヤ２ＩＤ及びＭＡＣを容易に導出でき、受信側ＵＥは新しいＬ２ＩＤの有効性を容易に判定できる。

（実施形態１、変形例３、説明：リプレイ保護を備えたブロードキャストおよびグループキャスト通信における検証可能なＬ２ＩＤ更新）
実施形態１の変形例２と同様に、本変形例においても、ブロードキャスト、グループキャスト、またはユニキャストモードでＬ２ＩＤ更新を検証する方法を説明する。さらに、リプレイ攻撃を軽減するために、キー導出関数への入力として追加の情報要素が含まれている。本変形例では、キー導出関数（ＫＤＦ）への入力として「シーケンス番号」を導入する。この解決方法の主な利点は、中間者（ＭｉｔＭ）リプレイ攻撃を防ぐ点である。

図５は、送信側のＬ２ＩＤ及びＭＡＣの導出の様子を示しており、図６は、受信側のＭＡＣの導出及びＭＡＣ値の検証の様子を示している。

図５は、図３と同様に、送信側ＵＥが現在のＬ２ＩＤとＫＤＦ関数の入力パラメータを使用することを示している。さらに、送信側ＵＥは、シーケンス番号も使用して、新Ｌ２ＩＤとＭＡＣ（ハッシュ値）を生成する。

実施形態１の変形例２と同様に、受信側ＵＥは、Ｌ２ＩＤ更新メッセージを受信すると、メッセージの送信者の有効性および真正性を検証する。受信側ＵＥは、送信側と同じ、ピアの現在のＬ２ＩＤ及び入力パラメータのセットを使用する。また、ＭＡＣ（ハッシュ値）を生成するために、受信側ＵＥも送信側のＵＥと同じシーケンス番号を使用する。次に、受信側ＵＥは、このＭＡＣ（ハッシュ）値をＬ２ＩＤ更新メッセージで受信した値と比較する。これらが一致する場合、受信側ＵＥはメッセージが正当なＵＥからのものであるとみなし、受信メッセージにおける新Ｌ２ＩＤを受け入れる。しかしながら、これらが一致しない場合、受信側ＵＥは当該メッセージが悪意のあるＵＥからのものであるとみなし、受信メッセージにおける新Ｌ２ＩＤを拒否する。

シーケンス番号を用いることにより、受信したＬ２ＩＤ更新メッセージが以前に送信されたメッセージと重複しないことを確認可能である点に留意されたい。これは、Ｌ２ＩＤ更新メッセージを送信するたびにＵＥがシーケンス番号を増分して送信することによって実現される。

（実施形態１、変形例４、説明：確認なしの一方向更新）
本変形例では、確認なしでＬ２ＩＤを更新するための一方向の更新手順について説明する。本変形例では、送信側ＵＥは、受信側ＵＥからの確認応答を受信せずに、ブロードキャストまたはグループキャストモードで、更新された新Ｌ２ＩＤをピアＵＥに送信する。ブロードキャストまたはグループキャストモードにおいて、例えば受信側ＵＥの数が多い場合、他のＵＥからの確認応答を受信して追跡するためのオーバーヘッドを低減するのに有利である。ブロードキャストモードでは、通信範囲内にどの受信側ＵＥがどれだけ存在するかを事前に知ることはできない。

したがって、この解決方法の主な利点は、グループ内のピアＵＥの数に関係なく、Ｌ２ＩＤ更新手順のスケーラビリティを向上させることである。

また、ピアＵＥによって送信される確認応答がないため、前述のようにオーバーヘッドが軽減される。送信側ＵＥは、すべてのメンバーＵＥからの確認応答を追跡する必要がない。手順の一例を図７に示す。

図７のＳ１では、送信側ＵＥ（ＵＥ－Ｔｘ）が自身のＬ２ＩＤを更新している。
図７のＳ２ａ～Ｓ２ｃは、送信側ＵＥ（ＵＥ－Ｔｘ）が、検証情報（例：ＭＡＣ）を含むＬ２ＩＤ更新要求メッセージを送信することを示す。このＭＡＣ（ハッシュ）値は、実施形態の変形例１または変形例２で説明した方法に基づいて算出される。この情報により、受信側ＵＥはメッセージの送信元の有効性を確認できる。
図７のＳ３ａ～Ｓ３ｃは、受信側ＵＥ（図７のＵＥ－１～ＵＥ－３）が、ＵＥ－ＴｘからのＬ２ＩＤ更新メッセージに含まれる情報を用いて、メッセージの送信元の有効性及び真正性を検証し、受信したメッセージが正当なＵＥによって送信されたものか否かを判定することを示す。メッセージの送信元の有効性及び真正性が確認されると、受信側ＵＥは受信した更新メッセージを受け入れる。確認できない場合には、受信側ＵＥは受信した更新メッセージを受け入れない。受信側ＵＥによるこの動作は、悪意のあるＵＥがブロードキャスト、グループキャスト、またはユニキャスト通信で偽の更新メッセージを送信することを防止する。

（実施形態１、変形例５、説明：確認付き双方向更新）
本変形例では、受信側ＵＥは、Ｌ２ＩＤ更新応答メッセージを送信することによって、第１のＵＥからのＬ２ＩＤ更新に対する確認応答を送信する。このように、この解決方法の変形例によれば、送信側ＵＥが、通信中の他のＵＥからの確認応答を追跡することができる。したがって、本変形例では、常に新Ｌ２ＩＤの同期更新が保証される。

本変形例の主な利点は、送信側ＵＥが、受信側ＵＥによってＬ２ＩＤ更新メッセージを正常に受信されたか否かを認識することである。本変形例は、グループ内の少数のＵＥからなるグループキャストモード通信において有利である。手順の一例を図８に示す。

図８のＳ１は、実施形態１の変形例４の図７のＳ１と同じである。
図８のＳ２ａ～Ｓ２ｃは、実施形態１の変形例４の図７のＳ２ａ～Ｓ２ｃと同じである。
図８のＳ３ａ～Ｓ３ｃは、実施形態１の変形例４の図７のＳ３ａ～Ｓ３ｃと同じである。
図８のＳ４ａ～Ｓ４ｃは、受信側ＵＥ（ＵＥ－１～ＵＥ－３）がＵＥ－Ｔｘに対して検証の成功・失敗を示すＬ２ＩＤ更新応答を送信することを示している。

（実施形態１、変形例６、説明：ＫＤＦアルゴリズム交渉）
この解決方法の変形例は、実施形態１の変形例１、および変形例２で説明したように、通信ＵＥがＫＤＦについて交渉し、合意するためのメカニズムを導入する。本変形例では、通信ＵＥ間におけるＫＤＦ関数の可能な違いまたは変形の概念を導入する。この場合、本変形例では、通信中のＵＥがそのサポートするＫＤＦ関数の１つ以上を交換し、すべてのＵＥが同意できるＫＤＦを交渉することができる。

一例では、ＫＤＦ関数の交渉は、グループキャストまたはユニキャスト通信が確立された時点で行うことができる。

本変形例は、ＵＥによるＫＤＦ関数の異なる実装バリエーションを説明するのに有利である。さらに、本変形例は、ユニキャスト通信または少数のメンバーＵＥとのグループキャスト通信で有用である。本変形例は、ＵＥの数が事前に知られていないブロードキャスト通信や通信に参加するメンバーが多いグループキャストモードには適していない可能性があることに留意されたい。

（実施形態１、変形例７、説明：ＫＤＦ入力パラメータ交渉）
前述の実施形態の変形例５と同様に、本変形例は、ＵＥがメンバーＵＥ間のＫＤＦを導出するための入力パラメータのセットに関して、同様の発見／交渉／合意手順をサポートすべきであることを提案する。

この解決方法の変形例は、実施形態１の変形例１、および変形例２で説明したように、通信中のＵＥがＫＤＦについて交渉し、合意するためのメカニズムを導入する。本変形例において、通信中のＵＥ間でＫＤＦにより使用される入力パラメータの可能な違いまたは変化の概念を導入する。この場合、本変形例では、通信中のＵＥはＫＤＦによって使用されるサポート入力パラメータを交換し、すべてのＵＥによって合意される入力パラメータのセットを交渉することができる。

一例では、ＫＤＦ関数のためのパラメータ交渉は、グループキャストまたはユニキャスト通信が確立された時点で行うことができる。

本変形例は、ＵＥによるＫＤＦ関数の異なる実装バリエーションを考慮するのに有利である。さらに、本変形例は、少数のメンバーＵＥとのユニキャスト通信またはグループキャスト通信で有用である。本変形例は、ＵＥの数が事前に知られていない可能性があるブロードキャスト通信には適していない可能性があることに留意されたい。

（実施形態２：グループキャストおよびブロードキャスト通信におけるＬ２ＩＤ更新の改善された配信）
（実施形態２、変形例１：グループキャストおよびブロードキャスト通信におけるＬ２ＩＤ更新の改善された配信）
ユニキャスト通信の場合、通信に関与するＵＥは２つだけである。この場合、双方向の要求／応答メッセージ交換を定義することによって、Ｌ２ＩＤ更新の正常な配信を保証することは、むしろ些細なことである。しかしながら、グループキャストおよびブロードキャスト通信では、複数のＵＥが通信に関与しており、すべてのＵＥが常に同じメッセージを正常に受信できるとは限らないという問題が発生する。

グループキャストおよびブロードキャストモードでは、１つまたは複数のグループメンバがＬ２ＩＤ更新メッセージを見逃す場合がある（例えば電波状態が悪いなど。）。この状態では、そのようなＵＥはグループキャストまたはブロードキャストメッセージを受信し続けることはできるが（宛先Ｌ２ＩＤがグループキャストまたはブロードキャストＬ２ＩＤであるため）、グループキャストまたはブロードキャストメッセージがどこから送信されたかを区別できなくなる。これは、特定の送信元ＵＥからのＬ２ＩＤ更新を見逃したＵＥが、その特定の送信元ＵＥからのＬ２ＩＤの連続性を追跡できなくなり、その結果として、特定の送信元Ｌ２ＩＤが誰に属するかを識別できなくなるためである。

この点において、グループキャストおよびブロードキャストモードでＬ２ＩＤ更新メッセージが正常に配信される可能性を高めることは重要である。本開示では、この目的を達成するための２つの変形例について議論する。

本変形例では、すべてのグループメンバによって受信されるＬ２ＩＤ更新の機会を最大化し、元のＬ２ＩＤ更新メッセージを見逃がした場合に受信側ＵＥを再同期するメカニズムを導入する。

一例として、１つのメンバーＵＥが送信側ＵＥからのＬ２ＩＤ更新を見逃したシナリオを考える。この場合、１つを除くすべてのピアＵＥは、元の送信時に更新されたＬ２ＩＤを正常に受信する。一定時間の経過後、送信側ＵＥはＬ２ＩＤ更新メッセージを繰り返し送信する。これにより、最初の送信で更新を見逃がしたメンバーＵＥは、同じＵＥから更新されたＬ２ＩＤを受信することができる。

Ｌ２ＩＤ更新メッセージが繰り返される期間は、ネットワークによって設定されてもよく、ＵＥ内で独自に導出されてもよい。別の例では、同じメッセージが繰り返される回数は、ネットワークによって設定されるか、またはＵＥ内で独自に導出することができる。

変形例１の副変形例は次のとおりである。
変形例１．ａ：送信側ＵＥによる繰り返し
変形例１．ｂ：受信側ＵＥによる中継
変形例１．ｃ：受信側ＵＥによるフラッディング
変形例１．ｄ：（ａ）～（ｃ）の組み合わせ
以下の図９Ａ～９Ｄは、これらの副変形例を示す。

図９Ａは、送信元ＵＥからの繰り返しメッセージを示す。この場合、ＵＥ－４はＵＥ－１が送信した最初のＬ２ＩＤ更新メッセージを見逃しているが、ＵＥ－２及びＵＥ－３は最初のＬ２ＩＤ更新メッセージの受信に成功している。しかしながら、ＵＥ－４は、繰り返しメッセージの中でＵＥ－１から同じアップデートを正常に受信する。破線は繰り返しメッセージを示す。

図９Ｂは、元のＬ２ＩＤ更新メッセージを正常に受信したＵＥからの中継メッセージを示す。この場合、ＵＥ－４はＵＥ－１が送信した最初のＬ２ＩＤ更新メッセージを見逃しているが、ＵＥ－２及びＵＥ－３は最初のＬ２ＩＤ更新メッセージの受信に成功している。しかしながら、ＵＥ－４はＵＥ－３から中継された同じアップデートを正常に受信する。破線はＵＥ－３からの中継されたメッセージを示す。

図９Ｃは、元のＬ２ＩＤ更新メッセージを正常に受信したＵＥからのフラッディングメッセージを示す。この場合、ＵＥ－４はＵＥ－１が送信した最初のＬ２ＩＤ更新メッセージを見逃しているが、ＵＥ－２及びＵＥ－３は最初のＬ２ＩＤ更新メッセージの受信に成功する。しかしながら、ＵＥ－４は、ＵＥ－２およびＵＥ－３から同じアップデートをフラッディングメッセージで正常に受信する。破線はＵＥ－２およびＵＥ－３からの中継メッセージを示す。

図９Ｄは、元のＬ２ＩＤ更新メッセージの受信に成功したＵＥから繰り返され、中継され、およびフラッディングされたメッセージの組み合わせを示す。この場合、ＵＥ－４はＵＥ－１が送信した最初のＬ２ＩＤ更新メッセージを見逃しているが、ＵＥ－２とＵＥ－３は最初のＬ２ＩＤ更新メッセージの受信に成功している。しかしながら、ＵＥ－４は、繰り返され、中継され、およびフラッディングされたメッセージの中で、ＵＥ－１、ＵＥ－２、およびＵＥ－３から同じアップデートの受信に成功する。破線は、ＵＥ－１、ＵＥ－２、およびＵＥ－３からの繰り返し／中継／フラッディングメッセージを示す。

あるいは、上述の変形例では、１つまたは複数のＵＥが、同じメッセージを２回以上受信する可能性がある（つまり、元のメッセージ及び繰り返し／中継／フラッディングされたメッセージ、または２つまたは３つの繰り返し／中継／フラッディングされたメッセージ）。一例として、ＵＥは、同じメッセージのこのような重複受信を検出し、重複するものを廃棄することができる。

別の例では、繰り返し／中継／フラッディングされたメッセージは、繰り返し／中継／フラッディングされたメッセージを配信することが特に意図されている別の宛先のＬ２ＩＤに送信されてもよい。繰り返し／中継／フラッディングされたメッセージ専用の別のＬ２ＩＤを使用することで、ＵＥでの受信動作が簡素化され、重複したメッセージを素早く検出して廃棄することができる。

（実施形態２、変形例２：グループキャストおよびリプレイ保護付きブロードキャストにおけるＬ２ＩＤ更新の配信改善）
本変形例では、実施形態２の変形例１に追加の機能を導入する。悪意のあるＵＥによる中間者攻撃などのリプレイ攻撃を回避する。

この拡張機能は、実施形態２の変形例１の全ての副変形例（すなわち、変形例１．ａ～１．ｄ）に適用することができる。この変形例における追加機能は、次のように説明できる。

（実施形態２、変形例１、副変形例１．ａ～１．ｄ）において、繰り返しメッセージを生成する際に、シーケンス番号を導入する。各メッセージには、有効なシーケンス番号（値）が付与される。したがって、メッセージが繰り返される場合、繰り返されるメッセージのシーケンス番号は元のメッセージとは異なる。このシーケンス番号は一度のみ使用され、その後にメッセージをリプレイしようとしても、受信側ＵＥによって拒否される。

なお、本変形例で用いたシーケンス番号は、実施形態１の変形例２で導入したシーケンス番号とは異なる目的で用いられることに留意されたい。

一例では、このシーケンス番号は、同一メッセージの各連続した繰り返し／リプレイ／フラッディングにおいて単に単調に増加する番号よりも複雑な方法で定義することができる。そうでなければ、攻撃者が次のシーケンス番号としてＮ＋１を想定し、リプレイ攻撃を実行することは明らかである。

別の例では、最後に使用されたシーケンス番号をＫＤＦへの入力として使用して、次のシーケンス番号を導出することができる。これを図１０に示す。

別の例では、シーケンス番号の初期値は、送信者がランダムに選択することができ、後続の繰り返しメッセージでは、単調に増加するシーケンス番号を入力として使用することができる。この場合、送信者は安全な方法（例えば、暗号化キーなどを含む既存のセキュリティコンテキストを使用して暗号化されたメッセージ）で受信者に初期値を伝達する。

これらの例では、シーケンス番号に関係のない追加のパラメータをＫＤＦへの入力として使用することができる。

図１０は、最後に使用されたシーケンス番号および追加パラメータを入力パラメータとして使用して、新しいシーケンス番号を導出するためのＫＤＦ関数の一例を示す。図１０では、タイムスタンプが追加パラメータとして使用されている。

（実施形態３：グループキャスト、ブロードキャストおよびユニキャスト通信におけるアプリケーション層メッセージの配信改善）
（実施形態３、変形例１：Ｌ２ＩＤ更新時の重複通信）
実施形態１および実施形態２で説明したＬ２ＩＤ更新手順は、Ｖ２Ｘ通信におけるユーザおよび車両のプライバシーを保護する。このメカニズムは、システムによって設定された、またはＵＥ自体で自己設定され、又は指定された間隔で定期的に発生する。

このＬ２ＩＤの更新手順は、ＵＥ間でＰＣ５インタフェースを使用するアプリケーション層の通信（交通事故を回避するための基本的な安全メッセージなど）とは別に、独立して行われることに留意されたい。これは、アプリケーション層のメッセージイベントがこのＬ２ＩＤ更新を認識していないため、アプリケーション層のメッセージのフローがトリガされ、このようなＬ２ＩＤ更新イベントとは無関係に継続することを意味する。このイベントの独立性は、一般に、通信システムに一般的に存在するレイヤコンセプトの原理に従う。Ｌ２ＩＤ更新イベントがアプリケーション層メッセージフローと同時に発生した場合、Ｌ２ＩＤ更新イベントによってＰＣ５インタフェース上の通信に関係するＵＥ間で予期しない通信中断を引き起こすべきではない。この状況は、ブロードキャスト、グループキャスト、およびユニキャストモードの通信に適用される。Ｌ２ＩＤ更新などの下位レイヤでのイベントにより、アプリケーション層での通信が中断された場合、起こり得る結果として、アプリケーション層のメッセージが失われるなどの例が考えられる。

ブロードキャスト、グループキャスト、またはユニキャスト通信の１つまたは複数のＵＥが、通信に関係するＵＥのＬ２ＩＤ更新を見逃したり、Ｌ２ＩＤ更新などのイベントによってアプリケーションメッセージが遅延または消失したりすると、結果としてアプリケーション層サービスが中断される可能性がある。典型的なＶ２Ｘアプリケーション層通信は、非常に低遅延通信を必要とする交通事故を回避するための基本的な安全メッセージを含むことに留意されたい。したがって、アプリケーション層での通信の中断を防ぐことは重要である。そのような事象が発生した場合、事故が発生するかしないかの違いが生じる可能性がある。

この状況に対処し、潜在的な影響を緩和するために、実施形態３の変形例１では、グループキャスト、ブロードキャスト、およびユニキャストモードの通信におけるアプリケーション層のメッセージの配信を改善する以下のメカニズムを提案する。

この変形例では、ブロードキャスト、グループキャスト、またはユニキャスト通信に関与するＵＥは、自身のＬ２ＩＤが定期的に変更されるイベントを識別する。このとき、ＵＥは、旧Ｌ２ＩＤ及び新Ｌ２ＩＤを送信元Ｌ２ＩＤとして、同じアプリケーション層のメッセージを複数回（例えば２回）送信する。これにより、２つの異なる送信元Ｌ２ＩＤを使用して、同じアプリケーション層メッセージが複数回（例えば２回）繰り返される。これにより、ＵＥのＬ２ＩＤが変更されても、通信中の他のＵＥがアプリケーション層メッセージを中断することなく正常に受信できる可能性を最大化する。

一例では、Ｌ２ＩＤ更新を担当するＬ２層は、Ｌ２ＩＤ変更が行われていることを上位層（アプリケーション層）に示す。その後、上位層（アプリケーション層）は、生成するメッセージごとにメッセージを複数回（例えば２回）送信する。本副変形例は、アプリケーション層がＩＰベースの通信を使用する場合により適用可能である。なお、ＩＰベースの通信では、送信元ＩＰアドレス及び送信元Ｌ２ＩＤが同時に更新される。この場合、Ｌ２ＩＤの変更に関する本変形例の説明は、ＩＰアドレスの変更にも適用される。

別の例では、Ｌ２ＩＤ更新を担当するレイヤ２は、Ｌ２ＩＤ更新が発生する期間を検出する。この間、レイヤ２は、アプリケーション層が使用している通信モード（ブロードキャスト、グループキャスト、またはユニキャスト）において、新旧両方のＬ２ＩＤを用いて上位層からアプリケーション層のメッセージを送信する。この副変形例は、アプリケーション層通信が非ＩＰベースの通信を使用する場合により適用可能である。

一例では、以下のシナリオの両方において、送信側ＵＥによって送信されたメッセージの受信に成功する。したがって、本変形例は、ブロードキャストモードやグループキャストモードなど、複数の受信側ＵＥが存在する通信モードにおいて有利である。
ａ）受信側ＵＥが送信側ＵＥのＬ２ＩＤの更新処理中であっても、この受信側ＵＥは、旧Ｌ２ＩＤを送信側ＵＥの有効なＩＤとして認識することができる。この場合、受信側ＵＥは、送信側ＵＥが送信したメッセージの送信元Ｌ２ＩＤフィールドに旧Ｌ２ＩＤを含むメッセージを認識する。
ｂ）受信側ＵＥが送信側ＵＥのＬ２ＩＤの更新を既に受け入れている場合には、新Ｌ２ＩＤを送信側ＵＥの有効なＩＤとして認識してもよい。この場合、受信側ＵＥは、送信側ＵＥが送信したメッセージの送信元Ｌ２ＩＤフィールドに新Ｌ２ＩＤを含むメッセージを認識する。

一例として、この複製送信が行われる時間枠は、「Ｌ２ＩＤ更新セーフガードタイマー」というタイマーによって定義される。一例では、このタイマーは、システムによって構成されてもよく、ＵＥ自身によって自己割り当てされてもよい。

（実施形態３、変形例２：Ｌ２ＩＤ更新時における複数のＬ２ＩＤの受け入れ）
本変形例では、受信側ＵＥは、メッセージの送信元ＩＤとして新旧いずれかのＬ２ＩＤを含む送信側ＵＥからのメッセージを受け入れる。送信側ＵＥが使用する旧Ｌ２ＩＤと新Ｌ２ＩＤは、それぞれＬ２ＩＤ変更手順の前後に使用された／されているものを指す。この解決方法の変形例は、ブロードキャスト、グループキャスト、およびユニキャスト通信に適用できる。

この解決方法の変形例は、送信側ＵＥがメッセージ内の新Ｌ２ＩＤの使用を開始する時間と、受信側ＵＥが送信側ＵＥの新Ｌ２ＩＤの認識を開始する時間との間の相対的なタイミング差に対応する。換言すれば、このメカニズムは次の競合状態に対応する。
１）１つまたは複数の受信側ＵＥが送信側ＵＥの有効な送信元Ｌ２ＩＤとして旧Ｌ２ＩＤを認識している場合でも、送信側ＵＥがメッセージ内の送信元アドレスとして新Ｌ２ＩＤの使用を開始するシナリオ。
２）受信側ＵＥが送信側ＵＥの有効な送信元Ｌ２ＩＤとして新Ｌ２ＩＤをすでに認識している一方で、送信側ＵＥからのメッセージが旧Ｌ２ＩＤを含んで受信側ＵＥに到着するシナリオ。

いずれのシナリオにおいても、本項で説明するメカニズムがない場合、受信側ＵＥは、送信側ＵＥの送信元アドレス内のＬ２ＩＤが有効でないため、受信メッセージを廃棄する。本項で説明するメカニズムにより、受信側ＵＥは、送信側ＵＥからのメッセージを破棄することなく受信することが可能となり、送信側ＵＥが新Ｌ２ＩＤを用いてメッセージを送信するように切り替えるタイミングと、受信側ＵＥが新Ｌ２ＩＤを受信するように切り替えるタイミングとの相対的なタイミングの違いにかかわらず、メッセージの損失を回避することができる。

一例では、受信側ＵＥは、送信側ＵＥから送信元ＩＤとして送信側ＵＥの新Ｌ２ＩＤを含むメッセージを受信するとすぐに、送信側ＵＥから旧Ｌ２ＩＤを受け入れることを停止する。
これは送信側ＵＥがすでに新しいＬ２ＩＤに切り替えたことを示し、したがって、受信側ＵＥは、送信側ＵＥの旧Ｌ２ＩＤを含むメッセージをもはや受信しない。

別の例では、受信側ＵＥは、送信側ＵＥから新旧両方のＬ２ＩＤからのメッセージを受け入れる時間枠を使用する。この時間枠の定義及び使用方法は、上記実施形態３の変形例１で説明した「Ｌ２ＩＤ更新セーフガードタイマー」と同様である。このタイマーが満了すると、受信側ＵＥは、送信側ＵＥの旧Ｌ２ＩＤを含むメッセージの受信を停止する。その結果、受信側ＵＥは、送信側ＵＥの新しいＬ２ＩＤのみに切り替える。

ＩＰベースの通信の場合、ＩＰアドレスとＬ２ＩＤの変更が同時に発生する。この場合、本変形例で説明されているメカニズムは、ＩＰアドレス及びＬ２ＩＤの両方に適用される。

（実施形態４：複数回の更新サイクルでＬ２ＩＤ更新を見逃したＵＥを救済するメカニズム）
（実施形態４、変形例１：明示的クエリ）
実施形態１、実施形態２、実施形態３で説明したＬ２ＩＤ更新のメカニズムは、送信元ＵＥが旧（すなわち現在の）Ｌ２ＩＤ及び新Ｌ２ＩＤを通信することによって行われる。このメカニズムは、Ｌ２ＩＤ更新を複数回見逃したＵＥを「救済」することである。この更新は、通信中の他のＵＥに対して、使用されるモード（ブロードキャスト、グループキャスト、およびユニキャスト）に応じて送信される。

このＬ２ＩＤ更新のメカニズムにより、２つのすぐに連続するＬ２ＩＤ値のみが通信されることに留意されたい。たとえば、世代「Ｎ」のＬ２ＩＤの次に「Ｎ＋１」世代のＩＤが続き、これら２つのＬ２ＩＤがＬ２ＩＤ更新メッセージで送信される。

このメッセージ方式は、受信側ＵＥが１つのＬ２ＩＤ更新サイクルを逃すと、同じＵＥからの次のＬ２更新には、前回のＬ２ＩＤ更新サイクルを逃したＵＥにとって未知である旧（すなわち現在の）Ｌ２ＩＤを含むことを意味する。この場合、ＵＥは、通信中の所定のＵＥに対するＬ２ＩＤのシーケンスを追跡できなくなる。例えば、ある更新サイクルでＵＥ－ＡのＬ２ＩＤがＩＤ値＃１からＩＤ値＃２に、次の更新サイクルでＩＤ値＃２からＩＤ値＃３に変化し、受信側ＵＥの１つが最初の更新サイクル（ＩＤ値＃１からＩＤ値＃２への更新）を逃し、次のＬ２ＩＤ更新サイクル（ＩＤ値＃２からＩＤ値＃３への更新）を正常に受信した場合、このＵＥはＩＤ値がＩＤ値＃１からＩＤ値＃３に変化した順序を追跡できない。そのため、ＩＤ値＃１とＩＤ値＃３が同じＵＥであることを識別できない。

一般に、受信側ＵＥは、１回以上の更新サイクルでＬ２ＩＤ更新を受信できなかった場合、通信中の所定のＵＥに対して、その後のＬ２ＩＤ更新におけるＬ２ＩＤ変更の連続性を確立することができない。

上記のセクションで説明した状態を緩和するために、本変形例では、複数回の更新サイクルにまたがる時間にわたってＬ２ＩＤ変更の連続性を復元するメカニズムを導入する。

ＰＣ５インタフェースを用いた通信における各ＵＥは、「デフォルト」Ｌ２ＩＤを定義する。この「デフォルトＩＤ」は、フォールバックＬ２ＩＤとして使用され、受信側ＵＥが、送信元ＵＥと現在使用されている（すなわち最新の）Ｌ２ＩＤとの関連性を再確立する手段として使用される。このメカニズムは、通信に関与するすべてのＵＥが何らかの方法でこの「デフォルトＩＤ」を「知っている」ことを意味する。

別の例では、この「デフォルト」Ｌ２ＩＤはより永続的な性質を有する。この場合、システム設定又は各ＵＥに静的に割り当てられたＬ２ＩＤ値など、通信中のすべてのＵＥによって非明示的に知られている。

別の例では、この「デフォルト」Ｌ２ＩＤは、受信側ＵＥによる最後の既知のＬ２ＩＤに基づく明確な式によって作成することができる。例えば、Ｌ２ＩＤの最後の数ビットは、所定の送信元ＵＥの「デフォルト」Ｌ２ＩＤであることを指定するために、予め決められた周知の形式（例えば、すべて「１」）として設定することができる。

本変形例では、既に確立された通信における任意の正当なＵＥが、送信元ＵＥに明示的な要求メッセージを送信することができる。この要求は、ＵＥがＰＣ５インタフェースを介して問題のＵＥに明示的なメッセージを送信し、ＵＥが最新のＬ２ＩＤを送信するように要求することによって行うことができる。言い換えると、本変形例は、受信側ＵＥが送信側ＵＥのＬ２ＩＤを追跡できなくなったときのリカバリー方法としてまとめられる。これを図１１に示す。

図１１は、ＵＥがＰＣ５通信上のＬ２ＩＤ更新を複数回逃した場合に、Ｌ２ＩＤを再確立するメカニズムを示す。
図１１のＳ１は、ＵＥ－２が、例えば、ＵＥ－１からのＬ２ＩＤ更新を複数回逃すなどして、ＵＥ－１のＬ２ＩＤを見失った場合を示す。
図１１のＳ２は、ＵＥ－２が、例えば、ＵＥ－１にＵＥ－２が認識しているＵＥ－１のＬ２ＩＤの中で最新のものに基づいて、ＵＥ－１に最新のＬ２ＩＤの提供を要求するために、Ｌ２ＩＤ問合せメッセージを送信することを示す。このメッセージには、要求側エンティティ（ＵＥ－２）が通信中の有効かつ正当なＵＥであることを識別するその他の情報も含まれる。
図１１のＳ３では、ＵＥ－１がＳ２で受信した要求の有効性を検証する。
図１１のＳ４では、Ｓ３の有効性チェックが成功すると、ＵＥ－１は最新の（現在の）Ｌ２ＩＤをＵＥ－２に送信する。
図１１のＳ５は、ＵＥ－２がＳ４のメッセージを受信し、ＵＥ－１のＬ２ＩＤを復元する様子を示す。
図１１のＳ６は、ＵＥ－２がＵＥ－１から送信されたメッセージを送信元として識別できることを示す。

（実施形態４、変形例２：定期更新）
別の例では、問題のＵＥは、すべての受信側ＵＥへのＬ２ＩＤ更新メッセージに「デフォルト」Ｌ２ＩＤを自発的かつ定期的に含めることができる。このメカニズムは、Ｌ２ＩＤ更新を複数回見逃したＵＥを「救済」するためのものである。送信元ＵＥの最新のＬ２ＩＤに再同期する目的のために、この「デフォルト」Ｌ２ＩＤは、定期的に変更される通常のＬ２ＩＤと比較して、時間的に比較的持続する。換言すれば、本変形例は、受信側ＵＥが送信側ＵＥのＬ２ＩＤを見失うことを回避するための防止方法としてまとめられる。これを図１２に示す。

図１２は、ＰＣ５通信を介してピアＵＥに「デフォルト」Ｌ２ＩＤを提供するメカニズムを示す。

図１２のＳ１は、通信中のピアＵＥに対して、ＵＥ－１がＬ２ＩＤ更新要求メッセージを送信することを示す。このメッセージには、ＵＥ－１の「デフォルト」Ｌ２ＩＤが含まれる。なお、この「デフォルト」Ｌ２ＩＤ情報は、定期的に更新される通常の「Ｌ２ＩＤ」よりも含まれる頻度が低いことに留意されたい。図１２のＳ２は、ＵＥ－２がＵＥ－１の「デフォルト」Ｌ２ＩＤを保持していることを示す。

（他の実施形態）
（システムの概要）
図１３は、上記実施形態が適用可能な移動（セルラーまたは無線）通信システム１を概略的に示す図である。

このネットワークでは、モバイル機器３（ＵＥ）のユーザは、適切な３ＧＰＰ無線アクセス技術（ＲＡＴ）、例えばＥ－ＵＴＲＡおよび／または５Ｇ ＲＡＴを使用して、それぞれの基地局５およびコアネットワーク７を介して、互いに他のユーザと通信することができる。多くの基地局５が（無線）アクセスネットワークまたは（Ｒ）ＡＮを形成することが理解されよう。当業者には理解されるように、図１３には、例示の目的で１つのモバイル機器３および１つの基地局５が示されているが、システムが実装される場合、通常は、他の基地局およびモバイル機器（ＵＥ）を含む。

各基地局５は、１つまたは複数の関連セルを（直接またはホーム基地局、リレー、遠隔無線ヘッド、分散ユニットなどの他のノードを介して）制御する。Ｅ－ＵＴＲＡ／４Ｇプロトコルをサポートする基地局５は「ｅＮＢ」と呼ばれ、次世代／５Ｇプロトコルをサポートする基地局５は「ｇＮＢ」と呼ばれる。一部の基地局５は、４Ｇおよび５Ｇの両方、および／または任意の他の３ＧＰＰまたは非３ＧＰＰ通信プロトコルをサポートするように構成されてもよいことが理解されよう。

モバイル機器３とそのサービング基地局５とは、適切なエアインタフェース（例えば、いわゆる「Ｕｕ」インタフェースおよび／または同様のもの）を介して接続されている。隣接する基地局５は、適切な基地局間インタフェース（いわゆる「Ｘ２」インタフェース、「Ｘｎ」インタフェースおよび／または同様のもの）を介して互いに接続される。また、基地局５は、適切なインタフェース（例えば、いわゆる「Ｓ１」、「Ｎ１」、「Ｎ２」、「Ｎ３」インタフェースおよび／または同様のもの）を介してコアネットワークノードに接続されている。

コアネットワーク７は、典型的には、通信システム１における通信をサポートするための論理ノード（または「機能」）を含む。典型的には、例えば、「次世代」／５Ｇシステムのコアネットワーク７は、他の機能の中でも、制御プレーン機能（ＣＰＦ）及びユーザプレーン機能（ＵＰＦ）を含む。コアネットワーク７は、中でも、アクセスおよびモビリティ管理機能（ＡＭＦ）１０、セッション管理機能（ＳＭＦ）１１、セキュリティアンカー機能（ＳＥＡＦ）１２、認証サーバ機能（ＡＵＳＦ）１３、統合データ管理（ＵＤＭ）機能１５、認証クリデンシャルリポジトリおよび処理機能（ＡＲＰＦ）１６、加入識別子非隠蔽機能（ＳＩＤＦ）１７、ポリシー制御機能（ＰＣＦ）１８、およびアプリケーション機能（ＡＦ）１９を含むことができることが理解されよう。

コアネットワーク７からは、外部ＩＰネットワーク２０（インターネット等）への接続も提供される。このシステム１の構成要素は、上述の例示的な実施形態の１つ以上を実行するように構成される。

（ユーザ機器（ＵＥ））
図１４は、図１３に示すＵＥ３の主要な構成要素を示すブロック図である。図１４に示されるように、ＵＥ３は、１つまたは複数のアンテナ３３を介して、接続されたノードと信号を送受信するように動作可能なトランシーバ回路３１を含む。図１４には示されていないが、ＵＥ３は、当然、従来のモバイル機器における通常のすべての機能（ユーザインタフェース３５など）を有し、これは適宜、ハードウェア、ソフトウェアおよびファームウェアのいずれかまたは任意の組み合わせによって提供されてもよい。ソフトウェアは、メモリにプリインストールされていてもよく、および／または例えば、電気通信ネットワークを介して、またはリムーバブルデータ記憶装置（ＲＭＤ）からダウンロードされてもよい。

コントローラ３７は、メモリ３９に記憶されたソフトウェアに従ってＵＥ３の動作を制御する。コントローラ３７は、例えば、一つ以上のＣＰＵ（Central Processing Unit）によって実現することができる。また、コントローラ３７は、メモリ３９からソフトウェア（コンピュータプログラム）をロードし、ロードしたソフトウェアを実行することにより、上述した実施形態のシーケンス図及びフローチャートを参照して説明したＵＥ３の処理を行うことができる。

メモリ３９は、揮発性メモリと不揮発性メモリとを組み合わせて構成されている。メモリ３９は、コントローラ３７とは別に配置された記憶装置を含んでいてもよい。この場合、コントローラ３７は、Ｉ／Ｏインタフェース（図示せず）を介してメモリ３９にアクセスすることができる。メモリ３９に記憶されたソフトウェアは、図面を参照して上述したアルゴリズムをコンピュータに実行させるための命令群を含む。

ソフトウェアは、特に、オペレーティングシステム４１と、少なくともトランシーバ制御モジュールを有する通信制御モジュール４３とを含む。（トランシーバ制御サブモジュールを使用する）通信制御モジュール４３は、ＵＥ３と、基地局／（Ｒ）ＡＮノード５、ＭＭＥ、ＡＭＦ１０（および他のコアネットワークノード）などの他のノードとの間のシグナリングおよびアップリンク／ダウンリンクデータパケットの処理（生成／送信／受信）を担当する。このようなシグナリングは、例えば、接続確立および維持に関連する適切にフォーマットされたシグナリングメッセージ（例：ＲＲＣメッセージ）、定期的な位置更新関連メッセージ（例えばトラッキングエリアの更新、ページングエリアの更新、ロケーションエリアの更新）などのＮＡＳメッセージを含むことができる。

（（Ｒ）ＡＮノード）
図１５は、図１３に示される例示的な（Ｒ）ＡＮノード５、例えば基地局（ＬＴＥでは「ｅＮＢ」、５Ｇでは「ｇＮＢ」または「ｎｇＮＢ」）の主要構成要素を示すブロック図である。図に示されているように、（Ｒ）ＡＮノード５は、１つまたは複数のアンテナ５３を介して、接続されたＵＥ３と信号を送受信し、ネットワークインタフェース５５を介して（直接的または間接的に）他のネットワークノードと信号を送受信するように動作可能なトランシーバ回路５１を含む。コントローラ５７は、メモリ５９に記憶されたソフトウェアに従って、（Ｒ）ＡＮノード５の動作を制御する。コントローラ５７は、例えば、１つ以上のＣＰＵによって実現することができる。さらに、コントローラ５７は、メモリ５９からソフトウェア（コンピュータプログラム）をロードし、ロードされたソフトウェアを実行することにより、コアネットワークノードが実行する処理を実行することができる。ソフトウェアは、例えば、メモリ５９にプリインストールされていてもよく、および／または通信ネットワークを介して、またはリムーバブルデータ記憶装置（ＲＭＤ）からダウンロードされてもよい。

メモリ５９は、揮発性メモリと不揮発性メモリとを組み合わせて構成されている。メモリ５９は、コントローラ５７とは別に配置された記憶装置を含んでいてもよい。この場合、コントローラ５７は、Ｉ／Ｏインタフェース（図示せず）を介してメモリ５９にアクセスすることができる。メモリ５９に記憶されたソフトウェアは、コンピュータにアルゴリズムを実行させるための命令群を含む。

ソフトウェアは、特に、オペレーティングシステム６１と、少なくともトランシーバ制御モジュールを有する通信制御モジュール６３とを含む。（トランシーバ制御サブモジュールを使用する）通信制御モジュール６３は、（Ｒ）ＡＮノード５と、ＵＥ３、ＭＭＥ、ＡＭＦ１０などの他のノードとの間のシグナリングを（例えば直接的または間接的に）処理する（生成／送信／受信する）役割を果たす。シグナリングは、例えば、（特定のＵＥのための）無線接続および位置手順に関する、特に、接続確立および維持（例えば、ＲＲＣコネクション確立と他のＲＲＣメッセージ）、周期的位置更新関連メッセージ（トラッキングエリアの更新、ページングエリアの更新、ロケーションエリアの更新など）、Ｓ１ＡＰメッセージおよびＮＧＡＰメッセージ（すなわち、Ｎ２基準点によるメッセージ）などに関する、適切にフォーマットされたシグナリングメッセージを含むことができる。このようなシグナリングは、例えば、送信の場合には、ブロードキャスト情報（例：マスター情報とシステム情報）も含むことができる。

また、コントローラが実装されている場合、ＵＥ移動度推定および／または移動軌跡推定などの関連タスクを処理するように（ソフトウェアまたはハードウェアによって）構成される。

（コアネットワークノード）
図１６は、図１３に示される例示的なコアネットワークノード、例えば、ＡＭＦ１０、ＳＭＦ１１、ＳＥＡＦ１２、ＡＵＳＦ１３、ＵＰＦ１４、ＵＤＭ１５、ＡＲＰＦ１６、ＳＩＤＦ１７、ＰＣＦ１８、ＡＦ１９等の主要な構成要素を示すブロック図である。コアネットワークノードは５ＧＣに含まれる。図に示されているように、コアネットワークノードは、ネットワークインタフェース７５を介して他のノード（ＵＥ３を含む）と信号を送受信するように動作可能なトランシーバ回路７１を含む。コントローラ７７は、メモリ７９に記憶されたソフトウェアに従って、コアネットワークノードの動作を制御する。コントローラ７７は、例えば、１つ以上のＣＰＵによって実現することができる。さらに、コントローラ７７は、メモリ７９からソフトウェア（コンピュータプログラム）をロードし、ロードされたソフトウェアを実行することにより、コアネットワークノードが実行する処理を実行することができる。ソフトウェアは、例えば、メモリ７９にプリインストールされていてもよく、および／または通信ネットワークを介して、またはリムーバブルデータ記憶装置（ＲＭＤ）からダウンロードされてもよい。ソフトウェアは、特に、オペレーティングシステム８１と、少なくともトランシーバ制御モジュールを有する通信制御モジュール８３とを含む。

メモリ７９は、揮発性メモリと不揮発性メモリとを組み合わせて構成されている。メモリ７９は、コントローラ７７とは別に配置された記憶装置を含んでいてもよい。この場合、コントローラ７７は、Ｉ／Ｏインタフェース（図示せず）を介してメモリ７９にアクセスすることができる。メモリ７９に記憶されたソフトウェアは、コンピュータにアルゴリズムを実行させる命令群を含む。

（トランシーバ制御サブモジュールを使用する）通信制御モジュール８３は、コアネットワークノードと、ＵＥ３、基地局／（Ｒ）ＡＮノード５（例：「ｇＮＢ」または「ｅＮＢ」）などの他のノードとの間のシグナリングを（直接的または間接的に）処理する（生成／送信／受信する）役割を果たす。このようなシグナリングは、例えば、本明細書に記載する手順に関連する適切にフォーマットされたシグナリングメッセージ、例えば、ＵＥ等との間でＮＡＳメッセージを伝達するためのＮＧＡＰメッセージ（すなわち、Ｎ２基準点によるメッセージ）を含んでいてもよい。

ＡＭＦ１０は、ＵＥベースの認証、認可、およびモビリティ管理サービスを提供する。セッション管理機能にサービスを提供する。また、他のＡＭＦ、ポリシー制御機能１８、ショートメッセージサービス機能、ロケーション管理機能、ゲートウェイモバイルロケーションセンター、およびＮＥＦに、ネイムオブサービスベースのインタフェースを介してサービスを提供する。主要なＡＭＦサービスは、登録、接続、到達性、モビリティ管理などを含む。また、ＲＡＮコントロールプレーンインタフェース（Ｎ２）のターミネーションポイントとしても機能する。

ＳＭＦ１１は、ＵＥセッションの管理を行うとともに、ＵＥ３にＩＰアドレスを割り当てる。また、データ転送用のＵＰＦ１４を選択して制御する。複数のセッションを持つＵＥには、セッションごとのＳＭＦを割り当ててもよい。また、ユーザのパケットの効率的なルーティングのために、ユーザプレーン機能１４と相互に作用する。

ＳＥＡＦ１２は、一次認証のための後続の通信を保護するために、ＵＥ３およびサービングネットワークが使用できる統一されたアンカーキーＫＳＥＡＦ（全アクセス共通）を生成する。ＵＥ３が３ＧＰＰアクセス（訪問ネットワーク）及び非３ＧＰＰアクセス（ホームネットワーク）に接続されている場合のシナリオでは、２つのアンカーキーが存在する可能性がある。

ＡＵＳＦ１３コンポーネントは、３ＧＰＰアクセスおよび非３ＧＰＰアクセスネットワークの認証要求を処理する。ＡＵＳＦ１３コンポーネントは、ユーザ機器３を認証するためにセキュリティアンカー機能１２と相互に作用する。Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｍｏｄｕｌｅの値のセットは、認証クリデンシャルリポジトリおよび処理機能によって使用される。加入識別子は、加入を一意に識別し、ＵＥ３と５Ｇコアネットワーク７とを相互に認証するために用いられる。ＡＵＳＦ１３は、必要な認証および認可プロセスを提供するとともに、ユーザプレーンセキュリティのターミナルポイントとして機能する。また、ネットワークスライスセキュリティとＥｎｈａｎｃｅｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｐｒｉｖａｃｙも処理する。

ＵＰＦ１４は、パケットルーティングおよび転送、パケット検査、およびＱｏＳ処理をサポートする。また、データネットワークへの相互接続の外部ＰＤＵセッションポイントとしても機能し、ＲＡＴ内およびＲＡＴ間の移動のアンカーポイントでもある。これは重要な機能の一つであり、サブミリ秒以内にパケットを効率的に処理しなければならない。この機能の速度が低下すると、パケット遅延が大幅に増加し、ユーザの体感品質が低下する。ＵＰＦ１４は、セッション管理機能１１のサービスを利用する。

ＵＤＭ１５は、ＡＭＦ１０、ＳＭＦ１１、ＳＭＳＦ、ＮＥＦ、およびＡＵＳＦ１３にサービスを提供する。サービスには、ＡＵＳＦ１３と連携した、サブスクリプションデータストレージ、コンテキストデータ管理サービス、認証サービスが含まれる。サブスクリプションデータ管理は、ＮＦ（ＡＭＦ１０およびＳＭＦ１１）が、ＵＤＭ１５からコンシューマＮＦに関連するＵＥの加入データを取得するために使用される。また、コンシューマＮＦがデータ変更通知をサブスクライブまたはサブスクライブを解除するためにも使用される。ＵＤＭ１５は、以前に加入したことのあるコンシューマＮＦ（ＡＭＦ１０、ＳＭＦ１１、ＳＭＳＦ）、ＵＤＭ１５が加入データを変更することを判定したときに通知サービス動作によって通知を受けることができるようにする。

ＡＲＰＦ１６（通常はＵＤＭ１５と併設される）は、認証用にＥＰＳ ＡＫＡまたはＥＡＰ－ＡＫＡのキーＫなどの長期的なセキュリティクレデンシャルを記憶する。ＡＲＰＦ１６は、長期のセキュリティ認証情報を入力として使用して暗号化アルゴリズムを実行し、認証ベクトルを作成することができる。

ＰＣＦ１８は、統一されたポリシーフレームワークをサポートすることによって、ネットワークの動作を制御する。また、コントロールプレーン機能にポリシー規則を提供する。たとえば、ＡＭＦ１０には、アクセスおよびモビリティ管理関連ポリシー、アクセスネットワークの検出と選択のポリシー用のＵＥポリシーおよびＵＥルート選択のポリシーを提供する。

ＡＦ１９は、トラフィックルーティング、ＮＥＦへのアクセス、ポリシー制御のためのポリシーフレームワークとの相互作用に対するアプリケーションの影響を可能する。この機能は、コア機能がアプリケーションレベルに公開されるため、信頼性とセキュリティに大きく影響する。

ＮＥＦは、モニタリング、プロビジョニング、およびポリシー／課金をサポートするネットワーク機能の外部に公開することができる。ネットワーク機能の公開は、次のように構成される。（ｉ）ネットワークイベントを外部および内部のコアネットワークＮＦに公開すること、（ｉｉ)プロビジョニング機能を外部の機能に公開すること、(ｉｉｉ)ポリシーおよび課金機能を外部の機能に公開すること、(ｉｖ)分析のためにコアネットワーク内部の機能を公開すること。

上述した実施例において、プログラムは、任意の種類の非一時的なコンピュータ可読媒体を用いて格納され、コンピュータに提供され得る。非一時的なコンピュータ可読媒体は、任意の種類の有形記憶媒体を含む。非一時的なコンピュータ可読媒体の例としては、磁気記憶媒体（フロッピーディスク、磁気テープ、ハードディスクドライブなど）、光磁気記憶媒体（例えば光磁気ディスク）、ＣＤ－ＲＯＭ（compact disc read only memory）、ＣＤ－Ｒ（compact disc recordable）、ＣＤ－Ｒ／Ｗ（compact disc rewritable)、および半導体メモリ（ｍａｓｋＲＯＭ、ＰＲＯＭ（programmable ROM）、ＥＰＲＯＭ（erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory）など）を含む。プログラムは、任意の種類の一時的なコンピュータ可読媒体を使用してコンピュータに提供することができる。一時的なコンピュータ可読媒体の例は、電気信号、光信号、および電磁波を含む。一時的なコンピュータ可読媒体は、有線通信回線（例えば電線や光ファイバー）または無線通信回線を介してプログラムをコンピュータに提供することができる。

（変更及び代替）
以上、詳細な実施形態について説明した。当業者には理解されるように、実施形態に具現化された開示から恩恵を受けつつ、上述の実施形態においては多くの変更および代替を行うことができる。例示として、ここでは、これらの代替および修正のうちのいくつかのみを説明する。

本開示の実施形態は、レイヤ２アイデンティティ（Ｌ２ＩＤ）更新手順を説明する。アイデンティティ更新の一般的な概念は、別の通信レイヤにおける同等の機能、例えば、ＩＰレイヤにおけるＩＰアドレス更新機能にも適用可能である。Ｌ２ＩＤ更新およびＩＰアドレス更新が２つの異なる層で同時に起こるようにＵＥ内で同期されている場合、本開示に記載された手順を異なる層で適用しても同様の結果を達成することができる。

上述の実施形態で使用されるメッセージ名およびパラメータ名は、意図された機能および情報要素を表す。これらのメッセージ名およびパラメータ名は、特定の例示的な実施形態を説明するための例としてのみ使用される。しかしながら、異なる実装で異なるメッセージ名およびパラメータ名が使用されてもよいことが理解されよう。また、３ＧＰＰ ＴＳまたはＴＲ文書のような関連する標準仕様では、上記のメッセージおよびパラメータと同じ機能または情報を表すために、同様のまたは異なる名称を使用してもよいことが理解されるであろう。

本開示におけるユーザ機器（または「ＵＥ」、「移動局」、「モバイル機器」または「無線機器」）は、無線インタフェースを介してネットワークに接続されたものである。本明細書におけるＵＥは、専用の通信装置に限定されるものではなく、後述するように、本明細書に記載されたＵＥとして通信機能を有する任意の装置に適用できることに留意されたい。

「ユーザ機器」または「ＵＥ」（用語は３ＧＰＰによって使用される）、「移動局」、「モバイル機器」、および「ワイヤレス機器デバイス」という用語は、一般に、互いに同義であることが意図されており、端末、携帯電話、スマートフォン、タブレット、セルラーＩｏＴデバイス、ＩｏＴデバイス、および機械などのスタンドアロンの移動局を含む。「ＵＥ」および「無線機器」という用語は、長期間静止したままの据え置き型のデバイスも含むことが理解されよう。

ＵＥは、例えば、生産・製造用の機器および／またはエネルギー関連機器（例えば、ボイラー、エンジン、タービン、ソーラーパネル、風力発電機、水力発電機、火力発電機、原子力発電機、バッテリー、原子力システムおよび／または関連機器、重電、真空ポンプを含むポンプ、コンプレッサ、ファン、ブロワー、送風機、油圧機器、空圧機器、金属加工機械、マニピュレータ、ロボットおよび／またはその応用システム、工具または金型、ロール、搬送装置、昇降装置、マテリアルハンドリング装置、繊維機械、ミシン、印刷および／または関連機器、紙工機械、化学機械、鉱山機械および／または建設機械および／または関連機器、農林水産業用機械・器具、安全環境保全機器、トラクター、精密ベアリング、チェーン、ギア、動力伝達装置、潤滑装置、バルブ、管継手、および／または前述の任意の機器または機械の応用システムなど）である。

ＵＥは、例えば、輸送機器のアイテム（たとえば、鉄道車両、自動車、モーターサイクル、自転車、列車、バス、カート、人力車、船舶等の水用車両、航空機、ロケット、衛星、ドローン、気球などの輸送機器）であってもよい。

ＵＥは、例えば、情報通信機器のアイテム（例えば、電子計算機及び関連機器、通信関連機器、電子部品等の情報通信機器）であってもよい。

ＵＥは、例えば、冷凍機、冷凍機応用製品、貿易および／またはサービス産業機器、自動販売機、自動サービス機、事務用機械または機器、家電および電子機器（例えば、オーディオ機器、映像機器、拡声器、ラジオ、テレビ、電子レンジ、炊飯器、コーヒーメーカー、食器洗い機、洗濯機、乾燥機、扇風機または関連機器、クリーナーなど）であってもよい。

ＵＥは、例えば、電気応用システムまたは装置（例えば、以下のような電気的応用システムまたは装置：Ｘ線システム；粒子加速器；ラジオアイソトープ装置；音響機器；電磁応用装置；電子動力応用装置など）であってもよい。ＵＥは、例えば、電子ランプ、照明器具、測定器、分析器、テスター、または測量または感知器（例えば煙警報器、人感警報センサ、モーションセンサ、無線タグなど）、腕時計または時計、実験器具、光学装置、医療機器および／またはシステム、武器、カトラリーのアイテム、手工具などであってもよい。

ＵＥは、例えば、無線機能を備えたパーソナルデジタルアシスタント又は関連機器（例えば、他の電子装置（例えばパソコンや電気測定器）に取り付けたり、挿入したりするように設計されたワイヤレスカードやモジュール）であってもよい。

ＵＥは、様々な有線および／または無線通信技術を用いて、「モノのインターネット（ＩｏＴ）」に関して以下に説明するアプリケーション、サービス、およびソリューションを提供するデバイスまたはシステムの一部であってもよい。

モノのインターネット装置（または「モノ」）は、適切な電子機器、ソフトウェア、センサ、ネットワーク接続性、および／または同様のものを備えていてもよく、これらの装置は、相互に、および他の通信装置とデータを収集および交換することができる。ＩｏＴデバイスは、内部メモリに格納されたソフトウェア命令に従う自動化された機器を含んでいてもよい。ＩｏＴデバイスは、人間による監視ややり取りを必要とせずに動作してもよい。ＩｏＴデバイスは、長期間にわたって停止、及び／または非アクティブになるものであってもよい。ＩｏＴデバイスは、（一般に）据え置き型の機器の一部として実装されてもよい。ＩｏＴデバイスは、非静止装置（例：車両）に組み込まれていてもよく、又は監視／追跡対象の動物若しくは人に取り付けられていてもよい。

ＩｏＴ技術は、データを送受信するために通信ネットワークに接続することができる任意の通信デバイス上に実装することができ、そのような通信デバイスが、人間の入力によって制御されるか、またはメモリに記憶されたソフトウェア命令によって制御されるかに関わらないことが理解されよう。

なお、ＩｏＴデバイスは、マシンタイプ通信（ＭＴＣ）デバイス、Machine-to-Machine（Ｍ２Ｍ）通信デバイス、ナローバンドＩｏＴ ＵＥ（ＮＢ－ＩｏＴ ＵＥ）と呼ばれることもある。ＵＥは、１つ以上のＩｏＴまたはＭＴＣアプリケーションをサポートすることができることが理解されよう。ＭＴＣアプリケーションの例を次の表に示す（出典：３ＧＰＰ ＴＳ ２２．３６８ Ｖ１３．１．０、附則Ｂ、その内容は参照により本明細書に組み込まれる。）。このリストは、完全なものではなく、マシンタイプの通信アプリケーションのいくつかの例を示すことを意図している。

表２：マシンタイプの通信アプリケーションの例

アプリケーション、サービス、ソリューションとしては、ＭＶＮＯ（Mobile Virtual Network Operator）サービス、緊急無線通信システム、ＰＢＸ（Private Branch Exchange）システム、ＰＨＳ／デジタルコードレス通信システム、ＰＯＳ（Point of Sale）システム、広告呼出システム、ＭＢＭＳ（Multimedia Broadcast and Multicast Service）、Ｖ２Ｘ（Vehicle to Everything）システム、列車無線システム、位置関連サービス、災害／緊急無線通信サービス、コミュニティサービス、ビデオストリーミングサービス、フェムトセルアプリケーションサービス、ＶｏＬＴＥ（Voice over LTE）サービス、課金サービス、ラジオオンデマンドサービス、ローミングサービス、活動監視サービス、通信事業者／通信ＮＷ選択サービス、機能制限サービス、ＰｏＣ（Proof of Concept）サービス、個人情報管理サービス、アドホックネットワーク／ＤＴＮ（Delay Tolerant Networking）サービスなどが挙げられる。

また、上述したＵＥカテゴリは、本文書に記載されている技術的思想および例示的実施形態の適用例にすぎない。言うまでもなく、これらの技術的思想及び実施形態は、上述したＵＥに限定されるものではなく、種々の変形が可能である。

上述の説明では、ＵＥ、（Ｒ）ＡＮノード、コアネットワークノードは、理解を簡単にするために、複数の個別モジュール（通信制御モジュールなど）を有するものとして説明されている。これらのモジュールは、特定の用途、例えば本開示を実施するために既存のシステムが修正される場合には、このようにして提供することができるが、他の用途、例えば最初から本発明の特徴を考慮して設計されたシステムにおいて、これらのモジュールは、全体的なオペレーティングシステムまたはコードに組み込まれてもよく、したがって、これらのモジュールは、別個の実体として識別できない場合がある。これらのモジュールは、ソフトウェア、ハードウェア、ファームウェア、またはこれらの組み合わせで実装されてもよい。

各コントローラは、例えば、１つまたは複数のハードウェア実装されたコンピュータプロセッサ、マイクロプロセッサ、中央処理装置（ＣＰＵ）、マイクロ処理装置（ＭＰＵ）、算術論理ユニット（ＡＬＵ）、入出力（ＩＯ）回路、内部メモリ／キャッシュ（プログラムおよび／またはデータ）、処理レジスタ、通信バス（制御バス、データバス、アドレスバスなど）、ダイレクトメモリアクセス（ＤＭＡ）機能、ハードウェアまたはソフトウェアで実装されたカウンタ、ポインタ、および／またはタイマーおよび／または同様のものを含み（ただし、これらに限定されない）、任意の適切な形態の処理回路で構成される。

上記実施形態では、多数のソフトウェアモジュールについて説明した。当業者であれば理解できるように、ソフトウェアモジュールは、コンパイルされた形式またはコンパイルされていない形式で提供されてもよく、コンピュータネットワーク上の信号を介して、または記録媒体上でＵＥ、（Ｒ）ＡＮノード、およびコアネットワークノードに供給されてもよい。さらに、このソフトウェアの一部または全部によって実行される機能は、１つまたは複数の専用ハードウェア回路を使用して実行されてもよい。しかしながら、ＵＥ、（Ｒ）ＡＮノード、およびコアネットワークノードの機能を更新するための更新作業を容易にすることから、ソフトウェアモジュールの使用が好ましい。

本開示において提示されるメカニズムは、特定の情報要素を有するＵＥ間のメッセージ交換を含む。場合によっては、ＵＥはＤ２Ｄ通信またはダイレクト通信を行うことができる。したがって、ＵＥの通信を監視することで侵害を検出することができる。

上記の実施形態は、「非－モバイル」または一般的に据え置き型のユーザ機器にも適用可能である。

（方法の概要）
上記の態様は、例示的な方法を説明するものであり、以下のステップを含む。
（実施形態１、変形例１）
１）送信側ＵＥは、新Ｌ２ＩＤ及び検証情報を受信側ＵＥに送信する。
２）受信側ＵＥは、検証情報を用いて送信側ＵＥの有効性および真正性を検証し、新Ｌ２ＩＤを受け入れるか否かを判定する。
（実施形態１、変形例２）
１）送信側ＵＥは、入力パラメータのセットをＫＤＦに入力し、新Ｌ２ＩＤ及びＭＡＣ（ハッシュ値）を求める。
２）受信側ＵＥは、ＫＤＦに同じ入力パラメータのセットを入力してＭＡＣ（ハッシュ値）を導出し、送信側ＵＥから受信したＭＡＣと比較する。
（実施形態１、変形例３）
１）送信側ＵＥは、入力パラメータのセットに加えてシーケンス番号をＫＤＦに入力し、新Ｌ２ＩＤとＭＡＣ（ハッシュ値）を導出する。
２）受信側ＵＥは、入力パラメータの同一セットに加えてシーケンス番号をＫＤＦに入力し、ＭＡＣ（ハッシュ値）を求め、送信側ＵＥから受信したＭＡＣと比較する。
（実施形態１、変形例４）
１）送信側ＵＥは、新Ｌ２ＩＤ及び検証情報を受信側ＵＥに送信し、すべての受信側ＵＥが新Ｌ２ＩＤを受信し、検証に成功したと仮定して、新Ｌ２ＩＤの通信を開始する。
（実施形態１、変形例５）
１）送信側ＵＥは、新Ｌ２ＩＤ及び検証情報を受信側ＵＥに送信する。
２）受信側ＵＥは、検証情報を用いて送信側ＵＥの有効性および真正性を検証し、新Ｌ２ＩＤを受け入れるか否かを判定する。
３）受信側ＵＥは、検証の成功または失敗を示すＬ２ＩＤ更新応答メッセージを送信側ＵＥに返す。
（実施形態１、変形例６）
１）通信中のＵＥは、サポートされているＫＤＦ関数を交換し、通信確立時に新Ｌ２ＩＤとＭＡＣ（ハッシュ値）を導出する。
２）通信中のＵＥは、使用するＫＤＦ関数に同意する。
（実施形態１、変形例７）
１）通信中のＵＥは、サポートされているパラメータをＫＤＦ関数に交換し、通信確立時に新Ｌ２ＩＤとＭＡＣ（ハッシュ値）を導出する。
２）通信中のＵＥは、使用するＫＤＦ関数に対するパラメータに同意する。
（実施形態２、変形例１）
１）（副変形例１）Ｌ２ＩＤ更新メッセージを送信すると、送信側ＵＥは同じメッセージを複数回繰り返す。
２）（副変形例２）１つ以上の受信側ＵＥが送信側ＵＥからＬ２ＩＤ更新メッセージを受信すると、この受信側ＵＥは同じメッセージを中継する。
３）（副変形例３）１つ以上の受信側ＵＥが送信側ＵＥからＬ２ＩＤ更新メッセージを受信すると、この受信側ＵＥは同じメッセージをフラッディングする。
４）（副変形例４）Ｌ２ＩＤ更新メッセージを送信すると、送信側ＵＥは同じメッセージを複数回繰り返すか、および／または１つまたは複数の受信側ＵＥが同じメッセージを中継またはフラッディングする。
（実施形態２、変形例２）
１）Ｌ２ＩＤ更新メッセージを送信すると、送信側ＵＥは一意の１回限りの値（例えばシーケンス番号）をメッセージに挿入する。
２）受信側ＵＥは、受信した一意の１回限りの値（例えばシーケンス番号）を使用して、受信したメッセージがオリジナルのメッセージかリプレイされたメッセージかを判定する。
（実施形態３、変形例１）
１）送信側ＵＥがＬ２ＩＤを更新すると、送信側ＵＥは旧Ｌ２ＩＤと新Ｌ２ＩＤの両方を使用して、アプリケーション層メッセージを複数回繰り返す。
２）受信側ＵＥは、旧Ｌ２ＩＤまたは新Ｌ２ＩＤのいずれかをメッセージの送信元Ｌ２ＩＤとして使用して、受信したアプリケーション層メッセージを受け入れる。
（実施形態３、変形例２）
１）受信側ＵＥは、送信側ＵＥからアプリケーション層メッセージを受信すると、Ｌ２ＩＤの更新が行われている間、受信メッセージの送信元フィールドとして、新旧いずれかのＬ２ＩＤを含むメッセージを受け入れる。
（実施形態４、変形例１）
１）送信側ＵＥのＬ２ＩＤを見失った受信側ＵＥは、送信側ＵＥに対してＬ２ＩＤ情報の送信を要求する。
２）送信側ＵＥは、受信側ＵＥからの要求に応答して、Ｌ２ＩＤ情報を送信する。
３）受信側ＵＥは、送信側ＵＥのＬ２ＩＤを再確立する。
（実施形態４、変形例２）
１）送信側ＵＥは、受信側ＵＥに対する、Ｌ２ＩＤ更新メッセージに「デフォルト」Ｌ２ＩＤを定期的に挿入する。
２）受信側ＵＥは、受信した「デフォルト」Ｌ２ＩＤを記憶する。
３）受信側ＵＥが送信側ＵＥのＬ２ＩＤの変更を見失った場合、受信側ＵＥは「デフォルトＬ２ＩＤ」を用いて送信側ＵＥを識別する。

（開示の実施形態の機能）
有益なことに、上述の実施形態は、これらに限定されないが、以下の機能のうちの１つ以上を含む。
（実施形態１、変形例１）
ａ）送信側ＵＥは、自身のＬ２ＩＤを更新する際に、受信側ＵＥに対して、新しいＬ２ＩＤと付加情報を含むＬ２ＩＤ更新要求メッセージを送信し、これにより受信側ＵＥは、送信側ＵＥの有効性及び真正性を検証することができる。
ｂ）受信側ＵＥは、送信側ＵＥからＬ２ＩＤ更新メッセージを受信すると、新たなＬ２ＩＤを受け入れるか否かを判定する際に、メッセージ中の付加情報を用いて、受信したＬ２ＩＤ更新メッセージの有効性及び真正性を検証する。
（実施形態１、変形例２）
ａ）実施形態１の変形例１におけるＬ２ＩＤ更新メッセージ内のこの付加情報は、送信側ＵＥおよび通信コンテキストを一意に識別する１つまたは複数の情報要素、例えば、送信側ＵＥおよび受信側ＵＥに関連するＵＥ固有情報または通信コンテキスト固有情報を表す。
ｂ）新Ｌ２ＩＤに加えて、Ｌ２ＩＤ更新メッセージは、送信側ＵＥおよび上述の通信コンテキストを一意に表すこれらの情報要素のＭＡＣ（ハッシュ値）を含む。
ｃ）送信側ＵＥは、新しいＬ２ＩＤとＭＡＣ（ハッシュ値）を生成する際に、上記新Ｌ２ＩＤとＭＡＣ（ハッシュ値）を導出する際のＫＤＦ関数への入力パラメータとして、１つ以上の情報要素のセットを用いる。これにより、新Ｌ２ＩＤとＭＡＣ（ハッシュ値）に、送信側ＵＥと通信コンテキストを一意に識別する情報が反映されることが保証される。
（実施形態１、変形例３）
ａ）送信側ＵＥは、実施の形態１の変形例２に加えて、ＫＤＦ関数へのシーケンス番号を含み、新Ｌ２ＩＤとＭＡＣ（ハッシュ値）を生成する。
ｂ）シーケンス番号は、１つのＬ２ＩＤ更新メッセージに固有である。これにより、中間者リプレイ攻撃などのタイプの攻撃を防止する。
ｃ）シーケンス番号は、同じシーケンス番号値が一度だけ使用されるように、送信側ＵＥからの後続の各Ｌ２ＩＤ更新メッセージで更新される。
（実施形態１、変形例４）
ａ）送信側ＵＥは、受信側ＵＥにＬ２ＩＤ更新メッセージを送信する。
ｂ）受信側ＵＥは、送信側ＵＥから新たなＬ２ＩＤ値を受け入れるか否かを判定する際に、実施形態１の変形例１又は変形例２の記述に基づいて、受信メッセージの有効性及び真正性を検証する。
（実施形態１、変形例５）
ａ）実施形態１の変形例３に加えて、受信側ＵＥは、送信側ＵＥからＬ２ＩＤ更新メッセージを受信すると、検証及び認証チェックに基づいて、受信側ＵＥが新Ｌ２ＩＤを受け入れるか否かを示す応答メッセージ（Ｌ２ＩＤ更新応答）を送信側ＵＥに返信する。
ｂ）送信側ＵＥは、受信側ＵＥからこの応答メッセージを受信すると、各受信側ＵＥからの個々のＵＥにおける確認応答をチェックする。この結果を基に、送信側ＵＥは必要に応じて是正措置を講じる。
（実施形態１、変形例６）
ａ）通信中のＵＥは、通信を確立すると、サポートされている１つまたは複数のＫＤＦアルゴリズムを交換する。
ｂ）ＵＥは、交換された情報に基づいて、Ｌ２ＩＤ更新メッセージで送信される新Ｌ２ＩＤおよびＭＡＣ（ハッシュ値）の導出に使用されるＫＤＦアルゴリズムを判定し、これに合意する。
（実施形態１、変形例７）
ａ）通信中のＵＥは、新Ｌ２ＩＤとＭＡＣ（ハッシュ値）を導出するＫＤＦ関数に対するサポートされている１つまたは複数の入力パラメータを交換する。
ｂ）交換された情報に基づいて、ＵＥはＫＤＦ関数用の入力パラメータのセットを判定し、合意する。
（実施形態２、変形例１）
ａ）通信中のすべてのＵＥがＬ２ＩＤ更新メッセージを受信する機会を最大化するために、以下の副変形例のうち１つまたは複数のメカニズムを使用する。
（副変形例１）送信側ＵＥは、Ｌ２ＩＤ更新メッセージを複数回繰り返す。
（副変形例２）１つまたは複数の受信側ＵＥは、送信側ＵＥから受信したＬ２ＩＤ更新メッセージを中継する。
（副変形例３）１つまたは複数の受信側ＵＥは、送信側ＵＥから受信したＬ２ＩＤ更新メッセージをフラッディングする。
（副変形例４）送信側ＵＥは、Ｌ２ＩＤ更新メッセージを繰り返し、および／または１つまたは複数の受信側ＵＥは、送信側ＵＥから受信したＬ２ＩＤ更新メッセージを中継／フラッディングする。
（実施形態２、変形例２）
ａ）実施形態２の変形例１に加えて、送信側ＵＥは、リプレイ攻撃を防止するために、Ｌ２ＩＤ更新メッセージで１回だけ使用される固有情報（例えばシーケンス番号）を含める。
ｂ）受信側ＵＥは、固有情報（シーケンス番号）の一意性を確認し、受信したＬ２ＩＤ更新メッセージがオリジナルであるか、前のメッセージのリプレイであるかを判定する。
（実施形態３、変形例１）
ａ）Ｌ２ＩＤの更新が行われている間、送信側ＵＥは、送信元Ｌ２ＩＤフィールドにおいて新旧両方のＬ２ＩＤを使用して、同じアプリケーション層メッセージを受信側ＵＥに複数回送信する。
ｂ）受信側ＵＥは、個々の受信側ＵＥが旧Ｌ２ＩＤまたは新Ｌ２ＩＤを送信側ＵＥの有効なＬ２ＩＤとして認識しているかどうかにかかわらず、送信側ＵＥから受信したアプリケーション層メッセージを受け入れる。
（実施形態３、変形例２）
ａ）Ｌ２ＩＤの更新が行われている間、受信側ＵＥは、送信元Ｌ２ＩＤフィールドにおいて旧Ｌ２ＩＤまたは新Ｌ２ＩＤのいずれかを含む送信側ＵＥからのメッセージを受け入れる。
（実施形態４、変形例１）
ａ）時間の経過とともに送信側ＵＥのＬ２ＩＤの変化を追跡できなくなった受信側ＵＥは（例えば、受信側ＵＥが送信側ＵＥからのＬ２ＩＤ更新メッセージを複数回の更新サイクルで見逃した場合）、送信側ＵＥに対して、送信側ＵＥと最新のＬ２ＩＤとの間のマッピングを示すように要求する。
ｂ）受信側ＵＥは、送信側ＵＥからの受信情報を用いて、送信側ＵＥと最新のＬ２ＩＤとの相関を再確立する。
（実施形態４、変形例２）
ａ）送信側ＵＥは、受信側ＵＥに対する、Ｌ２ＩＤ更新メッセージに「デフォルト」Ｌ２ＩＤを定期的に挿入する。
ｂ）受信側ＵＥは、受信側ＵＥが時間の経過とともに送信側ＵＥのＬ２ＩＤの変化を追跡できなくなった場合（例えば、受信側ＵＥが送信側ＵＥからのＬ２ＩＤ更新メッセージを複数回の更新サイクルで見逃した場合）、「デフォルト」Ｌ２ＩＤを送信側ＵＥのフォールバックＬ２ＩＤとして識別する。
ｃ）受信側ＵＥが時間の経過とともに、送信側ＵＥのＬ２ＩＤの変化を追跡できなくなると、受信側ＵＥは「デフォルト」Ｌ２ＩＤを用いて送信側ＵＥを識別する。

（現行技術との対比における本開示の利点）
（実施形態１）
Ｌ２ＩＤ更新手順は、受信側ＵＥが受信メッセージの検証と送信側ＵＥの真正性とを検証できる方法を提供する。
この検証および真正性チェックのメカニズムは、悪意のあるＵＥが偽のＬ２ＩＤ更新メッセージを送信して、受信側ＵＥの送信側ＵＥのＬ２ＩＤマッピング情報を引き起こす可能性を防止する。
Ｌ２ＩＤ更新手順における検証情報は、ＭＡＣ（ハッシュ値）を用いて送信側ＵＥおよび新Ｌ２ＩＤを一意に識別し、検証する。
Ｌ２ＩＤ更新手順は、送信側ＵＥが受信側ＵＥによるＬ２ＩＤ更新メッセージの受諾または拒否を検証するためのオプションを提供する。
ＫＤＦ交渉メカニズムは、複数の異なるＫＤＦ関数実装を持つ様々なＵＥ実装のために、単一のＫＤＦ関数を交渉し、合意するための方法を提供する。
ＫＤＦ交渉メカニズムは、複数の異なる入力パラメータを持つさまざまなＵＥ実装のために、同じ入力パラメータのセットを交渉し合意するための方法を提供する。
（実施形態２）
これらの方法は、全てのＵＥが同じＬ２ＩＤ更新メッセージの複数のコピーを受信することができるようにするための１つまたは複数のメカニズムを使用することによって、通信中の全てのＵＥがＬ２ＩＤ更新メッセージを正常に受信できる可能性を向上させる。
この方法は、Ｌ２ＩＤ更新メッセージに固有の１回限りのパラメータを使用することで、受信側ＵＥは受信メッセージがオリジナルであるか複製されたものであるかを識別することができるため、リプレイ攻撃を防止することができる。
（実施形態３）
定期的なＬ２ＩＤ更新イベントが同時に発生する期間中に、１）新旧両方のＬ２ＩＤを使用してメッセージを複製するか、２）新旧いずれかのＬ２ＩＤのいずれかを受け入れることによって、アプリケーション層のメッセージフローが正常に受信される可能性を向上させる。
（実施形態４）
本方法は、通信中の受信側ＵＥがＬ２ＩＤ更新サイクルを複数回見逃した場合に、受信側ＵＥが送信側ＵＥのＬ２ＩＤ変更を再確立するためのメカニズムを提供する。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
Ｌ２ＩＤ（Layer 2 Identity）及び検証情報を含むメッセージを送信する第１のＵＥ（ユーザ機器）と、
前記第１のＵＥから前記メッセージを受信し、前記検証情報を用いて前記Ｌ２ＩＤを受け入れるか否かを判定する第２のＵＥ。
（付記２）
前記第１のＵＥは、ＫＤＦ（Key Derivation Function）を用いて前記Ｌ２ＩＤ及び第１のＭＡＣ（Message Authentication Code）を生成し、前記第１のＭＡＣを付加して前記メッセージを送信し、
前記第２のＵＥは、ＫＤＦを用いて第２のＭＡＣを生成し、前記第１のＭＡＣと前記第２のＭＡＣとを比較して、前記Ｌ２ＩＤを受け入れるか否かを判定する、
付記１に記載の通信システム。
（付記３）
前記第１のＵＥは、シーケンス番号を使用して、ＫＤＦにより前記Ｌ２ＩＤ及び前記第１のＭＡＣを生成し、
前記第２のＵＥは、前記シーケンス番号を使用して、ＫＤＦにより前記第２のＭＡＣを生成し、前記第１のＭＡＣと前記第２のＭＡＣとを比較して前記Ｌ２ＩＤを受け入れるか否かを判定する、
付記２に記載の通信システム。
（付記４）
前記第１のＵＥは、前記第２のＵＥに前記Ｌ２ＩＤを送信した後、前記Ｌ２ＩＤを通信に使用する、
付記１～３のいずれか１項に記載の通信システム。
（付記５）
前記第２のＵＥは、前記第２のＵＥの判定結果を示す応答メッセージを前記第１のＵＥに送信する、
付記１～４のいずれか１項に記載の通信システム。
（付記６）
前記第１のＵＥおよび前記第２のＵＥは、１つまたは複数のＫＤＦ関数を交換し、前記第１のＵＥについては前記Ｌ２ＩＤおよび前記第１のＭＡＣを生成し、前記第２のＵＥについては前記Ｌ２ＩＤおよび前記第２のＭＡＣを生成する、
付記２または３に記載の通信システム。
（付記７）
前記第１のＵＥおよび前記第２のＵＥは、パラメータを交換し、前記第１のＵＥについては前記Ｌ２ＩＤおよび前記第１のＭＡＣを生成し、前記第２のＵＥについては前記Ｌ２ＩＤおよび前記第２のＭＡＣを生成する、
付記２、３または６のいずれか１項に記載の通信システム。
（付記８）
前記第１のＵＥは、前記メッセージを複数回送信する、
付記１～７のいずれか１項に記載の通信システム。
（付記９）
前記第２のＵＥは、前記第１のＵＥから前記メッセージを受信すると、前記メッセージを中継またはフラッディングする、
付記１～８のいずれか１項に記載の通信システム。
（付記１０）
前記第１のＵＥは、複数の前記メッセージの各々にそれぞれ異なる値を挿入し、
前記第２のＵＥは、前記異なる値を使用して、前記第２のＵＥが受信した前記メッセージが最初のメッセージであるかリプレイされたメッセージであるかを判定する、
付記８に記載の通信システム。
（付記１１）
前記第１のＵＥが旧Ｌ２ＩＤを新Ｌ２ＩＤに更新すると、前記第１のＵＥは、前記旧Ｌ２ＩＤ及び前記新Ｌ２ＩＤを使用して前記メッセージを複数回送信し、
前記第２のＵＥは、前記メッセージ内の前記旧Ｌ２ＩＤまたは前記新Ｌ２ＩＤのいずれかを使用して前記メッセージを受け入れる、
付記１～１０のいずれか１項に記載の通信システム。
（付記１２）
前記第２のＵＥは、前記第１のＵＥから前記メッセージを受信する場合、前記第２のＵＥは、受信した前記メッセージの送信元の前記Ｌ２ＩＤとして、前記旧Ｌ２ＩＤ又は前記新Ｌ２ＩＤのいずれかを含む前記メッセージを受け入れる、
付記１１に記載の通信システム。
（付記１３）
前記第２のＵＥが前記第１のＵＥの前記Ｌ２ＩＤを追跡できない場合、前記第２のＵＥは、前記第１のＵＥに前記Ｌ２ＩＤの送信を要求し、
前記第１のＵＥは、前記第２のＵＥからの要求に応答して、前記第２のＵＥに前記Ｌ２ＩＤを送信し、
前記第２のＵＥは、前記第１のＵＥの前記Ｌ２ＩＤを再確立する、
付記１～１２のいずれか１項に記載の通信システム。
（付記１４）
前記第１のＵＥは、前記第２のＵＥにデフォルトＬ２ＩＤを定期的に挿入し、
前記第２のＵＥは、前記デフォルトＬ２ＩＤを受信して保存し、
前記第２のＵＥが前記第１のＵＥの前記Ｌ２ＩＤを追跡できない場合、前記第２のＵＥは前記デフォルトＬ２ＩＤを使用して前記第１のＵＥを識別する、
付記１～１３のいずれか１項に記載の通信システム。
（付記１５）
Ｌ２ＩＤ及び検証情報を含むメッセージを他のＵＥに送信する送信手段を備え、
前記検証情報は、別のＵＥが新しい前記Ｌ２ＩＤを受け入れるか否かを判定することを可能にする、
ＵＥ（ユーザ機器）。
（付記１６）
ＫＤＦ（Key Derivation Function）を用いて前記Ｌ２ＩＤ及びＭＡＣ（Message Authentication Code）を生成する生成手段をさらに備え、
前記送信手段は、前記ＭＡＣを付加して前記メッセージを送信する、
付記１５に記載のＵＥ。
（付記１７）
他のＵＥからＬ２ＩＤ及び検証情報を含むメッセージを受信する受信手段と、
前記検証情報を用いて前記Ｌ２ＩＤを受け入れるか否かを判定する判定手段と、を備える、
ＵＥ（ユーザ機器）。
（付記１８）
第１のＭＡＣ（Message Authentication Code）及び前記Ｌ２ＩＤを付加した前記メッセージは、ＫＤＦ（Key Derivation Function）を用いて生成され、
前記ＵＥは、ＫＤＦを用いて第２のＭＡＣを生成する生成手段をさらに備え、
前記判定手段は、前記第１のＭＡＣと前記第２のＭＡＣとを比較して、前記Ｌ２ＩＤを受け入れるか否かを判定する、
付記１７に記載のＵＥ。
（付記１９）
Ｌ２ＩＤ及び検証情報を含むメッセージをＵＥへ送信し、
前記検証情報は、前記ＵＥが新しい前記Ｌ２ＩＤを受け入れるか否かを判定することを可能にする、
通信方法。
（付記２０）
ＵＥからＬ２ＩＤ及び検証情報を含むメッセージを受信し、
前記検証情報を用いて前記Ｌ２ＩＤを受け入れるか否かを判定する、
通信方法。
（付記２１）
Ｌ２ＩＤ及び検証情報を含むメッセージをＵＥに送信する処理をコンピュータに実行させ、
前記検証情報によって、前記ＵＥが新しい前記Ｌ２ＩＤを受け入れるか否かを判定することを可能にする、
プログラムを格納した非一時的なコンピュータ可読媒体。
（付記２２）
ＵＥからＬ２ＩＤと検証情報を含むメッセージを受信する処理と、
前記検証情報を用いて前記Ｌ２ＩＤを受け入れるか否かを判定する処理と、
をコンピュータに実行させるためのプログラムを格納した非一時的なコンピュータ可読媒体。

当業者には、広く説明されているように、本開示の精神または範囲から逸脱することなく、特定の実施形態に示されているように、本開示に多数の変形および／または修正を行うことができることが理解されよう。したがって、本実施形態は、すべての点で例示的であり、限定的ではないと考えられる。

本出願は、２０１９年８月１６日に出願されたインド特許出願第２０１９１１０３３１３６号及び２０１９年１０月２３日に出願されたインド特許出願第２０１９１１０４３０９５号に基づく優先権の利益を主張するものであり、これらの開示の全てが参照により本明細書に組み込まれる。

１ 通信システム
３ モバイル機器
５ 基地局
７ コアネットワーク
２０ 外部ネットワーク
３１ トランシーバ回路
３３ アンテナ
３５ ユーザインタフェース
３７ コントローラ
３９ メモリ
４１ オペレーティングシステム
４３ 通信制御モジュール
５１ トランシーバ回路
５３ アンテナ
５５ ネットワークインタフェース
５７ コントローラ
５９ メモリ
６１ オペレーティングシステム
６３ 通信制御モジュール
７１ トランシーバ回路
７５ ネットワークインタフェース
７７ コントローラ
７９ メモリ
８１ オペレーティングシステム
８３ 通信制御モジュール
１００ 通信システム
１１０ ＵＥ
１１１ 送信部
１２０ ＵＥ
１２１ 受信部
１２２ 判定部

Claims (2)

1. Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ（ＵＥ）であって、
   他のＵＥと、ＰＣ５インタフェースでユニキャスト通信を行う手段と、
   前記他のＵＥに、新たなＬａｙｅｒ ２ Ｉｄｅｎｔｉｔｙ （Ｌ２ ＩＤ）と、セキュリティ情報と、シーケンス番号とを含む、リンク識別子更新要求メッセージを送信する手段と、
   前記リンク識別子更新要求メッセージを送信するごとに前記シーケンス番号を増分する手段と、
   前記他のＵＥが前記リンク識別子更新要求メッセージに基づく送信が正当であると決定した場合に、前記他のＵＥから応答メッセージを受信する手段と、
   内部のタイマーに基づき、前記他のＵＥに、前記リンク識別子更新要求メッセージを再度送信する手段と、を具備するＵＥ。
2. Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ（ＵＥ）の通信方法であって、
   他のＵＥと、ＰＣ５インタフェースでユニキャスト通信を行い、
   前記他のＵＥに、新たなＬａｙｅｒ ２ Ｉｄｅｎｔｉｔｙ （Ｌ２ ＩＤ）と、セキュリティ情報と、シーケンス番号とを含む、リンク識別子更新要求メッセージを送信し、
   前記リンク識別子更新要求メッセージを送信するごとに前記シーケンス番号を増分し、
   前記他のＵＥが前記リンク識別子更新要求メッセージに基づく送信が正当であると決定した場合に、前記他のＵＥから応答メッセージを受信し、
   内部のタイマーに基づき、前記他のＵＥに、前記リンク識別子更新要求メッセージを再度送信する、通信方法。

Images